> 継続的なプロセス改善 > 調達から支払いまでの購買依頼 > Microsoft Dynamics 365 > データテンプレート

調達から支払いまで：購買依頼のデータテンプレート

Microsoft Dynamics 365

← 改善ガイドに戻る

調達から支払いまで：購買依頼の属性(17) 調達から支払いまで：購買依頼のアクティビティ(12) データ抽出ガイド(3)

調達から支払いまで：購買依頼のデータテンプレート

このテンプレートでは、収集する主要な属性と追跡する重要なアクティビティを示し、購買依頼プロセスを詳しく分析するための準備を整えます。データの抽出方法も案内しているため、詳細な分析に向けてイベントログを効率よく準備できます。

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

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

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

調達から支払いまで：購買依頼の属性

調達から支払いまでの購買依頼プロセスを詳しく分析するために、イベントログに含めることを推奨するデータフィールドです。

5 必須 6 推奨 6 任意

	名前	説明
	アクティビティ名 ActivityName	購買依頼プロセスで発生した特定の業務イベントまたはステップの名前です。
説明この属性には、購買依頼のライフサイクルで実行された各アクティビティの名前が記録されます。例として、「購買依頼の作成」「承認ステップの承認」「発注書の作成」などがあります。これらのアクティビティが、検出されたプロセスマップのノードになります。アクティビティの順序や頻度、アクティビティ間の所要時間を分析することが、プロセスマイニングの中心です。ボトルネックや手戻りのループ、標準的な処理の流れからの逸脱を特定し、業務の非効率な箇所を把握できます。重要な理由この属性でプロセスマップの各ステップを定義し、購買依頼のワークフローを視覚化・分析して、処理の流れを把握できます。入手先通常、Microsoft Dynamics 365のステータス変更ログやワークフロー履歴テーブル、WorkflowTrackingStatusTableなどのイベントテーブルから取得します。例購買依頼を承認に提出承認ステップの承認購買依頼の変更
	イベント時刻 EventTime	特定のアクティビティまたはイベントが発生した正確な日時です。
説明イベント時刻（タイムスタンプ）は、業務イベントがシステムに記録された日時を示します。時間に基づくプロセス分析の基礎となるデータです。この属性は、サイクルタイムや所要時間、アクティビティ間の待ち時間の算出に欠かせません。プロセスのパフォーマンスやボトルネックの分析、SLAの遵守状況のモニタリングにも使われます。正確なタイムスタンプは、信頼性の高いプロセスマイニング分析に不可欠です。重要な理由イベントの時系列を把握できるため、プロセスの所要時間の算出やボトルネックの特定、時間の経過に伴うパフォーマンスの分析に必要です。入手先ワークフロー履歴テーブルや文書ログテーブルに記録されています。ステータス変更やイベントの各レコードに関連付けられた「CreatedDateTime」または「ModifiedDateTime」フィールドが該当します。例 2023-10-26T10:00:00Z2023-10-26T11:30:15Z2023-10-27T14:22:05Z
	購買依頼ID PurchaseRequisitionId	購買依頼を一意に識別するIDで、ケースを識別する主キーとして使われます。
説明購買依頼IDは、商品やサービスの1件の依頼に関するすべてのアクティビティを結び付ける中心的なキーです。作成から最終承認、完了まで、各購買依頼の処理をこの一意のIDで追跡します。プロセスマイニングでは、この属性を使って購買依頼ごとの一連の処理を再構成します。個々のケースについて、プロセスのバリアントやサイクルタイム、コンプライアンスを分析し、ライフサイクル全体を把握できます。重要な理由関連するすべてのイベントを1つのプロセスインスタンスにまとめ、購買依頼ごとのライフサイクルを最初から最後まで分析するために欠かせません。入手先通常、Microsoft Dynamics 365のPurchReqTableなど、購買依頼ヘッダーを管理するメインテーブルの主キーです。例 PR-001254PR-001255PR-001256
	ソースシステム SourceSystemId	データの抽出元となる記録システムです。
説明この属性は、イベントデータの発生元となるソースシステムを示します。この場合は「Microsoft Dynamics 365」です。複数のシステムが連携する環境では、データの来歴やコンテキストを把握するうえで重要な項目です。分析では、複数のシステムにまたがるプロセスを区別したり、データが単一の信頼できる情報源から取得されたことを確認したりできます。データの検証や、正しいデータセットに基づく分析を行ううえで役立ちます。重要な理由データの発生元に関するコンテキストを把握できます。データガバナンスや検証、複数のシステムが連携する環境で重要です。入手先データの抽出・変換時に追加する固定値「Microsoft Dynamics 365」です。例 Microsoft Dynamics 365 F&OD365MSD365
	最終データ更新日時 LastDataIngestionTimestamp	データを最後に抽出し、プロセスマイニングツールに読み込んだ日時です。
説明この属性は、分析対象データの新しさを示します。ソースシステムから最後にデータを更新した日時を確認できます。Dynamics 365自体のフィールドではなく、データの取り込み時に追加されるメタデータです。このタイムスタンプは、インサイトがどの時点のデータに基づいているかを把握するうえで重要です。リアルタイムのデータか、特定の時点のスナップショットかを確認できるため、分析結果の妥当性を判断しやすくなります。重要な理由データがいつの時点のものかを把握できるため、分析対象期間とインサイトの妥当性を確認できます。入手先データの取り込みまたはETL処理の際に生成され、データセットに追加される値です。例 2024-05-20T08:00:00Z2024-05-21T08:00:00Z2024-05-22T08:00:00Z
	ユーザー User	アクティビティを実行した人のユーザーIDまたは名前です。
説明この属性は、購買依頼の提出や依頼の承認など、特定のプロセスステップを実行した従業員またはシステムユーザーを示します。ユーザーID、氏名、メールアドレスなどが該当します。ユーザー別にアクティビティを分析すると、研修の必要性や高い成果を上げている個人・チーム、業務量の分布を把握できます。また、職務分掌などのコンプライアンス分析や、異なるユーザーロールがプロセスにどう関わるかを理解するうえでも欠かせません。重要な理由ユーザーごとの行動や業務量、パフォーマンスを分析できます。リソース管理や研修機会の特定に役立ちます。入手先通常、ワークフロー履歴テーブル（例：WorkflowTrackingStatusTable）またはトランザクションテーブル（例：PurchReqTable）に記録され、ユーザーテーブル（例：UserInfo）と関連付けられています。例 j.smitha.joness.patel
	承認ステップ ApprovalStep	ワークフロー内の特定の承認ステップの名前または段階です。
説明この属性は、「マネージャー承認」や「財務承認」など、承認ワークフロー内の特定の段階を示します。一般的なアクティビティ名よりも詳細な情報を確認できます。「承認ステップのボトルネック分析」に欠かせない属性です。各承認ステップにかかった時間を追跡することで、プロセス全体の遅延につながっている段階を特定できます。対象を絞った対策を講じ、ワークフローの効率を高められます。重要な理由承認ワークフローを詳細に分析し、ボトルネックの原因となっている段階を特定できます。入手先この情報は、WorkflowTrackingStatusTableなどのワークフロー履歴テーブルに含まれており、設定されたワークフローの各ステップが記録されています。例マネージャー承認部門長承認財務確認
	緊急度 UrgencyLevel	購買依頼の緊急度を「高」「中」「低」などで分類したものです。
説明緊急度（優先度）は、依頼した商品やサービスがどれほど早く必要かを示します。この属性は、承認経路の決定や承認者の作業の優先順位付けに使われることがあります。この属性を分析すると、優先度の設定が効果的かどうかを確認できます。たとえば、緊急度が「高」の購買依頼と「低」の購買依頼でサイクルタイムを比較できます。大きな差がなければ、優先度フィールドが無視されている、または適切に使われていない可能性があります。これは「緊急度の影響分析」ダッシュボードで確認できる重要なインサイトです。重要な理由優先度の設定によって緊急性の高い依頼が迅速に処理されているかを評価し、緊急度の分類が不適切に使われている可能性を把握できます。入手先 PurchReqTableの標準フィールドまたはカスタムフィールドとして設定されている場合があります。フィールドの有無や名前は、システム設定によって異なります。例高中低
	購買依頼のステータス RequisitionStatus	購買依頼の現在または最終的なステータスです。
