One of the big challenges for organisations implementing EUDR is internal traceability, that is linking inbound goods with outbound goods. This is essential for a few key reasons:
- Where your customers require you to share
DDS Reference Numbers you need to be able to identify the DDS Reference(s) associated on inbound delivery(ies). - Where you have to generate a DDS for an outbound delivery you need to be able to identify all the inbound deliveries so you can ultimately identify all the point's of origin related to those deliveries so you can provide the information requires for the DDS statement.
- When you need to be able to share end-to-end traceability information to your customers.
Whilst this seems great on paper, the reality of how to achieve is very dependent on your internal systems and processes. Often the data needed for this level of traceability is not immediately available and so the challenge of fulfilling end-to-end traceability without causing disruption to your existing processes is challenging.
Interu provides mechanisms to capture the data needed for end-end-end traceability. This can be broken down as follows:
Items that arrive in deliveries need to be linked to processes that happen within your organisation and items that come out of those proceess need to be linked with outbound deliveries.
Note that for all these examples the assumption is that this flow is for the same product, there is no processing or conversion.
This is a simplistic model which doesn't involve any processing but purely picking of goods that come in to send out to customers. It assumes that the specific goods can be identified as part of the picking process.
As you can see, for each outbound delivery, because you can identify the specific items that went into the picking process then Interu is able to link everything required to support EUDR and other traceability requirements.
User defined id for the item.
URI for the product that the item is.
URI for the location where the product was created.
List of material URIs that are used within the item.
URI for the location that the item is at or was last at (perhaps it no longer exists as it entered a manufacturing process).
The type of captured date.
If Type is EXACT then this precise date is used.
If type is RANGE then this is the start date.
If type is RANGE then this is the end date.
This quantity contained within this item at the point when it was created.
Additiononal quantities can be specified directly on the item.
The additional quantity base unit of measurement.
The additional quantity calculated if the product has a conversion to that base unit.
An override quantity provided irrespective of whether or not there is a conversion on the product.
If an item enters a process then this quantity The remaining quantity, some of the item may have been used in a process.
The uri of the product variant if applicable to this item.
If the item is associated with a particular batch (or multiple batches) then you can use this field to record the batch numbers.
System assigned or user defined id field.
Materials represent the raw materials that are incorporated into goods. This is of particular importance in regards to EUDR as it provides the means to specify the Common and Scientific names as required by the regulation.
We currently capture Scientific Name and Common Name custom fields. This is about to be replaced with standard fields within the Material model.
Material Schema
The name of the material.
This is the Scientific Name for this material. It is an optional field but is required for sbmission to the Traces NT system.
This is a Common Name for this material. It is an optional field but is required for sbmission to the Traces NT system.
The category for the material.
System assigned or user defined id field.
Products represent the type of goods that are flowing through the system. If you are submitting DDS Statements to the EU Traces NT system then the Product definition must have an HS Code attached.
We currently capture HS Codes through a custom field. This is about to be replaced with a standard field within the Product model.
Product Schema
The name for the product.
This is the HS (Harmonised Standard) code for the product. This is optional unless this product will be part of submission to the Traces NT system.
This is a simple description for the product. This is optional unless this product will be part of submission to the Traces NT system.
The URI(s) of the material(s) that are allowed to be used for this product.
The URI to the base unit of measurement that this product is specified in.
The URI to the unit of measurement that you wish to use as the default unit of measurement.
A list of additional units that specify the factor for converting from the base unit to other base units: e.g. unit to kg
The URI to the base unit of measurement to convert the base qty to. So if the product is specified in units and the conversion specifies kg then this conversion will provide the per unit mass.
The conversion factor from product base unit to conversion base unit.
System assigned or user defined id field.
Items represent goods flowing through the supply chain. Each item represents a quantity of a Product. It can also define the Materials that were used to make that Item.
Deliveries represent the movement of items (or goods) between two locations.
Items are referenced within the Delivery model by providing the URIs to each Item within the delivery.items collection:
Delivery Item Schema
The URI of the item included in the delivery.
The quantity of the item included in the delivery.
Processes are used to represent what goes on within an organisation, that may be manufacturing or it may simply be used to represent goods that are picked to send to a customer in the case of a trader. They are needed to link inbound goods with outbound goods to maintain end-to-end traceability.
Processes can be long lasting and they are linked to a location where they happened.
Items that enter and exit processes are added by linking them to the process via the .../inputs and .../outputs endpoints.