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

お客様の購買から支払いまで - 請求書処理データテンプレート

Coupa

購買から支払いまで - 請求書処理の属性 (21) 購買から支払いまで - 請求書処理のアクティビティ (14) 抽出ガイド (3)

お客様の購買から支払いまで - 請求書処理データテンプレート

このテンプレートは、Coupaでの請求書処理を効果的に分析するために必要な重要なデータポイントをご案内します。収集すべき重要な属性と、イベントログで追跡すべき主要なアクティビティを概説しています。さらに、Coupaシステムからこのデータを抽出するための実用的なガイダンスも記載されており、プロセスマイニングジャーニーをスムーズに開始できます。

収集を推奨する項目
追跡すべき主要アクティビティ
Coupa向け抽出ガイド

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

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

購買から支払いまで - 請求書処理の属性

これらは、購買から支払いまでの請求書処理を包括的に分析するために、イベントログに含めることを推奨するデータフィールドです。

3 必須 6 推奨 12 任意

	名前	説明
	イベント日時 EventTime	特定のアクティビティまたはイベントが発生した正確なタイムスタンプです。
説明イベント時間、またはタイムスタンプは、アクティビティが実行された正確な日時を記録します。これはプロセスログの時間的基盤であり、各ケースのすべてのイベントを時系列で並べます。この属性は、プロセスマイニングにおけるすべての時間ベース分析に不可欠です。アクティビティ間のサイクル時間を計算し、ボトルネックの期間を特定し、待ち時間を測定し、異なる期間でのプロセスパフォーマンスを分析するために使用されます。正確なタイムスタンプは、現実的なプロセスモデルを構築し、意味のあるパフォーマンスKPIを導き出すために不可欠です。その重要性すべての期間、サイクル時間、待ち時間を計算するために必要な時系列データを提供し、パフォーマンス分析の基礎となるものです。取得元このデータは、Coupaの請求書オブジェクトに関する監査証跡または履歴ログに記録されます。記録された各アクションまたはステータス変更には、関連するタイムスタンプが付随します。例 2023-10-26T10:00:00Z2023-11-05T14:32:15Z2023-11-15T09:01:45Z
	請求書番号 InvoiceNumber	サプライヤーの請求書に割り当てられる一意の識別子です。これは、請求書がそのライフサイクル全体を通じて追跡されるための主キーとして機能します。
説明請求書番号は、サプライヤーが請求書ドキュメントに割り当てる一意の参照番号です。プロセスマイニングでは、これがケースIDとして機能し、受領と検証から承認、最終支払いまでのすべての関連アクティビティをリンクします。請求書番号別にプロセスを分析することで、各請求書の完全なエンドツーエンドのジャーニーを把握できます。これにより、処理経路のバリエーションを特定し、サイクルタイムを正確に測定し、どの特定の請求書が遅延、保留、または例外に遭遇しているかを特定するのに役立ちます。これは、請求書処理パフォーマンスを詳細なレベルで理解するための基礎となる属性です。その重要性単一の請求書に関するすべてのイベントを接続する必須のケース識別子であり、首尾一貫したエンドツーエンドのプロセス分析を可能にします。取得元これはCoupaの請求書オブジェクトの主要フィールドです。UIの請求書ヘッダー詳細または請求書APIを介して見つけることができます。例 INV-2023-00123785549-APO45001-INV
	アクティビティ ActivityName	請求書処理ライフサイクル中に発生した特定のビジネスイベントまたはタスクの名前です。
説明アクティビティ名は、「請求書作成」「請求書承認依頼」「支払い実行」など、請求書処理ワークフローにおけるステップを記述します。各アクティビティは、請求書のステータスまたは所有権が変更された特定の時点を表します。プロセスマイニングでは、一連のアクティビティがプロセスフローマップを形成します。これらのアクティビティを分析することで、実際のプロセスを可視化し、一般的かつ稀な経路を特定し、アクティビティに時間がかかりすぎるボトルネックを検出し、手戻りループのような非準拠または非効率なステップを特定できます。その重要性この属性は、プロセスマップを構築するために不可欠であり、実際の請求書処理ワークフローの可視化と分析を可能にします。取得元この属性は通常、イベントログ、監査証跡、またはCoupaの請求書モジュール内のステータス変更から導出されます。多くの場合、ステータス変更や特定のユーザーアクションを定義されたアクティビティ名にマッピングする必要があります。例処理のために提出された請求書請求書承認済み請求書保留設定済み支払い実行
	ユーザー User	アクティビティを実行したユーザーまたはシステムエージェント。
説明この属性は、請求書の承認や保留の解除など、特定のプロセスステップを実行する個人または自動化システムを識別します。通常、ユーザーID、氏名、またはメールアドレスで表されます。ユーザー別にプロセスを分析することは、チームのパフォーマンス、ワークロードの配分、およびトレーニング機会を特定するための鍵となります。特定の承認者やチームに遅延が集中しているかどうかを明らかにできるため、ボトルネック分析に不可欠です。また、手動アクティビティと自動アクティビティを区別するのにも役立ちます。その重要性ワークロード分析を可能にし、特定のユーザーやチームによって引き起こされるボトルネックを特定し、ユーザーのパフォーマンスとコンプライアンスの評価に役立ちます。取得元ユーザー情報は通常、Coupaの請求書の監査証跡または履歴に記録され、実行された各アクションに関連付けられています。例 john.doe@company.comjane.smithSystem.Automation
	仕入先名 VendorName	請求書の発行元である仕入先／ベンダー名。
説明ベンダー名は、商品またはサービスが調達された取引先を識別します。これは、支払いパフォーマンスと関係を分析するための重要なコンテキストデータです。この属性により、ベンダー別に請求書プロセスをセグメント化できます。「どのベンダーが最も長い請求書処理時間を抱えているか？」や「特定の戦略的ベンダーに常に期日通り支払っているか？」といった問いに答えるのに役立ちます。ベンダー別の分析は、ベンダー支払い適時性ダッシュボードやサプライヤー関係を効果的に管理するために不可欠です。その重要性ベンダー別にプロセスをセグメント化し分析することを可能にし、サプライヤー関係の管理とベンダー固有の問題の特定にとって重要です。取得元この情報はCoupaのコア請求書データの一部であり、サプライヤー/ベンダーオブジェクトからリンクされています。例グローバル事務用品テックソリューションズ株式会社クリエイティブマーケティング代理店
	支払期日 PaymentDueDate	請求書が延滞になるのを避けるために支払う必要がある期日です。
説明支払期日は、請求書日付と合意された支払い条件に基づいて計算される重要な日付です。これはベンダーへの支払い期限を表します。この属性は、期日通りの支払いパフォーマンスを測定するためのベンチマークとなります。実際の支払い実行日と比較することで、期日通りの支払い率KPIを算出するために直接使用されます。この日付からの逸脱を分析することで、支払い遅延を引き起こしているシステム的な問題を特定し、ベンダー関係や潜在的な遅延損害金への影響を評価するのに役立ちます。その重要性期日内支払いパフォーマンスを測定するための主要なベンチマークであり、ベンダー関係の管理とペナルティの回避に不可欠です。取得元この日付は通常、Coupaによって「請求書日付」と「支払い条件」フィールドに基づいて計算されます。請求書レコードで利用可能であるべきです。例 2023-11-302023-12-152024-01-10
	発注書番号 PurchaseOrderNumber	請求書が発行される発注書（PO）の識別子です。
説明発注書番号は、請求書を元の購買文書にリンクさせます。この接続は、多くの組織における請求書検証の重要なステップである発注書照合プロセスにとって不可欠です。プロセスマイニングにおいて、この属性は発注書照合および不一致解消プロセスを分析するために非常に重要です。特定のPOに関連する請求書をフィルタリングすることができ、発注書照合不一致概要ダッシュボードに不可欠です。PO番号のない請求書が多い場合は、マベリックバイイングやコンプライアンス違反の調達を示している可能性があります。その重要性請求書を調達プロセスにリンクさせ、PO照合効率と不一致処理の分析を可能にします。取得元これはCoupaの請求書明細オブジェクトの標準フィールドであり、請求書明細と発注書明細を関連付けるために使用されます。例 PO4500123PO4500456PO4500789
	請求合計金額 InvoiceTotalAmount	税金およびその他の料金を含む、請求書の合計金額。
