> 継続的なプロセス改善 > オーダー・トゥ・キャッシュ（請求・支払業務） > Microsoft Dynamics 365 > データテンプレート

オーダー・トゥ・キャッシュ（請求・支払業務）データテンプレート

Microsoft Dynamics 365

オーダー・トゥ・キャッシュ（請求・支払業務）属性 (18) オーダー・トゥ・キャッシュ（請求・支払業務）アクティビティ (12) 抽出ガイド (2)

オーダー・トゥ・キャッシュ（請求・支払業務）データテンプレート

このテンプレートは、オーダー・トゥ・キャッシュ（請求・支払業務）プロセスを分析するために必要な重要なデータポイントを収集するための明確なロードマップを提供します。イベントログに含めるべき推奨属性、追跡すべき主要アクティビティ、およびこの情報を抽出するための実用的なガイダンスが見つかります。これは、洞察に満ちたプロセスマイニングのためにデータを迅速に設定できるよう設計されています。

収集を推奨する項目
追跡すべき主要アクティビティ
Microsoft Dynamics 365向けデータ抽出ガイド

イベントログについて初めての方へ：プロセスマイニングのイベントログ作成方法.

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

オーダー・トゥ・キャッシュ（請求・支払業務）属性

これらは、包括的なオーダー・トゥ・キャッシュ（請求・支払業務）分析のためにイベントログに含めるべき推奨データフィールドです。

3 必須 6 推奨 9 任意

	名前	説明
	請求書番号 InvoiceNumber	各顧客請求書の一意の識別子であり、請求業務の主要なケース識別子として機能します。
説明請求書番号は、単一の請求書文書に関連するすべてのアクティビティをグループ化する中心的なキーです。これにより、生成から承認、顧客支払い、最終的なクローズまでの請求書ライフサイクル全体のエンドツーエンド分析が可能になります。これをケースIDとして使用することで、すべてのイベントログエントリが特定の請求書に対応し、各請求処理の綿密なバリアント分析、サイクルタイム計算、およびパフォーマンス監視を可能にします。その重要性この属性は、請求書のライフサイクル全体を追跡するために不可欠であり、各請求書文書のプロセス効率、ボトルネック、および逸脱の分析を可能にします。取得元これは通常、販売およびマーケティングモジュール内の、CustInvoiceJourテーブル（InvoiceIdフィールド）またはSalesInvoiceHeaderV2のようなデータエンティティを通じて公開されます。例 CIV-001254INV-2023-9876US-004321
	アクティビティ名 ActivityName	請求書ライフサイクル内の特定の時点で発生したビジネス活動またはイベントの名称。
説明この属性は、「請求書作成済み」、「請求書承認済み」、「顧客入金済み」といった、請求業務内の特定のステップまたはマイルストーンを記述します。これらのアクティビティの順序がプロセスフローを形成します。アクティビティの分析はプロセスマイニングの基本であり、プロセスモデルの発見、バリアントの特定、および異なるステップ間のパフォーマンス測定を可能にするためです。その重要性これはプロセス内のステップを定義し、プロセスマップの可視化、プロセスバリアントの分析、およびボトルネックや標準手順からの逸脱の特定を可能にします。取得元この属性は通常、複数のソースから派生します。たとえば、ステータス変更フィールド（例：DocumentState）、特定の日付フィールドへのデータ入力、またはMicrosoft Dynamics 365内のワークフロー履歴ログなどです。例請求書生成済み請求書承認済み顧客からの入金受領クレジットノート発行
	イベント日時 EventTime	特定のアクティビティまたはイベントが発生した正確なタイムスタンプです。
説明イベント時間、またはタイムスタンプとは、プロセスにおける各活動の正確な日付と時間を記録するものです。このデータは、時間ベースの全てのプロセスマイニング分析にとって不可欠です。活動間のサイクルタイムの計算、ケースの総期間の測定、時間経過によるプロセスパフォーマンスの理解に利用されます。正確で信頼性の高いタイムスタンプは、DSO（売掛金回収日数）や請求書発行時間といったKPIの基盤となります。その重要性これは、すべてのパフォーマンスおよび時間関連分析の基礎となる属性であり、プロセス効率を測定するためのサイクルタイム、期間、およびスループットの計算を可能にします。取得元タイムスタンプは、Dynamics 365内のさまざまなテーブルにある日付および時刻フィールドから取得されます。例えば、請求書生成のためのCustInvoiceJourテーブルのCreatedDateTimeや、特定のワークフロー履歴タイムスタンプなどです。例 2023-04-15T10:22:15Z2023-05-01T14:05:00Z2023-05-10T09:00:30Z
	担当ユーザー UserResponsible	特定のアクティビティの実行責任者であるユーザーまたは従業員。
説明この属性は、請求業務において特定のタスク（例：請求書の承認や現金の適用）を実行した個人を特定します。これは、作業負荷分析、パフォーマンス比較、および研修ニーズの特定にとって重要です。例えば、「請求部門アクティビティ負荷」ダッシュボードは、この属性を使用して作業が均等に分散されているか、または特定のユーザーがボトルネックになっているかを確認します。また、リソース配分と効率性を理解する上でも役立ちます。その重要性これにより、リソースレベルの分析が可能になり、ボトルネックの特定、個人またはチームのパフォーマンス測定、および請求部門全体での作業負荷分散の分析に役立ちます。取得元これは、ワークフロー履歴ログ（例：WorkflowTrackingStatusTable）または関連テーブルのOwnerやModifiedByのような所有者フィールドから取得できます。例 John SmithAlicia Bakerシステム管理者
	支払期日 PaymentDueDate	顧客が請求書を支払うべき期日。
説明支払期日は、請求書発行日と顧客の支払条件に基づいて計算される重要な日付フィールドです。支払いの適時性を測定するための基準となります。この属性は「支払条件遵守分析」ダッシュボードにとって不可欠であり、「期日内支払い率」や「売掛金回収日数」といったKPIを計算するためにも重要です。この日付と実際の支払い日付を比較することで、顧客の支払い行動と回収プロセスの有効性が明らかになります。その重要性これは、支払いパフォーマンスを測定するためのベンチマークです。期日内支払い率の計算や顧客支払条件の遵守状況の分析に不可欠です。取得元これは通常、CustInvoiceJourテーブルのDueDateのようなフィールドにあります。例 2023-05-152023-06-302023-07-01
	請求書ステータス InvoiceStatus	ライフサイクルにおける請求書の現在のステータス（例：未決済、支払い済み、キャンセル済み）。
説明この属性は、請求書が現在どのような状態にあるかのスナップショットを提供します。請求書がまだ支払いを待っているか、全額支払い済みか、延滞しているか、またはクレジットノートによってキャンセルされたかを示します。これは、未決済の請求書のみを分析するためのケースのフィルタリングや、クローズされた請求書の最終的な結果を確認するのに役立ちます。また、現在の作業負荷と売掛金の財務状況を理解する上でも役立ちます。その重要性請求書の現在の状態のクイックスナップショットを提供し、ケースのフィルタリングやさまざまなプロセスバリアントの結果を理解するのに役立ちます。取得元これは請求書の支払いステータスから導き出すことができます。多くの場合、関連するCustTransレコードの残高がゼロであるかをチェックすることで確認されます。単一の「ステータス」フィールドが常に存在するわけではありません。例オープン支払い済み期限超過キャンセル済み
	請求金額 InvoiceAmount	請求書の合計金額。
