> 継続的なプロセス改善 > 調達から支払いまで：購買依頼 > Coupa > データテンプレート

調達から支払いまで：購買申請のデータテンプレート

Coupa

← 改善ガイドに戻る

調達から支払いまで：購買依頼の属性 (21) 調達から支払いまで：購買依頼のアクティビティ (12) 抽出ガイド (3)

調達から支払いまで：購買申請のデータテンプレート

このデータテンプレートでは、調達から支払いまでの購買申請プロセスを分析するために必要な情報を、体系的に収集できます。信頼性の高いイベントログに必要な属性とアクティビティを示し、Coupaからデータを効率的に抽出する方法も説明します。

詳細な分析に推奨される属性
追跡すべき主要なプロセスアクティビティ
データ抽出の具体的な手順

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

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

調達から支払いまで：購買依頼の属性

調達から支払いまで：購買依頼プロセスを詳細に分析するため、イベントログに含めることを推奨するデータ項目です。

5 必須 5 推奨 11 任意

	名前	説明
	アクティビティ名 ActivityName	購買申請について、ある時点で発生した特定の業務アクティビティまたはイベントの名称です。
説明この属性は、購買申請のライフサイクルにおける個別のステップを記録します。例として、「購買申請作成」、「承認ステップ承認」、「購買申請ソーシング開始」などがあります。各アクティビティは、購買申請に対して実行された特定のマイルストーンまたはアクションを表します。これらのアクティビティの順序と頻度を分析することは、プロセスマイニングの基本です。プロセスマップの可視化、一般的な経路の特定、標準手順からの逸脱の検出が可能になります。重要な理由プロセスマップ上のステップを定義し、購買申請の流れを可視化・分析できるようにします。入手先通常は、Coupa内のイベントログ、ステータス変更記録、または監査証跡から取得します。ステータスフィールドやアクションコードからのマッピングが必要になる場合があります。例申請作成申請提出承認ステップ承認購買申請却下購買注文作成
	イベント時刻 EventTime	アクティビティが発生した正確な日付と時刻です。
説明イベント時刻、つまりタイムスタンプは、購買申請についてアクティビティが記録された正確な時点を示します。このデータは、イベントを時系列に並べてプロセスフローを構築するために欠かせません。処理時間の算出、アクティビティ間の所要時間によるボトルネックの特定、期間ごとのプロセスパフォーマンスの把握など、時間に基づくすべての分析の基礎になります。意味のあるプロセス分析には、正確で詳細なタイムスタンプが必要です。重要な理由イベントを正しい順序に並べ、処理時間やボトルネックなど、所要時間に基づくすべての指標を算出するために欠かせないタイムスタンプです。入手先 Coupaの各購買申請に関する監査証跡または履歴レコードに記録されます。各アクションの「created_at」または「updated_at」フィールドとして保持されることが一般的です。例 2023-10-26T10:00:00Z2023-10-26T11:35:10Z2023-10-27T14:22:05Z
	購買申請ID PurchaseRequisitionId	各購買申請を一意に識別するIDであり、プロセスにおける主要なケース識別子です。
説明購買申請IDは、商品やサービスに関する1件の申請に関連するすべてのアクティビティを結び付ける中心的なキーです。各購買申請には作成時に一意のIDが割り当てられ、ライフサイクル全体を通じて変わりません。これにより、初回の作成と送信から、承認または却下の各ステップ、最終的なソーシングとクローズまで、購買申請をエンドツーエンドで追跡できます。プロセスマイニングでは、すべてのイベントログエントリがこのIDに紐付くため、各ケースの全体の流れを再構成できます。重要な理由すべてのプロセスステップを結び付ける必須のケースIDであり、購買申請の開始から完了までのライフサイクルを詳細に分析できます。入手先 CoupaのRequisitionsモジュールおよび関連するデータエクスポートに含まれる主キー項目です。例 PR-102934PR-102935PR-102936
	ソースシステム SourceSystem	データの抽出元となるソースシステムを識別します。
説明この属性は、プロセスデータの元となった記録システムを指定します。この分析では、値は一貫して「Coupa」になります。複数のシステムからデータを統合する環境では、特にこのフィールドを含めることが推奨されます。データの系譜に関する重要なコンテキストを提供し、データガバナンスと品質ルールの管理に役立ちます。重要な理由データの系譜を明確にし、データガバナンスや複数のエンタープライズシステムからのデータ統合に役立ちます。入手先通常は、データの抽出・変換処理中にデータセットの出所を示すために追加する固定値です。例 Coupa
	最終データ更新日時 LastDataUpdate	ソースシステムからデータが最後に更新された時点を示すタイムスタンプです。
説明この属性は、Coupaから直近にデータを抽出した日付と時刻を記録します。分析対象データの鮮度を明確にできます。データが現在の業務状態を反映しているのか、過去の時点を反映しているのかを判断するうえで、データの新しさを把握することは重要です。継続中の業務を監視するダッシュボードでは、特に重要になります。重要な理由データの鮮度をユーザーに伝え、分析対象の期間を理解したうえで最新情報に基づく意思決定ができるようにします。入手先データ抽出が正常に完了した時点で、データパイプラインまたはETLツールによって生成・追加されるタイムスタンプです。例 2024-05-21T02:00:00Z
	合計金額 TotalAmount	購買申請の金銭的な合計額です。
説明この属性は、購買申請で依頼されたすべての商品・サービスの合計費用を表します。金額はプロセス分析における重要な要素です。承認ワークフローの複雑さに影響することが多く、高額な購買申請ほど多くの承認ステップが必要になる傾向があります。金額帯（例：1,000ドル未満、1,000～10,000ドル）別にプロセス指標を分析することで、金銭的重要度の異なる購買申請をプロセスがどのように処理しているかを把握できます。重要な理由金額の異なる購買申請でプロセスがどのように変化するかを分析できます。金額が高いほど、より複雑な承認ワークフローが開始されることが多いためです。入手先 CoupaのRequisitionオブジェクトのヘッダーにある標準フィールドで、通常は「total」または「total_amount」という名称です。例 500.0012550.7599.99
	承認者 Approver	承認アクティビティを担当するユーザーまたはグループです。
説明この属性は、承認ステップに割り当てられた個人または承認グループを識別します。「承認ステップ開始」、「承認ステップ承認」、「承認ステップ却下」などのアクティビティに設定されます。承認者別のデータ分析は、「承認者のパフォーマンスと負荷」ダッシュボードの構築に欠かせません。個々の承認時間の測定、特定の承認者が原因となるボトルネックの特定、業務量の分布の評価に役立ちます。重要な理由承認者のパフォーマンスや業務量のバランスを分析し、特定の個人または承認グループに関連するボトルネックを特定するために欠かせません。入手先 Coupaの各購買申請に関連付けられた承認チェーンの詳細に含まれます。Userデータとの結合が必要になる場合があります。例 David Miller財務承認者L2Susan Chen
	申請者 Requester	購買申請を作成して送信した従業員です。
説明この属性は、申請を開始した個人を識別します。申請者別にデータを分析することで、特定のユーザーに関する傾向を把握できます。例えば、修正率が高い、却下が頻繁に発生するといった傾向は、追加のトレーニングが必要であることを示している可能性があります。また、ユーザーやユーザーグループごとの購買申請量とプロセス上の行動の分析にも使われます。重要な理由ユーザー別にプロセス上の行動を分析できるため、トレーニングの必要性を特定し、個々のユーザーがプロセスにどのように関わっているかを把握できます。入手先 CoupaのRequisitionオブジェクトにある標準フィールドとして利用でき、Userオブジェクトに関連付けられ、「requester」または「created_by」という名称であることが一般的です。例 Alice JohnsonBob SmithCharlie Brown
	購買申請ステータス RequisitionStatus	購買申請の現在または最終的なステータスです。
説明この属性は、データ抽出時点における購買申請の全体的な状態、または最終結果を示します。一般的なステータスには、「承認待ち」、「承認済み」、「却下」、「取り下げ」、「クローズ済み」などがあります。これはフィルタリングと分析における重要なディメンションです。承認率や却下率の算出、未完了の購買申請の現在の業務量の監視、申請の最終的な処理結果の把握に使われます。重要な理由購買申請の結果を理解し、承認率や却下率を算出し、処理中の購買申請の現在の状態を監視するために欠かせません。入手先 CoupaのPurchase Requisitionオブジェクトにある標準フィールドで、通常は「status」または「state」という名称です。例承認待ち承認済み却下済み取り下げ済みクローズ済み
	部門 Department	購買申請の費用が計上される業務部門またはコストセンターです。
説明部門属性は、各購買申請を特定の組織単位またはコストセンターに関連付けます。これは比較分析における重要なディメンションです。ダッシュボードとKPIを部門別に絞り込み、セグメント化できるため、管理者は組織内の各部門の承認処理時間、却下率、コンプライアンスを比較できます。部門固有の問題や優れた取り組みの特定にも役立ちます。重要な理由部門間で処理時間や却下率などのプロセスKPIを比較し、改善すべき領域を明らかにできます。入手先 CoupaのRequisitionオブジェクトにある標準フィールドで、申請者のユーザープロファイルに関連付けられるか、購買申請の明細行で指定されることが一般的です。例マーケティングIT業務施設研究開発
	サプライヤー名 SupplierName	購買申請で選択されたサプライヤーまたはベンダーの名称です。
