> 継続的なプロセス改善 > 受注から入金まで：請求・請求書発行 > Microsoft Dynamics 365 > データテンプレート

受注から入金まで：請求・請求書発行のデータテンプレート

Microsoft Dynamics 365

受注から入金まで：請求・請求書発行の属性 (18) 受注から入金まで：請求・請求書発行のアクティビティ (12) 抽出ガイド (2)

受注から入金まで：請求・請求書発行のデータテンプレート

このテンプレートでは、受注から入金までの請求・請求書発行プロセスを分析するために必要なデータ項目を収集する手順を示します。イベントログに含める推奨属性、追跡すべき主要なアクティビティ、情報の抽出方法を確認できます。プロセスマイニングに必要なデータをすばやく準備できるよう設計されています。

収集を推奨する属性
追跡すべき主要なアクティビティ
Microsoft Dynamics 365からの抽出方法

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

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

受注から入金まで：請求・請求書発行の属性

受注から入金までの請求・請求書発行を詳細に分析するため、イベントログに含めることを推奨するデータ項目です。

3 必須 6 推奨 9 任意

	名前	説明
	請求書番号 InvoiceNumber	各顧客請求書を一意に識別する番号で、請求プロセスの主要なケース識別子として機能します。
説明 Invoice Numberは、1件の請求書に関連するすべてのアクティビティをまとめる中心的なキーです。作成、承認から顧客の支払い、最終的なクローズまで、請求書のライフサイクル全体を分析できます。これをCase IDとして使用すると、すべてのイベントログエントリが特定の請求書に対応するため、詳細なバリアント分析、サイクルタイムの計算、請求取引ごとのパフォーマンス監視が可能になります。重要な理由この属性は、請求書のライフサイクル全体を追跡するために欠かせません。個々の請求書について、プロセス効率、ボトルネック、逸脱を分析できます。入手先通常は販売・マーケティングモジュールにあり、CustInvoiceJour（InvoiceIdフィールド）などのテーブル、またはSalesInvoiceHeaderV2などのデータエンティティから取得できます。例 CIV-001254INV-2023-9876US-004321
	アクティビティ名 ActivityName	請求書のライフサイクルにおいて、特定の時点で発生した業務アクティビティまたはイベントの名称です。
説明この属性は、「Invoice Generated」「Invoice Approved」「Customer Payment Received」など、請求プロセス内の特定のステップやマイルストーンを表します。これらのアクティビティの順序がプロセスフローを形成します。アクティビティの分析はプロセスマイニングの基本であり、プロセスモデルやバリアントの発見、ステップ間のパフォーマンス測定に役立ちます。重要な理由プロセスの各ステップを定義し、プロセスマップの可視化、プロセスバリアントの分析、標準手順からのボトルネックや逸脱の特定を可能にします。入手先通常は、ステータス変更フィールド（例：DocumentState）、特定の日付フィールドへの値の入力、Microsoft Dynamics 365内のワークフロー履歴ログなど、複数の情報源から導出します。例請求書を作成請求書を承認顧客から入金クレジットノートを発行
	イベント時刻 EventTime	特定のアクティビティまたはイベントが発生した正確な日時を示すタイムスタンプです。
説明イベント時刻はタイムスタンプとも呼ばれ、プロセス内の各アクティビティについて正確な日付と時刻を記録します。時間に基づくプロセスマイニング分析には欠かせないデータです。アクティビティ間のサイクルタイム、ケース全体の所要時間、時間の経過に伴うプロセスパフォーマンスの把握に使います。正確で信頼性の高いタイムスタンプは、売上債権回転日数や請求書作成時間などの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	請求書の発行先となる顧客の名称です。
説明顧客名は、請求先となる企業または個人を人が読み取れる形で識別する情報です。プロセスマイニング分析では、顧客別に請求プロセスを分けて分析できます。これにより、支払いが常に期日どおりの顧客、遅延が頻繁に発生する顧客、特定の顧客グループで固有のプロセス差異や遅延が発生しているかどうかを把握できます。顧客の支払い行動や売上債権回転日数の分析に関するダッシュボードに欠かせない情報です。重要な理由顧客別にプロセス分析を分けられるため、顧客固有の行動、支払いパターン、プロセス上の問題を特定しやすくなります。入手先通常は、顧客アカウント番号をキーとして、請求書データと顧客マスターデータテーブル（CustTable）を結合して取得します。例 Contoso Ltd.Fabrikam, Inc.Northwind Traders
	ソースシステム SourceSystem	データを抽出したシステムです。
