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

受注から入金までの請求・請求書発行プロセス向けデータテンプレート

Microsoft Dynamics 365

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

受注から入金までの請求・請求書発行プロセス向けデータテンプレート

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

収集を推奨する属性
追跡する主要なアクティビティ
Microsoft Dynamics 365からのデータ抽出ガイド

イベントログを初めて作成する方はこちら：プロセスマイニング用イベントログの作成方法.

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

受注から入金までの請求・請求書発行プロセスの属性

受注から入金までの請求・請求書発行プロセスを詳しく分析するために、イベントログへの追加を推奨するデータ項目です。

3 必須 6 推奨 9 任意

	名前	説明
	請求書番号 InvoiceNumber	顧客向けの各請求書を一意に識別する番号です。請求プロセスの主なケース識別子として使います。
説明請求書番号は、1件の請求文書に関連するすべてのアクティビティをまとめる中心的なキーです。請求書の作成と承認から、顧客の支払い、最終的なクローズまで、ライフサイクル全体を分析できます。ケースIDに請求書番号を使うと、イベントログの各レコードが特定の請求書に対応するため、バリアントの詳細な分析、サイクルタイムの算出、請求処理ごとのパフォーマンス監視が可能になります。重要な理由この属性は、請求書のライフサイクル全体を追跡するために欠かせません。個々の請求文書について、プロセス効率、ボトルネック、逸脱を分析できます。入手先通常は販売・マーケティングモジュールにあり、CustInvoiceJourテーブルのInvoiceIdフィールドや、SalesInvoiceHeaderV2などのデータエンティティから取得できます。例 CIV-001254INV-2023-9876US-004321
	アクティビティ名 ActivityName	請求書のライフサイクルにおいて、特定の時点で発生した業務アクティビティまたはイベントの名前です。
説明この属性は、「請求書を作成」「請求書を承認」「顧客からの入金を確認」など、請求プロセスの特定の手順や節目を表します。これらのアクティビティの順序がプロセスの流れを構成します。アクティビティの分析はプロセスマイニングの基本です。プロセスモデルの検出、バリアントの特定、各手順間のパフォーマンス測定に役立ちます。重要な理由プロセスの手順を定義する属性です。プロセスマップの可視化、プロセスバリアントの分析、ボトルネックや標準手順からの逸脱の特定に使います。入手先通常、Microsoft Dynamics 365のステータス変更フィールド（DocumentStateなど）、特定の日付フィールドへの値の入力、ワークフロー履歴ログなど、複数の情報源から取得します。例請求書を作成請求書を承認顧客からの入金を確認クレジットノートを発行
	イベント時刻 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
	最終データ更新日時 LastDataUpdate	このイベントのデータがソースシステムから最後に更新された日時を示すタイムスタンプです。
説明この属性には、Microsoft Dynamics 365からデータを最後に抽出または更新した日時が記録されます。分析対象のデータがどの程度新しいかを把握するための重要なメタデータです。分析担当者や業務ユーザーは、最新の情報を見ているかどうかを確認できます。また、データ更新スケジュールの管理や分析結果の信頼性確保にも役立ちます。重要な理由データがいつ更新されたかを把握できるため、データガバナンスやダッシュボードの更新管理に役立ち、インサイトの鮮度を確認できます。入手先この属性は、データの抽出、変換、ロード（ETL）の過程で生成され、データセットに記録されます。例 2023-06-20T05:00:00Z2023-06-21T05:00:00Z
	受注番号 SalesOrderNumber	請求書の元となった受注を識別する番号です。
説明受注番号を使うと、請求プロセスをその前段階の販売プロセスと関連付けられます。このつながりは、受注から入金までのプロセスを一貫して分析する際に役立ちます。受注内容の変更や出荷の遅れなど、販売・履行プロセスの問題が請求サイクルにどう影響するかを調べられます。たとえば、「複雑な受注の請求書は、入金までに時間がかかるか」といった疑問の検証に役立ちます。重要な理由請求プロセスと前段階の販売プロセスを結び付け、受注から入金までを一貫して分析できます。請求に関する問題の根本原因を特定する際に役立ちます。入手先請求書ヘッダーまたは明細にあり、受注と関連付けられています。CustInvoiceJourテーブルのSalesIdなどのフィールドを確認してください。例 SO-009876SO-010234US-SO-00543
	売上債権回転日数 DaysSalesOutstanding	請求書の発行から顧客の入金までの日数です。
