> 継続的なプロセス改善 > Record to Report 期間締め処理と照合 > Workiva > データテンプレート

決算報告 - 期末決算・照合データテンプレート

Workiva

Record to Report - 期間締め処理と照合属性 (19) Record to Report - 期間締め処理と照合アクティビティ (14) 抽出ガイド (3)

決算報告 - 期末決算・照合データテンプレート

このテンプレートは、Record to Report - 期間締め処理および照合プロセスを分析するために必要な不可欠なデータを収集するための明確なロードマップを提供します。収集すべき重要な属性、追跡すべき主要なアクティビティ、およびWorkivaからこの情報を抽出するための実践的なガイダンスを概説しています。このリソースを活用して、データが洞察に富むプロセス分析と最適化の準備ができていることを確認してください。

収集を推奨する項目
追跡すべき主要アクティビティ
Workiva向けデータ抽出ガイド

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

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

Record to Report - 期間締め処理と照合属性

これらは、Record to Report - 期間締め処理および照合プロセスの包括的な分析のために、イベントログに含めることを推奨するデータフィールドです。

5 必須 6 推奨 8 任意

	名前	説明
	アクティビティ名 ActivityName	期間締め処理内で発生した特定のタスクまたはイベントの名前。
説明アクティビティ名には、「ソースデータインポート済み」や「照合レビュー提出済み」など、Record to Reportワークフローのステップが記述されます。これらのアクティビティはプロセスマップの構成要素であり、イベントの順序を示すためにタイムスタンプが付与されます。\n\nアクティビティの分析はプロセスマイニングの基本です。これにより、プロセスフローを可視化し、タスクの順序を特定し、標準手順からの逸脱を発見し、各ステップの頻度と期間を測定するのに役立ちます。これは、ボトルネック、手戻りループ、および自動化の機会を特定するために不可欠です。その重要性この属性はプロセスマップの核を形成し、締め処理サイクルにおけるステップの順序の可視化と分析を可能にします。取得元これは通常、Workiva内の監査証跡、タスク管理、またはワークフローログに、特定の締め処理または照合タスクに関連付けられて記録されます。例期末決算開始照合レビュー提出済み修正仕訳記帳財務諸表作成済み
	イベントのタイムスタンプ EventTimestamp	特定のアクティビティまたはイベントが記録された正確な日時。
説明イベントタイムスタンプは、アクティビティが発生した時点を示します。イベントを正しく順序付け、その間の期間を計算するために不可欠です。完全なイベントログには、「期間締め処理開始」から「期間締め処理完了」までのすべてのアクティビティにタイムスタンプが付与されます。\n\nこのタイムスタンプは、プロセスマイニングにおけるすべての時間ベース分析の基盤です。「期間締め処理エンドツーエンドサイクルタイム」や「照合ボトルネック分析」などのダッシュボードで重要なサイクルタイム、待機時間、処理時間を計算するために使用されます。正確なタイムスタンプは、有意義なプロセス分析のために不可欠です。その重要性イベントを時系列で整理することで、サイクルタイムなどの時間指標の算出や、プロセスの遅延箇所の特定が可能になります。取得元 Workiva内のイベントログ、監査証跡、または取引記録にあり、タスクの作成または完了時刻に対応します。例 2024-04-01T09:00:00Z2024-04-05T14:32:15Z2024-04-10T11:05:00Z
	会計期間 FinancialPeriod	月次や四半期など、特定の財務報告サイクルの一意の識別子。これは、期間末締め処理のケースとして機能します。
説明財務期間は、特定の期間における帳簿締めに関連するすべてのアクティビティをグループ化する主要なケース識別子です。例えば、「2024-Q1」や「2024-03」が単一のケースを表します。\n\nプロセスマイニングでは、財務期間ごとに分析することで、Record to Reportサイクル全体を包括的に把握できます。これにより、異なる期間の締め処理を比較し、傾向を特定し、サイクルタイムの改善を測定し、繰り返し発生するボトルネックを特定することが可能になります。各期間をケースとして扱うことで、組織は時間の経過とともにプロセスバリアントと標準手順への適合性を分析できます。その重要性それは分析の枠組みとなる不可欠なケース識別子であり、各期末決算サイクルをエンドツーエンドで測定および比較することを可能にします。取得元これは通常、Workivaの財務報告または締め管理モジュール内の報告期間コンテキストから導出されます。具体的なフィールド名についてはWorkivaのドキュメントを参照してください。例 2024-032024-Q1FY2023-P122024年4月
	ソースシステム SourceSystem	イベントデータの元のソースシステム。
説明この属性は、データを生成したアプリケーションまたはプラットフォームを識別します。この分析では主に「Workiva」となりますが、ERPなどの他のシステムからインポートされたデータを区別するためにも使用できます。\n\nマルチシステム環境では、ソースシステムを知ることがデータの系譜を理解し、データ品質を評価する上で重要です。データの不整合が発見された際の根本原因分析に役立ち、アクティビティがどのように実行されたかについてのコンテキストを提供します。その重要性データ起源に関する重要なコンテキストを提供し、データ検証やプロセスの技術的ランドスケープを理解するために重要です。取得元この値は通常、データ抽出および変換プロセス中に、レコードの出所をラベル付けするために設定されます。例 Workiva`SAP S/4HANA``Oracle NetSuite`
	最終データ更新 LastDataUpdate	プロセスのデータが最後に更新された日時を示すタイムスタンプ。
説明この属性は、データセットがソースシステムから最後に更新された日時を記録します。これは、各更新時にデータセット全体に適用されるメタデータフィールドです。\n\nダッシュボードに最終データ更新のタイムスタンプを表示することは、ユーザーが分析しているデータの鮮度を知らせるベストプラクティスです。これにより、洞察の最新性に関する期待を管理し、運用監視にとって不可欠です。その重要性データの適時性についてユーザーに通知し、分析のコンテキストと情報の最終更新日時を理解できるようにします。取得元これは、データ抽出時にデータパイプラインまたはETLツールによって生成され、保存されます。例 2024-05-10T08:00:00Z2024-05-09T08:00:00Z
	GL勘定 GLAccount	照合または調整対象の総勘定元帳勘定番号。
説明この属性は、照合または仕訳に関わるGL勘定科目を指定します。これにより、締め処理を分析するための詳細なレベルの粒度を提供します。\n\nGL勘定科目による分析は、「照合ボトルネック分析」および「照合ステータスと経過日数」ダッシュボードにとって不可欠です。どの特定の勘定科目が最も問題であり、照合に最も時間がかかったり、最も多くの調整を必要としたりするかを特定するのに役立ちます。この洞察により、チームは、複雑な勘定科目やデータ品質が低い勘定科目など、最も影響の大きい領域に改善努力を集中させることができます。その重要性勘定調整のパフォーマンスを詳細に把握でき、遅延の原因となったり頻繁な調整が必要な問題のある勘定科目を特定するのに役立ちます。取得元これは、Workiva内の照合または仕訳データにおける主要なフィールドとなります。例 11010012105003410000012300-001
	会社コード CompanyCode	財務決算が実行されている法人の一意の識別子。
