Replenishment Policies

A pick face that runs dry is usually only noticed when a picker arrives at an empty shelf. Replenishment Policies let ShipStream watch for you: a Policy pairs a group of Products with a Replenishment Lane and measures each SKU's coverage in days of inventory (DOI) — the quantity on hand in the Lane's destination Location Profile divided by the SKU's recent daily pick rate. When a SKU's coverage falls below the Policy's Trigger DOI, ShipStream flags it along with the quantity needed to restore coverage to the Target DOI.

Daily pick rates come from ShipStream's Product Velocity data, so a Policy can flag not only SKUs that are running low in the Profile, but also SKUs that are selling and were never stocked there in the first place. Each Policy chooses which picks count toward that rate with its Demand Basis — see Choosing a Demand Basis.

Understand ShipStream: How Much Stock?

Stocking targets answer how much to keep within reach of your pickers. Giving every Product the same space does not give each one the same coverage: a fast-selling Product runs through its share sooner. Giving every Product the same number of days of stock can require very different amounts of room, especially when Products differ in size.

ShipStream lets you choose the balance. Policy (single DOI) gives matching Products the same days-of-inventory band. By Slot Type lets a cubby, shelf, and pallet face use different bands, while Product Overrides handle individual exceptions. For DOI-based sizing, daily demand multiplied by Target DOI gives the target quantity. More coverage takes more room; less coverage can mean more frequent replenishment. ShipStream uses your settings rather than automatically choosing an optimal division of space.

The example below holds demand and physical pick faces constant. Change the targets to see which fit. Use one DOI makes the tailored targets identical to equal-time stocking, so you can see that the benefit comes from the settings you choose, not a different calculation.

Stocking quantity is separate from placement priority. Understand who gets first choice of a preferred Location to see how the three Rank Formula options compare.

How to Create a Replenishment Policy

1. Navigate to System -> Operations -> Replenishment Policies.
2. Click Create Replenishment Policy.
3. Choose the Warehouse first — it scopes the Lane and Handling Class choices, and it cannot be changed after the Policy is saved.
4. Fill in the remaining fields (see the reference table below) and click Save Replenishment Policy.

After a Policy is saved, its form also shows two read-only rows: Qualification (whether the Policy participates in evaluation, with an explanation when it does not) and Replenishment Build (whether the figures come from the latest published calculation, and the current Flagged SKUs count).

Each Replenishment Lane also has an Open Task Cap. A positive lane cap and a positive Warehouse cap are both required before the lane can dispatch work. Needs above either cap remain visible rather than being discarded.

An administrator with access to only some Merchants can create and edit Policies limited entirely to those Merchants. A Policy that also applies to other Merchants is shown read-only in the grid without the other Merchant names or result counts. A Policy that applies only to inaccessible Merchants is hidden.

How Policies Are Evaluated

Each SKU is governed by at most one Policy. Policies are evaluated from the lowest Sort Order upward, and the first qualified Policy whose subject (Merchants, Product Profiles, Handling Classes) matches the SKU wins; later Policies never see that SKU. Administrators with access to all Merchants can adjust precedence directly from the grid using the editable Sort Order column.

For each SKU the winning Policy governs, ShipStream divides the quantity on hand in the Lane's destination Location Profile by the SKU's average daily pick rate over the Demand Period, on the Policy's Demand Basis, to get its days of inventory. A SKU whose coverage is below the Trigger DOI is flagged, along with the quantity needed to bring coverage back up to the Target DOI.

SKUs that Slotting Rules forbid in every Location of the Profile are excluded automatically — there would be nowhere to put the replenished stock — and are reported in the Slotting Forbidden count instead.

A SKU that matches Policies in several Lanes produces a need only in the Lane with the lowest Sort Order; the other matches are listed under Suppressed In on the Replenishment Report so demand is never counted twice.

Top-Off

The trigger fires when coverage has already dropped below Trigger DOI. Top-Off lets a Policy act earlier: when a SKU's Inventory Position falls below the Top-Off Threshold percentage of its target level, the SKU is flagged with a Top-off trigger on the Replenishment Report. This is useful when replenishment runs on a schedule and you would rather fill a face to its target during a quiet period than wait for it to run low during a wave.

The Top-Off Schedule limits when a top-off may act. Click Add Window and choose a Day, a Start Time, and an End Time, or tick To end of day to run to midnight. An end time earlier than its start is an overnight window that ends the next day. Windows must not overlap. When a SKU meets the threshold outside every window, the report shows it as Waiting for Top-off window with the time it next becomes eligible.

Choosing a DOI Basis

Choose Policy (single DOI) when every matching SKU should use one Policy trigger and target. Choose By Slot Type when the amount of stock held in different kinds of pick face should control the replenishment band.

You can switch between the two choices while editing without losing unsaved override values. If you save the Policy with Policy (single DOI) selected, ShipStream removes its Slot Type DOI Overrides because they do not apply in that mode.

When using By Slot Type, ShipStream finds the SKU's classified Location in the selected Location Profile with the lowest Location priority (and then the lowest Location ID when priorities tie). It uses that Location's Slot Type to resolve the schedule in this order:

1. A Slot Type DOI Override on the Policy.
2. The Slot Type's Trigger DOI and Target DOI from its Replenishment Defaults.
3. The Policy's Fallback Trigger DOI and Fallback Target DOI.

