Orders over a store that isn't getting anything are now refused by the overstock check

Flow

What one override token is tied to

1. 1The plan⌄

   A hash of the exact frozen plan it was issued for.

2. 2The problems⌄

   A hash of the exact list of flagged piles.

3. 3The person⌄

   Only the owner of the plan can get one, and their name goes on it.

4. 4The reason⌄

   A written reason, not just a click.

5. 5The clock⌄

   It runs out after minutes.

One test for my new overstock check gives a store nothing at all, and the order still gets refused. That store already has more on the shelf than the ceiling allows, and that's enough to stop the whole draft.

Before anything is written

The ordering system turns a reviewed, frozen plan into a draft order. The check now runs first, before any workflow record exists, so a refusal leaves nothing to clean up. For each store and product it works out days of supply: stock on hand plus this order, divided by what the store sells in a day. Over a ceiling of a few months, the draft is refused. Right at the ceiling is fine.

Add up the slices first

A plan can list the same product for the same store more than once, split by supplier case size. Checked one line at a time, a big order passes in pieces. So the check pools lines before doing the math.

Lines are grouped by store and product before the check runs.

Items ordered as a family go into one pile by their cleaned-up label, so two spellings don't make two piles. If two lines in one pile disagree about stock or sales, the check throws an error instead of guessing.

Two cases that look harmless

A product with no recent sales can't have a days figure, because you'd divide by zero. If something is on order anyway, the check flags it. Letting that through as "fine" would make the worst orders look the safest.

A store with no order is still checked on its shelf alone. If it's already over the line, the order is refused. I'm split on that one. It makes someone look at a store that's buried, but the order can't fix it.

Getting past it on purpose

There's no "force" switch. A separate command:

1. reads the frozen plan and checks it against a hash you give it
2. shows every flagged pile and stops
3. signs a short token only if you run it again to actually sign, and only for the person who owns the plan

The token lasts minutes and records who asked and why. It's tied to that exact plan and that exact list of problems. Change one store's stock by one unit and it stops working. Tampered or expired tokens fail. A token on a plan with nothing flagged is rejected too.

Writing the decision down

The decision becomes part of the workflow's request fingerprint, so a retry with a different decision isn't mistaken for the same request. The order notes say it passed cleanly, or name the override by a hash of the token, with who and why. The token itself is never saved.

The two paths into the check don't refuse in the same shape yet, and if its own signing key is missing it borrows another one from the app. A brand-new product has no sales at all, so it'll need an override every single time, and I don't have an answer for that.