説明会社コードは、組織内の特定の法人を表します。財務締め処理は通常、連結前に各会社コードで個別に実行されます。\n\nこの属性は、異なる法人間のプロセスをフィルタリングおよび比較するために重要です。特定の会社に分析を掘り下げて表示することで、「照合ステータスと経過日数」ダッシュボードをサポートします。特定のエンティティが常に遅延に直面したり、調整率が高かったりする場合を特定するのに役立ち、エンティティ固有のプロセスまたはデータの問題を示唆します。その重要性組織内の異なる法人間の決算プロセスの効率性とコンプライアンスの比較を可能にします。取得元 Workiva内の財務データ、勘定、取引に関連し、おそらくソースのERPシステムから継承されたものです。例 1000US01DE015400
	担当ユーザー ResponsibleUser	アクティビティを実行した、または割り当てられたユーザーIDまたは担当者名。
説明この属性は、期間締め処理における特定のタスクを担当する個人（照合を作成した人、またはそれを承認した管理者など）を識別します。これは、ワークロードとパフォーマンスを分析するために不可欠です。\n\n責任者は、「期間締め処理ワークロード配分」ダッシュボードにとって重要です。これにより、管理者はタスクがチームメンバー間でどのように配分されているかを理解し、潜在的な燃え尽き症候群のリスクを特定し、バランスの取れたリソース配分を確保できます。また、特定のユーザーが常に手戻りループやプロセス逸脱に関与している場合に、トレーニングの必要性を特定するためにも使用できます。その重要性これにより、ワークロードの配分、ユーザーのパフォーマンス、リソースの割り当てを分析でき、チームの効率性を管理する上で重要です。取得元通常、Workivaのタスク管理またはワークフローログに見られ、「担当者」、「所有者」、または「完了者」としてラベル付けされています。例 j.doeasmithRobert.Paulsonuser123
	照合カテゴリ ReconciliationCategory	照合対象となる勘定科目のカテゴリまたは種類（例：銀行口座、会社間）。
説明この属性は、GL勘定科目を論理的なカテゴリにグループ化し、より高レベルの分析を可能にします。例として「現金」、「固定資産」、「未払費用」、「会社間」などがあります。この分類は、異なる種類の照合におけるプロセスパフォーマンスを理解するのに役立ちます。\n\n「照合ボトルネック分析」では、照合カテゴリによるフィルタリングが重要です。これにより、例えば会社間照合が常に銀行照合よりも時間がかかる場合など、遅延が特定の領域に集中しているかどうかを判断できます。この洞察は、各カテゴリの特定の課題に合わせたターゲットプロセス改善を導きます。その重要性異なる種類の勘定科目間での勘定調整パフォーマンスの集計と比較を可能にし、カテゴリ固有のボトルネックを明らかにします。取得元これは、勘定科目表マスターデータの一部である可能性があり、Workivaで管理されているか、ERPから継承されている可能性があります。例銀行勘定会社間取引固定資産未払金計上前払費用
	照合ステータス ReconciliationStatus	勘定科目照合の現在のステータス。
説明この属性は、照合がワークフロー内で進行する際のステータス（例：「未処理」、「進行中」、「承認待ち」、「承認済み」）を追跡します。これにより、照合アクティビティの現在の進捗状況のスナップショットを提供します。\n\nこれは「照合ステータスと経過日数」ダッシュボードの主要な属性です。これにより、管理者は未処理および進行中の項目を監視し、停滞している照合を特定し、期限が確実に守られるように作業を優先順位付けできます。時間の経過に伴うステータス変更を追跡することは、項目が次の状態に移行する前に長期間待機するボトルネックを特定するのにも役立ちます。その重要性勘定調整の進捗状況をリアルタイムでモニタリングし、停滞している項目を特定して対処することで、決算を軌道に乗せるのに役立ちます。取得元これは、Workivaの照合または締め管理モジュール内のコア属性です。例オープン作成済みレビューのために提出済み承認済み却下
	部署 Department	その活動を担当する部門または機能チーム。
説明この属性は、「経理部」や「内部監査部」など、ユーザーまたはアクティビティ自体に関連するビジネスユニットまたは部門を示します。これにより、プロセスデータのより高レベルな集計が可能になります。\n\n部門別にプロセスを分析することは、「期間締め処理ワークロード配分」ダッシュボードや組織内の異なる部門間でのプロセスパフォーマンス比較に不可欠です。これにより、部門内のシステム的な問題を特定し、チーム間の効率性を比較し、部門間の引き継ぎが全体的なサイクルタイムにどのように影響するかを理解するのに役立ちます。その重要性事業分野別にプロセス分析をセグメント化することができ、パフォーマンスの比較や部門固有の問題の特定に役立ちます。取得元この情報は、Workivaのユーザープロフィールの一部として、またはタスクのメタデータに関連付けられて保存される場合があります。例北米法人会計EMEAシェアードサービス内部監査FP&A
	アクティビティ所要時間 ActivityDuration	アクティビティの開始から終了までの経過時間。
説明これは、単一のアクティビティの処理時間を測定する計算メトリクスです。通常、後続のアクティビティの開始タイムスタンプから、そのアクティビティの開始タイムスタンプを差し引くことによって導出されます。\n\nアクティビティ期間は、プロセスマイニングにおける基本的なメトリクスであり、「照合ボトルネック分析」および「レビュー・承認サイクルタイム」ダッシュボードで直接使用されます。これにより、プロセス内のどの特定のステップが最も時間を消費しているかを特定し、集中的な最適化努力を可能にします。これは、平均サイクルタイムを含む多くのKPIを計算するための基礎となります。その重要性個々のステップの処理時間を定量化し、最も時間のかかる活動やボトルネックを特定・分析することを可能にします。取得元これはソースシステムフィールドではありません。イベントタイムスタンプを使用して、プロセスマイニングのデータ変換中に計算されます。例 P1DT2H30MPT5HP3D
	仕訳伝票ID JournalEntryId	調整仕訳の一意の識別子。
説明この属性は、締め処理中に転記された各仕訳、特に照合後に作成された調整仕訳に対して一意のIDを提供します。これにより、特定の調整をそのソースアクティビティにまで遡って追跡できます。\n\n仕訳IDの追跡は、「照合後調整トレンド」ダッシュボードにとって重要です。これにより、手作業による調整の量を定量化し、プロセス後半で行われた特定の仕訳を調査する方法を提供します。この追跡可能性は、調整の根本原因を理解し、初期データ品質を向上させる鍵となります。その重要性各財務調整の一意の参照を提供し、手動入力の量、タイミング、および理由の詳細な分析を可能にします。取得元これは、WorkivaまたはソースERP内の仕訳データにおける主要なフィールドとなります。例 JE202404-00123ADJ-593029100004567
	却下理由 RejectionReason	レビュー中に照合または財務諸表が却下された際に提供される理由。