The selected Slot Type chooses only the DOI band. DOI itself still uses all on-hand quantity in the Policy's Location Profile, not just the selected Location or Slot Type.

The Effective DOI Schedule Preview shows one row for each Slot Type present in the selected Location Profile. DOI values and the DOI Source use the current unsaved form values. The SKU count comes from SKUs assigned to that Policy by the latest completed Replenishment build.

For each row, ShipStream multiplies the published daily demand by the current Target DOI and compares it with known Slot Capacity. When no authoritative capacity is available but both the Slot Type and SKU have dimensions, the preview labels and uses a slot-cube divided by unit-cube estimate. It reports how many assessable SKUs exceed capacity, how many could not be assessed, and how many used dimension estimates. If Slotting is forbidden for a SKU in that Slot Type, the preview shows a separate warning rather than treating it as a capacity failure.

Assignment warnings use current Locations in the Location Profile for the latest build's winning SKUs. Location-priority and Location Profile membership changes appear after the Warehouse's next Replenishment rebuild. Ordinary inventory movements do not change the selected Slot Type. A Pending rebuild, Building, or Build failed badge warns when the latest completed build may lag current changes; unavailable figures are not shown as false zeroes.

Choosing a Demand Basis

A SKU's daily pick rate is only as broad as the picks you count, and that is what Demand Basis decides.

• Pickable counts only picks made from pickable Locations. A SKU that ships entirely out of reserve records no demand at all, so it is never flagged. Choose this when the Policy is maintaining pick faces that are already working — the demand you are sizing against is the demand that pickable Locations actually serve.
• Overall counts every pick, including those served from reserve. A SKU that sells but has never been slotted now carries its full pick rate, which is what makes it eligible to be flagged to Slot. Choose this when the point of the Policy is to find SKUs that ought to be in the Profile and are not.

A SKU with no picking history at all is never flagged on either basis — there is nothing to measure.

Reading the Grid

The grid at System -> Operations -> Replenishment Policies shows each Policy's Name, Warehouse, Active state, Subject (the Merchants, Product Profiles, and Handling Classes it selects), Lane, Location Profile (the Lane's destination), fallback Trigger DOI and Target DOI, Demand Period, Demand Basis, Qualification, Sort Order, result counts, Replenishment Build, and Updated At.

The three result counts come from the Warehouse's latest published replenishment calculation. They are empty until the Warehouse publishes its first result; after that, a zero is a real finding and shows as 0.

Replenishment Build shows whether those counts are Current, Rebuild pending, Building, Build failed, or Not built yet. Previous data shown means the numeric counts are still from the last successful build while a newer one is pending, building, or failed.

Qualification

The Qualification column shows whether a Policy currently participates in evaluation. A Policy that cannot be evaluated is skipped, and its Products fall through to the next matching Policy.

For Profile-related disqualifications, the Qualification row on the Policy's form links directly to the Location Profile so you can open and fix it.

Product Overrides

Most SKUs should follow their Policy's sizing, but some deserve their own numbers: a promotional item that needs deeper coverage, a bulky Product whose pick face only holds so much, or a SKU that should always be topped up to a fixed shelf quantity. Product Overrides carry those exceptions.

Open a saved Policy and scroll to Product Overrides. A new Policy must be saved before overrides can be added, because each override belongs to exactly one Policy. Click Add Product Override, choose the Product with Choose Product... (the picker offers only Products the Policy selects and hides Products that already have an override on this Policy), and pick one Sizing Mode:

Click Save Product Override. On the Replenishment Report the row's Sizing Source reads Product override. A disabled Product keeps its override, which takes effect again when the Product is re-enabled. If the Policy later stops selecting the Product, the override is marked Out of subject and produces nothing until you delete it or return the Product to the Policy's subject.

Replenishment Move Size

Replenishment usually moves whole handling units, such as a case or an inner pack, rather than loose units. An override can record that in two ways under Replenishment Move Size:

• Move Multiple on its own, for example 5 when the SKU is moved in stacks of five. This is advisory and shows a Confirmation of Not applicable.
• UOM Product, the case or pack Product this SKU is replenished from. ShipStream derives the multiple from the two Products' quantity Bill of Materials and shows Confirmed. A value typed in Move Multiple is only checked against that derivation.

If the Bill of Materials between the two Products later changes, the override becomes Stale: the last confirmed multiple stays visible but is not used for new work until you review it and click Reconfirm UOM with a reason. An override whose multiple the Product can no longer hold shows Unusable and must be edited or cleared.

Locking and Audit History

Lock pins an override so routine edits cannot change it. A locked override refuses ordinary saves and deletes; users with the Edit Locked permission may still save it with a fresh Edit Reason, without releasing the lock. Unlock is its own action. Each of these asks for an Action Reason so whoever reads the history later knows why.

Every change (create, edit, lock, unlock, reconfirm, delete, and the automatic invalidation after a Bill of Materials change) adds a row to Product Override Audit History below the overrides grid, with the user, the reason, and the before and after values. History is never edited or removed and survives the override's deletion. If two people edit the same override at once, the second save is refused with a request to reload, so nothing is overwritten silently.

Deleting a Replenishment Policy

A Replenishment Policy whose results are still part of the Warehouse's published calculation cannot be deleted yet. Set the Policy's Active field to No first; once the Warehouse publishes an updated result without it, click Delete Replenishment Policy on the Policy's form.