A build-to-order Odoo module that lets you attach unlimited alternate barcodes to a single product and resolve any of them instantly during scanning, search, POS, and inventory operations. ECOSIRE scopes, builds, installs, and supports it for your Odoo 17/18/19 environment. Built to order by ECOSIRE for Odoo 17, 18, 19 — indicative price from $249.00 USD; request a quote for a scoped proposal.
Manifeste de l'app
Conçu autour de votre flux de travail
A build-to-order Odoo module that lets you attach unlimited alternate barcodes to a single product and resolve any of them instantly during scanning, search, POS, and inventory operations. ECOSIRE scopes, builds, installs, and supports it for your Odoo 17/18/19 environment.
Aucune configuration à faire vous-même — une app fonctionnelle conçue, installée et prise en charge par ECOSIRE.
Commencez par un prix de développement unique. Nous cadrons le projet avec vous au lancement.
ECOSIRE la développe, la configure et l'installe sur votre Odoo.
Vous êtes en ligne en 2–4 semaines environ, avec une période d’assistance après le lancement.
Odoo out of the box stores exactly one barcode per product.product variant, in the barcode field, under a single-value uniqueness constraint. That breaks down the moment reality is messier than the master data: the same SKU arrives from two suppliers with different EAN-13 codes, a manufacturer changes the pack barcode between production runs, a legacy system and your carton labels each carry their own identifier, or a case and its inner unit need to scan to the same item. When a scanner reads a code Odoo does not recognize as the primary barcode, the POS, Inventory, and Sales flows simply fail to find the product — and staff fall back to manual name search, which is slow and error-prone at the counter and on the warehouse floor.
We build a made-to-order module that adds a proper one-to-many barcode model to your products. A new product.multi.barcode model (a models.Model with product_tmpl_id / product_id relations, a name barcode field, an optional barcode_type selection such as EAN-13, UPC-A, or internal, and a sequence for priority) lets you register any number of alternate barcodes against a template or a specific variant. We override the product name_search and _search methods so that scanning or typing any registered barcode — not just the native barcode field — resolves to the correct product everywhere the standard search widget is used: POS, stock transfers, inventory adjustments, and sales/purchase order lines.
Technically, the implementation is careful about the parts that matter. A SQL-level uniqueness index (or a @api.constrains guard) prevents the same barcode from mapping to two different products, so scans stay deterministic. Access is governed by ir.model.access.csv plus optional record rules for multi-company setups, and the alternate-barcode list is surfaced as an editable one-to-many tab on the product form via inherited XML views (OWL-compatible for 17/18/19). Where you scan against the Point of Sale, we extend the POS load and the JS barcode-lookup so the alternate codes are available offline in the browser cache, not just server-side. Optional extras we quote on request include printing selected alternate barcodes on QWeb product-label reports, exposing the barcodes over the XML-RPC/JSON-RPC API for external systems, and an automated action to import barcodes in bulk from a spreadsheet.
Delivery is build-to-order: this is not an existing apps.odoo.com download. After a short scoping call we confirm exact scope, your Odoo edition (Community or Enterprise) and version (17.0 / 18.0 / 19.0), then build on a staging copy, run UAT with you, and deploy to production with a rollback plan. Typical delivery is 2–4 weeks from confirmed scope. Pricing starts from $249 (indicative, single-company base scope); multi-company record rules, POS-offline lookup, label-report printing, and bulk data-migration volume increase the quoted scope. You receive a fixed quote after the scoping call.
Runs multi-till or multi-store Odoo POS where the same item arrives with different manufacturer or supplier barcodes. Needs any pack to scan to the right product at the counter, including offline, without cashiers hunting by name.
Handles goods-in from multiple suppliers and mixed case/inner-unit labeling. Needs receipts, transfers, and inventory adjustments to resolve every barcode variant to one SKU so putaway and picking stay fast and accurate.
Owns the Odoo instance and integrations. Wants a clean, upgrade-safe extension with proper access rules and XML-RPC/JSON-RPC exposure so external WMS, PIM, or e-commerce systems can read and write alternate barcodes.
Consolidates product master data from legacy systems that each carried their own identifiers. Needs to bulk-import many alternate codes per product and keep them unique without overwriting the primary Odoo barcode.
| Critère | ÉCOSIRE | Construction personnalisée | Concurrent | Odoo natif |
|---|---|---|---|---|
| Barcodes per product | Unlimited alternate codes per template or variant, plus native field | Whatever your team builds, if scoped correctly | Usually multiple, but fixed to the author's data model | |
| Scan search coverage | POS, inventory, sales and purchase lines via `name_search`/`_search` overrides | Depends on how thoroughly your devs override search methods | Often catalog and POS only; inventory coverage varies | |
| POS offline lookup | Optional: alternate codes cached in POS browser for offline scans | Extra work most teams skip | Rarely handled for offline | |
| Uniqueness safety | SQL index + `@api.constrains` prevent one code mapping to two products | Only if your team adds the constraint | Varies by author; not always enforced | |
| Fit to your Odoo | Built and tested against your exact edition and version 17/18/19 | Fully bespoke but you own all the build effort | Generic; may lag on new Odoo versions | |
| Support & handover | Support window, docs, training, and full git repo handover | Internal knowledge only, no external backup | Author support quality and responsiveness vary | |
| Delivery model | Build-to-order, 2–4 weeks, fixed quote after scoping | Open-ended internal timeline and cost | Instant download but generic and unsupported for your case | |
| External integration | Optional XML-RPC/JSON-RPC exposure for WMS/PIM/e-commerce sync | Possible with extra scoping | Seldom exposes alternate codes via API |
No. This is a build-to-order module. ECOSIRE builds it against your confirmed Odoo edition and version after a scoping call, then installs, tests, and supports it. There is no instant download — you receive installable source code once your build is complete.
Typical delivery is 2–4 weeks from confirmed scope. The exact timeline depends on options such as POS-offline lookup, multi-company record rules, label-report printing, and any bulk data migration. We commit to a delivery window in your fixed quote after the scoping call.
Pricing starts from $249 as an indicative, single-company base-scope figure. Drivers such as multi-company setups, POS integration depth, custom label reports, external-API sync, and data-migration volume increase the quoted scope. After a short scoping call we send a fixed quote — no open-ended hourly billing.
We support Odoo 17.0, 18.0, and 19.0 on both Community and Enterprise. POS and inventory behavior differs slightly between editions, so we confirm your exact edition during scoping and build/test against that target. If you run multiple versions, we can quote a build per version.
Every build includes a post-go-live support window for defect fixes and configuration help. Because you receive the full git repository, your team can maintain the module too. When you upgrade Odoo to a newer major version, we can quote a migration of the module to the new API as a separate, scoped engagement.
Yes, when POS integration is in scope. We extend the POS product load and the JavaScript barcode lookup so alternate codes are cached in the browser and resolve even without a live server connection. This is one of the options that affects the quote, so flag it on the scoping call.
No. The design is non-destructive: the standard `barcode` field on `product.product` keeps working as the primary code. Alternate barcodes live in a separate one-to-many table with a uniqueness guard, so scans stay deterministic and your existing data and workflows are untouched.
A build-to-order Odoo module that lets you attach unlimited alternate barcodes to a single product and resolve any of them instantly during scanning, search, POS, and inventory operations. ECOSIRE scopes, builds, installs, and supports it for your Odoo 17/18/19 environment.