11 Replenishment
Replenishment is a complex business process that monitors stock levels and creates transactions to ensure that stores and warehouses have optimal stock levels.
Merchandising supports a number of replenishment methods, which are associated with each item/location being replenished. Each replenishment method uses a specific 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 a warehouse to store, or both, such as in the case of a cross-docked order.
The main purpose of this chapter is to describe the batch processes involved in replenishment. For additional information about the parameters and different replenishment methods, see the Merchandising Documentation Library (Doc ID: 1585843.1).
Replenishment Sub Processes
Replenishment can be divided into four major sub-processes:
Manage Replenishment Attributes
Replenishment attributes are set up for item/locations, or higher levels, using the Merchandising UI or uploaded from an external system using one of the supported integration methods. Attribute updates managed at levels higher than item/location or that are scheduled for future updates require backend processing to help manage the updates. Additionally, for some methods or configurations, there is other supporting data that requires batch processes to periodically refresh data, including that for size profiles and maximums for Floating Point replenishment.
-
Update Replenishment Size Profile (replsizeprofile) is used to copy size profile information from Allocation to Merchandising. If used, the size profiles in this table are used to spread attributes from the parent item/diff level down to the transaction item level.
-
Update Replenishment Calculation Attributes (rplatupd) is used to stage updates, when replenishment attributes are updated at a level above transaction item/location in Merchandising. This includes attributes maintained using item lists, parent items, location lists, or other location groupings.
-
Update Replenishment Calculation Attributes by Item/Locrilmaint) works in conjunction with the Update Replenishment Calculation Attributes process, but is used to update certain attributes of items and item/locations to the replenishment working tables, such as store order multiple, item status, pack sizes, and so on.
-
Recalculate Maximum Levels for Floating Point Replenishment (repladj) is used to calculate the maximum level for all item/locations set up to use the Floating Point replenishment method based on sales history.
Calculate Recommended Order Quantities
The next section of replenishment programs are focused around generating recommended order quantities (ROQs). Many user and batch processes combine to calculate ROQ. Item/location combinations follow different paths to calculate ROQ depending on whether they are replenished from a warehouse or from a supplier.
-
Calculate Net Inventory (replroq.ksh) is used to calculate the net inventory values that are used throughout the replenishment batch processing.
-
ROQ Calculation and Distribution for Item/Locs Replenished from WH (reqext) is used to calculate and create orders for item/stores that are sourced from warehouses. The batch_reqext process is used to run reqext with multiple threads.
-
ROQ Calculation and Distribution for Item/Locs Replenished from Supplier (rplext.ksh) evaluates all other item/locations not processed by reqext and calculates recommended order quantities. These are written to REPL_RESULTS to be built into orders in a later process.
If using the Investment Buy feature in Merchandising, then there are two other programs that are relevant for ROQ calculation:
Build Orders and Transfers
This section of programs create purchase orders and transfers based on the calculated ROQs.
-
Split Replenishment Orders Among Suppliers (supsplit) splits recommended order quantities using the ratios defined for an item/location, if using the supplier distribution ratios feature.
-
Build Replenishment Orders (rplbld) uses ROQs and investment buy results to build replenishment orders, including grouping like line items together to consolidate orders, where possible.
-
Scale Purchase Orders Based on Supplier Constraints (supcnstr) scales POs based on supplier constraints. See the Purchase Order chapter for details on this process.
-
Truck Splitting Optimization for Replenishment (rplsplit) splits POs and Allocations to optimize truck loads
-
Approve Replenishment Orders (rplapprv) reviews all orders created as part of the replenishment process and determines which orders can be approved. In order to be approved, an order must have an order control of Automatic and must meet vendor minimums.
Additional batch processes that may apply for this section of batches, depending on your implementation:
-
Update Replenishment Order Taxes (batch_rplapprvgtax.ksh) updates tax information when configured to run Brazil Tax as your default tax type.
-
Sync Replenishment Franchise Orders (repl_wf_order_sync.ksh) creates appropriate franchise orders for approved allocations created during replenishment
Cleanup Replenishment Data
The programs in this section are used to clean up temporary tables used in the above programs, or to remove historical attribute and result information.
-
Purge Scheduled Replenishment Induction Staging Tables (repl_indctn_purge.ksh) - see the Merchandising Operations Guide Volume 2 for details on integrating replenishment attributes from an external source.
There is also an option of running a background process for some of the above cleanup jobs, as an alternative to running during the batch schedule. The background job options are:
Approve Replenishment Orders (rplapprv)
|
Module Name |
rplapprv.pc |
|
Description |
Approve Replenishment Orders |
|
Functional Area |
Replenishment |
|
Module Type |
Business Processing |
|
Module Technology |
ProC |
|
Catalog ID |
RMS300 |
|
Wrapper Script |
rmswrap.ksh |
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, 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 supplier inventory management table. There is a flag that determines if they are applied at the order level or at the location level. Vendor minimums at the item level are held on the item/supplier/country table.
When an order fails the minimums, and the flag is set to 'N', a failure at any level causes the order to be placed in worksheet status. When the flag is 'Y', a failure at the location level causes the offending location to be deleted; a failure at the item level causes the problematic item 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 flag is set to 'Y', a record is written to the supplier minimum failures 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 warehouse. If the vendor minimum is not met for a physical location, all the virtual warehouses on the order within the physical warehouse will need to be removed along with associated allocations.
The pre-processing function for this batch program on prepost truncates the supplier minimum failures table.
Build Replenishment Orders (rplbld)
|
Module Name |
rplbld.pc |
|
Description |
Build Replenishment Orders |
|
Functional Area |
Replenishment |
|
Module Type |
Business Processing |
|
Module Technology |
ProC |
|
Catalog ID |
RMS314 |
|
Wrapper Script |
rmswrap_multi.ksh |
Design Overview
This batch program builds Merchandising orders from recommended order quantities (ROQ) generated by the replenishment extract and investment buy calculation processes. The apply type A, C & D contracts to orders created by replenishment batch associates contracts with the ROQs created by the ROQ calculation and distribution for item/locations replenished from supplier program. These ROQs are placed on a temporary table by the replenishment extract and investment buy calculation processes. All records on the temporary tables are processed by this batch each night. These temporary table records are placed into logical groups, and a Merchandising order is created for each logical group.
In order to be placed in the same order group, the item/location ROQs from the temporary tables 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 order inventory management table, two other criteria can be used for splitting order groups. First, if the inventory management level is set to 'D'ept, only items in a single department are allowed in an ordering group. Secondly, the single location indicator can be set to 'Y'es. If this is the case, only one location is allowed per ordering group. Finally, an item may only exist in an ordering group with a single origin country. When an item/location ROQ temporary table 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 replenishment results record, associated with the order temporary table record being processed, is updated with the order number and allocation number that the order temporary table record was placed with. Investment Buy results is also updated with the order number.
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.
Calculate Net Inventory (replroq.ksh)
|
Module Name |
replroq.ksh |
|
Description |
Calculate Net Inventory |
|
Functional Area |
Replenishment |
|
Module Type |
Business Processing |
|
Module Technology |
ksh |
|
Catalog ID |
RMS308 |
|
Wrapper Script |
rmswrap_shell.ksh |
Design Overview
This module performs the bulk of the logic to process and persist the replenishment data into replenishment net inventory temp table. (The information on this table is extracted by the reqext batch program.)
The wrapper script does the following things:
-
Insert records into the staging table and determines the thread id of each record.
-
Retrieves the max concurrent thread from to determine the maximum number of concurrent process the wrapper should run at a time.
-
Moves the records from a staging table to a temporary table and will calculate the net inventory position and determine the ROQ of items which are on replenishment.
The pre-processing function of this batch program in prepost truncates the records from the replenishment net inventory temp tables, and builds replenishment distribution temp and replenishment allocation in temp tables.
Calculate ROQ for Profitable Investment Buys (ibcalc)
|
Module Name |
ibcalc.pc |
|
Description |
Calculate ROQ for Profitable Investment Buys |
|
Functional Area |
Replenishment |
|
Module Type |
Business Processing |
|
Module Technology |
ProC |
|
Catalog ID |
RMS249 |
|
Wrapper Script |
rmswrap_multi.ksh |
Design Overview
The 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 the 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.
The pre-processing for this batch in the prepost program sets the status of investment buy from 'W' (worksheet) to 'U' (unprocessed).
Determines Eligible Investment Buy Opportunities (ibexpl)
|
Module Name |
ibexpl.pc |
|
Description |
Determines Eligible Investment Buy Opportunities |
|
Functional Area |
Investment Buy |
|
Module Type |
Business Processing |
|
Module Technology |
ProC |
|
Catalog ID |
RMS250 |
|
Wrapper Script |
rmswrap.ksh |
Design Overview
The batch program pre-qualifies investment buy (IB) eligible wh/dept and IB eligible supp/dept/locs.
The warehouse/department table holds IB parameters at the warehouse or at the warehouse/department level. If there are IB parameters defined at the warehouse/department level, they are used. If there are no IB parameters defined at the warehouse/department level, the IB parameters at the warehouse 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 warehouse/department level no matter what level they are held at in the database. The results are written to the warehouse/department explode table.
Next the warehouse/department explode table is combined with supplier inventory management data to get the final list of all eligible supplier/department/locations. 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:
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:
-
Supplier (S)
-
Supplier/department (D)
-
Supplier/location (L)
-
Supplier/department/location (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 (supplier). If no record exists as the supplier level, it is not IB eligible.
-
Supplier
-
Supplier/department -> Supplier
-
Supplier/location -> Supplier
-
Supplier/department/location -> Supplier/department ' Supplier
The second part of this program explodes the supplier inventory management data down to the supplier/department/location level by filling in the implied rows. The exploded supplier inventory management information is only done for IB eligible warehouse/department combinations from the warehouse/department explode table. The results are placed on the SIM explode table.
Multithreading Wrapper for reqext (batch_reqext.ksh)
|
Module Name |
batch_reqext.ksh |
|
Description |
Multithreading Wrapper for reqext |
|
Functional Area |
Replenishment |
|
Module Type |
Admin |
|
Module Technology |
ksh |
|
Catalog ID |
RMS192 |
|
Wrapper Script |
N/A |
Purge Aged Buyer Worksheet Results (buyer_wksht_purge_job)
|
Module Name |
buyer_wksht_purge_job |
|
Description |
Purge Aged Buyer Worksheet Results |
|
Functional Area |
Replenishment |
|
Module Type |
Admin - Ad hoc |
|
Module Technology |
Background Processing |
|
Catalog ID |
N/A |
|
Wrapper Script |
b8dwrap.ksh |
Design Overview
This background job is composed of two steps processing. It will have a threading assignment and a business logic processing.
Thread assignment program will filter eligible records from buyer worksheet manual results table based on its purge criteria from system parameter settings. The Replenishment Result Purging Cycle parameter will determine those unneeded records that are older than predetermined number of days from its creation date. These records are chunked and Thread ID is assigned for each. They will be stored temporarily in a staging table.
The Business logic program will process all records from the staging table. Using bulk processing, this program will delete old records from buyer worksheet manual table. It will free up and clean the staging table afterwards. There is a STOP ON NEXT feature in bulk processing (through a loop) where Administrators can stop this batch with a flip of this indicator.
Purge Aged Investment Buy Results (investment_buy_purge_job)
|
Module Name |
investment_buy_purge_job |
|
Description |
Purge Aged Investment Buy Results |
|
Functional Area |
Replenishment |
|
Module Type |
Admin - Ad hoc |
|
Module Technology |
Background Processing |
|
Catalog ID |
N/A |
|
Wrapper Script |
b8dwrap.ksh |
Design Overview
This background job is composed of two steps processing. It will have a threading assignment and a business logic processing.
Thread assignment program will filter eligible records from investment buy results table based on its purge criteria from system parameter settings. The Replenishment Result Purging Cycle parameter will determine those unneeded records that are older than predetermined number of days from its creation date. These records are chunked and Thread ID is assigned for each. They will be stored temporarily in a staging table.
The Business logic program will process all records from the staging table. Using bulk processing, this program will delete old records from investment buy results table. It will free up and clean the staging table afterwards. There is a STOP ON NEXT feature in bulk processing (through a loop) where Administrators can stop this batch with a flip of this indicator.
Purge Aged Replenishment Results (replenishment_purge_job)
|
Module Name |
replenishment_purge_job |
|
Description |
Purge Aged Replenishment Results |
|
Functional Area |
Replenishment |
|
Module Type |
Admin - Ad hoc |
|
Module Technology |
Background Processing |
|
Catalog ID |
N/A |
|
Wrapper Script |
b8dwrap.ksh |
Design Overview
The replenishment extraction programs write a number of records to Replenishment Results. This table holds information that is relevant to replenishment processes. Over time, records on this table become unneeded and must be cleared out.
This background job is composed of one step processing only. It will retain the business logic processing from the original batch program algorithm.
The Business logic program will invoke a call to a new program specific for handling historical tables such as replenishment results table that are considered partitioned tables. PARTITION_SQL.PURGE_INTERVAL_PARTITION is called passing the target table name "REPL_RESULTS" and will execute the proper deletion/purging of records from target table by exercising table partitioning handling such as Dropping Interval Partition (same as truncate or delete from table).
The purge program considered the system parameter setting, Replenishment Results Purging Cycle to determine those records that are older than a predetermined number of days.
Purge Aged Replenishment Results (rplprg)
|
Module Name |
rplprg.pc |
|
Description |
Purge Aged Replenishment Results |
|
Functional Area |
Replenishment |
|
Module Type |
Admin |
|
Module Technology |
ProC |
|
Catalog ID |
RMS316 |
|
Wrapper Script |
rmswrap.ksh |
Design Overview
The replenishment extraction programs write a number of records to replenishment results. Store orders populate the store orders table. The investment buy process writes records to IB results and the Buyer Worksheet Form populates buyer worksheet manual table. 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.
Purge Aged Store Orders Results (store_orders_purge_job)
|
Module Name |
store_orders_purge_job |
|
Description |
Purge Aged Store Orders Results |
|
Functional Area |
Replenishment |
|
Module Type |
Admin - Ad hoc |
|
Module Technology |
Background Processing |
|
Catalog ID |
N/A |
|
Wrapper Script |
b8dwrap.ksh |
Design Overview
This background job is composed of two steps processing. It will have a threading assignment and a business logic processing.
Thread assignment will filter eligible records from store orders results table based on its purge criteria from system parameter settings. The Replenishment Result Purging Cycle parameter will determine those unneeded records that are older than predetermined number of days from its creation date. These records are chunked and Thread ID is assigned for each. They will be stored temporarily in a staging table.
The Business logic program will process all records from the staging table. Using bulk processing, this program will delete old records from store orders results table. It will free up and clean the staging table afterwards. There is a STOP ON NEXT feature in bulk processing (through a loop) where Administrators can stop this batch with a flip of this indicator.
Purge Replenishment Attribute History (rplathistprg)
|
Module Name |
rplathistprg.pc |
|
Description |
Purge Replenishment Attribute History |
|
Functional Area |
Replenishment |
|
Module Type |
Admin |
|
Module Technology |
ProC |
|
Catalog ID |
RMS312 |
|
Wrapper Script |
rmswrap.ksh |
Purge Replenishment Results History by Month (rplprg_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 |
|
Wrapper Script |
rmswrap.ksh |
Design Overview
The replenishment extraction programs write a number of records to replenishment results. Store orders populate the store orders table. The investment buy process writes records to IB results and the Buyer Worksheet Form populates buyer worksheet manual table. These tables hold information that is relevant to replenishment processes. Over time, records on these tables become unneeded and must 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 defined as a system parameter. The eways ewInvAdjustToRMS, ewReceiptToRMS need to be shutdown when this program is run.
Purge Scheduled Replenishment Induction Staging Tables (repl_indctn_purge.ksh)
|
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 |
N/A |
|
Wrapper Script |
N/A |
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 Merchandising 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 (that is, the action date is earlier than the retention date)
Recalculate Maximum Levels for Floating Point Replenishment (repladj)
|
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 |
|
Wrapper Script |
rmswrap_multi.ksh |
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 item/location replenishment 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/location history table.
ROQ Calculation and Distribution for Item/Locs Replenished from WH (reqext)
|
Module Name |
reqext.pc |
|
Description |
ROQ Calculation and Distribution for Item/Locations Replenished from Warehouse |
|
Functional Area |
Replenishment |
|
Module Type |
Business Processing |
|
Module Technology |
ProC |
|
Catalog ID |
RMS310 |
|
Runtime Parameters |
rmswrap_shell.ksh |
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 tablebased 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 Franchise Order Number 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.
The pre-processing function of this batch in prepost will create transfer header records for unique combinations of warehouse and store, stock category and department.
The post-processing function of this batch will update the transfer status to Approved.
Restart/Recovery
The logical unit of work is an item/source warehouse. Restart/recovery is achieved implicitly because item/location replenishment 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 the maximum commit counter 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.
ROQ Calculation and Distribution for Item/Locs Replenished from Supplier (rplext.ksh)
|
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 |
|
Wrapper Script |
rmswrap_shell.ksh |
Design Overview
Vendor Replenishment Extraction, which uses 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 the temporary order table and replenishment results. The temporary order table is later reviewed by the batch in its evaluation of orders against contract types A, C, D, whereas replenishment results is processed by build replenishment orders.
The wrapper script does the following things:
-
Calls the function will insert records into the replenishment ROQ table and determines the thread id of each record.
-
Retrieves the max concurrent thread from configuration table to determine the maximum number of concurrent processes the wrapper should run at a time.
-
For each thread, call the function that will move the records from the replenishment ROQ table to the replenishment ROQ global temporary table and the processed records will be inserted to the temporary order and replenishment results tables.
The pre-processing function for this program in the prepost batch truncates records form the temporary order table and the missed order table.
The post-processing function for this program truncates the replenishment distro temp and replenishment allocation in temp table.
Restart/Recovery
If the program fails, the program can be restarted and it will process the remaining records on replenishment table.
Performance Considerations
The values on RMS_PLSQL_BATCH_CONFIG can be change to alter the behavior of the chunking and threading process.
MAX_CHUNK_SIZE - determines the maximum number of rows that should be processed for a given thread. Currently, this is set to 10000.
MAX_CONCURRENT_THREAD - determines the maximum number of parallel threads for a given run. Currently, this is set to 32.
Split Replenishment Orders Among Suppliers (supsplit)
|
Module Name |
supsplit.pc |
|
Description |
Split Replenishment Orders Among Suppliers |
|
Functional Area |
Replenishment |
|
Module Type |
Business Processing |
|
Module Technology |
ProC |
|
Catalog ID |
RMS370 |
|
Wrapper Script |
rmswrap_multi.ksh |
Design Overview
This program splits replenishment orders among different suppliers based on the supplier distribution ratio setup for an item/location on replenishment. It applies to Direct to Store, Crossdock replenishments and warehouse stocked replenishments where a purchase order will be created from a supplier.
Sync Replenishment Franchise Orders (repl_wf_order_sync.ksh)
|
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 |
|
Wrapper Script |
rmswrap_shell.ksh |
Truck Splitting Optimization for Replenishment (rplsplit)
|
Module Name |
rplsplit.pc |
|
Description |
Truck Splitting Optimization for Replenishment |
|
Functional Area |
Replenishment |
|
Module Type |
Business Processing |
|
Module Technology |
ProC |
|
Catalog ID |
RMS318 |
|
Wrapper Script |
rmswrap_multi.ksh |
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 the order approve indicator set to Yes.
-
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.
Update Replenishment Calculation Attributes (rplatupd)
|
Module Name |
rplatupd.pc |
|
Description |
Update Replenishment Calculation Attributes |
|
Functional Area |
Replenishment |
|
Module Type |
Business Processing |
|
Module Technology |
ProC |
|
Catalog ID |
RMS313 |
|
Wrapper Script |
rmswrap_multi.ksh |
Design Overview
The batch module reads replenishment attributes from the replenishment attribute item and location 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 a separate table. Review cycle information is kept on another table, and the rejected records are written to the mass change rejections table for later reporting.
The pre-processing function of this batch program on prepost truncates records in the mass change rejections table.
The post-processing function of this batch program on prepost locks and deletes records form the various replenishment attributes tables.
Update Replenishment Calculation Attributes by Item/Locrilmaint)
|
Module Name |
rilmaint.pc |
|
Description |
Update Replenishment Calculation Attributes by Item/Location |
|
Functional Area |
Replenishment |
|
Module Type |
Business Processing |
|
Module Technology |
ProC |
|
Catalog ID |
RMS311 |
|
Wrapper Script |
rmswrap_multi.ksh |
Design Overview
This module transfers the replenishment attributes from the item/location replenishment updates table to the item/location replenishment table. Item/location replenishment 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 item/location replenishment updates table, this program will note the type of change and will update item/location replenishment table appropriately.
Update Replenishment Order Taxes (batch_rplapprvgtax.ksh)
|
Module Name |
batch_rplapprvgtax.ksh |
|
Description |
Update Replenishment Order Taxes |
|
Functional Area |
Replenishment |
|
Module Type |
Business Processing |
|
Module Technology |
ksh |
|
Catalog ID |
RMS194 |
|
Wrapper Script |
N/A |
Design Overview
This script calls a function to enable parallel execution via multiple thread calls compute taxes for approved replenishment orders. Computed taxes are inserted/updated into the order tax breakup table.
This batch should be run only for Global Tax (GTAX) configuration.
Restart/Recovery
The logical unit of work is a set of purchase orders. Purchase order numbers in the replenishment approval 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 replenishment approval GTAX queue. Any restart after a fatal error will include the failed purchase order numbers when assigning new threads.
Update Replenishment Size Profile (replsizeprofile)
|
Module Name |
replsizeprofile.pc |
|
Description |
Update Replenishment Size Profile |
|
Functional Area |
Replenishment |
|
Module Type |
Business Processing |
|
Module Technology |
ProC |
|
Catalog ID |
RMS309 |
|
Wrapper Script |
batch_replsizeprofile.ksh |
Design Overview
The batch module will do a total synchronization update of the Merchandising size profile table with data from the Allocation size profile table if the Allocation product is installed. It will also do a complete refresh of the size profile materialized view used by the replenishment attributes update batch and the replenishment attributes screen when size curves are applied to the items being replenished.