説明この属性は、請求書に記載された総支払額を表します。これは財務分析にとって重要な指標であり、金額に基づいて請求書をセグメント化することを可能にします。例えば、アナリストは高額な請求書に焦点を当てて、その支払い行動を理解したり、高額な請求書が承認に長い時間がかかるかどうかを特定したりできます。また、未決済請求書の総額およびDSO計算の基礎でもあります。その重要性これにより、財務的影響分析が可能になり、金額に基づいてプロセスをフィルタリングおよびセグメント化することで、高額な請求書を優先し、その特定のプロセス行動を理解することができます。取得元 CustInvoiceJourテーブル内の通常InvoiceAmountのようなフィールドに見られます。関連する取引テーブルでも利用可能です。例 5430.5012500.00750.25
	部署 Department	ユーザーまたはアクティビティに関連付けられた事業部門。
説明この属性は、アクティビティまたはユーザーを特定の組織部門（例：経理部や営業部など）に割り当てます。これにより、個々のユーザーレベルよりも高レベルでのプロセスパフォーマンスの視点を提供します。部門ごとに分析することで、部門間の引き継ぎの理解、チーム間の効率性の比較、そして「請求部門アクティビティ負荷」ダッシュボードで必要とされる部門レベルのボトルネックの特定に役立ちます。その重要性組織レベルでのパフォーマンス分析を可能にし、異なるチーム間の効率を比較し、部門間の引き継ぎがプロセスにどのように影響するかを理解します。取得元これは通常、請求書トランザクションの直接的なフィールドではありません。これは、UserResponsible IDと部門情報を含む従業員またはユーザーディレクトリを結合することで導き出されます。例債権財務請求業務
	顧客名 CustomerName	請求書が発行された顧客の名前。
説明顧客名は、請求対象の企業または個人にとって人間が読める識別子を提供します。プロセスマイニング分析では、これにより顧客ごとに請求プロセスをセグメント化できます。どの顧客が常に期日内に支払いを行うか、どの顧客が頻繁に遅延するか、または特定の顧客グループが独自のプロセスバリエーションや遅延を経験するかどうかが明らかになります。これは、顧客の支払い行動および売掛金回収日数（DSO）分析に関連するダッシュボードにとって重要です。その重要性これにより、顧客ごとにプロセス分析をセグメント化でき、顧客固有の行動、支払いパターン、またはプロセス上の問題を特定するのに役立ちます。取得元この情報は、顧客口座番号に基づいて、請求書データと顧客マスターデータテーブル（通常はCustTable）を結合することで取得されます。例 Contoso Ltd.Fabrikam, Inc.ノースウィンドトレーダーズ
	`売上債権回転日数` DaysSalesOutstanding	請求書発行から顧客入金までの日数。
説明 DSO（Days Sales Outstanding、売掛金回収日数）は、企業が売上発生後に支払いを受け取るまでの平均日数を測定する主要な財務指標です。この計算された属性は、個々の請求書ごとにこの期間を算出します。「DSOトレンド分析」ダッシュボードおよび「DSO」KPIの主要な指標となります。DSOを分析することは、キャッシュフローの管理と信用・回収機能の効率評価に役立ちます。その重要性これは、企業キャッシュフローの健全性と回収プロセスの効率を測定するための重要なKPIです。収益がどれだけ迅速に現金に変換されるかを定量化します。取得元この属性はソースシステムにはありません。「請求書作成済み」アクティビティと「顧客入金」アクティビティ間の期間として計算されます。例 284592
	ソースシステム SourceSystem	データを抽出した元システム。
説明この属性は、プロセスデータの発生元を識別します。この文脈では、データがMicrosoft Dynamics 365から来ていることを指定します。これは、複数システム環境においてデータソースを区別し、データの来歴を明確にするために重要であり、データ検証とトラブルシューティングに役立ちます。その重要性これは、データソースに関する重要なコンテキストを提供し、データガバナンス、検証、および複数のエンタープライズシステムからデータを統合する際に不可欠です。取得元これは、データセットの発生源を示すために、データ抽出および変換プロセス中に加えられる静的値です。例 Microsoft Dynamics 365 FinanceD365 F&O
	最終データ更新 LastDataUpdate	このイベントのデータがソースシステムから最後に更新された日時を示すタイムスタンプ。
説明この属性は、Microsoft Dynamics 365からデータが最後に抽出または更新された日時を記録します。これは、分析対象データの鮮度を理解するために不可欠なメタデータフィールドです。これにより、アナリストやビジネスユーザーは、最新の情報を見ているかどうかを知ることができ、データ更新スケジュールを管理し、分析の信頼性を確保するために不可欠です。その重要性これにより、ユーザーはデータの鮮度を理解できます。これはデータガバナンス、ダッシュボードの更新管理、およびインサイトの適時性を信頼するために不可欠です。取得元この属性は、データ抽出、変換、ロード（ETL）プロセス中に生成され、データセットにスタンプされます。例 2023-06-20T05:00:00Z2023-06-21T05:00:00Z
	手動介入が必要 RequiresManualIntervention	現金消込時に支払いに手動での調整が必要だったかを示すフラグです。
説明このブール属性は、現金適用プロセス中に手動介入または修正が必要だった支払いにフラグを立てます。これは「現金適用不一致率」KPIにとって重要であり、支払い計上の正確性と自動化レベルを定量化するのに役立ちます。支払通知情報の不足や支払い不一致など、手動介入の理由を特定することで、ストレートスルー処理率を高めるプロセス改善につながります。その重要性この属性は、現金適用ステップにおけるプロセス上の摩擦や不正確さを特定するのに役立ち、これは自動化の改善と手動作業の削減にとって不可欠です。取得元この情報は、支払いを行ったユーザー（システムユーザーでない場合）または支払い照合中に使用された特定の理由コードから推測される可能性があります。Microsoft Dynamics 365のドキュメントを参照してください。例 truefalse
	手戻り IsRework	請求書プロセスで、複数回の承認などの手戻り作業が発生したかどうかを示すフラグです。
説明これは、手戻りが発生した請求書にフラグを立てる計算されたブール属性です。手戻りは、複数の「請求書承認済み」イベントまたは支払いの取り消しとして定義できます。この属性は、「請求書手戻り分析」ダッシュボードおよび「請求書手戻り率」KPIをサポートするために特別に設計されています。これらのケースを分離することで、アナリストは手戻りの根本原因を調査でき、これは、プロセス非効率性、データ品質の問題、またはトレーニングのギャップをしばしば示唆しています。その重要性このフラグは、反復的なまたは修正的なアクションを伴うケースを特定することで、プロセスの非効率性を直接的に定量化し、無駄と遅延の根本原因を特定するのに役立ちます。取得元この属性はソースシステムにはありません。ケース内の繰り返されるアクティビティや特定の手戻りパターンをチェックすることで、データ変換層で計算されます。例 truefalse
	支払条件 PaymentTerms	請求書支払いの合意された条件（例：Net 30、Net 60）。