説明項目が却下された場合、レビュアーは通常、理由を提供します。この属性は、「不正確な証拠書類」や「計算エラー」など、項目が承認基準を満たさなかった理由を説明するそのテキストまたはコードを捕捉します。\n\n却下理由を分析することは、エラーや手戻りの一般的な原因を特定するのに役立ちます。これらの理由を分類し、数を数えることで、経営陣はプロセス改善、作成者へのより良いトレーニング、またはより明確な指示が必要な領域を特定できます。このデータは、手戻りループを削減し、初回承認率を向上させる上で貴重です。その重要性手戻りや品質問題の根本原因を直接洞察でき、ターゲットを絞ったトレーニングやプロセス改善活動を導きます。取得元この情報は、ユーザーがWorkivaワークフローで「却下」アクションを実行した際に、コメントフィールドまたは事前定義されたリストに記録される可能性が高いです。例証拠書類の欠如計算エラー期間の誤りポリシー違反
	承認後調整 IsPostApprovalAdjustment	対応する勘定調整が承認された後に修正仕訳が記帳された場合にtrueとなる計算フラグ。
説明このブールフラグは、イベントの順序を分析することによって導出されます。特定の勘定科目と財務期間において、「調整仕訳が転記された」アクティビティが「照合レビュー・承認済み」アクティビティの後に発生した場合、このフラグはtrueに設定されます。それ以外の場合はfalseです。\n\nこの属性は、「照合後調整トレンド」ダッシュボードおよび「照合後調整率」KPIにとって極めて重要です。これらのイベントの数が多いことは、コントロールの欠如、上流システムからのデータ品質の低下、またはプロセスの破綻を示しており、大幅な手戻りを発生させ、コンプライアンスリスクを高めます。その重要性承認後に行われたリスクの高い調整を具体的に特定し、プロセス管理とデータ品質の問題を測定するのに役立ちます。取得元これはソースフィールドではありません。関連するアクティビティのタイムスタンプを比較することで、プロセスマイニングツール内のロジックを使用して導出されます。例 truefalse
	期末決算サイクルタイム PeriodCloseCycleTime	単一の会計期間における期間締め処理の開始から完了までの合計時間。
説明この算出メトリクスは、期間締め処理ケース全体の「エンドツーエンドの期間」を表します。これは、特定の財務期間における最初のアクティビティ（「期間締め処理開始」）と最後のアクティビティ（「期間締め処理完了」）の時間差として計算されます。\n\nこの属性は、「期間締め処理エンドツーエンドサイクルタイム」ダッシュボードおよび対応するKPIの主要な指標です。これを経時的に追跡することで、経営陣はプロセス改善の影響を確認し、異なる事業部門や期間における締め処理効率を比較できます。これは、プロセスパフォーマンスの最も重要な高レベル指標の1つです。その重要性これは、期間締め処理全体を最初から最後まで測定する、全体的な効率性と速度を測る主要業績評価指標（KPI）です。取得元これは、プロセスマイニングツールでケースレベルで計算され、各ケースの最も早い開始時刻から最も遅い終了時刻を差し引くことによって求められます。例 P10DT5HP8DT12HP12D
	目標完了日 TargetCompletionDate	期間締め処理を完了するための計画または期限日。
説明目標完了日は、期間締め処理を完了しなければならない内部または外部の期限です。これは、実際のパフォーマンスを測定するためのベンチマークとして機能します。\n\nこの日付は、「期間締め処理期日内完了率」KPIを計算するために不可欠です。「期間締め処理完了」アクティビティの実際の完了タイムスタンプをこの目標日付と比較することで、締め処理が期限内か、早期か、遅延かを判断できます。これは、プロセスの信頼性と財務報告のタイムラインへの遵守を測る上で重要な尺度です。その重要性定時達成パフォーマンスを測定するためのベースラインとして機能し、決算プロセスの信頼性と予測可能性を示す重要な指標となります。取得元この日付は、Workivaの締め管理または計画モジュール内で、各財務期間に対して設定されている可能性が高いです。例 2024-04-102024-01-152023-10-12
	自動化 IsAutomated	そのアクティビティが自動システムによって実行されたか、人間によって実行されたかを示すフラグ。
説明このブール属性は、データインポートやシステム生成レポートなど、システムによって自動的に実行されるタスクと、ユーザーが手動で実行するタスクを区別します。 \n\nこの属性は、自動化を増やす機会を特定するために重要です。手動タスクと自動タスクの比率およびそれらに関連する処理時間を分析することで、組織は反復的で時間のかかるステップを自動化するためのビジネスケースを構築できます。また、人間主導のアクティビティとシステム主導のアクティビティの効率を正確に測定するのにも役立ちます。その重要性人間とシステムの活動を区別し、これは自動化の機会を特定し、既存の自動化の影響を測定するための鍵となります。取得元これは、アクティビティに関連付けられたユーザーID（例：「system」または「bot」ユーザー）またはアクティビティタイプ自体の特定のフラグから導出できます。例 truefalse
	調整金額 AdjustmentAmount	調整仕訳の金額。
説明この属性は、調整の金額を記録します。これは、締め処理中に行われる変更の重要性を理解するために使用できます。\n\n調整金額の分析は、照合後調整の調査を優先順位付けするのに役立ちます。高額な調整は、基礎となるデータやプロセスに重大な問題がある可能性を示しており、早急な注意が必要です。この属性は、純粋な数量ベースではなく、金額ベースでの調整分析を可能にすることで、「手動調整比率」KPIをサポートします。その重要性調整による財務的影響を定量化するのに役立ち、チームが重要性に基づいて調査の優先順位を付けることを可能にします。取得元これは、Workivaまたは接続されたERP内の仕訳データテーブルにおける標準フィールドとなります。例 15250.75-500.00120000.00

必須推奨任意

Record to Report - 期間締め処理と照合アクティビティ

これらは、財務締め処理の正確な発見と最適化のために、イベントログに記録すべき主要なプロセスステップとマイルストーンです。

7 推奨 7 任意

	アクティビティ	説明
	修正仕訳記帳	照合プロセス中に発見された事柄に基づいて修正仕訳を作成し、転記するアクションを表します。Workivaは仕訳とそのステータスを追跡できます。
その重要性このアクティビティは、「照合後の調整率」KPIにとって重要です。照合承認後に大量の調整が行われる場合、ソースデータの品質やプロセス管理に問題がある可能性があります。取得元これは、Workivaの仕訳モジュールで作成タイムスタンプと転記済みを示すステータスとともに捕捉される明示的なイベントである可能性が高いです。取得仕訳のステータスが「転記済み」に設定されたときのタイムスタンプを使用します。イベントタイプ explicit
	期末決算完了	このアクティビティは、財務期間のRecord to Reportプロセス全体の正式な完了を示します。Workivaプロセスワークフローにおける最終ステップです。
その重要性これはプロセスの主要な終了イベントです。これにより、期間締め処理のエンドツーエンドサイクルタイム合計と期間締め処理期日内完了率を正確に測定できます。取得元 Workivaにおける親となる期末決算プロセス、チェックリスト、またはワークフローの完了タイムスタンプから推測されます。手動によるステータス変更である可能性もあります。取得親プロセスの完了タイムスタンプ、または締め処理チェックリスト内の最終タスクの完了タイムスタンプを使用します。イベントタイプ inferred
	期末決算開始	このアクティビティは、特定の期間の財務締め処理の正式な開始を示します。通常、ユーザーがWorkiva内で期間締め処理チェックリストまたはプロセスワークフローを作成または開始したときにトリガーされます。
