> 継続的なプロセス改善 > 決算・レポーティングの仕訳 > Microsoft Dynamics 365 > データテンプレート

決算・レポーティング：仕訳のデータテンプレート

Microsoft Dynamics 365

決算・レポーティングの仕訳プロセスの属性(20) 決算・レポーティングの仕訳プロセスのアクティビティ(12) データ抽出ガイド(4)

決算・レポーティング：仕訳のデータテンプレート

このテンプレートでは、決算・レポーティングの仕訳プロセスを分析するために必要なデータ項目を詳しく説明します。収集を推奨する属性と追跡すべき主なアクティビティを示し、プロセスマイニングに必要な情報を漏れなく把握できるようにします。また、ソースシステムからデータを抽出する方法もご案内します。

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

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

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

決算・レポーティングの仕訳プロセスの属性

決算・レポーティングの仕訳プロセスを詳しく分析するには、以下のデータ項目をイベントログに含めることをおすすめします。

3 必須 7 推奨 10 任意

	名前	説明
	アクティビティ名 ActivityName	発生した業務プロセスの具体的なステップまたはイベントの名前です。
説明この属性は、仕訳入力のライフサイクルにおける個々のイベントやタスクを表します。たとえば、「仕訳入力の作成」「仕訳の承認申請」「仕訳入力の転記」などです。これらのアクティビティが、検出されたプロセスマップのノードになります。アクティビティの順序や発生頻度の分析は、プロセスマイニングの中核です。実際のプロセスフローを明らかにし、標準手順からの逸脱を特定するとともに、想定以上に時間がかかる、または繰り返されるアクティビティのボトルネックを見つけます。重要な理由この属性はプロセスの各ステップを定義し、プロセスマップの基盤となります。プロセスフローやその違いを分析できます。入手先これは、Microsoft Dynamics 365内のシステムイベント、ステータス変更、またはワークフローログから導出される概念上の属性です。例仕訳入力の作成仕訳の承認申請仕訳の承認仕訳の転記完了
	イベント時刻 EventTime	アクティビティまたはイベントが発生した正確な日時を示すタイムスタンプです。
説明イベント時刻は、仕訳入力プロセスの特定のアクティビティが行われた日時を記録します。この時系列データは、イベントの順序付けやイベント間の所要時間の算出に欠かせません。分析では、このタイムスタンプを使ってケースごとのタイムラインを作成します。サイクルタイム、処理時間、待ち時間など、時間に関する指標の算出に必要です。ステップ間の遅れを特定できるほか、ボトルネックやSLAへの適合状況を分析するダッシュボードにも役立ちます。重要な理由イベントを正しい順序に並べ、サイクルタイムや処理の遅れなど、所要時間に関する重要業績評価指標（KPI）を算出するために欠かせないタイムスタンプです。入手先イベントのタイムスタンプは通常、ワークフロー履歴ログ、監査証跡テーブル（例：SysDatabaseLog）、またはLedgerJournalTableやLedgerJournalTransなどの関連レコードの作成・変更タイムスタンプに記録されています。例 2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:45:10Z
	仕訳入力ID JournalEntryId	仕訳入力を一意に識別するIDで、主要なケースIDとして使用します。
説明仕訳入力IDは、1件の仕訳取引に関連するすべてのアクティビティとデータを一意に結び付けます。作成やレビューから総勘定元帳への最終転記まで、仕訳のライフサイクル全体を追跡できます。プロセスマイニング分析では、この属性がプロセスフローの再構成に欠かせません。一意の仕訳入力IDがプロセスの1つのケースを表すため、個々の財務取引について、プロセスのバリアント、サイクルタイム、コンプライアンスを詳しく分析できます。重要な理由仕訳入力を開始から完了まで追跡するための基本となるキーです。ケースごとにプロセスフロー全体を分析できます。入手先通常はLedgerJournalTableなどの仕訳ヘッダーテーブルにあり、JournalNumというフィールド名が使われることがよくあります。例 JRN-0012345JV-2023-08-156GENJ0000891
	イベント終了時刻 EventEndTime	アクティビティまたはイベントが完了した日時を示すタイムスタンプです。
説明イベント終了時刻は、特定のアクティビティが完了した時点を示します。StartTimeがイベントの開始時刻を示すのに対し、EndTimeはもう一方の境界を示し、個々のタスクの所要時間を正確に算出できます。プロセスマイニングでは、開始時刻と終了時刻の両方があれば、待ち時間とは区別してアクティビティの処理時間を算出できます。ユーザーの作業状況を分析し、ステップ間の待ち時間だけでなく、どのタスクに最も時間がかかっているかを特定するダッシュボードに欠かせません。重要な理由各アクティビティの所要時間を正確に算出できます。ユーザーの作業状況を分析し、リソースを多く必要とするタスクを特定するうえで重要です。入手先このデータはワークフローログに明示的に記録されている場合もあれば、後続アクティビティのStartTimeを使って算出する必要がある場合もあります。例 2023-10-26T10:05:15Z2023-10-26T11:45:00Z2023-10-27T15:00:00Z
	ユーザー名 UserName	アクティビティを実行したユーザーの名前です。
説明この属性は、仕訳入力の作成、承認、転記など、特定のアクティビティを実行した従業員またはシステムユーザーを示します。プロセスの各ステップと担当者を結び付けます。ユーザー別の実績分析は、プロセスマイニングの主要な機能です。「仕訳入力ユーザー実績」ダッシュボードを作成し、ユーザーやチームごとのアクティビティ所要時間と処理量を比較できます。優れた実績を上げている担当者やトレーニングが必要な領域を特定し、業務負荷の調整にも役立ちます。重要な理由プロセスのアクティビティを個人に結び付け、ユーザーの実績、業務負荷の分布、リソースの割り当てを分析できます。入手先ユーザー情報は通常、LedgerJournalTableなどのテーブルにあるcreatedByまたはmodifiedByフィールド、あるいは関連するワークフロー履歴ログに記録されています。例アリス・スミスボブ・ジョンソンsystem.batch
	仕訳タイプ JournalType	一般仕訳や未払計上など、仕訳入力の分類です。
説明仕訳タイプは、日次仕訳、未払計上、配賦、消去など、業務上の目的に応じて仕訳を分類します。プロセスの経路や動作の違いを把握するうえで、この分類は重要です。この属性を使うと、仕訳タイプごとにプロセスを絞り込み、比較できます。「仕訳タイプ別の処理件数」ダッシュボードに欠かせない情報であり、特定の仕訳タイプで遅延、差し戻し、手戻りが多く発生していないかを分析できます。重要な理由業務目的ごとに分析を分けて比較できます。目的によってプロセスの経路、サイクルタイム、承認要件が異なる場合があります。入手先通常は仕訳ヘッダーテーブルのLedgerJournalTableに保存され、JournalNameなど、仕訳名やタイプに関連するフィールドに記録されます。例一般仕訳未払費用の調整会社間振替給与計算
	仕訳のステータス JournalStatus	仕訳の現在または最終のステータスです。
説明この属性は、「下書き」「審査中」「承認済み」「却下」「転記済み」など、特定の時点における仕訳の状態を示します。仕訳がライフサイクルのどの段階にあるかを把握できます。ステータスを分析すると、ケースの結果を理解しやすくなります。却下された仕訳をすべて抽出したり、特定の段階にある仕訳の件数を追跡したりできます。この属性は、処理量やステータスを分析する際のコンテキストとなり、複数のダッシュボードで利用できます。重要な理由各仕訳の結果を明確に把握できるため、成功率や却下率、各段階の作業量を分析できます。入手先ステータスは通常、仕訳ヘッダーテーブルのLedgerJournalTableに格納されています。または、ワークフローのステータスから取得できます。例下書き申請済み承認済み転記済み却下
	仕訳合計金額 JournalTotalAmount	仕訳の金額の合計です。通常は借方金額の合計を指します。
説明この属性は仕訳の合計金額を表します。金額を低・中・高などの範囲に分けて分類できます。金額別にプロセスを分析すると、重要な傾向が見えてきます。たとえば、高額の仕訳では、承認ステップが増え、サイクルタイムも長くなるなど、より厳格な承認プロセスが適用される場合があります。この属性は、重要性分析やプロセスの非効率性が財務に与える影響の把握に欠かせません。重要な理由金額別にプロセスを分析できます。金額は、プロセスの複雑さ、リスク、承認ワークフローと関連することがよくあります。入手先仕訳ごとに、仕訳明細テーブルLedgerJournalTransの借方金額を合計して算出する必要がある場合があります。例 1500.75125000.0050.25
	却下理由 RejectionReason	承認プロセスで仕訳が却下された際に示される理由です。
説明仕訳が却下されると、承認者が理由を示すことがあります。この属性にはその情報が記録され、根本原因の分析に役立ちます。「仕訳却下率分析」ダッシュボードで中心となる属性です。却下理由を分類して分析することで、文書の不備、ポリシー違反、データ入力ミスなどの共通する問題を特定し、対象を絞ったトレーニングやプロセスの改善につなげられます。重要な理由手戻りが発生する理由を明らかにし、却下率の低減と初回承認率の向上に必要な情報を提供します。入手先通常、この情報はワークフロー履歴、または却下ステップに関連付けられたコメント欄に保存されています。例裏付けとなる文書が不十分勘定科目の誤り承認基準額を超過重複入力
	法人 LegalEntity	仕訳を記録する法人または会社コードです。
説明法人は、財務取引を記録する組織内の特定の会社または事業部門を表します。財務システムにおける基本的な組織区分です。プロセスマイニングでは、この属性を使って組織内の各部門における仕訳プロセスを比較できます。法人ごとの処理効率、却下率、サイクルタイムの違いを明らかにし、優れた取り組みの特定と共有に役立てられます。重要な理由会社や事業部門ごとのプロセスのパフォーマンスを比較し、差異や改善の機会を見つけられます。入手先 Dynamics 365の基本項目で、通常はLedgerJournalTableなどの取引テーブルにあり、一般にDataAreaIdに関連付けられています。例 USMFDEMFGBSI
	ソースシステム SourceSystem	データの抽出元となる記録システムです。
説明この属性は、仕訳入力データの取得元となるアプリケーションを示します。このプロセスでは通常、「Microsoft Dynamics 365」などの固定値が設定されます。複数のERPや連携システムがある環境で分析する場合、このフィールドを使ってプロセスやデータソースを区別できます。データの出所を明確にし、データガバナンスや検証にも役立ちます。重要な理由データの出所を示します。データガバナンスや複数の基幹システムにまたがる分析に欠かせない情報です。入手先データの抽出、変換、読み込み（ETL）の際に、データセットの出所を示すために追加する固定値です。例 Microsoft Dynamics 365D365 F&O
	最終データ更新日時 LastDataUpdate	ソースシステムからデータを最後に更新した日時を示すタイムスタンプです。
説明この属性は、ソースシステムからデータを最後に抽出した日時を示します。分析の鮮度や対象データの範囲を把握するための情報です。ダッシュボードにこの情報を表示することで、データがいつ時点のものかを確認でき、現在のプロセス分析が対象とする期間も把握しやすくなります。プロセスマイニングプロジェクトに欠かせないメタデータです。重要な理由データがどの時点のものかを示す重要な情報です。プロセス分析の最新性を把握できます。入手先このタイムスタンプは、データの抽出、変換、読み込み（ETL）の際に生成され、保存されます。例 2023-10-27T02:00:00Z
	初回で完了したかどうか IsFirstTimeRight	仕訳が却下されることなく承認されたかどうかを示すフラグです。