説明この属性は、請求書の総支払い金額を表します。これは、幅広い分析で使用される基本的な財務データポイントです。請求金額に基づいてプロセスを分析することで、重要なパターンが明らかになることがあります。例えば、高額な請求書は、より厳格な承認経路をたどり、サイクルタイムが長くなる可能性があります。また、現在保留中または遅延している請求書の金額など、プロセス非効率性の財務的影響を評価するためにも使用されます。その重要性重要な財務コンテキストを提供し、請求書金額によるプロセス動作の変化と遅延の財務的影響の分析を可能にします。取得元これはCoupaの請求書オブジェクトの標準フィールドであり、通常「合計」または「合計金額」と名付けられています。例 1500.75250.0012345.50
	請求書ステータス InvoiceStatus	請求書が処理ワークフローにおいて現在どの状態にあるかを示します。
説明請求書ステータスは、請求書が「承認待ち」「承認済み」「保留中」「支払い済み」など、特定の時点でどこにあるかを示すスナップショットです。この属性は動的であり、請求書がプロセスを進むにつれて変化します。これは、「請求書処理スループット＆ステータス」ダッシュボードのような運用監視ダッシュボードにとって重要な属性です。未処理の請求書の現在の在庫と、異なるステージへのそれらの分布を追跡できます。時間経過に伴うステータス遷移の分析は、「アクティビティ名」属性を導出するための主要な情報源でもあります。その重要性ワークフロー内での請求書の位置をリアルタイムで表示し、運用ダッシュボードやステータス追跡に不可欠です。取得元これはCoupaの請求書オブジェクトの主要なステータスフィールドです。例承認待ち承認済み取消済み支払い済み
	ソースシステム SourceSystem	イベントデータが抽出された元のシステムです。
説明ソースシステム属性は、請求書処理アクティビティが記録されたアプリケーションまたはプラットフォームを識別します。主要なシステムはCoupaですが、請求書や関連データはERPやベンダーポータルなどの他の統合システムから発信される場合があります。この情報は、複雑なIT環境において、異なるシステムが全体的なプロセスにどのように貢献しているかを理解する上で価値があります。データ品質の問題を診断し、システム間の引き渡しを理解し、複数のアプリケーションにまたがるプロセスを分析するのに役立ちます。その重要性データの出所を明確にし、トラブルシューティングや複数の統合システムを含むプロセスを分析するために不可欠です。取得元これは通常、データ抽出時にデータの出所を識別するために追加される静的な値です。Coupaの場合、「Coupa」に設定されます。例 Coupa`SAP S/4HANA`Oracle Fusion
	会社コード CompanyCode	請求書に責任を持つ法人または会社の識別子です。
説明会社コードは、大規模な組織内の特定の法人を表します。請求書は、財務会計および報告目的で会社コードに計上されます。この属性は、法人別にプロセス分析をフィルタリングおよびセグメント化するために不可欠です。「米国法人とドイツ法人では請求書承認プロセスが異なるか？」といった、ビジネスの異なる部分間でのプロセスパフォーマンス比較を可能にします。これは、大規模な多国籍企業にとって非常に重要です。その重要性組織内の異なる法務エンティティや事業部門間で、プロセス比較とパフォーマンスベンチマークを可能にします。取得元これはCoupaの請求書オブジェクトにおける基本的な会計フィールドであり、財務転記によく必要とされます。例 1000US01DE01
	保留理由 HoldReason	請求書が保留または支払い停止になった具体的な理由です。
説明保留理由は、請求書が支払いに進むのを妨げられる理由を説明します。例としては、「数量不一致」や「商品受領待ち」などがあります。この情報は、支払い遅延の原因を理解するために重要です。この属性は、支払いブロックの根本原因分析ダッシュボードの鍵となります。さまざまな保留理由の発生を分類し、数えることで、企業は支払いプロセスを妨げる最も一般的な問題を特定できます。これにより、将来の保留を防ぎ、支払いを加速するための的を絞った改善が可能になります。その重要性支払いが遅延する理由を説明し、的を絞った根本原因分析を可能にし、支払いブロックの頻度と期間を削減します。取得元 Coupaで請求書が保留にされる際、通常、理由が選択または入力されます。このデータは請求書の保留ステータスに関連付けられています。例発注書との価格不一致商品受領待ち重複請求書
	最終データ更新 LastDataUpdate	このイベントのデータがソースシステムから最後に更新された日時を示すタイムスタンプ。
説明この属性は、データがいつプロセスマイニングツールに最後に抽出され、ロードされたかを記録します。分析の鮮度に関するコンテキストを提供し、ダッシュボードに表示される洞察の適時性を理解するために重要です。最終データ更新時刻を知ることは、運用監視のユースケースにとって重要です。これにより、ユーザーは情報がどれだけ最新であるかを明確に理解し、古いプロセスビューに基づいて意思決定が行われないようにすることができます。その重要性プロセスデータの適時性と関連性に関する重要なコンテキストを提供し、ユーザーが分析の最新性を理解できるようにします。取得元このタイムスタンプは、データ抽出および変換（ETL）プロセス中に生成され、データセットに追加されます。例 2024-05-20T04:00:00Z2024-05-19T04:00:00Z
	割引獲得済み EarlyPaymentDiscountCaptured	利用可能な早期支払い割引が正常に適用されたかどうかを示すフラグです。
説明この属性は、企業が支払い条件（例：「2% 10、Net 30」条件の場合10日以内支払い）で定義された割引期間内に請求書を正常に支払ったかどうかを示すブール値です。これは、早期支払い割引トラッキングダッシュボードと関連KPIの主要な指標です。このフラグが「偽」である場合を分析することで、見逃された節約機会を特定するのに役立ちます。これにより、企業は割引対象の請求書がなぜ十分に迅速に処理されていないのかを調査し、より多くの割引を獲得するための変更を実施して、運転資金を最適化することができます。その重要性効率的な請求書処理から実現された財務上の利益を直接測定し、逃した節約の機会を特定するのに役立ちます。取得元これは計算属性です。ロジックは、「支払い条件」で定義された割引期間内に支払い日が収まっているか、および実際に割引が適用されたかをチェックすることを含みます。例 truefalse
	却下理由 RejectionReason	承認プロセス中に請求書が却下された際に提供される理由です。
説明承認者が請求書を却下する場合、「金額不正確」や「重複請求書」といった却下理由を通常提供します。この属性は、その自由形式またはコード化された理由を捕捉します。このデータは、承認遅延や手戻りの根本原因分析にとって非常に貴重です。異なる却下理由の頻度を分析することで、組織は、発注書の正確性やベンダーの請求習慣に関する問題など、上流プロセスにおけるシステム的な問題を特定できます。この情報は、請求書承認ボトルネック分析ダッシュボードをサポートします。その重要性請求書却下の根本原因に関する直接的なインサイトを提供し、プロセス改善領域の特定と手戻りの削減に役立ちます。取得元この情報は、ユーザーが承認ワークフローで「却下」アクションを実行したときに取得されます。多くの場合、コメントまたは監査証跡に保存されます。例数量の誤り価格が発注書と一致しない重複請求書の提出
	支払条件 PaymentTerms	「Net 30」や「2% 10, Net 30」といった、請求書支払いの合意された条件。
説明支払い条件は、ベンダーへの支払いに関するルールを定義するものです。これには支払期日や早期支払い割引の有無などが含まれ、通常はベンダーマスターデータで設定され、請求書に適用されます。この属性は、支払期日の算出や早期支払い割引の機会特定に不可欠です。早期支払い割引トラッキングダッシュボードおよび関連KPIへの直接的な入力となります。支払い条件別に分析することで、特定の条件が支払い遅延と関連しているかどうかが明らかになることがあります。その重要性支払い期日の計算の基礎となり、早期支払い割引の機会を特定し、運転資金に直接影響を与えます。取得元これはCoupaの標準フィールドであり、通常、サプライヤー/ベンダーレコードから請求書にデフォルトで設定されます。例支払条件：正味30日支払条件：正味60日2% 10, Net 30
	期日通りに支払い済み IsOnTimePayment	請求書が支払い期日までに支払われたかどうかを示すブール型のフラグです。
