Go to primary content
Oracle® Retail Merchandise Financial Planning Cloud Service Implementation Guide
Release 19.0
F24871-12
  Go To Table Of Contents
Contents

Previous
Previous
 
Next
Next
 

H Appendix: Using BDI and PDS

MFP Cloud Service supports integration with RMF CS using Bulk Data Interface (BDI) and Planning Data Storage (PDS). It also allows using only PDS to share data across different RPAS Planning applications if they are registered against it and have common shared hierarchies and positions.

For information on the BDI process flow, see the BDI Process Flow appendix in the Oracle Retail Predictive Application Server Cloud Edition Implementation Guide.

Using BDI

BDI allows sharing data across the enterprise. If the customer implements RMF CS and BDI, then the use of PDS is mandatory, as currently the data loaded into BDI can only be internally transformed to PDS shared measures. For more details about PDS, see "Using PDS".

If BDI is enabled, there is no need for retailers to export flat files from RMS. In order for the batch process to not wait for the files from RMS, the Batch Uses BDI Boolean flag needs to be set to true.

Using PDS

Different RPAS applications can share measures across shared applications if they share common hierarchies and measure data. RPAS uses PDS which can hold the shared dimensions and fact data (shared measures).

A PDS-enabled domain needs an Integration Configuration which contains Shared Dimension data and also shared measures as Fact data that is grouped as Fact Group across different RPAS applications.

All RPAS GA Planning applications have one common GA Integration Configuration which is part of the RPAS Application Standard Libraries (RASL) package called RGBU_RDM.xml that is pre-configured.

The following section describes the shared dimension and measure data from the MFP CS solution which is present in Integration Configuration.

Shared Hierarchies

Shared Hierarchies in PDS should have the union of all dimensions across the different RPAS applications without any User Defined Dimensions and also all of them should have the same names for common hierarchies and common shared dimensions. If RMF CS integration and BDI are used, those hierarchies will be loaded as part of that scheduled process in BDI. If the customer is only using PDS and not using BDI, the customer has to first load the shared hierarchies into one of the RPAS applications by calling the loadDimData utility by using Standard Admin Tasks after uploading the shared dimension file named as <hier>.csv.dat with header information including all shared dimension positions with position labels. In the header, the dimension name should be the shared dimension name in the hierarchy file and the dimension label should be <dim>_label.

The file should be uploaded into the $INCOMING_FTP_PATH/rdm_input/dimdata directory.

If the domain is registered against PDS, then the Batch Uses PDS Boolean flag will be set during batch. It controls the flow of the weekly batch.

The Regular Weekly Batch in MFP CS, in turn calls the batch frame work service dimdataload to load those dimension data files into PDS, if the domain is registered against PDS (Batch Uses PDS flag is set) and not using BDI (Batch Uses BDI flag is not set) to get its data.

Loading dimension data will only load the dimension details into the PDS. The customer needs to run the standard loadHier utility without any input files, in order to synchronize the domain dimension data with PDS for updated positions. That will also be run by default as part of the weekly batch process.

The following tables list the shared hierarchies and dimensions for MFP CS available in the GA Integration Configuration. Any additional dimensions present in those hierarchies which are not present in MFP CS can be from another shared application. Those also need to be provided if the customer loads those positions into PDS.

Calendar Hierarchy (clnd)

Shared Dimension Shared Dimension Label Aggregate Dimension
day Day Not Applicable
week Week day
mnth Month week
qrtr Quarter mnth
half Half qrtr
year Year half
woyr Week of Year year
dow Day of Week day

Product Hierarchy (prod)

Shared Dimension Shared Dimension Label Aggregate Dimension
sku Item Not Applicable
skup Style/Color sku
skug Style skup
scls Subclass skug
clss Class scls
dept Department clss
pgrp Group dept
dvsn Division pgrp
cmpp Company dvsn
brnd Brand sku
vndr Vendor sku

Location Hierarchy (loc)

Shared Dimension Shared Dimension Label Aggregate Dimension
stor Location Not Applicable
dstr District stor
regn Region dstr
chnl Channel regn
chan Chain chnl
comp Company chan
loct Location Type stor
phwh Physical Warehouse stor
fflt Fulfillment Type stor
tdar Trade Area stor
strc Store Cluster stor
chnc Cluster Channel strc
sfmt Store Format stor
stcl Store Class stor

Currency (curh)

Shared Dimension Shared Dimension Label Aggregate Dimension
curc Currency Not Applicable


Note:

