==Version 2 (Proposed)==
[[DataContainer - Item|Part of DataContainer: Item]] and, from version 2.0, reusable across other containers (see [[DataContainers and DataTopics - DS]]).

'''Measurements''' covers Trade Item measurements (the smallest rectangular box fitting around the item, plus gross weight), Product measurements (net weight, content, drained weight and product states such as out of pack or in use), and Packaging measurements (shape aware dimensions, packaging weight, nominal capacity and material thickness). The information model is described on [[Measurements - IM]].

From version 2.0 the topic is included per container and selected by a '''Profile''', so the same schema is reused on a Sales Unit, a Packaging Assembly Unit, an Element, a Material or a Composite Material. See the [[#Changes from version 1.1|migration notes]] below before upgrading.

== Structure ==

The topic is a set of optional '''blocks'''. A Profile states which blocks apply for a given container.

{| class="wikitable"
! Block !! Contents
|-
| BaseUnitOfMeasure || Base unit for the block (IMDE Unit of Measure code list)
|-
| Outershape || Packaging shape that drives the dimension fields (Box, Cylinder, Sheet / Film / Band, Cord, Sphere)
|-
| Dimensions || Length, Width, Height, Depth, Diameter
|-
| Weights || GrossWeight, NetWeight, TareWeight, DrainedWeight, PackagingWeight
|-
| NettoContents || One or more NettoContent values
|-
| Capacity || NominalCapacity (Rigid Containers family only)
|-
| Thickness || Nominal, Minimum, Maximum (material and composite layer)
|-
| AlternativeMeasurements || Product states, each tagged with a Product Measurement Type
|}

== Profiles ==

{| class="wikitable"
! Profile !! Container Type !! Blocks
|-
| TradeItem || Item (Sales, Grouped, Transport Unit) || Dimensions, Weights (gross)
|-
| Product || Item (Product) || Weights (net, drained), NettoContents, AlternativeMeasurements
|-
| Packaging || Packaging Assembly Unit, Packaging Element || Outershape, Dimensions, Weights (packaging), Capacity
|-
| MaterialThickness || Packaging Material, Composite Material || Thickness
|}

The XSD validates structure; the Schematron profile rules enforce which blocks each Profile requires or forbids.

== Sample XML ==

A single Packaging Assembly Unit (a bottle from a supplier), reusing the topic at object level (Packaging) and material level (MaterialThickness).

<syntaxhighlight lang="xml">
<PackagingAssemblyUnit Type="PackagingAssemblyUnit" GTIN="08712345555014"
PackagingTypeFamily="RIGID_CONTAINER"
xmlns="https://imde.io/schema/azlon/2.0/item"
xmlns:m="https://imde.io/schema/azlon/2.0/measurements">
<m:Measurements Profile="Packaging">
<m:BaseUnitOfMeasure Type="IMDE">MMT</m:BaseUnitOfMeasure>
<m:Outershape>Cylinder</m:Outershape>
<m:Dimensions>
<m:Diameter Value="65"><m:Units><m:Unit Type="DataReceiver">Mm</m:Unit></m:Units></m:Diameter>
<m:Height Value="223"><m:Units><m:Unit Type="DataReceiver">Mm</m:Unit></m:Units></m:Height>
</m:Dimensions>
<m:Weights>
<m:PackagingWeight Value="22"><m:Units><m:Unit Type="DataReceiver">Gr</m:Unit></m:Units></m:PackagingWeight>
</m:Weights>
<m:Capacity>
<m:NominalCapacity Value="500"><m:Units><m:Unit Type="DataReceiver">Ml</m:Unit></m:Units></m:NominalCapacity>
</m:Capacity>
</m:Measurements>
<PackagingElement>
<PackagingMaterial MaterialType="rPET">
<m:Measurements Profile="MaterialThickness">
<m:Thickness>
<m:Nominal Value="0.30"><m:Units><m:Unit Type="DataReceiver">Mm</m:Unit></m:Units></m:Nominal>
</m:Thickness>
</m:Measurements>
</PackagingMaterial>
</PackagingElement>
</PackagingAssemblyUnit>
</syntaxhighlight>

A second sample (a television in a box) shows the topic reused across nested containers: Sales Unit, Product, and three Packaging Assembly Units down to composite material layers.

== Downloads ==

* Measurements topic XSD, version 2.0: https://imde.io/schema/azlon/2.0/measurements.xsd
* Container XSD, version 2.0: https://imde.io/schema/azlon/2.0/item.xsd
* Profile rules (Schematron): https://imde.io/schema/azlon/2.0/measurements-profiles.sch
* Sample XML, bottle Packaging Assembly Unit, version 2.0
* Sample XML, television in a box, version 2.0
* Code lists: IMDE_UnitofMeasureCode, ProductMeasurementType, ShapeType, ContainerType, PackagingTypeFamily

Old versions:

* XSD version 1.1: https://imde.io/schema/azlon/1.1/measurements.xsd
* XSD version 1.0: https://imde.io/schema/azlon/1.0/measurements.xsd

== Changes from version 1.1 ==

Version 1.1 is live. Version 2.0 keeps all version 1.1 content valid but introduces a new namespace, so every consumer must update the schema reference. Please plan the change with your trading partners.

=== Namespace and schema location ===

{| class="wikitable"
! !! Version 1.1 !! Version 2.0
|-
| Topic namespace || https://imde.io/schema/azlon/1.1/measurements || https://imde.io/schema/azlon/2.0/measurements
|-
| Container schema || (Measurements included in Item) || https://imde.io/schema/azlon/2.0/item
|}

=== What is new (additive, non breaking) ===

* The topic is reused across containers (Item, Packaging Assembly Unit, Packaging Element, Packaging Material, Composite Material), not only Item.
* New '''Profile''' attribute on Measurements: TradeItem, Product, Packaging, MaterialThickness. Profile is optional; if it is absent, treat the block as a legacy flat Measurements (Trade Item plus Product).
* New '''Outershape''' element for packaging.
* New blocks: '''Capacity''' (NominalCapacity), '''Thickness''' (Nominal, Minimum, Maximum) and '''AlternativeMeasurements''' (each tagged with a Product Measurement Type).
* New '''Weights''' members: NetWeight, TareWeight, PackagingWeight. GrossWeight and DrainedWeight are unchanged.
* New '''Dimensions''' members: Length and Diameter. Height, Width and Depth are unchanged.

=== Naming and deprecation ===

* Version 1.1 '''NettoWeight''' is retained as a deprecated alias of '''NetWeight'''. Senders should move to NetWeight; receivers should accept both during the transition.
* NettoContents and NettoContent are unchanged.

=== Element mapping ===

{| class="wikitable"
! Version 1.1 !! Version 2.0 !! Note
|-
| NettoWeight || NetWeight || NettoWeight kept as a deprecated alias
|-
| Dimensions: Depth, Height, Width || same || unchanged
|-
| GrossWeight, DrainedWeight || same || unchanged
|-
| NettoContents, NettoContent || same || unchanged
|-
| (none) || Outershape, Capacity, Thickness, AlternativeMeasurements || new blocks
|-
| (none) || NetWeight, TareWeight, PackagingWeight, Length, Diameter || new members
|-
| Measurements under Item only || Measurements under any container, with Profile || new reuse model
|}

=== Action for the ecosystem ===

* Point messages and validators at the version 2.0 namespace and XSD. A version 1.1 message converts by changing the namespace and, where used, renaming NettoWeight to NetWeight.
* Version 1.1 endpoints remain available during the transition period. New blocks and measurements at packaging, material or composite level require version 2.0.
* Weight identity to be aware of: GrossWeight (Trade Item) = NetWeight (Product) + TareWeight, where TareWeight is the sum of PackagingWeight across the packaging.

[[Category:Data Schema]]

==Version 1 (Current version)==
[[DataContainer_-_Item|Part of DataContainer: Item]]

Measurements covers both trade item measurements (defined as the smallest rectangular fitting around an item) and additional product measurements related to the product out of pack, installed or in use.

BaseUnitOfMeasure is added in version 1.1.

<pre>
<Measurements xmlns="https://imde.io/schema/azlon/1.1/measurements" xsi:schemaLocation="https://imde.io/schema/azlon/1.1/measurements https://imde.io/schema/azlon/1.1/measurements.xsd">

<BaseUnitOfMeasure Type="IMDE">MMT</BaseUnitOfMeasure>
<Dimensions>
<Depth Value="105.8">
<Units>
<Unit Type="DataReceiver">Mm</Unit>
</Units>
</Depth>
<Depth Value="105.8">
<Units>
<Unit Type="DataReceiver">Mm</Unit>
</Units>
</Depth>
<Height Value="108.7">
<Units>
<Unit Type="DataReceiver">Mm</Unit>
</Units>
</Height>
<Width Value="105.8">
<Units>
<Unit Type="DataReceiver">Mm</Unit>
</Units>
</Width>
</Dimensions>
<Weights>
<GrossWeight Value="665.3">
<Units>
<Unit Type="DataReceiver">Gr</Unit>
</Units>
</GrossWeight>
<NettoWeight Value="650">
<Units>
<Unit Type="DataReceiver">Gr</Unit>
</Units>
</NettoWeight>
<DrainedWeight Value="645">
<Units>
<Unit Type="DataReceiver">Gr</Unit>
</Units>
</DrainedWeight>
</Weights>
<NettoContents>
<NettoContent Value="6">
<Units>
<Unit Type="DataReceiver">Pce</Unit>
</Units>
</NettoContent>
<NettoContent Value="1550">
<Units>
<Unit Type="DataReceiver">Ml</Unit>
</Units>
</NettoContent>
</NettoContents>
</Measurements>
</pre>

===Downloads===
* [https://imde.io/schema/Sample%20XML%20message%20DataTopic%20Measurements.xml Sample XML] version 1.1
* [https://imde.io/schema/azlon/1.1/measurements.xsd XSD] version 1.1
* [https://imde.io/schema/codelists/IMDE_UnitofMeasureCode.xml Codelist IMDE_UnitofMeasureCode]
* [https://imde.io/schema/azlon/1.0/codelists/unitType.xsd Codelist unitType]

Old versions:
* [https://imde.io/schema/azlon/1.0/measurements.xsd XSD] version 1.0

Category:Data Schema

2026-06-21T10:23:31Z

HansdG: Created blank page

DataContainers and DataTopics - DS

2026-06-21T10:22:48Z

HansdG: Created page with "This page explains the key structure of IMDE data schemas: how reusable '''DataTopics''' are included into '''DataContainers''' and constrained by '''Profiles''', so that the same schema can be reused at every level of the trade and packaging hierarchy and across the supply chain. The Measurements topic is used as the worked example throughout. == Key concepts == {| class="wikitable" ! Term !! Meaning !! Status |- | DataContainer || The entity or..."

This page explains the key structure of IMDE data schemas: how reusable '''DataTopics''' are included into '''DataContainers''' and constrained by '''Profiles''', so that the same schema can be reused at every level of the trade and packaging hierarchy and across the supply chain. The [[Measurements - IM|Measurements]] topic is used as the worked example throughout.

== Key concepts ==

{| class="wikitable"
! Term !! Meaning !! Status
|-
| DataContainer || The entity or host that includes DataTopics and carries identity and role. || exists (extend)
|-
| Container Type || What the container is: Item (Trade Item / Product), Packaging Assembly Unit, Packaging Element, Packaging Material, Composite Material, Party, Person. || new code list
|-
| DataTopic Measurements || The single reusable measurement topic, included per container. || exists (extend)
|-
| Measurement Block || The includable parts inside the topic: Dimensions, Weights, Contents, Capacity, Thickness, AlternativeMeasurements. || partly exists
|-
| Measurement (atomic type) || A value plus a unit, reused everywhere. || exists
|-
| Profile || The rule set saying which blocks are valid or required for a given Container Type and supply chain position. || new
|-
| Object level vs component level || Measurement on the container itself versus on its child containers. || terminology
|}

== DataContainer ==

A '''DataContainer''' is the entity or host that includes one or more DataTopics. It carries identity, such as a GTIN, and a role. A DataContainer can contain child DataContainers, which forms both the trade item hierarchy (for example a case that contains bottles) and the packaging decomposition (a Packaging Assembly Unit that contains Packaging Elements, Materials and Composite Materials).

The '''Container Type''' states what the container is. It is a new code list (CONTAINER_TYPE).

{| class="wikitable"
! Container Type !! Typical role
|-
| Item || Trade Item (Sales, Grouped or Transport Unit) or Product
|-
| Packaging Assembly Unit || A physical packaging component or SKU item in a Bill of Materials
|-
| Packaging Element || Lowest functional packaging part
|-
| Packaging Material || One or more materials that make up an element
|-
| Composite Material || An individual layer within a composite material
|-
| Party || An organisation (uncommon for measurements, supported for reuse)
|-
| Person || An individual (uncommon for measurements, supported for reuse)
|}

A single physical object can appear as more than one container depending on its role in the supply chain. An empty bottle is a Packaging Assembly Unit inside a filled product, and at the same time a Trade Item when the bottle supplier sells it. It is one object that is described by two container roles, reusing the same topic.

== DataTopic ==

A '''DataTopic''' is a modular, reusable block of structure that is modelled once and expressed across the IMDE layers. A topic is included per container. Depending on the position in the supply chain, topics are included or excluded, and the same topic can be reused across different Container Types. Measurements is one DataTopic; other topics (for example composition or compliance) are included alongside it on the same container.

== Measurement Block ==

Within a topic, '''blocks''' are the includable parts. For Measurements the blocks are Dimensions, Weights, Contents, Capacity, Thickness and AlternativeMeasurements. All blocks are optional in the base schema. A Profile decides which blocks apply for a given container.

== Measurement (atomic type) ==

The atomic '''Measurement''' is a value plus a unit of measure, drawn from the Unit of Measure code list. Every block reuses this one type, which keeps Trade Item, Product, Packaging and Material Thickness measurements consistent and makes schema generation in XLS, XML and JSON straightforward.

== Profile ==

A '''Profile''' is the rule set that says which blocks are valid or required for a given Container Type and supply chain position. The base schema stays permissive so one schema validates everywhere; the Profile enforces what is allowed and required.

{| class="wikitable"
! Profile !! Container Type !! Blocks typically populated
|-
| TradeItem || Item (Sales / Grouped / Transport Unit) || Dimensions, Weights (gross)
|-
| Product || Item (Product) || Weights (net, drained), Contents, AlternativeMeasurements
|-
| Packaging || Packaging Assembly Unit, Packaging Element || Dimensions (shape aware), Weights (packaging), Capacity
|-
| MaterialThickness || Packaging Material, Composite Material || Thickness
|}

== Object level and component level ==

'''Object level''' is a measurement on the container itself. '''Component level''' is a measurement on its child containers. A Packaging Assembly Unit carries object level packaging measurements (shape, dimensions, packaging weight, and capacity for rigid containers), and component level measurements on its Packaging Elements, Packaging Materials and Composite Materials, where material thickness lives.

== Reuse across the supply chain ==

Because topics are included or excluded per container, the position in the supply chain decides what travels in a message. The structure does not change; only the included topics and populated blocks change.

{| class="wikitable"
! Position !! Container in focus !! Measurements included
|-
| Primary material or converter || Packaging Material, Composite Material || MaterialThickness; packaging weight
|-
| Component supplier (SIM intake) || Packaging Assembly Unit || Packaging at object level plus the decomposition to material thickness
|-
| Brand owner (PIM) || Sales, Grouped and Transport Units || Trade Item and Product; Packaging via the Bill of Materials
|-
| Retailer (PPWR manufacturer, EPR producer) || Sales Unit || Trade Item and Product
|}

== Examples ==

The two examples below reuse the same Measurements topic. Namespaces are illustrative.

=== Television in a box (nested containers) ===

One Sales Unit (Item) holds the Trade Item measurements, a Product (the television) in the Bill of Materials, and a Packaging Unit with three Packaging Assembly Units. The outer box is decomposed down to composite material layers.

<syntaxhighlight lang="xml">
<Item Type="Item" Role="TradeItem" GTIN="08712345000018">
<m:Measurements Profile="TradeItem"></m:Measurements>
<BillOfMaterials>
<Product Type="Item" Role="Product" GTIN="08712345111016">
<m:Measurements Profile="Product">


</m:Measurements>
</Product>
<PackagingUnit>
<PackagingAssemblyUnit PackagingTypeFamily="RIGID_BOX">
<m:Measurements Profile="Packaging"></m:Measurements>
<PackagingElement>
<PackagingMaterial MaterialType="CorrugatedBoard" Composite="true">
<m:Measurements Profile="MaterialThickness"></m:Measurements>
<CompositeMaterial Layer="OuterLiner">
<m:Measurements Profile="MaterialThickness"></m:Measurements>
</CompositeMaterial>

</PackagingMaterial>
</PackagingElement>
</PackagingAssemblyUnit>
<PackagingAssemblyUnit PackagingTypeFamily="MOULDED_FIBRE"></PackagingAssemblyUnit>
<PackagingAssemblyUnit PackagingTypeFamily="FLEXIBLE"></PackagingAssemblyUnit>
</PackagingUnit>
</BillOfMaterials>
</Item>
</syntaxhighlight>

=== Bottle as a standalone Packaging Assembly Unit ===

The same topic, on a different root container, as received from a bottle supplier. No Sales Unit and no Bill of Materials. A bottle is a Rigid Containers family, so the object level carries Nominal Capacity.

<syntaxhighlight lang="xml">
<PackagingAssemblyUnit Type="PackagingAssemblyUnit" GTIN="08712345555014"
PackagingTypeFamily="RIGID_CONTAINER">
<m:Measurements Profile="Packaging">
<m:Outershape>Cylinder</m:Outershape>
<m:Dimensions>
<m:Diameter Value="65"><m:Units><m:Unit Type="DataReceiver">Mm</m:Unit></m:Units></m:Diameter>
<m:Height Value="223"><m:Units><m:Unit Type="DataReceiver">Mm</m:Unit></m:Units></m:Height>
</m:Dimensions>
<m:Weights>
<m:PackagingWeight Value="22"><m:Units><m:Unit Type="DataReceiver">Gr</m:Unit></m:Units></m:PackagingWeight>
</m:Weights>
<m:Capacity>
<m:NominalCapacity Value="500"><m:Units><m:Unit Type="DataReceiver">Ml</m:Unit></m:Units></m:NominalCapacity>
</m:Capacity>
</m:Measurements>
<PackagingElement>
<PackagingMaterial MaterialType="rPET">
<m:Measurements Profile="MaterialThickness">
<m:Thickness>
<m:Nominal Value="0.30"><m:Units><m:Unit Type="DataReceiver">Mm</m:Unit></m:Units></m:Nominal>
</m:Thickness>
</m:Measurements>
</PackagingMaterial>
</PackagingElement>
</PackagingAssemblyUnit>
</syntaxhighlight>

The empty bottle, when sold by the supplier, is also a Trade Item, so the same container can include the Measurements topic a second time with the TradeItem profile. This is the reuse principle: one topic, many containers, selected by Profile and by supply chain position.

[[Category:Data Schema]]

Layer - Data Schema

2026-06-21T09:55:45Z

HansdG: /* Data Schema and Data Containers */

== IMDE Data Schemas==
IMDE goal is to support multiple versioned DataSchemas (backwards and forwards compatible) for all data points relevant to manufacture, distribute, commercialize and re-cycle discrete products (e.g. food, beverages, fashion, electronics, power tools, adhesives, pet food, personal care, home care, et cetera).

The IMDE DataSchema layer is implementation agnostic so that the defined DataSchemas can be implemented in DataPools, Data Networks or Digital Catalog standards (like [https://fabdis.fr/ FABDIS] or [https://www.bme.de/ BMECAT]).

==Data Schema and Data Containers==

IMDE supports the exchange of data related to the following entities via so called DataContainers. A data container contains a message or file related to one or more entities of the same type.

* '''[[DataContainer_-_Item|Item/Object]]''': Use to exchange data related to physical items. Items can be transported by car, truck, plane or boat. There are multiple types of items:
** ''Handling unit'' (e.g. a physical package or container that is used to transport, store or handle goods. It could be a pallet, a box, a crate or a bundle, and it is often used to group items together to facilitate handling, storage and transport. A cases, cartons, display)
** ''Finished goods'' (e.g. TV, mobile phone, bottle of shampoo, ready to eat salad, smoothie in plastic bottle)
** Parts/Components
*** ''Semi-finished good / Sub-assemblies'' (e.g. bottled beer without labels, frozen fries not yet packaged), usually produced by the brandowner/product manufacturer).
*** ''Components'' (e.g packaging components like foil & cans and food components like herb-mixes or electronic components)
*** ''Raw material'' (e.g. eggs, raw milk, salt, oil, tree trunk, grain, iron)
* '''[[DataContainer_-_Bill_of_materials|Bill of materials]]''': Hierarchies of physical items, for example full trade hierarchy (Pallet, case, finished good) or manufacturing BOMs (Finished Good, Components/Parts, Raw Materials)
* '''[[Trade_hierarchies|Trade hierarchies]]''': In the IMDE format, trade hierarchies are modelled as part of the Bill of materials
* '''Party/Legal Entity''': Organizations and corporations like Manufacturers, Retailers, NGOs and government bodies. Easy check: Legal entities can be sued in court
* '''Location''': Any place on earth where activities take place, like farms, forests, production facilities, distribution centers and retail stores). Easy check: Locations can be found on Google Maps.
* '''Brand''': Covers both product and organizational brands.
* '''Person''': Individuals/humans like employees and consumers)
* '''[[Transactions]]''': Production Runs, Orders, Shipments
*

Every entity will have a defined '''DataContainer''' within IMDE framework to exchange data related to this entity (e.g. product information for materials). Every DataContainer will have a header which includes an [[Layer_-_Identifiers|identifier]] which will enable machines to process the data in a fully automatic way.

===One or more Data Topics per container===
The core principles of the IMDE framework are interoperable and modular. That also applies to data schemas (data message formats and spreadsheet templates). Within the IMDE framework industry groups will work on defining DataTopics. A DataTopic will contain all datapoints covering a specific topic. Examples are: Packaging Materials, Allergens, Marks or Claims. Any data message or template can contain one or more DataTopics, depending on the needs in that part of the supply chain. For example
* A Packaging Component Supplier will include the Packaging Material Datatopic in a data message that is send to a CPG brand owner.
* A Herb Mix Supplier will include all Food recipe related DataTopics like Allergens, Ingredients and Nutrients
* A Adhesive supplier will include all Formula related DataTopics like Reach
* A CPG/FMCG in Food will data related to the "consumer product" which will Food and Packaging related DataTopics in the data message that is sent to heir business partners (retailers, wholesales, logistic service providers)

This covers the modular part, the framework becomes interoperable by allowing multiple schemas per DataTopic, with defined transformations between the schemas. This allows every party (both data senders and receivers) to work in the schema they prefer (no longer deliver multiple formats to all different data receivers).

The IMDE framework will support multiple DataSchemas per '''DataTopic''' (e.g allergens) and related data points, making sure all industries and all territories can join IMDE. IMDE will also support multiple DataSchemas per Data topic. Example: allergen exchange Excel template and Allergen Exchange XSD/XML. IMDE will also support existing information & taxonomy standards, like for example:
* [https://www.etim-international.com/ ETIM], the international classification standard for technical products
* [https://www.fao.org/ FAO] for Fish farming and Fishery related information standards
* [https://www.iso.org/ ISO] (e.g. for languages, countries and units)

[[Category:Layers]]

Measurements - IM

2026-06-21T09:49:56Z

HansdG:

The '''Measurements''' information model defines the technology neutral structure for describing the physical size and quantity of trade items, products and packaging. It has three subsections: '''Trade Item Measurements''' and '''Product Measurements''', aligned with the GS1 Package and Product Measurement Standard, and '''Packaging Measurements''', captured per Packaging Element using a shape aware model. [[Material Thickness - TX|Material Thickness]] is held separately at material level.

This page describes the Information Model only. The Unit of Measure, Shape Type and Product Measurement Type code lists (L4), and the data schemas in XLS, XML and JSON (L5), are described on their own pages. Minimum Critical Dimension and recyclability roll up logic are out of scope here.

== Scope ==

The Measurements Data Topic separates three subjects that are often confused:

* '''Trade Item Measurements''' describe the trade item as placed on the market or moved through logistics: its outer dimensions and its gross weight. For Sales Units, Grouped Units and Transport Units.
* '''Product Measurements''' describe the goods themselves: net weight, net content, drained weight, and optional alternative measurements such as dimensions in use or with and without a stand. For the product inside a Sales Unit.
* '''Packaging Measurements''' describe the physical packaging: element outer dimensions, packaging weight and material thickness. For Packaging Elements.

The three subsections meet in one weight identity: '''gross weight = net weight + tare weight''', where tare weight is the weight of the packaging. Packaging is described using Sales Packaging, Grouped Packaging and Transport Packaging.

== Where measurements attach ==

'''Trade Item Measurements''' attach to the Sales Unit, the Grouped Unit and the Transport Unit, which are the levels carried in GS1 and GDSN. '''Product Measurements''' attach to the product inside a Sales Unit, because a Sales Unit = Product + Packaging. '''Packaging Measurements''' attach to the Packaging Element for outer dimensions and packaging weight, and to the material for thickness.

{| class="wikitable"
! Level !! Meaning !! Measurement attached
|-
| Sales / Grouped / Transport Unit || The trade item as placed on the market or moved through logistics. || Trade Item Measurements; Product Measurements (Sales Unit)
|-
| Packaging Unit || Complete physical packaging defined by the Bill of Materials for one unit. || Roll up of packaging weight to tare weight
|-
| Packaging Assembly Unit || A physical packaging component or SKU item in the BOM. || Roll up of element measurements (optional)
|-
| Packaging Element || Lowest functional packaging part, separate or integrated. || Packaging Measurements: outer dimensions, packaging weight
|-
| Packaging Material || One or more materials that make up a Packaging Element. || Material thickness (total); packaging weight
|-
| Composite Material || Individual layers within a composite material. || Layer thickness
|}

=== The weight identity ===

'''Gross weight = net weight + tare weight.''' Gross weight is the total weight of the trade item including its packaging, and is a Trade Item Measurement. Net weight is the weight of the product contents excluding packaging, and is a Product Measurement. Tare weight is the weight of the empty packaging; it equals the sum of the packaging weights of all Packaging Elements and materials in the Packaging Unit, and is therefore derived from Packaging Measurements. Tare is the official term for packaging weight, so gross weight minus net weight equals tare weight.

== Trade Item Measurements ==

Trade Item Measurements follow the GS1 Package and Product Measurement Standard and the GDSN trade item measurements module. They describe the trade item as placed on the market or moved through logistics: its outer dimensions and its gross weight. Net weight, net content and drained weight describe the product, not the trade item.

=== Default front and the measurement process ===

Before height, width and depth can be determined, the default front of the consumer trade item must be identified. The default front is the surface with the largest area used by the brand owner to promote the product to the consumer. Where GS1 defines a specific rule for the product or packaging type, that rule is used. Where no clear promotional surface exists, the largest surface is treated as the default front.

Measurements are taken while facing the default front, with the trade item resting naturally on a flat surface. The maximum distance is always measured, including projections, caps, lids and any attached complementary products such as on packs or samples.

{| class="wikitable"
! Dimension !! GS1 definition
|-
| Height || Distance from the bottom most point to the top most point, measured facing the default front.
|-
| Width || Distance from the left most point to the right most point, measured facing the default front.
|-
| Depth || Distance from the default front to the farthest opposite surface (front to back).
|}

=== Alternative dimensions for round and irregular items ===

GS1 always derives height, width and depth from the bounding box around the trade item. For a round or cylindrical item the width and depth equal the sides of the rectangle drawn around the circle, so for a perfect cylinder width equals depth equals the diameter. To capture this explicitly, the model supports an alternative attribute, diameter, which records the widest circular cross section.

=== Trade Item Measurement attributes ===

{| class="wikitable"
! Attribute !! Definition !! Type / unit !! Card. !! GDSN mapping
|-
| height || Vertical outer dimension facing the default front. || Measurement, length || 0..1 || tradeItemMeasurements/height
|-
| width || Horizontal outer dimension facing the default front. || Measurement, length || 0..1 || tradeItemMeasurements/width
|-
| depth || Front to back outer dimension facing the default front. || Measurement, length || 0..1 || tradeItemMeasurements/depth
|-
| diameter || Widest circular cross section for round or cylindrical items. || Measurement, length || 0..1 || tradeItemMeasurements/diameter
|-
| grossWeight || Total weight of the trade item including packaging. || Measurement, mass || 0..1 || tradeItemMeasurements/grossWeight
|}

'''Applies to:''' Sales Unit, Grouped Unit and Transport Unit.

== Product Measurements ==

Product Measurements describe the goods themselves, independent of the packaging. They cover the declared content and weight of the product, and a code list driven set of alternative measurements for products that are measured in more than one state. Product Measurements attach to the product inside a Sales Unit.

=== Core product measurements ===

{| class="wikitable"
! Attribute !! Definition !! Type / unit !! Card. !! GDSN mapping
|-
| netWeight || Weight of the product contents excluding packaging. || Measurement, mass || 0..1 || tradeItemMeasurements/netWeight
|-
| netContent || Declared content of the consumer unit, including liquid where applicable. || Measurement, volume or mass or count || 0..n || netContent
|-
| drainedWeight || Weight of solid content excluding packing liquid, for items packed in brine, syrup or oil. || Measurement, mass || 0..1 || drainedWeight
|}

Net weight is the product side of gross weight = net weight + tare weight.

=== Alternative product measurements ===

A product can be measured in more than one state. Each alternative measurement is tagged with a Product Measurement Type from an L4 code list, and can carry its own dimensions and weight under that state. The set is optional and unbounded (0..N), so a user adds one or more alternative measurements only where they are relevant. The Product Measurement Type code list is seeded with the following values and is extensible.

{| class="wikitable"
! Code !! Measurement type !! Typical use
|-
| AS_STORED || As stored (dry) || Dry, concentrated or as stored product, for example dry pasta, powder or concentrate.
|-
| IN_USE || Prepared / in use || Product as prepared, reconstituted or in use, for example cooked or made up volume.
|-
| WITH_STAND || With stand || Display product measured with the stand fitted, for example a television.
|-
| WITHOUT_STAND || Without stand || Same product with the stand removed.
|-
| ASSEMBLED || Assembled || Product measured fully assembled.
|-
| FOLDED || Folded / collapsed || Product measured folded, collapsed or flat packed.
|}

{| class="wikitable"
! Attribute !! Definition !! Type / unit !! Card.
|-
| measurementTypeCode || Reference to the Product Measurement Type for this alternative measurement. || Code (Product Measurement Type list) || 1..1
|-
| height, width, depth, diameter || Dimensions of the product in this state. || Measurement, length || 0..1 each
|-
| weight || Weight of the product in this state. || Measurement, mass || 0..1
|-
| netContent || Content of the product in this state, for example prepared volume. || Measurement, volume or mass or count || 0..1
|}

== Packaging Measurements ==

Packaging Measurements describe the physical packaging itself: the outer dimensions of each Packaging Element, its packaging weight, and its material thickness. The input is context aware: the user first selects or inherits an Outershape, and the shape then determines which dimension fields are shown and which units apply by default. Thickness is not part of the shape; it is held on the material.

=== The Outershape concept ===

Every Packaging Element has one Outershape, for example Box, Cylinder or Sheet / Film / Band. The Outershape is usually derived automatically from the selected Packaging Element Type (a bottle resolves to Cylinder, a tray resolves to Box) and is user overridable. The shape controls which of the four dimension fields are presented and the default unit of each field. A Packaging Element cannot record dimensions until its Outershape is set.

=== Dimension field codes ===

{| class="wikitable"
! Code !! Field !! Notes
|-
| L || Length || Longest planar dimension.
|-
| W || Width || Second planar dimension.
|-
| H || Height || Vertical dimension.
|-
| D || Diameter || Widest circular cross section.
|}

Thickness is deliberately not a dimension field. It is a property of the material and is modelled at material level.

=== Shape registry ===

The shape registry is stored once as reference data (an L4 code list). Because thickness is held on the material, the Sheet / Film / Band shape covers all flat forms, from broad sheets and films to narrow bands and straps, which are geometrically identical to a sheet.

{| class="wikitable"
! Shape !! Dimension fields !! Typical packaging examples
|-
| Box || L, W, H || Carton, tray, case, folding box, rigid box
|-
| Cylinder || D, H || Bottle, can, jar, tube, cup, cap
|-
| Sheet / Film / Band || L, W || Label, film, foil, laminate web, lidding, liner, layer pad, sleeve, tape, band, tear strip, pallet strap
|-
| Cord || D, L || Tie, string, drawstring, handle cord
|-
| Sphere || D || Ball, bead, spherical closure
|}

=== Units and defaults ===

Each dimension field carries its own unit of measure. Allowed length units are m, dm, cm and mm. Allowed capacity units are l, dl, cl and ml. Packaging weight uses mass units such as g and kg. The default unit is mm for all dimension fields. Thickness is handled separately at material level, with um (micrometre) available for thin films and foils.

=== Nominal capacity and Packaging Type Family ===

Nominal capacity is the declared filling volume of a packaging element that holds a product. It is part of Packaging Measurements but applies only to Packaging Elements whose Packaging Type Family is Rigid Containers, for example cans, bottles, jars and cups. For all other families it is not recorded. Nominal capacity is measured in millilitres (ml) by default. The Packaging Type Family is taken from the IMDE Packaging Type Family code list (PACKAGING_TYPE_FAMILY) and is inherited from the Packaging Element Type.

{| class="wikitable"
! Packaging Type Family !! Nominal capacity
|-
| Rigid Containers (cans, bottles, jars, cups) || Yes, default ml
|-
| All other families || Not recorded
|}

=== Packaging Measurement attributes ===

Dimensions are stored as two parallel maps on the element: a value per field code and a unit per field code. Only the fields declared by the Outershape are populated. Packaging weight is captured per element and rolls up to the tare weight of the trade item.

{| class="wikitable"
! Attribute !! Definition !! Type / unit !! Card.
|-
| outershapeCode || Reference to the Outershape in the shape registry. || Code (Shape Type list) || 1..1
|-
| dimensionValue[field] || Measured value for a declared dimension field (L, W, H, D). || Decimal || 0..1 per field
|-
| dimensionUnit[field] || Unit of measure for that dimension field. || Code (length subset) || 0..1 per field
|-
| packagingWeight || Weight of this Packaging Element; rolls up to tare weight. || Measurement, mass || 0..1
|-
| nominalCapacity || Declared filling volume; only for the Rigid Containers Packaging Type Family. || Decimal || 0..1
|-
| nominalCapacityUnit || Unit of measure for nominal capacity; default ml. || Code (capacity subset) || 0..1
|}

== Material Thickness ==

Thickness is a property of the material, not of the element outer shape. This follows the [[Material Thickness - TX|Material Thickness]] taxonomy, which separates thickness from outer dimensions such as length, width, height, depth and diameter. Modelling thickness at material level keeps the shape registry purely geometric and matches current GDSN practice, where thickness is reported only for selected materials such as aluminium.

=== Where thickness lives in the hierarchy ===

A Packaging Element consists of one or more Packaging Materials. A Packaging Material can be simple or composite. A composite Packaging Material consists of two or more Composite Materials, which are the individual layers of a laminate or multilayer structure. Thickness therefore has two variants.

{| class="wikitable"
! Level !! Thickness variant !! Meaning
|-
| Packaging Material || Material thickness || Total thickness of the material or the complete material structure.
|-
| Composite Material (layer) || Layer thickness || Thickness of one individual layer within a composite material.
|}

A simple, non composite material carries only material thickness. A composite carries a layer thickness on each Composite Material, plus a material thickness on the Packaging Material that represents the total structure.

=== Total thickness versus the sum of layers ===

For a composite, the material thickness (total) may be measured directly or derived from the sum of the layer thicknesses. Treat the layer thicknesses as the source of truth where layers are modelled. Enter the total directly for a simple material, and for a composite validate the total against the sum of the layers, flagging a mismatch rather than overwriting.

=== The Thickness type ===

Thickness reuses one shared type, applied at both the Packaging Material and Composite Material levels. The nominal value is the primary figure and is the value published for data exchange. Minimum and maximum are optional and used when a tolerance or range is required, mainly for films and foils. The default unit is mm, with um available for thin films and foils.

{| class="wikitable"
! Attribute !! Definition !! Type / unit !! Card.
|-
| nominal || Declared nominal thickness; the value published for data exchange. || Measurement, length (mm or um) || 0..1
|-
| minimum || Lower bound of the thickness range, when a range is specified. || Measurement, length || 0..1
|-
| maximum || Upper bound of the thickness range, when a range is specified. || Measurement, length || 0..1
|}

A separate average attribute is intentionally not introduced. If measured quality control statistics are captured later, model them as a distinct measured value rather than overloading nominal. A single nominal value satisfies the current GDSN requirement for materials such as aluminium today.

== Data model summary ==

{| class="wikitable"
! Entity !! Key attributes !! Attaches to
|-
| TradeItemMeasurement || height, width, depth, diameter, grossWeight (each value plus unit) || Sales Unit, Grouped Unit, Transport Unit
|-
| ProductMeasurement || netWeight, netContent, drainedWeight; alternativeMeasurement[ ] || Product (inside a Sales Unit)
|-
| AlternativeProductMeasurement || measurementTypeCode, height, width, depth, diameter, weight, netContent || ProductMeasurement (0..N)
|-
| PackagingMeasurement || outershapeCode, dimensionValue[ ], dimensionUnit[ ], packagingWeight, nominalCapacity, nominalCapacityUnit || Packaging Element
|-
| MaterialThickness || nominal, minimum, maximum (each value plus unit) || Packaging Material (total) and Composite Material (layer)
|-
| ShapeType (reference) || code, name, dimensionFields[ ] (subset of L, W, H, D), sortOrder || Referenced by PackagingMeasurement
|-
| ProductMeasurementType (reference) || code, name, description || Referenced by AlternativeProductMeasurement
|-
| UnitOfMeasure (reference) || code, name, quantityKind (length, mass, volume, count) || Referenced by all measurement values
|}

'''Reusable Measurement type.''' Every measured quantity is a pair of a decimal value and a unit of measure code. One shared Measurement type keeps all three subsections and Material Thickness consistent. The weight identity gross weight = net weight + tare weight links the three subsections, with tare weight derived as the sum of packaging weight across the Packaging Unit.

[[Category:Information Model]]

Measurements - IM

2026-06-21T09:19:31Z

HansdG: Created page with "The '''Measurements''' information model defines the technology neutral structure for describing the physical size and quantity of trade items and packaging. It has two subsections: '''Trade Item Measurements''', aligned with the GS1 Package and Product Measurement Standard, and '''Packaging Measurements''', captured per Packaging Element using a shape aware model. Material Thickness is held separately at material level. This page describes t..."

The '''Measurements''' information model defines the technology neutral structure for describing the physical size and quantity of trade items and packaging. It has two subsections: '''Trade Item Measurements''', aligned with the GS1 Package and Product Measurement Standard, and '''Packaging Measurements''', captured per Packaging Element using a shape aware model. [[Material Thickness - TX|Material Thickness]] is held separately at material level.

This page describes the Information Model only. The Unit of Measure code list and Shape Type code list (L4), and the data schemas in XLS, XML and JSON (L5), are described on their own pages. Minimum Critical Dimension and recyclability roll up logic are out of scope here.

== Scope ==

The Measurements Data Topic has two subsections in this release:

* '''Trade Item Measurements''' for Sales Units, Grouped Units and Transport Units, using GS1 definitions.
* '''Packaging Measurements''' for Packaging Elements, using a context aware, shape driven model, with Material Thickness held at material level.

Packaging is described using Sales Packaging, Grouped Packaging and Transport Packaging.

== Where measurements attach ==

Measurements attach at distinct points in the packaging hierarchy, and this separation is the backbone of the model.

'''Trade Item Measurements''' describe the trade item as placed on the market or moved through logistics. They attach to the Sales Unit, the Grouped Unit and the Transport Unit, which are the levels carried in GS1 and GDSN.

'''Packaging Measurements''' describe the physical packaging itself. Outer dimensions attach to the Packaging Element, the lowest functional packaging part, while thickness attaches to the material.

{| class="wikitable"
! Level !! Meaning !! Measurement attached
|-
| Packaging Unit || Complete physical packaging defined by the Bill of Materials for one Sales, Grouped or Transport Unit. || Roll up of element measurements (optional)
|-
| Packaging Assembly Unit || A physical packaging component or SKU item in the BOM (jar, lid, label, carton, tray, flowwrap, cap, sleeve, pallet wrap). || Roll up of element measurements (optional)
|-
| Packaging Element || Lowest functional packaging part, separate or integrated. || Packaging Measurements, outer dimensions (primary input level)
|-
| Packaging Material || One or more materials that make up a Packaging Element. || Material thickness (total)
|-
| Composite Material || Individual layers within a composite material. || Layer thickness
|}

Each trade item level (Sales Unit, Grouped Unit, Transport Unit) carries its own Trade Item Measurements. Because a Sales Unit = Product + Packaging, a Sales Unit can also carry Product Measurements, which are a separate subsection of this Data Topic.

== Trade Item Measurements ==

Trade Item Measurements follow the GS1 Package and Product Measurement Standard and the GDSN trade item measurements module. The goal is a global, unambiguous and repeatable definition of the nominal size and quantity of a trade item, whether packed or unpacked.

=== Default front and the measurement process ===

Before height, width and depth can be determined, the default front of the consumer trade item must be identified. The default front is the surface with the largest area used by the brand owner to promote the product to the consumer. Where GS1 defines a specific rule for the product or packaging type, that rule is used. Where no clear promotional surface exists, the largest surface is treated as the default front.

Measurements are taken while facing the default front, with the trade item resting naturally on a flat surface. The maximum distance is always measured, including projections, caps, lids and any attached complementary products such as on packs or samples.

{| class="wikitable"
! Dimension !! GS1 definition
|-
| Height || Distance from the bottom most point to the top most point, measured facing the default front.
|-
| Width || Distance from the left most point to the right most point, measured facing the default front.
|-
| Depth || Distance from the default front to the farthest opposite surface (front to back).
|}

=== Alternative dimensions for round and irregular items ===

GS1 always derives height, width and depth from the bounding box around the trade item. For a round or cylindrical item the width and depth equal the sides of the rectangle drawn around the circle, so for a perfect cylinder width equals depth equals the diameter. To capture this explicitly, the model supports an alternative attribute, diameter, which records the widest circular cross section. Diameter is provided in addition to or instead of width and depth depending on the receiving system and the GS1 rule for the product type.

* Rectangular and box shaped items: use height, width and depth.
* Round, cylindrical or oval items: use height plus diameter, and where required also width and depth as the bounding rectangle.

=== Trade Item Measurement attributes ===

Each linear attribute is a measured value with a unit of measure from the Unit of Measure code list (length subset). Weight and content attributes use the mass and volume subsets. The GDSN mapping gives the GS1 attribute used for data exchange.

{| class="wikitable"
! Attribute !! Definition !! Type / unit !! Card. !! GDSN mapping
|-
| height || Vertical outer dimension facing the default front. || Measurement, length || 0..1 || tradeItemMeasurements/height
|-
| width || Horizontal outer dimension facing the default front. || Measurement, length || 0..1 || tradeItemMeasurements/width
|-
| depth || Front to back outer dimension facing the default front. || Measurement, length || 0..1 || tradeItemMeasurements/depth
|-
| diameter || Widest circular cross section for round or cylindrical items. || Measurement, length || 0..1 || tradeItemMeasurements/diameter
|-
| netContent || Declared content of the consumer unit, including liquid where applicable. || Measurement, volume or mass or count || 0..n || netContent
|-
| netWeight || Weight of the trade item contents excluding packaging. || Measurement, mass || 0..1 || tradeItemMeasurements/netWeight
|-
| grossWeight || Weight including packaging. || Measurement, mass || 0..1 || tradeItemMeasurements/grossWeight
|-
| drainedWeight || Weight of solid content excluding packing liquid, for items packed in brine, syrup or oil. || Measurement, mass || 0..1 || drainedWeight
|}

'''Applies to:''' Sales Unit, Grouped Unit and Transport Unit. The same attribute set is reused at each trade item level; the level is identified by the parent object, not by separate attributes.

== Packaging Measurements ==

Packaging Measurements describe the physical outer dimensions of a single Packaging Element. The input is context aware: the user first selects or inherits an Outershape, and the shape then determines which dimension fields are shown, which units apply by default, and which optional attributes such as nominal capacity are relevant. Thickness is not part of the shape; it is held on the material.

=== The Outershape concept ===

Every Packaging Element has one Outershape, for example Box, Cylinder or Sheet / Film / Band. The Outershape is usually derived automatically from the selected Packaging Element Type (a bottle resolves to Cylinder, a tray resolves to Box) and is user overridable. The shape controls which of the four dimension fields are presented and the default unit of each field. A Packaging Element cannot record dimensions until its Outershape is set.

=== Dimension field codes ===

{| class="wikitable"
! Code !! Field !! Notes
|-
| L || Length || Longest planar dimension.
|-
| W || Width || Second planar dimension.
|-
| H || Height || Vertical dimension.
|-
| D || Diameter || Widest circular cross section.
|}

Thickness is deliberately not a dimension field. It is a property of the material, not of the outer shape, and is modelled at material level.

=== Shape registry ===

The shape registry is stored once as reference data (an L4 code list). Each shape declares the ordered set of dimension fields it requires. Because thickness is held on the material, the Sheet / Film / Band shape covers all flat forms, from broad sheets and films to narrow bands and straps, which are geometrically identical to a sheet.

{| class="wikitable"
! Shape !! Dimension fields !! Typical packaging examples
|-
| Box || L, W, H || Carton, tray, case, folding box, rigid box
|-
| Cylinder || D, H || Bottle, can, jar, tube, cup, cap
|-
| Sheet / Film / Band || L, W || Label, film, foil, laminate web, lidding, liner, layer pad, sleeve, tape, band, tear strip, pallet strap
|-
| Cord || D, L || Tie, string, drawstring, handle cord
|-
| Sphere || D || Ball, bead, spherical closure
|}

=== Units and defaults ===

Each dimension field carries its own unit of measure. Allowed length units are m, dm, cm and mm. Allowed capacity units are l, dl, cl and ml. The default unit is mm for all dimension fields. Thickness is handled separately at material level, with its own unit handling including um (micrometre) for thin films and foils.

{| class="wikitable"
! Field context !! Default unit
|-
| Dimension fields (L, W, H, D), all shapes || mm
|-
| Nominal capacity (container class only) || ml
|}

When the Outershape changes, values for fields that exist on both shapes are preserved and units for removed fields are cleared. For example, changing Box to Sheet / Film / Band keeps L and W and drops H.

=== Element class and conditional attributes ===

Whether a Packaging Element can record a nominal capacity depends on its element class. Containers hold a product and therefore carry a nominal capacity; closures and other elements do not.

{| class="wikitable"
! Element class !! Dimensions !! Nominal capacity
|-
| Container (bottle, jar, can, tube, cup) || Yes || Yes
|-
| Closure (cap, lid, stopper) || Yes || No
|-
| Other (label, sleeve, tray, insert) || Yes || No
|}

=== Packaging Measurement attributes ===

Dimensions are stored as two parallel maps on the element: a value per field code and a unit per field code. Only the fields declared by the Outershape are populated.

{| class="wikitable"
! Attribute !! Definition !! Type / unit !! Card.
|-
| outershapeCode || Reference to the Outershape in the shape registry. || Code (Shape Type list) || 1..1
|-
| dimensionValue[field] || Measured value for a declared dimension field (L, W, H, D). || Decimal || 0..1 per field
|-
| dimensionUnit[field] || Unit of measure for that dimension field. || Code (length subset) || 0..1 per field
|-
| nominalCapacity || Declared filling capacity of a container element. || Decimal || 0..1
|-
| nominalCapacityUnit || Unit of measure for nominal capacity. || Code (capacity subset) || 0..1
|}

== Material Thickness ==

Thickness is a property of the material, not of the element outer shape. This follows the [[Material Thickness - TX|Material Thickness]] taxonomy, which separates thickness from outer dimensions such as length, width, height, depth and diameter. Modelling thickness at material level keeps the shape registry purely geometric and matches current GDSN practice, where thickness is reported only for selected materials such as aluminium and is carried on the material.

=== Where thickness lives in the hierarchy ===

A Packaging Element consists of one or more Packaging Materials. A Packaging Material can be simple or composite. A composite Packaging Material consists of two or more Composite Materials, which are the individual layers of a laminate or multilayer structure. Thickness therefore has two variants.

{| class="wikitable"
! Level !! Thickness variant !! Meaning
|-
| Packaging Material || Material thickness || Total thickness of the material or the complete material structure.
|-
| Composite Material (layer) || Layer thickness || Thickness of one individual layer within a composite material.
|}

A simple, non composite material carries only material thickness. A composite carries a layer thickness on each Composite Material, plus a material thickness on the Packaging Material that represents the total structure.

=== Total thickness versus the sum of layers ===

For a composite, the material thickness (total) may be measured directly or derived from the sum of the layer thicknesses. Treat the layer thicknesses as the source of truth where layers are modelled. Enter the total directly for a simple material, and for a composite validate the total against the sum of the layers, flagging a mismatch rather than overwriting, so that a measured total and a calculated total stay reconcilable.

=== The Thickness type ===

Thickness reuses one shared type, applied at both the Packaging Material and Composite Material levels. The nominal value is the primary figure and is the value published for data exchange. Minimum and maximum are optional and used when a tolerance or range is required, mainly for films and foils. The default unit is mm, with um available for thin films and foils.

{| class="wikitable"
! Attribute !! Definition !! Type / unit !! Card.
|-
| nominal || Declared nominal thickness; the value published for data exchange. || Measurement, length (mm or um) || 0..1
|-
| minimum || Lower bound of the thickness range, when a range is specified. || Measurement, length || 0..1
|-
| maximum || Upper bound of the thickness range, when a range is specified. || Measurement, length || 0..1
|}

A separate average attribute is intentionally not introduced. The nominal value already represents the declared figure. If measured quality control statistics are captured later, model them as a distinct measured value rather than overloading nominal, so that the declared specification and the measured result never collide. A single nominal value satisfies the current GDSN requirement for materials such as aluminium today.

== Data model summary ==

The Measurements information model resolves to the following entities. The model is technology neutral and maps directly to relational tables, to JSON objects and to XML complex types.

{| class="wikitable"
! Entity !! Key attributes !! Attaches to
|-
| TradeItemMeasurement || height, width, depth, diameter, netContent, netWeight, grossWeight, drainedWeight (each value plus unit) || Sales Unit, Grouped Unit, Transport Unit
|-
| PackagingMeasurement || outershapeCode, dimensionValue[ ], dimensionUnit[ ], nominalCapacity, nominalCapacityUnit || Packaging Element
|-
| MaterialThickness || nominal, minimum, maximum (each value plus unit) || Packaging Material (total) and Composite Material (layer)
|-
| ShapeType (reference) || code, name, dimensionFields[ ] (subset of L, W, H, D), sortOrder || Referenced by PackagingMeasurement
|-
| UnitOfMeasure (reference) || code, name, quantityKind (length, mass, volume, count) || Referenced by all measurement values
|}

'''Reusable Measurement type.''' Every measured quantity is a pair of a decimal value and a unit of measure code. One shared Measurement type keeps Trade Item Measurements, Packaging Measurements and Material Thickness consistent and makes schema generation in XLS, XML and JSON straightforward. Material Thickness reuses this type with optional minimum and maximum, applied at the Packaging Material and Composite Material levels.

[[Category:Information Model]]

Material Thickness - TX

2026-06-21T08:21:23Z

HansdG: Created page with "== Material Thickness == '''Material Thickness''' is the measured distance between two opposite surfaces of a material or material layer. It may be specified as a single nominal value or as a range, for example when minimum and maximum thickness values are required. In packaging specifications, Material Thickness describes how thick the material itself is. It should not be confused with the outer dimensions of a packaging item, such as length, width, height, depth or d..."

== Material Thickness ==

'''Material Thickness''' is the measured distance between two opposite surfaces of a material or material layer. It may be specified as a single nominal value or as a range, for example when minimum and maximum thickness values are required.

In packaging specifications, Material Thickness describes how thick the material itself is. It should not be confused with the outer dimensions of a packaging item, such as length, width, height, depth or diameter.

Depending on the packaging type, material type or industry context, Material Thickness may also be referred to as:

* '''Wall thickness''' for rigid packaging such as bottles, jars, cans, cups, tubes and closures.
* '''Film thickness''' for flexible packaging such as films, foils, wraps, sleeves and laminates.
* '''Sheet thickness''' for sheets, plates, labels, layer pads and liners.
* '''Caliper''' for paper, paperboard, cardboard and corrugated board.
* '''Gauge''' for films, foils, sheet metals and other thin materials.
* '''Layer thickness''' for individual layers in multilayer packaging materials.
* '''Coating thickness''' for coatings, varnishes, lacquers, inks and barrier coatings.

Material Thickness can describe the total thickness of a material structure or, where relevant, the thickness of a specific material layer.

[[Category: Taxonomy]]

EORI (Economic Operators Registration and Identification) - ID

2026-06-20T11:17:58Z

HansdG: HansdG moved page EORI Economic Operators Registration and Identification - ID to EORI (Economic Operators Registration and Identification) - ID without leaving a redirect

= EORI Number =

== What is an EORI number? ==

An EORI number is an ''Economic Operators Registration and Identification'' number.

It is a unique identification number used by customs authorities to identify economic operators involved in customs activities. Businesses and, in some cases, individuals need an EORI number when importing goods into or exporting goods out of the customs territory of the European Union.

An EORI number allows customs authorities to recognise the same economic operator across customs declarations, safety and security filings, and other customs-related processes.

== Why is an EORI number needed? ==

An EORI number is needed for customs processes involving international trade.

The main reasons are:

* '''Customs clearance''' - An EORI number is required for customs declarations, entry summary declarations and exit summary declarations. Without a valid EORI number, shipments may be delayed or blocked at the border.
* '''Data exchange''' - The EORI number allows customs authorities, businesses and logistics parties to exchange customs data efficiently and consistently across EU member states.
* '''Identification and tracking''' - The EORI number uniquely identifies the economic operator involved in cross-border trade activities.

== Who needs an EORI number? ==

An EORI number is generally needed by economic operators that interact with EU customs authorities.

This includes:

* '''EU-based businesses''' - Companies, sole proprietors and other economic operators established in the EU that import goods into or export goods out of the EU.
* '''Non-EU businesses''' - Companies established outside the EU that act as importer of record, lodge customs declarations, or submit safety and security declarations in the EU.

In practice, an EORI number is required when an economic operator needs to be identified in EU customs procedures.

== Structure of an EORI number ==

An EORI number is unique and consists of letters and numbers.

For EU member states, the EORI number usually starts with a two-letter country code that identifies the member state that issued the number.

Examples of country codes:

* <code>NL</code> - Netherlands
* <code>DE</code> - Germany
* <code>FR</code> - France
* <code>BE</code> - Belgium

The country code is followed by a national identifier. The exact structure of the national identifier depends on the issuing country.

A simplified structure is:

<code>Country Code</code> + <code>National Identifier</code>

Example:

<code>NL123456789</code>

== How to get an EORI number ==

An EORI number is normally requested from the customs authority of the country where the economic operator is established.

For example:

* A business established in the Netherlands applies through Dutch Customs.
* A business established in Germany applies through German customs.
* A business established in another EU member state applies through the customs authority of that member state.

Applying for an EORI number is generally free of charge.

Non-EU businesses that need an EORI number should apply in the EU member state where they first carry out customs activities, or where they are required to lodge customs declarations.

== EORI in data exchange ==

In data exchange, an EORI number can be used as an external identifier for an economic operator.

It identifies the party for customs purposes, but it does not replace all other identifiers. The same economic operator may also have other identifiers, such as:

* Legal Entity Identifier, or LEI
* VAT number
* D-U-N-S number
* Company registration number
* Tax identification number
* GLN

For this reason, an EORI number should usually be stored as one of the external identifiers linked to the economic operator.

== Suggested field names ==

For data exchange, the following field names can be used:

* <code>EconomicOperatorID</code> - The main VTA Economic Operator identifier
* <code>ExternalIdentifierType</code> - The type of external identifier, for example <code>EORI</code>
* <code>ExternalIdentifierValue</code> - The EORI number itself
* <code>CountryCode</code> - The country related to the identifier, where relevant
* <code>IssuingAuthority</code> - The customs authority or issuing organisation, where known

Example:

<code>ExternalIdentifierType</code>: <code>EORI</code>

<code>ExternalIdentifierValue</code>: <code>NL123456789</code>

<code>CountryCode</code>: <code>NL</code>

== Summary ==

An EORI number is a customs identifier used to identify economic operators involved in import and export activities with the European Union.

It is required for many customs processes and supports efficient data exchange between businesses, logistics parties and customs authorities.

In a broader economic operator registry, the EORI number should be treated as an external identifier linked to the economic operator, alongside other identifiers such as LEI, VAT number, D-U-N-S number and company registration number.

[[Category:Identifiers]]

EORI (Economic Operators Registration and Identification) - ID

2026-06-20T11:17:41Z

HansdG:

LEI (Legel Entity Identifier) - ID

2026-06-20T11:16:38Z

HansdG: HansdG moved page LEI Legel Entity Identifier - ID to LEI (Legel Entity Identifier) - ID

A Legal Entity Identifier (LEI) is a unique 20-character alphanumeric code used globally to identify legal entities that participate in financial transactions.

In the EU, LEIs are heavily mandated by regulations like MiFIR and EMIR to ensure market transparency and prevent financial fraud.

An example of an LEI belonging to a well-known European entity is:529900O1HZZDWNUT6Y94

This specific LEI belongs to ASML Holding N.V. (a major Dutch semiconductor manufacturer).

===Structure of an LEI Number===
Every valid LEI follows the ISO 17442 standard and is broken down into three logical parts:
*'''Characters 1–4 (Prefix)''': Identifies the Local Operating Unit (LOU) that issued the code.Example: 5299 indicates the LOU is the London Stock Exchange
*'''Characters 5–18 (Entity ID)''': A randomly generated, unique number assigned to the specific company. Example: 00O1HZZDWNUT6Y identifies ASML uniquely.
*'''Characters 19–20 (Checksum)''': Two digits used by computer systems to validate the code and prevent data entry errors

'''Multiple issuers exist, but the identifier is globally coordinated.'''
LEI issuers are called Local Operating Units, or LOUs. An entity can choose an accredited issuer, not necessarily one in its own country, but the issued LEI is recorded in the Global LEI System and published through the GLEIF Global LEI Index. GLEIF describes the LEI as a unique 20-character code, and each LEI can represent only one entity.

An entity can transfer the management of its LEI from one issuer to another, for example for service or pricing reasons. That does not create a second LEI. It changes the managing LOU.

'''The LEI number does not change on transfer.'''
The first four characters are indeed the LOU prefix, but they identify the LOU that first issued the LEI, not necessarily the LOU currently maintaining it. The LEI ROC explains that the prefix “identifies the LOU that first issued the LEI,” and adds that the entity may later have “ported the maintenance of its LEI to a different LOU.”

{| class="wikitable"
! Sample LOU / LEI Issuer
! Country / market association
|-
| London Stock Exchange LEI Limited
| United Kingdom
|-
| Bloomberg Finance L.P.
| United States
|-
| Ubisecure Oy / RapidLEI
| Finland / global
|-
| GS1 AISBL
| Belgium / global GS1 network
|-
| Kamer van Koophandel
| Netherlands
|-
| INSEE
| France
|-
| Bundesanzeiger Verlag GmbH
| Germany
|-
| WM Datenservice
| Germany
|-
| Krajowy Depozyt Papierów Wartościowych S.A.
| Poland
|-
| CSD Prague
| Czech Republic
|}

[[Category:Identifiers]]

EORI (Economic Operators Registration and Identification) - ID

2026-06-20T11:15:37Z

HansdG: Created page with "= EORI Number = == What is an EORI number? == An EORI number is an ''Economic Operators Registration and Identification'' number. It is a unique identification number used by customs authorities to identify economic operators involved in customs activities. Businesses and, in some cases, individuals need an EORI number when importing goods into or exporting goods out of the customs territory of the European Union. An EORI number allows customs authorities to recognis..."

VTA Identifiers - ID

2026-06-20T10:50:13Z

HansdG: /* Identifier structure */

== Identifiers for value chain data exchange ==

VTA identifiers are designed to support reliable data exchange across value chains. In a value chain, many different parties need to exchange data about products, packaging, facilities, batches, serialized items, brands, materials and economic operators. This data often moves between different systems, standards, markets and organisations.

For this to work, every object or party referenced in the data exchange needs a stable identifier. Without stable identifiers, systems cannot reliably understand whether two data records refer to the same product model, the same packaging system, the same facility, the same batch or the same economic operator.

VTA identifiers provide a structured way to identify the main entities that are needed for value chain data exchange.

== ISO/IEC 15459 context ==

VTA is an Issuing Agency Code registered under ISO/IEC 15459, ''Information technology - Automatic identification and data capture techniques - Unique identification''.

ISO/IEC 15459 provides a framework for globally unique identification. It uses the concept of registered Issuing Agency Codes and rules for issuing identifiers in a way that prevents different issuing organisations from creating conflicting identifiers.

Within this framework, <code>VTA</code> is the ISO/IEC 15459 Issuing Agency Code. VTA identifiers are therefore issued under the VTA issuing agency namespace.

VTA applies the ISO/IEC 15459 principles to value chain data exchange. The VTA identifier structure combines:

* the ISO/IEC 15459 Issuing Agency Code <code>VTA</code>
* a VTA-controlled Identity Issuer Code
* a VTA Entity Class
* an Identifier Body

This makes it possible to combine global uniqueness, central governance and scalable local issuing.

== Why VTA identifiers are needed ==

Many existing identifiers are designed for a specific industry, market, organisation or use case. They are often excellent within their original context, but less suitable when data needs to move across many domains.

Value chain data exchange requires identifiers that are:

* globally understandable
* machine-readable
* stable over time
* suitable for multiple entity types
* usable by both central authorities and local issuing systems
* flexible enough for different industries and technical environments

VTA identifiers are not intended to replace all existing identifiers. Instead, they provide a common identifier framework that can be used in data exchange to reference entities consistently.

A VTA identifier can point to a product model, a packaging system, a sales unit, a facility, a batch, a serialized item, a material platform, an economic operator or a trademark/brand.

== Central and local issuing ==

VTA supports both central and local issuing of identifiers.

Some identifiers need to be governed centrally because duplicate identifiers would create major problems in the value chain. Economic Operator identifiers are an example. If the same legal or economic party receives multiple independent identifiers from different identity issuers, systems may not be able to determine that these identifiers refer to the same party. For this reason, Economic Operator identifiers can be centrally issued.

Other identifiers can be issued locally by authorised identity issuers. For example, a product manufacturer, platform or system provider may issue identifiers for product models, packaging systems, batches or serialized items within its own VTA identity issuer namespace. As long as the Identity Issuer Code is unique within VTA and the issuing rules are followed, the resulting full VTA identifier remains globally unique.

This combination makes VTA practical for real-world implementation. It allows central governance where needed, while still allowing local systems to create identifiers at scale.

= VTA Identifiers =

== Identifiers for value chain data exchange ==

VTA identifiers are designed to support reliable data exchange across value chains. In a value chain, many different parties need to exchange data about products, packaging, facilities, batches, serialized items, brands, materials and economic operators. This data often moves between different systems, standards, markets and organisations.

For this to work, every object or party referenced in the data exchange needs a stable identifier. Without stable identifiers, systems cannot reliably understand whether two data records refer to the same product model, the same packaging system, the same facility, the same batch or the same economic operator.

VTA identifiers provide a structured way to identify the main entities that are needed for value chain data exchange.

== ISO/IEC 15459 context ==

VTA is an Issuing Agency Code registered under ISO/IEC 15459, ''Information technology - Automatic identification and data capture techniques - Unique identification''.

ISO/IEC 15459 provides a framework for globally unique identification. It uses the concept of registered Issuing Agency Codes and rules for issuing identifiers in a way that prevents different issuing organisations from creating conflicting identifiers.

Within this framework, <code>VTA</code> is the ISO/IEC 15459 Issuing Agency Code. VTA identifiers are therefore issued under the VTA issuing agency namespace.

VTA applies the ISO/IEC 15459 principles to value chain data exchange. The VTA identifier structure combines:

* the ISO/IEC 15459 Issuing Agency Code <code>VTA</code>
* a VTA-controlled Identity Issuer Code
* a VTA Entity Class
* an Identifier Body

This makes it possible to combine global uniqueness, central governance and scalable local issuing.

== Why VTA identifiers are needed ==

Many existing identifiers are designed for a specific industry, market, organisation or use case. They are often excellent within their original context, but less suitable when data needs to move across many domains.

Value chain data exchange requires identifiers that are:

* globally understandable
* machine-readable
* stable over time
* suitable for multiple entity types
* usable by both central authorities and local issuing systems
* flexible enough for different industries and technical environments

VTA identifiers are not intended to replace all existing identifiers. Instead, they provide a common identifier framework that can be used in data exchange to reference entities consistently.

A VTA identifier can point to a product model, a packaging system, a sales unit, a facility, a batch, a serialized item, a material platform, an economic operator or a trademark/brand.

== Central and local issuing ==

VTA supports both central and local issuing of identifiers.

Some identifiers need to be governed centrally because duplicate identifiers would create major problems in the value chain. Economic Operator identifiers are an example. If the same legal or economic party receives multiple independent identifiers from different identity issuers, systems may not be able to determine that these identifiers refer to the same party. For this reason, Economic Operator identifiers can be centrally issued.

Other identifiers can be issued locally by authorised identity issuers. For example, a product manufacturer, platform or system provider may issue identifiers for product models, packaging systems, batches or serialized items within its own VTA identity issuer namespace. As long as the Identity Issuer Code is unique within VTA and the issuing rules are followed, the resulting full VTA identifier remains globally unique.

This combination makes VTA practical for real-world implementation. It allows central governance where needed, while still allowing local systems to create identifiers at scale.

== Identifier structure ==

A VTA identifier consists of several parts:

{| class="wikitable"
! Part
! Description
|-
| ISO/IEC 15459 Issuing Agency Code
| The registered Issuing Agency Code. For VTA identifiers this is <code>VTA</code>.
|-
| Identity Issuer Code
| Identifies the VTA-controlled identity issuer namespace.
|-
| Entity Class
| Identifies the type of entity being identified.
|-
| Identifier Body
| Identifies the specific entity within the Identity Issuer Code and Entity Class namespace.
|}

A simplified structure is:

<code>VTA</code> + <code>Identity Issuer Code</code> + <code>Entity Class</code> + <code>Identifier Body</code>

Example:

<code>VTA0000H12345678</code>

In this example:

{| class="wikitable"
! Part
! Example
! Meaning
|-
| ISO/IEC 15459 Issuing Agency Code
| <code>VTA</code>
| The registered VTA Issuing Agency Code
|-
| Identity Issuer Code
| <code>0000</code>
| VTA central identity issuer
|-
| Entity Class
| <code>H</code>
| Economic Operator
|-
| Identifier Body
| <code>12345678</code>
| Specific Economic Operator
|}

The Identity Issuer Code ensures that different authorised identity issuers can issue identifiers without creating collisions. The Entity Class ensures that the identifier can be interpreted in the correct value chain context.

== Reserved central identity issuer code ==

The Identity Issuer Code <code>0000</code> is reserved for centrally issued VTA identifiers.

This means that an identifier such as:

<code>VTA0000H...</code>

can be recognised as a centrally issued VTA Economic Operator identifier.

The code <code>0000</code> should not be used as a placeholder, unknown value, default value or temporary value. It is a valid reserved Identity Issuer Code for centrally governed VTA identifiers.

== Flexible length ==

VTA identifiers support flexible identifier lengths. Different entity classes have different practical requirements.

For example, a Product Model identifier may need a different length than a Batch identifier or a Serialized Item identifier. Some identifiers are expected to remain relatively short and stable, while others may need additional capacity because they are issued in large volumes.

Each entity class can define its own minimum, preferred and maximum length for the Identifier Body.

{| class="wikitable"
! Key
! Entity Class
! Type
! Minimum length
! Preferred length
! Maximum length
|-
| A
| Product Model
| Object
| 6
| 7
| 8
|-
| B
| Packaging System
| Object
| 8
| 8
| 8
|-
| C
| Sales Unit
| Object
| 8
| 8
| 8
|-
| D
| Facility
| Object
| 8
| 8
| 8
|-
| E
| Batch
| Object
| 5
| 5
| 12
|-
| F
| Serialized Item
| Object
| 8
| 10
| 12
|-
| G
| Material Platform
| Object
| 6
| 6
| 6
|-
| H
| Economic Operator
| Party
| 8
| 8
| 8
|-
| I
| Trademark / Brand
| Object
| 6
| 6
| 6
|}

Flexible length makes the identifier framework more adaptable. It avoids forcing all entity types into the same format, while still keeping the overall structure consistent.

== Character set ==

VTA identifiers should use a restricted character set that is suitable for machine-readable data exchange.

The recommended character set is uppercase alphanumeric characters:

<code>A-Z</code> and <code>0-9</code>

Special characters, spaces and separators should not be used in the VTA identifier itself, unless explicitly allowed by the VTA issuing rules for a specific use case.

This keeps VTA identifiers suitable for XML, JSON, XLS, barcodes, QR codes, APIs and other data exchange formats.

== Field keys for data exchange ==

In XML, JSON, XLS and other data exchange formats, each VTA identifier type should have a clear and stable field key.

The recommended convention is to use the readable English entity name in UpperCamelCase, followed by <code>ID</code>. This keeps the data exchange format understandable without requiring users to learn short internal abbreviations.

{| class="wikitable"
! Identifier type
! Field key
|-
| Product Model
| <code>ProductModelID</code>
|-
| Packaging System
| <code>PackagingSystemID</code>
|-
| Sales Unit
| <code>SalesUnitID</code>
|-
| Facility
| <code>FacilityID</code>
|-
| Batch
| <code>BatchID</code>
|-
| Serialized Item
| <code>SerializedItemID</code>
|-
| Material Platform
| <code>MaterialPlatformID</code>
|-
| Economic Operator
| <code>EconomicOperatorID</code>
|-
| Trademark / Brand
| <code>TrademarkBrandID</code>
|}

For future VTA entity classes, the same convention should be used:

<code>EntityNameID</code>

Examples:

{| class="wikitable"
! Future entity class
! Field key
|-
| Packaging Component
| <code>PackagingComponentID</code>
|-
| Material Source
| <code>MaterialSourceID</code>
|-
| Declaration
| <code>DeclarationID</code>
|}

== Entity classes ==

VTA identifiers use an Entity Class key to indicate what type of entity is being identified.

=== A: Product Model ===

A Product Model identifies the product as a model or specification. It is not a single physical item and not necessarily a specific commercial sales unit. It is the product definition that can be used across markets, channels or packaging configurations.

Product Model identifiers are useful when product-related data needs to be exchanged independently from packaging, logistics or serialization.

=== B: Packaging System ===

A Packaging System identifies a packaging configuration or packaging structure. This can include the combination of packaging components that together form the packaging system for a product or sales unit.

Packaging System identifiers support exchange of packaging-related data, such as material composition, recyclability, packaging tax data and sustainability information.

=== C: Sales Unit ===

A Sales Unit identifies a commercial unit that can be sold or exchanged in the market. It can combine product, packaging and other commercial attributes.

Sales Unit identifiers are useful when data exchange needs to refer to a tradeable unit rather than only the product model or packaging system.

=== D: Facility ===

A Facility identifies a physical site, such as a production location, warehouse, distribution centre or other relevant value chain location.

Facility identifiers can be used in data exchange for traceability, sustainability declarations, manufacturing information, compliance data and supply chain transparency.

=== E: Batch ===

A Batch identifies a group of products or materials produced, processed or handled together under defined conditions.

Batch identifiers are important for traceability, quality management, recalls, compliance and product-specific declarations that apply to a production batch rather than to an individual item.

The Batch entity class supports a flexible Identifier Body length, allowing different industries and systems to use batch identifiers with different levels of complexity.

=== F: Serialized Item ===

A Serialized Item identifies an individual physical item.

Serialized Item identifiers may be issued in very high volumes and are often generated in operational systems. VTA supports this by allowing authorised identity issuers to issue serialized item identifiers within their own VTA identity issuer namespace.

For serialized items, the Identity Issuer Code can be followed by an Identifier Body that is generated by an internal system. This allows companies to continue using internal serial number generation logic while making the resulting identifier globally unique in the VTA framework.

For example:

<code>VTA1234FABC987654</code>

In this example:

{| class="wikitable"
! Part
! Example
! Meaning
|-
| ISO/IEC 15459 Issuing Agency Code
| <code>VTA</code>
| The registered VTA Issuing Agency Code
|-
| Identity Issuer Code
| <code>1234</code>
| Local identity issuer namespace
|-
| Entity Class
| <code>F</code>
| Serialized Item
|-
| Identifier Body
| <code>ABC987654</code>
| Internally generated serial reference
|}

This makes VTA suitable for item-level data exchange without requiring every serial number to be centrally issued.

=== G: Material Platform ===

A Material Platform identifies a material concept or material platform that can be referenced across products, packaging or value chain processes.

This can be used to exchange data about material composition, material origin, recycled or virgin content, certification, environmental impact and other material-related declarations.

=== H: Economic Operator ===

An Economic Operator identifies a party in the value chain. This can include manufacturers, importers, distributors, authorised representatives, fulfilment service providers or other parties that have a role in placing, moving or maintaining products in the market.

Economic Operator identifiers are candidates for central issuing because the same party may appear in many data exchanges, systems and value chains. A centrally issued identifier reduces the risk of duplicates and helps systems recognise the same party across different contexts.

Example:

<code>VTA0000H12345678</code>

This indicates a centrally issued VTA identifier for an Economic Operator.

=== I: Trademark / Brand ===

A Trademark / Brand identifier identifies a brand, trademark or other market-facing identity.

This is useful when product data exchange needs to distinguish between the manufacturer, the owner of the brand, the commercial product identity and the actual product model.

== Identity issuer permissions ==

Not every identity issuer should be allowed to issue every type of VTA identifier.

VTA can use identity issuer permissions to define which entity classes an identity issuer is allowed to issue. This prevents uncontrolled creation of identifiers for entity classes that require stronger governance.

For example, an identity issuer may be allowed to issue Product Model, Batch and Serialized Item identifiers, but not Economic Operator identifiers.

This creates a clear governance model:

{| class="wikitable"
! Role
! Description
|-
| Issuing Agency
| The ISO/IEC 15459 issuing agency responsible for the VTA issuing namespace.
|-
| Central identity issuer
| Issues centrally governed VTA identifiers, using reserved Identity Issuer Code <code>0000</code>.
|-
| Local identity issuer
| Issues identifiers within its own authorised VTA Identity Issuer Code.
|-
| Registrar
| Requests or registers entities for identification.
|-
| Maintainer
| Maintains the data record linked to the identifier.
|-
| Resolver
| Provides access to the data or metadata linked to the identifier.
|}

The identity issuer of an identifier does not need to be the same party as the maintainer or resolver of the related data. This distinction is important in value chain data exchange, where different parties may create, maintain, exchange or host different parts of the data.

== Relationship with existing identifiers ==

VTA identifiers can coexist with existing identifiers. A product, facility, batch, item or economic operator may already have other identifiers from industry standards, regulatory frameworks or internal systems.

A VTA identifier can be used as a common reference in data exchange, while existing identifiers can be stored as additional identifiers or external references.

Examples of external identifiers include:

{| class="wikitable"
! Entity
! Possible external identifiers
|-
| Product Model
| Internal product code, model number, GTIN-related references
|-
| Sales Unit
| GTIN, SKU, retailer item number
|-
| Facility
| GLN, internal site code, regulatory site number
|-
| Batch
| Internal batch code, production lot number
|-
| Serialized Item
| Internal serial number, item-level code
|-
| Economic Operator
| LEI, VAT number, company registration number, EORI
|-
| Trademark / Brand
| Trademark registration number, internal brand code
|}

This makes VTA a bridge for data exchange, not a replacement for every identifier already used in the market.

== Benefits of the VTA identifier model ==

The VTA identifier model provides several benefits:

{| class="wikitable"
! Benefit
! Explanation
|-
| ISO/IEC 15459 basis
| VTA uses a registered ISO/IEC 15459 Issuing Agency Code.
|-
| Global uniqueness
| The combination of Issuing Agency Code, Identity Issuer Code, Entity Class and Identifier Body prevents collisions.
|-
| Human readability
| The structure makes it possible to recognise the issuing namespace and entity type.
|-
| Central governance where needed
| Critical identifiers, such as Economic Operators, can be centrally issued.
|-
| Local scalability
| High-volume identifiers, such as serialized items, can be issued by local systems.
|-
| Flexible length
| Each entity class can have a length suitable for its purpose.
|-
| Data exchange readiness
| Identifiers are designed to be used across organisations, systems and standards.
|-
| Coexistence
| Existing identifiers can remain in use as external references.
|}

== Example identifiers ==

{| class="wikitable"
! Example identifier
! Meaning
|-
| <code>VTA0000H12345678</code>
| Centrally issued Economic Operator identifier.
|-
| <code>VTA1234A7654321</code>
| Product Model issued by local identity issuer <code>1234</code>.
|-
| <code>VTA1234B87654321</code>
| Packaging System issued by local identity issuer <code>1234</code>.
|-
| <code>VTA1234D23456789</code>
| Facility issued by local identity issuer <code>1234</code>.
|-
| <code>VTA1234ELOT25</code>
| Batch issued by local identity issuer <code>1234</code>.
|-
| <code>VTA1234FABC987654</code>
| Serialized Item issued by local identity issuer <code>1234</code>.
|-
| <code>VTA1234I654321</code>
| Trademark / Brand issued by local identity issuer <code>1234</code>.
|}

These examples are illustrative only. The actual Identifier Body must be created according to the issuing rules for the entity class and identity issuer.

== Summary ==

VTA identifiers provide a structured identifier framework for value chain data exchange.

They combine:

* the ISO/IEC 15459 Issuing Agency Code <code>VTA</code>
* a VTA-controlled Identity Issuer Code
* a VTA Entity Class
* a flexible Identifier Body

This allows VTA to support both centrally governed identifiers and locally issued identifiers. Central issuing can be used where uniqueness across the full value chain is critical, such as Economic Operators. Local issuing can be used where identifiers need to be created at scale, such as Product Models, Batches or Serialized Items.

The result is an identifier framework that is structured, scalable and suitable for cross-company data exchange.

== Reserved central identity issuer code ==

The Identity Issuer Code <code>0000</code> is reserved for centrally issued VTA identifiers.

This means that an identifier such as:

<code>VTA0000H...</code>

can be recognised as a centrally issued VTA Economic Operator identifier.

The code <code>0000</code> should not be used as a placeholder, unknown value, default value or temporary value. It is a valid reserved Identity Issuer Code for centrally governed VTA identifiers.

== Flexible length ==

VTA identifiers support flexible identifier lengths. Different entity classes have different practical requirements.

For example, a Product Model identifier may need a different length than a Batch identifier or a Serialized Item identifier. Some identifiers are expected to remain relatively short and stable, while others may need additional capacity because they are issued in large volumes.

Each entity class can define its own minimum, preferred and maximum length for the Identifier Body.

{| class="wikitable"
! Key
! Entity Class
! Type
! Minimum length
! Preferred length

| ! Maximum length |
| ----------------- |
| A |
| Product Model |
| Object |
| 6 |
| 7 |
| 8 |
| - |
| B |
| Packaging System |
| Object |
| 8 |
| 8 |
| 8 |
| - |
| C |
| Sales Unit |
| Object |
| 8 |
| 8 |
| 8 |
| - |
| D |
| Facility |
| Object |
| 8 |
| 8 |
| 8 |
| - |
| E |
| Batch |
| Object |
| 5 |
| 5 |
| 12 |
| - |
| F |
| Serialized Item |
| Object |
| 8 |
| 10 |
| 12 |
| - |
| G |
| Material Platform |
| Object |
| 6 |
| 6 |
| 6 |
| - |
| H |
| Economic Operator |
| Party |
| 8 |
| 8 |
| 8 |
| - |
| I |
| Trademark / Brand |
| Object |
| 6 |
| 6 |
| 6 |
| } |

Flexible length makes the identifier framework more adaptable. It avoids forcing all entity types into the same format, while still keeping the overall structure consistent.

== Character set ==

VTA identifiers should use a restricted character set that is suitable for machine-readable data exchange.

The recommended character set is uppercase alphanumeric characters:

<code>A-Z</code> and <code>0-9</code>

Special characters, spaces and separators should not be used in the VTA identifier itself, unless explicitly allowed by the VTA issuing rules for a specific use case.

This keeps VTA identifiers suitable for XML, JSON, XLS, barcodes, QR codes, APIs and other data exchange formats.

== Field keys for data exchange ==

In XML, JSON, XLS and other data exchange formats, each VTA identifier type should have a clear and stable field key.

The recommended convention is to use the readable English entity name in UpperCamelCase, followed by <code>ID</code>. This keeps the data exchange format understandable without requiring users to learn short internal abbreviations.

{| class="wikitable"
! Identifier type

| ! Field key |
| ------------------------------- |
| Product Model |
| <code>ProductModelID</code> |
| - |
| Packaging System |
| <code>PackagingSystemID</code> |
| - |
| Sales Unit |
| <code>SalesUnitID</code> |
| - |
| Facility |
| <code>FacilityID</code> |
| - |
| Batch |
| <code>BatchID</code> |
| - |
| Serialized Item |
| <code>SerializedItemID</code> |
| - |
| Material Platform |
| <code>MaterialPlatformID</code> |
| - |
| Economic Operator |
| <code>EconomicOperatorID</code> |
| - |
| Trademark / Brand |
| <code>TrademarkBrandID</code> |
| } |

For future VTA entity classes, the same convention should be used:

<code>EntityNameID</code>

Examples:

{| class="wikitable"
! Future entity class

| ! Field key |
| --------------------------------- |
| Packaging Component |
| <code>PackagingComponentID</code> |
| - |
| Material Source |
| <code>MaterialSourceID</code> |
| - |
| Declaration |
| <code>DeclarationID</code> |
| } |

== Entity classes ==

VTA identifiers use an Entity Class key to indicate what type of entity is being identified.

=== A: Product Model ===

A Product Model identifies the product as a model or specification. It is not a single physical item and not necessarily a specific commercial sales unit. It is the product definition that can be used across markets, channels or packaging configurations.

Product Model identifiers are useful when product-related data needs to be exchanged independently from packaging, logistics or serialization.

=== B: Packaging System ===

A Packaging System identifies a packaging configuration or packaging structure. This can include the combination of packaging components that together form the packaging system for a product or sales unit.

Packaging System identifiers support exchange of packaging-related data, such as material composition, recyclability, packaging tax data and sustainability information.

=== C: Sales Unit ===

A Sales Unit identifies a commercial unit that can be sold or exchanged in the market. It can combine product, packaging and other commercial attributes.

Sales Unit identifiers are useful when data exchange needs to refer to a tradeable unit rather than only the product model or packaging system.

=== D: Facility ===

A Facility identifies a physical site, such as a production location, warehouse, distribution centre or other relevant value chain location.

Facility identifiers can be used in data exchange for traceability, sustainability declarations, manufacturing information, compliance data and supply chain transparency.

=== E: Batch ===

A Batch identifies a group of products or materials produced, processed or handled together under defined conditions.

Batch identifiers are important for traceability, quality management, recalls, compliance and product-specific declarations that apply to a production batch rather than to an individual item.

The Batch entity class supports a flexible Identifier Body length, allowing different industries and systems to use batch identifiers with different levels of complexity.

=== F: Serialized Item ===

A Serialized Item identifies an individual physical item.

Serialized Item identifiers may be issued in very high volumes and are often generated in operational systems. VTA supports this by allowing authorised identity issuers to issue serialized item identifiers within their own VTA identity issuer namespace.

For serialized items, the Identity Issuer Code can be followed by an Identifier Body that is generated by an internal system. This allows companies to continue using internal serial number generation logic while making the resulting identifier globally unique in the VTA framework.

For example:

<code>VTA1234FABC987654</code>

In this example:

{| class="wikitable"
! Part
! Example

| ! Meaning |
| -------------------------------------- |
| ISO/IEC 15459 Issuing Agency Code |
| <code>VTA</code> |
| The registered VTA Issuing Agency Code |
| - |
| Identity Issuer Code |
| <code>1234</code> |
| Local identity issuer namespace |
| - |
| Entity Class |
| <code>F</code> |
| Serialized Item |
| - |
| Identifier Body |
| <code>ABC987654</code> |
| Internally generated serial reference |
| } |

This makes VTA suitable for item-level data exchange without requiring every serial number to be centrally issued.

=== G: Material Platform ===

A Material Platform identifies a material concept or material platform that can be referenced across products, packaging or value chain processes.

This can be used to exchange data about material composition, material origin, recycled or virgin content, certification, environmental impact and other material-related declarations.

=== H: Economic Operator ===

An Economic Operator identifies a party in the value chain. This can include manufacturers, importers, distributors, authorised representatives, fulfilment service providers or other parties that have a role in placing, moving or maintaining products in the market.

Economic Operator identifiers are candidates for central issuing because the same party may appear in many data exchanges, systems and value chains. A centrally issued identifier reduces the risk of duplicates and helps systems recognise the same party across different contexts.

Example:

<code>VTA0000H12345678</code>

This indicates a centrally issued VTA identifier for an Economic Operator.

=== I: Trademark / Brand ===

A Trademark / Brand identifier identifies a brand, trademark or other market-facing identity.

This is useful when product data exchange needs to distinguish between the manufacturer, the owner of the brand, the commercial product identity and the actual product model.

== Identity issuer permissions ==

Not every identity issuer should be allowed to issue every type of VTA identifier.

VTA can use identity issuer permissions to define which entity classes an identity issuer is allowed to issue. This prevents uncontrolled creation of identifiers for entity classes that require stronger governance.

For example, an identity issuer may be allowed to issue Product Model, Batch and Serialized Item identifiers, but not Economic Operator identifiers.

This creates a clear governance model:

{| class="wikitable"
! Role

| ! Description |
| ------------------------------------------------------------------------------------------------- |
| Issuing Agency |
| The ISO/IEC 15459 issuing agency responsible for the VTA issuing namespace. |
| - |
| Central identity issuer |
| Issues centrally governed VTA identifiers, using reserved Identity Issuer Code <code>0000</code>. |
| - |
| Local identity issuer |
| Issues identifiers within its own authorised VTA Identity Issuer Code. |
| - |
| Registrar |
| Requests or registers entities for identification. |
| - |
| Maintainer |
| Maintains the data record linked to the identifier. |
| - |
| Resolver |
| Provides access to the data or metadata linked to the identifier. |
| } |

The identity issuer of an identifier does not need to be the same party as the maintainer or resolver of the related data. This distinction is important in value chain data exchange, where different parties may create, maintain, exchange or host different parts of the data.

== Relationship with existing identifiers ==

VTA identifiers can coexist with existing identifiers. A product, facility, batch, item or economic operator may already have other identifiers from industry standards, regulatory frameworks or internal systems.

A VTA identifier can be used as a common reference in data exchange, while existing identifiers can be stored as additional identifiers or external references.

Examples of external identifiers include:

{| class="wikitable"
! Entity

| ! Possible external identifiers |
| ------------------------------------------------------------ |
| Product Model |
| Internal product code, model number, GTIN-related references |
| - |
| Sales Unit |
| GTIN, SKU, retailer item number |
| - |
| Facility |
| GLN, internal site code, regulatory site number |
| - |
| Batch |
| Internal batch code, production lot number |
| - |
| Serialized Item |
| Internal serial number, item-level code |
| - |
| Economic Operator |
| LEI, VAT number, company registration number, EORI |
| - |
| Trademark / Brand |
| Trademark registration number, internal brand code |
| } |

This makes VTA a bridge for data exchange, not a replacement for every identifier already used in the market.

== Benefits of the VTA identifier model ==

The VTA identifier model provides several benefits:

{| class="wikitable"
! Benefit

| ! Explanation |
| ------------------------------------------------------------------------------------------------------------------- |
| ISO/IEC 15459 basis |
| VTA uses a registered ISO/IEC 15459 Issuing Agency Code. |
| - |
| Global uniqueness |
| The combination of Issuing Agency Code, Identity Issuer Code, Entity Class and Identifier Body prevents collisions. |
| - |
| Human readability |
| The structure makes it possible to recognise the issuing namespace and entity type. |
| - |
| Central governance where needed |
| Critical identifiers, such as Economic Operators, can be centrally issued. |
| - |
| Local scalability |
| High-volume identifiers, such as serialized items, can be issued by local systems. |
| - |
| Flexible length |
| Each entity class can have a length suitable for its purpose. |
| - |
| Data exchange readiness |
| Identifiers are designed to be used across organisations, systems and standards. |
| - |
| Coexistence |
| Existing identifiers can remain in use as external references. |
| } |

== Example identifiers ==

{| class="wikitable"
! Example identifier

| ! Meaning |
| -------------------------------------------------------------------- |
| <code>VTA0000H12345678</code> |
| Centrally issued Economic Operator identifier. |
| - |
| <code>VTA1234A7654321</code> |
| Product Model issued by local identity issuer <code>1234</code>. |
| - |
| <code>VTA1234B87654321</code> |
| Packaging System issued by local identity issuer <code>1234</code>. |
| - |
| <code>VTA1234D23456789</code> |
| Facility issued by local identity issuer <code>1234</code>. |
| - |
| <code>VTA1234ELOT25</code> |
| Batch issued by local identity issuer <code>1234</code>. |
| - |
| <code>VTA1234FABC987654</code> |
| Serialized Item issued by local identity issuer <code>1234</code>. |
| - |
| <code>VTA1234I654321</code> |
| Trademark / Brand issued by local identity issuer <code>1234</code>. |
| } |

These examples are illustrative only. The actual Identifier Body must be created according to the issuing rules for the entity class and identity issuer.

== Summary ==

VTA identifiers provide a structured identifier framework for value chain data exchange.

They combine:

* the ISO/IEC 15459 Issuing Agency Code <code>VTA</code>
* a VTA-controlled Identity Issuer Code
* a VTA Entity Class
* a flexible Identifier Body

This allows VTA to support both centrally governed identifiers and locally issued identifiers. Central issuing can be used where uniqueness across the full value chain is critical, such as Economic Operators. Local issuing can be used where identifiers need to be created at scale, such as Product Models, Batches or Serialized Items.

The result is an identifier framework that is structured, scalable and suitable for cross-company data exchange.

2026-06-20T09:55:47Z

HansdG:

LEI (Legel Entity Identifier) - ID

2026-06-20T09:47:57Z

HansdG: /* Structure of an LEI Number */

LEI (Legel Entity Identifier) - ID

2026-06-20T09:47:16Z

HansdG:

A Legal Entity Identifier (LEI) is a unique 20-character alphanumeric code used globally to identify legal entities that participate in financial transactions.

In the EU, LEIs are heavily mandated by regulations like MiFIR and EMIR to ensure market transparency and prevent financial fraud.

An example of an LEI belonging to a well-known European entity is:529900O1HZZDWNUT6Y94

This specific LEI belongs to ASML Holding N.V. (a major Dutch semiconductor manufacturer).

===Structure of an LEI Number===
Every valid LEI follows the ISO 17442 standard and is broken down into three logical parts:
*''Characters 1–4 (Prefix)'''''Bold text''': Identifies the Local Operating Unit (LOU) that issued the code.Example: 5299 indicates the LOU is the London Stock Exchange
*'''Characters 5–18 (Entity ID)''': A randomly generated, unique number assigned to the specific company. Example: 00O1HZZDWNUT6Y identifies ASML uniquely.
*'''Characters 19–20 (Checksum)''': Two digits used by computer systems to validate the code and prevent data entry errors

'''Multiple issuers exist, but the identifier is globally coordinated.'''
LEI issuers are called Local Operating Units, or LOUs. An entity can choose an accredited issuer, not necessarily one in its own country, but the issued LEI is recorded in the Global LEI System and published through the GLEIF Global LEI Index. GLEIF describes the LEI as a unique 20-character code, and each LEI can represent only one entity.

An entity can transfer the management of its LEI from one issuer to another, for example for service or pricing reasons. That does not create a second LEI. It changes the managing LOU.

'''The LEI number does not change on transfer.'''
The first four characters are indeed the LOU prefix, but they identify the LOU that first issued the LEI, not necessarily the LOU currently maintaining it. The LEI ROC explains that the prefix “identifies the LOU that first issued the LEI,” and adds that the entity may later have “ported the maintenance of its LEI to a different LOU.”

{| class="wikitable"
! Sample LOU / LEI Issuer
! Country / market association
|-
| London Stock Exchange LEI Limited
| United Kingdom
|-
| Bloomberg Finance L.P.
| United States
|-
| Ubisecure Oy / RapidLEI
| Finland / global
|-
| GS1 AISBL
| Belgium / global GS1 network
|-
| Kamer van Koophandel
| Netherlands
|-
| INSEE
| France
|-
| Bundesanzeiger Verlag GmbH
| Germany
|-
| WM Datenservice
| Germany
|-
| Krajowy Depozyt Papierów Wartościowych S.A.
| Poland
|-
| CSD Prague
| Czech Republic
|}

[[Category:Identifiers]]

LEI (Legel Entity Identifier) - ID

2026-06-20T09:46:23Z

HansdG:

A Legal Entity Identifier (LEI) is a unique 20-character alphanumeric code used globally to identify legal entities that participate in financial transactions.

In the EU, LEIs are heavily mandated by regulations like MiFIR and EMIR to ensure market transparency and prevent financial fraud.

An example of an LEI belonging to a well-known European entity is:529900O1HZZDWNUT6Y94

This specific LEI belongs to ASML Holding N.V. (a major Dutch semiconductor manufacturer).

===Structure of an LEI Number===
Every valid LEI follows the ISO 17442 standard and is broken down into three logical parts:
*''Characters 1–4 (Prefix)'''''Bold text''': Identifies the Local Operating Unit (LOU) that issued the code.Example: 5299 indicates the LOU is the London Stock Exchange
*'''Characters 5–18 (Entity ID)''': A randomly generated, unique number assigned to the specific company. Example: 00O1HZZDWNUT6Y identifies ASML uniquely.
*'''Characters 19–20 (Checksum)''': Two digits used by computer systems to validate the code and prevent data entry errors

'''Multiple issuers exist, but the identifier is globally coordinated.'''
LEI issuers are called Local Operating Units, or LOUs. An entity can choose an accredited issuer, not necessarily one in its own country, but the issued LEI is recorded in the Global LEI System and published through the GLEIF Global LEI Index. GLEIF describes the LEI as a unique 20-character code, and each LEI can represent only one entity.

An entity can transfer the management of its LEI from one issuer to another, for example for service or pricing reasons. That does not create a second LEI. It changes the managing LOU.

'''The LEI number does not change on transfer.'''
The first four characters are indeed the LOU prefix, but they identify the LOU that first issued the LEI, not necessarily the LOU currently maintaining it. The LEI ROC explains that the prefix “identifies the LOU that first issued the LEI,” and adds that the entity may later have “ported the maintenance of its LEI to a different LOU.”

[[Category:Identifiers]]

LEI (Legel Entity Identifier) - ID

2026-06-20T09:40:59Z

HansdG: Created page with "A Legal Entity Identifier (LEI) is a unique 20-character alphanumeric code used globally to identify legal entities that participate in financial transactions. In the EU, LEIs are heavily mandated by regulations like MiFIR and EMIR to ensure market transparency and prevent financial fraud. An example of an LEI belonging to a well-known European entity is:529900O1HZZDWNUT6Y94 This specific LEI belongs to ASML Holding N.V. (a major Dutch semiconductor manufacturer). '..."

Material Grade - TX

2026-04-03T08:09:34Z

HansdG:

Material Grade is a standardized classification of a raw or semi-finished substance—such as a polymer, metal alloy, textile fabric, or paperboard—defined by a consistent set of technical specifications, chemical compositions, and performance characteristics.

Unlike a "Finished Good" (which has a specific shape and function) or a "Batch" (which represents a single production run), a Material Grade represents a "Type" of material that remains constant across multiple production cycles and diverse end-use applications. It is the primary level at which Technical Dossiers and Compliance Evidence (e.g., REACH, RoHS, PFAS-free, or FSC certifications) are established and maintained.

Key Structural Attributes:
* Technical DNA: Defines the intrinsic properties (e.g., tensile strength, melt flow index, or GSM) and chemical makeup (CAS/EC numbers) of the material.
* Compliance Anchor: Acts as the "Parent" record for laboratory test results. In a circular economy, the Material Grade is the level where recyclability and toxicity data are legally anchored.
* Data Inheritance: Facilitates a "One-to-Many" relationship in data management. A single Material Grade (e.g., Grade 304 Stainless Steel or Recycled HDPE Resin) may be used to manufacture thousands of different unique parts or components.

Traceability Interoperability: Provides the link between the Primary Material Producer (the source) and the Final Product Manufacturer (the assembler). It ensures that sustainability data—such as Carbon Footprint (PCF) or Recycled Content—can be accurately passed through the value chain without redundant data entry.

[[Category: Taxonomy]]

2025-11-14T10:20:38Z

HansdG:

'''Substances of Very High Concern (SVHC)''' is a legal classification of chemicals under the European Union's primary chemical regulation, '''REACH''' (Regulation (EC) No 1907/2006).

This taxonomy page defines the SVHCs that must be tracked for packaging compliance, separate from other specific restrictions like those for Heavy Metals or PFAS under the PPWR.

== 🏛️ Definition and Legal Basis ==
An SVHC is a substance that has been identified as having intrinsic hazardous properties, such as:
* Being carcinogenic, mutagenic, or toxic for reproduction (CMR).
* Being persistent, bioaccumulative, and toxic (PBT).
* Causing other serious effects to human health or the environment (e.g., endocrine disruptors).

=== The Official List ===
There is no fixed list of SVHCs. The official list is called the '''"Candidate List of substances of very high concern for Authorisation"''' and is maintained by the ''European Chemicals Agency (ECHA)''.

This list is dynamic and is '''updated twice per year''' as new substances are identified. All compliance checks must be made against the most current version of this list.

=== The Threshold That Matters: 0.1% w/w ===
For packaging (which is defined as an "article" under REACH), a legal obligation is triggered if any single SVHC from the Candidate List is present in any component in a concentration above '''0.1% weight by weight (w/w)'''.

This is the threshold (equivalent to '''1000 mg/kg''') that must be tracked.

If this threshold is exceeded, producers have legal obligations, including:
1. '''Duty to Communicate:''' Informing B2B customers of the substance's presence and name.
2. '''SCIP Database Notification:''' Submitting a notification to the ECHA **SCIP** (Substances of Concern in Products) database.

== 📋 SVHC Data in Your System ==
In this system, SVHCs are tracked using the following data points for each packaging component.

* '''`SVHC_Present_Above_0_1_pct`''': [Boolean] A True/False flag. "True" means one or more substances from the official ECHA Candidate List are present above the 1000 mg/kg threshold.
* '''`SVHC_Substance_Name`''': [String] The official chemical name of the SVHC.
* '''`SVHC_CAS_Number`''': [String] The CAS number of the SVHC.
* '''`SVHC_EC_Number`''': [String] The EC number of the SVHC.

== 💡 Common SVHCs Relevant for Packaging ==
The full ECHA Candidate List contains over 240 substances. The table below provides common examples relevant to packaging materials. This list is '''for illustration only''' and is not exhaustive.

''Note: This list excludes the four heavy metals (Lead, Cadmium, Mercury, Hexavalent Chromium) and PFAS, which are tracked separately in this system under their own PPWR-specific restrictions.''

{| class="wikitable"
|-
! Substance Name
! EC Number
! CAS Number
! Common Use in Packaging / Where to Look
|-
! colspan="4" | Plasticizers (Phthalates)
|-
| Bis(2-ethylhexyl) phthalate (DEHP)
| 204-211-0
| 117-81-7
| Very common plasticizer, especially in flexible '''PVC'''; also in inks and adhesives.
|-
| Dibutyl phthalate (DBP)
| 201-557-4
| 84-74-2
| Plasticizer for '''PVC''', adhesives, and coatings; solvent in inks.
|-
| Benzyl butyl phthalate (BBP)
| 201-622-7
| 85-68-7
| Plasticizer for '''PVC''', adhesives, sealants, and inks.
|-
| Diisobutyl phthalate (DIBP)
| 201-553-2
| 84-69-5
| Plasticizer, often used as a substitute for DBP in '''PVC''', inks, and adhesives.
|-
! colspan="4" | Monomers & Other Additives
|-
| Bisphenol A (BPA)
| 201-245-8
| 80-05-7
| Monomer for '''Polycarbonate (PC)''' plastic; used in '''epoxy resin''' linings for food/drink cans.
|-
| Melamine
| 203-615-4
| 108-78-1
| Used in resins and polymers. Can be found in "bamboo-melamine" composite packaging.
|}

== See Also ==
* [[EPR_(Extended_Producer_Responsibility)_-_TX]]

[[Category:Taxonomy]]

SVHC Substances of Very High Concern - TX

2025-11-14T10:19:56Z

HansdG: Created page with "'''Substances of Very High Concern (SVHC)''' is a legal classification of chemicals under the European Union's primary chemical regulation, '''REACH''' (Regulation (EC) No 1907/2006). This taxonomy page defines the SVHCs that must be tracked for packaging compliance, separate from other specific restrictions like those for Heavy Metals or PFAS under the PPWR. == 🏛️ Definition and Legal Basis == An SVHC is a substance that has been identified as having intrinsic ha..."

'''Substances of Very High Concern (SVHC)''' is a legal classification of chemicals under the European Union's primary chemical regulation, '''REACH''' (Regulation (EC) No 1907/2006).

This taxonomy page defines the SVHCs that must be tracked for packaging compliance, separate from other specific restrictions like those for Heavy Metals or PFAS under the PPWR.

== 🏛️ Definition and Legal Basis ==
An SVHC is a substance that has been identified as having intrinsic hazardous properties, such as:
* Being carcinogenic, mutagenic, or toxic for reproduction (CMR).
* Being persistent, bioaccumulative, and toxic (PBT).
* Causing other serious effects to human health or the environment (e.g., endocrine disruptors).

=== The Official List ===
There is no fixed list of SVHCs. The official list is called the '''"Candidate List of substances of very high concern for Authorisation"''' and is maintained by the **European Chemicals Agency (ECHA)**.

This list is dynamic and is '''updated twice per year''' as new substances are identified. All compliance checks must be made against the most current version of this list.

=== The Threshold That Matters: 0.1% w/w ===
For packaging (which is defined as an "article" under REACH), a legal obligation is triggered if any single SVHC from the Candidate List is present in any component in a concentration above '''0.1% weight by weight (w/w)'''.

This is the threshold (equivalent to '''1000 mg/kg''') that must be tracked.

If this threshold is exceeded, producers have legal obligations, including:
1. '''Duty to Communicate:''' Informing B2B customers of the substance's presence and name.
2. '''SCIP Database Notification:''' Submitting a notification to the ECHA **SCIP** (Substances of Concern in Products) database.

== 📋 SVHC Data in Your System ==
In this system, SVHCs are tracked using the following data points for each packaging component.

* '''`SVHC_Present_Above_0_1_pct`''': [Boolean] A True/False flag. "True" means one or more substances from the official ECHA Candidate List are present above the 1000 mg/kg threshold.
* '''`SVHC_Substance_Name`''': [String] The official chemical name of the SVHC.
* '''`SVHC_CAS_Number`''': [String] The CAS number of the SVHC.
* '''`SVHC_EC_Number`''': [String] The EC number of the SVHC.

== 💡 Common SVHCs Relevant for Packaging ==
The full ECHA Candidate List contains over 240 substances. The table below provides common examples relevant to packaging materials. This list is '''for illustration only''' and is not exhaustive.

''Note: This list excludes the four heavy metals (Lead, Cadmium, Mercury, Hexavalent Chromium) and PFAS, which are tracked separately in this system under their own PPWR-specific restrictions.''

{| class="wikitable"
|-
! Substance Name
! EC Number
! CAS Number
! Common Use in Packaging / Where to Look
|-
! colspan="4" | Plasticizers (Phthalates)
|-
| Bis(2-ethylhexyl) phthalate (DEHP)
| 204-211-0
| 117-81-7
| Very common plasticizer, especially in flexible '''PVC'''; also in inks and adhesives.
|-
| Dibutyl phthalate (DBP)
| 201-557-4
| 84-74-2
| Plasticizer for '''PVC''', adhesives, and coatings; solvent in inks.
|-
| Benzyl butyl phthalate (BBP)
| 201-622-7
| 85-68-7
| Plasticizer for '''PVC''', adhesives, sealants, and inks.
|-
| Diisobutyl phthalate (DIBP)
| 201-553-2
| 84-69-5
| Plasticizer, often used as a substitute for DBP in '''PVC''', inks, and adhesives.
|-
! colspan="4" | Monomers & Other Additives
|-
| Bisphenol A (BPA)
| 201-245-8
| 80-05-7
| Monomer for '''Polycarbonate (PC)''' plastic; used in '''epoxy resin''' linings for food/drink cans.
|-
| Melamine
| 203-615-4
| 108-78-1
| Used in resins and polymers. Can be found in "bamboo-melamine" composite packaging.
|}

== See Also ==
* [[EPR_(Extended_Producer_Responsibility)_-_TX]]

[[Category:Taxonomy]]