13 Replenishment

Replenishment is a complex business process that monitors stock levels and creates transactions to ensure that stores and WHs have optimal stock levels.

RMS supports a number of Replenishment Methods. A Replenishment Method is associated with each item/location being replenished. Each Replenishment Method uses an optimized calculation to determine the correct stock orders to create. Depending on the locations, inventory in the supply chain and other factors, these stock orders can be either Purchase Orders sent to a supplier, Transfers of inventory from WH to store or Allocations.

The main purpose of this chapter is to describe the batch processes involved in Replenishment. There is some discussion of user interfaces and database tables involved in the larger Replenishment business process to provide context for the batch processes, but please be aware that the discussion in this chapter of user interfaces and tables not exhaustive.

For additional information about Replenishment, see the Merchandising Functional Library (Doc ID: 1585843.1). Note that the White Papers in this library are intended only for reference and educational purposes and may not reflect the latest version of Oracle Retail software.

Replenishment Sub Processes

Replenishment can be divided into four major sub-processes:

Figure 13-1 Replenishment Sub Processes

1. Establishment/Management of Replenishment Calculation Attributes

   1. Replenishment Calculation Attributes drive how quantities will be calculated. A number of UIs and batch processes maintain this data.

2. Calculation of Recommended Order Quantity (ROQ)

   1. Complex processing determines the Recommended Order Quantity (ROQ) to meet optimal stock level for item/locations based on current stock, forecasts, history, Replenishment Calculation Attributes and other calculation inputs (please note that the inputs and calculations vary depending on the replenishment method selected for each item/location).

   2. If a client uses Investment Buying, additional calculations are performed to determine where additional profitable opportunistic purchases can be made.

3. Build Transactions to Replenish Inventory

   1. Based on ROQ and Investment Buy, Purchase Orders, Allocations and Transfers are created.

   2. Additional processing optimizes these transactions.

4. Cleanup of Replenishment Data

   1. Cleanup processes purge aged data to ensure good performance.

Establishment/Management of Replenishment Calculation Attributes

Many user and batch processes combine to manage replenishment calculation attributes.

1. replsizeprofile.pc reconciles the size profiles in RMS and Allocations and refreshes the size profile materialized view used in replenishment processing.

2. Users create or update assorted replenishment calculation attributes. Data defined by end users includes the schedule the item/location should be reviewed and item/location level attributes. Item/location level attribute changes are written to a series of Replenishment Attribute Staging Tables.

3.  rplatupd.pc moves information from the item and location level Replenishment Attribute Staging Tables (repl_attr_update_item and repl_attr_update_loc) to the Replenishment Attributes Working Table (repl_item_loc).

4. rilmaint.pc moves information from the item/loc level Replenishment Attribute Staging Table (repl_item_loc_updates) to the Replenishment Attributes Working Table (repl_item_loc).

5. repladj.pc updates the Replenishment Attributes Working Table (repl_item_loc) for item/locations using the Floating Point Replenishment Method based on history.

   Figure 13-2 Managing Replenishment Calculation Attributes

   
   

Calculation of Recommended Order Quantity (ROQ)

Many user and batch processes combine to calculate ROQ. Item/Locations follow very different paths through the calculation of ROQ depending on whether they are replenished from inventory (WH to Store via transfer) or from suppliers (via Purchase Order).

1. replroq.ksh determines working net inventory

2. batch_reqext.ksh multithreads reqext.pc

   1. reqext.pc uses calculated ROQ in rpl_net_inventory_tmp, franchise order quantity on store_orders, and replenishment attributes to create transfer. Adjusted ROQ is written to repl_results.

      
      

      Note: Transfers generated by Replenishment will follow the same integration, processing and admin described in the ’Transfers, Allocations and Receiving' described in this volume. Transactions will also be published as described in Volume 2 of the Operations Guide.

      
      

3. rplext.ksh uses replenishment attributes to determine ROQ for item/locs replenished from suppliers. ROQ is written to repl_results. Working POs are written to ord_temp.

4. If the customer uses Contracts, contracts are evaluated by cntrprss.pc. See the chapter ’Contracts' in this guide for more information.

5. If the customer uses Investment buying

   1. ibexpl.pc determines eligible investment buy opportunities

   2. ibcalc.pc calculates recommended investment buys that will meet the target return-on-investment

      Figure 13-3 Calculation of ROQ

      
      

Build Transactions to Replenish Inventory

Transactions are built based on ROQ. Additional jobs optimize the resulting POs, Allocations and Transfers.

1. rplbld.pc uses ROQ and Investment Buy Results to build Orders

2. supcnstr.pc scales POs based on supplier constraints

3. rplsplit.pc splits POs and Allocations to optimize truck loads

4. rplapprv.pc approves Purchase Orders and Allocations

   
   

   Note: Once approved, Purchase Orders and Allocations generated by Replenishment will follow the same integration, processing and Admin described in the ’Purchase Orders' and ’Transfers, Allocations and Receiving' described in this volume. Transactions will also be published as described in Volume 2 of the Operations Guide.

   
   

