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

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

Coupa Expenses

経費管理の属性(20) 経費管理のアクティビティ(13) データ抽出ガイド(2)

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

このデータテンプレートでは、Coupa Expensesの経費管理プロセスを分析するためのデータを体系的に整理しています。収集する属性、記録する主要なアクティビティ、データ抽出の手順をまとめています。プロセスマイニング分析に必要な情報を収集する際にご利用ください。

データ収集に推奨される属性
記録すべき経費管理の主要なアクティビティ
Coupa Expensesからデータを抽出する手順

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

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

経費管理の属性

経費管理プロセスを詳しく分析するため、イベントログに含めることを推奨するデータ項目です。

5 必須 7 推奨 8 任意

	名前	説明
	アクティビティ名 ActivityName	経費精算書について、特定の時点で発生した業務イベントの名前です。
説明アクティビティ名は、経費管理プロセスにおける具体的なステップや節目を示します。たとえば、「経費精算書の提出」「マネージャーによる承認」「払い戻しの実行」などです。これらのアクティビティがプロセスマップのノードとなり、プロセスフロー、ボトルネック、処理経路の違いを分析する基礎になります。この属性を分析すると、イベントの順序や各ステップの発生頻度、ステップ間の移行を把握できます。プロセスマップの作成、移行時間の算出、一般的な処理経路やコンプライアンスに適合しない処理経路の特定に欠かせません。重要な理由プロセスの各ステップを定義する属性です。プロセスフローを可視化して分析するために使われ、プロセスマイニングの中核を担います。入手先通常は、Coupaの経費精算書オブジェクトに関連するイベントログ、ステータス変更記録、監査証跡テーブルから取得します。ステータスコードやイベント種別を、利用者にわかりやすい名前に対応付ける必要がある場合があります。例経費精算書を提出マネージャーが承認経理部門が却下払い戻しを実行
	イベント時刻 EventTime	アクティビティまたはイベントが発生した時刻を示すタイムスタンプです。
説明イベント時刻は、特定のアクティビティがシステムに記録された正確な日時です。イベントを時系列に並べ、時間に基づく分析を行ううえで欠かせません。プロセスの各ステップがいつ発生し、どれくらいかかったかを把握するための事実に基づく情報です。プロセスマイニングでは、この属性を使って各ケースのタイムラインを作成し、アクティビティ間の所要時間を算出します。また、遅延の特定や全体のサイクルタイムの測定にも利用します。パフォーマンスやサービスレベル合意の遵守状況を分析し、時間に関する傾向やボトルネックを特定するうえで重要です。重要な理由イベントの時系列を示すタイムスタンプです。サイクルタイムの算出やボトルネックの特定など、所要時間やパフォーマンスに関する分析の基礎になります。入手先 Coupaの監査証跡またはイベントログのテーブルにあり、通常はアクティビティやステータス変更の記録とともに保存されています。例 2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z
	経費精算書ID ExpenseReportId	経費精算書を一意に識別するIDです。1件の申請に関連するすべてのアクティビティと経費をまとめます。
説明経費精算書IDは、1件の経費申請に関連するすべてのイベントとアクティビティをまとめる、主要なケース識別子です。経費精算書の作成時に一意のIDが割り当てられ、申請の登録から最終的な支払いまでを時系列で追跡できます。プロセスマイニング分析では、このIDを使って各経費精算書の一連の流れを再構成します。プロセスフローを可視化し、処理経路の違いを特定できるほか、個々の申請の総サイクルタイムや手戻りの回数など、ケース単位の指標を算出できます。重要な理由 1件の経費申請に関連するすべてのイベントを結び付けるための基本となるキーです。これにより、プロセスの開始から完了までを分析できます。入手先 Coupaの経費精算書オブジェクトで使われる主キーです。Expense Reports 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	承認者が経費精算書を却下した際に示す理由です。
説明マネージャーや財務部門の担当者が経費精算書を却下する際、理由を記載することがあります。この属性にはその理由が記録され、定義済みの選択肢または自由記述の場合があります。根本原因の分析に役立つ属性です。よくある却下理由を分析すると、ポリシーがわかりにくい、従業員へのトレーニングが必要、申請プロセスに問題があるといった課題を特定できます。手戻りの削減や初回承認率の向上にもつながります。重要な理由手戻りが発生する理由を直接把握できます。対象を絞ったトレーニングやポリシーの明確化、プロセスの改善を通じて、却下率を下げるための具体的な改善案を検討できます。入手先通常は、Coupaで却下イベントに関連付けられた監査証跡やコメントに記録されます。専用フィールドに保存される場合と、コメントから抽出する場合があります。例領収書が未添付ポリシーに適合しない経費経費カテゴリの誤り申請の重複
	合計金額 TotalAmount	経費精算書の合計金額です。
