Skip to content
  • There are no suggestions because the search field is empty.

Why is a GTIN not necessarily the Product Model identifier for an EU-DPP?

Short answer

A GTIN identifies a commercial Trade Item or Sales Unit.

An EU-DPP can apply to a Product Model, Batch or Serialized Item.

Those are not necessarily the same object.

A Product Model can occur in several Sales Units, while one Sales Unit can contain several Product Models. SyncForce therefore gives the Product Model its own persistent identity instead of deriving that identity from the GTIN of one particular Sales Unit.

The fundamental SyncForce principle is:

Sales Unit = Product(s) + Packaging

What does a GTIN identify?

A GTIN identifies the commercial Trade Item.

In the SyncForce Golden Hierarchy, the Sales Unit is the finished commercial proposition placed on the market.

The Sales Unit normally carries information such as:

  • GTIN
  • commercial description
  • market information
  • artwork
  • claims
  • trade information
  • stock information

The GTIN therefore belongs to the Sales Unit.

It does not automatically become the identity of every Product Model or Packaging System related to that Sales Unit.

What does the Product Model identify?

A Product Model represents the Product with its own technical and regulatory lifecycle.

Examples include:

  • a laptop model
  • a charger model
  • a battery model
  • a towel
  • a reusable bag

A Product Model can exist before it is assigned to a Sales Unit.

It can also participate in several Sales Units.

SyncForce therefore explicitly separates:

Product Model ≠ Sales Unit

and:

Product Model ID ≠ GTIN

Why does the laptop example make this clear?

Consider a laptop purchased online or in a retail store.

The consumer buys:

one Sales Unit

with:

one GTIN

Inside the box are:

  • Laptop Product Model
  • Charger Product Model
  • one Packaging System

After unboxing, the laptop and charger continue to exist independently.

The Packaging System enters its own recycling, reuse or waste lifecycle.

The commercial Sales Unit has largely fulfilled its physical purpose.

This immediately shows that:

one Sales Unit does not necessarily equal one Product.

What happens when the same charger is used in several Sales Units?

Suppose the same charger is used across several current laptop models.

The charger might appear in:

  • Laptop Sales Unit A, GTIN A
  • Laptop Sales Unit B, GTIN B
  • Laptop Sales Unit C, GTIN C
  • Laptop Sales Unit D, GTIN D
  • Replacement Charger Sales Unit, GTIN E

There is still only one Charger Product Model.

If the Product Model identifier were derived from GTIN A, the same charger would require another Product Model identifier when used in GTIN B.

That would make Product identity depend on a commercial context in which the Product happens to be sold.

SyncForce instead follows the principle:

Identity belongs to the object being identified, not to the commercial context in which that object happens to be used.

Can one Product Model occur in several Sales Units?

Yes.

This is a normal manufacturing scenario.

A Product Model may be:

  • used inside several different Sales Units
  • sold in different markets
  • packaged differently
  • included in bundles
  • supplied as a replacement part
  • reused across several finished goods

The Product Model remains the same Product Model even when its commercial context changes.

The relationship is therefore:

Product Model → many Sales Units

Can one Sales Unit contain several Product Models?

Yes.

The opposite relationship is equally important.

One Sales Unit can contain:

  • Product Model A
  • Product Model B
  • Product Model C
  • one Packaging System

Examples include:

  • laptop + charger
  • toy + remote control + batteries
  • towel + bag
  • multi-product gift sets
  • tool + charger + battery

The relationship is therefore:

Sales Unit → many Product Models

This creates a many-to-many relationship:

Product Models ↔ Sales Units

That relationship is one of the reasons Product Model identity should not be serialized from the GTIN.

Can the Product exist before the GTIN is known?

Yes.

This is another important reason to separate Product Model identity from Sales Unit identity.

Products may be manufactured before:

  • the final Sales Unit is assembled
  • packaging is sourced
  • the final market configuration is known
  • the Sales Unit is commercially introduced

