受注から入金まで:販売注文処理のデータテンプレート

Oracle Fusion Financials
受注から入金まで:販売注文処理のデータテンプレート

受注から入金まで:販売注文処理のデータテンプレート

このテンプレートでは、受注から入金まで:販売注文処理を分析するために必要なデータを収集する手順を整理しています。収集すべき重要な属性と追跡すべき主要なアクティビティを示し、プロセス全体を把握するために必要なデータを確実に揃えられるようにします。ソースシステムからデータを抽出するための具体的なガイダンスも記載しているため、すぐに始められます。
  • 収集を推奨する属性
  • 追跡すべき主要なアクティビティ
  • データ抽出に関する具体的なガイダンス
イベントログを初めて扱いますか。学ぶ プロセスマイニングのイベントログを作成する方法.

受注から入金まで:受注処理の属性

受注から入金までの受注処理を詳しく分析し、インサイトを得るために、イベントログに含める推奨データ項目です。
3 必須 8 推奨 12 任意
名前 説明
受注
SalesOrder
受注から入金までのプロセスにおける主要なケースとなる、受注の一意の識別子です。
説明

受注番号は、顧客注文をライフサイクル全体にわたって一意に識別します。初回の作成と確定から、フルフィルメント、請求、最終的な入金まで、関連するすべてのアクティビティをつなぐ中心的な識別子です。

プロセスマイニングでは、関連するすべてのイベントを1つのケースにまとめるために、この属性が欠かせません。受注単位でプロセスを分析すると、エンドツーエンドの全体像を把握でき、総サイクルタイムの計算、個々の注文におけるプロセスバリアントの特定、部門やシステムをまたぐ注文の流れの追跡が可能になります。

重要な理由

これはCase IDです。すべてのプロセスイベントを関連付け、1件の顧客注文のエンドツーエンドの流れを追跡できるようにします。

入手先

通常、Oracle Fusionの受注ヘッダーテーブル(DOO_HEADERS_ALLなど)にあります。Oracle Fusion Financialsのドキュメントを参照してください。

SO-100567SO-100568SO-100569
アクティビティ名
ActivityName
受注プロセス内で発生した特定のビジネスイベントまたはタスクの名称です。
説明

この属性は、受注に対して特定の時点で実行されたステップを示します。例として、「受注作成」、「商品の出荷」、「入金受領」などがあります。これらのアクティビティの順序が、各ケースのプロセスフローを形成します。

ActivityNameの分析は、プロセスマイニングの基本です。プロセスマップの可視化、さまざまなプロセスバリアントの発見、ケースが滞留するボトルネックの特定に役立ちます。また、ステップ間の遷移時間を計算し、受注から入金までのプロセスにおける業務の順序を把握する基盤となります。

重要な理由

この属性はプロセスマップ上のステップを定義し、プロセスフローを可視化して分析できるようにします。

入手先

さまざまなOracle Fusionテーブルの取引ステータスやイベントタイプ(注文ステータス、出荷ステータス、請求ステータスなど)を、標準化されたアクティビティ名の一覧にマッピングして作成する派生属性です。

受注作成商品の出荷請求書作成入金受領
イベント時刻
EventTime
受注に対して特定のアクティビティまたはイベントが発生した時点を示すタイムスタンプです。
説明

この属性はプロセス内の各アクティビティの日付と時刻を示し、イベントの時系列を確立します。各ステップがいつ発生したかを正確に記録する、プロセス分析の時間的な基盤です。

プロセスマイニングでは、EventTimeがサイクルタイム、アクティビティ間の所要時間、ケース全体のリードタイムを計算するうえで欠かせません。パフォーマンス分析、待ち時間に基づくボトルネック検出、サービスレベル合意(SLA)に関するコンプライアンスの監視を可能にします。時間に基づくすべてのKPIとダッシュボードは、この属性の正確性に依存します。

重要な理由

このタイムスタンプは、イベントを時系列に並べ、サイクルタイムや所要時間など、時間に基づくすべての指標を計算するうえで欠かせません。

入手先

