受注から入金までの受注処理データテンプレート
受注から入金までの受注処理データテンプレート
- 収集を推奨する項目
- 追跡すべき主要アクティビティ
- 実践的なデータ抽出ガイド
受注から入金まで - 販売受注処理属性
| 名前 | 説明 | ||
|---|---|---|---|
| 受注 SalesOrder | 販売注文の一意の識別子であり、受注から入金までのプロセスの主要なケースとして機能します。 | ||
| 説明 販売注文番号は、各顧客注文をライフサイクル全体を通じて一意に識別します。これは、初期作成、確認からフルフィルメント、請求、最終支払いまで、すべての関連アクティビティを結びつける中心的な糸として機能します。 プロセスマイニングにおいて、この属性はすべての関連イベントを単一のケースとしてグループ化するために不可欠です。販売注文別にプロセスを分析することで、完全なエンドツーエンドの視点が得られ、総サイクルタイムの計算、個別の注文に対するプロセスバリアントの特定、そして異なる部門やシステムを通じた注文の経路追跡が可能になります。 その重要性 これはケースIDです。すべてのプロセスイベントをリンクし、単一の顧客注文のエンドツーエンドの経路を追跡することを可能にします。 取得元 この識別子は通常、Oracle Fusionの販売注文のヘッダーテーブル(例:DOO_HEADERS_ALL)で見つかります。Oracle Fusion Financialsのドキュメントを参照してください。 例 SO-100567SO-100568SO-100569 | |||
| アクティビティ名 ActivityName | 販売注文プロセス内で発生した特定のビジネスイベントまたはタスクの名称。 | ||
| 説明 この属性は、販売注文に対して特定の時点で実行されたステップ(「受注作成」、「商品出荷」、「入金確認」など)を表します。これら一連のアクティビティが、各ケースのプロセスフローを構成します。 ActivityNameの分析は、プロセスマイニングにおいて極めて重要です。これにより、プロセスマップの可視化や多様なプロセスバリエーションの把握、案件が滞留しているボトルネックの特定が可能になります。また、ステップ間の遷移時間の算出や、オーダー・トゥ・キャッシュ(O2C)プロセスにおける業務実態を理解するための基礎データとなります。 その重要性 この属性はプロセスマップ内のステップを定義し、プロセスフローの視覚化と分析を可能にします。 取得元 これは、様々なOracle Fusionテーブル(例:注文ステータス、出荷ステータス、請求書ステータス)のトランザクションステータスまたはイベントタイプを、標準化されたアクティビティ名のリストにマッピングすることで構築される派生属性です。 例 販売注文作成済み商品発送済み請求書作成入金確認済み | |||
| イベント日時 EventTime | 販売注文に関して特定の活動またはイベントが発生した日時を示すタイムスタンプ。 | ||
| 説明 この属性は、プロセス内の各アクティビティの日付と時間を提供し、イベントの時系列順序を確立します。これはプロセス分析の時間的な基盤であり、各ステップがいつ発生したかを正確に記録します。 プロセスマイニングにおいて、EventTimeはサイクルタイム、アクティビティ間の期間、および全体的なケースリードタイムを計算するために極めて重要です。これにより、パフォーマンス分析、待ち時間に基づくボトルネック検出、および適時性に関連するサービスレベル契約(SLA)の遵守状況の監視が可能になります。すべての時間ベースのKPIおよびダッシュボードは、この属性の精度に依存します。 その重要性 このタイムスタンプは、イベントを時系列で順序付け、サイクルタイムや期間など、すべての時間ベースの指標を計算するために不可欠です。 取得元 これは、注文作成日、出荷日、請求書日付、支払い日など、異なるOracle Fusionテーブル全体の様々なタイムスタンプフィールドから取得される派生属性です。 例 2023-04-15T09:00:00Z2023-04-18T14:30:00Z2023-04-20T11:25:00Z | |||
| `実績納期` ActualDeliveryDate | 商品が実際に顧客に配送された日付。 | ||
| 説明 この属性は最終配送日を記録し、プロセスのフルフィルメント部分の完了を示します。これは、計画されたまたは要求された日付に対して測定される実際の結果です。 この日付は、RequestedDeliveryDateと比較され、納期遵守パフォーマンスを計算します。「納期遵守率」KPIおよび「配送SLA」ダッシュボードにとって重要な入力であり、ロジスティクスとサプライチェーンの有効性を明確に測定します。 その重要性 これは、納期遵守率を計算し、顧客の要求に対するフルフィルメントパフォーマンスを評価するために使用される実際の結果日付です。 取得元 Oracle Fusionの出荷および配送トランザクションテーブルから取得されます。Oracle Fusion Financialsのドキュメントを参照してください。 例 2023-05-202023-06-032023-05-25 | |||
| ユーザー名 UserName | `アクティビティ`を実行した`ユーザー`名または`ID`。 | ||
| 説明 この属性は、特定のプロセスステップの実行を担当する従業員またはシステムユーザーを識別します。これは、ユーザーレベルのパフォーマンス、ワークロード配分、および標準手順への遵守を分析するために使用できます。 ユーザー別に分析することで、トレーニングニーズの特定、高パフォーマンスの個人やチームの認識、特定のユーザーによって引き起こされた逸脱の調査に役立ちます。また、誰がどのアクションを実行したかを追跡するため、コンプライアンスおよび監査目的でも価値があります。 その重要性 ユーザーごとのパフォーマンス、ワークロード分散、および個人に関連する手動による手戻りパターンの特定を可能にします。 取得元 通常、Oracle Fusionトランザクションテーブル内のCREATED_BYやLAST_UPDATED_BYのようなフィールドから取得され、しばしばFND_USERのようなユーザーマスターテーブルにリンクされています。 例 john.smithjane.doesystem_batch_user | |||
| 希望納期 RequestedDeliveryDate | 顧客から要求された、受注品の配送日です。 | ||
| 説明 この属性は、顧客が商品を受け取りたい日付を捕捉します。これは、受注から入金までのプロセスのフルフィルメント部分における主要なパフォーマンス目標として機能します。 この日付は、「納期遵守率」KPIを計算し、「配送サービスレベル契約(SLA)」ダッシュボードをサポートするために不可欠です。この日付をActualDeliveryDateと比較することで、組織は顧客の期待に応える能力を測定し、配送遅延の根本原因を特定できます。 その重要性 オンタイム配送パフォーマンスと顧客サービスレベル契約(SLA)遵守を測定するためのベースラインとして機能します。 取得元 通常、Oracle Fusionの販売注文明細テーブルに配置されています。Oracle Fusion Financialsのドキュメントを参照してください。 例 2023-05-202023-06-012023-05-25 | |||
| 支払期日 PaymentDueDate | 顧客が請求書の支払いを求められる日付です。 | ||
| 説明 支払期日は、請求書発行日と顧客と合意された支払条件に基づいて計算されます。これは、期日通りの支払い回収の期限を設定します。 この属性は、「期日内支払い回収率」KPIにとって極めて重要です。支払期日と実際の支払い受領日を比較することで、システムは支払いが期日通りであったか遅延であったかを判断でき、売掛金のパフォーマンスを監視し、キャッシュフローを管理するのに役立ちます。 その重要性 期日内支払い率を計算する際の期限として機能し、キャッシュフロー効率の主要な指標となります。 取得元 AR_PAYMENT_SCHEDULES_ALLなど、Oracle Fusion内の売掛金または請求書テーブルで確認できます。 例 2023-06-192023-07-012023-06-25 | |||
| 自動化 IsAutomated | `アクティビティ`がシステムによって自動的に実行されたか、またはユーザーによって手動で実行されたかを示すフラグ。 | ||
| 説明 このブール属性は、システム駆動型イベント(例:自動信用審査、システム生成請求書)と手動ユーザーアクションを区別します。通常、アクティビティに関連付けられたユーザー名に基づいて導出され、汎用システムIDが自動化を示します。 この属性を分析することは、プロセスにおける自動化レベルを測定するのに役立ち、「手動手戻り注文割合」KPIの直接的な入力となります。どの手動ステップが最も時間消費的であるか、またはエラー発生しやすいかを示すことで、さらなる自動化の機会を強調できます。 その重要性 プロセスの自動化レベルを定量化し、コストのかかる手動介入を削減する機会を特定するのに役立ちます。 取得元 これは派生フィールドであり、しばしばUserName属性に適用されるルールに基づきます。例えば、ユーザーが「SYSTEM」または「BATCH」の場合、このフラグはtrueに設定されます。 例 truefalse | |||
| 販売`チャネル` SalesChannel | 販売注文が受領されたチャネル。 | ||
| 説明 この属性は、販売注文の起源(例:「Web」、「Direct Sales(直接販売)」、「Partner(パートナー)」、「EDI」など)を分類します。注文が組織にどのように入力されたかについてのコンテキストを提供します。 販売チャネル別にプロセスをセグメント化することは、「販売チャネルパフォーマンス概要」ダッシュボードにとって極めて重要です。これにより、異なるチャネルの効率性、サイクルタイム、エラー率を比較し、最も効果的なチャネルや、プロセス改善またはさらなる自動化が必要なチャネルを特定するのに役立ちます。 その重要性 チャネル別のパフォーマンス分析をサポートし、注文処理において最も効率的および最も非効率的なチャネルを特定するのに役立ちます。 取得元 この情報は、販売注文ヘッダーの専用フィールドに格納されている場合があります。Oracle Fusion Financialsのドキュメントを参照してください。 例 直販WebポータルEDIリセラー | |||
| 販売注文合計金額 SalesOrderTotalAmount | 販売受注の総金額です。 | ||
| 説明 この属性は、販売注文全体に関して顧客に請求される合計金額を表します。これには、割引適用前のすべての明細項目、税金、およびその他の費用の合計が含まれます。 プロセス分析において、この属性は価値ベースのプロセスマイニングにとって極めて重要です。これにより、価値別に注文をセグメント化(例:高価値注文対低価値注文)し、異なるプロセスパスをたどるか、異なるサイクルタイムを持つかを確認できます。また、財務的に最も重要なケースにプロセス改善の取り組みを優先順位付けするのにも役立ちます。 その重要性 財務影響分析を可能にし、高価値注文のプロセス改善を優先し、コストドライバーを理解するのに役立ちます。 取得元 通常、Oracle Fusionの販売注文ヘッダーテーブルで見つかります。Oracle Fusion Financialsのドキュメントを参照してください。 例 5250.00125000.75980.50 | |||
| 顧客名 CustomerName | 受注を発注した顧客の名前です。 | ||
| 説明 この属性は、販売注文に関連付けられた顧客アカウントの法人名を識別します。これは、顧客中心の視点からプロセスをセグメント化し、分析するための主要なディメンションです。 顧客別に分析することで、特定の顧客がより長いサイクルタイム、より多くの手戻り、または特定のプロセス逸脱を経験しているかどうかを特定するのに役立ちます。この洞察は、顧客サービスの改善、主要アカウント向けのプロセス調整、および顧客満足度に影響する問題の調査に利用できます。 その重要性 特定の顧客に影響を与えるプロセス上の問題を特定し、顧客満足度を向上させるための顧客中心の分析を可能にします。 取得元 顧客マスターデータテーブル(例:HZ_PARTIES)から取得され、顧客IDを介して販売注文にリンクされます。 例 Global Corp Inc.Innovate Solutions Ltd.Tech Services LLC | |||
| ソースシステム SourceSystemIdentifier | イベントデータが抽出されたソースシステムを特定します。 | ||
| 説明 この属性はデータの発生源を特定します。これは、受注から入金までのプロセスに複数のシステムが関与する環境で特に有用です。例えば、注文データはOracle Fusionから、出荷データはサードパーティ製のロジスティクスシステムから発信される場合があります。 分析において、これはデータリネージの理解に役立ち、特定のシステムからのイベントでプロセスビューをフィルタリングするために使用できます。データ検証と、異なるITランドスケープ間でのプロセス断片化を特定するために不可欠です。 その重要性 データ発生源に関するコンテキストを提供し、マルチシステム環境におけるデータガバナンスとトラブルシューティングにとって不可欠です。 取得元 データ抽出・変換の過程で付与する固定値で、データセットのソースを示すラベルとして利用します。 例 Oracle Fusion Cloud FinancialsOracle SCM CloudOracle ERP | |||
| ビジネスユニット BusinessUnitName | 販売注文を担当する社内事業単位の名称。 | ||
| 説明 この属性は、取引を所有する社内の特定の部門または運用単位を表します。これにより、組織の異なる部門間でのパフォーマンス比較が可能になります。 事業単位別にプロセスをセグメント化することで、会社全体の効率、コスト、およびコンプライアンスにおける変動を特定するのに役立ちます。この分析は、高パフォーマンスの単位におけるベストプラクティスを明らかにし、共有を促したり、的を絞ったプロセス改善が必要なパフォーマンスの低い単位を強調したりすることができます。 その重要性 異なる組織単位間でのパフォーマンスベンチマーキングとプロセス一貫性分析を可能にします。 取得元 通常、販売注文ヘッダーで利用可能であり、Oracle Fusionで定義された組織構造にリンクされています。 例 BU-North AmericaBU-EMEAグローバルサービス | |||
| 最終データ更新 LastUpdateDate | このイベントのデータがソースシステムから最後に更新された日時を示すタイムスタンプ。 | ||
| 説明 この属性は、プロセスマイニングデータセット内でデータが最後に抽出または更新された日時を記録します。これにより、分析されているデータの鮮度に関する透明性が提供されます。 この情報は、ユーザーがプロセス分析の最新性を理解するために不可欠です。データの適時性に関する期待値を管理するのに役立ち、データ更新スケジュールの設定と監視にとって重要です。 その重要性 データの鮮度を示し、プロセス分析がどれだけ最新かをユーザーに明確にします。 取得元 この値は、各データ抽出および変換サイクル中に生成され、データセットにスタンプされます。 例 2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
| 出荷方法 ShippingMethod | 商品を顧客へ出荷するために使用された方法または運送業者。 | ||
| 説明 この属性は、「Ground Freight(陸上貨物)」、「Air Express(航空速達)」、「Local Courier(地域クーリエ)」など、配送に使用されたロジスティクス運送業者またはサービスレベルの詳細を説明します。 この情報は、「出荷方法配送遵守」ダッシュボードにとって不可欠です。これにより、異なる方法や運送業者間での納期遵守パフォーマンスと出荷コストの比較が可能になり、ロジスティクス戦略とベンダー選定の最適化に役立ちます。 その重要性 異なる運送業者や配送方法のパフォーマンス比較を可能にすることで、物流分析を直接サポートします。 取得元 Oracle Fusion内の出荷およびフルフィルメントテーブルで利用可能です。Oracle Fusion Financialsのドキュメントを参照してください。 例 FedEx Ground`UPS` `ネクストデイ` `エアー`DHL International | |||
| 定時配送か IsOnTimeDelivery | 実際の配送が要求された配送日以前に行われた場合にtrueとなる計算フラグです。 | ||
| 説明 このブール属性は、ActualDeliveryDateとRequestedDeliveryDateを比較することで導出されます。これは、配送パフォーマンスを示すシンプルでケースレベルの指標を提供します。 このフラグは、集計「納期遵守率」KPIを計算するための基盤となります。フィルタリングと分析を簡素化し、ユーザーがすべての遅延注文を迅速に隔離して、遅延に寄与する要因に関する根本原因分析を実行することを可能にします。 その重要性 顧客の期待に対するフルフィルメントパフォーマンスを直接測定し、遅延注文の分析を簡素化します。 取得元 これは計算フィールドです。ロジックは「ActualDeliveryDate <= RequestedDeliveryDate」です。 例 truefalse | |||
| 延滞 IsLatePayment | 支払いが支払い期日後に受領された場合にtrueとなる計算フラグです。 | ||
| 説明 このブール属性は、実際の支払い受領日と支払期日を比較することで導出されます。請求書が期日通りに支払われたかどうかを明確に示します。 この属性は、「期日内支払い率」KPIを計算するために使用されます。期日通り支払いと遅延支払いを容易にセグメント化し、支払い遅延顧客の特性、遅延の一般的な理由、および運転資本への財務的影響を分析することを可能にします。 その重要性 支払回収の有効性を直接測定し、延滞支払いの分析を簡素化します。 取得元 これは計算フィールドです。ロジックは「PaymentReceivedDate > PaymentDueDate」です。 例 falsetrue | |||
| 支払条件 PaymentTerms | 顧客支払いに関して合意された条件。 | ||
| 説明 この属性は、顧客が請求書を支払うべき条件(例:「Net 30」または「Net 60」)を特定します。これらの条件は支払期日を計算するための基礎となります。 分析において、支払条件別にセグメント化することで、支払いサイクルタイムの変動を説明するのに役立ちます。異なる条件は自然に異なる支払い行動につながるため、「期日内支払い率」KPIのコンテキストを提供します。これは信用ポリシーとキャッシュフロー予測に情報を提供できます。 その重要性 支払い行動分析に不可欠なコンテキストを提供し、請求書発行から支払いまでのサイクルタイムの変動を説明するのに役立ちます。 取得元 Oracle Fusion内の販売オーダーまたは顧客アカウントレベルで利用可能です。Oracle Fusion Financialsのドキュメントを参照してください。 例 支払条件:正味30日支払条件:正味60日受領時支払い | |||
| 注文から支払いまでの期間 OrderToPaymentDuration | 販売注文作成から支払い受領までの総時間。 | ||
| 説明 この計算属性は、単一のケースにおける受注から入金までのプロセス(Order to Cash)のエンドツーエンドのサイクルタイムを測定します。これは、最初のイベント(「Sales Order Created(販売注文作成)」)から最終イベント(「Payment Received(支払い受領)」)までの総期間を表します。 この指標は、プロセス全体の健全性と効率性を直接的に測定するものです。これは「全体的な受注から入金までのサイクルタイム」KPIの基礎となり、高レベルのパフォーマンス監視とベンチマーク設定に役立ちます。 その重要性 エンドツーエンドの総サイクルタイムを表し、プロセス全体の効率とキャッシュコンバージョン速度を示すハイレベルKPIとなります。 取得元 これは計算フィールドです。ロジックは「『Payment Received(支払い受領)』のタイムスタンプ - 『Sales Order Created(販売注文作成)』のタイムスタンプ」です。 例 45 days 6 hours62 days 11 hours35 days 2 hours | |||
| 注文タイプ OrderType | 販売オーダーの分類で、「通常注文」や「返品注文」などが含まれます。 | ||
| 説明 「注文タイプ」は、ビジネス目的に基づいて販売注文を分類するために使用されます。一般的なタイプには、標準販売、サービス注文、返品承認(RMA)、社内注文などがあります。 注文タイプ別にプロセスを分析することは重要です。なぜなら、異なるタイプはそれぞれ独自のプロセスフローとパフォーマンス目標を持つことが多いためです。このセグメンテーションは、意図的で想定されるプロセスバリエーションを理解するのに役立ち、それらが逸脱として誤解されるのを防ぎます。 その重要性 異なる、正当なプロセスフロー(例:標準と返品)をセグメント化することで、公正かつ正確な分析を保証できます。 取得元 通常、Oracle Fusionの販売注文ヘッダーテーブルのフィールドとして利用可能です。Oracle Fusion Financialsのドキュメントを参照してください。 例 標準販売注文返品承認サービスオーダー | |||
| 製品名 ProductName | 販売されている製品またはサービスの名称。 | ||
| 説明 この属性は、販売注文明細上の品目を指定します。注文に複数の明細がある場合、ケースは明細レベルで分析されるか、この属性がヘッダーレベルで集計される可能性があります。 製品別に分析することで、特定の製品が頻繁な配送遅延や支払い問題など、より複雑または問題のあるプロセスフローに関連しているかどうかを理解するのに役立ちます。これは製品管理およびサプライチェーン戦略に情報を提供できます。 その重要性 異なる製品のプロセスパフォーマンスを分析し、複雑なフルフィルメントパスや請求パスを持つ可能性のある品目を強調表示できます。 取得元 販売注文明細テーブルから取得され、製品マスターテーブルと結合されます。Oracle Fusion Financialsのドキュメントを参照してください。 例 標準ウィジェットX1プレミアムサービスパッケージComponent Y2-B | |||
| 請求書が修正されたか IsInvoiceCorrected | 請求書が最初の作成後に修正または改訂されたかどうかを示すフラグです。 | ||
| 説明 このブール属性は、「Invoice Corrected(請求書修正済み)」アクティビティの存在によって示されるように、請求書が修正ループを経た場合にtrueとなります。これは、請求段階で手戻りが発生したケースにフラグを立てます。 これは「請求書精度と手戻り分析」ダッシュボードおよび「請求書手戻り率」KPIの主要な入力です。請求書エラーの程度を定量化し、修正が必要な理由を特定するための根本原因分析を可能にし、手作業と支払い遅延の削減を目指します。 その重要性 請求書の手戻りを特定します。これは、プロセス非効率性、データ品質の問題、および支払い遅延の潜在的な主要指標です。 取得元 これは計算フィールドであり、「Invoice Corrected(請求書修正済み)」アクティビティがそのイベントログに存在する場合、通常、ケースに対してtrueに設定されます。 例 falsetrue | |||
| 請求書番号 InvoiceNumber | 顧客請求書の`一意の識別子`です。 | ||
| 説明 この属性は、販売注文から生成された請求書に割り当てられる一意の番号です。販売およびフルフィルメント活動をプロセスの財務決済部分にリンクします。 販売注文が主要なケースIDである一方で、請求書番号は請求および支払いサブプロセスを分析するために極めて重要です。請求書修正、紛争、支払いステータスの追跡に不可欠であり、「請求書精度と手戻り分析」のようなダッシュボードをサポートします。 その重要性 売掛金プロセスへの重要なリンクを提供し、請求書の手戻りや支払いサイクルを分析するために不可欠です。 取得元 RA_CUSTOMER_TRX_ALLなど、Oracle Fusionの売掛金取引テーブルで利用可能です。 例 INV-93485INV-93486INV-93487 | |||
| 顧客国 CustomerCountry | 顧客が所在する国。 | ||
| 説明 この属性は、顧客の出荷先または請求先住所から国情報を提供します。これは地理的分析のための主要なディメンションです。 国別にプロセスをセグメント化することで、プロセスパフォーマンス、サイクルタイム、または支払い行動における地域差を明らかにできます。これは、地域の規制、ロジスティクス上の課題、市場状況が受注から入金までのプロセスに与える影響を理解する上で価値があります。 その重要性 プロセス効率、コンプライアンス、顧客行動における地域差を特定するための地理的分析を可能にします。 取得元 販売注文にリンクされた顧客マスターデータテーブル(HZ_LOCATIONS、HZ_PARTY_SITES)から取得されます。 例 米国ドイツ日本 | |||
受注から入金まで - 販売受注処理活動
| アクティビティ | 説明 | ||
|---|---|---|---|
| 入金確認済み | このアクティビティは、顧客の支払いが受領され、売掛金内の請求書に適用されたことを示します。これは、現金受領の適用が記帳されたときに捕捉されます。 | ||
| その重要性 これは「全体的な受注から入金までのサイクルタイム」と「期日内支払い率」を測定するための重要なマイルストーンです。売上を現金化することを示します。 取得元 これはOracle売掛金における明示的なイベントです。受領書が請求書に適用される際に、AR_RECEIVABLE_APPLICATIONS_ALLのような現金受領テーブルに記録されます。 取得 ARにおける現金受領適用レコードの「適用日」タイムスタンプから取得されます。 イベントタイプ explicit | |||
| 受注確認済み | この主要なマイルストーンは、販売注文が信用承認を含むすべての初期チェックを通過し、現在フルフィルメントのためにコミットされたことを示します。通常、注文ステータスが「Awaiting Shipping(出荷待ち)」や「Scheduled(スケジュール済み)」のような状態に進んだときに推測されます。 | ||
| その重要性 このアクティビティは、「平均注文確定時間」を計算するための重要なマイルストーンであり、注文入力からフルフィルメントプロセスへの引き渡しを示します。 取得元 販売オーダーヘッダーまたはラインのステータスが、フルフィルメントの準備ができたことを示す値(例:「出荷待ち」)に変わったことから推測されます。DOO_HEADERS_ALLまたはDOO_FULFILL_LINES_ALLのステータス列を確認してください。 取得 注文ステータスが確定またはスケジュール済み状態に変わったタイムスタンプから導出されます。 イベントタイプ inferred | |||
| 商品発送済み | このアクティビティは、商品が倉庫から出荷され、顧客への輸送中である時点を示します。これはOracle Shippingで出荷確認トランザクションが処理されたときに捕捉されます。 | ||
| その重要性 これは、プロセスのフルフィルメント部分の完了を示し、請求をトリガーする重要なマイルストーンです。期日内出荷と納期リードタイムを測定するために不可欠です。 取得元 これはOracle Shipping Executionで記録される明示的なイベントです。出荷確認トランザクションにより、出荷日と共にWSH_DELIVERY_DETAILSのような出荷テーブルにレコードが作成されます。 取得 オーダーラインに関連付けられた配送詳細レコードの「実際出荷日」タイムスタンプから取得されます。 イベントタイプ explicit | |||
| 注文完了 | プロセスにおける最終アクティビティであり、販売注文のすべての明細が履行され、請求され、クローズされたことを示します。注文ヘッダーのステータスは「Closed(クローズ済み)」に更新されます。 | ||
| その重要性 このアクティビティは、販売注文ライフサイクルの成功裏の終了を示します。エンドツーエンドのプロセス期間を計算し、決してクローズされない「ゾンビ注文」を特定するために不可欠です。 取得元 DOO_HEADERS_ALLテーブルで販売オーダーヘッダーのステータスが「Closed(クローズ済み)」に変更されたことから推測されます。この最終ステータス変更のタイムスタンプがイベント時間として機能します。 取得 販売オーダーヘッダーのステータスが「Closed(クローズ済み)」に変更されたタイムスタンプから導出されます。 イベントタイプ inferred | |||
| 請求書作成 | このアクティビティは、売掛金モジュールでの顧客請求書の作成を表し、通常は出荷確認イベントによってトリガーされます。一意の番号と作成日を持つ請求書レコードが生成されます。 | ||
| その重要性 支払い回収サイクルの正式な開始を示します。「請求書から支払いまでの時間」および全体的なキャッシュフロー効率を測定するための基準となります。 取得元 これはOracle売掛金(AR)における明示的なイベントです。RA_CUSTOMER_TRX_ALLテーブルにトランザクション日付と共に請求書レコードが作成されます。 取得 ARモジュールにおける請求書トランザクションの作成日から取得されます。 イベントタイプ explicit | |||
| 販売注文作成済み | このアクティビティは販売注文プロセスの開始を示し、新しい販売注文がOracle Fusionに入力された瞬間を表します。このイベントは通常、ユーザーがOrder Managementモジュールで新しい注文レコードを保存する際に明示的に捕捉されます。 | ||
| その重要性 プロセス開始活動として、これはOrder to Cashの全体的なサイクルタイムを測定し、受注量を分析するために不可欠です。 取得元 Order Management Cloudで販売注文レコードが作成される際に明示的に記録されます。DOO_HEADERS_ALLテーブルの作成タイムスタンプを確認してください。 取得 販売オーダーヘッダーレコードの作成タイムスタンプから取得されます。 イベントタイプ explicit | |||
| ピッキング済み | 倉庫から商品を物理的にピッキングし、注文を履行することを示します。これはロジスティクスプロセスにおける重要なステップであり、通常、倉庫管理または出荷モジュールで記録されます。 | ||
| その重要性 このアクティビティは、倉庫業務の可視性を提供します。在庫予約からピッキングまでの遅延は、倉庫におけるリソースまたはプロセスのボトルネックを示唆する可能性があります。 取得元 Oracle Fusion Cloud SCM(Supply Chain Management)モジュール内で取得されます。販売オーダーラインに関連付けられたピッキングウェーブまたはピッキングスリップのステータス変更から推測できます。 取得 SCMモジュールにおけるピッキングトランザクションの完了タイムスタンプから推測されます。 イベントタイプ inferred | |||
| 与信チェック実行済み | 顧客の口座に対する信用度を評価するための信用審査の実行を示します。これは注文処理ワークフロー内の自動または手動のステップであり、その完了は通常、ステータス更新または完了したタスクとしてログに記録されます。 | ||
| その重要性 与信チェックにかかる時間を分析することで、注文承認におけるボトルネックを特定できます。「与信チェックから確定までの時間」KPIにとって極めて重要です。 取得元 販売オーダーのステータス変更、例えば「与信承認保留中」ステータスへの移行、または与信管理機能における明示的なイベントログから推測できます。 取得 注文ステータスの変更または与信審査タスクに関連付けられたタイムスタンプから推測されます。 イベントタイプ inferred | |||
| 与信保留適用済み | このアクティビティは、信用審査の失敗やその他の信用関連の問題により、販売注文が自動的または手動で保留にされるときに発生します。これは通常、システム内の注文の保留ステータスの変更によって捕捉されます。 | ||
| その重要性 信用保留を追跡することは、注文処理遅延の背後にある理由を特定し、信用保留解除プロセスの効率性を測定するために不可欠です。 取得元 販売オーダーに保留が適用されたことから推測されます。これは通常、販売オーダーにリンクされたDOO_HOLDS_ALLなどの保留関連テーブルに記録されます。 取得 オーダー保留テーブルに「Credit(与信)」保留タイプでレコードが作成されたことから推測されます。 イベントタイプ inferred | |||
| 受注キャンセル済み | 完全に商品が出荷される前に販売注文がキャンセルされたことを示します。これは様々な理由で発生し、最終ステータスが「Cancelled(キャンセル済み)」となります。 | ||
| その重要性 これは重要な例外パスです。キャンセルされた注文を分析することで、在庫切れ、価格設定の問題、顧客の心変わりといった根本原因を特定するのに役立ち、プロセス改善に情報を提供できます。 取得元 販売オーダーヘッダーまたはラインのステータスが「Cancelled(キャンセル済み)」状態に変更されたことから推測されます。このステータス変更のタイムスタンプがイベントを記録するために使用されます。 取得 オーダーヘッダーまたはラインのステータスが「Cancelled(キャンセル済み)」に変更されたタイムスタンプから導出されます。 イベントタイプ inferred | |||
| 受注明細完了 | 個別の販売注文明細が最終的にクローズされたことを示し、完全に発送され、請求され、それ以上の取引が予定されていないことを意味します。システムは明細ステータスを「Closed(クローズ済み)」に更新します。 | ||
| その重要性 オーダーラインのクローズは、その品目に関するすべての契約上の義務が完了したことを意味します。これを分析することで、フルフィルメントと支払い後も長期間オープン状態にあるオーダーを特定するのに役立ちます。 取得元 DOO_FULFILL_LINES_ALLテーブルでフルフィルメントラインのステータスが「Closed(クローズ済み)」に変更されたことから推測されます。このステータス変更のタイムスタンプがイベントをマークします。 取得 フルフィルメントラインのステータスが「Closed(クローズ済み)」に変更されたタイムスタンプから導出されます。 イベントタイプ inferred | |||
| 商品配送済み | 顧客が出荷物を受け取ったことを示します。この情報は、多くの場合、外部の運送業者から提供され、Oracle Fusionに更新されるか、出荷日から標準的な輸送時間に基づいて推測される場合があります。 | ||
| その重要性 このアクティビティは、「納期遵守率」KPIの計算と、顧客サービスレベルを正確に測定するために不可欠です。 取得元 これはしばしばネイティブなOracleイベントではありません。運送業者との連携がある場合に捕捉できるか、または「Goods Shipped(商品出荷済み)」日付に標準的な輸送時間を加算することで計算できます。システム分析が必要です。 取得 運送業者のデータフィードから推測されるか、出荷日と平均輸送時間に基づいて計算されます。 イベントタイプ inferred | |||
| 在庫予約済み | このアクティビティは、販売注文明細を履行するための物理在庫の割り当てまたは予約を表します。システムは特定の在庫をコミットし、注文がピッキング準備完了になったときにそれが利用可能であることを保証します。 | ||
| その重要性 これを追跡することで、「在庫割り当てリードタイム」KPIの分析に役立ち、注文確定から商品の確保までの遅延を特定します。 取得元 このイベントは、在庫管理またはサプライチェーン実行モジュールでしばしば捕捉されます。在庫が詳細化または予約されたことを示すフルフィルメント明細のステータス更新から推測することも可能です。 取得 在庫予約またはスケジューリングに関連するフルフィルメントラインのステータス変更から推測されます。 イベントタイプ inferred | |||
| 請求書修正済み | エラーや顧客との紛争により、以前作成された請求書が修正、再発行、または相殺される場合に発生します。これは通常、クレジットメモの作成または請求書の新しいバージョン発行によって記録されます。 | ||
| その重要性 請求書修正を追跡することは、「請求書手戻り率」KPIの鍵であり、支払い遅延や管理コスト増加につながる請求プロセス内の問題を浮き彫りにします。 取得元 クレジットメモ(元の請求書にリンクされている)の作成、またはRA_CUSTOMER_TRX_ALLテーブル内の同じ請求書のその後のバージョンによって推測されます。 取得 以前の請求書トランザクションを参照するクレジットメモまたは請求書を特定することによって導出されます。 イベントタイプ inferred | |||