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

調達から支払いまで - 申請データテンプレート

Coupa

購買から支払いまで - 購買依頼属性 (22) 購買から支払いまで - 購買依頼アクティビティ (12) 抽出ガイド (3)

調達から支払いまで - 申請データテンプレート

この包括的なデータテンプレートは、お客様の購買から支払いまでの購買依頼プロセスを分析するために必要な情報を収集するための構造化されたアプローチを提供します。堅牢なイベントログに不可欠な属性とアクティビティを概説しています。また、Coupaシステムからこのデータを効果的に抽出するためのガイダンスも含まれています。

包括的な分析のための推奨属性
追跡すべき主要なプロセスアクティビティ
実践的なデータ抽出ガイド

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

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

購買から支払いまで - 購買依頼属性

これらは、お客様の購買から支払いまでの購買依頼プロセスを包括的に分析するために、イベントログに含めることを推奨するデータフィールドです。

5 必須 5 推奨 12 任意

	名前	説明
	アクティビティ名 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が割り当てられ、そのライフサイクルを通じて一定のままです。これにより、初期作成と提出から、すべての承認または却下ステップ、最終的な調達とクローズまで、購買依頼のエンドツーエンドの追跡が可能になります。プロセスマイニングでは、すべてのイベントログエントリがこのIDに紐付けられ、各ケースの完全なジャーニーを再構築できます。その重要性これはすべてのプロセスステップを結びつける必須のケースIDであり、購買依頼のライフサイクルを最初から最後まで完全に分析することを可能にします。取得元これはCoupaの購買依頼モジュールおよび関連するデータエクスポートに見られる主キーフィールドです。例 PR-102934PR-102935PR-102936
	ソースシステム SourceSystem	データが抽出されたソースシステムを特定します。
説明この属性は、プロセスデータの発生元となるシステムオブレコードを指定します。この分析では、値は常に「Coupa」となります。このフィールドを含めることは、特に複数のシステムからデータが統合される可能性のある環境において、ベストプラクティスです。データリネージに関する重要なコンテキストを提供し、データガバナンスと品質ルールの管理に役立ちます。その重要性明確なデータリネージを提供します。これはデータガバナンスや、複数の企業システムからのデータを統合する際に不可欠です。取得元これは通常、データ抽出および変換プロセス中にデータセットの起源を識別するために追加される静的な値です。例 Coupa
	最終データ更新 LastDataUpdate	ソースシステムからデータが最後に更新されたことを示すタイムスタンプです。
説明この属性は、Coupaからの最新のデータ抽出日時を記録します。これにより、分析対象データの鮮度に関する透明性が提供されます。データの鮮度を知ることは、インサイトが現在の運用状態を反映しているのか、それとも過去の時点を反映しているのかをユーザーが理解するために不可欠です。これは、継続的な運用を監視するダッシュボードにとって特に重要です。その重要性データの鮮度をユーザーに伝え、分析の期間を理解し、最新情報に基づいて意思決定を行えるようにします。取得元このタイムスタンプは、データパイプラインまたはETLツールによって、データ抽出の成功実行の最後に生成され追加されます。例 2024-05-21T02:00:00Z
	リクエスター Requester	購買依頼を作成し提出した従業員。
説明この属性は、要求を開始した個人を特定します。申請者別にデータを分析することで、変更率が高い、却下が多いなど、特定のユーザーに関連するパターンを特定でき、追加トレーニングの必要性を示唆する場合があります。また、異なるユーザーまたはユーザーグループの購買依頼量とプロセス動作を分析するためにも使用されます。その重要性ユーザーごとのプロセス行動分析を可能にし、トレーニングの必要性を特定したり、異なる個人がプロセスとどのように関わっているかを理解するのに役立ちます。取得元 Coupaの申請書オブジェクト上の標準フィールドとして利用可能で、多くの場合、ユーザーオブジェクトにリンクされ、「requester」または「created_by」と名付けられます。例 Alice JohnsonBob SmithCharlie Brown
	合計金額 TotalAmount	購買依頼の合計金額。
説明この属性は、購買依頼で要求されたすべての物品およびサービスの合計費用を表します。この金額は、承認ワークフローの複雑さに影響を与えることが多いため、プロセス分析における重要な要素です。価値の高い購買依頼は、通常、より多くの承認ステップを必要とします。価値帯（例：1000ドル未満、1000ドル～10000ドル）別にプロセス指標を分析することで、プロセスが異なる財務的意義を持つ購買依頼をどのように処理しているかを明らかにできます。その重要性異なる金額の申請書に対してプロセスがどのように変化するかを分析するのに役立ちます。金額が大きいほど、より複雑な承認ワークフローがトリガーされることが多いためです。取得元これはCoupaの購買依頼オブジェクトのヘッダーにある標準フィールドで、通常は「total」または「total_amount」という名前です。例 500.0012550.7599.99
	承認者 Approver	承認活動を担当するユーザーまたはグループ。