5. batch_rplapprvgtax.ksh updates tax information (only necessary for GTAX implementations

   1. repl_wf_order_sync.ksh creates appropriate franchise orders for approved allocations created during replenishment

      Figure 13-4 Building Transactions to Replenish Inventory

      
      

Cleanup Replenishment Data

Replenishment creates large volumes of data. Several programs exist to purge aged replenishment information. Regular purging ensures good batch performance.

Note: Note that all tables discussed in this chapter are not purged by replenishment cleanup jobs. Many replenishment processes clean up their own working tables. The POs, transfers and allocations created by replenishment are purged in their own batch processes.

1. rplprg.pc purges aged ROQ and investment buy results.

2. rplahistprg.pc purges aged replenishment attribute history.

3. rplprg_month.pc purges ROQ and investment buy results.

   Figure 13-5 Cleanup Replenishment Data

   
   

Batch Design Summary

The following batch designs are included in this chapter:

• replsizeprofile.pc - Update Replenishment Size Profile

• rplatupd.pc - Update Replenishment Calculation Attributes

• rilmaint.pc - Update Replenishment Calculation Attributes by Item/Loc

• repladj.pc - Recalculate Maximum Levels for Floating Point Replenishment

• replroq.ksh - Calculate Net Inventory

• batch_reqext.ksh - Multithreading Wrapper for reqext

• reqext.pc - ROQ Calculation and Distribution for Item/Locs Replenished from WH

• rplext.ksh - ROQ Calculation for Item/Locs Replenished from Supplier

• ibexpl.pc - Determines Eligible Investment Buy Opportunities

• ibcalc.pc - Calculate ROQ for Profitable Investment Buys

• rplbld.pc - Build Replenishment Orders

• supsplit.pc - Split Replenishment Orders Among Suppliers

• rplsplit.pc - Truck Splitting Optimization for Replenishment

• rplapprv.pc - Approve Replenishment Orders

• batch_rplapprvgtax.ksh - Update Replenishment Order Taxes

• repl_wf_order_sync.ksh - Sync Replenishment Franchise Orders

• rplprg.pc - Purge Aged Replenishment Results

• rplathistprg.pc - Purge Replenishment Attribute History

• rplprg_month.pc - Purge Replenishment Results History by Month

• repl_indctn_purge.ksh - Purge Scheduled Replenishment Induction Staging Tables

• replindbatch.ksh - Upload Replenishment Induction Data

The following batch designs are not included in this chapter, but are related to replenishment as they impact the purchase orders generated by replenishment

• vrplbld.pc – See Purchase Order chapter of this document

• cntrprss.pc – See the Contracts chapter of this document

• supcnstr.pc - See Purchase Order chapter of this document

replsizeprofile (Update Replenishment Size Profile)

Module Name	replsizeprofile.pc
Description	Update Replenishment Size Profile
Functional Area	Replenishment
Module Type	Business Processing
Module Technology	ProC
Catalog ID	RMS309
Runtime Parameters	NA

Design Overview

The batch module will do a total synchronization update of the RMS_SIZE_PROFILE table with data from the ALC_SIZE_PROFILE table if the Allocation product is installed. It will also do a complete refresh of the MV_SIZE_PROFILE materialized view used by the RPLATUPD batch and REPLATTR form when size curves are applied to the items being replenished.

Scheduling Constraints

Table 13-1 Scheduling Constraints

Schedule Information	Description
Processing Cycle	Phase 3
Frequency	Daily
Scheduling Considerations	This program should be run before the rplatupd batch to update the size curve definitions before being applied to the items replenished
Pre-Processing	Prepost replsizeprofile pre – truncate records in the RMS_SIZE_PROFILE table
Post-Processing	NA
Threading Scheme	NA

Restart/Recovery

Na

Key Tables Affected

Table 13-2 Key Tables Affected

Table	Select	Insert	Update	Delete
ALC_SIZE_PROFILE	Yes	No	No	No
RMS_SIZE_PROFILE	No	Yes	No	No
MV_SIZE_PROFILE	No	No	Yes	No

Design Assumptions

NA

rplatupd (Update Replenishment Calculation Attributes)

Module Name	rplatupd.pc
Description	Update Replenishment Calculation Attributes
Functional Area	Replenishment
Module Type	Business Processing
Module Technology	ProC
Catalog ID	RMS313
Runtime Parameters	NA

Design Overview

The batch module reads replenishment attributes from the REPL_ATTR_UPDATE_ITEM and REPL_ATTR_UPDATE_LOC tables and processes the item location relationships to determine what replenishment attributes for what locations have to be updated. Replenishment attributes for each item/location are recorded in REPL_ITEM_LOC table. Review cycle information is kept on the REPL_DAY table. The rejected records are written to the MC_REJECTIONS table for later reporting.

Prepost rplatupd pre – truncate records in the MC_REJECTIONS table.

Prepost rplatupd post – lock and delete records from REPL_ATTR_UPDATE_ITEM, REPL_ATTR_UPDATE_LOC, REPL_ATTR_UPDATE_EXCLUDE, and REPL_ATTR_UPDATE_HEAD tables.

Scheduling Constraints

Table 13-3 Scheduling Constraints

Schedule Information	Description
Processing Cycle	Phase 3
Frequency	Daily
Scheduling Considerations	This program should be run before the replenishment batch programs, rpladj.pc, replroq.ksh, reqext.pc, and rplext.ksh. Run after replsizeprofile if size curves are used for replenishment.
Pre-Processing	prepost rplatupd pre, replsizeprofile (if size profiles are used in replenishment)
Post-Processing	prepost rplatupd post repladj rplext reqext
Threading Scheme	This program is threaded by location (store and warehouse)

Restart/Recovery

The logical unit of work is replenishment attribute id, item, and location. Records will be committed to the database when commit_max_ctr defined in the RESTART_CONTROL table is reached.

Key Tables Affected

Table 13-4 Key Tables Affected

Table	Select	Insert	Update	Delete
REPL_ATTR_UPDATE_ITEM	Yes	No	No	No
REPL_ATTR_UPDATE_HEAD	Yes	No	No	No
REPL_ATTR_UPDATE_LOC	Yes	No	No	No
ITEM_LOC	Yes	No	No	No
REPL_ITEM_LOC	Yes	Yes	Yes	Yes
REPL_DAY	No	Yes	No	Yes
ITEM_SEASONS	Yes	Yes	No	No
SYSTEM_OPTIONS	Yes	No	No	No
ITEM_SUPP_COUNTRY	Yes	No	No	No
ITEM_MASTER	Yes	No	No	No
PACKITEM	Yes	No	No	No
DEPS	Yes	No	No	No
REPL_ITEM_LOC_UPDATES	No	Yes	No	Yes
SUB_ITEMS_DETAIL	Yes	No	No	No
MASTER_REPL_ATTR	Yes	Yes	Yes	Yes
REPL_ATTR_UPDATE_EXCLUDE	Yes	No	No	No
REPL_DAY_UPDATE	Yes	Yes	Yes	Yes
STORE_ORDERS	No	No	No	Yes
PARTNER_ORG_UNIT	Yes	No	No	No
STORE	Yes	No	No	No
WH	Yes	No	No	No
SUPS	Yes	No	No	No
MV_SIZE_PROFILE	Yes	No	No	No
REPL_ATTR_UPD_HIST	No	Yes	No	No

Design Assumptions

NA

rilmaint (Update Replenishment Calculation Attributes by Item/Loc)

Module Name	rilmaint.pc
Description	Update Replenishment Calculation Attributes by Item/Loc
Functional Area	Replenishment
Module Type	Business Processing
Module Technology	ProC
Catalog ID	RMS311
Runtime Parameters	NA

Design Overview

This module transfers the replenishment attributes from the REPL_ITEM_LOC_UPDATES table to the REPL_ITEM_LOC table. REPL_ITEM_LOC_UPDATES is populated when certain attributes impacting replenishment are modified. These attributes are located across the entire system and are monitored for changes by a series of triggers and modules. Once a change is logged in the REPL_ITEM_LOC_UPDATES table, this program will note the type of change and update REPL_ITEM_LOC appropriately.

Scheduling Constraints

Table 13-5 Scheduling Constraints

Schedule Information	Description
Scheduling Considerations	Run after sccext.pc and rplatupd.pc but before repladj.pc
Pre-Processing	NA
Post-Processing	prepost rilmaint post- truncate records on REPL_ITEM_LOC_UPDATES table
Threading Scheme	Threaded by location (store and warehouse)

Restart/Recovery

The logical unit of work for RILMAINT is item, change type and location. Records are committed to the database once commit_max_counter defined in the RESTART_CONTROL table is reached.

Key Tables Affected

Table 13-6 Key Tables Affected

Table	Select	Insert	Update	Delete
REPL_ITEM_LOC_UPDATES	'Yes	No	No	No
REPL_ITEM_LOC	Yes	No	Yes	Yes
REPL_DAY	Yes	No	No	Yes
STORE_ORDERS	No	No	No	Yes
ITEM_MASTER	Yes	No	No	No
PACKITEM	Yes	No	No	No
ITEM_LOC	Yes	No	No	No
ITEM_SUPP_COUNTRY	Yes	No	No	No
ITEM_SUPP_COUNTRY_LOC	Yes	No	No	No
MASTER_REPL_ATTR	No	No	No	Yes

Design Assumptions

NA

repladj (Recalculate Maximum Levels for Floating Point Replenishment)

Module Name	repladj.pc
Description	Recalculate Maximum Levels for Floating Point Replenishment
Functional Area	Replenishment
Module Type	Business Processing
Module Technology	ProC
Catalog ID	RMS307
Runtime Parameters	NA

Design Overview

This batch module recalculates the maximum stock levels for all item-location combinations with replenishment method of 'F' (floating point). The floating model stock method will dynamically calculate an order-up-to-level. The calculated order-up-to-level is used to update the REPL_ITEM_LOC table.

The maximum model stock (used for calculating order-up-to-level) is derived using the sales history of various periods of time in order to accommodate seasonality as well as trend. The sales history is obtained from the ITEM_LOC_HIST table.

Scheduling Constraints

Table 13-7 Scheduling Constraints

Schedule Information	Description
Frequency	Daily
Scheduling Considerations	Run before rplext/reqext and after rplatupd
Pre-Processing	NA
Post-Processing	NA
Threading Scheme	Multi-threaded by dept

Restart/Recovery

Themodule has restart/recovery based on item/ location. Records will be committed to the database when commit_max_ctr defined in the RESTART_CONTROL table is reached.

Key Tables Affected

Table 13-8 Key Tables Affected

Table	Select	Insert	Update	Delete
REPL_ITEM_LOC	Yes	No	Yes	No
SUB_ITEMS_HEAD	Yes	No	No	No
SUB_ITEMS_DETAIL	Yes	No	No	No
ITEM_LOC_HIST	Yes	No	No	No
ITEM_SUPP_COUNTRY	Yes	No	No	No
REPL_DAY	Yes	No	No	No
STORE	Yes	No	No	No
WH	Yes	No	No	No
SUPS	Yes	No	No	No

Design Assumptions

NA

replroq.ksh (Calculate Net Inventory)

Module Name	replroq.ksh
Description	Calculate Net Inventory
Functional Area	Replenishment
Module Type	Business Processing
Module Technology	ksh
Catalog ID	RMS308
Runtime Parameters	NA

Design Overview

This module performs the bulk of the logic to process and persist the replenishment data into RPL_NET_INVENTORY_TMP table. (The information on this table is extracted by reqext batch program.)

The wrapper script does the following things:

• Insert records into the SVC_REPL_ROQ table and determines the thread id of each record.

• Move the records from SVC_REPL_ROQ to SVC_REPL_ROQ_GTT table and will calculate the net inventory position and determine the ROQ of items which are on replenishment.

Prepost replroq pre – truncate records in RPL_NET_INVENTORY_TMP tables and build RPL_DISTRO_TMP and RPL_ALLOC_IN_TMP tables.

Scheduling Constraints

Table 13-9 Schedulng Constraints

Schedule Information	Description
Frequency	Daily
Scheduling Considerations	rplatupd, rilmaint, and repladj need to run before replroq.ksh so that all replenishment calculation attributes are up to date
Pre-Processing	Prepost replroq pre
Post-Processing	NA
Threading Scheme	The number of threads running in parallel is based on value in the column RMS_PLSQL_BATCH_CONFIG.MAX_CONCURRENT_THREADS with the program name ”CORESVC_REPL_ROQ_SQL”. Threading is based on chunks. Each chunk would have a defined size. This is defined in RMS_PLSQL_BATCH_CONFIG.MAX_CHUNK_SIZE

Restart/Recovery

The program processes all items on REPL_DAY for the current day. If the program fails, the program can be restarted and it will process the remaining records on SVC_REPL_ROQ table.

Key Tables Affected

Table 13-10 Key Tables Affected

Table	Select	Insert	Update	Delete
DOMAIN_CLASS	Yes	No	No	No
DOMAIN_DEPT	Yes	No	No	No
DOMAIN_SUBCLASS	Yes	No	No	No
REPL_DAY	Yes	No	No	No
REPL_ITEM_LOC	Yes	No	No	No
SVC_REPL_ROQ	Yes	Yes	Yes	Yes
SVC_REPL_ROQ_GTT	Yes	Yes	Yes	Yes
RPL_NET_INVENTORY_TMP	No	Yes	No	No
STORE	Yes	No	No	No
WH	Yes	No	No	No
STORE_ORDERS	Yes	No	Yes	No
SUPS	Yes	No	No	No
SYSTEM_OPTIONS	Yes	No	No	No

Design Assumptions

NA

batch_reqext.ksh (Multithreading Wrapper for reqext)

Module Name	batch_reqext.ksh
Description	Multithreading Wrapper for reqext
Functional Area	Replenishment
Module Type	Admin
Module Technology	ksh
Catalog ID	RMS192
Runtime Parameters	NA

Design Overview

The purpose of this module is to run the reqext.pc batch program multithreaded.

prepost reqext pre - create the TSFHEAD records for unique combination of Warehouse and Store, stock category, and department.

prepost reqext post – update transfer status to ’A'pproved.

Scheduling Constraints

Table 13-11 Schedulng Constraints

Schedule Information	Description
Frequency	Daily
Scheduling Considerations	Sales Posting, rplatupd, rilmaint, repladj, prepost replroq and replroq need to run before reqext rplext.ksh should run after reqext
Pre-Processing	prepost reqext pre
Post-Processing	prepost reqext post, rplext.ksh
Threading Scheme	Threaded by different partitions of RPL_NET_INVENTORY_TMP

Restart/Recovery

N/A - this script only serves as a wrapper for the batch process reqext.pc.

Key Tables Affected

Table 13-12 Key Tables Affected

Table	Select	Insert	Update	Delete
ALL_TAB_PARTITIONS	Yes	No	No	No
RESTART_CONTROL	Yes	No	No	No

Design Assumptions

NA

reqext (ROQ Calculation and Distribution for Item/Locs Replenished from WH)

Module Name	reqext.pc
Description	ROQ Calculation and Distribution for Item/Locs Replenished from WH
Functional Area	Replenishment
Module Type	Business Processing
Module Technology	ProC
Catalog ID	RMS310
Runtime Parameters	NA

Design Overview

This module performs the automatic replenishment of items from warehouses to stores. It runs through every item-store combination set to be reviewed on the current day, and calculates the quantity of the item, known as the recommended order quantity (ROQ) that needs to be transferred to the store (if any). In addition, it distributes this ROQ over any applicable alternate items associated with the item.

Once the transfer quantity of an item has been calculated, transfers are created and records are written to the replenishment results table (REPL_RESULTS) based on the replenishment order control indicator.

For franchise stores, separate transfers are created based on the need date and will be linked back to a Franchise Order through the wf_order_no field.

This batch will also insert records into the respective tables for supporting the localization feature. This will be applicable only if localizations are enabled.

prepost reqext pre - Create the TSFHEAD records for unique combination of Warehouse and Store, stock category and department.

prepost reqext post – update transfer status to approved.

Scheduling Constraints

Table 13-13 Schedulng Constraints

Schedule Information	Description
Frequency	Daily
Scheduling Considerations	Sales Posting, rplatupd and repladj need to run before reqext rplext should run after reqext
Pre-Processing	prepost reqext pre rplatupd and repladj
Post-Processing	prepost reqext post, rplext
Threading Scheme	Multiple processes of this program can be run at the same time, each running against a different partition of rpl_net_inventory_tmp

Restart/Recovery

The logical unit of work is an item/source warehouse. Restart/recovery is achieved implicitly because repl_item_loc records that have been processed are updated with a last review date and only records that have not been reviewed today will be picked up by the driving cursor again. Records will be committed to the database when commit_max_ctr defined in the RESTART_CONTROL table is reached. During the night run the batch processed only those store order records with delivery slot. The review dates are not updated during day run. During night all the records are processed irrespective of the delivery slots.

Key Tables Affected

Table 13-14 Key Tables Affected

Table	Select	Insert	Update	Delete
ITEM_LOC	Yes	No	No	No
ITEM_LOC_SOH	No	No	Yes	No
ITEM_SUPP_COUNTRY	Yes	No	No	No
PACKHEAD	Yes	No	No	No
PACKITEM	Yes	No	No	No
PACKSTORE_HIST	Yes	No	No	No
PERIOD	Yes	No	No	No
REPL_DAY	Yes	No	No	No
REPL_ITEM_LOC	Yes	No	Yes	No
REPL_RESULTS	No	Yes	No	No
RPL_NET_INVENTORY_TMP	Yes	No	No	No
STORE	Yes	No	No	No
SUB_ITEMS_DETAIL	Yes	No	No	No
SUB_ITEMS_HEAD	Yes	No	No	No
SUPS	Yes	No	No	No
SYSTEM_OPTIONS	Yes	No	No	No
TSFDETAIL	Yes	Yes	Yes	No
TSFHEAD	Yes	Yes	No	No
WH	Yes	No	No	No
STORE_ORDERS	Yes	No	Yes	No
WF_ORDER_HEAD	No	Yes	No	No
WF_ORDER_DETAIL	Yes	Yes	No	No
DELIVERY_SLOT	Yes	No	No	No
ADDR	Yes	No	No	No
COMPHEAD	Yes	No	No	No
OUTLOC	Yes	No	No	No
L10N_DOC_DETAILS_GTT	Yes	Yes	No	No
MV_L10N_ENTITY	Yes	No	No	No
COUNTRY_ATTRIB	Yes	No	No	No
L10N_PKG_CONFIG	Yes	No	No	No
ORDHEAD_L10N_EXT	No	Yes	No	No
TSFHEAD_L10N_EXT	No	Yes	No	No
MRT_L10N_EXT	No	Yes	No	No

Design Assumptions

NA

rplext.ksh (ROQ Calculation and Distribution for Item/Locs Replenished from Supplier

Module Name	rplext.ksh
Description	ROQ Calculation and Distribution for Item/Locs Replenished from Supplier
Functional Area	Replenishment
Module Type	Business Processing
Module Technology	KSH
Catalog ID	RMS315
Runtime Parameters	NA

Design Overview

RPLEXT (Vendor Replenishment Extraction), which is in bulk processing logic, is the driving program for the replenishment process. It cycles through every item-location combination that is ready to be reviewed on the current day, and calculates the quantity of the item that needs to be ordered to the location. The program then writes these temporary order line items to ORD_TEMP and REPL_RESULTS. ORD_TEMP is later reviewed by the module CNTPRSS.PC in its evaluation of orders against contract types A, C, D, whereas REPL_RESULTS is processed by RPLBLD.

The wrapper script does the following things:

• Insert records into the SVC_REPL_ROQ table and determines the thread id of each record.

• Move the records from SVC_REPL_ROQ to SVC_REPL_ROQ_GTT table and the processed records will be inserted to ORD_TEMP and REPL_RESULTS tables.

• prepost rpl pre – truncate records in ORD_TEMP and ORD_MISSED tables.

• prepost rplext post – truncate records in RPL_DISTRO_TMP and RPL_ALLOC_IN_TMP table.

Scheduling Constraints

Table 13-15 Schedulng Constraints

Schedule Information	Description
Frequency	Daily
Scheduling Considerations	rplatupd.pc, rilmaint.pc, rpladj.pc, reqext.pc and cntrordb.pc need to run before rplext If contracting is being used, cntrprss.pc should run after rplext.pc; otherwise, run ibexpl.pc, ibcalc.pc rplbld.pc
Pre-Processing	rplatupd.pc, rilmaint.pc, rpladj.pc, reqext.pc and cntrordb.pc prepost rpl pre
Post-Processing	prepost rplext post ibexpl.pc, ibcalc.pc rplbld.pc
Threading Scheme	Multiple processes of this program can be run at the same time against different departments

Restart/Recovery

If the program fails, the program can be restarted and it will process the remaining records on SVC_REPL_ROQ table.

Locking Strategy

STORE_ORDER table records are locked while calculating ROQ.

Security Considerations

NA

Key Tables Affected

Table 13-16 Key Tables Affected

Table	Select	Insert	Update	Delete
DOMAIN_CLASS	Yes	No	No	No
DOMAIN_DEPT	Yes	No	No	No
DOMAIN_SUBCLASS	Yes	No	No	No
ITEM_SUPP_COUNTRY	Yes	No	No	No
PERIOD	Yes	No	No	No
REPL_DAY	Yes	No	No	No
REPL_ITEM_LOC	Yes	No	Yes	No
STORE	Yes	No	No	No
SYSTEM_OPTIONS	Yes	No	No	No
WH	Yes	No	No	No
SUPS	Yes	No	No	No
SUP_INV_MGMT	Yes	No	No	No
ORD_TEMP	No	Yes	No	No
REPL_RESULTS	No	Yes	No	No

Design Assumptions

NA

ibexpl (Determines Eligible Investment Buy Opportunities)

Module Name	ibexpl.pc
Description	Determines Eligible Investment Buy Opportunities
Functional Area	Investment Buy
Module Type	Business Processing
Module Technology	ProC
Catalog ID	RMS250
Runtime Parameters	NA

Design Overview

The ibexpl batch program pre-qualifies investment buy (IB) eligible wh/dept and IB eligible supp/dept/locs.

The WH_DEPT table holds IB parameters at the WH or at the wh/dept level. If there are IB parameters defined at the wh/dept level, they are used. If there are no IB parameters defined at the wh/dept level, the IB parameters at the WH level are used. If IB parameters are not defined at either level, then system level IB parameters are used. The first part of this program sends IB parameters to the wh/dept level no matter what level they are held at in the database. The results are written to the WH_DEPT_EXPL table.

Next the WH_DEPT_EXPL table is combined with supplier inventory management data to get the final list of all eligible sup/dept/locs. The supplier inventory management data determines whether or not a given sup/dept/loc combo is IB eligible.

The main problem is that this table can store information at different levels depending upon the supplier's inventory management level.

Valid options for this level are:

• Sup (S)

• Sup/dept (D)

• Sup/loc (L)

• Sup/dept/loc (A)

If the record is not found at the defined level, it needs to look up the hierarchy as shown below, up to the highest level (sup). If no record exists as the sup level, it is not IB eligible.

• Sup

• Sup/dept - sup

• Sup/loc - sup

• Sup/dept/loc - sup/dept -sup

The second part of this program explodes the supplier inventory management data down to the sup/dept/loc level by filling in the implied rows. The exploded sup_inv_mgmt information is only done for IB eligible wh/dept combinations from the wh_dept_expl table. The results are placed on the sim_expl table.

Scheduling Constraints

Table 13-17 Scheduling Constraints

Schedule Information	Description
Frequency	Daily
Scheduling Considerations	After rplext.pc and before ibcalc.pc
Pre-Processing	NA
Post-Processing	NA
Threading Scheme	NA

Restart/Recovery

NA

Key Tables Affected

Table 13-18 Key Tables Affected

Table	Select	Insert	Update	Delete
WH	Yes	No	No	No
DEPS	Yes	No	No	No
WH_DEPT	Yes	No	No	No
SUP_INV_MGMT	Yes	No	No	No
SUPS	Yes	No	No	No
WH_DEPT_EXPL	Yes	Yes	No	Yes
TERMS	Yes	No	No	No
SIM_EXPL	No	Yes	No	Yes
SYSTEM_OPTIONS	Yes	No	No	No

Design Assumptions

NA

ibcalc (Calculate ROQ for Profitable Investment Buys)

Module Name	ibcalc.pc
Description	Calculate ROQ for Profitable Investment Buys
Functional Area	Replenishment
Module Type	Business Processing
Module Technology	ProC
Catalog ID	RMS249
Runtime Parameters	NA

Design Overview

The ibcalc.pc batch program is the calculation engine for investment buy processing. It identifies investment buy (IB) opportunities and calculates recommended order quantities (ROQs) that will meet the target return-on-investment (ROI)

This module will calculate forward buy opportunities using:

• Carrying costs

• Ordering parameters

• Deals – future and expiring

• Cost changes – future

• Forecasts

• Inventory levels

• Target ROI (return on investment)

The deals and cost change components will be contained on a FUTURE_COST table. This table will hold a record for each future date that has a costing event (for example, a cost change, deal activation/deactivation). This process utilizes the default costing bracket and default deal thresholds in the calculations.

Prepost ibcalc pre – set ib_results.status from ’W' (worksheet) to ’U' (unprocessed).

Scheduling Constraints

Table 13-19 Scheduling Constraints

Schedule Information	Description
Frequency	Daily
Scheduling Considerations	After rplext. pc and ibexpl. pc Before rplbld.pc
Pre-Processing	rplext. pc and ibexpl. pc Prepost ibcalc pre
Post-Processing	rplbld.pc
Threading Scheme	NA

Restart/Recovery

The logical unit of work is item and location combination.

Key Tables Affected

Table 13-20 Key Tables Affected

Table	Select	Insert	Update	Delete
FUTURE_COST	Yes	No	No	No
SIM_EXPL	Yes	No	No	No
ITEM_LOC	Yes	No	No	No
REPL_ITEM_LOC	Yes	No	No	No
ITEM_MASTER	Yes	No	No	No
PACKITEM	Yes	No	No	No
ITEM_SUPP_COUNTRY	Yes	No	No	No
ITEM_SUPP_COUNTRY_LOC	Yes	No	No	No
ITEM_SUPP_COUNTRY_DIM	Yes	No	No	No
SUPS	Yes	No	No	No
SUB_ITEMS_DETAIL	Yes	No	No	No
SUB_ITEMS_HEAD	Yes	No	No	No
UOM_CONVERSION	Yes	No	No	No
WH	Yes	No	No	No
IB_RESULTS	No	Yes	No	No

Design Assumptions

NA

rplbld (Build Replenishment Orders)

Module Name	rplbld.pc
Description	Build Replenishment Orders
Functional Area	Replenishment
Module Type	Business Processing
Module Technology	ProC
Catalog ID	RMS314
Runtime Parameters	NA

Design Overview

RPLBLD builds RMS orders from recommended order quantities (ROQ) generated by the RPLEXT.PC and IBCALC.PC processes. CNTRPRSS.PC associates contracts with the ROQs created by RPLEXT.PC. These ROQs are placed on a temporary table (ORD_TEMP or IB_RESULTS) by RPLEXT.PC and IBCALC.PC. All records on ORD_TEMP/IB_RESULTS are processed by RPLBLD each night. These ORD_TEMP/IB_RESULTS records are placed into logical groups, and a RMS order is created for each logical group.

In order to be placed in the same order group, the item/location ROQs from ORD_TEMP/IB_RESULTS must share a common supplier, have the same order_status (’W'orksheet or ’A'pproved), and be on the same contract (or not be associated with a contract). Depending on flags on the ORD_INV_MGMT table, two other criteria can be used for splitting order groups. First, if the INV_MGMT_LVL is set to ’D'ept, only items in a single department are allowed in an ordering group. Secondly, the SINGLE_LOC_IND can be set to ’Y'es. If this is the case, only one location is allowed per ordering group. Finally, a SKU may only exist in an ordering group with a single origin country. When an item/loc ROQ ORD_TEMP/IB_RESULTS record is encountered with a different origin country than the one it exists with in the current ordering group, it is placed in a different ordering group.

To assist the recalculation and order scaling processes of replenishment ROQs, the REPL_RESULTS record, associated with the ORD_TEMP being processed, is updated with the ORDER_NO and ALLOC_NO that the ORD_TEMP record was placed with. IB_RESULTS is also updated with the ORDER_NO.

If the location to be replenished is a Franchise location and the replenishment Order Control is Semi-Automatic or Automatic, Franchise POs will be created per Costing Location/Location. Associated Franchise Orders will also be created.

Scheduling Constraints

Table 13-21 Scheduling Constraints

Schedule Information	Description
Frequency	Daily
Scheduling Considerations	Runs after rplext.pc, cntrprss.pc (if contracting is being used). Runs after vrplbld and ibcalc. Runs before supcnstr
Pre-Processing	None
Post-Processing	None
Threading Scheme	This program is threaded by supplier.

Restart/Recovery

The logical unit of work is supplier, contract number, and order status. Records will be committed to the database when commit_max_ctr defined in the RESTART_CONTROL table is reached

Key Tables Affected

Table 13-22 Key Tables Affected

Table	Select	Insert	Update	Delete
ORD_TEMP	Yes	No	No	No
REPL_RESULTS	Yes	No	Yes	No
WH	Yes	No	No	No
ITEM_MASTER	Yes	No	No	No
IB_RESULTS	Yes	No	Yes	No
CONTRACT_HEADER	Yes	No	Yes	No
CONTRACT_DETAIL	Yes	No	Yes	No
ORDSKU	Yes	Yes	No	No
ORDLOC	Yes	Yes	No	No
ALLOC_HEADER	No	Yes	No	No
ALLOC_DETAIL	No	Yes	No	No
ITEM_LOC	Yes	No	No	No
ORDHEAD	Yes	Yes	Yes	No
ORD_INV_MGMT	Yes	Yes	Yes	No
ORDLC	No	Yes	No	No
ITEM_SUPP_COUNTRY_LOC	No	No	No	No
ITEM_SUPP_COUNTRY	No	No	Yes	No
BUYER_WKSHT_MANUAL	No	No	Yes	No
L10N_DOC_DETAILS_GTT	Yes	Yes	No	No
MV_L10N_ENTITY	Yes	No	No	No
COUNTRY_ATTRIB	Yes	No	No	No
L10N_PKG_CONFIG	Yes	No	No	No
TSFHEAD	Yes	No	No	No
ORDHEAD_L10N_EXT	No	Yes	No	No
TSFHEAD_L10N_EXT	No	Yes	No	No
MRT_L10N_EXT	No	Yes	No	No
FM_SYSTEM_OPTIONS	Yes	No	No	No
WF_ORDER_HEAD	No	Yes	No	No
WF_ORDER_DETAIL	No	Yes	No	No

Design Assumptions

NA

supsplit (Split Replenishment Orders Among Suppliers)

Module Name	supsplit.pc
Description	Split Replenishment Orders Among Suppliers
Functional Area	Replenishment
Module Type	Business Processing
Module Technology	ProC
Catalog ID	RMS370
Runtime Parameters	NA

Design Overview

This program splits replenishment orders among different suppliers based on the supplier distribution ratio setup for an item/location on replenishment. It only applies to Direct to Store and Crossdock replenishments where a purchase order will be created from a supplier.

Scheduling Constraints

Table 13-23 Scheduling Constraints

Schedule Information	Description
Frequency	Daily
Scheduling Considerations	This program will run nightly after the vendor replenishment extraction program (rplext.pc) and before the contract replenishment program (cntrprss.pc)
Pre-Processing	rplext.pc prepost supsplit pre
Post-Processing	cntrprss.pc
Threading Scheme	Thread by department

Restart/Recovery

The logical unit of work for this program is set at item level. Records will be committed to the database when commit_max_ctr defined in the RESTART_CONTROL table is reached.

Key Tables Affected

Table 13-24 Key Tables Affected

Table	Select	Insert	Update	Delete
REPL_ITEM_LOC_SUPP_DIST	Yes	No	No	No
ORD_TEMP	Yes	Yes	No	Yes
REPL_RESULTS	Yes	Yes	No	Yes
ITEM_MASTER	Yes	No	No	No
ITEM_SUPP_COUNTRY	Yes	No	No	No
ITEM_SUPP_COUNTRY_LOC	Yes	No	No	No

Design Assumptions

NA

rplsplit (Truck Splitting Optimization for Replenishment)

Module Name	rplsplit.pc
Description	Truck Splitting Optimization for Replenishment
Functional Area	Replenishment
Module Type	Business Processing
Module Technology	ProC
Catalog ID	RMS318
Runtime Parameters	NA

Design Overview

The purpose of this program is to select all the orders eligible for truck splitting, which are created by the replenishment programs. The orders that are eligible will be sent into the truck splitting logic and the resulting orders will be created.

The orders, which will be eligible for splitting, are as follows:

• The order must have been created today by replenishment with ord_inv_mgmt.ord_approve_ind = ’Y'.

• The order must not have been already split.

• The order must be a single location order and the location must be a warehouse.

• The order must not have any allocations associated.

Orders will only be split if they meet criteria for splitting as defined in the supplier inventory management parameters.

Scheduling Constraints

Table 13-25 Scheduling Constraints

Schedule Information	Description
Frequency	Daily
Scheduling Considerations	This program will run nightly after the replenishment-scaling program (supcnstr.pc) and before the replenishment approval program (rplapprv.pc)
Pre-Processing	supcnstr.pc
Post-Processing	rplapprv.pc
Threading Scheme	Thread by supplier

Restart/Recovery

The logical unit of work for this program is set at order level. Records will be committed to the database when commit_max_ctr defined in the RESTART_CONTROL table is reached.

Key Tables Affected

Table 13-26 Key Tables Affected

Table	Select	Insert	Update	Delete
ORDHEAD	Yes	Yes	Yes	No
ORDSKU	Yes	Yes	No	Yes
ORDLOC	Yes	Yes	No	Yes
ORD_INV_MGMT	Yes	Yes	Yes	Yes
ITEM_MASTER	Yes	No	No	No
WH	Yes	No	No	No
V_RESTART_SUPPLIER	Yes	No	No	No
ALLOC_HEADER	Yes	Yes	No	Yes
ALLOC_DETAIL	Yes	Yes	No	Yes
ALLOC_CHRG	No	No	No	Yes
ORDHEAD_REV	No	No	No	Yes
ORDSKU_REV	No	No	No	Yes
ORDLOC_REV	No	No	No	Yes
ORDLOC_WKSHT	No	No	No	Yes
ORDLOC_DISCOUNT	No	No	No	Yes
ORDCUST	No	No	No	Yes
ORDLC	No	No	No	Yes
DEAL_COMP_PROM	No	No	No	Yes
DEAL_ITEMLOC	No	No	No	Yes
DEAL_THRESHOLD	No	No	No	Yes
DEAL_DETAIL	No	No	No	Yes
DEAL_QUEUE	No	No	No	Yes
DEAL_CALC_QUEUE	No	No	No	Yes
DEAL_HEAD	No	No	No	Yes
REPL_RESULTS	No	No	No	Yes
REV_ORDERS	No	No	No	Yes
ITEM_LOC	Yes	No	No	No
ITEM_SUPP_COUNTRY_LOC	Yes	No	No	No
CONTRACT_DETAIL	No	No	Yes	No
CONTRACT_HEAD	No	No	Yes	No
BUYER_WKSHT_MANUAL	No	No	Yes	No
IB_RESULTS	No	No	Yes	No
L10N_DOC_DETAILS_GTT	Yes	No	No	Yes
MV_L10N_ENTITY	Yes	No	No	No
COUNTRY_ATTRIB	Yes	No	No	No
L10N_PKG_CONFIG	Yes	No	No	No
TSFHEAD	Yes	No	No	No
ORDHEAD_L10N_EXT	No	Yes	No	No
TSFHEAD_L10N_EXT	No	Yes	No	No
MRT_L10N_EXT	No	Yes	No	No
FM_SYSTEM_OPTIONS	Yes	No	No	No

Design Assumptions

NA

rplapprv (Approve Replenishment Orders)

Module Name	rplapprv.pc
Description	Approve Replenishment Orders
Functional Area	Replenishment
Module Type	Business Processing
Module Technology	ProC
Catalog ID	RMS300
Runtime Parameters	NA

Design Overview

This program looks at all replenishment, vendor and contract orders created during the nightly batch run to determine if they can be approved. These orders are compared with any vendor minimums that may exist. Orders that do not meet the vendor minimums are either deleted or placed in worksheet status. A flag, held at the supplier inventory management level (ORD_INV_MGMT.ORD_PURGE_IND), determines what action is taken on orders that fail minimums. Vendor generated orders are not subject to these minimum checks.

Vendor minimums can be held at the order, item, or location level. Order and location level minimums are held on the SUP_INV_MGMT table. There is a flag that determines if they are applied at the order level or at the location level. Vendor minimums at the SKU level are held on the ITEM_SUPP_COUNTRY table.

When the ORD_INV_MGMT.ORD_PURGE_IND is ’N', a failure at any level causes the order to be placed in worksheet status. When the ORD_INV_MGMT.ORD_PURGE_IND is ’Y', a failure at the location level causes the offending location to be deleted; a failure at the SKU level causes the problematic SKU to be deleted; and a failure at the order level caused the entire order to be deleted.

For any orders that fail vendor minimums when the ORD_INV_MGMT.ORD_PURGE_IND is ’Y', a record is written to the SUPS_MIN_FAIL table for reporting purposes. This table is purged during the pre-processing of this batch program.

After order records are updated, any applicable deals, brackets and allowances are applied to the orders by subsequent processes. Open to buy is then updated for any orders built in approved status. If any orders are contract orders, the contract amounts are updated as well to reflect any order record deletions.

If any orders are Franchise POs, the associated Franchise Orders are also approved if they pass the credit check. If they fail the credit check, both Franchise POs and orders will remain in Worksheet.

An order may not pass vendor minimum checks assuming that the vendor minimum checks are performed for a physical WH. If the vendor minimum is not met for a physical location, all the virtual WHs on the order within the physical WH will need to be removed along with associated allocations.

Prepost rplapprv pre – truncates sups_min_fail table

Scheduling Constraints

Table 13-27 Scheduling Constraints

Schedule Information	Description
Frequency	Daily
Scheduling Considerations	This program should run directly after the replenishment supcnstr.pc program. It is important that this program runs before any other process affects the generated orders. The script batch_rplapprvgtax.ksh should also run immediately after this program to ensure that taxes are computed for the approved replenishment orders in a global tax configuration
Pre-Processing	Prepost rplapprv pre
Post-Processing	batch_rplapprvgtax.ksh (when GTAX)
Threading Scheme	NA

Restart/Recovery

The logical unit of work is order number. Records will be committed to the database when commit_max_ctr defined in the RESTART_CONTROL table is reached.

Key Tables Affected

Table 13-28 Key Tables Affected

Table	Select	Insert	Update	Delete
ORDHEAD_LOCK	No	No	No	Yes
ORDHEAD	Yes	No	Yes	Yes
ORDLOC	Yes	No	No	Yes
ORDSKU	Yes	No	No	Yes
ORD_INV_MGMT	Yes	No	Yes	Yes
DEAL_CALC_QUEUE	No	Yes	Yes	No
ITEM_SUPP_COUNTRY	Yes	No	No	No
SUPS_MIN_FAIL	No	Yes	No	Yes
ALLOC_HEADER	Yes	No	Yes	Yes
ALLOC_DETAIL	No	No	No	Yes
CONTRACT_HEADER	Yes	No	Yes	No
OTB	No	No	Yes	No
PERIOD	Yes	No	No	No
SYSTEM_OPTIONS	Yes	No	No	No
WH	Yes	No	No	No
ITEM_MASTER	Yes	No	No	No
SUPS	Yes	No	No	No
REPL_APPRV_GTAX_QUEUE	No	Yes	No	No
ORDHEAD_CFA_EXT	No	No	No	Yes
WF_ORDER_HEAD	Yes	No	Yes	No

Design Assumptions

NA

batch_rplapprvgtax.ksh (Update Replenishment Order Taxes)

Module Name	batch_rplapprvgtax.ksh
Description	Update Replenishment Order Taxes
Functional Area	Replenishment
Module Type	Business Processing
Module Technology	ksh
Catalog ID	RMS194
Runtime Parameters	NA

Design Overview

This script calls the TAX_THREAD_SQL.LOAD_REPL_ORDER_TAX_BREAKUP to enable parallel execution via multiple thread calls to the L10N_BR_INT_SQL.LOAD_ORDER_TAX_OBJECT function to compute taxes for approved replenishment orders. Computed taxes are inserted/updated into the ORD_TAX_BREAKUP table.

This batch should be run only for Global Tax (GTAX) configuration.

Scheduling Constraints

Table 13-29 Scheduling Constraints

Schedule Information	Description
Frequency	Daily
Scheduling Considerations	This batch should be run only for Global Tax (GTAX) configuration This program should run directly after the replenishment rplapprv program. It is important that this program runs before any other process affects the generated orders
Pre-Processing	rplapprv
Post-Processing	NA
Threading Scheme	Threaded by purchase order number

Restart/Recovery

The logical unit of work is a set of purchase orders. Purchase order numbers in the REPL_APPRV_GTAX_QUEUE table are assigned a thread number given the number of slots.

The same table drives the restart and recovery as well. Purchase orders in a thread that successfully complete execution are deleted from REPL_APPRV_GTAX_QUEUE. Any restart after a fatal error will include the failed purchase order numbers when assigning new threads.

Key Tables Affected

Table 13-30 Key Tables Affected

Table	Select	Insert	Update	Delete
ORD_TAX_BREAKUP	Yes	Yes	Yes	No
REPL_APPRV_GTAX_QUEUE	Yes	No	No	Yes
ORDLOC	Yes	No	No	No
ORDHEAD	Yes	No	No	No
ITEM_MASTER	Yes	No	No	No
MV_CURRENCY_CONVERSION_RATES	Yes	No	No	No
ITEM_SUPP_COUNTRY	Yes	No	No	No
V_PACKSKU_QTY	Yes	No	No	No
ADDR	Yes	No	No	No
STATE	Yes	No	No	No
COUNTRY	Yes	No	No	No
COUNTRY_TAX_JURISDICTION	Yes	No	No	No
V_BR_COUNTRY_ATTRIB	Yes	No	No	No
V_BR_SUPS	Yes	No	No	No
V_BR_STORE_FISCAL_CLASS	Yes	No	No	No
V_BR_STORE_REG_NUM	Yes	No	No	No
V_BR_WH_REG_NUM	Yes	No	No	No
V_BR_ITEM_FISCAL_ATTRIB	Yes	No	No	No
ORDLOC_EXP	Yes	No	No	No
ELC_COMP	Yes	No	No	No
ORDLOC_DISCOUNT	Yes	No	No	No
VAT_CODES	Yes	No	No	No
FM_FISCAL_UTILIZATION	Yes	No	No	No
V_BR_ORD_UTIL_CODE	Yes	No	No	No

Design Assumptions

This program should only be run in Global Tax (GTAX) installations.

repl_wf_order_sync.ksh (Sync Replenishment Franchise Orders

Module Name	repl_wh_order_sync.ksh
Description	Sync Replenishment Franchise Orders
Functional Area	Replenishment
Module Type	Business Processing
Module Technology	ksh
Catalog ID	RMS306
Runtime Parameters	N/A

Design Overview

This module will serve as the wrapper for the package function WF_ALLOC_SQL.REPL_SYNC_F_ORDER which will check the crossdock orders created during replenishment and create franchise order records for any allocations where the destination location is a franchise store.

Scheduling Constraints

Table 13-31 Scheduling Constraints

Schedule Information	Description
Frequency	Daily
Scheduling Considerations	End of replenishment batch schdule
Pre-Processing	rplapprv
Post-Processing	NA
Threading Scheme	NA

Restart/Recovery

NA

Key Tables Affected

Table 13-32 Key Tables Affected

Table	Select	Insert	Update	Delete
ALLOC_HEADER	Yes	No	Yes	No
ALLOC_DETAIL	Yes	No	Yes	No
STORE	Yes	No	No	No
WF_CUSTOMER	Yes	No	No	No
WF_ORDER_HEAD	Yes	Yes	Yes	No
WF_ORDER_DETAIL	Yes	Yes	Yes	Yes
ITEM_MASTER	Yes	No	No	No
STORE	Yes	No	No	No
WF_ORDER_AUDIT	Yes	No	No	Yes
FUTURE_COST	Yes	No	No	No
ITEM_SUPP_COUNTRY	Yes	No	No	No
ITEM_SUPP_COUNTRY_DIM	Yes	No	No	No
WF_ORDER_EXP	Yes	Yes	No	Yes
WF_COST_BUILDUP_TMPL_HEAD	Yes	No	No	No
WF_COST_BUILDUP_TMPL_DETAIL	Yes	No	No	No
ITEM_LOC	Yes	No	No	No
ITEM_SUPP_UOM	Yes	No	No	No
V_ITEM_MASTER	Yes	No	No	No
V_STORE	Yes	No	No	No

Design Assumptions

NA

rplprg (Purge Aged Replenishment Results)

Module Name	rplprg.pc
Description	Purge Aged Replenishment Results
Functional Area	Replenishment
Module Type	Admin
Module Technology	ProC
Catalog ID	RMS316
Runtime Parameters	NA

Design Overview

The replenishment extraction programs (RPLEXT, REQEXT) write a number of records to REPL_RESULTS. Store orders populate the STORE_ORDERS table. The investment buy process writes records to IB_RESULTS and the Buyer Worksheet Form populates BUYER_WKSHT_MANUAL. These tables hold information that is relevant to replenishment processes. Over time, records on these tables become unneeded and must be cleared out. The replenishment purge program goes through these tables and clears out those records that are older than a predetermined number of days. The purging cycles (number of days) are maintained as a system parameter.

Scheduling Constraints

Table 13-33 Scheduling Constraints

Schedule Information	Description
Frequency	Daily
Scheduling Considerations	NA
Pre-Processing	NA
Post-Processing	NA
Threading Scheme	NA

Restart/Recovery

Because this program performs only deletes, there is no need for restart/recovery or multithreading, and there is no driving cursor. However, this program still needs an entry on RESTART_CONTROL to determine the number of records to be deleted between commits.

Key Tables Affected

Table 13-34 Key Tables Affected

Table	Select	Insert	Update	Delete
SYSTEM_OPTIONS	Yes	No	No	No
ALL_TAB_PARTITIONS	Yes	No	No	No
REPL_RESULTS	No	No	No	Yes
BUYER_WKSHT_MANUAL	No	No	No	Yes
STORE_ORDERS	No	No	No	Yes
IB_RESULTS	No	No	No	Yes

Design Assumptions

NA

rplathistprg (Purge Replenishment Attribute History)

Module Name	rplathistprg.pc
Description	Purge Replenishment Attribute History
Functional Area	Replenishment
Module Type	Admin
Module Technology	ProC
Catalog ID	RMS312
Runtime Parameters	NA

Design Overview

The batch will purge data from the REPL_ATTR_UPD_HIST table if it's older than the defined number of retention weeks as specified in the system parameters.

Scheduling Constraints

Table 13-35 Scheduling Constraints

Schedule Information	Description
Frequency	Weekly
Scheduling Considerations	This program should run at the end of the week
Pre-Processing	NA
Post-Processing	NA
Threading Scheme	NA

Restart/Recovery

NA

Key Tables Affected

Table 13-36 Key Tables Affected

Table	Select	Insert	Update	Delete
REPL_ATTR_UPD_HIST	No	No	No	Yes
SYSTEM_OPTIONS	Yes	No	No	No
PERIOD	Yes	No	No	No
ALL_TAB_PARTITIONS	Yes	No	No	No

Integration Contract

Integration Type	NA
File Name	NA
Integration Contract	NA

Design Assumptions

NA

rplprg_month (Purge Replenishment Results History by Month)

Module Name	rplprg_month.pc
Description	Purge Replenishment Results History by Month
Functional Area	Replenishment
Module Type	Admin
Module Technology	ProC
Catalog ID	RMS317
Runtime Parameters	NA

Design Overview

The replenishment extraction programs (RPLEXT, REQEXT) write a number of records to REPL_RESULTS. The investment buy process writes records to IB_RESULTS and the Buyer Worksheet Form populates BUYER_WKSHT_MANUAL. These tables hold information that is relevant to replenishment processes. Over time, records on these tables become unneeded and should be cleared out. The monthly replenishment purge program goes through these tables and clears out those records that are older than a predetermined number of days (maintained in SYSTEM_OPTIONS). The eways ewInvAdjustToRMS, ewReceiptToRMS need to be shutdown when RPLPRG_MONTH.PC is run.

Scheduling Constraints

Table 13-37 Scheduling Constraints

Schedule Information	Description
Frequency	Monthly
Scheduling Considerations	NA
Pre-Processing	NA
Post-Processing	NA
Threading Scheme	NA

Restart/Recovery

Because this program performs only deletes, there is no need for restart/recovery or multithreading, and there is no driving cursor. However, this program still needs an entry on RESTART_CONTROL to determine the number of records to be deleted between commits.

Key Tables Affected

Table 13-38 Key Tables Affected

Table	Select	Insert	Update	Delete
SYSTEM_OPTIONS	Yes	No	No	No
ALL_TAB_PARTITIONS	Yes	No	No	No
REPL_RESULTS	No	No	No	Yes
BUYER_WKSHT_MANUAL	No	No	No	Yes
STORE_ORDERS	No	No	No	Yes
IB_RESULTS	No	No	No	Yes

Design Assumptions

NA

repl_indctn_purge.ksh (Purge Scheduled Replenishment Induction Staging Tables)

Module Name	repl_indctn_purge.ksh
Description	Purge scheduled replenishment induction staging tables
Functional Area	Inventory Management
Module Type	Admin
Module Technology	Shell Script
Catalog ID	NA
Runtime Parameters	NA

Design Overview

The purpose of this module is to remove old scheduled replenishment records from the staging tables. Records that are candidates for deletion are:

• Processes that have successfully been processed or processed with warnings that have been uploaded to RMS or downloaded to S9T

• Processes in error status where all other related records containing the process ID have been processed successfully

• Processes that are past the data retention days (action_date < current date - system_options.proc_data_retention_days)

Scheduling Constraints

Table 13-39 Scheduling Constraints

Schedule Information	Description
Processing Cycle	Ad Hoc
Frequency	Daily
Scheduling Considerations	NA
Pre-Processing	NA
Post-Processing	NA
Threading Scheme	NA

Restart/Recovery

Restart ability will be implied, because the records that are selected from the cursor will be deleted before the commit.

Key Tables Affected

Table 13-40 Key Tables Affected

Table	Select	Insert	Update	Delete
PROC_DATA_RETENTION_DAYS	Yes	No	No	No
SVC_PROCESS_TRACKER	Yes	No	No	Yes
SVC_REPL_ATTR_UPDATE	Yes	No	No	Yes
CORESVC_PREPL_ERR	Yes	No	No	Yes
S9T_ERRORS	Yes	No	No	Yes
CORESVC_REPL_CHUNKS	Yes	No	No	Yes
S9T_FOLDER	Yes	No	No	Yes
SVC_PROCESS_REPL	Yes	No	No	Yes

Design Assumptions

NA

replindbatch.ksh (Upload Replenishment Induction Data)

Module Name	replindbatch.ksh
Description	Upload replenishment schedule
Functional Area	Inventory Movement
Module Type	Integration
Module Technology	Ksh
Catalog ID	NA
Runtime Parameters	Database connection, Input File Name, Template Name

Design Overview

This batch program is used to Bulk upload xml file data from template files to S9T_FOLDER table (into content_xml column).

This batch will be responsible for validating the input parameters, below are the list of validations.

• The input file should exist.

• The input file's extension must be ".xml".

• The template_name should be valid. Function S9T_PKG.CHECK_TEMPLATE is called for validation.

Once xml data is loaded into S9T_FOLDER table, the script will do post processing by calling below packages

• REPL_INDUCT_SQL.INIT_PROCESS - This initializes a row in svc_process_tracker for asynchronous processing.

• REPL_INDUCT_SQL.EXEC_ASYNC - This function calls the main induction process that uploads data into the staging tables, validates and inserts data into the base RMS replenishment schedule tables.

Scheduling Constraints

Table 13-41 Scheduling Constraints

Schedule Information	Description
Processing Cycle	Adhoc
Frequency	Daily
Scheduling Considerations	NA
Pre-Processing	NA
Post-Processing	NA
Threading Scheme	NA

Restart/Recovery

NA

Key Tables Affected

Table 13-42 Key Tables Affected

Table	Select	Insert	Update	Delete
S9T_FOLDER	No	Yes	No	No
S9T_TEMPLATE	Yes	No	No	No
SVC_PROCESS_TRACKER	No	Yes	No	No
SVC_REPL_ATTR_UPDATE	Yes	Yes	No	Yes
REPL_ATTR_UPDATE_HEAD	Yes	Yes	Yes	Yes
REPL_ATTR_UPDATE_ITEM	Yes	Yes	Yes	Yes
REPL_ATTR_UPDATE_LOC	Yes	Yes	Yes	Yes
CORESVC_REPL_ERR	Yes	Yes	No	No
S9T_ERRORS	Yes	Yes	No	No