> 継続的なプロセス改善 > 決算報告プロセス仕訳伝票 > BlackLine > データテンプレート

決算報告プロセス - 仕訳伝票データテンプレート

BlackLine

決算報告プロセス - 仕訳伝票の属性 (20) 決算報告プロセス - 仕訳伝票アクティビティ (12) 抽出ガイド (2)

決算報告プロセス - 仕訳伝票データテンプレート

このテンプレートは、決算報告プロセス - 仕訳伝票の分析に必要なデータを収集するための包括的なガイドを提供します。収集すべき必須属性、追跡すべき主要アクティビティ、およびブラックラインからこの情報を抽出するための実践的なガイダンスを概説しています。このリソースを使用して、効果的なプロセスマイニングに必要なすべてのデータを確実に捕捉してください。

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

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

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

決算報告プロセス - 仕訳伝票の属性

これらは、決算報告プロセス - 仕訳伝票の包括的な分析のために、イベントログに含めることを推奨するデータフィールドです。

5 必須 6 推奨 9 任意

	名前	説明
	アクティビティ ActivityName	仕訳伝票プロセスのある時点で発生した特定のビジネスイベントの名前。
説明この属性は、「仕訳伝票作成済み」、「仕訳伝票承認済み」、「仕訳伝票転記済み」など、仕訳伝票ライフサイクル内で実行される単一のステップまたはタスクを記述します。各アクティビティはプロセス内の個別のイベントを表します。これらのアクティビティのシーケンスを分析することで、プロセスフローの可視化と理解が可能になります。これは、プロセスバリエーションの発見、ステップ間の移行時間の測定、および仕訳伝票が却下され再提出されるような手戻りループの特定にとって不可欠です。その重要性プロセスの`ステップ`を定義するものであり、プロセス`マップ`の可視化、フローの分析、逸脱や`ボトルネック`の特定に不可欠です。取得元これは通常、ブラックライン内のイベントログ、ステータス変更記録、または監査証跡から導き出されます。システムステータスコードをユーザーフレンドリーなアクティビティ名にマッピングする必要がある場合があります。例仕訳を作成仕訳提出済み仕訳承認済み仕訳転記済み
	仕訳ID JournalEntryId	単一の仕訳伝票の一意の識別子であり、そのライフサイクルを追跡するための主要なケース識別子。
説明仕訳伝票IDは、総勘定元帳に記録された各財務トランザクションのセットを一意に識別します。これは、作成、レビュー、承認、転記など、すべての関連アクティビティをリンクする中心的なキーとして機能します。プロセスマイニングにおいて、このIDは単一の仕訳伝票ケースに属するすべてのイベントを関連付けるために不可欠です。この識別子に基づいてプロセスフローを分析することで、開始から最終照合までのエンドツーエンドのジャーニーを再構築でき、サイクルタイム、ボトルネック、およびプロセスバリエーションの詳細な分析が可能になります。その重要性これは基本的なケース識別子であり、単一の仕訳伝票の完全なライフサイクルを追跡し、そのパフォーマンスを分析することを可能にします。取得元これはブラックラインの仕訳伝票テーブルまたはデータエクスポートにおける主キーです。具体的なフィールド名についてはブラックラインのドキュメントを参照してください。例 JE2024-001234JE2024-001235JE2024-001236
	開始時刻 EventTime	特定のアクティビティまたはイベントが発生した正確なタイムスタンプです。
説明イベントタイムは、ビジネスイベントが発生した日付と時刻を記録します。これはプロセスの時系列の基盤であり、すべてのアクティビティのシーケンスと期間を確立します。このタイムスタンプは、すべての時間ベースのプロセスマイニング分析にとって不可欠です。サイクルタイム、待機時間、アクティビティ間の期間を計算するために使用されます。これにより、ボトルネックの特定、時間の経過に伴うパフォーマンスの分析、およびサービスレベル契約への遵守の評価が可能になります。その重要性このタイムスタンプは、サイクルタイムやボトルネック分析を含むすべてのパフォーマンス指標の基盤であり、プロセスの時系列再構築を可能にします。取得元この情報は、ブラックラインのイベントログまたはトランザクションレコードのタイムスタンプフィールドに捕捉されます。例 2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:05:00Z
	ソースシステム SourceSystem	仕訳伝票データが抽出された記録システム。
説明この属性は、イベントデータの発生元システムを識別します。このコンテキストでは、通常「ブラックライン」ですが、プロセスがそこで開始される場合は、上流のERPシステムからのデータも含まれる可能性があります。ソースシステムを特定することは、データガバナンスとプロセスのコンテキストを理解するために重要です。特に複数のシステムからのデータが結合される環境では、データ取り込みの問題のトラブルシューティングやデータリネージの検証に役立ちます。その重要性 `データ`の出所に関する重要な`コンテキスト`を提供し、`トレーサビリティ`を確保し、異なる`プラットフォーム`からの`データ統合`を管理するのに役立ちます。取得元これは通常、データ抽出および変換プロセス中にデータセットの起源を識別するために追加される静的な値です。例 BlackLine`SAP S/4HANA``Oracle NetSuite`
	最終データ更新 LastDataUpdate	`データ`が`ソースシステム`から最後に更新または抽出された日時を示す`タイムスタンプ`です。
説明この属性は、最新のデータ取得の日時を示します。これは分析中のデータの鮮度に関する参照点を提供し、ユーザーがデータの通貨を認識していることを保証します。これは、あらゆるプロセスマイニングダッシュボードまたは分析にとって重要なメタデータです。ユーザーにインサイトの適時性を通知し、最新のトランザクションがビューに含まれているかどうかに関する期待値を管理するのに役立ちます。その重要性 `データ`の鮮度に関する透明性を確保し、`ユーザー`がプロセス分析の最新性を理解できるようにします。取得元このタイムスタンプは、実行時にデータ抽出ツールまたはETLプロセスによって生成され、データセットに追加されます。例 2023-11-01T02:00:00Z2023-11-02T02:00:00Z
	ユーザー UserName	`アクティビティ`を実行した`ユーザー`名または`ID`。
説明この属性は、仕訳伝票の提出、レビュー、または承認を行った人物など、特定のプロセスステップの実行責任者を識別します。これは名前または一意のユーザーIDである場合があります。ユーザーごとのアクティビティ分析は、ワークロード配分、個人のパフォーマンス、およびトレーニング機会の特定を理解するために不可欠です。「作業はチーム全体に均等に配分されているか？」や「どのユーザーの承認時間が最も長いか？」といった質問に答えるのに役立ちます。また、コンプライアンスおよび監査証跡分析にとっても重要です。その重要性 `ワークロード分析`、`チームメンバー`間のパフォーマンス比較を可能にし、`リソース`関連の`ボトルネック`や`トレーニング`ニーズの特定に役立ちます。取得元この情報はブラックラインの監査ログで利用でき、多くの場合、各イベントに関連付けられた「ユーザーID」または「変更者」フィールドとして保存されます。例 j.doea.smithr.joness.patel
	仕訳`ステータス` JournalEntryStatus	「処理中」、「承認済み」、「転記済み」などの仕訳伝票のライフサイクルにおける現在のステータス。
