| Oracle® Business Intelligence Applications Informatica PowerCenterユーザーのための構成ガイド リリース7.9.6.3 B66691-01 |
|
 前 |
 次 |
| Oracle® Business Intelligence Applications Informatica PowerCenterユーザーのための構成ガイド リリース7.9.6.3 B66691-01 |
|
前 |
次 |
この項では、Oracle Supply Chain and Order Management Analyticsの構成方法について説明します。内容は次のとおりです。
第6.1項「Oracle Supply Chain and Order Management Analyticsの概要」
第6.2項「完全ロード前にOracle Supply Chain and Order Management Analyticsに必要な構成」
Oracle Supply Chain and Order Management Analyticsアプリケーションにより、次のものが分析できます。
部品表。
予約。
財務バックログおよび出荷待ちバックログ。
組織により保留されたインベントリ。
メーカー工場、流通センターまたは各地の倉庫での入出荷、経路といったインベントリの動き。
請求書。
販売サイクルの様々なステージにおける販売オーダーの動き。
Oracle Supply Chain and Order Management Analyticsアプリケーションは、オーダー、請求、バックログおよびインベントリから構成されます。販売注文は、セールスプロセスへのエントリポイントです。請求は、履行プロセスからの終了ポイントです。バックログは、履行プロセスにおいて輻輳が発生しているポイントです。このカバレッジには、アイテムの予約、バックログおよび請求に関する情報が含まれています。これにより、個々の営業担当者や部署の販売実績を評価できます。Oracle Supply Chain and Order Management Analyticsアプリケーションは、インベントリ・トランザクション、インベントリ・バランス、部品表および顧客およびサプライヤによる返品に関する情報も提供します。これにより、企業は販売実績に対するインベントリ・レベルの傾向をモニターして、コストの明確化、インベントリ・レベルの抑制、回転率向上による売上増加、インベントリの適地、適時の適切なデプロイ、顧客およびサプライヤによる返品への理解を深め、品質の維持へとつなげることができます。
Oracle Supply Chain and Order Management Analyticsアプリケーションでは、集計テーブルおよび派生テーブルにデータをポピュレートするために、ロード後の処理のマッピングを構成する必要もあります。
この項では、データの完全ロードを実行する前にOracle Supply Chain and Order Management Analyticsで実行が必要な構成手順について説明します。内容は次のとおりです。
第6.2.1項「すべてのソース・システム用にOracle Supply Chain and Order Management Analyticsを構成するための手順」
第6.2.2項「Oracle EBS用にOracle Supply Chain and Order Management Analyticsを構成するための手順」
この項では、すべてのソース・システムに適用される構成手順について説明します。内容は次のとおりです。
|
注意: すべての分析モジュール(Oracle Financial Analytics、Oracle HR AnalyticsまたはOracle Sales Analyticsなど)に適用される構成手順は、第3章「共通のエリアと次元の構成」を参照してください。 |
Oracle Projectsのライセンスがない場合や、実装を必要としない場合は、プロジェクト次元を無効化できます。
プロジェクト次元を無効化するには:
DACで、「Design」ビューに移動して、適切なカスタム・コンテナをドロップダウン・リストから選択します。
「Configuration Tags」タブを表示します。
「Enable Project Dimensions」タグに対して問合せを実行します。
「Subject Area」サブタブを表示します。
「Supply Chain - Inventory Transactions」という名前のサブジェクト・エリアの、「Inactive」チェック・ボックスを選択します。
上部ペインに「Subject Area」タブが表示されます。「Projects」という名前のサブジェクト・エリアを選択します。
下部ペインに、「Configuration Tags」タブが表示されます。
「Enable Project Dimensions」という名前の「Configuration Tag」構成タグの、「Inactive」チェック・ボックスを選択します。
Oracle Supply Chain and Order Management Analyticsの削除セッションおよびプライマリ抽出セッションを有効化する必要があります。詳細は、第17.8.3.2項「削除セッションおよびプライマリ抽出セッションの有効化」を参照してください。プライマリ抽出とマッピングの削除の一般情報は、第17.8項「ロードの構成」を参照してください。
この項では、データの完全ロードを実行する前に、Oracle EBSに適用される構成手順について説明します。
表6-1に、$PMServer\LkpFilesフォルダ(INFA_HOME\server\infa_shared\LkpFilesなど)にあるOracle Supply Chain and Order Management Analytics用のCSVワークシート・ファイルとドメイン値を示します。
表6-1 Oracle Supply Chain and Order Management Analytics用のドメイン値とCSVワークシート・ファイル
| ワークシート・ファイル名 | 説明 | セッション |
|---|---|---|
|
domainValues_InvoiceTypes_ora11i.csv |
請求ドキュメント・タイプのカラムと、Oracle 11iまたはOracle R12のアプリケーションに対応するドメイン値の一覧です。 このファイルの値を更新する方法の詳細は、第6.2.2.2項「請求タイプのドメイン値の構成方法」を参照してください。 |
SDE_ORA_Transaction TypeDimension_SalesInvoiceLines |
|
domainValues_PickTypes_ora11i.csv |
在庫出しドキュメント・タイプのカラムと、Oracle 11iまたはOracle R12のアプリケーションに対応するドメイン値の一覧です。 このファイルの値を更新する方法の詳細は、第6.2.2.3項「在庫出しタイプのドメイン値の構成方法」を参照してください。 |
SDE_ORA_Transaction TypeDimension_SalesPickLines |
|
domainValues_OrderTypes_ora11i.csv |
オーダー・ドキュメント・タイプのカラムと、Oracle 11iまたはOracle R12のアプリケーションに対応するドメイン値の一覧です。 このファイルの値を更新する方法の詳細は、第6.2.2.4項「オーダー・タイプのドメイン値の構成方法」を参照してください。 |
SDE_ORA_Transaction TypeDimension_SalesOrderLines |
|
domainValues_PickStatus_ora11i.csv |
在庫出し状況コードおよび状況説明のカラムと、Oracle 11iまたはOracle R12のアプリケーションに対応するドメイン値の一覧です。 このファイルの値を更新する方法の詳細は、第6.2.2.5項「在庫出し状況のドメイン値の構成方法」を参照してください。 |
SDE_ORA_StatusDimension_SalesPickLines |
|
domainValues_PayMethodCode_ora.csv |
方法コードのカラムと、アプリケーションに対応するドメイン値の一覧です。 このファイルの値を更新する方法の詳細は、第6.2.2.6項「支払い方法のドメイン値の構成方法」を参照してください。 |
SDE_ORA_Payment MethodDimension |
|
domainValues_InvoiceStatus_ora11i.csv |
請求状況コードおよび状況説明のカラムと、Oracle 11iまたはOracle R12のアプリケーションに対応するドメイン値の一覧です。 このファイルの値を更新する方法の詳細は、第6.2.2.7項「請求状況のドメイン値の構成方法」を参照してください。 |
SDE_ORA_StatusDimension_SalesInvoiceLine |
|
domainValues_OrderOverallStatus_ora11i.csv |
注文状況コードのカラムと、Oracle 11iまたはOracle R12のアプリケーションに対応するドメイン値の一覧です。 このファイルの値を更新する方法の詳細は、第6.2.2.8項「オーダー全般状況のドメイン値の構成方法」を参照してください。 |
SDE_ORA_StatusDimension_SalesOrderLineCycle |
|
domainValues_InvoiceSrcTypes_ora11i.csv |
請求ソース・コード列およびソース説明の列と、Oracle 11iまたはOracle R12のアプリケーションに対応するドメイン値の一覧です。 このファイルの値を更新する方法の詳細は、第6.2.2.10項「請求ソース・タイプのドメイン値の構成方法」を参照してください。 |
SDE_ORA_Transaction SourceDimension |
CSVワークシート・ファイルのドメイン値の詳細は、Oracle Business Intelligence Applications Informatica PowerCenterユーザーのためのインストレーション・ガイドのOracle Business Analytics Warehouseのカスタマイズに関する項を参照してください。
注意: 後続の各項でSQLコードが提供されている箇所では、FND_LOOKUP_VALUES.LANGUAGE = ' 'コマンドで指定された言語の変更が必要になる場合があります。
この項では、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ディレクトリ(INFA_HOME\server\infa_shared\LkpFilesなど)にあるdomainValues_InvoiceTypes_ora11i.csvファイルを開きます。
TYPEカラムをこのファイルのXACT_TYPE_CODEカラムにコピーします。
2行目以降のデータをコピーしてください。最初の行はカラム・ヘッダーです。
各トランザクションタイプ・コードを1つのドメイン値にマッピングします。
トランザクション・タイプ・コードのドメイン値の詳細は、Oracle Business Analytics Warehouseデータ・モデル・リファレンスを参照してください。
ファイルを保存して閉じます。
この項では、domainValues_PickTypes_ora11i.csvファイルを使用して、在庫出しタイプのドメイン値を構成する方法について説明します。
在庫出しタイプのドメイン値を構成するには:
テキスト・エディタを使用して、$PMServer\LkpFilesディレクトリ(INFA_HOME\server\infa_shared\LkpFilesなど)にあるdomainValues_PickTypes_ora11i.csvファイルを開きます。
ファイルのXACT_TYPE_CODEカラムにSTANDARDを挿入します。
2行目以降のデータをコピーしてください。最初の行はカラム・ヘッダーです。
各トランザクションタイプ・コードを1つのドメイン値にマッピングします。
トランザクション・タイプ・コードのドメイン値の詳細は、Oracle Business Analytics Warehouseデータ・モデル・リファレンスを参照してください。
ファイルを保存して閉じます。
この項では、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ディレクトリ(INFA_HOMEなど)にあるdomainValues_OrderTypes_ora11i.csvファイルを開きます。
このファイルのXACT_TYPE_CODEカラムにLOOKUP_TYPEカラムをコピーします。
2行目以降のデータをコピーしてください。最初の行はカラム・ヘッダーです。
各トランザクションタイプ・コードを1つのドメイン値にマッピングします。
トランザクション・タイプ・コードのドメイン値の詳細は、Oracle Business Analytics Warehouseデータ・モデル・リファレンスを参照してください。
ファイルを保存して閉じます。
この項では、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ディレクトリ(INFA_HOME\server\infa_shared\LkpFilesなど)にあるdomainValues_PickStatus_ora11i.csvファイルを開きます。
このファイルのSTATUS_CODEカラムにLOOKUP_CODEカラムをコピーします。
2行目以降のデータをコピーしてください。最初の行はカラム・ヘッダーです。
各状況コードを1つのドメイン値にマッピングします。
状況コードのドメイン値の詳細は、Oracle Business Analytics Warehouseデータ・モデル・リファレンスを参照してください。
ファイルを保存して閉じます。
この項では、domainValues_PayMethodCode_ora.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ディレクトリ(INFA_HOME\server\infa_shared\LkpFilesなど)にあるdomainValues_PayMethodCode_ora.csvファイルを開きます。
このファイルのMETHOD_CODEカラムにLOOKUP_CODEカラムをコピーします。
2行目以降のデータをコピーしてください。最初の行はカラム・ヘッダーです。
各方法コードを1つのドメイン値にマッピングします。
方法コードのドメイン値の詳細は、Oracle Business Analytics Warehouseデータ・モデル・リファレンスを参照してください。
ファイルを保存して閉じます。
この項では、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ディレクトリ(INFA_HOME\server\infa_shared\LkpFilesなど)にあるdomainValues_InvoiceStatus_ora11i.csvファイルを開きます。
このファイルのSTATUS_CODEカラムにLOOKUP_CODEカラムをコピーします。
2行目以降のデータをコピーしてください。最初の行はカラム・ヘッダーです。
各状況コードを1つのドメイン値にマッピングします。
状況コードのドメイン値の詳細は、Oracle Business Analytics Warehouseデータ・モデル・リファレンスを参照してください。
ファイルを保存して閉じます。
この項では、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ディレクトリ(INFA_HOME\server\infa_shared\LkpFilesなど)にあるdomainValues_OrderOverallStatus_ora11i.csvファイルを開きます。
このファイルのSTATUS_CODEカラムにLOOKUP_CODEカラムをコピーします。
2行目以降のデータをコピーしてください。最初の行はカラム・ヘッダーです。
各状況コードを1つのドメイン値にマッピングします。
状況コードのドメイン値の詳細は、Oracle Business Analytics Warehouseデータ・モデル・リファレンスを参照してください。
ファイルを保存して閉じます。
この項では、移動タイプのドメイン値の構成方法について説明します。
次のSQLを使用して、Oracle EBSソース・システムの在庫輸送タイプを特定します。
SELECT DISTINCT MTL_TRANSACTION_TYPES.TRANSACTION_TYPE_NAME FROM MTL_TRANSACTION_TYPES
テキスト・エディタを使用して、$PMServer\LkpFilesディレクトリ(INFA_HOME\server\infa_shared\LkpFilesなど)にあるdomainValues_Movement_Types_ora11i.csvファイルを開きます。
TRANSACTION_TYPE_NAMEをこのファイルのTRANSACTION_TYPE_NAMEカラムにコピーします。
2行目以降のデータをコピーしてください。
各TRANSACTION_TYPE_NAMEを1つの在庫輸送タイプのドメイン値にマップします。
カンマを使用してエントリを区切ります。
ファイルを保存して閉じます。
この項では、domainValues_InvoiceSrcTypes_ora11i.csvファイルを使用して、ソース・タイプのドメイン値を構成する方法について説明します。
ソース・タイプのドメイン値を構成するには:
次のSQLを使用して、Oracle 11iソース・システムのソース・タイプを特定します。
SELECT DISTINCT DESCRIPTIVE_FLEX_CONTEXT_CODE FROM FND_DESCR_FLEX_CONTEXTS WHERE DESCRIPTIVE_FLEXFIELD_NAME = 'RA_INTERFACE_LINES' AND APPLICATION_ID=222 ORDER BY 1;
テキスト・エディタを使用して、$PMServer\LkpFilesディレクトリ(INFA_HOME\server\infa_shared\LkpFilesなど)にあるdomainValues_InvoiceSrcType_ora11i.csvファイルを開きます。
このファイルのXACT_TYPE_CODE列に、TYPE列をコピーします。
2行目以降のデータをコピーしてください。最初の行はカラム・ヘッダーです。
各トランザクションのソース・タイプ・コードを1つのドメイン値にマッピングします。
トランザクション・タイプ・コードのドメイン値の詳細は、Oracle Business Analytics Warehouseデータ・モデル・リファレンスを参照してください。
ファイルを保存して閉じます。
Oracle 11iでは、数量を次の3タイプに分類しています。
受領商品数。受領商品数は、受領した商品の数です。
配送数。配送数は、配送した商品の数です。
ベース数。ベース数は、トランザクションの量です。
Oracle Business Analytics Warehouseはトランザクションタイプを抽出して、その値をXACT_SRC_TYPEカラムにロードします。このカラムの値が1の場合は受領商品数を、2の場合は配送数を表します。
XACT_SRC_TYPE列の詳細を表示するには、EBSインスタンスに対して次のSQLを実行します。
SELECT TRANSACTION_SOURCE_TYPE_ID, TRANSACTION_SOURCE_TYPE_NAME, DESCRIPTION FROM MTL_TXN_SOURCE_TYPES ORDER BY 1
購入オーダー(1)に相当する行がある場合は、TRANSACTION_SOURCE_TYP E_IDを受領商品数のカラム(EXT_GR_QTY)に追加する必要があります。販売注文(2)に相当する行がある場合は、TRANSACTION_SOURCE_TYPE_IDを配送数のカラム(EXT_DELIVERY_QTY)に追加する必要があります。
ソース・システムから抽出される数量はすべて、常にベース数の列(EXT_BASE_QTY)にロードされます。ただし、受領数のみの場合は受領商品数の列(EXT_GR_QTY)に、配送数のみの場合は配送数の列(EXT_DELIVERY_QTY)にロードされます。
組織の受領済商品数または配送数の定義が、事前構成されている条件と異なる場合は、組織のビジネス要件に合せて条件を編集できます。
数量タイプを構成するには:
Informatica PowerCenter Designerで、SDE_ORAVersion_Adaptorを開きます。
mplt_SA_ORA_ProductTransactionFactマップレットを開きます。
「EXP_PROD_XACTS Expression transformation」をダブルクリックして「Edit Transformations」ダイアログ・ボックスを開き、「Port」タブをクリックしてEXT_GR_QTYポートとEXT_DELIVERY_QTYポートを表示します。
事前構成されている式に独自の条件を代入して、数量タイプを編集します。
「Apply」をクリックします。
マップレットを確認し、変更内容をリポジトリに保存します。
「部品表」(BOM)機能エリアでは、完成品を構成するコンポーネントの利益幅を調べることができます。BOMを使用すると、コストと収益の面で最も有望なベンダーを追跡したり、販売組織に製品の配送状況や品切れなどを認識させることができます。
Oracle EBSでオブジェクトをデプロイしてBOMを展開するには、次に示すように、Oracle EBSソース環境が使用するバージョンの最小パッチ・レベルと一致している必要があります。
Oracle EBSバージョンR12を使用している場合は、パッチ・レベル10422612以上であること。
Oracle EBSバージョンR12.0.xまたはOPIパッチ・セットAを使用している場合は、パッチ・レベル10422612:R12.OPI.A以上であること。
Oracle EBSバージョンR12.1.xまたはOPIパッチ・セットBを使用している場合は、パッチ・レベル10422612:R12.OPI.B以上であること。
Oracle EBSバージョン11iを使用している場合は、バッチ・レベル10361119以上であること。
ソース・システムでサポートされるパッチ・レベルの詳細は、『Oracle Business Intelligence Applicationsシステム要件およびサポートされるプラットフォーム』を参照してください。
詳細は、第6.3.2.14項「部品表展開オプションの構成方法」を参照してください。
|
注意: これらの最小パッチ・レベル以上のシステムには、パッケージOPI_OBIA_BOMPEXPL_WRAPPER_PKGがAPPSスキーマに含まれます。また、次の表がOPIスキーマに含まれ、APPSスキーマにはその別名表があります。OPI_OBIA_W_BOM_HEADER_DS OPI_OBIA_BOM_EXPLOSION OPI_OBIA_BOM_EXPLOSION_S |
この項では、OracleのJD Edwards EnterpriseOneに適用するデータの完全ロードを実行する前に必要な構成手順について説明します。内容は次のとおりです。
表6-2に、$PMServer\LkpFilesディレクトリ(INFA_HOME\server\infa_shared\LkpFilesなど)にあるOracle Supply Chain and Order Management Analytics用のCSVワークシート・ファイルとドメイン値を示します。
表6-2 JD Edwards EnterpriseOne用のOracle Supply Chain and Order Management Analyticsのドメイン値とCSVワークシート・ファイル
| ワークシート・ファイル | 説明 | セッション |
|---|---|---|
|
file_udc_category_mapping_jde.csv |
このファイルは、W_CODE_D表に移入されるJD Edwards EnterpriseOneのユーザー定義コードを指定するために使用します。 |
SDE_JDE_Code_Category_Map_Load |
|
domainvalues_Movement_Types_jde.csv |
このファイルは、特定の移動タイプの説明に関するオーバーライド情報を指定するために使用します。 |
SDE_JDE_MvmntTypeDimension |
|
domainvalues_xact_type_codes_scom_jde_sales_ivclns.csv |
このファイルは、販売請求書明細に適用可能な販売注文トランザクション・タイプ・コードを指定するために使用します。 |
SDE_JDE_XactTypeDimension_SalesInvoiceLine |
|
domainvalues_xact_type_codes_scom_jde_sales_ordlns.csv |
このファイルは、販売注文明細に適用可能な販売注文トランザクション・タイプ・コードを指定するために使用します。 |
SDE_JDE_XactTypeDimension_SalesOrderLine |
|
file_sales_order_status_jde.csv |
このファイルは、W_CODE_D(カテゴリ別)およびW_STATUS_Dの各表に移入する販売注文ステータスの情報を指定するために使用します。 |
SDE_JDE_StatusDimension_SalesOrder |
|
file_lkp_chnl_typ_jde.csv |
このファイルは、チャネル・タイプ次元表に移入する追加情報をチャネル・タイプ・コード別に指定するために使用します。 |
SDE_JDE_ChannelTypeDimension |
|
file_lkp_consign_inv_org_jde.csv |
このファイルは、在庫プロセス内で委託に使用される支店/工場(組織ID)を指定するために使用します。 |
SDE_JDE_Inventory_Daily_Bal_Fact |
|
file_lkp_return_loc_jde.csv |
このファイルは、在庫プロセスで支店/工場、場所、およびロット番号別に返品場所を指定するために使用します。 |
SDE_JDE_Inventory_Daily_Bal_Fact |
この項では、file_udc_category_mapping_jde.csvファイルの構成方法について説明します。
このフラット・ファイルには、SDE_JDE_Category_Map_Loadワークフローを実行する前にデータを移入します。このワークフローは、CSVファイルを入力として使用し、同じ名前をマッピングしてW_JDE_UDC_CATEGORY_MAP_TMPという一時表を作成します。この一時表は、W_CODE_D表をロードする際にSDE_JDE_CODE_DIMENSIONワークフローへのソース入力として使用されます。
file_udc_category_mapping_jde.csvを構成するには:
テキスト・エディタを使用して、$PMServer\SrcFilesフォルダにあるfile_udc_category_mapping_jde.csvファイルを開きます。
このファイルの値を、第3.5.1.2項「OracleのJD Edwards EnterpriseOneまたはJD Edwards World UDCコード次元の構成について」に記載されている表3-22の値と比較します。
表3-22のエントリからシステム・コード、ユーザー定義コード、およびカテゴリの単位でCSVファイルに任意の新しい値を追加します。このカテゴリが、JD Edwards EnterpriseOne用のOracle Supply Chain and Order Management Analyticsのマッピングで定義されているものと一致するように、各カテゴリの値は必ず正しく記述してください。
このCSVファイルに追加した値は、UDCエントリとしてカテゴリごとにW_CODE_D表に追加されます。
W_CODE_D表および各値の詳細は、Oracle Business Analytics Warehouseデータ・モデル・リファレンスを参照してください。
カンマを使用してエントリをシステム・コード、UDC列、およびカテゴリで区切ります。スペースは入れないようにしてください。
ファイルを保存して閉じます。
この項では、domainvalues_Movement_Types_jde.csvの構成方法について説明します。このフラット・ファイルには、SDE_JDE_MvmntTypeDimensionワークフローを実行する前にデータを移入します。
domainvalues_Movement_Types_jde.csvを構成するには:
次のSQLを使用して、JD Edwards EnterpriseOneソース・システムの移動タイプを特定します。
SELECT RTRIM(DRSY) || '~' || DRRT || '~' || LTRIM(DRKY) FROM F0005 AS MVMNT_TYPE_CODE WHERE DRSY = '00' AND DRRT = 'DT' AND DRKY <> ' '
テキスト・エディタを使用して、$PMServer\LkpFilesディレクトリ(INFA_HOME\server\infa_shared\LkpFilesなど)にあるdomainvalues_Movement_Types_jde.csvファイルを開きます。
SQLのMVMNT_TYPE_CODE列の値をファイルのMVMNT_TYPE_CODE列にコピーします。
2行目以降のデータをコピーしてください。最初の行はカラム・ヘッダーです。
ファイルの各MVMNT_TYPE_CODEに対して、W_MVMNT_TYPE_CODEおよびW_MVMNT_TYPE_DESCの適切なドメイン値を追加します。有効なドメイン値は、OTHERS、CUSTOMER RETURN、またはVENDOR RETURNです。
W_MVMNT_TYPE_CODEおよびW_MVMNT_TYPE_DESCの値は、すべてOTHERSになりますが、顧客返品またはベンダー返品で実際に使用されるドキュメント・タイプ(移動タイプ)は例外です。これらの特定のドキュメント・タイプは、それぞれのドメイン値で識別されるので、その値を適切に使用してください。
移動タイプのドメイン値の詳細は、Oracle Business Analytics Warehouseデータ・モデル・リファレンスを参照してください。
ファイルを保存して閉じます。
この項では、domainvalues_xact_type_codes_scom_jde_sales_ivclns.csvの構成方法について説明します。このフラット・ファイルには、SDE_JDE_XactTypeDimension_SalesInvoiceLineワークフローを実行する前にデータを移入します。
domainvalues_xact_type_codes_scom_jde_sales_ivclns.csvを構成するには:
テキスト・エディタを使用して、$PMServer\LkpFilesフォルダにあるdomainvalues_xact_type_codes_scom_jde_sales_ivclns.csvファイルを開きます。
次のSQLを使用して、JD Edwards EnterpriseOneで使用する請求明細のトランザクション・タイプを特定します。
SELECT F0005.DRKY FROM F0005 WHERE DRSY = '00' AND DRRT = 'DT'
XACT_TYPE_CODEソース列に対応するように、戻り値をフラット・ファイルにマップします。Oracle Business Analytics Warehouseデータ・モデル・リファレンスに記載されているとおりに、このファイルの値を請求明細のトランザクション・タイプのドメイン値に関連付けます。
次に構成の例を示します。
XACT_TYPE_CODE,XACT_CODE,W_XACT_TYPE_CODE,W_XACT_TYPE_DESC,W_XACT_TYPE_CODE1,W_XACT_TYPE_DESC1 <DRKY>,SALES_IVCLNS,Standard Invoice,Standard Invoice,Order Management,Order Management source code
|
注意: この例に示されている値は、ソース・コードのドメイン値のデフォルト値でもあります。フラット・ファイルにドキュメント・タイプ<DRKY>が構成されていない場合は、この例で示されている値が、それらのドキュメントのデフォルト値とみなされます。 |
W_XACT_TYPE_Dで使用するトランザクション・タイプのドメイン値の詳細は、Oracle Business Analytics Warehouseデータ・モデル・リファレンスを参照してください。
カンマを使用してエントリをシステム・コード、UDC列、およびカテゴリで区切ります。スペースは入れないようにしてください。
ファイルを保存して閉じます。
この項では、domainvalues_xact_type_codes_scom_jde_sales_ordlns.csvの構成方法について説明します。このフラット・ファイルには、SDE_JDE_XactTypeDimension_SalesOrderLineワークフローを実行する前にデータを移入します。
domainvalues_xact_type_codes_scom_jde_sales_ordlns.csvを構成するには:
テキスト・エディタを使用して、$PMServer\LkpFilesフォルダにあるdomainvalues_xact_type_codes_scom_jde_sales_ordlns.csvファイルを開きます。
次のSQLを使用して、JD Edwards EnterpriseOneで使用する注文明細トランザクション・タイプを特定します。
SELECT F0005.DRKY FROM F0005 WHERE DRSY = '00' AND DRRT = 'DT'
XACT_TYPE_CODEソース列に対応するように、戻り値をフラット・ファイルにマップします。Oracle Business Analytics Warehouseデータ・モデル・リファレンスに記載されているとおりに、この列の値を注文明細トランザクション・タイプのドメイン値に関連付けます。
次に構成の例を示します。
XACT_TYPE_CODE,XACT_CODE,W_XACT_TYPE_CODE,W_XACT_TYPE_DESC,W_XACT_TYPE_CODE1,W_XACT_TYPE_DESC1, W_XACT_TYPE_CODE2,W_XACT_TYPE_DESC2 <DRKY>,SALES_ORDLNS,Regular,Regular,EXTERNAL,External order,Self Ship,Internal inventory order
|
注意: この例に示されている値は、ソース・コードのドメイン値のデフォルト値でもあります。フラット・ファイルにドキュメント・タイプ<DRKY>が構成されていない場合は、この例で示されている値が、それらのドキュメントのデフォルト値とみなされます。 |
W_XACT_TYPE_Dのドメイン値の詳細は、Oracle Business Analytics Warehouseデータ・モデル・リファレンスを参照してください。
カンマを使用してエントリをシステム・コード、UDC列、およびカテゴリで区切ります。スペースは入れないようにしてください。
ファイルを保存して閉じます。
この項では、file_sales_order_status_jde.csvの構成方法について説明します。このフラット・ファイルには、SDE_JDE_StatusDimension_SalesOrderワークフローを実行する前にデータを移入します。このフラット・ファイルは、W_STATUS_DSテーブルのソースです。また、$PMServer\SrcFilesフォルダにあるものを使用します。
file_sales_order_status_jde.csvを構成するには:
テキスト・エディタを使用して、$PMServer\SrcFilesフォルダにあるfile_sales_order_status_jde.csvファイルを開きます。
オーダー・アクティビティ・ルールの設定を分析して、販売注文ステータスの組合せを特定します。データの組合せは次のようになります。
| DocType | LineType | 前のステータス | 説明 | 次のステータス | 説明 |
|---|---|---|---|---|---|
| SO | S | 520 | 販売オーダー入力 | 540 | ピックスリップ印刷 |
| SO | S | 520 | 販売オーダー入力 | 560 | 出荷確認 |
| SO | S | 520 | 販売オーダー入力 | 535 | ウェアハウス管理 |
| SO | S | 900 | 入荷待ちのSOエントリ | 540 | ピックスリップ印刷 |
すべての販売注文に対して、F4211表からDocType、LineType、前のステータス、および次のステータスがそれぞれ異なる組合せを特定します。
これらの組合せごとに次のような接頭辞を付けます。
SALES_ORDLNS~<DocType>~<LineType>~<LastStatus>~NextStatus> SALES_PCKLNS~<DocType>~<LineType>~<LastStatus>~NextStatus> SALES_SCHLNS~<DocType>~<LineType>~<LastStatus>~NextStatus>
接頭辞を付けた値が、フラット・ファイルのSTATUS_CODE列、STATUS_NAME列に対応するように、STATUS_CLASS (SALES_ORDLNS、SALES_PCKLNS、およびSALES_SCHLNS)ごとにそれぞれコピーします。
次に構成の例を示します。
STATUS_CLASS,STATUS_CODE,STATUS_NAME,STATUS_CAT,STATUS_CAT_DESC SALES_ORDER_PROCESS,SALES_ORDLNS~SO~S~620~998,SALES_ORDLNS~SO~S~620~998,Being Processed,Being Processed SALES_ORDER_PROCESS,SALES_ORDLNS~SO~S~620~999,SALES_ORDLNS~SO~S~620~999,Closed,Closed SALES_ORDER_PROCESS,SALES_ORDLNS~SO~S~985~999,SALES_ORDLNS~SO~S~985~999,Closed,Closed SALES_PICKING_PROCESS,SALES_PCKLNS~SO~S~520~540,SALES_PCKLNS~SO~S~520~540,Not Yet Picked,Not Yet Picked SALES_PICKING_PROCESS,SALES_PCKLNS~SO~S~520~560,SALES_PCKLNS~SO~S~520~560,Not Yet Picked,Not Yet Picked
|
注意:
|
ハードコードされた3つの必須ステータスを構成に追加します。
FULFILLMENT_STATUS,ORDER BOOKED,ORDER BOOKED,Order Booked,Order Booked FULFILLMENT_STATUS,ORDER ENTERED,ORDER ENTERED,Order Entered,Order Entered FULFILLMENT_STATUS,ORDER FULLY CANCELLED,ORDER FULLY CANCELLED,Order Fully Cancelled,Order Fully Cancelled FULFILLMENT_STATUS,ORDER FULLY PICKED,ORDER FULLY PICKED,Order Fully Picked,Order Fully Picked FULFILLMENT_STATUS,ORDER FULLY SCHEDULED,ORDER FULLY SCHEDULED,Order Fully Scheduled,Order Fully Scheduled FULFILLMENT_STATUS,ORDER FULLY SHIPPED,ORDER FULLY SHIPPED,Order Fully Shipped,Order Fully Shipped FULFILLMENT_STATUS,ORDER PARTIALLY CANCELLED,ORDER PARTIALLY CANCELLED,Order Partially Cancelled,Order Partially Cancelled FULFILLMENT_STATUS,ORDER PARTIALLY SCHEDULED,ORDER PARTIALLY SCHEDULED,Order Partially Scheduled,Order Partially Scheduled FULFILLMENT_STATUS,ORDER PARTIALLY SHIPPED,ORDER PARTIALLY SHIPPED,Order Partially Shipped,Order Partially Shipped FULFILLMENT_STATUS,ORDER NOT ELIGIBLE,ORDER NOT ELIGIBLE,Order Not Eligible,Order Not Eligible SALES_INVOICE_PROCESS,SALES_INVCLNS~CANCELLED,SALES_INVCLNS~CANCELLED, Cancelled,Cancelled SALES_INVOICE_PROCESS,SALES_INVCLNS~COMPLETED,SALES_INVCLNS~COMPLETED, Completed,Completed SALES_INVOICE_PROCESS,SALES_INVCLNS~OPEN,SALES_INVCLNS~OPEN,Open,Open SALES_INVOICE_PROCESS,SALES_INVCLNS~PENDING,SALES_INVCLNS~PENDING,Pending, Pending SALES_ORDER_PROCESS,SALES_ORDLNS~BEING PROCESSED,SALES_ORDLNS~BEING PROCESSED, Being Processed,Being Processed SALES_ORDER_PROCESS,SALES_ORDLNS~BLOCKED,SALES_ORDLNS~BLOCKED,Blocked,Blocked SALES_ORDER_PROCESS,SALES_ORDLNS~BOOKED,SALES_ORDLNS~BOOKED,Booked,Booked SALES_ORDER_PROCESS,SALES_ORDLNS~CANCELLED,SALES_ORDLNS~CANCELLED,Cancelled, Cancelled SALES_ORDER_PROCESS,SALES_ORDLNS~CLOSED,SALES_ORDLNS~CLOSED,Closed,Closed SALES_ORDER_PROCESS,SALES_ORDLNS~ENTERED,SALES_ORDLNS~ENTERED,Entered,Entered SALES_PICKING_PROCESS,SALES_PCKLNS~CANCELLED,SALES_PCKLNS~CANCELLED,Cancelled,Cancelled SALES_PICKING_PROCESS,SALES_PCKLNS~FULLY PICKED,SALES_PCKLNS~FULLY PICKED,Fully Picked,Fully Picked SALES_PICKING_PROCESS,SALES_PCKLNS~FULLY SHIPPED,SALES_PCKLNS~FULLY SHIPPED, Fully Shipped,Fully Shipped SALES_PICKING_PROCESS,SALES_PCKLNS~NOT RELEVANT,SALES_PCKLNS~NOT RELEVANT,Not Relevant,Not Relevant SALES_PICKING_PROCESS,SALES_PCKLNS~NOT YET PICKED,SALES_PCKLNS~NOT YET PICKED, Not Yet Picked,Not Yet Picked SALES_PICKING_PROCESS,SALES_PCKLNS~BACKORDERED,SALES_PCKLNS~BACKORDERED, Backordered,Backordered SALES_PICKING_PROCESS,SALES_PCKLNS~PURGED,SALES_PCKLNS~PURGED,Purged,Purged SALES_SCHEDULE_PROCESS,SALES_SCHLNS~BLOCKED,SALES_SCHLNS~BLOCKED,Blocked, Blocked SALES_SCHEDULE_PROCESS,SALES_SCHLNS~CANCELLED,SALES_SCHLNS~CANCELLED,Cancelled, Cancelled SALES_SCHEDULE_PROCESS,SALES_SCHLNS~CLOSED,SALES_SCHLNS~CLOSED,Closed,Closed SALES_SCHEDULE_PROCESS,SALES_SCHLNS~ENTERED,SALES_SCHLNS~ENTERED,Entered, Entered SALES_SCHEDULE_PROCESS,SALES_SCHLNS~NOT VALID,SALES_SCHLNS~NOT VALID,Not Valid,Not Valid
ファイルを保存して閉じます。
この項では、file_lkp_chnl_typ_jde.csvの構成方法について説明します。このフラット・ファイルには、SDE_JDE_ChannelTypeDimensionワークフローを実行する前にデータを移入します。
file_lkp_chnl_typ_jde.csvファイルを構成するには:
次のSQLを使用して、JD Edwards EnterpriseOneソース・システムのチャネル・タイプを特定します。
SELECT DRKY FROM F0005 WHERE DRSY = '90CB' AND DRRT = 'TC'
テキスト・エディタを使用して、$PMServer\LkpFilesディレクトリ(INFA_HOME\server\infa_shared\LkpFilesなど)にあるfile_lkp_chnl_typ_jde.csvファイルを開きます。
SQLのDRKY列の値を、ファイルのCHNL_TYPE_CODE列にコピーします。
2行目以降のデータをコピーしてください。最初の行はカラム・ヘッダーです。
ファイルで、各チャネル・タイプ・コード(CHNL_TYPE_CODE)に対応するチャネル・タイプ・グループ・コード(W_CHTY_GRP_CODE)、チャネル・タイプ・サブグループ・コード(W_CHTY_SUBG_CODE)、およびW_INBOUND_TYPE_FLGに適切なドメイン値を追加します。
チャネル・タイプのドメイン値の詳細は、Oracle Business Analytics Warehouseデータ・モデル・リファレンスを参照してください。
ファイルを保存して閉じます。
この項では、file_lkp_consign_inv_org_jde.csvの構成方法について説明します。このフラット・ファイルには、SDE_JDE_Inventory_Daily_Bal_Factワークフローを実行する前にデータを移入します。
file_lkp_consign_inv_org_jde.csvを構成するには:
JD Edwards EnterpriseOneソース・システムの在庫委託支店/工場(ウェアハウスおよび在庫の組織ID)を特定します。
テキスト・エディタを使用して、$PMServer\LkpFilesディレクトリ(INFA_HOME\server\infa_shared\LkpFilesなど)にあるfile_lkp_consign_inv_org_jde.csvファイルを開きます。
ファイルの2行目に、有効な在庫委託支店/工場の値を手動で入力します。最初の行はカラム・ヘッダーです。
|
注意: 各支店/工場のデータは、先頭に空白を入力して右揃えにし、12文字で入力する必要があります。たとえば、支店/工場(INVENTORY_ORG_ID)がABCの場合は、先頭に9つの空白を入力して「---------ABC」とする必要があります。 |
以降、それぞれの在庫委託支店/工場を1行ずつ入力します。
委託の詳細は、Oracle Business Analytics Warehouseデータ・モデル・リファレンスを参照してください。
ファイルを保存して閉じます。
この項では、file_lkp_return_loc_jde.csvの構成方法について説明します。このフラット・ファイルには、SDE_JDE_Inventory_Daily_Bal_Factワークフローを実行する前にデータを移入します。
file_lkp_return_loc_jde.csvを構成するには:
JD Edwards EnterpriseOneソース・システムの各支店/工場(ウェアハウス/在庫の組織ID)に対する在庫返品場所を特定します。
テキスト・エディタを使用して、$PMServer\LkpFilesディレクトリ(INFA_HOME\server\infa_shared\LkpFilesなど)にあるfile_lkp_return_loc_jde.csvファイルを開きます。
ファイルの2行目に有効な在庫返品場所の値を手動で入力します。最初の行はカラム・ヘッダーです。
|
注意: 各返品場所のデータは、次の形式で1行ずつ入力する必要があります。STORAGE_LOC~支店/工場~場所~ロット番号 これらの意味は、次のとおりです。
たとえば、在庫返品場所の支店/工場がABC、場所が123、ロット番号が789の場合は、次の形式で入力します。 STORAGE_LOC~ ABC~123 ~789 |
以降、それぞれの在庫返品場所を1行ずつ入力します。
返品場所の詳細は、Oracle Business Analytics Warehouseデータ・モデル・リファレンスを参照してください。
ファイルを保存して閉じます。
この項では、部品表(BOM)をマルチレベルの構造に展開するように処理して、最終的にはW_BOM_HEADER_DおよびW_BOM_ITEM_Fの両方の表に移入する方法について説明します。
JD Edwards EnterpriseOneでは、BOM情報が単一レベルの形式で保持されますが、Oracle BI Applicationsでは、マルチレベルの形式で保持する必要があります。そのため、Oracle BI Applicationの各テーブルにデータをロードする前に、単一レベルの構造をマルチレベルの構造に展開する必要があります。
JD Edwards EnterpriseOneソースでは、すべてのBOM情報が単一の表に格納され、BOMに対してレベルが定義されていません。そのため、システムでループ処理を繰り返してBOMを展開する必要があります。また、Oracle BI Applicationsでは、コンポーネントに対するすべてのリビジョンが有効日とともにBOMの新しいバージョンとして保持されます。これらの点を考慮すると、ETLを使用して単一レベルのBOMをマルチレベルのBOMに変換するのは適切とはいえません。したがって、新しいUBEを作成して展開する際には、既存のJD Edwards EnterpriseOne UBE (R30460)のロジックが使用されていました。
新しいUBE (R30461)は、製造段階の製品を抽出し、単一レベルのBOM形式をマルチレベルのBOM形式に変換します。また、左限界値/右限界値や上位レベル(1 - 10)などの必要な情報も抽出します。
UBEは、製造段階の製品のマルチレベルのBOM構造を各リビジョンとともに2つのワーク・ファイルに、それぞれBOMヘッダー用および項目(コンポーネント)用としてロードします。続いて、ETLがこの2つのワーク・ファイルからデータを抽出して、Oracle BI Applicationsの各表にロードします。
|
注意: 部品表で分析を使用する場合は、ETLの開始前にこのUBEを実行する必要があります。このUBEおよび関連するJD Edwards EnterpriseOneのオブジェクトは、分析のために単独で作成されるため、既存のソース・システムでは使用できません。 |
SIL_BOMItemFactマッピングに含まれるCOMPUTE_BOUNDSというストアド・プロシージャによって、展開後のBOMツリー構造が探索され、左右の限界値が計算されます。デフォルトでは、COMPUTE_BOUNDSストアド・プロシージャはオフに設定されています。プロシージャをオンにする場合は、第6.3.2.15項「左限界値および右限界値の計算オプションの構成方法」を参照してください。
BOMを使用してETLを実行する前に、Compute_Bounds_Ora11i.sqlのSQLコードをコンパイルしてデプロイする必要があります。ストアド・プロシージャをデプロイするには、Oracle Business Intelligenceのインストール・ディレクトリからストアド・プロシージャのファイルをコピーし、ターゲットのデータ・ウェアハウスにデプロイします。
JD Edwards EnterpriseOneでは、UBE (R30461)によって左右の限界値が計算されます。
|
注意: ワークフローを実行する前にこのプロシージャをデータベースでコンパイルしないと、一部のセッションが失敗する場合があります。 |
COMPUTE_BOUNDSストアド・プロシージャをデプロイするには:
MW_HOME\biapps\dwrep\Informatica\Stored_Procedure_Scriptsフォルダに移動します。
ターゲットのデータベース・タイプ(たとえば、OracleやDB2)に該当するフォルダを選択します。
DB_type\Compute_Bounds_DB_type.sqlファイルにあるソース・コードを、ターゲットのデータ・ウェアハウスのスキーマにコピーします。
たとえば、Oracleデータベースの場合は、Oracle\Compute_Bounds_Ora11i.sqlからソースSQLコードをコピーします。
ターゲットのデータ・ウェアハウス・データベースで、ストアド・プロシージャをコンパイルします。
|
注意: ストアド・プロシージャをデプロイする際に問題が発生した場合は、データベースのリファレンス・ガイドを参照するか、データベース管理者に連絡してください。 |
この項では、Oracle Supply Chain and Order Management Analyticsに適用される追加の構成手順について説明します。内容は次のとおりです。
第6.3.1項「すべてのソース・システム用にOracle Supply Chain and Order Management Analyticsを構成するための手順」
第6.3.2項「Oracle EBS用にOracle Supply Chain and Order Management Analyticsを構成するための手順」
この項では、すべてのソース・システムに適用される構成手順について説明します。内容は次のとおりです。
第6.3.1.2項「Oracle Supply Chain and Order Management Analyticsのテーブルの集計プロセス」
第6.3.1.3項「Oracle Supply Chain and Order Management Analyticsでの複数製品の追跡について」
第6.3.1.5項「Oracle Supply Chain and Order Management 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_ACCOUNT_ID)
予約における次元属性の変更を追跡するには:
Informatica PowerCenter Designerで、SDE_ORA115Version_AdaptorまたはSDE_ORAR12_Adaptorフォルダを開きます。
次のマッピングのいずれかを開きます。
mplt_SA_ORA_SalesOrderLinesFact
mplt_SA_ORA_SalesScheduleLinesFact
適切な「Expression transformation」をダブルクリックして、「Edit Transformation」ボックスを開きます。
EXP_SALES_ORDLNS
EXP_SALES_SCHLNS
「Ports」タブで、EXT_BOOKING_IDポートに対する式を編集し、変更を追跡する属性のIDを入力します。
複数の属性の変更を追跡する場合は、すべての属性のIDを連結し、連結値をVAR_BOOKING_IDカラムに挿入します。
変更を確認し、リポジトリに保存します。
この項では、Sales Invoice LinesテーブルおよびSales Order Linesテーブルの集計におけるOracle Supply Chain and Order Management 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パラメータには、次の値を指定できます。
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ファイルを構成し、初期ワークフローと増分ワークフローを実行する必要があります。テキスト・エディタを使用して、DAC ServerコンピュータのDac\Informatica\parameters\inputフォルダにあるparameterfileDW.txtファイルを開きます。次に例を示します。
C:\orahome\10gversion\bifoundation\dac\Informatica\parameters\input
Sales Invoice Lines集計テーブルを構成するには:
DACで、「Design」ビューに移動して、適切なカスタム・コンテナをドロップダウン・リストから選択します。
「Tasks」タブを表示します。
次の各タスクごとに、「Parameters」タブを表示して、TIME_GRAINパラメータの「Value」フィールドに適切な値を指定します。
SIL_SalesInvoiceLinesAggregate_Derive_PreLoadImage
SIL_SalesInvoiceLinesAggregate_Derive_PreSoftDeleteImage
PLP_SalesInvoiceLinesAggregate_Derive_PostLoadImage
PLP_SalesInvoiceLinesAggregate_Load
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パラメータには、次の値を指定できます。
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集計テーブルを構成するには:
DACで、「Design」ビューに移動して、適切なカスタム・コンテナをドロップダウン・リストから選択します。
「Tasks」タブを表示します。
次の各タスクごとに、「Parameters」タブを表示して、TIME_GRAINパラメータの「Value」フィールドに適切な値を指定します。
SIL_SalesOrderLinesAggregate_Derive_PreLoadImage
SIL_SalesOrderLinesAggregate_Derive_PreSoftDeleteImage
PLP_SalesOrderLinesAggregate_Derive_PostLoadImage
PLP_SalesOrderLinesAggregate_Load
複数の製品が単体化され1つのパッケージとして販売される場合は、Sales Order Linesテーブルにある2つのカラム(ORDHD_KEY_IDとORDLN_KEY_ID)を使用することで、それらの製品を追跡します。これらの2つのカラムにより、単体として販売されるすべての製品間の関係を分析できます。ORDHD_KEY_ID列には、販売オーダー全体のオーダーIDが格納されます。ORDLN_KEY_ID列には、親製品の明細項目IDが格納されます。
たとえば、ある顧客がコンピュータ、スキャナ、プリンタから成るパッケージを購入したとします。これらとは別に、その顧客はモニターも購入したとします。この場合は、パッケージとモニターという2つの親項目があります。コンピュータ、スキャナおよびプリンタはすべて、親オーダーであるパッケージの子オーダーとなり、モニターは1つの項目から成る親オーダーとなります。
表6-3に示すように、データ・ウェアハウスではこの販売情報がSales Order Linesテーブルに格納されます。ORDLN_KEY_IDフィールドには親製品の明細項目IDが格納され、それによりパッケージ内の製品の親子関係情報を管理します。この例のORDLN_KEY_IDフィールドには、親パッケージである親Aの一部として販売された3つの子製品(A1、A2、A3)に対して、それぞれLine_1が指定されています。
表6-3 親子関係があるSales Orderテーブルのカラム
| Key_ID | SALES_ORDER_NUM | PRODUCT_ID | ORDHD_ KEY_ID | ORDLN_ KEY _ID | 関係(テーブルのカラムではありません) |
|---|---|---|---|---|---|
|
Line_1 |
1000 |
パッケージ |
1000 |
Line_1 |
親A |
|
Line_2 |
1000 |
コンピュータ |
1000 |
Line_1 |
子A1 |
|
Line_3 |
1000 |
スキャナ |
1000 |
Line_1 |
子A2 |
|
Line_4 |
1000 |
プリンタ |
1000 |
Line_1 |
子A3 |
|
Line_5 |
1000 |
モニター |
1000 |
Line_5 |
親B(子はなし) |
これとは対照的に、表6-3の4つの項目がすべて個々の製品として購入された場合は、ORDLN_KEY_IDの各行に異なる明細項目IDが指定されます。この場合のSales Order Linesテーブルは、表6-4のようになります。
Order Cycle Timeテーブルに日付をさらに追加するには、このテーブルがどのようにポピュレートされるかを理解する必要があります。つまり、Order Cycle Timeテーブル(W_SALES_CYCLE_LINE_F)にロードする日付を変更するには、W_*テーブルから日付を取得しOrder Cycle TimeテーブルにロードするPLP_SalesCycleLinesFact_LoadマッピングとPLP_SalesCycleLinesFact_Load_Fullマッピングを変更する必要があります。
Cycle Timeテーブルにロードする日付を追加するには:
Informatica PowerCenter Designerで、ロード後処理用の構成フォルダを(つまり、PLPフォルダ)を開きます。
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カラムが含まれるようにします。
Mapping Designerで、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テーブルのエントリは、表6-5に示すようになります。
表6-5 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テーブルの既存行が更新され、表6-6のようになります。
表6-6 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テーブルは、表6-7に示すような内容になります。
表6-7 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テーブルは、表6-8のようになります。
表6-8 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 |
バックログ履歴は月レベルで保持されるため、バックログ履歴の内容は部分的なものとなります。表6-8に示された最新のBacklog Historyテーブルからは、販売オーダー番号1には、5項目の財務バックログ項目が残されていたことがわかります。この販売注文における最初の財務バックログ項目数量が不明ですが、前月末時点での数量のみが判明しています。
バックログにおける項目の変動状況をより詳細に追跡管理する場合は、より綿密な粒度レベルで履歴を保持する必要があります。たとえば、バックログのオープン時に記録された項目数量を調べる必要がある場合は、バックログ履歴を月レベルではなく日レベルで追跡管理する必要があります。
たとえば、バックログ履歴を日レベルで保持すると、2月1日終了時点での販売オーダー1の最初のバックログ数量が10で、それが2月2日に5に減少したことが判明します。このように、履歴を日レベルで追跡管理することにより、項目がバックログから消去されるまでの経過日数であるサイクル時間を算出できます。ただし、バックログ履歴を日レベルで追跡管理すると、Backlog Historyテーブルのサイズが急激に増大することがあります。このため、詳細レベルでバックログ履歴を記録すると、パフォーマンスが低下する場合があります。
バックログ履歴データを保持する期間を変更する場合は、すべてのタイプのバックログが同じレベルで格納されるように確認する必要がありますが、それには複数のマッピングを変更する必要があります。表6-9に、該当するすべてのマッピングと、変更が必要なそれらの式変換を示します。
表6-9 Oracle 11iおよびOracle R12: バックログ履歴用のマッピングと式変換
| マッピング | 式変換 |
|---|---|
|
PLP_SalesBacklogLinesfact_LoadOrderLines |
EXP_SALES_ORNLNS_BACKLOG |
|
PLP_SalesBacklogLinesfact_LoadScheduleLines |
EXP_SALES_SCHLNS_BACKLOG |
バックログ履歴期間のデフォルトは月です。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 Supply Chain and Order Management Analyticsでは、W_CUSTOMER_STATUS_HIST_Fは、オーダーの頻度に基づいて顧客の状況を追跡管理する要素テーブルです。可能な状況値は、NEW、RECENT、DORMANTおよびLOSTです。各状況バケットの期間は構成可能ですが、出荷時の設定はカレンダー年です。このテーブルの単位は、顧客、顧客状況および状況開始日のレベルです。この後の項では、このテーブルに適用可能な構成手順、その意味および実装方法について説明します。
この項では、Customer Status History要素テーブルに適用可能な次の構成について説明します。
データ・ウェアハウス識別子の構成
各状況バケットの期間の構成
データ・ウェアハウス識別子の構成
このテーブルでは、Oracle BI Applicationsで定義されている状況(NEW、RECENT、DORMANT、LOSTなど)がいくつか使用されます。これらの状況データは、事前パッケージされたデフォルトCSVファイルから直接データ・ウェアハウスにロードされます。このファイルのデータは、各企業の顧客データや販売データが格納されたOLTPソース・システムとは無関係です。事前パッケージされたデフォルト・データ・ウェアハウス状況とソースベースの状況を区別するには、固有の識別子が必要です。Informaticaマッピング・パラメータの$$WH_DATASOURCE_NUM_IDが、この目的に対応します。
事前パッケージされたデフォルト値には、識別子値として999が設定されています。特別な事情のないかぎり、組織のデータソース(Oracle EBS 11.5.10など)には、この値(999)を構成しないでください。
$$WH_DATASOURCE_NUM_ID値の構成方法の詳細は、第6.3.1.9項「Customer Status History要素テーブルの構成方法」を参照してください。
各状況バケットの期間の構成
ある顧客が製品やサービスを初めてオーダーすると、その顧客の状況がOracle BI ApplicationsによりNEWに設定されます。その後、顧客が一定のオーダー・パターンを示す場合、各オーダー間の間隔が構成可能なビジネス定義期間よりも短いかぎり、その顧客の状況は同じ状況のままになります。このInformaticaパラメータ$$PERIODの値(デフォルトは365日)は構成可能です。通常、商品販売の回転頻度が高い業種(小売業など)の多くの企業では、この期間値は30日に定義しています。一方、販売回転頻度が低い業種の企業では、この期間が730日でも問題がない場合があります。
顧客がこの期間に一度も注文しなかった場合、その顧客の状況は次の状況であるRECENTになります。同様に、RECENTになってから対象期間に一度も注文しないと、状況はDORMANTになります。最後に、DORMANTになってから対象期間に一度も注文しないと、状況がLOSTに設定されます。
ただし、DORMANT状況の顧客がオーダーすると、顧客の状況はOracle BI Applicationsにより、RECENTに戻されます。同様に、LOST状況の顧客が注文した場合も、状況はRECENTに戻ります。
これらの例で示すように、この期間を適切な値に設定することはビジネスにとって重要です。多くの組織では、顧客の現在の状況(つまり、注文パターン)に基づいて顧客を区分し、各状況の顧客に応じて異なるキャンペーンを企画して、異なる方法で実行する傾向にあります。
$$PERIOD値の構成方法の詳細は、第6.3.1.9項「Customer Status History要素テーブルの構成方法」を参照してください。
この項では、$$WH_DATASOURCE_NUM_ID変数と$$PERIOD変数を使用して、Customer Status History要素テーブルを構成する手順について説明します(これらの変数の詳細は、第6.3.1.8項「Customer Status History要素テーブルの構成」を参照)。
$$WH_DATASOURCE_NUM_IDの値を変更するには:
DACで、「Design」ビューに移動して、適切なカスタム・コンテナをドロップダウン・リストから選択します。
「Source System Parameters」タブを表示し、$$WH_DATASOURCE_NUM_IDパラメータを探します。
「Edit」サブタブの「Value」フィールドに適切な値を入力します。
変更を保存します。
DACで、「Design」ビューに移動して、適切なカスタム・コンテナをドロップダウン・リストから選択します。
「Tasks」タブを表示して、次の2つのタスクに対して問合せを行います。
PLP_CustomerStatusHistoryFact_New_Customers_Load
PLP_CustomerStatusHistoryFact_Status_Revalidate
タスクごとに、「Parameters」サブタブを表示して、「Value」フィールドに適切な値を入力します。
両方のタスクに対して、必ず同じ値を指定します。
変更を保存します。
在庫月間残高集計テーブル(W_INVENTORY_DAILY_BALANCE_F_A1)を構成するには、集計レベル、集計更新期間および在庫残高表レコードの保有期間を考慮する必要があります。
在庫月間残高テーブルを構成するには、次の3つのパラメータを構成する必要があります。
GRAIN
GRAINパラメータのデフォルト値はMONTHです。GRAINパラメータには、次の値を指定できます。
DAY
WEEK
MONTH
QUARTER
YEAR
KEEP_PERIOD
KEEP_PERIODパラメータのデフォルト値はMONTHです。KEEP_PERIODパラメータには、次の値を指定できます。
DAY
WEEK
MONTH
QUARTER
YEAR
NUM_OF_PERIOD
NUM_OF_PERIODパラメータのデフォルト値は3です。NUM_OF_PERIODパラメータの値には、1、2、3などの正の整数を指定します。
|
注意: 3か月以上前の周期のインベントリ調整データが必要な場合、KEEP_PERIODとNUM_OF_PERIODのパラメータ値を変更する必要があります。たとえば、過去3年間のデータが必要な場合は、KEEP_PERIODをYEARに、NUM_OF_PERIODを3に設定します。 |
初期ETLセッションまたは増分ETLセッションを実行して在庫月間残高表をロードする前に、在庫月間残高表を次のように構成します。
在庫月間残高を構成するには:
DACで、「Design」ビューに移動して、適切なカスタム・コンテナをドロップダウン・リストから選択します。
「Tasks」タブを表示します。
次のタスクごとに、「Parameters」サブタブを表示して、指定されたパラメータ名とパラメータ値を作成します。
PLP_InventoryMonthlyBalance $$GRAIN 'MONTH'
PLP_InventoryDailyBalance_Trim $$KEEP_PERIOD 'MONTH'
PLP_InventoryDailyBalance_Trim $$NUM_OF_PERIOD 3
在庫月間残高テーブルを増分リフレッシュするには:
月間残高集計テーブル(W_INVENTORY_MONTHLY_BAL_F)から特定期間のレコードを削除します。
削除する期間はGRAINパラメータで指定します。たとえば、GRAINがMONTHで、日付が2005年5月15日の場合、4月と現在の月(5月)のすべてのレコードが月間残高テーブル(W_INVENTORY_MONTHLY_BAL_F)から削除されます。
この手順は、PLP_InventoryMonthlyBalanceワークフロー・マッピングを実行することによって実装されます。
在庫残高要素テーブル(W_INVENTORY_DAILY_BALANCE_F)のレコードを取得し、そのレコードを特定の単位レベルで月間残高テーブル(W_INVENTORY_MONTHLY_BAL_F)にロードします。
たとえば、GRAINがMONTHに設定されている場合、W_INVENTORY_DAILY_BALANCE_F要素テーブルの月末の残高レコードが月間残高(W_INVENTORY_MONTHLY_BAL_F)に格納されて集計されます。
この手順は、S_M_PLP_INV_BALANCE_A1_AGGセッションとM_PLP_INV_BALANCE_A1_AGGマッピングを実行することによって実装されます。現在の月間残高については、前日の残高レコード(前日が同じ月の場合)がW_INVENTORY_MONTHLY_BAL_Fから削除され、現在の日付の残高レコードがW_INVENTORY_BALANCE_FからW_INVENTORY_MONTHLY_BAL_Fにロードされます。
この手順は、PLP_InventoryMonthlyBalanceワークフローを実行することによって実装されます。
古いレコードをW_INVENTORY_DAILY_BALANCE_F要素テーブルから削除します。
古いレコードを削除するには、KEEP_PERIODおよびNUM_OF_PERIODパラメータを使用します。たとえば、KEEP_PERIODがMONTH、NUM_OF_PERIODが1、日付が2005年5月15日の場合、4月と現在の月(5月)のレコードが維持され、それ以前の古いレコードは削除されます。
この手順は、PLP_InventoryDailyBalance_Trimワークフローを実行することによって実装されます。
|
注意: 切捨プロセスは、表内のデータ・サイズを削減します。古い日次残高レコードが参照不能になる点に十分注意してください。ただし、月末残高は参照できます。したがって、必ずNUM_OF_PERIOD値を調整して、必要に応じたデータの量とデータの最新性を反映してください。 |
製品トランザクション集計テーブル(W_PRODUCT_XACT_A)を構成するには、初期ETLを実行してから増分ETLを実行するという、2つの集計シナリオが必要です。
初期ETLの実行では、集計レベルと、製品トランザクション要素テーブルに維持する履歴の期間を構成する必要があります。
また、GRAINパラメータを使用して、集計単位も構成する必要があります。
増分ETLの実行では、次のパラメータを使用して、集計レベル、集計更新期間および製品トランザクション要素テーブルに維持する履歴の期間を構成する必要があります。
GRAIN
GRAINパラメータは、集計レベルを指定します。指定できる値は、DAY、WEEK、MONTH(デフォルト値)、QUARTER、YEARです。
REFRESH_PERIOD
REFRESH_PERIODパラメータは、NUM_OF_PERIODとともに使用され、トランザクション・テーブルから集計テーブルにレコードを更新する期間を指定します。指定できる値は、DAY、WEEK、MONTH(デフォルト値)、QUARTER、YEARです。
NUM_OF_PERIOD
NUM_OF_PERIODパラメータは、REFRESH_METHODとともに使用され、トランザクション・テーブルから集計テーブルにレコードを更新する期間を指定します。指定できる値は、1、2、3(デフォルト値)などの正の整数です。
初期ETLセッションと、その後の増分ETLセッションを実行して、製品トランザクション集計テーブルをロードする前に、製品トランザクション集計テーブルを次のように構成する必要があります。
製品トランザクション集計テーブルを構成するには:
DACで、「Design」ビューに移動して、適切なカスタム・コンテナをドロップダウン・リストから選択します。
「Tasks」タブを表示します。
PLP_ProductTransactionAggregateという名前のタスクを探して、「Parameters」サブタブを表示し、次の3つのパラメータがこのとおりに設定されていることを確認します。
$$REFRESH_PERIOD = 'MONTH'
$$GRAIN = 'MONTH'
$$NUM_OF_PERIOD = 3
注意: 3つのパラメータのいずれかが存在しない場合は、そのパラメータを前述の値が指定された、データ型 = テキストという形式で作成してください。
初期ETLを実行できるように製品トランザクション集計テーブルを構成するには:
製品トランザクション要素テーブル(W_PRODUCT_XACT_F)内のレコードを取得し、それらのレコードを特定の単位レベルで製品トランザクション集計テーブル(W_PRODUCT_XACT_A)に集計します。
たとえば、GRAINがMONTHに設定されている場合、W_PRODUCT_XACT_F要素テーブルのレコードが取得され、月レベルでW_PRODUCT_XACT_Aテーブルに集計されます。
この手順は、PLP_ProductTransactionAggregatelワークフローを実行することによって実装されます。
増分ETLを実行できるように製品トランザクション集計テーブルを構成するには:
製品トランザクション集計テーブル(W_PRODUCT_XACT_A)から特定期間の更新済レコードを削除します。
削除する期間はREFRESH_PERIODおよびNUM_OF_PERIODパラメータで指定します。
たとえば、REFRESH_PERIODがMONTH、NUM_OF_PERIODが1、日付が2005年5月15日の場合、4月と現在の月(5月)のすべてのレコードがW_PRODUCT_XACT_Aテーブルから削除されます。
この手順は、PLP_ProductTransactionAggregateワークフローを実行することによって実装されます。
製品トランザクション要素テーブル(W_PRODUCT_XACT_F)内のレコードを取得し、それらのレコードを特定の単位レベルでW_PRODUCT_XACT_Aテーブルに集計します。
たとえば、GRAINがMONTHに設定されている場合、W_PRODUCT_XACT_F要素テーブルのレコードが取得され、月レベルでW_PRODUCT_XACT_Aテーブルに集計されます。
この手順は、PLP_ProductTransactionAggregateワークフローを実行することによって実装されます。
この項では、Oracle EBSに適用される構成手順について説明します。内容は次のとおりです。
デフォルトでは、図6-1に示すように、予約オーダーのみがOracleソース・システムから抽出されます。そのため、Sales Order Linesテーブル、Sales Schedule Linesテーブル、Sales Booking Linesテーブルにロードされるオーダーはすべて予約済です。
未予約のオーダーをSales Order LinesテーブルおよびSales Schedule Linesテーブルにロードする場合は、未予約オーダーがフィルターで除外されないように抽出を構成する必要があります。Oracle 11iおよびOracle R12では、OE_ORDER_LINES_ALL.BOOKED_FLAG = 'Y'条件はオーダーが予約されていることを示します。そのため、この文は未予約オーダーを除外するために使用されます。未予約オーダーを含む、すべてのオーダーをロードするには、次のオブジェクトでソースSQL問合せからフィルタ条件を削除します。
SDE_ORA_SalesOrderLinesFact (マッピング)
SDE_ORA_SalesOrderLinesFact_Primary (マッピング)
SDE_ORA_SalesOrderLinesFact_Full (セッション)
Sales Order LinesテーブルとSales Schedule Linesテーブルに未予約オーダーを含める場合、Sales Booking Linesテーブルを販売オーダー明細や販売スケジュール明細から移入するときに、未予約オーダーを除外する必要があります。これは、W_SALES_ORDER_LINE_F.BOOKING_FLG = 'Y'条件を、次のマッピングのソースSQL問合せに追加することにより、実行できます。
SIL_SalesBookingLinesFact_Load_OrderLine_Credit、SIL_SalesBookingLinesFact_Load_OrderLine_Debit
SIL_SalesBookingLinesFact_Load_ScheduleLine_Credit、SIL_SalesBookingLinesFact_Load_ScheduleLine_Debit
デフォルトでは、予約オーダーのみが、Sales Order Linesテーブル(W_SALES_ORDER_LINES_F)、Sales Schedule Linesテーブル(W_SALES_SCHEDULE_LINE_F)およびSales Booking Linesテーブル(W_SALES_BOOKING_LINE_F)にロードされます。ただし、Sales Booking Linesテーブル(W_SALES_BOOKING_LINE_F)には予約済オーダーのみをロードしますが、Sales Order Linesテーブル(W_SALES_ORDERS_LINES_F)とSales Schedule Linesテーブル(W_SALES_SCHEDULE_LINE_F)には、未予約オーダーもロードできます。
Sales Order LinesテーブルとSales Schedule Linesテーブルに未予約オーダーを含めるには(増分ロード):
Informatica PowerCenter Designerで、SDE_ORA115Version_AdaptorまたはSDE_ORAR12_Adaptorフォルダを開きます。
Mapplet Designerで、mplt_BC_ORA_SalesOrderLinesFactマップレットを開き、チェックアウトします。
SQ_BCI_SALES_ORDLNSソース修飾子をダブルクリックして、「Edit Transformations」ボックスを開きます。
「Properties」タブを表示します。
「Transformation Attribute」の「Sql Query」、「User Defined Join」および「Source Filter」に対して、次の手順を実行します。
「Value」フィールドにある下向きの矢印を選択し、「SQL Editor」ボックスを表示します。
「SQL」ボックスで、「Transformation Attribute」の「Sql Query」、「User Defined Join」および「Source Filter」から、AND OE_ORDER_LINES_ALL.BOOKED_FLAG='Y' (またはOE_ORDER_LINES_ALL.BOOKED_FLAG='Y' AND)の行を削除します。「Transformation Attribute」の「User Defined Join」と「Source Filter」には、この行がない場合があります。
「OK」をクリックして変更を保存します。
変更内容を確認してリポジトリに保存し、マップレットをチェックインします。
Mapplet Designerで、mplt_BC_ORA_SalesOrderLinesFact_Primaryを開きます。Sales Order Lines Primaryテーブルに、手順3から6を繰り返します。
Sales Order LinesテーブルとSales Schedule Linesテーブルに未予約オーダーを含めるには(完全ロード):
Informatica PowerCenter Workflow Managerで、SDE_ORA115Version_Adaptor or SDE_ORAR12_Adaptorフォルダを開きます。
SDE_ORA_SalesOrderLinesFact_FullセッションをTask Developerにドラッグします。
セッションをチェックアウトしてダブルクリックし、「Edit Tasks」ウィンドウを開きます。
「Mapping」タブを表示し、左ペインで「mplt_BC_ORA_SalesOrderLinesFact.SQ_BCI_SALES_ORDLNS」をクリックします。
右ペインの「Properties」の、「Sql Query Attribute」、「Source Filter Attribute」および「User Defined Join Attribute」に対して、次の手順を実行します。
「Value」フィールドにある下向きの矢印を選択し、「SQL Editor」ボックスを表示します。
「SQL」ボックスで、「Sql Query Attribute」、「Source Filter Attribute」および「User Defined Join Attribute」から、AND OE_ORDER_LINES_ALL.BOOKED_FLAG='Y' (またはOE_ORDER_LINES_ALL.BOOKED_FLAG='Y' AND)の行を削除します。「User Defined Join Attribute」または「Source Filter Attribute」には、この行がない場合があります。
「OK」をクリックして変更を保存します。
変更内容を確認してリポジトリに保存し、セッションをチェックインします。
Sales Booking Linesテーブルに予約済オーダーのみを含めるには:
Informatica PowerCenter Designerで、SILOSフォルダを開きます。
Mapping Designerで、SIL_SalesBookingLinesFact_Load_OrderLine_Creditマッピングを開き、チェックアウトします。
SQ_W_SALES_ORDER_LINE_Fソース修飾子をダブルクリックして、「Edit Transformations」ボックスを開きます。
「Properties」タブを表示します。
「Transformation Attribute」の「Source Filter」と「Sql Query」が空ではない場合には、次の手順を実行します。
「Value」フィールドにある下向きの矢印を選択し、「SQL Editor」ボックスを表示します。
「SQL」ボックスで、W_SALES_ORDER_LINE_F.BOOKING_FLG = 'Y' (既存のフィルタがある場合はこれに加えてAND)を「Transformation Attribute」の「Sql Query」または「Source Filter」に追加します。
注意: 「Transformation Attribute」の「Sql Query」が空の場合は、この行を追加しないでください。その場合は、「Transformation Attribute」の「Source Filter」にのみ行を追加します。
「OK」をクリックして変更を保存します。
変更内容を確認してリポジトリに保存し、マッピングをチェックインします。
手順2～6を繰り返して、SIL_SalesBookingLinesFact_Load_OrderLine_Debit、SIL_SalesBookingLinesFact_Load_ScheduleLine_CreditおよびSIL_SalesBookingLinesFact_Load_ScheduleLine_Debitをマッピングします。
販売スケジュール明細は、各注文項目の出荷予定に関する詳細です。各販売注文は販売注文明細に細分化され、その各販売注文明細が複数のスケジュール明細を持つことがあります。
たとえば、特定の販売注文明細に対応するだけの十分な在庫がない場合は、2つのスケジュールを作成して注文に対応します。1つのスケジュールには、現在の在庫数量を設定し、もう一方のスケジュールには、残りの数量を製造して出荷できるだけの期間を設定します。この情報はW_SALES_SCHEDULE_LINE_Fテーブルに格納されます。ここでは、このテーブルに格納される情報のタイプを変更する方法について説明します。
Oracle 11iおよびOracle R12の初期構成では、予約は販売注文明細レベルで記録されます。図6-2に示すように、Bookingsテーブルには各予約オーダーに対して行が1行以上作成されます。
SDE_ORA115Version_AdaptorまたはSDE_ORAR12_Adaptorコンテナには、サブジェクト・エリアが2つあります。
企業販売 - 予約明細と注文明細
企業販売 - 予約明細とスケジュール明細
Oracle BI Applicationsによりインストールされる実行プランでは、デフォルトで使用されるサブジェクト・エリアは、企業販売 - 予約明細と注文明細です。予約明細をスケジュール明細レベルでロードする場合は、新しい実行プランを作成し、企業販売 - 予約明細と注文明細のかわりに、企業販売 - 予約明細とスケジュール明細サブジェクト・エリアを含めます。
予約は、販売注文明細レベルではなく、販売スケジュール明細レベルでも記録できます。販売スケジュール明細レベルでは、注文がスケジュール明細により区分けされるため、より詳細な粒度で予約を表示できます。スケジュール明細レベルで予約を記録する場合は、図6-3に示すように、Bookingsテーブルでは各スケジュール明細に対して行が1行作成されます。Oracle Applicationsのスケジュール明細の粒度は、注文明細と同じ粒度になります。そのため、予約明細をスケジュール明細から取得する場合、予約明細はスケジュール済の注文明細に制限されます。
期日前出荷と期日後出荷の定義を構成するには、mplt_SA_ORA_SalesPickLinesFactマップレットのEXP_SALES_PCKLNS式を編集します。mplt_SA_ORA_SalesPickLinesFactマップレットは、SDE_ORASalesPickLinesFactマッピングにより使用されます。
このマップレットは、実際の在庫出し日と出荷日を出荷予定日で比較し、注文が遅延していないかどうかを判定します。
期日前出荷と期日後出荷の許容日数を定義するには:
parameterfileOLTP.txtファイルを開き、セクション[SDE_ORA_SalesPickLinesFact]を探します。
変更する許容範囲のパラメータを編集します。
次に例を示します。
実際の在庫出し日が出荷予定日よりも2日遅れた場合に期日後出荷フラグを設定する場合は、$$PICK_LATE_TIME_TOL=2を設定します。
期日前出荷として扱うためのフラグの日数を設定するには、$$PICK_EARLY_TIME_TOLの値を設定します。
期日後出荷として扱うためのフラグの日数を設定するには、$$PICK_LATE_TIME_TOLの値を設定します。
出荷の許容日数を変更する場合は、出荷パラメータ($$SHIP_LATE_TIME_TOLと$$SHIP_EARLY_TIME_TOL)の値を設定します。
変更を確認し、パラメータ・ファイルに保存します。
販売請求書明細は、顧客から注文を受けた項目に関する支払情報です。この情報はW_SALES_INVOICE_LINE_Fテーブルに格納されます。ここでは、このテーブルに格納される情報のタイプを変更する方法について説明します。
デフォルトでは、Oracle Supply Chain and Order Management Analyticsアプリケーションは、販売請求書データを抽出する際に、完了した販売請求書を抽出するように構成されています。Oracle 11iおよびOracle R12では、フラグを使用することで、販売請求書が完了しているかどうかが示されます。具体的にいうと、完了した販売請求書とは、Oracle 11iおよびOracle R12でRA_CUSTOMER_TRX_ALL.COMPLETE_FLAG = Yとなっている請求書のことです。
完了した販売請求書と同様に未完了の販売請求書を抽出するには、抽出のフィルター文を削除します。
販売請求書の抽出フィルタを削除するには:
Informatica PowerCenter Designerで、SDE_ORA115Version_AdaptorまたはSDE_ORAR12_Adaptorフォルダを開きます。
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を繰り返します。
すぐに使用可能なETLコンポーネントのバックログとサイクル明細は、バックログ、在庫出しおよびサイクル明細のテーブルが、Oracle EBSインタフェース・プログラムなどを使用して、出荷情報と請求情報で更新されていることを前提としています。Oracle Order Lineテーブルが出荷情報と請求情報で更新されていない場合、デフォルトのETLコンポーネントを次のように更新する必要があります。
オーダー明細を構成するには:
Informatica PowerCenter Designerで、PLP\Mappingsフォルダを開きます。
Mapping Designerを使用して、PLP_SalesCycleLinesFact_LoadマッピングとPLP_SalesCycleLinesFact_Load_Fullマッピングを次のように編集します。
Mapping Designerでマッピングを開きます。
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で、次を実行します。
「Design」ビューに移動して、ドロップダウン・リストから適切なカスタム・コンテナを選択します。
「Configuration Tags」タブを表示します。
「Sales PLP Optional Tasks」タグに対して問合せを実行します。
「Subject Area」サブタブを表示します。
「Inactive」チェック・ボックスをオフにして、該当するサブジェクト・エリアをアクティブ化します。
PowerCenter Designerで、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 Supply Chain and Order Management Analyticsアプリケーションが使用するテーブルは、Oracle Financial Analyticsアプリケーションでも使用されます。
Oracle 11iおよびOracle R12では、次のOracle Financial Analytics用構成手順を使用して、Oracle Supply Chain and Order Management 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 PowerCenter DesignerのMapplet Designerで、mplt_SA_ORA_SalesOrderLinesFactマップレットを開きます。
MAPI_SALES_ORDLNS変換をダブルクリックして、「Edit Transformation」ボックスを開きます。
「Ports」タブを表示します。
「EXP_SALES_ORDLNS」変換を選択します。
VAR_BOOKING_IDポートの式を編集します。
このシナリオにおいてに担当営業者が変更された場合にソース・システムとW_SALES_BOOKING_LINE_Fテーブルがどのような影響を受けるかについて、この後の説明と表で示します。
1日目: 担当営業者1001が注文を受けました。ソース・システムには、表6-10に示すような内容の情報が表示されます。
表6-10 Oracle 11iおよびOracle R12: 1日目の営業終了時点におけるソース・システムのテーブル行
| 販売注文番号 | 販売注文明細番号 | 担当営業者ID | 数量 | 販売価格 | 日付 |
|---|---|---|---|---|---|
|
1 |
1 |
1001 |
100 |
25 |
1-June-2000 |
表6-10の行は、IA Bookingsテーブル(W_SALES_BOOKING_LINE_F)に表6-11のような形式で入力されます。
表6-11 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に変更されます。変更後のソース・システムの行は、表6-12に示すような内容になります。
表6-12 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テーブルの行は表6-13のようになります。
バックログ情報は、W_SALES_BACKLOG_LINE_FテーブルとW_SALES_BACKLOG_HISTORY_Fテーブルに格納されます。この項では、これらのテーブルに格納される情報のタイプを変更する方法について説明します。Oracle Supply Chain and Order Management Analyticsアプリケーションには、財務バックログ、出荷待ちバックログ、延滞バックログ、予定済バックログ、未予定バックログ、保留バックログなど、様々なタイプのバックログが用意されています。バックログの各タイプは、セールスプロセスにおける特定の2つの日付により定義されるため、バックログの計算には複数の要素テーブルが検索されます。
たとえば、財務バックログには、注文を受けたが支払いを受領していない項目が記録されます。したがって、財務バックログの項目数の計算には、Sales Order Linesテーブル(注文を受けた項目の特定)とSales Invoice Linesテーブル(支払いを受領した注文の特定)が使用されます。これらの2つのテーブルを使用することで、財務バックログに記録する項目の数と値を特定できます。
デフォルトでは、Oracle Supply Chain and Order Management 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に設定されています。したがって、すべての販売注文がバックログ計算の対象となります。
オープンなオーダーを抽出するフィルターを削除するには:
Informatica PowerCenter Designerで、SDE_ORA115Version_AdaptorまたはSDE_ORAR12_Adaptorフォルダを開きます。
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'条件を削除します。
「部品表」(BOM)機能エリアでは、完成品を構成するコンポーネントを分析できます。BOMにより、特定のコンポーネントを使用する製品がいくつあるかを調べることができます。また、完成品について完全なBOM階層を明らかにすることもできます。BOM構造を開くには、特定のオブジェクトをEBSシステムにデプロイする必要があります。
ETLをapps_read_onlyユーザーとして実行するには、APPSスキーマから次のDCLコマンドを実行する必要があります。
Grant insert on opi.opi_obia_w_bom_header_ds to &read_only_user; Grant analyze any to &read_only_user;
BOM構造は、次の3つのオプションを使用して展開できます。
すべて。有効日と無効日に関係なく、すべてのBOMコンポーネントが展開されます。BOMコンポーネントを展開するには、BOMツリー構造を開きます。
現行。増分抽出ロジックでは、現在有効な変更済のコンポーネント、最終抽出日以降に有効化されたコンポーネント、または最終抽出日以降に無効化されたコンポーネントが対象となります。
現在および将来。現在有効なまたは将来有効になるBOMコンポーネントがすべて展開されます。無効になっているコンポーネントは除外されます。
これらのオプションはEXPLODE_OPTION変数で制御されます。EXPLODE_OPTION変数のデフォルト値は2(現行のBOM構造を展開)です。
SDE_ORA_BOM_Explosionマッピングでは、OPI_OBIA_BOMPEXPL_KPGストアド・プロシージャによってbompexpl.exploder_userexitストアド・プロシージャがコールされ、これによりBOM構造が展開されます。表6-14は、bompexpl.exploder_userexitストアド・プロシージャの変数を表しています。
表6-14 bompexpl.exploder_userexitストアド・プロシージャの変数
| 入力変数 | デフォルト値 | 説明 |
|---|---|---|
|
VERIFY_FLAG |
0 |
値が1の検証フラグは、標準BOMにのみ適用されます。 |
|
ORG_ID |
ORGANIZATION_ID |
組織のID |
|
ORDER_BY |
1 |
レコードの順序を制御します。 1—操作シーケンス番号、項目番号 2—項目番号、操作シーケンス番号 |
|
GRP_ID |
負のシーケンスID(-1、-2など) |
現在の展開を識別するための一意の値 |
|
SESSION_ID |
負のシーケンスID(-1、-2など) |
現在のセッションを識別するための一意の値 |
|
LEVELS_TO_EXPLODE |
10 |
展開する階層レベルの数。 |
|
BOM_OR_ENG |
1 |
1—BOM 2—ENG |
|
IMPL_FLAG |
1 |
1—実装済のみ 2—実装済および未実装 |
|
PLAN_FACTOR |
2 |
1—はい 2—いいえ |
|
EXPLODE_OPTION |
2 |
1—すべて 2—現行 3—現在および将来 |
|
MODULE |
2 |
1—コスト 2—BOM 3—オーダー入力 4—ATO 5—WSM |
|
CST_TYPE_ID |
0 |
費用の展開に使用される費用タイプID |
|
STD_COMP_FLAG |
0 |
1—標準のコンポーネントのみを展開 2—すべてのコンポーネントを展開 |
|
EXPL_QTY |
1 |
展開数 |
|
ITEM_ID |
ROUND(TO_DECIMAL(PRODUCT_ID)) |
展開するアセンブリの項目ID |
|
ALT_DESG |
ALTERNATE_BOM_DESIGNATOR |
代替ルーティング指定子 |
|
COMP_CODE |
NULL |
連結コンポーネント・コード |
|
REV_DATE |
TO_CHAR(CREATION_DT, 'YYYY/MM/DD HH24:MI') |
展開日 YYYY/MM/DD HH24:MI |
ソース・システムには5種類のBOMタイプ(1 - モデル、2 - オプション・クラス、3 - 計画、4 - 標準、5 - 製品系列)があります。デフォルトでは、標準BOMタイプのみが抽出されて展開されます。
BOMの展開オプションをすべてに構成するには:
Informatica PowerCenter Designerで、SDE_ORAVersion_Adaptorを開きます。
Mapplet Designerに移動し、mplt_BC_ORA_BOMHeaderDimensionを開きます。
SQL修飾子「SQ_BOM_INVENTORY_COMPONENTS」をダブルクリックして「Edit Transformations」ダイアログを開き、「Properties」タブを表示して「SQL Query」の値を開きます。
デフォルトでは、WHERE条件は次のように記述されていますが、変更します。
((
/* CURRENT valid component changed */
INV.LAST_UPDATE_DATE > TO_DATE('$$LAST_EXTRACT_DATE','MM/DD/YYYY
HH24:MI:SS') AND (INV.EFFECTIVITY_DATE <= TO_DATE('$$CURRENT_DATE','MM/DD/YYYY
HH24:MI:SS') and (INV.DISABLE_DATE > TO_DATE('$$CURRENT_DATE','MM/DD/YYYY
HH24:MI:SS') OR INV.DISABLE_DATE IS NULL))
OR
/* Component that became effective after last extract date and before
today's extract, for CURRENT Option*/
INV.EFFECTIVITY_DATE between TO_DATE('$$LAST_EXTRACT_DATE','MM/DD/YYYY
HH24:MI:SS') and TO_DATE('$$CURRENT_DATE','MM/DD/YYYY HH24:MI:SS')
OR
/* Component that become disabled after last extract date and before today's
extract, for CURRENT and CURRENT-FUTURE Option*/
INV.DISABLE_DATE between TO_DATE('$$LAST_EXTRACT_DATE','MM/DD/YYYY
HH24:MI:SS') and TO_DATE('$$CURRENT_DATE','MM/DD/YYYY HH24:MI:SS')
)
OR BOM.LAST_UPDATE_DATE > TO_DATE('$$LAST_EXTRACT_DATE','MM/DD/YYYY
HH24:MI:SS'))
GROUP BY
変更後:
(INV.LAST_UPDATE_DATE > TO_DATE('$$LAST_EXTRACT_DATE','MM/DD/YYYY
HH24:MI:SS')
OR BOM.LAST_UPDATE_DATE > TO_DATE('$$LAST_EXTRACT_DATE','MM/DD/YYYY
HH24:MI:SS'))
GROUP BY
「Apply」をクリックしてマッピングを確認し、変更内容をリポジトリに保存します。
DACで、「Design」ビューに移動して、適切なカスタム・コンテナをドロップダウン・リストから選択します。
「Tasks」タブを表示します。
タスクSDE_ORA_BOMItemFactに対して問合せを実行し、「Parameters」サブタブを表示します。
パラメータ「$$EXPLODE_OPTION」を選択して、「Value」フィールドの値を1に変更して保存します。
BOMの展開を「現在および将来」オプションに構成するには:
Informatica PowerCenter Designerで、SDE_ORAVersion_Adaptorを開きます。
Mapplet Designerに移動し、mplt_BC_ORA_BOMHeaderDimensionを開きます。
SQL修飾子「SQ_BOM_INVENTORY_COMPONENTS」をダブルクリックして「Edit Transformations」ダイアログを開き、「Properties」タブを表示して「SQL Query」の値を開きます。
デフォルトでは、WHERE条件は次のように記述されていますが、変更します。
((
/* CURRENT valid component changed */
INV.LAST_UPDATE_DATE > TO_DATE('$$LAST_EXTRACT_DATE','MM/DD/YYYY HH24:MI:SS')
AND (INV.EFFECTIVITY_DATE <= TO_DATE('$$CURRENT_DATE','MM/DD/YYYY HH24:MI:SS')
and (INV.DISABLE_DATE > TO_DATE('$$CURRENT_DATE','MM/DD/YYYY HH24:MI:SS') OR
INV.DISABLE_DATE IS NULL))
OR
/* Component that became effective after last extract date and before today's
extract, for CURRENT Option*/
INV.EFFECTIVITY_DATE between TO_DATE('$$LAST_EXTRACT_DATE','MM/DD/YYYY
HH24:MI:SS') and TO_DATE('$$CURRENT_DATE','MM/DD/YYYY HH24:MI:SS')
OR
/* Component that become disabled after last extract date and before today's
extract, for CURRENT and CURRENT-FUTURE Option*/
INV.DISABLE_DATE between TO_DATE('$$LAST_EXTRACT_DATE','MM/DD/YYYY HH24:MI:SS')
and TO_DATE('$$CURRENT_DATE','MM/DD/YYYY HH24:MI:SS')
)
OR BOM.LAST_UPDATE_DATE > TO_DATE('$$LAST_EXTRACT_DATE','MM/DD/YYYY
HH24:MI:SS'))
GROUP BY
変更後:
((
INV.LAST_UPDATE_DATE > TO_DATE('$$LAST_EXTRACT_DATE','MM/DD/YYYY HH24:MI:SS')
AND ((INV.DISABLE_DATE > TO_DATE('$$CURRENT_DATE','MM/DD/YYYY HH24:MI:SS') OR
INV.DISABLE_DATE IS NULL))
OR
INV.DISABLE_DATE between TO_DATE('$$LAST_EXTRACT_DATE','MM/DD/YYYY HH24:MI:SS')
and TO_DATE('$$CURRENT_DATE','MM/DD/YYYY HH24:MI:SS')
)
OR BOM.LAST_UPDATE_DATE > TO_DATE('$$LAST_EXTRACT_DATE','MM/DD/YYYY
HH24:MI:SS'))
GROUP BY
「Apply」をクリックしてマッピングを確認し、変更内容をリポジトリに保存します。
DACで、「Design」ビューに移動して、適切なカスタム・コンテナをドロップダウン・リストから選択します。
「Tasks」タブを表示します。
タスクSDE_ORA_BOMItemFactに対して問合せを実行し、「Parameters」サブタブを表示します。
パラメータ「$$EXPLODE_OPTION」を選択して、「Value」フィールドの値を3に変更して保存します。
BOMタイプを構成するには:
Informatica PowerCenter Designerで、SDE_ORAVersion_Adaptorを開きます。
mplt_BC_ORA_BOMHeaderDimensionマップレットを開きます。
SQL修飾子「SQ_BOM_INVENTORY_COMPONENTS」をダブルクリックして「Edit Transformations」ダイアログを開き、「Properties」タブを表示して「SQL Query」の値を開きます。
WHERE文のBOM_ITEM_TYPEセクションを変更して、BOMタイプの番号を変更します。たとえば、計画BOMタイプを使用する場合は、次のように番号を3に変更します。
Where INV.BOM_ITEM_TYPE = 3 AND M.BOM_ITEM_TYPE = 3 AND
|
注意: この2つのフィルターを削除すると、すべてのBOMタイプを抽出できます。 |
「Apply」をクリックしてマッピングを確認し、変更内容をリポジトリに保存します。
左限界値および右限界値の計算を使用すると、特定のレポート要件を効率よく処理できます。たとえば、完成品のサブアセンブリに含まれるコンポーネントを検索できます。左限界値と右限界値は、BOMノードごとのW_BOM_ITEM_Fテーブルに格納されます。これらの値は、W_BOM_ITEM_Fテーブル内に左限界値と右限界値のデータの行が1行あります。COMPUTE_BOUNDSストアド・プロシージャによって展開後のBOMツリー構造が探索され、左右の限界値が計算されます。デフォルトでは、COMPUTE_BOUNDSストアド・プロシージャはオフに設定されており、W_BOM_ITEM_F.LEFT_BOUNDSカラムとW_BOM_ITEM_F.RIGHT_BOUNDSカラムは空になっています。
図6-4は、各ノードに左限界値と右限界値が示されたサンプルのBOM構造を示しています。ノードBに属するすべてのコンポーネントを検索するには、上位プロダクト・キー値がA、左限界値が2より大きく、右限界値が17未満に設定されているコンポーネントを選択します。
次の手順を使用すると、左右の限界値の計算をオンにして、W_BOM_ITEM_F.LEFT_BOUNDSカラムおよびW_BOM_ITEM_F.RIGHT_BOUNDSカラムにポピュレートできます。
注意: BOMを使用してETLを実行する前に、Compute_Bounds_Ora11i.sqlのSQLコードをコンパイルしてデプロイする必要があります。詳細は、第6.2.3.11項「左限界値および右限界値の計算オプション用ストアド・プロシージャのデプロイ方法」を参照してください。
左限界値および右限界値の計算オプションを構成するには:
Informatica PowerCenter Designerで、SILOSフォルダに移動してSIL_BOMItemFactマッピングを編集します。
「COMPUTE_BOUNDS」ストアド・プロシージャ変換をダブルクリックして「Edit Transformations」ダイアログを開き、「Properties」タブを表示します。
Call Text属性の値をcompute_bounds_ora11i(1)に変更します。
「Apply」をクリックします。
マッピングを確認し、変更内容をリポジトリに保存します。