さまざまなOracle Fusionテーブルにあるタイムスタンプ項目(注文作成日、出荷日、請求日、支払日など)から取得する派生属性です。

2023-04-15T09:00:00Z2023-04-18T14:30:00Z2023-04-20T11:25:00Z
ユーザー名
UserName
アクティビティを実行したユーザーの名前またはIDです。
説明

この属性は、特定のプロセスステップを実行した従業員またはシステムユーザーを識別します。ユーザー単位のパフォーマンス、業務量の分布、標準手順の遵守状況を分析できます。

ユーザー別に分析すると、トレーニングの必要性を特定し、高い成果を上げている個人やチームを把握できます。また、特定のユーザーに起因する逸脱の調査や、誰がどの操作を実行したかを追跡するコンプライアンスおよび監査にも役立ちます。

重要な理由

ユーザー別のパフォーマンス、業務量の分布、個人に関連する手作業の手戻りパターンを分析できます。

入手先

通常、Oracle Fusionの取引テーブルにあるCREATED_BYやLAST_UPDATED_BYなどの項目から取得し、FND_USERなどのユーザーマスターテーブルと関連付けます。

john.smithjane.doesystem_batch_user
受注合計金額
SalesOrderTotalAmount
受注の合計金額です。
説明

この属性は、受注全体について顧客に請求する合計金額を示します。すべての明細、税金、その他の料金の合計が含まれ、割引適用前の金額です。

プロセス分析では、金額に基づくプロセスマイニングに欠かせません。注文を高額と低額などに分け、異なるプロセス経路やサイクルタイムがあるかを確認できます。また、金銭的な影響が大きいケースを優先してプロセス改善に取り組む際にも役立ちます。

重要な理由

財務的な影響を分析し、高額注文に対するプロセス改善の優先順位付けや、コスト要因の把握に役立ちます。

入手先

通常、Oracle Fusionの受注ヘッダーテーブルにあります。Oracle Fusion Financialsのドキュメントを参照してください。

5250.00125000.75980.50
実納品日
ActualDeliveryDate
商品が実際に顧客へ納品された日付です。
説明

この属性は最終的な納品日を記録し、プロセスにおけるフルフィルメント部分の完了を示します。計画日または希望納品日と比較する実績値です。

この日付をRequestedDeliveryDateと比較して、納期遵守のパフォーマンスを計算します。「納期遵守率」KPIと「納品SLA」ダッシュボードに欠かせない入力値であり、物流およびサプライチェーンの有効性を明確に測定できます。

重要な理由

納期遵守率の計算と、顧客の希望に対するフルフィルメントのパフォーマンス評価に使用する実績日です。

入手先

Oracle Fusionの出荷および納品取引テーブルから取得します。Oracle Fusion Financialsのドキュメントを参照してください。

2023-05-202023-06-032023-05-25
希望納品日
RequestedDeliveryDate
顧客が希望する注文商品の納品日です。
説明

この属性は、顧客が商品の受け取りを希望する日付を記録します。受注から入金までのプロセスにおけるフルフィルメント部分の主要な目標値です。

「納期遵守率」KPIの計算や、「納品サービスレベル合意(SLA)」ダッシュボードを支えるうえで欠かせません。この日付とActualDeliveryDateを比較することで、組織が顧客の期待に応えられているかを測定し、納品遅延の根本原因を特定できます。

重要な理由

納期遵守のパフォーマンスと顧客サービスレベル合意(SLA)のコンプライアンスを測定する基準となります。

入手先

通常、Oracle Fusionの受注明細テーブルにあります。Oracle Fusion Financialsのドキュメントを参照してください。

2023-05-202023-06-012023-05-25
支払期日
PaymentDueDate
顧客が請求書の支払いを完了する必要がある日付です。
説明

支払期日は、請求書の日付と顧客との合意済み支払条件に基づいて計算されます。期限内の入金回収に向けた締切日となります。

この属性は「支払期日遵守率」KPIに欠かせません。PaymentDueDateと実際の入金日を比較することで、支払いが期日どおりか遅延しているかを判定し、売掛金業務のパフォーマンスを監視してキャッシュフローを管理できます。

重要な理由