説明この属性は、「確認中」「承認済み」「却下」「クローズ」など、各時点での購買依頼全体のステータスを示します。多くの場合、ケース単位で最終結果を表す属性です。最終ステータスを分析すると、プロセス全体の結果を把握できます。たとえば、「却下」や「取り下げ」となった購買依頼が多い場合、依頼の初期段階に問題がある、または承認プロセスが煩雑である可能性があります。成功率やプロセス効率の測定にも欠かせません。重要な理由ケースごとの結果が明確になり、承認率、却下率、取り下げ率など、重要業績評価指標（KPI）の分析に役立ちます。入手先ステータスのフィールドは通常、購買依頼ヘッダーテーブルのPurchReqTableにあり、「Status」または「PurchReqStatus」という名前が付いています。例承認済み確認中却下下書き
	購買依頼の合計金額 RequisitionTotalAmount	購買依頼の合計金額です。
説明この属性には、購買依頼のすべての明細の合計金額が記録されます。金額が大きいほど承認ワークフローが複雑になり、承認ステップが増えることがあります。プロセス分析では、金額に基づく絞り込みや分析に欠かせない属性です。「高額の購買依頼は承認に時間がかかるか」「現在プロセス内で滞留している購買依頼の金額はいくらか」といった問いに答えるのに役立ちます。プロセスのパフォーマンスを財務面から把握できます。重要な理由分析に財務面の視点を加え、高額案件の優先順位付けや、金額がプロセスの動きに与える影響の把握に役立ちます。入手先この値は通常、購買依頼ヘッダーテーブルに記録されています。または、購買依頼明細テーブル（PurchReqLine）の明細金額を合計して算出します。例 1500.0025000.50500.75
	部門 Department	依頼者の部門、または購買依頼に関連付けられたコストセンターです。
説明この属性は、購買依頼を起票した事業部門またはコストセンターを示します。例として、「マーケティング」「IT」「オペレーション」などがあります。通常、購買依頼ヘッダーに記録されています。部門別にプロセスを分けて分析することは、比較分析に欠かせません。サイクルタイムが最も長い部門や、却下率が最も高い部門、変更が最も頻繁な部門を確認できます。こうしたインサイトをもとに、各部門のニーズに合わせて改善策を検討できます。重要な理由事業部門ごとのプロセスパフォーマンスを絞り込んで比較し、部門固有の傾向やボトルネック、非効率な箇所を明らかにできます。入手先この情報は通常、購買依頼ヘッダー（PurchReqTable）に保存され、Dynamics 365の財務分析コードの設定に関連付けられています。例 IT部門財務業務
	修正回数 AmendmentCount	購買依頼が修正された合計回数です。
説明購買依頼のケースごとに「購買依頼の修正」アクティビティの発生回数を数える、計算された数値属性です。「購買依頼の修正頻度」ダッシュボードと「購買依頼の修正率」の重要業績評価指標（KPI）に欠かせません。ケースごとの手戻りの量を数値化し、修正や非効率が多い購買依頼、部門、ユーザーを特定しやすくします。依頼の初期品質を高める取り組みの対象を絞るのに役立ちます。重要な理由ケース内の手戻りを数値化し、修正の頻度とプロセス効率への影響を簡単に測定・分析できます。入手先計算属性です。データ変換時に、一意のPurchaseRequisitionIdごとに「購買依頼の修正」アクティビティを数えて算出します。例 013
	初回承認済みかどうか IsFirstPass	事前の修正や却下を経ずに購買依頼が承認されたかどうかを示すフラグです。
説明購買依頼の承認までの経路に「購買依頼の修正」または「承認ステップでの却下」のアクティビティが含まれない場合に「true」、含まれる場合に「false」となる、計算された真偽値属性です。「購買依頼の初回承認率」の重要業績評価指標（KPI）に直接役立ちます。ケース単位で手戻りの有無を明確に示すため、プロセス効率を簡単に分析できます。初回承認率が低い場合、初期データの品質や要件の明確さに問題がある可能性があり、プロセス改善の余地を示します。重要な理由手戻りが発生したケースを特定してプロセスの品質と効率を直接測定し、初回で正しく完了した割合に関する重要業績評価指標（KPI）を支援します。入手先計算属性です。データ変換時に各ケースのアクティビティの全順序を分析し、承認前に手戻りのアクティビティがないことを確認して算出します。例 truefalse
	承認ワークフローの経路 ApprovalWorkflowPath	実行された承認ステップの順序を表します。
説明この属性は、購買依頼ごとの承認ステップの順序を連結して作成する派生フィールドです。たとえば、「マネージャー承認 → 部門長承認 → 財務承認」のように表します。承認サブプロセスのバリアントを要約できます。「コンプライアンス逸脱モニター」ダッシュボードで重要な役割を果たします。実際のワークフロー経路を事前に定めた標準または想定経路と比較することで、ポリシー違反や業務上のリスクにつながる可能性のある、コンプライアンスに適合しない、または通常とは異なるプロセスの流れを簡単に検出できます。重要な理由プロセスのバリアントを文字列で明確に示すため、コンプライアンス分析が容易になり、標準手順からの逸脱を見つけやすくなります。入手先この属性は標準フィールドではありません。データ変換時に、各ケースの「ApprovalStep」の値を時系列順に連結して作成する必要があります。例マネージャー → ディレクターマネージャー → ディレクター → 財務担当副社長マネージャー → 自動承認
	承認者グループ ApproverGroup	承認ステップを担当するユーザーグループまたは役割です。
説明この属性は、「財務承認者」や「ITマネージャー」など、特定の承認タスクを担当するグループ、役割、またはキューを示します。承認者グループごとにプロセスのパフォーマンスを分析すると、作業負荷の分布を把握し、人員やトレーニングが不足しているグループを特定できます。承認を担当するチームごとにパフォーマンスを絞り込めるため、「承認ステップのボトルネック分析」ダッシュボードにも役立ちます。重要な理由承認チーム間のパフォーマンスの違いを把握し、特定のグループでリソースが不足している可能性や、トレーニングが必要な領域を明らかにできます。入手先この情報はワークフロー履歴（例：WorkflowTrackingStatusTable）に含まれており、各タスクに割り当てられたユーザーまたはユーザーグループが記録されています。例財務承認者ITマネージャー上級管理職
	発注書番号 PurchaseOrderNumber	購買依頼から作成された発注書の識別子です。
説明この属性には、承認済みの購買依頼から作成された発注書の一意のIDが保存されます。購買依頼プロセスと、その後の調達プロセスを結び付ける情報です。「購買依頼から発注書への変換時間」を分析するうえで、この番号の追跡は欠かせません。購買依頼が調達から支払いまでのサイクルの次の段階へ正常に進んだことを確認でき、購買依頼と発注書の両方にまたがるエンドツーエンドのプロセス分析が可能になります。重要な理由購買依頼と後続の発注書を結び付け、購買依頼から発注書への変換を分析できます。また、調達から支払いまでのプロセスの各段階を関連付けられます。入手先この情報は通常、発注書の作成後に購買依頼明細テーブル（PurchReqLine）に記録され、PurchTableに関連付けられます。例 PO-000987PO-000988PO-000989
	通貨 Currency	購買依頼の金額に使用される通貨コードです。
説明この属性は、購買依頼の合計金額に使用される通貨（USD、EUR、GBPなど）を示します。複数の通貨を扱う多国籍組織の財務分析では特に重要です。通貨属性を使うことで、財務データを適切に処理し、集計できます。金額を正しく解釈できるほか、共通通貨への換算により、地域や事業部門をまたいだ正確な報告や比較が可能になります。重要な理由財務属性を解釈するために必要なコンテキストを提供し、複数通貨を扱う環境で金額を正確に解釈・集計できます。入手先このフィールドは通常、購買依頼ヘッダーテーブルのPurchReqTableにあり、金額フィールドの近くに配置されています。例 USDEURGBP

必須推奨任意

調達から支払いまで：購買依頼のアクティビティ

購買依頼ワークフローを正確に把握・分析するために、イベントログに記録する必要があるプロセスのステップと節目です。

7 推奨 5 任意

	アクティビティ	説明
	承認ステップの承認	承認者が割り当てられたタスクを完了し、その段階で購買依頼を承認します。これにより、購買依頼は次のステップまたは最終承認へ進みます。
重要な理由各承認段階の処理時間を測定し、ワークフローの効率が高い箇所を特定できます。バリアント分析の重要な要素です。入手先ユーザーが「Approve」の結果で作業項目を完了した時点で、WorkflowTrackingStatusTableに明示的に記録されます。記録ワークフロー履歴ログから、「Approve」の結果を伴う「WorkItemCompleted」イベントを特定します。イベントタイプ explicit
	発注書の作成	承認済みの購買依頼明細が発注書明細に変換され、調達チームへ引き継がれます。購買依頼明細と発注書明細を関連付けて記録します。
