> 継続的なプロセス改善 > 購買申請プロセス > Microsoft Dynamics 365 > データテンプレート

調達から支払いまで - 申請データテンプレート

Microsoft Dynamics 365

購買-支払プロセス - 購買依頼属性 (18) 購買申請プロセス活動 (12) 抽出ガイド (3)

調達から支払いまで - 申請データテンプレート

このテンプレートは、収集すべき主要属性と追跡すべき重要な活動を概説しており、購買依頼プロセスの詳細な分析を可能にします。また、このデータを抽出するための実用的なガイダンスも提供し、詳細な分析のためにイベントログを効率的に準備するのに役立ちます。

収集を推奨する項目
追跡すべき主要アクティビティ
抽出の手引き

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

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

購買-支払プロセス - 購買依頼属性

これらは、購買-支払プロセスにおける購買依頼プロセスの包括的な分析のために、イベントログに含めることを推奨されるデータフィールドです。

5 必須 7 推奨 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の下で追跡されます。プロセスマイニングにおいて、この属性は各購買依頼の最初から最後までのジャーニーを再構築するための基礎となります。これにより、個々のケースにおけるプロセスバリアント、サイクルタイム、コンプライアンスの分析が可能となり、購買依頼ライフサイクルの全体像を提供します。その重要性関連するすべてのイベントを単一のプロセスインスタンスにグループ化するために不可欠であり、各購買申請のライフサイクルを完全にエンドツーエンドで分析することを可能にします。取得元これは通常、Microsoft Dynamics 365のPurchReqTableのような主要な購買依頼ヘッダーテーブルにおける主キーです。例 PR-001254PR-001255PR-001256
	ソースシステム SourceSystemId	`データ`が抽出された記録システム。
説明この属性は、イベントデータが発生したソースシステムを識別します。この文脈では、「Microsoft Dynamics 365」となります。複数の統合システムを持つ環境では、このフィールドはデータリネージとコンテキストにとって不可欠です。分析においては、複数のシステムにまたがるプロセスを区別したり、データが単一の信頼できるソースから来ていることを確認したりするのに役立ちます。これは、データ検証と、分析が正しいデータセットに基づいていることを保証するために重要です。その重要性データの出所に関するコンテキストを提供し、これはデータガバナンス、検証、および複数のシステムが統合された環境において重要です。取得元これは、データ抽出および変換プロセス中にHaddされた静的な値「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）またはユーザーテーブル（例：UserInfo）にリンクされたトランザクションテーブル（例：PurchReqTable）に見つかります。例 j.smitha.joness.patel
	処理時間 ProcessingTime	特定のタスクに費やされた実際の作業時間。
説明処理時間とは、リソースがタスクの実行に実際に費やす期間のことです。これは、活動の終了時刻と開始時刻の差として計算されます。サイクルタイムとは異なり、待機時間やキュー時間は含まれません。この計算されたメトリックは、リソース効率と各プロセスステップに必要な実際の労力を理解するために不可欠です。これは、「承認ステップのボトルネック分析」において、複雑なタスクを示す可能性のある長い処理時間と、リソースの可用性の問題を示唆する長いキュー時間を区別するのに役立ちます。その重要性アクティビティのアクティブな作業時間を測定し、付加価値時間と待機時間を区別することで、正確なボトルネック分析に役立ちます。取得元これは、データ変換中に活動の開始時間から終了時間を差し引くことで計算されます。これには、各活動のStartTimeとEndTimeの両方が必要です。例 864000003600000600000
	承認ステップ 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」値を時系列順に連結して導出する必要があります。例マネージャー -> ディレクターマネージャー -> ディレクター -> 財務VPマネージャー -> 自動承認
	承認者グループ ApproverGroup	承認ステップを担当するユーザーグループまたはロール。