期限内の支払率を計算する基準日となり、キャッシュフロー効率を測る主要な指標です。

入手先

Oracle Fusionの売掛金または請求書テーブル(AR_PAYMENT_SCHEDULES_ALLなど)にあります。

2023-06-192023-07-012023-06-25
自動処理かどうか
IsAutomated
アクティビティがシステムによって自動的に実行されたか、ユーザーが手動で実行したかを示すフラグです。
説明

この真偽値属性は、システム主導のイベント(自動与信確認やシステム生成請求書など)と、ユーザーによる手動操作を区別します。通常、アクティビティに関連付けられたユーザー名から導出し、汎用的なシステムIDであれば自動処理と判定します。

この属性を分析すると、プロセスの自動化レベルを測定できます。また、「手作業で手戻りとなった注文の割合」KPIへの直接的な入力値となります。時間がかかる、またはエラーが発生しやすい手動ステップを明らかにし、さらなる自動化の機会を特定できます。

重要な理由

プロセスの自動化レベルを定量化し、コストのかかる手作業を減らす機会を特定できます。

入手先

通常、UserName属性に適用するルールに基づく派生項目です。たとえば、ユーザーが「SYSTEM」または「BATCH」の場合、このフラグはtrueに設定されます。

truefalse
販売チャネル
SalesChannel
受注を受け付けたチャネルです。
説明

この属性は、Web、直販、パートナー、EDIなど、受注の発生元を分類します。注文がどのように組織へ入ったかを把握するための情報です。

販売チャネル別にプロセスを分類することは、「販売チャネルパフォーマンス概要」ダッシュボードに欠かせません。チャネルごとの効率、サイクルタイム、エラー率を比較し、最も効果的なチャネルや、プロセス改善またはさらなる自動化が必要なチャネルを特定できます。

重要な理由

チャネル別のパフォーマンス分析を支援し、注文処理の効率が高いチャネルと低いチャネルを特定できます。

入手先

通常、受注ヘッダーの専用項目に保存されます。Oracle Fusion Financialsのドキュメントを参照してください。

直販WebポータルEDI再販業者
顧客名
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-EMEAGlobal Services
最終データ更新日時
LastUpdateDate
このイベントのデータがソースシステムから最後に更新された時点を示すタイムスタンプです。
説明

この属性は、プロセスマイニング用データセットのデータが最後に抽出または更新された時点を記録します。分析対象データの鮮度を明確に把握できます。

この情報は、プロセス分析がどの程度最新の状態かを理解するうえで重要です。データの適時性に関する期待値を管理し、データ更新スケジュールの設定と監視にも役立ちます。

重要な理由

データの鮮度を示し、プロセス分析がどの程度最新の状態かを把握できるようにします。

入手先

データ抽出および変換のサイクルごとに生成され、データセットに付与されます。

2023-10-27T02:00:00Z2023-10-28T02:00:00Z
出荷方法
ShippingMethod
顧客に商品を出荷する際に使用する方法または配送業者です。
説明

この属性は、陸上輸送、航空速達、地域配送など、納品に使用する物流業者またはサービスレベルを示します。

「出荷方法の納品コンプライアンス」ダッシュボードに欠かせない情報です。出荷方法や配送業者ごとの納期遵守率と出荷コストを比較し、物流戦略や業者選定の改善に役立てられます。

重要な理由

異なる配送業者や出荷方法のパフォーマンスを比較でき、物流分析を直接支援します。

入手先

Oracle Fusionの出荷およびフルフィルメントテーブルで利用できます。Oracle Fusion Financialsのドキュメントをご確認ください。

FedEx GroundUPS Next Day AirDHL International
商品名
ProductName
販売する商品またはサービスの名称です。
説明

この属性は、受注明細に含まれる商品を示します。複数の明細がある注文では、明細単位でケースを分析することも、ヘッダーレベルでこの属性を集計することもできます。

商品別に分析すると、特定の商品で、納品遅延や支払問題が頻発するなど、より複雑または問題の多いプロセスフローが発生しているかを把握できます。商品管理やサプライチェーン戦略の検討に役立ちます。

