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

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

Coupa Expenses

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

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

この詳細なデータテンプレートでは、Coupa Expensesの経費管理プロセスを分析するための構成を示します。収集すべき基本的なデータ属性、追跡すべき主要なアクティビティ、データ抽出の手順をまとめています。このテンプレートを使うことで、プロセスマイニングに必要な情報を漏れなく収集できます。

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

イベントログを初めて扱いますか。学ぶプロセスマイニングのイベントログを作成する方法.

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

経費管理の属性

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

5 必須 7 推奨 8 任意

	名前	説明
	アクティビティ名 ActivityName	経費レポートについて、特定の時点で発生した業務イベントの名称です。
説明アクティビティ名は、経費管理プロセスにおける具体的なステップまたはマイルストーンを示します。たとえば、「Expense Report Submitted」、「Manager Approved」、「Reimbursement Executed」などです。これらのアクティビティがプロセスマップのノードとなり、プロセスフロー、ボトルネック、処理経路の違いを分析する基盤になります。この属性を分析すると、イベントの順序、各プロセスステップの発生頻度、ステップ間の遷移を把握できます。プロセスマップの作成、遷移時間の計算、一般的な経路やコンプライアンスに反する経路の特定に欠かせません。重要な理由この属性によってプロセス内のステップが定義され、プロセスフローを可視化・分析できます。プロセスマイニングの中核となる情報です。入手先通常は、Coupaの経費レポートオブジェクトに関連するイベントログ、ステータス変更レコード、または監査証跡テーブルから取得されます。ステータスコードやイベントタイプを、ユーザーが理解しやすい名称にマッピングする必要がある場合があります。例経費精算レポートを提出マネージャーが承認財務部門が却下払い戻しの実行
	イベント時刻 EventTime	アクティビティまたはイベントが発生した時点を示すタイムスタンプです。
説明イベント時刻は、特定のアクティビティがシステムに記録された正確な日時です。このタイムスタンプは、イベントを時系列に並べ、時間に基づく分析を行うために欠かせません。プロセスステップの発生時点と所要時間を把握するための事実に基づく情報になります。プロセスマイニングでは、この属性を使って各ケースのタイムラインを構築し、アクティビティ間の所要時間を計算し、遅延を特定し、全体のサイクルタイムを測定します。パフォーマンス、サービスレベル合意の遵守状況、時間的なパターンやボトルネックを分析するうえで重要です。重要な理由このタイムスタンプによってイベントの時系列が定まり、サイクルタイムやボトルネックの特定を含む、所要時間およびパフォーマンス分析の基盤になります。入手先 Coupaの監査証跡またはイベントログテーブルに、通常はアクティビティやステータス変更の記録とともに保存されています。例 2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z
	経費レポートID ExpenseReportId	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	経費レポートの現在または最終的なステータスです。
説明経費レポートのライフサイクル終了時点における全体的な状態を示す属性です。「Approved」、「Paid」、「Rejected」、「Withdrawn」などが該当します。各ケースの最終結果を確認できます。分析では、最終ステータスを使って完了したケースを抽出し、結果を分類します。却下率などの指標を計算し、各レポートがどの終了状態に至ったかの割合を把握するために欠かせません。中間ステータスで滞留しているレポートの特定にも役立ちます。重要な理由各ケースの結果を定義します。承認済みレポートと却下レポートの経路を比較するなど、結果に基づく分析の基盤になります。入手先 Coupaの経費レポートオブジェクトにある主要なステータスフィールドです。ヘッダーデータで確認でき、プロセス全体を通じて更新されます。例承認待ち承認済み支払い済み却下済み
	コストセンター CostCenter	経費が割り当てられるコストセンターです。
説明コストセンターは、会計と予算管理に使う財務上の切り口です。経費を負担する組織内の部門を示します。提出者自身の所属部門とは異なる場合があります。コストセンター別に分析すると、財務会計の観点からプロセスを確認できます。特定の予算または財務単位に対する支出とプロセス効率を追跡できます。組織全体の支出を把握・管理したい財務部門にとって、特に重要な情報です。重要な理由分析における重要な財務上の切り口となり、プロセス指標を財務単位や予算単位に直接関連付けられます。入手先 Coupaの標準的な会計フィールドです。経費レポートのヘッダーまたは明細にあり、勘定科目体系の一部であることが多い項目です。例 CC4510-MarketingCC2100-EngineeringCC7800-Sales-East
	ポリシー違反理由 PolicyViolationReason	経費レポートがポリシー違反としてフラグ付けされた具体的な理由です。
説明ポリシー違反がフラグ付けされた際、その具体的な理由を示す属性です。「金額が上限を超過」や「未承認の加盟店」などが該当します。単純なブール値のフラグよりも詳細な情報を提供します。ポリシー違反の理由を分析すると、コンプライアンス上の問題をより細かく把握できます。頻繁に違反される特定のポリシーを特定できるため、周知方法の改善、ポリシーの見直し、より厳格な運用が必要かどうかを判断できます。効果的なコンプライアンス改善策を作るための重要な情報です。重要な理由コンプライアンス上の問題を具体的に示し、会社の経費ポリシーの遵守状況を改善するための対象を絞った対応を可能にします。入手先通常は、Coupaのコンプライアンスエンジンが生成したポリシーフラグまたは警告メッセージの詳細に記録されています。例 1日の食事上限超過経費が重複しています領収書が必要です
	再作業かどうか IsRework	レポートが修正のため差し戻された場合など、アクティビティが再作業ループの一部かどうかを示すフラグです。