説明この属性は、レポートに含まれるすべての経費明細の合計を示します。プロセス内で処理される金額を把握するための重要な財務指標です。合計金額を分析すると、経費精算書を金額帯ごとに分類できます。金額帯によって承認経路や確認の厳しさが異なる場合があります。ダッシュボードで支出傾向を分析したり、高額なレポートによるボトルネックを特定したり、金額と処理時間や却下率の関係を調べたりする際に使います。重要な理由経費精算書の金額に基づく分析が可能になります。金額によって承認経路や処理の優先度が変わる場合があるため、プロセスを財務面から把握するのに役立ちます。入手先 Coupaの経費精算書ヘッダーにある標準フィールドです。「total」または「total-amount」という名前がよく使われます。例 150.752500.0085.50
	従業員の部門 EmployeeDepartment	経費精算書を提出した従業員の部門です。
説明この属性は、経費精算書の申請者が所属する組織の部門または事業部門を示します。通常は、従業員マスターデータから取得します。組織内の部門ごとにプロセスのパフォーマンスを比較するための重要な分析軸です。部門別に承認時間、却下率、ポリシー違反を分析するダッシュボードでは、この属性を使って、プロセスの改善や対象を絞ったトレーニングが必要な領域を特定します。重要な理由部門ごとのパフォーマンスを比較し、効率的に処理できている部門や支援が必要な部門を特定できます。入手先 Coupaの申請者のユーザープロフィールから取得するか、ユーザーIDを使って外部の人事マスターデータと結合します。ユーザーオブジェクトの「department」フィールドを確認してください。例営業マーケティングエンジニアリング財務
	終了時刻 EndTime	アクティビティが完了した時刻を示すタイムスタンプです。
説明終了時刻は、アクティビティが完了した時刻を示します。多くのトランザクションシステムでは、アクティビティは瞬時に発生するイベントのため、終了時刻は開始時刻と同じです。一方、所要時間を測定できるアクティビティでは、完了した時刻が記録されます。このフィールドは、個々のアクティビティの処理時間を正確に算出するために欠かせません。プロセスのどこで時間がかかっているかをより正確に分析し、待ち時間と実作業時間を区別できます。重要な理由アクティビティごとの所要時間を正確に算出できます。特定の作業にかかった時間と待ち時間を区別し、分析するうえで重要です。入手先瞬時に発生するイベントでは、開始時刻（EventTime）と同じことがよくあります。所要時間のあるアクティビティでは、別のフィールドから取得するか、次のイベントのタイムスタンプを基に算出する必要があります。例 2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z
	経費精算書のステータス ExpenseReportStatus	経費精算書の現在または最終のステータスです。
説明この属性は、経費精算書のライフサイクル終了時点での全体的な状態を示します。「承認済み」「支払い済み」「却下」「取り下げ」などがあり、各ケースの最終結果を確認できます。分析では、最終ステータスを使って完了したケースを絞り込み、結果を分類します。却下率などの指標を算出し、各終了状態に至ったレポートの割合を把握するうえで欠かせません。また、中間ステータスのまま滞留しているレポートの特定にも役立ちます。重要な理由各ケースの結果を示すため、承認されたレポートと却下されたレポートの処理経路を比較するなど、結果に基づく分析の基礎になります。入手先 Coupaの経費精算書オブジェクトにある主要なステータスフィールドです。ヘッダーデータで確認でき、プロセスの進行に伴って更新されます。例 pending_approvalapprovedpaidrejected
	コストセンター CostCenter	経費の配賦先となるコストセンターです。
