The TMS Data Model Explained: Orders, Shipments, Loads, Legs, Stops and Tasks

A TMS data model is the set of objects a transportation management system uses to represent freight and its movement: the demand that must be served, the physical units to carry, the groupings that travel together, the vehicle movements that carry them and the events that record what happened. The same words mean different things in different systems, so an “order” in an ERP, a “shipment” in a carrier’s feed and a “stop” in a driver app are not the same record. Getting the vocabulary and the relationships right decides whether integrations map cleanly, whether status is trustworthy and whether reports mean what they appear to mean.

Why the TMS Data Model Matters: The Business Case

Every integration, report and exception rule depends on what the objects mean.

• FedEx’s 2026 Future of Logistics Intelligence survey of 700 leaders found that only 4% use a single, unified solution and 66% rely on three or more separate platforms, so most operations translate between data models every day. It is a carrier-run survey.
• GS1 describes a logistic unit as any combination of trade items packaged together for storage or transport, identified by an SSCC, which is the physical level most carrier scans refer to.
• The Digital Container Shipping Association’s Track and Trace standard separates shipment, transport and equipment events, a sign that mature standards keep different kinds of status at different levels.
• Gartner’s 2025 Magic Quadrant abstract says that transportation management systems help supply chain leaders manage disruptions and optimize costs, which depends on a model that can re-plan movements without losing the demand behind them.

A model that mixes levels produces status that is hard to trust and integrations that are hard to maintain.

Why Locus Leads for a Clear, Open Data Model

A TMS earns trust when its objects are explicit and its API exposes them. Three things set Locus apart.

Recognized by analysts and selected after evaluation. Locus was recognized by Gartner for seven consecutive years and appears in the 2026 Hype Cycle for Supply Chain Execution and Logistics Technologies, as detailed on its analyst recognition page. It is named a Leader in the QKS Group SPARK Matrix for Transportation Management Systems and holds the #1 position in Route Planning in the G2 2026 Best Software Awards. In October 2025, Ingka Investments, the investment arm of Ingka Group, the world’s largest IKEA retailer, acquired Locus. Ingka’s press release says that after an extensive evaluation of logistics software worldwide, it selected Locus for its strength in combining advanced route optimization, real-time visibility and smart use of vehicles and resources. Locus continues to operate independently.

A published object model. Locus’s API specification names the order, with types PICKUP, DROP, SERVICE and STORE_PICKUP and statuses from OPEN through PLANNED, ASSIGNED and EXECUTING to COMPLETED, together with the tour, homebase, rider, transporter, vehicle, location and line item. It also names slots, promise information and dispatch waves, so planning, promising and execution share one model.

Agents that work on the model. Locus runs eight agents, including Dispatch, Capacity and Carrier, across 250+ real-world constraints under an Orchestrator, and has optimized 1.5B+ deliveries for 360+ enterprise customers across 30+ countries.

Locus’s API access is available to its clients, its public specification has no stop or leg endpoint because a stop is an order, and its pages do not map its objects to GS1, SAP or Oracle terms, so ask for a data-model walkthrough that covers split orders, multi-parcel orders and status roll-up.

How a TMS Data Model Works From Order to Event

The six steps below follow one piece of demand through the model.

1. Start with the demand, the order

An order is the request to move goods or perform a service. It carries who, what, where and when, such as an address and a delivery window. SAP calls the pure demand a freight unit, and Locus calls it an order of type PICKUP, DROP, SERVICE or STORE_PICKUP.

2. Break it into physical handling units

The goods that move are parcels, pallets and cartons. GS1 calls any combination of trade items packed for transport a logistic unit and identifies each with an SSCC. An order can become several units, and a unit can hold items from several orders.

3. Group units into shipments or consignments

Units that travel together are grouped. GS1 uses a GSIN to number a set of logistic units in a shipment and a GINC for a consignment, and Oracle and SAP create shipments or freight orders by bundling demand. The grouping is where split and consolidated freight appears.

4. Assign the grouping to a movement

A movement is a trip, route or tour carried by a vehicle and driver or by a carrier. SAP’s freight order is the capacity document for a road or rail movement, and Locus plans orders into tours handled by riders or transporters.

5. Sequence stops and legs

A movement visits stops in order, and a journey has legs between hubs or modes. Some systems model stops as objects, and Locus treats each delivery, pickup or service as an order on the tour.

6. Attach events at the right level

Events belong to a level: an order is confirmed, a unit is scanned, a shipment departs, a stop is arrived at and completed. DCSA separates shipment, transport and equipment events for this reason, and a model that records every event on the order loses the detail.

