A plan that said buy nothing, so the deploy now checks with the store records first

Flow

How the zero check fits together

1. 1Plan rows⌄

   Stock, sales and linked products for each group and store.

2. 2Raw summary⌄

   Store records added up by category, without the matcher.

3. 3Grade each zero⌄

   Same-category evidence is critical. Everything else is a warning.

4. 4Deploy step⌄

   Runs for every active supplier and stops only on critical.

5. 5Second check⌄

   Confirms the scan line is still in the deploy script.

6. 6Triage⌄

   One next action per supplier, worst first.

A row of zeros in the ordering system means "buy nothing." No stock, no sales. But it can also mean the plan never got the data. The row looks the same both ways.

My plan puts products into groups that can stand in for each other, like the same brand in the same size. Store records get matched into those groups, and the order math runs on the group totals. If the matching breaks, the totals drop to zero, and the plan says buy nothing. The plan can't spot this, because all its numbers came through the broken step.

A witness that skips the matcher

So the new check looks at two things. One is the plan: stock, sales and linked products for each group in each store. The other is a plain summary of the raw store records, added up by category and store. It never uses the groups. If the matcher broke, this summary still tells the truth.

Then the check sorts each zero into a kind:

• The whole supplier is zero. Warning: check the sync and the setup.
• A category is all zero in the plan, but the store records show stock or sales in that same category. Critical.
• A category is all zero, but the records only show activity in other categories. Warning: check how categories and stores are matched.
• A category is all zero, and the records show nothing at all. Warning: resync first.
• A category has stock but no sales. Warning: maybe dead stock, maybe missing sales data.

The core test is tiny.

If the plan says zero for everything but the raw records show stock or sales, the deploy blocks.

Moving things between two piles

Most of the day went into deciding what can stop a deploy and what can only complain.

The same-category case started as a warning. I made it critical, because I can't see how "the plan says empty" and "the store says not empty" can both be true. I also added a test so a group with no linked products never raises anything. Those groups are supposed to be empty.

An older check went the other way. It flags products that matched two groups equally well. When one of those groups was empty, that used to be critical, and I moved it down to a warning. A product that fits two groups means my rules are fuzzy, not that the plan is lying.

The check also skips small categories, so one quiet item can't set it off.

Where the scan sits in the deploy

A check that only prints gets ignored. So the server deploy now runs the scan for every active supplier, after the tests and before the build. A critical finding stops the deploy. A warning just gets printed.

A second check makes sure the scan line stays in the deploy script. That cost me the same day: changing the scan's lookback meant editing the deploy script, that second check and its test together. The first version of the scan also read suppliers from the wrong table and needed a small follow-up.

Last, a triage step gives each supplier one next action. Blockers come first, then missing data, then category setup, then fuzzy matches, then records nothing matched.