重要な理由これは購買依頼と後続の調達プロセスをつなぐ重要な節目です。「購買依頼から発注書への変換時間」を測定するうえで欠かせません。入手先購買依頼のケースに関連付けられたPurchReqLineのIDを参照するレコードを、PurchLineテーブルから検索して推定します。記録関連付け用の参照フィールド（例：PurchReqLineRefId）を使って、PurchReqLineとPurchLineを結合します。イベントタイプ inferred
	購買依頼の作成	このイベントは、購買依頼レコードが下書き状態で初めて作成されたことを示します。購買依頼ヘッダーの作成タイムスタンプから記録します。
重要な理由プロセスの開始点となるこのアクティビティは、購買依頼のライフサイクル全体の所要時間や、日ごとの処理件数を分析するうえで欠かせません。入手先新しい購買依頼IDごとに、PurchReqTableの「createdDateTime」フィールドからこのアクティビティを推定します。記録 PurchReqTableレコードの作成タイムスタンプを使用します。イベントタイプ inferred
	購買依頼の却下	承認ワークフローで購買依頼が却下され、それ以降は処理されない状態です。購買依頼の処理が終了する最終的な失敗状態を示します。
重要な理由この終了イベントは、却下率全体の分析や、依頼が却下された場合の財務面・業務面への影響を把握するうえで重要です。入手先ワークフローの完了時にステータスが「Rejected」となったことを、WorkflowTrackingStatusTableから明示的に取得します。このとき、PurchReqTableのステータスフィールドも更新されます。記録ワークフローの「Completion」イベントでステータスが「Rejected」のものを抽出するか、PurchReqTableのステータス変更を追跡します。イベントタイプ explicit
	購買依頼の完了	購買依頼全体の処理が完了した状態です。すべての明細が発注書に変換されるか、キャンセルされています。最終的な正常終了状態を示します。
重要な理由このアクティビティは、購買依頼のライフサイクルが正常に完了したことを示します。プロセス全体の所要時間を測定する際の最終地点です。入手先このステータスは通常、計算または推定されます。関連するすべてのPurchReqLineレコードが「Closed」や「Cancelled」などの最終ステータスに達した時点で完了と判断します。記録 PurchReqTableに関連するすべての子PurchReqLineレコードが最終ステータスになっているかを確認し、このイベントを導出します。イベントタイプ calculated
	購買依頼の承認	購買依頼がワークフローで必要なすべての承認ステップを通過した状態です。ワークフローインスタンスが最終承認済みステータスで完了した時点で記録します。
重要な理由これは承認サイクルの終了と調達段階の開始を示す重要な節目です。「購買依頼の承認サイクルタイム」を測定する際の終了イベントになります。入手先ワークフローの完了時にWorkflowTrackingStatusTableから明示的に取得します。また、PurchReqTableの「Status」フィールドも「Approved」に更新されます。記録ワークフローの「Completion」イベントでステータスが「Approved」のものを抽出するか、PurchReqTableのステータス変更を追跡します。イベントタイプ explicit
	購買依頼を承認に提出	ユーザーが入力済みの購買依頼を提出すると、正式な承認ワークフローが開始されます。システムのワークフローエンジンに明示的に記録される操作です。
重要な理由このアクティビティは、承認サイクルの開始を示す重要な節目です。「購買依頼の承認サイクルタイム」と「初回承認率」を測定する起点になります。入手先購買依頼に対する「Submission」イベントが記録されるWorkflowTrackingStatusTable、または同様のワークフロー履歴テーブルから取得します。記録購買依頼に関連付けられた「Submission」または「Start」イベントを、ワークフロー履歴ログから抽出します。イベントタイプ explicit
	承認ステップの却下	承認者が割り当てられたタスクを却下すると、通常、購買依頼は修正のため依頼者に差し戻されます。ワークフローエンジンに明示的に記録される操作です。
重要な理由このアクティビティは「購買依頼の却下率」の算出に欠かせません。却下が発生しやすい段階を特定し、プロセス改善が必要な箇所を明らかにできます。入手先ユーザーが「Reject」の結果で作業項目を完了した時点で、WorkflowTrackingStatusTableに明示的に記録されます。記録ワークフロー履歴ログから、「Reject」の結果を伴う「WorkItemCompleted」イベントを特定します。イベントタイプ explicit
	承認ステップの開始	ワークフローの一環として、個別の承認タスクがユーザーまたはグループに割り当てられます。特定の承認者による待ち時間または処理時間の開始を示します。
重要な理由このアクティビティは「承認ステップのボトルネック分析」に欠かせません。承認段階ごとの待ち時間を測定できます。入手先購買依頼のワークフローインスタンスに新しい作業項目が作成され、割り当てられた時点で、WorkflowTrackingStatusTableから取得します。記録対象の購買依頼に関するワークフロー履歴ログから、「WorkItemCreated」または同様のイベントを特定します。イベントタイプ explicit
	購買依頼の取り下げ	作成者または権限を持つユーザーが、提出後の購買依頼をキャンセルします。この操作により、ワークフローと依頼の処理が終了します。
重要な理由取り下げを追跡すると、需要計画の問題やプロセスの複雑さを特定できます。「購買依頼の取り下げインサイト」ダッシュボードの分析にも役立ちます。入手先 PurchReqTableのステータスが「Cancelled」に変更されたこと、またはWorkflowTrackingStatusTableの「Cancel」イベントから推定します。記録 PurchReqTableのステータスが「Cancelled」に変更されたこと、またはワークフローのキャンセルイベントを検出します。イベントタイプ inferred
	購買依頼の変更	ユーザーが変更のため、提出済みの購買依頼をワークフローから差し戻したときに発生するイベントです。通常、差し戻し操作の後に再提出が行われたことから、このアクティビティを特定します。
重要な理由変更を追跡すると、手戻り、最初の依頼内容の不明確さ、プロセスの非効率を特定できます。「購買依頼の変更頻度」ダッシュボードの分析にも役立ちます。入手先ワークフロー履歴（WorkflowTrackingStatusTable）で「Recall」または「RequestChange」操作を検出して推定できます。また、提出後にPurchReqTableの「modifiedDateTime」フィールドが変更されたことからも推定できます。記録ワークフローの差し戻しイベントを検出するか、提出イベント間のレコードバージョンの変更を確認します。イベントタイプ inferred
	購買依頼明細の完了	購買依頼の個々の明細が処理済みになった状態です。通常、その明細が発注書に完全に変換された後に発生します。
重要な理由購買依頼の履行状況を明細単位で把握でき、発注書への変換が一部にとどまっているか、すべて完了しているかを特定できます。入手先個々のPurchReqLineテーブルのステータスフィールドから推定します。発注済みまたは受領済みを示すステータスであれば、完了と判断できます。記録 PurchReqLineテーブルのステータスフィールドを確認し、「Invoiced」や「Closed」などの最終値を検出します。イベントタイプ inferred

推奨任意

データ抽出ガイド

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

ステップ

データ管理ワークスペースにアクセス：Microsoft Dynamics 365にログインし、Workspacesメニューを開きます。Data managementを選択すると、データのインポートとエクスポートを行う画面が表示されます。
新しいエクスポートプロジェクトを作成：データ管理ワークスペースでExportタイルをクリックします。一意のグループ名と内容がわかる説明を入力し、Project categoryをProjectに設定します。これにより、データ抽出タスクを整理できます。
データエンティティを追加：必要な標準データエンティティをプロジェクトに追加します。Add entityをクリックし、以下を1つずつ検索して追加します。
- Purchase requisition headers
- Purchase requisition lines
- Workflow tracking status table
- Workflow work items
- Purchase order lines V2
エクスポート形式を指定：追加した各エンティティで、CSVやExcelなどのTarget data formatを選択します。パフォーマンスとデータ変換ツールとの互換性を考慮すると、通常はCSVを推奨します。
データにフィルターを適用：エンティティを選択し、フィルターボタンをクリックします。範囲タブでLegal entity（会社コード）を指定し、正しい事業部門のデータを抽出できるようにします。また、データ量を抑えるため、Purchase requisition headersエンティティのCreated date and timeフィールドに日付フィルターを設定することも重要です。まずは3～6か月分のデータから始めることをお勧めします。
エクスポートジョブを実行：すべてのエンティティとフィルターを設定したら、アクションペインでExportをクリックします。システムがジョブパッケージを作成し、処理を開始します。Job historyセクションで進行状況を確認できます。
データパッケージをダウンロード：エクスポートジョブが正常に完了したら、Job historyの詳細を開き、Download packageをクリックします。各エンティティのデータファイルを含むZIPファイルがダウンロードされます。
生のデータをイベントログに変換：エクスポートしたファイルはシステムテーブルの生のデータであり、そのままではイベントログとして使えません。Python、Power Query、ETLプラットフォームなどの外部ツールでデータを結合し、整形する必要があります。主な作業は次のとおりです。
- ヘッダーファイルと明細ファイルを結合します。
- CorrelationIdと購買依頼ヘッダーのRecIdを使って、ワークフローデータを購買依頼に結合します。
- ワークフローテーブルのステータス変更とイベントを、個別のアクティビティ行（Requisition Submitted、Approval Step Approvedなど）に変換します。
- 各アクティビティについて、正しいActivityName、EventTime、PurchaseRequisitionIdを持つ行を作成します。
属性を計算して対応付け：変換時に、ソース列をユーザーや部門などの必要な属性に対応付けます。明細金額を合計してRequisitionTotalAmountなどの派生属性を計算します。SourceSystemIdには固定値（例：'D365_F&O'）を設定し、LastDataIngestionTimestampにはスクリプトの実行時刻を使用します。
出力を仕上げて形式を整える：最終出力は、プロセス内の各イベントを1行ずつ記録した単一のCSVファイルにします。列はPurchaseRequisitionId、ActivityName、EventTimeなど、必要なイベントログの構成に合わせてください。