説明この属性は、データ抽出時点での仕訳伝票ケースの現在の状態を示します。これにより、仕訳が全体プロセスの中でどこにあるかのスナップショットが提供されます。プロセスマイニングはアクティビティからフローを再構築しますが、最終ステータスを持つことは、フィルタリングや高レベルのサマリーダッシュボード作成に役立ちます。これにより、現在承認待ちまたは特定の状態で滞留しているすべての仕訳を迅速に特定でき、バックログ分析に価値があります。その重要性仕訳の現在の`ステータス`の`スナップショット`を提供し、`バックログ分析`や`作業中`（`WIP`）の理解に役立ちます。取得元これはブラックラインの仕訳伝票にある標準的なステータスフィールドです。例進行中承認待ち承認済み転記済み却下
	仕訳タイプ JournalEntryType	標準、経常、振替などの仕訳伝票の分類。
説明仕訳タイプは、仕訳をその性質や目的に基づいて分類します。一般的なタイプには、標準的な手動仕訳、自動`システム`生成仕訳、月末の未払い費用に対する定期仕訳、または次期間に自動的に逆仕訳されるリバース仕訳などがあります。この`属性`は、セグメンテーションおよび比較分析にとって極めて重要です。これにより、異なる種類の仕訳間でプロセスパフォーマンス（`サイクルタイム`や却下率など）を比較できます。これは、特定の種類の仕訳が他のものよりも問題が多いか、非効率的であるかを特定するのに役立ち、ターゲットを絞ったプロセス改善につながります。その重要性セグメント化された分析により、異なる種類の仕訳が異なる経路をたどるのか、あるいは異なるパフォーマンス特性を持つのかを理解できます。取得元これはブラックラインの仕訳伝票ヘッダーにある標準的なフィールドです。正確なフィールド名についてはブラックラインのドキュメントを参照してください。例標準経常的取消処理未払い費用
	仕訳金額 JournalEntryAmount	仕訳伝票の総金額で、通常は借方の合計。
説明この属性は、仕訳伝票の財務的価値を表します。これは、高額な仕訳の転記遅延など、プロセス非効率性の財務的影響を理解するために使用できます。仕訳の価値に基づいてプロセスを分析することで、重要性に基づく分析が可能になります。例えば、高額な仕訳に対するプロセス改善を優先したり、それらが異なる承認経路をたどるかどうかを調査したり、サイクルタイムが長いかどうかを判断したりできます。これにより、プロセスフローに重要なビジネスコンテキストが追加されます。その重要性財務上の`コンテキスト`を提供し、`重要性`に基づいて分析を可能にします。例えば、高価値の仕訳を優先したり、`価値ベース`のプロセス逸脱を特定したりします。取得元これは、ブラックラインの仕訳伝票ヘッダーにある、借方または貸方の合計金額を表す計算フィールドまたは標準フィールドです。例 15000.00250.75125000.50500.00
	会社コード CompanyCode	仕訳伝票が作成される法人または会社の一意の識別子。
説明会社コードは企業グループ内の特定の法人を表します。これは財務会計における基本的な組織単位であり、トランザクションが正しいエンティティに計上されることを保証します。プロセスマイニングにおいて、会社コードはフィルタリングと比較のための強力なディメンションです。これにより、異なるエンティティ間でのプロセスパフォーマンスの分析が可能になり、地域またはエンティティ固有のボトルネック、コンプライアンスのばらつき、およびプロセスをグローバルに標準化する機会を特定するのに役立ちます。「承認から転記までの遅延分析」ダッシュボードを直接サポートします。その重要性異なる`法務エンティティ`や`事業部門`間でのパフォーマンス比較とプロセス標準化の取り組みを可能にします。取得元これはブラックラインの仕訳伝票ヘッダーの主要なフィールドであり、多くの場合、基盤となるERPシステムから同期されます。例 1000US01DE012500
	却下理由 RejectionReason	仕訳伝票が却下された際にレビュー担当者から提供される理由。
説明仕訳伝票が修正のために差し戻された場合、承認者は通常、却下の理由を提供します。この属性はその理由を捕捉し、事前定義されたコードまたは自由形式テキストである可能性があります。これは、手戻りの根本原因分析にとって重要な属性です。最も一般的な却下理由を分析することで、企業は不十分なトレーニング、不明確なポリシー、または添付資料の問題など、システム的な問題を特定できます。これは、「仕訳伝票却下・手戻り分析」ダッシュボードを直接サポートし、全体の却下率を削減するのに役立ちます。その重要性プロセス手戻りの根本原因分析に不可欠であり、仕訳が却下される理由を特定し、ターゲットを絞った改善を可能にするのに役立ちます。取得元このデータは通常、ユーザーがブラックラインで「却下」アクションを実行した際に、コメントまたは理由コードフィールドに捕捉されます。例誤った勘定科目`コード`証拠書類の欠落しきい値超過重複仕訳
	`ケース``サイクルタイム` CaseCycleTime	仕訳伝票ケースの作成から最終的な転記検証までの総期間。
説明この属性は、仕訳伝票がそのライフサイクル全体を通過するのにかかった総経過時間を表す算出メトリックです。これは、最初のアクティビティ（例：「仕訳伝票作成済み」）のタイムスタンプと最後のアクティビティ（例：「転記検証済み」または「仕訳伝票照合済み」）のタイムスタンプ間の差として計算されます。これは、全体的なプロセス効率を測定するための主要なKPIです。ほとんどすべてのダッシュボードで使用され、パフォーマンスの全体像を提供し、長期実行ケースを特定し、時間の経過に伴う効率改善を追跡します。これは「平均仕訳伝票サイクルタイム」KPIを直接サポートします。その重要性これは、エンドツーエンドのプロセス効率を測定し、目標に対するパフォーマンスを追跡するための基本的なKPIです。取得元このメトリックは、各JournalEntryIdの最大StartTimeから最小StartTimeを減算することで、プロセスマイニングツール内で計算されます。例 P2DT4H30MP0DT8H15MP5DT12H0M
	ドキュメントが添付されました IsDocumentAttached	仕訳に証拠書類が添付されたかどうかを示すフラグです。
説明このブーリアン属性は、請求書や計算書などの1つ以上の添付資料が仕訳伝票に添付されているかどうかを示します。これはしばしば承認の前提条件となります。このフラグは、「仕訳伝票の文書コンプライアンス」ダッシュボードおよび「文書添付率」KPIにとって重要です。文書の不足が却下や遅延の一般的な原因であるかどうかを分析し、レビュー提出前に添付を要求するポリシーの実施を支援します。その重要性文書化`ポリシー`への`コンプライアンス`を直接測定し、承認遅延や却下の一般的な根本原因を診断するのに役立ちます。取得元これは、提出アクティビティが発生する前に、JournalEntryIdに関連付けられた添付記録の存在を確認することで計算される派生フィールドである可能性が高いです。例 truefalse
	勘定照合済み AccountReconciled	仕訳伝票によって照合されている総勘定元帳の勘定科目番号。
説明この属性は、勘定科目表の中で影響を受ける、または照合されている特定の勘定科目を識別します。仕訳伝票はしばしば勘定照合プロセスの一部であり、これにより仕訳がその特定の勘定科目にリンクされます。この属性は「仕訳伝票照合サイクルタイム」ダッシュボードを直接サポートします。勘定科目ごとのプロセスを分析することで、特定の勘定科目の照合が一貫して長くかかっているかどうかを特定でき、それらの特定の勘定科目に関連する複雑性やデータ問題を示唆します。その重要性仕訳プロセスを照合される特定の勘定に`リンク`させ、照合の`ボトルネック`をターゲットを絞って分析できるようにします。取得元この情報はブラックラインの仕訳伝票明細の一部です。一つの仕訳が複数の勘定科目に影響する場合、ケースレベルに集計する必要があるかもしれません。例 101000210500400100550200
	手戻り IsRework	仕訳が少なくとも一度は却下された場合にtrueとなる計算フラグです。