説明ケースレベルの真偽値属性です。仕訳が申請から承認まで進む間に「仕訳却下」や「仕訳修正」のアクティビティがなければ、trueになります。プロセス品質を測る重要な指標です。「初回承認率」重要業績評価指標（KPI）は、この属性から直接算出されます。数値が高い場合は、効率的で質の高いプロセスであることを示します。低い場合は、初期データの品質、要件の明確さ、申請手順に構造的な問題がある可能性があります。重要な理由プロセス品質を測る重要な指標です。手戻りなく承認プロセスを進んだ仕訳の件数を把握できます。入手先各仕訳IDのアクティビティの順序を分析し、ケースレベルで算出する属性です。例 truefalse
	手戻りかどうか IsRework	手戻りや修正のループに含まれるアクティビティを識別するフラグです。
説明この計算済みの真偽値属性は、却下後に発生する「仕訳修正」や、繰り返し行われる「仕訳の承認申請」などのアクティビティにtrueを設定します。手戻りを切り分けて定量化できます。「仕訳の手戻りと修正ループ」ダッシュボードと「手戻り率」重要業績評価指標（KPI）に欠かせない属性です。手戻りにフラグを付けることで、修正サイクルの頻度と影響を簡単に可視化して測定できます。修正サイクルは、プロセスの非効率性を生む主な要因の1つです。重要な理由非効率な手戻りループを直接識別し、却下や修正が全体のサイクルタイムとコストに与える影響を簡単に定量化できます。入手先ケース内のアクティビティの順序を分析し、データ変換時に算出する属性です。例 truefalse
	承認SLAのステータス ApprovalSlaState	仕訳の承認がサービスレベル合意（SLA）を満たしたかどうかを示します。
説明この属性は、サービスレベル合意（SLA）で定めた目標時間内に完了したかどうかに基づいて、各仕訳の承認サイクルを分類します。値は通常、「達成」または「未達」です。「仕訳承認SLA適合性」ダッシュボードの中心となる指標です。目標に対するパフォーマンスを業務の観点から明確に示し、承認プロセスの所要時間を監視・管理できます。SLA未達が頻発する箇所の改善にも役立ちます。重要な理由生のサイクルタイムデータを「達成」または「未達」という明確な業務上の結果に置き換え、主要目標に対するパフォーマンスを簡単に追跡できます。入手先計算済みの属性です。算出には、計算済みの承認サイクルタイム重要業績評価指標（KPI）と事前に設定したSLA目標を比較します。例達成未達
	承認レベル ApprovalLevel	複数段階の承認ワークフローにおける現在または完了済みの段階を示します。
説明複数の承認が必要な仕訳について、階層のどの段階まで進んだかを記録します。たとえば、「マネージャー承認」や「ディレクター承認」などです。この属性を使うと、承認のボトルネックを詳しく分析できます。承認プロセスの特定の段階で遅延が繰り返し発生しているかを特定し、その段階でのプロセスの見直しやリソースの再配分を検討できます。重要な理由複数段階の承認ワークフローを可視化し、特定の承認レベルにおけるボトルネックの特定に役立ちます。入手先ワークフロー履歴ログから情報を取得し、各承認ステップの完了状況を追跡します。例レベル1：マネージャーレベル2：ディレクターレベル3：財務担当副社長
	自動転記かどうか IsAutomatedPosting	仕訳が自動で作成または転記されたかどうかを示すフラグです。
説明この真偽値属性は、ユーザーが手動で作成した仕訳と、システムやサブシステムが自動で作成した仕訳を区別します。後者には、システム連携や自動配賦プロセスによるものなどがあります。この属性を分析すると、自動処理と手動処理の効率やエラー率を比較できます。手動入力でエラーや手戻り、遅延が発生しやすいかを確認し、さらなる自動化の機会を見つけられます。重要な理由手動処理と自動処理を区別し、効率、正確性、コンプライアンスを比較できます。入手先「作成者」のユーザー（システムユーザーやバッチユーザーなど）や、仕訳ヘッダーまたは仕訳タイプの設定にある専用フラグで判別できる場合があります。例 truefalse
	転記日 PostingDate	仕訳が総勘定元帳に転記された日付です。
説明転記日は、取引が総勘定元帳の残高に反映される正式な日付です。財務報告や決算期間の管理に欠かせません。この属性を使うと、承認から転記までの遅れを分析できます。「仕訳転記リードタイム」重要業績評価指標（KPI）で対象となる期間です。この遅れの短縮は、決算の迅速化に向けた重要な目標となることがよくあります。また、期間ごとの転記件数の分析にも利用できます。重要な理由転記リードタイムの重要業績評価指標（KPI）の算出に必要です。承認から取引が元帳に正式に反映されるまでの遅れも把握できます。入手先通常、この日付は仕訳ヘッダーテーブル（LedgerJournalTable）または関連する転記済み取引テーブルに保存されています。例 2023-10-282023-11-012023-10-31
	通貨コード CurrencyCode	仕訳金額の通貨です。
説明この属性は、仕訳の金額に使用される通貨（USD、EUR、GBPなど）を示します。仕訳合計金額を理解するために必要なコンテキストを提供します。プロセスフロー自体の分析に通貨を使わない場合でも、仕訳金額に基づく財務レポートや分析には欠かせません。特に多国籍組織では、金額を正しく集計して比較するために必要です。重要な理由財務分析に必要なコンテキストを提供し、特に複数通貨を扱う環境で金額を正しく解釈できるようにします。入手先通常、通貨コードは仕訳明細テーブルLedgerJournalTransで確認できます。例 USDEURGBPJPY
	部門 DepartmentName	仕訳に関連付けられた部門またはコストセンターです。
説明部門またはコストセンターは、財務取引を担当する、またはその影響を受ける社内の事業部門を示します。社内管理レポートにおける重要な分析軸です。この属性を使うと、部門別に仕訳プロセスを分析できます。仕訳の申請件数が最も多い部門や、却下率や承認時間が長い部門を特定するのに役立ちます。対象を絞ったプロセス改善にも利用できます。重要な理由業務機能別にプロセスのパフォーマンスを分析し、部門固有のボトルネックやトレーニングの必要性を特定できます。入手先通常、この情報は仕訳明細レベルのLedgerJournalTransに財務ディメンションとして記録されています。例営業財務マーケティング業務

必須推奨任意

決算・レポーティングの仕訳プロセスのアクティビティ

プロセスを正確に把握して分析するために、イベントログに記録すべき主な手順と節目を示します。

5 推奨 7 任意

	アクティビティ	説明
	仕訳の差し戻し	レビュー担当者または承認者が仕訳を差し戻し、修正が必要になったことを示します。仕訳のステータスが「差し戻し」または「要修正」に変わった時点で記録されます。
重要な理由差し戻しを追跡することは、差し戻し率の算出や手戻りの根本原因の特定に欠かせません。データ品質、コンプライアンス、ユーザートレーニングに関する問題が明らかになります。入手先 LedgerJournalTableのステータスフィールドの変更（例：ApprovalStatusが「Rejected」に変更）またはワークフロー履歴ログから判定します。記録仕訳のステータスが「差し戻し」に変わった時点のタイムスタンプを特定します。イベントタイプ inferred
	仕訳の承認	指定された権限者が仕訳を承認し、承認ワークフローの最終ステップが完了したことを示します。通常、仕訳ヘッダーのステータスが「承認済み」に変わった時点で記録されます。
重要な理由これは承認プロセスを完了し、転記を可能にする重要な節目です。承認サイクルタイム、転記リードタイム、初回正確処理率の算出に欠かせません。入手先 LedgerJournalTableのステータスフィールドの変更（例：ApprovalStatusが「Approved」に変更）または最終承認を示すワークフロー履歴テーブルから判定します。記録仕訳のステータスが「承認済み」に変わった時点のタイムスタンプを特定します。イベントタイプ inferred
	仕訳の承認申請	完成した仕訳をレビューと承認のワークフローに正式に提出したことを示します。通常、仕訳ヘッダーのステータスが「下書き」から「レビュー中」または「提出済み」に変わったことから判定します。
重要な理由これは承認サイクルの開始を示す重要な節目です。提出から最終承認までの時間を測定することで、レビューのボトルネックを特定し、SLAへの適合状況を確認できます。入手先 LedgerJournalTableのステータスフィールドの変更（例：ApprovalStatusが「InReview」に変更）または仕訳に関連付けられたワークフロー履歴ログから判定します。記録仕訳のステータスが「提出済み」または「レビュー中」に変わった時点のタイムスタンプを特定します。イベントタイプ inferred
	仕訳の転記完了	このアクティビティは、仕訳が総勘定元帳に正常に転記され、正式な財務記録になったことを示します。仕訳ヘッダーのステータスが「転記済み」に更新された時点で記録される重要なイベントです。
重要な理由これはプロセスが正常に完了したことを示す主要な終了イベントです。プロセス全体のサイクルタイムと転記リードタイムの算出に使われ、決算の効率を測る重要な指標となります。入手先 LedgerJournalTableのステータスフィールドの変更（例：JournalStatusが「Posted」に変更）と、GeneralJournalAccountEntryテーブルへの対応レコードの作成から取得します。記録仕訳のステータスが「転記済み」になった時点のタイムスタンプを特定します。イベントタイプ inferred
	仕訳入力の作成	このアクティビティは、新しい仕訳入力の開始を示します。ユーザーがシステムで新しい仕訳ヘッダーレコードを作成した時点で記録され、プロセス分析のケースIDとなる一意の仕訳入力IDが設定されます。
重要な理由これはプロセスの主要な開始イベントです。この時点から転記までの時間を分析することで、プロセス全体のサイクルタイムを測定し、初期のデータ入力の遅れを特定できます。入手先このイベントは、GeneralJournalEntryまたはLedgerJournalTableエンティティにある仕訳ヘッダーの作成タイムスタンプから取得します。通常、レコードの作成を明示的に示すイベントです。記録 GeneralJournalEntryまたはLedgerJournalTableの「createdDateTime」フィールドを使用します。イベントタイプ explicit
	仕訳の修正	このアクティビティは、差し戻された仕訳がユーザーによって変更されたことを示します。通常、「差し戻し」ステータスが記録された後に、仕訳ヘッダーまたは明細が変更されたことから判定します。
重要な理由このアクティビティで手戻りを明確に特定できます。修正の繰り返し回数や所要時間を分析すると、プロセスの効率化と手作業の削減につながります。入手先「仕訳の差し戻し」イベントの後に、LedgerJournalTableまたはLedgerJournalTransテーブルの「modifiedDateTime」および「modifiedBy」フィールドを追跡して判定します。記録「差し戻し」ステータスのタイムスタンプと、その後に作成者が変更した時刻を比較します。イベントタイプ inferred
	仕訳の再承認申請	修正した仕訳を新たなレビューサイクルに戻します。「差し戻し」または「下書き」から「レビュー中」または「提出済み」へのステータス変更から判定します。