説明支払条件は、顧客が請求書をいつ支払うべきかのルールを定義します。この属性は支払期日を計算するために使用され、支払行動を分析するための重要なディメンションです。「支払条件遵守分析」ダッシュボードは、この属性を使用して顧客と請求書をグループ化し、特定の支払条件がより効果的であるか、または遅延支払いの割合が高いかどうかを確認します。その重要性これは、請求書が特定の日付に期日を迎える理由の背景を提供し、特定の支払条件が遅延支払いと関連しているかどうかを確認するためのセグメント化分析を可能にします。取得元これは通常、顧客マスターレコードに保存されますが、請求書ヘッダーにコピーされます。CustInvoiceJourテーブルのPaymentまたはPaymTermIdフィールドを探してください。例支払条件：正味30日支払条件：正味60日受領時支払い
	期日内支払いか IsOnTimePayment	顧客からの支払いが期日までに受領されたかどうかを示すフラグです。
説明この計算されたブール属性は、「顧客入金」タイムスタンプと「支払期日」を比較します。これにより、各請求書が期日内に支払われたか、または遅延したかをフラグ付けします。これは「期日内支払い率」KPIを計算するための核となるコンポーネントであり、「支払条件遵守分析」ダッシュボードで頻繁に使用されます。支払いパフォーマンスに対する明確な二者択一の結果を提供し、分析とレポート作成を簡素化します。その重要性顧客の支払い条件順守状況を直接測定し、オンタイム支払い率KPIの基礎となり、回収効果の分析を簡素化します。取得元この属性はソースシステムにはありません。データ変換中に、支払い日付とPaymentDueDateを比較することで計算されます。例 truefalse
	販売オーダー番号 SalesOrderNumber	請求書の元となった販売オーダーの識別子。
説明販売オーダー番号は、請求業務を先行する販売プロセスにリンクします。この連携は、より広範なエンドツーエンドのオーダー・トゥ・キャッシュ分析にとって非常に価値があります。これにより、アナリストは、注文変更や出荷遅延など、販売および履行プロセスにおける問題が請求サイクルにどのように影響するかを調査できます。例えば、「複雑な販売オーダーからの請求書は支払いまでに時間がかかるのか？」といった疑問に答えるのに役立ちます。その重要性この属性は、請求業務を上流の販売プロセスに接続し、より包括的なエンドツーエンドのオーダー・トゥ・キャッシュ分析を可能にすることで、請求問題の根本原因を特定します。取得元請求書ヘッダーまたは明細詳細にあり、販売注文にリンクしています。CustInvoiceJourテーブルでSalesIdのようなフィールドを探してください。例 SO-009876SO-010234US-SO-00543
	通貨 Currency	請求金額の通貨コード（例: USD, EUR）。
説明この属性は、請求金額が建てられている通貨を指定します。これは、異なる通貨を扱う多国籍企業にとって不可欠です。このコンテキストがなければ、請求金額を集計したり比較したりすることは無意味になります。適切な通貨換算と、異なる地域間での正確な財務報告および分析を可能にします。その重要性これは、請求金額のような財務指標にとって不可欠なコンテキストを提供し、不正確な集計を防ぎ、多通貨環境での正確な分析を可能にします。取得元 CustInvoiceJourテーブル内の通常CurrencyCodeのようなフィールドに見られます。例 USDEURGBP

必須推奨任意

オーダー・トゥ・キャッシュ（請求・支払業務）アクティビティ

これらは、正確な`プロセス`ディスカバリと分析のために`イベントログ`に記録すべき主要な`プロセス``ステップ`と`マイルストーン`です。

7 推奨 5 任意

	アクティビティ	説明
	支払期日到達	請求書の支払期日が到来しても支払いが完全に適用されていない場合に発生する計算されたイベントです。この活動はシステム内のトランザクションには対応せず、既存のデータから導出されます。
その重要性このイベントは、期日内支払い率を分析し、延滞になりつつある請求書を特定するために不可欠です。回収活動や督促活動のトリガーポイントとして機能します。取得元これはイベントとしては記録されません。CustInvoiceJourテーブルのDueDateフィールドを使用して計算されます。イベントタイムスタンプは期日そのものです。取得タイムスタンプがCustInvoiceJour.DueDateフィールドの値であるイベントを作成します。イベントタイプ calculated
	請求書がクローズ済み	このアクティビティは、請求書の最終状態を示します。全額支払い済み、またはクレジットノートで決済されたため、残高がゼロになった状態です。これは直接的なトランザクションではなく、請求書の財務状況に基づいて推測される状態です。
その重要性このイベントは、単一の請求書に対するオーダー・トゥ・キャッシュサイクルの成功裏の完了を意味します。この状態に達するまでの時間は、プロセスの全体的な効率の主要な尺度となります。取得元 CustTransテーブル内の請求書トランザクションの残高がゼロであるかをチェックすることで推測されます。これは、請求金額とそれに対して相殺済みの合計金額を比較することで決定されます。取得 AmountCurがSettleAmountCurと等しいCustTransレコードから導出します。タイムスタンプは最終消込日です。イベントタイプ inferred
	請求書に現金適用	特定の請求書に対する顧客支払いの決済を表し、請求書の未決済残高を減らします。これはDynamics 365における明確なステップであり、支払いトランザクションを請求書トランザクションにリンクします。
その重要性これは、DSOを正確に計算し、現金適用チームの効率性を理解するための重要なマイルストーンです。支払いと請求額が完全に照合された時点を示します。取得元 CustSettlementテーブルに記録されます。このテーブルの決済日フィールドは、特定の支払いが特定の請求書トランザクションに適用された際のタイムスタンプを提供します。取得 CustSettlementテーブルのTransDateまたはCreatedDateTimeを使用します。イベントタイプ explicit
	請求書承認済み	内部審査プロセスの完了を示し、請求書が正式に承認された時点です。このイベントはDynamics 365ワークフローシステムによってログに記録され、請求書が顧客に送付される準備ができたことを意味します。
その重要性これは、承認サイクルタイムを測定するための重要なマイルストーンです。この段階での遅延は、顧客からの支払い受領までの全体的な時間を直接増加させる可能性があります。取得元 WorkflowTrackingStatusTableなどのワークフロー履歴テーブルに、特定の請求書ワークフローインスタンスの完了または承認ステップとして記録されます。取得ステータスが「承認済み」または「完了済み」であるワークフローイベントログを抽出します。イベントタイプ explicit
	請求書生成済み	システム内での売上請求書文書の作成と計上を表します。これはDynamics 365における明示的なトランザクションであり、法的文書を作成し、売掛金補助元帳に財務エントリを生成します。
