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

How are Product Model, Batch and Serialized Item identified for an EU-DPP?

Short answer

An EU-DPP can apply at three different levels:

  • Product Model
  • Batch
  • Serialized Item

SyncForce supports all three levels.

For the VTA-based EU-DPP route, SyncForce uses ASC MH10.8.2 Data Identifiers consistently:

  • 25P for the Product Model reference
  • 1T for Batch or Lot
  • S for a contextual Serial Number
  • 25S for a globally unique Serialized Item

The most important rule is:

An EU-DPP identifier remains within one identification system.

When SyncForce uses the Data Identifier route, it does not mix those Data Identifiers with GS1 Application Identifiers such as 10, 17 or 21.

At what level can an EU-DPP exist?

The applicable Product regulation or delegated act determines the required EU-DPP granularity.

An EU-DPP can be established at:

Product Model level 

The EU-DPP applies to the Product Model as a whole.

Batch level

The EU-DPP applies to a specific production Batch or Lot of a Product Model.

Serialized Item level

The EU-DPP applies to one individual physical Product.

SyncForce therefore models these three identities separately instead of forcing all EU-DPP identification into the commercial Sales Unit GTIN.

How does SyncForce identify a Product Model?

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

SyncForce uses:

25P + VTA Product Model ID

For example:

VTA-MPLA-PM-346UJI3NUM

The complete web-enabled EU-DPP identifier is:

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

In this structure:

  • 25P is the Data Identifier for the Product reference
  • VTA is the ISO/IEC 15459 Issuing Agency Code
  • MPLA identifies the organization or namespace
  • PM identifies the SyncForce Product Model object
  • 346UJI3NUM uniquely identifies the Product Model

This Product Model identity is independent from the GTIN of any Sales Unit in which the Product Model occurs.

Why is Product Model identity independent from GTIN?

A Product Model and a Sales Unit are different business objects.

The SyncForce Golden Hierarchy uses:

Sales Unit = Product(s) + Packaging

This means:

  • one Product Model can occur in several Sales Units
  • one Sales Unit can contain several Product Models

For example, the same charger Product Model may be used in several laptop Sales Units and may also be sold separately as a replacement charger.

The charger therefore needs one Product Model identity of its own.

It should not receive a different identity merely because it appears under another GTIN.

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

How does SyncForce identify a Batch?

A Batch is a production grouping belonging to a Product Model.

Within SyncForce, the business identity is:

Product Model ID + Lot/Batch Number

For example:

Product Model:

VTA-MPLA-PM-346UJI3NUM

Batch:

LOT-2028-00425

For an EU-DPP using the Data Identifier route:

  • 25P identifies the Product Model
  • 1T identifies the Batch or Lot

The EU-DPP URL becomes:

https://prodigi.link/?.25P=VTA-MPLA-PM-346UJI3NUM&.1T=LOT-2028-00425

The Batch Number therefore qualifies the Product Model.

It does not become an unrelated Product identity.

Conceptually:

25P Product Model

1T Batch

=

Batch-level EU-DPP identity

Why does SyncForce use Product Model + Batch?

A Batch only has meaning in the context of the Product that was manufactured.

For example:

LOT-2028-00425

on its own may not be globally unique.

But:

Product Model PM-346UJI3NUM + LOT-2028-00425

identifies a specific production Batch of that Product Model.

This avoids creating unnecessary independent Product identities for every Batch while still supporting Batch-level EU-DPP requirements.

How does SyncForce identify a Serialized Item?

A Serialized Item is one individual physical Product.

SyncForce supports two identification approaches.

This is the only EU-DPP level where SyncForce deliberately supports two alternatives.

Option 1: Product Model + Serial Number

The first approach uses:

Product Model ID + Serial Number

For example:

Product Model:

VTA-MPLA-PM-346UJI3NUM

Serial Number:

000012345

For the EU-DPP Data Identifier route:

  • 25P identifies the Product Model
  • S identifies the Serial Number

The URL becomes:

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

The Serial Number is interpreted within the Product Model context.

Conceptually:

25P Product Model

S Serial Number

=

individual physical Product

Can Batch and Serial Number be combined?

Yes.

Where both Batch and Serial Number are relevant, all qualifiers remain within the same Data Identifier system.

For example:

https://prodigi.link/?.25P=VTA-MPLA-PM-346UJI3NUM&.1T=LOT-2028-00425&.S=000012345

This identifies:

  • Product Model
  • Batch
  • individual Serialized Item

without switching identifier systems.

Option 2: globally unique Serialized Item

SyncForce can alternatively create a globally unique identity for the individual physical Product.

This uses:

