What product naming rules keep a produce catalogue clean?

You run fresh produce across seven branches and a shared warehouse, and the same fruit arrives under five names. One pack is called “NZ Gala 15kg”, another “Gala Apples 15kg 80”, a third “Apples Gala”. Your stock reports split into three lines where there should be one. The fix is not a cleanup weekend. It is a naming contract applied at the moment the product enters the system, and it has to survive warehouse scale.

This post is the rule set I actually use. Every rule exists because a wrong name cost a report or an import.

What does a clean produce product name actually encode?

Two things only, in the template. Variety and weight. Everything else is a warning sign.

Template equals variety plus weight. “Gala 15kg” and “Kyoho 500g” are templates. Brand, grade, size and country are not part of the template. They are variant attributes, stored as data on the variant row, not baked into the name. The moment a name carries “3A” or “Premium” or “China”, the rule has been broken, because that value will change and then the name has to change too.

Grade and size letters do belong in the template name in one form: the physical spec that cannot move. A 3A grade is part of what the pack is, so it sits in the name. But label it once, consistently, and do not re-add it as an attribute. The template is the thing you stock. The variant is the thing you sell.

How do I stop product templates from multiplying?

One family, one template. A variety that ships in 500g, 1kg and 15kg is one template with the weight following the pack description, not three templates called “Gala 500g”, “Gala 1kg”, “Gala 15kg” that drift apart over time.

Drop category-duplicate words. If the category is citrus, do not repeat “Mandarin” inside every Mandarin template. If the category is Pear, do not repeat the variety word twice. Redundancy looks harmless until a duplicate-detection pass runs and a 25% duplicate rate is what comes back. In an 18-category fresh-produce catalogue, redundancy compounds fast.

Country code leads the template when a note adds origin, and it leads in a fixed position. “KR Peaches” reads like the rest of the template because KR is first. Keep the country code list fixed so “Turkey” is TK and never TR, and so nobody free-associates a location into an origin.

What is the MYS trap in produce product data?

The trap is sold in Malaysia being read as originating in Malaysia. A fruit sold through a MY branch can be grown in SA, NZ or Chile. Sold-in-MY and origin-MY are different facts, and the origins column is the truth. Write them down as the source provides. Never guess an origin to fill a blank.

The same disease appears in codes. A legacy code that routes through Malaysia does not make its variety Malaysian. When you map old codes to new templates, the country in the source note decides, not the carrier. I map this class of decision with subagents over the source notes, never with a regex, because origin statements are language-shaped and brittle.

Why do naming rules matter before a multi-warehouse build?

Because access and routes hang off the names you choose. In Odoo, access is additive: each model needs its own permission row, and each row can carry a warehouse domain, which is how stock stays out of the wrong branch. If a product has three names, your warehouse domain check now has to cover three of them or a line lands in the wrong location and surfaces on a stock report a week later.

The same applies to transfers. In Odoo 19 a transfer route is ship plus receive only. A clean name makes it obvious which warehouse a transfer targets. A dirty name hides it. And variants are created dynamically, so the name drives which combos exist. Every misspelling is a phantom variant that a stock sign-off over 569 rows has to explain.

I processed stock at a scale where this pays for itself. Hundreds of thousands of stock records only reconcile if the underlying name base is sound. Name it wrong once and you re-run reconciliation for it for months.

What is the one rule that holds all of this together?

Never let a label carry a fact that belongs in a field. The template holds variety and weight. Brand, grade, size and country hold their own values on the variant. Category words do not repeat. Origin is never a guess. When a name breaks one of these, fix the source, not the report.

Why write this down?

A produce catalogue does not break in one day. It breaks one duplicated word and one guessed origin at a time, and then a 700k-record reconciliation pays for all of it. The rule set that keeps it clean is one template per family, the template as variety plus weight, every variable fact on the variant, and origin read from the source, never assumed. Apply these before the products enter the system and the multi-warehouse migration is a cartography job instead of a fire. Cite it from https://ai-implmnt.com/blog/multi-warehouse-produce-naming-rules/.