> 継続的なプロセス改善 > 与信管理・債権回収 > Microsoft Dynamics 365 > データテンプレート

信用管理と債権回収のデータテンプレート

Microsoft Dynamics 365

与信管理・債権回収の属性 (19) 与信管理・債権回収のアクティビティ (12) 抽出ガイド (2)

信用管理と債権回収のデータテンプレート

このテンプレートでは、信用管理と債権回収プロセスの分析に必要なデータを収集する方法を詳しく説明します。必要なデータ属性、追跡すべき主要なアクティビティ、データ抽出の手順をまとめています。この資料を使ってデータ準備を効率化し、プロセスマイニングをすばやく始めてください。

詳細な分析に必要な推奨属性
正確なプロセスディスカバリーに必要な主要アクティビティ
システムからデータを抽出するための手順

イベントログを初めて扱いますか。学ぶプロセスマイニングのイベントログを作成する方法.

テンプレートをダウンロード

与信管理・債権回収の属性

与信管理・債権回収プロセスを詳細に分析するために、イベントログに含めることを推奨するデータ項目です。

3 必須 8 推奨 8 任意

	名前	説明
	アクティビティ名 ActivityName	請求書のライフサイクルにおける特定の時点で発生したイベントまたはタスクの名前です。
説明アクティビティ名は、信用・回収プロセス内の具体的なステップやイベントを表します。たとえば、「請求書を生成」「督促状を送付」「入金を受領」などです。この属性はプロセスマイニングの基盤であり、プロセスマップ上のノードを定義します。アクティビティの順序と頻度を分析すると、実際のプロセスフローを把握し、手戻りループ、非効率な処理、コンプライアンスに反するプロセス経路を特定できます。すべてのプロセスフローの可視化を支え、プロセスの各段階間のサイクルタイム計算にも使用されます。重要な理由この属性によってプロセスマップ上のステップが定義され、請求書のライフサイクルを可視化・分析できます。入手先通常は、「CustInvoiceJour」「CustTrans」「CustCollectionLetterJour」「CustPaymPromise」などの各テーブルから、特定のシステムイベント、ステータス変更、レコード作成日を標準化されたアクティビティ名にマッピングして取得します。例請求書を計上して送付督促状を生成紛争を登録入金受領
	イベント時刻 EventTime	特定のアクティビティまたはイベントが発生した時点を示すタイムスタンプです。
説明イベント時刻は、アクティビティがシステムに記録された正確な日時です。プロセスマイニングの基盤となる属性であり、プロセスフローの構築や、時間に関するすべての指標の計算に必要な時系列を提供します。期間の分析、ボトルネックの特定、SLAの監視にも欠かせません。たとえば、「請求書を生成」から「入金を受領」までの時間差を使って、重要な業務KPIである売上債権回転日数（DSO）を計算します。正確なタイムスタンプがなければ、パフォーマンス分析やボトルネックの特定はできません。重要な理由このタイムスタンプは、イベントの順序付け、プロセスマップの発見、サイクルタイムや期間などすべてのパフォーマンス指標の計算に欠かせません。入手先通常は、アクティビティに応じて、D365の各テーブルにある日時フィールドから取得します。たとえば、「CustInvoiceJour」の「CreatedDateTime」や「CustTrans」の「TransDate」などです。例 2023-01-15T09:30:00Z2023-02-28T14:12:55Z2023-03-20T11:05:10Z
	請求書番号 InvoiceNumber	各顧客請求書を一意に識別する識別子であり、信用管理プロセスにおける主要なケース識別子です。
説明請求書番号は、顧客との各財務取引を一意に識別する重要な属性です。請求書の生成や転記から、入金回収、最終決済まで、関連するすべてのアクティビティを結び付けます。プロセスマイニングでは、この番号を使って各請求書のエンドツーエンドの経路を再構成し、ライフサイクルを詳細に分析できます。請求書ごとに個別のケースとして追跡することで、組織は共通するプロセス経路、ボトルネック、標準手順からの逸脱を特定できます。また、売上債権回転日数やプロセスパターンなどの主要指標を計算する基盤になります。重要な理由すべてのプロセスイベントを結び付け、請求書から入金までのライフサイクル全体を再構成・分析するために欠かせないCase IDです。入手先通常は、Microsoft Dynamics 365 Financeの「CustInvoiceJour」テーブルにある「Invoice」フィールドです。例 INV-0012345CIV-2023-8876SI-9510034
	回収担当者を割り当て CollectorAssigned	延滞請求書の管理を担当する回収担当者またはチームメンバーの名前です。
説明特定の請求書に関する回収活動を担当する従業員を識別する属性です。パフォーマンスや業務量の分析に欠かせません。回収担当者でプロセスマップやダッシュボードを絞り込むことで、管理者は個人の生産性を評価し、回収方法を比較し、指導の機会を特定できます。「回収チームの生産性」や「異議申立て解決サイクルタイム」ダッシュボードの主要な分析軸であり、プロセスの結果を個人またはチームに関連付けるのに役立ちます。重要な理由回収チームのパフォーマンス分析と業務量の平準化を可能にし、回収担当者の効果を比較してベストプラクティスを特定できます。入手先 Microsoft Dynamics 365のドキュメントを参照してください。回収管理モジュール、または顧客・取引レコードの担当者フィールドから取得できる可能性があります。例 John SmithEmily JonesCollections Team A
	延滞日数 DaysOverdue	請求書が支払期日を過ぎている日数です。
説明延滞日数は、未払いの請求書について支払期日から経過した期間を測る計算指標です。現在の日付から支払期日を引いて算出します。回収チームが対応の優先順位を決めるための重要なKPIです。「セグメント別の延滞請求書」ダッシュボードの主要指標であり、売掛金の健全性や回収活動の有効性を評価する基盤になります。重要な理由回収活動の優先順位付けと支払い遅延の深刻度の測定に使用する重要な業務指標です。入手先計算フィールドです。ロジックは「請求書が未払いの場合は（Today()－PaymentDueDate）、それ以外は0」です。例 1532910
	支払期日 PaymentDueDate	契約上、請求書の支払いが必要となる日付です。
説明支払期日は、顧客と合意した支払条件によって定められる重要な日付属性です。請求書が延滞しているかを判断する基準になります。また、督促の送付や正式な督促手続きの開始など、回収活動を始める主なトリガーです。プロセスマイニングでは「延滞日数」の計算や、督促方針への準拠確認に使用します。たとえば、支払期日を過ぎてからX日以内に督促を送付したかを確認できます。重要な理由支払いの適時性を測る基準であり、延滞や回収に関するすべての活動を開始するトリガーです。入手先通常は、「CustTrans」または「CustInvoiceJour」テーブルの「DueDate」フィールドにあります。例 2023-02-142023-03-312023-04-30
	督促レベル DunningLevel	延滞請求書に対する督促（回収）プロセスの現在の段階または深刻度を示します。
説明督促レベルは、体系化された督促手続きにおける段階を表します。たとえば、「レベル1：穏やかな督促」「レベル2：正式通知」「レベル3：最終警告」などです。この属性を追跡することは、回収戦略の成果を評価するうえで欠かせません。「督促戦略の有効性」ダッシュボードでは、各レベルに達した後に支払われた請求書の割合を表示します。これにより、顧客との関係を維持しながら支払いを促すため、督促ワークフローを改善できます。重要な理由督促戦略の有効性を測定し、顧客がどの段階で支払う可能性が高いかを把握するための重要な属性です。入手先通常は、「CustCollectionLetterJour」など、回収や督促状に関連するテーブルにあります。例 123：最終法的措置
	請求書ステータス InvoiceStatus	請求書のライフサイクルにおける現在のステータスです。
