Odoo core ties each product variant to exactly one barcode field on product.product. In the real world a single item arrives with several codes: the manufacturer's EAN-13, an old internal SKU from your previous system, a distributor's own label, a case or inner-pack code, and sometimes a weighed-item prefix. When a cashier scans any code other than the one you happened to store, the POS throws "product not found", the picker can't confirm a stock move, and staff fall back to manual search — slowing every checkout and every receipt. Native Odoo has no supported place to record more than one code per product, and the barcode.rule / barcode.nomenclature machinery only governs how a scanned string is parsed (price-embedded, weight-embedded, aliases), not which product a plain code belongs to. That is exactly where Odoo runs out of road.

We build a dedicated product.barcode model (a one-to-many off product.template and product.product) so each product owns an unlimited list of alternate barcodes, each with its own optional label, pack quantity, and active flag. A database-level unique SQL constraint plus an @api.constrains guard prevents the same code from resolving to two different products, and a stored compute keeps the core barcode field in sync with the designated primary so nothing in stock reporting, invoicing, or e-commerce breaks. The heart of the work is the lookup layer: we extend the POS load_product_from_scan / _get_product_by_barcode path so the point-of-sale UI resolves any registered alternate to the right product.product and adds the correct line, and we extend server-side name/barcode search (_name_search and the Sales/Inventory barcode handlers) so the same codes work when creating a quotation, receiving a purchase, or picking a delivery.

Technically the module ships as a proper Odoo addon: a versioned __manifest__.py declaring dependencies on point_of_sale, sale_management, and stock; OWL/JS overrides loaded through the POS assets bundle so scanning is instant at the till; XML and inherited form views adding a "Barcodes" tab on the product form; and ir.model.access.csv plus record rules so only the right roles can add or edit codes. Optional extras we scope on request include pack-quantity handling (scanning a case code adds the case quantity), an import wizard to load thousands of legacy codes from CSV, exposure of alternate barcodes over the XML-RPC / JSON-RPC API for external scanners or middleware, and a QWeb label report to print any of a product's codes. It runs on Odoo 17.0, 18.0, and 19.0, on both Community and Enterprise (the POS overrides differ slightly between Community and Enterprise POS, which we account for during scoping).

Because this is a build-to-order product, nothing ships the instant you pay. After you request a quotation we hold a short scoping call, confirm the exact Odoo version, edition, and which barcode sources you need, then build against your requirements and deliver on staging for UAT before go-live — typically one working week from confirmed scope. Pricing starts from $999 (indicative, single-company base scope); multi-company barcode isolation, high-volume legacy-code data migration, or extra integrations such as external scanner middleware and custom label reports increase the quoted scope. You receive a fixed quote after the scoping call, never a surprise invoice.