その重要性これはエンドツーエンドプロセスの主要な開始イベントです。これにより、期間締め処理のエンドツーエンドサイクルタイム合計を正確に測定し、プロセスがいつ正式に開始されるかを特定できます。取得元このイベントは、特定の財務期間におけるWorkivaの主要な期間締め処理プロセスオブジェクト、タスクリスト、またはワークフローの作成タイムスタンプから推測される可能性が高いです。取得財務期間の親プロセスまたはチェックリストの作成タイムスタンプを使用します。イベントタイプ inferred
	照合レビュー・承認済み	管理者またはレビュー担当者が作成された勘定調整を正式に承認し、その正確性を確認する重要な節目です。これは通常、タスクが「承認済み」または「完了」ステータスに移行したときに捕捉されます。
その重要性このアクティビティは、平均照合サイクルタイムと平均レビュー・承認サイクルタイムの計算に不可欠です。プロセス内の品質チェックの完了を確認します。取得元これは、照合タスクのステータス変更またはWorkiva内のタスクの監査証跡における明示的な承認イベントから推測される可能性が高いです。取得ステータスが「承認済み」または「認定済み」に変更されたときのタイムスタンプを捕捉します。イベントタイプ inferred
	試算表作成済み	このマイルストーンは、試算表が最終と見なされ、財務諸表の生成に使用できる準備が整った時点を示します。これは、特定のタスクが完了したとき、またはレポートが生成されたときに推測される場合があります。
その重要性これは、財務諸表生成のための重要な前提条件です。この時点からの時間を測定することで、最終報告段階の効率性を分析するのに役立ちます。取得元これは、Workivaチェックリスト内の「試算表最終化」タスクの完了、または最終試算表レポートの生成タイムスタンプから推測される可能性が高いです。取得「試算表作成」タスク完了または最終試算表レポート生成のタイムスタンプ。イベントタイプ inferred
	財務諸表作成済み	貸借対照表、損益計算書、キャッシュフロー計算書などの財務諸表のドラフト作成を表します。これは、Workivaでレポートドキュメントが生成されたときに記録されます。
その重要性このアクティビティのタイミングは、「財務諸表生成遅延時間」KPIにとって極めて重要です。データの集計から最終レポート作成への移行を示します。取得元これは、その期間のWorkivaプラットフォーム内の財務諸表ドキュメントまたはレポートの作成または最終主要更新のタイムスタンプから推測できます。取得主要な財務諸表ドキュメントの作成または「最終更新」タイムスタンプを使用します。イベントタイプ inferred
	財務諸表承認済み	財務諸表に対する経営陣または監査委員会の最終承認。これは、期間が正式に締められる前の最後の主要な承認を意味します。
その重要性これは、レポートが最終化されたことを示す重要なマイルストーンです。財務諸表自体の平均レビュー・承認サイクルタイムを測定するために不可欠です。取得元 Workivaにおける主要な報告書またはタスクでの電子署名、認定プロセス、または「承認済み」への最終ステータス変更を通じて捕捉される可能性が高いです。取得財務諸表の最終承認ステータス変更または認証イベントのタイムスタンプ。イベントタイプ inferred
	ソースデータインポート済み	ソースERPシステムからWorkivaプラットフォームへのデータロードの完了を表します。これには、試算表データ、取引明細、および照合に必要なその他の補助スケジュールが含まれる場合があります。
その重要性データの可用性における遅延は一般的なボトルネックです。この活動を追跡することで、データ統合の問題を、その後の勘定調整や報告作業から切り離して特定するのに役立ちます。取得元これは、Workivaのデータ統合ログまたは監査証跡における明示的なイベントである可能性があります。また、照合タスクが開始される前の期間の最終データ更新のタイムスタンプから推測することもできます。取得期間のデータインポートまたはERP接続更新が正常に完了したタイムスタンプ。イベントタイプ inferred
	会社間照合開始	特定の、そしてしばしば複雑な会社間取引の照合プロセスの開始を示します。これは、会社間照合モジュールまたは特定のタスクが開始されたときに捕捉されます。
その重要性会社間照合は頻繁な遅延の原因となります。この活動を分離することで、その特定の期間を測定し、これらの取引に固有のボトルネックを特定するのに役立ちます。取得元これは、Workivaプロセスワークフロー内の会社間勘定科目向けに特別に指定されたタスクのステータス変更から推測できます。取得「会社間」と分類されたタスクが「進行中」ステータスに移行した際のタイムスタンプ。イベントタイプ inferred
	会計期間再開	以前に締められた期間を再開し、遅れて修正仕訳を記帳したり、修正を行ったりする例外的な活動です。これは、「クローズ済み」からアクティブなステータスへの変更によって捕捉されます。
その重要性これは重大なプロセス例外と手戻りを示します。その頻度を追跡することで、プロセス管理と最終性に関する根本的な問題を特定するのに役立ちます。取得元これは、親となる期間締め処理プロセスオブジェクトのステータス変更から推測され、完了またはクローズされたステータスからオープンまたは進行中のステータスに戻る動きを示します。取得期間オブジェクトのステータスが「クローズ済み」から「オープン」に変更されたことを検出します。イベントタイプ inferred
	勘定調整開始	このアクティビティは、作成者が特定の勘定科目照合の作業を開始したことを示します。これは通常、ユーザーがWorkivaプロセス内で照合タスクを最初に開くか、引き受けたときに記録されます。
その重要性照合作業の開始を追跡することは、作成者のサイクルタイムを測定し、タスクの割り当てから実際の作業開始までの遅延を特定するために不可欠です。取得元 Workivaのチェックリストまたはワークフロー内で、勘定調整タスクのステータスが「未開始」から「進行中」または類似のステータスに最初に変更されたタイムスタンプから推測されます。取得勘定調整タスクのステータスが「進行中」のようなアクティブな状態に変わった最初のタイムスタンプを検出します。イベントタイプ inferred
	照合レビュー提出済み	このイベントは、作成者が照合作業を完了し、正式に承認のために提出する際に発生します。Workivaでは、これはしばしばタスクのステータス変更（例：「レビュー待ち」への移行）によって表されます。
その重要性これは作成者からレビュアーへの引き渡しを示し、レビューキュー時間の測定を可能にします。レビューおよび承認ワークフローの効率を分析するための重要なマイルストーンです。取得元勘定調整タスクのステータスが「進行中」から「レビュー保留中」または「提出済み」の状態に変わったタイムスタンプから推測されます。取得ステータスが「レビュー保留中」またはそれに相当する状態に変更されたときのタイムスタンプを捕捉します。イベントタイプ inferred
	照合却下	レビュー担当者が提出された勘定調整に問題を発見し、修正のために作成者に差し戻す際に発生します。これは、「却下済み」または「手戻りが必要」へのステータス変更によって捕捉されます。