重要な理由

商品ごとのプロセスパフォーマンスを分析し、フルフィルメントや請求経路が複雑な商品を特定できます。

入手先

受注明細テーブルから取得し、商品マスターテーブルと結合します。Oracle Fusion Financialsのドキュメントを参照してください。

Standard Widget X1Premium Service PackageComponent Y2-B
支払い条件
PaymentTerms
顧客との間で合意した支払い条件です。
説明

この属性は、顧客が請求書を支払う条件を示します。たとえば、「30日後払い」や「60日後払い」などです。これらの条件はPaymentDueDateの計算基準になります。

支払い条件別に分析すると、支払いサイクルタイムの違いを説明しやすくなります。また、条件によって支払い行動が自然に異なるため、「期限内支払い率」KPIを解釈する際の背景情報になります。与信方針やキャッシュフロー予測にも役立ちます。

重要な理由

支払い行動の分析に重要な背景情報を提供し、請求から支払いまでのサイクルタイムの違いを説明しやすくします。

入手先

Oracle Fusionの販売注文または顧客アカウントのレベルで利用できます。Oracle Fusion Financialsのドキュメントをご確認ください。

Net 30Net 60受領時支払い
支払い遅延かどうか
IsLatePayment
支払期日を過ぎてから支払いを受領した場合に真となる計算フラグです。
説明

この真偽値属性は、実際の支払受領日とPaymentDueDateを比較して算出します。請求書が期限内に支払われたかどうかを明確に示します。

この属性は「期限内支払い率」KPIの計算に使います。期限内支払いと遅延支払いを簡単に分けて分析できるため、支払いが遅れる顧客の特徴、遅延の主な理由、運転資本への財務的影響を把握できます。

重要な理由

支払い回収の有効性を直接測定し、延滞支払いの分析を簡単にします。

入手先

計算項目です。ロジックは次のとおりです:PaymentReceivedDate > PaymentDueDate。

falsetrue
期限内納品かどうか
IsOnTimeDelivery
実際の納品日が希望納品日以前であれば真となる計算フラグです。
説明

この真偽値属性は、ActualDeliveryDateとRequestedDeliveryDateを比較して算出します。納品パフォーマンスをケース単位で簡潔に示します。

このフラグは、集計された「期限内納品率」KPIの計算基盤です。フィルタリングと分析が容易になり、遅延した注文をすばやく抽出して、遅延要因の根本原因を分析できます。

重要な理由

顧客の期待に対するフルフィルメントのパフォーマンスを直接測定し、遅延注文の分析を簡単にします。

入手先

計算項目です。ロジックは次のとおりです:ActualDeliveryDate <= RequestedDeliveryDate。

truefalse
注文タイプ
OrderType
「標準注文」や「返品注文」など、販売注文を分類する項目です。
説明

注文タイプは、販売注文を業務上の目的に応じて分類するために使います。一般的なタイプには、標準販売、サービス注文、返品承認(RMA)、社内注文があります。

注文タイプ別にプロセスを分析することが重要なのは、タイプごとにプロセスフローや目標パフォーマンスが異なる場合が多いためです。この切り分けにより、意図された想定内のプロセス差異を把握し、逸脱と誤って解釈することを防げます。

重要な理由

異なる正当なプロセスフロー(標準注文と返品注文など)を分けて分析できるため、公平で正確な分析が可能になります。

入手先

通常、Oracle Fusionの販売注文ヘッダーテーブルの項目として利用できます。Oracle Fusion Financialsのドキュメントをご確認ください。

標準販売注文返品承認サービス注文
請求書が訂正済みかどうか
IsInvoiceCorrected
請求書が初回作成後に訂正または改訂されたかどうかを示すフラグです。
説明

この真偽値属性は、「請求書訂正」アクティビティの存在によって示される訂正ループが請求書に発生した場合に真となります。請求段階で手戻りが発生したケースを示します。

「請求書の正確性と手戻り分析」ダッシュボードおよび「請求書手戻り率」KPIの重要な入力項目です。請求ミスの程度を定量化し、訂正が必要になった理由を根本原因分析で特定できます。手作業と支払い遅延の削減にもつながります。

