> 継続的なプロセス改善 > 経費精算 > Coupa Expenses > データテンプレート

経費管理データ``テンプレート

Coupa Expenses

経費管理データ``テンプレート

この包括的なデータテンプレートは、Coupa Expenses内での経費管理プロセスを分析するための構造化されたアプローチを提供します。収集すべき必須のデータ属性、追跡すべき重要なアクティビティ、およびデータ抽出に関する実用的なガイダンスを概説しています。このテンプレートを使用して、徹底的なプロセスマイニング分析に必要なすべての情報を確実に収集してください。

包括的なデータ収集のための推奨属性
追跡すべき主要な経費管理アクティビティ
Coupa Expensesからのデータ抽出に関するステップバイステップガイド

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

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

経費精算属性

これらは、経費管理プロセスの包括的な分析のためにイベントログに含めることを推奨するデータフィールドです。

5 必須 7 推奨 9 任意

	名前	説明
	アクティビティ名 ActivityName	経費レポートに関して特定の時点で発生したビジネスイベントの名前。
説明アクティビティ名は、「経費レポート提出済み」、「マネージャー承認済み」、「精算実行済み」など、経費管理プロセスにおける特定のステップや節目を表します。これらのアクティビティはプロセスマップのノードを形成し、プロセスフロー、ボトルネック、およびバリエーションを分析するための基礎となります。この属性の分析は、イベントの順序、異なるプロセスステップの頻度、およびそれらの間の遷移を理解するのに役立ちます。これは、プロセスマップの構築、遷移時間の計算、および一般的または準拠していないプロセスパスの特定にとって不可欠です。その重要性この属性はプロセスのステップを定義し、プロセスマイニングの核であるプロセスフローの視覚化と分析を可能にします。取得元これは通常、Coupaの経費レポートオブジェクトに関連するイベントログ、ステータス変更記録、または監査証跡テーブルから導出されます。ステータスコードまたはイベントタイプをユーザーフレンドリーな名前にマッピングする必要がある場合があります。例経費レポート提出済みマネージャー承認財務却下済み精算実行済み
	イベント日時 EventTime	アクティビティ／event の発生時刻を示すタイムスタンプ。
説明イベントタイムは、特定の活動がシステムに記録された正確な日付と時刻です。このタイムスタンプは、イベントを時系列で並べ替え、すべての時間ベースの分析を行うために不可欠です。これにより、プロセスステップのタイミングと期間を理解するための事実に基づいた根拠が提供されます。プロセスマイニングでは、この属性は各ケースのタイムラインを構築し、アクティビティ間の期間を計算し、遅延を特定し、全体のサイクルタイムを測定するために使用されます。パフォーマンス分析、サービスレベル契約の遵守、時間的パターンやボトルネックの特定に不可欠です。その重要性このタイムスタンプはイベントの時系列順序を提供し、サイクルタイムやボトルネックの特定を含む、すべての期間およびパフォーマンスベースの分析の基礎となります。取得元この情報は通常、Coupaの監査証跡またはイベントログテーブルに、アクティビティまたはステータス変更の記録とともにあることが確認できます。例 2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z
	経費レポートID ExpenseReportId	経費レポートの一意の識別子。単一の申請に関するすべての関連アクティビティと経費をグループ化します。
説明経費レポートIDは、単一の経費提出に関連するすべてのイベントとアクティビティをグループ化する主要なケース識別子として機能します。各経費レポートには作成時に一意のIDが割り当てられ、最初の入力から最終支払いまでの経費請求を完全に時系列で追跡できます。プロセスマイニング分析において、このIDは各経費レポートのエンドツーエンドのジャーニーを再構築するために不可欠です。これにより、アナリストはプロセスフローを視覚化し、処理パスのバリエーションを特定し、個々の請求の合計サイクル時間や手戻りループなどのケースレベルのメトリクスを計算できます。その重要性これは、単一の経費請求に関するすべての関連イベントを接続するための不可欠なキーであり、プロセス全体を最初から最後まで分析することを可能にします。取得元これはCoupaの経費レポートオブジェクトにおける主キーであり、通常、経費レポートAPIエンドポイントまたは基になるテーブルで「id」または「report-id」として見られます。例 ER-0012345ER-0012399ER-0013001
	ソースシステム SourceSystem	データが生成されたシステム。
説明この属性は、イベントデータが生成されたソースアプリケーションを識別します。この文脈では、「Coupa Expenses」となります。データガバナンスにとって重要であり、複数システムプロセスビューで異なるシステムからのデータを区別するために重要です。データの起源に関するコンテキストを提供し、複数のアプリケーションにまたがるプロセスを分析する際に重要になる可能性があります。その重要性データの発生源に関する重要なコンテキストを提供します。これは、データガバナンス、検証、および複数システムにまたがるプロセス分析にとって極めて重要です。取得元これは通常、データ抽出と変換の際に、データセットの起源をラベル付けするために追加される静的値です。例 Coupa ExpensesCoupa
	最終データ更新 LastDataUpdate	ソースシステムからの最終データ更新または抽出のタイムスタンプです。
説明この属性は、データがCoupa Expensesから最後に抽出され、プロセスマイニングツールにロードされた日時を記録します。これにより、分析対象データの鮮度が示されます。この情報は、ユーザーが分析の適時性を理解し、ダッシュボードが最新の業務状況を反映しているかどうかを知るために不可欠です。データガバナンスと分析結果への信頼を確保するための重要なメタデータです。その重要性データの鮮度をユーザーに伝え、分析の期間を理解し、その関連性を信頼できるようにします。取得元このタイムスタンプは通常、データ抽出またはETLツールによって、データロードが成功した時点で生成および保存されます。例 2024-05-21T02:00:00Z2024-05-22T02:00:00Z
	ポリシー違反フラグ PolicyViolationFlag	経費レポートがポリシー違反としてフラグ付けされた場合にtrueとなるブール値のインジケーターです。
説明 Coupaは、支出限度額の超過や未承認ベンダーの使用など、会社ポリシーに違反する経費を自動的にフラグ付けできます。この属性は、経費レポートでそのような違反が検出されたかどうかを示す単純なtrue/falseフラグです。このフラグは、コンプライアンスの監視と分析に不可欠です。これにより、時間経過や部門ごとのポリシー違反率を追跡するダッシュボードの作成が可能になります。また、ポリシー違反レポートが、コンプライアンスに準拠したレポートとどのように異なる処理を受けているか（例えば、承認に時間がかかったり、却下される頻度が高かったりするかどうか）を分析することもできます。その重要性ポリシーコンプライアンスの直接的な測定と分析を可能にし、高リスク領域や頻繁な非準拠領域を特定し対処するのに役立ちます。取得元これは通常、Coupaの経費レポートまたは個々の経費明細にフラグまたはステータスとして利用可能です。多くの場合、システムのルールエンジンによって設定されます。例 truefalse
	ユーザー名 UserName	アクティビティを実行した従業員またはユーザーの名前。
説明この属性は、経費レポートを提出、承認、または却下した人物など、特定のイベントに関連する個人を識別します。これは氏名、従業員ID、またはシステムユーザーアカウントである可能性があります。ユーザーごとのプロセス分析は、パフォーマンスパターン、ワークロードの分散、および潜在的なトレーニングニーズを特定するのに役立ちます。異なるマネージャー間の承認時間を比較するなど、リソース別にメトリクスを分解するダッシュボードにとって重要です。その重要性特定の個人に業務を割り当て、プロセス内のワークロード、パフォーマンス、リソース固有の行動を分析することを可能にします。取得元この情報は通常、Coupa Expensesの監査証跡テーブルで、各イベントまたはアクションにリンクされて利用可能です。「user-id」、「submitted-by」、「updated-by」などのフィールドを探してください。例 John Smithjsmith11023
	却下理由 RejectionReason	承認者によって経費レポートが却下された際に提供される理由。