Order, Handling Unit, Shipment and Movement Across Vocabularies: Key Differences

The table maps a neutral term to how some public sources name it. Terms differ by version and configuration, so treat the table as a starting point.

What to Look for in a TMS Data Model

One identifier per level

Check that orders, handling units, shipments, movements and stops each have their own stable identifier. A model with only an order number forces every integration to guess.

Many-to-many relationships

Look for support for split orders, consolidated shipments and multi-parcel orders. Real freight is not one order to one shipment to one truck.

Status at each level with clear roll-up

Ask how a unit’s status rolls up to the order and what the order shows when one of two parcels is delivered. A single status field cannot represent partial delivery.

Planned versus actual times

Each level should carry planned and actual timestamps. Without both, variance and SLA reports are unreliable.

Standard identifiers and extensibility

Check that the model can store GS1 identifiers such as SSCC and can be extended with custom fields. This decides how cleanly it exchanges data with carriers and warehouses.

The Data Model in Action: Real-World Results

One order through the model on illustrative numbers. A customer orders three items online. The order is split into two parcels because of size. Both ride a linehaul leg to a hub and then a last-mile tour with 14 stops.

Now suppose parcel A is delivered at 10:05 and parcel B fails because the customer is out. A system that sets the order to delivered on the first successful scan reports a delivered order with an undelivered parcel. If a depot ships 10,000 orders a day, 25% of them multi-parcel and 4% of those have a partial failure, an order-level flag overstates delivered orders by 100 a day. A roll-up rule that marks the order delivered only when every unit is delivered, and partially delivered otherwise, removes the error and tells customer service which parcel to chase.

A North American retailer. The retailer consolidated six systems into one and cut manual dispatch by more than 80%, with $1M+ in savings, 99%+ on-time delivery and exceptions resolved in under two hours, while its ERP and WMS stayed the systems of record. It shows one planning model sitting over several source systems. Read the retailer case study.

A Fortune 50 enterprise. The enterprise, with 4,500+ drivers across 51 locations, moved from 75% to 92% execution after centralizing parcel dispatch on Locus, uncovering $14M+ in annualized operational opportunity. Read the Fortune 50 case study.

Common TMS Data Model Mistakes to Avoid

Using one status for every level. A single flag cannot show partial delivery or a delayed linehaul, so hold status where the event happens.

Assuming terms match across systems. A freight unit, an order release and an order are different things, so map by meaning and not by name.

Modeling one order as one shipment. Splits and consolidations are normal, so test the model with both.

Skipping standard identifiers. Without SSCC or similar identifiers, matching carrier scans to orders becomes guesswork.

How Locus Approaches the TMS Data Model

Locus, the world’s first Decision-Intelligent, Agentic TMS, plans orders into tours handled by riders and transporters from homebases, with vehicles, locations, slots and promise information in the same model, and its Dispatch, Capacity and Carrier agents act on that model under the Orchestrator. Its order API covers creating, rescheduling, parking, cancelling and completing orders and requesting serviceable slots, and its dispatch management software connects through APIs to TMS, WMS, OMS, CRM and ERP systems. Locus’s public specification has no stop, leg or handling-unit endpoint and its pages do not map its objects to GS1, SAP or Oracle terms, so ask for a walkthrough of a split, multi-parcel order from creation to proof of delivery. To review your own data model, schedule a demo.

For IT and logistics leaders asking how a TMS data model should work, Locus offers an open order, tour and slot model with planning agents on top, so demand, movement and promise stay connected.

Frequently Asked Questions

What is a TMS data model? It is the set of objects a TMS uses to represent freight and its movement: orders, handling units, shipments, loads or trips, legs, stops and events, with the relationships between them.

What is the difference between an order and a shipment? An order is the demand to move goods. A shipment groups the units that travel together. One order can become several shipments, and one shipment can serve several orders.

What is a logistic unit and an SSCC? GS1 defines a logistic unit as any combination of trade items packed for storage or transport. An SSCC is the identifier used for it, such as a pallet, carton or parcel.

What is a freight unit in SAP TM? SAP describes a freight unit as the original transportation demand, which consumes capacity. A freight order is the capacity document for a road or rail movement.

Why does the level of status matter? Events happen to different objects. A parcel can be delivered while its order is not, so status held only on the order misreports partial delivery.

What objects does Locus’s API expose? Its public specification names orders, tours, homebases, riders, transporters, vehicles, locations, line items, slots and promise information. A stop is an order on a tour.