重要な理由

請求書の手戻りを特定します。これは、プロセスの非効率、データ品質の問題、支払い遅延の可能性を示す重要な指標です。

入手先

計算項目です。通常、イベントログに「請求書訂正」アクティビティが存在するケースで真に設定します。

falsetrue
請求書番号
InvoiceNumber
顧客請求書を一意に識別する番号です。
説明

この属性は、販売注文から生成された請求書に割り当てられる一意の番号です。販売およびフルフィルメントのアクティビティと、プロセスの決済部分を結び付けます。

販売注文が主なケースIDである一方、請求書番号は請求および支払いのサブプロセスを分析するうえで欠かせません。請求書の訂正、異議申し立て、支払い状況を追跡するために必要であり、「請求書の正確性と手戻り分析」などのダッシュボードを支えます。

重要な理由

売掛金プロセスへの重要な紐付けを提供し、請求書の手戻りや支払いサイクルの分析に必要です。

入手先

Oracle Fusionの売掛金取引テーブル(RA_CUSTOMER_TRX_ALLなど)で利用できます。

INV-93485INV-93486INV-93487
顧客の国
CustomerCountry
顧客が所在する国です。
説明

この属性は、顧客の出荷先住所または請求先住所に基づく国を示します。地理的な分析における重要な切り口です。

国別にプロセスを分けて分析すると、プロセスのパフォーマンス、サイクルタイム、支払い行動における地域差を明らかにできます。現地の規制、物流上の課題、市場環境が受注から入金までのプロセスに与える影響を把握するうえで役立ちます。

重要な理由

地域ごとのプロセス効率、コンプライアンス、顧客行動の違いを特定する地理的な分析が可能になります。

入手先

販売注文に紐付いた顧客マスターデータテーブル(HZ_LOCATIONS、HZ_PARTY_SITES)から取得します。

USAドイツ日本
必須 推奨 任意

受注から入金まで:受注処理のアクティビティ

正確なプロセスディスカバリーとパフォーマンス評価に向けて、イベントログに記録すべき主要なプロセス手順と節目です。
6 推奨 8 任意
アクティビティ 説明
入金受領
顧客からの入金を受領し、売掛金で請求書に充当したことを示します。入金充当が転記された時点で記録されます。
重要な理由

「受注から入金までのサイクルタイム全体」と「支払期日遵守率」を測定する重要なマイルストーンです。販売を現金に変換したことを示します。

入手先

Oracle Accounts Receivableにおける明示的なイベントです。入金が請求書に充当されると、AR_RECEIVABLE_APPLICATIONS_ALLなどの入金テーブルに記録されます。

取得

ARにおける入金充当レコードの「充当日」タイムスタンプから取得します。

イベントタイプ explicit
受注作成
このアクティビティは受注プロセスの開始を示し、Oracle Fusionに新しい受注が入力された時点を表します。通常、Order Managementモジュールでユーザーが新しい注文レコードを保存した際に、明示的に記録されます。
重要な理由

プロセスの開始点となるこのアクティビティは、受注から入金までのサイクルタイム全体を測定し、受注量を分析するうえで欠かせません。

入手先

Order Management Cloudで受注レコードが作成された時点に明示的に記録されます。DOO_HEADERS_ALLテーブルの作成日時を確認してください。

取得

受注ヘッダーレコードの作成日時から取得します。

イベントタイプ explicit
商品の出荷
商品が倉庫から発送され、顧客に向けて輸送中となった時点を示します。Oracle Shippingで出荷確認取引が処理された際に記録されます。
重要な理由

フルフィルメント部分の完了を示し、請求処理を開始する重要なマイルストーンです。出荷および納品の納期遵守率を測定するうえで欠かせません。

入手先

Oracle Shipping Executionに明示的に記録されるイベントです。出荷確認取引により、出荷日を含むレコードがWSH_DELIVERY_DETAILSなどの出荷テーブルに作成されます。

取得

注文行に関連付けられた配送明細レコードの「実出荷日」タイムスタンプから取得します。