その重要性却下を追跡することは、手戻りループの特定、初回正確率の測定、および繰り返しの品質問題がある勘定科目や作成者の特定に不可欠です。取得元勘定調整タスクのステータスが「却下済み」、「差し戻し」、または手戻りが必要であることを示す類似のステータスに変更されたタイムスタンプから推測されます。取得ステータスが「却下済み」またはそれに相当する状態に変更されたときのタイムスタンプを捕捉します。イベントタイプ inferred
	財務諸表レビュー済み	このアクティビティは、ユーザーまたはユーザーグループが生成された財務諸表の正確性と完全性をレビューする際に発生します。これは、レビュータスクのステータス更新によって捕捉される場合があります。
その重要性レビューサイクルを追跡することは、最終承認段階での遅延を理解する上で重要です。ここでの長期間は、全体の締め処理期間に大きな影響を与える可能性があります。取得元これは、Workivaプロセスにおけるレビュータスクのステータス変更、つまり「レビュー待ち」から「レビュー完了」や「承認済み」のような状態への移行から推測できます。取得財務諸表のレビューサイクルが完了したことを示すステータス変更のタイムスタンプ。イベントタイプ inferred

推奨任意

抽出ガイド

Workivaからデータを取得する方法

ステップ

Workivaインスタンスにログインし、メインアプリケーションスイッチャーからプロセスセクションに移動します。
プロセスダッシュボードで、レポートタブをクリックし、レポートインターフェースにアクセスします。
作成ボタンをクリックし、プロセスレポートを選択して新しいレポートの作成を開始します。
レポート設定で、利用可能なプロセスリストから分析したい特定の期末決算プロセスを選択します。例えば、「2023年第3四半期決算」を選択します。
レポートビルダーの列またはデータセクションに移動します。イベントログに必要なデータを提供する列を追加します。タスク名、ステータス、最終ステータス変更日、担当ユーザー、完了ユーザー、および貴社がCompany Code、GL Account、Departmentに利用するカスタムメタデータフィールドなどを含める必要があります。
レポートのフィルターを設定します。分析したい会計期間をカバーする日付範囲（通常は少なくとも3〜6ヶ月）を設定します。特定の会社コードやプロセスタイプなど、その他の関連フィルターも追加します。
レポートを実行してデータのプレビューを生成します。列と行が期待どおりに表示されることを確認します。
プレビューが確認されたら、レポートをエクスポートします。エクスポート形式としてCSVを選択します。ファイルをローカルマシンにダウンロードします。
エクスポートしたCSVファイルをスプレッドシートアプリケーションで開きます。データは、タスクの現在の状態ごと、またはステータス変更ごとに1行として構造化されている可能性があります。このデータを有効なイベントログ形式に変換する必要があります。
ActivityName、EventTimestamp、FinancialPeriodの新しい列を作成します。Workivaエクスポートからのデータをこれらの列にマッピングします。例えば、「現金勘定調整」というタスクが「レビューのために提出済み」のステータスにある場合、それはReconciliation Submitted for Reviewアクティビティとなります。「最終ステータス変更日」はEventTimestampとなります。
レポート内のタスク名とステータス変更に基づいて、必須の14アクティビティそれぞれについて個別の行を作成する必要があります。これには、単一タスクの履歴から複数の行を作成することが必要になる場合があります。
完全に変換されたファイルをCSVとして保存します。最終的な列ヘッダーが、プロセスマイニングツールへのアップロードに必要な属性と一致していることを確認してください。

設定

プロセス選択：分析したいタスクを含む、「月次決算チェックリスト」や「四半期報告プロセス」のような特定の財務決算プロセスを選択する必要があります。
レポートタイプ：ステータス変更履歴を含む「プロセス監査証跡」や「タスク詳細レポート」のように、過去のタスクデータを提供するレポートタイプを選択してください。単純なサマリーレポートでは不十分です。
日付範囲：意味のある分析のためには、少なくとも3〜6会計期間のデータを抽出するようにレポートを設定してください。これにより、サイクルを比較し、傾向を特定できます。
レポート列：イベントの詳細を捕捉する列を含めることが非常に重要です。タスク名、タスクステータス、開始日、期日、完了日、担当ユーザー、完了ユーザー、および最終ステータス変更のタイムスタンプの各フィールドを必ず追加してください。また、CompanyCode、Department、またはGLAccountにマッピングされるカスタムフィールドもすべて含めてください。
フィルター：抽出範囲を絞り込むためにフィルターを使用します。エクスポートサイズを管理し、関連データに集中するために、特定のFinancialPeriod名、CompanyCode、またはタスクステータスの範囲でフィルターをかけることができます。
前提条件：抽出を実行するユーザーは、レポート対象の特定のプロセスについてWorkiva内で少なくとも読み取りアクセス権限を持つとともに、レポートを作成および実行する権限が必要です。

a クエリ例 config

// Workiva Process Report Configuration
// This is not an executable script, but a representation of the settings to be configured in the Workiva UI.

ReportType: "Process Task Detail" or "Process Audit Trail"

// Select the primary process to report on
ProcessFilter: "[Your Period Close Process Name]"

// Define the time frame for the data export
DateRange: {
  StartDate: "[YYYY-MM-DD]",
  EndDate: "[YYYY-MM-DD]"
}

// Columns to include in the exported report
// These fields will be mapped to the event log attributes during data transformation
Columns: [
  "Process Name",         // Maps to FinancialPeriod
  "Task Name",            // Used to derive ActivityName
  "Current Status",       // Used to derive ActivityName
  "Status Change Date",   // Maps to EventTimestamp
  "Assigned To User",     // Maps to ResponsibleUser
  "Completed By User",    // Maps to ResponsibleUser
  "Start Date",           // Potential timestamp for 'Started' activities
  "Completion Date",      // Potential timestamp for 'Completed' activities

  // Add custom metadata fields configured in your Workiva process
  "[Custom Field for Company Code]", // Maps to CompanyCode
  "[Custom Field for Department]",   // Maps to Department
  "[Custom Field for GL Account]",   // Maps to GLAccount
  "[Custom Field for Reconciliation Category]" // Maps to ReconciliationCategory
]

// Filters to apply to the dataset
Filters: {
  // Add any specific filters if needed, for example, by company code
  "[Custom Field for Company Code]": "[Filter by specific company codes]"
}

// Export Format
Format: "CSV"

ステップ