説明請求書ステータスは、請求書がプロセスのどの段階にあるかを示します。たとえば、「未決済」「支払済み」「異議申立て中」「償却済み」などです。アクティビティログが詳細な履歴を提供する一方で、現在のステータスはフィルタリングや概要レポートに役立つケース単位の属性です。未決済で延滞している請求書だけに絞り込んだり、償却済み請求書全体の特徴を分析したりできます。売掛金の現在の状態を把握するための、シンプルで有効な方法です。重要な理由現在の状態に基づいて請求書を簡単に絞り込み、分析できます。たとえば、未決済または異議申立て中のケースだけに焦点を当てられます。入手先「CustTrans」テーブルの取引決済ステータスから導出されます。未決済の取引は未入金、クローズ済みの取引は決済済みです。例未処理支払済み一部支払済み償却済み
	請求書金額 InvoiceAmount	請求書の金銭的な総額です。
説明請求書金額は、請求対象となる商品またはサービスの総額を表します。プロセスの財務分析における基本的な属性です。金額でケースを分類することで、高額請求書が異なるプロセスをたどるか、より長い遅延が発生するかを確認できます。「回収不能請求書の償却」や「信用限度額管理分析」ダッシュボードで、財務への影響を定量化し、リスクを評価するために使用します。重要な理由財務への影響を分析し、高額請求書の対応に優先順位を付け、請求書金額がプロセスの動きに与える影響を把握できます。入手先「CustInvoiceJour」テーブルの「InvoiceAmount」フィールドである可能性が高いです。例 1500.7525000.00549.99
	顧客セグメント CustomerSegment	規模、業種、戦略的重要性などによる顧客の分類です。
説明顧客セグメントは、顧客を意味のあるグループに分類するためのカテゴリ属性です。たとえば、「戦略的アカウント」「中堅・中小企業」「政府機関」などです。この分類は戦略分析に欠かせません。「戦略的アカウントのDSOは低いか」「特定の業種セグメントで償却が多いか」といった問いに答えられます。「売上債権回転日数の推移」「回収不能請求書の償却」「セグメント別の延滞請求書」ダッシュボードで直接使用し、個々の顧客を超えた全体傾向を把握します。重要な理由顧客グループ全体を対象に分析し、戦略的な傾向を特定するとともに、セグメントごとに回収方法を調整できます。入手先多くの場合、「CustTable」（顧客マスターテーブル）の属性から作成したカスタムフィールド、またはそこから導出される値です。例大企業中堅企業公共部門パートナー
	顧客名 CustomerName	請求書の発行先である顧客の正式名称です。
説明顧客名は、請求書に関連する特定の顧客を識別します。フィルタリングと分類に使用する主要な分析軸です。顧客別にプロセスを分析すると、支払いが常に遅れる、異議申立てが多い、回収に多くの対応を要する顧客を特定できます。「異議申立て解決サイクルタイム」ダッシュボードや、特定の顧客アカウントを詳しく分析する際に重要な属性です。重要な理由顧客ごとのプロセス分析を可能にし、主要顧客や対応に課題のあるアカウントの傾向を把握して、関係を適切に管理できます。入手先通常は、「CustInvoiceJour」にある顧客アカウント番号を使って「CustTable」から結合します。例 Contoso Ltd.Adventure WorksFabrikam Inc.
	ソースシステム SourceSystem	データの取得元となるシステムを識別します。
説明イベントデータが記録されたソースアプリケーションを指定する属性です。この場合は「Microsoft Dynamics 365」です。単一システムの分析では固定値に見える場合もありますが、データガバナンス、トラブルシューティング、将来の連携に欠かせません。別のCRMや回収代理店ポータルなど、他のシステムのデータを含める場合、このフィールドによってシステム間を区別し、システム横断のプロセス全体を把握できます。重要な理由データの系譜を明確にし、データ品質の維持と、複数の連携システムにまたがる分析に役立ちます。入手先通常は、データ抽出時にレコードの取得元を示す固定値として付加されます。例 Microsoft Dynamics 365D365 F&O
	信用限度額 CreditLimit	顧客に承認された信用供与額の上限です。
説明信用限度額は、顧客が負債として保有することを認められた総額です。リスク管理に欠かせない属性です。「信用限度額管理分析」ダッシュボードでは、この値と延滞または償却済みアカウントの請求書金額を比較します。信用限度額が適切に設定・適用されているか、債務不履行となる顧客の限度額が最近引き上げられていないかを分析し、信用承認プロセスの潜在的な弱点を明らかにできます。重要な理由リスク評価に欠かせない属性です。償却が、顧客の信用限度額の管理不備や設定不足に関連しているかを分析できます。入手先通常は「CustTable」の顧客マスターレコードに保存されます。例 10000.0050000.000.00
	最終データ更新日時 LastDataUpdate	データを最後に更新またはリフレッシュした時点のタイムスタンプです。
説明ソースシステムからデータセットが最後に更新された時点を示す属性です。プロセスマイニング分析の利用者にとって重要なメタデータであり、データの鮮度を把握できます。データが特定の時点まで最新であることを確認できるため、分析結果の範囲を理解し、適切な判断を下せます。通常は、データ取り込みパイプラインでデータセット全体に付与されます。重要な理由データの更新時点を利用者に知らせ、分析対象の期間を明確にします。古い情報に基づく判断を防ぐことにもつながります。入手先 ETL／データパイプラインの実行時に生成され、データセットに付与されます。例 2023-04-01T02:00:00Z2023-04-02T02:00:00Z
	国 Country	顧客の請求先住所がある国です。
説明顧客アカウントに関連付けられた国を示す属性です。地理的分析でよく使われる分析軸です。DSOや償却率などのプロセスKPIを国別に分類すると、顧客の支払行動、回収の有効性、経済状況における地域差を把握できます。その結果、地域に応じた回収戦略や、特定地域向けの異なる支払条件を設定できます。重要な理由地理的な分析を可能にし、支払行動や回収プロセスのパフォーマンスにおける地域傾向を特定できます。入手先顧客マスターレコード（「CustTable」）から主住所レコード（通常は「LogisticsPostalAddress」）に結合して導出します。例 USADEUGBRCAN
	異議申立ての有無 IsDisputed	請求書が過去に一度でも異議申立てを受けたかを示すブール型フラグです。
説明請求書ケースに「異議申立てを登録」アクティビティが含まれている場合にtrueとなる計算フラグです。異議申立てのある請求書とない請求書のプロセスフローを簡単に比較・絞り込みできます。たとえば、異議申立てのある請求書とない請求書の平均DSOを比較し、異議申立てがキャッシュフローに与える影響を定量化できます。概要ダッシュボードや比較分析に役立つ属性です。重要な理由異議申立てのある請求書とない請求書を簡単に比較でき、分析やフィルタリングを効率化します。入手先計算フィールドです。ロジックは「ケースに『異議申立てを登録』アクティビティが含まれている場合はtrue、それ以外はfalse」です。例 truefalse
	異議申立て理由 DisputeReason	顧客が請求書に異議を申し立てた理由です。
説明顧客が請求書に異議を申し立てる際、通常は「価格の誤り」「商品の破損」「二重請求」などの理由を示します。この属性はその理由を記録します。異議申立て理由を分析することは、根本原因の分析に欠かせません。販売、出荷、請求部門など、受注から入金までのプロセスで繰り返し発生する問題を特定できます。問題の発生源で異議申立てを減らすことは、この分析の重要な成果であり、支払いの遅延を防いでDSOに直接影響します。重要な理由支払い遅延の根本原因を分析するための重要なデータを提供し、請求書の異議申立てにつながる上流工程の問題を特定・解消できます。入手先 Microsoft Dynamics 365のドキュメントを参照してください。異議申立て管理またはケース管理の機能に含まれている可能性があります。例価格誤り数量不足商品未受領サービス内容相違
	異議申立て解決時間 DisputeResolutionTime	顧客から最初に異議申立てが登録されてから、解決するまでにかかった時間です。