If the customer implementation will use RMF CS flat files for integration and will not use BDI but would like to use PDS, the batch transform process should be customized to transform the RMS files to create the shared hierarchy files from the RMS files as needed by PDS with headers.


Note:

GA batch control files contain entries only to load shared hierarchies used by the application into PDS, but PDS can have more hierarchies not used by the current application. If not using BDI to load PDS, it is recommended to load the shared hierarchies common across multiple applications into only one application which contains most of the shared hierarchies. That way the customer can avoid uploading shared hierarchies data into multiple applications.

Shared Fact Data

PDS shared measure data is called as Fact Data to share across different planning applications. Shared fact data are grouped together as fact groups to enable them to be accessed together. If RMF CS Integration and BDI are used, those shared fact measures are directly loaded as part of the scheduled process in BDI. If the customer is only using PDS and not using BDI, then they have to load the fact data into one of the RPAS applications by calling the loadFactData utility by using Standard Admin Tasks after uploading the shared fact file named as <fact_group>.csv.ovr or <fact_group>.csv.rpl with the header as the shared fact name. The customer can use any single file with any name or split them into multiple files to load different fact measures if all of them have the same base intersection, but it is recommended to load the files after grouping them as per the fact groups to allow them to load in parallel.

The file should be uploaded into the $INCOMING_FTP_PATH/rdm_input/factdata directory.

If the domain is registered against PDS, then the Batch Uses PDS Boolean flag will be set during batch. It controls the flow of weekly batch.

The regular Weekly Batch in MFP CS also calls the batch frame work service loaddata, with control entries containing "H" and file names as parameters, to load the fact data into PDS, if the domain is registered against PDS and not using BDI to get its data.

Loading fact data will only load the fact data into PDS and will automatically make the mapped shared measures available into the registered domains The customer does not have to load those shared measures again into domains.

The following table lists the shared measures for MFP CS available in the GA Integration Configuration.

