User Guide: Transaction Management
Transactions Management provides a systematic way to link EUDR compliance data with the product level information required to evidence compliance with the Regulation in the form of a Due Diligence Statement (DDS) in the EU Information System (EU TRACES). It enables key information from your ERP, such as Purchase Orders and Sales Orders, to be captured in these DDS as well providing a way of managing linkages with existing DDS and connections between different product level documentation.
⚠️ Prerequisites
Transactions are a premium feature in TradeAware. To use this functionality, your account must be enabled for transactions. If you do not have this enabled, contact your Customer Success Manager.
Overview
Transaction Management provides a way to link transaction data, such as Purchase Orders (PO) and Sales Orders (SO) to compliance data in TradeAware to create and manage Due Diligence Statements.
Customers can:
Manage Due Diligence Statements: Link orders from your ERP system to compliance data in TradeAware.
Enhance Traceability: Connect DDS compliance data to orders, streamlining regulatory reporting and audit preparation.
Automate Compliance Workflows: Minimize manual data entry by automating key compliance and transaction workflows.
List of Use Cases
Managing Compliance with the Transaction API (for Operators)
Forwarding Upstream DDS References for Traders
Managing Composite Products
Submitting Transactions to TRACES
Linking Transactional Data to Compliance Workflows (e.g. Batches, Shipments)
Key Concepts:
Component Object: Represents a commodity or product, including essential details like type, quantity, and origin, traceable to the supplier or production location. Components are mapped to the requirements for validly creating a Due Diligence Statement in the EU Information System (EU TRACES).
CustomData: Metadata related to the transaction. This flexible structure allows users to store relevant information, provided it follows these rules:
Maximum of 10 keys.
Data must be of type string, number, or boolean. Arrays are not supported due to validation and storage constraints.
ddsReferences: Links a transaction component to one or more Due Diligence Statements (DDS), ensuring compliance and traceability. Each DDS in the array includes:
id
: Unique identifier for the DDS.verificationNumber
: Code validating the DDS’s authenticity.
supplierBusinessId
is a unique identifier representing the supplier's business in the TradeAware system. This identifier is used to establish a direct link between a transaction and its immediate supplier, ensuring their required data can be captured against a Due Dilligence Statement.
Transaction Statuses
Transactions progress through various statuses during their lifecycle, from creation to final processing in the EU Information System (EU TRACES) as a Due Diligence Statement. Below is an overview of each status:
DRAFT: The transaction is in draft mode, still being prepared and not yet submitted to the for processing.
TO_SUBMIT: The transaction is marked as ready to be submitted to the EU Information System.
PROCESSING: The transaction is currently being processed by the EU Information System.
SUBMITTED: The transaction has been submitted for validation in the EU Information System but does not yet have a DDS reference or verification number.
COMPLETED: The transaction was successfully validated and accepted by the EU Information
WITHDRAWN: The transaction was withdrawn from the EU Information System and is no longer active.
Transaction Management accommodate for both Operators and Traders needs
Operators and traders play distinct roles in the compliance chain under the EU Information System (EU TRACES).
Operators are the first person to make a product available on the EU market. Their transactions focus on direct traceability to immediate suppliers, requiring a supplierBusinessId
but excluding ddsReferences
.
Traders are those to subsequently move products already available in the EU market around it. Their transactions emphasize linking products to upstream DDS references, requiring ddsReferences
but not supplierBusinessId
. It is important to avoid including both supplierBusinessId
and ddsReferences
in a single request to prevent errors and maintain traceability integrity.
Why the Distinction? The EU TRACES design separates these responsibilities to reduce duplication of effort. An entity must choose between associating a transaction with
supplierBusinessId
orddsReferences
, not both. This ensures that existing available information in the EU TRACES system does have to be re-entered.Common Challenges and Clarifications:
If both
supplierBusinessId
andddsReferences
are included in a request, the system will throw an error. This is because EU TRACES does not require both properties together for a single component.Users should ensure they store supplier and DDS information separately in their systems if needed for later traceability.
Use Case 1: Managing Compliance with the Transaction API (for Operators)
Business Case:
Operators need a reliable way to link different type of orders from their ERP systems to compliance workflows. Ensuring accurate traceability at the point of importation is critical for meeting EUDR requirements.
Solution:
The Transactions API allows operators to link order data directly to their immediate suppliers, enabling efficient management of Due Diligence Statements and compliance workflows.
Create a New Transaction as an Operator:
Description: This is for the entity that is the first to import goods into the EU. Operators are responsible for ensuring that products meet EUDR compliance at the initial point of entry into the EU market.
Key Requirements:
supplierBusinessId
is required to link the transaction to the immediate supplier.ddsReferences
should not exist in the request body.The focus is on maintaining traceability to the immediate supplier rather than upstream DDS references.
Steps to Implement:
Retrieve a list of suppliers:
Endpoint:
GET /business-connections/suppliers
endpoint to fetch supplier details.Important: When linking a transaction to a supplier, you can use any of the following identifiers: EORI, VAT number, email, or the
customData
field if none of the other identifiers are sufficient. We recommend prioritizing EORI or VAT for better traceability and compliance alignment.Example Request:
This returns a list of all the business connections that have you as
sourceBusiness
with the data of your suppliers intargetBusiness
(for each item in the list). Check whatsourceBusiness
andtargetBusiness
mean in our API reference for business connectionsYour
{businessId}
can be found in thesourceBusiness
field underid
.Your supplier's unique identifier (
id
) is located in thetargetBusiness
field.
Create a transaction with supplier-linked components:
Endpoint:
POST /businesses/{businessId}/transactions
Example Request:
List all transactions:
Endpoint:
GET /transactions
Example Request:
Update an existing order:
Endpoint:
PATCH /transactions/{transaction_id}
Example Request:
Use Case 2: Forwarding Upstream DDS References for Traders
Business Case:
Traders must comply with regulatory requirements by ensuring traceability of DDS references for each transaction. Forwarding upstream DDS references can be complex when dealing with multiple components.
Solution:
Use the Transactions API to include DDS references in transaction components, ensuring compliance and transparency.
Create a New Transaction as a Trader:
Description: This is for entities that make relevant products available on the market. Traders are involved in the subsequent movement of goods and must link products to their immediate suppliers.
Key Requirements:
supplierBusinessId
should not exist in the request body.ddsReferences
should be provided for traceability.The focus is on associating products with upstream DDS references.
Steps to Implement:
Retrieve a list of suppliers:
Endpoint:
GET /business-connections/suppliers
Example Request:
This returns a list of all the business connections that have you as
sourceBusiness
with the data of your suppliers intargetBusiness
(for each item in the list).Your
{businessId}
can be found in thesourceBusiness
field underid
.
Create a transaction with DDS references:
Endpoint:
POST /businesses/{businessId}/transactions
Example Request:
Use Case 3: Managing Composite Products
Business Case:
Managing products composed of multiple components while ensuring compliance requires a structured approach to track each material’s origin and DDS references.
Solution:
Use the Transactions API to associate components with composite products, maintaining traceability for compliance.
Steps to Implement:
Create a composite product with multiple components:
Endpoint:
POST /businesses/{businessId}/transactions
Example Request:
Add a component to a transaction:
Endpoint:
POST /transactions/{id}/components
Example Request:
Update a component to modify DDS references:
Endpoint:
PATCH /components/{id}
Example Request:
Use Case 4: Submitting Transactions to TRACES
Business Case:
Businesses need to ensure transactions are ready for submission to the EU Information System (TRACES). This step is critical for regulatory compliance but requires careful validation and preparation.
Solution:
Use the submit
endpoint to update a transaction’s status to TO_SUBMIT
, signaling its readiness for TRACES submission.
Steps to Implement:
Submit a transaction:
Endpoint:
PUT /transactions/{id}/submit
Example Request:
Example Response:
Use Case 5: Linking Transactional Data to Compliance Workflows (e.g., Batches, Shipments)
Business Case:
Businesses need to link transactional data, such as batches, shipments, Purchase Orders etc. to compliance workflows to create a robust audit trail and maintain regulatory compliance. Without this linkage, inefficiencies and compliance risks can arise.
Solution:
Leverage the customData
field in the Transactions API to associate SOs with POs for seamless traceability.
Create a Batch linked to a purchase order:
Endpoint:
POST /businesses/{businessId}/transactions
Example Request:
Last updated