| 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 BI Applicationsに適用される必須および追加の構成タスク、および様々なソース・システム固有の必須および追加のタスクについて説明します。
Oracle BI Applicationsを構成するには、まず、第3.1項「ソースに依存しない構成手順」の手順を実行する必要があります。
|
注意: このガイドで説明する多くの構成タスクでは、ご使用のソース・システム(Oracle E-Business Suiteなど)への問合せを行うことによって取得する値を手動で入力する必要があります。これらの値は、ご使用のソース・システムおよび実装に固有です。これらの値を正しく取得するには、ソース・システムの技術について正しく理解している必要があります。ソース・システムからの値の取得に関して支援が必要な場合、組織内でこの知識を有する人に相談するか、またはソース・システムのOracleサポート・サービス・チームに相談してください。構成エントリを注意深く確認し、ETLプロセス中のデータ損失を回避してください。 |
次に、ソース・システムのタイプに応じて、次のいずれかの項のタスクを実行する必要があります。
この項では、ソース・システムに配置されているOracle BI Applicationsに適用される構成手順について説明します。内容は次のとおりです。
初期の抽出日付は、完全ロードのためにデータを抽出するときに必要です。これは、初期ロードのデータ量を減らします。指定された初期の抽出日付は、選択された完全抽出マッピングのトランザクション・データの作成日に関してフィルタとして使用されます。デフォルトの日付は1970年1月1日です。
初期の抽出日付のパラメータを設定する場合、会計期間の中間の日付に設定するのではなく、会計期間の初日に設定してください。たとえば、2005年6月からデータを抽出することに決め、2005年6月の会計期間が6月5日に始まる場合、初期の抽出日付を2005年6月5日に設定します。
初期の抽出日付を構成するには:
DACで、「Design」ビューに移動して、適切なカスタム・コンテナをドロップダウン・リストから選択します。
「Source System Parameters」タブを表示します。
$$INITIAL_EXTRACT_DATEパラメータの値を編集します。
変更を保存します。
ビジネス上の取引では、複数の通貨が関係する場合があるため、通貨の変換が必要です。有効なレポートを作成するには、共通の通貨を使用する必要があります。Oracle Business Analytics Warehouseでは、次の通貨で金額が保存されます。
ドキュメント通貨。ドキュメント通貨は、トランザクションの通貨です。たとえば、メキシコのサプライヤから椅子を購入した場合、ドキュメント通貨はメキシコのペソになる可能性があります。また、イギリスに出張して、現地での食事の経費レポートを提出した場合、経費レポートのドキュメント通貨はイギリスのポンドになる可能性があります。
ローカル通貨。ローカル通貨は、元帳の基本通貨、または会計仕訳エントリを記録する通貨です。
グローバル通貨。Oracle BI Applicationsは、Oracle Business Analytics Warehouseで使用される共通通貨である3つのグローバル通貨を提供します。たとえば、組織が米国に本社がある多国籍企業の場合、3つのグローバル通貨の1つとして米国ドル(USD)を選択するでしょう。
グローバル通貨は、全社的なレポートを作成するときに便利です。たとえば、他の通貨で全社的なデータを表示する必要がある場合があります。ソースから抽出されるあらゆる金額に対して、ロード・マッピングは、ドキュメント通貨の金額およびローカル通貨の金額をターゲット・テーブルにロードします。ドキュメント通貨の金額を3つのグローバル通貨それぞれに変換するために必要な為替レートもロードします。要素テーブルの場合、ローカル通貨の金額およびドキュメント通貨の金額を表示する2つの金額カラムがあります。また、グローバル通貨(たとえばglobal _amount1)および対応する為替レートのカラムを表示する3つのカラムがあります。
ほとんどの場合、ソース・システムがドキュメント通貨の金額を提供します。これは、最も一般的な状況です。したがって、これが通貨の処理に関するOracle Business Analytics Warehouseのデフォルトになっています。ソース・システムがドキュメント通貨の金額しか提供しない場合、ソース・アダプタは参照を実行し、適切な通貨が割り当てられたソース・システムに基づいて、ローカル通貨コードを特定します。参照を実行した後、抽出マッピングは、ドキュメント通貨の金額、ドキュメント通貨コードおよびローカル通貨コードを含むロード・マッピングを提供します。次に、ロード・マッピングは、提供されたローカル通貨コードを使用し、通貨変換を実行してローカル通貨での金額を導き出します。ロード・マッピングは、DACパラメータから設定されたグローバル通貨のフェッチ、および3つのグローバル通貨それぞれに対応する為替レートの参照も行います。
レポートするグローバル通貨を構成するには:
DACで、「Design」ビューに移動して、適切なカスタム・コンテナをドロップダウン・リストから選択します。
「Source System Parameters」タブを表示します。
次のパラメータを探して、「Value」フィールドに通貨コードを設定します。
$$GLOBAL1_CURR_CODE(最初のグローバル通貨用)。
$$GLOBAL2_CURR_CODE(2番目のグローバル通貨用)。
$$GLOBAL3_CURR_CODE(3番目のグローバル通貨用)。
ローカル通貨に変換するための為替レートが指定されているかぎり、任意の通貨を指定できます。通貨のスペルは、ソースOLTPシステムと同じにしてください。
変更を保存します。
Oracle BI Applicationsで取引レコードの金額をドキュメント通貨からグローバル通貨に変換する場合、変換の実行に使用する為替レートの各タイプの指定も必要になります。Oracle BI Applicationsでは、各グローバル通貨について、変換の実行に使用する為替レートのタイプも指定できます。また、ユーザーが構成可能な3つのグローバル為替レートのタイプも提供されています。
Oracle BI Applicationsでは、取引レコードの金額をドキュメント通貨からローカル通貨に変換することもできます。ローカル通貨とは、会計仕訳エントリと会計レポートを記録する基本通貨です。この変換を実行するために、Oracle BI Applicationsでは、ドキュメント通貨からローカル通貨への変換に使用するレート・タイプを構成することもできます。
為替レートのタイプを構成するには:
DACで、「Design」ビューに移動して、適切なカスタム・コンテナをドロップダウン・リストから選択します。
「Source System Parameters」タブを表示します。
次のDACパラメータを探して、「Value」フィールドに為替レートのタイプを設定します。
$$GLOBAL1_RATE_TYPE
$$GLOBAL2_RATE_TYPE
$$GLOBAL3_RATE_TYPE
$$DEFAULT_LOC_RATE_TYPE(ドキュメント通貨からローカル通貨への変換用の為替レートのタイプ)
為替レートのタイプ値のスペルは、ソースOLTPシステムと同じにしてください。
変更を保存します。
この項では、Oracle Business Intelligence Applicationsでサポートされている様々なタイプのカレンダーを設定する方法について説明します。この項の内容は次のとおりです。
Oracle Business Intelligence Applicationsリリース7.9.6.3は、次のカレンダー形式をサポートします。
企業(グローバル): 部門間レポート・カレンダー(会計またはグレゴリオ)。
会計: 経理カレンダーまたは会計カレンダー。
グレゴリオ: 1月1日から始まり12月31日に終わる通常のカレンダー。
13周期: 各年が28日の13周期で構成されます。
4-4-5: 各年が28日の4週間または35日の5週間のいずれかの12周期で構成されます。
複数のカレンダーをデプロイする場合は(Oracle Financial Analyticsなど)、次の初期化ブロックを有効にしておく必要があります。
EBSシングル・サインオン統合
EBSセキュリティ・コンテキスト
元帳
営業単位組織
これらの初期化ブロックはデフォルトでは有効になっていません。これらの初期化ブロックを有効にせずにデータをロードしようとすると、ダッシュボードにはデータが移入されず、BI Serverのログには初期化ブロック・エラーが示されることがあります(例: nQSError:43059)。
複数のカレンダーに対して初期化ブロックを有効にするには:
管理ツールを使用して、OracleBIAnalyticsApps.rpdを開きます。
OracleBIAnalyticsApps.rpdファイルは次の場所にあります。
ORACLE_INSTANCE\bifoundation\OracleBIServerComponent\coreapplication_ obisn\repository
「管理」→「変数」を選択して、「変数マネージャ」を表示します。
左側のペインで、「セッション」→「初期化ブロック」を選択します。
この項でリストした初期化ブロックのそれぞれについて、右側のペインで初期化ブロック名をクリックし、「有効化」を選択します。
Oracle BIサーバーを再起動します。
この項では、時間次元カレンダー(グレゴリオ・カレンダー、会計カレンダー、企業カレンダーなど)に使用するテーブルについて説明します。
グレゴリオ・カレンダー・テーブル
W_WEEK_D
W_MONTH_D
W_QTR_D
W_YEAR_D
W_DAY_D
会計カレンダー・テーブル
W_MCAL_DAY_D
W_MCAL_WEEK_D
W_MCAL_PERIOD_D
W_MCAL_QTR_D
W_MCAL_YEAR_D
企業カレンダー・テーブル
W_ENT_WEEK_D
W_ENT_PERIOD_D
W_ENT_QTR_D
W_ENT_YEAR_D
表3-1は、時間次元構成およびコンテキスト・テーブルを示しています。
図3-1 時間次元構成およびコンテキスト・テーブル
| 構成テーブル | PeopleSoft固有の構成テーブル | コンテキスト・テーブル |
|---|---|---|
|
W_MCAL_CONFIG_G |
W_MCAL_PSFT_SUMP_CONFIG_G |
W_MCAL_CONTEXT_G |
構成テーブルおよびコンテキスト・テーブルの詳細は、第3.1.4.2項「カレンダーの構成について」を参照してください。
注意: 次のテーブルは、Oracle Business Intelligence Applicationsリリース7.9.6以降では廃止されました。
W_FSCL_WEEK_D
W_FSCL_MONTH_D
W_FSCL_QTR_D
W_FSCL_YEAR_D
前述のリストに記載したテーブルは、以前のリリースではCSVファイルを介して移入されていました。これらのテーブルのデータを新しい会計カレンダー・テーブルに移行する必要がある場合、アップグレード・ドキュメントを参照してください。
この項では、様々なタイプのサポートされるカレンダーの構成方法を説明します。
デプロイするカレンダーのタイプに関係なく、グレゴリオ暦の開始日と終了日の範囲を設定する必要があります。詳細は、第3.1.4.4項「グレゴリオ暦の日付範囲の設定方法」を参照してください。
Oracle Business Analytics Warehouseの時間次元を表す基本テーブルはW_DAY_Dです。このテーブルは、複数の会計カレンダー・テーブルの前提条件としてポピュレートされる必要があります。W_DAY_Dをポピュレートしないと、会計カレンダー・テーブルはポピュレートされません。
タスクSIL_DayDimensionには、W_DAY_Dのカレンダー・データのロード時に設定が必要なパラメータが2つ($$START_DATEと$$END_DATE)あります。SILマッピングでは、標準的な時間関数を使用して、これらの2つのパラメータで定義されている日付範囲内にあるカレンダー日ごとのレコードが作成されます。W_DAY_Dにレコードが作成されると、集計カレンダー・テーブルは、それぞれのSILマッピングによってロードされます。次に会計カレンダー・テーブル(MCALテーブルと呼ばれる)がポピュレートされます。
注意: パラメータ$$START_DATEと$$END_DATEには、ウェアハウスに持ち込まれるすべての会計カレンダーに含まれるすべての日付が含まれる必要があります。これらのパラメータは、日付次元と関連テーブルの境界です。
企業カレンダー(またはレポート・カレンダー)は、サブジェクトエリア間で分析ができます。企業カレンダー・テーブルには接頭辞W_ENTがあります。
企業カレンダーは、OLTPソース会計カレンダーの1つ、またはウェアハウス生成カレンダーの1つに設定できます。これは、次のソース・システム・パラメータをDACコンテナ・レベルで設定することによって実行できます。
$$GBL_CALENDAR_ID
$$GBL_DATSOURCE_NUM_ID
次の項では、次のような様々なシナリオで企業カレンダーのソース・システム・パラメータを設定する方法を示します。
シナリオ1: Oracle EBS会計カレンダーを企業カレンダーとして使用
Oracle EBS企業カレンダーのソース・システムDACパラメータ:
GBL_CALENDAR_ID: このパラメータは、企業カレンダーを選択するために使用されます。これは、非生成カレンダーのMCAL_CAL_NAME~MCAL_PERIOD_TYPEです。たとえば、企業カレンダーのid='Accounting'でカレンダーのperiod_type='41'の場合、GBL_CALENDAR_IDは'Accounting~41'になります。
GBL_DATASOURCE_NUM_ID: 企業カレンダーが生成カレンダーでない場合、カレンダーの定義が取得されたソース・システムのDATASOURCE_NUM_IDです。たとえば、PeopleSoftとOracleの2つのデータ・ソースがあり、グローバル・カレンダーがOracleデータ・ソースから取得される場合、このパラメータ値はOracleデータ・ソースを指定します。
シナリオ2: PeopleSoft会計カレンダーを企業カレンダーとして使用
PeopleSoft企業カレンダーのソース・システムDACパラメータ:
GBL_CALENDAR_ID: このパラメータは、企業カレンダーを選択するために使用されます。これは、非生成カレンダーのSETID~CALENDAR_IDです。たとえば、企業カレンダーのid='01'でSETID='SHARE'の場合、GBL_CALENDAR_IDは'SHARE~01'になります。
GBL_DATASOURCE_NUM_ID: グローバル・カレンダーが生成カレンダーでない場合、カレンダーの定義が取得されたソース・システムのDATASOURCE_NUM_IDです。たとえば、PeopleSoftとOracleの2つのデータ・ソースがあり、グローバル・カレンダーがOracleソースから取得される場合、このパラメータ値はOracleデータ・ソースを指定します。
シナリオ3: ウェアハウス生成カレンダーを企業カレンダーとして使用
生成される企業カレンダーのソース・システムDACパラメータ:
GBL_CALENDAR_ID: このパラメータは、生成カレンダー(4-4-5カレンダーまたは13周期カレンダー)のCALENDAR_IDです。デフォルトでは、4-4-5カレンダーには'10000'のCALENDAR_IDがあり、13周期カレンダーには'10001'のCALENDAR_IDがあります。
GBL_DATASOURCE_NUM_ID: グローバル・カレンダーが生成カレンダーの場合、OLAP(データ・ウェアハウス)のDATASOURCE_NUM_ID値です。
シナリオ4: 汎用アダプタを使用してロードした会計カレンダーを企業カレンダーとして使用
汎用企業カレンダーのソース・システムDACパラメータ:
GBL_CALENDAR_ID: このパラメータは、グローバル・カレンダーとして定義された特定のカレンダーのfile_mcal_cal_d.csvファイルのINTEGRATION_IDです。
GBL_DATASOURCE_NUM_ID: グローバル・カレンダーが生成カレンダーでない場合、カレンダーの定義が取得されたソース・システムのDATASOURCE_NUM_IDです。これがfile_mcal_period_ds.csvファイルで定義されている場合、その値が取得されます。それ以外の場合、汎用アダプタのDACで定義されているように取得されます。
シナリオ5: Oracle JD Edwards EnterpriseOne会計カレンダーを企業カレンダーとして使用
企業カレンダーを構成するOracle JD Edwards EnterpriseOneのソース・システムDACパラメータ:
GBL_CALENDAR_ID: このパラメータは、企業カレンダーを選択するために使用されます。これは、MCAL_CAL_IDです。たとえば、企業カレンダーのid='R'の場合、GBL_CALENDAR_IDは'R'になります。
GBL_DATASOURCE_NUM_ID: 企業カレンダーが生成カレンダーでない場合、この値は、カレンダーの定義が取得されたソース・システムのDATASOURCE_NUM_IDです。たとえば、OracleとOracle JD Edwards EnterpriseOneの2つのデータ・ソースがあり、グローバル・カレンダーがOracle JD Edwards EnterpriseOneデータ・ソースから取得される場合、このパラメータ値はOracle JD Edwards EnterpriseOneデータ・ソースを指定します。
シナリオ6: Oracle JD Edwards World会計カレンダーを企業カレンダーとして使用
OracleのJD Edwards Worldでは、企業カレンダーは、世界カレンダーと呼ばれます。
世界カレンダーを構成するOracle JD Edwards Worldのソース・システムDACパラメータ:
GBL_CALENDAR_ID: このパラメータは、世界カレンダーを選択するために使用されます。これは、MCAL_CAL_IDです。たとえば、世界カレンダーのid='R'の場合、GBL_CALENDAR_IDは'R'になります。
GBL_DATASOURCE_NUM_ID: 世界カレンダーが生成カレンダーでない場合、この値は、カレンダーの定義が取得されたソース・システムのDATASOURCE_NUM_IDです。たとえば、OracleとOracle JD Edwards Worldの2つのデータ・ソースがあり、グローバル・カレンダーがOracle JD Edwards Worldデータ・ソースから取得される場合、このパラメータ値はOracle JD Edwards Worldデータ・ソースを指定します。
Oracle Business Intelligence Applicationsリリース7.9.6.3は、次のタイプの生成カレンダーをサポートします。
13周期カレンダー
4-4-5カレンダー(およびこの変種)
このテーブルは、Oracle Financial AnalyticsおよびOracle Project Analyticsの要素によって使用され、指定の元帳またはOU(営業単位)のカレンダーIDを参照します。これは、要素テーブルに対してポピュレートされ、正しくロードされる必要があります(DACのデフォルトの実行プランがこれを行います)。
Oracle EBSでは、プロジェクト・カレンダーおよび組織(OU)の関係は、PA_IMPLEMENTATIONS_ALLからW_MCAL_CONTEXT_Gに取得されます。プロジェクト・カレンダーは、カラムPA_IMPLEMTATIONS_ALL.PERIOD_SET_NAMEから取得されます。プロジェクト分析で使用される総勘定元帳カレンダーは、カラムPA_IMPLENTATIONS_ALL.SET_OF_BOOKS_IDから取得されます。
カレンダーを設定するとき、次のことに注意してください。
W_MCAL_CONFIG_Gテーブルは、生成カレンダーが作成される方法を制御します。
4-4-5カレンダーまたは13周期カレンダーを生成する場合、W_MCAL_CONFIG_Gには、4-4-5周期または13周期用に最低1つの行がある必要があります。Oracle EBSまたはPeopleSoftのソース・カレンダー用では、このテーブルにエントリは不要です。
注意: OracleのJD Edwards EnterpriseOneおよびJD Edwards WorldのFinancial Analytics用のアダプタは、4-4-5周期カレンダーをサポートしません。
W_MCAL_WEEK_Dは、生成カレンダー(13周期カレンダー、4-4-5カレンダーなど)に対してのみポピュレートされます。したがって、W_DAY_D週の企業カラムは、非生成カレンダー(OLTPソース会計カレンダーと呼ばれる)に対してはNULLです。非生成カレンダーが企業カレンダーとして選択された場合、W_ENT_WEEK_Dはポピュレートされません。
13周期カレンダーの場合、四半期の概念はありません。したがって、W_MCAL_WEEK_D、W_MCAL_PERIOD_D、W_MCAL_YEAR_Dのすべての四半期カラムはNULLになります。13周期カレンダーが企業カレンダーとして選択された場合、W_ENT_QTR_Dはポピュレートされません。
表3-2 に、file_mcal_config_g.csvからロードされるW_MCAL_CONFIG_Gテーブルのカラムの概要を示します。
表3-2 構成テーブルW_MCAL_CONFIG_Gのカラム
| カラム名 | カラムの説明 |
|---|---|
|
CALENDAR_ID |
構成されるカレンダーのID。これは、このテーブルの主キーです。 |
|
CALENDAR_NAME |
構成されるカレンダーの名前。 |
|
CALENDAR_CLASS |
自動的に生成されます。 |
|
PERIOD_TYPE |
構成されるカレンダー周期のタイプ(4-4-5など)。 |
|
CAL_ST_DT |
カレンダー生成が開始される日付。 |
|
CAL_END_DT |
カレンダー生成が終了する日付。 |
|
CAL_OFFSET |
カレンダーの開始日を特定するオフセット。有効な開始日およびオフセット値は次のとおりです。
|
|
WEEK_ALLOCATION_RULE |
このパラメータは、構成されるカレンダーで週を割り当てる方法を決定します。4-4-5、5-4-4、4-5-4、13周期などです。 |
|
REFERENCE_DATE |
会計年度が始まる日付(MMDD形式)。たとえば、組織の会計年度が10月から9月の場合、reference_date値は0929になります。 前の会計年度は、REFERENCE_DATEで指定した日付の3日前から3日後の間(つまり、(REFERENCE_DATE - 3)から(REFERENCE_DATE + 3)の範囲内)に終了する必要があります。つまり、REFERENCE_DATEが0131(1月31日)の場合、前の会計年度を2月3日よりも後にはできません。 |
|
他の標準カラム |
W_INSERT_DT、W_UPDATE_DT、TENANT_ID、X_CUSTOMなど。 |
次のテーブルは、生成カレンダーに必要なタスク・レベルDACパラメータの概要について示しています。
図3-3 生成カレンダーに必要なタスク・レベルDACパラメータ
| DACパラメータ名 | DACパラメータの説明 |
|---|---|
|
$$13P_CALENDAR_ID |
タスク: SIL_TimeDimension_MCalWeek13Period。データ・ウェアハウスに13周期タイプのカレンダーをポピュレートする場合に必要です。この値は、13周期タイプのカレンダーのW_MCAL_CONFIG_Gテーブルで定義されたCALENDAR_IDです。 |
|
$$445P_CALENDAR_ID |
タスク: SIL_TimeDimension_MCalWeek445。データ・ウェアハウスに445周期タイプのカレンダーをポピュレートする場合に必要です。この値は、445周期タイプのカレンダーのW_MCAL_CONFIG_Gテーブルで定義されたCALENDAR_IDです。 |
2つのカレンダー年にまたがる週(日曜日で始まり土曜日で終わる)がある場合、その週は両方の年でカウントされます。たとえば、2007年12月30日で始まる週は、2007年と2008年の両方でカウントされます。2007年では、週の開始日が2007年12月30日で、終了日が2007年12月31日になります。2008年では、第1週になり、開始日が2008年1月1日で、終了日が2008年1月5日になります。
W_DAY_Dは、1か月の日数が31日であるかどうかに関係なく、月ごとに31件のレコードを格納します。月の日数が31日よりも少ない場合、カレンダー日付と日付のカラムにNULL値を持つレコードが作成されます。これらの追加レコードは、Oracle BIリポジトリの前期間指標の計算時にロードされ、ETLやレポートには影響を与えません。
W_DAY_Dテーブルには、Oracle BIリポジトリの物理レイヤーにマップされない属性がいくつかあります。そのため、このリポジトリで新しい属性を作成する前に、その属性がすでに物理レイヤーで使用可能になっているか、また直接マップできるかどうかを確認してください。
会計カレンダーが12か月を超えている場合、余分な月には会計四半期に0の値が割り当てられます。会計三半期と会計半期についても同じ値が割り当てられます。
デフォルトでは、Oracle BI Applicationsは、最大65536行生成できます。65536行よりも多くの行を必要とする場合、次の手順を実行して、容量を262144行(718年)に増やすことができます。
'SIL_DayDimension_GenerateRows7'を複製します。
これを'SIL_DayDimension_GenerateRows8'に名前を変更します。
これを'SIL_DayDimension_GenerateRows7'の直後に実行します。
このタスクは、すべてのタイプのカレンダーの前提条件です。このタスクは、標準グレゴリオ暦を日付次元テーブルW_DAY_Dにロードします。
グレゴリオ暦を設定するには:
DACで、「Design」ビューに移動して、適切なカスタム・コンテナをドロップダウン・リストから選択します。
「Tasks」タブを表示します。
タスクSIL_DayDimensionに対するクエリーを実行します。
下部のペインに「Parameters」タブを表示します。
$$START_DATEと$$END_DATEのパラメータを使用して、生成するカレンダーの日付範囲を指定します。
注意: 日付次元をロードするタスクは、サブジェクトエリアの実行プランの一部として実行されます。共通の次元に個別のサブジェクトエリアはありません。これらは、コア・サブジェクトエリアに含まれています。
この構成手順は、PeopleSoft会計カレンダーをロードする前にのみ実行する必要があります。PeopleSoftでは、サマリー・カレンダーは、詳細カレンダーに基づいています。多くのサマリー・カレンダーは、単一の詳細カレンダーに基づかない可能性があります。file_summary_calendar.csv構成ファイルでは、PeopleSoft詳細会計期間の会計四半期および会計年度を決定するためにサマリー・カレンダーの関連付けを使用できます。詳細カレンダーそれぞれについて、ファイルfile_summary_calendar.csvにサマリーCALENDAR_IDおよびサマリーSETIDを入力します。このファイルのカラムは、表3-4にリストされています。
表3-4 file_summary_calendar.csv構成ファイルのフィールド
| カラム名 | カラムのタイプ | カラムの説明 |
|---|---|---|
|
DETAIL_CALENDAR_SETID |
VARCHAR2(5) |
構成される詳細カレンダーのSETID。 |
|
DETAIL_CALENDAR_ID |
VARCHAR2(15) |
構成される詳細カレンダーのCALENDAR_ID。 |
|
SUMMARY_CALENDAR_SETID_QTR |
VARCHAR2(5) |
指定される四半期サマリー・カレンダーのSETID。 |
|
SUMMARY_CALENDAR_QTR |
VARCHAR2(15) |
指定される四半期サマリー・カレンダーのCALENDAR_ID。 |
|
SUMMARY_CALENDAR_SETID_YEAR |
VARCHAR2(5) |
指定される年サマリー・カレンダーのSETID。 |
|
SUMMARY_CALENDAR_YEAR |
VARCHAR2(15) |
指定される四半期カレンダーのCALENDAR_ID。 |
|
SUMMARY_CALENDAR_SETID_MONTH |
VARCHAR2(5) |
指定される月サマリー・カレンダーのSETID。 |
|
SUMMARY_CALENDAR_MONTH |
VARCHAR2(15) |
指定される月カレンダーのCALENDAR_ID。 |
|
SUMMARY_CALENDAR_SETID_HALF |
VARCHAR2(5) |
指定される半年サマリー・カレンダーのSETID。 |
|
SUMMARY_CALENDAR_HALF |
VARCHAR2(15) |
指定される半年カレンダーのCALENDAR_ID。 |
|
他の標準カラム |
なし |
W_INSERT_DT、W_UPDATE_DT、TENANT_ID、X_CUSTOMなど。 |
カレンダーは、People SoftのSETIDとCALENDAR_IDによって定義されるため、特定の詳細カレンダーには、関連するサマリー・カレンダーのSETIDおよびCALENDAR_IDが追加されます。このフラット・ファイルfile_summary_calendar.csvを更新した後、ETLプロセスを実行します。このフラット・ファイルは、テーブルW_MCAL_PSFT_SUMP_CONFIG_Gをロードします。これは、W_MCAL_PERIOD_Dをロードしその詳細期間の四半期の数を解決するマッピングで使用されます。指定されるサマリー・カレンダーがその詳細期間に含まれる日付範囲を網羅することを確認する必要があります。そうでない場合、W_MCAL_PERIOD_DのMCAL_QTRカラムはNULLになります。
次のイメージは、file_summary_calendar.csvファイルの値の例を示しています。
DACで、「Design」ビューに移動して、適切なカスタム・コンテナをドロップダウン・リストから選択します。
「Source System Parameters」タブを表示します。
次のように、$$GBL_CALENDAR_IDと$$GBL_DATSOURCE_NUM_IDの値を設定します。
$$GBL_CALENDAR_ID: このパラメータは、企業カレンダーを選択するために使用されます。次のEBSソースのクエリーを使用して、このパラメータに使用できる値を識別します。
SELECT period_set_name || '~'|| period_type FROM gl_periods;
このクエリーは、$$GBL_CALENDAR_IDパラメータに選択できるリストを返します。企業カレンダーを選択するには、返される値のいずれかを$$GBL_CALENDAR_IDの値として使用します。パラメータ$$GBL_CALENDAR_IDの形式は、PERIOD_SET_NAMEとPERIOD_TYPEの連結名です。
$$GBL_DATASOURCE_NUM_ID: このパラメータは、EBSカレンダーのロードに使用したdata_source_num_idです。
|
注意: 企業カレンダーをロードするタスクは、サブジェクトエリアの実行プランの一部として実行されます。共通の次元に個別のサブジェクトエリアはありません。これらは、コア・サブジェクトエリアに含まれています。 |
DACで、「Design」ビューに移動して、適切なカスタム・コンテナをドロップダウン・リストから選択します。
「Source System Parameters」タブを表示します。
次のように、$$GBL_CALENDAR_IDと$$GBL_DATSOURCE_NUM_IDの値を設定します。
$$GBL_CALENDAR_ID: このパラメータは、企業カレンダーを選択するために使用されます。次のPeopleSoftソースのクエリーを使用して、このパラメータに使用できる値を識別します。
SELECT SETID|| '~'|| CALENDAR_ID FROM PS_CAL_DEFN_TBL;
このクエリーは、$$GBL_CALENDAR_IDパラメータに選択できるリストを返します。企業カレンダーを選択するには、返される値のいずれかを$$GBL_CALENDAR_IDの値として使用します。パラメータ$$GBL_CALENDAR_IDの形式は、SETIDとCALENDAR_IDの連結名です。
$$GBL_DATASOURCE_NUM_ID: このパラメータは、PeopleSoftカレンダーのロードに使用したdata_source_num_idです。
|
注意: 企業カレンダーをロードするタスクは、サブジェクトエリアの実行プランの一部として実行されます。共通の次元に個別のサブジェクトエリアはありません。これらは、コア・サブジェクトエリアに含まれています。 |
DACで、「Design」ビューに移動して、適切なカスタム・コンテナをドロップダウン・リストから選択します。
「Source System Parameters」タブを表示します。
次のように、$$GBL_CALENDAR_IDと$$GBL_DATSOURCE_NUM_IDの値を設定します。
$$GBL_CALENDAR_ID: このパラメータは、企業カレンダーを選択するために使用されます。次のOracle JD Edwards EnterpriseOneソースのクエリーを使用して、このパラメータに使用できる値を識別します。
SELECT DISTINCT CDDTPN FROM F0008
このクエリーは、$$GBL_CALENDAR_IDパラメータに選択できるリストを返します。企業カレンダーを選択するには、返される値のいずれかを$$GBL_CALENDAR_IDの値として使用します。デフォルト構成では、デフォルトのカレンダーは「R」です。
$$GBL_DATASOURCE_NUM_ID: このパラメータは、Oracle JD Edwardsカレンダーのロードに使用したdata_source_num_idです。
|
注意: 企業カレンダーをロードするタスクは、サブジェクトエリアの実行プランの一部として実行されます。共通の次元に個別のサブジェクトエリアはありません。これらは、コア・サブジェクトエリアに含まれています。 |
DACで、「Design」ビューに移動して、適切なカスタム・コンテナをドロップダウン・リストから選択します。
「Source System Parameters」タブを表示します。
次のように、$$GBL_CALENDAR_IDと$$GBL_DATSOURCE_NUM_IDの値を設定します。
$$GBL_CALENDAR_ID: このパラメータは、企業カレンダーを選択するために使用されます。次のOracle JD Edwards Worldソースのクエリーを使用して、このパラメータに使用できる値を識別します。
SELECT DISTINCT CDDTPN FROM F0008
このクエリーは、$$GBL_CALENDAR_IDパラメータに選択できるリストを返します。企業カレンダーを選択するには、返される値のいずれかを$$GBL_CALENDAR_IDの値として使用します。デフォルト構成では、デフォルトのカレンダーは「R」です。
$$GBL_DATASOURCE_NUM_ID: このパラメータは、Oracle JD Edwardsカレンダーのロードに使用したdata_source_num_idです。
|
注意: 企業カレンダーをロードするタスクは、サブジェクトエリアの実行プランの一部として実行されます。共通の次元に個別のサブジェクトエリアはありません。これらは、コア・サブジェクトエリアに含まれています。 |
DACで、「Design」ビューに移動して、適切なカスタム・コンテナをドロップダウン・リストから選択します。
「Source System Parameters」タブを表示します。
次のように、$$GBL_CALENDAR_IDと$$GBL_DATSOURCE_NUM_IDの値を設定します。
GBL_CALENDAR_ID: 生成カレンダー(4-4-5カレンダーまたは13周期カレンダー)のCALENDAR_IDです。デフォルトでは、4-4-5カレンダーには10000のCALENDAR_IDがあり、13周期カレンダーには10001のCALENDAR_IDがあります。
GBL_DATASOURCE_NUM_ID: グローバル・カレンダーが生成カレンダーの場合、OLAP(データ・ウェアハウス)のDATASOURCE_NUM_ID値です。
テキスト・エディタを使用して、file_mcal_config_g.csvの値を編集します。
DACでは、13P_CALENDAR_IDの値を10001に設定します。
注意: タスクSIL_TimeDImension_McalWeek13Periodは、サブジェクトエリアの実行プランの一部として実行されます。共通の次元に個別のサブジェクトエリアはありません。これらは、コア・サブジェクトエリアに含まれています。
DACで、「Design」ビューに移動して、適切なカスタム・コンテナをドロップダウン・リストから選択します。
「Source System Parameters」タブを表示します。
次のように、$$GBL_CALENDAR_IDと$$GBL_DATSOURCE_NUM_IDの値を設定します。
GBL_CALENDAR_ID: 生成カレンダー(4-4-5カレンダーまたは13周期カレンダー)のCALENDAR_IDです。デフォルトでは、4-4-5カレンダーには10000のCALENDAR_IDがあり、13周期カレンダーには10001のCALENDAR_IDがあります。
GBL_DATASOURCE_NUM_ID: グローバル・カレンダーが生成カレンダーの場合、OLAP(データ・ウェアハウス)のDATASOURCE_NUM_ID値です。
テキスト・エディタを使用して、file_mcal_config_g.csvの値を編集します。
DACでは、445P_CALENDAR_IDの値を10000に設定します。
注意: タスクSIL_TimeDimension_McalWeek445は、サブジェクトエリアの実行プランの一部として実行されます。共通の次元に個別のサブジェクトエリアはありません。これらは、コア・サブジェクトエリアに含まれています。
DACで、「Design」ビューに移動して、適切なカスタム・コンテナをドロップダウン・リストから選択します。
「Source System Parameters」タブを表示します。
次のように、$$GBL_CALENDAR_IDと$$GBL_DATSOURCE_NUM_IDの値を設定します。
GBL_CALENDAR_ID: グローバル・カレンダーとして定義された特定のカレンダーのfile_mcal_cal_d.csvファイルのINTEGRATION_IDです。
GBL_DATASOURCE_NUM_ID: グローバル・カレンダーが生成カレンダーでない場合、カレンダーの定義が取得されたソース・システムのDATASOURCE_NUM_IDです。これがfile_mcal_period_ds.csvファイルで定義されている場合、その値が取得され、それ以外の場合、汎用アダプタのDACで定義された値が取得されます。
テキスト・エディタを使用して、w_mcal_config_g.csvファイルの値を編集します。
テキスト・エディタを使用して、w_mcal_config_d.csvファイルの値を編集します。
Oracle Financial AnalyticsおよびOracle Project Analyticsを使用して指定の元帳OUのカレンダーIDを参照している場合、テキスト・エディタを使用して、w_mcal_context_g.csvファイルの値を編集します。
(必要に応じて)テキスト・エディタを使用して、w_mcal_period_ds.csvファイルの値を編集します。
DACで、GBL_CALENDAR_IDおよびGBL_DATASOURCE_NUM_IDの値を設定します(シナリオ4を参照)。
複数カレンダーのサポートを含み、PeopleSoftソース・システムから会計カレンダーを取得している実行プランを実行する前にこのタスクを完了する必要があります。
PeopleSoftサマリー・カレンダーを使用するには:
テキスト・エディタを使用して、summary_calendar.csvの値を編集します。
サブジェクトエリアの実行プランを実行します。
この実行プランには、PeopleSoftサマリー・カレンダーの構成テーブルをロードするタスクが自動的に含まれます。
汎用アダプタは、PeopleSoft、Oracle EBSまたはOracle JD Edwards以外のソースからデータを複数のカレンダー・テーブルに取得できるように用意されています。これらのソースからのデータは、次のCSVファイルを使用して取得する必要があります。
file_mcal_config_g.csv: W_MCAL_CONFIG_Gをロードします。
file_mcal_context_g.csv: W_MCAL_CONTEXT_Gをロードします。
file_mcal_cal_d.csv: W_MCAL_CAL_Dをロードします。
file_mcal_period_ds.csv: W_MCAL_PERIOD_DS(ステージング・テーブル)をロードします。
この項では、汎用アダプタ構成ファイルの構成設定例を説明します。この項の内容は次のとおりです。
file_mcal_cal_d.csv設定の例
注意:
主キーはROW_WIDで、一意である必要があります。
file_mcal_config_g.csv設定の例
注意:
すべてのアダプタの生成カレンダーに使用されます。
生成カレンダーのCALENDAR_ID値は、DACタスク・レベル・パラメータで使用されます。
DATEカラムの形式は、YYYYMMDDHHMMSS(たとえば、2000年2月2日の場合、20000202000000)です。
13周期タイプの生成カレンダーのCALENDAR_NAMEは、'13'または'13 Period'です。
REFERENCE_DATEの形式は、MMDD(たとえば、1月31日の場合、0131)です。
file_mcal_context_g.csv設定の例
注意:
DATEカラムの形式は、YYYYMMDDHHMMSS(たとえば、20000202000000)です。
file_file_mcal_period_ds.csv設定の例
注意:
DATEカラムの形式は、YYYYMMDDHHMMSS(たとえば、20000202000000)です。
時間次元テーブルのデータは、ウェアハウスの初期完全ロード時に1回ロードされます。続いて、SIL_%_UpdateFlagマッピングが、各増分実行時に実行され、ドメイン値コードを更新します。これは、日、週、月、四半期または年が現在の日付の時点において、現行、次または前のいずれかを指定します。W_MCAL_%テーブル(複数カレンダーのサポートのテーブル)をポピュレートするために実行する他の増分タスクもあります。データを時間次元テーブルにロードする日付の範囲は、パラメータ$$START_DATEと$$END_DATEによって決まります。
$$END_DATE到来前に時間次元テーブルのデータを拡張することをお薦めします。$$END_DATE到来前に拡張しないと、My Oracle Supportのテクニカル・ノート1063484に記載されているように障害が発生します。
7963では、DACの各コンテナに実行プランが提供されており、必要時に日付次元を拡張します。この実行プランには、すべての時間次元関連タスクが含まれており、W_DAY_Dの完全ロードETL実行およびすべての関連時間次元テーブル(W_MCAL_%テーブルなど)が起動されます。
日付次元を拡張するには:
日付次元および関連テーブルの拡張を容易にするために、「Common dimension Extend Day Dimension」というサブジェクトエリアが用意されています。デフォルトでは、このサブジェクトエリアには、W_MCAL_%関連のタスクは含まれていません。日付次元で複数カレンダーのサポートが有効になっている場合、「Extend Day Dimension Multiple Calendar Support」という構成タグを含めます。次にこのサブジェクトエリアを作成します。
注意: サブジェクトエリア「Common dimension Extend Day Dimension」のみを拡張に含めてください。この拡張実行プランに他のサブジェクトエリアを含めないでください。
このサブジェクトエリアに対応する実行プラン(EP)を同じ名前を使用して作成します。
実行プラン内でタスクSIL_DayDimension_XTNDを選択し、パラメータ値を次のように設定します。
$$START_DATE: このパラメータを古い$$END_DATE値より1日大きい日付($$END_DATE +1)に設定します。
$$END_DATE: このパラメータを拡張する新しい終了日に設定します。
実行プラン内でSIL_TimeDimension_MCalPeriod_XTNDを選択し、パラメータ値を設定します。元の$$START_DATEをそのままにし、拡張する新しい$$END_DATEを選択します。$$END_DATE値は、手順3のタスクSIL_DayDimension_XTNDで選択した$$END_DATE値と同じ値にします。この手順は、手順1で構成タグ「Extend Day Dimension Multiple Calendar Support」を含めた場合のみ必要です。
必要に応じて、次のCSVファイルを変更します。
FILE_MCAL_CAL_D
FILE_MCAL_CONTEXT_G
FILE_MCAL_PERIOD_DS(汎用アダプタを使用している場合)
FILE_MCAL_CONFIG_G
これらのファイルのいずれかがソースとして使用されている場合、それらを新しい日付範囲に拡張する必要があります。
この実行プランを実行し、W_D_DAYおよび関連テーブルの日付が拡張されたことを確認します。
影響を受けたすべての要素集計を再作成します。再作成する集計およびその再作成方法の詳細は、My Oracle Supportのテクニカル・ノート1063484.1を参照してください。テクニカル・ノート1063484.1は、7.9.6.3以前のお客様向けに作成されました。
テクニカル・ノート1063484にも、時間次元および関連テーブルの拡張手順が記載されています。この手順書の手順の代替としてテクニカル・ノートの手順を使用できます。
次の図は、ETLプロセス・フローおよび様々な複数の会計カレンダー・タスクの依存関係を示しています。
この項では、総勘定元帳勘定のグループ勘定コードへのマッピングについて説明します。
グループ勘定の目的を理解するために、Financial Analyticsの総勘定元帳ダッシュボードの事前作成レポートの1つである月間貸借対照表レポートを確認できます。次の例は、前払い経費指標を中心に示し、その計算方法を説明します。
レポートの前払い経費指標は、RPDファイルのプレゼンテーション・レイヤーの「財務 - 総勘定元帳貸借対照表」サブジェクトエリア内の「ファクト - 貸借対照表」テーブルから直接取得されます。プレゼンテーション・レイヤー指標は、ビジネス・モデルおよびマッピング・レイヤーの対応する項目から取得されます。
図3-3は、月間貸借対照表レポートおよびRPDファイルの対応する指標を示しています。
ビジネス・モデルおよびマッピング・レイヤーの要素テーブル(総勘定元帳残高要素)は、総勘定元帳勘定次元と結合し、グループ勘定コードPPAID EXPに属する総勘定元帳勘定をフィルタします。
物理表W_GL_BALANCE_Fを見ると、この場合の指標が、グループ勘定コードPPAID EXPに関連付けられた総勘定元帳勘定(1340)から計算されています。(この例では、簡潔にするために、元帳などの他の次元を含んでいないことに注意してください)。
勘定1340がグループ勘定コードPPAID EXPに属していることを検証するために、file_group_acct_codes_source.csvファイル(たとえば、Oracle EBSの場合、file_group_acct_codes_ora.csv)のグループ勘定コードのマッピングの構成を表示できます。
図3-4は、W_GL_BALANCE_Fテーブルおよび対応するRPD指標を示しています。
このトピックについては、ソース固有の次の各項も参照してください。
この項では、ソース・システムに配置されているOracle BI Applicationsに適用される追加の構成手順について説明します。内容は次のとおりです。
データ・ソースの番号は、データ・ウェアハウスでデータを識別できるようにデータ・ソースに割り当てられる識別番号です。たとえば、1つのOracle EBS R12データ・ソースがある場合、デフォルトで値「9」が使用されます。2つのOracle EBS R12データ・ソースがあり、これらをデータ・ウェアハウスで区別する場合、異なるデータ・ソースの番号(たとえば、30)を2番目のデータ・ソースに割り当てる必要があります。
データ・ソースの番号は、データ・ウェアハウスのDATASOURCE_NUM_IDカラムに格納されます。
Oracle BI Applicationsは、多数の事前定義データ・ソース・テンプレートを使用してインストールされます。データ・ソース・テンプレートは、編集してOLTPデータ・ソースおよびOLAPデータ・ソースを指定できます。データ・ソース・テンプレートは、表3-5で指定された推奨データ・ソースの番号とともに事前に導入されています。事前定義されたテンプレートの1つを使用してデータ・ソースを指定する場合、デフォルトで定義されているデータ・ソースの番号を使用することをお薦めします。事前定義されたテンプレートの1つを使用せずに新規データ・ソースを作成する場合、表3-5にリストされているそのデータ・ソースのカテゴリにDATASOURCE_NUM_IDを指定することをお薦めします。たとえば、Oracle R12 EBSデータ・ソースを指定する場合、DATASOURCE_NUM_ID値「9」を指定することをお薦めします。データ・ソースの指定方法については、Oracle Business Intelligence Applications Informatica PowerCenterユーザーのためのインストール・ガイドの物理データ・ソースの設定に関する項を参照してください。
表3-5は、Oracle BI Applicationsで使用できるデータ・ソースおよびそのデフォルトのDATASOURCE_NUM_ID値を示しています。
注意: 表3-5にリストされているデータ・ソースのタイプのすべてが現在のバージョンのOracle Business Intelligence Applicationsでサポートされているわけではありません。サポートされるソース・システムのリストは、Oracle Business Intelligence Applicationsのシステム要件およびサポートされるプラットフォームを参照してください。
表3-5 データソースと関連付けられているDATASOURCE_NUM_ID値
| データソース名 | データソース番号 |
|---|---|
|
JDE_8_11_SP1_CTRL JDE_8_11_SP1_DATA JDE_8_11_SP1_DD JDE_8_11_SP1_FlatFile JDE_8_11_SP1_SYS |
17 |
|
JDE_8.12_CTRL JDE_8.12_DATA JDE_8.12_DD JDE_8_12_FlatFile JDE_8.12_SYS |
15 |
|
JDE_9.0_CTRL JDE_9.0_DATA JDE_9.0_DD JDE_9_0_FlatFile JDE_9.0_SYS |
25 |
|
JDEW_9_2_CTRL JDEW_9_2_DATA JDEW_9_2_DD JDEW_9_2_FlatFile JDEW_9_2_SYS |
24 |
|
ORA_11_5_8 ORA_11_5_8_Flatfile |
2 |
|
ORA_11_5_9 ORA_11_5_9_Flatfile |
5 |
|
ORA_11_5_10 ORA_11_5_10_Flatfile |
4 |
|
ORA_R12 ORA_R12_Flatfile |
9 |
|
ORA_R1211 ORA_R1211_Flatfile |
26 |
|
ORA_R1212 ORA_R1212_Flatfile |
27 |
|
ORA_R1213 ORA_R1213_Flatfile |
1000 |
|
PSFT_8_4_FINSCM PSFT_8_4_FlatFile |
7 |
|
PSFT_8_8_FINSCM PSFT_8_8_FlatFile |
8 |
|
PSFT_8_8_HCM |
6 |
|
PSFT_8_9_FINSCM PSFT_8_9_FlatFile |
11 |
|
PSFT_8_9_HCM PSFT_8_9_HCM_FlatFile |
10 |
|
PSFT_9_0_ELM PSFT_9_0_HCM PSFT_9_0_HCM_FlatFile |
12 |
|
PSFT_9_0_FINSCM PSFT_9_0_FlatFile |
13 |
|
PSFT_9_1_ELM PSFT_9_1_HCM PSFT_9_1_HCM_FlatFile |
28 |
|
PSFT_9_1_FINSCM PSFT_9_1_FlatFile |
29 |
|
SEBL_63 SEBL_6_3_Flatfile |
1 |
|
SEBL_753 SEBL_7_5_3_Flatfile |
1 |
|
SEBL_771 SEBL_7_7_1_Flatfile |
1 |
|
SEBL_78 SEBL_7_8_Flatfile |
1 |
|
SEBL_80 SEBL_8_0_Flatfile |
1 |
|
SEBL_811 SEBL_8_1_1_Flatfile |
1 |
|
SEBL_VERT_753 SEBL_VERT_7_5_3_Flatfile |
1 |
|
SEBL_VERT_771 SEBL_VERT_7_7_1_Flatfile |
1 |
|
SEBL_VERT_78 SEBL_VERT_7_8_Flatfile |
1 |
|
SEBL_VERT_80 SEBL_VERT_80_Flatfile |
1 |
|
SEBL_VERT_811 SEBL_VERT_8_1_1_Flatfile |
1 |
|
UNIV |
3 |
データ・ソースの番号を構成するには:
DACで、「Setup」ビューに移動し、「Physical Data Sources」タブを表示します。
構成するデータ・ソースを選択します。
「Edit」サブタブで、「Data Source Number」フィールドを使用して値を設定します。
「Save」をクリックします。
データ・ソースの番号の変更を選択してProcurement and Spend Analytics製品ファミリーを実装する場合は、第4.2.2.1項「購入サイクル明細のDACパラメータの構成方法」の手順を実行する必要があります。
「バックデート変更」とは、すでに処理され、ウェアハウスにロードされたOLTPレコードに生じた変更を意味します。役割階層は、従業員と管理者の報告関係を表し、この関係はOracle BI Applicationsのデータ・ウェアハウスで維持されます。この階層は、HRでは管理者階層に、CRMでは役割階層になります。役割階層は、現行の階層行の現行マークを使用して、階層の履歴バージョンをサポートします。役割階層は、履歴の追跡が有効化された状態で配信されます。従業員の組織と管理者は、タイプ2の緩やかに変化する属性です。また、CRMの役割階層では、従業員の役割の変更もタイプ2の緩やかに変化する属性として追跡されます。
リリース7.9.6.2以降では、管理者階層および役割階層に影響を及ぼすOLTPでのバックデート変更や削除でも、ウェアハウスでは変更が遡及的に反映されるように、ETLで適切に処理されます。
役割階層は列がフラット化した構造をしており、役割次元からロードされます。またこの役割階層では親子関係が維持されています。この項に記載されているシナリオでは、バックデート変更によって役割次元が受ける影響について、また、それにより役割階層が受ける影響について説明します。
Oracle EBSなどのOLTPソース・システムでは、履歴行または現行行に対して修正を行うことができます。修正は、データ・ウェアハウスのプライマリ・データソースとなるOLTP表、またはETLプロセスで補助参照用として機能する表に対して行うことができます。修正は、次の属性に影響する可能性があります:
履歴を収集せず、タイプ1の緩やかに変化する次元(SCD)としてデータ・ウェアハウスで処理される属性。
履歴を収集し、タイプ2のSCDとしてデータ・ウェアハウスで処理される属性。
役割階層は、様々な表におけるバックデート変更の影響を受けます。これにより、ETLプロセスも直接的または間接的な影響を受けます。たとえば、OLTPソース・システムで過去に遡って部署名を変更し、これに対応する従業員の割当てを変更しなかった場合、この部署名のバックデート変更によって役割階層に対する履歴の更新が発生します。
管理者階層または役割階層に影響を及ぼすOLTP表は、主に3つのタイプに分かれます。次の例は、OLTPソース・システムの表を表しています。
タイプA: すべての割当て履歴データが格納されるプライマリ駆動表です(PER_ALL_ASSIGNMENTS_Fなど)。この表は、データ・ウェアハウスの従業員割当て履歴に対するプライマリ・ドライバになります。
タイプB: OLTPには履歴が保持されない補助ソース表(タイプ1のSCD)ですが、ウェアハウスではタイプ2のSCDとして属性変更が追跡されます(HR_ORGANIZATION_UNITSなど)。この表は、ウェアハウスで履歴が追跡される属性のソースになります
タイプC: OLTPには履歴が保持されず、ウェアハウスでも属性の変更履歴が保持されない(タイプ1のSCD)補助ソース表です(PER_JOBSなど)。この表は、ウェアハウスで履歴が追跡されない属性のソースになります。
Oracle BI Applicationsリリース7.9.6の機能では、次のことを前提とします。
役割階層は、データ・ウェアハウス内ではタイプ2のSCDとして履歴の追跡が行われます。
部署名は、データ・ウェアハウス内ではタイプ2の緩やかに変化する属性として履歴の追跡が行われます。
従業員名(タイプ1の緩やかに変化する属性)は、データ・ウェアハウス内で履歴の追跡が行われません。
ジョブ(タイプ1の緩やかに変化する属性)は、ウェアハウス内で履歴の追跡が行われません。
次の表は、ウェアハウス内にある、バックデート変更前の従業員P1の割当て履歴の例です。
表3-6 バックデート変更前の従業員P1の割当て履歴の例
| 行 | 従業員 | 部門 | 管理者 | 開始日 | 終了日 |
|---|---|---|---|---|---|
|
行1 |
P1 |
CRM |
Mgr1 |
2006 |
2008 |
|
行2 |
P1 |
マイ部署 |
Mgr2 |
2008 |
2009 |
|
行3 |
P1 |
マイ部署 |
Mgr3 |
2009 |
4712 |
次の各項では、役割階層に影響を与えるOLTPでのバックデート変更のタイプと、そのバックデート変更シナリオへの対応としてウェアハウスに用意されているソリューションについて説明します。
ある部署名が、現行のレコードに対する修正として変更されました。たとえば、部署名「マイ部署」が、2010年に「マイ新規部署」に変更されたような場合です。異動の結果、従業員の部署は変更されませんでした。この場合、ソース表では部署名の履歴が追跡されないため、タイプBの変更、つまりタイプ2のウェアハウス内で緩やかに変化する属性になります。
オプション1 このオプションは、タイプ2(SCD)の変更として処理され、ウェアハウスにはタイプ2(SCD)の新規行が導入されます。このオプションは、DACパラメータUPDATE_CORRECTIONS_FLGが「N」に設定されている場合に有効です。
| 従業員 | 部門 | 管理者 | 開始日 | 終了日 |
|---|---|---|---|---|
| P1 | CRM | Mgr1 | 2006 | 2008 |
| P1 | マイ部署 | Mgr2 | 2008 | 2009 |
| P1 | マイ部署 | Mgr3 | 2009 | 2010 |
| P1 | マイ新規部署 | Mgr3 | 2010 | 4712 |
オプション2 このオプションは、修正として処理されるため、ウェアハウスではタイプ2の新規行は追加されず、履歴データのみが変更されます。このオプションは、DACパラメータUPDATE_CORRECTIONS_FLGが「Y」に設定されている場合に有効です。
| 従業員 | 部門 | 管理者 | 開始日 | 終了日 |
|---|---|---|---|---|
| P1 | CRM | Mgr1 | 2006 | 2008 |
| P1 | マイ新規部署 | Mgr2 | 2008 | 2009 |
| P1 | マイ新規部署 | Mgr3 | 2009 | 4712 |
部署名が履歴レコードに対する修正として変更されました。たとえば、部署名「マイ部署」が、過去の2008年に遡って「MD」に変更されたような場合です。異動の結果、従業員の部署は変更されませんでした。この場合も、部署名の履歴がOLTPソース・システムでは追跡されず、データ・ウェアハウスではタイプ2のSCDとして追跡されるため、タイプBの変更になります。
オプション 該当する履歴レコードで、変更内容に応じて名前を更新します。
| 従業員 | 部門 | 管理者 | 開始日 | 終了日 |
|---|---|---|---|---|
| P1 | CRM | Mgr1 | 2006 | 2008 |
| P1 | MD | Mgr2 | 2008 | 2009 |
| P1 | マイ新規部署 | Mgr3 | 2009 | 4712 |
補助表の変更: ウェアハウスの履歴データから参照されるジョブ情報が、OLTPソース・システムで変更されました。たとえば、ジョブ名が小文字に変更されたような場合です。この場合、OLTPでもデータ・ウェアハウスでも履歴の変更が追跡されないため、タイプCの変更になります。
オプション 新しいジョブは、すべての履歴行に伝播されます。
| 従業員 | 部門 | 管理者 | 開始日 | 終了日 |
|---|---|---|---|---|
| P1 | CRM | Mgr1、job2 | 2006 | 2008 |
| P1 | マイ部署 | Mgr2、job2 | 2008 | 2009 |
| P1 | マイ部署 | Mgr3、job2 | 2009 | 4712 |
異動の結果、従業員の割当て部署が変更されました。たとえば、従業員P1が2010年に部署「GRC」に異動になり、Mgr4の部下となったような場合です。この場合、メインのOLTP駆動表で変更が発生し、履歴の追跡も行われるため、タイプAの変更になります。
オプション ある従業員に新しい管理者が追加され、その従業員を追跡するために、データ・ウェアハウスに新規行が挿入されます。これは標準のケースです。
| 従業員 | 部門 | 管理者 | 開始日 | 終了日 |
|---|---|---|---|---|
| P1 | CRM | Mgr1 | 2006 | 2008 |
| P1 | マイ部署 | Mgr2 | 2008 | 2009 |
| P1 | マイ部署 | Mgr3 | 2009 | 2010 |
| P1 | GRC | Mgr4 | 2010 | 4712 |
これはシナリオ3のバリエーションです。たとえば、従業員が「CRM」から「マイ部署」に異動したのが、実際には2008年ではなく2007年だったような場合です。この場合は、割当て履歴レコードに対する修正になります。駆動側であるOLTP履歴表のeffective_fromとeffective_toの日付に対してバックデート変更が行われます。
オプション1 ウェアハウスで履歴データを更新します。このとき、ファクト表の更新は必要ありません。このオプションは、DACパラメータUPDATE_CORRECTIONS_FLGが「Y」に設定されている場合に有効です。
| 行 | 従業員 | 部門 | 管理者 | 開始日 | 終了日 |
|---|---|---|---|---|---|
| 1 | P1 | CRM | Mgr1 | 2006 | 2007 |
| 2 | P1 | マイ部署 | Mgr2 | 2007 | 2009 |
| 3 | P1 | マイ部署 | Mgr3 | 2009 | 4712 |
オプション2 このオプションでは、変更の追跡対象となる新規行がウェアハウスに導入されます。このオプションは、DACパラメータUPDATE_CORRECTIONS_FLGが「N」に設定されている場合に有効です。
| 行 | 従業員 | 部門 | 管理者 | 開始日 | 終了日 |
|---|---|---|---|---|---|
| 1 | P1 | CRM | Mgr1 | 2006 | 2007 |
| 4 | P1 | マイ部署 | Mgr2 | 2007 | 2008(新規) |
| 2 | P1 | マイ部署 | Mgr2 | 2008 | 2009 |
| 3 | P1 | マイ部署 | Mgr3 | 2009 | 4712 |
バックデート変更前の状態では、ファクト表には階層表の行1を参照しているトランザクションや行2への外部キーを持つトランザクションがありました。行1への外部キーを持つファクト行は、トランザクション日付に応じて、引き続き同じ外部キーを使用するか、行2または行4のいずれかに一致するように外部キーが更新されます。
OLTPソース・システムでバックデート変更を行うと、レコードが分割されます。たとえば、従業員の2007年の管理者をMgr1からMgr5に変更したような場合です。OLTPソース・システムでは、元のMgr1の情報を持つ割当てレコードの終了日に新しく2007が使用されます。また、2007年の管理者Mgr5には新規レコードが追加され、従業員が新しく割り当てられます。
オプション ウェアハウスは、OLTPソースの変更に応じて次の表のようになります。
| 行 | 従業員 | 部門 | 管理者 | 開始日 | 終了日 |
|---|---|---|---|---|---|
| 1 | P1 | CRM | Mgr1 | 2006 | 2007 |
| 4 | P1 | CRM | Mgr5 | 2007 | 2008(新規) |
| 2 | P1 | マイ部署 | Mgr2 | 2008 | 2009 |
| 3 | P1 | マイ部署 | Mgr3 | 2009 | 4712 |
行1への外部キーを持つファクト行では、トランザクション日付に応じて、その外部キーが引き続き使用されるか、または行4に対する外部キーとなるように更新されます。
バックデート変更は、特定の日付を基点としてすべてのレコードにカスケードされます。たとえば、行3のMgr2はMgr4になり、2008年以降のすべての行では、管理者も変更されます。従業員割当ての現行レコードは、データ・ウェアハウスでは次のようになります。
| 行 | 従業員 | 部門 | 管理者 | 開始日 | 終了日 |
|---|---|---|---|---|---|
| 1 | P1 | CRM | Mgr1 | 2006 | 2007 |
| 2 | P1 | CRM | Mgr5 | 2007 | 2008(新規) |
| 3 | P1 | マイ部署 | Mgr2 | 2008 | 2009 |
| 4 | P1 | マイ部署 | Mgr3 | 2009 | 4712 |
オプション ウェアハウスの履歴レコードおよび現行レコードを次のように更新します。
| 行 | 従業員 | 部門 | 管理者 | 開始日 | 終了日 |
|---|---|---|---|---|---|
| 1 | P1 | CRM | Mgr1 | 2006 | 2007 |
| 2 | P1 | CRM | Mgr5 | 2007 | 2008(新規) |
| 3 | P1 | マイ部署 | Mgr4 | 2008 | 2009 |
| 4 | P1 | マイ部署 | Mgr4 | 2009 | 4712 |
この項では、Oracle EBSソース・システムに配置されているOracle BI Applicationsに適用される構成手順について説明します。
この項は、次の項目を含んでいます。
この項では、データの完全ロードを実行する前に、Oracle EBSソース・システムに配置されているOracle BI Applicationsに適用される構成手順について説明します。内容は次のとおりです。
この項では、Product次元テーブルおよびInventory Product次元テーブルの製品階層の構成ポイントについて説明します。
階層は、Oracle EBSのフレックスフィールド構造のセグメント値を使用して定義されます。Oracle EBSでは最大20個のセグメントを使用できますが、Oracle Business Intelligence Applicationsがサポートするのは、10レベルの階層(セグメント)のみです。これらの階層は、Oracle EBSカテゴリー・セットおよびカテゴリーのテーブルから取得されます。デフォルトの製品階層は、次のようにデフォルトで構成されています。
購入カテゴリー・セットは、DACソース・システム・パラメータPROD_CAT_SET_ID1を使用して、値2が割り当てられます。
在庫カテゴリー・セットは、DACソース・システム・パラメータINV_PROD_CAT_SET_ID1を使用して、値27が割り当てられます。
これらのパラメータを構成し、Oracle Business Analytics WarehouseにロードするOracle EBSカテゴリー・セットIDに基づいて、DACで新しいPROD_CAT_SETnおよびINVPROD_CAT_SETnの各パラメータを作成します。
製品カテゴリー・セットを構成する手順は次のとおりです。
レポートするカテゴリー・セットを識別します(詳細は、第3.2.1.1.1項「Oracle EBSからのカテゴリー・セットの識別方法」を参照)。
製品階層のDACパラメータを構成します(詳細は、第3.2.1.1.2項「製品階層のDACソース・システム・パラメータの構成方法」を参照)。
この手順は、第3.2.1.1項「製品階層の構成(GL、HRモジュールを除く)」のタスクの一部です。
組織が使用しているカテゴリー・セットを検索する手順は次のとおりです。
Oracle EBSインスタンスにログインします。
「Setup」→「Items」→「Categories」→「Default Category Sets」をクリックします。
「Inventory」機能エリアを探して、「Category Set」フィールドにカーソルを置きます。
図3-5は、「Default Category Sets」画面の例を示しています。
「Help」→「Diagnostics」→「Examine」を選択してから、アプリケーションのユーザー・パスワードを指定します。
「Field LOV」ボタンをクリックし、CATEGORY_SET_IDを選択し、値を登録します。
「Purchasing」機能エリアで、手順3から5を繰り返します。
この手順は、第3.2.1.1項「製品階層の構成(GL、HRモジュールを除く)」のタスクの一部です。
製品階層のDACソース・システム・パラメータを構成するには:
DACで、「Design」ビューに移動して、適切なカスタム・コンテナをドロップダウン・リストから選択します。
「Source System Parameters」タブを表示します。
INV_PROD_CAT_SET_ID1パラメータおよびPROD_CAT_SET_ID1パラメータを検索し、それぞれのパラメータに対して次の作業を実行します。
複数の製品階層を設定する場合、配置する追加のINV_PROD_CAT_SET_IDnパラメータおよびPROD_CAT_SET_IDnパラメータに値を指定します。
「Save」をクリックします。
注意:
製品次元の単位は、マスター・レベルです。したがって、製品次元パラメータ(PROD_CAT_SET_ID)の値として選択されるカテゴリー・セットは、組織レベルではなくマスター・レベルで制御されるカテゴリー・セットである必要があります。
製品カテゴリ階層の追加またはカスタマイズの詳細は、第16.4項「製品カテゴリ階層の設定方法」を参照してください。
この項では、国連標準製品およびサービス・コード(UNSPSC)のコードを製品および商品に割り当てる方法について説明します。国連標準製品およびサービス・コード®(UNSPSC®)は、製品およびサービスの効率的かつ正確な分類に関してオープンでグローバルな複数セクターの標準を提供します。
UNSPSCコードをfile_unspsc.csvファイルに追加することによって、UNSPSCコードを製品に割り当てることができます。次にコードは、SDE_UNSPSCプロセスによって、W_PROD_CAT_DHテーブルにロードされます。次に、コードをFILE_ITEM_TO_UNSPSC.csvにマップして手動で分類し、ロード・プロセスPLP_ItemToUNSPSC_Classificationを使用して、製品(D)テーブルと製品カテゴリ(DH)テーブルをリンクする必要があります。
UNSPSCコードでは、次のことに注意してください。
自分のUNSPSCデータをUNSPSC.orgから直接購入し、file_unspsc.csvにデータをマップしてOracle BI Applicationsにロードする必要があります。
file_unspsc.csvファイルは、SDE_UNSPSCプロセスによって使用され、サンプル・データが含まれています。サンプル・データを自分のUNSPSCデータに置き換えます。この項の後で説明する手動分類手順を実行する前にこのタスクを実行してください。
UNSPSC_CODEカラムは、ファイル内の各レコードで一意である必要があります。このカラムは、Oracle BI Applications固有で、購入したUNSPSCデータからは取得されません。このカラムをCOMMODITY_CODEカラムにマップできます。
FUNCTION_CODEカラムおよびFUNCTION_NAMEカラムは、購入したUNSPSCデータに含まれている場合がある追加カラムです。購入したUNSPSCデータにこれらのカラムがない場合、これらのカラムをそれぞれCOMMODITY_CODEカラムとCOMMODITY_NAMEカラムにマップできます。これらのカラムは、階層のレベルを基本レベルにコピーするために使用されます。
ファイルのDATASOURCE_NUM_IDをOracle EBSアダプタに対して定義したものと同じにしてください。デフォルト値は、Oracle EBS R12では'9'、Oracle EBS R11510では'4'です。
UNSPSCコードを製品に割り当てるには:
デプロイに使用する製品を識別するには、W_PRODUCT_Dテーブルでselect文を実行します。
たとえば、Oracle SQLDeveloperを使用して次のSQLコマンドを実行します。
SELECT INTEGRATION_ID, PRODUCT_NAME, PART_NUMBER FROM W_PRODUCT_D;
注意: このSQL文の例では、INTEGRATION_IDは、分類する必要がある製品です。PRODUCT_NAMEとPART_NUMは、UNSPSCコードの分類を補助する追加属性です。
製品IDとUNSPSCコードをFILE_ITEM_TO_UNSPSC.csvファイルに追加します。
FILE_ITEM_TO_UNSPSC.csvファイルは、$PMServer\SrcFilesディレクトリにあります(たとえば、INFA_HOME\server\infa_shared\SrcFiles)。
PRODUCT_IDフィールドに、手順1で取得したINTEGRATION_ID値をポピュレートします。UNSPSC_CODEフィールドにUNSPSC.orgから購入したUNSPSCコードをポピュレートします。また、DATASOURCE_NUM_IDは、ご使用のOracle EBSアダプタと同じにしてください。
Informatica PowerCenter Designerで、\PLP\PLP_ItemToUNSPSC_Classificationワークフローを実行し、W_PRODUCT_Dテーブルの行を更新します。
Oracle 11iおよびR12.xのアプリケーションでは、製品はマスター組織で定義され、その後、トランザクション用に他の在庫組織にコピーされます。製品次元の抽出マッピングSDE_ORA_ProductDimensionでは、OLTP構成に基づいてこのマスター組織が構成できます。デフォルトでは、組織ID(DACの$$MASTER_ORGパラメータが設定)は204に設定されます。この組織ID(204)は、個々のOLTP実装に応じて変更する必要があります。
|
注意: このETL実装は、製品マスター定義におけるシングル・マスター組織の作成に関するオラクル社のベスト・プラクティスをサポートしています。組織コードの文字列をカンマで区切ることによって、複数のマスター組織を同じパラメータの下に割り当てることもできます(たとえば、「'204','458'」)。 |
製品次元抽出でマスター在庫組織を設定するには:
DACで、「Design」ビューに移動して、適切なカスタム・コンテナをドロップダウン・リストから選択します。
「Tasks」タブを表示して、SDE_ORA_ProductDimensionタスクに対するクエリーを実行します。
下部のペインに「Parameters」タブを表示し、$$MASTER_ORGパラメータを探します。
「Value」フィールドを使用して、適切な値を指定します。
たとえば、204と入力します。複数のマスター組織を定義するには、一重引用符内で囲んだ組織コードをカンマで区切られたリストにして指定します(たとえば、「'204', '301'」)。
変更を保存します。
この項では、Oracle総勘定元帳勘定をグループ勘定コードにマップする方法について説明します。項目は次のとおりです。
Oracle総勘定元帳勘定の設定の概要: 第3.2.1.4.1項「Oracle総勘定元帳勘定のグループ勘定コードへのマッピングの概要」を参照してください。
グループ勘定コードへのOracle総勘定元帳勘定のマップ方法の説明: 第3.2.1.4.2項「Oracle総勘定元帳勘定番号のグループ勘定コードへのマップ方法」を参照してください。
Oracle BIリポジトリへのグループ勘定コード指標の追加方法を説明する例: 第3.2.1.4.3項「グループ勘定コード指標のOracle BIリポジトリへの追加例」を参照してください。
|
注意: 総勘定元帳勘定番号は、グループ勘定コード(またはドメイン値)にマップされている必要があります。これは、総勘定元帳レポート・レイヤーの指標でこれらの値が使用されるためです。総勘定元帳勘定番号のドメイン値の一覧は、Oracle Business Analytics Warehouseデータ・モデル・リファレンスを参照してください。 |
詳細は、第3.1.5項「すべてのソース・システムに対する総勘定元帳勘定のグループ勘定コードへのマッピングについて」も参照してください。
グループ勘定コードの構成は、総勘定元帳および利益率モジュールの指標の大部分の精度を決定するため、Financial Analyticsの構成において重要な手順です。グループ勘定は財務諸表コードと組み合されて総勘定元帳の調整処理にも使用され、補助元帳データが総勘定元帳仕訳エントリに対して調整されます。このトピックの詳細は、この項の後で説明します。
$PMServer\SrcFilesディレクトリにある次の構成ファイルを使用して、総勘定元帳勘定を設定します。
file_group_acct_names.csv: このファイルは、グループ勘定名および対応するグループ勘定コードを指定します。
file_group_acct_codes_ora.csv: このファイルは、総勘定元帳勘定をグループ勘定コードにマップします。
file_grpact_fstmt.csv: このファイルは、財務諸表項目コートをグループ勘定コードにマップします。
データをロードする前に、勘定の値のマップがこれら3つの構成ファイル間で整合性があることを確認する必要があります。図3-6は、file_group_acct_names.csvのGROUP_ACCOUNT_NUMフィールドがfile_group_acct_codes_ora.csvのGROUP_ACCT_NUMフィールドおよびfile_grpact_fstmt.csvのGROUP_ACCT_NUMフィールドにどのようにマップされている必要があるかを示しています。
Oracle General Ledgerの勘定を特定のグループ勘定コードに分類できます。グループ勘定コードは、データの抽出時とフロントエンドでのレポート作成時に使用されます。総勘定元帳勘定次元テーブルW_GL_ACCOUNT_DのGROUP_ACCT_NUMフィールドは、総勘定元帳勘定の種類(現金勘定や給与勘定など)を表します。使用できるグループ勘定コード(たとえば、AR、CASH、COGS)については、file_group_acct_names.csvファイルのGROUP_ACCOUNT_NUMカラムを参照してください。グループ勘定コードのドメイン値の一覧は、Oracle Business Analytics Warehouseデータ・モデル・リファレンスを参照してください。総勘定元帳勘定番号のマップは、利益率分析と総勘定元帳分析(貸借対照表、損益計算書、現金収支一覧表など)の両方にとって重要です。
グループ勘定割当てのロジックは、file_group_acct_codes_ora.csvファイルにあります。表3-7は、file_group_acct_codes_ora.csvファイルの構成例です。
表3-7 file_group_acct_codes_ora.csvファイルの構成例
| CHART OF ACCOUNTS ID | FROM ACCT | TO ACCT | GROUP_ACCT_NUM |
|---|---|---|---|
|
1 |
101010 |
101099 |
CA |
|
1 |
131010 |
131939 |
FG INV |
|
1 |
152121 |
152401 |
RM INV |
|
1 |
171101 |
171901 |
WIP INV |
|
1 |
173001 |
173001 |
PPE |
|
1 |
240100 |
240120 |
ACC DEPCN |
|
1 |
261000 |
261100 |
INT EXP |
|
1 |
181011 |
181918 |
CASH |
|
1 |
251100 |
251120 |
ST BORR |
表3-7の最初の行では、会計チャート(COA)IDが1で、勘定番号101010から101099のすべての勘定が流動資産(つまり、CA)に割り当てられています。各行で、指定された会計チャートIDを持ち、指定された勘定番号の範囲内にあるすべての勘定がマップされます。
勘定番号の新しいグループを作成する必要がある場合は、file_group_acct_names.csvファイルに新しい行を作成できます。次に、file_group_acct_codes_ora.csvファイルで、勘定番号の新しいグループに対して総勘定元帳勘定を割り当てることができます。
また、file_grpact_fstmt.csvファイルにも新しい行を追加する必要があります。このファイルによって、グループ勘定コードと財務諸表項目コードとのリレーションシップが指定されます。表3-8は、グループ勘定コードがマップする必要がある財務諸表項目コードおよび関連のベース要素テーブルを示しています。
表3-8 財務諸表項目コードおよび関連のベース要素テーブル
| 財務諸表項目コード | ベース要素テーブル |
|---|---|
|
AP |
買掛金ベース要素(W_AP_XACT_F) |
|
AR |
売掛金ベース要素(W_AR_XACT_F) |
|
COGS |
売上原価ベース要素(W_GL_COGS_F) |
|
REVENUE |
収益ベース要素(W_GL_REVN_F) |
|
TAX |
税金ベース要素(W_TAX_XACT_F)脚注 1 |
|
OTHERS |
総勘定元帳仕訳ベース要素(W_GL_OTHER_F) |
脚注 1 Financial AnalyticsのOracle EBSアダプタは税金ベース要素(W_TAX_XACT_F)をサポートしません。
総勘定元帳勘定をグループ勘定コードにマップし、そのグループ勘定コードを財務諸表項目コードに関連付けることにより、総勘定元帳勘定番号が財務諸表項目コードに間接的に関連付けられます。この関連付けは、総勘定元帳の調整を実行し、補助元帳データを総勘定元帳仕訳エントリに対して調整する際に重要です。請求書が総勘定元帳に転送された後、総勘定元帳のユーザーは、総勘定元帳でその請求書を調整できます。このシナリオでは、調整金額を補助元帳のベース要素および残高テーブルに確実に反映することが重要です。総勘定元帳でこのような補助元帳のトランザクションを決定するために、調整プロセスでは、財務諸表項目コードが使用されます。
財務諸表項目コードはETLプロセスで使用される内部コードで、補助元帳に対する総勘定元帳の調整プロセス時に総勘定元帳仕訳レコードの処理に使用されます。ETLプロセスによって総勘定元帳仕訳レコードが調整される場合、その仕訳が記入される総勘定元帳勘定に関連付けられている財務諸表項目コードが確認され、その財務諸表項目コードの値を使用して、どのベース要素に対して総勘定元帳仕訳を調整するかが決められます。たとえば、AP財務諸表項目コードに関連付けられている総勘定元帳勘定に記入される総勘定元帳仕訳を調整するときは、買掛金ベース要素テーブル(W_AP_XACT_F)に対して調整され、その要素テーブルに対応する買掛金会計仕訳が検索されます。総勘定元帳勘定がREVENUE財務諸表項目コードに関連付けられている場合は、収益ベース要素テーブル(W_GL_REVN_F)に対して調整され、その要素テーブルに対応する収益会計仕訳が検索されます。
|
注意: グループ勘定コードを指定する場合、文字を大文字にして、file_group_acct_names.csvファイルのGROUP_ACCOUNT_NUMカラムの値を使用する必要があります。 |
この項では、Oracle総勘定元帳勘定番号をグループ勘定コードにマップする方法を説明します。
|
注意: 新しいグループ勘定コードをfile_group_acct_codes_ora.csvファイルに追加する場合、指標をOracle BIリポジトリに追加する必要もあります。詳細は、第3.2.1.4.3項「グループ勘定コード指標のOracle BIリポジトリへの追加例」を参照してください。 |
Oracle総勘定元帳勘定番号をグループ勘定コードにマップするには:
テキスト・エディタを使用して、$PMServer\SrcFilesディレクトリ(たとえば、INFA_HOME\server\infa_shared\SrcFiles)にあるfile_group_acct_codes_ora.csvファイルを開きます。
マップするOracle総勘定元帳勘定番号それぞれに対して、次のフィールドを含むファイルに新しい行を作成します。
| フィールド名 | 説明 |
|---|---|
| CHART OF ACCOUNTS ID | 総勘定元帳の会計チャートのID。 |
| FROM ACCT | 種類別勘定の範囲の下限。この値は総勘定元帳勘定の種類別勘定のセグメントに基づきます。 |
| TO ACCT | 種類別勘定の範囲の上限。この値は総勘定元帳勘定の種類別勘定のセグメントに基づきます。 |
| GROUP_ACCT_NUM | このフィールドは、file_group_acct_names.csvファイルで指定されたOracle総勘定元帳勘定のグループ勘定コードを表します。買掛金の場合にはAP、現金勘定の場合にはCASH、給与勘定の場合にはGEN PAYROLLなどです。 |
次に例を示します。
101, 1110, 1110, CASH 101, 1210, 1210, AR 101, 1220, 1220, AR
|
注意: オプションで、CSVファイルの未使用の行を削除できます。 |
file_group_acct_codes_ora.csvファイルで指定する値は、file_group_acct_names.csvファイルおよびfile_grpact_fstmt.csvファイルで指定する値と整合性を保つようにしてください。
例については、図3-6「Oracle EBSのグループ勘定を構成する構成ファイル」を参照してください。
CSVファイルを保存して閉じます。
新しいグループ勘定コードをfile_group_acct_codes_ora.csvファイルに追加する場合(第3.2.1.4.2項「Oracle総勘定元帳勘定番号のグループ勘定コードへのマップ方法」を参照)、指標をOracle BIリポジトリに追加して、新しいグループ勘定コードを公開する必要もあります。この例は、Oracle BI管理ツールを使用して、グループ勘定コードの指標を追加する方法を示しています。
この例では、「Payroll」という新しいグループ勘定コードがあり、新しい指標を「Payroll Expense」というプレゼンテーション・レイヤーに追加します。
新しい指標を論理テーブル「Fact – Fins – GL Other Posted Transaction」に追加するには:
管理ツールを使用して、OracleBIAnalyticsApps.rpdを開きます。
OracleBIAnalyticsApps.rpdファイルは次の場所にあります。
ORACLE_INSTANCE\bifoundation\OracleBIServerComponent\coreapplication_ obisn\repository
「ビジネス・モデルとマッピング」レイヤーで、次を実行します。
「Payroll Expense」という論理カラムを論理テーブル「Fact – Fins – GL Other Posted Transaction」に作成します。
たとえば、「Core\Fact - Fins - GL Other Posted Transaction\」オブジェクトを右クリックし、「新規オブジェクト」→「論理列」を選択し、「論理列」ダイアログを表示します。「名前」フィールドで「Payroll Expense」を指定します。
「集計」タブを表示し、「デフォルトの集計ルール」ドロップダウン・リストで「合計」を選択します。
「OK」をクリックして詳細を保存し、ダイアログを閉じます。
「Core\Fact - Fins - GL Other Posted Transaction\Sources\」フォルダを展開し、「Fact_W_GL_OTHER_GRPACCT_FSCLYR_A」ソースをダブルクリックして、「論理表ソース」ダイアログを表示します。
「列マッピング」タブを表示します。
「マップされていない列の表示」を選択します。
「Payroll Expense」式を探し、「式ビルダー」ボタンをクリックして、式ビルダーを開きます。
式ビルダーを使用して、次のSQL文を指定します。
CASE WHEN "Oracle Data Warehouse"."Catalog"."dbo". "Dim_W_GL_GROUP_ACCOUNT_D"."GROUP_ACCOUNT_NUM" = 'PAYROLL' THEN "Oracle Data Warehouse"."Catalog"."dbo". "Fact_Agg_W_GL_OTHER_GRPACCT_FSCLYR_A"."OTHER_GLOBAL1_AMT" ELSE NULL END
CASE条件は、新しいグループ勘定コード「Payroll」を参照し、これをフィルタとして使用します。
論理テーブル・ソースそれぞれに対して、手順dからhを繰り返します。論理テーブル・ソースに対応する要素テーブルを使用して、各論理テーブル・ソースに対して、手順hで適切に式を変更します。
手順dからhは、論理テーブル・ソースそれぞれに対して繰り返す必要があります。これは、この例では、この論理テーブルの要素テーブルおよび集約テーブルに対して複数の論理テーブル・ソースがあるためです。対応する要素テーブルを使用して、各論理テーブル・ソースに対して、手順hで適切に式を変更します。
これらの詳細を保存します。
エンド・ユーザーのダッシュボードおよびレポートで新しいリポジトリ・オブジェクトを公開するには、新しいオブジェクトをビジネス・モデルおよびマッピング・レイヤーからプレゼンテーション・レイヤーの該当するフォルダにドラッグします。
新しい指標を論理テーブル「Fact – Fins – GL Balance」に追加するには:
管理ツールを使用して、OracleBIAnalyticsApps.rpdを開きます。
OracleBIAnalyticsApps.rpdファイルは次の場所にあります。
ORACLE_INSTANCE\bifoundation\OracleBIServerComponent\coreapplication_ obisn\repository
「ビジネス・モデルとマッピング」レイヤーで、次を実行します。
「Payroll Expense」という論理カラムを論理テーブル「Fact – Fins – GL Balance」に作成します。
たとえば、「Core\Fact – Fins – GL Balance」オブジェクトを右クリックし、「新規オブジェクト」→「論理列」を選択し、「論理列」ダイアログを表示します。「名前」フィールドで「Payroll Expense」を指定します。
「列ソース」タブで「式を使用して既存の列から派生」を選択します。
「式ビルダー」ボタンをクリックして、式ビルダーを表示します。
式ビルダーを使用して、次のSQL文を指定します。
FILTER("Core"."Fact - Fins - GL Balance"."Activity Amount" USING "Core"."Dim - GL Account"."Group Account Number" = 'Payroll')
CASE条件は、新しいグループ勘定コード「Payroll」を参照します。
これらの詳細を保存します。
エンド・ユーザーのダッシュボードおよびレポートで新しいリポジトリ・オブジェクトを公開するには、新しいオブジェクトをビジネス・モデルおよびマッピング・レイヤーからプレゼンテーション・レイヤーの該当するフォルダにドラッグします。
注意: グループ勘定コードと財務諸表項目コードの概要は、第3.2.1.4項「Oracle総勘定元帳の種類別勘定のグループ勘定コードへのマッピングについて」を参照してください。
総勘定元帳の種類別勘定が間違ったグループ勘定コードにマップされると、不適切な会計エントリが要素テーブルに挿入される可能性があります。たとえば、APグループ勘定コードに分類されるはずの種類別勘定1210が、ARグループ勘定コードに間違って分類されているとします。この場合、ETLプログラムは勘定1210に対してすべての総勘定元帳の仕訳明細を記入し、これらの総勘定元帳の仕訳明細を売掛金要素テーブル(W_AR_XACT_F)の補助元帳会計レコードに対して調整しようとします。これらの総勘定元帳の仕訳明細は売掛金とは関係ないため、ETLプログラムは、これらの総勘定元帳の仕訳明細に対応する補助元帳会計レコードを見つけることができません。この場合、ETLプログラムにより、これらの総勘定元帳の仕訳明細が、総勘定元帳システムによる売掛金勘定に対する記入時に直接作成された手動仕訳エントリであると判断され、その結果、売掛金要素テーブルに手動レコードが挿入されます。このプロセス全体を、総勘定元帳の調整プロセスと呼びます。
売掛金要素テーブルのこれらの手動エントリを元に戻すには、Oracle BI Applicationsに付属の「Group Account Number Clean Up」プログラムを使用します。このプログラムは、要素テーブル(この場合は、売掛金要素テーブル)の手動エントリを元に戻し、総勘定元帳の調整プロセスの再実行を試みます。file_group_acct_codes_ora.csvファイルで種類別勘定1210がAPグループ勘定コードに割当て変更されていれば、ETLプログラムは、AP要素(W_AP_XACT_F)で対応する補助元帳会計レコードを探します。
|
注意: 「Financials – Group Account Number Clean Up」サブジェクトエリアは、グループ勘定コードの割当てを修正する必要がある場合のみ使用してください。このサブジェクトエリアは、標準のFinancials実行プランに含まないでください。これは、個別に実行する必要があります。 |
グループ勘定を修正するには:
入力CSVファイルfile_group_acct_codes_ora.csv内の、グループ勘定に対する総勘定元帳の種類別勘定のマッピングを修正します。
たとえば、修正前のCSVファイルに、次の値が指定されているとします。
CHART OF ACCOUNTS ID = 101
FROM ACCT = 1110
TO ACCT = 1110
GROUP_ACCT_NUM = CASH
勘定1210の元の分類先がAPグループ勘定コードであるとすると、修正後のCSVファイルでは、この総勘定元帳の種類別勘定とグループ勘定のマッピング値は次のようになります。
CHART OF ACCOUNTS ID = 101
FROM ACCT = 1210
TO ACCT = 1210
GROUP_ACCT_NUM = AR
DACで、次を実行します。
「Design」ビューに移動して、ドロップダウン・リストから適切なカスタム・コンテナを選択します。
Subject Areasタブを表示します。
「Financials – General Ledger」サブジェクトエリアに対するクエリーを実行します。
「Configuration Tags」サブタブを表示し、次のいずれの構成タグが「Inactive」にマークされているかを確認します。
- Financials – Calculate GL Balance
- Oracle – Extract GL Balance
デフォルトでは、「Financials – Calculate GL Balance」が「Inactive」にマークされています。
「Financials – Group Account Number Clean Up」サブジェクトエリアに対するクエリーを実行し、次の手順を実行します。
- 前の手順で、構成タグ「Financials – Calculate GL Balance」が「Inactive」にマークされていた場合は、「Financials – Calculate GL Balance Reverse」も「Inactive」にマークします。
- 前の手順で、「Oracle – Extract GL Balance」が「Inactive」にマークされていた場合は、「Financials – Calculate GL Balance Reverse」をアクティブにマークします(つまり、「Inactive」チェック・ボックスを選択解除)。
前の手順で変更を行う必要がある場合、「Subject Areas」タブを表示し、「Financials – Group Account Number Clean Up」というサブジェクトエリアを再アセンブルする必要があります。
「Financials – Group Account Number Clean Up」というサブジェクトエリアのロードに使用している実行プランを再構築して実行します。
たとえば、Oracle EBSのバージョンに応じて、「Financials – Group Account Number Clean Up R12」や「Financials – Group Account Number Clean Up R1211」などのデフォルトの実行プランのいずれかを使用します。
次のアプリケーションのいずれかをデプロイしている場合、総勘定元帳勘定階層を構成する必要があります。
Oracle Financial Analytics
Oracle Procurement and Spend Analytics
Oracle Supply Chain and Order Management Analytics
総勘定元帳勘定階層を構成する方法は2つあります。
総勘定元帳会計フレックスフィールドの値セット定義の使用
手順は、第3.2.1.6.1項「フレックスフィールドの値セット定義を使用した総勘定元帳セグメントおよびセグメント階層の構成方法」を参照してください。
Financial Statement Generator(FSG)のレポート定義の使用
このオプションは、ソース・システムがOracle EBSの場合のみ使用できます。手順は、第3.2.1.6.2項「Financial Statement Generator(FSG)のレポート定義を使用した総勘定元帳勘定階層の構成方法(Oracle EBS用)」を参照してください。
どちらの方法で総勘定元帳勘定階層を設定する場合も、階層情報はW_HIERARCHY_Dテーブルに格納します。
たとえば、US Acctという総勘定元帳勘定の階層に次のような構造があるとします。
ノードAに子ノードBおよびCがある。
ノードBに子ノードDおよびEがある。
ノードCに子ノードFおよびGがある。
ノードDに子ノードHおよびIがある。
ノードFに子ノードJおよびKがある。
図3-7は、このUS Acctの階層の例を示します。
表3-9は、US Acctの階層がW_HIERARCHY_Dテーブルに格納されるしくみを示しています。
表3-9 US Acctの階層のW_HIERARCHY_Dテーブルへの格納例
| HIER_KEY | HIER_NAME | HIER1_CODE | HIER2_CODE | HIER3_CODE | HIER4_CODE | HIER5_CODE | 6 - 19 | HIER20_CODE |
|---|---|---|---|---|---|---|---|---|
|
1 |
US Acct |
A |
B |
D |
H |
H |
H |
H |
|
2 |
US Acct |
A |
B |
D |
I |
I |
I |
I |
|
3 |
US Acct |
A |
B |
E |
E |
E |
E |
E |
|
4 |
US Acct |
A |
C |
F |
J |
J |
J |
J |
|
5 |
US Acct |
A |
C |
F |
K |
K |
K |
K |
|
6 |
US Acct |
A |
C |
G |
G |
G |
G |
G |
Oracle Financial Analytics、Oracle Procurement and Spend AnalyticsおよびOracle Supply Chain and Order Management Analyticsをデプロイしている場合、総勘定元帳勘定階層を構成する必要があります。
30個のセグメントがサポートされます。ここに勘定フレックスフィールドを格納できます。フレックスフィールドは柔軟性があるため、複雑なデータ構成に対応できます。次に例を示します。
任意のセグメントにデータを格納できます。
必要に応じて、会計チャートごとに使用するセグメントの数を増減できます。
同じ会計チャートに対して、複数のセグメントを指定できます。
次の例は、US会計チャートとAPAC会計チャートの両方を持つ企業のデータ構成です。
表3-10 会計チャートの例
| セグメント・タイプ | US会計チャート(4256)の値 | APAC会計チャート(4257)の値 |
|---|---|---|
|
企業 |
セグメント3に格納 |
セグメント1に格納 |
|
種類別勘定 |
セグメント4に格納 |
セグメント3に格納 |
|
コストセンター |
セグメント5に格納 |
セグメント2に格納 |
|
地域 |
セグメント2に格納 |
セグメント5に格納 |
|
業務別ライン(LOB) |
セグメント1に格納 |
セグメント4に格納 |
この例は、会計チャート4256では、「企業」がOracle EBSのテーブルGL_CODE_COMBINATIONS_ALLのセグメント3カラムに格納されることを示しています。会計チャートCOA4257では、「企業」はGL_CODE_COMBINATIONS_ALLテーブルのセグメント1カラムに格納されます。この構成ファイルの目的は、セグメントの情報がデータ・ウェアハウス・テーブルW_GL_ACCOUNT_Dに抽出されるときに、異なる会計チャートの同種のセグメントがW_GL_ACCOUNT_Dの同じカラムに格納されるようにすることです。
たとえば、会計チャート4256と4257の企業セグメントをW_GL_ACCOUNT_Dのセグメント1カラムに格納でき、コストセンター・セグメントをセグメント2カラムに格納できます。他のセグメントも同様です。
総勘定元帳勘定のETLプロセスを実行する前に、file_glacct_segment_config_source_system.csvというETL構成ファイルを使用して、分析するセグメントを指定する必要があります。このファイルは、$PMServer\SrcFiles(たとえば、INFA_HOME\server\infa_shared\SrcFiles)にあります。
図3-8 テキスト・エディタで開いたfile_glacct_segment_config_ora.csvファイル
file_glacct_segment_config_source_system.csvファイルでは、同一カラムで同種のセグメントを指定する必要があります。たとえば、すべての会計チャートのすべてのコストセンター・セグメントを1つのカラムに格納し、すべての会計チャートのすべての企業セグメントを別のカラムに格納します。
たとえば、次のような処理が必要な場合があります。
企業、コストセンター、種類別勘定および商品ラインの各セグメントを使用して、総勘定元帳勘定階層を分析します。
この階層分析に地域セグメントは使用しません。
すべての会計チャートのすべての企業セグメントをW_GL_ACCOUNT_DのACCOUNT_SEG1_CODEカラムに格納します。
すべての会計チャートのすべてのコストセンター・セグメントを、W_GL_ACCOUNT_DのACCOUNT_SEG2_CODEカラムに格納します。
すべての会計チャートのすべての種類別勘定セグメントを、W_GL_ACCOUNT_DのACCOUNT_SEG3_CODEカラムに格納します。
すべての会計チャートのすべての商品ライン・セグメントを、W_GL_ACCOUNT_DのACCOUNT_SEG4_CODEカラムに格納します。
W_GL_BALANCE_A(総勘定元帳勘定残高を集計レベルで格納)には、総勘定元帳のコード組合せレベルではなく、企業およびコストセンター・レベルで総勘定元帳勘定残高を格納します。
注意: W_GL_BALANCE_AをポピュレートするETLロジックは、「CHART OF ACCOUNTS_ID = AGGREGATION」であるファイルの最後の行に依存します。ValueSet定義を使用する総勘定元帳勘定階層を使用していない場合でも、CSVファイルにこの行を含める必要があります。この値のデフォルト設定は、SEG1からSEG6まで「Y」です(つまり「AGGREGATION,Y, ,Y, ,Y, ,Y, ,Y, ,Y」)。
U.S. Federal Financial Analyticsの総勘定元帳セグメントの構成ファイルを設定します。
U.S. Federal Financials Analyticsの場合、最初の2つのセグメントは、それぞれ資金用およびプログラム用に予約されます。したがって、これらのいずれかまたは両方を使用するには、次の特定の順序でfile_glacct_segment_config_source_system.csvを構成します。
1. 資金セグメント・カラムの名前をCSVファイルのSEGMENT1カラムに入力します。
2. プログラム・セグメント・カラムの名前をCSVファイルのSEGMENT2カラムに入力します。
ソース・システムにこれらの予約済セグメントのいずれもない場合、CSVファイルのこのセグメントを空のままにします。資金およびプログラム以外のセグメントを構成するには、これらのセグメントをSEGMENT3から構成します。
値セット定義を使用した総勘定元帳セグメントおよび階層の構成手順
file_glacct_segment_config_source_system.csvを次のように構成します。
$PMServer\SrcFilesにナビゲートします(たとえば、INFA_HOME\server\infa_shared\SrcFiles)。
テキスト・エディタでfile_glacct_segment_config_source_system.csvを開きます。
「総勘定元帳セグメントの構成ファイルの設定方法」の手順に従い、ファイルを構成します。
総勘定元帳セグメントの値セット階層を抽出している場合、DACで次の手順を実行します。値セット階層のない総勘定元帳セグメントのみの使用を計画している場合、この手順をスキップして手順3に進みます。
「Subject Areas」タブにナビゲートし、「Financials – General Ledger」に対するクエリーを実行します。
「Configuration Tags」サブタブで、次の手順を実行します。
タグ「Oracle – Extract Value Set Hierarchies」に対するクエリーを実行し、「Inactive」チェック・ボックスが選択されていないことを確認し、タグ「Oracle – Extract FSG Hierarchies」に対するクエリーを実行し、「Inactive」チェック・ボックスが選択されていることを確認します。
「Assemble」をクリックして、サブジェクト・エリアを再アセンブルします。
「Execute」ビューの「Execution Plans」タブにナビゲートし、「Financials – General Ledger」サブジェクトエリアを含むすべての実行計画を再構築します。
実行計画を構築する方法の詳細は、Oracle Business Intelligenceデータ・ウェアハウス管理コンソール・ガイドを参照してください。
総勘定元帳勘定に対して実行計画を実行します。
Oracle BI管理ツールを使用して、RPDメタデータで次の変更を行います。メタデータには、各総勘定元帳セグメント(「Dim – GL Segment1」、「Dim – GL Segment2」など)を表す複数の論理テーブルが含まれています。これらの論理テーブルはすべて、同じ物理テーブルW_GL_SEGMENT_Dにマップされているため、その特定のセグメントのみを表すように論理テーブルの出力を抑制するために、これらの論理テーブルの論理テーブル・ソースでフィルタを指定する必要があります。物理カラムSEGMENT_LOV_IDに対するフィルタをその特定のセグメントに適用可能なValueSet IDに設定する必要があります。ValueSet IDのリストは、前述のCSVファイルで構成したValueSet IDと同じになります。
Oracle BI Repositoryのビジネス・モデルとマッピング・レイヤーでフィルタを指定するには、次の手順を実行します。
管理ツールを使用して、OracleBIAnalyticsApps.rpdを開きます。
OracleBIAnalyticsApps.rpdファイルは次の場所にあります。
ORACLE_INSTANCE\bifoundation\OracleBIServerComponent\coreapplication_ obisn\repository
各論理表(Dim - GL Segment1など)を開き、その論理表の論理表ソースを開きます。
「コンテンツ」タブを表示します。
このWHERE句の使用…ボックスで、W_GL_SEGMENT_Dの対応する物理表の別名に対するフィルタを適用します。次に例を示します。
"Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_GL_SEGMENT_D_Segment1"."SEGMENT_LOV_ID" IN (comma seperated valuesetids)
このセグメントに対応するすべてのValueSet IDをカンマで区切って入力します。
Oracle Financial Analyticsでは、総勘定元帳次元で最大30のセグメントをサポートします。また、デフォルトでは、RPDで10個の総勘定元帳セグメントを利用できます。10個以上の総勘定元帳セグメントが必要な場合は、次の手順を実行して新しいセグメントを追加します。
「物理」レイヤーで、次の手順を実行します。
W_GL_SEGMENT_Dの新しい物理別名を、Dim_W_GL_SEGMENT_D_SegmentXXとして作成します。これを行うには、物理表W_GL_SEGMENT_Dを右クリックし、「新規オブジェクト」を選択してから「別名」を選択します。新しい別名にDim_W_GL_SEGMENT_D_SegmentXXという名前を付けます。同様に、W_HIERARCHY_Dの新しい別名をDim_W_HIERARCHY_D_SegmentXXとして作成します。
物理図で、Dim_W_HIERARCHY_D_Segment1とDim_W_GL_SEGMENT_D_Segment1間の物理外部キーと同様に、Dim_W_HIERARCHY_D_SegmentXXとDim_W_GL_SEGMENT_D_SegmentXX間に物理外部キーを作成します。この外部キーの方向は、W_HIERACHY_DからW_GL_SEGMENT_Dに向ける必要があります。たとえば、'0/1':N基数の結合では、W_HIERARCHY_Dが'0/1'側になり、W_GL_SEGMENT_Dが'N'側になります。物理外部キー結合を作成する方法の詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ作成者ガイド』を参照してください。
同様に、Dim_W_GL_SEGMENT_D_SegmentXXとDim_W_GL_ACCOUNT_D間に物理外部キー結合を作成します。このとき、W_GL_SEGMENT_Dを'1'側にして、W_GL_ACCOUNT_Dを'N'側にします。
変更を保存します。
「ビジネス・モデルとマッピング」レイヤーで、次を実行します。
新しい論理表Dim - GL SegmentXXを、Dim - GL Segment1と同じように作成します。この論理表には、前述の手順で作成した物理表にマップされている論理表ソースを含める必要があります(たとえば、Dim_W_GL_SEGMENT_D_SegmentXXとDim_W_HIERARCHY_D_SegmentXXの両方を含めます)。また、この論理表には、それぞれの物理表Dim_W_GL_SEGMENT_D_SegmentXXとDim_W_HIERARCHY_D_SegmentXXに適切にマップされているDim - GL Segment1と同様に、すべての属性を含める必要もあります。
ビジネス・モデル図で、Dim - GL Segment1と同じようにDim - GL SegmentXXから、すべての関連論理ファクト表への論理結合を作成します。このとき、総勘定元帳セグメント次元論理表を0/1側にして、論理ファクト表をN側にします。すべての関連論理ファクト表を確認するには、最初に、ビジネス・モデル図にDim - GL Segment1を含めて、この表を右クリックしてから「直接結合の追加」を選択します。
前述の手順で説明したように、Dim - GL SegmentXXの論理表ソースにコンテンツ・フィルタを追加します。
Dim - GL SegmentXXを右クリックし、「ディメンションの作成」を選択して次元を作成します。この名前を、GL SegmentXXに変更します。ドリルダウン構造がGL Segment1と同様になっていることを確認します。これを行う方法がわからない場合は、次の手順を実行します。デフォルトでは、この次元にはGrand Total LevelとDetail Levelという2つのレベルがあります。これらのレベルの名前を、それぞれAllとDetailに変更します。Allレベルを右クリックし、「新規オブジェクト」を選択してから「子レベル」を選択します。このレベルに、Level1という名前を付けます。同様に、Level1の下にレベルを作成して、そのレベルにLevel2という名前を付けます。この手順を、Level18の次のLevel19に達するまで繰り返します。この時点で、DetailレベルをLevel19の下にドラッグして、階層の最後のレベルがDetailになるようにします。ここで、新しい論理表Dim - GL SegmentXXからLevel1のCode属性とLevel1の「名前」属性を、階層のLevel1レベルにドラッグします。次に、Levelの「プロパティ」に移動して、「キー」タブから2つの新しいキーを作成します。このキーの一方はLevel1の「コード」用で、もう一方はLevel1の「名前」用です。キーの作成時には、ドリルダウン用に使用オプションがLevel1の「コード」に対しては「オフ」、Level1の「名前」に対しては「オン」になっていることを確認します。また、「主キー」ドロップダウンがLevel1の「コード」に設定されていることも確認します。次に、19のレベルすべてに対して同様の作業を進めます。該当する2つの属性を該当するレベルにドラッグし、前述したようにキーを作成します。Detailレベルについては、Level20の「コード」とLevel20の「名前」の属性をこのレベルにドラッグし、前述したようにキーを作成します。
新しく作成した論理表Dim - GL SegmentXXの「論理表ソース」を開きます。「論理レベル」を、前の手順で作成したGL SegmentXX次元または階層のDetailレベルに設定することで、「コンテンツ」タブの「集計内容」を設定します。
同様に、集計コンテンツをすべての関連要素論理テーブル・ソースに対して設定します。新しい論理表に関連するすべての論理ファクト表の「論理表ソース」を、すべて同時に開きます。「コンテンツ」タブに移動します。これが、その他の総勘定元帳次元(GL Segment1、GL Segment2など)のDetailレベルに設定されている場合は、それを前述の手順で作成したGL Segment XX次元または階層のDetailレベルに設定します。それ以外の場合は、その論理表ソースはスキップして、次の論理表ソースに作業を進めます。
新しいDim - GL Segment XX次元を、「プレゼンテーション」レイヤーの該当するサブジェクト・エリアにドラッグします。通常、このような総勘定元帳セグメント次元は、総勘定元帳勘定次元が公開されているすべてのサブジェクト・エリア内で公開できます。また、該当するすべてのサブジェクト・エリアは、Dim - GL Segment1を右クリックし、「問合せ関連オブジェクト」を選択してから「サブジェクト・エリア」を選択することで確認できます。
変更を保存し、グローバルな整合性をチェックを実行します。
各総勘定元帳セグメントは、OLTPの特定の意味のあるValueSetを表します。レポート内の各セグメントを明確に識別するために、プレゼンテーション表GL SegmentX、論理次元GL SegmentXおよび論理表Dim - GL SegmentXを、ぞれぞれが持つ意味に応じた名前に変更できます。
たとえば、製品セグメントをSegment1にポピュレートする場合、論理テーブル「Dim - GL Segment1」を「Dim – GL Segment Product」などの該当する名前に変更し、プレゼンテーション・レイヤーのテーブルの名前をこれに合せて変更できます。
Oracle Financial Analytics、Oracle Procurement and Spend AnalyticsおよびOracle Supply Chain and Order Management Analyticsをデプロイしている場合、総勘定元帳勘定階層を構成する必要があります。総勘定元帳勘定階層を構成する2つの方法については、第3.2.1.6項「総勘定元帳勘定階層の構成について」を参照してください。
会計チャート内の複数のセグメントに基づいて総勘定元帳勘定階層を定義する必要がある場合は、Oracle EBSのOracle FSGのレポート定義を使用できます。
まず、Oracle FSGのフォームを使用して、行セットまたはカラム・セットを定義します。次に、Oracle BI Applicationsにより行セットまたはカラム・セットの定義を抽出し、それらを階層に変換します。
Oracle FSGの階層は、次のOracle EBSソース・テーブルから抽出します。
RG_REPORT_AXIS_CONTENTS
このテーブルは、FSGのレポート軸と総勘定元帳のコード組合せとのリレーションシップを定義します。その軸に定義された値範囲内のセグメント値を持つ総勘定元帳のコード組合せは、その軸の子として分類されます。
RG_REPORT_AXIS_SETS
このテーブルは、定義済の各行セットまたはカラム・セットについての情報を格納します。このテーブルには、定義済の行セットまたはカラム・セットごとに1つのレコードが格納されます。各行には、軸セットの識別子、行セットまたはカラム・セットの名前および特定の会計チャートを行セットまたはカラム・セットに割り当てる構造識別子が格納されます。
RG_REPORT_CALCULATIONS
このテーブルには、行セットまたはカラム・セット内の各行または各カラムの計算に使用する計算式が格納されます。行計算の例として、前の5行の合計値の計算などがあります。カラム計算の例として、カラム3の値からカラム4の値を減算した値をカラム5に挿入するなどの計算があります。
たとえば、収入計算書の純収入は、売上総利益から経費総額を減算した計算結果です。階層に変換するときは、純収入が売上総利益と経費総額の親となります。このように、RG_REPORT_CALCULATIONの情報に基づいて階層を導出できます。
次の図は、階層の例を示しています。この例では、最上位階層の純収入ノードに2つの子ノード、経費総額と売上総利益があり、経費総額ノードに2つの子ノード、営業経費と減価償却費があります。
次の図は、収入状態が階層から導出される関係を示しています。
この階層を平坦な階層に変換しW_HIERARCHY_Dに格納すると、次のような形式になります。
表3-11 W_HIERARCHY_Dに格納された平坦階層の例
| 階層名 | HIER1 | HIER2 | HIER3 | HIER4 | HIER20 |
|---|---|---|---|---|---|
|
収入計算書 |
純収入 |
売上総利益 |
売上総利益 |
売上総利益 |
売上総利益 |
|
収入計算書 |
純収入 |
経費総額 |
営業経費 |
営業経費 |
営業経費 |
|
収入計算書 |
純収入 |
経費総額 |
減価償却費 |
減価償却費 |
減価償却費 |
要素テーブルは、総勘定元帳勘定次元テーブル(W_GL_ACCOUNT_D)を介してW_HIERARCHY_Dテーブルに結合されます。
W_GL_ACCOUNT_Dテーブルには6つのフィールド(HIER1_WID、HIER2_WID、HIER3_WID、....、HIER6_WID)があり、それらはW_HIERARCHY_D.row_widに対する外部キーです。このため、総勘定元帳コードの各組合せに、最大6つの階層を構成できます。これら6つのいずれの階層にドリルするかは、W_HIERARCHY_Dへの結合に使用するカラムに基づいて決定されます。たとえば、3番目の階層を使用してドリルする場合、「W_GL_ACCOUNT_D.hier3_wid = W_HIERARCHY_D.row_wid」を使用します。
|
注意: 「+」、「-」、「*」、「/」(加算、減算、乗算、除算)などの算術演算子は、FSG定義から抽出されません。たとえば、「A + B = C」と「A - B = C」の両方とも、次の図で示すように、ノードCが2つの子ノードAとBを持つ同じ階層になります。 |
Oracle FSGレポートのETLプロセスについて
総勘定元帳勘定に対してETLプロセスを実行する前に、参照対象の階層を指定する必要があります。参照するFSG階層を指定するには、$PMServer\SrcFiles(たとえば、INFA_HOME\server\infa_shared\SrcFiles)にあるファイルfile_gl_hierarchy_assignment_ora.csvを使用します。
図3-9 テキスト・エディタで開いたfile_gl_hierarchy_assignment_ora.csvファイル
このファイルでは、会計チャートそれぞれに対して、RG_REPORT_AXIS_SETSテーブルのカラムであるaxis_set_idを使用して、6つのFSG階層を指定できます。これは、その会計チャートに属するコードの組合せに対して、総勘定元帳勘定次元テーブルに格納する行セットまたはカラム・セットの一意のIDです。
DATASOURCE_NUM_IDフィールドでは、構成を適用するデータ・ソースを指定します。ソース・システムが複数ある場合は、1つの会計チャートが同じIDを持つ複数のソース・システムに対応付けられている場合があります。このため、DATASOURCE_NUM_ID値を使用して、それらを区別する必要があります。
たとえば、収入計算書FSGレポートと貸借対照表FSGレポートがあり、その両方の階層構造をデータ・ウェアハウスに入力するとします。Oracle BI Applicationsの前提では、両方のレポートはCHART_OF_ACCOUNTS=101となっている同じ総勘定元帳勘定セットから導出されます。収入計算書のaxis_set_idは1001、貸借対照表のaxis_set_idは1003です。このアプリケーションのDATASOURCE_NUM_IDは2です。
また、2つのレポートに適用される総勘定元帳勘定について、GL_ACCOUNT_DのHIER1カラムを収入計算書の階層構造に、HIER3カラムを貸借対照表の階層構造に関連付ける必要があるとします。
この場合、file_gl_hierarchy_assignment_ora.csvに1行追加して、各フィールドを次のように設定します。
CHART OF ACCOUNTS - 101
HIER1_AXIS_SET_ID - 1001
HIER3_AXIS_SET_ID - 1003
DATASOURCE_NUM_ID - 2
(その他の行の値は空白のままにします。)
この行は、CHART_OF_ACCOUNTS=101およびDATASOURCE_NUM_ID=2となっているすべての総勘定元帳勘定について、そのHIER1からHIER6のカラムに、それぞれaxis_set_idが1001、NULL、1003、NULL、NULL、NULLの階層を割り当てることを示しています。これによって、抽出およびロードの完了後、対象の総勘定元帳勘定行について、HIER1カラムがW_HIERARCHY_Dの収入計算書階層の行IDに対する外部キーとなり、HIER3カラムがW_HIERARCHY_Dの貸借対照表階層の行IDに対する外部キーとなります。
注意: Financial Analyticsで階層をロードするには、Axis_set_idが、file_gl_hierarchy_assignment_ora.csvで指定されている必要があります。
FSGのレポート定義を使用して階層を設定するには:
file_gl_hierarchy_assignment_ora.csvファイルを構成して、CHART_OF_ACCOUNTSそれぞれに対して参照する階層を指定します。
$PMServer\SrcFilesにナビゲートします(たとえば、INFA_HOME\server\infa_shared\SrcFiles)。
テキスト・エディタでfile_gl_hierarchy_assignment_ora.csvを開きます。
分析するセグメントを指定します。
ファイルを保存して閉じます。
DACで、次を実行します。
「Design」ビューに移動して、ドロップダウン・リストから適切なカスタム・コンテナを選択します。
「Subject Areas」タブをクリックし、すべての「Financials」サブジェクトエリアに対するクエリーを実行します。
これらのサブジェクトエリアそれぞれに対して、「Configuration Tags」サブタブで、サブジェクトエリアに次の2つの構成タグがあるかどうか確認します。
Oracle - Extract FSG Hierarchies
Oracle - Extract Value Set Hierarchies
これら2つのタグがあるサブジェクトエリアに対して、次の手順を実行します。
「Inactive」チェック・ボックスの選択を解除して、「Oracle – Extract FSG Hierarchies」タグをアクティブ化します。
「Inactive」チェック・ボックスを選択して、「Oracle – Extract Value Set Hierarchies」タグを非アクティブにします。
「Assemble」をクリックして、サブジェクトエリアを再アセンブルします。
「Execute」ビューの「Execution Plans」タブにナビゲートし、前の手順でアセンブルされたサブジェクトエリアのいずれかが使用されるすべての実行計画を再ビルドします。
実行計画を構築する方法の詳細は、Oracle Business Intelligenceデータ・ウェアハウス管理コンソール・ガイドを参照してください。
総勘定元帳勘定に対して実行計画を実行します。
Oracle BI管理ツールを使用して、Oracle BIリポジトリの物理レイヤーで、テーブルW_HIERARCHY_Dに対して、追加の別名を作成するか、または既存の別名の名前を変更します。
たとえば、収入計算書階層を作成する場合は、テーブルW_HIERARCHY_Dに対して追加の別名Dim_IncomeStatement_FSGHierarchy_Dを作成します。
Oracle BI管理ツールを使用して、Oracle BIリポジトリの物理レイヤーで、次のように前述の手順で作成した新しい別名から物理レイヤーに結合を作成します。
収入計算書の場合は、ファイルfile_gl_hierarchy_assignment_ora.csvで指定したHIER1からHIER6のいずれかのカラムに収入計算書階層を結合します。
この場合は、Dim_W_GL_ACCOUNT_D.HIER1_WID = Dim_IncomeStatement_FSGHierarchy_D.ROW_WIDとしてHIER1カラムに結合します。
Oracle BI管理ツールを使用して、Oracle BIリポジトリのビジネス・モデルおよびマッピング・レイヤーで、新しい別名を使用して追加の次元を作成します。
収入計算書階層の場合は、新しい論理テーブルDim_IncomeStatement_FSGHierarchy_Dを作成し、物理レイヤーでソースとしてDim_IncomeStatement_FSGHierarchy_Dを選択します。物理テーブルのROW_WID、HIER_CODEおよびHIER1~HIER20(名前とコードの両方)を論理キーにマップします。
次に、論理テーブルでHIER_CODEを1001(収入計算書階層のAxis_set_id)に設定し、論理テーブルの出力を収入計算書階層にのみ抑制します(論理テーブル「Dim_IncomeStatement_FSGHierarchy_D」を右クリックして、「プロパティ」→「ソース」タブ→「Dim_IncomeStatement_FSGHierarchy_D」を選択し、「編集」ボタンをクリックして「コンテンツ」タブを選択し、WHERE句の使用…テキスト・ボックスに「"Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_HIERARCHY_D_FSG1"."HIER_CODE" =1001」と入力します)。
このプロセスの詳細は、Oracle Business Analytics Warehouseに事前インストールされているサンプル論理テーブル「Dim - FSG Hierarchy 1」を参照してください。
Oracle BI管理ツールを使用して、Oracle BIリポジトリのビジネス・モデルおよびマッピング・レイヤーで、前述の手順で作成した論理テーブルに基づいて新しい次元を作成します。
例として「FSG Hierarchy 1」を参照してください。
ビジネス・モデルとマッピング・レイヤーで、論理階層テーブル「Dim - FSG Hierarchy1」に論理結合されている論理要素テーブルをすべて検索します。次のように、作成した新しい論理階層次元とこれらの論理要素の間に同様の論理結合を作成する必要があります。
論理要素テーブルそれぞれで、論理テーブル・ソースを開き、「コンテンツ」タブに移動します。集計コンテンツで、「マップされていないものを表示」チェック・ボックスを選択します。前の手順で作成したすべての階層が表示されます。これらの階層それぞれに対して、論理レベルを「詳細」に選択します。
「ビジネス・モデル図」で、新しい論理階層テーブルそれぞれと論理要素それぞれの間に新しい論理結合を作成します。結合において、基数は、次元側で(0,1)、要素側でNであることを確認します。
Oracle BI管理ツールを使用して、Oracle BIリポジトリのプレゼンテーション・レイヤーで、新しい階層をプレゼンテーション・フォルダにドラッグします。
注意: プレゼンテーション・レイヤーの階層名は、必要に応じて変更できます。
この項では、Oracle EBSソース・システムに配置されているOracle BI Applicationsに適用される追加の構成手順について説明します。内容は、次のとおりです。
製造/購入インジケーターは、製品の材料が自社で製造されたものか、他社から購入したものかを指定します。デフォルトでは、製造/購入インジケーターは、M(つまり、自社製造)に対して1、B(つまり他社から購入)に対して2に設定されています。組織がこれらのインジケーター・コードを使用する場合、デフォルトのETLマッピングを変更する必要はありません。
組織が別のインジケーター・コードを使用する場合、この項に用意されている手順に従って、マップレットmplt_SA_ORA_ProductDimensionのインジケーター・マッピングを変更する必要があります。たとえば、インジケーター・コードを製造の場合は0、購入の場合は1に設定できます。
製造/購入インジケーターを構成する手順は次のとおりです。
Informatica PowerCenter Designerで、該当するOracle EBSアダプタ(たとえば、SDE_ORAVersion_Adaptor)を開き、マップレット・サブフォルダを展開します。
Mapplet Designerを使用して、マップレットmplt_SA_ORA_ProductDimensionを編集します。
「Expression transformation EXP_PRODUCTS」をダブルクリックして、「Edit Transformations」ダイアログを開き、「Ports」タブを表示します。
「Expression Editor」を使用して、EXT_MAKE_BUY_INDポートの式を編集します。
たとえば、インジケーター・コードを製造に対して0、購入に対して1にする場合、式を次のように変更します。
DECODE (INP_PLANNING_MAKE_BUY_CODE,0,'M',1,'B',NULL)
マップレットを確認し、変更内容をリポジトリに保存します。
この項では、PeopleSoftソース・システムに配置されているOracle BI Applicationsに適用される構成手順について説明します。
この項は、次の項目を含んでいます。
この項では、データの完全ロード前に、PeopleSoftソース・システムに配置されているOracle BI Applicationsに適用する必要がある構成手順について説明します。内容は次のとおりです。
Oracle Business Analytics Warehouseの総勘定元帳勘定次元は、チャートフィールドの組合せの単位です。PeopleSoft Financialsは、総勘定元帳勘定(勘定科目、代替勘定科目、営業単位、部門など)用にいくつかのチャートフィールドを用意しています。ETLプログラムは、使用したこれらのチャートフィールドのあらゆる組合せを抽出し、これらのチャートフィールドそれぞれを総勘定元帳勘定次元に個別に格納します。これは、使用したチャートフィールドの組合せを次のPeopleSoft勘定エントリ・テーブルから抽出します。
PS_VCHR_ACCTG_LINES(買掛金)
PS_ITEM_DST(売掛金)
PS_BI_ACCT_ENTRY(請求)
PS_CM_ACCTG_LINE(費用)
PS_JRNL_LN(総勘定元帳)
Oracle Business Analytics Warehouseの総勘定元帳勘定次元(W_GL_ACCOUNT_D)は、柔軟性のある汎用データ・モデルを提供し、最大30個のチャートフィールドに対応します。これらは、ACCOUNT_SEG1_CODE、ACCOUNT_SEG2_CODEからACCOUNT_SEG30_CODEまでの汎用カラムに格納されます。今後これらをセグメントと呼びます。これらのカラムは、PeopleSoftアプリケーションで使用される実際のチャートフィールド値を格納します。
PeopleSoftチャートフィールドのマップ
PeopleSoftチャートフィールドを汎用セグメントにマップするためのCSVファイルが用意されています。このファイルを使用して、PeopleSoftアプリケーションのチャートフィールドをポピュレートするセグメントを指定します。このファイルは、file_glacct_segment_config_psft.csvと呼ばれ、$PMServer\SrcFilesディレクトリ(たとえば、INFA_HOME\server\infa_shared\SrcFiles)にあります。
このファイルの最初の行はヘッダー行ですので変更しないでください。ファイルの2行目に、チャートフィールドとセグメントのマッピング関係を指定します。カラムROW_IDの値は'1'にハードコード化されており、変更の必要はありません。
このファイルには、SEG1、SEG2からSEG30までの30カラムが含まれています。チャートフィールドでサポートされる値の1つを指定することによって、各カラムにポピュレートする必要があるチャートフィールドを指定する必要があります。次のリストに、PeopleSoftアプリケーションで現在サポートされているチャートフィールドを示します。
|
注意: これらの値では大文字と小文字が区別されます。次のリストに示される値を正確に指定する必要があります。 |
勘定科目
代替勘定科目
業務ユニット
資金コード
部門
プログラム・コード
クラス・フィールド
予算参照
製品
プロジェクト
関係会社
資金関係会社
業務ユニット関係会社
チャートフィールド1
チャートフィールド2
チャートフィールド3
統計コード
PCビジネス・ユニット
アクティビティID
分析タイプ
リソース・タイプ
リソース・カテゴリ
リソース・サブカテゴリ
|
注意: このCSVファイルには、マップ対象のチャートフィールドのみを含める必要があります。 |
プロジェクト固有のチャートフィールドの構成 プロジェクトに関係する6つのチャートフィールド(PCビジネス・ユニット、アクティビティID、分析タイプ、リソース・タイプ、リソース・カテゴリおよびリソース・サブカテゴリ)を使用するには、DACパラメータ$$INCLUDE_PROJ_CHARTFIELDSを「Y」に設定する必要があります。分析で6つのプロジェクト・チャートフィールドを使用する場合のみ、この手順を実行する必要があります。
プロジェクト固有のチャートフィールドをDACに含めるには:
DACで、「Design」ビューに移動して、適切なカスタム・コンテナをドロップダウン・リストから選択します。
「Source System Parameters」タブを表示します。
パラメータ$$INCLUDE_PROJ_CHARTFIELDSを「Y」に設定します。
完全ETLを実行します。
これらのチャートフィールドを使用しない場合は、DACのパラメータ$$INCLUDE_PROJ_CHARTFIELDSをデフォルト値の「N」に設定します。
|
注意: このパラメータ値を変更する場合は、常に完全ロードのETLを実行する必要があります。 |
この項では、総勘定元帳勘定をグループ勘定コードにマップする方法について説明します。項目は次のとおりです。
総勘定元帳勘定の設定の概要: 第3.3.1.2.1項「総勘定元帳勘定のグループ勘定コードへのマッピングの概要」を参照してください。
グループ勘定コードへの総勘定元帳勘定のマップ方法の説明: 第3.3.1.2.2項「総勘定元帳勘定番号のグループ勘定コードへのマップ方法」を参照してください。
Oracle BIリポジトリへのグループ勘定コード指標の追加方法を説明する例: 第3.3.1.2.3項「グループ勘定コード指標のOracle BIリポジトリへの追加例」を参照してください。
|
注意: 総勘定元帳勘定番号は、グループ勘定コード(またはドメイン値)にマップされている必要があります。これは、総勘定元帳レポート・レイヤーの指標でこれらの値が使用されるためです。総勘定元帳勘定番号のドメイン値の一覧は、Oracle Business Analytics Warehouseデータ・モデル・リファレンスを参照してください。 |
詳細は、第3.1.5項「すべてのソース・システムに対する総勘定元帳勘定のグループ勘定コードへのマッピングについて」も参照してください。
グループ勘定コードの構成は、総勘定元帳および利益率モジュールの指標の大部分の精度を決定するため、Financial Analyticsの構成において重要な手順です。グループ勘定は財務諸表コードと組み合されて総勘定元帳の調整処理にも使用され、補助元帳データが総勘定元帳仕訳エントリに対して調整されます。このトピックの詳細は、この項の後で説明します。
PeopleSoft General Ledgerの勘定を、特定のグループ勘定コードに分類できます。GROUP_ACCT_NUMフィールドは、総勘定元帳勘定の種類を表します。
$PMServer\SrcFilesディレクトリにある次の構成ファイルを使用して、総勘定元帳勘定を設定します。
file_group_acct_names.csv: このファイルは、グループ勘定名および対応するグループ勘定コードを指定します。
file_group_acct_codes_psft.csv: このファイルは、総勘定元帳勘定をグループ勘定コードにマップします。
file_grpact_fstmt.csv: このファイルは、財務諸表項目コートをグループ勘定コードにマップします。
データをロードする前に、勘定の値のマップがこれら3つの構成ファイル間で整合性があることを確認する必要があります。図3-10は、file_group_acct_names.csvのGROUP_ACCOUNT_NUMフィールドがfile_group_acct_codes_psft.csvのGROUP_ACCT_NUMフィールドおよびfile_grpact_fstmt.csvのGROUP_ACCT_NUMフィールドにどのようにマップされている必要があるかを示しています。
例には、現金勘定、給与勘定などが含まれています。グループ勘定コードのドメイン値の一覧は、Oracle Business Analytics Warehouseデータ・モデル・リファレンスを参照してください。グループ勘定コードの構成は、データの抽出時とフロントエンドでのレポート作成時に使用されます。たとえば、グループ勘定コードの構成は、利益率分析(収入計算書)と総勘定元帳分析の両方で頻繁に使用されます。勘定の割当てロジックは、file_group_acct_codes_ora.csvファイルで指定されます。このファイルは、$PMServer\SrcFilesディレクトリ(たとえば、INFA_HOME\server\infa_shared\SrcFiles)にあります。
表3-12 file_group_acct_codes_psft.csvファイルのレイアウト
| BUSINESS_UNIT | FROM_ACCT | TO_ACCT | GROUP_ACCT_NUM |
|---|---|---|---|
|
AUS01 |
101010 |
101099 |
AP |
|
AUS01 |
131010 |
131939 |
AR |
|
AUS01 |
152121 |
152401 |
COGS |
|
AUS01 |
171101 |
173001 |
OTHER |
|
AUS01 |
240100 |
240120 |
REVENUE |
|
AUS01 |
251100 |
251120 |
TAX脚注 1 |
脚注 1 Financial AnalyticsのOracle PeopleSoftアダプタは税金ベース要素(W_TAX_XACT_F)をサポートしません。
表3-12の最初の行では、ビジネス・ユニットがAUS01で、勘定番号101010から101099のすべての勘定がAPに割り当てられています。各行で、指定されたビジネス・ユニットの指定された勘定番号範囲内のすべての勘定がマップされます。勘定番号の新しいグループを割り当てる必要がある場合は、file_group_acct_codes_psft.csvファイルで勘定番号の新しいグループに総勘定元帳勘定を割り当てることができます。
file_grpact_fstmt.csvファイルによって、グループ勘定コードと財務諸表項目コードとのリレーションシップが指定されます。表3-13は、グループ勘定コードがマップする必要がある財務諸表項目コードおよび関連のベース要素テーブルを示しています。
表3-13 財務諸表項目コードおよび関連のベース要素テーブル
| 財務諸表項目コード | ベース要素テーブル |
|---|---|
|
AP |
買掛金ベース要素(W_AP_XACT_F) |
|
AR |
売掛金ベース要素(W_AR_XACT_F) |
|
COGS |
売上原価ベース要素(W_GL_COGS_F) |
|
REVENUE |
収益ベース要素(W_GL_REVN_F) |
|
TAX |
税金ベース要素(W_TAX_XACT_F)脚注 1 |
|
OTHERS |
総勘定元帳仕訳ベース要素(W_GL_OTHER_F) |
脚注 1 Financial AnalyticsのOracle PeopleSoftアダプタは税金ベース要素(W_TAX_XACT_F)をサポートしません。
総勘定元帳勘定をグループ勘定コードにマップし、そのグループ勘定コードを財務諸表項目コードに関連付けることにより、総勘定元帳勘定番号が財務諸表項目コードに間接的に関連付けられます。この関連付けは、総勘定元帳の調整を実行し、補助元帳データを総勘定元帳仕訳エントリに対して調整する際に重要です。請求書が総勘定元帳に転送された後、総勘定元帳のユーザーは、総勘定元帳でその請求書を調整できます。このシナリオでは、調整金額を補助元帳のベース要素および残高テーブルに確実に反映することが重要です。総勘定元帳でこのような補助元帳のトランザクションを決定するために、調整プロセスでは、財務諸表項目コードが使用されます。
財務諸表項目コードはETLプロセスで使用される内部コードで、補助元帳に対する総勘定元帳の調整プロセス時に総勘定元帳仕訳レコードの処理に使用されます。ETLプロセスによって総勘定元帳仕訳レコードが調整される場合、その仕訳が記入される総勘定元帳勘定に関連付けられている財務諸表項目コードが確認され、その財務諸表項目コードの値を使用して、どのベース要素に対して総勘定元帳仕訳を調整するかが決められます。たとえば、AP財務諸表項目コードに関連付けられている総勘定元帳勘定に記入される総勘定元帳仕訳を調整するときは、買掛金ベース要素テーブル(W_AP_XACT_F)に対して調整され、その要素テーブルに対応する買掛金会計仕訳が検索されます。総勘定元帳勘定がREVENUE財務諸表項目コードに関連付けられている場合は、収益ベース要素テーブル(W_GL_REVN_F)に対して調整され、その要素テーブルに対応する収益会計仕訳が検索されます。
この項では、総勘定元帳勘定番号をグループ勘定コードにマップする方法を説明します。
|
注意: 新しいグループ勘定コードをfile_group_acct_codes_psft.csvファイルに追加する場合、指標をOracle BIリポジトリに追加する必要もあります。詳細は、第3.3.1.2.3項「グループ勘定コード指標のOracle BIリポジトリへの追加例」を参照してください。 |
PeopleSoft総勘定元帳勘定番号をグループ勘定コードにマップするには:
テキスト・エディタを使用して、$PMServer\SrcFilesディレクトリ(たとえば、INFA_HOME\server\infa_shared\SrcFiles)にあるfile_group_acct_codes_psft.csvファイルを開きます。
マップする総勘定元帳勘定番号それぞれに対して、次のフィールドを含むファイルに新しい行を作成します。
| フィールド名 | 説明 |
|---|---|
| BUSINESS_UNIT | ビジネス・ユニットのID。 |
| FROM ACCT | 種類別勘定の範囲の下限。この値は総勘定元帳勘定の種類別勘定のセグメントに基づきます。 |
| TO ACCT | 種類別勘定の範囲の上限。この値は総勘定元帳勘定の種類別勘定のセグメントに基づきます。 |
| GROUP_ACCT_NUM | このフィールドは、file_group_acct_names.csvファイルで指定された総勘定元帳勘定のグループ勘定コードを表します。買掛金の場合にはAP、現金勘定の場合にはCASH、給与勘定の場合にはGEN PAYROLLなどです。 |
次に例を示します。
AUS01, 1110, 1110, CASH AUS01, 1210, 1210, AR AUS01, 1220, 1220, AR
|
注意: オプションで、CSVファイルの未使用の行を削除できます。 |
file_group_acct_codes_psft.csvファイルで指定する値は、file_group_acct_names.csvファイルおよびfile_grpact_fstmt.csvファイルで指定する値と整合性を保つようにしてください。
例については、図3-10「PeopleSoftのグループ勘定を構成する構成ファイル」を参照してください。
CSVファイルを保存して閉じます。
新しいグループ勘定コードをfile_group_acct_codes_psft.csvファイルに追加する場合(第3.3.1.2.2項「総勘定元帳勘定番号のグループ勘定コードへのマップ方法」を参照)、指標をOracle BIリポジトリに追加して、新しいグループ勘定コードを公開する必要もあります。この例は、Oracle BI管理ツールを使用して、グループ勘定コードの指標を追加する方法を示しています。
この例では、「Payroll」という新しいグループ勘定コードがあり、新しい指標を「Payroll Expense」というプレゼンテーション・レイヤーに追加します。
論理テーブル「Fact – Fins – GL Other Posted Transaction」の新しい指標を追加するには:
管理ツールを使用して、OracleBIAnalyticsApps.rpdを開きます。
OracleBIAnalyticsApps.rpdファイルは次の場所にあります。
ORACLE_INSTANCE\bifoundation\OracleBIServerComponent\coreapplication_ obisn\repository
「ビジネス・モデルとマッピング」レイヤーで、次を実行します。
「Payroll Expense」という論理カラムを論理テーブル「Fact – Fins – GL Other Posted Transaction」に作成します。
たとえば、「Core\Fact - Fins - GL Other Posted Transaction」オブジェクトを右クリックし、「新規オブジェクト」→「論理列」を選択し、「論理列」ダイアログを表示します。「名前」フィールドで「Payroll Expense」を指定します。
「集計」タブを表示し、「デフォルトの集計ルール」ドロップダウン・リストで「合計」を選択します。
「OK」をクリックして詳細を保存し、ダイアログを閉じます。
「Core\Fact - Fins - GL Other Posted Transaction\Sources」フォルダを展開し、「Fact_W_GL_OTHER_GRPACCT_FSCLYR_A」ソースをダブルクリックして、「論理表ソース」ダイアログを表示します。
「列マッピング」タブを表示します。
「マップされていない列の表示」を選択します。
「Payroll Expense」式を探し、「式ビルダー」ボタンをクリックして、式ビルダーを開きます。
式ビルダーを使用して、次のSQL文を指定します。
CASE WHEN "Oracle Data Warehouse"."Catalog"."dbo". "Dim_W_GL_GROUP_ACCOUNT_D"."GROUP_ACCOUNT_NUM" = 'PAYROLL' THEN "Oracle Data Warehouse"."Catalog"."dbo". "Fact_Agg_W_GL_OTHER_GRPACCT_FSCLYR_A"."OTHER_GLOBAL1_AMT" ELSE NULL END
CASE条件は、新しいグループ勘定コード「Payroll」を参照し、これをフィルタとして使用します。
論理テーブル・ソースそれぞれに対して、手順dからhを繰り返します。論理テーブル・ソースに対応する要素テーブルを使用して、各論理テーブル・ソースに対して、手順hで適切に式を変更します。
手順dからhは、論理テーブル・ソースそれぞれに対して繰り返す必要があります。これは、この例では、この論理テーブルの要素テーブルおよび集約テーブルに対して複数の論理テーブル・ソースがあるためです。対応する要素テーブルを使用して、各論理テーブル・ソースに対して、手順hで適切に式を変更します。
これらの詳細を保存します。
エンド・ユーザーのダッシュボードおよびレポートで新しいリポジトリ・オブジェクトを公開するには、新しいオブジェクトをビジネス・モデルおよびマッピング・レイヤーからプレゼンテーション・レイヤーの該当するフォルダにドラッグします。
論理テーブル「Fact – Fins – GL Balance」の新しい指標を追加するには:
管理ツールを使用して、OracleBIAnalyticsApps.rpdを開きます。
OracleBIAnalyticsApps.rpdファイルは次の場所にあります。
ORACLE_INSTANCE\bifoundation\OracleBIServerComponent\coreapplication_ obisn\repository
「ビジネス・モデルとマッピング」レイヤーで、次を実行します。
「Payroll Expense」という論理カラムを論理テーブル「Fact – Fins – GL Balance」に作成します。
たとえば、「Core\Fact – Fins – GL Balance」オブジェクトを右クリックし、「新規オブジェクト」→「論理列」を選択し、「論理列」ダイアログを表示します。「名前」フィールドで「Payroll Expense」を指定します。
「列ソース」タブで「式を使用して既存の列から派生」を選択します。
「式ビルダー」ボタンをクリックして、式ビルダーを表示します。
式ビルダーを使用して、次のSQL文を指定します。
FILTER("Core"."Fact - Fins - GL Balance"."Activity Amount"
USING "Core"."Dim - GL Account"."Group Account Number" = 'Payroll')
CASE条件は、新しいグループ勘定コード「Payroll」を参照します。
これらの詳細を保存します。
エンド・ユーザーのダッシュボードおよびレポートで新しいリポジトリ・オブジェクトを公開するには、新しいオブジェクトをビジネス・モデルおよびマッピング・レイヤーからプレゼンテーション・レイヤーの該当するフォルダにドラッグします。
注意: グループ勘定コードと財務諸表項目コードの概要は、第3.3.1.2項「PeopleSoft総勘定元帳勘定のグループ勘定コードへのマッピングについて」を参照してください。
総勘定元帳の種類別勘定が間違ったグループ勘定コードにマップされると、不適切な会計エントリが要素テーブルに挿入される可能性があります。たとえば、APグループ勘定コードに分類されるはずの種類別勘定1210が、ARグループ勘定コードに間違って分類されているとします。この場合、ETLプログラムは勘定1210に対してすべての総勘定元帳の仕訳明細を記入し、これらの総勘定元帳の仕訳明細を売掛金要素テーブル(W_AR_XACT_F)の補助元帳会計レコードに対して調整しようとします。これらの総勘定元帳の仕訳明細は売掛金とは関係ないため、ETLプログラムは、これらの総勘定元帳の仕訳明細に対応する補助元帳会計レコードを見つけることができません。この場合、ETLプログラムにより、これらの総勘定元帳の仕訳明細が、総勘定元帳システムによる売掛金勘定に対する記入時に直接作成された手動仕訳エントリであると判断され、その結果、売掛金要素テーブルに手動レコードが挿入されます。このプロセス全体を、総勘定元帳の調整プロセスと呼びます。
売掛金要素テーブルのこれらの手動エントリを元に戻すには、Oracle BI Applicationsに付属の「Group Account Number Clean Up」プログラムを使用します。このプログラムは、要素テーブル(この場合は、売掛金要素テーブル)の手動エントリを元に戻し、総勘定元帳の調整プロセスの再実行を試みます。file_group_acct_codes_psft.csvファイルで種類別勘定1210がAPグループ勘定コードに割当て変更されていれば、ETLプログラムは、AP要素(W_AP_XACT_F)で対応する補助元帳会計レコードを探します。
|
注意: 「Financials – Group Account Number Clean Up」サブジェクトエリアは、グループ勘定コードの割当てを修正する必要がある場合のみ使用してください。このサブジェクトエリアは、標準のFinancials実行プランに含まないでください。これは、個別に実行する必要があります。 |
グループ勘定を修正するには:
入力CSVファイルfile_group_acct_codes_psft.csv内の、グループ勘定に対する総勘定元帳の種類別勘定のマッピングを修正します。
たとえば、修正前のCSVファイルに、次の値が指定されているとします。
BUSINESS_UNIT = AUS01
FROM ACCT = 1110
TO ACCT = 1110
GROUP_ACCT_NUM = CASH
勘定1210の元の分類先がAPグループ勘定コードであるとすると、修正後のCSVファイルでは、この総勘定元帳の種類別勘定とグループ勘定のマッピング値は次のようになります。
BUSINESS_UNIT = AUS01
FROM ACCT = 1210
TO ACCT = 1210
GROUP_ACCT_NUM = AR
DACで、次を実行します。
「Design」ビューに移動して、ドロップダウン・リストから適切なカスタム・コンテナを選択します。
Subject Areasタブを表示します。
「Financials – General Ledger」サブジェクトエリアに対するクエリーを実行します。
「Configuration Tags」サブタブを表示し、次のいずれの構成タグが「Inactive」にマークされているかを確認します。
- Financials – Calculate GL Balance
- Oracle – Extract GL Balance
デフォルトでは、「Financials – Calculate GL Balance」が「Inactive」にマークされています。
「Financials – Group Account Number Clean Up」サブジェクトエリアに対するクエリーを実行し、次の手順を実行します。
- 前の手順で、構成タグ「Financials – Calculate GL Balance」が「Inactive」にマークされていた場合は、「Financials – Calculate GL Balance Reverse」も「Inactive」にマークします。
- 前の手順で、「Oracle – Extract GL Balance」が「Inactive」にマークされていた場合は、「Financials – Calculate GL Balance Reverse」をアクティブにマークします(つまり、「Inactive」チェック・ボックスを選択解除)。
前の手順で変更を行う必要がある場合、「Subject Areas」タブを表示し、「Financials – Group Account Number Clean Up」というサブジェクトエリアを再アセンブルする必要があります。
「Financials – Group Account Number Clean Up」というサブジェクトエリアのロードに使用している実行プランを再構築して実行します。
Oracle Business Intelligence Applicationsでは、これらのすべてのセグメントに対して階層がサポートされます。いずれかのチャートフィールドに対してPeopleSoftでツリーを作成した場合、それらのツリーをOracle Business Analytics Warehouseの階層に抽出して、階層の任意のレベルでファクトを分析できます。ツリーの抽出については、第3.3.2.2項「部門ツリーの構成」も参照してください。また、ツリーのRPDファイルの階層としての包含の詳細は、第16.4項「製品カテゴリ階層の設定方法」も参照してください。
総勘定元帳残高集計 Oracle Business Analytics Warehouseデータ・モデルには、すべての総勘定元帳勘定の総勘定元帳残高を格納する要素テーブル(W_GL_BALANCE_F)があります。パフォーマンスを向上させる目的で、この要素テーブルに加えて、選択した最大6つのセグメントの総勘定元帳残高を格納する集計テーブル(W_GL_BALANCE_A)が、この要素テーブルの縮小版として用意されています。集計テーブルに必要なセグメントの数および必要なセグメントを構成できます。この構成は、file_glacct_segment_config_psft.csvファイルの3行目で実行します。集計テーブルに含めるセグメントのカラムに、値「Y」を指定します。
|
注意: ファイルで最大6個の「Y」を指定できます。6個すべてを使用する必要はありません。たとえば、3つのセグメントのみを集計する場合は、3つの「Y」のみ指定が必要です。 |
CSVファイルの構成例 file_glacct_segment_config_psft.csvファイルの構成例として、次のシナリオを考えます。
システムで4つのチャートフィールド(勘定科目、代替勘定科目、営業単位および部門)を使用します。4つのチャートフィールドの内3つのみ(勘定科目、営業単位、部門)でデータを分析する必要があり、通常、勘定科目と部門の組合せで総勘定元帳残高を表示すると仮定します。ときどき3つすべてのチャートフィールドの組合せとして総勘定元帳残高を表示する必要があります。このシナリオでは、CSVファイルは、表3-14に示す値のようになります。
この構成によって、W_GL_ACCOUNT_Dでは、勘定科目チャートフィールドの値がSEGMENT1カラムに、営業単位チャートフィールドの値がSEGMENT2カラムに格納されます。総勘定元帳残高の集計テーブルのW_GL_BALANCE_Aには、勘定科目チャートフィールドと部門チャートフィールドの一意の組合せごとに総勘定元帳残高が格納されます。
この項では、PeopleSoftに適用される追加の構成手順について説明します。内容は次のとおりです。
HRMSでのみリソースを管理するかFSCMで非従業員のみを作成し、従業員に対するHRMS統合を行う場合、統合ブローカーを実行して、HRMSテーブルとFSCMテーブルを同期させる必要があります。従業員および非従業員のソース・データに関するPeopleSoft Resource Managementの実装は、PeopleSoftリソース管理9.0 PeopleBookを参照してください。
Oracle Business Intelligence Applicationsでは、PeopleSoft部門ベースの組織階層がサポートされます。ETLマッピングは、PeopleSoft部門ツリーを抽出して平坦化し、平坦化された組織階層にします。ETLパラメータでも、SetIDおよびツリー名によって部門ツリーを平坦化できます。
サポートされるツリー構造
Oracle HR Analyticsは、winterツリーとsummerツリーの構造タイプをサポートします。winterツリーにはノードがありますが、詳細の値はありません。summerツリーには、ノードと詳細の値の両方があります。ノードは、レベルにグループ化され、Oracle HR Analyticsは、厳密に実施されたツリー・レベル(同じレベルのすべてのノードがエンティティの同じタイプを表す)のみをサポートします。ツリー構造の詳細は、PeopleSoftのドキュメントを参照してください。
Oracle HR Analyticsが部門ツリーを処理する方法
PeopleSoftの部門および関連する部門ツリーは、組織次元(W_INT_ORG_D)および平坦化された組織階層構造(W_INT_ORG_DH)としてOracle HR Analyticsでサポートされています。
Oracle HR Analyticsは、レベル0から14まで最大15レベルまでツリーを平坦化します(レベル0が最下位ノード)。ツリー平坦化ETLプロセス中、各ツリー・ノードは、ツリーの最上位ノードからのパスとともにW_INT_ORG_DHに挿入されます。ノードが15レベルより少ない場合、ノード値は、そのノード・レベルの下のすべてのレベルで繰り返されます。
部門ツリーのポピュレート方法の例
次の図および表は、部門ツリーがW_INT_ORG_DおよびW_INT_ORG_DHにポピュレートされる方法の例を示しています。この例のツリー名は、「NA Sales」で、setIDは「Share」です。
部門テーブル(PS_DEPT_TBL)は、内部組織次元テーブル(W_INT_ORG_D)に次のようにポピュレートされます。
表3-15 PS_DEPT_TBLがW_INT_ORG_Dにポピュレートされる方法
| ROW_ID | ORG_NUM | ORG_NAME | HR_ORG_FLAG |
|---|---|---|---|
|
1 |
A |
American Sales |
Y |
|
2 |
B |
West Region |
Y |
|
3 |
C |
New England |
Y |
|
4 |
D |
Massachusetts |
Y |
|
5 |
E |
California |
Y |
|
6 |
F |
Boston |
Y |
部門ツリーは、内部組織階層テーブルW_INT_ORG_DHに次のようにポピュレートされます。
表3-16 PS_DEPT_TBLがW_INT_ORG_DHにポピュレートされる方法
| ORG_WID | ORG_HIER(1-11)_NUM | ORG_HIER(1-11)_NAME | ORG_HIER12_NUM | ORG_HIER12_NAME | ORG_HIER13_NUM | ORG_HIER13_NAME | ORG_TOP_NUM | ORG_TOP_NAME | HIERARCHY_NAME | W_HIERARCHY_CLASS | FIXED_HIER_LEVEL | HR_ORG_FLG |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
1 |
A |
North American Sales |
A |
North American Sales |
A |
North American Sales |
A |
North American Sales |
Share ~NA Sales |
HR Org |
14 |
Y |
|
2 |
B |
West Region |
B |
West Region |
B |
West Region |
A |
North American Sales |
Share ~NA Sales |
HR Org |
13 |
Y |
|
3 |
C |
New England |
C |
New England |
C |
New England |
A |
North American Sales |
Share ~NA Sales |
HR Org |
13 |
Y |
|
4 |
D |
Massachusetts |
D |
Massachusetts |
C |
New England |
A |
North American Sales |
Share ~NA Sales |
HR Org |
12 |
Y |
|
5 |
E |
California |
E |
California |
B |
West Region |
A |
North American Sales |
Share ~NA Sales |
HR Org |
11 |
Y |
|
6 |
F |
Boston |
D |
Boston |
C |
New England |
A |
North American Sales |
Share ~NA Sales |
HR Org |
12 |
Y |
summerツリーの平坦化方法
ツリー平坦化プロセスは、summerツリーもサポートしています。summerツリーは、詳細範囲があるツリーです。ツリーに最下位ノード用に指定された詳細範囲がある場合、抽出プロセスで多数のノードが、指定されたノード範囲の部門に対応するW_INT_ORG_HIERに作成されます。
ツリーがsummerツリーの場合、ETLソース修飾子から返されるデータの単位は、指定された範囲ごとに1行です。ツリーの最下位の親ノードは、複数の範囲を作成できるため、複数回繰り返すことができます。次の図は、summerツリーの平坦化方法を示しています。
詳細範囲は、内部組織次元テーブルW_INT_ORG_Dに次のようにポピュレートされます。
表3-17 詳細範囲がW_INT_ORG_Dにポピュレートされる方法
| ROW_WID | ORG_NUM | ORG_NAME | HR_ORG_FLG |
|---|---|---|---|
|
7 |
2334 |
Appliances |
Y |
|
8 |
2340 |
Home Theater |
Y |
|
9 |
3001 |
MP3 Players |
Y |
summerツリーの詳細範囲は、W_INT_ORG_DHに次のようにポピュレートされます。
表3-18 詳細範囲がW_INT_ORG_DHにポピュレートされる方法
| ORG_WID | ORG_HIER (1-10) | ORG_HIER11 | ORG_HIER12 | ORG_HIER13 | ORG_TOP | FIXED_HIER_LVL | HR_ORG_FLG |
|---|---|---|---|---|---|---|---|
|
7 |
Boston |
Boston |
Massachusetts |
New England |
North American Sales |
11 |
Y |
|
8 |
Boston |
Boston |
Massachusetts |
New England |
North American Sales |
10 |
Y |
|
9 |
Boston |
Boston |
Massachusetts |
New England |
North American Sales |
10 |
Y |
平坦化された内部組織階層のOracle BI Enterprise Editionでの表示方法
Oracle HR Analytics Presentation Catalogには、15レベルの従業員組織があります。従業員組織階層レベルは、内部組織次元および階層テーブルに次のようにマップされます。
| RPDプレゼンテーション・レイヤー | 物理テーブル・マッピング |
|---|---|
| 従業員組織番号 | W_INT_ORG_D.ORG_NUM |
| 従業員組織名 | W_INT_ORG_D.ORG_NAME |
| 従業員組織階層名 | W_INT_ORG_DH.HIERARCHY_NAME |
| 階層バージョン | W_INT_ORG_DH.HIERARCHY_VERSION |
| 従業員組織階層1 | W_INT_ORG_DH.HIER1_NUM |
| 従業員組織階層2 | W_INT_ORG_DH.HIER2_NUM |
| 従業員組織階層3 | W_INT_ORG_DH.HIER3_NUM |
| 従業員組織階層4 | W_INT_ORG_DH.HIER4_NUM |
| 従業員組織階層5 | W_INT_ORG_DH.HIER5_NUM |
| 従業員組織階層6 | W_INT_ORG_DH.HIER6_NUM |
| 従業員組織階層7 | W_INT_ORG_DH.HIER7_NUM |
| 従業員組織階層8 | W_INT_ORG_DH.HIER8_NUM |
| 従業員組織階層9 | W_INT_ORG_DH.HIER9_NUM |
| 従業員組織階層10 | W_INT_ORG_DH.HIER10_NUM |
| 従業員組織階層11 | W_INT_ORG_DH.HIER11_NUM |
| 従業員組織階層12 | W_INT_ORG_DH.HIER12_NUM |
| 従業員組織階層13 | W_INT_ORG_DH.HIER13_NUM |
| 従業員組織階層14 | W_INT_ORG_DH.HIER14_NUM |
次の表では、HR組織次元および次元階層テーブルについて説明します。
| テーブル名 | 説明 | ソース・テーブル |
|---|---|---|
| W_INT_ORG_DS | HR組織次元およびステージング・テーブル | PS_DEPT_TBL |
| W_INT_ORG_D | HR組織次元テーブル | W_INT_ORG_DS |
| W_INT_ORG_DHS | HR組織次元階層ステージング・テーブル | PSTREESTRCT
PSTREENODE PSTREELEVEL |
| W_INT_ORG_DH | HR組織次元階層テーブル | W_INT_ORG_DHS |
表3-19は、ツリーの抽出およびロードの処理に使用する一時テーブルおよび対応するセッションを示しています。
表3-19 ツリーを抽出しロードするための一時テーブルおよび対応するセッション
| シーケンス | 一時テーブル名 | セッション |
|---|---|---|
|
シーケンス1 |
W_PSFT_INT_ORG_DEPT_DH_TMP |
SDE_PSFT_Stage_InternalOrganizationDimension_DepartmentHierarchy_GetDept |
|
シーケンス2 |
W_PSFT_INT_ORG_TREE_TMP |
|
|
シーケンス3 |
W_PSFT_INT_ORG_VERT_DH_TMP |
SDE_PSFT_Stage_InternalOrganizationDimension_CompanyHierarchy_GetHierarchyLevel |
|
シーケンス4 |
W_PSFT_INT_ORG_DTLRGE_DH_TMP |
SDE_PSFT_Stage_InternalOrganizationDimension_CompanyHierarchy_DeriveRange |
|
シーケンス5 |
W_PSFT_INT_ORG_FLAT_DH_TMP |
SDE_PSFT_Stage_InternalOrganizationDimension_CompanyHierarchy_Flatten |
Oracle Business Intelligence Applicationsは、PeopleSoft部門組織階層とビジネス・ユニットベースの組織階層の両方をサポートします。ETLマッピングは、PeopleSoft部門ツリーまたはビジネス・ユニット・ツリーを抽出して平坦化し、平坦化された組織階層にします。ETLパラメータでも、SetIDおよびツリー名によって部門ツリーまたはビジネス・ユニット・ツリーを平坦化できます。
DACは、パラメータ$$TREE_SETID_NAME_LISTを提供して、ツリー平坦化ETLプロセスを構成します。$$TREE_SETID_NAME_LISTは、2つのPeopleSoftツリー・パラメータ(SETIDとTREE_NAME)をサポートします。
PeopleSoftツリー・パラメータEFFDTには、DACパラメータは提供されません。ツリー抽出マッピングには、組込みロジックがあり、指定されたツリー名に対して、現在有効な日付を付けられたツリー(未来の日付を除く)を抽出します。PeopleSoftツリーに増分抽出はありません。また、完全抽出は、各ETLプロセス中に必ず実行されます。
部門ツリーとビジネス・ユニット・ツリーを構成するには:
DACで、「Design」ビューに移動して、適切なカスタム・コンテナをドロップダウン・リストから選択します。
「Tasks」タブを表示します。
タスク「SDE_PSFT_Stage_InternalOrganizationDimension_Hierarchy_Extract」を選択し、「Parameters」サブタブを表示します。
$$TREE_SETID_NAME_LISTパラメータを使用して、ツリー・セットIDおよびツリー名をsetid~tree_nameの形式で指定します。
setid~tree_nameの値を一重引用符で囲みます。複数のツリーがある場合は、カンマを使用して区切ります。次に例を示します。
'SHARE~DEPT1', 'US~DEPT1', 'EU~DEPT1'
$$TREE_STRUCT_ID_LISTパラメータを使用して、抽出する必要があるデータの構造IDを指定します。各IDをカンマで区切ります。
このパラメータのデフォルト値は、「'BUSINESS_UNIT','DEPARTMENT'」です。
手順3～5をSDE_PSFT_Stage_InternalOrganizationDimension_CompanyHierarchy_Extractタスクに対して繰り返します。
地理国次元は、ビジネス・ロケーションのロールアップ次元および地理次元として使用されます。
Oracle Business Intelligence Applicationsには、デフォルトで国の標準セットがインストールされています(ファイルdomainValues_GeoCountry_ISO_Country_Codes_Type.csv内)。ファイルdomainValues_GeoCountry_ISO_Country_Codes_Type.csvにない国をソース・システムに追加する場合、ファイルを変更して、このデータに対応する必要があります。
ファイルdomainValues_GeoCountry_ISO_Country_Codes_Type.csvは、ISOの国コードのW_GEO_COUNTRY_Dテーブルのドメイン値参照です。これには、カラムCOUNTRY_CODE、COUNTRY_NAME、ISO_COUNTRY_CODE、ISO_COUNTRY_NAME、ISO_NUMERICAL_CODE、ISO_ALPHA3_CODE、NLS_TERRITORYが含まれています。
注意: domainValues_GeoCountry_ISO_Country_Codes_psft.csvのCOUNTRY_CODEは、PeopleSoftアプリケーション・データベースのPS_COUNTRY_TBLの値と一致する必要があります。
PeopleSoftの国コードを構成するには:
テキスト・エディタを使用して、$PMServer\LkpFilesディレクトリ(たとえば、INFA_HOME\server\infa_shared\LkpFiles)にあるdomainValues_GeoCountry_ISO_Country_Codes_psft.csvを編集します。
新しい行を適切な値を指定してCSVファイルに追加します。
ファイルを保存して閉じます。
Siebelソース・システムに配置されているOracle BI Applicationsに適用される必須または追加の構成手順はありません。
この項では、OracleのJD Edwards EnterpriseOneソース・システムまたはJD Edwards Worldソース・システムに配置されているOracle BI Applicationsに適用される構成手順について説明します。
このセクションには次のトピックが含まれます。
この項では、データの完全ロードを実行する前に、OracleのJD Edwards EnterpriseOneソース・システムに配置されているOracle BI Applicationsに適用される構成手順について説明します。内容は次のとおりです。
第3.5.1.2項「OracleのJD Edwards EnterpriseOneまたはJD Edwards WorldのUDCのコード次元の構成について」
第3.5.1.4項「JD Edwards EnterpriseOneまたはJD Edwards Worldの総勘定元帳勘定のグループ勘定コードへのマッピングについて」
DACパラメータを使用して、カテゴリ・コードをOracleのJD Edwards EnterpriseOneおよびJD Edwards Worldから次元テーブルにロードします。DACパラメータを構成するとき、次のリストに示されている次元の20個の新しいカラムにどのカテゴリ・コードをマップするかを選択します。また、表3-20に示されている既存のカラムにマップするカテゴリ・コードも選択できます。DACでは、デフォルトで、次元テーブルの新しい属性および構成可能カラムの名前のすべてのDACパラメータにNULLが割り当てられています。
次の次元は、カテゴリ・コードをサポートします。
W_INT_ORG_D
W_PRODUCT_D
W_CUSTOMER_ACCOUNT_D
W_PARTY_ORG_D
W_GL_ACCOUNT_D
注意: OracleのJD Edwards EnterpriseOneおよびJD Edwards Worldの総勘定元帳勘定に関するカテゴリ・コードは、W_GL_ACCOUNT_Dテーブルの既存の勘定セグメント・カラムにマップされます。構成ファイル(DACパラメータではない)は、これらのカテゴリ・コードを構成するために使用されます(詳細は、第5.2.4.8項「file_glacct_segment_config_jde.csvの構成方法」を参照)。
表3-20は、カテゴリ・コードもマップできる次元テーブルの追加フィールドの一覧です。
表3-20 カテゴリ・コードをマップできる追加の次元テーブルのフィールド
| テーブル | カラム |
|---|---|
|
W_CUSTOMER_ACCOUNT_DS |
ACCOUNT_TYPE_CODE |
|
W_CUSTOMER_ACCOUNT_DS |
ACCOUNT_CLASS_CODE |
|
W_INT_ORG_DS |
STATE_REGION |
|
W_INT_ORG_DS |
COUNTRY_REGION |
|
W_PARTY_ORG_DS |
LINE_OF_BUSINESS |
|
W_PARTY_ORG_DS |
REGION |
|
W_PARTY_ORG_DS |
ACCNT_AHA_NUM |
|
W_PARTY_ORG_DS |
ACCNT_CLASS |
|
W_PARTY_ORG_DS |
ACCNT_HIN_NUM |
|
W_PARTY_ORG_DS |
ACCNT_REGION |
|
W_PARTY_ORG_DS |
ACCNT_VALUE |
|
W_PARTY_ORG_DS |
CUST_CAT_CODE |
|
W_PRODUCT_DS |
CONFIG_CAT_CODE |
|
W_PRODUCT_DS |
INDUSTRY_CODE |
|
W_PRODUCT_DS |
BRAND |
|
W_PRODUCT_DS |
COLOR |
|
W_PRODUCT_DS |
UNIV_PROD_CODE |
DACでカテゴリ・コードを構成するには:
DACで、「Design」ビューに移動して、適切なカスタム・コンテナをドロップダウン・リストから選択します。
「Tasks」タブを表示して、タスクに対するクエリーを実行します。
表3-21は、マップできるカテゴリ・コードおよび編集する必要がある対応DACタスクを含むOracle JD Edwards EnterpriseOneテーブルを示しています。
表3-21 OracleのJD Edwards EnterpriseOne/JD Edwards Worldテーブル名および対応するDACタスク名
| OracleのJD Edwards EnterpriseOne/JD Edwards Worldテーブル | DACタスク |
|---|---|
|
F0006ビジネス・ユニット・マスター |
SDE_JDE_InternalOrganization_BusinessUnits |
|
F0101アドレス・ブック・マスター、業務別ラインごとのF03012顧客マスター |
SDE_JDE_PartyOrganisationDimension |
|
業務別ラインごとのF03012顧客マスター(JD Edwards EnterpriseOneのみ) |
SDE_JDE_Customer_Account_Dimension |
|
F0301顧客マスター(JD Edwards Worldのみ) |
SDE_JDE_Customer_Account_Dimension |
|
F4101項目マスター |
SDE_JDE_ProductDimensions |
選択したタスクの「Detail」エリアで、「Parameters」タブを表示します。NULL値をJDEカテゴリ・コードのカラム名およびテーブル名で上書きして、DACパラメータの値を変更します。次に例を示します。
$$FLEX_ATTRIB_2_CHAR = F0006.MCRP24
file_udc_category_mapping_jde.csvファイルは、OracleのJD Edwards EnterpriseOneまたはJD Edwards Worldのユーザー定義コード(UDC)をコード(W_CODE_D)次元にロードします。すべてのUDCのコード次元へのロードを回避するには、このフラット・ファイルを使用して、ロードするUDCのセットを指定します。
CSVファイルを構成する前に、ロードしている機能モジュールに応じて、必要なUDCを特定します。ETLプロセスに関連するトランザクション・テーブルのUDCのみを選択します。CSVファイルを構成するとき、参照できるUDCのリストを準備することをお薦めします。
CSVファイルには、3つのカラムがあります。最初の2つのカラムは、システム・コードおよびユーザー定義コードを特定するために使用されます。これらのカラムは両方とも、W_CODE_DにロードされるUDCを特定するために使用されます。3つめのカラムは、W_CODE_Dのコードのロード先カテゴリです。
W_CODE_Dのカテゴリは、類似の目的用のコードをグループ化するために使用されます。たとえば、UDC 00||CNが国コードおよび説明を格納するとします。これをW_CODE_DのCOUNTRYカテゴリに格納するには、次の行をCSVファイルに入力します。
00 CN COUNTRY
CSVファイルで、システム・コードおよびユーザー定義コードを指定し、これをUDCのロード先カテゴリと関連付けます。このデータは、UDC_CATEGORY_MAP_TMPテーブルにロードされ、このテーブルは、データを使用して関連コードをコード次元にロードします。
表3-22には、file_udc_category_mapping_jde.csvフラット・ファイルを使用してマップできるUDCが含まれています(ファイルにリストされた順にマップ)。
表3-22 file_udc_category_mapping_jde.csvフラット・ファイルのUDCのリスト
| システム・コード | ユーザー定義コード | カテゴリ |
|---|---|---|
|
00 |
PY |
SUPPLIER_PAYMENT_METHOD |
|
00 |
CN |
COUNTRY |
|
01 |
GD |
GENDER |
|
01 |
LP |
LANGUAGE |
|
00 |
S |
STATE |
|
01 |
PH |
FIN_PHONE_USAGE |
|
00 |
MC |
DIVISION_TYPE |
|
00 |
TS |
FIN_ORG_STRUCTURE |
|
01 |
SC |
PROFITCNTR_GRP |
|
H00 |
TA |
TAX_CODE |
|
00 |
PY |
PAYMENT_METHOD |
|
98 |
IC |
ACCT_DOC~STATUS |
|
00 |
UM |
UOM |
|
41 |
I |
STORAGE_TYPE |
|
49 |
BX |
HAZARD_MTL |
|
41B |
PG |
PROD_GRP |
|
46 |
EQ |
CONTAINER |
|
41 |
I |
PRODUCT_TYPE |
|
42 |
FR |
FRGHT_TERMS |
|
06 |
G |
JOB |
|
07 |
MS |
MARITAL_STATUS |
|
05 |
HQ |
DISABILITY |
|
00 |
CN |
NATIONAL_ID_TYPE |
データ・ウェアハウスの一時表は、UDCをカテゴリ・マッピングに格納します。コード次元のETLが開始されると、このテーブルにあるすべてのUDCおよびそれぞれのカテゴリに対するマッピングが、ソースから抽出され、W_CODE_Dテーブルにロードされます。
UDCをカテゴリと関連付ける方法を決定するには、W_CODE_Dを参照して説明が解決されるSILOマッピングを確認する必要があります。カテゴリは、参照でハード・コードされます。説明をW_CODE_Dから解決するためには、UDCを正しいカテゴリに確実にロードする必要があります。
OracleのJD Edwards EnterpriseOneまたはJD Edwards Worldのカテゴリ・コードのカテゴリの作成およびコード次元の構成の詳細は、My Oracle Supportのナレッジ記事を参照してください。
OracleのJD Edwards EnterpriseOneおよびJD Edwards Worldには、会計パターンまたは会計年度の四半期を定義するという概念がありません。したがって、四半期情報をポピュレートするために構成可能なフラット・ファイルが提供されます。この構成ファイルを使用すると、各期間の四半期番号、四半期の開始日、四半期の終了日などの四半期情報をフィードできます。このフラット・ファイルの構成方法は、第5.2.4.9項「file_lkp_fiscal_period_Qtr_Config_jde.csvの構成方法」を参照してください。各会計パターンには、OLTPがサポートする様々な数の期間があります。したがって、四半期構成は、会計年度それぞれおよび会計パターンそれぞれに対して必要です。表3-23は、テキスト・エディタで開いたfile_lkp_fiscal_period_Qtr_Config_jde.csvの例を示しています。
表3-23 file_lkp_fiscal_period_Qtr_Config_jde.csvの例
| Fiscal Pattern | Year | Period | QuarterNo | QuarterStart | QuarterEnd |
|---|---|---|---|---|---|
|
F |
4 |
1 |
1 |
6/1/2004 |
8/30/2004 |
|
F |
4 |
2 |
1 |
6/1/2004 |
8/30/2004 |
|
F |
4 |
3 |
1 |
6/1/2004 |
8/30/2004 |
|
F |
4 |
4 |
2 |
9/1/2004 |
11/30/2004 |
|
F |
4 |
5 |
2 |
9/1/2004 |
11/30/2004 |
|
F |
4 |
6 |
2 |
9/1/2004 |
11/30/2004 |
|
F |
4 |
7 |
3 |
12/1/2004 |
2/28/2005 |
|
F |
4 |
8 |
3 |
12/1/2004 |
2/28/2005 |
|
F |
4 |
9 |
3 |
12/1/2004 |
2/28/2005 |
|
F |
4 |
10 |
4 |
3/1/2005 |
3/31/2005 |
|
F |
4 |
11 |
4 |
3/1/2005 |
3/31/2005 |
|
F |
4 |
12 |
4 |
3/1/2005 |
3/31/2005 |
|
F |
4 |
13 |
4 |
3/1/2005 |
3/31/2005 |
|
F |
4 |
14 |
4 |
3/1/2005 |
3/31/2005 |
F0008テーブルの各会計年度に対して、各会計期間の四半期を定義する必要があります。四半期情報は、四半期ごとの集計の計算で使用されます。
Oracle Business Analytics WarehouseのW_MCAL_CONTEXT_Gテーブルは、組織ID、元帳IDおよび営業単位の各カラムと関連付けられたカレンダーを格納します。OracleのJD Edwards EnterpriseOneおよびJD Edwards Worldでは、会計日付パターンは、ORG_IDおよびLEDGER_IDを形成する会社と関連付けられます。
W_MCAL_CAL_Dテーブルは、カレンダー情報を格納します。会計日付パターン・テーブル(F0008)に格納されたそれぞれの会計日付パターンには、このテーブルのエントリがあります。この次元の単位は、日付パターン・タイプで、Oracle Business Analytics Warehouseのカレンダーを識別します。この次元には、そのパターンの会計年度との関連はありません。MCAL_CAL_WIDカラムは、ETLを実行するたびに1000にリセットされ、W_MCAL_CAL_Dに格納される日付パターン・タイプそれぞれに対して1ずつ増やされる4桁の番号です。
この項では、Oracle JD Edwards EnterpriseOneまたはJD Edwards Worldの総勘定元帳勘定をグループ勘定コードにマップする方法について説明します。項目は次のとおりです。
総勘定元帳勘定の設定の概要: 第3.5.1.4.1項「総勘定元帳勘定のグループ勘定コードへのマッピングの概要」を参照してください。
グループ勘定コードへの総勘定元帳勘定のマップ方法の説明: 第3.5.1.4.2項「総勘定元帳勘定番号のグループ勘定コードへのマップ方法」を参照してください。
Oracle BIリポジトリへのグループ勘定コード指標の追加方法を説明する例: 第3.5.1.4.3項「グループ勘定コード指標のOracle BIリポジトリへの追加例」を参照してください。
|
注意: 総勘定元帳勘定番号は、グループ勘定コード(またはドメイン値)にマップされている必要があります。これは、総勘定元帳レポート・レイヤーの指標でこれらの値が使用されるためです。総勘定元帳勘定番号のドメイン値の一覧は、Oracle Business Analytics Warehouseデータ・モデル・リファレンスを参照してください。 |
詳細は、第3.1.5項「すべてのソース・システムに対する総勘定元帳勘定のグループ勘定コードへのマッピングについて」も参照してください。
グループ勘定コードの構成は、総勘定元帳および利益率モジュールの指標の大部分の精度を決定するため、Financial Analyticsの構成において重要な手順です。
$PMServer\SrcFilesディレクトリにある次の構成ファイルを使用して、総勘定元帳勘定を設定します。
file_group_acct_names.csv: このファイルは、グループ勘定名および対応するグループ勘定コードを指定します。
file_group_acct_codes_jde.csv: このファイルは、総勘定元帳勘定をグループ勘定コードにマップします。
file_grpact_fstmt.csv: このファイルは、財務諸表項目コートをグループ勘定コードにマップします。
データをロードする前に、勘定の値のマップがこれら3つの構成ファイル間で整合性があることを確認する必要があります。図3-13は、file_group_acct_names.csvのGROUP_ACCOUNT_NUMフィールドがfile_group_acct_codes_ora.csvのGROUP_ACCT_NUMフィールドおよびfile_grpact_fstmt.csvのGROUP_ACCT_NUMフィールドにどのようにマップされている必要があるかを示しています。
OracleのJD Edwards EnterpriseOneまたはJD Edwards Worldの総勘定元帳勘定を特定のグループ勘定コードに分類できます。グループ勘定コードは、データの抽出時とフロントエンドでのレポート作成時に使用されます。総勘定元帳勘定次元テーブルW_GL_ACCOUNT_DのGROUP_ACCT_NUMフィールドは、総勘定元帳勘定の種類(現金勘定、売掛金勘定、長期借入金勘定、給与勘定など)を表します。グループ勘定コードのドメイン値の一覧は、Oracle Business Analytics Warehouseデータ・モデル・リファレンスを参照してください。総勘定元帳勘定番号のマップは、利益率分析および総勘定元帳分析(貸借対照表など)の両方にとって重要です。
file_group_account_codes_jde.csvを使用して、目的の勘定を関連付けるグループ勘定を(使用可能なグループ勘定の中から)指定できます。このCSVファイルのCompanyカラムは、目的の勘定が属する実際の会社です。From AccountからTo Accountの範囲の他に、システムは、入力会社を関連付けのパラメータとして使用します。入力会社がグループ勘定フラット・ファイルで構成されていない場合、システムは、参照するために00000を会社のデフォルト値として挿入します。1つのグローバル会計チャートを使用している場合、00000以外の任意の会社のグループ勘定を構成しないことを選択できます。ただし、追加の会社に対してグループ勘定を構成する場合、すべての可能なFrom AccountからTo Accountの範囲をこれらの会社に対して構成する必要があります。また、会社00000の勘定の全範囲を常に構成する必要があります。
表3-24は、テキスト・エディタで開いたfile_group_account_codes_jde.csvの例を示しています。
表3-24 file_group_account_codes_jde.csvの例
| COMPANY | FROM ACCT | TO ACCT | GROUP_ACCT_NUM |
|---|---|---|---|
|
00000 |
4100 |
4190 |
AP |
|
00000 |
1200 |
1299 |
AR |
|
00000 |
2120 |
2195 |
ACC DEPCN |
|
00000 |
4200 |
4211 |
ACC LIAB |
|
00000 |
1100 |
1121 |
CASH |
|
00000 |
4900 |
4910 |
CMMN STOCK |
|
00000 |
1401 |
1469 |
FG INV |
|
00000 |
3990 |
3990 |
GOODWILL |
|
00000 |
4690 |
4690 |
LT DEBT |
|
00000 |
3900 |
3940 |
OTHER ASSET |
|
00000 |
1310 |
1400 |
OTHER CA |
|
00000 |
4212 |
4550 |
OTHER CL |
|
00000 |
4950 |
4950 |
OTHER EQUITY |
|
00000 |
4610 |
4685 |
OTHER LIAB |
file_grpact_fstmt.csvファイルによって、グループ勘定コードと財務諸表項目コードとのリレーションシップが指定されます。表3-25は、グループ勘定コードがマップする必要がある財務諸表項目コードおよび関連のベース要素テーブルを示しています。
表3-25 財務諸表項目コードおよび関連のベース要素テーブル
| 財務諸表項目コード | ベース要素テーブル |
|---|---|
|
AP |
買掛金ベース要素(W_AP_XACT_F) |
|
AR |
売掛金ベース要素(W_AR_XACT_F) |
|
COGS |
売上原価ベース要素(W_GL_COGS_F) |
|
REVENUE |
収益ベース要素(W_GL_REVN_F) |
|
TAX |
税金ベース要素(W_TAX_XACT_F)脚注 1 |
|
OTHERS |
総勘定元帳仕訳ベース要素(W_GL_OTHER_F) |
脚注 1 Financial AnalyticsのOracleのJD Edwards EnterpriseOneおよびJD Edwards Worldのアダプタは税金ベース要素(W_TAX_XACT_F)をサポートしません。
総勘定元帳勘定をグループ勘定コードにマップし、そのグループ勘定コードを財務諸表項目コードに関連付けることにより、総勘定元帳勘定番号が財務諸表項目コードに間接的に関連付けられます。
この項では、総勘定元帳勘定番号をグループ勘定コードにマップする方法を説明します。
|
注意: 新しいグループ勘定コードをfile_group_acct_codes_jde.csvファイルに追加する場合、指標をOracle BIリポジトリに追加する必要もあります。詳細は、第3.5.1.4.3項「グループ勘定コード指標のOracle BIリポジトリへの追加例」を参照してください。 |
Oracle総勘定元帳勘定番号をグループ勘定コードにマップするには:
テキスト・エディタを使用して、$PMServer\SrcFilesディレクトリ(たとえば、INFA_HOME\server\infa_shared\SrcFiles)にあるfile_group_acct_codes_jde.csvファイルを開きます。
マップする総勘定元帳勘定番号それぞれに対して、次のフィールドを含むファイルに新しい行を作成します。
| フィールド名 | 説明 |
|---|---|
| COMPANY | 会社のID。 |
| FROM ACCT | 種類別勘定の範囲の下限。この値は総勘定元帳勘定の種類別勘定のセグメントに基づきます。 |
| TO ACCT | 種類別勘定の範囲の上限。この値は総勘定元帳勘定の種類別勘定のセグメントに基づきます。 |
| GROUP_ACCT_NUM | このフィールドは、file_group_acct_names.csvファイルで指定された総勘定元帳勘定のグループ勘定コードを表します。買掛金の場合にはAP、現金勘定の場合にはCASH、給与勘定の場合にはGEN PAYROLLなどです。 |
次に例を示します。
10000, 1110, 1110, CASH 10000, 1210, 1210, AR 10000, 1220, 1220, AR
|
注意: オプションで、CSVファイルの未使用の行を削除できます。 |
file_group_acct_codes_jde.csvファイルで指定する値は、file_group_acct_names.csvファイルおよびfile_grpact_fstmt.csvファイルで指定する値と整合性を保つようにしてください。
例については、図3-13「JD Edwardsのグループ勘定を構成する構成ファイル」を参照してください。
CSVファイルを保存して閉じます。
新しいグループ勘定コードをfile_group_acct_codes_jde.csvファイルに追加する場合(第3.5.1.4.2項「総勘定元帳勘定番号のグループ勘定コードへのマップ方法」を参照)、指標をOracle BIリポジトリに追加して、新しいグループ勘定コードを公開する必要もあります。この例は、Oracle BI管理ツールを使用して、グループ勘定コードの指標を追加する方法を示しています。
この例では、「Payroll」という新しいグループ勘定コードがあり、新しい指標を「Payroll Expense」というプレゼンテーション・レイヤーに追加します。
論理テーブル「Fact – Fins – GL Other Posted Transaction」の新しい指標を追加するには:
管理ツールを使用して、OracleBIAnalyticsApps.rpdを開きます。
OracleBIAnalyticsApps.rpdファイルは次の場所にあります。
ORACLE_INSTANCE\bifoundation\OracleBIServerComponent\coreapplication_ obisn\repository
「ビジネス・モデルとマッピング」レイヤーで、次を実行します。
「Payroll Expense」という論理カラムを論理テーブル「Fact – Fins – GL Other Posted Transaction」に作成します。
たとえば、「Core\Fact - Fins - GL Other Posted Transaction」オブジェクトを右クリックし、「新規オブジェクト」→「論理列」を選択し、「論理列」ダイアログを表示します。「名前」フィールドで「Payroll Expense」を指定します。
「集計」タブを表示し、「デフォルトの集計ルール」ドロップダウン・リストで「合計」を選択します。
「OK」をクリックして詳細を保存し、ダイアログを閉じます。
「Core\Fact - Fins - GL Other Posted Transaction\Sources」フォルダを展開し、「Fact_W_GL_OTHER_GRPACCT_FSCLYR_A」ソースをダブルクリックして、「論理表ソース」ダイアログを表示します。
「列マッピング」タブを表示します。
「マップされていない列の表示」を選択します。
「Payroll Expense」式を探し、「式ビルダー」ボタンをクリックして、式ビルダーを開きます。
式ビルダーを使用して、次のSQL文を指定します。
CASE WHEN "Oracle Data Warehouse"."Catalog"."dbo". "Dim_W_GL_GROUP_ACCOUNT_D"."GROUP_ACCOUNT_NUM" = 'PAYROLL' THEN "Oracle Data Warehouse"."Catalog"."dbo". "Fact_Agg_W_GL_OTHER_GRPACCT_FSCLYR_A"."OTHER_GLOBAL1_AMT" ELSE NULL END
CASE条件は、新しいグループ勘定コード「Payroll」を参照し、これをフィルタとして使用します。
論理テーブル・ソースそれぞれに対して、手順dからhを繰り返します。論理テーブル・ソースに対応する要素テーブルを使用して、各論理テーブル・ソースに対して、手順hで適切に式を変更します。
手順dからhは、論理テーブル・ソースそれぞれに対して繰り返す必要があります。これは、この例では、この論理テーブルの要素テーブルおよび集約テーブルに対して複数の論理テーブル・ソースがあるためです。対応する要素テーブルを使用して、各論理テーブル・ソースに対して、手順hで適切に式を変更します。
これらの詳細を保存します。
エンド・ユーザーのダッシュボードおよびレポートで新しいリポジトリ・オブジェクトを公開するには、新しいオブジェクトをビジネス・モデルおよびマッピング・レイヤーからプレゼンテーション・レイヤーの該当するフォルダにドラッグします。
論理テーブル「Fact – Fins – GL Balance」の新しい指標を追加するには:
管理ツールを使用して、OracleBIAnalyticsApps.rpdを開きます。
OracleBIAnalyticsApps.rpdファイルは次の場所にあります。
ORACLE_INSTANCE\bifoundation\OracleBIServerComponent\coreapplication_ obisn\repository
「ビジネス・モデルとマッピング」レイヤーで、次を実行します。
「Payroll Expense」という論理カラムを論理テーブル「Fact – Fins – GL Balance」に作成します。
たとえば、「Core\Fact – Fins – GL Balance」オブジェクトを右クリックし、「新規オブジェクト」→「論理列」を選択し、「論理列」ダイアログを表示します。「名前」フィールドで「Payroll Expense」を指定します。
「列ソース」タブで「式を使用して既存の列から派生」を選択します。
「式ビルダー」ボタンをクリックして、式ビルダーを表示します。
式ビルダーを使用して、次のSQL文を指定します。
FILTER("Core"."Fact - Fins - GL Balance"."Activity Amount"
USING "Core"."Dim - GL Account"."Group Account Number" = 'Payroll')
CASE条件は、新しいグループ勘定コード「Payroll」を参照します。
これらの詳細を保存します。
エンド・ユーザーのダッシュボードおよびレポートで新しいリポジトリ・オブジェクトを公開するには、新しいオブジェクトをビジネス・モデルおよびマッピング・レイヤーからプレゼンテーション・レイヤーの該当するフォルダにドラッグします。
OracleのJD Edwards EnterpriseOneアダプタでは、勘定セグメントは次のようにマップされます。
CO.BU.OBJ.SUB.Sub Ledger.Sub Ledger type.Category Code(x).Category Code(n). Category Code(y)
セグメント階層は、ビジネス・ユニット(BU)セグメントに対してのみサポートされます。ビジネス・ユニット階層はW_INT_ORG_DHですでに取得されているため、W_HIERARCHY_Dをポピュレートするための抽出(ETL)はありません。
OracleのJD Edwards EnterpriseOneおよびJD Edwards Worldのレート・タイプの概念は、Oracle Business Analytics Warehouseでの定義方法とは異なります。OracleのJD Edwards EnterpriseOneおよびJD Edwards Worldでは、レート・タイプは、オプションのキーです。これは、為替レートの計算時には使用されません。
DACは、$$JDE_RATE_TYPEソース・システム・パラメータを使用して、W_EXCH_RATE_GSテーブルのRate_Typeフィールドをポピュレートします。デフォルトでは、DACの$$JDE_RATE_TYPEソース・システム・パラメータの値は「Actual」です。
W_EXCH_RATE_Gに対するクエリーおよび参照は、W_EXCH_RATE_GテーブルのRATE_TYPEフィールドにW_GLOBAL_CURR_GテーブルのGLOBAL1_RATE_TYPE、GLOBAL2_RATE_TYPE 2およびGLOBAL3_RATE_TYPEの各フィールドと同じ値が含まれていない場合、失敗します。