説明マネージャーまたは財務チームのメンバーである承認者が経費精算レポートを却下する際、しばしば理由を付記します。この属性は、あらかじめ定義されたリストから、または自由形式のテキストとして、その理由を記録します。\n\nこれは根本原因分析にとって非常に価値のある属性です。最も一般的な却下理由を分析することで、組織はポリシーが不明確な領域、従業員がより多くのトレーニングを必要とする領域、または申請プロセスに欠陥がある領域を特定できます。これにより、手戻りの削減と初回承認率の向上に向けた取り組みが直接的に支援されます。その重要性手戻りが発生する理由を直接説明し、ターゲットを絞ったトレーニング、ポリシーの明確化、またはプロセス改善を通じて却下率を削減するための実用的な洞察を提供します。取得元この情報は通常、Coupaにおける却下イベントに関連する監査証跡またはコメントとして捕捉されます。専用のフィールドにあるか、コメントから解析される場合があります。例領収書が不足していますポリシー外の経費不適切な経費カテゴリ重複提出
	合計金額 TotalAmount	経費レポートの総額。
説明この属性は、レポートに含まれるすべての経費明細の合計額を表します。これは、プロセスを流れる価値を理解するための主要な財務指標です。合計金額を分析することで、経費レポートを異なる価値帯に分類するのに役立ち、それらは異なる承認経路や精査レベルを持つ可能性があります。ダッシュボードでは、支出パターンを分析し、ボトルネックを引き起こしている可能性のある高額レポートを特定し、レポート価値と処理時間や却下率を相関させるために使用されます。その重要性プロセスに財務的なコンテキストを提供し、経費レポートの金銭的価値に基づいた分析を可能にします。これはしばしば承認経路や処理の優先順位に影響を与えます。取得元これはCoupaの経費レポートヘッダーの標準フィールドで、通常「total」または「total-amount」という名前で表示されます。例 150.752500.0085.50
	従業員部門 EmployeeDepartment	経費レポートを提出した従業員の部門。
説明この属性は、経費レポート提出者が所属する組織部門または事業単位を指定します。この情報は通常、従業員マスターデータから派生します。これは分析にとって重要な側面であり、組織の異なる部分間でのプロセスパフォーマンスの比較を可能にします。部門ごとの承認時間、却下率、またはポリシー違反を分析するダッシュボードは、プロセス改善や対象を絞ったトレーニングが必要な領域を特定するために、この属性に大きく依存します。その重要性異なる部門間のパフォーマンス比較を可能にし、組織のどの部分が効率的で、どの部分がサポートを必要としているかを特定するのに役立ちます。取得元 Coupaの提出ユーザーのプロファイルから、またはユーザーIDを使用して外部HRマスターデータシステムと結合することで取得されます。ユーザーオブジェクト上の「department」フィールドを探してください。例営業マーケティングエンジニアリング財務
	終了日時 EndTime	アクティビティの完了時刻を示すタイムスタンプ。
説明終了時間はアクティビティの完了を示します。多くのトランザクションシステムでは、アクティビティは瞬間的なイベントであるため、終了時間は開始時間と同じになります。ただし、測定可能な期間を持つアクティビティの場合、この属性は完了時刻を捕捉します。このフィールドは、個々のアクティビティの正確な処理時間を計算するために不可欠です。プロセス内で時間がどこで費やされているかをより正確に分析することを可能にし、待機時間と実際の作業時間を区別するのに役立ちます。その重要性正確なアクティビティ期間の計算を可能にし、特定のタスクに費やされた時間と待機時間を特定・分析するために不可欠です。取得元これは、アトミックイベントの場合、開始時間（EventTime）と同じであることがよくあります。期間を要するアクティビティの場合、別のフィールドから取得するか、次のイベントのタイムスタンプに基づいて導出する必要がある場合があります。例 2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z
	経費レポートステータス ExpenseReportStatus	経費レポートの現在または最終ステータス。
説明この属性は、経費レポートのライフサイクル終了時における全体的な状態を示します。例えば「承認済み」、「支払い済み」、「却下済み」、「取り下げ済み」などです。これにより、各ケースの最終的な結果が提供されます。分析では、最終ステータスは完了したケースをフィルタリングし、結果を分類するために使用されます。却下率などのメトリクスを計算し、各可能な最終状態に到達するレポートの割合を理解するために不可欠です。また、中間ステータスで停滞しているレポートを特定するのにも役立ちます。その重要性各ケースの結果を定義し、承認済みレポートと却下済みレポートの経路比較など、結果に基づいた分析にとって不可欠です。取得元これはCoupaの経費レポートオブジェクトにおける主要なステータスフィールドです。ヘッダーデータで確認でき、プロセス全体を通じて更新されます。例 pending_approval承認済みpaidrejected
	アクティビティ処理時間 ActivityProcessingTime	個々のアクティビティの期間。終了時間と開始時間の差として計算されます。
説明このメトリクスは、単一のプロセスステップを実行するのに費やされた時間を測定します。アクティビティの終了時間から開始時間を引くことで計算されます。瞬間的なイベントの場合、この期間はゼロです。この計算された属性は、アクティブな処理時間と待機時間（アクティビティ間の時間）を区別するのに役立ちます。処理時間を分析することで、どの特定のタスクが最も時間のかかるものであるかを特定し、自動化またはタスク最適化の機会を示します。その重要性付加価値のある作業に費やされた時間を測定し、アイドル時間や待機時間と区別し、非効率なタスクを特定するのに役立ちます。取得元これはデータ変換中に「EndTime」から「EventTime」（StartTime）を引くことで計算されます。式：EndTime - StartTime。例 0864003600
	コストセンター CostCenter	経費が割り当てられるコストセンター。
説明コストセンターは、会計および予算編成に使用される財務次元であり、組織のどの部分が経費を負担するかを示します。これは提出者自身の部門とは異なる場合があります。コストセンターによる分析は、プロセスに関する財務会計ビューを提供します。特定の予算や財務単位に対して支出とプロセス効率を追跡できます。これは、組織の支出を理解し管理しようとしている財務部門にとって特に重要です。その重要性分析のための重要な財務的側面を提供し、プロセスメトリクスを財務および予算単位に直接リンクすることを可能にします。取得元これはCoupaの標準的な会計フィールドで、経費レポートのヘッダーまたは明細項目に記載されています。多くの場合、勘定科目構造の一部です。例 CC4510-マーケティングCC2100-エンジニアリングCC7800-セールス-東
	ポリシー違反理由 PolicyViolationReason	経費レポートがポリシー違反としてフラグ付けされた具体的な理由。
説明ポリシー違反が検出された場合、この属性は「金額が上限を超える」や「未承認の業者」といった具体的な違反理由を提供します。これは単なるブール値のフラグよりも詳細な情報です。\n\nポリシー違反の理由を分析することで、コンプライアンス問題のより詳細な理解が得られます。頻繁に破られる特定のポリシーを特定するのに役立ち、より良いコミュニケーション、ポリシーの調整、またはより厳格な実施の必要性を示唆する可能性があります。これは効果的なコンプライアンス改善戦略を策定するための鍵となります。その重要性コンプライアンス問題に関する具体的な詳細を提供し、会社の経費ポリシー順守を改善するためのターゲットを絞ったアクションを可能にします。取得元この情報は通常、Coupaのコンプライアンスエンジンによって生成されたポリシーフラグまたは警告メッセージの詳細で利用できます。例日次食費上限超過経費は重複しています領収書が必要です
	一次承認であるか IsFirstPassApproval	経費レポートが一度も却下や修正を受けることなく承認された場合にtrueとなるフラグです。