説明再作業を示すアクティビティをフラグ付けする、計算済みのブール属性です。通常は「Sent Back For Revision」などのイベント、または同じケース内でそのイベントの後に発生するアクティビティに対して「true」に設定します。再作業の特定は、プロセスマイニングの主要な目的の1つです。このフラグを使うと、再作業を直接フィルタリング・集計できます。再作業率の計算、プロセスマップ上の再作業ループの可視化、プロセスを繰り返す原因となるアクティビティの根本原因分析に利用できます。重要な理由非効率な再作業ループを直接フラグ付けし、頻度、サイクルタイムへの影響、根本原因を簡単に定量化できます。入手先プロセスフローに基づいて計算されます。「Sent Back For Revision」など、以前のプロセス段階に戻ったことを示すアクティビティを特定するロジックが必要です。例 truefalse
	初回承認かどうか IsFirstPassApproval	経費レポートが却下や修正なしで承認された場合にtrueとなるフラグです。
説明経費レポートが1回目の承認プロセスを正常に通過したかどうかを示す、ケース単位の計算済み属性です。ケースに却下または「Sent Back For Revision」アクティビティが含まれていない場合に「true」に設定します。提出・承認プロセスの効率を直接測定できます。初回承認率が低いことと、部門や経費カテゴリなどの要因との関係を分析すると、プロセス改善に役立つ情報が得られます。重要な理由プロセスの品質と効率を明確に測定し、再作業なしで処理されたレポートの割合を定量化できます。入手先ケース単位で計算します。特定のExpenseReportIdに属するすべてのアクティビティを確認し、却下または修正イベントがないことを判定する必要があります。例 truefalse
	国 Country	提出した従業員または取引に関連する国です。
説明経費レポートに関連する国を示す属性です。通常は提出した従業員の居住国です。グローバルな組織でプロセスを分析するための重要な切り口になります。国別にプロセスを分析すると、地域間でパフォーマンス、コンプライアンス、プロセスの違いを比較できます。規制、ポリシー、業務効率における地域差を明らかにし、対応が必要な領域を特定できます。重要な理由地域間でプロセスパフォーマンスとコンプライアンスを比較できます。グローバルな組織に欠かせない分析です。入手先 Coupaのユーザープロファイル、または経費レポートに関連付けられた法人から取得できます。例 USADEUGBRJPN
	承認者名 ApproverName	経費レポートを承認または却下したマネージャーまたは財務ユーザーの名前です。
説明マネージャー承認または財務承認のステップに関係する承認者を識別する属性です。レポートを提出したユーザーとは異なります。承認者のパフォーマンスや行動を分析するために役立ちます。承認者ごとの承認サイクルタイムを測定し、業務量の偏りや追加トレーニングの必要性によって特定の承認者がボトルネックになっていないか確認できます。業務量の平準化と承認効率の向上を目的とするダッシュボードにも利用できます。重要な理由遅延や高い却下率を特定の承認者に関連付け、承認チェーンのボトルネックを特定できます。対象を絞った対策にもつながります。入手先 Coupaの経費レポートにある承認履歴または監査証跡で確認できます。各承認ステップには、アクションを実行したユーザーの記録があるはずです。例 Sarah ChenDavid Rodriguez財務チームキュー
	経費カテゴリ ExpenseCategory	旅行、会食、事務用品など、経費のカテゴリです。
説明申請された経費の種類を分類する属性です。経費レポートには複数の経費明細が含まれることが多く、それぞれにカテゴリがあります。ケース単位で分析する場合は、最も頻度の高いカテゴリや集約したカテゴリ一覧を使うことがあります。経費カテゴリ別にプロセスを分けて分析すると、異なる行動やボトルネックが見えてきます。たとえば、旅行経費は事務用品の購入よりも複雑な承認経路をたどる場合があります。この切り口は、経費の性質が処理経路に与える影響を把握するために重要です。重要な理由支出の種類に基づいてプロセスを分けて分析できます。カテゴリ固有のボトルネック、ポリシー、承認経路を特定するのに役立ちます。入手先 Coupaでは経費明細レベルに保存されています。ケース単位で分析する場合は、たとえば最も金額の大きい明細のカテゴリを採用するなど、集約が必要です。例航空運賃食事・接待ソフトウェア事務用品
	通貨 Currency	経費レポートの合計金額に使用される通貨コードです。
