このリファレンスの項には、機能設定マネージャ(FSM)の情報タスクに関するヘルプ・トピックが記載されています。情報タスクでは、概念情報やFSM以外のツール(Oracle Data IntegratorやOracle BI EE管理ツールなど)で実行される構成手順が表示されます。
この項のヘルプ・トピックは、情報タスクで「タスクに進む」をクリックしたり、FSMタスクに関する追加情報を取得するためにヘルプ・アイコンをクリックすることでFSMに表示されます。
この章の内容は次のとおりです。
注意: セキュリティに関するFSMタスクについては、『Oracle Business Intelligence Applicationsセキュリティ・ガイド』を参照してください。
この項では、複数のオファリングに適用されるタスクの例を一覧表示します。
ファイル・ベース・カレンダのデータ・ロード・パラメータの構成
企業リストの構成
グローバル通貨の構成
初期抽出日の構成
年プロンプトのレポート・パラメータの構成
遅延変更ディメンションの構成
企業カレンダの定義
グレゴリオ暦の日付範囲の指定
この項には、その他のヘルプ・トピックが記載されています。
機能構成を開始するには、第3.2項「機能構成のロードマップ」を参照してください。
実装プロジェクトの作成時には、BI Applicationオファリングと1つ以上の機能領域が選択されます。機能設定タスクのリストは、選択されたOracle BI Applicationsオファリングと機能領域に基づいて生成されます。
機能タスクには、主に次の4種類があります。
データ・ロード・パラメータを構成する各タスク: これらのタスクで「タスクに進む」ボタンをクリックすると、Oracle BI Applications構成マネージャが起動し、「データ・ロード・パラメータの管理」設定ユーザー・インタフェースが、タスクの実行に必要とされる適切なデータ・ロード・パラメータ・セットとともに表示されます。
ドメインおよびマッピングを管理する各タスク: これらのタスクで「タスクに進む」ボタンをクリックすると、Oracle BI Applications構成マネージャが起動し、「ドメインおよびマッピングの管理」設定ユーザー・インタフェースが、適切なドメイン・マッピング・セットとともに表示されます。
レポート・パラメータを構成する各タスク: これらのタスクで「タスクに進む」ボタンをクリックすると、Oracle BI Applications構成マネージャが起動し、「レポート・パラメータの管理」設定ユーザー・インタフェースが、タスクの実行に必要とされる適切なレポート・パラメータ・セットとともに表示されます。
情報用の各タスク: これらのタスクでは、次のいずれかの内容が提供されます。
概念情報、背景情報またはサポート情報。
FSM以外のツール(Oracle Data IntegratorやOracle BI EE管理ツールなど)で実行される構成手順。
初期抽出日は、完全ロード用にデータを抽出する際に必要です。これにより、初期ロード時におけるデータ量が削減されます。指定された初期抽出日は、選択された全体抽出マッピングのトランザクション・データの作成日に対するフィルタとして使用されます。日付形式はYYYY-MM-DDになります(例: 2014-12-31)。デフォルトの日付は1970年01月01日です。
初期抽出日パラメータを設定する場合は、会計期間中の任意の日付ではなく、会計期間の開始日に設定してください。たとえば、2005年6月からデータ抽出を開始するとします(2005年6月の会計期間は6月5日に始まる)。この場合、日付を2005年6月5日に設定します。
次の表では、INITIAL_EXTRACT_DATEが使用されています。
PROJECTS: W_PROJ_BUDGET_F W_PROJ_COMMITMENT_F W_PROJ_COMMITMENT_SNP_F W_PROJ_CONTRACT_LINE_F W_PROJ_COST_LINE_F W_PROJ_CROSS_CHARGE_DIST_F W_PROJ_FORECAST_F W_PROJ_FUNDING_LINE_F W_PROJ_INVOICE_DIST_F W_PROJ_REVENUE_LINE_F FINANCE: W_GL_OTHER_F W_GL_BALANCE_F W_GL_REVN_F W_GL_COGS_F W_GL_COST_REVN_F W_AP_HOLDS_F W_FA_BALANCE_F W_FA_XACT_F OM: W_SALES_ORDER_LINE_F W_SALES_INVOICE_LINE_F W_SALES_SCHEDULE_LINE_F W_SALES_PICK_LINE_F W_SALES_ORDER_HOLD_F W_SALES_ORDER_HOLD_1_F W_DOO_PROCESS_F W_SALES_ORDER_CREDIT_F W_SALES_INVOICE_CREDIT_F PIM: W_ITEM_REQUEST_F W_ITEM_REQUEST_STATUS_SNP_F W_ITEM_INTERFACE_F W_ITEM_F PRM: No INITIAL_EXTRACT_DATE usage Procurement: W_PURCH_RQSTN_LINE_F W_RQSTN_LINE_COST_F W_PURCH_AGREEMENT_HEADER_F W_PURCH_AGREEMENT_LINE_F W_PURCH_SCHEDULE_LINE_F W_PURCH_COST_F W_PURCH_RCPT_F W_AP_INV_DIST_F W_PURCH_CHANGE_ORDER_F Sourcing: W_NEG_INVITATIONS_F W_NEG_LINES_F W_NEG_RESPONSES_F Expense: W_EXPENSE_F W_EXPENSE_CC_F W_EXPENSE_VIOLATION_F SCM: W_CST_ITEM_COST_DAILY_F W_CST_INTRANSIT_DAILY_F W_CST_INTRAN_ACCNTED_DAILY_F W_CST_ONHAND_ACCNTED_DAILY_F W_CST_ONHAND_DAILY_F W_INVENTORY_CYCLE_COUNT_F W_PRODUCT_XACT_F HCM: W_WRKFC_EVT_F
注意: HRでは、HR_WRKFC_EXTRACT_DATE、HR_ABSENCE_EXTRACT_DATE、HR_PAYROLL_EXTRACT_DATE、HR_ACCRUAL_EXTRACT_DATEなどの特定の抽出日(初期抽出日のかわりに使用する)が必要です。共通するINITIAL_EXTRACT_DATEパラメータを設定するための唯一の要件は、4つの特定の抽出日付値より前の日付を設定することです。
Oracle Business Analytics Warehouseには、カテゴリ2の遅延変更ディメンション(SCD)機能が提供されています。これにより、ディメンション・レコードへの更新履歴を追跡できます。Oracle Business Analytics Warehouseのレコードに対する更新がある場合、その更新情報は新しい行に転記され、古い情報は履歴レポート用に保存されます。
Oracle Business Analytics Warehouseでは、データが抽出されてソースとは異なる形式に変換された後に、ユーザーが選択した遅延変更ディメンション・ロジックが識別されて適用されます。ユーザーは、カテゴリ1 SCD (データが更新情報で上書きされる)およびカテゴリ2 SCD (新しいレコードに更新データが保存され、元のレコードは保持される)をサポートするようにOracle BI Applicationsを構成できます。カテゴリ1 SCDまたはカテゴリ2 SCDのどちらが選択されるかは、履歴の有効属性が識別されるかどうかにかかっています。
ユーザーは、Oracle BI Applications構成マネージャで$$TYPE2_FLGの値をYまたはNに設定することによって、カテゴリ1またはカテゴリ2を選択できます。
次の表では、TYPE2がデフォルトで定義されています(デフォルトでは、ONに設定されている)。
共通ディメンション:
W_PRODUCT_D
W_INVENTORY_PRODUCT_D
W_POSITION_D
W_USER_D
W_INT_ORG_DH
W_PARTY_ORG_D
W_PARTY_PER_D
HCM:
W_HR_PERSON_LEG_D
W_HR_POSITION_D
W_JOB_D
W_PAY_GRADE_D
W_SUPERVISOR_DおよびW_SUPERVISOR_STATUS_D:
注意: これらは従来のタイプ2ディメンションではありませんが、EFFECTIVE_FROM_DTとEFFECTIVE_TO_DTが存在しており、これらはタイプ2に設定されています。
ただし、HCMではこれらの日付が内部処理されます。また、これら2つの日付を処理するのにSCDUpdateマッピングを必要としません。これらの表は監督者階層の作成に使用されますが、物理レイヤーでの公開後はRPDに公開されません。
財務:
W_FIXED_ASSET_D
次の表では、TYPE2がアプリケーションでサポートされていますが、デフォルトでは設定されていません(デフォルトはOFF、必要に応じてONにできる)。
共通ディメンション:
W_COST_CENTER_D
W_COST_CENTER_DH
W_BUSN_LOCATION_D
W_TERR_DH
財務:
W_AP_TERMS_D
W_BALANCING_SEGMENT_D
W_BANK_D
W_ASSET_BOOK_D
W_ASSET_CATEGORY_D
W_ASSET_LOCATION_D
W_GL_ACCOUNT_D
W_GL_SEGMENT_D
W_NATURAL_ACCOUNT_D
W_PAYMENT_TERMS_D
CRM/OM/PIM:
SCD2ディメンションはない
SCM/調達/ソーシング/経費:
SCD2ディメンションはない
このタスクでは、Customer Data Management AnalyticsのETLパラメータACTIVITYFILTERを構成します。このフィルタは、アクティビティに対するフィルタのカスタマイズに使用されます。デフォルト値は「(1=1) AND」で、ロードされるデータに影響を与えません。
ロードされるレコード数を調整する場合は、このデフォルト値を変更します。たとえば、今月または現四半期に作成されたアクティビティのみをロードする場合は、次の構文を使用します。
(ACT.CREATED_ON_DT > <Date>) AND
<Date>は、YYYY-MM-DD形式になります(例: 2014-12-31)。
このタスクは、E-Business Suiteアダプタのロード・パラメータ「Is Fed Fin Enabled」の構成に使用されます。連邦政府Financial Analyticsをデプロイする場合は、この値を「Y」に設定します。
製品はマスター組織で定義されてから、トランザクション用に別の在庫組織にコピーされます。製品ディメンションの抽出マッピング「SDE_ORA_ProductDimension_Derive」は、このマスター組織の構成に対して有効化されています(OLTPの構成に基づいている)。デフォルトでは、組織ID (MASTER_ORGパラメータで設定)は204に設定されます。この組織ID (204)は、デプロイメントにおけるOLTPの個々の実装に基づいて変更する必要があります。
注意: このETL実装では、製品マスターの定義における単一マスター組織の作成に関するオラクル社のベスト・プラクティスがサポートされています。このETL実装では、同じ製品が複数のマスター組織で定義されている場合、複数のマスター組織はサポートされません。また、組織コードのカンマ区切りの文字列(例: '204','458')を指定することにより、同じパラメータに複数のマスター組織を割り当てることもできます。
FSMでマスター在庫組織を構成する場合は、FSMタスク「マスター組織のデータ・ロード・パラメータの構成」を使用してください。
JD Edwardsにおける購買オーダー・ステータスのドメインとメンバー・マッピングの管理
Oracle Business Intelligence Applicationsには、シードされたOracle BI Applicationドメイン値をOracle Procurement and Spend Analyticsアプリケーションのシードされた構成データにマップするデフォルトのドメイン値マッピングが付属しています。購買オーダー・タイプは、FSMパラメータJDE_PURCHASING_ORDER_TYPE_LISTを使用して構成されます。このパラメータのデフォルト値はOP、O4、OS、ODです。
前述のパラメータを構成してその他の購買オーダー・タイプを含める場合は、PURCHASE_ORDER_STATUSのドメイン値と、それに対応するターゲット・ドメインW_PURCHASE_ORDER_CYCLE_STATUSおよびW_PURCHASE_ORDER_APPROVAL_STATUSのデフォルト・マッピングを確認する必要があります。また、新しい購買オーダー・タイプのマッピングに対応するように、必要に応じてそれらの値を更新する必要があります。
Oracle Procurement and Spend Analyticsでは、PURCHASE_ORDER_STATUSのドメイン・メンバー値は、購買オーダー・タイプ~ 明細ステータス~ 次のステータスです。
例: OP~220~240、OP~282~300。
デフォルトの購買オーダー・タイプをJDE_PURCHASING_ORDER_TYPE_LISTのように使用する場合、ETLプロセスを開始する前にこれらのドメイン・マッピングに変更を加える必要はありません。
新しいオーダー・タイプをJDE_PURCHASING_ORDER_TYPE_LISTに追加した場合は、PURCHASE_ORDER_STATUSの新しいドメイン・メンバーを追加する必要があります。その後、「ドメイン・マッピング」タブを使用して、デフォルト・マッピングに変更を加えてください。
JD Edwardsにおける購買オーダー・ドキュメント・サブタイプのドメインとメンバー・マッピングの管理
Oracle Business Intelligence Applicationsには、シードされたOracle BI Applicationドメイン値をOracle Procurement and Spend Analyticsアプリケーションのシードされた構成データにマップするデフォルトのドメイン値マッピングが付属しています。このパラメータのデフォルト値はOP、O4、OS、OD、OB、C、E、L、N、S、Tです。
OP、O4、OS、ODは、FSMパラメータJDE_PURCHASING_ORDER_TYPE_LISTで、残りは(OB、C、E、L、N、S、T)、JDE_PO_AGREE_STANDARD_TYPE_LISTで構成されます。
JD Edwardsにおける購買オーダー出荷タイプのドメインとメンバー・マッピングの管理
Oracle Business Intelligence Applicationsには、シードされたOracle BI Applicationドメイン値をOracle Procurement and Spend Analyticsアプリケーションのシードされた構成データにマップするデフォルトのドメイン値マッピングが付属しています。包括購買、見積書などに対してリリースされるオーダーは、この構成のマッピング対象として考慮されます。このパラメータのデフォルト値はOB、OQ、STDです。
FSMパラメータ:
次のパラメータを構成します。
JDE_PURCHASING_CANCELED_STATUS_CODE_LIST
購買オーダーの取消済ステータス・コードは、FSMパラメータを使用して構成されます。取消済ステータスに対応するすべてのPOステータス・コードは、このパラメータの値として一覧表示されます(シード・マネージャで値を入力するときには、引用符やスペースを削除してください)。また、関連付けられたファクト・グループに対するこのパラメータのデフォルト値を編集できます。たとえば、購買オーダーのETLタスクに対するこのパラメータのデフォルト値が980、982、983、984、985、986、987、988、989である場合でも、購買依頼のETLタスクに対するデフォルト値のリストを499、980、981、982、983、984、985、986、987、988、989、990、991にすることができます。
JDE_PURCHASING_ORDER_TYPE_LIST
購買オーダー・タイプは、FSMパラメータJDE_PURCHASING_ORDER_TYPE_LISTを使用して構成されます。このパラメータのデフォルト値はOP、O4、OS、ODです。また、関連付けられたファクト・グループに対するこのパラメータのデフォルト値を編集できます。前述のパラメータを構成してその他の購買オーダー・タイプを含める場合は、PURCHASE_ORDER_STATUSのドメイン値と、それに対応するターゲット・ドメインW_PURCHASE_ORDER_CYCLE_STATUSおよびW_PURCHASE_ORDER_APPROVAL_STATUSのデフォルト・マッピングを確認または編集する必要があります。
JDE_REQ_ORDER_TYPE_LIST
購買依頼文書タイプは、FSMパラメータJDE_REQ_ORDER_TYPE_LISTを使用して構成されます。このパラメータのデフォルト値はOU、ORです。
JDE_PO_QUOTE_TYPE
「見積」タイプの購買オーダーは、購買オーダーの出荷タイプの導出に使用されます。JDE_PO_QUOTE_TYPEは、見積タイプを使用して構成されます。このパラメータのデフォルト値はOQです。
JDE_PON_BID_QTN_PRICE_TYPE
入札質問の価格タイプは、FSMパラメータJDE_PON_BID_QTN_PRICE_TYPEを使用して構成されます。デフォルト値はPです。
JDE_PON_RFI_TYPE
ソーシング情報依頼文書タイプは、FSMパラメータJDE_PON_RFI_TYPEを使用して構成されます。デフォルト値はRFです。
JDE_RCPT_LINE_TYPE
運送費明細は、入金ファクトでは考慮されません。これは、FSMパラメータJDE_RCPT_LINE_TYPEを使用して構成されます。デフォルト値はFです。
JDE_PO_AGREE_BLOCKED_STATUS_CODE
購買契約のブロック済ステータス・コードは、パラメータJDE_PO_AGREE_BLOCKED_STATUS_CODEを使用して構成されます。このパラメータのデフォルト値は210です。
JDE_PO_AGREE_BLANKET_TYPE
購買包括契約タイプは、パラメータJDE_PO_AGREE_BLANKET_TYPEを使用して構成されます。このパラメータのデフォルト値はOBです。
このパラメータのデフォルト値に変更を加える場合は、「ドメイン・マッピング」タブを使用して、PO_DOCUMENT_TYPESのドメイン値と、それに対応するターゲット・ドメインW_XACT_TYPE_PO_DOCUMENT_TYPESのデフォルト・マッピングを確認または編集する必要があります。
JDE_PO_AGREE_STANDARD_TYPE_LIST
購買標準契約タイプは、パラメータJDE_PO_AGREE_STANDARD_TYPE_LISTを使用して構成されます。このパラメータのデフォルト値はC、E、L、N、P、S、Tです。
このパラメータのデフォルト値に変更を加える場合は、「ドメイン・マッピング」タブを使用して、PO_DOCUMENT_TYPESのドメイン値と、それに対応するターゲット・ドメインW_XACT_TYPE_PO_DOCUMENT_TYPESのデフォルト・マッピングを確認または編集する必要があります。
デフォルトのOracle Supply Chain and Order Management Analyticsアプリケーションでは、バックログ表を移入するために、販売オーダー明細表(W_SALES_ORDER_LINE_F)と販売スケジュール明細表(W_SALES_SCHEDULE_LINE_F)のオープン販売オーダーのみが抽出されてバックログ計算が行われます。オープン販売オーダーは、取り消されていないオーダーまたは未完了のオーダーとして定義されます。オープン・オーダーのみを抽出する理由は、ほとんどの組織においてクローズ済オーダーはバックログの一部ではなくなるためです。ただし、クローズ済としてマークされた販売オーダーを抽出する場合は、抽出マッピングからデフォルトのフィルタ条件を削除する必要があります。
たとえば、顧客が10個のアイテムを発注するとします。そのうちの6個に対しては請求書が発行されて出荷されますが、4個のアイテムは出荷待ちバックログと財務バックログに記載されます。このバックログ・ステータスは、次のいずれかの事象が発生するまで維持されます。
アイテムが出荷されて請求書が発行される。
残りのオーダーが取り消される。
クローズ済としてフラグされた販売オーダーの抽出を選択するときは、バックログ・フラグの条件を削除する必要があります。そのためには、次の手順に従います。
W_SALES_ORDER_LINE_F表のBACKLOG_FLAGも、バックログ計算対象として適格な販売オーダーの識別に使用されます。デフォルトでは、すべての販売オーダー・タイプのバックログ・フラグはYに設定されています。その結果、すべての販売オーダー・タイプがバックログ計算に含められます。
オープン・オーダーの抽出フィルタを削除する手順は次のとおりです。
Oracle Data Integratorで「マッピング」フォルダを開いて、「SDE_ORA11510_Adaptor」フォルダ、「SDE_ORAR12Version_Adaptor」フォルダまたは「SDE_FUSION_V1_Adaptor」フォルダを開きます。
「SDE_ORA_SalesOrderLinesFact」→「インタフェース」→「E-Business SuiteのSDE_ORA_SalesOrderLinesFact.W_SALES_ORDER_LINE_FS」アダプタ、または「SDE_FUSION_SalesOrderLinesFact」→「インタフェース」→「FUSIONのSDE_FUSION_SalesOrderLinesFact.W_SALES_ORDER_LINE_FS」アダプタを開きます。
「クイック編集」タブをクリックし、「クイック編集」タブ内の「マッピング」を開きます。
OPR_BACKLOG_FLGを探し、「マッピング式」を開きます。E-Business SuiteアダプタではSQ_BCI_SALES_ORDLNS.OPEN_FLAG = 'Y' ANDを、FUSIONアダプタではSQ_FULFILLLINEPVO.FulfillLineOpenFlag = 'Y' ANDを削除します。
FIN_BACKLOG_FLGを探し、「マッピング式」を開きます。E-Business SuiteアダプタではSQ_BCI_SALES_ORDLNS.OPEN_FLAG = 'Y' ANDを、FUSIONアダプタではSQ_FULFILLLINEPVO.FulfillLineOpenFlag = 'Y' ANDを削除します。
変更内容をリポジトリに保存します。
「マッピング」フォルダ、「PLP」フォルダの順に開きます。
「PLP_SalesBacklogLinesFact_Load_OrderLines」→「インタフェース」→「PLP_SalesBacklogLinesFact_Load_OrderLines.W_SALES_BACKLOG_LINE_F.SQ_SALES_ORER_LINES_BACKLOG」を開きます。
「クイック編集」タブをクリックし、「クイック編集」タブ内の「フィルタ」を開きます。
フィルタ「W_STATUS_D.W_STATUS_CODE<>'Closed'」を探し、それを削除します。
「PLP_SalesBacklogLinesFact_Load_ScheduleLines」→「インタフェース」→「PLP_SalesBacklogLinesFact_Load_ScheduleLines.W_SALES_BACKLOG_LINE_F.SQ_W_SALES_SCHEDULE_LINE_F」を開きます。
「クイック編集」タブをクリックし、「クイック編集」タブ内の「フィルタ」を開きます。
フィルタ「W_STATUS_D.W_STATUS_CODE<>'Closed'」を探し、それを削除します。
変更内容をリポジトリに保存します。
このタスクは、SDE_ORA11510_AdaptorやSDE_ORAR12Version_AdaptorなどのE-Business Suiteソース・システムに適用されます。デフォルトでは、図B-1に示すように、記帳済オーダーのみがE-Business Suiteから抽出されます。
したがって、販売オーダー明細表、販売スケジュール明細表および販売予約明細表にロードされているすべてのオーダーは記帳されます。
ただし、未記帳オーダーを販売オーダー明細(W_SALES_ORDERS_LINES_F)と販売スケジュール明細(W_SALES_SCHEDULE_LINE_F)にロードしながら、記帳済オーダーのみを販売予約明細(W_SALES_BOOKING_LINE_F)にロードすることもできます。
未記帳オーダーを販売オーダー明細表と販売スケジュール明細表にロードする場合、それらの未記帳オーダーが除外されないように抽出条件を構成する必要があります。OE_ORDER_LINES_ALL.BOOKED_FLAG = 'Y'条件は、オーダーが記帳済であることを示します。つまり、未記帳オーダーの除外にはこの文が使用されます。未記帳オーダーを含むすべてのオーダーをロードする場合は、次のマッピングの一時インタフェースからこのフィルタ条件を削除します。
SDE_ORA_SalesOrderLinesFact
SDE_ORA_SalesOrderLinesFact_Primary
また、未記帳オーダーを販売オーダー明細表と販売スケジュール明細表に追加した場合は、販売オーダー明細または販売スケジュール明細から販売予約明細表への移入を行う際に未記帳オーダーを除外する必要があります。これを行うには、次のマッピングのインタフェースに、W_SALES_ORDER_LINE_F.BOOKING_FLG = 'Y'またはW_SALES_SCHEDULE_LINE_F.BOOKING_FLG = 'Y'条件を追加します。
SIL_SalesBookingLinesFact_Load_OrderLine_Credit
SIL_SalesBookingLinesFact_Load_OrderLine_Debit
SIL_SalesBookingLinesFact_Load_ScheduleLine_Credit
SIL_SalesBookingLinesFact_Load_ScheduleLine_Debit
販売オーダー明細表と販売スケジュール明細表に未記帳オーダーを追加する手順は次のとおりです(完全ロードと増分ロードの両方に対応)。
ODIデザイナ・ナビゲータで、SDE_ORA11510_AdaptorまたはSDE_ORAR12Version _Adaptorを開きます。
SDE_ORA_SalesOrderLinesFactおよびSDE_ORA_SalesOrderLinesFact_Primaryを探します。次の一時インタフェースを開きます。
SDE_ORA_SalesOrderLinesFact.W_SALES_ORDER_LINE_FS_SQ_BCI_SALES_ORDLNS
SDE_ORA_SalesOrderLinesFact_Primary.W_SALES_ORDER_LINE_F_PE_SQ_BCI_SALES_ORDLS
前述の一時インタフェースからフィルタ条件OE_ORDER_LINES_ALL.BOOKED_FLAG='Y'を探して削除します。
変更内容をリポジトリに保存します。
次の手順に従って、販売予約明細表に変更を加えます。
販売予約明細表に記帳済オーダーのみを追加する手順は次のとおりです。
ODIデザイナ・ナビゲータで、「SILOS」フォルダを開きます。
次の各インタフェースを開き、「フィルタ」セクションにフィルタを追加します。
「SIL_SalesBookingLinesFact_Load_OrderLine_Credit」フォルダ: 「SIL_SalesBookingLinesFact_Load_OrderLine_Credit.W_SALES_BOOKING_LINE_F_SQ_W_SALES_ORDER_LINE_F」インタフェースの「クイック編集」タブを開き、「フィルタ」セクションに「W_SALES_ORDER_LINE_F.BOOKING_FLG = 'Y'」を追加します。
「SIL_SalesBookingLinesFact_Load_OrderLine_Debt」フォルダ: 「SIL_SalesBookingLinesFact_Load_OrderLine_Debt.W_SALES_BOOKING_LINE_F」インタフェースの「クイック編集」タブを開き、「フィルタ」セクションに「SQ_W_SALES_ORDER_LINE_F.BOOKING_FLG = 'Y'」を追加します。
「SIL_SalesBookingLinesFact_Load_ScheduleLine_Credit」フォルダ: 「SIL_SalesBookingLinesFact_Load_ScheduleLine_Credit.W_SALES_BOOKING_LINE_F_SQ_W_SALES_SCHEDULE_LINE_F」インタフェースの「クイック編集」タブを開き、「フィルタ」セクションに「W_SALES_SCHEDULE_LINE_F.BOOKING_FLG = 'Y'」を追加します。
「SIL_SalesBookingLinesFact_Load_ScheduleLine_Debt」フォルダ: 「SIL_SalesBookingLinesFact_Load_ScheduleLine_Debt.W_SALES_BOOKING_LINE_F」インタフェースの「クイック編集」タブを開き、「フィルタ」セクションに「SQ_W_SALES_SCHEDULE_LINE_F.BOOKING_FLG = 'Y'」を追加します。
変更内容をリポジトリに保存します。
W_SALES_BOOKING_LINE_F表では、SALES_QTY、NET_AMTの変更と、BOOKING_ID列に定義されている特定の属性の変更が追跡されます。BOOKING_IDは、販売オーダー明細表のSDEマッピングで次のように計算されます。
SDE_ORA11510_AdaptorおよびSDE_ORA12Version_Adaptorの場合
TO_CHAR(SQ_BCI_SALES_ORDLNS.LINE_ID)||'~'||TO_CHAR(SQ_BCI_SALES_ORDLNS.INVENTORY_ITEM_ID)||'~'||TO_CHAR(SQ_BCI_SALES_ORDLNS.SHIP_FROM_ORG_ID)
SDE_FUSION_V1_Adaptorの場合
TO_CHAR(SQ_FULFILLLINEPVO.FulfillLineId)||'~'||TO_CHAR(SQ_FULFILLLINEPVO.FulfillLineInventoryItemId)||'~'||TO_CHAR(SQ_FULFILLLINEPVO.FulfillLineFulfillOrgId)
ただし、別の属性の変更を追跡する場合は、その属性のソース列とデフォルトのマッピング式を連結する必要があります。たとえば、顧客アカウントの変更を追跡する場合は、BOOKING_ID列の顧客アカウントのソース列を次のように連結します。
SDE_ORA11510_AdaptorおよびSDE_ORA12Version_Adaptorの場合
TO_CHAR(SQ_BCI_SALES_ORDLNS.LINE_ID)||'~'||TO_CHAR(SQ_BCI_SALES_ORDLNS.INVENTORY_ITEM_ID)||'~'||TO_CHAR(SQ_BCI_SALES_ORDLNS.SHIP_FROM_ORG_ID)||'~'||TO_CHAR(INP_CUSTOMER_ACCOUNT_ID)
SDE_FUSION_V1_Adaptorの場合
TO_CHAR(SQ_FULFILLLINEPVO.FulfillLineId)||'~'||TO_CHAR(SQ_FULFILLLINEPVO.FulfillLineInventoryItemId)||'~'||TO_CHAR(SQ_FULFILLLINEPVO.FulfillLineFulfillOrgId)||'~'||TO_CHAR(SQ_FULFILLLINEPVO.HeaderSoldToCustomerId)
記帳における複数のディメンション属性変更を追跡する手順は次のとおりです。
ODIデザイナ・ナビゲータで、「SDE_ORA11510_Adaptor」フォルダ、「SDE_ORAR12Version _Adaptor」フォルダまたは「SDE_FUSION_V1_Adaptor」フォルダを開きます。
販売オーダー明細表のSDEマッピングにある次のメイン・インタフェースを開きます。
SDE_ORA_SalesOrderLinesFact.W_SALES_ORDER_LINE_FS
SDE_FUSION_SalesOrderLinesFact.W_SALES_ORDER_LINE_FS
BOOKING_ID列を探し、前述のとおりマッピング式を変更します。
複数の属性の変更を追跡する場合は、それらの属性のソース列をすべて連結する必要があります。
変更内容をリポジトリに保存します。
表パーティション化は、Human Resourceアプリケーションにメリットを提供します。これは、データ量が多くなる大規模なシステムにおいて特に顕著です。
表パーティション化の主なメリットは次のとおりです。
より高速なETL (変更された表パーティションに対してのみ索引が再構築されるため)。
より高速なレポート(パーティション・プルーニングは、必要なデータを取得するための非常に効率的な方法であるため)。
オプションまたは必須
このタスクはオプションですが、デフォルトではパーティション化されている表はありません。
適用対象
Oracleデータベース上にOracle Business Analytics Warehouseが実装されているシステム。
依存関係
依存関係はありません。
タスク
Human Resource表の表パーティション化に関する最新の推奨事項は、My Oracle Supportの技術ノートに記載されています。これらは、なんらかのアクションを実行する前に必ず参照する必要があります。
ODIには、パーティション化された表の作成に使用できる、表パーティション化ユーティリティが提供されています。このユーティリティは、表に対して特定のパーティション戦略を実装するためにいつでも実行できます。これは再実行可能です。また、必要に応じて戦略を変更するために使用できます。これにより、既存の表のバックアップ、代替用のパーティション化された表の作成、データと索引のコピーが行われます。
たとえば、W_WRKFC_EVT_MONTH_F表で表パーティション化を実装する手順は次のとおりです。
IMPLEMENT_DW_TABLE_PARTITIONSシナリオを実行し、次のパラメータを渡します。
必要に応じてスクリプトをレビューし、パーティション化定義を調整します。
ワークフォース・ファクト表では、月次スナップショット・レコードが指定の日付(HRワークフォース・スナップショット日、デフォルト値は2008年1月1日)で作成されます。そのため、この日付を最初のパーティションの締日にするのが論理的です。その後、月次または四半期ごとにパーティション化することができます。
これを行うには、スクリプトを
CREATE TABLE W_WRKFC_EVT_MONTH_F … PARTITION BY RANGE (EVENT_MONTH_WID) INTERVAL(1) (PARTITION p0 VALUES LESS THAN (1)) …
次のように変更します。
CREATE TABLE W_WRKFC_EVT_MONTH_F … PARTITION BY RANGE (EVENT_MONTH_WID) INTERVAL(3) (PARTITION p0 VALUES LESS THAN (200801)) …
Oracle Business Analytics Warehouseに対して、スクリプトを実行します。
部品構成表(BOM)の機能領域を使用すると、完了した製品を構成するコンポーネントの利益マージンを判断できます。BOMを参照することで、原価および利益の観点から最も有望なベンダーを常に意識しながら、自社の販売組織に、品不足などの配達ステータスを喚起することができます。
BOMを展開するためにE-Business Suiteにオブジェクトを配置する場合は、次のように、E-Business Suiteソース環境がご使用のバージョンの最低パッチ・レベルを満たしていることを確認してください。
Oracle EBSバージョンR12.2.xのユーザーは、パッチ・レベル17457141:R12.BOM.D以上が必要です。
Oracle EBSバージョンR12.0.xまたはOPIパッチ・セットAのユーザーは、パッチ・レベル16507117:R12.OPI.A以上が必要です。
Oracle EBSバージョンR12.1.xまたはOPIパッチ・セットBのユーザーは、パッチ・レベル16507117:R12.OPI.B以上が必要です。
Oracle EBSバージョン11iのユーザーは、パッチ・レベル16506948以上が必要です。
ソース・システムでサポートされているパッチ・レベルの詳細は、Oracle Business Intelligence Applicationsのシステム要件とサポートされているプラットフォームのドキュメントを参照してください。
注意: これらの最低パッチ・レベル以上のシステムには、APPSスキーマのOPI_OBIA_BOMPEXPL_WRAPPER_PまたはOBIA_BOMPEXPL_WRAPPER_Pパッケージが含まれます。OPIまたはBOMスキーマの次の表は、APPSスキーマの別名表として追加されています。
OPI_OBIA_W_BOM_HEADER_DSまたはOBIA_W_BOM_HEADER_DS
OPI_OBIA_BOM_EXPLOSIONまたはOBIA_BOM_EXPLOSION
OBIA_BOM_EXPLOSION_TEMP
部品構成表の展開オプションの構成方法
部品構成表(BOM)の機能領域を使用すると、完了した製品を構成するコンポーネントを分析できます。BOMを参照することで、特定のコンポーネントを使用する製品の数を判断できます。また、完了した製品のBOM階層全体に関する情報を表示できます。
注意: apps_read_onlyユーザーとしてETLを実行するには、最初に次のDCLコマンドをAPPSスキーマから実行する必要があります。
Grant insert on opi.opi_obia_w_bom_header_ds to &read_only_user; Grant analyze any to &read_only_user;
BOM構造は、次の3種類のオプションで展開できます。
すべて。有効日や使用不可日にかかわらず、すべてのBOMコンポーネントは展開されます。BOMコンポーネントの展開とは、BOMツリー構造の展開のことです。
現行。増分抽出ロジックでは、現在有効なすべての変更済コンポーネント、前回の抽出日より後に有効になったコンポーネント、または前回の抽出日より後に使用不可になったコンポーネントが対象となります。
現行および将来。BOMコンポーネントの中で現在有効なもの、または将来有効になるものがすべて展開されます。使用不可のコンポーネントは除外されます。
これらのオプションは、EXPLODE_OPTION変数によって制御されています。EXPLODE_OPTION変数には、値2 (現在のBOM構造を展開)が事前構成されています。
これらのオプションは、EXPLODE_OPTION変数によって制御されています。EXPLODE_OPTION変数には、値2 (現在のBOM構造を展開)が事前構成されています。
ソース・システムには、1 - モデル、2 - オプション・クラス、3 - プランニング、4 - 標準、5 - 製品ファミリという5種類のBOMタイプがあります。デフォルトでは、標準BOMタイプのみが抽出されて展開されます。この選択は、EBS_BOM_TYPEパラメータを使用して制御できます。
SDE_ORA_BOMItemFact_Headerマッピングは、EBSデータベースのOPI_OBIA_BOMPEXPL_PまたはOBIA_BOMPEXPL_Pパッケージを呼び出すことにより、BOM構造を展開します。表B-2に、ストアド・プロシージャの制御に使用する変数を示します。
表B-2 BOM展開用のストアド・プロシージャの変数
入力変数 | 事前構成された値 | 説明 |
---|---|---|
BOM_OR_ENG |
1 |
1—BOM 2—ENG |
COMMIT_POINT |
5000 |
コミットをトリガーするレコード数。 |
COMP_CODE |
該当なし。 |
このパラメータは非推奨であるため、現在はプロシージャの機能に何の影響もありません。 |
CST_TYPE_ID |
0 |
このパラメータは非推奨であるため、現在はプロシージャの機能に何の影響もありません。 |
EXPLODE_OPTION |
2 |
1—すべて 2—現行 3—現行および将来 |
EXPL_QTY |
1 |
展開する数量。 |
IMPL_FLAG |
1 |
1—実装済のみ 2—実装済および未実装 |
LEVELS_TO_EXPLODE |
10 |
展開するレベル数。 |
MODULE |
2 |
1—原価計算 2—BOM 3—受注 4—ATO 5—WSM |
ORDER_BY |
1 |
レコードの順序を制御します。 1—工程連番、品目番号。 2—品目番号、工程連番。 |
PLAN_FACTOR_FLAG |
2 |
1—はい 2—いいえ |
RELEASE_OPTION |
0 |
RELEASE_OPTIONに指定できる値は、次のとおりです。 0 –ステータス6 (実装済)の改訂済品目を含める 1 –ステータス4、6、7 (スケジュール済、実装済、リリース済)の改訂済品目を含める 2 –ステータス1、4、6、7 (オープン、スケジュール済、実装済、リリース済)の改訂済品目を含める 3 –ステータスに関係なく品目を含める |
STD_COMP_FLAG |
0 |
0 –すべてのコンポーネントを除外する 1 –標準コンポーネントのみを展開する 2 –すべてのコンポーネントを展開する 3 –オプション・コンポーネントのみを展開する 注意: STD_CMP_FLAGは、MODULE = 3 (受注)の場合にのみ使用されます。 |
UNIT_NUMBER |
該当なし。 |
入力すると、展開されたコンポーネントを指定したユニットに制限します。 |
VERIFY_FLAG |
0 |
このパラメータは非推奨であるため、現在はプロシージャの機能に何の影響もありません。 |
次のディメンション表には、ソース・アプリケーション・システムからのカスタマイズ可能な値を格納および表示するための20個の汎用属性列があります。
W_PRODUCT_ADDL_ATTR_D
W_PARTY_ORG_ADDL_ATTR_D
W_CUSTOMER_ACCOUNT_D (ベース表自体に新しい属性列が含まれる)
W_INT_ORG_D (ベース表自体に新しい属性列が含まれる)
注意: グループ口座番号および財務取引明細書項目コードの一般的な概念については、「PeopleSoftにおけるグループ口座番号の設定方法」を参照してください。
ユーザーがGL勘定科目を間違ったグループ口座番号にマップすると、ファクト表に間違った会計仕訳が挿入される場合があります。たとえば、AP (買掛金)グループ口座番号に分類される必要のある勘定科目620000が、誤ってAR (売掛金)グループ口座番号に分類されてしまうことがあります。この状態が発生した場合、ETLプログラムによって、ARファクト(W_AR_XACT_F)の補助元帳会計レコードへの勘定科目620000の全GL仕訳の調整が試みられます。これらのGL仕訳明細はARから取得されたものではないため、ETLプログラムでは、当該のGL仕訳明細に対応する補助元帳会計レコードを検出できません。この場合、ETLプログラムによってARファクト表に手動レコードが挿入されます。これらのGL仕訳明細が、GLシステムで直接作成された、AR勘定科目への手動仕訳入力であると見なされるからです。
Peoplesoftのグループ口座番号構成を修正するには、file_group_acct_codes_psft.csvという入力CSVファイルで、GL勘定科目が正しいグループ口座にマッピングされるように修正してください。
値を追加した場合は、BIメタデータ・リポジトリ(RPDファイル)も更新する必要があります。
注意: このタスクの構成ファイル(複数の場合もあり)は、Oracle BI Applicationsインストールの次の場所にあります。 ソース独立ファイル: <Oracle Home for BI>\biapps\etl\data_files\src_files\。 ソース固有ファイル: <Oracle Home for BI>\biapps\etl\data_files\src_files\<source adaptor>。 システム管理者は、これらのファイルを別の場所にコピーして、この場所から読み取るためのODI接続を構成しているはずです。システム管理者に、これらのファイルの取得を依頼してください。構成が完了したら、システム管理者は、構成済ファイルをODIの読取り元にコピーする必要があります。 |
たとえば、修正前のCSVファイルには次の値があります(不適切なグループ口座番号割当て)。
BUSINESS_UNIT = AUS01
FROM ACCT = 620000
TO ACCT = 620000
GROUP_ACCT_NUM = AR
修正後の勘定科目620000は、正しいグループ口座番号「AP」を指しているはずです。また、CSVファイルには次の(修正済の)値が記載されます。
BUSINESS_UNIT = AUS01
FROM ACCT = 620000
TO ACCT = 620000
GROUP_ACCT_NUM = AP
CSVファイルにおけるグループ口座の修正に基づいて、次のETLプロセスがグループ口座を正しく再割当てします。その際に、前回のETLの実行でファクト表に挿入された仕訳入力が修正されます。
JDE_RATE_TYPEパラメータの設定
JD Edwards EnterpriseOneにおけるレート・タイプの概念は、Oracle Business Analytics Warehouseでの定義とは異なります。
オラクル社のJD Edwards EnterpriseOneでは、レート・タイプはオプション・キーであるため、通貨換算レートの計算では使用されません。
ODIでは、JDE_RATE_TYPEパラメータを使用してW_EXCH_RATE_GS表のRate_Typeフィールドを移入します。デフォルトでは、JDE_RATE_TYPEパラメータの値は「Actual」に設定されています。W_EXCH_RATE_Gにおける問合せと参照の実行は、W_EXCH_RATE_G表のRATE_TYPEフィールドに、W_GLOBAL_CURR_G表のGLOBAL1_RATE_TYPEフィールド、GLOBAL2_RATE_TYPEフィールドおよびGLOBAL3_RATE_TYPEフィールドと同じ値が含まれている場合に成功します。
日付をさらに追加するには、オーダー・サイクル時間表への移入方法を理解しておく必要があります。つまり、オーダー・サイクル時間表(W_SALES_CYCLE_LINE_F)にロードされる日付を変更する場合は、W_*表から日付を取得してサイクル時間表にその日付をロードする、完全ロードおよび増分ロード用のインタフェースを両方とも変更する必要があります。
サイクル時間表ロードに日付を追加する手順は次のとおりです。
ODIデザイナ・ナビゲータで、「モデル」→「Oracle BI Applications」→「Oracle BI Applications」→「ファクト」を開きます。
W_SALES_CYCLE_LINE_Fを探し、追加対象の日付を格納するための列を追加します。
たとえば、W_SALES_CYCLE_LINE_F表の検証日をロードする場合は、新しい列VALIDATED_ON_DTを作成してから、W_SALES_CYCLE_LINE_F表のターゲット定義を変更する必要があります。
変更内容を保存します。
「プロジェクト」→「BI Appsプロジェクト」→「マッピング」→「PLP」フォルダを開きます。
「PLP_SalesCycleLinesFact_Load」フォルダを探し、次のいずれかのソース表から新しい列を選択するように、フォルダの下にある各インタフェースを変更してから、そのフォルダをW_SALES_CYCLE_LINE_Fターゲット表にロードします。
W_SALES_ORDER_LINE_F
W_SALES_INVOICE_LINE_F
W_SALES_PICK_LINE_F
W_SALES_SCHEDULE_LINE_F
完全ロードおよび増分ロード用に、一時インタフェースとメイン・インタフェースを変更します。
この項では、Oracle General Ledger勘定科目をグループ口座番号にマップする方法について説明します。その内容は次のとおりです。
Oracle General Ledger勘定科目の設定の概要: 第B.2.18.1項「グループ口座番号へのOracle GL勘定科目のマッピングの概要」を参照してください。
グループ口座番号へのOracle General Ledger勘定科目のマップ方法の説明: 第B.2.18.2項「グループ口座番号へのOracle GL勘定科目コードのマップ方法」を参照してください。
Oracle BI Repositoryへのグループ口座番号メトリックの追加方法の説明: 第B.2.18.3項「論理表「ファクト - 最終 - 転記されたGL仕訳」への新規メトリックの追加方法」を参照してください。
注意: GL勘定科目コードがグループ口座番号(ドメイン値)にマップされることが重要です。GLレポート・レイヤーのメトリックでは、これらの値が使用されるからです。 |
グループ口座番号の構成は、Financial Analyticsの構成における重要な手順です。一般会計および収益性モジュールのほとんどのメトリックの精度は、この手順で決定されるためです。GL調整プロセスでは、グループ口座と一緒に財務取引明細書項目コードも利用することで、補助元帳データがGL仕訳入力と適合していることが確認されます。このトピックの詳細は、この項で後述します。
一般会計勘定科目は、次の構成ファイルを使用して設定します。
file_group_acct_codes_ora.csv: このファイルは、一般会計勘定科目をグループ口座コードにマップします。
注意: このタスクの構成ファイル(複数の場合もあり)は、Oracle BI Applicationsインストールの次の場所にあります。 ソース独立ファイル: <Oracle Home for BI>\biapps\etl\data_files\src_files\。 ソース固有ファイル: <Oracle Home for BI>\biapps\etl\data_files\src_files\<source adaptor>。 システム管理者は、これらのファイルを別の場所にコピーして、この場所から読み取るためのODI接続を構成しているはずです。システム管理者に、これらのファイルの取得を依頼してください。構成が完了したら、システム管理者は、構成済ファイルをODIの読取り元にコピーする必要があります。 |
Oracle General Ledger勘定科目は、特定のグループ口座番号としてカテゴリ化できます。グループ口座番号はデータ抽出のほかに、フロントエンド・レポート処理でも使用されます。GL勘定科目ディメンション表W_GL_ACCOUNT_DのGROUP_ACCT_NUMフィールドは、一般会計勘定科目の内容(例: 現預金勘定科目、給与勘定科目)を示しています。グループ口座番号のドメイン値の一覧については、Oracle Business Analytics Warehouseデータ・モデル・リファレンスを参照してください。一般会計勘定科目コードへのマッピングは、収益性分析と一般会計分析の両方で重要になります(例: 貸借対照表、損益計算書、キャッシュ・フロー明細)。
グループ口座を割り当てるためのロジックは、file_group_acct_codes_ora.csvファイルにあります。表B-3に、file_group_acct_codes_ora.csvファイルのサンプル構成を示します。
表B-3 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 |
表B-3の最初の行では、勘定科目コード101010から101099の範囲内にあり、勘定体系(COA) ID 1を持つすべての勘定科目が流動資産(CA)に割り当てられます。各行では、指定された勘定科目コードの範囲内にあり、特定の勘定体系IDを持つすべての勘定科目がマップされます。
勘定科目コードの新規グループを作成する必要がある場合は、Oracle BI Applications構成マネージャで新規行を作成できます。その後、file_group_acct_codes_ora.csvファイルで、GL勘定科目を勘定科目コードの新規グループに割り当てることができます。
また、Oracle BI Applications構成マネージャで新規行を追加してから、財務取引明細書項目コードを個々のベース表ファクトにマップする必要もあります。表B-4に、グループ口座番号のマップ対象である財務取引明細書項目コードと関連ベース・ファクト表を示します。
表B-4 財務取引明細書項目コードと関連ベース・ファクト表
財務取引明細書項目コード | ベース・ファクト表 |
---|---|
AP |
APベース・ファクト(W_AP_XACT_F) |
AR |
ARベース・ファクト(W_AR_XACT_F) |
COGS |
売上原価ベース・ファクト(W_GL_COGS_F) |
REVENUE |
収益ベース・ファクト(W_GL_REVN_F) |
TAX |
税金ベース・ファクト(W_TAX_XACT_F)脚注 1 |
OTHERS |
GL仕訳ベース・ファクト(W_GL_OTHER_F) |
脚注 1 Financial AnalyticsのE-Business Suiteアダプタでは、税金ベース・ファクト(W_TAX_XACT_F)がサポートされていません。
GL勘定科目をグループ口座番号に対してマッピングした後で、そのグループ口座番号を財務取引明細書項目コードに関連付けると、GL勘定科目コードを財務取引明細書項目コードに間接的に関連付けたことにもなります。この関連付けは、GL調整を実行したり、補助元帳データがGL仕訳入力と適合していることを確認する際に重要になります。GLへの請求書の振替え後に、GLユーザーがその請求書をGLで調整することがあります。このシナリオでは、調整額を補助元帳ベース・ファクトのみでなく、貸借対照表にも反映する必要があります。GLにおけるこのような補助元帳トランザクションを判別するために、調整プロセスでは財務取引明細書項目コードが使用されます。
財務取引明細書項目コードは、補助元帳に対するGL調整プロセスの実行時に、ETLプロセスがGL仕訳レコードの処理に使用する内部コードです。ETLプロセスは、GL仕訳レコードを調整する際に、まず仕訳対象のGL勘定科目に関連付けられた財務取引明細書項目コードを参照します。次に、財務取引明細書項目コードの値を使用して、GL仕訳の調整でどのベース・ファクトを使用するかを決定します。たとえば、仕訳の対象が、財務取引明細書項目コード「AP」に関連付けられたGL勘定科目であるGL仕訳を処理する場合、ETLプロセスによってAPベース・ファクト表(W_AP_XACT_F)が参照され、対応するAP会計仕訳が見つけられます。そのGL勘定科目が財務取引明細書項目コード「REVENUE」に関連付けられている場合は、ETLプログラムによって収益ベース・ファクト(W_GL_REVN_F)が参照され、対応する収益会計仕訳が見つけられます。
この項では、グループ口座番号へのOracle General Ledger勘定科目コードのマップ方法について説明します。
注意: 新しいグループ口座番号をfile_group_acct_codes_<source system type>.csvファイルに追加する場合は、BIメタデータ・リポジトリ(RPDファイル)へのメトリックの追加も必要です。詳細は、第B.2.18.3項「論理表「ファクト - 最終 - 転記されたGL仕訳」への新規メトリックの追加方法」を参照してください。 |
Oracle GL勘定科目コードをグループ口座番号に追加するには:
file_group_acct_codes_ora.csvファイルを編集します。
注意: このタスクの構成ファイル(複数の場合もあり)は、Oracle BI Applicationsインストールの次の場所にあります。 ソース独立ファイル: <Oracle Home for BI>\biapps\etl\data_files\src_files\。 ソース固有ファイル: <Oracle Home for BI>\biapps\etl\data_files\src_files\<source adaptor>。 システム管理者は、これらのファイルを別の場所にコピーして、この場所から読み取るためのODI接続を構成しているはずです。システム管理者に、これらのファイルの取得を依頼してください。構成が完了したら、システム管理者は、構成済ファイルをODIの読取り元にコピーする必要があります。 |
マップするOracle GL勘定科目コードごとに、新しい行を作成します。このファイルには、次のフィールドが含まれています。
フィールド名 | 説明 |
---|---|
CHART OF ACCOUNTS ID |
GL勘定体系のID。 |
FROM ACCT |
勘定科目範囲の下限。これは、GL勘定科目の勘定科目セグメントに基づいています。 |
TO ACCT |
勘定科目範囲の上限。これは、GL勘定科目の勘定科目セグメントに基づいています。 |
GROUP_ACCT_NUM |
このフィールドは、Oracle General Ledger勘定科目のグループ口座番号を示します(Oracle BI Applications構成マネージャのウェアハウス・ドメイン「Group Account」で指定)。たとえば、「AP」は買掛金、「CASH」は現預金勘定科目、「GEN PAYROLL」は給与勘定科目を表しています。 |
例:
101, 1110, 1110, CASH 101, 1210, 1210, AR 101, 1220, 1220, AR
注意: 必要に応じて、CSVファイルから未使用の行を削除できます。 |
file_group_acct_codes_ora.csvファイルで指定した値が、Oracle BI Applications構成マネージャのグループ口座で指定されている値と適合していることを確認します。
CSVファイルを保存して閉じます。
新しいグループ口座番号をfile_group_acct_codes_<source system type>.csvファイルに追加した場合、その新しいグループ口座番号を展開するには、この項の説明に従ってOracle BI EE管理ツールを使用して、Oracle BIリポジトリにメトリックを追加する必要もあります。
このタスクは、次のタスクに適用されます。
E-Business Suiteの場合: 第B.2.18.2項「グループ口座番号へのOracle GL勘定科目コードのマップ方法」
PeopleSoftの場合: 第B.2.19.2項「グループ口座番号へのGL勘定科目コードのマップ方法」
JD Edwardsの場合: 第B.2.36.2項「グループ口座番号へのGL勘定科目コードのマップ方法」
この例は、「給与」(ドメイン・メンバー・コード「PAYROLL」)という新しいグループ口座番号が存在し、「給与経費」というプレゼンテーション・レイヤーに新規メトリックが追加されることを前提としています。
論理表「ファクト - 最終 - その他のGL転記済トランザクション」に新規メトリックを追加するには:
Oracle BI EE管理ツールを使用して、BIメタデータ・リポジトリ(RPDファイル)を編集します。
たとえば、OracleBIAnalyticsApps.rpdファイルは次の場所にあります。
ORACLE_INSTANCE\bifoundation\OracleBIServerComponent\coreapplication_ obis<n>\repository
「ビジネス・モデルとマッピング」レイヤーで、次の操作を行います。
「コア」→「ファクト - 最終 - 転記されたGL仕訳」→「ソース」フォルダを開き、「Fact_W_GL_OTHER_GRPACCT_FSCLPRD_A」ソースをダブルクリックして「論理表ソース」ダイアログを表示します。
「列マッピング」タブを表示します。
「新規列の追加」アイコンをクリックして「論理列」ダイアログを表示します。
「列ソース」タブを表示します。
「式を使用して既存の列から派生」ラジオ・ボタンを選択し、「式の編集」アイコンをクリックします。
式ビルダーで、「カテゴリ」リストの「論理表」を選択します。
式ビルダーを使用して、次のSQL文を指定します。
FILTER("Core"."Fact - Fins - GL Journals Posted"."Transaction Amount" USING "Core"."Dim - GL Account"."Group Account Number" = 'PAYROLL')
「OK」をクリックして「論理列」ダイアログに戻ります。
「OK」をクリックして詳細を保存します。
新しいリポジトリ・オブジェクトをエンド・ユーザーのダッシュボードとレポートに展開するには、新規オブジェクトを「ビジネス・モデルとマッピング」レイヤーから「プレゼンテーション」レイヤーの適切なフォルダにドラッグします。
論理表「ファクト - 最終 - GL残高」に新規メトリックを追加するには:
Oracle BI EE管理ツールを使用して、BIメタデータ・リポジトリ(RPDファイル)を編集します。
たとえば、OracleBIAnalyticsApps.rpdファイルは次の場所にあります。
ORACLE_INSTANCE\bifoundation\OracleBIServerComponent\coreapplication_ obis<n>\repository
「ビジネス・モデルとマッピング」レイヤーで、次の操作を行います。
論理表「ファクト - 最終 - GL残高」に、「給与経費」という論理列名を作成します。
たとえば、「コア」→「ファクト - 最終 - GL残高」オブジェクトに移動し、右クリックしてから「新規オブジェクト」→「論理列」を選択して、「論理列」ダイアログを表示します。「名前」フィールドに、「給与経費」を指定します。
「列ソース」タブで、「式を使用して既存の列から派生」ラジオ・ボタンを選択します。
「式ビルダー」アイコンをクリックして式ビルダーを表示します。
式ビルダーを使用して、次のSQL文を指定します。
FILTER("Core"."Fact - Fins - GL Balance"."Activity Amount" USING "Core"."Dim - GL Account"."Group Account Number" = 'PAYROLL')
フィルタ条件によって、新しいグループ口座番号「PAYROLL」が参照されます。
詳細を保存します。
新しいリポジトリ・オブジェクトをエンド・ユーザーのダッシュボードとレポートに展開するには、新規オブジェクトを「ビジネス・モデルとマッピング」レイヤーから「プレゼンテーション」レイヤーの適切なフォルダにドラッグします。
この項では、一般会計勘定科目をグループ口座番号にマップする方法について説明します。その内容は次のとおりです。
一般会計勘定科目の設定の概要: 第B.2.19.1項「グループ口座番号へのGL勘定科目のマッピングの概要」を参照してください。
グループ口座番号への一般会計勘定科目のマップ方法の説明: 第B.2.19.2項「グループ口座番号へのGL勘定科目コードのマップ方法」を参照してください。
Oracle BI Repositoryへのグループ口座番号メトリックの追加方法を説明する例: 第B.2.18.3項「論理表「ファクト - 最終 - 転記されたGL仕訳」への新規メトリックの追加方法」を参照してください。
注意: GL勘定科目コードがグループ口座番号(ドメイン値)にマップされることが重要です。GLレポート・レイヤーのメトリックでは、これらの値が使用されるからです。GL勘定科目コードのドメイン値の一覧については、Oracle Business Analytics Warehouseデータ・モデル・リファレンスを参照してください。 |
グループ口座番号の構成は、Financial Analyticsの構成における重要な手順です。一般会計および収益性モジュールのほとんどのメトリックの精度は、この手順で決定されるためです。GL調整プロセスでは、グループ口座と一緒に財務取引明細書項目コードも利用することで、補助元帳データがGL仕訳入力と適合していることが確認されます。このトピックの詳細は、この項で後述します。
PeopleSoft一般会計の勘定科目は、特定のグループ口座番号としてカテゴリ化できます。GROUP_ACCT_NUMフィールドは、一般会計勘定科目の内容を示しています。
一般会計勘定科目は、次の構成ファイルを使用して設定します。
file_group_acct_codes_psft.csv: このファイルは、一般会計勘定科目をグループ口座コードにマップします。
注意: このタスクの構成ファイル(複数の場合もあり)は、Oracle BI Applicationsインストールの次の場所にあります。 ソース独立ファイル: <Oracle Home for BI>\biapps\etl\data_files\src_files\。 ソース固有ファイル: <Oracle Home for BI>\biapps\etl\data_files\src_files\<source adaptor>。 システム管理者は、これらのファイルを別の場所にコピーして、この場所から読み取るためのODI接続を構成しているはずです。システム管理者に、これらのファイルの取得を依頼してください。構成が完了したら、システム管理者は、構成済ファイルをODIの読取り元にコピーする必要があります。 |
この例としては、現預金勘定科目、給与勘定科目などがあげられます。グループ口座番号のドメイン値の一覧については、Oracle Business Analytics Warehouseデータ・モデル・リファレンスを参照してください。グループ口座番号構成はデータ抽出のほかに、フロントエンド・レポート処理でも使用されます。たとえば、グループ口座番号構成は、収益性分析(損益計算書)および一般会計分析の両方で頻繁に使用されています。勘定科目を割り当てるためのロジックは、file_group_acct_codes_psft.csvファイルにあります。
表B-5 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)がサポートされていません。
表B-5の最初の行では、勘定科目コード101010から101099の範囲内にあり、ビジネス・ユニットAUS01を含むすべての勘定科目がAPに割り当てられます。各行では、指定された勘定科目コードの範囲内にあり、特定のビジネス・ユニットを持つすべての勘定科目がマップされます。勘定科目コードの新規グループを割り当てる必要がある場合は、file_group_acct_codes_psft.csvファイルで、GL勘定科目を勘定科目コードの新規グループに割り当てることができます。
また、Oracle BI Applications構成マネージャで新規行を追加してから、財務取引明細書項目コードを個々のベース表ファクトにマップする必要もあります。表B-6に、グループ口座番号のマップ対象である財務取引明細書項目コードと関連ベース・ファクト表を示します。
表B-6 財務取引明細書項目コードと関連ベース・ファクト表
財務取引明細書項目コード | ベース・ファクト表 |
---|---|
AP |
APベース・ファクト(W_AP_XACT_F) |
AR |
ARベース・ファクト(W_AR_XACT_F) |
COGS |
売上原価ベース・ファクト(W_GL_COGS_F) |
REVENUE |
収益ベース・ファクト(W_GL_REVN_F) |
TAX |
税金ベース・ファクト(W_TAX_XACT_F)脚注 1 |
OTHERS |
GL仕訳ベース・ファクト(W_GL_OTHER_F) |
脚注 1 Financial AnalyticsのOracle PeopleSoftアダプタでは、税金ベース・ファクト(W_TAX_XACT_F)がサポートされていません。
GL勘定科目をグループ口座番号に対してマッピングした後で、そのグループ口座番号を財務取引明細書項目コードに関連付けると、GL勘定科目コードを財務取引明細書項目コードに間接的に関連付けたことにもなります。この関連付けは、GL調整を実行したり、補助元帳データがGL仕訳入力と適合していることを確認する際に重要になります。GLへの請求書の振替え後に、GLユーザーがその請求書をGLで調整することがあります。このシナリオでは、調整額を補助元帳ベース・ファクトのみでなく、貸借対照表にも反映する必要があります。GLにおけるこのような補助元帳トランザクションを判別するために、調整プロセスでは財務取引明細書項目コードが使用されます。
グループ口座番号をドメイン・メンバーに追加した後で財務取引明細書項目コードにマップするには:
Oracle BI Applications構成マネージャで、「タスク」ペインの「ウェアハウス・ドメインの管理」をクリックし、「ウェアハウス・ドメインの管理」ダイアログを表示します。
「検索」領域で、「オファリング」ドロップダウン・リストの「Oracle Financial Analytics」を選択し、「ドメイン」ドロップダウン・リストの「名前」を選択してから、隣接するテキスト・ボックスに「Group Account」と入力します。
「検索」をクリックしてグループ口座を検索し、「ウェアハウス・ドメイン」領域のグループ口座を選択します。
「ウェアハウス・メンバー」領域までスクロール・ダウンします。
「追加」をクリックして「ターゲット・ドメイン・メンバーの追加」ダイアログを表示し、「コード」および「名前」の各フィールドに、グループ口座番号を指定します。
「タスク」ペインの「ドメイン・マッピングおよび階層の管理」をクリックして、「ドメイン・マッピングおよび階層の管理」を表示します。
「ソース・インスタンス」およびディメンション・グループ「GL勘定科目ディメンション」を選択し、「検索」をクリックします。
「ウェアハウス・ドメイン階層」タブをクリックし、「W_FIN_STMT」の下にある「W_GL_GROUP_ACCOUNT」を選択します。
「ドメイン・メンバー・マッピング」リージョンに移動し、手順5で追加したグループ口座番号ドメイン・メンバーを選択します。
「ターゲット・ドメイン・メンバー」列の財務取引明細書項目をクリック編集(選択)し、この値をグループ口座番号に割り当てます。
変更内容を保存します。
財務取引明細書項目コードは、補助元帳に対するGL調整プロセスの実行時に、ETLプロセスがGL仕訳レコードの処理に使用する内部コードです。ETLプロセスは、GL仕訳レコードを調整する際に、まず仕訳対象のGL勘定科目に関連付けられた財務取引明細書項目コードを参照します。次に、財務取引明細書項目コードの値を使用して、GL仕訳の調整でどのベース・ファクトを使用するかを決定します。たとえば、仕訳の対象が、財務取引明細書項目コード「AP」に関連付けられたGL勘定科目であるGL仕訳を処理する場合、ETLプロセスによってAPベース・ファクト表(W_AP_XACT_F)が参照され、対応するAP会計仕訳が見つけられます。そのGL勘定科目が財務取引明細書項目コード「REVENUE」に関連付けられている場合は、ETLプログラムによって収益ベース・ファクト(W_GL_REVN_F)が参照され、対応する収益会計仕訳が見つけられます。
この項では、グループ口座番号への一般会計勘定科目コードのマップ方法について説明します。
注意: 新しいグループ口座番号をfile_group_acct_codes_<source system type>.csvファイルに追加する場合は、BIメタデータ・リポジトリ(RPDファイル)へのメトリックの追加も必要です。詳細は、第B.2.18.3項「論理表「ファクト - 最終 - 転記されたGL仕訳」への新規メトリックの追加方法」を参照してください。 |
PeopleSoft GL勘定科目コードをグループ口座番号に追加するには:
file_group_acct_codes_psft.csvファイルを編集します。
注意: このタスクの構成ファイル(複数の場合もあり)は、Oracle BI Applicationsインストールの次の場所にあります。 ソース独立ファイル: <Oracle Home for BI>\biapps\etl\data_files\src_files\。 ソース固有ファイル: <Oracle Home for BI>\biapps\etl\data_files\src_files\<source adaptor>。 システム管理者は、これらのファイルを別の場所にコピーして、この場所から読み取るためのODI接続を構成しているはずです。システム管理者に、これらのファイルの取得を依頼してください。構成が完了したら、システム管理者は、構成済ファイルをODIの読取り元にコピーする必要があります。 |
マップするGL勘定科目コードごとに、新しい行を作成します。このファイルには、次のフィールドが含まれています。
フィールド名 | 説明 |
---|---|
BUSINESS_UNIT |
BUSINESS UNITのID。 |
FROM ACCT |
勘定科目範囲の下限。これは、GL勘定科目の勘定科目セグメントに基づいています。 |
TO ACCT |
勘定科目範囲の上限。これは、GL勘定科目の勘定科目セグメントに基づいています。 |
GROUP_ACCT_NUM |
このフィールドは、一般会計勘定科目のグループ口座番号を示します(Oracle BI Applications構成マネージャの「グループ口座」ドメインの「ドメイン」で指定)。たとえば、「AP」は買掛金、「CASH」は現預金勘定科目、「GEN PAYROLL」は給与勘定科目を表しています。 |
例:
AUS01, 1110, 1110, CASH AUS01, 1210, 1210, AR AUS01, 1220, 1220, AR
注意: 必要に応じて、CSVファイルから未使用の行を削除できます。 |
file_group_acct_codes_psft.csvファイルで指定した値が、Oracle BI Applications構成マネージャのドメインで指定されている値と適合していることを確認します。
CSVファイルを保存して閉じます。
この項では、E-Business Suiteの一般会計勘定科目および一般会計セグメントを構成する方法について説明します。その内容は次のとおりです。
Oracle Financial Analytics、Oracle Procurement and Spend AnalyticsまたはOracle Supply Chain and Order Management Analyticsをデプロイする場合、このトピックの説明に従って、GL勘定科目階層を構成する必要があります。
会計フレックスフィールドの格納が可能な、30個のセグメントがサポートされています。フレックスフィールドは、複雑なデータ構成に対応しています。次に例を示します。
すべてのセグメントのデータを格納できます。
勘定体系ごとのセグメント数を、必要に応じて増減できます。
同じ勘定体系に対して、複数のセグメントを指定できます。
1つの会社が、次のデータ構成のUS勘定体系とAPAC勘定体系を採用しているとします。
表B-7 勘定体系の例
セグメント・タイプ | US勘定体系(4256)の値 | APAC勘定体系(4257)の値 |
---|---|---|
会社 |
セグメント3で格納 |
セグメント1で格納 |
勘定科目 |
セグメント4で格納 |
セグメント3で格納 |
コスト・センター |
セグメント5で格納 |
セグメント2で格納 |
地域 |
セグメント2で格納 |
セグメント5で格納 |
ライン・オブ・ビジネス(LOB) |
セグメント1で格納 |
セグメント4で格納 |
この例は、US勘定体系では、「会社」がE-Business Suite表GL_CODE_COMBINATIONSのセグメント3列に格納されることを示しています。APAC勘定体系では、「会社」がGL_CODE_COMBINATIONS表のセグメント1列に格納されます。この構成ファイルの目的は、セグメント情報がOracle Business Analytics Warehouse表W_GL_ACCOUNT_Dに抽出される際に、同じ性質を持つ異なる勘定体系からのセグメントが、W_GL_ACCOUNT_Dの同じ列に格納されるようにすることです。
たとえば、US COAとAPAC COAの「会社」セグメントをW_GL_ACCOUNT_Dのセグメント1列に、US COAとAPAC COAの「コスト・センター」セグメントをW_GL_ACCOUNT_Dのセグメント2列に格納できます。
GL勘定科目のETLプロセスを実行する前に、分析対象のセグメントを指定する必要があります。勘定科目セグメント、貸借一致セグメントおよびコスト・センター・セグメントはデフォルトでマップされていますが、このトピックの説明に従って、追加セグメントを手動でマップする必要があります。
セグメントを指定するには、file_glacct_segment_config_ora.csvという名前のETL構成ファイルを使用します。
注意: このタスクの構成ファイル(複数の場合もあり)は、Oracle BI Applicationsインストールの次の場所にあります。 ソース独立ファイル: <Oracle Home for BI>\biapps\etl\data_files\src_files\。 ソース固有ファイル: <Oracle Home for BI>\biapps\etl\data_files\src_files\<source adaptor>。 システム管理者は、これらのファイルを別の場所にコピーして、この場所から読み取るためのODI接続を構成しているはずです。システム管理者に、これらのファイルの取得を依頼してください。構成が完了したら、システム管理者は、構成済ファイルをODIの読取り元にコピーする必要があります。 |
file_glacct_segment_config_ora.csvでは、同じ種類のセグメントを同じ列で指定する必要があります。たとえば、すべての勘定体系から得られるすべての製品セグメントを1つの列に格納できます。それとは別の列に、すべての勘定体系から得られるすべての地域セグメントを格納できます。
ファイルfile_glacct_segment_config_ora.csvには、ウェアハウスで構成される会計セグメントごとに、3つの列のセットが含まれています。最初の列には、このエンティティが格納されるOracle E-Business Suiteでの実際のセグメント列名を指定します。この列は、SEGMENT1、SEGMENT2....SEGMENT30のような値を取ります(この値は大文字/小文字が区別されます)。2番目の列には、対応するVALUESETIDを指定します。これは、このCOAとOracle E-Business Suiteのセグメントに使用されているものです。3番目の列は、最初の列に依存セグメントを構成している場合にのみ構成が必要になります。最初の列のセグメントが依存セグメントの場合は、そのセグメントが依存するOracle E-Business Suiteのセグメント名を指定します。依存セグメントがない場合、CSVファイルのこの列は空欄のままにします。
たとえば、次に示す処理が必要になるとします。
製品、地域および場所のみを使用して、GL勘定科目階層を分析する。
W_GL_ACCOUNT_DのACCOUNT_SEG1_CODE列に含まれるすべてのCOAから得られるすべての製品セグメントを格納する。
W_GL_ACCOUNT_DのACCOUNT_SEG2_CODE列に含まれるすべてのCOAから得られるすべての地域セグメントを格納する。
W_GL_ACCOUNT_DのACCOUNT_SEG3_CODE列に含まれるすべてのCOAから得られるすべての場所セグメントを格納する。
次に示すように、EBSで3つの異なるCOA (101、50194および50195)を定義しています。
COA 101の場合、製品はSEGMENT1、地域はSEGMENT2、場所はSEGMENT3です。
COA 50194の場合、製品はSEGMENT2、地域はSEGMENT3、場所はSEGMENT1です。
COA 50195の場合、製品はSEGMENT3、地域はSEGMENT1、場所はSEGMENT2です。
COA 50195では、地域セグメントと場所セグメントの両方が製品セグメントに依存しています。
図B-2は、この構成値をCSVファイルで指定する方法を示しています。
注意: Oracle BI Applications 7.9.6.xからアップグレードしている場合、コスト・センター、貸借一致セグメントおよび勘定科目セグメントは、デフォルトでマッピングされています。file_glacct_segment_config_ora.csvファイルでは、コスト・センター、貸借一致セグメントおよび勘定科目セグメントについてマッピングする必要はありません。前述の例は、追加のセグメントをマッピングする方法の説明のみを目的として示されています。
予算管理のためのGLセグメントの構成
予算管理の場合、最初の2つのセグメントは、それぞれプロジェクト・セグメントとプログラム・セグメント用に予約されています。そのため、これらのどちらか(または両方)を使用する場合は、このとおりの順序でfile_glacct_segment_config_ora.csvを構成してください。
file_glacct_segment_config_ora.csvファイルを編集します。
プロジェクト・セグメントの列名を'SEG_PROJECT'列で指定します。
プログラム・セグメントの列名を'SEG_PROGRAM'列で指定します。
プロジェクト・セグメントとプログラム・セグメントが別のセグメントに依存している場合は、それらのセグメントの列名をそれぞれ'PROJECT_DEP'列と'PROGRAM_DEP'列で指定します。
ソース・システムで予約されているセグメントがない場合、そのセグメントは空のままにします。
ファイルを保存します。
追加情報
次に示すSQL文の例は、Oracle E-Business Suiteデータベースに対するものであり、GL勘定体系全体の設定を出力します。この出力には、file_glacct_segment_config_ora.csvファイルの設定に必要な必須情報が含まれています。
SELECT ST.ID_FLEX_STRUCTURE_CODE "Chart of Account Code" ,SG.ID_FLEX_NUM "Chart of Account Num" ,SG.SEGMENT_NAME "Segment Name" ,SG.APPLICATION_COLUMN_NAME "Column Name" ,SG.FLEX_VALUE_SET_ID "Value Set Id" ,SG1.APPLICATION_COLUMN_NAME "Parent Column Name" FROM FND_ID_FLEX_STRUCTURES ST INNER JOIN FND_ID_FLEX_SEGMENTS SG ON ST.APPLICATION_ID = SG.APPLICATION_ID AND ST.ID_FLEX_CODE = SG.ID_FLEX_CODE AND ST.ID_FLEX_NUM = SG.ID_FLEX_NUM INNER JOIN FND_FLEX_VALUE_SETS VS ON SG.FLEX_VALUE_SET_ID = VS.FLEX_VALUE_SET_ID LEFT OUTER JOIN FND_ID_FLEX_SEGMENTS SG1 ON VS.PARENT_FLEX_VALUE_SET_ID = SG1.FLEX_VALUE_SET_ID AND SG.ID_FLEX_NUM = SG1.ID_FLEX_NUM AND SG.APPLICATION_ID = SG1.APPLICATION_ID AND SG.ID_FLEX_CODE = SG1.ID_FLEX_CODE WHERE ST.APPLICATION_ID = 101 AND ST.ID_FLEX_CODE = 'GL#' AND ST.ENABLED_FLAG = 'Y' ORDER BY 1,2,3;
たとえば、勘定体系が2つのあり、このSQL文により、その2つの勘定体系の設定が次のように表示されたとします。
Chart of Account Code Chart of Account Num Segment Name Column Name Value Set Id Parent Column Name US_ACCOUNTING_FLEX 101 Region SEGMENT1 1026447 US_ACCOUNTING_FLEX 101 Product SEGMENT2 1026448 SEGMENT1 US_ACCOUNTING_FLEX 101 Sub-Account SEGMENT3 1026449 SEGMENT1 EU_ ACCOUNTING_FLEX 201 Region SEGMENT1 1031001 EU_ ACCOUNTING_FLEX 201 Department SEGMENT2 1031002 EU_ ACCOUNTING_FLEX 201 Product SEGMENT3 1031003 EU_ ACCOUNTING_FLEX 201 Sub Account SEGMENT4 1031004
これらすべてのセグメントがBIで必要になり、それらのセグメントはBIで次のようにマップすることになります。
- 地域をSeg1にマップする
- 製品をSeg2にマップする
- 補助勘定科目をSeg3にマップする
- 部門をSeg4にマップする
注意:
- 部門はCOA 201にのみ適用できます。
- COA 101には、依存セグメントとして製品セグメントと補助勘定科目セグメントがあります。
図B-3は、この構成値をCSVファイルで指定する方法を示しています。
注意: このタスクの構成ファイル(複数の場合もあり)は、Oracle BI Applicationsインストールの次の場所にあります。 ソース独立ファイル: <Oracle Home for BI>\biapps\etl\data_files\src_files\。 ソース固有ファイル: <Oracle Home for BI>\biapps\etl\data_files\src_files\<source adaptor>。 システム管理者は、これらのファイルを別の場所にコピーして、この場所から読み取るためのODI接続を構成しているはずです。システム管理者に、これらのファイルの取得を依頼してください。構成が完了したら、システム管理者は、構成済ファイルをODIの読取り元にコピーする必要があります。 |
次に示すように、file_glacct_segment_config_ora.csvを構成します。
file_glacct_segment_config_ora.csvファイルを編集します。
たとえば、\src_files\EBS11510にあるファイルを編集します。
第B.2.20.3項「GLセグメントの構成ファイルの設定方法」の手順を実行して、ファイルを構成します。
値セット定義を使用したGLセグメントと階層のためのBIメタデータ・リポジトリ(RPDファイル)を編集します。
このメタデータには、複数の論理表が含まれています。この論理表は、Dim_W_GL_SEGMENT_D_ProgramSegment、Dim_W_GL_SEGMENT_D_ProjectSegment、Dim_W_GL_SEGMENT_D_Segment1などの各GLセグメントを表しています。これらの論理表は、すべて同一の物理表W_GL_SEGMENT_Dにマッピングされているため、該当するセグメントに関する値を取得するには、これらの論理表の論理表ソースにフィルタを指定して論理表の出力を限定する必要があります。物理列SEGMENT_LOV_IDから該当するセグメントに適した値セットIDへのフィルタを設定する必要があります。値セットIDのリストは、前述したCSVファイルで構成した値セットIDと同じになります。
次に示すように、Oracle BI Repositoryの「ビジネス・モデルとマッピング」レイヤーでフィルタを指定します。
Oracle BI EE管理ツールで、BIメタデータ・リポジトリ(例: OracleBIAnalyticsApps.rpd)を編集します。
OracleBIAnalyticsApps.rpdファイルは、ORACLE_INSTANCE\bifoundation\OracleBIServerComponent\coreapplication_obis<n>\repositoryにあります。
各論理表(例: ディメンション - GLセグメント1)を開いて、その論理表の論理表ソースを開きます。「内容」タブを表示します。「このWHERE句を使用する...」ボックスで、W_GL_SEGMENT_Dの対応する物理表の別名にフィルタを適用します。
例: "Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_GL_SEGMENT_D_Segment1"."SEGMENT_LOV_ID" IN (カンマ区切り値のID)。
このセグメントに対応する値セットIDをカンマで区切ってすべて入力します。
Oracle Financial Analyticsは、GL勘定科目ディメンションで最大30個のセグメントをサポートしています。デフォルトでは、BIメタデータ・リポジトリ(RPDファイル)で10個のGLセグメント・ディメンションを使用できます。10個より多くのGLセグメントが必要な場合は、次の手順を実行して新しいセグメントを追加してください。
「物理レイヤー」で、次の操作を実行します。
W_GL_SEGMENT_Dの新しい物理的な2つの別名(Dim_W_GL_SEGMENT_D_SegmentXXとDim_W_GL_SEGMENT_D_SegmentXX_GLAccount)を作成します。
これを行うには、物理表W_GL_SEGMENT_Dを右クリックして、「新規オブジェクト」→「別名」の順に選択します。新しい別名として"Dim_W_GL_SEGMENT_D_SegmentXX"および"Dim_W_GL_SEGMENT_D_SegmentXX_GLAccount"という名前を付けます。
次に示すように、W_GL_SEGMENT_DHの4つの新しい別名を作成します。
- 'Dim_W_GL_SEGMENT_DH_SegmentXX'
- 'Dim_W_GL_SEGMENT_DH_Security_SegmentXX'
- 'Dim_W_GL_SEGMENT_DH_SegmentXX_GLAccount'
- 'Dim_W_GL_SEGMENT_DH_Security_SegmentXX_GLAccount'
'Dim_W_GL_SEGMENT_D_SegmentXX'から'Dim_W_GL_SEGMENT_DH_SegmentXX'と'Dim_W_GL_SEGMENT_DH_Security_SegmentXX'への外部キーを作成します。
'Dim_W_GL_SEGMENT_D_Segment1'から'Dim_W_GL_SEGMENT_DH_Segment1'と'Dim_W_GL_SEGMENT_DH_Security_Segment1'への外部キーは同様のものになります。
外部キーの方向は、W_GL_SEGMENT_DHからW_GL_SEGMENT_Dに向ける必要があります。たとえば、'0/1': Nカーディナリティの結合では、W_GL_SEGMENT_DHが'0/1'側になり、W_GL_SEGMENT_Dは'N'側になります。物理外部キー結合の作成方法の詳細は、Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ作成者ガイドを参照してください。
'Dim_W_GL_SEGMENT_D_SegmentXX_GLAccount'から'Dim_W_GL_SEGMENT_DH_SegmentXX_GLAccount'と'Dim_W_GL_SEGMENT_DH_Security_SegmentXX_GLAccount'への同様の物理外部キーを作成します。
前述したように、Dim_W_GL_SEGMENT_D_SegmentXXとDim_W_GL_ACCOUNT_Dとの間の物理外部キー結合は、W_GL_SEGMENT_Dを'1'側にし、W_GL_ACCOUNT_Dを'N'側にして作成します。
変更内容を保存します。
「ビジネス・モデルとマッピング」レイヤーで、次を実行します。
「ディメンション - GLセグメント1」と同様の新しい論理表「ディメンション - GLセグメントXX」を作成します。
この論理表には、前述の手順で作成した物理表にマッピングした論理表ソースを含める必要があります(たとえば、この論理表に、Dim_W_GL_SEGMENT_DH_SegmentXXとDim_W_GL_SEGMENT_DH_SegmentXX_GLAccountを含めるようにします)。
また、この論理表には、それぞれの物理表(Dim_W_GL_SEGMENT_DH_SegmentXXとDim_W_GL_SEGMENT_DH_SegmentXX_GLAccount)に適切にマップされた「ディメンション - GLセグメント1」と同様の属性をすべて含める必要があります。
「ビジネス・モデル図」で、「ディメンション - GLセグメント1」と同様に、「ディメンション - GLセグメントXX」から関連するすべての論理ファクト表への論理結合を作成します。このとき、GLセグメント・ディメンション論理表を'0/1'側にして、論理ファクト表を'N'側にします。
関連するすべての論理ファクト表を確認するには、まず、「ビジネス・モデル図」にディメンション - GLセグメント1を含めてから、その表を右クリックして「直接結合の追加」を選択します。
前述の手順で説明したように、「ディメンション - GLセグメントXX」の論理表ソースにコンテンツ・フィルタを追加します。
「ディメンション - GLセグメントXX」を右クリックし、「ディメンションの作成」を選択することでディメンションを作成します。これの名前を「GLセグメントXX」に変更します。ドリルダウン構造が、「GLセグメント1」と同様になっていることを確認します。
この方法がわからない場合は、次の手順を実行してください。デフォルトでは、ディメンションには総計レベルと詳細レベルの2つのレベルが含まれています。これらのレベルの名前を、それぞれ「すべて」および「詳細 - GLセグメント」に変更します。
「すべて」レベルを右クリックして、「新規オブジェクト」→「子レベル」を選択します。このレベルに、「ツリー・コードとバージョン」という名前を付けます。「ツリー・コードとバージョン」の下にレベルを作成して、そのレベルに「レベル31」という名前を付けます。同様に、「レベル31」の下に「レベル30」というレベルを作成します。「レベル2」の下に「レベル1」が含まれるまで、この手順を繰り返します。
「詳細 - GLセグメント」レベルを「レベル1」の下にドラッグして、このレベルがレベル階層の最後から2番目のレベルになるようにします。「詳細 - GLセグメント」の下に別の子レベルを作成して、そのレベルに「詳細 - GL勘定科目」という名前を付けます。
新しい論理表「Dim - GLセグメントXX」から、階層の「詳細 - GLセグメント」レベルに、セグメント・コード属性、セグメント名属性、セグメント摘要属性、セグメント・コードID属性およびセグメント値セット・コード属性をドラッグします。同様に、次に示す列を残りのレベルに取り込みます。
詳細 – GL勘定科目 – セグメント・コード – GL勘定科目
レベルxx – レベルxxコード、レベルxx名、レベルxx摘要およびレベルxxコードId
ツリー・コードとバージョン – ツリー・フィルタ、ツリー・バージョンID、ツリー・バージョン名およびツリー・コード
各レベルのプロパティに移動します。「キー」タブから、後述するように、各レベルに該当するキーを作成します。次のマトリックスで示すように、レベルごとに主キーと「表示に使用」オプションを選択します。
表B-8 値セット定義を使用したGLセグメントと階層の構成値
レベル | キー名 | 列 | そのレベルの主キー | 表示に使用するかどうか |
---|---|---|---|---|
ツリー・コードとバージョン |
ツリー・フィルタ |
ツリー・フィルタ |
Y |
Y |
レベルxx |
レベルxxコード |
レベルxxコード |
Y |
Y |
レベルxx |
レベルxx ID |
レベルxxコードId |
<空> |
<空> |
詳細 - GLセグメント |
セグメントID |
セグメント・コードId |
Y |
<空> |
詳細 - GLセグメント |
セグメント・コード |
セグメント値セット・コードとセグメント・コード |
<空> |
Y |
詳細 - GL勘定科目 |
セグメント・コード - GL勘定科目 |
セグメント・コード - GL勘定科目 |
Y |
Y |
これらの新しいレベルを作成したら、新しく作成した論理表「ディメンション - GLセグメントXX」のすべての論理表ソースに対して集計内容を設定する必要があります。各LTSの「内容」タブで、次に示すように「集計内容」を設定します。
Dim_W_GL_SEGMENT_DH_SegmentXX: 内容レベルを「詳細 - GLセグメント」に設定します。
Dim _W_GL_SEGMENT_DH_SegmentXX_GLAccount: これを「詳細 - GL勘定科目」に設定します。
集計内容を関連するすべてのファクト論理表ソースに設定します。新しい論理表に関連するすべての論理ファクト表の論理表ソースを一度にすべて開きます。「内容」タブを表示します。LTSが新しく作成したセグメントに該当する場合は、集計内容を「詳細 - GL勘定科目」に設定します。それ以外の場合は、その論理表ソースを省略して、次の論理表ソースに進みます。
新しい「ディメンション - GLセグメントXX」ディメンションを「プレゼンテーション」レイヤーの該当するサブジェクト領域にドラッグします。通常、これらのGLセグメント・ディメンションは、GL勘定科目ディメンションが公開されているどのサブジェクト領域でも公開できます。また、「ディメンション - GLセグメント1」を右クリックして、「問合せ関連オブジェクト」→「プレゼンテーション」→「サブジェクト領域」の順に選択することで、該当するすべてのサブジェクト領域を見つけることもできます。
変更内容を保存して、グローバルな整合性をチェックします。
各GLセグメントは、OLTPで特定の意味を持つ値セットを表します。レポートに含まれる各セグメントを明確に識別するために、プレゼンテーション表「GLセグメントX」、論理ディメンション「GLセグメントX」、および論理表「ディメンション - GLセグメントX」の名前は、それらの意味に応じて変更してください。
たとえば、製品セグメントをSegment1に移入する場合、論理表「ディメンション - GLセグメント1」の名前を「ディメンション - GLセグメント製品」のような名前に変更するか、その他の適切な名前を付けて、それに応じて表の名前を「プレゼンテーション」レイヤーで変更します。
Oracle Business Analytics WarehouseのGL勘定科目ディメンションは、詳細度がチャートフィールドの組合せになります。PeopleSoft Financialsには、GL勘定科目に関するいくつかのチャートフィールド(勘定科目、代替勘定科目、業務ユニット、部門など)が用意されています。ETLプログラムにより、これらのチャートフィールド(使用しているもの)の組合せで考えられるものがすべて抽出され、これらのチャートフィールドのそれぞれが個別にGL勘定科目ディメンションに格納されます。これより、次に示すPeopleSoft勘定科目エントリ表から使用されているチャートフィールドの組合せが抽出されます。
PS_VCHR_ACCTG_LINES (買掛金)
PS_ITEM_DST (売掛金)
PS_BI_ACCT_ENTRY (請求)
PS_CM_ACCTG_LINE (原価計算)
PS_JRNL_LN (総勘定元帳)
Oracle Business Analytics WarehouseのGL勘定科目ディメンション(W_GL_ACCOUNT_D)には、最大30種のチャートフィールドに適合する柔軟で汎用的なデータ・モデルが用意されています。これらは、ACCOUNT_SEG1_CODE、ACCOUNT_SEG2_CODE、...、ACCOUNT_SEG30_CODEという名前が付けられた汎用列に格納されます。これ以降、これらの列をセグメントと呼びます。これらの列には、PeopleSoftアプリケーションで使用されている実際のチャートフィールド値が格納されます。
PeopleSoftチャートフィールドのマッピング
file_glacct_segment_config_psft.csvという名前のCSVファイルは、PeopleSoftチャートフィールドを汎用セグメントにマッピングするために用意されています。
注意: このタスクの構成ファイル(複数の場合もあり)は、Oracle BI Applicationsインストールの次の場所にあります。 ソース独立ファイル: <Oracle Home for BI>\biapps\etl\data_files\src_files\。 ソース固有ファイル: <Oracle Home for BI>\biapps\etl\data_files\src_files\<source adaptor>。 システム管理者は、これらのファイルを別の場所にコピーして、この場所から読み取るためのODI接続を構成しているはずです。システム管理者に、これらのファイルの取得を依頼してください。構成が完了したら、システム管理者は、構成済ファイルをODIの読取り元にコピーする必要があります。 |
このファイルの最初の行は、ヘッダー行です。この行は変更しないでください。このファイルの2番目の行では、マッピングの方法を指定します。ROW_ID列の値は、'1'にハードコードされています。これを変更する必要はありません。
このファイルには、30の列(SEG1、SEG2、からSEG30まで)が含まれている点に注意してください。これらの各列に値を移入するためのチャートフィールドの指定が必要になります。それには、チャートフィールドでサポートされる値のいずれかを指定します。次のリストは、PeopleSoftアプリケーションで現在サポートされているチャートフィールドを示しています。
注意: これらの値は大文字と小文字が区別されます。次のリストに示したとおりに、正確に値を指定する必要があります。 |
Activity ID
Affiliate
Alternate Account
Analysis Type
Book Code
Budget Reference
Budget Scenario
Business Unit PC
ChartField 1
ChartField 2
ChartField 3
Class Field
Fund Affiliate
GL Adjust Type
Operating Unit
Operating Unit Affiliate
Product
Program Code
Project
Resource Category
Resource Sub Category
Resource Type
Statistics Code
注意: CSVファイルに含める必要のあるチャートフィールドは、マッピングするチャートフィールドのみです。 |
ユーザーがGL勘定科目を間違ったグループ口座番号にマップすると、ファクト表に間違った会計仕訳が挿入される場合があります。たとえば、AP (買掛金)グループ口座番号に分類される必要のある勘定科目1210が、誤ってAR (売掛金)グループ口座番号に分類されてしまうことがあります。この状態が発生した場合、ETLプログラムにより、すべてのGL仕訳明細が勘定科目1210に割り付けられ、それらのGL仕訳明細をARファクト表(W_AR_XACT_F)の補助元帳会計レコードに照らし合せた調整が試行されます。これらのGL仕訳明細はARから得られるものではないため、ETLプログラムでは、これらのGL仕訳明細に対応する補助元帳会計レコードを検出できません。この場合、ETLプログラムによってARファクト表に手動レコードが挿入されます。これらのGL仕訳明細が、GLシステムで直接作成された、AR勘定科目への手動仕訳入力であると見なされるからです。
注意: このタスクの構成ファイル(複数の場合もあり)は、Oracle BI Applicationsインストールの次の場所にあります。 ソース独立ファイル: <Oracle Home for BI>\biapps\etl\data_files\src_files\。 ソース固有ファイル: <Oracle Home for BI>\biapps\etl\data_files\src_files\<source adaptor>。 システム管理者は、これらのファイルを別の場所にコピーして、この場所から読み取るためのODI接続を構成しているはずです。システム管理者に、これらのファイルの取得を依頼してください。構成が完了したら、システム管理者は、構成済ファイルをODIの読取り元にコピーする必要があります。 |
E-Business Suiteにおけるグループ口座番号構成の修正方法は、次のとおりです。
GL勘定科目からグループ口座へのマッピングをfile_group_acct_codes_ora.csvという名前の入力CSVファイルで修正します。
たとえば、修正前のCSVファイルには次の値があります(不適切なグループ口座番号割当て)。
CHART OF ACCOUNTS ID = 101
FROM ACCT = 2210
TO ACCT = 2210
GROUP_ACCT_NUM = AR
修正後の勘定科目2210は、正しいグループ口座番号「AP」を指すようになります。また、CSVファイルには次の(修正済の)値が記載されます。
CHART OF ACCOUNTS ID = 101
FROM ACCT = 2210
TO ACCT = 2210
GROUP_ACCT_NUM = AP
ファイルを保存します。
CSVファイルで修正したグループ口座に基づいて、次回のETLプロセスではグループ口座が正しく再割当されます。また、前回のETLの実行でファクト表に作成された仕訳入力が修正されます。
特定のメトリックが適切に機能するためには、Oracle BI Applicationsメタデータ・リポジトリ(RPDファイル)で、次に示す2つの内部メトリックを構成する必要があります。
経過日数
累積経過日数
これらのメトリックは、その他のメトリック(売掛債権回転日数、買掛債権回転日数、AP回転率、AR回転率など)の計算に影響します。
日数ベースのメトリックを構成するには:
Oracle BI EE管理ツールで、BIメタデータ・リポジトリ(例: OracleBIAnalyticsApps.rpd)を編集します。
このRPDファイルは、次の場所にあります。
ORACLE_INSTANCE\bifoundation\OracleBIServerComponent\coreapplication_obisn\repository
「ビジネス・モデルとマッピング」レイヤーで、論理表「ファクト - 最終 - 日数カウント期間」を見つけます。
「ソース」で、Fact_W_DAY_D_PSFT論理表ソースを選択します。
「一般」タブで、「無効化」オプションを選択解除して「OK」をクリックします。
その他の2つの論理表ソース(Fact_W_DAY_D_ORAとFact_W_DAY_D_JDE)を開いて、「無効化」オプションを選択します。
「ファクト - 最終 - 日数カウント期間」論理表と「ディメンション - 法的エンティティ」論理表を「ビジネス・モデル図」に追加します。これを行うには、それらのオブジェクトを右クリックして、「ビジネス・モデル図」→「選択された表のみ」の順に選択します。
「ビジネス・モデル図」で、「ディメンション - 法的エンティティ」から「ファクト - 最終 - 日数カウント期間」への新しい論理結合を作成します。外部キーの方向は、「ディメンション - 法的エンティティ」論理表から「ファクト - 最終 - 日数カウント期間」表に向ける必要があります。たとえば、(0,1):Nカーディナリティの結合の場合、「ディメンション - 法的エンティティ」を(0/1)側にして、「ファクト - 最終 - 日数カウント期間」をN側にします。
「ファクト - 最終 - 日数カウント期間」論理表の下で、「経過日数」を開きます。「レベル」タブに移動します。法的エンティティ・ディメンションには、「論理レベル」が「すべて」に設定されています。「X」ボタンをクリックして、この設定を削除してください。
「ファクト - 最終 - 日数カウント期間」論理表の下で、「累積経過日数」を開きます。「レベル」タブに移動します。法的エンティティ・ディメンションには、「論理レベル」が「すべて」に設定されています。「X」ボタンをクリックして、この設定を削除してください。
グローバルな整合性をチェックし、エラーがないことを確認してから、BIメタデータ・リポジトリ(RPDファイル)を保存します。
データソース固有のダッシュボード・プロンプトには、すべてのアプリケーションのダッシュボード・ページを通してソース固有のフィルタ処理を調整するFinancial Analyticsが備わっています。表B-9に示した各PeopleSoftダッシュボード・プロンプトは、アプリケーション構成プロセスの一環として、そのプロンプトに関連するダッシュボード・ページに追加する必要があります。
表B-9 事前構成済のPeopleSoftパスおよびプロンプト名を備えたFinancial Analyticsのダッシュボード・ページ
ダッシュボード | ダッシュボード・ページ | 共有フォルダ/会計/分析ライブラリ | PeopleSoftプロンプト名 |
---|---|---|---|
一般会計 |
概要 |
/一般会計/キー比率 |
Oracle PSFT - GLキー比率プロンプト |
一般会計 |
貸借対照表 |
/一般会計/貸借対照表 |
Oracle PSFT - GL貸借対照表プロンプト |
一般会計 |
キャッシュ・フロー |
/一般会計/キャッシュ・フロー |
Oracle PSFT - GLキャッシュ・フロー・プロンプト |
一般会計 |
予算対実績 |
/一般会計/予算対実績 |
Oracle PSFT - GL予算プロンプト |
一般会計 |
資産利用 |
/一般会計/資産利用 |
Oracle PSFT - GL資産利用プロンプト |
一般会計 |
流動性 |
/一般会計/流動性 |
Oracle PSFT - GL流動性プロンプト |
一般会計 |
財務体系 |
/一般会計/財務体系 |
Oracle PSFT - GL財務体系プロンプト |
一般会計 |
GL残高 |
/一般会計/トランザクション |
Oracle PSFT - GL残高トランザクション・プロンプト |
一般会計 |
残高試算表 |
/一般会計/残高試算表 |
Oracle PSFT - GL残高試算表プロンプト |
買掛管理 |
概要 |
/買掛管理/概要 |
Oracle PSFT - AP概要プロンプト |
買掛管理 |
AP残高 |
/買掛管理/AP残高 |
Oracle PSFT - AP残高プロンプト |
買掛管理 |
支払未払 |
/買掛管理/支払未払 |
Oracle PSFT - AP支払未払プロンプト |
買掛管理 |
有効性 |
/買掛管理/有効性 |
Oracle PSFT - AP有効性プロンプト |
買掛管理 |
支払実績 |
/買掛管理/支払実績 |
Oracle PSFT - AP支払実績プロンプト |
買掛管理 |
サプライヤ・レポート |
/買掛管理/サプライヤ・レポート |
Oracle PSFT - APサプライヤ・レポート・プロンプト |
買掛管理 |
保留および割引 |
/買掛管理/サプライヤ・レポート |
Oracle PSFT - AP保留および割引プロンプト |
買掛管理 |
請求書詳細 |
/買掛管理/請求書詳細 |
Oracle PSFT - AP請求書詳細プロンプト |
買掛管理 |
全APトランザクション |
/買掛管理/全APトランザクション |
Oracle PSFT - APトランザクション・プロンプト |
収益性 |
概要 |
/収益性/概要 |
Oracle PSFT - GL収益性の概要プロンプト |
収益性 |
損益計算書 |
/収益性/損益計算書 |
Oracle PSFT - GL収益性の損益計算書プロンプト |
収益性 |
マージン |
/収益性/マージン |
Oracle PSFT - GL収益性のマージン・プロンプト |
収益性 |
収益 |
/収益性/収益 |
Oracle PSFT - GL収益性の収益プロンプト |
収益性 |
製品 |
/収益性/製品 |
Oracle PSFT - GL収益性の製品プロンプト |
収益性 |
顧客 |
/収益性/顧客 |
Oracle PSFT - GL収益性の顧客プロンプト |
売掛管理 |
概要 |
/売掛管理/概要 |
Oracle PSFT - AR概要プロンプト |
売掛管理 |
AR残高 |
/売掛管理/AR残高 |
Oracle PSFT - AR残高プロンプト |
売掛管理 |
支払未払 |
/売掛管理/支払未払 |
Oracle PSFT - AR支払未払プロンプト |
売掛管理 |
有効性 |
/売掛管理/有効性 |
Oracle PSFT - AR有効性プロンプト |
売掛管理 |
支払実績 |
/売掛管理/支払実績 |
Oracle PSFT - AR支払実績プロンプト |
売掛管理 |
顧客レポート |
/売掛管理/顧客レポート |
Oracle PSFT - AR顧客プロンプト |
売掛管理 |
請求書詳細 |
/売掛管理/請求書詳細 |
Oracle PSFT - AR請求書詳細プロンプト |
売掛管理 |
全ARトランザクション |
/売掛管理/全ARトランザクション |
Oracle PSFT - ARトランザクション・プロンプト |
PeopleSoftプロンプトでダッシュボード・ページを更新するには:
ここに示す手順では、プロンプトの変更方法の一例として、「一般会計」ダッシュボードの「概要」ページ・プロンプトを変更する方法について説明します。
ダッシュボード・ページにアクセスします。
「ページ・オプション」ボタンをクリックし、「ダッシュボードの編集」を選択してダッシュボード・エディタを起動します。
既存のダッシュボード・プロンプトをダッシュボード・エディタで最上部のセクションから削除します。
「一般会計」ダッシュボードの「概要」ページの場合は、「セクション1」から「Oracle FUSION - GLキー比率プロンプト」を削除します。
注意: セクションを削除するのではなく、プロンプトを削除してください。 |
「保存したコンテンツ」領域の選択ペインから、このダッシュボード・ページに使用するダッシュボード・プロンプトが格納されている共有フォルダを参照します。
「一般会計」ダッシュボードの「概要」ページの場合は、次の場所にカタログ・パスが格納されています。
/Shared folders/Financials/Analytic Library/General Ledger/Key Ratios Prompt name: Oracle PSFT - GL Key Ratios Prompt
共有フォルダからダッシュボード・プロンプトをドラッグして、手順3で削除したプロンプトのセクションにドロップします。
「保存」ボタンをクリックして、ダッシュボード・ページを保存し、ダッシュボード・エディタを終了します。
これにより、PeopleSoftプロンプトでダッシュボード・ページを更新します。
表B-9に示したFinancial Analyticsのすべてのダッシュボード・ページに対して、これらの手順を繰り返します。
概要
E-Business Suiteでは、ジョブ求人ステータスがOLTPで履歴情報として保存されません。そのため、ジョブ求人ステータスが変化すると(たとえば、求人起案、承認済、開示、クローズ済の順に変化すると)、OLTPは最後のステータスのみを保存します。
Oracle Business Analytics Warehouseでは、ジョブ求人オープン開示イベントが重要なイベントになります。いくつかのジョブ求人メトリック(ジョブ求人の開示からアセスメント開始までの日数、ジョブ求人開示以降(日数)、ジョブ求人経過時間(月数)、ジョブ求人開示済、ジョブ求人開示、ジョブ求人開示(期間開始)など)は、このイベントに依存するためです。そのため、ジョブ求人開始日に発生する当初ジョブ求人ステータス・イベントを構成して、このイベントを追跡する必要があります。
このタスクでは、ジョブ求人「開始」イベントを構成します。
オプションまたは必須
これは、必須のタスクです。ただし、インストール済のソリューションでは、すでにデフォルトの設定が行われています。この項を読んでから、デフォルトの設定が目的のビジネス・ニーズを満たしているかどうか判断してください。満たしていない場合は、ビジネス・ニーズに適合するように構成を変更する必要があります。
適用対象
この構成は、E-Business Suiteソースのアプリケーションに対してのみ必要になります。
タスクの説明
現時点ではあらゆる状態が考えられるジョブ求人(「ジョブ求人現行ステータス」という名前のソース適合ドメイン)の「開始」イベントを推測するために、直前の最重要ステータスを調べます。これは、「ジョブ求人当初ステータス」という名前のソース適合ドメインです。このタスクでは、「ジョブ求人現行ステータス」ドメインのメンバーを、「ジョブ求人当初ステータス」ドメインの可能なメンバーのいずれかにマップします。
たとえば、現在のステータスが「クローズ済」の場合、ある時点で「開示」のステータスになっていたことが推測できます。そのため、現在のステータス「クローズ済」に対して、元のステータスを「開示」にマップすることになります。ただし、現在のステータスが「承認拒否」の場合、求人は開示されたことがなかったと想定するのが合理的です。そのため、現在のステータス「承認拒否」に対しては、元のステータスを別の値(「要求済」など)にマップすることになります。
関連するソース適合ドメインの「ジョブ求人現行ステータス」(**)と「ジョブ求人当初ステータス」は、どちらも同じ値のセットから得られるメンバーが含まれます。実際に、「ジョブ求人当初ステータス」のすべての値は、「ジョブ求人現行ステータス」の値として存在している必要があります。
(**)「ジョブ求人当初ステータス」を構成する前に、ソース適合ドメイン「ジョブ求人現行ステータス」を構成する必要があります。詳細は、タスク「採用ファクト・グループのドメインとメンバー・マッピングの管理」を参照してください。
後述する「追加情報」の項では、このタスクに関連する特別な情報が記載されています。この情報は、これらの構成が下流で使用される方法についての概念をより深く理解するために役立ちます。また、このタスクに関連する2つのソース適合ドメイン・メンバー間のインストール済マッピングのリストも示します。
追加情報
現時点のタスクでは、「求人開示」イベントを追跡するために、現在のステータスが得られたときには、ジョブ求人の「推定」および「最重要」の元のステータスを構成することになります。ただし、元の「ステータス」をマッピングするだけでは、「イベント」構成は完了しません。元のステータスをマップすると、「採用イベント・タイプのドメインとメンバー・マッピングの管理」という後続のタスクで、「複数のステータス」を該当する「複数のイベント」にマップすることも必要になります。これら2つのタスクを両方実行すると、求人開始イベントの構成が完了します。
たとえば、「ジョブ求人現行ステータス」が「クローズ済」の場合は、それより前の日付でジョブ求人が「開示」であったことを意味します。この場合、「ジョブ求人当初ステータス」は「承認済」として構成できます。「承認済」ステータスは、その後の構成タスク「採用イベント・タイプのドメインとメンバー・マッピングの管理」で、W_EVENT_CODE、W_SUB_STAGE_CODE、およびW_STAGE_CODEとしてRQSTN_OPENにマップできます。これにより、現在のジョブ求人が「クローズ済」であり、それ以前のステータスがE-Business Suiteで追跡されていないときに、ジョブ求人の「開示済」イベントを特定する処理が完了します。
もう1つの例も、同様に進行します。「ジョブ求人現行ステータス」が「却下済」の場合、ジョブ求人の前のステータスが以前の日付で「保留中」であったことと、「開示」ステータスになったことがないという意味になります。この場合、「ジョブ求人当初ステータス」は「オープン」としてではなく「保留中」として構成できます。「保留中」ステータスは、構成タスク「採用イベント・タイプのドメインとメンバー・マッピングの管理」のステージ・コードであるW_EVENT_CODE、W_SUB_STAGE_CODEおよびRQSTN_PENDINGとしてRQSTN_APPROVAL_PENDINGにマッピングできます。Oracle Business Analytics Warehouseでは、このジョブ求人は開示されたことがないものとして扱われます。
次の表は、2つのソース適合ドメイン・メンバー間のインストール済マッピングを示しています。これが目的のビジネス・ニーズを満たしていない場合は、メンバー・マッピングを編集する必要があります。
表B-10 ジョブ求人現行ステータスからジョブ求人当初ステータスへのメンバー・マッピング
ソース・メンバー(現在のステータス) | ソース・メンバー・コード(現在のステータス) | ターゲット・メンバー(元のステータス) | ターゲット・メンバー・コード(元のステータス) |
---|---|---|---|
APPROVED |
APPROVED |
APPROVED |
APPROVED |
CANCELLED |
CANCELLED |
PENDING |
PENDING |
CLOSED |
CLOSED |
APPROVED |
APPROVED |
HOLD |
HOLD |
APPROVED |
APPROVED |
OPEN |
OPEN |
APPROVED |
APPROVED |
PENDING |
PENDING |
APPROVED |
APPROVED |
REJECTED |
REJECTED |
PENDING |
PENDING |
RQSTN_CANCELLED |
UNAPPROVED |
PENDING |
PENDING |
UNDER REVIEW |
UNDER REVIEW |
PENDING |
PENDING |
依存関係
このマッピングを編集すると、Oracle Business Analytics Warehouseへの完全ETLロードの実施が必要になります。
資産カテゴリは、キー・フレックス・フィールド(KFF)機能を使用して、E-Business Suite Fixed Assetアプリケーションで定義されます。KFFは、目的のビジネス・ニーズに基づいて各種のセグメントを使用して設定できます。
構成ファイルfile_fa_category_segment_config_ora.csvは、E-Business Suite Fixed AssetアプリケーションのカテゴリKFFと、Oracle Business Analytics Warehouseの資産カテゴリ・ディメンションとのセグメント・マッピングを構成するために使用します。この構成は、ETLロードの前に完了しておく必要があります。ETLの実行時には、この構成CSVファイルにより、どのKFFセグメントをどのセグメント列(Oracle Business Analytics Warehouseの資産カテゴリ・ディメンション表のセグメント列)にロードする必要があるかが決定されます。
たとえば、Oracle Business Analytics Warehouseには、セグメント列に次の適合値が格納されているとします。
W_ASSET_CATEGORY_D.major_categoryには、主カテゴリ(COMPUTER)が格納されている
W_ASSET_CATEGORY_D.minor_categoryには、補助カテゴリ(LAPTOPやDESKTOPなど)が格納されている
W_ASSET_CATEGORY_D.segment1には、主カテゴリが格納されている
W_ASSET_CATEGORY_D.segment2には、補助カテゴリが格納されている
E-Business Suiteインスタンスでは、主カテゴリと補助カテゴリを格納するためにセグメント2とセグメント3を使用しているとします。
FA_CATEGORIES_B.segment1は未使用
FA_CATEGORIES_B.segment2には、主カテゴリが格納されている
FA_CATEGORIES_B.segment3には、補助カテゴリが格納されている
この例の場合は、構成CSVファイルを次のように構成する必要があります。
表B-11 資産カテゴリ・ディメンションの構成
MAJOR_CATEGORY | MINOR_CATEGORY | SEG1 | SEG2 | SEG3 | SEG4 | SEG5 | その他 |
---|---|---|---|---|---|---|---|
SEGMENT2 |
SEGMENT3 |
SEGMENT2 |
SEGMENT3 |
注意: major_category列とminor_category列には、それぞれ主カテゴリと補助カテゴリを表すセグメント番号を格納します。
file_fa_category_segment_config_ora.csvを使用して、資産カテゴリ・ディメンションを構成する方法は、次のとおりです。
file_fa_category_segment_config_ora.csvファイルを編集します。
file_fa_category_segment_config_ora.csvは、E-Business Suiteのセグメント・フィールドと、Oracle Business Analytics Warehouseの表W_ASSET_CATEGORY_Dのセグメント・フィールドを照合するために使用します。
注意: このタスクの構成ファイル(複数の場合もあり)は、Oracle BI Applicationsインストールの次の場所にあります。 ソース独立ファイル: <Oracle Home for BI>\biapps\etl\data_files\src_files\。 ソース固有ファイル: <Oracle Home for BI>\biapps\etl\data_files\src_files\<source adaptor>。 システム管理者は、これらのファイルを別の場所にコピーして、この場所から読み取るためのODI接続を構成しているはずです。システム管理者に、これらのファイルの取得を依頼してください。構成が完了したら、システム管理者は、構成済ファイルをODIの読取り元にコピーする必要があります。 |
セグメント・マッピングの情報をフィールドに入力します。
列SEG1からSEG7は、Oracle Business Analytics Warehouseの資産カテゴリ・ディメンション表のセグメント列を表しています。これらの各セグメントに、対応するマッピング済KFFセグメントを入力します。MAJOR_CATEGORY列とMINOR_CATEGORY列には、それぞれ主カテゴリと補助カテゴリを表すセグメント番号を入力します。
マッピングのないフィールドは空のままにします。
ファイルを保存します。
この項では、Oracle Financial Analyticsの顧客原価明細と製品原価明細を構成する方法について説明します。この項の内容は次のとおりです。
第B.2.27.1項「Financial Profitability Analyticsの顧客原価明細表と製品原価明細表について」
第B.2.27.2項「Financial Profitability Analyticsの顧客原価明細表と製品原価明細表の構成方法」
この構成は、Financial Profitability Analyticsを実装していて、製品ディメンションまたは顧客ディメンションごとに経費を割り当てようとしている場合にのみ必要になります。デフォルトのアダプタでは、顧客や製品から生成される収益に関連付けられた「その他原価」や「その他経費」(マーケティング・キャンペーン経費など)がキャプチャされません。この「その他」のデータは、この項で説明するように、CSVファイルで指定する必要があります。
データ・ファイルのfile_customer_cost_line_fs.csvとfile_product_cost_line_fs.csvは、ETL完全ロードを実行する前に、顧客原価明細表と製品原価明細表にデータを入力するために使用します。これらのファイルで示されたINTEGRATION_IDに応じて、ETLでは顧客原価明細表と製品原価明細表に挿入と更新を実行します。これらのファイルで示されたINTEGRATION_IDがファクト表にすでに存在している場合、ファクト表のこの取引行に対してETLによる更新が実行されます。これらのデータ・ファイルには、ETLロードの実行前にデータを移入しておく必要があります。
注意: このタスクの構成ファイル(複数の場合もあり)は、Oracle BI Applicationsインストールの次の場所にあります。 ソース独立ファイル: <Oracle Home for BI>\biapps\etl\data_files\src_files\。 ソース固有ファイル: <Oracle Home for BI>\biapps\etl\data_files\src_files\<source adaptor>。 システム管理者は、これらのファイルを別の場所にコピーして、この場所から読み取るためのODI接続を構成しているはずです。システム管理者に、これらのファイルの取得を依頼してください。構成が完了したら、システム管理者は、構成済ファイルをODIの読取り元にコピーする必要があります。 |
file_customer_cost_line_fs.csvファイルでは、顧客原価明細データをW_CUSTOMER_COST_LINE_F表にロードします。次に示すように、列は4種類のカテゴリに分類されています。
Integration_ID: ファイル内の個別の行に対する一意の識別子です。
FK_ID: 対応するディメンションの統合IDにする必要があります。たとえば、CUSTOMER_ID。これは、顧客ディメンションの統合IDで移入される必要があります。
金額列: たとえば、CUST_COST_AMT。取引行の実際の金額です。
属性列: たとえば、COST_LINE_DOC_ITEM、COST_LINE_DOC_SUB_ITEM、EXPENSED_ON_DTなどです。_DT列のデータを挿入するときには、そのデータが'YYYYMMDDHH24MISS'形式で入力されていることを確認する必要があります。
file_product_cost_line_fs.csvファイルでは、製品原価明細データをW_PRODUCT_COST_LINE_F表にロードします。次に示すように、列は4種類のカテゴリに分類されています。
Integration_ID: ファイル内の個別の行に対する一意の識別子です。
FK_ID: 対応するディメンションの統合IDにする必要があります。たとえば、PRODUCT_ID。これは、製品ディメンションの統合IDで移入される必要があります。
金額列: たとえば、CUST_COST_AMT。取引行の実際の金額です。
属性列: たとえば、COST_LINE_DOC_ITEM、COST_LINE_DOC_SUB_ITEM、EXPENSED_ON_DTなどです。_DT列のデータを挿入するときには、そのデータが'YYYYMMDDHH24MISS'形式で入力されていることを確認する必要があります。
完全ロードETLを実行する前に、ここに示す手順を実行して、顧客原価明細と製品原価明細を構成する必要があります。
顧客原価明細表と製品原価明細表を構成するには:
データ・ファイルのfile_customer_cost_line_fs.csvとfile_product_cost_Line_fs.csvをコピーします。
注意: このタスクの構成ファイル(複数の場合もあり)は、Oracle BI Applicationsインストールの次の場所にあります。 ソース独立ファイル: <Oracle Home for BI>\biapps\etl\data_files\src_files\。 ソース固有ファイル: <Oracle Home for BI>\biapps\etl\data_files\src_files\<source adaptor>。 システム管理者は、これらのファイルを別の場所にコピーして、この場所から読み取るためのODI接続を構成しているはずです。システム管理者に、これらのファイルの取得を依頼してください。構成が完了したら、システム管理者は、構成済ファイルをODIの読取り元にコピーする必要があります。 |
file_customer_cost_line_fs.csvを編集します。
顧客原価ファクト表にロードする顧客原価計算トランザクションごとのファイルに、レコードを挿入します。
ファイルを保存します。
file_product_cost_line_fs.csvを編集します。
製品原価ファクト表にロードする製品原価計算トランザクションごとのファイルに、レコードを挿入します。
ファイルを保存します。
この時点で、顧客原価明細表と製品原価明細表をロードする完全ロードETLが実行できるようになります。
E-Business Suite、PeopleSoft、またはJD Edwards EnterpriseOneを使用しているときに、それらのソースから予算データを抽出してOracle Business Analytics Warehouseにインポートする場合は、事前構成済のアダプタ・マッピングを使用できます。ただし、その他の外部システムから得られる予算データを使用する場合は、この項で説明するように、Universalアダプタを使用してOracle Business Analytics Warehouseにデータをインポートします。この項の内容は次のとおりです。
次に示す各表では、UniversalソースCSVファイルのfile_budget.csvおよびfile_acct_budget.csvの列と、それらの列のデータ型について説明しています。また、それらの列に値を移入する方法についても説明しています(該当する場合)。
表B-12に、file_budget.csvファイルの構造を示します。file_budget.csvのレコードは、W_BUDGET_Dにロードされます。
表B-12 予算ファクトのUniversalソース(file_budget.csv)
列名 | データ型 | サイズ | 説明 |
---|---|---|---|
BUDGET_NAME |
文字列 |
80 |
予算名。 |
BUDGET_VERSION |
文字列 |
30 |
予算バージョン。 |
BUDGET_STATUS |
文字列 |
30 |
予算ステータス。 |
BUDGET_TYPE |
文字列 |
30 |
予算タイプ。 |
CREATED_BY_ID |
文字列 |
80 |
ユーザーが作成したID。w_user_dからのIntegration_IDを移入します。 |
CHANGED_BY_ID |
文字列 |
80 |
ユーザーが変更したID。w_user_dからのIntegration_IDを移入します。 |
CREATED_ON_DT |
文字列 |
14 |
作成日。 |
CHANGED_ON_DT |
文字列 |
14 |
変更日。ウェアハウスに既存のレコードを更新する場合に使用します。レコードを更新する場合は、日付を進めてください。ターゲット表W_BUDGET_Dに同じintegration_IDのレコードがすでに存在する場合は、ロード・プロセスで、このレコードとW_BUDGET_DのレコードのCHANGED_ON_DT値が比較されます。このレコードのCHANGED_ON_DTがW_BUDGET_Dのレコードよりも後になる場合は、ロード・プロセスで、W_BUDGET_Dのレコードに対する更新が実行されます。それ以外の場合、このレコードはロード・プロセスで無視され、更新や挿入は実行されません。同じintegration_IDを持つ一致レコードがW_BUDGET_Dに存在しない場合は、ロード・プロセスにより、このレコードがW_BUDGET_Dに挿入されます。 |
AUX1_CHANGED_ON_DT |
文字列 |
14 |
- |
AUX2_CHANGED_ON_DT |
文字列 |
14 |
- |
AUX3_CHANGED_ON_DT |
文字列 |
14 |
- |
AUX4_CHANGED_ON_DT |
文字列 |
14 |
- |
DELETE_FLG |
文字列 |
1 |
- |
DATASOURCE_NUM_ID |
数値 |
10 |
データ・ソースの番号。メイン・ソース・アプリケーションと同じdatasource_num_idを移入します。 |
INTEGRATION_ID |
文字列 |
80 |
レコードに対する一意の識別子。 |
TENANT_ID |
文字列 |
80 |
- |
X_CUSTOM |
文字列 |
10 |
- |
表B-13に、file_acct_budget.csvファイルの構造を示します。file_acct_budget.csvのレコードは、W__ACCT_BUDGET_Fにロードされます。
表B-13 予算ファクトのUniversalソース(file_acct_budget.csv)
列名 | データ型 | サイズ | 説明 |
---|---|---|---|
ADJUSTMENT_FLG |
文字列 |
1 |
- |
AUX1_CHANGED_ON_DT |
文字列 |
14 |
- |
AUX2_CHANGED_ON_DT |
文字列 |
14 |
- |
AUX3_CHANGED_ON_DT |
文字列 |
14 |
- |
AUX4_CHANGED_ON_DT |
文字列 |
14 |
- |
BUDG_BUSN_AREA_ORG_ID |
文字列 |
80 |
会社組織の識別子。business_area_flg = Yであるw_int_org_dのintegration_idを移入します。 |
BUDG_CTRL_AREA_ORG_ID |
文字列 |
80 |
会社組織の識別子。ctrl_area_flg = Yであるw_int_org_dのintegration_idを移入します。 |
BUDG_FIN_AREA_ORG_ID |
文字列 |
80 |
会社組織の識別子。fin_area_flg = Yであるw_int_org_dのintegration_idを移入します。 |
BUDGET_CALENDAR_ID |
文字列 |
80 |
- |
BUDGET_DOC_AMT |
数値 |
22 |
ドキュメント通貨での予算額。 |
BUDGET_GRP_AMT |
数値 |
22 |
- |
BUDGET_ID |
文字列 |
80 |
file_budget.csvのintegration_idの値を移入します。 |
BUDGET_LEDGER_ID |
文字列 |
80 |
- |
BUDGET_LOC_AMT |
数値 |
22 |
現地通貨での予算額。 |
CHANGED_BY_ID |
文字列 |
80 |
ユーザーが変更したID。w_user_dからのIntegration_IDを移入します。 |
CHANGED_ON_DT |
文字列 |
14 |
変更日。ウェアハウスに既存のレコードを更新する場合に使用します。レコードを更新する場合は、日付を進めてください。ターゲット表W_ACCT_BUDGET_Fに同じintegration_IDのレコードがすでに存在する場合は、ロード・プロセスで、このレコードとW_ACCT_BUDGET_FのレコードのCHANGED_ON_DT値が比較されます。このレコードのCHANGED_ON_DTがW_ACCT_BUDGET_Fのレコードよりも後になる場合は、ロード・プロセスで、W_ACCT_BUDGET_Fのレコードに対する更新が実行されます。それ以外の場合、このレコードは無視され、更新や挿入は実行されません。同じintegration_IDを持つ一致レコードがW_ACCT_BUDGET_Fに存在しない場合は、ロード・プロセスにより、このレコードがW_ACCT_BUDGET_Fに挿入されます。 |
COMPANY_ORG_ID |
文字列 |
80 |
会社組織の識別子。company_flg = Yであるw_int_org_dのintegration_idを移入します。 |
COST_CENTER_ID |
文字列 |
80 |
コスト・センターの識別子。w_cost_center_dのintegration_idを移入します。 |
CREATED_BY_ID |
文字列 |
80 |
ユーザーが作成したID。w_user_dからのIntegration_IDを移入します。 |
CREATED_ON_DT |
文字列 |
14 |
作成日。 |
DATASOURCE_NUM_ID |
数値 |
10 |
データ・ソースの番号。メイン・ソース・アプリケーションと同じdatasource_num_idを移入します。 |
DELETE_FLG |
文字列 |
1 |
- |
DOC_CURR_CODE |
文字列 |
30 |
ドキュメント通貨コード。 |
GL_ACCOUNT_ID |
文字列 |
80 |
GL勘定科目の識別子。w_gl_account_dのintegration_idを移入します。 |
GRP_CURR_CODE |
文字列 |
30 |
- |
INTEGRATION_ID |
文字列 |
80 |
レコードに対する一意の識別子。 |
LOC_CURR_CODE |
文字列 |
30 |
現地通貨コード。 |
PERIOD_BEGIN_DT |
文字列 |
14 |
- |
PERIOD_END_DT |
文字列 |
14 |
予算期間の終了日を移入します。予算が月単位の場合は、その月の末日を移入します。 |
POSTED_ON_DT |
文字列 |
14 |
このトランザクションを報告できる日付。 |
PRODUCT_ID |
文字列 |
80 |
製品の識別子。w_product_dのintegration_idを移入します。 |
PROFIT_CENTER_ID |
文字列 |
80 |
利益センターの識別子。w_profit_center_dのintegration_idを移入します。 |
PROJECT_ID |
文字列 |
80 |
- |
TENANT_ID |
文字列 |
80 |
- |
X_CUSTOM |
文字列 |
10 |
- |
注意: 日付の列は、YYYYMMDDHH24MISSの形式の数値としてCSVファイルに移入する必要があります。
表B-14を使用して、いくつかの主要なディメンションのintegration_id (キー)をE-Business Suiteソース・システム用に構築する方法について理解してください。この情報は、前述の予算ファクト用のUniversalソースCSVファイルにディメンション外部キーの識別子を移入するために使用できます(E-Business Suiteから移入したディメンションと予算ファクトを併用する必要がある場合)。
表B-14 E-Business Suiteソース・システムのintegration_idフィールドの移入
フィールド | 移入方法 |
---|---|
GL_ACCOUNT_ID (w_gl_account_d) |
GLコードの組合せID。 |
COMPANY_ORG_ID (w_int_org_d) |
移入の必要はありません。GL勘定科目IDに基づいて計算されます。 |
COST_CENTER_ID (w_cost_center_d) |
移入の必要はありません。GL勘定科目IDに基づいて計算されます。 |
PROFIT_CENTER_ID (w_profit_center_d) |
移入の必要はありません。GL勘定科目IDに基づいて計算されます。 |
LEDGER_ID (w_ledger_d) |
Oracle 11iの場合は、台帳IDのセットとして移入します。Oracle R12の場合は、元帳IDとして移入します。 |
表B-15を使用して、いくつかの主要なディメンションのintegration_id (キー)をオラクル社のJD Edwards EnterpriseOneソース・システム用に構築する方法について理解してください。この情報は、前述の予算ファクト用のUniversalソースCSVファイルにディメンション外部キーの識別子を移入するために使用できます(オラクル社のJD Edwards EnterpriseOneから移入したディメンションと予算ファクトを併用する必要がある場合)。
表B-15 オラクル社のJD Edwards EnterpriseOneのintegration_idフィールドの移入
フィールド | 移入方法 |
---|---|
GL_ACCOUNT_ID (w_gl_account_d_) |
GBAID||'~'||GBSBL||'~'||GBSBLT |
COMPANY_ORG_ID (w_int_org_d) |
GBCO |
COST_CENTER_ID (w_cost_center_d) |
GBMCU |
PROFIT_CENTER_ID (w_profit_center_d) |
GBCO |
LEDGER_ID (w_ledger_d) |
GBCO |
PRODUCT_ID (w_product_d) |
GBSBLTが品目を指している場合は、そのGBSBLで製品IDを更新します。 |
PROJECT_ID (w_product_d) |
該当なし |
BUDG_BUSN_AREA_ORG_ID (w_int_org_d) |
GBMCU |
BUDG_FIN_AREA_ORG_ID (w_int_org_d) |
GBMCU |
BUDG_CTRL_AREA_ORG_ID (w_int_org_d) |
GBMCU |
BUDGET_ID (w_budget_d) |
該当なし |
Universalアダプタを通じて予算データをOracle Business Analytics Warehouseにインポートするには、次の手順を実行してください。
file_budget.csvファイルとfile_acct_budget.csvファイルに予算データを移入します。
これらのファイルの詳細な移入方法は、前述の表を参照してください。
1つのファクト・グループでロード計画を作成します: '900: Universalアダプタのインスタンス'.'GL予算'。
前の手順で作成したロード計画を実行します。
注意: このロード計画は、その他のサブジェクト領域についてOracle Business Analytics Warehouseに移入する通常のロード計画が完了してから実行する必要があります。
予算データをロードするか、既存の予算データに変更を加えます。
次回の会計期間に向けた新しい予算をロードしたり、すでにロードした予算データに訂正を加えたりする必要がある場合は手順1と手順3を繰り返します。
ワークフォース凍結スナップショット・ファクトは、従業員データのスナップショットを定期的にキャプチャし、特定の時点でのデータを報告できるようにするために、そのスナップショットが変更されないように維持します。スナップショットの周期は、各種のモードで構成できます。スナップショットは、特定の経過時間に達した時点で削除できます。
オプションまたは必須
このタスクは任意です。ただし、デフォルトのオプションでは凍結スナップショットが収集されません。
適用対象
すべてのソース(E-Business Suite、PeopleSoftおよびFusion)。
詳細なタスクの説明
この機能を有効にするには、次のパラメータを構成します。
スナップショット・モード(HR_WRKFC_SNAPSHOT_HIST_MODE_CODE)
注意: オプションについての詳しい説明は、次に示す表に記載されています。
None (デフォルト値)
Start of Month
End of Month
Relative to Start
Relative to End
Day of Week
スナップショットの抽出開始日(HR_WRKFC_SNAPSHOT_HIST_EXTRACT_DATE)
これは、凍結スナップショットを生成する最初の日付に設定します。
保持期間のタイプ(KEEP_PERIOD)
Calendar Day
Calendar Week
Calendar Month
Calendar Quarter
Calendar Year
期間数(NUM_OF_PERIOD)
デフォルトは0 (すべてのスナップショットを保持)
正の数値Nに設定すると、N回の期間(保持期間のタイプで指定した期間)より古いスナップショットが自動的に消去されます
表B-16 HR_WRKFC_SNAPSHOT_HIST_MODE_CODEの値
値 | 説明 |
---|---|
None (デフォルト) |
この機能が無効になります。その他のオプションについては、後続の項で詳しく説明します。凍結スナップショットは、表W_WRKFC_SNP_Fに保存されます。 |
Start of Month |
スナップショットは、各月の初日ごとに毎月1回取得されます。その他のパラメータを構成する必要はありません。 |
End of Month |
スナップショットは、各月の末日ごとに毎月1回取得されます。その他のパラメータを構成する必要はありません。 |
Relative to Start |
スナップショットは、各月のn回目の曜日ごとに毎月1回取得されます。たとえば、各月の第3火曜日など。その他のパラメータも構成する必要があります。
|
Relative to End |
スナップショットは各月の末日から数えてn回目の特定の曜日ごとに毎月取得されます。たとえば、月末から数えた第3火曜日など。その他のパラメータも構成する必要があります。
|
Day of Week |
スナップショットは、各週の特定の曜日ごとに毎週1回取得されます。たとえば、毎週月曜日など。その他のパラメータも構成する必要があります。
|
依存関係
依存関係はありません。
ワークフォース配置サブジェクト領域には、2つの論理ファクトが含まれています。
ワークフォース・バランス情報: 特定の時点でのバランス(たとえば、月末の人員数と給与)について報告します。
ワークフォース・イベント情報: ある期間内に発生したイベント(たとえば、年間の退職者数)について報告します。
ほとんどのレポートは、どちらか一方の論理ファクトを使用します。また、その違いを理解することは、レポートを合理的なものにするために重要になります。両方の論理ファクトを併用するようにレポートを設計できますが、ディメンションの使用に注意を払う必要があります。
詳細なタスクの説明
ワークフォース・バランス情報
ワークフォース・バランス・ファクトは、特定の時点でのステータスを示します。このファクトは時間ディメンションと併用する必要があります。時間ディメンションが使用されていないと、すべての期間についてのステータスが計算されるようになりますが、現行のステータスのみが返されます。そのため、著しく効率が低下します。
現行の期間を除いて、どの期間(年、四半期、月および日)が使用されていても、その期間の終了日時点のステータスがファクトから得られます。現行の期間については、将来の期間終了日時点でのステータスを示すように動作を構成することも、現在の日付の時点でのステータスを示すように動作を構成することもできます。これは、HR_WRKFC_MAX_EFFECTIVE_DTセッション変数で制御します。この変数の詳細は、タスク「将来のトランザクション・データ表示の管理方法」を参照してください。
このファクトには、退職した就業者が含まれません。退職していない就業者についてのステータスのみが得られます。E-Business Suiteの場合は、雇用の最終日に当たる「実際の退職日」が含まれます。雇用の最終日では、就業者はシステム上でアクティブな状態が維持されています。
ワークフォース・イベント情報
ワークフォース・イベント・ファクトは、特定の期間内に発生したイベントを示します。このファクトは時間ディメンションと併用する必要があります。時間ディメンションを併用しないと、すべての期間が表示され、パフォーマンスの大幅な低下につながります。イベントは、各期間内に発生したものが示されます。現行の期間については、現在の日付までのイベントを示すように動作を構成することも、期間内の将来のイベントをすべて示すように動作を構成することもできます。これは、HR_WRKFC_MAX_EFFECTIVE_DTセッション変数で制御します。この変数の詳細は、タスク「将来のトランザクション・データ表示の管理方法」を参照してください。
このファクトには雇用終了イベントが含まれます。就業者が非アクティブになった最初の日付が雇用終了イベントの日付になるように定義されています。E-Business Suiteの場合は、雇用の最終日に当たる「実際の退職日」の次の日になります。雇用の最終日では、就業者はシステム上でアクティブな状態が維持されています。
ワークフォース・イベント・ディメンション
ワークフォース・イベント・ファクトは、詳細レベルでワークフォース・イベント・ディメンションに結合します。このディメンションには、各イベントに関する情報が格納されます。この情報とは、主要ディメンション(たとえば、組織、ジョブ、等級)に変更があったかどうかを示すいくつかの変更フラグを伴ったイベントのタイプ(たとえば、採用や退職)などです。
ワークフォース・バランス・ファクトは、要約レベルでワークフォース・イベント・ディメンションに結合します。そのため、レポートではディメンションに基づいたフィルタや属性を使用できなくなります。ただし、バランス情報とイベント情報を組み合せたレポートの場合は、ワークフォース・イベント・ディメンションに基づいたメトリックを作成できます。
ワークフォース・イベント・ディメンションが役立つ主な2つの方法は次のとおりです。
詳細レポート(「2011年のすべての退職者の報告」や「就業1年未満の就業者に関する組織のすべての変更の報告」など)の作成。
イベントに基づくメトリックの作成。たとえば、「ヘッドハンティング退職」イベントに関するレポートが必要だとします。ワークフォース・イベントのドメイン・マッピングでは、ヘッドハンティングによる退職者を「ヘッドハンティング退職」という新しいイベント(サブグループの自己都合退職とグループの雇用終了にマップされるイベント)にマップします。
「ヘッドハンティング退職」詳細レポートは、わかりやすくする必要があります(ワークフォース・イベント・ディメンションのイベントコードが'HEADHUNTED'である属性のリストにする)。
要約レポートでは、退職者数(自己都合退職、会社都合退職およびヘッドハンティング退職を含む)を表示する必要があります。それ以外のメトリックは、すでに定義されています。次のように定義されたイベント論理ファクトに、新しいメトリック「ヘッドハンティング数」を追加します。
CASE WHEN "Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_WRKFC_EVENT_TYPE_D"."W_EVENT_CODE" = 'HEADHUNTED' THEN 1 ELSE 0 END
このメトリックの集計ルールを「合計」になるように設定します。
目的
フレックスフィールドとは、ユーザーが構成したフィールドのことです。このフィールドは、標準のOLTPの表には格納されない追加情報を格納するために使用します。この情報は、一部のウェアハウスのディメンションでは固定属性やプレースホルダ属性にマップされることがあります。Oracle Business Analytics Warehouseの固定属性(ジョブ・コード、ジョブ・ファミリ、ジョブ機能、ジョブ・レベル、給与レベルなど)は、事前定義済のレポートで使用されることがあります。プレースホルダ属性は、アドホックのレポート作成に使用できます。この属性のラベルは、マッピング後に、格納しているデータについて説明するラベルに付け替えできます。このマッピングとラベルの付け替えは、この項で説明するように、Oracle BI Applications構成マネージャを使用して、ドメインとドメイン・マッピングを構成することで実行できます。
オプションまたは必須
この構成はオプションです。この構成を行わないと、フレックスフィールド・データに依存する固定列にはデータが保持されなくなります。さらに、プレースホルダ列が使用できなくなります。これは、構成が行われているかどうかに応じて、Oracle BI EEプレゼンテーション・カタログにプレースホルダ列が表示されなくなるためです。
適用対象
E-Business Suiteソース・システム。
予備知識
Oracle BI Applications構成マネージャを使用して、フレックスフィールドを構成します。次の表に、ソースとしてサポートされるフレックスフィールドと、そのフレックスフィールドのマッピング先のターゲット・ディメンションを示します。
ディメンション | ターゲット・ドメイン(ディメンション属性) | ソース・ドメイン(フレックスフィールド) |
---|---|---|
HRアサイメント |
HRアサイメント・ディメンション属性(W_FLEX_ASSIGNMENT_ATTRIBUTES) |
Peopleグループ・キー・フレックスフィールド(KEY:801:GRP) |
HRアサイメント |
HRアサイメント・ディメンション属性(W_FLEX_ASSIGNMENT_ATTRIBUTES) |
アサイメント付加フレックスフィールド(DESCRIPTIVE:800:PER_ASSIGNMENTS) |
HR個人 |
HR個人ディメンション属性 (W_FLEX_PERSON_ATTRIBUTES) |
個人付加フレックスフィールド(DESCRIPTIVE:800:PER_PEOPLE) |
脚注 1 HR個人国別仕様 |
HR個人国別仕様ディメンション市民権属性(W_FLEX_CITIZENSHIP_ATTRIBUTES) |
個人その他情報付加フレックスフィールド(DESCRIPTIVE:800:PER_PEOPLE_EXTRA_INFO) |
HR個人国別仕様* |
HR個人国別仕様ディメンション人種属性(W_FLEX_ETHNIC_ATTRIBUTES) |
個人その他情報付加フレックスフィールド(DESCRIPTIVE:800:PER_PEOPLE_EXTRA_INFO) |
HR個人国別仕様* |
HR個人国別仕様ディメンション・ビザ属性(W_FLEX_VISA_ATTRIBUTES) |
個人その他情報付加フレックスフィールド(DESCRIPTIVE:800:PER_PEOPLE_EXTRA_INFO) |
HRポジション |
HRポジション・ディメンション属性(W_FLEX_POSITION_ATTRIBUTES) |
ポジション・キー・フレックスフィールド(KEY:800:POS) |
HRポジション |
HRポジション・ディメンション属性(W_FLEX_POSITION_ATTRIBUTES) |
ポジション付加フレックスフィールド(DESCRIPTIVE:800:PER_POSITIONS) |
ジョブ |
ジョブ・ディメンション属性(W_FLEX_JOB_ATTRIBUTES) |
ジョブ・キー・フレックスフィールド(KEY:800:JOB) |
ジョブ |
ジョブ・ディメンション属性(W_FLEX_JOB_ATTRIBUTES) |
ジョブ付加フレックスフィールド(DESCRIPTIVE:800:PER_JOBS) |
支給等級 |
支給等級ディメンション属性(W_FLEX_GRADE_ATTRIBUTES) |
等級キー・フレックスフィールド(KEY:800:GRADE) |
支給等級 |
支給等級ディメンション属性(W_FLEX_GRADE_ATTRIBUTES) |
等級付加フレックスフィールド(DESCRIPTIVE:800:PER_GRADES) |
脚注 1 HR個人国別仕様プレースホルダは、HR個人のマッピングにより、個人付加フレックスフィールドから部分的に入力されます。
すべてのターゲット・ドメインで、次に示す属性がサポートされます。プレースホルダ属性には事前シードされていないものがあります。ただし、ドメインはサポート範囲の上限まで拡張可能で、追加されたものはETLによりすべて自動的に取得されます。
ディメンション | ドメイン・メンバー |
---|---|
HRアサイメント |
プレースホルダ(30文字、20桁の数字、10桁の日付) |
HR個人 |
プレースホルダ(30文字、20桁の数字、10桁の日付) |
HR個人国別仕様 |
プレースホルダ(HR個人属性から取得: 最初の15文字、9桁の数字、6桁の日付) プレースホルダ(市民権属性から取得: 後続の5文字、3桁の数字、2桁の日付) プレースホルダ(人種属性から取得: 後続の5文字、3桁の数字、2桁の日付) プレースホルダ(ビザ属性から取得: 後続の5文字、3桁の数字、2桁の日付) |
HRポジション |
プレースホルダ(30文字、20桁の数字、10桁の日付) ポジション番号 |
ジョブ |
プレースホルダ(30文字、20桁の数字、10桁の日付) ジョブ・コード ジョブ・ファミリ ジョブ機能 ジョブ・レベル |
支給等級 |
プレースホルダ(30文字、20桁の数字、10桁の日付) 支払レベル |
詳細なタスクの説明
固定データのウェアハウス列(ジョブ・ファミリやジョブ機能など)についての情報を格納するフレックスフィールドの構造と列を特定します。
さらに、アドホックのレポート作成のためにウェアハウスに含める必要がある情報を格納するフレックスフィールドの構造と列を特定します。
どのプレースホルダのターゲット・ドメイン・メンバーが、どのソース・フレックスフィールドの列を保持するかを決定します。
ターゲット列にカスタム名を指定することで、デフォルトのターゲット・ドメイン・メンバー名を上書きします。ソース・フレックスフィールド列を変換するために値セットが使用される場合は、ターゲット・ドメイン・メンバーの説明を指定します。これは、変換されたターゲット列のラベルになります。
ドメイン・マッピングの画面で、ソース・ドメイン・メンバー(フレックスフィールドの構造と列)を、ターゲット・ドメイン・メンバー(ウェアハウスのディメンション列)にマッピングします。
例
たとえば、次に示すドメイン・マッピングは、ジョブ・ディメンションに対して実行します(国別仕様の異なるジョブ・ファミリを格納するキー・フレックスフィールドに2つの構造が定義されていて、アドホックのレポート作成に必要な3つのグローバル付加フレックスフィールドの属性があるとします)。
ソース・ドメイン | ソース・メンバー | ターゲット・ドメイン | ターゲット・メンバー |
---|---|---|---|
ジョブ・キー・フレックスフィールド |
ジョブ・ファミリ(1:SEGMENT3) |
ジョブ・ディメンション属性(W_FLEX_JOB_ATTRIBUTES) |
ジョブ・ファミリ(JOB_FAMILY) |
ジョブ・キー・フレックスフィールド |
ジョブ・ファミリ(2:SEGMENT5) |
ジョブ・ディメンション属性(W_FLEX_JOB_ATTRIBUTES) |
ジョブ・ファミリ(JOB_FAMILY) |
ジョブ付加フレックスフィールド |
ジョブ・タイプ1 (Global:ATTRIBUTE8) |
ジョブ・ディメンション属性(W_FLEX_JOB_ATTRIBUTES) |
ジョブ・タイプ1 (JOB_ATTR1_CHAR) |
ジョブ付加フレックスフィールド |
ジョブ・タイプ2 (Global:ATTRIBUTE13) |
ジョブ・ディメンション属性(W_FLEX_JOB_ATTRIBUTES) |
ジョブ・タイプ2 (JOB_ATTR2_CHAR) |
ジョブ付加フレックスフィールド |
ジョブ・タイプ3 (Global:ATTRIBUTE19) |
ジョブ・ディメンション属性(W_FLEX_JOB_ATTRIBUTES) |
ジョブ・タイプ3 (JOB_ATTR3_CHAR) |
ETLにより、ソースからマップされたフレックスフィールド列に格納されているデータが、対応するディメンション列に移入されます。
また、値セットでフレックスフィールドが定義されている場合は、ETLにより、この値セットからの値もドメインに抽出されます。この値は、コードの変換や参照に使用できます。このような参照ドメインは、ターゲット・ドメイン・メンバーに由来する名前が付けられます。たとえば、ドメインJOB_ATTR1_CHAR:W_FLEX_JOB_ATTRIBUTESには、ジョブ・ディメンションのジョブ・タイプ1フィールドの値を変換するために必要になるコードと名前のペアが格納されています。変換された値は、ターゲット・メンバーの説明を使用することでOracle BI EE Answersにも提示されます。たとえば、ターゲット列JOB_ATTR1_CHARには、「ジョブ・タイプ1」という名前と「ジョブ・タイプ1の名前」という説明が付けられています。その場合、Oracle BI EE Answersでは、値セットから得られるコードを列「ジョブ・タイプ1」に格納し、値セットから得られる変換された名前を列「ジョブ・タイプ1の名前」に格納します。
依存関係
なし。
目的
給与バランスをOracle Business Analytics Warehouseに抽出するには、そのバランスをFusion ApplicationsシステムのBIバランス・グループに割り当てることと、エレメントをPeopleSoftグローバル・ペイロールのエレメント・グループに割り当てることが必要になります。
PeopleSoftのNorth American PayrollとE-Business Suite Payrollについては、Oracle Business Analytics Warehouseに抽出する必要のあるすべてのバランス、支給、控除、税を使用してOLTP環境にカスタム表を作成することが強く推奨されています。
抽出するバランスを制限することで、ETLとレポートのパフォーマンスが向上します。また、ウェアハウスに含めるバランスが特定のタイプにのみ限定されます。実行バランスのみを抽出する必要があります。これは、その他のタイプのバランスは完全な加算性を備えていない可能性があるためです(たとえば、年間累計バランスを加算して1つにまとめることはできません)。
メジャーの加算性を確保するために、実行バランスのみがサポートされます。給与計算を実行するたびに、処理された実際の実行バランスが格納されます。これらはコンテキストで分類されないため、時間を通じて実行バランスを組み合せて上位のバランスを形成できます(たとえば、PTD、MTD、YTDなど)。
E-Business Suite PayrollおよびPeopleSoft North American Payrollについては、ヘルプ・トピックID 243で詳細を参照してください。
オプションまたは必須
Fusion PayrollおよびPeopleSoftグローバル・ペイロールの場合は必須です。E-Business Suite PayrollおよびPeopleSoft North American Payrollの場合は任意ですが、強く推奨されています。
Fusionおよびグローバル・ペイロールの場合は、それぞれ「BIバランス・グループ」と「GLOBAL BI BALGRP」エレメント・グループに割り当てられているバランスのみを抽出するようにETLを構成します。
適用対象
Fusion Payroll、PeopleSoftグローバル・ペイロール、PeopleSoft North American PayrollおよびE-Business Suite Payroll。
詳細なタスクの説明
目的のソース・システムに応じて、該当する項を参照してください。
前提条件
Fusion Applications給与管理領域へのアクセス。
Oracle ADF 11gプラグインを組み込んだOffice 2007。
BIバランス・グループへの追加が必要になる定義済バランスのリスト。
バランス・ディメンション(実行であること)およびバランス・タイプごとにリストされていること。
国別仕様データ・グループごとにリストされていること。
ここでは、Oracle Business Analytics Warehouseに取り込むBIバランス・グループにバランスを追加する際に必要になる手順について説明します。給与管理のドキュメントには、あらゆる設定を検証するための例外と検証レポートについての詳しい説明が記載されています。
バッチの作成手順:
Fusion Applicationsにログインして、給与管理領域に移動します(ナビゲータから「給与」→「給与管理」)。
「タスク」ペインで、「バッチ処理」→「バッチ・ローダー」の順に選択します。
「ダウンロード」ボタンをクリックして「バッチ・ローダー・スプレッドシート」を開き、要求に応じてログイン詳細を再入力します。
「バッチ・ヘッダー・シート」タブで、バッチの名前と「国別仕様データ・グループ」を入力して保存します。
バッチ名をダブルクリックすることでバッチを選択して、「バッチ・コンテンツ・シート」タブを開きます。
「追加」ボタンをクリックし、「定義済バランスの追加」アクションを選択します。
BIバランス・グループに追加する定義済バランスごとに、詳細を入力します。
ライン順序。
属性定義: 「グローバルBI属性」
国別仕様データ・グループ: 手順4で入力したもの。
バランス・ディメンション: バランス・ディメンションの名前。これは、コンテキストが一切ない単純な実行バランスにする必要があります。
バランス・タイプ: 定義済バランスのバランス・タイプの名前
「保存」をクリックします。
バッチの転送手順:
Fusion Applicationsで、「チェックリスト」ページに移動します(ナビゲータから「給与」→「チェックリスト」)。
「タスク」ペインで、「給与フロー」→「プロセスまたはレポートの発行」の順に選択します。
バッチに対する「国別仕様データ・グループ」を選択します。
「バッチの転送」プロセスを選択して、「次」をクリックします。
詳細の入力:
給与フローに名前を付けます。
バッチ・パラメータには、「バッチの作成手順」で入力したバッチ名を選択します。
プロセスを実行します。
「HRMS 基本設定」→「グローバル ペイロール/休暇欠勤管理」→「エレメント」→「エレメント グループ」→「値の追加」の順に移動します。
エレメント・グループの名前に「GLOBAL BI BALGRP」を指定して、意味のわかる説明を指定します。
「エレメント グループ メンバー」タブをクリックします。
Oracle Business Analytics Warehouseに抽出する必要のある支給/控除を、作成したエレメント・グループに追加します。
グローバル・ペイロールのETLは、エレメント・グループのGLOBAL BI BALGRPに割り当てた支給/控除のみを抽出するように構成します。次に示すスクリーンショットは、エレメント・グループに支給/控除を割り当てる方法を示しています。
PeopleSoft North American PayrollとE-Business Suite Payrollについては、Oracle Business Analytics Warehouseに抽出する必要のあるすべてのバランス、支給、控除、税を使用してOLTP環境にカスタム表を作成することが強く推奨されています。
たとえば、次に示すPeopleSoft North American Payrollのカスタム表スクリプトを使用できます。
CREATE TABLE OBIA_PAY_BAL_FILTER (BALANCE_ID VARCHAR2 (50)); INSERT INTO OBIA_PAY_BAL_FILTER(BALANCE_ID) SELECT DISTINCT A.BALANCE_CODE FROM ( SELECT D.DEDCD AS BALANCE_CODE FROM PS_DEDUCTION_TBL D WHERE D.DEDCD IN ('401','B00-23','B10-02','B10-15','B10-16') UNION SELECT E.ERNCD AS BALANCE_CODE FROM PS_EARNINGS_TBL E WHERE E.ERNCD IN ('001','007','B14','B30') UNION SELECT S.ERNCD_SPCL AS BALANCE_CODE FROM PS_SPCL_EARNS_TBL S WHERE S.ERNCD_SPCL IN ('100','142','143','145') UNION SELECT ST.STATE AS BALANCE_CODE FROM PS_STATE_TAX_TBL ST WHERE ST.STATE IN ('AK','AL','AR','AS') UNION SELECT CT.PROVINCE AS BALANCE_CODE FROM PS_CAN_TAX_PROV CT WHERE CT.PROVINCE IN ('AB','BC','MB','NB') ) A; CREATE UNIQUE INDEX OBIA_PAY_BAL_FILTER_U1 ON OBIA_PAY_BAL_FILTER (BALANCE_ID);
この問合せのIN句に、それぞれ、すべての支給、控除、税を追加します。
次に、E-Business Suite Payrollのカスタム表スクリプトを示します。
CREATE TABLE OBIA_PAY_BAL_FILTER (BALANCE_ID VARCHAR2 (50)); INSERT INTO OBIA_PAY_BAL_FILTER (BALANCE_ID) SELECT DISTINCT DB.DEFINED_BALANCE_ID FROM PAY_BALANCE_TYPES BT, PAY_DEFINED_BALANCES DB, PAY_BALANCE_DIMENSIONS BD WHERE BT.BALANCE_TYPE_ID = DB.BALANCE_TYPE_ID AND DB.BALANCE_DIMENSION_ID = BD.BALANCE_DIMENSION_ID AND BT.BALANCE_NAME IN ('Payments','Overtime','Regular Earnings','Regular Salary'); CREATE UNIQUE INDEX OBIA_PAY_BAL_FILTER_U1 ON OBIA_PAY_BAL_FILTER (BALANCE_ID);
BT.BALANCE_NAME IN ('Payments','Overtime','Regular Earnings','Regular Salary'): Oracle Business Analytics Warehouseに抽出する必要のあるすべてのバランスのリストです。
目的
HR Analyticsでは、7つの区分ディメンションを使用します。このタスクの目的は、区分ディメンションに関する情報と、それらの表での区分を構成するために必要な内容をすべて提供することです。
オプションまたは必須
デフォルトのソリューションには、業界のベスト・プラクティスに基づいて構成された区分が用意されています。デフォルトの区分が目的のビジネス・ニーズを満たしている場合は、追加の構成は必要ありません。それ以外の場合は、このタスクは必須になります。
タスクの説明: 区分ディメンションの概要
特定の属性の様々なグループに基づいたデータ分析を可能にするために、Oracle BI Applicationsでは、次に示す7つの属性ファミリについて、グループ(つまり区分)の選択をユーザーが構成するためのオプションが用意されています。
個人経過時間
ジョブ求人経過時間
タイム・カード経過時間
パフォーマンス・レーティング
勤続期間
支給率
学習等級
構成する区分データは、7つの対応するディメンション表に格納します。次の表に、これらの各表の説明を示します。
表B-17 区分データを格納するディメンション表
ディメンション表 | 説明 |
---|---|
W_AGE_BAND_D |
年齢区分表。この表では、人々の年齢を様々な区分に分割します。この表は、人々が収まる経過時間の範囲を判定するために役立ちます。この表には、2つのレベルがあります。 LEVEL_ID = AGE_BAND。このレベルでは、年齢の区分を定義します。 LEVEL_ID = AGE。このレベルでは、個人の年齢(月単位)を定義します。 |
W_JOB_RQSTN_AGE_BAND_D |
ジョブ求人経過時間区分表。この表では、ジョブ求人の経過時間を様々な区分に分割します。この表は、ジョブ求人が収まる経過時間の範囲を判定するために役立ちます。この表には、2つのレベルがあります。 LEVEL_ID = RQSTN_AGE_BAND。このレベルでは、ジョブ求人経過時間の区分を定義します。 LEVEL_ID = RQSTN_AGE。このレベルでは、ジョブ求人経過時間(月単位)を定義します。 |
W_TLB_AGE_BAND_D |
タイムカード経過時間区分表。この表では、タイム・カードの経過時間を様々な区分に分割します。この表は、タイム・カードの経過時間が収まる範囲を判定するために役立ちます。この表には、2つのレベルがあります。 LEVEL_ID = TIMECARD_AGE_BAND。このレベルでは、タイム・カード経過時間の区分を定義します。 LEVEL_ID = TIMECARD_AGE。このレベルでは、タイム・カードの経過期間を定義します(日数単位)。 |
W_PERFORMANCE_BAND_D |
パフォーマンス区分表。この表では、パフォーマンス・レーティングを様々な区分に分割します。この表は、候補者の資質レベルを判断するために役立ちます。この表には、2つのレベルがあります。 LEVEL_ID = PERF_BAND。このレベルでは、パフォーマンス・レーティングの区分を定義します。 LEVEL_ID = PERF_RTNG。このレベルでは、人物ごとに正規化した各パフォーマンス・レーティングを定義します(最大100の整数)。 |
W_PRD_OF_WRK_BAND_D |
勤務期間区分表。この表では、従業員と派遣就業者を様々な区分に分割します。これは、従業員と派遣就業者が雇用されている期間を判定するために役立ちます。この表には、3つのレベルがあります。 2つのレベルで区分を定義します。LEVEL_ID = POW_BAND_EMPでは、従業員の勤務期間区分を定義します。LEVEL_ID = POW_BAND_CWKでは、派遣就業者の勤務期間区分を定義します。 LEVEL_ID = POW。このレベルでは、個人の勤務期間を定義します(月数単位)。 |
W_COMPA_RATIO_BAND_D |
支給率区分表。この表では、従業員の支給率(パーセンテージ)の値を様々な区分に分割します。これは、組織内の支給率の分布を判定するために役立ちます。 LEVEL_ID = COMPA_RATIO_BAND。このレベルでは、支給率の区分を定義します。 LEVEL_ID = COMP。このレベルでは、個人の支給率を定義します。 |
W_LM_GRADE_BAND_D |
学習等級区分表。この表では、学習スコアを様々な区分に分割します。これは、講座の選択に関して学習者の資質を判定するために役立ちます。この表には、2つのレベルがあります。 LEVEL_CODE = LM_GRADE_BAND。このレベルでは、学習等級の区分を定義します。 LEVEL_CODE = GRADE。このレベルでは、特定の講座の選択に合せた学習者の学習スコアを定義します。 |
タスクの説明: すべての区分ディメンションに対する区分の構成
サポートされている属性(全部で7つ)に対する区分は、Oracle BI Applications構成マネージャで事前シードされています。ただし、デフォルトの区分を別の基準値に変更する場合は、Oracle BI Applications構成マネージャの「ドメイン・マッピングおよび階層の管理」オプションを使用して事前シード済の構成を編集する必要があります。次に、事前シード済マッピングのスクリーンショットをサポートされている属性ごとに示します。
年齢の区分
ジョブ求人経過時間の区分
タイムカード経過時間の区分
パフォーマンスの区分
勤務期間の比率の区分: 従業員
勤務期間の比率の区分: 派遣就業者
支給率の区分
学習等級の区分
目的
ほとんどのHRシステムでは、トランザクションを事前に入力することが一般的です。これは、通常、先日付トランザクションと呼ばれます。どのロールが先日付トランザクションを表示できるかについては、通常、ロール・ベースのアクセス制御に結び付けられています。BI Applications Human Resourcesでは、このような方法でいくつかのファクトを保護することで、先日付トランザクションへのアクセスを制限しています。これは、いくつかのセッション・レベルのOBIEE初期化ブロックと、それに関連する特定の日付値を返す変数で実現されています。この日付値により、データへのアクセスが可能であったとしても、どこまで将来のデータにユーザーがアクセスできるかどうかを決定します。このタスクの目的は、この日付を設定することです。
オプションまたは必須
デフォルトでは、将来のデータへのアクセスはユーザーに提供されていません。ユーザーが将来のデータへのアクセスを必要としている場合、このタスクは必須になります。
タスクの説明
5つのセッション変数と、関連する2つの初期化ブロックがこのタスクに関与します。これらは、次のとおりです。
表B-18 セッション変数
セッション変数名 | 使用される初期化ブロック | 構成の必要性(Y/N) |
---|---|---|
HR_WRKFC_MAX_EFFECTIVE_DT |
HR_WRKFC_MAX_EFFECTIVE_DT |
Y |
HR_WRKFC_MAX_EFFECTIVE_DT_WID |
HRワークフォースの最大有効日 |
N |
HR_WRKFC_MAX_EFFECTIVE_DT_MONTH_WID |
HRワークフォースの最大有効日 |
N |
HR_WRKFC_MAX_EFFECTIVE_DT_QTR_WID |
HRワークフォースの最大有効日 |
N |
HR_WRKFC_MAX_EFFECTIVE_DT_YEAR_WID |
HRワークフォースの最大有効日 |
N |
最初の初期化ブロックにのみ構成が必要になります。初期化ブロック'HR_WRKFC_MAX_EFFECTIVE_DT'のデフォルト設定の動作は、常に本日の日付を返します。このSQL文は次のとおりです。
select DAY_DT from "Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_DAY_D_Common" where DAY_DT = CURRENT_DATE
本日から1年先までの将来のデータへのアクセスを許可するという要件がある場合は、次のようにSQLを変更する必要があります。
select CAST(TIMESTAMPADD(SQL_TSI_YEAR, 1, DAY_DT) AS DATE) from "Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_DAY_D_Common" where DAY_DT = CURRENT_DATE
認証されたユーザーに応じて初期化ブロックの動作を変更する場合は、付属のSQLの初期化ブロックHR_WRKFC_MAX_EFFECTIVE_DTを次のように変更します。
select case when ':USER' in ('A','B','C') then CAST(TIMESTAMPADD(SQL_TSI_YEAR, 1, DAY_DT) AS DATE) else DAY_DT end from "Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_DAY_D_Common" where DAY_DT = CURRENT_DATE
これは、ユーザーA、BおよびCは本日から1年先までの将来のデータへのアクセスが可能であり、その他のユーザーは将来のデータにアクセスできない場合のユースケースを表しています。
このユースケースに関係なく、変数HR_WRKFC_MAX_EFFECTIVE_DTが返す内容に応じて、2番目の初期化ブロックHR - 先日付データ日(WID)は、4つの従属変数に適切な値を返します。SQLは次のようになります(これは、情報提供のみを目的としています。変更の必要はありません)。
select CAST(ROW_WID AS INT) AS HR_WRKFC_MAX_EFFECTIVE_DT_WID, CAST(CAL_MONTH_WID AS INT) AS HR_WRKFC_MAX_EFFECTIVE_DT_MWID, CAST(CAL_QTR_WID AS INT) AS HR_WRKFC_MAX_EFFECTIVE_DT_QWID, CAST(CAL_YEAR_WID AS INT) AS HR_WRKFC_MAX_EFFECTIVE_DT_YWID from "Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_DAY_D_Common" where DAY_DT = CAST(VALUEOF(NQ_SESSION.HR_WRKFC_MAX_EFFECTIVE_DT) AS DATE
厳密なSQLは、ユーザーやロールの要件によって異なります。
注意: 先日付のセキュリティは、ディメンションではなく、HRファクトにのみ適用されます(このドキュメントの執筆時点)。
依存関係
将来のデータの制限は、次の論理ファクトに対して利用できます。
ファクト - 人事管理 - ワークフォース - バランス情報
ファクト - 人事管理 - ワークフォース - イベント情報
ファクト - 人事管理 - 採用イベント情報
ファクト - 人事管理 - ワークフォース増減 - イベント情報
ファクト - 人事管理 - ワークフォース増減 - バランス情報
ファクト - 人事管理 - 給与バランス詳細
ファクト - 人事管理 - 給与バランス要約
ファクト - 人事管理 - 計上トランザクション - バランス情報
ファクト - 人事管理 - 計上トランザクション - イベント情報
オラクル社のJD Edwards EnterpriseOneには、会計パターンまたは会計年度に四半期を定義するという概念がありません。そのため、四半期情報を移入するために、構成可能なフラット・ファイルが用意されています。この構成ファイルを使用すると、各期間の四半期番号、四半期開始日、四半期終了日などの情報を提供できるようになります。
このフラットファイルを構成する方法の詳細は、第B.2.71.1項「file_lkp_fiscal_period_Qtr_Config_jde.csvの構成方法」を参照してください。OLTPでサポートされているように、各会計パターンには、様々な数の期間を含められます。そのため、会計年度や会計パターンごとに、四半期の構成が必要になります。次の表に、ファイルfile_lkp_fiscal_period_Qtr_Config_jde.csvで指定されるサンプル値を示します。
表B-19 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列、および業務ユニット列に関連付けられたカレンダが格納されています。オラクル社の
JD Edwards EnterpriseOneでは、ORG_IDとLEDGER_IDを形成する会社に会計日のパターンが関連付けられます。
W_MCAL_CAL_D表には、カレンダ情報が格納されます。この表には、会計年度パターン表(F0008)に格納された個別の会計日パターンごとに1つのエントリがあります。このディメンションの単位は、日付パターン・タイプになります。これにより、Oracle Business Analytics Warehouseのカレンダを識別します。このディメンションには、そのパターンの会計年度との関連付けがありません。MCAL_CAL_WID列の内容は、ETLの実行ごとに1000にリセットされる4桁の数値であり、W_MCAL_CAL_Dに格納されている日付パターン・タイプごとに1ずつ増分されます。
この項では、一般会計勘定科目をグループ口座番号にマップする方法について説明します。その内容は次のとおりです。
一般会計勘定科目の設定の概要: 第B.2.36.1項「グループ口座番号へのGL勘定科目のマッピングの概要」を参照してください。
グループ口座番号への一般会計勘定科目のマップ方法の説明: 第B.2.36.2項「グループ口座番号へのGL勘定科目コードのマップ方法」を参照してください。
Oracle BI Repositoryへのグループ口座番号メトリックの追加方法を説明する例: 第B.2.18.3項「論理表「ファクト - 最終 - 転記されたGL仕訳」への新規メトリックの追加方法」を参照してください。
注意: GL勘定科目コードがグループ口座番号(ドメイン値)にマップされることが重要です。GLレポート・レイヤーのメトリックでは、これらの値が使用されるからです。GL勘定科目番号のドメイン値のリストは、Oracle Business Analytics Warehouseデータ・モデル・リファレンスを参照してください。 |
グループ口座番号の構成は、Financial Analyticsの構成における重要な手順です。一般会計および収益性モジュールのほとんどのメトリックの精度は、この手順で決定されるためです。GL調整プロセスでは、グループ口座と一緒に財務取引明細書項目コードも利用することで、補助元帳データがGL仕訳入力と適合していることが確認されます。このトピックの詳細は、この項で後述します。
GL勘定科目は、特定のグループ口座番号としてカテゴリ化できます。GROUP_ACCT_NUMフィールドは、一般会計勘定科目の内容を示しています。
注意: このタスクの構成ファイル(複数の場合もあり)は、Oracle BI Applicationsインストールの次の場所にあります。 ソース独立ファイル: <Oracle Home for BI>\biapps\etl\data_files\src_files\。 ソース固有ファイル: <Oracle Home for BI>\biapps\etl\data_files\src_files\<source adaptor>。 システム管理者は、これらのファイルを別の場所にコピーして、この場所から読み取るためのODI接続を構成しているはずです。システム管理者に、これらのファイルの取得を依頼してください。構成が完了したら、システム管理者は、構成済ファイルをODIの読取り元にコピーする必要があります。 |
file_group_acct_codes_jde.csv: このファイルでは、一般会計勘定科目をグループ口座コードにマップします。
このファイルに含まれる関連付けは、次に示すドメインに定義された値と併用します。
W_GL_GROUP_ACCOUNT
W_GL_ACCT_CATEGORY
W_FIN_STMT
これらのドメインの値と、それらの値間のマッピングにより、勘定科目を「売上の収益と原価」などのサブグループにまとめて分類します。同様に、勘定科目を「貸借対照表」と「損益」に分割して分類します。データをロードする前に、これら3つのコレクション全体を通して、勘定科目の値が矛盾なくマッピングされていることを確認する必要があります。特に、Oracle BI Applications構成マネージャで指定したGROUP_ACCOUNT_NUMドメインには、W_GL_GROUP_ACCOUNTドメインの有効なメンバーが含まれている必要があります。その次に、これらの値をW_GL_ACCT_CATEGORYドメインとW_FIN_STMTドメインのメンバーにマップします。
オラクル社のJD Edwards EnterpriseOneの一般会計勘定科目は、特定のグループ口座番号にカテゴリ分けできます。グループ口座番号はデータ抽出のほかに、フロントエンド・レポート処理でも使用されます。
GL勘定科目ディメンション表W_GL_ACCOUNT_DのGROUP_ACCT_NUMフィールドは、一般会計勘定科目の内容を表します(たとえば、現金勘定科目、AR勘定科目、長期債務勘定科目、給与勘定科目)。グループ口座番号のドメイン値の一覧については、Oracle Business Analytics Warehouseデータ・モデル・リファレンスを参照してください。
一般会計勘定科目番号へのマッピングは、利益分析と一般会計分析の両方にとって重要です(貸借対照表など)。
file_group_account_codes_jde.csvを使用すると、オブジェクトの勘定科目を関連付けるグループ勘定科目を(利用可能なグループ勘定科目から)指定できます。CSVファイルのCompany列は、オブジェクトの勘定科目が帰属する実際の会社になります。
開始勘定科目と終了勘定科目の範囲に加えて、システムは関連付けのパラメータとして入金会社を使用します。グループ勘定科目フラット・ファイルで入金会社が構成されていない場合、システムはCompanyの参照用のデフォルト値として00000を挿入します。単一のグローバルな勘定体系を使用している場合は、00000以外の会社に対してグループ勘定科目を構成しなくてもかまいません。ただし、追加の会社にグループ勘定科目を構成する場合は、それらの会社に対して考えられるすべての開始勘定科目と終了勘定科目を構成する必要があります。さらに、会社00000には、常に勘定科目の範囲全体を構成する必要があります。
次に示す表B-20は、ファイルfile_group_account_codes_jde.csvで指定される値の例です。
表B-20 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 |
W_GL_GROUP_ACCOUNTからW_FIN_STMTへのドメイン・マッピングにより、グループ口座番号と財務諸表項目コードとの間の関係を指定します。
表B-21に、グループ口座番号のマップ対象である財務取引明細書項目コードと、関連するベース・ファクト表を示します。
表B-21 財務諸表項目のコードおよび関連するベース・ファクト表
財務取引明細書項目コード | ベース・ファクト表 |
---|---|
AP |
APベース・ファクト(W_AP_XACT_F) |
AR |
ARベース・ファクト(W_AR_XACT_F) |
COGS |
売上原価ベース・ファクト(W_GL_COGS_F) |
REVENUE |
収益ベース・ファクト(W_GL_REVN_F) |
OTHERS |
GL仕訳ベース・ファクト(W_GL_OTHER_F) |
GL勘定科目をグループ口座番号に対してマッピングした後で、そのグループ口座番号を財務取引明細書項目コードに関連付けると、GL勘定科目コードを財務取引明細書項目コードに間接的に関連付けたことにもなります。
この項では、グループ口座番号への一般会計勘定科目コードのマップ方法について説明します。
注意: 新しいグループ口座番号をfile_group_acct_codes_<source system type>.csvファイルに追加する場合は、BIメタデータ・リポジトリ(RPDファイル)へのメトリックの追加も必要です。詳細は、第B.2.18.3項「論理表「ファクト - 最終 - 転記されたGL仕訳」への新規メトリックの追加方法」を参照してください。 |
GL勘定科目番号をグループ口座番号にマッピングするには:
file_group_acct_codes_jde.csvを編集します。
注意: このタスクの構成ファイル(複数の場合もあり)は、Oracle BI Applicationsインストールの次の場所にあります。 ソース独立ファイル: <Oracle Home for BI>\biapps\etl\data_files\src_files\。 ソース固有ファイル: <Oracle Home for BI>\biapps\etl\data_files\src_files\<source adaptor>。 システム管理者は、これらのファイルを別の場所にコピーして、この場所から読み取るためのODI接続を構成しているはずです。システム管理者に、これらのファイルの取得を依頼してください。構成が完了したら、システム管理者は、構成済ファイルをODIの読取り元にコピーする必要があります。 |
マップするGL勘定科目コードごとに、新しい行を作成します。このファイルには、次のフィールドが含まれています。
フィールド名 | 説明 |
---|---|
COMPANY |
COMPANYのID。 |
FROM ACCT |
勘定科目範囲の下限。これは、GL勘定科目の勘定科目セグメントに基づいています。 |
TO ACCT |
勘定科目範囲の上限。これは、GL勘定科目の勘定科目セグメントに基づいています。 |
GROUP_ACCT_NUM |
このフィールドは、Oracle BI Applications構成マネージャのドメインで指定した一般会計勘定科目のグループ口座番号を示します。たとえば、「AP」は買掛金、「CASH」は現預金勘定科目、「GEN PAYROLL」は給与勘定科目を表しています。 |
次に例を示します。
1000, 1110, 1110, CASH 1000, 1210, 1210, AR 1000, 1220, 1220, AR
注意: 必要に応じて、CSVファイルから未使用の行を削除できます。 |
file_group_acct_codes_jde.csvファイルで指定した値は、グループ勘定科目(W_GL_GROUP_ACCOUNT)のドメイン・メンバーとの矛盾がないことを確認してください。
特に、file_group_acct_names.csvのGROUP_ACCOUNT_NUMフィールドには、W_GL_GROUP_ACCOUNTドメインの有効なメンバーが含まれている必要があります。その次に、これらの値をW_GL_ACCT_CATEGORYドメインとW_FIN_STMTドメインのメンバーにマップします。
CSVファイルを保存して閉じます。
この項では、PeopleSoftのプロジェクト・ファクトに対する増分抽出の構成方法について説明します。増分抽出は、次の2通りの方法で構成できます。
データベース・トリガーを使用する: この方法を使用する場合の詳細は、第B.2.37.1項「DBトリガーを使用したPeopleSoftにおけるプロジェクト・ファクトの増分抽出の構成方法」を参照してください。
マテリアライズド・ビューを使用する: この方法を使用する場合の詳細は、第B.2.37.2項「マテリアライズド・ビューを使用したPeopleSoftにおけるプロジェクト・ファクトの増分抽出の構成方法」を参照してください。
この項では、これら2つの方法について説明します。この項には、それぞれの方法の長所や短所については説明していません。また、採用するメソッドの選択方法についてのアドバイスについても記載していません。
この項では、データベース・トリガー・ソリューションを使用することで、プロジェクト予算/原価/収益/取引約定/予測/相互賦課/保留の各ファクトについて、PeopleSoftからの増分ETLを実行する際のパフォーマンス低下を軽減する増分抽出ソリューションについて説明します。
データベース・トリガーを使用したプロジェクト・ファクトの増分抽出を構成するには:
ソース・システムに適切なSQLコードをデプロイする方法について記載された「概要」を読みます(詳細は、第B.2.37.1.1項「概要」を参照)。
Oracle BI Applications構成マネージャで更新を実行します(詳細は、第B.2.37.1.2項「Oracle BI Applications構成マネージャでの更新」を参照)。
Oracle Data Integratorで更新を実行します(詳細は、第B.2.37.1.3項「Oracle Data Integratorでの更新」を参照)。
一時インタフェースに変更を加えます(詳細は、第B.2.37.1.4項「一次インタフェースの変更」を参照)。
ロード計画に変更を加えます(詳細は、第B.2.37.1.5項「ロード計画の変更」を参照)。
BIメタデータ・リポジトリ(RPDファイル)に変更を加えます。詳細は、第B.2.37.1.6項「メタデータ・リポジトリ(RPD)の変更内容」を参照してください。
作業を開始する前に、この概要を読んでください。
サポート対象のバージョン
サポート対象のDB: Oracle/SQL Server
サポート対象のOracle BI Applicationsのリリース: 11.1.1.7.1以降
サポート対象のAppsのリリース: PeopleSoft 8.9以降
概要
PeopleSoft ESAアプリケーションは、PS_PROJ_RESOURCEのDTTM_STAMP列に正しくデータを移入しません。そのため、この列に関連する増分ロード・ロジックを考案する際に制限が課せられます。これは、プロジェクト予算、予測、取引約定、相互賦課、原価、保留および収益の各ファクトをロードする際のパフォーマンスの低下につながります。
ここでは、データベース・トリガーに基づいて、PeopleSoft OLTPのチェンジ・データ・キャプチャ(CDC)を促進する手順について簡単に説明します。注意: デフォルトでは、GoldenGateとODIを使用したCDCがサポートされます。GoldenGateのライセンスを所持していない場合は、関連するプロジェクト・ファクト表のCDCと増分ロードについて、ここで説明するソリューションを実行できます。
注意: この方法は、Oracle/SQL Serverデータベースに対してのみサポートされます。
この項での指定内容は次のとおりです。
ソース・システム(PeopleSoftアプリケーション)にデプロイするコード。
ODIリポジトリにインポートする必要のあるODI XMLファイル。
このソリューションを正常に実装するための、BIメタデータ・リポジトリ(RPDファイル)の変更内容。
要約
PS_PROJ_RESOURCEに対するトリガーは、変更された行のPKをPROJ_RESOURCE_UPD_AUD表に挿入するOLTPで作成されます(コードについては、「手順」の項を参照)。
ビュー(OBIEE_PS_PROJ_RESOURCE_VW)は、PS_PROJ_RESOURCEと、このトリガー表(PROJ_RESOURCE_UPD_AUD)に作成されます。このビュー(OBIEE_PS_PROJ_RESOURCE_VW)がSDEファクトの抽出ソースで使用されます。(コードについては、「手順」の項を参照)。
削除された行は、ETLにより、フィルタupdate_type = 'D'が適用されたトリガー表(PROJ_RESOURCE_UPD_AUD)からPE表にキャプチャされます。
その他の削除戦略インタフェースもソフト削除ロジックを適切に処理するために更新します。
ODIモデル・レイヤーで、オブジェクトPS_PROJ_RESOURCE表のリソース名をMVに対するビュー(OBIEE_PS_PROJ_RESOURCE_VW)に置換します。
削除された行は、ETLにより、OBIEE_PS_PROJ_RESOURCE_DEL_VWから<ファクト>_DEL表にキャプチャされます。
SILファクト・インタフェースは、次のように変数の値を設定すると、ソフト削除ロジックを適切に処理するようになります。
- SOFT_DELETE_PREPROCESS = 'N' (<ファクト>_PE表に値が移入されなくなります)
- SOFTDELETE_FEATURE_ENABLED = 'Y'
手順の要約:
トリガー・オブジェクトとデータベース・オブジェクトを作成します。
完全ETLを実行します。
OLTPでデータに変更を加えます。
SDEファクトの抽出を実行します。
SILファクトのロードを実行します。
ソフト削除ETLを実行します。
想定内容
トリガーがあることで、OLTPアプリケーションのパフォーマンスになんらかの影響があります。
PS_PROJ_RESOURCEからの実際の削除が、Oracle Business Analytics Warehouseではソフト削除として処理されます。
重要: ユーザーは、トリガー表PROJ_RESOURCE_UPD_AUDが大きくなりすぎてETL実行時間に影響を与えないようにするために、このトリガー表を時々(たとえば、毎週)切り捨てる必要があります。
Oracleデータベースに必要なデータベースの変更内容
ソースOLTPデータベースがOracleデータベース・インスタンスの場合は、ファイルpsft_orcl_trigger.txtに含まれるSQLスクリプトを実行します。このファイルは、インストール・フォルダの<Oracle Home for BI>/biapps/etl/src_specific/PSFT/oracleにあります。
次に例を示します。
/*ORACLE SCRIPT TO IMPLEMENT INCREMENTAL SOLUTION FOR PEOPLESOFT ADAPTOR FOR OBIA PROJECT ANALYTICS */ DROP TABLE PROJ_RESOURCE_UPD_AUD; / CREATE TABLE PROJ_RESOURCE_UPD_AUD( ROW_WID number(10), BUSINESS_UNIT varchar2(5) NULL, PROJECT_ID varchar2(15) NULL, ... ... And so on.
MS SQLデータベースに必要なデータベースの変更内容
ソースOLTPデータベースがMS SQL Serverデータベース・インスタンスの場合、ファイルpsft_mssql_trigger.txtに含まれるSQLスクリプトを実行します。このファイルは、インストール・フォルダの<Oracle Home for BI>/biapps/etl/src_specific/PSFT/ms_sql_serverにあります。
次に例を示します。
/*MSSQL SCRIPT TO IMPLEMENT INCREMENTAL SOLUTION FOR PEOPLESOFT ADAPTOR FOR OBIA PROJECT ANALYTICS */ /* Replace <DB> with the actual schema name */ USE <DB> DROP TABLE PROJ_RESOURCE_UPD_AUD; CREATE TABLE PROJ_RESOURCE_UPD_AUD( ROW_WID INT IDENTITY(1,1) PRIMARY KEY, ... ... And so on.
Oracle BI Applications構成マネージャで、次の変更を行います。
SOFT_DELETE_PREPROCESSの値を'N'に設定します。
ファクト・グループ・レベルの変数については、SOFTDELETE_FEATURE_ENABLEDの値を'Y'に設定します。
次の変更を行います。
ODIモデル・レイヤーで、オブジェクトPS_PROJ_RESOURCE表のリソース名をビューOBIEE_PS_PROJ_RESOURCE_VWに置換します。
PeopleSoft 90を使用している場合は、この指示に従います。それ以外の場合は、9.0フォルダに移動します。つまり、ODIデザイナ・ナビゲータで、「モデル」→「PeopleSoft 9.0」→「peoplesoft 9.0 FNSCM」→「FPC-プロジェクト」に移動し、オブジェクトPROJ_RESOURCEを開いて、「リソース名」を「OBIEE_PS_PROJ_RESOURCE_VW」に変更します。
列LAST_UPDATE_DTのTIMESTAMPをODIモデルのオブジェクトPROJ_RESOURCEに追加します。
「保存」をクリックします。
前述したすべてのファクトに対して、適切なSDEシナリオを再生成します。
つまり、ODIデザイナ・ナビゲータで、「プロジェクト」→「マッピング」→「SDE_PSFT_90_Folder」に移動し、ファクト・フォルダ(たとえば、SDE_PSFT_ProjectCostLineFact)から「パッケージ」→「シナリオ」の順に移動して、名前を右クリックしてから「再生成」ボタンを選択します。
次に示すように、一時インタフェースを変更します。
ODI一時インタフェースで、LAST_UPDATE_DT列をコードに含めるようにCHANGED_ON_DTのマッピングを変更する必要があります。
たとえば、次の原価ファクトに対する一時インタフェースについて考えてみます。
SDE_PSFT_ProjectCostLineFact.W_PROJ_COST_LINE_FS_SQ_PROJ_RESOURCE
CHANGED_ON_DTを次にマッピングします。
RUN_REPLICATED_TRANSACTIONAL('#IS_SDS_DEPLOYED',PS_PROJ_RESOURCE.DTTM_STAMP,PS_PROJ_RESOURCE.CDC$_SRC_LAST_UPDATE_DATE)
更新日を次に変更します。
RUN_REPLICATED_TRANSACTIONAL('#IS_SDS_DEPLOYED',COALESCE(PS_PROJ_RESOURCE.LAST_UPDATE_DT,PS_PROJ_RESOURCE.DTTM_STAMP),PS_PROJ_RESOURCE.CDC$_SRC_LAST_UPDATE_DATE)
増分フィルタを変更して、PS_PROJ_RESOURCE.DTTM_STAMPをCOALESCE(PS_PROJ_RESOURCE.LAST_UPDATE_DT,PS_PROJ_RESOURCE.DTTM_STAMP)に置き換えます。
シナリオを再生成します。
残りの各ファクト(予算、予測、取引約定、相互賦課、保留および収益)に対して、この手順を繰り返します。
次に示すように、ロード計画を変更します。
次に示すように、削除された行をロードするインタフェースをロード計画に追加する必要があります。
ODIデザイナ・ナビゲータで、「ロード計画とシナリオ」→「生成済ロード計画」の順に移動して、そのロード計画を開きます。
「ステップ」タブで、「1 SDE抽出」ステップ→「2 SDEファクト・グループ」→「パラレル(永続/一時ステージング表)」→「3 SDE PS PROJECT」の順に移動します。
次のスクリーンショットに示すように、ルート・ステップの下にシリアル・ステップ'Projects_Identify_Deletes'を作成して、プロジェクト原価、予算、予測、取引約定、相互賦課、保留および収益の各ファクトのステップに対して削除識別ファクトのシナリオを追加します。
ロード計画に関連するシナリオを追加します。たとえば、接頭辞SDE_PSFT_90_ADAPTORの付いたシナリオはPeopleSoft 90ロード計画に追加し、接頭辞SDE_PSFT_91_ADAPTORの付いたシナリオはPeopleSoft 91ロード計画に追加します。
これらのタスクは、「失敗から再開」に設定する必要があります。
新しく追加したこれらのタスクをクリックし、スクリーンショットで示すように、'-1'バージョンを取るように編集します。
これは、複数のシナリオが存在する場合に、最新のシナリオが使用されるようにするために必要になります。
ロード計画を保存します。
削除されたレコードを除外するように、ベース・ファクトのBMMフィルタを変更します。これらの変更は、オフライン・モードで実行するようにしてください。
Oracle BI EE管理ツールで、BIメタデータ・リポジトリ(例: OracleBIAnalyticsApps.rpd)を編集します。
BMMレイヤーで、「ファクト - プロジェクト予算」に移動します。
クリックして、この論理ファクトの下の各LTSを表示します。
Fact_W_PROJ_BUDGET_F_Budget_Factに、次に示すフィルタを追加します。
予算ファクトITD LTSに、同様のフィルタを追加します(削除フラグ = 'N')。
同様に、原価、予測、取引約定、相互賦課、収益、保留の各ファクトに対して変更を行います。
PeopleSoft ESAアプリケーションは、PS_PROJ_RESOURCEのDTTM_STAMP列に正しくデータを移入しません。そのため、この列に関連する増分ロード・ロジックを考案する際に制限が課せられます。これは、プロジェクト予算、予測、取引約定、相互賦課、原価および収益の各ファクトをロードする際のパフォーマンスの低下につながります。
データベース・トリガーを使用したプロジェクト・ファクトの増分抽出を構成するには:
ソース・システムに適切なSQLコードをデプロイする方法について記載された「概要」を読みます(詳細は、第B.2.37.2.1項「概要」を参照)。
Oracle BI Applications構成マネージャで更新を実行します(詳細は、第B.2.37.2.2項「Oracle BI Applications構成マネージャでの更新」を参照)。
Oracle Data Integratorで更新を実行します(詳細は、第B.2.37.2.3項「Oracle Data Integratorでの更新」を参照)。
一時インタフェースに変更を加えます(詳細は、第B.2.37.2.4項「一次インタフェースの変更」を参照)。
ロード計画に変更を加えます(詳細は、第B.2.37.2.5項「ロード計画の変更」を参照)。
BIメタデータ・リポジトリ(RPDファイル)に変更を加えます。詳細は、第B.2.37.2.6項「メタデータ・リポジトリ(RPD)の変更内容」を参照してください。
ここでは、マテリアライズド・ビューの高速リフレッシュ(MVログを使用)に基づいて、PeopleSoft OLTPのチェンジ・データ・キャプチャ(CDC)を促進する手順について説明します。デフォルトでは、GoldenGateとODIを使用したCDCがサポートされます。GoldenGateのライセンスを所持していない場合は、関連するプロジェクト・ファクト表のCDCと増分ロードについて、ここで説明するソリューションに従うことができます。
注意: この方法は、Oracleデータベースに対してのみサポートされます。
この項での指定内容は次のとおりです。
ソース・システム(PeopleSoftアプリケーション)にデプロイするコード。
ODIリポジトリにインポートする必要のあるODI XMLファイル。
このソリューションを正常に実装するためのRPDの変更内容。
サポート対象のバージョン
サポート対象のDB: パッチ(RDBMSパッチ9580103)を適用した10.2.0.4、Oracle 11i以降
サポート対象のOracle BI Applicationsのリリース: 11.1.1.7.1以降
サポート対象のAppsのリリース: PeopleSoft 8.9以降
要約
PS_PROJ_RESOURCEのMVログは、OLTPで作成されます(コードについては、「手順」の項を参照)。
PS_PROJ_RESOURCEの一意索引に基づいたPK制約を作成する必要があります。
MVは、LAST_UPDATE_DTの追加の列を使用してPS_PROJ_RESOURCEに作成します。この列には、システム日付に基づいた値を移入します。この新しいフィールドには、索引を作成します。(コードについては、「手順」の項を参照)。
MVに対するビューを作成します。このビューは、SDEファクトの抽出ソースで使用されます。(コードについては、「手順」の項を参照)。
MVの1回限りの完全リフレッシュを実行します。
日次ETLの実行の前に、MVを高速リフレッシュします。MVのリフレッシュはロード計画に統合します(詳細は、後述する「手順」の項を参照)。注意: Oracleは高速リフレッシュの実行後にMVログを自動的に消去します(MVログは本質的に巨大化するため、MVの高速リフレッシュの時間が短くなるように、日次ETLの実行を行うようにしてください)。
ODIモデル・レイヤーで、オブジェクトPS_PROJ_RESOURCE表のリソース名をMVに対するビュー(OBIEE_PS_PROJ_RESOURCE_VW)に置換します。
削除された行は、ETLにより、DMLTYPE$$ = 'D'のフィルタを適用したMVログから<ファクト>_DEL表に取り込まれます。このETLは、高速リフレッシュの前に実行します。そのようにしないと、データが切り捨てられます。
SILファクト・インタフェースは、次のように変数の値を設定すると、ソフト削除ロジックを適切に処理するようになります。
- SOFT_DELETE_PREPROCESS = 'N' (<ファクト>_PE表に値が移入されなくなります)
- SOFTDELETE_FEATURE_ENABLED = 'Y'
手順の要約:
MVログ、MV、ビューを作成します。
MVの1回限りの完全リフレッシュを実行します。
完全ETLを実行します。
OLTPでデータに変更を加えます。
削除の一次キャプチャETLを実行します。
MVを高速リフレッシュします(自動的に、MVが切り捨てられます)。
SDEファクトの抽出を実行します。
SILファクトのロードを実行します。
想定内容
MVログが存在するために、OLTPアプリケーションにはなんらかのパフォーマンスの影響があります。また、頻繁にMVをリフレッシュしていない場合は、MVログのリフレッシュ時間に関する潜在的な問題があります。この問題を回避するために、日常的にリフレッシュを実行してください。
このソリューションには、パッチ(RDBMSパッチ9580103)を適用したOracle RDBMSバージョン10.2.0.4またはバージョン11.1.2.0以降が必要になります。事前に作成した表に基づくマテリアライズド・ビューを更新しているときに、Oracleデータベースの動作が変化する場合は、このソリューションへの変更が必要になることがあります。
いずれかのユーザーが同じMVログを使用して別のMVを作成する場合、そのユーザーは、ログを削除する前に依存関係にあるMVをすべてリフレッシュする必要があります。
PS_PROJ_RESOURCEからの実際の削除が、Oracle Business Analytics Warehouseではソフト削除として処理されます。
データベースの変更
次に示すOLTPデータベースのステップを指定した順序どおりにインスタンス内で実行します。
ALTER TABLE PS_PROJ_RESOURCE ADD CONSTRAINT PS_PROJ_RESOURCE_PK PRIMARY KEY (BUSINESS_UNIT,PROJECT_ID,ACTIVITY_ID,RESOURCE_ID) USING INDEX PS_PROJ_RESOURCE; CREATE MATERIALIZED VIEW LOG ON PS_PROJ_RESOURCE NOCACHE LOGGING NOPARALLEL WITH SEQUENCE; CREATE TABLE OBIEE_PS_PROJ_RESOURCE_MV AS SELECT * FROM PS_PROJ_RESOURCE WHERE 1=2; ALTER TABLE OBIEE_PS_PROJ_RESOURCE_MV ADD (LAST_UPDATE_DT DATE DEFAULT SYSDATE); CREATE MATERIALIZED VIEW OBIEE_PS_PROJ_RESOURCE_MV ON PREBUILT TABLE REFRESH FAST ON DEMAND AS SELECT * FROM PS_PROJ_RESOURCE; CREATE VIEW OBIEE_PS_PROJ_RESOURCE_VW AS SELECT * FROM OBIEE_PS_PROJ_RESOURCE_MV; CREATE VIEW OBIEE_PS_PROJ_RESOURCE_DEL_VW AS SELECT business_unit, project_id, activity_id, resource_id FROM (SELECT business_unit, project_id, activity_id, resource_id, dmltype$$, CASE WHEN sequence$$ = MAX(sequence$$) over (PARTITION BY business_unit, project_id, activity_id, resource_id ) THEN sequence$$ ELSE NULL END AS sequence$$ FROM mlog$_ps_proj_resource) WHERE sequence$$ IS NOT NULL And dmltype$$ ='D';
マテリアライズド・ビューをリフレッシュします。
これにより、コマンドEXECUTE DBMS_MVIEW.REFRESH('OBIEE_PS_PROJ_RESOURCE_MV', 'C');などを使用した増分実行時に、MVが高速にリフレッシュされるようになります。
抽出SQLを調べてクエリ計画を実行することで、どの索引をMVに作成するかを判断します。
たとえば、LAST_UPDATE_DTフィールドには索引が必要になり、PKフィールドには一意索引が必要になります。
Oracle BI Applications構成マネージャで、次の変更を行います。
SOFT_DELETE_PREPROCESSの値を'N'に設定します。
ファクト・グループ・レベルの変数については、SOFTDELETE_FEATURE_ENABLEDの値を'Y'に設定します。
カスタムのMVを最新の状態に維持する最良の方法は、それらのリフレッシュをODIロード計画に結合することです。次のPLSQL呼び出しにより、OBIEE_PS_PROJ_RESOURCE_MV:BEGINDBMS_MVIEW.REFRESH('OBIEE_PS_PROJ_RESOURCE_MV', 'F');END;の高速リフレッシュが確実になります。
ODIデザイナ・ナビゲータで、次に示す変更を行います。
ODIモデル・レイヤーで、オブジェクトPS_PROJ_RESOURCE表のリソース名をビューOBIEE_PS_PROJ_RESOURCE_VWに置換します。
PeopleSoft 90を使用している場合は、この指示に従います。それ以外の場合は、9.0フォルダに移動します。つまり、ODIデザイナ・ナビゲータで、「モデル」→「PeopleSoft 9.0」→「Peoplesoft 9.0 FNSCM」→「FPC-プロジェクト」に移動し、オブジェクトPROJ_RESOURCEを開いて、「リソース名」を「OBIEE_PS_PROJ_RESOURCE_VW」に変更します。
列LAST_UPDATE_DTのTIMESTAMPをODIモデルのオブジェクトPROJ_RESOURCEに追加します。
「保存」をクリックします。
前述したすべてのファクトに対して、適切なSDEシナリオを再生成します。
つまり、ODIデザイナ・ナビゲータで、「プロジェクト」→「マッピング」→「SDE_PSFT_90_Folder」に移動し、ファクト・フォルダ(たとえば、SDE_PSFT_ProjectCostLineFact)から「パッケージ」→「シナリオ」の順に移動して、名前を右クリックしてから「再生成」ボタンを選択します。
次に示すように、一時インタフェースを変更します。
ODI一時インタフェースで、LAST_UPDATE_DT列をコードに含めるようにCHANGED_ON_DTのマッピングを変更する必要があります。
たとえば、次の原価ファクトに対する一時インタフェースについて考えてみます。
SDE_PSFT_ProjectCostLineFact.W_PROJ_COST_LINE_FS_SQ_PROJ_RESOURCE
CHANGED_ON_DTを次にマッピングします。
RUN_REPLICATED_TRANSACTIONAL('#IS_SDS_DEPLOYED',PS_PROJ_RESOURCE.DTTM_STAMP,PS_PROJ_RESOURCE.CDC$_SRC_LAST_UPDATE_DATE)
更新日を次に変更します。
RUN_REPLICATED_TRANSACTIONAL('#IS_SDS_DEPLOYED',COALESCE(PS_PROJ_RESOURCE.LAST_UPDATE_DT,PS_PROJ_RESOURCE.DTTM_STAMP),PS_PROJ_RESOURCE.CDC$_SRC_LAST_UPDATE_DATE)
増分フィルタを変更して、PS_PROJ_RESOURCE.DTTM_STAMPをCOALESCE(PS_PROJ_RESOURCE.LAST_UPDATE_DT,PS_PROJ_RESOURCE.DTTM_STAMP)に置き換えます。
シナリオを再生成します。
残りの各ファクト(予算、予測、取引約定、相互賦課、保留および収益)に対して、この手順を繰り返します。
次に示すように、ロード計画を変更します。
削除された行をロードするインタフェースをロード計画に追加する必要があります。
ODIデザイナ・ナビゲータで、「ロード計画とシナリオ」→「生成済ロード計画」の順に移動して、そのロード計画を開きます。
「ステップ」タブで、「1 SDE抽出」ステップ→「2 SDEファクト・グループ」→「パラレル(永続/一時ステージング表)」→「3 SDE PS PROJECT」の順に移動します。
次のスクリーンショットに示すように、ルート・ステップの下にシリアル・ステップ'Projects_Identify_Deletes'を作成して、プロジェクト原価、予算、予測、取引約定、相互賦課、保留および収益の各ファクトのステップに対して削除識別ファクトのシナリオを追加します。
ロード計画に関連するシナリオを追加します。たとえば、接頭辞SDE_PSFT_90_ADAPTORの付いたシナリオはPeopleSoft 90ロード計画に追加し、接頭辞SDE_PSFT_91_ADAPTORの付いたシナリオはPeopleSoft 91ロード計画に追加します。
これらのタスクは、「失敗から再開」に設定する必要があります。
新しく追加したこれらのタスクをクリックし、スクリーンショットで示すように、'-1'バージョンを取るように編集します。
これは、複数のシナリオが存在する場合に、最新のシナリオが使用されるようにするために必要になります。
ロード計画を保存します。
削除されたレコードを除外するように、ベース・ファクトのBMMフィルタを変更します。これらの変更は、オフライン・モードで実行するようにしてください。
Oracle BI EE管理ツールで、BIメタデータ・リポジトリ(例: OracleBIAnalyticsApps.rpd)を編集します。
BMMレイヤーで、「ファクト - プロジェクト予算」に移動します。
クリックして、この論理ファクトの下の各LTSを表示します。
Fact_W_PROJ_BUDGET_F_Budget_Factに、次に示すフィルタを追加します。
予算ファクトITD LTSに、同様のフィルタを追加します(削除フラグ = 'N')。
同様に、原価、予測、取引約定、相互賦課、収益、保留の各ファクトに対して変更を行います。
この項では、プロジェクト・タイプに基づいて、Peoplesoftソースのプロジェクト・ディメンションのプロジェクト資産計上可能フラグを構成する方法について説明します。
プロジェクト資産計上可能フラグは、フラット・ファイルfile_project_capitalizable_flag_psft.csvのプロジェクト・タイプに関連付けられています。
注意: このタスクの構成ファイル(複数の場合もあり)は、Oracle BI Applicationsインストールの次の場所にあります。 ソース独立ファイル: <Oracle Home for BI>\biapps\etl\data_files\src_files\。 ソース固有ファイル: <Oracle Home for BI>\biapps\etl\data_files\src_files\<source adaptor>。 システム管理者は、これらのファイルを別の場所にコピーして、この場所から読み取るためのODI接続を構成しているはずです。システム管理者に、これらのファイルの取得を依頼してください。構成が完了したら、システム管理者は、構成済ファイルをODIの読取り元にコピーする必要があります。 |
PeopleSoftのプロジェクト資産計上可能フラグを構成するには:
次のSQLを使用して(OLTPソースで実行して)、プロジェクト・タイプ区分コードを特定します。
SELECT T.PROJECT_TYPE||'~'||T.SETID AS PROJECT_TYPE FROM PS_PROJ_TYPE_TBL T WHERE T.EFFDT = (SELECT MAX(EFFDT) FROM PS_PROJ_TYPE_TBL T1 WHERE T1.SETID = T.SETID AND T1.PROJECT_TYPE = T.PROJECT_TYPE AND T1.EFFDT <= CURRENT_TIMESTAMP GROUP BY T1.SETID, T1.PROJECT_TYPE)
file_project_capitalizable_flag_psft.csvファイルを編集します。
CSVファイルで、PROJECT_TYPE列のデータをPROJECT_TYPE_CLASS_CODE列にコピーします。
CAPITALIZABLE_FLG列で、プロジェクト・タイプ区分をYまたはNの値にマッピングします。プロジェクト・タイプ区分が資産計上可能と見なされる場合は、Yを入力します。それ以外の場合は、Nを入力します。
ファイルを保存して閉じます。
E-Business Suiteでは、基本編成済予算が予算ファクト(W_PROJ_BUDGET_F)表に抽出されます。この表の単位は予算明細になります。基本編成済予算のみが抽出されるため、この表のレコードはOracle Business Analytics Warehouseにロードした後で更新されることはなく、増分ETL実行時に新しいレコードが挿入されるだけになります。予算は、予算ディメンション(W_PROJ_BUDGET_D)に格納されます。
注意: E-Business Suiteでは、取引通貨はこのファクトのドキュメント通貨になります。
予算メトリックに対するフィルタの定義
ユーザーは単一のプロジェクトに複数の予算を作成できます。また、同一の予算タイプに複数のバージョンを作成できます。そのため、公開されるすべてのメトリックは、次のフィルタでフィルタ処理します。
承認済予算タイプ。1つのプロジェクトには、1つの原価予算(予算タイプ「承認済原価予算」)と、1つの収益予算(予算タイプ「承認済収益予算」)のみを含めることができます。そのため、原価予算メトリックを承認済原価予算フラグと承認済収益予算フラグでフィルタ処理することで、そのメトリックには1つの予算のみのデータが含まれるようになります。
現行予算または当初予算。各プロジェクト予測には、複数のバージョンを含めることができます。現行バージョンは、当初バージョンと同じにならないことがあります。そのため、一度に1つの予測バージョンのみを表示するために、現行バージョンと当初バージョンには個別のメトリックが存在します。これらのフラグは、予測が基本編成されるときに自動的にOLTPで設定されます。ただし、それらのフラグはユーザーが更新することもできます。
ユーザーは、「ファクト - プロジェクト予算」ファクト表から「プレゼンテーション」領域にフィルタを適用していないメトリックを移動することで、その他の予算タイプや予算バージョンのメトリックを引き続き確認できます。データの重複を回避するため、レポートには「ディメンション - プロジェクト予算バージョン.予算タイプ」および「ディメンション - プロジェクト予算バージョン.予算バージョン」に対するフィルタを含める必要があります。
ETLの初回実行の前に、HTMLアプリケーションの「財務計画タイプ」ページに移動して、「承認済原価予算」タイプと「承認済収益予算」タイプを、次のスクリーンショット例に示すように設定します。
フォーム・クライアントで作成された予算
フォーム・クライアントから予算を入力した場合、2つの事前定義予算タイプ(ACおよびAR)については、PA_BUDGET_ TYPES.PLAN_TYPE列にデータが移入されません。そのため、SDE_ORA_ProjectBudgetDimensionフォルダ内のインタフェースSDE_ORA_ProjectBudgetDimension_BudgetType.W_PROJ_BUDGET_DSには、次に示すETLロジックを組み込みます。
DOMAIN_DEFAULT_UNASSIGNED( TO_CHAR(case when ISNULL(SQ_PA_BUDGET_VERSIONS.PLAN_TYPE) then DECODE(SQ_PA_BUDGET_VERSIONS.BUDGET_TYPE_CODE1,'AC','BUDGET','AR','BUDGET','FC','FORECAST','FR', 'FORECAST',SQ_PA_BUDGET_VERSIONS.PLAN_TYPE else SQ_PA_BUDGET_VERSIONS.PLAN_TYPE end )
予算ファクトの基準日付
予算ファクトには、次に示す2つのセットの会計日と期間WIDが含まれています。
PROJ_ACCT_START_DT_WID、PROJ_ACCT_END_DT_WID、およびPROJ_PERIOD_WID
プロジェクト会計(PA)カレンダを使用して時間フェーズ化された予算の場合にのみ、PROJ_ACCT_START_DT_WIDおよびPROJ_ACCT_END_DT_WIDには、予算明細のSTART_DATEおよびEND_DATEを使用してデータが移入されます。
GL_ACCT_START_DT_WID、GL_ACCT_END_DT_WIDおよびGL_PERIOD_WID
一般会計(GL)カレンダを使用して時間フェーズ化された予算の場合、GL_ACCT_START_DT_WIDおよびGL_ACCT_END_DT_WIDには、予算明細のSTART_DATEおよびEND_DATEを使用してデータが移入されます。
時間フェーズが'P'(PA)、'N'(時間フェーズなし)または'R'(日付範囲)で定義されている予算については、その日付がGLカレンダ(GL_MCAL_CAL_WIDで固定されているカレンダ)に含まれている期間を選択することで、GL_ACCT_START_DT_WIDおよびGL_PERIOD_WIDが予算明細のSTART_DATEを使用して解決されます。
この方法では、時間フェーズが'P'、'N'、および'R'の場合は、OLTPデータベースで指定されたGLカレンダにSTART_DATEが含まれている期間があることを想定しています。
フォームベースの予算の場合、アプリケーションではプロジェクト機能通貨以外の各種通貨で予算明細を作成できない場合でも、プロジェクト機能通貨の通貨がドキュメント通貨フィールドのデフォルト値に使用されます。これにより、予算金額がグローバル通貨で分析できるようになります。たとえば、ドキュメント直接費金額には、次のようにデータが移入されます。
COALESCE(SQ_PA_BUDGET_LINES.TXN_RAW_COST, IIF(SQ_PA_BUDGET_LINES.TXN_CURRENCY_CODE = SQ_PA_BUDGET_LINES.PROJFUNC_CURRENCY_CODE,SQ_PA_BUDGET_LINES.RAW_COST, NULL))
サービス業界では、従業員は所属する組織の外部が所有するプロジェクトに従事することがあります。その場合、プロジェクトを所有する組織と、人材資源(従業員)を所有する組織が異なることになります。このようなシナリオをPeoplesoftで処理するには、プロジェクト会計の組織間収支配分方式を使用して、プロジェクトやアクティビティによりエンティティ間で生成される経費と収益を配分します。プロジェクトを所有する組織と、人材資源を所有する組織の間での契約を定義するルールと会計手順を設定します。
配分ルールが定義されて有効化されると、価格設定プロセスは配分アプリケーション・エンジン・プロセス(PSA_SHARING)呼び出して、配分することが指定された行を検索します。これらの行は、分析タイプに応じて原価ファクトまたは収益ファクトにロードされます。配分される行を特定するための配分設定のページで設定した条件を満たした行は、分配プロセスの対象になります。たとえば、プロジェクトまたはアクティビティを所有する組織と、取引を所有する組織が異なっているとします。適用可能な配分ルールが存在していると、その行は配分ルールの例外と見なされなくなります。
組織収支配分の例
US004 (受給側)とUS001 (配給側)の間で、例外セットのない80%の収益配分ルールが実施されているとします。
PeopleSoftで作成した配分される行は、相互賦課ファクト表にロードされます。
注意: このリリースでは、内部契約の配分がサポートされています。また、PeopleSoft areの「取引追加」ページ(「プロジェクトコスト管理」→「取引定義」→「取引追加」)で直接作成した行の配分はサポートされていません。
予測ファクト表は、PA_BUDGET_LINESに基づいています。予算バージョン表にフィルタを適用して、予測ファクトの基本編成済予測のみを抽出します。この表の単位は予測明細になります。ETLでは基本編成済予測のみが抽出されるため、この表のレコードはOracle Business Analytics Warehouseにロードした後で更新されることはなく、増分実行時に新しいレコードが挿入されるだけになります。予測は、予測ディメンション(W_PROJ_BUDGET_D)にも格納されます。
注意:
E-Business Suiteでは、このファクトのドキュメント通貨が取引通貨になります。
予測メトリックに対するフィルタの定義
ユーザーは、単一のプロジェクトに複数の予測を作成できます。また、同一の予測タイプに複数のバージョンを作成できます。そのため、Oracle BI Applicationsでは、次に示すフィルタを使用して、公開されたすべてのメトリックにフィルタを適用します。
主予測タイプ: 1つのプロジェクトには予測タイプが「主原価予測」の原価予測を1つと、予測タイプが「主収益予測」の収益予測を1つのみを含めることができます。そのため、すべての原価予測メトリックと収益予測メトリックには、2つのフラグ(「主原価予測」フラグと「主収益予測」フラグ)に対するフラグを適用して、1つの予測についてのみのデータが表示されるようにします。
現行の予測または当初の予測: 1つのプロジェクト予測には、複数のバージョンを含めることができます。一度に1つの予測バージョンのみを表示する場合は、現行バージョンと現行当初バージョンのメトリックごとに表示されます。これらのフラグは、予測が基本編成されるときに自動的にOLTPで設定されます。ただし、それらのフラグはユーザーが更新することもできます。
ユーザーは、フィルタを適用していないメトリックを「ファクト - プロジェクト予測」ファクト表から「プレゼンテーション」領域に移動することで、その他の予測タイプの予測バージョンのメトリックを引き続き表示できます。データの重複を避けるため、レポートには「ディメンション - プロジェクト予測バージョン.予測タイプ」と「ディメンション - プロジェクト予測バージョン.予測バージョン」に対するフィルタを含める必要があります。
ETLの初回実行の前に、HTMLクライアントで「財務計画タイプ」ページにアクセスし、「主原価予測」と「主収益予測」の予測タイプを選択します。
フォーム・クライアントで作成された予測
フォーム・クライアントから予測を入力した場合、2つの事前定義済予算タイプ(FCおよびFR)については、PA_BUDGET_ TYPES.PLAN_TYPE列にデータが移入されません。そのため、SDE_ORA_ProjectBudgetDimensionフォルダ内のSDE_ORA_ProjectBudgetDimension_BudgetType.W_PROJ_BUDGET_DSには、次に示すETLロジックを組み込みます。
DOMAIN_DEFAULT_UNASSIGNED( TO_CHAR(case when ISNULL(SQ_PA_BUDGET_VERSIONS.PLAN_TYPE) then DECODE(SQ_PA_BUDGET_VERSIONS.BUDGET_TYPE_CODE1,'AC','BUDGET','AR','BUDGET','FC','FORECAST','FR', 'FORECAST',SQ_PA_BUDGET_VERSIONS.PLAN_TYPE else SQ_PA_BUDGET_VERSIONS.PLAN_TYPE end ) )
フォーム・クライアントで作成したFCおよびFRタイプの予測バージョンについては、PRIMARY_COST_FORECAST _FLAGおよびPRIMARY_REV_FORECAST_FLAGがPA_BUDGET_VERSIONSに移入されません。そのため、SDE_ORA_ProjectBudgetDimensionフォルダ内のSDE_ORA_ProjectBudgetDimension_BudgetType.W_PROJ_BUDGET_DSには、次に示すETLロジックを組み込みます。
COALESCE(SQ_PA_BUDGET_VERSIONS.PRIMARY_COST_FORECAST_FLAG, case when SQ_PA_BUDGET_VERSIONS.BUDGET_TYPE_CODE1 = 'FC' THEN 'Y' ELSE NULL END) COALESCE(SQ_PA_BUDGET_VERSIONS.PRIMARY_REV_FORECAST_FLAG, case when SQ_PA_BUDGET_VERSIONS.BUDGET_TYPE_CODE1 = 'FR' THEN 'Y' ELSE NULL END)
フォームベースの予測については、アプリケーションでプロジェクト機能通貨とは別の通貨による予測明細を作成できない場合でも、ドキュメント通貨フィールドのプロジェクト機能通貨がデフォルトに設定されています。これにより、予測金額はグローバル通貨でも分析できます。たとえば、ドキュメントEAC直接費金額には、次に示すようにデータが移入されます。
COALESCE(SQ_PA_BUDGET_LINES.TXN_RAW_COST,IIF(SQ_PA_BUDGET_LINES.TXN_CURRENCY_CODE = SQ_PA_BUDGET_LINES.PROJFUNC_CURRENCY_CODE, SQ_PA_BUDGET_LINES.RAW_COST,NULL))
予測ファクトの基準日付: 予測ファクトには、次に示す2つのセットの会計日付と期間WIDが含まれています。
PROJ_ACCT_START_DT_WID、PROJ_ACCT_END_DT_WIDおよびPROJ_PERIOD_WID
プロジェクト会計(PA)カレンダを使用して時間フェーズ化された予測の場合にのみ、PROJ_ACCT_START_DT_WIDおよびPROJ_ACCT_END_DT_WIDには、予測明細のSTART_DATEおよびEND_DATEを使用してデータが移入されます。
GL_ACCT_START_DT_WID、GL_ACCT_END_DT_WIDおよびGL_PERIOD_WID
一般会計(GL)カレンダで時間フェーズ化された予測の場合、GL_ACCT_START_DT_WIDおよびGL_ACCT_END_DT_WIDには、予測明細のSTART_DATEおよびEND_DATEを使用してデータが移入されます。
時間フェーズが'P' (PA)、'N' (時間フェーズなし)、または'R' (日付範囲)の予測については、その日付が対応するGLカレンダに含まれている期間を選択することで、GL_ACCT_START_DT_WIDおよびGL_PERIOD_WIDが予測明細のSTART_DATEを使用して解決されます。
この方法では、時間フェーズが'P'、'N'、および'R'の場合は、OLTPデータベースで指定されたGLカレンダにSTART_DATEが含まれている期間が常にあることを想定しています。
タスク・ディメンションのデータは、E-Business Suiteのタスク表(PA_TASKS)と、次に示すような他のタスク関連のOLTP表がソースになります。
PA_PROJ_ELEMENTS
PA_PROJ_ELEMENT_VERSIONS
PA_PROJ_ELEM_VER_STRUCTURE
PA_PROJ_ELEM_VER_SCHEDULE
WBS_NUMBER、PRIORITY_CODE、SCHEDULE_START_DATE、SCHEDULE_END_DATEなどの属性は、これらの表がソースになります。Oracle BI Applicationsは、次に示すフィルタ条件を使用することで、最新バージョンの財務構造のみをサポートするようになります。
PA_PROJ_ELEM_VER_STRUCTURE.STATUS_CODE = 'STRUCTURE_PUBLISHED' AND PA_PROJ_ELEM_VER_STRUCTURE.LATEST_EFF_PUBLISHED_FLAG = 'Y'
W_TASK_DH階層表には、W_TASK_Dのタスクごとにフラット化された階層が格納されます。これは、W_TASK_Dと同じ単位になり、タイプIディメンションとしてモデル化されます。階層内のすべてのタスクは、次に示す列をサポートします。
TASK_NAME
TASK_NUMBER
WBS_LEVEL
WBS_NUMBER
W_TASK_D表とW_TASK_DH表の単位はどちらも同じため、ファクト表には、この表と結合するための個別の外部キーがありません。そのかわりに、タスク外部キーに対する結合があります。
デフォルトでは、Oracle BI Applicationsはフラット化された階層で20のレベルをサポートします。このレベルは、ベース、1から18、およびトップです。ベース・レベルは階層レコードを表し、トップ・レベルはプロジェクトの最上位階層になります。財務構造に含まれるレベルが20を超える場合は、スキーマとETLのレベル数を拡大することで、すべてのレベルをサポートできます。
プロジェクト・タスク階層ディメンションを拡張するには:
レベルを拡張するには、ODIデザイナ・ナビゲータの「モデル」サブ・タブで、W_TASK_DHS表とW_TASK_DH表に必要になる新しいレベルごとに、すべてのチェンジ・キャプチャ列(TASK_NUMBER、WBS_LEVELおよびWBS_NUMBER)を追加する必要があります。
次のように、SDEおよびSILOSフォルダ内のインタフェースを拡張します。
ソースに応じて、E-Business SuiteまたはPeopleSoftの適切なSDEフォルダに移動します。
新しい列に適切なマッピングを指定することで、適切なメイン・インタフェースを編集して更新します。
例: SDE_ORA_TaskDimensionHierarchy.W_TASK_DHS or SDE_PSFT_TaskDimensionHierarchy.W_TASK_DHS。
SILOSフォルダを開き、ODIインタフェースSIL_Project_TaskDimensionHierarchyを編集して更新します。
「パッケージ」フォルダを開き、再生成するシナリオを右クリックして、SDE/SILOSシナリオを再生成します。
次に示すBIメタデータ・リポジトリ(RPDファイル)のオブジェクトも更新する必要があります。
物理レイヤーのW_TASK_DH表。
論理レイヤーの「ディメンション - タスク階層」論理表とタスク階層ディメンション。
プレゼンテーション領域内のすべてのタスク階層プレゼンテーション表。
デフォルトでは、E-Business SuiteのPA_PROJECT_CUSTOMERS表には「PRIMARY」関係コードしかありません。そのため、ODIフィルタに値を追加することになります。この値は、プロジェクト・ディメンションのソース抽出マッピングで、プロジェクト顧客を取得するために使用します。ユーザーは、関係値として「OVERRIDE CUSTOMER」などの追加の値を定義できます。この場合は、追加の値がすべて含まれるようにフィルタを編集する必要があります。
フィルタを編集する手順は次のとおりです。
ODIデザイナ・ナビゲータで、ODIリポジトリに接続します。
ソース・システムに適したフォルダ(たとえば、Oracle V11.5.10のSDE_ORA_11510_AdaptorやOracle V12のSDE_ORA_R12_Adaptor)を開きます。
SDE_ORA_ProjectDimensionフォルダを開き、SDE_ORA_Project.W_PROJECT_DS.LKP_PROJ_CUSTインタフェースを開いて、「クイック編集」タブをクリックします。
「フィルタ」タブを開いて、2番目のフィルタの式列を編集します。
既存のSQLを削除して、次のサンプルSQLを追加します。ここでは、値として「PRIMARY」および「OVERRIDE CUSTOMER」を使用することを想定しています。
構成内容に応じて値を変更してください。この値をいずれの関係からも独立させる場合は、PROJECT_RELATIONSHIP_CODE - UPPER(PA_PROJECT_CUSTOMERS.PROJECT_RELATIONSHIP_CODE (+)) IN ('PRIMARY' .'OVERRIDE CUSTOMER')のフィルタを削除します。
注意: この参照により複数の顧客が返される場合は、常に1つの行が返されるように、MAX関数をIDに適用する必要があります。
マッピングが有効になっていることを確認し、「OK」を押してインタフェースを保存します。
「パッケージ」フォルダを開き、再生成するシナリオを右クリックして、シナリオを再生成します。
すべてのプロジェクトは、オプションで様々なカテゴリに分類できます。これらのカテゴリ内で、プロジェクトはさらに様々な分類コードに分類できます。アプリケーション内でのこれらの分類カテゴリの定義方法に応じて、一部のカテゴリについては、1つのプロジェクトを複数の分類コードで分類できます。
プロジェクト分類表(W_PROJ_CLASSIFICATION_D)の単位は、プロジェクト、分類カテゴリおよび分類コードになります。このプロジェクトのファクトには、プロジェクト分類ディメンションと結合するための明示的な外部キーは存在しません。そのかわりに、プロジェクト外部キーで結合が行われます。プロジェクトに対する分類カテゴリの指定はオプションです。そのため、BIメタデータ・リポジトリ(RPDファイル)におけるファクトとプロジェクト分類ディメンションの間の論理結合は、右側外部結合として設定されています。これにより、プロジェクトが分類されていない場合でもレコードは失われません。
注意: 複数の分類カテゴリに1つの特定の分類コードが存在する可能性があります。このため、二重カウントを防ぐために、レポート属性の1つに分類コードがあるレポートでは、分類カテゴリを固定化することが重要です。1つのプロジェクトが同じ分類の下の複数の分類カテゴリに属している場合、そのプロジェクトのメトリック(原価や収益など)が二重にカウントされることになるからです。
資金は資金明細に基づいています。資金明細とは、プロジェクトやタスクに対して作成された割当てを表します。明細レベルの資金情報は資金明細ファクト(W_PROJ_ FUNDING_ LINE_F)内に保持されており、これはE-Business Suiteの請求モジュールにあるPA_PROJECT_FUNDINGS表に基づいています。また、要約資金表(PA_SUMMARY_PROJECT_FUNDINGS)からデータが抽出され、未基本編成金額、基本編成済金額、請求額、見越計上済収益などの追加のメトリックが取得されます。これらは資金明細ファクトでは提供されません。資金ヘッダー・ファクト(W_PROJ_FUNDING_HDR_F)で入手できる場合があります。ODI ETLジョブを実行する前に、E-Business Suiteで「PRC: プロジェクト要約金額のリフレッシュ」プロセスを実行して、この表を更新する必要があります。
注意: E-Business Suiteでは、資金通貨が、このファクトのドキュメント通貨になります。
「プロジェクト資金」領域で、次に示すドメインを使用します。
Project_Funding_Category: 資金割当てタイプの分類に使用します。Project_Funding_Level: このフラット・ファイルは、資金明細がタスクとプロジェクトのどちらに対するものなのかを示すために使用します。これは、どのデフォルトのメトリック定義でも使用されません。
注意: OLTPアプリケーションでは、資金ファクトの標準日付のGL記帳日は移入されません。したがって、Oracle Business Analytics Warehouseでは、E-Business SuiteのGL記帳日は資金割当て日付に基づいており、プロジェクトOUのGLカレンダを使用します。これにより、GLカレンダに対する相互機能分析が可能になります。たとえば、資金ファクトにGL記帳日が存在しない場合、会計年度による資金と請求の相互分析ができません。GLカレンダに基づく分析を実行しない顧客は、企業カレンダに基づく分析ができます。
GL記帳日(資金割当て日付)はこの表の標準日付で、グローバルな為替レートの計算にも使用します。
リソース区分により、リソースは個人、設備、材料品目および財務の要素に分類されます。
この特定方法をETLプロセス時に使用するには、FSMで変数RESOURCE_CLASS_TYPECATSUBを1に設定する必要があります。
ETLプロセスは、domainValues_Project_Cost_Resource_Class_TypeCatSub_psft.csvフラット・ファイルを使用して、リソース区分をプロジェクト原価レコードに割り当てます。
ソース・タイプ、カテゴリ、サブカテゴリの値の組合せに基づいてリソース区分を特定するには、次に示すフラット・ファイルを使用します。
file_project_cost_resource_class_typecatsub_config_psft.csv
このファイルを使用して、参照で使用する列(ソース・タイプ、カテゴリおよびサブカテゴリ)を指定します。
file_project_cost_resource_class_typecatsub_psft.csv
ETLプロセスではこのフラット・ファイルを使用して、リソース区分に使用するソース・タイプ、カテゴリ、サブカテゴリの値の組合せをすべて一覧表示します。file_Project_Cost_Resource_Class_TypeCatSub_config_psft.csvファイルで選択した列の値のみを入力します。フラット・ファイルにはすべての列を含める必要があり、選択されていない列には値を格納できません。
各行は末尾の値によって個人(L)なのか設備(A)なのかを識別する必要があります。
file_Project_Cost_Resource_Class_TypeCatSub_config_psft.csv (構成ファイル)を構成する手順は次のとおりです。
file_Project_Cost_Resource_Class_TypeCatSub_config_psft.csvファイルを編集します。
注意: このタスクの構成ファイル(複数の場合もあり)は、Oracle BI Applicationsインストールの次の場所にあります。 ソース独立ファイル: <Oracle Home for BI>\biapps\etl\data_files\src_files\。 ソース固有ファイル: <Oracle Home for BI>\biapps\etl\data_files\src_files\<source adaptor>。 システム管理者は、これらのファイルを別の場所にコピーして、この場所から読み取るためのODI接続を構成しているはずです。システム管理者に、これらのファイルの取得を依頼してください。構成が完了したら、システム管理者は、構成済ファイルをODIの読取り元にコピーする必要があります。 |
行IDが1の行を1行のみ入力します。リソース区分を割り当てられる値の組合せを表す各列にYを入力します。次の列が対象になります。
Row ID Source Type Category Subcategory
次の例では、ソース・タイプとカテゴリの組合せの使用方法を示します。
1,Y,Y,
この例では、値が一致したときに、file_project_cost_resource_class_typecatsub_psft.csvに格納されているソース・タイプとカテゴリの組合せが個人または設備に分類されます。
ファイルを保存して閉じます。
file_project_cost_resource_class_typecatsub_psft.csvファイル(データ・ファイル)を構成する手順は次のとおりです。
file_Project_Cost_Resource_Class_TypeCatSub_psft.csvを編集します。
注意: このタスクの構成ファイル(複数の場合もあり)は、Oracle BI Applicationsインストールの次の場所にあります。 ソース独立ファイル: <Oracle Home for BI>\biapps\etl\data_files\src_files\。 ソース固有ファイル: <Oracle Home for BI>\biapps\etl\data_files\src_files\<source adaptor>。 システム管理者は、これらのファイルを別の場所にコピーして、この場所から読み取るためのODI接続を構成しているはずです。システム管理者に、これらのファイルの取得を依頼してください。構成が完了したら、システム管理者は、構成済ファイルをODIの読取り元にコピーする必要があります。 |
個人または設備のリソース区分と見なされるリソース・タイプ、カテゴリおよびサブカテゴリの組合せを入力します。リソース区分が個人の場合は、末尾の値としてLを入力します。
リソース区分が設備の場合は、末尾の値としてAを入力します。形式は次のとおりです。
XXXXX,XXXXX,XXXXX,X
参照値の組合せをそれぞれ指定する必要があります。ワイルドカードはサポートされていません。
次に、ソース・タイプLABORまたはSUBCN(カテゴリなし)が人件費であり、ソース・タイプDIRCT (HRDWRカテゴリ)が設備費の場合の原価分類の例を示します。
LABOR,,,L SUBCN,,,L DIRCT,HRDWR,,A
注意:
このCSVファイルはfile_Project_Cost_Resource_Class_TypeCatSub_config_psft.csv構成ファイルと組み合せて使用します。この例では、この構成ファイルに値(1,Y,Y,)が格納されます。
参照値の組合せをそれぞれ指定する必要があります。参照では、構成ファイル内でYになっている列を使用します。
ファイルを保存して閉じます。
特定方法をETLプロセス時に使用するには、FSMで変数RESOURCE_CLASS_CHARTFIELDを1に設定する必要があります。
ETLプロセスは、file_project_cost_resource_class_chartfield_psft.csvフラット・ファイルを使用して、リソース区分をプロジェクト原価レコードに割り当てます。
チャートフィールドの値の組合せに基づいてリソース区分を割り当てるには、次のCSVを使用します。
file_Project_Cost_Resource_Class_ChartField_config_psft.csv
このフラット・ファイルを使用して、参照に使用されるチャートフィールド列を指定します。
file_project_cost_resource_class_chartfield_psft.csv
このフラット・ファイルを使用して、すべてのチャートフィールドの値の組合せをリソース区分に割り当てます。file_Project_Cost_Resource_Class_ChartField_config_psft.csvファイルで選択した列の値のみを入力します。
フラット・ファイルにはすべての列を含める必要があり、選択されていない列には値を格納できません。各行は末尾の値によって個人(L)なのか設備(A)なのかを識別する必要があります。
file_Project_Cost_Resource_Class_ChartField_config_psft.csv (構成ファイル)を構成する手順は次のとおりです。
file file_Project_Cost_Resource_Class_ChartField_config_psft.csvファイルを編集します。
注意: このタスクの構成ファイル(複数の場合もあり)は、Oracle BI Applicationsインストールの次の場所にあります。 ソース独立ファイル: <Oracle Home for BI>\biapps\etl\data_files\src_files\。 ソース固有ファイル: <Oracle Home for BI>\biapps\etl\data_files\src_files\<source adaptor>。 システム管理者は、これらのファイルを別の場所にコピーして、この場所から読み取るためのODI接続を構成しているはずです。システム管理者に、これらのファイルの取得を依頼してください。構成が完了したら、システム管理者は、構成済ファイルをODIの読取り元にコピーする必要があります。 |
行IDが1の行を1行のみ入力します。リソース区分を割り当てられる値の組合せを表す各列にYを入力します。次の列が対象になります。
Row ID Account Alternate Account Operating Unit Fund Dept ID Program Class Budget Project Business Unit Project Activity Source Type Category Subcategory Affiliate Affiliate 1 Affiliate 2 ChartField 1 ChartField 2 ChartField 3
次の例では、資金コードとプログラムの組合せの使用方法を示します。
,,,Y,,Y,,,,,,,,,,,,,,,
この例では、値が一致したときに、file_project_cost_resource_class_chartfield_psft.csvに格納されている資金コードとプログラム・コードの組合せが個人または設備に分類されます。
ファイルを保存して閉じます。
file_Project_Cost_Resource_Class_ChartField_psft.csv (データ・ファイル)を構成する手順は次のとおりです。
file file_project_cost_resource_class_chartfield_psft.csvファイルを編集します。
注意: このタスクの構成ファイル(複数の場合もあり)は、Oracle BI Applicationsインストールの次の場所にあります。 ソース独立ファイル: <Oracle Home for BI>\biapps\etl\data_files\src_files\。 ソース固有ファイル: <Oracle Home for BI>\biapps\etl\data_files\src_files\<source adaptor>。 システム管理者は、これらのファイルを別の場所にコピーして、この場所から読み取るためのODI接続を構成しているはずです。システム管理者に、これらのファイルの取得を依頼してください。構成が完了したら、システム管理者は、構成済ファイルをODIの読取り元にコピーする必要があります。 |
個人または設備のリソース区分と見なされるチャートフィールドの組合せを入力します。リソース区分が個人の場合は、末尾の値としてLを入力します。
リソース区分が設備の場合は、末尾の値としてAを入力します。形式は次のとおりです。
X,X,X,X,X,X,X,X,X,X,X,X,X,X,X,X,X,X,X,X,X,X
Xはチャートフィールドの組合せを表しています。
参照値の組合せをそれぞれ指定する必要があります。ワイルドカードはサポートされていません。
次に、資金コードFND01とプログラム・コードP200bが人件費である場合の原価分類方法の例を示します。
,,,FND01,, P2008,,,,,,,,,,,,,,,,L
注意:
このCSVファイルはfile_Project_Cost_Resource_Class_ChartField_config_psft.csv構成ファイルと組み合せて使用します。この例では、この構成ファイルに値(,,,Y,,Y,,,,,,,,,,,,,,,)が格納されます。
前述の例の場合、資金コードFND01およびプログラム・コードP2008のプロジェクト原価レコードが個人のリソース区分に分類されます。
参照値の組合せをそれぞれ指定する必要があります。構成ファイル内でYになっている列が参照の対象になります。
ファイルを保存して閉じます。
デフォルトでは、Oracle Supply Chain and Order Management Analyticsアプリケーションは、売上請求書データを抽出する際に、完了した売上請求書を抽出するように構成されています。Oracle 11iおよびOracle R12では、フラグを使用することで、売上請求書が完了しているかどうかが示されます。特に、完了した売上請求書とは、Oracle 11iおよびOracle R12でRA_CUSTOMER_TRX_ALL.COMPLETE_FLAG = Yとなっている請求書です。完了した売上請求書と同様に未完了の売上請求書を抽出するには、抽出のフィルタ文を削除します。
販売請求書の抽出フィルタを削除する手順は次のとおりです。
ODIで、SDE_ORA115<バージョン>_AdaptorまたはSDE_ORAR12_Adaptorフォルダを開きます。
SDE_ORA_SalesInvoiceLinesFact.W_SALES_INVOICE_LINE_FS.SQ_BCI_SALES_IVCLNS一時インタフェースを開いて、「クイック編集」タブに移動します。
「フィルタ」セクションを開いて、フィルタ「RA_CUSTOMER_TRX_ALL.COMPLETE_FLAG='Y'」を選択します。
赤色の×印が強調表示されます。強調表示されたフィルタが削除されます。
×印をクリックします。
変更内容をリポジトリに保存します。
シナリオを再生成します。
SDE_ORA_SalesInvoiceLinesFact_Primary.W_SALES_INVOICE_LINE_F_PE_SQ_BCI_SALES_IVCLNS一時インタフェースに対して、手順2から6を繰り返します。
Oracle Fusion Applicationsでは、フラグを使用することで、売上請求書が完了しているかどうかが示されます。特に、完了した売上請求書とは、SALESINVOICECUSTOMERTRXLINESPVO.TransactionHeaderCompleteFlag='Y'となっている請求書です。完了した売上請求書と同様に未完了の売上請求書を抽出するには、抽出のフィルタ文を削除します。
販売請求書の抽出フィルタを削除する手順は次のとおりです。
ODIで、SDE_FUSION_Adaptorを開きます。
SDE_FUSION_SalesInvoiceLinesFact.W_SALES_INVOICE_LINE_FS_SQ_TRANSACTIONLINEPVO一時インタフェースを開いて、「クイック編集」タブに移動します。
「フィルタ」セクションを開いて、フィルタ「SALESINVOICECUSTOMERTRXLINESPVO.TransactionHeaderCompleteFlag='Y'」を選択します。
赤色の×印が強調表示されます。強調表示されたフィルタが削除されます。
×印をクリックします。
変更内容をリポジトリに保存します。
シナリオを再生成します。
SDE_ORA_SalesInvoiceLinesFact_Primary.W_SALES_INVOICE_LINE_F_PE_SQ_BCI_SALES_IVCLNS一時インタフェースに対して、手順2から6を繰り返します。
目的
ヘッドカウントと常勤換算は、OLTPの設定に応じて数通りの方法で導出できます。それらの値が表PER_ASSIGNMENT_BUDGET_VALUES_Fに格納されていない場合は、アサイメント・レコードごとの値を計算するために、FastFormulaが実行されます。
一般に、FastFormulaの実行速度は低速であり、大規模なシステムでのパフォーマンス問題を回避するために、ワークフォース・バイパスFastFormulaという新しい機能が用意されています。この機能は、FastFormulaの柔軟性を維持しながらも費用がかかりません。
オプションまたは必須
このタスクは任意です。ただし、FastFormulaを実行するデフォルトのオプションでは速度が遅くなります。
適用対象
E-Business Suiteのすべてのバージョン。
詳細なタスクの説明
FastFormulaの実行をバイパスするには、パラメータHR_WRKFC_BYPASS_FFを構成します。これを行うと、デフォルトのFastFormula (TEMPLATE_HEADおよびTEMPLATE_FTE)と同じロジックを使用して、ヘッドカウントと常勤換算の値がETLによって計算されます(ただし、FastFormulaには、値がABV表に直接入力されるという優位性が残されています)。
テンプレートFormulaのロジックに不足がある場合は、そのロジックをETLで構成できますが、Formulaロジックを実装するSQL式の変更を伴う非常に複雑なタスクになります。ヘッドカウントと常勤換算を求めるテンプレートFormulaのSQL式は、ODI変数HR_WRKFC_BYPASS_HDC_CALCとHR_WRKFC_BYPASS_FTE_CALCに格納されます。これらの変数値は、生成されたロード計画で必要になるロジックでオーバーライドできます。
HR_WRKFC_BYPASS_HDC_CALC
FastFormula TEMPLATE_HEADのロジックを実装して、実表から直接計算します。このロジックの実装は、次のとおりです。
アサイメントがプライマリの場合、ヘッドカウントは1になります。
それ以外の場合、ヘッドカウントは0になります。
この変数式は次のとおりです。
(case when asg.primary_flag = 'Y' then 1 else 0 end)
この式をオーバーライドする場合は、インタフェースのすべてのデータ・セットで、すべての参照が一致するように注意する必要があります。処理される行の数を変更しない結合は追加できます。
HR_WRKFC_BYPASS_FTE_CALC
FastFormula TEMPLATE_FTEのロジックを実装して、実表から直接計算します。このロジックの実装は次のとおりです。
アサイメントがフルタイム雇用カテゴリを含む場合、常勤換算は1になります。
アサイメントがパートタイム雇用カテゴリを含む場合、アサイメントの勤務時間/アサイメントの見込み勤務時間に基づいて常勤換算が計算されます。
それ以外の場合、FTEは0になります。
アサイメントの見込み勤務時間は、優先順にポジション、組織、ビジネス・グループから取得されます。アサイメントの時間が見込み勤務時間とは異なる周期で与えられる場合は、なんらかの変換が必要になります。
この変数式は次のとおりです。
(case when asg.employment_category in ('FT','FR') then 1 when asg.employment_category in ('PT','PR') then round((case when NVL(pos.working_hours, NVL(org.org_information3, bus.org_information3)) = 0 then 0 else (decode(NVL(pos.frequency, NVL(org.org_information4, bus.org_information4)), 'H', 1, 'D', 8, 'W', 40, 'M', 169) * asg.normal_hours) / (decode(asg.frequency, 'HO', 1, 'D', 8, 'W', 40, 'M', 169) * NVL(pos.working_hours, NVL(org.org_information3, bus.org_information3))) end), 2) else 0 end)
この式をオーバーライドする場合は、インタフェースのすべてのデータ・セットで、すべての参照が一致するように注意する必要があります。処理される行の数を変更しない結合は追加できます。
依存関係
依存関係はありません。
ここでは、Fusionユーザーに向けて、プロジェクト請求書明細を無効にする方法について説明します。デフォルトでは、請求メトリックは、請求書明細ファクトW_PROJ_INVOICE_LINE_Fと、請求書明細配分ファクトW_PROJ_INVOICE_DIST_Fにマップされます。Fusionデータベースが唯一のデータ・ソースになるユーザーの場合、請求書明細ファクトは廃止された表であり、無効にする必要があります。ただし、これを無効にする前に、明細ファクトのみで定義されるメトリックを削除する必要があります。次にリストするメトリックは保持に関連するものです。これは、現行のFusionアプリケーションではサポートされていません。
プロジェクト請求書明細ファクトを無効にするには、次の操作を実行します。
第B.2.49.1項「不要なメトリックの削除方法」で説明するように、不要なメトリックを削除します。
第B.2.49.2項「請求書明細ファクトの無効化方法」で説明するように、請求書明細ファクトを無効にします。
注意: このプロセスを開始する前に、BIメタデータ・リポジトリ(RPDファイル)のバックアップを作成することをお薦めします。
次に示すように、論理表ソースを無効にする前に、これらの論理表ソースを使用して定義されるメトリックをマップ解除/削除して、RPDの一貫性を保つ必要があります。
Oracle BI EE管理ツールで、BIメタデータ・リポジトリ(例: OracleBIAnalyticsApps.rpd)を編集します。
ビジネス・モデルとマッピング・レイヤーで、「ファクト - プロジェクト請求」に移動します。
次のスクリーンショットに示すように、後出のリストに示したメトリックを削除します。
削除する必要がある71のメトリックのリスト
1. Fact - Project Billing.--------------- Retention Amount --------------- 2. Fact - Project Billing.Current Withheld Amount 3. Fact - Project Billing.Current Withheld Amount - ITD 4. Fact - Project Billing.Current Withheld Amount - MTD 5. Fact - Project Billing.Current Withheld Amount - QTD 6. Fact - Project Billing.Current Withheld Amount - YTD 7. Fact - Project Billing.---------- Retention Billed ------------- 8. Fact - Project Billing.Retention Billed 9. Fact - Project Billing.Retention Billed - ITD 10. Fact - Project Billing.Retention Billed - MTD 11. Fact - Project Billing.Retention Billed - QTD 12. Fact - Project Billing.Retention Billed - YTD 13. Fact - Project Billing.----------- Retention Withheld ------------- 14. Fact - Project Billing.Total Retained Amount 15. Fact - Project Billing.Total Retained Amount - ITD 16. Fact - Project Billing.Total Retained Amount - MTD 17. Fact - Project Billing.Total Retained Amount - QTD 18. Fact - Project Billing.Total Retained Amount - YTD 19. Fact - Project Billing.----------- Retention Write-off ----------- 20. Fact - Project Billing.Retention Write-off 21. Fact - Project Billing.Retention Write-off - ITD 22. Fact - Project Billing.Retention Write-off - MTD 23. Fact - Project Billing.Retention Write-off - QTD 24. Fact - Project Billing.Retention Write-off - YTD 25. Fact - Project Billing.-------------- Unearned Revenue ---------------- 26. Fact - Project Billing.Unearned Revenue 27. Fact - Project Billing.Unearned Revenue - ITD 28. Fact - Project Billing.Unearned Revenue - MTD 29. Fact - Project Billing.Unearned Revenue - QTD 30. Fact - Project Billing.Unearned Revenue - YTD 31. Fact - Project Billing.-------------- Unbilled Receivables ------------ 32. Fact - Project Billing.Unbilled Receivables 33. Fact - Project Billing.Unbilled Receivables - ITD 34. Fact - Project Billing.Unbilled Receivables - MTD 35. Fact - Project Billing.Unbilled Receivables - QTD 36. Fact - Project Billing.Unbilled Receivables - YTD 37. Fact - Project Billing.# of Unapproved Invoices 38. Fact - Project Billing.Retention Amount - MTD - Enterprise Calendar 39. Fact - Project Billing.Retention Amount - QTD - Enterprise Calendar 40. Fact - Project Billing.Retention Amount - YTD - Enterprise Calendar 41. Fact - Project Billing.Retention Billed - MTD - Enterprise Calendar 42. Fact - Project Billing.Retention Billed - QTD - Enterprise Calendar 43. Fact - Project Billing.Retention Billed - YTD - Enterprise Calendar 44. Fact - Project Billing.Retention Withheld - MTD - Enterprise Calendar 45. Fact - Project Billing.Retention Withheld - QTD - Enterprise Calendar 46. Fact - Project Billing.Retention Withheld - YTD - Enterprise Calendar 47. Fact - Project Billing.Retention Write-off - MTD - Enterprise Calendar 48. Fact - Project Billing.Retention Write-off - QTD - Enterprise Calendar 49. Fact - Project Billing.Retention Write-off - YTD - Enterprise Calendar 50. Fact - Project Billing.Unearned Revenue - MTD - Enterprise Calendar 51. Fact - Project Billing.Unearned Revenue - QTD - Enterprise Calendar 52. Fact - Project Billing.Unearned Revenue - YTD - Enterprise Calendar 53. Fact - Project Billing.Unbilled Receivables - MTD - Enterprise Calendar 54. Fact - Project Billing.Unbilled Receivables - QTD - Enterprise Calendar 55. Fact - Project Billing.Unbilled Receivables - YTD - Enterprise Calendar 56. Fact - Project Billing.Internal UBR UER Metric (Invoice Fact) 57. Fact - Project Billing.Internal Unearned Revenue - ITD 58. Fact - Project Billing.Internal Unbilled Receivable - ITD 59. Fact - Project Revenue.------------- Unearned Revenue -------------- 60. Fact - Project Revenue.Unearned Revenue 61. Fact - Project Revenue.Unearned Revenue - ITD 62. Fact - Project Revenue.Unearned Revenue - QTD 63. Fact - Project Revenue.Unearned Revenue - MTD 64. Fact - Project Revenue.Unearned Revenue - YTD 65. Fact - Project Revenue.------------ Unbilled Receivable ------------- 66. Fact - Project Revenue.Unbilled Receivable 67. Fact - Project Revenue.Unbilled Receivable - ITD 68. Fact - Project Revenue.Unbilled Receivable - MTD 69. Fact - Project Revenue.Unbilled Receivable - QTD 70. Fact - Project Revenue.Unbilled Receivable - YTD 71. Fact - Project Revenue.Internal UBR UER Metric (Invoice Fact)
Oracle BI EE管理ツールで、BIメタデータ・リポジトリ(例: OracleBIAnalyticsApps.rpd)を編集します。
ビジネス・モデルとマッピング・レイヤーで、「ファクト - プロジェクト請求」に移動します。
「Fact_W_PROJ_INVOICE_LINE_F_Invoice_Line」論理表ソースを選択し、右クリックして「編集」を選択します。
「一般」タブを表示し、「無効」チェック・ボックスを選択して「OK」をクリックします。
「Fact_W_PROJ_INVOICE_LINE_F_Invoice_Line_ITD」論理表ソースを選択し、右クリックして「編集」を選択します。
「一般」タブを表示し、「無効」チェック・ボックスを選択して「OK」をクリックします。
変更内容を保存します。
整合性チェックを実行してエラーがないことを確認し、RPDファイルを保存して、Oracle BI Enterprise Editionのキャッシュをクリアします。
オフライン・モードで変更を行った場合は、Oracle BI ServerとOracle BI Presentation Servicesを再起動します。
PeopleSoftのプロジェクト原価計算領域ソースからの完了見積(ETC。分析タイプの値'ETC'と混同しないように)原価および収益データは、プロジェクト予測に抽出されます。ユーザーは、PROJ_FORECAST_FILTERの「完了見積分析タイプ」についての分析タイプをFSMで構成することが必要になる場合があります。
FSMで、「データ・ロード・パラメータの管理」セクションに移動し、「ソース」にPeopleSoft 9.0または9.1 FINSCM、「オファリング」に「Oracle Project Analytics」、「機能領域」に「プロジェクト管理および原価計算」のフィルタを適用します。
変数PROJ_FORECAST_FILTERには、プロジェクト・コスト計算領域の原価メトリックと収益メトリックに対する分析タイプを設定します。設定する分析タイプは、引用符で囲みます(たとえば、'ETC'や'ETB')。
分析タイプ、ソース・タイプ、カテゴリ、サブカテゴリの値の組合せに基づくプロジェクト予測の原価および収益ETCメトリックの特定
分析タイプ(必須)、ソース・タイプ、カテゴリ、サブカテゴリの値の組合せに基づいて、プロジェクト予測ETC原価およびETC収益を特定するには、次のフラット・ファイルを構成する必要があります。
file_Project_Forecast_config_psft.csvの構成
ETLプロセスではこのフラット・ファイルを使用して、参照に使用される列(分析タイプ、ソース・タイプ、カテゴリおよびサブカテゴリ)を指定します。Oracle BI Applications構成マネージャで指定したパラメータにより、この参照が実装に対して実行されるかどうかが決まります。
例(1) 分析タイプにのみ適用するフィルタを構成する場合は、次のようになります。
表B-22 file_Project_Forecast_config_psft.csvを構成する場合のサンプル・データ
ROWID | ANALYSIS_TYPE | RESOURCE_TYPE | RESOURCE_CAT | RESOURCE_SUB_CAT | RETURN_VALUE |
---|---|---|---|---|---|
1 |
1 |
例(2) RESOURCE_CATおよびRESOURCE TYPEに適用するフィルタを構成する場合は、次のようになります(ANALYSIS_TYPEは必須)。
file_Project_Forecast_psft.csvの構成
ETLプロセスではこのフラット・ファイルを使用して、プロジェクト予測ETC原価および収益に使用する分析タイプ、ソース・タイプ、カテゴリ、サブカテゴリの値の組合せをすべて一覧表示します。前述の構成(1)の例:
表B-24 file_Project_Forecast_config_psft.csvを構成する場合のサンプル・データ
ANALYSIS_TYPE | RESOURCE_TYPE | RESOURCE_CAT | RESOURCE_SUB_CAT | RETURN_VALUE |
---|---|---|---|---|
ETC |
C |
|||
ETB |
R |
前述の構成(2)の例:
ストアド・プロシージャは、データベースに対して特定のタスクを実行するSQL文のグループです。たとえば、ストアド・プロシージャを利用してデータベースのパフォーマンスを高めることができます。ストアド・プロシージャをデプロイするには、Oracle BI Applicationsのインストールからストアド・プロシージャ・ファイルをコピーし、Oracle Business Analytics Warehouseにデプロイします。
注意: ワークフローを実行する前にこれらのプロシージャをデータベースでコンパイルしておかないと、一部のセッションが失敗する場合があります。
ストアド・プロシージャをデプロイする手順は次のとおりです。
<ORACLE_BI_HOME>/biapps/etl/etl_stored_procs/<データベース・テクノロジ・フォルダ>フォルダに移動します。
たとえば、Oracleデータベースの場合は<ORACLE_BI_HOME>/biapps/etl/etl_stored_procs/oracleに移動します。
SQLスクリプト'FIND_AUDIT_VALUES.sql'を実行して、ストアド・プロシージャをOracle Business Analytics Warehouseに配信します。
Oracle Business Analytics Warehouseスキーマでストアド・プロシージャをコンパイルします。
通常、スキーマには、%PREFIX%_DWというような名前が付けられています。たとえば、BIAPPS_DWです。
注意: ストアド・プロシージャをデプロイする際に問題が発生した場合は、データベースのリファレンス・ガイドを参照するか、データベース管理者に連絡してください。
在庫月次残高表の構成について
在庫月次残高(W_INVENTORY_DAILY_BALANCE_F)集計表および在庫ロット月次残高(W_INV_LOT_MONTHLY_BAL_F)集計表を構成するには、集計レベル、集計更新期間および在庫残高表レコードの保有期間を考慮する必要があります。在庫月次残高表を構成するには、次の3つのパラメータを構成する必要があります。
GRAIN
GRAINパラメータは、最新の残高を維持する期間を制御します。このパラメータのデフォルト値はMONTHです。GRAINパラメータには、次の値を指定できます。
DAY
WEEK
MONTH
QUARTER
YEAR
KEEP_PERIOD
KEEP_PERIODパラメータは、NUM_OF_PERIODと併用することで、在庫日次残高表にデータを維持しておく価値のある期間数を制御します。たとえば、KEEP_PERIODがCAL_MONTHで、NUM_OF_PERIODが3の場合は、最近3か月間のデータが維持されます。このパラメータのデフォルト値は、CAL_MONTHです。KEEP_PERIODパラメータには、次の値を指定できます。
CAL_DAY
CAL_WEEK
CAL_MONTH
CAL_QTR
CAL_YEAR
NUM_OF_PERIOD
NUM_OF_PERIODパラメータのデフォルト値は3です。NUM_OF_PERIODパラメータの値には、1、2、3などの正の整数を指定します。
注意: 3か月以上前の周期の在庫回転データが必要な場合は、KEEP_PERIODおよびNUM_OF_PERIODのパラメータ値を変更する必要があります。たとえば、過去3年間のデータが必要な場合は、KEEP_PERIODをCAL_YEARに、NUM_OF_PERIODを3に設定します。
製品トランザクション集計表の構成について
製品トランザクション集計表(W_PRODUCT_XACT_A)を構成するには、初期ETLを実行してから増分ETLを実行する、2つの集計シナリオが必要です。
初期ETLの実行では、集計レベルと、製品トランザクション・ファクト表に維持する履歴の期間を構成する必要があります。
また、GRAINパラメータを使用して、集計単位も構成する必要があります。
増分ETLの実行では、次のパラメータを使用して、集計レベル、集計更新期間および製品トランザクション・ファクト表に維持する履歴の期間を構成する必要があります。
GRAIN
GRAINパラメータは、集計レベルを指定します。指定できる値は、DAY、WEEK、MONTH(デフォルト値)、QUARTER、YEARです。
REFRESH_PERIOD
REFRESH_PERIODパラメータは、NUM_OF_PERIODと併用して、トランザクション表から集計表にレコードを更新する期間を指定します。指定できる値は、DAY、WEEK、MONTH(デフォルト値)、QUARTER、YEARです。
NUM_OF_PERIOD
NUM_OF_PERIODパラメータは、REFRESH_METHODと併用して、トランザクション表から集計表にレコードを更新する期間数を指定します。指定できる値は、1、2、3 (デフォルト値)などの正の整数です。
初期ETLを実行した後で、増分ETLを実行して製品トランザクション集計表をロードするには、まず、製品トランザクション集計表を次のように構成しておく必要があります。
製品トランザクション集計表を構成するには:
3つのパラメータ、REFRESH_PERIOD = 'MONTH'、GRAIN = 'MONTH'、およびNUM_OF_PERIOD = 3を構成する必要があります。
初期ETLを実行できるように製品トランザクション集計表を構成するには:
製品トランザクション・ファクト表(W_PRODUCT_XACT_F)内のレコードを取得し、そのレコードを特定の単位レベルで製品トランザクション集計表(W_PRODUCT_XACT_A)に集計します。
たとえば、GRAINがMONTHに設定されている場合、W_PRODUCT_XACT_Fファクト表のレコードが取得され、月レベルでW_PRODUCT_XACT_A表に集計されます。
この手順は、PLP_ProductTransactionAggregateシナリオを実行することで実装されます。
増分ETLを実行できるように製品トランザクション集計表を構成するには:
製品トランザクション集計表(W_PRODUCT_XACT_A)から特定期間の更新済レコードを削除します。
削除する期間はREFRESH_PERIODおよびNUM_OF_PERIODパラメータで指定します。
たとえば、REFRESH_PERIODがMONTH、NUM_OF_PERIODが1、日付が15.05.05の場合、W_PRODUCT_XACT_A表の4月と当月(5月)のすべてのレコードが削除されます。
この手順は、PLP_ProductTransactionAggregate_Updateシナリオを実行することで実装されます。
製品トランザクションのファクト表(W_PRODUCT_XACT_F)内のレコードを取得し、それらのレコードを特定の単位レベルでW_PRODUCT_XACT_A表に集計します。
たとえば、GRAINがMONTHに設定されている場合、W_PRODUCT_XACT_Fファクト表のレコードが取得され、月レベルでW_PRODUCT_XACT_A表に集計されます。
この手順は、PLP_ProductTransactionAggregateシナリオを実行することで実装されます。
SIL_BOMItemFactマッピングに含まれるCOMPUTE_BOUNDSというストアド・プロシージャによって、展開後のBOMツリー構造が探索され、左範囲と右範囲が計算されます。デフォルトでは、COMPUTE_BOUNDSストアド・プロシージャはオフに設定されています。このプロシージャをオンにする場合は、第B.2.53.1項「左範囲および右範囲の計算オプションの構成方法」を参照してください。
このプロシージャは、E-Business SuiteおよびOracle Fusionソース・システムに適用されます。
注意: このプロシージャはJD Edwards EnterpriseOneには必要ありません(JD Edwards EnterpriseOneでは、UBE (R30461)によって左範囲および右範囲が自動的に計算されます)。
左範囲および右範囲の計算を使用すると、特定のレポート要件を効率よく処理できます。たとえば、完成品のサブ組立品に含まれるコンポーネントを検索できます。左範囲と右範囲がそれぞれのBOMノードのW_BOM_ITEM_F表に格納され、W_BOM_ITEM_F表内の1データ行になります。COMPUTE_BOUNDSストアド・プロシージャによって展開後のBOMツリー構造が探索され、左範囲および右範囲が計算されます。デフォルトでは、COMPUTE_BOUNDSストアド・プロシージャはオフに設定されています。また、W_BOM_ITEM_F.LEFT_BOUNDS列とW_BOM_ITEM_F.RIGHT_BOUNDS列は空になっています。
次の図は、各ノードに左範囲と右範囲の値が示された、サンプルのBOM構造です。ノードBに属するすべてのコンポーネントを検索するには、上位製品キーの値がA、左範囲の値が2より大きく、右範囲の値が17未満に設定されているコンポーネントを選択します。
次のプロセスを使用すると、左範囲および右範囲の計算をオンにして、W_BOM_ITEM_F.LEFT_BOUNDS列およびW_BOM_ITEM_F.RIGHT_BOUNDS列に移入できます。
左範囲および右範囲の計算オプションを構成するには:
ODIで、「SILOS」→「SIL_BOMItemFact」→「パッケージ」の順に移動して、SIL_BOMItemFactパッケージを編集します。
「ダイアグラム」タブを表示します。
「成功時の次のステップ」ツール(つまり、緑色の矢印とOKのボタン)を選択します。
IS_INCREMENTALのリフレッシュ・アイコンを「COMPUTE_BOUNDSの実行」アイコンにつなぐ線を引きます。
「COMPUTE_BOUNDSの実行」アイコンを「SIL_BOMItemFactの実行」アイコンにつなぐ線を引きます。
パッケージを保存します。
関連するシナリオを生成します。
注意: COMPUTE_BOUNDS ODIプロシージャの最初のステップにより、Oracle Business Analytics Warehouse内での関連プロシージャの作成または置換が試行されます。このシナリオを実行しているユーザー・アカウントには、このステップを正常に進めるための適切な権限が付与されている必要があります。別の方法として、ストアド・プロシージャを手動でデプロイすると、ODIプロシージャの最初のステップを無効にできるため、そのような権限を付与することを回避できます。
目的
ここでは、ODI変数HR_ABS_WORKING_HOURS_PER_DAYの構成について説明します。この変数は、日数ごとの時間数を計算するために使用されます。
オプションまたは必須
Oracle BI Applicationsでは、変数HR_ABS_WORKING_HOURS_PER_DAYにSQL式を使用します(デフォルト時)。このSQL式は、ソースHR関数hri_bpl_utilization.convert_days_to_hours()から呼び出されるFastFormulaのTEMPLATE_BIS_DAYS_TO_HOURSに基づいています。テンプレートFormulaを使用する場合、この構成はオプションになります。
ただし、FastFormulaがソースでカスタマイズされている場合は、HR_ABS_WORKING_HOURS_PER_DAY変数に使用するSQL式の再確認と変更が必須になります。
適用対象
E-Business Suite 11.1.10およびR12.x.xのAbsencesモジュールに対して実行されるすべての抽出に適用されます。
詳細なタスクの説明
FastFormulaのTEMPLATE_BIS_DAYS_TO_HOURSで使用されるロジックを確認します。このFastFormulaがカスタマイズされていない場合は、この変数のデフォルト値で問題なく動作します。それ以外の場合は、この変数値を適切なSQL式に変更する必要があります。
FastFormulaテキストから、(a) デフォルトの日単位の時間数、(b)週単位の勤務日数および(c)月単位の勤務日数を特定し、これらの値をODI変数のHR_ABS_DFLT_HOURS_PER_DAY、HR_ABS_WORKING_DAYS_PER_WEEKおよびHR_ABS_WORKING_DAYS_PER_MONTHにそれぞれ割り当てます。
FastFormulaテキストの残りの部分を確認して、日単位の勤務時間の計算に使用されるFormulaを特定します。
これらの情報を基にして、FastFormulaロジックに厳密に適合するSQL式を作成します。具体的な考え方については、掲載されているデフォルトのSQL式を参照してください。
この変数HR_ABS_WORKING_HOURS_PER_DAYは、列UTL_HOURS_IN_DAYに対するインタフェースSDE_ORA_AbsenceEventDimension.W_ABSENCE_EVENT_DS_SQ_PER_ABSENCE_ATTENDANCES_TMPで使用されます。
HR_ABS_WORKING_HOURS_PER_DAYで使用されているデフォルトのSQL式は、次のとおりです。
round(case when tab.asg_freq is not null and tab.asg_hours is not null then (case when tab.asg_freq = 'W' then tab.asg_hours/tab.working_days_per_week when tab.asg_freq ='M' then tab.asg_hours/working_days_per_month when tab.asg_freq = 'D' then asg_hours else 0 end) else(case when tab.full_freq is not null and tab.full_hours is not null then(case when tab.full_freq ='W' then tab.full_hours/tab.working_days_per_week when tab.full_freq='M' then tab.full_hours/working_days_per_month when tab.full_freq ='D' then full_hours else 0 end ) else dflt_hours_per_day end) end,2)
依存関係
なし。
目的
このパラメータは、バランスを選択的にウェアハウスに抽出するために使用されます。抽出するバランスを制限することで、ETLとレポートのパフォーマンスが向上します。また、ウェアハウスに含めるバランスが特定のタイプにのみ限定されます。実行バランスのみを抽出する必要があります。これは、その他のタイプのバランスは完全な加算性を備えていない可能性があるためです(たとえば、年間累計バランスを加算して1つにまとめることはできません)。
E-Business Suite PayrollとPeopleSoft North American Payrollは、どちらも、支払実行バランス詳細ファクト表で追跡することになる、バランス(E-Business Suite Payrollの場合)と支給/控除/税(PeopleSoft North American Payrollの場合)を選択するメカニズムを用意する必要があります。
メジャーの加算性を確保するために、実行バランスのみがサポートされます。給与計算実行ごとに、処理された実際の実行バランスが格納されます。これらをコンテキスト別に分割しないことで、上位レベルのバランスを形成するために、実行バランスの時間を通じた組合せが可能になります(たとえば、PTD、MTD、YTDなど)。
オプションまたは必須
E-Business Suite PayrollおよびPeopleSoft North American Payrollの場合はオプションですが、強く推奨されています。
適用対象
E-Business SuiteおよびPeopleSoft North American Payroll。
依存関係
手順
OLTPシステムに、レポート用に抽出する必要のあるバランスのリストを含むカスタム表を作成します。SDE ETLは、これらのバランスのみをソース・システムから抽出するようになります。次に例を示します。
CREATE TABLE OBIA_PAY_BAL_FILTER (BALANCE_ID VARCHAR2 (50));
パラメータHR_PAYROLL_FILTER_CLAUSEをODIに追加します。このパラメータには、ユーザーがソース・システムに作成したカスタム表からのSELECT文を含めます。
SELECT <COLUMN_NAME> FROM <SCHEMA>.<TABLE_NAME>
次に例を示します。SELECT BALANCE_ID FROM EMDBO.OBIA_PAY_BAL_FILTER
ユーザーがソース・システムにカスタム表を作成しないと、SDE抽出はすべてのバランスを取得するようになります。これがパフォーマンスの問題につながることがあります。
すべてのバランスを抽出する必要がある場合は、このパラメータを1=1に設定する必要があります(これは、インストール時のデフォルトです)。
この値を変数HR_PAYROLL_FILTER_CLAUSEに設定するには、構成マネージャを使用します。
E-Business Suite PayrollまたはPeopleSoft North American Payrollの場合は、次の設定を使用します。
バランスにフィルタを適用するには、SELECT<COLUMN_NAME> FROM <TABLE_NAME>を使用します。
すべてのバランスを抽出するには、1=1を使用します。
ODIのHR_PAYROLL_FILTER_CLAUSEパラメータ
このパラメータを設定して、Oracle BI Applications構成マネージャからの値をリフレッシュします。
構成マネージャのHR_PAYROLL_FILTER_CLAUSEパラメータ
目的
ここでは、ODI変数HR_ACCRUAL_EXTRACT_MTHS_INCRの構成について説明します。この変数は、増分モードでの実行時にHR有給休暇モジュールのデータを抽出するために使用します。
オプションまたは必須
デフォルトでは、Oracle BI ApplicationsはHR_ACCRUAL_EXTRACT_MTHS_INCR変数の値を3か月に設定します。この変数により、ETLが実行されると、最近3か月のデータがウェアハウスでリフレッシュされます。この値で問題がなければ、変更の必要はありません。
ただし、最近3か月のデータとは異なる増分データのコレクションを保持することにした場合は、必須の手順として、この変数の値を必要に応じて設定しなければなりません。
適用対象
E-Business Suite 11.1.10およびR12.x.xのAbsencesモジュールに対して実行されるすべての抽出に適用されます。
詳細なタスクの説明
有給休暇のメトリックは、実行時に計算され、ソースから抽出されます。E-Business Suite有給休暇のデータが格納されているソース表はありません。
デフォルトでは、E-Business Suiteからの抽出をOracle BI Applicationsで実行すると、現在の日付から3か月過去までの増分有給休暇データが抽出されます。そのために、増分抽出のフィルタ条件にHR_ACCRUAL_EXTRACT_MTHS_INCRが使用されます。
注意: 設定する値を大きくすると、増分抽出のパフォーマンスへの影響も大きくなります。この値は、増分問合せのパフォーマンスに応じて、慎重に選択する必要があります。
依存関係
なし。
Oracle Business Analytics Warehouseでは、国はOracle Business Analytics Warehouseの1つのドメインになります。このドメインのドメイン・コードは'W_COUNTRY'に設定されています。Oracle BI Applications構成マネージャで、ドメイン・コードとしてISO alpha-2文字コードを格納します。
ISO標準により、新しい国コードが発表されています(たとえば、南スーダン・国コード'SS'が、2011年8月11日に発表されました)。新しい国コードがOLTPに追加されると、それに応じて、次に示す変更をOracle BI Applicationsで実行する必要があります。
Oracle BI Applications構成マネージャで、新しい国コードを新しいドメイン・コードとしてドメイン'W_COUNTRY'に追加します。
Oracle BI Applications構成マネージャで、新しい国コードを新しいドメイン・コードとして、特定の製品ライン・バージョンのドメイン'COUNTRY'に追加します。
Oracle BI Applications構成マネージャで、ソース・ドメイン'COUNTRY'から、新しい国コードのターゲット・ドメイン'W_COUNTRY'へのドメイン・マッピングを作成します。
Oracle Business Analytics Warehouseの表W_GEO_COUNTRY_Dを再ロードします。
CSVファイルfile_GeoCountry_ISO_Country_Codes_FUSIONがソースになります。このファイルには、新しい国コードが移入されている必要があります。
目的
このドキュメントでは、E-Business Suite有給休暇抽出インタフェースで使用されるODI変数の構成について説明します。
a) HR_ACCRUAL_PERIOD_GRANT_AMT
b) HR_ACCRUAL_BALANCE_AMT
c) HR_ACCRUAL_CARRYOVER_AMT
d) HR_ACCRUAL_ABSENCE_AMT
e) HR_ACCRUAL_OTHER_AMT
オプションまたは必須
デフォルトでは、Oracle BI Applicationsは、前述の5つの変数にSQL式を使用してテンプレートFastFormulaを実行します。このSQL式は、次に示す有給休暇抽出で使用される各種メトリックの関数を呼び出すものです。
OBIA_ACCRUAL_FUNCTIONS.GET_NET_ACCRUAL() - 変数(a)および変数(b)で使用します。
OBIA_ACCRUAL_FUNCTIONS.GET_CARRY_OVER() - 変数(c)で使用します。
OBIA_ACCRUAL_FUNCTIONS.GET_ABSENCE() - 変数(d)で使用します。
OBIA_ACCRUAL_FUNCTIONS.GET_OTHER_NET_CONTRIBUTION()- 変数(e)で使用します。
ソースの有給休暇FastFormulaがカスタマイズされている場合、この手順は必須になります。
適用対象
E-Business Suite 11.1.10およびR12.x.xの有給休暇モジュールに対して実行されるすべての抽出に適用されます。
詳細なタスクの説明
ODI変数HR_ACCRUAL_PERIOD_GRANT_AMTの構成
この変数により、特定の有給休暇付与プランおよび有給休暇付与期間について、従業員に与えられた期間有給休暇を取得する関数が呼び出されます。
デフォルト値を次に示します。
OBIA_ACCRUAL_FUNCTIONS.GET_NET_ACCRUAL(PER_ALL_ASSIGNMENTS_F.ASSIGNMENT_ID,PER_ALL_ASSIGNMENTS_F.PAYROLL_ID,PER_ALL_ASSIGNMENTS_F.BUSINESS_GROUP_ID,-1,PER_TIME_PERIODS.END_DATE,PAY_ACCRUAL_PLANS.ACCRUAL_PLAN_ID,PER_TIME_PERIODS.START_DATE,NULL)
カスタマイズされた関数を呼び出したときに、従業員が計上期間ごとに1.5日の期間休暇付与を受け取ると、関数呼び出しから次に示す例外が返されます。
テンプレートFastFormulaがカスタマイズされている場合は、ODI変数値の内部の関数呼出しも適切に変更されている必要があります。
計上期間の例については、その他の情報に関する項を参照してください。
ODI変数HR_ACCRUAL_BALANCE_AMTの構成
この変数により、特定の有給休暇付与プランおよび有給休暇付与期間について、アサイメントのバランス有給休暇を取得する関数が呼び出されます。
デフォルト値は次のとおりです。
OBIA_ACCRUAL_FUNCTIONS.GET_NET_ACCRUAL(PER_ALL_ASSIGNMENTS_F.ASSIGNMENT_ID,PER_ALL_ASSIGNMENTS_F.PAYROLL_ID,PER_ALL_ASSIGNMENTS_F.BUSINESS_GROUP_ID,-1,PER_TIME_PERIODS.END_DATE,PAY_ACCRUAL_PLANS.ACCRUAL_PLAN_ID)
カスタマイズされた関数を呼び出したときに、従業員が1.5日の期間休暇付与を受け取り、休暇、繰越、その他の有給休暇残余日数がないと、関数呼出しから次に示す例外が返されます。
テンプレートFastFormulaがカスタマイズされている場合は、ODI変数値の内部の関数呼出しも適切に変更されている必要があります。
ODI変数HR_ACCRUAL_CARRYOVER_AMTの構成
この変数により、新しい有給休暇期間が始まったときに、繰越日数を取得する関数が呼び出されます。
デフォルト値は次のとおりです。
OBIA_ACCRUAL_FUNCTIONS.GET_CARRY_OVER(PER_ALL_ASSIGNMENTS_F.ASSIGNMENT_ID,PAY_ACCRUAL_PLANS.ACCRUAL_PLAN_ID,PER_TIME_PERIODS.END_DATE,PER_TIME_PERIODS.START_DATE )
カスタマイズされた関数を呼び出したときに、次の例に示す例外がその関数から返されます。
テンプレートFastFormulaがカスタマイズされている場合は、ODI変数値の内部の関数呼出しも適切に変更されている必要があります。有給休暇期間の例については、その他の情報に関する項を参照してください。
ODI変数HR_ACCRUAL_ABSENCE_AMTの構成
この変数により、特定の計上期間のうちの休暇欠勤数を取得する関数が呼び出されます。
デフォルト値は次のとおりです。
OBIA_ACCRUAL_FUNCTIONS.GET_ABSENCE(PER_ALL_ASSIGNMENTS_F.ASSIGNMENT_ID,PAY_ACCRUAL_PLANS.ACCRUAL_PLAN_ID,PER_TIME_PERIODS.END_DATE,PER_TIME_PERIODS.START_DATE )
カスタマイズされた関数を呼び出したときに、次の例に示す例外がその関数から返されます。
テンプレートFastFormulaがカスタマイズされている場合は、ODI変数値の内部の関数呼出しも適切に変更されている必要があります。
ODI変数HR_ACCRUAL_OTHER_AMTの構成
この変数により、特定の計上期間のうちのその他の有給休暇残余日数を取得する関数が呼び出されます。
デフォルト値は次のとおりです。
OBIA_ACCRUAL_FUNCTIONS.GET_OTHER_NET_CONTRIBUTION(PER_ALL_ASSIGNMENTS_F.ASSIGNMENT_ID,PAY_ACCRUAL_PLANS.ACCRUAL_PLAN_ID,PER_TIME_PERIODS.END_DATE,PER_TIME_PERIODS.START_DATE )
カスタマイズされた関数を呼び出したときに、次の例に示す例外がその関数から返されます。
テンプレートFastFormulaがカスタマイズされている場合は、ODI変数値の内部の関数呼出しも適切に変更されている必要があります。
依存関係
なし。
追加情報/注意
- 休暇欠勤は常に有給休暇バランスから差し引かれます。
- 繰越は常に有給休暇バランスに追加されます。
- その他の正味貢献日数は常に有給休暇バランスに追加されますが、適切な符号が付きます。
たとえば、有給休暇バランスが10、その他の正味貢献日数が2の場合、有給休暇残余日数バランスは10+2=12です。有給休暇バランスが10、その他の正味貢献日数が(-3)の場合、有給休暇残余日数バランスは10+(-3) = 7になります。
- 有給休暇期間と計上期間のサンプル・データ・セットを次に示します。
ここでは、原価集計(W_PROJ_COST_A)と収益集計(W_PROJ_REVENUE_A)の単位を、期間、四半期、または年に構成する方法について説明します。デフォルトのインストール時には、原価集計と収益集計の単位は会計期間に設定されます。集計の単位は、期間、四半期、または年のいずれかに変更できます。これは、FSMパラメータ(COST_TIME_GRAINおよびREVENUE_TIME_GRAIN)を「PERIOD」、「QUARTER」、「YEAR」に構成することで行います。さらに、この項で説明するBIメタデータ・リポジトリ(RPDファイル)の変更も必要です。
この項の内容は次のとおりです。
注意: 変更を適用する前に、BIメタデータ・リポジトリ(RPDファイル)のバックアップを作成するようにしてください。
デフォルトでは、パラメータCOST_TIME_GRAINおよびREVENUE_TIME_GRAINは「PERIOD」に設定されています。集計の単位を変更する場合は、これらの変数を目的のレベルに設定する必要があります。また、RPDでの結合も、適切な表を反映するように更新する必要があります。
FSMで値を変更するには、「パラメータの管理」に移動し、「COST_TIME_GRAIN」を選択して、「編集」ボタンをクリックします。
FSMで時間単位パラメータを設定する手順は次のとおりです。
「パラメータの管理」に移動します。
「COST_TIME_GRAIN」を選択して、「編集」ボタンをクリックします。
「パラメータの管理」の「デフォルト」領域で、「デフォルト値」フィールドの値を指定します。使用できる値は、次のとおりです。
PERIOD
QUARTER
YEAR
前述の手順をREVENUE_TIME_GRAINでも繰り返します。
これはデフォルトの構成です。FSMでCOST_TIME_GRAINが「PERIOD」に設定されていることと、次に示すRPD結合が用意されていることを確認する必要があります。
会計カレンダ(「ディメンション - 日付会計カレンダ」)への結合を確認します。
「ビジネス・モデルとマッピング」レイヤーで、「ディメンション - 日付会計カレンダ」から「Dim_W_MCAL_PERIOD_D_Fiscal_Period」論理表ソースを、「ファクト - プロジェクト原価」で「Fact_Agg_W_PROJ_COST_A_Project_Cost」および「Fact_Agg_W_PROJ_COST_A_Project_Cost_ITD」論理表ソースを選択し、右クリックして「物理図」→「選択されたオブジェクトのみ」を選択して、次に示す物理結合を確認し、「OK」をクリックします。
結合A:
"Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_MCAL_PERIOD_D_Fiscal_Period"."MCAL_PERIOD_START_DAY_WID" = "Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_COST_A_Project_Cost"."PRVDR_GL_ACCT_PRD_STRT_DAY_WID"
結合B:
"Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_MCAL_PERIOD_D_Fiscal_Period"."MCAL_PERIOD_END_DAY_WID" >= "Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_COST_A_Project_Cost_ITD"."PRVDR_GL_ACCT_PRD_END_DAY_WID" AND "Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_MCAL_PERIOD_D_Fiscal_Period"."MCAL_CAL_WID" = "Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_COST_A_Project_Cost_ITD"."PRVDR_GL_MCAL_CAL_WID"
結合C:
"Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_COST_A_Project_Cost_ITD"."PRVDR_GL_ACCT_PRD_END_DAY_WID" <= "Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_MCAL_QTR_D_Fiscal_Quarter"."MCAL_QTR_END_DAY_WID" AND "Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_MCAL_QTR_D_Fiscal_Quarter"."MCAL_CAL_WID" = "Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_COST_A_Project_Cost_ITD"."PRVDR_GL_MCAL_CAL_WID"
結合D:
"Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_MCAL_YEAR_D_Fiscal_Year"."MCAL_YEAR_END_DAY_WID" >= "Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_COST_A_Project_Cost_ITD"."PRVDR_GL_ACCT_PRD_END_DAY_WID" AND "Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_MCAL_YEAR_D_Fiscal_Year"."MCAL_CAL_WID" = "Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_COST_A_Project_Cost_ITD"."PRVDR_GL_MCAL_CAL_WID"
プロジェクト・カレンダ(「ディメンション - 日付プロジェクト・カレンダ」)への結合を確認します。
「ビジネス・モデルとマッピング」レイヤーで、「ディメンション - 日付プロジェクト・カレンダ」から「Dim_W_MCAL_PERIOD_D_Project_Period」論理表ソースを、「ファクト - プロジェクト原価」で「Fact_Agg_W_PROJ_COST_A_Project_Cost」および「Fact_Agg_W_PROJ_COST_A_Project_Cost_ITD」論理表ソースを選択し、右クリックして「物理図」→「選択されたオブジェクトのみ」を選択して、次に示す物理結合を確認し、「OK」をクリックします。
結合A:
"Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_MCAL_PERIOD_D_Project_Period"."MCAL_PERIOD_START_DAY_WID" = "Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_COST_A_Project_Cost"."PRVDR_PRJ_ACCT_PRD_ST_DAY_WID"
結合B:
"Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_MCAL_PERIOD_D_Project_Period"."MCAL_PERIOD_END_DAY_WID" >= "Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_COST_A_Project_Cost_ITD"."PRVDR_PRJ_ACCT_PRD_END_DAY_WID" AND "Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_MCAL_PERIOD_D_Project_Period"."MCAL_CAL_WID" = "Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_COST_A_Project_Cost_ITD"."PRVDR_PROJ_MCAL_CAL_WID"
結合C:
"Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_COST_A_Project_Cost_ITD"."PRVDR_PRJ_ACCT_PRD_END_DAY_WID" <= "Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_MCAL_QTR_D_Project_Quarter"."MCAL_QTR_END_DAY_WID" AND "Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_MCAL_QTR_D_Project_Quarter"."MCAL_CAL_WID" = "Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_COST_A_Project_Cost_ITD"."PRVDR_PROJ_MCAL_CAL_WID"
結合D:
"Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_MCAL_YEAR_D_Project_Year"."MCAL_YEAR_END_DAY_WID" >= "Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_COST_A_Project_Cost_ITD"."PRVDR_PRJ_ACCT_PRD_END_DAY_WID" AND "Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_MCAL_YEAR_D_Project_Year"."MCAL_CAL_WID" = "Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_COST_A_Project_Cost_ITD"."PRVDR_PROJ_MCAL_CAL_WID"
企業カレンダ(「ディメンション - 日付」)への結合を確認します。
「ビジネス・モデルとマッピング」レイヤーで、「ディメンション - 日付」から「Dim_W_ENT_PERIOD_D」論理表ソースを、「ファクト - プロジェクト原価」で「Fact_Agg_W_PROJ_COST_A_Project_Cost」および「Fact_Agg_W_PROJ_COST_A_Project_Cost_ITD」論理表ソースを選択し、右クリックして「物理図」→「選択されたオブジェクトのみ」を選択して、次に示す物理結合を確認し、「OK」をクリックします。
結合A:
"Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_ENT_PERIOD_D"."ENT_PERIOD_START_DT_WID" = "Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_COST_A_Project_Cost"."ENT_PERIOD_START_DAY_WID"
結合B:
"Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_COST_A_Project_Cost_ITD"."ENT_PERIOD_END_DAY_WID" <= "Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_ENT_PERIOD_D"."ENT_PERIOD_END_DT_WID"
結合C:
"Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_COST_A_Project_Cost_ITD"."ENT_PERIOD_END_DAY_WID" <= "Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_ENT_QTR_D"."ENT_QTR_END_DT_WID"
結合D:
"Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_ENT_YEAR_D"."ENT_YEAR_END_DT_WID" >= "Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_COST_A_Project_Cost_ITD"."ENT_PERIOD_END_DAY_WID"
「ビジネス・モデルとマッピング」レイヤーで、コンテンツ集計レベルを変更します。
デフォルトのインストール時には、「ディメンション - 日付会計カレンダ」、「ディメンション - 日付プロジェクト・カレンダ」および「ディメンション - 日付」の各ディメンションに対する原価集計の単位が「期間」に設定されます。「ビジネス・モデルとマッピング」レイヤーで、「ファクト - プロジェクト原価」に含まれる、これら2つの論理表ソースを開いて、単位が「期間」レベルに設定されていることを確認します。
変更内容を保存します。
整合性チェックを実行してエラーがないことを確認し、RPDファイルを保存して、Oracle BI Enterprise Editionのキャッシュをクリアします。オフライン・モードで変更を行った場合は、Oracle BI ServerとOracle BI Presentation Servicesを再起動します。
これはデフォルトの構成です。FSMでREVENUE_TIME_GRAINが「PERIOD」に設定されていることと、次に示すRPD結合が用意されていることを確認する必要があります。
会計カレンダ(「ディメンション - 日付会計カレンダ」)への結合を確認します。
「ビジネス・モデルとマッピング」レイヤーで、「ディメンション - 日付会計カレンダ」から「Dim_W_MCAL_PERIOD_D_Fiscal_Period」論理表ソースを、「ファクト - プロジェクト収益」で「Fact_Agg_W_PROJ_REVENUE_A_Revenue」および「Fact_Agg_W_PROJ_REVENUE_A_Revenue_ITD」論理表ソースを選択し、右クリックして「物理図」→「選択されたオブジェクトのみ」を選択して、次に示す物理結合を確認し、「OK」をクリックします。
結合A:
"Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_MCAL_PERIOD_D_Fiscal_Period"."MCAL_PERIOD_START_DAY_WID" = "Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_REVENUE_A_Revenue"."GL_ACCT_PERIOD_START_DAY_WID"
結合B:
"Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_MCAL_PERIOD_D_Fiscal_Period"."MCAL_PERIOD_END_DAY_WID" >= "Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_REVENUE_A_Revenue_ITD"."GL_ACCT_PERIOD_END_DAY_WID" AND "Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_MCAL_PERIOD_D_Fiscal_Period"."MCAL_CAL_WID" = "Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_REVENUE_A_Revenue_ITD"."GL_MCAL_CAL_WID"
結合C:
"Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_REVENUE_A_Revenue_ITD"."GL_ACCT_PERIOD_END_DAY_WID" <= "Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_MCAL_QTR_D_Fiscal_Quarter"."MCAL_QTR_END_DAY_WID" AND "Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_MCAL_QTR_D_Fiscal_Quarter"."MCAL_CAL_WID" = "Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_REVENUE_A_Revenue_ITD"."GL_MCAL_CAL_WID"
結合D:
"Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_MCAL_YEAR_D_Fiscal_Year"."MCAL_YEAR_END_DAY_WID" >= "Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_REVENUE_A_Revenue_ITD"."GL_ACCT_PERIOD_END_DAY_WID" AND "Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_MCAL_YEAR_D_Fiscal_Year"."MCAL_CAL_WID" = "Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_REVENUE_A_Revenue_ITD"."GL_MCAL_CAL_WID"
プロジェクト・カレンダ(「ディメンション - 日付プロジェクト・カレンダ」)への結合を確認します。
「ビジネス・モデルとマッピング」レイヤーで、「ディメンション - 日付プロジェクト・カレンダ」から「Dim_W_MCAL_PERIOD_D_Project_Period」論理表ソースを、「ファクト - プロジェクト収益」で「Fact_Agg_W_PROJ_REVENUE_A_Revenue」および「Fact_Agg_W_PROJ_REVENUE_A_Revenue_ITD」論理表ソースを選択し、右クリックして「物理図」→「選択されたオブジェクトのみ」を選択して、次に示す物理結合を確認し、「OK」をクリックします。
結合A:
"Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_MCAL_PERIOD_D_Project_Period"."MCAL_PERIOD_START_DAY_WID" = "Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_REVENUE_A_Revenue"."PROJ_ACCT_PERIOD_START_DAY_WID"
結合B:
"Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_MCAL_PERIOD_D_Project_Period"."MCAL_PERIOD_END_DAY_WID" >= "Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_REVENUE_A_Revenue_ITD"."PROJ_ACCT_PERIOD_END_DAY_WID" AND "Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_MCAL_PERIOD_D_Project_Period"."MCAL_CAL_WID" = "Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_REVENUE_A_Revenue_ITD"."PROJ_MCAL_CAL_WID"
結合C:
"Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_REVENUE_A_Revenue_ITD"."PROJ_ACCT_PERIOD_END_DAY_WID" <= "Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_MCAL_QTR_D_Project_Quarter"."MCAL_QTR_END_DAY_WID" AND "Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_MCAL_QTR_D_Project_Quarter"."MCAL_CAL_WID" = "Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_REVENUE_A_Revenue_ITD"."PROJ_MCAL_CAL_WID"
結合D:
"Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_MCAL_YEAR_D_Project_Year"."MCAL_YEAR_END_DAY_WID" >= "Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_REVENUE_A_Revenue_ITD"."PROJ_ACCT_PERIOD_END_DAY_WID" AND "Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_MCAL_YEAR_D_Project_Year"."MCAL_CAL_WID" = "Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_REVENUE_A_Revenue_ITD"."PROJ_MCAL_CAL_WID"
企業カレンダ(「ディメンション - 日付」)への結合を確認します。
「ビジネス・モデルとマッピング」レイヤーで、「ディメンション - 日付」から「Dim_W_ENT_PERIOD_D」論理表ソースを、「ファクト - プロジェクト収益」で「Fact_Agg_W_PROJ_COST_A_Project_Cost」、「Fact_Agg_W_PROJ_REVENUE_A_Revenue」および「Fact_Agg_W_PROJ_REVENUE_A_Revenue_ITD」論理表ソースを選択し、右クリックして「物理図」→「選択されたオブジェクトのみ」を選択して、次に示す物理結合を確認し、「OK」をクリックします。
結合A:
"Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_ENT_PERIOD_D"."ENT_PERIOD_START_DT_WID" = "Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_REVENUE_A_Revenue"."ENT_PERIOD_START_DAY_WID"
結合B:
"Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_REVENUE_A_Revenue_ITD"."ENT_PERIOD_END_DAY_WID" <= "Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_ENT_PERIOD_D"."ENT_PERIOD_END_DT_WID"
結合C:
"Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_REVENUE_A_Revenue_ITD"."ENT_PERIOD_END_DAY_WID" <= "Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_ENT_QTR_D"."ENT_QTR_END_DT_WID"
結合D:
"Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_ENT_YEAR_D"."ENT_YEAR_END_DT_WID" >= "Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_REVENUE_A_Revenue_ITD"."ENT_PERIOD_END_DAY_WID"
「ビジネス・モデルとマッピング」レイヤーで、コンテンツ集計レベルを変更します。
デフォルトのインストール時には、「ディメンション - 日付会計カレンダ」、「ディメンション - 日付プロジェクト・カレンダ」および「ディメンション - 日付」の各ディメンションに対する原価集計の単位が「期間」に設定されます。「ビジネス・モデルとマッピング」レイヤーで、「ファクト - プロジェクト収益」に含まれる、これら2つの論理表ソースを開いて、単位が「期間」レベルに設定されていることを確認します。
変更内容を保存します。
整合性チェックを実行してエラーがないことを確認し、RPDファイルを保存して、Oracle BI Enterprise Editionのキャッシュをクリアします。オフライン・モードで変更を行った場合は、Oracle BI ServerとOracle BI Presentation Servicesを再起動します。
原価集計の単位が四半期レベルの場合は、FSMでCOST_TIME_GRAINが「QUARTER」に設定されていることを確認する必要があります。また、会計カレンダ、プロジェクト・カレンダ、および企業カレンダについて、次のメタデータを変更する必要があります。
Dim_W_MCAL_PERIOD_D_Fiscal_Period/ Dim_W_MCAL_ PERIOD_D_Project_Period /Dim_W_ENT_ PERIOD_Dへの結合を削除します。
Fact_Agg_W_PROJ_COST_A_Project_Cost (論理表「ファクト - プロジェクト原価」の下)とDim_W_MCAL_PERIOD_D_Fiscal_Period (論理ディメンション、「ディメンション - 日付会計カレンダ」の下)、Dim_W_MCAL_PERIOD_D_Project_Period (論理ディメンション、「ディメンション - 日付プロジェクト・カレンダ」の下)とDim_W_ENT_PERIOD_D (論理ディメンション、「ディメンション - 日付」の下)の間の、既存の物理結合を削除します。
結合A:
"Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_MCAL_PERIOD_D_Fiscal_Period"."MCAL_PERIOD_START_DAY_WID" = "Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_COST_A_Project_Cost"."PRVDR_GL_ACCT_PRD_STRT_DAY_WID"
結合B:
"Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_MCAL_PERIOD_D_Project_Period"."MCAL_PERIOD_START_DAY_WID" = "Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_COST_A_Project_Cost"."PRVDR_PRJ_ACCT_PRD_ST_DAY_WID"
結合C:
"Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_ENT_PERIOD_D"."ENT_PERIOD_START_DT_WID" = "Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_COST_A_Project_Cost"."ENT_PERIOD_START_DAY_WID"
Fact_Agg_W_PROJ_COST_A_Project_Cost_ITD (論理表「ファクト - プロジェクト原価」の下)とDim_W_MCAL_PERIOD_D_Fiscal_Period (論理ディメンション、「ディメンション - 日付会計カレンダ」の下)、Dim_W_MCAL_PERIOD_D_Project_Period (論理ディメンション、「ディメンション - 日付プロジェクト・カレンダ」の下)とDim_W_ENT_PERIOD_D (論理ディメンション、「ディメンション - 日付」の下)の間の、既存の物理結合を削除します。
結合A:
"Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_MCAL_PERIOD_D_Fiscal_Period"."MCAL_PERIOD_END_DAY_WID" >= "Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_COST_A_Project_Cost_ITD"."PRVDR_GL_ACCT_PRD_END_DAY_WID" AND "Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_MCAL_PERIOD_D_Fiscal_Period"."MCAL_CAL_WID" = "Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_COST_A_Project_Cost_ITD"."PRVDR_GL_MCAL_CAL_WID"
結合B:
"Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_MCAL_PERIOD_D_Project_Period"."MCAL_PERIOD_END_DAY_WID" >= "Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_COST_A_Project_Cost_ITD"."PRVDR_PRJ_ACCT_PRD_END_DAY_WID" AND "Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_MCAL_PERIOD_D_Project_Period"."MCAL_CAL_WID" = "Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_COST_A_Project_Cost_ITD"."PRVDR_PROJ_MCAL_CAL_WID"
結合C:
"Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_COST_A_Project_Cost_ITD"."ENT_PERIOD_END_DAY_WID" <= "Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_ENT_PERIOD_D"."ENT_PERIOD_END_DT_WID"
Dim_W_MCAL_QTR_D_Fiscal_Quarterへの結合を作成します。
「ビジネス・モデルとマッピング」レイヤーで、「ディメンション - 日付プロジェクト・カレンダ」から「Dim_W_MCAL_QTR_D_Project_Quarter/ Dim_W_MCAL_YEAR_D_Project_Year」論理表ソースを、「ファクト - プロジェクト原価」で「Fact_Agg_W_PROJ_COST_A_Project_Cost」および「Fact_Agg_W_PROJ_COST_A_Project_Cost_ITD」論理表ソースを選択し、右クリックして「物理図」→「選択されたオブジェクトのみ」を選択して、「OK」をクリックします。次の物理結合を作成します。
結合A:
"Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_MCAL_QTR_D_Fiscal_Quarter"."MCAL_QTR_START_DAY_WID" = "Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_COST_A_Project_Cost"."PRVDR_GL_ACCT_PERIOD_START_DAY_WID"
次の結合を確認します。
結合A:
"Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_COST_A_Project_Cost_ITD"."PRVDR_GL_ACCT_PERIOD_END_DAY_WID" <= "Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_MCAL_QTR_D_Fiscal_Quarter"."MCAL_QTR_END_DAY_WID" AND "Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_COST_A_Project_Cost_ITD"."PRVDR_GL_MCAL_CAL_WID" = "Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_MCAL_QTR_D_Fiscal_Quarter"."MCAL_CAL_WID"
結合B:
"Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_MCAL_YEAR_D_Fiscal_Year"."MCAL_YEAR_END_DAY_WID" >= "Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_COST_A_Project_Cost_ITD"."PRVDR_GL_ACCT_PERIOD_END_DAY_WID" AND "Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_MCAL_YEAR_D_Fiscal_Year"."MCAL_CAL_WID" = "Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_COST_A_Project_Cost_ITD"."PRVDR_GL_MCAL_CAL_WID"
Dim_W_MCAL_QTR_D_Project_Quarterへの結合を作成します。
「ビジネス・モデルとマッピング」レイヤーで、「ディメンション - 日付プロジェクト・カレンダ」から「Dim_W_MCAL_QTR_D_Project_Quarter/ Dim_W_MCAL_YEAR_D_Project_Year」論理表ソースを、「ファクト - プロジェクト収益」で「Fact_Agg_W_PROJ_COST_A_Project_Cost」および「Fact_Agg_W_PROJ_COST_A_Project_Cost_ITD」論理表ソースを選択し、右クリックして「物理図」→「選択されたオブジェクトのみ」を選択して、「OK」をクリックします。次の物理結合を作成します。
結合A:
"Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_MCAL_QTR_D_Project_Quarter"."MCAL_QTR_START_DAY_WID" = "Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_COST_A_Project_Cost"."PRVDR_PRJ_ACCT_PRD_START_DAY_WID"
次の結合を確認します。
結合A:
"Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_COST_A_Project_Cost_ITD"."PRVDR_PRJ_ACCT_PRD_END_DAY_WID" <= "Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_MCAL_QTR_D_Project_Quarter"."MCAL_QTR_END_DAY_WID" AND "Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_COST_A_Project_Cost_ITD"."PRVDR_PROJ_MCAL_CAL_WID" = "Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_MCAL_QTR_D_Project_Quarter"."MCAL_CAL_WID"
結合B:
"Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_MCAL_YEAR_D_Project_Year"."MCAL_YEAR_END_DAY_WID" >= "Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_COST_A_Project_Cost_ITD"."PRVDR_PRJ_ACCT_PRD_END_DAY_WID" AND "Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_MCAL_YEAR_D_Project_Year"."MCAL_CAL_WID" = "Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_COST_A_Project_Cost_ITD"."PRVDR_PROJ_MCAL_CAL_WID"
Dim_W_ENT_QTR_Dへの結合を作成します。
「ビジネス・モデルとマッピング」レイヤーで、「ディメンション - 日付」から「Dim_W_ENT_QTR_D / Dim_W_ENT_YEAR_D」論理表ソースを、「ファクト - プロジェクト原価」で「Fact_Agg_W_PROJ_COST_A_Project_Cost」および「Fact_Agg_W_PROJ_COST_A_Project_Cost_ITD」論理表ソースを選択し、右クリックして「物理図」→「選択されたオブジェクトのみ」を選択して、「OK」をクリックします。次の物理結合を作成します。
結合A:
"Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_ENT_QTR_D"."ENT_QTR_START_DT_WID" = "Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_COST_A_Project_Cost"."ENT_PERIOD_START_DAY_WID"
次の結合を確認します。
結合A:
"Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_COST_A_Project_Cost_ITD"."ENT_PERIOD_END_DAY_WID" <= "Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_ENT_QTR_D"."ENT_QTR_END_DT_WID"
結合B:
"Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_ENT_YEAR_D"."ENT_YEAR_END_DT_WID" >= "Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_COST_A_Project_Cost_ITD"."ENT_PERIOD_END_DAY_WID"
「ビジネス・モデルとマッピング」レイヤーで、コンテンツ集計レベルを変更します。
デフォルトのインストール時には、「ディメンション - 日付会計カレンダ」、「ディメンション - 日付プロジェクト・カレンダ」および「ディメンション - 日付」の各ディメンションに対する原価集計の単位が「期間」に設定されます。
会計/プロジェクト/企業期間のかわりに、「ディメンション - 日付会計カレンダ」には会計四半期、「ディメンション - 日付プロジェクト・カレンダ」にはプロジェクト四半期、「ディメンション - 日付」には企業四半期を設定する必要があります。
変更内容を保存します。
これらの変更を完了したら、整合性チェックを実行してエラーがないことを確認し、RPDファイルを保存して、Oracle BI Enterprise Editionのキャッシュをクリアします。オフライン・モードで変更を行った場合は、Oracle BI ServerとOracle BI Presentation Servicesを再起動します。
収益集計の単位が四半期レベルの場合は、FSMでREVENUE_TIME_GRAINが「QUARTER」に設定されていることを確認する必要があります。また、会計、プロジェクト、および企業カレンダの、次のメタデータを変更する必要があります。
Dim_W_MCAL_PERIOD_D_Fiscal_Period/ Dim_W_MCAL_ PERIOD_D_Project_Period /Dim_W_ENT_ PERIOD_Dへの結合を削除します。
Fact_Agg_W_PROJ_REVENUE_A_Revenue (論理表「ファクト – プロジェクト収益」の下)とDim_W_MCAL_ PERIOD_D_Fiscal_Period (論理ディメンション「ディメンション – 日付会計カレンダ」の下)、Dim_W_MCAL_ PERIOD_D_Project_Period (論理ディメンション「ディメンション – 日付プロジェクト・カレンダ」の下)とDim_W_ENT_ PERIOD_D (論理ディメンション、「ディメンション - 日付」の下)の間の、既存の物理結合を削除します。
結合A:
"Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_MCAL_PERIOD_D_Fiscal_Period"."MCAL_PERIOD_START_DAY_WID" = "Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_REVENUE_A_Revenue"."GL_ACCT_PERIOD_START_DAY_WID"
結合B:
"Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_MCAL_PERIOD_D_Project_Period"."MCAL_PERIOD_START_DAY_WID" = "Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_REVENUE_A_Revenue"."PROJ_ACCT_PERIOD_START_DAY_WID"
結合C:
"Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_ENT_PERIOD_D"."ENT_PERIOD_START_DT_WID" = "Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_REVENUE_A_Revenue"."ENT_PERIOD_START_DAY_WID"
Fact_Agg_W_PROJ_REVENUE_A_Revenue_ITD (論理表「ファクト - プロジェクト収益」の下)とDim_W_MCAL_PERIOD_D_Fiscal_Period (論理ディメンション、「ディメンション - 日付会計カレンダ」の下)、Dim_W_MCAL_PERIOD_D_Project_Period (論理ディメンション、「ディメンション - 日付プロジェクト・カレンダ」の下)とDim_W_ENT_PERIOD_D (論理ディメンション、「ディメンション - 日付」の下)の間の、既存の物理結合を削除します。
結合A:
"Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_MCAL_PERIOD_D_Fiscal_Period"."MCAL_PERIOD_END_DAY_WID" >= "Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_REVENUE_A_Revenue_ITD"."GL_ACCT_PERIOD_END_DAY_WID" AND "Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_MCAL_PERIOD_D_Fiscal_Period"."MCAL_CAL_WID" = "Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_REVENUE_A_Revenue_ITD"."GL_MCAL_CAL_WID"
結合B:
"Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_MCAL_PERIOD_D_Project_Period"."MCAL_PERIOD_END_DAY_WID" >= "Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_REVENUE_A_Revenue_ITD"."PROJ_ACCT_PERIOD_END_DAY_WID" AND "Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_MCAL_PERIOD_D_Project_Period"."MCAL_CAL_WID" = "Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_REVENUE_A_Revenue_ITD"."PROJ_MCAL_CAL_WID"
結合C:
"Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_REVENUE_A_Revenue_ITD"."ENT_PERIOD_END_DAY_WID" <= "Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_ENT_PERIOD_D"."ENT_PERIOD_END_DT_WID"
Dim_W_MCAL_QTR_D_Fiscal_Quarterへの結合を作成します。
「ビジネス・モデルとマッピング」レイヤーで、「ディメンション - 日付会計カレンダ」から「Dim_W_MCAL_QTR_D_Fiscal_Quarter/ Dim_W_MCAL_YEAR_D_Fiscal_Year」論理表ソースを、「ファクト - プロジェクト収益」で「Fact_Agg_W_PROJ_REVENUE_A_Revenue」および「Fact_Agg_W_PROJ_REVENUE_A_Revenue_ITD」論理表ソースを選択し、右クリックして「物理図」→「選択されたオブジェクトのみ」を選択して、「OK」をクリックします。次の物理結合を作成します。
結合A:
"Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_MCAL_QTR_D_Fiscal_Quarter"."MCAL_PERIOD_START_DAY_WID" = "Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_REVENUE_A_Revenue"."GL_ACCT_PERIOD_START_DAY_WID"
次の結合を確認します。
結合A:
"Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_REVENUE_A_Revenue_ITD"."GL_ACCT_PERIOD_END_DAY_WID" <= "Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_MCAL_QTR_D_Fiscal_Quarter"."MCAL_QTR_END_DAY_WID" AND "Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_MCAL_QTR_D_Fiscal_Quarter"."MCAL_CAL_WID" = "Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_REVENUE_A_Revenue_ITD"."GL_MCAL_CAL_WID"
結合B:
"Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_MCAL_YEAR_D_Fiscal_Year"."MCAL_YEAR_END_DAY_WID" >= "Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_REVENUE_A_Revenue_ITD"."GL_ACCT_PERIOD_END_DAY_WID" AND "Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_MCAL_YEAR_D_Fiscal_Year"."MCAL_CAL_WID" = "Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_REVENUE_A_Revenue_ITD"."GL_MCAL_CAL_WID"
Dim_W_MCAL_QTR_D_Project_Quarterへの結合を作成します。
「ビジネス・モデルとマッピング」レイヤーで、「ディメンション - 日付プロジェクト・カレンダ」から「Dim_W_MCAL_QTR_D_Project_Quarter/ Dim_W_MCAL_YEAR_D_Project_Year」論理表ソースを、「ファクト - プロジェクト収益」で「Fact_Agg_W_PROJ_REVENUE_A_Revenue」および「Fact_Agg_W_PROJ_REVENUE_A_Revenue_ITD_Logical」表ソースを選択し、右クリックして「物理図」→「選択されたオブジェクトのみ」を選択して、「OK」をクリックします。次の物理結合を作成します。
結合A:
"Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_MCAL_QTR_D_Project_Quarter"."MCAL_QTR_START_DAY_WID" = "Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_REVENUE_A_Revenue"."PROJ_ACCT_PERIOD_START_DAY_WID"
次の結合を確認します。
結合A:
"Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_REVENUE_A_Revenue_ITD"."PROJ_ACCT_PERIOD_END_DAY_WID" <= "Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_MCAL_QTR_D_Project_Quarter"."MCAL_QTR_END_DAY_WID" AND "Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_MCAL_QTR_D_Project_Quarter"."MCAL_CAL_WID" = "Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_REVENUE_A_Revenue_ITD"."PROJ_MCAL_CAL_WID"
結合B:
"Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_MCAL_YEAR_D_Project_Year"."MCAL_YEAR_END_DAY_WID" >= "Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_REVENUE_A_Revenue_ITD"."PROJ_ACCT_PERIOD_END_DAY_WID" AND "Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_MCAL_YEAR_D_Project_Year"."MCAL_CAL_WID" = "Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_REVENUE_A_Revenue_ITD"."PROJ_MCAL_CAL_WID"
Dim_W_ENT_QTR_Dへの結合を作成します。
「ビジネス・モデルとマッピング」レイヤーで、「ディメンション - 日付」から「Dim_W_ENT_QTR_D / Dim_W_ENT_YEAR_D」論理表ソースを、「ファクト - プロジェクト収益」で「Fact_Agg_W_PROJ_REVENUE_A_Revenue」および「Fact_Agg_W_PROJ_REVENUE_A_Revenue_ITD_ Logical」表ソースを選択し、右クリックして「物理図」→「選択されたオブジェクトのみ」を選択して、「OK」をクリックします。次の物理結合を作成します。
結合A:
"Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_ENT_QTR_D"."ENT_QTR_START_DT_WID" = "Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_REVENUE_A_Revenue"."ENT_PERIOD_START_DAY_WID"
次の結合を確認します。
結合A:
"Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_REVENUE_A_Revenue_ITD"."ENT_PERIOD_END_DAY_WID" <= "Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_ENT_QTR_D"."ENT_QTR_END_DT_WID"
結合A:
"Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_ENT_YEAR_D"."ENT_YEAR_END_DT_WID" >= "Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_REVENUE_A_Revenue_ITD"."ENT_PERIOD_END_DAY_WID"
「ビジネス・モデルとマッピング」レイヤーで、コンテンツ集計レベルを変更します。
デフォルトのインストール時には、「ディメンション - 日付会計カレンダ」、「ディメンション - 日付プロジェクト・カレンダ」および「ディメンション - 日付」の各ディメンションに対する収益集計の単位が「期間」に設定されます。
会計/プロジェクト期間のかわりに、「ディメンション - 日付会計カレンダ」には会計四半期、「ディメンション - 日付プロジェクト・カレンダ」にはプロジェクト四半期、「ディメンション - 日付」には企業四半期を設定する必要があります。
変更内容を保存します。
これらの変更を完了したら、整合性チェックを実行してエラーがないことを確認し、RPDファイルを保存して、Oracle BI Enterprise Editionのキャッシュをクリアします。オフライン・モードで変更を行った場合は、Oracle BI ServerとOracle BI Presentation Servicesを再起動します。
原価集計の単位が年度レベルの場合は、FSMでCOST_TIME_GRAINが「YEAR」に設定されていることを確認する必要があります。また、会計、プロジェクト、および企業カレンダの、次のメタデータを変更する必要があります。
Dim_W_MCAL_PERIOD_D_Fiscal_Period/ Dim_W_MCAL_ PERIOD_D_Project_Period /Dim_W_ENT_ PERIOD_Dへの結合を削除します。
Fact_Agg_W_PROJ_COST_A_Project_Cost (論理表「ファクト - プロジェクト原価」の下)とDim_W_MCAL_PERIOD_D_Fiscal_Period (論理ディメンション、「ディメンション - 日付会計カレンダ」の下)、Dim_W_MCAL_PERIOD_D_Project_Period (論理ディメンション、「ディメンション - 日付プロジェクト・カレンダ」の下)とDim_W_ENT_PERIOD_D (論理ディメンション、「ディメンション - 日付」の下)の間の、既存の物理結合を削除します。
結合A:
"Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_MCAL_PERIOD_D_Fiscal_Period"."MCAL_PERIOD_START_DAY_WID" = "Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_COST_A_Project_Cost"."PRVDR_GL_ACCT_PRD_STRT_DAY_WID"
結合B:
"Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_MCAL_PERIOD_D_Project_Period"."MCAL_PERIOD_START_DAY_WID" = "Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_COST_A_Project_Cost"."PRVDR_PRJ_ACCT_PRD_ST_DAY_WID"
結合C:
"Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_ENT_PERIOD_D"."ENT_PERIOD_START_DT_WID" = "Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_COST_A_Project_Cost"."ENT_PERIOD_START_DAY_WID"
Fact_Agg_W_PROJ_COST_A_Project_Cost_ITD (論理表「ファクト - プロジェクト原価」の下)とDim_W_MCAL_PERIOD_D_Fiscal_Period (論理ディメンション、「ディメンション - 日付会計カレンダ」の下)、Dim_W_MCAL_PERIOD_D_Project_Period (論理ディメンション、「ディメンション - 日付プロジェクト・カレンダ」の下)とDim_W_ENT_PERIOD_D (論理ディメンション、「ディメンション - 日付」の下)の間の、既存の物理結合を削除します。
結合A:
"Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_MCAL_PERIOD_D_Fiscal_Period"."MCAL_PERIOD_END_DAY_WID" >= "Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_COST_A_Project_Cost_ITD"."PRVDR_GL_ACCT_PRD_END_DAY_WID" AND "Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_MCAL_PERIOD_D_Fiscal_Period"."MCAL_CAL_WID" = "Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_COST_A_Project_Cost_ITD"."PRVDR_GL_MCAL_CAL_WID"
結合B:
"Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_MCAL_PERIOD_D_Project_Period"."MCAL_PERIOD_END_DAY_WID" >= "Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_COST_A_Project_Cost_ITD"."PRVDR_PRJ_ACCT_PRD_END_DAY_WID" AND "Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_MCAL_PERIOD_D_Project_Period"."MCAL_CAL_WID" = "Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_COST_A_Project_Cost_ITD"."PRVDR_PROJ_MCAL_CAL_WID"
結合C:
"Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_COST_A_Project_Cost_ITD"."ENT_PERIOD_END_DAY_WID" <= "Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_ENT_PERIOD_D"."ENT_PERIOD_END_DT_WID"
Dim_W_MCAL_YEAR_D_Fiscal_Year/ Dim_W_MCAL_YEAR_D_Project_Year/ Dim_W_ENT_YEAR_Dへの結合を作成します。
次に示す物理結合を、次に示す論理表ソース・ファクトFact_Agg_W_PROJ_COST_A_Project_Cost (論理表「ファクト - プロジェクト原価」の下)とDim_W_MCAL_YEAR_D_Fiscal_Year (論理ディメンション、「ディメンション - 日付会計カレンダ」の下)、Dim_W_MCAL_YEAR_D_Project_Year (論理ディメンション、「ディメンション - 日付プロジェクト・カレンダ」の下)とDim_W_ENT_YEAR_D (論理ディメンション、「ディメンション - 日付」の下)の間に作成する必要があります。
結合A:
"Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_MCAL_YEAR_D_Fiscal_Year"."MCAL_YEAR_START_DAY_WID" = "Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_COST_A_Project_Cost"."PRVDR_GL_ACCT_PERIOD_START_DAY_WID"
結合B:
"Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_MCAL_YEAR_D_Project_Year"."MCAL_YEAR_START_DAY_WID" = "Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_COST_A_Project_Cost"."PRVDR_PRJ_ACCT_PRD_START_DAY_WID"
結合C:
"Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_ENT_YEAR_D"."ENT_YEAR_START_DT_WID" = "Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_COST_A_Project_Cost"."ENT_PERIOD_START_DAY_WID"
Dim_W_MCAL_YEAR_D_Fiscal_Year/ Dim_W_MCAL_YEAR_D_Project_Year/ Dim_W_ENT_YEAR_Dへの結合を確認します。
「ファクト - プロジェクト原価」のFact_Agg_W_PROJ_COST_A_Project_Cost_ITD論理表ソースから、「ディメンション - 日付会計カレンダ」のDim_W_MCAL_YEAR_D_Fiscal_Year論理表ソース、「ディメンション - 日付プロジェクト・カレンダ」のDim_W_MCAL_YEAR_D_Project_Year論理表ソースおよび「ディメンション - 日付」のDim_W_ENT_YEAR_D論理表ソースへの結合が存在していることを確認します。これらは、デフォルトで行われています。
結合A:
"Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_MCAL_YEAR_D_Fiscal_Year"."MCAL_YEAR_END_DAY_WID" >= "Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_COST_A_Project_Cost_ITD"."PRVDR_GL_ACCT_PRD_END_DAY_WID" AND "Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_MCAL_YEAR_D_Fiscal_Year"."MCAL_CAL_WID" = "Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_COST_A_Project_Cost_ITD"."PRVDR_GL_MCAL_CAL_WID"
結合B:
"Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_MCAL_YEAR_D_Project_Year"."MCAL_YEAR_END_DAY_WID" >= "Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_COST_A_Project_Cost_ITD"."PRVDR_PRJ_ACCT_PRD_END_DAY_WID" AND "Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_MCAL_YEAR_D_Project_Year"."MCAL_CAL_WID" = "Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_COST_A_Project_Cost_ITD"."PRVDR_PROJ_MCAL_CAL_WID"
結合C:
"Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_ENT_YEAR_D"."ENT_YEAR_END_DT_WID" >= "Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_COST_A_Project_Cost_ITD"."ENT_PERIOD_END_DAY_WID"
「ビジネス・モデルとマッピング」レイヤーで、「集計内容」レベルを変更します。
デフォルトのインストール時には、「ディメンション - 日付会計カレンダ」、「ディメンション - 日付プロジェクト・カレンダ」および「ディメンション - 日付」の各ディメンションに対する原価集計の単位が「期間」に設定されます。
会計/プロジェクト期間のかわりに、「ディメンション - 日付会計カレンダ」には会計年度、「ディメンション - 日付プロジェクト・カレンダ」にはプロジェクト年度、「ディメンション - 日付」には企業年度を設定する必要があります。
変更内容を保存します。
これらの変更を完了したら、整合性チェックを実行してエラーがないことを確認し、RPDファイルを保存して、Oracle BI Enterprise Editionのキャッシュをクリアします。オフライン・モードで変更を行った場合は、Oracle BI ServerとOracle BI Presentation Servicesを再起動します。
収益集計の単位が年度レベルの場合は、FSMでREVENUE_TIME_GRAINが'YEAR'に設定されていることを確認する必要があります。また、会計、プロジェクト、および企業カレンダの、次のメタデータを変更する必要があります。
Dim_W_MCAL_PERIOD_D_Fiscal_Period/ Dim_W_MCAL_ PERIOD_D_Project_Period /Dim_W_ENT_ PERIOD_Dへの結合を削除します。
Fact_Agg_W_PROJ_REVENUE_A_Revenue (論理表「ファクト – プロジェクト収益」の下)とDim_W_MCAL_ PERIOD_D_Fiscal_Period (論理ディメンション「ディメンション – 日付会計カレンダ」の下)、Dim_W_MCAL_ PERIOD_D_Project_Period (論理ディメンション「ディメンション – 日付プロジェクト・カレンダ」の下)とDim_W_ENT_ PERIOD_D (論理ディメンション、「ディメンション - 日付」の下)の間の、既存の物理結合を削除します。
結合A:
"Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_MCAL_PERIOD_D_Fiscal_Period"."MCAL_PERIOD_START_DAY_WID" = "Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_REVENUE_A_Revenue"."GL_ACCT_PERIOD_START_DAY_WID"
結合B:
"Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_MCAL_PERIOD_D_Project_Period"."MCAL_PERIOD_START_DAY_WID" = "Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_REVENUE_A_Revenue"."PROJ_ACCT_PERIOD_START_DAY_WID"
結合C:
"Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_ENT_PERIOD_D"."ENT_PERIOD_START_DT_WID" = "Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_REVENUE_A_Revenue"."ENT_PERIOD_START_DAY_WID"
Fact_Agg_W_PROJ_REVENUE_A_Revenue_ITD (論理表「ファクト - プロジェクト収益」の下)とDim_W_MCAL_PERIOD_D_Fiscal_Period (論理ディメンション、「ディメンション - 日付会計カレンダ」の下)、Dim_W_MCAL_PERIOD_D_Project_Period (論理ディメンション、「ディメンション - 日付プロジェクト・カレンダ」の下)とDim_W_ENT_PERIOD_D (論理ディメンション、「ディメンション - 日付」の下)の間の、既存の物理結合を削除します。
結合A:
"Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_MCAL_PERIOD_D_Fiscal_Period"."MCAL_PERIOD_END_DAY_WID" >= "Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_REVENUE_A_Revenue_ITD"."GL_ACCT_PERIOD_END_DAY_WID" AND "Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_MCAL_PERIOD_D_Fiscal_Period"."MCAL_CAL_WID" = "Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_REVENUE_A_Revenue_ITD"."GL_MCAL_CAL_WID"
結合B:
"Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_MCAL_PERIOD_D_Project_Period"."MCAL_PERIOD_END_DAY_WID" >= "Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_REVENUE_A_Revenue_ITD"."PROJ_ACCT_PERIOD_END_DAY_WID" AND "Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_MCAL_PERIOD_D_Project_Period"."MCAL_CAL_WID" = "Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_REVENUE_A_Revenue_ITD"."PROJ_MCAL_CAL_WID"
結合C:
"Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_REVENUE_A_Revenue_ITD"."ENT_PERIOD_END_DAY_WID" <= "Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_ENT_PERIOD_D"."ENT_PERIOD_END_DT_WID"
Dim_W_MCAL_YEAR_D_Fiscal_Year、Dim_W_MCAL_YEAR_D_Project_Yearへの結合を作成します。
論理表ソース・ファクトFact_Agg_W_PROJ_REVENUE_A_Revenue (論理ファクト「ファクト - プロジェクト原価」の下)と、Dim_W_MCAL_YEAR_D_Fiscal_Year (論理ディメンション「ディメンション - 日付会計カレンダ」の下)、Dim_W_MCAL_YEAR_D_Project_Year (論理ディメンション「ディメンション - 日付プロジェクト・カレンダ」の下)およびDim_W_ENT_YEAR_D (論理ディメンション、「ディメンション - 日付」の下)との間に追加の物理結合を作成する必要があります。
結合A:
"Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_MCAL_YEAR_D_Fiscal_Year"."MCAL_YEAR_START_DAY_WID" = "Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_REVENUE_A_Revenue"."GL_ACCT_PERIOD_START_DAY_WID"
結合B:
"Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_MCAL_YEAR_D_Project_Year"."MCAL_YEAR_START_DAY_WID" = "Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_REVENUE_A_Revenue"."PROJ_ACCT_PERIOD_START_DAY_WID"
結合C:
"Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_ENT_YEAR_D"."ENT_YEAR_START_DT_WID" = "Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_REVENUE_A_Revenue"."ENT_PERIOD_START_DAY_WID"
Dim_W_MCAL_YEAR_D_Fiscal_Year、Dim_W_MCAL_YEAR_D_Project_Yearへの結合を確認します。
「ファクト - プロジェクト収益」のFact_Agg_W_PROJ_REVENUE_A_Revenue_ITD論理表ソースから、「ディメンション - 日付会計カレンダ」のDim_W_MCAL_YEAR_D_Fiscal_Year論理表ソース、「ディメンション - 日付プロジェクト・カレンダ」のDim_W_MCAL_YEAR_D_Project_Year論理表ソースおよび「ディメンション - 日付」のDim_W_ENT_YEAR_D論理表ソースへの結合が存在していることを確認します。これらは、デフォルトで行われています。
結合A:
"Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_MCAL_YEAR_D_Fiscal_Year"."MCAL_YEAR_END_DAY_WID" >= "Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_REVENUE_A_Revenue_ITD"."GL_ACCT_PERIOD_END_DAY_WID" AND "Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_MCAL_YEAR_D_Fiscal_Year"."MCAL_CAL_WID" = "Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_REVENUE_A_Revenue_ITD"."GL_MCAL_CAL_WID"
結合B:
"Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_MCAL_YEAR_D_Project_Year"."MCAL_YEAR_END_DAY_WID" >= "Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_REVENUE_A_Revenue_ITD"."PROJ_ACCT_PERIOD_END_DAY_WID" AND "Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_MCAL_YEAR_D_Project_Year"."MCAL_CAL_WID" = "Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_REVENUE_A_Revenue_ITD"."PROJ_MCAL_CAL_WID"
結合C:
"Oracle Data Warehouse"."Catalog"."dbo"."Dim_W_ENT_YEAR_D"."ENT_YEAR_END_DT_WID" >= "Oracle Data Warehouse"."Catalog"."dbo"."Fact_Agg_W_PROJ_REVENUE_A_Revenue_ITD"."ENT_PERIOD_END_DAY_WID"
「ビジネス・モデルとマッピング」レイヤーで、「集計内容」レベルを変更します。
デフォルトのインストール時には、「ディメンション - 日付会計カレンダ」、「ディメンション - 日付プロジェクト・カレンダ」および「ディメンション - 日付」の各ディメンションに対する収益集計の単位が「期間」に設定されます。
会計/プロジェクト期間のかわりに、「ディメンション - 日付会計カレンダ」には会計年度、「ディメンション - 日付プロジェクトカレンダ」にはプロジェクト年度、および「ディメンション - 日付」には企業年度を設定する必要があります。
変更内容を保存します。
これらの変更を完了したら、整合性チェックを実行してエラーがないことを確認し、RPDファイルを保存して、Oracle BI Enterprise Editionのキャッシュをクリアします。オフライン・モードで変更を行った場合は、Oracle BI ServerとOracle BI Presentation Servicesを再起動します。
目的
このドキュメントでは、ODI変数HR_ACCRUAL_EXTRACT_MODEの構成について説明します。この変数は、E-Business Suite有給休暇抽出プログラムで使用します。
HR_ACCRUAL_EXTRACT_MODEの値に基づいて、変数HR_ACCRUAL_THREADS_TOTALも抽出の一環として設定する必要があります。
オプションまたは必須
これは、必須の手順です。HR_ACCRUAL_EXTRACT_MODEのデフォルト値は、値を設定する(またはデフォルト値のNOPARALLELを使用する)前に確認して、その値の影響について理解しておく必要があります。このモードの詳細は、「詳細なタスクの説明」の項を参照してください。
適用対象
E-Business Suite 11.1.10およびR12.x.xの有給休暇モジュールに対して実行されるすべての抽出に適用されます。
詳細なタスクの説明
E-Business Suite有給休暇は、アサイメントの有給休暇データを抽出するために、FastFormula呼び出しを使用します。FastFormula関数呼び出しは、本質的に低速であり、パフォーマンス問題の原因になることがあります。ただし、アサイメント数が比較的少ない場合や収集する履歴の期間数が少ない場合は、各種のメトリックについてFastFormulasの呼び出しにかかる時間を再確認する必要があります。時間の推定に使用するSQLは、後述する「追加情報」の項を参照してください。
次に示す、3つのモードを使用できます。
NOPARALLEL: この値は、有給休暇抽出を単一のスレッド・モードで実行する場合に使用します。これにより、有給休暇抽出が有給休暇ロード計画の一環として行われるようになります。このモードが動作するには、ODIに、pl/sqlパッケージを作成するE-Business Suiteソース・スキーマの権限が必要になります。データ・ロードが比較的少ない場合(たとえば、増分ロード)や、HR_ACCRUAL_EXTRACT_DATEパラメータが比較的小さい値に設定されている場合に使用できます。また、デフォルトでは、これがDEFAULT抽出モードになります。
PARALLEL: この値は、有給休暇抽出を並列スレッドで実行する場合に使用します。これにより、ロード速度が向上します。このモードを構成するには、HR_ACCRUAL_THREADS_TOTAL変数に値を割り当てる必要があります。この変数の数値により、有給休暇ソース抽出プログラムで生成される並列スレッドの数が決まります。この変数に割り当てられるデフォルト値の8は、8つの並列スレッドが生成されることを意味します。10スレッドまでの拡張に対応できますが、その場合は、スレッド9およびスレッド10の並列ロード計画のステップを有効化する必要があります(デフォルトでは、8つの並列ステップが有効化されています)。
STANDALONE: この値は、有給休暇抽出プロセスが有給休暇ロード計画に含まれていないときに、そのプロセスを有給休暇ロード計画の実行前にスタンドアロン方式で実行する場合に使用します。これは、有給休暇抽出インタフェースで、有給休暇ロード計画に時間がかかりすぎて進行が停滞しないようにするために行われることがあります。スタンドアロン・モードは、抽出量が多い完全ロードで、完了までに時間がかかる場合に使用できます。この場合は、PLSQLベースのラッパー・アプローチも使用します。このモードが動作するには、ODIに、pl/sqlパッケージを作成するE-Business Suiteソース・スキーマの権限が必要になります。
依存関係
増分ロードの抽出は、HR_ACCRUAL_EXTRACT_DATEの値セットに依存します。そのため、この変数の値が大きい(比較的大きいデータセットを取得する)場合は、STANDALONEモードが最適になります。
追加情報
次に示すSQLは、有給休暇抽出時間の推定に使用できます。
SELECT PER_ALL_ASSIGNMENTS_F.ASSIGNMENT_ID ,PER_TIME_PERIODS.END_DATE, PER_UTILITY_FUNCTIONS.GET_NET_ACCRUAL(PER_ALL_ASSIGNMENTS_F.ASSIGNMENT_ID,PER_ALL_ASSIGNMENTS_F.PAYROLL_ID, PER_ALL_ASSIGNMENTS_F.BUSINESS_GROUP_ID,-1,PER_TIME_PERIODS.END_DATE,PAY_ACCRUAL_PLANS.ACCRUAL_PLAN_ID,PER_TIME_PERIODS.START_DATE,NULL), PER_ACCRUAL_CALC_FUNCTIONS.GET_CARRY_OVER(PER_ALL_ASSIGNMENTS_F.ASSIGNMENT_ID, PAY_ACCRUAL_PLANS.ACCRUAL_PLAN_ID,PER_TIME_PERIODS.END_DATE,PER_TIME_PERIODS.START_DATE ), PER_ACCRUAL_CALC_FUNCTIONS.GET_ABSENCE(PER_ALL_ASSIGNMENTS_F.ASSIGNMENT_ID, PAY_ACCRUAL_PLANS.ACCRUAL_PLAN_ID,PER_TIME_PERIODS.END_DATE, PER_TIME_PERIODS.START_DATE ), PER_ACCRUAL_CALC_FUNCTIONS.GET_OTHER_NET_CONTRIBUTION(PER_ALL_ASSIGNMENTS_F.ASSIGNMENT_ID, PAY_ACCRUAL_PLANS.ACCRUAL_PLAN_ID,PER_TIME_PERIODS.END_DATE,PER_TIME_PERIODS.START_DATE) FROM APPS.PAY_ELEMENT_ENTRIES_F PAY_ELEMENT_ENTRIES_F, APPS.PAY_ELEMENT_LINKS_F PAY_ELEMENT_LINKS_F, APPS.PAY_ELEMENT_TYPES_F PAY_ELEMENT_TYPES_F, APPS.PER_ALL_ASSIGNMENTS_F PER_ALL_ASSIGNMENTS_F, APPS.PER_TIME_PERIODS PER_TIME_PERIODS, APPS.PAY_ACCRUAL_PLANS PAY_ACCRUAL_PLANS WHERE (1=1) AND (PER_ALL_ASSIGNMENTS_F.ASSIGNMENT_TYPE IN ('E','C')) AND (PER_TIME_PERIODS.END_DATE < SYSDATE) AND (PER_TIME_PERIODS.END_DATE > #HR_ACCRUAL_EXTRACT_DATE)—Set the start date AND (PER_ALL_ASSIGNMENTS_F.PAYROLL_ID IS NOT NULL ) AND (PER_ALL_ASSIGNMENTS_F.ASSIGNMENT_ID=PAY_ELEMENT_ENTRIES_F.ASSIGNMENT_ID) AND (PER_ALL_ASSIGNMENTS_F.PAYROLL_ID=PER_TIME_PERIODS.PAYROLL_ID) AND (PAY_ELEMENT_ENTRIES_F.ELEMENT_LINK_ID=PAY_ELEMENT_LINKS_F.ELEMENT_LINK_ID) AND (PAY_ELEMENT_LINKS_F.ELEMENT_TYPE_ID=PAY_ELEMENT_TYPES_F.ELEMENT_TYPE_ID) AND (PAY_ELEMENT_LINKS_F.ELEMENT_TYPE_ID=PAY_ACCRUAL_PLANS.ACCRUAL_PLAN_ELEMENT_TYPE_ID) AND (PER_TIME_PERIODS.END_DATE BETWEEN PAY_ELEMENT_ENTRIES_F.EFFECTIVE_START_DATE AND PAY_ELEMENT_ENTRIES_F.EFFECTIVE_END_DATE) AND (PER_TIME_PERIODS.END_DATE BETWEEN PAY_ELEMENT_LINKS_F.EFFECTIVE_START_DATE AND PAY_ELEMENT_LINKS_F.EFFECTIVE_END_DATE) AND (PER_TIME_PERIODS.END_DATE BETWEEN PER_ALL_ASSIGNMENTS_F.EFFECTIVE_START_DATE AND PER_ALL_ASSIGNMENTS_F.EFFECTIVE_END_DATE) AND (PER_TIME_PERIODS.END_DATE BETWEEN PAY_ELEMENT_TYPES_F.EFFECTIVE_START_DATE AND PAY_ELEMENT_TYPES_F.EFFECTIVE_END_DATE);
GL勘定科目階層の構成は、Oracle Financial Analytics、Oracle Procurement and Spend Analytics、およびOracle Supply Chain and Order Management Analyticsをデプロイしている場合に必要になります。
GL会計フレックスフィールドの値セット定義を使用して階層を構成する方法の詳細は、第B.2.20項「E-Business SuiteのGL勘定科目およびGLセグメントの構成方法」を参照してください。
勘定体系内の複数のセグメントに基づいたGL勘定科目階層を定義する必要がある場合は、それらの階層を定義するために、E-Business SuiteのOracle FSGレポート定義を使用できます。
最初にOracle FSGのフォームを使用して、行セットまたは列セットを定義する必要があります。その後、Oracle BI Applicationsで行セットまたは列セットの定義を抽出して、その定義を階層に変換します。
Oracle FSGの階層は、次に示すE-Business Suiteのソース表から抽出します。
RG_REPORT_AXIS_CONTENTS
この表では、FSGレポートの軸とGLコードの組合せとの間の関係を定義します。その軸に定義された値範囲内のセグメント値を持つGLコードの組合せは、その軸の子として分類されます。
RG_REPORT_AXIS_SETS
この表には、定義した行セットまたは列セットごとの情報を格納します。この表には、定義した行セットまたは列セットごとに1つのレコードが格納されます。各行には、軸セットの識別子、行セットまたは列セットの名前、および特定の勘定体系を行セットまたは列セットに割り当てる構造識別子が格納されます。
RG_REPORT_CALCULATIONS
この表には、行セットまたは列セット内の各行または各列の計算に使用する計算式が格納されます。行計算の例としては、直前の5行の合計値の計算などがあげられます。列計算の例としては、列3の値から列4の値を減算した値を列5に挿入するなどの計算があげられます。
たとえば、損益計算書決算の純利益は、収益からの総利益を合計経費で減算した計算結果になります。階層に変換する場合、純利益は、収益からの総利益と合計経費の親になります。そのため、階層は、RG_REPORT_CALCULATIONの情報に基づいて導出できます。
次の図は、階層の例を示しています。この例では、最上位階層の純利益ノードには2つの子ノード(合計経費と収益からの総利益)があり、合計経費ノードには2つの子ノード(営業経費と減価償却費)があります。
この図は、階層から収入状態が導出される方法を示しています。
この階層は、フラット化された階層に変換してから、次に示す形式でW_HIERARCHY_Dに格納されます。
表B-26 W_HIERARCHY_Dに格納されるフラット化された階層の例
階層名 | HIER1 | HIER2 | HIER3 | HIER4 | HIER20 |
---|---|---|---|---|---|
損益計算書 |
純利益 |
総利益... |
総利益... |
総利益... |
総利益... |
損益計算書 |
純利益 |
合計経費 |
営業経費 |
営業経費 |
営業経費 |
損益計算書 |
純利益 |
合計経費 |
減価償却費 |
減価償却費 |
減価償却費 |
ファクト表は、GL勘定科目ディメンション表(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プロセスについて
GL勘定に対してETLプロセスを実行する前に、参照対象の階層を指定する必要があります。参照対象のFSG階層を指定するには、ファイルfile_gl_hierarchy_assignment_ora.csvを使用します。
注意: このタスクの構成ファイル(複数の場合もあり)は、Oracle BI Applicationsインストールの次の場所にあります。 ソース独立ファイル: <Oracle Home for BI>\biapps\etl\data_files\src_files\。 ソース固有ファイル: <Oracle Home for BI>\biapps\etl\data_files\src_files\<source adaptor>。 システム管理者は、これらのファイルを別の場所にコピーして、この場所から読み取るためのODI接続を構成しているはずです。システム管理者に、これらのファイルの取得を依頼してください。構成が完了したら、システム管理者は、構成済ファイルをODIの読取り元にコピーする必要があります。 |
このファイルでは、勘定体系ごとに6つのFSG階層を指定できます。FSG階層の指定には、axis_set_id (RG_REPORT_AXIS_SETS表の列)を使用します。これは、その勘定体系に属するコードの組合せの行セットまたは列セットの固有IDであり、GL勘定科目ディメンション表に格納します。
DATASOURCE_NUM_IDフィールドでは、構成を適用するデータソースを指定します。ソース・システムが複数ある場合は、同じIDを持つ勘定体系が複数のソース・システムに及んで存在している可能性があります。そのため、DATASOURCE_NUM_ID値を使用して、それらを区別する必要があります。
たとえば、損益計算書FSGレポートと貸借対照表FSGレポートがあり、それら両方の階層構造をOracle Business Analytics Warehouseに取り込むとします。Oracle BI Applicationsでは、両方のレポートが同じGL勘定セット(CHART_OF_ACCOUNTS=101)から導出されていることを想定しています。損益計算書のaxis_set_idは1001であり、貸借対照表のaxis_set_idは1003です。このアプリケーションのDATASOURCE_NUM_IDは2です。
さらに、このようにGL勘定が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のすべてのGL勘定について、HIER1からHIER6の列に、それぞれaxis_set_id=1001、NULL、1003、NULL、NULL、NULLの階層を割り当てることを示しています。その結果として、影響を受けるGL勘定の行については、抽出およびロードの完了後に、HIER1列がW_HIERARCHY_Dの収入計算書階層の行IDへの外部キーになり、HIER3列がW_HIERARCHY_Dの貸借対照表階層の行IDへの外部キーになります。
注意: Financial Analyticsで階層をロードするには、file_gl_hierarchy_assignment_ora.csv内でaxis_set_idが指定されている必要があります。
FSGレポート定義を使用して階層を設定するには:
file_gl_hierarchy_assignment_ora.csvファイルを構成して、CHART_OF_ACCOUNTSごとに参照対象にする階層を指定します。
ファイルfile_gl_hierarchy_assignment_ora.csvを編集します。
注意: このタスクの構成ファイル(複数の場合もあり)は、Oracle BI Applicationsインストールの次の場所にあります。 ソース独立ファイル: <Oracle Home for BI>\biapps\etl\data_files\src_files\。 ソース固有ファイル: <Oracle Home for BI>\biapps\etl\data_files\src_files\<source adaptor>。 システム管理者は、これらのファイルを別の場所にコピーして、この場所から読み取るためのODI接続を構成しているはずです。システム管理者に、これらのファイルの取得を依頼してください。構成が完了したら、システム管理者は、構成済ファイルをODIの読取り元にコピーする必要があります。 |
分析対象にするセグメントを指定します。
ファイルを保存して閉じます。
FSGを使用したGL勘定科目階層に関連するBIメタデータ・リポジトリ(RPDファイル)に、デフォルトで用意されている構成は次のとおりです。
FSGを使用したGL勘定科目階層の物理表(6つ)の別名が作成され、GL勘定科目ディメンション表(Dim_W_GL_ACCOUNT_D)に結合が作成されます。
前述の6つのディメンション階層の物理表に対応する論理表が、関連する論理ファクトへのBMM結合とともに作成されます。
適切な論理レベルとコンテンツ・フィルタが、デフォルトで用意されている6つのFSG論理ディメンションに設定されます。
論理ファクト表に含まれる関連する論理表ソースのすべてが、デフォルトで用意されている6つの論理ディメンションに必要な集計内容で設定されています。
FSGに関連している必須の属性を公開するには、次に示すようなユーザーによる追加構成が必要になることがあります。
Oracle BI EE管理ツールを使用して、Oracle BI Repositoryの「プレゼンテーション」レイヤーで、該当する論理ディメンションからプレゼンテーション・フォルダに新しい階層をドラッグします。
階層の名前は、「プレゼンテーション」レイヤーで必要に応じて変更できます。
目的
雇用ディメンションには、多くのHCMメトリックで使用される、いくつかの適合ドメインが含まれています。これらのドメインは、適切に構成してレポートに正確な情報が含まれるようにする必要があります。
オプションまたは必須
このタスクはオプションです。ただし、OLTP設定がデフォルト構成に適切に反映されていないことがあるため、レポートが正確であることを保証するための再確認が必要になります。
適用対象
すべてのソース。
詳細なタスクの説明
雇用ディメンションに関連するドメイン・マッピングを構成します。これらのマッピングで最重要な(多数のメトリックで使用されている)ものは、就業者タイプと就業者サブタイプへのマッピングです。これらは、階層として設計されています。この階層により、各種システムからの就業者タイプが1つの分類に収まるようになります。就業者タイプは、従業員と派遣就業者を区別するために主に使用されます。また、就業者サブタイプにより、各タイプを細かく分類できます。
就業者タイプのドメイン・マッピングは、ソース・ドメイン「システム・ワーカー・タイプおよびユーザー・ワーカー・タイプ」から派生されます。これは、ソース・システムごとに個別に派生され、それぞれに対する例が提供されます。
E-Business Suiteの例
「システム・ワーカー・タイプおよびユーザー・ワーカー・タイプ」ドメインは、次のタイプに基づきます。
システムPersonタイプ
ユーザーPersonタイプ
要件の例: デフォルトでは、派遣就業者はすべて1つのグループにまとめられています。インターン用に派遣就業者のサブタイプを追加して、対応するユーザーPersonタイプで識別します。
実装の例:
次のマッピングを、ドメインマップ「システム・ワーカー・タイプおよびユーザー・ワーカー・タイプ」→「就業者サブタイプ」に追加します。
CWK~INTERN→CONTINGENT_INTERN
通常の派遣就業者についての残りの定義は、すでにシードされているため、変更の必要はありません。
次の表は、このドメイン・マッピングの結果を示しています。1行目と2行目は、シード済のドメイン・マッピングを示しています。
表B-27 ドメイン・マッピングの例
ソース・メンバー・コード | 列1のメンバー・コード | 列2のメンバー・コード | ターゲット・メンバー・コード |
---|---|---|---|
CWK~__ANY__ |
CWK |
__ANY__ |
CONTINGENT_CONTINGENT |
EMP~__ANY__ |
EMP |
__ANY__ |
EMPLOYEE_REGULAR |
CWK~INTERN |
CWK |
INTERN |
CONTINGENT_INTERN |
注意: 複数の一致が許容されます。たとえば、個人タイプが「インターン」の派遣就業者は、CONTINGENT_CONTINGENTまたはCONTINGENT_INTERNのどちらかと一致します。ユーザーPersonタイプに対する完全一致は任意タイプの一致よりも優先されるため、結果はCONTINGENT_INTERNになります。
Peoplesoftの例
「システム・ワーカー・タイプおよびユーザー・ワーカー・タイプ」ドメインは、次のタイプに基づきます。
雇用形態
関係者(POI)タイプ
要件の例: デフォルトでは、派遣就業者は1つのグループにまとめられています。インターン用に派遣就業者のサブタイプを追加して、対応するPOIタイプで識別します。
実装の例:
次のマッピングを、ドメインマップ「システム・ワーカー・タイプおよびユーザー・ワーカー・タイプ」→「就業者サブタイプ」に追加します。
CWR~INT -> CONTINGENT_INTERN
通常の派遣就業者についての残りの定義は、すでにシードされているため変更の必要はありません。
次の表は、このドメイン・マッピングの結果を示しています。1行目から3行目は、シード済のドメイン・マッピングを示しています。
表B-28 ドメイン・マッピングの例
ソース・メンバー・コード | 列1のメンバー・コード | 列2のメンバー・コード | ターゲット・メンバー・コード |
---|---|---|---|
CWR~__ANY__ |
CWR |
__ANY__ |
CONTINGENT_CONTRACTOR |
EMP~__ANY__ |
EMP |
__ANY__ |
EMPLOYEE_REGULAR |
POI~__ANY__ |
POI |
__ANY__ |
NONWORKER |
CWR~INT |
CWR |
INT |
CONTINGENT_INTERN |
注意: 複数の一致が許容されます。たとえば、POIタイプが「インターン」の派遣就業者は、CONTINGENT_CONTRACTORまたはCONTINGENT_INTERNのどちらかと一致します。POIタイプに対する完全一致は任意POIタイプの一致よりも優先されるため、結果はCONTINGENT_INTERNになります。
Fusionの例
Fusionでの設定は、E-Business Suiteの場合とまったく同じです。
依存関係
なし。
実績原価は、プロジェクト原価計算から、そのプロジェクトの実績原価分析グループ内のすべての分析タイプについて抽出されます。
抽出されたすべての原価は原価ファクト明細表に直接費としてロードされます。ただし、次のどちらか、または両方の構成を実行した場合を除きます。
この特定方法をETLプロセス時に使用するには、FSMで変数BURDEN_ANALYSIS_TYPEを1に設定する必要があります。
ETLプロセスは、file_Project_Cost_Burden_Analysis_Type_psft.csvフラット・ファイルを使用して、プロジェクト原価間接費のすべての分析タイプをリストします。
ETLプロセスで、このフラット・ファイル内に分析タイプが見つかった場合は、プロジェクト原価間接費を判断するために、その他の参照表をさらに参照することはなくなります。
分析タイプに基づいてプロジェクト原価間接費を特定するには:
file_Project_Cost_Burden_Analysis_Type_psft.csvファイルを編集します。
注意: このタスクの構成ファイル(複数の場合もあり)は、Oracle BI Applicationsインストールの次の場所にあります。 ソース独立ファイル: <Oracle Home for BI>\biapps\etl\data_files\src_files\。 ソース固有ファイル: <Oracle Home for BI>\biapps\etl\data_files\src_files\<source adaptor>。 システム管理者は、これらのファイルを別の場所にコピーして、この場所から読み取るためのODI接続を構成しているはずです。システム管理者に、これらのファイルの取得を依頼してください。構成が完了したら、システム管理者は、構成済ファイルをODIの読取り元にコピーする必要があります。 |
間接費と見なされる分析タイプのリストを入力します。
形式はXXX,1です。XXXは分析タイプです。1は、間接費であることを示す戻り値です。
次に、分析タイプがBURおよびBRDである原価を間接費として分類する方法の例を示します。
BUR,1 BRD,1
ファイルを保存して閉じます。
注意:
FSMパラメータBURDEN_ANALYSIS_TYPEは、間接費を特定するための原価サブジェクト領域と予算サブジェクト領域の両方に共通のものです。
目的の実装ではプロジェクト予算とプロジェクト原価で要件に違いがある場合は、同じものに別個のFSM変数とODI変数を作成できます。注意: 間接費を特定するために、予算ファクトと原価ファクトに別個のFSM変数を作成する場合は、それらの新しい変数を使用するようにETLに変更を加える必要があります。
この特定方法をETLプロセス時に使用するには、FSMで変数BURDEN_TYPECATSUBを1に設定する必要があります。
ソース・タイプ、カテゴリ、サブカテゴリの値の組合せに基づいてプロジェクト原価間接費を特定するには、次のフラット・ファイルを構成する必要があります。file_Project_Cost_Burden_TypeCatSub_config_psft.csv。
このフラット・ファイルfile_Project_Cost_Burden_TypeCatSub_psft.csvを使用して、参照で使用する列(ソース・タイプ、カテゴリ、サブカテゴリ)をすべて指定します。
前述のCSVファイルに入力した列に基づいて、プロジェクト原価間接費として使用するソース・タイプ、カテゴリ、サブカテゴリの値の組合せをすべてリストするために、このフラット・ファイルを使用します。
注意:
これらのフラット・ファイルをプロジェクト予算とプロジェクト原価の両方で使用し、W_PROJ_LOOKUP_PSにFSMパラメータとともにデータをロードして間接費を特定します。
目的の実装ではプロジェクト予算とプロジェクト原価で要件に違いがある場合は、これらのファイルをカスタマイズできます。
file_Project_Cost_Burden_TypeCatSub_config_psft.csvファイル(構成ファイル)を構成するには:
file_Project_Cost_Burden_TypeCatSub_config_psft.csvファイルを編集します。
注意: このタスクの構成ファイル(複数の場合もあり)は、Oracle BI Applicationsインストールの次の場所にあります。 ソース独立ファイル: <Oracle Home for BI>\biapps\etl\data_files\src_files\。 ソース固有ファイル: <Oracle Home for BI>\biapps\etl\data_files\src_files\<source adaptor>。 システム管理者は、これらのファイルを別の場所にコピーして、この場所から読み取るためのODI接続を構成しているはずです。システム管理者に、これらのファイルの取得を依頼してください。構成が完了したら、システム管理者は、構成済ファイルをODIの読取り元にコピーする必要があります。 |
行IDが1の行を1行のみ入力します。プロジェクト原価間接費として評価される組合せを表す各列にYを入力します。次の列が対象になります。
Row ID Source Type Category Subcategory
次の例では、ソース・タイプとカテゴリの組合せの使用方法を示します。
1,Y,Y
(ソース・タイプとサブカテゴリの組合せの場合は、1,Y,,Yになります。)
ファイルを保存して閉じます。
file_Project_Cost_Burden_TypeCatSub_psft.csvファイル(データ・ファイル)を構成するには:
file_Project_Cost_Burden_TypeCatSub_psft.csvファイルを編集します。
注意: このタスクの構成ファイル(複数の場合もあり)は、Oracle BI Applicationsインストールの次の場所にあります。 ソース独立ファイル: <Oracle Home for BI>\biapps\etl\data_files\src_files\。 ソース固有ファイル: <Oracle Home for BI>\biapps\etl\data_files\src_files\<source adaptor>。 システム管理者は、これらのファイルを別の場所にコピーして、この場所から読み取るためのODI接続を構成しているはずです。システム管理者に、これらのファイルの取得を依頼してください。構成が完了したら、システム管理者は、構成済ファイルをODIの読取り元にコピーする必要があります。 |
プロジェクト原価間接費と見なされるリソース・タイプ、リソース・カテゴリ、リソース・サブカテゴリの組合せのリストを入力します。形式は次のとおりです。
XXXXX,XXXXX,XXXXX,1
XXXXXは、リソース・タイプ、リソース・サブカテゴリ、リソース・サブカテゴリの各組合せを表しています。
1は、間接費であることを示す戻り値です。参照値の組合せをそれぞれ指定する必要があります。ワイルドカードはサポートされていません。
次に、ソース・タイプがG&AまたはFRNGである原価をプロジェクト原価間接費として分類する方法の例を示します。
G&A,,,1
FRNG,,,1
注意: このCSVファイルはfile_Project_Cost_Burden_TypeCatSub_config_psft.csv構成ファイルと組み合せて使用します。この例では、この構成ファイルに値1,Yが格納されます。
ファイルを保存して閉じます。
E-Business Suite用のOracle Project Analyticsには、プロジェクト取引約定についてのレポートする機能を提供する、プロジェクト取引約定サブジェクト領域が含まれています。プロジェクト取引約定には、組織、プロジェクト、タスク、リソース、サプライヤおよび関連する階層に向けた購買依頼、発注、サプライヤ請求書の合計直接金額と総原価額が含まれます。このサブジェクト領域では、取引約定を取引約定ドキュメントのレベルで追跡できます。
Oracle Business Analytics Warehouseには、プロジェクト取引約定サブジェクト領域をサポートするためのスター・スキーマが含まれています。このスターには、すべての取引約定とその構成要素についてレポートするためのメトリックが含まれています。このメトリックには、購買依頼、発注、サプライヤ請求書の数量と金額(直接額および間接額)が含まれています。
スター・スキーマの中央に位置するW_PROJ_COMMITMENT_Fファクト表には、トランザクション・ソースPA_COMMITMENT_TXNSから取得された最新の取引約定データが格納されます。
取引約定スナップショットの構成
一時的な取引約定データであるスナップショット表W_PROJ_COMMITMENT_SNP_Fにデータが移入されます。このスナップショット表のデータの単位は、ETLパラメータPROJ_COMMITMENT_GRAINで制御します。このパラメータはFSMで設定します。有効な値は、WEEK、MONTH、QUARTERおよびYEARです。例: PROJ_COMMITMENT_GRAIN = 'WEEK'は、毎週1つのスナップショットがスナップショット表に格納されることを意味します。そのため、1週間に2回以上ETLを実行すると、その週の週末になるまで古いスナップショットが上書きされて、最新のスナップショットが維持されます。金曜日のレコードが維持されるようになり、その次の月曜に新しい週の新しいレコードが生成されます。この単位は、タスクを使用してFSMで指定します。デフォルトは、'Month'に設定されています。
この変数にFSMで値を設定するには、「データ・ロード・パラメータの管理」セクションに移動します(Oracle Project Analyticsを提供するためのフィルタ)。
目的
勤怠管理 - レポート時間ディメンションには、多数の勤怠管理メトリックで使用される、いくつかの適合ドメインが含まれています。これらのドメインは、適切に構成してレポートに正確な情報が含まれるようにする必要があります。詳細は、次の各項を参照してください。
オプションまたは必須
このタスクはオプションです。デフォルト値で、目的のビジネス要件が満たされる可能性があります。
適用対象
E-Business Suite、およびPeopleSoft。
詳細なタスクの説明
勤怠時間 - レポート時間ディメンションのドメインを構成することは、ウェアハウスのレポート単位、記録タイプ、およびE-Business Suiteのフレックスフィールド属性に時間レポートのエントリが正常に帰属するための鍵になります。
このタスクはオプションです。デフォルト値で、目的のビジネス要件が満たされる可能性があります。
ソース時間入力単位コードを付属のターゲット・タイムカード単位コード・ドメイン・メンバーにマップする方法を指定するために使用します。ターゲット・ドメインは拡張可能です。このドメインへの追加は可能ですが、削除はできません。
E-Business Suiteの例
ソース時間入力単位コードは、現時点では、常にHOURSになると想定されています。
実装の例
このタスクはオプションです。デフォルト値で、目的のビジネス要件が満たされる可能性があります。
ソース時間入力単位コードを付属のターゲット・タイムカード単位コード・ドメイン・メンバーにマップする方法を指定するために使用します。ターゲット・ドメインは拡張可能です。このドメインへの追加は可能ですが、削除はできません。
このドメインは、複数コード・ドメイン・メンバー・タイプです。これは、2つのソース・ドメイン(ソースTRCタイプ・コードとソース単位)を組み合せて、1つのターゲット・ドメインにマッピングするために使用します。
PeopleSoftの例
ソースTRCタイプ・コード
PeopleSoftでは、ソースTRCタイプ・コードはPSXLATITEM TRC_TYPE_CODEです。
ソース単位(UOM)
PeopleSoftでは、ソース単位はPSXLATITEMです。
実装の例
このタスクはオプションです。デフォルト値で、目的のビジネス要件が満たされる可能性があります。
ソース・タイムカード・パンチ・タイプ・コードを付属のタイムカード・パンチ・タイプ・コード・ドメイン・メンバーにマップする方法を指定するために使用します。ターゲット・ドメインは拡張可能です。このドメインへの追加は可能ですが、削除はできません。
E-Business Suiteの例
ソース・タイムカード・パンチ・タイプ・コードは、現時点では、常にELAPSEDになると想定されています。
実装の例
表B-31 ソース・メンバー・コードとターゲット・メンバー・コード
ソース・メンバー・コード(名前) | ターゲット・メンバー・コード(名前) |
---|---|
ELAPSED (経過時間) |
ELAPSED (ELAPSED) |
PeopleSoftの例
ソースTRCタイプ・コード
PeopleSoftでは、ソース・タイムカード・パンチ・タイプ・コードはPSXLATITEM PUNCH_TYPEです。
実装の例
表B-32 ソース・メンバー・コードとターゲット・メンバー・コード
ソース・メンバー・コード(名前) | ターゲット・メンバー・コード(名前) |
---|---|
0 (経過時間) |
ELAPSED (ELAPSED) |
1 (始業) |
IN (始業) |
2 (終業) * |
OUT (終業) |
3 (食事) |
MEAL (食事) |
4 (休憩) |
BRK (休憩) |
5 (移動) |
XFR (移動) |
* データ量を削減するため、記録時刻「終業」はOracle Business Analytics Warehouseに抽出されません。
このタスクはオプションです。デフォルト値で、目的のビジネス要件が満たされる可能性があります。
ソース・タイムカード詳細属性付加フレックスフィールドを付属のタイムカード詳細フレックス属性ドメイン・メンバーにマップする方法を指定するために使用します。ターゲット・ドメインは拡張可能です。このドメインへの追加は可能ですが、削除はできません。
E-Business Suiteの例
ソース・タイムカード詳細属性付加フレックスフィールドには、次の項目が含まれています。
レイアウトID (LAYOUT_ID)
ATTRIBUTE_CATEGORY (HXC_TIME_ATTRIBUTES)
付加フレックスフィールド列(例: ATTRIBUTE2)
ソース・タイムカード詳細属性付加フレックスフィールド・ドメインは、ドメイン・タスクSDE_ORA_DESCRIPTIVEFLEXFIELD_COLUMN_TIMECARDLAYOUTでロードされている必要があります。
実装の例
表B-33 ソース・メンバー・コードとターゲット・メンバー・コード
ソース・メンバー・コード(名前) | ターゲット・メンバー・コード(名前) |
---|---|
シード済マッピングはありません。「関連する変数」を参照してください HR_TIMECARD_FLEX_MAP_ELEMENT_TYPE_ID |
ELEMENT_TYPE_ID_CHAR |
シード済マッピングはありません。「関連する変数」を参照してください HR_TIMECARD_FLEX_MAP_HR_ORG_ID |
HR_ORG_ID_CHAR |
シード済マッピングはありません。「関連する変数」を参照してください HR_TIMECARD_FLEX_MAP_JOB_ID |
JOB_ID_CHAR |
シード済マッピングはありません。「関連する変数」を参照してください HR_TIMECARD_FLEX_MAP_PAY_GRADE_ID |
PAY_GRADE_ID_CHAR |
シード済マッピングはありません。「関連する変数」を参照してください HR_TIMECARD_FLEX_MAP_POSITION_ID |
POSITION_ID_CHAR |
シード済マッピングはありません。「関連する変数」を参照してください HR_TIMECARD_FLEX_MAP_LOCATION_ID |
LOCATION_ID_CHAR |
シード済マッピングはありません。「関連する変数」を参照してください HR_TIMECARD_FLEX_MAP_COST_CENTER_ID |
COST_CENTER_ID_CHAR |
11:PROJECTS:ATTRIBUTE1 プロジェクト・タイムカード・レイアウト - プロジェクトID (文字) |
PROJECT_ID_CHAR |
11:PROJECTS:ATTRIBUTE2 プロジェクト・タイムカード・レイアウト - タスクID (文字) |
TASK_ID_CHAR |
11:PROJECTS:ATTRIBUTE3 プロジェクト・タイムカード・レイアウト - 支出タイプ(文字) |
EXP_TYPE_ID_CHAR |
シード済マッピングはありません。「関連する変数」を参照してください HR_TIMECARD_FLEX_MAP_BILLABLE_FLG |
BILLABLE_FLAG_CHAR |
シード済マッピングはありません。「関連する変数」を参照してください HR_TIMECARD_FLEX_MAP_PO_NUMBER |
PO_NUMBER |
1198:PURCHASING:ATTRIBUTE8 プロジェクト・タイムカード・レイアウト - POヘッダーID (文字) |
PO_HEADER_ID |
1198:PURCHASING:ATTRIBUTE8 プロジェクト-購買タイムカード・レイアウト - PO明細ID (文字) |
PO_LINE_ID |
シード済マッピングはありません。「関連する変数」を参照してください HR_TIMECARD_FLEX_MAP_BUSINESS_GROUP_ID |
BUSINESS_GROUP_ID_CHAR |
シード済マッピングはありません。「関連する変数」を参照してください HR_TIMECARD_FLEX_MAP_PEOPLE_GROUP_ID |
PEOPLE_GROUP_ID_CHAR |
シード済マッピングはありません。「関連する変数」を参照してください HR_TIMECARD_FLEX_DET_ATTR1_CHAR |
FLEX_DET_ATTR1_CHAR |
シード済マッピングはありません。「関連する変数」を参照してください HR_TIMECARD_FLEX_DET_ATTR2_CHAR |
FLEX_DET_ATTR2_CHAR |
シード済マッピングはありません。「関連する変数」を参照してください HR_TIMECARD_FLEX_DET_ATTR3_CHAR |
FLEX_DET_ATTR3_CHAR |
シード済マッピングはありません。「関連する変数」を参照してください HR_TIMECARD_FLEX_DET_ATTR4_CHAR |
FLEX_DET_ATTR4_CHAR |
シード済マッピングはありません。「関連する変数」を参照してください HR_TIMECARD_FLEX_DET_ATTR5_CHAR |
FLEX_DET_ATTR5_CHAR |
シード済マッピングはありません。「関連する変数」を参照してください HR_TIMECARD_FLEX_DET_ATTR6_CHAR |
FLEX_DET_ATTR6_CHAR |
シード済マッピングはありません。「関連する変数」を参照してください HR_TIMECARD_FLEX_DET_ATTR7_CHAR |
FLEX_DET_ATTR7_CHAR |
シード済マッピングはありません。「関連する変数」を参照してください HR_TIMECARD_FLEX_DET_ATTR8_CHAR |
FLEX_DET_ATTR8_CHAR |
シード済マッピングはありません。「関連する変数」を参照してください HR_TIMECARD_FLEX_DET_ATTR9_CHAR |
FLEX_DET_ATTR9_CHAR |
シード済マッピングはありません。「関連する変数」を参照してください HR_TIMECARD_FLEX_DET_ATTR10_CHAR |
FLEX_DET_ATTR10_CHAR |
関連する変数
それぞれのターゲット・ドメイン・コードには、関連するODI変数があります(この変数のリストは、後出の表を参照)。各変数には、デフォルト値が設定されています。多くの場合、シード済のOracle E-Business勤怠管理エンジン・タイムカード・レイアウトは、この値で適切にマッピングされています。
マップされるドメインのCase文式は、次の形式の変数リフレッシュにより、Oracle Business Analytics Warehouseの表W_FLEX_SQL_Gから取得されます。
マップされるドメインのCase文式は、次の形式の変数リフレッシュにより、Oracle Business Analytics Warehouseの表W_FLEX_SQL_Gから取得されます。
SELECT COLUMN_EXPRESSION FROM W_FLEX_SQL_G WHERE DOMAIN_CODE = 'W_FLEX_TIMECARD_DETAIL_ATTRIBUTES' AND DOMAIN_MEMBER_CODE = '<Target Domain Code>' AND DATASOURCE_NUM_ID = #DATASOURCE_NUM_ID
次の表に、変数名とデフォルト式のリストを示します。
表B-34 変数名とデフォルト式
変数名 | デフォルト式 | BIACMからのリフレッシュ* |
---|---|---|
HR_TIMECARD_FLEX_MAP_ELEMENT_TYPE_ID |
SUBSTR(HA.ATTRIBUTE_CATEGORY,1,7) = 'ELEMENT' THEN SUBSTR(HA.ATTRIBUTE_CATEGORY,LENGTH('ELEMENT - ') +1) |
Y |
HR_TIMECARD_FLEX_MAP_BUSINESS_GROUP_ID |
WHEN HA.ATTRIBUTE_CATEGORY = 'SECURITY' THEN HA.ATTRIBUTE2 |
Y |
HR_TIMECARD_FLEX_MAP_HR_ORG_ID |
WHEN HA.ATTRIBUTE_CATEGORY = 'SECURITY' THEN HA.ATTRIBUTE1 |
Y |
HR_TIMECARD_FLEX_MAP_JOB_ID |
WHEN 1=0 THEN NULL |
Y |
HR_TIMECARD_FLEX_MAP_POSITION_ID |
WHEN 1=0 THEN NULL |
Y |
HR_TIMECARD_FLEX_MAP_LOCATION_ID |
WHEN 1=0 THEN NULL |
Y |
HR_TIMECARD_FLEX_MAP_PEOPLE_GROUP_ID |
WHEN 1=0 THEN NULL |
Y |
HR_TIMECARD_FLEX_MAP_PO_HEADER_ID |
WHEN HA.ATTRIBUTE_CATEGORY = 'PURCHASING' THEN HA.ATTRIBUTE8 |
Y |
HR_TIMECARD_FLEX_MAP_PO_LINE_ID |
WHEN HA.ATTRIBUTE_CATEGORY = 'PURCHASING' THEN HA.ATTRIBUTE2 |
Y |
HR_TIMECARD_FLEX_MAP_PO_NUMBER |
WHEN HA.ATTRIBUTE_CATEGORY = 'PURCHASING' THEN HA.ATTRIBUTE1 |
Y |
HR_TIMECARD_FLEX_MAP_COST_CENTER_ID |
WHEN HA.ATTRIBUTE_CATEGORY = 'Dummy Cost Context' THEN HA.ATTRIBUTE1 |
Y |
HR_TIMECARD_FLEX_MAP_PROJECT_ID |
WHEN HA.ATTRIBUTE_CATEGORY = 'PROJECTS' THEN HA.ATTRIBUTE1 |
Y |
HR_TIMECARD_FLEX_MAP_TASK_ID |
WHEN HA.ATTRIBUTE_CATEGORY = 'PROJECTS' THEN HA.ATTRIBUTE2 |
Y |
HR_TIMECARD_FLEX_MAP_EXPENDITURE_TYPE_ID |
WHEN HA.ATTRIBUTE_CATEGORY = 'PROJECTS' THEN HA.ATTRIBUTE3 |
Y |
HR_TIMECARD_FLEX_MAP_BILLABLE_FLG |
WHEN HA.ATTRIBUTE_CATEGORY = 'PROJECTS' THEN HA.ATTRIBUTE7 |
Y |
HR_TIMECARD_FLEX_MAP_APPOVED_DATE |
DECODE(HA.ATTRIBUTE_CATEGORY,'APPROVAL',DECODE(TRANSLATE(HA.ATTRIBUTE5, '0123456789', '0000000000'), '0000/00/00 00:00:00', FND_DATE.CANONICAL_TO_DATE(HA.ATTRIBUTE5))) |
N |
HR_TIMECARD_FLEX_MAP_APPOVER_ID |
DECODE(HA.ATTRIBUTE_CATEGORY,'APPROVAL',HA.ATTRIBUTE3) |
N |
HR_TIMECARD_FLEX_MAP_CLA_COMMENTS |
WHEN HA.ATTRIBUTE_CATEGORY = 'REASON' THEN HA.ATTRIBUTE2 |
Y |
HR_TIMECARD_FLEX_MAP_CLA_REASON |
WHEN HA.ATTRIBUTE_CATEGORY = 'REASON' THEN HA.ATTRIBUTE1 |
Y |
HR_TIMECARD_FLEX_MAP_CLA_TYPE |
WHEN HA.ATTRIBUTE_CATEGORY = 'REASON' THEN HA.ATTRIBUTE3 |
Y |
HR_TIMECARD_FLEX_DET_ATTR1_CHAR, HR_TIMECARD_FLEX_DET_ATTR2_CHAR and so on to HR_TIMECARD_FLEX_DET_ATTR10_CHAR |
WHEN 1=0 THEN NULL |
Y |
* BIACMとは、Oracle BI Applications構成マネージャのことです。
注意: これらの代替変数の式(またはドメイン生成の式)に使用するODIインタフェース/式では、式をCASE文ロジックで囲みます。つまり、次のようになります。
デフォルト(ドメイン・マッピングなし):
CASE WHEN 1=0 THEN NULL END
ソース→ターゲット・ドメインのマッピングを使用:
WHEN TC.LAYOUT_ID = 11 AND HA.ATTRIBUTE_CATEGORY = 'PROJECTS' THEN HA.ATTRIBUTE2 WHEN TC.LAYOUT_ID = 123456 AND HA.ATTRIBUTE_CATEGORY = 'PROJECTS' THEN HA.ATTRIBUTE3 ..
PeopleSoftの例
この機能は、PeopleSoftには適用されません。
Fusionの例
この機能は、Fusion Applicationsには適用されません。
目的
不良データには、永続化ステージング・レイヤーのワークフォースETLプロセスで処理されるものがあります。この不良データは、エラーを発生させるのではなく無効のフラグを設定して、Oracle Business Analytics Warehouseから除外します。不良データがOLTPでクリーンアップされた場合は、不良データを再処理するための再検証オプションを使用して、そのデータが有効な場合はOracle Business Analytics Warehouseに含まれるようにします。
オプションまたは必須
このタスクはオプションです。ただし、デフォルトのオプションでは、常に不良データを再処理します。この再処理は、不良データをクリーンアップする予定がない場合は、わずかなオーバーヘッドになります。
適用対象
すべてのソース。
詳細なタスクの説明
パラメータHR_WRKFC_REVALIDATEを設定します。対応するETLタスクのうち影響を受けるものは、SDE%Workforce%Validate%を検索することで見つかります。無効なデータは、VALID_FLG = 'N'のマークが付いたレコードをクリックすることで再確認できます。実装されている表と確認は、後出のリストに示します。
表B-35 E-Business Suite
永続化ステージング表 | 除外される不良データのタイプ |
---|---|
アサイメント - W_ORA_WEVT_ASG_PS |
重複している有効日 重複しているアクティブなプライマリ・アサイメント |
常勤換算 - W_ORA_WEVT_FTE_PS |
重複している有効日 |
等級レート - W_ORA_WEVT_GRT_PS |
重複している有効日 |
ヘッドカウント - W_ORA_WEVT_HDC_PS |
重複している有効日 |
考課 - W_ORA_WEVT_PERF_PS |
個人/アサイメントごとに1日に複数の評価 |
個人 - W_ORA_WEVT_PSN_PS |
重複している有効日 |
個人タイプ - W_ORA_WEVT_PTYP_PS |
重複している有効日 |
給与 - W_ORA_WEVT_SAL_PS |
重複している有効日 |
表B-36 Peoplesoft
永続化ステージング表 | 除外される不良データのタイプ |
---|---|
ヘッドカウント - W_PSFT_WEVT_HDC_PS |
重複しているアクティブなプライマリ・アサイメント |
考課 - W_PSFT_WEVT_PERF_PS |
個人/アサイメントごとに1日に複数の評価 |
表B-37 Fusion
永続化ステージング表 | 除外される不良データのタイプ |
---|---|
アサイメント - W_FSN_WEVT_ASG_PS |
重複している有効日 重複しているアクティブなプライマリ・アサイメント |
考課 - W_FSN_WEVT_PERF_PS |
個人/アサイメントごとに1日に複数の評価 |
給与 - W_FSN_WEVT_SAL_PS |
重複している有効日 |
監督者 - W_FSN_WEVT_SUP_PS |
重複している有効日 |
依存関係
依存関係はありません。
目的
このタスクは、Recruitment Analyticsにとって重要な構成手順です。このタスクにより、採用パイプラインのソース・ステータス(ジョブ求人ステータスと応募者ステータスの両方)と、それらのソース・ステータスに関連付けられたソース事由から、ウェアハウス適合ドメインのセットへのドメイン・メンバー・マッピングが簡単に構成できるようになります。これらの付属のウェアハウス適合ドメインには、採用イベント、採用イベント事由、採用イベント事由タイプ、採用サブステージ、採用ステージ、応募者イベント・フラグおよびジョブ求人イベント・フラグが含まれます。
付属のウェアハウス適合ドメイン間には既存の関係があり、デフォルトのメンバー・マッピングはシステムですでに構成されています。それらの変更を望まない場合は、変更しなくてもかまいません。ただし、このタスクの主な目的は、ソース・ドメイン・メンバー(ステータスと事由)がウェアハウス適合ドメインに有意義にマップされている確認することにあります。
オプションまたは必須
このタスクは、Recruitment Analyticsに必須の構成手順です。
予備知識
実際のタスクを始める前に、ドメイン間に存在する関係/マッピングについて明確にすることが重要です。
ウェアハウス適合ドメイン間のドメイン・メンバー・マッピングは、デフォルトでシードされています。デフォルトの設定が目的のビジネス・ニーズを満たしている場合は、それ以上の構成は必要ありません。
Recruitment Analyticsのメトリックは、ウェアハウス適合ドメインの採用イベント、採用サブステージおよび採用ステージに強く依存しています。採用プロセスでは、特定のアクティビティ/イベントに応じて、応募プロセス(またはジョブ求人プロセス)のステータスを変更できます。採用プロセス・パイプラインを進めているときには、特定の応募(またはジョブ求人)が特定のステージに入る、またはステージから出て新しいステージに入ることと考えることができます(ステージは、全体的なプロセスでの応募の場所を示します)。各ステージは、より詳細な分析のためのサブステージに分類できます。たとえば、応募者は一次選考が行われ(サブステージ = INITIAL_SCREENING)、適格な応募者は筆記テストに回され(サブステージ = ASSESSMENT)、合格した応募者は面接を受けます(サブステージ = INTERVIEW)。おおまかに考えると、候補者は2つの主要ステージ(INITIAL_SCREENINGとASSESSMENT)を通過していることになります。この例では、デフォルトのドメイン・メンバー・マッピングの構成方法は次のようになります。
サブステージからステージへのマップ
表B-38 サブステージからステージへのマップ
採用サブステージ(ウェアハウス適合) | 採用ステージ(ウェアハウス適合) |
---|---|
INITIAL_SCREENING |
INITIAL_SCREENING |
ASSESSMENT |
ASSESSMENT |
INTERVIEW |
ASSESSMENT |
応募は、なんらかのイベントの発生でステージまたはサブステージに入るか、それらのステージから出ることになります。ウェアハウス適合ドメイン「採用イベント」を「サブステージ」にマッピングするときには、実際には「原因と結果」を連結することになります。応募がINITIAL_SCREENINGサブステージに入る可能性のあるイベントについて考えてみます。まず、応募受理の後で一次審査を実施します。ドメイン「採用イベント」に対するシード済の値は「応募受理」になります。これが、「結果」をトリガーする「原因」(つまりイベント)です。その他いくつかについて、次に示します。
採用イベントからサブステージへのマップ
表B-39 採用イベントからサブステージへのマップ
採用サブステージ(ウェアハウス適合) | 採用ステージ(ウェアハウス適合) |
---|---|
APPLICATION_RECEIVED |
INITIAL_SCREENING |
ASSESSMENT_START |
ASSESSMENT |
ASSESSMENT_INTERVIEW |
INTERVIEW |
ASSESSMENT_INTERVIEW1 |
INTERVIEW |
ASSESSMENT_INTERVIEW2 |
INTERVIEW |
これらは、少数のウェアハウス適合ドメイン・メンバー・マッピングを示す単なる例であり、採用パイラインのステージとサブステージ、および関連するイベントについてのトピックを紹介することを目的としています。前述したように、これらのマッピングは変更の必要がありません。ただし、提供されている内容が目的のビジネス要件を満たさない場合は変更が必要になります。ウェアハウス適合ドメイン・メンバー・マッピングの完全なリストは、このヘルプ・トピックの最後に情報提供を目的として掲載されています(「追加情報」の項を参照)。
ソースからウェアハウス適合ドメイン・メンバーへのマッピングについての説明に移る前に、それ以外の2つのウェアハウス適合ドメイン・マッピングについて簡単に説明します。この時点では、それらの例は示しません。簡単に触れるだけにします。
採用イベントから採用イベント順序へのマップ
ウェアハウス適合採用イベントは、数値による順序設定を使用することで順序付けできます。これにより、ビジネス・ユーザーは採用プロセスをより明確に確認できるようになります。一部のビジネスでは、このプロセスの最後(採用の直前)に身辺調査を実施することがあります。その他のビジネスでは、アセスメント・ステージで身辺調査を実施します。採用イベントの順序は、採用分析データの処理に関してはほとんど問題にはなりませんが、レポート目的としては役に立つことがあります。
採用イベント事由から採用イベント事由タイプへのマップ
採用イベントとは、採用パイラインにおけるステータス変更の「原因」であり、通常は、そのイベントについての「事由」が存在します。たとえば、応募中止は、候補者がどこかで別の仕事を見つけたという理由で発生することがあります。この場合は、「他社に就職」が事由になります。ソースの事由をウェアハウス適合の採用イベント事由にマッピングする方法については後述しますが、Recruitment Analyticsには採用イベント事由タイプによる上位レベルの分析単位が用意されています。この「タイプ」レベルでは、主に、採用イベント事由を3つのバケットVOLUNTARY、INVOLUNTARY、またはOTHER (判別できない場合)に分割することを試行します。ここで説明した事例では、候補者が別の仕事に就いたために、応募が自己都合で中止されたことになります。
タスクの説明
ここでは、実際のタスクについて説明します。このタスクでは、ソース・ドメイン・メンバーを異なるウェアハウス適合ドメイン・メンバーにマッピングします。「ソース採用ステータスおよびイベント事由から採用イベント」と「ソース採用イベント事由から採用イベント事由」のマッピングは、すでにデフォルトのソリューションに存在しています。そのため、これらのドメイン・マッピングは作成する必要はありません。これらのドメイン間のドメイン・メンバー・マッピングを実施する必要があります。
ステータスをイベントに正確にマップするには、事由をステータスに関連付ける必要があります。これは、両方のソース(ステータスと事由)を1つにまとめて、ウェアハウス適合イベントとウェアハウス適合イベント事由へのマッピングに使用する必要がある(また、マッピングに使用できる)理由になります。
ソース採用ステータスおよびイベント事由から採用イベントへのマップ
ソース採用ステータスおよびイベント事由(またはステータスのみ)から採用イベント・ドメインへのマッピングは、E-Business SuiteとPeopleSoftでは異なります。2つの専用のドメイン値が提供されています。E-Business Suite用のドメイン値(DOMAIN_CODE = ASSIGNMENT_SYSTEM_STATUS~ASSIGNMENT_USER_STATUS~RECRUITMENT_EVENT_REASON)と、PeopleSoft用のドメイン値(CODE = RECRUITMENT_STATUS)です。これらについては個別に説明しますが、全体的な目的は同じです。つまり、ソースのステータスおよび事由を採用イベント・ドメインのウェアハウス適合値のいずれかにマッピングするということです。
E-Business Suiteアプリケーション:
この場合、応募者アサイメントの正しいステータスは、PER_ASSINGMENT_STATUS_TYPES表のシステム・ステータスとユーザー・ステータスから推測できます。応募者のステータスのみを考慮に入れるために、システム・ステータスには、リスト('ACTIVE_APL','INTERVIEW1','INTERVIEW2', 'OFFER', 'ACCEPTED')に対するフィルタを適用します。事由は、HR_STANDARD_LOOKUPS.LOOKUP_TYPE = 'APL_ASSIGN_REASON'から取得して、考えられるすべての応募者ステータスでタグを付けます。同様に、応募中止のステータスには、システム・ステータス'TERM_APL'と事由'TERM_APL_REASON'を使用します。これら2つのタイプは、「応募者イベント」になります。さらに、必要要員ステータス(HR_STANDARD_LOOKUPS.LOOKUP_TYPE = 'VACANCY_STATUS')も取得します。必要要員ステータスには関連付ける事由がないため、必要要員事由の代替として「未指定」を使用します。要するに、E-Business Suiteのソース・ドメインのセットには、応募アサイメントのステータスと事由、応募中止のステータスと事由(「未指定」のみ)に応じたメンバーを含めるということです。これらのソース・ドメイン・メンバーは、採用イベントのウェアハウス適合ドメインのいずれかのメンバーにマッピングすることになります。
採用イベントのドメイン値にマッピングする付属のE-Business Suiteソース・ドメインについてのリストを次に示します。ソースのE-Business Suite iRecruitment構成における実際値に基づいて、適切なマッピングを調べて構成する必要があります。
表B-40 (EBS)ソース採用ステータスおよびイベント事由(ソース・ドメイン)から採用イベント(ウェアハウス適合)メンバーへのマッピング
ソース・メンバー・コード | ターゲット・メンバー | ターゲット・メンバー・コード |
---|---|---|
__ANY__ |
その他のイベント |
OTHER |
ACCEPTED~__ANY__~__ANY__ |
オファー受入済 |
OFFER_ACCEPTED |
ACTIVE_APL~__ANY__~__ANY__ |
応募受理 |
APPLICATION_RECEIVED |
INTERVIEW1~__ANY__~__ANY__ |
アセスメント面接 |
ASSESSMENT_INTERVIEW |
INTERVIEW2~__ANY__~__ANY__ |
アセスメント二次面接 |
ASSESSMENT_INTERVIEW2 |
OFFER~__ANY__~__ANY__ |
オファー提示済 |
OFFER_EXTENDEDTERM_APL~__ANY__~__ANY__ |
TERM_APL~__ANY__~__ANY__ |
応募終了 |
APPLICATION_TERMINATED |
PeopleSoftアプリケーション:
ステータス(ステータス領域を含む)は、採用イベントを正しく特定するために必要になります。PS_HRS_STS_TBLでは、ステータス領域ごとの有効なステータスの組合せを追跡します。また、この表はソース・ドメイン・メンバーのプライマリ・ソースになります。応募者のステータス(STATUS_AREA = 3)とジョブ求人ステータス(STATUS_AREA = 1)は、どちらもソース・ドメイン・メンバーとして取り入れます。この組合せを、ウェアハウス適合の採用イベント・ドメイン・メンバーにマッピングする必要があります。
次の表に、付属のメンバー・マッピングの例のセットを示します。PeopleSoft構成における実際値に基づいて、適切なマッピングを調べて構成する必要があります。
表B-41 PeopleSoftのソース採用ステータスおよびイベント事由(ソース・ドメイン)から採用イベント(ウェアハウス適合)メンバーへのマッピング
ソース・メンバー | ソース・メンバー・コード | ターゲット・メンバー | ターゲット・メンバー・コード |
---|---|---|---|
応募 |
3~020 |
応募受理 |
APPLICATION_RECEIVED |
キャンセル |
1~120 |
求人取消 |
RQSTN_CANCELLED |
クローズ |
1~110 |
求人補充済またはクローズ済 |
RQSTN_FILLED_CLOSED |
却下 |
1~008 |
求人承認拒否 |
RQSTN_APPROVAL_DENIED |
却下 |
3~008 |
応募終了 |
APPLICATION_TERMINATED |
ドラフト |
1~005 |
求人起案 |
RQSTN_DRAFTED |
ドラフト |
3~005 |
応募受理 |
APPLICATION_RECEIVED |
採用決定 |
3~078 |
オファー提示済 |
OFFER_EXTENDED |
採用済 |
3~090 |
採用 |
HIRE |
保留 |
1~100 |
求人保留中 |
RQSTN_HOLD |
保留 |
3~100 |
非パイプライン・イベント |
NON_PIPELINE |
非アクティブ |
3~140 |
非パイプライン・イベント |
NON_PIPELINE |
面接 |
3~060 |
アセスメント面接 |
ASSESSMENT_INTERVIEW |
リンク |
3~015 |
応募受理 |
APPLICATION_RECEIVED |
関連質問 |
3~019 |
応募受理 |
APPLICATION_RECEIVED |
提示条件 |
3~070 |
オファー提示済 |
OFFER_EXTENDED |
提示条件受諾 |
3~071 |
オファー受入済 |
OFFER_ACCEPTED |
募集中 |
1~010 |
求人開示済 |
RQSTN_OPEN |
保留 |
1~006 |
求人承認保留 |
RQSTN_APPROVAL_PENDING |
内定受諾 |
3~076 |
オファー受入済 |
OFFER_ACCEPTED |
内定決定 |
3~069 |
オファー提示済 |
OFFER_EXTENDED |
内定通知 |
3~075 |
オファー提示済 |
OFFER_EXTENDED |
内定辞退 |
3~077 |
オファー提示済 |
OFFER_EXTENDED |
採用準備完了 |
3~080 |
オファー受入済 |
OFFER_ACCEPTED |
不採用 |
3~110 |
応募終了 |
APPLICATION_TERMINATED |
レビュー |
3~010 |
応募受理 |
APPLICATION_RECEIVED |
書類選考 |
3~050 |
アセスメント開始 |
ASSESSMENT_START |
予備選考 |
3~030 |
アセスメント開始 |
ASSESSMENT_START |
取消 |
3~120 |
応募終了 |
APPLICATION_TERMINATED |
ソース採用イベント事由から採用イベント事由タイプへのマップ
E-Business SuiteアプリケーションとPeopleSoftアプリケーションでは、ソース・ドメインのソース採用イベント事由(RECRUITMENT_EVENT_REASON)のメンバーにより、すべての欠員ステータスと応募者ステータスの事由が構成されます。E-Business Suiteでは、中止に関連するステータス事由をマッピングすることのみが必要になります(最小限)。その他の事由は、すべて、ターゲット・ドメイン・メンバーの「その他」にマッピングします。(これは、最小要件に過ぎないことに注意してください。その他の事由も、すべてマッピングできます)。PeopleSoftでは、ソース・メンバー(つまり事由)は、3つのコンポーネント(ステータス領域、ステータス、および事由)で形成されます。これら3つをまとめたものを適切なターゲット・ドメイン・メンバーの事由にマッピングすることが必要になります。これらのマッピングはデフォルトで存在していますが、それらは単なるサンプルとして扱われるものであり、独自のマッピングを指定することになります。次の表に、付属のメンバー・マッピングの例のセットを示します(情報提供のみを目的としています)。
表B-42 (すべてのソース)ソース採用イベント事由(ソース・ドメイン)から採用イベント事由(ウェアハウス適合)メンバー
ソース・メンバー | ソース・メンバー・コード | ターゲット・メンバー | ターゲット・メンバー・コード | 製品ライン |
---|---|---|---|---|
APPLICATON WITHDRAWN |
APL_ASSIGN_REASON:EBSTM WA |
応募取下 |
WITHDRAWN |
EBS |
APPLICATON WITHDRAWN |
APL_ASSIGN_REASON:WA |
応募取下 |
WITHDRAWN |
EBS |
APPLICATON WITHDRAWN |
TERM_APL_REASON:W |
応募取下 |
WITHDRAWN |
EBS |
いずれか |
__ANY__ |
その他 |
OTHER |
EBS |
DECLINED POSITION |
APL_ASSIGN_REASON:DEC |
不適格 |
INELIGIBLE |
EBS |
DECLINED POSITION |
APL_ASSIGN_REASON:EBSTM DEC |
不適格 |
INELIGIBLE |
EBS |
DECLINED POSITION |
TERM_APL_REASON:D |
不適格 |
INELIGIBLE |
EBS |
DECLINED POSITION |
TERM_APL_REASON:DEC |
不適格 |
INELIGIBLE |
EBS |
選抜なし |
3~110:150 |
面接で不適格 |
DISQUALIFIED |
PSFT |
その他の応募者を採用 |
3~110:010 |
開始に失敗 |
FAILED_TO_START |
PSFT |
他社に就職 |
3~110:190 |
他社に就職 |
ANOTHER_JOB |
PSFT |
資格なし - 基本資格 |
3~110:100 |
不適格 |
INELIGIBLE |
PSFT |
資格なし - 雇用条件 |
3~110:110 |
不適格 |
INELIGIBLE |
PSFT |
資格なし - 等級/給与下限 |
3~110:120 |
不適格 |
INELIGIBLE |
PSFT |
その他の必須資格なし |
3~110:130 |
不適格 |
INELIGIBLE |
PSFT |
必須資格証明書なし |
3~110:140 |
不適格 |
INELIGIBLE |
PSFT |
必須学歴なし |
3~110:090 |
不適格 |
INELIGIBLE |
PSFT |
必須職務経験なし |
3~110:160 |
不適格 |
INELIGIBLE |
PSFT |
詐称 |
3~110:070 |
面接で不適格 |
DISQUALIFIED |
PSFT |
欠員なし |
3~110:180 |
ヘッドカウント使用不可または採用凍結 |
HEADCOUNT_NOT_AVAILABLE |
PSFT |
面接欠席 |
3~110:060 |
面接に連絡なし不参加 |
NO_SHOW |
PSFT |
技能不適合 |
3~110:040 |
面接で不適格 |
DISQUALIFIED |
PSFT |
面接結果に問題 |
3~110:030 |
面接で不適格 |
DISQUALIFIED |
PSFT |
経営協議会による却下 |
3~110:200 |
オファー拒否済 |
OFFER_REJECTED |
PSFT |
経営協議会による却下 |
3~110:210 |
オファー拒否済 |
OFFER_REJECTED |
PSFT |
その他のポジションに選抜 |
3~110:080 |
他社に就職 |
ANOTHER_JOB |
PSFT |
連絡不可 |
3~110:020 |
面接に連絡なし不参加 |
NO_SHOW |
PSFT |
不適格 |
3~110:050 |
面接で不適格 |
DISQUALIFIED |
PSFT |
依存関係
デフォルトのOracle BI Applications - Recruitment Analyticsは、正確なドメイン・メンバーのマッピングとその他の構成に強く依存します。ドメイン・メンバー・マップに変更を加えた場合は、完全ロードETLを実施する必要があります。
拡張性
通常、ターゲット・ドメイン・メンバーには拡張性があります。ただし、Recruitment Analyticsの2つのターゲット・ドメイン「採用ステージ」と「採用サブステージ」には拡張性がありません。ETLロジックは、これら2つのターゲット・ウェアハウス・ドメインにドメイン値がシードされていることを想定していて、拡張や変更を行うと付属のETLロジックに変更を加えることが必要になります。
追加情報
次に、ウェアハウス適合ドメイン・メンバーのマッピングのリストを示します。前述したように、これらのマッピングは変更の必要がありません。ただし、これらのマッピング方法が目的のビジネス・ニーズを満たさない場合は変更が必要になります。
表B-43 採用イベント(ウェアハウス適合)から採用サブステージ(ウェアハウス適合)メンバーへのマッピング
ソース・メンバー | ソース・メンバー・コード | ターゲット・メンバー | ターゲット・メンバー・コード |
---|---|---|---|
応募受理 |
APPLICATION_RECEIVED |
初期スクリーニング |
INITIAL_SCREENING |
応募終了 |
APPLICATION_TERMINATED |
応募終了 |
APPLICATION_TERMINATED |
アセスメント一次面接 |
ASSESSMENT_INTERVIEW1 |
面接 |
INTERVIEW |
アセスメント面接 |
ASSESSMENT_INTERVIEW |
面接 |
INTERVIEW |
アセスメント二次面接 |
ASSESSMENT_INTERVIEW2 |
面接 |
INTERVIEW |
アセスメント開始 |
ASSESSMENT_START |
アセスメント |
ASSESSMENT |
最初の勤務期間の範囲完了後に雇用 |
EMP_FST_POW_COMPLETION |
最初の勤務期間の範囲より後の雇用 |
EMPLOYMENT_POST_POW1 |
初回考課/レビュー |
EMP_PERF_REVIEW |
最初の勤務期間の範囲より前の雇用 |
EMPLOYMENT_PRE_POW1 |
採用 |
HIRE |
最初の勤務期間の範囲より前の雇用 |
EMPLOYMENT_PRE_POW1 |
非パイプライン・イベント |
NON_PIPELINE |
非パイプライン |
NON_PIPELINE |
オファー受入済 |
OFFER_ACCEPTED |
開始保留 |
START_PENDING |
オファー提示済 |
OFFER_EXTENDED |
オファー |
OFFER |
その他のイベント |
OTHER |
非パイプライン |
NON_PIPELINE |
求人承認拒否 |
RQSTN_APPROVAL_DENIED |
求人承認拒否 |
RQSTN_APPROVAL_DENIED |
求人承認保留 |
RQSTN_APPROVAL_PENDING |
求人承認保留 |
RQSTN_APPROVAL_PENDING |
求人取消 |
RQSTN_CANCELLED |
求人取消 |
RQSTN_CANCELLED |
求人起案 |
RQSTN_DRAFTED |
求人起案 |
RQSTN_DRAFTED |
求人補充済またはクローズ済 |
RQSTN_FILLED_CLOSED |
求人補充済またはクローズ済 |
RQSTN_FILLED_CLOSED |
求人開示済 |
RQSTN_OPEN |
求人開示 |
RQSTN_OPEN |
求人保留中 |
RQSTN_HOLD |
求人保留中 |
RQSTN_HOLD |
最初の勤務期間の範囲完了の前に終了 |
EMP_TERMINATED |
雇用終了 |
EMPLOYMENT_TERMINATED |
最初の勤務期間の範囲完了の前に異動 |
EMP_TRANSFER |
最初の勤務期間の範囲より前の雇用 |
EMPLOYMENT_PRE_POW1 |
表B-44 採用サブステージ(ウェアハウス適合)から採用ステージ(ウェアハウス適合)メンバーへのマッピング
ソース・メンバー | ソース・メンバー・コード | ターゲット・メンバー | ターゲット・メンバー・コード |
---|---|---|---|
応募終了 |
APPLICATION_TERMINATED |
応募終了 |
APPLICATION_TERMINATED |
アセスメント |
ASSESSMENT |
アセスメント |
ASSESSMENT |
雇用終了 |
EMPLOYMENT_TERMINATED |
雇用終了 |
EMPLOYMENT_TERMINATED |
最初の勤務期間の範囲より前の雇用 |
EMPLOYMENT_PRE_POW1 |
雇用 |
EMPLOYMENT |
最初の勤務期間の範囲より後の雇用 |
EMPLOYMENT_POST_POW1 |
雇用 |
EMPLOYMENT |
初期スクリーニング |
INITIAL_SCREENING |
初期スクリーニング |
INITIAL_SCREENING |
面接 |
INTERVIEW |
アセスメント |
ASSESSMENT |
非パイプライン |
NON_PIPELINE |
非パイプライン |
NON_PIPELINE |
オファー |
OFFER |
オファー |
OFFER |
求人承認拒否 |
RQSTN_APPROVAL_DENIED |
求人拒否済 |
RQSTN_REJECTED |
求人承認保留 |
RQSTN_APPROVAL_PENDING |
求人保留 |
RQSTN_PENDING |
求人取消 |
RQSTN_CANCELLED |
求人クローズ済 |
RQSTN_CLOSED |
求人起案 |
RQSTN_DRAFTED |
求人保留 |
RQSTN_PENDING |
求人補充済またはクローズ済 |
RQSTN_FILLED_CLOSED |
求人クローズ済 |
RQSTN_CLOSED |
求人開示 |
RQSTN_OPEN |
求人開示 |
RQSTN_OPEN |
求人保留中 |
RQSTN_HOLD |
求人開示 |
RQSTN_OPEN |
開始保留 |
START_PENDING |
開始保留 |
START_PENDING |
表B-45 採用イベント(ウェアハウス適合)から採用イベント順序(ウェアハウス適合)メンバーへのマッピング
ソース・メンバー | ソース・メンバー・コード | ターゲット・メンバー | ターゲット・メンバー・コード |
---|---|---|---|
求人起案 |
RQSTN_DRAFTED |
10 |
10 |
求人承認保留 |
RQSTN_APPROVAL_PENDING |
20 |
20 |
求人承認拒否 |
RQSTN_APPROVAL_DENIED |
30 |
30 |
求人開示済 |
RQSTN_OPEN |
40 |
40 |
求人保留中 |
RQSTN_HOLD |
50 |
50 |
求人取消 |
RQSTN_CANCELLED |
60 |
60 |
求人補充済またはクローズ済 |
RQSTN_FILLED_CLOSED |
70 |
70 |
応募受理 |
APPLICATION_RECEIVED |
100 |
100 |
アセスメント開始 |
ASSESSMENT_START |
110 |
110 |
アセスメント面接 |
ASSESSMENT_INTERVIEW |
120 |
120 |
アセスメント一次面接 |
ASSESSMENT_INTERVIEW1 |
130 |
130 |
アセスメント二次面接 |
ASSESSMENT_INTERVIEW2 |
140 |
140 |
オファー提示済 |
OFFER_EXTENDED |
150 |
150 |
オファー受入済 |
OFFER_ACCEPTED |
170 |
170 |
応募終了 |
APPLICATION_TERMINATED |
190 |
190 |
採用 |
HIRE |
200 |
200 |
初回考課/レビュー |
EMP_PERF_REVIEW |
230 |
230 |
最初の勤務期間の範囲完了の前に異動 |
EMP_TRANSFER |
240 |
240 |
最初の勤務期間の範囲完了後に雇用 |
EMP_FST_POW_COMPLETION |
250 |
250 |
最初の勤務期間の範囲完了の前に終了 |
EMP_TERMINATED |
270 |
270 |
非パイプライン・イベント |
NON_PIPELINE |
1000 |
1000 |
その他のイベント |
OTHER |
1010 |
1010 |
表B-46 採用イベント事由(ウェアハウス適合)から採用イベント事由タイプ(ウェアハウス適合)メンバーへのマッピング
ソース・メンバー | ソース・メンバー・コード | ターゲット・メンバー | ターゲット・メンバー・コード |
---|---|---|---|
別のジョブ |
ANOTHER_JOB |
自己都合 |
VOLUNTARY |
応募取下 |
WITHDRAWN |
自己都合 |
VOLUNTARY |
面接で不適格 |
DISQUALIFIED |
会社都合 |
INVOLUNTARY |
開始に失敗 |
FAILED_TO_START |
自己都合 |
VOLUNTARY |
使用可能ヘッドカウント |
HEADCOUNT_AVAILABLE |
その他 |
OTHER |
ヘッドカウント使用不可または採用凍結 |
HEADCOUNT_NOT_AVAILABLE |
その他 |
OTHER |
不適格 |
INELIGIBLE |
会社都合 |
INVOLUNTARY |
面接に連絡なし不参加 |
NO_SHOW |
自己都合 |
VOLUNTARY |
オファー拒否済 |
OFFER_REJECTED |
会社都合 |
INVOLUNTARY |
未指定 |
UNSPECIFIED |
その他 |
OTHER |
PeopleSoftの取引約定サブジェクト領域は、PS_INSTALLATION_PC表にフィルタを適用することでソースから選別されます。これにより、購買オーダーと購買依頼の取引約定トランザクションについての分析タイプが、PeopleSoftで適切にマッピングされるようにします。
取引約定スナップショットの構成
一時的な取引約定データであるスナップショット表W_PROJ_COMMITMENT_SNP_Fにデータが移入されます。このスナップショット表のデータの単位は、ETLパラメータPROJ_COMMITMENT_GRAINで制御します。このパラメータはFSMで設定します。有効な値は、WEEK、MONTH、QUARTERおよびYEARです。例: PROJ_COMMITMENT_GRAIN = 'WEEK'は、毎週1つのスナップショットがスナップショット表に格納されることを意味します。そのため、1週間に2回以上ETLを実行すると、その週の週末になるまで古いスナップショットが上書きされて、最新のスナップショットが維持されます。金曜日のレコードが維持されるようになり、その次の月曜に新しい週の新しいレコードが生成されます。この単位は、FSMのタスクを使用して指定します。デフォルトは、'Month'に設定されています。
この変数にFSMで値を設定するには、「データ・ロード・パラメータの管理」セクションに移動します(Oracle Project Analyticsを提供するためのフィルタ)。
PeopleSoftにおける予算管理のRPDを設定するには:
Oracle BI EE管理ツールで、BIメタデータ・リポジトリ(例: OracleBIAnalyticsApps.rpd)を編集します。
このRPDファイルは、次の場所にあります。
ORACLE_INSTANCE\bifoundation\OracleBIServerComponent\coreapplication_obisn\repository
「ビジネス・モデル」および「マッピング」レイヤーで、論理表「ファクト - 最終 - GL仕訳予算管理」に移動します。
「ソース」で、論理表ソース「Fact_W_GL_OTHER_F_PSFT」を選択します。
「一般」タブで「無効」オプションを選択解除して、「OK」をクリックします。
論理表ソース「Fact_W_GL_OTHER_GRPACCT_DAY_A_PSFT」と「Fact_W_GL_OTHER_GRPACCT_FSCLPRD_A_PSFT」に対して、手順4を繰り返します。
「ソース」で、論理表ソース「Fact_W_GL_OTHER_F_EBS」を選択します。
「一般」タブで「無効」オプションを選択して、「OK」をクリックします。
論理表ソース「Fact_W_GL_OTHER_GRPACCT_DAY_A_EBS」と「Fact_W_GL_OTHER_GRPACCT_FSCLPRD_A_EBS」に対して、手順7を繰り返します。
「ビジネス・モデルとマッピング」レイヤーで、論理表「ファクト - 最終 - 活動予算管理」に移動します。
「ソース」で、論理表ソース「Fact_W_GL_BALANCE_F_PSFT」を選択します。
「一般」タブで「無効」オプションを選択解除して、「OK」をクリックします。
その他の論理表ソース「Fact_W_GL_BALANCE_A_PSFT」に対して、手順11を繰り返します。
「ソース」で、論理表ソース「Fact_W_GL_BALANCE_F_EBS」を選択します。
「一般」タブで「無効」オプションを選択して、「OK」をクリックします。
その他の論理表ソース「Fact_W_GL_BALANCE_A_EBS」に対して、手順13を繰り返します。
原価予算は、プロジェクト原価計算から、そのプロジェクトの原価予算分析グループ内のすべての分析タイプについて抽出されます。抽出されたすべての原価予算は予算ファクト表に直接費としてロードされます。ただし、この項で説明する構成のどちらか、または両方を実行した場合を除きます。
分析タイプに基づくプロジェクト予算間接費の特定
ETLプロセスは、file_Project_Budget_Burden_Analysis_Type_psft.csvフラット・ファイルを使用して、プロジェクト予算間接費のすべての分析タイプをリストします。ETLプロセスで、このフラット・ファイル内に分析タイプが見つかった場合は、プロジェクト予算間接費を判断するために、その他の参照表をさらに参照することはなくなります。
file_Project_Budget_Burden_Analysis_Type_psft.csvファイルを構成するには:
file_Project_Budget_Burden_Analysis_Type_psft.csvファイルを編集します。
注意: このタスクの構成ファイル(複数の場合もあり)は、Oracle BI Applicationsインストールの次の場所にあります。 ソース独立ファイル: <Oracle Home for BI>\biapps\etl\data_files\src_files\。 ソース固有ファイル: <Oracle Home for BI>\biapps\etl\data_files\src_files\<source adaptor>。 システム管理者は、これらのファイルを別の場所にコピーして、この場所から読み取るためのODI接続を構成しているはずです。システム管理者に、これらのファイルの取得を依頼してください。構成が完了したら、システム管理者は、構成済ファイルをODIの読取り元にコピーする必要があります。 |
プロジェクト予算間接費と見なされる分析タイプのリストを入力します。
形式はXXX,1です。このXXXは分析タイプです。1は、プロジェクト予算間接費であることを示す戻り値として使用されます。
次に、分析タイプBURおよびBRDがプロジェクト予算間接費である場合の原価分類の例を示します。
BUR,1 BRD,1
ファイルを保存して閉じます。
ソース・タイプ、カテゴリ、サブカテゴリの値の組合せに基づくプロジェクト予算間接費の特定
ソース・タイプ、カテゴリ、サブカテゴリの値の組合せに基づいてプロジェクト予算間接費を特定するには、次のフラット・ファイルを構成する必要があります。実装に対してこの参照を実行するかどうかは、FSMパラメータのBURDEN_TYPECATSUBによって決まります。
file_Project_Cost_Burden_TypeCatSub_config_psft.csv
ETLプロセスではこのフラット・ファイルを使用して、参照に使用される列(ソース・タイプ、カテゴリ、サブカテゴリ)を指定します。
file_Project_Cost_Burden_TypeCatSub_psft.csv
ETLプロセスではこのフラット・ファイルを使用して、プロジェクト予算間接費に使用するソース・タイプ、カテゴリ、サブカテゴリの値の組合せをすべて一覧表示します。
file_Project_Cost_Burden_TypeCatSub_config_psft.csvファイルを構成するには:
file_Project_Cost_Burden_TypeCatSub_config_psft.csvを編集します。
注意: このタスクの構成ファイル(複数の場合もあり)は、Oracle BI Applicationsインストールの次の場所にあります。 ソース独立ファイル: <Oracle Home for BI>\biapps\etl\data_files\src_files\。 ソース固有ファイル: <Oracle Home for BI>\biapps\etl\data_files\src_files\<source adaptor>。 システム管理者は、これらのファイルを別の場所にコピーして、この場所から読み取るためのODI接続を構成しているはずです。システム管理者に、これらのファイルの取得を依頼してください。構成が完了したら、システム管理者は、構成済ファイルをODIの読取り元にコピーする必要があります。 |
行IDが1の行を1行のみ入力します。間接費として評価される値の組合せを表す各列にYを入力します。次の列が対象になります。
行ID
ソース・タイプ
カテゴリ
サブカテゴリ
次の例では、ソース・タイプとカテゴリの組合せの使用方法を示します。
1,Y,Y,
ファイルを保存して閉じます。
file_Project_Cost_Burden_TypeCatSub_psft.csvファイルを構成するには:
file_Project_Cost_Burden_TypeCatSub_psft.csvを編集します。
注意: このタスクの構成ファイル(複数の場合もあり)は、Oracle BI Applicationsインストールの次の場所にあります。 ソース独立ファイル: <Oracle Home for BI>\biapps\etl\data_files\src_files\。 ソース固有ファイル: <Oracle Home for BI>\biapps\etl\data_files\src_files\<source adaptor>。 システム管理者は、これらのファイルを別の場所にコピーして、この場所から読み取るためのODI接続を構成しているはずです。システム管理者に、これらのファイルの取得を依頼してください。構成が完了したら、システム管理者は、構成済ファイルをODIの読取り元にコピーする必要があります。 |
間接費と見なされるリソース・タイプ、リソース・カテゴリ、リソース・サブカテゴリの組合せのリストを入力します。形式は次のとおりです。
XXXXX,XXXXX,XXXXX,1
XXXXXは、リソース・タイプ、リソース・サブカテゴリ、リソース・サブカテゴリの組合せを表しています。
1は、プロジェクト予算間接費であることを示す戻り値です。参照値の組合せをそれぞれ指定する必要があります。
ワイルドカードはサポートされていません。
次に、ソース・タイプG&AまたはFRNGがプロジェクト予算間接費である場合の原価分類の例を示します。
G&A,,,1 FRNG,,,1
注意: このCSVファイルはfile_Project_Cost_Burden_TypeCatSub_config_psft.csv構成ファイルと組み合せて使用します。この例では、この構成ファイルに値1,Yが格納されます。
表B-47 file_Project_Cost_Burden_TypeCatSub_config_psft.csv構成ファイルの例
ソース・タイプ | カテゴリ | サブカテゴリ |
---|---|---|
G&A |
<空白> |
<空白> |
FRNG |
LUX |
TEMP |
FRNG |
BONUS |
<空白> |
注意: 参照値の組合せをそれぞれ指定する必要があります。参照では、構成ファイル内でYになっている列を使用します。
ファイルを保存して閉じます。
プロジェクト予算分析の構成方法
この項では、プロジェクト予算分析を構成する方法について説明します。
FSMで、「データ・ロード・パラメータの管理」セクションに移動し、「ソース」にPeoplesoft 9.0または9.1 FINSCM、「オファリング」に「Oracle Project Analytics」、「機能領域」に「プロジェクト管理および原価計算」のフィルタを適用します。
次のパラメータを設定します。
BURDEN_ANALYSIS_TYPE
このパラメータは、分析タイプを間接費として参照に指定するために使用します。有効な値は次のとおりです。
- 1. この参照を実行するための実装を有効にします。
- 0. (デフォルト)この参照を無効にします。
BURDEN_TYPECATSUB
このパラメータは、ソース・タイプ、カテゴリ、サブカテゴリの値の組合せを経費として参照に指定するために使用します。有効な値は次のとおりです。
- 1. この参照を有効にします。
- 0. (デフォルト)この参照を無効にします。
詳細を保存します。
次の表に、JD Edwards EnterpriseOne用のFinancial AnalyticsのCSVワークシート・ファイルおよびドメイン値のリストを示します。
表B-48 JD Edwards EnterpriseOne用のFinancial AnalyticsのCSVワークシート・ファイルおよびドメイン値。
ワークシート・ファイル名 | 説明 |
---|---|
file_group_acct_codes_jde.csv |
JD Edwards EnterpriseOneアプリケーションのグループ口座コードと、対応するドメイン値をリストします。 |
file_lkp_fiscal_period_Qtr_Config_jde.csv |
JD Edwardsアプリケーションの時間ディメンション会計期間と、対応するドメイン値をリストします。 |
file_group_acct_codes_jde.csvの構成方法
この項では、file_group_acct_codes_jde.csvの構成方法について説明します。このフラット・ファイルは、各オブジェクトの勘定科目範囲のグループ口座コードを会社ごとに特定するために使用します。たとえば、会社00001で、グループ口座コードの1000から2000までの勘定科目を「収益」として指定します。すべての使用可能なグループ口座コードのドメイン値に関する詳細リストは、Oracle Business Analytics Warehouseデータ・モデル・リファレンスを参照してください。
file_group_acct_codes_jde.csvを構成するには:
file_group_acct_codes_jde.csvファイルを編集します。
注意: このタスクの構成ファイル(複数の場合もあり)は、Oracle BI Applicationsインストールの次の場所にあります。 ソース独立ファイル: <Oracle Home for BI>\biapps\etl\data_files\src_files\。 ソース固有ファイル: <Oracle Home for BI>\biapps\etl\data_files\src_files\<source adaptor>。 システム管理者は、これらのファイルを別の場所にコピーして、この場所から読み取るためのODI接続を構成しているはずです。システム管理者に、これらのファイルの取得を依頼してください。構成が完了したら、システム管理者は、構成済ファイルをODIの読取り元にコピーする必要があります。 |
「会社」フィールドに、設定する会社を移入し、対応するグループ口座コードを使用して、その行の「自」列と「至」列に範囲を指定します。
ファイルを保存して閉じます。
この項では、file_lkp_fiscal_period_Qtr_Config_jde.csvの構成方法について説明します。会計四半期に基づいたメトリックをサポートするには、このファイルを構成する必要があります。
file_lkp_fiscal_period_Qtr_Config_jde.csvを構成するには:
次のSQLを使用して、JD Edwards EnterpriseOneソース・システムの会計四半期データを特定します。
Select CDDTPN,CDFY from F0008
file_lkp_fiscal_period_Qtr_Config_jde.csvファイルを編集します。
注意: このタスクの構成ファイル(複数の場合もあり)は、Oracle BI Applicationsインストールの次の場所にあります。 ソース独立ファイル: <Oracle Home for BI>\biapps\etl\data_files\src_files\。 ソース固有ファイル: <Oracle Home for BI>\biapps\etl\data_files\src_files\<source adaptor>。 システム管理者は、これらのファイルを別の場所にコピーして、この場所から読み取るためのODI接続を構成しているはずです。システム管理者に、これらのファイルの取得を依頼してください。構成が完了したら、システム管理者は、構成済ファイルをODIの読取り元にコピーする必要があります。 |
日付パターンごとに、次のフィールドを設定します。
表B-49 file_lkp_fiscal_period_Qtr_Config_jde.csvのフィールドおよび値
フィールド | 値 |
---|---|
FiscalPattern |
CDDTPN。 |
YEAR |
CDFY。 |
Period |
期間番号の数値。 |
Quarter No |
JD Edwards EnterpriseOneには四半期の概念がないため、期間が属する数値の四半期番号を定義します。 |
Quarter Start Date |
カスタマイズされた期間ごとの四半期開始日。各四半期は、ユーザーが構成したものと同じ期間数になります。形式はDD/MM/YYYYです。 |
Quarter End Date |
カスタマイズされた期間ごとの四半期終了日。各四半期は、ユーザーが構成したものと同じ期間数になります。形式はDD/MM/YYYYです。 |
注意: フラット・ファイルの中に不必要なスペースがないことを確認してください。
ファイルを保存して閉じます。
資産事業所は、キー・フレックス・フィールド(KFF)機能を使用して、E-Business SuiteのFixed Assetアプリケーションで定義されます。KFFは、目的のビジネス・ニーズに基づいて各種のセグメントを使用して設定します。たとえば、あるソース・システムのKFF設定では、セグメント1、2、3、4を国、都道府県、市区町村、および住所に使用し、それとは別のソース・システムでは、セグメント1、2、3、4を住所、市区町村、都道府県、および国またはその他の追加情報に使用していることがあります。
構成ファイルfile_fa_location_segment_config_ora.csvは、Fixed Assetアプリケーションの「場所」KFFと、Oracle Business Analytics Warehouseの資産事業所ディメンションとの間のセグメント・マッピングを構成するために使用します。このファイルはETLを起動する前に構成する必要があります。
構成ファイルの設定:file_fa_location_segment_config_ora.csv
file_fa_location_segment_config_ora.csvを使用して、E-Business Suiteのセグメント・フィールドを、Oracle Business Analytics Warehouseの資産事業所表W_ASSET_LOCATION_Dのセグメント・フィールドと一致させます。
注意: このタスクの構成ファイル(複数の場合もあり)は、Oracle BI Applicationsインストールの次の場所にあります。 ソース独立ファイル: <Oracle Home for BI>\biapps\etl\data_files\src_files\。 ソース固有ファイル: <Oracle Home for BI>\biapps\etl\data_files\src_files\<source adaptor>。 システム管理者は、これらのファイルを別の場所にコピーして、この場所から読み取るためのODI接続を構成しているはずです。システム管理者に、これらのファイルの取得を依頼してください。構成が完了したら、システム管理者は、構成済ファイルをODIの読取り元にコピーする必要があります。 |
このファイルを編集して、セグメントのマッピング情報を記入します。列SEG1から列SEG7は、資産事業所ディメンション表に含まれるOracle Business Analytics Warehouseのセグメント列を表します。各セグメントに、対応するマップ済のKFFセグメントを入力します。マッピングがない場合、フィールドは空のままにします。
例
Oracle Business Analytics Warehouseでは、次の適合値をセグメント列に格納します。
W_ASSET_LOCATION_D.segment1には国の値を格納
W_ASSET_LOCATION_D.segment2には都道府県の値を格納
W_ASSET_LOCATION_D.segment3には郡の値を格納
W_ASSET_LOCATION_D.segment4には市区町村の値を格納
W_ASSET_LOCATION_D.segment5には住所を格納
E-Business Suiteでは、郡は使用されません。KFFでは、次に示すように、国、都道府県、市区町村、および住所を格納します。
FA_LOCATIONS.segment1には国の値を格納
FA_LOCATIONS.segment2には都道府県の値を格納
FA_LOCATIONS.segment3には市区町村の値を格納
FA_LOCATIONS.segment4には国の値を格納
このシナリオをデプロイするには、file_fa_location_segment_config_ora.csvファイルを次のように構成します。
明細レベルの請求情報はE-Business Suiteの請求モジュールにある請求書明細表(PA_DRAFT_INVOICE_ITEMS)から抽出され、請求書明細ファクト(W_PROJ_INVOICE_LINE_F)にロードされます。作成、承認、リリース、転送など、請求書生成プロセスのすべてのステージの全請求書がこの表にロードされ、ユーザーは請求の全体像を確認できます。E-Business Suiteの請求書ヘッダー表(PA_DRAFT_INVOICES_ALL)で使用できる一部の情報(GL記帳日やPA日付など)とフラグ(貸倒償却フラグ、優遇フラグ、取消済フラグ、保留請求書フラグなど)も、請求書明細ファクト内で非正規化されます。
E-Business Suiteでは、このファクトのドキュメント通貨が請求通貨になります。
注意:
E-Business Suite同時実行プログラム(請求書草案を生成する「PRC: 単一プロジェクトの請求書草案の生成」、「PRC: プロジェクト範囲の請求書草案の生成」や、請求書を売掛金管理に転送する「PRC: インタフェース・ストリームライン処理」など)は、Oracle Business Analytics WarehouseをロードするETLの実行前に実行する必要があります。
構成ファイル: file_orderitem_fs.csv
このファイルは汎用であり、ソース・オーダー・システム固有の機能(繰返オーダー明細など)をサポートするものではありません。
このファイルの各行は、次に示す価格を移入するデータで、既存のE-Business Suiteのオーダー明細を補足します。
オーダー品目の承認済請求書価格
オーダー品目の承認済実勢マージン
オーダー品目の承認済実勢価格
オーダー品目のガイドライン請求書価格
オーダー品目のガイドライン実勢価格
オーダー品目のガイドライン実勢価格
オーダー品目の要求済請求書価格
オーダー品目の要求済実勢マージン
オーダー品目の要求済実勢価格
このファイルの単位は、オーダー明細ID単位になります。構成済製品の場合、これはルートのオーダー明細IDになります。
構成済製品の場合、前述の各価格は集計価格にする必要があります。
表B-51 file_orderitem_fs.csvのフィールドの説明
列名 | データ型 | サンプル・データ | 説明 |
---|---|---|---|
INTEGRATION_ID |
VARCHAR2(80) |
344946 |
このファイルのINTEGRATION_IDがオーダー明細IDになります。構成済製品の場合、これはルートのオーダー明細IDになります。 |
GLN_INV_PRI |
NUMBER(28,10) |
101.55 |
オーダーに適用された売上ガイドライン(価格設定方針)請求書価格。価格に例外がなかった場合、これは実際の請求書価格と同じになります。 |
GLN_PKT_PRI |
NUMBER(28,10) |
91.534 |
オーダーに適用された売上ガイドライン(価格設定方針)実勢価格、またはガイドライン請求書価格に基づいた導出ガイドライン実勢価格。価格に例外がなかった場合、これは実際の実勢価格と同じになります。 |
GLN_PKT_MARGIN |
NUMBER(28,10) |
30 |
数量とガイドライン実勢価格に基づいていた場合のオーダーの実勢マージン。価格に例外がなかった場合、これは実際の実勢マージンと同じになります。 |
REQ_INV_PRI |
NUMBER(28,10) |
1345.12 |
価格例外要求で要求された(通常は売上による)請求書価格。価格に例外がなかった場合、これは実際の請求書価格と同じになります。 |
REQ_PKT_PRI |
NUMBER(28,10) |
122.2 |
価格例外要求で要求された(通常は売上による)請求書価格に基づいた実勢価格。価格に例外がなかった場合、これは実際の実勢価格と同じになります。 |
REQ_PKT_MARGIN |
NUMBER(28,10) |
1.3 |
数量と要求された実勢価格に基づいていた場合のオーダーの実勢マージン。価格に例外がなかった場合、これは実際の実勢マージンと同じになります。 |
APPR_INV_PRI |
NUMBER(28,10) |
44.44 |
最後にオーダーに承認された請求書価格。価格に例外がなかった場合、これは実際の請求書価格と同じになります。 |
APPR_PKT_PRI |
NUMBER(28,10) |
22222.2 |
最後にオーダーに承認された実勢価格。価格に例外がなかった場合、これは実際の実勢価格と同じになります。 |
APPR_PKT_MARGIN |
NUMBER(28,10) |
172222.2 |
最後に数量とオーダーに承認された請求書価格に基づいていた場合のオーダーの実勢マージン。価格に例外がなかった場合、これは実際の実勢マージンと同じになります。 |
構成ファイル: file_pri_segment_ds.csv
このファイルは汎用であり、ソース価格設定システム固有の機能をサポートするものではありません。
注意: このタスクの構成ファイル(複数の場合もあり)は、Oracle BI Applicationsインストールの次の場所にあります。 ソース独立ファイル: <Oracle Home for BI>\biapps\etl\data_files\src_files\。 ソース固有ファイル: <Oracle Home for BI>\biapps\etl\data_files\src_files\<source adaptor>。 システム管理者は、これらのファイルを別の場所にコピーして、この場所から読み取るためのODI接続を構成しているはずです。システム管理者に、これらのファイルの取得を依頼してください。構成が完了したら、システム管理者は、構成済ファイルをODIの読取り元にコピーする必要があります。 |
このファイルの各行は、既存のE-Business Suite顧客区分を補足します。これは、次に示すSQLを使用して抽出されます。
SELECT LOOKUP_CODE, MEANING FROM FND_LOOKUP_VALUES WHERE LOOKUP_TYPE = 'CUSTOMER CLASS' AND VIEW_APPLICATION_ID = 220 AND LANGUAGE = '<Base Language>'
このファイルの単位は、顧客区分参照コード単位になります。このコードはE-Business Suiteアプリケーションで作成されています。
表B-52 file_pri_segment_ds.csvのフィールドの説明
列名 | データ型 | サンプル・データ | 説明 |
---|---|---|---|
INTEGRATION_ID |
VARCHAR2(80) |
テクノロジ |
このファイルのINTEGRATION_IDは顧客区分コード(FND_LOOKUP_VALUES.LOOKUP_CODE)になります。 |
PROF_ATTR_<n>_CODE |
VARCHAR2(50) |
貸方 |
プロファイル属性コード。コードと名前のペアの値は、ソース・ドメインとして、file_domain_member_gs.csvを使用して補足される必要があります。 |
AUX1_CHANGED_ON_DT |
NUMBER(28,10) |
<日付> |
タイプ1の変更を有効にするには、この列に増分ロードでレコードの更新日付を移入する必要があります。 |
構成ファイル: file_pri_strategy_ds.csv
このファイルは汎用であり、ソース価格設定システム固有の機能をサポートするものではありません。
このファイルの各行は、次に示すSQLを使用して抽出される、既存のE-Business Suiteの販売チャネルを補足します。
SELECT LOOKUP_CODE, MEANING FROM FND_LOOKUP_VALUES WHERE LOOKUP_TYPE = 'SALES_CHANNEL' AND VIEW_APPLICATION_ID = 660 AND LANGUAGE = '<Base Language>'
このファイルの単位は、販売チャネル参照コード単位になります。このコードはE-Business Suiteアプリケーションによって作成されています。
表B-53 file_pri_strategy_ds.csvのフィールドの説明
列名 | データ型 | サンプル・データ | 説明 |
---|---|---|---|
INTEGRATION_ID |
VARCHAR2(80) |
ALUMNI_VISIT |
このファイルのINTEGRATION_IDは販売チャネルコード(FND_LOOKUP_VALUES.LOOKUP_CODE)になります。 |
STRATEGY_NUM |
VARCHAR2(30) |
PRODUCT_GL_PLAN_NAME |
使用しません。 |
PRODUCT_GL_PLAN_NAME |
VARCHAR2(200) |
PRICE_LIST_NAME |
使用しません。 |
PRICE_LIST_NAME |
VARCHAR2(100) |
会社の価格リスト |
使用しません。 |
DEAL_GL_PLAN_NAME |
VARCHAR2(200) |
標準の取引ポリシー |
使用しません。 |
PRI_SEGMENT_NAME |
VARCHAR2(200) |
産業 – 保持/収穫 |
使用しません。 |
VERSION |
NUMBER(10) |
1 |
使用しません。 |
COMPETITOR_NAME |
VARCHAR2(200) |
名前 |
使用しません。 |
AUX1_CHANGED_ON_DT |
VARCHAR2(19) |
使用しません。 |
販売チャネルのタイプ2の変更を有効にする増分ロードの場合は、この列が移入されている必要があります。 |
構成ファイル: file_pwf_element_ds.csv
このファイルは汎用であり、ソース価格設定システム固有の機能をサポートするものではありません。
注意: このタスクの構成ファイル(複数の場合もあり)は、Oracle BI Applicationsインストールの次の場所にあります。 ソース独立ファイル: <Oracle Home for BI>\biapps\etl\data_files\src_files\。 ソース固有ファイル: <Oracle Home for BI>\biapps\etl\data_files\src_files\<source adaptor>。 システム管理者は、これらのファイルを別の場所にコピーして、この場所から読み取るためのODI接続を構成しているはずです。システム管理者に、これらのファイルの取得を依頼してください。構成が完了したら、システム管理者は、構成済ファイルをODIの読取り元にコピーする必要があります。 |
このファイルの各行は、次に示すSQLを使用して抽出される、既存のE-Business Suiteの変更要因明細IDを補足します。
SELECT QP_LIST_LINES.LIST_LINE_ID MODIFIER_LINE_ID FROM APPS.QP_LIST_LINES INNER JOIN APPS.QP_LIST_HEADERS_B ON QP_LIST_LINES.LIST_HEADER_ID = QP_LIST_HEADERS_B.LIST_HEADER_ID INNER JOIN APPS.QP_LIST_HEADERS_TL ON QP_LIST_HEADERS_B.LIST_HEADER_ID = QP_LIST_HEADERS_TL.LIST_HEADER_ID WHERE (QP_LIST_HEADERS_TL.LANGUAGE = 'US') AND QP_LIST_LINES.LIST_LINE_TYPE_CODE IN ('DIS','SUR','PBH','FREIGHT_CHARGE') AND EXISTS (SELECT 1 FROM ASO_PRICE_ADJUSTMENTS WHERE QP_LIST_LINES.LIST_LINE_ID = ASO_PRICE_ADJUSTMENTS.MODIFIER_LINE_ID AND ASO_PRICE_ADJUSTMENTS.APPLIED_FLAG = 'Y' UNION ALL SELECT 1 FROM OE_PRICE_ADJUSTMENTS WHERE QP_LIST_LINES.LIST_LINE_ID = OE_PRICE_ADJUSTMENTS.LIST_LINE_ID AND OE_PRICE_ADJUSTMENTS.APPLIED_FLAG = 'Y' )
このファイルの単位は、変更要因明細タイプ(割引、追加料金、価格分岐ヘッダーまたはオーダー明細または見積明細の修正の原因となった運送費)の変更要因明細ID単位になります。
表B-54 file_pwf_element_ds.csvのフィールドの説明
列名 | データ型 | サンプル・データ | 説明 |
---|---|---|---|
INTEGRATION_ID |
VARCHAR2(80) |
15678 |
このファイルのINTEGRATION_IDは変更要因明細ID (QP_LIST_LINES.LIST_LINE_ID)になります。 |
ELEMENT_TYPE_CODE |
VARCHAR2(80) |
収益修正 |
価格要素タイプ・コード。コードと名前のペアの値は、ファイルfile_domain_member_gs.csvを使用して補足されます。 |
BASIS_SEGMENT |
VARCHAR2(50) |
上限収益 |
使用しません。 |
TOKEN |
VARCHAR2(50) |
OFF_CEILING |
使用しません。 |
REVN_COST_IND |
NUMBER(10) |
1 |
使用しません。 |
DISP_ON_ZERO_FLG |
VARCHAR2(1) |
N |
使用しません。 |
構成ファイル: file_quoteitem_fs.csv
このファイルは汎用であり、繰返見積明細など、ソース見積システム固有の機能をサポートするものではありません。
注意: このタスクの構成ファイル(複数の場合もあり)は、Oracle BI Applicationsインストールの次の場所にあります。 ソース独立ファイル: <Oracle Home for BI>\biapps\etl\data_files\src_files\。 ソース固有ファイル: <Oracle Home for BI>\biapps\etl\data_files\src_files\<source adaptor>。 システム管理者は、これらのファイルを別の場所にコピーして、この場所から読み取るためのODI接続を構成しているはずです。システム管理者に、これらのファイルの取得を依頼してください。構成が完了したら、システム管理者は、構成済ファイルをODIの読取り元にコピーする必要があります。 |
このファイルの各明細は、次に示す価格を移入するデータを使用して、既存のEBS見積明細を補足します。
見積品目承認済請求書価格
見積品目承認済実勢マージン
見積品目承認済実勢価格
見積品目ガイドライン請求書価格
見積品目ガイドライン実勢マージン
見積品目ガイドライン実勢価格
見積品目要求済請求書価格
見積品目要求済実勢マージン
見積品目要求済実勢価格
このファイルの単位は、見積明細ID単位になります。構成済製品の場合、これはルートの見積明細IDになります。
構成済製品の場合、前述の各価格は集計価格にする必要があります。
表B-55 file_quoteitem_fs.csvのフィールドの説明
列名 | データ型 | サンプル・データ | 説明 |
---|---|---|---|
INTEGRATION_ID |
VARCHAR2(80) |
344946 |
このファイルのINTEGRATION_IDが見積明細IDになります。構成済製品の場合、これはルートの見積明細IDになります。 |
GLN_INV_PRI |
NUMBER(28,10) |
101.55 |
見積に適用された売上ガイドライン(価格設定方針)請求書価格。価格に例外がなかった場合、これは実際の請求書価格と同じになります。 |
GLN_PKT_PRI |
NUMBER(28,10) |
91.534 |
見積に適用された売上ガイドライン(価格設定方針)実勢価格、またはガイドライン請求書価格に基づいて導出したガイドライン実勢価格。価格に例外がなかった場合、これは実際の実勢価格と同じになります。 |
GLN_PKT_MARGIN |
NUMBER(28,10) |
30 |
数量とガイドライン実勢価格に基づいていた場合の見積の実勢マージン。価格に例外がなかった場合、これは実際の実勢マージンと同じになります。 |
REQ_INV_PRI |
NUMBER(28,10) |
1345.12 |
価格例外要求で要求された(通常は売上による)請求書価格。価格に例外がなかった場合、これは実際の請求書価格と同じになります。 |
REQ_PKT_PRI |
NUMBER(28,10) |
122.2 |
価格例外要求で要求された(通常は売上による)請求書価格に基づいた実勢価格。価格に例外がなかった場合、これは実際の実勢価格と同じになります。 |
REQ_PKT_MARGIN |
NUMBER(28,10) |
1.3 |
数量と要求された実勢価格に基づいていた場合の見積の実勢マージン。価格に例外がなかった場合、これは実際の実勢マージンと同じになります。 |
APPR_INV_PRI |
NUMBER(28,10) |
44.44 |
最後に見積に承認された請求書価格。価格に例外がなかった場合、これは実際の請求書価格と同じになります。 |
APPR_PKT_PRI |
NUMBER(28,10) |
22222.2 |
最後に見積に承認された実勢価格。価格に例外がなかった場合、これは実際の実勢価格と同じになります。 |
APPR_PKT_MARGIN |
NUMBER(28,10) |
172222.2 |
最後に数量と見積に承認された請求書価格に基づいていた場合の見積の実勢マージン。価格に例外がなかった場合、これは実際の実勢マージンと同じになります。 |
この項では、価格フラット・ファイル使用してシードされたコードに対するソース・ドメイン・メンバー名の値を構成する方法について説明します。次の表には、プレゼンテーション列からフラット・ファイル列および関連するソース・ドメイン・コードへの結合がまとめられています。
表B-56 Price Analyticsでのソース・ドメインのフラット・ファイルの構成
プレゼンテーション表 | プレゼンテーション列 | ファイル名 | ファイル列 | ソース・ドメイン・コード |
---|---|---|---|---|
価格ウォーターフォール要素 |
ソース要素コード |
file_pwf_element_ds.csv |
ELEMENT_CODE |
PRC_ELEMENT_CODE |
価格ウォーターフォール要素 |
ソース要素タイプ・コード |
file_pwf_element_ds.csv |
ELEMENT_TYPE_CODE |
PRC_ELEMENT_TYPE_CODE |
価格プロファイル |
プロファイル属性1のコード |
file_pri_segment_ds.csv |
PROF_ATTR_1_CODE |
PRC_PROFILE_1 |
価格プロファイル |
プロファイル属性2のコード |
file_pri_segment_ds.csv |
PROF_ATTR_2_CODE |
PRC_PROFILE_2 |
価格プロファイル |
プロファイル属性3のコード |
file_pri_segment_ds.csv |
PROF_ATTR_3_CODE |
PRC_PROFILE_3 |
価格プロファイル |
プロファイル属性4のコード |
file_pri_segment_ds.csv |
PROF_ATTR_4_CODE |
PRC_PROFILE_4 |
価格プロファイル |
プロファイル属性5のコード |
file_pri_segment_ds.csv |
PROF_ATTR_5_CODE |
PRC_PROFILE_5 |
注意: このタスクの構成ファイル(複数の場合もあり)は、Oracle BI Applicationsインストールの次の場所にあります。 ソース独立ファイル: <Oracle Home for BI>\biapps\etl\data_files\src_files\。 ソース固有ファイル: <Oracle Home for BI>\biapps\etl\data_files\src_files\<source adaptor>。 システム管理者は、これらのファイルを別の場所にコピーして、この場所から読み取るためのODI接続を構成しているはずです。システム管理者に、これらのファイルの取得を依頼してください。構成が完了したら、システム管理者は、構成済ファイルをODIの読取り元にコピーする必要があります。 |
構成ファイル: file_domain_member_gs.csv
このファイルは汎用であり、ソース価格設定システム固有の機能をサポートするものではありません。
このファイルは、E-Business Suiteでは使用できないドメインにデータを移入するために使用します。次にリストするディメンションにデータを補足する場合にのみロードする必要があります。
価格ウォーターフォール要素ディメンション – 価格要素タイプ・コード(適合価格要素タイプは、このディメンションを通じて導入される新しいドメインにマップする必要があります)。
価格セグメント・ディメンション - 価格プロファイル属性1コード
価格セグメント・ディメンション - 価格プロファイル属性2コード
価格セグメント・ディメンション - 価格プロファイル属性3コード
価格セグメント・ディメンション - 価格プロファイル属性4コード
価格セグメント・ディメンション - 価格プロファイル属性5コード
タスクSDE_ORA_DomainGeneral_PriceElementTypeでは、ファイルのデータをウェアハウスのステージング表W_DOMAIN_MEMBER_GSにロードします。
このファイルの単位は、前述のリストに含まれるドメインの言語ごとのドメイン・メンバー単位になります。
表B-57 file_domain_member_gs.csvのフィールドの説明
列名 | データ型 | サンプル・データ | 説明 |
---|---|---|---|
DOMAIN_CODE |
使用しません。 |
使用しません。 |
これには、表10-1に示したように、構成されるソース・ドメインに対応するドメイン・コードを移入する必要があります。 |
DOMAIN_TYPE_CODE |
使用しません。 |
使用しません。 |
デフォルト設定は'S'です。この値は、これがソース・ドメイン・コードであることを示します。 |
DOMAIN_MEMBER_CODE |
使用しません。 |
使用しません。 |
これには、前述のファイルのいずれかで提供されるCODE値を移入する必要があります。 |
DOMAIN_MEMBER_NAME |
使用しません。 |
使用しません。 |
これには、提供されるメンバー・コードに対応するNAME値を移入する必要があります。 |
DOMAIN_MEMBER_DESCR |
使用しません。 |
使用しません。 |
使用しません。 |
DOMAIN_MEMBER_REF_CODE |
使用しません。 |
使用しません。 |
'__NOT_APPLICABLE__'にハードコードされています。 |
DOMAIN_MEMBER_DEFN_TYPE_CODE |
使用しません。 |
使用しません。 |
使用しません。 |
LANGUAGE_CODE |
使用しません。 |
使用しません。 |
ウェアハウスの言語コード。 |
SRC_LANGUAGE_CODE |
使用しません。 |
使用しません。 |
ソース言語コード。 |
INTEGRATION_ID |
使用しません。 |
使用しません。 |
これは、レコードに対して固有のIDです。このファイルのINTEGRATION_IDは、DOMAIN_CODE~DOMAIN_MEMBER_CODEとして移入することもできます。 |
DATASOURCE_NUM_ID |
使用しません。 |
使用しません。 |
構成するSiebelインスタンスの固有データ・ソースID。 |
予備知識
Oracle Price Analyticsは、E-Business Suiteで使用できるQuotingモジュール、Order ManagementモジュールおよびAdvanced Pricingモジュールをデータ・ソースにしています(デフォルト時)。さらに、ディメンションの属性と追加のオーダー明細価格やオーダー見積価格(ガイドライン請求書価格など)を補足するフラット・ファイル・オプションが用意されています。これらは、前述のモジュールの簡易実装では使用できません。
注意: このタスクの構成ファイル(複数の場合もあり)は、Oracle BI Applicationsインストールの次の場所にあります。 ソース独立ファイル: <Oracle Home for BI>\biapps\etl\data_files\src_files\。 ソース固有ファイル: <Oracle Home for BI>\biapps\etl\data_files\src_files\<source adaptor>。 システム管理者は、これらのファイルを別の場所にコピーして、この場所から読み取るためのODI接続を構成しているはずです。システム管理者に、これらのファイルの取得を依頼してください。構成が完了したら、システム管理者は、構成済ファイルをODIの読取り元にコピーする必要があります。 |
フラット・ファイルからのETL
ETLプロセスは、フラット・ファイルからの非E-Business Suiteデータと、E-Business Suiteアプリケーションのデータベース表からのデータをステージング表にロードします。その後で、ステージング表からのデータをOracle Business Analytics Warehouseにロードします。
表B-58 フラット・ファイルとOracle Business Analytics Warehouseのターゲット表
フラット・ファイル | 説明 | 補足対象 |
---|---|---|
file_pri_strategy_ds |
このファイルは、EBS販売チャネル・コードを補足する追加の属性についてのデータを保持します。 |
W_PRI_STRATEGY_D 価格戦略: 販売と価格設定および製品に関連する特定の目標に達成するための方法を定義する価格設定ルールのグループ化。ターゲットは、価格設定セグメント、サブセグメントおよび特定の販売状況。 |
file_pri_segment_ds |
このファイルは、EBS顧客区分コードを補足する追加の属性についてのデータを保持します。 |
W_PRI_SEGMENT_D 価格設定セグメント: 製品またはサービスの供給者との関連で共通する特徴と購買行動を明らかにする顧客の集合またはグループ化。価格設定セグメントは、通常、価格設定戦略で一般的な価格設定戦術に反応する顧客の集合を分類して理解できるようにするために、市場セグメントを微調整したものです。 |
file_pwf_element_ds |
このファイルは、EBS変更要因明細を補足する追加の属性についてのデータを保持します。 |
W_PWF_ELEMENT_D 価格ウォーターフォール要素: PWF要素とは、価格ウォーターフォールを構成する各種のコンポーネントのことです。これには、(a)上限価格やセグメント収益などの要約された価格/収益と、(b)割引プログラム、奨励金、要約された価格/収益の経費または原価についてのユニット化修正または実際の金額修正になる各種の調整が含まれます。 |
file_quoteitem_fs |
このファイルは、見積品目のトランザクション・データに対応する承認済、要求済およびガイドライン請求書価格/実勢価格とマージンを保持します。 |
W_QUOTEITEM_F 見積品目: 各種の見積明細収益額と修正額を格納しますこの表の単位は見積明細になります。 |
file_orderitem_fs |
このファイルは、オーダー品目のトランザクション・データに対応する承認済、要求済およびガイドライン請求書価格/実勢価格とマージンを保持します。 |
W_ORDERITEM_F オーダー品目: 各種のオーダー明細収益額と修正額を格納しますこの表の単位はオーダー明細になります。 |
フラット・ファイルによるドメインの構成
該当するファイルを使用して補足される、コード・ディメンション属性のソース・ドメイン・メンバー値は、ドメイン・ファイル(file_domain_member_gs.csv)でウェアハウスに移入できます。
ファイルの仕様
該当するファイルは、すべてのアダプタで使用されるため、E-Business Suite 12.1.3アダプタでサポートされている少数の列にのみデータを移入する必要があります。その他の列には、NULLを移入する必要があります。
ファイルでサポートされる列については、後述する「ファイル構造」の項にリストが示されています。
該当するファイルは、データの補足に使用されていない場合でも、E-Business Suite 12.1.3のソース・ファイル・フォルダに存在している必要があります。それ以外の場合、抽出タスクは失敗します。
ソース・ファイル内のデータは、次の仕様に適合している必要があります。
データはCSVファイル(*.csv)に存在している必要があります。
完全ETLの場合、これらのファイルにはOracle Business Analytics Warehouseにロードすることになる初期レコードがすべて含まれている必要があります。増分ETLの場合、新しいレコードまたは更新されたレコードのみを含める必要があります。
ファイルに含まれるすべての列は、E-Business Suiteアプリケーション・データ・モデルの用語と基準に従う必要があります。ファイルに含まれるすべてのID列には、対応するE-Business Suite IDが存在することが予想されます。
データは、各ファイルの6行目から始まっている必要があります。各ファイルの先頭から5行は、ETLプロセス時にスキップされます。
各行は、ステージング表の1つの固有レコードを表します。
すべての日付値は、YYYYMMDDHH24MISS形式にする必要があります。たとえば、2007年12月31日午後2:03の場合は、20071231140300を使用する必要があります。
金額列または価格列の値は、OLTPトランザクションで使用されているドキュメント通貨コードと同じにする必要があります。
すべてのフラット・ファイルに含まれる列INTEGRATION_IDは、NULLにはできません。この列は、(i) OLTPデータを補足している場合は参照キーとして機能し、(ii)ファイルがプライマリ・ソースの役割を果たしている場合は主キーとして機能するためです。
この項では、ソースおよび適合ドメイン・コード・メンバーにデータを移入するために、Oracle Project Analyticsで実行する必要がある構成手順について説明します。この項の内容は次のとおりです。
注意: このタスクの構成ファイル(複数の場合もあり)は、Oracle BI Applicationsインストールの次の場所にあります。 ソース独立ファイル: <Oracle Home for BI>\biapps\etl\data_files\src_files\。 ソース固有ファイル: <Oracle Home for BI>\biapps\etl\data_files\src_files\<source adaptor>。 システム管理者は、これらのファイルを別の場所にコピーして、この場所から読み取るためのODI接続を構成しているはずです。システム管理者に、これらのファイルの取得を依頼してください。構成が完了したら、システム管理者は、構成済ファイルをODIの読取り元にコピーする必要があります。 |
この項では、価格フラット・ファイル使用してシードされたコードに対するソース・ドメイン・メンバー名の値を構成する方法について説明します。次の表には、プレゼンテーション列からフラット・ファイル列および関連するソース・ドメイン・コードへの結合がまとめられています。
表B-59 Price Analyticsでのソース・ドメインのフラット・ファイルの構成
プレゼンテーション表 | プレゼンテーション列 | ファイル名 | ファイル列 | ソース・ドメイン・コード |
---|---|---|---|---|
価格ウォーターフォール要素 |
ソース要素コード |
file_pwf_element_ds.csv |
ELEMENT_CODE |
PRC_ELEMENT_CODE |
価格ウォーターフォール要素 |
ソース要素タイプ・コード |
file_pwf_element_ds.csv |
ELEMENT_TYPE_CODE |
PRC_ELEMENT_TYPE_CODE |
価格ウォーターフォール要素 |
価格グループ・コード |
file_pwf_element_ds.csv |
GROUP_CODE |
PRC_GROUP_CODE |
価格プロファイル |
プロファイル属性1のコード |
file_pri_segment_ds.csv |
PROF_ATTR_1_CODE |
PRC_PROFILE_1 |
価格プロファイル |
プロファイル属性2のコード |
file_pri_segment_ds.csv |
PROF_ATTR_2_CODE |
PRC_PROFILE_2 |
価格プロファイル |
プロファイル属性3のコード |
file_pri_segment_ds.csv |
PROF_ATTR_3_CODE |
PRC_PROFILE_3 |
価格プロファイル |
プロファイル属性4のコード |
file_pri_segment_ds.csv |
PROF_ATTR_4_CODE |
PRC_PROFILE_4 |
価格プロファイル |
プロファイル属性5のコード |
file_pri_segment_ds.csv |
PROF_ATTR_5_CODE |
PRC_PROFILE_5 |
たとえば、file_pwf_element_ds.csvファイル内のサンプル・データには、次に示す各要素タイプが使用されています。
セグメント
ウォーターフォールの一部になる収益(上限収益、一覧収益など)。
収益修正
セグメント要素に対して行われる調整(上限額修正、請求書修正など)。
原価修正
どのセグメントにも含まれない、その他すべての修正。
これらの要素タイプや、表10-1に示したソース・ドメイン・メンバーのいずれかに対応する名前の値は、file_domain_member_gs.csvファイルで提供する必要があります。これにより、Analyticsで名前を問い合せたときに、それらの値が表示されるようになります。
File_domain_member_gs.csv
このファイルは汎用であり、ソース価格設定システム固有の機能をサポートするものではありません。
タスクSDE_DomainGeneral_PriceElementTypeでは、ファイルのデータをウェアハウスのステージング表W_DOMAIN_MEMBER_GSにロードします。
このファイルの単位は、前述のリストに含まれるドメインの言語ごとのドメイン・メンバー単位になります。
表B-60 file_domain_member_gs.csvのフィールドの説明
列名 | データ型 | サンプル・データ | 説明 |
---|---|---|---|
DOMAIN_CODE |
使用しません。 |
使用しません。 |
これには、表10-1に示したように、構成されるソース・ドメインに対応するドメイン・コードを移入する必要があります。 |
DOMAIN_TYPE_CODE |
使用しません。 |
使用しません。 |
デフォルト設定は'S'です。この値は、これがソース・ドメイン・コードであることを示します。 |
DOMAIN_MEMBER_CODE |
使用しません。 |
使用しません。 |
これには、前述のファイルのいずれかで提供されるCODE値を移入する必要があります。 |
DOMAIN_MEMBER_NAME |
使用しません。 |
使用しません。 |
これには、提供されるメンバー・コードに対応するNAME値を移入する必要があります。 |
DOMAIN_MEMBER_DESCR |
使用しません。 |
使用しません。 |
使用しません。 |
DOMAIN_MEMBER_REF_CODE |
使用しません。 |
使用しません。 |
'__NOT_APPLICABLE__'にハードコードされています。 |
DOMAIN_MEMBER_DEFN_TYPE_CODE |
使用しません。 |
使用しません。 |
使用しません。 |
LANGUAGE_CODE |
使用しません。 |
使用しません。 |
ウェアハウスの言語コード。 |
SRC_LANGUAGE_CODE |
使用しません。 |
使用しません。 |
ソース言語コード。 |
INTEGRATION_ID |
使用しません。 |
使用しません。 |
これは、レコードに対して固有のIDです。このファイルのINTEGRATION_IDは、DOMAIN_CODE~DOMAIN_MEMBER_CODEとして移入することもできます。 |
DATASOURCE_NUM_ID |
使用しません。 |
使用しません。 |
構成するSiebelインスタンスの固有データ・ソースID。 |
次の表にまとめたように、Oracle Price Analyticsで使用する適合ドメインは2つあります。
表B-61 Price Analyticsでのソース・ドメインのフラット・ファイルの構成
プレゼンテーション表 | プレゼンテーション列 | ファイル名 | ファイル列 | ソース・ドメイン・コード |
---|---|---|---|---|
価格ウォーターフォール要素 |
要素コード |
file_pwf_element_ds.csv |
W_ELEMENT_CODE |
適合価格ウォーターフォール要素 |
価格ウォーターフォール要素 |
要素タイプ |
file_pwf_element_ds.csv |
W_ELEMENT_TYPE_CODE |
適合価格ウォーターフォール要素タイプ |
ソース・ファイルfile_pwf_element_ds.csvにはマップされた適合ドメインが含まれていて、対応するソース・ドメイン・コード・メンバーには前述の列の値が含まれている必要があります。
これらの適合ドメインはユーザーが拡張できるため、適合ドメインに含まれるドメイン・メンバーの名前の値(前述の表で指定した値)は、Oracle BI Applications構成マネージャで入力する必要があります。
この項では、価格フラット・ファイル使用してシードされたコードに対するソース・ドメイン・メンバー名の値を構成する方法について説明します。次の表には、プレゼンテーション列からフラット・ファイル列および関連するソース・ドメイン・コードへの結合がまとめられています。
表B-62 ドメイン・マップ: 価格ウォーターフォール要素→適合価格ウォーターフォール要素
ソース価格ウォーターフォール要素メンバー・コード | ソース価格ウォーターフォール要素名 | 適合価格ウォーターフォール要素メンバー・コード | 適合価格ウォーターフォール要素名 |
---|---|---|---|
上限収益 |
上限収益 |
上限収益 |
上限収益 |
原価 |
原価 |
原価 |
原価 |
請求書収益 |
請求書収益 |
請求書収益 |
請求書収益 |
実勢マージン |
実勢マージン |
実勢マージン |
実勢マージン |
実勢収益 |
実勢収益 |
実勢収益 |
実勢収益 |
セグメント収益 |
セグメント収益 |
セグメント収益 |
セグメント収益 |
この項では、価格フラット・ファイル使用してシードされたコードに対するソース・ドメイン・メンバー名の値を構成する方法について説明します。次の表には、プレゼンテーション列からフラット・ファイル列および関連するソース・ドメイン・コードへの結合がまとめられています。
表B-63 ドメイン・マップ: 価格ウォーターフォール要素タイプ→適合価格ウォーターフォール要素タイプ
ソース価格ウォーターフォール要素メンバー・コード | ソース価格ウォーターフォール要素名 | 適合価格ウォーターフォール要素メンバー・コード | 適合価格ウォーターフォール要素名 |
---|---|---|---|
原価修正 |
原価修正 |
原価修正 |
原価修正 |
収益修正 |
収益修正 |
収益修正 |
収益修正 |
セグメント |
セグメント |
セグメント |
セグメント |
これらはfile_pwf_element_ds.csvファイルに含めることができます。また、前の項で説明したように、新しいソース/適合ドメイン・メンバーを入力できます。
この項では、Oracle Price Analyticsを構成する方法について説明します。この項の内容は次のとおりです。
注意: このタスクの構成ファイル(複数の場合もあり)は、Oracle BI Applicationsインストールの次の場所にあります。 ソース独立ファイル: <Oracle Home for BI>\biapps\etl\data_files\src_files\。 ソース固有ファイル: <Oracle Home for BI>\biapps\etl\data_files\src_files\<source adaptor>。 システム管理者は、これらのファイルを別の場所にコピーして、この場所から読み取るためのODI接続を構成しているはずです。システム管理者に、これらのファイルの取得を依頼してください。構成が完了したら、システム管理者は、構成済ファイルをODIの読取り元にコピーする必要があります。 |
この項では、データの完全ロードを実行する前に、Oracle Project Analyticsで実行する必要がある構成手順について説明します。
Universalソースに対する構成手順
Oracle Price Analyticsは、ウォーターフォール関連のデータについては、Universalソース(フラット・ファイルなど)のデータに依存します。
次の表に、ウォーターフォール関連のデータ用のフラット・ファイルのソース表と、それに対応するOracle Business Analytics Warehouseの表をリストします。
表B-64 フラット・ファイルのソース表と対応するウェアハウスの表
フラット・ファイル | 説明 | ロード対象 |
---|---|---|
FILE_PRI_STRATEGY_DS |
このファイルは、使用する各種価格設定戦略についての情報を保持します。 |
W_PRI_STRATEGY_D |
FILE_PRI_SEGMENT_DS |
このファイルは、各種価格設定セグメントの詳細を保持します。 |
W_PRI_SEGMENT_D |
FILE_PWF_ELEMENT |
このファイルは、各種ウォーターフォール要素についての情報を格納します。 |
W_PWF_ELEMENT_D |
FILE_ORDIT_WTR_LOG_FS |
このファイルは、オーダー品目のすべてのトランザクション・データに関するウォーターフォール情報を保持します。 |
W_ORDIT_WTR_LOG_F |
FILE_QTEIT_WTR_LOG_FS |
このファイルは、見積品目のすべてのトランザクション・データに関するウォーターフォール情報を保持します。 |
W_QTEIT_WTR_LOG_F |
この項では、ソースがSiebelの場合に、価格設定データをフラット・ファイルに移入する際のガイドラインについて説明します。
Oracle Price Analyticsには、Siebelソースの価格設定戦略、価格設定セグメントまたは価格ウォーターフォール要素の情報をロードする方法がありません。それらのすべてのディメンションは、フラット・ファイルなどのUniversalソースを使用してロードする必要があります。
価格設定に関連するディメンション用のソース・ファイルは、次のルールに適合している必要があります。
フラット・ファイルで提供される価格設定セグメントと価格設定戦略IDは、あらゆるオーダーに含まれるすべてのオーダー品目明細と同じものにする必要があります。
ROW_IDは統合IDの作成に使用されるため、すべてのフラット・ファイル内でROW_IDを一意にする必要があります。
追加する情報は、Siebelシステム内に既存のデータとの整合性を保つ必要があります。たとえば、ファイルに追加した競合他社名を正しく解決するには、それがソース・システムに存在している必要があります。
オーダー品目ウォーターフォールのファクト・ソース内のオーダー明細IDは、ソース表S_ORDER_ITEM内に存在している必要があります。
見積品目ウォーターフォールのファクト・ソース内の見積明細IDは、ソース表S_QUOTE_ITEM内に存在している必要があります。
Oracle Price AnalyticsのファクトW_ORDIT_WTR_LOG_FとW_QTEIT_WTR_LOG_Fは、オーダー品目ファクトと見積品目ファクトを使用して、フラット・ファイルとともにロードされる必要があります。
オーダー品目ファクトと見積品目ファクト内の価格設定の列は、次の表に示すようにロードされます。
表B-65 オーダー品目ファクトと見積品目ファクトの価格設定列
列名 | 式 |
---|---|
CEIL_PRI |
IIF(ISNULL(FLAT_FILE_DATA),START_PRI,FLAT_FILE_DATA) |
SEG_PRI |
IIF(ISNULL(FLAT_FILE_DATA),START_PRI,FLAT_FILE_DATA) |
INV_PRI |
IIF(ISNULL(FLAT_FILE_DATA),NET_PRI,FLAT_FILE_DATA) |
PKT_PRI |
IIF(ISNULL(FLAT_FILE_DATA),NET_PRI,FLAT_FILE_DATA) |
PKT_MARGIN |
IIF(ISNULL(FLAT_FILE_DATA),START_PRI-NET_PRICE,FLAT_FILE_DATA) |
価格設定列に既存の価格とは異なる値をロードする必要がある場合は、フラット・ファイルFILE_ORDERITEM_FS.csvとFILE_QUOTEITEM_FS.csvが使用できます。統合IDに基づいて、これらのフラット・ファイルから価格設定データが検索され、ファクト表にロードされます。
注意: たとえQUOTEITEMまたはORDERITEMを補足していない場合でも、抽出タスクの失敗を防ぐために、アダプタ・ソース・ファイル・フォルダで空のファイルが使用できるようにしておく必要があります。
この項では、ソースがSiebel以外の場合に、価格設定データをフラット・ファイルに移入する際のガイドラインについて説明します。
ソースがSiebel以外の場合、価格設定に関連するディメンション用のソース・ファイルは、次のルールに適合している必要があります。
オーダー品目ウォーターフォールのファクト・ソース内のオーダー明細IDは、ファクト・ファイル・ソースFILE_ORDERITEM_FS内に存在している必要があります。
見積品目ウォーターフォールのファクト・ソース内の見積明細IDは、ファクト・ファイル・ソースFILE_QUOTEITEM_FSの一部にする必要があります。
重複や索引の問題を避けるために、すべてのROW_IDが一意であることを確認してください。
追加したすべてのファクトIDが正しく解決されるには、ディメンション・ファイル・ソースのROW_IDとの整合性を保つ必要があります。
Oracle Price Analyticsのファクトに使用するフラット・ファイル(FILE_ORDIT_WTR_LOG_FSやFILE_QTEIT_WTR_LOG_FSなど)は、明細品目の表との整合性を保つ必要があります。ウォーターフォール・ログ表内の価格は、明細品目の表内の集計済価格にする必要があります。また、組立済の製品またはパッケージ化された製品の場合、品目表にはパッケージまたは構成部品と、そのパッケージまたは構成部品を構成する個別の品目を、別々の明細品目として格納する必要があります。フラット・ファイル内の明細品目には、集計した価格ではなく、個別の価格を格納する必要があります。パッケージには価格が付けられていないときに、そのパッケージ内の個別の品目にのみ価格が付けられている場合は、パッケージの価格を0にして各品目に価格を付けるか、パッケージに集計した価格を付けて品目の価格は0にすることで、二重計算を避けるようにします。さらに、ウォーターフォール・ログ表には、パッケージまたは構成部品のみを格納して、それらを構成する品目は格納しません。また、価格は単位パッケージの価格にするか、構成部品の価格を集計したものにします。
この項では、価格ウォーターフォール要素のサンプル・データについて説明します。
このシナリオでは、ラップトップを製造販売している企業に対するシンプルなオーダーを作成します。次の図は、オーダー品目ファクト表内のオーダー情報の例を示しています。
シンプルな製品のサンプル・データ
次の図は、トランザクションに対するオーダー品目ウォーターフォール・ログ・ファクト・データの例です。
シンプルな製品のオーダー品目ウォーターフォール・ログ・ファクト・データ
この例で示したように、各ウォーターフォール要素は個別のレコードとして格納され、その要素が収益か修正かについてはウォーターフォール要素ディメンションによって特定されます。
この項では、ソースおよび適合ドメイン・コード・メンバーにデータを移入するために、Oracle Project Analyticsで実行する必要がある構成手順について説明します。この項の内容は次のとおりです。
注意: このタスクの構成ファイル(複数の場合もあり)は、Oracle BI Applicationsインストールの次の場所にあります。 ソース独立ファイル: <Oracle Home for BI>\biapps\etl\data_files\src_files\。 ソース固有ファイル: <Oracle Home for BI>\biapps\etl\data_files\src_files\<source adaptor>。 システム管理者は、これらのファイルを別の場所にコピーして、この場所から読み取るためのODI接続を構成しているはずです。システム管理者に、これらのファイルの取得を依頼してください。構成が完了したら、システム管理者は、構成済ファイルをODIの読取り元にコピーする必要があります。 |
この項では、価格フラット・ファイル使用してシードされたコードに対するソース・ドメイン・メンバー名の値を構成する方法について説明します。次の表には、プレゼンテーション列からフラット・ファイル列および関連するソース・ドメイン・コードへの結合がまとめられています。
表B-66 Price Analyticsでのソース・ドメインのフラット・ファイルの構成
プレゼンテーション表 | プレゼンテーション列 | ファイル名 | ファイル列 | ソース・ドメイン・コード |
---|---|---|---|---|
価格ウォーターフォール要素 |
ソース要素コード |
file_pwf_element_ds.csv |
ELEMENT_CODE |
PRC_ELEMENT_CODE |
価格ウォーターフォール要素 |
ソース要素タイプ・コード |
file_pwf_element_ds.csv |
ELEMENT_TYPE_CODE |
PRC_ELEMENT_TYPE_CODE |
価格ウォーターフォール要素 |
価格グループ・コード |
file_pwf_element_ds.csv |
GROUP_CODE |
PRC_GROUP_CODE |
価格プロファイル |
プロファイル属性1のコード |
file_pri_segment_ds.csv |
PROF_ATTR_1_CODE |
PRC_PROFILE_1 |
価格プロファイル |
プロファイル属性2のコード |
file_pri_segment_ds.csv |
PROF_ATTR_2_CODE |
PRC_PROFILE_2 |
価格プロファイル |
プロファイル属性3のコード |
file_pri_segment_ds.csv |
PROF_ATTR_3_CODE |
PRC_PROFILE_3 |
価格プロファイル |
プロファイル属性4のコード |
file_pri_segment_ds.csv |
PROF_ATTR_4_CODE |
PRC_PROFILE_4 |
価格プロファイル |
プロファイル属性5のコード |
file_pri_segment_ds.csv |
PROF_ATTR_5_CODE |
PRC_PROFILE_5 |
たとえば、file_pwf_element_ds.csvファイル内のサンプル・データには、次に示す各要素タイプが使用されています。
セグメント
ウォーターフォールの一部になる収益(上限収益、一覧収益など)。
収益修正
セグメント要素に対して行われる調整(上限額修正、請求書修正など)。
原価修正
どのセグメントにも含まれない、その他すべての修正。
これらの要素タイプや、表10-1に示したソース・ドメイン・メンバーのいずれかに対応する名前の値は、file_domain_member_gs.csvファイルで提供する必要があります。これにより、Analyticsで名前を問い合せたときに、それらの値が表示されるようになります。
File_domain_member_gs.csv
このファイルは汎用であり、ソース価格設定システム固有の機能をサポートするものではありません。
タスクSDE_DomainGeneral_PriceElementTypeでは、ファイルのデータをウェアハウスのステージング表W_DOMAIN_MEMBER_GSにロードします。
このファイルの単位は、前述のリストに含まれるドメインの言語ごとのドメイン・メンバー単位になります。
表B-67 file_domain_member_gs.csvのフィールドの説明
列名 | データ型 | サンプル・データ | 説明 |
---|---|---|---|
DOMAIN_CODE |
使用しません。 |
使用しません。 |
これには、表10-1に示したように、構成されるソース・ドメインに対応するドメイン・コードを移入する必要があります。 |
DOMAIN_TYPE_CODE |
使用しません。 |
使用しません。 |
デフォルト設定は'S'です。この値は、これがソース・ドメイン・コードであることを示します。 |
DOMAIN_MEMBER_CODE |
使用しません。 |
使用しません。 |
これには、前述のファイルのいずれかで提供されるCODE値を移入する必要があります。 |
DOMAIN_MEMBER_NAME |
使用しません。 |
使用しません。 |
これには、提供されるメンバー・コードに対応するNAME値を移入する必要があります。 |
DOMAIN_MEMBER_DESCR |
使用しません。 |
使用しません。 |
使用しません。 |
DOMAIN_MEMBER_REF_CODE |
使用しません。 |
使用しません。 |
'__NOT_APPLICABLE__'にハードコードされています。 |
DOMAIN_MEMBER_DEFN_TYPE_CODE |
使用しません。 |
使用しません。 |
使用しません。 |
LANGUAGE_CODE |
使用しません。 |
使用しません。 |
ウェアハウスの言語コード。 |
SRC_LANGUAGE_CODE |
使用しません。 |
使用しません。 |
ソース言語コード。 |
INTEGRATION_ID |
使用しません。 |
使用しません。 |
これは、レコードに対して固有のIDです。このファイルのINTEGRATION_IDは、DOMAIN_CODE~DOMAIN_MEMBER_CODEとして移入することもできます。 |
DATASOURCE_NUM_ID |
使用しません。 |
使用しません。 |
構成するSiebelインスタンスの固有データ・ソースID。 |
次の表にまとめたように、Oracle Price Analyticsで使用する適合ドメインは2つあります。
表B-68 Price Analyticsでのソース・ドメインのフラット・ファイルの構成
プレゼンテーション表 | プレゼンテーション列 | ファイル名 | ファイル列 | ソース・ドメイン・コード |
---|---|---|---|---|
価格ウォーターフォール要素 |
要素コード |
file_pwf_element_ds.csv |
W_ELEMENT_CODE |
適合価格ウォーターフォール要素 |
価格ウォーターフォール要素 |
要素タイプ |
file_pwf_element_ds.csv |
W_ELEMENT_TYPE_CODE |
適合価格ウォーターフォール要素タイプ |
ソース・ファイルfile_pwf_element_ds.csvにはマップされた適合ドメインが含まれていて、対応するソース・ドメイン・コード・メンバーには前述の列の値が含まれている必要があります。
これらの適合ドメインはユーザーが拡張できるため、適合ドメインに含まれるドメイン・メンバーの名前の値(表10-2で指定した値)は、Oracle BI Applications構成マネージャで入力する必要があります。
この項では、価格フラット・ファイル使用してシードされたコードに対するソース・ドメイン・メンバー名の値を構成する方法について説明します。次の表には、プレゼンテーション列からフラット・ファイル列および関連するソース・ドメイン・コードへの結合がまとめられています。
表B-69 ドメイン・マップ: 価格ウォーターフォール要素→適合価格ウォーターフォール要素
ソース価格ウォーターフォール要素メンバー・コード | ソース価格ウォーターフォール要素名 | 適合価格ウォーターフォール要素メンバー・コード | 適合価格ウォーターフォール要素名 |
---|---|---|---|
上限収益 |
上限収益 |
上限収益 |
上限収益 |
原価 |
原価 |
原価 |
原価 |
請求書収益 |
請求書収益 |
請求書収益 |
請求書収益 |
実勢マージン |
実勢マージン |
実勢マージン |
実勢マージン |
実勢収益 |
実勢収益 |
実勢収益 |
実勢収益 |
セグメント収益 |
セグメント収益 |
セグメント収益 |
セグメント収益 |
この項では、価格フラット・ファイル使用してシードされたコードに対するソース・ドメイン・メンバー名の値を構成する方法について説明します。次の表には、プレゼンテーション列からフラット・ファイル列および関連するソース・ドメイン・コードへの結合がまとめられています。
表B-70 ドメイン・マップ: 価格ウォーターフォール要素タイプ→適合価格ウォーターフォール要素タイプ
ソース価格ウォーターフォール要素メンバー・コード | ソース価格ウォーターフォール要素名 | 適合価格ウォーターフォール要素メンバー・コード | 適合価格ウォーターフォール要素名 |
---|---|---|---|
原価修正 |
原価修正 |
原価修正 |
原価修正 |
収益修正 |
収益修正 |
収益修正 |
収益修正 |
セグメント |
セグメント |
セグメント |
セグメント |
これらはfile_pwf_element_ds.csvファイルに含めることができます。また、前の項で説明したように、新しいソース/適合ドメイン・メンバーを入力できます。
単位を構成するには、Oracle BI Applications構成マネージャで外部適合ドメインを使用します。外部適合ドメインの構成方法の詳細は、第4.4.8項「外部適合ドメインの構成方法」を参照してください。
セマンティック・レイヤー(RPD)メタデータには、ユーザーの現行会計年、会計四半期、および会計期間などを格納するセッション変数が含まれています。複数の会計カレンダをサポートするには、ユーザーに割り当てられる元帳やビジネス・ユニットに基づいてユーザーのデフォルトの会計カレンダを取得し、次に、このデフォルトの会計カレンダに基づいて、現行会計年や四半期などを取得する必要があります。これを行うには、デプロイされたソース・システムに応じて適切な初期化ブロックを有効にして、その他のブロックはすべて無効にする必要があります。様々なソース・システムに関連のある初期化ブロック名を次に示します。複数のソース・システムをデプロイする場合は、それらのソース・システムの初期化ブロックも有効にする必要があります。
この機能に関連した初期化ブロックのセットは2つあります。
初期化ブロックに関連する元帳:
Oracle Fusion Applications: Ledgers_MCAL Fusion
E-Business Suite 11i: Ledgers_MCAL EBS11
E-Business Suite R12: Ledgers_MCAL EBS12
Oracle PeopleSoft: Ledgers_MCAL PSFT
初期化ブロックに関連する営業単位:
Oracle Fusion Applications: Operating Unit Orgs Calendar Fusion
E-Business Suite (すべてのバージョン): Operating Unit Orgs Calendar EBS
Oracle PeopleSoft: Operating Unit Orgs Calendar PSFT
初期化ブロックを有効にするには、次の手順に従ってください。
Oracle BI EE管理ツールで、BIメタデータ・リポジトリ(例: OracleBIAnalyticsApps.rpd)を編集します。
「管理」→「変数」の順に選択します。
「セッション」の「初期化ブロック」で、有効化する必要がある初期化ブロックを開きます。
「無効」チェック・ボックスの選択を解除します。
BIメタデータ・リポジトリ(RPDファイル)を保存します。
実績原価はE-Business Suiteのプロジェクト原価計算モジュールにある原価配分明細表から抽出され、原価明細ファクト(W_PROJ_COST_LINE_F)表にロードされます。E-Business Suiteでは、このファクトのドキュメント通貨が取引通貨になります。
注意: GL記帳日(原価配分時に)原価配分明細にのみ割り当てられ、支出項目レコードには割り当てられません。支出データは、企業カレンダ・ディメンションによってのみ分析可能で、GLカレンダでは分析できません。GL勘定が関連付けられるのはデータの配分時のみです。そのため、GL勘定による支出データの分析はできません。 |
原価ファクトの標準日付
原価ファクトの標準日付ディメンションは、配分明細表のPRVDR_GL_DATEに基づいています。一方、支出ファクトの標準日付ディメンションは、支出項目表のEXPENDITURE_DATEに基づいています。
複数のカレンダ日付ディメンションに、複数の組織のカレンダが格納されています。会計カレンダ(ディメンション - 会計カレンダ)によってデータを分析しているレポート内のレコードは、すべて同じカレンダを指している必要があります。このために、ダッシュボードのすべてのレポートには、プロジェクト・ビジネス・ユニットに対するフィルタが適用されます。プロジェクト・ビジネス・ユニットのすべての原価レコードが同じカレンダを指すようにするために、RCVR_GL_DATE列とRCVR_PA_DATE列を使用して、ファクト表のGL_ACCOUNTING_DT_WID列とPROJ_ACCOUNTING_DT_WID列にデータを移入します。支出OUビュー(原価ファクト内)は、企業カレンダを使用して構築することもできます。
原価ファクトのドメイン値
プロジェクト費用振替ステータスはドメイン値としてモデル化されていて、FSMで構成できます。
原価ファクトの増分ロジック
原価のファクト表の増分抽出ロジックは、原価配分明細表の「REQUEST_ID」フィールドに依存します。このロジックは、W_PROJ_ETL_PSパラメータ表によって簡便化されています。個別のODIインタフェースを使用することで、この表にはETLの実行時におけるソース表内の最大リクエストIDが格納されます。その後で、このIDはSDEタスク(SDE_ORA_PROJECTCOSTLINE)レベルのODI変数#EBS_REQUEST_ID_1に移入されます。これは、次の問合せを使用して初期化されます。SELECT COALESCE((SELECT PRE_REQUEST_ID FROM QUALIFY_DS(W_PROJ_ETL_PS) WHERE TBL_NAME = 'PA_COST_DISTRIBUTION_LINES_ALL'),0) FROM_DUAL()
注意: 増分更新後に、W_PROJ_COST_LINE_Fに一部の原価レコードが見つからない場合は、My Oracle Supportからパッチ9896800をダウンロードしてください。このパッチに含まれるTech Noteには、この事象の発生シナリオについての説明と、提案される解決策が掲載されています。 |
プロジェクト原価集計表の構成
支出項目のプロジェクト原価配分に関する情報をキャプチャするには、プロジェクト原価集計表(W_PROJ_COST_A)を使用します。初期ETLの実行とそれに続く増分ETLを実行する前に、プロジェクト原価明細集計表を構成する必要があります。初期ETLを実行する前に、プロジェクト原価明細集計ファクト表の時間集計レベルに対して、FSMでCOST_TIME_GRAINパラメータを構成する必要があります。 デフォルトでは、COST_TIME_GRAINパラメータの値はPERIODに設定されています。COST_TIME_GRAINパラメータに指定できる値は、次のとおりです。
PERIOD
QUARTER
YEAR
プロジェクト原価明細集計表は、初期ETLの実行時にベース表から完全にロードされます。この表のレコード数は、数百万件にも及ぶことがあります。そのため、増分ETLの実行後に、プロジェクト原価集計表がベース表から完全に再ロードされることはありません。Oracle Business Analytics Warehouseでは、ベース表の更新に伴い集計表を増分的に変更することで、増分集計の負荷が最小限になります。
このプロセスは次のとおりです。
Oracle Business Analytics Warehouseは、前回のETLの実行後にベース表で更新されるレコードを検索し、それらのレコードをW_PROJ_COST_LINE_TMP表にロードします。これらのレコードのメジャーは、(-1)で乗算されます。このタスクを担当するマッピングは、SIL_ProjectCostLinesFact_Derive_PreLoadImageです。
Oracle Business Analytics Warehouseは、前回のETLの実行後にベース表に挿入またはベース表で更新されるレコードを検索し、それらのレコードを符号を変えずに、W_PROJ_COST_LINE_TMP表にロードします。このタスクを担当するマッピングはSIL_ProjectCostLinesFact_Derive_PreLoadImageです。これは、PLP_ProjectCostLinesFact_Derive_PostLoadImageでベース表のレコードを更新または挿入する前に実行されます。
Oracle Business Analytics WarehouseはW_PROJ_COST_LINE_TMP表を集計し、W_PROJ_COST_A表と同じ粒度のW_PROJ_COST_A_TMPにロードします。
PLP_ProjectCostLinesAggregate_DeriveマッピングによりW_PROJ_COST_A集計表が検索され、その集計表に対して、既存のバケットの更新または新規のバケットの挿入が行われます(このマッピングはPLP_ProjectCostLinesAggregate_Load)。
E-Business Suiteの収益ファクトの構成
収益実績明細レコードはE-Business Suiteのプロジェクト原価計算モジュールにある収益/イベント配分明細表(PA_CUST_REV_DISTRIB_LINES_ALLとPA_CUST_EVENT_DIST_ALL)から抽出され、収益明細ファクト(W_PROJ_REVENUE_LINE_F)表にロードされます。
E-Business Suiteでは、収益取引通貨コードが、このファクトのドキュメント通貨コードになります。
注意: 収益配分のためのE-Business Suiteコンカレント・プログラム(PRC: 単一プロジェクトの収益草案の生成、PRC: プロジェクト範囲の収益草案の生成など)は、ETLを実行してOracle Business Analytics Warehouseをロードする前に実行する必要があります。 |
収益ヘッダー・ファクト(W_PROJ_REVENUE_HDR_F)のプライマリ・ソースは、PA_DRAFT_REVENUES表になります。請求金額や収益金額などの収益明細メトリックも、この表で集計されます。
収益ファクトの標準日付
収益ファクト標準日付ディメンションは、収益草案表のGL_DATEに基づいています。
収益ファクト・ステージング表
収益ファクト・ステージング表は、ヘッダーと明細レベルの両方の収益ファクト表をロードする共通のステージング表です。
収益ファクトの複数通貨サポート
前受収益、未請求売掛金、為替差益、為替差損などの一部のメトリックは、現地通貨とグローバル通貨のみで使用できます。グローバル通貨での収益金額については、w_proj_revenue_line_fとw_proj_revenue_hdr_fのそれぞれに3つの列が存在します。
収益ファクトのドメイン値
プロジェクト収益ステータスはドメイン値としてモデル化されていて、FSMで構成できます。
収益ファクトの増分ロジック
収益ファクト表の増分抽出ロジックは、収益配分明細表の「REQUEST_ID」フィールドに依存しています。このロジックはW_PROJ_ETL_PSパラメータによって簡便化されており、ETL実行時おけるソース表内の最大リクエストIDが個別のODIプロセスを通じて、この表に格納されます。その後、ODIで、次に示すSDE_ORA_ProjectRevenueLineタスクの変数に値を移入するために使用されます。
#EBS_REQUEST_ID_2
#EBS_REQUEST_ID_3
#EBS_REQUEST_ID_4
これらは、次の問合せを使用して初期化されます。
SELECT COALESCE((SELECT COALESCE(PRE_REQUEST_ID,0) FROM QUALIFY_DS(W_PROJ_ETL_PS) WHERE TBL_NAME ='PA_CUST_EVENT_RDL_ALL'),0) FROM_DUAL() SELECT COALESCE((SELECT COALESCE(PRE_REQUEST_ID,0) FROM QUALIFY_DS(W_PROJ_ETL_PS) WHERE TBL_NAME ='PA_CUST_REV_DIST_LINES_ALL'),0) FROM_DUAL() SELECT COALESCE((SELECT COALESCE(PRE_REQUEST_ID,0) FROM QUALIFY_DS(W_PROJ_ETL_PS) WHERE TBL_NAME ='PA_DRAFT_REVENUES_ALL'),0) FROM_DUAL()
プロジェクト収益集計表の構成
プロジェクト原価集計表(W_PROJ_REVENUE_A)は、プロジェクト収益配分に関する情報を取得するために使用します。初期ETLの実行とそれに続く増分ETLを実行する前に、プロジェクト収益明細集計表を構成する必要があります。
初期ETLを実行する前に、プロジェクト収益明細集計ファクト表の時間集計レベルに対して、FSMでREVENUE_TIME_GRAINパラメータを構成する必要があります。
デフォルトでは、REVENUE _TIME_GRAINパラメータの値はPERIODに設定されています。REVENUE_TIME_GRAINパラメータに指定できる値は、次のとおりです。
PERIOD
QUARTER
YEAR
プロジェクト収益明細集計表は、初期ETLの実行時にベース表から完全にロードされます。この表のレコード数は、数百万件にも及ぶことがあります。そのため、増分ETLの実行後に、プロジェクト収益集計表がベース表から完全に再ロードされることはありません。Oracle Business Analytics Warehouseでは、ベース表の更新に伴い集計表を増分的に変更することで、増分集計の負荷が最小限になります。
このプロセスは次のとおりです。
Oracle Business Analytics Warehouseは、前回のETLの実行後にベース表で更新されるレコードを検索し、それらのレコードをW_PROJ_ REVENUE_LINE_TMP表にロードします。これらのレコードのメジャーは、(-1)で乗算されます。このタスクを担当するマッピングは、SIL_Project RevenueLinesFact_Derive_PreLoadImageです。
Oracle Business Analytics Warehouseは、前回のETLの実行以降にベース表に挿入またはベース表で更新されるレコードを検索し、それらのレコードを符号を変えずに、W_PROJ_REVENUE_LINE_TMP表にロードします。このタスクを担当するマッピングはSIL_ProjectRevenueLinesFact_Derive_PreLoadImageです。これは、PLP_ProjectRevenueLinesFact_Derive_PostLoadImageでベース表のレコードを更新または挿入する前に実行されます。
Oracle Business Analytics WarehouseはW_PROJ_ REVENUE _LINE_TMP表を集計し、W_PROJ_REVENUE_A表と同じ粒度のW_PROJ_REVENUE_A_TMPにロードします。
PLP_ProjectRevenueLinesAggregate_DeriveマッピングによりW_PROJ_REVENUE_A集計表が検索され、その集計表に対して、既存バケットの更新または新規バケットの挿入が行われます(このマッピングはPLP_ProjectRevenueLinesAggregate_Load)。
E-Business Suiteのプロジェクト単位の構成方法
次のSQLを使用して、プロジェクト単位を取得します。
select lookup_code, meaning, description from fnd_lookup_values where lookup_type='UNIT' and LANGUAGE='US';
コードがまだマップされていない場合は、FSMでプロジェクト単位をウェアハウス(適合)単位にマップします。
詳細は、「ドメインおよびドメイン・マッピングの操作について」を参照してください。
プロジェクト単位は、OLTPソース・データベースで次のSQLを使用して取得します。コードがまだマップされていない場合は、プロジェクト単位を、FSMでコード化されたウェアハウス(適合)単位にマップします。次に例を示します。
select lookup_code, meaning, description from fnd_lookup_values where lookup_type='UNIT' and LANGUAGE='US';
このトピックでは、プロジェクト保留ファクトをPSFTアダプタ用に構成する方法について説明します。この項の内容は次のとおりです。
保留メトリックは、EBSアダプタおよびPSFTアダプタでサポートされます。EBSアダプタにとって唯一の正しい情報源は請求ファクトであるため、デフォルトでは、請求書明細ファクトに保留額がマップされます。一方、PSFTアダプタでは、これらのマッピングは無効なため、保留ファクトからソーシングする必要が生じます。そのため、請求書明細ファクトに定義したメトリックのマッピングを解除して、保留ファクトを有効にする必要があります。
変更を適用する前には、BIメタデータ・リポジトリ(RPDファイル)のバックアップを作成することをお薦めします。
Oracle BI EE管理ツールで、BIメタデータ・リポジトリ(OracleBIAnalyticsApps.rpdなど)をオンライン・モードで編集します。
「ビジネス・モデルとマッピング」レイヤーで、「ファクト - プロジェクト請求」から「Fact_W_PROJ_RETENTION_F_Retention_Amounts」論理表ソースを選択し、右クリックして「編集」を選択します。
「一般」タブを表示して、次のスクリーンショットに示されている「無効化」チェック・ボックスの選択を解除します。
BIメタデータ・リポジトリ(RPDファイル)を保存します。
デフォルトでは、保留に関連する金額が請求書明細ファクトにマップされています。PeopleSoftアダプタでは、このマッピングが無効なため、これらのメトリックをマップ解除する必要があります。
Oracle BI EE管理ツールで、BIメタデータ・リポジトリ(OracleBIAnalyticsApps.rpdなど)をオンライン・モードで編集します。
「ファクト - プロジェクト請求」に移動して、「請求済保留」メトリックを選択し、右クリックして編集します。
「列ソース」タブを表示し、Fact_W_PROJ_INVOICE_LINE_F_Invoice_Lineにマップされた定義を選択して、次のスクリーンショットに示すように「アンマップ」をクリックします。
次に示すFact_W_PROJ_INVOICE_LINE_F_Invoice_Lineのメトリックに対して、手順2と3を繰り返します。
合計保有金額
保留貸倒償却
整合性チェックを実行してエラーがないことを確認し、BIメタデータ・リポジトリを保存して、Oracle BI Enterprise Editionのキャッシュをクリアします。
Oracle BI ServerとOracle BI Presentation Servicesを再起動します。
ジョブ・ディメンションはHuman Resources Analyticsモジュールで維持します。
第B.2.89.2項「E-Business SuiteのProjects Analyticsにおけるプロジェクト顧客の構成方法」
第B.2.89.3項「E-Business SuiteのProjects Analyticsにおけるプロジェクト分類ディメンションの構成について」
タスク・ディメンションのデータは、E-Business Suiteのタスク表(PA_TASKS)と、次に示すその他のタスク関連のOLTP表がソースになります。
PA_PROJ_ELEMENTS
PA_PROJ_ELEMENT_VERSIONS
PA_PROJ_ELEM_VER_STRUCTURE
PA_PROJ_ELEM_VER_SCHEDULE
WBS_NUMBER、PRIORITY_CODE、SCHEDULE_START_DATE、SCHEDULE_END_DATEなどの属性は、これらの表がソースになります。Oracle BI Applicationsは、次のフィルタ条件を使用することで、最新バージョンの財務構造のみをサポートするようになります。
PA_PROJ_ELEM_VER_STRUCTURE.STATUS_CODE = 'STRUCTURE_PUBLISHED'
AND PA_PROJ_ELEM_VER_STRUCTURE.LATEST_EFF_PUBLISHED_FLAG = 'Y'
W_TASK_DH階層表には、W_TASK_Dのタスクごとにフラット化された階層が格納されます。これは、W_TASK_Dと同じ単位で、タイプIディメンションとしてモデル化されます。階層内のすべてのタスクは、次に示す列をサポートします。
TASK_NAME
TASK_NUMBER
WBS_LEVEL
WBS_NUMBER
W_TASK_D表とW_TASK_DH表の単位は同じであるため、ファクト表には、この表と結合するための個別の外部キーがありません。そのかわりに、タスク外部キーに対する結合があります。
デフォルトでは、Oracle BI Applicationsはフラット化された階層で20のレベルをサポートします。このレベルは、ベース、1から18、およびトップです。ベース・レベルは階層レコードを表し、トップ・レベルはプロジェクトの下の最上位階層になります。財務構造に、20を超えるレベルが含まれている場合は、スキーマとETLのレベル数を拡大することで、すべてのレベルをサポートできます。
E-Business Suiteのプロジェクト・タスク階層ディメンションを拡張する手順は次のとおりです。
ODIデザイナ・ナビゲータで、「モデル」タブを表示し、W_TASK_DHS表およびW_TASK_DH表で必要とされる新しいレベルごとに、チェンジ・キャプチャ列(TASK_NUMBER、WBS_LEVELおよびWBS_NUMBER)を追加します。
次のように、SDEおよびSILOSフォルダ内のインタフェースを拡張します。
ソースに応じて、EBSまたはPSFTの適切なSDEフォルダに移動します。
新しい列に適切なマッピングを指定して、適切なメイン・インタフェース(たとえば、SDE_ORA_TaskDimensionHierarchy.W_TASK_DHSまたはSDE_PSFT_TaskDimensionHierarchy.W_TASK_DHS)を編集して更新します。
SILOSフォルダを開き、ODIインタフェースSIL_Project_TaskDimensionHierarchyを編集して更新します。
「パッケージ」フォルダを開き、再生成するシナリオを右クリックして、SDE/SILOSシナリオを再生成します。
次に示すBIメタデータ・リポジトリ(RPDファイル)のオブジェクトを更新するには、Oracle BI EE管理ツールも使用する必要があります。
物理レイヤーのW_TASK_DH表。
論理レイヤーの「ディメンション - タスク階層」論理表とタスク階層ディメンション。
プレゼンテーション領域内のすべてのタスク階層プレゼンテーション表。
デフォルトでは、E-Business SuiteのPA_PROJECT_CUSTOMERS表には「PRIMARY」関係コードしかありません。そのため、ODIフィルタに値を追加することになります。この値は、プロジェクト・ディメンションのソース抽出マッピングで、プロジェクト顧客を取得するために使用します。ユーザーは、関係値として「OVERRIDE CUSTOMER」などの追加の値を定義できます。この場合は、次のように、すべての追加値が含まれるようにフィルタを編集する必要があります。
E-Business SuiteのProjects Analyticsでプロジェクト顧客を構成する手順は次のとおりです。
ODIデザイナ・ナビゲータで、ODIリポジトリに接続します。
適切なフォルダを開きます(ソースに応じて、SDE_ORA_11510_AdaptorフォルダやSDE_ORA_R12_Adaptorフォルダなど)。
SDE_ORA_ProjectDimensionフォルダを開き、SDE_ORA_Project.W_PROJECT_DS.LKP_PROJ_CUSTインタフェースを開いて、「クイック編集」タブをクリックします。
「フィルタ」タブを開いて、2番目のフィルタの式列を編集します。
既存のSQLを削除して、次のサンプルSQLを追加します。ここでは、値として「PRIMARY」および「OVERRIDE CUSTOMER」を使用することを想定しています。構成内容に応じて値を変更してください。
この値をいずれの関係からも独立させる場合は、PROJECT_RELATIONSHIP_CODE -UPPER(PA_PROJECT_CUSTOMERS.PROJECT_RELATIONSHIP_CODE (+)) IN ('PRIMARY' .'OVERRIDE CUSTOMER')のフィルタを削除する必要があります。
注意: この参照により複数の顧客が返される場合は、常に1つの行が返されるように、IDに対する最大値を適用する必要があります。
マッピングが有効になっていることを確認し、「OK」を押してインタフェースを保存します。
「パッケージ」フォルダを開き、再生成するシナリオを右クリックして、シナリオを再生成します。
すべてのプロジェクトは、オプションで様々なカテゴリに分類できます。これらのカテゴリ内で、プロジェクトはさらに様々な分類コードに分類できます。アプリケーション内でのこれらの分類カテゴリの定義方法に応じて、一部のカテゴリについては、1つのプロジェクトを複数の分類コードで分類できます。
プロジェクト分類表(W_PROJ_CLASSIFICATION_D)の単位は、プロジェクト、分類カテゴリおよび分類コードになります。このプロジェクトのファクトには、プロジェクト分類ディメンションと結合するための明示的な外部キーは存在しません。そのかわりに、プロジェクト外部キーで結合が行われます。プロジェクトに対する分類カテゴリの指定はオプションです。そのため、BIメタデータ・リポジトリ(RPDファイル)におけるファクトとプロジェクト分類ディメンションの間の論理結合は、右側外部結合として設定されています。これにより、プロジェクトが分類されていない場合でもレコードは失われません。
注意: 複数の分類カテゴリに1つの特定の分類コードが存在する可能性があります。このため、二重カウントを防ぐために、レポート属性の1つに分類コードがあるレポートでは、分類カテゴリを固定化することが重要です。1つのプロジェクトが同じ分類の下の複数の分類カテゴリに属している場合、そのプロジェクトのメトリック(原価や収益など)が二重にカウントされることになるからです。
資金は資金明細に基づいています。資金明細とは、プロジェクトやタスクに対して作成された割当てを表します。明細レベルの資金情報は資金明細ファクト(W_PROJ_ FUNDING_ LINE_F)内に保持されており、これはE-Business Suiteの請求モジュールにあるPA_PROJECT_FUNDINGS表に基づいています。また、要約資金表(PA_SUMMARY_PROJECT_FUNDINGS)からデータが抽出され、未基本編成金額、基本編成済金額、請求額、見越計上済収益などの追加のメトリックが取得されます。これらは資金明細ファクトでは提供されません。資金ヘッダー・ファクト(W_PROJ_FUNDING_HDR_F)で入手できる場合があります。ODI ETLジョブを実行する前に、E-Business Suiteで「PRC: プロジェクト要約金額のリフレッシュ」プロセスを実行して、この表を更新する必要があります。
注意: E-Business Suiteでは、資金通貨が、このファクトのドキュメント通貨になります。
Project_Funding_Category: 資金割当てタイプの分類に使用します。Project_Funding_Level: このフラット・ファイルは、資金明細がタスクとプロジェクトのどちらに対するものなのかを示すために使用します。デフォルトのメトリック定義では使用されません。
注意: OLTPアプリケーションでは、資金ファクトの標準日付のGL記帳日は移入されません。したがって、Oracle Business Analytics Warehouseでは、E-Business SuiteのGL記帳日は資金割当て日付に基づいており、プロジェクトOUのGLカレンダを使用します。これにより、GLカレンダに対する相互機能分析が可能になります。たとえば、資金ファクトにGL記帳日が存在しない場合、会計年度による資金と請求の相互分析ができません。GLカレンダに基づく分析を実行しない顧客は、企業カレンダに基づく分析ができます。
GL記帳日(資金割当て日付)はこの表の標準日付で、グローバルな為替レートの計算にも使用します。
E-Business Suite V12アダプタおよびPeopleSoft V90アダプタの場合は、プロジェクトGL調整ソリューションがデフォルトでサポートされます。このソリューションをE-Business Suite V11510アダプタでサポートするには、次に示す手順を実行する必要があります。この手順には、PLP GL調整ODIインタフェースに結合を追加する手順が含まれます。
注意: E-Business Suite V11510アダプタには、追加の結合が必要になります。これは、補助元帳会計処理はE-Business Suite V12以降に導入されたものであり、E-Business Suite V11510とV12では、プロジェクトとGLのソース表の結合が異なるためです。
E-Business Suite 11.5.10のプロジェクトGL調整ソリューションを構成する方法は次のとおりです。
ODIデザイナ・ナビゲータで、ODIリポジトリに接続します。
「BI Appsプロジェクト」→「マッピング」→「PLP」→「PLP_Project_GLReconciliationFact」に移動します。
変更を行う前に、「PLP_Project_GLReconciliationFact」フォルダを右クリックして、現在のフォルダのバージョンを作成します。
説明文「Before adding GL Account join for 11510 source」を入力して、「OK」をクリックします。
次の3つの一時インタフェースを変更します。
PLP_Project_GLReconciliationFact.SQ_AGG_CDL_AMOUNTS
PLP_Project_GLReconciliationFact.SQ_W_PROJ_GL_RECNCLIATION_F_A (「不一致がある原価配分」データセット)
PLP_Project_GLReconciliationFact.SQ_W_PROJ_GL_RECNCLIATION_F_U
「BI Appsプロジェクト」→「マッピング」→「PLP」→「PLP_Project_GLReconciliationFact」に移動します。
一時インタフェースを開いて、「クイック編集」タブに移動します。
「ソース」を開いて、「ソースの追加」をクリックします。
「ソース・ウィザード」ダイアログ・ボックスが開きます。「インタフェース」タブをクリックして、LKP_W_GL_ACCOUNT_Dを検索します。PLPフォルダでルックアップ・インタフェースを選択して、LKP_W_GL_ACCOUNT_Dという別名を付けます。「一時インタフェースを導出表として使用(下位選択)」オプションを選択して、「OK」をクリックします。「自動マッピングを実行しますか。」というODIプロンプトが表示された場合は、「いいえ」を押します。
「ソース・ウィザード」ダイアログ・ボックスが開きます。「インタフェース」タブをクリックして、LKP_W_GL_ACCOUNT_Dを検索します。PLPフォルダでルックアップ・インタフェースを選択して、LKP_W_GL_ACCOUNT_Dという別名を付けます。「一時インタフェースを導出表として使用(下位選択)」オプションを選択して、「OK」をクリックします。「自動マッピングを実行しますか。」というODIプロンプトが表示された場合は、「いいえ」を押します。
この手順では、次の2つの結合を追加します。
- W_GL_LINKAGE_INFORMATION_GとLKP_W_GL_ACCOUNT_Dとの結合。
- W_PROJ_COST_LINE_FとLKP_W_GL_ACCOUNT_Dとの結合。
e.1 「クイック編集」タブの「結合」セクションを開いて、「結合の追加」をクリックします。
e.2 「左側のソース」で「General Ledger Linkage Information」を、「右側のソース」で「LKP_W_GL_ACCOUNT_D」を選択します。次のようにフィールドを結合します。
W_GL_LINKAGE_INFORMATION_G.GL_ACCOUNT_ID = LKP_W_GL_ACCOUNT_D.INTEGRATION_ID AND W_GL_LINKAGE_INFORMATION_G.DATASOURCE_NUM_ID = LKP_W_GL_ACCOUNT_D.DATASOURCE_NUM_ID
e.3 「結合タイプ」で「左の外部結合」を選択して、「OK」をクリックします。
e.4 「結合の追加」を再度クリックします。「左側のソース」で「W_PROJ_COST_LINE_F」を、「右側のソース」で「LKP_W_GL_ACCOUNT_D」を選択します。次のようにフィールドを結合します。
W_PROJ_COST_LINE_F.COST_GL_ACCOUNT_WID=LKP_W_GL_ACCOUNT_D.ROW_WID AND W_PROJ_COST_LINE_F.CR_GL_ACCOUNT_WID=LKP_W_GL_ACCOUNT_D.ROW_WID
e.5 「結合タイプ」で「内部結合」を選択して、「OK」をクリックします。
e.6 「結合」セクションで右方向にスクロールして、W_PROJ_COST_LINE_FとLKP_W_GL_ACCOUNT_Dの間に新しく追加した結合を編集します。
e.7 次のように結合条件を編集します。
W_PROJ_COST_LINE_F.COST_GL_ACCOUNT_WID = COALESCE(LKP_W_GL_ACCOUNT_D.ROW_WID,#ETL_UNSPEC_NUM) OR W_PROJ_COST_LINE_F.CR_GL_ACCOUNT_WID = COALESCE(LKP_W_GL_ACCOUNT_D.ROW_WID,#ETL_UNSPEC_NUM)
e.8 COALESCE関数を追加するのみでなく、結合条件をORに変更してください。「OK」をクリックします。
e.9 GLリンケージとGL勘定科目参照との間の「左の外部結合」で、「順序付き」チェック・ボックスを選択します。
インタフェースを保存します。
次の3つの一時インタフェースのすべてで、手順aからeを繰り返します。
PLP_Project_GLReconciliationFact.SQ_AGG_CDL_AMOUNTS
PLP_Project_GLReconciliationFact.SQ_W_PROJ_GL_RECNCLIATION_F_A (「不一致のある原価配分」データセットのみ。「不一致のある仕訳明細」データセットへの結合の追加は不可)
PLP_Project_GLReconciliationFact.SQ_W_PROJ_GL_RECNCLIATION_F_U
シナリオを再生成します。
3つの一時インタフェースをすべて変更して保存したら、「PLP_Project_GLReconciliationFact」→「パッケージ」→「PLP_Project_GLReconciliationFact」→「シナリオ」に移動します。シナリオ「PLP_PLP_PROJECT_GLRECONCILIATIONFACT」を右クリックし、「再生成」をクリックします。
「シナリオの再生成」ダイアログ・ボックスで「OK」をクリックします。
「シナリオ変数」ダイアログで、「起動パラメータ」ドロップダウン・リストの「すべてを使用」を選択して、「OK」をクリックします。
この項では、Project AnalyticsのGL調整の概要について説明します。この項の内容は次のとおりです。
補助元帳から一般会計への調整は、会計プロセスにおける一般的なタスクです。調整プロセスには、一般会計(GL)と補助元帳(プロジェクトなど)の残高勘定の比較が伴います。その後で、GLと補助元帳の間の勘定科目の残高差異は、一致しない仕訳入力を見つけることで説明(調整)されます。この差異は、プロジェクト・モジュールの原価/収益配分プロセスの非同期性と、財務モジュールでのGL仕訳の作成/転記の非同期性が原因で発生することがあります。たとえば、原価配分が補助元帳には転送されても、GLには対応する仕訳が作成されていない(または転記されていない)ことがあります。
調整を行うことで、GLの数値に間違いがないことと、それらの数値に対応するドリルダウンの配分で同期されることが保証されます。これらの数値が財務諸表の生成に使用されるため、これは重要なことです。
新機能
プロジェクト補助元帳とGLを調整するプロジェクト会計担当を支援するために、Oracle Project Analyticsには、6つの状況(ユースケース)を識別する調整ソリューションが導入されています。このソリューションにより、GLとプロジェクト補助元帳の間に不一致がある理由が説明されます。後述の第3項では、これらのユースケースとそれらが意味することについて、アダプタごとに特定して説明しています。
Oracle Business Intelligence Applicationsリリース11.1.1.7.1では、プロジェクト原価および収益トランザクションに対して調整ソリューションを利用できます(E-Business Suite 11.5.10、E-Business Suite R12xおよびPeopleSoft 9xソース・システムの場合)。
このソリューションのために、Oracle Business Intelligence Applicationsには、2つの新しいサブジェクト領域と30以上の新しいメトリックが導入されています。カタログには、「プロジェクト・エグゼクティブ」ダッシュボードの2つの新しいダッシュボード・ページと22のレポートが含まれています。このダッシュボード・ページのレポートには、ユースケースごとに検出した例外の数と、それらの合計金額が示されます。ユーザーは、これらのレポートを時間別、組織別およびプロジェクト別にスライスできます(原価明細および収益明細に関連する場合)。また、これらのレポートを時間別、元帳別および科目別にスライスすることもできます(仕訳明細に関連する場合)。
これらのレポートは、プロジェクト補助元帳とGLを調整するために、どこで処理を実行する必要があるかを簡単に見つけられるように設計されています。そのために、レポートでは、補助元帳とGLとの間の相違の原因である原価明細、収益明細、および仕訳明細が特定されます。
実装時には(また、ユーザーのソース・システムによっては)、一部のユースケースのサポートを有効にするために、ETLコードとメタデータに対するカスタマイズが必要になることがあります。このドキュメントでは、E-Business Suiteソース・システムとPeopleSoftソース・システムについて、これらの手順を含むFSMタスクと、それらのソース・システムごとのユースケースを示します。
プロジェクトGL調整ETLは、特定の期間に対して実行します。ユーザーは、次の2つの変数を構成することで、調整の問題を特定する期間を指定できます。これらの変数はNULLにしないでください。
PROJ_GL_PERIODS_TO_LOAD
調整に含める期間の数を指定します。
デフォルト(インストール済)値: 1。
許容値: 正の整数0、1、2、3など。
PROJ_GL_RECON_DT
これは、調整用のデータのロード時における、期間数のカウントの開始日です(時間を遡ります)。
デフォルト(インストール済)値: DEFAULT。この変数の値がDEFAULTの場合は、現在の期間を特定するためにSYSDATEが使用されます。
許容値: 文字列「DEFAULT」またはYYYY-MM-DD形式の日付。
例
表B-71 例
サンプル値 | 動作 |
---|---|
PROJ_GL_RECON_DT: DEFAULT PROJ_GL_PERIODS_TO_LOAD: 1 |
これらの変数がどちらもデフォルト値の場合、ETLが実行されて、現在の期間(SYSDATEに基づく)と1つ前の期間に対するデータの調整が行われます。 |
PROJ_GL_RECON_DT: DEFAULT PROJ_GL_PERIODS_TO_LOAD: 3 |
これらの値の場合、ETLが実行されて、現在の期間(SYSDATEに基づく)と3つ前までの期間に対するデータの調整が行われます。 |
PROJ_GL_RECON_DT: 2012-12-31 PROJ_GL_PERIODS_TO_LOAD: 1 |
これらの値の場合、ETLが実行されて、2012年12月31日が含まれる期間と1つ前の期間に対するデータの調整が行われます。 そのため、カレンダが月単位の場合は、現在の期間(ここでは、2012年12月)と1つ前の期間(ここでは、2012年11月)に対する調整が行われます。 |
PROJ_GL_RECON_DT: 2012-06-30 PROJ_GL_PERIODS_TO_LOAD: 3 |
これらの値の場合、ETLが実行されて、2012年6月30日が含まれる期間と3つ前までの期間に対するデータが調整されます。 そのため、カレンダが月単位の場合、現在の期間(ここでは、2012年6月)と、その前の期間(ここでは、2012年3月、2012年4月、2012年5月)に対する調整が行われます。 |
デフォルトでサポートされているユースケースに加え、このリリースのプロジェクトGL調整ソリューションでは、GLに手動で作成したプロジェクト仕訳を識別するという追加のユースケースもサポートされています。
EBS R11.5.10およびR12.xでは、ほとんどのユーザーは手動で仕訳を作成したときに、その仕訳をプロジェクトに関連付けるために、ソースの付加フレックスフィールドにプロジェクト番号または識別子が移入されるように構成します。このような場合、それらの手動で作成した仕訳を抽出および報告するようにETLコードをカスタマイズできます。そのため、ユーザーがEBSアプリケーションのGL仕訳ヘッダー表または明細表に付加フレックスフィールドを作成していて、その付加フレックスフィールドを、手動で作成した仕訳のプロジェクト番号の移入に使用すると、それらのトランザクションはプロジェクトGL調整ODIインタフェースで識別できます(抽出時のJOURNAL_SOURCEフィールドにデータを移入する部分の式をカスタマイズした場合)。
デフォルトでは、JOURNAL_SOURCEはGL_JE_HEADERSから直接移入され、プロジェクト補助元帳にリンクされることはないため、そのようなトランザクションは除外されます。
このドキュメントでは、手動で作成した仕訳入力を識別するように、ODIインタフェースのETLコードをカスタマイズする手順の例について説明します。この説明の前提は次のとおりです。
表GL_JE_HEADERSの付加フレックスフィールドATTRIBUTE1が、プロジェクト番号(または、その他のプロジェクト・キー)を格納するために使用されていること。
プロジェクトGL調整手動仕訳を構成する手順は次のとおりです。
ODIデザイナ・ナビゲータで、ODIリポジトリに接続します。
「BI Appsプロジェクト」→「マッピング」→「<EBSアダプタのフォルダ> - SDE_ORA_GLJournalsFact - SDE_ORA_GLJournalsFact.W_GL_OTHER_FS_SQ_GL_JE_LINES」に移動します。
一時インタフェースを開き、JE_SOURCEの式を調べます。
デフォルトでマップされている式は、GL_JE_HEADERS.JOURNAL_SOURCEです。
JE_SOURCEフィールドを次の値に変更します。
GL_JE_HEADERS.JE_SOURCE || (CASE WHEN GL_JE_HEADERS.CONTEXT = 'Project Context' AND GL_JE_HEADERS.ATTRIBUTE1 IS NOT NULL THEN '~PA' ELSE NULL END)
通常は、この式を次のようにカスタマイズする必要があります。
GL_JE_HEADERS.JOURNAL_SOURCE || (CASE WHEN <Manual Entries for Projects> THEN '~PA' ELSE NULL END CASE)
インタフェースを保存します。
SDE_ORA_GLJOURNALSFACTのシナリオを再生成します。
次回のETL実行時には、プロジェクトに手動で作成した仕訳については、W_GL_OTHER_F表のJOURNAL_SOURCEフィールドに値「Manual~PA」が移入されるようになり、それらはプロジェクトに関連する手動仕訳としてGL調整ODIインタフェースで識別されるようになります。
Oracle Financial Analyticsでは、重複する年齢調べバケット範囲がサポートされていません。Fusion ApplicationsまたはE-Business Suiteで年齢調べバケットを設定する場合、Financial AnalyticsのAPおよびAR年齢調べ分析で、重複しない年齢調べバケットのみを使用する必要があります。さらに、未払金額と期限超過金額を別々のバケットに分離するようにバケットを定義している場合は、未払トランザクションまたは期限超過トランザクションのどちらか一方を選択するように、バケットのdays_from値とdays_to値を定義していることを確認します。これを行うには、期限超過バケットのdays_fromが1または正の数値(0または負の数値ではない)から始まるようにします。次の例に、サポートされる年齢調べバケットの範囲を示します。
サポート対象:
a) -60 days to -31 days b) -30 days to -11 days c) -10 days to 0 days d) 1 days to 10 days e) 11 days to 30 days f) 31 days to 60 days and so on.
この例では、a/b/cは未払バケットです。d/e/fは期限超過バケットです。バケット範囲には重複がなく、すべての期限超過バケットが1から始まる正しい状態で定義されています。
サポート対象外:
a) -60 days to -31 days b) -30 days to -11 days c) -10 days to -1 days d) 0 days to 10 days e) 9 days to 30 days f) 31 days to 60 days and so on.
この例では、バケット範囲が正しく定義されていません。バケットdが0から始まっていることに注目してください。そのため、このバケットに、未払の請求書と期限超過の請求書が一緒に保持されている可能性があります。その結果、期限超過バケットのみを示すレポートに、期限超過ではない請求書が記載されてしまう可能性があります。さらに、バケットdとeは重複しています。そのため、いくつかの請求書が両方のバケットで報告されてしまう可能性があり、合計の未回収金額が本来の金額よりも多く表示されることになります。
サポート対象外:
a) -60 days to -31 days b) -30 days to -11 days c) -10 days to -6 days d) -5 days to 5 days e) 6 days to 30 days f) 31 days to 60 days and so on.
この例では、バケット範囲が正しく定義されていません。ここでは、バケットdが負の数値から開始され、正の数値で終了します。前の例と同様に、このバケットには未払の請求書と期限超過の請求書が一緒に保持されている可能性があります。
目的
タイムカード入力ステータス・ディメンションは、タイムカード入力のステータスを理解する鍵になります。タイムカード入力ステータスは、報告時間と処理時間(支給対象とも呼ばれる)との間で異なります。オラクル社は、報告と処理の両方に対して、ドメイン・メンバー・マッピングを提供しています。
オプションまたは必須
このタスクは必須です。
適用対象
E-Business SuiteとPeopleSoft
詳細なタスクの説明
タイムカード入力ステータス・ディメンションのドメインを構成することは、時間レポートのエントリをウェアハウス・レポートのカテゴリおよびサブカテゴリに正常に帰属させるための鍵になります。
「ソース・レポート済タイムカード入力ステータス・コード」→「レポート済タイムカード・ステータス・コード」
このタスクは必須です。ソース・レポート済タイムカード入力ステータスを付属のターゲット・レポート済タイムカード・ステータス・ドメイン・メンバーにマップする方法を指定するために使用します。WORKING (作業中)、APPROVED (承認済)などのターゲット・ドメイン・メンバーは、付属のメトリック、ダッシュボード、およびレポートで使用されます。ターゲット・ドメインは拡張可能です。このドメインへの追加は可能ですが、削除はできません。
E-Business Suiteの例
ソース・レポート済タイムカード入力ステータス・コードは、FND参照(HXC_APPROVAL_STATUS)の値に基づいています。
実装の例
表B-72 ターゲット・メンバー・コードの例
ソース・メンバー・コード(名前) | ターゲット・メンバー・コード(名前) |
---|---|
APPROVED (承認済) |
APPROVED (承認済) |
ERROR (エラー) |
ERROR (エラー) |
REJECTED (却下済) |
REJECTED (却下済) |
SUBMITTED (提出済) |
SUBMITTED (提出済) |
WORKING (作業中) |
WORKING (作業中) |
PeopleSoftの例
ソース・レポート済タイムカード入力ステータス・コードは、PSXLATITEM (REPORTED_STATUS)の値に基づいています。
実装の例
表B-73 ターゲット・メンバー・コードの例
ソース・メンバー・コード(名前) | ターゲット・メンバー・コード(名前) |
---|---|
AP (承認済) |
APPROVED |
CN (取消済) |
CANCELLED |
DN (拒否済) |
REJECTED |
IE (エラー) |
ERROR |
IP (処理中) |
IN_PROCESS |
NA (承認要) |
SUBMITTED |
NW (新規) |
WORKING |
PR (処理済) |
PROCESSED |
PB (差戻済) |
PUSHED_BACK |
SV (保存済) |
WORKING |
提出済(SB) |
SUBMITTED |
無効化(VD) |
VOIDED |
「ソース処理済タイムカード入力ステータス・コード」→「処理済タイムカード入力ステータス・コード」
このタスクは必須です。
処理済タイムカード入力ステータスにマップするソース処理済タイムカード入力ステータスを指定するために使用します。ESTIMATE (見積)、TRNSFRD_TO_PAY (給与に転送済)などのターゲット・ドメイン・メンバーは、付属のメトリック、ダッシュボード、およびレポートで使用されます。ターゲット・ドメインは拡張可能です。このドメインへの追加は可能ですが、削除はできません。
E-Business Suiteの例
Oracle EBS (HXT_)では、ソース処理済タイムカード入力ステータスがバッチ・ステータスになります。
Oracle EBS (HXC_)では、ソース処理済タイムカード入力ステータスが取得ステータスと取得中のアプリケーションの組合せになります。
実装の例
表B-74 ターゲット・メンバー・コードの例
ソース・メンバー・コード(名前) | ターゲット・メンバー・コード(名前) |
---|---|
SUCCESS:PAY (給与により取得済) |
TRNSFRD_TO_PAY (給与に転送済) |
SUCCESS:PA (プロジェクトにより取得済) |
TRNSFRD_TO_PROJ (プロジェクトに転送済) |
SUCCESS:PO (購買により取得済) |
TRNSFRD_TO_PURCH (購買に転送済) |
PeopleSoftの例
PeopleSoftでは、ソース処理済タイムカード入力ステータスは、PSXLATITEM (PAYABLE_STATUS)になります。
実装の例
表B-75 ターゲット・メンバー・コードの例
ソース・メンバー・コード(名前) | ターゲット・メンバー・コード(名前) |
---|---|
OE (オンライン見積) |
ONLINE_ESTIMATE (オンライン見積) |
NA (承認要) |
NEEDS_APPROVAL (承認要) |
ES (見積) |
ESTIMATED (見積) |
AP (承認済) |
APPROVED (承認済) |
CL (クローズ済) |
<値なし> |
SP (給与に送信済) |
<値なし> |
RP (給与で却下済) |
<値なし> |
TP (給与で取得) |
TAKEN_BY_PAY (給与で取得) |
PD |
<値なし> |
DL |
<値なし> |
IG |
<値なし> |
RV |
<値なし> |
NP |
TRNSFRD_TO_PROJ (プロジェクトに転送済) |
DN |
<値なし> |
PB |
<値なし> |
目的
この項では、ソースの給与バランス、給与支給、給与控除、給与税からOracle Business Analytics Warehouseの給与要約メジャーへのドメイン値を使用したマッピングについて説明します。
HR Analyticsの給与モデルには、2つのファクト表(詳細ファクト表と要約ファクト表)が含まれています。詳細ファクト表には、ソース・システムから抽出されたすべてのバランス(EBS Payrollの場合)と支給/控除/税(PeopleSoft North Americanおよびグローバル・ペイロールの場合)を個別の行に保持します。この表は、詳細レポートとアドホック分析に使用されます。
分析レポートをサポートするために、要約ファクト表には、デフォルトの要約メジャーのセットが用意されています。ソースの給与バランスは、要約メジャーにマップされ、要約ファクト表にロードされます。要約メトリックには、複数の給与バランスをマップできますが、この場合、要約メジャーを形成するために個別のソース・バランスが合計されます。
基本給が通常給与になる場合、支給項目合計は通常給与と賞与になり、税額合計は所得税と社会保険税になります。
ソースからターゲット・バランスへのマッピングは、次に示すように実行する必要があります。
通常給与は、Pay_Baseと支給項目合計の要約メジャーにマップされます。
賞与は、支給項目合計にマップされます(支給項目合計 = 通常給与 + 賞与)。
所得税と社会保険税は、税額合計にマップされます(税額合計 = 所得税 + 社会保険税)。
メジャーの加算性を確保するために、実行バランスのみをサポートしています。給与計算実行ごとに、処理された実際の実行バランスが格納されます。これらはコンテキストで分割されないため、時間を通じて実行バランスを組み合せて上位のバランスを形成できます(たとえば、PTD、MTD、YTDなど)。
ソース・バランスの要約メジャーへのマッピングが構成マネージャで行われていない場合、給与要約ファクト表にはいかなるデータもロードされません。このため、要約ファクト表に基づくレポートがデータを返さなくなります。
オプションまたは必須
必須です(要約ファクト表に基づくデフォルトのHR Analytics給与レポートは、ソース・バランスのマッピングが構成されていないと値を返さないため)。
詳細なタスクの説明
次の図は、ソースのバランスをターゲットの要約メジャーにマッピングするために使用するドメインを示しています。
ソースの給与バランスは、ターゲットの要約メジャーに2通りの方法でマッピングできます。
- 1対1のマッピング(W_PAY_BALANCEドメインを使用)。
- 1対多のマッピング(W_PAY_MAP_FACTOR_xxxxドメインを使用)。
1対1のマッピングの場合は、Oracle BI Applications構成マネージャで、ソース・バランスを要約メジャーに直接マッピングします。
たとえば、基本給というソース・バランスがある場合、そのソース・バランスを、構成マネージャの「ドメイン・マッピング」を使用して、PAY_BASE要約メジャー・コードにマップできます。
要約メジャーPAY_BASEを構成するソース・バランスが複数(Earns1、Earns2)ある場合は、複数のソース・バランスを1つの要約メジャーにマッピングできます。
ソース・バランスは、要約メジャーにデータを移入するために集計されます。
PAY_BASE = Earns1 + Earns2
1対1のバランス・マッピングの手順
次の手順を実行して、ソース・バランスをウェアハウス要約メジャーにマップします。
ETLで抽出するソース・バランスを特定します。
バランスの抽出の制限については、タスク「BIバランス・グループへのバランスの追加方法」を参照してください。
ドメインETLを実行して、Oracle BI Applications構成マネージャにソース・ドメインを抽出します。
構成マネージャでファクト・グループを給与ファクト・グループとして使用して、ドメインETLロード計画を作成します。
ロード計画を実行します。これにより、構成マネージャのスキーマにソース・ドメインが抽出されます。
ソース・バランスを対応する要約メジャーにマップします。
「ドメイン管理」の「ソース・ドメインの管理」に移動して、ソース・ドメインにデータが移入されているかどうかを調べます。
「ドメイン管理」の「ウェアハウス・ドメインの管理」に移動して、ターゲット・ドメイン(要約メジャー)が存在することを確認します。
「ドメイン・マッピングおよび階層の管理」に移動して、ソース・バランスを要約メジャーにマッピングします。
「ドメイン・メンバー・マッピング」セクションの「編集」ボタンをクリックして、ソース・ドメインをターゲット・ドメインにマップします。
保存して閉じます。
メイン・ロード計画を実行して、Oracle Business Analytics Warehouseをロードします。
特定されたバランスが、給与詳細ファクト表に個別の行としてロードされます。
手順3で行ったマッピングのとおり、要約ファクト表に要約メジャーがロードされます。
多対1のバランス・マッピングの手順
多対1のマッピングでは、様々なバランスを使用して1つの要約メジャーを導き出すこともできます。
たとえば、次のような計算を使用して、NET_PAYを導き出せます。
Earns1 + Earns2 – Ded1 – Ded2 (Earns1、Earns2、Ded1およびDed2はソース・バランス)。
そのためには、前述のソース・バランスをウェアハウス・ドメインW_PAY_MAP_FACTOR_PAY_NETにマップする必要があります。
前述の手順1から3.aを実行します(「1対1のバランス・マッピングの手順」の項)
「ウェアハウス・ドメインの管理」に移動して、W_PAY_MAP_FACTORドメイン・コードを検索します。
ドメイン・メンバー・コードとして、必要な乗数を追加できます。たとえば、バランスが1回追加されるようにする場合は1。1回差し引かれるようにする場合は–1。
「ドメイン・マッピングおよび階層の管理」に移動して、ドメインW_PAY_MAP_FACTORを検索します。
差引支給額ドメイン・マッピングを選択して、「ドメイン・メンバー」セクションの「編集」ボタンをクリックします。
この画面では、ソース・バランスをバランス乗数にマップできます。
たとえば、NET_PAYがEarns1 + Earns2 – Ded1 – Ded2として計算される場合、ソースのEarns1は1に、Earns2は1に、Ded1は–1に、Ded2は–1にそれぞれマップされます。
各従業員について、NET_PAYは前述の計算式で支払期間ごとに計算され、給与要約ファクト表のPAY_NET列にロードされます。
メイン・ロード計画を実行して、ソースからウェアハウスにバランスを抽出します。
特定されたバランスが、給与詳細ファクト表に個別の行としてロードされます。
手順3で行ったマッピングのとおり、要約ファクト表に要約メジャーがロードされます。
付属の給与要約メジャーのリスト
FLEX_BALANCEx要約メジャーは、初期設定の要約メジャーに適合しないソース・バランスをマップするために使用できます。フレックス残高リストは、カスタマイズの一環として拡張できます。
次のリストは、付属の給与要約メジャーについてのタブ区切りデータ(要約メジャー・コード、カテゴリ、および説明)を示しています。
SUMMARY MEASURE CODE CATEGORY DESCRIPTION BEN_COST_EMPLOYEE Benefits Benefit costs paid by an employee such as employee premium for medical, dental, vision, disability and life insurance. BEN_COST_EMPLOYER Benefits Benefit costs paid by the employer such as employer premium for medical, dental, vision, disabilility, and life insurance, retirement funding and educational assistance, et., Employer-paid benefit cost is a key metric in analyzing employee total compensation and workforce cost. BEN_TAXABLE Benefits Taxable benefits are employer provided "non-cash" taxable compensation or fringe benefits, such as employer-provided vehicles, complementary tickets, and educational assistance, are subject to tax rules. DEDUCTIONS_INVOL Other Deductions Involuntary deducitons are payroll deductions that the employer is mandated by the law to withhold from an employee's paycheck, e.g. income tax witholding, social security taxes, court ordered garnishment such as child support, bankrupcy order, tax levy. DEDUCTIONS_POST_TAX Other Deductions Payroll deductions that are deducted after taxes are withheld. Examples of post tax deductions are union dues, transportation fees, garnishments etc. These deductions do not reduce taxable wages. DEDUCTIONS_PRE_TAX Other Deductions Payroll deductions that are deducted before taxes are withheld. Examples of before tax deductions are health insurance premium, 401K deductions, etc. These deductions reduce taxable wages. DEDUCTIONS_VOL Other Deductions Voluntary deductions are payroll deductions that have been authorized by an employee e.g. retirement saving deduction, health and life insurance premiums, contribution to disability and health saving plans. Some voluntary deductions are before-tax withholdings whereas others are withheld after taxes. FLEX_BALANCE1 Flex Balances Extensible balance field 1 FLEX_BALANCE10 Flex Balances Extensible balance field 10 FLEX_BALANCE11 Flex Balances Extensible balance field 11 FLEX_BALANCE12 Flex Balances Extensible balance field 12 FLEX_BALANCE13 Flex Balances Extensible balance field 13 FLEX_BALANCE14 Flex Balances Extensible balance field 14 FLEX_BALANCE15 Flex Balances Extensible balance field 15 FLEX_BALANCE16 Flex Balances Extensible balance field 16 FLEX_BALANCE17 Flex Balances Extensible balance field 17 FLEX_BALANCE18 Flex Balances Extensible balance field 18 FLEX_BALANCE19 Flex Balances Extensible balance field 19 FLEX_BALANCE2 Flex Balances Extensible balance field 2 FLEX_BALANCE20 Flex Balances Extensible balance field 20 FLEX_BALANCE3 Flex Balances Extensible balance field 3 FLEX_BALANCE4 Flex Balances Extensible balance field 4 FLEX_BALANCE5 Flex Balances Extensible balance field 5 FLEX_BALANCE6 Flex Balances Extensible balance field 6 FLEX_BALANCE7 Flex Balances Extensible balance field 7 FLEX_BALANCE8 Flex Balances Extensible balance field 8 FLEX_BALANCE9 Flex Balances Extensible balance field 9 HEALTHCARE_EMPLOYEE Other Deductions Employee contribution to healcare insurance premiums including medical, dental and vision plans. HEALTHCARE_EMPLOYER Benefits Employer contribution towards the cost of employee healthcare insurance including medical, dental and vision insurance premium, or other employer-assisted wellness plans. HOLIDAY_HOURS Hours Holiday hours are hours compensated for paid company holidays such as New Year, Christmas, etc. OVERTIME_HOURS Hours Overtime hours paid PAY_BASE Standard Earnings Base salary is the fixed salary or wage paid to an employee based on an employment contract. Base pay does not include variable pay components such as bonus, overtime or sales commission. PAY_BONUS Standard Earnings Bonus pay is they pay compensation over and above the amount of pay specified as a base salary or hourly rate of pay PAY_COMMISSION Standard Earnings The amount of money that an individual receives based on the level of sales he or she has obtained. Sales commission is the amount earned in addition to his/her base salary. PAY_GROSS Standard Earnings Gross amount of remuneration for each pay type including regular pay, overtime pay, allowances, commissions, bonuses, and any other amounts, before any deductions are made. PAY_HOLIDAY Standard Earnings Holiday pay are pay compensated for paid company holidays such as New Year, Christmas, etc. PAY_NET Standard Earnings The remaining amounts of an employee's gross pay after deductions, such as taxes and retirement contributions, are made. PAY_OTHER Standard Earnings Other types of pay that are not base pay, bonus, overtime, commision pay. PAY_OVERTIME Standard Earnings The amount of pay compensated for hours worked beyond an employee's normal working hours and is entitled to overtime premium. PAY_VARIABLE Standard Earnings Variable pay is also known as performance pay, is used to recognise and reward employee performance above and beyond their normal job requirements. Variable pay may include profit sharing, bonuses, holiday bonus, or other forms of cash, and goods and services such as a company-paid trip. PENSION_EMPLOYEE Pension The amount contributed by an employee towards his/her retirement funding such as an employee's contribution to a retirement saving plan PENSION_EMPLOYER Pension The amount contributed by the employer towards an employee's retirement funding such as employer contribution to an employee's retirement saving plan REGULAR_HOURS Hours Hours compensation for an employee's normal working hours based on an employment contract SICK_HOURS Hours An employee sick time that is compensated SICK_PAY Standard Earnings Amount paid for an employee's sick time SOC_INS_EMPLOYEE Other Deductions Social security insurance taxes paid by an employee SOC_INS_EMPLOYER Other Deductions Social security insurance taxes paid by the employer STOCK_VESTED_VAL Benefits The value of an employee's vested stock options TAX_EMPLOYEE Tax Payroll taxes withheld from an employee's pay check such as income taxes, social security and medicate taxes, etc. TAX_EMPLOYER Tax Employer paid taxes are payroll taxes paid by the employer for social security, medicare tax withholding unemployment tax insurance or any other form of employer payroll taxes. Employer-paid tax is a key metric in analyzing employee total compensation and workforce cost. TOTAL_DEDUCTIONS Totals Total before and after tax deductions including benefit deductions, taxes, and other voluntary or involuntary deductions. TOTAL_EARNINGS Totals Total gross pay; this is the grand total of all gross pays on a pay check VACATION_HOURS Hours Total number of hours paid for an employee's vacation time or personal time off. VACATION_PAY Standard Earnings Amount compensated for an employee's vacation time or personal time off
Oracle BI Applicationsのインストール後の設定の詳細は、『Oracle Business Intelligence Applicationsインストレーション・ガイド』を参照してください。
Oracle BI Answersで一般会計から補助元帳へのドリルダウンを設定するには:
該当する「会計 - APトランザクション」または「会計 - ARトランザクション」カタログから、補助元帳の要求を作成します。
この要求内で、「AP明細詳細」または「AR明細詳細」フォルダの「文書詳細」サブフォルダにある列「GL仕訳ID」に対するフィルタを追加し、フィルタの演算子を「プロンプトで使用」に設定します。
「財務 - GL詳細トランザクション」カタログから、GL仕訳要求を作成します。
要求に対して、「文書詳細」フォルダの「GL仕訳ID」列を追加します。
この列の「列のプロパティ」に移動し、「列書式の相互作用」タブの「値のプライマリ相互作用」プロパティを「NavigateActionリンク」に設定します。
ナビゲーション・ターゲットを追加して、前述の手順で作成した補助元帳の要求にそのターゲットの場所を設定します。
GLレポートに複数の補助元帳からのトランザクションが表示されていて、GLから該当する補助元帳レポートへのドリル操作が必要な場合は、複数のナビゲーション・ターゲットを追加できます。たとえば、GLレポートにAP、ARおよび収益のトランザクションが表示されていて、それぞれに3つの補助元帳分析がある場合、(「ナビゲーションTargetsActionリンクの追加」オプションを選択することにより)3つのナビゲーション・ターゲットを追加して、それらの分析の場所を設定できます。その後、GLレポートを実行するときに「GL仕訳ID」列の値をクリックすると、ポップアップが表示されます。ここでは、クリックした仕訳に基づいた適切なターゲットをクリックする必要があります。これは自動的には行われません。たとえば、APに由来する仕訳トランザクションをクリックした場合は、該当する補助元帳レポート(この場合、APレポート)を選択し、APレポートをドリルして詳細を確認する必要があります。GL勘定科目ディメンションからのグループ口座番号属性をGLレポートに追加すると、GLトランザクションが属する補助元帳の識別が簡単になります。
注意: COGSの場合、「GL仕訳ID」はどのプレゼンテーション・カタログでも公開されません。これは、RPDメタデータのビジネス・モデル・レイヤーの「ディメンション - GL COGS詳細」論理表の下にあります。回避策として、COGSの詳細レベルのトランザクションについてレポートするプレゼンテーション・カタログを作成して、この列をプレゼンテーション・カタログの「文書詳細」フォルダで公開できます。前述と同様の手順を使用して、GLからCOGSへのドリルダウンを設定します。
これと同じ手順は、GLから収益レベルの詳細トランザクションへのドリルダウンを可能にする、収益のプレゼンテーション表を作成する場合にも実行できます。 |
Oracle Financial Analyticsで、Oracle Project Analyticsのディメンション表が使用可能になるように設定できます。この統合は、Oracle Project Analyticsのライセンスを所持している場合にのみ実行できます。
Oracle Financial Analyticsの次のサブジェクト領域を構成することで、特定のプロジェクト・ディメンションに結合できます。
財務 - 買掛管理(プロジェクト、タスク、財務リソースおよび支出組織のディメンション)
財務 - 売掛管理(契約ディメンション)
Oracle Financial Analyticsの次のファクト表は、Project Analyticsのディメンションと統合されています。
W_AP_XACT_F
W_AR_XACT_F
W_AR_AGING_INVOICE_A
Oracle Project AnalyticsのディメンションをOracle Financial Analyticsで使用するには、インストール時および設定時にOracle Project Analyticsオファリングを選択する必要があります。
この項の手順に従って、GLセグメントおよびGLセグメント階層のディメンションを実装します。
ガイドライン
連結セグメントのみのレポートが必要な場合は、構成する必要はありません。この項は省略してもかまいません。
グループ口座番号(および関連属性)のみが必要な場合は、少なくとも勘定科目ディメンションは構成しておく必要があります。
いずれかのGLセグメント(コスト・センター、貸借一致セグメント、勘定科目を含む)を公開している場合は、すべての構成を完了する必要があります。
なんらかの財務ファクトを公開している場合は、グループ口座番号が必要になるため、少なくとも勘定科目ディメンションを構成しておく必要があります。
前提条件
BI拡張機能の事前構成タスクが完了していることを確認します(Oracle Business Intelligence Applications管理ガイドのBI拡張機能の事前構成タスクの実行に関する項を参照)。
この項では、GLセグメントとGL勘定科目ディメンションを構成する方法について説明します。
Oracle BI ApplicationsのGL会計フレックスフィールドを有効にするには、Fusion Applicationsの「キー・フレックスフィールドの管理」ユーザー・インタフェースで、次の構成を実行する必要があります。この構成によって、BIの会計フレックス・セグメントが有効になり、各会計フレックス・セグメントのディメンションとして使用する必要のあるBIオブジェクト名とのマッピングが提供されます。
一般会計の場合:
Fusion Applicationsで一般会計セグメントのラベルをBIオブジェクトにマップする手順は次のとおりです。
Fusion Applicationsで、「キー・フレックスフィールドの管理」に移動します。
一般会計の各会計フレックス・フィールド・セグメントで、次のように「BI使用可能」フラグをYに設定します。
キー・フレックス・コードとして、「GL#」を問い合せます。
「体系インスタンスの管理」をクリックします。
各セグメントを編集し、「BI使用可能」チェック・ボックスを選択して、詳細を保存します。
これは、BIメタデータ・リポジトリ(RPDファイル)でマップする各体系インスタンスに含まれる、すべてのセグメントに対して実行する必要があります。
次のように、各セグメント・ラベルのBIオブジェクト名を入力します。
注意: この名前は、対応するセグメントのディメンションとして使用されるBIメタデータ・リポジトリ(RPDファイル)の論理表名です。
Fusion Applicationsの「キー・フレックスフィールドの管理」ユーザー・インタフェースで、キー・フレックスフィールド・コードとして「GL#」を問い合せます。
「処理」→「セグメント・ラベルの管理」を選択します。
RPDでマップする必要があるすべてのセグメント・ラベルにBIオブジェクト名を移入して、詳細を保存します。
次の表は、適合セグメント・ラベルごとのBIオブジェクト名を示しています。
表B-76 セグメント・ラベル・コードからBIオブジェクト名へのマッピング
セグメント・ラベル・コード | BIオブジェクト名 |
---|---|
FA_COST_CTR |
ディメンション - コスト・センター |
GL_BALANCING |
ディメンション - 貸借一致セグメント |
GL_ACCOUNT |
ディメンション - 勘定科目セグメント |
非適合セグメント・ラベルの場合、BIオブジェクト名には10個の番号付きディメンション - セグメント(ディメンション - GLセグメント1、ディメンション - GLセグメント2、ディメンション - GLセグメント<n>からディメンション - GLセグメント10まで)のいずれかを移入する必要があります
フレックスフィールドのデプロイ・オプションをクリックして、フレックスフィールドをデプロイします。
資産の場合:
Fusion Applicationsで資産セグメントのラベルをBIオブジェクトにマップする手順は次のとおりです。
Fusion Applicationsで、「キー・フレックスフィールドの管理」に移動します。
資産の各会計フレックスフィールド・セグメントで、次のように「BI使用可能」フラグをYに設定します。
次に示すように、キー・フレックスフィールド・コードを問い合せます。
固定資産カテゴリの場合は、CAT#を問い合せます。
固定資産事業所の場合は、LOC#を問い合せます。
「体系インスタンスの管理」をクリックします。
各セグメントを編集し、「BI使用可能」チェック・ボックスを選択して、詳細を保存します。
これは、BIメタデータ・リポジトリ(RPDファイル)でマップする各体系インスタンスに含まれる、すべてのセグメントに対して実行する必要があります。
次のように、各セグメント・ラベルのBIオブジェクト名を入力します。
注意: この名前は、対応するセグメントのディメンションとして使用されるBIメタデータ・リポジトリ(RPDファイル)の論理表名です。
「キー・フレックスフィールドの管理」ダイアログで、該当するキー・フレックスフィールド・コード(CAT#またはLOC#)を問い合せます。
「処理」→「セグメント・ラベルの管理」を選択します。
BIメタデータ・リポジトリ(RPDファイル)でマップする必要があるすべてのセグメント・ラベルにBIオブジェクト名を移入して、詳細を保存します。
適合セグメント・ラベルの場合は、次のBIオブジェクト名を各適合セグメント・ラベルに使用します。
表B-77 資産セグメント・ラベル・コードからBIオブジェクト名へのマッピング
セグメント・ラベル・コード | BIオブジェクト名 |
---|---|
BASED_CATEGORY |
主カテゴリ |
MINOR_CATEGORY |
補助カテゴリ |
その他のすべてのセグメント・ラベルには、次の値のいずれかを使用します。セグメント1、セグメント2、...、セグメント10
「固定資産事業所(LOC#)」キー・フレックスフィールドのBIオブジェクト名の場合は、すべてのセグメント・ラベルで、セグメント1、セグメント2、...、セグメント7を使用します。
フレックスフィールドのデプロイ・オプションをクリックして、フレックスフィールドをデプロイします。
この項では、BIメタデータ・リポジトリ(RPDファイル)のGL勘定科目セグメント・ディメンションを構成する方法について説明します。また、ETLメタデータを拡張して、Oracle Business Analytics Warehouseの対応する表にデータを移入する方法についても説明します。
BI拡張プロセスの概要
Oracle Business Analytics Warehouseには、セグメント・ディメンション表(W_COST_CENTER_D、W_COST_CENTER_DH、W_NATURAL_ACCOUNT_D、W_NATURAL_ACCOUNT_DH、W_BALANCING_SEGMENT_D、W_BALANCING_SEGMENT_DH、W_GL_SEGMENT_D、W_GL_SEGMENT_DH)にデータを移入するためのデフォルトのマッピングはありません。これらの表にデータを移入するためのマッピングは、BI拡張プロセスで生成されます。このプロセスは、RPDメタデータを通じて実行されます。これらの表に対応するRPDメタデータ内の論理ディメンションは、「ディメンション - コスト・センター」、「ディメンション - 貸借一致セグメント」、「ディメンション - 勘定科目セグメント」ディメンションと、すべての「ディメンション - GLセグメント<n>」ディメンションです。Fusion Applicationsでツリーにセグメントが関連付けられているかどうかに応じて、これらのディメンション表へは、ツリー・ビュー・オブジェクト(VO)または値セット・ビュー・オブジェクト(VO)からデータが移入されます。
ツリーに関連付けられたセグメントごとに、次の名前構造で2つのVOが生成されます(ツリーおよびTreeCode)。
- FscmTopModelAM.AccountBIAM.FLEX_TREE_VS_<segment label> _VI
- FscmTopModelAM.AccountBIAM.FLEX_TREECODE_VS_<segment label>_VI
ツリーのないセグメントごとに、次の名前構造で1つのVOが生成されます。
- FscmTopModelAM.AccountBIAM.FLEX_VS_<XXX>_VI
セグメント・ディメンション表に加えて、BI拡張プロセスでは、GL勘定科目ディメンション(W_GL_ACCOUNT_D)にデータを移入するためのインストール済ETLマッピングも拡張します。このディメンション表には、セグメント・ディメンションごとに1つの列のペアが含まれています。たとえば、コスト・センター・ディメンションにはCOST_CENTER_NUMとCOST_CENTER_ATTRIB、貸借一致セグメント・ディメンションにはBALANCING_SEGMENT_NUMとBALANCING_SEGMENT_ATTRIB、汎用のGLセグメント<n>ディメンションには対応するACCOUNT_SEGn_CODEとACCOUNT_SEGn_ATTRIBがあります。これらの列には、フレックスBIのフラット化されたVO (FscmTopModelAM.AccountBIAM.FLEX_BI_Account_VI)からのデータが移入されます。このVOには、セグメントごとに1つの列のペア(<segment label>_と<segment label>_c)が含まれます。たとえば、セグメント・ラベルがFA_COST_CTRのコスト・センター・セグメントがある場合、このVOにはFA_COST_CTR_とFA_COST_CTR_cという名前の2つの列が存在します。
BI拡張プロセスのフロー
手順 1: 適切なビュー・オブジェクト(VO)をADFデータ・ソースからインポートします。
手順2: マッピング・ダイアログで、論理オブジェクトへのVOの自動マッピングを検証します。
手順3: リポジトリの接続情報(ユーザー名やパスワードなど)を指定します。
手順4: 「終了」をクリックすると、個別のリポジトリで該当するメタデータが生成および更新されます。
前提条件
BI拡張プロセスを開始する前に、Oracle BI EE管理ツールを使用して、「BIAPPSの機能拡張」設定を有効にする必要があります。これを行うには、「ツール」→「オプション」→「一般」を選択して「オプション」ダイアログを表示し、「BIAPPSの機能拡張」チェック・ボックスを選択します。
BI拡張プロセスを使用してGLセグメントおよびGL勘定を構成する手順は次のとおりです。
Oracle BI EE管理ツールで、BIメタデータ・リポジトリ(例: OracleBIAnalyticsApps.rpd)を編集します。
次の物理レイヤーにあるOracle ADFデータベースに移動します。
oracle.apps.fscm.model.analytics.applicationModule.FscmTopModelAM_FscmTopModelAMLocal
接続プールを右クリックして、「メタデータのインポート」を選択します。
「メタデータ・オブジェクトの選択」ダイアログで、次の手順を実行します。
「欠落した結合オブジェクトを自動的に含める」ラジオ・ボタンを選択していることを確認します。
次のサンプル・スクリーンショットに示すように、「データ・ソースと同期」アイコンをクリックします。
これらの設定により、セグメント・ラベルとBIオブジェクトのマッピングに基づいて、RPDの論理表へのマッピングに必要なVOをすべてインポートします。
資産カテゴリおよび資産事業所ディメンションの構成
固定資産カテゴリおよび資産事業所のディメンションを実装する場合は、次のフレックスBIのフラット化されたビュー・オブジェクトとセグメント列が同一のインポート・プロセスでインポートされます。
- FscmTopModelAM.CategoryBIAM.FLEX_BI_Category_VI
- FscmTopModelAM.LocationBIAM.FLEX_BI_Location_VI
次の例は、FLEX_BI_Category_VIのインポート・プロセスを示しています。
次の例は、FLEX_BI_Location_VIのインポート・プロセスを示しています。
インポートが完了したら、「次へ」をクリックします。
注意: Fusion Applicationsでいくつかの複雑な勘定体系構造が定義されている場合は、同一のセグメント・ラベルに対して複数のVOが生成されることがあります。この場合は、次のスクリーンショットに示すような警告メッセージが表示されます。メッセージに示されている情報をコピーします。このメッセージは後続の手順で必要になる可能性があるからです。「OK」をクリックして先に進みます。
「論理モデルへのマップ」ダイアログでは、手順3でインポートしたVOが自動的に適切な論理表にマップされています。また、下部のパネルでは、論理列が自動的にVO列にマップされています。
検証:
ツリー・ベース・セグメントの場合、ツリーとツリー・コードVOはどちらも同じ論理表にマップされている必要があります。どちらも「階層」オプションを選択する必要があります。
非ツリー・ベース・セグメントの場合、「階層」オプションを選択しないでください。
FscmTopModelAM.AccountBIAM.FLEX_BI_Account_VIは、Dim – GL Accountにマップされています。
論理表にマップされているVOの場合、必要なVO列も適切な論理列にマップされています。
注意: 手順4で警告メッセージが表示された場合は、メッセージで示されているVOが1つも論理表にマップされていません。これらのVOをOracle BI Applicationsでマップするには、このステージで手動でいずれかの汎用GLセグメント・ディメンション(Dim – GL Segment<n>)にマップする必要があります。さらに、この手順で手動でマップする各VOについて、FscmTopModelAM.AccountBIAM.FLEX_BI_Account_VIの対応する列をDim – GL Accountの適切な論理列にマップする必要があります。
資産カテゴリおよび資産事業所ディメンションの構成
「論理モデルへのマップ」ダイアログでは、手順3でインポートしたVOが自動的に適切な論理表にマップされることに注意してください。また、下部のパネルでは、論理列が自動的にVO列にマップされていることにも注意してください。
検証: このステージで、次のガイドラインを使用して、すべての自動マッピングが予想どおりに行われていることを検証できます。
- FLEX_BI_Category_VIは論理表Dim – Asset Categoryにマップされ、FLEX_BI_Location_VIは論理表Dim – Asset Locationにマップされます。
- これらのVOのセグメント列は、セグメント・ラベル・コードとBIオブジェクト名のマッピングに基づいて、これらのディメンションの適切な論理列にマップされます。
マッピングを検証して「次」をクリックすると、「ウェアハウスに公開」に移動します。
「ODI」チェック・ボックスを選択し、次の詳細を入力します。
「ユーザー名」 – <ODIマスター・リポジトリ・ユーザー名>
「パスワード」 - <ODIマスター・リポジトリ・パスワード>
「スキーマ所有者名」 – <ODIマスター・リポジトリDBスキーマ所有者名>
「パスワード」 - <ODIマスター・リポジトリDBスキーマ所有者パスワード>
「終了」、「検証」の順にクリックして、変更内容を保存します。
検証: 拡張プロセスが正常終了した場合、ODIリポジトリの新しいマッピングが必要な表に移入されます。これらのマッピングには、SDE_<論理表名>_<物理ターゲット名>という命名規則に従って名前が付けられます。
一般会計の場合:
ツリーおよびツリー・コードVOのセグメントがマップされる場合、セグメント・ディメンションをロードするためのマッピングおよび階層ディメンションのためのマッピングの2つのマッピングが生成されます。たとえば、コスト・センター・ディメンションの場合はSDE_Dim_Cost_Center_W_COST_CENTER_DとSDE_Dim_Cost_Center_W_COST_CENTER_DHが生成されます。
値セットVOのセグメントがマップされる場合、セグメント・ディメンションをロードするためのマッピングが生成されます。たとえば、SDE_Dim_GL_Segment1_W_GL_SEGMENT_Dが生成されます。
GL勘定科目ディメンションの拡張の場合、マッピングSDE_FUSION_GLAccountDimensionが拡張され、これまでの手順でマップされた新しい列に移入されます。
前述の新しく作成されたマッピングはそれぞれ、「デザイナ・ナビゲータ」→「ロード計画とシナリオ」→「BIAPPSロード計画」→「ロード計画Devコンポーネント」→「SDE」→「FUSION_1_0」の対応するロード計画コンポーネントにも追加されます。変更されているロード計画コンポーネントは、セグメント・ディメンションに応じて、次のいずれかになります。
- 3 SDE Dims COSTCTR_DIM FUSION_1_0
- 3 SDE Dims BALSEG_DIM FUSION_1_0
- 3 SDE Dims NAT_ACCT_DIM FUSION_1_0
- 3 SDE Dims GLSEG_DIM FUSION_1_0
資産区分と資産所在地:
資産区分と資産所在地の拡張の場合、SDE_FUSION_FixedAssetCategoryDimensionフォルダとSDE_FUSION_FixedAssetLocationDimensionフォルダにあるマッピングが拡張されて、これまでの手順でマップされた新しい列に移入されます。
BI拡張プロセスを完了したら、適切なロード計画を再作成するか、または新しいロード計画を作成します。
RPDメタデータには、Dim – GL Segment1、Dim – GL Segment2など、汎用GLセグメントを表す複数の論理表が含まれます。これらの論理表は同じ物理表W_GL_SEGMENT_Dにマップされているので、これらの論理表の論理表ソースでフィルタを指定して、論理表の出力が特定のセグメントのみを表すようにする必要があります。これらのフィルタは、物理列SEGMENT_LOV_IDで特定のセグメントに適用可能な値セットコードに適用する必要があります。
拡張プロセスは、これまでの手順でマップされたすべての汎用Dim – GL Segment<n>ディメンションにコンテンツ論理表ソースフィルタを適用します。検証によってフィルタが適切に適用されているかどうかを確認し、変更内容を保存できます。
汎用GLセグメントディビジョンの論理表ソースフィルタを検証するには:
Oracle BI EE管理ツールで、BIメタデータ・リポジトリ(例: OracleBIAnalyticsApps.rpd)を編集します。
「ビジネス・モデルとマッピング」レイヤーでDim – GL Segment<n>をダブルクリックし、LTSを開きます。「内容」表に移動すると、適用されているフィルタを確認できます。次の例と同様のフィルタが確認できるはずです。
注意: RPDの物理レイヤーのセグメントVO表オブジェクトを開くことによって、特定のセグメントの値セット・コードのリストが表示されます。これは、その表オブジェクトのdescriptionフィールドに格納されます。
最初の項の説明に従ってセグメント・ディメンションを構成する際、誤ったVOをセグメント・ディメンションにマップしてメタデータを生成していた場合、その変更を元に戻して、正しいVOによる再マップを実行する必要があります。
セグメント・ディメンションを再構成するには:
対応する論理表から既存のVO論理表ソースを削除して、その論理表を初期状態に戻します。
DW論理表ソースに論理表ソースフィルタが適用されている場合、そのフィルタを削除します(汎用セグメント・ディメンションの場合のみ)。
新しいVOをインポート(VOが物理レイヤーに既存の場合は再インポート)して、これまでの項の説明に従って拡張プロセスを再実行します。
拡張プロセスが正常終了すると、その前に作成したマッピングが、新しいVOを使用した新しいマッピングに置き換わります。
Fusion Applicationsの次のグループ口座番号をHR用に割り当てる必要があります(このタスクはGLに対して実行済であれば省略できます)。
CONT EXP →契約経費
COGS →売上原価
DEPCN →減価償却費
EMP BENFT →従業員福利厚生関連経費
EMP OVERTIME →従業員超過勤務経費
EMP SUPP →従業員サポート経費
GEN PAYROLL →一般管理およびその他の給与支払
MISC OPER EXP →その他営業経費
MKTG PAYROLL →給与経費
SLS PAYROLL →給与経費
R&D PAYROLL →給与経費(GEN PAYROLLはすでにリストされています)
VARIANCE EXP →製品差異経費
REVENUE →収益
注意: 「その他営業経費」は派生列です。グループ口座番号を割り当てる必要はありません。
グループ口座番号を勘定科目に割り当てる方法:
Fusion Applicationsにログインします。
「Applcore」メニューをクリックします。
勘定科目で使用している値セットを特定します。
値セットの値を管理するウィンドウを開きます。
各勘定科目に値のリストから財務カテゴリを割り当てます。
次のグループ口座番号(財務カテゴリ)はシードされています。
ACC DEPCN - Accumulated Depreciation ACC LIAB - Accrued Liabilities AP - Account Payables AR - Account Receivables CASH - Cash CMMN STOCK - Common Stock COGS - Cost Of Goods Sold CONT EXP - Contracting Expenses DEFERRED COGS - Deferred Cost of Goods Sold DEFERRED REVENUE - Deferred Revenue DEPCN - Depreciation Expenses EMP BENFT - Employee Benefits Related Expenses EMP OVERTIME - Employee Overtime EMP SUPP - Employee Support and Cafeteria Expenses FG INV - Finished Goods Inventory, FREIGHT - Freight Expenses GEN PAYROLL - General Admin And Other Payroll GOODWILL - Goodwill INC TAX - Income Tax INT EXP - Interest Expenses LT DEBT - Long Term Debt MISC OPER EXP - Miscellaneous Operating Expenses MKTG PAYROLL - Marketing Payroll OTHER ASSET - Other Assets OTHER CA - Other Current Assets OTHER CL - Other Current Liabilities OTHER EQUITY - Other Equity Related OTHER INC - Other Income OTHER LIAB - Other Liabilities OTHER MKTG EXP - Other Marketing Expenses OTHER R&D EXP - Other R&D Expenses OTHER SLS EXP - Other Sales Expenses PPAID EXP - Prepaid Expenses PPE - PPE PREF STOCK - Preferred Stock PURCH - Purch R&D PAYROLL - R&D Payroll RET EARNING - Retained Earning REVENUE - Sales Revenue RM CONS - RM Cons RM INV - Raw Material Inventory SLS PAYROLL - Sales Payroll ST BORR - ST Borr TAX LIAB - Tax Liabilities TRAVEL & ENT EXP - Travel & Entertainment Expenses VARIANCE EXP - Product Variance Expenses WIP INV - WIP Inventory
財務カテゴリ(グループ口座番号)を、次のように勘定科目に割り当てます。Fusion Applicationsの「アプリケーション・コア設定」へのアクセス権が必要です。
Fusion Applicationsで「アプリケーション・コア設定」に移動します。
「キー・フレックスフィールドの管理」をクリックします。
キー・フレックスフィールド・コードGL#を検索します。
「体系インスタンスの管理」をクリックします。
勘定体系の体系インスタンスを検索します。
体系インスタンスを選択し、「編集」をクリックします。
勘定科目セグメントの「値セット・コード」をクリックして「値セットの管理」を開きます。
「値の管理」をクリックします。
財務カテゴリを割り当てる勘定科目を検索します。
値を選択し、「編集」をクリックします。
値のリストから財務カテゴリを割り当てます。
変更内容を保存します。
集計したGL残高はW_GL_BALANCE_Aに移入されます。デフォルトでは、この表にGL残高が格納される修飾GLセグメントは、勘定科目セグメント、貸借一致セグメント、およびコスト・センター・セグメントの3つのみです。GL残高の集計には、デフォルトでインストールされている非修飾セグメントは含まれません。非修飾セグメントを集計対象にするには、次のようにODIインタフェースを変更する必要があります。
GL残高のセグメント集計を設定するには:
1. ODIデザイナ・ナビゲータで、ODIリポジトリに接続します。
2. 一時インタフェースPLP_GLBalanceAggrByAcctSegCodes.SQ_W_GL_BALANCE_Fを開きます。
3. 「マッピング」タブを開きます。
4. 一般勘定残高(W_GL_BALANCE_F)のGL_SEGMENT<N>_WIDを右クリックして「ターゲット表への列の追加」をクリックします。
5. 「プロパティ・インスペクタ」で「実行」をGL_SEGMENT<N>_WIDの「ステージング」に変更します。
6. メイン・インタフェースPLP_GLBalanceAggrByAcctSegCodes.W_GL_BALANCE_Aを開きます。
7. SEGMENT<N>_WIDの式をSQ_W_GL_BALANCE_F.GL_SEGMENT<N>_WIDに変更します。
8. 「プロパティ・インスペクタ」で「実行」を「ソース」に変更します。
Oracle Spend Classificationを実装していない場合、BIリポジトリのプレゼンテーション・レイヤーに存在するOracle Spend Classification統合メタデータを削除または非表示にすることをお薦めします。このメタデータを非表示または削除することによって、ビジネス・エンド・ユーザーの間に混乱を招く恐れがなくなります。
Oracle Spend Classification統合メタデータを削除または非表示にするには:
Oracle BI EE管理ツールで、BIメタデータ・リポジトリ(例: OracleBIAnalyticsApps.rpd)を編集します。
デプロイされたRPDファイルは、ORACLE_HOME\bifoundation\OracleBIServerComponent\coreapplication_obis<n>\repositoryにあります。
「プレゼンテーション・レイヤー」ペインで、「調達および支出 - 請求書明細」フォルダを開きます。
物理レイヤーのOracle Spend Classificationメタデータは、次のオブジェクトで構成されています。
データ分類
自動UNSPSC
自動購買カテゴリ
自動カスタム・カテゴリ1
これらのメタデータ・オブジェクトを削除するには、オブジェクトを右クリックして「削除」を選択します。
注意: 後になってOracle Spend Classificationを実装することにした場合は、次の手順を実行する必要があります。
|
前述のオブジェクトがエンド・ユーザーに表示されないようにするには、それらを右クリックして「プロパティ」、「権限」の順に選択し、該当するユーザーまたはグループの「読取り」権限チェック・ボックスの選択を解除します。
注意: 後になってOracle Spend Classificationを実装することにした場合は、次の手順を実行する必要があります。
|
BIメタデータ・リポジトリ(RPDファイル)を保存して閉じます。
Oracle Supply Chain and Order Managementを有効化して、Oracle Project Analyticsでディメンション表を使用できます。この統合は、Oracle Project Analyticsのライセンスを所持している場合にのみ実行できます。次に示すOracle Supply Chain and Order Managementのサブジェクト領域を構成して、特定のプロジェクト・ディメンションに結合できます。在庫トランザクション(Project Dim、Task Dim、Financial Resource Dim)
サプライ・チェーンの次のファクト表は、Project Analyticsのディメンションと統合されています。
W_PRODUCT_XACT_F
Fusionアプリケーションの制限により、Oracle Supply Chain and Order Management Analyticsの次のサブジェクト領域は、構成タグEnable Project Dimensionに含まれていますが、デフォルトでは非アクティブになっています。注意: これらの設定は意図的であり、再アクティブ化してはいけません。
SCOM_AN: Order Backlog
SCOM_AN: Order Booking
SCOM_AN: Order Credit
SCOM_AN: Order Customer Status History
SCOM_AN: Order Cycle
SCOM_AN: Order Fulfillment
SCOM_AN: Order Hold
SCOM_AN: Order Invoice
SCOM_AN: Order Invoice Credit
SCOM_AN: Order Scheduling
SCOM_AN: Order Shipping
第B.2.98項「Financial AnalyticsとProject Analyticsの統合方法」を参照してください。
予備知識
Fusion Applicationsには、非Fusion Applicationsシステムをソースとする様々なエンティティが存在します。Fusion Applications CRMは、OBIA (Oracle Business Intelligence Applications)を使用して、Fusion Applicationsシステムと非Fusion Applicationsシステムをソースとするデータを統合します。Oracle BI Applicationsメタデータ・レイヤーは、種類の異なる物理データ・ソースを統合して、Fusion Applicationsユーザーが分析できるように準備します。Sales Prospector (SPE)は、営業ユーザー向けの最新のFusionアプリケーションであり、営業ユーザーがパイプラインやホワイトスペースを効率的に管理できるように支援します。SPEは、オーダー品目とサービス要求のデータを非Fusionアプリケーションから取得することを想定しています。
注意: このタスクの構成ファイル(複数の場合もあり)は、Oracle BI Applicationsインストールの次の場所にあります。 ソース独立ファイル: <Oracle Home for BI>\biapps\etl\data_files\src_files\。 ソース固有ファイル: <Oracle Home for BI>\biapps\etl\data_files\src_files\<source adaptor>。 システム管理者は、これらのファイルを別の場所にコピーして、この場所から読み取るためのODI接続を構成しているはずです。システム管理者に、これらのファイルの取得を依頼してください。構成が完了したら、システム管理者は、構成済ファイルをODIの読取り元にコピーする必要があります。 |
フラット・ファイルのETL
オーダー品目やサービス要求などの非Fusion Applicationsデータは、指定されているフラット・ファイル形式であるかぎり、Oracle Business Analytics Warehouseに直接ロードできます。ETLプロセスは、非Fusion Applicationsデータはフラット・ファイルから、Fusion ApplicationsデータはFusion Applicationsデータベース表から、それぞれステージング表にロードします。次に、ステージング表からデータをOracle Business Analytics Warehouseにロードします。
SPEのETLの準備
SPEでは、オーダー品目ファクト、サービス要求ファクト、およびサービス要求ディメンションに非Fusion Applicationsデータが必要です。このデータは、次の仕様に従ったフラット・ファイルで提供される必要があります。
データはCSVファイル(*.csv)に存在している必要があります。
これらのファイルには、完全ETLの場合はOracle Business Analytics Warehouseにロードすることになっているすべての初期レコードが存在する必要があります。増分ETLの場合は新しいレコードまたは更新されたレコードのみ存在する必要があります。
これらのファイルは、Fusion Sales Prediction Engine (SPE)データ・マイニング専用の特別な形式になっています。ファイルに含まれるすべての列は、Fusionアプリケーション・データ・モデルの用語と基準に従う必要があります。ファイルに含まれるすべてのID列には、対応するFusion統合IDが存在することが予想されます。
データは、各ファイルの6行目から始まっている必要があります。各ファイルの先頭から5行は、ETLプロセス時にスキップされます。
各行が、ステージング表の1レコードを表します。
すべての日付値は、YYYYMMDDHH24MISS形式にする必要があります。たとえば、2007年12月31日午後2:03の場合は、20071231140300を使用する必要があります。
すべてのフラット・ファイルのDATASOURCE_NUM_ID列とINTEGRATION_ID列は、NULLにはできません。
列DATASOURCE_NUM_IDは常に200にする必要があります。これはFusion Applicationsデータ・ソース番号でもあります。
オーダー品目ファクト、サービス要求ファクト、およびサービス要求ディメンションのフラット・ファイルを次に示します。
file_orderitem_fs.csv - このファイルの構造の詳細は、第B.2.107.1項「フラット・ファイルfile_orderitem_fs.csv」を参照してください。
file_srvreq_fs.csv - このファイルの構造の詳細は、第B.2.107.2項「フラット・ファイルfile_srvreq_fs.csv」を参照してください。
file_srvreq_ds.csv - このファイルの構造の詳細は、第B.2.107.3項「フラット・ファイルfile_srvreq_ds.csv」を参照してください。
ETLの実行を開始する前に、これらのフラット・ファイルを、この後の各項で説明する形式で用意する必要があります。
このファイルは汎用であり、繰返オーダー明細など、ソース・オーダー・システム固有の機能をサポートするものではありません。各明細は、合計受注金額に加算されます。このファイルの粒度は、オーダー明細単位です。
Fusion Sales Prediction Engine (SPE)データ・マイニング専用の特別な形式になっています。
表B-78 file_orderitem_fs.csvのファイル構造
列名 | データ型 | サンプル・データ | 説明 |
---|---|---|---|
CUSTOMER_ID |
VARCHAR(80) |
999997551042159 |
顧客パーティID。1件のオーダーには、複数の顧客IDが存在する可能性があります。たとえば請求先、出荷先、請求書送付先などの顧客IDがありますが、この顧客IDはBI分析に使用するプライマリIDです。 HZ_PARTIES.PARTY_IDに対する外部キー。 |
CURCY_CD |
VARCHAR(20) |
USD |
通貨コード。オーダー明細金額を表す際に使用する通貨。 |
CRM_CURR_EXCHANGE_RATE |
NUMBER(28,10) |
1.00 |
CRM通貨換算レート。オーダー明細金額をCRM共通通貨に変換する際に使用します。 |
CRM_CORP_CURR_CODE |
VARCHAR(20) |
USD |
CRM共通通貨コード。 |
ORDER_ID |
VARCHAR(80) |
4171787 |
オーダーヘッダーID。 |
PROD_ID |
VARCHAR(80) |
999997500678718 |
製品在庫品目ID。 EGP_SYSTEM_ITEMS_B.INVENTORY_ITEM_IDに対する外部キー。 |
PROD_GROUP_ID |
VARCHAR(80) |
Null |
製品グループID。SPE ETLでオプションとして使用します。Nullのままにします。 |
RESOURCE_ID |
VARCHAR(80) |
123445623 |
リソースID。オーダーの受注オーナー・リソースID。 HZ_PARTIES.PARTY_IDに対する外部キー。 |
RESOURCE_ORG_ID |
VARCHAR(80) |
3453453453 |
リソース組織ID。受注オーナーの組織ID。 HR_ALL_ORGANIZATION_UNITS_F.ORGANIZATION_IDに対する外部キー。 |
SOURCE_ID |
VARCHAR(80) |
100000016742344 |
MKT_SC_SOURCE_CODESで定義されているマーケティング・キャンペーン・ソース・コード。 |
ORDER_DT |
DATE |
20061220000000 |
オーダー日(YYYYMMDDHH24MISS形式)。オーダーが行われた日付。この日付は、ETLでディメンションFKを解決するための標準日付として使用されます。 |
DATASOURCE_NUM_ID |
NUMBER(10) |
200 |
データ・ソース番号ID。200固定である必要があります。これは、ETLのFusion Applicationsデータ・ソースと同じ値です。 |
INTEGRATION_ID |
VARCHAR(80) |
12149813 |
統合ID。オーダー明細ID。一般に、各オーダーに、オーダーヘッダーが1つとオーダー明細が複数存在します。 |
DISCNT_AMT |
NUMBER(28,10) |
2.33 |
割引額。単価に対する調整額です。 |
NET_PRI |
NUMBER(28,10) |
45.752 |
オーダー明細項目の正味価格。割引額適用後の最終価格。 |
QTY_REQ |
NUMBER(28,10) |
12 |
明細項目のオーダー済数量。 |
PR_TERR_ID |
VARCHAR(80) |
1000000000023112 |
プライマリ・テリトリID。オーダーが行われたプライマリ販売テリトリのID。 テリトリIDは、MOT_TERRITORIESで定義されています。 |
CREATED_BY_ID |
VARCHAR(80) |
SALES_ADMIN |
作成者ID。この行を作成したユーザーのログインID。 |
CREATED_ON_DT |
DATE |
20071231140300 |
作成日(YYYYMMDDHH24MISS形式)。 |
CHANGED_BY_ID |
VARCHAR(80) |
SALES_ADMIN |
変更者ID。この行を変更したユーザーのログインID。 |
CHANGED_ON_DT |
DATE |
20071231140300 |
変更日(YYYYMMDDHH24MISS形式)。 |
DELETE_FLG |
VARCHAR(1) |
Null、Y、またはN |
削除フラグ。最後のETLの実行後にこのレコードが削除されているかどうかを示します。Nullの場合、デフォルトでNになります。 |
X_CUSTOM |
VARCHAR(10) |
Null |
ETLで予約されています。Nullのままにします。 |
SPE ETLで使用する場合、この後の表に示す列は必須です。このファイルの粒度は、サービス要求単位です。Fusion Sales Prediction Engine (SPE)データ・マイニング専用の特別な形式になっています。
表B-79 フラット・ファイルfile_srvreq_fs.csvのファイル構造
列名 | データ型 | サンプル・データ | 説明 |
---|---|---|---|
DATASOURCE_NUM_ID |
NUMBER(10) |
200 |
データ・ソース番号ID。200固定である必要があります。これは、ETLのFusion Applicationsデータ・ソースと同じ値です。 |
INTEGRATION_ID |
VARCHAR(80) |
12149813 |
統合ID。各サービス要求の一意の識別子ID。 |
CLOSE_DT |
DATE |
20030616174947 |
クローズ日。サービス要求がクローズされた日付(YYYYMMDDHH24MISS形式)。 |
OPEN_DT |
DATE |
20020516174947 |
オープン日。サービス要求がオープンされた日付(YYYYMMDDHH24MISS形式)。 |
DELETE_FLG |
VARCHAR(1) |
Null、Y、またはN |
削除フラグ。最後のETLの実行後にこのレコードが削除されているかどうかを示します。Nullの場合、デフォルトでNになります。 |
CREATED_BY_ID |
VARCHAR(80) |
SALES_ADMIN |
作成者ID。この行を作成したユーザーのログインID。 |
CREATED_ON_DT |
DATE |
20071231140300 |
作成日(YYYYMMDDHH24MISS形式)。 |
CHANGED_BY_ID |
VARCHAR(80) |
SALES_ADMIN |
変更者ID。この行を変更したユーザーのログインID。 |
CHANGED_ON_DT |
DATE |
20071231140300 |
変更日(YYYYMMDDHH24MISS形式)。 |
X_CUSTOM |
VARCHAR(10) |
Null |
ETLで予約されています。Nullのままにします。 |
CUSTOMER_ID |
VARCHAR(80) |
999997551042159 |
顧客パーティID。 HZ_PARTIES.PARTY_IDに対する外部キー。 |
PROD_ID |
VARCHAR(80) |
999997500678718 |
製品在庫品目ID。 EGP_SYSTEM_ITEMS_B.INVENTORY_ITEM_IDに対する外部キー。 |
SPE ETLで使用する場合、この後の表に示す列は必須です。このファイルの粒度は、サービス要求単位です。Fusion Sales Prediction Engine (SPE)データ・マイニング専用の特別な形式になっています。
表B-80 フラット・ファイルfile_srvreq_ds.csvのファイル構造
列名 | データ型 | サンプル・データ | 説明 |
---|---|---|---|
DATASOURCE_NUM_ID |
NUMBER(10) |
200 |
データ・ソース番号ID。200固定である必要があります。これは、ETLのFusion Applicationsデータ・ソースと同じ値です。 |
INTEGRATION_ID |
VARCHAR(80) |
1-10E-5 |
統合ID。各サービス要求の一意の識別子ID。 |
CLOSE_DT |
DATE |
20020516174947 |
クローズ日。サービス要求がクローズされた日付(YYYYMMDDHH24MISS形式)。 |
OPEN_DT |
DATE |
20020516174947 |
オープン日。サービス要求がオープンされた日付(YYYYMMDDHH24MISS形式)。 |
SEV_CD |
VARCHAR(80) |
SR_SEVERITY~3-Medium |
サービス要求の重大度コード。 可能な値: SR_SEVERITY~1-Critical SR_SEVERITY~2-High SR_SEVERITY~3-Medium SR_SEVERITY~4-Low |
STATUS |
VARCHAR(80) |
SR_STATUS~Open |
サービス要求ステータス。 可能な値は、SR_STATUS~Approved、SR_STATUS~Cancelled、SR_STATUS~Closed、SR_STATUS~Completed、SR_STATUS~Open、SR_STATUS~Pendingです。 |
DELETE_FLG |
VARCHAR(1) |
Null, Y or N |
削除フラグ。最後のETLの実行後にこのレコードが削除されているかどうかを示します。Nullの場合、デフォルトでNになります。 |
CREATED_BY_ID |
VARCHAR(80) |
SALES_ADMIN |
作成者ID。この行を作成したユーザーのログインID。 |
CREATED_ON_DT |
DATE |
20071231140300 |
作成日(YYYYMMDDHH24MISS形式)。 |
CHANGED_BY_ID |
VARCHAR(80) |
SALES_ADMIN |
変更者ID。この行を変更したユーザーのログインID。 |
CHANGED_ON_DT |
DATE |
20071231140300 |
変更日(YYYYMMDDHH24MISS形式)。 |
X_CUSTOM |
VARCHAR(10) |
Null |
ETLで予約されています。Nullのままにします。 |
在庫月次残高表を増分リフレッシュするには:
月次残高集計表(W_INVENTORY_MONTHLY_BAL_F)から特定期間のレコードを削除します。
削除する期間は、GRAINパラメータで指定します。たとえば、GRAINがMONTHで、日付が2005年5月15日の場合、月次残高表(W_INVENTORY_MONTHLY_BAL_F)の4月と当月(5月)のすべてのレコードが削除されます。
この手順は、PLP_InventoryMonthlyBalanceワークフロー・マッピングを実行することによって実装されます。
特定の単位レベルで在庫残高ファクト表(W_INVENTORY_DAILY_BAL_F
)のレコードを取得し、月次残高表(W_INVENTORY_MONTHLY_BAL_F)にロードします。
たとえば、GRAINがMONTHの場合、W_INVENTORY_DAILY_BAL_F
ファクト表の月末残高レコードが月次残高表(W_INVENTORY_MONTHLY_BAL_F)に格納され、集計されます。
この手順は、PLP_InventoryMonthlyBalance
セッション、さらにPLP_InventoryMonthlyBalance
マッピングを実行することによって実装されます。当月残高については、前日(前日が同じ月である場合)の残高レコードがW_INVENTORY_MONTHLY_BAL_Fから削除され、当日の残高レコードがW_INVENTORY_BALANCE_FからW_INVENTORY_MONTHLY_BAL_Fにロードされます。
この手順は、PLP_InventoryMonthlyBalanceワークフローを実行することによって実装されます。
W_INVENTORY_DAILY_BAL_Fファクト表から古いレコードを削除します。
古いレコードを削除するには、KEEP_PERIODパラメータとNUM_OF_PERIODパラメータを使用する必要があります。たとえば、KEEP_PERIODがMONTH、NUM_OF_PERIODが1、日付が2005年5月15日の場合、4月と当月(5月)のレコードは残され、それより古いレコードは削除されます。
この手順は、PLP_InventoryDailyBalance_Trimワークフローを実行することによって実装されます。
注意: この切捨て処理を行うと、表のデータ・サイズが減少します。古い日次残高レコードを確認できなくなるという点に注意してください。ただし、月末残高は引き続き確認できます。したがって、NUM_OF_PERIODの値は、どの程度のデータ量と、どの程度新しいデータが必要かという要件に応じて調整する必要があります。 |
在庫月次残高と在庫トランザクション集計表を構成するには:
月次残高集計表(W_INVENTORY_MONTHLY_BAL_F)から特定期間のレコードを削除します。
削除する期間は、GRAINパラメータで指定します。たとえば、GRAINがMONTHで、日付が2005年5月15日の場合、月次残高表(W_INVENTORY_MONTHLY_BAL_F)の4月と当月(5月)のすべてのレコードが削除されます。
この手順は、PLP_InventoryMonthlyBalanceワークフロー・マッピングを実行することによって実装されます。
特定の単位レベルで在庫残高ファクト表(W_INVENTORY_DAILY_BAL_F
)のレコードを取得し、月次残高表(W_INVENTORY_MONTHLY_BAL_F)にロードします。
たとえば、GRAINがMONTHの場合、W_INVENTORY_DAILY_BAL_F
ファクト表の月末残高レコードが月次残高表(W_INVENTORY_MONTHLY_BAL_F)に格納され、集計されます。
この手順は、PLP_InventoryMonthlyBalance
セッション、さらにPLP_InventoryMonthlyBalance
マッピングを実行することによって実装されます。当月残高については、前日(前日が同じ月である場合)の残高レコードがW_INVENTORY_MONTHLY_BAL_Fから削除され、当日の残高レコードがW_INVENTORY_BALANCE_FからW_INVENTORY_MONTHLY_BAL_Fにロードされます。
この手順は、PLP_InventoryMonthlyBalanceワークフローを実行することによって実装されます。
W_INVENTORY_DAILY_BAL_Fファクト表から古いレコードを削除します。
古いレコードを削除するには、KEEP_PERIODパラメータとNUM_OF_PERIODパラメータを使用する必要があります。たとえば、KEEP_PERIODがMONTH、NUM_OF_PERIODが1、日付が2005年5月15日の場合、4月と当月(5月)のレコードは残され、それより古いレコードは削除されます。
この手順は、PLP_InventoryDailyBalance_Trimワークフローを実行することによって実装されます。
注意: この切捨て処理を行うと、表のデータ・サイズが減少します。データ切捨て処理の実行後は、古い日次残高レコードを確認できなくなるという点に注意してください。ただし、月末残高は引き続き確認できます。したがって、NUM_OF_PERIODの値は、どの程度のデータ量と、どの程度新しいデータが必要かという要件に応じて調整する必要があります。 |
初期ETLを実行した後で、増分ETLを実行して製品トランザクション集計表をロードするには、まず、製品トランザクション集計表を次のように構成しておく必要があります。
製品トランザクション集計表を構成するには:
Oracle BI Applications Configuration Managerを使用して、次のパラメータに必要な値が設定されていることを確認します。
REFRESH_PERIOD = 'MONTH'
GRAIN = 'MONTH'
NUM_OF_PERIOD = 3
注意: これらのパラメータのいずれかが存在しない場合は、データ型をTextとして作成し、指定されている値を設定してください。
初期ETLを実行できるように製品トランザクション集計表を構成するには:
製品トランザクション・ファクト表(W_PRODUCT_XACT_F)内のレコードを取得し、そのレコードを特定の単位レベルで製品トランザクション集計表(W_PRODUCT_XACT_A)に集計します。
たとえば、GRAINがMONTHに設定されている場合、W_PRODUCT_XACT_Fファクト表のレコードが取得され、月レベルでW_PRODUCT_XACT_A表に集計されます。
この手順は、PLP_ProductTransactionAggregateマッピングを実行することによって実装されます。
増分ETLを実行できるように製品トランザクション集計表を構成するには:
製品トランザクション集計表(W_PRODUCT_XACT_A)から特定期間の更新済レコードを削除します。
削除する期間はREFRESH_PERIODおよびNUM_OF_PERIODパラメータで指定します。
たとえば、REFRESH_PERIODがMONTH、NUM_OF_PERIODが1、日付が2013年5月15日の場合、W_PRODUCT_XACT_A表の4月と当月(5月)のすべてのレコードが削除されます。
この手順は、PLP_ProductTransactionAggregateマッピングを実行することによって実装されます。
製品トランザクションのファクト表(W_PRODUCT_XACT_F)内のレコードを取得し、それらのレコードを特定の単位レベルでW_PRODUCT_XACT_A表に集計します。
たとえば、GRAINがMONTHに設定されている場合、W_PRODUCT_XACT_Fファクト表のレコードが取得され、月レベルでW_PRODUCT_XACT_A表に集計されます。
この手順は、PLP_ProductTransactionAggregateワークフローを実行することによって実装されます。
この項では、部品表を複数レベルの構造に展開して、最終的にW_BOM_HEADER_D表とW_BOM_ITEM_F表の両方に移入する方法について説明します。
JD Edwards EnterpriseOneの部品表情報は単一レベル形式で管理されていますが、Oracle BI Applicationsの部品表情報は複数レベル形式である必要があります。したがって、データをOracle BI Applicationの表にロードする前に、単一レベルの構造を展開して複数レベルの構造にする必要があります。
JD Edwards EnterpriseOneソースでは部品表情報がすべて単一表に格納されており、部品表のレベルは定義されていないので、反復的なループ処理によって部品表を展開する必要があります。また、Oracle BI Applicationsでは、構成部品に対するすべての改訂が、有効日が設定されている新しいバージョンの部品表として管理されます。この事実を考慮すると、ETLを使用して単一レベルの部品表を複数レベルの部品表に変換することは実現不可能です。したがって、既存のJD Edwards EnterpriseOne UBE (R30460)のロジックを使用して、部品表展開のための新しいUBEが作成されています。
この新しいUBE (R30461)は、製造最終製品を抽出して、単一レベルの部品表形式を複数レベルの部品表形式に変換します。また、左範囲や右範囲、レベル親(1-10)などのいくつかの必須情報も抽出します。
このUBEは、改訂ごとの製造最終製品の複数レベルの部品表構造を、部品表ヘッダーと部品表アイテム(構成部品)に分けて2つの作業ファイルにロードします。
次に、ETLがこれらの2つの作業ファイルからデータを抽出して、Oracle BI Applicationsの表にロードします。
注意: 部品表の分析の消込みを予定している場合は、ETLを開始する前にこのUBEを実行する必要があります。このUBEとJD Edwards EnterpriseOneの関連オブジェクトは、分析の効果を高めるためにのみ作成されたもので、既存のソース・システムでは使用できません。 |
タイムカード入力タイプ・ディメンションには、勤務管理メトリックの多くで使用される適合ドメインが多数存在します。ウェアハウスのレポート・カテゴリとレポート・サブカテゴリに対する時間レポート入力の正確な帰属がレポートで定義されるように、これらのドメインを適切に構成する必要があります。
オプションまたは必須
このタスクは必須です。
適用対象
E-Business SuiteとPeopleSoft。
タイムカード入力タイプ・サブカテゴリにマップされるソース・タイムカード入力タイプ・コード
このタスクは必須です。
ソース・タイムカード入力タイプを付属のターゲット・タイムカード入力タイプ・サブカテゴリ・ドメイン・メンバーにマップする方法を指定するために使用します。REGULAR (通常)、OVERTIME (超過勤務)などのターゲット・ドメイン・メンバーは、付属のメトリック、ダッシュボード、およびレポートで使用されます。ターゲット・ドメインは拡張可能です。このドメインへの追加は可能ですが、削除はできません。
E-Business Suiteの例
ソース・タイムカード入力タイプは、要素タイプID (要素)です。
表B-81 E-Business Suiteの場合の実装例
ソース・メンバー・コード(名前) | ターゲット・メンバー・コード(名前) |
---|---|
64668 (超過勤務エレメント) |
OVERTIME (超過勤務) |
57941 (標準勤務時間) |
REGULAR (通常) |
_HOURS_ (時間) |
REGULAR (通常) |
63085 (教室内研修時間リベート) |
TRAINING (研修) |
PeopleSoftの例
PeopleSoftでは、ソース・タイムカード入力タイプは、勤務時間レポート・コード(TRC)です。
表B-82 PeopleSoftの場合の実装例
ソース・メンバー・コード | ターゲット・メンバー・コード |
---|---|
KAO20 (超過勤務 - 倍額支給) |
OVERTIME (超過勤務) |
MCREG (通常) |
REGULAR (通常) |
MTRG (研修) |
TRAINING (研修) |
タイムカード入力タイプ・カテゴリにマップされるタイムカード入力タイプ・サブカテゴリ
このタスクはオプションです。シード済マッピングが製品に付属しています。
タイムカード入力タイプ・カテゴリにマップするタイムカード入力タイプ・サブカテゴリを指定するために使用します。WORKED (就業)、NON_WORKED (非就業)などのターゲット・ドメイン・メンバーは、付属のメトリック、ダッシュボード、およびレポートで使用されます。ターゲット・ドメインは拡張可能です。このドメインへの追加は可能ですが、削除はできません。
表B-83 シード済の実装例
ソース・メンバー・コード(名前) | ターゲット・メンバー・コード(名前) |
---|---|
BL (忌引) |
NON_WORKED (非就業) |
FAML (家族休暇) |
NON_WORKED (非就業) |
HOL (休日) |
NON_WORKED (非就業) |
OVERTIME (超過勤務) |
WORKED (就業) |
PREMIUM (保険料) |
WORKED (就業) |
REGULAR (通常) |
WORKED (就業) |
SCK (疾病) |
NON_WORKED (非就業) |
TRAINING (研修) |
OTHER (その他) |
WORKING (作業中) |
WORKED (就業) |
タイムカード入力が生産的(Y/N)フラグのソース・タイムカード入力タイプ・コード
生産的であると見なすソース・タイムカード入力タイプを指定するために使用します。Y (はい)、N (いいえ)などのターゲット・ドメイン・メンバーは、付属のメトリック、ダッシュボード、およびレポートで使用されます。ターゲット・ドメインは拡張可能です。このドメインへの追加は可能ですが、削除はできません。
E-Business Suiteの例
ソース・タイムカード入力タイプは、要素タイプID (要素)です。
表B-84 E-Business Suiteの場合の実装例
ソース・メンバー・コード(名前) | ターゲット・メンバー・コード(名前) |
---|---|
64668 (超過勤務エレメント) |
Y (はい) |
57941 (標準勤務時間) |
Y (はい) |
63085 (教室内研修時間リベート) |
N (いいえ) |
PeopleSoftの例
PeopleSoftでは、ソース・タイムカード入力タイプは、勤務時間レポート・コード(TRC)です。
表B-85 PeopleSoftの場合の実装例
ソース・メンバー・コード | ターゲット・メンバー・コード |
---|---|
KAO20 (超過勤務 - 倍額支給) |
Y (はい) |
MCREG (通常) |
Y (はい) |
MTRG (研修) |
N (いいえ) |
注意: 次のドメイン・メンバー・マッピングは、勤怠管理ウェアハウス・スキーマをロードする前に、ユーザーが入力を完了する必要があります。 |
タイムカード入力不就業カテゴリにマップされるソース・タイムカード入力不就業カテゴリ
このタスクはオプションです。
タイムカード入力不就業カテゴリにマップするソース・タイムカード入力不就業カテゴリを指定するために使用します。ターゲット・ドメイン・メンバーは、付属のメトリック、ダッシュボード、およびレポートで現在は使用されません。ターゲット・ドメインは拡張可能です。このドメインへの追加は可能ですが、削除はできません。
タイムカード入力タイプ支給項目カテゴリにマップされるソース・タイムカード入力支給項目カテゴリ
このタスクはオプションです。
タイムカード入力タイプ支給項目カテゴリにマップするソース・タイムカード入力支給項目カテゴリを指定するために使用します。ターゲット・ドメイン・メンバーは、付属のメトリック、ダッシュボード、およびレポートで現在は使用されません。ターゲット・ドメインは拡張可能です。このドメインへの追加は可能ですが、削除はできません。
適合STATE_PROVを構成するには、Oracle BI Applications構成マネージャで外部適合ドメインを使用します。外部適合ドメインの構成方法の詳細は、第4.4.8項「外部適合ドメインの構成方法」を参照してください。
注意: このタスクは、Peoplesoftのプロジェクト・リソース管理でのみ適用可能です。
作業タイプは、プロジェクトやタスクに対して実行する作業のタイプを指定します。作業タイプによって、この特定のタスクが請求可能か、資産計上可能か、または研修用かを指定でき、タスクを実行する個人の稼働率レベルに加重を割り当てます。Project Analytics要員管理ソリューションのメトリックの多くは、作業タイプに依存しています。たとえば、研修時間には、タイプが研修であるタスクのみが考慮されます。PeopleSoft要員管理では、要員タスクは、PeopleSoft要員管理で事前定義されている一連のタスク・カテゴリおよび組織固有のタスクに使用可能なユーザー定義カテゴリによって管理されます。ただし、PeopleSoft要員管理UIでは、これらのタスク・カテゴリに関連付けられる作業タイプを指定することはできません。PeopleSoft要員管理で定義されるタスク・タイプが、作業タイプ・ディメンションにマップされます。PeopleSoftの作業タイプ・ディメンションは、要員管理以外のプロジェクト・サブジェクト領域には適用できません。
PeopleSoftのプロジェクト・リソース管理作業タイプ・ディメンションを構成するには:
ソース・データベースで次の問合せを実行します。
SELECT CONCAT(CONCAT(TASK_TYPE,'~'),SYSTEM_SOURCE) FROM PS_RS_TASK_TYPE WHERE SYSTEM_SOURCE='RS'
実行した問合せの出力をコピーして、ファイルfile_psft_work_type_ds.csvの5行目の最初の列(INTEGRATION_ID)の下に貼り付けます。
作業タイプ・ディメンションは、加重割当時間に対する2つの異なるスケールを提供します。これにより、稼働率を要員レベルと組織レベルの2つの異なるビューで表示できます。たとえば、再加工または研修を実行している時間は、要員レベルでは高く評価されますが、組織レベルでは部分的にしか評価されない可能性があります。各行について、次の情報を指定します。
表B-86 file_psft_work_type_ds.csvの列
列 | 説明 |
---|---|
RES_UTILIZATION_PERCENTAGE |
このタスク・カテゴリの要員稼働率のパーセント値。0から100までの任意の値。 |
ORG_UTILIZATION_PERCENTAGE |
このタスク・カテゴリの組織稼働率のパーセント値。0から100までの任意の値。 |
REDUCE_CAPACITY_FLG |
このタスク・カテゴリに課金される要員の勤務時間によって、その要員および該当する組織の生産能力が減少するかどうかを示すフラグ。YまたはNのどちらか。 |
BILLABLE_CAPITALIZABLE_FLG |
タスク・カテゴリ・タイプが請求可能または資産計上可能であるかどうかを示すフラグ。YまたはNのどちらか。 |
TRAINING_FLAG |
タスク・カテゴリが研修タイプかどうかを示すフラグ。 |
ファイルを保存します。
ファイルが、MS Excel形式ではなく、CSV(テキスト)で保存されることを確認します。
このファイルは、Oracle BI Applications Source Filesフォルダに配置する必要があります。
この項の内容は次のとおりです。
実績原価はE-Business Suiteのプロジェクト原価計算モジュールにある原価配分明細表から抽出され、原価明細ファクト(W_PROJ_COST_LINE_F)表にロードされます。
E-Business Suiteでは、このファクトのドキュメント通貨が取引通貨になります。
注意: ETLを実行してOracle Business Analytics Warehouseをロードする前に、原価を配分するE-Business Suiteのコンカレント・プログラム(PRC: 労務費の配分、PRC: 使用費およびその他原価の配分など)を実行する必要があります。すべての増分ETLの実行前に原価配分プログラムを実行しないと、原価配分ファクトが支出ファクト表の実際の支出と同期されません。
支出ファクト
支出ファクト(W_PROJ_EXP_LINE_F)は、PA_EXPENDITURE_ITEMS_ALLを基にしています。このファクトは、配分前の実際の支出データを示します。支出の配分を毎日実行しないけれども、一部のユーザーが頻繁に更新される支出データを確認する必要がある顧客は、このファクトを使用する必要があります。
注意: GL記帳日は、(原価配分中に)原価配分明細にのみ割り当てられ、支出項目レコードには割り当てられません。したがって、支出データは、エンタープライズ・カレンダ・ディメンションによってのみ分析可能であり、GLカレンダでは分析できません。また、GL勘定科目はデータが配分される場合にのみ関連付けられるので、GL勘定科目で支出データを分析することはできません。
原価ファクトの標準日付
原価ファクトの標準日付ディメンションは、配分明細表のPRVDR_GL_DATEに基づいています。一方、支出ファクトの標準日付ディメンションは、支出項目表のEXPENDITURE_DATEに基づいています。
複数のカレンダ日付ディメンションに、複数の組織のカレンダが格納されています。会計カレンダ(ディメンション - 会計カレンダ)によってデータを分析しているレポート内のレコードは、すべて同じカレンダを指している必要があります。このために、ダッシュボードのすべてのレポートには、プロジェクト・ビジネス・ユニットに対するフィルタが適用されます。プロジェクト・ビジネス・ユニットのすべての原価レコードが同じカレンダを指すようにするために、RCVR_GL_DATE列とRCVR_PA_DATE列を使用して、ファクト表のGL_ACCOUNTING_DT_WID列とPROJ_ACCOUNTING_DT_WID列にデータを移入します。支出OUビュー(原価ファクト内)は、企業カレンダを使用して構築することもできます。
原価ファクトのドメイン値について
プロジェクト費用振替ステータスはドメイン値としてモデル化されていて、FSMで構成できます。
原価ファクトの増分ロジック
原価のファクト表の増分抽出ロジックは、原価配分明細表の「REQUEST_ID」フィールドに依存します。このロジックは、W_PROJ_ETL_PSパラメータ表によって簡便化されています。
ODIインタフェースを使用して、ETL実行時のソース表内の最大リクエストIDがこの表に格納され、次にSDEタスク(SDE_ORA_PROJECTCOSTLINE)レベルのODI変数#EBS_REQUEST_ID_1に移入されます。これは、次の問合せを使用して初期化されます。
SELECT COALESCE((SELECT PRE_REQUEST_ID FROM QUALIFY_DS(W_PROJ_ETL_PS) WHERE TBL_NAME = 'PA_COST_DISTRIBUTION_LINES_ALL'),0) FROM_DUAL()
注意: 増分更新後にW_PROJ_COST_LINE_Fに原価レコードが見つからない場合は、My Oracle Supportからパッチ9896800をダウンロードしてください。このパッチに含まれるTech Noteには、この事象の発生シナリオについての説明と、提案される解決策が掲載されています。
支出項目のプロジェクト原価配分に関する情報をキャプチャするには、プロジェクト原価集計表(W_PROJ_COST_A)を使用します。初期ETLとそれに続く増分ETLを実行する前に、プロジェクト原価明細集計表を構成する必要があります。
初期ETLを実行する前に、プロジェクト原価明細集計ファクト表の時間集計レベルに対して、FSMでCOST_TIME_GRAINパラメータを構成する必要があります。
デフォルトでは、COST_TIME_GRAINパラメータの値はPERIODに設定されています。COST_TIME_GRAINパラメータに指定できる値は、次のとおりです。
PERIOD
QUARTER
YEAR
プロジェクト原価明細集計表は、初期ETLの実行時にベース表から完全にロードされます。この表のレコード数は、数百万件にも及ぶことがあります。そのため、増分ETLの実行後に、プロジェクト原価集計表がベース表から完全に再ロードされることはありません。Oracle Business Analytics Warehouseでは、次に示すように、ベース表の更新に伴い集計表を増分的に変更することで、増分集計の負荷が最小限になります。
プロジェクト原価集計表を構成するには:
Oracle Business Analytics Warehouseは、前回のETLの実行後にベース表で更新されるレコードを検索し、それらのレコードをW_PROJ_COST_LINE_TMP表にロードします。これらのレコードのメジャーは、(-1)で乗算されます。このタスクを担当するマッピングは、SIL_ProjectCostLinesFact_Derive_PreLoadImageです。
Oracle Business Analytics Warehouseは、前回のETLの実行後にベース表に挿入またはベース表で更新されるレコードを検索し、それらのレコードを符号を変えずに、W_PROJ_COST_LINE_TMP表にロードします。このタスクを担当するマッピングはSIL_ProjectCostLinesFact_Derive_PreLoadImageです。これは、PLP_ProjectCostLinesFact_Derive_PostLoadImageでベース表のレコードを更新または挿入する前に実行されます。
Oracle Business Analytics WarehouseはW_PROJ_COST_LINE_TMP表を集計し、W_PROJ_COST_A表と同じ粒度のW_PROJ_COST_A_TMPにロードします。
PLP_ProjectCostLinesAggregate_DeriveマッピングによりW_PROJ_COST_A集計表が検索され、その集計表に対して、既存のバケットの更新または新規のバケットの挿入が行われます(このマッピングはPLP_ProjectCostLinesAggregate_Load)。
収益実績明細レコードはE-Business Suiteのプロジェクト原価計算モジュールにある収益/イベント配分明細表(PA_CUST_REV_DISTRIB_LINES_ALLとPA_CUST_EVENT_DIST_ALL)から抽出され、収益明細ファクト(W_PROJ_REVENUE_LINE_F)表にロードされます。
E-Business Suiteでは、収益取引通貨コードが、このファクトのドキュメント通貨コードになります。
注意: 収益配分のためのE-Business Suiteコンカレント・プログラム(PRC: 単一プロジェクトの収益草案の生成、PRC: プロジェクト範囲の収益草案の生成など)は、ETLを実行してOracle Business Analytics Warehouseをロードする前に実行する必要があります。
収益ヘッダー・ファクト(W_PROJ_REVENUE_HDR_F)のプライマリ・ソースは、PA_DRAFT_REVENUES表になります。請求金額や収益金額などの収益明細メトリックも、この表で集計されます。
収益ファクトの標準日付
標準日付ディメンションは、収益草案表のGL_DATEに基づいています。
収益ファクト・ステージング表
ヘッダーと明細レベルの両方の収益ファクト表をロードする共通のステージング表です。
収益ファクトの複数通貨サポート
前受収益、未請求売掛金、為替差益、為替差損などの一部のメトリックは、現地通貨とグローバル通貨のみで使用できます。グローバル通貨での収益金額については、w_proj_revenue_line_fとw_proj_revenue_hdr_fのそれぞれに3つの列が存在します。
収益ファクトのドメイン値
プロジェクト収益ステータスはドメイン値としてモデル化されていて、FSMで構成できます。
収益ファクトの増分ロジック
収益ファクト表の増分抽出ロジックは、収益配分明細表の「REQUEST_ID」フィールドに依存しています。このロジックはW_PROJ_ETL_PSパラメータによって簡便化されており、ETL実行時おけるソース表内の最大リクエストIDが個別のODIプロセスを通じて、この表に格納されます。その後、ODIで、次に示すSDE_ORA_ProjectRevenueLineタスクの変数に値を移入するために使用されます。
#EBS_REQUEST_ID_2
この変数は、次の問合せを使用して初期化されます。
SELECT COALESCE((SELECT COALESCE(PRE_REQUEST_ID,0) FROM QUALIFY_DS(W_PROJ_ETL_PS) WHERE TBL_NAME ='PA_CUST_EVENT_RDL_ALL'),0) FROM_DUAL()
#EBS_REQUEST_ID_4
この変数は、次の問合せを使用して初期化されます。
SELECT COALESCE((SELECT COALESCE(PRE_REQUEST_ID,0) FROM QUALIFY_DS(W_PROJ_ETL_PS) WHERE TBL_NAME ='PA_CUST_REV_DIST_LINES_ALL'),0) FROM_DUAL()
#EBS_REQUEST_ID_4
この変数は、次の問合せを使用して初期化されます。
SELECT COALESCE((SELECT COALESCE(PRE_REQUEST_ID,0) FROM QUALIFY_DS(W_PROJ_ETL_PS) WHERE TBL_NAME ='PA_DRAFT_REVENUES_ALL'),0) FROM_DUAL()
プロジェクト原価集計表(W_PROJ_REVENUE_A)は、プロジェクト収益配分に関する情報を取得するために使用します。初期ETLの実行とそれに続く増分ETLを実行する前に、プロジェクト収益明細集計表を構成する必要があります。
初期ETLを実行する前に、プロジェクト収益明細集計ファクト表の時間集計レベルに対して、FSMでREVENUE_TIME_GRAINパラメータを構成する必要があります。
デフォルトでは、REVENUE _TIME_GRAINパラメータの値はPERIODに設定されています。REVENUE_TIME_GRAINパラメータに指定できる値は、次のとおりです。
PERIOD
QUARTER
YEAR
プロジェクト収益明細集計表は、初期ETLの実行時にベース表から完全にロードされます。この表のレコード数は、数百万件にも及ぶことがあります。そのため、増分ETLの実行後に、プロジェクト収益集計表がベース表から完全に再ロードされることはありません。Oracle Business Analytics Warehouseでは、ベース表の更新に伴い集計表を増分的に変更することで、増分集計の負荷が最小限になります。
プロジェクト収益集計表を構成するには:
Oracle Business Analytics Warehouseは、前回のETLの実行後にベース表で更新されるレコードを検索し、それらのレコードをW_PROJ_ REVENUE_LINE_TMP表にロードします。これらのレコードのメジャーは、(-1)で乗算されます。このタスクを担当するマッピングは、SIL_Project RevenueLinesFact_Derive_PreLoadImageです。
Oracle Business Analytics Warehouseは、前回のETLの実行以降にベース表に挿入またはベース表で更新されるレコードを検索し、それらのレコードを符号を変えずに、W_PROJ_REVENUE_LINE_TMP表にロードします。このタスクを担当するマッピングはSIL_ProjectRevenueLinesFact_Derive_PreLoadImageです。これは、PLP_ProjectRevenueLinesFact_Derive_PostLoadImageでベース表のレコードを更新または挿入する前に実行されます。
Oracle Business Analytics WarehouseはW_PROJ_ REVENUE _LINE_TMP表を集計し、W_PROJ_REVENUE_A表と同じ粒度のW_PROJ_REVENUE_A_TMPにロードします。
PLP_ProjectRevenueLinesAggregate_DeriveマッピングによりW_PROJ_REVENUE_A集計表が検索され、その集計表に対して、既存バケットの更新または新規バケットの挿入が行われます(このマッピングはPLP_ProjectRevenueLinesAggregate_Load)。
OLTPで次のSQLを使用してプロジェクト単位を取得し、コードがまだマップされていない場合はFSMでプロジェクト単位をウェアハウス(適合)単位にマップします。
select lookup_code, meaning, description from fnd_lookup_values where lookup_type='UNIT' and LANGUAGE='US';
Student Information Analytics (SIA)では、デフォルト提供されるStudent Information Analyticsモジュールに次のプレゼンテーション階層が実装されています。
階層-1: 学年度 → 学期
階層-2 (サブ計画階層): 学業機関 → 学歴 → 学業プログラム → 学業計画 → 学業サブ計画
階層-3 (計画階層): 学業機関 → 学歴 → 学業プログラム → 学業計画
階層-4 (プログラム階層): 学業機関 → 学歴 → 学業プログラム
階層-1は構成を必要としません。しかし、階層-2、3、4は、顧客設定と顧客データに従って、一定の構成が必要です。
この後は、サブ計画階層を構成する手順を説明します。同様の手順で、計画階層とプログラム階層を構成できます。
サブ計画階層の構成
サブ計画階層は、基本的に学業計画ディメンションのサブセットであるサブ計画ディメンションに基づいて作成されています。すべてのファクト行についてサブ計画レベルまでファクト・データが存在する場合、デフォルトのサブ計画階層のままで正しく動作するので、構成は必要ありません。
ただし、すべてのファクト行で少なくとも学業計画レベルまでデータが存在するとユーザーが判断し、学業サブ計画情報がオプションである場合は、学業計画階層(BMMレイヤーに既存)を使用する必要があります。
(前述のシナリオで)サブ計画階層を構成する手順は次のとおりです。
「学業機関」プレゼンテーション表の「プレゼンテーション」レイヤーから「SIA学業サブ計画」階層を削除します。
「ビジネス・モデルとマッピング」レイヤーの「SIA学業計画」階層を、特定のサブジェクト領域の「学業機関」プレゼンテーション表にドラッグ・アンド・ドロップします。
次の各プレゼンテーション列を、学業計画プレゼンテーション階層のそれぞれのプレゼンテーション階層レベルにドラッグ・アンド・ドロップします。
表B-87 プレゼンテーション表とプレゼンテーション列
SI番号 | プレゼンテーション表 | プレゼンテーション列 |
---|---|---|
1 |
学業機関/機関 |
ソース機関 |
1 |
学歴 |
学歴 |
2 |
学業プログラム |
学業プログラム |
3 |
学業計画 |
学業計画 |
ただし、すべてのファクト行で少なくとも学業プログラム・レベルまでデータが存在するとユーザーが判断し、学業サブ計画情報と学業計画情報がオプションである場合は、学業プログラム階層(同じくBMMレイヤーに既存)を使用する必要があります。
ただし、学歴階層を使用する場合は、先にそれを作成する必要があります。学歴階層はデフォルトでデプロイされており、カスタマイズが必要です。
バックログ表(W_SALES_BACKLOG_LINE_F)には、当月のバックログ・データが格納されます。一方、バックロク履歴表(W_SALES_BACKLOG_HIST_F)には、これまでのすべての月の履歴バックログ・データのスナップショットが格納されます。バックログ履歴表でバックログ・データを追跡する期間は、バックログ期間日付によって定義されます。この日付は、デフォルトでは月の最後のカレンダ日として設定されますが、構成可能です。バックログ履歴を月単位以外の長期間(四半期単位、年単位など)または短期間(日単位、週単位など)で表示するには、FSMパラメータのTIME_GRAINをDAY、WEEK、QUARTER、またはYEARに構成します。また、この項で説明するODIの変更を行う必要があります。
FSMの時間単位パラメータの設定
デフォルトでは、パラメータTIME_GRAINはMONTHに設定されています。集計期間を変更する場合、これらの変数を望ましいレベルに設定する必要があります。FSMでそれらの値を変更するには、「パラメータの管理」に移動し、'TIME_GRAIN'を選択して「編集」ボタンをクリックします。
FSMで時間単位パラメータを設定するには:
「パラメータの管理」に移動します。
TIME_GRAINを選択して「編集」ボタンをクリックします。
「パラメータのデフォルト値の管理」領域の「デフォルト値」フィールドで値を指定します。有効な値は次のとおりです。
DAY
WEEK
MONTH
QUARTER
YEAR
FSMの対応するパラメータ・タスクは、「バックログ期間日付の時間単位の構成」です。
ODIでのバックログ期間のKMオプションの設定
バックログ期間の集計期間は、デフォルトでは月単位に設定されています。集計期間を変更する場合、PLP_SalesBacklogHistoryFact_Load.W_SALES_BACKLOG_HISTORY_Fという名前のODIインタフェースのKMオプションOBI_DELETE_TYPEを設定する必要があります。
ODIでOBI_DELETE_TYPEを設定するには:
ODIデザイナ・ナビゲータで、「BIAppsプロジェクト」、「マッピング」、「PLP」、PLP_SalesBacklogHistoryFact_Loadフォルダの順に移動します。
インタフェースPLP_SalesBacklogHistoryFact_Load.W_SALES_BACKLOG_HISTORY_Fを開いて、「フロー」タブに移動します。
「プロパティ・インスペクタ」で、KMオプションOBI_DELETE_TYPEに移動し、FSMのTIME_GRAINパラメータ値の設定に従って、値を次のいずれかのオプションに変更します。このオプションの有効な値は次のとおりです。
CAL_DAY
CAL_WEEK
CAL_MONTH
CAL_QTR
CAL_YEAR
インタフェースを保存し、シナリオを再生成します。
時間ディメンションの最終日のデフォルト値は2020年12月31日です。この日付を延長する必要がある場合、Oracle BI Applications構成マネージャを使用して、変数END_DATEのデフォルト値をさらに先の日付(ただし、2050年12月31日が上限です)に変更する必要があります。時間ディメンション表は、次の増分ロードの際に自動的に拡張されます。
Oracle Business Analytics Warehouseのロード後に時間ディメンション表を再ロードするには:
共通ディメンションと日付ディメンションの拡張という名前のサブジェクト領域があります。日付ディメンションに複数カレンダが存在する場合は構成タグExtend Day Dimension Multiple Calendar Supportを選択し、存在しない場合は削除します。サブジェクト領域をアセンブルします。
タスクSil_DayDimension_XTNDを選択します。新しいSTART_DATE (= @ END_DATE +1)と新しいEND_DATEを選択し、パラメータ値を設定します。
タスクSDE_FUSION_TimePeriodMCalPeriod_XTNDを選択します。START_DATEはそのままで、新しいEND_DATEを選択します。
対応するロード計画を同じ名前で作成します。
ソースとして使用する場合に備えて、FILE_MCAL_CAL_D、FILE_MCAL_CONTEXT_G、FILE_MCAL_PERIOD_DS (これらの3つは普遍的)、およびFILE_MCAL_CONFIG_Gを変更することを忘れないでください。
Fusion Applicationsコンテナの場合のロード計画手順:
「共通-日付ディメンションの拡張」という名前のサブジェクト領域があります。日付ディメンションに複数カレンダが存在する場合は構成タグExtend Day Dimension Multiple Calendar Supportを選択し、存在しない場合は削除します。サブジェクト領域をアセンブルします。
タスクSil_DayDimension_XTNDを選択します。新しいSTART_DATE (= END_DATE +1)と新しいEND_DATEを選択し、パラメータ値を設定します。
タスクSDE_FUSION_TimePeriodMCalPeriod_XTNDを選択します。START_DATEはそのままで、新しいEND_DATEを選択します。
対応するロード計画をCommon-Extend Day Dimension Fusionという名前で作成します。
目的
この項では、スコアカード・ターゲット・ファイルを準備する方法について説明します。
オプションまたは必須
このタスクは、調達スコアカード機能を実装することを選択する場合にのみ必須です。
詳細なタスクの説明
ファイルfile_purch_scorecard_target.csvを使用して、KPIのターゲットを指定します。サポートされているディメンションは、時間ディメンションと調達ビジネス・ユニット・ディメンションです。
注意: このタスクの構成ファイル(複数の場合もあり)は、Oracle BI Applicationsインストールの次の場所にあります。 ソース独立ファイル: <Oracle Home for BI>\biapps\etl\data_files\src_files\。 ソース固有ファイル: <Oracle Home for BI>\biapps\etl\data_files\src_files\<source adaptor>。 システム管理者は、これらのファイルを別の場所にコピーして、この場所から読み取るためのODI接続を構成しているはずです。システム管理者に、これらのファイルの取得を依頼してください。構成が完了したら、システム管理者は、構成済ファイルをODIの読取り元にコピーする必要があります。 |
ソース・ファイルで次の値を必要とされるデータ形式で指定する必要があります。
四半期開始日
調達ビジネス・ユニットID
KPI名
KPIターゲット値
KPIターゲット値では、次のKPIがサポートされています。
# of Negotiation Lines Awarded Per Category # of POs Per Buyer # of Suppliers Per Category % of Fulfilled Requisition Lines Past Expected Date % of Late Receipts % of Processed Requisition Lines Past Expected Date % of Realized Savings % of Supplier Diversity Spend % of Unfulfilled Requisition Lines Past Expected Date Average Negotiation Cycle Time Average Requisition to Receipt Cycle Time Electronic Invoice % Manual Requisition Lines Rate Non-Agreement Purchase Rate Overall Accepted % Perfect Invoices % Purchase Order Schedule Line Return Rate Received On Time %
このトピックでは、購買サイクル明細集計パラメータの構成の詳細情報について説明します。
ETL用に購買サイクル明細表を集計するには、TIME_GRAINパラメータを構成します。このパラメータの値としてMonthが事前構成されています。有効な値は、DAY、WEEK、MONTH、QUARTER、YEARです。
購買サイクル明細集計表は、初期ETLの実行時にベース表から完全にロードされます。この表のレコード数は、数百万件にも及ぶことがあります。ETLの実行後は、購買サイクル明細集計表がベース表から完全に再ロードされることはありません。Oracle Business Analytics Warehouseでは、ベース表の更新に伴い集計表を増分的に変更することで、増分集計の負荷が最小限になります。
Oracle BI Applications構成マネージャでロード計画にサプライ・チェーン - 購買サイクル明細サブジェクト領域が含まれる場合、次のタスクによって購買サイクル明細データが抽出されます。
SIL_PurchaseCycleLinesAggregate_Derive_PreSoftDeleteImageは、前回のETLの実行後にベース表で削除されるレコードを検索し、それらのレコードをW_PURCH_CYCLE_LINE_TMP表にロードします。このタスクは、ベース表からそれらのレコードが削除される前に、ソース固有のウィンドウで実行されます。
SIL_PurchaseCycleLinesAggregate_Derive_PreLoadImageは、前回のETLの実行後にベース表で更新されるレコードを検索し、それらのレコードをW_PURCH_CYCLE_LINE_TMP表にロードします。これらのレコードのメジャーは、(-1)で乗算されます。このタスクは、ベース表でそれらのレコードが更新される前に、ソース固有のワークフローで実行されます。
PLP_PurchaseCycleLinesAggregate_Derive_PostLoadImageは、前回のETLの実行後にベース表に挿入またはベース表で更新されるレコードを検索し、それらのレコードを符号を変えずにW_PURCH_CYCLE_LINE_TMP表にロードします。このタスクは、それらのレコードがベース表で更新またはベース表に挿入された後に、ロード後処理ワークフローで実行されます。
PLP_PurchaseCycleLinesAggregate_Loadは、W_PURCH_CYCLE_LINE_TMP表を集計し、W_PURCH_CYCLE_LINE_A集計表と結合して、集計表に新しいバケットを挿入するか、集計表の既存のバケットを更新します。
このトピックでは、購買受入集計パラメータの構成の詳細情報について説明します。
ETL用に購買受入表を集計するには、TIME_GRAINパラメータを構成します。このパラメータの値としてMonthが事前構成されています。有効な値は、DAY、WEEK、MONTH、QUARTER、YEARです。
購買受入明細集計表は、初期ETLの実行時にベース表から完全にロードされます。 この表のレコード数は、数百万件にも及ぶことがあります。そのため、増分ETLの実行後に、購買受入集計表がベース表から完全に再ロードされることはありません。Oracle Business Analytics Warehouseでは、ベース表の更新に伴い集計表を増分的に変更することで、増分集計の負荷が最小限になります。
Oracle BI Applications構成マネージャでロード計画にサプライ・チェーン - 購買受入サブジェクト領域が含まれる場合、次のタスクによって購買受入データが抽出されます。
SIL_PurchaseReceiptAggregate_Derive_PreSoftDeleteImageは、前回のETLの実行後にベース表で削除されるレコードを検索し、それらのレコードをW_PURCH_RCPT_TMP表にロードします。これらのレコードのメジャーは、(-1)で乗算されます。このタスクは、ベース表からそれらのレコードが削除される前に、ソース固有のワークフローで実行されます。
SIL_PurchaseReceiptAggregate_Derive_PreLoadImageは、前回のETLの実行後にベース表で更新されるレコードを検索し、それらのレコードをW_PURCH_RCPT_TMP表にロードします。これらのレコードのメジャーは、(-1)で乗算されます。このタスクは、ベース表でそれらのレコードが更新される前に、ソース固有のワークフローで実行されます。
PLP_PurchaseReceiptAggregate_Derive_PostLoadImageは、前回のETLの実行後にベース表に挿入またはベース表で更新されるレコードを検索し、それらのレコードを符号を変えずに、W_PURCH_RCPT_TMP表にロードします。このタスクは、それらのレコードがベース表で更新またはベース表に挿入された後に、ロード後処理ワークフローで実行されます。
PLP_PurchaseReceiptAggregate_Loadは、W_PURCH_RCPT_TMP表を集計し、W_PURCH_RCPT_A集計表と結合して、集計表に新しいバケットを挿入するか、集計表の既存のバケットを更新します。
目的
ワークフォース・イベント・ディメンションには、HCMメトリックの多くで使用される適合ドメインが多数存在します。これらのドメインは、適切に構成してレポートに正確な情報が含まれるようにする必要があります。
オプションまたは必須
このタスクはオプションです。ただし、デフォルト構成にはOLTP設定が十分に反映されていない可能性があるので、レポートが正確であることを保証するためにレビューする必要があります。
適用対象
すべてのソース。ただし、このドメインの構成方法は、ソースごとに異なります。
詳細なタスクの説明
ワークフォース・イベント・ディメンション/ファクトに関連するドメイン・マッピングを構成します。ワークフォース・イベント、サブグループ、およびグループのドメイン・マッピングを使用して、採用数、退職、異動などのイベントを分類したり、自己都合退職や会社都合退職などの様々なサブタイプを詳細にドリルダウンしたりします。
これらのドメインは階層として設計されているので、ベース・レベルではすべてのイベントが、イベントを追加するために拡張可能な適合ワークフォース・イベント・ドメインにマップされる必要があります。このドメインのイベントには、カスタム・メトリックを定義できます。上位レベルのグループ・ドメインは、詳細へのドリルが可能です。たとえば、採用(グループ)は、新しい採用または再雇用(サブグループ)にブレークダウン可能です。
E-Business Suiteの例
E-Business Suiteの場合、イベント・ソース、イベント事由、および変更の組合せを組み合せて、ドメイン・マッピングを構成します。
イベント・ソースは、イベントの発生元です。これらはすでにシードされています。たとえば、ASG、FTE、HDC、SALです。
イベント事由は、アプリケーション参照表から取得する対応する事由です。事由コードにはプレフィックスとして、対応する事由タイプが付きます。
変更の組合せを使用して、組織、ジョブ、等級、事業所、ポジション、または監督者の変更にイベントをマップできます。これらを任意に組み合せて指定できます。いくつかの例がシード済です。
要件の例:
昇格・昇進を、事由が昇格・昇進であり等級変更を伴うアサイメント変更として定義します。
再構築を、事由が再構築である組織変更として定義します。
異動を、他のなんらかの事由による組織変更として定義します。
実装の例:
再構築を「ワークフォース・イベント詳細」ドメインに追加します。
再構築を「ワークフォース・イベント・サブグループ」ドメインの異動にマップします。
異動はすでに「ワークフォース・イベント・グループ」ドメインの異動にマップされています。
必須マッピングに必要な新しいソース・ドメイン・メンバーを「ソース・ワークフォース・イベント事由の組合せ」から追加します。
ASG~PROMOTION~Grd=Y
ASG~RESTRUCTURE~Org=Y
次のマッピングを、ドメイン・マップ「ソース・ワークフォース・イベント事由の組合せ」→「ワークフォース・イベント詳細」に追加します。
ASG~PROMOTION~Grd=Y > ASG_PROMOTION
ASG~RESTRUCTURE~Org=Y > RESTRUCTURE
異動の残りの定義はすでにシード済なので、変更は必要ありません。
次のようなドメイン・マッピングが生成されます。影付きの行はシード済のドメイン・マッピングです。
注意
複数一致は許容されています。たとえば、組織変更および事由が再構築であるアサイメント変更の場合、マッピングはTRANSFERまたはRESTRUCTUREのどちらかに一致します。事由が完全一致であることは、任意の事由との一致よりも優先されるので、結果はRESTRUCTUREになります。
PeopleSoftの例
PeopleSoftの場合、処理および処理事由を組み合せて、ドメイン・マッピングを構成します。処理事由コードにはプレフィックスとして、対応する処理コードが付きます。
要件の例:
再構築を、事由が再構築である異動処理として定義します。
異動を、他のなんらかの事由による異動処理として定義します。
実装の例:
再構築を「ワークフォース・イベント詳細」ドメインに追加します。
再構築を「ワークフォース・イベント・サブグループ」ドメインの異動にマップします。
異動はすでに「ワークフォース・イベント・グループ」ドメインの異動にマップされています。
次のマッピングを、ドメイン・マップ「ソース・ワークフォース・イベントおよび事由」→「ワークフォース・イベント詳細」に追加します。
XFR~RESTRUCTURE -> RESTRUCTURE
異動の残りの定義はすでにシード済なので、変更は必要ありません。
次のようなドメイン・マッピングが生成されます。影付きの行はシード済のドメイン・マッピングです。
注意
複数一致は許容されています。たとえば、事由が再構築である異動処理の場合、マッピングはTRANSFERまたはRESTRUCTUREのどちらかに一致します。事由が完全一致であることは、任意の事由との一致よりも優先されるので、結果はRESTRUCTUREになります。
Fusionの例
Fusionの場合、ワークフォース・イベントを決定するための2つのドメイン・マッピングがあります。シード済マッピングは、デフォルト・ワークフォース・イベントを提供するためにのみ処理タイプを使用します。このマッピングは、処理および処理事由の組合せを使用するドメイン・マッピングにより上書きされる可能性があります。
要件の例:
再構築を、事由が再構築である異動処理として定義します。
異動を、他のなんらかの事由による異動処理として定義します。
実装の例:
再構築を「ワークフォース・イベント詳細」ドメインに追加します。
再構築を「ワークフォース・イベント・サブグループ」ドメインの異動にマップします。
異動はすでに「ワークフォース・イベント・グループ」ドメインの異動にマップされています。
次のマッピングを、ドメイン・マップ「ソース・ワークフォース・イベントおよび事由」→「ワークフォース・イベント詳細」に追加します。
TRANSFER~RESTRUCTURE -> RESTRUCTURE
異動の残りの定義はすでにシード済なので、変更は必要ありません。
処理と処理事由から次のようなドメイン・マッピングが生成されます。
注意
「ソース・ワークフォース・イベントおよび事由」ドメイン・マッピングには、シード済マッピングは存在しません。このドメイン・マッピングで一致が見つからない場合は、「ソース・ワークフォース・イベント・タイプ」ドメイン・マッピングのデフォルトを使用します。
依存関係
依存関係はありません。
ERPに最低限必要なレベルのProject Applicationsを実装していない場合、Oracle Project Analyticsのライセンスを取得していない場合、またはProcurement and Spend Analyticsではプロジェクト・ディメンションは重要ではないと考えている場合、調達および支出分析とプロジェクトの統合を無効化する必要があります。それ以外の場合は、統合を有効化できます。
特定の調達ファクトではいくつかのプロジェクト管理ディメンションがサポートされており、たとえばプロジェクトおよびタスク・ディメンションによって調達ファクトを分析できます。
これらのディメンションは、デフォルトで(すなわちインストール時に) Procurement and Spend Analyticsウェアハウスに移入され、その外部キーは次のファクトで解決されます。
経費概要(Project Dim、Task Dim、Financial Resource Dim)
費用請求書配分(Project Dim、Task Dim)
購買オーダー(Project Dim、Task Dim)
購買依頼(Project Dim、Task Dim)
Oracle Procurement and Spend Analyticsの次のファクト表は、Project Analyticsのディメンションと統合されています。
W_EXPENSE_F
W_AP_INV_DIST_F
W_AP_XACT_F
W_PURCH_COST_F
W_RQSTN_LINE_COST_F
Project Analyticsと調達および支出のサブジェクト領域の統合を有効化するには:
調達および支出分析のファクト・グループを選択すると、ロード計画ジェネレータが自動的にプロジェクト関連のディメンションとタスクをロード計画に取り込みます。他に必要な手順はありません。
Project Analyticsと調達および支出のサブジェクト領域の統合を無効化するには:
ODIデザイナ・ナビゲータで、「ロード計画と生成されたシナリオ」に移動し、生成されたロード計画を開きます。
ロード計画を次の順に開きます。
1 SDE Extract→2 SDE Dimension Group→Parallel
次のディメンション・グループを無効化します。
- SDE Dims PROJECT_DIM
- SDE Dims PROJRSRC_DIM
- SDE Dims TASK_DIM
ロード計画を保存します。
この項では、Oracle Spend Classificationと一緒にデプロイされているOracle Procurement and Spend Analyticsに適用する構成手順について説明します。Oracle Spend Classificationと必要なパッチを実装する場合は、Oracle Spend Classificationの製品ドキュメントを参照してください。
Oracle Spend Classificationを実装していない場合、BIリポジトリのプレゼンテーション・レイヤーからOracle Spend Classification統合メタデータを削除するか、非表示にすることを選択できます(Oracle Spend Classificationメタデータの削除の詳細は、第B.2.104項「Spend Classification統合メタデータの削除方法」を参照)。
注意: Oracle Spend ClassificationはOracle BI Applicationsのコア製品スイートには含まれません。また、Oracle BI Applicationsのどのモジュールともパッケージされていません。これは、Oracleが提供する独立したソリューションであり、別途ライセンスが必要です。Oracle Spend Classificationのライセンスを取得して実装することを検討される場合は、お客様の担当営業までご連絡ください。
Oracle Spend Classificationは、未分類の支出を品目カテゴリに変換して支出の精度を高めるためにOracle Procurement and Spend Analyticsと連携して使用できる補完的製品です。Oracle Procurement and Spend Analyticsは、Oracle Spend Classificationと連携させることも、単独で使用することもできるように設計されています。
典型的な調達システムの場合、品目および品目カテゴリを参照しない購買オーダー、請求書、および経費に関するトランザクションを多数使用し、その多くは品目摘要が自由形式テキストで記述されています。Oracle Procurement and Spend Analyticsを実装する場合、このようなトランザクションは、対応する品目や品目カテゴリが存在しないので、未分類としてシステムに取り込まれます。組織の支出が間接支出の大部分を占める場合、この問題はさらに顕著になります。
Oracle Procurement and Spend Analyticsは、Oracle Business Analytics WarehouseからOracle Spend Classificationにデータを送信し、分類済データをOracle Business Analytics Warehouseに返信する必要があるインフラストラクチャにインストールします。このインフラストラクチャは、Oracle Procurement and Spend AnalyticsとOracle Spend Classificationの両方の利点の活用を考えているお客様向けの追加機能として提供されます。
Oracle Spend Classificationを使用しない場合、Oracle Procurement and Spend Analyticsをスタンドアロン・ソリューションとしてデプロイできます。また、その機能をOracle Spend Classificationに依存しない形でデプロイできます。
この項では、Oracle Spend Classificationで使用可能なOracle Spend Classificationのメタデータとリポジトリ・メタデータについて説明します。
カテゴリ・コードを拡充し、自動割当するために、次のファクトがOracle Data Classificationに統合されています。
W_AP_INV_DIST_F
W_PURCH_COST_F
W_RQSTN_LINE_COST_F
UNSPSC、Oracle Purchasingカテゴリ、および3つのカスタム・カテゴリの合計5種類のタクソノミがサポートされています。分類結果論理表ソースは、次の列に格納されます。
AUTO_UNSPSC_WID
AUTO_PURCHASING_CATEGORY_WID
AUTO_CUSTOM_CATEGORY1_WID
AUTO_CUSTOM_CATEGORY2_WID
AUTO_CUSTOM_CATEGORY3_WID
分析メタデータ・リポジトリ(RPD)は、デフォルトで次のように構成されています。
UNSPSC、Oracle Purchasingカテゴリ、およびカスタム・カテゴリ1は、ビジネス・モデルとマッピング・レイヤーまで構成されています。ファクトとディメンション名は次のとおりです。
Fact - Spend and AP Invoice Distribution
Fact - Purchasing – Order
Fact - Purchasing – Requisition
Dim - Auto UNSPSC
Dim - Auto Purchasing Category
Dim - Auto Custom Category1
「プレゼンテーション」レイヤーでは、「調達および支出 - 請求書明細」の次のフォルダにデータ分類用列があります。
データ分類
自動UNSPSC
自動購買カテゴリ
自動カスタム・カテゴリ1
購買オーダーおよび購買依頼サブジェクト領域でUNSPSC、Oracle Purchasingカテゴリ、およびカスタム・カテゴリ1を公開する場合、次の手順を実行します。
UNSPSC、Oracle Purchasingカテゴリ、およびカスタム・カテゴリ1をデプロイするには:
Oracle BI EE管理ツールで、BIメタデータ・リポジトリ(例: OracleBIAnalyticsApps.rpd)を編集します。
RPDファイルは、\bifoundation\OracleBIServerComponent\coreapplication_obisn\repositoryフォルダにあります。
「プレゼンテーション」レイヤーで次を実行します。
「調達および支出 - 請求書明細」フォルダを開きます。
次のフォルダを複数選択し、右クリックしてコピーします。
データ分類
自動UNSPSC
自動購買カテゴリ
自動カスタム・カテゴリ1
購買オーダーにOracle Spend Classificationを実装するには、「調達および支出 - 購買オーダー」フォルダを選択し、右クリックして選択したフォルダに貼り付けます。
購買依頼にOracle Spend Classificationを実装するには、「調達および支出 - 購買依頼」フォルダを選択し、右クリックして選択したフォルダに貼り付けます。
新しいフォルダを検証します。
必要に応じて、プレゼンテーション・サービス・カタログを表示するビジネス・ユーザーに見せる順序で、フォルダを並べ替えます。
リポジトリを保存して閉じます。
カスタム・カテゴリ2とカスタム・カテゴリ3をデプロイするには:
注意: このタスクでは例としてFact_W_AP_INV_DIST_Fファクトを使用しますが、他のファクトをデプロイする場合もこの手順を適用できます。
Oracle BI EE管理ツールで、BIメタデータ・リポジトリ(例: OracleBIAnalyticsApps.rpd)を編集します。
RPDファイルは、\bifoundation\OracleBIServerComponent\coreapplication_obisn\repositoryフォルダにあります。
「物理」レイヤーで次を実行します。
Oracle Data Warehouseの下にある「Dim_W_PROD_CAT_DH_AUTO_CUSTOM_CATEGORY1」を右クリックして、「複製」を選択します。
名前をDim_W_PROD_CAT_DH_AUTO_CUSTOM_CATEGORY2に変更します。
次の条件を使用して、ディメンションDim_W_PROD_CAT_DH_AUTO_CUSTOM_CATEGORY2とファクトFact_W_AP_INV_DIST_Fを結合します。
Dim_W_PROD_CAT_DH_AUTO_CUSTOM_CATEGORY2.ROW_WID = Fact_W_AP_INV_DIST_F.'AUTO_CUSTOM_CATEGORY2_WID
「ビジネス・モデルとマッピング」レイヤーで、次を実行します。
表Dim - Auto Custom Category1のすぐ下にDim - Auto Custom Category2を作成します。
階層「自動カスタム・カテゴリ1」の下に、物理表Dim_W_PROD_CAT_DH_AUTO_CUSTOM_CATEGORY2に基づいてDim - Auto Custom Category2を作成します。
Dim - Auto Custom Category1をFact - Spend and AP Invoice Distributionに結合します。
Fact - Spend and AP Invoice Distributionを編集します。Fact_W_AP_INV_DIST_F。「内容」タブを表示し、Auto Custom Category2のレベルを「カスタム階層のベース・レベル」に設定します。
「プレゼンテーション」レイヤーで次を実行します。
「調達および支出 - 請求書明細」フォルダにAuto Custom Category 2という名前でサブフォルダを作成します。フォルダを編集し、次の文字列を正確に「摘要」ボックスに追加します。
Auto Custom Category2 becomes a sub-folder of Data Classification.
このフォルダが「自動カスタム・カテゴリ1」の下に表示されるように並べ替えます。
「ビジネス・モデルとマッピング」レイヤーのDim - Auto Custom Category1の列を、「プレゼンテーション」レイヤーのAuto Custom Category 2にドラッグします。
リポジトリを保存して閉じます。
カスタム・カテゴリ3について手順2-5を繰り返します。
企業カレンダ(またはレポート・カレンダ)を使用して、相互サブジェクト領域分析を実行できます。企業カレンダ表には、W_ENTプレフィックスが付いています。
企業カレンダとして、OLTPソースの会計カレンダまたはウェアハウスで生成されたカレンダの1つを設定できます。それには、Business Intelligence Applicationsの構成マネージャで、次のソース・システム・パラメータを設定します。
- GBL_CALENDAR_ID
- GBL_DATASOURCE_NUM_ID
この後の各項では、様々なシナリオで企業カレンダのソース・システム・パラメータを設定する方法について説明します。
シナリオ1: Oracle EBS会計カレンダを企業カレンダとして使用する場合
Oracle EBS企業カレンダのソース・システムのOracle BI Applications構成マネージャのパラメータ:
GBL_CALENDAR_ID
このパラメータは、企業カレンダを選択するために使用します。非生成カレンダの場合はMCAL_CAL_NAME~MCAL_PERIOD_TYPEである必要があります。たとえば、企業カレンダのidがAccounting、カレンダのperiod_typeが41である場合、GBL_CALENDAR_IDはAccounting~41になります。
注意: MCAL_CAL_NAMEとMCAL_PERIOD_TYPEは、GL_PERIODS表(Oracle EBS OLTP表)のPERIOD_SET_NAMEとPERIOD_TYPEからそれぞれ取得します。MCAL_CAL_NAME~MCAL_PERIOD_TYPEの組合せの有効なリストを確認するには、OLTPで次の問合せを実行します。
SELECT DISTINCT PERIOD_SET_NAME || '~' || PERIOD_TYPE FROM GL_PERIODS;
GBL_DATASOURCE_NUM_ID
企業カレンダが生成カレンダではない場合、カレンダ定義の取得元のソース・システムのDATASOURCE_NUM_IDである必要があります。たとえば、PeopleSoftとOracleの2つのデータ・ソースがあり、グローバル・カレンダをOracleデータ・ソースから取得する場合、このパラメータ値でOracleデータ・ソースを指定する必要があります。次の表に、Oracle EBSの各バージョンでDATASORUCE_NUM_IDに事前設定されている値を示します。
GBL_CALENDAR_IDとGBL_DATASOURCE_NUM_IDを設定するには、Oracle BI Applications構成マネージャにログインし、左側にあるナビゲーション・バーの「データ・ロード・パラメータの管理」をクリックします。「データ・ロード・パラメータの管理」ページが表示されたら、パラメータ・フィールドに「GBL_CALENDAR_ID」と入力し、パラメータ・タイプとして「コード」を選択します。次に「検索」ボタンをクリックすると、パラメータとその現在値が表示されます。次に、GBL_CALENDAR_IDの現在値として10000が表示されている例を示します。
GBL_CALENDAR_IDの値を変更するには、その現在値をクリックします。「編集ダイアログ」がポップアップ表示されます。
「パラメータ値」フィールドに望ましい値を入力し(値に単一引用符を付ける必要はありません。たとえば、'Accounting~41'ではなくAccounting~41とだけ入力します)、「保存してクローズ」をクリックして変更内容を保存します。GBL_CALENDAR_IDの新しい値が設定されます。
同様の手順でGBL_DATASOURCE_NUM_IDも設定します。まず、この変数を検索して取得する必要があります。検索結果が表示されたら、その現在値をクリックします。「編集ダイアログ」がポップアップ表示されます。そこでパラメータ値を変更して、変更内容を保存します。
注意: 使用可能なOracle EBSカレンダは、OLAPウェアハウス表W_MCAL_CAL_Dにもロードされます。したがって、DWで次の問合せを実行することで表示できます。
SELECT MCAL_CAL_ID, MCAL_CAL_NAME, MCAL_CAL_CLASS, DATASOURCE_NUM_ID FROM W_MCAL_CAL_D
WHERE DATASOURCE_NUM_ID = <使用するEBSのバージョンに対応する値>;
シナリオ2: PeopleSoft会計カレンダを企業カレンダとして使用する場合
PeopleSoft企業カレンダのソース・システムのOracle BI Applications構成マネージャのパラメータ:
GBL_CALENDAR_ID
このパラメータは、企業カレンダを選択するために使用します。非生成カレンダの場合はSETID~CALENDAR_IDである必要があります。たとえば、企業カレンダのidが01、SET_IDがSHAREである場合、GBL_CALENDAR_IDはSHARE~01になります。
注意: SETIDとCALENDAR_IDは、PS_CAL_DEFN_TBL表(PeopleSoft OLTP表)から取得します。SETID~CALENDAR_IDの組合せの有効なリストを確認するには、OLTPで次の問合せを実行します。
SELECT DISTINCT SETID || '~' || CALENDAR_ID FROM PS_CAL_DEFN_TBL;
GBL_DATASOURCE_NUM_ID
グローバル・カレンダが生成カレンダではない場合、カレンダ定義の取得元のソース・システムのDATASOURCE_NUM_IDである必要があります。たとえば、PeopleSoftとOracleの2つのデータ・ソースがあり、グローバル・カレンダをPeopleSoftソースから取得する場合、このパラメータ値でPeopleSoftデータ・ソースを指定する必要があります。次の表に、PeopleSoftの各バージョンでDATASORUCE_NUM_IDに事前設定されている値を示します。
Oracle BI Applications構成マネージャでこの2つの変数を設定する手順は、Oracle EBSの場合の手順と同じです。
注意: 使用可能なPeopleSoftカレンダは、OLAPウェアハウス表W_MCAL_CAL_Dにもロードされます。したがって、DWで次の問合せを実行することで表示できます。
SELECT MCAL_CAL_ID, MCAL_CAL_NAME, MCAL_CAL_CLASS, DATASOURCE_NUM_ID FROM W_MCAL_CAL_D
WHERE DATASOURCE_NUM_ID = <使用するPeopleSoftのバージョンに対応する値>;
シナリオ3: ウェアハウスで生成されたカレンダを企業カレンダとして使用する場合
生成された企業カレンダのソース・システムのOracle BI Applications構成マネージャのパラメータ:
GBL_CALENDAR_ID
このパラメータは、生成されたカレンダ(4-4-5タイプまたは14期間タイプのカレンダ)のCALENDAR_IDである必要があります。デフォルトでは4-4-5カレンダのCALENDAR_IDは10000、13期間カレンダのCALENDAR_IDは10001です。
GBL_DATASOURCE_NUM_ID
グローバル・カレンダが生成カレンダである場合、OLAP (Oracle Business Analytics Warehouse)のDATASOURCE_NUM_ID値(999)である必要があります。
Oracle BI Applications構成マネージャでこの2つの変数を設定する手順は、Oracle EBSの場合の手順と同じです。
注意1: ユーザーは、企業カレンダとして選択可能な、ウェアハウスで生成された追加のカレンダを生成できます。
注意2: Oracle Business Analytics Warehouseでは、使用可能なカレンダは、OLAP表W_MCAL_CAL_Dにもロードされます。したがって、DWで次の問合せを実行することで表示できます。
SELECT MCAL_CAL_ID, MCAL_CAL_NAME, MCAL_CAL_CLASS, DATASOURCE_NUM_ID FROM W_MCAL_CAL_D WHERE DATASOURCE_NUM_ID = 999;
複数ソースのETLでのGBL_CALENDAR_IDとGBL_DATASOURCE_NUM_IDの設定
複数ソースのETLを実行する際、複数のデータ・ソースから複数のカレンダをロードできます。ただし、この場合、グローバル・カレンダとして選択できるのは、1つのカレンダのみです。たとえば、PeopleSoftとOracleの2つのデータ・ソースがある場合、PeopleSoftのカレンダまたはOracleのカレンダのどちらか1つのみをグローバル・カレンダとして選択できます。GBL_CALENDAR_IDとGBL_DATASOURCE_NUM_IDの2つのパラメータは、選択するグローバル・カレンダに従って、Oracle BI Applications構成マネージャで設定する必要があります。Oracle BI Applications構成マネージャでは、決してGBL_CALENDAR_IDまたはGBL_DATASOURCE_NUM_IDに複数の値を設定しないでください。複数の値を設定すると、ETLの実行に失敗します。
この項では、国連標準製品およびサービス・コード(UNSPSC)のコードをOracle Business Analytics Warehouseの製品と商品に割り当てる方法について説明します。UNSPSCは、製品とサービスを効率よく正確に分類するためのオープンでグローバルな複数セクターの標準を提供します。
次のスクリーンショットは、UNSPSCデータが含まれるファイルから抜粋したデータです。ここでは、CatsのUNSPSCコードが10101501、DogsのUNSPSCコードが10101502であることが示されています。
UNSPSCパラメータの構成について
Oracle BI Applications構成マネージャでは、UNSPSC_DATALOADとUNSPSC_WHERE_CLAUSEの2つのデータ・ロード・パラメータを使用して、UNSPSCデータをロードする方法を構成します(次のスクリーンショットの例を参照)。
UNSPSCコードを製品に割り当てるには:
Oracle BI Applications構成マネージャで、次の手順を実行して、UNSPSC_DATALOADという名前のデータ・ロード・パラメータを編集します。
「タスク」ペインで「データ・ロード・パラメータの管理」をクリックして「データ・ロード・パラメータの管理」ページを開きます。
「検索」ペインを使用してUNSPSC_DATALOADを特定し、「データ・ロード・パラメータ」のリストでUNSPSC_DATALOADを選択します。
「UNSPSC_DATALOADに対するグループ固有パラメータ値」領域で、UNSPSC_DATALOADパラメータの値を編集して、次のいずれかの値を指定します。
- NONE (デフォルト): UNSPSCデータはロードされません。
- FULL: SILプロセスは常にW_PRODUCT_DのデータをすべてファイルFILE_ITEM_TO_UNSPSC.csvに挿入します。
- EMPTY: SILプロセスはUNSPSC_CODEがNULLである品目のみロードします。
- OWN_SQL: ユーザーがUNSPSC_WHERE_CLAUSEデータ・ロード・パラメータ(手順1dを参照)を使用して、カスタム条件を指定します。
- INCR: 新しい品目レコードと更新された品目レコードをファイルFILE_ITEM_TO_UNSPSC.csvに挿入します。
- INCR_NEW: 新しい品目のみをファイルFILE_ITEM_TO_UNSPSC.csvにロードします。
UNSPSC_DATALOAD値をOWN_SQLに設定した場合、UNSPSC_WHERE_CLAUSEデータ・ロード・パラメータを編集して、カスタム条件を定義するSQL文を指定する必要があります。次に例を示します。
W_PRODUCT_D.INTEGRATION_ID <>0
Oracle BI Applications構成マネージャで、このオファリングおよび機能領域のロード計画を作成して実行します。
ロード計画の実行時に、プロセスSIL_Product_ItemtoUNSPSC_File_Loadはデータをファイルfile_item_to_unspsc.csvにロードします。このファイルは、次の場所に書き込まれます。
<Oracle Home for BI>\biapps\etl\data_files\src_files\
たとえば、ファイルfile_item_to_unspsc.csvには、次のデータが格納されます。
PRODUCT_ID PRODUCT_NAME PART_NUMBER UNSPSC_CODE DATASOURCE_NUM_ID 1-2IBV TEST 5142 200 1002A TEST 5142 200
file_item_to_unspsc.csvの内容をコピーして、file_item_to_unspsc_update.csvの内容を置き換えます。
インストール時のファイルfile_item_to_unspsc_update.csvの内容はサンプルです。
ファイルfile_item_to_unspsc_update.csvで、分類する各製品のUNSPSC_CODE列に、UNSPSCコードを追加します。
たとえば、UNSPSCコードの10124708をPRODUCT1に、UNSPSCコードの1010AをPRODUCT2に、それぞれ割り当てるとします。編集後のファイルfile_item_to_unspsc_update.csvには、次のデータが含まれています。
PRODUCT_ID PRODUCT_NAME PART_NUMBER UNSPSC_CODE DATASOURCE_NUM_ID 1-2IBV PRODUCT1 5142 10124708 200 1002A PRODUCT2 5142 1010A 200
UNSPSCコードのリストは、file_unspsc.csvで参照できます。
注意: UNSPSC_DATALOADの値を変更してから手順1と手順2を再実行する場合、手順3と手順4も再実行する必要があります。たとえば、新しい製品または更新された製品をロードするためにUNSPSC_DATALOADの値をINCRに変更する場合です。
通貨換算が必要なのは、業務で複数通貨を使用するトランザクションを行う可能性があるためです。意味のあるレポートを作成するには、共通通貨を使用する必要があります。Oracle Business Analytics Warehouseでは、次の通貨で金額が格納されます。
文書通貨。文書通貨は、トランザクションの通貨です。たとえば、メキシコのサプライヤから椅子を購入する場合、文書通貨はおそらくメキシコ・ペソになります。英国に出張して、英国内での食事経費に関する経費精算書を届け出た場合、経費精算書の文書通貨はおそらくイギリス・ポンドになります。
現地通貨。現地通貨は、元帳の基準通貨または会計仕訳の記録に使用する通貨です。
グローバル通貨。Oracle BI Applicationsには3つのグローバル通貨があります。これらは、Oracle Business Analytics Warehouseで使用する共通通貨です。たとえば、所属する組織が本社を米国に置く多国籍企業である場合、おそらく3つのグローバル通貨の1つとして米国ドル(USD)を選択します。
グローバル通貨は、企業全体の分析を作成する場合に便利です。たとえば、ユーザーが企業全体のデータを他の通貨で表示する場合があります。ロード・マッピングにより、ソースから抽出したすべての金額の文書通貨金額と現地通貨金額がターゲット表にロードされます。同時に、文書通貨金額を3つのグローバル通貨それぞれに換算するために必要な換算レートもロードされます。ファクト表には、現地通貨金額と文書通貨金額が格納される2つの金額列があります。さらに、グローバル通貨(たとえばglobal_amount1)が格納される3つの列とそれぞれに対応する換算レート列があります。
多くの場合、ソース・システムは文書通貨金額を提供します。これは通貨処理のデフォルト設定です。ソース・システムが提供するのが文書通貨金額のみである場合、ソース・アダプタはソース・システムに基づいて適切な通貨が割り当てられている現地通貨コードを特定する検索を実行します。検索した後、抽出マッピングにより、文書通貨金額および文書通貨コードと現地通貨コードを使用するロード・マッピングが行われます。ロード・マッピングは、提供された現地通貨コードを使用して通貨換算を実行し、現地通貨金額を算出します。さらに、グローバル通貨設定を取得し、3つのグローバル通貨のそれぞれに対応する換算レートを参照します。
グローバル通貨を指定するには、GLOBAL1_CURR_CODE、GLOBAL2_CURR_CODE、およびGLOBAL3_CURR_CODEの各パラメータを使用します。
注意: GLOBAL1_CURR_CODE、GLOBAL2_CURR_CODEなどのパラメータを使用してグローバル通貨を構成する前に、次の手順を実行して通貨ドメインを構成する必要があります。
|
PeopleSoftのプロジェクト原価ファクトを構成するには、次を実行します。
FSMタスク「PeopleSoftのプロジェクト・リソース区分の構成」を完了します。
FSMタスク「PeopleSoftのプロジェクト原価計算間接費の構成方法」を完了します。
このタスクの手順は、FSMで表示されます。第B.2.63項「PeopleSoftのプロジェクト原価計算間接費の構成方法」でもアクセスできます。
Oracle BI Applicationsは、PeopleSoftツリー・マネージャで定義されているツリーを、次のディメンションのディメンション階層のソースとして使用します。
部門階層
会社(ビジネス・ユニット)階層
製品カテゴリ階層
HRポジション階層
これらのディメンション階層のデータ・ロード・パラメータを指定することによって、これらのPeopleSoftツリー抽出プロセスを構成します。次のリストでは、各ディメンション階層の関連データ・ロード・パラメータとその使用方法について説明します。
ツリー・ストラクチャID: PeopleSoftツリーは、特定のツリー構造で定義されます。ツリー・ストラクチャは、ツリー・ノードとツリー詳細を格納するための表を指定します。また、ツリーが冬ツリーまたは夏ツリーとして定義されているかどうかも指定します。通常は、Oracle BI Applicationの各ディメンション階層は、1つのツリー・ストラクチャを基盤にしています。ただし、複数のツリー・ストラクチャからツリーを抽出する場合もあります。唯一の制約として、それらのツリー・ストラクチャの詳細が格納される表が同一であることを保証する必要があります。
ツリーとSETID: PeopleSoftアプリケーションは、異なるSETIDでツリーを格納します。ツリー名とSETIDの組合せにより、階層を一意に識別できます。Oracle BI Applicationsは、特定のディメンションに対して複数の階層をサポートできます。ツリー抽出プロセスは、デフォルトでは、特定のツリー・ストラクチャに対して作成されるすべてのツリーを抽出します。ツリーとSETIDの組合せのリストを指定して、抽出するツリーの数を制限することもできます。
このタスクは、JD Edwards EnterpriseOneをソースとするFinancial Analyticsの構成手順です。仕訳ソース・ドメインは、Financial AnalyticsでGL仕訳(買掛/未払金、売掛/未収金など)のソースを識別するために使用します。このタスクは、JDE Edwards EnterpriseOneのバッチ・タイプとFinancial Analyticsの仕訳ソースの間のドメイン・メンバー・マッピングの構成に役立ちます。
ドメイン・メンバー・マッピング
次の表は、仕訳ソース・ドメインのドメイン・メンバー・マッピングを示します。シード済マッピングは、要件を満たすように変更できます。
表B-88 ソース・ドメインGL_JOURNAL_SOURCEからターゲット・ドメインW_GL_JOURNAL_SOURCEへのマッピング
ソース・メンバー | ソース・メンバー・コード | ターゲット・メンバー | ターゲット・メンバー・コード |
---|---|---|---|
A/P Checks (Automatic) |
K |
Account Payables |
AP |
Account Payables |
Payables |
Account Payables |
AP |
Direct Payments |
Q |
Account Payables |
AP |
Manual & Void Checks w/Match |
M |
Account Payables |
AP |
Manual Checks without Match |
W |
Account Payables |
AP |
Voucher Entry |
V |
Account Payables |
AP |
A/R Drafts |
& |
Account Receivables |
AR |
Invoice Entry |
I |
Account Receivables |
AR |
Invoices |
IB |
Account Receivables |
AR |
Account Receivables |
Receivables |
Account Receivables |
AR |
Cash Receipts and Adjustments |
R |
Account Receivables |
AR |
Receipts & Adjustments |
RB |
Account Receivables |
AR |
Revenue |
Revenue |
Account Receivables |
AR |
Asset Revaluation |
AR |
Fixed Assets |
FA |
Asset Transfer |
E |
Fixed Assets |
FA |
Depreciation - Journal Entries |
X |
Fixed Assets |
FA |
Fixed Assets |
Fixed Assets |
Fixed Assets |
FA |
COGS |
COGS |
Inventory |
INV |
Inventory |
N |
Inventory |
INV |
General Accounting |
G |
Inventory |
INV |
注意
次のSQLを使用して、JDEのバッチ・タイプ(ソース・ドメイン・メンバー)のリストを参照します。
SELECT * FROM F0005 WHERE DRSY = '98' AND DRRT = 'IT'
Payables、Receivables、Fixed Assets、COGS、およびRevenueは、内部ソース・メンバー・コードであり、JDEバッチ・タイプに由来するものではありません。これらは、Financial Analyticsの個々の補助元帳ファクトで補助元帳トランザクションにタグを付けるために使用します。
ETL
JOURNAL_SOURCE_IDは、内部ソース・ドメイン・メンバーを使用するためにSDEインタフェースにハードコードされています。
表B-89 インタフェース名からJOURNAL_SOURCE_IDへのマッピング
インタフェース名 | JOURNAL_SOURCE_ID |
---|---|
SDE_JDE_APTransactionFact% |
GL_JOURNAL_SOURCE~Payables |
SDE_JDE_ARTransactionFact% |
GL_JOURNAL_SOURCE~Receivables |
SDE_JDE_GLCogs_Fact |
GL_JOURNAL_SOURCE~COGS |
SDE_JDE_GLRevenue_Fact% |
GL_JOURNAL_SOURCE~Revenue |
オプションまたは必須
オプション。JD Edwards EnterpriseOneでは、デフォルト値を変更する必要があるのは、シード済のソース・ドメインとドメイン・マッピングがビジネス要件を満たさない場合だけです。
目的
ここでは、ODI変数のHR_PSFT_TLNT_PROFILE_TYPES_FILTERとHR_PSFT_TLNT_CONTENT_TYPES_FILTERの構成について説明します。これらの変数は、PeopleSoft HR Talent Managementデータの抽出に使用します。
オプションまたは必須
これは、必須の手順です。この設定手順が実行されていない場合、データはタレント管理ファクト表にロードされません。
適用対象
PeopleSoft 9.0、9.1、および9.2の抽出に適用されます。
詳細なタスクの説明
ETL変数: HR_PSFT_TLNT_CONTENT_TYPES_FILTER
次のSQLを使用して、ETLで使用するタレント内容タイプを特定します。
SELECT DISTINCT JPM_CAT_TYPE FROM PS_JPM_CAT_TYPES;
抽出する関連タイプを選択します。
ETL変数: HR_PSFT_TLNT_PROFILE_TYPES_FILTER
PeopleSoftでは、プロファイルは、個人プロファイルと非個人プロファイルに分類されます。次のSQLを使用して、ETLで使用するプロファイル・タイプを特定します。
SELECT DISTINCT JPM_JP_TYPE FROM PS_JPM_JP_TYPES;
抽出する関連タイプを選択します。
依存関係
なし。
JDEの原価計算と在庫残高の元帳タイプを構成するには:
Oracle BI Applications構成マネージャで、「タスク」パネルの「データ・ロード・パラメータ管理」セクションにある「データ・ロード・パラメータの管理」をクリックします。
「データ・ロード・パラメータの管理」パネルで、「パラメータ」ドロップダウンの値を「コード」に変更し、隣にあるテキスト・ボックスに「CST_LEDGER_TYPE」と入力して「検索」をクリックします。
「データ・ロード・パラメータ」パネルに表示される行の任意の場所をクリックします。
「JDE Costing Ledger Typeに対するグループ固有パラメータ値」パネルで、鉛筆アイコンまたは「パラメータ値」列のハイパーリンクのどちらかをクリックして、「編集ダイアログ」ポップアップ・ウィンドウを開きます。
「パラメータ値」フィールドで値を編集し、「保存してクローズ」をクリックします。
注意: 有効な元帳タイプ値を入力する際は注意が必要です。この自由形式テキストに対する検証は、この時点では行われません。
ページ右上の「完了」ボタンをクリックします。
ウェアハウスの完全な抽出とロードを実行する際、Oracle Business Analytics Warehouseの表の既存のデータは消去され、新しいデータが移入されます。このとき、集計表とスナップショット表に長期にわたって累積された履歴データが失われる可能性があります。このような履歴データは、一度消去されると、簡単に置き換えることはできません。
在庫残高集計表(在庫月次残高と在庫ロット月次残高)のスナップショット・データを保存するために、そのデータを完全ロードの開始時に一時表にコピーして、完全ロードの完了後にコピーしたデータをスナップショット表に復元するマッピングが作成されています。このマッピングは、完全ロードの実行時にのみ実行されます。
さらに、コピーして復元するプロセスを有効化するために、関連パラメータRESTORE_INV_MONTHLY_BALをYに設定する必要があります。完全ロードの実行中に在庫残高スナップショット表のデータのコピーと復元をする必要がない場合は、このパラメータの値をN (またはY以外の任意の値)に設定します。
このタスクは、JD Edwards 9.0.xと9.1.xに適用されます。
販売オーダー・マッピングのDISCOUNT_AMTの計算方法を構成するには:
Oracle BI Applications構成マネージャで、「タスク」ペインの「データ・ロード・パラメータの管理」をクリックし、「データ・ロード・パラメータの管理」ダイアログを表示します。
「検索」ペインを使用して、変数JDE_SALES_PRICE_ADJ_ORDER_LINE_TYPEを検索します。
検索結果のリストで、デプロイしているJD Edwardsのバージョンを表す値を選択します。
JDE_SALES_PRICE_ADJ_ORDER_LINE_TYPEの値を編集し、JDEシステムで「価格調整」に使用する明細タイプのリストを指定します。
このタスクは、JD Edwards 9.0.xと9.1.xに適用されます。
販売オーダー・マッピングのDISCOUNT_AMTの計算方法を構成するには:
Oracle BI Applications構成マネージャで、「タスク」ペインの「データ・ロード・パラメータの管理」をクリックし、「データ・ロード・パラメータの管理」ダイアログを表示します。
「検索」ペインを使用して、変数JDE_SALES_PRICE_ADJ_ORDER_LINE_TYPEを検索します。
検索結果のリストで、デプロイしているJD Edwardsのバージョンを表す値を選択します。
JDE_SALES_PRICE_ADJ_ORDER_LINE_TYPEの値を編集し、JDEシステムで「価格調整」に使用する明細タイプのリストを指定します。
目的
フレックスフィールドは、通常の属性に格納されない必要情報を格納するためのユーザー構成フィールドです。フレックスフィールドには、キー・フレックスフィールド、付加フレックスフィールド、または拡張可能フレックスフィールドがあります。
この項では、Fusion Applicationsのフレックスフィールド属性をOracle Business Analytics Warehouseにマップする方法について説明します。
オプションまたは必須
Oracle Business Analytics Warehouseでフレックスフィールド情報を必要とする場合は、これは必須の構成手順です。
適用対象
Fusion Applicationsソース・システム。
組織情報
組織情報フレックスフィールドは、ソース・データがOracle Business Analytics Warehouseの組織ディメンションに標準では存在しない特殊ケースです。Oracle Business Analytics Warehouseのディメンションには、組織ごとに1行が存在し、現在の情報のみ保持します。一方、組織情報フレックスフィールドには、組織ごとに(複数の情報コンテキストに対応して)複数行が存在し、履歴を保持します。
HR組織情報履歴ディメンションは、そのフレックスフィールドから1つ以上の情報コンテキストをロードするように構成できます。フレックスフィールドのすべての属性は、ディメンションのプレースホルダ列にマップされます。
デフォルトでは、次の3つのディメンション・ロールがインストールされます。
HR組織情報履歴: 組織およびスナップショット日を使用してワークフォース・ファクトに結合され、スナップショット時にフレックスフィールド属性に正しい値を設定します。
HR組織情報履歴(現在): 組織および現在のフラグを使用してワークフォース・ファクトに結合され、ファクトのスナップショット日に関係なく、フレックスフィールド属性に最新の値を設定します。
HR組織情報履歴(前): 前の組織およびスナップショット日を使用してワークフォース・ファクトに結合され、スナップショット時に前の組織のフレックスフィールド属性に正しい値を設定します。
構成手順
Oracle BI構成マネージャでHR Organization Type Listという名前のデータ・ロード・パラメータを使用して、抽出する組織情報コンテキストのカンマ区切りリストを指定します。
「タスク」バーで「データ・ロード・パラメータの管理」をクリックし、「データ・ロード・パラメータの管理」ダイアログを表示します。
「検索」ペインでHR Organization Type Listという名前のデータ・ロード・パラメータを検索します。
検索は、パラメータ名またはパラメータ・コード(HR_ORG_TYPE_LIST)のどちらかで実行できます。
値を編集して、抽出する組織情報コンテキストのカンマ区切りリストを指定します。
フレックスフィールド属性からOracle Business Analytics Warehouse属性へのデフォルト・マッピングがこのディメンションの使用要件を満たさない場合、ODI Studioのデザイナ・ツールでETLマッピングをカスタマイズします。
デフォルト抽出では、フレックスフィールド属性1がOracle Business Analytics Warehouse属性1というように(選択されているすべての情報コンテキストで)マップされます。
Oracle BI EE管理ツールを使用して、Oracle BIプレゼンテーション・カタログで「部門拡張可能属性」フォルダを公開します。
デフォルトでは、ワークフォース凍結スナップショット・サブジェクト領域のリストにありますが、非表示になっています。
Oracle BI EE管理ツールで、「部門拡張可能属性」フォルダのプレゼンテーション列のラベルを、その列にマップされる属性を説明するテキストに変更します。
複数のコンテキストが必要な場合、これをモデリングするオプションとして次の2つがあります。
(デフォルト)複数のコンテキストの一部を含む1つのディメンション・ロール。予想されることとして、このロールを使用するユーザーは1つの情報コンテキストでフィルタをかける必要があり、適用しない場合はメトリックの重複が発生する可能性があります。
それぞれがRPD論理モデルで1つのコンテキストにフィルタされている複数のディメンション・ロール。これは、デフォルトのディメンション・ロール実装をコピーして、必要に応じて論理フィルタを追加することによって実現できます。これにより、メトリックに影響を与えることなく、1つのレポートで複数の情報コンテキストから属性を選択できます。
一般フレックスフィールド(クラウドのFusion)
この情報はまだ使用できません。
一般フレックスフィールド(事業所のFusion)
この情報はまだ使用できません。
依存関係
なし。
この項には、ETLノートと概要ヘルプ・トピックがまとめられています。
このオファリングの機能領域のリストを次に示します。
PROJECT_AN: Revenue
PROJECT_AN: Funding
PROJECT_AN: Forecast
PROJECT_AN: Cross Charge
PROJECT_AN: Cost
PROJECT_AN: Contract
PROJECT_AN: Commitment
PROJECT_AN: Budget
PROJECT_AN: Billing
Procurement and Spend Analyticsには、次のファクト・グループがあります。
従業員経費機能領域
経費クレジット・カード
経費概要
経費違反
ソーシング機能領域
ソーシング・ネゴシエーション
ソーシング応答
調達機能領域
購買オーダー
購買サイクル
購買受入
購買依頼
購買契約
費用請求書配分
調達スコアカード・ターゲット・ファクト・グループ
Procurement and Spend AnalyticsではFinancial Analyticsとのクロス機能分析も行われるので、実装には買掛管理機能領域およびAPトランザクションと残高ファクト・グループも追加する必要があります。
サプライ・チェーンおよびオーダー管理に関連する機能領域とファクト・グループを次に示します。
売掛/未収金
ARトランザクションと残高(ARTRANS_FG)
顧客財務プロファイル・ファクト(FINPROFL_FG)
原価計算
品目原価(ITEMCOST_FG)
評価(VALUATION_FG)
売上原価(GLCOGS_FG)
ロジスティクス
在庫残高(INVBAL_FG)
在庫循環棚卸(INVCYCNT_FG)
在庫トランザクション(INVTRX_FG)
オーダー管理
オーダー予約(OMBACKLOG_FG)
オーダー予約(OMBOOKING_FG)
オーダー顧客ステータス履歴(OMCUSTSTATHIST_FG)
オーダー・サイクル(OMCYCLE_FG)
オーダー出荷(OMDELIVERY_FG)
オーダー・オーケストレーション・プロセス(OMDOOPRCSS_FG)
オーダー請求書クレジット(OMINVOICECREDIT_FG)
オーダー請求書(OMINVOICE_FG)
オーダー・クレジット(OMORDERCREDIT_FG)
オーダー履行(OMORDERFULFILL_FG)
オーダー保留(OMORDERHOLD_FG)
オーダー・スケジューリング(OMSCHEDULE_FG)
収益性
顧客経費(CUSTEXP_FG)
売上原価(GLCOGS_FG)
GL収益(GLREVN_FG)
製品経費(PRODEXP_FG)
サプライ・チェーン
BOM品目ファクト(BOMITEM_FG)
Oracle Sales Analyticsオファリングの機能領域とファクト・グループのリストを次に示します。
オファリング
--> Oracle Sales Analytics (SALES_AN_OFRNG)
機能領域
--> 資産(ASSET_FA)
ファクト・グループ
--> 資産(ASSET_FG)
--> 顧客対応管理(CUSTINTMGMT_FA)
ファクト・グループ
--> 顧客対応カバレッジ(INTCTNCVRG_FG)
--> 顧客対応(INTERACTIONS_FG)
--> マーケティング引合(LEADS_FA)
ファクト・グループ
--> 顧客対応(INTERACTIONS_FG)
--> マーケティング引合(MKTGLEAD_FG)
--> 商談および売上管理(OPTYREVNMGMT_FA)
ファクト・グループ
--> 顧客対応(INTERACTIONS_FG)
--> 商談売上(OPTYREVN_FG)
--> セグメンテーション用商談および売上管理(OPTYREVNMGMTSEG_FA)
ファクト・グループ
--> 商談売上セグメンテーション(OPTYSEG_FG)
--> オーダーCRM (ORDRCRM_FA)
ファクト・グループ
--> CRMオーダー(ORDER_FG)
--> 目標管理(QUOTAMGMT_FA)
ファクト・グループ
--> リソース目標(RESOURCEQUOTA_FG)
--> テリトリ目標(TERRQUOTA_FG)
--> 見積CRM (QTECRM_FA)
ファクト・グループ
--> CRM見積(QUOTE_FG)
--> 販売アカウント(SALESACCNT_FA)
ファクト・グループ
--> 販売アカウント(SALESACCNT_FG)
--> 販売予測管理(SALESFCSTMGMT_FA)
ファクト・グループ
--> 販売予測(SALESFCST_FG)
--> Siebel販売予測(SIEBELSALESFCST_FG)
--> 販売予測エンジン(SPE_FA)
ファクト・グループ
--> 契約品目ファクト(AGREE_FG)
--> 資産(ASSET_FG)
--> キャンペーン履歴(CAMPHIST_FG)
--> マーケティング引合(MKTGLEAD_FG)
--> 商談売上(OPTYREVN_FG)
--> CRMオーダー(ORDER_FG)
--> 応答(RESPONSE_FG)
--> サービス要求(SRVREQ_FG)
--> サービス契約(AGREE_FA)
ファクト・グループ
--> 契約請求書明細ファクト・グループ(AGREEINVCLINE_FG)
--> 契約品目ファクト(AGREE_FG)
--> 請求ファクト・グループ(INVOICE_FG)
--> サービス要求(SRVREQ_FA)
ファクト・グループ
--> 活動ファクト・グループ(ACTIVITY_FG)
--> サービス要求(SRVREQ_FG)
--> 調査(SURVEY_FG)
--> テリトリ管理(TERRMGMT_FA)
ファクト・グループ
--> マーケティング引合(MKTGLEAD_FG)
--> 商談売上(OPTYREVN_FG)
--> 販売アカウント(SALESACCNT_FG)
--> 販売予測(SALESFCST_FG)
--> Usage Accelerator (USGACC_FA)
ファクト・グループ
--> 顧客データの完全度(CUSTDTCMP_FG)
--> 顧客対応(INTERACTIONS_FG)
--> パーティ個人ファクト(PARTYPERSON_FG)
Oracle Partner Analyticsオファリングの機能領域とファクト・グループのリストを次に示します。
オファリング
--> Oracle Marketing Analytics (PARTNER_AN_OFRNG)
機能領域
--> パートナ・ディール(DEALS_FA)
ファクト・グループ
--> マーケティング引合(MKTGLEAD_FG)
--> 商談および売上管理(OPTYREVNMGMT_FA)
ファクト・グループ
--> 顧客対応(INTERACTIONS_FG)
--> 商談売上(OPTYREVN_FG)
--> パートナ・パフォーマンス(PARTPERF_FA)
ファクト・グループ
--> パートナ・プログラム・メジャー・ファクト・グループ(PRMPROGMSR_FG)
--> パートナ・プログラム(PARTPROG_FA)
ファクト・グループ
--> パートナ登録ファクト・グループ(PRMENROLL_FG)
--> パートナ存在ファクト・グループ(PRMPRES_FG)
--> サービス要求(SRVREQ_FA)
ファクト・グループ
--> 活動ファクト・グループ(ACTIVITY_FG)
--> サービス要求(SRVREQ_FG)
--> 調査(SURVEY_FG)
Oracle Human Resources Analyticsオファリングの機能領域とファクト・グループのリストを次に示します。
オファリング
--> Oracle Human Resources Analytics (HR_AN_OFRNG)
機能領域
--> 不就業および有給休暇(ABSACCRUAL_FA)
ファクト・グループ
--> 不就業イベント(ABSEVT_FG)
--> 有給休暇トランザクション(ACCRUALTRANS_FG)
--> 一般会計(GENLDGR_FA)
ファクト・グループ
--> GL予算(BUDGET_FG)
--> GL残高(GLBAL_FG)
--> GL仕訳(GLBAL_FG)
--> 学習(LEARNING_FA)
ファクト・グループ
--> 学習登録(LMENROLL_FG)
--> 給与(PAYROLL_FA)
ファクト・グループ
--> 給与バランス(PAYROLLBAL_FG)
--> 採用(RCRTMNT_FA)
ファクト・グループ
--> 採用(RCRTMNT_FG)
--> 勤怠管理(TIMELABOR_FA)
ファクト・グループ
--> 勤怠管理 - 処理/支払可能時間(TLPRCSD_FG)
--> 勤怠管理 - レポート時間(TLRPTD_FG)
--> ワークフォース配置(WRKFCDEPLOY_FA)
ファクト・グループ
--> ワークフォース・イベント(WRKFRCEVT_FG)
--> ワークフォース有効性(WRKFCEFFECT_FA)
ファクト・グループ
--> GL仕訳(GLBAL_FG)
--> ワークフォース・イベント(WRKFRCEVT_FG)
Oracle Marketing Analyticsオファリングの機能領域とファクト・グループのリストを次に示します。
オファリング
--> Oracle Marketing Analytics (MARKETING_AN_OFRNG)
機能領域
--> コア・マーケティング(COREMKTG_FA)
ファクト・グループ
--> キャンペーン履歴(CAMPHIST_FG)
--> キャンペーン商談(CAMPOPTY_FG)
--> 世帯ファクト(HOUSEHLD_FG)
--> 顧客対応(INTERACTIONS_FG)
--> KPI (KPI_FG)
--> オファー製品(OFFRPROD_FG)
--> パーティ個人ファクト(PARTYPERSON_FG)
--> 応答(RESPONSE_FG)
--> マーケティング引合(LEADS_FA)
ファクト・グループ
--> 顧客対応(INTERACTIONS_FG)
--> マーケティング引合(MKTGLEAD_FG)
--> マーケティング・プラン(MKTGPLAN_FA)
ファクト・グループ
--> マーケティング費用(MKTGCOST_FG)
--> マーケティング目標(MKTGGOAL_FG)
--> 商談ランドスケープ(OPTYLANDSCAPE_FA)
ファクト・グループ
--> 顧客購買(CUSTPURCH_FG)
--> マーケティング引合(MKTGLEAD_FG)
--> 販売アカウント(SALESACCNT_FG)
--> 商談および売上管理(OPTYREVNMGMT_FA)
ファクト・グループ
--> 顧客対応(INTERACTIONS_FG)
--> 商談売上(OPTYREVN_FG)
--> オーダーCRM (ORDRCRM_FA)
ファクト・グループ
--> CRMオーダー(ORDER_FG)
--> 見積CRM (QTECRM_FA)
ファクト・グループ
--> CRM見積(QUOTE_FG)
--> サービス要求(SRVREQ_FA)
ファクト・グループ
--> 活動ファクト・グループ(ACTIVITY_FG)
--> サービス要求(SRVREQ_FG)
--> 調査(SURVEY_FG)
Oracle Financial Analyticsオファリング(FIN_AN_OFRNG)の機能領域とファクト・グループのリストを次に示します。
機能領域:
--> 買掛管理(ACNTPAY_FA)
ファクト・グループ
--> AP保留(APHOLDS_FG)
--> APトランザクションと残高(APTRANS_FG)
--> 売掛管理(ACNTREC_FA)
ファクト・グループ
--> ARトランザクションと残高(ARTRANS_FG)
--> 予算管理(BUDCNTRL_FA)
ファクト・グループ
--> GL予算(BUDGET_FG)
--> GL残高(GLBAL_FG)
--> GL仕訳(GLJRNLS_FG)
--> 従業員経費(EMPEXP_FA)
ファクト・グループ
--> 経費クレジット・カード(EXPCRDTCRD_FG)
--> 経費概要(EXPOVERVIEW_FG)
--> 経費違反(EXPVIOLATION_FG)
--> 連邦財務(FEDFIN_FA)
ファクト・グループ
--> GL予算(BUDGET_FG)
--> GL残高(GLBAL_FG)
--> GL仕訳(GLJRNLS_FG)
--> 固定資産(FIXEDASSET_FA)
ファクト・グループ
--> 固定資産残高(ASTBAL_FG)
--> 固定資産トランザクション(ASTXACT_FG)
--> 一般会計(GENLDGR_FA)
ファクト・グループ
--> GL予算(BUDGET_FG)
--> GL残高(GLBAL_FG)
--> GL仕訳(GLJRNLS_FG)
--> 収益性(PROFIT_FA)
ファクト・グループ
--> 顧客経費(CUSTEXP_FG)
--> 売上原価(GLCOGS_FG)
--> GL収益(GLREVN_FG)
--> 製品経費(PRODEXP_FG)
BI ApplicationsのStudent Information Analytics (SIA)は、学生、インストラクタ、および機関に関する詳細情報を単一環境に取り込みます。こうすることで、機関は、入試、入学、学生レコード、および学生財務状況のデータを分析できます。そこから得られる適切な戦略的判断を活用して、機関の学生入試に対する努力の最大化、保持率の向上、コースやプログラムの成功と不成功の識別、教員ワークロードの分析、および学生財務の管理と追跡を実現します。
Student Information Analyticsは、包括的な統合分析プラットフォームを構成する次の3つのコンテンツ固有のデータ・マートで構成されています。
入学および入試。詳細は、第B.3.14.1項「入学および入試の概要」を参照してください。
学生レコード。詳細は、第B.3.14.2項「学生レコードの概要」を参照してください。
学生財務状況。詳細は、第B.3.14.3項「学生財務状況の概要」を参照してください。
学生入試分析は、機関の候補者と入試担当者について、および機関の候補者から応募者および登録者への転換の成功について、学生の学業経歴、学業プログラム、入学学期、および入試ステータスを中心として情報提供を試みます。
学生入学分析は、機関への応募者および機関での最終記録について、学生の学業経歴、学業プログラム、入学学期、およびプログラム・ステータスを中心として情報提供を試みます。入学および入試に含まれるサブジェクト領域を次に示します。
学生入試: 学生候補者、関連する学業機関、学業経歴、学業プログラム、学業計画、および学業サブ計画に関するデータが含まれます。
学生入学応募: 学生による応募の現在の情報が含まれ、応募者とその応募データに関する情報、関連する学業機関、学業経歴、学業プログラム、学業計画、および学業サブ計画に関する情報を提供します。
学生入学応募ステータス: 応募ステータス変更および有効日に関するデータが含まれます。各ステータス変更は、表の行として表されます。
外部テスト・スコア: 候補者および応募者の外部テスト・スコアに関するデータが含まれます。
外部学業要約: 候補者および応募者の外部学業情報に関するデータが含まれます。
応募評価: 応募者を、応募している学業経歴および学業プログラムの固有の基準に基づいて評価するために使用する、応募評価に関する情報が含まれます。
入学ファネル: 応募者タイプ、学業レベル、学業負荷、最終通学に加えて、学期、機関、経歴、プログラム、キャンパスなどによるファネル・レポート分析を有効化します。
学生応答: 機関に対する学生応答に関する情報が含まれ、学生が機関への入学を断った理由などの分析を可能にします。
履修単位移行: 学生の単位に関する情報が含まれます。学生は、コースの単位、テストの単位、または他の単位を取得できます。
学生レコードは、カタログとクラス・スケジュールの保守、履修単位移行、クラスの開始日と終了日、待機リスト、学業プログラム、成績証明、および分析など、登録のあらゆる側面の管理に役立ちます。学生レコードに関する分析は、機関が登録メトリック、登録コース別の学生数と教員数、受講可能なコース、卒業率、学生経歴、学生の学業水準、および学生と教員のプロファイルなどの項目をレビューおよび管理するために役立ちます。
現在の学生レコードに含まれるサブジェクト領域を次に示します。
学業計画要約: 学業計画要約ビジネス領域には、特定の学業計画および関連する学業プログラムでの個々の学生の要約情報が含まれます。
学業プログラム詳細: 学業プログラム・ビジネス領域には、特定の学業プログラムに対するすべての学生の個々のプログラム処理の詳細が含まれます。
学業クラス: 学業クラス・ビジネス領域には、クラス、提供コース、コース・コンポーネントなどに関する情報が含まれます。
クラス登録: クラス登録ビジネス領域には、特定のクラスの特定の期間の個々の学生の登録に関する詳細が含まれます。
クラス・インストラクタ: クラス・インストラクタ・ビジネス領域には、特定の期間にスケジュールされている個々のクラスに関する詳細が含まれます。
クラス会議パターン: クラス会議パターン・サブジェクト領域には、サブジェクト領域別または部門別の平均クラス・サイズ、会議パターン別の平均クラス・サイズ、時間別および曜日別の教室利用率、クラス利用率、および成績分布などのメトリックが含まれます。
登録要求: このサブジェクト領域は、学生登録要求の分析を提供します。マネージャは、学生別、学業経歴別、機関別、期間別、ステータス別、処理別、理由別などで登録要求に関するメトリックを分析できます。
学位および優秀賞: このサブジェクト領域は、学生学位および関連する優秀賞の分析を提供します。マネージャは、学生別、機関別、学業計画別、学業サブ計画別などで授与される学位と優秀賞に関するメトリックを分析できます。
期間登録: 期間登録ビジネス領域には、特定の期間の個々の学生の登録に関する詳細が含まれます。
機関要約: 機関要約ビジネス領域には、すべての学業プログラム、入学学期、入学タイプ、学生の性別、人種、および学生集団に関する学生数、卒業数、および保持数の詳細が含まれます。
学生財務状況サービスは、機関が学生の売掛/未収金、請求、および回収を管理するために使用します。SIAのサブジェクト領域は、学生財務状況情報を学生、勘定カテゴリなどのディメンションにリンクして、様々な観点から学生財務状況情報を分析できるようにします。
学生財務状況分析は、機関が学生財務状況トランザクションのレビューと管理および未処理のモニターを行う際に役立ちます。機関はそれによって学生財務状況トランザクション・レベルの詳細を取得できます。
現在の学生財務状況モジュールに含まれるサブジェクト領域を次に示します。
支払詳細: 詳細レベルの支払情報。マネージャは、ビジネス・ユニット別、支払方法別、項目タイプ別、期間別、学年度別などで支払を分析できます。
支払と請求の相互参照: 学生財務状況内で請求に適用される支払に関する情報を提供します。マネージャは、ビジネス・ユニット別、項目タイプ別、勘定タイプ別、期間別、学年度別などで請求に適用される支払を分析できます。
トランザクション詳細: 詳細レベルの学生財務状況トランザクション情報。マネージャは、ビジネス・ユニット別、項目タイプ別、勘定タイプ別、期間別、学年度別などで明細項目を分析できます。
クレジット履歴: 年齢調べ設定別および年齢調べカテゴリ別の学生および外部組織のアカウントに関する情報。学生財務状況マネージャは、特定のビジネス・ユニット、勘定タイプ、学生、外部組織のクレジット履歴トレンドを分析できます。
Oracle Human Resources Analyticsは、様々なHR機能および財務からのワークフォース情報を統合します。エグゼクティブ、HRマネージャ、および現場マネージャは、提供される対話型ツールを使用して、ワークフォース要員配置、従業員パフォーマンス、および給与原価の分析、パフォーマンスに対する報酬の設計向上、従業員の保持および不就業のコストの削減、および高品質な応募者の調達向上を実行できます。
Oracle HR Analyticsアプリケーションに含まれる機能領域を次に示します。
ワークフォース有効性
ワークフォース有効性は、主なHRメトリックを組織の財務データと組み合せます。これにより、上級エグゼクティブは、主なHR有効性メトリックを企業レベルでモニターできます。ワークフォース・メトリックと財務メトリックの相関により、ワークフォース・トレンドが組織運営と財務健全性に及ぼす直接的な影響について的確に把握できます。
ワークフォース有効性には、次のサンプル・メトリックが用意されています。
契約費用
ヘッドカウント当たりの貢献度
人的資本収益率
ヘッドカウント当たりの収益
ワークフォース費用
ワークフォース配置
ワークフォース配置サブジェクト領域は、ワークフォース分析の基盤です。包括的なコア・ワークフォース情報を提供して、ヘッドカウント、保持、ワークフォース多様性、従業員パフォーマンス、および派遣労務稼働率の分析をサポートします。従業員、組織、監督者、パフォーマンス・バンド、およびサービス・バンドなどの主なワークフォース配置情報は、他のHR機能領域と共有します。生年月日、年齢、および婚姻区分などの機密性のある個人属性は、制限付きアクセスを適用できるように別フォルダで整理されます。
構成可能なHRイベント分析は、ワークフォース配置サブジェクト領域のもう1つの重要な機能です。ユーザーは、様々な従業員アサイメント処理を構成して、自己都合/会社都合退職、採用、異動、昇格・昇進、または解雇などの分析をサポートできます。さらに、従業員のジョブ、組織、事業所、監督者、および給与の変更が追跡されており、ワークフォース移動分析をサポートします。
ワークフォース配置は、次に示すタイプの分析をサポートします。
ヘッドカウント分析
ワークフォース多様性
従業員の減少および保持
従業員パフォーマンス
担当期間
内部モビリティ
ワークフォース増減
ヘッドカウント予算とタレント移動を管理するには、ヘッドカウント移動について理解することが必要不可欠です。転属により、レポート階層をトラバースする際に、ヘッドカウントが増加または減少するか、または変化しない可能性があります。ヘッドカウント増減サブジェクト領域では、採用、転入、転出、組織変更、退職などのアサイメント変更が、監督者階層によるヘッドカウント移動に及ぼす影響を分析できます。
ワークフォース増減には、次のメトリックが用意されています。
採用、再編成、グローバル異動、異動、監督者変更によるヘッドカウント増加
異動、再編成、グローバル異動、監督者変更、退職によるヘッドカウント減少
報酬
報酬サブジェクト領域は、報酬マネージャとライン・マネージャが報酬経費を管理し、報酬計画の有効性を評価するために必要な情報を提供します。提供されている報酬メトリックを使用して、従業員の給与とパフォーマンスを関連付けて、ジョブ別、等級別、および在職期間別に様々なレベルの報酬パリティ分析を実行できます。これにより、過大または過小な報酬を受け取っている従業員をプロアクティブに検出します。これは、会社の競争力を維持する能力に大きな影響を与える可能性があります。
報酬サブジェクト領域では、次の分析がサポートされています。
給与トレンドおよびパーセンタイル(百分位数)分析
等級、ジョブ、および熟練した作業員の間の給与減額
給与と従業員パフォーマンス
支給率区分分析
不就業と有給休暇
不就業と有給休暇は、従業員の不就業トレンドと有給休暇バランスを分析します。不就業は、ワークフォースの生産性の低下とワークフォース費用の上昇を招きます。ここで計画済と予定外の不就業トレンドおよび従業員の労働損失日数を分析し、予定外不就業の頻度が高い従業員を特定して不就業費用を削減します。また、マネージャが従業員の有給休暇バランスと有給休暇債務を表示することもできます。
不就業と有給休暇では、次の分析タイプがサポートされています。
労働損失日数と不就業トレンド
従業員不就業カレンダ
Bradfordスコア
組織別の有給休暇のバランスと債務
給与
給与サブジェクト領域は、トランザクション給与詳細および集計された給与バランスを収集します。給与サブジェクト領域を使用すると、給与から、支給項目、控除、税、および特別なアキュムレータのすべてのバランスを分析できます。これにより、ソース給与バランスから基本給与、変動給与、事業主支払の合計医療保険費用、および事業主支払の合計税額などの要約メジャーを構成して、合計報酬またはワークフォース費用を簡単に分析できます。給与サブジェクト領域は拡張可能です。拡張フィールドが用意されているので、ユーザーは、事前定義済給与バランスに含まれていないバランス・メジャーを追加でマップできます。
すべての給与メジャーは、年、四半期、月、前年などの時間トレンド分析で使用できます。
給与サブジェクト領域では、次の分析タイプがサポートされています。
給与バランス
給与支給項目バランスおよび給与控除項目バランス(YTD、QTD、MTD、YAGO)
給与原価トレンド
超過勤務手当と給与労務時間
採用
採用機能領域は、質の高い新規採用を募集して引き寄せるための採用プロセスの効率と有効性を評価するインテリジェント機能をエグゼクティブ、採用マネージャ、およびライン・マネージャに提供します。ここでは、採用ライフ・サイクル全体をモニターするための100個以上のメトリックが用意されています。
採用サブジェクト領域では、次の採用分析タイプがサポートされています。
ジョブ必要要員分析
採用イベント分析
採用の質
採用募集元
応募者プール分析
推薦元分析
学習
学習はタレント管理の主要コンポーネントです。学習機能領域は、コース提供、提供方法、コース利用状況、および学習者の登録と完了の分析に重点を置きます。学習機能領域は、学習メトリックとワークフォース・メトリックを組み合せることで、学習提供の有効性について、およびワークフォース開発と従業員パフォーマンスに対する学習の貢献度について、重要な洞察を提供します。
学習サブジェクト領域では、次の分析タイプがサポートされています。
従業員のコース登録率とコース完了率
提供学習時間
コース登録の上位10件
コース登録待機時間
学習スコア
勤怠管理
勤怠管理サブジェクト領域は、遅延タイムカード発行、報告時間、処理時間、または給与対象時間を分析します。勤怠管理では、ソースとなる時間追跡システムから取得したタイムカード・トランザクションの詳細を保存します。構成可能な時間入力カテゴリを使用して、生産性時間と非生産性時間の比較、超過勤務トレンド、報告時間の見積原価、報告時間と処理時間の差異を分析できます。また、プロジェクト別、タスク別に報告時間と処理時間を分析することによって、プロジェクト時間報告もサポートします。
勤怠管理サブジェクト領域では、次の分析タイプがサポートされています。
時間カテゴリ別と発行ステータス別の報告時間
生産性時間と非生産性時間の比較
遅延タイムカードとタイムカード経過時間
処理ステータス別の処理時間または給与対象時間
報告時間と処理時間の見積原価
プロジェクト労務時間
Oracle Price Analyticsは、価格設定分析、営業業務、製品のマーケティングと管理、および財務を対象としています。契約、見積、オーダー、競合他社の価格についての完全な価格ウォーターフォールを通した価格設定分析を提供することで、ビジネス・ユーザーは次の事項を実行できます。
正当な実現価格の特定と、該当する要約レベルおよびトランザクション・レベルで価格が希薄化される程度の把握。
セグメント、戦略、チャネル、地域および時間を通した価格および割引のトレンドの監視。
価格範囲分析を通じた同一製品内または同一顧客の範囲内での価格とマージンの変動量の把握。
顧客や製品の収益性についての異常値の検出。これにより、あるグループが別のグループよりも優れた実績を上げている根本原因を判断し、きわめて的確な価格設定ポリシーと理想的な商談を特定します。
履歴データから得られた洞察と、Oracleのデータ・マイニングおよび予測テクノロジを組み合せることによる、将来的な意思決定の向上。
トランザクション・レベルでの価格要素の分割と、詳細なウォーターフォール分析を通じた正当な実現価格とマージンの特定。
数量に対して不均衡な割引の強調表示と、どの地域、製品または顧客が原因であるかの判断。
価格設定データを移入できるソースは次のとおりです。
Siebel CRM 8.1.1.7および8.2.2
E-Business Suite 12.1.3
Universalソース
競争が激化する今日の市場において、会社の顧客サービス・センターが競争優位性を生み出す有力な要因になる可能性があります。実際、高い実績を誇るサービス・センターを擁する会社では、一般に、満足度の高い顧客の増加、営業費の減少、および顧客当たりの収益の増加が見られます。しかし、このような結果を達成するには、組織は主なサービス・センター・メトリック(サービス要求経過時間、サービス要求解決、従業員当たりサービス活動など)を厳格に追跡および分析して、パフォーマンス・レベルを維持するための適切な行動をとる必要があります。Oracle Service Analyticsは、サービス・センターのあらゆる側面のパフォーマンス分析を可能にする強力な洞察を組織に提供します。このソリューションは、ベスト・プラクティスのメトリック、アラート、キー・パフォーマンス・インジケータ(KPI)を提供しており、従業員の生産性の向上、費用の削減、顧客満足度の向上に絞った行動をとることができます。
Oracle Manufacturing Analyticsは、Oracle Business Intelligence Applications製品ラインの一部で、製造実行、生産原価計算、在庫管理、および生産品質に関する深い洞察を提供します。製造エグゼクティブ、原価会計士、生産マネージャ、および運用マネージャが、製造実行のパフォーマンス・インジケータと主なトレンドを追跡するのを支援します。Manufacturing Analyticsを、その他のOracle Business Intelligence Applications分析オファリングと緊密に統合することで、サプライ・チェーンの実行と有効性を監視および評価する際に、組織は十分な情報に基づいた意思決定を下せるようになります。
Oracle Manufacturing Analyticsでは、次のコンテンツ領域の分析サポートが提供されています。
製造実行
製造実行は、生産作業現場の作業オーダー・トランザクションを収集して、要約レベルのパフォーマンス・インジケータと詳細な作業オーダー詳細へのドリルダウンを提供します。分析サポートには、次のものが含まれます。
在庫予定の生産完了。
作業オーダー分析。生産スケジュール順守、生産品質、作業オーダー・サイクル時間、作業オーダー年齢調べなどが含まれます。
生産への資材払出および使用量差異分析。
標準に対するリソース使用量差異および標準操業度でのリソース利用率。
リーン製造におけるカンバン・カード活動とカンバン補充分析
生産原価計算
このコンテンツ領域は、生産原価と原価差異に関する洞察を生産原価会計士に提供します。生産原価計算は、原価要素をリソース別、資材別、間接費別に分割して、作業オーダー完了の実際の生産原価を収集します。実際の原価トレンドと例外の追跡に加えて、このコンテンツ領域は、標準原価計算を実施する組織が、特定の品目の事前定義済標準原価に対する原価要素別の生産原価差異を追跡できるように支援します。この差異分析は、GL差異勘定科目別に要約レベルで実行でき、作業オーダーおよび原価要素の詳細までドリルダウンして例外を追跡できます。
生産品質
このコンテンツ領域は、品質テスト情報を収集します。このコンテンツ領域には豊富な属性があり、特定の品質計画の品質テスト結果および関連するすべての回収要素を収集します。これらのテスト結果を事前定義済のしきい値と比較して分析することによって、例外を不適合および処分の詳細とともに特定できます。
廃棄、再作業、初回合格歩留などの実際の作業オーダー品質を、品質計画とテスト結果に結び付けることができ、生産品質パフォーマンスを監視および追跡する高度な機能を提供します。
生産-計画
このコンテンツ領域には、ASCPやMPSをソースとする様々な生産計画を分析する機能および特定の計画をベースライン計画として事前構成する機能があります。このベースライン計画を実際の生産完了と比較することによって、生産の計画に対する準拠、生産達成累計、ベースライン計画からの偏差などの理解を深めることができます。また、特定の計画をベースライン計画と比較することによって、ベースライン計画を基準とした特定の計画の推奨事項の逸脱をレビューできます。
在庫
作業現場の生産実績に加えて、在庫詳細を分析する分析サポートがあります。これにより、生産工場および全在庫組織を通した利用可能な供給合計の全体像を提供します。在庫に関する分析サポートには、次のものが含まれます。
在庫残高: このコンテンツ領域は、製品別、ロット別(ロット管理が有効な場合)の在庫残高の日次と月次のスナップショットを収集します。これにより、様々な在庫組織にわたって在庫残高のトレンドを分析できます。また、「在庫回転率」や「在庫未処理日数」などの業界標準メトリックの集計をサポートします。これらは、組織全体のサプライ・パフォーマンスを追跡するKPIをサプライ・チェーンのエグゼクティブに提供する計算済メトリックです。
在庫トランザクション: このコンテンツ領域は、組織間転送、顧客とサプライヤからの返品、資材払出と作業現場からの返品、在庫予定の作業オーダー完了などを含むすべての在庫トランザクションを収集します。これにより、トランザクション・タイプ別にトレンドを分析して、組織内の在庫移動パターンの理解を深めることができます。
在庫部品構成表: このコンテンツ領域は、特定の製品のフラット化された部品表をレビューして、部品表で全レベルにわたってまとめて使用される、およびその各ステージで個別に使用される、すべてのコンポーネントと原材料について理解を深めるのに役立ちます。この情報は、有効日に基づいており、特定の生産作業オーダーに関連付けられているすべてのコンポーネント/資材、およびこれらのコンポーネント/資材の関連在庫レベルを引き出すために有用です。
在庫年齢調べ: このコンテンツ領域には、在庫への受入日に基づいて在庫年齢を追跡し、年齢調べバケットに在庫を分類する機能があります。また、貯蔵寿命やロット失効日に基づいて、失効在庫を複数のバケットに分類して監視し、迅速に処理するのに役立ちます。
Fusion ApplicationsのOracle Supply Chain and Order Management Analyticsアプリケーションでは、次のものを分析できます。
記帳
財務バックログと出荷待ちバックログ
請求書
営業サイクルの各ステージを通過する販売オーダーの移動
オーケストレーション・オーダー分析
オーダー保留分析
組織が保有する在庫
製造工場、配送センター、ストレージ保管場所の内外での在庫移動またはそれらを通過する在庫移動
在庫評価
ヒット/ミス分析および完全一致分析による在庫循環棚卸
品目、品目バッチ、および品目カタログの各属性の分析を含む製品情報管理
Fusionの新規品目要求プロセスと変更オーダー・プロセスをサポートする製品情報分析
Oracle Supply Chain and Order Management Analyticsアプリケーションは、オーダー、請求書、オーダー・オーケストレーション、バックログ、在庫、ロジスティクス、および製品情報管理で構成されています。販売オーダーは、販売プロセスの入口ポイントです。請求書は、履行プロセスからの出口ポイントです。バックログは、履行プロセスで輻輳が発生するポイントです。この対象には、オーケストレーション・オーダーと処理期間、および記帳済、バックログ済、請求済の品目に対する洞察が含まれます。これにより、個々の営業担当または営業部門の販売実績を評価できます。Oracle Supply Chain and Order Management Analyticsアプリケーションは、在庫トランザクション、在庫残高、および顧客とサプライヤからの返品に関する情報も提供します。これにより、企業は、在庫レベルで販売実績のトレンドを監視して費用効果を高めたり、在庫レベルを減らして迅速化することで在庫回転率を向上させたり、在庫を適所/適時で配置することができます。また、品質を管理するために、顧客やサプライヤからの返品状況をより詳しく把握できます。
前述のコンテンツ以外に、Oracle Supply Chain and Order Management Analyticsには、原価計算、分散オーダー・オーケストレーション、ロジスティクス、および製品情報管理の新しいサブジェクト領域を含む、Fusion Applicationsソースの新しいコンテンツがあります。
Oracle Marketing Analyticsは、組織全体のマーケティング活動について、タイムリなファクトベースの洞察を得られる包括的な分析ソリューションです。情報の豊富さや有用性は、これまでにないレベルにまで引き上げられ、企業全体のマーケティング担当者に行き渡ります。これにより、マーケティング効果、顧客洞察、引合分析の各マーケティング領域におけるアクショナブル・インテリジェンスが提供されます。
Marketing Analyticsの主な機能領域は次のとおりです。
コア・マーケティング: キャンペーン、マーケティング活動、マーケティング・オファーに対する顧客および見込み客の反応を分析できます。
マーケティング引合: ライフ・サイクルを移動する引合の状況や、顧客および見込み客の引合に対する会社の対応を詳細に分析できます。この分析には、引合から商談への変換、営業チームが引合を却下しリタイアした率、その主な理由、営業員がどの程度効果的に引合を変換しているかなどの詳細が含まれます。
マーケティング・プランニング: マーケティング目標およびマーケティング費用分析を含む、マーケティング・プランニングの関連情報を分析できます。
商談売上管理: マーケティング活動からの商談売上を分析できます。マーケティング担当者は、マーケティング投資収益率(ROMI)を計算できます。
オーダーCRM: マーケティング活動からのオーダー売上を分析できます。マーケティング担当者は、マーケティング投資収益率を計算できます。
見積CRM: マーケティング活動からの見積売上を分析できます。マーケティング担当者は、マーケティング投資収益率を計算できます。
サービス要求: 顧客および見込み客を対象とした、会社の様々なマーケティング活動を分析できます。
マーケティング・キャンペーンや他の活動に対するエンド・ツー・エンドの完全な分析を行うには、これらすべての機能領域を実装する必要があります。
商談ランドスケープ: 商談ランドスケープは、Marketing Analytics内に含まれる機能領域ですが、Marketing Analyticsの動作に必要ではありません。このモジュールは、Fusion商談ランドスケープ・アプリケーションに分析機能を提供します。詳細は、Fusion商談ランドスケープの製品ドキュメントを参照してください。
Fusion Customer Data Management Analyticsは、組織の顧客データのデータ品質に関する洞察を提供します。このソリューションは、自社の基盤となるパーティ情報(組織や個人の情報を含む)の完全度を監視、測定、分析するために使用できる一連のデータ完全度分析機能を提供します。
この項では、Project Resource Management Analyticsの概要について説明します。
PeopleSoftまたはE-Business SuiteでProject Resource Management Analyticsを使用する場合の一般情報については、第B.3.22.1項「PeopleSoftとE-Business SuiteにおけるProject Resource Management Analyticsについて」を参照してください。
PeopleSoftでのProject Resource Management Analyticsの使用については、第B.3.22.2項「Project Resource Management Analytics for PeopleSoftの注意事項」を参照してください。
注意: E-Business SuiteでのProject Resource Management Analyticsの使用については、第B.3.23項「Project Resource Management Analytics for E-Business Suiteの概要」を参照してください。
この項では、PeopleSoftとE-Business Suiteで使用するProject Resource Management Analyticsの該当情報について説明します。
概要
Oracle Business Intelligence Applicationsリリース11.1.1.7.1では、Project Analyticsに、プロジェクト・リソース管理を分析するための新しいサブジェクト領域が導入されています。
このリリースでは、E-Business Suite 11.5.10とR12x、およびPeopleSoft 9xがサポートされています。
新しいサブジェクト領域には、230個以上のメトリックが用意されており、カタログには5つの新しいダッシュボード・ページと40個以上の新しいレポートが追加されています。詳細は、Oracle BI Applicationsメトリック・ガイドを参照してください。
このサブジェクト領域でサポートされている、Oracle Business Analytics Warehouseの新しいファクト表が導入された分析領域は次のとおりです。
プロジェクト要件
表W_PROJ_RSRC_RQRMNT_Fには、プロジェクト要件の詳細が格納されます(プロジェクト要件によって要求されている、未履行のリソースの時間と数を示すメトリックを含む)。このファクト表には、要件の日付範囲の単位で要件が格納されます。ERPでは、一定の日付範囲にある要件が収集されますが、要件と生産能力を日単位で比較できるように、要件の時間がBIメタデータ・リポジトリ(RPDファイル)でその日付範囲内で線形に配分されます。
リソース稼働率
表W_PROJ_RSRC_UTILIZATION_Fには、各割当日のリソース割当および各リソースの有効営業日のリソース生産能力の詳細が格納されます。このファクトには、生産能力、スケジュール済時間、使用可能時間、および未割当時間などのメトリックが含まれます。実績利用率は、プロジェクト原価ファクトを通じてもサポートされます。
コンピテンシとジョブ
表W_EMP_JOB_Fには、従業員の主要職務の詳細が格納されます。表W_EMP_COMPETENCY_Fには、従業員のコンピテンシの詳細が格納されます。このRPDには、これらの2つのファクトを使用してジョブとコンピテンシの供給と需要を比較できるようにする新しい論理表ソースが導入されています。このファクトには、「従業員数」、「従業員数MAGO」などのメトリックが含まれます。
リソース可用性
このスターには、事前設定されている連続日数の営業日に使用可能なリソースを検索する機能があります。ウェアハウスにこのファクトの物理表は存在しません。これは、BIメタデータ・リポジトリ(RPDファイル)の不透明なビューです。
この不透明なビューは、従業員の休日情報と従業員のアサイメント情報を使用して勤務可能性を計算する選択問合せです。このファクトには、「バケット1の使用可能リソース数」などのメトリックが含まれます。
この新しいサブジェクト領域は、実装時に次のパラメータを設定する必要があります。これらは、EBSアダプタとPSFTアダプタの両方で使用するFSMパラメータです。これらのパラメータは、FSMで構成する必要があります。
プロジェクト・リソース管理生産能力レコード作成期間: このパラメータを使用して、生産能力レコードを作成する期間(月単位)を指定します。このパラメータのデフォルト値は12です。
プロジェクト生産能力バケット・サイズ: このパラメータを使用して、リソースを検索する際に使用する、使用可能な営業日の連続日数を指定します。このパラメータのデフォルト値は5です。
プロジェクト・リソース管理単位: RPD変数PROJ_RSRC_MNGMT_UOMは、レポート・ユニットを指定します。HOURS、DAYS、またはFTEを設定できます。このパラメータのデフォルト値はHOURSです。
プロジェクト・リソース管理単位(日)値: 単位(日)値を表す時間数。営業日の時間数を指定します。このパラメータのデフォルト値は8です。
プロジェクト・リソース管理単位(FTE)値: 単位(FTE)値、すなわち常勤換算の1週間を表す時間数。このパラメータのデフォルト値は40です。
プロジェクト・リソース管理単位(時間)値: 単位(時間)値。デフォルトでは、すべてのメトリックは時間単位で表示されます。このパラメータのデフォルト値は1です。
この項では、Project Resource Management Analytics for PeopleSoftに固有の情報について説明します。
リソース管理ソース・アプリケーションで定義されているタスク・タイプを作業タイプ・ディメンションにマップする必要があります。タスク・タイプが請求可能、資産計上可能、または研修用のどれであるかを指定するためのFSMの構成ポイントが用意されています。また、利用率を計算する際にタイプごとの時間に対して割り当てる加重も指定します。
支出タイプ、支出区分、GL会計日、GL会計日会計カレンダ、プロジェクト・カレンダ・ディメンションは、このアダプタではサポートされていません。
PeopleSoft要員管理では、要員の配置可能数は格納されません。ETLで、作業日のみの配置可能数を計算します。
これらの計算では、プロジェクトへの配置対象として適格な従業員のみが考慮されます。
この項では、E-Business Suiteで使用するProject Resource Management Analyticsに固有の情報について説明します。
PeopleSoftまたはE-Business SuiteでProject Resource Management Analyticsを使用する場合の一般情報については、第B.3.22.1項「PeopleSoftとE-Business SuiteにおけるProject Resource Management Analyticsについて」を参照してください。
E-Business Suiteアダプタの注意事項
E-Business Suite資源管理では、プロジェクトに資源が割り当てられていない場合を除いて、資源許容量を作成します。すべての従業員のレポートが同型になることを保証するために、ETLプロセスの実行中に未割当従業員の許容量レコードが作成され、Oracle Business Analytics Warehouseにロードされます。許容量レコードを作成する期間は、FSMパラメータのProject Resource Management Capacity Records Creation Periodで制御します。
Oracle Project Analyticsは、プロジェクト管理の様々な基本領域について、広範な洞察を得ることができる包括的ソリューションを提供します。Project Analyticsを使用することにより、プロジェクト・エグゼクティブ、プロジェクト・マネージャ、プロジェクト会計士は、ライフ・サイクルを通じてプロジェクトのステータスを追跡して、パフォーマンスと収益性を向上させることができます。Oracle Project Analyticsは、FinancialsやProcurement AnalyticsなどのOracle BI Applicationsにも統合されています。これらの統合により、ARトランザクション、APトランザクション、調達トランザクションのプロジェクト別のクロス機能分析が実現します。
Project Analyticsに含まれるサブジェクト領域は次のとおりです。
プロジェクト - プロジェクト請求
このサブジェクト領域には、請求に関するレポート機能があります。これには、外部請求、プロジェクト間請求、会社間請求におけるプロジェクト、タスク、組織、リソース、関連階層間の金額と数量のレポート機能が含まれます。このサブジェクト領域には、契約メトリックも含まれます。
プロジェクト - 予算
このサブジェクト領域には、原価、収益、マージン予算、予算変更に関するレポート機能があります。これには、予算明細レベルでプロジェクト、タスク、組織、リソース、期間、関連階層間の当初予算と現行予算を追跡するレポート機能が含まれます。
プロジェクト - 費用
このサブジェクト領域には、過去期間と現行期間の原価(総原価)、直接費、および間接費に関するレポート機能があります。これには、プロジェクト、タスク、組織、リソース、サプライヤ、関連階層間の開始来累計と年累計を比較するレポート機能が含まれます。また、原価配分レベルで原価を追跡する機能を提供します。
プロジェクト - 予測
このサブジェクト領域には、原価、収益、マージン予測、予測変更をレポートする機能があります。これには、プロジェクト、タスク、組織、リソース、期間、関連階層間の当初予測と現行予測を追跡するレポート機能が含まれます。また、原価、収益、マージンの過去、現在、および将来のパフォーマンスを示すメトリックの追跡機能を提供します。
プロジェクト - 資金
このサブジェクト領域には、契約額、資金額、およびプロジェクトのライフ・サイクルを通じた資金のその他の変更を追跡する機能があります。また、プロジェクト、タスク、顧客、組織、関連階層間の契約額、資金額、請求額を比較分析する機能を提供します。
プロジェクト - パフォーマンス
これは、予算、予測、原価、収益からの情報を組み合せた連結サブジェクト領域です。実績(原価、収益、マージン、およびマージン率(%))と予算の比較、およびプロジェクト、タスク、組織、リソース、関連階層間の予測の比較によって、パフォーマンスを監視する機能があります。
プロジェクト - 収益
このサブジェクト領域には、過去期間と現行期間の収益トランザクションに関するレポート機能があります。これには、プロジェクト、タスク、組織、リソース、サプライヤ、関連階層間の開始来累計と年累計を比較するレポート機能が含まれます。また、配分レベルで収益を追跡する機能を提供します。
プロジェクト - 取引約定
このサブジェクト領域には、プロジェクトの将来の支出の債務に関するレポート機能があります。組織、プロジェクト、タスク、リソース、期間を対象にレポート可能です。購買依頼、購買オーダー、サプライヤ請求書の直接金額および間接金額を示すメトリックがあります。
プロジェクト – 相互賦課
このサブジェクト領域には、プロジェクトまたは組織が共有するリソースに対して相互賦課する支出に関するレポート機能があります。期間、組織、プロジェクト、タスク、リソースを対象にレポート可能です。メトリックには、会社間請求によって生成される賦課または現在と過去の期間の借入と貸出の方法が含まれます。
プロジェクト – リソース管理
このサブジェクト領域には、リソース利用、プロジェクト要件のステータスと属性、およびコンピテンシとジョブの供給と需要に関するレポート機能があります。グレゴリオ暦期間、リソース組織、リソース、要件、プロジェクトを対象にレポート可能です。
プロジェクト – 原価GL調整
このサブジェクト領域には、プロジェクトと一般会計の間の調整例外の数、およびそれらの金額を追跡するメトリックとディメンションがあります。プロジェクトの原価配分明細の転送から対応する仕訳明細の一般会計への転記までをカバーする、6つのユース・ケースをサポートしています。ユース・ケースは、集計している原価配分明細と一致しない仕訳明細、および一致する原価配分明細が存在しない仕訳明細による例外もカバーしています。
プロジェクト – 収益GL調整
このサブジェクト領域には、プロジェクトと一般会計の間の調整例外の数、およびそれらの金額を追跡するメトリックとディメンションがあります。プロジェクトの収益配分明細の転送から対応する仕訳明細の一般会計への転記までをカバーする、6つのユース・ケースをサポートしています。ユース・ケースは、集計している収益配分明細と一致しない仕訳明細、および一致する収益配分明細が存在しない仕訳明細による例外もカバーしています。
クロス・ファクト分析
標準BU (標準組織)は、複数のファクト表にわたってデータを分析する共通論理BU (組織)です。各ファクト表からそのデータの分析に使用するメインBU (Org)を1つ選択し(たとえば、原価ファクトの場合の標準BUは支出BU、収益ファクト表の場合の標準BUは担当者BU)、対応する外部キーを使用して論理ディメンションDim - Business Unit (Dim - Project Organization)と結合します。Dim - Business UnitとDim - Project Organizationの2つのディメンションはそれぞれ、標準BUディメンションと標準プロジェクト組織ディメンションと呼ばれます。たとえば、原価ファクトの場合、結合は次のようになります。
Dim_W_INT_ORG_D_Business_Unit.SCD1_WID = Fact_W_PROJ_COST_LINE_F_Project_Cost.EXPENDITURE_OPER_UNIT_WID
収益ファクトの場合、結合は次のようになります。
Dim_W_INT_ORG_D_Business_Unit.SCD1_WID =Fact_W_PROJ_REVENUE_LINE_F_Revenue_Lines.CONTRACT_BU_WID
また、標準BUカレンダは、会計カレンダ日ディメンション(W_MCAL_DAY_D)の外部キーを形成する際に使用します。クロス・ファクト分析の場合、標準BU (プレゼンテーション領域の「組織」フォルダの「ビジネス・ユニット名」列)にフィルタを適用していることを常に確認する必要があります。標準BUに対するこのフィルタは、カレンダが一意であり、二重にカウントされないことを保証するので、すべてのダッシュボードで必要です。
次の表に、Project Analyticsソリューションでサポートされている論理ファクトで使用可能な標準BU (標準組織)を示します。
表B-90 ファクト、標準BU、および標準組織のリスト
ファクト | 標準ビジネス・ユニット | 標準組織 |
---|---|---|
プロジェクト請求 |
契約BU |
契約組織 |
プロジェクト予算 |
プロジェクトBU |
プロジェクト組織 |
プロジェクト予算 - リニア・スプレッド |
プロジェクトBU |
プロジェクト組織 |
プロジェクト取引約定 |
プロジェクトBU |
プロジェクト組織 |
プロジェクト取引約定スナップショット |
プロジェクトBU |
プロジェクト組織 |
プロジェクト契約 |
契約BU |
契約組織 |
プロジェクト原価 |
支出BU |
支出組織 |
プロジェクト相互賦課 - 請求書 |
プロジェクトBU |
プロジェクト組織 |
プロジェクト相互賦課 - 送り側 |
支出BU |
支出組織 |
プロジェクト相互賦課 - 受け側 |
プロジェクトBU |
契約組織 |
プロジェクト相互賦課 - 収益 |
契約BU |
契約組織 |
プロジェクト予測 |
プロジェクトBU |
プロジェクト組織 |
プロジェクト資金 |
契約BU |
契約組織 |
プロジェクト収益 |
契約BU |
契約組織 |
「予算管理」ダッシュボードは、総予算を管理するエグゼクティブ、およびコスト・センター別、資金別、プログラム別、プロジェクト別、勘定科目別に予算を管理する上級レベル・マネージャを対象としています。経費予算(予算額、予算引当、支出など)および収益予算(予算額、認識済収益など)に関する主な分析を提供するように設計されています。
予算管理分析を使用するには、いくつかの事前要件を満たす必要があります。
予算管理分析のダッシュボードでは、Procurement and Spend Analyticsのサブジェクト領域に分類されている、購買オーダー、購買依頼などに関する要約レポートから詳細レポートにドリルダウンできます。したがって、これらのドリルダウンを使用できるようにするために、Financial Analyticsオファリングに加えて、Procurement and Spend Analyticsオファリングもライセンスを取得して実装する必要があります。
PeopleSoftの利用者は、商業部門または公共部門のどちらでも、Budgetary Control Analyticsを使用するために、PeopleSoft Applicationsにコミットメント・コントロール・モジュールを実装する必要があります。
Projects AnalyticsのGL調整の概要は、第B.2.91項「Project AnalyticsにおけるGL調整の追加情報」を参照してください。
E-Business Suite11.5.10にはリンケージ(SLA)表の概念が存在しないので、ユース・ケースはR12のものとは多少異なります。E-Business Suite11.5.10ソース・システムでサポートされているユース・ケースを次に示します。
表B-91 ユース・ケースと説明
ユース・ケース | 説明 |
---|---|
転送されない原価/収益明細 |
転送ステータスが未転送である原価/収益明細トランザクション |
転送例外のある原価/収益明細 |
転送ステータスが転送済で、転送例外のある原価/収益明細。このような明細はOracle Business Intelligence Date Warehouseの表w_gl_linkage_information_Gに存在しないので、ETLプロセスによって特定されます。 表w_gl_linkage_information_Gには、一般会計に正常に転送された明細が含まれます。 |
GLに存在しない原価/収益明細 |
SLAモジュールが存在しないので、EBS 11.5.10ではサポートされません。 |
未転記の仕訳が存在する原価/収益明細 |
プロジェクトからGLに転送されて、まだ一般会計に転記されていない原価/収益明細。このユース・ケースは、EBS R11510とR12のFSMタスク「プロジェクトGL調整手動仕訳の構成方法」のユース・ケースの説明に従って、一部カスタマイズする必要があります。 |
手動仕訳明細 |
一般会計で手動作成され、プロジェクトに対応する原価/収益明細が存在しない仕訳明細をレポートします。 勘定体系にプロジェクト・セグメントが存在しないように設定されている会計の場合、この調整モジュールは手動仕訳明細と個々のプロジェクトを適合させることができません。 手動仕訳明細をプロジェクトと適合させるには、対応するプロジェクト番号についての注釈をフレックスフィールドを使用して手動仕訳明細に追加し、この情報を取得するようにETLを変更する必要があります。 |
金額不一致 |
仕訳明細のGL金額が、対応する原価/収益明細で集計されている金額の合計に一致しない場合に、仕訳明細と原価/収益明細をレポートします。 |
Projects AnalyticsのGL調整の概要は、第B.2.91項「Project AnalyticsにおけるGL調整の追加情報」を参照してください。
E-Business Suite R12ソース・システムでサポートされているユース・ケースを次に示します。
表B-92 ユース・ケースと説明
ユース・ケース | 説明 |
---|---|
転送されない原価/収益明細 |
転送ステータスが未転送である原価/収益明細トランザクション |
転送例外のある原価/収益明細 |
転送ステータスが転送済で、GLリンケージ表に存在しない原価/収益明細。 このような明細はOracle Business Intelligence Date Warehouseの表w_gl_linkage_information_Gに存在しないので、ETLプロセスによって特定されます。表w_gl_linkage_information_Gには、SLAに正常に転送された明細が含まれます。 |
GLに存在しない原価/収益明細 |
プロジェクトSLAから転送されて、まだ一般会計に転送されていない原価/収益明細。 |
未転記の仕訳が存在する原価/収益明細 |
適合する仕訳明細が一般会計に転記されていない原価/収益明細。 |
手動仕訳明細 |
一般会計で手動作成され、プロジェクトに対応する原価/収益明細が存在しない仕訳明細をレポートします。 勘定体系にプロジェクト・セグメントが存在しないように設定されている会計の場合、この調整モジュールは手動仕訳明細と個々のプロジェクトを適合させることができません。 手動仕訳明細をプロジェクトと適合させるには、対応するプロジェクト番号についての注釈をフレックスフィールドを使用して手動仕訳明細に追加し、この情報を取得するようにETLを変更する必要があります。このユース・ケースは、EBS R11510とR12のFSMタスク「プロジェクトGL調整手動仕訳の構成方法」のユース・ケースの説明に従って、一部カスタマイズする必要があります。 |
金額不一致 |
対応する原価明細または収益明細の金額と一致しない金額を持つ仕訳明細。 |
Projects AnalyticsのGL調整の概要は、第B.2.91項「Project AnalyticsにおけるGL調整の追加情報」を参照してください。
PeopleSoft 9.0ソース・システムでサポートされているユース・ケースを次に示します。
シングル・フィード・データ・システム
ソース・システムがシングル・フィードを使用するように設定されている場合、表PS_CA_ACCTG_LN_PCが存在します。この表は、原価転送(シングル・フィード)と収益の一般会計の1つ前の手順になります。
表B-93 ユース・ケースと説明
ユース・ケース | 説明 |
---|---|
転送されない原価/収益明細 |
転送ステータスが未転送である原価/収益明細トランザクション |
転送例外のある原価/収益明細 |
転送ステータスが転送済で、転送例外のある原価/収益明細。このような明細はOracle Business Intelligence Date Warehouseの表w_gl_linkage_information_Gに存在しないので、ETLプロセスによって特定されます。 表w_gl_linkage_information_Gには、PS_CA_ACCTG_LN_PCに正常に転送された明細が含まれます。 |
GLに存在しない原価/収益明細 |
プロジェクトから中間の補助元帳またはGLリンケージ表に転送され、まだ一般会計に転送されていない原価/収益明細。 |
未転記の仕訳が存在する原価/収益明細 |
プロジェクトからGLに転送されて、まだ一般会計に転記されていない原価/収益明細。 |
手動仕訳明細 |
一般会計で手動作成され、プロジェクトに対応する原価/収益明細が存在しない仕訳明細をレポートします。 |
金額不一致 |
仕訳明細のGL金額が、対応する原価/収益明細で集計されている金額の合計に一致しない場合に、仕訳明細と原価/収益明細をレポートします。 |
デュアル・フィード・データ・システム
表B-94 ユース・ケースと説明
ユース・ケース | 説明 |
---|---|
転送されない原価/収益明細 |
このユース・ケースはデュアル・フィード設定には適用されません。 |
転送例外のある原価/収益明細 |
このユース・ケースは、プロジェクト補助元帳に存在し、一般会計には存在しない明細を特定します。このような明細はOracle Business Intelligence Date Warehouseの表W_GL_LINKAGE_INFORMATION_Gに存在しないので、ETLプロセスによって特定されます。表W_GL_LINKAGE_INFORMATION_Gには、一般会計に正常に転送された明細が含まれます。 |
GLに存在しない原価/収益明細 |
このユース・ケースはデュアル・フィード設定には適用されません。 |
未転記の仕訳が存在する原価/収益明細 |
プロジェクトからGLに転送されて、まだ一般会計に転記されていない原価/収益明細。 |
手動仕訳明細 |
一般会計で手動作成され、プロジェクトに対応する原価/収益明細が存在しない仕訳明細をレポートします。 |
金額不一致 |
仕訳明細のGL金額が、対応する原価/収益明細で集計されている金額の合計に一致しない場合に、仕訳明細と原価/収益明細をレポートします。 |
注意
PeopleSoftシステムには、金額ベース収益とレートベース収益の2種類の収益トランザクションが存在します。
Oracle Business Intelligence Applicationsリリース11.1.1.7.1の場合、調整によってサポートされるのはレートベース収益トランザクションのみです。現在は金額ベース収益の行は収益ファクト表に収集されないので、サポートされていません。
Oracle Procurement and Spend Analyticsは、Procurement Analytics、Sourcing AnalyticsおよびEmployee Expense Analyticsで構成されます。
Oracle Procurement and Spend Analyticsを使用すると、組織のバリュー・チェーン全体のデータを統合して、エグゼクティブ、マネージャ、現場の従業員が、より詳細な情報に基づいて実用的な決定を下せるようになるため、サプライ側のパフォーマンスを最大限に高めることができます。Oracle Procurement and Spend Analyticsの利点は、広範なソーシングと調達の分析、サプライヤの実績分析、サプライヤの支払能力分析、従業員経費分析などを含め、社内支出やソーシングから支払までのプロセス全体を視覚的により詳しく管理できる点にあります。削減額、支出パターン、およびサプライヤの実績を細部まで十分に洞察することによって、組織は費用を大幅に削減し、利益率を拡大できます。また、顧客満足度を高め、競争上の優位性を確保することもできます。Oracle Procurement and Spend Analyticsは、Oracle Financial Analyticsなど、Oracle Business Intelligence Applications製品ラインの他のアプリケーションとも統合されます。これにより、このような洞察が組織全体に浸透するため、顧客管理、サプライヤ管理、および財務決定における組織の有効性はさらに高まります。
Oracle Procurement and Spend Analyticsは、企業支出、支払、従業員経費にわたって、ソーシング、直接支出および間接支出に関する情報を提供します。Oracle Procurement and Spend Analyticsは、次のサブジェクト領域から構成されます。
調達および支出 - 変更オーダー: このサブジェクト領域には、購買文書事後承認の変化に関するレポートする機能があります。ここでは、サプライヤ別、BU別、バイヤー別、および変更オーダー属性(方法、タイプ、開始者など)別に変更/取消の数および処理時間が表示されます。注意: このサブジェクト領域は、Fusionソースに適用可能です。EBSやPeopleSoftなどの他のソースは、このサブジェクト領域をサポートしません。
調達および支出 - 請求書明細: この詳細サブジェクト領域には、サプライヤ、製品、品目カテゴリ、ビジネス・ユニット、コスト・センター、購買事業所、サプライヤ所在地、および関連する階層にわたって組織の合計支出をレポートする機能があります。また、請求書配分レベルの詳細情報を提供します。
調達および支出 - 調達から支払まで: この要約サブジェクト領域には、直接支出と間接支出(MROと従業員経費による間接支出)の両方についてビジネス・ユニット、購買事業所、サプライヤ、製品、品目カテゴリ、および関連階層にわたって請求済支出、約定済支出、および実際の支出と受入を詳細に比較分析してレポートする機能があり、組織全体の支出を詳細に表示できます。
調達および支出 - 購買契約: このサブジェクト領域には、サプライヤ、サプライヤ・サイト、バイヤー、品目、BU、および契約詳細にわたって、契約金額、その消費と有効期限、異なる契約タイプの数、バイヤー、サプライヤとサプライヤ・サイト、契約明細を示す購買契約をレポートする機能があります。
調達および支出 - 購買サイクル明細: この要約サブジェクト領域には、組織のサプライヤの購買依頼から購買オーダーまでのリード・タイム、購買オーダーから受入までのリード・タイム、P2Pリード・タイムなどのサイクル期間パフォーマンスをレポートする機能があります。
調達および支出 - 購買オーダー: この詳細サブジェクト領域は、購買オーダー、購買オーダー費用、および購買スケジュールの情報を組み合せて、サプライヤ、会社、製品、品目カテゴリ、および関連階層にわたって組織のサプライヤの約定済支出、契約遵守、および購買オーダーを購買オーダー明細レベルでレポートする機能があります。
調達および支出 - 購買オーダーBU要約: これは、データ・セキュリティが有効化されていないことを除けば、調達および支出 - 購買オーダー・サブジェクト領域と同じであり、Fusion Applications組込みレポートで明示的データ・フィルタによってのみ使用されます。
調達および支出 - 購買受入: この詳細サブジェクト領域には、サプライヤ、会社、事業所、製品、品目カテゴリ、および関連階層にわたって組織のサプライヤの実際の支出および購買受入を購買受入明細レベルでレポートする機能があり、受入時間に基づくレポートなどが含まれます。
調達および支出 - 購買依頼BU要約: これは、データ・セキュリティが有効化されていないことを除けば、調達および支出 - 購買受入サブジェクト領域と同じであり、Fusion Applications組込みレポートで明示的データ・フィルタによってのみ使用されます。
調達および支出 - 購買依頼ステータス: この要約サブジェクト領域には、購買依頼ステータスを組織のサプライヤの購買依頼の承認サイクルとともにレポートする機能があります。このサブジェクト領域への移入は、Universalアダプタによってのみ行われます。
調達および支出 - 購買依頼: この詳細サブジェクト領域には、サプライヤ、会社、製品、品目カテゴリ、および関連階層にわたって組織のサプライヤの請求支出および購買依頼(循環依頼を含む)を購買依頼明細レベルでレポートする機能があります。
サプライヤ・パフォーマンス - サプライヤAPトランザクション: この要約サブジェクト領域には、サプライヤ、会社、事業所、製品、部品分類、および関連階層にわたって組織のサプライヤの支払実績と支払未払を分析する機能があります。(注意: サプライヤ買掛金コンポーネントを移入するには、Oracle Financial Analyticsの買掛管理モジュールを実装する必要があります。買掛管理モジュールを実装しないと、サプライヤ買掛金レポートの一部に値が表示されません)。調達および支出 - スコアカード: このサブジェクト領域は、調達スコアカードをサポートします。調達組織のパフォーマンスのトレンドを監視して分析する機能を提供するメトリック/KPIとそのターゲットが含まれます。財務、内部顧客、業務、およびサプライヤなどの様々な観点から見たパフォーマンスおよび目標達成の情報を、時間およびビジネス・ユニットにわたって提供します。
サプライヤ・パフォーマンス - サプライヤ・パフォーマンス: このサブジェクト領域(基盤は購買サイクル明細)には、サプライヤから提供される商品の適時性、信頼性、原価、および品質の分析に使用できる目標メトリックがあります。組織の成功に対するサプライヤの貢献度の把握に役立ちます。
ソーシング - 落札: このサブジェクト領域には、ソーシング落札をレポートする機能があり、ソーシングのネゴシエーション・タイプ、BU、サプライヤ、バイヤー、およびカテゴリにわたって予定削減と実現削減、落札金額、落札数量、落札価格、PO額、サプライヤ数、および落札済BUを表示します。
ソーシング - ネゴシエーション: このサブジェクト領域には、ソーシング・ネゴシエーションをレポートする機能があり、ソーシングのネゴシエーション・タイプ、BU、サプライヤ、バイヤー、およびカテゴリにわたってネゴシエーション金額、ヘッダー/行カウント、およびサイクル時間を表示します。
ソーシング - 概要: この詳細サブジェクト領域には、ソーシングのネゴシエーション・タイプ、BU、サプライヤ、バイヤー、およびカテゴリにわたってソーシング文書へのサプライヤの参加と応答、予定削減と実現削減、落札金額、落札数量、落札価格、PO額、サプライヤ数、および落札済BUをレポートする機能があります。
ソーシング - 応答: このサブジェクト領域には、ソーシング・ネゴシエーションをレポートする機能があり、ソーシングのネゴシエーション・タイプ、BU、サプライヤ、バイヤー、およびカテゴリにわたってサプライヤの応答と参加を表示します。
従業員経費 - クレジット・カード: このサブジェクト領域には、組織のコーポレート・カード支出をレポートする機能があり、ビジネス・ユニット別、従業員別、および経費カテゴリ別に未回収トランザクションの件数と金額を表示します。
従業員経費 - 概要: この詳細サブジェクト領域には、従業員、会社、コスト・センター、および関連階層にわたって、承認に関連する承認者とサイクル時間測定および経費タイプ別の従業員経費など、組織の従業員支出をレポートする機能があります。
従業員経費 - 違反: このサブジェクト領域には、従業員およびビジネスにわたって組織の提出済従業員経費のポリシー違反をレポートする機能があります。
支出プランニング - 共通: このサブジェクト領域は、支出プランニング・アプリケーションが換算レート、単位変換、契約などの参照データを提供するために使用します。このサブジェクト領域の各表は、独立して問い合せる必要があるオブジェクトを表すことに注意してください。複数の表にまたがる問合せを作成しないでください。
支出プランニング - 履歴支出: このサブジェクト領域は、支出プランニング・アプリケーションが履歴支出データを抽出および分析するために使用します。
支出プランニング - 購買: このサブジェクト領域は、支出プランニング・アプリケーションが履歴購買データを抽出および分析するために使用します。
Oracle Product Information Management (PIM)データ・ハブは、顧客が異種システムのすべての製品情報を集中管理できるようにする企業データ管理ソリューションです。複数のソース・システムからの断片化した製品データを統合、標準化、同期化して、中央の常時稼働するデータ・リポジトリ(ハブ)に集約することによって、製品情報の単一の企業ビューを作成できます。
PIMデータ・ハブ・ソリューションは、製品情報の異種ソースを集中管理し、あらゆる角度から捉えられた完全な製品ビューをすべてのチャネルで提供します。これにより、組織の内外で、顧客とバリュー・チェーン・パートナの両方に対して製品情報の一貫した管理と通信が可能になります。
Oracle Product Information Management Analyticsアプリケーションは、次のサブジェクト領域から構成されます。
PIM - 品目: このサブジェクト領域は、様々な品目区分、品目タイプ、品目フェーズ、および品目ステータスの品目に関連する作成活動と承認活動の情報を提供します。
PIM - 変更オーダー: このサブジェクト領域は、様々な経過時間範囲の変更オーダーの数、変更オーダーの平均経過時間、変更オーダーのライフ・サイクルの様々なステージ(たとえば、承認済、却下済、ドラフト、保留中有効)など、変更オーダーに関連する活動の情報を提供します。
PIM - 新規品目要求: このサブジェクト領域は、様々な経過時間範囲の新規品目要求の数、新規品目要求の平均経過時間、新規品目要求サイクル時間、および新規品目要求のライフ・サイクルの様々なステージ(たとえば、新規、承認済、却下済)など、新規品目要求に関連する活動の情報を提供します。
PIM - 品目カタログ: このサブジェクト領域は、新規カタログ数、カテゴリ数、および共有カテゴリ数など、品目カタログに関連する活動の情報を提供します。
PIM - 品目バッチ: このサブジェクト領域は、バッチ・インポート・プロセス中の除外品目数、一部インポート済品目数、正常インポート済品目数など、外部システムからの品目インポートに関連する活動の情報を提供します。
Partner Analyticsは、チャネル・マネージャとパートナ・アカウント・マネージャが、すべての重要な前線でのパートナとプログラムのパフォーマンス(引合生成、登録済取引、収益、および登録など)を評価する際に役立ちます。また、パートナ組織の営業担当とマネージャがその営業パフォーマンスを自己評価できるようにします。
Oracle Financial Analyticsは、次の機能領域から構成されます。
従業員経費: Oracle Employee Expenses Analyticsアプリケーションは、コーポレート・カードの使用、経費ポリシー違反、提出と承認のプロセス全体など、組織の従業員関連の支出に関する情報を提供するように設計されています。経費カテゴリにわたって上位支出者を分離し、ポリシー違反の繰返しを特定することによって、従業員経費の要因を把握します。経費トレンドを俯瞰できることにより、主要業者とのネゴシエーション能力が向上します。Oracle Employee Expenses Analyticsアプリケーションのデフォルト構成は、標準レベルとして幅広く認められた詳細度または粒度に基づいています。ただし、抽出処理は、ビジネス要件にあわせて構成および変更できます。
固定資産: 財務管理部長、資産マネージャ、およびコスト・センター・マネージャは、Oracle Fixed Assets Analyticsアプリケーションを使用して、資産の取得から除・売却までのライフ・サイクルの全体像を把握できます。貸借対照表のおよそ40-50%を構成する固定資産は、商業部門と公的部門のどちらの顧客にとっても重要なコンポーネントです。資産のライフ・サイクル値を追跡し、一部の主要資産の収益率を測定することは、組織全体の収益率向上にとって重要です。Oracle Fixed Assets Analyticsアプリケーションのデフォルト構成は、標準レベルとして幅広く認められた詳細度または粒度に基づいています。ただし、抽出処理は、ビジネス要件にあわせて構成および変更できます。
一般会計: General Ledger Analyticsアプリケーションは、貸借対照表、キャッシュ・フロー、経費、予算と実績の比較、運転資金、流動性など、実績に関する主な財務領域を的確に把握できるように設計されています。差異の根本原因を特定し、組織のあらゆるレベルでよりタイムリな十分な情報に基づく決定を行うことができるようにします。帳簿をクローズする前に、期間内財務情報に基づくレポートと分析にアクセスできます。Oracle General Ledger Analyticsアプリケーションのデフォルト構成は、標準レベルとして幅広く認められた詳細度または粒度に基づいています。ただし、抽出処理は、ビジネス要件にあわせて構成および変更できます。
買掛管理: Oracle Payables Analyticsアプリケーションは、ビジネスの買掛/未払金の状態概要を提供するように設計され、財務でその資金アウトフローを適切に管理して、サプライヤに対する予定どおりの支払を保証することができます。サプライヤが戦略上のビジネス・パートナとなり、適時の効率性の向上と購買関係の高品質化が注目されるようになるにつれて、この分析の必要性はますます重要になっています。Oracle Payables Analyticsアプリケーションのデフォルト構成は、標準レベルとして幅広く認められた詳細度または粒度に基づいています。ただし、抽出処理は、ビジネス要件にあわせて構成および変更できます。
収益性: Oracle Profitability Analyticsアプリケーションは、損益計算書、顧客収益性、製品収益性、マージン分析、ROA、およびROEなど、収益性に関する重要なデータを提供するように設計されています。収益と原価の要因に関する洞察を得ることで、財務に関する説明責任の所在を明確にし、プロアクティブな行動を促します。Oracle Profitability Analyticsアプリケーションのデフォルト構成は、標準レベルとして幅広く認められた詳細度または粒度に基づいています。ただし、抽出処理は、ビジネス要件にあわせて構成および変更できます。
売掛管理: Receivables Analyticsアプリケーションは、売掛期限、クレジット・リスク、支払、回収効率など、売掛/未収金に関連する重要なデータを提供するように設計されており、財務担当者による資金インフローと負債回収の管理が最適化されます。売掛/未収金が支払期日を過ぎると、その1日1日が会社にとって大きな機会費用となります。トレンドに注意を払い売掛金の決済状況を分析することは、営業業務の効率、売掛/未収金の質、および主要顧客の価値を評価する1つの方法となります。Oracle Receivables Analyticsアプリケーションのデフォルト構成は、標準レベルとして幅広く認められた詳細度または粒度に基づいています。ただし、抽出処理は、ビジネス要件にあわせて構成および変更できます。
補助元帳会計: Oracle Subledger Accounting Analyticsは、単一のグローバル会計リポジトリで企業全体の会計情報を提供します。期末のクローズ・レポートの合理化と消込の改善、多様なグローバル会計レポート要件への対応、取引パートナに関する報告(サプライヤおよび顧客の会計活動や完全な監査証跡)を支援します。Oracle Subledger Accounting Analyticsアプリケーションのデフォルト構成は、標準レベルとして幅広く認められた詳細度または粒度に基づいています。ただし、抽出処理は、ビジネス要件にあわせて構成および変更できます。
Oracle Enterprise Asset Management Analyticsは、企業全体のすべての保守情報を詳細に分析します。Oracle Enterprise Asset Management Analyticsには、資産故障分析、保守作業オーダー、保守履歴、保守原価分析、リソース利用率、資産品質、および資産メーター読取りが事前に組み込まれているので、保守マネージャは、パフォーマンスを最大化し、利用可能資産を最適化する機会を特定することができます。また、潜在的な問題を前もって特定し、重大な問題になる前に解決するのに役立ちます。故障詳細、作業オーダー原価、資産保守、作業オーダー完了、作業オーダー・バックログ、およびリソース利用率の詳細レベルの分析へのドリルダウン機能を備えたOracle Enterprise Asset Management Analyticsは、すべての保守組織が、パフォーマンスを向上して戦略的目標を満たすために必要な分析機能を提供します。このソリューションは、Oracle Manufacturing Analytics、Supply Chain and Order Management Analytics、Financial Analytics、Procurement and Spend Analyticsなどの他のOracle BI Applicationsとシームレスに統合されており、クロス分析機能をサポートします。
Oracle Enterprise Asset Management Analyticsでは、次のコンテンツ領域の分析サポートが提供されています。
保守原価分析: 様々な資産グループにわたって発生する保守原価に関する情報を提供します。これは、保守原価差異を評価する際に役立ちます。また、非常に詳細なレベルで保守原価を分析する際にも役立ちます。たとえば、資材原価、労務費、ブレークダウン原価などの各原価コンポーネント別に分析できます。
作業オーダー分析: 保守作業オーダーに関するすべての必要な分析情報を提供します。また、バックログ、期日超過バックログ、および作業オーダーの定時完了率に関する洞察情報を提供し、それによって保守組織の作業効率向上を支援します。
故障分析: 資産故障およびそれらの故障に対応するためにかかった時間と費用に関連する情報を提供します。修理までの平均時間(MTTR)や平均故障間隔(MTBF)などの業界標準メトリックにより提供される情報は、資産の全体的な故障履歴およびそれらの故障により組織が負担する間接費を評価する際に役立ちます。
リソース分析: 使用されている保守リソースと、その利用率と効率性の詳細に関する情報を提供します。また、保守マネージャが、使用可能な保守リソースを効率よく使用できるように支援します。
MRO在庫: 保守組織にわたって手持在庫の詳細を分析し、それによって予備品品目の在庫管理にかかる組織の支出を強調する際に役立ちます。MRO在庫年齢調べと組み合せることによって、MRO在庫分析は、保守組織の合計発生原価に対するあらゆる角度からの完全なビューを提供します。
資産履歴: すべての資産について、資産原価、発生した合計保守原価、事業供用年数など、その開始以来の詳細情報を提供します。この情報は、保守マネージャが既存資産を除・売却するのか、または資産を事業に供用するのかを決定する際に役立ちます。
資産品質: 資産に適用する品質テストに関する情報を、資産の収集プラン、収集要素、その結果、および不適合と処分のステータスとともに提供します。
目的
勤務時間は、ソース・システムで様々な周期で定義される可能性があります。たとえば、週当たり35時間と定義される従業員もいれば、月当たりまたは年当たりで定義される従業員もいる可能性があります。メトリックを標準化するために、ソース・システムの単位を日当たり時間または月当たり時間の標準ファクト・メトリックに変換する換算レートを指定する必要があります。
オプションまたは必須
このタスクはオプションです。ただし、デフォルト構成にはOLTP設定が十分に反映されていない可能性があるので、レポートが正確であることを保証するためにレビューする必要があります。
適用対象
勤務時間周期ドメイン構成はすべてのソースに適用されますが、Peoplesoftは独自の年間勤務時間周期換算レートを定義する点で多少異なります。この換算レートは、月標準勤務時間を計算するために、ドメイン・マッピングのかわりに使用されます。
勤務時間ドメイン構成
勤務時間のドメイン・マッピングは、ソース・システムで使用される様々な単位の時間を日当たり時間または月当たり時間の標準ファクト・メトリックに変換するために使用します。
これは、次の2つのドメイン・マッピングで行われます。
表B-95 「ワークフォース・イベントのドメインとメンバー・マッピングの管理」のマッピング
マッピング | ソース・ドメイン | ターゲット・ドメイン | 適用対象 |
---|---|---|---|
「ソース労働時間周期」→「周期-月次ファクタ」 |
WORK_HRS_FREQ |
W_WORK_HRS_FREQ_ MONTHLY_FACTOR |
Fusion EBS Peoplesoftは対象外* |
「ソース労働時間周期」→「周期-日次ファクタ」 |
WORK_HRS_FREQ |
W_WORK_HRS_FREQ_ DAILY_FACTOR |
すべてのソース |
* PeopleSoftはこの計算に周期参照表PS_FREQUENCY_TBL (年間係数/12)を使用します。
ソース・ドメインは、ソース・システムに定義されているすべての勤務時間周期単位(Monthly、Weekly、Bi-Weeklyなど)によってロードされます。
ターゲット・ドメインには、共通周波数単位の様々な換算ファクタがシードされています。たとえば、40時間/週を、8時間/日(40*0.2=8)に換算する0.2がシードされています。
換算ファクタを追加する必要がある場合、ターゲット・ドメインを拡張できます。たとえば、3週間の期間中の標準勤務時間を定義するために単位Tri-weekly (3週間隔)が使用されているとします。5日/週として、この場合、次の新しい周期をターゲット・ドメインに追加する必要があります(数値形式は999.999999999であるとします)。
表B-96 「ワークフォース・イベントのドメインとメンバー・マッピングの管理」のドメイン・マッピング
ドメイン | メンバー・コード | メンバー名 |
---|---|---|
W_WORK_HRS_FREQ_MONTHLY_FACTOR |
1.444444444 |
Tri-weekly 52/(12*3)として計算 |
W_WORK_HRS_FREQ_DAILY_FACTOR |
0.066666667 |
Tri-weekly 1/15として計算 |
このドメイン・マッピングでは、ソース単位のTri-weeklyはこれらの対応する新しいターゲット・メンバーにマップされます。
したがって、3週間の勤務時間が120時間の従業員は、ファクト・メトリックでは次のように表示されます。
- 標準時間(月): 120 * 1.444444444 = 173.3333333331585
- 標準時間(日): 20 * 0.066666667 = 8
依存関係
依存関係はありません。