その重要性これは、請求書における請求ライフサイクルの正式な開始です。売掛金回収日数（DSO）とプロセス全体の期間を追跡するための重要なイベントです。取得元 CustInvoiceJourテーブル内の転記済み売上請求書レコードの作成タイムスタンプからキャプチャされます。対応する財務取引は、転記時にGeneralJournalEntryおよびLedgerEntryテーブルに作成されます。取得計上された請求書には、CustInvoiceJourテーブルのCreatedDateTimeフィールドを使用します。イベントタイプ explicit
	顧客からの入金受領	このアクティビティは、顧客から受け取った支払いを記録するための仕訳帳エントリの作成を示します。現金が受領されたことを意味しますが、まだ特定の請求書に適用されていません。
その重要性これは、現金適用リードタイムを測定するための出発点です。お金の受領と未決済請求書への実際の照合を区別します。取得元顧客支払仕訳の作成または転記からキャプチャされます。これはLedgerJournalTransのようなテーブルに記録され、転記時にCustTransに顧客取引が作成されます。取得 LedgerJournalTableの顧客支払仕訳帳の計上タイムスタンプを使用します。イベントタイプ explicit
	顧客へ請求書送付済み	このアクティビティは、請求書が電子的または物理的に顧客に送信された瞬間を表します。Dynamics 365では、システムメール経由で送信された場合は明示的なイベントとして扱われ、特定の追跡が有効になっていない場合は、計上時に発生したと推測されます。
その重要性請求書送付プロセスの効率を測定します。承認から請求書送付までの遅延は、支払いサイクルを不必要に延長させます。取得元 D365のメール機能を使用している場合、SysOutgoingEmailTableのようなメールログから明示的にキャプチャできます。そうでない場合、CustInvoiceJourからの請求書転記時間と同じと推測されることがよくあります。取得利用可能な場合はメールログのタイムスタンプを使用します。それ以外の場合は、請求書計上のタイムスタンプを使用します。イベントタイプ inferred
	クレジットノート発行	クレジットノートまたはクレジットメモの作成を表し、通常は請求の誤りの修正、価格調整の付与、または返品された商品に対応するために使用されます。クレジットノートは本質的にマイナス請求書です。
その重要性頻繁なクレジットノートの発行は、注文履行または請求プロセスにおけるシステム的な問題を示唆している可能性があります。クレジットノートが発行される理由を分析することは、プロセス改善と収益漏洩の削減にとって重要です。取得元これは、CustInvoiceJourテーブルに負の金額を持つ新規計上請求書として記録される明示的なトランザクションです。参照フィールドを介して元の請求書にリンクされることがよくあります。取得負の合計金額を持つCustInvoiceJourのレコードを特定し、元の請求書にリンクします。イベントタイプ explicit
	承認のために請求書提出済み	このアクティビティは、作成された請求書が正式な承認ワークフローに提出されたことを示します。これは、顧客に請求書を送付する前に経営陣のレビューを必要とする統制を持つ組織で一般的です。これは、D365ワークフローエンジンにおける特定のステップとしてログに記録されます。
その重要性承認のための提出を追跡することで、請求書作成時間と承認待ち時間を区別できます。これは、内部審査および統制プロセスの効率性を分析する最初のステップです。取得元 WorkflowTrackingStatusTableのようなワークフロー履歴テーブルから、請求書ドキュメントに関連する提出イベントでフィルタリングすることによってキャプチャされます。取得ステータスが「提出済み」であるワークフローイベントログを抽出します。イベントタイプ explicit
	支払い取り消し	このアクティビティは、以前に計上された顧客支払いの取り消しを意味します。これは、不正確な計上、資金不足、またはその他の支払い不履行などのエラーが原因で発生します。
その重要性支払い取り消しは、運用上のエラーや顧客支払いに関する問題を浮き彫りにします。その頻度を分析することで、根本原因を特定し、現金適用プロセスの精度を向上させることができます。取得元総勘定元帳で取引の取り消しとしてキャプチャされます。取り消された仕訳はGeneralJournalEntryで、特定のフラグや元の取引との関係によって識別できます。取得取り消しフラグを持つ仕訳、または取り消された取引への参照を持つ仕訳を特定します。イベントタイプ explicit
	支払督促発行	顧客に対する延滞請求書に関する督促状または回収通知の送付を表します。Dynamics 365には、これらの連絡を生成およびログに記録する正式な督促プロセスがあります。
その重要性督促の追跡は、督促プロセスの有効性を評価するのに役立ちます。支払い受領までにいくつの督促が必要かを分析することができます。取得元これは、CustCollectionLetterJourテーブル内の回収通知仕訳帳の作成日からキャプチャされた明示的なイベントです。これは、延滞請求書トランザクションにリンクされています。取得 CustCollectionLetterJourテーブルの作成タイムスタンプを使用します。イベントタイプ explicit
	販売オーダー履行済み	このアクティビティは、販売オーダーの商品が出荷またはサービスが提供された時点を示し、請求プロセスが開始されます。通常、Microsoft Dynamics 365での納品書または出荷伝票の計上から推測され、これにより、関連する販売オーダー明細のステータスが変更されます。
その重要性このイベントは、請求書作成サイクルタイムを測定するための出発点となります。履行と請求書作成の間の遅延を理解することは、キャッシュフローに影響を与える可能性のある管理上のボトルネックを特定するのに役立ちます。取得元販売オーダーにリンクされた納品書仕訳帳エントリの作成日から推測されます。これには、請求書の基となる販売オーダーに関連するCustPackingSlipJourやCustPackingSlipTransといったテーブルが関与します。取得請求書に関連付けられた販売オーダーの最新の納品書計上日を特定します。イベントタイプ inferred

推奨任意

抽出ガイド

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

ステップ