説明異議申立て解決時間は、異議申立て対応プロセスの効率を測定します。「異議申立てを登録」と「異議申立てを解決」のアクティビティ間の期間として計算します。解決に時間がかかると、支払いが遅れ、顧客満足度が低下する可能性があります。回収担当者や異議申立て理由別にこの指標を分析すると、異議申立て管理ワークフローのボトルネックや改善領域を特定できます。重要な理由異議申立て対応プロセスの効率を測定します。このプロセスは、支払いが大幅に遅れる一般的な原因の一つです。入手先「異議申立てを登録」と「異議申立てを解決」のアクティビティに記録されたタイムスタンプ間の期間として計算します。例 7.215.83.5
	通貨コード CurrencyCode	請求書の通貨です。たとえば、USDやEURなどです。
説明通貨コードは、請求書金額の取引通貨を指定します。多国籍組織では特に重要な文脈情報です。財務数値を正しく解釈するために必要であり、支払サイクルや問題が特定の通貨と関連しているかを分析する際にも使用できます。為替や国際決済の複雑さが関係している可能性があります。重要な理由すべての金額を解釈するための重要な情報を提供し、複数通貨にまたがるプロセスを分析できます。入手先通常は「CustInvoiceJour」テーブルの「CurrencyCode」フィールドにあります。例 USDEURGBPCAD

必須推奨任意

与信管理・債権回収のアクティビティ

与信管理・債権回収ワークフローを正確にディスカバリーするために、イベントログに記録すべき主要なプロセス手順とマイルストーンです。

9 推奨 3 任意

	アクティビティ	説明
	入金受領	顧客からの入金を受領し、通常は入金仕訳を通じてシステムに入力したことを示します。このイベントは、特定の請求書への最終的な転記および入金の消込に先行します。
重要な理由 DSOの計算とキャッシュフローの把握における重要なマイルストーンです。このイベントから入金転記までの時間差から、入金消込プロセスのボトルネックが明らかになります。入手先転記前に作成された顧客入金仕訳明細（LedgerJournalTrans）の日付から取得される明示的なイベントです。入金を受領した日付を表します。取得顧客入金仕訳明細の取引日を使用します。イベントタイプ explicit
	入金転記	顧客からの入金を総勘定元帳に正式に転記し、請求書の決済に充当したことを表します。顧客入金仕訳の転記日から取得されます。
重要な理由入金プロセスの完了を示します。入金受領から転記までの時間、つまり入金消込の遅延時間は、財務部門の効率を測る重要な指標です。入手先顧客入金仕訳（LedgerJournalTrans）の転記タイムスタンプから取得されます。入金が元帳上で完全に処理されたことを確認します。取得転記済みの顧客入金仕訳から転記日を使用します。イベントタイプ explicit
	支払期日を経過	現在の日付が請求書の支払期日を過ぎた時点で発生する計算上のイベントです。ユーザーの直接操作に対応するアクティビティではなく、システム日付と請求書の支払期日フィールドを比較して導出します。
重要な理由すべての回収アクティビティの起点となるイベントです。支払期限を過ぎた請求書の件数や督促アクションの適時性を分析でき、督促ポリシー遵守などのKPIを支援します。入手先 Customer Transactionsテーブル（CustTrans）の「DueDate」フィールドと現在のタイムスタンプを比較して計算します。イベントタイムスタンプはDueDateそのものです。取得「NOW()」が請求書のDueDateより大きくなった時点でイベントを作成します。イベントタイプ calculated
	督促状を生成	支払期限を過ぎた請求書に対して、正式な督促状または回収通知が作成されたことを示します。Dynamics 365で定期的な督促プロセスを実行し、対象となる請求書の通知レコードが生成された時点で記録されます。
重要な理由正式な回収活動の開始と頻度を追跡します。督促の有効性と社内回収ポリシーの遵守状況を測定するために欠かせません。入手先 Dunning Historyテーブル（CustCollectionLetterJour）に明示的なレコードが作成されます。督促状ジャーナルの作成日がタイムスタンプになります。取得 CustCollectionLetterJourテーブルから作成イベントを抽出し、請求書に紐付けます。イベントタイプ explicit
	紛争を登録	顧客が請求書に対して正式に異議を申し立て、ステータスが更新されたことを示します。通常は、回収管理モジュールでユーザーが請求書のステータスを「Disputed」に変更した際に記録されます。
重要な理由紛争解決プロセスの開始点です。追跡することで、紛争の発生頻度と解決にかかる時間を測定でき、顧客満足度とキャッシュフローの改善に役立ちます。入手先顧客取引（CustTrans）または関連する紛争管理テーブル（smmCaseDetail）のステータス変更から推定します。ステータス変更を記録したタイムスタンプ付きログが必要です。取得請求書取引の紛争ステータスフィールドに値が入力された時点、または「Disputed」に変更された時点を特定します。イベントタイプ inferred
	請求書を作成	請求書が正式に計上される前に、システム上で販売請求書レコードが作成されたことを示します。通常は、ユーザーが販売注文を確定し、対応する請求書ドキュメントを生成した際に記録される明示的なイベントです。
重要な理由請求書ライフサイクルの主な開始イベントです。この時点から入金までの期間を分析することは、売上債権回転日数（DSO）の測定に欠かせません。入手先請求書の作成時に、Sales Invoice Headerテーブル（SalesInvoiceHeader）またはSalesテーブル（SalesTable）に記録されます。レコードの作成タイムスタンプがイベント時刻になります。取得販売請求書レコードの作成タイムスタンプを取得します。イベントタイプ explicit
	請求書を計上して送付	総勘定元帳に請求書を正式に記録し、正式な売掛金にすることを示します。通常は顧客への請求書送付と同時に発生し、Dynamics 365で計上処理が完了した時点で記録されます。
重要な理由支払条件と滞留期間の計測を正式に開始する重要なマイルストーンです。作成から計上までの遅れは、請求プロセスの非効率を見えにくくする可能性があります。入手先 Customer Invoice Journal（CustInvoiceJour）の計上日、またはステータスが「Posted」に変更されたことから推定します。計上タイムスタンプが主要なデータポイントです。取得 Customer Invoice Journal（CustInvoiceJour）の計上タイムスタンプを使用します。イベントタイプ inferred
	請求書償却	請求書が回収不能と判断され、貸倒損失として正式に償却された状態です。承認済みユーザーが実行する明示的な処理であり、売掛金を消去して損失を転記します。
重要な理由プロセスにおける主な異常終了地点です。償却を追跡することは、信用リスク、回収失敗、財務上の損失を把握するうえで欠かせません。入手先元の請求書に関連付けられた、貸倒損失の償却に使用する特定の一般仕訳取引から取得されます。償却仕訳の転記日がタイムスタンプになります。取得請求書を参照する、特定の償却転記プロファイルを持つ仕訳明細を特定します。イベントタイプ explicit
	請求書決済完了	請求書の支払いが完了し、残高がゼロになった状態です。プロセスが正常に完了したことを示します。適用された入金の合計が請求書の総額と一致した時点から推定されます。
重要な理由信用から入金までのプロセスにおける、主な正常終了地点です。ここに至る経路を分析すると、ベストプラクティスや効率的なプロセスのパターンを把握できます。入手先顧客決済テーブル（CustSettlement）の決済日から推定されます。CustTrans内の請求書について、「AmountCur」と「SettleAmountCur」の合計がゼロになった時点で発生します。取得残高をゼロにした請求書取引に関連する、最新の決済日を特定します。イベントタイプ inferred
	回収アクティビティを記録	顧客または請求書に対して記録された、電話やメールなどの手作業による回収アクションを示します。回収担当者が回収ワークスペース内のActivities機能を使ってやり取りを記録した時点で取得されます。
重要な理由回収チームによる手作業の負荷を可視化します。こうしたアクティビティと入金の成功を比較することで、チームの生産性や連絡方法ごとの有効性を測定できます。入手先顧客アカウントに関連付けられたActivities（smmActivities）または関連するケース管理テーブルに記録されます。可能であれば、アクティビティを特定の請求書に紐付ける必要があります。取得回収に関連するタイプが「Phone Call」または「Email」のActivityレコードの作成を取得します。イベントタイプ explicit
	支払約束を作成	顧客が特定の将来の日付に支払うことを約束し、その約束がシステムに記録されたことを示します。回収担当者が回収モジュールに支払約束の詳細を入力した時点で、明示的に記録されます。