説明コストセンターは、会計や予算管理に使われる財務上の区分で、経費をどの組織が負担するかを示します。申請者が所属する部門とは異なる場合があります。コストセンター別の分析では、プロセスを財務会計の観点から把握できます。特定の予算や財務単位に対する支出とプロセスの効率を追跡できます。組織全体の支出を把握、管理したい財務部門にとって特に重要です。重要な理由財務面の重要な分析軸となり、プロセス指標を財務単位や予算単位に直接結び付けて分析できます。入手先 Coupaの標準的な会計フィールドで、経費精算書のヘッダーまたは明細にあります。勘定科目表の構成要素であることがよくあります。例 CC4510-MarketingCC2100-EngineeringCC7800-Sales-East
	ポリシー違反の理由 PolicyViolationReason	経費精算書がポリシー違反として検出された具体的な理由です。
説明ポリシー違反が検出された際、この属性には「金額が上限を超過」「未承認の加盟店」など、具体的な理由が記録されます。単純な真偽値のフラグより詳しい情報を確認できます。ポリシー違反の理由を分析すると、コンプライアンス上の問題をより細かく把握できます。頻繁に違反されるポリシーを特定し、周知方法の見直しやポリシーの調整、より厳格な運用が必要かどうかを検討できます。効果的なコンプライアンス改善策を立てるうえで役立ちます。重要な理由コンプライアンス上の問題を具体的に把握し、経費ポリシーの遵守を促すための対策を検討できます。入手先通常は、Coupaのコンプライアンスエンジンが生成するポリシーフラグや警告メッセージの詳細に記録されています。例 1日の食事上限を超過経費の重複領収書が必要
	初回承認の有無 IsFirstPassApproval	却下や修正を経ずに経費精算書が承認された場合にtrueとなるフラグです。
説明このケース単位の計算属性は、経費精算書が初回の承認プロセスで承認されたかどうかを示します。却下または「修正のため差し戻し」のアクティビティがケースに含まれない場合、「true」に設定されます。この属性は、申請と承認のプロセスの効率を直接測定します。初回承認率という重要業績評価指標（KPI）の基礎となります。部門や経費カテゴリなど、初回承認率の低さに関係する要因を分析すると、プロセス改善に役立つインサイトが得られます。重要な理由プロセスの品質と効率を明確に測定し、手戻りなしで処理されたレポートの割合を把握できます。入手先ケース単位で算出します。特定のExpenseReportIdに属するすべてのアクティビティを確認し、却下または修正のイベントがないことを確かめます。例 truefalse
	国 Country	申請した従業員または取引の対象となる国です。
説明この属性は、経費精算書に関連する国を示します。通常は、申請した従業員の居住国です。グローバルな組織のプロセスを分析するための重要な軸です。国別にプロセスを分析すると、地域ごとのパフォーマンス、コンプライアンス、処理経路の違いを比較できます。対応が必要な規制やポリシー、業務効率の地域差を把握できます。重要な理由地域ごとのプロセスのパフォーマンスとコンプライアンスを比較できます。グローバルな組織に欠かせない分析です。入手先 Coupaのユーザープロフィール、または経費精算書に関連付けられた法人から取得できます。例 USADEUGBRJPN
	手戻りの有無 IsRework	レポートが修正のために差し戻されるなど、アクティビティが手戻りのループに含まれるかを示すフラグです。
説明この真偽値の計算属性は、手戻りに該当するアクティビティを示します。通常、「修正のため差し戻し」などのイベントや、同じケースでそのイベントの後に発生したアクティビティに「true」を設定します。手戻りの特定は、プロセスマイニングの主な目的の1つです。このフラグを使うと、手戻りを直接絞り込み、集計できるため、分析が容易になります。手戻り率の算出、プロセスマップ上での手戻りループの可視化、プロセスの再実行につながる根本原因の分析に利用できます。重要な理由非効率な手戻りループを直接特定し、その頻度やサイクルタイムへの影響、根本原因を簡単に把握できます。入手先プロセスフローを基に算出します。「修正のため差し戻し」など、前のプロセス段階に戻ったことを示すアクティビティを特定するロジックが必要です。例 truefalse
	承認者名 ApproverName	経費精算書を承認または却下したマネージャー、もしくは財務部門のユーザー名です。