説明この属性は、特定の承認タスクを処理するために割り当てられたグループ、ロール、またはキュー（例：「財務承認者」や「ITマネージャー」）を識別します。承認者グループごとのプロセスパフォーマンスを分析することは、ワークロードの配分を理解し、どのグループがリソース不足であるか、または追加トレーニングが必要かを特定する上で重要です。これにより、承認担当チーム別にパフォーマンスを分析できるため、「承認ステップのボトルネック分析」ダッシュボードを直接サポートします。その重要性承認チーム間のパフォーマンスの違いを特定するのに役立ち、特定のグループ内での潜在的なリソース制約やトレーニングニーズを浮き彫りにします。取得元この情報は、各タスクに割り当てられたユーザーまたはユーザーグループを記録するワークフロー履歴（例：WorkflowTrackingStatusTable）の一部です。例財務承認者ITマネージャー経営陣
	発注書番号 PurchaseOrderNumber	購買依頼から作成された発注書の識別子。
説明この属性は、承認された購買依頼から生成された発注書の一意のIDを格納します。これは、購買依頼プロセスと下流の調達プロセスとの間のリンクとして機能します。この番号を追跡することは、「購買依頼から発注書への変換時間」を分析するために不可欠です。これにより、購買依頼が購買-支払サイクルの次の段階に正常に移行したことを確認し、購買依頼と発注書の両方にまたがるエンドツーエンドのプロセス分析を可能にします。その重要性購買申請をその後の購買オーダーに接続し、申請から購買オーダーへの変換の分析と、P2Pプロセスの異なる段階の紐付けを可能にします。取得元この情報は通常、発注書が作成された後、購買依頼明細テーブル（PurchReqLine）に見つかり、PurchTableにリンクされています。例 PO-000987PO-000988PO-000989
	通貨 Currency	購買依頼金額の通貨コード。
説明この属性は、購買依頼の総額が表記されている通貨（例：USD、EUR、GBP）を指定します。多通貨を扱う多国籍企業にとって、財務分析に不可欠です。通貨属性を使用することで、財務データの適切な処理と集計が可能になります。これにより、金銭的価値が正しく解釈され、異なる地域や事業単位間での正確なレポート作成と比較のために共通通貨への換算が可能になります。その重要性財務アトリビュートに必要なコンテキストを提供し、多通貨環境での金銭的価値の正確な解釈と集計を保証します。取得元このフィールドは通常、PurchReqTableの購買依頼ヘッダーテーブルに、金額フィールドとともに見つかります。例 USDEURGBP

必須推奨任意

購買申請プロセス活動

これらは、購買依頼ワークフローを正確に発見・分析するために、イベントログにキャプチャすべき不可欠なプロセスステップとマイルストーンです。

7 推奨 5 任意

	アクティビティ	説明
	依頼書承認済み	購買依頼は、ワークフロー内の全ての必須承認ステップを正常に通過しました。この活動は、ワークフローインスタンスが最終的な承認ステータスで完了したときに捕捉されます。
その重要性これは、承認サイクルの終了と調達フェーズの開始を示す主要なマイルストーンです。「購買依頼承認サイクルタイム」KPIの終了イベントです。取得元ワークフローが完了した際に`WorkflowTrackingStatusTable`から明示的に取得されます。これにより、`PurchReqTable`の「Status」フィールドも「Approved」（承認済み）に更新されます。取得「Approved」（承認済み）ステータスを持つワークフロー「完了」イベントをフィルタリングするか、`PurchReqTable`のステータス変更を追跡します。イベントタイプ explicit
	承認ステップ承認済み	承認者が割り当てられたタスクを完了し、プロセスの当該段階の申請を承認します。これにより、申請は次のステップまたは最終承認へと進みます。
その重要性各承認段階の処理時間を測定し、ワークフローの効率的な部分を特定するのに役立ちます。これはバリアント分析の主要な要素です。取得元ユーザーがワークアイテムを「Approve」（承認）の結果で完了した際に、`WorkflowTrackingStatusTable`に明示的にログが記録されます。取得ワークフロー履歴ログで「Approve」（承認）の結果を持つ「WorkItemCompleted」イベントを特定します。イベントタイプ explicit
	採用申請作成済み	このイベントは、購買依頼レコードが下書き状態で最初に作成されたことを示します。これは、購買依頼ヘッダーの作成タイムスタンプを特定することで捕捉されます。