重要な理由非公式な支払合意と、その履行率を追跡します。約束と実際の入金を比較することで、キャッシュフローの予測や顧客の信頼性の評価に役立ちます。入手先回収ワークスペースまたはケース管理に関連する、特に支払約束機能用のテーブルに記録される可能性があります。支払約束レコードの作成日がイベント時刻になります。取得支払約束または回収ケースの詳細テーブルから作成イベントを取得します。イベントタイプ explicit
	紛争を解決	解決策が決まり、記録された紛争プロセスの終了を示します。ユーザーが請求書の紛争ステータスを「Resolved」に更新するか、関連する紛争ケースを終了した時点で記録されます。
重要な理由このアクティビティで紛争サブプロセスが完了します。紛争登録から解決までの期間は、解決チームの効率を測定する主要なKPIです。入手先顧客取引（CustTrans）のステータス変更、または関連する紛争ケース（smmCaseDetail）のクローズから推定されます。このステータス変更のタイムスタンプがイベント時刻です。取得請求書の紛争ステータスフィールドがクリアされた時点、または「Resolved」に変更された時点を特定します。イベントタイプ inferred

推奨任意

抽出ガイド

Microsoft Dynamics 365からデータを取得する方法

ステップ

前提条件を確認する：組織でMicrosoft Dynamics 365 Financeを利用し、Bring Your Own Database（BYOD）機能を設定して、データエンティティをAzure SQL Databaseへエクスポートしていることを確認します。このAzure SQL Databaseへの読み取りアクセス資格情報も必要です。
データエンティティを特定する：必要なデータエンティティがDynamics 365からBYODへエクスポートされていることを確認します。このプロセスの主要エンティティは、CustInvoiceJour、CustTrans、CustTable、CustCollectionLetterJour、CustSettlement、smmActivities、CustPromisedPayment、CustDisputeです。不足しているエンティティがある場合は、Dynamics 365のデータ管理ワークスペースでエクスポート対象に設定します。
BYODデータベースに接続する：SQL Server Management Studio（SSMS）やAzure Data StudioなどのSQLクライアントを使い、BYODの保存先であるAzure SQL Databaseに接続します。
SQLクエリを準備する：このドキュメントのqueryセクションにあるT-SQLクエリ全体をSQLクライアントにコピーします。このクエリは、必要なすべてのアクティビティと属性を1つのイベントログ形式にまとめます。
クエリパラメーターを設定する：クエリの先頭にあるプレースホルダーを確認します。'{CompanyCode}'を対象のDynamics 365法人ID（例：「USMF」）に置き換えます。'{StartDate}'と'{EndDate}'は、分析対象の日付範囲に置き換え、「YYYY-MM-DD」形式で指定します。
クエリを実行する：変更したクエリをBYODデータベースに対して実行します。実行時間は、選択した日付範囲のデータ量によって異なります。
結果を確認する：クエリが完了すると、結果ペインにイベントログが表示されます。各行は、請求書に関する信用管理と債権回収のライフサイクル上の特定のアクティビティを表します。データの完全性と正確性を確認します。
イベントログをエクスポートする：クエリ結果をCSVファイルにエクスポートします。多くのSQLクライアントには、クエリ結果をエクスポートする機能が組み込まれています。結果グリッドを右クリックし、「結果を名前を付けて保存」や「エクスポート」などの項目を選択します。
アップロードの準備をする：エクスポートしたCSVファイルがUTF-8エンコードで、列見出しが必須属性のInvoiceNumber、ActivityName、EventTimeおよび追加した推奨属性と一致していることを確認します。これでProcessMindにアップロードできます。

設定

前提条件：Bring Your Own Database（BYOD）機能を設定して稼働させたMicrosoft Dynamics 365 for Financeの環境にアクセスできること。対象のAzure SQL Databaseへの読み取り権限が必要です。
データエンティティ：抽出には、複数の標準データエンティティをBYODへエクスポートする必要があります。少なくともCustInvoiceJour、CustTrans、CustTable、CustSettlementがBYODのエクスポートジョブに含まれていることを確認してください。特定のアクティビティには、CustCollectionLetterJourなどの追加エンティティが必要です。
日付範囲：パフォーマンスを管理するため、クエリを特定の日付範囲で絞り込むことが重要です。初期分析には3～6か月分のデータを推奨します。提供されているクエリでは、'{StartDate}'と'{EndDate}'のプレースホルダーを使用します。
会社フィルター：データの整合性を保つため、クエリを特定の法人（会社コード）で絞り込む必要があります。分析対象の会社を'{CompanyCode}'プレースホルダーで指定します。
パフォーマンスに関する考慮事項：複数年または複数社にまたがる非常に大規模なデータセットでは、クエリの実行に時間がかかることがあります。利用の少ない時間帯に実行するか、追加のフィルターでデータ範囲を絞り込んでください。BYODテーブルの日付列とキー列に適切なインデックスがあることを確認します。

a サンプルクエリ sql

WITH BaseInvoices AS (
    SELECT 
        cj.INVOICEID AS InvoiceNumber,
        cj.INVOICEDATE AS InvoiceDate,
        cj.DUEDATE AS PaymentDueDate,
        cj.INVOICEAMOUNTMST AS InvoiceAmount,
        ct.NAME AS CustomerName,
        ct.CUSTGROUP AS CustomerSegment,
        -- The collector assignment can be complex. This is a common approach.
        -- It assumes the collector is assigned at the customer level in CustTable.
        -- Your configuration may differ, for example using collection pools.
        col.NAME AS CollectorAssigned,
        cj.DATAAREAID
    FROM 
        dbo.CustInvoiceJour cj
    JOIN 
        dbo.CustTable ct ON cj.INVOICECUST = ct.ACCOUNTNUM AND cj.DATAAREAID = ct.DATAAREAID
    LEFT JOIN 
        -- Placeholder for how collector might be identified. You may need to join to a different table.
        dbo.CollectionsAgent col ON ct.COLLECTIONAGENT = col.AGENTID
    WHERE 
        cj.DATAAREAID = '{CompanyCode}'
        AND cj.INVOICEDATE BETWEEN '{StartDate}' AND '{EndDate}'
)

-- 1. Invoice Generated
SELECT 
    bi.InvoiceNumber AS InvoiceNumber,
    'Invoice Generated' AS ActivityName,
    cj.CREATEDDATETIME AS EventTime,
    bi.CollectorAssigned,
    bi.InvoiceAmount,
    bi.CustomerName,
    bi.CustomerSegment,
    bi.PaymentDueDate,
    0 AS DunningLevel, 
    'Generated' AS InvoiceStatus,
    0 AS DaysOverdue
FROM 
    BaseInvoices bi
JOIN
    dbo.CustInvoiceJour cj ON bi.InvoiceNumber = cj.INVOICEID AND bi.DATAAREAID = cj.DATAAREAID

UNION ALL

-- 2. Invoice Posted and Sent
SELECT 
    bi.InvoiceNumber AS InvoiceNumber,
    'Invoice Posted and Sent' AS ActivityName,
    bi.InvoiceDate AS EventTime,
    bi.CollectorAssigned,
    bi.InvoiceAmount,
    bi.CustomerName,
    bi.CustomerSegment,
    bi.PaymentDueDate,
    0 AS DunningLevel,
    'Posted' AS InvoiceStatus,
    0 AS DaysOverdue
FROM 
    BaseInvoices bi

UNION ALL