説明この属性は、依頼した商品またはサービスの予定サプライヤーを識別します。サプライヤーは申請者が指定する場合と、後のソーシングプロセスで追加される場合があります。サプライヤー別にプロセス指標を分析することで、サプライヤーのパフォーマンスを評価し、特定のサプライヤーとのやり取りが処理時間の長期化やその他のプロセス上の非効率につながっているかを把握できます。調達戦略やサプライヤー関係管理に重要なコンテキストを提供します。重要な理由選択したサプライヤー別にプロセスパフォーマンスを分析でき、ソーシング戦略やサプライヤー管理に役立ちます。入手先 CoupaのRequisition Lineオブジェクトで利用でき、通常は「supplier」または「vendor」フィールドとして保持されます。例 StaplesDell TechnologiesAccentureCDW
	修正済み IsAmended	初回送信後に購買申請が1回以上修正された場合にtrueとなるブール型フラグです。
説明この計算属性は、特定のケースで「購買申請修正」アクティビティが発生したかを示す単純なフラグ（True／False）です。変更が必要だった購買申請を簡単に抽出・フィルタリングできるため、分析が容易になります。「購買申請修正率」KPIの算出や、「購買申請修正件数」ダッシュボードに使われ、手戻りの根本原因の特定と初回品質の改善に役立ちます。重要な理由修正率KPIの算出を簡単にし、手戻りが必要だったケースと不要だったケースを容易に分けて分析できます。入手先各ケースのイベントログに「購買申請修正」アクティビティが存在するかを確認し、プロセスマイニングツールで算出します。例 truefalse
	却下理由 RejectionReason	購買申請または承認ステップを却下した際に、承認者が入力した理由です。
説明承認者が購買申請を却下する際、通常は判断理由を入力します。この属性は、その説明文を記録します。却下理由を分析することで、購買申請が失敗した理由について直接的かつ定性的な情報を得られます。誤ったコード、予算不足、説明不足などの共通する問題を特定し、トレーニングやプロセス改善によって対処する根本原因分析に役立ちます。重要な理由プロセス失敗の根本原因を直接把握し、ユーザートレーニングやプロセスの明確化が必要な領域を特定できます。入手先通常は、購買申請の承認履歴で「Rejected」ステータスに変更された際に関連付けられたコメントまたはメモフィールドに記録されます。例誤った原価センター今四半期の予算超過重複申請根拠の説明不足
	商品・サービスカテゴリ Commodity	依頼された商品またはサービスの大分類です。
説明商品・サービスカテゴリ属性は、購買申請の明細に含まれる品目を、「事務用品」、「コンピューターハードウェア」、「マーケティングサービス」などの標準化された分類で示します。購入内容に基づいて購買パターンやプロセスの違いを分析できます。特定の商品カテゴリには専用の承認要件やソーシング戦略が設定されている場合があり、カテゴリ別のプロセス分析は、支出カテゴリごとの調達改善に役立ちます。重要な理由支出カテゴリを分析し、購入する商品やサービスの種類によって、承認時間などのプロセス上の行動が異なるかを把握できます。入手先 Coupaの標準フィールドで、通常は購買申請の明細行レベルで利用できます。ヘッダーレベルへの集約が必要になる場合があります。例事務用品コンピューターハードウェアマーケティングサービス出張
	承認ステップ所要時間 ApprovalStepDuration	購買申請が1つの承認ステップで待機していた時間です。
説明この計算指標は、「承認ステップ開始」アクティビティから、対応する「承認ステップ承認」または「承認ステップ却下」アクティビティまでの所要時間を測定します。承認チェーンの各ステージでの待ち時間を個別に把握できます。「重要な承認ステップのボトルネック」ダッシュボードに欠かせない指標であり、全体のプロセスで大きな遅延を生じさせている承認者や承認ステージを正確に特定できます。重要な理由合計処理時間だけでなく、各ステップの待ち時間を測定することで、承認ワークフロー内の具体的なボトルネックを特定できます。入手先「承認ステップ開始」から、その後に発生する終端承認イベント（承認／却下）までの時間差を求め、プロセスマイニングツールで算出します。例 1.2日4時間3.8日
	承認ステップ数 ApprovalStepCount	購買申請が通過した承認ステップの合計数です。
説明この計算属性は、購買申請ごとに「承認ステップ承認」アクティビティの個数を数えます。ケースごとの承認ワークフローの複雑さを定量化できます。「承認ステップの平均数」KPIの基礎となり、通常より長い、または複雑な承認経路をたどる購買申請を特定することで、ワークフローの簡素化が必要な領域を把握できます。重要な理由購買申請ごとの承認ワークフローの複雑さを定量化し、簡素化が必要な過度に複雑な経路を特定できます。入手先各Case IDについて「承認ステップ承認」の発生回数を数え、プロセスマイニングツールで算出します。例 253
	承認ワークフロー経路 ApprovalWorkflowPath	購買申請に適用された特定の承認チェーンまたはワークフローテンプレートを識別するIDです。
説明この属性は、購買申請がたどるべき承認者の定義済みの順序を識別します。通常は、金額、部門、購買申請タイプなどの要素に基づく業務ルールによって決まります。この属性は、「購買申請ポリシーコンプライアンス」ダッシュボードの中心となります。実際の承認者の順序と割り当てられたワークフロー経路を比較することで、逸脱の検出、適合率の測定、管理されていない例外の特定が可能になります。重要な理由想定された承認ステップと実際の承認ステップを比較できるため、プロセスの逸脱を明らかにし、コンプライアンスを分析できます。入手先 Coupaのドキュメントを確認してください。購買申請に対して実行された承認チェーンまたはワークフロールールの名称から導出される場合があります。例標準承認（5,000ドル未満）ITハードウェア承認（10,000ドル超）資本的支出のCFO審査
	緊急度 UrgencyLevel	購買申請の緊急度を示す分類で、「高」、「中」、「低」などがあります。
説明緊急度は、多くの場合、優先度フィールドにマッピングされ、申請者が迅速な処理を必要とする申請を示すために使います。この属性は、「緊急購買申請の処理時間」ダッシュボードに欠かせません。緊急度の高い購買申請と通常の購買申請の処理時間を比較することで、優先順位付けの仕組みが有効か、緊急の業務ニーズに適時対応できているかを評価できます。重要な理由緊急の申請が通常の申請より速く処理されているかを分析し、優先順位付けポリシーの有効性を検証できます。入手先 CoupaのRequisitionオブジェクトにある標準フィールドまたはカスタムフィールドである可能性があります。Coupaのドキュメントまたはシステム設定を確認してください。例高中低
	購買注文ID PurchaseOrderId	承認済みの購買申請から作成された購買注文の識別子です。
説明購買申請が完全に承認され、ソーシングが完了すると、通常は購買注文が作成されます。この属性には、作成されたPOのIDが保存されます。上流の購買申請プロセスと下流の購買注文プロセスを結び付ける重要なリンクです。「購買申請承認からPO作成までの時間」のKPIを算出し、調達から支払いまでのサイクル全体をエンドツーエンドで分析できます。重要な理由購買申請を後続の購買注文に関連付け、引き継ぎにかかる時間を分析するとともに、調達から支払いまでの全体像を把握できます。入手先 CoupaのRequisitionオブジェクトにある標準フィールドで、PO作成後に値が設定されます。例 PO-45000123PO-45000124PO-45000125
	購買申請タイプ RequisitionType	購買申請のカテゴリまたはタイプで、「資本的支出」、「営業費用」、「ソフトウェア」などがあります。
説明購買申請タイプは、業務上の目的や購入内容に基づいて購買申請を分類する属性です。コンプライアンス分析や、申請タイプごとのプロセスの流れを把握するうえで役立ちます。例えば、資本的支出の申請は、通常の営業費用の申請より厳格で時間のかかる承認経路をたどる場合があります。購買申請タイプ別にプロセスを分析することで、プロセス改善につながる情報を見つけられます。重要な理由申請の業務上の目的別に分析を分けられます。タイプによってプロセスの流れやポリシーが異なる場合があるためです。入手先 CoupaのRequisitionオブジェクトにあるカスタムまたは標準の分類フィールドである可能性があります。例資本的支出営業費用ITハードウェア専門サービス
	通貨 Currency	購買申請の合計金額に使用される通貨コードです。
説明この属性は、購買申請の合計金額がどの通貨（例：USD、EUR、GBP）で表示されているかを指定します。複数の通貨を扱う多国籍組織では、財務分析に欠かせない情報です。金額を正しく解釈し、財務レポートやダッシュボードで適切に換算・集計できます。重要な理由「合計金額」属性に必要なコンテキストを提供し、複数通貨の環境で正確な財務分析を行えるようにします。入手先 CoupaのRequisitionオブジェクトにある標準フィールドで、通常は「currency_code」などの名称です。例 USDEURGBP