説明この属性は、プロセスデータの取得元を示します。ここでは、データがMicrosoft Dynamics 365から取得されたことを表します。複数のシステムを利用する環境では、データソースを区別し、データの系譜を明確にするために重要です。データの検証や問題の切り分けにも役立ちます。重要な理由データの取得元に関する重要な背景情報を提供します。データガバナンスや検証に欠かせないほか、複数の業務システムからデータを統合する際にも役立ちます。入手先データの抽出・変換処理で追加される固定値で、データセットの取得元を示すラベルとして使用します。例 Microsoft Dynamics 365 FinanceD365 F&O
	再作業あり IsRework	複数回の承認など、請求書プロセスに再作業のアクティビティが含まれていたかを示すフラグです。
説明再作業が発生した請求書を示す、計算されたブール型の属性です。再作業は、「請求書承認済み」イベントが複数回発生した場合や、支払いが取り消された場合などと定義できます。この属性は、「請求書再作業分析」ダッシュボードと「請求書再作業率」KPIを支えるために設計されています。該当するケースを分離することで、プロセスの非効率、データ品質の問題、トレーニング不足につながることが多い再作業の根本原因を調査できます。重要な理由反復作業や修正作業が発生したケースを特定することで、プロセスの非効率を直接測定できます。無駄や遅延の根本原因を特定する際にも役立ちます。入手先この属性はソースシステムにはありません。ケース内のアクティビティの繰り返しや、特定の再作業パターンを確認して、データ変換レイヤーで計算します。例 truefalse
	最終データ更新 LastDataUpdate	このイベントのデータがソースシステムから最後に更新された日時を示すタイムスタンプです。
説明 Microsoft Dynamics 365からデータを最後に抽出または更新した日時を記録する属性です。分析対象データの鮮度を把握するために欠かせないメタデータフィールドです。分析担当者や業務ユーザーは最新情報を確認できているか判断でき、データ更新スケジュールの管理や分析の信頼性確保にも役立ちます。重要な理由データがいつ更新されたかをユーザーが把握できるようにします。データガバナンス、ダッシュボードの更新管理、分析結果の適時性を信頼するうえで重要です。入手先データの抽出、変換、ロード（ETL）処理の中で生成され、データセットに付与されます。例 2023-06-20T05:00:00Z2023-06-21T05:00:00Z
	売上債権回転日数 DaysSalesOutstanding	請求書の発行から顧客の支払いを受領するまでの日数です。
説明売上債権回転日数（DSO）は、販売後に企業が支払いを回収するまでの平均日数を測定する重要な財務指標です。この計算された属性は、請求書ごとにこの期間を算出します。「売上債権回転日数の推移分析」ダッシュボードと「DSO」KPIの主要指標です。DSOを分析すると、キャッシュフローを管理し、与信・回収業務の効率を評価できます。重要な理由企業のキャッシュフローの健全性と回収プロセスの効率を測定する重要なKPIです。収益がどれだけ速く現金化されるかを数値で示します。入手先この属性はソースシステムにはありません。「請求書発行」アクティビティから「顧客支払受領」アクティビティまでの期間として計算します。例 284592
	手動対応が必要 RequiresManualIntervention	入金消込の際に、支払いに手動調整が必要だったかを示すフラグです。
説明このブール型の属性は、入金消込プロセスで手動対応または修正が必要だった支払いを示します。支払転記の正確性と自動化レベルを測定する「入金消込差異率」KPIに欠かせません。送金情報の不足や支払額の不一致など、手動対応の理由を特定することで、ストレートスルー処理率を高めるプロセス改善につなげられます。重要な理由入金消込の手順における作業上の障害や不正確さを特定するのに役立ちます。自動化の向上と手作業の削減に欠かせない属性です。入手先支払いを転記したユーザーがシステムユーザーではない場合は、そのユーザー情報から推測できる可能性があります。また、支払照合で使われた特定の理由コードから判断できる場合もあります。Microsoft Dynamics 365のドキュメントを確認してください。例 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
	請求書に入金を消込	顧客からの支払いを特定の請求書に対して決済し、請求書の未決済残高を減らしたことを示します。Dynamics 365では、支払い取引と請求書取引を紐づける独立したステップです。