説明このブーリアンフラグは、手戻りが発生した仕訳伝票を識別するために計算されます。通常、ケースに「仕訳伝票却下済み」アクティビティに続いて「修正および再提出」アクティビティが含まれている場合にtrueに設定されます。この属性は、ユーザーが却下を経験したすべてのケースを簡単にフィルタリングできるようにすることで、手戻り分析を簡素化します。「仕訳伝票却下率」KPIを計算し、「仕訳伝票却下・手戻り分析」ダッシュボードで品質問題のコストと時間への影響を理解するための詳細な分析を行う上で不可欠です。その重要性手戻りが発生した`ケース`を容易に特定し、却下率の計算や`品質`問題の影響分析を簡素化します。取得元このフラグは、各ケースのアクティビティのシーケンスをチェックすることで、プロセスマイニングツール内で計算されます。例 truefalse
	承認から転記までのラグ ApprovalToPostingLag	最終承認から仕訳伝票の実際の転記までの算出期間。
説明このメトリックは、仕訳伝票が完全に承認された後、総勘定元帳に転記されるまでに発生する遅延を測定します。これは、「仕訳伝票承認済み」アクティビティと「仕訳伝票転記済み」アクティビティ間の時間差として計算されます。これは、月次決算プロセスを著しく遅らせる可能性がある承認後のボトルネックを特定するための重要なKPIです。「承認から転記までの遅延分析」ダッシュボードはこのメトリックを使用して、承認された仕訳が迅速に転記されない理由を調査し、プロセスの最終ステップを効率化するのに役立ちます。その重要性承認後の効率を具体的に測定し、決算の速度に影響を与える遅延を特定し排除するのに役立ちます。取得元このメトリックは、各ケースの「仕訳伝票承認済み」イベントと「仕訳伝票転記済み」イベント間の期間を見つけることで、プロセスマイニングツール内で計算されます。例 P0DT1H10MP1DT2H0MP0DT0H5M
	自動化 IsAutomated	仕訳が自動プロセスによって作成または転記されたかどうかを示すフラグです。
説明このブーリアン属性は、ユーザーによって手動で作成および処理される仕訳伝票と、経常仕訳やシステム連携など、システムによって自動的に生成される仕訳伝票を区別します。この属性を分析することは、自動化の有効性を評価するのに役立ちます。これにより、自動化されたプロセスと手動プロセスの間で、サイクルタイム、エラー率、コストを直接比較できます。これは、さらなる自動化のビジネスケースを構築し、既存の取り組みのROIを測定するための鍵となります。その重要性手動プロセスと自動プロセスを直接比較することができ、自動化`イニシアチブ`の影響とROIを測定する上で不可欠です。取得元これは、「仕訳伝票タイプ」（例：「経常的」）またはシステムユーザー（例：「SYSTEM」や「BATCH」）が自動転記に使用されている場合は「ユーザー」フィールドから導き出すことができます。例 truefalse
	計上日 PostingDate	仕訳伝票が総勘定元帳に正式に転記される日付。
説明転記日付は、財務記録におけるトランザクションの有効日です。これは、トランザクションが認識される会計期間を決定するため、会計にとって重要な日付です。イベントタイムスタンプが転記アクティビティが発生した日時を追跡する一方で、転記日付自体は重要なデータ属性です。これは、仕訳が正しい期間に転記されていることを確認するために財務分析で使用され、トランザクション日付、承認日付、転記日付間の遅延を分析するために使用できます。その重要性この日付は財務報告の正確性にとって重要であり、仕訳が正しい会計期間に転記されているかどうかを分析するのに役立ちます。取得元これはブラックラインの仕訳伝票ヘッダーにある標準的な日付フィールドです。例 2023-10-312023-11-012023-10-30
	通貨 Currency	仕訳伝票に指定された金額の通貨コード。
説明この属性は、USD、EUR、GBPなどの仕訳伝票金額の通貨を指定します。トランザクションの財務的価値を正しく解釈するために不可欠です。多国籍組織の場合、通貨別に分析することで有用なコンテキストが得られます。特定の通貨にプロセス分析をフィルタリングでき、金融金額を集計するあらゆるダッシュボードに必要なフィールドです。その重要性財務金額に必要な`コンテキスト`を提供し、正確な解釈を保証し、`通貨`固有の分析を可能にします。取得元これはブラックラインの仕訳伝票ヘッダーにある標準的なフィールドで、通常「文書通貨」などの名称が付けられています。例 USDEURGBPJPY
	部署 Department	仕訳伝票に関連付けられた事業部門または原価センター。
説明この属性は、仕訳伝票を開始した、または費用が割り当てられている部門、原価センター、または機能領域を指定します。これにより、組織的なコンテキストの追加レイヤーが提供されます。部門別にプロセスを分析することで、ビジネスの異なる部分が仕訳伝票プロセスをどのように利用しているかを理解するのに役立ちます。部門間の効率性、コンプライアンス、手戻り率のばらつきを明らかにし、追加のサポートやプロセス標準化が必要な領域を浮き彫りにすることができます。その重要性これにより、異なる事業部門間でプロセスパフォーマンスを比較し、ばらつきや標準化の機会を明らかにすることができます。取得元この情報は通常、ブラックラインの仕訳伝票明細データまたはヘッダーデータの一部であり、多くの場合GL勘定にリンクされています。例財務マーケティング営業運用

必須推奨任意

決算報告プロセス - 仕訳伝票アクティビティ

これらは、お客様の仕訳伝票プロセスを正確に発見し分析するために、イベントログに捕捉すべき主要なプロセスステップとマイルストーンです。

6 推奨 6 任意

	アクティビティ	説明
	仕訳を作成	このアクティビティは、仕訳伝票ケースの開始を示します。ユーザーがブラックラインで新しい仕訳伝票レコードを作成し、一意の仕訳伝票IDが生成され、作成タイムスタンプとユーザーが記録されたときに捕捉されます。
その重要性これはプロセスの主要な開始イベントです。このアクティビティから他のアクティビティまでの時間を分析することで、総プロセスサイクルタイムが明らかになり、ワークフローの非常に早い段階での遅延を特定するのに役立ちます。取得元このイベントは、ブラックラインの仕訳伝票モジュールに明示的に記録されます。主要な仕訳伝票テーブルまたはその監査履歴にある各仕訳伝票IDに関連付けられた作成タイムスタンプとユーザー詳細から捕捉されます。取得仕訳レコードに関連付けられた「作成日」の`タイムスタンプ`から取得されます。イベントタイプ explicit
	仕訳却下済み	このアクティビティは、レビュー担当者または承認者による仕訳伝票の却下を示します。ユーザーが「却下」アクションを実行し、仕訳のステータスが「却下済み」に更新され、監査ログに記録されたときに捕捉されます。
その重要性これは、手戻り、品質問題、トレーニングニーズを特定するための重要なアクティビティです。却下頻度、理由、およびその後の手戻りループを分析することは、プロセス改善とサイクルタイム短縮の鍵となります。取得元これは通常、仕訳伝票データにおける「却下済み」または「修正が必要」へのステータス変更から推測されます。タイムスタンプと却下を実行したユーザーはブラックラインの履歴に記録されます。取得仕訳の`ステータス`が「却下済み」に`アップデート`されたときの`タイムスタンプ`から推測されます。イベントタイプ inferred
	仕訳承認済み	このアクティビティは、仕訳伝票が必要なすべてのレビューおよび承認ステップを通過したことを示します。最終承認者が仕訳を承認し、「承認済み」へのステータス変更がトリガーされたときに捕捉されます。