Fact Name Fact Label Fact Group Name Shared Measure Name
drtynslsregr Ty Net Sales Reg R nsls drtynslsregr
drtynslspror Ty Net Sales Promo R nsls drtynslspror
drtynslsclrr Ty Net Sales Clr R nsls drtynslsclrr
drtynslsregc Ty Net Sales Reg C nsls drtynslsregc
drtynslsproc Ty Net Sales Promo C nsls drtynslsproc
drtynslsclrc Ty Net Sales Clr C nsls drtynslsclrc
drtynslsregu Ty Net Sales Reg U nsls drtynslsregu
drtynslsprou Ty Net Sales Promo U nsls drtynslsprou
drtynslsclru Ty Net Sales Clr U nsls drtynslsclru
drtyrtnregr Ty Returns Reg R rtn drtyrtnregr
drtyrtnpror Ty Returns Promo R rtn drtyrtnpror
drtyrtnclrr Ty Returns Clr R rtn drtyrtnclrr
drtyrtnregc Ty Returns Reg C rtn drtyrtnregc
drtyrtnclrc Ty Returns Promo C rtn drtyrtnclrc
drtyrtnclrc Ty Returns Clr C rtn drtyrtnclrc
drtyrtnregu Ty Returns Reg U rtn drtyrtnregu
drtyrtnprou Ty Returns Promo U rtn drtyrtnprou
drtyrtnclru Ty Returns Clr U rtn drtyrtnclru
drtyeop1c Ty EOP Reg+Promo C eopx drtyeop1c
drtyeop2c Ty EOP Clr C eopx drtyeop2c
drtyeop1r Ty EOP Reg+Promo R eopx drtyeop1r
drtyeop2r Ty EOP Clr R eopx drtyeop2r
drtyeop1u Ty EOP Reg+Promo U eopx drtyeop1u
drtyeop2u Ty EOP Clr U eopx drtyeop2u
drtyporcptc Ty PO Receipts C rcpt drtyporcptc
drtypocptr Ty PO Receipts R rcpt drtypocptr
drtyporcptu Ty PO Receipts U rcpt drtyporcptu
drtyrinva1c Ty RMF Shrink Inventory Adjust C tran drtyrinva1c
drtyrinva1r Ty RMF Shrink Inventory Adjust R tran drtyrinva1r
drtyrinva1u Ty RMF Shrink Inventory Adjust U tran drtyrinva1u
drtyrinva2c Ty RMF Non-Shrink Inventory Adjust C tran drtyrinva2c
drtyrinva2r Ty RMF Non-Shrink Inventory Adjust R tran drtyrinva2r
drtyrinva2u Ty RMF Non-Shrink Inventory Adjust U tran drtyrinva2u
drtyvndfndr Ty Vendor Funds R tran drtyvndfndr
drtytraninu Ty Transfers In U tranx drtytraninu
drtytraninc Ty Transfers In C tranx drtytraninc
drtytraninr Ty Transfers In R tranx drtytraninr
drtytraninbu Ty Transfers In Book U tranx drtytraninbu
drtytraninbc Ty Transfers In Book C tranx drtytraninbc
drtytraninbr Ty Transfers In Book R tranx drtytraninbr
drtytranoutu Ty Transfers Out U tranx drtytranoutu
drtytranoutc Ty Transfers Out C tranx drtytranoutc
drtytranoutr Ty Transfers Out R tranx drtytranoutr
drtytranoutbu Ty Transfers Out Book U tranx drtytranoutbu
drtytranoutbc Ty Transfers Out Book C tranx drtytranoutbc
drtytranoutbr Ty Transfers Out Book R tranx drtytranoutbr
drtytraniniu Ty Transfers In ICT U tranx drtytraniniu
drtytraninic Ty Transfers In ICT C tranx drtytraninic
drtytraninir Ty Transfers In ICT R tranx drtytraninir
drtytranoutiu Ty Transfers Out ICT U tranx drtytranoutiu
drtytranoutic Ty Transfers Out ICT C tranx drtytranoutic
drtytranoutir Ty Transfers Out ICT R tranx drtytranoutir
drtyicmkur TY Inter-Company Markup tranx drtyicmkur
drtyicmkdr TY Inter-Company Markdown tranx drtyicmkdr
drtymkupr Ty Markup R mkd drtymkupr
drtymkdcanr Ty Markdown Cancel R mkd drtymkdcanr
drtymkdregr Ty Markdown Reg R mkd drtymkdregr
drtymkdpror Ty Markdown Promo R mkd drtymkdpror
drtymkdpclr Ty Markdown Promo Clear R mkd drtymkdpclr
drtymkdclrr Ty Markdown Clear R mkd drtymkdclrr
drtywfmkdr Ty W/F Markdown R mkd drtywfmkdr
drtywfmkur Ty W/F Markup R mkd drtywfmkur
drtyoou Ty On Order U oo drtyoou
drtyoor Ty On Order R oo drtyoor
drtyooc Ty On Order C oo drtyooc
drtylcratex Ty Local Currency Rate curc drtylcratex
addvlocendd Location Close Dt stor_metrics addvlocendd
addvlocrefd Location Refurbish Dt stor_metrics addvlocrefd
addvwfpoct W/F Location Type stor_metrics addvwfpoct
drtypclsst TY RMS Display Class Id item_metrics drtypclsst
drtypsclst TY RMS Display Sub-Class Id item_metrics drtypsclst
mpcpslsu MP CP Sales U mfp_cp mpcpslsu
mpcpslsr MP CP Sales R mfp_cp mpcpslsr
mpcpslsc MP CP Sales C mfp_cp mpcpslsc
mpcprcptu MP CP Receipts U mfp_cp mpcprcptu
mpcprcptr MP CP Receipts R mfp_cp mpcprcptr
mpcprcptc MP CP Receipts C mfp_cp mpcprcptc
mpcpeopu MP CP EOP U mfp_cp mpcpeopu
mpcpeopr MP CP EOP R mfp_cp mpcpeopr
mpcpeopc MP CP EOP C mfp_cp mpcpeopc
mpcprtnu MP CP Returns U mfp_cp mpcprtnu
mpcprtnr MP CP Returns R mfp_cp mpcprtnr
mpwpotbu MP WP OTB U mfp_wp mpwpotbu
mpwpooadju MP WP OO Adj U mfp_wp mpwpooadju
mpwpotbc MP WP OTB C mfp_wp mpwpotbc
mpwpooadjc MP WP OO Adj C mfp_wp mpwpooadjc
lpcpslsu LP CP Sales U lp_cp lpcpslsu
lpcpslsr LP CP Sales R lp_cp lpcpslsr
lpcpslsc LP CP Sales C lp_cp lpcpslsc
lpcprcptu LP CP Receipts U lp_cp lpcprcptu
lpcprcptr LP CP Receipts R lp_cp lpcprcptr
lpcprcptc LP CP Receipts C lp_cp lpcprcptc
lpcpeopu LP CP EOP U lp_cp lpcpeopu
lpcpeopr LP CP EOP R lp_cp lpcpeopr
lpcpeopc LP CP EOP C lp_cp lpcpeopc
lpcprtnu LP CP Returns U lp_cp lpcprtnu
lpcprtnr LP CP Returns R lp_cp lpcprtnr
lpwpotbu LP WP OTB U lp_wp lpwpotbu
lpwpooadju LP WP OO Adj U lp_wp lpwpooadju
lpwpotbc LP WP OTB C lp_wp lpwpotbc
lpwpooadjc LP WP OO Adj C lp_wp lpwpooadjc
lpapslsu LP AP Sales U lp_ap lplaslsu
lpapslsr LP AP Sales R lp_ap lplaslsr
lpapslsc LP AP Sales C lp_ap lplaslsc
lpaprcptu LP AP Receipts U lp_ap lplarcptu
lpaprcptr LP AP Receipts R lp_ap lplarcptr
lpaprcptc LP AP Receipts C lp_ap lplarcptc
lpapeopu LP AP EOP U lp_ap lplaeopu
lpapeopr LP AP EOP R lp_ap lplaeopr
lpapeopc LP AP EOP C lp_ap lplaeopc
lpaprtnu LP AP Returns U lp_ap lplartnu
lpaprtnr LP AP Returns R lp_ap lplartnr
addvchwhmapt Warehouse - Channel Mapping whmap addvchwhmapt
drtywfslsu Ty W/F Sales U wfsls drtywfslsu
drtywfslsc Ty W/F Sales C wfsls drtywfslsc
drtywfslsr Ty W/F Sales R wfsls drtywfslsr
drtywfrtnu Ty W/F Returns U wfsls drtywfrtnu
drtywfrtnc Ty W/F Returns C wfsls drtywfrtnc
drtywfrtnr Ty W/F Returns R wfsls drtywfrtnr