重要な理由 DSOを正確に計算し、入金消込チームの効率を把握するための重要なマイルストーンです。請求額に対する支払いの消込が完了した時点を示します。入手先 CustSettlementテーブルに記録されます。このテーブルの決済日フィールドから、特定の支払いを特定の請求書取引に適用した時点のタイムスタンプを取得できます。取得 CustSettlementテーブルのTransDateまたはCreatedDateTimeを使用します。イベントタイプ explicit
	請求書をクローズ	請求書の残高がゼロになり、全額支払いまたはクレジットノートとの決済が完了した最終状態を示します。直接の取引ではなく、請求書の財務ステータスに基づいて推定する状態です。
重要な理由 1件の請求書について、受注から入金までのサイクルが正常に完了したことを示します。この状態に到達するまでの時間は、プロセス全体の効率を測る主要な指標です。入手先 CustTransテーブルの請求書取引について、残高がゼロかどうかを確認して推定します。請求書金額と、その請求書に対する決済済み金額の合計を比較して判定します。取得 AmountCurがSettleAmountCurと等しいCustTransレコードから導出します。タイムスタンプには最後の決済日を使用します。イベントタイプ inferred
	請求書を作成	システム上で販売請求書を作成し、転記したことを示します。Dynamics 365で明示的に記録される取引であり、法的文書と売掛金補助元帳の財務仕訳を作成します。
重要な理由請求書の請求ライフサイクルが正式に始まる時点です。売上債権回転日数（DSO）とプロセス全体の所要時間を追跡するうえで重要なイベントです。入手先 CustInvoiceJourテーブルにある転記済み販売請求書レコードの作成タイムスタンプから取得します。転記時には、GeneralJournalEntryおよびLedgerEntryテーブルに対応する財務取引が作成されます。取得転記済み請求書について、CustInvoiceJourテーブルのCreatedDateTimeフィールドを使用します。イベントタイプ explicit
	請求書を承認	社内確認プロセスが完了し、請求書が正式に承認されたことを示します。このイベントはDynamics 365のワークフローシステムに記録され、請求書を顧客に送付できる状態になったことを意味します。
重要な理由承認サイクルタイムを測定する重要なマイルストーンです。この段階での遅延は、顧客から入金されるまでの全体時間を直接延ばす可能性があります。入手先 WorkflowTrackingStatusTableなどのワークフロー履歴テーブルに、特定の請求書ワークフローインスタンスの完了または承認ステップとして記録されます。取得ステータスが「Approved」または「Completed」のワークフローイベントログを抽出します。イベントタイプ explicit
	請求書を顧客に送付	請求書を電子的または物理的に顧客へ送信した時点を示すアクティビティです。Dynamics 365では、システムメールで送信した場合は明示的なイベントとして記録できます。専用の追跡機能を有効にしていない場合は、転記時に送信されたものとして推定することがあります。
重要な理由請求書送付プロセスの効率を測定します。承認から送付までの遅延は、支払いサイクルを不必要に長期化させます。入手先 D365のメール機能を利用している場合は、SysOutgoingEmailTableなどのメールログから明示的に取得できます。それ以外の場合は、CustInvoiceJourの請求書転記時刻と同じ時刻として推定することが一般的です。取得利用できる場合はメールログのタイムスタンプを使用し、利用できない場合は請求書の転記タイムスタンプを使用します。イベントタイプ inferred
	顧客から入金	顧客から受け取った支払いを記録する仕訳を作成したことを示すアクティビティです。現金を受領したことを意味しますが、特定の請求書への消込はまだ完了していません。
重要な理由入金消込のリードタイムを測定する起点です。資金を受け取った時点と、未決済の請求書に対して実際に消し込んだ時点を区別できます。入手先顧客支払い仕訳の作成または転記から取得します。LedgerJournalTransなどのテーブルに記録され、転記時にCustTransの顧客取引が作成されます。取得 LedgerJournalTableから、顧客支払い仕訳の転記タイムスタンプを使用します。イベントタイプ explicit
	クレジットノートを発行	請求ミスの訂正、価格調整、返品商品の処理などを目的に、クレジットノートまたはクレジットメモを作成したことを示します。クレジットノートは、基本的にマイナスの請求書です。
