受注から入金まで:販売注文処理のデータテンプレート
受注から入金まで:販売注文処理のデータテンプレート
- 収集を推奨する属性
- 追跡すべき主要なアクティビティ
- データ抽出に関する具体的なガイダンス
受注から入金まで:受注処理の属性
| 名前 | 説明 | ||
|---|---|---|---|
| 受注 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ドイツ日本 | |||
受注から入金まで:受注処理のアクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
| 入金受領 | 顧客からの入金を受領し、売掛金で請求書に充当したことを示します。入金充当が転記された時点で記録されます。 | ||
| 重要な理由 「受注から入金までのサイクルタイム全体」と「支払期日遵守率」を測定する重要なマイルストーンです。販売を現金に変換したことを示します。 入手先 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 BI Publisherに移動:BI AdministratorまたはBI Authorの権限を持つユーザーでOracle Fusion環境にログインします。Navigatorメニューから「Tools」>「Reports and Analytics」に移動します。「Browse Catalog」をクリックしてBusiness Intelligence Catalogを開きます。
- 新しいData Modelを作成:BI Catalogで適切なフォルダー(例:Shared Folders > Custom)に移動します。「New」ドロップダウンメニューをクリックし、「Data Model」を選択します。
- SQL Queryデータセットを定義:Data Modelエディターで「+」アイコンをクリックして新しいデータセットを作成し、「SQL Query」を選択します。ダイアログボックスが表示されます。データセット名(例:'OrderToCash_EventLog')を入力し、Data Sourceに「Oracle BI EE」、SQLの種類に「Standard SQL」を選択します。
- SQL Queryを入力:このドキュメントの「query」セクションに記載された完全なSQL Queryをコピーし、SQL Queryのテキスト領域に貼り付けます。Queryには開始日と終了日(:p_start_dateおよび:p_end_date)のパラメーターが含まれており、BI Publisherによって自動的に認識されます。
- Data Modelのプロパティを設定:Queryを貼り付けたら「OK」をクリックします。Data Modelエディターの左ペインで「Properties」セクションに移動します。「Include Parameter Tags」にチェックが入っていることを確認します。必要に応じて、日付パラメーターのデフォルト値も設定できます。
- Data Modelを表示して保存:「Data」タブをクリックします。日付パラメーターの入力を求められる場合があります。テスト用に短い期間を入力します。「View」をクリックしてデータのサンプルを確認します。データが正しく表示されたら、保存アイコンをクリックし、分かりやすい名前(例:'OrderToCash_EventLog_DM')を付けてData Modelを保存します。
- Data Modelからレポートを作成:Data Modelを保存した状態で、右上の「Create Report」ボタンをクリックします。レポート作成ウィザードが開きます。
- レポートを設定:ウィザードで「Use Data Model」を選択します。ウィザードの案内に従ってレイアウトを設定します。単純なCSVエクスポートの場合は、「Table」レイアウトを選択できます。すべての列をテーブルにドラッグ&ドロップします。「Next」をクリックし、「Show Grand Totals Row」のチェックを外します。「Finish」をクリックしてレポートを保存します。'OrderToCash_EventLog_Report'などの名前を付けます。
- レポートを実行:作成したレポートを開きます。抽出する開始日と終了日の入力を求められます。希望する期間を指定します。
- データをエクスポート:レポートの実行後、「View」ドロップダウンをクリックし、「View Report」など別の表示オプションを選択します。次に「Export」リンクまたはアイコンを見つけ、エクスポート形式として「CSV」を選択します。イベントログファイルがダウンロードされます。
- アップロードの準備:ダウンロードしたCSVファイルを開きます。列見出しが必要な属性と一致していることを確認します:SalesOrder、ActivityName、EventTime、UserName、SalesOrderTotalAmount、CustomerName、SalesChannel、RequestedDeliveryDate、ActualDeliveryDate、PaymentDueDate、IsAutomated。これでファイルをプロセスマイニングツールにアップロードできます。
設定
- ユーザー権限:BI PublisherのData Modelとレポート作成権限を持つロール(「BI Administrator」または「BI Author」など)が必要です。
- データソース:Queryは、トランザクションデータベース(Fusion Apps)に接続する標準の「Oracle BI EE」アプリケーションデータソース向けに設計されています。通常、特別な設定は必要ありません。
- 日付範囲パラメーター:Queryでは、データを絞り込むために:p_start_dateと:p_end_dateの2つのパラメーターを使用します。レポートのタイムアウトやパフォーマンスの問題を避けるため、3~6か月など、管理しやすい単位でデータを抽出することを強く推奨します。
- Business Unitによる絞り込み:抽出範囲を限定するには、QueryのBaseOrders CTEにWHERE句を追加し、特定のBusiness Unit IDで絞り込めます(例:AND dhead.SUBMITTING_BU_ID IN ([Your Business Unit ID]))。
- 注文タイプによる絞り込み:BaseOrders CTEのdhead.SOURCE_ORDER_TYPE_CODEに条件を追加して、特定の販売注文タイプに絞り込むこともできます。
- パフォーマンス:数年分にわたる非常に大規模なデータセットでは、この単一Query方式の処理に時間がかかる場合があります。業務時間外に実行するか、月単位など小さなバッチに分けて抽出してください。Data Modelで「Enable SQL Pruning」が選択されていないことを確認してください。複雑なUNION Queryに影響する可能性があります。
a サンプルクエリ sql
WITH BaseOrders AS (
SELECT
dhead.HEADER_ID,
dhead.ORDER_NUMBER AS SalesOrder,
dhead.CREATION_DATE,
dhead.CREATED_BY,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = dhead.CREATED_BY AND ROWNUM = 1) AS UserName,
dhead.SUBMITTING_BU_ID,
dhead.AMOUNT AS SalesOrderTotalAmount,
hp_sold.PARTY_NAME AS CustomerName,
dhead.SALES_CHANNEL_CODE AS SalesChannel,
dfl.REQUEST_SHIP_DATE AS RequestedDeliveryDate
FROM
DOO_HEADERS_ALL dhead
JOIN
DOO_FULFILL_LINES_ALL dfl ON dhead.HEADER_ID = dfl.HEADER_ID
JOIN
HZ_CUST_ACCOUNTS hc_sold ON dhead.SOLD_TO_CUSTOMER_ID = hc_sold.CUST_ACCOUNT_ID
JOIN
HZ_PARTIES hp_sold ON hc_sold.PARTY_ID = hp_sold.PARTY_ID
WHERE
dhead.OBJECT_VERSION_NUMBER = 1
AND dfl.LINE_NUMBER = 1 -- To avoid duplicating header-level events for each line
AND dhead.CREATION_DATE BETWEEN TO_DATE(:p_start_date, 'YYYY-MM-DD') AND TO_DATE(:p_end_date, 'YYYY-MM-DD')
)
-- 1. Sales Order Created
SELECT
bo.SalesOrder,
'Sales Order Created' AS ActivityName,
bo.CREATION_DATE AS EventTime,
bo.UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN bo.CREATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM BaseOrders bo
UNION ALL
-- 2. Credit Check Performed (inferred from Credit Hold Release)
SELECT
bo.SalesOrder,
'Credit Check Performed' AS ActivityName,
dha.RELEASED_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = dha.RELEASED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN dha.RELEASED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM DOO_HOLDS_ALL dha
JOIN BaseOrders bo ON dha.HEADER_ID = bo.HEADER_ID
WHERE dha.HOLD_CODE = '[Your Credit Check Hold Code]' AND dha.RELEASED_FLAG = 'Y' AND dha.RELEASED_DATE IS NOT NULL
UNION ALL
-- 3. Credit Hold Applied
SELECT
bo.SalesOrder,
'Credit Hold Applied' AS ActivityName,
dha.APPLIED_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = dha.APPLIED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN dha.APPLIED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM DOO_HOLDS_ALL dha
JOIN BaseOrders bo ON dha.HEADER_ID = bo.HEADER_ID
WHERE dha.HOLD_CODE = '[Your Credit Check Hold Code]' AND dha.APPLIED_DATE IS NOT NULL
UNION ALL
-- 4. Order Confirmed (inferred from status 'Awaiting Shipping')
SELECT
bo.SalesOrder,
'Order Confirmed' AS ActivityName,
dfl.STATUS_CHANGE_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = dfl.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN dfl.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM DOO_FULFILL_LINES_ALL dfl
JOIN BaseOrders bo ON dfl.HEADER_ID = bo.HEADER_ID
WHERE dfl.STATUS_CODE = 'AWAIT_SHIP'
UNION ALL
-- 5. Inventory Reserved
SELECT
bo.SalesOrder,
'Inventory Reserved' AS ActivityName,
irl.LAST_UPDATE_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = irl.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN irl.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM INV_RESERVATIONS irl
JOIN DOO_FULFILL_LINES_ALL dfl ON irl.DEMAND_SOURCE_LINE_ID = dfl.FULFILL_LINE_ID
JOIN BaseOrders bo ON dfl.HEADER_ID = bo.HEADER_ID
WHERE irl.DEMAND_SOURCE_TYPE_ID = 2 -- Order Entry
UNION ALL
-- 6. Goods Picked (inferred from delivery detail status 'Staged')
SELECT
bo.SalesOrder,
'Goods Picked' AS ActivityName,
wdd.LAST_UPDATE_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = wdd.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN wdd.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM WSH_DELIVERY_DETAILS wdd
JOIN BaseOrders bo ON wdd.SOURCE_HEADER_NUMBER = bo.SalesOrder
WHERE wdd.RELEASED_STATUS = 'S' -- 'S' typically means Staged/Picked
UNION ALL
-- 7. Goods Shipped
SELECT
bo.SalesOrder,
'Goods Shipped' AS ActivityName,
wnd.INITIAL_PICKUP_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = wnd.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN wnd.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM WSH_NEW_DELIVERIES wnd
JOIN WSH_DELIVERY_ASSIGNMENTS wda ON wnd.DELIVERY_ID = wda.DELIVERY_ID
JOIN WSH_DELIVERY_DETAILS wdd ON wda.DELIVERY_DETAIL_ID = wdd.DELIVERY_DETAIL_ID
JOIN BaseOrders bo ON wdd.SOURCE_HEADER_NUMBER = bo.SalesOrder
WHERE wnd.STATUS_CODE = 'CL' -- Closed/Shipped
UNION ALL
-- 8. Goods Delivered
SELECT
bo.SalesOrder,
'Goods Delivered' AS ActivityName,
wnd.ULTIMATE_DROPOFF_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = wnd.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
wnd.ULTIMATE_DROPOFF_DATE AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN wnd.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM WSH_NEW_DELIVERIES wnd
JOIN WSH_DELIVERY_ASSIGNMENTS wda ON wnd.DELIVERY_ID = wda.DELIVERY_ID
JOIN WSH_DELIVERY_DETAILS wdd ON wda.DELIVERY_DETAIL_ID = wdd.DELIVERY_DETAIL_ID
JOIN BaseOrders bo ON wdd.SOURCE_HEADER_NUMBER = bo.SalesOrder
WHERE wnd.ULTIMATE_DROPOFF_DATE IS NOT NULL
UNION ALL
-- 9. Invoice Created
SELECT
bo.SalesOrder,
'Invoice Created' AS ActivityName,
rct.TRX_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = rct.CREATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
aps.DUE_DATE AS PaymentDueDate,
CASE WHEN rct.CREATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM RA_CUSTOMER_TRX_ALL rct
JOIN RA_CUSTOMER_TRX_LINES_ALL rctl ON rct.CUSTOMER_TRX_ID = rctl.CUSTOMER_TRX_ID
JOIN AR_PAYMENT_SCHEDULES_ALL aps ON rct.CUSTOMER_TRX_ID = aps.CUSTOMER_TRX_ID
JOIN BaseOrders bo ON rctl.INTERFACE_LINE_ATTRIBUTE1 = bo.SalesOrder
WHERE rctl.INTERFACE_LINE_CONTEXT = 'ORDER ENTRY' AND rctl.LINE_TYPE = 'LINE'
UNION ALL
-- 10. Invoice Corrected (Credit Memo)
SELECT
bo.SalesOrder,
'Invoice Corrected' AS ActivityName,
rct_cm.TRX_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = rct_cm.CREATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN rct_cm.CREATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM RA_CUSTOMER_TRX_ALL rct_cm
JOIN RA_CUSTOMER_TRX_LINES_ALL rctl_cm ON rct_cm.CUSTOMER_TRX_ID = rctl_cm.CUSTOMER_TRX_ID
JOIN RA_CUSTOMER_TRX_ALL rct_orig ON rct_cm.PREVIOUS_CUSTOMER_TRX_ID = rct_orig.CUSTOMER_TRX_ID
JOIN RA_CUSTOMER_TRX_LINES_ALL rctl_orig ON rct_orig.CUSTOMER_TRX_ID = rctl_orig.CUSTOMER_TRX_ID
JOIN BaseOrders bo ON rctl_orig.INTERFACE_LINE_ATTRIBUTE1 = bo.SalesOrder
WHERE rctl_orig.INTERFACE_LINE_CONTEXT = 'ORDER ENTRY' AND rctl_cm.LINE_TYPE = 'LINE'
UNION ALL
-- 11. Payment Received
SELECT
bo.SalesOrder,
'Payment Received' AS ActivityName,
araa.APPLY_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = araa.CREATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN araa.CREATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM AR_RECEIVABLE_APPLICATIONS_ALL araa
JOIN RA_CUSTOMER_TRX_ALL rct ON araa.APPLIED_CUSTOMER_TRX_ID = rct.CUSTOMER_TRX_ID
JOIN RA_CUSTOMER_TRX_LINES_ALL rctl ON rct.CUSTOMER_TRX_ID = rctl.CUSTOMER_TRX_ID
JOIN BaseOrders bo ON rctl.INTERFACE_LINE_ATTRIBUTE1 = bo.SalesOrder
WHERE araa.STATUS = 'APP' AND rctl.INTERFACE_LINE_CONTEXT = 'ORDER ENTRY' AND rctl.LINE_TYPE = 'LINE'
UNION ALL
-- 12. Order Line Closed
SELECT
bo.SalesOrder,
'Order Line Closed' AS ActivityName,
dfl.LAST_UPDATE_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = dfl.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN dfl.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM DOO_FULFILL_LINES_ALL dfl
JOIN BaseOrders bo ON dfl.HEADER_ID = bo.HEADER_ID
WHERE dfl.STATUS_CODE = 'CLOSED'
UNION ALL
-- 13. Order Closed
SELECT
bo.SalesOrder,
'Order Closed' AS ActivityName,
dhead.LAST_UPDATE_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = dhead.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN dhead.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM DOO_HEADERS_ALL dhead
JOIN BaseOrders bo ON dhead.HEADER_ID = bo.HEADER_ID
WHERE dhead.STATUS_CODE = 'CLOSED'
UNION ALL
-- 14. Order Cancelled
SELECT
bo.SalesOrder,
'Order Cancelled' AS ActivityName,
dhead.LAST_UPDATE_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = dhead.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN dhead.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM DOO_HEADERS_ALL dhead
JOIN BaseOrders bo ON dhead.HEADER_ID = bo.HEADER_ID
WHERE dhead.STATUS_CODE = 'CANCELED' ステップ
- BICCコンソールにアクセス:BICC_ADMINISTRATORロールを持つユーザーでOracle Fusion Applicationsインスタンスにログインします。Toolsに移動し、メニューからBusiness Intelligence Cloud Connectorを選択します。
- 新しいOfferingを作成:BICCコンソールで「Configure External Storage」をクリックし、保存先を設定します。保存先にはOracle Universal Content Management(UCM)またはOCI Object Storageバケットを指定できます。接続情報と認証情報が正しいことを確認します。
- 新しいExtract Jobを開始:「Manage Extract Jobs」セクションに移動します。「+」アイコンをクリックして新しいジョブを作成します。ProcessMind_O2C_SalesOrder_Extractなど、分かりやすい名前を付けます。
- Data Store(PVO)を選択:ジョブ設定で、販売注文のライフサイクルを記録するために必要なPublic View Objects(PVO)を検索して追加します。FscmTopModelAM.DooTopAM.Header、FscmTopModelAM.DooTopAM.FulfillLine、FscmTopModelAM.DooTopAM.HoldInstance、FscmTopModelAM.ScmTopAM.ShipmentLine、FscmTopModelAM.ArTopAM.ReceivableInvoice、FscmTopModelAM.ArTopAM.CashReceiptApplicationなど、複数のPVOを追加する必要があります。
- 各PVOの列を設定:選択した各PVOで「Actions」メニューをクリックし、「Select Columns」を選択します。イベントログの生成に必要なHeaderId、CreationDate、ShippedDate、TrxDate、ApplyDate、ユーザー識別子などの列を慎重に選択します。各PVOから必要な列の詳細な一覧は、Queryマニフェストを参照してください。
- 増分ロード用のフィルターを適用:データ量を管理するため、各PVOのLastUpdateDate列に基づいてフィルターを適用します。初回実行では広い日付範囲を指定できます。以降の定期実行では、前回のジョブ実行後に更新されたレコードだけを抽出するように設定します。
- 抽出ジョブをスケジュール:「Manage Schedule」に移動します。ジョブの新しいスケジュールを作成します。システムパフォーマンスへの影響を抑えるため、毎晩など、業務時間外に実行することを推奨します。
- ジョブを送信して監視:設定が完了したらジョブを送信します。「Manage Extract Jobs」画面で進行状況を確認できます。正常に完了すると、データファイルが設定したクラウドストレージに圧縮CSV形式で保存されます。
- 生のデータをイベントログに変換:抽出したCSVファイルをダウンロードします。BICCが提供するのは整形済みのイベントログではなく、生のテーブルデータです。これらのファイルを処理するには、外部ツール(Python、データベーススクリプト、ETLプラットフォームなど)を使う必要があります。処理内容は次のとおりです:
- 異なるファイルのデータを結合します(例:請求書データを販売注文ヘッダーに関連付けます)。
- 日付列を個別のアクティビティ行に変換します。たとえば、FscmTopModelAM.DooTopAM.Headerファイルから、CreationDateを使ってSales Order Createdの行を作成し、ClosedDateを使ってOrder Closedの行を作成します。
- ステータスコードやフラグを、Order ConfirmedやOrder Cancelledなどの特定のアクティビティにマッピングします。
- 変換したすべてのデータを、SalesOrder、ActivityName、EventTimeという必要な列を持つ1つのファイルにまとめます。
- アップロード用に整形:最終的な変換ファイルが1つのCSVであり、必要な属性および推奨属性と一致する列を持つことを確認します。これでファイルをProcessMindにアップロードできます。
設定
- PVOの選択:イベントログの正確性は、適切なPVOを選択できるかどうかに大きく左右されます。主要なPVOには、注文の作成と完了に使用するFscmTopModelAM.DooTopAM.Header、出荷イベントに使用するFscmTopModelAM.ScmTopAM.ShipmentLine、請求に使用するFscmTopModelAM.ArTopAM.ReceivableInvoiceがあります。
- 増分抽出:定期的な抽出では、必ずLastUpdateDateフィルターを使用してください。パフォーマンスを確保し、数GB規模の同じデータセットを繰り返し抽出しないために欠かせません。初回の全件ロードで基準データを作成し、以降の実行では変更分だけを取得します。
- 日付範囲:最初の履歴ロードでは、完全性とデータ量のバランスを取るため、直近3~6か月など、代表的な期間を抽出します。以降は増分抽出を行います。
- ストレージ設定:BICCではOracleのUCMまたはOCI Object Storageにエクスポートできます。大量データを扱い、後続のETLツールと連携する場合は、通常OCI Object Storageを推奨します。
- ジョブのスケジュール:Oracle Fusion Financialsのトランザクションシステムでパフォーマンスが低下する可能性を避けるため、抽出ジョブは業務時間外にスケジュールします。
- 前提条件:ジョブを設定するユーザーにはBICC_ADMINISTRATORロールが必要です。クラウドストレージの認証情報を事前に設定し、抽出後に必要となるデータ変換ロジックを明確にしておく必要があります。
a サンプルクエリ config
# BICC Data Store (PVO) and Column Selection Manifest
# This manifest outlines the PVOs and columns to select in the BICC UI for the extract job.
# PVO for Sales Order Header information (Created, Confirmed, Closed, Cancelled events)
PVO: FscmTopModelAM.DooTopAM.Header
Columns:
- HeaderId -> SalesOrder
- CreationDate -> EventTime (for 'Sales Order Created')
- CreatedBy -> UserName (for 'Sales Order Created')
- LastUpdateDate # For incremental filtering
- StatusCode
- SubmittedDate -> EventTime (for 'Order Confirmed')
- SubmittedBy -> UserName (for 'Order Confirmed')
- OrderedTotal -> SalesOrderTotalAmount
- SoldToPartyName -> CustomerName
- SourceSalesChannelCode -> SalesChannel
- RequestShipDate -> RequestedDeliveryDate
- ClosedDate -> EventTime (for 'Order Closed')
- CanceledFlag
- CanceledDate -> EventTime (for 'Order Cancelled')
# PVO for Sales Order Lines (Line Closed event)
PVO: FscmTopModelAM.DooTopAM.FulfillLine
Columns:
- HeaderId -> SalesOrder
- ActualCompletionDate -> EventTime (for 'Order Line Closed')
- LastUpdateDate # For incremental filtering
- LastUpdatedBy -> UserName
- StatusName # To confirm closed status
# PVO for Holds (Credit Hold Applied event)
PVO: FscmTopModelAM.DooTopAM.HoldInstance
Columns:
- SourceHeaderId -> SalesOrder
- CreationDate -> EventTime (for 'Credit Hold Applied')
- CreatedBy -> UserName
- HoldName # To filter for credit-related holds
# PVO for Shipments (Picked, Shipped, Delivered events)
PVO: FscmTopModelAM.ScmTopAM.ShipmentLine
Columns:
- SourceHeaderNumber -> SalesOrder
- PickedDate -> EventTime (for 'Goods Picked')
- ShippedDate -> EventTime (for 'Goods Shipped')
- ActualDeliveryDate -> ActualDeliveryDate & EventTime (for 'Goods Delivered')
- LastUpdateDate # For incremental filtering
- LastUpdatedBy -> UserName
# PVO for Invoices (Invoice Created, Invoice Corrected events)
PVO: FscmTopModelAM.ArTopAM.ReceivableInvoice
Columns:
- InterfaceHeaderAttribute1 -> SalesOrder # Link to SO via reference field
- TrxDate -> EventTime (for 'Invoice Created')
- CreatedBy -> UserName
- DueDate -> PaymentDueDate
- PreviousTrxNumber # If populated, indicates a correction
- CreationDate # Can be used for 'Invoice Corrected' if a new record is made
- LastUpdateDate # For incremental filtering
# PVO for Payments (Payment Received event)
PVO: FscmTopModelAM.ArTopAM.CashReceiptApplication
Columns:
- AppliedCustomerTrxId # ID to link back to the invoice
- ApplyDate -> EventTime (for 'Payment Received')
- CreatedBy -> UserName
- LastUpdateDate # For incremental filtering 準備はできましたか?
このテンプレートを使ってデータ収集を効率化し、プロセスマイニングを始めましょう。今すぐ受注から入金まで:販売注文処理の最適化に取り組めます。
今すぐ受注から入金まで:販売注文処理を最適化
ボトルネックを特定し、受注から入金までのサイクルタイムを簡単に30%短縮できます。
クレジットカードは不要です。14日間無料でお試しいただけます。