REPLENISHMENT BATCHES

• Replenishment means re-filling the quantities which has been consumedor used up.
• RMS replenishment provides an automated approach in calculating replenishment  quantities.
• Replenishment monitors available inventory, and expected demand (from Retail Demand Forecasting (RDF)).
• Orders and transfers will be suggested where available inventory is insufficient.



REPLENISHMENT BATCH PROCESS FLOW (WITH SUPPLIER SCALING)

1.   RPLATUPD.PC (Replenishment Attribute Update) :- 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.
Pre-Processing   :-  Prepost rplatupd pre – truncate  records in the  MC_REJECTIONS table.
Post-Processing :-  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.

2.   RILMAINT.PC (Replenishment Item Location Maintenance) :-  This module transfers the replenishment attributes from REPL_ITEM_LOC_UPDATES to REPL_ITEM_LOC. The REPL_ITEM_LOC_UPDATES is populated when certain attributes effecting 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 REPL_ITEM_LOC_UPDATES, RILMAINT.PC will note the type of change and update REPL_ITEM_LOC appropriately.
Post-Processing :- Prepost rilmaint post- truncate records on   EPL_ITEM_LOC_UPDATES  table.

3.  REPLADJ.PC (Replenishment Adjustment)  :-  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 dynamically calculates an order-up-to-level. The calculated order-up-to-level is written to 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.

4.   OCIROQ.C  (Recommended Order Quantity)  :-  This batch module is used to calculate the net inventory position of the items and determines the ROQ, which are on replenishment. The recommended order quantities are stored in RPL_NET_INVENTORY_TMP table. This information is extracted by REQEXT (item requisition extraction). During day runs, this program will process only Store Order records with delivery slots. During night runs, it processed all the records.

       Pre-Processing :- Prepost ociroq pre – truncate records in  RPL_NET_INVENTORY_TMP tables and build RPL_DISTRO_TMP and RPL_ALLOC_IN_TMP tables.

5.   RPLEXT.PC (Replenishment Extract) :-  RPLEXT (Vendor Replenishment Extraction) 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. During day runs, the batch processes only those rows which have been processed by reqext batch previously. It checks the RPL_NET_INVENTORY_TMP and processed only those present on that table during day run. In night runs, all the records will be processed.

       Pre-Processing  :-  Prepost rpl pre – truncate records in ORD_TEMP and  ORD_MISSED tables.

       Post-Processing :- Prepost rplext post – truncate records in tables RPL_DISTRO_TMP and    RPL_ALLOC_IN_TMP .

6.  RPLBLD.PC  (Replenishment Order Build) :- RPLBLD builds RMS orders from recommended order quantities (ROQ) generated by RPLEXT.PC and IBCALC.PC. 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.The grouping is based on different criteria like supplier,order status,contract(if any),department,location,origin country .

7.   SUPCNSTR.PC   (Supplier Constraint Scaling) :- This batch program processes all orders eligible for scaling during the nightly replenishment run. The purpose of this program is to select all of the orders created by the replenishment programs which are eligible for scaling. Once selected, the program serves as a wrapper program and sends each order number into the supplier constraint scaling library to actually perform the scaling on the order.The eligibility of the orders for scaling are based on order status,order date,origin type as replenishment,several indicators for due order,constrains,approval etc.

8.   RPLSPLIT.PC (Replenishment Splitting) :- The purpose of this program is to select all the orders for truck splitting, which are created by the replenishment programs. The orders that are eligible are sent into the truck splitting logic and the resulting orders are created.  The orders, which are 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.
• This batch will support the localization feature when system_options localization indicator is set to “Y”.

9.   RPLAPPRV.PC (Replenishment Approve) :-  This program looks at all replenishment, vendor and contract orders created during the nightly batch run. 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. 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, a record is written to the SUPS_MIN_FAIL table for reporting purposes. 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. 
Pre-Processing :- Prepost rplapprv pre – truncates sups_min_fail table.