The Replenishment Batch Flow

While REPL_ITEM_LOC defines the rules, the actual work of automated ordering happens overnight during the RMS batch window. Replenishment in RMS is broken down into a multi-step sequence of Pro*C batch programs.

This multi-step approach is crucial: it allows RMS to calculate the pure "need" first, then apply constraints (like investment buying or supplier minimums), and finally generate the actual documents (POs or Transfers).

Requirement Extraction (reqext.pc)

The Requirement Extraction program is the heavy lifter.

What it does:

1. It scans REPL_ITEM_LOC for all active records.
2. It checks the Review Cycle. If the item is not scheduled for review today, it skips it.
3. It calculates Net Inventory (SOH + In Transit + On Order - Reserved).
4. It evaluates the Net Inventory against the replenishment method thresholds (Min/Max, Dynamic, etc.).
5. If the Net Inventory is below the threshold, it calculates the raw quantity required to reach the Max level.

Where it writes:

The output of reqext.pc is written to the REPL_RESULTS table. This table contains the raw "need" for every item/location that triggered tonight.

Replenishment Build (rplbld.pc)

Once reqext.pc has identified what needs to be ordered, Replenishment Build takes over.

What it does:

1. It reads the raw requirements from REPL_RESULTS.
2. It looks at the sourcing rules. Should this requirement be fulfilled by a Warehouse (Transfer) or by a Supplier (Purchase Order)?
3. Scaling & Rounding: It applies supplier constraints. If the raw requirement is 12 units, but the supplier only sells in Cases of 10, rplbld.pc will round the order to either 10 or 20 based on the rounding rules in RMS.
4. It inserts headers and details into the ORDHEAD/ORDLOC tables (for POs) or TSFHEAD/TSFDETAIL tables (for Transfers) in a Worksheet (W) status.

Replenishment Approval (rplapprv.pc)

The final step in the core sequence is Replenishment Approval.

What it does:

By default, rplbld.pc creates orders in Worksheet status. rplapprv.pc attempts to automatically move these orders to Approved (A) status so they can be transmitted to the supplier (via EDI) or the warehouse (via RIB).

It evaluates conditions like:

• Does the Purchase Order meet the supplier's Minimum Order Quantity (MOQ)?
• Does the PO meet the supplier's Minimum Order Value (MOV)?
• Does the Transfer exceed available warehouse inventory?

If the order fails these checks, rplapprv.pc leaves it in Worksheet status, and a buyer must manually review it the next morning.

Troubleshooting Batch Failures

When replenishment "isn't working," it usually means one of the batches skipped an item. Here is how to trace it:

1. Check REPL_ITEM_LOC: Is the item active? Is today on its Review Cycle?
2. Check Net Inventory: Run the formula manually. Is the Net Inventory actually below the minimum?
3. Check REPL_RESULTS: Did reqext.pc write a record here? If yes, reqext worked fine.
4. Check ORDHEAD / TSFHEAD: Look for orders created by the batch user (usually RMSBATCH). Are they stuck in Worksheet status because they failed an MOQ check in rplapprv.pc?