Barcode / GS1 & Marketplace Identifier Manager

Key Features

Dedicated `gs1.identifier` model storing GTIN-8/12/13/14, UPC-A, EAN-13, ISBN, ASIN and MPN as separate typed rows per product, not one overloaded `barcode` field

GS1/UPC/EAN/ISBN check-digit validation via `@api.constrains` (modulo-10) that rejects a malformed digit at save time

Cross-catalog uniqueness enforcement — SQL `unique` constraint plus a `@api.constrains` scan blocks the same GTIN attaching to two products

`marketplace.sku` model mapping each product to `(marketplace, sku, external_id)` tuples for Amazon ASIN, eBay item ID, Walmart, Noon and channel-specific SKUs

GTIN-exemption `Boolean` flag with a brand-registry / approval note field for products legitimately listed without a GTIN

Computed `@api.depends` fields that surface primary GTIN and channel-ready status on the product list view for at-a-glance QA

Inline notebook page on `product.template`/`product.product` forms (XML/OWL) editing all identifiers and mappings without leaving the product

Bulk import via a mapped Odoo `Import` template and export (XLSX/QWeb) for feeding channel integrations and offline reconciliation

GTIN normalization helpers — pad UPC-12 to GTIN-14, strip formatting, and flag length/format mismatches per identifier type

Duplicate-and-conflict report listing products sharing an identifier or missing a required one for a selected marketplace

Role-based access via `ir.model.access.csv` and record rules so editors maintain identifiers while other roles have read-only visibility

Standard XML-RPC/JSON-RPC exposure so existing Amazon/Google/eBay feed jobs read identifiers via `search_read` with no custom scraping

Automated action / server-action hook to flag a product as not-list-ready when a required identifier for an active marketplace is missing

Barcode-field bridge that keeps Odoo's native `barcode` in sync with the designated primary GTIN so scanning and reports still work

Compatible with Odoo 17.0, 18.0 and 19.0 on both Community and Enterprise editions

Built to order, done for you

No DIY setup — a working app, built, installed and supported by ECOSIRE.

You order

Start with a one-time build price. We scope it with you at kickoff.

We build & install

ECOSIRE builds, configures and installs it on your Odoo.

Go live + support

You go live in about 2–4 weeks, with a post-launch support window.

About this Product

Marketplaces reject listings that don't carry a valid, unique product identifier. Amazon wants a GTIN or an approved GTIN-exemption; eBay, Google Shopping, Walmart and Noon each enforce their own GTIN/UPC/EAN rules; and the same physical product often needs a different SKU or channel-specific ID on every store. In stock Odoo, product.template/product.product give you a single barcode field and a default_code (internal reference) — one slot for one code. There is no place to hold a UPC and an EAN and an ASIN and an ISBN at once, no check-digit validation, no cross-product uniqueness guard, and no way to say "this SKU is what we list on eBay, that ASIN is what Amazon assigned." Catalog managers end up tracking all of this in spreadsheets, and a single transposed digit becomes a suppressed listing.

We build a dedicated identifier layer on top of your product catalog. The core is a gs1.identifier model (a models.Model linked by Many2one to product.product) that stores each identifier as its own typed row — GTIN-8/12/13/14, UPC-A, EAN-13, ISBN, ASIN, MPN and free-form channel IDs — with a type selection field and a value char. A @api.constrains hook runs GS1 check-digit validation (the modulo-10 algorithm) on GTIN/UPC/EAN/ISBN values and rejects a bad digit at save time, and a SQL unique constraint plus a @api.constrains uniqueness scan stops the same GTIN being attached to two different products. A second marketplace.sku model maps each product to a (marketplace, sku, external_id) tuple so Amazon ASINs, eBay item IDs and per-channel SKUs live in structured rows, not notes.

On top of the data model we build the working surfaces: a notebook page on the product form (XML/OWL views) listing all identifiers and marketplace mappings inline; a Boolean GTIN-exemption flag with a brand-registry note field for products legitimately sold without a GTIN; ir.model.access.csv rules plus record rules so catalog editors can maintain identifiers while read-only roles only view them; and bulk import/export via a mapped Odoo Import template and an optional QWeb/XLSX export for channel feeds. Because everything is real Odoo data, your existing integrations reach it over standard XML-RPC/JSON-RPC — an Amazon or Google feed job can read search_read on gs1.identifier and marketplace.sku with no scraping. The module targets Odoo 17.0, 18.0 and 19.0 and works on Community and Enterprise (identifiers are core-model extensions, so no Enterprise-only dependency).

This is build-to-order: ECOSIRE develops, installs and supports the module for your specific catalog and channel mix — it is not an existing apps.odoo.com download. We start with a short scoping call to confirm which identifier types and marketplaces you sell on, your uniqueness and exemption rules, and how your feeds consume the data. Typical delivery is 2-4 weeks from confirmed scope, delivered as installable source you own, validated on a staging database against your real catalog before go-live.

What you get

