調達から支払いまで:発注書データテンプレート

Oracle Fusion Financials
調達から支払いまで:発注書データテンプレート

調達から支払いまで:発注書データテンプレート

このテンプレートでは、調達から支払いまでの発注書プロセスを分析するために必要なデータを収集する手順を示します。必要なデータ属性、追跡すべき主要なアクティビティ、情報を抽出するための具体的な方法をまとめています。プロセスマイニングに必要な情報を漏れなく収集するためにご利用ください。
  • 詳細なデータ収集に推奨される属性
  • 追跡・分析すべき主要なプロセスアクティビティ
  • Oracle Fusion Financialsからデータを抽出する手順
イベントログを初めて扱いますか。学ぶ プロセスマイニングのイベントログを作成する方法.

調達から支払いまで:発注書の属性

調達から支払いまで:発注書プロセスを詳細に分析するため、イベントログに含めることを推奨するデータ項目です。
3 必須 7 推奨 11 任意
名前 説明
アクティビティ
ActivityName
発注書のライフサイクル内で発生した、特定の業務イベントまたはステップの名称です。
説明

この属性は、「発注書を作成」や「商品を受領」など、プロセス内の特定のタスクまたはステータス変更を表します。これらのアクティビティが、プロセスフローを構成する一連のイベントになります。

アクティビティの順序とタイミングの分析は、プロセスマイニングの中心です。プロセスマップの可視化、ボトルネックの特定、標準手順からの逸脱の発見、特定ステップの所要時間の測定に役立ちます。

重要な理由

アクティビティはプロセスマップを構成する基本要素です。追跡することで、プロセスフロー、ボトルネック、逸脱を可視化して分析できます。

入手先

PO_HEADERS_ALLやPO_ACTION_HISTORYなどのテーブルにおけるステータス変更、または入荷の場合はRCV_TRANSACTIONSなどの取引テーブルから導出します。

発注書を作成発注書を承認商品を受領
発注書
PurchaseOrder
調達ライフサイクルを追跡する際の主要なケースIDとなる、発注書ドキュメントの一意の識別子です。
説明

発注書番号は、作成から最終クローズまで、関連するすべてのアクティビティを結び付ける中心的な識別子です。これにより、1件の調達ケースをエンドツーエンドで分析できます。

プロセスマイニングでは、一意の発注書番号がプロセスの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
サプライヤー名
VendorName
商品またはサービスの購入先となるサプライヤーの名称です。
説明

この属性は、発注書の外部サプライヤーを示します。発注書ヘッダーに関連付けられた重要なマスターデータです。

サプライヤー分析は、調達から支払いまでのプロセスマイニングにおける重要な要素です。サプライヤー別にフィルタリングまたはセグメント化することで、「サプライヤー納入パフォーマンス」を分析し、納期遵守率を比較できます。また、「商品返品率」を調査して、パフォーマンスの高いサプライヤーと低いサプライヤーを特定できます。サプライヤーとの関係管理や戦略的な調達に欠かせないデータです。

重要な理由

サプライヤーのパフォーマンス分析に欠かせません。サプライヤー間で納入時間、返品率、全体的な信頼性を比較できます。

入手先

PO_HEADERS_ALL.VENDOR_IDからPOZ_SUPPLIERS.VENDOR_NAMEへリンクします。

グローバルオフィス用品Tech Solutions Inc.Advanced Logistics Co.
ユーザー
UserName
アクティビティを実行した担当者のユーザーIDまたは氏名です。
説明

この属性は、購買依頼の作成、発注書の承認、入荷の計上など、特定のイベントを担当した従業員またはシステムユーザーを示します。通常は「Created By」や「Last Updated By」などの項目から取得します。

ユーザー別にプロセスを分析すると、業務負荷の分布、個人のパフォーマンス、トレーニングの必要性を把握できます。「承認担当者の業務負荷」ダッシュボードや、ユーザー操作に関するコンプライアンス上の問題を調査する際にも欠かせません。

重要な理由

ユーザーの操作を特定の担当者に結び付け、業務負荷の分析、パフォーマンス評価、トレーニング機会の特定を可能にします。

入手先

PO_HEADERS_ALLやPO_ACTION_HISTORYなどのテーブルにあるCREATED_BYまたはLAST_UPDATED_BYのIDを基に、ユーザーテーブルと結合します。

john.doejane.smithsystem.batch
希望納入日
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 VisionAPAC Services
再作業あり
IsRework
発注書が初回作成後に変更されたかどうかを示すフラグです。
説明