その重要性プロセス開始として、このアクティビティは、購買申請の全体的なライフサイクル時間を測定し、日次の購買申請処理量を分析するために不可欠です。取得元この活動は、新しい購買依頼IDごとの「PurchReqTable」の「createdDateTime」フィールドから推測されます。取得 PurchReqTableのレコードの作成タイムスタンプを使用します。イベントタイプ inferred
	発注作成済み	承認された購買申請明細は購買オーダー明細に変換され、調達チームへの引き渡しを示します。これは、申請明細を購買オーダー明細に紐付けることで捉えられます。
その重要性これは、購買依頼を下流の調達プロセスに接続する重要なマイルストーンです。「購買依頼から発注書への変換時間」KPIを測定するために不可欠です。取得元購買申請ケースに関連付けられた`PurchReqLine`のIDを参照する`PurchLine`テーブル内のレコードを見つけることで推測されます。取得関連参照フィールド（例：`PurchReqLineRefId`）を使用して、`PurchReqLine`を`PurchLine`に結合します。イベントタイプ inferred
	購買依頼却下	購買依頼は承認ワークフロー中に却下され、それ以上処理されません。これは、購買依頼にとって最終的な失敗状態を示します。
その重要性この終了イベントは、全体的な却下率を分析し、失敗した依頼の財務的または運用上の影響を理解するために不可欠です。取得元ワークフローが「却下済み」ステータスで完了した際に`WorkflowTrackingStatusTable`から明示的に取得され、`PurchReqTable`のステータスフィールドが更新されます。取得「Rejected」（却下済み）ステータスを持つワークフロー「完了」イベントをフィルタリングするか、`PurchReqTable`のステータス変更を追跡します。イベントタイプ explicit
	購買依頼完了	購買依頼全体が完了と見なされます。これは、全ての明細行が発注書として処理されたか、またはキャンセルされたことを意味します。これは最終的で成功した終了状態です。
その重要性この活動は、購買依頼のライフサイクルの正常な完了を示します。これは、エンドツーエンドのプロセス総期間を測定するための最終的な終点です。取得元このステータスは通常、計算または推測されます。関連する全ての「PurchReqLine」レコードが最終ステータス（例：「完了済み」、「キャンセル済み」）に達したときに発生します。取得このイベントは、`PurchReqTable`のすべての子`PurchReqLine`レコードが最終ステータスを持っているかどうかを確認することで導出されます。イベントタイプ calculated
	購買依頼承認申請	ユーザーは完了した購買依頼を提出し、それが正式な承認ワークフローを開始します。これは、システムのワークフローエンジンによって明示的にログに記録されるアクションです。
その重要性この活動は、承認サイクルを開始する重要なマイルストーンです。これは、「購買依頼承認サイクルタイム」と「初回承認率」を測定するための開始点となります。取得元 `WorkflowTrackingStatusTable`または類似のワークフロー履歴テーブルから取得され、そこで購買申請に対して「Submission」（提出）イベントがログに記録されます。取得購買申請に関連付けられた「Submission」（提出）または「Start」（開始）イベントタイプについて、ワークフロー履歴ログをフィルタリングします。イベントタイプ explicit
	承認ステップ却下済み	承認者が割り当てられたタスクを却下し、通常、修正のために申請者を差し戻します。これはワークフローエンジンによって明示的にログに記録されるアクションです。
その重要性この活動は、「購買依頼却下率」を計算し、却下が最も頻繁に発生する段階を特定するために不可欠であり、プロセス改善の領域を浮き彫りにします。取得元ユーザーがワークアイテムを「Reject」（却下）の結果で完了した際に、`WorkflowTrackingStatusTable`に明示的にログが記録されます。取得ワークフロー履歴ログで「Reject」（却下）の結果を持つ「WorkItemCompleted」イベントを特定します。イベントタイプ explicit
	承認ステップ開始	ワークフローの一部として、個別の承認タスクがユーザーまたはグループに割り当てられます。これは、特定の承認者に対する待機時間または処理時間の開始を表します。