Note:

If the customer implementation is using RMF CS flat files for integration and not using BDI but would like to also use PDS, then it is only partially supported. The customer has to customize the batch transform process to transform the RMS files to fact files with headers fact names as headers to load into PDS.


Note:

Currently, the BDI-PDS existing integration allows limited extensibility. For allowed changes to the PDS Integration Configuration, see Appendix G, "Appendix: Extensibility". Only existing measures present in the GA Integration Configuration for PDS can now be integrated with BDI. Any added hierarchies or facts to the Integration Configuration will not be readily integrated using BDI. The customer can only load those components into PDS using the standard file-based integration allowed for PDS.


Note:

PDS allows using fact measures with a lower intersection than the shared measures present in the domain and allows them to aggregate it while accessing the data from PDS. For MFP CS, all fact measures loaded at the sku level are aggregated and viewed as shared measures in MFP CS at the scls level.


Note:

Enterprise Edition (EE) customers and non-EE customers can use PDS to create shared hierarchies and share measures across multiple applications, but they can also use the BDI process only if the hierarchy and measures conform to the GA Integration Configuration. They can use the GA Integration Configuration as the base and can only add custom changes on top of it, without changing any GA components. The PDS build or patch process will merge GA component changes and validate for removal of any GA components in the customer uploaded Integration Configuration.

For details about creating and editing an Integration Configuration, see the Oracle Retail Predictive Application Server Cloud Edition Configuration Tools User Guide. For details about building and patching an Integration Configuration for creating PDS, see the Oracle Retail Predictive Application Server Cloud Edition Administration Guide.


Implementation Steps with BDI, PDS, and RMF CS Integration

If BDI implementation with RMF CS is used for implementation, the following steps need to be done in this order. The steps assume that RPAS, RASL, UI, and BDI are already installed:

  1. Once the MFP Cloud Service environment is provisioned, use the bootstrap build MFP domain using the initial set of customer hierarchy data. For Shared Hierarchies which are expected to come from BDI/PDS, load only with the valid positions which are in BDI. It is not necessary to have all records, but at least one valid position in each of the shared hierarchy files is needed.

  2. Build PDS using the default integration configuration, without uploading any data. After PDS is built, it will also register the domain against that PDS.

  3. Integrate with BDI and load PDS by running the BDI Process Flows. That should load the PDS schemas with data from BDI for both shared dimensions and shared measure (fact) data.

  4. Upload the hierarchy files for non-shared hierarchies and run the Load Hierarchies OAT task under Configured Batch Tasks. It will synch up the shared hierarchies with PDS and load the non-shared hierarchies from the uploaded files.

  5. Set the Batch Uses BDI and Enable RMF CS Boolean measures in the Admin workbooks.

  6. Set up the necessary Admin data or load the admin data files.

  7. Run the weekly batch to process all loaded actuals (from PDS for shared data).