Installable Odoo module source code for your target version (17.0, 18.0 or 19.0), with `__manifest__.py`, models, views, security and data files

Installation and configuration on your environment, including identifier types, marketplaces and validation rules matched to your catalog

Technical documentation — data model, constraints, access rules, XML-RPC/JSON-RPC access points and import/export field mapping

End-user guide plus a live training session for your catalog team on maintaining identifiers, exemptions and marketplace mappings

UAT on a staging database against your real product data, with a documented rollback plan before production go-live

Post-go-live support window for defect fixes and questions after launch

Full Git repository handover so you own and can extend the source

Who this is for

Marketplace catalog manager

Owns listings across Amazon, eBay, Walmart, Noon and Google Shopping and is blocked when a product lacks a valid GTIN or the right per-channel SKU. Needs one place to hold every identifier, catch bad check digits before upload, and know instantly which SKUs aren't list-ready.

E-commerce / integrations lead

Runs the feed and integration jobs that push products to each channel. Needs identifiers as structured, queryable Odoo data reachable over XML-RPC/JSON-RPC so feeds pull a clean GTIN and channel ID instead of parsing a barcode field or a spreadsheet.

Brand owner using GTIN exemptions

Sells own-brand or bundled products that are legitimately exempt from GTIN on some channels. Needs to flag exemptions, record brand-registry approval notes, and prove per-product why a listing carries no GTIN.

Operations / data-quality manager

Accountable for catalog accuracy across systems. Needs uniqueness enforcement, a duplicate/conflict report, and role-based access so identifier changes are controlled and auditable, not free-typed into notes.

How Barcode / GS1 & Marketplace Identifier Manager Compares

Criterion	ECOSIRE	Custom Build	Competitor	Odoo Native
Identifier storage	Typed rows per product for GTIN/UPC/EAN/ISBN/ASIN/MPN	Whatever you spec and build in-house	Often a few extra fixed fields	One `barcode` + one `default_code` field only
Check-digit validation	GS1 modulo-10 enforced via `@api.constrains` at save	Only if you write and test it	Rarely included or partial	None — accepts any string
Cross-product uniqueness	SQL `unique` + constraint scan + conflict report	Must design and maintain yourself	Inconsistent, often absent	No GTIN uniqueness guard
Per-marketplace SKU/ID mapping	`marketplace.sku` model per channel (ASIN, item ID, SKU)	Buildable but from scratch	Usually tied to one integration	Not modeled at all
GTIN exemptions	Flag + brand-registry approval note per product	Only if scoped in	Seldom supported	No concept of exemption
Feed / API access	Structured data over XML-RPC/JSON-RPC, no scraping	Depends on your data model	Often locked to its own feed job	Limited to the single barcode field
Fit to your channels	Scoped to your exact marketplaces and rules	Fully bespoke but you own the effort	Generic, one-size-fits-all	Not channel-aware
Delivery & ownership	2-4 weeks, source + Git handover, support window	Your timeline, cost and maintenance burden	Instant install, vendor-controlled updates	Included, but lacks the capability

Frequently Asked Questions about Barcode / GS1 & Marketplace Identifier Manager

How is delivery handled and how long does it take?

This is a build-to-order module, not an instant download. After a short scoping call to confirm your identifier types, marketplaces, uniqueness and exemption rules, we build and install it for your Odoo version. Typical delivery is 2-4 weeks from confirmed scope, validated on a staging database against your real catalog before go-live.

Do I get the source code and can we extend it later?

Yes. You receive the full installable module source and a Git repository handover, so you own it outright and your team or any Odoo developer can extend it. Nothing is locked or obfuscated.

What support and updates do I get after launch?

Every build includes a post-go-live support window for defect fixes and questions. Because we hand over the source and target Odoo 17/18/19, updates and version upgrades can be scoped as follow-on work; we can also arrange an ongoing support/maintenance retainer if you prefer.

Does it work with my Odoo version and edition?

We build for Odoo 17.0, 18.0 or 19.0, whichever you run, on both Community and Enterprise. The identifier and marketplace-mapping models are core-model extensions, so there is no Enterprise-only dependency.

Will my existing marketplace feeds and integrations be able to read the identifiers?

Yes. Identifiers and marketplace mappings are stored as real Odoo models, so any existing Amazon, Google Shopping or eBay feed job reads them over standard XML-RPC/JSON-RPC with `search_read`. No scraping and no separate database.

How does check-digit validation and uniqueness actually work?

Each GTIN/UPC/EAN/ISBN is validated with the GS1 modulo-10 check-digit algorithm inside an `@api.constrains` hook, so a bad digit is rejected at save time. A SQL `unique` constraint plus a uniqueness scan stop the same GTIN being attached to two different products, and a conflict report surfaces any existing duplicates.

What about products that legitimately have no GTIN?

Each product can carry a GTIN-exemption flag with a brand-registry / approval note field, so you can list exempt products on channels that allow it and keep a per-product record of why no GTIN is present.