説明これは、経費レポートが最初の試行で承認プロセスを正常に通過したかどうかを示すケースレベルで計算されるブール属性です。ケースに却下または「改訂のために差し戻し」のアクティビティが含まれていない場合、「true」に設定されます。この属性は、提出および承認プロセスの効率を直接測定します。初回承認率KPIの基礎となります。部門や経費カテゴリなど、低い初回承認率と相関する要因を分析することで、プロセス改善のための貴重な洞察が得られます。その重要性プロセス品質と効率の明確な尺度を提供し、手戻りなしで処理されるレポートの割合を定量化するのに役立ちます。取得元これはケースレベルで計算されます。特定の`ExpenseReportId`のすべてのアクティビティをスキャンし、却下または修正イベントがないかを確認する必要があります。例 truefalse
	国 Country	提出した従業員または取引の国。
説明この属性は、経費レポートに関連する国を示します。これは通常、提出する従業員の居住国です。これはグローバル組織におけるプロセスを分析するための重要な側面です。国別にプロセスを分析することで、異なる地理的地域間でのパフォーマンス、コンプライアンス、およびプロセスバリエーションを比較するのに役立ちます。これにより、対処すべき規制、ポリシー、または運用効率における地域差を浮き彫りにすることができます。その重要性異なる地理的地域間でのプロセスパフォーマンスとコンプライアンスの比較を可能にし、グローバル企業にとって不可欠です。取得元これはCoupaのユーザープロファイル、または経費レポートに関連付けられた法人から導出できます。例米国DEUGBRJPN
	手戻り IsRework	アクティビティが手戻りループの一部であるかどうかを示すフラグ（例：レポートが修正のために差し戻された場合など）です。
説明この計算されたブール属性は、手戻りを表すアクティビティにフラグを立てます。通常、「改訂のために差し戻し」などのイベント、または同じケース内でそのようなイベントの後に発生する任意のアクティビティに対して「true」に設定されます。手戻りの特定は、プロセスマイニングの主要な目標です。このフラグは、直接フィルタリングと集計を可能にすることで、手戻りの分析を簡素化します。手戻り率の計算、プロセスマップでの手戻りループの可視化、およびプロセスがステップを繰り返すことを強制するアクティビティの根本原因の分析に使用されます。その重要性非効率的な手戻りループを直接フラグ付けし、その頻度、サイクルタイムへの影響、根本原因を容易に定量化できるようにします。取得元これはプロセスフローに基づいて計算されます。以前のプロセス段階への戻りを示すアクティビティ（例：「改訂のために差し戻し」）を特定するためにロジックを適用する必要があります。例 truefalse
	承認者名 ApproverName	経費レポートを承認または却下したマネージャーまたは財務担当者の名前。
説明この属性は、マネージャーまたは財務承認ステップに関与する特定の承認者を識別します。これはレポートを提出したユーザーとは異なります。このデータは、承認者のパフォーマンスと行動を分析するのに役立ちます。個々の承認者ごとの承認サイクル時間を測定でき、過負荷になっている、または追加トレーニングが必要な特定の個人によって引き起こされるボトルネックを特定するのに役立ちます。ワークロードのバランスを取り、承認効率を向上させることを目的としたダッシュボードをサポートします。その重要性承認チェーンのボトルネックを特定するのに役立ちます。遅延や高い却下率を特定の承認者に帰属させることで、ターゲットを絞った介入を可能にします。取得元 Coupaの経費レポートの承認履歴または監査証跡に記載されています。各承認ステップには、アクションを実行したユーザーの記録があるはずです。例サラ・チェンデビッド・ロドリゲス経理チームキュー
	経費カテゴリ ExpenseCategory	交通費、食費、事務用品などの経費カテゴリ。
説明この属性は、請求される経費の種類を分類します。経費レポートには、それぞれ独自のカテゴリを持つ複数の経費明細が含まれることがよくあります。ケースレベル分析の場合、これは最も頻繁なカテゴリまたは集計リストになる可能性があります。経費カテゴリ別にプロセスをセグメント化すると、異なる挙動やボトルネックが明らかになることがあります。例えば、旅費は事務用品の購入よりも複雑な承認経路をたどる可能性があります。この側面は、経費の性質がその処理プロセスにどのように影響するかを理解するための鍵となります。その重要性支出の種類に基づいてプロセスをセグメント化することができ、カテゴリ固有のボトルネック、ポリシー、または承認経路を明らかにすることが可能です。取得元この情報はCoupaの経費明細レベルで保存されています。ケースレベル分析の場合、例えば最高額明細のカテゴリを取得するなどして集計する必要があります。例航空運賃交際費・接待費ソフトウェアオフィス用品
	通貨 Currency	経費レポートの合計金額の通貨コード。
説明この属性は、経費レポートの合計金額がどの通貨（USD、EUR、GBPなど）で表示されているかを指定します。これはあらゆる財務データにとって不可欠なコンテキストです。グローバル組織の経費を分析する場合、このフィールドは金銭的価値の正確な解釈と集計のために重要です。異なる地域間での意味のある比較を行うためには、すべての金額を単一の基準通貨に変換する必要がある場合があります。その重要性金銭的価値に必要なコンテキストを提供し、正確な財務分析を保証し、グローバルレポートのための通貨換算を可能にします。取得元これはCoupaの経費レポートヘッダーの標準フィールドで、通常、合計金額フィールドとともに「currency-code」のような名前で表示されます。例 USDEURGBPJPY

必須推奨任意

経費精算アクティビティ

これらは、経費ワークフローの正確な発見と分析のために、イベントログにキャプチャすべき主要なプロセスステップとマイルストーンです。

6 推奨 7 任意

	アクティビティ	説明
	マネージャー承認	従業員の直属のマネージャーまたは一次承認者が経費レポートを承認します。これは、レポートの承認履歴にタイムスタンプとともに明示的なイベントとして記録されます。
その重要性最初の承認レベルの完了を示します。このイベントまでの時間を分析することは、承認サイクルタイムのKPIとマネージャーレベルのボトルネック特定に重要です。取得元 Coupaの経費レポートに関する詳細な承認履歴または監査証跡における承認アクションのタイムスタンプから取得されます。取得経費レポートの承認履歴ログにある承認イベントタイムスタンプから。イベントタイプ explicit
	会計計上済み	経費レポートに関連する財務取引が総勘定元帳に転記されます。これは、財務会計の観点からのプロセスの最終ステップを表します。
その重要性これは最終アクティビティであり、プロセスの真の終わりを示します。精算から記帳までの時間は、迅速かつ正確な決算にとって重要です。取得元このイベントは、経費レポートに関連する仕訳または会計明細の記帳日から捕捉されます。これらはCoupaの会計統合によって管理されます。取得経費レポートに関連する会計明細の記帳日付フィールドから。イベントタイプ explicit
	精算実行済み	支払いが正常に処理され、資金が従業員に支払われます。このイベントは、従業員への支払いが完了し、精算プロセスの一部が完了したことを確認します。