The Product therefore needs its own identity independently from the later Sales Unit.

This is particularly relevant in manufacturing environments where Products, Packaging Components and final Sales Units are created at different points in the lifecycle.

How does this affect the EU-DPP?

An EU-DPP can apply at:

  • Product Model level
  • Batch level
  • Serialized Item level

The applicable Product regulation or delegated act determines which level is required.

SyncForce therefore identifies the Product independently from the Sales Unit.

For a Product Model, SyncForce can use:

25P + VTA Product Model ID

For example:

VTA-MPLA-PM-346UJI3NUM

represented as:

https://prodigi.link/?.25P=VTA-MPLA-PM-346UJI3NUM

This identifier follows the Product Model, not one particular GTIN.

Does this mean GTIN is not important?

No.

GTIN remains extremely important.

It continues to identify the commercial Sales Unit and supports processes such as:

  • ordering
  • invoicing
  • retail
  • POS
  • warehousing
  • GS1 GDSN
  • commercial data exchange

 

How does SyncForce identify the Sales Unit?

The Sales Unit remains identified through:

GTIN

For example:

08712345678901

prodigi.link can make that Sales Unit digitally resolvable through GS1 Digital Link:

https://prodigi.link/01/08712345678901

The Sales Unit can also have GS1 qualifiers such as Lot or CPV.

For example:

/01/{GTIN}/10/{lot}

or:

/01/{GTIN}/22/{CPV}

This remains the commercial identity route.

How does SyncForce identify the Product Model?

For the EU-DPP Data Identifier route, SyncForce uses:

25P

together with the VTA Product Model identifier.

For example:

https://prodigi.link/?.25P=VTA-MPLA-PM-346UJI3NUM

This remains the Product identity route.

The two routes can be linked through the SyncForce Golden Hierarchy without merging them.

Can the Sales Unit still link to the EU-DPP?

Yes.

This is an important part of the architecture.

A Sales Unit identified by:

/01/{GTIN}

can resolve to a Marketing Landing Page.

That page can link to one or more Product Models and their EU-DPP resources.

For example:

Sales Unit

↓

Marketing Landing Page

↓

Product Model A → EU-DPP A

↓

Product Model B → EU-DPP B

This is indirect access.

The Product itself can also carry a data carrier identifying its Product Model directly.

This provides direct access to the EU-DPP.

Why is the distinction important for AI, software and linked data?

The relationship should not exist only visually on webpages.

SyncForce can expose the relationships as machine-readable links.

For example:

Sales Unit

containsProduct → Product Model A

containsProduct → Product Model B

usesPackagingSystem → Packaging System C

and:

Product Model

hasEUDigitalProductPassport → EU-DPP

This allows software, APIs and AI systems to understand that:

  • the GTIN identifies the Sales Unit
  • the Product Model has its own identity
  • the EU-DPP belongs to the applicable Product identity
  • Packaging is another related but separate domain

What is the SyncForce Golden Hierarchy principle behind this?

The SyncForce Golden Hierarchy separates:

Product identity

commercial Sales Unit identity

Packaging identity

and:

regulatory EU-DPP identity

while maintaining the relationships between them.

In practical terms:

We manufacture Products.

We combine Product(s) and Packaging into Sales Units.

We sell those Sales Units using GTINs.

We identify Product Models independently from those GTINs.

We identify Packaging Systems independently from those GTINs.

We use prodigi.link to connect those identities to digital resources.

This allows SyncForce to support EU-DPP, PPWR, the EU Battery Regulation and future Product-specific regulation without forcing different business objects into one GTIN-based model.

 See the full overview: How does SyncForce support the EU Digital Product Passport, EU-DPP? 

In one sentence

A GTIN uniquely identifies the commercial Sales Unit, while the EU-DPP must identify the regulated Product at the required Product Model, Batch or Serialized Item level. SyncForce therefore keeps these identities connected, but independent.