> 継続的なプロセス改善 > 購買から支払いまで請求書処理 > Microsoft Dynamics 365 > データテンプレート

貴社の購買から支払いまで - 請求書処理データテンプレート

Microsoft Dynamics 365

購買から支払いまで - 請求書処理属性 (23) 購買から支払いまで - 請求書処理アクティビティ (14) 抽出ガイド (4)

貴社の購買から支払いまで - 請求書処理データテンプレート

このテンプレートは、Microsoft Dynamics 365における「購買から支払いまで」の請求書処理を分析するために必要な必須データを抽出するための明確なガイドを提供します。収集すべき重要な属性、追跡すべき主要なアクティビティ、およびデータ抽出のための実用的なガイダンスを概説します。このリソースを使用して、包括的なプロセス分析と最適化に必要なすべての情報を確実に収集してください。

詳細な分析のために収集推奨される属性
請求書処理ライフサイクル全体で追跡すべき主要なアクティビティ
Microsoft Dynamics 365からのデータ抽出に関するガイダンス

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

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

購買から支払いまで - 請求書処理属性

これらは、「購買から支払いまで」の請求書処理を包括的に分析するために、イベントログに含めることを推奨されるデータフィールドです。

5 必須 7 推奨 11 任意

	名前	説明
	アクティビティ名 ActivityName	請求書処理ライフサイクル内の特定の時点`で`発生した特定のビジネスイベントまたはタスクの名称。
説明アクティビティ名は、「請求書登録済み」、「承認のために請求書が送信されました」、または「支払い実行済み」などの、請求書処理における特定のステップまたはステータス変更を記述します。このデータは、プロセスマップの構築とイベントの順序を理解するために不可欠です。この属性を分析することで、プロセスフローが明らかになり、共通のパスウェイが特定され、逸脱やボトルネックが浮き彫りになります。承認から記帳までの期間など、アクティビティ間のサイクルタイムを計算`し、`却下や支払いブロックなどの特定のイベントの頻度を測定するために使用されます。その重要性プロセスマップのステップを定義し、プロセスフローの可視化や、異なるアクティビティ間の移行分析を可能にします。取得元この属性は通常、請求書処理に関連するさまざまなDynamics 365テーブル内のステータスフィールド、トランザクションタイプ、または変更ログエントリの組み合わせから導出されます。例承認のために請求書送信済みマッチングの不一致を検出支払い実行
	イベント日時 EventTime	特定のアクティビティまたはイベントが発生した正確なタイムスタンプです。
説明イベントタイム、つまりタイムスタンプは、アクティビティが発生した正確な日時を記録します。これはイベントログの重要な要素であり、アクティビティを正しく順序付けし、期間を計算するために必要な時系列を提供します。分析において、このタイムスタンプはすべての時間関連メトリックの基礎となります。アクティビティの期間、異なるステップ間のサイクルタイム（例: 承認時間）、および各請求書の総エンドツーエンド処理時間を計算するために使用されます。また、経時的なトレンド分析も可能にします。その重要性このタイムスタンプは、イベントの順序付け`、`すべてのサイクルタイムと期間の計算`、`およびプロセスボトルネックの特定に不可欠です。取得元これは、VendInvoiceInfoTable、VendTrans、またはワークフロー履歴テーブルなどのテーブル内のcreatedDateTimeやmodifiedDateTimeフィールドといった、複数のテーブルにわたるさまざまな日付/時刻フィールドから取得されます。例 2023-04-15T09:00:12Z2023-05-20T14:30:00Z2023-06-01T11:05:45Z
	請求書番号 InvoiceNumber	各仕入先請求書の一意の識別子であり、そのライフサイクルを追跡するための主要なケースIDとして機能します。
説明請求書番号は、単一の仕入先請求書に関連するすべての`アクティビティ`をリンクする一意のキーです。受領と登録からマッチング、承認、最終支払いまでの請求書のジャーニーのエンドツーエンドの追跡を可能にします。プロセスマイニング分析において、この属性は基本的です。これはケースを定義`し、`各請求書のプロセスフローの再構築を可能にします。これにより、総サイクルタイムの計算、プロセスバリアントの特定、および請求書固有の特性と結果の分析が可能になります。その重要性これは、すべての関連イベントを接続する不可欠なケースIDであり、個々の請求書の全ライフサイクルを分析することを可能にします。取得元これは通常、VendInvoiceInfoTableのような主要な仕入先請求書テーブルのNumフィールドにあります。例 INV-10056773245-AUS-001-98432
	ソースシステム SourceSystem	イベントデータが抽出された元システムです。
説明この属性は、アクティビティデータが発生したソースアプリケーションを識別します。このプロセスの場合、通常「Microsoft Dynamics 365」になります。外部OCRやキャプチャソリューションのような複数のシステムがある環境では、このフィールドはプロセスの各ステップがどこで発生するかを区別するのに役立ちます。データリネージが明確であることを保証`し、`データ抽出の問題のトラブルシューティングに役立ちます。その重要性データソースに関する重要なコンテキストを提供し、データの検証やプロセスのシステムランドスケープの理解に役立ちます。取得元これは静的な値「Microsoft Dynamics 365」であり、データ変換中にデータセットの発生元をラベル付けするために追加されます。例 Microsoft Dynamics 365
	最終データ更新 LastDataUpdate	このプロセスのデータがソースシステムから最後に更新された時刻を示すタイムスタンプ。
説明この属性は、データセットがMicrosoft Dynamics 365から最後に抽出され更新された日時を記録します。通常、単一のデータロード内のすべてのレコードで同じです。この情報は、ユーザーが分析しているデータの鮮度を理解するために不可欠です。プロセスインサイトの現在の状況に関するコンテキストを提供`し、データ`の更新スケジュールの管理とデータパイプラインの検証に不可欠です。その重要性ユーザーにデータのタイムリーさを通知し、分析がどれくらい最近のものか、次のデータ更新がいつ予定されているかを確認できます。取得元このタイムスタンプは、データ抽出またはETLプロセスによって、実行時にデータセット上に生成されスタンプされます。例 2023-10-27T02:00:00Z2023-10-28T02:00:00Z
	ユーザー User	そのアクティビティを実行した担当者のユーザーIDまたは氏名を示します。
説明この属性は、特定のプロセスステップの実行を担当する従業員またはシステムユーザーを識別します。自動化されたステップの場合、これはシステムまたはサービスアカウントである可能性があります。ユーザーごとにプロセスを分析することは、ワークロードの配分を理解`し、トレーニングニーズ`を特定`し、`個人`またはチーム`間のパフォーマンスを比較するのに役立ちます。手戻りループ（作業がユーザー間でやり取りされる場所）を分析`し、`異なるユーザーが同じタスクを完了する方法のバリエーションを理解するために不可欠です。その重要性ユーザーまたはチームごとのパフォーマンスやワークロードの分析を可能にし、自動化レベルや手戻りの原因特定に役立ちます。取得元 createdbyやmodifiedbyフィールドなど、トランザクションまたはワークフロー履歴テーブルのユーザーIDフィールドから取得されます。この情報はワークフロー追跡テーブルに含まれている場合があります。例 j.doea.smithAX_Admin
	仕入先コード VendorNumber	請求書を提出したベンダーまたはサプライヤーの一意の識別子。
説明ベンダー番号は、マスターデータ内でサプライヤーを一意に識別するコードです。請求書トランザクションを特定のベンダーにリンク`し、ベンダー中心`の分析を可能にします。この属性は、ベンダーごとにプロセスデータをセグメント化するために不可欠です。「どのベンダーが最も長い承認時間を持っていますか？」や「特定のベンダーでマッチングの不一致はより一般的ですか？」といった質問に答えるのに役立ちます。ベンダーごとのパフォーマンスを分析することで、サプライヤーコラボレーションとプロセス改善の機会を発見できます。その重要性ベンダーごとのフィルターと根本原因分析を可能にし、特定のサプライヤーに関連するパフォーマンス問題やパターンを識別するのに役立ちます。取得元これは通常、VendInvoiceInfoTableのような仕入先請求書テーブルのヘッダーにあり、VendTableの主要な仕入先マスターデータにリンクされています。例 V-1001V-2050V-8342
	支払期日 PaymentDueDate	合意された支払条件に従い、請求書が支払われるべき期日。
説明支払期日は、請求書日付とベンダーの支払条件に基づいて計算されます。支払いに関する契約上の期限を表します。この日付は、財務パフォーマンスとベンダー関係管理を測定するために重要です。実際の「支払い実行済み」日付と比較することで、「期日内支払い率」KPIを計算するために使用されるベースラインです。これを分析することは、遅延支払いの原因となるシステム的な問題を特定するのに役立ち、ベンダー関係の損傷や早期支払い割引の逸失につながる可能性があります。その重要性これは期日内支払いパフォーマンスを測定するためのベンチマークであり、財務健全性とベンダー関係にとって重要なKPIです。取得元この日付は、システムによって計算され、VendTransのような仕入先トランザクションテーブルに、請求書日付と支払条件に基づいて保存されることがよくあります。例 2023-05-152023-06-302023-07-20
	発注書番号 PurchaseOrderNumber	請求書が関連する購買発注書（PO）の識別子。
説明購買発注書番号は、請求書を元の調達文書にリンクします。これは、請求書、PO、および品目受領間の2ウェイまたは3ウェイマッチングを含むプロセスにとって重要です。この属性により、異なるプロセスパスをたどることが多いPO連動請求書とPO非連動請求書の分析が可能になります。マッチングプロセスの有効性を理解`し、`マッチングの不一致を調査`し、`PO連動請求書のストレートスルー処理率を測定するための鍵となります。その重要性 PO連動の請求書とPO非連動の請求書を区別することで、プロセス変動の主な要因を特定し、マッチング分析に不可欠な情報を提供します。取得元例えばVendInvoiceInfoTableのような請求書ヘッダーテーブルにあり、多くの場合PurchIdのようなフィールドに格納されています。例 PO-001234PO-005678PO-009101
	終了日時 EndTime	特定のアクティビティまたはイベントが完了したことを示す正確なタイムスタンプ。
説明 EndTimeはアクティビティが完了した時間を記録します。StartTime（EventTime）と組み合わせることで、個々のステップが完了するのにかかった時間を正確に計算できます。この属性は、各アクティビティの「ProcessingTime」を計算するために不可欠であり、パフォーマンス分析の主要なメトリックです。プロセス内でどのステップが最も時間を消費しているかを正確に特定するのに役立ち、的を絞った改善努力を可能にします。例えば、手動コーディングや承認ステップの正確な期間を測定できます。その重要性アクティビティ処理時間の直接計算を可能にし、プロセス内で最も時間がかかるステップを特定するための基本となります。取得元 StartTimeと同様に、これは様々な日付/時刻フィールドから取得されます。一部のアクティビティでは、次のアクティビティのStartTimeとなる場合があります。その他のケースでは、特定の「完了日時」のタイムスタンプとなることがあります。例 2023-04-15T09:15:20Z2023-05-20T18:00:00Z2023-06-01T11:05:45Z
	請求書ステータス InvoiceStatus	データ抽出時の請求書の現在のステータス。
説明請求書ステータスは、請求書ライフサイクル内の現在の状態、例えば「承認保留中」、「承認済み」、「記帳済み」、または「支払い済み」を示します。これは請求書の進捗状況のスナップショットを提供します。この属性は、主に現在のワークロードとバックログを示す運用ダッシュボードの作成に使用されます。マネージャーがプロセスの各段階にいくつの請求書があるかを理解するのに役立ち、リソース割り当てと運用モニタリングをサポートします。「請求書処理スループット＆ステータス」ダッシュボードにとって重要です。その重要性すべての請求書の現在の状態をビューで提供し、運用モニタリング、ワークロード管理、および現在のボトルネックの特定に不可欠です。取得元これは通常、VendInvoiceInfoTableのような主要な請求書テーブルのステータスフィールドから導出されます。例承認待ち転記済み支払い済み
	請求金額 InvoiceAmount	請求書の合計金額。