発注書のケースに「Purchase Order Changed」アクティビティが含まれる場合にtrueとなる、計算されたブール型属性です。修正や変更が必要だった発注書をすばやく特定できます。

「発注書変更率」KPIの算出を簡単にし、再作業が発生した発注書を容易に絞り込んで分析できます。再作業が発生した発注書について、関係する仕入先や部門などの特徴を把握すると、データの不正確さや要件変更の根本原因を特定しやすくなります。

重要な理由

「発注書変更率」KPIを直接支援し、変更が発生したすべての発注書にフラグを付けることで、プロセスの不安定さを簡単に分析できます。

入手先

計算フィールドです。ケースのイベントログに「Purchase Order Changed」アクティビティが含まれる場合は「true」、それ以外の場合は「false」に設定されます。

truefalse
最終データ更新日時
LastDataUpdate
ソースシステムからデータを最後に抽出または更新した時点のタイムスタンプです。
説明

この属性は、分析対象データの新しさを示します。Oracle Fusion Financialsから直近にデータを取得した日時を記録します。

この情報は、分析やダッシュボードの適時性を理解するうえで重要です。プロセスに関する分析結果がどの時点まで最新であるかを明確にし、ごく最近の取引が含まれているかどうかについて適切な認識を持てるようにします。

重要な理由

データの新しさを明確にし、プロセス分析がどの時点まで最新であるかを把握できるようにします。

入手先

データ抽出・変換(ETL)処理の中で生成され、追加されるタイムスタンプです。

2023-10-27T02:00:00Z2023-10-28T02:00:00Z
承認コンプライアンスあり
IsApprovalCompliant
仕入先に送付する前に発注書が承認されたかどうかを示すフラグです。
説明

発注書は仕入先に送付する前に承認されていなければならないという、社内統制への準拠を確認する計算されたブール型属性です。「Purchase Order Approved」アクティビティが「Purchase Order Sent to Vendor」アクティビティより前に発生した場合にtrueとなります。

「発注書プロセスコンプライアンス監査」ダッシュボードと「発注書承認コンプライアンス率」KPIに欠かせません。コンプライアンス違反を簡単に特定・定量化し、調達ポリシーの徹底と無許可支出に伴うリスクの低減に役立ちます。

重要な理由

「発注書承認コンプライアンス率」KPIを直接測定し、承認前に仕入先へ送付された発注書という重要な内部統制違反を明らかにします。

入手先

計算フィールドです。「Purchase Order Approved」のタイムスタンプが「Purchase Order Sent to Vendor」のタイムスタンプ以下の場合は「true」に設定されます。

truefalse
発注書ステータス
PurchaseOrderStatus
発注書ドキュメントの現在のステータスです。
説明

この属性は、発注書のライフサイクルにおける現在の状態を示します。「Open」、「Approved」、「Finally Closed」、「Canceled」などがあります。発注書の進捗状況を把握するためのスナップショットです。

プロセスマイニングではアクティビティの順序を重視しますが、現在のステータスはケースのフィルタリングに役立ちます。たとえば、未完了の発注書だけを分析して現在の処理状況を把握したり、クローズ済みの発注書を分析して完了したプロセスインスタンスを確認したりできます。「発注書フローとステータス」ダッシュボードにも欠かせません。

重要な理由

発注書の現在の状態を把握でき、処理中、完了、キャンセル済みの発注書に絞って分析できます。

入手先

Oracle Fusion Cloud SCMのPO_HEADERS_ALLテーブル、AUTHORIZATION_STATUSまたはDOCUMENT_STATUS列です。

OPENAPPROVEDFINALLY_CLOSEDCANCELED
発注書タイプ
PurchaseOrderType
発注書の種類です。「Standard」、「Blanket」、「Contract」などがあります。
説明

この属性は、調達目的に基づいて発注書を分類します。発注書の種類によって、適用されるプロセスルールやライフサイクルが異なる場合があります。

「Standard」は一回限りの購入を指し、「Blanket」は仕入先との長期契約を指します。発注書タイプ別に分析することで、プロセスパフォーマンスをより正確に把握できます。標準発注書と包括契約のサイクルタイムを比較すると、条件が異なるため誤解を招く可能性があります。同じ条件の発注書同士で比較できるようになります。

重要な理由

さまざまな調達シナリオを区別し、同種の発注書同士でプロセスパフォーマンスを正確に比較できます。

入手先