設定

必要な権限：エクスポートするデータエンティティにアクセスでき、Data managementワークスペースを利用できるセキュリティロールが必要です。たとえば、Data management administratorまたは同等のカスタムロールが該当します。
主なデータエンティティ：
- Purchase requisition headers：主なケース識別子、作成日時、全体のステータスを提供します。
- Purchase requisition lines：依頼された各品目の詳細、金額、発注書との関連情報を含みます。
- Workflow tracking status table：申請、承認、却下、取り消しなど、ワークフローイベントの主なデータソースです。
- Workflow work items：承認プロセスでユーザーに割り当てられた個々のタスクの詳細を示します。
- Purchase order lines V2：購買依頼の明細に関連付けられた発注書の作成日時を確認するために使用します。
日付範囲のフィルタリング：Purchase requisition headersエンティティのCreated date and timeフィールドに、日付範囲のフィルターを必ず適用してください。データ量とプロセスの把握しやすさのバランスを取るため、最初の分析では3～6か月分を推奨します。
会社コードのフィルタリング：意図しない会社やテスト用の会社のデータを抽出しないよう、必ずLegal entityでフィルターを設定してください。これにより、データ量を大幅に減らし、ジョブの処理性能を高められます。
データ変換：この方法では、Dynamics 365の外部で生のエンティティデータを構造化されたイベントログに変換する後処理が必要です。スクリプトやETLツールをご用意ください。

クエリの例 sql

/*
This is not a single executable query. Instead, it is a configuration manifest for a Dynamics 365 Data Management Framework Export Project.
You must add each entity listed below to the project and select the specified fields for export.
The transformation logic to create the final event log must be applied after exporting these files.
*/

-- Entity 1: Purchase requisition headers
-- Purpose: Captures requisition creation, overall status, and header-level attributes.
SELECT
    REQUISITIONNUMBER AS PurchaseRequisitionId,
    REQUISITIONSTATUS AS RequisitionStatus,
    CREATEDDATETIME AS EventTime_RequisitionCreated,
    MODIFIEDDATETIME AS EventTime_RequisitionClosed, -- Used if status is Closed
    PREPARERPERSONNELNUMBER AS User_Preparer,
    REQUESTERPERSONNELNUMBER AS User_Requester,
    DEFAULTLEDGERDIMENSIONDISPLAYVALUE AS Department, -- Or similar dimension field
    REQUISITIONTOTAL AS RequisitionTotalAmount
FROM PurchaseRequisitionHeaderEntity;

-- Entity 2: Purchase requisition lines
-- Purpose: Provides line-level details, amounts, and links to Purchase Orders.
SELECT
    REQUISITIONNUMBER AS PurchaseRequisitionId,
    LINENUMBER,
    REQUISITIONINGSTATUS AS LineStatus,
    MODIFIEDDATETIME AS EventTime_LineClosed, -- Used if status is Closed
    PURCHASEORDERNUMBER,
    PURCHASEORDERLINENUMBER
FROM PurchaseRequisitionLineEntity;

-- Entity 3: Workflow tracking status table
-- Purpose: The primary source for all workflow-driven activities.
-- Note: Requires joining to PurchReqTable on RecId = CorrelationId post-export.
SELECT
    CONTEXT, -- Contains information like step name
    CORRELATIONID, -- Links to source document's RecId
    CREATEDDATETIME AS EventTime_WorkflowStep,
    TRACKINGSTATUS AS ActivityName, -- (e.g., Submitted, Approved, Rejected, Canceled)
    USERID AS User
FROM WorkflowTrackingStatusTableEntity;

-- Entity 4: Workflow work items
-- Purpose: Captures the start of an approval task assigned to a user.
-- Note: Requires joining to PurchReqTable on RecId = CorrelationId post-export.
SELECT
    CORRELATIONID, -- Links to source document's RecId
    CREATEDDATETIME AS EventTime_ApprovalStepStarted,
    USERID AS User, -- The user assigned the task
    DESCRIPTION AS ApprovalStep
FROM WorkflowWorkItemTableEntity;

-- Entity 5: Purchase order lines V2
-- Purpose: Used to find the creation date of the resulting Purchase Order.
-- Note: Requires joining to PurchaseRequisitionLineEntity on PO/Line number post-export.
SELECT
    PURCHASEORDERNUMBER,
    LINENUMBER,
    CREATEDDATETIME AS EventTime_PurchaseOrderCreated
FROM PurchaseOrderLinesV2Entity;

ステップ

Azure Active Directoryアプリケーションを登録：Azureポータルで新しいアプリケーションを登録します。このアプリケーションを使ってDynamics 365 APIの認証を行います。アプリケーション（クライアント）IDとディレクトリ（テナント）IDを控えてください。
クライアントシークレットを作成：Azureで登録したアプリケーションの「Certificates & secrets」から、新しいクライアントシークレットを作成します。シークレットの値は後から再表示できないため、安全な場所にコピーしてください。
APIのアクセス許可を付与：アプリケーションの「API permissions」セクションで「Dynamics ERP」のアクセス許可を追加します。「Delegated permissions」を選択し、Financials.ReadWrite.Allまたは、より制限された読み取り専用のアクセス許可を付与します。アクセス許可に対する管理者の同意も付与してください。
Pythonライブラリをインストール：Pythonがインストールされていることを確認します。次に、pipを使って必要なライブラリをインストールします：pip install requests pandas。
Pythonスクリプトを設定：提供されたPythonスクリプトをファイル（例：extract_d365_requisitions.py）にコピーします。スクリプトの先頭にあるプレースホルダーに、Dynamics 365のURL、テナントID、クライアントID、クライアントシークレット、対象の日付範囲、会社IDを入力します。
ODataエンティティを確認：スクリプトは主に3つのデータエンティティを照会します。購買依頼の主な詳細にはPurchaseRequisitionHeaders、明細や発注書への変換情報にはPurchaseRequisitionLines、申請や承認などのワークフローイベントにはWorkflowTrackingStatusTableを使用します。
スクリプトを実行：コマンドラインからpython extract_d365_requisitions.pyを実行します。スクリプトが認証を行い、各アクティビティのデータを取得して、APIのページネーションを自動的に処理します。
データを変換：スクリプトはAPI呼び出しで取得した生のJSONデータを処理します。レコードを順に読み込み、12種類の業務アクティビティごとに行を作成します。また、ソースフィールドをPurchaseRequisitionId、ActivityName、EventTimeなどの標準イベントログ列に対応付けます。
イベントを統合して標準化：作成したイベントを1つのリストにまとめ、pandasのDataFrameに変換します。SourceSystemIdやLastDataIngestionTimestampなどの固定列も追加します。
CSVにエクスポート：最終的なDataFrameをd365_purchase_requisition_log.csvという名前のCSVファイルにエクスポートします。このファイルはプロセスマイニングツールに直接アップロードできる形式です。UTF-8でエンコードされていることを確認してください。

設定