その重要性これは承認プロセスを締めくくる主要なマイルストーンです。「仕訳伝票提出済み」からこのイベントまでの時間は「承認サイクルタイム」であり、ワークフロー効率を測定する重要なKPIです。取得元このイベントは、仕訳伝票レコードにおける「承認済み」へのステータス変更から推測されます。最終承認者のユーザーIDと承認タイムスタンプは通常、ブラックラインの監査履歴に記録されます。取得仕訳`ステータス`が「承認済み」に`アップデート`されたときの`タイムスタンプ`から推測されます。イベントタイプ inferred
	仕訳提出済み	このアクティビティは、起票者が仕訳伝票を正式にレビューおよび承認ワークフローに提出したときに発生します。これは通常、「準備中」から「提出済み」へのステータス変更として、タイムスタンプとともに捕捉されます。
その重要性これは準備段階の終了と承認サイクルの開始を示します。準備段階と承認段階の両方の期間を測定するための主要なマイルストーンです。取得元これはブラックラインの仕訳伝票レコードのステータス変更から推測される可能性が高いです。「承認申請済み」または類似の値へのステータス変更のタイムスタンプがイベントタイムを示します。取得仕訳`ステータス`フィールドが「提出済み」または「承認保留中」に`アップデート`されたときの`タイムスタンプ`から推測されます。イベントタイプ inferred
	仕訳照合済み	仕訳が最終化され認定された勘定調整に含まれる、`ライフサイクル`の完了を示します。BlackLineでは、これはこの仕訳を含む調整の認証に対応します。
その重要性このアクティビティは、エンドツーエンドプロセスの最終終点として機能します。「仕訳伝票転記済み」から「照合済み」までの時間は、決算業務における勘定照合部分の効率を測定します。取得元これは推測されるイベントです。特定の仕訳伝票を含む勘定照合のステータスが、ブラックラインの勘定照合モジュール内で「認定済み」に変更されたときに特定することで導き出されます。取得仕訳を対応する勘定調整に`リンク`させ、その調整の認証日を取得することで推測されます。イベントタイプ inferred
	仕訳転記済み	承認済み仕訳伝票が総勘定元帳に正式に記録される時点を表します。これは多くの場合、ブラックラインでの明示的なアクションであり、その後に仕訳ステータスが「転記済み」に更新されます。
その重要性これは重要なマイルストーンであり、多くの場合、プロセスの運用上の最終段階と見なされます。「仕訳伝票承認済み」からこのアクティビティまでの遅延時間は、承認後の効率を示す重要な指標です。取得元これは通常、「転記済み」へのステータス変更から推測されます。このイベントは、特定の転記日付とタイムスタンプとともに、転記履歴テーブルまたは監査証跡に明示的に記録されることもあります。取得仕訳`ステータス`が「転記済み」に`アップデート`されたときの`タイムスタンプ`から推測されます。転記日`フィールド`も関連します。イベントタイプ inferred
	仕訳レビュー済み	多段階承認プロセスにおける正式なレビュー手順を表し、指定されたレビュー担当者によって完了されます。これは通常、ステータス変更またはレビュー担当者のアクションを示す特定のログエントリとして捕捉されます。
その重要性明確なレビューと承認`ステップ`を持つ組織にとって、この活動は承認チェーン内の`ボトルネック`を特定するのに役立ちます。初期レビューと最終承認でどれだけ仕訳が待機しているかを示します。取得元 BlackLine`ワークフロー`では、これは承認履歴`ログ`の明示的な`イベント`であるか、「レビュー済み」または「最終承認保留中」への`ステータス`変更から推測できます。`ユーザー`と`タイムスタンプ`が記録されます。取得仕訳`ステータス`がレビュー段階の完了を反映するように変更されたときの`タイムスタンプ`から推測されます。イベントタイプ inferred
	仕訳修正・再提出済み	仕訳伝票が却下され、起票者が必要な修正を行い、再度提出された後に発生します。これは、「却下済み」から「承認申請済み」へのステータス変更によって捕捉されます。
その重要性このアクティビティは、手戻りにかかった時間と労力を定量化するのに役立ちます。「仕訳伝票却下済み」からこのイベントまでの期間は手戻り時間を示し、効率分析の重要な指標です。取得元これは、ブラックラインデータにおけるステータス変更のシーケンス、特に同じ仕訳伝票IDに対して「却下済み」ステータスから「提出済み」または「承認待ち」ステータスへの移行を観察することによって推測されます。取得「却下」から「提出済み」または「承認保留中」への`ステータス`変更から導出されます。イベントタイプ inferred
	仕訳逆仕訳処理済み	このアクティビティは、以前に転記された仕訳伝票を取り消す新しい仕訳伝票の作成と転記を捕捉します。これは通常、元の仕訳伝票が転記された後に発見されたエラーに対応して開始されます。
その重要性このイベントは、上流のデータ品質問題の強い指標です。取消の割合を追跡することで、「転記後修正率」を測定し、精度向上が必要な領域を特定するのに役立ちます。取得元これはしばしば、ユーザーがブラックラインで転記済み仕訳伝票に対して「取消」アクションを開始する明示的なイベントです。システムは新しい振替仕訳を作成し、多くの場合元の仕訳伝票IDにリンクされます。取得「逆仕訳」アクションが`ログ`に記録されたとき、または逆仕訳フラグと元の仕訳IDへのリンクを持つ新しい仕訳が作成されたときに取得されます。イベントタイプ explicit
	承認撤回	このアクティビティは、承認者が以前に付与した承認を取り消し、仕訳伝票を以前の状態に戻すことを表します。これは、「承認済み」から「準備中」のような以前のステータスへの変更によって捕捉されます。
その重要性このまれではあるが重要なアクティビティは、承認後かつ転記前に発見されるプロセス例外や潜在的な問題を浮き彫りにします。これは、データエラーや仕訳に影響するポリシー変更を示唆する可能性があります。取得元これは推測されるイベントであり、「承認済み」から未転記の編集可能なステータスへの変更によって特定されます。このアクションはブラックラインの詳細な監査ログに記録されます。取得「承認済み」から「準備中」や「提出済み」のような先行`ステータス`への変更によって識別されます。イベントタイプ inferred
	添付資料あり	ユーザーが仕訳伝票に1つ以上の添付資料を添付するアクションを表します。このイベントは通常、監査ログまたは仕訳伝票IDにリンクされた関連添付ファイルテーブルに捕捉されます。
その重要性このアクティビティの追跡は、コンプライアンスと効率性を監視するために不可欠です。承認プロセスの遅延が添付資料の不足によって引き起こされているかどうかを分析し、「文書添付率」KPIをサポートするのに役立ちます。取得元これは通常、ブラックラインにおける明示的なイベントであり、監査証跡または添付ファイルログに記録されます。データには、仕訳伝票ID、ファイルを添付したユーザー、およびタイムスタンプが含まれます。取得ファイルが仕訳に`アップロード`されるたびに、`システム`監査証跡または専用の添付ファイル履歴`テーブル`に`イベント`が`ログ`されます。イベントタイプ explicit
	転記検証済み	転記済み仕訳伝票がターゲットERPシステムに正常に受信および記録されたことの確認を表します。これは、システム間の自動連携または手動確認ステップである可能性があります。