その重要性これは従業員満足度にとって重要なマイルストーンであり、「平均精算リードタイム」KPIの終点です。取得元経費レポートに関連付けられた支払いレコードの支払い実行日から取得されます。通常、Coupa Payまたは統合されたAPシステム内で行われます。取得経費レポートにリンクされた関連する支払いレコードの支払い日から。イベントタイプ explicit
	経費レポート作成済み	経費レポートのライフサイクルの始まりを示します。このイベントは、ユーザーが新しい経費レポートを初めて作成および保存し、ドラフト状態にしたときに捕捉されます。
その重要性これはすべてのプロセス分析の出発点であり、経費レポートのエンドツーエンドの総サイクル時間を測定するために不可欠です。取得元これは、Coupaの経費レポートヘッダーレコードの作成タイムスタンプから取得される明示的なイベントです。経費ヘッダーテーブルの「created_at」タイムスタンプがソースです。取得経費精算レポートオブジェクトの作成タイムスタンプを使用します。イベントタイプ explicit
	経費レポート提出済み	従業員は完成した経費レポートを承認のために正式に提出します。このアクションにより、レポートはドラフト状態から承認待ち状態に移行し、システムによって明示的に記録されます。
その重要性これは承認時間のカウントを開始する重要なマイルストーンです。作成から提出までの期間は、従業員がレポート作成にどれくらいの時間を要するかを示します。取得元経費レポート記録自体の提出タイムスタンプ、または提出イベントの監査証跡ログエントリから取得されます。取得経費精算レポートの「submitted_at」タイムスタンプフィールドを使用します。イベントタイプ explicit
	財務承認済み	財務または監査チームが経費レポートの最終承認を行います。このイベントは、レポートが検証され、支払い処理の準備が整ったことを示し、承認履歴に記録されます。
その重要性これは最終承認のマイルストーンです。マネージャー承認から財務承認までの時間は、全体的な承認サイクルにおける主要な要素です。取得元経費レポートの詳細な承認履歴または監査証跡における最終承認アクションのタイムスタンプから取得されます。取得経費レポートの承認履歴にある最終承認イベントタイムスタンプから。イベントタイプ explicit
	ポリシーチェック実施済み	会社の経費ポリシーへの準拠を自動で確認するチェックが実行されます。これは通常、ポリシー違反フラグまたは警告がレポートに初めて設定されたタイムスタンプから推測されます。
その重要性ポリシーコンプライアンス概要ダッシュボードに不可欠です。プロセス内で違反がいつ検出されるか、そしてそれが承認時間に与える影響を理解するのに役立ちます。取得元経費明細またはレポートヘッダーにポリシー違反フラグが適用されたタイムスタンプから推測されます。取得経費レポートまたはその明細にポリシー違反フラグが最初に設定されたタイムスタンプ。イベントタイプ inferred
	マネージャー却下	従業員のマネージャーは経費レポートを却下します。これは多くの場合プロセスを停止させ、レポートを従業員に差し戻します。これは承認履歴の特定のイベントとして捕捉されます。
その重要性これはプロセス摩擦を浮き彫りにする負の結果です。これらのイベントを分析することは、経費レポート却下率ダッシュボードとKPIにとって非常に重要です。取得元経費レポートの承認履歴または監査証跡における却下アクションのタイムスタンプから取得されます。取得経費レポートの承認履歴ログにある却下イベントのタイムスタンプから。イベントタイプ explicit
	改訂のために差し戻し	承認者が最終的な却下を出さずに、修正のためにレポートを従業員に差し戻します。このアクションは手戻りループを作成し、ステータス変更または特定の監査証跡イベントから推測されます。
その重要性このアクティビティは、手戻りループを分析するための基礎となります。レポートが差し戻される理由を特定することは、トレーニングと初回承認率の向上に役立ちます。取得元「修正保留中」や「差し戻し」などのステータス変更から推測されます。Coupaは、このアクションを承認履歴に明示的に記録することもあります。取得「改訂が必要」状態へのステータス変更のタイムスタンプ、または監査ログからの特定のイベント。イベントタイプ inferred
	精算スケジュール済み	最終承認後、経費レポートは支払いバッチにまとめられ、支払われます。これは承認フェーズから支払い処理フェーズへの移行を示します。
その重要性このアクティビティは、精算実行サイクル時間の計測を開始します。ここでの遅延は、承認済みレポートを支払いシステムに移行する際のバックログを示します。取得元「支払い保留中」へのステータス変更、またはCoupa Payの支払いバッチ記録に関連付けられた日付から推測されます。取得ステータスが「支払い保留中」に変更されたタイムスタンプ、または関連する支払いバッチの作成日。イベントタイプ inferred
	経費レポート取り下げ済み	従業員は、完全に承認される前に提出済みの経費レポートを取り下げます。このアクションは現在の承認プロセスをキャンセルし、明示的なイベントとして捕捉されます。
その重要性従業員が自己修正したり、申請をキャンセルしたりするケースを追跡します。これはプロセスに対する混乱を示している可能性があります。プロセスの中断の一種です。取得元明示的なユーザーアクションから取得され、「取り下げ済み」または「キャンセル済み」のステータスになり、監査証跡に記録されます。取得経費レポートの監査証跡における「取り下げ」アクションのタイムスタンプから。イベントタイプ explicit
	財務却下済み	財務または監査チームは経費レポートを却下します。これは最終的な負の結果であり、レポートの履歴に最終却下ステータスとして記録されます。
その重要性財務却下を追跡することで、以前のレビューで見落とされた可能性のある重大なコンプライアンスまたは文書化の問題を特定し、却下率KPIに影響を与えるのに役立ちます。取得元経費レポートの監査証跡における財務承認者による却下アクションのタイムスタンプから取得されます。取得財務審査ステップ中の監査証跡における却下イベントのタイムスタンプから。イベントタイプ explicit
	領収書添付済み	レポート内の経費明細に領収書をアップロードまたは添付するユーザーアクションを表します。これは、経費レポートにリンクされた添付ファイル記録の作成を監視することで捕捉されます。
その重要性このアクティビティのタイミングと頻度を分析することで、ユーザー行動パターンや書類不足による潜在的な遅延を明らかにすることができます。取得元特定の経費レポートIDにリンクされた添付ファイル記録の作成タイムスタンプから推測されます。取得添付ファイルレコードが経費レポートにリンクされたタイムスタンプを識別します。イベントタイプ inferred

推奨任意

抽出ガイド

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

ステップ

