Reorder passed review at three times the size my own rule allowed

Flow

Checks in the order they should run

1. 1One snapshot⌄

   Capture stock and sales in the same run that plans the order.

2. 2Calendar rate⌄

   Divide raw units sold by every day in the window.

3. 3Exact gate⌄

   Check start and band with whole-number math.

4. 4Whole cases⌄

   Reject a plan that can't fit whole cases before anything is reserved.

5. 5Tie the proof⌄

   Attach the proof to the exact version of the order.

The review packet said the order would leave every store with about two months of stock. That was my rule, and the math on every row checked out. Counted from raw sales over the whole window, the worst items would actually last six to nine months. The order was about three times too big.

Two kinds of "per day"

How long stock lasts is stock divided by sales per day. The sales rate on this order only counted the days the item was on the shelf. My rule counts every calendar day. For an item that was sold out most of the window, the shelf-only rate is several times higher, so a huge order looks small.

The error is biggest on items that keep selling out, which are the ones you're reordering. It's zero on items that never ran out. So checking a few normal items tells you nothing.

Three holes in the review

Three things went wrong at once.

• The tool that built the review packet checked the math but took the daily rate as given. It never saw raw sales, where they came from, or which days were counted.
• A later attempt to replace the order mixed sales from one system with stock counts from another. A new minimum-cover rule rejects it, but it failed late and left junk behind: a stuck job, an expired receipt and a changed cart.
• The replay tool, which should explain why an order exists, could show an older version's story as if it were the current one.

What the order checks before it exists

Now the planner takes one snapshot of stock and sales in the same run that plans the order. It uses whole calendar days, ending at the start of the decision day, so a rerun gets the same window. It divides raw units sold by every day in that window. Other sales tools are only a cross-check.

Each item has to start low and land inside the band after rounding to whole supplier cases. The edges are compared with whole numbers, not decimals: stock times days against sales times the limit. That way an item sitting right on the line gets the same answer every run. A plan that can't work in whole cases is rejected before anything is reserved or changed.

The proof is tied to the exact version of the order. A version can only be replaced if it's still the current one and nothing has been sent. Replay says "not captured" when it has no exact match, instead of guessing.

Still waiting at review

The order is still waiting at review, and nothing went to the vendor. A read-only rerun of the older planner wanted about half as many units. If I did it again, I'd make the check demand raw facts from day one instead of trusting a rate somebody else worked out.