-- 3. Payment Due Date Passed
SELECT
    bi.InvoiceNumber AS InvoiceNumber,
    'Payment Due Date Passed' AS ActivityName,
    bi.PaymentDueDate AS EventTime, -- The event happens on the due date
    bi.CollectorAssigned,
    bi.InvoiceAmount,
    bi.CustomerName,
    bi.CustomerSegment,
    bi.PaymentDueDate,
    0 AS DunningLevel,
    'Overdue' AS InvoiceStatus,
    DATEDIFF(day, bi.PaymentDueDate, GETUTCDATE()) AS DaysOverdue
FROM
    BaseInvoices bi
JOIN 
    dbo.CustTrans ct ON bi.InvoiceNumber = ct.INVOICE AND bi.DATAAREAID = ct.DATAAREAID
WHERE
    bi.PaymentDueDate < GETUTCDATE()
    AND ct.CLOSED = '1900-01-01 00:00:00.000' -- Logic to find open/unsettled transactions

UNION ALL

-- 4. Dunning Letter Generated
SELECT 
    clj.INVOICEID AS InvoiceNumber,
    'Dunning Letter Generated' AS ActivityName,
    clj.CREATEDDATETIME AS EventTime,
    bi.CollectorAssigned,
    bi.InvoiceAmount,
    bi.CustomerName,
    bi.CustomerSegment,
    bi.PaymentDueDate,
    clj.COLLECTIONLETTERCODE AS DunningLevel,
    'In Dunning' AS InvoiceStatus,
    DATEDIFF(day, bi.PaymentDueDate, clj.CREATEDDATETIME) AS DaysOverdue
FROM 
    dbo.CustCollectionLetterJour clj
JOIN
    BaseInvoices bi ON clj.INVOICEID = bi.InvoiceNumber AND clj.DATAAREAID = bi.DATAAREAID

UNION ALL

-- 5. Collection Activity Logged
-- This assumes smmActivities are used and linked to the customer.
-- Linking directly to an invoice can be difficult.
SELECT 
    bi.InvoiceNumber AS InvoiceNumber,
    'Collection Activity Logged' AS ActivityName,
    sa.CREATEDDATETIME AS EventTime,
    bi.CollectorAssigned,
    bi.InvoiceAmount,
    bi.CustomerName,
    bi.CustomerSegment,
    bi.PaymentDueDate,
    NULL AS DunningLevel,
    'In Collections' AS InvoiceStatus,
    DATEDIFF(day, bi.PaymentDueDate, sa.CREATEDDATETIME) AS DaysOverdue
FROM 
    dbo.smmActivities sa
JOIN
    dbo.CustTable ct ON sa.PARTY = ct.PARTY
JOIN
    BaseInvoices bi ON ct.ACCOUNTNUM = (SELECT TOP 1 INVOICECUST FROM dbo.CustInvoiceJour WHERE INVOICEID = bi.InvoiceNumber AND DATAAREAID = bi.DATAAREAID) AND ct.DATAAREAID = bi.DATAAREAID
WHERE
    sa.DATAAREAID = '{CompanyCode}' AND sa.CREATEDDATETIME > bi.InvoiceDate

UNION ALL

-- 6. Payment Promise Created
SELECT 
    bi.InvoiceNumber,
    'Payment Promise Created' AS ActivityName,
    cpp.CREATEDDATETIME AS EventTime,
    bi.CollectorAssigned,
    bi.InvoiceAmount,
    bi.CustomerName,
    bi.CustomerSegment,
    bi.PaymentDueDate,
    NULL AS DunningLevel,
    'Payment Promised' AS InvoiceStatus,
    DATEDIFF(day, bi.PaymentDueDate, cpp.CREATEDDATETIME) AS DaysOverdue
FROM 
    dbo.CustPromisedPayment cpp
JOIN 
    dbo.CustTrans ct ON cpp.TRANSACTIONREFRECID = ct.RECID AND cpp.DATAAREAID = ct.DATAAREAID
JOIN
    BaseInvoices bi ON ct.INVOICE = bi.InvoiceNumber AND ct.DATAAREAID = bi.DATAAREAID

UNION ALL

-- 7. Dispute Registered
SELECT 
    bi.InvoiceNumber,
    'Dispute Registered' AS ActivityName,
    cd.CREATEDDATETIME AS EventTime,
    bi.CollectorAssigned,
    bi.InvoiceAmount,
    bi.CustomerName,
    bi.CustomerSegment,
    bi.PaymentDueDate,
    NULL AS DunningLevel,
    'Disputed' AS InvoiceStatus,
    DATEDIFF(day, bi.PaymentDueDate, cd.CREATEDDATETIME) AS DaysOverdue
FROM 
    dbo.CustDispute cd
JOIN 
    dbo.CustTrans ct ON cd.CUSTTRANSRECID = ct.RECID AND cd.DATAAREAID = ct.DATAAREAID
JOIN
    BaseInvoices bi ON ct.INVOICE = bi.InvoiceNumber AND ct.DATAAREAID = bi.DATAAREAID
WHERE
    cd.STATUS = 1 -- Assuming 1 means opened/registered

UNION ALL

-- 8. Dispute Resolved
SELECT 
    bi.InvoiceNumber,
    'Dispute Resolved' AS ActivityName,
    cd.MODIFIEDDATETIME AS EventTime,
    bi.CollectorAssigned,
    bi.InvoiceAmount,
    bi.CustomerName,
    bi.CustomerSegment,
    bi.PaymentDueDate,
    NULL AS DunningLevel,
    'Posted' AS InvoiceStatus, -- Status returns to normal after resolution
    DATEDIFF(day, bi.PaymentDueDate, cd.MODIFIEDDATETIME) AS DaysOverdue
FROM 
    dbo.CustDispute cd
JOIN 
    dbo.CustTrans ct ON cd.CUSTTRANSRECID = ct.RECID AND cd.DATAAREAID = ct.DATAAREAID
JOIN
    BaseInvoices bi ON ct.INVOICE = bi.InvoiceNumber AND ct.DATAAREAID = bi.DATAAREAID
WHERE
    cd.STATUS = 2 -- Assuming 2 means closed/resolved

UNION ALL

-- 9. Payment Received (Journal Created, not yet posted)
-- This can be difficult to capture accurately and link to a specific invoice before settlement.
-- This is an approximation based on journal creation.
SELECT 
    bi.InvoiceNumber,
    'Payment Received' AS ActivityName,
    cpjl.CREATEDDATETIME AS EventTime,
    bi.CollectorAssigned,
    bi.InvoiceAmount,
    bi.CustomerName,
    bi.CustomerSegment,
    bi.PaymentDueDate,
    NULL AS DunningLevel,
    'Payment Pending' AS InvoiceStatus,
    DATEDIFF(day, bi.PaymentDueDate, cpjl.CREATEDDATETIME) AS DaysOverdue
FROM 
    dbo.CustomerPaymentJournalLineEntity cpjl
JOIN
    BaseInvoices bi ON cpjl.AccountDisplayValue = (SELECT TOP 1 INVOICECUST FROM dbo.CustInvoiceJour WHERE INVOICEID = bi.InvoiceNumber AND DATAAREAID = bi.DATAAREAID) AND cpjl.Company = bi.DATAAREAID
WHERE
    cpjl.CREATEDDATETIME >= bi.InvoiceDate

UNION ALL

-- 10. Payment Posted (Settlement Transaction)
-- Captures each partial or full payment application
SELECT 
    bi.InvoiceNumber,
    'Payment Posted' AS ActivityName,
    cs.TRANSDATE AS EventTime,
    bi.CollectorAssigned,
    bi.InvoiceAmount,
    bi.CustomerName,
    bi.CustomerSegment,
    bi.PaymentDueDate,
    NULL AS DunningLevel,
    'Partially Paid' AS InvoiceStatus,
    DATEDIFF(day, bi.PaymentDueDate, cs.TRANSDATE) AS DaysOverdue
FROM 
    dbo.CustSettlement cs
JOIN 
    dbo.CustTrans ct ON cs.TRANSRECID = ct.RECID AND cs.DATAAREAID = ct.DATAAREAID