重要な理由このアクティビティは手戻りサイクルの開始を示します。イベント数を数えることで、手戻り率や仕訳1件あたりの平均承認サイクル数を把握できます。入手先ワークフロー履歴、またはLedgerJournalTableのステータス変更を追跡し、差し戻し状態から提出済み状態に戻ったことから判定します。記録同じ仕訳について、「差し戻し」ステータスの後に発生した「提出済み」ステータスのイベントを特定します。イベントタイプ inferred
	仕訳の取消処理を開始	このイベントは、転記済みの仕訳を取り消す処理の開始を示します。ユーザーがシステムで取消操作を開始した時点で記録されます。
重要な理由取消を追跡すると、転記済みの仕訳を修正する頻度や理由を特定できます。初期のデータ入力や承認段階に潜む問題が明らかになる場合もあります。入手先通常、これはユーザーが明示的に行う操作です。監査証跡から取得するか、元の仕訳に関連付けられた新しい取消仕訳の作成を特定できます。記録転記済みの仕訳を取り消すものとして記録された、新しい仕訳の作成イベントを使用します。イベントタイプ explicit
	仕訳の取消完了	取消仕訳が正常に転記され、仕訳の取消処理が完了したことを示します。誤った仕訳のライフサイクルにおける、もう1つの終了点となります。
重要な理由このアクティビティで修正後の仕訳処理が完了したことを確認でき、転記後の調整にかかった作業全体を分析できます。こうした作業はプロセス全体の効率に影響します。入手先新しい取消仕訳のステータスが「転記済み」に変わった時点で記録されます。参照フィールドを通じて元の仕訳との関連が保持されます。記録関連する取消仕訳の「転記済み」ステータスイベントを特定します。イベントタイプ inferred
	仕訳の転記を試行	このアクティビティは、承認済みの仕訳について、ユーザーが転記処理を開始したことを示します。システムが転記ジョブの開始を記録している場合は、明示的に取得できます。
重要な理由転記の試行と転記の完了を区別すると、決算に影響するシステムの性能問題やバッチジョブの遅延を調査しやすくなります。入手先バッチジョブ履歴テーブルに記録された明示的なイベント、またはLedgerJournalTableのステータスが「転記処理中」に変わったことから判定できます。記録総勘定元帳の転記処理に関連するバッチジョブまたはシステムログの分析が必要です。イベントタイプ explicit
	仕訳レビューの開始	このアクティビティは、レビュー担当者が提出済みの仕訳の確認を始めた時点を示します。仕訳がレビュー担当者に割り当てられた時点、または担当者が初めてレコードを開いて確認した時点から判定できます。
重要な理由このアクティビティを使うと、提出からレビュー開始までの遅れにあたる、レビュー担当者への引き継ぎ時間を測定できます。リソースの割り当てや通知に関する問題も明らかになります。入手先このイベントは明示的に記録されないことがよくあります。ワークフローの割り当てログから判定するか、提出時刻とレビュー担当者による最初の変更時刻を比較する必要があります。記録ワークフローのユーザー割り当てログまたはユーザーアクティビティログの分析が必要です。これらのログは標準で記録されていない場合があります。イベントタイプ inferred
	仕訳明細の追加	このイベントは、借方または貸方の明細が仕訳に追加されたことを示します。新しい取引明細が作成され、仕訳ヘッダーに関連付けられるたびに記録されます。
重要な理由明細の作成状況を追跡すると、仕訳の種類ごとの複雑さやデータ入力の作業量を把握できます。また、ヘッダーの作成から明細の入力完了までの遅れも明らかになります。入手先 LedgerJournalTransエンティティのレコード作成タイムスタンプから取得し、仕訳ヘッダーに関連付けます。明細の作成ごとに個別のイベントとして記録されます。記録 LedgerJournalTransテーブルの各レコードにある「createdDateTime」フィールドを使用します。イベントタイプ explicit

推奨任意

データ抽出ガイド

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

ステップ

データ管理ワークスペースを開く：Microsoft Dynamics 365環境にログインします。メインの検索バーで「データ管理」ワークスペースを検索して開きます。
新しいエクスポートプロジェクトを作成する：データ管理ワークスペースで「エクスポート」タイルを選択し、新しいデータエクスポートプロジェクトを作成します。「ProcessMind_JournalEntry_Export」など、内容がわかる名前を付けます。
データ形式を選択する：プロジェクトの詳細で、出力するデータ形式を指定します。後続の変換作業を簡単にするため、「CSV」または「Excel」を選択します。
必要なデータエンティティを追加する：必要なアクティビティと属性をすべて取得するため、複数のエンティティをプロジェクトに追加します。各エンティティについて「エンティティの追加」をクリックし、以下の名前を検索します。1つずつ追加することをおすすめします。
- Ledger journal headers：作成、転記、取消のイベントを取得します。
- Ledger journal lines：個々の借方・貸方明細の追加を取得します。
- Workflow tracking status table：申請、承認、却下など、ワークフロー関連のイベントを取得します。
エンティティのフィルターを設定する：追加した各エンティティで「フィルター」を選択し、エクスポートの対象を絞ります。少なくとも「法人」（会社）で絞り込み、関連する日付フィールドに期間を指定してください。たとえば、Ledger journal headersのCREATEDDATETIMEを使います。データ量を運用しやすい範囲に抑えるため、直近3～6か月分をエクスポートする方法があります。
エンティティのフィールドをマッピングする：各エンティティのフィールドマッピングを確認し、最終的な属性に必要なフィールドがすべてエクスポートファイルに含まれていることを確認します。通常、システムでは既定ですべてのフィールドが含まれます。
エクスポートジョブを実行する：プロジェクトの設定が完了したら、アクションペインで「エクスポート」をクリックします。各データエンティティのファイルを含むデータパッケージが作成されます。
エクスポートしたデータをダウンロードする：エクスポートジョブが正常に完了したら、ジョブ履歴を開き、生成されたzip形式のデータパッケージをダウンロードします。
データをイベントログに変換する：この作業はDynamics 365の外部で、スクリプト（Python、PowerShellなど）またはデータ準備ツールを使って行います。複数のエクスポートファイルのデータを結合・変換し、1つのイベントログCSVファイルにまとめます。各ソースファイルから、該当するアクティビティの行を作成します。例：
- Ledger journal headersファイルから、作成日時を使って「仕訳作成」イベントを、転記日時を使って「仕訳転記」イベントを作成します。
- Ledger journal linesファイルから、「仕訳明細追加」イベントを作成します。
- Workflow tracking status tableファイルをヘッダーデータと結合し、ワークフローのステータスとタイムスタンプに基づいて「仕訳承認申請」「仕訳承認」「仕訳却下」イベントを作成します。
- 「仕訳却下」イベントの後に更新日時が記録されているかを確認し、「仕訳修正」などのイベントを推定します。
最終CSVファイルを整える：変換後のファイルに、JournalEntryId、ActivityName、EventTimeの各列と、推奨属性が含まれていることを確認します。JournalEntryId、続いてEventTimeの順に並べ替えます。
ProcessMindにアップロードする：完成した単一のCSVイベントログをProcessMindにアップロードし、分析を開始できます。

設定

データエンティティ：設定の要となるのは、適切なエンティティの選択です。主にLedger journal headers、Ledger journal lines、Workflow tracking status tableを使用します。ワークフローの設定によっては、追加のエンティティが必要になる場合があります。
エクスポート形式：必要な変換作業にスクリプト言語やデータツールを使いやすいため、汎用性の高いCSVをおすすめします。
フィルター：関係のない事業部門のデータをエクスポートしないよう、「法人」（会社）で絞り込むことが欠かせません。日付範囲（例：CREATEDDATETIME）の指定も、処理性能とファイルサイズの管理に重要です。初回の分析では、通常3～6か月分を対象にします。
増分エクスポート：継続的に監視する場合は、エクスポートプロジェクトで増分エクスポートを設定します。前回の実行以降に変更されたレコードのみを抽出するため、毎回すべてのデータをエクスポートするより効率的です。
アクセス許可：エクスポートジョブを設定・実行するユーザーアカウントには、データ管理ワークスペースと基盤となるデータエンティティにアクセスできる「データ管理者」ロール、または同等のアクセス許可が必要です。

クエリの例 sql

/*
This is not a single executable query. Instead, it defines the configuration of a Data Management Framework export project. The following entities and fields must be selected and then combined using an external script to build the final event log.
*/

-- Configuration for Entity 1: Ledger journal headers
-- Purpose: Extracts core journal header data for Created, Posted, and Reversal events.
-- Source Entity: Ledger journal headers
-- Key Fields to Map:
--   JournalBatchNumber -> JournalEntryId
--   CREATEDDATETIME -> EventTime (for 'Journal Entry Created')
--   CREATEDBY -> UserName (for 'Journal Entry Created')
--   LedgerJournalWFApprovalStatus -> JournalStatus (for workflow context)
--   JournalType -> JournalType
--   company -> LegalEntity
--   PostedDateTime -> EventTime (for 'Journal Entry Posted')
--   PostedBy -> UserName (for 'Journal Entry Posted')
--   ReverseDate -> EventTime (for 'Journal Entry Reversal Initiated')
--   MODIFIEDDATETIME -> Used to infer 'Journal Entry Corrected'
--   MODIFIEDBY -> UserName

-- Configuration for Entity 2: Ledger journal lines
-- Purpose: Extracts individual transaction lines to create 'Journal Line Added' events.
-- Source Entity: Ledger journal lines
-- Key Fields to Map:
--   JournalBatchNumber -> JournalEntryId
--   CREATEDDATETIME -> EventTime (for 'Journal Line Added')
--   CREATEDBY -> UserName (for 'Journal Line Added')
--   AmountInTransactionCurrency -> JournalTotalAmount (Note: Must be aggregated per JournalEntryId)
--   company -> LegalEntity

-- Configuration for Entity 3: Workflow tracking status table
-- Purpose: Extracts detailed workflow history for approval and rejection events.
-- Source Entity: Workflow tracking status table
-- Key Fields to Map:
--   ContextRecId -> (This needs to be joined back to the RecId of the LedgerJournalTable to get the JournalBatchNumber)
--   ContextTableId -> (Used to filter for Journal related workflows)
--   CREATEDDATETIME -> EventTime
--   User -> UserName
--   TrackingStatus -> Used to derive ActivityName ('Submitted For Approval', 'Journal Approved', 'Journal Rejected')
--   Comment -> RejectionReason

-- **Post-Processing Transformation Logic (to be implemented in an external script)**

-- 1. For each row in 'Ledger journal headers' export:
--    - Create one row with ActivityName = 'Journal Entry Created', EventTime = CREATEDDATETIME.
--    - If PostedDateTime is not null, create one row with ActivityName = 'Journal Entry Posted', EventTime = PostedDateTime.
--    - If ReverseDate is not null, create one row with ActivityName = 'Journal Entry Reversal Initiated', EventTime = ReverseDate. (A separate 'Journal Entry Reversed' event may need to be derived from the creation of the reversing journal).

-- 2. For each row in 'Ledger journal lines' export:
--    - Create one row with ActivityName = 'Journal Line Added', EventTime = CREATEDDATETIME.