説明この計算属性は、各請求書の支払い適時性を示すシンプルな真偽値を提供します。「支払い実行」アクティビティのタイムスタンプと「支払期日」を比較することで導出されます。支払いタイムスタンプが支払期日以前であれば、値は真となります。このフラグは、期日通りの支払い率KPIの計算を簡素化します。これにより、一般的なベンダー、部署、または遅延に関連する請求金額など、遅延支払いの特性を分析するための簡単なフィルタリングとセグメント化が可能になります。その重要性支払いパフォーマンスの分析を簡素化し、重要な期日内支払い率KPIを計算するための基礎となります。取得元これは計算属性です。ロジックは「支払い実行日」≦「支払期日」です。これはプロセスマイニングツールに実装されます。例 truefalse
	自動化 IsAutomated	アクティビティが自動システムまたは人間ユーザーによって実行されたかどうかを示すフラグです。
説明このブール属性は、自動発注書照合やシステム生成の転記など、システム自動化によって実行されるタスクと、ユーザーが手動で実行するタスクを区別します。この属性を分析することで、請求書処理ワークフローにおける自動化のレベルを定量化するのに役立ちます。自動化イニシアチブの成功を測定し、自動化可能な手動介入ポイントを特定し、自動化されたアクティビティと手動アクティビティの効率およびエラー率を比較するために使用されます。これは、プロセスの真のコストと効率を理解する上で重要です。その重要性プロセスにおける自動化レベルを測定するのに役立ち、さらなる自動化の機会を特定し、既存のボットの影響を評価します。取得元これは通常、アクティビティに関連付けられた「ユーザー」がシステムまたはサービスアカウントか、それとも人間のユーザーアカウントかをチェックすることで導出されます。例 truefalse
	請求日 InvoiceDate	ベンダーの請求書ドキュメントに記載されている日付です。
説明請求書日付は、サプライヤーが請求書に付与する日付です。これは通常、支払いライフサイクルの公式な開始を示し、支払い条件に従って支払期日を計算するための基礎として使用されます。この属性は、多くのサイクルタイム計算の重要な開始点となります。支払期日の算出や早期支払い割引の資格を決定するための重要な入力情報です。請求書日付とシステムへの入力日の差を分析することで、請求書の提出や受領における遅延が明らかになることがあります。その重要性支払い期日を計算するために使用される主要な日付であり、支払いの適時性を測定し、割引を獲得するための重要な参照点です。取得元これはCoupaの請求書オブジェクトにおける標準的で必須のフィールドです。例 2023-10-152023-11-012023-12-20
	請求書処理リードタイム InvoiceCycleTime	請求書の一連の処理において、最初のアクティビティ（例：請求書作成）から最終支払いアクティビティまでの総経過時間です。
説明請求書サイクル時間は、請求書処理ライフサイクルのエンドツーエンド期間を測定する主要なパフォーマンス指標です。これは、最後の重要なイベント（「支払い実行済み」など）のタイムスタンプと最初のイベント（「請求書作成済み」または「請求書受領済み」など）のタイムスタンプの差として計算されます。この計算されたメトリックは、請求書サイクル時間分析ダッシュボードの基盤となります。全体的なプロセス効率の全体的な尺度を提供します。ベンダー、金額、または会社コード別に分解することで、非効率性の原因を明らかにし、改善 efforts の優先順位付けに役立ちます。その重要性これは、プロセス全体の速度と効率を測定するための主要なKPIであり、請求書の処理にかかる時間を直接示します。取得元この属性は、プロセスマイニングツール内で、各ケース（請求書番号）のイベントの最大時刻と最小時刻の差を取ることによって計算されます。例 15日4時間32日1時間5日8時間
	通貨 CurrencyCode	請求金額のISO通貨コード。
説明通貨コードは、請求書の金額の通貨単位（USD、EUR、GBPなど）を指定します。これは、グローバルに事業を展開し、複数の通貨で請求書を扱う組織にとって不可欠です。分析において、この属性は財務データを正確に解釈し集計するために必要です。ダッシュボードやKPIは、意味のある財務概要を提供するために通貨をフィルタリングまたは変換する必要があります。異なる通貨価値の誤った集計を防ぎ、通貨ごとのプロセス分析を可能にします。その重要性多通貨環境におけるすべての金銭的価値に必要なコンテキストを提供することで、正確な財務分析とレポート作成を保証します。取得元これはCoupaの請求書オブジェクトの標準フィールドであり、通常、ベンダーにリンクされているか、請求書自体に指定されています。例 USDEURGBP

必須推奨任意

購買から支払いまで - 請求書処理のアクティビティ

これらは、正確な`プロセス`ディスカバリと分析のために`イベントログ`に記録すべき主要な`プロセス``ステップ`と`マイルストーン`です。

5 推奨 9 任意

	アクティビティ	説明
	承認のために送信された請求書	請求書が初期チェックを通過した後、正式な承認ワークフローに送られる時点を示します。これは通常、請求書が1人以上の承認者からのアクションを待っていることを示すステータス変更から推測されます。
その重要性このアクティビティは、承認サイクルタイムを測定するための開始点です。承認階層内のボトルネックを分析するために重要であり、「請求書承認ボトルネック分析」ダッシュボードをサポートします。取得元請求書ステータスが「承認待ち」または同様の状態に変わることから推測されます。請求書の承認履歴に最初の承認レコードが作成されることも、このイベントを示します。取得請求書ステータスが「承認待ち」に変更されたとき、または最初の承認レコードが作成されたときのタイムスタンプをキャプチャします。イベントタイプ inferred
	支払い実行	このアクティビティは、プロセスにおける最終ステップであり、支払いが実行され、ベンダーに送金されることを示します。これは、Coupa Paymentsまたは統合支払いシステム内の関連する支払い記録のステータスから取得されます。
その重要性プロセスの最終的な終了として、このアクティビティは完全なエンドツーエンドサイクル時間を計算し、「期日内支払い率」KPIを測定するために不可欠です。取得元このイベントは、請求書に関連付けられた支払い記録から推測されます。「支払い済み」、「完了」、または「支払い日付」フィールドが入力されているステータスは、実行を示します。取得請求書にリンクされた支払い記録から「支払い日付」を使用します。イベントタイプ inferred
	支払い用に転記された請求書	承認された請求書は支払い準備が完了したとマークされ、その財務詳細はしばしば外部ERPシステムに転記されます。これは通常、統合ステータスフラグまたは請求書の主要ステータスの変更から推測されます。
その重要性このマイルストーンは、AP処理から財務または支払い機能への引き渡しを表します。この時点より前の遅延はAPの効率に影響し、この時点より後の遅延は財務およびベンダー関係に影響します。取得元これは、ステータスが「支払い承認済み」への変更、または「エクスポート済み」のようなフラグが真に設定されたことから推測されることがよくあります。この情報は請求書ヘッダーオブジェクトで利用可能です。取得請求書ステータスが「支払い承認済み」になったとき、またはエクスポートフラグが設定されたときのタイムスタンプを検出します。イベントタイプ inferred
	請求書作成	このアクティビティは、Coupaシステムでの請求書レコードの初期作成を示します。このイベントは、手動入力、Coupaサプライヤーポータルなどの統合サプライヤーネットワーク、または自動OCRスキャンを介して新しい請求書オブジェクトがインスタンス化されたときに捕捉されます。
その重要性請求書ライフサイクルの開始として、このアクティビティは総エンドツーエンド処理時間を測定するために不可欠です。それは、すべて後続のサイクル時間およびスループット分析のベースラインを提供します。取得元これは、請求書レコードの作成タイムスタンプから取得される明示的なイベントです。Coupaのデータモデルでは、これは請求書ヘッダーオブジェクトの「created-at」タイムスタンプに対応します。取得請求書レコードの作成タイムスタンプを使用します。イベントタイプ explicit
	請求書承認済み	このアクティビティは、請求書が承認ワークフローのすべての必須ステップを正常に通過したことを示します。最終的な必須承認者が肯定的なアクションを実行した際に、承認履歴から取得されます。