データ管理ワークスペースに移動: Microsoft Dynamics 365 Finance and Operationsにログインします。検索バーを使用して「Data management（データ管理）」ワークスペースを検索し、移動します。ここは全てのデータインポートおよびエクスポート操作の中心ハブです。
新しいエクスポートプロジェクトの作成: 「Data management（データ管理）」ワークスペース内で、「Export（エクスポート）」タイルをクリックして新しいデータエクスポートプロジェクトを作成します。「ProcessMind_O2C_Billing_Export」のような意味のある名前と説明をプロジェクトに付けます。
ターゲットデータ形式の選択: プロジェクト設定で、「Target data format（ターゲットデータ形式）」を指定します。ほとんどのデータ変換ツールとの互換性のため、「CSV」を選択します。必要に応じてフォーマットオプションを設定し、一般的な区切り文字とテキスト修飾子を確実に設定してください。
必要なデータエンティティの追加: これは最も重要なステップです。必要な全ての活動をキャプチャするために、複数の標準データエンティティをプロジェクトに追加します。各エンティティについて、「Add entity（エンティティの追加）」をクリックし、「Query/Script」セクションに記載されているエンティティ名を検索します。プロジェクトに以下の各エンティティを追加してください: Sales invoice headers V2、Sales packing slip headers、Workflow tracking status table、CustPaymentJournalLineEntity、Customer settlement、Dunning history letters。
エンティティフィルターの適用: データを関連する範囲に限定するために、エンティティにフィルターを適用します。最低限、「Sales invoice headers V2」を「InvoiceDate」で特定の期間（例: 過去6ヶ月間）でフィルタリングします。また、分析したい特定の法人（会社）でフィルタリングします。
エクスポートジョブの実行: 全てのエンティティが追加され、フィルターが適用されたら、アクションペインの「Export（エクスポート）」ボタンをクリックします。システムはジョブパッケージを作成し、バックグラウンドでデータ抽出の処理を開始します。
データの監視とダウンロード: 「Job history（ジョブ履歴）」セクションでジョブの進行状況を監視できます。ジョブが正常に完了したら、エクスポートされたデータパッケージをダウンロードできます。パッケージは、各データエンティティごとに個別のCSVファイルを含むZIPファイルになります。
パッケージの解凍: ダウンロードしたZIPファイルのコンテンツをローカルフォルダーに抽出します。これで、各エンティティごとに複数のCSVファイルが手に入ります。
データの変換と結合: 生のファイルは単一のイベントログに変換する必要があります。Power Query、Python、またはデータベースのステージングエリアのようなデータ準備ツールを使用します。各ソースファイルについて、必要な列を作成します: InvoiceNumber（ケースID）、ActivityName（「Invoice Generated」のようなイベントを表すハードコードされた値）、EventTime（ソースファイルからの関連する日付フィールド）。InvoiceAmountやCustomerNameなどの他の属性もマッピングします。
全ての変換データの統合: ユニオンまたは追加操作を使用して、全てのソースファイルからの変換データを単一のテーブルに結合します。これにより、各行が請求書ライフサイクルにおける1つの活動を表す、最終的な統合イベントログが作成されます。
アップロードのための最終フォーマット: 最終的なCSVファイルに正しい列ヘッダー（InvoiceNumber、ActivityName、EventTimeなど）があり、EventTime列が一貫したタイムスタンプ形式（例: YYYY-MM-DD HH:MI:SS）であることを確認してください。このファイルはProcessMindへのアップロード準備が整いました。

設定

Data Entities: 抽出は標準的なD365データエンティティ群に依存しています。主要なエンティティには、Sales invoice headers V2（請求書およびクレジットノート用）、Sales packing slip headers（受注処理用）、CustPaymentJournalLineEntity（支払用）、Customer settlement（現金消込用）、Workflow tracking status table（承認用）が含まれます。
Export Format: データ変換ツールとの幅広い互換性を考慮し、推奨されるターゲットデータフォーマットはCSVです。
Date Range Filtering: 主要エンティティ、特にSales invoice headers V2のInvoiceDateフィールドには日付範囲フィルターを適用することが重要です。分析に十分なデータを提供しつつ、エクスポートを管理可能なサイズに保つため、3〜6ヶ月の範囲が推奨されます。
Company Filtering: データ関連性を確保し、エクスポートサイズを削減するために、分析対象の特定の法人または会社コードでエクスポートをフィルターする必要があります。
Data Staging and Transformation: Dynamics 365外での後処理ステップが必要です。エクスポートされたファイルは結合され、単一のイベントログ形式に整形される必要があります。これには通常、Power BI（Power Query）、Python、SQLなどのツールが使用されます。
Prerequisites: エクスポートを実行するユーザーは、Dynamics 365内で適切なセキュリティロール（通常、Data managementワークスペースへの権限および必要なデータエンティティへのアクセス権を含むロール）が割り当てられている必要があります。

a クエリ例 config

The following configuration outlines the data entities and field mappings required for the export project within the Dynamics 365 Data Management Framework. A post-processing script or tool is required to union these outputs into a single event log.

**1. Activity: Sales Order Fulfilled**
*   **Entity Name:** `Sales packing slip headers`
*   **Mapping:**
    *   `InvoiceNumber`: Use `SalesOrderNumber` as a key to later join to the invoice data and find the corresponding `InvoiceNumber`.
    *   `ActivityName`: 'Sales Order Fulfilled' (Hardcoded Value)
    *   `EventTime`: `DeliveryDate`
    *   `UserResponsible`: `CreatedBy`

**2. Activity: Invoice Generated**
*   **Entity Name:** `Sales invoice headers V2`
*   **Filter:** `InvoiceType` is not 'CreditNote'.
*   **Mapping:**
    *   `InvoiceNumber`: `InvoiceNumber`
    *   `ActivityName`: 'Invoice Generated' (Hardcoded Value)
    *   `EventTime`: `InvoiceDate` and `CreatedTime`
    *   `InvoiceAmount`: `TotalInvoiceAmount`
    *   `CustomerName`: `InvoiceCustomerName`
    *   `UserResponsible`: `CreatedBy`
    *   `PaymentDueDate`: `DueDate`
    *   `InvoiceStatus`: `DocumentState`

**3. Activities: Invoice Submitted for Approval & Invoice Approved**
*   **Entity Name:** `Workflow tracking status table`
*   **Filter:** `ContextTableName` is 'CustInvoiceJour'.
*   **Mapping:**
    *   `InvoiceNumber`: Join `ContextRecId` to `RecId` from `Sales invoice headers V2` to get the `InvoiceNumber`.
    *   `ActivityName`: Use a conditional rule, if `TrackingStatus` is 'Submitted', set to 'Invoice Submitted for Approval'; if 'Approved', set to 'Invoice Approved'.
    *   `EventTime`: `CreatedDateTime`
    *   `UserResponsible`: `User`

**4. Activity: Invoice Sent to Customer**
*   **Note:** This is an inferred event. The posting date is used as a proxy.
*   **Entity Name:** `Sales invoice headers V2`
*   **Mapping:**
    *   `InvoiceNumber`: `InvoiceNumber`
    *   `ActivityName`: 'Invoice Sent to Customer' (Hardcoded Value)
    *   `EventTime`: `PostedDateTime` (or equivalent posting timestamp)

**5. Activity: Payment Due Date Reached**
*   **Note:** This is a calculated event generated during post-processing.
*   **Source Entity:** `Sales invoice headers V2`
*   **Logic:** For each invoice where the `DueDate` has passed and the invoice is not fully settled.
*   **Mapping:**
    *   `InvoiceNumber`: `InvoiceNumber`
    *   `ActivityName`: 'Payment Due Date Reached' (Hardcoded Value)
    *   `EventTime`: `DueDate`

**6. Activity: Payment Reminder Issued**
*   **Entity Name:** `Dunning history letters`
*   **Mapping:**
    *   `InvoiceNumber`: Join from the dunning history to the customer transactions to find the related `InvoiceNumber`.
    *   `ActivityName`: 'Payment Reminder Issued' (Hardcoded Value)
    *   `EventTime`: `DunningLetterDate`
    *   `UserResponsible`: `CreatedBy`