説明この属性は、マネージャーまたは財務部門による承認ステップに関わった承認者を特定します。レポートを提出したユーザーとは異なります。承認者のパフォーマンスや対応状況の分析に役立ちます。承認者ごとの承認サイクルタイムを測定し、業務が集中している、または追加のトレーニングが必要な担当者によるボトルネックを特定できます。業務量の偏りを調整し、承認の効率を高めるためのダッシュボードにも利用できます。重要な理由遅延や却下率の高さを特定の承認者にひも付けて、承認プロセスのボトルネックを特定できます。対象を絞った対策にも役立ちます。入手先 Coupaの経費精算書にある承認履歴または監査証跡で確認できます。各承認ステップには、操作を行ったユーザーの記録が残ります。例 Sarah ChenDavid Rodriguez財務部門の処理待ち
	経費カテゴリ ExpenseCategory	出張費、食費、事務用品費など、経費の分類です。
説明この属性は、申請された経費の種類を分類します。経費精算書には複数の明細が含まれ、それぞれにカテゴリが設定されることがあります。ケース単位で分析する場合は、最も多いカテゴリを使うか、カテゴリを集約します。経費カテゴリ別にプロセスを分類すると、カテゴリごとの処理傾向やボトルネックを把握できます。たとえば、出張費は事務用品の購入より複雑な承認経路をたどる場合があります。経費の種類が処理の流れに与える影響を理解するための重要な分析軸です。重要な理由支出の種類ごとにプロセスを分類し、カテゴリ固有のボトルネックやポリシー、承認経路を特定できます。入手先この情報はCoupaの経費明細単位で保存されます。ケース単位で分析するには、たとえば金額が最も大きい明細のカテゴリを使うなど、集約が必要です。例航空運賃食事・接待費ソフトウェア事務用品
	通貨 Currency	経費精算書の合計金額に使われる通貨コードです。
説明この属性は、経費精算書の合計金額に使われる通貨を示します。たとえば、USD、EUR、GBPなどです。財務データを正しく解釈するために欠かせない情報です。グローバルな組織の経費を分析する際は、地域ごとの金額を正しく解釈し、集計するために重要です。地域間で適切に比較するには、すべての金額を単一の基準通貨に換算する必要がある場合があります。重要な理由金額の通貨を明確にし、正確な財務分析を支えます。グローバルなレポートでは、通貨換算にも役立ちます。入手先 Coupaの経費精算書ヘッダーにある標準フィールドです。通常は合計金額フィールドの近くにあり、「currency-code」のような名前が付いています。例 USDEURGBPJPY

必須推奨任意

経費管理のアクティビティ

経費管理ワークフローを正確に把握・分析するため、イベントログに記録する主要なプロセスのステップと節目です。

6 推奨 7 任意

	アクティビティ	説明
	マネージャーが承認	従業員の直属のマネージャー、または最初の承認者が経費精算書を承認します。タイムスタンプを含む承認履歴に、明示的なイベントとして記録されます。
重要な理由最初の承認段階の完了を示します。このイベントまでの時間は、承認サイクルタイムの重要業績評価指標（KPI）の分析や、マネージャー段階のボトルネック特定に重要です。入手先 Coupaの詳細な承認履歴または経費精算書の監査証跡に記録された、承認操作のタイムスタンプから取得します。記録経費精算書の承認履歴ログに記録された承認イベントのタイムスタンプを使用します。イベントタイプ explicit
	会計に計上	経費精算書に関連する会計取引が総勘定元帳に転記されます。財務会計の観点では、これがプロセスの最終ステップです。
重要な理由これが最後のアクティビティで、プロセスの実質的な完了を示します。払い戻しから転記までの時間は、迅速かつ正確な決算に欠かせません。入手先このイベントは、経費精算書に関連する仕訳または会計明細の転記日から記録されます。これらはCoupaの会計連携によって管理されます。記録経費精算書に関連する会計明細の転記日フィールドから取得します。イベントタイプ explicit
	払い戻しを実行	支払い処理が正常に完了し、従業員に資金が支払われます。このイベントは従業員への支払い完了を示し、払い戻しプロセスの終了となります。
