受注から入金までの受注処理データテンプレート
受注から入金までの受注処理データテンプレート
- 収集を推奨する項目
- 追跡すべき主要アクティビティ
- 実践的なデータ抽出ガイド
受注から入金まで - 販売受注処理属性
| 名前 | 説明 | ||
|---|---|---|---|
| 受注 SalesOrder | 販売注文の一意の識別子であり、受注から入金までのプロセスの主要なケースとして機能します。 | ||
| 説明 販売注文番号は、各顧客注文をライフサイクル全体を通じて一意に識別します。これは、初期作成、確認からフルフィルメント、請求、最終支払いまで、すべての関連アクティビティを結びつける中心的な糸として機能します。 プロセスマイニングにおいて、この属性はすべての関連イベントを単一のケースとしてグループ化するために不可欠です。販売注文別にプロセスを分析することで、完全なエンドツーエンドの視点が得られ、総サイクルタイムの計算、個別の注文に対するプロセスバリアントの特定、そして異なる部門やシステムを通じた注文の経路追跡が可能になります。 その重要性 これはケースIDです。すべてのプロセスイベントをリンクし、単一の顧客注文のエンドツーエンドの経路を追跡することを可能にします。 取得元 この識別子は通常、Oracle Fusionの販売注文のヘッダーテーブル(例:DOO_HEADERS_ALL)で見つかります。Oracle Fusion Financialsのドキュメントを参照してください。 例 SO-100567SO-100568SO-100569 | |||
| アクティビティ名 ActivityName | 販売注文プロセス内で発生した特定のビジネスイベントまたはタスクの名称。 | ||
| 説明 この属性は、販売注文に対して特定の時点で実行されたステップ(「受注作成」、「商品出荷」、「入金確認」など)を表します。これら一連のアクティビティが、各ケースのプロセスフローを構成します。 ((ActivityName))の分析は、プロセスマイニングにおいて極めて重要です。これにより、プロセスマップの可視化や多様なプロセスバリエーションの把握、案件が滞留しているボトルネックの特定が可能になります。また、ステップ間の遷移時間の算出や、オーダー・トゥ・キャッシュ(O2C)プロセスにおける業務実態を理解するための基礎データとなります。 その重要性 この属性はプロセスマップ内のステップを定義し、プロセスフローの視覚化と分析を可能にします。 取得元 これは、様々な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 | |||
| 実績納期 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にとって極めて重要です。支払期日と実際の支払い受領日を比較することで、システムは支払いが期日通りであったか遅延であったかを判断でき、売掛金のパフォーマンスを監視し、キャッシュフローを管理するのに役立ちます。 その重要性 期日内支払い率を計算する際の期限として機能し、キャッシュフロー効率の主要な指標となります。 取得元 AR_PAYMENT_SCHEDULES_ALLなど、Oracle Fusion内の売掛金または請求書テーブルで確認できます。 例 2023-06-192023-07-012023-06-25 | |||
| 自動化 IsAutomated | `アクティビティ`がシステムによって自動的に実行されたか、またはユーザーによって手動で実行されたかを示すフラグ。 | ||
| 説明 このブール属性は、システム駆動型イベント(例:自動信用審査、システム生成請求書)と手動ユーザーアクションを区別します。通常、アクティビティに関連付けられたユーザー名に基づいて導出され、汎用システムIDが自動化を示します。 この属性を分析することは、プロセスにおける自動化レベルを測定するのに役立ち、「手動手戻り注文割合」KPIの直接的な入力となります。どの手動ステップが最も時間消費的であるか、またはエラー発生しやすいかを示すことで、さらなる自動化の機会を強調できます。 その重要性 プロセスの自動化レベルを定量化し、コストのかかる手動介入を削減する機会を特定するのに役立ちます。 取得元 これは派生フィールドであり、しばしばUserName属性に適用されるルールに基づきます。例えば、ユーザーが「SYSTEM」または「BATCH」の場合、このフラグはtrueに設定されます。 例 truefalse | |||
| 販売チャネル SalesChannel | 販売注文が受領されたチャネル。 | ||
| 説明 この属性は、販売注文の起源(例:「Web」、「Direct Sales(直接販売)」、「Partner(パートナー)」、「EDI」など)を分類します。注文が組織にどのように入力されたかについてのコンテキストを提供します。 販売チャネル別にプロセスをセグメント化することは、「販売チャネルパフォーマンス概要」ダッシュボードにとって極めて重要です。これにより、異なるチャネルの効率性、サイクルタイム、エラー率を比較し、最も効果的なチャネルや、プロセス改善またはさらなる自動化が必要なチャネルを特定するのに役立ちます。 その重要性 チャネル別のパフォーマンス分析をサポートし、注文処理において最も効率的および最も非効率的なチャネルを特定するのに役立ちます。 取得元 この情報は、販売注文ヘッダーの専用フィールドに格納されている場合があります。Oracle Fusion Financialsのドキュメントを参照してください。 例 直販WebポータルEDIリセラー | |||
| 販売注文合計金額 SalesOrderTotalAmount | 販売受注の総金額です。 | ||
| 説明 この属性は、販売注文全体に関して顧客に請求される合計金額を表します。これには、割引適用前のすべての明細項目、税金、およびその他の費用の合計が含まれます。 プロセス分析において、この属性は価値ベースのプロセスマイニングにとって極めて重要です。これにより、価値別に注文をセグメント化(例:高価値注文対低価値注文)し、異なるプロセスパスをたどるか、異なるサイクルタイムを持つかを確認できます。また、財務的に最も重要なケースにプロセス改善の取り組みを優先順位付けするのにも役立ちます。 その重要性 財務影響分析を可能にし、高価値注文のプロセス改善を優先し、コストドライバーを理解するのに役立ちます。 取得元 通常、Oracle Fusionの販売注文ヘッダーテーブルで見つかります。Oracle Fusion Financialsのドキュメントを参照してください。 例 5250.00125000.75980.50 | |||
| 顧客名 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-EMEAグローバルサービス | |||
| 最終データ更新 LastUpdateDate | このイベントのデータがソースシステムから最後に更新された日時を示すタイムスタンプ。 | ||
| 説明 この属性は、プロセスマイニングデータセット内でデータが最後に抽出または更新された日時を記録します。これにより、分析されているデータの鮮度に関する透明性が提供されます。 この情報は、ユーザーがプロセス分析の最新性を理解するために不可欠です。データの適時性に関する期待値を管理するのに役立ち、データ更新スケジュールの設定と監視にとって重要です。 その重要性 データの鮮度を示し、プロセス分析がどれだけ最新かをユーザーに明確にします。 取得元 この値は、各データ抽出および変換サイクル中に生成され、データセットにスタンプされます。 例 2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
| 出荷方法 ShippingMethod | 商品を顧客へ出荷するために使用された方法または運送業者。 | ||
| 説明 この属性は、「Ground Freight(陸上貨物)」、「Air Express(航空速達)」、「Local Courier(地域クーリエ)」など、配送に使用されたロジスティクス運送業者またはサービスレベルの詳細を説明します。 この情報は、「出荷方法配送遵守」ダッシュボードにとって不可欠です。これにより、異なる方法や運送業者間での納期遵守パフォーマンスと出荷コストの比較が可能になり、ロジスティクス戦略とベンダー選定の最適化に役立ちます。 その重要性 異なる運送業者や配送方法のパフォーマンス比較を可能にすることで、物流分析を直接サポートします。 取得元 Oracle Fusion内の出荷およびフルフィルメントテーブルで利用可能です。Oracle Fusion Financialsのドキュメントを参照してください。 例 FedEx GroundUPS ネクストデイ エアーDHL International | |||
| 定時配送か IsOnTimeDelivery | 実際の配送が要求された配送日以前に行われた場合にtrueとなる計算フラグです。 | ||
| 説明 このブール属性は、ActualDeliveryDateとRequestedDeliveryDateを比較することで導出されます。これは、配送パフォーマンスを示すシンプルでケースレベルの指標を提供します。 このフラグは、集計「納期遵守率」KPIを計算するための基盤となります。フィルタリングと分析を簡素化し、ユーザーがすべての遅延注文を迅速に隔離して、遅延に寄与する要因に関する根本原因分析を実行することを可能にします。 その重要性 顧客の期待に対するフルフィルメントパフォーマンスを直接測定し、遅延注文の分析を簡素化します。 取得元 これは計算フィールドです。ロジックは「ActualDeliveryDate <= RequestedDeliveryDate」です。 例 truefalse | |||
| 延滞 IsLatePayment | 支払いが支払い期日後に受領された場合にtrueとなる計算フラグです。 | ||
| 説明 このブール属性は、実際の支払い受領日と支払期日を比較することで導出されます。請求書が期日通りに支払われたかどうかを明確に示します。 この属性は、「期日内支払い率」KPIを計算するために使用されます。期日通り支払いと遅延支払いを容易にセグメント化し、支払い遅延顧客の特性、遅延の一般的な理由、および運転資本への財務的影響を分析することを可能にします。 その重要性 支払回収の有効性を直接測定し、延滞支払いの分析を簡素化します。 取得元 これは計算フィールドです。ロジックは「PaymentReceivedDate > PaymentDueDate」です。 例 falsetrue | |||
| 支払条件 PaymentTerms | 顧客支払いに関して合意された条件。 | ||
| 説明 この属性は、顧客が請求書を支払うべき条件(例:「Net 30」または「Net 60」)を特定します。これらの条件は支払期日を計算するための基礎となります。 分析において、支払条件別にセグメント化することで、支払いサイクルタイムの変動を説明するのに役立ちます。異なる条件は自然に異なる支払い行動につながるため、「期日内支払い率」KPIのコンテキストを提供します。これは信用ポリシーとキャッシュフロー予測に情報を提供できます。 その重要性 支払い行動分析に不可欠なコンテキストを提供し、請求書発行から支払いまでのサイクルタイムの変動を説明するのに役立ちます。 取得元 Oracle Fusion内の販売オーダーまたは顧客アカウントレベルで利用可能です。Oracle Fusion Financialsのドキュメントを参照してください。 例 支払条件:正味30日支払条件:正味60日受領時支払い | |||
| 注文タイプ OrderType | 販売オーダーの分類で、「通常注文」や「返品注文」などが含まれます。 | ||
| 説明 「注文タイプ」は、ビジネス目的に基づいて販売注文を分類するために使用されます。一般的なタイプには、標準販売、サービス注文、返品承認(RMA)、社内注文などがあります。 注文タイプ別にプロセスを分析することは重要です。なぜなら、異なるタイプはそれぞれ独自のプロセスフローとパフォーマンス目標を持つことが多いためです。このセグメンテーションは、意図的で想定されるプロセスバリエーションを理解するのに役立ち、それらが逸脱として誤解されるのを防ぎます。 その重要性 異なる、正当なプロセスフロー(例:標準と返品)をセグメント化することで、公正かつ正確な分析を保証できます。 取得元 通常、Oracle Fusionの販売注文ヘッダーテーブルのフィールドとして利用可能です。Oracle Fusion Financialsのドキュメントを参照してください。 例 標準販売注文返品承認サービスオーダー | |||
| 製品名 ProductName | 販売されている製品またはサービスの名称。 | ||
| 説明 この属性は、販売注文明細上の品目を指定します。注文に複数の明細がある場合、ケースは明細レベルで分析されるか、この属性がヘッダーレベルで集計される可能性があります。 製品別に分析することで、特定の製品が頻繁な配送遅延や支払い問題など、より複雑または問題のあるプロセスフローに関連しているかどうかを理解するのに役立ちます。これは製品管理およびサプライチェーン戦略に情報を提供できます。 その重要性 異なる製品のプロセスパフォーマンスを分析し、複雑なフルフィルメントパスや請求パスを持つ可能性のある品目を強調表示できます。 取得元 販売注文明細テーブルから取得され、製品マスターテーブルと結合されます。Oracle Fusion Financialsのドキュメントを参照してください。 例 標準ウィジェットX1プレミアムサービスパッケージComponent Y2-B | |||
| 請求書が修正されたか IsInvoiceCorrected | 請求書が最初の作成後に修正または改訂されたかどうかを示すフラグです。 | ||
| 説明 このブール属性は、「Invoice Corrected(請求書修正済み)」アクティビティの存在によって示されるように、請求書が修正ループを経た場合にtrueとなります。これは、請求段階で手戻りが発生したケースにフラグを立てます。 これは「請求書精度と手戻り分析」ダッシュボードおよび「請求書手戻り率」KPIの主要な入力です。請求書エラーの程度を定量化し、修正が必要な理由を特定するための根本原因分析を可能にし、手作業と支払い遅延の削減を目指します。 その重要性 請求書の手戻りを特定します。これは、プロセス非効率性、データ品質の問題、および支払い遅延の潜在的な主要指標です。 取得元 これは計算フィールドであり、「Invoice Corrected(請求書修正済み)」アクティビティがそのイベントログに存在する場合、通常、ケースに対してtrueに設定されます。 例 falsetrue | |||
| 請求書番号 InvoiceNumber | 顧客請求書の一意の識別子です。 | ||
| 説明 この属性は、販売注文から生成された請求書に割り当てられる一意の番号です。販売およびフルフィルメント活動をプロセスの財務決済部分にリンクします。 販売注文が主要なケースIDである一方で、請求書番号は請求および支払いサブプロセスを分析するために極めて重要です。請求書修正、紛争、支払いステータスの追跡に不可欠であり、「請求書精度と手戻り分析」のようなダッシュボードをサポートします。 その重要性 売掛金プロセスへの重要なリンクを提供し、請求書の手戻りや支払いサイクルを分析するために不可欠です。 取得元 RA_CUSTOMER_TRX_ALLなど、Oracle Fusionの売掛金取引テーブルで利用可能です。 例 INV-93485INV-93486INV-93487 | |||
| 顧客国 CustomerCountry | 顧客が所在する国。 | ||
| 説明 この属性は、顧客の出荷先または請求先住所から国情報を提供します。これは地理的分析のための主要なディメンションです。 国別にプロセスをセグメント化することで、プロセスパフォーマンス、サイクルタイム、または支払い行動における地域差を明らかにできます。これは、地域の規制、ロジスティクス上の課題、市場状況が受注から入金までのプロセスに与える影響を理解する上で価値があります。 その重要性 プロセス効率、コンプライアンス、顧客行動における地域差を特定するための地理的分析を可能にします。 取得元 販売注文にリンクされた顧客マスターデータテーブル(HZ_LOCATIONS、HZ_PARTY_SITES)から取得されます。 例 米国ドイツ日本 | |||
受注から入金まで - 販売受注処理活動
| アクティビティ | 説明 | ||
|---|---|---|---|
| 入金確認済み | このアクティビティは、顧客の支払いが受領され、売掛金内の請求書に適用されたことを示します。これは、現金受領の適用が記帳されたときに捕捉されます。 | ||
| その重要性 これは「全体的な受注から入金までのサイクルタイム」と「期日内支払い率」を測定するための重要なマイルストーンです。売上を現金化することを示します。 取得元 これはOracle売掛金における明示的なイベントです。受領書が請求書に適用される際に、AR_RECEIVABLE_APPLICATIONS_ALLのような現金受領テーブルに記録されます。 取得 ARにおける現金受領適用レコードの「適用日」タイムスタンプから取得されます。 イベントタイプ explicit | |||
| 受注確認済み | この主要なマイルストーンは、販売注文が信用承認を含むすべての初期チェックを通過し、現在フルフィルメントのためにコミットされたことを示します。通常、注文ステータスが「Awaiting Shipping(出荷待ち)」や「Scheduled(スケジュール済み)」のような状態に進んだときに推測されます。 | ||
| その重要性 このアクティビティは、「平均注文確定時間」を計算するための重要なマイルストーンであり、注文入力からフルフィルメントプロセスへの引き渡しを示します。 取得元 販売オーダーヘッダーまたはラインのステータスが、フルフィルメントの準備ができたことを示す値(例:「出荷待ち」)に変わったことから推測されます。DOO_HEADERS_ALLまたはDOO_FULFILL_LINES_ALLのステータス列を確認してください。 取得 注文ステータスが確定またはスケジュール済み状態に変わったタイムスタンプから導出されます。 イベントタイプ inferred | |||
| 商品発送済み | このアクティビティは、商品が倉庫から出荷され、顧客への輸送中である時点を示します。これはOracle Shippingで出荷確認トランザクションが処理されたときに捕捉されます。 | ||
| その重要性 これは、プロセスのフルフィルメント部分の完了を示し、請求をトリガーする重要なマイルストーンです。期日内出荷と納期リードタイムを測定するために不可欠です。 取得元 これはOracle Shipping Executionで記録される明示的なイベントです。出荷確認トランザクションにより、出荷日と共にWSH_DELIVERY_DETAILSのような出荷テーブルにレコードが作成されます。 取得 オーダーラインに関連付けられた配送詳細レコードの「実際出荷日」タイムスタンプから取得されます。 イベントタイプ explicit | |||
| 注文完了 | プロセスにおける最終アクティビティであり、販売注文のすべての明細が履行され、請求され、クローズされたことを示します。注文ヘッダーのステータスは「Closed(クローズ済み)」に更新されます。 | ||
| その重要性 このアクティビティは、販売注文ライフサイクルの成功裏の終了を示します。エンドツーエンドのプロセス期間を計算し、決してクローズされない「ゾンビ注文」を特定するために不可欠です。 取得元 DOO_HEADERS_ALLテーブルで販売オーダーヘッダーのステータスが「Closed(クローズ済み)」に変更されたことから推測されます。この最終ステータス変更のタイムスタンプがイベント時間として機能します。 取得 販売オーダーヘッダーのステータスが「Closed(クローズ済み)」に変更されたタイムスタンプから導出されます。 イベントタイプ inferred | |||
| 請求書作成 | このアクティビティは、売掛金モジュールでの顧客請求書の作成を表し、通常は出荷確認イベントによってトリガーされます。一意の番号と作成日を持つ請求書レコードが生成されます。 | ||
| その重要性 支払い回収サイクルの正式な開始を示します。「請求書から支払いまでの時間」および全体的なキャッシュフロー効率を測定するための基準となります。 取得元 これはOracle売掛金(AR)における明示的なイベントです。RA_CUSTOMER_TRX_ALLテーブルにトランザクション日付と共に請求書レコードが作成されます。 取得 ARモジュールにおける請求書トランザクションの作成日から取得されます。 イベントタイプ explicit | |||
| 販売注文作成済み | このアクティビティは販売注文プロセスの開始を示し、新しい販売注文がOracle Fusionに入力された瞬間を表します。このイベントは通常、ユーザーがOrder Managementモジュールで新しい注文レコードを保存する際に明示的に捕捉されます。 | ||
| その重要性 プロセス開始活動として、これはOrder to Cashの全体的なサイクルタイムを測定し、受注量を分析するために不可欠です。 取得元 Order Management Cloudで販売注文レコードが作成される際に明示的に記録されます。DOO_HEADERS_ALLテーブルの作成タイムスタンプを確認してください。 取得 販売オーダーヘッダーレコードの作成タイムスタンプから取得されます。 イベントタイプ explicit | |||
| ピッキング済み | 倉庫から商品を物理的にピッキングし、注文を履行することを示します。これはロジスティクスプロセスにおける重要なステップであり、通常、倉庫管理または出荷モジュールで記録されます。 | ||
| その重要性 このアクティビティは、倉庫業務の可視性を提供します。在庫予約からピッキングまでの遅延は、倉庫におけるリソースまたはプロセスのボトルネックを示唆する可能性があります。 取得元 Oracle Fusion Cloud SCM(Supply Chain Management)モジュール内で取得されます。販売オーダーラインに関連付けられたピッキングウェーブまたはピッキングスリップのステータス変更から推測できます。 取得 SCMモジュールにおけるピッキングトランザクションの完了タイムスタンプから推測されます。 イベントタイプ inferred | |||
| 与信チェック実行済み | 顧客の口座に対する信用度を評価するための信用審査の実行を示します。これは注文処理ワークフロー内の自動または手動のステップであり、その完了は通常、ステータス更新または完了したタスクとしてログに記録されます。 | ||
| その重要性 与信チェックにかかる時間を分析することで、注文承認におけるボトルネックを特定できます。「与信チェックから確定までの時間」KPIにとって極めて重要です。 取得元 販売オーダーのステータス変更、例えば「与信承認保留中」ステータスへの移行、または与信管理機能における明示的なイベントログから推測できます。 取得 注文ステータスの変更または与信審査タスクに関連付けられたタイムスタンプから推測されます。 イベントタイプ inferred | |||
| 与信保留適用済み | このアクティビティは、信用審査の失敗やその他の信用関連の問題により、販売注文が自動的または手動で保留にされるときに発生します。これは通常、システム内の注文の保留ステータスの変更によって捕捉されます。 | ||
| その重要性 信用保留を追跡することは、注文処理遅延の背後にある理由を特定し、信用保留解除プロセスの効率性を測定するために不可欠です。 取得元 販売オーダーに保留が適用されたことから推測されます。これは通常、販売オーダーにリンクされたDOO_HOLDS_ALLなどの保留関連テーブルに記録されます。 取得 オーダー保留テーブルに「Credit(与信)」保留タイプでレコードが作成されたことから推測されます。 イベントタイプ inferred | |||
| 受注キャンセル済み | 完全に商品が出荷される前に販売注文がキャンセルされたことを示します。これは様々な理由で発生し、最終ステータスが「Cancelled(キャンセル済み)」となります。 | ||
| その重要性 これは重要な例外パスです。キャンセルされた注文を分析することで、在庫切れ、価格設定の問題、顧客の心変わりといった根本原因を特定するのに役立ち、プロセス改善に情報を提供できます。 取得元 販売オーダーヘッダーまたはラインのステータスが「Cancelled(キャンセル済み)」状態に変更されたことから推測されます。このステータス変更のタイムスタンプがイベントを記録するために使用されます。 取得 オーダーヘッダーまたはラインのステータスが「Cancelled(キャンセル済み)」に変更されたタイムスタンプから導出されます。 イベントタイプ inferred | |||
| 受注明細完了 | 個別の販売注文明細が最終的にクローズされたことを示し、完全に発送され、請求され、それ以上の取引が予定されていないことを意味します。システムは明細ステータスを「Closed(クローズ済み)」に更新します。 | ||
| その重要性 オーダーラインのクローズは、その品目に関するすべての契約上の義務が完了したことを意味します。これを分析することで、フルフィルメントと支払い後も長期間オープン状態にあるオーダーを特定するのに役立ちます。 取得元 DOO_FULFILL_LINES_ALLテーブルでフルフィルメントラインのステータスが「Closed(クローズ済み)」に変更されたことから推測されます。このステータス変更のタイムスタンプがイベントをマークします。 取得 フルフィルメントラインのステータスが「Closed(クローズ済み)」に変更されたタイムスタンプから導出されます。 イベントタイプ inferred | |||
| 商品配送済み | 顧客が出荷物を受け取ったことを示します。この情報は、多くの場合、外部の運送業者から提供され、Oracle Fusionに更新されるか、出荷日から標準的な輸送時間に基づいて推測される場合があります。 | ||
| その重要性 このアクティビティは、「納期遵守率」KPIの計算と、顧客サービスレベルを正確に測定するために不可欠です。 取得元 これはしばしばネイティブなOracleイベントではありません。運送業者との連携がある場合に捕捉できるか、または「Goods Shipped(商品出荷済み)」日付に標準的な輸送時間を加算することで計算できます。システム分析が必要です。 取得 運送業者のデータフィードから推測されるか、出荷日と平均輸送時間に基づいて計算されます。 イベントタイプ inferred | |||
| 在庫予約済み | このアクティビティは、販売注文明細を履行するための物理在庫の割り当てまたは予約を表します。システムは特定の在庫をコミットし、注文がピッキング準備完了になったときにそれが利用可能であることを保証します。 | ||
| その重要性 これを追跡することで、「在庫割り当てリードタイム」KPIの分析に役立ち、注文確定から商品の確保までの遅延を特定します。 取得元 このイベントは、在庫管理またはサプライチェーン実行モジュールでしばしば捕捉されます。在庫が詳細化または予約されたことを示すフルフィルメント明細のステータス更新から推測することも可能です。 取得 在庫予約またはスケジューリングに関連するフルフィルメントラインのステータス変更から推測されます。 イベントタイプ inferred | |||
| 請求書修正済み | エラーや顧客との紛争により、以前作成された請求書が修正、再発行、または相殺される場合に発生します。これは通常、クレジットメモの作成または請求書の新しいバージョン発行によって記録されます。 | ||
| その重要性 請求書修正を追跡することは、「請求書手戻り率」KPIの鍵であり、支払い遅延や管理コスト増加につながる請求プロセス内の問題を浮き彫りにします。 取得元 クレジットメモ(元の請求書にリンクされている)の作成、またはRA_CUSTOMER_TRX_ALLテーブル内の同じ請求書のその後のバージョンによって推測されます。 取得 以前の請求書トランザクションを参照するクレジットメモまたは請求書を特定することによって導出されます。 イベントタイプ inferred | |||
抽出ガイド
ステップ
- Oracle BI Publisherへのナビゲート: BI AdministratorまたはBI Author権限を持つユーザーでOracle Fusion環境にログインします。ナビゲーターメニューを使用して「Tools(ツール)」>「Reports and Analytics(レポートと分析)」に移動します。「Browse Catalog(カタログの参照)」ボタンをクリックして「Business Intelligence Catalog」を開きます。
- 新しいデータモデルの作成: BIカタログで、適切なフォルダー(例: Shared Folders > Custom)に移動します。「New(新規)」ドロップダウンメニューをクリックし、「Data Model(データモデル)」を選択します。
- SQLクエリデータセットの定義: データモデルエディターで、「+」アイコンをクリックして新しいデータセットを作成し、「SQL Query(SQLクエリ)」を選択します。ダイアログボックスが表示されます。データセットに名前を付け(例: 'OrderToCash_EventLog')、データソースとして「Oracle BI EE」を選択し、SQLのタイプとして「Standard SQL」を選択します。
- SQLクエリの入力: このドキュメントの「query」セクションで提供されている完全なSQLクエリをコピーし、SQL Queryテキストエリアに貼り付けます。クエリには開始日と終了日のパラメータ(:p_start_dateおよび:p_end_date)が含まれており、BI Publisherによって自動的に認識されます。
- データモデルプロパティの設定: クエリを貼り付けた後、「OK」をクリックします。データモデルエディターの左ペインにある「Properties(プロパティ)」セクションに移動します。「Include Parameter Tags」がチェックされていることを確認します。必要に応じて、日付パラメータのデフォルト値を設定することもできます。
- データモデルの表示と保存: 「Data(データ)」タブをクリックします。日付パラメータの値を入力するよう求められる場合があります。テストのために短い日付範囲を入力します。「View(表示)」をクリックしてデータのサンプルを確認します。データが正しく表示されたら、保存アイコンをクリックしてデータモデルを保存し、分かりやすい名前(例: 'OrderToCash_EventLog_DM')を付けます。
- データモデルからのレポートの作成: データモデルが保存されたら、右上隅にある「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)と一致していることを確認します。これでファイルはプロセスマイニングツールにアップロードする準備ができました。
設定
- User Privileges: BI Publisherのデータモデルおよびレポート作成権限を持つロール(例:'BI Administrator'または'BI Author')が必要です。
- Data Source: このクエリは、トランザクションデータベース(Fusion Apps)に接続する標準の'Oracle BI EE'アプリケーションデータソース向けに設計されています。通常、特別な設定は不要です。
- Date Range Parameters: クエリは、データをフィルタリングするために、:p_start_dateと:p_end_dateの2つのパラメータを使用します。レポートのタイムアウトやパフォーマンスの問題を避けるため、一度に3〜6ヶ月分など、管理しやすいバッチでデータを抽出することを強く推奨します。
- Business Unit Filtering: 抽出範囲を制限するには、クエリ内のBaseOrders CTEに特定のビジネスユニットIDでフィルタリングするWHERE句を追加できます(例:AND dhead.SUBMITTING_BU_ID IN ([Your Business Unit ID]))。
- Order Type Filtering: BaseOrders CTEのdhead.SOURCE_ORDER_TYPE_CODEに条件を追加することで、特定の販売オーダータイプでフィルタリングすることもできます。
- Performance: 数年間にわたる非常に大規模なデータセットの場合、この単一クエリのアプローチは遅くなる可能性があります。オフピーク時に実行するか、抽出をより小さな月次バッチに分割することを検討してください。複雑なUNIONクエリと干渉する可能性があるため、データモデルで「Enable SQL Pruning」プロパティが選択されていないことを確認してください。
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」を選択します。
- 新しいオファリングの作成: BICCコンソール内で、「Configure External Storage(外部ストレージの設定)」をクリックして、ターゲット宛先(Oracle Universal Content Management (UCM)またはOCI Object Storageバケット)を設定します。接続詳細と認証情報が正しいことを確認してください。
- 新規抽出ジョブの開始: 「Manage Extract Jobs(抽出ジョブの管理)」セクションに移動します。「+」アイコンをクリックして新しいジョブを作成します。例えば「ProcessMind_O2C_SalesOrder_Extract」のような分かりやすい名前を付けます。
- データストア(PVO)の選択: ジョブ設定で、販売オーダーライフサイクルをキャプチャするために必要なPublic View Objects (PVOs)を検索して追加します。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から必要な列の詳細なリストについては、クエリマニフェストを参照してください。
- 増分ロードのフィルター適用: データ量を管理するために、LastUpdateDate列に基づいて各PVOにフィルターを適用します。最初の実行では、広い日付範囲を選択できます。その後のスケジュールされた実行では、このフィルターは、前回のジョブ実行以降に更新されたレコードのみを抽出するように設定する必要があります。
- 抽出ジョブのスケジュール: 「Manage Schedule(スケジュールの管理)」セクションに移動します。ジョブの新しいスケジュールを作成します。システムパフォーマンスへの影響を最小限に抑えるため、たとえば毎日夜間などのオフピーク時間にジョブを実行することをお勧めします。
- ジョブの送信と監視: 設定が完了したら、ジョブを送信します。「Manage Extract Jobs」画面からその進行状況を監視できます。正常に完了すると、データファイルは設定されたクラウドストレージの場所に圧縮されたCSV形式で利用可能になります。
- 生データをイベントログに変換: 抽出されたCSVファイルをダウンロードします。BICCは生のテーブルデータを提供するため、フォーマット済みのイベントログではありません。これらのファイルを処理するには、外部ツール(Python、データベーススクリプト、ETLプラットフォームなど)を使用する必要があります。これには次の作業が含まれます。
- 異なるファイルからのデータの結合(例:請求書データを販売オーダーヘッダーにリンクする)。
- 日付列を個別の活動行にピボットする。例:FscmTopModelAM.DooTopAM.Headerファイルから、CreationDateを使用して「Sales Order Created」の行を1つ、ClosedDateを使用して「Order Closed」の行を1つ作成します。
- ステータスコードまたはフラグを「Order Confirmed」や「Order Cancelled」などの特定の活動にマッピングする。
- 変換されたすべてのデータを、SalesOrder、((ActivityName))、イベント日時 (イベント日時 (EventTime))の必須列を持つ単一のファイルに結合する。
- アップロード用のフォーマット: 最終的に変換されたファイルが、必須および推奨される属性と一致する列を持つ単一のCSVであることを確認します。これでファイルはProcessMindにアップロードする準備ができました。
設定
- PVO Selection: イベントログの精度は、適切なPVOsの選択に完全に依存します。主要なPVOsには、FscmTopModelAM.DooTopAM.Header(注文作成、クローズ用)、FscmTopModelAM.ScmTopAM.ShipmentLine(出荷イベント用)、およびFscmTopModelAM.ArTopAM.ReceivableInvoice(請求書作成用)が含まれます。
- Incremental Extraction: 定期的なデータ抽出には、常にLastUpdateDateフィルターを使用してください。これはパフォーマンスにとって非常に重要であり、同じ数ギガバイトのデータセットを繰り返し抽出するのを防ぎます。最初のフルロードでベースラインを確立し、それ以降の実行では変更のみをキャプチャするようにします。
- Date Range: 最初の履歴データロードでは、データの完全性と管理可能なデータ量のバランスを取るため、過去3〜6ヶ月のような代表的な期間のデータを抽出してください。それ以降の実行は差分抽出となります。
- Storage Configuration: BICCはOracle UCMまたはOCI Object Storageにエクスポートできます。大量データの場合やダウンストリームのETLツールとの連携を容易にするためには、通常OCI Object Storageの使用が推奨されます。
- Job Scheduling: Oracle Fusion Financialsトランザクションシステムへの潜在的なパフォーマンス低下を避けるため、抽出ジョブは業務時間外にスケジュールしてください。
- Prerequisites: ジョブを構成するユーザーには、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