**7. Activity: Customer Payment Received**
*   **Entity Name:** `CustPaymentJournalLineEntity`
*   **Mapping:**
    *   `InvoiceNumber`: The `Invoice` field may be populated, but often settlements are needed to link payments to invoices. This might require staging the payment data first.
    *   `ActivityName`: 'Customer Payment Received' (Hardcoded Value)
    *   `EventTime`: `ReceivedDate` or `DocumentDate`
    *   `UserResponsible`: `CreatedBy`

**8. Activity: Cash Applied to Invoice**
*   **Entity Name:** `Customer settlement`
*   **Mapping:**
    *   `InvoiceNumber`: `OffsetInvoice`
    *   `ActivityName`: 'Cash Applied to Invoice' (Hardcoded Value)
    *   `EventTime`: `TransDate`
    *   `UserResponsible`: `CreatedBy`

**9. Activity: Payment Reversed**
*   **Source Entity:** `Customer settlement`
*   **Logic:** Filter for transactions where a settlement was later reversed. This may require looking for cancellation markers.
*   **Mapping:**
    *   `InvoiceNumber`: `OffsetInvoice`
    *   `ActivityName`: 'Payment Reversed' (Hardcoded Value)
    *   `EventTime`: Reversal transaction timestamp.

**10. Activity: Credit Note Issued**
*   **Entity Name:** `Sales invoice headers V2`
*   **Filter:** `InvoiceType` is 'CreditNote'.
*   **Mapping:**
    *   `InvoiceNumber`: `InvoiceNumber`
    *   `ActivityName`: 'Credit Note Issued' (Hardcoded Value)
    *   `EventTime`: `InvoiceDate`
    *   `InvoiceAmount`: `TotalInvoiceAmount` (will be negative)
    *   `CustomerName`: `InvoiceCustomerName`
    *   `UserResponsible`: `CreatedBy`

**11. Activity: Invoice Closed**
*   **Note:** This is an inferred event based on settlement data.
*   **Source Entity:** `Customer settlement`
*   **Logic:** Use the latest `TransDate` for an invoice from the settlement data where the invoice balance becomes zero.
*   **Mapping:**
    *   `InvoiceNumber`: `OffsetInvoice`
    *   `ActivityName`: 'Invoice Closed' (Hardcoded Value)
    *   `EventTime`: The latest `TransDate` that resulted in the invoice being fully settled.

ステップ

前提条件: Python 3.6以降がインストールされ、requestsとpandasライブラリが利用可能であることを確認してください。また、Dynamics 365 Finance & Operations環境へのアクセス権が付与されたAzure Active Directory内のサービスプリンシパル（アプリ登録）の資格情報も必要です。
アプリケーション登録: Azure ADで新しいアプリケーションを登録します。クライアントシークレットを作成し、アプリケーション（クライアント）ID、ディレクトリ（テナント）ID、およびクライアントシークレットを控えておきます。Dynamics 365では、「システム管理」>「設定」>「Azure Active Directoryアプリケーション」の下にこのアプリケーションIDを追加し、必要なデータエンティティを読み取るための適切なユーザー権限を割り当てます。
スクリプトの設定: 提供されたPythonスクリプトを開きます。スクリプトの上部にある設定変数、すなわちd365_url、tenant_id、client_id、client_secret、company、start_date、end_dateに値を入力します。d365_urlは、https://your-d365-instance.operations.dynamics.comのようなDynamics 365環境のベースURLである必要があります。
認証: スクリプトには、資格情報を使用してMicrosoftのIDプラットフォームからOAuth2アクセストークンを自動的に要求するget_access_token関数が含まれています。このトークンは、その後のAPI呼び出しを認証するために必要です。
データ抽出: ターミナルからpython your_script_name.pyを使用してスクリプトを実行します。スクリプトは、指定された日付範囲内の全ての転記済み売上請求書（CustInvoiceJour）の取得を開始します。各請求書について、支払い、決済、クレジットノート、ワークフロー履歴などの関連データを取得するために追加のAPI呼び出しを行います。
活動の生成: スクリプトは複数のAPIエンドポイントからの生データを処理します。必要な12の活動それぞれについて、明示的に行を生成します。例えば、「請求書生成済み」イベントにはCustInvoiceJourエンティティを使用し、「現金が請求書に適用済み」イベントを作成するにはCustSettlementエンティティを照会します。
計算されたイベント: 「支払期日到達済み」や「請求書クローズ済み」のようなイベントは、Dynamics 365の直接的なトランザクションではないことに注意してください。スクリプトは、請求書の期日、ステータス、決済履歴に基づいてこれらのイベントを導出し、イベントログに対応するエントリを作成します。
ページネーションの処理: fetch_all_dataヘルパー関数は、ページネーションを自動的に処理するように設計されています。Dynamics 365 OData APIはページごとに限られた数のレコードを返すため、この関数はAPIレスポンスで提供される@odata.nextLinkに従って完全なデータセットを取得します。
データ変換と出力: 全てのイベントを収集した後、スクリプトはそれらを単一のリストにコンパイルし、pandas DataFrameに変換し、列名をInvoiceNumber、ActivityName、EventTime、およびその他の必要な属性に標準化します。
CSVへのエクスポート: 最後に、スクリプトは結果のDataFrameをd365_billing_event_log.csvという名前のCSVファイルに保存します。このファイルは、ProcessMindまたは他のプロセスマイニングツールにアップロードできる形式になっています。

設定

D365 URL: Dynamics 365 Finance & OperationsインスタンスのベースURLです。これは全てのAPI呼び出しの主要なエンドポイントとなります。
Azure AD Credentials: 認証にはclient_id、client_secret、tenant_idが必要です。これらは、関連するD365エンティティへの読み取りアクセス権を持つアプリケーション用である必要があります。
Company: データ抽出元となるDynamics 365の法人（例: 'USMF'）に対応するDataAreaIdを指定します。
Date Range: 抽出範囲を制限するためにstart_dateとend_dateを定義します。最初の分析では、管理しやすいデータセットサイズを確保しつつ、十分なプロセスバリエーションを捉えるために、3〜6ヶ月の期間を推奨します。
Key OData Entities: スクリプトは主に以下のエンティティを照会します: CustInvoiceJours、CustSettlements、CustTrans、CustCollectionLetterJours、WorkflowTrackingStatusTables。設定されたユーザーがこれら全てのエンティティへの読み取り権限を持っていることを確認してください。
Performance: 長期間のデータや非常に大規模な会社からのデータ抽出は、複数の連続したAPI呼び出しを行う性質上、時間がかかる場合があります。スクリプトはオフピーク時間帯に実行し、まず短い日付範囲で開始して総実行時間を見積もることをお勧めします。

a クエリ例 python

import requests
import pandas as pd
from datetime import datetime, timezone

class=class="hl-string">"hl-comment"># --- Configuration ---
d365_url = class="hl-string">"https://[your-d365-instance].operations.dynamics.com" class=class="hl-string">"hl-comment"># Your D365 F&O URL
tenant_id = class="hl-string">"[Your Tenant ID]"
client_id = class="hl-string">"[Your Client ID]"
client_secret = class="hl-string">"[Your Client Secret]"
company = class="hl-string">"[Your Company DataAreaId, e.g., USMF]"
start_date = class="hl-string">"2023-01-01"
end_date = class="hl-string">"2023-12-31"