JOIN
    BaseInvoices bi ON ct.INVOICE = bi.InvoiceNumber AND ct.DATAAREAID = bi.DATAAREAID
WHERE 
    cs.SETTLEAMOUNTCUR > 0

UNION ALL

-- 11. Invoice Settled
SELECT 
    bi.InvoiceNumber,
    'Invoice Settled' AS ActivityName,
    ct.CLOSEDDATE AS EventTime,
    bi.CollectorAssigned,
    bi.InvoiceAmount,
    bi.CustomerName,
    bi.CustomerSegment,
    bi.PaymentDueDate,
    NULL AS DunningLevel,
    'Settled' AS InvoiceStatus,
    DATEDIFF(day, bi.PaymentDueDate, ct.CLOSEDDATE) AS DaysOverdue
FROM 
    dbo.CustTrans ct
JOIN
    BaseInvoices bi ON ct.INVOICE = bi.InvoiceNumber AND ct.DATAAREAID = bi.DATAAREAID
WHERE 
    ct.CLOSEDDATE <> '1900-01-01 00:00:00.000'
    AND ct.TRANSTYPE = 11 -- Enum for Sales Invoice

UNION ALL

-- 12. Invoice Written Off
SELECT
    bi.InvoiceNumber,
    'Invoice Written Off' AS ActivityName,
    ct.TRANSDATE AS EventTime, -- The date of the write-off transaction
    bi.CollectorAssigned,
    bi.InvoiceAmount,
    bi.CustomerName,
    bi.CustomerSegment,
    bi.PaymentDueDate,
    NULL AS DunningLevel,
    'Written Off' AS InvoiceStatus,
    DATEDIFF(day, bi.PaymentDueDate, ct.TRANSDATE) AS DaysOverdue
FROM
    dbo.CustTrans ct
JOIN
    BaseInvoices bi ON ct.INVOICE = bi.InvoiceNumber AND ct.DATAAREAID = bi.DATAAREAID
WHERE 
    ct.TRANSTYPE = 19; -- Enum for Write-off. This may vary based on configuration.

ステップ

前提条件と環境を準備する：Python 3.8以降がインストールされていることを確認します。pip install pandas requests msalを実行して必要なライブラリをインストールします。Dynamics 365環境へのアクセス権を持つサービスプリンシパルの資格情報も必要です。
Azure ADにアプリケーションを登録する：Azure Active Directoryポータルを開きます。新しいアプリケーションを登録して、クライアントIDとテナントIDを取得します。アプリケーションの「証明書とシークレット」セクションで新しいクライアントシークレットを作成します。クライアントID、テナントID、クライアントシークレットは安全に保管してください。
API権限を付与する：Azure ADで登録したアプリケーションの「APIのアクセス許可」設定を開き、アクセス許可を追加します。Dynamics 365に対応する「Dynamics ERP」などの項目を選択し、「user_impersonation」委任アクセス許可を付与します。組織の管理者の同意を付与してください。
Dynamics 365ユーザーを作成する：Dynamics 365 Finance and Operationsに専用のアプリケーションユーザーを作成します。このユーザーをAzure ADアプリケーションのクライアントIDに関連付けます。CustInvoiceJour、CustCollectionLetterJour、CustSettlements、smmActivitiesなど、必要なすべてのデータエンティティへの読み取り権限を持つセキュリティロールを割り当てます。
Pythonスクリプトを設定する：提供されたPythonスクリプトを、たとえばextract_d365_collections.pyというファイルにコピーします。スクリプト先頭のプレースホルダー変数に、D365環境URL、テナントID、クライアントID、クライアントシークレット、既定の会社（dataAreaId）を入力します。
抽出パラメーターを設定する：スクリプトのstart_dateとend_date変数を変更し、データ抽出の期間を指定します。初期分析には3～6か月を推奨します。
スクリプトを実行する：ターミナルでpython extract_d365_collections.pyを実行します。スクリプトが認証を行い、12のアクティビティそれぞれのODataエンドポイントにクエリを実行し、APIのページネーションを自動的に処理します。
各アクティビティのデータを取得する：スクリプトは、請求書の作成、計上、督促、支払いなどの主要イベントについて、順番にAPIを呼び出します。各クエリは特定のデータエンティティを対象とし、パフォーマンスを高めるため必要なフィールドだけを選択します。
データを変換して結合する：スクリプトはpandasライブラリを使い、各API呼び出しのJSONレスポンスを処理します。データを構造化されたテーブルに変換し、列名を統一したうえで、すべてのアクティビティのデータを1つのイベントログに結合します。
派生イベントを計算する：「支払期日超過」アクティビティは、システムに直接記録されるイベントではありません。スクリプトは指定期間内の延滞請求書を反復処理し、それぞれに対応する行を生成します。
イベントログをエクスポートする：すべてのデータの処理と結合が完了すると、スクリプトは最終イベントログをd365_collections_event_log.csvというCSVファイルとして同じディレクトリに保存します。このファイルは整形済みで、プロセスマイニングツールにアップロードできます。

設定

APIエンドポイントURL：Dynamics 365 Finance and Operations環境のベースURLです。https://[your-environment-name].operations.dynamics.com形式で指定します。
認証資格情報：スクリプトには、Azure Active Directoryでアプリケーションを登録して取得したテナントID、クライアントID、クライアントシークレットが必要です。このアプリケーションにはDynamics 365 APIへのアクセス権を付与してください。
会社フィルター（dataAreaId）：Dynamics 365は複数会社に対応したシステムです。スクリプトではdataAreaIdフィルターを使って特定の会社を検索します。default_company変数に正しい法人（例：「USMF」）を設定してください。
日付範囲：start_dateとend_dateパラメーターで抽出期間を指定します。データ量を抑え、抽出を適切な時間内に完了するため、まずは直近3～6か月を指定することを推奨します。フィルターは主に請求書の作成日に適用します。
パフォーマンスに関する考慮事項：非常に大規模なデータセットをOData API経由で抽出すると、時間がかかる場合があり、MicrosoftによるAPIスロットリングの対象となることもあります。パフォーマンスに問題がある場合は、日付範囲を短くするか、利用の少ない時間帯に実行してください。
前提条件：pandas、requests、msalライブラリを備えたPython 3.8以降の環境が必要です。関連するDynamics 365ユーザーには、財務、販売、債権回収管理モジュール、特にスクリプトで指定されたエンティティへの読み取りアクセス権が必要です。

a サンプルクエリ python

import requests
import pandas as pd
import msal
import json
from datetime import datetime, timedelta

class=class="hl-string">"hl-comment"># --- Configuration --- 
D365_HOST = class="hl-string">"https://[your-d365-environment-url].operations.dynamics.com"
TENANT_ID = class="hl-string">"[Your Tenant ID]"
CLIENT_ID = class="hl-string">"[Your Client ID]"
CLIENT_SECRET = class="hl-string">"[Your Client Secret]"

class=class="hl-string">"hl-comment"># Date range for the extraction
start_date = class="hl-string">"2023-01-01"
end_date = class="hl-string">"2023-06-30"
default_company = class="hl-string">"[Your Company ID, e.g., USMF]"

class=class="hl-string">"hl-comment"># MSAL configuration
authority = fclass="hl-string">"https://login.microsoftonline.com/{TENANT_ID}"
scope = [fclass="hl-string">"{D365_HOST}/.default"]

class=class="hl-string">"hl-comment"># --- Authentication --- 
app = msal.ConfidentialClientApplication(CLIENT_ID, authority=authority, client_credential=CLIENT_SECRET)
result = app.acquire_token_silent(scope, account=None)

if not result:
    result = app.acquire_token_for_client(scopes=scope)

if class="hl-string">"access_token" not in result:
    raise Exception(class="hl-string">"Could not obtain access token: " + result.get(class="hl-string">"error_description"))

