Importer couldn't tell a blank setup sheet from a used order sheet

Flow

Where the shape check sits

1. 1Read the chosen tab⌄

   Convert the tab to text; no records touched yet.

2. 2Run the analyzer⌄

   Count store headers, product rows, TRUE/FALSE cells, stray numbers in the lineup, filled order amounts.

3. 3Print the verdict in the dry run⌄

   Reasons list plus a few sample cells; informational only.

4. 4Write path checks the verdict⌄

   Empty reasons list proceeds; otherwise it refuses before any transaction opens.

5. 5Operator fixes the sheet⌄

   Edit the cell or choose another tab, then preview again.

The supplier importer couldn't tell a blank setup sheet from one somebody had already ordered from. To it they were the same file, and the output would have looked fine and been wrong.

The setup tab lists products in rows. A block of store columns says TRUE or FALSE for which stores carry each one. Then the same store names repeat as empty columns for order amounts. Order tabs are copies of that tab with numbers typed into those empty columns. Same headers, same products. The only difference is where the numbers are.

The two tabs differ only by the numbers typed into the second block.

How an order became a lineup

The part that read the store columns was far too loose. It looked at every column under a store's name, and yes, x, 1 or any positive number meant "this store carries it." So on an order tab, every store with an amount got added to the lineup. A test even expected that. The bug had a test guarding it.

Words were the wrong signal

My first guard looked for words like vape or pre-roll in product names and blocked those rows, with a flag to skip the block after review. It was gone in under half an hour. A product word tells you what a row sells, not which kind of tab it came from. An order tab of gummies gets through. A good setup tab with one pre-roll gets stopped, and soon everyone uses the flag.

Checking where each kind of value sits

The replacement looks at the tab before anything is written. It counts the store headers, the product rows, the TRUE/FALSE cells, and any numbers sitting where ticks or blanks should be. Each problem becomes a plain reason. No reasons means it's a setup tab. A practice run prints the verdict, and a real run refuses with the reasons and a few example cells. I deleted the word guard and its flag at the same time.

Then I picked the wrong column

I also made the reader use only the first column under each store name. But a tab can have a copy of the store headers in front of the real grid. Then the first column is empty, no store looks like it carries anything, and a good tab gets refused. A few hours later I changed it to use the first column per store that holds a clear yes or no, and stopped counting 1 or plain numbers as yes. A test now covers that layout.

Two smaller filters went in too. Rows with no store ticked get skipped, and so do rows with no positive cost.

A word list came back

That evening a keyword check came back for a different job. Its notes say it keeps rotating products out of the fixed path when an old header layout hides them. It has no override, and it blocks practice runs too. If I did the day over, I'd have started from the shape of the tab and never shipped the first word list at all.