class=class="hl-string">"hl-comment"># --- Authentication ---
def get_access_token():
    url = fclass="hl-string">"https://login.microsoftonline.com/{tenant_id}/oauth2/v2.0/token"
    payload = {
        class="hl-string">'grant_type': class="hl-string">'client_credentials',
        class="hl-string">'client_id': client_id,
        class="hl-string">'client_secret': client_secret,
        class="hl-string">'scope': fclass="hl-string">"{d365_url}/.default"
    }
    response = requests.post(url, data=payload)
    response.raise_for_status()
    return response.json()[class="hl-string">'access_token']

class=class="hl-string">"hl-comment"># --- OData Helper ---
def fetch_all_data(access_token, resource_path):
    headers = {
        class="hl-string">'Authorization': fclass="hl-string">'Bearer {access_token}',
        class="hl-string">'Content-Type': class="hl-string">'application/json'
    }
    full_url = fclass="hl-string">"{d365_url}/data/{resource_path}"
    results = []
    while full_url:
        response = requests.get(full_url, headers=headers)
        response.raise_for_status()
        data = response.json()
        results.extend(data[class="hl-string">'value'])
        full_url = data.get(class="hl-string">'@odata.nextLink')
    return results

class=class="hl-string">"hl-comment"># --- Main Extraction Logic ---
def main():
    print(class="hl-string">"Acquiring access token...")
    token = get_access_token()
    event_log = []
    today = datetime.now(timezone.utc).date()

    print(class="hl-string">"Fetching Invoices and Credit Notes...")
    invoice_filter = fclass="hl-string">"$filter=InvoiceDate ge {start_date} and InvoiceDate le {end_date}"
    invoice_fields = class="hl-string">"$select=InvoiceNumber,InvoiceDate,SalesOrderNumber,InvoiceAmount,CustomerAccount,Due_Date,WorkerSalespersonName,createdDateTime,RecId,SalesInvoiceHeader_SalesStatus"
    invoices = fetch_all_data(token, fclass="hl-string">"CustInvoiceJours?cross-company=true&{invoice_filter}&{invoice_fields}")

    class=class="hl-string">"hl-comment"># Create a lookup for invoice RecIds for workflow queries
    invoice_recid_map = {inv[class="hl-string">'RecId']: inv[class="hl-string">'InvoiceNumber'] for inv in invoices}

    for inv in invoices:
        case_id = inv[class="hl-string">'InvoiceNumber']
        invoice_amount = inv[class="hl-string">'InvoiceAmount']
        customer_name = inv.get(class="hl-string">'CustomerAccount', class="hl-string">'') class=class="hl-string">"hl-comment"># Placeholder, join to CustTable for name
        user_responsible = inv.get(class="hl-string">'WorkerSalespersonName', class="hl-string">'System')
        due_date = inv.get(class="hl-string">'Due_Date')
        invoice_status = inv.get(class="hl-string">'SalesInvoiceHeader_SalesStatus', class="hl-string">'Open')

        class=class="hl-string">"hl-comment"># Activity: Invoice Generated / Credit Note Issued
        activity_name = class="hl-string">'Credit Note Issued' if invoice_amount < 0 else class="hl-string">'Invoice Generated'
        event_log.append({
            class="hl-string">'InvoiceNumber': case_id,
            class="hl-string">'ActivityName': activity_name,
            class="hl-string">'EventTime': inv[class="hl-string">'createdDateTime'],
            class="hl-string">'InvoiceAmount': invoice_amount,
            class="hl-string">'CustomerName': customer_name,
            class="hl-string">'UserResponsible': user_responsible,
            class="hl-string">'Department': class="hl-string">'[Configure based on your system]',
            class="hl-string">'PaymentDueDate': due_date,
            class="hl-string">'InvoiceStatus': invoice_status
        })

        class=class="hl-string">"hl-comment"># Activity: Invoice Sent to Customer (proxy)
        event_log.append({
            class="hl-string">'InvoiceNumber': case_id,
            class="hl-string">'ActivityName': class="hl-string">'Invoice Sent to Customer',
            class="hl-string">'EventTime': inv[class="hl-string">'InvoiceDate'],
            class="hl-string">'InvoiceAmount': invoice_amount,
            class="hl-string">'CustomerName': customer_name,
            class="hl-string">'UserResponsible': user_responsible,
            class="hl-string">'Department': class="hl-string">'[Configure based on your system]',
            class="hl-string">'PaymentDueDate': due_date,
            class="hl-string">'InvoiceStatus': invoice_status
        })
        
        class=class="hl-string">"hl-comment"># Activity: Sales Order Fulfilled (proxy via invoice date, complex to get actual packing slip date)
        class=class="hl-string">"hl-comment"># A more accurate query would trace SalesInvoiceLinesV2 -> SalesOrderLines -> CustPackingSlipJour
        event_log.append({
            class="hl-string">'InvoiceNumber': case_id,
            class="hl-string">'ActivityName': class="hl-string">'Sales Order Fulfilled',
            class="hl-string">'EventTime': inv[class="hl-string">'InvoiceDate'], class=class="hl-string">"hl-comment"># Using InvoiceDate as a proxy
            class="hl-string">'InvoiceAmount': invoice_amount,
            class="hl-string">'CustomerName': customer_name,
            class="hl-string">'UserResponsible': user_responsible,
            class="hl-string">'Department': class="hl-string">'[Configure based on your system]',
            class="hl-string">'PaymentDueDate': due_date,
            class="hl-string">'InvoiceStatus': invoice_status
        })

        class=class="hl-string">"hl-comment"># Activity: Payment Due Date Reached (calculated)
        if due_date and pd.to_datetime(due_date).date() < today and invoice_status != class="hl-string">'Paid':
            event_log.append({
                class="hl-string">'InvoiceNumber': case_id,
                class="hl-string">'ActivityName': class="hl-string">'Payment Due Date Reached',
                class="hl-string">'EventTime': due_date,
                class="hl-string">'InvoiceAmount': invoice_amount,
                class="hl-string">'CustomerName': customer_name,
                class="hl-string">'UserResponsible': class="hl-string">'System',
                class="hl-string">'Department': class="hl-string">'Finance',
                class="hl-string">'PaymentDueDate': due_date,
                class="hl-string">'InvoiceStatus': invoice_status
            })

    print(class="hl-string">"Fetching Settlements for Cash Applied and Invoice Closed events...")
    settlement_filter = fclass="hl-string">"$filter=InvoiceDate ge {start_date} and InvoiceDate le {end_date}"
    settlement_fields = class="hl-string">"$select=InvoiceNumber,SettlementDate,OffsetTransactionVoucher,OffsetRecId,CanBeReversed"
    settlements = fetch_all_data(token, fclass="hl-string">"CustSettlements?cross-company=true&{settlement_filter}&{settlement_fields}")

    class=class="hl-string">"hl-comment"># Group settlements by invoice
    settlements_by_invoice = pd.DataFrame(settlements).groupby(class="hl-string">'InvoiceNumber')

    for case_id, group in settlements_by_invoice:
        last_settlement = group.sort_values(class="hl-string">'SettlementDate').iloc[-1]

        for _, settlement in group.iterrows():
            class=class="hl-string">"hl-comment"># Activity: Cash Applied to Invoice
            event_log.append({
                class="hl-string">'InvoiceNumber': case_id,
                class="hl-string">'ActivityName': class="hl-string">'Cash Applied to Invoice',
                class="hl-string">'EventTime': settlement[class="hl-string">'SettlementDate'],
                class="hl-string">'UserResponsible': class="hl-string">'System',
                class=class="hl-string">"hl-comment"># Add other attributes from original invoice if needed
            })

            class=class="hl-string">"hl-comment"># Activity: Customer Payment Received (date of original payment)
            class=class="hl-string">"hl-comment"># This requires a second hop to CustTrans using OffsetRecId
            class=class="hl-string">"hl-comment"># For simplicity, we use settlement date as a proxy. A full implementation would query CustTrans.
            event_log.append({
                class="hl-string">'InvoiceNumber': case_id,
                class="hl-string">'ActivityName': class="hl-string">'Customer Payment Received',
                class="hl-string">'EventTime': settlement[class="hl-string">'SettlementDate'], class=class="hl-string">"hl-comment"># Proxy timestamp
                class="hl-string">'UserResponsible': class="hl-string">'System',
            })

            class=class="hl-string">"hl-comment"># Activity: Payment Reversed (if applicable)
            if settlement[class="hl-string">'CanBeReversed']: class=class="hl-string">"hl-comment"># A simplistic check, real logic is more complex
                 event_log.append({
                    class="hl-string">'InvoiceNumber': case_id,
                    class="hl-string">'ActivityName': class="hl-string">'Payment Reversed',
                    class="hl-string">'EventTime': settlement[class="hl-string">'SettlementDate'], class=class="hl-string">"hl-comment"># Reversal date would be different in reality
                    class="hl-string">'UserResponsible': class="hl-string">'System',
                 })
        
        class=class="hl-string">"hl-comment"># Activity: Invoice Closed (inferred from last settlement)
        class=class="hl-string">"hl-comment"># This logic assumes the invoice is fully paid by the last settlement. A robust check would sum amounts.
        event_log.append({
            class="hl-string">'InvoiceNumber': case_id,
            class="hl-string">'ActivityName': class="hl-string">'Invoice Closed',
            class="hl-string">'EventTime': last_settlement[class="hl-string">'SettlementDate'],
            class="hl-string">'UserResponsible': class="hl-string">'System',
        })

    print(class="hl-string">"Fetching Payment Reminders...")
    reminder_filter = fclass="hl-string">"$filter=CollectionLetterDate ge {start_date} and CollectionLetterDate le {end_date}"
    reminders = fetch_all_data(token, fclass="hl-string">"CustCollectionLetterJours?cross-company=true&{reminder_filter}")
    for rem in reminders:
        class=class="hl-string">"hl-comment"># Linking reminders to invoices can be complex. This is a simplified approach.
        if rem.get(class="hl-string">'InvoiceNum'):
            event_log.append({
                class="hl-string">'InvoiceNumber': rem[class="hl-string">'InvoiceNum'],
                class="hl-string">'ActivityName': class="hl-string">'Payment Reminder Issued',
                class="hl-string">'EventTime': rem[class="hl-string">'CollectionLetterDate'],
                class="hl-string">'UserResponsible': rem.get(class="hl-string">'UserId', class="hl-string">'System'),
            })

    print(class="hl-string">"Fetching Workflow History...")
    class=class="hl-string">"hl-comment"># This is a complex query. It requires knowing the TableId for CustInvoiceJour (e.g., 523)
    class=class="hl-string">"hl-comment"># The filter below is illustrative and needs to be adapted for your specific workflow setup.
    workflow_filter = fclass="hl-string">"$filter=createdDateTime ge {start_date}T00:00:00Z"
    wf_history = fetch_all_data(token, fclass="hl-string">"WorkflowTrackingStatusTables?cross-company=true&{workflow_filter}")
    for item in wf_history:
        if item.get(class="hl-string">'ContextRecId') in invoice_recid_map:
            case_id = invoice_recid_map[item[class="hl-string">'ContextRecId']]
            activity_name = None
            if item[class="hl-string">'TrackingStatus'] == class="hl-string">'Submitted':
                activity_name = class="hl-string">'Invoice Submitted for Approval'
            elif item[class="hl-string">'TrackingStatus'] == class="hl-string">'Approved':
                activity_name = class="hl-string">'Invoice Approved'
            
            if activity_name:
                event_log.append({
                    class="hl-string">'InvoiceNumber': case_id,
                    class="hl-string">'ActivityName': activity_name,
                    class="hl-string">'EventTime': item[class="hl-string">'createdDateTime'],
                    class="hl-string">'UserResponsible': item.get(class="hl-string">'User', class="hl-string">'System'),
                })

    print(fclass="hl-string">"Total events extracted: {len(event_log)}")
    if not event_log:
        print(class="hl-string">"No events found for the given criteria.")
        return

    df = pd.DataFrame(event_log)
    df = df.sort_values(by=[class="hl-string">'InvoiceNumber', class="hl-string">'EventTime'])
    df.to_csv(class="hl-string">'d365_billing_event_log.csv', index=False)
    print(class="hl-string">"Event log saved to d365_billing_event_log.csv")