Workivaインスタンスにログインし、メインアプリケーションスイッチャーからプロセスセクションに移動します。
プロセスダッシュボードで、レポートタブをクリックし、レポートインターフェースにアクセスします。
作成ボタンをクリックし、プロセスレポートを選択して新しいレポートの作成を開始します。
レポート設定で、利用可能なプロセスリストから分析したい特定の期末決算プロセスを選択します。例えば、「2023年第3四半期決算」を選択します。
レポートビルダーの列またはデータセクションに移動します。イベントログに必要なデータを提供する列を追加します。タスク名、ステータス、最終ステータス変更日、担当ユーザー、完了ユーザー、および貴社がCompany Code、GL Account、Departmentに利用するカスタムメタデータフィールドなどを含める必要があります。
レポートのフィルターを設定します。分析したい会計期間をカバーする日付範囲（通常は少なくとも3〜6ヶ月）を設定します。特定の会社コードやプロセスタイプなど、その他の関連フィルターも追加します。
レポートを実行してデータのプレビューを生成します。列と行が期待どおりに表示されることを確認します。
プレビューが確認されたら、レポートをエクスポートします。エクスポート形式としてCSVを選択します。ファイルをローカルマシンにダウンロードします。
エクスポートしたCSVファイルをスプレッドシートアプリケーションで開きます。データは、タスクの現在の状態ごと、またはステータス変更ごとに1行として構造化されている可能性があります。このデータを有効なイベントログ形式に変換する必要があります。
ActivityName、EventTimestamp、FinancialPeriodの新しい列を作成します。Workivaエクスポートからのデータをこれらの列にマッピングします。例えば、「現金勘定調整」というタスクが「レビューのために提出済み」のステータスにある場合、それはReconciliation Submitted for Reviewアクティビティとなります。「最終ステータス変更日」はEventTimestampとなります。
レポート内のタスク名とステータス変更に基づいて、必須の14アクティビティそれぞれについて個別の行を作成する必要があります。これには、単一タスクの履歴から複数の行を作成することが必要になる場合があります。
完全に変換されたファイルをCSVとして保存します。最終的な列ヘッダーが、プロセスマイニングツールへのアップロードに必要な属性と一致していることを確認してください。

設定

プロセス選択：分析したいタスクを含む、「月次決算チェックリスト」や「四半期報告プロセス」のような特定の財務決算プロセスを選択する必要があります。
レポートタイプ：ステータス変更履歴を含む「プロセス監査証跡」や「タスク詳細レポート」のように、過去のタスクデータを提供するレポートタイプを選択してください。単純なサマリーレポートでは不十分です。
日付範囲：意味のある分析のためには、少なくとも3〜6会計期間のデータを抽出するようにレポートを設定してください。これにより、サイクルを比較し、傾向を特定できます。
レポート列：イベントの詳細を捕捉する列を含めることが非常に重要です。タスク名、タスクステータス、開始日、期日、完了日、担当ユーザー、完了ユーザー、および最終ステータス変更のタイムスタンプの各フィールドを必ず追加してください。また、CompanyCode、Department、またはGLAccountにマッピングされるカスタムフィールドもすべて含めてください。
フィルター：抽出範囲を絞り込むためにフィルターを使用します。エクスポートサイズを管理し、関連データに集中するために、特定のFinancialPeriod名、CompanyCode、またはタスクステータスの範囲でフィルターをかけることができます。
前提条件：抽出を実行するユーザーは、レポート対象の特定のプロセスについてWorkiva内で少なくとも読み取りアクセス権限を持つとともに、レポートを作成および実行する権限が必要です。

a クエリ例 config

// Workiva Process Report Configuration
// This is not an executable script, but a representation of the settings to be configured in the Workiva UI.

ReportType: "Process Task Detail" or "Process Audit Trail"

// Select the primary process to report on
ProcessFilter: "[Your Period Close Process Name]"

// Define the time frame for the data export
DateRange: {
  StartDate: "[YYYY-MM-DD]",
  EndDate: "[YYYY-MM-DD]"
}

// Columns to include in the exported report
// These fields will be mapped to the event log attributes during data transformation
Columns: [
  "Process Name",         // Maps to FinancialPeriod
  "Task Name",            // Used to derive ActivityName
  "Current Status",       // Used to derive ActivityName
  "Status Change Date",   // Maps to EventTimestamp
  "Assigned To User",     // Maps to ResponsibleUser
  "Completed By User",    // Maps to ResponsibleUser
  "Start Date",           // Potential timestamp for 'Started' activities
  "Completion Date",      // Potential timestamp for 'Completed' activities

  // Add custom metadata fields configured in your Workiva process
  "[Custom Field for Company Code]", // Maps to CompanyCode
  "[Custom Field for Department]",   // Maps to Department
  "[Custom Field for GL Account]",   // Maps to GLAccount
  "[Custom Field for Reconciliation Category]" // Maps to ReconciliationCategory
]

// Filters to apply to the dataset
Filters: {
  // Add any specific filters if needed, for example, by company code
  "[Custom Field for Company Code]": "[Filter by specific company codes]"
}

// Export Format
Format: "CSV"

ステップ

前提条件：WorkivaでAPIクレデンシャルを生成する
- OAuth2 Grant管理権限を持つアカウントでWorkivaにログインします。
- Workiva管理コンソールに移動し、OAuth2 Grantsセクションを選択します。
- 抽出スクリプト用の新しいグラントを作成します。プロセス、タスク、ユーザーデータを読み取るために必要な適切なスコープを選択します。一般的なスコープには、processes:read、tasks:read、users:readが含まれます。
- 生成されたクライアントIDとクライアントシークレットを安全にコピーします。これらはPythonスクリプトによる認証に使用されます。
Python環境をセットアップする
- スクリプトが実行されるマシンにPython 3.6以降がインストールされていることを確認します。
- pipを使用して必要なPythonライブラリをインストールします。主なライブラリは、APIへのHTTPリクエスト用のrequestsと、データ操作およびCSVエクスポート用のpandasです。
- コマンドプロンプトまたはターミナルを開き、以下を実行します：pip install requests pandas
Pythonスクリプトを設定する
- 提供されたPythonスクリプトを、例えばextract_workiva_log.pyというファイルにコピーします。
- スクリプト上部のプレースホルダー値を置き換えます。これには、CLIENT_ID、CLIENT_SECRET、START_DATE、END_DATE、PROCESS_TEMPLATE_IDSが含まれます。
- PROCESS_TEMPLATE_IDSは、分析したい記録から報告まで（R2R）プロセステンプレートの一意の識別子のリストである必要があります。
スクリプトのロジックを理解する
- スクリプトはまず、提供されたクレデンシャルを使用してWorkiva APIで認証し、アクセストークンを取得します。
- 次に、/processesエンドポイントをクエリして、指定された日付範囲内でテンプレートIDに一致するすべてのプロセスインスタンス（各FinancialPeriodケースを表します）を検索します。
- 各プロセスインスタンスについて、スクリプトは/tasksエンドポイントから関連するすべてのタスクを取得します。
- スクリプトはタスクとその履歴またはステータス変更を反復処理し、イベントログの行を生成します。タスク名とステータス更新を、事前定義された14のアクティビティリストにマッピングします。
抽出スクリプトを実行する
- コマンドラインまたはターミナルから以下のコマンドを使用してスクリプトを実行します：python extract_workiva_log.py
- スクリプトはAPIからデータを取得する際に、コンソールに進行状況の更新を表示します。
- 長期間のデータ取得は、APIのページネーションやレート制限により数分かかる場合があるため、お待ちください。
出力データを確認する
- スクリプトが正常に完了すると、同じディレクトリにworkiva_event_log.csvという名前のファイルが生成されます。
- スプレッドシートアプリケーションでCSVファイルを開き、データを確認します。FinancialPeriod、ActivityName、EventTimestamp、SourceSystem、およびLastDataUpdateの各列が正しく入力されていることを確認します。
ProcessMindへのアップロード準備
- 生成されたCSVファイルは、ProcessMindと直接互換性があるように構成されています。通常、それ以上の書式設定は必要ありません。列ヘッダーがProcessMindインスタンスのターゲットデータモデルと一致することを確認してください。

