当事者およびグローバル アドレス帳

  • [アーティクル]

関係者 と グローバル アドレス帳 は、財務と運用アプリケーションでの概念です。 当事者は、組織または個人の可能性があります。 当事者のプロパティ (名前、言語、連絡先、住所など) をグローバルに保存および管理するのに便利です。 次に、1 つの場所でプロパティ値が変更されると、当事者が関係するすべての場所に変更が反映されます。

当事者

当事者とは、業務に関わる人物または組織です。 当事者の概念を使用する場合、ある人または組織が1つの企業で複数の役割を果たできます (顧客、仕入先、連絡先など)。 ロールは、コンテキストおよび目的に基づいて設定されます。 Contoso と Fabrikam という 2 つの架空会社での役割の例を次に示します:

  • 仕入先 – 仕入先組織、または会社に商品やサービスを提供している唯一の個人事業主。 たとえば、Fabrikam が Contoso に供給品を販売している場合、Fabrikam は Contoso の仕入先の役割を果たしています。
  • 連絡先 – 連絡する対象の担当者。 たとえば、Contoso が Fabrikam から供給品を購入した場合、Contoso の従業員が Fabrikam の連絡先に連絡します。
  • 顧客 – 会社から物品を購入する個人または会社です。 たとえば、Contoso が Fabrikam から供給品を購入した場合、Contoso は Fabrikam の顧客となります。

当事者モデルは、多くの場合、特に当事者が複数の役割を持つ場合など、組織と個人間で中規模なリレーションシップから複雑なリレーションシップを表するために使用されます。 次にいくつか一般的な例を挙げます。

  • 当事者は、顧客と仕入先両方の可能性があります。 たとえば、北アメリカでは、Fabrikam が Contoso に対して電線を販売し、Contoso の組み立て式スピーカーを買います。 ヨーロッパでは、Fabrikam は Contoso に部品を販売しますが、Contoso の製品は買いません。
  • 当事者は、従業員と顧客両方の可能性があります。 たとえば、Contoso の従業員が Contoso から電子製品を個人的に購入したとします。
  • 個人と組織の間には多対多 (N:N) のリレーションシップである可能性があります。 たとえば、Fabrikam はサービスのスペシャリストを提供し、配置コーディネーターを採用します。 配置コーディネーターは、Fabrikam の複数の顧客からの作業依頼にサービスのスペシャリストを対応させます。 Contoso は Fabrikam の顧客の 1 人です。 Contoso がスペシャリストを必要とする場合、配置コーディネーターに連絡してその要求に対応してもらいます。 すべての顧客の要求は配置コーディネーターによって処理されるため、N:N リレーションシップが関係してきます。

次の図は、当事者のデータ モデルを示しています。

当事者のデータ モデル。

ヒント

新しい口座レコードの作成を試みている場合、当事者フィールドを使用してそのレコードを名前で検索します。 この方法で、レコードを検索したら、そのレコードを選択する必要があります。 次に当事者からのデータはすべて自動的に入力されます。 すべての必須フィールドを手動で設定する必要はありません。 この動作は、最初から組み込まれている口座、連絡先、および仕入先ページに入っています。

二重書き込みは財務と運用アプリのすべての当事者ロールをサポートしているわけではありません。 当事者ロールの完全なリストについては、グローバル アドレス帳の概要を参照してください。

グローバル アドレス帳

グローバル アドレス帳は、業務に参加する組織および個人の住所および電子住所のディレクトリです。

グローバル アドレス帳では、必要な数の住所および電子住所が格納および処理されます。 たとえば、Fabrikam には 50 か所にガソリンスタンドがあります。 場所ごとに異なる住所、電子メール アドレス、および電話番号があります。 すべての業務関連の購入はメインのガソリン スタンドに請求されますが、購入を要求した特定のガソリン スタンドまで直接出荷されます。 グローバル アドレス帳には、請求先住所として Fabrikam のメインのガソリン スタンドが格納され、出荷先住所として各ガソリン スタンドが格納されます。 住所は一度格納され、必要に応じて見積書や注文で取得できます。