if __name__ == class="hl-string">"__main__":
    main()

オーダー・トゥ・キャッシュ（請求・支払業務）データテンプレート

オーダー・トゥ・キャッシュ（請求・支払業務）データテンプレート

オーダー・トゥ・キャッシュ（請求・支払業務）属性

オーダー・トゥ・キャッシュ（請求・支払業務）アクティビティ

抽出ガイド

Microsoft Dynamics 365 データエンティティのエクスポート

ステップ

設定

a クエリ例 config

PythonスクリプトによるDynamics 365 OData Web APIの利用

ステップ

設定

a クエリ例 python

今すぐ始めますか？

請求遅延をなくす: 受注から現金化までの請求・入金を今すぐ最適化

オーダー・トゥ・キャッシュ（請求・支払業務）データテンプレート

オーダー・トゥ・キャッシュ（請求・支払業務）データテンプレート

オーダー・トゥ・キャッシュ（請求・支払業務）属性

オーダー・トゥ・キャッシュ（請求・支払業務）アクティビティ

抽出ガイド

Microsoft Dynamics 365 データエンティティのエクスポート

ステップ

設定

a クエリ例 config

PythonスクリプトによるDynamics 365 OData Web APIの利用

ステップ

設定

a クエリ例 python

お客様のプライバシーを大切にしています

今すぐ始めますか？

請求遅延をなくす: 受注から現金化までの請求・入金を今すぐ最適化