Trading Community Architecture–TCA
Trading Community Architecture(TCA)は、サプライヤーと銀行とのR12でさらに拡張された追加のニーズに応えるために複雑な取引関係をサポートす したがって、TCAは、組織、場所、およびそれらの間の階層的な関係のネットワークを含む、あなたの商業コミュニティに属している当事者、または顧客や仕入
取引コミュニティアーキテクチャ(TCA)とは何ですか? Tca、取引コミュニティアーキテクチャとは何ですか? TCAはOracle Applicationsモジュールですか? Oracleモジュール内の機能ですか? これらは、いくつかの一般的な質問であり、多くの場合、与えられた多くの答えがあります。 TCAは、対話するエンティティの入力と管理をサポートするデータモデルです。 だから、概念を再訪することができます。
Trading Community Architectureは非常に柔軟で堅牢なモデルで、E-business Suite内の取引に関連するコンポーネントを定義しています。 ユーザーがエンティティ間の関係を作成および維持できるようにするテクノロジーとアプリケーションの実装
すべてのOracle EBS applications tcaで、顧客、見込み客、仕入先、
また、TCAはOracle Applicationsモジュールでもなく、個別のライセンスも必要でもないことに注意してください。 TCAガイドが表示されている場合は、これらがtcaの主要な機能であることがわかります
- は、顧客情報の単一のソースの基盤を提供します。
- すべてのビジネスエンティティを”当事者”(組織、人、グループ、関係)として表現し、それらを同じ方法で処理する能力。 このアプローチは、同じリポジトリ内のすべてのB2B、B2C、およびハイブリッドモデルに対応する柔軟性を提供します。
- 当事者と場所の間の多対多の関係により、重複が少なく、更新が容易になります。
- 取引コミュニティ内のエンティティ間の高度な関係モデリングのための機能。 関係者は、マトリックス階層(関係ネットワーク)内であっても、任意の数の関係を把握できます。
- 報告および割り当ての目的で使用できる任意の数のパーティ分類を設定および維持する機能。
- さまざまなビジネスデータ要件を可能にする拡張可能なデータモデル。
- 実際には、3つのエンティティがTcaモデルを推進しています。
TCA用語
- パーティー
- ‘パーティー’の概念は、タイプに関係なく、すべてのビジネスエンティティを均等に扱うことを顧客モデルに可能にします。 B2B、B2Cを簡単に処理できます。
タイプ”グループ”の当事者は、任意の数の他の当事者を単一のエンティティにグループ化することができ、家計のモデル化と購買コンソーシアムを可能にします。 - タイプ”関係”の当事者は、二つの当事者間の関係をそれ自身の権利で当事者と見なすことを可能にする
- 当事者–当事者は、ビジネス関係を締結
- Person–ソフトウェアの所有者に関心のあるユニークな個人(死んでいるか生きているか)。
- 組織–いくつかの政府当局によって認識された法人。
- グループ–ソフトウェアの所有者の使用のために作成された2人以上の人、組織またはグループの組み合わせ。
- リレーションシップ–個人と組織の間の関連。 通常、組織またはグループの連絡先。
- ‘パーティー’の概念は、タイプに関係なく、すべてのビジネスエンティティを均等に扱うことを顧客モデルに可能にします。 B2B、B2Cを簡単に処理できます。
図1:TCA論理図
- Account
- Account–顧客の購入と支払いのmonitory部分を追跡するための財務ロールアップポイントです。 パーティーとあなたのビジネスの間の顧客関係に関する詳細を格納します。
- これは、請求イベントや出荷イベントなどの売買関係を表します
- トランザクションに必要なアカウント
- アカウントは、パーティなしでは存在
- 当事者は、1つ以上の顧客アカウント
- アカウントロール–当事者がアカウントの管理または使用に関して持っている関係を持つことができます。
- 顧客アカウントサイトは、顧客アカウントのコンテキスト内で(請求または出荷の目的などで)使用されるパーティサイトです。
- 顧客取引先責任者は、顧客取引先のコンテキストで使用されるパーティ取引先責任者です。
- Account–顧客の購入と支払いのmonitory部分を追跡するための財務ロールアップポイントです。 パーティーとあなたのビジネスの間の顧客関係に関する詳細を格納します。
- 顧客
顧客アカウントは、当事者が別の当事者と入力できるビジネス関係を表します。 アカウントには、当事者との取引に関する条件に関する情報があります。 たとえば、内部使用のためにVision Distributionによって購入される商用アカウントと、エンドユーザーへの製品の販売のためにVision Distributionによって購入される再販業者アカウ
顧客アカウントごとに、取引先責任者、銀行口座、支払方法、電話番号、およびリレーションシップを定義することもできます。また、組織内の複数のビジネスラインでビジネスを取引する顧客に対して、複数の顧客アカウントを管理することもできます。
顧客アカウントごとに、個別の顧客プロファイル、住所、および連絡先を管理します。パーティサイトは、特定のパーティが物理的に配置されている場所です。 すべての当事者には1つの識別アドレスしかありませんが、1つの当事者には複数の当事者サイトを含めることができます。
顧客の住所は、請求、配送、またはその他の目的のために顧客アカウントのコンテキストで使用されるパーティサイトです。 取引先責任者は、当事者または顧客アカウントのために通信するか、または代理して行動します。
取引先責任者は、取引先または住所レベルで顧客に存在できます。 人は通常、組織の連絡先として機能しますが、他の人の連絡先にすることもできます。 たとえば、管理アシスタントが幹部の連絡先になる可能性があります。
旧モデルと新顧客モデル
イチジク2; 顧客旧モデルとTCAモデル
- 場所/サイト:場所は、住所によって記述される地理的空間内のポイントです。 パーティーサイトは場所です。
- 当事者関係:上記のタイプ(個人と組織)の2つの当事者間の関係で、その関係として保存する必要があるもの。 自分の記録。 この関係に直接対応するデータ(連絡先情報など))も格納されている。 リレーションシップは、HZ_PARTY_RELATIONSHIPSテーブルに格納されます。
TCAエンティティに考慮できる要因
- レポートを含むビジネス要件
- システム/アプリケーション要件
- 国または組織の法的要件
- グローバルな配慮
- プロセスの標準化
tcaセットアップの考慮事項tcaカスタマーモデリングを行うときは、次のことに注意してください;
- 当事者は、任意の実在の人物や組織であること。
- パーティーサイトは、パーティーや組織のための場所です。
- リレーションシップは、一般的に組織の階層構造を構築するために使用されます。
- パーティーは、販売関係が確立されると、顧客/アカウントになります。
- アカウントは通常、少なくとも一つのアクティブな’bill_to’サイトを持つ必要があります。 これは、会計および報告の目的のために役立ちます。
- パーティを作成するとき、すべてのパーティサイトがパーティとして作成できるか、または作成すべきもの。
- 通常、サイトレベルのアクティビティを親レベルのパーティとは別に表示する場合は、そのサイトを別のパーティ/エンティティとして作成する必要が
- アカウントは別のエンティティです。 あなたが販売関係を持っている場所、すなわち顧客のためだけにアカウントを作成します。 支払条件、配送および請求の設定などの販売属性を識別します。 関係の。
- 外部パーティとビジネスエンティティの関係ごとに、複数のアカウントを持つことができます。 これにより、支払条件などの販売属性の複数の
セットを持つことができます。 - あなたは、アカウント間の関係を構築し、別のために支払うために一つのアカウントを持つことができます。
- 販売または取引関係に基づいて詳細な分析を行うために取引を当事者内で分離する必要がある場合は、当事者との別々の口座を作成する必要があ
他のOracle製品とのTCAの統合
これは、TCAデータが他のOracle製品とどのように強化されるかです。
TCAの技術的なテーブル
- TCA–Customer:TCAの11i/R12顧客のための技術的な詳細はここにあります。 また、顧客モデルの古い投稿を参照することもできます。
- TCA-Suppliers
TCAのR12Supplierの技術的な詳細はこちらです。 詳細については、古い投稿を参照することもできます。
- TCA銀行