その重要性この重要なマイルストーンは、承認サイクルの終了を示し、請求書を支払い処理のために開放します。承認期間とプロセス全体の効率性を測定するために不可欠です。取得元これは、承認履歴ログまたは請求書ヘッダーのステータスが「承認済み」に変更されたことから取得される明示的なイベントです。ログ内の最終承認アクションは正確なタイムスタンプを提供します。取得承認履歴内の最終承認アクションのタイムスタンプをキャプチャします。イベントタイプ explicit
	不一致解決開始	発注書照合の不一致を解決するための手動介入の開始を表します。このアクティビティは直接捕捉するのが難しく、不一致がフラグ付けされた後、コメントの追加や請求書の編集など、最初のユーザーアクションから推測されることがよくあります。
その重要性不一致の特定から解決開始までの時間を追跡することは、例外の割り当てや対処における遅延を浮き彫りにするのに役立ちます。これは「発注書照合不一致概要」ダッシュボードの重要な部分です。取得元これはソース特定が困難であり、高度な推論を必要とする場合があります。照合ステータスが失敗を示した後、請求書に関連する最初のユーザーコメント、編集、またはタスク割り当てのタイムスタンプを見つけることで導出できる可能性があります。取得「照合不一致が特定されました」イベントの後、最初のユーザーが開始した変更イベントを見つけます。イベントタイプ inferred
	処理のために提出された請求書	新しく作成された請求書が処理ワークフローに正式に提出されることを表します。これは通常、すべての初期データが入力され検証された後にユーザーによってトリガーされます。このイベントは、請求書のステータスが下書き状態から提出済みの状態に変化した際に監査証跡から取得されます。
その重要性このアクティビティは、データ入力時間と実処理時間を区別します。「請求書作成」からこのイベントまでの期間を分析することで、初期データ処理段階での遅延を特定するのに役立ちます。取得元請求書のステータスが「下書き」または「新規」から「提出済み」または「承認待ち」に変化したことを追跡します。これはCoupaの請求書履歴または監査ログテーブルで利用可能です。取得請求書ステータスが最初に「提出済み」になったときのタイムスタンプをキャプチャします。イベントタイプ explicit
	支払いスケジュール設定	請求書は、将来の日付に実行が予定されている支払いバッチに含まれています。このイベントは、請求書がシステム内の支払い実行または支払いバッチオブジェクトに関連付けられていることから推測されます。
その重要性このアクティビティは、プロセス最終段階の可視性を提供し、請求書の支払い準備完了と実際に支払いが開始される時点を区別します。キャッシュフロー予測に役立ちます。取得元請求書IDを含む支払いレコードまたはバッチレコードの作成から推測されます。支払いオブジェクトの「支払い予定日」が関連するタイミングを提供します。取得請求書に関連付けられた支払いバッチレコードの作成日を使用します。イベントタイプ inferred
	照合不一致が特定されました	数量や価格などの不一致により、自動システムが請求書と発注書のマッチングに失敗する状況です。これは、請求書のステータスが「不一致」や「照合失敗」など、手動での対応が必要な状態に変化したことから推測されます。
その重要性このアクティビティは、遅延の一般的な原因である例外処理の入り口です。その頻度と根本原因を分析することは、初回照合率を向上させ、手動作業負荷を削減するために不可欠です。取得元請求書の照合ステータスから推測されます。「未照合」、「不一致」、または類似のステータスは、手動レビューが必要な不一致を示します。これは請求書オブジェクトで追跡されます。取得 PO照合ステータスが失敗を示す値に変更されたときのタイムスタンプを検出します。イベントタイプ inferred
	請求書をPOと照合済み	このアクティビティは、システムが請求書明細行を対応する発注書明細行に正常に照合したことを示します。このイベントは、請求書のマッチングステータスフィールドの変化から推測され、発注書に対する正常な検証を示します。
その重要性自動照合の成功は、健全なタッチレスプロセスの重要な指標です。このアクティビティを追跡することで、自動化の効果とストレートスルー処理率を測定するのに役立ちます。取得元請求書照合ステータスフィールドが「照合済み」状態に変わることから推測されます。Coupaの請求書オブジェクトには、PO照合試行の結果を示すフラグとステータスが含まれています。取得請求書のPO照合ステータスが「照合済み」に変更されたときのタイムスタンプを検出します。イベントタイプ inferred
	請求書保留解除	請求書に以前設定された保留が解除され、支払いに進むことができるようになります。保留を設定するのと同様に、これは請求書の監査証跡に記録される明示的なアクションです。
その重要性保留が開始されてから解除されるまでの時間は、「平均支払いブロック期間」KPIにとって重要です。このアクティビティは遅延の終了を示し、そのトリガーを分析することで、より迅速な解決のための機会が明らかになる可能性があります。取得元これは請求書の履歴または監査ログで見つかる明示的なイベントです。個別のユーザーまたはシステムアクションとしてログに記録されます。取得請求書履歴レコードを「保留解除済み」または類似のシステムイベントでフィルタリングします。イベントタイプ explicit
	請求書保留設定済み	請求書の支払いを一時的に停止させるための措置であり、支払いを阻止するものです。これは明示的なイベントであり、通常、請求書の履歴や監査証跡に記録され、多くの場合、関連する理由が付随します。
その重要性このアクティビティは、支払いブロックに相当し、支払い遅延の主な原因となります。保留がいつ開始されたかを追跡することは、その根本原因と期間を分析する最初のステップであり、「支払いブロック率」KPIをサポートします。取得元これは、請求書の履歴または監査ログで見つかる明示的なイベントです。Coupaは、保留の配置を含むユーザーまたはシステムのアクションをログに記録します。取得請求書履歴レコードを「保留設定済み」または類似のシステムイベントでフィルタリングします。イベントタイプ explicit
	請求書却下	承認者が正式に請求書を却下し、ワークフローでの進行を停止させました。これは請求書の承認履歴に記録された明示的なアクションであり、誰がいつ却下したかの詳細が含まれます。
その重要性却下は手戻りを生み、サイクルタイムを大幅に増加させます。却下の頻度と理由を分析することは、プロセス改善の鍵であり、「初回承認率」KPIの算出にも必要です。取得元これは請求書の承認履歴ログに記録される明示的なイベントです。各承認ステップには、ステータス、タイムスタンプ、および承認者のアクションを含むレコードがあります。取得承認履歴レコードを「却下」または「拒否」のアクションでフィルタリングします。イベントタイプ explicit
	請求書無効	請求書がキャンセルされ、処理または支払いは行われません。これは、請求書にとって明示的な最終ステータス変更であり、システム内のステータスフィールドから直接取得されます。
その重要性これは、プロセスにおける別の、成功しなかった終了を表します。請求書が無効化される理由を分析することで、調達またはベンダーとのコミュニケーションにおける上流の問題を明らかにすることができます。取得元これは、請求書のステータスが「無効」に変更されたときに取得される明示的なイベントです。これはCoupaの請求書管理における標準的なステータスです。取得請求書ステータスが「無効」に更新されたときのタイムスタンプをキャプチャします。イベントタイプ explicit

推奨任意

抽出ガイド

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

ステップ