説明この属性は、仕入先請求書に記載された総支払い金額を表します。これは各ケースにとって基本的な財務データポイントです。請求金額は、セグメンテーションと分析に広く使用されます。高額な請求書が異なる`、`より厳格な承認プロセスをたどるか、または処理に時間がかかるかを明らかにできます。ダッシュボードでも、金額ごとの請求書ボリュームを分析するために使用され、分析対象の総支出を理解するために集計できます。その重要性財務価値に基づく分析を可能にし、高額な請求書に対するプロセス改善の取り組みを優先し、コストドライバーを理解するのに役立ちます。取得元請求書ヘッダーテーブル（例:`VendInvoiceInfoTable`）の`InvoiceAmount`や`Amount`のようなフィールドにあります。例 1500.00250.7512500.50
	不一致タイプ MatchingDiscrepancyType	請求書とPOマッチングプロセス中に見つかった不一致の種類を分類します。
説明 2ウェイまたは3ウェイマッチング中に不一致が発生した場合、この属性は問題の性質を特定します。例えば、「価格不一致」、「数量不一致」、または「品目受領の欠落」などです。このデータは、「マッチング不一致解決時間」ダッシュボードの中心となります。異なる不一致タイプの頻度を分析することで、企業はマッチング失敗の根本原因を特定できます。例えば、頻繁な価格不一致は古いマスターデータの問題を示唆する可能性があり、数量不一致は配送問題を示す可能性があります。その重要性マッチングの失敗を分類し、根本原因分析を可能にすることで、不一致の発生率を減らし、ストレートスルー処理を改善します。取得元これは専用のマッチングまたは例外ログテーブルに保存されるか、ステータスメッセージまたはワークフローコメントから導出される必要がある場合があります。例価格不一致数量不一致検収未計上
	会社コード CompanyCode	請求書を処理する組織内の法的エンティティまたは会社の識別子。
説明会社コードは、請求書に対して財務責任を負う特定の法的エンティティを表します。複数企業組織では、これは財務セグメンテーションにとって重要なデータポイントです。この属性により、異なる法的エンティティ間でプロセス分析をフィルタリングまたは比較できます。プロセスパフォーマンス、ポリシー、またはボトルネックがグループ内の特定の企業に固有のものであるかを明らかに`し、`ローカライズされたプロセス改善イニシアチブをサポートします。その重要性法的エンティティごとにプロセス分析をセグメント化することが可能になり、大規模な複数企業組織にとって重要です。取得元これはDynamics 365のほとんどの財務テーブルにある標準フィールドで、しばしばDataAreaIdと呼ばれます。例 USMFDEMFGBSI
	処理時間 ProcessingTime	単一のアクティビティの期間。その終了時刻と開始時刻の差として計算されます。
説明処理時間（Processing Time）は、特定のタスクに費やされたアクティブな時間を測定します。イベントのStartTimeからそのEndTimeを差し引くことで計算されます。これはアクティビティ期間とも呼ばれます。このメトリックはパフォーマンス分析の基本です。アクティビティ間の待機時間とは対照的に、どの特定のアクティビティが最も時間を消費しているかを特定するのに役立ちます。これにより、手動コーディングを高速化するためのより良いトレーニングの提供や、実行が遅いシステムステップの最適化など、焦点を絞った改善が可能になります。その重要性アクティビティの実際の作業期間を測定し、最適化や自動化に適した非効率なタスクを特定するのに役立ちます。取得元これはソースシステムのフィールドではありません。データ変換中に、EndTime - StartTimeの式を使用して計算されます。例 PT1H30MP2DT4HPT5M15S
	却下理由 RejectionReason	承認者が請求書を却下した理由。
説明承認ワークフローで請求書が却下される際、承認者は通常その理由を提示します。この属性は、事前定義されたコードまたは自由記述テキストでその説明を記録します。これは「請求書却下分析」ダッシュボードにとって極めて重要な属性です。「注文書番号の誤り」、「重複請求書」、「価格不一致」といった却下の根本原因を理解するための定性的な洞察を提供します。これらの理由を分析することで、却下率を削減するための対策を優先的に講じることが可能になります。その重要性請求書が拒否される理由について直接的なインサイトを提供し、手戻りを減らし、ファーストタイムライト率を向上させるための的を絞った行動を可能にします。取得元ワークフロー処理テーブルのコメントまたは履歴ログで通常見られます。例数量が間違っています重複請求書承認限度額超過
	合計サイクルタイム TotalCycleTime	請求書の受領から支払いまでの、単一の請求書処理におけるエンドツーエンドの総期間。
説明総サイクルタイムは、請求書がプロセス内で費やす全期間を測定します。特定の請求書番号について、最初のアクティビティ（例：「請求書登録済み」）から最後のアクティビティ（例：「支払い実行済み」）までの時間差として計算されます。これは、全体的なプロセス効率を測定するための主要なKPIです。パフォーマンスのハイレベルビューを提供`し、「`請求書エンドツーエンドサイクルタイム」ダッシュボードで使用されます。このメトリックの傾向を分析`し、`ベンダーや金額などの属性でセグメント化することは、広範な改善機会を特定するのに役立ちます。その重要性全体的なプロセス速度と効率性の主要なハイレベルKPIを表し、各請求書のパフォーマンスを要約します。取得元これは、プロセスマイニングツール内のケースレベルで、またはデータ準備中に計算されます。各CaseIdの最初と最後のイベントタイムスタンプ間の時間差です。例 P15DP22DT5H30MP7D
	支払ブロック理由 PaymentBlockReason	請求書に支払いブロックが適用された理由を説明する理由コード。
説明支払いブロックは、請求書の支払いを阻止します。この属性はブロックの理由を捕捉し、通常はユーザーが選択した「係争中の料金」や「商品受領待ち」のような標準化されたコードです。この属性は、「支払いブロックの頻度と期間」ダッシュボードにとって不可欠です。支払いブロックの最も一般的な理由を分析することで、P2Pプロセスにおける根本的な問題を特定できます。これらの根本原因を解決することで、支払い遅延を大幅に削減し、ベンダーとの関係を改善できます。その重要性支払いが意図的に遅延する理由を説明し、支払いブロックの原因となる上流の問題を特定し、解決するのに役立ちます。取得元これは通常、仕入先トランザクションまたは請求書レコード上のフィールドであり、しばしば支払いブロックステータスに関連します。VendTransのようなテーブルで探してください。例品質に関する紛争クレジットメモ待ち手動ブロック
	支払条件 PaymentTerms	ベンダーとの支払条件に関する合意。「Net 30」や「2% 10, Net 30」など。
説明支払条件は、ベンダーへの支払いに関する合意された条件を定義し、期間や潜在的な割引を含みます。この情報は通常、ベンダーマスターデータまたは購買発注書から取得されます。この属性は、支払期日と期日内支払い率KPIにとって重要なコンテキストを提供します。特定の支払条件が遅延支払いと関連しているかどうかを分析することで、業務上の課題を明らかにできます。また、財務計画や運転資金の効率的な管理にも役立ちます。その重要性支払期日に関するコンテキストを提供し、支払いタイミングと割引取得率が財務に与える影響を分析するのに役立ちます。取得元この情報はベンダーマスター（VendTable）に保存され、VendInvoiceInfoTableのようなトランザクションテーブルにコピーされます。例支払条件：正味30日支払条件：正味60日2% 10, Net 30
	期日内支払いか IsOnTimePayment	請求書が期日通りに、または期日前に支払われたかどうかを示す計算済みのフラグです。