設定

APIクレデンシャル：認証にはクライアントIDとクライアントシークレットが必要です。これらは、プロセスおよびタスクデータの読み取りを許可するスコープを持つWorkiva管理コンソールから生成する必要があります。
プロセステンプレートID：データを抽出したい期末決算プロセステンプレートの一意の識別子を指定する必要があります。これにより、関連するプロセスのみを確実に抽出できます。
日付範囲：スクリプト内のSTART_DATEとEND_DATE変数は、抽出の時間枠を定義します。データ量とAPIコールを管理するために、3〜6か月程度の短い範囲から始めることをお勧めします。
APIエンドポイントURL：スクリプトはWorkivaのv1 APIエンドポイントを使用します。デフォルトと異なる場合は、Workivaインスタンスのリージョンに合わせてこれらが正しいことを確認してください。
ユーザー権限：APIクレデンシャルに関連付けられたユーザーアカウントは、抽出されるプロセスおよびタスクに対する少なくとも読み取り専用アクセス権限が必要です。権限が不足していると、エラーが発生したり、データが不完全になったりします。
環境変数：セキュリティを向上させるため、クライアントIDとクライアントシークレットをスクリプトに直接ハードコードするのではなく、環境変数として保存することを強くお勧めします。

a クエリ例 python

import requests
import pandas as pd
import datetime
import time

class=class="hl-string">"hl-comment"># --- Configuration Settings --- #
class=class="hl-string">"hl-comment"># Replace with your Workiva API credentials
CLIENT_ID = class="hl-string">'YOUR_CLIENT_ID'
CLIENT_SECRET = class="hl-string">'YOUR_CLIENT_SECRET'

class=class="hl-string">"hl-comment"># Define the date range for the extraction
START_DATE = class="hl-string">'YYYY-MM-DD'
END_DATE = class="hl-string">'YYYY-MM-DD'

class=class="hl-string">"hl-comment"># Define the Process Template IDs for your Record to Report processes
PROCESS_TEMPLATE_IDS = [class="hl-string">'YOUR_PROCESS_TEMPLATE_ID_1', class="hl-string">'YOUR_PROCESS_TEMPLATE_ID_2']

class=class="hl-string">"hl-comment"># API Base URL
BASE_URL = class="hl-string">'https://api.workiva.com/v1'

class=class="hl-string">"hl-comment"># --- Function to get an OAuth2 Token --- #
def get_access_token():
    url = fclass="hl-string">'{BASE_URL}/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
    }
    response = requests.post(url, data=payload)
    response.raise_for_status() class=class="hl-string">"hl-comment"># Raises an exception for bad status codes
    return response.json()[class="hl-string">'access_token']

class=class="hl-string">"hl-comment"># --- Function to handle paginated API calls --- #
def get_all_pages(url, headers, params):
    all_items = []
    while url:
        response = requests.get(url, headers=headers, params=params)
        response.raise_for_status()
        data = response.json()
        all_items.extend(data[class="hl-string">'data'])
        url = data.get(class="hl-string">'metadata', {}).get(class="hl-string">'nextPageUrl')
        params = None class=class="hl-string">"hl-comment"># Subsequent requests use the full nextPageUrl
        if url:
            print(fclass="hl-string">'Fetching next page: {url}')
            time.sleep(0.5) class=class="hl-string">"hl-comment"># Be respectful of API rate limits
    return all_items