説明経費レポートの合計金額がどの通貨で表示されているかを示す属性です。USD、EUR、GBPなどが該当します。財務データを解釈するために欠かせない情報です。グローバルな組織の経費を分析する場合、金額を正しく解釈・集計するために重要です。地域間で意味のある比較を行うには、すべての金額を単一の基準通貨に換算する必要がある場合があります。重要な理由金額の解釈に必要な背景情報を提供し、正確な財務分析とグローバルレポート向けの通貨換算を可能にします。入手先 Coupaの経費レポートヘッダーにある標準フィールドです。通常は合計金額フィールドの近くにあり、「currency-code」のような名称が付いています。例 USDEURGBPJPY

必須推奨任意

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

経費ワークフローを正確に発見・分析するため、イベントログに記録する主要なプロセス手順とマイルストーンです。

6 推奨 7 任意

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

推奨任意

抽出ガイド

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

ステップ

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

設定

前提条件：Coupa Expensesモジュールが有効になっている必要があります。エクスポートを設定するユーザーには、「Scheduled CSV Exports」の権限を持つロールが必要です。SFTPサーバーを用意し、必要に応じてIPアドレスを許可リストに登録してください。
主なCoupaオブジェクト：抽出では、標準のCoupaデータオブジェクトである「Expense Report」、「Expense Report Approval」、「Expense Report Attachment」、「Invoice from Expense Report」の定期エクスポートを設定します。
SFTP設定：SFTPサーバーのURL、ポート（通常は22）、専用ユーザーの認証情報、ファイル配置先のディレクトリを指定します。Coupaの画面上で接続テストが正常に完了することを確認してください。
期間とフィルタリング：定期エクスポートでは通常、前回の正常終了以降に作成または更新されたレコードを対象にします。初回の履歴データの取り込みでは、直近6～12か月など、対象期間を指定するcreated-atまたはupdated-atの範囲を設定できます。
ファイル形式：データ処理ツールとの互換性が高く、扱いやすいため、ファイル形式には必ずCSVを使用してください。
スケジュール頻度：プロセスマイニングでは、プロセスデータを適切に最新の状態に保つため、毎日のエクスポートを推奨します。業務時間外に実行すると、パフォーマンスへの影響を抑えられます。

a サンプルクエリ 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以降がインストールされていることを確認します。ターミナルでpip install pandas requestsを実行し、データ操作用のpandasとAPI呼び出し用のrequestsをインストールします。また、経費レポート、経費明細、添付ファイル、承認を読み取る権限を持つAPIキーをCoupa管理者から取得する必要があります。
Coupa APIキーを生成：Coupaの環境にログインします。「Setup」>「Company Setup」>「API Keys」に移動します。新しいAPIキーを作成し、必要なExpenseモジュールへの読み取り権限を付与します。このキーは自社データへのアクセスに使用するため、安全に保管してください。
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レスポンスを標準化したイベントログの行に変換します。必要な13種類のアクティビティごとに、1件のイベントを表す辞書を作成してリストに追加します。たとえば、「Expense Report Created」イベントにはcreated-atを使い、承認データをループして「Manager Approved」や「Finance Rejected」などのイベントを作成します。
APIデータを属性にマッピング：変換処理で、Coupa APIレスポンスのJSONフィールドを必要な属性と推奨属性にマッピングします。たとえば、idをExpenseReportIdに、created-atをEventTimeに、totalをTotalAmountにマッピングします。ネストされたユーザーオブジェクトからユーザーと部門の情報を抽出します。
推定イベントを処理：「Reimbursement Scheduled」や「Accounting Posted」など、一部のアクティビティはステータスの変更から推定します。レポートのstatusフィールドとupdated-atのタイムスタンプを使って、これらのイベントを生成します。たとえば、ステータスがprocessing_paymentに変わった場合、「Reimbursement Scheduled」アクティビティとして記録できます。
DataFrameを作成してエクスポート：すべての経費レポートを処理し、イベントのリストを作成したら、そのリストをpandas DataFrameに変換します。SourceSystemやLastDataUpdateなどの固定列を追加します。最後に、indexをFalseに設定してto_csvメソッドでDataFrameをCSVファイルにエクスポートします。このCSVファイルをProcessMindにアップロードできます。

設定

APIキーの権限：認証に使うAPIキーには、少なくとも次のCoupaオブジェクトへの読み取り専用アクセス権が必要です：Expense Reports、Expense Lines、Users、Approvals、Attachments。
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を基準にした増分読み込みを実装してください。

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()

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

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

改善ガイドに戻るテンプレートをダウンロード

経費管理を最適化：今日からボトルネックを解消

非効率な箇所を見つけ、明確な分析結果に基づいて経費プロセスのサイクルタイムを30％削減します。

無料トライアルを開始

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

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

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

経費管理の属性

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

抽出ガイド

経費データを取得するCoupaのSFTP定期エクスポート

ステップ

設定

a サンプルクエリ sql

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

ステップ

設定

a サンプルクエリ python

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

経費管理を最適化：今日からボトルネックを解消

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

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

経費管理の属性

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

抽出ガイド

経費データを取得するCoupaのSFTP定期エクスポート

ステップ

設定

a サンプルクエリ sql

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

ステップ

設定

a サンプルクエリ python

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

経費管理を最適化：今日からボトルネックを解消

プライバシーを大切にしています