重要な理由従業員満足度に関わる重要な節目であり、平均払い戻しリードタイムの重要業績評価指標（KPI）の終点です。入手先経費精算書に関連付けられた支払いレコードの支払い実行日から取得します。通常はCoupa Payまたは連携された買掛金システムに記録されています。記録経費精算書に関連付けられた支払いレコードの支払日を使用します。イベントタイプ explicit
	経理部門が承認	経理または監査チームが経費精算書を最終承認します。このイベントは、精算書の検証が完了し、支払い処理に進める状態になったことを示し、承認履歴に記録されます。
重要な理由最終承認の節目です。マネージャーの承認から経理部門の承認までの時間は、承認サイクル全体を構成する重要な要素です。入手先経費精算書の詳細な承認履歴または監査証跡に記録された最終承認操作のタイムスタンプから取得します。記録経費精算書の承認履歴に記録された最終承認イベントのタイムスタンプを使用します。イベントタイプ explicit
	経費精算書を作成	経費精算書のライフサイクルの開始を示します。ユーザーが新しい経費精算書を初めて作成して保存した時点で記録され、精算書は下書き状態になります。
重要な理由すべてのプロセス分析の起点となり、経費精算書の開始から終了までのサイクルタイム全体を測定するうえで重要です。入手先 Coupaの経費精算書ヘッダーレコードの作成時刻から取得する明示的なイベントです。経費ヘッダーテーブルの「created_at」タイムスタンプがデータソースになります。記録経費精算書オブジェクトの作成時刻を使用します。イベントタイプ explicit
	経費精算書を提出	従業員が入力を完了した経費精算書を正式に承認申請します。この操作により、精算書は下書き状態から承認待ち状態に移り、システムに明示的に記録されます。
重要な理由承認にかかる時間の計測が始まる重要な節目です。作成から提出までの時間から、従業員が精算書の準備にかけた時間がわかります。入手先経費精算書のレコードに記録された提出時刻、または提出イベントの監査証跡ログから取得します。記録経費精算書の「submitted_at」タイムスタンプ項目を使用します。イベントタイプ explicit
	ポリシーを確認	経費ポリシーへの準拠を確認する自動チェックが実行されます。通常は、経費精算書にポリシー違反のフラグまたは警告が初めて設定された時刻から推定します。
重要な理由ポリシー遵守状況の概要を示すダッシュボードに欠かせないイベントです。プロセスのどの時点で違反が検出されたか、その違反が承認時間にどう影響したかを把握できます。入手先経費明細または経費精算書のヘッダーにポリシー違反のフラグが設定された時刻から推定します。記録経費精算書またはその明細にポリシー違反のフラグが初めて設定された時刻です。イベントタイプ inferred
	マネージャーが却下	従業員のマネージャーが経費精算書を却下します。多くの場合、プロセスが中断され、精算書は従業員に差し戻されます。承認履歴に特定のイベントとして記録されます。
重要な理由プロセス上の問題を示す否定的な結果です。このイベントの分析は、経費精算書の却下率を示すダッシュボードと重要業績評価指標（KPI）に欠かせません。入手先経費精算書の承認履歴または監査証跡に記録された却下操作のタイムスタンプから取得します。記録経費精算書の承認履歴ログに記録された却下イベントのタイムスタンプを使用します。イベントタイプ explicit
	修正のため差し戻し	承認者が最終却下せずに、修正のため経費精算書を従業員に差し戻します。この操作によって手戻りのループが発生し、ステータスの変更または特定の監査証跡イベントから推定されます。
重要な理由このアクティビティは、手戻りのループを分析するうえで中心となります。差し戻しの理由を特定することで、研修の改善や初回承認率の向上につながります。入手先「修正待ち」や「差し戻し」などへのステータス変更から推定します。Coupaの承認履歴にこの操作が明示的に記録される場合もあります。記録「要修正」状態へのステータス変更時刻、または監査ログに記録された特定のイベントのタイムスタンプを使用します。イベントタイプ inferred
	払い戻しを予定	最終承認後、経費精算書が支払い用のバッチにまとめられます。承認段階から支払い処理段階への移行を示します。