前提条件: レポートの作成、編集、スケジュール設定を許可するロールと権限を持つCoupaユーザーアカウントがあることを確認してください。また、以下のCoupaデータオブジェクトへのアクセスも必要です：請求書ヘッダー、請求書監査証跡、承認、支払い情報。
レポート機能への移動: Coupaインスタンスにログインし、レポートセクションに移動します。これは通常、メインメニューまたは専用のアナリティクスタブにあります。
主要請求書レポートの作成: 「レポートを作成」をクリックします。「請求書ヘッダー」を主要データソースとして選択します。このレポートは、いくつかのステータスベースのアクティビティの基礎となります。「ProcessMind - 請求書マスターデータ」のような記述的な名前を付けてください。
関連データオブジェクトの追加: レポートビルダーで、「請求書ヘッダー」オブジェクトを関連オブジェクトと結合してデータを補強します。ベンダーとユーザーの詳細を取得するために、「サプライヤー」、「作成ユーザー」、「更新ユーザー」を追加します。これは、推奨される属性をデータ入力するために重要です。
特定のイベントレポートの作成: イベントログの性質上、単一のレポートから必要なすべての行を生成することはできません。異なる種類のイベントをキャプチャするために設計された複数のレポートを作成し、後で結合する必要があります。
- レポートA：請求書ステータスイベント: 「請求書ヘッダー」と結合された「請求書監査証跡」オブジェクトに基づいてレポートを作成します。このレポートは、監査証跡を特定のステータス変更でフィルタリングすることで、「請求書作成済み」、「請求書提出済み」、「請求書保留中」、「請求書保留解除済み」、「請求書無効化済み」などのアクティビティをキャプチャします。
- レポートB：承認イベント: 「請求書ヘッダー」と結合された「承認」オブジェクトに基づいてレポートを作成します。このレポートは、「承認のために請求書を送信」、「請求書承認済み」、および「請求書却下済み」アクティビティをキャプチャします。
- レポートC：支払いイベント: 「請求書ヘッダー」と結合された「支払い情報」オブジェクトに基づいてレポートを作成します。これにより、「支払い予定」および「支払い実行済み」イベントがキャプチャされます。
各レポートの列設定: 作成する各レポートには、必要な列を追加します。Coupaフィールドを必要なイベントログスキーマに手動でマッピングする必要があります。例えば、承認イベントレポートでは、「承認 > 作成日時」を追加して「EventTime」に名前を変更し、「Invoice Approved」というテキストのカスタム列を追加して「ActivityName」と名付け、「請求書ヘッダー > 請求書番号」を「InvoiceNumber」として追加します。
レポートフィルターの定義: 各レポートのフィルターセクションで、データ量を制限するために日付フィルターを追加します。過去3〜6ヶ月間の「請求書ヘッダー > 作成日時」でフィルターをかけることを推奨します。また、必要に応じて、特定の会社コードまたは法務エンティティのフィルターも追加します。
レポートの実行とエクスポート: 各レポートを個別に保存して実行します。各レポートの結果をCSVファイルとしてエクスポートします。各ファイルのデータが正しく、設定した列が含まれていることを確認してください。
エクスポートのスケジュール設定: レポートが正しいことを確認したら、定期的に（例：毎日）実行されるようにスケジュールします。自動取得のために、CSVファイルを指定された場所、できればSFTPサーバーにエクスポートするようにスケジュールを設定します。
データの結合と変換: 最終的なデータ変換を実行するために、外部スクリプト（例：Python、PowerShell）またはETLツールを使用します。このスクリプトは以下を行う必要があります。
- SFTPサーバーからすべてのCSVファイルをダウンロードする。
- すべてのファイルで列名をイベントログスキーマ（InvoiceNumber、ActivityName、EventTimeなど）に一致するように標準化する。
- 個々のファイルからのすべての行を単一の統合されたイベントログファイルに統合する。
最終的な書式設定とアップロード: 最終的に統合されたファイルがUTF-8エンコードされたCSVとして保存されていることを確認します。このファイルはProcessMindアプリケーションにアップロードして分析する準備が整いました。

設定

主要データオブジェクト: 抽出は、アクセス可能である必要があるいくつかの主要なCoupaオブジェクトに依存しています。これらには、請求書ヘッダー、請求書監査証跡、承認、支払い情報、サプライヤーが含まれます。
期間フィルタリング: パフォーマンスとデータ量を管理するため、日付フィルターを適用することが重要です。初回分析には、請求書ヘッダー > 作成日時に過去3〜6ヶ月間のローリング期間でフィルターをかけることを推奨します。
必須フィルター: 分析対象の事業部門に関連するデータであることを確認するため、常に会社コードまたは法務エンティティでフィルターをかけてください。プロセスに関連しない場合は、「ドラフト」などの特定の請求書ステータスを除外することもできます。
レポートのスケジュール設定: Coupaでは、レポートを毎日、毎週、または毎月実行するようスケジュールできます。プロセスマイニングでは、分析を最新に保つため、毎日のエクスポートを推奨します。自動化のためにCSVファイルをSFTPサーバーに配信するようエクスポートを設定してください。
ユーザー権限: これらのレポートを設定および実行するユーザーアカウントには、レポートの作成とスケジュール設定の権限、および上記のすべてのデータオブジェクトに対する読み取りアクセス権を持つロールが必要です。

a クエリ例 config

// This is a configuration guide for creating multiple Coupa reports. These reports must be combined externally to form the final event log.

// --- Report 1: Invoice Creation Event ---
// Primary Object: Invoice Header
// Columns:
//   'InvoiceNumber' = Invoice Header > Invoice Number
//   'ActivityName' = 'Invoice Created' (Static Value)
//   'EventTime' = Invoice Header > Created At
//   'User' = Invoice Header > Created By > Login
//   'VendorName' = Invoice Header > Supplier > Name
//   'InvoiceTotalAmount' = Invoice Header > Total
//   'PaymentDueDate' = Invoice Header > Payment Due Date
//   'PurchaseOrderNumber' = Invoice Header > PO Number
//   'InvoiceStatus' = Invoice Header > Status

// --- Report 2: Invoice Status Change Events ---
// Primary Object: Invoice Audit Trail
// Joined Object: Invoice Header (on Invoice ID)
// Columns:
//   'InvoiceNumber' = Invoice Header > Invoice Number
//   'ActivityName' = CASE WHEN (Field Name = 'status' AND Old Value = 'new' AND New Value = 'pending_approval') THEN 'Invoice Submitted for Processing' WHEN (Field Name = 'po_match_status' AND New Value = 'matched') THEN 'Invoice Matched to PO' WHEN (Field Name = 'po_match_status' AND New Value = 'unmatched') THEN 'Matching Discrepancy Identified' WHEN (Field Name = 'status' AND New Value = 'on_hold') THEN 'Invoice Hold Placed' WHEN (Field Name = 'status' AND Old Value = 'on_hold') THEN 'Invoice Hold Released' WHEN (Field Name = 'exported' AND New Value = 't') THEN 'Invoice Posted for Payment' WHEN (Field Name = 'status' AND New Value = 'voided') THEN 'Invoice Voided' END
//   'EventTime' = Invoice Audit Trail > Created At
//   'User' = Invoice Audit Trail > Updated By > Login
//   'VendorName', 'InvoiceTotalAmount', etc. from joined Invoice Header.
// Filters:
//   Field Name IN ('status', 'po_match_status', 'exported')

// --- Report 3: Invoice Approval Events ---
// Primary Object: Approval
// Joined Object: Invoice Header (on Invoice ID)
// This report will create multiple rows from one source object. This logic needs to be applied in the external transformation script.
// Logic Block 1: Invoice Sent for Approval (First Approver Record for the Invoice)
//   'InvoiceNumber' = Invoice Header > Invoice Number
//   'ActivityName' = 'Invoice Sent for Approval'
//   'EventTime' = MIN(Approval > Created At) GROUP BY InvoiceNumber
//   'User' = Approver associated with the MIN(Created At) timestamp.
// Logic Block 2: Invoice Rejected
//   'InvoiceNumber' = Invoice Header > Invoice Number
//   'ActivityName' = 'Invoice Rejected'
//   'EventTime' = Approval > Created At
//   'User' = Approval > Approver > Login
//   Filter: Approval > Status = 'rejected'
// Logic Block 3: Invoice Approved (Final Approver Record)
//   'InvoiceNumber' = Invoice Header > Invoice Number
//   'ActivityName' = 'Invoice Approved'
//   'EventTime' = MAX(Approval > Created At) where Status is 'approved'
//   'User' = Approver associated with the MAX(Created At) timestamp.

// --- Report 4: Discrepancy Resolution Event ---
// Primary Object: Invoice Audit Trail
// Joined Object: Invoice Header (on Invoice ID)
//   'InvoiceNumber' = Invoice Header > Invoice Number
//   'ActivityName' = 'Discrepancy Resolution Started'
//   'EventTime' = Invoice Audit Trail > Created At
//   'User' = Invoice Audit Trail > Updated By > Login
// Filter:
//   This event is difficult. A common proxy is the first user comment or field change after the PO match status changes to 'unmatched'.
//   Logic: Find the MIN(Created At) from the audit trail where the timestamp is greater than the timestamp of the 'Matching Discrepancy Identified' event.

