How it works
The import execution spine, in the order the goods move.
Shipeezi models retail import as a chain of linked objects: PO line, SSCC carton, booking, container, leg and event. Read it once and the whole product makes sense.
The object chain
Six objects, in the order the goods move.
Mobile record builders collapse these into one row, which is why "is this a sea booking or a CFS booking" is a question. Shipeezi keeps them separate and links them.
PO line
SKU, quantity, HS code and country of origin. Line identity is per line, because one SKU routinely splits across destinations.
SSCC carton
Minted at packing. Holds its SKU contents as rows, nests to a pallet SSCC, and rolls provenance up from the lines inside it.
Booking
A supplier's request to move cargo against PO lines, carrying a mode. CFS is a facility role, not a booking type.
Container
Built by the LSP or CFS from one or more bookings. Vessel, voyage and seal belong here, not on a pending supplier booking.
Leg
An ordered chain. Each leg has a mode, an operator entity, a milestone template, and plan-versus-actual events.
Event
Planned, estimated and actual, normalised onto the leg regardless of source: carrier API, forwarder, or a scan at the dock.
Why the leg spine matters
Mode lives on the leg. Direction is derived.
One shipment, many legs
When goods travel sea inbound to a hub and then air outbound, that is one shipment with two legs, not two cloned shipments. Direction of travel is a property of a leg relative to the hub, derived from the sequence, not a flag copied onto a duplicate record.
Dispatch is a road leg
There is no separate dispatch concept to reconcile. A door-to-door move is a sea leg plus a road leg. When a mode is added, a leg is added. The shipment is never cloned, so the carton trace stays continuous across the whole journey.
The leg is the spine
A shipment is an ordered chain of legs.Multimodal is a sequence, never a duplicate.
This is the direct fix for two live operational holes: treating a CFS booking as a mode, and cloning a shipment to add a second mode.
Five profiles
Who you are decides your workspace. What you service decides your legs.
Entity profile is who you are. Service scope, the mile and the mode, lives on shipment legs. An operator's profile is simply which leg types and modes it can service, which drives assignment and matching.
Retailer / shipper
Creates the POs, owns the buy, opens on an exception queue rather than a grid.
LSP / 4PL
Operates for many clients in one workspace, with a header client switcher and per-client data partitions.
Supplier
Manufactures, books against POs and packs SSCC cartons inside the retailer's rules.
CFS / consolidator
Receives and scans cartons at the dock, consolidates, and reconciles discrepancies at the source.
Forwarder
Quote, book, document and track air and ocean, with execution handed to CargoWise.
Navigation is derived, not hand-built
Each surface is composed from the entity profile, the permission catalog and feature flags. Per-tenant labels sit on top of one canonical internal name, so one client calling it a PO and another calling it an order is a display setting, not a second model.
By exception
Open on what is wrong, not on a wall of rows.
Detect
ETA slippage against the milestone plan, PO changes hitting draft bookings, tolerance breaches, free-day burn-down.
Draft
Draft the supplier notification, propose a booking amendment, recommend a consolidation.
Act, gated
Auto-apply safe changes at a level set per capability, logged and reversible, with an explicit agent-action audit trail.
See the spine on a real order.
We will walk a PO from line to leg and show where each validation fires.