説明この属性は、承認ステップに割り当てられた特定の個人または承認グループを識別します。「承認ステップ開始」、「承認ステップ承認」、「承認ステップ却下」などのアクティビティで設定されます。承認者別にデータを分析することは、「承認者のパフォーマンスと負荷」ダッシュボードを構築する上で重要です。これにより、個々の承認時間を測定し、特定の承認者によって引き起こされるボトルネックを特定し、ワークロードの配分を評価するのに役立ちます。その重要性承認者のパフォーマンス、ワークロードのバランス、特定の個人または承認グループに関連するボトルネックの特定に不可欠です。取得元この情報はCoupaの各購買依頼に関連する承認チェーンの詳細にあります。ユーザーデータとの結合が必要になる場合があります。例 David Miller財務承認者L2Susan Chen
	購買依頼ステータス RequisitionStatus	購買依頼の現在の、または最終的なステータス。
説明この属性は、データ抽出時または最終結果における購買依頼の全体的な状態を示します。一般的なステータスには、「承認待ち」、「承認済み」、「却下済み」、「撤回済み」、「クローズ済み」などがあります。これはフィルタリングと分析のための重要な側面です。承認率と却下率の計算、未処理の購買依頼の現在のワークロードの監視、および要求の最終処分を理解するために使用されます。その重要性申請結果の理解、承認率と却下率の計算、および進行中の申請書の現状監視に不可欠です。取得元これはCoupaの購買依頼オブジェクトの標準フィールドで、多くの場合「status」または「state」という名前です。例承認待ち承認済み却下取り消し済みクローズ
	部署 Department	購買依頼が計上される事業部門またはコストセンター。
説明部門属性は、各購買依頼を特定の組織単位またはコストセンターにリンクさせます。これは比較分析にとって重要な側面です。これにより、ダッシュボードやKPIを部門別にフィルタリング・セグメント化することができ、管理者は組織内の異なる部門間で承認サイクルタイム、却下率、コンプライアンスを比較できます。これは、部門固有の問題やベストプラクティスを特定するのに役立ちます。その重要性サイクルタイムや却下率などのプロセスKPIを異なる事業部門間で比較し、改善領域を明確にすることを可能にします。取得元これはCoupaの購買依頼オブジェクトにある標準フィールドで、多くの場合、申請者のユーザープロファイルに関連付けられているか、購買依頼明細で指定されています。例マーケティングIT運用施設研究開発
	`購買発注`ID PurchaseOrderId	承認された購買依頼から作成された購買発注の識別子。
説明購買依頼が完全に承認され、調達が完了すると、通常、購買発注が作成されます。この属性は、その結果として作成されたPOのIDを保存します。これは、上流の購買依頼プロセスと下流の購買発注プロセス間の重要なリンクとして機能します。「購買依頼承認からPO作成までの時間」というKPIの算出を可能にし、購買から支払いまでのサイクル全体のエンドツーエンドの広範な分析を可能にします。その重要性購買依頼をその後の購買発注にリンクさせることで、引き渡し時間の分析を可能にし、より広範なP2Pプロセスのエンドツーエンドの可視化を促進します。取得元これはCoupaの購買依頼オブジェクトにある標準フィールドで、POが作成された後に設定されます。例 PO-45000123PO-45000124PO-45000125
	仕入先名 SupplierName	購買依頼で選択されたサプライヤーまたはベンダーの名前。
説明この属性は、要求された物品またはサービスの意図されたサプライヤーを特定します。サプライヤーは申請者によって指定されるか、ソーシングプロセス中に後から追加される場合があります。サプライヤー別にプロセス指標を分析することで、サプライヤーのパフォーマンスを評価し、特定のサプライヤーとのやり取りがサイクルタイムの延長やその他のプロセス非効率性につながるかどうかを特定するのに役立ちます。これは、調達戦略とサプライヤー関係管理にとって重要なコンテキストを提供します。その重要性選択されたサプライヤーに基づいたプロセスパフォーマンス分析を可能にし、ソーシング戦略やサプライヤー管理に情報を提供できます。取得元この情報はCoupaの購買依頼明細オブジェクトで利用可能で、多くの場合「supplier」または「vendor」フィールドとして提供されます。例ステープルズデル・テクノロジーズアクセンチュアCDW
	依頼種別 RequisitionType	購買依頼のカテゴリまたはタイプ（「設備投資」、「運用費用」、「ソフトウェア」など）。