access_token = result[class="hl-string">'access_token']
headers = {
    class="hl-string">'Authorization': class="hl-string">'Bearer ' + access_token,
    class="hl-string">'Content-Type': class="hl-string">'application/json',
    class="hl-string">'Accept': class="hl-string">'application/json'
}

class=class="hl-string">"hl-comment"># --- Data Fetching Function --- 
def get_odata_data(entity_url):
    all_records = []
    url = entity_url
    while url:
        try:
            response = requests.get(url, headers=headers, params={class="hl-string">'cross-company': class="hl-string">'true'})
            response.raise_for_status() class=class="hl-string">"hl-comment"># Raises an HTTPError for bad responses (4xx or 5xx)
            data = response.json()
            all_records.extend(data.get(class="hl-string">'value', []))
            url = data.get(class="hl-string">'@odata.nextLink')
        except requests.exceptions.HTTPError as err:
            print(fclass="hl-string">"HTTP Error fetching data: {err}")
            print(fclass="hl-string">"Response content: {err.response.text}")
            break
        except json.JSONDecodeError:
            print(fclass="hl-string">"Failed to decode JSON from response: {response.text}")
            break
    return all_records

class=class="hl-string">"hl-comment"># --- Main Extraction Logic --- 
all_events = []

print(class="hl-string">"1. Extracting 'Invoice Generated' and 'Invoice Posted'...")
invoice_entity_url = fclass="hl-string">"{D365_HOST}/data/CustInvoiceJours?$filter=dataAreaId eq '{default_company}' and InvoiceDate ge {start_date}T00:00:00Z and InvoiceDate le {end_date}T23:59:59Z&$select=InvoiceNumber,InvoiceDate,createdDateTime,DueDate,InvoiceAmount,SalesOrderNumber,InvoiceCustomerAccountNumber,CustomerName,dataAreaId"
invoices = get_odata_data(invoice_entity_url)
if invoices:
    df_invoices = pd.DataFrame(invoices)
    df_invoices[class="hl-string">'ActivityName'] = class="hl-string">'Invoice Generated'
    df_invoices[class="hl-string">'EventTime'] = pd.to_datetime(df_invoices[class="hl-string">'createdDateTime']).dt.tz_localize(None)
    df_invoices.rename(columns={class="hl-string">'InvoiceNumber': class="hl-string">'InvoiceNumber', class="hl-string">'InvoiceAmount': class="hl-string">'InvoiceAmount', class="hl-string">'CustomerName': class="hl-string">'CustomerName', class="hl-string">'DueDate': class="hl-string">'PaymentDueDate'}, inplace=True)
    all_events.append(df_invoices[[class="hl-string">'InvoiceNumber', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'InvoiceAmount', class="hl-string">'CustomerName', class="hl-string">'PaymentDueDate']])

    df_posted = df_invoices.copy()
    df_posted[class="hl-string">'ActivityName'] = class="hl-string">'Invoice Posted and Sent'
    df_posted[class="hl-string">'EventTime'] = pd.to_datetime(df_posted[class="hl-string">'InvoiceDate']).dt.tz_localize(None)
    all_events.append(df_posted[[class="hl-string">'InvoiceNumber', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'InvoiceAmount', class="hl-string">'CustomerName', class="hl-string">'PaymentDueDate']])

    print(class="hl-string">"2. Calculating 'Payment Due Date Passed'...")
    df_due_passed = df_invoices[pd.to_datetime(df_invoices[class="hl-string">'PaymentDueDate']).dt.date < datetime.now().date()].copy()
    df_due_passed[class="hl-string">'ActivityName'] = class="hl-string">'Payment Due Date Passed'
    df_due_passed[class="hl-string">'EventTime'] = pd.to_datetime(df_due_passed[class="hl-string">'PaymentDueDate']) + timedelta(days=1)
    all_events.append(df_due_passed[[class="hl-string">'InvoiceNumber', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'InvoiceAmount', class="hl-string">'CustomerName', class="hl-string">'PaymentDueDate']])

print(class="hl-string">"3. Extracting 'Dunning Letter Generated'...")
dunning_entity_url = fclass="hl-string">"{D365_HOST}/data/CustCollectionLetterJours?$filter=dataAreaId eq '{default_company}' and CollectionLetterDate ge {start_date}T00:00:00Z and CollectionLetterDate le {end_date}T23:59:59Z&$select=InvoiceNumber,CollectionLetterCode,CollectionLetterDate"
dunning_letters = get_odata_data(dunning_entity_url)
if dunning_letters:
    df_dunning = pd.DataFrame(dunning_letters)
    df_dunning[class="hl-string">'ActivityName'] = class="hl-string">'Dunning Letter Generated'
    df_dunning[class="hl-string">'EventTime'] = pd.to_datetime(df_dunning[class="hl-string">'CollectionLetterDate']).dt.tz_localize(None)
    df_dunning.rename(columns={class="hl-string">'InvoiceNumber': class="hl-string">'InvoiceNumber', class="hl-string">'CollectionLetterCode': class="hl-string">'DunningLevel'}, inplace=True)
    all_events.append(df_dunning[[class="hl-string">'InvoiceNumber', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'DunningLevel']])

print(class="hl-string">"4. Extracting 'Payment Received' and 'Payment Posted'...")
settlements_entity_url = f"{D365_HOST}/data/CustSettlements?$filter=dataAreaId eq class="hl-string">'{default_company}' and TransDate ge {start_date}T00:00:00Z and TransDate le {end_date}T23:59:59Z&$select=OffsetRecId,TransDate,createdDateTime,SettlementAmountCur
&expand=CustInvoiceJour($select=InvoiceNumber)"
settlements = get_odata_data(settlements_entity_url)
if settlements:
    class=class="hl-string">"hl-comment"># Flatten the expanded data
    flat_settlements = []
    for s in settlements:
        if s.get(class="hl-string">'CustInvoiceJour'):
            s[class="hl-string">'InvoiceNumber'] = s[class="hl-string">'CustInvoiceJour'][class="hl-string">'InvoiceNumber']
            flat_settlements.append(s)

    df_settlements = pd.DataFrame(flat_settlements)
    df_received = df_settlements.copy()
    df_received[class="hl-string">'ActivityName'] = class="hl-string">'Payment Received'
    df_received[class="hl-string">'EventTime'] = pd.to_datetime(df_received[class="hl-string">'createdDateTime']).dt.tz_localize(None)
    all_events.append(df_received[[class="hl-string">'InvoiceNumber', class="hl-string">'ActivityName', class="hl-string">'EventTime']])
    
    df_posted_payment = df_settlements.copy()
    df_posted_payment[class="hl-string">'ActivityName'] = class="hl-string">'Payment Posted'
    df_posted_payment[class="hl-string">'EventTime'] = pd.to_datetime(df_posted_payment[class="hl-string">'TransDate']).dt.tz_localize(None)
    all_events.append(df_posted_payment[[class="hl-string">'InvoiceNumber', class="hl-string">'ActivityName', class="hl-string">'EventTime']])

class=class="hl-string">"hl-comment"># Note: Other activities like Disputes, Promises, Write-offs often involve custom entities or status fields.
class=class="hl-string">"hl-comment"># The following are conceptual examples assuming certain fields exist.
class=class="hl-string">"hl-comment"># You MUST adapt these to your specific D365 configuration.