説明このブール型の属性は、「支払い実行済み」アクティビティのタイムスタンプと「支払期日」を比較することによって導出されます。支払い日が期日以下の場合、値はtrue`、`それ以外の場合はfalse`です。この属性は、「期日内支払い率」KPIと「支払条件コンプライアンス」ダッシュボードを直接サポートします。各請求書に対して明確なバイナリ結果を提供することで分析を簡素化`し、`遅延支払いをフィルタリング`し、`ベンダー、部署、または国ごとにその根本原因を調査することを容易にします。その重要性支払い条件へのコンプライアンスを直接測定し、オンタイム支払い率KPIおよび関連分析の計算を簡素化します。取得元この属性はデータ変換レイヤーで計算されます。ロジックは以下の通りです。（「支払い実行済み」アクティビティのタイムスタンプ） <= （支払期日）。例 truefalse
	自動化 IsAutomated	アクティビティがシステムによる自動実行か、人手による実行かを示すフラグ。
説明このブール型の属性（true/false）は、システム実行イベントと手動ユーザー`タスク`を区別します。例えば、請求書マッチングステップは自動化されている可能性がありますが、不一致処理は手動です。この属性を分析することは、プロセスにおける自動化のレベルを理解する上で重要です。自動化イニシアチブの成功を測定`し、`残存する手動ボトルネックを特定`し、`効率を向上させ、エラーを削減するためのさらなる自動化の機会を浮き彫りにするのに役立ちます。その重要性プロセスにおける自動化のレベルを測定し、手動のボトルネックと効率向上機会を特定するのに役立ちます。取得元これは通常、「ユーザー」属性に基づいて導出されます。ユーザーが既知のシステムまたはサービスアカウントである場合、このフラグはtrueに設定されます。例 truefalse
	請求通貨 InvoiceCurrency	請求金額の通貨コード（例: USD, EUR）。
説明請求書通貨は、請求金額が建てられている通貨を指定します。これは、異なる国からのサプライヤーと取引する多国籍企業にとって重要です。この属性は、請求金額に必要なコンテキストを提供し、特にグローバルオペレーションにおいてフィルタリングやレポート作成に使用されます。財務値が正しく解釈されることを保証し、通貨固有の分析や標準報告通貨への変換を可能にします。その重要性財務金額に関する不可欠なコンテキストを提供し、異なる地域間の請求書価値の正確な解釈と分析を可能にします。取得元例えば、VendInvoiceInfoTableのCurrencyCodeフィールドなど、請求書ヘッダーテーブルの請求金額とともに配置されます。例 USDEURGBP
	部署 Department	請求書費用が割り当てられるコストセンターまたは部署。
説明部署は、請求書の費用を担当する事業単位またはコストセンターを特定します。これは通常、請求書コーディングアクティビティ中に決定されます。部署ごとにプロセスを分析することは、支出、承認時間、およびコンプライアンスにおける部署間の違いを理解するために重要です。どの部署が最も多くの請求書例外や最も長い承認サイクルを持っているかを特定するのに役立ち、的を絞ったコミュニケーションとトレーニングの基礎を提供します。その重要性部署ごとのコストおよびプロセス分析を可能にし、組織全体のパフォーマンスとコンプライアンスの変動を強調します。取得元請求書明細またはヘッダーにリンクされた財務ディメンションから取得されます。これには、ディメンション関連のデータ構造をクエリする必要があります。例営業マーケティングIT運用

必須推奨任意

購買から支払いまで - 請求書処理アクティビティ

仕入先請求書処理ワークフローを正確に可視化・分析するため、イベントログに記録すべき主要ステップとマイルストーンは次のとおりです。

6 推奨 8 任意

	アクティビティ	説明
	承認のために請求書送信済み	このアクティビティは、レビューと承認のために請求書がワークフローに正式に提出されたことを示します。Dynamics 365のワークフローエンジンは、この提出イベントを明示的に記録します。
その重要性これは承認サイクル全体を測定するための出発点です。承認プロセスが開始される前に請求書がどれだけ待機するかを特定`し、`承認関連KPIのトリガーとなります。取得元これは、請求書がワークフローに提出されたときに、ワークフロー履歴テーブル（例：WorkflowTrackingStatusTable）にログとして記録される明示的なイベントです。取得ワークフロー履歴におけるワークフロー提出レコードの作成タイムスタンプ。イベントタイプ explicit
	支払い実行	これは最後の`アクティビティ`であり、支払いを作成`し、`請求書を決済する支払仕訳帳の記帳を表します。これは、請求書ライフサイクルを閉じる明示的なトランザクションイベントです。
その重要性このアクティビティは、請求書から支払いまでのプロセスの成功した終了を示します。「期日内支払い率」と総エンドツーエンドサイクルタイムを測定するための基礎となります。取得元これは、支払仕訳帳の記帳からキャプチャされた明示的なイベントです。決済情報はVendSettlementのようなテーブルに記録され、支払いを請求書にリンクします。取得仕入先取引を決済する支払仕訳帳のタイムスタンプを記帳します。イベントタイプ explicit
	請求書が購買発注書に一致	請求書の詳細が購買発注書および品目受領情報と一致する、マッチングプロセスの成功した完了を表します。このイベントは、請求書のマッチングステータスが「合格」に更新されたときに推定されます。
その重要性成功したマッチングは、PO連動請求書にとって重要なマイルストーンであり、支払い前の請求の有効性を確認します。マッチング効率と自動化率の追跡に不可欠です。取得元仕入先請求書ヘッダーまたは明細行（例:`VendInvoiceInfoTable`）のマッチングステータスフィールドが「Passed」または「Successfully Matched」値に更新されたことから推測されます。取得請求書マッチング検証詳細におけるステータス変更が「合格」になったときのタイムスタンプ。イベントタイプ inferred
	請求書仕訳計上済み	これは、承認された請求書が総勘定元帳に記録され、負債を作成する正式な会計イベントです。これは、システムにおける明示的なトランザクションイベントです。
その重要性記帳は支払い前の最終ステップであり、重要な財務コントロールポイントです。「請求書承認済み」から「請求書記帳済み」までの時間は、最終的な会計ステップの効率を測定します。取得元これは、VendTransのようなテーブルにおける記帳済み仕入先トランザクション、および関連するGeneralJournalEntryとLedgerEntryレコードの作成からキャプチャされた明示的なイベントです。取得仕入先トランザクションテーブル（VendTrans）におけるレコードの作成タイムスタンプ。イベントタイプ explicit
	請求書承認済み	ワークフロー内での請求書の最終的かつ成功した承認を表し、記帳と支払いを許可します。これは、ワークフローエンジンが完了時にログに記録する明示的なイベントです。
その重要性これは承認プロセスを完了させる重要なマイルストーンです。「承認のために請求書が送信されました」からこのイベントまでの時間は、承認効率の主要な測定値であり、ボトルネックを特定するのに役立ちます。取得元これは、ワークフローステータスが「承認済み」に変更されたときに、ワークフロー履歴テーブル（例：WorkflowTrackingStatusTable）にログとして記録される明示的なイベントです。取得ワークフロー履歴における「承認済み」ステータスエントリのタイムスタンプ。イベントタイプ explicit
	請求書登録	これはシステムへの請求書の初期入力であり、詳細が完全に処理される前にプレースホルダーレコードを作成します。このアクティビティは、仕入先請求書登録ジャーナルに新しいレコードが作成されたときにキャプチャされます。
その重要性このアクティビティは、請求書処理ライフサイクルの公式な開始を示します。この時点からの時間を分析することで、総処理期間を測定`し、`初期段階の遅延を特定するのに役立ちます。取得元これは、仕入先請求書登録簿にレコードが作成された時点からキャプチャされた明示的なイベントであり、通常はVendInvoiceRegisterJournalTableまたは同様の保留請求書テーブルにあります。取得仕入先請求書登録仕訳におけるレコードの作成タイムスタンプ。イベントタイプ explicit
	マッチングの不一致を処理済み	以前特定されたマッチングの不一致が解決され、請求書が処理を進められるようになったことを示します。「失敗」したマッチングステータスの請求書が正常に再マッチングされるか、手動で上書きされた場合に推定されます。
その重要性このアクティビティは、不一致解決サブプロセスを完了させます。「マッチングの不一致を検出」からこのイベントまでの時間は、解決効率を測定するための主要なKPIです。取得元同じ請求書に対する「マッチング不一致発見」イベントの後に発生する成功したマッチングイベント（「請求書が購買発注書に一致」）によって推測されます。取得 'Failed'ステータス`タイムスタンプ`の後に続く「Passed」マッチングステータス`タイムスタンプ`を識別します。イベントタイプ inferred
	マッチングの不一致を検出	このアクティビティは、請求書、購買発注書、または品目受領間の不一致により、請求書マッチングプロセスが失敗したときに発生します。請求書マッチングステータスが「失敗」または「不一致」に設定されたときにキャプチャされます。
その重要性不一致がいつ、なぜ発生するかを特定することは、「マッチング不一致率」KPIにとって重要です。このアクティビティは解決プロセスの開始を示し、しばしば大幅な遅延の原因となります。取得元仕入先請求書（例:`VendInvoiceInfoTable`）のマッチングステータスフィールドが「Failed」値に更新されたことから推測されます。失敗の理由も、しばしばログに記録されます。取得マッチング中のステータス変更が「失敗」または「不一致」になったときのタイムスタンプ。イベントタイプ inferred
	支払いスケジュール設定	このアクティビティは、記帳済み請求書が支払い提案または支払仕訳帳に含まれる`が、`支払いが実行される前に発生します。これは、支払仕訳帳の明細を作成する明示的なアクションです。
その重要性これは買掛金から財務業務への移行を示します。このステップを分析することで、請求書記帳から支払い開始までの遅延が明らかになる可能性があります。取得元これは、記帳済み仕入先トランザクションを決済する支払仕訳帳（LedgerJournalTrans）での明細の作成からキャプチャされた明示的なイベントです。取得請求書を参照する支払い仕訳明細行の作成タイムスタンプ。イベントタイプ explicit
	支払いブロックが解除されました	支払い保留が解除され、請求書が支払いスケジューリングに進むことを表します。これは、支払いブロックフィールドがクリアされるか、ブロック解除済みの状態に変更されたときにキャプチャされます。
その重要性支払い保留の原因となっている問題を解決するのにかかる時間を測定します。ブロックが設定されてから解除されるまでの期間が長い場合、非効率な問題解決プロセスを示唆します。取得元転記された仕入先トランザクション（VendTrans）における支払い保留またはブロックフィールドをクリアする変更から推測されます。変更ログはタイムスタンプを提供できます。取得仕入先トランザクションの支払いブロックフィールドをクリアする更新のタイムスタンプ。イベントタイプ inferred
	支払ブロック設定	このアクティビティは、請求書に保留が設定され、支払いが停止されたときに発生します。これは、記帳済み請求書レコードの支払いブロックまたは保留ステータスフィールドの変更によってキャプチャされます。
その重要性支払いブロックは遅延支払いの主な原因です。いつ、なぜ設定されるのかを分析することは、期日内支払いパフォーマンスとベンダー関係を改善するために不可欠です。取得元転記された仕入先トランザクション（VendTrans）における支払い保留またはブロックフィールドへの変更から推測されます。変更ログはタイムスタンプをキャプチャするために使用できます。取得仕入先トランザクションに支払いブロックフィールドを設定する更新のタイムスタンプ。イベントタイプ inferred
	請求書コード化済み	このアクティビティは、総勘定元帳勘定の配賦が請求書明細に割り当てられたことを示します。通常、請求書にリンクされた元帳勘定配賦の作成または確定によって推定されます。
その重要性コーディングは財務の正確性にとって重要なステップです。請求書のコーディングにかかる時間を測定することで、会計審査プロセスのボトルネックを特定し、「データキャプチャからコーディングまでの平均時間」KPIをサポートします。取得元保留中の仕入先請求書に関連する会計配賦テーブル（例:`AccountingDistribution`）におけるレコードの作成と検証から推測されます。取得請求書の会計配賦が保存され検証されたときのタイムスタンプ。イベントタイプ inferred
	請求書データ取り込み完了	請求書のヘッダーおよび明細データを含むデータ入力が完了し、マッチングまたは承認のために提出される前の状態を表します。これは、請求書レコードが「新規」または「登録済み」ステータスから「処理準備完了」ステータスに移行したときに推定されることがよくあります。
その重要性このアクティビティを追跡することは、手動または自動（OCR）であるかにかかわらず、データ入力プロセスの効率を測定するのに役立ちます。ここでの遅延は、プロセス全体に連鎖的に影響を与える可能性があります。取得元保留中の仕入先請求書レコード（例:`VendInvoiceInfoTable`）のステータス変更から推測されます。イベントは、すべての必須フィールドが入力され、請求書が次のステップの準備ができたときに発生します。取得データ入力完了を示す保留中の請求書テーブルのステータス変更を検出します。イベントタイプ inferred
	請求書却下	承認者が請求書を却下し、プロセスを停止させ、通常は修正のために返送したことを示します。ワークフローエンジンはこの却下イベントを明示的にログに記録します。
その重要性却下を追跡することは、手戻りを定量化`し、`誤ったコーディングやポリシー違反など、失敗の一般的な理由を特定するのに役立ちます。これは「請求書却下率」KPIを直接サポートします。取得元これは、ワークフローステータスが「却下済み」または「キャンセル済み」に変更されたときに、ワークフロー履歴テーブル（例：WorkflowTrackingStatusTable）にログとして記録される明示的なイベントです。取得ワークフロー履歴における「却下済み」ステータスエントリのタイムスタンプ。イベントタイプ explicit

推奨任意

抽出ガイド

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

ステップ

データ管理ワークスペースへ移動: Microsoft Dynamics 365 Financeにログインします。検索バーを使用してデータ管理ワークスペースを検索し、移動します。
新規エクスポートプロジェクトの作成: ワークスペース内で、Exportタイルを選択して新しいデータエクスポートプロジェクトを作成します。プロジェクトにProcessMind_Invoice_Processing_Exportのような分かりやすい名前を付けます。
データプロジェクトの定義: 新しいプロジェクトのGeneralタブで、Data formatを指定します。CSVは一般的に使用され、推奨される形式です。必要に応じて他のパラメーターを設定します。
必要なデータエンティティの追加: Selected entitiesセクションに移動し、Add entityをクリックします。以下のコアエンティティを一つずつ検索して追加します。それぞれのターゲットデータ形式を指定する必要があります。
- VendInvoiceInfoTableEntity (仕入先請求書ヘッダー)
- VendInvoiceTransEntity (仕入先請求書明細行)
- VendInvoiceRegisterHeaderEntity (請求書登録仕訳ヘッダー)
- WorkflowTrackingStatusTableEntity (ワークフロー履歴)
- AccountingDistributionEntity (総勘定元帳の配賦)
- VendInvoiceJour (転記済み仕入先請求書)
- VendTrans (仕入先トランザクション、支払いブロック用)
- LedgerJournalTransVendPaymEntity (仕入先支払い仕訳明細行)
- VendSettlement (仕入先決済トランザクション)
フィルターの適用: 各エンティティについて、データスコープを制限するためにフィルターを適用することが重要です。エンティティを選択し、Filterをクリックします。最低限、Company（法的エンティティ）と、CREATEDDATETIMEやINVOICEDATEなどの関連する日付フィールドで特定の日付範囲をフィルターします。初期分析の一般的な範囲は、過去3〜6ヶ月です。
エンティティマッピングの構成: 各エンティティについて、ソースからターゲットへのマッピングを確認します。最終的なイベントログに必要なすべてのフィールドがエクスポートに含まれていることを確認します。この段階では、複雑なマッピング変更は通常必要ありません。
エクスポートジョブの実行: すべてのエンティティが追加され、フィルターされたら、アクションペインのExportをクリックしてジョブを開始します。すぐに実行することも、システム負荷を最小限に抑えるためにオフピーク時間にスケジュールすることもできます。
エクスポートされたデータのダウンロード: エクスポートジョブが正常に完了したら、ジョブ履歴に移動します。そこから、エクスポートされたデータパッケージをダウンロードできます。これには各データエンティティの個別のファイルが含まれます。
データをイベントログに変換: エクスポートされたファイルはエンティティのスナップショットであり、統合されたイベントログではありません。これらのファイルを処理および結合するには、データベース、Pythonスクリプト、Power Queryなどの外部ツールを使用する必要があります。queryセクションにある概念的なクエリは、この変換の完全なロジックを提供します。
変換ロジックの実行: エクスポートされたCSVファイルを`選択した変換環境にロードします。提供された変換クエリを実行すると、すべてのソースファイルからデータが統合され、ビジネスアクティビティごとに1行を持つ単一のイベントログテーブルが作成されます。
最終化とアップロード: 最終的に変換されたデータを単一のCSVファイルにエクスポートします。列ヘッダーがInvoiceNumber、ActivityName、EventTimeなどの要件と一致していることを確認します。このファイルはProcessMindにアップロードする準備ができています。

設定

