Go to primary content
Oracle® Retail Merchandising System Operations Guide, Volume 1 - Batch Overviews and Designs
16.0.024
E89599-02
  Go To Table Of Contents
Contents

Previous
Previous
 
Next
Next
 

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

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

    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

      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

      Transactions to Replenish Invetory

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

    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