その重要性このアクティビティは、転記ステップに最終的な確定をもたらし、システム間のデータ整合性を確保します。「転記済み」から「検証済み」までの期間は、統合の問題やシステム同期の遅延を浮き彫りにする可能性があります。取得元これは、システム統合ログからの明示的なイベントであるか、「転記および検証済み」のような値へのステータス変更から推測される場合があります。手動の場合は、ユーザー主導のステータス更新となります。取得「検証済み」へのステータス``アップデート、または`ターゲット`ERP`システム`から受信した確認`フラグ`から推測されます。イベントタイプ inferred

推奨任意

抽出ガイド

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

ステップ

財務報告へのアクセスに必要な権限を持つユーザーアカウントでBlackLineインスタンスにログインします。
レポートモジュールにナビゲートします。これは通常、「レポート」>「標準レポート」のようなメニューにあります。
利用可能な標準レポートのリストから、「仕訳＆サービスレポート」または同様の名前の包括的な仕訳レポートを見つけて選択します。
レポートパラメータを設定します。分析したい期間に対応する抽出対象の「日付範囲」を指定します。最初の分析には3～6ヶ月の期間を推奨します。
データを絞り込むために必要なフィルターを適用します。最低限、関連する「会社コード」でフィルターをかけます。また、作成から転記までのすべての関連ステータスを含めるために、「仕訳ステータス」でフィルターをかけることもできます。
イベントログ生成に必要なすべての日付、ユーザー、ステータスフィールドがレポートに含まれるように、出力可能なすべての列を選択します。主要フィールドには、作成日、提出日、承認日、転記日、ユーザーロールが含まれます。
BlackLine UIで直接レポートを実行します。レポートの生成が完了したら、「エクスポート」または「ダウンロード」機能を使用してデータをCSVファイルとして保存します。ファイル名を「blackline_report.csv」とします。
pandasライブラリがインストールされたPython環境をセットアップします。インストールされていない場合は、pip install pandasコマンドを使用してインストールします。
提供されたPythonスクリプトを、ダウンロードした「blackline_report.csv」ファイルと同じディレクトリに配置します。
Pythonスクリプトを実行します。スクリプトは生のCSVレポートを読み込み、各ビジネス活動について個別の行を作成することでデータを変換し、必要な形式の「event_log.csv」という新しいファイルを生成します。
アップロードする前に、「event_log.csv」ファイルのデータ品質と完全性を確認するためのバリデーションチェックを実行します。
最終的な「event_log.csv」ファイルをProcessMindにアップロードして分析します。

設定

レポート名: 「仕訳＆サービスレポート」。正確な名称はBlackLineの設定によって異なる場合があります。
日付範囲: 初回分析では、3〜6か月分のデータを抽出することを推奨します。レポートの日付フィルターは通常、仕訳作成日または転記日に適用されます。正しいデータセットが抽出されるよう、どの日付フィールドがフィルターに使用されているか確認してください。
主要フィルター:
- 会社コード: データ量を制限し、分析を集中させるために、常に分析したい会社コードを指定してください。
- 仕訳ステータス: 作成から転記までの完全なend-to-endプロセスを捕捉するために、すべてのステータス（例：準備中、提出済み、承認済み、却下済み、転記済み）を選択してください。
- 仕訳タイプ: 分析範囲に応じて、特定の仕訳タイプ（例：標準、定期）でフィルターをかけてください。
前提条件: レポートを実行するユーザーアカウントは、BlackLine内で仕訳データを表示し、標準レポートを実行する権限を持っている必要があります。これには通常、「経理担当者」または「レポートユーザー」などの役割が必要です。
パフォーマンスに関する考慮事項: 長期間または多数の会社コードをカバーする大規模なデータセットのエクスポートは、リソースを大量に消費し、BlackLine UIでの生成にかなりの時間がかかる場合があります。パフォーマンスの問題やタイムアウトが発生した場合は、レポートをより小さなバッチで実行することを検討してください。

a クエリ例 config

import pandas as pd
import numpy as np
import datetime

# --- Configuration ---
# Define the input file name from BlackLine
input_filename = 'blackline_report.csv'
# Define the output file for ProcessMind
output_filename = 'event_log.csv'

# --- Column Mapping ---
# Map the BlackLine report column names to the required event log attribute names.
# Adjust the keys in this dictionary to match the exact column headers in your CSV export.
column_mapping = {
    'Journal ID': 'JournalEntryId',
    'Journal Type': 'JournalEntryType',
    'Company': 'CompanyCode',
    'Amount': 'JournalEntryAmount',
    'Current Status': 'JournalEntryStatus',
    'Rejection Reason': 'RejectionReason',
    'Preparer': 'PreparerUserName',
    'Submitter': 'SubmitterUserName',
    'Reviewer': 'ReviewerUserName',
    'Approver': 'ApproverUserName',
    'Poster': 'PosterUserName',
    'Verifier': 'VerifierUserName',
    'Reverser': 'ReverserUserName',
    'Reconciler': 'ReconcilerUserName',
    'Creation Date': 'CreationTimestamp',
    'Attachment Date': 'AttachmentTimestamp',
    'Submission Date': 'SubmissionTimestamp',
    'Review Date': 'ReviewTimestamp',
    'Rejection Date': 'RejectionTimestamp',
    'Resubmission Date': 'ResubmissionTimestamp',
    'Approval Date': 'ApprovalTimestamp',
    'Rescind Date': 'RescindTimestamp',
    'Posting Date': 'PostingTimestamp',
    'Verification Date': 'VerificationTimestamp',
    'Reversal Date': 'ReversalTimestamp',
    'Reconciliation Date': 'ReconciliationTimestamp'
}

# --- Data Loading ---
try:
    df_raw = pd.read_csv(input_filename)
except FileNotFoundError:
    print(f"Error: The file {input_filename} was not found. Please ensure it's in the same directory as the script.")
    exit()

# Rename columns based on the mapping
df = df_raw.rename(columns=column_mapping)

# Ensure all required timestamp columns exist, fill with NaT if not
for col in column_mapping.values():
    if 'Timestamp' in col and col not in df.columns:
        df[col] = pd.NaT

# Convert date columns to datetime objects, coercing errors to NaT (Not a Time)
date_cols = [col for col in df.columns if 'Timestamp' in col]
for col in date_cols:
    df[col] = pd.to_datetime(df[col], errors='coerce')

all_events = []
last_data_update = datetime.datetime.now()

# --- Activity Extraction ---

# 1. Journal Entry Created
event_created = df[df['CreationTimestamp'].notna()].copy()
event_created['ActivityName'] = 'Journal Entry Created'
event_created['EventTime'] = event_created['CreationTimestamp']
event_created['UserName'] = event_created.get('PreparerUserName')
all_events.append(event_created)

# 2. Supporting Documentation Attached
if 'AttachmentTimestamp' in df.columns:
    event_attached = df[df['AttachmentTimestamp'].notna()].copy()
    event_attached['ActivityName'] = 'Supporting Documentation Attached'
    event_attached['EventTime'] = event_attached['AttachmentTimestamp']
    # Assuming the submitter or preparer attached the document
    event_attached['UserName'] = event_attached.get('SubmitterUserName', event_attached.get('PreparerUserName'))
    all_events.append(event_attached)