前提条件: Coupaのユーザーアカウントがあり、スケジュール済みエクスポートにアクセスして設定するために必要な権限（通常は管理者または統合スペシャリストのロール）を持っていることを確認してください。また、Coupaがエクスポートファイルを配置できるSFTPサーバーへのアクセスも必要です。
スケジュール済みエクスポートへの移動: Coupaインスタンスにログインします。設定メニューに移動し、「統合」セクションの下にある「スケジュール済みエクスポート」をクリックします。
経費レポートエクスポートの設定: 「作成」ボタンをクリックします。「経費レポート」オブジェクトの最初のエクスポートを設定します。「ProcessMind_Expense_Reports」のようなわかりやすい名前を付けます。フォーマットは「CSV」を選択します。「フィールド」セクションでは、ID、作成日時、提出日時、更新日時、ステータス、合計、ユーザーID、その他関連するレポートレベルの属性などの列を選択します。
承認履歴エクスポートの設定: 「経費レポート承認」オブジェクトの2番目のスケジュール済みエクスポートを作成します。「ProcessMind_Expense_Approvals」と名付けます。ID、作成日時、更新日時、ステータス、承認者ID、経費レポートIDなどのフィールドを含めます。このオブジェクトは、承認、却下、修正のイベントをキャプチャするために不可欠です。
添付ファイルエクスポートの設定: 「経費レポート添付ファイル」オブジェクトの3番目のエクスポートを作成し、「ProcessMind_Expense_Attachments」と名付けます。作成日時タイムスタンプと、領収書が追加された時期を追跡するための関連する経費レポートIDまたは経費明細IDを含めます。
支払い用請求書エクスポートの設定: 「経費レポートからの請求書」オブジェクトの4番目のエクスポートを作成します。「ProcessMind_Expense_Invoices」と名付けます。これは、精算および会計イベントを追跡するために必要です。経費レポートID、支払い日、スケジュールされた支払い日、エクスポート済み、更新日時などのフィールドを含めます。
配信とスケジュールの設定: 作成した各エクスポートについて、「配信」タブに移動します。ホスト、ユーザー名、ディレクトリパスを含むSFTPサーバーの接続詳細を入力します。認証方法（通常はパスワードまたはキーベース）を設定します。「スケジュール」タブで、頻度を「毎日」に設定し、定期的な更新を取得します。
エクスポートの実行と取り込み: スケジュールを有効にし、必要に応じて初回を手動で実行します。SFTPサーバーからCSVファイルを取得し、ステージングデータベースにロードするための自動化プロセス（ETLスクリプトやデータウェアハウス取り込みツールなど）を設定します。
データをイベントログに変換: 提供されているSQLクエリのような変換スクリプトを、ステージングデータに対して実行します。このスクリプトは、異なるテーブル（レポート、承認、請求書）からのデータを結合し、単一の統合されたイベントログテーブルを作成します。
ProcessMind向けのエクスポート: データベースまたはデータウェアハウスから、結果のイベントログテーブルを単一のCSVファイルにエクスポートします。ExpenseReportId、ActivityName、EventTimeなどの必須属性と列ヘッダーが一致していることを確認してください。これで、ファイルはプロセスマイニングツールへのアップロード準備が整いました。

設定

前提条件: アクティブなCoupa Expensesモジュールが必要です。エクスポートを設定するユーザーは、「スケジュール済みCSVエクスポート」の権限を持つロールを持っている必要があります。SFTPサーバーが利用可能であり、必要に応じてそのIPアドレスがホワイトリストに登録されている必要があります。
主要なCoupaオブジェクト: 抽出は、いくつかの標準的なCoupaデータオブジェクト（「経費レポート」、「経費レポート承認」、「経費レポート添付ファイル」、「経費レポートからの請求書」）のスケジュール済みエクスポートに依存しています。
SFTP設定: SFTPサーバーのURL、ポート（通常22）、専用のユーザー資格情報、およびファイルの保存先ディレクトリを提供する必要があります。Coupa UI内で接続が正常にテストされていることを確認してください。
日付範囲とフィルタリング: スケジュール済みエクスポートは通常、前回の成功した実行以降に作成または更新されたレコードをエクスポートするように構成されます。最初の履歴データロードの場合、過去6〜12ヶ月など、目的の期間をカバーする特定の「作成日時」または「更新日時」の範囲を設定できます。
ファイル形式: シンプルさとデータ処理ツールとの幅広い互換性のため、常にCSVをファイル形式として使用してください。
スケジュール頻度: プロセスマイニングにおいては、プロセスデータを常に最新の状態に保つため、日次エクスポートスケジュールを推奨します。オフピーク時間帯に実行することで、潜在的なパフォーマンスへの影響を最小限に抑えることができます。

a クエリ例 config

WITH last_update AS (
  SELECT CURRENT_TIMESTAMP AS last_data_update
)
SELECT
  er.id AS ExpenseReportId,
  'Expense Report Created' AS ActivityName,
  er."created-at" AS EventTime,
  er."updated-at" AS EndTime,
  u.full_name AS UserName,
  u.department_name AS EmployeeDepartment,
  er.total AS TotalAmount,
  er.status AS ExpenseReportStatus,
  NULL AS RejectionReason,
  er.has_policy_violations AS PolicyViolationFlag,
  'Coupa' AS SourceSystem,
  lu.last_data_update AS LastDataUpdate
FROM stg_expense_reports er
LEFT JOIN stg_users u ON er.user_id = u.id
CROSS JOIN last_update lu

UNION ALL

SELECT
  er.id AS ExpenseReportId,
  'Receipts Attached' AS ActivityName,
  att."created-at" AS EventTime,
  att."updated-at" AS EndTime,
  u.full_name AS UserName,
  u.department_name AS EmployeeDepartment,
  er.total AS TotalAmount,
  er.status AS ExpenseReportStatus,
  NULL AS RejectionReason,
  er.has_policy_violations AS PolicyViolationFlag,
  'Coupa' AS SourceSystem,
  lu.last_data_update AS LastDataUpdate
FROM stg_expense_report_attachments att
JOIN stg_expense_reports er ON att.expense_report_id = er.id
LEFT JOIN stg_users u ON er.user_id = u.id
CROSS JOIN last_update lu

UNION ALL

SELECT
  er.id AS ExpenseReportId,
  'Expense Report Submitted' AS ActivityName,
  er."submitted-at" AS EventTime,
  er."updated-at" AS EndTime,
  u.full_name AS UserName,
  u.department_name AS EmployeeDepartment,
  er.total AS TotalAmount,
  er.status AS ExpenseReportStatus,
  NULL AS RejectionReason,
  er.has_policy_violations AS PolicyViolationFlag,
  'Coupa' AS SourceSystem,
  lu.last_data_update AS LastDataUpdate
FROM stg_expense_reports er
LEFT JOIN stg_users u ON er.user_id = u.id
CROSS JOIN last_update lu
WHERE er."submitted-at" IS NOT NULL

UNION ALL

SELECT
  era.expense_report_id AS ExpenseReportId,
  'Manager Approved' AS ActivityName,
  era."updated-at" AS EventTime,
  era."updated-at" AS EndTime,
  approver.full_name AS UserName,
  u.department_name AS EmployeeDepartment,
  er.total AS TotalAmount,
  er.status AS ExpenseReportStatus,
  NULL AS RejectionReason,
  er.has_policy_violations AS PolicyViolationFlag,
  'Coupa' AS SourceSystem,
  lu.last_data_update AS LastDataUpdate
FROM stg_expense_report_approvals era
JOIN stg_expense_reports er ON era.expense_report_id = er.id
LEFT JOIN stg_users u ON er.user_id = u.id
LEFT JOIN stg_users approver ON era.approver_id = approver.id
CROSS JOIN last_update lu
WHERE era.status = 'approved' AND approver.role LIKE '%Manager%'

UNION ALL

SELECT
  era.expense_report_id AS ExpenseReportId,
  'Manager Rejected' AS ActivityName,
  era."updated-at" AS EventTime,
  era."updated-at" AS EndTime,
  approver.full_name AS UserName,
  u.department_name AS EmployeeDepartment,
  er.total AS TotalAmount,
  er.status AS ExpenseReportStatus,
  era.reason AS RejectionReason,
  er.has_policy_violations AS PolicyViolationFlag,
  'Coupa' AS SourceSystem,
  lu.last_data_update AS LastDataUpdate
FROM stg_expense_report_approvals era
JOIN stg_expense_reports er ON era.expense_report_id = er.id
LEFT JOIN stg_users u ON er.user_id = u.id
LEFT JOIN stg_users approver ON era.approver_id = approver.id
CROSS JOIN last_update lu
WHERE era.status = 'rejected' AND approver.role LIKE '%Manager%'

UNION ALL