説明売上債権回転日数（DSO）は、販売後に代金を回収するまでの平均日数を測る重要な財務指標です。この計算済み属性では、請求書ごとの所要日数を算出します。「売上債権回転日数の推移分析」ダッシュボードと「DSO」KPIの主要指標です。DSOの分析は、キャッシュフローの管理や与信・債権回収業務の効率評価に役立ちます。重要な理由企業のキャッシュフローの健全性と債権回収プロセスの効率を測る重要なKPIです。売上がどれだけ早く現金化されるかを数値で示します。入手先この属性はソースシステムにはありません。「請求書作成」アクティビティから「顧客からの入金」アクティビティまでの所要時間として算出します。例 284592
	手作業での対応が必要 RequiresManualIntervention	入金消込の際に、支払いの手動調整が必要だったかを示すフラグです。
説明この真偽値属性は、入金消込の際に手作業での対応や修正が必要だった支払いを示します。「入金消込の不一致率」KPIの算出に役立ち、支払い計上の正確性や自動化の度合いを把握できます。送金情報の不足や支払額の不一致など、手作業が必要となった理由を特定することで、プロセスを改善し、処理の自動化率を高められます。重要な理由入金消込の手順で発生する処理上の問題や不正確さを特定できます。自動化の改善や手作業の削減に役立ちます。入手先支払いを計上したユーザーがシステムユーザーでない場合は、そのユーザー情報から推定できることがあります。また、支払い照合時に使用した特定の理由コードから判断できる場合もあります。詳しくはMicrosoft Dynamics 365の文書をご確認ください。例 truefalse
	手戻りあり IsRework	複数回の承認など、請求書の処理で手戻りが発生したかを示すフラグです。
説明手戻りが発生した請求書を示す、計算済みの真偽値属性です。手戻りは、「請求書承認」イベントの複数回発生や、支払いの取り消しなどで判定できます。この属性は、「請求書の手戻り分析」ダッシュボードと「請求書の手戻り率」KPIに対応しています。該当するケースを抽出することで、手戻りの根本原因を調査できます。原因としては、プロセスの非効率、データ品質の問題、トレーニング不足などが考えられます。重要な理由繰り返しや修正の作業が発生したケースを特定し、プロセスの非効率を数値で把握できます。無駄や遅延の根本原因を特定するのに役立ちます。入手先この属性はソースシステムにはありません。ケース内でアクティビティの繰り返しや特定の手戻りパターンを確認し、データ変換レイヤーで算出します。例 truefalse
	支払条件 PaymentTerms	請求書の支払いに関する合意条件です（例：30日以内、60日以内）。
説明支払条件は、顧客が請求書をいつまでに支払うかを定めたものです。この属性は支払期日の算出に使われ、支払い傾向を分析する際の重要な切り口となります。「支払条件の遵守状況分析」ダッシュボードでは、この属性で顧客や請求書を分類し、支払条件によって支払いの状況や遅延の発生率に違いがあるかを確認します。重要な理由請求書の支払期日が設定された理由を把握できます。また、支払条件ごとに分析し、特定の条件が支払い遅延と関連しているかを確認できます。入手先通常は顧客マスターレコードに保存され、請求書ヘッダーにもコピーされます。CustInvoiceJourテーブルのPaymentまたはPaymTermIdフィールドを確認してください。例 30日以内60日以内受領時払い
	期日どおりの支払い IsOnTimePayment	顧客からの支払いが支払期日までに行われたかを示すフラグです。