必須推奨任意

調達から支払いまで：購買依頼のアクティビティ

調達から支払いまで：購買依頼ワークフローを正確に発見するため、イベントログに記録する主要なプロセス手順とマイルストーンです。

6 推奨 6 任意

	アクティビティ	説明
	申請作成	ユーザーが新しい購買申請を開始し、下書きとして保存します。これはすべての申請ケースの起点であり、通常は申請レコード自体の作成タイムスタンプから推定されます。
重要な理由このアクティビティは、申請ライフサイクルの開始を示します。作成から提出までの時間を分析すると、ユーザーの迷いやシステムの複雑さによる遅延を明らかにできます。入手先このイベントは、特定の購買申請IDに対応する「requisition_headers」テーブルの「created-at」タイムスタンプから取得します。取得申請ヘッダーレコードの作成タイムスタンプを使用します。イベントタイプ inferred
	申請提出	申請者が完成した申請を正式に承認ワークフローへ提出します。このイベントは、システムの監査ログまたは履歴テーブルで、申請のステータスが「draft」から「pending_approval」へ変わったことを確認して推定します。
重要な理由提出をきっかけに承認プロセスが始まるため、「申請承認サイクルタイムの平均」KPIを測定するうえで重要なマイルストーンです。この時点までの遅延はユーザーに起因し、その後の遅延はプロセスに起因します。入手先「requisition_headers」テーブルのステータス変更から推定します。具体的には、「status」フィールドが「pending_approval」に変わった時点で、対応する監査証跡からタイムスタンプを取得します。取得申請ステータスが初めて「pending_approval」に変わった時点のタイムスタンプを特定します。イベントタイプ inferred
	購買注文作成	承認済みの購買申請の情報に基づき、購買注文（PO）が正常に生成されます。元の購買申請IDを参照するPOレコードが作成された時点から、このイベントを推定します。
重要な理由これは購買申請プロセスにおける主な成功結果であり、調達から支払いまでの次のステージへの引き継ぎを示します。「購買申請承認済み」からこのイベントまでの時間を分析することで、実行時の遅延を把握できます。入手先元の「requisition_headers」または「requisition_lines」のIDを参照するレコードが「purchase_orders」テーブルに作成されたことから推定します。取得購買申請IDに関連付けられたPOレコードの「created-at」タイムスタンプを使用します。イベントタイプ inferred
	購買申請クローズ	購買申請が正式にクローズされ、それ以上のアクションが行われないことを示します。POの作成と履行後、または承認後かつ発注前に購買申請がキャンセルされた場合に発生します。
重要な理由このアクティビティは、購買申請のライフサイクルにおける明確な終点になります。ケースを適切に完了させることで、プロセス分析上、購買申請が無期限に「アクティブ」として残ることを防ぎます。入手先「requisition_headers」テーブルの「status」フィールドが「closed」に更新されたことから推定します。タイムスタンプは関連する監査証跡に記録されます。取得購買申請の全体ステータスが「closed」に変更された時点のタイムスタンプを特定します。イベントタイプ inferred
	購買申請却下	承認プロセス中に購買申請が最終的に却下され、購買注文には変換されない状態です。購買申請ヘッダーの全体ステータスが「rejected」に変更されたことから推定します。
重要な理由このアクティビティは、プロセスが最終的に失敗したことを示します。これらのイベントを分析することは、「購買申請却下率」の改善や、ポリシー違反、予算上の問題などの根本原因の特定に役立ちます。入手先「requisition_headers」テーブルの「status」フィールドが「rejected」に更新されたことから推定します。タイムスタンプは関連する監査証跡に記録されます。取得購買申請の全体ステータスが「rejected」に変更された時点のタイムスタンプを特定します。イベントタイプ inferred
	購買申請承認済み	購買申請が承認ワークフローで必要なすべてのステップを正常に通過した状態です。購買申請ヘッダーの全体ステータスが「approved」に変更されたことから推定します。
重要な理由これは承認サイクルの終了を示す重要な成功マイルストーンです。このアクティビティに到達するまでの時間は主要なKPIであり、後続の調達アクションを開始するトリガーになります。入手先「requisition_headers」テーブルの「status」フィールドが「approved」に更新されたことから推定します。タイムスタンプは関連する監査証跡に記録されます。取得購買申請の全体ステータスが「approved」に変更された時点のタイムスタンプを特定します。イベントタイプ inferred
	承認ステップ却下	ワークフローの担当ステージで承認者が購買申請を却下し、通常は修正のため申請者に差し戻します。これはCoupaに記録される明示的なアクションです。
重要な理由どのステップで発生した却下も手戻りを生み、処理時間を延ばします。却下が発生した場所と理由を分析することは、プロセス改善とユーザートレーニングに欠かせません。入手先購買申請および承認者に関連付けられた「approvals」テーブルまたは監査証跡に記録された、明示的な「reject」アクションから取得します。取得購買申請の承認履歴で「reject」イベントを絞り込みます。イベントタイプ explicit
	承認ステップ承認	ワークフロー内の担当承認者が、購買申請を承認します。これは、システムに特定のタイムスタンプとユーザー情報とともに記録される明示的なアクションです。
重要な理由このアクティビティにより、承認プロセスの流れを詳細に把握できます。これらのステップを集計することで、「承認ステップあたりの平均待ち時間」を算出し、承認者のパフォーマンスを分析できます。入手先購買申請および承認者に関連付けられた「approvals」テーブルまたは監査証跡に記録された、明示的な「approve」アクションから取得します。取得購買申請の承認履歴で「approve」イベントを絞り込みます。イベントタイプ explicit
	承認ステップ開始	承認タスクが特定の承認者または承認グループに割り当てられ、申請がその対応を待っている状態です。申請に関連する承認レコードが「pending」ステータスで作成された時点から推定します。
重要な理由特定の承認における待機時間の開始を示します。この時点から対応する「承認ステップ承認／却下」までの時間を測定すると、承認チェーン内の具体的なボトルネックを特定できます。入手先申請に関連付けられた「approvals」テーブルのレコード作成タイムスタンプから推定します。承認者の対応ステータスが「pending」または同等の状態であるレコードを使用します。取得承認チェーンにある個人の保留中の承認レコードの作成タイムスタンプを使用します。イベントタイプ inferred
	申請修正	申請が提出された後、申請者または権限を持つ別のユーザーが内容を編集します。Coupaでは通常、これを新しいバージョンまたは監査エントリとして明示的に記録し、承認ワークフローの一部または全体がリセットされることがあります。
重要な理由修正を追跡することは、プロセスの手戻りと非効率を把握するうえで重要です。修正件数が多い場合、初回要件の不明確さや購買ポリシーの複雑さが考えられ、「申請修正率」KPIに影響します。入手先「requisition_headers」テーブルに関連付けられた監査証跡テーブルから取得します。これらのテーブルには、バージョン変更や特定の「edit」アクションが記録されています。取得提出後の申請履歴ログで、明示的な「edit」または「update」イベントを探します。イベントタイプ explicit
	購買申請ソーシング開始	承認済みの購買申請が、すぐに購買注文へ変換されるのではなく、RFQやオークションなどのソーシングイベントに送られます。購買申請がソーシングイベントオブジェクトに関連付けられた時点から、このイベントを推定します。
重要な理由このアクティビティにより、調達プロセスにおける重要な別経路が明らかになります。単純な購買と、より複雑で戦略的なソーシング活動を分けることで、処理時間をより詳細に分析できます。入手先ステータスが「sourcing」に変更されたこと、または「requisition_lines」テーブルとソーシングイベントテーブルの間にリンクが作成されたことを検出して推定します。取得ステータスが「sourcing」に変更されたこと、またはソーシングイベントIDへのリンクが作成されたことを確認します。イベントタイプ inferred
	購買申請取り下げ	最終承認を受ける前に、元の申請者が購買申請をキャンセルします。これはユーザーが実行する明示的なアクションであり、その購買申請のプロセスを終了させます。
重要な理由取り下げは、ビジネスニーズの変化、重複申請、またはユーザーによるプロセス回避を示している可能性があります。これを追跡することで、需要の変動やプロセス遵守上の潜在的な問題を把握できます。入手先「requisition_headers」テーブルのステータスが「withdrawn」または同様の状態に変更されたことから推定します。変更は、監査証跡に記録された明示的なユーザーアクションに基づきます。取得購買申請のステータスが「withdrawn」に変更された時点のタイムスタンプを特定します。イベントタイプ inferred

推奨任意

抽出ガイド

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

ステップ