# 3. Journal Entry Submitted
event_submitted = df[df['SubmissionTimestamp'].notna()].copy()
event_submitted['ActivityName'] = 'Journal Entry Submitted'
event_submitted['EventTime'] = event_submitted['SubmissionTimestamp']
event_submitted['UserName'] = event_submitted.get('SubmitterUserName')
all_events.append(event_submitted)

# 4. Journal Entry Reviewed
if 'ReviewTimestamp' in df.columns:
    event_reviewed = df[df['ReviewTimestamp'].notna()].copy()
    event_reviewed['ActivityName'] = 'Journal Entry Reviewed'
    event_reviewed['EventTime'] = event_reviewed['ReviewTimestamp']
    event_reviewed['UserName'] = event_reviewed.get('ReviewerUserName')
    all_events.append(event_reviewed)

# 5. Journal Entry Rejected
if 'RejectionTimestamp' in df.columns:
    event_rejected = df[df['RejectionTimestamp'].notna()].copy()
    event_rejected['ActivityName'] = 'Journal Entry Rejected'
    event_rejected['EventTime'] = event_rejected['RejectionTimestamp']
    event_rejected['UserName'] = event_rejected.get('ReviewerUserName', event_rejected.get('ApproverUserName'))
    all_events.append(event_rejected)

# 6. Entry Corrected and Resubmitted
if 'ResubmissionTimestamp' in df.columns:
    event_resubmitted = df[df['ResubmissionTimestamp'].notna()].copy()
    event_resubmitted = event_resubmitted[event_resubmitted['ResubmissionTimestamp'] > event_resubmitted.get('RejectionTimestamp', pd.NaT)]
    event_resubmitted['ActivityName'] = 'Entry Corrected and Resubmitted'
    event_resubmitted['EventTime'] = event_resubmitted['ResubmissionTimestamp']
    event_resubmitted['UserName'] = event_resubmitted.get('SubmitterUserName')
    all_events.append(event_resubmitted)

# 7. Journal Entry Approved
event_approved = df[df['ApprovalTimestamp'].notna()].copy()
event_approved['ActivityName'] = 'Journal Entry Approved'
event_approved['EventTime'] = event_approved['ApprovalTimestamp']
event_approved['UserName'] = event_approved.get('ApproverUserName')
all_events.append(event_approved)

# 8. Approval Rescinded
if 'RescindTimestamp' in df.columns:
    event_rescinded = df[df['RescindTimestamp'].notna()].copy()
    event_rescinded['ActivityName'] = 'Approval Rescinded'
    event_rescinded['EventTime'] = event_rescinded['RescindTimestamp']
    event_rescinded['UserName'] = event_rescinded.get('ApproverUserName')
    all_events.append(event_rescinded)

# 9. Journal Entry Posted
event_posted = df[df['PostingTimestamp'].notna()].copy()
event_posted['ActivityName'] = 'Journal Entry Posted'
event_posted['EventTime'] = event_posted['PostingTimestamp']
event_posted['UserName'] = event_posted.get('PosterUserName')
all_events.append(event_posted)

# 10. Posting Verified
if 'VerificationTimestamp' in df.columns:
    event_verified = df[df['VerificationTimestamp'].notna()].copy()
    event_verified['ActivityName'] = 'Posting Verified'
    event_verified['EventTime'] = event_verified['VerificationTimestamp']
    event_verified['UserName'] = event_verified.get('VerifierUserName')
    all_events.append(event_verified)

# 11. Journal Entry Reversal Processed
if 'ReversalTimestamp' in df.columns:
    event_reversal = df[df['ReversalTimestamp'].notna()].copy()
    event_reversal['ActivityName'] = 'Journal Entry Reversal Processed'
    event_reversal['EventTime'] = event_reversal['ReversalTimestamp']
    event_reversal['UserName'] = event_reversal.get('ReverserUserName')
    all_events.append(event_reversal)

# 12. Journal Entry Reconciled
if 'ReconciliationTimestamp' in df.columns:
    event_reconciled = df[df['ReconciliationTimestamp'].notna()].copy()
    event_reconciled['ActivityName'] = 'Journal Entry Reconciled'
    event_reconciled['EventTime'] = event_reconciled['ReconciliationTimestamp']
    event_reconciled['UserName'] = event_reconciled.get('ReconcilerUserName')
    all_events.append(event_reconciled)


# --- Final Assembly ---
if all_events:
    event_log = pd.concat(all_events, ignore_index=True)

    # Add required constant value attributes
    event_log['SourceSystem'] = 'BlackLine'
    event_log['LastDataUpdate'] = last_data_update

    # Select and order columns for the final output
    final_columns = [
        'JournalEntryId',
        'ActivityName',
        'EventTime',
        'SourceSystem',
        'LastDataUpdate',
        'UserName',
        'JournalEntryType',
        'CompanyCode',
        'JournalEntryAmount',
        'JournalEntryStatus',
        'RejectionReason'
    ]

    # Filter for only the columns that exist in the dataframe to avoid errors
    existing_columns = [col for col in final_columns if col in event_log.columns]
    event_log = event_log[existing_columns]

    # Sort the event log
    event_log = event_log.sort_values(by=['JournalEntryId', 'EventTime'])

    # Save to CSV
    event_log.to_csv(output_filename, index=False, date_format='%Y-%m-%d %H:%M:%S')
    print(f"Successfully created event log: {output_filename}")
else:
    print("No events were generated. Please check your input file and column mappings.")

ステップ

前提条件とセットアップ: Python 3.6以降がインストールされていることを確認してください。必要なライブラリをpipでインストールします: pip install requests pandas。APIクレデンシャル（クライアントID、クライアントシークレット、リフレッシュトークン）および組織のBlackLineベースURLをBlackLine管理者から取得します。
スクリプト変数の設定: Pythonスクリプトを開き、設定セクションを見つけます。クライアントID、クライアントシークレット、リフレッシュトークン、ベースURLを入力します。START_DATEとEND_DATE変数を「YYYY-MM-DD」形式で設定して抽出期間を定義します。
認証: スクリプトはget_access_token関数を呼び出すことから始まります。この関数はクレデンシャルをBlackLine認証エンドポイント（/api/oauth/token）に送信し、その後のすべてのAPIリクエストに必要な一時的なアクセストークンを取得します。
初期仕訳リストの取得: スクリプトは/api/v2/journalsエンドポイントに対し、指定された作成日範囲でフィルタリングされたページネーションリクエストを行います。ページをループして、範囲内のすべての仕訳の主要な詳細を収集します。
詳細なイベント履歴の取得: 前のステップで収集された各Journal Entry IDについて、スクリプトはさらに2つのAPI呼び出しを行います。まず、仕訳の履歴エンドポイント（例：/api/v2/journals/{id}/history）にクエリを送信し、ステータス変更、承認、却下に関する詳細な監査証跡を取得します。次に、添付ファイルエンドポイント（例：/api/v2/journals/{id}/attachments）を呼び出し、証拠書類がいつ追加されたかを識別します。
データをイベントログに変換: スクリプトはAPIからのJSONレスポンスを処理します。各仕訳とその関連履歴および添付ファイルレコードを反復処理し、生のデータを構造化されたイベントログ形式にマッピングします。これにより、「仕訳作成」、「仕訳提出」、「仕訳承認」などの、必要な12の活動それぞれについて個別の行を作成します。
ステータス変更を活動にマッピング: 主要な活動は履歴エンドポイントからのデータを解釈することで生成されます。例えば、「提出済み」へのステータス変更を示す履歴項目は、「仕訳提出」活動となります。スクリプトには、異なる履歴イベントタイプをProcessMindで必要とされる標準化された活動名にマッピングするロジックが含まれています。
データフレームの構築: スクリプトはpandasライブラリを使用してデータフレームを構築します。まず、主要な仕訳リストから「作成済み」イベントのデータフレームを作成します。次に、履歴および添付ファイルログから派生した他のすべての活動を含む別のデータフレームを作成します。これらはその後、単一の包括的なイベントログに結合されます。
メタデータの追加と列の標準化: データを結合した後、スクリプトは、SourceSystem（「BlackLine」としてハードコード）やLastDataUpdate（スクリプトの実行時間に設定）などの必要なメタデータ列を追加します。また、APIのidフィールドをJournalEntryIdにマッピングするなど、必要なスキーマに一致するように列名を変更します。
CSVへのエクスポート: 最後に、スクリプトは完成したイベントログ``データフレームをblackline_journal_entry_event_log.csvという名前のCSVファイルにエクスポートします。このファイルは、ProcessMindに直接アップロードできるようフォーマットされています。