データエンティティ: 設定の中心は、請求書ライフサイクルをカバーする適切なエンティティセットを選択することです。主要なエンティティには、VendInvoiceInfoTableEntity、VendInvoiceJour、WorkflowTrackingStatusTableEntityなどが含まれます。
エクスポートデータ形式: 後続の変換ステップで処理しやすいため、ターゲットデータ形式としてCSVを選択してください。
会社によるフィルタリング: 分析対象の特定の法的エンティティ（会社）で各データエンティティをフィルターし、無関係なデータを取得しないようにすることが重要です。
日付範囲フィルタリング: VendInvoiceInfoTableEntityやVendInvoiceJourなど、関連するすべてのエンティティに、作成日または転記日に基づいた一貫した日付範囲フィルターを適用してください。データ量を管理するために、直近の期間（例：過去6ヶ月間）から開始することをお勧めします。
フルプッシュ対インクリメンタル: 最初の抽出では、フルプッシュを実行してください。その後の更新では、前回の実行以降に変更されたデータのみを取得するインクリメンタルエクスポートを設定でき、処理時間を短縮できます。
前提条件: エクスポートを実行するユーザーは、Dynamics 365で適切なセキュリティロール（通常はデータ管理管理者、または必要なデータエンティティへのアクセス権を持つ類似のロール）を持っている必要があります。

a クエリ例 config

/*
-- This is a conceptual query to be executed in a database or data transformation tool.
-- The tables referenced (e.g., 'VendInvoiceInfoTableEntity') are the CSV files exported from Dynamics 365.
-- Replace '[Your_Source_System_Name]' with the actual source system identifier.
*/

-- 1. Invoice Registered
SELECT
    h.INVOICENUMBER AS "InvoiceNumber",
    'Invoice Registered' AS "ActivityName",
    h.CREATEDDATETIME AS "EventTime",
    h.CREATEDBY AS "User",
    h.INVOICEACCOUNT AS "VendorNumber",
    NULL AS "PurchaseOrderNumber",
    h.INVOICEAMOUNT AS "InvoiceAmount",
    NULL AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    h.CREATEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendInvoiceRegisterHeaderEntity h

UNION ALL

-- 2. Invoice Data Captured
SELECT
    i.INVOICENUMBER AS "InvoiceNumber",
    'Invoice Data Captured' AS "ActivityName",
    i.CREATEDDATETIME AS "EventTime",
    i.CREATEDBY AS "User",
    i.VENDORACCOUNT AS "VendorNumber",
    i.PURCHASEORDERNUMBER AS "PurchaseOrderNumber",
    i.INVOICEAMOUNT AS "InvoiceAmount",
    'Pending' AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    i.CREATEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendInvoiceInfoTableEntity i

UNION ALL

-- 3. Invoice Coded
SELECT
    i.INVOICENUMBER AS "InvoiceNumber",
    'Invoice Coded' AS "ActivityName",
    MIN(a.CREATEDDATETIME) AS "EventTime",
    MIN(a.CREATEDBY) AS "User",
    i.VENDORACCOUNT AS "VendorNumber",
    i.PURCHASEORDERNUMBER AS "PurchaseOrderNumber",
    i.INVOICEAMOUNT AS "InvoiceAmount",
    'Pending' AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    MIN(a.CREATEDDATETIME) AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendInvoiceInfoTableEntity i
JOIN AccountingDistributionEntity a ON i.INVOICENUMBER = a.SOURCEDOCUMENTLINE_INVOICENUMBER
GROUP BY i.INVOICENUMBER, i.VENDORACCOUNT, i.PURCHASEORDERNUMBER, i.INVOICEAMOUNT

UNION ALL

-- 4. Invoice Matched To Purchase Order
SELECT
    i.INVOICENUMBER AS "InvoiceNumber",
    'Invoice Matched To Purchase Order' AS "ActivityName",
    i.MODIFIEDDATETIME AS "EventTime",
    i.MODIFIEDBY AS "User",
    i.VENDORACCOUNT AS "VendorNumber",
    i.PURCHASEORDERNUMBER AS "PurchaseOrderNumber",
    i.INVOICEAMOUNT AS "InvoiceAmount",
    'Matched' AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    i.MODIFIEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendInvoiceInfoTableEntity i
WHERE i.LASTMATCHSTATUS = 'Passed'

UNION ALL

-- 5. Matching Discrepancy Found
SELECT
    i.INVOICENUMBER AS "InvoiceNumber",
    'Matching Discrepancy Found' AS "ActivityName",
    i.MODIFIEDDATETIME AS "EventTime",
    i.MODIFIEDBY AS "User",
    i.VENDORACCOUNT AS "VendorNumber",
    i.PURCHASEORDERNUMBER AS "PurchaseOrderNumber",
    i.INVOICEAMOUNT AS "InvoiceAmount",
    'Discrepancy' AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    i.MODIFIEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendInvoiceInfoTableEntity i
WHERE i.LASTMATCHSTATUS = 'Failed'

UNION ALL

-- 6. Matching Discrepancy Handled (Approximation)
SELECT
    i.INVOICENUMBER AS "InvoiceNumber",
    'Matching Discrepancy Handled' AS "ActivityName",
    i.MODIFIEDDATETIME AS "EventTime",
    i.MODIFIEDBY AS "User",
    i.VENDORACCOUNT AS "VendorNumber",
    i.PURCHASEORDERNUMBER AS "PurchaseOrderNumber",
    i.INVOICEAMOUNT AS "InvoiceAmount",
    'Matched' AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    i.MODIFIEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendInvoiceInfoTableEntity i
WHERE i.LASTMATCHSTATUS = 'Passed' AND i.MODIFIEDDATETIME > i.CREATEDDATETIME

UNION ALL

-- 7. Invoice Sent For Approval, 8. Invoice Approved, 9. Invoice Rejected
SELECT
    w.CONTEXT_INVOICENUMBER AS "InvoiceNumber",
    CASE w.TRACKINGSTATUS
        WHEN 'Submitted' THEN 'Invoice Sent For Approval'
        WHEN 'Completed' THEN 'Invoice Approved'
        WHEN 'Canceled' THEN 'Invoice Rejected'
        ELSE CONCAT('Workflow: ', w.TRACKINGSTATUS)
    END AS "ActivityName",
    w.CREATEDDATETIME AS "EventTime",
    w.USERID AS "User",
    i.VENDORACCOUNT AS "VendorNumber",
    i.PURCHASEORDERNUMBER AS "PurchaseOrderNumber",
    i.INVOICEAMOUNT AS "InvoiceAmount",
    w.TRACKINGSTATUS AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    w.CREATEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM WorkflowTrackingStatusTableEntity w
JOIN VendInvoiceInfoTableEntity i ON w.CONTEXT_RECID = i.RECID AND w.CONTEXT_TABLEID = i.TABLEID
WHERE w.TRACKINGTYPE = 'Approval'

UNION ALL

-- 10. Payment Block Set
SELECT
    v.INVOICENUMBER AS "InvoiceNumber",
    'Payment Block Set' AS "ActivityName",
    v.MODIFIEDDATETIME AS "EventTime",
    v.MODIFIEDBY AS "User",
    v.ACCOUNTNUM AS "VendorNumber",
    NULL AS "PurchaseOrderNumber",
    v.AMOUNT AS "InvoiceAmount",
    'Blocked' AS "InvoiceStatus",
    v.DUEDATE AS "PaymentDueDate",
    v.MODIFIEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendTrans v
WHERE v.BLOCKED = 'Yes'

UNION ALL

-- 11. Payment Block Released
SELECT
    v.INVOICENUMBER AS "InvoiceNumber",
    'Payment Block Released' AS "ActivityName",
    v.MODIFIEDDATETIME AS "EventTime",
    v.MODIFIEDBY AS "User",
    v.ACCOUNTNUM AS "VendorNumber",
    NULL AS "PurchaseOrderNumber",
    v.AMOUNT AS "InvoiceAmount",
    'Open' AS "InvoiceStatus",
    v.DUEDATE AS "PaymentDueDate",
    v.MODIFIEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendTrans v
WHERE v.BLOCKED = 'No' AND v.MODIFIEDDATETIME > v.CREATEDDATETIME

UNION ALL

-- 12. Invoice Posted
SELECT
    vj.INVOICENUM AS "InvoiceNumber",
    'Invoice Posted' AS "ActivityName",
    vj.POSTINGDATE AS "EventTime",
    vj.CREATEDBY AS "User",
    vj.INVOICEACCOUNT AS "VendorNumber",
    vj.PURCHID AS "PurchaseOrderNumber",
    vj.INVOICEAMOUNT AS "InvoiceAmount",
    'Posted' AS "InvoiceStatus",
    vj.DUEDATE AS "PaymentDueDate",
    vj.POSTINGDATE AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendInvoiceJour vj

UNION ALL

-- 13. Payment Scheduled
SELECT
    l.INVOICENUMBER AS "InvoiceNumber",
    'Payment Scheduled' AS "ActivityName",
    l.CREATEDDATETIME AS "EventTime",
    l.CREATEDBY AS "User",
    l.ACCOUNTDISPLAYVALUE AS "VendorNumber",
    NULL AS "PurchaseOrderNumber",
    l.DEBITAMOUNT + l.CREDITAMOUNT AS "InvoiceAmount",
    'Scheduled for Payment' AS "InvoiceStatus",
    l.DUEDATE AS "PaymentDueDate",
    l.CREATEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM LedgerJournalTransVendPaymEntity l

UNION ALL

-- 14. Payment Executed
SELECT
    vs.INVOICENUMBER AS "InvoiceNumber",
    'Payment Executed' AS "ActivityName",
    vs.TRANSDATE AS "EventTime",
    vs.CREATEDBY AS "User",
    vs.ACCOUNTNUM AS "VendorNumber",
    NULL AS "PurchaseOrderNumber",
    vs.SETTLEMENTAMOUNT AS "InvoiceAmount",
    'Paid' AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    vs.TRANSDATE AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendSettlement vs;

ステップ

前提条件: BYODの構成: Microsoft Dynamics 365 Finance and Operations環境でBring Your Own Database機能が構成されていることを確認してください。これには、Azure SQL Databaseのセットアップと、D365からデータをエクスポートするための構成が含まれます。
データエンティティの特定: D365で、データ管理ワークスペースに移動します。この抽出のコアは、特定のデータエンティティのエクスポートに依存しています。以下のエンティティが、BYODデータベースをターゲットとするエクスポートジョブに含まれていることを確認してください: Vendor invoice journal、Vendor invoice lines、Vendor invoice document register、Workflow tracking status table、Vendor payment journal lines、Vendor settlements、Accounting distributions。
エクスポートジョブの作成とスケジュール設定: データ管理ワークスペースで、新しいエクスポートプロジェクトを作成します。上記でリストされたエンティティをプロジェクトに追加します。ターゲットデータ形式をBYODデータベースに設定します。BYODのデータを最新の状態に保つために、エクスポートジョブの定期的なスケジュール（例: 毎日または毎時）を設定します。
Azure SQLでのデータ検証: SQL Server Management Studio（SSMS）やAzure Data Studioのようなツールを使用してAzure SQL Databaseに接続します。D365エンティティに対応するテーブルが作成され、データが入力されていることを確認します。
SQLクエリの準備: 提供されているSQLクエリをコピーします。このクエリは、Azure SQL Database内のBYODエクスポートプロセスによって作成されたテーブルに対して直接実行されるように設計されています。
接続と実行: BYODに接続されたSQLクライアントで新しいクエリウィンドウを開きます。コピーしたSQLクエリをウィンドウに貼り付けます。
クエリパラメーターの設定: スクリプトの上部にあるプレースホルダー変数を見つけます。{StartDate}、{EndDate}、{CompanyCode}をそれぞれ目的の開始日、終了日、および法的エンティティ識別子に置き換えます。例えば、SET @StartDate = '2023-01-01';、SET @EndDate = '2023-12-31';、SET @CompanyCode = 'USMF';のように設定します。
クエリの実行: 完全なSQLスクリプトを実行します。クエリは複数のテーブルからデータを収集し、結合して各請求書の時系列イベントログを構築します。
結果の確認: 出力は、InvoiceNumber、ActivityName、EventTime、およびその他の指定された属性の列を含むイベントログを含む単一のテーブルになります。結果を確認して、それらが正しく完全であることを確認します。
イベントログのエクスポート: クエリ結果をCSVファイルにエクスポートします。ほとんどのSQLクライアントには、結果をファイルに保存する組み込み関数があります。ファイルがUTF-8エンコーディングで保存されていることを確認します。
アップロードの準備: プロセスマイニングツールにアップロードする前に、CSVファイルのヘッダーがクエリで指定されたもの（InvoiceNumber、ActivityNameなど）と正確に一致していることを確認します。ファイル構造のそれ以上の変換は必要ありません。

設定