Coupaへのログイン：レポートの作成とスケジュール設定の権限を持つユーザーアカウントで、Coupaの環境にアクセスします。
レポートモジュールへの移動：Setupタブを開き、Reportingセクションを見つけます。Reportsを選択して、レポート用のダッシュボードを開きます。
新しいカスタムレポートの作成：作成ボタンをクリックして、新しいレポートの作成を開始します。種類としてカスタムレポートを選択します。
レポートのデータソースの定義：レポートビルダーで、必要な情報を集めるために複数のデータソースを選択して結合します。まず、主なデータソースとしてRequisition Headersを選択します。次に、次の関連オブジェクトを追加します。
- Approvals：各承認ステップの承認者、ステータス、タイムスタンプなどの詳細を取得します。
- Requisition Lines：合計金額を集計し、明細レベルの情報を取得します。
- Purchase Order Headers：購買依頼が発注書に変換された時点を特定します。
- Users：依頼者と承認者の氏名および部門の詳細を取得します。
レポート列の構成：利用可能なデータソースから必要なフィールドをレポートレイアウトにドラッグアンドドロップします。これらの列がイベントログの作成に使われるため、最も重要な手順です。少なくとも次の項目を含めます。
- Requisition Headers：Requisition #、Created At、Submitted At、Updated At、ステータス、Created by (Login ID)、合計、Sourced Externally?
- Users（依頼者用）：氏名、Department Name
- Approvals：Created At、Updated At、ステータス、Approver (Login ID)
- Purchase Order Headers：PO Number、Created At
レポートフィルターの設定：データ抽出の範囲を指定するため、フィルターを適用します。一般的で効果的な方法は、Requisition Headers - Created Atを使い、たとえば過去90日間のような動的な期間を設定することです。必要に応じて、特定の会社コードで絞り込むこともできます。
レポートのスケジュール設定：レポートビルダー内のScheduleタブに移動します。レポートを実行する頻度を、毎日や毎週などから指定します。利用の少ない時間帯を実行時刻に設定します。
配信の構成：配信方法を指定します。自動化する場合はSFTPを選択し、サーバーの認証情報と対象ディレクトリを入力します。別の方法として、メールアドレスに送信することもできます。ファイル形式にはCSVを選択します。
保存と有効化：レポートを保存し、スケジュールが有効になっていることを確認します。最初のレポートは、次回の予定時刻に実行されます。
データの変換：生成されたCSVは、イベントログではなくフラットファイルです。外部スクリプト（Pythonなど）またはETLツールを使って処理する必要があります。スクリプトでは、データをピボットし、各アクティビティに対応する行を作成します。たとえば、Created At列を使った「Requisition Created」の行、Approvals列を使った各承認ステップの行、POのCreated At列を使った「Purchase Order Created」の行を作成します。
最終イベントログの作成：変換スクリプトで、PurchaseRequisitionId、ActivityName、EventTime、SourceSystem、LastDataUpdate、その他の推奨属性を含む最終CSVファイルを出力します。これでアップロードできる状態になります。

設定

主要なデータソース：レポートは複数のCoupaオブジェクトを結合して作成する必要があります。主要なソースは「Requisition Headers」、「Approvals」、「Requisition Lines」、「Purchase Order Headers」です。
期間による絞り込み：データ量を抑えるため、日付フィルターを適用することが重要です。まずは「Requisition Headers - Created At」を基準に、過去3～6か月のローリング期間を設定することを推奨します。
増分ロード：継続的に分析する場合は、レポートを毎日実行し、前日（「Yesterday」など）のデータを抽出して増分ロードを作成します。
配信設定：データパイプラインと安定して自動連携できるよう、SFTPサーバーへの配信を設定します。保存先の安全性と十分な容量を確認してください。
必要な権限：レポートを設定するユーザーアカウントには、必要なデータオブジェクト（Requisitions、POs、Approvals、Users）の作成、スケジュール設定、アクセスに必要な管理者権限またはレポート専用権限が必要です。

a サンプルクエリ config

This extraction is configured within the Coupa UI and does not use a direct script. The following outlines the objects and fields required to build the report, which is then transformed into an event log.

**Data Sources (Objects to Join):**
1.  `Requisition Headers` (Primary)
2.  `Approvals` (Joined on Requisition Header ID)
3.  `Users` (Joined from `Requisition Headers` for Requester details)
4.  `Users` (Joined from `Approvals` for Approver details)
5.  `Purchase Order Headers` (Joined on Requisition Header ID)

**Report Columns Configuration (Fields to Select):**

*   **For 'Requisition Created' event:**
    *   Source Object: `Requisition Headers`
    *   Source Field: `Requisition #` -> Maps to `PurchaseRequisitionId`
    *   Source Field: `Created At` -> Maps to `EventTime`

*   **For 'Requisition Submitted' event:**
    *   Source Object: `Requisition Headers`
    *   Source Field: `Submitted At` -> Maps to `EventTime`

*   **For 'Requisition Amended' event:**
    *   Source Object: `Requisition Headers`
    *   Source Field: `Updated At` -> Maps to `EventTime` (Logic must be applied to identify updates after submission)

*   **For 'Approval Step Started' event:**
    *   Source Object: `Approvals`
    *   Source Field: `Created At` -> Maps to `EventTime`

*   **For 'Approval Step Approved' / 'Approval Step Rejected' events:**
    *   Source Object: `Approvals`
    *   Source Field: `Updated At` -> Maps to `EventTime`
    *   Source Field: `Status` -> Used to determine `ActivityName` ('Approved' or 'Rejected')

*   **For 'Requisition Withdrawn' / 'Requisition Approved' / 'Requisition Rejected' / 'Requisition Closed' events:**
    *   Source Object: `Requisition Headers`
    *   Source Field: `Updated At` -> Maps to `EventTime`
    *   Source Field: `Status` -> Used to determine `ActivityName`

*   **For 'Requisition Sourced' event:**
    *   Source Object: `Requisition Headers`
    *   Source Field: `Updated At` -> Maps to `EventTime`
    *   Source Field: `Sourced Externally?` -> Used in logic to identify this event

*   **For 'Purchase Order Created' event:**
    *   Source Object: `Purchase Order Headers`
    *   Source Field: `Created At` -> Maps to `EventTime`

*   **For General Attributes:**
    *   `Requisition Headers | Requisition #` -> `PurchaseRequisitionId`
    *   `Requisition Headers | Status` -> `RequisitionStatus`
    *   `Requisition Headers | Created By (Full Name)` -> `Requester`
    *   `Requisition Headers | Account Department` -> `Department`
    *   `Requisition Headers | Total` -> `TotalAmount`
    *   `Approvals | Approver (Full Name)` -> `Approver`

ステップ

前提条件：Python 3の環境がインストールされていることを確認します。ターミナルまたはコマンドプロンプトでpip install pandas requestsを実行し、必要なライブラリpandasとrequestsをインストールします。
Coupa APIキーを取得：管理者としてCoupa環境にログインします。「Setup」>「Company Setup」>「API Keys」に移動し、少なくとも次のスコープに対する読み取り権限を持つ新しいAPIキーを作成します：core.purchase_order.read、core.requisition.read、core.user.read。
スクリプトを設定：新しいPythonファイル（例：extract_coupa_reqs.py）を作成し、提供されたPythonスクリプトをコピーします。COUPA_INSTANCE_URLには会社のCoupa URL（例：https://yourcompany.coupahost.com）を、API_KEYには前の手順で取得したキーを設定します。
抽出パラメーターを設定：スクリプトのmainセクションで、START_DATEとEND_DATEの変数を調整し、抽出期間を定義します。これにより、作成日を基準に購買申請を絞り込めます。
スクリプトを実行：ターミナルでpython extract_coupa_reqs.pyを実行します。スクリプトがCoupa APIに接続してデータを取得し、コンソールに進捗を表示します。
APIのページネーションを処理：スクリプトにはAPIのページネーションを自動処理する関数が含まれています。50件ずつデータを取得し、指定期間内の購買申請をすべて取得するまで処理を続けます。
購買申請データを処理：取得した各購買申請ヘッダーについて、「Requisition Created」と「Requisition Submitted」のイベントを生成します。その後、関連する承認データと購買発注データを取得するため、追加のAPI呼び出しを行います。
アクティビティイベントを生成：承認レコードを処理し、「Approval Step Started」、「Approval Step Approved」、「Approval Step Rejected」のイベントを作成します。また、購買申請の最終ステータスと関連データを確認し、「Requisition Approved」、「Purchase Order Created」、「Requisition Withdrawn」などのイベントを生成します。
変更を検出：各購買申請のversion属性を確認します。バージョンが1より大きい場合は変更を示します。新しいバージョンのupdated-atタイムスタンプを使って「Requisition Amended」イベントを作成します。
イベントログを組み立てる：生成したすべてのイベントを構造化されたリストに集約します。各イベントにはPurchaseRequisitionId、ActivityName、EventTimeなどの必須属性と、Requester、TotalAmountなどの推奨属性を含めます。
CSVにエクスポート：すべての購買申請の処理が完了したら、最終イベントリストをpandasのDataFrameに変換し、同じディレクトリにcoupa_requisition_event_log.csvというCSVファイルとして保存します。このファイルはProcessMindに直接アップロードできる形式です。

設定