前提条件：アプリケーション登録に使用するAzureサブスクリプションへのアクセスが必要です。Azure Active Directoryからアプリケーション（クライアント）ID、クライアントシークレット、テナントIDを取得してください。スクリプトの実行ユーザーには、Dynamics 365 Finance and OperationsのOData APIエンドポイントへのアクセス権を付与する必要があります。
APIエンドポイントの設定：スクリプトにはDynamics 365環境のベースURLが必要です。通常はhttps://[your-environment-name].operations.dynamics.comの形式です。
日付範囲：スクリプトのSTART_DATEとEND_DATEの値を設定し、抽出期間を指定します。データ量と分析に必要な情報のバランスを取るため、最初は3～6か月分を推奨します。
会社のフィルター：スクリプトはCOMPANY_ID変数を使い、特定の法人に絞り込む設定になっています。すべての会社のデータを抽出するには、ODataフィルターを変更し、リクエストヘッダーにcross-company=trueを含める必要がある場合があります。
処理性能に関する考慮事項：ODataクエリで$selectを使ってイベントログに必要な列だけを取得するため、処理性能が向上します。また、大規模なデータセットでもAPIに過度な負荷をかけないよう、ページネーションを処理します。過去のデータを大量に読み込む場合は、日付範囲を短く区切ってスクリプトを実行してください。

クエリの例 python

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

class=class="hl-string">"hl-comment"># --- Configuration ---
class=class="hl-string">"hl-comment"># Replace with your Dynamics 365 environment details
D365_URL = class="hl-string">"https://[your-d365-url].operations.dynamics.com"
TENANT_ID = class="hl-string">"[your-tenant-id]"
CLIENT_ID = class="hl-string">"[your-client-id]"
CLIENT_SECRET = class="hl-string">"[your-client-secret]"

class=class="hl-string">"hl-comment"># --- Parameters ---
class=class="hl-string">"hl-comment"># Set the data extraction window
START_DATE = class="hl-string">"2023-01-01T00:00:00Z"
END_DATE = class="hl-string">"2023-12-31T23:59:59Z"
COMPANY_ID = class="hl-string">"[YourCompanyLegalEntity]" class=class="hl-string">"hl-comment"># e.g., class="hl-string">"USMF"
OUTPUT_FILENAME = class="hl-string">"d365_purchase_requisition_log.csv"


def get_access_token():
    class="hl-string">"""Authenticates with Azure AD to get an access token."""
    auth_url = fclass="hl-string">"https://login.microsoftonline.com/{TENANT_ID}/oauth2/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">'resource': D365_URL
    }
    response = requests.post(auth_url, data=payload)
    response.raise_for_status()
    return response.json()[class="hl-string">'access_token']

def fetch_data(access_token, entity_url):
    class="hl-string">"""Fetches all pages of data from a given D365 OData entity URL."""
    all_records = []
    headers = {
        class="hl-string">'Authorization': fclass="hl-string">'Bearer {access_token}',
        class="hl-string">'Accept': class="hl-string">'application/json'
    }
    while entity_url:
        response = requests.get(entity_url, headers=headers)
        response.raise_for_status()
        data = response.json()
        all_records.extend(data[class="hl-string">'value'])
        entity_url = data.get(class="hl-string">'@odata.nextLink')
    return all_records

def main():
    class="hl-string">"""Main function to extract, transform, and save the event log."""
    print(class="hl-string">"Acquiring access token...")
    access_token = get_access_token()
    events = []
    last_ingestion_ts = datetime.now(timezone.utc).isoformat()

    class=class="hl-string">"hl-comment"># 1. Fetch Purchase Requisition Headers for class="hl-string">'Created' and class="hl-string">'Closed' events
    print(class="hl-string">"Fetching Purchase Requisition Headers...")
    pr_headers_url = (
        fclass="hl-string">"{D365_URL}/data/PurchaseRequisitionHeaders?" 
        fclass="hl-string">"$filter=dataAreaId eq '{COMPANY_ID}' and CreatedDateTime ge {START_DATE} and CreatedDateTime le {END_DATE}" 
        fclass="hl-string">"&$select=RequisitionNumber,RequisitionStatus,CreatedDateTime,CreatedBy,RequestingDepartmentName,RequisitionTotalAmount,RequisitionUrgencyLevel"
    )
    pr_headers = fetch_data(access_token, pr_headers_url)

    for prh in pr_headers:
        case_id = prh.get(class="hl-string">'RequisitionNumber')
        class=class="hl-string">"hl-comment"># Activity: Requisition Created
        events.append({
            class="hl-string">'PurchaseRequisitionId': case_id,
            class="hl-string">'ActivityName': class="hl-string">'Requisition Created',
            class="hl-string">'EventTime': prh.get(class="hl-string">'CreatedDateTime'),
            class="hl-string">'User': prh.get(class="hl-string">'CreatedBy'),
            class="hl-string">'Department': prh.get(class="hl-string">'RequestingDepartmentName'),
            class="hl-string">'RequisitionStatus': prh.get(class="hl-string">'RequisitionStatus'),
            class="hl-string">'RequisitionTotalAmount': prh.get(class="hl-string">'RequisitionTotalAmount'),
            class="hl-string">'UrgencyLevel': prh.get(class="hl-string">'RequisitionUrgencyLevel'),
            class="hl-string">'ApprovalStep': None,
            class="hl-string">'ProcessingTime': None
        })
        class=class="hl-string">"hl-comment"># Activity: Requisition Closed
        if prh.get(class="hl-string">'RequisitionStatus') == class="hl-string">'Closed':
            class=class="hl-string">"hl-comment"># Note: We need a reliable timestamp for closure. Using CreatedDateTime as a placeholder.
            class=class="hl-string">"hl-comment"># A better source might be the last workflow approval or line closure date.
            events.append({
                class="hl-string">'PurchaseRequisitionId': case_id,
                class="hl-string">'ActivityName': class="hl-string">'Requisition Closed',
                class="hl-string">'EventTime': prh.get(class="hl-string">'CreatedDateTime'), class=class="hl-string">"hl-comment"># Placeholder timestamp
                class="hl-string">'User': prh.get(class="hl-string">'CreatedBy'), class=class="hl-string">"hl-comment"># Placeholder user
                class="hl-string">'Department': prh.get(class="hl-string">'RequestingDepartmentName'),
                class="hl-string">'RequisitionStatus': class="hl-string">'Closed',
                class="hl-string">'RequisitionTotalAmount': prh.get(class="hl-string">'RequisitionTotalAmount'),
                class="hl-string">'UrgencyLevel': prh.get(class="hl-string">'RequisitionUrgencyLevel'),
                class="hl-string">'ApprovalStep': None,
                class="hl-string">'ProcessingTime': None
            })

    class=class="hl-string">"hl-comment"># 2. Fetch Workflow History for workflow-related events
    print(class="hl-string">"Fetching Workflow Tracking Status Table...")
    workflow_url = (
        fclass="hl-string">"{D365_URL}/data/WorkflowTrackingStatusTable?"
        fclass="hl-string">"$filter=dataAreaId eq '{COMPANY_ID}' and CreatedDateTime ge {START_DATE} and CreatedDateTime le {END_DATE} and startswith(Context,'PurchReq')"
        fclass="hl-string">"&$select=Context,CreatedDateTime,TrackingType,User,WorkItemSubject"
    )
    workflow_items = fetch_data(access_token, workflow_url)

    for item in workflow_items:
        context_parts = item.get(class="hl-string">'Context', class="hl-string">'').split(class="hl-string">':')
        if len(context_parts) < 2:
            continue
        case_id = context_parts[1].strip()
        tracking_type = item.get(class="hl-string">'TrackingType')
        activity_map = {
            class="hl-string">'Submission': class="hl-string">'Requisition Submitted for Approval',
            class="hl-string">'Started': class="hl-string">'Approval Step Started',
            class="hl-string">'Completion': class="hl-string">'Approval Step Approved',
            class="hl-string">'Rejection': class="hl-string">'Approval Step Rejected',
            class="hl-string">'Cancellation': class="hl-string">'Requisition Withdrawn',
            class="hl-string">'Recall': class="hl-string">'Requisition Amended',
            class="hl-string">'Approved': class="hl-string">'Requisition Approved',
            class="hl-string">'Fault': class="hl-string">'Requisition Rejected'
        }
        activity_name = activity_map.get(tracking_type)
        if activity_name:
            events.append({
                class="hl-string">'PurchaseRequisitionId': case_id,
                class="hl-string">'ActivityName': activity_name,
                class="hl-string">'EventTime': item.get(class="hl-string">'CreatedDateTime'),
                class="hl-string">'User': item.get(class="hl-string">'User'),
                class="hl-string">'Department': None, class=class="hl-string">"hl-comment"># Department info is not in this entity
                class="hl-string">'RequisitionStatus': None, class=class="hl-string">"hl-comment"># Status info is not in this entity
                class="hl-string">'RequisitionTotalAmount': None,
                class="hl-string">'UrgencyLevel': None,
                class="hl-string">'ApprovalStep': item.get(class="hl-string">'WorkItemSubject'),
                class="hl-string">'ProcessingTime': None
            })

    class=class="hl-string">"hl-comment"># 3. Fetch Purchase Requisition Lines for PO Creation and Line Closure
    print(class="hl-string">"Fetching Purchase Requisition Lines...")
    pr_lines_url = (
        fclass="hl-string">"{D365_URL}/data/PurchaseRequisitionLines?"
        fclass="hl-string">"$filter=dataAreaId eq '{COMPANY_ID}' and CreatedDateTime ge {START_DATE} and CreatedDateTime le {END_DATE}"
        fclass="hl-string">"&$select=RequisitionNumber,PurchaseOrderNumber,IsPrepaymentRequired,LineStatus,ModifiedDateTime,ModifiedBy"
    )
    pr_lines = fetch_data(access_token, pr_lines_url)

    for prl in pr_lines:
        case_id = prl.get(class="hl-string">'RequisitionNumber')
        po_number = prl.get(class="hl-string">'PurchaseOrderNumber')
        line_status = prl.get(class="hl-string">'LineStatus')
        
        class=class="hl-string">"hl-comment"># Activity: Purchase Order Created
        if po_number:
             events.append({
                class="hl-string">'PurchaseRequisitionId': case_id,
                class="hl-string">'ActivityName': class="hl-string">'Purchase Order Created',
                class="hl-string">'EventTime': prl.get(class="hl-string">'ModifiedDateTime'),
                class="hl-string">'User': prl.get(class="hl-string">'ModifiedBy'),
                class="hl-string">'Department': None,
                class="hl-string">'RequisitionStatus': None,
                class="hl-string">'RequisitionTotalAmount': None,
                class="hl-string">'UrgencyLevel': None,
                class="hl-string">'ApprovalStep': fclass="hl-string">"PO: {po_number}",
                class="hl-string">'ProcessingTime': None
            })

        class=class="hl-string">"hl-comment"># Activity: Requisition Line Closed
        if line_status == class="hl-string">'Closed':
             events.append({
                class="hl-string">'PurchaseRequisitionId': case_id,
                class="hl-string">'ActivityName': class="hl-string">'Requisition Line Closed',
                class="hl-string">'EventTime': prl.get(class="hl-string">'ModifiedDateTime'),
                class="hl-string">'User': prl.get(class="hl-string">'ModifiedBy'),
                class="hl-string">'Department': None,
                class="hl-string">'RequisitionStatus': class="hl-string">'Closed',
                class="hl-string">'RequisitionTotalAmount': None,
                class="hl-string">'UrgencyLevel': None,
                class="hl-string">'ApprovalStep': None,
                class="hl-string">'ProcessingTime': None
            })

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

    class=class="hl-string">"hl-comment"># 4. Create and format the DataFrame
    print(class="hl-string">"Formatting data...")
    df = pd.DataFrame(events)
    df[class="hl-string">'SourceSystemId'] = class="hl-string">'Microsoft Dynamics 365'
    df[class="hl-string">'LastDataIngestionTimestamp'] = last_ingestion_ts

    class=class="hl-string">"hl-comment"># Fill forward missing data within each case
    df = df.sort_values(by=[class="hl-string">'PurchaseRequisitionId', class="hl-string">'EventTime'])
    df[[class="hl-string">'Department', class="hl-string">'RequisitionTotalAmount', class="hl-string">'UrgencyLevel']] = \
        df.groupby(class="hl-string">'PurchaseRequisitionId')[[class="hl-string">'Department', class="hl-string">'RequisitionTotalAmount', class="hl-string">'UrgencyLevel']].ffill().bfill()

    class=class="hl-string">"hl-comment"># Ensure required columns exist and are in order
    final_columns = [
        class="hl-string">'PurchaseRequisitionId',
        class="hl-string">'ActivityName',
        class="hl-string">'EventTime',
        class="hl-string">'SourceSystemId',
        class="hl-string">'LastDataIngestionTimestamp',
        class="hl-string">'User',
        class="hl-string">'Department',
        class="hl-string">'RequisitionStatus',
        class="hl-string">'RequisitionTotalAmount',
        class="hl-string">'UrgencyLevel',
        class="hl-string">'ApprovalStep',
        class="hl-string">'ProcessingTime'
    ]
    for col in final_columns:
        if col not in df.columns:
            df[col] = None
    
    df = df[final_columns]

    class=class="hl-string">"hl-comment"># 5. Save to CSV
    df.to_csv(OUTPUT_FILENAME, index=False, encoding=class="hl-string">'utf-8')
    print(fclass="hl-string">"Successfully extracted {len(df)} events to {OUTPUT_FILENAME}")

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