その重要性この活動は「承認ステップのボトルネック分析」に不可欠であり、特定の承認段階におけるキュー時間の測定を可能にします。取得元 `WorkflowTrackingStatusTable`から取得され、申請のワークフローインスタンスに対して新しいワークアイテムが作成され、割り当てられた際に記録されます。取得特定の購買申請について、ワークフロー履歴ログで「WorkItemCreated」または類似のイベントを特定します。イベントタイプ explicit
	購買依頼修正	このイベントは、ユーザーが提出済みの購買依頼をワークフローから呼び戻して変更を加える場合に発生します。この活動は通常、呼び戻しアクションとその後の再提出を識別することで捕捉されます。
その重要性修正を追跡することは、手戻り、不明確な初期依頼、およびプロセス非効率性を特定するための鍵です。これは「購買依頼修正頻度」ダッシュボードを直接サポートします。取得元ワークフロー履歴（`WorkflowTrackingStatusTable`）において「Recall」（取り消し）または「RequestChange」（変更要求）アクションを検出することで推測できます。また、提出後の`PurchReqTable`の`modifiedDateTime`フィールドへの変更からも推測可能です。取得ワークフローの取り消しイベントまたは提出イベント間のレコードバージョン変更を検出します。イベントタイプ inferred
	購買依頼取り下げ	作成者または承認されたユーザーが、提出された購買依頼をキャンセルします。このアクションにより、ワークフローと依頼が終了します。
その重要性取り下げを追跡することは、需要計画の問題や過度に複雑なプロセスを特定するのに役立ちます。これは「購買依頼取り下げインサイト」ダッシュボードをサポートします。取得元これは、「PurchReqTable」のステータスが「Cancelled」に変更されたこと、または「WorkflowTrackingStatusTable」の「Cancel」イベントから推測されます。取得 `PurchReqTable`のステータスが「Cancelled」（キャンセル済み）に変更されたこと、またはワークフローキャンセルイベントを検出します。イベントタイプ inferred
	購買依頼明細行完了	購買申請上の個別の明細項目が完全に処理されたと見なされます。これは通常、明細が完全に購買オーダーに変換された後に発生します。
その重要性購買申請の履行に関する詳細な情報を提供し、購買申請が部分的にまたは完全に購買オーダーに変換されているかを特定するのに役立ちます。取得元個別の`PurchReqLine`テーブルのステータスフィールドから推測されます。発注済みまたは受領済みを示すステータスはクローズを意味します。取得 `PurchReqLine`テーブルのステータスフィールドを監視し、「Invoiced」（請求済み）または「Closed」（クローズ済み）のような最終値を検出します。イベントタイプ inferred

推奨任意

抽出ガイド

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

ステップ