業務コンテキストによっては、個人または組織が複数の役割を果たしたり、すべての役割で同じ郵便番号や電子アドレスが使用されたりする場合があります。 この場合、1 つの役割における住所の変更がもう一方のすべての役割に表示されます。 グローバル アドレス帳は、住所をグローバルに格納して処理します。

次の図は、グローバル アドレス帳のデータ モデルを示しています。

グローバル アドレス帳のデータ モデル。

お問い合わせ

Customer Engagement アプリでは、連絡先は個人です。 ただし、連絡先テーブルは、個人、ポータル ユーザー、企業と顧客間 (B2C) 顧客、または仕入先を表すために過負荷状態となっています。 表現は暗黙的であり、関連するトランザクションを調査しない限りその差は見分けられません。 連絡先テーブルは口座テーブルとの一対一 (1:1) リレーションシップに制限されています。 当事者およびグローバル アドレス帳モデルの一部として、二重書き込みでは分類用の明示的なプロパティが導入され、個人や組織の連絡先間 (口座または仕入先エンティティ) の N:N のリレーションシップが可能になります。

連絡先行には 2 種類あります。

  • ストライプ連絡先 – 会社フィールドに必須値が設定された連絡先行。
  • 非ストライプ連絡先 – 会社フィールドが空白の連絡先行。

連絡先テーブルには、次のタイプの行を格納できます。

行タイプ 説明
顧客である個人 (販売可能な連絡先や B2C 顧客など) 会社フィールドが空白ではなく、顧客であるフィールドがはいに設定されている、ストライプ連絡先レコード。
仕入先である個人 (仕入先のような唯一の個人事業主) 会社フィールドが空白ではなく、仕入先であるフィールドがはいに設定されている、ストライプ連絡先レコード。
顧客と仕入先の両方である個人 会社フィールドが空白ではなく、顧客であるフィールドがはいに設定されており、仕入先であるフィールドがはいに設定された、ストライプ連絡先レコード。 ある人物を、1 つの製品の生産者と別の製品の消費者の両方に指定できます。 財務と運用アプリと二重書き込みの両方でこのリレーションシップがサポートされます。
組織の連絡担当者で、顧客でも仕入先でもない個人 会社フィールドが空白で、顧客であるフィールドがいいえに設定されており、仕入先であるフィールドもいいえに設定された、非ストライプ連絡先レコード。

当事者テーブルの連絡先

当事者の連絡先テーブルは、口座行と連絡先行間の N:N のリレーションシップを格納して処理します。 非ストライプ行からストライプ連絡先行を除外して、非ストライプ連絡先行のみを口座または仕入先行に関連付けることができます。

たとえば、Natasha Jones と Miguel Reyes は、担当地域内の農場を診察する獣医です。 Natasha はシアトル、Miguel はケント地域を担当しています。 Customer Engagement アプリでは、農場が顧客として表され、獣医は連絡担当者として表されます。 Natasha の単一連絡先レコードは、Natasha がサービスを提供しているすべての農場と関連付けられています。 同様に、Miguel の単一連絡先レコードは、Miguel がサービスを提供しているすべての農場と関連付けられています。

これらのリレーションシップは、当事者の連絡先テーブルに格納されます。 情報は、最初から組み込まれている口座、連絡先、および仕入先ページから検索できます:

  • 口座ページで、関連付けられた連絡先タブを使用して 1 つ以上の連絡先を口座行に関連付けできます。 このように、組織の連絡担当者を割り当てます。 その後、口座の基本連絡先として 1 つの連絡先を選択できます。 簡易作成ページを使用する場合は、連絡担当者のみを選択できます。 仕入先ページを使用している場合の動作と同じで、レコード タイプが組織となります。

  • 連絡先ページで、行が顧客、仕入先、またはその両方 (ストライプ連絡先) である場合、関連付けられた連絡先タブを使用して 1 つ以上の連絡先を関連付けできます。 このように、B2C 顧客または仕入先の連絡担当者を割り当てます。 その後、基本連絡先として 1 つの連絡先を選択できます。 簡易作成ページを使用する場合は、連絡担当者のみを選択できます。

  • 連絡先ページで、行が連絡担当者 (非ストライプ連絡先) である場合、関連付けられた組織タブを使用して 1 つ以上の顧客または仕入先を関連付けできます。 このように、顧客または仕入先を基本の連絡担当者に割り当てます。 顧客または仕入先は、組織、人物、またはその両方を設定できです。 一度に 4 つのフィールドから 1 つの値のみを選択できます:

    • 当事者 ID フィールドの値を選択すると、基本の連絡先は、選択した当事者のすべての役割に割り当てられます。
    • 関連付けられた連絡先フィールドの値を選択すると、個人タイプのストライプ連絡先を選択しています。
    • 関連付けられた口座または関連付けられた仕入れ先フィールドの値を選択すると、組織を選択しています。

    連絡先ページの関連付けられた組織タブ。

    選択に関係なく、関連は当事者レベルで作成され、当事者のすべての役割に適用され、当事者の連絡先エンティティに格納されます。

