データテンプレート: 受注から入金まで - 販売受注処理
貴社の受注から入金までの受注処理データテンプレート
- 収集を推奨する項目
- 分析のために追跡すべき主要な活動
- データ抽出のガイダンス
受注から入金まで - 販売受注処理属性
| 名前 | 説明 | ||
|---|---|---|---|
|
アクティビティ名
ActivityName
|
受注のライフサイクル内で発生した特定のビジネスイベント、またはステップの名称です。 | ||
|
説明
この属性は、「受注登録」、「製品出荷」、「入金完了」など、受注で実行された各アクティビティの名称を記録します。これらのアクティビティは、受注から入金までのプロセスの主要な節目を表します。 これらのアクティビティの順序と頻度を分析することは、プロセスマイニングの中核を成します。これにより、一般的な経路、逸脱、ボトルネックなど、実際のプロセスフローを明らかにすることができます。このデータは、プロセス分析における主要な可視化ツールであるプロセスマップの生成に利用されます。
その重要性
プロセス マップにおける各ステップを定義します。これは、プロセスフローを視覚化し分析するために不可欠です。
取得元
これは、Order Management、Shipping Execution、Accounts Receivableなどのモジュールを横断するさまざまなソースシステムイベント、ステータス、およびトランザクション日付から導き出される概念フィールドです。
例
販売注文作成済み商品発送済み請求書作成入金確認済み
|
|||
|
イベント日時
EventTime
|
特定のアクティビティが発生した日時を示すタイムスタンプです。 | ||
|
説明
イベントタイム、またはタイムスタンプは、アクティビティが実行された正確な日時を記録します。例えば、注文が作成された日時、請求書が送信された日時、または支払いが受領された日時などが記録されます。この時間的なデータは、プロセスマイニングの基礎となります。 この属性は、各ケースのイベントを時系列順に並べるために使用され、プロセスフローを正確に再構築するために不可欠です。また、アクティビティ間のサイクルタイム、全体のケース期間、遅延やボトルネックの特定など、すべての期間とパフォーマンス計算の基礎となります。
その重要性
イベントの時系列シーケンスを提供し、cycle time(処理時間)やボトルネックの特定を含む、すべての時間ベースのパフォーマンス分析の基盤となります。
取得元
Oracle EBSの複数のテーブルにわたる様々な日付フィールドから取得されます。例えば、OE_ORDER_HEADERS_ALLのCREATION_DATE、WSH_DELIVERY_DETAILSのACTUAL_SHIPMENT_DATE、RA_CUSTOMER_TRX_ALLのTRX_DATEなどです。
例
2023-04-15T10:30:00Z2023-04-18T14:00:00Z2023-05-01T09:15:00Z
|
|||
|
販売オーダー
SalesOrder
|
顧客の受注を一意に識別するものです。Order to Cashプロセスのプライマリケースとして機能します。 | ||
|
説明
受注番号は、作成から最終クローズまで、ライフサイクル全体を通じて各顧客注文を一意に識別します。これは、予約、出荷、請求、支払いなど、すべての関連するアクティビティを結びつける中心的な役割を果たします。 Process Miningにおいて、この属性はすべての注文のエンドツーエンドの過程を再構築するために不可欠です。すべてのイベントを単一の受注の下にグループ化することで、アナリストは完全なプロセスフローを可視化し、注文間の差異を特定し、個々のケースについてサイクルタイムや納期遵守率のような主要なパフォーマンス指標を測定できます。
その重要性
これはケースIDであり、エンドツーエンドの受注ライフサイクルを分析するために、すべてのプロセスイベントを連携させる基礎となります。
取得元
受注の主キーです。通常、OE_ORDER_HEADERS_ALL.HEADER_IDのようなOracle Order Managementのテーブルで確認されます。
例
685127103482459
|
|||
|
ユーザー名
UserName
|
アクティビティを実行したユーザーです。 | ||
|
説明
特定のプロセスステップを実行した担当者を特定します。これは、注文を作成した営業担当者、確認を実行した信用アナリスト、または請求書を作成した事務員である可能性があります。 ユーザーごとのアクティビティを分析することで、研修ニーズ、高業績の個人やチーム、およびワークロードの分散を特定するのに役立ちます。また、不正な行動の調査や、特定のユーザーに関連する手戻りパターンの理解など、コンプライアンスと監査証跡の分析にとっても不可欠です。
その重要性
ユーザーのパフォーマンス、ワークロード配分、コンプライアンス プロトコルの遵守状況を分析できます。誰がアクションを実行したかを特定するのに役立ちます。
取得元
様々なOracle EBSテーブルのCREATED_BYやLAST_UPDATED_BYといったユーザー関連フィールドから取得されます。完全なユーザー名を取得するには、多くの場合、FND_USERとの結合が必要です。
例
JSMITHRWILLIAMSCDAVIS
|
|||
|
受注ステータス
OrderStatus
|
受注または受注明細の現在または過去のステータスです。 | ||
|
説明
この属性は、入力済み、予約済み、クローズ済み、キャンセル済みなど、異なる時点での受注のステータスを捕捉します。ステータスは多くの場合、プロセスアクティビティに直接対応します。 受注ステータスの追跡は、すべての有効な注文の現在の状態を示すダッシュボードを構築する上で重要です。これにより、マネージャーは受注パイプラインを監視し、滞留している注文を特定し、例外を積極的に管理できます。ステータス遷移の分析は、プロセスマップのアクティビティを定義する一般的な方法です。
その重要性
販売オーダーパイプラインの可視性を提供し、停滞したオーダーの特定とプロセス例外の管理を支援します。
取得元
通常、OE_ORDER_HEADERS_ALLテーブルおよびOE_ORDER_LINES_ALLテーブルのFLOW_STATUS_CODE列にあります。
例
BOOKEDAWAITING_SHIPPINGSHIPPEDCLOSEDCANCELLED
|
|||
|
合計注文金額
TotalOrderAmount
|
受注の合計金額です。 | ||
|
説明
この属性は、受注の全明細の合計金額を取引通貨で表したものです。これは、各ケースに関連付けられた主要な財務指標です。 受注金額別にプロセス指標を分析することは、改善の取り組みを優先順位付けするのに役立ちます。例えば、アナリストは高額な受注が低額な受注よりも多くの遅延や手戻りを経験しているかどうかを調査できます。また、特定のボトルネックで滞留している受注の価値を定量化するなど、財務的影響評価を行うことも可能になります。
その重要性
プロセスの財務分析を可能にし、高価値の注文に優先順位を付けたり、非効率性による金銭的影響を数値化したりする際に役立ちます。
取得元
この値は通常、特定の注文の明細金額を合計することで算出されます。明細金額は、OE_ORDER_LINES_ALLのようなテーブルで見つけることができます。
例
5450.00125000.75980.50
|
|||
|
支払期日
PaymentDueDate
|
顧客からの請求書の支払期限として計算された日付です。 | ||
|
説明
支払期日は、請求書日付と合意された支払条件に基づいて計算される、請求書の支払期限となる特定の暦日です。これは、入金済みアクティビティのターゲット日付です。 この属性は、実際の支払日付と比較することで、支払条件順守率KPIを計算するために不可欠です。偏差を分析することで、回収チームは取り組みの優先順位を付け、慢性的に支払いが遅れている顧客を特定し、督促プロセスの有効性を測定するのに役立ちます。
その重要性
支払いの回収目標日付として機能し、支払いの適時性や顧客の条件遵守状況の測定を可能にします。
取得元
AR_PAYMENT_SCHEDULES_ALLテーブル内のDUE_DATEフィールドにあり、請求書トランザクションにリンクされています。
例
2023-06-152023-07-012023-08-30
|
|||
|
支払条件
PaymentTerms
|
顧客が商品やサービスの支払いをいつ行うべきかを定める、合意済みの条件です。 | ||
|
説明
支払条件とは、「Net 30」や「Net 60」、「Due on Receipt」のように、請求書の支払いに関する取り決めを指します。この属性は、売掛金管理とキャッシュフローにおいて極めて重要です。 支払条件別にプロセスパフォーマンスを分析することで、特定の条件を持つ顧客が支払いを滞納しやすいかどうかを特定できます。この情報は、財務リスクの評価、回収戦略の最適化、および様々な支払条件がどの程度効果的かを評価するために活用されます。「支払条件コンプライアンス監視」ダッシュボードの主要な分析軸となります。
その重要性
支払行動の分析、キャッシュフローのモニタリング、顧客契約に関連する財務リスクの評価に不可欠です。
取得元
RA_TERMSテーブルにあり、RA_CUSTOMER_TRX_ALL(請求書用)やOE_ORDER_HEADERS_ALL(注文書用)などのテーブルのTERM_IDを通じてリンクされています。
例
支払条件:正味30日支払条件:正味60日受領時払い
|
|||
|
確定配送日
ConfirmedDeliveryDate
|
商品が顧客に配達される予定の確約された日付です。 | ||
|
説明
この属性は、顧客に約束または確認された納期を格納します。これは、定時配送パフォーマンスを測定するための目標または基準となります。 プロセスマイニングでは、この日付は実際の配送タイムスタンプ(「製品配送完了」アクティビティのタイムスタンプ)と比較され、「定時配送率」KPIが算出されます。この日付からの逸脱を分析することで、配送遅延につながるロジスティクス、在庫管理、または生産計画におけるシステム的な問題を特定するのに役立ちます。
その重要性
これは定時配送パフォーマンスを測定するための基準であり、顧客満足度と業務の卓越性にとって不可欠なKPIです。
取得元
この日付は通常、OE_ORDER_LINES_ALL テーブルの受注明細レベルにある LATEST_ACCEPTABLE_DATE または REQUEST_DATE フィールドで見つかります。
例
2023-05-102023-06-012023-07-20
|
|||
|
顧客名
CustomerName
|
受注を行った顧客の名称です。 | ||
|
説明
この属性は、受注に関連付けられた顧客の正式名称を識別します。これは、プロセスパフォーマンスをセグメント化し分析するための主要なディメンションです。 顧客ごとにプロセスをフィルタリングまたは分解することで、アナリストはどの顧客が最も長いサイクルタイムを経験しているか、最も高い手戻り率を持っているか、または支払い遅延に最も頻繁に関連しているかを特定できます。このインサイトは、顧客関係の改善、サービスレベルの調整、および顧客行動の理解に不可欠です。
その重要性
顧客中心の分析により、顧客ごとのパフォーマンスのばらつきを特定し、サービスを向上させ、支払い行動を理解することが可能になります。
取得元
OE_ORDER_HEADERS_ALLのSOLD_TO_ORG_IDをHZ_CUST_ACCOUNTSおよびHZ_PARTIESテーブルと結合することで導出され、取引先名を取得します。
例
Global Tech Inc.Innovate Solutions LLCPioneer Corp
|
|||
|
キャンセル理由
CancellationReason
|
受注または受注明細がキャンセルされた、記録上の理由です。 | ||
|
説明
販売受注がキャンセルされた際、この属性はキャンセル理由を捕捉します。理由の例としては、「顧客都合」、「在庫切れ」、「信用保留」などが挙げられます。\n\nこのデータは、注文キャンセルの根本原因分析に不可欠です。「販売受注キャンセル率と理由」ダッシュボードはこの属性を使用してキャンセルの主な要因を特定し、企業が解約率を低減し、在庫予測を改善し、信用方針を洗練させるためのターゲットを絞った戦略を実行することを可能にします。
その重要性
オーダーがキャンセルされる理由について直接的なインサイトを提供し、根本原因分析を可能にすることで、逸失売上を削減し、顧客維持率を向上させます。
取得元
この情報は、OE_ORDER_LINES_ALL テーブル、または受注変更に関連するテーブルで利用可能なCANCELLED_REASONのような理由コードフィールドに格納されていることがよくあります。
例
品目廃止顧客キャンセル済み重複注文
|
|||
|
ソースシステム
SourceSystem
|
データを抽出した元システム。 | ||
|
説明
この属性は、イベントデータがどこから発生したかを示す情報源システムを識別します。このプロセスでは、常にOracle E-Business Suiteになります。 複数のシステムがある環境では、このフィールドはデータの来歴とトラブルシューティングにとって重要です。単一システムのコンテキストでも、データモデルにとって重要なコンテキストを提供し、データ取り込みプロセスの標準化に役立ちます。
その重要性
データの起源に関する必要不可欠なコンテキストを提供し、特にマルチシステム環境において、データのトレーサビリティと適切な解釈を確実にします。
取得元
これは通常、データ抽出、変換、ロード (ETL) プロセス中にデータの出所をラベル付けするために追加される静的な値です。
例
Oracle E-Business SuiteOracle EBS R12
|
|||
|
最終データ更新
LastDataUpdate
|
ソースシステムからの最新データ更新時刻を示すタイムスタンプ。 | ||
|
説明
この属性は、Oracle E-Business Suiteからデータが抽出され、プロセスマイニングツールにロードされた最終日時を示し、分析対象データの鮮度を反映します。 ユーザーが参照するインサイトが、どれくらい新しい情報であるかを理解するために不可欠です。リアルタイムの情報なのか、特定の時点のスナップショットなのかを把握することで、適切な運用上の意思決定が可能になります。
その重要性
データ鮮度は分析の信頼性や迅速な意思決定に不可欠であり、ユーザーにその情報を提供します。
取得元
このタイムスタンプは、データの抽出、変換、ロード(ETL)プロセス中に生成・追加されます。
例
2023-10-27T02:00:00Z2023-10-28T02:00:00Z
|
|||
|
受注数量
OrderQuantity
|
特定の受注明細で注文された製品の数量です。 | ||
|
説明
この属性は、顧客が受注明細で要求した特定の製品の単位数を指定します。これは、明細レベルでの取引の数量を表します。 受注数量は、プロセス挙動が受注規模によって変化するかどうかを判断する分析軸として使用できます。例えば、非常に大きい受注や非常に小さい受注は、異なるプロセス経路をたどったり、異なる種類の遅延を経験したりする可能性があります。また、受注金額などの他の指標に対し、より深い情報を提供します。
その重要性
オーダーの規模に関するコンテキストを提供し、オーダー量がプロセス効率と履行パスにどのように影響するかを分析できるようにします。
取得元
OE_ORDER_LINES_ALLテーブルのORDERED_QUANTITYフィールドにあります。
例
102501
|
|||
|
定時配送か
IsOnTimeDelivery
|
注文が確定配送日までに配達されたかどうかを示すフラグ。 | ||
|
説明
この計算属性は、受注が配送約束を満たしたかどうかを示す真偽値フラグ(True/False)です。「製品配送完了」アクティビティのタイムスタンプと「確認済み納期」を比較して導き出されます。 この属性は「定時配送率」KPIを直接サポートします。各受注に対して明確な真偽の結果を提供することで、分析やダッシュボード作成が簡素化されます。これにより、容易なフィルタリングと集計が可能となり、一般的な製品、顧客、出荷方法など、遅延配送の特性を特定するのに役立ちます。
その重要性
顧客 サービスレベルと履行の信頼性を直接測定し、オンタイムデリバリー KPIの計算と視覚化を簡素化します。
取得元
これは計算フィールドです。ロジックは、「製品配送完了」EventTime <= ConfirmedDeliveryDate の場合 True、それ以外の場合 False です。
例
truefalse
|
|||
|
手戻り
IsRework
|
販売注文に、繰り返しの確認や更新作業のような手戻りが発生したかどうかを識別するフラグです。 | ||
|
説明
これは、手戻りを示すパターンを含むケースをフラグ付けする計算真偽値属性です。手戻りは、受注が複数回計上されるなどのプロセスマップ内のループを検出するか、システムに記録された特定の変更イベントによって識別できます。 このフラグは、「受注手戻り率」KPIの計算や「受注手戻り分析」ダッシュボードの表示に活用されます。これにより、アナリストは標準プロセスから逸脱した受注を容易に分離して調査し、手戻りがサイクルタイムとコストに与える影響を定量化したり、非効率なループの根本原因を特定したりするのに役立ちます。
その重要性
手作業での変更が必要だった注文にフラグを付けることでプロセス非効率性を定量化し、手戻りの原因と影響の分析を可能にします。
取得元
データ変換時に、ループを表す一連のアクティビティ(例: 同じケースに対してOrder Bookedが複数回発生するなど)を特定することで算出されます。
例
truefalse
|
|||
|
支払期日遵守か
IsPaymentOnTime
|
支払いが請求書の支払期日までに受領されたかどうかを示すフラグ。 | ||
|
説明
これは、「入金完了」アクティビティのタイムスタンプを対応する請求書の「支払期日」と比較して導き出される計算真偽値属性です。支払いコンプライアンスを示す単純な真偽値の指標となります。 このフラグは、「支払条件遵守率」KPIの基礎となります。これにより、顧客の支払い挙動や売掛金プロセスの有効性を監視するダッシュボードやレポートの作成が簡素化されます。また、期限内支払いと遅延支払いを迅速に分類して、顧客タイプや支払条件などの要因を分析することが可能になります。
その重要性
支払条件の遵守状況を直接測定します。これはキャッシュフロー管理や顧客の財務信頼性を評価する上で不可欠です。
取得元
これは計算フィールドです。ロジックは、「入金完了」EventTime <= PaymentDueDate の場合 True、それ以外の場合 False です。
例
truefalse
|
|||
|
製品番号
ProductNumber
|
受注明細上の製品または品目に対する一意の識別子です。 | ||
|
説明
この属性は、販売されている特定の資材、品目、またはサービスを識別します。これにより、受注ヘッダーよりもきめ細かいレベルで分析を実行できます。 製品ごとにプロセスを分析することで、製品固有の問題を明らかにすることに役立ちます。例えば、特定の製品は複雑な製造や調達のために処理時間が長くなる可能性があり、一方で別の製品は高い出荷エラー率や顧客からの異議申し立てに関連している可能性があります。これにより、サプライチェーンおよび製品管理におけるターゲットを絞った改善が可能になります。
その重要性
製品レベルの分析により、プロセスの遅延、手戻り、またはその他の非効率性を引き起こす品目を特定できます。
取得元
OE_ORDER_LINES_ALLテーブルのINVENTORY_ITEM_IDから導出され、MTL_SYSTEM_ITEMS_Bと結合することで品目番号または説明を取得できます。
例
AS54888CM15001SV20100
|
|||
|
通貨
Currency
|
受注金額を表す通貨コードです。 | ||
|
説明
通貨属性は、注文金額が米ドル、ユーロ、日本円などのどの通貨で表記されているかを示します。これにより、注文に関連するあらゆる財務データを解釈するために必要なコンテキストが提供されます。 これは、複数の通貨で取引を行う多国籍組織での分析に不可欠です。総注文金額のような財務指標が正しく理解され、集計レポートに通貨換算が必要な場合に適切に行われることを確実にします。
その重要性
すべての金額データに対して必要不可欠なコンテキストを提供し、特にグローバルビジネス環境において、正確な財務分析を確実にします。
取得元
OE_ORDER_HEADERS_ALLテーブル内のTRANSACTIONAL_CURR_CODEフィールドにあります。
例
USDEURGBP
|
|||
|
配送方法
ShippingMethod
|
顧客へ商品を輸送するために使用された方法、または運送業者です。 | ||
|
説明
この属性は、出荷に利用された陸上貨物、航空速達、地域宅配などの輸送モードまたはサービスレベルを指定します。これは、配送時間とコストの両方に影響を与える主要な要素です。 この属性を使用してプロセスを分析することで、企業は異なる出荷方法のパフォーマンスを評価できます。例えば、「Shipping Method Performance」ダッシュボードは、各方法の「製品出荷」から「製品配送完了」までのサイクルタイムを比較し、スピード、コスト、信頼性のバランスの取れたロジスティクスの最適化に役立ちます。
その重要性
異なる運送業者や配送オプションのパフォーマンス評価を可能にし、コスト、速度、信頼性を最適化します。
取得元
通常、WSH_DELIVERY_DETAILSやOE_ORDER_LINES_ALLなどのテーブルにSHIPPING_METHOD_CODEとして保存されます。
例
UPS GroundFedEx Priority OvernightDHL Express Worldwide
|
|||
受注から入金まで - 販売受注処理活動
| アクティビティ | 説明 | ||
|---|---|---|---|
|
入金確認済み
|
このアクティビティは、顧客からの支払いが受領され、システム内の対応する請求書に適用されたときに発生します。これは、売掛金モジュールに記録される明示的な財務取引です。 | ||
|
その重要性
このマイルストーンは、キャッシュフロー、売掛金回収日数(DSO)、および支払い条件の順守状況を追跡する上で非常に重要です。財務サイクルタイムを測定するための主要な終点となります。
取得元
AR_RECEIVABLE_APPLICATIONS_ALLテーブルに明示的に記録されます。APPLY_DATE列は、現金領収書が請求書に適用された時点のタイムスタンプを提供します。
取得
特定の請求書には、AR_RECEIVABLE_APPLICATIONS_ALLのAPPLY_DATEを使用してください。
イベントタイプ
explicit
|
|||
|
受注完了
|
このアクティビティは、すべての明細が正常に出荷、請求、クローズされた後の受注の最終的な完了を示します。これはオーダーヘッダーに対する明示的なステータス更新です。 | ||
|
その重要性
これは、受注から入金までのプロセスにおける主要な成功エンドポイントです。正常に履行された受注のエンドツーエンドサイクルタイムを計算するために必要な最終タイムスタンプを提供します。
取得元
このイベントは、FLOW_STATUS_CODEが「CLOSED」に更新されたときにOE_ORDER_HEADERS_ALL テーブルに記録されます。このステータス変更のLAST_UPDATE_DATEがイベントタイムスタンプとなります。
取得
OE_ORDER_HEADERS_ALLのFLOW_STATUS_CODEが'CLOSED'に更新されたタイムスタンプ。
イベントタイプ
explicit
|
|||
|
受注確定済み
|
販売オーダーの正式な確定を表し、これによりオーダーはアクティブになり、ソーシングや出荷などのその後の処理に適格となります。これは、Oracle EBSにおいてオーダーのステータスを'Entered'から'Booked'に変更する明示的なアクションです。 | ||
|
その重要性
注文確定は、注文の履行を正式に約束する重要なマイルストーンです。作成から確定までの遅延は、データ入力、承認、または初期検証に関する問題を示唆する可能性があります。
取得元
OE_ORDER_HEADERS_ALLテーブルから取得されます。このイベントはBOOKED_FLAGが'Y'に設定されたときに発生し、タイムスタンプはBOOKED_DATE列に記録されます。
取得
OE_ORDER_HEADERS_ALLテーブルのBOOKED_DATEを使用してください。
イベントタイプ
explicit
|
|||
|
商品発送済み
|
商品が物理的に倉庫から出荷される出荷確認プロセスの完了を表します。これは、在庫を更新し、オーダー ステータスを進める出荷モジュールにおける重要な明示的なイベントです。 | ||
|
その重要性
これは、定時出荷パフォーマンスを測定するために使用される重要なフルフィルメントの節目です。また、請求および収益認識プロセスのトリガーとしても機能します。
取得元
Oracle Shipping Executionにおける明示的なトランザクションとして記録されます。タイムスタンプはWSH_NEW_DELIVERIESテーブルのINITIAL_PICKUP_DATEで見つけるか、WSH_DELIVERY_DETAILSのステータス更新が'Shipped'になった時点から導出できます。
取得
WSH_DELIVERY_DETAILSまたはWSH_NEW_DELIVERIESからの出荷確認日を使用してください。
イベントタイプ
explicit
|
|||
|
在庫引当済み
|
このアクティビティは、注文明細に対する在庫の引当を表し、必要な数量がピッキングのために利用可能であることを確保します。これは通常、倉庫へのリリース準備ができたことを示す受注明細のステータス変更から推測されます。 | ||
|
その重要性
このマイルストーンは、履行準備状況を把握する上で極めて重要です。ここでの遅延は、在庫不足、調達の問題、または引当プロセスの非効率性を示している可能性があります。
取得元
WSH_DELIVERY_DETAILSテーブルでのステータス変更から推測されます。このアクティビティは、明細のステータスが「リリース準備完了」に更新された際に発生し、タイムスタンプは関連するステータス更新から取得されます。
取得
WSH_DELIVERY_DETAILSにおける明細ステータスの「リリース準備完了」への更新から推測されます。
イベントタイプ
inferred
|
|||
|
請求書作成
|
このイベントは、出荷された製品に対する売掛金請求書の作成を示します。これは、Order ManagementおよびShippingからデータをReceivablesモジュールに取り込むAutoInvoiceプロセスによってトリガーされる明示的なイベントです。 | ||
|
その重要性
このアクティビティはプロセスの財務決済部分を開始します。これは、請求書から支払いまでのサイクルタイムを測定し、請求効率を監視するための開始点です。
取得元
これは、Oracle ReceivablesのRA_CUSTOMER_TRX_ALL テーブルに記録される明示的なトランザクションです。TRX_DATEまたはCREATION_DATEがイベントタイムスタンプとして機能します。
取得
RA_CUSTOMER_TRX_ALLテーブルのTRX_DATEを使用してください。
イベントタイプ
explicit
|
|||
|
販売注文作成済み
|
このアクティビティは、システムにおける受注の初期作成を示します。これは、ユーザーが新しい受注ヘッダーを保存したときに捕捉される明示的なイベントであり、order-to-cashプロセスの正式な開始を表します。 | ||
|
その重要性
これは、プロセスの主要な開始イベントです。この時点から後続のアクティビティまでの時間を分析することは、受注から入金までの全体的なサイクルタイムを測定するために不可欠です。
取得元
このイベントは、Oracle Order ManagementモジュールのOE_ORDER_HEADERS_ALL テーブルから取得されます。CREATION_DATE 列は、このアクティビティの明示的なタイムスタンプを提供します。
取得
OE_ORDER_HEADERS_ALLテーブルのCREATION_DATEを使用してください。
イベントタイプ
explicit
|
|||
|
ピック指示済
|
このイベントは、受注明細が倉庫にリリースされ、ピッキングアクティビティが開始される時点を示します。これは、ピッキング伝票を作成し、倉庫作業員が受注を確認できるようになる明示的なアクションです。 | ||
|
その重要性
このアクティビティは物理的なフルフィルメントプロセスを開始します。この時点から出荷済みまでの時間を分析することで、倉庫現場の効率と潜在的なピッキングのボトルネックが明らかになります。
取得元
これは、Oracle Shipping Executionモジュールで捕捉される明示的なイベントです。WSH_DELIVERY_DETAILS内の配送詳細のステータスが「Released to Warehouse」または「Transactable」に変更されることで識別できます。
取得
WSH_DELIVERY_DETAILS.RELEASED_STATUSが'S' (提出済み) に変更されたタイムスタンプ。
イベントタイプ
explicit
|
|||
|
与信チェック実行済み
|
このアクティビティは、注文に対する顧客の信用照会プロセスの完了を示します。信用照会保留が適用されている場合、それが受注から解除され、プロセスが続行できるようになったときに捕捉されることがよくあります。 | ||
|
その重要性
与信チェックの遅延は、プロセス全体を停滞させる一般的なボトルネックです。このアクティビティをモニタリングすることで、財務管理および承認における非効率性を特定するのに役立ちます。
取得元
このイベントは、OE_ORDER_HOLDS_ALL テーブルから、特定の受注ヘッダーに対して「与信チェック保留」が解除されたときのタイムスタンプを特定することで推測できます。
取得
OE_ORDER_HOLDS_ALLからの信用関連の保留に対するリリースタイムスタンプを使用してください。
イベントタイプ
inferred
|
|||
|
受注キャンセル済み
|
履行が完了する前に販売オーダー全体がキャンセルされることを表します。これは、オーダー処理 ワークフローを終了させる明示的なイベントです。 | ||
|
その重要性
これは重要な例外エンドポイントです。キャンセルの頻度、タイミング、および理由を分析することは、収益損失とプロセスまたは製品の問題を特定するために不可欠です。
取得元
FLOW_STATUS_CODEが'CANCELLED'に設定され、CANCELLED_FLAGが'Y'の場合にOE_ORDER_HEADERS_ALLテーブルに記録されます。LAST_UPDATE_DATEをタイムスタンプとして使用できます。
取得
OE_ORDER_HEADERS_ALLのCANCELLED_FLAGが'Y'に設定されたタイムスタンプ。
イベントタイプ
explicit
|
|||
|
受注明細完了
|
個別の販売注文明細に対する、出荷および請求書発行を含む全ての処理が完了したことを示します。これは、ワークフロープロセスによって管理される明示的なステータス変更です。 | ||
|
その重要性
明細レベルのクローズを追跡することで、部分出荷の分析や、注文全体が完了する前に特定の製品や履行経路に関する問題を特定するのに役立ちます。
取得元
これは、FLOW_STATUS_CODEが「CLOSED」に更新されたときにOE_ORDER_LINES_ALL テーブルに記録されます。このステータス変更のLAST_UPDATE_DATEがタイムスタンプとして機能します。
取得
OE_ORDER_LINES_ALLのFLOW_STATUS_CODEが'CLOSED'に更新されたタイムスタンプ。
イベントタイプ
explicit
|
|||
|
商品配送済み
|
このアクティビティは、出荷が顧客に到着したことを示します。標準のOracle EBSはこのイベントを追跡しないため、通常は外部の運送業者システムから推測またはインポートする必要があります。 | ||
|
その重要性
オンタイムデリバリー KPIの測定と、顧客体験全体を理解するために不可欠です。出荷と配送の間のギャップは、運送業者のパフォーマンスを浮き彫りにします。
取得元
システム分析が必要です。このデータはOracle EBSにネイティブには存在せず、外部の運送業者データフィードまたはシステムと統合されたロジスティクスプラットフォームから取得する必要があります。
取得
外部の運送業者データから推測されるか、または「商品発送済み」後の標準的な輸送時間に基づいて仮定されます。
イベントタイプ
inferred
|
|||
|
顧客へ請求書送信済み
|
このアクティビティは、請求書が印刷または電子的手段で顧客に送信される時点を表します。これは、作成とは常に明示的かつ分離されたイベントではないため、通常は推測されます。 | ||
|
その重要性
顧客の支払期間が正式に開始するタイミングを示します。請求書の作成から送付までの遅延は、キャッシュフローに悪影響を及ぼし、支払いの遅延につながる可能性があります。
取得元
これは、RA_CUSTOMER_TRX_ALL テーブルの LAST_PRINTED_DATE から推測できます。電子請求書の場合、外部文書配信システムのログを確認する必要がある場合があります。
取得
RA_CUSTOMER_TRX_ALLのLAST_PRINTED_DATEまたはサードパーティツールからのログを使用してください。
イベントタイプ
inferred
|
|||