-- 3. For each row in 'Workflow tracking status table' export (after joining to get JournalBatchNumber):
--    - IF TrackingStatus indicates submission, create ActivityName = 'Journal Submitted For Approval'.
--    - IF TrackingStatus indicates approval, create ActivityName = 'Journal Approved'.
--    - IF TrackingStatus indicates rejection, create ActivityName = 'Journal Rejected'.
--    - Other activities like 'Journal Review Started', 'Journal Entry Corrected', 'Journal Resubmitted For Approval', and 'Journal Posting Attempted' are often not explicitly logged. They must be inferred from status changes, user actions within a timeframe, or modification timestamps on the journal header after a rejection event.

ステップ

D365からAzure Data Lakeへのエクスポートを設定する：クエリを実行する前に、Microsoft Dynamics 365標準の「Export to Azure Data Lake」機能が設定され、有効になっていることを確認します。仕訳プロセスに必要なデータエンティティを選択します。最低限、LedgerJournalTable、LedgerJournalTrans、GeneralJournalEntry、GeneralJournalAccountEntry、WorkflowTrackingStatusTableを含めてください。初回のデータ同期が完了するまで待ちます。
Azure Synapse Analyticsを開く：Azure Portalで、Dynamics 365のデータを含むAzure Data Lake Storageアカウントに接続されたSynapse Analyticsワークスペースを開きます。
SQLデータベースにアクセスする：Synapse Studioで「データ」ハブを開きます。データレイク内のファイルを対象に作成されたサーバーレスSQLデータベースを探します。D365のエンティティは、クエリ可能なテーブルまたはビューとして利用できます。
新しいSQLスクリプトを作成する：「開発」ハブを開き、新しい空のSQLスクリプトを作成します。ここでイベントログのクエリを作成します。
クエリをコピーして調整する：この文書の「クエリ」セクションにあるSQLクエリ全体をコピーし、Synapse Studioの新しいスクリプトエディターに貼り付けます。
プレースホルダーを更新する：クエリを確認し、すべてのプレースホルダー値を置き換えます。たとえば、データベース名とスキーマ名を[YourD365DB].[dbo]から更新し、分析期間に合わせてStartDateとEndDateのパラメーターを設定します。
クエリを実行する：サーバーレスSQLプールを使ってスクリプトを実行します。実行時間は、日付範囲やシステム内のデータ量によって異なります。
結果を確認する：クエリが完了すると、結果ペインに生成されたイベントログが表示されます。列（JournalEntryId、ActivityName、EventTimeなど）とデータが正しいことを確認します。
イベントログをエクスポートする：クエリツールまたはSynapse Studioのエクスポート機能を使い、結果をCSVファイルとして保存します。結果を右クリックし、「CSVとして保存」などのオプションを選択します。
アップロードの準備をする：エクスポートしたCSVファイルがUTF-8でエンコードされ、列見出しがProcessMindの要件に合っていることを確認します。追加のデータ変換は不要です。

設定

前提条件：この方法を使うには、Microsoft Dynamics 365 FinanceとAzure Data Lake Storage Gen2アカウントの連携が正常に動作している必要があります。また、このデータをクエリできるようにAzure Synapse Analyticsワークスペースを設定してください。ユーザーには、Azure Synapseとデータレイクの両方で適切な読み取り権限が必要です。
データエンティティ：以下のD365エンティティがデータレイクへのエクスポートに含まれていることを確認します：LedgerJournalTable、LedgerJournalTrans、WorkflowTrackingStatusTable、GeneralJournalEntry、UserInfo。
日付範囲の指定：提供するクエリには@StartDateと@EndDateのパラメーターがあります。クエリの処理性能とコストを管理するため、まずは3～6か月など、期間を限定して実行することを強くおすすめします。業務の状況を代表する期間を分析してください。
法人による絞り込み：特定の会社を対象に分析するには、クエリをDataAreaId（法人）で絞り込みます。大規模なD365環境では、処理性能を保つために欠かせないフィルターです。プレースホルダーの[YourLegalEntity]を置き換えてください。
ワークフローの設定：承認・却下イベントに関するクエリのロジックは、標準のD365ワークフローエンジンが使われ、データがWorkflowTrackingStatusTableに記録されることを前提としています。別の承認方法やカスタムの仕組みを使っている場合は、クエリの調整が必要です。

クエリの例 sql

DECLARE @StartDate DATETIME = '2023-01-01';
DECLARE @EndDate DATETIME = '2023-12-31';

WITH JournalHeaders AS (
    SELECT 
        JOURNALBATCHNUMBER AS JournalEntryId,
        JOURNALTYPE AS JournalType,
        DOCUMENTSTATUS AS JournalStatus, -- Captures Posted, etc.
        APPROVALSTATUS AS ApprovalStatus, -- Captures Draft, InReview, Approved, Rejected
        LOG AS RejectionReason, -- Often contains rejection comments
        POSTEDDATETIME, 
        CREATEDDATETIME,
        CREATEDBY,
        MODIFIEDDATETIME,
        MODIFIEDBY,
        DATA indignationId
    FROM 
        [YourD365DB].[dbo].LedgerJournalTable
    WHERE 
        CREATEDDATETIME BETWEEN @StartDate AND @EndDate
        AND DATA indignationId = '[YourLegalEntity]'
),
WorkflowEvents AS (
    SELECT 
        wtst.CONTEXTRECID,
        wtst.CONTEXTTABLEID,
        wtst.USERID,
        wtst.CREATEDDATETIME,
        wtst.TRACKINGSTATUS, -- Submitted, Approved, Rejected
        wtsi.INSTANCENUMBER
    FROM 
        [YourD365DB].[dbo].WorkflowTrackingStatusTable wtst
    JOIN 
        [YourD365DB].[dbo].WorkflowTrackingTable wtsi ON wtst.WORKFLOWTRACKINGTABLEINSTANCENUMBER = wtsi.RECID
    WHERE 
        wtst.CONTEXTTABLEID = (SELECT TABLEID FROM [YourD365DB].[dbo].SysTableIdTable WHERE NAME = 'LedgerJournalTable')
)

-- 1. Journal Entry Created
SELECT 
    jh.JournalEntryId AS JournalEntryId,
    'Journal Entry Created' AS ActivityName,
    jh.CREATEDDATETIME AS EventTime,
    NULL AS EventEndTime,
    u.NAME AS UserName,
    jh.JournalType,
    CAST(jh.ApprovalStatus AS VARCHAR) AS JournalStatus,
    NULL AS RejectionReason,
    jh.DataAreaId AS LegalEntity,
    (SELECT SUM(ABS(jlt.AMOUNTCREDIT)) FROM [YourD365DB].[dbo].LedgerJournalTrans jlt WHERE jlt.JOURNALBATCHNUMBER = jh.JournalEntryId) AS JournalTotalAmount
FROM 
    JournalHeaders jh
LEFT JOIN 
    [YourD365DB].[dbo].UserInfo u ON jh.CREATEDBY = u.ID

UNION ALL

-- 2. Journal Line Added
SELECT 
    jlt.JOURNALBATCHNUMBER AS JournalEntryId,
    'Journal Line Added' AS ActivityName,
    jlt.CREATEDDATETIME AS EventTime,
    NULL AS EventEndTime,
    u.NAME AS UserName,
    jh.JournalType,
    CAST(jh.ApprovalStatus AS VARCHAR) AS JournalStatus,
    NULL AS RejectionReason,
    jlt.DATA indignationId AS LegalEntity,
    NULL AS JournalTotalAmount
FROM 
    [YourD365DB].[dbo].LedgerJournalTrans jlt
JOIN 
    JournalHeaders jh ON jlt.JOURNALBATCHNUMBER = jh.JournalEntryId AND jlt.DATA indignationId = jh.DataAreaId
LEFT JOIN 
    [YourD365DB].[dbo].UserInfo u ON jlt.CREATEDBY = u.ID

UNION ALL

-- 3. Journal Submitted For Approval
SELECT 
    jh.JournalEntryId,
    'Journal Submitted For Approval' AS ActivityName,
    we.CREATEDDATETIME AS EventTime,
    NULL AS EventEndTime,
    u.NAME AS UserName,
    jh.JournalType,
    'InReview' AS JournalStatus,
    NULL AS RejectionReason,
    jh.DataAreaId AS LegalEntity,
    NULL AS JournalTotalAmount
FROM 
    JournalHeaders jh
JOIN 
    WorkflowEvents we ON jh.RecId = we.CONTEXTRECID
LEFT JOIN 
    [YourD365DB].[dbo].UserInfo u ON we.USERID = u.ID
WHERE 
    we.TRACKINGSTATUS = 1 -- Submitted

UNION ALL

-- 4. Journal Review Started (Approximation)
SELECT 
    jh.JournalEntryId,
    'Journal Review Started' AS ActivityName,
    we.CREATEDDATETIME AS EventTime,
    NULL AS EventEndTime,
    u.NAME AS UserName,
    jh.JournalType,
    'InReview' AS JournalStatus,
    NULL AS RejectionReason,
    jh.DataAreaId AS LegalEntity,
    NULL AS JournalTotalAmount
FROM 
    JournalHeaders jh
JOIN 
    WorkflowEvents we ON jh.RecId = we.CONTEXTRECID
LEFT JOIN 
    [YourD365DB].[dbo].UserInfo u ON we.USERID = u.ID
WHERE 
    we.TRACKINGTYPE = 5 -- Work item creation

UNION ALL

-- 5. Journal Approved
SELECT 
    jh.JournalEntryId,
    'Journal Approved' AS ActivityName,
    we.CREATEDDATETIME AS EventTime,
    NULL AS EventEndTime,
    u.NAME AS UserName,
    jh.JournalType,
    'Approved' AS JournalStatus,
    NULL AS RejectionReason,
    jh.DataAreaId AS LegalEntity,
    NULL AS JournalTotalAmount
FROM 
    JournalHeaders jh
JOIN 
    WorkflowEvents we ON jh.RecId = we.CONTEXTRECID
LEFT JOIN 
    [YourD365DB].[dbo].UserInfo u ON we.USERID = u.ID
WHERE 
    we.TRACKINGSTATUS = 5 -- Completion

UNION ALL

-- 6. Journal Rejected
SELECT 
    jh.JournalEntryId,
    'Journal Rejected' AS ActivityName,
    we.CREATEDDATETIME AS EventTime,
    NULL AS EventEndTime,
    u.NAME AS UserName,
    jh.JournalType,
    'Rejected' AS JournalStatus,
    jh.RejectionReason,
    jh.DataAreaId AS LegalEntity,
    NULL AS JournalTotalAmount
FROM 
    JournalHeaders jh
JOIN 
    WorkflowEvents we ON jh.RecId = we.CONTEXTRECID
LEFT JOIN 
    [YourD365DB].[dbo].UserInfo u ON we.USERID = u.ID
WHERE 
    we.TRACKINGSTATUS = 3 -- Rejection

UNION ALL

-- 7. Journal Entry Corrected (Approximation)
SELECT 
    jh.JournalEntryId,
    'Journal Entry Corrected' AS ActivityName,
    jh.MODIFIEDDATETIME AS EventTime,
    NULL AS EventEndTime,
    u.NAME AS UserName,
    jh.JournalType,
    'Corrected' AS JournalStatus,
    NULL AS RejectionReason,
    jh.DataAreaId AS LegalEntity,
    NULL AS JournalTotalAmount