Oracle Fusion Cloud SCMのテーブルPO_HEADERS_ALL、列TYPE_LOOKUP_CODEです。

STANDARDBLANKETCONTRACT
納入場所
DeliveryLocation
商品を納入する物理的な場所または住所です。
説明

この属性は、発注書の明細の納入先住所を指定します。重要な物流情報です。

プロセスマイニングでは、納入場所別に分析することで、「入荷処理効率」ダッシュボードを支援できます。特定の倉庫や拠点で入荷処理に時間がかかっているかを特定し、その場所における人員またはプロセス上の問題を把握できます。

重要な理由

地理的な場所別にパフォーマンスを分析し、入荷処理における地域または拠点固有のボトルネックを特定できます。

入手先

PO_LINE_LOCATIONS_ALL.SHIP_TO_LOCATION_IDからHR_LOCATIONS_ALLビューに関連付けられます。

中央倉庫:搬入口A3号館:受付サンフランシスコオフィス:10階
納入遅延あり
IsLateDelivery
最終入荷が希望納入日より後に発生したかどうかを示すフラグです。
説明

特定の発注書について、「Goods Received」アクティビティのタイムスタンプが「希望納入日」属性の値より後の場合にtrueとなる、計算されたブール型属性です。

「納期遵守率」KPIの基盤となります。納入遅延と納期遵守を簡単に分けて分析できるため、仕入先、場所、商品カテゴリなど、遅延の根本原因を調査できます。

重要な理由

「納期遵守率」KPIを直接支援し、仕入先のパフォーマンスと納入の信頼性を明確に分析できます。

入手先

計算フィールドです。「Goods Received」アクティビティのタイムスタンプが「RequestedDeliveryDate」属性より後の場合は「true」に設定されます。

truefalse
購買カテゴリ
PurchaseCategory
購入する商品またはサービスの分類です。「ITハードウェア」や「オフィス用品」などがあります。
説明

この属性は発注書の明細を調達階層に分類します。支出分析やサプライヤー管理に利用されます。

プロセスマイニングで購買カテゴリ別にプロセスを分けて分析すると、行動やパフォーマンスの違いを明らかにできます。たとえば、設備投資の承認プロセスは、業務用品の承認より長くなる場合があります。また、「返品率と返品理由」ダッシュボードで、どのカテゴリの商品が返品されやすいかを分析できます。

重要な理由

支出の種類別にプロセスを分析し、商品カテゴリごとのプロセス経路、ボトルネック、返品率の違いを明らかにできます。

入手先

PO_LINES_ALL.CATEGORY_IDからEGP_CATEGORIES_VLビューに関連付けられます。

IT.Hardware.LaptopsOffice.Supplies.StationeryProfessional.Services.Consulting
購買依頼
PurchaseRequisitionNumber
発注書に先行し、その作成を承認した購買依頼の識別子です。
説明

購買依頼は、商品またはサービスの調達を社内で申請するための文書です。この属性により、発注書を起点となった申請に関連付けられます。

依頼番号を含めることで、発注書だけでなく、最初の申請から始まる調達プロセス全体を分析できます。申請から発注までのサイクルタイムや、購買依頼の内容が後続の発注プロセスに与える影響を分析する際に役立ちます。

重要な理由

発注書を最初の申請に関連付け、購買依頼から支払いまでのプロセスをエンドツーエンドで把握できます。

入手先

PO_DISTRIBUTIONS_ALLテーブルのREQ_DISTRIBUTION_IDを介して関連付けられ、POR_REQUISITION_LINES_ALLテーブルまで追跡できます。

PR-2023-05-001PR-2023-05-002PR-2023-05-003
必須 推奨 任意

調達から支払いまで:発注書のアクティビティ

調達から支払いまで:発注書プロセスを正確に発見するため、イベントログに記録する主要なプロセス手順とマイルストーンです。
6 推奨 10 任意
アクティビティ 説明
商品を受領
商品が実際に受領され、数量を確認したうえで発注書に対して記録されました。これは在庫と発注書のステータスを更新する取引イベントです。
重要な理由

これは、サプライヤーの納期遵守率と全体のリードタイムを測定する重要なマイルストーンです。また、品質検査や請求書照合など、後続アクティビティの開始点にもなります。

入手先

これはRCV_TRANSACTIONSテーブルに記録される明示的なイベントです。TRANSACTION_TYPEが「RECEIVE」の取引として特定できます。

取得

TRANSACTION_TYPEが「RECEIVE」のRCV_TRANSACTIONSからTRANSACTION_DATEを使用します。

