データテンプレート:支払購買プロセス - 発注書
購買から支払いまでの発注書データテンプレート
- 推奨データ属性
- 主要なプロセス活動
- Coupaデータ抽出ステップ
調達・購買プロセス - 発注書属性
| 名前 | 説明 | ||
|---|---|---|---|
|
アクティビティ
ActivityName
|
発注書ライフサイクル内の特定の時点で発生したイベントまたはタスクの名前。 | ||
|
説明
アクティビティ名 は、調達・購買プロセスにおける「発注書承認済み」や「入庫記録済み」といった個々のステップを記述します。これらのアクティビティの連なりが、各発注書のプロセスフローを形成します。
その重要性
プロセス内のステップを定義し、プロセスフローの可視化を可能にし、ボトルネック、手戻り、逸脱を特定できます。
取得元
Coupaの発注書オブジェクトに関連するイベントログ、監査証跡、またはステータス変更記録から派生します。
例
購買申請承認済発注書提出済検収転記済みPOに対する請求書受領
|
|||
|
購買発注
PurchaseOrderNumber
|
発注書の一意の識別子であり、プロセスの主要なケース識別子として機能します。 | ||
|
説明
発注番号は、最初の依頼から商品やサービスの受領の最終確認まで、すべてのアクティビティを関連付ける中心的なケース識別子です。一意の発注番号は、調達プロセスの単一のインスタンスを表します。 プロセスマイニング分析において、この属性は各購買のエンドツーエンドのジャーニーを追跡するために不可欠です。これによりアナリストは、プロセスマップを可視化し、バリアントを特定し、注文の総サイクルタイムのようなケースレベルKPIを算出することが可能になります。すべてのイベントと関連データは、この識別子の下に集約され、プロセスの一貫したビューを構築します。
その重要性
各購買のライフサイクル全体を追跡するために不可欠であり、個々のプロセスインスタンスを再構築して詳細な分析を可能にします。
取得元
これは、Coupaの発注書オブジェクトにおける標準の主キーフィールドです。
例
PO-2023-00123PO-2023-00456PO-2023-00789
|
|||
|
開始時刻
EventTime
|
アクティビティまたはイベントが発生した正確なタイムスタンプ。 | ||
|
説明
イベントタイムは、特定のアクティビティが実行された日時を記録します。プロセスのすべてのアクティビティには、その発生を示す対応するタイムスタンプがあります。 この属性は、プロセスマイニングにおけるすべての時間ベースの分析に不可欠です。アクティビティ間のサイクルタイム計算、プロセス期間の測定、遅延の特定などに使用されます。例えば、「発注書下書き作成済み」と「発注書承認済み」のタイムスタンプ間の時間差は、「発注書承認サイクルタイムKPI」の計算に用いられます。
その重要性
各イベントの時間的コンテキストを提供し、サイクルタイムの計算、パフォーマンス分析、ボトルネックの検出に不可欠です。
取得元
Coupaのイベントログまたは監査証跡にあり、通常、発注書に対する各ステータス変更や実行されたアクションに関連付けられています。
例
2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z
|
|||
|
ソースシステム
SourceSystem
|
プロセスデータが抽出されたシステムです。 | ||
|
説明
この属性は、イベントデータが記録された情報システムの発生源を識別します。このプロセスの場合、値は常に「Coupa」となります。 データが複数のシステム(例:調達にはCoupa、請求には別のERP)から供給される企業環境では、この属性がデータソースの区別に役立ちます。これにより、データのリネージが明確化され、特定のシステムからのプロセスビューに合わせた分析をフィルタリングすることができます。
その重要性
データの出所に関する重要なコンテキストを提供し、追跡可能性を確保し、特に複数システム環境において適切なデータガバナンスを可能にします。
取得元
これは、データセットにラベルを付けるために、データ抽出および変換プロセス中に通常追加される静的値です。
例
Coupa
|
|||
|
最終データ更新
LastDataUpdate
|
このプロセスのデータが最後に更新された日時を示すタイムスタンプです。 | ||
|
説明
この属性は、データセットがソースシステムから最後に更新された日時を記録します。個々のイベントではなく、データセット全体に適用されるメタデータフィールドです。 分析ダッシュボードでは、このタイムスタンプは、ユーザーが閲覧しているデータの鮮度を理解するために不可欠です。これにより、インサイトが最新の情報に基づいているという信頼性が確保され、データの鮮度に対するユーザーの期待を適切に管理するのに役立ちます。通常、ダッシュボードに目立つように表示されます。
その重要性
データの適時性をユーザーに伝え、プロセス分析やKPIのデータがどれほど最新であるか理解を促します。
取得元
このタイムスタンプは、データ抽出・読み込み(ETL)パイプラインの実行時に生成および保存されます。
例
2023-11-01T05:00:00Z
|
|||
|
ユーザー
User
|
承認者や依頼者など、アクティビティを実行したユーザーIDまたは氏名です。 | ||
|
説明
この属性は、プロセス内で特定のイベントを実行する責任者(例:注文を作成した担当者、承認したマネージャー、商品受領を転記した事務員など)を特定します。 ユーザーごとのパフォーマンスを分析することで、トレーニングの必要性、高い成果を上げている個人、およびワークロードの分散を特定するのに役立ちます。例えば、「発注承認サイクルタイムパフォーマンス」ダッシュボードでは、この属性を使用して特定の承認者ごとの承認時間を詳細に分析し、プロセスにおけるボトルネックとなっている可能性のある人物を浮き彫りにします。
その重要性
個人または役割別にプロセスパフォーマンスの分析を可能にし、ボトルネック、トレーニング機会、リソース配分の問題を特定するのに役立ちます。
取得元
Coupaの発注書監査証跡または履歴ログ内の各イベントに関連付けられています。「作成者」、「承認者」、「更新者」などのフィールドが一般的なデータソースです。
例
j.doea.smithm.jones
|
|||
|
仕入先名
VendorName
|
商品やサービスを調達している供給元またはベンダーの名前です。 | ||
|
説明
ベンダー名は、発注書に記載された品目を供給する外部の取引先を特定するものです。この情報は、調達分析において極めて重要です。 ベンダーごとのプロセスパフォーマンスを分析することは、サプライヤー関係管理にとって不可欠です。「サプライヤーリードタイムパフォーマンス」の評価、「受領プロセス遅延」における遅延の特定、および「返品率」に基づいたサプライヤーの品質評価に役立ちます。この属性は、「非優先ベンダー支出比率」KPIの算出においても重要な要素となります。
その重要性
サプライヤーのパフォーマンス分析を可能にし、サプライヤー選定の最適化、より良い条件での交渉、パフォーマンスの高い、または低いベンダーの特定に役立ちます。
取得元
Coupaの発注書ヘッダーにある標準フィールドで、サプライヤーマスターデータにリンクしています。
例
グローバル事務用品テックソリューションズ株式会社高度産業部品クリエイティブマーケティングエージェンシー
|
|||
|
合計注文金額
TotalOrderAmount
|
発注書の総金額です。 | ||
|
説明
この属性は、特定の通貨で表された発注書に記載されているすべての商品およびサービスの総コストを表します。発注全体に適用されるケースレベル属性です。 この財務データは、支出分析やプロセス改善の取り組みの優先順位付けにとって非常に重要です。高額な発注は、より厳密な精査が必要であったり、異なる承認経路を要したりする場合があります。これは、「購買カテゴリ別支出分析」ダッシュボードで直接使用され、「非推奨ベンダーへの支出比率」KPIの計算要素となります。
その重要性
各購買の財務的背景を提供し、支出分析、高価値注文の優先順位付け、および財務的影響の評価を可能にします。
取得元
Coupaの発注書ヘッダーで利用可能で、通常「合計」または「総計」として表示されます。
例
1500.00250.7512500.50
|
|||
|
購買カテゴリ
PurchaseCategory
|
ITハードウェアやプロフェッショナルサービスなど、購入される製品またはサービスの分類。 | ||
|
説明
購買カテゴリは、「コモディティ」または「マテリアルグループ」とも呼ばれ、類似の購買タイプをグループ化するために使用される分類です。この構造化されたデータにより、支出と調達プロセスの体系的な分析が可能になります。 プロセスマイニングにおいて、この属性はフィルタリングとセグメンテーションのための重要な要素です。「購買カテゴリ別支出分析」ダッシュボードは、これを利用して支出パターンを分析します。また、特定のカテゴリ(例えば、複雑なサービス)が、他のカテゴリ(例えば、標準的な事務用品)よりも長いcycle timeや高い変更率を持つかどうかを明らかにすることもできます。
その重要性
カテゴリー別の支出とプロセス分析を可能にし、調達パターンの特定、ベンダーとの交渉、プロセス管理の調整に役立ちます。
取得元
これは通常、Coupaの発注書明細項目レベルで確認され、多くの場合、商品コードまたは購買カタログにリンクされています。
例
ITハードウェア事務用品プロフェッショナルサービスマーケティング資料
|
|||
|
部署
Department
|
発注書が計上される事業部門またはコストセンター。 | ||
|
説明
部門属性 は、購買を開始した、またはその費用を負担する組織単位を指定します。これは、発注書の明細項目にある申請者またはコストセンター情報と関連付けられることがよくあります。
その重要性
異なる事業部門間でプロセスおよび支出分析のフィルタリングと比較を可能にし、効率とコンプライアンスのばらつきを明らかにします。
取得元
Coupaの発注書ヘッダーまたは明細で利用可能で、多くの場合、コストセンターや組織単位にリンクされています。
例
マーケティング情報技術運用財務
|
|||
|
一次承認であるか
IsFirstPassApproval
|
発注書が下書き作成後、変更なしで承認された場合に真となる計算フラグです。 | ||
|
説明
このブーリアンフラグは、発注書が「発注書下書き」から「発注書承認済み」に至るプロセス中に、「発注書変更」または「発注書却下」アクティビティが含まれない場合にtrueが設定されます。 この属性は、「一発承認率」KPIを直接測定します。高い比率は、効率的かつ正確な初回処理を示します。このフラグがfalseであるケースを分析することで、手戻りの原因を特定し、発注書の初期データ品質を改善するのに役立ちます。
その重要性
初期作成および承認プロセスの効率を直接測定し、手戻りなく処理される発注の多さを示します。
取得元
PurchaseOrderNumberごとのイベントのシーケンスを分析することで、データ変換中に計算されます。
例
truefalse
|
|||
|
優先ベンダーであるか
IsPreferredVendor
|
購入が優先または戦略的ベンダーから行われたかどうかを示すブール値フラグです。 | ||
|
説明
このフラグは、発注書上のベンダーが事前承認された戦略的サプライヤーのリストの一部であるかどうかを識別します。これは、ベンダー名またはIDと推奨ベンダーのマスターリストを照合することで通常決定されます。 この属性は、戦略的ソーシングと支出管理イニシアティブにとって不可欠です。「非推奨ベンダーへの支出比率」KPIの計算に使用され、組織がマベリックバイイングを監視および制御するのに役立ちます。また、主要パートナーとの支出を統合し、ボリュームディスカウントやより有利な条件を活用することにも貢献します。
その重要性
優先サプライヤーと非優先サプライヤーとの支出を追跡することで、調達方針のコンプライアンスと戦略的ソーシング目標の監視に役立ちます。
取得元
これは、Coupaでは多くの場合、標準フィールドではありませんが、発注書上のベンダーIDを外部の推奨ベンダーリストと比較することで導出されます。
例
truefalse
|
|||
|
処理時間
ProcessingTime
|
アクティビティの期間であり、ユーザーがタスクに積極的に取り組んだ時間を表します。 | ||
|
説明
処理時間(「サービス時間」とも呼ばれます)は、タスクに積極的に費やされた時間です。これは待機時間とは異なります。例えば、ユーザーが発注書承認タスクを開いてから承認を提出するまでの時間を測定できます。 この指標は、待機期間を含むcycle timeと比較して、ユーザーの作業量をより正確に把握できます。処理時間を分析することで、能力計画、ワークロードのバランス調整、本質的に時間のかかるタスクの特定に役立ちます。これは、単一の活動の開始時刻と終了時刻の両方を必要としますが、常に利用できるとは限りません。
その重要性
実作業時間と待機時間を区別するのに役立ち、リソース効率とタスクの複雑さについて、より深い洞察を提供します。
取得元
単一アクティビティの開始タイムスタンプと終了タイムスタンプの両方がCoupa監査ログで利用可能な場合に計算されます。これは通常、標準ではありません。
例
3600120900
|
|||
|
却下理由
RejectionReason
|
承認ステップ中に購買依頼または発注が却下された際に提供される理由です。 | ||
|
説明
承認者が発注書を却下する際、その理由を提示することがよくあります。この属性は、「予算コードが正しくない」や「支出限度額を超過」といったテキストによる説明を記録します。 却下理由を分析することで、手戻りやプロセス上の問題の根本原因を直接的に把握できます。この定性的なデータは、申請プロセスにおける一般的なエラーを特定するために利用でき、将来的な却下を防ぎ、初回承認率を向上させるためのターゲットを絞ったトレーニングやシステム改善につながります。
その重要性
購買発注書が却下される理由について直接的で実行可能な洞察を提供し、プロセスの手戻りや遅延の根本原因に対処するのに役立ちます。
取得元
これは通常、Coupaの承認ワークフローにおける「発注書却下」または「申請却下」活動に関連付けられたコメントまたはメモフィールドに記録されます。
例
重複申請予算未承認誤ったベンダーの選択
|
|||
|
受領場所
ReceivingLocation
|
商品が納品される物理的な場所(倉庫やオフィスなど)です。 | ||
|
説明
受入場所は、発注書(PO)で注文された商品の目的地を具体的に示します。これは、特定の倉庫、工場、またはオフィス住所である可能性があります。 この属性は、異なる拠点におけるロジスティクスおよび受入のパフォーマンスを分析するために利用されます。「受領プロセス遅延」ダッシュボードをこの属性でフィルタリングすることで、特定の場所で入荷処理が遅延しているかどうかを特定し、運用上の非効率性やリソースの制約を正確に把握するのに役立ちます。
その重要性
受け入れプロセスを拠点ごとに分析でき、倉庫、工場、オフィス間のパフォーマンスの違いを浮き彫りにします。
取得元
この情報は、Coupaの発注書にある「出荷先住所」の一部です。
例
Warehouse A - Chicagoビルディング5 - ロンドンオフィスフランクフルト工場
|
|||
|
変更理由
ChangeReason
|
発注が最初に作成された後に行われた変更の理由です。 | ||
|
説明
この属性は、発注書が変更された理由、例えば「数量更新」や「価格修正」といった正当な理由を記録します。この情報は、ユーザーが「発注書変更」アクティビティを実行した際に監査証跡に記録されることがよくあります。 注文が変更される理由を理解することは、「発注書変更分析」ダッシュボードの鍵となります。これは、避けられない変更(例:ベンダーの在庫問題)と予防可能な変更(例:誤った初期データ入力)を区別するのに役立ち、注文の正確性を向上させ、「発注書変更率」KPIを削減するための取り組みを導きます。
その重要性
発注書変更の根本原因を説明し、初回発注精度の向上とプロセス手戻りの削減につながる具体的な対策を可能にします。
取得元
Coupaの購買発注書における変更イベントの監査ログやコメントによく記載されています。
例
ベンダーからの価格更新納品日調整済み修正済み品目コード
|
|||
|
希望納期
RequestedDeliveryDate
|
申請者が製品またはサービスの納品を要求した日付。 | ||
|
説明
この属性は、依頼プロセス中にビジネスユーザーが指定した目標納期です。これは、注文がいつ履行されるべきかというビジネス側の期待を表します。 この日付は、サプライヤーおよび内部パフォーマンスを測定するための重要なベンチマークとなります。実際の「商品受領転記日」と比較することで、「サプライヤー納期遵守率」KPIの算出に直接使用されます。「納期差異と返品」ダッシュボードでは、この要求された日付と実際の納期の間の乖離を可視化し、期待値の管理と予測精度の向上に貢献します。
その重要性
サプライヤーからの納期遵守率と社内受領プロセスの効率性を測定するための重要なパフォーマンス基準として機能します。
取得元
Coupaの発注書明細にある標準フィールドです。
例
2023-11-152023-12-012024-01-10
|
|||
|
手戻り
IsRework
|
発注書に変更アクティビティが発生したかどうかを識別する計算フラグです。 | ||
|
説明
このブーリアンフラグは、履歴に少なくとも1つの「発注書変更イベント」がある発注書に対してtrueが設定されます。これはイベントログから導出されるケースレベル属性です。 この属性により、「発注書変更率」のようなKPIの計算が簡素化されます。データのフィルタリングとセグメンテーションを容易にし、再作業が発生した発注とそうでない発注のプロセスを比較することで、変更がサイクルタイムやコストに与える影響を定量化するのに役立ちます。これは、「発注書変更分析」ダッシュボードの主要な要素です。
その重要性
少なくとも一度変更されたすべての発注書に対して、容易なフィルタリングと集計を可能にすることで、手戻り の分析を簡素化します。
取得元
PurchaseOrderNumberごとに「Purchase Order Changed」アクティビティの存在を確認することで、データ変換中に計算されます。
例
truefalse
|
|||
|
申請者名
RequesterName
|
最初に製品またはサービスを申請した個人の名前。 | ||
|
説明
この属性は、発注書に至る購買依頼を作成した従業員を特定します。依頼者は、ニーズを持つビジネスユーザーであり、バイヤーや承認者とは異なる場合があります。 依頼者ごとのプロセス行動を分析することで、特定のユーザーや部門に関連するパターンを特定するのに役立ちます。「発注書変更分析」ダッシュボードは、この情報を用いて、特定の依頼者がより頻繁に注文変更を行っているかどうかを確認し、それが仕様要件に関するより良いトレーニングの必要性を示唆している可能性があります。
その重要性
購買の発生元を特定するのに役立ち、申請者レベルでの調達行動と正確性の分析を可能にします。
取得元
この情報は、通常、元の購買依頼に保存され、Coupaの発注書に引き継がれます。
例
アリス・クーパーボブ・ディランチャーリー・パーカー
|
|||
|
納期通りの配送であるか
IsDeliveryOnTime
|
納品希望日以前に商品が受領されたかどうかを示す計算フラグです。 | ||
|
説明
このブーリアン属性は、「入庫計上イベント」のタイムスタンプを「希望納期」と比較することで算出されます。入庫日が希望日以前の場合にtrueが設定されます。 このフラグは、「サプライヤー納期遵守率」KPIおよび「納期差異と返品」ダッシュボードを直接サポートします。納期遵守の成否を明確な二値の結果として提供し、集計および可視化が容易であるため、ベンダーや社内入庫プロセスにおけるパフォーマンス上の問題を迅速に特定するのに役立ちます。
その重要性
配送パフォーマンスに関する明確なバイナリメトリックを提供し、定時配送KPIの計算と傾向分析を簡素化します。
取得元
RequestedDeliveryDateと「Goods Receipt Posted」アクティビティのタイムスタンプを比較することで、データ変換中に計算されます。
例
truefalse
|
|||
|
購買申請番号
PurchaseRequisitionNumber
|
発注書に先行する購買依頼の一意の識別子です。 | ||
|
説明
この属性は、発注書を元の購買依頼に紐付けるものです。1つの購買依頼から複数の発注書が発行される場合があります。 この紐付けは、購買依頼から発注までのサイクルタイム全体を分析する上で不可欠です。購買依頼の作成イベントを発注書の作成イベントおよび送付イベントと連携させることで、組織は依頼から履行に至る調達プロセス全体の効率を測定できます。
その重要性
プロセスの申請と発注のフェーズを結びつけ、申請から発注までのサイクルタイムとコンバージョン率の分析を可能にします。
取得元
これは通常、Coupaの発注書明細項目にある参照フィールドで、元の申請にリンクしています。
例
PR-2023-00098PR-2023-00152PR-2023-00341
|
|||
|
通貨
Currency
|
発注書上の金額の通貨コード。 | ||
|
説明
この属性は、総発注額がどの通貨(例:USD、EUR、GBP)で建てられているかを指定します。グローバル企業において財務データを正確に解釈する上で不可欠です。 多国籍企業にとって、通貨を考慮せずに支出を分析することは誤解を招く可能性があります。この属性により、適切な通貨換算とダッシュボード内での一貫した財務報告が可能になり、同等の基準で値を比較できることが保証されます。
その重要性
多国籍企業における正確な財務分析と報告を保証するため、通貨換算に必要な情報を提供します。
取得元
Coupaの発注書ヘッダーにある標準フィールドです。
例
USDEURGBPJPY
|
|||
調達・購買プロセス - 発注書アクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
|
検収転記済み
|
これは、商品が受領され、検査を経て承認されたことの正式な確認です。このイベントにより在庫記録が更新され、ベンダーがこの配送の義務を履行したことを示します。 | ||
|
その重要性
この重要なマイルストーンは、サプライヤーのリードタイムの終点となり、納期遵守率の測定に利用されます。入庫計上の遅延は、実際の在庫レベルの可視性を損なう可能性があります。
取得元
これはCoupaにおける主要なトランザクションであり、入庫オブジェクトに記録されます。イベントは、入庫のステータスが「Posted」または「Received」になったタイムスタンプから取得されます。
取得
システムで物品受領トランザクションが確定された際に記録されます。
イベントタイプ
explicit
|
|||
|
発注書をサプライヤーへ送付
|
このアクティビティは、承認された発注書が、例えばメールやCoupaサプライヤーポータルを通じてベンダーに正式に送信される時点を示します。このイベントによって、POは内部文書から外部への約束へと移行します。 | ||
|
その重要性
これは、内部の購買依頼から発注までのサイクルを終了させ、サプライヤーのリードタイムを開始させる重要なマイルストーンです。社内効率とサプライヤーパフォーマンスの両方を測定する上で不可欠です。
取得元
発注書のステータスが「発注済み」または「送信済み」に変わったことから、しばしば推測されます。Coupaには、発注書記録に特定のlast_exported_atまたはsent_to_supplier_atのタイムスタンプがある場合もあります。
取得
ステータスが「発注済み」に変更されたタイムスタンプ、または特定の送信タイムスタンプフィールドから派生します。
イベントタイプ
inferred
|
|||
|
購買申請作成済
|
このアクティビティは、発注書に先行する商品またはサービスに対する正式な要求である購買依頼の作成を示します。Coupaでは、ユーザーが新しい依頼書を保存して提出した際に捕捉される明示的なイベントです。 | ||
|
その重要性
調達プロセスの典型的な開始点として、このアクティビティは、購買依頼から発注までのフルサイクルタイムを測定し、上流プロセス効率を理解するために不可欠です。
取得元
このイベントは、Coupaの購買依頼オブジェクトまたはテーブルにある作成レコードに相当し、タイムスタンプは「created_at」またはそれに相当するシステム生成の作成日フィールドで確認できます。
取得
新しい申請記録の作成時に直接記録されます。
イベントタイプ
explicit
|
|||
|
購買発注書キャンセル済み
|
このアクティビティは、発注書が完了する前のキャンセルを表します。キャンセルは、例えば依頼が無効になった場合や、発注書が誤って作成された場合など、様々な段階で発生する可能性があります。 | ||
|
その重要性
代替のプロセス終了点として、キャンセルを追跡することは、プロセスの失敗を理解し、破棄された購買リクエストの理由を特定するために重要です。
取得元
これは、発注書オブジェクトのステータスが「キャンセル済み」に変更されたことから推測されます。このステータス変更のタイムスタンプがイベント時間として使用されます。
取得
ステータスが「キャンセル済み」に変更されたタイムスタンプから派生します。
イベントタイプ
inferred
|
|||
|
購買発注書クローズ済み
|
これは最終アクティビティであり、発注書が完了したことを意味します。発注書は、完全に受領され、完全に請求され、それ以上のトランザクションが予想されない場合にクローズ済みと見なされます。 | ||
|
その重要性
このアクティビティは、発注書(PO)のライフサイクルを正式に終了させます。完了までの時間を分析することで、最終的な照合や記録管理における非効率性を明らかにすることができます。
取得元
これは、発注書オブジェクトのステータスが「クローズ済み」に変更されたことから推測されます。このステータスは、入庫および請求の許容範囲に関するビジネスルールに基づいてCoupaによって多くの場合、自動的に設定されます。
取得
ステータスが「クローズ済み」に変更されたタイムスタンプから派生します。
イベントタイプ
inferred
|
|||
|
購買発注書承認済み
|
このマイルストーンは、発注書が内部承認ワークフローを完了し、ベンダーへの発行が承認されたことを意味します。これは通常、多段階プロセスにおける最終承認ステップです。 | ||
|
その重要性
これは、発注書承認のサイクルタイムを計算する上で重要なマイルストーンであり、承認のボトルネックを特定するためにも使用されます。また、重要なコンプライアンスチェックポイントとしても機能します。
取得元
Coupaの発注書承認履歴ログから取得されます。最終承認アクションのタイムスタンプがイベントタイムとなります。
取得
最終承認者がタスクを完了した際に、承認履歴に記録されます。
イベントタイプ
explicit
|
|||
|
POに対する請求書受領
|
このイベントは、発注書を参照するサプライヤーからの請求書の受領と入力を示します。これは、P2Pサイクルにおける請求書処理と支払いフェーズの開始を意味します。 | ||
|
その重要性
APプロセスの一部ではありますが、請求書受領を発注書にリンクすることで、トランザクションライフサイクルのend-to-endビューが提供され、配送と請求の間のギャップを分析するのに役立ちます。
取得元
Coupaの請求書ドキュメントの作成タイムスタンプから取得されます。このドキュメントでは、請求書が対応するPurchase Order番号と照合されます。
取得
POにリンクされた請求書レコードの作成時に記録されます。
イベントタイプ
explicit
|
|||
|
サービス確認入力済
|
サービスベースの発注書の場合、このアクティビティは検収と同等です。発注書の条件に従ってサービスが提供されたことを確認します。 | ||
|
その重要性
サービス確認の追跡は、サービスに対する支出の管理と、完了が確認された作業に対してのみ支払いが確実に行われるようにするために不可欠です。
取得元
このイベントは、Coupaで発注書に紐付けられたサービス受領書またはサービス入力シートの作成または承認から取得されます。
取得
サービスエントリーシートの作成と承認時に記録されます。
イベントタイプ
explicit
|
|||
|
ベンダーが注文を承認
|
このイベントは、ベンダーが発注書を受領し、確認したことを意味します。この確認は、Coupa Supplier Portal (CSP)のようなサプライヤーポータルを通じて、多くの場合、電子的に取得されます。 | ||
|
その重要性
ベンダーからの承認は、注文が処理中であるという確実性をもたらし、配送予測の精度を向上させ、サプライチェーンの不確実性を低減します。
取得元
この情報は、ベンダーがCoupa Supplier Portalを使用して「Acknowledge」アクションを実行する場合に、発注書で通常利用可能です。このアクションのタイムスタンプが使用されます。
取得
ベンダーがサプライヤーポータルで「確認」アクションを実行した際に記録されます。
イベントタイプ
explicit
|
|||
|
品質検査実施済
|
このイベントは、受領品目が品質検査を受け、合格したことを示します。これは、初回入庫が計上された後の別のステップとなる場合があり、企業のプロセスによって異なります。 | ||
|
その重要性
このアクティビティは、品質管理プロセスの効率性を測る上で非常に重要です。ここでの遅延は、受入から利用可能となるまでの間にボトルネックを生み出す可能性があります。
取得元
これは、受領明細項目におけるステータス変更として、またはCoupa内の個別の検査オブジェクトを通じて記録されることがあります。その利用可能性は、品質モジュールやカスタムワークフローが使用されているかどうかによって異なります。
取得
受領書のステータス変更、または関連する検査記録のタイムスタンプから推測されます。
イベントタイプ
inferred
|
|||
|
商品返品済み
|
このアクティビティは、以前に受領した商品がベンダーに返品された際に記録されます。これは通常、品質問題、損傷、または誤出荷が原因です。 | ||
|
その重要性
返品の追跡は、商品返品率の計算や、サプライヤー品質または注文の正確性に関する問題の特定に不可欠です。高い返品率は、費用のかかるプロセス上の問題を示すことがよくあります。
取得元
これは、Coupaの「サプライヤーへの返品」トランザクションまたはマイナス入庫トランザクションから取得されます。このトランザクションのタイムスタンプがイベント時間として使用されます。
取得
元のPO/受領書にリンクされた返品トランザクションが作成された際に記録されます。
イベントタイプ
explicit
|
|||
|
検収開始
|
このアクティビティは、商品の現物到着時にCoupaで受領書が作成されるなど、受入プロセスの開始を表します。この時点では、商品はまだ正式に在庫に計上されたり、受領が確定されたりしていません。 | ||
|
その重要性
このイベントは、「入庫処理時間」KPIを測定するための起点です。これは、商品がドックで待機している時間とシステム処理に費やされた時間を区別するのに役立ちます。
取得元
これは、「下書き」または「保留中」ステータスの入庫伝票の作成タイムスタンプから推測できます。この情報は最終的な入庫計上に先行します。
取得
未転記状態の受領記録の作成タイムスタンプから派生します。
イベントタイプ
inferred
|
|||
|
発注書作成中
|
このイベントは、システム内での発注書ドキュメントの初期作成を表します。多くの場合、承認された購買依頼から作成されます。この段階では、発注書は内部の下書きであり、まだ承認のために提出されていないか、ベンダーに送付されていない`状態です。 | ||
|
その重要性
このアクティビティは、発注承認サイクルタイムKPIを測定するための開始点となります。これは、発注書自身のライフサイクルにおける最初の正式なステップです。
取得元
これは、Coupaにおける発注書レコードの作成タイムスタンプに相当し、通常、「created_at」のようなフィールドで確認できます。
取得
POレコードのシステム生成作成タイムスタンプから取得されます。
イベントタイプ
explicit
|
|||
|
発注書却下
|
このアクティビティは、承認ワークフロー中に承認者が発注書を却下した際に発生します。その後、POは通常、作成者へ差し戻され、修正またはキャンセルが行われます。 | ||
|
その重要性
却下されたケースを分析することで、データ品質の問題、ポリシー違反、またはトレーニングのギャップを明らかにできます。これにより、大幅なプロセス遅延を引き起こす手戻りの発生箇所を明確にできます。
取得元
これは、Coupaの発注書の承認履歴ログに記録される明示的なイベントです。ログには、対応するタイムスタンプと共に「却下」アクションが表示されます。
取得
「却下」ステータスとともに承認履歴に記録されます。
イベントタイプ
explicit
|
|||
|
発注書提出済
|
発注書が作成された後、正式に承認ワークフローに提出されます。これは、POを下書き状態から承認待ち状態に移行させる明確なユーザーアクションです。 | ||
|
その重要性
このイベントは、下書き作成時間と発注書が実際に承認待ちである時間を区別します。これにより、ユーザーの行動とプロセスの引き継ぎに関するより明確な全体像を把握できます。
取得元
発注書オブジェクトのステータス変更、例えば「下書き」から「承認待ち」への変更から推測されます。この特定のステータス変更のタイムスタンプが使用されます。
取得
ステータスが「承認待ち」に変更されたタイムスタンプから派生します。
イベントタイプ
inferred
|
|||
|
購買申請承認済
|
購買依頼は、発注書に変換される前に承認ワークフローを経ます。このイベントは、購買依頼の最終承認を意味し、発注準備が整ったことを示します。 | ||
|
その重要性
申請承認の追跡は、発注前段階におけるボトルネックの特定に役立ちます。ここでの遅延は、発注書発行の迅速さに直接影響を与えます。
取得元
これは通常、Coupaの申請オブジェクトにおける承認履歴から取得されます。最終承認アクションには、対応するタイムスタンプとユーザーが含まれます。
取得
最終承認者がアクションを実行した際に、承認履歴に記録されます。
イベントタイプ
explicit
|
|||
|
購買発注書変更済み
|
このイベントは、発注書が最初に下書きが作成された後に加えられたあらゆる変更を表します。Coupaでは、変更は多くの場合、発注書ドキュメントのバージョン管理によって追跡されます。 | ||
|
その重要性
変更の追跡は、発注書変更率や不適合発注書率といったKPIにとって極めて重要です。頻繁な変更は、プロセスの不安定さや初期リクエストの不正確さを示します。
取得元
発注書の異なるバージョンを追跡することで推測できます。最初のバージョンよりも大きい新しいバージョン番号は変更を示し、その新しいバージョンの作成日がイベントタイムスタンプとして扱われます。
取得
新しい発注書バージョンの作成タイムスタンプから推測されます。
イベントタイプ
inferred
|
|||