FROM 
    JournalHeaders jh
LEFT JOIN 
    [YourD365DB].[dbo].UserInfo u ON jh.MODIFIEDBY = u.ID
WHERE 
    jh.MODIFIEDDATETIME > jh.CREATEDDATETIME AND
    EXISTS (
        SELECT 1 FROM WorkflowEvents we 
        WHERE we.CONTEXTRECID = jh.RecId AND we.TRACKINGSTATUS = 3 -- Rejection
        AND jh.MODIFIEDDATETIME > we.CREATEDDATETIME
    )

UNION ALL

-- 8. Journal Resubmitted For Approval
SELECT 
    jh.JournalEntryId,
    'Journal Resubmitted For Approval' AS ActivityName,
    we.CREATEDDATETIME AS EventTime,
    NULL AS EventEndTime,
    u.NAME AS UserName,
    jh.JournalType,
    'InReview' AS JournalStatus,
    NULL AS RejectionReason,
    jh.DataAreaId AS LegalEntity,
    NULL AS JournalTotalAmount
FROM 
    JournalHeaders jh
JOIN 
    WorkflowEvents we ON jh.RecId = we.CONTEXTRECID
LEFT JOIN 
    [YourD365DB].[dbo].UserInfo u ON we.USERID = u.ID
WHERE 
    we.TRACKINGSTATUS = 1 -- Submitted
    AND EXISTS (
        SELECT 1 FROM WorkflowEvents rej_we 
        WHERE rej_we.CONTEXTRECID = jh.RecId AND rej_we.TRACKINGSTATUS = 3 -- Rejection
        AND we.CREATEDDATETIME > rej_we.CREATEDDATETIME
    )

UNION ALL

-- 9. Journal Posting Attempted (Approximation)
SELECT 
    jh.JournalEntryId,
    'Journal Posting Attempted' AS ActivityName,
    DATEADD(second, -5, jh.POSTEDDATETIME) AS EventTime, -- Approximated as just before posting
    jh.POSTEDDATETIME AS EventEndTime,
    u.NAME AS UserName,
    jh.JournalType,
    'Posting' AS JournalStatus,
    NULL AS RejectionReason,
    jh.DataAreaId AS LegalEntity,
    NULL AS JournalTotalAmount
FROM 
    JournalHeaders jh
LEFT JOIN 
    [YourD365DB].[dbo].UserInfo u ON jh.MODIFIEDBY = u.ID -- Often posted by the last modifier or a system account
WHERE 
    jh.POSTEDDATETIME IS NOT NULL

UNION ALL

-- 10. Journal Entry Posted
SELECT 
    jh.JournalEntryId,
    'Journal Entry Posted' AS ActivityName,
    jh.POSTEDDATETIME AS EventTime,
    NULL AS EventEndTime,
    u.NAME AS UserName,
    jh.JournalType,
    'Posted' AS JournalStatus,
    NULL AS RejectionReason,
    jh.DataAreaId AS LegalEntity,
    NULL AS JournalTotalAmount
FROM 
    JournalHeaders jh
LEFT JOIN 
    [YourD365DB].[dbo].UserInfo u ON jh.MODIFIEDBY = u.ID
WHERE 
    jh.POSTEDDATETIME IS NOT NULL

UNION ALL

-- 11. Journal Entry Reversal Initiated
SELECT 
    gje.JOURNALNUMBER AS JournalEntryId,
    'Journal Entry Reversal Initiated' AS ActivityName,
    gje_rev.CREATEDDATETIME AS EventTime,
    NULL AS EventEndTime,
    u.NAME AS UserName,
    jh.JournalType,
    'Reversing' AS JournalStatus,
    NULL AS RejectionReason,
    gje.LEDGER AS LegalEntity,
    NULL AS JournalTotalAmount
FROM
    [YourD365DB].[dbo].GeneralJournalEntry gje
JOIN
    [YourD365DB].[dbo].GeneralJournalEntry gje_rev ON gje.JOURNALNUMBER = gje_rev.OriginalJournalNumber
JOIN
    JournalHeaders jh ON gje.JOURNALNUMBER = jh.JournalEntryId
LEFT JOIN 
    [YourD365DB].[dbo].UserInfo u ON gje_rev.CREATEDBY = u.ID
WHERE
    gje.REVERSED = 'Yes'

UNION ALL

-- 12. Journal Entry Reversed
SELECT 
    gje.JOURNALNUMBER AS JournalEntryId,
    'Journal Entry Reversed' AS ActivityName,
    gje.REVERSEDDATE AS EventTime,
    NULL AS EventEndTime,
    u.NAME AS UserName,
    jh.JournalType,
    'Reversed' AS JournalStatus,
    NULL AS RejectionReason,
    gje.LEDGER AS LegalEntity,
    NULL AS JournalTotalAmount
FROM
    [YourD365DB].[dbo].GeneralJournalEntry gje
JOIN
    JournalHeaders jh ON gje.JOURNALNUMBER = jh.JournalEntryId
LEFT JOIN 
    [YourD365DB].[dbo].UserInfo u ON gje.MODIFIEDBY = u.ID
WHERE
    gje.REVERSED = 'Yes' AND gje.REVERSEDDATE IS NOT NULL;

ステップ

前提条件と環境の準備：使用するマシンにPython 3.xをインストールします。pipを使って必要なPythonライブラリをインストールします：pip install pandas requests adal。adalライブラリは、Dynamics 365で必要となるAzure Active Directory認証に使用します。
Azure ADにアプリケーションを登録する：Dynamics 365 APIにアクセスするには、Azure Active Directoryにアプリケーションを登録する必要があります。アプリケーション（クライアント）IDとディレクトリ（テナント）IDを控え、クライアントシークレットを作成します。Financials.Readなど、Dynamics 365 Finance & Operationsへのアクセスに必要な委任されたアクセス許可をアプリケーションに付与します。
Pythonスクリプトを設定する：提供されたPythonスクリプトをextract_journals.pyなどのファイルにコピーします。スクリプトの先頭にあるプレースホルダー変数に、Azure ADとDynamics 365の情報を入力します：TENANT_ID、CLIENT_ID、CLIENT_SECRET、D365_URL。
抽出パラメーターを設定する：スクリプト内のSTART_DATEとEND_DATEを変更し、データを抽出する期間を指定します。LEGAL_ENTITIESリストを編集して、特定の会社コードに絞り込むこともできます。
抽出スクリプトを実行する：コマンドラインからpython extract_journals.pyを実行します。スクリプトがAzure ADで認証し、アクセストークンを取得した後、指定期間内の仕訳ヘッダーと明細データをDynamics 365 OData APIから取得します。
スクリプトの実行状況を確認する：APIからデータのページを取得するたびに、進行状況がコンソールに表示されます。データ量によっては、完了までに時間がかかる場合があります。スクリプトがAPIのページネーションを自動処理し、該当するレコードをすべて取得します。
生のデータを確認する（任意）：スクリプトはまず、クエリで取得した生のデータをraw_journal_headers.csvとraw_journal_lines.csvに保存します。変換処理を実行する前に、これらのファイルを確認してデータを正常に取得できたか確かめられます。
イベントの推定方法を確認する：スクリプトは生のデータを処理し、必要な12種類のプロセスアクティビティを推定します。たとえば、WorkflowApprovalStatusフィールドが「Draft」から「Submitted」に変わった場合、「仕訳承認申請」イベントとして扱います。このイベントのタイムスタンプには、レコードのModifiedDateTimeフィールドを使います。
最終イベントログを作成する：処理後、推定したすべてのイベントを1つの構造化されたイベントログにまとめます。JournalEntryId、ActivityName、EventTimeと、その他の推奨属性を列として作成します。
CSVファイルをエクスポートして確認する：最終イベントログはjournal_entry_event_log.csvとして保存されます。ファイルを開き、構造と内容を確認します。想定した列が含まれ、各アクティビティのデータが作成されていることを確かめてください。
ProcessMindへのアップロードを準備する：生成されたCSVファイルはアップロードに適した形式です。UTF-8で保存されていることを確認してください。このファイルをProcessMindのデータソースとして指定し、決算・レポーティングの仕訳プロセスを分析できます。

設定

APIエンドポイントURL：Dynamics 365 Finance & Operations OData APIのベースURLです。スクリプトのD365_URL変数に設定します。例：https://your-org.operations.dynamics.com。
Azure ADの認証情報：このスクリプトでは、Azure ADへのアプリケーション登録が必要です。認証に使うTENANT_ID、CLIENT_ID、CLIENT_SECRETを指定してください。
必要なAPIアクセス許可：Azure ADアプリケーションには、Dynamics 365のデータを読み取るための委任されたアクセス許可が必要です。仕訳データへのアクセスには、通常Financials.Readで十分です。
日付範囲：スクリプトのSTART_DATEとEND_DATEで抽出期間を指定します。初回の分析では、データ量とプロセスのインサイトのバランスを考慮し、3～6か月をおすすめします。
法人フィルター：スクリプトのLEGAL_ENTITIESリストで、抽出対象の会社コード（dataAreaId）を指定できます。関連する業務に分析対象を絞るうえで重要です。
データエンティティ：スクリプトでは主に、ODataエンティティのLedgerJournalHeadersとLedgerJournalLinesをクエリします。これらはDynamics 365の仕訳データに使われる標準エンティティです。
ステータスフィールドのマッピング：アクティビティの推定には、標準のWorkflowApprovalStatusフィールドを使います。仕訳のステータス管理にカスタムフィールドを使っている場合は、スクリプト内のフィールド名を更新してください。

クエリの例 python

import adal
import requests
import pandas as pd
from datetime import datetime

class=class="hl-string">"hl-comment"># --- Configuration --- 
class=class="hl-string">"hl-comment"># Azure AD Application Details
TENANT_ID = class="hl-string">'[Your Tenant ID]'
CLIENT_ID = class="hl-string">'[Your Application Client ID]'
CLIENT_SECRET = class="hl-string">'[Your Client Secret]'

class=class="hl-string">"hl-comment"># Dynamics 365 F&O Environment Details
D365_URL = class="hl-string">'https://[your-d365-url].operations.dynamics.com'
RESOURCE = D365_URL
AUTHORITY_URL = fclass="hl-string">'https://login.microsoftonline.com/{TENANT_ID}'

class=class="hl-string">"hl-comment"># Extraction Parameters
START_DATE = class="hl-string">'2023-01-01T00:00:00Z'
END_DATE = class="hl-string">'2023-12-31T23:59:59Z'
LEGAL_ENTITIES = [class="hl-string">'[YourLegalEntity1]', class="hl-string">'[YourLegalEntity2]'] class=class="hl-string">"hl-comment"># e.g., [class="hl-string">'USMF']

class=class="hl-string">"hl-comment"># --- OData Helper Functions ---

def get_access_token():
    class="hl-string">"""Authenticates with Azure AD to get an access token."""
    context = adal.AuthenticationContext(AUTHORITY_URL)
    token = context.acquire_token_with_client_credentials(RESOURCE, CLIENT_ID, CLIENT_SECRET)
    if class="hl-string">'accessToken' not in token:
        raise Exception(fclass="hl-string">"Failed to get access token: {token.get('error_description')}")
    return token[class="hl-string">'accessToken']