イベントタイプ explicit
発注書をキャンセル
発注書が完全にキャンセルされ、以降の取引が予定されていない状態です。これはドキュメントの最終ステータスを変更する明示的なアクションです。
重要な理由

このアクティビティは、プロセスにおける望ましくない終了状態を示します。キャンセルを分析することで、重複発注、予算変更、プロジェクト要件の変更などの問題を明らかにできます。

入手先

このアクションは、ACTION_CODEが「CANCEL」のレコードとしてPO_ACTION_HISTORYテーブルに記録され、PO_HEADERS_ALLの発注書ステータスも更新されます。

取得

ACTION_CODEが「CANCEL」のレコードをPO_ACTION_HISTORYから抽出します。

イベントタイプ explicit
発注書をサプライヤーへ送付
承認済みの発注書が、メールやEDIなどでサプライヤーに正式に通知されます。このイベントは、ステータスの変更または発注書の通信記録にあるタイムスタンプから推定されることが一般的です。
重要な理由

ここからサプライヤーのリードタイムが始まります。受領確認から最終納入までのサプライヤーのパフォーマンスを測定するうえで重要な時点です。

入手先

発注書ドキュメントのステータスが「Open」に変更され、通信日が入力されたことから推定できます。該当する項目は、PO_HEADERS_ALL.communicated_dateまたは関連するステータス項目であることが一般的です。

取得

発注書の通信ステータスが「Communicated」に更新された時点のタイムスタンプから推定します。

イベントタイプ inferred
発注書を作成
これは発注書のライフサイクルが正式に始まる時点です。発注書ドキュメントが下書きまたは未完了のステータスで生成され、新しい発注書ヘッダーレコードの作成タイムスタンプが記録されます。
重要な理由

発注書ケースの開始イベントとなるこのアクティビティは、すべてのサイクルタイム計算の基準になります。承認やサプライヤーとの連絡など、後続ステップの効率を測定する起点にもなります。

入手先

これは、対象の発注書ID(PO_HEADER_ID)について、PO_HEADERS_ALLテーブルのCREATION_DATE項目に基づく明示的なイベントです。

取得

PO_HEADERS_ALLテーブルの作成タイムスタンプを使用します。

イベントタイプ explicit
発注書を最終クローズ
発注書が完了した状態です。商品がすべて入荷し、請求処理も完了している、またはその両方が完了しており、今後のアクティビティが予定されていません。これは発注書を最終ステータスに設定する明示的なアクションです。
重要な理由

このアクティビティは、発注書のライフサイクルが正常に完了したことを示します。主要な正常終了状態であり、プロセス全体の処理量と完了率を測定するうえで追跡が欠かせません。

入手先

このイベントは、ACTION_CODEが「FINALLY CLOSE」のレコードとしてPO_ACTION_HISTORYテーブルに記録されます。PO_HEADERS_ALLの発注書ステータスも「Finally Closed」に更新されます。

取得

ACTION_CODEが「FINALLY CLOSE」のレコードをPO_ACTION_HISTORYから抽出します。

イベントタイプ 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」の取引として特定できます。

取得

TRANSACTION_TYPEが「ACCEPT」または「REJECT」のRCV_TRANSACTIONSからTRANSACTION_DATEを使用します。

イベントタイプ explicit
商品をサプライヤーへ返品
受領済みの商品を、欠陥、破損、誤出荷などの理由でサプライヤーへ返送します。これは入荷モジュールの返品取引として記録されます。
重要な理由

返品を追跡することは、サプライヤーの品質と発注内容の正確性を評価するうえで欠かせません。特定のサプライヤーで返品率が高い場合、対処が必要な構造的な問題がある可能性があります。

入手先

これは、TRANSACTION_TYPEが「RETURN TO VENDOR」の取引としてRCV_TRANSACTIONSテーブルに記録される明示的なイベントです。

取得

TRANSACTION_TYPEが「RETURN TO VENDOR」のRCV_TRANSACTIONSからTRANSACTION_DATEを使用します。

イベントタイプ explicit
発注書の受領を確認
サプライヤーが発注書を受領し、発注条件を受け入れたことを確認しました。このイベントは、サプライヤーとの連絡に基づいて調達担当者が手動で記録するか、電子的な受領確認によって取得することが一般的です。
重要な理由

サプライヤーからの受領確認により、発注書が届き、処理されていることを確実に把握できます。これを追跡することで、サプライヤーとの連絡を管理し、履行上の問題を早期に特定できます。

