| Oracle Business Intelligence Applicationsインストレーションおよび構成ガイド リリース7.9.4 E06112-01 |
|
 戻る |
 次へ |
この章では、ビジネス要件に合せて、Order Management and Fulfillment Analyticsを特定のソースに対して構成する方法について説明します。
この章の内容は次のとおりです。
第11.1項「Oracle Order Management and Fulfillment Analyticsの概要」
第11.2項「完全ロード前にOracle Order Management and Fulfillment Analyticsに必要な構成」
Oracle Order Management and Fulfillment Analyticsアプリケーションでは、セールスサイクルの様々なステージにおける販売注文の動きを分析できます。この分析には、どの項目を予約、バックログおよび請求するかについての洞察が含まれます。また、個々の担当営業者や販売部門の販売実績の評価に役立つ情報も提供されます。Oracle Order Management and Fulfillment Analyticsアプリケーションには、機能エリアとして「オーダーおよび売上」があります。
Oracle Order Management and Fulfillment Analyticsアプリケーションは、オーダー、請求およびバックログから構成されます。販売注文は、セールスプロセスへのエントリポイントです。請求は、履行プロセスからの終了ポイントです。バックログは、履行プロセスにおいて輻輳が発生しているポイントです。
Oracle Order Management and Fulfillment Analyticsアプリケーションには、次に示す2つの主要なバックログ・タイプがあります。
出荷待ち
財務
予定済、未予定、延滞および保留のバックログが出荷待ちバックログに該当します。次のソースにより「オーダーおよび売上」にポピュレートできます。
Oracle 11i
Oracle R12
汎用ソース
また、Oracle Order Management and Fulfillment Analyticsアプリケーションでは、テーブルにデータをポピュレートするには、ロード後の処理のマッピングを構成する必要があります。
この項では、データの完全ロードを実行する前にOracle Order Management and Fulfillment Analyticsで実行が必要な構成手順について説明します。この項の内容は次のとおりです。
第11.2.1項「すべてのソース・システム用にOracle Order Management and Fulfillment Analyticsを構成するための手順」
第11.2.2項「Oracle EBS用にOracle Order Management and Fulfillment Analyticsを構成するための手順」
第11.2.3項「PeopleSoft用にOracle Order Management and Fulfillment Analyticsを構成するための手順」
第11.2.4項「Oracle Order Management and Fulfillment Analyticsを構成するための汎用的な手順」
この項では、すべてのソース・システムに適用される構成手順について説明します。
|
注意: すべての分析モジュール（Oracle Financial Analytics、Oracle HR Analytics、Oracle Sales Analyticsなど）に適用される構成手順は、第8章「共通のエリアと次元の構成」を参照してください。 |
この項では、データの完全ロードを実行する前に、Oracle EBSに適用される構成手順について説明します。
次の表に、Oracle Order Management and Fulfillment Analytics用のCSVワークシート・ファイルとドメイン値の一覧を示します。これらのファイルは、$pmserver\LkpFilesフォルダにあります。
表11-1 Oracle Order Management and Fulfillment Analytics用のドメイン値とCSVワークシート・ファイル
| ワークシート・ファイル名 | 説明 | セッション |
|---|---|---|
|
domainValues_InvoiceTypes_ora11i.csv |
請求ドキュメント・タイプのカラムと、Oracle 11iまたはOracle R12のアプリケーションに対応するドメイン値の一覧です。 このファイルの値を更新する方法の詳細は、第11.2.2.2項「請求タイプのドメイン値の構成方法」を参照してください。 |
SDE_ORA_TransactionTypeDimension_SalesInvoiceLines |
|
domainValues_PickTypes_ora11i.csv |
在庫出しドキュメント・タイプのカラムと、Oracle 11iまたはOracle R12のアプリケーションに対応するドメイン値の一覧です。 このファイルの値を更新する方法の詳細は、第11.2.2.3項「在庫出しタイプのドメイン値の構成方法」を参照してください。 |
SDE_ORA_TransactionTypeDimension_SalesPickLines |
|
domainValues_OrderTypes_ora11i.csv |
オーダー・ドキュメント・タイプのカラムと、Oracle 11iまたはOracle R12のアプリケーションに対応するドメイン値の一覧です。 このファイルの値を更新する方法の詳細は、第11.2.2.4項「オーダータイプのドメイン値の構成方法」を参照してください。 |
SDE_ORA_TransactionTypeDimension_SalesOrderLines |
|
domainValues_PickStatus_ora11i.csv |
在庫出し状況コードおよび状況説明のカラムと、Oracle 11iまたはOracle R12のアプリケーションに対応するドメイン値の一覧です。 このファイルの値を更新する方法の詳細は、第11.2.2.5項「在庫出し状況のドメイン値の構成方法」を参照してください。 |
SDE_ORA_StatusDimension_SalesPickLines |
|
domainValues_PayMethodCode_ora11i.csv |
方法コードのカラムと、アプリケーションに対応するドメイン値の一覧です。 |
SDE_ORA_PaymentMethodDimension |
|
domainValues_InvoiceStatus_ora11i.csv |
請求状況コードおよび状況説明のカラムと、Oracle 11iまたはOracle R12のアプリケーションに対応するドメイン値の一覧です。 このファイルの値を更新する方法の詳細は、第11.2.2.6項「請求状況のドメイン値の構成方法」を参照してください。 |
SDE_ORA_StatusDimension_SalesInvoiceLine |
|
DomainValue_OrderOverallStatus_ora11i.csv |
注文状況コードのカラムと、Oracle 11iまたはOracle R12のアプリケーションに対応するドメイン値の一覧です。 このファイルの値を更新する方法の詳細は、第11.2.2.7項「オーダー全般状況のドメイン値の構成方法」を参照してください。 |
SDE_ORA_StatusDimension_SalesOrderLineCycle |
CSVワークシート・ファイルのドメイン値の詳細は、第6.12項「ドメイン値について」および第6.13項「CSVワークシート・ファイルによるドメイン値セットの構成」を参照してください。
この項では、domainValues_InvoiceTypes_ora11i.csvファイルを使用して、請求タイプのドメイン値を構成する方法について説明します。
請求タイプのドメイン値を構成する手順は次のとおりです。
次のSQLを使用して、Oracle 11iソース・システムの請求タイプを特定します。
SELECT DISTINCT RA_CUST_TRX_TYPES_ALL.TYPE
FROM RA_CUST_TRX_TYPES_ALL
ORDER BY 1;
$pmserver\lkpfilesフォルダにあるdomainValues_InvoiceType_ora11i.csvファイルをテキスト・エディタで開きます。
TYPEカラムをこのファイルのXACT_TYPE_CODEカラムにコピーします。
2行目以降のデータをコピーしてください。最初の行はカラム・ヘッダーです。
各トランザクションタイプ・コードを1つのドメイン値にマッピングします。
トランザクションタイプ・コードのドメイン値の詳細は、『Oracle Business Analytics Warehouse Data Model Reference』を参照してください。
ファイルを保存し閉じます。
この項では、domainValues_PickTypes_ora11i.csvファイルを使用して、在庫出しタイプのドメイン値を構成する方法について説明します。
在庫出しタイプのドメイン値を構成する手順は次のとおりです。
Oracle 11iソース・システムの在庫出しタイプを特定します。
$pmserver\lkpfilesフォルダにあるdomainValues_PickType_ora11i.csvファイルをテキスト・エディタで開きます。
ファイルのXACT_TYPE_CODEカラムにSTANDARDを挿入します。
2行目以降のデータをコピーしてください。最初の行はカラム・ヘッダーです。
各トランザクションタイプ・コードを1つのドメイン値にマッピングします。
トランザクションタイプ・コードのドメイン値の詳細は、『Oracle Business Analytics Warehouse Data Model Reference』を参照してください。
ファイルを保存し閉じます。
この項では、domainValues_OrderTypes_ora11i.csvファイルを使用して、オーダータイプのドメイン値を構成する方法について説明します。
オーダータイプのドメイン値を構成する手順は次のとおりです。
次のSQLを使用して、Oracle 11iソース・システムの在庫出しタイプを特定します。
SELECT DISTINCT FND_LOOKUP_VALUES.LOOKUP_CODE
FROM FND_LOOKUP_VALUES
WHERE FND_LOOKUP_VALUES.VIEW_APPLICATION_ID = 660
AND FND_LOOKUP_VALUES.LANGUAGE = 'US'
AND FND_LOOKUP_VALUES.LOOKUP_TYPE = 'LINE_CATEGORY'
ORDER BY 1;
$pmserver\lkpfilesフォルダにあるdomainValues_OrderType_ora11i.csvファイルをテキスト・エディタで開きます。
このファイルのXACT_TYPE_CODEカラムにLOOKUP_TYPEカラムをコピーします。
2行目以降のデータをコピーしてください。最初の行はカラム・ヘッダーです。
各トランザクションタイプ・コードを1つのドメイン値にマッピングします。
トランザクションタイプ・コードのドメイン値の詳細は、『Oracle Business Analytics Warehouse Data Model Reference』を参照してください。
ファイルを保存し閉じます。
この項では、domainValues_PickStatus_ora11i.csvファイルを使用して、在庫出し状況のドメイン値を構成する方法について説明します。
在庫出し状況のドメイン値を構成する手順は次のとおりです。
次のSQLを使用して、Oracle 11iソース・システムの在庫出し状況を特定します。
SELECT DISTINCT FND_LOOKUP_VALUES.LOOKUP_CODE
FROM FND_LOOKUP_VALUES
WHERE FND_LOOKUP_VALUES.LOOKUP_TYPE= 'PICK_STATUS'
AND FND_LOOKUP_VALUES.LANGUAGE = 'US'
AND FND_LOOKUP_VALUES.VIEW_APPLICATION_ID = 665
AND FND_LOOKUP_VALUES.SECURITY_GROUP_ID = 0
ORDER BY 1;
$pmserver\lkpfilesフォルダにあるdomainValues_PickStatus_ora11i.csvファイルをテキスト・エディタで開きます。
このファイルのSTATUS_CODEカラムにLOOKUP_CODEカラムをコピーします。
2行目以降のデータをコピーしてください。最初の行はカラム・ヘッダーです。
各状況コードを1つのドメイン値にマッピングします。
状況コードのドメイン値の詳細は、『Oracle Business Analytics Warehouse Data Model Reference』を参照してください。
ファイルを保存し閉じます。
この項では、domainValues_InvoiceStatus_ora11i.csvファイルを使用して、請求状況のドメイン値を構成する方法について説明します。
請求状況のドメイン値を構成する手順は次のとおりです。
次のSQLを使用して、Oracle 11iソース・システムの請求状況を特定します。
SELECT DISTINCT FND_LOOKUP_VALUES.LOOKUP_CODE
FROM FND_LOOKUP_VALUES
WHERE FND_LOOKUP_VALUES.LOOKUP_TYPE= 'INVOICE_TRX_STATUS' AND
FND_LOOKUP_VALUES.LANGUAGE = 'US'
AND FND_LOOKUP_VALUES.VIEW_APPLICATION_ID = 222
AND FND_LOOKUP_VALUES.SECURITY_GROUP_ID = 0
ORDER BY 1;
$pmserver\lkpfilesフォルダにあるdomainValues_InvoiceStatus_ora11i.csvファイルをテキスト・エディタで開きます。
このファイルのSTATUS_CODEカラムにLOOKUP_CODEカラムをコピーします。
2行目以降のデータをコピーしてください。最初の行はカラム・ヘッダーです。
各状況コードを1つのドメイン値にマッピングします。
状況コードのドメイン値の詳細は、『Oracle Business Analytics Warehouse Data Model Reference』を参照してください。
ファイルを保存し閉じます。
この項では、domainValues_OrderOverallStatus_ora11i.csvファイルを使用して、オーダー全般状況のドメイン値を構成する方法について説明します。
オーダー全般状況のドメイン値を構成する手順は次のとおりです。
次のSQLを使用して、Oracle 11iソース・システムのオーダー全般状況を特定します。
SELECT DISTINCT FND_LOOKUP_VALUES.LOOKUP_CODE
FROM FND_LOOKUP_VALUES
WHERE FND_LOOKUP_VALUES.LOOKUP_TYPE = 'LINE_FLOW_STATUS'
AND FND_LOOKUP_VALUES.LANGUAGE = 'US'
AND FND_LOOKUP_VALUES.VIEW_APPLICATION_ID = 660
AND FND_LOOKUP_VALUES.SECURITY_GROUP_ID = 0
ORDER BY 1;
$pmserver\lkpfilesフォルダにあるdomainValues_OrderOverallStatus_ora11i.csvファイルをテキスト・エディタで開きます。
このファイルのSTATUS_CODEカラムにLOOKUP_CODEカラムをコピーします。
2行目以降のデータをコピーしてください。最初の行はカラム・ヘッダーです。
各状況コードを1つのドメイン値にマッピングします。
状況コードのドメイン値の詳細は、『Oracle Business Analytics Warehouse Data Model Reference』を参照してください。
ファイルを保存し閉じます。
この項では、domainValues_PayMethodCode_ora11i.csvファイルを使用して、支払い方法のドメイン値を構成する方法について説明します。
支払い方法のドメイン値を構成する手順は次のとおりです。
次のSQLを使用して、Oracle 11iソース・システムの支払い方法を特定します。
SELECT DISTINCT FND_LOOKUP_VALUES.LOOKUP_CODE
FROM FND_LOOKUP_VALUES
WHERE LOOKUP_TYPE = 'PAYMENT TYPE'
AND VIEW_APPLICATION_ID = 660
AND LANGUAGE = 'US'
AND FND_LOOKUP_VALUES.SECURITY_GROUP_ID = 0
ORDER BY 1;
$pmserver\lkpfilesフォルダにあるdomainValues_PayMethodCode_ora11i.csvファイルをテキスト・エディタで開きます。
このファイルのMETHOD_CODEカラムにLOOKUP_CODEカラムをコピーします。
2行目以降のデータをコピーしてください。最初の行はカラム・ヘッダーです。
各方法コードを1つのドメイン値にマッピングします。
方法コードのドメイン値の詳細は、『Oracle Business Analytics Warehouse Data Model Reference』を参照してください。
ファイルを保存し閉じます。
この項では、データの完全ロードを実行する前に、PeopleSoftに適用される構成手順について説明します。
リリース7.9.4のOracle BI Applicationsには該当しません。
この項では、データの完全ロードを実行する前に、汎用的に適用される必要な構成手順について説明します。
リリース7.9.4のOracle BI Applicationsには該当しません。
この項では、Oracle Order Management and Fulfillment Analyticsの追加構成手順について説明します。この項の内容は次のとおりです。
第11.2.5.1項「すべてのソース・システム用にOracle Order Management and Fulfillment Analyticsを構成するための手順」
第11.2.5.2項「Oracle EBS用にOracle Order Management and Fulfillment Analyticsを構成するための手順」
第11.2.5.3項「PeopleSoft用にOracle Order Management and Fulfillment Analyticsを構成するための手順」
第11.2.5.4項「Oracle Order Management and Fulfillment Analyticsを構成するための汎用的な手順」
この項では、すべてのソース・システムに適用される構成手順について説明します。
デフォルトのVAR_BOOKING_IDカラムを変更するときは、Oracle 11iおよびOracle R12に対してSQL文を次のように構成します。
TO_CHAR(INP_LINE_ID)||'~'||TO_CHAR(INP_INV_ITEM_ID)||'~'||to_char(INP_WAREHOUSE_ID)
ただし、複数の属性に基づいた変更を追跡する場合は、SQL文でVAR_BOOKING_IDカラムの属性カラムIDを連結する必要があります。たとえば、営業担当者と顧客における変更を追跡する場合は、VAR_BOOKING_IDカラムでテクニカル名IDを次のように連結します。
TO_CHAR(INP_LINE_ID)||'~'||TO_CHAR(INP_INV_ITEM_ID)||'~'||TO_CHAR(INP_WAREHOUSE_ID)||'~'||TO_CHAR(INP_SALESREP_ID)||'~'||TO_CHAR(INP_CUSTOMER_ID)
予約における次元属性の変更を追跡するには:
PowerCenter Designerで、SDE_ORA115<ver>_adapterフォルダまたはSDE_ORAR12_adapterフォルダを開きます。
mplt_SA_ORA_SalesOrderLinesFactマップレットを開きます。
「EXP_SALES_ORDLNS Expression transformation」をダブルクリックして、「Edit Transformations」ボックスを開きます。
「Ports」タブで、VAR_BOOKING_IDポートに対する式を編集し、変更を追跡する属性のIDを入力します。
複数の属性の変更を追跡する場合は、すべての属性のIDを連結し、連結値をVAR_BOOKING_IDカラムに挿入します。
変更を確認し、リポジトリに保存します。
この項では、Sales Invoice LinesテーブルおよびSales Order Linesテーブルの集計におけるOracle Order Management and Fulfillment Analyticsの構成ポイントについて説明します。
集計プロセスでは、次のTeradataパラメータが使用されます。
Hint_Tera_Pre_Cast
Hit_Tera_Post_Cast
Sales Invoice LinesテーブルおよびSales Order Linesテーブルを集計するには、次の作業を実行します。
Sales Invoice Lines集計テーブルの構成
Sales Order Lines集計テーブルの構成
Sales Invoice Lines集計テーブルの構成について
Sales Invoice Lines集計テーブル（W_SALES_INVOICE_LINE_F_A）は、販売注文に対して発行された請求書に関する情報を取得する目的で使用されます。初期ETLおよび増分ETLを実行するには、Sales Invoice Lines集計テーブルを構成する必要があります。
初期ETLを実行する場合は、Sales Invoice Lines要素テーブルの時間集計レベルに対して、TIME_GRAINパラメータを構成する必要があります。
増分ETLを実行する場合は、時間集計レベルを構成する必要があります。
Sales Invoice Linesテーブルに対して増分集計を実行するには、TIME_GRAINパラメータを構成する必要があります。
TIME_GRAINパラメータのデフォルト値はMonthです。TIME_GRAINパラメータには、次の値を指定できます。
'DAY'
'WEEK'
'MONTH'
'QUARTER'
'YEAR'
集計プロセスでは、次のTeradataパラメータが使用されます。
Hint_Tera_Pre_Cast
Hit_Tera_Post_Cast
初期ETLの実行時には、Sales Invoice Lines集計テーブルが基本テーブルから完全ロードされます。テーブルのレコードは、数百万件になる可能性があります。そのため、以降の増分ETLの実行時には、Sales Invoice集計テーブルが基本テーブルから再び完全ロードされることはありません。Oracle Business Analytics Warehouseでは、基本テーブルの更新に伴い集計テーブルを増分的に変更することで、増分集計の負荷が最小限になります。このプロセスの説明を次に示します。
Oracle Business Analytics Warehouseは、前回のETL実行以降に基本テーブルから削除されたレコードを探して、削除レコードがある場合はそれらのレコードをW_SALES_INVOICE_LINE_TMPテーブルにロードします。これらのレコードのメジャーは、-1で乗算されます。この処理を実行するマッピングは、SIL_SalesInvoiceLinesAggregate_Derive_PreSoftDeleteImageです。これは、SIL_SalesInvoiceLinesFact_SoftDeleteによって基本テーブルからレコードが削除される前に実行されます。
Oracle Business Analytics Warehouseは、前回のETL実行以降に基本テーブルにおいて更新されたレコードを探して、更新レコードがある場合はそれらのレコードをW_SALES_INVOICE_LINE_TMPテーブルにロードします。これらのレコードのメジャーは、-1で乗算されます。この処理を実行するマッピングは、SIL_SalesInvoiceLinesFact_Derive_PreLoadImageです。これは、SIL_SalesInvoiceFactによって基本テーブルからレコードが削除される前に実行されます。
Oracle Business Analytics Warehouseは、前回のETL実行以降に基本テーブルに挿入されたり更新されたりしたレコードを探して、それらのレコードがある場合は、該当レコードの署名を変更せずにW_SALES_INVOICE_LINE_TMPテーブルにそれらをロードします。この処理を実行するマッピングは、SIL_SalesInvoiceLinesFact_Derive_PreLoadImageです。これは、PLP_SalesInvoiceLinesFact_Derive_PostLoadImageによって基本テーブルにレコードが挿入されたり更新されたりする前に実行されます。
Oracle Business Analytics WarehouseはW_SALES_INVOICE_LINE_TMPテーブルを集計し、W_SALES_INVOICE_LINE_Aと同じ粒度のW_SALES_INVOICE_LINE_A_TMPにロードします。
PLP_SalesInvoiceLinesAggregate_DeriveマッピングによりW_SALES_INVOICE_LINE_A集計テーブルを検索し、集計テーブルに対して既存バケットが更新されるか、新規バケットが挿入されるかします（このマッピングはPLP_SalesInvoiceLinesAggregate_Load）。
Sales Invoice Lines集計テーブルの構成方法
Sales Invoice Lines集計テーブル（W_SALES_INVOICE_LINE_A）をロードするには、parameterfileDW.txtファイルを構成し、初期ワークフローと増分ワークフローを実行する必要があります。
parameterfileDW.txtパラメータ・ファイルを構成するには:
parameterfileDW.txtファイルをテキスト・エディタで開きます。
このファイルはOracleBI\DAC\Informatica\parameters\inputフォルダにあります。
デフォルトの値を新しい値で置き換えます。
ファイルを保存し閉じます。
Sales Order Lines集計テーブルの構成について
Sales Order Lines集計テーブル（W_SALES_ORDER_LINE_A）は、販売注文に対して発行された注文明細に関する情報を取得する目的で使用されます。初期ETLおよび増分ETLを実行するには、Sales Order Lines集計テーブルを構成する必要があります。
初期ETLを実行する場合は、Sales Order Lines要素テーブルの時間集計レベルに対して、TIME_GRAINパラメータを構成する必要があります。
増分ETLを実行する場合は、時間集計レベルを構成する必要があります。
Sales Invoice Linesテーブルに対して増分集計を実行するには、TIME_GRAINパラメータを構成する必要があります。
TIME_GRAINパラメータのデフォルト値はMonthです。GRAINパラメータには、次の値を指定できます。
'DAY'
'WEEK'
'MONTH'
'QUARTER'
'YEAR'
集計プロセスでは、次のTeradataパラメータが使用されます。
Hint_Tera_Pre_Cast
Hit_Tera_Post_Cast
初期ETLの実行時には、Sales Order Lines集計テーブルは基本テーブルから全体ロードされます。テーブルのレコードは、数百万件になる可能性があります。そのため、以降の増分ETLの実行時には、Sales Order集計テーブルが基本テーブルから再び全体ロードされることはありません。Oracle Business Analytics Warehouseでは、基本テーブルの更新に伴い集計テーブルを増分的に変更することで、増分集計の負荷が最小限になります。このプロセスの説明を次に示します。
Oracle Business Analytics Warehouseは、前回のETL実行以降に基本テーブルから削除されたレコードを探して、削除レコードがある場合はそれらのレコードをW_SALES_ORDER_LINE_TMPテーブルにロードします。これらのレコードのメジャーは、-1で乗算されます。この処理を実行するマッピングは、SIL_SalesOrderLinesAggregate_Derive_PreSoftDeleteImageです。これは、SIL_SalesOrderLinesFact_SoftDeleteによって基本テーブルからレコードが削除される前に実行されます。
Oracle Business Analytics Warehouseは、前回のETL実行以降に基本テーブルにおいて更新されたレコードを探して、更新レコードがある場合はそれらのレコードをW_SALES_ORDER_LINE_TMPテーブルにロードします。これらのレコードのメジャーは、-1で乗算されます。この処理を実行するマッピングは、SIL_SalesOrderLinesFact_Derive_PreLoadImageです。これは、SIL_SalesOrderFactによって基本テーブルからレコードが削除される前に実行されます。
Oracle Business Analytics Warehouseは、前回のETL実行以降に基本テーブルに挿入されたり更新されたりしたレコードを探して、それらのレコードがある場合は、該当レコードの署名を変更せずにW_SALES_ORDER_LINE_TMPテーブルにそれらをロードします。この処理を実行するマッピングは、SIL_SalesOrderLinesFact_Derive_PreLoadImageです。これは、PLP_SalesOrderLinesFact_Derive_PostLoadImageによって基本テーブルにレコードが挿入されたり更新されたりする前に実行されます。
Oracle Business Analytics WarehouseはPLP_SalesOrderLinesAggregate_Deriveを使用してW_SALES_ORDER_LINE_TMPテーブルを集計し、W_SALES_ORDER_LINE_Aと同じ粒度のW_SALES_ORDER_LINE_A_TMPにロードします。
W_SALES_ORDER_LINE_A_TMPによりW_SALES_ORDER_LINE_A集計テーブルを検索し、集計テーブルに対して既存バケットが更新されるか、新規バケットが挿入されるかします（このマッピングはPLP_SalesOrderLinesAggregate_Load）。
Sales Order Lines集計テーブルの構成方法
Sales Order Lines集計テーブル（W_SALES_ORDER_LINE_A）をロードするには、ロード後処理のパラメータ・ファイルとソース･システムのパラメータ・ファイルを構成し、初期ワークフローと増分ワークフローを実行する必要があります。
Sales Order Lines集計テーブルを構成するには:
parameterfileDW.txtファイルをテキスト・エディタで開きます。
このファイルはOracleBI\DAC\Informatica\parameters\inputフォルダにあります。
デフォルトの値を新しい値で置き換えます。
ファイルを保存し閉じます。
複数の製品が単体化され1つのパッケージとして販売される場合は、Sales Order Linesテーブルにある2つのカラム（ORDHD_KEY_IDとORDLN_KEY_ID）を使用することで、それらの製品を追跡します。これらの2つのカラムにより、単体として販売されるすべての製品間の関係を分析できます。ORDHD_KEY_IDカラムには、販売注文全体の注文IDが格納されます。ORDLN_KEY_IDカラムには、親製品の明細項目IDが格納されます。
たとえば、ある顧客がコンピュータ、スキャナ、プリンタから成るパッケージを購入したとします。これらとは別に、その顧客はモニターも購入したとします。この場合は、パッケージとモニターという2つの親項目があります。コンピュータ、スキャナおよびプリンタはすべて、親注文であるパッケージの子注文となり、モニターは1つの項目から成る親注文となります。
表11-2に示すように、データ・ウェアハウスではこの販売情報がSales Order Linesテーブルに格納されます。ORDLN_KEY_IDフィールドには親製品の明細項目IDが格納され、それによりパッケージ内の製品の親子関係情報を管理します。この例のORDLN_KEY_IDフィールドには、親パッケージである親Aの一部として販売された3つの子製品（A1、A2、A3）に対して、それぞれLine_1が指定されています。
表11-2 親子関係があるSales Orderテーブルのカラム
| Key_ID | SALES_ORDER_NUM | PRODUCT_ID | ORDHD_ KEY_ID | ORDLN_ KEY _ID | 関係（テーブルのカラムではありません） |
|---|---|---|---|---|---|
|
Line_1 |
1000 |
Package |
1000 |
Line_1 |
親A |
|
Line_2 |
1000 |
Computer |
1000 |
Line_1 |
子A1 |
|
Line_3 |
1000 |
Scanner |
1000 |
Line_1 |
子A2 |
|
Line_4 |
1000 |
Printer |
1000 |
Line_1 |
子A3 |
|
Line_5 |
1000 |
Monitor |
1000 |
Line_5 |
親B（子はなし） |
これとは対照的に、表11-2の4つの項目がすべて個々の製品として購入された場合は、ORDLN_KEY_IDの各行に異なる明細項目IDが指定されます。この場合のSales Order Linesテーブルは、表11-3のようになります。
Order Cycle Timeテーブルに日付をさらに追加するには、このテーブルがどのようにポピュレートされるかを理解する必要があります。つまり、Order Cycle Timeテーブル（W_SALES_CYCLE_LINE_F）にロードする日付を変更するには、W_*テーブルから日付を取得しOrder Cycle TimeテーブルにロードするPLP_SalesCycleLinesFact_LoadマッピングとPLP_SalesCycleLinesFact_Load_Fullマッピングを変更する必要があります。
Order Cycle Timeテーブルにロードする日付を追加するには:
PowerCenter Designerで、ロード後処理用の構成フォルダを開きます。
Warehouse Designerで、ターゲット・テーブルのテーブル定義を変更し、追加する日付を格納するフィールドを確認します。
たとえば、検証日をW_SALES_CYCLE_LINE_Fテーブルにロードする場合は、新しいカラムであるVALIDATED_ON_DTを作成し、W_SALES_CYCLE_LINE_Fテーブルのターゲット定義を変更する必要があります。
Source Analyzerで、ソース・テーブルのテーブル定義を変更し、この新しいカラムが含まれるようにします。
この例では、W_SALES_CYCLE_LINE_Fソース・テーブルにVALIDATED_ON_DTカラムが含まれるようにします。
PLP_SalesCycleLinesFact_LoadマッピングとPLP_SalesCycleLinesFact_Load_Fullマッピングを変更し、次のいずれかのソース・テーブルから新しいカラムを選択し、それがW_SALES_CYCLE_LINE_Fターゲット・テーブルにロードされるようにします。
W_SALES_ORDER_LINE_F
W_SALES_INVOICE_LINE_F
W_SALES_PICK_LINE_F
W_SALES_SCHEDULE_LINE_F
マッピングのソース修飾子のSQLオーバーライドを変更し、変換内のカラムをターゲット・テーブルにマッピングします。
Backlogテーブル（W_SALES_BACKLOG_LINE_F）には、現在の月のバックログ・データが格納されます。一方、Backlog Historyテーブル（W_SALES_BACKLOG_LINE_F）には、それまでのすべての月のバックログ履歴データのスナップショットが格納されます。Backlog Historyテーブルによりバックログ・データを追跡する期間は、バックログ期間日により定義されます。バックログ期間日は、デフォルトで現在の月の最終カレンダー日に設定されますが、この日はユーザーが構成可能です。必要な場合は、月ではなく日や週などの詳細なレベルで、バックログ履歴を参照できます。次の項では、バックログ履歴データの格納例を示し、バックログ期間日を変更した場合の影響について説明します。
たとえば、製造会社の営業担当者に対して、受注したが代金を請求していない項目として財務バックログが定義されているとします。2001年2月1日に、30個の製品を受注しました（販売注文番号1）。20個の製品は出荷し請求処理を行いましたが、10個の製品は出荷はしたものの請求処理は行っていません。この日の終了時点では、BacklogテーブルとBacklog Historyテーブルに、この取引のエントリがあります。Backlog Historyテーブルのエントリは、表11-4に示すような内容になります。
表11-4 Oracle 11iおよびOracle R12: 2001年2月1日時点におけるBacklog Historyテーブルのエントリ
| SALES_ORDER_NUM（販売注文番号） | BACKLOG _DK（バックログ日） | BACKLOG_PERIOD_DK（バックログ期間日） | OPEN_QTY（バックログ数量） |
|---|---|---|---|
|
1 |
02/01/2001 |
02/28/2001 |
10 |
2月2日に、10項目ある財務バックログ項目の中の5項目で請求処理を行い、バックログから消去しました。その結果、Backlog Historyテーブルの既存行が更新され、表11-5のようになります。
表11-5 Oracle 11iおよびOracle R12: 2001年2月2日時点におけるBacklog Historyテーブルのエントリ
| SALES_ORDER_NUM（販売注文番号） | BACKLOG _DK（バックログ日） | BACKLOG_PERIOD_DK（バックログ期間日） | OPEN_QTY（バックログ数量） |
|---|---|---|---|
|
1 |
02/01/2001 |
02/28/2001 |
旧値: 10 新値: 5 |
その後、3月1日までこのままの状態が続きました。3月1日、財務バックログの残りの5項目で請求処理を行い、財務バックログから消去しました。さらに、50項目の新規注文を受けました（販売注文番号2）。財務バックログには、この50項目が記録されます。
販売注文番号1のすべての項目が財務バックログから消去されても、Backlog Historyテーブルの最終バックログ行は残ります。最終行が保持される目的は、この注文にバックログがあったことを示すことにあります。バックログ数量（この場合は5項目）は、最初のバックログ数量（この場合は10）を示していません。
Backlog Historyテーブルには、50項目の新しい財務バックログに対するエントリが記録されます。2001年2月28日終了時点でのBacklog Historyテーブルは、表11-6に示すような内容になります。
表11-6 Oracle 11i: 2001年2月28日終了時点におけるBacklog Historyテーブルのエントリ
| SALES_ORDER_NUM（販売注文番号） | BACKLOG _DK（バックログ日） | BACKLOG_PERIOD_DK（バックログ期間日） | OPEN_QTY（バックログ数量） |
|---|---|---|---|
|
1 |
旧値: 02/01/2001 新値: 02/02/2001 |
02/28/2001 |
旧値: 10 新値: 5 |
3月1日、さらに30項目の注文を受け（販売注文番号3）、財務バックログに記録されました。記録後のBacklog Historyテーブルは、表11-7のようになります。
表11-7 Oracle 11iおよびOracle R12: 2001年3月1日時点におけるBacklog Historyテーブルのエントリ
| SALES_ORDER_NUM（販売注文番号） | BACKLOG _DK（バックログ日） | BACKLOG_PERIOD_DK（バックログ期間日） | OPEN_QTY（バックログ数量） |
|---|---|---|---|
|
1 |
旧値: 02/01/2001 新値: 02/02/2001 |
02/28/2001 |
5 |
|
2 |
03/01/2001 |
03/31/2001 |
50 |
|
3 |
03/01/2001 |
03/31/2001 |
30 |
バックログ履歴は月レベルで保持されるため、バックログ履歴の内容は部分的なものとなります。表11-7に示された最新のBacklog Historyテーブルからは、販売注文番号1には、5項目の財務バックログ項目が残されていたことがわかります。この販売注文における最初の財務バックログ項目数量が不明ですが、前月末時点での数量のみが判明しています。
バックログにおける項目の変動状況をより詳細に追跡管理する場合は、より綿密な粒度レベルで履歴を保持する必要があります。たとえば、バックログのオープン時に記録された項目数量を調べる必要がある場合は、バックログ履歴を月レベルではなく日レベルで追跡管理する必要があります。
たとえば、バックログ履歴を日レベルで保持すると、2月1日終了時点での販売注文1の最初のバックログ数量が10で、それが2月2日に5に減少したことが判明します。このように、履歴を日レベルで追跡管理することにより、項目がバックログから消去されるまでの経過日数であるサイクル時間を算出できます。ただし、バックログ履歴を日レベルで追跡管理すると、Backlog Historyテーブルのサイズが急激に肥大化することがあります。このため、詳細レベルでバックログ履歴を記録すると、パフォーマンスが低下する場合があります。
バックログ履歴データを保持する期間を変更する場合は、すべてのタイプのバックログが同じレベルで格納されるように確認する必要がありますが、それには複数のマッピングを変更する必要があります。表11-8に、該当するすべてのマッピングと、変更が必要なそれらの式変換を示します。
表11-8 Oracle 11iおよびOracle R12: バックログ履歴用のマッピングと式変換
| マッピング | 式変換 |
|---|---|
|
|
|
|
|
|
バックログ履歴期間のデフォルトは月です。BACKLOG_PERIOD_DKポートに対する式変換のデフォルトSQL文は、次のとおりです。
TO_DECIMAL(TO_CHAR(LAST_DAY(CALENDAR_DATE),'YYYYMMDD'))
バックログ期間日を編集し詳細なバックログ履歴を保持するには、次の値を設定します。設定可能な期間は、日（CAL_DAY_DT）、週（CAL_WEEK_DT）、月（CAL_MONTH_DT）および四半期（CAL_QTR_DT）です。
Oracle Order Management and Fulfillment Analyticsでは、W_CUSTOMER_STATUS_HIST_Fは、注文の頻度に基づいて顧客の状況を追跡管理する要素テーブルです。可能な状況値は、NEW、RECENT、DORMANTおよびLOSTです。各状況バケットの期間は構成可能ですが、出荷時の設定はカレンダー年です。このテーブルの単位は、顧客、顧客状況および状況開始日のレベルです。この後の項では、このテーブルに適用可能な構成手順、その意味および実装方法について説明します。
この項では、Customer Status History要素テーブルに適用可能な次の構成について説明します。
データ・ウェアハウス識別子の構成
各状況バケットの期間の構成
データ・ウェアハウス識別子の構成
このテーブルでは、Oracle Business Intelligence Applicationsで定義されている状況（NEW、RECENT、DORMANT、LOSTなど）がいくつか使用されます。これらの状況データは、事前パッケージされたデフォルトCSVファイルから直接データ・ウェアハウスにロードされます。このファイルのデータは、各企業の顧客データや販売データが格納されたOLTPソース・システムとは無関係です。事前パッケージされたデフォルト・データ・ウェアハウス状況とソースベースの状況を区別するには、固有の識別子が必要です。Informaticaマッピング・パラメータの$$WH_DATASOURCE_NUM_IDが、この目的に対応します。
事前パッケージされたデフォルト値には、識別子値として999が設定されています。特別な事情のないかぎり、組織のデータソース（Oracle EBS 11.5.10など）には、この値（999）を構成しないでください。
$$WH_DATASOURCE_NUM_ID値の構成方法の詳細は、第11.2.5.1.9項「Customer Status History要素テーブルの構成方法」を参照してください。
各状況バケットの期間の構成
ある顧客が製品やサービスを初めて注文すると、その顧客の状況がOracle Business Intelligence ApplicationsによりNEWに設定されます。その後、顧客が一定の注文パターンを示す場合、各注文間の間隔が構成可能なビジネス定義期間よりも短いかぎり、その顧客の状況は同じ状況のままになります。このInformaticaパラメータである$$PERIODの値（デフォルトは365日）は構成可能です。通常、商品販売の回転頻度が高い業種（小売業など）の多くの企業では、この期間値は30日に定義しています。一方、販売回転頻度が低い業種の企業では、この期間が730日でも問題がない場合があります。
顧客がこの期間に一度も注文しなかった場合、その顧客の状況は次の状況であるRECENTになります。同様に、RECENTになってから対象期間に一度も注文しないと、状況はDORMANTになります。最後に、DORMANTになってから対象期間に一度も注文しないと、状況がLOSTに設定されます。
ただし、DORMANT状況の顧客が注文すると、顧客の状況はRECENTに戻ります。同様に、LOST状況の顧客が注文した場合も、状況はRECENTに戻ります。
これらの例で示すように、この期間を適切な値に設定することはビジネスにとって重要です。多くの組織では、顧客の現在の状況（つまり、注文パターン）に基づいて顧客を区分し、各状況の顧客に応じて異なるキャンペーンを企画して、異なる方法で実行する傾向にあります。
$$PERIODの構成方法の詳細は、第11.2.5.1.9項「Customer Status History要素テーブルの構成方法」を参照してください。
この項では、$$WH_DATASOURCE_NUM_ID変数と$$PERIOD変数を使用して、Customer Status History要素テーブルを構成する手順について説明します（これらの変数の詳細は、第11.2.5.1.8項「Customer Status History要素テーブルの構成」を参照）。
$$WH_DATASOURCE_NUM_IDの値を変更する手順は次のとおりです。
DACリポジトリにログオンし、「Design」タブを表示します。
各自のOLTPソース・システムに対応するコンテナにナビゲートします。
「Source System Parameters」タブを表示し、$$WH_DATASOURCE_NUM_IDパラメータを探します。
「Edit」ペインで、「Value」フィールドを使用して値を指定します。
変更を保存します。
DACリポジトリにログオンし、「Design」タブを表示します。
各自のOLTPソース・システムに対応するコンテナにナビゲートします。
「Tasks」タブをクリックして、次の2つのタスクに対してクエリーします。
PLP_CustomerStatusHistoryFact_New_Customers_Load
PLP_CustomerStatusHistoryFact_Status_Revalidate
各タスクに対して、「Parameters」タブを表示し、「Value」フィールドを使用して値を指定します。
両方のタスクに対して、必ず同じ値を指定します。
変更を保存します。
この項では、Oracle EBSに適用される構成手順について説明します。
販売注文明細は、販売注文を構成する項目明細です。この情報はW_SALES_ORDER_LINE_Fテーブルに格納されます。ここでは、このテーブルに格納される情報のタイプを変更する方法について説明します。
デフォルトでは、図11-1に示すように、予約オーダーのみがOracleソース・システムから抽出されます。そのため、Sales Order LinesテーブルとBookingsテーブルにロードされるすべての注文は予約されたものです。
未予約の注文をSales Order Linesテーブルにロードする場合は、未予約注文がフィルターで除外されないように抽出を構成する必要があります。Oracle 11iおよびOracle R12では、OE_ORDER_LINES_ALL.BOOKED_FLAG = Y条件により注文が予約されていることが示されるため、この文を使用して未予約注文がフィルター処理されています。未予約注文を含めてすべての注文をロードするには、SDE_ORA_SalesOrderLinesFactマッピングとSDE_ORA_SalesOrderLinesFact_PrimaryマッピングのWHERE句から、このフィルター条件を削除します。
デフォルトでは、予約注文のみが、Sales Order Linesテーブル（W_SALES_ORDER_LINES_F）とSales Booking Linesテーブル（W_SALES_BOOKING_LINE_F）にロードされます。ただし、Sales Order Linesテーブル（W_SALES_ORDERS_LINES_F）には、未予約注文もロードできます。
Sales Order Linesテーブルに未予約注文を含めるには:
PowerCenter Designerで、SDE_ORA115<ver>_adapterフォルダまたはSDE_ORAR12_adapterフォルダを開きます。
Mapplet Designerで、mplt_BC_ORA_SalesOrderFactマップレットを開きます。
SQ_BCI_SALES_ORDLNSソース修飾子をダブルクリックして、「Edit Transformations」ボックスを開きます。
「Properties」タブを表示します。
「Transformation Attribute」の「Sql Query」と「User Defined Join」の両方に対して、次の手順を実行します。
「Value」フィールドにある下向きの矢印を選択し、「SQL Editor」ボックスを表示します。
「SQL」ボックスで、AND OE_ORDER_LINES_ALL.BOOKED_FLAG='Y'の行を削除します。
「OK」をクリックして、変更を保存します。
変更を確認し、リポジトリに保存します。
SDE_ORA_SalesOrderLinesFact_Primaryマッピングに対して、手順3〜5を繰り返します。
販売スケジュール明細は、各注文項目の出荷予定に関する詳細です。各販売注文は販売注文明細に細分化され、その各販売注文明細が複数のスケジュール明細を持つことがあります。
たとえば、特定の販売注文明細に対応するだけの十分な在庫がない場合は、2つのスケジュールを作成して注文に対応します。1つのスケジュールには、現在の在庫数量を設定し、もう一方のスケジュールには、残りの数量を製造して出荷できるだけの期間を設定します。この情報はW_SALES_SCHEDULE_LINE_Fテーブルに格納されます。ここでは、このテーブルに格納される情報のタイプを変更する方法について説明します。
デフォルトでは、Sales Schedule Linesテーブルにロードされるすべての注文は予約されたものです。
未予約の注文をSales Schedule Linesテーブルにロードする場合は、未予約注文がフィルターで除外されないように抽出を構成する必要があります。Oracle 11iおよびOracle R12では、OE_ORDER_LINES_ALL.BOOKED_FLAG = Y条件により注文が予約されていることが示されるため、この文を使用して未予約注文がフィルター処理されています。未予約注文を含めてすべての注文をロードするには、SDE_ORA_SalesScheduleLinesFactマッピングとSDE_ORA_SalesScheduleLineLines_Fact_PrimaryマッピングのWHERE句から、このフィルター条件を削除します。
Sales Schedule Linesテーブルに未予約注文を含めるには:
PowerCenter Designerで、SDE_ORA115<ver>_adapterフォルダまたはSDE_ORAR12_adapterフォルダを開きます。
Mapplet Designerで、mplt_BC_ORA_SalesScheduleLinesFactマップレットを開きます。
SQ_BCI_SALES_ORDLNSソース修飾子をダブルクリックして、「Edit Transformations」ボックスを開きます。
「Properties」タブを表示します。
「Transformation Attribute」の「Sql Query」と「User Defined Join」の両方に対して、次の手順を実行します。
「Value」フィールドにある下向きの矢印を選択し、「SQL Editor」ボックスを表示します。
「SQL」ボックスで、AND OE_ORDER_LINES_ALL.BOOKED_FLAG='Y'の行を削除します。
「OK」をクリックして、変更を保存します。
変更を確認し、リポジトリに保存します。
SDE_ORA_SalesScheduleLinesFact_Primaryマッピングに対して、手順3〜5を繰り返します。
Oracle 11iおよびOracle R12の初期構成では、予約は販売注文明細レベルで記録されます。次の図に示すように、Bookingsテーブルには各予約注文に対して行が1行以上作成されます。
SDE_ORA115<ver>_adapterコンテナまたはSDE_ORAR12_adapterコンテナには、次の2つのサブジェクトエリアがあります。
企業販売 - 予約明細と注文明細
企業販売 - 予約明細とスケジュール明細
Oracle BI Applicationsによりインストールされる実行プランでは、デフォルトで使用されるサブジェクトエリアは、「企業販売 - 予約明細と注文明細」です。予約明細をスケジュール明細レベルでロードする場合は、新しい実行プランを作成し、「企業販売 - 予約明細と注文明細」のかわりに、「企業販売 - 予約明細とスケジュール明細」のサブジェクトエリアを含めます。
予約は、販売注文明細レベルではなく、販売スケジュール明細レベルでも記録できます。販売スケジュール明細レベルでは、注文がスケジュール明細により区分けされるため、より詳細な粒度で予約を表示できます。スケジュール明細レベルで予約を記録する場合は、次の図に示すように、Bookingsテーブルでは各スケジュール明細に対して行が1行作成されます。Oracle Applicationsのスケジュール明細の粒度は、注文明細と同じ粒度になります。そのため、予約明細をスケジュール明細から取得する場合、予約明細はスケジュール済の注文明細に制限されます。
期日前出荷と期日後出荷の定義を構成するには、mplt_SA_ORA_SalesPickLinesFactマップレットのEXP_SALES_PCKLNS式を編集します。mplt_SA_ORA_SalesPickLinesFactマップレットは、SDE_ORASalesPickLinesFactマッピングにより使用されます。
このマップレットは、実際の在庫出し日と出荷日を出荷予定日で比較し、注文が遅延していないかどうかを判定します。
期日前出荷と期日後出荷の許容日数を定義するには:
PowerCenter Designerで、SDE_ORA115<ver>_adapterフォルダまたはSDE_ORAR12_adapterフォルダを開きます。
Mapplet Designerで、mplt_SA_ORA_SalesPickLinesFactマップレットを開きます。
EXP_SALES_PCKLNS式をダブルクリックして、「Edit Transformations」ボックスを開きます。
「Ports」タブを表示します。
変更するポートの式を編集します。
次に例を示します。
実際の在庫出し日が出荷予定日よりも2日遅れた場合に期日後出荷フラグを設定する場合は、VAR_PICK_LATE_TIME_TOLポートの式値を2に設定します。
期日前出荷として扱うためのフラグの日数を設定するには、VAR_PICK_EARLY_TIME_TOLポートの式値を設定します。
期日後出荷として扱うためのフラグの日数を設定するには、VAR_PICK_LATE_TIME_TOLポートの式値を設定します。
出荷の許容日数を変更する場合は、出荷ポート（VAR_SHIP_LATE_TIME_TOLやVAR_SHIP_EARLY_TIME_TOLなど）の式値を設定します。
変更を確認し、リポジトリに保存します。
販売請求書明細は、顧客から注文を受けた項目に関する支払情報です。この情報はW_SALES_INVOICE_LINE_Fテーブルに格納されます。ここでは、このテーブルに格納される情報のタイプを変更する方法について説明します。
デフォルトでは、Oracle Order Management and Fulfillment Analyticsアプリケーションは、販売請求書データを抽出する際に、完了した販売請求書を抽出するように構成されています。Oracle 11iおよびOracle R12では、フラグを使用することで、販売請求書が完了しているかどうかが示されます。Oracle 11iおよびOracle R12では、完了した販売請求書は、RA_CUSTOMER_TRX_ALL.COMPLETE_FLAG = Yになります。
完了した販売請求書と同様に未完了の販売請求書を抽出するには、抽出のフィルター文を削除します。
販売請求書の抽出フィルターを削除するには:
PowerCenter Designerで、SDE_ORA115<ver>_adapterフォルダまたはSDE_ORAR12_adapterフォルダを開きます。
Mapplet Designerで、mplt_BC_ORA_SalesInvoiceLinesFactマップレットを開きます。
SQ_BCI_SALES_IVCLNSソース修飾子をダブルクリックして、「Edit Transformations」ボックスを開きます。
「Properties」タブを表示します。
「Transformation Attribute」の「Sql Query」で、「Value」フィールドにある下向きの矢印を選択し、「SQL Editor」ボックスを表示します。
「SQL」ボックスで、AND RA_CUSTOMER_TRX_ALL.COMPLETE_FLAG='Y'の行を削除します。
変更を確認し、リポジトリに保存します。
mplt_BC_ORA_SalesInvoiceLinesFact_Primaryマップレットに対して、手順2〜7を繰り返します。
バックログとサイクル明細（OTB ETL）のコンポーネントでは、バックログ、在庫出しおよびサイクル明細のテーブルが、Oracle EBSインタフェース・プログラムなどを使用して、出荷情報と請求情報で更新されていることが前提となります。Oracle Order Lineテーブルが出荷情報と請求情報で更新されていない場合は、次の手順に従って、OTB ETLと実行プランを更新する必要があります。
販売明細実行プランとOTB ETLを構成するには:
PowerCenter Designerで、PLPフォルダを開きます。
Mapplet Designerで、PLP_SalesCycleLinesFactマップレットを開きます。
SQ_W_SALES_ORDER_LINE_Fソース修飾子をダブルクリックして、「Edit Transformations」ボックスを開きます。
「Properties」タブを表示します。
「Transformation Attribute」の「Sql Query」で、「Value」フィールドにある下向きの矢印を選択し、「SQL Editor」ボックスを表示します。
「SQL」ボックスにおいて、SQL文の文字列であるX.TOTAL_SHIPPED_QTYをPICKLINE.TOTAL_SHIPPED_QTYで置換します。
「SQL」ボックスにおいて、SQL文の文字列であるX.TOTAL_INVOICED_QTYをIVCLINE.TOTAL_INVOICE_QTYで置換します。
変更を確認し、リポジトリに保存します。
DACにログインします。詳細は、第4.10.2項「DACへのログイン方法」を参照してください。
「Design」タブで、「Configuration Points」ノードを開き、「Sales PLP Optional Tasks」を選択します。
適切なサブジェクトエリアを有効にします。
SDE_ORA_SalesPickLinesFactで「Source Qualifier」を開きます。
SQLクエリーを次のように変更します。
次の結合基準を追加します。
AND WSH_DELIVERY_DETAILS.DELIVERY_DETAIL_ID=WSH_DELIVERY_ASSIGNMENTS.DELIVERY_DETAIL_ID (+) AND WSH_DELIVERY_ASSIGNMENTS.DELIVERY_ID=WSH_NEW_DELIVERIES.DELIVERY_ID (+)
かっこ内で次のフィルター条件をネストします。
OR WSH_NEW_DELIVERIES.LAST_UPDATE_DATE > TO_DATE('$$LAST_EXTRACT_DATE', 'MM/DD/YYYY HH24:MI:SS')
select OE_ORDER_LINES_ALL.ACTUAL_SHIPMENT_DATEをselect WSH_NEW_DELIVERIES.INTIAL_PICKUP_DATEに変更します。
WSH_NEW_DELIVERIES.LAST_UPDATE_DATEを選択し、EXP_SALES_PCKLNS.LAST_UPDATE_DATE1にリンクします。
Oracle Order Management and Fulfillment Analyticsアプリケーションが使用するテーブルは、Oracle Supply Chain Analyticsファミリーの製品（Oracle Inventory Analytics、Oracle Procurement and Spend Analytics、Oracle Supplier Performance Analytics）でも使用されます。
Oracle 11iおよびOracle R12では、次のSupply Chain Analytics用構成手順を使用して、Oracle Order Management and Fulfillment Analyticsを構成する必要があります。
Oracle Order Management and Fulfillment Analyticsアプリケーションが使用するテーブルは、Oracle Financial Analyticsアプリケーションでも使用されます。
Oracle 11iおよびOracle R12では、次のOracle Financial Analytics用構成手順を使用して、Oracle Order Management and Fulfillment Analyticsを構成する必要があります。
予約注文における変更は、Sales Order Linesテーブル（W_SALES_ORDER_LINE）ではなく、Booking Linesテーブル（W_SALES_BOOKING_LINE_F）で追跡されます。デフォルトでは、W_SALES_BOOKING_LINE_Fテーブルで追跡された変更のみ、注文金額、注文数量または予約IDにおいて変更されます。デフォルトでは、予約IDは次のように定義されます。
TO_CHAR(INP_LINE_ID)||'~'||TO_CHAR(INP_INV_ITEM_ID)||'~'||TO_CHAR(INP_WAREHOUSE_ID)
これらのフィールドにおける変更は、すべてW_SALES_BOOKING_LINE_Fテーブルの別の行に記録されます。ただし、これら以外のフィールドにおける変更は別の行に記録されずに、元の情報が変更後の情報で上書きされます。こうしたフィールドでは、値変更の履歴は保持されません。変更を追跡する必要がある場合は、追跡可能にすることができます。たとえば、注文を処理する担当営業者に対する変更を追跡する必要があるとします。デフォルトのETLプロセスでは担当営業者に関する変更は上書きされますが、保持する必要がある場合は、Source Adapterマップレット（mplt_SA_ORA_SalesOrderLinesFact）の予約ID式で、予約IDの定義に属性を追加する必要があります。次の項では、予約IDに担当営業者を追加するように変更した場合の影響について説明します。
たとえば、予約と予約解除に関する変更を担当営業者別に追跡するとします。この追跡の目的は、各担当営業者の販売実績をより詳細に評価することにあります。担当営業者ID別に変更を追跡するには、次の値が使用されるようにVAR_BOOKING_IDを変更する必要があります。
TO_CHAR(INP_LINE_ID)||'~'||TO_CHAR(INP_INV_ITEM_ID)||'~'||to_char(INP_WAREHOUSE_ID)
たとえば、VAR_BOOKING_ID値を編集するには、次の手順を実行します。
Informatica DesignerのMapplet Designerで、mplt_SA_ORA_SalesOrderLinesFactマップレットを開きます。
MAPI_SALES_ORDLNS変換をダブルクリックして、「Edit Transformations」ボックスを開きます。
「Ports」タブを表示します。
「EXP_SALES_ORDLNS」変換を選択します。
VAR_BOOKING_IDポートの式を編集します。
このシナリオにおいてに担当営業者が変更された場合にソース・システムとW_SALES_BOOKING_LINE_Fテーブルがどのような影響を受けるかについて、この後の説明と表で示します。
1日目: 担当営業者1001が注文を受けました。ソース・システムには、表11-9に示すような内容の情報が表示されます。
表11-9 Oracle 11iおよびOracle R12: 1日目の営業終了時点におけるソース・システムのテーブル行
| 販売注文番号 | 販売注文明細番号 | 担当営業者ID | 数量 | 販売価格 | 日付 |
|---|---|---|---|---|---|
|
1 |
1 |
1001 |
100 |
25 |
1-June-2000 |
表11-9の行は、IA Bookingsテーブル（W_SALES_BOOKING_LINE_F）に表11-10のような形式で入力されます。
表11-10 Oracle 11iおよびOracle R12: 1日目の営業終了時点におけるW_SALES_BOOKING_LINE_Fテーブル行
| SALES_ORDER_NUM | SALES_ORDER_ITEM | SALESREP_ID | SALES_QTY | NET_DOC_AMT | BOOKED_ON_DT |
|---|---|---|---|---|---|
|
1 |
1 |
1001 |
100 |
2500 |
1-June-2000 |
2日目: 担当営業者1002が担当営業者1001からこの注文を引き継ぎました。その結果、ソース・システムで、この注文に関連付けられていた担当営業者が1001から1002に変更されます。変更後のソース・システムの行は、表11-11に示すような内容になります。
表11-11 Oracle 11iおよびOracle R12: 2日目の営業終了時点におけるソース・システムのテーブル行
| 販売注文番号 | 販売注文明細番号 | 担当営業者ID | 数量 | 販売価格 | 日付 |
|---|---|---|---|---|---|
|
1 |
1 |
1002 |
100 |
25 |
2-June-2000 |
この時点で、予約テーブルへの書込みも処理するSIL_SalesBookingLinesFact_Load_OrderLine_Creditによって元の行が予約解除され、SIL_SalesBookingLinesFact_Load_OrderLine_DebtによってW_SALES_BOOKING_LINE_F予約テーブルに新しい行が挿入されます。2日目の時点で、W_SALES_BOOKING_LINE_Fテーブルの行は表11-12のようになります。
バックログ情報は、W_SALES_BACKLOG_LINE_FテーブルとW_SALES_BACKLOG_HISTORY_Fテーブルに格納されます。この項では、これらのテーブルに格納される情報のタイプを変更する方法について説明します。Oracle Order Management and Fulfillment Analyticsアプリケーションには、財務バックログ、出荷待ちバックログ、延滞バックログ、予定済バックログ、未予定バックログ、保留バックログなど、様々なタイプのバックログが用意されています。バックログの各タイプは、セールスプロセスにおける特定の2つの日付により定義されるため、バックログの計算には複数の要素テーブルが検索されます。
たとえば、財務バックログには、注文を受けたが支払いを受領していない項目が記録されます。したがって、財務バックログの項目数の計算には、Sales Order Linesテーブル（注文を受けた項目の特定）とSales Invoice Linesテーブル（支払いを受領した注文の特定）が使用されます。これらの2つのテーブルを使用することで、財務バックログに記録する項目の数と値を特定できます。
デフォルトでは、Oracle Order Management and Fulfillment Analyticsアプリケーションは、Sales Order Linesテーブル（W_SALES_ORDER_LINE_F）とSales Schedule Linesテーブル（W_SALES_SCHEDULE_LINE_F）からオープンされている販売注文のみを抽出し、バックログ計算を行いBacklogテーブルにポピュレートします。オープンな販売注文とは、取り消されていないか完了していない注文として定義されます。オープンな注文のみが抽出される理由は、ほとんどの組織で、クローズされた注文はバックログの一部でなくなるからです。ただし、クローズとしてマークされている販売注文を抽出する必要がある場合は、抽出マッピングからデフォルトのフィルター条件を削除できます。
たとえば、顧客が10項目を注文したとします。6項目の請求と出荷が行われましたが、残りの4項目が出荷待ちバックログと財務バックログに記録されています。このバックログ状況は、次のどちらかになるまで続きます。
残りの項目の出荷と請求が行われた場合
注文の残りの項目が取り消された場合
クローズとしてフラグ設定されている販売注文を抽出する場合は、バックログ・フラグの条件を削除する必要があります。それには、次の手順を実行します。
W_SALES_ORDER_LINE_FテーブルのBACKLOG_FLAGは、バックログ計算の対象となる販売注文を識別する目的でも使用されます。デフォルトでは、すべての販売注文タイプにはバックログ・フラグがYに設定されています。したがって、すべての販売注文がバックログ計算の対象となります。
オープンなオーダーを抽出するフィルターを削除するには:
PowerCenter Designerで、SDE_ORA115<ver>_adapterフォルダまたはSDE_ORAR12_adapterフォルダを開きます。
Mapplet Designerで、mplt_BC_ORA_SalesOrderLinesFactマップレットを開きます。
EXP_SALES_ORDLNSをダブルクリックし、「Ports」タブを表示します。
VAR_OPR_BACKLOG_FLGを編集し、OPEN_FLAG='Y'を削除します。
VAR_FIN_BACKLOG_FLGを編集し、OPEN_FLAG='Y'を削除します。
Mapplet Designerで、mplt_BC_ORA_SalesScheduleLinesFactマップレットを開きます。
EXP_SALES_SCHLNSをダブルクリックし、「Ports」タブを表示します。
VAR_OPR_BACKLOG_FLGを編集し、OPEN_FLAG='Y'を削除します。
VAR_FIN_BACKLOG_FLGを編集し、OPEN_FLAG='Y'を削除します。
変更を確認し、リポジトリに保存します。
PLPフォルダを開きます。
PLP_SalesBacklogLinesFact_LoadOrderLinesマッピングとPLP_SalesBacklogLinesFact_LoadScheduleLinesマッピングを開きます。
「Source Qualifier」の「SQL Query」から、W_STATUS_CODE <> 'Closed'条件を削除します。
この項では、PeopleSoftに適用される構成手順について説明します。
リリース7.9.4のOracle BI Applicationsには該当しません。
この項では、汎用的に適用される構成手順について説明します。
リリース7.9.4のOracle BI Applicationsには該当しません。