データ管理ワークスペースへのアクセス: Microsoft Dynamics 365にログインし、ワークスペースメニューに移動します。データ管理を選択して、データインポートおよびエクスポート操作の中心ハブを開きます。
新規エクスポートプロジェクトの作成: データ管理ワークスペース内で、エクスポートタイルをクリックします。一意のグループ名と説明的な説明を提供し、プロジェクトカテゴリをプロジェクトに設定します。これにより、データ抽出タスクが整理されます。
データエンティティの追加: 必要な標準データエンティティをプロジェクトに追加します。エンティティの追加をクリックし、以下の各エンティティを検索して1つずつ追加します。
- Purchase requisition headers（購買申請ヘッダー）
- Purchase requisition lines（購買申請明細）
- Workflow tracking status table（ワークフロートラッキングステータステーブル）
- Workflow work items（ワークフロー作業項目）
- Purchase order lines V2（購買オーダー明細 V2）
エクスポート形式の定義: 追加した各エンティティについて、CSVやExcelなどのターゲットデータ形式を選択します。一般的に、パフォーマンスとデータ変換ツールとの互換性のためにCSVが推奨されます。
データフィルターの適用: エンティティを選択し、フィルターボタンをクリックします。範囲タブで、Legal entity（法人）（会社コード）を指定し、正しいビジネスユニットからデータを抽出していることを確認します。また、データ量を制限するために、Purchase requisition headersエンティティのCreated date and time（作成日時）フィールドに日付フィルターを追加することが不可欠です。3〜6ヶ月の期間から始めることをお勧めします。
エクスポートジョブの実行: すべてのエンティティとフィルターが設定されたら、アクションペインのエクスポートをクリックします。システムはジョブパッケージを作成し、処理を開始します。ジョブ履歴セクションでジョブの進行状況を監視できます。
データパッケージのダウンロード: エクスポートジョブが正常に完了したら、ジョブ履歴の詳細に移動し、パッケージのダウンロードをクリックします。これにより、各エンティティの個別のデータファイルを含むZIPファイルがダウンロードされます。
生データをイベントログに変換: エクスポートされたファイルは生のシステムテーブルであり、最終的なイベントログではありません。Python、Power Query、またはETLプラットフォームなどの外部ツールを使用してデータを結合および再整形する必要があります。これには以下が含まれます。
- ヘッダーファイルと明細ファイルの結合。
- 購買申請ヘッダーのCorrelationIdとRecIdを使用して、ワークフローデータを申請に結合する。
- ワークフローテーブルからのステータス変更とワークフローイベントを、個別のアクティビティ行（Requisition Submitted、Approval Step Approvedなど）にピボットする。
- 正しいActivityName、EventTime、PurchaseRequisitionIdを持つ各アクティビティの新しい行を作成する。
アトリビュートの計算とマッピング: 変換中に、ソース列をUserやDepartmentなどの必要なアトリビュートにマッピングします。明細金額を合計してRequisitionTotalAmountなどの導出アトリビュートを計算します。SourceSystemIdに静的な値（例：'D365_F&O'）を設定し、スクリプトの実行時間をLastDataIngestionTimestampに使用します。
出力の最終化と形式設定: 最終出力ファイルが、各行がプロセスの1つのイベントを表す単一のCSVファイルであることを確認します。列は、PurchaseRequisitionId、ActivityName、およびEventTimeを含む、必要なイベントログ構造と一致している必要があります。

設定

必要な権限: ユーザーは、Data managementワークスペースへのアクセス権限、およびデータ管理管理者または類似のカスタムロールといった、エクスポートされる特定のデータエンティティへのアクセス権限を持つセキュリティロールが必要です。
主要データエンティティ:
- Purchase requisition headers（購買申請ヘッダー）：主要なケース識別子、作成タイムスタンプ、全体ステータスを提供します。
- Purchase requisition lines（購買申請明細）：金額や購買オーダーへのリンクを含む、各要求品目の詳細を含みます。
- Workflow tracking status table（ワークフロートラッキングステータステーブル）：提出、承認、却下、取り消しといったワークフローイベントの主要なソースです。
- Workflow work items（ワークフロー作業項目）：承認プロセス中にユーザーに割り当てられる特定のタスクの詳細です。
- Purchase order lines V2（購買オーダー明細 V2）：申請明細にリンクされた購買オーダーの作成タイムスタンプを見つけるために使用されます。
日付範囲のフィルタリング: Purchase requisition headersエンティティのCreated date and time（作成日時）フィールドに日付範囲フィルターを適用することが不可欠です。データ量とプロセス洞察のバランスを取るため、初回分析では3〜6ヶ月の範囲を推奨します。
会社コードのフィルタリング: 意図しない会社やテスト会社からデータを抽出することを避けるため、常にLegal entity（法人）でフィルターを適用してください。これにより、データサイズが大幅に削減され、ジョブのパフォーマンスが向上します。
データ変換: この方法では、未加工のエンティティエクスポートを構造化されたイベントログに変換するために、Dynamics 365外での大幅な後処理ステップが必要です。スクリプトツールまたはETLツールを使用する準備をしてください。

a クエリ例 config