説明購買依頼タイプは、その事業目的や購入の性質に基づいて購買依頼を分類するのに役立つ分類です。この属性は、コンプライアンス分析や、異なるタイプの要求がプロセス内でどのように流れるかを理解する上で価値があります。例えば、設備投資の要求は、標準的な業務上の要求よりも厳格で長い承認経路をたどる可能性があります。購買依頼タイプ別にプロセスを分析することで、プロセス最適化のための貴重な洞察が明らかになります。その重要性申請の事業目的別に分析をセグメント化することを可能にします。異なるタイプの申請は、独自のプロセスフローやポリシーを持つ場合があるためです。取得元これはCoupaの購買依頼オブジェクトにあるカスタムフィールドまたは標準分類フィールドである可能性が高いです。例設備投資運用費用ITハードウェアプロフェッショナルサービス
	却下理由 RejectionReason	承認者によって、購買依頼または承認ステップが却下された際に提供される理由。
説明承認者が購買依頼を却下する際、その決定理由を提供することがよくあります。この属性はそのテキストによる説明を捕捉します。却下理由を分析することで、購買依頼が失敗する理由に関する直接的で定性的なフィードバックが得られます。この洞察は、根本原因分析にとって非常に貴重であり、誤ったコーディング、予算不足、不十分な正当性など、一般的な問題を特定するのに役立ち、その後トレーニングやプロセス改善を通じて対処することができます。その重要性プロセス失敗の根本原因に対する直接的な洞察を提供し、ユーザー研修やプロセス明確化が必要な領域の特定に役立ちます。取得元この情報は通常、購買依頼の承認履歴における「却下済み」ステータス変更に関連するコメントまたはメモフィールドに記録されます。例不正確なコストセンター今四半期の予算超過重複`申請`十分な正当性が提供されていません
	品目 Commodity	要求される物品またはサービスの高レベルなカテゴリ。
説明品目属性は、購買依頼上の品目（「オフィス用品」、「コンピューターハードウェア」、「マーケティングサービス」など）に標準化された分類を提供します。これにより、購入品目に基づいた購買パターンとプロセスバリエーションの分析が可能になります。特定の品目には専門的な承認要件や調達戦略が必要な場合があり、品目別にプロセスを分析することで、異なる支出カテゴリにおける調達を最適化するのに役立ちます。その重要性支出カテゴリを分析し、承認時間などのプロセス行動が購入する商品やサービスの種類によって異なるかどうかを理解するのに役立ちます。取得元これはCoupaの標準フィールドであり、通常は購買依頼明細レベルで利用可能です。ヘッダーレベルに集約する必要がある場合があります。例オフィス用品コンピューターハードウェアマーケティングサービス旅行
	変更済み IsAmended	申請書が初回提出後に1回以上修正された場合に真となるブール値フラグです。
説明この計算された属性は、特定のケースで「購買依頼変更済み」アクティビティが発生したかどうかを示す単純なフラグ（True/False）です。これにより、変更が必要だった購買依頼をユーザーが容易に分離できるため、分析とフィルタリングが簡素化されます。これは購買依頼変更率KPIの計算と、「購買依頼変更ボリューム」ダッシュボードの機能提供に使用され、手戻りの根本原因を特定し、初回品質を向上させるのに役立ちます。その重要性変更率KPIの計算を簡素化し、手戻りが必要だったケースとそうでないケースを容易にセグメント化することを可能にします。取得元これは、プロセスマイニングツールで、各ケースのイベントログ内に「購買依頼変更済み」アクティビティが存在するかどうかを確認することで計算されます。例 truefalse
	承認ステップ数 ApprovalStepCount	購買依頼が経由した承認ステップの総数。
説明この計算された属性は、各購買依頼における個別の「承認ステップ承認済み」アクティビティの数をカウントします。これにより、各ケースの承認ワークフローの複雑さを定量化するのに役立ちます。これは「平均承認ステップ数」KPIの基礎となり、通常よりも長いまたは複雑な承認経路をたどる購買依頼を特定するのに有用であり、ワークフローの簡素化が必要であることを示唆する場合があります。その重要性各購買依頼の承認ワークフローの複雑さを定量化し、効率化が必要な過度に複雑なパスを特定するのに役立ちます。取得元このメトリックは、各ケースIDについて「承認ステップ承認済み」の発生数をカウントすることにより、プロセスマイニングツールで計算されます。例 253
	承認ステップ期間 ApprovalStepDuration	購買依頼が単一の承認ステップで待機した時間。
