Oracle® Retail Merchandising System Operations Guide, Volume 1 - Batch Overviews and Designs 16.0.024 E89599-02 |
|
Previous |
Next |
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 can be divided into four major sub-processes:
Establishment/Management of Replenishment Calculation Attributes
Replenishment Calculation Attributes drive how quantities will be calculated. A number of UIs and batch processes maintain this data.
Calculation of Recommended Order Quantity (ROQ)
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).
If a client uses Investment Buying, additional calculations are performed to determine where additional profitable opportunistic purchases can be made.
Build Transactions to Replenish Inventory
Based on ROQ and Investment Buy, Purchase Orders, Allocations and Transfers are created.
Additional processing optimizes these transactions.
Cleanup of Replenishment Data
Cleanup processes purge aged data to ensure good performance.
Many user and batch processes combine to manage replenishment calculation attributes.
replsizeprofile.pc reconciles the size profiles in RMS and Allocations and refreshes the size profile materialized view used in replenishment processing.
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.
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).
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).
repladj.pc updates the Replenishment Attributes Working Table (repl_item_loc) for item/locations using the Floating Point Replenishment Method based on history.
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).
replroq.ksh determines working net inventory
batch_reqext.ksh multithreads reqext.pc
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. |
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.
If the customer uses Contracts, contracts are evaluated by cntrprss.pc. See the chapter ’Contracts' in this guide for more information.
If the customer uses Investment buying
ibexpl.pc determines eligible investment buy opportunities
ibcalc.pc calculates recommended investment buys that will meet the target return-on-investment
Transactions are built based on ROQ. Additional jobs optimize the resulting POs, Allocations and Transfers.
rplbld.pc uses ROQ and Investment Buy Results to build Orders
supcnstr.pc scales POs based on supplier constraints
rplsplit.pc splits POs and Allocations to optimize truck loads
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. |
batch_rplapprvgtax.ksh updates tax information (only necessary for GTAX implementations
repl_wf_order_sync.ksh creates appropriate franchise orders for approved allocations created during replenishment
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. |
rplprg.pc purges aged ROQ and investment buy results.
rplahistprg.pc purges aged replenishment attribute history.
rplprg_month.pc purges ROQ and investment buy results.
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
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 |
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.
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 |
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 |
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.
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) |
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.
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 |
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 |
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.
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) |
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.
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 |
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 |
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.
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.
Module Name | replroq.ksh |
Description | Calculate Net Inventory |
Functional Area | Replenishment |
Module Type | Business Processing |
Module Technology | ksh |
Catalog ID | RMS308 |
Runtime Parameters | NA |
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.
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 |
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.
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 |
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 |
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.
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 |
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 |
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.
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 |
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.
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 |
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 |
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.
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 |
If the program fails, the program can be restarted and it will process the remaining records on SVC_REPL_ROQ table.
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 |
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 |
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.
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 |
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).
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 |
Module Name | rplbld.pc |
Description | Build Replenishment Orders |
Functional Area | Replenishment |
Module Type | Business Processing |
Module Technology | ProC |
Catalog ID | RMS314 |
Runtime Parameters | NA |
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.
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. |
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
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 |
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 |
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.
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 |
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.
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 |
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.
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 |
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.
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 |
Module Name | rplapprv.pc |
Description | Approve Replenishment Orders |
Functional Area | Replenishment |
Module Type | Business Processing |
Module Technology | ProC |
Catalog ID | RMS300 |
Runtime Parameters | NA |
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
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 |
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.
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 |
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 |
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.
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 |
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.
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 |
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 |
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.
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 |
Module Name | rplprg.pc |
Description | Purge Aged Replenishment Results |
Functional Area | Replenishment |
Module Type | Admin |
Module Technology | ProC |
Catalog ID | RMS316 |
Runtime Parameters | NA |
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.
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.
Module Name | rplathistprg.pc |
Description | Purge Replenishment Attribute History |
Functional Area | Replenishment |
Module Type | Admin |
Module Technology | ProC |
Catalog ID | RMS312 |
Runtime Parameters | NA |
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.
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 |
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.
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.
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 |
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)
Restart ability will be implied, because the records that are selected from the cursor will be deleted before the commit.
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 |
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 |
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.
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 |