主要データエンティティ: 抽出は、BYODにエクスポートされる複数のD365データエンティティに依存しています。重要なエンティティには、VendInvoiceJour、VendInvoiceInfoTable、WorkflowTrackingStatusTable、VendSettlement、VendInvoiceRegisterHeader、LedgerJournalTrans、AccountingDistribution、VendTransが含まれます。
日付範囲フィルタリング: 提供されるクエリには@StartDateと@EndDateパラメーターが含まれています。パフォーマンスを確保するため、3〜6ヶ月間のデータなど、限られた日付範囲から始めることをお勧めします。フィルターは請求書の転記日または作成日に適用されます。
会社コードフィルタリング: @DataAreaIdパラメーターは、マルチカンパニー環境にとって非常に重要です。データのコンテキストが正しいことを確認するために、常に特定の法的エンティティ（Company Code）でフィルターしてください。
BYOD更新頻度: データの適時性は、D365エクスポートジョブのスケジュールに完全に依存します。ほぼリアルタイムの分析のためには、高頻度（例：毎時）が必要ですが、D365とAzureの両方でパフォーマンスとコストに影響を与える可能性があります。
前提条件: この方法では、アクティブなAzureサブスクリプション、プロビジョニングされたAzure SQL Database、およびデータ管理ワークスペースを構成するためのD365での管理者レベルのアクセス権が必要です。

a クエリ例 sql

DECLARE @StartDate DATETIME = '{StartDate}';
DECLARE @EndDate DATETIME = '{EndDate}';
DECLARE @CompanyCode NVARCHAR(4) = '{CompanyCode}';

WITH BaseInvoices AS (
    SELECT
        h.INVOICEID AS InvoiceNumber,
        h.VENDORACCOUNT AS VendorNumber,
        h.PURCHID AS PurchaseOrderNumber,
        h.INVOICEAMOUNT AS InvoiceAmount,
        p.DUEDATE AS PaymentDueDate,
        h.DOCUMENTSTATUS AS InvoiceStatus,
        h.CREATEDBY AS CreatedByUser,
        h.CREATEDDATETIME AS CreatedDateTime,
        h.MODIFIEDBY AS ModifiedByUser,
        h.MODIFIEDDATETIME AS ModifiedDateTime,
        h.BLOCKED AS IsBlocked,
        h.POSTINGDATE AS PostingDate
    FROM VendInvoiceJour h
    LEFT JOIN VendTrans p ON h.INVOICEID = p.INVOICE AND h.DATAAREAID = p.DATAAREAID AND h.VENDORACCOUNT = p.ACCOUNTNUM
    WHERE h.DATAAREAID = @CompanyCode
      AND h.POSTINGDATE BETWEEN @StartDate AND @EndDate
)
-- 1. Invoice Registered
SELECT
    vpr.JOURNALID AS InvoiceNumber,
    'Invoice Registered' AS ActivityName,
    vpr.CREATEDDATETIME AS EventTime,
    'D365 F&O' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    vpr.VENDORACCOUNT AS VendorNumber,
    NULL AS PurchaseOrderNumber,
    vpr.INVOICEAMOUNT AS InvoiceAmount,
    vpr.CREATEDBY AS User,
    'Registered' AS InvoiceStatus,
    vpr.DUEDATE AS PaymentDueDate,
    vpr.CREATEDDATETIME AS EndTime
FROM VendInvoiceRegisterHeader vpr
WHERE vpr.DATAAREAID = @CompanyCode AND vpr.CREATEDDATETIME BETWEEN @StartDate AND @EndDate

UNION ALL

-- 2. Invoice Data Captured
SELECT
    viit.NUM AS InvoiceNumber,
    'Invoice Data Captured' AS ActivityName,
    viit.CREATEDDATETIME AS EventTime,
    'D365 F&O' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    viit.VENDORACCOUNT AS VendorNumber,
    viit.PURCHID AS PurchaseOrderNumber,
    viit.INVOICEAMOUNT AS InvoiceAmount,
    viit.CREATEDBY AS User,
    'Pending' AS InvoiceStatus,
    NULL AS PaymentDueDate,
    viit.CREATEDDATETIME AS EndTime
FROM VendInvoiceInfoTable viit
WHERE viit.DATAAREAID = @CompanyCode AND viit.CREATEDDATETIME BETWEEN @StartDate AND @EndDate

UNION ALL

-- 3. Invoice Coded
SELECT
    vil.INVOICEID AS InvoiceNumber,
    'Invoice Coded' AS ActivityName,
    MAX(ad.CREATEDDATETIME) AS EventTime,
    'D365 F&O' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    bij.VendorNumber,
    bij.PurchaseOrderNumber,
    bij.InvoiceAmount,
    MAX(ad.CREATEDBY) AS User,
    bij.InvoiceStatus,
    bij.PaymentDueDate,
    MAX(ad.CREATEDDATETIME) AS EndTime
FROM AccountingDistribution ad
JOIN VendInvoiceInfoLine vil ON ad.SOURCEDOCUMENTLINE = vil.RECID
JOIN BaseInvoices bij ON vil.INVOICEID = bij.InvoiceNumber
WHERE ad.DATAAREAID = @CompanyCode
GROUP BY vil.INVOICEID, bij.VendorNumber, bij.PurchaseOrderNumber, bij.InvoiceAmount, bij.InvoiceStatus, bij.PaymentDueDate

UNION ALL

-- 4. Invoice Matched To Purchase Order
SELECT
    viit.NUM AS InvoiceNumber,
    'Invoice Matched To Purchase Order' AS ActivityName,
    viit.MODIFIEDDATETIME AS EventTime,
    'D365 F&O' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    viit.VENDORACCOUNT AS VendorNumber,
    viit.PURCHID AS PurchaseOrderNumber,
    viit.INVOICEAMOUNT AS InvoiceAmount,
    viit.MODIFIEDBY AS User,
    'Matched' AS InvoiceStatus,
    NULL AS PaymentDueDate,
    viit.MODIFIEDDATETIME AS EndTime
FROM VendInvoiceInfoTable viit
WHERE viit.DATAAREAID = @CompanyCode AND viit.PURCHMATCHINGPOLICY > 0 AND viit.LASTMATCHINGSTATUS = 1 -- Enum for Passed
  AND viit.MODIFIEDDATETIME BETWEEN @StartDate AND @EndDate

UNION ALL

-- 5. Matching Discrepancy Found
SELECT
    viit.NUM AS InvoiceNumber,
    'Matching Discrepancy Found' AS ActivityName,
    viit.MODIFIEDDATETIME AS EventTime,
    'D365 F&O' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    viit.VENDORACCOUNT AS VendorNumber,
    viit.PURCHID AS PurchaseOrderNumber,
    viit.INVOICEAMOUNT AS InvoiceAmount,
    viit.MODIFIEDBY AS User,
    'Matching Failed' AS InvoiceStatus,
    NULL AS PaymentDueDate,
    viit.MODIFIEDDATETIME AS EndTime
FROM VendInvoiceInfoTable viit
WHERE viit.DATAAREAID = @CompanyCode AND viit.PURCHMATCHINGPOLICY > 0 AND viit.LASTMATCHINGSTATUS = 2 -- Enum for Failed
  AND viit.MODIFIEDDATETIME BETWEEN @StartDate AND @EndDate

UNION ALL

-- 6. Matching Discrepancy Handled (Inferred by successful match after a failure)
-- This is an approximation. A true 'handled' event is difficult to capture without change tracking.
-- This query assumes the modification time of the 'Passed' status represents the handling time.
SELECT
    viit.NUM AS InvoiceNumber,
    'Matching Discrepancy Handled' AS ActivityName,
    viit.MODIFIEDDATETIME AS EventTime,
    'D365 F&O' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    viit.VENDORACCOUNT AS VendorNumber,
    viit.PURCHID AS PurchaseOrderNumber,
    viit.INVOICEAMOUNT AS InvoiceAmount,
    viit.MODIFIEDBY AS User,
    'Matched' AS InvoiceStatus,
    NULL AS PaymentDueDate,
    viit.MODIFIEDDATETIME AS EndTime
FROM VendInvoiceInfoTable viit
WHERE viit.DATAAREAID = @CompanyCode AND viit.PURCHMATCHINGPOLICY > 0 AND viit.LASTMATCHINGSTATUS = 1 -- Enum for Passed
  AND viit.DISCREPANCYSTATE > 0 -- Indicates there was a discrepancy at some point
  AND viit.MODIFIEDDATETIME BETWEEN @StartDate AND @EndDate

UNION ALL

-- 7, 8, 9. Workflow Events (Submitted, Approved, Rejected)
SELECT
    bij.InvoiceNumber,
    CASE wts.TRACKINGTYPE
        WHEN 1 THEN 'Invoice Sent For Approval' -- Submitted
        WHEN 5 THEN 'Invoice Approved' -- Completed/Approved
        WHEN 4 THEN 'Invoice Rejected' -- Rejection
    END AS ActivityName,
    wts.CREATEDDATETIME AS EventTime,
    'D365 F&O' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    bij.VendorNumber,
    bij.PurchaseOrderNumber,
    bij.InvoiceAmount,
    wts.USERID AS User,
    bij.InvoiceStatus,
    bij.PaymentDueDate,
    wts.CREATEDDATETIME AS EndTime
FROM WorkflowTrackingStatusTable wts
JOIN VendInvoiceInfoTable viit ON wts.CONTEXTRECID = viit.RECID
JOIN BaseInvoices bij ON viit.NUM = bij.InvoiceNumber
WHERE wts.DATAAREAID = @CompanyCode AND wts.TRACKINGTYPE IN (1, 4, 5)

UNION ALL

-- 10. Payment Block Set
SELECT
    bij.InvoiceNumber,
    'Payment Block Set' AS ActivityName,
    bij.ModifiedDateTime AS EventTime,
    'D365 F&O' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    bij.VendorNumber,
    bij.PurchaseOrderNumber,
    bij.InvoiceAmount,
    bij.ModifiedByUser AS User,
    'Blocked' AS InvoiceStatus,
    bij.PaymentDueDate,
    bij.ModifiedDateTime AS EndTime
FROM BaseInvoices bij
WHERE bij.IsBlocked = 1 -- Enum for Yes

UNION ALL

-- 11. Payment Block Released (Inferred by modification of a previously blocked invoice)
SELECT
    bij.InvoiceNumber,
    'Payment Block Released' AS ActivityName,
    bij.ModifiedDateTime AS EventTime,
    'D365 F&O' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    bij.VendorNumber,
    bij.PurchaseOrderNumber,
    bij.InvoiceAmount,
    bij.ModifiedByUser AS User,
    bij.InvoiceStatus,
    bij.PaymentDueDate,
    bij.ModifiedDateTime AS EndTime
FROM BaseInvoices bij
-- This logic assumes modification date reflects the unblocking action.
-- It requires a more sophisticated change log for true accuracy.
WHERE bij.IsBlocked = 0 AND bij.ModifiedDateTime > bij.CreatedDateTime

UNION ALL

-- 12. Invoice Posted
SELECT
    bij.InvoiceNumber,
    'Invoice Posted' AS ActivityName,
    bij.PostingDate AS EventTime, -- Or CreatedDateTime depending on business process
    'D365 F&O' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    bij.VendorNumber,
    bij.PurchaseOrderNumber,
    bij.InvoiceAmount,
    bij.CreatedByUser AS User,
    'Posted' AS InvoiceStatus,
    bij.PaymentDueDate,
    bij.PostingDate AS EndTime
FROM BaseInvoices bij

UNION ALL

-- 13. Payment Scheduled
SELECT
    ljt.INVOICE AS InvoiceNumber,
    'Payment Scheduled' AS ActivityName,
    ljt.CREATEDDATETIME AS EventTime,
    'D365 F&O' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    bij.VendorNumber,
    bij.PurchaseOrderNumber,
    bij.InvoiceAmount,
    ljt.CREATEDBY AS User,
    'Payment Scheduled' AS InvoiceStatus,
    bij.PaymentDueDate,
    ljt.CREATEDDATETIME AS EndTime
FROM LedgerJournalTrans ljt
JOIN BaseInvoices bij ON ljt.INVOICE = bij.InvoiceNumber
WHERE ljt.DATAAREAID = @CompanyCode AND ljt.ACCOUNTPLUSTYPE = 2 -- Vendor type
  AND ljt.CREATEDDATETIME BETWEEN @StartDate AND @EndDate

