| Oracle® Retail Merchandising System Operations Guide, Volume 1 - Batch Overviews and Designs 16.0.025 E95001-03 |
|
 Previous |
 Next |
| Oracle® Retail Merchandising System Operations Guide, Volume 1 - Batch Overviews and Designs 16.0.025 E95001-03 |
|
Previous |
Next |
Retail Predictive Application Server (RPAS) is the platform for Oracle Retail's planning applications. RMS provides foundation and inventory information to RPAS for use in planning processes. All RPAS based planning processes require a minimum amount of information. These platform level integration processes are discussed in this chapter.
Some of additional planning products based on the RPAS platform require additional information from RMS and produce additional results for RMS. RMS also provides specific integrations for Retail Demand Forecasting (RDF) and Merchandise Financial Planning (MFP). These product level integration processes are also discussed in this chapter.
Deeper information about the flow of information between RMS and Planning applications can be found in the Retail Reference Architecture (available on MyOracleSupport).
RPAS requires both foundation and transaction data from RMS.
Transaction and inventory extracts should be scheduled after main RMS inventory processing. Weekly information in RMS is rolled up, which pushes some weekly RPAS extracts to quite late in the RMS schedule.
Scheduling and dependency information for each program can be found in the program details section of this chapter.
Table 28-1 RDF Integration Program Summary
| Program | Description |
|---|---|
|
rms_oi_forecast_history.ksh |
Retain Item Forecast History |
|
fcstprg.pc |
Purge Forecast Data |
|
load_item_forecast.ksh |
RMS load of weekly or daily item forecast from RDF or a 3rd party forecasting application |
|
BDI_RPAS_Calendar_Fnd_PF_From_RMS_JOB |
Calendar Bulk Extract to RPAS |
|
BDI_RPAS_CurrConvRates_Fnd_PF_From_RMS_JOB |
Currency Rates Bulk Extract to RPAS |
|
BDI_RPAS_MerchHier_Fnd_PF_From_RMS_JOB |
Merchandise Hierarchy and Item Bulk Data Extract to RPAS |
|
BDI_RPAS_OrgHier_Fnd_PF_From_RMS_JOB |
Organization Hierarchy Bulk Data Extract to RPAS |
|
BDI_RPAS_Store_Fnd_PF_From_RMS_JOB |
Store Bulk Data Extract to RPAS |
|
BDI_RDF_UdaItemLov_Fnd_From_RMS_JOB |
UDA Item LOV Bulk Data Extract to RDF |
|
BDI_RDF_StockOut_Tx_PF_From_RMS_JOB |
Extracts information for items which are out of stock for use by the RDF application. |
|
BDI_RDF_WeeklySales_Tx_PF_From_RMS_JOB |
Extracts weekly sales information for use by the RDF application. |
Table 28-2 MFP Integration Program Summary
| Program | Description |
|---|---|
|
BDI_MFP_Inventory_Tx_PF_From_RMS_JOB |
Inventory Bulk Extract to MFP |
|
BDI_MFP_OnOrder_Tx_PF_From_RMS_JOB |
OnOrder Bulk Extract to MFP |
|
BDI_MFP_TranData_Tx_PF_From_RMS_JOB |
Transaction Data Bulk Extract to MFP |
|
BDI_RPAS_Calendar_Fnd_PF_From_RMS_JOB |
Calendar Bulk Extract to RPAS |
|
BDI_RPAS_CurrConvRates_Fnd_PF_From_RMS_JOB |
Currency Rates Bulk Extract to RPAS |
|
BDI_RPAS_MerchHier_Fnd_PF_From_RMS_JOB |
Merchandise Hierarchy and Item Bulk Data Extract to RPAS |
|
BDI_RPAS_OrgHier_Fnd_PF_From_RMS_JOB |
Organization Hierarchy Bulk Data Extract to RPAS |
|
BDI_RPAS_Store_Fnd_PF_From_RMS_JOB |
Store Bulk Data Extract to RPAS |
For additional details on the RMS/MFP integration from the perspective of MFP, see the Oracle Retail Merchandise Financial Planning Operations Guide.
The following table lists programs that are to be deprecated. These programs have either been replaced by the BDI interfaces described above or through the Data Loading feature of the application.
Table 28-3 Deprecated Programs
| Program | Description |
|---|---|
|
soutdnld.pc |
Download of Out Of Stock Items |
|
ftmednld.pc |
Download of Time Hierarchy for Planning Systems |
|
onictext |
On Inter-Company Transfer Exhibit |
|
onordext |
On Order Extract |
|
gradupld |
Upload of Store Grade Classifications from RPAS |
|
onorddnld |
On Order Download to Financial Planning |
| Module Name | rms_oi_forecast_history.ksh |
| Description | Retain 4 weeks of Item Forecast History |
| Functional Area | Item Forecast, Inventory Analyst Report |
| Module Type | Admin |
| Module Technology | Ksh |
| Catalog ID | RMS491 |
| Runtime Parameters | $UP (database connect string) |
This batch program preserves 4 weeks of weekly forecasted sales data in ITEM_FORECAST to the ITEM_FORECAST_HISTORY table before ITEM_FORECAST is truncated and refreshed by the load_item_forecast.ksh weekly batch program. The data in ITEM_FORECAST_HISTORY is used to support the Inventory Variance to Forecast report in the Inventory Analyst dashboard. If the system is not configured to use this report (for example, rms_oi_system_options.ia_variance_to_forecast_ind is N), then running this batch job will NOT copy any data to ITEM_FORECAST_HISTORY.
To support potentially large volume of data on ITEM_FORECAST and ITEM_FORECAST_HISTORY, ITEM_FORECAST_HISTORY is interval partitioned by EOW_DATE with a partition interval of 7 days and an interval high value of EOW_DATE+1. EOW_DATE must be a valid EOW_DATE based on calendar type - (4) 454 or (C) Standard Calendar.
| Module Name | fcstprg.pc |
| Description | Purge Forecast Data |
| Functional Area | Interface - Planning |
| Module Type | Admin |
| Module Technology | ProC |
| Catalog ID | RMS227 |
| Runtime Parameters | NA |
This program deletes data from the RMS forecast information tables. This program serves to delete data by domains so that they can re-loaded with new forecast information from a forecasting system such as RDF.
| Module Name | load_item_forecast.ksh |
| Description | Load daily/weekly item forecast from Oracle Retail Demand Forecasting (RDF) Cloud Service |
| Functional Area | Integration - Forecast |
| Module Type | Integration |
| Module Technology | Ksh |
| Catalog ID | N/A |
| Runtime Parameters | Database connection,
Upload file name, Type of the run (Valid values: W – Weekly and D - Daily) |
This script loads item forecast data into the RMS forecast tables.
The forecast data comes from RDF in a CSV (comma separated) format file. RMS expects a single input file (that is, a csv file) in an archive file format (that is, zip). A run-time parameter (that is, run type) of ’D' or ’W' indicates whether the Daily or Weekly forecast data is being loaded into RMS. If the forecast is a daily forecast, information is written to the DAILY_ITEM_FORECAST table. If the forecast is a weekly forecast, information is written to the ITEM_FORECAST table. Depending on the run type parameter, the batch truncates the respective forecast table prior to loading.
This batch is executed through the wrapper script rmswrap_shell_in.ksh
Table 28-8 Scheduling Constraints
| Schedule Information | Description |
|---|---|
|
Processing Cycle |
N/A |
|
Frequency |
Daily |
|
Scheduling Considerations |
If the system is configured to use the Inventory Variance to Forecast report in the Inventory Analyst dashboard, run this program after rms_oi_forecast_history.ksh to preserve 4 weeks of item forecast data before truncating it in this program. |
|
Pre-Processing |
N/A |
|
Post-Processing |
N/A |
|
Threading Scheme |
N/A |
Evaluate the successful load of the data.
In case of any failures:
SQL load – SQL load dumps invalid records that do not meet certain technical requirements (that is, data type inconsistencies, and so on). The rejected record is written either to a bad file or to a discard file. The discard file contains records that do not satisfy conditions such as, missing or invalid record types. Records with other technical issues are written to the bad file.
Note that a non-fatal code is returned by the program and a message will be written to the log file if reject files are created.
User Action: When such conditions exist, the user may update either the bad or the discard file and attempt to reload using the same files.
Or fix the data input file and reload, so that the item forecast tables will be truncated and uploads item forecast tables with the corrected the data.
If a run-time parameter of weekly is used, the input file is in fixed-length format.
Table 28-10 load_item_forecast.ksh - Input File Layout Weekly
| Field Name | Field Type | Required | Description |
|---|---|---|---|
|
EOW_DATE |
Date(8) |
Yes |
Item_forecast.eow_date (YYYYMMDD) |
|
ITEM |
Char(25) |
Yes |
Item_forecast.item |
|
LOC |
Char(10) |
Yes |
Item_forecast.loc |
|
FORECAST_SALES |
Double(14) |
Yes |
Item_forecast.forecast_sales Note - this field can contain decimal quantities. Unlike quantity fields in RMS ProC Batch files, this qty field is not assumed to be extended to significant digits. |
|
FORECAST_STD_DEV |
Double(14) |
Yes |
Item_forecast.forecast_std_dev Note - this field can contain decimal quantities. Unlike quantity fields in RMS ProC Batch files, this qty field is not assumed to be extended to significant digits. |
If a run-time parameter of daily is used, the input file is in fixed-length format.
Table 28-11 load_item_forecast.ksh - Input File Layout Daily
| Field Name | Field Type | Required | Description |
|---|---|---|---|
|
DATA_DATE |
Date(8) |
Yes |
Daily_item_forecast.data_date (YYYYMMDD) |
|
ITEM |
Char(25) |
Yes |
Daily_item _forecast.item |
|
LOC |
Char(10) |
Yes |
Daily_item _forecast.loc |
|
FORECAST_SALES |
Double(14) |
Yes |
Daily_item_forecast.forecast_sales Note - this field can contain decimal quantities. Unlike quantity fields in RMS ProC Batch files, this qty field is not assumed to be extended to significant digits. |
|
FORECAST_STD_DEV |
Double(14) |
Yes |
Daily_item_forecast.forecast_std_dev Note - this field can contain decimal quantities. Unlike quantity fields in RMS ProC Batch files, this qty field is not assumed to be extended to significant digits |
| Module Name | BDI_MFP_Inventory_Tx_PF_From_RMS_JOB |
| Description | Extracts inventory information to MFP from RMS |
| Functional Area | Inventory |
| Module Type | Integration |
| Module Technology | BDI job |
| Catalog ID | NA |
| Runtime Parameters | Inventory_Tx_ProcessFlow_From_RMS Inventory_Tx_Extractor |
RMS extracts inventoried, non-pack transaction items to Merchandise Financial Planning (MFP) on a weekly basis. It utilizes BDI (Bulk Data Integration) to facilitate the bulk data movement from RMS to MFP.
The batch job BDI_MFP_Inventory_Tx_PF_From_RMS_JOB is defined in the RMS JOS batch job admin as follows:
<job id="BDI_MFP_Inventory_Tx_PF_From_RMS_JOB" version="1.0" xmlns="http://xmlns.jcp.org/xml/ns/javaee">
<properties>
<property name="description" value="Extracts information regarding inventory for use by the MFP application"/>
</properties>
<step id="batchlet-step">
<batchlet ref="BDIInvokerBatchlet">
<properties>
<property name="bdiProcessFlowUrl" value="#SysOpt.bdiProcessFlowUrl"/>
<property name="bdiProcessFlowCredential" value="#SysOpt.bdiProcessFlowUrlUserAlias"/>
<property name="predicateDS" value="RmsDBDS"/>
<property name="predicateFunction" value="RMS_BATCH_STATUS_SQL.GET_EOW_RUN_SIGNAL"/>
</properties>
</batchlet>
<end on="COMPLETED"/>
</step>
</job>
When the batch job BDI_MFP_Inventory_Tx_PF_From_RMS_JOB is executed, a batchlet (BDIInvokerBatchlet) starts the execution flow. It calls a PLSQL function (RMS_BATCH_STATUS_SQL.GET_EOW_RUN_SIGNAL) to ensure the process flow is only executed on an EOW_DATE. If vdate is an EOW_DATE, it invokes a BDI process flow (Inventory_Tx_ProcessFLow_From_RMS) to perform a series of steps to extract, download, and transport the downloaded files to target applications (MFP):
Extractor job (Inventory_Tx_ExtractorJob) calls BDI_MFP_SQL. INVENTORY_UP function to extract data from RMS view V_BDI_MFP_INVENTORY to MFP outbound staging table INVENTORY_OUT.
A generic BDI Downloader file creator job writes quantities on order information from the INVENTORY_OUT table into a comma-delimited flat file, which will be consumed by MFP. A zero-byte trigger file is also generated to signal that the extract process was successful. Two separate copies of the data file and the trigger file are sent to MFP.
The downloaded data files and trigger files are written to designated MFP location as configured via BDI system options MFP_outboundLocation.
The flat file will contain the following information:
Table 28-14 Flat File - Inventory Bulk Extract to MFP
| Field Name | Field Type | Required | Description |
|---|---|---|---|
|
EOW |
Date |
Yes |
Indicates the end of week date that the on order information pertains to. |
|
ITEM |
Varchar2(25 |
Yes |
Transaction level item only. |
|
LOCATION |
Number(10) |
Yes |
Could be a store or warehouse. |
|
LOC_TYPE |
VARCHAR2(1) |
Yes |
Indicates if the location is a store or warehouse - S = Store; W = Warehouse. |
|
CLEAR_IND |
Number(1) |
Yes |
If Y, item/location is currently on clearance, then inventory values below will be mapped to the clearance measures in MFP; if N, then they will be mapped to the regular/promotion inventory measures in MFP. |
|
REGULAR_INVENTORY_UNITS |
NUMBER(12,4) |
Yes |
item_loc_soh: inventory units = stock_on_hand + pack_comp_soh + in_transit_qty + pack_comp_intran |
|
REGULAR_INVENTORY_COST |
NUMBER(20,4) |
Yes |
item_loc_soh: inventory units * cost - cost will differ based on accounting method - If item is in a cost department and running average cost, use av_cost - If item is in a cost department and running standard cost, use unit_cost - If item is in a retail department, use cum_markon_pct for subclass/location * unit_retail |
|
REGULAR_INVENTORY_RETAIL |
NUMBER(20,4) |
Yes |
item_loc_soh: inventory units * unit_retail - If system option set to have stock ledger run VAT exclusive, then a VAT exclusive unit_retail should be used here. |
| Module Name | BDI_MFP_OnOrder_Tx_PF_From_RMS_JOB |
| Description | Extracts inventory information to MFP from RMS |
| Functional Area | Inventory Tracking |
| Module Type | Integration |
| Module Technology | BDI job |
| Catalog ID | NA |
| Runtime Parameters | OnOrder_Tx_ProcessFlow_From_RMS OnOrder_Tx_Extractor |
RMS extracts its quantities on order to MFP on a weekly basis. It utilizes BDI (Bulk Data Integration) to facilitate the bulk data movement from RMS to MFP.
The batch job BDI_MFP_OnOrder_Tx_PF_From_RMS_JOB is defined in the RMS JOS batch job admin as follows:
<job id="BDI_MFP_OnOrder_Tx_PF_From_RMS_JOB" version="1.0" xmlns="http://xmlns.jcp.org/xml/ns/javaee">
<properties>
<property name="description" value="Extracts information regarding quantities on order for use by the MFP application"/>
</properties>
<step id="batchlet-step">
<batchlet ref="BDIInvokerBatchlet">
<properties>
<property name="bdiProcessFlowUrl" value="#SysOpt.bdiProcessFlowUrl"/>
<property name="bdiProcessFlowCredential" value="#SysOpt.bdiProcessFlowUrlUserAlias"/>
<property name="predicateDS" value="RmsDBDS"/>
<property name="predicateFunction" value="RMS_BATCH_STATUS_SQL.GET_EOW_RUN_SIGNAL"/>
</properties>
</batchlet>
<end on="COMPLETED"/>
</step>
</job>
When the batch job BDI_MFP_OnOrder_Tx_PF_From_RMS_JOB is executed, a batchlet (BDIInvokerBatchlet) starts the execution flow. It calls a PLSQL function (RMS_BATCH_STATUS_SQL.GET_EOW_RUN_SIGNAL) to ensure the process flow is only executed on an EOW_DATE. If vdate is an EOW_DATE, it invokes a BDI process flow (OnOrder_Tx_ProcessFlow_RMS) to perform a series of steps to extract, download, and transport the downloaded files to target applications (MFP):
Extractor job (OnOrder_Tx_Extractor) calls BDI_MFP_SQL. ON_ORDER_UP function to extract data from RMS view V_BDI_MFP_ON_ORDER to MFP outbound staging table ON_ORDER_OUT.
A generic BDI Downloader file creator job writes quantities on order information from the ON_ORDER_OUT table into a comma-delimited flat file, which will be consumed by MFP. A zero-byte trigger file is also generated to signal that the extract process was successful. Two separate copies of the data file and the trigger file are sent to MFP.
The downloaded data files and trigger files are written to designated MFP location as configured via BDI system options MFP_outboundLocation.
The flat file will contain the following information:
Table 28-17 Flat File - OnOrder Bulk Extract to MFP
| Field Name | Field Type | Required | Description |
|---|---|---|---|
|
EOW |
Date |
Yes |
Indicates the end of week date that the on order information pertains to. |
|
ITEM |
Varchar2(25) |
Yes |
Transaction level item only. |
|
LOCATION |
Number(10) |
Yes |
Could be a store or warehouse. |
|
LOC_TYPE |
VARCHAR2(1) |
Yes |
Indicates if the location is a store or warehouse - S = Store; W = Warehouse. |
|
CLEAR_IND |
Number(1) |
Yes |
Indicates if the item/location is on clearance. |
|
ON_ORDER_UNITS |
NUMBER(12) |
Yes |
Indicates the total quantity of the item in the order in standard unit of measure. |
|
ON_ORDER_COST |
NUMBER(20,4) |
Yes |
on order * PO cost in primary currency |
|
ON_ORDER_RETAIL |
NUMBER(20,4) |
Yes |
on order * PO retail in primary currency |
| Module Name | BDI_MFP_TranData_Tx_PF_From_RMS_JOB |
| Description | Extracts Transaction data to MFP from RMS |
| Functional Area | Transactional Data |
| Module Type | Integration |
| Module Technology | BDI job |
| Catalog ID | NA |
| Runtime Parameters | TranData_Tx_ProcessFlow_From_RMS TranData_Tx_Extractor |
RMS extracts transactional data to MFP on a weekly basis. It utilizes BDI (Bulk Data Integration) to facilitate the bulk data movement from RMS to MFP.
The batch job BDI_MFP_TranData_Tx_PF_From_RMS_JOB is defined in the RMS JOS batch job admin as follows:
<job id="BDI_MFP_TranData_Tx_PF_From_RMS_JOB" version="1.0" xmlns="http://xmlns.jcp.org/xml/ns/javaee">
<properties>
<property name="description" value="Extracts information regarding transaction data for use by the MFP application"/>
</properties>
<step id="batchlet-step">
<batchlet ref="BDIInvokerBatchlet">
<properties>
<property name="bdiProcessFlowUrl" value="#SysOpt.bdiProcessFlowUrl"/>
<property name="bdiProcessFlowCredential" value="#SysOpt.bdiProcessFlowUrlUserAlias"/>
<property name="predicateDS" value="RmsDBDS"/>
<property name="predicateFunction" value="RMS_BATCH_STATUS_SQL.GET_EOW_RUN_SIGNAL"/>
</properties>
</batchlet>
<end on="COMPLETED"/>
</step>
</job>
When the batch job BDI_MFP_TranData_Tx_PF_From_RMS_JOB is executed, a batchlet (BDIInvokerBatchlet) starts the execution flow. It calls a PLSQL function (RMS_BATCH_STATUS_SQL.GET_EOW_RUN_SIGNAL) to ensure the process flow is only executed on an EOW_DATE. If vdate is an EOW_DATE, it invokes a BDI process flow (Trandata_Tx_ProcessFLow_From_RMS) to perform a series of steps to extract, download, and transport the downloaded files to target applications (MFP):
Extractor job (TranData_Tx_Extractor) calls BDI_MFP_SQL. TRAN_DATA_UP function to extract data from RMS view V_BDI_MFP_TRAN_DATA to MFP outbound staging table TRAN_DATA_OUT.
A generic BDI Downloader file creator job writes quantities on order information from the TRAN_DATA_OUT table into a comma-delimited flat file, which will be consumed by MFP. A zero-byte trigger file is also generated to signal that the extract process was successful. Two separate copies of the data file and the trigger file are sent to MFP.
The downloaded data files and trigger files are written to designated MFP location as configured via BDI system options MFP_outboundLocation.
The flat file will contain the following information:
Table 28-20 Flat File
| Field Name | Field Type | Required | Description |
|---|---|---|---|
|
EOW |
Date |
Yes |
Indicates the end of week date that the on order information pertains to. |
|
ITEM |
Varchar2(25) |
Yes |
Transaction level item only. |
|
LOCATION |
Number(10) |
Yes |
Could be a store or warehouse. |
|
LOC_TYPE |
VARCHAR2(1) |
Yes |
Indicates if the location is a store or warehouse - S = Store; W = Warehouse. |
|
CLEAR_IND |
Number(1) |
Yes |
If Y, item/location is currently on clearance. |
|
NET_SALES_REG_UNITS |
NUMBER(12,4) |
Yes |
tran_data_history.units: tran_code = 1 and sales type = R or P |
|
NET_SALES_REG_COST |
NUMBER(20,4) |
Yes |
tran_data_history.total_cost: tran_code = 1 and sales type = R or P |
|
NET_SALES_REG_RETAIL |
NUMBER(20,4) |
Yes |
tran_data_history.total_retail: tran_code = 1 and sales type = R or P |
|
NET_SALES_REG_UNITS_VAT_EXCL |
NUMBER(12,4) |
N/A |
tran_data_history.units: tran_code = 2 and sales type = R or P |
|
NET_SALES_REG_COST_VAT_EXCL |
NUMBER(20,4) |
N/A |
tran_data_history.total_cost: tran_code = 2 and sales type = R or P |
|
NET_SALES_REG_RETAIL_VAT_EXCL |
NUMBER(20,4) |
N/A |
tran_data_history.total_retail: tran_code = 2 and sales type = R or P |
|
RETURNS_REG_UNITS |
NUMBER(12,4) |
N/A |
tran_data_history.units: tran_code = 4 (clear_ind for item/loc = N) |
|
RETURNS_REG_COST |
NUMBER(20,4) |
N/A |
tran_data_history.total_cost: tran_code = 4 (clear_ind for item/loc = N) |
|
RETURNS_REG_RETAIL |
NUMBER(20,4 |
N/A |
tran_data_history.total_retail: tran_code = 4 (clear_ind for item/loc = N) |
|
NET_SALES_CLEAR_UNITS |
NUMBER(12,4) |
N/A |
tran_data_history.units: tran_code = 1 and sales type = C |
|
NET_SALES_CLEAR_COST |
NUMBER(20,4) |
N/A |
tran_data_history.total_cost: tran_code = 1 and sales type = C |
|
NET_SALES_CLEAR_RETAIL |
NUMBER(20,4) |
N/A |
tran_data_history.total_retail: tran_code = 1 and sales type = C |
|
NET_SALES_CLR_UNITS_VAT_EXCL |
NUMBER(12,4) |
N/A |
tran_data_history.units: tran_code = 2 and sales type = C |
|
NET_SALES_CLR_COST_VAT_EXCL |
NUMBER(20,4) |
N/A |
tran_data_history.total_cost: tran_code = 2 and sales type = C |
|
NET_SALES_CLR_RETAIL_VAT_EXCL |
NUMBER(20,4) |
N/A |
tran_data_history.total_retail: tran_code = 2 and sales type = C |
|
RETURNS_CLEAR_UNITS |
NUMBER(20,4) |
N/A |
tran_data_history.units: tran_code = 4 (clear_ind for item/loc = Y) |
|
RETURNS_CLEAR_COST |
NUMBER(20,4) |
N/A |
tran_data_history.total_cost: tran_code = 4 (clear_ind for item/loc = Y) |
|
RETURNS_CLEAR_RETAIL |
NUMBER(20,4) |
N/A |
tran_data_history.total_cost: tran_code = 4 (clear_ind for item/loc = Y) |
|
REG_MARKDOWN_RETAIL |
NUMBER(20,4) |
N/A |
tran_data_history.total_retail: tran_code 13 - tran_code 14 (Markdown Cancel) - tran_code 11 (Markup) |
|
PROMO_MARKDOWN_RETAIL_REG |
NUMBER(20,4) |
N/A |
tran_data_history.total_retail: tran_code = 15 - if the item is not on clearance EOW |
|
PROMO_MARKDOWN_RETAIL_CLEAR |
NUMBER(20,4) |
N/A |
tran_data_history.total_retail: tran_code = 15 - if the item is on clearance EOW |
|
CLEAR_MARKDOWN_RETAIL |
NUMBER(20,4) |
N/A |
tran_data_history.total_retail: tran_code = 16 |
|
WF_MARKDOWN_RETAIL |
NUMBER(20,4) |
N/A |
tran_data_history.total_retail: tran_code = 85 |
|
WF_MARKUP_RETAIL |
NUMBER(20,4) |
N/A |
tran_data_history.total_retail: tran_code = 84 |
|
SHRINK_UNITS |
NUMBER(12,4) |
N/A |
tran_data_history.units: tran_code 22 |
|
SHRINK_COST |
NUMBER(20,4) |
N/A |
tran_data_history.total_cost: tran_code 22 |
|
SHRINK_RETAIL |
NUMBER(20,4) |
N/A |
tran_data_history.total_retail: tran_code 22 |
|
DEAL_INCOME_COST |
NUMBER(20,4) |
N/A |
tran_data_history.total_cost: tran_code 6 & 7 |
|
RECEIPT_UNITS |
NUMBER(12,4) |
N/A |
tran_data_history.units: tran_code = 20 |
|
RECEIPT_COST |
NUMBER(20,4) |
N/A |
tran_data_history.total_cost: tran_code = 20 |
|
RECEIPT_RETAIL |
NUMBER(20,4) |
N/A |
tran_data_history.total_retail: tran_code = 20 |
|
NON_SHRINK_ADJ_UNITS |
NUMBER(12,4) |
N/A |
tran_data_history.units: tran_code = 23 |
|
NON_SHRINK_ADJ_COST |
NUMBER(20,4) |
N/A |
tran_data_history.total_cost: tran_code = 23 |
|
NON_SHRINK_ADJ_RETAIL |
NUMBER(20,4) |
N/A |
tran_data_history.total_retail: tran_code = 23 |
| Module Name | BDI_RDF_UdaItemLov_Fnd_From_RMS_JOB bdi_merch_extract_to_file_wrapper.sh
bdi_rdf_itemuda_extract.ksh |
| Description | Extracts information for LOV type of UDAs to RDF from RMS |
| Functional Area | Foundation |
| Module Type | Integration |
| Module Technology | BDI job, shell scripts |
| Catalog ID | NA |
| Runtime Parameters | ItemHdrAndUdaItemLov_Fnd_ProcessFlow_From_RMS
ItemHdr_Fnd_Extractor UdaItemLov_Fnd_Extractor Database connection, download file location, filename, trigger filename |
RMS extracts LOV type of UDA data to RDF on a weekly basis. It utilizes BDI (Bulk Data Integration) to facilitate the bulk data movement from RMS to RDF.
The batch job BDI_RDF_UdaItemLov_Fnd_From_RMS_JOB is defined in the RMS JOS batch job admin as follows:
<job id="BDI_RDF_UdaItemLov_Fnd_From_RMS_JOB" version="1.0" xmlns="http://xmlns.jcp.org/xml/ns/javaee">
<properties>
<property name="description" value="Extracts UDA item LOV information and writes it out to a flat file for processing by RDF."/>
</properties>
<step id="batchlet-step">
<batchlet ref="BDIInvokerBatchlet">
<properties>
<property name="bdiProcessFlowUrl" value="#SysOpt.bdiProcessFlowUrl"/>
<property name="bdiProcessFlowCredential" value="#SysOpt.bdiProcessFlowUrlUserAlias"/>
<property name="predicateDS" value="RmsDBDS"/>
<property name="predicateFunction" value="RMS_BATCH_STATUS_SQL.GET_EOW_RUN_SIGNAL"/>
</properties>
</batchlet>
<end on="COMPLETED"/>
</step>
</job>
When the batch job BDI_RDF_UdaItemLov_Fnd_From_RMS_JOB is executed, a batchlet (BDIInvokerBatchlet) starts the execution flow. It calls a PLSQL function (RMS_BATCH_STATUS_SQL.GET_EOW_RUN_SIGNAL) to ensure the process flow is only executed on an EOW_DATE. If vdate is an EOW_DATE, it invokes a BDI process flow (ItemHdrAndUdaItemLov_Fnd_ProcessFlow_From_RMS) to perform a series of steps to extract, download, and transport the downloaded files to RDF:
Extractor jobs (ItemHdr_Fnd_Extractor, UdaItemLov_Fnd_Extractor) call respective BDI_ITEM_SQL functions to extract data from RMS tables to BDI outbound staging tables ITEM_HDR_OUT and UDA_ITEM_LOV_OUT.
Downloader file creator job calls the wrapper script, bdi_merch_extract_to_file_wrapper.sh, to set the runtime parameters on environment variables. This script will then call bdi_rdf_itemuda_extract.ksh to write LOV type of UDA information from the ITEM_HDR_OUT and UDA_ITEM_LOV_OUT tables into a comma-delimited flat file, which will be consumed by RDF. A zero-byte trigger file is also generated to signal that the extract process was successful. The data file and the trigger file are then sent to RDF.
Only UDA IDs and values associated to items are extracted.
Only forecasted items will be extracted.
The downloaded data file and trigger file are written to designated RDF locations as configured via BDI system options RDF_outboundLocation.
Table 28-22 Key Tables Affected
| Table | Select | Insert | Update | Delete |
|---|---|---|---|---|
|
ITEM_MASTER |
Yes |
No |
No |
No |
|
CLASS |
Yes |
No |
No |
No |
|
SUBCLASS |
Yes |
No |
No |
No |
|
DIFF_GROUP_HEAD |
Yes |
No |
No |
No |
|
DIFF_IDS |
Yes |
No |
No |
No |
|
SYSTEM_OPTION |
Yes |
No |
No |
No |
|
UDA_ITEM_LOV |
Yes |
No |
No |
No |
|
UDA |
Yes |
No |
No |
No |
|
UDA_VALUES |
Yes |
No |
No |
No |
|
UDA_ITEM_LOV_OUT |
Yes |
Yes |
No |
Yes |
|
ITEM_HDR_OUT |
Yes |
Yes |
No |
Yes |
|
BDI_DWNLDR_IFACE_MOD_DATA_CTL |
Yes |
No |
No |
No |
|
BDI_DWNLDR_IFACE_DATA_CTL |
Yes |
No |
No |
No |
| Module Name | BDI_RPAS_Calendar_Fnd_PF_From_RMS_JOB |
| Description | Extracts calendar information to RPAS from RMS |
| Functional Area | Foundation |
| Module Type | Integration |
| Module Technology | BDI job |
| Catalog ID | NA |
| Runtime Parameters | Calendar_Fnd_ProcessFlow_From_RMS Calendar_Fnd_Extractor |
RMS extracts its calendar data to RPAS (including MFP and RDF) on a weekly basis. It utilizes BDI (Bulk Data Integration) to facilitate the bulk data movement from RMS to MFP and RDF.
The batch job BDI_RPAS_Calendar_Fnd_PF_From_RMS_JOB is defined in the RMS JOS batch job admin as follows:
<job id="BDI_RPAS_Calendar_Fnd_PF_From_RMS_JOB" version="1.0" xmlns="http://xmlns.jcp.org/xml/ns/javaee">
<properties>
<property name="description" value="Extracts calendar information and writes it out to a flat file for processing by both MFP and RDF."/>
</properties>
<step id="batchlet-step">
<batchlet ref="BDIInvokerBatchlet">
<properties>
<property name="bdiProcessFlowUrl" value="#SysOpt.bdiProcessFlowUrl"/>
<property name="bdiProcessFlowCredential" value="#SysOpt.bdiProcessFlowUrlUserAlias"/>
<property name="predicateDS" value="RmsDBDS"/>
<property name="predicateFunction" value="RMS_BATCH_STATUS_SQL.GET_EOW_RUN_SIGNAL"/>
</properties>
</batchlet>
<end on="COMPLETED"/>
</step>
</job>
When the batch job BDI_RPAS_Calendar_Fnd_PF_From_RMS_JOB is executed, a batchlet (BDIInvokerBatchlet) starts the execution flow. It calls a PLSQL function (RMS_BATCH_STATUS_SQL.GET_EOW_RUN_SIGNAL) to ensure the process flow is only executed on an EOW_DATE. If vdate is an EOW_DATE, it invokes a BDI process flow (Calendar_Fnd_ProcessFlow_From_RMS) to perform a series of steps to extract, download, and transport the downloaded files to target applications (MFP and RDF):
Extractor job (Calendar_Fnd_Extractor) calls BDI_FOUNDATION_SQL.CALENDAR_UP function to extract data from RMS view V_BDI_DAY_LEVEL_CALENDAR to BDI outbound staging table CALENDAR_OUT.
A generic BDI Downloader file creator job writes calendar information from the CALENDAR_OUT table into a comma-delimited flat file, which will be consumed by RDF and MFP. A zero-byte trigger file is also generated to signal that the extract process was successful. Two separate copies of the data file and the trigger file are sent to MFP and RDF.
The downloaded data files and trigger files are written to designated MFP and RDF locations as configured via BDI system options MFP_outboundLocation and RDF_outboundLocation.
The flat file will contain the following information:
Table 28-26 Flat File
| Field Name | Field Type | Required | Description |
|---|---|---|---|
|
DAY |
Date |
Yes |
The date from which the 4-5-4 data was derived, in YYYYMMDD format |
|
WEEK |
Date |
Yes |
The end of week date for the day, in YYYYMMDD format |
|
MONTH |
Number(2) |
Yes |
The 4-5-4 month of the year, valid values 1-12 |
|
QUARTER |
Number(1) |
Yes |
The 4-5-4 quarter of the year, valid values 1-4 |
|
HALF |
Number(1) |
Yes |
The 4-5-4 half of the year, valid values are 1 or 2 |
|
YEAR |
Number(4) |
Yes |
The 4-5-4 year |
|
WEEK_OF_YEAR |
Number(2) |
Yes |
The 4-5-4 week of the year, valid values 1-53 |
|
DAY_OF_YEAR |
Number(1) |
Yes |
The day number within the week 1-7 |
| Module Name | BDI_RPAS_CurrConvRates_Fnd_PF_From_RMS_JOB
bdi_merch_extract_to_file_wrapper.sh bdi_rpas_curr_conv_rates_extract.ksh |
| Description | Extracts currency rates information to RPAS from RMS |
| Functional Area | Foundation |
| Module Type | Integration |
| Module Technology | BDI job, shell scripts |
| Catalog ID | NA |
| Runtime Parameters | CurrConvRates_Fnd_ProcessFlow_From_RMS
CurrConvRates_Fnd_Extractor Database connection, download file location, filename, trigger filename |
RMS extracts its currency rates data to MFP and RDF on a weekly basis. It utilizes BDI (Bulk Data Integration) to facilitate the bulk data movement from RMS to MFP and RDF.
The batch job BDI_RPAS_CurrConvRates_Fnd_PF_From_RMS_JOB is defined in the RMS JOS batch job admin as follows:
<job id="BDI_RPAS_CurrConvRates_Fnd_PF_From_RMS_JOB" version="1.0" xmlns="http://xmlns.jcp.org/xml/ns/javaee">
<properties>
<property name="description" value="Extracts currency conversion rate information and writes it out to a flat file for processing by both MFP and RDF."/>
</properties>
<step id="batchlet-step">
<batchlet ref="BDIInvokerBatchlet">
<properties>
<property name="bdiProcessFlowUrl" value="#SysOpt.bdiProcessFlowUrl"/>
<property name="bdiProcessFlowCredential" value="#SysOpt.bdiProcessFlowUrlUserAlias"/>
<property name="predicateDS" value="RmsDBDS"/>
<property name="predicateFunction" value="RMS_BATCH_STATUS_SQL.GET_EOW_RUN_SIGNAL"/>
</properties>
</batchlet>
<end on="COMPLETED"/>
</step>
</job>
When the batch job BDI_RPAS_CurrConvRates_Fnd_PF_From_RMS_JOB is executed, a batchlet (BDIInvokerBatchlet) starts the execution flow. It calls a PLSQL function (RMS_BATCH_STATUS_SQL.GET_EOW_RUN_SIGNAL) to ensure the process flow is only executed on an EOW_DATE. If vdate is an EOW_DATE, it invokes a BDI process flow (CurrConvRates_Fnd_ProcessFlow_From_RMS) to perform a series of steps to extract, download, and transport the downloaded files to target applications (MFP and RDF):
Extractor job (CurrConvRates_Fnd_Extractor) calls BDI_FOUNDATION_SQL.CURR_CONV_RATES_UP function to extract data from RMS view MV_CURRENCY_CONVERSION_RATES to BDI outbound staging table CURR_CONV_RATES_OUT.
Only the currencies for which stores and warehouses exist in RMS will be extracted.
Either consolidated or operational rates will be included based on RMS system options (consolidation_ind).
Downloader file creator job calls the wrapper script, bdi_merch_extract_to_file_wrapper.sh, to set the runtime parameters on environment variables. This script will then call bdi_rpas_curr_conv_rates_extract.ksh to write currency rates information from the CURR_CONV_RATES_OUT table into a comma-delimited flat file, which will be consumed by RDF and MFP. A zero-byte trigger file is also generated to signal that the extract process was successful. Two separate copies of the data file and the trigger file are sent to MFP and RDF.
The downloaded data files and trigger files are written to designated MFP and RDF locations as configured via BDI system options MFP_outboundLocation and RDF_outboundLocation.
The flat file will contain the following information:
Table 28-29 Flat File
| Field Name | Field Type | Required | Description |
|---|---|---|---|
|
EFFECTIVE_DATE |
Date |
Yes |
Holds the next effective date of the exchange rate for the currencies and the exchange type |
|
FROM_CURRENCY_CODE |
Char(3) |
Yes |
Holds the convert from currency code. |
|
TO_CURRENCY_CODE |
Char(3) |
Yes |
Holds the convert to currency code. |
|
EXCHANGE_TYPE |
Char(1) |
Yes |
Identifies the type of exchange rate. |
|
EXCHANGE_RATE |
Number(20,10) |
Yes |
Contains the exchange rate between the from and to currencies for the specified exchange type on the next effective date. It is expressed in the to-currency. |
| Module Name | BDI_RPAS_MerchHier_Fnd_PF_From_RMS_JOB
bdi_merch_extract_to_file_wrapper.sh bdi_rpas_merchhier_extract.ksh |
| Description | Extracts merchandise hierarchy and item information to RPAS from RMS |
| Functional Area | Foundation |
| Module Type | Integration |
| Module Technology | BDI job, shell scripts |
| Catalog ID | NA |
| Runtime Parameters | ItemHdrAndMerchHier_Fnd_ProcessFlow_From_RMS
ItemHdr_Fnd_Extractor Database connection, download file location, filename, trigger filename |
RMS extracts its merchandise hierarchy and item data to MFP and RDF on a weekly basis. It utilizes BDI (Bulk Data Integration) to facilitate the bulk data movement from RMS to MFP and RDF.
The batch job BDI_RPAS_MerchHier_Fnd_PF_From_RMS_JOB is defined in the RMS JOS batch job admin as follows:
<job id="BDI_RPAS_MerchHier_Fnd_PF_From_RMS_JOB" version="1.0" xmlns="http://xmlns.jcp.org/xml/ns/javaee">
<properties>
<property name="description" value="Extracts Merch Hierarchy information and writes it out to a flat file for processing by both MFP and RDF."/>
</properties>
<step id="batchlet-step">
<batchlet ref="BDIInvokerBatchlet">
<properties>
<property name="bdiProcessFlowUrl" value="#SysOpt.bdiProcessFlowUrl"/>
<property name="bdiProcessFlowCredential" value="#SysOpt.bdiProcessFlowUrlUserAlias"/>
<property name="predicateDS" value="RmsDBDS"/>
<property name="predicateFunction" value="RMS_BATCH_STATUS_SQL.GET_EOW_RUN_SIGNAL"/>
</properties>
</batchlet>
<end on="COMPLETED"/>
</step>
</job>
When the batch job BDI_RPAS_MerchHier_Fnd_PF_From_RMS_JOB is executed, a batchlet (BDIInvokerBatchlet) starts the execution flow. It calls a PLSQL function (RMS_BATCH_STATUS_SQL.GET_EOW_RUN_SIGNAL) to ensure the process flow is only executed on an EOW_DATE. If vdate is an EOW_DATE, it invokes a BDI process flow (ItemHdrAndMerchHier_Fnd_ProcessFlow_From_RMS) to perform a series of steps to extract, download, and transport the downloaded files to target applications (MFP and RDF):
Extractor jobs (MerchHier_Fnd_Extractor, ItemHdr_Fnd_Extractor) call respective BDI_MERCH_SQL and BDI_ITEM_SQL functions to extract data from RMS tables to BDI outbound staging tables MERCH_HIER_OUT and ITEM_HDR_OUT.
Downloader file creator job calls the wrapper script, bdi_merch_extract_to_file_wrapper.sh, to set the runtime parameters on environment variables. This script will then call bdi_rpas_merchhier_extract.ksh to write merchandise hierarchy and item information from the MERCH_HIER_OUT and ITEM_HDR_OUT tables into a comma-delimited flat file, which will be consumed by RDF and MFP. A zero-byte trigger file is also generated to signal that the extract process was successful. Two separate copies of the data file and the trigger file are sent to MFP and RDF.
Merchandise Hierarchy information extracted are those related to items.
Records for inventoried, sellable, non-pack transaction items will be extracted.
The downloaded data files and trigger files are written to designated MFP and RDF locations as configured via BDI system options MFP_outboundLocation and RDF_outboundLocation.
Table 28-31 Key Tables Affected
| Table | Select | Insert | Update | Delete |
|---|---|---|---|---|
|
COMPHEAD |
Yes |
No |
No |
No |
|
DIVISION |
Yes |
No |
No |
No |
|
GROUPS |
Yes |
No |
No |
No |
|
DEPS |
Yes |
No |
No |
No |
|
CLASS |
Yes |
No |
No |
No |
|
SUBCLASS |
Yes |
No |
No |
No |
|
ITEM_MASTER |
Yes |
No |
No |
No |
|
DIFF_GROUP_HEAD |
Yes |
No |
No |
No |
|
DIFF_IDS |
Yes |
No |
No |
No |
|
SYSTEM_OPTIONS |
Yes |
No |
No |
No |
|
MERCH_HIER_OUT |
Yes |
Yes |
No |
Yes |
|
ITEM_HDR_OUT |
Yes |
Yes |
No |
Yes |
|
BDI_DWNLDR_IFACE_MOD_DATA_CTL |
Yes |
No |
No |
No |
|
BDI_DWNLDR_IFACE_DATA_CTL |
Yes |
No |
No |
No |
The flat file will contain the following information:
Table 28-32 Flat File
| Field Name | Field Type | Required | Description |
|---|---|---|---|
|
ITEM |
Char(25) |
Yes |
N/A |
|
ITEM_DESC |
Char(250) |
Yes |
N/A |
|
ITEM_PARENT_DIFF |
Char(30) |
No |
Concatenated value consisting of item parent ID with the letter 'A' at the end. |
|
ITEM_PARENT_DIFF_DESC |
Char(250) |
No |
Description of the item parent diff. Concatenated value consisting of the item parent description and the diff IDs for all diffs associated to the parent which is marked as aggregate. |
|
ITEM_PARENT |
Char(25) |
No |
N/A |
|
ITEM_PARENT_DESC |
Char(250) |
No |
N/A |
|
SUBCLASS_ID |
Number(10) |
Yes |
Unique subclass ID |
|
SUBCLASS_NAME |
Char(120) |
Yes |
Concatenated value consisting of subclass number with name. |
|
CLASS_ID |
Number(10) |
Yes |
Unique class ID |
|
CLASS_NAME |
Char(120) |
Yes |
Concatenated value consisting of class number with name. |
|
DEPT |
Number(4) |
Yes |
N/A |
|
DEPT_NAME |
Char(120) |
Yes |
N/A |
|
GROUP_NO |
Number(4) |
Yes |
N/A |
|
GROUP_NAME |
Char(120) |
Yes |
N/A |
|
DIVISION |
Number(4) |
Yes |
N/A |
|
DIV_NAME |
Char(120) |
Yes |
N/A |
|
COMPANY |
Number(4) |
Yes |
N/A |
|
COMPANY_NAME |
Char(120) |
Yes |
N/A |
|
FORECAST_IND |
Char(1) |
Yes |
N/A |
| Module Name | BDI_RPAS_OrgHier_Fnd_PF_From_RMS_JOB
bdi_merch_extract_to_file_wrapper.sh bdi_rpas_orghier_extract.ksh |
| Description | Extracts org hierarchy information to RPAS from RMS |
| Functional Area | Foundation |
| Module Type | Integration |
| Module Technology | BDI job, shell scripts |
| Catalog ID | NA |
| Runtime Parameters | StoreAndWhAndOrgHier_Fnd_ProcessFlow_From_RMS
Store_Fnd_Extractor Wh_Fnd_Extractor OrgHier_Fnd_Extractor Database connection, download file location, filename, trigger filename |
RMS extracts its organization hierarchy data to MFP and RDF on a weekly basis. It utilizes BDI (Bulk Data Integration) to facilitate the bulk data movement from RMS to MFP and RDF.
The batch job BDI_RPAS_OrgHier_Fnd_PF_From_RMS_JOB is defined in the RMS JOS batch job admin as follows:
<job id="BDI_RPAS_OrgHier_Fnd_PF_From_RMS_JOB" version="1.0" xmlns="http://xmlns.jcp.org/xml/ns/javaee">
<properties>
<property name="description" value="Extracts Org Hierarchy information and writes it out to a flat file for processing by both MFP and RDF."/>
</properties>
<step id="batchlet-step">
<batchlet ref="BDIInvokerBatchlet">
<properties>
<property name="bdiProcessFlowUrl" value="#SysOpt.bdiProcessFlowUrl"/>
<property name="bdiProcessFlowCredential" value="#SysOpt.bdiProcessFlowUrlUserAlias"/>
<property name="predicateDS" value="RmsDBDS"/>
<property name="predicateFunction" value="RMS_BATCH_STATUS_SQL.GET_EOW_RUN_SIGNAL"/>
</properties>
</batchlet>
<end on="COMPLETED"/>
</step>
</job>
When the batch job BDI_RPAS_OrgHier_Fnd_PF_From_RMS_JOB is executed, a batchlet (BDIInvokerBatchlet) starts the execution flow. It calls a PLSQL function (RMS_BATCH_STATUS_SQL.GET_EOW_RUN_SIGNAL) to ensure the process flow is only executed on an EOW_DATE. If vdate is an EOW_DATE, it invokes a BDI process flow (StoreAndWhAndOrgHier_Fnd_ProcessFlow_From_RMS) to perform a series of steps to extract, download, and transport the downloaded files to target applications (MFP and RDF):
Extractor jobs (Store_Fnd_Extractor, Wh_Fnd_Extractor, OrgHier_Fnd_Extractor) call respective BDI_ORG_SQL functions to extract data from RMS tables to BDI outbound staging tables ORG_HIER_OUT, STORE_OUT, and WH_OUT.
Downloader file creator job calls the wrapper script, bdi_merch_extract_to_file_wrapper.sh, to set the runtime parameters on environment variables. This script will then call bdi_rpas_orghier_extract.ksh to write organization hierarchy information from the ORG_HIER_OUT, STORE_OUT, and WH_OUT tables into a comma-delimited flat file, which will be consumed by RDF and MFP. A zero-byte trigger file is also generated to signal that the extract process was successful. Two separate copies of the data file and the trigger file are sent to MFP and RDF.
The downloaded data files and trigger files are written to designated MFP and RDF locations as configured via BDI system options MFP_outboundLocation and RDF_outboundLocation.
Table 28-34 Key Tables Affected
| Table | Select | Insert | Update | Delete |
|---|---|---|---|---|
|
STORE |
Yes |
No |
No |
No |
|
WH |
Yes |
No |
No |
No |
|
AREA |
Yes |
No |
No |
No |
|
CHAIN |
Yes |
No |
No |
No |
|
DISTRICT |
Yes |
No |
No |
No |
|
REGION |
Yes |
No |
No |
No |
|
COMPHEAD |
Yes |
No |
No |
No |
|
CHANNELS |
Yes |
No |
No |
No |
|
CODE_DETAIL |
Yes |
No |
No |
No |
|
STORE_FORMAT |
Yes |
No |
No |
No |
|
LANG |
Yes |
No |
No |
No |
|
VAT_REGION |
Yes |
No |
No |
No |
|
TSFZONE |
Yes |
No |
No |
No |
|
ORG_HIER_OUT |
Yes |
Yes |
No |
Yes |
|
STORE_OUT |
Yes |
Yes |
No |
Yes |
|
WH_OUT |
Yes |
Yes |
No |
Yes |
|
BDI_DWNLDR_IFACE_MOD_DATA_CTL |
Yes |
No |
No |
No |
|
BDI_DWNLDR_IFACE_DATA_CTL |
Yes |
No |
No |
No |
The flat file will contain the following information:
Table 28-35 Flat File
| Field Name | Field Type | Required | Description |
|---|---|---|---|
|
LOCATION |
Number(10) |
Yes |
Store or warehouse ID |
|
LOC_NAME |
Char(150) |
Yes |
Store or warehouse name |
|
DISTRICT |
Number(10) |
Yes |
For warehouses, repeat the warehouse ID |
|
DISTRICT_NAME |
Char(120) |
Yes |
For warehouses, repeat the warehouse name |
|
REGION |
Number(10) |
Yes |
For warehouses, repeat the warehouse ID |
|
REGION_NAME |
Char(120) |
Yes |
For warehouses, repeat the warehouse name |
|
AREA |
Number(10) |
Yes |
For warehouses, repeat the warehouse ID |
|
AREA_NAME |
Char(120) |
Yes |
For warehouses, repeat the warehouse name |
|
CHAIN |
Number(10) |
Yes |
For warehouses, repeat the warehouse ID |
|
CHAIN_NAME |
Char(120) |
Yes |
For warehouses, repeat the warehouse name |
|
COMPANY |
Number(4) |
Yes |
Company ID |
|
COMPANY_NAME |
Char(120) |
Yes |
Company name |
|
COMPANY_CURRENCY |
Char(3) |
Yes |
Currency code |
|
LOC_TYPE |
Char(1) |
Yes |
'S' for store, 'W' for warehouse |
|
LOC_TYPE_NAME |
Char(120) |
Yes |
Store or Warehouse depending on location type |
|
PHYSICAL_WH |
Number(10) |
Yes |
Physical warehouse for warehouse, repeat store ID for store |
|
PHYSICAL_WH_NAME |
Char(120) |
Yes |
Physical warehouse name for warehouse, repeat store name for stores |
|
CHANNEL_ID |
Number(4) |
Yes |
Will be used as fulfillment type alternate in MFP |
|
CHANNEL_NAME |
Char(120) |
Yes |
Channel name |
| Module Name | BDI_RPAS_Store_Fnd_PF_From_RMS_JOB
bdi_merch_extract_to_file_wrapper.sh bdi_rpas_store_extract.ksh |
| Description | Extracts store information to RPAS from RMS |
| Functional Area | Foundation |
| Module Type | Integration |
| Module Technology | BDI, shell scripts |
| Catalog ID | NA |
| Runtime Parameters | Store_Fnd_ProcessFlow_From_RMS
Store_Fnd_Extractor Database connection, download file location, filename, trigger filename |
RMS extracts its store data to MFP and RDF on a weekly basis. It utilizes BDI (Bulk Data Integration) to facilitate the bulk data movement from RMS to MFP and RDF.
The batch job BDI_RPAS_Store_Fnd_PF_From_RMS_JOB is defined in the RMS JOS batch job admin as follows:
<job id="BDI_RPAS_Store_Fnd_PF_From_RMS_JOB" version="1.0" xmlns="http://xmlns.jcp.org/xml/ns/javaee">
<properties>
<property name="description" value="Extracts store information and writes it out to a flat file for processing by both MFP and RDF."/>
</properties>
<step id="batchlet-step">
<batchlet ref="BDIInvokerBatchlet">
<properties>
<property name="bdiProcessFlowUrl" value="#SysOpt.bdiProcessFlowUrl"/>
<property name="bdiProcessFlowCredential" value="#SysOpt.bdiProcessFlowUrlUserAlias"/>
<property name="predicateDS" value="RmsDBDS"/>
<property name="predicateFunction" value="RMS_BATCH_STATUS_SQL.GET_EOW_RUN_SIGNAL"/>
</properties>
</batchlet>
<end on="COMPLETED"/>
</step>
</job>
When the batch job BDI_RPAS_Store_Fnd_PF_From_RMS_JOB is executed, a batchlet (BDIInvokerBatchlet) starts the execution flow. It calls a PLSQL function (RMS_BATCH_STATUS_SQL.GET_EOW_RUN_SIGNAL) to ensure the process flow is only executed on an EOW_DATE. If vdate is an EOW_DATE, it invokes a BDI process flow (Store_Fnd_ProcessFlow_From_RMS) to perform a series of steps to extract, download, and transport the downloaded files to target applications (MFP and RDF):
Extractor job (Store_Fnd_Extractor) calls BDI_ORG_SQL.STORE_UP function to extract data from RMS tables to BDI outbound staging table STORE_OUT.
Downloader file creator job calls the wrapper script, bdi_merch_extract_to_file_wrapper.sh, to set the runtime parameters on environment variables. This script will then call bdi_rpas_store_extract.ksh to write store information from the STORE_OUT table into a comma-delimited flat file, which will be consumed by RDF and MFP. A zero-byte trigger file is also generated to signal that the extract process was successful. Two separate copies of the data file and the trigger file are sent to MFP and RDF.
The downloaded data files and trigger files are written to designated MFP and RDF locations as configured via BDI system options MFP_outboundLocation and RDF_outboundLocation.
Table 28-37 Key Tables Affected
| Table | Select | Insert | Update | Delete |
|---|---|---|---|---|
|
STORE |
Yes |
No |
No |
No |
|
CHANNELS |
Yes |
No |
No |
No |
|
CODE_DETAIL |
Yes |
No |
No |
No |
|
STORE_FORMAT |
Yes |
No |
No |
No |
|
LANG |
Yes |
No |
No |
No |
|
VAT_REGION |
Yes |
No |
No |
No |
|
TSFZONE |
Yes |
No |
No |
No |
|
STORE_OUT |
Yes |
Yes |
No |
Yes |
|
BDI_DWNLDR_IFACE_MOD_DATA_CTL |
Yes |
No |
No |
No |
|
BDI_DWNLDR_IFACE_DATA_CTL |
Yes |
No |
No |
No |
The flat file will contain the following information:
Table 28-38 Flat File
| Field Name | Field Type | Required | Description |
|---|---|---|---|
|
STORE |
Number(10) |
Yes |
Store ID |
|
STORE_NAME |
Char(150) |
Yes |
Store name |
|
DISTRICT |
Number(10) |
Yes |
District in which the store is a member |
|
STORE_CLOSE_DATE |
DATE |
No |
Date on which the store closed |
|
STORE_OPEN_DATE |
DATE |
Yes |
Date on which the store opened |
|
REMODEL_DATE |
DATE |
No |
Date on which the store was last remodeled |
|
STORE_CLASS |
Char(1) |
Yes |
Class of which the store is a member |
|
STORE_CLASS_DESCRIPTION |
Char(250) |
Yes |
Store class description |
|
STORE_FORMAT |
Number(4) |
No |
Store format |
|
STORE_FORMAT_NAME |
Char(60) |
No |
Store format name |
|
CURRENCY |
Char(3) |
Yes |
Currency under which the store operates |
|
STORE_TYPE |
Char(6) |
Yes |
Indicates whether the store is a franchise or company store |
|
STOCKHOLDING_IND |
Char(1) |
Yes |
Indicates whether the store can hold stock |
| Module Name | BDI_RDF_StockOut_Tx_PF_From_RMS_JOB |
| Description | Extracts out of stock item location information to RDF from RMS |
| Functional Area | Foundation |
| Module Type | Integration |
| Module Technology | BDI job |
| Catalog ID | NA |
| Runtime Parameters | StockOut_Tx_ProcessFlow_From_RMS StockOut_Tx_Extractor |
RMS extracts items which are out of stock for use by RDF on a weekly basis. It utilizes BDI (Bulk Data Integration) to facilitate the bulk data movement from RMS to RDF.
The batch job BDI_RDF_StockOut_Tx_PF_From_RMS_JOB is defined in the RMS JOS batch job admin as follows:
<job id="BDI_RDF_StockOut_Tx_PF_From_RMS_JOB" version="1.0" xmlns="http://xmlns.jcp.org/xml/ns/javaee">
<properties>
<property name="description" value="Extracts information for items which are out of stock for use by the RDF application"/>
</properties>
<step id="batchlet-step">
<batchlet ref="BDIInvokerBatchlet">
<properties>
<property name="bdiProcessFlowUrl" value="#SysOpt.bdiProcessFlowUrl"/>
<property name="bdiProcessFlowCredential" value="#SysOpt.bdiProcessFlowUrlUserAlias"/>
<property name="predicateDS" value="RmsDBDS"/>
<property name="predicateFunction" value="RMS_BATCH_STATUS_SQL.GET_EOW_RUN_SIGNAL"/>
</properties>
</batchlet>
<end on="COMPLETED"/>
</step>
</job>
When the batch job BDI_RDF_StockOut_Tx_PF_From_RMS_JOB is executed, a batchlet (BDIInvokerBatchlet) starts the execution flow. It calls a PLSQL function (RMS_BATCH_STATUS_SQL.GET_EOW_RUN_SIGNAL) to ensure the process flow is only executed on an EOW_DATE. If vdate is an EOW_DATE, it invokes a BDI process flow (StockOut_Tx_ProcessFlow_From_RMS) to perform a series of steps to extract, download, and transport the downloaded files to target applications (RDF):
Extractor job (StockOut_Tx_ExtractorJob) calls BDI_RDF_SQL. STOCKOUT_UP function to extract data from RMS view V_BDI_RDF_STOCKOUT to RDF outbound staging table STOCKOUT_OUT.
A generic BDI Downloader file creator job writes out of stock item information from the STOCKOUT_OUT table into a comma-delimited flat file, which will be consumed by RDF. A zero-byte trigger file is also generated to signal that the extract process was successful. Two separate copies of the data file and the trigger file are sent to RDF.
The downloaded data files and trigger files are written to designated RDF location as configured via BDI system options RDF_outboundLocation.
The flat file will contain the following information:
Table 28-41 Flat File
| Field Name | Field Type | Required | Description |
|---|---|---|---|
|
ITEM |
Varchar2(25) |
Yes |
Item that is out of stock at the store. |
|
STORE |
Number(10) |
Yes |
Store that is out of stock for the item. |
|
EOW_DATE |
Date |
Yes |
Indicates the end of week date for which the data applies. |
|
OUT_OF_STOCK |
Number(1) |
Yes |
Default to 1 to indicate out of stock. Only item/locs that are actually out of stock should be included in the file. So the value will always be 1. |
| Module Name | BDI_RDF_WeeklySales_Tx_PF_From_RMS_JOB |
| Description | Extracts weekly sales information to RDF from RMS |
| Functional Area | Foundation |
| Module Type | Integration |
| Module Technology | BDI job |
| Catalog ID | NA |
| Runtime Parameters | WeeklySales_Tx_ProcessFlow_From_RMS
WeeklySales_Tx_Extractor |
RMS extracts weekly sales for use by RDF on a weekly basis. It utilizes BDI (Bulk Data Integration) to facilitate the bulk data movement from RMS to RDF.
The batch job BDI_RDF_WeeklySales_Tx_PF_From_RMS_JOB is defined in the RMS JOS batch job admin as follows:
<job id="BDI_RDF_WeeklySales_Tx_PF_From_RMS_JOB" version="1.0" xmlns="http://xmlns.jcp.org/xml/ns/javaee">
<properties>
<property name="description" value="Extracts weekly sales information for use by the RDF application"/>
</properties>
<step id="batchlet-step">
<batchlet ref="BDIInvokerBatchlet">
<properties>
<property name="bdiProcessFlowUrl" value="#SysOpt.bdiProcessFlowUrl"/>
<property name="bdiProcessFlowCredential" value="#SysOpt.bdiProcessFlowUrlUserAlias"/>
<property name="predicateDS" value="RmsDBDS"/>
<property name="predicateFunction" value="RMS_BATCH_STATUS_SQL.GET_EOW_RUN_SIGNAL"/>
</properties>
</batchlet>
<end on="COMPLETED"/>
</step>
</job>
When the batch job BDI_RDF_WeeklySales_Tx_PF_From_RMS_JOB is executed, a batchlet (BDIInvokerBatchlet) starts the execution flow. It calls a PLSQL function (RMS_BATCH_STATUS_SQL.GET_EOW_RUN_SIGNAL) to ensure the process flow is only executed on an EOW_DATE. If vdate is an EOW_DATE, it invokes a BDI process flow (WeeklySales_Tx_ProcessFlow_From_RMS) to perform a series of steps to extract, download, and transport the downloaded files to target applications (RDF):
Extractor job (WeeklySales_Tx_ExtractorJob) calls BDI_RDF_SQL. WEEKLY_SALES_UP function to extract data from RMS view V_BDI_RDF_WEEKLY_SALES to RDF outbound staging table WEEKLY_SALES_OUT.
A generic BDI Downloader file creator job writes weekly sales information from the WEEKLY_SALES_OUT table into a comma-delimited flat file, which will be consumed by RDF. A zero-byte trigger file is also generated to signal that the extract process was successful. Two separate copies of the data file and the trigger file are sent to RDF.
The downloaded data files and trigger files are written to designated RDF location as configured via BDI system options RDF_outboundLocation.
The flat file will contain the following information:
Table 28-44 Flat File
| Field Name | Field Type | Required | Description |
|---|---|---|---|
|
ITEM |
Varchar2(25) |
Yes |
Indicates the item. |
|
STORE |
Number(10) |
Yes |
Indicates the store. |
|
EOW_DATE |
Date |
Yes |
Indicates the end of week date for which the data applies. |
|
SALES_UNITS |
Number(12,4) |
No |
This value will be the total sales units for the item/location for the week. |
|
SALES_TYPE |
Varchar2(1) |
Yes |
Indicates the sales type i.e. R (Regular Sales), P (Promotional Sales) or C (Clearance Sales). |
| Module Name | soutdnld.pc |
| Description | Download of Out Of Stock Items |
| Functional Area | Integration - Planning |
| Module Type | Integration |
| Module Technology | ProC |
| Catalog ID | RMS115 |
| Runtime Parameters | NA |
A forecasting interface requires a notification whenever an item stock on hand at a store goes to zero or below that level. This soutdnld program loops through the item/store stock on hand table and outputs any item/store combinations that have a stock out condition to an output file. This output file will then be sent to the forecasting system.
Table 28-45 Scheduling Constraints
| Schedule Information | Description |
|---|---|
|
Frequency |
Daily |
|
Scheduling Considerations |
Processing that updates the stock levels should be completed before running this program |
|
Pre-Processing |
NA |
|
Post-Processing |
NA |
|
Threading Scheme |
The forecasting system requires that the output files generated by this program be grouped by domain number. To accommodate this requirement, soutdnld.pc should be threaded by a domain |
The logical unit of work for this program is set at item/location level. Table based restart/recovery is used. The commit_max_ctr field should be set to prevent excessive rollback space usage, and to reduce the overhead of the file I/O.
Since threads are determined by the value of the domain ID, the RESTART_PROGRAM_STATUS table should contain a row for each domain ID. The thread value of the domain ID should be used as the thread value on this table. The total number of domains/number of threads should be equal to the number of rows on the RESTART_PROGRAM_STATUS table. This value must be entered into the restart_control table num_threads field. Note that anytime a new domain is created, an additional row should be added to the RESTART_PROGRAM_STATUS table with the thread value equal to the domain ID and the restart_control table num_threads field must be incremented to equal the total number of domains.
| Integration Type | Download from RMS |
| File Name | sout%d.dat, where %d is substitued with the department id |
| Integration Contract | IntCon000036 |
The output filename is hardcoded to sout%d.dat where %d is substitued with the department id. Each run of the program can produce multiple output files, one for each department.
Table 28-47 Output File Layout
| Field Name | Field Type | Default Value | Description |
|---|---|---|---|
|
Date |
Char(8) |
Period.vdate |
The date of the stockout in YYYYMMDD format |
|
Store |
Number(10) |
NA |
The store at which the sku encountered the stockout - left justified with trailing blanks |
|
Item |
Char(25) |
NA |
The item that encountered the stockout - left justified with trailing blanks |
| Module Name | ftmednld.pc |
| Description | Download of Time Hierarchy for Planning Systems |
| Functional Area | Integration - Planning |
| Module Type | Integration |
| Module Technology | ProC |
| Catalog ID | RMS15 |
The FTMEDNLD.PC module downloads the RMS calendar (year, half, quarter, month, week, day, and date) in the 454-calendar format. The download consists of the entire calendar in the RMS. This program accounts for a fiscal year that could be different from the standard year in the CALENDAR table.
As part of the implementation, the extracted flat file needs to be transferred to a location where the planning system (with its transformation script) can access it.
Due to the relatively small amount of processing this program performs; restart recovery will not be used. The calls to retek_init() and retek_close() are used in the program only for logging purposes (to prevent double-runs).
| Integration Type | Download from RMS |
| File Name | rmse_rpas_clndmstr.dat |
| Integration Contract | IntCon000035 |
The file outputted will be named rmse_rpas_clndmstr.dat.
Table 28-50 Output File Layout
| Field Name | Field Type | Description |
|---|---|---|
|
Year |
Number(4) |
The 4-5-4 year |
|
Half |
Number(1) |
The 4-5-4 half of the year, valid values are 1 or 2 |
|
Quarter |
Number(1) |
The 4-5-4 quarter of the year, valid values 1-4 |
|
Month |
Number(2) |
The 4-5-4 month of the year, valid values 1-12 |
|
Week |
Number(2) |
The 4-5-4 week of the year, valid values 1-53 |
|
Day |
Number(1) |
The 4-5-4 day of the current week, valid values 1-7 |
|
Date |
Date |
The date from which the 4-5-4 data was derived, in YYYYMMDD format |
| Module Name | onictext.pc |
| Description | On Inter-Company Transfer Exhibit |
| Functional Area | Integration - Planning |
| Module Type | Integration |
| Module Technology | ProC |
| Catalog ID | RMS128 |
This program calculates the value in cost and retail of items that are on intercompany transfers. It calculates the on order cost and retail for all approved intercompany transfers that have exp_dc_eow_dates less than or equal to the planning horizon date. Once the program has calculated the costs and retails, they are inserted into the ON_ORDER_TEMP table.
This program takes in a small input file. The input file determines if the run should be for weekly or historical data.
The logical unit of work is unique transfer number. Each time the record counter equals the maximum recommended commit number the retek_commit function is called. The program is multithreaded using v_restart_transfer view.
Table 28-52 Key Tables Affected
| Table | Select | Insert | Update | Delete |
|---|---|---|---|---|
|
STORE |
Yes |
No |
No |
No |
|
WH |
Yes |
No |
No |
No |
|
TSF_ITEM_COST |
Yes |
No |
No |
No |
|
TSFHEAD |
Yes |
No |
No |
No |
|
ITEM_MASTER |
Yes |
No |
No |
No |
|
ITEM_LOC_SOH |
Yes |
No |
No |
No |
|
ITEM_LOC |
Yes |
No |
No |
No |
|
TSF_XFORM |
Yes |
No |
No |
No |
|
TSF_XFORM_DETAIL |
Yes |
No |
No |
No |
|
PERIOD |
Yes |
No |
No |
No |
|
SYSTEM_OPTIONS |
Yes |
No |
No |
No |
|
ON_ORDER_TEMP |
Yes |
No |
No |
No |
| Module Name | onordext.pc |
| Description | On Order Extract |
| Functional Area | Integration - Planning |
| Module Type | Integration |
| Module Technology | ProC |
| Catalog ID | RMS129 |
This program calculates the value in cost and retail of items that are on order for the department/class/subclass/location level. This program is the first step in the stock ledger download process to RPAS. It calculates the on order cost and retail for all approved orders that have not before dates less than or equal to the planning horizon date. Once the program has calculated the costs and retails, they are inserted into the ON_ORDER_TEMP table. Customer Order POs are filtered out and will not affect the on order quantity that is sent to RPAS.
The logical unit of work is unique order number. Each time the record counter equals the maximum recommended commit number the retek_commit function is called.
It is also split into two sections item and pack. First all items on orders are processed. When they are done a pack 'flag' is turned on and the restart order is reset. Then all the packs on order are processed. So all orders are considered twice, once for items and once for packs.
Table 28-56 Key Tables Affected
| Table | Select | Insert | Update | Delete |
|---|---|---|---|---|
|
ORDHEAD |
Yes |
No |
No |
No |
|
ORDLOC |
Yes |
No |
No |
No |
|
ORDSKU |
Yes |
No |
No |
No |
|
ALLOC_HEADER |
Yes |
No |
No |
No |
|
ALLOC_DETAIL |
Yes |
No |
No |
No |
|
ITEM_MASTER |
Yes |
No |
No |
No |
|
ITEM_SUPP_COUNTRY_LOC |
Yes |
No |
No |
No |
|
PERIOD |
Yes |
No |
No |
No |
|
SYSTEM_OPTIONS |
Yes |
No |
No |
No |
|
CLASS |
Yes |
No |
No |
No |
|
ON_ORDER_TEMP |
No |
Yes |
No |
No |
|
DEFAULT_TAX_TYPE |
Yes |
No |
No |
No |
|
VAT_REGION |
Yes |
No |
No |
No |
|
WH |
Yes |
No |
No |
No |
|
VAT_ITEM |
Yes |
No |
No |
No |
|
ITEM_LOC |
Yes |
No |
No |
No |
|
ITEM_LOC_SOH |
Yes |
No |
No |
No |
|
ITEM_SUPPLIER |
Yes |
No |
No |
No |
|
UOM_CLASS |
Yes |
No |
No |
No |
|
UOM_CONVERSION |
Yes |
No |
No |
No |
|
ITEM_SUPP_UOM |
Yes |
No |
No |
No |
| Module Name | gradupld.pc |
| Description | Upload of Store Grade Classifications from RPAS |
| Functional Area | Integration - RPAS |
| Module Type | Integration |
| Module Technology | ProC |
| Catalog ID | RMS133 |
| Runtime Parameter | NA |
The store grade upload module is designed to load forecasting-driven store grades into RMS. Data will be loaded into the STORE_GRADE_GROUP, STORE_GRADE and STORE_GRADE_STORE tables.
Oracle Retail standard restart/recovery is used. The commit_max_ctr field should be set to prevent excessive rollback space usage, and to reduce the overhead of file I/O. The recommended commit counter setting is 1000 records (subject to change based on implementation).
| Integration Type | Upload to RMS |
| File Name | Determined by runtime parameter |
| Integration Contract | IntCon000037 |
The input filename is not fixed; the input filename is determined by a runtime parameter. Records rejected by the import process are written to a reject file. The reject filename is not fixed; the reject filename is determined by a runtime parameter.
The input file should be sorted by grade group description, grade ID, and grade store. The grade group description should be unique by grade group ID.
Table 28-61 Input File Layout
| Record Name | Field Name | Field Type | Default Value | Description |
|---|---|---|---|---|
|
FHEAD |
Record type |
Char(5) |
FHEAD |
Record Identifier |
|
Line ID |
Number(10) |
0000000001 |
Line Sequence Identifier |
|
|
File name |
Char(5) |
GRADU |
File Identifier |
|
|
FDETL |
Record type |
Char(5) |
FDETL |
Record Identifier |
|
Line id |
Number(10) |
NA |
Line Sequence Identifier |
|
|
Grade Group ID |
Number(8) |
NA |
Valid Grade Group ID |
|
|
Grade Group |
Char(120) |
NA |
Valid Grade Group |
|
|
Grade store |
Number(10) |
NA |
Valid Grade store |
|
|
Grade ID |
Number(10) |
NA |
Valid Grade ID |
|
|
Grade name |
Char(120) |
NA |
Valid Grade name |
|
|
FTAIL |
Record Type |
Char(5) |
FTAIL |
Record Identifier |
|
Line id |
Number(10) |
NA |
Line Sequence Identifier |
|
|
Line Total |
Number(10) |
NA |
Total number of FDETL lines in the file. |
| Module Name | ONORDDNLD.PC |
| Description | On Order Download to Financial Planning |
| Functional Area | Integration - Planning |
| Module Type | Integration |
| Module Technology | ProC |
| Catalog ID | RMS12 |
This program sends on order cost, retail and quantity at the item/location/week level to a planning system. The values are used by a financial planning system to generate OTB numbers that are interfaced back into the RMS.
This program creates three output files: one for orders, one for intercompany transfer sending locations and one for intercompany transfer receiving locations.
Table 28-62 Scheduling Constraints
| Schedule Information | Description |
|---|---|
|
Frequency |
Daily |
|
Scheduling Considerations |
This program is run towards end of the batch schedule after the ONORDEXT.PC (on order extract) and ONICTEXT.PC |
|
Pre-Processing |
onordext.pc, onictext.pc |
|
Post-Processing |
NA |
|
Threading Scheme |
Threaded by location |
The logical unit of work for this program is set at item/location/eow_date level. Table based restart/recovery must be used. The commit_max_ctr field should be set to prevent excessive rollback space usage, and to reduce the overhead of file I/O. The recommended commit counter setting is 1000 records (subject to change based on implementation).
| Integration Type | Download from RMS |
| File Name | The filename is hardcoded to onorder.dat%d, onictsend.dat%d, or onictrcv.dat%d where %d is substituted with the domain ID |
| Integration Contract | IntCon000027 |
Each run of the program can produce multiple output files, one for each domain.
Table 28-64 Output File Layout
| Field Name | Field Type | Description |
|---|---|---|
|
ITEM |
Char(25) |
RMS ITEM Identifier. |
|
Location (Store / WH) |
NUMBER(20) |
Store or WH identifier. |
|
Location Type ('S' or 'W') |
Char(1) |
Indicates if the location is a store or a warehouse: S - if the location is a store, W - If the location is a warehouse. |
|
OTB EOW date |
DATE (8) |
The OTB End of week date. |
|
On Order Retail |
NUMBER(25,4) |
Total on order retail for the item/location/EOW date. |
|
On order Cost |
NUMBER(25,4) |
Total on order cost for the item/location/EOW date. |
|
On Order Quantity |
NUMBER(17,4) |
Total on order Quantity for the item/location/EOW date. |