説明この計算済みの真偽値属性は、「顧客からの入金」タイムスタンプと「支払期日」を比較し、請求書ごとに期日どおりの支払いか遅延かを示します。「期日どおりの支払い率」KPIの算出に使う基本的な属性で、「支払条件の遵守状況分析」ダッシュボードでも広く利用されます。支払い状況を明確に二分して示すため、分析や報告が容易になります。重要な理由顧客が支払条件を守っているかを直接測定します。「期日どおりの支払い率」KPIの基礎となり、回収業務の有効性を分析しやすくします。入手先この属性はソースシステムにはありません。データ変換時に、支払日とPaymentDueDateを比較して算出します。例 truefalse
	通貨 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
	受注内容の履行完了	このアクティビティは、受注した商品の出荷またはサービスの提供が完了し、請求処理が始まる時点を示します。通常、Microsoft Dynamics 365で梱包明細書または納品書を転記すると記録され、関連する受注明細のステータスが変わります。
重要な理由このイベントは、請求書発行のサイクルタイムを測定する起点です。受注内容の履行から請求書発行までの遅れを把握すると、キャッシュフローに影響する事務処理上のボトルネックを特定できます。入手先受注に関連付けられた梱包明細書仕訳の作成日から推定します。CustPackingSlipJourやCustPackingSlipTransなどのテーブルを参照します。これらのテーブルは、請求書の基となる受注に関連付けられています。記録請求書に関連付けられた受注について、梱包明細書の最新の転記日を特定します。イベントタイプ inferred
	支払いリマインダーを送信	支払期日を過ぎた請求書について、顧客に督促状または回収通知を送ることを示します。Dynamics 365には、こうした連絡を作成して記録する正式な督促プロセスがあります。
重要な理由リマインダーを追跡すると、督促プロセスの効果を評価できます。入金までに必要なリマインダーの回数も分析できます。入手先 CustCollectionLetterJourテーブルに記録された回収通知仕訳の作成日から取得する、明示的なイベントです。回収通知仕訳は、支払期日を過ぎた請求書のトランザクションに関連付けられています。記録 CustCollectionLetterJourテーブルの作成タイムスタンプを使用します。イベントタイプ explicit
	支払いを取り消し	転記済みの顧客入金を取り消したことを示すアクティビティです。誤った転記、残高不足、その他の支払い失敗などが原因で発生します。
重要な理由支払いの取り消しは、業務上のミスや顧客の支払いに関する問題を示します。発生頻度を分析すると、根本原因を特定し、入金消込の精度を高められます。入手先総勘定元帳のトランザクション取消として記録されます。GeneralJournalEntryで取消済みの仕訳を特定できます。多くの場合、専用のフラグや元のトランザクションとの関連付けで判別します。記録取消フラグが付いた仕訳、または取り消されたトランザクションを参照する仕訳を特定します。イベントタイプ explicit
	請求書を承認に申請	作成した請求書を正式な承認ワークフローに申請したことを示すアクティビティです。請求書を顧客に送る前に管理者の確認を求める組織でよく見られます。D365のワークフローエンジンに特定の手順として記録されます。
重要な理由承認申請を追跡すると、請求書の作成時間と承認待ちの時間を分けて把握できます。社内の確認・統制プロセスの効率を分析する最初の手順です。入手先 WorkflowTrackingStatusTableなどのワークフロー履歴テーブルから、請求書文書に関連する申請イベントを抽出します。記録ステータスが「Submitted」のワークフローイベントログを抽出します。イベントタイプ explicit

推奨任意

データ抽出ガイド

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

ステップ