ステップ

Power BI DesktopでMicrosoft Dynamics 365 Financeの標準コネクタを利用できることを確認します。また、ユーザーに必要なデータエンティティ、ワークフロー履歴、購買依頼データ、関連する発注書データへのアクセス権があることを確認してください。
Power BI Desktopで「データを取得」を選択し、Microsoft Dynamics 365 Financeコネクタを選んで、Dynamics 365 FinanceのインスタンスURLを入力します。必要なエンティティを読み取る権限のあるアカウントで認証します。[Your Dynamics 365 Finance instance URL]を、ご利用の環境のインスタンスURLに置き換えてください。
ナビゲーターで、購買依頼のヘッダーと明細のエンティティ、ワークフロー履歴または追跡エンティティ、ユーザーと組織のエンティティ、および導入環境で必要となる発注書のエンティティを選択します。エンティティ名と利用可能なフィールドは環境によって異なります。エンティティのメタデータを確認し、クエリ内の各プレースホルダーを、システムで公開されている対応するエンティティとフィールドに置き換えてください。
選択したエンティティをPower Queryに読み込みます。必要な法人または会社、文書タイプ、抽出期間でデータを絞り込みます。[Start date]と[End date]にはパラメーターを使用し、イベントのタイムスタンプが指定期間内にあるレコードを残します。期間内にワークフローイベントや完了イベントがある場合は、ケース履歴を完全に保つため、開始日より前に作成されたレコードも含めてください。
識別子とタイムスタンプの形式を統一します。購買依頼の識別子をテキストに変換し、すべてのイベントのタイムスタンプをUTCまたは業務で使用するタイムゾーンに統一して、ソースのタイムスタンプ精度を維持します。各イベント行に購買依頼ヘッダーの識別子が含まれていることを確認してください。ワークフローレコードにワークフローの相関識別子しかない場合は、環境で設定されている文書化済みの関連付けを使って購買依頼ヘッダーに結合します。
必要なアクティビティごとにイベントクエリを作成します。各クエリは、Requisition Created、Requisition Submitted for Approval、Requisition Amended、Approval Step Started、Approval Step Approved、Approval Step Rejected、Requisition Approved、Requisition Rejected、Requisition Withdrawn、Purchase Order Created、Requisition Line Closed、Requisition Closedの行を明示的に返す必要があります。ステータスの変更やイベントの順序からProcessMindがアクティビティを推測することはありません。
Requisition Amendedについては、ワークフロー履歴に記録された取り消しと再申請のロジックを適用します。取り消しの後に再申請が行われた場合は、取り消しのタイムスタンプ、またはソースエンティティに記録された変更のタイムスタンプで変更イベントを作成します。ソースシステムに変更として明示的に記録されていない限り、購買依頼のステータスが変わっただけで変更イベントを作成しないでください。
明細と発注書のイベントでは、文書化されたソースの関連付けを使って購買依頼の明細と発注書の明細を結合します。PurchaseRequisitionIdをケース識別子とするイベントログでは、明細レベルのイベントを集約するか、同じケース識別子を持つ個別の行として保持します。必須属性ではありませんが、利用可能な場合は明細の識別子も追加列に残してください。
必須の出力列として、PurchaseRequisitionId、ActivityName、EventTime、SourceSystemId、LastDataIngestionTimestampを追加します。推奨列として、ユーザー、部門、RequisitionStatus、RequisitionTotalAmount、UrgencyLevel、ApprovalStepも追加します。取得できない値は作り出さず、nullにしてください。SourceSystemIdには、Dynamics 365 Financeなど一貫した値を設定します。
すべてのアクティビティクエリをUNION ALLで結合し、ケース識別子またはイベントのタイムスタンプが欠けている行を除外してから、PurchaseRequisitionIdとEventTimeで並べ替えます。別々のワークフロータスクや購買依頼の明細に対応するイベントは、重複していても保持してください。ソースレコードが明らかに重複して抽出された場合に限り、重複を削除します。
以下のチェックを使って、作成したイベントログを検証します。必要なアクティビティがすべて明示的な行として含まれていること、タイムスタンプが指定期間内であること、結合によってイベントが意図せず増えていないことを確認してください。
最終テーブルをCSVまたはProcessMindが対応する別のイベントログ形式で読み込むか、エクスポートします。PurchaseRequisitionIdをケース識別子、ActivityNameをアクティビティ、EventTimeをイベントのタイムスタンプとして対応付けます。SourceSystemIdとLastDataIngestionTimestampはイベント属性として保持し、取得可能な推奨属性もすべて残してください。