イベントタイプ explicit
注文クローズ
プロセスの最終アクティビティです。受注のすべての明細がフルフィルメント、請求、クローズまで完了したことを示します。注文ヘッダーのステータスが「クローズ」に更新されます。
重要な理由

このアクティビティは、受注ライフサイクルが正常に完了したことを示します。エンドツーエンドのプロセス所要時間を計算し、最後までクローズされない滞留注文を特定するうえで欠かせません。

入手先

DOO_HEADERS_ALLテーブルで、受注ヘッダーのステータスが「クローズ」に変更されたことから推定します。この最終ステータス変更のタイムスタンプがイベント時刻となります。

取得

受注ヘッダーのステータスが「クローズ」に変更された時点のタイムスタンプから導出します。

イベントタイプ inferred
注文確定
この重要なマイルストーンは、受注が与信承認を含むすべての初期確認を通過し、フルフィルメントの対象として確定したことを示します。通常、注文ステータスが「出荷待ち」や「スケジュール済み」などに進んだことから推定します。
重要な理由

このアクティビティは「平均注文確定時間」の計算における重要なマイルストーンであり、受注入力からフルフィルメントプロセスへの引き継ぎを示します。

入手先

受注ヘッダーまたは明細のステータスが、フルフィルメントの準備完了を示す値(例:「出荷待ち」)に変更されたことから推定します。DOO_HEADERS_ALLまたはDOO_FULFILL_LINES_ALLのステータス列を確認してください。

取得

注文ステータスが確定済みまたはスケジュール済みの状態に変更された時点のタイムスタンプから導出します。

イベントタイプ inferred
請求書作成
通常は出荷確認イベントを契機として、売掛金モジュールで顧客請求書を作成することを示します。一意の番号と作成日を持つ請求書レコードが生成されます。
重要な理由

入金回収サイクルの正式な開始点を示します。「請求書から入金までの時間」とキャッシュフロー効率を測定する基準となります。

入手先

Oracle Accounts Receivable(AR)における明示的なイベントです。取引日を含む請求書レコードがRA_CUSTOMER_TRX_ALLテーブルに作成されます。

取得

ARモジュールにおける請求取引の作成日から取得します。

イベントタイプ explicit
与信保留の適用
与信確認に失敗した場合や、その他の与信関連の問題が発生した場合に、受注が自動または手動で保留されることで発生します。通常、システム内で注文の保留ステータスが変更されたことによって記録されます。
重要な理由

与信保留を追跡すると、注文処理の遅延原因を特定し、与信保留解除プロセスの効率を測定できます。

入手先

受注に保留が適用されたことから推定します。通常、受注に関連付けられたDOO_HOLDS_ALLなどの保留関連テーブルに記録されます。

取得

保留テーブルに「Credit」タイプのレコードが作成されたことから推定します。

イベントタイプ inferred
与信確認の実施
顧客の信用力を評価するため、顧客アカウントに対して与信確認を実行したことを示します。通常、注文処理ワークフロー内の自動または手動のステップであり、完了時にステータス更新または完了したタスクとして記録されます。
重要な理由

与信確認にかかった時間を分析すると、注文承認におけるボトルネックを特定できます。「与信確認から確定までの時間」KPIに欠かせない指標です。

入手先

受注が「与信承認待ち」などのステータスに移行したことによるステータス変更、または与信管理機能の明示的なイベントログから推定できます。

取得

注文ステータスの変更、または与信審査タスクに関連するタイムスタンプから推定します。

イベントタイプ inferred
商品のピッキング
注文に対応するため、倉庫から商品を実際にピッキングしたことを示します。物流プロセスにおける重要なステップであり、通常は倉庫管理または出荷モジュールに記録されます。
重要な理由

このアクティビティにより、倉庫業務の状況を把握できます。在庫引当からピッキングまでの遅延は、倉庫内のリソースまたはプロセス上のボトルネックを示す場合があります。

入手先

Oracle Fusion Cloud SCM(Supply Chain Management)モジュールに記録されます。受注明細に関連付けられたピックウェーブまたはピッキングリストのステータス変更から推定できます。

取得