/*
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で新しく登録したアプリケーション内で、「証明書とシークレット」の下に新しいクライアントシークレットを作成します。シークレット値は再度表示されないため、安全にコピーしてください。
API権限の付与: アプリケーションの「API権限」セクションで、「Dynamics ERP」の権限を追加します。「委任された権限」を選択し、Financials.ReadWrite.Allまたはより制限的な読み取り専用の同等権限を付与します。これらの権限に対する管理者の同意を付与してください。
Pythonライブラリのインストール: Pythonがインストールされていることを確認してください。その後、pipを使用して必要なライブラリをインストールします: pip install requests pandas。
Pythonスクリプトの設定: 提供されたPythonスクリプトをファイル（例：extract_d365_requisitions.py）にコピーします。スクリプトの冒頭にあるプレースホルダー変数（Dynamics 365 URL、テナントID、クライアントID、クライアントシークレット、希望する日付範囲、会社ID）を埋めます。
ODataエンティティの理解: スクリプトは、主要な申請詳細用のPurchaseRequisitionHeaders、購買オーダーへの変換を含む明細項目詳細用のPurchaseRequisitionLines、および提出や承認などのすべてのワークフロー関連イベント用のWorkflowTrackingStatusTableという3つの主要なデータエンティティにクエリを実行します。
スクリプトの実行: コマンドラインからスクリプトを実行します: python extract_d365_requisitions.py。スクリプトは認証を行い、各アクティビティのデータをフェッチし、APIページネーションを自動的に処理します。
データ変換: スクリプトはAPI呼び出しからの生のJSONデータを処理します。レコードを反復処理し、12のビジネスアクティビティそれぞれに個別の行を作成することでデータを再整形し、ソースフィールドをPurchaseRequisitionId、ActivityName、EventTimeなどの標準イベントログ列にマッピングします。
イベントの結合と標準化: 生成されたすべてのイベントは単一のリストに収集され、その後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を圧倒することなく大規模なデータセットを管理するためにページネーションを処理します。非常に大規模な履歴ロードの場合、より小さな日付範囲でスクリプトをバッチ処理で実行することを検討してください。

a クエリ例 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()

ステップ

データ管理ワークスペースへのアクセス: Microsoft Dynamics 365にログインし、ワークスペースメニューに移動します。データ管理を選択して、データインポートおよびエクスポート操作の中心ハブを開きます。
新規エクスポートプロジェクトの作成: データ管理ワークスペース内で、エクスポートタイルをクリックします。一意のグループ名と説明的な説明を提供し、プロジェクトカテゴリをプロジェクトに設定します。これにより、データ抽出タスクが整理されます。
データエンティティの追加: 必要な標準データエンティティをプロジェクトに追加します。エンティティの追加をクリックし、以下の各エンティティを検索して1つずつ追加します。
- Purchase requisition headers（購買申請ヘッダー）
- Purchase requisition lines（購買申請明細）
- Workflow tracking status table（ワークフロートラッキングステータステーブル）
- Workflow work items（ワークフロー作業項目）
- Purchase order lines V2（購買オーダー明細 V2）
エクスポート形式の定義: 追加した各エンティティについて、CSVやExcelなどのターゲットデータ形式を選択します。一般的に、パフォーマンスとデータ変換ツールとの互換性のためにCSVが推奨されます。
データフィルターの適用: エンティティを選択し、フィルターボタンをクリックします。範囲タブで、Legal entity（法人）（会社コード）を指定し、正しいビジネスユニットからデータを抽出していることを確認します。また、データ量を制限するために、Purchase requisition headersエンティティのCreated date and time（作成日時）フィールドに日付フィルターを追加することが不可欠です。3〜6ヶ月の期間から始めることをお勧めします。
エクスポートジョブの実行: すべてのエンティティとフィルターが設定されたら、アクションペインのエクスポートをクリックします。システムはジョブパッケージを作成し、処理を開始します。ジョブ履歴セクションでジョブの進行状況を監視できます。
データパッケージのダウンロード: エクスポートジョブが正常に完了したら、ジョブ履歴の詳細に移動し、パッケージのダウンロードをクリックします。これにより、各エンティティの個別のデータファイルを含むZIPファイルがダウンロードされます。
生データをイベントログに変換: エクスポートされたファイルは生のシステムテーブルであり、最終的なイベントログではありません。Python、Power Query、またはETLプラットフォームなどの外部ツールを使用してデータを結合および再整形する必要があります。これには以下が含まれます。
- ヘッダーファイルと明細ファイルの結合。
- 購買申請ヘッダーのCorrelationIdとRecIdを使用して、ワークフローデータを申請に結合する。
- ワークフローテーブルからのステータス変更とワークフローイベントを、個別のアクティビティ行（Requisition Submitted、Approval Step Approvedなど）にピボットする。
- 正しいActivityName、EventTime、PurchaseRequisitionIdを持つ各アクティビティの新しい行を作成する。
アトリビュートの計算とマッピング: 変換中に、ソース列をUserやDepartmentなどの必要なアトリビュートにマッピングします。明細金額を合計してRequisitionTotalAmountなどの導出アトリビュートを計算します。SourceSystemIdに静的な値（例：'D365_F&O'）を設定し、スクリプトの実行時間をLastDataIngestionTimestampに使用します。
出力の最終化と形式設定: 最終出力ファイルが、各行がプロセスの1つのイベントを表す単一のCSVファイルであることを確認します。列は、PurchaseRequisitionId、ActivityName、およびEventTimeを含む、必要なイベントログ構造と一致している必要があります。

設定

必要な権限: ユーザーは、Data managementワークスペースへのアクセス権限、およびデータ管理管理者または類似のカスタムロールといった、エクスポートされる特定のデータエンティティへのアクセス権限を持つセキュリティロールが必要です。
主要データエンティティ:
- Purchase requisition headers（購買申請ヘッダー）：主要なケース識別子、作成タイムスタンプ、全体ステータスを提供します。
- Purchase requisition lines（購買申請明細）：金額や購買オーダーへのリンクを含む、各要求品目の詳細を含みます。
- Workflow tracking status table（ワークフロートラッキングステータステーブル）：提出、承認、却下、取り消しといったワークフローイベントの主要なソースです。
- Workflow work items（ワークフロー作業項目）：承認プロセス中にユーザーに割り当てられる特定のタスクの詳細です。
- Purchase order lines V2（購買オーダー明細 V2）：申請明細にリンクされた購買オーダーの作成タイムスタンプを見つけるために使用されます。
日付範囲のフィルタリング: Purchase requisition headersエンティティのCreated date and time（作成日時）フィールドに日付範囲フィルターを適用することが不可欠です。データ量とプロセス洞察のバランスを取るため、初回分析では3〜6ヶ月の範囲を推奨します。
会社コードのフィルタリング: 意図しない会社やテスト会社からデータを抽出することを避けるため、常にLegal entity（法人）でフィルターを適用してください。これにより、データサイズが大幅に削減され、ジョブのパフォーマンスが向上します。
データ変換: この方法では、未加工のエンティティエクスポートを構造化されたイベントログに変換するために、Dynamics 365外での大幅な後処理ステップが必要です。スクリプトツールまたはETLツールを使用する準備をしてください。

a クエリ例 config

/*
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;

調達から支払いまで - 申請データテンプレート

調達から支払いまで - 申請データテンプレート

購買-支払プロセス - 購買依頼属性

購買申請プロセス活動

抽出ガイド

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

ステップ

設定

a クエリ例 config

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

ステップ

設定

a クエリ例 python

Microsoft Power BIネイティブコネクタによる抽出

ステップ

設定

a クエリ例 config

今すぐ始めますか？

今すぐ購買申請プロセスを最適化し、より迅速な承認を実現

調達から支払いまで - 申請データテンプレート

調達から支払いまで - 申請データテンプレート

購買-支払プロセス - 購買依頼属性

購買申請プロセス活動

抽出ガイド

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

ステップ

設定

a クエリ例 config

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

ステップ

設定

a クエリ例 python

Microsoft Power BIネイティブコネクタによる抽出

ステップ

設定

a クエリ例 config

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

今すぐ始めますか？

今すぐ購買申請プロセスを最適化し、より迅速な承認を実現