A Catalogue Is Not a Text Field
A free-text field with validation is not a smaller version of a coded one. Where a jurisdiction wants a value from a published list, the field either holds that value or your document is not the document.
Software people are relaxed about text fields. A description is a description; if somebody needs it structured later, you add validation, a dropdown, a lookup. The field grows into the requirement. That instinct is right most of the time and it is why nobody plans for the case where it is wrong.
It is wrong when a jurisdiction requires a value from a published catalogue. Then the field is not a place to write what the thing is — it is a place to put an identifier that a third party defined, maintains, and validates against. A description that reads correctly to a human and is not on the list is not a near miss. It is a rejection.
Mexico is the market where our own product runs into this most plainly, and the specific gap is worth publishing because it is small, concrete and ours.
The worked example is a defect of ours
Our items and our document lines do not carry a unit of measure. Not a wrong one, not an unvalidated one — there is no field. For most of this product's life that has been an unremarkable simplification: quantities are numbers, everybody in the business knows the item is sold in cases, and no document has ever asked.
In a market whose document requires a coded unit from a catalogue, that simplification stops being a simplification. There is nowhere to put the code, so there is nothing to send, so the document cannot be produced. The gap is not that the value would be wrong. It is that the value has no home.
There are no catalogue values anywhere in this post
No classification keys, no unit codes, no worked identifiers. We do not maintain any of that reference data, and a plausible-looking key in a blog post is precisely the thing somebody copies. What the catalogues contain, and which value applies to your product, is a question for whoever runs your invoicing — and in this market that is a certified provider rather than us.
Four ways a coded field differs from a text one
| A text field | A coded field | |
|---|---|---|
| Who defines the valid values | You do | Somebody outside your organisation does |
| What happens to an unknown value | It is stored | The document is rejected |
| When the list changes | Nothing happens | Values that were valid stop being valid |
| Migrating from one to the other | Widen the column | Map every existing row, and decide what to do with the ones that will not map |
The expensive part of adding a coded field is never the field. It is the several thousand existing rows that have to be assigned a value by somebody who knows the products.
That last row is the whole cost, and it is not ours
Adding a field to a schema is a small piece of work. Populating it is a project — and it is a project that only your people can do, because deciding which catalogue value describes a particular product is a judgement about the product.
So the honest sequencing on any build like this is: the field is quick, the mapping is slow, and the mapping cannot be bought. Any vendor who quotes you a coded-field requirement as pure development time has either not done it before or is quoting for half of it.
What this means for us in this market, stated plainly
Coded items with your own classification
Items carry codes and categories you define, which is what makes stock, procurement and reporting coherent. Yours, not a catalogue's.
Batch and expiry traceability
Which is a genuinely strong fit for distribution here and has nothing to do with any of the above — worth saying, because a post about a gap can leave a reader thinking the product is a gap.
A unit of measure on the item and the line
Not built. No field, so no value and no output. Ordinary work — a field, a default, a picker, a migration for existing rows — and commissionable now with a written specification, a timeline and a price. It is the first thing we would expect to be asked for here.
A catalogue key of any kind
Not built and not held. We maintain no jurisdiction's reference data and we are not going to imply we could keep it current.
Issuing the document itself
Not ours in any version. In this market the instrument is cleared by a certified provider before your customer sees it, and what we print is a representation rather than the thing. The market page is explicit about this and so is the honesty ledger on it.
The general test, for any market you are entering
One question, asked before you evaluate anything: which fields on my documents have to hold a value somebody else defines?
- List them. Units, classifications, counterparty attributes, document purposes — whatever applies.
- For each, ask the vendor whether there is a field, not whether it is supported.
- Ask what happens to your existing records when the field appears. Somebody has to populate it.
- Ask who maintains the list of valid values, and how you find out when it changes.
- If any answer is "you can put it in the description", the field does not exist and the document cannot be produced.
The last one is the tell. A description is where structured requirements go to be quietly not met — and it is convincing right up to the moment a document is rejected by something that does not read descriptions.
What is built here, what is not, and what we would decline is on the Mexico market page — including the parts of its own document model we cannot produce. The other two records this market puts pressure on are the cancellation your customer can refuse and fields that are not on your customer record. The general form of asking what an obligation is computed over is what does this obligation count in.