設定

コネクタとソース：Power BI DesktopでMicrosoft Dynamics 365 Financeの標準コネクタを使用します。[Your Dynamics 365 Finance instance URL]を環境のURLに置き換えてください。対象の導入環境について、ナビゲーターのメタデータでエンティティ名とフィールドを確認します。
必要なエンティティ：購買依頼のヘッダーと明細、ワークフローの追跡または履歴、発注書のヘッダーと明細、データ補完に必要なユーザーまたは組織のエンティティを選択します。正確なエンティティが確認できるまでは、[Your entity name]のプレースホルダーを使用してください。
日付範囲：まずは3～6か月分のデータを対象にします。選択期間内にワークフロー、発注書、明細の完了、または購買依頼の完了イベントがあるケースについては、過去に作成された購買依頼のヘッダーも含めてください。
会社と文書のフィルター：該当する場合は、[Your company or legal entity filter]と[Your document type filter]で絞り込みます。購買依頼の識別子が全社で一意なのか、会社ごとに一意なのかを確認してください。
ワークフローの対象範囲：申請、取り消し、再申請、タスクの割り当て、承認、却下、取り下げ、完了、キャンセルの各アクションを含めます。環境で使用されている値に基づいて、ワークフローのアクションとステータスを対応付けてください。
イベントの定義：各アクティビティを、明示的なイベント行として出力する必要があります。ProcessMindが他の行から承認、変更、完了、変換のイベントを推測することはありません。
タイムスタンプの処理：すべてのタイムスタンプを1つのタイムゾーンに統一します。ソースのタイムスタンプがUTCと現地の業務時間のどちらで保存されているかを文書化してください。ソースで利用できる最も高い精度のタイムスタンプを使用します。
増分更新：定期的にデータを抽出する場合は、ソースの最終更新時刻またはイベント時刻の最大値を基準にウォーターマークを設定し、遅れて到着するワークフローレコードを取り込めるよう、期間に重なりを設けます。最終的なイベントログを読み込む前に、重複期間のデータを照合してください。
処理性能：結合の前にソースエンティティを絞り込み、必要な列だけを選択します。不要な過去のワークフローレコードを読み込まず、対応している場合はクエリフォールディングを利用してください。ヘッダー、明細、ワークフローイベント、発注書との関連データは、別々に抽出してから結合します。
権限と前提条件：アカウントには、選択したDynamics 365 Financeのデータエンティティとワークフローデータへの読み取り権限が必要です。調達とワークフローに関する機能が有効であること、またPower BI Desktop、コネクタ、必要に応じたゲートウェイの設定、組織のセキュリティポリシーがデータ抽出を許可していることを確認してください。
通貨と金額：RequisitionTotalAmountがどの通貨を表すかを確認してください。購買依頼に複数の通貨が含まれる場合は、ソースの通貨を追加属性として含め、金額を明示せずに換算しないでください。
nullの処理：ソースに値が保存されていない場合、セキュリティによって値が制限されている場合、または関連付けを解決できない場合、推奨属性はnullになることがあります。エクスポート前に、必須のケース、アクティビティ、イベントのタイムスタンプを検証してください。

クエリの例 sql

