From a CMR note to data exchange between systems. Learn what each part does and how it connects to the rest.
One or a TMS collects the parties, cargo and route.
Hub provides the document, version and event evidence layer.
A PDF is for reading, e-POD confirms receipt and an API connects the workflow to another system.
A consignment note brings together the sender, carrier, recipient, cargo and route. It describes a particular shipment; it is not fleet management software.
Before departure, the office adds the transport parties, loading and delivery locations, and 12 pallets of goods.
An electronic consignment note combines document data with a process for sharing, confirming and keeping its versions. Emailing a PDF alone does not describe this whole workflow.
The recipient records a cargo reservation. The event and its evidence remain connected to the relevant document version.
Electronic Proof of Delivery records what was received, when it arrived, who confirmed receipt and whether there were reservations.
The warehouse confirms receipt and the driver adds a photo of a damaged pallet.
A readable file to download, print or share. It represents a document at a point in time; the format alone does not guarantee an electronic signature or a complete change history.
Fill in the CMR details in the One generator and download a printable copy.
A collection of shipment evidence: content versions, events, confirmations, signatures, photos and reservations. It helps reconstruct the workflow without searching across scattered files.
When reviewing a claim, check the document version at delivery and the photos attached to its confirmation.
A TMS manages transport orders and operations. An ERP supports business processes such as orders and invoicing. They can exchange shipment data with Hub through an integration.
The dispatcher works in their TMS; order details populate a document without being typed again.
The application for people handling a shipment: office staff, drivers and recipients. The public generator creates CMR PDFs. Further application workflows are being developed in private testing.
Prepare a document in the generator; an invitation also gives access to testing the shipment application.
The document and integration layer for One and TMS partners. It provides an API and SDK for document data, versions and event evidence. Regulatory eFTI integrations are in development.
A partner connects their system to Hub to build document workflows within their own interface.
An API defines how programs exchange data and perform operations. An SDK provides libraries and tools that help developers use an API. Neither is a separate driver application.
An integration creates a document and retrieves its version; the SDK helps a partner implement those calls.
A notification sent to a partner system after an event. Instead of repeatedly asking for changes, a system can receive an update and take its next step. Available events and retries depend on the integration.
After delivery confirmation, a TMS can receive an event and update the transport order status.
Electronic Freight Transport Information is a framework for electronically sharing freight transport information with authorised authorities. Its scope differs from preparing an eCMR note or e-POD confirmation.
Information required for an inspection can be shared in a structured way. Hub is preparing this integration; we do not claim completed certification.
A data exchange point between eFTI platforms and systems used by authorised authorities. It belongs to the information-sharing infrastructure; it is not a form where a driver creates a CMR.
In the integration concept, Hub shares the required data scope through a gate with an authorised recipient.