説明この計算された指標は、「承認ステップ開始」アクティビティとその対応する「承認ステップ承認済み」または「承認ステップ却下済み」アクティビティ間の期間を測定します。これにより、承認チェーンの各個別の段階での待機時間が分離されます。これは、「重要な承認ステップのボトルネック」ダッシュボードにとって極めて重要であり、プロセス全体で最も significant な遅延を引き起こしている承認者または承認段階を正確に特定します。その重要性承認ワークフロー内の特定のボトルネックを、総サイクルタイムだけでなく、各個別ステップでの待機時間を測定することで特定します。取得元プロセスマイニングツール内で、「承認ステップ開始」とその後の最終承認イベント（承認済み/却下済み）との時間差を計算して算出されます。例 1.2日4時間3.8日
	承認ワークフローパス ApprovalWorkflowPath	申請書に適用された特定の承認チェーンまたはワークフローテンプレートの識別子。
説明この属性は、購買依頼が従うべき承認者の事前定義されたシーケンスを識別します。これは、金額、部門、購買依頼タイプなどの要因に基づいてビジネスルールによって決定されます。この属性の分析は、「購買依頼ポリシーコンプライアンス」ダッシュボードの中心です。承認者の実際のシーケンスと割り当てられたワークフローパスを比較することで、逸脱を検出し、適合率を測定し、未管理の例外を特定することが可能になります。その重要性予期される承認ステップと実際の承認ステップを比較できるようにすることでコンプライアンス分析を可能にし、プロセス逸脱を浮き彫りにします。取得元 Coupaのドキュメントを参照してください。これは、申請書に対してトリガーされた承認チェーンまたはワークフロールールの名前から派生する場合があります。例標準承認 5千ドル未満ITハードウェア承認 1万ドル以上設備投資CFOレビュー
	緊急度レベル UrgencyLevel	申請書の緊急度を示す分類で、「高」「中」「低」などがあります。
説明緊急度レベルは、しばしば優先度フィールドにマッピングされ、申請者が迅速な処理を必要とする要求にフラグを立てることを可能にします。この属性は、「緊急購買依頼処理時間」ダッシュボードにとって不可欠です。緊急度の高い購買依頼のサイクルタイムを標準的なものと比較することで、組織は優先順位付けメカニズムが効果的であるか、緊急のビジネスニーズがタイムリーに満たされているかを評価できます。その重要性緊急の申請が通常の申請よりも迅速に処理されているかを分析し、優先順位付けポリシーの有効性を検証することを可能にします。取得元これはCoupaの購買依頼オブジェクトの標準フィールドまたはカスタムフィールドである可能性があります。Coupaのドキュメントまたはシステム構成を参照してください。例高中低
	購買依頼承認サイクルタイム RequisitionApprovalCycleTime	購買依頼が最初に提出されてから最終承認を受けるまでの合計経過時間。
説明これは、コア承認プロセスの期間を測定する計算メトリックです。各ケースの「購買依頼提出済み」アクティビティと「購買依頼承認済み」アクティビティの間の時間差を求めることで算出されます。承認ワークフローの効率を直接定量化するため、このプロセスにおいて最も重要なKPIの1つです。パフォーマンスの追跡、ボトルネックの特定、プロセス改善イニシアチブの影響測定のために、複数のダッシュボードで使用されます。その重要性これはプロセス効率を測定するための主要なKPIです。承認にかかる時間を定量化し、ボトルネックを特定するために不可欠です。取得元このメトリックは、プロセスマイニングツールにおいて、「購買依頼提出済み」のタイムスタンプを「購買依頼承認済み」のタイムスタンプから差し引くことで計算されます。例 2.5日8時間15.2日
	通貨 Currency	購買依頼の合計金額の通貨コード。
説明この属性は、購買依頼の合計金額がどの通貨（例：USD、EUR、GBP）で表示されているかを指定します。これは、特に複数の通貨で事業を行う多国籍企業にとって、あらゆる財務分析に不可欠なコンテキストです。これにより、金銭的価値が正しく解釈され、財務報告やダッシュボードでの適切な換算と集計が可能になります。その重要性「合計金額」属性に必要なコンテキストを提供し、多通貨環境での正確な財務分析を保証します。取得元これはCoupaの購買依頼オブジェクトにある標準フィールドで、通常「currency_code」などの名前です。例 USDEURGBP

必須推奨任意

購買から支払いまで - 購買依頼アクティビティ

これらは、お客様の購買から支払いまでの購買依頼ワークフローを正確に発見するために、イベントログにキャプチャすべき主要なプロセスステップとマイルストーンです。

6 推奨 6 任意

	アクティビティ	説明
	依頼書承認済み	購買依頼は、承認ワークフローのすべての必須ステップを正常に通過しました。これは、購買依頼ヘッダーの全体ステータスが「承認済み」に変更されたことから推測されます。
