Automated Replenishment Buy Plan

A replenishment buy plan is a proposed set of order lines, not a purchase order. For each SKU and location (or SKU and fulfillment node) the model scores coverage over the relevant lead-time horizon, then proposes a quantity, a suggested supplier or source, and a requested ship or receive window. The buyer still reviews those lines, edits them, and only then releases a PO through the existing procurement system.

The job is cost control under a service constraint. Overbuying ties up working capital, fills DCs and stores with the wrong depth, and raises markdown risk on seasonal or short-life goods. Underbuying shows up as lost sales, emergency freight, and fractured packs that cost more per unit than a planned order. The model’s role is to turn four operational inputs (demand forecast, on-hand and inbound stock, supplier lead time, and the service target the merchant actually holds) into a draft the buyer can approve in one pass.

This page is for the retail buyer who owns open-to-buy and vendor fill, not for a warehouse planner who is slotting inventory after the PO already exists. Category managers and replenishment analysts sit in the same loop when they own min/max, presentation stock, or vendor MOQs that the buyer will not override without a reason.

The model does not run on a SKU until four facts are present and internally consistent. Demand forecast means a dated quantity by SKU and location (or by SKU and cluster, if that is how the chain forecasts). Stock position means on-hand, on-order, and in-transit units in the same unit of measure as the forecast, with a cutoff timestamp. Lead time means the expected calendar days from PO release to available-to-sell at the destination, including vendor production or transit where that is how the chain measures it. Service target means the coverage rule the buyer already uses: a fill-rate or in-stock goal, a days-of-supply band, a presentation minimum, or a combination the planning system already stores.

If the forecast, the stock position, or the lead time is missing, incomplete, or not joinable on SKU and location, the SKU produces empty output. The plan does not backfill those fields from last year, from a sister SKU, or from a category average. Guessing a lead time of “about two weeks” or a stock figure of “whatever was on last week’s extract” is how phantom orders get into a buy. Empty is the correct result until operations or merchandising repairs the source.

Other fields improve the recommendation but do not substitute for those three. Case pack, MOQ, and order multiple keep the proposed quantity orderable. Cost, freight terms, and payment terms affect landed-cost ranking when more than one source can fill the need. Promotional lifts, seasonal profiles, and known stock-out history belong inside the forecast the planning team already signed, not as a second demand engine inside this use case. If those overlays never made it into the forecast file, the buy plan will not invent them.

Vendor calendars, freeze dates, and open-to-buy remaining are constraints the buyer applies at approval time. The model can flag a line that would break a freeze or exhaust a budget envelope when those fields are supplied. It still does not place the order.

Coverage is computed forward from the stock snapshot across the lead-time window, using the forecast as the depletion path. Projected available is on-hand plus inbound that will arrive inside the window, minus forecast demand and any reserved or allocated quantity the stock feed already subtracts. When projected available falls below the service rule (days of supply, presentation min, or the safety stock implied by the in-stock target), the model proposes a replenishment quantity that restores coverage to that rule, then rounds to pack and MOQ.

When two or more sources can supply the SKU, the recommendation ranks them on expected landed cost and on whether the lead time still hits the coverage date. A cheaper source that arrives after the projected stock-out is not treated as equivalent to a dearer source that arrives in time. The buyer sees both the primary recommendation and the rejected alternatives, with the reason (cost, lead time, MOQ, or capacity) attached to the line. That ranking is a suggestion. Contracted vendors, exclusives, and private-label sources stay under buyer control.

Exception logic belongs on the line, not in a separate dark process. Forecast step-changes, zero sales with high stock, inbound that already covers the horizon, and lead times longer than the remaining season should all produce a hold, a reduced quantity, or empty output rather than a full economic order. The model does not auto-split a need across vendors to “optimize” cost unless the buyer’s sourcing rules already allow split fills and the split still meets pack and MOQ.

The output artifact is a buy worksheet: SKU, location, recommended units, recommended source, need date, projected days of supply after arrival, and the inputs used (forecast version, stock as-of, lead-time source). Lines the model cannot score are listed as unscored with the missing input named. Nothing in that worksheet is a PO, an EDI 850, or a reservation against vendor capacity.

The buyer owns quantity, vendor, timing, and whether the line exists at all. Typical edits are cutting a recommendation that would break open-to-buy, raising a line for a display or reset the forecast did not include, switching vendor for a relationship or quality reason, and killing a line where the forecast looks wrong relative to what the merchant just saw on the floor or in the channel.

Approval is line-level or batch-level inside the buyer’s own workflow. A “recommend all” or “select all in-stock risks” action is acceptable only as a review accelerator. It must still require an explicit approve step, and it must not call the PO API. After approval, the existing purchase-order process (ERP, vendor portal, or EDI) creates the document, applies tax and Incoterms, and sends it. If the buyer walks away, the worksheet ages out. It does not become an order at midnight.

Service targets are a merchant decision, not a model default. A 98% in-stock goal on a key-value SKU and a make-to-order posture on a long-tail colorway are different policies. The plan should consume the target that merchandising already set. If no target is stored, treat that like a missing input: empty output for the SKU, not a silent company-wide fill-rate assumption.

Auditability matters when finance asks why a PO is larger than last cycle. Each approved line should retain the recommendation it started from, the buyer’s delta, and the input versions. That is how you separate a forecast error from a buyer override from a lead-time master-data miss.

Empty output is required, not optional, when forecast, stock, or lead time cannot be resolved for the SKU-location. The same rule applies when units of measure do not match (eaches vs. cases) and no trusted conversion exists, or when the stock as-of is older than the freshness window operations has set. A stale snapshot is a missing snapshot. Do not replenish against it.

Do not auto-place POs. Do not transmit EDI. Do not write a draft PO in the ERP that a night job could submit. Do not increment “on order” in the inventory ledger from a recommendation. Those updates happen only after the buyer approves and the procurement system creates the PO.

Other hard stops: new SKUs with no forecast and no agreed proxy stay unscored; negative stock without a confirmed adjustment stay unscored; lead times of zero or of implausible length (relative to the vendor master) stay unscored until master data is fixed. Promotional forecasts that have not been published into the demand file are not inferred from a marketing calendar.

Operational exceptions the buyer should see as flags, not as silent quantity changes: inbound already covering the horizon (recommend zero, show the inbound), MOQ larger than the need (show the cost of buying the multiple vs. waiting), and seasonal exit dates inside the lead time (recommend zero or a clearance-aware cut). Flags keep the human in the loop. Hidden clipping does not.