// --- Report 5: Payment Events ---
// Primary Object: Payment Information
// Joined Object: Invoice Header (on Invoice ID)
// Logic Block 1: Payment Scheduled
//   'InvoiceNumber' = Invoice Header > Invoice Number
//   'ActivityName' = 'Payment Scheduled'
//   'EventTime' = Payment Information > Payment Date
//   'User' = 'System'
// Logic Block 2: Payment Executed
//   'InvoiceNumber' = Invoice Header > Invoice Number
//   'ActivityName' = 'Payment Executed'
//   'EventTime' = Payment Information > Paid At
//   'User' = 'System'
// Filter:
//   Payment Information > Paid At IS NOT NULL

ステップ

Coupa APIキーの生成: 管理者としてCoupaインスタンスにログインします。設定 > 会社設定 > APIキーに移動します。新しいAPIキーを作成します。キーには、core.invoice.read、core.user.read、core.supplier.read、core.approval.read、core.payment.readの各スコープに対する読み取り権限があることを確認してください。
Python環境のセットアップ: Python 3.6以降がインストールされていることを確認してください。新しいプロジェクトディレクトリを作成し、pipを使用して必要なライブラリをインストールします。pip install requests pandas
Pythonスクリプトの設定: 新しいPythonファイル（例：extract_coupa_invoices.py）を作成します。提供されたスクリプトをこのファイルにコピーします。YOUR_COUPE_INSTANCE_URL、YOUR_API_KEY、START_DATEのプレースホルダー値を、お客様の特定のインスタンス詳細と希望の抽出開始日に置き換えます。
スクリプトの実行: ターミナルからpython extract_coupa_invoices.pyコマンドを使用してスクリプトを実行します。スクリプトはCoupa APIからデータの取得を開始します。
抽出の監視: スクリプトはコンソールに進捗状況を更新して表示し、処理された請求書の数を示します。期間とデータ量によっては、APIレート制限のため、かなりの時間がかかる場合があります。
コアロジックの理解: スクリプトはまず/api/invoicesエンドポイントにクエリを実行し、指定された期間内に更新されたすべての請求書のリストを取得します。すべてのレコードを取得するためにページネーションを自動的に処理します。
各請求書の処理: 取得された各請求書について、スクリプトは利用可能なタイムスタンプと関連データに基づいて複数のイベントログエントリを生成します。例えば、created-atは「請求書作成済み」に、submitted-atは「請求書処理のために提出済み」に使用されます。
承認詳細の取得: 承認および却下イベントをキャプチャするため、スクリプトは各請求書について/api/invoices/{invoice_id}/approvalsエンドポイントへの二次API呼び出しを行います。その後、このリストを処理し、「承認のために請求書を送信」、「請求書承認済み」、および「請求書却下済み」アクティビティを作成します。
支払い詳細の取得: 支払い情報が必要な場合、スクリプトは/api/paymentsエンドポイントにクエリを実行し、請求書IDでフィルタリングして、「支払い予定」および「支払い実行済み」イベントに関連する支払いレコードを検索します。
データの変換と集計: 生成されたすべてのイベントは辞書のリストに収集されます。各辞書は最終イベントログの1行を表します。
イベントログファイルの作成: すべての請求書の処理が完了すると、スクリプトは集計されたデータをpandas DataFrameに変換します。このDataFrameは、ProcessMindへのアップロード準備が整ったcoupa_invoice_event_log.csvという名前のCSVファイルとして同じディレクトリに保存されます。

設定

APIキー権限: APIキーには、Coupaの請求書、承認、ユーザー、サプライヤー、支払いオブジェクトに対する少なくとも読み取り専用アクセスが必要です。権限が不足している場合、スクリプトエラーやデータ不完全性の原因となります。
期間設定: スクリプトはupdated-at[gt]フィルターを使用して、指定されたSTART_DATE以降に作成または変更された請求書のみを取得します。初回抽出では、データ量とパフォーマンスのバランスを考慮し、3〜6ヶ月間を推奨します。後続の差分ロードでは、START_DATEを最終成功抽出のタイムスタンプに設定してください。
APIレート制限: CoupaはAPIにレート制限を設けています。提供されているスクリプトには、各請求書の処理間隔にtime.sleep(0.5)呼び出しが含まれており、これらの制限を超えるのを防ぎます。この値は、お客様のCoupaインスタンスの特定の設定に基づいて調整する必要がある場合があります。
カスタムフィールド: この抽出スクリプトには、標準のCoupaフィールドのみが含まれています。組織で分析に必要なカスタムフィールドを請求書に使用している場合、スクリプトを変更してAPIレスポンス内のcustom-fields要素を解析し、それらを列として出力に追加する必要があります。

a クエリ例 python

import requests
import pandas as pd
import time
import os
from datetime import datetime

class=class="hl-string">"hl-comment"># --- Configuration ---
class=class="hl-string">"hl-comment"># Replace with your Coupa instance URL (e.g., class="hl-string">'https://mycompany.coupahost.com')
COUPE_INSTANCE_URL = class="hl-string">'YOUR_COUPE_INSTANCE_URL' 
class=class="hl-string">"hl-comment"># Replace with your Coupa API Key
API_KEY = class="hl-string">'YOUR_API_KEY'
class=class="hl-string">"hl-comment"># Set the start date for the extraction (YYYY-MM-DD format)
START_DATE = class="hl-string">'2023-01-01' 

class=class="hl-string">"hl-comment"># --- API Setup ---
API_BASE_URL = fclass="hl-string">"{COUPE_INSTANCE_URL}/api"
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"># --- Event Log Storage ---
event_log_records = []

def get_paginated_data(endpoint_url, params=None):
    class="hl-string">"""Fetches all pages of data from a Coupa API endpoint."""
    all_data = []
    url = fclass="hl-string">"{API_BASE_URL}/{endpoint_url}"
    
    class=class="hl-string">"hl-comment"># Coupa uses offset-based pagination, 50 is a common limit
    offset = 0
    while True:
        paginated_params = params.copy() if params else {}
        paginated_params[class="hl-string">'offset'] = offset
        paginated_params[class="hl-string">'limit'] = 50
        
        try:
            response = requests.get(url, headers=HEADERS, params=paginated_params)
            response.raise_for_status()
            data = response.json()
            if not data: class=class="hl-string">"hl-comment"># Break if the page is empty
                break
            all_data.extend(data)
            offset += len(data)
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Error fetching data from {url}: {e}")
            break
    return all_data

def add_event(invoice, activity_name, event_time, user_info=None):
    class="hl-string">"""Helper function to create and add an event record."""
    if not event_time:
        return class=class="hl-string">"hl-comment"># Do not add events without a timestamp

    record = {
        class="hl-string">'InvoiceNumber': invoice.get(class="hl-string">'invoice-number'),
        class="hl-string">'ActivityName': activity_name,
        class="hl-string">'EventTime': event_time,
        class="hl-string">'User': user_info.get(class="hl-string">'login') if user_info else None,
        class="hl-string">'VendorName': invoice.get(class="hl-string">'supplier', {}).get(class="hl-string">'name'),
        class="hl-string">'InvoiceTotalAmount': invoice.get(class="hl-string">'total-with-taxes'),
        class="hl-string">'PaymentDueDate': invoice.get(class="hl-string">'payment-date'),
        class="hl-string">'PurchaseOrderNumber': invoice.get(class="hl-string">'purchase-order', {}).get(class="hl-string">'number') if invoice.get(class="hl-string">'purchase-order') else None,
        class="hl-string">'InvoiceStatus': invoice.get(class="hl-string">'status')
    }
    event_log_records.append(record)

