The AIP system interfaces with the merchandising system, the forecasting system, and any other external system that provides data in the predetermined file format. This chapter provides information on how AIP interfaces with various RMS versions and RDF. For a complete list of supported RMS versions, see the Oracle Retail Advanced Inventory Planning Installation Guide.
During AIP installation, the RMS-AIP transform scripts and output schema files were installed to a directory specified by the user, as the Dir to store RMS transform files. This location is referred to as $RMS_AIP_TRANSFORM for this section. Refer to the Oracle Retail Advanced Inventory Planning Installation Guide for more information about the installation details.
The AIP installation includes a separate set of transformation scripts for interfacing with RMS 10, 11, and 13.0/13.1. These were installed to
$RMS_AIP_TRANSFORM/k_shell_scripts. The schema files in $RMS_AIP_TRANSFORM/aip_schema_dir are used for interfacing with any version of RMS. The following documentation describes the differences in the interfacing process for each version of RMS.
The overall process of interfacing RMS with AIP begins with generation of the RMS RETL extracts. A separate set of RMS extract scripts and schema files control this generation. These scripts and schema are not included in the AIP installation.
After generating the RMS RETL extracts, the RMS-AIP transformation scripts convert the RMS RETL extracts into RPAS loadable format. There are two sets of schema files: one which matches the formats of the RMS RETL extract files, and a second which matches the formats of the RPAS-loadable files.
Location: $RMS_AIP_TRANSFORM/k_shell_scripts and $RPAS_HOME/bin
The Transform Interface Scripts are the Korn shell scripts used to drive the process for transforming the RMS RETL extract files into AIP RPAS domain-loadable files.
The $RMS_AIP_TRANSFORM/k_shell_scripts directory's contents should have been copied to $RPAS_HOME/bin during installation.
The execution of these scripts is controlled by running the master script:
aip_t_master_rms10.ksh for RMS 10.x
aip_t_master_rms11.ksh for RMS 11.x
aip_t_master_rms13.ksh for RMS 13.1/13.0
aip_t_master_rms13.2.ksh for RMS 13.2
aip_t_master_rms14.0.ksh for RMS 14.0
These scripts are run before running the AIP RPAS batch.
The execution of these scripts is controlled by running the master script, aip_t_master_rms14.0.ksh for RMS 14.0 transforms.
These scripts are run before running the AIP RPAS batch.
For RMS 14.0, $RPAS_HOME/bin must contain the following scripts:
aip_t_master_rms14.0.ksh
aipt_clnd.awk, aipt_clnd.ksh, days_from_cycle_start_date.pl
aipt_delete_input_files.ksh
aipt_future_delivery_rms14.0.ksh
aipt_item_rms14.0.ksh
aipt_move.ksh
aipt_orghier_rms14.0.ksh
aipt_rename.ksh
aipt_sr0_dayslsld_rms14.0.ksh
aipt_str_prd_life_rms14.0.ksh
aipt_sub_item_rms14.0.ksh
The execution of these scripts is controlled by running the master script, aip_t_master_rms13.2.ksh for RMS 13.2 transforms.
These scripts are run before running the AIP RPAS batch.
For RMS 13.2, $RPAS_HOME/bin must contain the following scripts:
aip_t_master_rms13.2.ksh
aipt_clnd.awk, aipt_clnd.ksh, days_from_cycle_start_date.pl
aipt_delete_input_files.ksh
aipt_future_delivery_rms13.2.ksh
aipt_item_rms13.2.ksh
aipt_move.ksh
aipt_orghier_rms13.2.ksh
aipt_rename.ksh
aipt_sr0_dayslsld_rms13.2.ksh
aipt_str_prd_life_rms13.2.ksh
aipt_sub_item_rms13.2.ksh
The execution of these scripts is controlled by running the master script, aip_t_master_rms13.ksh for RMS 13.1/13.0 transforms.
These scripts are run before running the AIP RPAS batch.
For RMS 13.1/13.0, $RPAS_HOME/bin must contain the following scripts:
aip_t_master_rms13.ksh
aipt_clnd.awk, aipt_clnd.ksh, days_from_cycle_start_date.pl
aipt_delete_input_files.ksh
aipt_future_delivery_rms13.ksh
aipt_item_rms13.ksh
aipt_move.ksh
aipt_orghier_rms13.ksh
aipt_pad.ksh, aipt_pad_splr.awk, aipt_pad_whse.awk
aipt_rename.ksh
aipt_sr0_dayslsld_rms13.ksh
aipt_str_prd_life_rms13.ksh
aipt_sub_item_rms13.ksh
The execution of these scripts is controlled by running the master script,
aip_t_master_rms11.ksh for RMS 11 transforms. These scripts are run before the AIP RPAS batch is run.
For RMS 11, $RPAS_HOME/bin must contain the following scripts:
aip_t_master_rms11.ksh
aipt_clnd.awk, aipt_clnd.ksh, days_from_cycle_start_date.pl
aipt_delete_input_files.ksh
aipt_future_delivery_rms11.ksh
aipt_item_rms11.ksh
aipt_move.ksh
aipt_orghier_rms11.ksh
aipt_pad.ksh, aipt_pad_splr.awk, aipt_pad_whse.awk
aipt_rename.ksh
aipt_sr0_dayslsld_rms11.ksh
aipt_str_prd_life_rms11.ksh
aipt_sub_item_rms11.ksh
The execution of these scripts is controlled by running the aip_t_master_rms10.ksh for RMS 10 transforms. These scripts are run before the AIP RPAS batch is run.
For RMS 10, $RPAS_HOME/bin must contain the following scripts:
aip_t_master_rms10.ksh
aipt_clnd.awk, aipt_clnd.ksh, days_from_cycle_start_date.pl
aipt_delete_input_files.ksh
aipt_future_delivery_rms10.ksh
aipt_item_rms10.ksh
aipt_move.ksh
aipt_orghier_rms10.ksh
aipt_pad.ksh, aipt_pad_splr.awk, aipt_pad_whse.awk
aipt_rename.ksh
aipt_sr0_dayslsld_rms10.ksh
aipt_str_prd_life_rms10.ksh
aipt_sub_item_rms10.ksh
Location: The schema files matching the RMS RETL extracts are provided by the RMS installation. These files are owned by RMS and are not included with the AIP Package.
Input schema files are the schema files which are required by the Transform Interface scripts to read the RETL extracts from RMS.
These files are used as output schema by the RMS RETL extract scripts.
For RMS 14.0, 13.2, 13.1/13.0, and RMS 11, the $RMS_ SCHEMA_DIR directory (refer to aip_env_rpas.sh in the Oracle Retail Advanced Inventory Planning Implementation Guide) must contain the following input schema files from the RMS installation:
Note: While the file names for these schema files do not differ among RMS versions 14.0, 13.2, 13.1/13.0, and RMS 11, the contents of the files vary among the four versions. Ensure you copy in the correct version of the RMS output schema into $RMS_SCHEMA_DIR. |
rmse_aip_alloc_in_well.schema
rmse_aip_dmx_bndprdasc.schema
rmse_aip_future_delivery_alloc.schema
rmse_aip_future_delivery_order.schema
rmse_aip_future_delivery_tsf.schema
rmse_aip_item_loc_traits.schema
rmse_aip_item_master.schema
rmse_aip_item_retail.schema
rmse_aip_item_supp_country.schema
rmse_aip_merchhier.schema
rmse_aip_orghier.schema
rmse_aip_purged_item.schema
rmse_aip_store.schema
rmse_aip_substitute_items.schema
rmse_aip_tsf_in_well.schema
rmse_aip_wh.schema
rmse_aip_wh_dat.schema
rmse_rpas_daily_sales.schema
For RMS 10, the $RMS_SCHEMA_DIR directory (refer to aip_env_rpas.sh in the Oracle Retail Advanced Inventory Planning Implementation Guide) must contain the following input schema files from the RMS installation:
rmse_aip_item_master.schema
rmse_alloc_in_well.schema
rmse_daily_sales.schema
rmse_dmx_bndprdasc.schema
rmse_future_delivery_alloc.schema
rmse_future_delivery_order.schema
rmse_future_delivery_tsf.schema
rmse_item_loc_traits.schema
rmse_item_retail.schema
rmse_item_supp_country.schema
rmse_merchhier.schema
rmse_orghier.schema
rmse_purged_item.schema
rmse_store.schema
rmse_substitute_items.schema
rmse_tsf_in_well.schema
rmse_wh.schema
rmse_whse1.schema
Location: $RMS_AIP_TRANSFORM/aip_schema_dir
Output Schema files are the schema files which are required by the Transform Interface scripts to write the AIP loads/feeds. These files are owned by AIP and should have been unpacked to $RMS_AIP_TRANSFORM/aip_schema_dir during AIP installation.
These output schema files are the same regardless of which version of RMS is interfaced with AIP.
The $AIP_SCHEMA_DIR (refer to aip_env_rpas.sh in the Oracle Retail Advanced Inventory Planning Implementation Guide) directory must contain the following output schema files from the AIP installation:
aipt_dm0_pmsendsrc.schema
aipt_dm0_pmsstasrc.schema
aipt_dmx_dscdt_.schema
aipt_dmx_vadprdasc.schema
aipt_item.schema
aipt_loc.schema
aipt_sr0_dayslsld.schema
aipt_sr0_it_.schema
aipt_sr0_oo_.schema
aipt_str_prd_life.schema
aipt_wr1_aiw.schema
aipt_wr1_it_.schema
aipt_wr1_oo_.schema
aipt_wr1_tiw.schema
Location: RMS server
The RETL Extracts from RMS are used as AIP loads/feeds. Following are the four categories of RETL Extracts:
Table 3-1 Description of RETL Extracts by Group
Note: The four sets of files must be copied from the RMS server to the AIP server, into the $RAW_RMS_DATA_DIR directory. |
The following sections list the RMS 14.0, 13.2, and 13.1/13.0 RETL Extracts for each group described in Table 3-1.
Following is the list of RETL Extracts that are used by the RMS 14.0, 13.2, and 13.1/13.0-AIP Interface Transform scripts to generate a new set of AIP RPAS loads/feeds.
date_format_preference.txt
dmx_bndprdasc.txt
last_day_of_week.txt
rmse_aip_alloc_in_well.dat
rmse_aip_future_delivery_alloc.dat
rmse_aip_future_delivery_order.dat
rmse_aip_future_delivery_tsf.dat
rmse_aip_item_loc_traits.dat
rmse_aip_item_master.dat
rmse_aip_item_retail.dat
rmse_aip_item_supp_country.dat
rmse_aip_merchhier.dat
rmse_aip_orghier.dat
rmse_aip_purged_item.dat
rmse_aip_store.dat
rmse_aip_substitute_items.dat
rmse_aip_tsf_in_well.dat
rmse_aip_wh.dat
rmse_aip_wh.txt
rmse_aip_wh_type.txt
rmse_rpas_clndmstr.dat
rmse_rpas_daily_sales.dat
Note: dmx_bndprdasc.txt is used by the transformation process, but is also a direct feed into AIP RPAS. |
The following are the RETL extracts used by RMS 14.0, 13.2, and 13.1/13.0that do not need to be transformed by AIP
splr.txt
dmx_dirspl.txt
dmx_prdspllks.txt
sr0_curinv_[1..n].txt
wr1_curinv.txt
Note: As previously shown, the sr0_curinv data feed may be partitioned. For example: sr0_curinv_1.txt, sr0_curinv_2.txt. The data always has at least one partition, namely sr0_curinv_1.txt. AIP RPAS batch steps combine any partitions before loading the data into the AIP domain. |
Following are the RMS 14.0, 13.2, and 13.1/13.0 RETL extracts which are not used by AIP RPAS batch but are used by AIP Oracle batch.
closed_order.txt
received_qty.txt
Following are the RMS 14.0, 13.2, and 13.1/13.0 RETL extracts which at this time are not used by AIP.
rmse_aip_item_supp_country_reject_ord_mult.txt
rmse_aip_suppliers.dat
The following sections list the RMS 11 RETL Extracts for each group described in Table 3-1.
Following is the list of RETL Extracts that are used by the RMS 11-AIP Interface Transform scripts to generate a new set of AIP RPAS loads/feeds.
date_format_preference.txt
dmx_bndprdasc.txt
last_day_of_week.txt
rmse_aip_alloc_in_well.dat
rmse_aip_future_delivery_alloc.dat
rmse_aip_future_delivery_order.dat
rmse_aip_future_delivery_tsf.dat
rmse_aip_item_loc_traits.dat
rmse_aip_item_master.dat
rmse_aip_item_retail.dat
rmse_aip_item_supp_country.dat
rmse_aip_merchhier.dat
rmse_aip_orghier.dat
rmse_aip_purged_item.dat
rmse_aip_store.dat
rmse_aip_substitute_items.dat
rmse_aip_tsf_in_well.dat
rmse_aip_wh.dat
rmse_aip_wh.txt
rmse_aip_wh_type.txt
rmse_clndmstr.dat
rmse_rpas_daily_sales.dat
Note: dmx_bndprdasc.txt is used by the transformation process, but is also a direct feed into AIP RPAS. |
The following are the RETL extracts used by RMS 11 that do not need to be transformed by AIP.
splr.txt
dmx_dirspl.txt
dmx_prdspllks.txt
sr0_curinv_[1..n].txt
wr1_curinv.txt
Note: As previously shown, the sr0_curinv data feed may be partitioned. For example: sr0_curinv_1.txt, sr0_curinv_2.txt. The data always has at least one partition, namely sr0_curinv_1.txt. AIP RPAS batch steps combine any partitions before loading the data into the AIP domain. |
Following are the RMS 11 RETL extracts which are not used by AIP RPAS batch but are used by AIP Oracle batch.
closed_order.txt
received_qty.txt
Following are the RMS 11 RETL extracts which at this time are not used by AIP.
rmse_aip_item_supp_country_reject_ord_mult.txt
rmse_aip_suppliers.dat
The following sections list the RMS 10 RETL Extracts for each group described in Table 3-1.
Following is the list of RETL Extracts that are used by the RMS 10-AIP Interface Transform scripts to generate a new set of AIP RPAS loads/feeds.
date_format_preference.txt
dmx_bndprdasc.txt
last_day_of_week.txt
rmse_aip_item_master.dat
rmse_aip_wh.txt
rmse_alloc_in_well.dat
rmse_clndmstr.dat
rmse_daily_sales.dat
rmse_future_delivery_alloc.dat
rmse_future_delivery_order.dat
rmse_future_delivery_tsf.dat
rmse_item_loc_traits.dat
rmse_item_retail.dat
rmse_item_supp_country.dat
rmse_merchhier.dat
rmse_orghier.dat
rmse_purged_item.dat
rmse_store.dat
rmse_substitute_items.dat
rmse_tsf_in_well.dat
rmse_wh.dat
rmse_wh_type.txt
Note: dmx_bndprdasc.txt is used by the transformation process, but is also a direct feed into AIP RPAS. |
The following are the RMS 10 RETL extracts that do not need to be transformed by AIP.
splr.txt
dmx_dirspl.txt
dmx_prdspllks.txt
sr0_curinv_[1..n].txt
wr1_curinv.txt
Note: As previously shown, the sr0_curinv data feed may be partitioned. For example: sr0_curinv_1.txt, sr0_curinv_2.txt. The data always has at least one partition, namely sr0_curinv_1.txt. AIP RPAS batch steps combine any partitions before loading the data into the AIP domain. |
Following are the RMS 10 RETL extracts which are not used by AIP RPAS batch but are used by AIP Oracle batch.
closed_order.txt
received_qty.txt
Following are the RMS 10 RETL extracts, which for this release are not used by AIP.
rmse_aip_item_supp_country_reject_ord_mult.txt
rmse_aip_suppliers.dat
This section provides information for running the transform scripts on AIP Oracle and AIP RPAS.
The following steps describe how to run the transform scripts for AIP RPAS.
Copy Group 1 and Group 2 extracts from the RMS server to the
$RAW_RMS_DATA_DIR directory on the AIP server. This process is not part of the Transformation process or AIP batch. It must be scheduled by the client.
Copy the RMS RETL Extract schema files for the version of RMS you are running from the RMS installation to the directory specified by the $RMS_SCHEMA_DIR in $RPAS_HOME/bin/aip_env_rpas.sh. Note that previous versions of AIP utilized separate variable names for different versions of RMS. This version of AIP uses a single variable: $RMS_SCHEMA_DIR.
Copy the $RMS_AIP_TRANSFORM/aip_schema_dir files from the AIP installation into the $AIP_SCHEMA_DIR. This needs to be done only once per AIP install/patch release.
Optionally modify the clnd.prefixes and clnd.day_of_week configuration files, located in the AIP RPAS domain, in $AIPDOMAIN/interface/config/hier, in order to customize the calendar dimension prefixes as well as day of week names.
Run the scripts according to the following table:
When extracts are from: | Then run: | |
---|---|---|
RMS 14.0 | aip_t_master_rms14.0.ksh | |
RMS 13.2 | RMS 13.2 | aip_t_master_rms13.2.ksh | |
RMS 13.1/13.0 | aip_t_master_rms13.ksh | |
RMS 11 | aip_t_master_rms11.ksh | |
RMS 10 | aip_t_master_rms10.ksh |
The location of these scripts is $RPAS_HOME/bin. Either script executes the appropriate RMS-AIP Interface Transform scripts.
Once this script has successfully completed, the following new AIP loads/feeds are created:
clnd.csv.dat | loc.txt | wr1_aiw.txt | |
dm0_pmsendsrc.txt | sr0_dayslsld.txt | wr1_it_.txt | |
dm0_pmsstasrc.txt | sr0_it_.txt | wr1_oo_.txt | |
dmx_dscdt_.txt | sr0_oo_.txt | wr1_tiw.txt | |
dmx_vadprdasc.txt | sr0_prdlfe.txt | wh_type.txt | |
item.txt | whse.txt |
After the transforms scripts create the new files, there is logic in the scripts to move all files required by AIP RPAS into $INTERFACE_RMS_DIR/input (defined in aip_constants_rpas.sh.) This is the location where the files are processed by AIP RPAS batch. In addition, there is logic in the scripts (see
aipt_delete_input_files.ksh) to remove the raw RMS data from the
$RAW_RMS_DATA_DIR directory which are not needed by the AIP RPAS domain.
The file clnd.csv.dat is moved to $INTERFACE_RMS_DIR/input and
$PURGE_IMPORT_HIER_DIR.
The client must schedule a batch job to copy Group 3 extracts from the RMS server to the AIP Oracle server location defined by $ONL_INBOUND_DIR in the
aip_env_online.sh file. The suffixes for each of the two files (closed_order.txt and received_qty.txt) must be renamed to .dat
, to create closed_order.dat and
received_qty.dat.
The cron_import.sh script does not FTP or copy these two data files to the DM Online server, nor does it uncompress, or untar any package (for example, om.tar.Z) containing these files. Clients can still use the om.tar.Z file. However, they are required to tar, compress, ftp, uncompress, and untar by using a batch scheduler.
Note: AIP also accepts the OM file rmse_order_purge.txt in this location. However, this file is not critical to AIP—it can be configured as optional—and must be generated from a custom RMS script. |
At this point, the RMS-AIP transformation is complete.
AIP does not provide transformation scripts to format data files from RDF. The data files are expected to arrive in an AIP loadable format. AIP does not provide any script to transfer the RDF data into AIP. You need to have a job scheduled to transfer the files from the RDF server to the AIP RPAS server.
This batch job must copy or FTP the forecast data from the RDF server location to the AIP location, $AIPDOMAIN/interface/forecast.
The following table describes the forecast data files that are loaded from the forecasting system into AIP.
Input File Name | Description |
---|---|
iprdfdtdaltv.txt | WRP RDF Alert |
sr0_rdfdtdmsk.txt | RDF Detailed Alert Masks |
sr0_fcterrlvl1.txt | Store Weekly Demand Forecast Error |
sr0_fcterrlvl2.txt | Store Weekly Demand Forecast Error |
sr0_rdfdtdcnt.txt | RDF Detail Alert Count |
sr0_frclvl1_[1..n].txt | Store Approved RDF Forecast Level 1 |
sr0_frclvl2_[1..n].txt | Store Approved RDF Forecast Level 2 |
Once the files are loaded onto the AIP RPAS platform, the AIP RPAS batch script processes the files. The check_load_forecast_data.sh wrapper script is executed to verify that all required files are present before proceeding to load the data into the AIP measures.
The AIP Order Management releases data into the staging tables.
The polling thread runs EJB at certain time intervals.
EJB's stateless Session Beans polls data from the staging table and publishes messages to RIB.
RMS uses RIB to receive messages published by AIP.
Figure 3-1 shows the AIP to RMS process flow.
There are five types of messages:
Message Type | Description |
---|---|
XORDERCRE | Create Purchase Order |
XORDERDTLCRE | Create Purchase Order Detail |
XORDERMOD | Modify Purchase Order |
XORDERDTLMOD | Modify Purchase Order Detail |
XTSFCRE | Create Transfer |
The Oracle Retail Integration Bus (RIB) is a near real-time data synchronization solution used by AIP for publishing orders to RMS. Order publication begins with the order release batch adding the affected order to the appropriate message family queue staging table, and then marking each message with a sequence number. AIP publishes two sets of order messages to the RIB: Purchase Orders and Transfers. RMS subscribes to the RIB messages and inserts the orders into the appropriate RMS Purchase Order and Transfer tables.
A polling operation in the servlet triggers the message creation. The polling is performed by two threads:
One for the PO_MFQUEUE staging table
One for the TSF_MFQUEUE staging table
The polling is controlled by the configuration settings in the main.properties file.
The order period count defines the number of time intervals that are to be used. An order period count of 0 indicates that no orders are released. If the order period count is 0, no threads are started.
The time interval defines the amount of time for which the threads sleep. A thread does not go to sleep until less than the maximum number of allowable messages is processed in a given call to the publisher (OrderSenderBean). Publishing less than the maximum allowable messages indicates that all orders on the staging table (at the time it was queried) have been processed. Any orders added to the staging table afterward, are processed the next time the thread wakes up and the publisher is invoked.
For each order period count greater than zero, an order period start and order period end must be added to the properties file. When the thread wakes up and the current time falls between the start and end of any of the intervals (up to X intervals, where X is the order period count), the thread calls the publication procedure. If desired, various time intervals can be created to manage the publication of orders by forcing the threads to poll the staging tables only between certain time periods.
The publisher is an Enterprise Java Session Bean named OrderSenderBean. Its checkAndPublish method queries the staging table and the base order tables to get the message details. The publisher also ensures that the messages are published to the RIB, in the correct order.
Once the message payload is built by the OrderSenderBean, the RIB message publisher takes the payload and wraps it with an envelope used by the RIB infrastructure.
The purchase order publication messages are in the XOrder message family. In AIP, this message family processes the staged orders on the PO_MFQUEUE table. There are four purchase order message types used by AIP:
All four message types use XOrderDesc.dtd.
This message type indicates that a brand new purchase order is being sent to RMS. The orders are sent to RMS in an A (Approved) status. This message type is inserted into PO_MFQUEUE in three different circumstances:
The purchase order was released by the batch, or you chose to release the purchase order in the OM Order Maintenance screen.
You created a new purchase order in the OM Order Create screen.
In the OM Order Maintenance screen, you chose to move a purchase order delivery date, or destination, or both, and also generate a new order number.
This message type indicates that a new line item is being added to the purchase order after the order was externally communicated. This message type is inserted into PO_MFQUEUE when you have moved the purchase order destination and chosen to retain the existing order number, and the destination does not already exist on the order for that item.
This message type indicates that a modification was made to the overall purchase order details (header level information). This message type is inserted into PO_MFQUEUE in the following circumstances:
You have moved the purchase order delivery date and chosen to retain the existing order number.
You have canceled all ordered quantities of all items on the purchase order. The total order quantity for the entire purchase order is zero. The purchase order is sent to RMS with a C (Canceled) status.
This message type indicates that a modification was made to the purchase order line items after the order was externally communicated. This message type is inserted into PO_MFQUEUE when you perform various actions in the OM Order Maintenance screen:
You modify the order quantity of a purchase order that is not closed.
You chose to move a purchase order line item to a new destination, and also retain the order number. If the move-to destination already exists on the order, a message is written to the staging table to increase the quantity at the move-to location.
Note: Only one message can be inserted for the move-to destination for a particular purchase order. This is either an XORDERDTLCRE if the destination is new, or, XORDERDTLMOD if the SKU is already being delivered to the move-to destination. |
The order quantity of the move from destination must be decremented to equal the received quantity. A message is staged for the move from destination.
The transfer publication messages are in the XTsf message family. In AIP, this message family processes the staged orders on the TSF_MFQUEUE table. There is one transfer message type used by AIP. It uses XTsfDesc.dtd.
The contingency orders in OM give the planners a view of the expected future orders and also serve as backup in the event that new overnight orders cannot be produced from AIP replenishment batch. Since the contingency orders are yesterday's view of today's orders they are very close to the orders that would have likely been produced if today's run of the overnight replenishment batch had completed.
Contingency orders may be available to be released to the RMS in the event that AIP batch cannot produce an order plan, or the data imports into AIP Oracle cannot be completed. The contingency orders, sometimes referred to as yesterday's (forecast) orders, are orders that were generated as forecast orders during the previous batch run. During a normal batch run, yesterday's forecast orders that had not met their release lead time, and had not been released early, are re-planned to ensure the order quantities reflect the latest forecast and inventory information. At the end of the AIP RPAS batch run, the new orders to be release today along with some of the new forecast orders are exported from AIP RPAS to AIP Oracle. During the AIP RPAS replenishment batch calculation of the new order plan, AIP Oracle (OM) still has yesterday's forecast orders in the database. These orders remain in the Oracle database until the import scripts have been run to load the new orders from AIP RPAS.
It is important to understand that when following the contingency order steps, the contingency orders are a replacement for the orders that would normally be produced in the replenishment batch run for release today. When the batch run is complete, the orders must not be released or executed.
The following tables provide a list of the related Purchase Order and Transfer files and what orders are contained in each file.
Table 3-2 Store Orders Purchase Order and Transfer Files
Store Orders | |
---|---|
strsplrord.dat |
This file contains store Purchase Orders to be released today. It also contains all Purchase Orders forecasted for the entire planning horizon. The release date in the file indicates whether the order is to be released today, or whether it is a forecast order. Purchase Orders with a release date greater than today are forecast orders. Data in this file is first loaded into interface_store_orders table and then copied into store_order table during the load process. |
strwhord.dat |
This file contains store Transfers to be released today. The release date in the file equals today. Data in this file is first loaded into interface_store_transfers table during load and then copied into store_order table during the load process. |
strsplrord.dat1 |
This file contains the forecasted store Purchase Orders with an expected release date of tomorrow. |
strwhord.dat1 |
This file contains the forecasted store Transfers with an expected release date of tomorrow. |
Table 3-3 Warehouse Orders Purchase Order and Transfer files
Warehouse Orders (Non-contents Orders) | |
---|---|
vendor_to_wh_order.dat |
This file contains into-warehouse Purchase Orders to be released today. It also contains all Purchase Orders forecasted for the entire planning horizon. Data in this file is first loaded into warehouse_purchase_order table through i_non_contents_order table during load and then copied into non_contents_order table during merge (that runs before release) process. |
wh_to_wh_transfer.dat |
This file contains into-warehouse transfers to be released today. It also contains all Transfers forecasted for the entire planning horizon. Data in this file is first loaded into i_non_contents_transfer table during load process. Transfers with release date of today are moved (not copied) into non_contents_order table during release process while transfers with future release dates are copied (not moved) into non_contents_order table during post-release. |
Your operations to perform depend on the point of failure. For your selected failure point, be sure to read and understand all steps before taking action.
Note: The following steps listed will release contingency orders include running cron_release_store_order.sh and cron_release_non_contents_order.sh from cron_release.sh. These are regularly schedule batch scripts that release the orders to be executed. They simply identify all into-store or into-warehouse orders in the Oracle database that have met their lead time.These scripts must not be run a second time upon successful completion of AIP replenishment batch, otherwise, the system is likely to double order. |
If AIP RPAS batch fails before completion of send_scrp_measures_to_online.sh no new RPAS order extracts are available for import into AIP Oracle.
Load Contingency Into-Store Transfers
Perform the following steps to load contingency into-store transfers:
In the Oracle schema, navigate to $ONL_INBOUND_DIR.
Add an extension, such as today's date, to strwhord.dat in order to prevent the file from being re-loaded into the Oracle table.
For example, if today's date is 18-January-2015, rename the file to strsplrord.dat.20151801.
Rename strwhord.dat1 to strwhord.dat.
Navigate to $INTEGRATION_HOME.
Execute script cron_import_order.sh with parameters -o transfer -d store. This loads the contingency store transfers found in the strwhord.dat file.
No action is needed to load any other contingency orders. The contingency store purchase orders and contingency warehouse purchase orders and transfers were loaded during the previous run of cron_import_order.sh.
Release Remaining Orders That Have Met Their Lead Time
Perform the following steps to release remaining orders that have met their lead time:
Run cron_release.sh to release today's contingency store purchase orders and transfers.
Run cron_release.sh to release today's contingency warehouse purchase orders and transfers.
Note: If failure occurs during send_scrp_measures_to_online.sh, some of the export files may have been generated. If you can verify that some of the files (strsplrord.dat, strwhord.dat, vendor_to_wh_order.dat, wh_to_wh_transfer.dat) have been completely extracted successfully, they should be manually moved to the Oracle database and manually loaded. If strwhord.dat is manually loaded, skip steps 1 through 5 in "Load Contingency Into-Store Transfers" and perform steps 1 and 2 in "Release Remaining Orders That Have Met Their Lead Time". |
During the run of cron_import_order.sh while loading strsplrord.dat (scripts/import/ord_imp_store_ord_po_in.sh).
If the error is returned by the subscript ord_imp_store_ord_po_in.sh, the contingency purchase orders might have already been deleted in order to prepare the database to import the new purchase order plan.
Manually delete any orders from the STORE_ORDER table that was partially loaded as a result of executing ord_imp_store_ord_po_in.sh. These orders can be identified as the orders that are in status U, release_date = VDATE, order number IS NULL and source_type = V.
Navigate to $ONL_INBOUND_DIR. Make a backup of strsplrord.dat1 by renaming it strsplrord.dat1bak. This is restored at the end of the contingency process.
Make a backup of strsplrord.dat by renaming it strsplrord.datbak.
Navigate to $BSA_ARCHIVE_DIR. Locate the srp.tar.Z file archived with yesterday's date. Extract the strsplrord.dat1 file and copy it to $ONL_INBOUND_DIR.
Note: Information about Batch Script Architecture (BSA) previously found in this guide is now in the Oracle Retail Planning Batch Script Architecture (BSA) Implementation Guide. |
Navigate to $ONL_INBOUND_DIR and rename strsplrord.dat1 to strsplrord.dat.
Navigate to $INTEGRATION_HOME. Execute: cron_import_order.sh-o purchase -d store.
Release Orders That Have Met Their Lead Time
Perform the following steps to release orders that have met their lead time:
Navigate to $INTEGRATION_HOME and execute cron_release.sh to release store purchase order.
Restore backup files.
Navigate to $ONL_INBOUND_DIR. Remove strsplrord.dat. Rename/move strsplrord.datbak to strsplrord.dat. Rename strsplrord.dat1bak to strsplrord.dat1.
Note: This process only reloaded one day's worth of purchase orders. In the event that the Corrupt Data File process is needed in tomorrow's batch run, no contingency purchase orders are available.It is also important to note that the contingency file (.dat1) contains any forecasted purchase orders that were released early. If any purchase orders that are scheduled for release today are executed early (during the previous Online day), a duplicate order is released today. |
During the run of cron_import_order.sh while loading strwhord.dat (scripts/import/ord_imp_store_ord_tsf_in.sh):
Manually delete any orders from STORE_ORDER table that were partially loaded as a result of executing ord_imp_store_ord_tsf_in.sh. These orders can be identified as the orders that are in status U, release_date = VDATE, release_wave IS NULL, order number IS NULL and source_type = W.
Navigate to $ONL_INBOUND_DIR. Make a backup of strwhord.dat1 by renaming it strwhord.dat1bak. This is restored at the end of the contingency process.
Make a backup of strwhord.dat by renaming it strwhord.datbak.
Navigate to $BSA_ARCHIVE_DIR. Locate the srp.tar.Z file archived with yesterday's date. Extract the strwhord.dat1 file and copy it to $ONL_INBOUND_DIR.
Navigate to $ONL_INBOUND_DIR and rename strwhord.dat1 to strwhord.dat.
Navigate to $INTEGRATION_HOME. Execute cron_import_order.sh -o transfer -d store. This loads the contingency transfers produced yesterday.
Release Orders That Have Met Their Lead Time
Perform the following steps to release orders that have met their lead time:
Navigate to $INTEGRATION_HOME and execute cron_release.sh to release store transfer orders. Restore Backup Files
Navigate to $ONL_INBOUND_DIR. Remove strwhord.dat. Rename/move strwhord.datbak to strwhord.dat. Rename strwhord.dat1bak to strwhord.dat1.
This failure point can happen during the run of cron_import_order.sh (load) while loading vendor_to_wh_order.dat (scripts/import/ord_imp_non_cont_ord_fcst_in.sh) into warehouse_purchase_order table.
If the error was technical in nature and can be fixed, and the interface table i_non_contents_order_forecast still has the data, then rerunning the procedure retl_load.import_wh_purchase_order should be attempted to load the orders.
No contingency file is available in the AIP release. The vendor_to_wh_order.dat file archived in yesterday's srp.tar.Z contains contingency orders. However, it also contains the orders that were released yesterday. The orders which were released yesterday must be deleted from the file before it can be reloaded (including any orders that were released early.)
During the run of cron_import_order.sh while loading wh_to_wh_transfer.dat (scripts/import/ ord_imp_non_cont_tsf_in.sh)
No contingency file is available in the AIP release. The wh_to_wh_transfer.dat file archived in yesterday's srp.tar.Z contains contingency orders however it also contains the orders that were released yesterday. The orders which were released yesterday must be deleted from the file before it can be reloaded (including any orders that were released early).
This failure point can happen during the run of merge_order.sh.
If the failure happens after removing the contingency orders in non_contents_order, then orders should be manually copied from warehouse_purchase_order table into non_contents_order using a similar INSERT query as used in order_merge.copy_order_xxx function.
If the failure happens before removing the contingency orders (of previous merge run) in non_contents_order, then unreleased orders should be manually deleted from non_contents_order.
The script should then be attempted again to merge orders into non_contents_order table.