SELECT
  era.expense_report_id AS ExpenseReportId,
  'Sent Back For Revision' AS ActivityName,
  era."updated-at" AS EventTime,
  era."updated-at" AS EndTime,
  approver.full_name AS UserName,
  u.department_name AS EmployeeDepartment,
  er.total AS TotalAmount,
  er.status AS ExpenseReportStatus,
  era.reason AS RejectionReason,
  er.has_policy_violations AS PolicyViolationFlag,
  'Coupa' AS SourceSystem,
  lu.last_data_update AS LastDataUpdate
FROM stg_expense_report_approvals era
JOIN stg_expense_reports er ON era.expense_report_id = er.id
LEFT JOIN stg_users u ON er.user_id = u.id
LEFT JOIN stg_users approver ON era.approver_id = approver.id
CROSS JOIN last_update lu
WHERE era.status = 'sent_back'

UNION ALL

SELECT
  er.id AS ExpenseReportId,
  'Policy Check Performed' AS ActivityName,
  er."updated-at" AS EventTime,
  er."updated-at" AS EndTime,
  'System' AS UserName,
  u.department_name AS EmployeeDepartment,
  er.total AS TotalAmount,
  er.status AS ExpenseReportStatus,
  NULL AS RejectionReason,
  er.has_policy_violations AS PolicyViolationFlag,
  'Coupa' AS SourceSystem,
  lu.last_data_update AS LastDataUpdate
FROM stg_expense_reports er
LEFT JOIN stg_users u ON er.user_id = u.id
CROSS JOIN last_update lu
WHERE er.has_policy_violations = TRUE

UNION ALL

SELECT
  era.expense_report_id AS ExpenseReportId,
  'Finance Approved' AS ActivityName,
  era."updated-at" AS EventTime,
  era."updated-at" AS EndTime,
  approver.full_name AS UserName,
  u.department_name AS EmployeeDepartment,
  er.total AS TotalAmount,
  er.status AS ExpenseReportStatus,
  NULL AS RejectionReason,
  er.has_policy_violations AS PolicyViolationFlag,
  'Coupa' AS SourceSystem,
  lu.last_data_update AS LastDataUpdate
FROM stg_expense_report_approvals era
JOIN stg_expense_reports er ON era.expense_report_id = er.id
LEFT JOIN stg_users u ON er.user_id = u.id
LEFT JOIN stg_users approver ON era.approver_id = approver.id
CROSS JOIN last_update lu
WHERE era.status = 'approved' AND approver.role LIKE '%Finance%'

UNION ALL

SELECT
  era.expense_report_id AS ExpenseReportId,
  'Finance Rejected' AS ActivityName,
  era."updated-at" AS EventTime,
  era."updated-at" AS EndTime,
  approver.full_name AS UserName,
  u.department_name AS EmployeeDepartment,
  er.total AS TotalAmount,
  er.status AS ExpenseReportStatus,
  era.reason AS RejectionReason,
  er.has_policy_violations AS PolicyViolationFlag,
  'Coupa' AS SourceSystem,
  lu.last_data_update AS LastDataUpdate
FROM stg_expense_report_approvals era
JOIN stg_expense_reports er ON era.expense_report_id = er.id
LEFT JOIN stg_users u ON er.user_id = u.id
LEFT JOIN stg_users approver ON era.approver_id = approver.id
CROSS JOIN last_update lu
WHERE era.status = 'rejected' AND approver.role LIKE '%Finance%'

UNION ALL

SELECT
  er.id AS ExpenseReportId,
  'Expense Report Withdrawn' AS ActivityName,
  er."updated-at" AS EventTime,
  er."updated-at" AS EndTime,
  u.full_name AS UserName,
  u.department_name AS EmployeeDepartment,
  er.total AS TotalAmount,
  er.status AS ExpenseReportStatus,
  NULL AS RejectionReason,
  er.has_policy_violations AS PolicyViolationFlag,
  'Coupa' AS SourceSystem,
  lu.last_data_update AS LastDataUpdate
FROM stg_expense_reports er
LEFT JOIN stg_users u ON er.user_id = u.id
CROSS JOIN last_update lu
WHERE er.status = 'withdrawn'

UNION ALL

SELECT
  inv.expense_report_id AS ExpenseReportId,
  'Reimbursement Scheduled' AS ActivityName,
  inv.scheduled_payment_date AS EventTime,
  inv.updated_at AS EndTime,
  'System' AS UserName,
  u.department_name AS EmployeeDepartment,
  er.total AS TotalAmount,
  er.status AS ExpenseReportStatus,
  NULL AS RejectionReason,
  er.has_policy_violations AS PolicyViolationFlag,
  'Coupa' AS SourceSystem,
  lu.last_data_update AS LastDataUpdate
FROM stg_invoices_from_expense_reports inv
JOIN stg_expense_reports er ON inv.expense_report_id = er.id
LEFT JOIN stg_users u ON er.user_id = u.id
CROSS JOIN last_update lu
WHERE inv.scheduled_payment_date IS NOT NULL

UNION ALL

SELECT
  inv.expense_report_id AS ExpenseReportId,
  'Reimbursement Executed' AS ActivityName,
  inv.paid_date AS EventTime,
  inv.updated_at AS EndTime,
  'System' AS UserName,
  u.department_name AS EmployeeDepartment,
  er.total AS TotalAmount,
  er.status AS ExpenseReportStatus,
  NULL AS RejectionReason,
  er.has_policy_violations AS PolicyViolationFlag,
  'Coupa' AS SourceSystem,
  lu.last_data_update AS LastDataUpdate
FROM stg_invoices_from_expense_reports inv
JOIN stg_expense_reports er ON inv.expense_report_id = er.id
LEFT JOIN stg_users u ON er.user_id = u.id
CROSS JOIN last_update lu
WHERE inv.paid_date IS NOT NULL

UNION ALL

SELECT
  inv.expense_report_id AS ExpenseReportId,
  'Accounting Posted' AS ActivityName,
  inv.updated_at AS EventTime,
  inv.updated_at AS EndTime,
  'System' AS UserName,
  u.department_name AS EmployeeDepartment,
  er.total AS TotalAmount,
  er.status AS ExpenseReportStatus,
  NULL AS RejectionReason,
  er.has_policy_violations AS PolicyViolationFlag,
  'Coupa' AS SourceSystem,
  lu.last_data_update AS LastDataUpdate
FROM stg_invoices_from_expense_reports inv
JOIN stg_expense_reports er ON inv.expense_report_id = er.id
LEFT JOIN stg_users u ON er.user_id = u.id
CROSS JOIN last_update lu
WHERE inv.exported = TRUE;

ステップ