設定

APIクレデンシャル: BlackLine REST APIの有効なクライアントID、クライアントシークレット、リフレッシュトークンが必要です。これらは安全に保管し、本番スクリプトに直接ハードコードしないでください。
ベースURL: スクリプトには、組織固有のBlackLine APIベースURL（例: https://api.blackline.com）が必要です。
日付範囲: スクリプトはSTART_DATEとEND_DATE変数で設定されます。初回分析では、過度に大きくならずに十分なデータを提供するために、過去3～6か月間の活動をカバーする日付範囲が推奨されます。
ページネーション制限: LIMIT変数は、API呼び出しごとに取得されるレコード数を制御します。デフォルトは通常100です。これを調整するとパフォーマンスに影響が出る可能性があるため、BlackLineサポートから別途指示がない限り、推奨値のままにしておくのが最適です。
必要な権限: 資格情報に関連付けられたAPIユーザーは、分析対象のすべての会社コードで仕訳、仕訳履歴、添付ファイルを読み取るための十分な権限を持っている必要があります。
Python環境: スクリプトを実行するには、requestsおよびpandasライブラリがインストールされたPython 3.6以降の動作環境が必須です。

a クエリ例 python

import requests
import pandas as pd
from datetime import datetime
import time

class=class="hl-string">"hl-comment"># --- Configuration ---
class=class="hl-string">"hl-comment"># Replace with your BlackLine API credentials and base URL
CLIENT_ID = class="hl-string">'[Your Client ID]'
CLIENT_SECRET = class="hl-string">'[Your Client Secret]'
REFRESH_TOKEN = class="hl-string">'[Your Refresh Token]'
BASE_URL = class="hl-string">'[Your BlackLine API Base URL, e.g., https://api.blackline.com]'

class=class="hl-string">"hl-comment"># --- Extraction Parameters ---
START_DATE = class="hl-string">'2023-01-01' class=class="hl-string">"hl-comment"># Format: YYYY-MM-DD
END_DATE = class="hl-string">'2023-12-31'   class=class="hl-string">"hl-comment"># Format: YYYY-MM-DD
LIMIT = 100 class=class="hl-string">"hl-comment"># Records per page

def get_access_token():
    class="hl-string">"""Authenticates with BlackLine to get an access token."""
    auth_url = fclass="hl-string">"{BASE_URL}/api/oauth/token"
    payload = {
        class="hl-string">'grant_type': class="hl-string">'refresh_token',
        class="hl-string">'client_id': CLIENT_ID,
        class="hl-string">'client_secret': CLIENT_SECRET,
        class="hl-string">'refresh_token': REFRESH_TOKEN
    }
    response = requests.post(auth_url, data=payload)
    response.raise_for_status() class=class="hl-string">"hl-comment"># Raise an exception for bad status codes
    return response.json()[class="hl-string">'access_token']