入手先

通常は、発注書ヘッダーまたは明細の受領確認ステータス項目の変更から推定します。たとえば、PO_HEADERS_ALL.acceptance_statusが「Accepted」に変更された場合です。

取得

発注書の受領確認ステータス項目の更新から推定します。

イベントタイプ inferred
発注書を却下
承認者が発注書を却下し、作成者に修正のため差し戻しました。これはアクション履歴に記録される明示的なイベントであり、標準的なプロセスフローが中断されたことを示します。
重要な理由

却下が発生すると、プロセスに手戻りと遅延が生じます。このアクティビティを追跡することで、却下の主な理由、トレーニングの必要性、承認要件の不明確さを特定できます。

入手先

このアクションは、該当するPO_HEADER_IDについて、ACTION_CODEが「REJECT」のレコードとしてPO_ACTION_HISTORYテーブルに記録されます。

取得

ACTION_CODEが「REJECT」のレコードをPO_ACTION_HISTORYから抽出します。

イベントタイプ explicit
発注書を変更
初回承認後に、数量、価格、納期などの発注内容が変更されました。Oracle Fusionでは、ドキュメントの新しい改訂版を作成することでこの変更を追跡します。
重要な理由

発注書の変更は手戻りを示し、初回発注の正確性に問題があったことや、ビジネス要件が変化したことを示す場合があります。変更の頻度と内容を分析することで、プロセス効率を改善する機会を特定できます。

入手先

このイベントは、新しいドキュメント改訂版が作成された時点で明示的に取得されます。PO_HEADERS_ALLテーブルのREVISION_NUM項目の増加から特定できます。

取得

PO_HEADER_IDごとにREVISION_NUMが増加した各時点を特定します。

イベントタイプ explicit
発注書を申請
作成された発注書が承認ワークフローに申請されます。Oracle Fusionにはこのアクションが明示的に記録され、申請を行ったユーザーとタイムスタンプが保存されます。
重要な理由

このアクティビティは承認サイクルの開始を示します。申請から承認までの時間を分析することは、社内承認プロセスのボトルネックを特定するうえで重要です。

入手先

このアクションは、該当するPO_HEADER_IDについて、ACTION_CODEが「SUBMIT」のレコードとしてPO_ACTION_HISTORYテーブルに記録されます。

取得

ACTION_CODEが「SUBMIT」のレコードをPO_ACTION_HISTORYから抽出します。

イベントタイプ explicit
購買依頼を作成
このアクティビティは、発注書に先立つ商品の購入またはサービス提供を正式に依頼する購買依頼の作成を示します。Oracle Fusionの購買依頼ヘッダーテーブルに新しいレコードが作成された時点で記録されます。
重要な理由

このアクティビティを分析すると、需要が発生する段階を把握できます。購買依頼の作成から発注書の作成までの時間を追跡することで、社内需要を実行可能な調達依頼へ変換する際の遅延を明らかにできます。

入手先

これは、新しい購買依頼を保存した時点で記録される明示的なイベントです。POR_REQUISITION_HEADERS_ALLテーブルの作成タイムスタンプを追跡することで特定できます。

取得

このイベントは、POR_REQUISITION_HEADERS_ALLテーブルのレコード作成日に基づきます。

イベントタイプ explicit
購買依頼を承認
購買依頼が指定された承認者によって承認され、調達部門が発注書を作成できる状態になりました。このイベントは、購買依頼のアクション履歴に明示的に記録されます。
重要な理由

このマイルストーンは、依頼に対する社内承認プロセスの完了を示します。ここでの遅延は調達全体のスケジュールに直接影響するため、所要時間の監視が欠かせません。

入手先

このイベントは購買依頼に関連付けられたアクション履歴に記録されます。通常は、ワークフローテーブルまたは購買依頼ドキュメントの承認ステータス項目で追跡します。

取得

該当する購買依頼ドキュメントのワークフロー履歴に、承認アクションとして記録されます。

イベントタイプ explicit
推奨 任意

抽出ガイド

Oracle Fusion Financialsからデータを取得する方法

準備はできましたか?

このテンプレートを使ってデータ収集を効率化し、調達から支払いまでの発注書プロセスに関する具体的な改善案を見つけ出してください。今すぐ業務の最適化を始めましょう。

今日から調達から支払いまでの発注書プロセスを最適化

コストにつながるボトルネックを特定し、サイクルタイムを簡単に30%短縮できます。

無料トライアルを開始

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