前提条件と環境設定: Python 3.6以降がインストールされていることを確認してください。データ操作用のpandasとAPI呼び出し用のrequestsといった必要なライブラリを、ターミナルでpip install pandas requestsを実行してインストールします。また、Coupa管理者から、経費レポート、経費明細、添付ファイル、承認に対する読み取り権限を持つAPIキーを取得する必要があります。
Coupa APIキーの生成: Coupaインスタンスにログインします。設定 > 会社設定 > APIキーに移動します。新しいAPIキーを作成し、必要な経費モジュールに対する読み取り権限があることを確認します。このキーは会社のデータへのアクセスを提供するものなので、安全に保管してください。
Pythonスクリプトの初期化: 新しいPythonファイルを作成します。まず、必要なライブラリ（requests、pandas、datetime）をインポートします。CoupaインスタンスのURL（例：https://[your_company].coupahost.com）、APIキー、API認証に必要なヘッダーをグローバル定数として定義します。
日付範囲とAPIパラメータの定義: データ抽出期間の開始日と終了日を指定します。これらはAPI呼び出しでデータ量を制限するためのフィルターとして使用されます。また、Coupaでは通常1リクエストあたり50レコードであるページネーション制限を定義します。
経費レポートヘッダーの取得: 指定された日付範囲内のすべての経費レポートヘッダーを取得する関数を実装します。この関数は、/api/expense_reportsエンドポイントへの繰り返し呼び出しを行い、すべてのレポートが取得されるまでoffsetパラメータを増分することで、ページネーションを処理する必要があります。これらのレポートヘッダーをリストに保存します。
反復処理と詳細データの取得: 前のステップで取得した各経費レポートヘッダーをループ処理します。各レポートについて、その関連詳細（/api/expense_reports/{id}/approvalsからの承認、/api/expense_reports/{id}/attachmentsからの添付ファイル）を取得するために個別のAPIコールを行います。これらの詳細は、完全なイベントログを構築するために不可欠です。
イベントログの構築: イベントログレコードを保持するための空のリストを初期化します。各経費レポートとその詳細データを処理しながら、生のAPIレスポンスを標準化されたイベントログ行に変換します。必要な13のアクティビティそれぞれについて、単一のイベントを表す辞書を作成し、リストに追加します。例えば、「経費レポート作成済み」イベントにはcreated-atフィールドを使用し、承認データをループして「マネージャー承認済み」または「財務却下済み」イベントを作成します。
APIデータを属性にマッピング: 変換ロジックでは、Coupa APIレスポンスからのJSONフィールドを必須および推奨される属性にマッピングします。例えば、idをExpenseReportIdに、created-atをEventTimeに、totalをTotalAmountにマッピングします。ネストされたユーザーオブジェクトからユーザーと部門の情報を抽出します。
推論イベントの処理: 「精算スケジュール済み」や「会計記帳済み」のような一部のアクティビティは、ステータス変更から推論されます。レポートのstatusフィールドとupdated-atタイムスタンプを使用してこれらのイベントを生成します。例えば、ステータスが「processing_payment」に変更された場合、「精算スケジュール済み」アクティビティとしてログに記録できます。
データフレームの作成とエクスポート: すべての経費レポートを処理し、イベントのリストを作成したら、このリストをpandasのDataFrameに変換します。SourceSystemやLastDataUpdateなどの静的列を追加します。最後に、to_csvメソッドを使用してDataFrameをCSVファイルにエクスポートし、indexがFalseに設定されていることを確認します。このCSVファイルは、ProcessMindにアップロードする準備が整いました。

設定

APIキーの権限: 認証に使用されるAPIキーは、以下のCoupaオブジェクトに対して少なくとも読み取り専用アクセス権を持っている必要があります：経費レポート、経費明細、ユーザー、承認、添付ファイル。
CoupaインスタンスURL: 貴社のCoupaインスタンスのベースURL（例：https://your-company.coupahost.com）を提供する必要があります。これはすべてのAPIエンドポイントコールのルートとなります。
日付範囲フィルター: パフォーマンスとデータ量を管理するために、特定の期間でデータをフィルタリングすることが重要です。created-at[gt]（より大きい）およびcreated-at[lt]（より小さい）クエリパラメータを使用してください。一般的な開始範囲は3〜6ヶ月間のデータです。
ページネーション制限: Coupa APIは、1回のリクエストで返されるレコード数を通常50件に制限しています。スクリプトは、このlimitを処理し、offsetパラメータを使用してすべての後続ページデータを取得するように構成する必要があります。
ステータスフィルター: 抽出範囲をさらに絞り込むために、経費レポートヘッダーの初期クエリにstatusフィルターを追加できます。例えば、「承認済み」、「支払い済み」、または「却下済み」のステータスを持つレポートのみを抽出することができます。
パフォーマンスに関する考慮事項: スクリプトは各経費レポートに対して複数のAPIコールを実行します。数万件のレポートがあるインスタンスの場合、抽出には時間がかかることがあります。オフピーク時にスクリプトを実行するか、updated-atタイムスタンプに基づいた増分ロード戦略を実装することを検討してください。

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 Coupa instance URL and API Key
COUPA_URL = class="hl-string">"https://[your_company].coupahost.com"
API_KEY = class="hl-string">"[your_api_key]"

class=class="hl-string">"hl-comment"># Define the date range for the extraction
class=class="hl-string">"hl-comment"># Format: YYYY-MM-DDTHH:MM:SSZ (UTC)
START_DATE = class="hl-string">"2023-01-01T00:00:00Z"
END_DATE = class="hl-string">"2023-12-31T23:59:59Z"

class=class="hl-string">"hl-comment"># API request headers
HEADERS = {
    class="hl-string">"Accept": class="hl-string">"application/json",
    class="hl-string">"X-COUPA-API-KEY": API_KEY
}

class=class="hl-string">"hl-comment"># Static values for the event log
SOURCE_SYSTEM = class="hl-string">"Coupa Expenses"
LAST_DATA_UPDATE = datetime.datetime.utcnow().isoformat() + class="hl-string">'Z'

def get_paginated_data(endpoint, params):
    class="hl-string">"""Helper function to fetch all pages for a given API endpoint."""
    all_data = []
    offset = 0
    limit = 50
    while True:
        params[class="hl-string">'offset'] = offset
        params[class="hl-string">'limit'] = limit
        try:
            response = requests.get(endpoint, headers=HEADERS, params=params)
            response.raise_for_status() class=class="hl-string">"hl-comment"># Raises an HTTPError for bad responses (4xx or 5xx)
            data = response.json()
            if not data:
                break
            all_data.extend(data)
            offset += limit
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Error fetching data from {endpoint}: {e}")
            break
    return all_data

