Category: ERP and e-commerce systems
Author: AorBorC Technologies
Published: July 21, 2026
The hard part is not the QR code. It is proving that supplier evidence, ERP master data, and the sellable catalog describe the same product.
On July 20, 2026, the European Commission launched the Digital Product Passport Registry and a testing environment.
For businesses responsible for placing covered products on the EU market, the launch creates a real registration system to test. It does not bring forward any product-specific passport obligation.
A Digital Product Passport, or DPP, is a digital container for product information required under applicable European Union rules. The passport data remains decentralised. The new registry is the central infrastructure for registering the unique product identifiers and associated metadata that connect a covered product to its passport.
That distinction matters. The registry going live does not mean every product placed on the EU market or put into service suddenly needs a passport. Product-specific legislation determines which products are covered, what information is required, whether a passport applies at model, batch, or item level, and when the obligation starts. The Commission's announcement identifies February 18, 2027 as the first implementation deadline, for certain types of large batteries.
AorBorC's view: this is a product-data operating model, not a QR-code project.
What changed
The Commission launched a secure registry interface and a testing environment. Its announcement says affected economic operators can register through either the user interface or an API, and request a secure electronic proof of registration for third parties, including business-to-business transactions.
The implementation regulation behind the registry was adopted on July 16, published on July 17, and is listed by EUR-Lex with an August 6, 2026 date of effect. It defines a wider operating architecture that includes:
- a secure user interface and registration API;
- identity verification for economic operators and value-chain actors authorised under the relevant Union rules;
- unique registration identifiers;
- storage of unique identifiers and, where relevant, commodity codes for customs release for free circulation;
- a verification platform for passport existence and completeness;
- a semantic repository for machine-readable structures, meanings, versions, and interoperability requirements;
- a list of verified DPP service providers; and
- logs for relevant registry operations.
The registry's automated checks cover data structure, required registration granularity, semantic conformity, and selected identifiers or links where relevant. They are not proof that the underlying data is substantively correct or that the product complies with every applicable rule. The implementing regulation leaves substantive verification to market-surveillance authorities.
The Commission also says eight harmonised DPP standards have been developed and six were available through national standards organisations at launch. They cover areas such as identifiers, data carriers, interoperability, APIs, data exchange, and storage.
These are useful technical foundations. They do not clean a product catalog, reconcile duplicate SKUs, prove a supplier document belongs to the current product version, or decide which system owns a batch identifier.
Why operational leaders should care
The registry makes product identity a cross-system control.
For a manufacturer or distributor, supplier evidence may arrive through email, a portal, shared storage, or a custom app. Odoo or another ERP may own the product master, bill of materials, purchasing, lots, serial numbers, inventory, and warehouse movements. Shopify or another e-commerce platform may own the sellable catalog, variants, descriptions, and channel publication. A product information system may sit between them. Customs, repair, support, and compliance teams may need different views of the same record.
If those systems disagree, the DPP handoff becomes fragile.
A model-level passport does not map like an item-level passport. A Shopify variant might carry the customer-facing SKU, option combination, and channel publication state. Odoo might separately own the operational product variant, bill of materials, supplier references, commodity code, and lot or serial records. Those structures are related, but they are not automatically one-to-one. Matching them only by product title is unsafe.
The integration also has to distinguish a commercial edit from a controlled identity or version change. Updating a storefront description may not change passport identity. A supplier component, regulated attribute, or product identifier change may require a review and version decision under the applicable product rule.
The operational question is therefore not "Where do we generate the code?" It is "Which product identity survives every handoff?"
The product-data chain to map
Before choosing a DPP platform or building an API integration, map six records for one covered product:
- Supplier evidence: documents, declarations, test results, and source references used by the responsible team.
- Product master: the ERP or product-information record that owns identifiers, versions, variants, and operational status.
- Sellable catalog: the channel-facing product and variant structure used in Shopify, a marketplace, or another commerce system.
- Physical traceability: the batch, lot, serial, warehouse, or item records used in procurement, inventory, manufacturing, fulfillment, repair, and returns.
- Passport record: the decentralised product data, version, supporting references, access rules, and destination reached by the QR code or other data carrier.
- Registry entry: the submitted registration data, status, unique registration identifier, and separate proof-of-registration document when requested.
For each record, name the owner, source of truth, update trigger, approval step, exception path, and evidence retained. If the team cannot trace one product across all six records, the gap should be fixed before registration automation makes it harder to see.
Digital Product Passport implementation checklist
Use this checklist as an operational starting point. These are internal control recommendations, not a claim that every field must be submitted to the registry. Mandatory data, product scope, and legal interpretation come from the applicable product-specific rules and still need qualified review.
- Confirm scope product by product. Record the applicable EU rule, product group, responsible economic operator, required start date, and source used for the decision. Do not copy a generic DPP deadline across the whole catalog.
- Build an affected-product register. Connect each in-scope product to its ERP item, catalog product, variants, suppliers, facilities, commodity code where relevant, and current operational status.
- Set the required granularity. Confirm whether the applicable rule requires the passport at model, batch, or item level. Map the required identifiers to existing ERP records. When a required DPP identifier differs from an ERP key, maintain an explicit, governed crosswalk instead of creating an unmanaged parallel scheme.
- Assign identifier authority and custody. Record the authoritative issuer and the system of record for each product, operator, facility, batch, lot, and serial identifier. The registry generates the unique registration identifier; define where that identifier is stored, who may correct the underlying registration, and how duplicates are prevented.
- Separate passport data from registry metadata. Document where the decentralised passport data lives, what the central registry receives, who can access each layer, and how the QR code or other data carrier resolves to the correct product and variant.
- Create an evidence trail. Link each reviewed data point to its source document, supplier, product version, reviewer, and approval date. AI can help extract or classify incoming documents, but regulated product data should not be written into approved product records without human review.
- Define system ownership. State what Odoo or another ERP owns, what Shopify or another storefront owns, what a product-information system owns, and what a Zoho Creator or custom workflow app owns. Avoid two systems being allowed to silently overwrite the same field.
- Design the registration integration. Cover authentication, validation against the required data model, duplicate-safe resubmission, retries, version changes, rejected registrations, registry outage and recovery, delegated-user offboarding, logs, and evidence retention. A generated proof remains available in the registry for 90 calendar days and can be regenerated; retain the registration identifier, timestamp, hash or version, and proof under the business's evidence policy.
- Test lifecycle and release gates. Rehearse a new model, batch creation, item registration where applicable, supplier change, corrected identifier, product withdrawal, catalog unpublish, returned item, and replaced or expired document. Test a purchase receipt with missing evidence, the hold before stock becomes sellable, and the product-specific decision on whether the registry record must change.
- Run end-to-end acceptance testing. Verify one product from supplier evidence through ERP, Shopify or another catalog, warehouse, QR code or other data carrier, registry structural and semantic checks, separate substantive review, and retained proof. Reconcile affected products expected versus registered, failed submissions and retries, ERP/catalog/registry version mismatches, live products missing the correct passport destination, and commodity-code mismatches where relevant. Include compliance, product, procurement, warehouse, e-commerce, IT, and support owners in sign-off.
Where the hype is not useful
Do not treat the July launch as a universal compliance deadline. The registry supports multiple product groups, but the actual obligations arrive through product-specific rules and schedules.
Do not assume a DPP vendor can repair product master data by installing a connector. If the ERP, warehouse, and storefront disagree on product identity, a connector will automate the disagreement.
Do not make the data carrier the project centre. A QR code or other carrier is only useful when it resolves to the right passport at the right granularity and remains connected to the physical and commercial product throughout its lifecycle.
Do not let AI-generated extraction become unreviewed product truth. Document intake can be accelerated, but supplier evidence, classification, product scope, and regulated data need accountable review.
Finally, do not use a systems implementation as a substitute for legal or conformity advice. AorBorC can map and build the operational workflow; the responsible business and its qualified advisers must confirm the applicable product rules and compliance interpretation.
AorBorC's implementation view
AorBorC would approach DPP readiness in four passes:
- Rescue-style audit: trace one covered product across supplier evidence, ERP, catalog, warehouse, integrations, and reports to find identity breaks.
- Operating design: define source-of-truth boundaries, model/batch/item relationships, permissions, review gates, exception ownership, and registration evidence.
- Systems delivery: configure Odoo or another ERP, strengthen Shopify catalog operations, build ERP modules or Zoho Creator workflows, and connect the required APIs without hiding failures.
- Human-reviewed launch: test normal, changed, duplicate, rejected, offline, and recovery scenarios before scaling to the affected catalog.
AorBorC's founder-led model is useful when one product record has to stay aligned across ERP, Shopify, supplier review, warehouse execution, integrations, reporting, and long-lived support.
Relevant service paths:
- Odoo implementation for product, purchasing, inventory, manufacturing, warehouse, and reporting workflows.
- E-commerce store development for catalog, variant, product-data, and channel handoffs.
- ERP module development for product-specific controls, approvals, traceability, and exception queues.
Business takeaway
The live EU registry gives Digital Product Passport teams a concrete system to test. It does not make every product subject to registration today. The first useful deliverable is not a code or a connector. It is a verified product-identity map that shows how supplier evidence, ERP data, the sellable catalog, physical traceability, the passport, and the registry entry stay aligned.
If your team needs to find those boundaries before choosing tools, map one covered product with AorBorC. Bring the real product records, supplier documents, catalog variants, warehouse identifiers, and exception cases your team already handles.