def main():
    class="hl-string">"""Main function to extract, transform, and save journal entry event data."""
    print(class="hl-string">"Starting BlackLine Journal Entry extraction...")
    
    try:
        access_token = get_access_token()
        headers = {class="hl-string">'Authorization': fclass="hl-string">'Bearer {access_token}'}
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Authentication failed: {e}")
        return

    events = []
    last_data_update = datetime.utcnow().isoformat() + class="hl-string">'Z'

    class=class="hl-string">"hl-comment"># 1. Fetch all journals within the date range
    print(fclass="hl-string">"Fetching journals created between {START_DATE} and {END_DATE}...")
    journals = []
    offset = 0
    while True:
        journals_url = fclass="hl-string">"{BASE_URL}/api/v2/journals"
        params = {
            class="hl-string">'createdStartDate': START_DATE,
            class="hl-string">'createdEndDate': END_DATE,
            class="hl-string">'limit': LIMIT,
            class="hl-string">'offset': offset
        }
        try:
            response = requests.get(journals_url, headers=headers, params=params)
            response.raise_for_status()
            data = response.json()
            journals.extend(data.get(class="hl-string">'data', []))
            if class="hl-string">'nextLink' not in data or not data.get(class="hl-string">'data'):
                break
            offset += LIMIT
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Error fetching journals: {e}")
            break

    print(fclass="hl-string">"Found {len(journals)} journals. Now fetching detailed events for each...")

    class=class="hl-string">"hl-comment"># 2. For each journal, fetch history and attachments
    for journal in journals:
        journal_id = journal.get(class="hl-string">'id')
        if not journal_id:
            continue

        class=class="hl-string">"hl-comment"># --- Activity: Journal Entry Created ---
        events.append({
            class="hl-string">'JournalEntryId': journal_id,
            class="hl-string">'ActivityName': class="hl-string">'Journal Entry Created',
            class="hl-string">'EventTime': journal.get(class="hl-string">'createdDate'),
            class="hl-string">'UserName': journal.get(class="hl-string">'createdBy', {}).get(class="hl-string">'username'),
            class="hl-string">'JournalEntryType': journal.get(class="hl-string">'type'),
            class="hl-string">'CompanyCode': journal.get(class="hl-string">'companyCode'),
            class="hl-string">'JournalEntryAmount': journal.get(class="hl-string">'totalDebit'),
            class="hl-string">'JournalEntryStatus': journal.get(class="hl-string">'status'),
            class="hl-string">'RejectionReason': None
        })

        class=class="hl-string">"hl-comment"># Fetch history for other activities
        try:
            history_url = fclass="hl-string">"{BASE_URL}/api/v2/journals/{journal_id}/history"
            history_response = requests.get(history_url, headers=headers)
            history_response.raise_for_status()
            history_items = history_response.json().get(class="hl-string">'data', [])
            
            for item in history_items:
                activity_name = None
                rejection_reason = None
                
                class=class="hl-string">"hl-comment"># This mapping requires knowledge of your specific BlackLine history event descriptions
                class=class="hl-string">"hl-comment"># The following are common examples. Adjust them based on your BlackLine configuration.
                event_description = item.get(class="hl-string">'description', class="hl-string">'').lower()
                if class="hl-string">'submitted' in event_description:
                    activity_name = class="hl-string">'Journal Entry Submitted'
                elif class="hl-string">'reviewed' in event_description:
                    activity_name = class="hl-string">'Journal Entry Reviewed'
                elif class="hl-string">'rejected' in event_description:
                    activity_name = class="hl-string">'Journal Entry Rejected'
                    rejection_reason = item.get(class="hl-string">'comment') class=class="hl-string">"hl-comment"># Assuming comment contains the reason
                elif class="hl-string">'resubmitted' in event_description:
                    activity_name = class="hl-string">'Entry Corrected and Resubmitted'
                elif class="hl-string">'approved' in event_description and class="hl-string">'final' in event_description: class=class="hl-string">"hl-comment"># Example for final approval
                    activity_name = class="hl-string">'Journal Entry Approved'
                elif class="hl-string">'approval rescinded' in event_description:
                    activity_name = class="hl-string">'Approval Rescinded'
                elif class="hl-string">'posted' in event_description:
                    activity_name = class="hl-string">'Journal Entry Posted'
                elif class="hl-string">'posting verified' in event_description:
                     activity_name = class="hl-string">'Posting Verified'
                
                if activity_name:
                    events.append({
                        class="hl-string">'JournalEntryId': journal_id,
                        class="hl-string">'ActivityName': activity_name,
                        class="hl-string">'EventTime': item.get(class="hl-string">'eventDate'),
                        class="hl-string">'UserName': item.get(class="hl-string">'user', {}).get(class="hl-string">'username'),
                        class="hl-string">'JournalEntryType': journal.get(class="hl-string">'type'),
                        class="hl-string">'CompanyCode': journal.get(class="hl-string">'companyCode'),
                        class="hl-string">'JournalEntryAmount': journal.get(class="hl-string">'totalDebit'),
                        class="hl-string">'JournalEntryStatus': journal.get(class="hl-string">'status'),
                        class="hl-string">'RejectionReason': rejection_reason
                    })
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Could not fetch history for Journal ID {journal_id}: {e}")

        class=class="hl-string">"hl-comment"># Fetch attachments
        try:
            attachments_url = fclass="hl-string">"{BASE_URL}/api/v2/journals/{journal_id}/attachments"
            attachments_response = requests.get(attachments_url, headers=headers)
            attachments_response.raise_for_status()
            attachments = attachments_response.json().get(class="hl-string">'data', [])
            for attachment in attachments:
                events.append({
                    class="hl-string">'JournalEntryId': journal_id,
                    class="hl-string">'ActivityName': class="hl-string">'Supporting Documentation Attached',
                    class="hl-string">'EventTime': attachment.get(class="hl-string">'uploadedDate'),
                    class="hl-string">'UserName': attachment.get(class="hl-string">'uploadedBy', {}).get(class="hl-string">'username'),
                    class="hl-string">'JournalEntryType': journal.get(class="hl-string">'type'),
                    class="hl-string">'CompanyCode': journal.get(class="hl-string">'companyCode'),
                    class="hl-string">'JournalEntryAmount': journal.get(class="hl-string">'totalDebit'),
                    class="hl-string">'JournalEntryStatus': journal.get(class="hl-string">'status'),
                    class="hl-string">'RejectionReason': None
                })
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Could not fetch attachments for Journal ID {journal_id}: {e}")

        class=class="hl-string">"hl-comment"># --- Activities based on journal fields (may need customization) ---
        if journal.get(class="hl-string">'isReversed'):
            events.append({
                class="hl-string">'JournalEntryId': journal_id,
                class="hl-string">'ActivityName': class="hl-string">'Journal Entry Reversal Processed',
                class="hl-string">'EventTime': journal.get(class="hl-string">'[reversalDate]'), class=class="hl-string">"hl-comment"># Placeholder for reversal date field
                class="hl-string">'UserName': journal.get(class="hl-string">'[reversalUser]'), class=class="hl-string">"hl-comment"># Placeholder for user field
                class="hl-string">'JournalEntryType': journal.get(class="hl-string">'type'),
                class="hl-string">'CompanyCode': journal.get(class="hl-string">'companyCode'),
                class="hl-string">'JournalEntryAmount': journal.get(class="hl-string">'totalDebit'),
                class="hl-string">'JournalEntryStatus': class="hl-string">'Reversed',
                class="hl-string">'RejectionReason': None
            })

        if journal.get(class="hl-string">'reconciliationId'): class=class="hl-string">"hl-comment"># Assuming this indicates reconciliation
            events.append({
                class="hl-string">'JournalEntryId': journal_id,
                class="hl-string">'ActivityName': class="hl-string">'Journal Entry Reconciled',
                class="hl-string">'EventTime': journal.get(class="hl-string">'[reconciliationCertifiedDate]'), class=class="hl-string">"hl-comment"># Placeholder for certified date
                class="hl-string">'UserName': journal.get(class="hl-string">'[reconciliationCertifier]'), class=class="hl-string">"hl-comment"># Placeholder for certifier user
                class="hl-string">'JournalEntryType': journal.get(class="hl-string">'type'),
                class="hl-string">'CompanyCode': journal.get(class="hl-string">'companyCode'),
                class="hl-string">'JournalEntryAmount': journal.get(class="hl-string">'totalDebit'),
                class="hl-string">'JournalEntryStatus': journal.get(class="hl-string">'status'),
                class="hl-string">'RejectionReason': None
            })
        class=class="hl-string">"hl-comment"># Introduce a small delay to respect API rate limits
        time.sleep(0.1)

    if not events:
        print(class="hl-string">"No events were generated. Please check your date range and API access.")
        return

    class=class="hl-string">"hl-comment"># 3. Create DataFrame and save to CSV
    print(class="hl-string">"Transforming data and saving to CSV...")
    df = pd.DataFrame(events)

    class=class="hl-string">"hl-comment"># Add metadata columns
    df[class="hl-string">'SourceSystem'] = class="hl-string">'BlackLine'
    df[class="hl-string">'LastDataUpdate'] = last_data_update
    
    class=class="hl-string">"hl-comment"># Ensure required columns are present
    final_columns = [
        class="hl-string">'JournalEntryId', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate',
        class="hl-string">'UserName', class="hl-string">'JournalEntryType', class="hl-string">'CompanyCode', class="hl-string">'JournalEntryAmount', class="hl-string">'JournalEntryStatus', class="hl-string">'RejectionReason'
    ]
    for col in final_columns:
        if col not in df.columns:
            df[col] = None
            
    df = df[final_columns] class=class="hl-string">"hl-comment"># Order columns

    output_filename = class="hl-string">'blackline_journal_entry_event_log.csv'
    df.to_csv(output_filename, index=False)
    print(fclass="hl-string">"Extraction complete. Event log saved to {output_filename}")

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

決算報告プロセス - 仕訳伝票データテンプレート

決算報告プロセス - 仕訳伝票データテンプレート

決算報告プロセス - 仕訳伝票の属性

決算報告プロセス - 仕訳伝票アクティビティ

抽出ガイド

BlackLine 仕訳＆サービスレポート `エクスポート`

ステップ

設定

a クエリ例 config

PythonスクリプトによるブラックラインREST API経由の抽出

ステップ

設定

a クエリ例 python

今すぐ始めますか？

今すぐ決算報告プロセスの仕訳伝票効率を最適化する

決算報告プロセス - 仕訳伝票データテンプレート

決算報告プロセス - 仕訳伝票データテンプレート

決算報告プロセス - 仕訳伝票の属性

決算報告プロセス - 仕訳伝票アクティビティ

抽出ガイド

BlackLine 仕訳＆サービスレポート `エクスポート`

ステップ

設定

a クエリ例 config

PythonスクリプトによるブラックラインREST API経由の抽出

ステップ

設定

a クエリ例 python

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

今すぐ始めますか？

今すぐ決算報告プロセスの仕訳伝票効率を最適化する