def main():
    class="hl-string">"""Main function to extract, transform, and save expense data."""
    print(class="hl-string">"Starting expense report extraction...")
    event_log = []

    class=class="hl-string">"hl-comment"># 1. Fetch all expense report headers in the date range
    reports_endpoint = fclass="hl-string">"{COUPA_URL}/api/expense_reports"
    reports_params = {
        class="hl-string">"created-at[gt]": START_DATE,
        class="hl-string">"created-at[lt]": END_DATE,
        class="hl-string">"fields": class="hl-string">"["idclass="hl-string">", "created-atclass="hl-string">", "updated-atclass="hl-string">", "submitted-atclass="hl-string">", "withdrawn-atclass="hl-string">", "statusclass="hl-string">", "totalclass="hl-string">", "userclass="hl-string">", "exportedclass="hl-string">", "expense-linesclass="hl-string">", "policy-violationsclass="hl-string">"]"
    }
    expense_reports = get_paginated_data(reports_endpoint, reports_params)

    print(fclass="hl-string">"Found {len(expense_reports)} expense reports to process.")

    class=class="hl-string">"hl-comment"># 2. Process each expense report to create events
    for i, report in enumerate(expense_reports):
        print(fclass="hl-string">"Processing report {i+1}/{len(expense_reports)}: ID {report['id']}")
        
        class=class="hl-string">"hl-comment"># Common attributes for all events of this case
        base_event = {
            class="hl-string">'ExpenseReportId': report[class="hl-string">'id'],
            class="hl-string">'TotalAmount': float(report.get(class="hl-string">'total', 0.0)),
            class="hl-string">'ExpenseReportStatus': report.get(class="hl-string">'status'),
            class="hl-string">'EmployeeDepartment': report.get(class="hl-string">'user', {}).get(class="hl-string">'department', {}).get(class="hl-string">'name') if report.get(class="hl-string">'user', {}).get(class="hl-string">'department') else None,
            class="hl-string">'SourceSystem': SOURCE_SYSTEM,
            class="hl-string">'LastDataUpdate': LAST_DATA_UPDATE,
            class="hl-string">'EndTime': None, class=class="hl-string">"hl-comment"># EndTime can be populated if duration is meaningful
            class="hl-string">'RejectionReason': None, class=class="hl-string">"hl-comment"># Will be populated by rejection events
            class="hl-string">'PolicyViolationFlag': bool(report.get(class="hl-string">'policy-violations'))
        }

        class=class="hl-string">"hl-comment"># Event: Expense Report Created
        event_log.append({
            **base_event,
            class="hl-string">'ActivityName': class="hl-string">'Expense Report Created',
            class="hl-string">'EventTime': report[class="hl-string">'created-at'],
            class="hl-string">'UserName': report.get(class="hl-string">'user', {}).get(class="hl-string">'fullname')
        })
        
        class=class="hl-string">"hl-comment"># Event: Expense Report Submitted
        if report.get(class="hl-string">'submitted-at'):
            event_log.append({
                **base_event,
                class="hl-string">'ActivityName': class="hl-string">'Expense Report Submitted',
                class="hl-string">'EventTime': report[class="hl-string">'submitted-at'],
                class="hl-string">'UserName': report.get(class="hl-string">'user', {}).get(class="hl-string">'fullname')
            })

        class=class="hl-string">"hl-comment"># Event: Expense Report Withdrawn
        if report.get(class="hl-string">'withdrawn-at'):
            event_log.append({
                **base_event,
                class="hl-string">'ActivityName': class="hl-string">'Expense Report Withdrawn',
                class="hl-string">'EventTime': report[class="hl-string">'withdrawn-at'],
                class="hl-string">'UserName': report.get(class="hl-string">'user', {}).get(class="hl-string">'fullname')
            })
        
        class=class="hl-string">"hl-comment"># Event: Policy Check Performed (inferred)
        if base_event[class="hl-string">'PolicyViolationFlag']:
             event_log.append({
                **base_event,
                class="hl-string">'ActivityName': class="hl-string">'Policy Check Performed',
                class="hl-string">'EventTime': report[class="hl-string">'updated-at'], class=class="hl-string">"hl-comment"># Using updated-at as a proxy timestamp
                class="hl-string">'UserName': class="hl-string">'System'
            })

        class=class="hl-string">"hl-comment"># 3. Fetch attachments for class="hl-string">'Receipts Attached' event
        attachments_endpoint = fclass="hl-string">"{COUPA_URL}/api/expense_reports/{report['id']}/attachments"
        attachments = get_paginated_data(attachments_endpoint, {})
        if attachments:
            first_attachment_time = min(att[class="hl-string">'created-at'] for att in attachments if class="hl-string">'created-at' in att)
            event_log.append({
                **base_event,
                class="hl-string">'ActivityName': class="hl-string">'Receipts Attached',
                class="hl-string">'EventTime': first_attachment_time,
                class="hl-string">'UserName': report.get(class="hl-string">'user', {}).get(class="hl-string">'fullname')
            })

        class=class="hl-string">"hl-comment"># 4. Fetch approvals for approval/rejection events
        approvals_endpoint = fclass="hl-string">"{COUPA_URL}/api/expense_reports/{report['id']}/approvals"
        approvals = get_paginated_data(approvals_endpoint, {})
        
        is_first_approval = True
        for approval in sorted(approvals, key=lambda x: x[class="hl-string">'updated-at']):
            activity = None
            rejection_reason = approval.get(class="hl-string">'reason')
            
            if approval[class="hl-string">'status'] == class="hl-string">'approved':
                activity = class="hl-string">'Manager Approved' if is_first_approval else class="hl-string">'Finance Approved'
                is_first_approval = False
            elif approval[class="hl-string">'status'] == class="hl-string">'rejected':
                activity = class="hl-string">'Manager Rejected' if is_first_approval else class="hl-string">'Finance Rejected'
                is_first_approval = False
            elif approval[class="hl-string">'status'] in [class="hl-string">'sent_back', class="hl-string">'pending_resubmit']:
                activity = class="hl-string">'Sent Back For Revision'

            if activity:
                event_log.append({
                    **base_event,
                    class="hl-string">'ActivityName': activity,
                    class="hl-string">'EventTime': approval[class="hl-string">'updated-at'],
                    class="hl-string">'UserName': approval.get(class="hl-string">'approver', {}).get(class="hl-string">'fullname'),
                    class="hl-string">'RejectionReason': rejection_reason
                })
        
        class=class="hl-string">"hl-comment"># 5. Infer payment and accounting events from status
        if report[class="hl-string">'status'] == class="hl-string">'processing_payment':
            event_log.append({
                **base_event,
                class="hl-string">'ActivityName': class="hl-string">'Reimbursement Scheduled',
                class="hl-string">'EventTime': report[class="hl-string">'updated-at'], class=class="hl-string">"hl-comment"># Inferred from last update timestamp
                class="hl-string">'UserName': class="hl-string">'System'
            })
            
        if report[class="hl-string">'status'] == class="hl-string">'paid':
            event_log.append({
                **base_event,
                class="hl-string">'ActivityName': class="hl-string">'Reimbursement Executed',
                class="hl-string">'EventTime': report[class="hl-string">'updated-at'], class=class="hl-string">"hl-comment"># Inferred from last update timestamp
                class="hl-string">'UserName': class="hl-string">'System'
            })

        class=class="hl-string">"hl-comment"># class="hl-string">'exported' flag indicates posting to an ERP system
        if report.get(class="hl-string">'exported') == True:
            event_log.append({
                **base_event,
                class="hl-string">'ActivityName': class="hl-string">'Accounting Posted',
                class="hl-string">'EventTime': report[class="hl-string">'updated-at'], class=class="hl-string">"hl-comment"># Inferred from last update timestamp
                class="hl-string">'UserName': class="hl-string">'System'
            })

    class=class="hl-string">"hl-comment"># 6. Create DataFrame and save to CSV
    if not event_log:
        print(class="hl-string">"No events were generated. Exiting.")
        return
        
    df = pd.DataFrame(event_log)
    class=class="hl-string">"hl-comment"># Reorder columns for clarity
    column_order = [
        class="hl-string">'ExpenseReportId', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'EndTime', class="hl-string">'UserName',
        class="hl-string">'EmployeeDepartment', class="hl-string">'TotalAmount', class="hl-string">'ExpenseReportStatus',
        class="hl-string">'RejectionReason', class="hl-string">'PolicyViolationFlag', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate'
    ]
    df = df[column_order]
    df.sort_values(by=[class="hl-string">'ExpenseReportId', class="hl-string">'EventTime'], inplace=True)
    
    output_filename = class="hl-string">'coupa_expense_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()

経費管理データ``テンプレート

経費管理データ``テンプレート

経費精算属性

経費精算アクティビティ

抽出ガイド

経費データ用Coupa SFTP経由スケジュール済みエクスポート

ステップ

設定

a クエリ例 config

Coupa Expenses向けREST APIを使用するPythonスクリプト

ステップ

設定

a クエリ例 python

今すぐ始めますか？

経費管理を最適化：今日のボトルネックを解消しましょう

経費管理データ``テンプレート

経費管理データ``テンプレート

経費精算属性

経費精算アクティビティ

抽出ガイド

経費データ用Coupa SFTP経由スケジュール済みエクスポート

ステップ

設定

a クエリ例 config

Coupa Expenses向けREST APIを使用するPythonスクリプト

ステップ

設定

a クエリ例 python

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

今すぐ始めますか？

経費管理を最適化：今日のボトルネックを解消しましょう