def execute_odata_query(entity_url, headers):
    class="hl-string">"""Executes a paginated OData query and returns a list of records."""
    all_records = []
    next_link = entity_url
    page_num = 1
    while next_link:
        print(fclass="hl-string">"Fetching page {page_num} for entity: {entity_url.split('/')[-1].split('?')[0]}...")
        response = requests.get(next_link, headers=headers)
        if response.status_code != 200:
            raise Exception(fclass="hl-string">"Query failed with status {response.status_code}: {response.text}")
        data = response.json()
        all_records.extend(data[class="hl-string">'value'])
        next_link = data.get(class="hl-string">'@odata.nextLink')
        page_num += 1
    return all_records

class=class="hl-string">"hl-comment"># --- Main Extraction Logic ---

if __name__ == class="hl-string">"__main__":
    print(class="hl-string">"Starting Journal Entry data extraction...")
    
    class=class="hl-string">"hl-comment"># 1. Get Access Token
    access_token = get_access_token()
    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">'Accept': class="hl-string">'application/json'
    }

    class=class="hl-string">"hl-comment"># 2. Build and Execute Queries
    legal_entity_filter = class="hl-string">" or ".join([fclass="hl-string">"dataAreaId eq '{le}'" for le in LEGAL_ENTITIES])
    date_filter = fclass="hl-string">"CreatedDateTime ge {START_DATE} and CreatedDateTime le {END_DATE}"

    class=class="hl-string">"hl-comment"># Query LedgerJournalHeaders
    headers_fields = [
        class="hl-string">'JournalBatchNumber', class="hl-string">'dataAreaId', class="hl-string">'LedgerJournalType', class="hl-string">'WorkflowApprovalStatus',
        class="hl-string">'CreatedBy', class="hl-string">'CreatedDateTime', class="hl-string">'ModifiedBy', class="hl-string">'ModifiedDateTime', class="hl-string">'PostedDateTime',
        class="hl-string">'JournalTotalDebit', class="hl-string">'Reversed', class="hl-string">'ReversedDate', class="hl-string">'RejectionReasonComment' class=class="hl-string">"hl-comment"># Assuming a field for rejection reason
    ]
    headers_select = fclass="hl-string">"$select={','.join(headers_fields)}"
    headers_filter = fclass="hl-string">"$filter=({legal_entity_filter}) and ({date_filter})"
    headers_url = fclass="hl-string">"{D365_URL}/data/LedgerJournalHeaders?{headers_select}&{headers_filter}&cross-company=true"
    
    journal_headers_raw = execute_odata_query(headers_url, headers)
    if not journal_headers_raw:
        print(class="hl-string">"No journal headers found for the specified criteria. Exiting.")
        exit()

    df_headers = pd.DataFrame(journal_headers_raw)
    df_headers.to_csv(class="hl-string">'raw_journal_headers.csv', index=False)
    print(fclass="hl-string">"Fetched and saved {len(df_headers)} journal headers.")

    class=class="hl-string">"hl-comment"># Query LedgerJournalLines for class="hl-string">'Line Added' activity
    journal_batch_numbers = df_headers[class="hl-string">'JournalBatchNumber'].unique().tolist()
    journal_batch_filter = class="hl-string">" or ".join([fclass="hl-string">"JournalBatchNumber eq '{jbn}'" for jbn in journal_batch_numbers])
    
    lines_fields = [class="hl-string">'JournalBatchNumber', class="hl-string">'CreatedDateTime', class="hl-string">'CreatedBy']
    lines_select = fclass="hl-string">"$select={','.join(lines_fields)}"
    lines_filter = fclass="hl-string">"$filter=({legal_entity_filter}) and ({journal_batch_filter})"
    lines_url = fclass="hl-string">"{D365_URL}/data/LedgerJournalLines?{lines_select}&{lines_filter}&cross-company=true"

    journal_lines_raw = execute_odata_query(lines_url, headers)
    df_lines = pd.DataFrame(journal_lines_raw)
    df_lines.to_csv(class="hl-string">'raw_journal_lines.csv', index=False)
    print(fclass="hl-string">"Fetched and saved {len(df_lines)} journal lines.")

    class=class="hl-string">"hl-comment"># 3. Transform Data into Event Log Format
    print(class="hl-string">"Transforming raw data into event log...")
    event_log_frames = []

    class=class="hl-string">"hl-comment"># Rename columns for consistency
    df_headers.rename(columns={
        class="hl-string">'JournalBatchNumber': class="hl-string">'JournalEntryId',
        class="hl-string">'dataAreaId': class="hl-string">'LegalEntity',
        class="hl-string">'LedgerJournalType': class="hl-string">'JournalType',
        class="hl-string">'JournalTotalDebit': class="hl-string">'JournalTotalAmount',
        class="hl-string">'WorkflowApprovalStatus': class="hl-string">'JournalStatus',
        class="hl-string">'RejectionReasonComment': class="hl-string">'RejectionReason'
    }, inplace=True)
    df_lines.rename(columns={class="hl-string">'JournalBatchNumber': class="hl-string">'JournalEntryId'}, inplace=True)

    class=class="hl-string">"hl-comment"># Activity: Journal Entry Created
    df_created = df_headers[[class="hl-string">'JournalEntryId', class="hl-string">'CreatedDateTime', class="hl-string">'CreatedBy']].copy()
    df_created[class="hl-string">'ActivityName'] = class="hl-string">'Journal Entry Created'
    df_created.rename(columns={class="hl-string">'CreatedDateTime': class="hl-string">'EventTime', class="hl-string">'CreatedBy': class="hl-string">'UserName'}, inplace=True)
    event_log_frames.append(df_created)

    class=class="hl-string">"hl-comment"># Activity: Journal Line Added
    df_line_added = df_lines[[class="hl-string">'JournalEntryId', class="hl-string">'CreatedDateTime', class="hl-string">'CreatedBy']].copy()
    df_line_added[class="hl-string">'ActivityName'] = class="hl-string">'Journal Line Added'
    df_line_added.rename(columns={class="hl-string">'CreatedDateTime': class="hl-string">'EventTime', class="hl-string">'CreatedBy': class="hl-string">'UserName'}, inplace=True)
    event_log_frames.append(df_line_added)

    class=class="hl-string">"hl-comment"># Activities inferred from status changes and modifications
    class=class="hl-string">"hl-comment"># This part requires a more stateful analysis if audit trails are not directly available
    class=class="hl-string">"hl-comment"># We use ModifiedDateTime as a proxy for the event time of status changes.
    
    class=class="hl-string">"hl-comment"># NOTE: The logic below is a simplified inference. A real implementation might require parsing audit trail logs for precise timestamps.
    status_events_map = {
        class="hl-string">'Submitted': class="hl-string">'Journal Submitted For Approval',
        class="hl-string">'InProgress': class="hl-string">'Journal Review Started', class=class="hl-string">"hl-comment"># Approximation
        class="hl-string">'Approved': class="hl-string">'Journal Approved',
        class="hl-string">'Rejected': class="hl-string">'Journal Rejected',
        class="hl-string">'ChangeRequested': class="hl-string">'Journal Rejected', class=class="hl-string">"hl-comment"># Map another status to Rejected
        class="hl-string">'Canceled': class="hl-string">'Journal Rejected' class=class="hl-string">"hl-comment"># Map another status to Rejected
    }

    status_change_df = df_headers[df_headers[class="hl-string">'JournalStatus'].isin(status_events_map.keys())].copy()
    status_change_df[class="hl-string">'ActivityName'] = status_change_df[class="hl-string">'JournalStatus'].map(status_events_map)
    status_change_df.rename(columns={class="hl-string">'ModifiedDateTime': class="hl-string">'EventTime', class="hl-string">'ModifiedBy': class="hl-string">'UserName'}, inplace=True)
    event_log_frames.append(status_change_df[[class="hl-string">'JournalEntryId', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'UserName', class="hl-string">'RejectionReason']])

    class=class="hl-string">"hl-comment"># Activity: Journal Resubmitted For Approval & Journal Entry Corrected
    class=class="hl-string">"hl-comment"># Infer this by finding a class="hl-string">'Submitted' status that occurred after a class="hl-string">'Rejected' status for the same journal.
    class=class="hl-string">"hl-comment"># For simplicity, we assume any modification after rejection is a correction.
    df_rejected = status_change_df[status_change_df[class="hl-string">'ActivityName'] == class="hl-string">'Journal Rejected']
    for index, row in df_rejected.iterrows():
        class=class="hl-string">"hl-comment"># Check for modifications on the header after rejection
        header_row = df_headers[df_headers[class="hl-string">'JournalEntryId'] == row[class="hl-string">'JournalEntryId']].iloc[0]
        if pd.to_datetime(header_row[class="hl-string">'ModifiedDateTime']) > pd.to_datetime(row[class="hl-string">'EventTime']):
            class=class="hl-string">"hl-comment"># Add Corrected Event
            corrected_event = row.copy()
            corrected_event[class="hl-string">'ActivityName'] = class="hl-string">'Journal Entry Corrected'
            corrected_event[class="hl-string">'EventTime'] = header_row[class="hl-string">'ModifiedDateTime']
            corrected_event[class="hl-string">'UserName'] = header_row[class="hl-string">'ModifiedBy']
            event_log_frames.append(pd.DataFrame([corrected_event]))
            
            class=class="hl-string">"hl-comment"># If status went back to submitted, it's a resubmission
            if header_row[class="hl-string">'JournalStatus'] == class="hl-string">'Submitted':
                resubmitted_event = row.copy()
                resubmitted_event[class="hl-string">'ActivityName'] = class="hl-string">'Journal Resubmitted For Approval'
                resubmitted_event[class="hl-string">'EventTime'] = header_row[class="hl-string">'ModifiedDateTime']
                resubmitted_event[class="hl-string">'UserName'] = header_row[class="hl-string">'ModifiedBy']
                event_log_frames.append(pd.DataFrame([resubmitted_event]))

    class=class="hl-string">"hl-comment"># Activity: Journal Posting Attempted (Approximation)
    class=class="hl-string">"hl-comment"># This is difficult to capture. We'll use the approval time as a proxy.
    df_approved_for_posting = status_change_df[status_change_df[class="hl-string">'ActivityName'] == class="hl-string">'Journal Approved'].copy()
    df_approved_for_posting[class="hl-string">'ActivityName'] = class="hl-string">'Journal Posting Attempted'
    event_log_frames.append(df_approved_for_posting[[class="hl-string">'JournalEntryId', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'UserName']])

    class=class="hl-string">"hl-comment"># Activity: Journal Entry Posted
    df_posted = df_headers[df_headers[class="hl-string">'PostedDateTime'].notna()].copy()
    if not df_posted.empty:
        df_posted[class="hl-string">'ActivityName'] = class="hl-string">'Journal Entry Posted'
        class=class="hl-string">"hl-comment"># Use PostedDateTime if available, otherwise fallback to ModifiedDateTime
        df_posted[class="hl-string">'EventTime'] = df_posted[class="hl-string">'PostedDateTime'].fillna(df_posted[class="hl-string">'ModifiedDateTime'])
        df_posted.rename(columns={class="hl-string">'ModifiedBy': class="hl-string">'UserName'}, inplace=True)
        event_log_frames.append(df_posted[[class="hl-string">'JournalEntryId', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'UserName']])

    class=class="hl-string">"hl-comment"># Activity: Journal Entry Reversal Initiated & Reversed
    df_reversed = df_headers[df_headers[class="hl-string">'Reversed'] == True].copy()
    if not df_reversed.empty:
        class=class="hl-string">"hl-comment"># Reversal Initiated (approximated by modification date when Reversed flag is set)
        df_reversal_initiated = df_reversed.copy()
        df_reversal_initiated[class="hl-string">'ActivityName'] = class="hl-string">'Journal Entry Reversal Initiated'
        df_reversal_initiated.rename(columns={class="hl-string">'ModifiedDateTime': class="hl-string">'EventTime', class="hl-string">'ModifiedBy': class="hl-string">'UserName'}, inplace=True)
        event_log_frames.append(df_reversal_initiated[[class="hl-string">'JournalEntryId', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'UserName']])
        class=class="hl-string">"hl-comment"># Reversed (using the specific ReversedDate)
        df_reversed_final = df_reversed[df_reversed[class="hl-string">'ReversedDate'].notna()].copy()
        df_reversed_final[class="hl-string">'ActivityName'] = class="hl-string">'Journal Entry Reversed'
        df_reversed_final.rename(columns={class="hl-string">'ReversedDate': class="hl-string">'EventTime', class="hl-string">'ModifiedBy': class="hl-string">'UserName'}, inplace=True)
        event_log_frames.append(df_reversed_final[[class="hl-string">'JournalEntryId', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'UserName']])

    class=class="hl-string">"hl-comment"># 4. Assemble Final Event Log
    print(class="hl-string">"Assembling the final event log...")
    final_event_log = pd.concat(event_log_frames, ignore_index=True)

    class=class="hl-string">"hl-comment"># Merge attributes from the header file
    attributes_to_merge = df_headers[[class="hl-string">'JournalEntryId', class="hl-string">'LegalEntity', class="hl-string">'JournalType', class="hl-string">'JournalStatus', class="hl-string">'JournalTotalAmount', class="hl-string">'RejectionReason']].drop_duplicates()
    final_event_log = pd.merge(final_event_log, attributes_to_merge, on=class="hl-string">'JournalEntryId', how=class="hl-string">'left')

    class=class="hl-string">"hl-comment"># Clean up and order columns
    final_event_log[class="hl-string">'EventTime'] = pd.to_datetime(final_event_log[class="hl-string">'EventTime'])
    final_event_log.sort_values(by=[class="hl-string">'JournalEntryId', class="hl-string">'EventTime'], inplace=True)
    final_event_log.drop_duplicates(subset=[class="hl-string">'JournalEntryId', class="hl-string">'ActivityName', class="hl-string">'EventTime'], inplace=True)
    
    class=class="hl-string">"hl-comment"># Define column order
    final_columns = [
        class="hl-string">'JournalEntryId', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'UserName', class="hl-string">'LegalEntity',
        class="hl-string">'JournalType', class="hl-string">'JournalStatus', class="hl-string">'JournalTotalAmount', class="hl-string">'RejectionReason'
    ]
    class=class="hl-string">"hl-comment"># Add missing columns with None
    for col in final_columns:
        if col not in final_event_log.columns:
            final_event_log[col] = None
    final_event_log = final_event_log[final_columns]
    
    class=class="hl-string">"hl-comment"># Add EventEndTime (optional, can be populated if duration is known)
    final_event_log[class="hl-string">'EventEndTime'] = None
    
    class=class="hl-string">"hl-comment"># 5. Export to CSV
    final_event_log.to_csv(class="hl-string">'journal_entry_event_log.csv', index=False, date_format=class="hl-string">'%Y-%m-%dT%H:%M:%SZ')
    print(fclass="hl-string">"Extraction complete. Event log with {len(final_event_log)} events saved to journal_entry_event_log.csv")

