データテンプレート: 購買から支払いまで - 購買オーダー
購買から支払いまでの発注書データテンプレート
- 包括的なデータ収集のための推奨属性
- 追跡・分析すべき主要なプロセスアクティビティ
- Oracle Fusion Financials向けのステップバイステップ抽出ガイド
購買から支払いまで - 発注書属性
| 名前 | 説明 | ||
|---|---|---|---|
|
アクティビティ
ActivityName
|
購買オーダーライフサイクル内で発生した特定のビジネスイベントまたはステップの名称。 | ||
|
説明
この属性は、'発注書作成済み' や '商品受領済み' など、プロセスにおける特定のタスクやステータス変更を記述します。これらのアクティビティが、プロセスフローを構成するイベントのシーケンスを形成します。 これらのアクティビティのシーケンスとタイミングを分析することが、プロセスマイニングの核心です。これにより、プロセスマップの視覚化、ボトルネックの特定、標準手順からの逸脱の発見、および特定のステップの期間測定が可能になります。
その重要性
アクティビティはプロセスマップの構成要素です。これらを追跡することで、プロセスフロー、ボトルネック、および逸脱を可視化・分析することができます。
取得元
PO_HEADERS_ALLやPO_ACTION_HISTORYのようなテーブルのステータス変更から、または物品受領のためのRCV_TRANSACTIONSのような特定のトランザクションテーブルから派生しています。
例
発注書作成発注書承認済み物品受領済み
|
|||
|
購買発注
PurchaseOrder
|
購買オーダー文書の一意の識別子であり、調達ライフサイクルを追跡するための主要なケースIDとして機能します。 | ||
|
説明
購買オーダー番号は、その作成から最終的なクローズまで、関連するすべてのアクティビティをリンクする中心的な識別子です。これにより、個々の調達ケースのエンドツーエンド分析が可能になります。 プロセスマイニングでは、各一意の購買オーダー番号がプロセスの単一インスタンスを表します。この識別子でグループ化されたデータを分析することで、個々のオーダーにおけるプロセスのバリエーション、サイクルタイム、およびコンプライアンスを理解するのに役立ちます。
その重要性
これは、関連するすべてのeventをつなぎ、Purchase Orderのライフサイクル全体を再構築・分析するための不可欠なCase IDです。
取得元
Oracle Fusion Cloud SCM、調達モジュール、テーブルPO_HEADERS_ALL、カラムSEGMENT1。
例
100234510023461002347
|
|||
|
開始時刻
EventTime
|
特定のアクティビティまたはイベントが発生した時刻を示すタイムスタンプ。 | ||
|
説明
この属性は、プロセスの各アクティビティの正確な日時を記録します。これはイベントの時系列順並べ替えと、すべての時間ベースの分析にとって不可欠です。 プロセスマイニングでは、開始時間はイベントログの構築、アクティビティ間のサイクルタイムの計算、待機時間の測定、および異なる期間にわたるプロセスパフォーマンスの分析に使用されます。これは、サイクルタイムとパフォーマンスに関連するダッシュボードにとって不可欠です。
その重要性
このtimestampは、eventを正しく順序付けし、cycle timeやbottleneckなどのすべての期間ベースのメトリクスを計算するために不可欠です。
取得元
PO_HEADERS_ALL、PO_ACTION_HISTORY、RCV_SHIPMENT_LINESを含むさまざまなテーブルからのCREATION_DATEやLAST_UPDATE_DATEなどのtimestamp field。
例
2023-04-15T10:05:00Z2023-04-16T14:30:00Z2023-05-01T09:00:00Z
|
|||
|
ユーザー
UserName
|
そのアクティビティを実行した担当者のユーザーIDまたは氏名を示します。 | ||
|
説明
この属性は、依頼の作成、POの承認、商品受領の転記など、特定のイベントを担当する従業員またはシステムユーザーを識別します。これは通常、'作成者' や '最終更新者' といったフィールドから取得されます。 ユーザー別にプロセスを分析することは、ワークロードの配分、個人のパフォーマンス、およびトレーニングのニーズを理解する上で役立ちます。'Approval Resource Workload' ダッシュボードにとって不可欠であり、ユーザーアクションに関連するコンプライアンス問題の調査においても重要です。
その重要性
ユーザーのアクションを特定の個人に紐づけ、ワークロード分析、パフォーマンス評価、トレーニング機会の特定を可能にします。
取得元
PO_HEADERS_ALLやPO_ACTION_HISTORYなどのテーブルにあるCREATED_BYやLAST_UPDATED_BYといったフィールドのIDに基づいて、ユーザーテーブルと結合します。
例
john.doejane.smithsystem.batch
|
|||
|
仕入先名
VendorName
|
物品またはサービスが購買される仕入先またはベンダーの名称。 | ||
|
説明
この属性は、発注書の外部サプライヤーを識別します。これは、PO ヘッダーにリンクされた重要なマスターデータの一部です。 ベンダー分析は、購買から支払いまでのプロセスマイニングの重要な部分です。ベンダー別にフィルタリングまたはセグメント化することで、企業は'Vendor Delivery Performance' を分析し、納期遵守率を比較し、'Goods Return Rate' を調査して、高または低パフォーマンスのサプライヤーを特定できます。このデータは、サプライヤー関係の管理と戦略的調達にとって不可欠です。
その重要性
サプライヤーパフォーマンス分析に不可欠であり、ベンダー間での納期、返品率、全体的な信頼性を比較できるようにします。
取得元
PO_HEADERS_ALL.VENDOR_IDからPOZ_SUPPLIERS.VENDOR_NAMEにリンクされています。
例
グローバル事務用品テックソリューションズ株式会社Advanced Logistics Co.
|
|||
|
希望納期
RequestedDeliveryDate
|
申請元が物品またはサービスの納品を期待する期日。 | ||
|
説明
この日付は購買オーダー明細に指定され、ベンダーに希望する納期を伝達します。これは、納期遵守パフォーマンスを測定するためのベースラインとなります。 この属性は、「納期遵守率」KPIを計算する上で不可欠です。実際の物品受領日と要求納期を比較することで、組織はベンダーの信頼性を定量的に測定・追跡し、サプライチェーンにおける体系的な遅延を特定できます。
その重要性
納期遵守パフォーマンスを測定するためのベースラインとして機能し、仕入先の信頼性やサプライチェーンの効率性を評価するための主要なKPIとなります。
取得元
明細ロケーションレベル、テーブルPO_LINE_LOCATIONS_ALLのNEED_BY_DATEカラムにあります。
例
2023-05-202023-06-152023-07-01
|
|||
|
承認者名
ApproverName
|
購買オーダーに対して承認または却下アクションを実行したユーザーの名称。 | ||
|
説明
この属性は、ワークフローにおける承認ステップの担当者を記録します。この情報は通常、発注書に関連するアクション履歴やワークフローログテーブルに保存されます。 承認者別にデータを分析することは、'PO Approval Cycle Time Analysis' および 'Approval Resource Workload' ダッシュボードにとって非常に重要です。これにより、どの承認者や承認グループがボトルネックになっているかを特定し、ワークロードを公正に評価し、委任やプロセス再設計の機会を明確にできます。
その重要性
承認チェーン内の個人を特定し、承認ボトルネック、ワークロード、および承認者ごとのサイクルタイムを分析することを可能にします。
取得元
アクションを実行したユーザー。PO_ACTION_HISTORY.ACTION_PERFORMED_BYにあり、ユーザーテーブルにリンクされてフルネームが取得されます。
例
susan.managerdavid.directoremily.finance
|
|||
|
発注書合計金額
PurchaseOrderTotalAmount
|
購買オーダーの総金額。 | ||
|
説明
この属性は、指定された通貨における発注書上の全品目の合計コストを表します。これは、プロセスを通じて流れるトランザクションの価値を理解するための重要な財務指標です。 POの合計金額を分析することは、プロセス改善の取り組みを優先するのに役立ちます。例えば、高額な注文は、より厳格な承認プロセスを経る場合があります。また、頻繁に変更されたり遅延したりするPOの価値を計算するなど、財務上の影響分析も可能にします。
その重要性
プロセスに財務的な文脈を提供し、高額な注文に焦点を当てたり、遅延の財務的影響を理解したりするなど、金銭的価値に基づく分析を可能にします。
取得元
特定のPOヘッダーに対するPO_LINES_ALLからの金額を合計するか、ヘッダーレベルの合計がある場合はそこから取得して計算されます。
例
5250.00120000.50750.99
|
|||
|
終了日時
EndTime
|
アクティビティが完了したタイムスタンプ。アトミックイベントでは開始時刻と同じである場合が多いです。 | ||
|
説明
期間を持つアクティビティの場合、これは完了時刻を示します。瞬間的なイベントの場合、通常は開始時刻と同じです。個々のアクティビティの処理時間を計算するために不可欠です。 明確な終了時刻を持つことで、アクティビティ間の待機時間とは異なるアクティビティ期間のより正確な分析が可能になります。これにより、実作業時間とアイドル時間を区別し、リソースのワークロードと効率分析をサポートします。
その重要性
正確なアクティビティ処理時間の算出を可能にし、リソース効率の分析や時間のかかるタスクの特定に不可欠です。
取得元
アトミックイベントの開始時間と同じタイムスタンプであるか、後続のイベントタイムスタンプから導出されます。一部のアクティビティには、別途完了タイムスタンプが存在する場合があります。
例
2023-04-15T10:05:00Z2023-04-16T14:45:00Z2023-05-01T09:15:00Z
|
|||
|
部署
DepartmentName
|
購買オーダーを開始した、または責任を負う部門の名称。 | ||
|
説明
この属性は、購買に関連する'Finance' (経理部)、'IT' (情報システム部)、'Manufacturing' (製造部) などの組織単位を指定します。これはコスト配分と組織レポート作成に使用されます。 プロセスマイニングの文脈では、部門別にプロセスをセグメント化することは、パフォーマンスの比較、部門固有のボトルネックの特定、および組織全体のプロセス実行における変動の理解にとって不可欠です。これは、'PO Approval Cycle Time Analysis' や 'Purchase Order Modification Trends' などのダッシュボードを直接サポートします。
その重要性
異なる事業部門間でプロセスパフォーマンスをフィルタリング・比較し、部門固有の問題やベストプラクティスを明らかにできます。
取得元
PO_DISTRIBUTIONS_ALLのようなテーブルのコストセンター情報から派生し、部門マスターデータにリンクしています。
例
IT運用マーケティング研究開発
|
|||
|
Is Approval Compliant
IsApprovalCompliant
|
購買オーダーがベンダーに送付される前に承認されたかどうかを示すフラグです。 | ||
|
説明
これは、主要な内部統制への順守を確認する計算ブール属性です。購買オーダーはサプライヤーに発送される前に承認されなければなりません。「購買オーダー承認済み」アクティビティが「購買オーダーをベンダーに送信」アクティビティの前に発生した場合にtrueとなるものです。 この属性は、「POプロセスコンプライアンス監査」ダッシュボードと「PO承認コンプライアンス率」KPIにとって不可欠です。コンプライアンス違反を特定し定量化するための直接的な方法を提供し、調達ポリシーの施行と不正支出に関連するリスクの軽減に役立ちます。
その重要性
PO Approval Compliance Rate KPI を直接測定し、承認前に注文がベンダーに送られるという重要な内部統制違反を特定します。
取得元
計算フィールド。「購買発注承認済み」のタイムスタンプが「購買発注サプライヤーへ送付済み」のタイムスタンプ以下の場合「true」に設定されます。
例
truefalse
|
|||
|
Is Late Delivery
IsLateDelivery
|
最終的な物品受領が要求された納期よりも後に発生したかどうかを示すフラグです。 | ||
|
説明
この計算ブール属性は、特定の購買オーダーにおいて、「物品受領」アクティビティのタイムスタンプが「要求納期」属性の値よりも遅い場合にtrueとなるものです。 このフラグは、「納期遵守率」KPIの基礎となります。これにより、納期遅延オーダーと納期内オーダーの分類と分析が容易になり、特定のベンダー、場所、製品カテゴリに関わらず、遅延の根本原因を特定するのに役立ちます。
その重要性
On-Time Delivery Rate KPI を直接サポートし、ベンダーパフォーマンスと納期遵守度を明確に分析できるようにします。
取得元
計算フィールド。「物品受領済み」アクティビティのタイムスタンプが「要求配達日」属性よりも後の場合「true」に設定されます。
例
truefalse
|
|||
|
POタイプ
PurchaseOrderType
|
購買オーダーのタイプ(例:「標準」、「包括契約」、または「契約」など)。 | ||
|
説明
この属性は、発注書をその調達目的に基づいて分類します。異なる種類のPOは、多くの場合、異なるプロセスルールとライフサイクルに従います。 'Standard' POは一回限りの購買であり、'Blanket' POはサプライヤーとのより長期的な合意です。PO タイプ別にプロセスを分析することで、より正確なプロセスパフォーマンスを把握できるようになります。標準POのサイクルタイムを包括的な契約と比較することは誤解を招くためです。これにより、同種のプロセス間での比較が可能になります。
その重要性
さまざまな調達シナリオを区別し、同種の注文におけるプロセスパフォーマンスをより正確かつ公平に比較できるようにします。
取得元
Oracle Fusion Cloud SCM、テーブルPO_HEADERS_ALL、カラムTYPE_LOOKUP_CODE。
例
標準BLANKETCONTRACT
|
|||
|
ソースシステム
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
|
|||
|
最終データ更新
LastDataUpdate
|
データがソースシステムから最後に抽出または更新されたタイムスタンプ。 | ||
|
説明
この属性は、分析対象データの鮮度を示します。Oracle Fusion Financialsから最新のデータが取得された日時を記録するものです。 この情報は、ユーザーが分析およびダッシュボードのタイムリーさを理解する上で不可欠です。プロセスインサイトがどの程度最新であるかを明確にし、非常に新しいトランザクションの反映に関する期待値を適切に管理するのに役立ちます。
その重要性
データの鮮度に関する透明性を提供し、ユーザーがプロセス分析の最新性を理解できるようにします。
取得元
これは、データの抽出および変換 (ETL) プロセス中に生成され追加されるタイムスタンプです。
例
2023-10-27T02:00:00Z2023-10-28T02:00:00Z
|
|||
|
手戻り
IsRework
|
購買オーダーが初回作成後に修正されたかどうかを示すフラグです。 | ||
|
説明
これは、「購買オーダー変更済み」アクティビティを購買オーダーのケースが含む場合にtrueとなる計算ブール属性です。これにより、修正または変更が必要なオーダーを迅速に特定するのに役立ちます。 このフラグは、「PO変更率」KPIの計算を簡素化し、手戻りしたオーダーのフィルタリングと分析を容易にします。手戻りしたオーダーの特性(関与したベンダーや部門など)を理解することは、データ不正確性や要件変更の根本原因を特定するのに役立ちます。
その重要性
PO Modification Rate KPI を直接サポートし、変更があったすべての注文を特定することで、プロセスの不安定さの分析を簡素化します。
取得元
計算フィールド。ケースのイベントログに「購買発注変更」アクティビティが含まれている場合「true」に設定され、そうでない場合は「false」に設定されます。
例
truefalse
|
|||
|
承認サイクルタイム
ApprovalCycleTime
|
購買オーダーが作成されてから、最終的に承認されるまでの期間。 | ||
|
説明
これは、単一のケースにおける「購買オーダー作成済み」アクティビティと「購買オーダー承認済み」アクティビティの間で経過した時間を測定する計算期間メトリクスです。 この属性は、「平均PO承認サイクルタイム」KPIの値を直接提供します。その分布を分析することは、承認ワークフローの効率を理解し、外れ値を特定し、承認遅延を削減することを目的としたプロセス改善イニシアティブの影響を測定するのに役立ちます。
その重要性
承認のボトルネックを数値化し、「平均PO承認サイクルタイム」KPIを直接測定してワークフローの遅延を明確にします。
取得元
計算フィールド。「購買発注承認済み」アクティビティと「購買発注作成済み」アクティビティのタイムスタンプ間の差。
例
P2DPT8H30MP5DT12H
|
|||
|
発注書ステータス
PurchaseOrderStatus
|
購買オーダー文書の現在のステータス。 | ||
|
説明
この属性は、'Open'、'Approved'、'Finally Closed'、'Canceled' など、発注書のライフサイクルにおける現在の状態を示します。これはPOの進捗状況を把握するためのスナップショットとして機能します。 プロセスマイニングはアクティビティのシーケンスに焦点を当てますが、現在のステータスはケースのフィルタリングに役立ちます。例えば、現在のパイプラインを理解するためにオープンなPOのみに分析を集中させたり、完了したプロセスインスタンスを分析するためにクローズされたPOに集中させたりすることが可能です。これは、'Purchase Order Flow & Status' ダッシュボードにとって不可欠です。
その重要性
発注書の現在の状態のスナップショットを提供し、分析をアクティブ、完了、またはキャンセルされた注文に絞り込むことができます。
取得元
Oracle Fusion Cloud SCM、テーブルPO_HEADERS_ALL、カラムAUTHORIZATION_STATUSまたはDOCUMENT_STATUS。
例
オープンAPPROVEDFINALLY_CLOSEDCANCELED
|
|||
|
購買カテゴリ
PurchaseCategory
|
購買される物品またはサービスの分類(例:「ITハードウェア」や「オフィス用品」など)。 | ||
|
説明
この属性は、発注書の品目を調達階層に分類します。この分類は、支出分析やサプライヤー管理に使用されます。 プロセスマイニングでは、購買カテゴリ別にプロセスをセグメント化することで、異なる挙動やパフォーマンスレベルを明らかにできます。例えば、設備投資の承認プロセスは、事業用品の場合よりも長くなることがあります。これにより、どのカテゴリが最も頻繁に返品されるかを分析できるようになり、'Goods Return Rate & Reasons' ダッシュボードを直接サポートします。
その重要性
支出の種類に応じたプロセス分析を可能にし、異なる商品カテゴリにおけるプロセス経路、ボトルネック、または返品率の違いを明らかにします。
取得元
PO_LINES_ALL.CATEGORY_IDからEGP_CATEGORIES_VLビューにリンクされています。
例
IT.Hardware.Laptops事務用品.文具専門サービス.コンサルティング
|
|||
|
購買依頼書
PurchaseRequisitionNumber
|
購買オーダーに先行し、これを承認した購買要求の識別子。 | ||
|
説明
購買要求は、物品またはサービスの調達を要求するために使用される内部文書です。この属性は、購買オーダーをその起原となる要求にリンクします。 要求番号を含めることで、購買オーダーだけでなく、最初の要求から始まる調達プロセスのより広範な分析が可能になります。これにより、要求からオーダーまでのサイクルタイムを分析し、要求詳細が下流の購買オーダープロセスにどのように影響するかを理解するのに役立ちます。
その重要性
発注書(PO)を最初の要求にリンクさせることで、申請から支払いまでの包括的なエンドツーエンドのプロセスを可視化します。
取得元
REQ_DISTRIBUTION_IDを含むPO_DISTRIBUTIONS_ALLテーブルを介し、POR_REQUISITION_LINES_ALLテーブルまで遡ってリンクされています。
例
PR-2023-05-001PR-2023-05-002PR-2023-05-003
|
|||
|
配送場所
DeliveryLocation
|
物品が納品される物理的な場所または住所。 | ||
|
説明
この属性は、発注書上の品目の出荷先住所を指定します。これは物流情報の重要な一部です。 プロセスマイニングの場合、配送先場所別に分析することで、'Goods Receipt Processing Efficiency' ダッシュボードの利用をサポートします。これにより、特定の倉庫やサイトでの受領プロセスが遅いかどうかを特定し、その場所における潜在的なリソースやプロセス上の問題を示唆するのに役立ちます。
その重要性
地理的な場所ごとのパフォーマンス分析を可能にし、物品受領プロセスにおける地域固有または拠点固有のボトルネックの特定に役立ちます。
取得元
PO_LINE_LOCATIONS_ALL.SHIP_TO_LOCATION_IDからHR_LOCATIONS_ALLビューにリンクされています。
例
本社倉庫 - ドックAビル3 - 受付SFオフィス - 10階
|
|||
購買から支払いまで - 発注書活動
| アクティビティ | 説明 | ||
|---|---|---|---|
|
ベンダーへ発注書送付済み
|
承認された購買オーダーは、例えばメールやEDIを介して仕入先に正式に伝達されます。このイベントは、ステータス変更や購買オーダー伝達記録のタイムスタンプから推測されることがよくあります。 | ||
|
その重要性
これはベンダーのリードタイムの開始を示します。承認から最終納品までのサプライヤーのパフォーマンスを測定する上で、極めて重要なpointです。
取得元
これは、購買オーダー文書のステータスが「オープン」に変わり、伝達日付が入力されたことから推測できます。具体的なフィールドは、多くの場合PO_HEADERS_ALL.communicated_date、または関連するステータスです。
取得
購買発注のコミュニケーションステータスが「Communicated」に更新されたタイムスタンプから推測します。
イベントタイプ
inferred
|
|||
|
物品受領済み
|
物理的な物品が受領され、計数され、購買オーダーに対して記録されました。これは在庫と購買オーダーのステータスを更新するトランザクションイベントです。 | ||
|
その重要性
これは、ベンダーの納期遵守パフォーマンスと全体的なリードタイムを測定するための重要なマイルストーンです。また、品質検査や請求書照合などの後続アクティビティのトリガーとしても機能します。
取得元
これは、RCV_TRANSACTIONSテーブルに記録された明示的なイベントです。具体的なトランザクションは、TRANSACTION_TYPEが「RECEIVE」であることによって特定できます。
取得
TRANSACTION_TYPEが「RECEIVE」であるRCV_TRANSACTIONSからのTRANSACTION_DATEを使用します。
イベントタイプ
explicit
|
|||
|
発注書キャンセル済み
|
購買オーダーは恒久的にキャンセルされ、それ以上のトランザクションは想定されません。これは文書の最終ステータスを変更する明示的なアクションです。 | ||
|
その重要性
このアクティビティは、プロセスにおける否定的な終了状態を示します。キャンセルを分析することで、重複注文、予算変更、プロジェクト要件の変更といった問題を明らかにできます。
取得元
このアクションは、PO_ACTION_HISTORYテーブルにACTION_CODEが'CANCEL'として記録され、PO_HEADERS_ALLのPO ステータスもそれに伴い更新されます。
取得
PO_ACTION_HISTORYテーブルをACTION_CODE = 'CANCEL' でフィルタリングします。
イベントタイプ
explicit
|
|||
|
発注書作成
|
これはPurchase Orderライフサイクルの正式な開始であり、PO文書が下書きまたは未完了ステータスで作成されます。システムは、新しいPOヘッダーレコードの作成timestampを記録することで、このeventを捕捉します。 | ||
|
その重要性
POケースの主要な開始イベントとして、このアクティビティはすべてのサイクルタイム計算の基本となります。これは承認やサプライヤーとのコミュニケーションなどの後続ステップの効率を測定するためのベースラインを提供します。
取得元
これは、特定の購買オーダーID (PO_HEADER_ID) に関連するPO_HEADERS_ALLテーブルのCREATION_DATEフィールドに基づく明示的なイベントです。
取得
PO_HEADERS_ALLテーブルの作成timestampを使用します。
イベントタイプ
explicit
|
|||
|
発注書最終クローズ済み
|
購買オーダーは完了と見なされ、完全に受領および/または請求済みであり、それ以上のアクティビティは予測されません。これは購買オーダーに最終ステータスを設定する明示的なアクションです。 | ||
|
その重要性
このアクティビティは、発注書ライフサイクルの正常な完了を示します。これはプロセスにおける主要な肯定的な終了状態であり、これを追跡することは、プロセス全体のスループットと完了率を測定する上で不可欠です。
取得元
このイベントは、ACTION_CODEが「FINALLY CLOSE」であるPO_ACTION_HISTORYテーブルに記録されます。PO_HEADERS_ALLにおけるPOステータスも「Finally Closed」に更新されます。
取得
PO_ACTION_HISTORYテーブルをACTION_CODE = 'FINALLY CLOSE' でフィルタリングします。
イベントタイプ
explicit
|
|||
|
発注書承認済み
|
購買オーダーは必要なすべての承認を受け、ベンダーへの発送が許可されました。これは文書のアクション履歴に明示的にログされる主要なマイルストーンイベントです。 | ||
|
その重要性
これは、購買オーダーがベンダーに送信されるのを阻止する重要なマイルストーンです。承認サイクルタイムの測定と支出ポリシーへのコンプライアンスの確保に不可欠です。
取得元
このイベントはPO_ACTION_HISTORYテーブルに記録されます。通常、ACTION_CODEが「APPROVE」の場合、またはPO_HEADERS_ALLにおける文書ステータスが承認済みの状態に変化した場合に捕捉されます。
取得
PO_ACTION_HISTORYテーブルを最終的な「承認」アクションでフィルタリングします。
イベントタイプ
explicit
|
|||
|
サービス提供確認済み
|
サービスベースの購買発注の場合、このアクティビティは、合意されたサービスが提供されたことの確認を示します。この確認は、多くの場合、手動またはサービスエントリーシートを通じて記録されます。 | ||
|
その重要性
これはサービスにおける物品受領に相当し、請求書の支払い前に不可欠なステップです。サービス確認の遅延は、支払いの遅れやベンダーとの関係悪化を招く可能性があります。
取得元
これは通常、PO上のサービスラインに対する受領として捕捉されます。サービスの進捗や完了を追跡する特定のfieldや複雑な受領が関係する場合があります。
取得
サービスベースの購買発注明細にリンクされた入荷トランザクション (RCV_TRANSACTIONS) を特定します。
イベントタイプ
explicit
|
|||
|
ベンダーへ商品返品
|
以前に受領した商品が、通常は欠陥、損傷、または誤った出荷が原因でベンダーに返品されます。これは、受入モジュールで特定の返品トランザクションとして記録されます。 | ||
|
その重要性
返品の追跡は、サプライヤーの品質と注文の正確性を評価する上で不可欠です。特定のベンダーにおける高い返品率は、対処すべきシステム的な問題を示している可能性があります。
取得元
これは、TRANSACTION_TYPEが「RETURN TO VENDOR」であるRCV_TRANSACTIONSテーブルに記録された明示的なイベントです。
取得
TRANSACTION_TYPEが「RETURN TO VENDOR」であるRCV_TRANSACTIONSからのTRANSACTION_DATEを使用します。
イベントタイプ
explicit
|
|||
|
入荷伝票作成
|
物品の物理的な到着に備えて、システム内で受領文書が作成されます。この活動は、社内受領プロセスが開始されたことを示します。 | ||
|
その重要性
これは調達からロジスティクスへの移行を示します。このpointから最終受領計上までの時間を分析することで、倉庫や受入部門における非効率性を特定するのに役立ちます。
取得元
これは、購買オーダーにリンクされたRCV_SHIPMENT_HEADERSテーブルにおける新しいレコードの作成タイムスタンプによって捕捉される明示的なイベントです。
取得
RCV_SHIPMENT_HEADERS内の該当レコードの作成日を使用します。
イベントタイプ
explicit
|
|||
|
品質検査実行済み
|
品質管理が必要な商品は検査され、受け入れられるか拒否されます。このアクティビティは最初の受領後に発生し、個別のトランザクションとして記録されます。 | ||
|
その重要性
このアクティビティは品質管理にとって不可欠です。検査にかかる期間を分析することで、品質管理プロセスを効率化し、製品が利用可能になるまでの遅延を削減できます。
取得元
これはRCV_TRANSACTIONSテーブルに記録されます。受入トランザクションに続くTRANSACTION_TYPEが「ACCEPT」または「REJECT」のトランザクションとして識別されます。
取得
TRANSACTION_TYPEが「ACCEPT」または「REJECT」であるRCV_TRANSACTIONSからのTRANSACTION_DATEを使用します。
イベントタイプ
explicit
|
|||
|
発注書却下
|
承認者が購買発注を却下し、作成者に戻して修正を依頼しました。これはアクション履歴に明確に記録されるイベントであり、標準プロセスフローが中断されたことを示しています。 | ||
|
その重要性
却下はプロセスに手戻りや遅延をもたらします。このアクティビティを追跡することで、却下の一般的な原因、トレーニングの必要性、または不明確な承認要件を特定できます。
取得元
このアクションは、対応するPO_HEADER_IDについて、PO_ACTION_HISTORYテーブルにACTION_CODEが'REJECT'として記録されます。
取得
PO_ACTION_HISTORYテーブルをACTION_CODE = 'REJECT' でフィルタリングします。
イベントタイプ
explicit
|
|||
|
発注書変更済み
|
購買オーダーは、最初の承認後に数量、価格、納期などが変更されました。Oracle Fusionは、文書の新しいリビジョンを作成することでこの変更を追跡します。 | ||
|
その重要性
発注書(PO)の変更は手戻りを意味し、初期注文の正確性や変化するビジネスニーズに関する問題を示している可能性があります。これらの変更の頻度と性質を分析することで、プロセス効率を改善する機会を特定できます。
取得元
このイベントは、新しい文書リビジョンが作成された際に明示的に捕捉されます。これは、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
|
|||
|
発注書確認済み
|
ベンダーが発注書の条件を受領し、承諾したことを確認しました。このイベントは、ベンダーからの連絡に基づき調達担当者が手動で記録するか、電子的な確認によってシステムに捕捉されるのが一般的です。 | ||
|
その重要性
ベンダー承認は、注文が受領され処理されていることの確実性を提供します。これを追跡することで、サプライヤーとのコミュニケーションを管理し、潜在的な履行問題を事前に特定するのに役立ちます。
取得元
これは通常、POヘッダーまたはラインの承認ステータスfieldの変更、例えばPO_HEADERS_ALL.acceptance_statusが「Accepted」に変わったことから推測されます。
取得
購買発注の受領確認ステータスフィールドへの更新から推測します。
イベントタイプ
inferred
|
|||
|
購買依頼書作成
|
このアクティビティは、発注書に先行する商品またはサービスの正式な要求である購買依頼の作成を示します。これは、Oracle Fusionの依頼ヘッダーテーブルに新しいエントリが作成された際に捕捉されます。 | ||
|
その重要性
このアクティビティを分析することで、需要発生フェーズを理解するのに役立ちます。要求から購買発注作成までの時間を追跡することで、内部需要を具体的な調達オーダーに変換する際の潜在的な遅延が明らかになります。
取得元
これは、新しい購買申請書の保存時に記録される明示的なイベントです。POR_REQUISITION_HEADERS_ALLテーブルにおける作成タイムスタンプを追跡することで発見できます。
取得
イベントは、POR_REQUISITION_HEADERS_ALL テーブル内のレコード作成日に基づいています。
イベントタイプ
explicit
|
|||
|
購買依頼書承認済み
|
購買要求は指定された権限者によって承認され、調達部門に購買オーダーの作成を許可しました。このイベントは、要求のシステムアクション履歴に明示的にログされます。 | ||
|
その重要性
このマイルストーンは、依頼に対する内部承認プロセスの終了を意味します。ここでの遅延は、調達timeline全体に直接影響を与える可能性があるため、その期間の監視は極めて重要です。
取得元
このイベントは、購買申請書に関連付けられたアクション履歴に記録されます。通常、ワークフローテーブル、または購買申請書文書の特定の承認ステータスフィールドを通じて追跡されます。
取得
特定の申請文書のワークフロー履歴に承認アクションとして記録されます。
イベントタイプ
explicit
|
|||