重要な理由払い戻し実行のサイクルタイムの計測が始まるアクティビティです。ここでの遅れは、承認済みの精算書を支払いシステムに移す際の滞留を示します。入手先ステータスが「支払い待ち」に変わった時刻、またはCoupa Payの支払いバッチレコードに精算書が関連付けられた日付から推定します。記録ステータスが「支払い待ち」に変わった時刻、または関連する支払いバッチの作成日を使用します。イベントタイプ inferred
	経理部門が却下	経理または監査チームが経費精算書を却下します。これはプロセスの最終的な否定的結果であり、精算書の履歴に最終却下のステータスとして記録されます。
重要な理由経理部門による却下を追跡すると、前段階の確認で見逃された重大なコンプライアンス上の問題や文書の不備を特定でき、却下率の重要業績評価指標（KPI）の分析に役立ちます。入手先経費精算書の監査証跡に記録された、経理部門の承認者による却下操作のタイムスタンプから取得します。記録経理部門による確認段階で監査証跡に記録された却下イベントのタイムスタンプを使用します。イベントタイプ explicit
	経費精算書を取り下げ	従業員が、提出済みで最終承認前の経費精算書を取り下げます。この操作により現在の承認プロセスが取り消され、明示的なイベントとして記録されます。
重要な理由従業員が自ら内容を修正したり、提出を取り消したりした事例を追跡します。プロセスに関する混乱を示す場合があり、プロセスの中断の一種です。入手先ユーザーの明示的な操作から取得します。「取り下げ」または「キャンセル」ステータスになり、監査証跡に記録されます。記録経費精算書の監査証跡に記録された「取り下げ」操作のタイムスタンプを使用します。イベントタイプ explicit
	領収書を添付	経費精算書の明細に領収書をアップロードまたは添付するユーザー操作を示します。経費精算書に関連付けられた添付ファイルレコードの作成を確認して記録します。
重要な理由このアクティビティのタイミングと頻度を分析すると、ユーザーの行動パターンや、文書の不足による遅れを把握できます。入手先特定の経費精算書IDに関連付けられた添付ファイルレコードの作成時刻から推定します。記録添付ファイルレコードが経費精算書に関連付けられた時刻を特定します。イベントタイプ inferred

推奨任意

データ抽出ガイド

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

ステップ

前提条件：Coupaで定期エクスポートにアクセスし、設定するための適切な権限（通常は管理者またはインテグレーションスペシャリストのロール）を持つユーザーアカウントが必要です。また、Coupaがエクスポートファイルを配置するSFTPサーバーへのアクセスも必要です。
定期エクスポートを開く：Coupaにログインします。「設定」メニューから「インテグレーション」セクションに進み、「定期エクスポート」をクリックします。
経費レポートのエクスポートを設定する：「作成」をクリックし、「経費レポート」オブジェクトのエクスポートを設定します。「ProcessMind_Expense_Reports」など、内容が分かる名前を付けます。形式は「CSV」を選択します。「フィールド」セクションで、id、created-at、submitted-at、updated-at、status、total、user-idなど、レポート単位で必要な属性を選択します。
承認履歴のエクスポートを設定する：「経費レポート承認」オブジェクトの定期エクスポートを追加し、「ProcessMind_Expense_Approvals」と名前を付けます。id、created-at、updated-at、status、approver-id、expense-report-idなどのフィールドを含めます。承認、却下、修正のイベントを記録するために必要なデータです。
添付ファイルのエクスポートを設定する：「経費レポート添付ファイル」オブジェクトのエクスポートを追加し、「ProcessMind_Expense_Attachments」と名前を付けます。領収書が追加された時刻を追跡できるよう、created-atと、関連するexpense-report-idまたはexpense-line-idを含めます。
支払い用の請求書エクスポートを設定する：「経費レポートからの請求書」オブジェクトのエクスポートを追加し、「ProcessMind_Expense_Invoices」と名前を付けます。払い戻しと会計処理のイベントを追跡するために必要です。expense-report-id、paid-date、scheduled-payment-date、exported、updated-atなどのフィールドを含めます。
納品先とスケジュールを設定する：作成した各エクスポートで「納品」タブを開き、ホスト名、ユーザー名、ディレクトリパスなど、SFTPサーバーの接続情報を入力します。通常はパスワードまたは鍵を使う認証方式を設定します。「スケジュール」タブで頻度を「毎日」に設定し、定期的にデータを更新します。
エクスポートを実行してデータを取り込む：スケジュールを有効にし、必要に応じて初回は手動で実行します。ETLスクリプトやデータウェアハウスの取り込みツールなどを使って、SFTPサーバーからCSVファイルを取得し、ステージングデータベースに読み込む処理を設定します。
データをイベントログに変換する：ステージングしたデータに、提供されているSQLクエリなどの変換スクリプトを実行します。レポート、承認、請求書の各テーブルのデータを結合し、統合されたイベントログテーブルを作成します。
ProcessMind用にエクスポートする：データベースまたはデータウェアハウスから、作成したイベントログテーブルを1つのCSVファイルにエクスポートします。列名がExpenseReportId、ActivityName、EventTimeなどの必要な属性と一致していることを確認してください。これで、プロセスマイニングツールにアップロードできる状態になります。