UNION ALL

-- 14. Payment Executed
SELECT
    vs.INVOICEID AS InvoiceNumber,
    'Payment Executed' AS ActivityName,
    vs.CREATEDDATETIME AS EventTime,
    'D365 F&O' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    vs.VENDORACCOUNT AS VendorNumber,
    bij.PurchaseOrderNumber,
    bij.InvoiceAmount,
    vs.CREATEDBY AS User,
    'Paid' AS InvoiceStatus,
    bij.PaymentDueDate,
    vs.CREATEDDATETIME AS EndTime
FROM VendSettlement vs
JOIN BaseInvoices bij ON vs.INVOICEID = bij.InvoiceNumber
WHERE vs.DATAAREAID = @CompanyCode AND vs.CREATEDDATETIME BETWEEN @StartDate AND @EndDate;

ステップ

前提条件のセットアップ: システムにPython 3.6以降がインストールされていることを確認します。pipを使用して必要なライブラリをインストールします: pip install pandas requests msal。これらのライブラリは、データ操作、APIへのHTTPリクエストの作成、およびMicrosoftアイデンティティプラットフォームの認証処理用です。
Azure Active Directoryでのアプリケーションの登録: Dynamics 365 APIで認証するには、組織のAzure ADテナントでアプリケーションを登録する必要があります。新しいApp Registrationを作成し、クライアントシークレットを生成し、Application (client) ID、Directory (tenant) ID、およびクライアントシークレット値を控えておきます。
API権限の付与: Azure ADで新しく作成したApp Registration内で、APIの権限に移動します。「Dynamics ERP」または「Dynamics 365 Business Central」（ライセンスによって異なる）の権限を追加し、user_impersonation委任権限を付与します。管理者はこれらの権限に対して管理者の同意を付与する必要があります。
Dynamics 365でのアプリケーションユーザーの作成: Dynamics 365環境で、System administration > Users > Usersに移動します。新しいユーザーを作成し、Azure App RegistrationからのApplication (client) IDをApplication IDフィールドに入力します。このユーザーに、「System administrator」のような適切なセキュリティロール、または必要なすべてのデータエンティティへの読み取りアクセス権を持つより制限されたロールを割り当てます。
Pythonスクリプトの構成: 提供されたPythonスクリプトを、例えばextract_invoices.pyというファイルにコピーします。ファイルを開き、上部のプレースホルダー変数を、特定のDynamics 365環境URL、テナントID、クライアントID、クライアントシークレット、およびデータを抽出したい会社コード（dataAreaId）で更新します。
日付範囲の設定: スクリプト内のSTART_DATEとEND_DATE変数を調整して、データ抽出の時間枠を定義します。スクリプトをテストし、結果を検証するために、1ヶ月のようなより小さい範囲から始めることをお勧めします。
スクリプトの実行: コマンドラインまたはターミナルからコマンド: python extract_invoices.pyを使用してスクリプトを実行します。スクリプトは認証を行い、各アクティビティの異なるODataエンドポイントをクエリし、データを処理します。
実行の監視: スクリプトは、各アクティビティのデータを取得する際に、コンソールに進行状況メッセージを表示します。これは、日付範囲とデータ量によってはかなりの時間を要する場合があります。認証やAPIアクセスに関する問題を示す可能性のあるエラーメッセージを探してください。
出力ファイルの確認: スクリプトが正常に完了すると、同じディレクトリにd365_invoice_event_log.csvという名前のCSVファイルが生成されます。このファイルには、統合されたイベントログが含まれます。
アップロードの準備: CSVファイルを開いて、正しくフォーマットされていることを確認します。必要なすべての列（InvoiceNumber、ActivityName、EventTime、SourceSystem、LastDataUpdate）が存在し、入力されていることを確認します。このファイルはProcessMindにアップロードする準備ができています。

設定

認証: スクリプトはOAuth 2.0クライアントクレデンシャルフローを使用します。Azure AD App Registrationを設定し、Dynamics 365へのAPIアクセス許可を付与する必要があります。また、Dynamics 365自体で適切なセキュリティロールを持つアプリケーションユーザーを作成する必要があります。
APIエンドポイント: Dynamics 365 Finance and Operations OData APIのベースURLです。通常、https://[your-d365-environment-name].operations.dynamics.comの形式です。
日付範囲: スクリプトにはSTART_DATEとEND_DATE変数が含まれています。これらは、作成日または変更日に基づいてレコードをフィルターし、データ量を管理するために使用されます。初期抽出では、3〜6ヶ月の期間が推奨されます。
会社フィルター: データは特定の法的エンティティまたは会社でフィルターする必要があります。これは、APIクエリフィルターでdataAreaIdを指定することによって行われ、スクリプト内の必須構成です。
主要データエンティティ: スクリプトは、VendorInvoiceRegisterJournalsV2、VendorInvoiceHeaders、VendorPostedInvoices、VendorPaymentJournalLines、VendSettlementsを含む複数の標準Dynamics 365 ODataエンティティを照会します。標準プロセスが大幅に変更されている場合は、カスタムエンティティが必要になる場合があります。
ページネーション: スクリプトは、@odata.nextLinkプロパティを使用してAPIからのページ分割された応答を自動的に処理し、指定された期間のすべてのレコードが取得されるようにします。

a クエリ例 python

import os
import pandas as pd
import requests
import msal
import datetime
import time

class=class="hl-string">"hl-comment"># --- Configuration: Update these values --- #
D365_URL = class="hl-string">"https://[your-d365-environment].operations.dynamics.com"
TENANT_ID = class="hl-string">"[your-tenant-id]"
CLIENT_ID = class="hl-string">"[your-client-id]"
CLIENT_SECRET = class="hl-string">"[your-client-secret]"
COMPANY_ID = class="hl-string">"[your-company-id]" class=class="hl-string">"hl-comment"># e.g., class="hl-string">'USMF'
START_DATE = class="hl-string">"2023-01-01T00:00:00Z"
END_DATE = class="hl-string">"2023-12-31T23:59:59Z"

class=class="hl-string">"hl-comment"># --- End Configuration --- #

RESOURCE = fclass="hl-string">"{D365_URL}/"
AUTHORITY = fclass="hl-string">"https://login.microsoftonline.com/{TENANT_ID}"
API_BASE_URL = fclass="hl-string">"{D365_URL}/data"

LAST_DATA_UPDATE = datetime.datetime.now(datetime.timezone.utc).isoformat()
SOURCE_SYSTEM = class="hl-string">"Microsoft Dynamics 365"

def get_access_token():
    class="hl-string">"""Acquires an access token from Azure AD."""
    app = msal.ConfidentialClientApplication(
        CLIENT_ID,
        authority=AUTHORITY,
        client_credential=CLIENT_SECRET
    )
    result = app.acquire_token_for_client(scopes=[fclass="hl-string">"{RESOURCE}/.default"])
    if class="hl-string">"access_token" in result:
        return result[class="hl-string">'access_token']
    else:
        print(class="hl-string">"Error acquiring token:", result.get(class="hl-string">"error_description"))
        return None

def fetch_all_data(access_token, entity_url):
    class="hl-string">"""Fetches all pages of data from a given D365 OData entity URL."""
    all_data = []
    headers = {
        class="hl-string">'Authorization': fclass="hl-string">'Bearer {access_token}',
        class="hl-string">'Content-Type': class="hl-string">'application/json',
        class="hl-string">'OData-MaxVersion': class="hl-string">'4.0',
        class="hl-string">'OData-Version': class="hl-string">'4.0',
        class="hl-string">'Prefer': class="hl-string">'odata.include-annotations="*"'
    }
    
    next_link = entity_url
    while next_link:
        try:
            response = requests.get(next_link, headers=headers)
            response.raise_for_status()
            data = response.json()
            all_data.extend(data[class="hl-string">'value'])
            next_link = data.get(class="hl-string">'@odata.nextLink')
            time.sleep(0.1) class=class="hl-string">"hl-comment"># Small delay to respect API limits
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"An error occurred: {e}")
            print(fclass="hl-string">"Response body: {response.text}")
            next_link = None
    return all_data

