Transaction Management
Last updated
Last updated
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.
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.
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.
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)
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.
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.
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.
Validation Rules:
When a DDS reference is included in a transaction, the system will verify both the DDS ID and the verificationNumber before submission.
If the TRACES API is unavailable or returns an unknown error, new transactions referencing DDS numbers will be rejected with a recommendation to message.
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.
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 or ddsReferences, 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 and ddsReferences 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.
DDS Reference Validation in Transactions API
When referencing a previously submitted Due Diligence Statement (DDS), the API performs validation checks to ensure the provided DDS ID and verificationNumber are correct.
Error Handling:
If the provided DDS reference is invalid or does not match, the API will return:
If the TRACES system is unavailable, new transactions using DDS references will be rejected with an instruction to retry later.
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/suppliersendpoint 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 in targetBusiness (for each item in the list). Check what sourceBusiness and targetBusiness mean in our API reference for business connections
Your {businessId} can be found in the sourceBusiness field under id.
Your supplier's unique identifier (id) is located in the targetBusiness 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:
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 in targetBusiness (for each item in the list).
Your {businessId} can be found in the sourceBusiness field under id.
Create a transaction with DDS references:
Endpoint: POST /businesses/{businessId}/transactions
Example Request:
Note: The system will validate the provided DDS ID and verificationNumber before accepting the transaction.
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:
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:
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: