ai-coding-minesIndexGitHub

Every product from one store shows a loss: the price field was not in USD

Python and databases

Symptom

The price from a source catalog API was written straight in as cost. Every product from certain stores came out at a loss, and the margin check, repricing, and sourcing verdicts were all invalid at once.

Cause

The catalog's price is in the store's display currency. Not USD. A Swedish brand was in SEK (×133 won), a Taiwanese brand in TWD (×44.5), a Japanese brand in JPY (×9.3). Nothing in the response says which — 1400.00 could be 1,400 USD or 1,400 SEK, and the number alone can't tell you.

The misdiagnosis

The numbers were large, so the diagnosis was "it's in cents" — and 65 records from one store were divided by 100, then restored. That store was plain USD. A healthy store got broken.

Two hypotheses — "cents" and "different currency" — produce the same number. Looking at the number cannot distinguish them.

Fix — how to tell

  1. Compare the live product page's displayed price against the API price. That is the deciding evidence.
  2. Guess the currency from the brand's home country first — Swedish, suspect SEK.
  3. The domain TLD is a clue but not enough on its own (plenty of European brands sit on .com).

The correction covered 939 records in two currencies plus 14 in JPY.

Verification

After conversion, check that the cost/price ratio falls in a sane range per store. A store that is entirely at a loss, or entirely at 90% margin, has the wrong currency.

Before any irreversible bulk conversion, decide which hypothesis is true. A value being present does not mean its unit is right.

★★★ The same assumption has to be broken separately at every endpoint

Six days later we hit the identical trap on the cart-quote endpoint. The catalog price had been fixed, but the shipping-quote response was also in the store's display currency. A Taiwanese store returned 378; read as-is that is $378, and the real figure was $11.72.

★★★ A fix in one place does not carry to the others. "The store is in USD" has to be un-assumed at every point that reads an amount.grep every call site that receives a monetary value and add the currency check to each. "The fix is decided" and "the fix is in every call site" are different facts.

★★ And unit errors are caught by magnitude, not meaning. Which currency 378 is cannot be told from the value — but "$378 international shipping" is impossible and you do know that. Put a sanity ceiling on every path where a conversion happens, and treat anything above it as a misread unit.