SCMモジュールにおけるピッキング取引の完了タイムスタンプから推定します。

イベントタイプ inferred
商品の納品
顧客が出荷品を受け取ったことを示します。通常、外部の配送業者から情報を取得してOracle Fusionに反映するか、出荷日から標準輸送日数を用いて推定します。
重要な理由

このアクティビティは、「納期遵守率」KPIの計算と、顧客サービスレベルの正確な測定に欠かせません。

入手先

通常、Oracle固有のイベントではありません。配送業者との連携がある場合は記録できます。または、「商品の出荷」日付に標準輸送日数を加えて算出します。システム分析が必要です。

取得

配送業者からのデータフィード、または出荷日に平均輸送時間を加えた計算結果から推定します。

イベントタイプ inferred
在庫引当
このアクティビティは、受注明細を満たすために実在庫を割り当て、確保することを示します。注文のピッキング準備が整った時点で在庫を利用できるよう、システムが特定の在庫を確保します。
重要な理由

この指標を追跡すると、「在庫引当リードタイム」KPIを分析し、注文確定から商品の確保までに発生する遅延を特定できます。

入手先

通常、在庫またはサプライチェーン実行モジュールで記録されます。フルフィルメント明細のステータスが、在庫の明細化または引当済みを示す値に更新されたことから推定できます。

取得

在庫引当またはスケジューリングに関連するフルフィルメント明細のステータス変更から推定します。

イベントタイプ inferred
注文キャンセル
受注が完全に出荷される前にキャンセルされたことを示します。さまざまな理由で発生し、最終ステータスは「キャンセル済み」となります。
重要な理由

これは重要な例外経路です。キャンセルされた注文を分析すると、在庫切れ、価格の問題、顧客都合による変更などの根本原因を特定でき、プロセス改善に役立てられます。

入手先

受注ヘッダーまたは明細のステータスが「キャンセル済み」に変更されたことから推定します。このステータス変更のタイムスタンプをイベントの記録に使用します。

取得

注文ヘッダーまたは明細のステータスが「キャンセル済み」に変更された時点のタイムスタンプから導出します。

イベントタイプ inferred
注文行のクローズ
個々の受注明細を最終的にクローズしたことを示します。商品が完全に出荷され、請求書が発行され、以後の取引が見込まれない状態です。システムによって明細ステータスが「クローズ」に更新されます。
重要な理由

注文行をクローズすることは、その商品に関する契約上の義務がすべて完了したことを示します。分析により、フルフィルメントや入金が完了した後も長期間オープンのまま残る注文を特定できます。

入手先

DOO_FULFILL_LINES_ALLテーブルで、フルフィルメント明細のステータスが「クローズ」に変更されたことから推定します。このステータス変更のタイムスタンプがイベント時刻となります。

取得

フルフィルメント明細のステータスが「クローズ」に変更された時点のタイムスタンプから導出します。

イベントタイプ inferred
請求書の訂正
エラーや顧客との紛争により、作成済みの請求書を修正、再発行、またはクレジット処理した場合に発生します。通常、クレジットメモまたは請求書の新しいバージョンを作成することで記録されます。
重要な理由

請求書の訂正を追跡すると、「請求書手戻り率」KPIを把握できます。支払いを遅らせ、事務コストを増加させる請求プロセス上の問題を明らかにします。

入手先

元の請求書に関連付けられたクレジットメモ、またはRA_CUSTOMER_TRX_ALLテーブルにある同じ請求書の後続バージョンの作成から推定します。

取得

過去の請求取引を参照するクレジットメモまたは請求書を特定して導出します。

イベントタイプ inferred
推奨 任意

抽出ガイド

Oracle Fusion Financialsからデータを取得する方法

準備はできましたか?

このテンプレートを使ってデータ収集を効率化し、プロセスマイニングを始めましょう。今すぐ受注から入金まで:販売注文処理の最適化に取り組めます。

今すぐ受注から入金まで:販売注文処理を最適化

ボトルネックを特定し、受注から入金までのサイクルタイムを簡単に30%短縮できます。

無料トライアルを開始

クレジットカードは不要です。14日間無料でお試しいただけます。