Restock report counted the same units twice, so my deploy now reads the reports first

Flow

Which checks stop a release

Errors stop the deploy before the build. Warnings print and let it continue.

1. 1Internal-transfer row in either report⌄

   Error. Suppliers should never see that location.

2. 2Velocity row with no sales⌄

   Error. A supplier summary shouldn't list items that didn't sell.

3. 3Visible restock row with no sales, no order and no review flag⌄

   Error. The grid is supposed to hide it by default.

4. 4Direct row a pool borrowed from, or a generic slot shown as a direct line⌄

   Error. Stops the same units from being counted twice.

5. 5Zero-sales row that still has an order⌄

   Warning. Probably a standing minimum, and that's a buying policy call.

Double-counting was possible in my restock report: the same units could be counted twice. They showed up once inside a grouped row and again as their own line lower down. Nothing errored. A buyer would just see demand that wasn't real.

How the double count got in

A grouped row stands for a pool of products that can swap for each other. Pools often have no sales of their own, so the planner borrows stock and sales from matching raw rows out of the stores' sales feed.

The planner never wrote down what it borrowed. The code that picks direct lines only skipped declared pool members. Borrowed rows weren't members, so they got their own lines too.

Now the planner keeps a list of borrowed rows for each store, and the reports and the cart treat those rows as already covered. Two things to copy if you build this. Key the list by store, because a product can be borrowed in one store and stand alone in another. And drop borrowed rows before any "always stock this" override gets a say, or the override brings the duplicate back.

The same question kept coming up

I fixed a few more cases like it that day. Generic slot rows could show as direct lines. The supplier velocity report would list products just for having stock. The restock grid would show rows that hadn't moved and didn't need an order. Each was a different bit of code deciding which rows exist. A shared row resolver puts those rules in one place, but it can't stop the next change from going around it.

The deploy reads the reports first

So the deploy now runs a read-only checker for every active supplier. It calls the same report code the app calls, and asks the grid's own show-or-hide rule what a buyer sees. Don't give the checker its own copy of the rules. It would only agree with itself.

It stops the deploy on an internal-transfer row, a velocity row with no sales, a visible restock row with no sales, no order and no review flag, a direct row a pool borrowed from, or a generic slot shown as a direct line. A zero-sales row that still has an order is only a warning, since that's a buying policy question, not a leak.

Put it after the tests and before the build and restart. An error or a crash stops the deploy, and the old version keeps running. Add a small check that fails if someone deletes the gate from the deploy script.

At-risk rows and empty suppliers

The velocity report keeps a zero-sales row if it's tagged at risk, but the checker rejects every zero-sales row. If one shows up, the deploy stops, and I'll have to pick which rule is wrong.

A supplier with no rows also passes, because there's nothing to flag. The row counts are in the log, but nobody reads a log that passed. So a supplier that had rows and comes back with none would pass without anyone noticing.