ステップ

対象環境でPower Platform Dataflows、Dynamics 365標準コネクタ、必要なDynamics 365データエンティティを利用できることを確認します。仕訳ヘッダー、仕訳明細、ワークフローまたは承認履歴、ステータス履歴、ユーザー情報、法人データ、取消または転記履歴を読み取るために必要なアクセス許可を取得します。利用できるエンティティは、Dynamics 365のアプリケーションや設定によって異なります。必要なデータがコネクタから取得できない場合は、[Your table name]または[Configure based on your system]を使用します。
Power Appsで対象環境を開き、データフローを作成します。Dynamics 365標準コネクタを選択し、環境への接続情報を入力して、必要なエンティティを読み取る権限のあるアカウントで認証します。変換ロジックに認証情報を埋め込まないでください。
仕訳ヘッダーエンティティ、仕訳明細エンティティに加え、ワークフロー、ステータス、割り当て、監査、転記、取消のイベントを記録する設定済みのソースをすべて追加します。仕訳の識別、イベントのタイムスタンプ、ユーザー、仕訳タイプ、ステータス、却下理由、法人、合計金額に必要なフィールドを選択します。実際のエンティティとフィールドのマッピングをデータフローの文書に記録します。
Power Queryで、設定した日付範囲と会社または法人のフィルターを適用します。ソースのタイムスタンプを保持し、文書化した1つのタイムゾーンに統一します。識別子はテキスト型、タイムスタンプは一貫した日時型、金額は数値型、ステータス値は一貫したテキスト値に変換します。使用可能なJournalEntryIdまたはEventTimeがないレコードは、別の例外出力に残す場合を除き、削除します。
必要な12種類のアクティビティごとにイベントクエリを作成します。各クエリから、JournalEntryId、ActivityName、EventTime、EventEndTime、UserName、JournalType、JournalStatus、RejectionReason、LegalEntity、JournalTotalAmountを含む行を明示的に出力します。ステータスやフィールドの変更からアクティビティをProcessMindに推定させないでください。
利用可能なソースデータに基づいてイベントルールを設定します。仕訳作成には仕訳の作成タイムスタンプ、仕訳明細追加には明細の作成タイムスタンプを使います。申請、レビュー、承認、却下には承認ワークフローまたはステータスの遷移を使います。却下後の変更は仕訳修正、後続の申請遷移は仕訳再申請、転記の開始・完了記録は仕訳転記の試行・仕訳転記、取消の開始・完了記録は仕訳取消の開始・仕訳取消に使います。必要なイベントが明示的に記録されていない場合は、ソース履歴から監査可能な方法で導出し、そのルールを文書化します。
12種類すべてのイベントクエリを1つのイベントログクエリに追加します。すべての出力行に必要な列名が正確に含まれ、ActivityNameには文書化されたアクティビティ名のみが入り、EventTimeが設定されていることを確認します。JournalEntryId、EventTimeの順に並べ替え、ソースに情報がある場合は一意に順序を決めるための項目も指定します。
ProcessMindへの取り込みに使う、対応済みのデータレイク、データウェアハウス、データベース、ファイル出力先などをデータフローに設定します。イベントログは、1イベントにつき1行のフラットテーブルまたは区切り文字付きファイルとして保存します。UTF-8エンコード、ISO互換の日時値、安定したスキーマを維持します。
指定期間のデータフローを更新し、更新エラーと除外された行を確認します。イベント数をソースのエンティティや履歴と照合します。出力を公開する前に、マッピングやフィルターを修正してください。
完成したイベントログをエクスポートするか、ProcessMindへのアップロード用に参照できる状態にします。JournalEntryIdをケース識別子、ActivityNameをアクティビティ、EventTimeをイベントのタイムスタンプとしてマッピングし、残りの列をイベント属性またはケース属性として設定します。ProcessMindはイベントログをそのまま読み込むため、プロセスの可視化に必要なアクティビティがすべて行として含まれていることを確認してください。

設定

接続：Power Platform Dataflowsを通じてDynamics 365標準コネクタを使用します。環境と認証は、クエリテキストではなく、プラットフォームの接続設定で構成します。
ソースエンティティ：設定済みの仕訳ヘッダー、仕訳明細、ワークフローまたは承認履歴、ステータス履歴、監査履歴、転記履歴、取消履歴、ユーザー、法人の各エンティティを選択します。Dynamics 365のアプリケーションやカスタマイズによって正確な名前は異なるため、[Your table name]を使ってマッピングします。
必須の出力列：すべてのイベント行にJournalEntryId、ActivityName、EventTimeを設定します。
推奨する出力列：EventEndTime、UserName、JournalType、JournalStatus、RejectionReason、LegalEntity、JournalTotalAmount。
日付範囲：まずは3～6か月分の履歴を対象にします。更新時間、ソースデータの保持期間、イベントの網羅性を確認してから、期間を延長してください。イベントが指定した開始日以降に完了する場合は、開始日前の期間も含めます。
フィルター：分析対象に合致する場合に限り、会社コードまたは法人、仕訳タイプ、文書タイプ、仕訳ステータス、EventTimeで絞り込みます。プロセスの全体像を再構成するために必要な却下、修正、再申請、取消、転記済みのレコードを除外しないでください。
増分更新：利用できる場合は、信頼性の高いソースの更新タイムスタンプを使います。後から到着するワークフロー、監査、転記、取消のレコードを保持し、安定したソースイベント識別子または文書化した複合キーで重複を除去します。
タイムゾーン：すべてのソースのタイムスタンプを、文書化した1つのタイムゾーンに変換します。監査時の照合に必要な場合は、元のタイムスタンプも保持します。
処理性能：対応している場合はソース側で絞り込み、必要な列のみを選択します。不要な結合を避け、合計値を結合する前に仕訳明細を集計します。履歴データが大きい場合は、パーティション分割または増分更新を行います。
データ品質：JournalEntryIdまたはEventTimeがない行は除外するか、別途報告します。イベントクエリを追加する前に、ステータス名とユーザー識別子を統一します。
前提条件：Power Platform Dataflowsの利用環境、Dynamics 365コネクタへの接続、選択したすべてのエンティティへの読み取りアクセス、必要に応じたワークフロー・監査・転記・取消履歴へのアクセス、ProcessMindの出力先またはアップロード方法を利用するライセンスや権限が必要です。
設定への依存：Dynamics 365では、すべてのアプリケーションや導入環境で同じエンティティや履歴フィールドが公開されるわけではありません。導入前に、プレースホルダーを実際のエンティティとフィールドのマッピングに置き換えてください。

クエリの例 sql

