Back to Feed
article 3m read

Onboarding asked one store and called a whole product line missing

Supplier onboarding read a single store, and a best-effort second read turned a failed answer into an empty one that counted as proof. Now it reads every store, records what failed, and only says a product is missing after a verified census.

Article DepthPractice

Flow

How each row is judged

  1. 1One active match

    Good.

  2. 2Two or more

    Ambiguous; a person picks.

  3. 3Repeated generic rows

    Need that many different active products.

  4. 4Only a retired match

    Blocked, and it says retired.

  5. 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.

Keep reading

Pick up a connected idea or branch into a nearby one.

5 paths forward