TMS integration with your website: from order to confirmed delivery
TMS integration with your website is not about adding another ‘shipped’ label. Its purpose is to give the transport department an actionable task and provide the buyer with reliable delivery information. If a store works with several warehouses, its own vehicles and external carriers, a separate process emerges between placing an order and handing it over. That is the process worth describing before choosing software.
A TMS, or transportation management system, helps plan, execute and monitor the movement of goods. But having such a platform does not yet mean that the website promises an accurate delivery date or can handle cancellations. What follows is a practical plan for connecting sales and transport operations, not a review of every feature available in logistics products.
When TMS integration is justified and when a simpler solution is enough
Start with the complexity of transport decisions, not the number of orders. If every purchase becomes one parcel handled by one carrier, that carrier’s standard delivery module may cover the task. A dedicated transportation platform becomes worth considering when you need to consolidate goods, assign trips, account for vehicle capacity or agree time windows with the recipient.
In Oracle’s explanation of TMS, the core scope covers planning, executing and optimizing the physical movement of goods. For a web project, the boundary matters: the website captures the customer’s requirements, while the transportation system checks whether they can be fulfilled. A calculation on the website must not automatically become a confirmed trip.
| Business situation | What to check first | Limits of the solution |
|---|---|---|
| Parcels handled by one carrier | Shipping document and status module | May be sufficient without a TMS |
| Own routes with several stops | Trip and time-window planning | Capacity and assignment rules are needed |
| Mixed delivery from different warehouses | Splitting an order into shipments | A single overall status is not enough |
| External carriers with different terms | Rate and execution confirmation | The customer’s delivery charge and the carrier’s invoice are different |
Separate orders, shipments and trips
An order describes a purchase, a shipment describes a specific set of goods to be transported, and a trip describes the transport work. These objects do not always correspond one to one. One order may travel in two vehicles, while a single trip may carry goods for several buyers. Linking everything through one number without separate identifiers quickly becomes a source of confusion.
A hypothetical example: a distributor sells equipment and consumables. The consumables are ready at one warehouse, the equipment at another. The buyer has agreed to partial delivery. If the website stores only the overall purchase status, the first handover may incorrectly close the entire order. Instead, each shipment needs its own warehouse, list of goods, quantity and status, while the overall result is calculated according to an agreed rule.
Identify the owner of each field
Draw up a responsibility map: where the address is created, where cargo readiness is confirmed, where the carrier is assigned, and who records the handover. An order management system, or OMS, can manage purchase fulfillment; a warehouse management system, or WMS, can manage warehouse operations; and a TMS can manage transportation. Product names are no substitute for checking their actual functions.
Prepare the data and exchange contract before programming
Delivery status synchronization starts with an event dictionary, not colors in the customer portal. ‘Request accepted’, ‘trip assigned’, ‘cargo loaded’ and ‘delivered’ have different meanings. Acknowledging receipt of a request through an API—an application programming interface for data exchange—does not yet prove that a logistics coordinator has approved the transport.
The minimum contract should describe order and shipment identifiers, record version, address, recipient contact details, time interval, weight and dimensions with units of measurement. For specialized cargo, add only the characteristics that are needed: temperature conditions, unloading requirements or access requirements. It is important to define which fields are mandatory and what happens if they are missing.
Do not confuse an event with the current state
An event reports what happened at a particular moment; a state shows the current situation. A late loading notification must not return an already delivered shipment to an earlier state. Store the event time, receipt time and rules for permitted transitions. Conflicts need a separate review path, not silent overwriting.
Also align the reference data for warehouses, delivery types and reasons for failed delivery. Free text such as ‘didn’t get there’ is unsuitable for reliable analytics. It is better to have defined reasons with the option to add a comment: recipient absent, incorrect address, or rescheduling at the recipient’s request. Do not send the buyer’s entire profile to the transportation system if the operation needs only contact details and an address.
Design retries, cancellations and manual exception handling
An unstable connection must not create a second transport task. If the website receives no response, it does not know whether the request was lost or executed. A retry must therefore use the same operation identifier. Idempotency means that repeating the same command does not produce a duplicate business outcome.
AWS guidance on the transactional outbox pattern specifically warns about duplicate messages and event ordering. An outgoing event log helps coordinate a database write and the subsequent transmission of a message. This is a possible architectural tool, not a requirement to use AWS cloud products.
Cancellation is a separate operation
Before an order is handed over to the warehouse, one cancellation rule may apply; after loading, another is needed. Define who decides whether to stop a delivery and how the website receives that decision’s outcome. Until the transportation system has confirmed cancellation, the buyer should not see a definitive ‘delivery cancelled’ message.
Failed exchanges need a review queue containing the object, reason, number of attempts, person responsible and next action. Staff must distinguish between ‘no confirmation’ and ‘transport rejected’. Provide a manual fallback procedure, but record any operation performed outside the system. Otherwise, when the connection is restored, automation will resend a request that has already been processed.
Give the buyer an honest promise and a useful status
An order tracking portal should not reproduce an internal dispatch log. The buyer needs to know what the delivery contains, the expected window, its status and a clear next step. ‘Planning initiated’ is useful to a logistics coordinator, but it is better to explain to the customer that the timing is still being agreed. An approximate forecast must be distinguished from a confirmed interval.
If an order is split, show its shipments separately. If the data has not been updated for a long time, indicate the time of the last confirmation rather than creating the impression of live tracking. A delay notification should include an available action: wait for an update or contact the person responsible. A map with a moving marker is no substitute for reliable operational data.
A Drupal website can provide the customer-facing layer and access rules while leaving transport planning to a specialized platform. The architecture is chosen to fit the process, not the other way around. In the context of developing web systems for business, it is important to assess the portal, integration service and responsibility for logistics decisions separately. Having a CMS does not, in itself, create TMS functions.
Test the integration in a pilot before a full rollout
Limit the pilot to a clearly defined area: one warehouse, delivery method or customer group. At the same time, include more than just successful operations. The goal is to prove that the team can see discrepancies and correct them before volumes increase. Compare the result of every test in the systems on both sides.
- Create a test order with an incomplete address. Make sure it is not accepted for transportation without clarification and that the reason is available to the person responsible.
- Split a purchase across warehouses. Check item quantities, shipment identifiers and the overall status in the portal.
- Repeat the creation command after simulating a timeout. Check that there is still only one transport task.
- Send events in the wrong order. Delivery confirmation must not disappear because of a late loading status.
- Cancel delivery before and after trip assignment. Check approvals, the notification to the buyer and the absence of a duplicate request.
- Disconnect the exchange and restore it. Reconcile accumulated events, manual interventions and the error log.
- Check access permissions: buyers see only their own shipments, carriers see only the operations they need, and administrators see the recorded history of changes.
Agree acceptance criteria before testing: no unprocessed discrepancies in the control sample, visible errors and a person responsible for every exception. Set an acceptable update time separately for different events. A ‘real-time’ label without a measurable criterion guarantees nothing.
What determines implementation timelines, budget and risks
Timelines depend on data readiness and team availability as much as on programming. The plan should include process description, agreement on the contract, test environment setup, development, exception testing, training and a pilot. Until the TMS provider confirms the available API operations, the completion date should be treated as provisional.
In the estimate, separate business analysis, reference data cleansing, connectors, the portal, migration of the required data, automated tests and training. Account separately for the TMS license or subscription, exchange infrastructure, logs, monitoring, paid mapping services if needed, and subsequent API changes. Compare proposals against the same scenarios, not just the connection price.
The main risks are incomplete dimensions, conflicting addresses, delays in third-party services, duplicate commands and unclear authority. Automatic planning will not fix an incorrect weight or an inaccessible approach road. If the data is unreliable, it is safer to start with confirmation by a logistics coordinator and gradually automate proven decisions. Personal data processing terms and contractual obligations should be checked with the relevant specialists.
Start with one manageable transport scenario
A successful connection between a website and a TMS is a clear progression from the buyer’s need to confirmed fulfillment. First define the objects and those responsible, then check the data, retries and cancellations, and only then scale automation. If a simpler module covers the task, a separate transportation platform may be unnecessary.
To prepare for a discussion with GL.ua (Glyanets), put together a diagram of your current process, a list of systems and a few anonymized examples of problematic deliveries. Send the GL.ua team your task for an integration assessment: this will help define the scope of the web component, dependencies on the TMS and the checks needed before launch, without promises detached from your operations.
Just one step to your perfect website
