Produce distributors import from everywhere and sell locally. The data trap is assuming the two are the same. We hit it during a 700k record migration into Odoo 19 for a Malaysian fresh produce business with 7 branches plus Westport.

The trap has a name in our notes: MYS. Stock sold in Malaysia is not stock of Malaysian origin. A box of Egyptian oranges sold at the Selayang branch is still EG, not MY. Confusing these two corrupts every report built on top.

Where does the confusion come from?

Legacy spreadsheets record what sold, where it sold, and what it is. Often in one text field. “Orange Egypt” in a Selayang sales row carries three facts: product, origin, branch. If you import that field as-is, the origin sticks to the location.

The fix is splitting the field before it touches the database. Product name keeps the origin code when the note adds it. Branch is the warehouse on the order. Origin is a product attribute, never a location property.

How do you verify origin data?

Never guess. We used the product notes CSV as the single source of truth for origin prefixes. Each new template name was checked against the Description and Internal Reference columns of that file, category by category. Apples first, then citrus, then the rest of the 18 categories.

Two rules came out of that pass. First, a category name is not an origin: a mango sold in MY could be from TH, VN, or PH. Second, sold-in location proves nothing about origin. Only the source document does.

What does clean data look like?

One product template per variety and weight. Brand, grade, size, and country of origin as attributes. Country code leading the template name when notes specify it. Duplicate legacy codes removed up front, roughly 25% of them were duplicates. Cleaning before import costs a day. Cleaning after costs a re-import.

How does this apply to CRM data?

The same discipline applies to customers. A customer’s shipping branch is not their company. A contact name is not the company record. Import CRM rows with the same separation: company, contact, delivery address, salesperson as distinct fields. If your legacy export merges them, split it before import, not after.

Why write this down

Country of origin is a product attribute and country of sale is an order property; never merge them when migrating produce distribution data, and verify every origin code against the source CSV rather than inferring it from location. Full series at https://ai-implmnt.com/blog/.