Shipment, Load, Stop and Leg: A Logistics Data Model That Scales

The first version of most transport platforms has one table called shipments, with a truck number, a pickup time, a delivery time and a status. It works until a planner puts three customer orders on one trailer, or a carrier splits one large order across two trucks, or a cross-dock hands goods from a linehaul trailer to a delivery van. Then the same row is asked to describe a contract, a vehicle and a route at once, and every integration downstream starts to disagree.

Separating four entities, the shipment, the load, the stop and the leg, removes most of that disagreement. Each one gets its own identifier, owner and lifecycle, so re-planning a truck never rewrites what the customer was promised, carrier status messages attach to the right place, and freight cost can be allocated back to shipments with arithmetic that finance can repeat.

• Entity definitions: what each record means, which identifiers belong to it, including GS1 GSIN, GINC and SSCC keys, and which fields never move between them.
• Standards mapping: how the model lines up with an X12 204 load tender, an 856 ship notice, a US bill of lading under 49 CFR 373.101 and the Indian e-way bill under Rule 138.
• Worked material: SQL table definitions, a load-splitting incident, a USD ($) and INR (₹) cost allocation and a migration checklist.

Four entities that most TMS schemas collapse into one record

Model the shipment as the commercial promise, the load as one vehicle's trip, the stop as one visit to one place on that trip, and the leg as the part of a shipment's journey that rides on one load. Everything else, from tracking to billing, hangs off those four records and the links between them.

The relationships are what make the model scale. A shipment has one or more legs; each leg rides on exactly one load; a load has an ordered list of stops; and each leg names the stop where its goods are picked up and the stop where they are dropped. Handling units, identified by SSCC, belong to the shipment and travel on whichever leg is active. Nothing in the shipment record names a vehicle, and nothing in the load record names a customer.

• Shipment: goods from one consignor to one consignee, between two addresses, under one set of commercial terms and service promise.
• Load: one trip of one conveyance or equipment unit under one carrier, from first stop to last, whatever it carries.
• Stop: a numbered visit by a load to a location, with a reason such as load, part load, unload or part unload, and planned and actual times.
• Leg: the join between a shipment and a load, naming the pickup stop and drop stop on that load for that shipment's goods.
• Handling unit: a pallet, crate or parcel with its own label, owned by a shipment and scanned at stops.

Ownership of each entity follows the team that decides its content. The table below names the team that creates each record, who may change it after creation, and which document or message it feeds. That last column is the practical test: if two documents disagree, the owner of the record behind them settles it.

Defining the shipment as the commercial promise to move goods

A shipment record should hold only facts that stay true when the truck changes: who sends, who receives, from where, to where, what goods, how many packages, and by when. If a field would change because a planner moved the goods to another vehicle, it belongs on the load or the leg instead.

US regulation gives a useful floor for those fields. Under 49 CFR 373.101, a for-hire motor carrier's receipt or bill of lading must show the consignor and consignee names, origin and destination points, number of packages, description of the freight and, where it affects rating, weight, volume or measurement. Every one of those is a shipment fact; none of them names a tractor, a trailer or a driver.

A shipment data model keeps consignor, consignee, origin, destination, package count, description and rating weight on the shipment record, matching the bill of lading content in 49 CFR 373.101, and identifies it with a 17-digit GS1 GSIN, while vehicle and stop data live on the load and leg.

GS1 offers a matching identifier. The Global Shipment Identification Number, application identifier 402 with seventeen digits including a check digit, is assigned by the seller or shipper to a group of logistic units meant to be delivered together, and GS1 Australia's guidance ties it to goods travelling under one bill of lading. Each unit in that group keeps its own Serial Shipping Container Code, AI 00 with eighteen digits.

• Keep on the shipment: parties, addresses, requested dates, service level, Incoterms or freight terms, goods description, declared packages and weight, GSIN, customer references.
• Keep off the shipment: vehicle number, driver, carrier PRO or LR number, planned stop times, consolidated e-way bill number, trailer seal.
• Version, never overwrite: when a customer changes quantity or address after release, write a new shipment version with a reason, so tender and invoice can say which version they used.

Loads, legs and stops: the physical plan built around shipments

A load is a plan for one conveyance, and it should be cheap to create, split, merge and cancel. Treat it as disposable: a shipment may be planned onto three loads before it moves, and only the legs that actually ran should survive into costing and proof of delivery.

Stops carry the sequence. The X12 204 motor carrier load tender expresses each stop in an S5 stop-off details segment whose first element is the stop sequence number and second is a stop reason code, with values such as LD for load, PL for part load, CL for complete, UL for unload, PU for part unload and CU for complete unload. Modelling stops the same way makes the outbound tender a direct read of the table rather than a translation.

Legs are where cross-docks and transfers become simple. A pallet that runs Chicago to Indianapolis on a linehaul trailer, is cross-docked, and then runs to Louisville on a delivery truck is one shipment with two legs on two loads. The shipment's promised delivery date does not move; each leg has its own pickup and drop stop, and the cross-dock scan closes the first leg and opens the second.

