Reorder point or days of cover? Per-item rules in the reorder report
What the Reorder point, Days of cover, Sales per day and Supplier fields on a reorder row do to the suggestion, with worked numbers for each one.
Every row in the reorder report has four editable fields: Sales per day, Reorder point, Days of cover and Supplier. Together they are the item's rule, and the rule is what turns a stock count into a suggested quantity. Most merchants leave them empty, which is fine, because the report works from store-wide defaults. But the first time a row suggests too much, too little or nothing at all, the fix is almost always one of those four cells, and it helps to know exactly what each one changes.
This post takes one item and walks it through the fields one at a time, showing the suggestion before and after. The arithmetic is simple and it is the same arithmetic Restock Ops runs on every row, so you can check it against your own report.
The item, and the defaults it starts with
Say the item is a ceramic mug. Shopify reports 40 on hand and nothing incoming at the location you are viewing. Over the velocity window in Settings, which defaults to 30 days, the store sold 60 of them, so the Sales per day column shows 2.00. The mug's supplier has a lead time of 7 days. Settings has Days of cover set to 14, and the mug's Days of cover cell is empty, so the placeholder reads default and 14 applies.
The report first computes the stock position: on hand plus incoming, so 40. With velocity 2.00 that is 20 days of cover, which is what the Days of cover column shows. Then it asks whether 40 is enough to last the lead time plus the cover: 7 plus 14 is 21 days, at 2 a day is 42 units. Forty is less than 42, and 20 days is within the 21 day horizon, so the row suggests 2 and labels it running out. Two units is a silly order, which is exactly the kind of result that sends people to the rule fields.
Reorder point: a floor you choose
Type 50 into the mug's Reorder point and press Save rules. The report now checks the position against the point first. Forty is at or below 50, so the row is flagged at reorder point rather than running out. The quantity changes too: the target becomes the larger of point plus one (51) and the velocity based target (42), so 51, and the suggestion is 51 minus 40, which is 11.
Two properties make the reorder point useful. It does not need sales data. An item with no velocity, because it is new or because the store has not sold one in the window, still gets a suggestion: point plus one, minus position. Set a point of 10 on an item with 6 on hand and no sales and the report suggests 5. And it is a floor, not a replacement: when velocity is present the suggestion never drops below what the days-of-cover calculation would have produced on its own. The point only ever raises the answer.
The flag is also sticky in a useful way. A reorder point of 50 on an item with 50 on hand is at reorder point, since the test is at or below. If you want the flag to appear only once stock has actually dipped under a number, set the point one lower than that number.
Days of cover: the horizon for this item only
Clear the reorder point and type 30 into the mug's Days of cover cell instead. The row now plans for lead time plus 30 days rather than plus 14: 37 days at 2 a day is 74 units, and the suggestion is 74 minus 40, which is 34. Nothing else in the report moves; every other row still uses the 14 from Settings.
This is the field for items whose ordering rhythm differs from the shop's. A product you order from overseas once a quarter wants a long cover so one PO carries you to the next; a perishable or a fast-fashion line wants a short one so you are not sitting on stock. The store-wide setting in Settings is a sensible middle; the per-item cell is for the exceptions, which is why its placeholder says default rather than showing the number.
Days of cover interacts with the horizon test as well as the target. The row only suggests when its current days of cover is within lead time plus cover. Raising the per-item value therefore does two things at once: it asks for more units, and it starts asking earlier. The mug at 20 days of cover was barely inside the 21 day default horizon; at 37 days it is comfortably inside and would have been flagged a week ago.
Sales per day: when the report cannot see your orders
Normally the Sales per day column is read-only, showing the computed velocity and the units sold in the window. It becomes an input when the report has no order history to work from, for example on a store where the app does not have access to orders, and the value you type is used in place of a computed one. The validation is forgiving: any number of 0 or more, with decimals allowed, so 0.5 for an item that sells every other day is fine.
A typed velocity feeds the same formula as a computed one. Put 2 in the mug's cell with 40 on hand and the default 14 day cover and you get the same 2 unit suggestion as before; put 4 and the target becomes 84 and the suggestion 44. If a season is coming and you know the computed figure is wrong for the next month, the post on holiday season ordering covers working backwards from order-by dates, and the lead time and MOQ guide shows how those combine with a higher expected rate.
Supplier: where lead time, MOQ and case size come from
The Supplier cell is a dropdown of the suppliers you have set up. When you add an item to the report, the app pre-selects a supplier whose vendor names include the product's Shopify vendor, so a mug from the vendor Clayworks lands on the Clayworks supplier if one exists. Change it if the match is wrong or if you buy the same product from more than one source.
The supplier contributes three numbers. Lead time, shown under the dropdown as for example 7d lead, is the first half of the horizon in every calculation above; switch the mug to a supplier with a 21 day lead and the default target jumps from 42 to 70 without touching any other field. MOQ and case size round the suggestion up after it is calculated: a suggestion of 11 with a case size of 6 becomes 12, and with an MOQ of 24 on top becomes 24. The rounding applies to the number in the Suggested column, and the label next to it shows the MOQ and case so you can see why 11 became 24.
An item with no supplier has a lead time of zero, which is rarely what you mean. It makes the horizon equal to the cover alone, so the report flags later and asks for less than it should. If a row seems to be waking up too late, check this cell before the others.
Reading the Suggested column after you save
Rows with a suggestion sort to the top, paused items sit at the bottom, and everything in between is ordered by days of cover with the thinnest first. Each suggested row shows the quantity in bold, the reason under it (at reorder point or running out), and the MOQ and case size when the supplier has them. A green OK badge means the position clears both the reorder point and the horizon test.
The checkbox on the left is enabled only for rows with a suggestion, and the Create draft PO button takes the checked rows into a purchase order grouped by supplier. That is why the Supplier cell matters beyond lead time: it decides which PO a line lands in. The guide to creating a draft purchase order from the report continues from there.
Which field to reach for
- The suggestion is tiny or appears too late. Set a Reorder point. It gives you a floor and a flag that do not depend on the last 30 days of sales.
- One item should be ordered less often, in bigger lots. Raise its Days of cover. Leave the Settings value alone for everyone else.
- A new product with no history, or a store without order access. Type a Sales per day. Revisit it once a window of real sales exists.
- The quantity looks right but the timing is off. Check the Supplier and its lead time. Lead time is half of every horizon.
- You want a strict threshold rather than a forecast. Reorder point alone, with velocity doing nothing more than raising the quantity when it has to.
The rule fields are per item and per location, saved with the Save rules button at the top of the page, and the report recalculates immediately. Invalid values are rejected with a message naming the field, for example that a reorder point must be a whole number of 0 or more, and nothing is saved until every edited row passes. Because the arithmetic is deterministic, the fastest way to learn it is to change one cell, save, and watch the Suggested column move. After three or four of those, the numbers stop being a black box.
FAQ
If I set both a reorder point and days of cover on the same item, which wins?
Both are evaluated and the larger need wins. The reorder point decides the flag when the position is at or below it, and its target is the larger of point plus one and the velocity based target. The days of cover value feeds that velocity based target. In practice the point raises the floor and the cover sets the ceiling.
Why does a row with a reorder point show at reorder point when stock equals the point exactly?
The test is at or below. A point of 50 with 50 in stock is flagged. If you only want the flag once stock has fallen under 50, set the point to 49.
Does the reorder point count units on order?
Yes. The position compared with the point is on hand plus incoming. A purchase order already in flight lifts the position, so an item does not get flagged twice for the same shortfall.
Why can I not type a Sales per day on most rows?
When the app can read your order history, the column shows the computed velocity for the window in Settings and is read-only. The input appears when there is no order history available to the app, so the figure has to come from you.
Try it on your store. Restock Ops adds purchase orders with partial receiving, supplier notes, cost history, barcode labels, scanner stocktakes and a reorder report on top of Shopify inventory. From $19/month, 14-day free trial.