メモ

Customer Engagement アプリの当事者の連絡先テーブルの表示名は、顧客/仕入先の連絡先です。

顧客であるおよび仕入れ先であるフィールドの両方がいいえに設定されている連絡先行を開くと、関連付けられた組織タブが表示されます。 このタブを使用して 1 つ以上の顧客または仕入先を連絡先に関連付けます。

顧客であるフィールドまたは仕入れ先であるフィールドのいずれかがはいに設定されている連絡先行を開くと、関連付けられた連絡先タブが表示されます。 1 つ以上の連絡先を関連付けるには、このタブを使用 します。

住所

口座、連絡先、および仕入先ページに、新しい住所タブが導入されました。 次の図に示すように、このタブではグリッドを使用して複数の住所がサポートされます。

住所のグリッド。

グリッドには、次の列が含まれています:

  • 住所の役割 – 住所の目的。
  • 基本 – 住所が基本住所かどうかを示す値。
  • 住所番号 – 住所の順序。

グリッドの上にある新しい住所ボタンを使用して、必要な数の郵便番号を作成できます。

Customer Engagement アプリでは、ユーザーがアカウントページのサマリータブで住所を入力する際、住所 1と住所 2の欄がそれぞれ納品先と請求先に対応する。 しかし、ユーザーが財務と運用アプリで郵便物の住所を作成すると、顧客レコードの最初の 2 つの住所が Address1 および Address2 フィールドに表示され、ユーザーは住所目的を配達と請求書に変更するオプションがあります。

住所の集計タブ。

同様に、連絡先ページの集計タブにある住所 1 フィールド、住所 2 フィールド、および住所 3 フィールドが、それぞれビジネス住所、配送先住所、および請求先住所に対応します。

電子アドレス

口座、連絡先、および仕入先ページに、新しい電子アドレス タブが導入されました。 次の図に示すように、このタブではグリッドを使用して複数の電子アドレスがサポートされます。

電子アドレスのグリッド。

グリッドには、次の列が含まれています:

  • タイプ – 電子アドレスのタイプ。
  • 基本 住所が基本住所かどうかを示す値。
  • 目的 – 電子アドレスの目的。

グリッドの上にある新しい電子アドレス ボタンを使用して、必要な数の住所を作成できます。

潜在顧客の資格プロセス中は、ビジネスの電話番号と携帯電話番号の両方を指定できます。 ビジネス電話番号は IsMobile=No の場合、基本電話番号と見なされ、携帯電話番号は IsMobile=Yes の場合、2 番目の電話番号と見なされます。

ヒント

アカウントとコンタクトフォームで、アドレスと電子アドレスタブを使い、郵便番号と電子アドレスを管理します。 これにより、アドレス データは財務と運用アプリに確実に同期化されます。

