調達から支払いまで:発注書のデータテンプレート
調達から支払いまで:発注書のデータテンプレート
- データを網羅的に収集するための推奨属性
- 記録・分析する主要なプロセスアクティビティ
- Oracle Fusion Financialsからのデータ抽出手順
調達から支払いまで:発注書の属性
| 名前 | 説明 | ||
|---|---|---|---|
|
アクティビティ
ActivityName
|
発注書のライフサイクルで発生した、特定の業務イベントまたはステップの名前です。 | ||
|
説明
発注書の作成や商品の受領など、プロセス内の特定のタスクやステータス変更を表す属性です。これらのアクティビティが、プロセスフローを構成する一連のイベントになります。 アクティビティの順序や所要時間の分析は、プロセスマイニングの中心となる作業です。プロセスマップを可視化し、ボトルネックの特定、標準手順からの逸脱の発見、各ステップの所要時間の測定に役立ちます。
重要な理由
アクティビティはプロセスマップを構成する要素です。追跡することで、プロセスフローやボトルネック、逸脱を可視化して分析できます。
入手先
PO_HEADERS_ALLやPO_ACTION_HISTORYなどのテーブルに記録されたステータス変更、または入荷の場合はRCV_TRANSACTIONSなどの取引テーブルから導出します。
例
発注書を作成発注書を承認商品の受領
|
|||
|
発注書
PurchaseOrder
|
発注書を一意に識別する番号です。調達のライフサイクルを追跡する際の主要なケースIDとして使われます。 | ||
|
説明
発注書番号は、作成から最終クローズまで、関連するすべてのアクティビティを結び付ける中心的な識別子です。この番号を使うと、個々の調達ケースを最初から最後まで分析できます。 プロセスマイニングでは、一意の発注書番号がプロセスの1つのインスタンスを表します。この番号でデータをグループ化して分析すると、個々の発注におけるプロセスの違い、サイクルタイム、コンプライアンスを把握できます。
重要な理由
関連するすべてのイベントを結び付ける重要なケースIDです。発注書のライフサイクル全体を再構成し、分析できます。
入手先
Oracle Fusion Cloud SCMの調達モジュールにあるPO_HEADERS_ALLテーブルのSEGMENT1列。
例
100234510023461002347
|
|||
|
開始時刻
EventTime
|
特定のアクティビティまたはイベントが発生した時刻を示すタイムスタンプです。 | ||
|
説明
プロセス内の各アクティビティについて、正確な日時を記録する属性です。イベントを時系列に並べるための基礎となり、時間に基づくあらゆる分析に使われます。 プロセスマイニングでは、開始時刻を使ってイベントログを作成し、アクティビティ間のサイクルタイムや待ち時間を計算し、期間ごとのプロセスパフォーマンスを分析します。サイクルタイムやパフォーマンスに関するダッシュボードにも欠かせません。
重要な理由
イベントを正しい順序に並べ、サイクルタイムやボトルネックなど、所要時間に基づく指標を計算するうえで重要なタイムスタンプです。
入手先
PO_HEADERS_ALL、PO_ACTION_HISTORY、RCV_SHIPMENT_LINESなど、各テーブルのCREATION_DATEやLAST_UPDATE_DATEといったタイムスタンプフィールド。
例
2023-04-15T10:05:00Z2023-04-16T14:30:00Z2023-05-01T09:00:00Z
|
|||
|
ユーザー
UserName
|
アクティビティを実行した人のユーザーIDまたは名前です。 | ||
|
説明
購買依頼の作成、発注書の承認、入荷の計上など、各イベントを担当した従業員またはシステムユーザーを示す属性です。通常、「作成者」や「最終更新者」などのフィールドから取得します。 ユーザー別にプロセスを分析すると、業務負荷の分布や個人のパフォーマンスを把握し、研修が必要な領域を特定できます。「承認リソース負荷」ダッシュボードや、ユーザー操作に関連するコンプライアンス上の問題の調査にも欠かせません。
重要な理由
ユーザーの操作を個人にひも付け、業務負荷の分析、パフォーマンスの評価、研修機会の特定に役立てます。
入手先
PO_HEADERS_ALLやPO_ACTION_HISTORYなどのテーブルにあるCREATED_BYやLAST_UPDATED_BYなどのフィールドのIDを使い、ユーザーテーブルと結合します。
例
john.doejane.smithsystem.batch
|
|||
|
仕入先名
VendorName
|
商品やサービスの購入先となるサプライヤーまたは仕入先の名前です。 | ||
|
説明
発注書に関連付けられた外部の仕入先を示す属性です。発注書ヘッダーにひも付く重要なマスターデータです。 仕入先分析は、調達から支払いまでのプロセスマイニングの重要な要素です。仕入先で絞り込みや分類を行うと、「仕入先の納品実績」を分析して納期遵守率を比較したり、「商品の返品率」を調べて実績の高い仕入先と低い仕入先を特定したりできます。仕入先との関係管理や戦略的な調達に欠かせないデータです。
重要な理由
仕入先ごとの納品日数、返品率、全体的な信頼性を比較し、サプライヤーパフォーマンスを分析するうえで欠かせません。
入手先
PO_HEADERS_ALL.VENDOR_IDからPOZ_SUPPLIERS.VENDOR_NAMEに関連付けられています。
例
Global Office SuppliesTech Solutions Inc.Advanced Logistics Co.
|
|||
|
希望納品日
RequestedDeliveryDate
|
依頼元が商品やサービスの納品を希望する日付です。 | ||
|
説明
発注書の明細に指定され、希望する納品時期を仕入先に伝える日付です。納期遵守パフォーマンスを測る際のベースラインになります。 納期遵守率の重要業績評価指標(KPI)を計算するうえで欠かせません。実際の入荷日と希望納品日を比較すると、仕入先の信頼性を定量的に測定して追跡し、サプライチェーン全体で繰り返し発生する遅延を特定できます。
重要な理由
納期遵守パフォーマンスを測る際のベースラインです。仕入先の信頼性やサプライチェーンの効率を評価する重要業績評価指標(KPI)に使われます。
入手先
PO_LINE_LOCATIONS_ALLテーブルの明細ロケーションレベルにあるNEED_BY_DATE列。
例
2023-05-202023-06-152023-07-01
|
|||
|
承認者名
ApproverName
|
発注書の承認または却下を行ったユーザーの名前です。 | ||
|
説明
ワークフローの承認ステップを担当した人を記録する属性です。通常、発注書に関連付けられた操作履歴テーブルやワークフローログテーブルに保存されます。 承認者別のデータ分析は、「発注書の承認サイクルタイム分析」や「承認リソース負荷」のダッシュボードに欠かせません。ボトルネックとなっている承認者や承認グループの特定、公平な業務負荷の評価、委任やプロセスの再設計が可能な箇所の把握に役立ちます。
重要な理由
承認プロセスに関わる人を特定し、承認者ごとのボトルネック、業務負荷、サイクルタイムを分析できます。
入手先
操作を実行したユーザーです。PO_ACTION_HISTORY.ACTION_PERFORMED_BYから取得し、ユーザーテーブルと結合して氏名を確認します。
例
susan.managerdavid.directoremily.finance
|
|||
|
発注書の合計金額
PurchaseOrderTotalAmount
|
発注書の金額の合計です。 | ||
|
説明
指定通貨での発注書の全明細の合計金額を表す属性です。プロセス内で処理される取引の金額を把握するための重要な財務指標です。 発注書の合計金額を分析すると、プロセス改善の優先順位を決める際に役立ちます。たとえば、高額の発注に対して、より厳格な承認プロセスを設定できます。また、頻繁に変更または遅延する発注書の金額を算出するなど、財務への影響も分析できます。
重要な理由
金額に基づく分析が可能になり、高額の発注への注目や、遅延による財務への影響の把握に役立ちます。
入手先
PO_LINES_ALLの金額を発注書ヘッダーごとに合計して算出します。ヘッダーレベルの合計金額がある場合は、その値を使用します。
例
5250.00120000.50750.99
|
|||
|
終了時刻
EndTime
|
アクティビティが完了した時刻を示すタイムスタンプです。単独で発生するイベントでは、開始時刻と同じ場合がよくあります。 | ||
|
説明
所要時間のあるアクティビティでは、完了時刻を示します。瞬時に発生するイベントでは、通常、開始時刻と同じです。個々のアクティビティの処理時間を計算するために必要です。 終了時刻を個別に記録すると、アクティビティの所要時間をより正確に分析できます。アクティビティ間の待ち時間と区別できるため、実作業時間と待機時間を分けて把握し、リソースの負荷や効率を分析できます。
重要な理由
アクティビティの処理時間を正確に計算できます。リソースの効率を分析し、時間のかかるタスクを特定するうえで重要です。
入手先
単独で発生するイベントでは開始時刻と同じ場合があります。または、後続イベントのタイムスタンプから算出します。アクティビティによっては、別途完了時刻が記録されている場合があります。
例
2023-04-15T10:05:00Z2023-04-16T14:45:00Z2023-05-01T09:15:00Z
|
|||
|
部門
DepartmentName
|
発注を開始した、または発注を担当する部門の名前です。 | ||
|
説明
購入に関連する「財務」「IT」「製造」などの組織単位を示す属性です。原価配賦や組織別のレポートに使われます。 プロセスマイニングでは、部門別にプロセスを分類することで、パフォーマンスの比較や部門固有のボトルネックの特定、組織内での実行方法の違いの把握ができます。「発注書の承認サイクルタイム分析」や「発注書の変更傾向」などのダッシュボードにも役立ちます。
重要な理由
事業部門ごとにプロセスパフォーマンスを絞り込んで比較し、部門固有の問題や優れた取り組みを明らかにできます。
入手先
PO_DISTRIBUTIONS_ALLなどのテーブルにある原価センター情報から導出します。このテーブルは部門マスターデータと関連付けられています。
例
IT運用マーケティング研究開発
|
|||
|
ソースシステム
SourceSystem
|
このデータの抽出元となる情報システムです。 | ||
|
説明
データの抽出元を示す属性です。複数のシステムを連携している環境で特に役立ちます。このプロセスでは、通常「Oracle Fusion Financials」が該当します。 データセット内では固定値であることが多いものの、データガバナンス、問題の調査、データの来歴確認に欠かせません。複数のソースのデータを組み合わせた分析では、抽出元のシステムで絞り込みや分類ができます。
重要な理由
データの抽出元を示します。データガバナンスやコンテキストの把握、他システムとの連携に欠かせません。
入手先
通常、データの抽出・変換(ETL)処理で定義して追加する固定値です。
例
Oracle Fusion FinancialsOracle Cloud SCMOracle Fusion P2P
|
|||
|
事業部門
BusinessUnitName
|
購入を行う組織内の事業部門です。 | ||
|
説明
事業部門は、独自の元帳や財務報告を持つことが多い、企業内の独立した事業体です。Oracle Fusionでは、データを分離するための主要な仕組みです。 大規模な多国籍企業では、事業部門別のプロセスパフォーマンス分析が欠かせません。組織内の各部門について、調達の効率、コンプライアンス、コストを比較し、優れた取り組みや改善が必要な領域を特定できます。
重要な理由
大規模な組織で、異なる事業部門間のプロセス効率やコンプライアンスを比較するうえで重要です。
入手先
事業部門の情報は通常、発注書ヘッダーのPO_HEADERS_ALL.PRC_BU_IDにあり、FUN_ALL_BUSINESS_UNITS_Vビューに関連付けられています。
例
米国事業部門EMEAビジョンAPACサービス
|
|||
|
最終データ更新日時
LastDataUpdate
|
ソースシステムからデータを最後に抽出または更新した時刻です。 | ||
|
説明
分析対象データの鮮度を示す属性です。Oracle Fusion Financialsからデータを最後に取得した日時を記録します。 分析やダッシュボードの情報がどの程度新しいかを把握するうえで重要です。プロセスに関するインサイトがどこまで最新の取引を含んでいるかが明確になり、直近の取引が反映されているかについて適切な見通しを持てます。
重要な理由
データの鮮度を明示し、プロセス分析がどの時点の情報に基づいているかを把握できます。
入手先
データの抽出・変換(ETL)処理で生成して追加するタイムスタンプです。
例
2023-10-27T02:00:00Z2023-10-28T02:00:00Z
|
|||
|
手戻りの有無
IsRework
|
発注書が最初に作成された後に変更されたかどうかを示すフラグです。 | ||
|
説明
計算される真偽値属性です。発注書のケースに「発注書変更」アクティビティが含まれる場合はtrueに設定されます。修正や変更が必要だった注文をすばやく特定できます。 このフラグを使うと、「発注書変更率」の重要業績評価指標(KPI)を簡単に計算でき、手戻りが発生した注文を容易に絞り込んで分析できます。手戻りが発生した注文の特徴(関与した仕入先や部門など)を把握することで、データの不正確さや要件変更の根本原因を特定しやすくなります。
重要な理由
「発注書変更率」の重要業績評価指標(KPI)に直接対応し、変更があったすべての注文にフラグを付けることで、プロセスの不安定さを簡単に分析できます。
入手先
計算フィールドです。ケースのイベントログに「発注書変更」アクティビティが含まれる場合は「true」、含まれない場合は「false」に設定されます。
例
truefalse
|
|||
|
承認コンプライアンスの適合状況
IsApprovalCompliant
|
発注書が仕入先に送付される前に承認されたかどうかを示すフラグです。 | ||
|
説明
重要な内部統制への準拠状況を確認する計算される真偽値属性です。発注書は仕入先に送付する前に承認されている必要があります。「発注書承認」アクティビティが「発注書を仕入先に送付」アクティビティより前に発生した場合、trueになります。 この属性は「発注書プロセスのコンプライアンス監査」ダッシュボードと「発注書承認コンプライアンス率」の重要業績評価指標(KPI)に欠かせません。コンプライアンス違反を簡単に特定して定量化できるため、調達方針の徹底や、承認されていない支出に伴うリスクの軽減に役立ちます。
重要な理由
「発注書承認コンプライアンス率」の重要業績評価指標(KPI)を直接測定し、承認前に注文が仕入先へ送付される重大な内部統制違反を明らかにします。
入手先
計算フィールドです。「発注書承認」のタイムスタンプが「発注書を仕入先に送付」のタイムスタンプ以前の場合は「true」に設定されます。
例
truefalse
|
|||
|
発注書のステータス
PurchaseOrderStatus
|
発注書の現在のステータスです。 | ||
|
説明
発注書のライフサイクルにおける現在の状態を示す属性です。「オープン」「承認済み」「最終クローズ」「キャンセル」などの状態が該当します。発注書の進捗状況を把握できます。 プロセスマイニングではアクティビティの順序を分析しますが、現在のステータスを使ってケースを絞り込むこともできます。たとえば、オープンの発注書だけを対象に現在の処理状況を確認したり、クローズ済みの発注書を対象に完了したプロセスを分析したりできます。「発注書のフローとステータス」ダッシュボードに欠かせない属性です。
重要な理由
発注書の現在の状態を把握し、処理中、完了、キャンセル済みの発注書に絞って分析できます。
入手先
Oracle Fusion Cloud SCMのPO_HEADERS_ALLテーブルにあるAUTHORIZATION_STATUS列またはDOCUMENT_STATUS列。
例
オープン承認済み最終クローズキャンセル済み
|
|||
|
発注書の種類
PurchaseOrderType
|
「標準」「包括契約」「契約」など、発注書の種類です。 | ||
|
説明
調達の目的に基づいて発注書を分類する属性です。発注書の種類によって、適用されるプロセスのルールやライフサイクルが異なることがあります。 「標準」発注書は1回限りの購入に使われ、「包括契約」発注書は仕入先との長期契約に使われます。種類別にプロセスを分析すると、パフォーマンスをより正確に把握できます。標準発注書と包括契約のサイクルタイムを比較しても、条件が異なるため適切な比較にはなりません。同じ種類の発注書同士を比較できます。
重要な理由
調達の種類を区別し、条件の近い発注書同士でプロセスパフォーマンスを正確に比較できます。
入手先
Oracle Fusion Cloud SCMのPO_HEADERS_ALLテーブルにあるTYPE_LOOKUP_CODE列。
例
標準包括契約契約
|
|||
|
納品先
DeliveryLocation
|
商品を納品する場所または住所です。 | ||
|
説明
発注書の商品を納品する住所を示す属性です。物流に関する重要な情報です。 プロセスマイニングでは、納品先別の分析が「入荷処理の効率」ダッシュボードに役立ちます。倉庫や拠点による受入処理の遅れを特定し、特定の場所におけるリソースやプロセスの問題を把握できます。
重要な理由
地域別にパフォーマンスを分析し、入荷処理における地域や拠点固有のボトルネックを特定できます。
入手先
PO_LINE_LOCATIONS_ALL.SHIP_TO_LOCATION_IDからHR_LOCATIONS_ALLビューに関連付けられています。
例
本社倉庫-Aドック3号館-受付サンフランシスコオフィス-10階
|
|||
|
納品遅延の有無
IsLateDelivery
|
最終的な入荷が希望納期を過ぎたかどうかを示すフラグです。 | ||
|
説明
計算される真偽値属性です。特定の発注書について、「商品受領」アクティビティのタイムスタンプが「希望納期」属性の値より後の場合にtrueになります。 このフラグは「納期遵守率」の重要業績評価指標(KPI)の基礎となります。納期遅延と納期遵守の注文を簡単に分類して分析できるため、特定の仕入先、拠点、商品カテゴリーなどに起因する遅延の根本原因を調査できます。
重要な理由
「納期遵守率」の重要業績評価指標(KPI)に直接対応し、仕入先の実績と納品の信頼性を明確に分析できます。
入手先
計算フィールドです。「商品受領」アクティビティのタイムスタンプが「RequestedDeliveryDate」属性の日付より後の場合は「true」に設定されます。
例
truefalse
|
|||
|
購買カテゴリ
PurchaseCategory
|
購入する商品やサービスの分類です。「ITハードウェア」や「事務用品」などが該当します。 | ||
|
説明
発注書の明細を調達階層に沿って分類する属性です。この分類は、支出分析や仕入先管理に使われます。 プロセスマイニングでは、購買カテゴリ別にプロセスを分類すると、カテゴリごとの業務の進め方やパフォーマンスの違いが明らかになります。たとえば、設備投資の承認には、業務用消耗品より時間がかかる場合があります。「商品の返品率と理由」ダッシュボードでは、返品が多いカテゴリを分析できます。
重要な理由
支出の種類ごとにプロセスを分析し、商品カテゴリによる経路、ボトルネック、返品率の違いを明らかにできます。
入手先
PO_LINES_ALL.CATEGORY_IDからEGP_CATEGORIES_VLビューに関連付けられています。
例
IT.ハードウェア.ノートパソコン事務用品.文房具専門サービス.コンサルティング
|
|||
|
購買依頼
PurchaseRequisitionNumber
|
発注書に先立って作成され、発注を承認した購買依頼の識別子です。 | ||
|
説明
購買依頼は、商品やサービスの調達を申請するための社内文書です。この属性を使うと、発注書を元の依頼に関連付けられます。 購買依頼番号を含めることで、発注書だけでなく、最初の依頼から始まる調達プロセス全体を分析できます。依頼から発注までのサイクルタイムや、購買依頼の詳細が後続の発注プロセスに与える影響を把握するのに役立ちます。
重要な理由
発注書を最初の依頼に関連付け、購買依頼から支払いまでのプロセス全体を分析できます。
入手先
REQ_DISTRIBUTION_IDを含むPO_DISTRIBUTIONS_ALLテーブルを介して関連付けられ、POR_REQUISITION_LINES_ALLテーブルまでたどれます。
例
PR-2023-05-001PR-2023-05-002PR-2023-05-003
|
|||
調達から支払いまで:発注書のアクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
|
商品の受領
|
商品が実際に納入され、数量を確認したうえで発注書に記録されています。この取引イベントにより、在庫と発注書のステータスが更新されます。 | ||
|
重要な理由
仕入先の納期遵守パフォーマンスと全体のリードタイムを測るうえで、重要なマイルストーンです。また、品質検査や請求書照合など、後続のアクティビティを開始するきっかけにもなります。
入手先
RCV_TRANSACTIONSテーブルに明示的に記録されるイベントです。TRANSACTION_TYPEが「RECEIVE」の取引によって特定できます。
記録
RCV_TRANSACTIONSでTRANSACTION_TYPEが「RECEIVE」のレコードのTRANSACTION_DATEを使用します。
イベントタイプ
explicit
|
|||
|
発注書のキャンセル
|
発注書が完全にキャンセルされ、以降の取引が予定されていない状態です。明示的な操作によって、文書の最終ステータスが変更されます。 | ||
|
重要な理由
このアクティビティは、プロセスが正常に完了しなかったことを示します。キャンセルを分析すると、発注の重複、予算の変更、プロジェクト要件の変更などの問題が明らかになる場合があります。
入手先
この操作はPO_ACTION_HISTORYテーブルにACTION_CODEが「CANCEL」として記録され、PO_HEADERS_ALLの発注書ステータスもそれに応じて更新されます。
記録
PO_ACTION_HISTORYをACTION_CODE = 「CANCEL」で絞り込みます。
イベントタイプ
explicit
|
|||
|
発注書の最終クローズ
|
発注書が完了した状態です。商品がすべて受領済み、または請求書の処理が完了しており、以降のアクティビティは予定されていません。明示的な操作によって、発注書が最終ステータスに設定されます。 | ||
|
重要な理由
このアクティビティは、発注書のライフサイクルが正常に完了したことを示します。プロセスの主な正常終了状態であり、全体の処理量や完了率を測るうえで追跡が欠かせません。
入手先
このイベントはPO_ACTION_HISTORYテーブルにACTION_CODEが「FINALLY CLOSE」として記録されます。PO_HEADERS_ALLの発注書ステータスも「Finally Closed」に更新されます。
記録
PO_ACTION_HISTORYをACTION_CODE = 「FINALLY CLOSE」で絞り込みます。
イベントタイプ
explicit
|
|||
|
発注書を仕入先に送信
|
承認済みの発注書を、メールやEDIなどで正式に仕入先へ送信します。このイベントは、ステータスの変更や発注書の連絡記録にあるタイムスタンプから推定されることがよくあります。 | ||
|
重要な理由
ここから仕入先側のリードタイムが始まります。受領確認から最終納品までの仕入先のパフォーマンスを測定するうえで重要な時点です。
入手先
発注書文書のステータスが「オープン」に変わり、連絡日が入力されたことから推定できます。該当項目は通常、PO_HEADERS_ALL.communicated_dateまたは関連するステータス項目です。
記録
発注書の連絡ステータスが「連絡済み」に更新された時点のタイムスタンプから推定します。
イベントタイプ
inferred
|
|||
|
発注書を作成
|
発注書のライフサイクルが正式に始まる時点です。下書きまたは未完了のステータスで発注書文書が作成されます。新しい発注書ヘッダーレコードの作成タイムスタンプが記録されます。 | ||
|
重要な理由
発注書ケースの開始イベントとなるこのアクティビティは、すべてのサイクルタイム計算の基準です。承認や仕入先への連絡など、後続手順の効率を測定するベースラインになります。
入手先
対象の発注書ID(PO_HEADER_ID)について、PO_HEADERS_ALLテーブルのCREATION_DATE項目を基に記録される明示的なイベントです。
記録
PO_HEADERS_ALLテーブルの作成タイムスタンプを使用します。
イベントタイプ
explicit
|
|||
|
発注書を承認
|
発注書に必要な承認がすべて完了し、仕入先に送付できる状態になったことを示します。文書の操作履歴に明示的に記録される重要なマイルストーンです。 | ||
|
重要な理由
この重要なマイルストーンを通過するまで、発注書を仕入先に送付できません。承認サイクルタイムの測定や支出規程の遵守確認に欠かせません。
入手先
このイベントは通常、PO_ACTION_HISTORYテーブルにACTION_CODE「APPROVE」として記録されます。または、PO_HEADERS_ALLの文書ステータスが承認済みの状態に変わった時点で確認できます。
記録
PO_ACTION_HISTORYを最後の「APPROVE」アクションで絞り込みます。
イベントタイプ
explicit
|
|||
|
サービス提供の確認
|
サービスの発注書では、合意したサービスが提供されたことを確認するアクティビティです。確認内容は、手動またはサービス入力シートで記録されることが一般的です。 | ||
|
重要な理由
サービスの受領に相当する処理で、請求書の支払い前に必要な重要なステップです。サービスの確認が遅れると、支払いの遅延や仕入先との関係悪化につながる可能性があります。
入手先
通常、発注書のサービス明細に対する受領として記録されます。サービスの進捗や完了を追跡するため、専用のフィールドや複雑な受領処理が使われる場合があります。
記録
サービスの発注書明細に関連付けられた受領取引(RCV_TRANSACTIONS)を特定します。
イベントタイプ
explicit
|
|||
|
入荷書類の作成
|
商品の到着に備え、システム上で入荷書類が作成されます。このアクティビティは、社内の入荷プロセスの開始を示します。 | ||
|
重要な理由
この時点で、調達から物流へと移行します。この時点から最終的な入荷計上までの時間を分析すると、倉庫や受入部門の非効率な箇所を特定できます。
入手先
発注書に関連付けられた新しいレコードがRCV_SHIPMENT_HEADERSテーブルに作成された時刻によって、明示的に記録されるイベントです。
記録
対応するRCV_SHIPMENT_HEADERSレコードの作成日を使用します。
イベントタイプ
explicit
|
|||
|
品質検査の実施
|
品質管理が必要な商品を検査し、受け入れるか、却下します。このアクティビティは最初の受領後に行われ、独立した取引として記録されます。 | ||
|
重要な理由
品質管理に欠かせないアクティビティです。検査にかかる時間を分析すると、品質管理プロセスを効率化し、商品を使用できる状態にするまでの遅延を減らせます。
入手先
RCV_TRANSACTIONSテーブルに記録されます。受領取引の後に続く、TRANSACTION_TYPEが「ACCEPT」または「REJECT」の取引によって特定できます。
記録
RCV_TRANSACTIONSでTRANSACTION_TYPEが「ACCEPT」または「REJECT」のレコードのTRANSACTION_DATEを使用します。
イベントタイプ
explicit
|
|||
|
商品を仕入先へ返品
|
受領済みの商品を、通常は不良、破損、誤納などの理由で仕入先へ返送します。受入モジュールでは、返品取引として記録されます。 | ||
|
重要な理由
返品を追跡することは、仕入先の品質と発注内容の正確さを評価するうえで欠かせません。特定の仕入先への返品率が高い場合、対処が必要な構造的な問題がある可能性があります。
入手先
RCV_TRANSACTIONSテーブルに、TRANSACTION_TYPEが「RETURN TO VENDOR」の明示的なイベントとして記録されます。
記録
RCV_TRANSACTIONSでTRANSACTION_TYPEが「RETURN TO VENDOR」のレコードのTRANSACTION_DATEを使用します。
イベントタイプ
explicit
|
|||
|
発注書の受領を確認
|
仕入先が発注書を受領し、条件に同意したことを確認した状態です。仕入先との連絡内容に基づいて調達担当者が手動で記録するか、電子的な受領確認を通じて記録されます。 | ||
|
重要な理由
仕入先から受領確認を得ることで、注文が届き、処理が進んでいることを確認できます。これを追跡すると、仕入先との連絡を管理し、履行上の問題の可能性を早期に特定できます。
入手先
通常、発注書ヘッダーまたは明細の受領確認ステータス項目の変更から推定します。たとえば、PO_HEADERS_ALL.acceptance_statusが「Accepted」に変わった場合です。
記録
発注書の受領確認ステータス項目の更新から推定します。
イベントタイプ
inferred
|
|||
|
発注書を却下
|
承認者が発注書を却下し、修正のため作成者に差し戻したことを示します。操作履歴に明示的に記録され、標準的なプロセスの流れから外れたことが分かります。 | ||
|
重要な理由
却下が発生すると、プロセスに手戻りや遅延が生じます。このアクティビティを追跡することで、却下のよくある理由や研修の必要性、承認要件の不明確さを特定できます。
入手先
この操作は、該当するPO_HEADER_IDについて、PO_ACTION_HISTORYテーブルにACTION_CODE「REJECT」として記録されます。
記録
PO_ACTION_HISTORYをACTION_CODE = 'REJECT'で絞り込みます。
イベントタイプ
explicit
|
|||
|
発注書を変更
|
発注書が最初に承認された後、数量、価格、納品日などが変更されています。Oracle Fusionでは、文書の新しい改訂版を作成して変更を記録します。 | ||
|
重要な理由
発注書の変更は手戻りを意味し、発注時の内容の不正確さや、変化する業務ニーズを示している場合があります。変更の頻度や内容を分析すると、プロセスを効率化できる箇所を特定できます。
入手先
新しい文書の改訂版が作成されると、このイベントが明示的に記録されます。PO_HEADERS_ALLテーブルのREVISION_NUMフィールドが増加したかどうかで特定できます。
記録
PO_HEADER_IDに対応するREVISION_NUMが増加した各ケースを特定します。
イベントタイプ
explicit
|
|||
|
発注書を提出
|
作成した発注書を承認ワークフローに提出します。Oracle Fusionにはこの操作が明示的に記録され、提出したユーザーとタイムスタンプが保存されます。 | ||
|
重要な理由
このアクティビティは承認サイクルの開始を示します。提出から承認までの時間を分析することで、社内の承認プロセスにおけるボトルネックを特定できます。
入手先
この操作は、該当するPO_HEADER_IDについて、PO_ACTION_HISTORYテーブルにACTION_CODE「SUBMIT」として記録されます。
記録
PO_ACTION_HISTORYをACTION_CODE = 'SUBMIT'で絞り込みます。
イベントタイプ
explicit
|
|||
|
購買依頼を作成
|
このアクティビティは、発注書に先立つ商品やサービスの正式な依頼である購買依頼の作成を示します。Oracle Fusionの購買依頼ヘッダーテーブルに新しいレコードが作成された時点で記録されます。 | ||
|
重要な理由
このアクティビティを分析すると、需要が発生する段階を把握できます。購買依頼から発注書の作成までの時間を追跡することで、社内の需要を実際の調達注文に移す際の遅延を特定できます。
入手先
新しい購買依頼の保存時に記録される明示的なイベントです。POR_REQUISITION_HEADERS_ALLテーブルの作成タイムスタンプを追跡して確認できます。
記録
POR_REQUISITION_HEADERS_ALLテーブルのレコード作成日を基にしたイベントです。
イベントタイプ
explicit
|
|||
|
購買依頼を承認
|
指定された承認者が購買依頼を承認し、調達部門が発注書を作成できる状態になったことを示します。このイベントは、購買依頼の操作履歴に明示的に記録されます。 | ||
|
重要な理由
このマイルストーンは、依頼に対する社内承認プロセスの完了を示します。ここでの遅延は調達全体のスケジュールに直接影響するため、所要時間の監視が重要です。
入手先
このイベントは購買依頼に関連する操作履歴に記録され、通常はワークフローテーブルまたは購買依頼文書の承認ステータス項目で追跡します。
記録
該当する購買依頼文書のワークフロー履歴に、承認アクションとして記録されます。
イベントタイプ
explicit
|
|||
データ抽出ガイド
始める準備はできましたか?
このテンプレートを使ってデータ収集を効率化し、調達から支払いまでの発注書プロセスに関するインサイトを見つけましょう。今すぐ業務の最適化を始めてください。
今すぐ調達から支払いまでの発注書プロセスを最適化
コストにつながるボトルネックを特定し、サイクルタイムを簡単に30%短縮できます。
クレジットカードは不要です。今すぐ業務の最適化を始めましょう。