The data a passport is built from — product name, brand, weight, country of origin, manufacturer — is already in the ERP. The Odoo connector stops it from being typed a second time, and then goes one step further than a PIM can: it reports what happens to the goods.

Unlike the UnoPim, ERPNext and metasfresh routes, which a service of ours polls, Odoo publishes from inside Odoo. The addons run in the ERP, queue on save, and deliver in the background on a schedule. Nothing of ours needs to reach into your database.

Seven addons, two services

The connector is split along Odoo's own module boundaries. The base addon depends on product and nothing else; everything that needs another Odoo app is a bridge that installs itself when that app is present. A database never carries code for an app it does not run.

Two services are involved and it helps to keep them apart from the first minute. The resolver holds master data — what a product is — and the three master-data addons write to it. The EPCIS repository holds events — what became of a product — and the three events addons write to it. Different hosts, configured separately, one offline token for both.

The Learn More button on each addon's tile in Odoo's app list opens the page linked above.

Installing

git clone https://github.com/openepcis/openepcis-odoo.git
# put the repository on your addons path, then:
odoo -d yourdb -i openepcis_connector

Then Settings → General Settings → OpenEPCIS: the resolver's URL and an offline token issued in the OpenEPCIS web interface. The bridges follow on their own once Inventory, Expiration Dates, Manufacturing or Point of Sale is installed; the events addon is a deliberate second step, because reporting movements to a shared repository is a decision rather than a default.

Two branches, following Odoo's convention: 18.0 for the current long-term release and 19.0 for the newest one. Same addons, same behaviour; they differ only where Odoo itself does — Odoo 19 can nest packages, so only there does a pallet of cases produce an aggregation of SSCCs.

The repository is openepcis/openepcis-odoo on GitHub, under LGPL-3. A demo container image with all six connector addons preinstalled is described in its docker/demo directory.

Where to start

• Master data first. The connector: give a product a barcode or draw one, set the GPC brick on its category, tick Publish to OpenEPCIS, and watch the readiness line tell you what a registry still wants.
• Then the instance level. Lots and serial numbers follow the product into the catalog, one document per batch or unit, with a QR code where labels are actually printed.
• Then events. Visibility events need a GLN on a location and a business step on an operation type, and then every validated transfer tells the repository what moved.
• See it end to end. A warehouse day: receipt, pallet, delivery, return, grinding and a withdrawn report — nine screens, twelve events, each copied from the outbox.

What it does not do

Changes made in the OpenEPCIS web interface to products do not flow back into Odoo; organizations do, on a schedule. A PUT merges rather than replaces, so clearing a field in Odoo leaves the published value in place — removing a published value is a deliberate act, not a side effect of a sync. Warehouses are given GLNs so events can name them, but are not published as GS1 places of their own.