class=class="hl-string">"hl-comment"># --- Main Extraction Logic --- #
def main():
    print(class="hl-string">'Starting Workiva data extraction...')
    access_token = get_access_token()
    headers = {class="hl-string">'Authorization': fclass="hl-string">'Bearer {access_token}'}
    event_log = []
    last_data_update = datetime.datetime.utcnow().isoformat() + class="hl-string">'Z'

    class=class="hl-string">"hl-comment"># 1. Fetch relevant processes (our cases)
    print(class="hl-string">'Fetching processes...')
    process_params = {
        class="hl-string">'filter[templateId]': class="hl-string">','.join(PROCESS_TEMPLATE_IDS),
        class="hl-string">'filter[created]': fclass="hl-string">'ge({START_DATE});lt({END_DATE})'
    }
    processes = get_all_pages(fclass="hl-string">'{BASE_URL}/processes', headers, process_params)
    print(fclass="hl-string">'Found {len(processes)} processes to analyze.')

    class=class="hl-string">"hl-comment"># 2. Iterate through each process to fetch tasks and create events
    for process in processes:
        financial_period = process.get(class="hl-string">'name', process[class="hl-string">'id'])
        process_id = process[class="hl-string">'id']
        process_owner_id = process.get(class="hl-string">'owner', {}).get(class="hl-string">'id')

        class=class="hl-string">"hl-comment"># Activity: Period Close Initiated
        event_log.append({
            class="hl-string">'FinancialPeriod': financial_period,
            class="hl-string">'ActivityName': class="hl-string">'Period Close Initiated',
            class="hl-string">'EventTimestamp': process[class="hl-string">'created'],
            class="hl-string">'ResponsibleUser': process_owner_id,
            class="hl-string">'CompanyCode': process.get(class="hl-string">'customProperties', {}).get(class="hl-string">'CompanyCode'),
            class="hl-string">'Department': None,
            class="hl-string">'GLAccount': None,
            class="hl-string">'ReconciliationStatus': None,
            class="hl-string">'ReconciliationCategory': None
        })

        class=class="hl-string">"hl-comment"># 3. Fetch all tasks for the current process
        print(fclass="hl-string">'Fetching tasks for process: {financial_period}')
        tasks = get_all_pages(fclass="hl-string">'{BASE_URL}/tasks?filter[processId]={process_id}', headers, None)

        for task in tasks:
            task_name = task.get(class="hl-string">'name', class="hl-string">'').lower()
            task_assignee_id = task.get(class="hl-string">'assignee', {}).get(class="hl-string">'id')
            task_status = task.get(class="hl-string">'status', {}).get(class="hl-string">'value', class="hl-string">'').lower()
            reconciliation_category = task.get(class="hl-string">'customProperties', {}).get(class="hl-string">'ReconciliationCategory')
            gl_account = task.get(class="hl-string">'customProperties', {}).get(class="hl-string">'GLAccount')

            class=class="hl-string">"hl-comment"># Map task creation to class="hl-string">'Started' activities
            activity_map_start = {
                class="hl-string">'import source data': class="hl-string">'Source Data Imported',
                class="hl-string">'reconcile account': class="hl-string">'Account Reconciliation Started',
                class="hl-string">'intercompany reconciliation': class="hl-string">'Intercompany Reconciliation Started',
                class="hl-string">'prepare trial balance': class="hl-string">'Trial Balance Prepared',
                class="hl-string">'generate financial statements': class="hl-string">'Financial Statements Generated',
                class="hl-string">'review financial statements': class="hl-string">'Financial Statements Reviewed',
                class="hl-string">'post adjusting journal entry': class="hl-string">'Adjusting Journal Entry Posted'
            }
            for key, activity in activity_map_start.items():
                if key in task_name:
                    event_log.append({
                        class="hl-string">'FinancialPeriod': financial_period,
                        class="hl-string">'ActivityName': activity,
                        class="hl-string">'EventTimestamp': task[class="hl-string">'created'],
                        class="hl-string">'ResponsibleUser': task_assignee_id,
                        class="hl-string">'CompanyCode': process.get(class="hl-string">'customProperties', {}).get(class="hl-string">'CompanyCode'),
                        class="hl-string">'Department': task.get(class="hl-string">'customProperties', {}).get(class="hl-string">'Department'),
                        class="hl-string">'GLAccount': gl_account,
                        class="hl-string">'ReconciliationStatus': class="hl-string">'In Progress',
                        class="hl-string">'ReconciliationCategory': reconciliation_category
                    })

            class=class="hl-string">"hl-comment"># Map task status changes and completion to other activities
            if task.get(class="hl-string">'completed'):
                activity_map_completed = {
                    class="hl-string">'reconcile account': class="hl-string">'Reconciliation Submitted for Review',
                    class="hl-string">'intercompany reconciliation': class="hl-string">'Reconciliation Submitted for Review',
                    class="hl-string">'approve reconciliation': class="hl-string">'Reconciliation Reviewed and Approved',
                    class="hl-string">'approve financial statements': class="hl-string">'Financial Statements Approved',
                    class="hl-string">'close period': class="hl-string">'Period Close Completed'
                }
                for key, activity in activity_map_completed.items():
                    if key in task_name:
                         event_log.append({
                            class="hl-string">'FinancialPeriod': financial_period,
                            class="hl-string">'ActivityName': activity,
                            class="hl-string">'EventTimestamp': task[class="hl-string">'completed'],
                            class="hl-string">'ResponsibleUser': task.get(class="hl-string">'completedBy',{}).get(class="hl-string">'id'),
                            class="hl-string">'CompanyCode': process.get(class="hl-string">'customProperties', {}).get(class="hl-string">'CompanyCode'),
                            class="hl-string">'Department': task.get(class="hl-string">'customProperties', {}).get(class="hl-string">'Department'),
                            class="hl-string">'GLAccount': gl_account,
                            class="hl-string">'ReconciliationStatus': class="hl-string">'Approved' if class="hl-string">'approve' in key else class="hl-string">'Submitted',
                            class="hl-string">'ReconciliationCategory': reconciliation_category
                        })

            if task_status == class="hl-string">'rejected':
                 event_log.append({
                    class="hl-string">'FinancialPeriod': financial_period,
                    class="hl-string">'ActivityName': class="hl-string">'Reconciliation Rejected',
                    class="hl-string">'EventTimestamp': task.get(class="hl-string">'updated'), class=class="hl-string">"hl-comment"># Use last updated time for rejection event
                    class="hl-string">'ResponsibleUser': task_assignee_id,
                    class="hl-string">'CompanyCode': process.get(class="hl-string">'customProperties', {}).get(class="hl-string">'CompanyCode'),
                    class="hl-string">'Department': task.get(class="hl-string">'customProperties', {}).get(class="hl-string">'Department'),
                    class="hl-string">'GLAccount': gl_account,
                    class="hl-string">'ReconciliationStatus': class="hl-string">'Rejected',
                    class="hl-string">'ReconciliationCategory': reconciliation_category
                })

        class=class="hl-string">"hl-comment"># Activity: Period Re-Opened (Example logic, assumes a status on the process itself)
        if process.get(class="hl-string">'status', {}).get(class="hl-string">'value') == class="hl-string">'re-opened':
            event_log.append({
                class="hl-string">'FinancialPeriod': financial_period,
                class="hl-string">'ActivityName': class="hl-string">'Period Re-Opened',
                class="hl-string">'EventTimestamp': process[class="hl-string">'updated'],
                class="hl-string">'ResponsibleUser': process_owner_id,
                class="hl-string">'CompanyCode': process.get(class="hl-string">'customProperties', {}).get(class="hl-string">'CompanyCode'),
                class="hl-string">'Department': None,
                class="hl-string">'GLAccount': None,
                class="hl-string">'ReconciliationStatus': None,
                class="hl-string">'ReconciliationCategory': None
            })

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

    class=class="hl-string">"hl-comment"># 4. Create and save the DataFrame
    print(class="hl-string">'Creating DataFrame and saving to CSV...')
    df = pd.DataFrame(event_log)

    class=class="hl-string">"hl-comment"># Add static columns
    df[class="hl-string">'SourceSystem'] = class="hl-string">'Workiva'
    df[class="hl-string">'LastDataUpdate'] = last_data_update

    class=class="hl-string">"hl-comment"># Reorder columns to a logical format
    final_columns = [
        class="hl-string">'FinancialPeriod', class="hl-string">'ActivityName', class="hl-string">'EventTimestamp', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate',
        class="hl-string">'ResponsibleUser', class="hl-string">'Department', class="hl-string">'CompanyCode', class="hl-string">'GLAccount', class="hl-string">'ReconciliationStatus', class="hl-string">'ReconciliationCategory'
    ]
    df = df[final_columns]

    df.to_csv(class="hl-string">'workiva_event_log.csv', index=False)
    print(class="hl-string">'Extraction complete. Output saved to workiva_event_log.csv')

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

決算報告 - 期末決算・照合データテンプレート

決算報告 - 期末決算・照合データテンプレート

Record to Report - 期間締め処理と照合属性

Record to Report - 期間締め処理と照合アクティビティ

抽出ガイド

Workiva プロセスレポートおよびスプレッドシートエクスポート

ステップ

設定

a クエリ例 config

Workiva Wdata Chains データ自動抽出

ステップ

設定

a クエリ例 config

Workiva REST APIを介したPythonスクリプトによるデータ抽出

ステップ

設定

a クエリ例 python

今すぐ始めますか？

記録から報告まで（R2R）の決算締処理と勘定調整を今すぐ最適化

決算報告 - 期末決算・照合データテンプレート

決算報告 - 期末決算・照合データテンプレート

Record to Report - 期間締め処理と照合属性

Record to Report - 期間締め処理と照合アクティビティ

抽出ガイド

Workiva プロセスレポートおよびスプレッドシートエクスポート

ステップ

設定

a クエリ例 config

Workiva Wdata Chains データ自動抽出

ステップ

設定

a クエリ例 config

Workiva REST APIを介したPythonスクリプトによるデータ抽出

ステップ

設定

a クエリ例 python

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

今すぐ始めますか？

記録から報告まで（R2R）の決算締処理と勘定調整を今すぐ最適化