Product
Case Rounding and Max-Stock Caps: How a Suggested Quantity Becomes Orderable
The math gives you a quantity. Your supplier ships cases and your shelf has a ceiling — this is the step in between.
The number the math gives you is rarely the number you can send
Replenishment math produces a clean number. Take a product's sales velocity, multiply it by the period you want to cover, subtract what's on hand, subtract what's already inbound on open purchase orders. What comes out is a genuine quantity — it just isn't an order.
It isn't an order because the math lives in a continuous world and purchasing lives in a discrete one. A supplier doesn't ship an arbitrary piece count because your arithmetic asked for it; it ships cases, and cases come in fixed counts. Many suppliers won't ship at all below a minimum order quantity. And storage doesn't stretch because your forecast got optimistic — a shelf, a pallet position, a cold room, and a cash balance all have ceilings.
So between "what I need" and "what I can send" sits a transform step that most spreadsheets skip and most buyers do in their heads, once per line, every week. This post is about that step alone: not how the need is computed, but what has to happen to it afterward before anyone can act on it.
Why your supplier sells in cases
The case pack is the wholesale unit of measure, and it exists for reasons that have nothing to do with your demand curve. Product comes off the production line already packed into cases, because a case is the cheapest thing to handle at every step after that: it palletizes cleanly, it fills a truck predictably, it stacks in a rack, it scans as one item. Breaking a case open to pull loose pieces is retail labor, and wholesale pricing is quoted on the assumption that nobody upstream has to do it.
Minimum order quantities apply the same logic one level up, at the order rather than the unit. Picking, packing, documentation, invoicing, and shipping carry a fixed cost per order regardless of how small that order is. Below some size, filling it costs the supplier more than it earns. The MOQ is where they draw that line, and it's why a supplier who is happy to sell you 500 units will decline to sell you 20.
The discipline pays off on your side of the dock too. Receiving against case quantities means counting cases, not pieces — fewer counts, fewer miscounts, and a receiving discrepancy that resolves to one case rather than a mystery unit variance. Ordering in pack multiples isn't a supplier imposition you tolerate; it's the shape of the whole channel.
Rounding has a direction, and the direction is a decision
Once the pack size is fixed, the only remaining question is which way you round — and that question has a real answer that changes by product. The common practice is to round up on fast movers, where the cost of being short is a lost sale and the extra units will clear anyway, and to round down on slow movers, where an extra case is capital and shelf space parked for months. A single rule applied to the whole catalog will be wrong at one end of it.
Larger operations formalize this instead of re-deciding it per line: threshold-based rounding profiles that round up when the remainder crosses some fraction of a case and down when it doesn't, configured per item class. The point of formalizing it isn't elegance, it's repeatability — the same SKU gets the same treatment whoever is buying this week.
Whichever direction you choose, the rounded number has to remain visible next to the raw need. A quantity that was silently adjusted is a quantity nobody audits: when the receipt lands and the shelf overflows, no one can tell whether the forecast was wrong or the rounding was.
| Raw suggested need | Orderable quantity | |
|---|---|---|
| Unit | Individual pieces | Cases, or a whole-order minimum |
| Respects supplier pack/MOQ | No — an arithmetic result | Yes — landed on a pack boundary |
| Respects your stock ceiling | No — unbounded above | Yes — clamped to remaining headroom |
| If you send it to the supplier | Gets rounded or rejected on their side | Accepted as written |
| Where the trade-off shows up | Hidden — nothing was decided yet | Visible — you chose over- or under-cover |
The ceiling at the other end: max stock
A maximum stock level is set by whatever runs out first — physical capacity, working capital, or shelf life. In min-max replenishment it isn't merely a warning line either: the max is the order-up-to level, the target you fill to when an item trips its minimum. That makes it an active input to the quantity, not a passive alarm.
Which sets up the collision. Rounding pushes the number up; the cap pushes it down; and an MOQ can be larger than the headroom the cap leaves. When all three meet, no quantity satisfies every constraint, and the transform stops being arithmetic and becomes a judgement call. A first cut looks like this:
orderable qty = min( ceil(raw need ÷ case size) × case size, max stock − on hand − incoming )
The catch is that the second term isn't guaranteed to land on a case boundary, so the minimum of the two often isn't orderable either. That's the fight in one line.
Suppose the raw need comes out at 50 units. The supplier ships cases of 12, you hold 15 on hand, and your maximum stock level is 60 — the cap is set by shelf space, not by demand, so it can sit below what the cover period asks for. That leaves headroom for 45. Rounding up to cover the need means five cases, 60 units, which lands you at 75 and blows through the ceiling. Four cases is 48, still over. Three cases is 36, which fits under the cap at 51 but leaves you 14 units short of the need. There is no quantity that satisfies both rules, and someone has to pick which one bends. (Illustrative numbers.)
This is exactly why the Smart Buying Table shows a quantity that is already through the transform. Every suggestion is computed from your sales velocity, lead times, and incoming stock — then rounded to your case sizes and capped at your maximum stock levels. Numbers you could order as-is, rather than a raw need you still have to convert line by line. When you do override one, the change shows as a was→now chip with per-row undo, so the adjustment stays auditable next to the original, and nothing is committed until you create the order. Downstream, a selection splits into one purchase order per supplier. An in-table data expert that answers "why 84?" on any row is listed as coming soon.
See how the underlying need is projected in Forecasting, where the post-transform quantity lives in the Smart Buying Table, and what happens after you commit it in Purchase Orders & Suppliers.