ShipStream Knowledge Base
Warehouse

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 Location Profile and measures each SKU's coverage in days of inventory (DOI) — the quantity on hand in the Profile's Locations 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.

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 Location Profile 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.
FieldDescription
NameA descriptive name for the Policy.
ActiveWhether the Policy participates in evaluation. An inactive Policy's Products fall through to the next Policy.
WarehouseThe Warehouse the Policy operates in. A Policy stays in the Warehouse it was created in.
MerchantsLimits the Policy to specific Merchants. Leave empty to apply the Policy to all Merchants.
Product Profiles and Profile Match ModeLimits the Policy to Products in the selected Product Profiles; the match mode controls how multiple selections combine. Leave empty for all Product Profiles.
Handling ClassesLimits the Policy to Products with the selected Handling Classes. Leave empty for all Handling Classes.
Location ProfileThe Locations of this Profile are the stock group this Policy measures. Only Profiles in the chosen Warehouse that are Ready can be selected; an empty Profile is labeled "Empty".
Trigger DOICoverage in days below which a Product is flagged for replenishment.
Target DOICoverage in days to restore. It may equal Trigger DOI, but then a Product can be flagged again after the next pick.
Demand PeriodThe velocity window used to derive daily demand. The choices are the velocity periods configured for Product Velocity.
Demand BasisWhich picks count as demand — Pickable (only picks made from pickable Locations) or Overall (every pick). See Choosing a Demand Basis.
Sort OrderPolicies are evaluated from the lowest sort order upward, and the first qualified match wins.

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 Results (whether the figures come from the latest published calculation, and the current Flagged SKUs count).

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. You can adjust precedence directly from the grid — the Sort Order column is editable inline.

For each SKU the winning Policy governs, ShipStream divides the quantity on hand in the Location Profile's Locations 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.

Set Target DOI comfortably above Trigger DOI so each replenishment buys several days of coverage. When the two are equal, a Product can be flagged again after the next pick.

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.

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.

Both bases count picks from across the whole Warehouse, and both are measured against the on-hand in one Location Profile. Overall counts at least as many picks as Pickable, so a SKU's daily demand can be higher, its coverage can be lower, and more SKUs can be flagged. The difference is the demand served from reserve. Review your Trigger DOI after switching an existing Policy because it may trigger earlier than before.

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), Location Profile, Trigger DOI, Target DOI, Demand Period, Demand Basis, Qualification, Sort Order, result counts, 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.

ColumnMeaning
Flagged SKUsSKUs whose coverage fell below the Trigger DOI, each flagged with the quantity needed to restore the Target DOI.
Skipped SKUsSKUs that matched this Policy's subject but fell through to lower Policies — for example because the Policy was inactive or disqualified when the result was calculated.
Slotting ForbiddenSKUs excluded because every target Location in the Profile is hard-forbidden by Slotting Rules.

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.

StateMeaning and Remedy
QualifiedThe Policy is evaluated for the Products it selects.
InactiveThe Policy is turned off, so its Products fall through to the next Policy. Set Active to Yes to include it again.
Disqualified (Profile building)The Location Profile is still building its first revision, so it has no Locations to measure yet. Wait for the build to complete.
Disqualified (Profile build failed)The Location Profile could not be built. Open the Profile to see the failure and rebuild it.
Disqualified (Profile never built)The Location Profile has never published a revision, so it has no Locations to measure. Open the Profile and save it so a revision is built.
Disqualified (empty Profile)The Location Profile is ready but currently matches no Locations, so there is nothing to measure. Adjust the Profile's Location Match criteria.
Disqualified (demand period unavailable)The velocity period this Policy uses is no longer configured. Edit the Policy and choose a configured Demand Period.

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.

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.

Access is controlled by the System -> Operations -> Replenishment Policies role permission, which is not granted automatically. Grant it — along with System -> Operations -> Location Profiles — to any role that should manage replenishment. See User Roles.