def main():
    class="hl-string">"""Main extraction function."""
    print(class="hl-string">"Starting Coupa invoice data extraction...")
    
    class=class="hl-string">"hl-comment"># Fetch all invoices updated since the start date
    invoice_params = {class="hl-string">'updated-at[gt]': START_DATE}
    invoices = get_paginated_data(class="hl-string">'invoices', invoice_params)
    print(fclass="hl-string">"Found {len(invoices)} invoices to process.")

    for i, invoice in enumerate(invoices):
        print(fclass="hl-string">"Processing invoice {i+1}/{len(invoices)}: {invoice.get('invoice-number')}")
        invoice_id = invoice.get(class="hl-string">'id')

        class=class="hl-string">"hl-comment"># Activity: Invoice Created
        add_event(invoice, class="hl-string">'Invoice Created', invoice.get(class="hl-string">'created-at'), invoice.get(class="hl-string">'created-by'))

        class=class="hl-string">"hl-comment"># Activity: Invoice Submitted for Processing
        add_event(invoice, class="hl-string">'Invoice Submitted for Processing', invoice.get(class="hl-string">'submitted-at'), invoice.get(class="hl-string">'submitted-by'))

        class=class="hl-string">"hl-comment"># Activities related to matching status
        if invoice.get(class="hl-string">'po-match-status') == class="hl-string">'matched':
            add_event(invoice, class="hl-string">'Invoice Matched to PO', invoice.get(class="hl-string">'updated-at'), invoice.get(class="hl-string">'updated-by'))
        elif invoice.get(class="hl-string">'po-match-status') in [class="hl-string">'unmatched', class="hl-string">'mismatched']:
            add_event(invoice, class="hl-string">'Matching Discrepancy Identified', invoice.get(class="hl-string">'updated-at'), invoice.get(class="hl-string">'updated-by'))
            class=class="hl-string">"hl-comment"># Inference for Discrepancy Resolution Started is complex. We approximate it as the next update.
            class=class="hl-string">"hl-comment"># A more robust solution would track status changes over time.
            add_event(invoice, class="hl-string">'Discrepancy Resolution Started', invoice.get(class="hl-string">'updated-at'), invoice.get(class="hl-string">'updated-by'))

        class=class="hl-string">"hl-comment"># Activities from Approvals endpoint
        approvals = get_paginated_data(fclass="hl-string">'invoices/{invoice_id}/approvals')
        if approvals:
            class=class="hl-string">"hl-comment"># Sent for Approval is often the creation of the first approval object
            first_approval = approvals[0]
            add_event(invoice, class="hl-string">'Invoice Sent for Approval', first_approval.get(class="hl-string">'created-at'), first_approval.get(class="hl-string">'created-by'))
            
            for approval in approvals:
                approver = approval.get(class="hl-string">'approver')
                if approval.get(class="hl-string">'status') == class="hl-string">'approved':
                    add_event(invoice, class="hl-string">'Invoice Approved', approval.get(class="hl-string">'updated-at'), approver)
                elif approval.get(class="hl-string">'status') == class="hl-string">'rejected':
                    add_event(invoice, class="hl-string">'Invoice Rejected', approval.get(class="hl-string">'updated-at'), approver)

        class=class="hl-string">"hl-comment"># Activities based on status and flags
        if invoice.get(class="hl-string">'on-hold'):
            class=class="hl-string">"hl-comment"># This timestamp is an approximation, representing the last update time when the hold was active.
            add_event(invoice, class="hl-string">'Invoice Hold Placed', invoice.get(class="hl-string">'updated-at'), invoice.get(class="hl-string">'updated-by'))
        class=class="hl-string">"hl-comment"># We canclass="hl-string">'t reliably detect 'Hold Released' without historical data, so we omit it for accuracy.

        if invoice.get(class="hl-string">'exported') == True:
            add_event(invoice, class="hl-string">'Invoice Posted for Payment', invoice.get(class="hl-string">'updated-at'), invoice.get(class="hl-string">'updated-by'))

        if invoice.get(class="hl-string">'status') == class="hl-string">'void':
            add_event(invoice, class="hl-string">'Invoice Voided', invoice.get(class="hl-string">'updated-at'), invoice.get(class="hl-string">'updated-by'))
        
        class=class="hl-string">"hl-comment"># Activities from Payments endpoint
        payments = get_paginated_data(class="hl-string">'payments', {class="hl-string">'invoice-id': invoice_id})
        for payment in payments:
            add_event(invoice, class="hl-string">'Payment Scheduled', payment.get(class="hl-string">'created-at'), payment.get(class="hl-string">'created-by'))
            if payment.get(class="hl-string">'payment-date'):
                add_event(invoice, class="hl-string">'Payment Executed', payment.get(class="hl-string">'payment-date'), payment.get(class="hl-string">'updated-by'))

        class=class="hl-string">"hl-comment"># A short delay to respect API rate limits
        time.sleep(0.5)

    if not event_log_records:
        print(class="hl-string">"No events were generated. Exiting.")
        return

    class=class="hl-string">"hl-comment"># Create DataFrame and save to CSV
    df = pd.DataFrame(event_log_records)
    df[class="hl-string">'EventTime'] = pd.to_datetime(df[class="hl-string">'EventTime']).dt.strftime(class="hl-string">'%Y-%m-%d %H:%M:%S')
    df = df.sort_values(by=[class="hl-string">'InvoiceNumber', class="hl-string">'EventTime'])
    
    output_filename = class="hl-string">'coupa_invoice_event_log.csv'
    df.to_csv(output_filename, index=False, encoding=class="hl-string">'utf-8')
    print(fclass="hl-string">"Extraction complete. Event log saved to {os.path.abspath(output_filename)}")

if __name__ == class="hl-string">'__main__':
    main()

ステップ

前提条件: レポートの作成、編集、スケジュール設定を許可するロールと権限を持つCoupaユーザーアカウントがあることを確認してください。また、以下のCoupaデータオブジェクトへのアクセスも必要です：請求書ヘッダー、請求書監査証跡、承認、支払い情報。
レポート機能への移動: Coupaインスタンスにログインし、レポートセクションに移動します。これは通常、メインメニューまたは専用のアナリティクスタブにあります。
主要請求書レポートの作成: 「レポートを作成」をクリックします。「請求書ヘッダー」を主要データソースとして選択します。このレポートは、いくつかのステータスベースのアクティビティの基礎となります。「ProcessMind - 請求書マスターデータ」のような記述的な名前を付けてください。
関連データオブジェクトの追加: レポートビルダーで、「請求書ヘッダー」オブジェクトを関連オブジェクトと結合してデータを補強します。ベンダーとユーザーの詳細を取得するために、「サプライヤー」、「作成ユーザー」、「更新ユーザー」を追加します。これは、推奨される属性をデータ入力するために重要です。
特定のイベントレポートの作成: イベントログの性質上、単一のレポートから必要なすべての行を生成することはできません。異なる種類のイベントをキャプチャするために設計された複数のレポートを作成し、後で結合する必要があります。
- レポートA：請求書ステータスイベント: 「請求書ヘッダー」と結合された「請求書監査証跡」オブジェクトに基づいてレポートを作成します。このレポートは、監査証跡を特定のステータス変更でフィルタリングすることで、「請求書作成済み」、「請求書提出済み」、「請求書保留中」、「請求書保留解除済み」、「請求書無効化済み」などのアクティビティをキャプチャします。
- レポートB：承認イベント: 「請求書ヘッダー」と結合された「承認」オブジェクトに基づいてレポートを作成します。このレポートは、「承認のために請求書を送信」、「請求書承認済み」、および「請求書却下済み」アクティビティをキャプチャします。
- レポートC：支払いイベント: 「請求書ヘッダー」と結合された「支払い情報」オブジェクトに基づいてレポートを作成します。これにより、「支払い予定」および「支払い実行済み」イベントがキャプチャされます。
各レポートの列設定: 作成する各レポートには、必要な列を追加します。Coupaフィールドを必要なイベントログスキーマに手動でマッピングする必要があります。例えば、承認イベントレポートでは、「承認 > 作成日時」を追加して「EventTime」に名前を変更し、「Invoice Approved」というテキストのカスタム列を追加して「ActivityName」と名付け、「請求書ヘッダー > 請求書番号」を「InvoiceNumber」として追加します。
レポートフィルターの定義: 各レポートのフィルターセクションで、データ量を制限するために日付フィルターを追加します。過去3〜6ヶ月間の「請求書ヘッダー > 作成日時」でフィルターをかけることを推奨します。また、必要に応じて、特定の会社コードまたは法務エンティティのフィルターも追加します。
レポートの実行とエクスポート: 各レポートを個別に保存して実行します。各レポートの結果をCSVファイルとしてエクスポートします。各ファイルのデータが正しく、設定した列が含まれていることを確認してください。
エクスポートのスケジュール設定: レポートが正しいことを確認したら、定期的に（例：毎日）実行されるようにスケジュールします。自動取得のために、CSVファイルを指定された場所、できればSFTPサーバーにエクスポートするようにスケジュールを設定します。
データの結合と変換: 最終的なデータ変換を実行するために、外部スクリプト（例：Python、PowerShell）またはETLツールを使用します。このスクリプトは以下を行う必要があります。
- SFTPサーバーからすべてのCSVファイルをダウンロードする。
- すべてのファイルで列名をイベントログスキーマ（InvoiceNumber、ActivityName、EventTimeなど）に一致するように標準化する。
- 個々のファイルからのすべての行を単一の統合されたイベントログファイルに統合する。
最終的な書式設定とアップロード: 最終的に統合されたファイルがUTF-8エンコードされたCSVとして保存されていることを確認します。このファイルはProcessMindアプリケーションにアップロードして分析する準備が整いました。