その重要性これは承認サイクルの終了を示す重要な成功マイルストーンです。このアクティビティに到達するまでの時間は主要なKPIであり、下流の調達アクションのトリガーとして機能します。取得元「requisition_headers」テーブルのステータスが「承認済み」に更新された際に発生するステータス変更から推測されます。タイムスタンプは関連する監査証跡に記録されます。取得申請書全体のステータスが「承認済み」に変更されたときのタイムスタンプを特定します。イベントタイプ inferred
	採用申請作成済み	新しい購買申請がユーザーによって開始され、下書きとして保存されます。これはすべての申請ケースの出発点であり、通常、申請書レコード自体の作成タイムスタンプから推測されます。
その重要性このアクティビティは、購買依頼ライフサイクルの開始を示します。作成から提出までの時間を分析することで、ユーザーの不確実性やシステムの複雑さに起因する遅延を明らかにできます。取得元このイベントは、特定の購買依頼IDに関する「requisition_headers」テーブルの「created-at」タイムスタンプからキャプチャされます。取得購買依頼ヘッダーレコードの作成タイムスタンプを使用してください。イベントタイプ inferred
	申請提出済	申請者は、完成した購買依頼を正式に承認ワークフローに提出します。このイベントは、システムの監査ログまたは履歴テーブルで、購買依頼のステータスが「ドラフト」から「承認待ち」に変化することから推測されます。
その重要性提出は承認プロセスをトリガーし、「平均購買依頼承認サイクルタイム」KPIを測定する上で重要なマイルストーンとなります。この時点以前の遅延はユーザー関連であり、その後の遅延はプロセス関連です。取得元「requisition_headers」テーブルのステータス変更、特に「status」フィールドが「承認待ち」に変化したことから推測されます。この変更のタイムスタンプは関連する監査証跡で確認できます。取得申請ステータスが最初に「承認待ち」に変更されたときのタイムスタンプを特定します。イベントタイプ inferred
	発注作成済み	承認された申請書の情報に基づいて、発注書（PO）が正常に生成されます。このイベントは、ソース申請書IDを参照するPOレコードが作成されたときに推測されます。
その重要性これは購買依頼プロセスの主要な成功結果であり、購買から支払いまでの次の段階への引き渡しを示します。「購買依頼承認済み」からこのイベントまでの時間を分析することで、実行における遅延を浮き彫りにします。取得元元の「requisition_headers」または「requisition_lines」IDへの参照を含む「purchase_orders」テーブル内のレコードの作成から推測されます。取得購買依頼IDにリンクされたPOレコードの「created-at」タイムスタンプを使用してください。イベントタイプ inferred
	購買依頼クローズ済み	購買依頼は正式にクローズされ、それ以上の措置が取られないことを示します。これは、POが作成され履行された後、または承認後だが発注前で購買依頼がキャンセルされた場合に発生する可能性があります。
その重要性このアクティビティは、購買依頼のライフサイクルにおける決定的な終点として機能します。これにより、ケースが明確に完結し、プロセス分析で無期限に「アクティブ」として表示されるのを防ぎます。取得元「requisition_headers」テーブルのステータスが「クローズ済み」に更新された際に発生するステータス変更から推測されます。タイムスタンプは関連する監査証跡に記録されます。取得申請書全体のステータスが「クローズ済み」に変更されたときのタイムスタンプを特定します。イベントタイプ inferred
	購買依頼却下済み	購買依頼は承認プロセス中に最終的に却下され、購買発注には変換されません。これは、購買依頼ヘッダーの全体ステータスが「却下済み」に変更されたことから推測されます。
その重要性このアクティビティは、プロセスにおける最終的な失敗を表します。これらのイベントを分析することは、「購買依頼却下率」を改善し、ポリシー違反や予算問題などの根本原因を特定する上で重要です。取得元「requisition_headers」テーブルのステータスが「却下済み」に更新された際に発生するステータス変更から推測されます。タイムスタンプは関連する監査証跡に記録されます。取得申請書全体のステータスが「却下済み」に変更されたときのタイムスタンプを特定します。イベントタイプ inferred
	承認ステップ却下済み	ワークフローの段階で個々の承認者が申請書を却下し、通常は修正のために申請者に戻します。これはCoupaによって記録される明示的なアクションです。
その重要性どのステップでの却下も、手戻りを発生させ、サイクルタイムを延長させます。却下が発生する場所とその理由を分析することは、プロセス改善とユーザー研修にとって極めて重要です。取得元特定の申請書と承認者にリンクされた「承認」テーブルまたはその監査証跡に記録された明示的な「却下」アクションから取得されます。取得申請書の承認履歴から「却下」イベントをフィルタリングします。イベントタイプ explicit
	承認ステップ承認済み	ワークフロー内の個々の承認者が申請書を承認します。これは、特定のタイムスタンプとユーザー情報とともにシステムによって記録される明示的なアクションです。
