受注から入金まで:販売注文処理のデータテンプレート
受注から入金まで:販売注文処理のデータテンプレート
- 収集を推奨する属性
- 分析で追跡する主要なアクティビティ
- データ抽出のガイダンス
受注から入金まで:受注処理の属性
| 名前 | 説明 | ||
|---|---|---|---|
|
アクティビティ名
ActivityName
|
販売注文のライフサイクル内で発生した特定の業務イベントまたはステップの名称です。 | ||
|
説明
この属性には、販売注文に対して実行された各アクティビティの名称が記録されます。たとえば、「Order Booked」、「Goods Shipped」、「Payment Received」などです。これらのアクティビティは、受注から入金までのプロセスにおける主要なマイルストーンを表します。 これらのアクティビティの順序と頻度を分析することは、プロセスマイニングの中心的な作業です。一般的な経路、逸脱、ボトルネックを含む実際のプロセスフローを発見できます。このデータからプロセスマップを生成し、プロセス分析の主要な可視化として利用します。
重要な理由
プロセスマップ上のステップを定義し、プロセスフローの可視化と分析に役立ちます。
入手先
Order Management、Shipping Execution、Accounts Receivableなどのモジュールにある、さまざまなソースシステムのイベント、ステータス、トランザクション日付から導出する概念的な項目です。
例
販売注文の作成商品の出荷請求書の作成入金
|
|||
|
イベント時刻
EventTime
|
特定のアクティビティが発生した時点を示すタイムスタンプです。 | ||
|
説明
イベント時刻、つまりタイムスタンプは、アクティビティが実行された正確な日時を記録します。たとえば、注文の作成時、請求書の送付時、入金時などを記録します。この時間データは、プロセスマイニングの基本となります。 この属性を使って、ケースごとにイベントを時系列に並べ、プロセスフローを正確に再構築します。また、アクティビティ間のサイクルタイム、ケース全体の所要時間、遅延やボトルネックの特定など、期間やパフォーマンスに関するすべての計算の基礎になります。
重要な理由
イベントの時系列を提供し、サイクルタイムやボトルネックの特定など、時間に基づくパフォーマンス分析の基盤となります。
入手先
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
|
顧客の販売注文を一意に識別するIDであり、受注から入金までのプロセスにおける主要なケースです。 | ||
|
説明
販売注文番号は、作成から最終的なクローズまで、注文のライフサイクル全体を通じて各顧客注文を一意に識別します。受注の確定、出荷、請求、入金など、関連するすべてのアクティビティを結び付ける中心的な識別子です。 プロセスマイニングでは、すべてのプロセスイベントを関連付けるために欠かせない属性です。すべてのイベントを1つの販売注文にまとめることで、分析担当者はプロセスフロー全体を可視化し、注文ごとの違いを特定できます。また、個々のケースについて、サイクルタイムや納期どおりの配送などの主要なパフォーマンス指標を測定できます。
重要な理由
これはケースIDであり、プロセスイベントをすべて結び付け、注文のライフサイクル全体を分析するための基本項目です。
入手先
販売注文の主キーで、通常はOE_ORDER_HEADERS_ALL.HEADER_IDなどのOracle Order Managementテーブルにあります。
例
685127103482459
|
|||
|
ユーザー名
UserName
|
アクティビティを実行したユーザーです。 | ||
|
説明
特定のプロセスステップを実行したユーザーを識別します。注文を作成した営業担当者、与信審査を実施した与信担当者、請求書を作成した事務担当者などが該当します。 ユーザー別にアクティビティを分析すると、トレーニングの必要性、成果の高い個人やチーム、業務量の分布を把握できます。また、権限のない操作の調査や、特定のユーザーに関連する手戻りパターンの理解など、コンプライアンスや監査証跡の分析にも欠かせません。
重要な理由
ユーザーのパフォーマンス、業務量の分布、コンプライアンス手順の遵守状況を分析できます。誰が操作を実行したのかを確認する際にも役立ちます。
入手先
さまざまなOracle EBSテーブルのCREATED_BYやLAST_UPDATED_BYなど、ユーザー関連のフィールドから取得します。完全なユーザー名を取得するには、FND_USERとの結合が必要になる場合があります。
例
JSMITHRWILLIAMSCDAVIS
|
|||
|
支払期日
PaymentDueDate
|
顧客から請求書の支払いを受ける期限として算出された日付です。 | ||
|
説明
支払期日は、請求書の日付と合意した支払条件に基づいて算出される、請求書の支払期限です。「Payment Received」アクティビティの目標日となります。 この属性は、実際の支払日と比較して「支払条件遵守率」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を介して関連付けます。
例
Net 30Net 60受領時支払い
|
|||
|
注文ステータス
OrderStatus
|
販売注文または注文行の現在または過去のステータスです。 | ||
|
説明
この属性には、「Entered」、「Booked」、「Closed」、「Cancelled」など、さまざまな時点における販売注文のステータスが記録されます。ステータスは、プロセスアクティビティに直接対応することがよくあります。 注文ステータスを追跡すると、アクティブなすべての注文の現在の状態を示すダッシュボードを作成できます。管理者は注文パイプラインを監視し、停滞している注文を特定して、例外に先回りして対応できます。ステータスの遷移を分析することは、プロセスマップのアクティビティを定義する一般的な方法です。
重要な理由
販売注文パイプラインを可視化し、停滞している注文の特定とプロセス上の例外管理に役立ちます。
入手先
通常は、OE_ORDER_HEADERS_ALLおよびOE_ORDER_LINES_ALLテーブルのFLOW_STATUS_CODE列にあります。
例
BOOKEDAWAITING_SHIPPINGSHIPPEDCLOSEDCANCELLED
|
|||
|
注文総額
TotalOrderAmount
|
販売注文の金銭的な合計額です。 | ||
|
説明
この属性は、取引通貨で表した販売注文の全注文行の合計額を示します。各ケースに関連する主要な財務指標です。 注文金額別にプロセス指標を分析すると、改善の優先順位を付けられます。たとえば、高額注文のほうが低額注文より遅延や手戻りが多いかを調査できます。また、特定のボトルネックで滞留している注文の金額を算出するなど、財務上の影響も評価できます。
重要な理由
プロセスを財務面から分析し、高額注文の優先順位付けや、非効率による金銭的影響の算出に役立ちます。
入手先
通常は、対象注文の注文行金額を合計して算出します。注文行金額は、OE_ORDER_LINES_ALLなどのテーブルにあります。
例
5450.00125000.75980.50
|
|||
|
確定納期
ConfirmedDeliveryDate
|
商品を顧客に配送する予定として確約した日付です。 | ||
|
説明
この属性には、顧客に約束または確定した配送日が保存されます。納期どおりの配送パフォーマンスを測定する際の目標または基準となります。 プロセスマイニングでは、この日付と「Goods Delivered」アクティビティの実際の配送タイムスタンプを比較し、「納期遵守率」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
|
販売注文または注文行をキャンセルした理由として記録された内容です。 | ||
|
説明
販売注文がキャンセルされた場合、この属性にはキャンセル理由が記録されます。理由の例として、「顧客からの依頼」、「在庫切れ」、「与信保留」などがあります。 このデータは、販売注文のキャンセルに関する根本原因分析に欠かせません。「販売注文キャンセル率と理由」ダッシュボードでは、この属性を使ってキャンセルの主な要因を特定し、解約を減らすための施策、在庫予測の改善、与信ポリシーの見直しにつなげられます。
重要な理由
注文がキャンセルされた理由を直接把握できるため、失注を減らし、顧客維持率を高めるための根本原因分析に役立ちます。
入手先
この情報は通常、CANCELLED_REASONなどの理由コード項目に保存されます。OE_ORDER_LINES_ALLテーブル、または注文変更に関連するテーブルで確認できる場合があります。
例
販売終了品顧客によるキャンセル重複注文
|
|||
|
ソースシステム
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
|
|||
|
手戻りの有無
IsRework
|
販売注文で、確認や更新の繰り返しなどの手戻りが発生したかどうかを示すフラグです。 | ||
|
説明
手戻りを示すパターンを含むケースにフラグを付ける、計算された真偽値の属性です。プロセスマップ上のループや、同じ注文が複数回登録されるパターン、システムに記録された特定の変更イベントを検出して、手戻りを特定できます。 このフラグは「販売注文手戻り率」KPIの計算と、「販売注文手戻り分析」ダッシュボードに使われます。標準プロセスから外れた注文を簡単に抽出して調査できるため、手戻りがサイクルタイムやコストに与える影響を定量化し、非効率なループの根本原因を特定できます。
重要な理由
手動変更が必要だった注文を特定し、プロセスの非効率を定量化できます。手戻りの原因と影響の分析にも役立ちます。
入手先
データ変換時に、ループを表すアクティビティの連続を特定して算出します。たとえば、同じケースで「Order Booked」が複数回発生する場合などです。
例
truefalse
|
|||
|
支払いが期日どおりかどうか
IsPaymentOnTime
|
請求書の支払期日までに、または支払期日当日に入金されたかどうかを示すフラグです。 | ||
|
説明
該当する請求書の「Payment Received」アクティビティのタイムスタンプと「Payment Due Date」を比較して算出する、真偽値の計算属性です。支払い条件を遵守したかどうかをTrue/Falseで示します。 このフラグは「支払い条件遵守率」KPIの基礎となります。顧客の支払い行動や売掛金プロセスの有効性を監視するダッシュボードとレポートを簡単に作成できます。期日どおりの支払いと遅延した支払いをすばやく分類し、顧客タイプや支払い条件などの要因を分析できます。
重要な理由
支払い条件の遵守状況を直接測定できるため、キャッシュフローの管理と顧客の財務面での信頼性評価に役立ちます。
入手先
計算項目です。ロジックは次のとおりです:IF(「Payment Received」EventTime <= PaymentDueDate)THEN True ELSE False。
例
truefalse
|
|||
|
注文数量
OrderQuantity
|
特定の販売注文明細行で注文された製品の数量です。 | ||
|
説明
この属性は、販売注文の明細行で顧客が要求した製品の数量を示します。明細行単位で取引量を表す値です。 注文数量を分析の軸にすると、注文規模によってプロセスの動きが変わるかどうかを確認できます。たとえば、非常に大きな注文や小さな注文では、異なるプロセス経路をたどったり、異なる種類の遅延が発生したりする場合があります。また、注文金額など、他の指標を解釈する際の背景情報にもなります。
重要な理由
注文規模を把握できるため、注文量がプロセス効率やフルフィルメント経路に与える影響を分析できます。
入手先
OE_ORDER_LINES_ALLテーブルのORDERED_QUANTITY項目に保存されています。
例
102501
|
|||
|
納期どおりかどうか
IsOnTimeDelivery
|
注文が確定納期までに、または確定納期当日に納品されたかどうかを示すフラグです。 | ||
|
説明
この計算属性は、注文が納期の約束を守ったかどうかを示す真偽値(True/False)です。「Goods Delivered」アクティビティのタイムスタンプと「Confirmed Delivery Date」を比較して算出します。 この属性は「納期遵守率」KPIを直接支えます。注文ごとの結果を明確な二値で示すため、分析やダッシュボード作成が簡単になります。納期遅延が発生した注文を絞り込み、共通する製品、顧客、配送方法などの特徴を集計できます。
重要な理由
顧客サービスの水準とフルフィルメントの信頼性を直接測定し、納期遵守率KPIの計算と可視化を簡単にします。
入手先
計算項目です。ロジックは次のとおりです:IF(「Goods Delivered」EventTime <= ConfirmedDeliveryDate)THEN True ELSE False。
例
truefalse
|
|||
|
製品番号
ProductNumber
|
販売注文の明細行に含まれる製品または品目を一意に識別する番号です。 | ||
|
説明
この属性は、販売する具体的な資材、品目、サービスを識別します。販売注文ヘッダーよりも詳細な単位で分析できます。 製品別にプロセスを分析すると、製品固有の問題を見つけやすくなります。たとえば、製造や調達が複雑な製品ではフルフィルメントに時間がかかる場合があります。一方で、出荷ミスや顧客との紛争が多い製品もあります。こうした分析により、サプライチェーンと製品管理を対象とした改善を進められます。
重要な理由
製品単位で分析し、プロセスの遅延、手戻り、その他の非効率を引き起こす品目を特定できます。
入手先
OE_ORDER_LINES_ALLテーブルのINVENTORY_ITEM_IDから取得し、MTL_SYSTEM_ITEMS_Bと結合して品目番号または説明を取得できます。
例
AS54888CM15001SV20100
|
|||
|
通貨
Currency
|
販売注文の金額に使用する通貨コードです。 | ||
|
説明
通貨属性は、注文金額の通貨を指定します。USD、EUR、JPYなどが該当します。注文に関する財務データを解釈するために必要な情報です。 複数の通貨で取引する多国籍組織の分析では欠かせません。「注文総額」などの財務指標を正しく理解し、必要に応じて集計レポート用の通貨換算を行えます。
重要な理由
すべての金額に必要な情報を提供し、特にグローバルな事業環境で正確な財務分析を可能にします。
入手先
OE_ORDER_HEADERS_ALLテーブルのTRANSACTIONAL_CURR_CODEフィールドにあります。
例
USDEURGBP
|
|||
|
配送方法
ShippingMethod
|
商品を顧客へ輸送する際に使用する方法または配送業者です。 | ||
|
説明
この属性は、「Ground Freight」、「Air Express」、「Local Courier」など、配送に使用する輸送手段またはサービスレベルを指定します。配送時間とコストの両方に影響する重要な要素です。 この属性を使ってプロセスを分析すると、配送方法ごとのパフォーマンスを評価できます。たとえば、「配送方法パフォーマンス」ダッシュボードでは、方法ごとに「Goods Shipped」から「Goods Delivered」までのサイクルタイムを比較し、速度、コスト、信頼性のバランスを考慮した物流の改善に役立てます。
重要な理由
配送業者や配送方法ごとのパフォーマンスを評価し、コスト、速度、信頼性の最適化に役立ちます。
入手先
通常は、WSH_DELIVERY_DETAILSやOE_ORDER_LINES_ALLなどのテーブルにあるSHIPPING_METHOD_CODEとして保存されます。
例
UPS GroundFedEx Priority OvernightDHL Express Worldwide
|
|||
受注から入金まで:受注処理のアクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
|
入金
|
顧客からの支払いを受領し、システム上で該当する請求書に充当した時点で発生します。Accounts Receivableモジュールに記録される明示的な財務トランザクションです。 | ||
|
重要な理由
キャッシュフロー、売上債権回転日数(DSO)、支払条件へのコンプライアンスを追跡するうえで重要なマイルストーンです。財務サイクルタイムを測定する際の主要な終点となります。
入手先
AR_RECEIVABLE_APPLICATIONS_ALLテーブルに明示的に記録されます。APPLY_DATE列から、入金を請求書に充当した時点のタイムスタンプを取得できます。
取得
該当する請求書について、AR_RECEIVABLE_APPLICATIONS_ALLのAPPLY_DATEを使用します。
イベントタイプ
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テーブルのステータス変更から推定します。行のステータスが「Ready to Release」に更新された時点でアクティビティが発生し、タイムスタンプは関連するステータス更新から取得します。
取得
WSH_DELIVERY_DETAILSの行ステータスが「Ready to Release」に更新された記録から推定します。
イベントタイプ
inferred
|
|||
|
注文のクローズ
|
すべての注文行が正常に出荷、請求、クローズされた後、販売注文が最終的に完了したことを示します。注文ヘッダーに対する明示的なステータス更新です。 | ||
|
重要な理由
受注から入金までのプロセスにおける主要な成功終点です。正常に履行された注文のエンドツーエンドのサイクルタイムを計算するために必要な最終タイムスタンプを提供します。
入手先
OE_ORDER_HEADERS_ALLテーブルでFLOW_STATUS_CODEが「CLOSED」に更新された際に記録されます。このステータス変更におけるLAST_UPDATE_DATEがイベントのタイムスタンプです。
取得
OE_ORDER_HEADERS_ALLでFLOW_STATUS_CODEが「CLOSED」になった更新時点のタイムスタンプです。
イベントタイプ
explicit
|
|||
|
請求書の作成
|
このイベントは、出荷済み商品の売掛請求書が作成されたことを示します。Order ManagementとShippingからデータを取得してReceivablesモジュールに取り込むAutoInvoiceプロセスによって開始される明示的なイベントです。 | ||
|
重要な理由
このアクティビティによって、プロセスの決済に関する財務処理が始まります。請求書発行から入金までのサイクルタイムを測定し、請求処理の効率を監視する際の開始点です。
入手先
Oracle ReceivablesのRA_CUSTOMER_TRX_ALLテーブルに明示的なトランザクションとして記録されます。TRX_DATEまたはCREATION_DATEがイベントのタイムスタンプになります。
取得
RA_CUSTOMER_TRX_ALLテーブルのTRX_DATEを使用します。
イベントタイプ
explicit
|
|||
|
販売注文の作成
|
このアクティビティは、システム上で販売注文が最初に作成されたことを示します。ユーザーが新しい販売注文ヘッダーを保存した際に記録される明示的なイベントであり、受注から入金までのプロセスの正式な開始点となります。 | ||
|
重要な理由
これはプロセスの主要な開始イベントです。この時点から後続のアクティビティまでの時間を分析することは、受注から入金までの全体のサイクルタイムを測定するうえで欠かせません。
入手先
このイベントは、Oracle Order ManagementモジュールのOE_ORDER_HEADERS_ALLテーブルから取得します。CREATION_DATE列が、このアクティビティの明示的なタイムスタンプになります。
取得
OE_ORDER_HEADERS_ALLテーブルのCREATION_DATEを使用します。
イベントタイプ
explicit
|
|||
|
ピッキングリリース済み
|
このイベントは、販売注文行がピッキングのために倉庫へリリースされた時点を示します。ピッキングリストを作成し、倉庫担当者が注文を確認できるようにする明示的なアクションです。 | ||
|
重要な理由
このアクティビティによって、実際の履行プロセスが始まります。この時点から「Goods Shipped」までの時間を分析すると、倉庫現場の効率とピッキングにおける潜在的なボトルネックを把握できます。
入手先
Oracle Shipping Executionモジュールに記録される明示的なイベントです。WSH_DELIVERY_DETAILSの配送詳細ステータスが「Released to Warehouse」または「Transactable」に変更された記録から特定できます。
取得
WSH_DELIVERY_DETAILS.RELEASED_STATUSが「S」(Submitted)に変更された時点のタイムスタンプです。
イベントタイプ
explicit
|
|||
|
与信審査の完了
|
このアクティビティは、注文に対する顧客の与信審査が完了したことを示します。与信審査保留が設定されている場合は、販売注文から保留が解除された時点で取得することが一般的です。 | ||
|
重要な理由
与信審査の遅延は、履行プロセス全体を停滞させる一般的なボトルネックです。このアクティビティを監視することで、財務管理や承認における非効率を特定できます。
入手先
OE_ORDER_HOLDS_ALLテーブルから、特定の注文ヘッダーに対する「Credit Check Hold」が解除された時点のタイムスタンプを特定して推定できます。
取得
OE_ORDER_HOLDS_ALLから、与信関連の保留が解除された時点のタイムスタンプを使用します。
イベントタイプ
inferred
|
|||
|
商品の配送完了
|
出荷物が顧客に到着したことを示します。標準のOracle EBSではこのイベントを追跡しないため、通常は外部の配送業者システムから推定または取り込む必要があります。 | ||
|
重要な理由
納期どおりの配送に関するKPIを測定し、顧客体験全体を把握するうえで欠かせません。出荷から配送までの差分から、配送業者のパフォーマンスを確認できます。
入手先
システム分析が必要です。このデータはOracle EBSで標準提供されないため、外部の配送業者データフィードまたはシステムと連携した物流プラットフォームから取得する必要があります。
取得
外部の配送業者データから推定するか、「Goods Shipped」後の標準的な輸送時間に基づいて設定します。
イベントタイプ
inferred
|
|||
|
注文のキャンセル
|
履行が完了する前に、販売注文全体がキャンセルされたことを示します。注文処理のワークフローを終了させる明示的なイベントです。 | ||
|
重要な理由
重要な例外終点です。キャンセルの頻度、発生時期、理由を分析することは、売上損失やプロセス・商品の問題を特定するうえで欠かせません。
入手先
OE_ORDER_HEADERS_ALLテーブルでFLOW_STATUS_CODEが「CANCELLED」に設定され、CANCELLED_FLAGが「Y」になった際に記録されます。LAST_UPDATE_DATEをタイムスタンプとして使用できます。
取得
OE_ORDER_HEADERS_ALLのCANCELLED_FLAGが「Y」に設定された時点のタイムスタンプです。
イベントタイプ
explicit
|
|||
|
注文行のクローズ
|
出荷や請求を含む、販売注文の個別の行に関するすべての処理が完了したことを示します。ワークフロープロセスによって管理される明示的なステータス変更です。 | ||
|
重要な理由
行単位のクローズを追跡すると、注文全体が完了する前に、部分出荷や特定の商品または履行経路に関する問題を分析できます。
入手先
OE_ORDER_LINES_ALLテーブルでFLOW_STATUS_CODEが「CLOSED」に更新された際に記録されます。このステータス変更におけるLAST_UPDATE_DATEをタイムスタンプとして使用できます。
取得
OE_ORDER_LINES_ALLでFLOW_STATUS_CODEが「CLOSED」になった更新時点のタイムスタンプです。
イベントタイプ
explicit
|
|||
|
顧客への請求書送付
|
請求書が印刷または電子的な手段で顧客に送信された時点を示します。作成とは別の明示的なイベントとして常に記録されるとは限らないため、通常は推定します。 | ||
|
重要な理由
顧客の支払条件の起算点となる正式な開始時点です。請求書の作成から送付までの遅延は、キャッシュフローに悪影響を与え、支払いの遅延につながる可能性があります。
入手先
RA_CUSTOMER_TRX_ALLテーブルのLAST_PRINTED_DATEから推定できます。電子請求書の場合は、外部の文書配信システムのログを確認する必要があります。
取得
RA_CUSTOMER_TRX_ALLのLAST_PRINTED_DATEまたはサードパーティツールのログを使用します。
イベントタイプ
inferred
|
|||
抽出ガイド
始める準備はできましたか?
このテンプレートには、受注から入金まで:販売注文処理の改善を始めるために必要な情報がそろっています。今すぐプロセスの改善に取り組み、効率を大きく高めてください。
受注から入金までの販売処理を今すぐ改善
非効率な箇所を特定し、受注から入金までのサイクルタイムを30%短縮します。
クレジットカードは不要です。14日間無料でお試しいただけます。