重要な理由クレジットノートが頻繁に発行される場合、受注履行や請求プロセスに構造的な問題がある可能性があります。発行理由を分析することは、プロセス改善と収益漏れの削減に重要です。入手先明示的な取引として、CustInvoiceJourテーブルに金額がマイナスの新しい転記済み請求書として記録されます。参照フィールドによって元の請求書に紐づけられることが多いです。取得 CustInvoiceJourで合計金額がマイナスのレコードを特定し、元の請求書に紐づけます。イベントタイプ explicit
	支払いリマインダーを発行	支払期日を過ぎた請求書について、顧客に督促状または回収通知を送付したことを示します。Dynamics 365には、こうした通知を生成して記録する正式な督促プロセスがあります。
重要な理由リマインダーを追跡することで、督促プロセスの効果を評価できます。入金されるまでに何回のリマインダーが必要だったかも分析できます。入手先延滞請求書の取引に紐づくCustCollectionLetterJourテーブルの回収通知仕訳の作成日から、明示的なイベントとして取得します。取得 CustCollectionLetterJourテーブルの作成タイムスタンプを使用します。イベントタイプ explicit
	支払いを取り消し	以前に転記した顧客支払いを取り消したことを示します。誤った転記、残高不足、その他の支払い失敗などが原因で発生します。
重要な理由支払いの取消は、業務上のエラーや顧客支払いに関する問題を示します。発生頻度を分析することで、根本原因を特定し、入金消込プロセスの正確性を高められます。入手先総勘定元帳の取引取消として取得します。取り消された仕訳はGeneralJournalEntryで、特定のフラグまたは元の取引との関連によって特定できることが多いです。取得取消フラグが付いた仕訳、または取り消された取引への参照を持つ仕訳を特定します。イベントタイプ explicit
	請求書を承認に提出	作成済みの請求書を正式な承認ワークフローに提出したことを示すアクティビティです。請求書を顧客に送付する前に管理者の確認を必要とする統制を設けている組織で、よく見られます。D365のワークフローエンジンでは、特定のステップとして記録されます。
重要な理由承認への提出を追跡することで、請求書の作成時間と承認待ち時間を分けて把握できます。社内の確認・統制プロセスの効率を分析する最初のステップです。入手先 WorkflowTrackingStatusTableなどのワークフロー履歴テーブルから、請求書文書に関連する提出イベントを絞り込んで取得します。取得ステータスが「Submitted」のワークフローイベントログを抽出します。イベントタイプ 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ファイルの内容をローカルフォルダーに展開します。エンティティごとに1つずつ、複数のCSVファイルが作成されます。
データを変換して結合： 生のファイルを1つのイベントログに変換する必要があります。Power Query、Python、データベースのステージング領域などのデータ準備ツールを使います。各ソースファイルに、必要な列を作成します：InvoiceNumber（ケースID）、ActivityName（「Invoice Generated」など、イベントを表す固定値）、EventTime（ソースファイルの該当する日付フィールド）。InvoiceAmountやCustomerNameなどの他の属性もマッピングします。
変換済みデータをすべて統合： unionまたはappend操作を使って、すべてのソースファイルの変換済みデータを1つのテーブルに結合します。これにより、請求書のライフサイクルにおける1つのアクティビティを各行で表す、統合済みのイベントログが作成されます。
アップロード用に最終整形： 最終CSVファイルに正しい列ヘッダー（InvoiceNumber、ActivityName、EventTimeなど）が設定され、EventTime列が一貫したタイムスタンプ形式（例：YYYY-MM-DD HH:MI:SS）になっていることを確認します。このファイルをProcessMindにアップロードできます。

設定