その重要性このアクティビティは、承認プロセスフローに関する詳細な洞察を提供します。これらのステップを集計することで、「承認ステップごとの平均待機時間」を計算し、承認者のパフォーマンスを分析するのに役立ちます。取得元特定の申請書と承認者にリンクされた「承認」テーブルまたはその監査証跡に記録された明示的な「承認」アクションから取得されます。取得申請書の承認履歴から「承認」イベントをフィルタリングします。イベントタイプ explicit
	承認ステップ開始	特定の承認者または承認グループに承認タスクが割り当てられ、申請書は彼らのアクションを待っている状態です。これは、申請書に関連付けられた承認レコードが「保留中」ステータスで作成されたときに推測されます。
その重要性これは、特定の承認の待機時間の開始を示します。これと対応する「承認ステップ承認済み/却下済み」の間の期間を測定することは、承認チェーンにおける特定のボトルネックを特定するのに役立ちます。取得元申請書にリンクされた「承認」テーブル内のレコードの作成タイムスタンプから推測されます。そこでは、承認者のアクションステータスが「保留中」またはそれに相当するものです。取得承認チェーン内の個人の承認待ち記録の作成タイムスタンプを使用してください。イベントタイプ inferred
	購買依頼変更済み	購買依頼は、提出後に申請者またはその他の承認されたユーザーによって編集されます。Coupaはこれを新しいバージョンまたは監査エントリとして明示的にログに記録し、多くの場合、承認ワークフローの一部または全体をリセットします。
その重要性変更を追跡することは、プロセスの手戻りや非効率性を理解する上で重要です。変更が多量に発生する場合、初期要件の不明確さや複雑な購買ポリシーを示している可能性があり、「購買依頼変更率」KPIに影響を与えます。取得元これは、「requisition_headers」テーブルに関連付けられた監査証跡テーブルから取得され、バージョン変更や特定の「編集」アクションがログに記録されます。取得申請後、購買依頼の履歴ログで明示的な「編集」または「更新」イベントを探してください。イベントタイプ explicit
	購買依頼撤回済み	元の申請者が最終承認を受ける前に購買依頼をキャンセルします。これは、その購買依頼のプロセスを終了させる、ユーザー主導の明示的なアクションです。
その重要性撤回は、ビジネスニーズの変化、重複する要求、またはユーザーがプロセスを回避していることを示唆する場合があります。これを追跡することで、需要シグナルの変動や潜在的なプロセス遵守の問題を理解するのに役立ちます。取得元監査証跡に記録された明示的なユーザーアクションに基づき、「requisition_headers」テーブルのステータスが「取り消し済み」または類似の状態に変化したことから推測されます。取得申請ステータスが「取り消し済み」に変更されたときのタイムスタンプを特定します。イベントタイプ inferred
	購買依頼調達済み	承認された購買依頼は、即座に購買発注に変換されるのではなく、RFQやオークションなどのソーシングイベントに送られます。このイベントは、購買依頼がソーシングイベントオブジェクトにリンクされている場合に推測されます。
その重要性このアクティビティは、調達プロセスにおける重要な代替経路を明らかにします。これにより、単純な購買と、より複雑で戦略的なソーシング活動を区別し、より詳細なサイクルタイム分析を可能にします。取得元ステータスが「ソーシング中」に変化したことを検出するか、「requisition_lines」テーブルとソーシングイベントテーブル間にリンクが作成されたことを識別することで推測されます。取得ステータスが「ソーシング中」に変化したこと、またはソーシングイベントIDへのリンクが作成されたことを確認します。イベントタイプ inferred

推奨任意

抽出ガイド

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

ステップ