• One load, many shipments: a consolidated multi-stop truckload holds several legs, each with its own pickup and drop stop numbers.
• One shipment, many loads: an over-capacity order split across two trucks becomes one shipment with two legs that run in parallel, each carrying part of the handling units.
• Relay and cross-dock: legs run in series, and a leg may not start before the previous leg's drop stop shows an actual arrival.
• Empty and deadhead moves: a load with stops and no legs is valid; it carries cost but allocates nothing to customers.

Identifiers that survive re-planning: GSIN, SSCC, PRO and EWB numbers

Give each entity an internal surrogate key and store every external number as an attribute with its issuer, never as the primary key. External numbers are reissued, corrected and duplicated across partners; internal keys are not.

The GS1 pair of shipment and consignment numbers maps closely onto this split. GS1's own support guidance says the GSIN reflects the commercial relationship between buyer and seller, while the GINC reflects the forwarder's logistics grouping, and that one shipment can be spread over several consignments while one consignment can carry goods from several shipments. That is the shipment-to-load relationship expressed in identifiers.

Store each external number with its issuer, its type and a validity window. A carrier that reuses PRO numbers after a period, or a portal that issues a new document after cancellation, then cannot collide with an older record. Our guide to governing logistics master data covers the location and party masters these records point at; this article stays with the transactional records that refer to them.

Mapping the model to X12 204, 856 and the Indian e-way bill

Map each outbound document to the entity that owns its content, and generate the document from the model rather than storing it as the model. When the mapping is clean, a re-plan regenerates the load-level documents and leaves shipment-level documents untouched.

In the US, the 204 tender is a load document: its stop loop is the stop table and its order-level detail lists the shipments riding each leg. The 856 ship notice is a shipment document with its own hierarchy, whose hierarchical level codes include S for shipment, O for order, T for shipping tare, P for pack and I for item. The 214 status message reports events against stops and references, and the 210 invoice bills the load or the leg.

India's e-way bill splits along the same line. Rule 138(1) of the CGST Rules requires the Part A information for a consignment above ₹50,000, and Explanation 2 ties consignment value to the invoice, bill of supply or delivery challan, which makes Part A a shipment record. Part B carries the conveyance details, which are load facts, and Rule 138(6) lets a transporter generate a consolidated e-way bill in Form GST EWB-02 for multiple consignments in one conveyance.

• Transfer between vehicles: Rule 138(5) requires Part B to be updated before goods move from one conveyance to another, so a new leg on a new load must trigger a Part B update for each affected e-way bill.
• Handover to another transporter: Rule 138(5A) lets the e-way bill be assigned to another registered or enrolled transporter, which in the model is a new carrier on the next leg's load.
• Validity runs from the shipment's distance: under Rule 138(10), cargo other than over-dimensional or ship-leg multimodal moves gets one day for the first 200 km and one more day for each further 200 km or part, so a 270 km consignment has two days whatever the loads look like.
• Cancellation window: Rule 138(9) allows cancellation within 24 hours of generation if goods do not move, which maps to cancelling a shipment before its first leg starts.

An Indian shipment data model keeps e-way bill Part A on the shipment and Part B on the load leg, because CGST Rule 138(5) requires a Part B update before goods change conveyance and Rule 138(6) allows one consolidated Form EWB-02 per vehicle; road validity is one day per 200 km.

Events belong to stops and handling units, not to the shipment row

Record every status as an immutable event attached to the most specific thing it describes: a stop arrival to the stop, a scan to the handling unit, a temperature reading to the load's equipment. Shipment status is then derived from those events, not typed into a column that the last message overwrites.

The difference shows up the first time a load splits. In the incident below, a flat table with one vehicle number per shipment row meets a breakdown on a three-drop Indian run. The figures and registration numbers are illustrative, but the failure is common wherever Part B updates are driven from a single vehicle field. Our article on detention and penalty under Section 129 covers what happens once goods are stopped.

1. 14:05: load LD-55210 leaves Bhiwandi with consignments C1 for Pune and C2 and C3 for Satara on vehicle MH-04-XX-1234. A consolidated e-way bill covers all three.
2. 19:40: the vehicle breaks down near Khandala. The transporter moves C2 and C3 to vehicle MH-12-XX-5678; C1 waits for repair and stays on the first vehicle.
3. 19:55: the TMS has one vehicle field per shipment row and none for a second truck. The dispatcher updates C2's Part B by hand on the portal and misses C3.
4. 23:10: an officer stops the second vehicle. C3's e-way bill still shows MH-04-XX-1234, so the documents do not match the conveyance, and the goods are held for verification.
5. Control applied: a split now creates load LD-55211 with new legs for C2 and C3. Each new leg emits a Part B update for its own e-way bill before the leg can be dispatched.

The same structure fixes US status messages. A 214 that reports an arrival at stop 2 of a load updates that stop's actual time; every shipment with a leg dropping at stop 2 then derives its delivered status from that one event. Our explainer on the EPCIS event model for multi-partner logistics goes further into what, where, when and why fields for events shared across companies.

