Flow
How each row is judged
1One active match
Good.
2Two or more
Ambiguous; a person picks.
3Repeated generic rows
Need that many different active products.
4Only a retired match
Blocked, and it says retired.
5Nothing at all
Not found after checking every store.
Every store got judged by one store's answer: supplier onboarding asked that store what a vendor sold.
When I add a supplier to the ordering system, I match each row of their price list to a real product in the stores. The old code asked only the first store, and by default only for active products. The on-hand and sales checks also read that first store's catalog once, best-effort.
Any error in that catalog read was swallowed and left an empty list.
If that read failed, every product missed, so "never got an answer" and "nothing found" came out the same.
Why the first store's answer broke the match
My stores don't share a catalog. Each one has its own records and its own product IDs. A product can be on sale in one store, retired in another and missing from a third.
I built a test from one real supplier's list. Every product on it lives in a store that isn't the first one. Ask the first store only and the whole line looks fake.
Reading every store and checking the result
Now the system reads every store it's allowed to read, one at a time. It merges the same product across stores but keeps each store's own ID. If a store fails, the answer still comes back, marked partial, with that store named.
It also checks the result against products I've actually stocked or sold. Anything missing from the result blocks the run. So does any record that's broken or unclear. That's strict, and sometimes it'll block a supplier for something unrelated.
Then judge the rows
Only after the search passes does the check look at rows:
- One active match: good.
- Two or more: ambiguous, a person picks.
- Repeated generic rows: need that many different active products.
- Only a retired match: blocked, and it says retired.
- Nothing at all: "not found after checking every store."
Each row problem points at its line in the supplier's file. Passing only unlocks a test order preview.
Giving the search more time
Warehouse-style locations are now left out by default, by a rule that hangs on a word in a location's name. Reading every store in a row is slow.
So the search got its own longer time limit with a cap, and the proxy in front now waits longer than the client so it can't cut the search off early.