統合された顧客マスター

複数の Dynamics 365 アプリケーションで顧客データをマスターできます。 たとえば、Dynamics 365 Sales (顧客エンゲージメント アプリ) の販売アクティビティを通じて顧客行を作成したり、Dynamics 365 Commerce (財務および運用アプリ) の小売活動を通じて顧客行を作成したりできます。 顧客データの発信元に関係なく、バックグラウンドで統合されます。 統合された顧客マスターを使用すると、任意の Dynamics 365 アプリケーションに顧客データをマスタに分配することができ、Dynamics 365 application スイートを介して顧客の包括的なビューを表示できます。

顧客データ フロー

顧客は、アプリケーションで明確に定義された概念です。 したがって、顧客データの統合は、2 つのアプリケーションの間で顧客の概念を調和させるだけです。 次の図は、顧客データ フローを示します。

顧客は、商用または組織の顧客と、コンシューマーまたはエンド ユーザーの 2 種類に広く分類できます。 財務と運用、Dataverse ストア、これら 2 種類の顧客の処理方法が異なります。

財務と運用では、商用または組織の顧客とコンシューマーまたはエンド ユーザーの両方が CustTable (CustCustomerV3Entity) という名前の単一のテーブルでマスターされ、 Type 属性に基づいて分類されます。 [種類] を [組織] に設定した場合、顧客は商用または組織の顧客になります。 [種類] を [ユーザー] に設定すると、顧客はコンシューマーまたはエンド ユーザーになります。 SMMContactPersonEntity テーブルは、主要な連絡先情報を処理します。

Dataverse では、RelationshipType 属性を Customer に設定すると、取引先企業または組織の顧客を取引先テーブルでマスターし、顧客として識別します。 連絡先テーブルは、コンシューマーまたはエンド ユーザーと連絡先ユーザーの両方を表します。 コンシューマーまたはエンド ユーザーと連絡先ユーザーの間で明確な分離を提供するために、 連絡先 テーブルには Sellable という名前のブール型フラグがあります。 Sellable が True の場合、連絡先はコンシューマーまたはエンド ユーザーであり、その連絡先の見積と注文を作成できます。 販売可能がが False の場合、連絡先は顧客の主要な連絡担当者にすぎません。

販売不可能な連絡先が見積または注文プロセスに参加する場合は、[ 販売可能 ] を [True] に設定して、販売可能な連絡先として連絡先にフラグを設定します。 販売可能な連絡先になる連絡先は、販売可能な連絡先のままです。

テンプレート

顧客データには、顧客グループ、住所、連絡先情報、支払プロファイル、請求書プロファイル、およびロイヤルティ ステータスなど、顧客に関するすべての情報が含まれます。 次の表に示すように、テーブル マップのコレクションは、顧客データ操作中に連携して動作します。