APIキーの権限：抽出に使うAPIキーには、Coupaのrequisition_headers、requisition_lines、approvals、purchase_orders、usersオブジェクトへの読み取りアクセス権が必要です。権限がない場合、スクリプトが失敗するか、不完全なデータが返されます。
期間：スクリプトは購買申請の作成日（created-at）に基づく期間フィルターを使います。実行時間の長期化やAPIタイムアウトを避けるため、3～6か月など、扱いやすい単位で抽出することを推奨します。START_DATEとEND_DATEを適宜調整してください。
ステータスによる絞り込み：提供されたスクリプトは、ステータスにかかわらずすべての購買申請を取得します。対象を絞り込む場合は、最初のAPI呼び出しのparams辞書にstatusパラメーターを追加し、approved、pending_approval、orderedなどの特定のステータスを指定できます。
ページネーションの上限：スクリプトは1回のAPI呼び出しで50件（limit=50）を取得する設定です。これはCoupa APIで標準的な値です。値を増やしても必ずしも処理速度は向上せず、複雑なクエリではタイムアウトのリスクが高まる可能性があります。
パフォーマンスに関する考慮事項：スクリプトは購買申請ごとに複数回（ヘッダー、承認、POについて各1回）APIを呼び出します。数千件の購買申請を抽出する場合、時間がかかることがあり、CoupaのAPIレート制限の影響を受ける可能性があります。業務時間外に実行することを推奨します。

a サンプルクエリ python

import requests
import pandas as pd
from datetime import datetime, timezone

class=class="hl-string">"hl-comment"># --- Configuration ---
class=class="hl-string">"hl-comment"># Replace with your Coupa instance URL and API Key
COUPA_INSTANCE_URL = class="hl-string">"https://[your_instance].coupahost.com"
API_KEY = class="hl-string">"[your_api_key]"

class=class="hl-string">"hl-comment"># --- Main Extraction Logic ---

def get_coupa_data(endpoint, params={}):
    class="hl-string">"""Fetches paginated data from a Coupa API endpoint."""
    headers = {
        class="hl-string">"Accept": class="hl-string">"application/json",
        class="hl-string">"X-COUPA-API-KEY": API_KEY
    }
    
    all_records = []
    offset = 0
    limit = 50
    
    while True:
        paginated_params = params.copy()
        paginated_params[class="hl-string">'offset'] = offset
        paginated_params[class="hl-string">'limit'] = limit
        
        try:
            response = requests.get(fclass="hl-string">"{COUPA_INSTANCE_URL}{endpoint}", headers=headers, params=paginated_params)
            response.raise_for_status() class=class="hl-string">"hl-comment"># Raises an exception for 4xx/5xx errors
            data = response.json()
            
            if not data:
                break
                
            all_records.extend(data)
            offset += limit
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Error fetching data from {endpoint}: {e}")
            break
            
    return all_records

def main(start_date, end_date):
    class="hl-string">"""Main function to extract, transform, and save the event log.""" 
    print(class="hl-string">"Starting Coupa Requisition data extraction...")
    
    event_log = []
    current_time_utc = datetime.now(timezone.utc).isoformat()

    class=class="hl-string">"hl-comment"># 1. Fetch Requisition Headers within the date range
    req_params = {
        class="hl-string">"created-at[gt]": start_date,
        class="hl-string">"created-at[lt]": end_date,
        class="hl-string">"fields": class="hl-string">'["id", "created-at", "submitted-at", "updated-at", "version", "status", "total", "requester", "currency", "sourcing-event-id"]'
    }
    requisition_headers = get_coupa_data(class="hl-string">"/api/requisition_headers", req_params)
    print(fclass="hl-string">"Found {len(requisition_headers)} requisitions to process.")

    for i, header in enumerate(requisition_headers):
        print(fclass="hl-string">"Processing requisition {i+1}/{len(requisition_headers)}: ID {header['id']}")
        
        class=class="hl-string">"hl-comment"># Common attributes for all events of this case
        case_id = str(header[class="hl-string">'id'])
        total_amount = header.get(class="hl-string">'total', {}).get(class="hl-string">'total')
        requester_name = fclass="hl-string">"{header.get('requester', {}).get('firstname', '')} {header.get('requester', {}).get('lastname', '')}".strip()
        department_name = header.get(class="hl-string">'requester', {}).get(class="hl-string">'department', {}).get(class="hl-string">'name')

        base_event = {
            class="hl-string">"PurchaseRequisitionId": case_id,
            class="hl-string">"TotalAmount": total_amount,
            class="hl-string">"Requester": requester_name,
            class="hl-string">"Department": department_name,
            class="hl-string">"Approver": None,
            class="hl-string">"SourceSystem": class="hl-string">"Coupa",
            class="hl-string">"LastDataUpdate": current_time_utc
        }

        class=class="hl-string">"hl-comment"># Activity: Requisition Created
        event_log.append({
            **base_event,
            class="hl-string">"ActivityName": class="hl-string">"Requisition Created",
            class="hl-string">"EventTime": header[class="hl-string">'created-at'],
            class="hl-string">"RequisitionStatus": class="hl-string">"draft"
        })

        class=class="hl-string">"hl-comment"># Activity: Requisition Submitted
        if header.get(class="hl-string">'submitted-at'):
            event_log.append({
                **base_event,
                class="hl-string">"ActivityName": class="hl-string">"Requisition Submitted",
                class="hl-string">"EventTime": header[class="hl-string">'submitted-at'],
                class="hl-string">"RequisitionStatus": class="hl-string">"pending_approval"
            })

        class=class="hl-string">"hl-comment"># Activity: Requisition Amended
        if header.get(class="hl-string">'version') and int(header[class="hl-string">'version']) > 1:
             event_log.append({
                **base_event,
                class="hl-string">"ActivityName": class="hl-string">"Requisition Amended",
                class="hl-string">"EventTime": header[class="hl-string">'updated-at'], class=class="hl-string">"hl-comment"># Timestamp of the new version
                class="hl-string">"RequisitionStatus": header[class="hl-string">'status']
            })

        class=class="hl-string">"hl-comment"># 2. Fetch Approvals for this requisition
        approval_params = {
            class="hl-string">"approvable-id": header[class="hl-string">'id'],
            class="hl-string">"approvable-type": class="hl-string">"RequisitionHeader"
        }
        approvals = get_coupa_data(class="hl-string">"/api/approvals", approval_params)

        for approval in approvals:
            approver = approval.get(class="hl-string">'approver', {}).get(class="hl-string">'fullname')
            approval_status = approval[class="hl-string">'status']

            class=class="hl-string">"hl-comment"># Activity: Approval Step Started
            event_log.append({
                **base_event,
                class="hl-string">"ActivityName": class="hl-string">"Approval Step Started",
                class="hl-string">"EventTime": approval[class="hl-string">'created-at'],
                class="hl-string">"RequisitionStatus": class="hl-string">"pending_approval",
                class="hl-string">"Approver": approver
            })

            if approval_status == class="hl-string">'approved':
                class=class="hl-string">"hl-comment"># Activity: Approval Step Approved
                event_log.append({
                    **base_event,
                    class="hl-string">"ActivityName": class="hl-string">"Approval Step Approved",
                    class="hl-string">"EventTime": approval[class="hl-string">'updated-at'],
                    class="hl-string">"RequisitionStatus": class="hl-string">"pending_approval",
                    class="hl-string">"Approver": approver
                })
            elif approval_status == class="hl-string">'rejected':
                class=class="hl-string">"hl-comment"># Activity: Approval Step Rejected
                event_log.append({
                    **base_event,
                    class="hl-string">"ActivityName": class="hl-string">"Approval Step Rejected",
                    class="hl-string">"EventTime": approval[class="hl-string">'updated-at'],
                    class="hl-string">"RequisitionStatus": class="hl-string">"pending_approval",
                    class="hl-string">"Approver": approver
                })
        
        class=class="hl-string">"hl-comment"># 3. Handle final status and related events
        final_status_event_time = header[class="hl-string">'updated-at']
        final_status = header[class="hl-string">'status']

        if final_status == class="hl-string">'approved':
            event_log.append({
                **base_event,
                class="hl-string">"ActivityName": class="hl-string">"Requisition Approved",
                class="hl-string">"EventTime": final_status_event_time,
                class="hl-string">"RequisitionStatus": final_status
            })
        elif final_status == class="hl-string">'rejected':
            event_log.append({
                **base_event,
                class="hl-string">"ActivityName": class="hl-string">"Requisition Rejected",
                class="hl-string">"EventTime": final_status_event_time,
                class="hl-string">"RequisitionStatus": final_status
            })
        elif final_status == class="hl-string">'withdrawn':
            event_log.append({
                **base_event,
                class="hl-string">"ActivityName": class="hl-string">"Requisition Withdrawn",
                class="hl-string">"EventTime": final_status_event_time,
                class="hl-string">"RequisitionStatus": final_status
            })
        elif final_status == class="hl-string">'closed':
             event_log.append({
                **base_event,
                class="hl-string">"ActivityName": class="hl-string">"Requisition Closed",
                class="hl-string">"EventTime": final_status_event_time,
                class="hl-string">"RequisitionStatus": final_status
            })

        class=class="hl-string">"hl-comment"># Activity: Requisition Sourced
        if header.get(class="hl-string">'sourcing-event-id'):
            event_log.append({
                **base_event,
                class="hl-string">"ActivityName": class="hl-string">"Requisition Sourced",
                class="hl-string">"EventTime": final_status_event_time, class=class="hl-string">"hl-comment"># Assumes status update time reflects sourcing
                class="hl-string">"RequisitionStatus": final_status
            })

        class=class="hl-string">"hl-comment"># 4. Fetch Purchase Orders to detect PO Creation
        po_params = {class="hl-string">"requisition-header-id": header[class="hl-string">'id']}
        purchase_orders = get_coupa_data(class="hl-string">"/api/purchase_orders", po_params)

        for po in purchase_orders:
            event_log.append({
                **base_event,
                class="hl-string">"ActivityName": class="hl-string">"Purchase Order Created",
                class="hl-string">"EventTime": po[class="hl-string">'created-at'],
                class="hl-string">"RequisitionStatus": class="hl-string">"ordered" 
            })

    class=class="hl-string">"hl-comment"># 5. Create and save the DataFrame
    if not event_log:
        print(class="hl-string">"No events were generated. The output file will be empty.")
        return

    df = pd.DataFrame(event_log)
    df = df.sort_values(by=[class="hl-string">"PurchaseRequisitionId", class="hl-string">"EventTime"])
    df.to_csv(class="hl-string">"coupa_requisition_event_log.csv", index=False)
    print(class="hl-string">"\nExtraction complete. Event log saved to coupa_requisition_event_log.csv")