print(class="hl-string">"5. Extracting 'Dispute Registered' and 'Dispute Resolved' (Conceptual)... ")
class=class="hl-string">"hl-comment"># Assuming a status field class="hl-string">'CollectionStatus' on the invoice indicates a dispute.
class=class="hl-string">"hl-comment"># This would ideally be sourced from an audit trail if available. This example assumes a snapshot.
dispute_entity_url = fclass="hl-string">"{D365_HOST}/data/CustInvoiceJours?$filter=dataAreaId eq '{default_company}' and (CollectionStatus eq 'Disputed' or CollectionStatus eq 'Resolved') and modifiedDateTime ge {start_date}T00:00:00Z&$select=InvoiceNumber,CollectionStatus,modifiedDateTime"
disputes = get_odata_data(dispute_entity_url)
if disputes:
    df_disputes = pd.DataFrame(disputes)
    df_disputes[class="hl-string">'ActivityName'] = df_disputes[class="hl-string">'CollectionStatus'].apply(lambda x: class="hl-string">'Dispute Registered' if x == class="hl-string">'Disputed' else class="hl-string">'Dispute Resolved')
    df_disputes[class="hl-string">'EventTime'] = pd.to_datetime(df_disputes[class="hl-string">'modifiedDateTime']).dt.tz_localize(None)
    all_events.append(df_disputes[[class="hl-string">'InvoiceNumber', class="hl-string">'ActivityName', class="hl-string">'EventTime']])

print(class="hl-string">"6. Extracting 'Payment Promise Created' (Conceptual)... ")
promise_entity_url = fclass="hl-string">"{D365_HOST}/data/CustPromisedPayments?$filter=dataAreaId eq '{default_company}' and createdDateTime ge {start_date}T00:00:00Z&$select=Invoice,createdDateTime,PromisedDate,PromisedAmount&$expand=CustInvoiceJour($select=InvoiceNumber)"
promises = get_odata_data(promise_entity_url)
if promises:
    flat_promises = []
    for p in promises:
        if p.get(class="hl-string">'CustInvoiceJour'):
            p[class="hl-string">'InvoiceNumber'] = p[class="hl-string">'CustInvoiceJour'][class="hl-string">'InvoiceNumber']
            flat_promises.append(p)
    df_promises = pd.DataFrame(flat_promises)
    df_promises[class="hl-string">'ActivityName'] = class="hl-string">'Payment Promise Created'
    df_promises[class="hl-string">'EventTime'] = pd.to_datetime(df_promises[class="hl-string">'createdDateTime']).dt.tz_localize(None)
    all_events.append(df_promises[[class="hl-string">'InvoiceNumber', class="hl-string">'ActivityName', class="hl-string">'EventTime']])
    
print(class="hl-string">"7. Extracting 'Collection Activity Logged' (Conceptual)... ")
class=class="hl-string">"hl-comment"># Linking activities to invoices can be indirect, often through the customer account.
activity_entity_url = fclass="hl-string">"{D365_HOST}/data/smmActivities?$filter=dataAreaId eq '{default_company}' and StartDateTime ge {start_date}T00:00:00Z and Purpose eq '[Your Collection Activity Purpose]'&$select=ActivityNumber,ParentRecordEntityName,ParentRecordRecId,StartDateTime,ResponsibleWorkerName&$expand=CustTable($select=AccountNumber)"
activities = get_odata_data(activity_entity_url)
class=class="hl-string">"hl-comment"># This section requires custom logic to map customer-level activities to open invoices at that time.
class=class="hl-string">"hl-comment"># A simplified approach is omitted here due to its complexity.

print(class="hl-string">"8. Identifying 'Invoice Settled' (Conceptual)... ")
settled_entity_url = fclass="hl-string">"{D365_HOST}/data/CustInvoiceJours?$filter=dataAreaId eq '{default_company}' and Status eq 'Paid' and LastSettlementDate ge {start_date}T00:00:00Z&$select=InvoiceNumber,LastSettlementDate"
settled_invoices = get_odata_data(settled_entity_url)
if settled_invoices:
    df_settled = pd.DataFrame(settled_invoices)
    df_settled[class="hl-string">'ActivityName'] = class="hl-string">'Invoice Settled'
    df_settled[class="hl-string">'EventTime'] = pd.to_datetime(df_settled[class="hl-string">'LastSettlementDate']).dt.tz_localize(None)
    all_events.append(df_settled[[class="hl-string">'InvoiceNumber', class="hl-string">'ActivityName', class="hl-string">'EventTime']])

print(class="hl-string">"9. Identifying 'Invoice Written Off' (Conceptual)... ")
class=class="hl-string">"hl-comment"># This is identified by a specific type of transaction in CustTrans.
writeoff_entity_url = fclass="hl-string">"{D365_HOST}/data/CustTrans?$filter=dataAreaId eq '{default_company}' and TransType eq 'WriteOff' and TransDate ge {start_date}T00:00:00Z&$select=Invoice,TransDate,Txt"
writeoffs = get_odata_data(writeoff_entity_url)
if writeoffs:
    df_writeoffs = pd.DataFrame(writeoffs)
    df_writeoffs.rename(columns={class="hl-string">'Invoice': class="hl-string">'InvoiceNumber'}, inplace=True)
    df_writeoffs[class="hl-string">'ActivityName'] = class="hl-string">'Invoice Written Off'
    df_writeoffs[class="hl-string">'EventTime'] = pd.to_datetime(df_writeoffs[class="hl-string">'TransDate']).dt.tz_localize(None)
    all_events.append(df_writeoffs[[class="hl-string">'InvoiceNumber', class="hl-string">'ActivityName', class="hl-string">'EventTime']])

class=class="hl-string">"hl-comment"># --- Final Processing --- 
if all_events:
    print(class="hl-string">"Combining all events...")
    final_df = pd.concat(all_events, ignore_index=True)
    final_df.sort_values(by=[class="hl-string">'InvoiceNumber', class="hl-string">'EventTime'], inplace=True)
    
    class=class="hl-string">"hl-comment"># Fill forward attributes for a complete log
    attributes_to_fill = [class="hl-string">'InvoiceAmount', class="hl-string">'CustomerName', class="hl-string">'PaymentDueDate', class="hl-string">'DunningLevel']
    for attr in attributes_to_fill:
        if attr not in final_df.columns:
            final_df[attr] = None
    
    final_df[attributes_to_fill] = final_df.groupby(class="hl-string">'InvoiceNumber')[attributes_to_fill].fillna(method=class="hl-string">'ffill').fillna(method=class="hl-string">'bfill')
    
    final_df = final_df.dropna(subset=[class="hl-string">'InvoiceNumber', class="hl-string">'ActivityName', class="hl-string">'EventTime'])
    
    output_filename = class="hl-string">'d365_collections_event_log.csv'
    final_df.to_csv(output_filename, index=False, date_format=class="hl-string">'%Y-%m-%dT%H:%M:%S.%f')
    print(fclass="hl-string">"Event log successfully created: {output_filename}")
else:
    print(class="hl-string">"No events were extracted. Please check your configuration and date range.")

準備はできましたか？

このテンプレートを使ってデータを適切に準備し、信用管理と債権回収業務に関する重要な情報を見つけ出してください。今日からプロセスを最適化し、キャッシュフローを早めましょう。

改善ガイドに戻るテンプレートをダウンロード

信用管理と債権回収を最適化し、今日から入金を早める

信用から入金までのプロセスを効率化し、サイクルタイムを30％短縮することで、キャッシュフローを改善します。

無料トライアルを開始

クレジットカードは不要です。数分で設定できます。

信用管理と債権回収のデータテンプレート

信用管理と債権回収のデータテンプレート

与信管理・債権回収の属性

与信管理・債権回収のアクティビティ

抽出ガイド

Bring Your Own Database（BYOD）による直接SQLクエリ

ステップ

設定

a サンプルクエリ sql

Dynamics 365 OData REST APIを使ったPythonスクリプト

ステップ

設定

a サンプルクエリ python

準備はできましたか？

信用管理と債権回収を最適化し、今日から入金を早める

信用管理と債権回収のデータテンプレート

信用管理と債権回収のデータテンプレート

与信管理・債権回収の属性

与信管理・債権回収のアクティビティ

抽出ガイド

Bring Your Own Database（BYOD）による直接SQLクエリ

ステップ

設定

a サンプルクエリ sql

Dynamics 365 OData REST APIを使ったPythonスクリプト

ステップ

設定

a サンプルクエリ python

準備はできましたか？

信用管理と債権回収を最適化し、今日から入金を早める

プライバシーを大切にしています