設定

前提条件：Coupa Expensesモジュールが有効になっている必要があります。エクスポートを設定するユーザーには、「定期CSVエクスポート」の権限を持つロールが必要です。SFTPサーバーを用意し、必要に応じてIPアドレスを許可リストに登録してください。
主なCoupaオブジェクト：標準のCoupaデータオブジェクトである「経費レポート」、「経費レポート承認」、「経費レポート添付ファイル」、「経費レポートからの請求書」のエクスポートをスケジュールします。
SFTPの設定：SFTPサーバーのURL、ポート（通常は22）、専用ユーザーの認証情報、ファイルの配置先ディレクトリを指定します。CoupaのUIで接続テストが正常に完了することを確認してください。
日付範囲とフィルタリング：定期エクスポートでは通常、前回の実行成功後に作成または更新されたレコードを対象にします。初回の履歴データ読み込みでは、対象期間に応じて「created-at」または「updated-at」の日付範囲を指定できます。たとえば、過去6～12か月を対象にします。
ファイル形式：データ処理ツールとの互換性が高く、扱いやすいCSV形式を使用してください。
スケジュールの頻度：プロセスマイニングでデータを適切な頻度で更新するため、毎日のエクスポートを推奨します。業務への影響を抑えるには、負荷の少ない時間帯に実行してください。

クエリの例 sql

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パラメーターを増やしてページネーションを処理します。取得したレポートヘッダーはリストに保存します。
各レポートの詳細データを取得する：前の手順で取得した経費レポートヘッダーを1件ずつ処理します。各レポートについて、承認情報を/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」に変わったとき、「払い戻し予定」アクティビティとして記録できます。
DataFrameを作成してエクスポートする：すべての経費レポートを処理し、イベントのリストを作成したら、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フィルターを追加します。たとえば、「approved」、「paid」、「denied」のステータスのレポートだけを取得できます。
処理性能に関する考慮事項：このスクリプトは経費レポートごとに複数回APIを呼び出します。数万件のレポートがある場合、抽出に時間がかかることがあります。負荷の少ない時間帯に実行するか、updated-atのタイムスタンプを基準に差分データを取り込む方法を検討してください。

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

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

このテンプレートを使ってプロセスマイニングを始め、経費管理に関するインサイトを見つけてください。今日から業務の改善に取り組みましょう。

改善ガイドに戻る

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

経費管理を最適化：ボトルネックを今すぐ解消

業務の状況を可視化して非効率な箇所を見つけ、経費処理のサイクルタイムを30％短縮しましょう。

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

クレジットカードは不要です。数分で利用を開始できます。

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

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

経費管理の属性

経費管理のアクティビティ

データ抽出ガイド

経費データをCoupaからSFTP経由で定期エクスポートする方法

ステップ

設定

クエリの例 sql

経費データを取得するCoupa REST API用Pythonスクリプト

ステップ

設定

クエリの例 python

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

経費管理を最適化：ボトルネックを今すぐ解消