Flow
Which answer the dry run gives
1Setup missing, duplicated, or label blank
Blocked. There is nothing to compare yet.
2At least one proposal matches
Scoped. The matches still need review; the rest count as excluded.
3No match, no brand values anywhere
Couldn't look. The whole pile is unknown, and the gap is missing evidence.
4No match, brand values present
Found none. The whole pile is unknown, and the label is the first suspect.
No way existed to show me just one supplier's proposed product matches in the ordering system, which had a big pile of them.
I'd already told it which brand goes with that supplier. But the proposals only carry safe fields like IDs and status, and none of those say brand. The brand sits in the stored product records behind each proposal, and I keep those values out of logs and terminal output.
The long way round to a brand
So I type the brand name. The dry run follows each proposal to its product records, reads the brand from a short, fixed list of field names, and compares after trimming spaces and ignoring case. If any one record matches, the proposal counts as in. That can let in a few extras, which is fine because a person reviews the list next. It reports counts, never names.
Two kinds of zero
A missing or duplicate setup record, or a blank label, stops the run cold. If something matches, I get a scoped count, the rest counted as excluded, and a note that the matches still need review.
If nothing matches, it tells me which kind of nothing. "Couldn't look" means no proposal had a brand to compare, so the problem is missing evidence. "Looked and found none" means the brand values were there and my label didn't match any, so I probably typed it wrong. Either way it doesn't call the pile excluded. It calls it unknown. The "found none" zero has no test yet.
Counting the database on the way in and out
Before reading, the tool counts rows in a long list of tables, including far-off ones like inventory and purchase orders. It counts again afterward, and if the numbers differ the command exits with an error.
That count is the only part that checks the database. The report's "nothing was saved" flags are hard-coded. The command's long list of "no this, no that" flags only has to be present. A test scans the tool's code for write calls, and another plants fake product names in the test data and makes sure none leak into the output.
Every test gives the tool the same numbers before and after, so the count check has only ever been handed matching tallies.
Counting rows has blind spots. It misses a value changed in place, and anything outside the listed tables. Another program writing at the same time can trip it, which is a false alarm and the better way to be wrong.