if __name__ == class="hl-string">"__main__":
    class=class="hl-string">"hl-comment"># Define the extraction period. Format: YYYY-MM-DDTHH:MM:SSZ
    START_DATE = class="hl-string">"2023-01-01T00:00:00Z"
    END_DATE = class="hl-string">"2023-06-30T23:59:59Z"
    main(START_DATE, END_DATE)

ステップ

選択したサードパーティ製iPaaSまたはプロセスマイニングプラットフォームが、購買依頼ヘッダー、購買依頼履歴または監査データ、承認レコード、ソーシング関係、購買注文関係、クローズ情報にアクセスできる、検証済みのCoupaコネクターを提供していることを確認します。コネクター名、オブジェクト名、利用可能なフィールドはプロバイダーによって異なるため、コネクターのドキュメントとCoupaテナントに従って設定します。
プラットフォームの接続インターフェースでコネクター接続を作成します。必要なCoupaテナントURL、認証方式、認証情報、OAuthの詳細、必要なスコープを入力します。対象環境で接続を設定するまでは、[Your Coupa tenant URL]や[Your connector credentials]などのプレースホルダーを使用します。
抽出範囲を設定します。最初は3～6か月のローリング日付範囲を選択し、照合後に拡張します。[Your company filter]や[Your document type filter]など、テナントで有効なフィルターだけを適用します。ライフサイクル分析に必要なため、現在のステータスがclosed、rejected、withdrawn、approvedであることだけを理由に購買依頼を除外しないでください。
コネクターでソースオブジェクトをマッピングします。購買依頼ヘッダーオブジェクト、購買依頼履歴または監査オブジェクト、承認オブジェクト、ソーシング関係オブジェクト、購買注文関係オブジェクト、コネクターが公開するクローズまたはステータス履歴オブジェクトを選択します。必要なオブジェクトを利用できない場合は、コネクターがサポートする履歴または監査表現を使用するか、抽出を公開する前に制限事項を記録します。
ケースとイベントのマッピングを設定します。購買依頼識別子をPurchaseRequisitionId、イベントラベルをActivityName、ソースタイムスタンプをEventTime、固定のソース値CoupaをSourceSystem、コネクターの更新タイムスタンプをLastDataUpdateにマッピングします。利用可能な場合は、依頼者、部門、合計金額、購買依頼ステータス、承認者もマッピングします。
12個すべてのアクティビティについて行を明示的に作成するイベントルールを設定します。購買依頼の作成タイムスタンプからRequisition Createdを、draftからpending_approvalへの遷移からRequisition Submittedを、提出後のバージョンまたは監査エントリからRequisition Amendedを、承認待ちレコードからApproval Step Startedを、承認アクションからApproval Step Approvedを、却下アクションからApproval Step Rejectedを、明示的な取り下げアクションまたはステータス遷移からRequisition Withdrawnを、ヘッダーのapprovedステータスへの遷移からRequisition Approvedを、ヘッダーのrejectedステータスへの遷移からRequisition Rejectedを、購買依頼とソーシングの関係からRequisition Sourcedを、購買依頼を参照する購買注文からPurchase Order Createdを、クローズアクションまたはステータス遷移からRequisition Closedを作成します。
イベントストリームを結合する前に、抽出データを正規化します。すべてのタイムスタンプを1つのタイムゾーン、できればUTCに変換し、ソースのタイムスタンプ精度を保持し、購買依頼識別子を一貫したテキスト型に変換し、ソースのステータスとユーザー値を保持します。重複排除は技術的に同一のソースレコードに限り、比較キーには購買依頼識別子、アクティビティ名、イベントタイムスタンプ、利用可能な場合はソースレコード識別子、承認者を使用します。
コネクターフローを公開またはスケジュールします。選択した日付範囲について最初に全件抽出を実行し、その後はソース更新タイムスタンプまたはコネクターがサポートする変更追跡機能に基づいて増分更新します。遅れて到着した監査エントリや修正された承認レコードを含めるため、ルックバック期間を設定します。
Coupaのレポートまたはコネクターのプレビューと照合して、生成されたイベントログを検証します。すべての購買依頼に作成イベントがあること、ステータスと承認の遷移が想定された時系列になっていること、ソーシングまたは購買注文が存在する場合に関係ベースのイベントが含まれていることを確認します。
最終結果をフラットCSVまたはProcessMindがサポートする別のイベントログ形式でエクスポートします。イベントごとに1行を含め、PurchaseRequisitionIdをケース識別子、ActivityNameをアクティビティ、EventTimeをイベントタイムスタンプとして使用します。欠落イベントをProcessMindに推測させず、ファイルをアップロードするか、コネクターデータセットをProcessMindに公開します。

設定

コネクターとアクセス：選択したiPaaSまたはプロセスマイニングプラットフォームが提供する、検証済みのCoupaコネクターを使用します。必要なCoupaの認可、APIスコープ、モジュール、コネクターライセンスは、プロバイダーとテナント設定によって異なります。実装前に、購買申請、履歴または監査、承認、ソーシング、購買発注、完了データへのアクセスを確認してください。
期間：まず3～6か月分のデータから始めます。スケジュール更新ではローリング抽出期間を使用し、遅れて更新されたデータ、承認操作、変更された購買申請を取得できるようルックバック期間を設けます。
必須マッピング：購買申請識別子をPurchaseRequisitionId、イベントラベルをActivityName、イベントタイムスタンプをEventTime、ソース値をSourceSystem、更新タイムスタンプをLastDataUpdateに対応付けます。
推奨マッピング：購買申請ステータス、申請者、部署またはコストセンター、合計金額、承認者を対応付けます。コネクターが対応している場合は、現在値とイベント単位の値の両方を保持してください。
イベントルール：12個すべての必須アクティビティを明示的に作成するよう設定します。ProcessMindはイベントログをそのまま読み込み、追加イベントを導出または推測しません。
フィルター：コネクターがサポートし、テナントで有効なフィルターだけを適用します。例として、[Your company filter]、[Your document type filter]、[Your business unit filter]、[Your requisition date range]があります。分析上の明確な要件がない限り、終了ステータスを除外しないでください。
タイムスタンプの処理：タイムスタンプを共通のタイムゾーンに変換し、ソースの精度を保持します。同一タイムスタンプのイベントには、決定的な並び順のルールを定義してください。
増分更新：コネクターがサポートするupdated-atまたは変更追跡フィールドを使用します。承認履歴、ソーシングリンク、購買発注リンク、完了情報は初回作成後に追加される場合があるため、ルックバック期間を設定してください。
パフォーマンス：初回抽出は期間と有効な業務フィルターで絞り、必要なフィールドだけを取得し、大規模なオブジェクトにはページネーションを使用します。履歴データセット全体を繰り返し結合することは避け、対応している場合は関連データと監査データを増分抽出してください。
データ品質：PurchaseRequisitionId、ActivityName、EventTime、SourceSystem、LastDataUpdateが空でないことを必須とします。コネクターが提供する場合は、トラブルシューティングと重複除去のためにソース識別子を保持してください。
設定の違い：オブジェクト名、フィールド名、ステータス値、監査データの表現、利用可能な関連データは、Coupaテナントとコネクターによって異なります。コネクターに文書化された同等項目がない場合は、[Configure based on your system]を使用してください。

a サンプルクエリ config