WITH
RequisitionHeader AS (
    SELECT
        CAST([PurchaseRequisitionIdField] AS varchar(100)) AS PurchaseRequisitionId,
        [CreatedDateTimeField] AS CreatedDateTime,
        [RequisitionStatusField] AS RequisitionStatus,
        [RequisitionTotalAmountField] AS RequisitionTotalAmount,
        [UrgencyLevelField] AS UrgencyLevel,
        [RequesterUserField] AS RequesterUser,
        [DepartmentField] AS Department
    FROM [Your requisition header entity]
    WHERE [CompanyField] = '[Your company or legal entity filter]'
      AND [DocumentTypeField] = '[Your document type filter]'
),
WorkflowEvents AS (
    SELECT
        CAST([PurchaseRequisitionIdField] AS varchar(100)) AS PurchaseRequisitionId,
        [WorkflowEventTimestampField] AS EventTime,
        [WorkflowActionField] AS WorkflowAction,
        [WorkflowStatusField] AS WorkflowStatus,
        [ApprovalStepField] AS ApprovalStep,
        [WorkflowUserField] AS EventUser,
        [WorkflowCorrelationField] AS WorkflowCorrelation
    FROM [Your workflow history or workflow tracking entity]
    WHERE [CompanyField] = '[Your company or legal entity filter]'
      AND [WorkflowEventTimestampField] >= CAST('[Start date]' AS datetime2)
      AND [WorkflowEventTimestampField] < CAST('[End date]' AS datetime2)
),
PurchaseOrderLinks AS (
    SELECT
        CAST([PurchaseRequisitionIdField] AS varchar(100)) AS PurchaseRequisitionId,
        [PurchaseRequisitionLineIdField] AS PurchaseRequisitionLineId,
        [PurchaseOrderIdField] AS PurchaseOrderId,
        [PurchaseOrderLineIdField] AS PurchaseOrderLineId,
        [PurchaseOrderCreatedDateTimeField] AS PurchaseOrderCreatedDateTime,
        [RequisitionLineClosedDateTimeField] AS RequisitionLineClosedDateTime
    FROM [Your requisition to purchase order relationship entity]
    WHERE [CompanyField] = '[Your company or legal entity filter]'
),
RequisitionClosure AS (
    SELECT
        CAST([PurchaseRequisitionIdField] AS varchar(100)) AS PurchaseRequisitionId,
        [RequisitionClosedDateTimeField] AS RequisitionClosedDateTime
    FROM [Your requisition closure entity]
    WHERE [CompanyField] = '[Your company or legal entity filter]'
),
Events AS (
    SELECT
        h.PurchaseRequisitionId,
        'Requisition Created' AS ActivityName,
        h.CreatedDateTime AS EventTime,
        'Dynamics 365 Finance' AS SourceSystemId,
        CAST(CURRENT_TIMESTAMP AS datetime2) AS LastDataIngestionTimestamp,
        h.RequesterUser AS [User],
        h.Department,
        h.RequisitionStatus,
        h.RequisitionTotalAmount,
        h.UrgencyLevel,
        CAST(NULL AS varchar(255)) AS ApprovalStep
    FROM RequisitionHeader h
    WHERE h.CreatedDateTime < CAST('[End date]' AS datetime2)

    UNION ALL

    SELECT
        w.PurchaseRequisitionId,
        'Requisition Submitted for Approval' AS ActivityName,
        w.EventTime,
        'Dynamics 365 Finance' AS SourceSystemId,
        CAST(CURRENT_TIMESTAMP AS datetime2) AS LastDataIngestionTimestamp,
        w.EventUser AS [User],
        h.Department,
        h.RequisitionStatus,
        h.RequisitionTotalAmount,
        h.UrgencyLevel,
        w.ApprovalStep
    FROM WorkflowEvents w
    LEFT JOIN RequisitionHeader h ON h.PurchaseRequisitionId = w.PurchaseRequisitionId
    WHERE w.WorkflowAction IN ('[Your submission action value]')

    UNION ALL

    SELECT
        w.PurchaseRequisitionId,
        'Requisition Amended' AS ActivityName,
        w.EventTime,
        'Dynamics 365 Finance' AS SourceSystemId,
        CAST(CURRENT_TIMESTAMP AS datetime2) AS LastDataIngestionTimestamp,
        w.EventUser AS [User],
        h.Department,
        h.RequisitionStatus,
        h.RequisitionTotalAmount,
        h.UrgencyLevel,
        w.ApprovalStep
    FROM WorkflowEvents w
    LEFT JOIN RequisitionHeader h ON h.PurchaseRequisitionId = w.PurchaseRequisitionId
    WHERE w.WorkflowAction IN ('[Your recall action value]')
      AND EXISTS (
          SELECT 1
          FROM WorkflowEvents w2
          WHERE w2.PurchaseRequisitionId = w.PurchaseRequisitionId
            AND w2.WorkflowAction IN ('[Your resubmission action value]')
            AND w2.EventTime > w.EventTime
      )

    UNION ALL

    SELECT
        w.PurchaseRequisitionId,
        'Approval Step Started' AS ActivityName,
        w.EventTime,
        'Dynamics 365 Finance' AS SourceSystemId,
        CAST(CURRENT_TIMESTAMP AS datetime2) AS LastDataIngestionTimestamp,
        w.EventUser AS [User],
        h.Department,
        h.RequisitionStatus,
        h.RequisitionTotalAmount,
        h.UrgencyLevel,
        w.ApprovalStep
    FROM WorkflowEvents w
    LEFT JOIN RequisitionHeader h ON h.PurchaseRequisitionId = w.PurchaseRequisitionId
    WHERE w.WorkflowAction IN ('[Your approval task assigned action value]')

    UNION ALL

    SELECT
        w.PurchaseRequisitionId,
        'Approval Step Approved' AS ActivityName,
        w.EventTime,
        'Dynamics 365 Finance' AS SourceSystemId,
        CAST(CURRENT_TIMESTAMP AS datetime2) AS LastDataIngestionTimestamp,
        w.EventUser AS [User],
        h.Department,
        h.RequisitionStatus,
        h.RequisitionTotalAmount,
        h.UrgencyLevel,
        w.ApprovalStep
    FROM WorkflowEvents w
    LEFT JOIN RequisitionHeader h ON h.PurchaseRequisitionId = w.PurchaseRequisitionId
    WHERE w.WorkflowAction IN ('[Your approval action value]')
      AND w.WorkflowStatus IN ('[Your approved status value]')

    UNION ALL

    SELECT
        w.PurchaseRequisitionId,
        'Approval Step Rejected' AS ActivityName,
        w.EventTime,
        'Dynamics 365 Finance' AS SourceSystemId,
        CAST(CURRENT_TIMESTAMP AS datetime2) AS LastDataIngestionTimestamp,
        w.EventUser AS [User],
        h.Department,
        h.RequisitionStatus,
        h.RequisitionTotalAmount,
        h.UrgencyLevel,
        w.ApprovalStep
    FROM WorkflowEvents w
    LEFT JOIN RequisitionHeader h ON h.PurchaseRequisitionId = w.PurchaseRequisitionId
    WHERE w.WorkflowAction IN ('[Your rejection action value]')
      AND w.WorkflowStatus IN ('[Your rejected status value]')

    UNION ALL

    SELECT
        w.PurchaseRequisitionId,
        'Requisition Approved' AS ActivityName,
        w.EventTime,
        'Dynamics 365 Finance' AS SourceSystemId,
        CAST(CURRENT_TIMESTAMP AS datetime2) AS LastDataIngestionTimestamp,
        w.EventUser AS [User],
        h.Department,
        h.RequisitionStatus,
        h.RequisitionTotalAmount,
        h.UrgencyLevel,
        w.ApprovalStep
    FROM WorkflowEvents w
    LEFT JOIN RequisitionHeader h ON h.PurchaseRequisitionId = w.PurchaseRequisitionId
    WHERE w.WorkflowAction IN ('[Your workflow completion action value]')
      AND w.WorkflowStatus IN ('[Your final approved status value]')

    UNION ALL

    SELECT
        w.PurchaseRequisitionId,
        'Requisition Rejected' AS ActivityName,
        w.EventTime,
        'Dynamics 365 Finance' AS SourceSystemId,
        CAST(CURRENT_TIMESTAMP AS datetime2) AS LastDataIngestionTimestamp,
        w.EventUser AS [User],
        h.Department,
        h.RequisitionStatus,
        h.RequisitionTotalAmount,
        h.UrgencyLevel,
        w.ApprovalStep
    FROM WorkflowEvents w
    LEFT JOIN RequisitionHeader h ON h.PurchaseRequisitionId = w.PurchaseRequisitionId
    WHERE w.WorkflowAction IN ('[Your workflow completion action value]', '[Your rejection action value]')
      AND w.WorkflowStatus IN ('[Your final rejected status value]')

    UNION ALL

    SELECT
        w.PurchaseRequisitionId,
        'Requisition Withdrawn' AS ActivityName,
        w.EventTime,
        'Dynamics 365 Finance' AS SourceSystemId,
        CAST(CURRENT_TIMESTAMP AS datetime2) AS LastDataIngestionTimestamp,
        w.EventUser AS [User],
        h.Department,
        h.RequisitionStatus,
        h.RequisitionTotalAmount,
        h.UrgencyLevel,
        w.ApprovalStep
    FROM WorkflowEvents w
    LEFT JOIN RequisitionHeader h ON h.PurchaseRequisitionId = w.PurchaseRequisitionId
    WHERE w.WorkflowAction IN ('[Your withdrawal or cancellation action value]')

    UNION ALL

    SELECT
        p.PurchaseRequisitionId,
        'Purchase Order Created' AS ActivityName,
        p.PurchaseOrderCreatedDateTime AS EventTime,
        'Dynamics 365 Finance' AS SourceSystemId,
        CAST(CURRENT_TIMESTAMP AS datetime2) AS LastDataIngestionTimestamp,
        h.RequesterUser AS [User],
        h.Department,
        h.RequisitionStatus,
        h.RequisitionTotalAmount,
        h.UrgencyLevel,
        CAST(NULL AS varchar(255)) AS ApprovalStep
    FROM PurchaseOrderLinks p
    LEFT JOIN RequisitionHeader h ON h.PurchaseRequisitionId = p.PurchaseRequisitionId
    WHERE p.PurchaseOrderCreatedDateTime >= CAST('[Start date]' AS datetime2)
      AND p.PurchaseOrderCreatedDateTime < CAST('[End date]' AS datetime2)

    UNION ALL

    SELECT
        p.PurchaseRequisitionId,
        'Requisition Line Closed' AS ActivityName,
        p.RequisitionLineClosedDateTime AS EventTime,
        'Dynamics 365 Finance' AS SourceSystemId,
        CAST(CURRENT_TIMESTAMP AS datetime2) AS LastDataIngestionTimestamp,
        h.RequesterUser AS [User],
        h.Department,
        h.RequisitionStatus,
        h.RequisitionTotalAmount,
        h.UrgencyLevel,
        CAST(NULL AS varchar(255)) AS ApprovalStep
    FROM PurchaseOrderLinks p
    LEFT JOIN RequisitionHeader h ON h.PurchaseRequisitionId = p.PurchaseRequisitionId
    WHERE p.RequisitionLineClosedDateTime >= CAST('[Start date]' AS datetime2)
      AND p.RequisitionLineClosedDateTime < CAST('[End date]' AS datetime2)

    UNION ALL

    SELECT
        c.PurchaseRequisitionId,
        'Requisition Closed' AS ActivityName,
        c.RequisitionClosedDateTime AS EventTime,
        'Dynamics 365 Finance' AS SourceSystemId,
        CAST(CURRENT_TIMESTAMP AS datetime2) AS LastDataIngestionTimestamp,
        h.RequesterUser AS [User],
        h.Department,
        h.RequisitionStatus,
        h.RequisitionTotalAmount,
        h.UrgencyLevel,
        CAST(NULL AS varchar(255)) AS ApprovalStep
    FROM RequisitionClosure c
    LEFT JOIN RequisitionHeader h ON h.PurchaseRequisitionId = c.PurchaseRequisitionId
    WHERE c.RequisitionClosedDateTime >= CAST('[Start date]' AS datetime2)
      AND c.RequisitionClosedDateTime < CAST('[End date]' AS datetime2)
)
SELECT
    PurchaseRequisitionId,
    ActivityName,
    EventTime,
    SourceSystemId,
    LastDataIngestionTimestamp,
    [User],
    Department,
    RequisitionStatus,
    RequisitionTotalAmount,
    UrgencyLevel,
    ApprovalStep
FROM Events
WHERE PurchaseRequisitionId IS NOT NULL
  AND EventTime IS NOT NULL
ORDER BY PurchaseRequisitionId, EventTime, ActivityName;

始める準備はできましたか？

このテンプレートを使えば、調達から支払いまでの購買依頼プロセスの最適化を始めるために必要な情報がそろいます。今すぐインサイトを見つけましょう。

改善ガイドに戻る

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

調達から支払いまでの購買依頼プロセスを改善し、承認を迅速化

遅延をなくし、Dynamics 365でサイクルタイムを30％短縮できます。

無料トライアルを開始しましょう

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

調達から支払いまで：購買依頼のデータテンプレート

調達から支払いまで：購買依頼のデータテンプレート

調達から支払いまで：購買依頼の属性

調達から支払いまで：購買依頼のアクティビティ

データ抽出ガイド

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

ステップ

設定

クエリの例 sql

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

ステップ

設定

クエリの例 python

Microsoft Power BI標準コネクタによるデータ抽出

ステップ

設定

クエリの例 sql

始める準備はできましたか？

調達から支払いまでの購買依頼プロセスを改善し、承認を迅速化