受注から入金までの販売注文処理向けデータテンプレート
受注から入金までの販売注文処理向けデータテンプレート
- 収集を推奨する属性
- 追跡する主要なアクティビティ
- データ抽出の手順
受注から入金までの販売注文処理の属性
| 名前 | 説明 | ||
|---|---|---|---|
| 受注 SalesOrder | 受注を一意に識別する番号で、受注から入金までのプロセスにおける主要なケースIDです。 | ||
| 説明 受注番号は、顧客の各注文をライフサイクル全体にわたって一意に識別します。受注の作成や確認から、履行、請求、最終的な入金まで、関連するすべてのアクティビティを結び付ける軸になります。 プロセスマイニングでは、この属性を使って関連するすべてのイベントを1つのケースにまとめます。受注単位で分析することで、プロセス全体を把握し、サイクルタイムの合計を算出したり、受注ごとのプロセスバリアントを特定したり、部門やシステムをまたぐ受注の流れを追跡したりできます。 重要な理由 これはケース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 | 商品が実際に顧客へ納品された日付です。 | ||
| 説明 この属性には最終的な納品日が記録され、プロセスの履行段階が完了したことを示します。計画日や希望日と比較するための実績日です。 この日付を希望納品日と比較して、期日どおりの納品パフォーマンスを算出します。「期日どおりの納品率」の重要業績評価指標(KPI)や「納品SLA」ダッシュボードに欠かせないデータであり、物流とサプライチェーンの有効性を明確に測定できます。 重要な理由 期日どおりの納品率の算出や、顧客の希望に対する履行パフォーマンスの評価に使う実績日です。 入手先 Oracle Fusionの出荷・納品取引テーブルから取得します。Oracle Fusion Financialsの文書をご確認ください。 例 2023-05-202023-06-032023-05-25 | |||
| 希望納品日 RequestedDeliveryDate | 顧客が希望する受注品の納品日です。 | ||
| 説明 この属性には、顧客が商品を受け取りたい日付が記録されます。受注から入金までのプロセスにおける履行段階の重要な目標日です。 「期日どおりの納品率」の重要業績評価指標(KPI)の算出や、「納品サービスレベル合意(SLA)」ダッシュボードに利用できます。この日付を実際の納品日と比較することで、顧客の期待に応えられているかを測定し、納品遅延の根本原因を特定できます。 重要な理由 期日どおりの納品パフォーマンスと顧客サービスレベル合意(SLA)の遵守状況を測定する際の基準になります。 入手先 通常、Oracle Fusionの受注明細テーブルにあります。Oracle Fusion Financialsの文書をご確認ください。 例 2023-05-202023-06-012023-05-25 | |||
| 支払期日 PaymentDueDate | 顧客が請求書の支払いを行う期限です。 | ||
| 説明 支払期日は、請求日と顧客との合意済み支払条件に基づいて算出されます。期日どおりに入金を回収するための期限です。 この属性は「期日どおりの入金回収率」の重要業績評価指標(KPI)に欠かせません。支払期日と実際の入金日を比較することで、支払いが期日どおりか遅延したかを判定し、売掛金の状況を監視してキャッシュフローを管理できます。 重要な理由 期日どおりの支払い率を算出する期限となり、キャッシュフローの効率を測る重要な指標です。 入手先 Oracle Fusionの売掛金または請求書テーブル(AR_PAYMENT_SCHEDULES_ALLなど)にあります。 例 2023-06-192023-07-012023-06-25 | |||
| 自動処理かどうか IsAutomated | アクティビティがシステムによって自動実行されたか、ユーザーが手動で実行したかを示すフラグです。 | ||
| 説明 この真偽値属性は、自動与信確認やシステム発行の請求書など、システム主導のイベントとユーザーによる手動操作を区別します。通常、アクティビティに紐づくユーザー名から判定し、汎用システムIDの場合は自動処理とみなします。 この属性を分析すると、プロセスの自動化レベルを測定できます。また、「手作業による手戻り受注率」の重要業績評価指標(KPI)の算出にも直接利用できます。時間がかかる、またはエラーが発生しやすい手作業のステップを明らかにし、さらなる自動化の機会を見つけるのに役立ちます。 重要な理由 プロセスの自動化レベルを定量化し、コストのかかる手作業を減らす機会を特定できます。 入手先 ユーザー名属性に適用するルールから作成する派生項目です。たとえば、ユーザーが「SYSTEM」または「BATCH」の場合、このフラグはtrueになります。 例 truefalse | |||
| 販売チャネル SalesChannel | 受注を受け付けたチャネルです。 | ||
| 説明 この属性は、受注の受付元を「ウェブ」「直販」「パートナー」「EDI」などに分類します。受注が組織にどのように入ってきたかを把握できます。 販売チャネル別のプロセス分析は、「販売チャネル別パフォーマンス概要」ダッシュボードに欠かせません。チャネルごとの効率、サイクルタイム、エラー率を比較し、効果の高いチャネルや、プロセス改善またはさらなる自動化が必要なチャネルを特定できます。 重要な理由 チャネル別のパフォーマンス分析に役立ち、受注処理の効率が最も高いチャネルと低いチャネルを特定できます。 入手先 受注ヘッダーの専用項目に保存されている場合があります。Oracle Fusion Financialsの文書をご確認ください。 例 直販ウェブポータル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 | |||
| 受注タイプ OrderType | 「標準受注」や「返品受注」など、受注の分類です。 | ||
| 説明 受注タイプは、業務上の目的に基づいて受注を分類するために使います。一般的なタイプには、標準販売、サービス受注、返品承認(RMA)、社内受注があります。 受注タイプごとにプロセスフローやパフォーマンス目標が異なることが多いため、タイプ別の分析が重要です。この分類により、意図された想定内のプロセスの違いを把握し、逸脱と誤認することを防げます。 重要な理由 標準受注と返品受注など、正当なプロセスフローを分類し、公平で正確な分析を行えます。 入手先 通常、Oracle Fusionの受注ヘッダーテーブルの項目として確認できます。Oracle Fusion Financialsの文書をご確認ください。 例 標準受注返品承認サービス受注 | |||
| 支払い遅延か IsLatePayment | 支払期日を過ぎてから入金された場合にtrueとなる計算フラグです。 | ||
| 説明 この真偽値属性は、実際の入金日と支払期日を比較して算出します。請求書が期日どおりに支払われたかを明確に示します。 この属性は「期日どおりの支払い率」の重要業績評価指標(KPI)の算出に使います。期日どおりの支払いと遅延した支払いを簡単に分類し、支払いが遅れがちな顧客の特徴、遅延の一般的な理由、運転資金への財務的影響を分析できます。 重要な理由 支払い回収の効果を直接測定し、延滞債権の分析を簡素化します。 入手先 計算フィールドです。ロジックは次のとおりです:PaymentReceivedDate > PaymentDueDate。 例 falsetrue | |||
| 支払条件 PaymentTerms | 顧客との合意済み支払条件です。 | ||
| 説明 この属性は、顧客が請求書を支払う条件を示します。たとえば、「30日以内」や「60日以内」などです。この条件を基に支払期日を算出します。 支払条件別に分析すると、支払いサイクルタイムの違いを説明しやすくなります。条件によって支払い行動が異なるため、「期日どおりの支払い率」の重要業績評価指標(KPI)を理解する際のコンテキストになります。与信方針やキャッシュフロー予測の検討にも役立ちます。 重要な理由 支払い行動の分析に必要なコンテキストを提供し、請求から入金までのサイクルタイムの違いを説明するのに役立ちます。 入手先 Oracle Fusionの受注または顧客アカウントに設定されています。Oracle Fusion Financialsの文書をご確認ください。 例 30日以内60日以内受領時払い | |||
| 期日どおりの納品か IsOnTimeDelivery | 実際の納品日が希望納品日以前の場合にtrueとなる計算フラグです。 | ||
| 説明 この真偽値属性は、実際の納品日と希望納品日を比較して算出します。ケース単位で納品パフォーマンスを簡潔に示します。 このフラグは、全体の「期日どおりの納品率」の重要業績評価指標(KPI)を算出する基礎になります。絞り込みや分析が簡単になり、遅延の要因を根本から調査するために、納品が遅れた受注をすばやく抽出できます。 重要な理由 顧客の期待に対する履行パフォーマンスを直接測定し、納品遅延の分析を簡単にします。 入手先 計算項目です。条件は次のとおりです:ActualDeliveryDate <= RequestedDeliveryDate。 例 truefalse | |||
| 製品名 ProductName | 販売する製品またはサービスの名前です。 | ||
| 説明 この属性は、受注明細の品目を示します。複数の明細がある受注は、明細単位で分析することも、この属性をヘッダー単位に集計することもできます。 製品別に分析すると、納品遅延や支払いの問題が頻繁に発生するなど、特定の製品に複雑なプロセスフローや問題が関連しているかを把握できます。製品管理やサプライチェーン戦略の検討に役立ちます。 重要な理由 製品ごとのプロセスパフォーマンスを分析し、履行や請求の経路が複雑な品目を特定できます。 入手先 受注明細テーブルから取得し、製品マスターテーブルと結合します。Oracle Fusion Financialsの文書をご確認ください。 例 Standard Widget X1Premium Service PackageComponent Y2-B | |||
| 請求書の修正有無 IsInvoiceCorrected | 請求書が最初に作成された後、修正または改訂されたかどうかを示すフラグです。 | ||
| 説明 このブール型属性は、請求書に修正ループが発生し、「請求書を修正」アクティビティが存在する場合にtrueになります。請求処理の段階で手戻りが発生したケースを示します。 「請求書の正確性と手戻り分析」ダッシュボードと「請求書手戻り率」KPIの主要な入力データです。請求書の誤りの程度を定量化し、修正が必要となる原因を特定する根本原因分析に役立ちます。これにより、手作業と支払いの遅延を減らせます。 重要な理由 請求書の手戻りを特定します。これは、プロセスの非効率性、データ品質の問題、支払い遅延の可能性を示す重要な指標です。 入手先 計算フィールドです。通常、ケースのイベントログに「請求書を修正」アクティビティがある場合にtrueが設定されます。 例 falsetrue | |||
| 請求書番号 InvoiceNumber | 顧客向け請求書を一意に識別する番号です。 | ||
| 説明 この属性は、受注から発行された請求書に割り当てられる一意の番号です。販売・履行のアクティビティと、プロセスの決済段階を結び付けます。 主要なケースIDは受注番号ですが、請求書番号は請求と支払いのサブプロセスを分析するうえで重要です。請求書の修正、異議申し立て、支払い状況の追跡に欠かせず、「請求書の正確性と手戻り分析」などのダッシュボードにも利用できます。 重要な理由 売掛金プロセスとの重要なつながりとなり、請求書の手戻りや支払いサイクルの分析に必要です。 入手先 Oracle Fusionの売掛金取引テーブル(RA_CUSTOMER_TRX_ALLなど)で確認できます。 例 INV-93485INV-93486INV-93487 | |||
| 配送方法 ShippingMethod | 顧客への商品配送に使用する方法または運送業者です。 | ||
| 説明 この属性には、「陸上貨物」「航空便」「地域配送」など、納品に使用する物流業者またはサービスレベルが記録されます。 「配送方法別納品コンプライアンス」ダッシュボードに欠かせない情報です。配送方法や運送業者ごとの期日どおりの納品パフォーマンスと配送コストを比較し、物流戦略や業者の選定を見直す際に役立ちます。 重要な理由 運送業者や配送方法ごとのパフォーマンスを比較でき、物流分析に直接役立ちます。 入手先 Oracle Fusionの出荷・履行テーブルで確認できます。Oracle Fusion Financialsの文書をご確認ください。 例 FedEx GroundUPS Next Day AirDHL International | |||
| 顧客の国 CustomerCountry | 顧客が所在する国です。 | ||
| 説明 この属性は、顧客の配送先住所または請求先住所に記載された国を示します。地理的な分析に使う重要な軸です。 国別にプロセスを分類すると、プロセスパフォーマンス、サイクルタイム、支払い行動の地域差を把握できます。現地の規制、物流上の課題、市場環境が受注から入金までのプロセスに与える影響を理解するうえで役立ちます。 重要な理由 地域ごとのプロセス効率、コンプライアンス、顧客行動の違いを特定する地理的分析に役立ちます。 入手先 顧客マスターデータテーブル(HZ_LOCATIONS、HZ_PARTY_SITES)から取得し、受注に紐づけます。 例 USAドイツ日本 | |||
受注から入金までの販売注文処理のアクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
| 入金確認 | 顧客からの支払いが入金され、売掛金で請求書に充当されたことを示すアクティビティです。入金消込が転記された時点で記録されます。 | ||
| 重要な理由 「受注から入金までの全体サイクルタイム」と「期日どおりの支払い率」を測定するうえで重要な節目です。販売を現金化する段階を表します。 入手先 Oracle Accounts Receivableで明示的に記録されるイベントです。入金が請求書に充当されると、AR_RECEIVABLE_APPLICATIONS_ALLなどの入金テーブルに記録されます。 記録 ARの入金充当レコードにある「充当日」のタイムスタンプから取得します。 イベントタイプ explicit | |||
| 受注クローズ | プロセスの最後のアクティビティで、受注明細のすべてについて履行、請求、クローズが完了したことを示します。受注ヘッダーのステータスは「クローズ」に更新されます。 | ||
| 重要な理由 このアクティビティは、受注のライフサイクルが正常に完了したことを示します。プロセス全体の所要時間の算出や、クローズされないまま残る受注の特定に欠かせません。 入手先 DOO_HEADERS_ALLテーブルで受注ヘッダーのステータスが「クローズ」に変わったことから推定します。この最終ステータス変更のタイムスタンプをイベント時刻として使用します。 記録 受注ヘッダーのステータスが「クローズ」に変わった時点のタイムスタンプから算出します。 イベントタイプ inferred | |||
| 商品の出荷 | 商品が倉庫から出荷され、顧客への輸送中となった時点を示します。Oracle Shippingで出荷確認取引が処理された際に記録されます。 | ||
| 重要な理由 この重要な節目は、プロセスの出荷準備が完了したことを示し、請求書の発行につながります。納期遵守や納品リードタイムの測定に欠かせません。 入手先 Oracle Shipping Executionに明示的に記録されるイベントです。出荷確認取引により、出荷日を含むレコードがWSH_DELIVERY_DETAILSなどの出荷テーブルに作成されます。 記録 注文明細に関連付けられた納品明細レコードの「実際の出荷日」タイムスタンプから取得します。 イベントタイプ explicit | |||
| 注文確認 | この重要な節目は、販売注文が与信承認を含む初期審査をすべて通過し、出荷準備に進める状態になったことを示します。通常、注文ステータスが「出荷待ち」や「スケジュール済み」などに進んだ時点から推定します。 | ||
| 重要な理由 このアクティビティは「注文確認までの平均時間」を算出する重要な節目であり、注文入力から出荷準備への引き継ぎを示します。 入手先 販売注文ヘッダーまたは明細のステータスが、出荷準備が整ったことを示す値(例:「出荷待ち」)に変わった時点から推定します。DOO_HEADERS_ALLまたはDOO_FULFILL_LINES_ALLのステータス列を確認してください。 記録 注文ステータスが確認済みまたはスケジュール済みの状態に変わった時点のタイムスタンプから算出します。 イベントタイプ inferred | |||
| 請求書の作成 | 売掛金管理モジュールで顧客向け請求書を作成するアクティビティです。通常、出荷確認イベントをきっかけに実行され、固有の番号と作成日を含む請求書レコードが作成されます。 | ||
| 重要な理由 入金回収サイクルの正式な開始を示します。「請求書発行から入金までの時間」とキャッシュフロー全体の効率を測定する基準になります。 入手先 Oracle Accounts Receivable(AR)に明示的に記録されるイベントです。取引日を含む請求書レコードがRA_CUSTOMER_TRX_ALLテーブルに作成されます。 記録 ARモジュールで請求書取引が作成された日付から取得します。 イベントタイプ explicit | |||
| 販売注文の作成 | このアクティビティは販売注文プロセスの開始を示し、新しい販売注文がOracle Fusionに入力された時点を表します。通常、Order Managementモジュールでユーザーが新しい注文レコードを保存した際に、イベントとして明示的に記録されます。 | ||
| 重要な理由 プロセスの開始点となるこのアクティビティは、受注から入金までの全体のサイクルタイムを測定し、注文の受付件数を分析するうえで欠かせません。 入手先 Order Management Cloudで販売注文レコードが作成された時点で明示的に記録されます。DOO_HEADERS_ALLテーブルの作成タイムスタンプを確認してください。 記録 販売注文ヘッダーレコードの作成タイムスタンプから取得します。 イベントタイプ explicit | |||
| 与信保留の適用 | 与信審査に通らなかった場合や、その他の与信関連の問題がある場合に、販売注文が自動または手動で保留されるアクティビティです。通常、システム内で注文の保留ステータスが変更されたことから確認できます。 | ||
| 重要な理由 与信保留を追跡すると、注文処理の遅延理由を特定し、与信保留解除の効率を測定できます。 入手先 販売注文に保留が適用されたことから推定します。通常、DOO_HOLDS_ALLなどの保留関連テーブルに販売注文と関連付けて記録されます。 記録 注文保留テーブルに「与信」タイプの保留レコードが作成されたことから推定します。 イベントタイプ inferred | |||
| 与信審査の実施 | 顧客の信用力を評価するために、顧客アカウントの与信審査を実施したことを示します。注文処理のワークフロー内で自動または手動で行われることが多く、完了時には通常、ステータスの更新またはタスクの完了として記録されます。 | ||
| 重要な理由 与信審査にかかる時間を分析すると、注文承認のボトルネックを特定できます。「与信審査から確認までの時間」KPIの測定にも欠かせません。 入手先 販売注文のステータスが「与信承認待ち」に変わったことから推定できます。または、与信管理機能のイベントログに明示的に記録されている場合もあります。 記録 注文ステータスの変更、または与信審査タスクに関連付けられたタイムスタンプから推定します。 イベントタイプ inferred | |||
| 受注キャンセル | 出荷がすべて完了する前に受注がキャンセルされたことを示します。さまざまな理由で発生し、最終ステータスは「キャンセル」になります。 | ||
| 重要な理由 これは重要な例外経路です。キャンセルされた受注を分析すると、在庫切れ、価格の問題、顧客の意向変更などの根本原因を特定し、プロセスの改善に役立てられます。 入手先 受注ヘッダーまたは明細のステータスが「キャンセル」に変わったことから推定します。このステータス変更のタイムスタンプをイベントの記録に使用します。 記録 受注ヘッダーまたは明細のステータスが「キャンセル」に変わった時点のタイムスタンプから算出します。 イベントタイプ inferred | |||
| 受注明細クローズ | 個々の受注明細が最終的にクローズされたことを示します。出荷と請求が完了し、以降の取引が予定されていない状態です。システムは明細のステータスを「クローズ」に更新します。 | ||
| 重要な理由 受注明細のクローズは、その品目に関する契約上の義務がすべて完了したことを示します。このアクティビティを分析すると、履行と支払いが完了してから長期間オープンのままになっている受注を特定できます。 入手先 DOO_FULFILL_LINES_ALLテーブルで履行明細のステータスが「クローズ」に変わったことから推定します。このステータス変更のタイムスタンプがイベント時刻になります。 記録 履行明細のステータスが「クローズ」に変わった時点のタイムスタンプから算出します。 イベントタイプ inferred | |||
| 商品のピッキング | 注文を処理するために、倉庫から商品を実際にピッキングすることを示します。物流プロセスの重要な工程であり、通常は倉庫管理または出荷モジュールに記録されます。 | ||
| 重要な理由 このアクティビティにより、倉庫業務の状況を把握できます。在庫引当からピッキングまでの遅延は、倉庫のリソース不足やプロセス上のボトルネックを示している可能性があります。 入手先 Oracle Fusion Cloud SCM(サプライチェーン管理)モジュールに記録されます。販売注文明細に関連付けられたピッキングウェーブまたはピッキング伝票のステータス変更から推定できます。 記録 SCMモジュールに記録されたピッキング取引の完了タイムスタンプから推定します。 イベントタイプ inferred | |||
| 商品の納品 | 顧客が商品を受け取ったことを示します。この情報は外部の運送会社から取得してOracle Fusionに反映されることが多く、出荷日から標準的な輸送日数をもとに推定する場合もあります。 | ||
| 重要な理由 このアクティビティは「納期遵守率」KPIの算出と、顧客サービスレベルの正確な測定に欠かせません。 入手先 Oracle標準のイベントとして記録されないことがよくあります。運送会社との連携が設定されていれば取得できます。または、「商品の出荷」日付に標準的な輸送日数を加えて算出できます。システム分析が必要です。 記録 運送会社のデータフィードから推定するか、出荷日と平均輸送日数をもとに算出します。 イベントタイプ inferred | |||
| 在庫の引当 | 販売注文の明細を処理するために、実在庫を割り当て、確保するアクティビティです。システムが特定の在庫を確保し、注文のピッキング準備が整った時点で利用できるようにします。 | ||
| 重要な理由 このアクティビティを追跡すると、「在庫引当リードタイム」KPIを分析し、注文確認から商品の確保までの遅延を特定できます。 入手先 このイベントは、在庫管理またはサプライチェーン実行のモジュールに記録されることがよくあります。出荷準備明細のステータスが更新され、在庫が詳細化または引当済みになったことから推定できます。 記録 在庫の引当またはスケジュールに関連する出荷準備明細のステータス変更から推定します。 イベントタイプ inferred | |||
| 請求書の修正 | 作成済みの請求書が、誤りや顧客との異議申し立てを受けて修正、再発行、またはクレジット処理されることを示します。通常は、クレジットメモの作成、または請求書の新しいバージョンの作成によって記録されます。 | ||
| 重要な理由 請求書の修正状況を追跡することは、「請求書手戻り率」の重要業績評価指標(KPI)を把握するうえで重要です。請求プロセスの問題を明らかにし、支払いの遅延や事務コストの増加につながる要因を特定できます。 入手先 元の請求書に紐づくクレジットメモ、またはRA_CUSTOMER_TRX_ALLテーブルに記録された同じ請求書の後続バージョンの作成から推定します。 記録 以前の請求書取引を参照するクレジットメモまたは請求書を特定して算出します。 イベントタイプ inferred | |||
データ抽出ガイド
ステップ
- Oracle BI Publisherを開く:BI AdministratorまたはBI Authorの権限を持つユーザーでOracle Fusion環境にログインします。ナビゲーターから「ツール」>「レポートと分析」を開きます。「カタログの参照」をクリックして、Business Intelligenceカタログを開きます。
- 新しいデータモデルを作成する:BIカタログで適切なフォルダー(例:Shared Folders > Custom)を開きます。「新規」ドロップダウンメニューをクリックし、「データモデル」を選択します。
- SQLクエリのデータセットを定義する:データモデルエディターで「+」アイコンをクリックして新しいデータセットを作成し、「SQL Query」を選択します。ダイアログが表示されたら、データセット名(例:「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)と一致することを確認します。これでファイルをプロセスマイニングツールにアップロードできます。
設定
- ユーザー権限:BI Publisherでデータモデルとレポートを作成する権限を持つロールが必要です。例:「BI Administrator」または「BI Author」。
- データソース:このクエリは、トランザクションデータベース(Fusion Apps)に接続する標準の「Oracle BI EE」アプリケーションデータソース向けに設計されています。通常、特別な設定は必要ありません。
- 期間パラメーター:クエリでは、データを絞り込むために:p_start_dateと:p_end_dateの2つのパラメーターを使用します。レポートのタイムアウトやパフォーマンスの問題を避けるため、3~6か月ずつなど、運用しやすい単位でデータを抽出することを強くお勧めします。
- 事業部門による絞り込み:抽出対象を限定するには、クエリのBaseOrders CTEにWHERE句を追加し、特定の事業部門IDで絞り込めます(例:AND dhead.SUBMITTING_BU_ID IN ([Your Business Unit ID]))。
- 注文タイプによる絞り込み:BaseOrders CTEでdhead.SOURCE_ORDER_TYPE_CODEに条件を追加すると、特定の販売注文タイプに絞り込めます。
- パフォーマンス:数年分にわたる非常に大規模なデータセットでは、この単一クエリ方式の処理に時間がかかる場合があります。利用の少ない時間帯に実行するか、月ごとなど小さな単位に分けて抽出してください。複雑なUNIONクエリに影響する可能性があるため、データモデルの「Enable SQL Pruning」プロパティは選択しないでください。
クエリの例 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インスタンスにログインします。「ツール」を開き、メニューから「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(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から必要な列の詳細は、クエリマニフェストを参照してください。
- 増分読み込み用のフィルターを設定する:データ量を管理するため、各PVOのLastUpdateDate列にフィルターを設定します。初回実行では、広い期間を指定できます。以降の定期実行では、前回のジョブ実行後に更新されたレコードだけを抽出するように設定します。
- 抽出ジョブをスケジュールする:「Manage Schedule」を開き、ジョブのスケジュールを新規作成します。システムへの負荷を抑えるため、毎晩など、利用の少ない時間帯に実行することをお勧めします。
- ジョブを送信して監視する:設定が完了したらジョブを送信します。「Manage Extract Jobs」画面で進行状況を確認できます。正常に完了すると、圧縮CSV形式のデータファイルが設定したクラウドストレージに保存されます。
- 生のデータをイベントログに変換する:抽出したCSVファイルをダウンロードします。BICCが提供するのはテーブルの生のデータであり、整形済みのイベントログではありません。ファイルの処理には、Python、データベーススクリプト、ETLプラットフォームなどの外部ツールが必要です。主な作業は次のとおりです。
- 複数のファイルのデータを結合します(例:請求書データを販売注文ヘッダーに関連付けます)。
- 日付列を、アクティビティごとの行に変換します。たとえば、FscmTopModelAM.DooTopAM.HeaderファイルのCreationDateから「販売注文を作成」の行を、ClosedDateから「注文をクローズ」の行を作成します。
- ステータスコードやフラグを、「注文を確認」や「注文をキャンセル」などのアクティビティに対応付けます。
- 変換したデータを、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ロールが必要です。また、クラウドストレージの認証情報を事前に設定し、抽出後に必要となるデータ変換ロジックを明確にしておく必要があります。
クエリの例 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日間の無料トライアルをご利用いただけます。