WITH
requisition_created AS (
    SELECT
        CAST(r.requisition_id AS VARCHAR(255)) AS PurchaseRequisitionId,
        'Requisition Created' AS ActivityName,
        CAST(r.created_at AS TIMESTAMP) AS EventTime,
        'Coupa' AS SourceSystem,
        CAST(r.last_data_update AS TIMESTAMP) AS LastDataUpdate,
        CAST(r.status AS VARCHAR(255)) AS RequisitionStatus,
        CAST(r.requester AS VARCHAR(255)) AS Requester,
        CAST(r.department AS VARCHAR(255)) AS Department,
        CAST(r.total_amount AS DECIMAL(38, 10)) AS TotalAmount,
        CAST(NULL AS VARCHAR(255)) AS Approver
    FROM [Your requisition header object] r
    WHERE r.created_at >= CAST('[Your start date]' AS TIMESTAMP)
      AND r.created_at < CAST('[Your end date]' AS TIMESTAMP)
      AND [Your company filter]
),
requisition_submitted AS (
    SELECT
        CAST(h.requisition_id AS VARCHAR(255)) AS PurchaseRequisitionId,
        'Requisition Submitted' AS ActivityName,
        CAST(h.event_time AS TIMESTAMP) AS EventTime,
        'Coupa' AS SourceSystem,
        CAST(h.last_data_update AS TIMESTAMP) AS LastDataUpdate,
        CAST(r.status AS VARCHAR(255)) AS RequisitionStatus,
        CAST(r.requester AS VARCHAR(255)) AS Requester,
        CAST(r.department AS VARCHAR(255)) AS Department,
        CAST(r.total_amount AS DECIMAL(38, 10)) AS TotalAmount,
        CAST(h.user_name AS VARCHAR(255)) AS Approver
    FROM [Your requisition history or audit object] h
    LEFT JOIN [Your requisition header object] r ON CAST(r.requisition_id AS VARCHAR(255)) = CAST(h.requisition_id AS VARCHAR(255))
    WHERE LOWER(CAST(h.previous_status AS VARCHAR(255))) = 'draft'
      AND LOWER(CAST(h.new_status AS VARCHAR(255))) = 'pending_approval'
      AND h.event_time >= CAST('[Your start date]' AS TIMESTAMP)
      AND h.event_time < CAST('[Your end date]' AS TIMESTAMP)
),
requisition_amended AS (
    SELECT
        CAST(h.requisition_id AS VARCHAR(255)) AS PurchaseRequisitionId,
        'Requisition Amended' AS ActivityName,
        CAST(h.event_time AS TIMESTAMP) AS EventTime,
        'Coupa' AS SourceSystem,
        CAST(h.last_data_update AS TIMESTAMP) AS LastDataUpdate,
        CAST(r.status AS VARCHAR(255)) AS RequisitionStatus,
        CAST(r.requester AS VARCHAR(255)) AS Requester,
        CAST(r.department AS VARCHAR(255)) AS Department,
        CAST(r.total_amount AS DECIMAL(38, 10)) AS TotalAmount,
        CAST(h.user_name AS VARCHAR(255)) AS Approver
    FROM [Your requisition history or audit object] h
    LEFT JOIN [Your requisition header object] r ON CAST(r.requisition_id AS VARCHAR(255)) = CAST(h.requisition_id AS VARCHAR(255))
    WHERE LOWER(CAST(h.event_type AS VARCHAR(255))) IN ('amended', 'updated', 'version_created')
      AND h.event_time >= CAST('[Your start date]' AS TIMESTAMP)
      AND h.event_time < CAST('[Your end date]' AS TIMESTAMP)
),
approval_step_started AS (
    SELECT
        CAST(a.requisition_id AS VARCHAR(255)) AS PurchaseRequisitionId,
        'Approval Step Started' AS ActivityName,
        CAST(a.created_at AS TIMESTAMP) AS EventTime,
        'Coupa' AS SourceSystem,
        CAST(a.last_data_update AS TIMESTAMP) AS LastDataUpdate,
        CAST(r.status AS VARCHAR(255)) AS RequisitionStatus,
        CAST(r.requester AS VARCHAR(255)) AS Requester,
        CAST(r.department AS VARCHAR(255)) AS Department,
        CAST(r.total_amount AS DECIMAL(38, 10)) AS TotalAmount,
        CAST(a.approver AS VARCHAR(255)) AS Approver
    FROM [Your approval object] a
    LEFT JOIN [Your requisition header object] r ON CAST(r.requisition_id AS VARCHAR(255)) = CAST(a.requisition_id AS VARCHAR(255))
    WHERE LOWER(CAST(a.status AS VARCHAR(255))) = 'pending'
      AND a.created_at >= CAST('[Your start date]' AS TIMESTAMP)
      AND a.created_at < CAST('[Your end date]' AS TIMESTAMP)
),
approval_step_approved AS (
    SELECT
        CAST(a.requisition_id AS VARCHAR(255)) AS PurchaseRequisitionId,
        'Approval Step Approved' AS ActivityName,
        CAST(a.action_time AS TIMESTAMP) AS EventTime,
        'Coupa' AS SourceSystem,
        CAST(a.last_data_update AS TIMESTAMP) AS LastDataUpdate,
        CAST(r.status AS VARCHAR(255)) AS RequisitionStatus,
        CAST(r.requester AS VARCHAR(255)) AS Requester,
        CAST(r.department AS VARCHAR(255)) AS Department,
        CAST(r.total_amount AS DECIMAL(38, 10)) AS TotalAmount,
        CAST(a.approver AS VARCHAR(255)) AS Approver
    FROM [Your approval object] a
    LEFT JOIN [Your requisition header object] r ON CAST(r.requisition_id AS VARCHAR(255)) = CAST(a.requisition_id AS VARCHAR(255))
    WHERE LOWER(CAST(a.action AS VARCHAR(255))) = 'approved'
      AND a.action_time >= CAST('[Your start date]' AS TIMESTAMP)
      AND a.action_time < CAST('[Your end date]' AS TIMESTAMP)
),
approval_step_rejected AS (
    SELECT
        CAST(a.requisition_id AS VARCHAR(255)) AS PurchaseRequisitionId,
        'Approval Step Rejected' AS ActivityName,
        CAST(a.action_time AS TIMESTAMP) AS EventTime,
        'Coupa' AS SourceSystem,
        CAST(a.last_data_update AS TIMESTAMP) AS LastDataUpdate,
        CAST(r.status AS VARCHAR(255)) AS RequisitionStatus,
        CAST(r.requester AS VARCHAR(255)) AS Requester,
        CAST(r.department AS VARCHAR(255)) AS Department,
        CAST(r.total_amount AS DECIMAL(38, 10)) AS TotalAmount,
        CAST(a.approver AS VARCHAR(255)) AS Approver
    FROM [Your approval object] a
    LEFT JOIN [Your requisition header object] r ON CAST(r.requisition_id AS VARCHAR(255)) = CAST(a.requisition_id AS VARCHAR(255))
    WHERE LOWER(CAST(a.action AS VARCHAR(255))) = 'rejected'
      AND a.action_time >= CAST('[Your start date]' AS TIMESTAMP)
      AND a.action_time < CAST('[Your end date]' AS TIMESTAMP)
),
requisition_withdrawn AS (
    SELECT
        CAST(h.requisition_id AS VARCHAR(255)) AS PurchaseRequisitionId,
        'Requisition Withdrawn' AS ActivityName,
        CAST(h.event_time AS TIMESTAMP) AS EventTime,
        'Coupa' AS SourceSystem,
        CAST(h.last_data_update AS TIMESTAMP) AS LastDataUpdate,
        CAST(r.status AS VARCHAR(255)) AS RequisitionStatus,
        CAST(r.requester AS VARCHAR(255)) AS Requester,
        CAST(r.department AS VARCHAR(255)) AS Department,
        CAST(r.total_amount AS DECIMAL(38, 10)) AS TotalAmount,
        CAST(h.user_name AS VARCHAR(255)) AS Approver
    FROM [Your requisition history or audit object] h
    LEFT JOIN [Your requisition header object] r ON CAST(r.requisition_id AS VARCHAR(255)) = CAST(h.requisition_id AS VARCHAR(255))
    WHERE LOWER(CAST(h.event_type AS VARCHAR(255))) IN ('withdrawn', 'withdrawal', 'cancelled_before_approval')
      AND h.event_time >= CAST('[Your start date]' AS TIMESTAMP)
      AND h.event_time < CAST('[Your end date]' AS TIMESTAMP)
),
requisition_approved AS (
    SELECT
        CAST(h.requisition_id AS VARCHAR(255)) AS PurchaseRequisitionId,
        'Requisition Approved' AS ActivityName,
        CAST(h.event_time AS TIMESTAMP) AS EventTime,
        'Coupa' AS SourceSystem,
        CAST(h.last_data_update AS TIMESTAMP) AS LastDataUpdate,
        CAST(r.status AS VARCHAR(255)) AS RequisitionStatus,
        CAST(r.requester AS VARCHAR(255)) AS Requester,
        CAST(r.department AS VARCHAR(255)) AS Department,
        CAST(r.total_amount AS DECIMAL(38, 10)) AS TotalAmount,
        CAST(h.user_name AS VARCHAR(255)) AS Approver
    FROM [Your requisition history or audit object] h
    LEFT JOIN [Your requisition header object] r ON CAST(r.requisition_id AS VARCHAR(255)) = CAST(h.requisition_id AS VARCHAR(255))
    WHERE LOWER(CAST(h.new_status AS VARCHAR(255))) = 'approved'
      AND h.event_time >= CAST('[Your start date]' AS TIMESTAMP)
      AND h.event_time < CAST('[Your end date]' AS TIMESTAMP)
),
requisition_rejected AS (
    SELECT
        CAST(h.requisition_id AS VARCHAR(255)) AS PurchaseRequisitionId,
        'Requisition Rejected' AS ActivityName,
        CAST(h.event_time AS TIMESTAMP) AS EventTime,
        'Coupa' AS SourceSystem,
        CAST(h.last_data_update AS TIMESTAMP) AS LastDataUpdate,
        CAST(r.status AS VARCHAR(255)) AS RequisitionStatus,
        CAST(r.requester AS VARCHAR(255)) AS Requester,
        CAST(r.department AS VARCHAR(255)) AS Department,
        CAST(r.total_amount AS DECIMAL(38, 10)) AS TotalAmount,
        CAST(h.user_name AS VARCHAR(255)) AS Approver
    FROM [Your requisition history or audit object] h
    LEFT JOIN [Your requisition header object] r ON CAST(r.requisition_id AS VARCHAR(255)) = CAST(h.requisition_id AS VARCHAR(255))
    WHERE LOWER(CAST(h.new_status AS VARCHAR(255))) = 'rejected'
      AND h.event_time >= CAST('[Your start date]' AS TIMESTAMP)
      AND h.event_time < CAST('[Your end date]' AS TIMESTAMP)
),
requisition_sourced AS (
    SELECT
        CAST(s.requisition_id AS VARCHAR(255)) AS PurchaseRequisitionId,
        'Requisition Sourced' AS ActivityName,
        CAST(s.created_at AS TIMESTAMP) AS EventTime,
        'Coupa' AS SourceSystem,
        CAST(s.last_data_update AS TIMESTAMP) AS LastDataUpdate,
        CAST(r.status AS VARCHAR(255)) AS RequisitionStatus,
        CAST(r.requester AS VARCHAR(255)) AS Requester,
        CAST(r.department AS VARCHAR(255)) AS Department,
        CAST(r.total_amount AS DECIMAL(38, 10)) AS TotalAmount,
        CAST(NULL AS VARCHAR(255)) AS Approver
    FROM [Your sourcing relationship object] s
    LEFT JOIN [Your requisition header object] r ON CAST(r.requisition_id AS VARCHAR(255)) = CAST(s.requisition_id AS VARCHAR(255))
    WHERE s.created_at >= CAST('[Your start date]' AS TIMESTAMP)
      AND s.created_at < CAST('[Your end date]' AS TIMESTAMP)
),
purchase_order_created AS (
    SELECT
        CAST(p.requisition_id AS VARCHAR(255)) AS PurchaseRequisitionId,
        'Purchase Order Created' AS ActivityName,
        CAST(p.created_at AS TIMESTAMP) AS EventTime,
        'Coupa' AS SourceSystem,
        CAST(p.last_data_update AS TIMESTAMP) AS LastDataUpdate,
        CAST(r.status AS VARCHAR(255)) AS RequisitionStatus,
        CAST(r.requester AS VARCHAR(255)) AS Requester,
        CAST(r.department AS VARCHAR(255)) AS Department,
        CAST(r.total_amount AS DECIMAL(38, 10)) AS TotalAmount,
        CAST(NULL AS VARCHAR(255)) AS Approver
    FROM [Your purchase order relationship object] p
    LEFT JOIN [Your requisition header object] r ON CAST(r.requisition_id AS VARCHAR(255)) = CAST(p.requisition_id AS VARCHAR(255))
    WHERE p.created_at >= CAST('[Your start date]' AS TIMESTAMP)
      AND p.created_at < CAST('[Your end date]' AS TIMESTAMP)
),
requisition_closed AS (
    SELECT
        CAST(h.requisition_id AS VARCHAR(255)) AS PurchaseRequisitionId,
        'Requisition Closed' AS ActivityName,
        CAST(h.event_time AS TIMESTAMP) AS EventTime,
        'Coupa' AS SourceSystem,
        CAST(h.last_data_update AS TIMESTAMP) AS LastDataUpdate,
        CAST(r.status AS VARCHAR(255)) AS RequisitionStatus,
        CAST(r.requester AS VARCHAR(255)) AS Requester,
        CAST(r.department AS VARCHAR(255)) AS Department,
        CAST(r.total_amount AS DECIMAL(38, 10)) AS TotalAmount,
        CAST(h.user_name AS VARCHAR(255)) AS Approver
    FROM [Your requisition history or audit object] h
    LEFT JOIN [Your requisition header object] r ON CAST(r.requisition_id AS VARCHAR(255)) = CAST(h.requisition_id AS VARCHAR(255))
    WHERE LOWER(CAST(h.event_type AS VARCHAR(255))) IN ('closed', 'closure', 'cancelled_after_approval')
      AND h.event_time >= CAST('[Your start date]' AS TIMESTAMP)
      AND h.event_time < CAST('[Your end date]' AS TIMESTAMP)
)
SELECT PurchaseRequisitionId, ActivityName, EventTime, SourceSystem, LastDataUpdate, RequisitionStatus, Requester, Department, TotalAmount, Approver FROM requisition_created
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, SourceSystem, LastDataUpdate, RequisitionStatus, Requester, Department, TotalAmount, Approver FROM requisition_submitted
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, SourceSystem, LastDataUpdate, RequisitionStatus, Requester, Department, TotalAmount, Approver FROM requisition_amended
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, SourceSystem, LastDataUpdate, RequisitionStatus, Requester, Department, TotalAmount, Approver FROM approval_step_started
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, SourceSystem, LastDataUpdate, RequisitionStatus, Requester, Department, TotalAmount, Approver FROM approval_step_approved
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, SourceSystem, LastDataUpdate, RequisitionStatus, Requester, Department, TotalAmount, Approver FROM approval_step_rejected
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, SourceSystem, LastDataUpdate, RequisitionStatus, Requester, Department, TotalAmount, Approver FROM requisition_withdrawn
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, SourceSystem, LastDataUpdate, RequisitionStatus, Requester, Department, TotalAmount, Approver FROM requisition_approved
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, SourceSystem, LastDataUpdate, RequisitionStatus, Requester, Department, TotalAmount, Approver FROM requisition_rejected
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, SourceSystem, LastDataUpdate, RequisitionStatus, Requester, Department, TotalAmount, Approver FROM requisition_sourced
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, SourceSystem, LastDataUpdate, RequisitionStatus, Requester, Department, TotalAmount, Approver FROM purchase_order_created
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, SourceSystem, LastDataUpdate, RequisitionStatus, Requester, Department, TotalAmount, Approver FROM requisition_closed
ORDER BY PurchaseRequisitionId, EventTime, ActivityName;