WITH
JournalHeader AS (
    SELECT
        CAST([JournalEntryId] AS varchar(255)) AS JournalEntryId,
        [CreatedDateTime] AS CreatedDateTime,
        [ModifiedDateTime] AS ModifiedDateTime,
        [CreatedBy] AS CreatedBy,
        [ModifiedBy] AS ModifiedBy,
        [JournalType] AS JournalType,
        [JournalStatus] AS JournalStatus,
        [RejectionReason] AS RejectionReason,
        [LegalEntity] AS LegalEntity,
        [JournalTotalAmount] AS JournalTotalAmount
    FROM [Your journal header entity]
    WHERE [CreatedDateTime] >= '[Start date parameter]'
      AND [CreatedDateTime] < '[End date parameter]'
      AND ([LegalEntity] IN ([Your company filter]) OR [Your company filter] IS NULL)
),
JournalLines AS (
    SELECT
        CAST([JournalEntryId] AS varchar(255)) AS JournalEntryId,
        [CreatedDateTime] AS EventTime,
        [CreatedBy] AS UserName,
        [JournalType] AS JournalType,
        [JournalStatus] AS JournalStatus,
        [RejectionReason] AS RejectionReason,
        [LegalEntity] AS LegalEntity,
        [JournalTotalAmount] AS JournalTotalAmount
    FROM [Your journal line entity]
    WHERE [CreatedDateTime] >= '[Start date parameter]'
      AND [CreatedDateTime] < '[End date parameter]'
),
StatusHistory AS (
    SELECT
        CAST([JournalEntryId] AS varchar(255)) AS JournalEntryId,
        [StatusChangeDateTime] AS EventTime,
        [StatusChangeEndDateTime] AS EventEndTime,
        [ChangedBy] AS UserName,
        [PreviousStatus] AS PreviousStatus,
        [NewStatus] AS NewStatus,
        [JournalType] AS JournalType,
        [RejectionReason] AS RejectionReason,
        [LegalEntity] AS LegalEntity,
        [JournalTotalAmount] AS JournalTotalAmount
    FROM [Your journal status history entity]
    WHERE [StatusChangeDateTime] >= '[Start date parameter]'
      AND [StatusChangeDateTime] < '[End date parameter]'
),
ReviewHistory AS (
    SELECT
        CAST([JournalEntryId] AS varchar(255)) AS JournalEntryId,
        [ReviewStartDateTime] AS EventTime,
        [ReviewEndDateTime] AS EventEndTime,
        [Reviewer] AS UserName,
        [JournalType] AS JournalType,
        [JournalStatus] AS JournalStatus,
        [RejectionReason] AS RejectionReason,
        [LegalEntity] AS LegalEntity,
        [JournalTotalAmount] AS JournalTotalAmount
    FROM [Your journal review history entity]
    WHERE [ReviewStartDateTime] >= '[Start date parameter]'
      AND [ReviewStartDateTime] < '[End date parameter]'
),
PostingHistory AS (
    SELECT
        CAST([JournalEntryId] AS varchar(255)) AS JournalEntryId,
        [PostingAttemptDateTime] AS PostingAttemptDateTime,
        [PostingDateTime] AS PostingDateTime,
        [PostingEndDateTime] AS PostingEndTime,
        [PostedBy] AS PostedBy,
        [JournalType] AS JournalType,
        [JournalStatus] AS JournalStatus,
        [LegalEntity] AS LegalEntity,
        [JournalTotalAmount] AS JournalTotalAmount
    FROM [Your journal posting history entity]
    WHERE [PostingAttemptDateTime] >= '[Start date parameter]'
      AND [PostingAttemptDateTime] < '[End date parameter]'
),
ReversalHistory AS (
    SELECT
        CAST([JournalEntryId] AS varchar(255)) AS JournalEntryId,
        [ReversalInitiatedDateTime] AS ReversalInitiatedDateTime,
        [ReversalCompletedDateTime] AS ReversalCompletedDateTime,
        [ReversalCompletedBy] AS ReversalCompletedBy,
        [JournalType] AS JournalType,
        [JournalStatus] AS JournalStatus,
        [LegalEntity] AS LegalEntity,
        [JournalTotalAmount] AS JournalTotalAmount
    FROM [Your journal reversal history entity]
    WHERE [ReversalInitiatedDateTime] >= '[Start date parameter]'
      AND [ReversalInitiatedDateTime] < '[End date parameter]'
),
CorrectionHistory AS (
    SELECT
        CAST([JournalEntryId] AS varchar(255)) AS JournalEntryId,
        [ModificationDateTime] AS EventTime,
        [ModificationEndDateTime] AS EventEndTime,
        [ModifiedBy] AS UserName,
        [JournalType] AS JournalType,
        [JournalStatus] AS JournalStatus,
        [RejectionReason] AS RejectionReason,
        [LegalEntity] AS LegalEntity,
        [JournalTotalAmount] AS JournalTotalAmount
    FROM [Your journal audit or modification history entity]
    WHERE [ModificationDateTime] >= '[Start date parameter]'
      AND [ModificationDateTime] < '[End date parameter]'
),
EventLog AS (
    SELECT JournalEntryId, 'Journal Entry Created' AS ActivityName, CreatedDateTime AS EventTime, CreatedDateTime AS EventEndTime, CreatedBy AS UserName, JournalType, JournalStatus, RejectionReason, LegalEntity, JournalTotalAmount FROM JournalHeader WHERE JournalEntryId IS NOT NULL AND CreatedDateTime IS NOT NULL
    UNION ALL
    SELECT JournalEntryId, 'Journal Line Added' AS ActivityName, EventTime, EventTime AS EventEndTime, UserName, JournalType, JournalStatus, RejectionReason, LegalEntity, JournalTotalAmount FROM JournalLines WHERE JournalEntryId IS NOT NULL AND EventTime IS NOT NULL
    UNION ALL
    SELECT JournalEntryId, 'Journal Submitted For Approval' AS ActivityName, EventTime, EventEndTime, UserName, JournalType, NewStatus AS JournalStatus, RejectionReason, LegalEntity, JournalTotalAmount FROM StatusHistory WHERE JournalEntryId IS NOT NULL AND EventTime IS NOT NULL AND (NewStatus IN ('In Review', 'Submitted') OR (PreviousStatus = 'Draft' AND NewStatus IN ('In Review', 'Submitted')))
    UNION ALL
    SELECT JournalEntryId, 'Journal Review Started' AS ActivityName, EventTime, EventEndTime, UserName, JournalType, JournalStatus, RejectionReason, LegalEntity, JournalTotalAmount FROM ReviewHistory WHERE JournalEntryId IS NOT NULL AND EventTime IS NOT NULL
    UNION ALL
    SELECT JournalEntryId, 'Journal Approved' AS ActivityName, EventTime, EventEndTime, UserName, JournalType, NewStatus AS JournalStatus, RejectionReason, LegalEntity, JournalTotalAmount FROM StatusHistory WHERE JournalEntryId IS NOT NULL AND EventTime IS NOT NULL AND NewStatus = 'Approved'
    UNION ALL
    SELECT JournalEntryId, 'Journal Rejected' AS ActivityName, EventTime, EventEndTime, UserName, JournalType, NewStatus AS JournalStatus, RejectionReason, LegalEntity, JournalTotalAmount FROM StatusHistory WHERE JournalEntryId IS NOT NULL AND EventTime IS NOT NULL AND NewStatus IN ('Rejected', 'Needs Correction')
    UNION ALL
    SELECT c.JournalEntryId, 'Journal Entry Corrected' AS ActivityName, c.EventTime, c.EventEndTime, c.UserName, c.JournalType, c.JournalStatus, c.RejectionReason, c.LegalEntity, c.JournalTotalAmount FROM CorrectionHistory c WHERE c.JournalEntryId IS NOT NULL AND c.EventTime IS NOT NULL AND EXISTS (SELECT 1 FROM StatusHistory s WHERE s.JournalEntryId = c.JournalEntryId AND s.NewStatus IN ('Rejected', 'Needs Correction') AND s.EventTime < c.EventTime)
    UNION ALL
    SELECT JournalEntryId, 'Journal Resubmitted For Approval' AS ActivityName, EventTime, EventEndTime, UserName, JournalType, NewStatus AS JournalStatus, RejectionReason, LegalEntity, JournalTotalAmount FROM StatusHistory WHERE JournalEntryId IS NOT NULL AND EventTime IS NOT NULL AND PreviousStatus IN ('Rejected', 'Needs Correction', 'Draft') AND NewStatus IN ('In Review', 'Submitted')
    UNION ALL
    SELECT JournalEntryId, 'Journal Posting Attempted' AS ActivityName, PostingAttemptDateTime AS EventTime, PostingAttemptDateTime AS EventEndTime, PostedBy AS UserName, JournalType, JournalStatus, CAST(NULL AS varchar(255)) AS RejectionReason, LegalEntity, JournalTotalAmount FROM PostingHistory WHERE JournalEntryId IS NOT NULL AND PostingAttemptDateTime IS NOT NULL
    UNION ALL
    SELECT JournalEntryId, 'Journal Entry Posted' AS ActivityName, PostingDateTime AS EventTime, PostingEndTime AS EventEndTime, PostedBy AS UserName, JournalType, 'Posted' AS JournalStatus, CAST(NULL AS varchar(255)) AS RejectionReason, LegalEntity, JournalTotalAmount FROM PostingHistory WHERE JournalEntryId IS NOT NULL AND PostingDateTime IS NOT NULL
    UNION ALL
    SELECT JournalEntryId, 'Journal Entry Reversal Initiated' AS ActivityName, ReversalInitiatedDateTime AS EventTime, ReversalInitiatedDateTime AS EventEndTime, CAST(NULL AS varchar(255)) AS UserName, JournalType, JournalStatus, CAST(NULL AS varchar(255)) AS RejectionReason, LegalEntity, JournalTotalAmount FROM ReversalHistory WHERE JournalEntryId IS NOT NULL AND ReversalInitiatedDateTime IS NOT NULL
    UNION ALL
    SELECT JournalEntryId, 'Journal Entry Reversed' AS ActivityName, ReversalCompletedDateTime AS EventTime, ReversalCompletedDateTime AS EventEndTime, ReversalCompletedBy AS UserName, JournalType, JournalStatus, CAST(NULL AS varchar(255)) AS RejectionReason, LegalEntity, JournalTotalAmount FROM ReversalHistory WHERE JournalEntryId IS NOT NULL AND ReversalCompletedDateTime IS NOT NULL
)
SELECT
    JournalEntryId,
    ActivityName,
    EventTime,
    EventEndTime,
    UserName,
    JournalType,
    JournalStatus,
    RejectionReason,
    LegalEntity,
    JournalTotalAmount
FROM EventLog
WHERE JournalEntryId IS NOT NULL
  AND EventTime IS NOT NULL
ORDER BY JournalEntryId, EventTime, ActivityName;

始める準備はできていますか？

このテンプレートを使えば、決算・レポーティングの仕訳プロセスの改善に取り組むために必要な情報がそろいます。データを使って業務効率を高め、財務報告のサイクルを短縮しましょう。

改善ガイドに戻る

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

Dynamics 365の仕訳プロセスを改善し、報告を迅速化

ボトルネックを解消し、決算・レポーティングの仕訳プロセスのサイクルタイムを30％短縮します。

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

クレジットカードは不要です。数分で始められます。

決算・レポーティング：仕訳のデータテンプレート

決算・レポーティング：仕訳のデータテンプレート

決算・レポーティングの仕訳プロセスの属性

決算・レポーティングの仕訳プロセスのアクティビティ

データ抽出ガイド

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

ステップ

設定

クエリの例 sql

Synapseを使ったDynamics 365のAzure Data Lakeクエリ

ステップ

設定

クエリの例 sql

Dynamics 365 OData APIを使ったPythonスクリプトによる抽出

ステップ

設定

クエリの例 python

Dynamics 365からPower Platform Dataflowsでデータを抽出する

ステップ

設定

クエリの例 sql

始める準備はできていますか？

Dynamics 365の仕訳プロセスを改善し、報告を迅速化