データ管理ワークスペースを開く： Microsoft Dynamics 365 Finance and Operationsにログインします。検索バーでData managementワークスペースを検索して開きます。ここでデータのインポートとエクスポートを管理します。
新しいエクスポートプロジェクトを作成する： Data managementワークスペースでExportタイルをクリックし、新しいデータエクスポートプロジェクトを作成します。ProcessMind_O2C_Billing_Exportなど、内容が分かる名前と説明を設定します。
出力データ形式を選択する： プロジェクトの設定でTarget data formatを指定します。多くのデータ変換ツールと互換性のあるCSVを選択してください。必要に応じて、一般的な区切り文字とテキスト修飾子を設定します。
必要なデータエンティティを追加する： ここは特に重要な手順です。必要なアクティビティを記録するため、複数の標準データエンティティをプロジェクトに追加します。各エンティティについてAdd entityをクリックし、クエリ／スクリプトのセクションに記載されたエンティティ名を検索します。次のエンティティをすべて追加してください：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セクションでジョブの進行状況を確認できます。正常に完了したら、エクスポートしたデータパッケージをダウンロードします。パッケージはZIP形式で、各データエンティティのCSVファイルが個別に含まれています。
パッケージを解凍する： ダウンロードしたZIPファイルをローカルフォルダーに展開します。エンティティごとに1つずつ、複数のCSVファイルが作成されます。
データを変換して結合する： 生のファイルを1つのイベントログに変換する必要があります。Power Query、Python、データベースのステージング領域などのデータ準備ツールを使います。各ソースファイルに、必要な列を作成します。たとえば、InvoiceNumber（ケースID）、イベントを示す固定値（「請求書を作成」など）を設定したActivityName、ソースファイルの該当する日付フィールドを設定したEventTimeです。InvoiceAmountやCustomerNameなどの属性も対応付けます。
変換したデータをすべて結合する： ユニオンまたは追加の操作を使い、すべてのソースファイルの変換済みデータを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を出力形式として推奨します。
日付範囲のフィルター： 主要なエンティティには日付範囲のフィルターを設定してください。特にSales invoice headers V2のInvoiceDateが対象です。分析に十分なデータを確保しつつ、運用しやすいエクスポートにするため、3～6か月の範囲を推奨します。
会社のフィルター： データの関連性を確保し、エクスポートのサイズを抑えるため、分析対象の法人または会社コードで絞り込んでください。
データのステージングと変換： Dynamics 365の外部で後処理が必要です。エクスポートしたファイルを結合し、単一のイベントログ形式に整えます。通常はPower BI（Power Query）、Python、SQLなどのツールを使用します。
前提条件： エクスポートを実行するユーザーには、Dynamics 365で適切なセキュリティロールが割り当てられている必要があります。通常、Data managementワークスペースの利用権限と、必要なデータエンティティへのアクセス権限が必要です。

クエリの例 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種類のアクティビティごとに行を作成します。たとえば、「請求書を作成」イベントにはCustInvoiceJourエンティティを使用し、「請求書に入金を消し込む」イベントの作成にはCustSettlementエンティティを照会します。
計算によるイベント： 「支払期日到来」や「請求書クローズ」などのイベントは、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の認証情報： 認証にはclient_id、client_secret、tenant_idが必要です。関連するD365エンティティの読み取り権限を持つアプリケーションの認証情報を指定してください。
会社： データの抽出元となるDynamics 365の法人に対応するDataAreaIdを指定します（例：USMF）。
日付範囲： 抽出対象を絞り込むため、start_dateとend_dateを指定します。初回の分析では、十分なプロセスの変化を把握しながらデータ量を抑えられる3～6か月の期間を推奨します。
主要なODataエンティティ： スクリプトでは主に、CustInvoiceJours、CustSettlements、CustTrans、CustCollectionLetterJours、WorkflowTrackingStatusTablesの各エンティティを照会します。設定したユーザーに、これらすべてのエンティティの読み取り権限があることを確認してください。
パフォーマンス： 長期間または大規模な会社のデータを抽出する場合、APIを複数回順次呼び出すため、処理に時間がかかることがあります。負荷の少ない時間帯に実行し、まず短い日付範囲で所要時間を見積もることをお勧めします。

クエリの例 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のデータエンティティをエクスポート

ステップ

設定

クエリの例 config

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

ステップ

設定

クエリの例 python

まずはここから

請求の遅延を解消：受注から入金までの請求プロセスを今すぐ最適化