def main():
    token = get_access_token()
    if not token:
        return

    all_events = []
    cross_company_filter = fclass="hl-string">"cross-company=true&$filter=dataAreaId eq '{COMPANY_ID}'"

    print(class="hl-string">"Fetching 'Invoice Registered' events...")
    entity_url = fclass="hl-string">"{API_BASE_URL}/VendorInvoiceRegisterJournalsV2?{cross_company_filter} and CreatedDateTime ge {START_DATE} and CreatedDateTime le {END_DATE}&$select=JournalNumber,CreatedDateTime,InvoiceNumber,VendorAccount,CreatedBy,JournalTotalCredit"
    data = fetch_all_data(token, entity_url)
    for item in data:
        all_events.append({
            class="hl-string">'InvoiceNumber': item.get(class="hl-string">'InvoiceNumber'),
            class="hl-string">'ActivityName': class="hl-string">'Invoice Registered',
            class="hl-string">'EventTime': item.get(class="hl-string">'CreatedDateTime'),
            class="hl-string">'User': item.get(class="hl-string">'CreatedBy'),
            class="hl-string">'VendorNumber': item.get(class="hl-string">'VendorAccount'),
            class="hl-string">'InvoiceAmount': item.get(class="hl-string">'JournalTotalCredit'),
            class="hl-string">'PurchaseOrderNumber': None, class="hl-string">'InvoiceStatus': None, class="hl-string">'PaymentDueDate': None
        })

    print(class="hl-string">"Fetching invoice header events...")
    entity_url = fclass="hl-string">"{API_BASE_URL}/VendorInvoiceHeaders?{cross_company_filter} and CreatedDateTime ge {START_DATE} and CreatedDateTime le {END_DATE}&$select=InvoiceNumber,CreatedDateTime,ModifiedDateTime,VendorAccount,PurchaseOrderNumber,InvoiceAmount,InvoiceMatchingStatus,LastMatchingValidationDate,InvoiceLastActionDate,Worker,InvoiceLastAction,DueDate,VendorInvoiceHeaderStatus"
    data = fetch_all_data(token, entity_url)
    for item in data:
        class=class="hl-string">"hl-comment"># Invoice Data Captured (approximated by creation of the header)
        all_events.append({
            class="hl-string">'InvoiceNumber': item.get(class="hl-string">'InvoiceNumber'), class="hl-string">'ActivityName': class="hl-string">'Invoice Data Captured', class="hl-string">'EventTime': item.get(class="hl-string">'CreatedDateTime'), class="hl-string">'User': item.get(class="hl-string">'Worker'),
            class="hl-string">'VendorNumber': item.get(class="hl-string">'VendorAccount'), class="hl-string">'InvoiceAmount': item.get(class="hl-string">'InvoiceAmount'), class="hl-string">'PurchaseOrderNumber': item.get(class="hl-string">'PurchaseOrderNumber'),
            class="hl-string">'InvoiceStatus': item.get(class="hl-string">'VendorInvoiceHeaderStatus'), class="hl-string">'PaymentDueDate': item.get(class="hl-string">'DueDate')
        })
        class=class="hl-string">"hl-comment"># Invoice Coded (inferred by modification after creation)
        if item.get(class="hl-string">'ModifiedDateTime') != item.get(class="hl-string">'CreatedDateTime'):
            all_events.append({
                class="hl-string">'InvoiceNumber': item.get(class="hl-string">'InvoiceNumber'), class="hl-string">'ActivityName': class="hl-string">'Invoice Coded', class="hl-string">'EventTime': item.get(class="hl-string">'ModifiedDateTime'), class="hl-string">'User': item.get(class="hl-string">'Worker'),
                class="hl-string">'VendorNumber': item.get(class="hl-string">'VendorAccount'), class="hl-string">'InvoiceAmount': item.get(class="hl-string">'InvoiceAmount'), class="hl-string">'PurchaseOrderNumber': item.get(class="hl-string">'PurchaseOrderNumber'),
                class="hl-string">'InvoiceStatus': item.get(class="hl-string">'VendorInvoiceHeaderStatus'), class="hl-string">'PaymentDueDate': item.get(class="hl-string">'DueDate')
            })
        class=class="hl-string">"hl-comment"># Matching activities
        if item.get(class="hl-string">'InvoiceMatchingStatus') == class="hl-string">'Passed' and item.get(class="hl-string">'LastMatchingValidationDate'):
            all_events.append({
                class="hl-string">'InvoiceNumber': item.get(class="hl-string">'InvoiceNumber'), class="hl-string">'ActivityName': class="hl-string">'Invoice Matched To Purchase Order', class="hl-string">'EventTime': item.get(class="hl-string">'LastMatchingValidationDate'), class="hl-string">'User': item.get(class="hl-string">'Worker'),
                class="hl-string">'VendorNumber': item.get(class="hl-string">'VendorAccount'), class="hl-string">'InvoiceAmount': item.get(class="hl-string">'InvoiceAmount'), class="hl-string">'PurchaseOrderNumber': item.get(class="hl-string">'PurchaseOrderNumber'),
                class="hl-string">'InvoiceStatus': item.get(class="hl-string">'VendorInvoiceHeaderStatus'), class="hl-string">'PaymentDueDate': item.get(class="hl-string">'DueDate')
            })
        if item.get(class="hl-string">'InvoiceMatchingStatus') == class="hl-string">'Failed' and item.get(class="hl-string">'LastMatchingValidationDate'):
            all_events.append({
                class="hl-string">'InvoiceNumber': item.get(class="hl-string">'InvoiceNumber'), class="hl-string">'ActivityName': class="hl-string">'Matching Discrepancy Found', class="hl-string">'EventTime': item.get(class="hl-string">'LastMatchingValidationDate'), class="hl-string">'User': item.get(class="hl-string">'Worker'),
                class="hl-string">'VendorNumber': item.get(class="hl-string">'VendorAccount'), class="hl-string">'InvoiceAmount': item.get(class="hl-string">'InvoiceAmount'), class="hl-string">'PurchaseOrderNumber': item.get(class="hl-string">'PurchaseOrderNumber'),
                class="hl-string">'InvoiceStatus': item.get(class="hl-string">'VendorInvoiceHeaderStatus'), class="hl-string">'PaymentDueDate': item.get(class="hl-string">'DueDate')
            })
            class=class="hl-string">"hl-comment"># Matching Discrepancy Handled (inferred if invoice is now matched or posted after a discrepancy)
            if item.get(class="hl-string">'VendorInvoiceHeaderStatus') in [class="hl-string">'Matched', class="hl-string">'Posted'] and item.get(class="hl-string">'ModifiedDateTime') > item.get(class="hl-string">'LastMatchingValidationDate'):
                all_events.append({
                    class="hl-string">'InvoiceNumber': item.get(class="hl-string">'InvoiceNumber'), class="hl-string">'ActivityName': class="hl-string">'Matching Discrepancy Handled', class="hl-string">'EventTime': item.get(class="hl-string">'ModifiedDateTime'), class="hl-string">'User': item.get(class="hl-string">'Worker'),
                    class="hl-string">'VendorNumber': item.get(class="hl-string">'VendorAccount'), class="hl-string">'InvoiceAmount': item.get(class="hl-string">'InvoiceAmount'), class="hl-string">'PurchaseOrderNumber': item.get(class="hl-string">'PurchaseOrderNumber'),
                    class="hl-string">'InvoiceStatus': item.get(class="hl-string">'VendorInvoiceHeaderStatus'), class="hl-string">'PaymentDueDate': item.get(class="hl-string">'DueDate')
                })

    print(class="hl-string">"Fetching workflow events...")
    class=class="hl-string">"hl-comment"># This is a simplified workflow extraction. A real scenario might need to query WorkflowTrackingWorkItem and join.
    entity_url = fclass="hl-string">"{API_BASE_URL}/WorkflowTrackingStatusTables?{cross_company_filter} and CreatedDateTime ge {START_DATE} and CreatedDateTime le {END_DATE}&$filter=contains(Context,'VendInvoice')&$select=ContextRecId,CreatedDateTime,TrackingStatus,User,Context"
    class=class="hl-string">"hl-comment"># Note: Linking ContextRecId back to an InvoiceNumber requires another lookup, which is complex. 
    class=class="hl-string">"hl-comment"># A placeholder is used here. For a real implementation, you must resolve this link.
    class=class="hl-string">"hl-comment"># For this script, we will not generate workflow events to avoid complexity.

    print(class="hl-string">"Fetching posted invoice events...")
    entity_url = fclass="hl-string">"{API_BASE_URL}/VendorPostedInvoices?{cross_company_filter} and PostedDateTime ge {START_DATE} and PostedDateTime le {END_DATE}&$select=InvoiceNumber,PostedDateTime,VendorAccount,PurchaseOrderNumber,InvoiceAmount,DueDate,Block,ModifiedDateTime,ModifiedBy"
    data = fetch_all_data(token, entity_url)
    for item in data:
        all_events.append({
            class="hl-string">'InvoiceNumber': item.get(class="hl-string">'InvoiceNumber'), class="hl-string">'ActivityName': class="hl-string">'Invoice Posted', class="hl-string">'EventTime': item.get(class="hl-string">'PostedDateTime'), class="hl-string">'User': item.get(class="hl-string">'ModifiedBy'),
            class="hl-string">'VendorNumber': item.get(class="hl-string">'VendorAccount'), class="hl-string">'InvoiceAmount': item.get(class="hl-string">'InvoiceAmount'), class="hl-string">'PurchaseOrderNumber': item.get(class="hl-string">'PurchaseOrderNumber'),
            class="hl-string">'InvoiceStatus': class="hl-string">'Posted', class="hl-string">'PaymentDueDate': item.get(class="hl-string">'DueDate')
        })
        if item.get(class="hl-string">'Block') not in [None, class="hl-string">'No', class="hl-string">'Free']:
            all_events.append({
                class="hl-string">'InvoiceNumber': item.get(class="hl-string">'InvoiceNumber'), class="hl-string">'ActivityName': class="hl-string">'Payment Block Set', class="hl-string">'EventTime': item.get(class="hl-string">'ModifiedDateTime'), class="hl-string">'User': item.get(class="hl-string">'ModifiedBy'),
                class="hl-string">'VendorNumber': item.get(class="hl-string">'VendorAccount'), class="hl-string">'InvoiceAmount': item.get(class="hl-string">'InvoiceAmount'), class="hl-string">'PurchaseOrderNumber': item.get(class="hl-string">'PurchaseOrderNumber'),
                class="hl-string">'InvoiceStatus': class="hl-string">'Posted (Blocked)', class="hl-string">'PaymentDueDate': item.get(class="hl-string">'DueDate')
            })
        class=class="hl-string">"hl-comment"># Payment Block Released is difficult to capture without audit logs. This is an approximation.

    print(class="hl-string">"Fetching payment schedule events...")
    entity_url = fclass="hl-string">"{API_BASE_URL}/VendorPaymentJournalLines?{cross_company_filter} and CreatedDateTime ge {START_DATE} and CreatedDateTime le {END_DATE}&$select=InvoiceNumber,CreatedDateTime,CreatedBy,JournalBatchNumber,VendorAccountNumber,Amount"
    data = fetch_all_data(token, entity_url)
    for item in data:
        all_events.append({
            class="hl-string">'InvoiceNumber': item.get(class="hl-string">'InvoiceNumber'), class="hl-string">'ActivityName': class="hl-string">'Payment Scheduled', class="hl-string">'EventTime': item.get(class="hl-string">'CreatedDateTime'), class="hl-string">'User': item.get(class="hl-string">'CreatedBy'),
            class="hl-string">'VendorNumber': item.get(class="hl-string">'VendorAccountNumber'), class="hl-string">'InvoiceAmount': item.get(class="hl-string">'Amount'), class="hl-string">'PurchaseOrderNumber': None,
            class="hl-string">'InvoiceStatus': class="hl-string">'Payment Scheduled', class="hl-string">'PaymentDueDate': None
        })

    print(class="hl-string">"Fetching payment execution events...")
    entity_url = fclass="hl-string">"{API_BASE_URL}/VendSettlements?{cross_company_filter} and SettlementDate ge {START_DATE} and SettlementDate le {END_DATE}&$select=InvoiceNumber,SettlementDate,VendorAccountNumber,SettlementAmount"
    data = fetch_all_data(token, entity_url)
    for item in data:
        all_events.append({
            class="hl-string">'InvoiceNumber': item.get(class="hl-string">'InvoiceNumber'), class="hl-string">'ActivityName': class="hl-string">'Payment Executed', class="hl-string">'EventTime': item.get(class="hl-string">'SettlementDate'), class="hl-string">'User': None, class=class="hl-string">"hl-comment"># User not available in this entity
            class="hl-string">'VendorNumber': item.get(class="hl-string">'VendorAccountNumber'), class="hl-string">'InvoiceAmount': item.get(class="hl-string">'SettlementAmount'), class="hl-string">'PurchaseOrderNumber': None,
            class="hl-string">'InvoiceStatus': class="hl-string">'Paid', class="hl-string">'PaymentDueDate': None
        })

    if not all_events:
        print(class="hl-string">"No events found for the specified criteria.")
        return

    print(class="hl-string">"Processing and saving data...")
    df = pd.DataFrame(all_events)
    df[class="hl-string">'SourceSystem'] = SOURCE_SYSTEM
    df[class="hl-string">'LastDataUpdate'] = LAST_DATA_UPDATE
    df[class="hl-string">'EndTime'] = df[class="hl-string">'EventTime']
    df.dropna(subset=[class="hl-string">'InvoiceNumber', class="hl-string">'ActivityName', class="hl-string">'EventTime'], inplace=True)
    df.sort_values(by=[class="hl-string">'InvoiceNumber', class="hl-string">'EventTime'], inplace=True)

    output_filename = class="hl-string">'d365_invoice_event_log.csv'
    df.to_csv(output_filename, index=False, date_format=class="hl-string">'%Y-%m-%dT%H:%M:%SZ')
    print(fclass="hl-string">"Event log successfully created: {output_filename}")

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

ステップ