Coupaにログインする: レポートの作成とスケジュール設定の権限を持つユーザーアカウントでCoupaインスタンスにアクセスします。
レポートモジュールに移動する: 「設定」タブに移動し、「レポート」セクションを見つけます。「レポート」を選択してレポートダッシュボードを開きます。
新しいカスタムレポートを作成する: 「作成」ボタンをクリックして新しいレポートの作成を開始します。タイプとして「カスタムレポート」を選択します。
レポートのデータソースを定義する: レポートビルダーで、必要なすべての情報を収集するために複数のデータソースを選択して結合する必要があります。まず「Requisition Headers（申請書ヘッダー）」を主要なソースとして選択します。次に、以下の関連オブジェクトを追加します。
- 「Approvals（承認）」: 承認者、ステータス、タイムスタンプなど、各承認ステップの詳細を取得するため。
- 「Requisition Lines（申請書ライン）」: 合計金額を集計し、品目レベルの詳細を取得するため。
- 「Purchase Order Headers（発注書ヘッダー）」: 申請書が発注書に変換された時期を特定するため。
- 「Users（ユーザー）」: 申請者および承認者の氏名と部署の詳細を取得するため。
レポートの列を設定する: 利用可能なデータソースから必要なフィールドをレポートレイアウトにドラッグ＆ドロップします。これらの列はイベントログの生成に使用されるため、これが最も重要なステップです。少なくとも以下の項目を含めてください。
- 申請書ヘッダーから: Requisition #（申請書番号）、Created At（作成日時）、Submitted At（提出日時）、Updated At（更新日時）、Status（ステータス）、Created by (Login ID)（作成者（ログインID））、Total（合計）、Sourced Externally?（外部調達済みか？）
- ユーザーから（申請者用）: Full Name（氏名）、Department Name（部署名）。
- 承認から: Created At（作成日時）、Updated At（更新日時）、Status（ステータス）、Approver (Login ID)（承認者（ログインID））。
- 発注書ヘッダーから: PO Number（PO番号）、Created At（作成日時）。
レポートフィルターを設定する: データ抽出の範囲を絞るためにフィルターを適用します。一般的で効果的なフィルターは、「Requisition Headers - Created At」を使用し、「過去90日」などの動的な日付範囲を設定することです。必要に応じて、特定の会社コードでフィルターすることもできます。
レポートをスケジュール設定する: レポートビルダー内の「スケジュール」タブに移動します。レポートの実行頻度を日次または週次などで定義します。トラフィックの少ない時間帯に設定してください。
配信を設定する: 配信方法を指定します。自動化のために「SFTP」を選択し、サーバーの認証情報とターゲットディレクトリを提供します。あるいは、Eメールアドレスに送信することもできます。ファイル形式は「CSV」を選択します。
保存してアクティブ化する: レポートを保存し、スケジュールがアクティブになっていることを確認します。最初のレポートは次のスケジュールされた時間に実行されます。
データを変換する: 生成されたCSVはフラットファイルであり、イベントログではありません。このファイルを処理するには、外部スクリプト（Pythonなど）またはETLツールを使用する必要があります。スクリプトはデータをピボットし、各アクティビティに対応する個別の行を作成する必要があります（例：Created At列を使用して「Requisition Created（申請書作成）」の行を作成し、承認列を使用して各承認ステップの行を作成し、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ヶ月間の期間を設定することが、推奨される開始点です。
増分ロード: 継続的な分析のためには、レポートを毎日実行し、前日（例：「昨日」）のデータを抽出して増分ロードを作成するようにスケジュール設定してください。
配信設定: 堅牢で自動化されたデータパイプラインとの連携のため、SFTPサーバーへの配信を設定してください。送信先が安全で十分なストレージ容量があることを確認してください。
必要な権限: レポートを設定するユーザーアカウントには、必要なすべてのデータオブジェクト（申請書、発注書、承認、ユーザー）を作成、スケジュール設定、およびアクセスするための管理者権限またはレポート固有の権限が必要です。

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インスタンスにログインします。設定 > 会社設定 > APIキーに移動します。以下のスコープに対して少なくとも読み取り権限を持つ新しい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レコードのチャンク（ページ）でデータを取得し、指定された日付範囲内のすべての申請書が取得されるまで続行します。
申請書データを処理する: 取得された各申請書ヘッダーについて、スクリプトは「申請書作成済み」および「申請書提出済み」イベントを生成します。その後、追加のAPI呼び出しを行って、関連する承認データと発注書データを取得します。
アクティビティイベントを生成する: スクリプトは承認レコードを処理して、「承認ステップ開始」、「承認ステップ承認済み」、および「承認ステップ却下済み」イベントを作成します。また、申請書の最終ステータスと関連データをチェックして、「申請書承認済み」、「発注書作成済み」、および「申請書取り消し済み」などのイベントを生成します。
修正を検出する: スクリプトは各申請書のversion属性をチェックします。バージョンが1より大きい場合、それは修正を意味します。新しいバージョンのupdated-atタイムスタンプを使用して「申請書修正済み」イベントが作成されます。
イベントログを組み立てる: 生成されたすべてのイベントは、構造化されたリストに収集されます。各イベントには、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などの特定のステータスを対象とすることができます。
ページネーション制限: スクリプトは、API呼び出しごとに50レコード（limit=50）を取得するようにハードコードされています。これはCoupa APIでうまく機能する標準的な値です。これを増やしても必ずしもパフォーマンスが向上するわけではなく、複雑なクエリの場合にはタイムアウトのリスクが高まる可能性があります。
パフォーマンスに関する考慮事項: スクリプトは、各申請書に対して複数のAPI呼び出し（ヘッダー、承認、POごとに1つ）を行います。数千件の申請書のデータ抽出は時間がかかり、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)