設定

主要データオブジェクト: 抽出は、アクセス可能である必要があるいくつかの主要なCoupaオブジェクトに依存しています。これらには、請求書ヘッダー、請求書監査証跡、承認、支払い情報、サプライヤーが含まれます。
期間フィルタリング: パフォーマンスとデータ量を管理するため、日付フィルターを適用することが重要です。初回分析には、請求書ヘッダー > 作成日時に過去3〜6ヶ月間のローリング期間でフィルターをかけることを推奨します。
必須フィルター: 分析対象の事業部門に関連するデータであることを確認するため、常に会社コードまたは法務エンティティでフィルターをかけてください。プロセスに関連しない場合は、「ドラフト」などの特定の請求書ステータスを除外することもできます。
レポートのスケジュール設定: Coupaでは、レポートを毎日、毎週、または毎月実行するようスケジュールできます。プロセスマイニングでは、分析を最新に保つため、毎日のエクスポートを推奨します。自動化のためにCSVファイルをSFTPサーバーに配信するようエクスポートを設定してください。
ユーザー権限: これらのレポートを設定および実行するユーザーアカウントには、レポートの作成とスケジュール設定の権限、および上記のすべてのデータオブジェクトに対する読み取りアクセス権を持つロールが必要です。

a クエリ例 config

// This is a configuration guide for creating multiple Coupa reports. These reports must be combined externally to form the final event log.

// --- Report 1: Invoice Creation Event ---
// Primary Object: Invoice Header
// Columns:
//   'InvoiceNumber' = Invoice Header > Invoice Number
//   'ActivityName' = 'Invoice Created' (Static Value)
//   'EventTime' = Invoice Header > Created At
//   'User' = Invoice Header > Created By > Login
//   'VendorName' = Invoice Header > Supplier > Name
//   'InvoiceTotalAmount' = Invoice Header > Total
//   'PaymentDueDate' = Invoice Header > Payment Due Date
//   'PurchaseOrderNumber' = Invoice Header > PO Number
//   'InvoiceStatus' = Invoice Header > Status

// --- Report 2: Invoice Status Change Events ---
// Primary Object: Invoice Audit Trail
// Joined Object: Invoice Header (on Invoice ID)
// Columns:
//   'InvoiceNumber' = Invoice Header > Invoice Number
//   'ActivityName' = CASE WHEN (Field Name = 'status' AND Old Value = 'new' AND New Value = 'pending_approval') THEN 'Invoice Submitted for Processing' WHEN (Field Name = 'po_match_status' AND New Value = 'matched') THEN 'Invoice Matched to PO' WHEN (Field Name = 'po_match_status' AND New Value = 'unmatched') THEN 'Matching Discrepancy Identified' WHEN (Field Name = 'status' AND New Value = 'on_hold') THEN 'Invoice Hold Placed' WHEN (Field Name = 'status' AND Old Value = 'on_hold') THEN 'Invoice Hold Released' WHEN (Field Name = 'exported' AND New Value = 't') THEN 'Invoice Posted for Payment' WHEN (Field Name = 'status' AND New Value = 'voided') THEN 'Invoice Voided' END
//   'EventTime' = Invoice Audit Trail > Created At
//   'User' = Invoice Audit Trail > Updated By > Login
//   'VendorName', 'InvoiceTotalAmount', etc. from joined Invoice Header.
// Filters:
//   Field Name IN ('status', 'po_match_status', 'exported')

// --- Report 3: Invoice Approval Events ---
// Primary Object: Approval
// Joined Object: Invoice Header (on Invoice ID)
// This report will create multiple rows from one source object. This logic needs to be applied in the external transformation script.
// Logic Block 1: Invoice Sent for Approval (First Approver Record for the Invoice)
//   'InvoiceNumber' = Invoice Header > Invoice Number
//   'ActivityName' = 'Invoice Sent for Approval'
//   'EventTime' = MIN(Approval > Created At) GROUP BY InvoiceNumber
//   'User' = Approver associated with the MIN(Created At) timestamp.
// Logic Block 2: Invoice Rejected
//   'InvoiceNumber' = Invoice Header > Invoice Number
//   'ActivityName' = 'Invoice Rejected'
//   'EventTime' = Approval > Created At
//   'User' = Approval > Approver > Login
//   Filter: Approval > Status = 'rejected'
// Logic Block 3: Invoice Approved (Final Approver Record)
//   'InvoiceNumber' = Invoice Header > Invoice Number
//   'ActivityName' = 'Invoice Approved'
//   'EventTime' = MAX(Approval > Created At) where Status is 'approved'
//   'User' = Approver associated with the MAX(Created At) timestamp.

// --- Report 4: Discrepancy Resolution Event ---
// Primary Object: Invoice Audit Trail
// Joined Object: Invoice Header (on Invoice ID)
//   'InvoiceNumber' = Invoice Header > Invoice Number
//   'ActivityName' = 'Discrepancy Resolution Started'
//   'EventTime' = Invoice Audit Trail > Created At
//   'User' = Invoice Audit Trail > Updated By > Login
// Filter:
//   This event is difficult. A common proxy is the first user comment or field change after the PO match status changes to 'unmatched'.
//   Logic: Find the MIN(Created At) from the audit trail where the timestamp is greater than the timestamp of the 'Matching Discrepancy Identified' event.

// --- Report 5: Payment Events ---
// Primary Object: Payment Information
// Joined Object: Invoice Header (on Invoice ID)
// Logic Block 1: Payment Scheduled
//   'InvoiceNumber' = Invoice Header > Invoice Number
//   'ActivityName' = 'Payment Scheduled'
//   'EventTime' = Payment Information > Payment Date
//   'User' = 'System'
// Logic Block 2: Payment Executed
//   'InvoiceNumber' = Invoice Header > Invoice Number
//   'ActivityName' = 'Payment Executed'
//   'EventTime' = Payment Information > Paid At
//   'User' = 'System'
// Filter:
//   Payment Information > Paid At IS NOT NULL

お客様の購買から支払いまで - 請求書処理データテンプレート

お客様の購買から支払いまで - 請求書処理データテンプレート

購買から支払いまで - 請求書処理の属性

購買から支払いまで - 請求書処理のアクティビティ

抽出ガイド

CoupaスケジュールレポートおよびCSVデータエクスポート

ステップ

設定

a クエリ例 config

抽出のためのCoupa REST APIを使用したPythonスクリプト

ステップ

設定

a クエリ例 python

SFTPスケジュールによるCoupaデータの自動エクスポート

ステップ

設定

a クエリ例 config

今すぐ始めますか？

最高の効率を引き出す：P2P請求書処理を今すぐ最適化

お客様の購買から支払いまで - 請求書処理データテンプレート

お客様の購買から支払いまで - 請求書処理データテンプレート

購買から支払いまで - 請求書処理の属性

購買から支払いまで - 請求書処理のアクティビティ

抽出ガイド

CoupaスケジュールレポートおよびCSVデータエクスポート

ステップ

設定

a クエリ例 config

抽出のためのCoupa REST APIを使用したPythonスクリプト

ステップ

設定

a クエリ例 python

SFTPスケジュールによるCoupaデータの自動エクスポート

ステップ

設定

a クエリ例 config

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

今すぐ始めますか？

最高の効率を引き出す：P2P請求書処理を今すぐ最適化