データ管理ワークスペースへ移動: Microsoft Dynamics 365 Financeにログインします。検索バーを使用してデータ管理ワークスペースを検索し、移動します。
新規エクスポートプロジェクトの作成: ワークスペース内で、Exportタイルを選択して新しいデータエクスポートプロジェクトを作成します。プロジェクトにProcessMind_Invoice_Processing_Exportのような分かりやすい名前を付けます。
データプロジェクトの定義: 新しいプロジェクトのGeneralタブで、Data formatを指定します。CSVは一般的に使用され、推奨される形式です。必要に応じて他のパラメーターを設定します。
必要なデータエンティティの追加: Selected entitiesセクションに移動し、Add entityをクリックします。以下のコアエンティティを一つずつ検索して追加します。それぞれのターゲットデータ形式を指定する必要があります。
- VendInvoiceInfoTableEntity (仕入先請求書ヘッダー)
- VendInvoiceTransEntity (仕入先請求書明細行)
- VendInvoiceRegisterHeaderEntity (請求書登録仕訳ヘッダー)
- WorkflowTrackingStatusTableEntity (ワークフロー履歴)
- AccountingDistributionEntity (総勘定元帳の配賦)
- VendInvoiceJour (転記済み仕入先請求書)
- VendTrans (仕入先トランザクション、支払いブロック用)
- LedgerJournalTransVendPaymEntity (仕入先支払い仕訳明細行)
- VendSettlement (仕入先決済トランザクション)
フィルターの適用: 各エンティティについて、データスコープを制限するためにフィルターを適用することが重要です。エンティティを選択し、Filterをクリックします。最低限、Company（法的エンティティ）と、CREATEDDATETIMEやINVOICEDATEなどの関連する日付フィールドで特定の日付範囲をフィルターします。初期分析の一般的な範囲は、過去3〜6ヶ月です。
エンティティマッピングの構成: 各エンティティについて、ソースからターゲットへのマッピングを確認します。最終的なイベントログに必要なすべてのフィールドがエクスポートに含まれていることを確認します。この段階では、複雑なマッピング変更は通常必要ありません。
エクスポートジョブの実行: すべてのエンティティが追加され、フィルターされたら、アクションペインのExportをクリックしてジョブを開始します。すぐに実行することも、システム負荷を最小限に抑えるためにオフピーク時間にスケジュールすることもできます。
エクスポートされたデータのダウンロード: エクスポートジョブが正常に完了したら、ジョブ履歴に移動します。そこから、エクスポートされたデータパッケージをダウンロードできます。これには各データエンティティの個別のファイルが含まれます。
データをイベントログに変換: エクスポートされたファイルはエンティティのスナップショットであり、統合されたイベントログではありません。これらのファイルを処理および結合するには、データベース、Pythonスクリプト、Power Queryなどの外部ツールを使用する必要があります。queryセクションにある概念的なクエリは、この変換の完全なロジックを提供します。
変換ロジックの実行: エクスポートされたCSVファイルを`選択した変換環境にロードします。提供された変換クエリを実行すると、すべてのソースファイルからデータが統合され、ビジネスアクティビティごとに1行を持つ単一のイベントログテーブルが作成されます。
最終化とアップロード: 最終的に変換されたデータを単一のCSVファイルにエクスポートします。列ヘッダーがInvoiceNumber、ActivityName、EventTimeなどの要件と一致していることを確認します。このファイルはProcessMindにアップロードする準備ができています。

設定

データエンティティ: 設定の中心は、請求書ライフサイクルをカバーする適切なエンティティセットを選択することです。主要なエンティティには、VendInvoiceInfoTableEntity、VendInvoiceJour、WorkflowTrackingStatusTableEntityなどが含まれます。
エクスポートデータ形式: 後続の変換ステップで処理しやすいため、ターゲットデータ形式としてCSVを選択してください。
会社によるフィルタリング: 分析対象の特定の法的エンティティ（会社）で各データエンティティをフィルターし、無関係なデータを取得しないようにすることが重要です。
日付範囲フィルタリング: VendInvoiceInfoTableEntityやVendInvoiceJourなど、関連するすべてのエンティティに、作成日または転記日に基づいた一貫した日付範囲フィルターを適用してください。データ量を管理するために、直近の期間（例：過去6ヶ月間）から開始することをお勧めします。
フルプッシュ対インクリメンタル: 最初の抽出では、フルプッシュを実行してください。その後の更新では、前回の実行以降に変更されたデータのみを取得するインクリメンタルエクスポートを設定でき、処理時間を短縮できます。
前提条件: エクスポートを実行するユーザーは、Dynamics 365で適切なセキュリティロール（通常はデータ管理管理者、または必要なデータエンティティへのアクセス権を持つ類似のロール）を持っている必要があります。

a クエリ例 config

/*
-- This is a conceptual query to be executed in a database or data transformation tool.
-- The tables referenced (e.g., 'VendInvoiceInfoTableEntity') are the CSV files exported from Dynamics 365.
-- Replace '[Your_Source_System_Name]' with the actual source system identifier.
*/

-- 1. Invoice Registered
SELECT
    h.INVOICENUMBER AS "InvoiceNumber",
    'Invoice Registered' AS "ActivityName",
    h.CREATEDDATETIME AS "EventTime",
    h.CREATEDBY AS "User",
    h.INVOICEACCOUNT AS "VendorNumber",
    NULL AS "PurchaseOrderNumber",
    h.INVOICEAMOUNT AS "InvoiceAmount",
    NULL AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    h.CREATEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendInvoiceRegisterHeaderEntity h

UNION ALL

-- 2. Invoice Data Captured
SELECT
    i.INVOICENUMBER AS "InvoiceNumber",
    'Invoice Data Captured' AS "ActivityName",
    i.CREATEDDATETIME AS "EventTime",
    i.CREATEDBY AS "User",
    i.VENDORACCOUNT AS "VendorNumber",
    i.PURCHASEORDERNUMBER AS "PurchaseOrderNumber",
    i.INVOICEAMOUNT AS "InvoiceAmount",
    'Pending' AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    i.CREATEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendInvoiceInfoTableEntity i

UNION ALL

-- 3. Invoice Coded
SELECT
    i.INVOICENUMBER AS "InvoiceNumber",
    'Invoice Coded' AS "ActivityName",
    MIN(a.CREATEDDATETIME) AS "EventTime",
    MIN(a.CREATEDBY) AS "User",
    i.VENDORACCOUNT AS "VendorNumber",
    i.PURCHASEORDERNUMBER AS "PurchaseOrderNumber",
    i.INVOICEAMOUNT AS "InvoiceAmount",
    'Pending' AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    MIN(a.CREATEDDATETIME) AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendInvoiceInfoTableEntity i
JOIN AccountingDistributionEntity a ON i.INVOICENUMBER = a.SOURCEDOCUMENTLINE_INVOICENUMBER
GROUP BY i.INVOICENUMBER, i.VENDORACCOUNT, i.PURCHASEORDERNUMBER, i.INVOICEAMOUNT

UNION ALL

-- 4. Invoice Matched To Purchase Order
SELECT
    i.INVOICENUMBER AS "InvoiceNumber",
    'Invoice Matched To Purchase Order' AS "ActivityName",
    i.MODIFIEDDATETIME AS "EventTime",
    i.MODIFIEDBY AS "User",
    i.VENDORACCOUNT AS "VendorNumber",
    i.PURCHASEORDERNUMBER AS "PurchaseOrderNumber",
    i.INVOICEAMOUNT AS "InvoiceAmount",
    'Matched' AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    i.MODIFIEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendInvoiceInfoTableEntity i
WHERE i.LASTMATCHSTATUS = 'Passed'

UNION ALL

-- 5. Matching Discrepancy Found
SELECT
    i.INVOICENUMBER AS "InvoiceNumber",
    'Matching Discrepancy Found' AS "ActivityName",
    i.MODIFIEDDATETIME AS "EventTime",
    i.MODIFIEDBY AS "User",
    i.VENDORACCOUNT AS "VendorNumber",
    i.PURCHASEORDERNUMBER AS "PurchaseOrderNumber",
    i.INVOICEAMOUNT AS "InvoiceAmount",
    'Discrepancy' AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    i.MODIFIEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendInvoiceInfoTableEntity i
WHERE i.LASTMATCHSTATUS = 'Failed'

UNION ALL

-- 6. Matching Discrepancy Handled (Approximation)
SELECT
    i.INVOICENUMBER AS "InvoiceNumber",
    'Matching Discrepancy Handled' AS "ActivityName",
    i.MODIFIEDDATETIME AS "EventTime",
    i.MODIFIEDBY AS "User",
    i.VENDORACCOUNT AS "VendorNumber",
    i.PURCHASEORDERNUMBER AS "PurchaseOrderNumber",
    i.INVOICEAMOUNT AS "InvoiceAmount",
    'Matched' AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    i.MODIFIEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendInvoiceInfoTableEntity i
WHERE i.LASTMATCHSTATUS = 'Passed' AND i.MODIFIEDDATETIME > i.CREATEDDATETIME

UNION ALL

-- 7. Invoice Sent For Approval, 8. Invoice Approved, 9. Invoice Rejected
SELECT
    w.CONTEXT_INVOICENUMBER AS "InvoiceNumber",
    CASE w.TRACKINGSTATUS
        WHEN 'Submitted' THEN 'Invoice Sent For Approval'
        WHEN 'Completed' THEN 'Invoice Approved'
        WHEN 'Canceled' THEN 'Invoice Rejected'
        ELSE CONCAT('Workflow: ', w.TRACKINGSTATUS)
    END AS "ActivityName",
    w.CREATEDDATETIME AS "EventTime",
    w.USERID AS "User",
    i.VENDORACCOUNT AS "VendorNumber",
    i.PURCHASEORDERNUMBER AS "PurchaseOrderNumber",
    i.INVOICEAMOUNT AS "InvoiceAmount",
    w.TRACKINGSTATUS AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    w.CREATEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM WorkflowTrackingStatusTableEntity w
JOIN VendInvoiceInfoTableEntity i ON w.CONTEXT_RECID = i.RECID AND w.CONTEXT_TABLEID = i.TABLEID
WHERE w.TRACKINGTYPE = 'Approval'

UNION ALL

-- 10. Payment Block Set
SELECT
    v.INVOICENUMBER AS "InvoiceNumber",
    'Payment Block Set' AS "ActivityName",
    v.MODIFIEDDATETIME AS "EventTime",
    v.MODIFIEDBY AS "User",
    v.ACCOUNTNUM AS "VendorNumber",
    NULL AS "PurchaseOrderNumber",
    v.AMOUNT AS "InvoiceAmount",
    'Blocked' AS "InvoiceStatus",
    v.DUEDATE AS "PaymentDueDate",
    v.MODIFIEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendTrans v
WHERE v.BLOCKED = 'Yes'

UNION ALL

-- 11. Payment Block Released
SELECT
    v.INVOICENUMBER AS "InvoiceNumber",
    'Payment Block Released' AS "ActivityName",
    v.MODIFIEDDATETIME AS "EventTime",
    v.MODIFIEDBY AS "User",
    v.ACCOUNTNUM AS "VendorNumber",
    NULL AS "PurchaseOrderNumber",
    v.AMOUNT AS "InvoiceAmount",
    'Open' AS "InvoiceStatus",
    v.DUEDATE AS "PaymentDueDate",
    v.MODIFIEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendTrans v
WHERE v.BLOCKED = 'No' AND v.MODIFIEDDATETIME > v.CREATEDDATETIME

UNION ALL

-- 12. Invoice Posted
SELECT
    vj.INVOICENUM AS "InvoiceNumber",
    'Invoice Posted' AS "ActivityName",
    vj.POSTINGDATE AS "EventTime",
    vj.CREATEDBY AS "User",
    vj.INVOICEACCOUNT AS "VendorNumber",
    vj.PURCHID AS "PurchaseOrderNumber",
    vj.INVOICEAMOUNT AS "InvoiceAmount",
    'Posted' AS "InvoiceStatus",
    vj.DUEDATE AS "PaymentDueDate",
    vj.POSTINGDATE AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendInvoiceJour vj

UNION ALL

-- 13. Payment Scheduled
SELECT
    l.INVOICENUMBER AS "InvoiceNumber",
    'Payment Scheduled' AS "ActivityName",
    l.CREATEDDATETIME AS "EventTime",
    l.CREATEDBY AS "User",
    l.ACCOUNTDISPLAYVALUE AS "VendorNumber",
    NULL AS "PurchaseOrderNumber",
    l.DEBITAMOUNT + l.CREDITAMOUNT AS "InvoiceAmount",
    'Scheduled for Payment' AS "InvoiceStatus",
    l.DUEDATE AS "PaymentDueDate",
    l.CREATEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM LedgerJournalTransVendPaymEntity l

UNION ALL

-- 14. Payment Executed
SELECT
    vs.INVOICENUMBER AS "InvoiceNumber",
    'Payment Executed' AS "ActivityName",
    vs.TRANSDATE AS "EventTime",
    vs.CREATEDBY AS "User",
    vs.ACCOUNTNUM AS "VendorNumber",
    NULL AS "PurchaseOrderNumber",
    vs.SETTLEMENTAMOUNT AS "InvoiceAmount",
    'Paid' AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    vs.TRANSDATE AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendSettlement vs;

貴社の購買から支払いまで - 請求書処理データテンプレート

貴社の購買から支払いまで - 請求書処理データテンプレート

購買から支払いまで - 請求書処理属性

購買から支払いまで - 請求書処理アクティビティ

抽出ガイド

Dynamics 365 データ管理フレームワークのエクスポート

ステップ

設定

a クエリ例 config

Bring Your Own Database (BYOD) を介した直接SQLクエリ

ステップ

設定

a クエリ例 sql

Dynamics 365 OData REST APIを使用するPythonスクリプト

ステップ

設定

a クエリ例 python

Microsoft Power Platform Dataflow抽出

ステップ

設定

a クエリ例 config

今すぐ始めますか？

今すぐ「購買から支払いまで」の請求書処理を最適化しましょう

貴社の購買から支払いまで - 請求書処理データテンプレート

貴社の購買から支払いまで - 請求書処理データテンプレート

購買から支払いまで - 請求書処理属性

購買から支払いまで - 請求書処理アクティビティ

抽出ガイド

Dynamics 365 データ管理フレームワークのエクスポート

ステップ

設定

a クエリ例 config

Bring Your Own Database (BYOD) を介した直接SQLクエリ

ステップ

設定

a クエリ例 sql

Dynamics 365 OData REST APIを使用するPythonスクリプト

ステップ

設定

a クエリ例 python

Microsoft Power Platform Dataflow抽出

ステップ

設定

a クエリ例 config

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

今すぐ始めますか？

今すぐ「購買から支払いまで」の請求書処理を最適化しましょう