受注から入金まで:販売注文処理のデータテンプレート
受注から入金まで:販売注文処理のデータテンプレート
- 収集を推奨する属性
- 分析で追跡する主要なアクティビティ
- データ抽出の手引き
受注から入金まで:販売注文処理の属性
| 名前 | 説明 | ||
|---|---|---|---|
|
アクティビティ名
ActivityName
|
販売注文のライフサイクルで発生した、特定の業務イベントまたはステップの名前です。 | ||
|
説明
この属性には、販売注文に対して実行された各アクティビティの名前が記録されます。たとえば、「受注確定」「商品出荷」「支払い受領」などです。これらのアクティビティは、受注から入金までのプロセスにおける主な節目を表します。 アクティビティの順序や頻度を分析することは、プロセスマイニングの中心となる作業です。一般的な経路や逸脱、ボトルネックを含め、実際のプロセスの流れを明らかにできます。このデータからプロセスマップを作成し、プロセス分析の主な可視化手段として利用します。
重要な理由
プロセスマップのステップを定義し、プロセスの流れを可視化・分析するために欠かせません。
入手先
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
|
顧客の販売注文を一意に識別する番号で、受注から入金までのプロセスにおける主要なケースとして機能します。 | ||
|
説明
販売注文番号は、作成から最終クローズまで、ライフサイクル全体を通じて顧客の各注文を一意に識別します。受注確定、出荷、請求、支払いなど、関連するすべてのアクティビティを結び付ける軸となります。 プロセスマイニングでは、この属性を使って各注文の一連の流れを再構成します。すべてのイベントを1つの販売注文にまとめることで、分析担当者はプロセス全体を可視化し、注文ごとの違いを特定できます。また、サイクルタイムや納期遵守などの重要業績評価指標を、ケース単位で測定できます。
重要な理由
これはケース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列にあります。
例
確定済み出荷待ち出荷済みクローズキャンセル済み
|
|||
|
受注総額
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
|
顧客が商品やサービスの代金を支払う時期を定めた合意条件です。 | ||
|
説明
支払条件は、請求書の支払い条件を定めるものです。たとえば、「30日以内」「60日以内」「受領時払い」などがあります。売掛金とキャッシュフローの管理に欠かせない属性です。 支払条件別にプロセスのパフォーマンスを分析すると、特定の条件の顧客で支払い遅延が起きやすいかを把握できます。この情報は、財務リスクの評価、回収方針の見直し、支払条件の選択肢の効果測定に役立ちます。「支払条件の遵守状況モニタリング」ダッシュボードの主要な分析軸です。
重要な理由
支払い傾向の分析、キャッシュフローの監視、顧客との契約条件に伴う財務リスクの評価に役立ちます。
入手先
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テーブルと結合し、取引先名を取得します。
例
グローバルテック株式会社イノベートソリューションズ合同会社パイオニア株式会社
|
|||
|
キャンセル理由
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
|
|||
|
受注数量
OrderQuantity
|
特定の販売注文の明細で注文された製品の数量です。 | ||
|
説明
この属性は、販売注文の明細で顧客が希望した製品の数量を示します。明細単位で取引量を表します。 受注数量を分析軸にすると、注文規模によってプロセスの動きが変わるかを確認できます。たとえば、非常に大きな注文や小さな注文では、異なる経路をたどったり、異なる種類の遅延が発生したりする場合があります。受注金額など、他の指標を理解する際の参考にもなります。
重要な理由
受注規模を把握し、注文量がプロセスの効率や履行経路に与える影響を分析できます。
入手先
OE_ORDER_LINES_ALLテーブルのORDERED_QUANTITYフィールドにあります。
例
102501
|
|||
|
手戻りの有無
IsRework
|
確認や更新のアクティビティが繰り返されるなど、販売注文に手戻りがあったかどうかを示すフラグです。 | ||
|
説明
手戻りを示すパターンを含むケースにフラグを付ける、計算による真偽値属性です。プロセスマップ上のループ、たとえば同じ受注が複数回確定されている状態や、システムに記録された特定の変更イベントから手戻りを特定できます。 このフラグは、販売注文の手戻り率の重要業績評価指標(KPI)の算出や、「販売注文の手戻り分析」ダッシュボードに使います。標準的なプロセスから外れた受注を簡単に抽出して調べられるため、手戻りがサイクルタイムやコストに与える影響を定量化し、非効率なループの根本原因を特定できます。
重要な理由
手作業での変更が必要だった受注にフラグを付け、プロセスの非効率を定量化できます。手戻りの原因と影響の分析にも役立ちます。
入手先
データ変換時に、ループを示すアクティビティの並びを特定して算出します(例:同じケースで「受注確定」が複数回発生する)。
例
truefalse
|
|||
|
支払期日遵守
IsPaymentOnTime
|
請求書の支払期日までに支払いを受領したかどうかを示すフラグです。 | ||
|
説明
対応する請求書の「支払い受領」アクティビティのタイムスタンプと「支払期日」を比較して算出する、真偽値属性です。支払条件が守られたかどうかを簡潔に示します。 このフラグは、支払条件遵守率の重要業績評価指標(KPI)の基礎となります。顧客の支払い傾向や売掛金管理プロセスの効果を監視するダッシュボードやレポートを簡単に作成できます。期日どおりの支払いと遅延した支払いをすばやく分類し、顧客の種類や支払条件など、影響する要因を分析できます。
重要な理由
支払条件の遵守状況を直接測定できるため、キャッシュフローの管理や顧客の支払い能力の評価に役立ちます。
入手先
計算フィールドです。ロジック:IF(「支払い受領」のEventTime <= PaymentDueDate)THEN True ELSE False。
例
truefalse
|
|||
|
納期遵守
IsOnTimeDelivery
|
確定納品日までに納品されたかどうかを示すフラグです。 | ||
|
説明
この計算属性は、受注が納品の約束を守ったかどうかを示す真偽値(True/False)です。「商品納品」アクティビティのタイムスタンプと「確定納品日」を比較して算出します。 この属性は、納期遵守率の重要業績評価指標(KPI)に直接役立ちます。受注ごとの結果を明確に示すため、分析やダッシュボードの作成が簡単になります。また、遅延した納品に共通する製品、顧客、配送方法などを絞り込み、集計できます。
重要な理由
顧客サービスの水準と履行の信頼性を直接測定でき、納期遵守の重要業績評価指標(KPI)の算出や可視化も簡単になります。
入手先
計算フィールドです。ロジック:IF(「商品納品」の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
|
顧客への商品の輸送に使う方法または運送業者です。 | ||
|
説明
この属性は、配送に使う輸送手段やサービス水準を示します。たとえば、「陸上貨物輸送」「航空便(速達)」「地域配送業者」などです。納品までの時間とコストの両方に影響する要素です。 この属性を使ってプロセスを分析すると、配送方法ごとのパフォーマンスを評価できます。たとえば、「配送方法別パフォーマンス」ダッシュボードでは、各方法について「商品出荷」から「商品納品」までのサイクルタイムを比較し、速度、コスト、信頼性のバランスを考慮した物流の見直しに役立てます。
重要な理由
運送業者や配送方法ごとのパフォーマンスを評価し、コスト、速度、信頼性のバランスを考慮した見直しに役立ちます。
入手先
通常、WSH_DELIVERY_DETAILSやOE_ORDER_LINES_ALLなどのテーブルにSHIPPING_METHOD_CODEとして保存されています。
例
UPS陸上便FedEx優先翌日配送DHLエクスプレス・ワールドワイド
|
|||
受注から入金まで:販売注文処理のアクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
|
入金
|
顧客からの支払いを受領し、システム上で該当する請求書に充当した時点で発生するアクティビティです。売掛金管理モジュールに明示的な財務取引として記録されます。 | ||
|
重要な理由
キャッシュフロー、売上債権回転日数(DSO)、支払条件の遵守状況を追跡するうえで重要な節目です。財務サイクルタイムを測定する際の主要な終点となります。
入手先
AR_RECEIVABLE_APPLICATIONS_ALLテーブルに明示的に記録されます。APPLY_DATE列には、入金が請求書に充当された時点のタイムスタンプが記録されています。
記録
該当する請求書について、AR_RECEIVABLE_APPLICATIONS_ALLのAPPLY_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
|
|||
|
注文確定
|
販売注文が正式に確定され、アクティブになり、調達や出荷などの後続処理に進める状態を示します。Oracle EBSで注文のステータスが「Entered」から「Booked」に変わる明示的な操作です。 | ||
|
重要な理由
注文確定は、履行に向けて注文を正式に確定する重要な節目です。作成から確定までの遅れは、データ入力、承認、初期検証に問題があることを示す場合があります。
入手先
OE_ORDER_HEADERS_ALLテーブルから取得します。BOOKED_FLAGが「Y」に設定された時点でイベントが発生し、タイムスタンプはBOOKED_DATE列に記録されます。
記録
OE_ORDER_HEADERS_ALLテーブルのBOOKED_DATEを使用します。
イベントタイプ
explicit
|
|||
|
請求書作成
|
出荷した商品の売掛金請求書が作成されたことを示すイベントです。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
|
|||
|
ピッキング指示
|
販売注文の明細行が倉庫にリリースされ、ピッキングを開始できる状態になったことを示すイベントです。ピッキングリストを作成し、倉庫担当者が注文を確認できるようにする明示的な操作です。 | ||
|
重要な理由
このアクティビティを起点に、実際の履行作業が始まります。この時点から「商品出荷」までの時間を分析すると、倉庫内の作業効率やピッキングのボトルネックを把握できます。
入手先
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ではこのイベントを追跡しないため、通常は外部の運送会社システムから推定するか、データを取り込む必要があります。 | ||
|
重要な理由
期日どおりの納品に関する重要業績評価指標を測定し、顧客体験全体を把握するうえで欠かせません。出荷から納品までの差から、運送会社の実績を確認できます。
入手先
システムの分析が必要です。このデータはOracle EBSに標準では含まれていないため、外部の運送会社のデータフィード、またはシステムと連携する物流プラットフォームから取得する必要があります。
記録
外部の運送会社のデータから推定するか、「商品出荷」後の標準的な輸送時間に基づいて算出します。
イベントタイプ
inferred
|
|||
|
注文キャンセル
|
履行が完了する前に販売注文全体がキャンセルされたことを示します。注文処理のワークフローを終了させる明示的なイベントです。 | ||
|
重要な理由
これは重要な例外の終点です。キャンセルの頻度、タイミング、理由を分析することは、売上の損失やプロセス・製品上の問題を特定するうえで欠かせません。
入手先
FLOW_STATUS_CODEが「CANCELLED」、CANCELLED_FLAGが「Y」に設定されたときに、OE_ORDER_HEADERS_ALLテーブルに記録されます。タイムスタンプには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日間の無料トライアルをご利用いただけます。