準備はできましたか？

このテンプレートを使って、Coupaの調達から支払いまでの購買申請プロセスを今日から改善しましょう。調達業務の改善につながる情報を見つけ、効率化を進められます。

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

CoupaのP2P購買申請を最適化し、今日からサイクルタイムを短縮

非効率な箇所を特定し、P2P購買申請のサイクルタイムを30％短縮します。

無料トライアルを開始

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

調達から支払いまで：購買申請のデータテンプレート

調達から支払いまで：購買申請のデータテンプレート

調達から支払いまで：購買依頼の属性

調達から支払いまで：購買依頼のアクティビティ

抽出ガイド

購買申請データをCoupaの定期レポートでエクスポートする方法

ステップ

設定

a サンプルクエリ config

Coupa REST APIを使ったPythonスクリプトによる抽出

ステップ

設定

a サンプルクエリ python

サードパーティ製iPaaSコネクターを使った抽出

ステップ

設定

a サンプルクエリ config

準備はできましたか？

CoupaのP2P購買申請を最適化し、今日からサイクルタイムを短縮

調達から支払いまで：購買申請のデータテンプレート

調達から支払いまで：購買申請のデータテンプレート

調達から支払いまで：購買依頼の属性

調達から支払いまで：購買依頼のアクティビティ

抽出ガイド

購買申請データをCoupaの定期レポートでエクスポートする方法

ステップ

設定

a サンプルクエリ config

Coupa REST APIを使ったPythonスクリプトによる抽出

ステップ

設定

a サンプルクエリ python

サードパーティ製iPaaSコネクターを使った抽出

ステップ

設定

a サンプルクエリ config

準備はできましたか？

CoupaのP2P購買申請を最適化し、今日からサイクルタイムを短縮

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