設定

  1. Customer Engagement アプリ環境を開きます。

  2. Separated Dual-write Application オーケストレーション パッケージの説明に従って、必要なすべてのソリューションをインストールします。

  3. 二重書き込み当事者およびグローバル アドレス帳ソリューションをインストールします。

  4. 財務と運用アプリを開きます。 データ管理モジュールに移動し、[二重書き込み] タブを選択します。二重書き込み管理ページが開きます。

  5. 手順2. と3. にインストールしたソリューションは、両方とも [Applyソリューション]((../../dev-itpro/power-platform/enable-power-platform-integration.md) 適用します。

  6. 以下のマップは、もう不要なので停止します。 代わりに、Contacts V2 (msdyn_contactforparties) マップを実行します。

    • CDS 連絡先 V2 および連絡先 (顧客連絡先を参照)
    • CDS 連絡先 V2 および連絡先 (仕入先連絡先を参照)

  7. 次のエンティティ マッピングが当事者機能に対して更新されたため、これらのマッピングには最新バージョンを適用する必要があります。

    マップ このバージョンに更新 変更
    CDS Parties (msdyn_parties) 1.0.0.2 これは、今回のリリースの一部として追加された新しいマップです。
    Contacts V2 (msdyn_contactforparties) 1.0.0.6 これは、今回のリリースの一部として追加された新しいマップです。
    Customers V3 (accounts) 1.0.0.5 PartyNumber など他の当事者関連フィールド (名前、個人情報、住所フィールド、電子連絡先住所など) を削除しました。
    Customer V3 (contacts) 1.0.0.5 PartyNumber など他の当事者関連フィールド (名前、個人情報、住所フィールド、電子連絡先住所など) を削除しました。
    Vendors V2 (msdyn_vendors) 1.0.0.6 PartyNumber など他の当事者関連フィールド (名前、個人情報、住所フィールド、電子連絡先住所など) を削除しました。
    CDS Sales quotation headers (quotes) 1.0.0.7 連絡担当者を ContactforParty 参照に置き換えました。
    Sales invoice headers V2 (invoices) 1.0.0.4 連絡担当者を ContactforParty 参照に置き換えました。
    CDS Sales order headers (salesorders) 1.0.0.5 連絡担当者を ContactforParty 参照に置き換えました。
    CDS Party postal address locations (msdyn_partypostaladdresses) 1.0.0.1 これは、今回のリリースの一部として追加された新しいマップです。
    CDS postal address history V2 (msdyn_postaladdresses) 1.0.0.2 これは、今回のリリースの一部として追加された新しいマップです。
    CDS postal address locations (msdyn_postaladdresscollections) 1.0.0.0 これは、今回のリリースの一部として追加された新しいマップです。
    Party Contacts V3 (msdyn_partyelectronicaddresses) 1.0.0.0 これは、今回のリリースの一部として追加された新しいマップです。
    Complimentary Closings (msdyn_compliemntaryclosings) 1.0.0.0 これは、今回のリリースの一部として追加された新しいマップです。
    Decision making roles (msdyn_decisionmakingroles) 1.0.0.0 これは、今回のリリースの一部として追加された新しいマップです。
    Loyalty levels (msdyn_loyaltylevels) 1.0.0.0 これは、今回のリリースの一部として追加された新しいマップです。
    Contact person titles (msdyn_salescontactpersontitles) 1.0.0.0 これは、今回のリリースの一部として追加された新しいマップです。
    Personal character types (msdyn_personalcharactertypes) 1.0.0.0 これは、今回のリリースの一部として追加された新しいマップです。
    Salutations (msdyn_salutations) 1.0.0.0 これは、今回のリリースの一部として追加された新しいマップです。
    Employment job functions (msdyn_employmentjobfunctions) 1.0.0.0 これは、今回のリリースの一部として追加された新しいマップです。
    CDS location roles (msdyn_addressroles) 1.0.0.0 これは、今回のリリースの一部として追加された新しいマップです。

  8. 上記のマップを実行する前に、次の手順の説明に従って統合キーを手動で更新する必要があります。 その後、保存を選択します。

    マップ キー
    口座 accountnumber [口座番号]
    msdyn_company.cdm_companycode [会社 (会社コード)]
    連絡 msdyn_contactpersonid [口座番号/連絡担当者 ID]
    msdyn_company.cdm_companycode [会社 (会社コード)]
    顧客/仕入先の連絡先 msdyn_contactforpartynumber [当事者番号の連絡先]
    msdyn_associatedcompanyid.cdm_companycode [関連する会社 (会社コード)]
    仕入先 msdyn_vendoraccountnumber [仕入れ先口座番号]
    msdyn_company.cdm_companycode [会社 (会社コード)]

  9. Dataverse では、重複検出ルールの文字数制限が 450 文字から 700 文字に増えました。 この制限により、重複検出ルールに 1 つ以上のキーを追加できます。 次のフ口座設定して、口座テーブルの重複検出ルールを展開します。

    フィールド 先頭値
    氏名 口座名が同じ口座。
    説明 口座名属性で同じ値を持つ口座レコードを検出します。
    基本レコード タイプ 口座
    一致するレコード タイプ 口座
    口座名 (フィールド) 完全一致
    会社 (フィールド) 完全一致
    リレーションシップ タイプ (フィールド) 完全一致
    当事者 ID (フィールド) 完全一致

    口座の重複ルール。

  10. 次のフィールドを設定して、連絡先テーブルの重複検出ルールを展開します。

    フィールド 先頭値
    氏名 名と性が同じ連絡先。
    説明 名と性フィールドに同じ値がある連絡先レコードを検出します。
    基本レコード タイプ 連絡
    一致するレコード タイプ 連絡
    名 (フィールド) 完全一致
    性 (フィールド) 完全一致
    会社 (フィールド) 完全一致
    当事者 ID (フィールド) 完全一致

    連絡先の重複ルール。

  11. 既存の二重書き込みユーザーである場合は、当事者およびグローバル アドレス帳モデルへのアップグレードの手順に従って、データをアップグレードしてください。 この手順を完了せずに手順 12 に進む必要があります。 新しい二重書き込みユーザーの場合は、手順 12 に進みます。

  12. 既存の二重書き込みユーザーの場合は、手順 11 に従ってマップを実行できます。 新しい二重書き込み顧客の場合は、直接続行できます。 次のようなエラー メッセージ、"プロジェクトの検証に失敗しました。 出力先フィールドがありません..." が示されたら、マップを開き、テーブルの更新 を選択し、マップを稼働します。

    財務と運用アプリ Customer Engagement アプリ
    CDS 関係者 msdyn_parties
    CDS の配送先の場所 msdyn_postaladdresscollections
    CDS 住所履歴 V2 msdyn_postaladdresses
    CDS 関係者の配送先の場所 msdyn_partypostaladdresses
    関係者の連絡先 V3 msdyn_partyelectronicaddresses
    顧客 V3 勘定
    顧客 V3 連絡先
    仕入先 V2 msdyn_vendors
    連絡担当者の肩書き msdyn_salescontactpersontitles
    結句 msdyn_complimentaryclosings
    あいさつ文 msdyn_salutations
    意思決定ロール msdyn_decisionmakingroles
    雇用職務権限 msdyn_employmentjobfunctions
    ロイヤルティ レベル msdyn_loyaltylevels
    個人の特徴タイプ msdyn_personalcharactertypes
    連絡先 V2 msdyn_contactforparties
    CDS 販売見積ヘッダー 見積
    CDS 販売注文ヘッダー 販売注文
    売上請求書ヘッダー V2 請求書
    CDS 住所ロール msdyn_addressroles

メモ

CDS Contacts V2 (contacts) マップは手順 1 で停止したマップです。 他のマップを実行しようとする場合、これら 2 つのマップが依存関係の一覧に表示される場合があります。 これらのマップを実行しないでください。

当事者およびグローバル アドレス帳ソリューションがインストールされたら、 Microsoft.Dynamics.SCMExtended.Plugins.Plugins.LeadPrimaryContactPostCreate: QualifyLead of lead という名前のプラグインを無効にする必要があります。 サプライ チェーンのデュアル 書き込みソリューション のバージョンが 2.3.4.203 以降の場合、プラグインの所有者によってプラグインが無効になります。 サプライ チェーンのデュアル 書き込みソリューション のバージョンが 2.3.4.203 以前の場合、サポートに連絡してプラグインを無効にします。 当事者およびグローバル アドレス帳ソリューションをアンインストールしたら、プラグインを再び有効にする必要があります。

口座、連絡先および仕入先テーブルに含まれる msdyn_*partynumber フィールド (単一行のテキスト フィールド) は、今後使用しないでください。 ラベル名には、わかりやすくするための接頭語(非推奨)が付いています。 代わりに、msdyn_partyid フィールドを使用します。 このフィールドは msdyn_party テーブルへのルックアップです。

テーブル名 古いフィールド 新しいフィールド
口座 msdyn_partynumber msdyn_partyid
連絡 msdyn_partynumber msdyn_partyid
msdyn_vendor msdyn_vendorpartynumber msdyn_partyid

テンプレート

次の表に示すように、テーブル マップのコレクションは、当事者とグローバル アドレス帳の操作中に連携して動作します。

財務と運用アプリ Customer Engagement アプリ Description
連絡担当者の肩書き msdyn_salescontactpersontitles
顧客 V3 勘定
顧客 V3 連絡先
CDS 関係者 msdyn_parties
CDS 関係者の配送先の場所 msdyn_partypostaladdresses
CDS 住所履歴 V2 msdyn_postaladdresses
CDS の配送先の場所 msdyn_postaladdresscollections
CDS 販売見積ヘッダー 見積
CDS 販売注文ヘッダー 販売注文
結句 msdyn_complimentaryclosings
連絡先 V2 msdyn_contactforparties
意思決定ロール msdyn_decisionmakingroles
雇用職務権限 msdyn_employmentjobfunctions
ロイヤルティ レベル msdyn_loyaltylevels
関係者の連絡先 V3 msdyn_partyelectronicaddresses
個人の特徴タイプ msdyn_personalcharactertypes
売上請求書ヘッダー V2 請求書
あいさつ文 msdyn_salutations
仕入先 V2 msdyn_vendors
CDS 住所ロール msdyn_addressroles

詳細については、二重書き込みマッピングのリファレンス を参照してください。

複数選択ドロップダウン リストとしてのアドレス ロール

住所または電子住所は複数の目的に使用できます。 たとえば、1 つの郵便番号を、請求先住所と配送先住所の両方に使用できます。 そのような場合、ユーザーは、次の図に示すように、ドロップダウン リストで請求と出荷の両方を選択できます。

[目的/役割] ドロップダウン リスト。

既知の問題と制限事項

  • 財務と運用アプリでは、顧客を住所と共に作成して保存すると、住所が 住所 テーブルに同期しない可能性があります。 これは、二重書き込みプラットフォームの順序付けの問題が原因です。 回避策として、最初に顧客を作成して保存します。 次に、住所を追加します。

  • 財務と運用アプリでは、顧客レコードに基本住所があり、その顧客に対して新しい連絡先を作成すると、連絡先レコードは顧客レコードからの基本住所を継承します。 これは仕入先の連絡先に関しても発生します。 Dataverse は現在、この動作をサポートしていません。 二重書き込みが有効である場合、財務と運用アプリからの基本住所と共に継承された顧客の連絡先は、その住所と共に Dataverse に同期されます。

  • 財務と運用アプリでは、連絡先の追加 フォームから連絡先レコードを追加できます。 連絡先の表示フォームから新しい連絡先を作成 しようとする場合、アクションは失敗します。 これは、既知の問題です。

    連絡先の追加に関する既知の問題。

  • 初期同期では ContactForParty の開始および終了日時フィールドをサポートしませんが、これは DIXF が値を整数ではなく文字列に変換するためです。 この変換によりエラー Cannot convert the literal '<say 08:00:00>' to the expected type edm.int32 が発生します。

  • 二重書き込み機能を持つ財務と運用アプリを使用すると、先日付の郵便住所を入力できません。これは Dataverse が日付の有効性をサポートしないためです。 財務と運用アプリを使用して将来日付の住所を入力すると、その住所が Dataverse に完全同期され、ユーザー インターフェイスにすぐに住所が表示されます。 このレコードを更新すると、財務と運用アプリで将来の日付が付けられ、現在ではないため、エラーが発生します。