How automatic replenishment works

How stock rules, the inventory scheduler, and PO confirmation work together to keep warehouses stocked automatically.

Updated October 29, 2026

Tooling items are high-variety, low-unit-cost, but operationally critical — a missing insert or the wrong holder can stop a machine. Managing replenishment manually across hundreds of SKUs is error-prone and time-consuming, which is why Tooling Metrics automates the entire chain from detection to purchase to putaway.

The three-part chain

Automatic replenishment works through three connected steps.

Stock Rules are the foundation. Each rule defines one replenishment policy: a specific item, in a specific condition, stored at a specific location, with a Threshold Quantity (the minimum) and a Max Capacity (the maximum). When the forecast at that location falls to the threshold or below, a replenishment is needed. The vendor a purchase request is directed to comes from the item itself (its Vendor or Service Vendor), not from the rule.

The Inventory Scheduler is the detection engine. It runs at configured intervals, reads all active stock rules, and compares each rule’s Threshold Quantity against the forecast at the rule’s location — on-hand minus pending outgoing plus pending incoming, so stock already on its way counts (see How the inventory model works). For every purchase-type rule whose forecast is at or below its threshold, the scheduler drafts a purchase request line targeting enough units to reach the Max Capacity. This batch approach is deliberate — running checks at intervals rather than reacting to every individual movement reduces noise and allows purchasers to review consolidated requests before sending orders.

PO Confirmation is the intentional manual checkpoint. Draft purchase orders are not sent to the vendor automatically — a purchaser reviews them, adjusts quantities or vendors if needed, and confirms. Once confirmed, Tooling Metrics immediately queues document creation for the incoming goods — configurable to create a Purchase Receipt, a Purchase Restock, both, or neither.

From confirmation to putaway

When a PO is confirmed, the organization’s automatic purchase setting determines what happens next.

Both (default): A Purchase Receipt and one or more Purchase Restocks are created. The Receipt covers the movement from the vendor’s inventory to the warehouse’s receiving area. Each Restock covers one Warehouse Access Point — as many Restocks are created as there are WAPs with stock rules that still have capacity for the item. The controller picks goods from the receiving area and follows each Restock document to the exact storage location it specifies.

Receipt only: A Purchase Receipt is created but no Restock. Physical putaway is handled manually.

Restock only: No Receipt is created — useful when the receiving step is handled externally. Restock documents are generated for guided putaway.

Off: No documents are created automatically. Both receipt and restock are handled manually.

The Restock documents are grounded in stock rules: each line targets a specific storage location and stops at the rule’s Max Capacity — it will not overfill a slot. If incoming goods exceed all available rule capacity at the warehouse, the system logs a warning to the purchaser rather than guessing a location.

Who the documents belong to

Each document the automation creates belongs to the person who will handle it, so it appears in their lists and they validate it at their access point.

Created by	Document	Belongs to
The inventory scheduler	Transfer	The administrator of the Warehouse Access Point that gives the stock
The inventory scheduler	Scrap List	The administrator of the storage device the stock is scrapped from
The inventory scheduler	Draft Purchase Order or Service Order	The administrator of the warehouse it is ordered for
PO confirmation	Purchase Receipt	The administrator of the order’s warehouse
PO confirmation	Purchase Restock	The administrator of the Warehouse Access Point it restocks at

When the access point’s or storage device’s administrator isn’t set, the document belongs to the warehouse’s administrator; when the warehouse’s isn’t set either, it belongs to the person who confirmed the order or ran the scheduler by hand. If the scheduler’s hourly run finds none of them, it creates nothing for that shortfall and warns the administrators instead.

Each document carries one creation comment saying what created it, signed by the person who confirmed the order or ran the scheduler by hand; on the hourly run, by the administrator it was created for.

Why rules are per condition

The same item can have multiple stock rules — one per condition. This is because the same physical item can be in different states that require different storage and different sourcing. A holder might need ten units in Brand new condition in the main tool crib, and five units in For service condition staged at the service shipping area. These are separate replenishment needs, separate locations, and potentially separate vendors (the main vendor for new stock, the regrinding vendor for service).

Transfers vs. purchase orders

The warehouse hierarchy determines what the scheduler creates when it detects a shortfall.

Purchase-type rules detect a shortage — the forecast falling to the Threshold Quantity or below. When triggered, the scheduler walks up the warehouse tree through all ancestors. For each ancestor that has a stock rule for the same item, it calculates how much that ancestor has above its own Threshold Quantity — the surplus. The ancestor protects its own safety stock first; only what exceeds its threshold is available to move down. The scheduler creates a Transfer for that surplus, reducing the outstanding demand. Whatever demand remains after all ancestors are exhausted goes onto a draft Purchase Order addressed to the root warehouse — goods arrive at the top of the hierarchy, and the next scheduler run transfers them the rest of the way down.

Service-type rules work in the opposite direction — they detect accumulation. When items awaiting service at a child warehouse’s staging location reach the Threshold Quantity, the scheduler creates a Transfer pushing them up to the root warehouse’s service area. If the warehouse being evaluated is itself the root, the scheduler drafts the service order directly instead of a transfer. This consolidates service shipments so the vendor receives one batch from across the site rather than separate packages from each tool crib.

Scrap-type rules detect the same kind of accumulation, but for items condemned to scrap. When stock in For scrap condition at a location reaches the rule’s Threshold Quantity, the scheduler adds it to a draft Scrap List for that storage device instead of creating a transfer or purchase order — consolidating write-offs so the disposal team works from one list per device rather than hunting for scrapped stock across locations.

The result

Once stock rules are configured, the warehouse manages itself. Purchasers no longer need to spot-check inventory before ordering — the scheduler does it for them. Controllers no longer need to decide where to put incoming goods — the restock document tells them. The human decisions move upstream to configuring the rules, leaving the routine execution to the system.