Go to primary content
Oracle® Retail Assortment & Item Planning for Fashion/Softlines Cloud Service Implementation Guide
Release 19.0
F24867-12
  Go To Table Of Contents
Contents

Previous
Previous
 
Next
Next
 

F Appendix: Using BDI and PDS

A&IP 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 A&IP 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 A&IP 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 A&IP CS available in the GA Integration Configuration. Any additional dimensions present in those hierarchies which are not present in A&IP 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

Product Attributes (patr)

Shared Dimension Shared Dimension Label Aggregate Dimension
patv Currency Not Applicable
patt
patv

Currency (curh)

Shared Dimension Shared Dimension Label Aggregate Dimension
curc Currency Not Applicable

Cluster (clrh)

Shared Dimension Shared Dimension Label Aggregate Dimension
clus Cluster Not Applicable
chnl Channel clus


Note:

If the customer implementation will use RMF CS flat files for integration and will not use BDI but would like to use PDS, it is only partially supported. The customer has to customize the batch transform process 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 A&IP 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 A&IP 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
drtyrtnproc Ty Returns Promo C rtn drtyrtnproc
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
drtyeopc Ty EOP C eop drtyeopc
drtyeopr Ty EOP R eop drtyeopr
drtyeopu Ty EOP U eop drtyeopu
drtyeopb Ty EOP Affected eop drtyeopb
drtyslsprcc Ty Base Unit Price C slsprc drtyslsprcc
drtyslsprcr Ty Base Unit Price R slsprc drtyslsprcr
drtyporcptc Ty PO Receipts C rcpt drtyporcptc
drtyporcptr Ty PO Receipts R rcpt drtypocptr
drtyporcptu Ty PO Receipts U rcpt drtyporcptu
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 R tranx drtyicmkur
drtyicmkdr Ty Inter-Company Markdown R tranx drtyicmkdr
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
drtypclsst TY RMS Display Class Id item_metrics drtypclsst
drtypsclst TY RMS Display item_metrics drtypsclst
drdvprdattt Product Attribute - Item Level prdatt drdvprdattt
drdvppatvt RMS Product Attribute Value patv drdvppatvt
drtyudab TY RMS UDA patt drtyudab
drtyaggwb Ty Aggregate Elapsed Week aggw drtyaggwb
IECPAsrtSkuB CP Assorted Item iecp IECPAsrtSkuB
IECPEventT CP Event iecp IECPEventT
IECPSlsRegU CP Sales Reg U iecp IECPSlsRegU
IECPSlsRegR CP Sales Reg R iecp IECPSlsRegR
IECPSlsProU CP Sales Promo U iecp IECPSlsProU
IECPSlsProR CP Sales Promo R iecp IECPSlsProR
IECPSlsClrU CP Sales Clr U iecp IECPSlsClrU
IECPSlsClrR CP Sales Clr R iecp IECPSlsClrR
IECPSlsC CP Sales C iecp IECPSlsC
IECPEOPU CP EOP U iecp IECPEOPU
IECPEOPC CP EOP C iecp IECPEOPC
IECPRcptU CP Receipts U iecp IECPRcptU
IECPRcptC CP Receipts C iecp IECPRcptC
IECPRtnU CP Customer Returns U iecp IECPRtnU
IECPRtnR CP Customer Returns R iecp IECPRtnR
IECPRtnC CP Customer Returns C iecp IECPRtnC
IECPTrafficU CP Traffic Count U iecp IECPTrafficU
IECPTransactU CP Transaction Count U iecp IECPTransactU
ISCPAsrtSkuB CP Assorted Item iscp ISCPAsrtSkuB
ISCPEventT CP Event iscp ISCPEventT
ISCPSlsRegU CP Sales Reg U iscp ISCPSlsRegU
ISCPSlsRegR CP Sales Reg R iscp ISCPSlsRegR
ISCPSlsProU CP Sales Promo U iscp ISCPSlsProU
ISCPSlsProR CP Sales Promo R iscp ISCPSlsProR
ISCPSlsClrU CP Sales Clr U iscp ISCPSlsClrU
ISCPSlsClrR CP Sales Clr R iscp ISCPSlsClrR
ISCPSlsC CP Sales C iscp ISCPSlsC
ISCPEOPU CP EOP U iscp ISCPEOPU
ISCPEOPC CP EOP C iscp ISCPEOPC
ISCPRcptU CP Receipts U iscp ISCPRcptU
ISCPRcptC CP Receipts C iscp ISCPRcptC
ISCPRtnU CP Customer Returns U iscp ISCPRtnU
ISCPRtnR CP Customer Returns R iscp ISCPRtnR
ISCPRtnC CP Customer Returns C iscp ISCPRtnC
ISCPTrafficU CP Traffic Count U iscp ISCPTrafficU
ISCPTransactU CP Transaction Count U iscp ISCPTransactU
APCPBuyQtyU AP Buy Quantity U apcp APCPBuyQtyU
DSCPAsrtCoreB AP Assorted Item apcp DSCPAsrtCoreB
S1DBCoreB AP Mandatory apcp S1DBCoreB
appwkfrcst Approved Forecast fcst appwkfrcst
MPCPEOPC Cp EOP C mfp_cp MLCPEOPC
MPCPEOPR Cp EOP R mfp_cp MLCPEOPR
MPCPEOPU Cp EOP U mfp_cp MLCPEOPU
MPCPRcptC Cp Receipts C mfp_cp MLCPRcptC
MPCPRcptR Cp Receipts R mfp_cp MLCPRcptR
MPCPRcptU Cp Receipts U mfp_cp MLCPRcptU
MPCPRtn1R Cp Returns Reg+Promo R mfp_cp MLCPRtn1R
MPCPRtn2R Cp Returns Clr R mfp_cp MLCPRtn2R
MPCPRtn1U Cp Returns Reg+Promo U mfp_cp MLCPRtn1U
MPCPRtn2U Cp Returns Clr U mfp_cp MLCPRtn2U
MPCPSlsC Cp Sales C mfp_cp MLCPSlsC
MPCPSls1R Cp Sales Reg+Promo R mfp_cp MLCPSls1R
MPCPSls1U Cp Sales Reg+Promo U mfp_cp MLCPSls1U
MPCPSls2R Cp Sales Clr R mfp_cp MLCPSls2R
MPCPSls2U Cp Sales Clr U mfp_cp MLCPSls2U
MPWPOOAdjC Wp On Order Adj C mfp_wp MLWPOOAdjC
MPWPOOAdjU Wp On Order Adj U mfp_wp MLWPOOAdjU
MPWPOTBC Wp OTB C mfp_wp MLWPOTBC
MPWPOTBU Wp OTB U mfp_wp MLWPOTBU
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, it is only partially supported. The customer has to customize the batch transform process to transform the RMS files to fact files with 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 E, "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:

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 A&IP Cloud Service environment is provisioned, use the bootstrap build A&IP 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 and without using any overwrite option of PDS 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).