データエンティティ： 抽出には、標準D365データエンティティを使用します。主なエンティティは、請求書とクレジットノート用のSales invoice headers V2、受注処理用のSales packing slip headers、支払い用のCustPaymentJournalLineEntity、入金消込用のCustomer settlement、承認用のWorkflow tracking status tableです。
エクスポート形式： 多くのデータ変換ツールと互換性があるため、対象データ形式にはCSVを推奨します。
日付範囲のフィルタリング： 主要エンティティ、特にInvoiceDateフィールドを持つSales invoice headers V2には、日付範囲フィルターを適用することが重要です。エクスポートを管理しやすくしながら、分析に十分なデータを確保するため、3～6か月の範囲を推奨します。
会社のフィルタリング： データの関連性を確保し、エクスポートサイズを抑えるため、分析対象の特定の法人エンティティまたは会社コードでエクスポートを絞り込んでください。
データのステージングと変換： Dynamics 365の外部で後処理が必要です。エクスポートしたファイルを結合し、1つのイベントログ形式に整形します。通常は、Power BI（Power Query）、Python、SQLなどのツールを使います。
前提条件： エクスポートを実行するユーザーには、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.

ステップ

前提条件： requestsとpandasライブラリを含むPython 3.6以降をインストールします。また、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にはDynamics 365環境のベースURLを指定します。例：https://your-d365-instance.operations.dynamics.com。
認証： スクリプトにはget_access_token関数が含まれており、認証情報を使ってMicrosoftのIDプラットフォームからOAuth2アクセストークンを自動的に取得します。このトークンは、後続のAPI呼び出しを認証するために必要です。
データを抽出： ターミナルでpython your_script_name.pyを実行します。スクリプトはまず、指定した日付範囲内の転記済み販売請求書（CustInvoiceJour）をすべて取得します。次に各請求書について、支払い、決済、クレジットノート、ワークフロー履歴などのアクティビティに関連するデータを取得するため、追加のAPI呼び出しを行います。
アクティビティを生成： スクリプトは複数のAPIエンドポイントから取得した生のデータを処理します。必要な12種類のアクティビティについて、それぞれ1行を明示的に生成します。たとえば、「Invoice Generated」イベントにはCustInvoiceJourエンティティを使い、「Cash Applied to Invoice」イベントはCustSettlementエンティティを照会して作成します。
計算イベント： 「Payment Due Date Reached」や「Invoice Closed」などのイベントは、Dynamics 365の直接的なトランザクションではありません。スクリプトは、請求書の支払期日、ステータス、決済履歴に基づいてこれらのイベントを導出し、イベントログに対応する行を作成します。
ページネーションを処理： fetch_all_dataヘルパー関数は、ページネーションを自動的に処理するよう設計されています。Dynamics 365 OData APIは1ページあたりのレコード数に上限があるため、この関数はAPIレスポンスに含まれる@odata.nextLinkをたどり、完全なデータセットを取得します。
データを変換して出力： すべてのイベントを収集したら、スクリプトはそれらを1つのリストにまとめ、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でデータを抽出する法人に対応するDataAreaIdを指定してください（例：'USMF'）。
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()

準備はできましたか？

このテンプレートを使って、請求・請求書発行の最適化に向けた取り組みを始めてください。業務効率を高め、キャッシュフローを改善するために必要な情報をチームに提供できます。

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

請求の遅延を解消：受注から入金までと請求書発行を今すぐ最適化

請求サイクルを30％短縮し、財務状況をより早く明確に把握できます。

無料トライアルを開始

クレジットカードは不要です。14日間無料でお試しいただけます。

受注から入金まで：請求・請求書発行のデータテンプレート

受注から入金まで：請求・請求書発行のデータテンプレート

受注から入金まで：請求・請求書発行の属性

受注から入金まで：請求・請求書発行のアクティビティ

抽出ガイド

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

ステップ

設定

a サンプルクエリ config

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

ステップ

設定

a サンプルクエリ python

準備はできましたか？

請求の遅延を解消：受注から入金までと請求書発行を今すぐ最適化

受注から入金まで：請求・請求書発行のデータテンプレート

受注から入金まで：請求・請求書発行のデータテンプレート

受注から入金まで：請求・請求書発行の属性

受注から入金まで：請求・請求書発行のアクティビティ

抽出ガイド

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

ステップ

設定

a サンプルクエリ config

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

ステップ

設定

a サンプルクエリ python

準備はできましたか？

請求の遅延を解消：受注から入金までと請求書発行を今すぐ最適化

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