ステップ

Coupaにログインする: レポートの作成とスケジュール設定の権限を持つユーザーアカウントでCoupaインスタンスにアクセスします。
レポートモジュールに移動する: 「設定」タブに移動し、「レポート」セクションを見つけます。「レポート」を選択してレポートダッシュボードを開きます。
新しいカスタムレポートを作成する: 「作成」ボタンをクリックして新しいレポートの作成を開始します。タイプとして「カスタムレポート」を選択します。
レポートのデータソースを定義する: レポートビルダーで、必要なすべての情報を収集するために複数のデータソースを選択して結合する必要があります。まず「Requisition Headers（申請書ヘッダー）」を主要なソースとして選択します。次に、以下の関連オブジェクトを追加します。
- 「Approvals（承認）」: 承認者、ステータス、タイムスタンプなど、各承認ステップの詳細を取得するため。
- 「Requisition Lines（申請書ライン）」: 合計金額を集計し、品目レベルの詳細を取得するため。
- 「Purchase Order Headers（発注書ヘッダー）」: 申請書が発注書に変換された時期を特定するため。
- 「Users（ユーザー）」: 申請者および承認者の氏名と部署の詳細を取得するため。
レポートの列を設定する: 利用可能なデータソースから必要なフィールドをレポートレイアウトにドラッグ＆ドロップします。これらの列はイベントログの生成に使用されるため、これが最も重要なステップです。少なくとも以下の項目を含めてください。
- 申請書ヘッダーから: Requisition #（申請書番号）、Created At（作成日時）、Submitted At（提出日時）、Updated At（更新日時）、Status（ステータス）、Created by (Login ID)（作成者（ログインID））、Total（合計）、Sourced Externally?（外部調達済みか？）
- ユーザーから（申請者用）: Full Name（氏名）、Department Name（部署名）。
- 承認から: Created At（作成日時）、Updated At（更新日時）、Status（ステータス）、Approver (Login ID)（承認者（ログインID））。
- 発注書ヘッダーから: PO Number（PO番号）、Created At（作成日時）。
レポートフィルターを設定する: データ抽出の範囲を絞るためにフィルターを適用します。一般的で効果的なフィルターは、「Requisition Headers - Created At」を使用し、「過去90日」などの動的な日付範囲を設定することです。必要に応じて、特定の会社コードでフィルターすることもできます。
レポートをスケジュール設定する: レポートビルダー内の「スケジュール」タブに移動します。レポートの実行頻度を日次または週次などで定義します。トラフィックの少ない時間帯に設定してください。
配信を設定する: 配信方法を指定します。自動化のために「SFTP」を選択し、サーバーの認証情報とターゲットディレクトリを提供します。あるいは、Eメールアドレスに送信することもできます。ファイル形式は「CSV」を選択します。
保存してアクティブ化する: レポートを保存し、スケジュールがアクティブになっていることを確認します。最初のレポートは次のスケジュールされた時間に実行されます。
データを変換する: 生成されたCSVはフラットファイルであり、イベントログではありません。このファイルを処理するには、外部スクリプト（Pythonなど）またはETLツールを使用する必要があります。スクリプトはデータをピボットし、各アクティビティに対応する個別の行を作成する必要があります（例：Created At列を使用して「Requisition Created（申請書作成）」の行を作成し、承認列を使用して各承認ステップの行を作成し、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ヶ月間の期間を設定することが、推奨される開始点です。
増分ロード: 継続的な分析のためには、レポートを毎日実行し、前日（例：「昨日」）のデータを抽出して増分ロードを作成するようにスケジュール設定してください。
配信設定: 堅牢で自動化されたデータパイプラインとの連携のため、SFTPサーバーへの配信を設定してください。送信先が安全で十分なストレージ容量があることを確認してください。
必要な権限: レポートを設定するユーザーアカウントには、必要なすべてのデータオブジェクト（申請書、発注書、承認、ユーザー）を作成、スケジュール設定、およびアクセスするための管理者権限またはレポート固有の権限が必要です。

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`

調達から支払いまで - 申請データテンプレート

調達から支払いまで - 申請データテンプレート

購買から支払いまで - 購買依頼属性

購買から支払いまで - 購買依頼アクティビティ

抽出ガイド

申請データエクスポートのための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購買依頼を最適化し、今すぐサイクルタイムを短縮