Allocating one load's cost back to shipments in dollars and rupees

Allocate load cost to shipments through their legs, using weight times distance for linehaul and fuel, and charging each stop's fee to the legs that use that stop. Only a model with legs and stops can do this without a spreadsheet, because the distance each shipment rode and the stops it caused live there.

The worked figures are illustrative. In the US, one truckload picks up three shipments at stop 1, drops S1 at stop 2 after 220 miles and drops S2 and S3 at stop 3 after 340 miles. Linehaul and fuel total $2,940 and each drop stop carries a $75 stop-off charge. In India, one truck leaves Bhiwandi with C1 for Pune at 160 km and C2 and C3 for Satara at 270 km, with freight of ₹38,000 and ₹1,500 unloading at each drop stop.

Two rules make the table repeatable. A stop charge at a stop shared by several drops is split among those legs by weight, which is why S2 takes $50 of the $75 at stop 3 and S3 takes $25. Rounding is pushed to the last leg on the load, so the allocated totals always equal the carrier invoice to the cent or paisa. Store the allocation key and its version on the load, so a later audit can recompute it exactly.

Load cost allocation through legs divides linehaul and fuel by each shipment's weight times distance ridden and splits each stop-off fee among the legs dropping there; in the worked US load, $3,090 of carrier charges split $1,230, $1,240 and $620 across three shipments with zero rounding residue.

Schema rules the database enforces versus judgement calls in planning

Put structural truths into database constraints and leave operating trade-offs to planners, with software only proposing. A stop sequence can be checked by a constraint; whether two shipments may share a trailer cannot, because it depends on temperature, hazard class, customer rules and cost.

CREATE TABLE shipment (
  shipment_id      BIGINT PRIMARY KEY,
  version_no       INT NOT NULL DEFAULT 1,
  gsin             CHAR(17) UNIQUE,                 -- GS1 AI 402, check digit validated in app
  consignor_id     BIGINT NOT NULL REFERENCES party,
  consignee_id     BIGINT NOT NULL REFERENCES party,
  origin_loc_id    BIGINT NOT NULL REFERENCES location,
  dest_loc_id      BIGINT NOT NULL REFERENCES location,
  package_count    INT NOT NULL CHECK (package_count > 0),
  rating_weight_kg NUMERIC(10,2),
  ewb_no           VARCHAR(20)                      -- India Part A, one per invoice or challan
);
CREATE TABLE load (
  load_id          BIGINT PRIMARY KEY,
  carrier_id       BIGINT REFERENCES party,
  conveyance_no    VARCHAR(20),                     -- feeds e-way bill Part B
  carrier_ref      VARCHAR(35),                     -- PRO or LR number, issued by carrier
  consolidated_ewb VARCHAR(20)                      -- Form GST EWB-02 where generated
);
CREATE TABLE stop (
  load_id          BIGINT REFERENCES load,
  stop_seq         SMALLINT CHECK (stop_seq >= 1),
  location_id      BIGINT NOT NULL REFERENCES location,
  reason_code      CHAR(2) CHECK (reason_code IN ('LD','PL','CL','UL','PU','CU')),
  planned_arrival  TIMESTAMPTZ,
  PRIMARY KEY (load_id, stop_seq)
);
CREATE TABLE leg (
  leg_id           BIGINT PRIMARY KEY,
  shipment_id      BIGINT NOT NULL REFERENCES shipment,
  load_id          BIGINT NOT NULL,
  pickup_seq       SMALLINT NOT NULL,
  drop_seq         SMALLINT NOT NULL,
  CHECK (pickup_seq < drop_seq),
  FOREIGN KEY (load_id, pickup_seq) REFERENCES stop (load_id, stop_seq),
  FOREIGN KEY (load_id, drop_seq)   REFERENCES stop (load_id, stop_seq)
);
CREATE TABLE stop_event (                           -- append only; corrections are new rows
  event_id BIGINT PRIMARY KEY, load_id BIGINT, stop_seq SMALLINT,
  event_code VARCHAR(10), event_time TIMESTAMPTZ, source VARCHAR(20),
  FOREIGN KEY (load_id, stop_seq) REFERENCES stop (load_id, stop_seq)
);

Migrating a flat shipment table without breaking live integrations

Migrate by adding the new tables beside the old one, back-filling one load and one leg per historic shipment, and switching consumers one at a time while a view keeps the old shape alive. A big-bang rename breaks every report, EDI map and carrier portal that reads the flat table.

Start with the outbound documents, because they prove the model. Generate the 204 tender and the e-way bill Part B update from the new tables in parallel with the old process for a few weeks, and compare every field. Then move status ingestion to stop events, then costing, and leave customer-facing tracking until last. The approach in our guide to evaluating a TMS with one difficult transport order works well as an acceptance test for the new model.

A clean shipment model underpins most of the integration and costing topics in our logistics and supply chain library. If you are redesigning a transport data layer, or replacing a TMS whose schema has outgrown a single shipment table, you can describe your flows, carriers and documents through our request for proposal form.