Compound Barcodes in a Stock App: Reading the Label Is Not the Same as Filling the Right Fields
A scanner returning a string is only the first part of a stock-app feature. If a supplier label contains a product identifier, batch and quantity together, the app must interpret those parts and put them in the intended fields. Commission that interpretation explicitly rather than accepting “barcode scanning works” as the whole requirement.
Bring labels, not just a feature name
Prepare representative labels your business is entitled to use, together with a written explanation of what each is meant to contain. Include different suppliers and label versions where those differences matter. For a demonstration, use synthetic values rather than exposing customer or supplier records unnecessarily.
Distinguish a code that identifies only a product from a compound code carrying several fields. Agree which formats the project accepts. A camera reading a QR code does not establish that its contents follow the same rules as a supplier's GS1 label.
The Odoo 19 GS1 guide provides a concrete implementation example: when one barcode encodes multiple fields, Odoo requires the corresponding rules to be present in its nomenclature. This is a product-specific dependency, not a claim that any scanner understands every supplier label.
Write the destination beside each part
Create a mapping sheet: input field, meaning, destination in the app and expected example result. Product identity should resolve the intended product record. A lot value should reach the agreed lot field. Quantity needs its agreed unit and interpretation, not merely a number placed in whichever input currently has focus.
These are requirements to agree for your app. Whether you need batch tracking and how you convert purchasing units are separate decisions; the parser should implement those decisions, not invent them.
The Odoo guide warns that adding recognition for an unknown encoded field does not link its information to an existing Odoo field without developer customisation. Ask the supplier to demonstrate saved destinations, not just a screen that displays decoded text. “Recognised” and “used by the workflow” are different acceptance results.
Decide how incomplete interpretation behaves
What if the product is recognised but another part is not? For a receipt that depends on the missing value, a useful default is to show the problem and require resolution before confirmation. If partial capture is allowed, make the omitted data explicit and agree what staff must do next.
Do not silently accept an unknown field by dropping it, and do not silently create new product or lot records because the text resembles an identifier. Those behaviours need an explicit business rule. Keep the distinction between preparing a receipt and confirming a stock movement visible.
Test the interpretation in layers
Odoo recommends diagnosing a combined product, lot and quantity barcode by testing the product identifier first, then adding the lot, then testing the complete barcode. Use that incremental approach to isolate a failure instead of repeatedly pointing the scanner at the same label.
For the commissioned app, agree a small acceptance set:
- A supported complete label fills the intended fields and resolves the intended product.
- A recognised product with an unsupported additional field produces the agreed outcome.
- A decoded field without a destination is not presented as successfully saved business data.
- Cancelling the review leaves stock unchanged.
- Confirming produces the agreed receipt data, with quantity and unit visible.
- A changed supplier label is tested before being added to the supported set.
Use known examples and inspect the resulting records. A beep, green camera frame or raw text preview is not evidence that the stock record is correct.
Keep the scope honest
This source supports Odoo's interpretation and configuration examples, not universal GS1 compliance, scanner compatibility or sector-specific traceability obligations. The mapping sheet and confirmation safeguards are proposed project requirements. Include them in your acceptance criteria and business-app brief before choosing hardware or estimating the integration.