25S + VTA Serialized Item ID

For example:

VTA-MPLA-SN-7F4K9X2Q

represented as:

https://prodigi.link/?.25S=VTA-MPLA-SN-7F4K9X2Q

Here the VTA-SN uniquely identifies the Serialized Item on its own.

The Product Model relationship still exists in SyncForce, but the Product Model ID is not required to make the Serialized Item identifier globally unique.

When would the two Serialized Item approaches be used?

The two options support different manufacturing practices.

Contextual serialisation

Use:

Product Model + Serial Number

when the manufacturer already manages Serial Numbers within a Product Model context.

For example:

PM-346UJI3NUM + 000012345

Globally unique serialisation

Use:

25S + VTA-SN

when every individual physical Product should receive a globally unique persistent identity independent from the Product Model identifier.

Both approaches can be supported while maintaining the relationship between Serialized Item and Product Model in SyncForce.

What does the complete EU-DPP identity model look like?

EU-DPP level Business identity prodigi.link representation
Product Model 25P + VTA-PM ?.25P={VTA-PM}
Batch Product Model + Lot/Batch ?.25P={VTA-PM}&.1T={lot}
Serialized Item, contextual Product Model + Serial Number ?.25P={VTA-PM}&.S={serial}
Batch + Serialized Item Product Model + Batch + Serial ?.25P={VTA-PM}&.1T={lot}&.S={serial}
Serialized Item, global 25S + VTA-SN ?.25S={VTA-SN}

Why does SyncForce not use GS1 Application Identifiers in these URLs?

Because the VTA-based EU-DPP route uses the Data Identifier scheme.

The identifier should remain within that scheme.

For example, SyncForce does not create:

/25P/{ProductModel}/10/{lot}

because:

  • 25P is a Data Identifier
  • 10 is a GS1 Application Identifier

That mixes two identification systems.

Instead, the Data Identifier route uses:

25P

with:

1T

for the Batch.

So the correct EU-DPP representation is:

?.25P={VTA-PM}&.1T={lot}

The same principle applies to Serial Number and other qualifiers.

How is this different from the Sales Unit route?

The Sales Unit uses GS1 Digital Link.

For example:

https://prodigi.link/01/{GTIN}

A Batch can then be expressed using normal GS1 syntax:

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

A CPV can be expressed as:

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

The important distinction is:

EU-DPP Product identity

Data Identifier route:

25P, 1T, S, 25S

Sales Unit identity

GS1 route:

01, 10, 17, 21, 22

SyncForce supports both systems but does not mix them within one identifier.

Is the URL itself the EU-DPP?

No.

The URL identifies the Product Model, Batch or Serialized Item and allows prodigi.link to resolve that identity.

The EU-DPP is the regulated digital information associated with that identity.

The flow is:

Physical Product

↓

QR or other Data Carrier

↓

Product identifier

↓

prodigi.link

↓

EU-DPP

The identifier and the EU-DPP are therefore connected, but they are not the same thing.

Does the EU-DPP itself also have an identifier?

Yes.

The Product identifier and the EU-DPP identifier are separate.

Three different identifiers are involved:

Identifier Identifies
Unique Product Identifier Product Model, Batch or Serialized Item
EU-DPP ID The passport itself
Registration ID The entry in the EU DPP registry

SyncForce uses a UUID for the EU-DPP ID.

For example:

urn:uuid:3f2b8c1e-6a4d-4e2b-9c7a-1d5e8f0a2b34

The EU-DPP ID remains the same across versions of that EU-DPP.

The EU DPP registry subsequently returns its own Registration ID.

Read more: Which identifiers are used in an EU-DPP?

How does prodigi.link fit into this?

prodigi.link provides the persistent resolution layer.

For example:

Product Model

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

Batch

https://prodigi.link/?.25P=VTA-MPLA-PM-346UJI3NUM&.1T=LOT-2028-00425

Serialized Item

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

Globally unique Serialized Item

https://prodigi.link/?.25S=VTA-MPLA-SN-7F4K9X2Q

The persistent identifier can remain unchanged even when the digital resources associated with it change over time.

What is the SyncForce principle behind this model?

The SyncForce Golden Hierarchy separates:

Product identity

commercial identity

Packaging identity

and:

EU-DPP identity

while maintaining the relationships between them.

The EU-DPP therefore follows the regulated Product at the required Product Model, Batch or Serialized Item level rather than automatically inheriting the identity of the Sales Unit.

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

In one sentence

SyncForce identifies the EU-DPP subject at Product Model, Batch or Serialized Item level using one consistent standards-based identification scheme, while keeping that Product identity separate from the GTIN-based commercial Sales Unit.