Retail import execution
The retailer's PO, executed once, across the whole chain.
Shipeezi owns the execution layer that collaboration tools and visibility tools skip: PO lines, SSCC cartons, bookings, containers and legs, with every party working the same record.
Retail import execution
From the retailer's PO to the DC door, on one record.
The retailer raises the PO. The supplier packs and books. The LSP consolidates and moves. The CFS receives and scans. Every step writes to the same chain, and nothing is re-keyed between systems.
Raise and import the PO
POs arrive by API, SFTP, email intake or EDI 850. Line identity and HS code come in, and an adapter maps the retailer's fields once.
Pack SSCC cartons
The supplier packs PO lines into cartons, mints the SSCC within the retailer's GS1 prefix, and nests mix cartons to a pallet.
Book against the PO
A booking carries a mode and the cartons it covers. CFS is a facility role on the move, not the booking type.
Receive and consolidate
The CFS scans cartons at the dock, reconciles short and over shipments against the plan, and builds the container.
Move on a leg chain
Sea, air, road and rail legs on one shipment, with plan-versus-actual events normalised from every source.
Prove it at the DC
The SSCC the DC scans matches the record Shipeezi minted, and the ASN agrees with both.
Carton grain
The carton is the moat, and its contents are rows.
A carton inherits nothing implicitly. Every answer about a carton, what is in it, where it came from, which store it is for, is computed from its contents, which is only possible because the contents are rows rather than a free-text label.
Every forwarder and mode
Nobody gets a bespoke model.
Carriers, forwarders, CFS operators and the retailer all work one canonical event spine. Ocean events adopt the DCSA track-and-trace taxonomy with planned, estimated and actual classification. Air and road use mode-appropriate vocabularies. Mapping happens at the adapter boundary, not in the domain.
The network
Invite the whole chain onto the POs.
A connection graph, not a flat directory. Any tenant invites any counterparty. Relationships are explicit: retailer-supplier, retailer-LSP, LSP-client, supplier-CFS, forwarder-carrier.
Portal is free, operating profiles are paid
An invited supplier or a tracking counterparty uses the portal at no cost. An operating profile is the paid tier. Every shipment with an unconnected party is an in-product invite.
Identity is resolved, not duplicated
When two retailers invite the same supplier, both resolve to one entity with two relationships. Email-domain identity and a claim flow stop the network fragmenting into shadow companies.
Managed accounts graduate cleanly
An LSP onboarding a retailer operates on its behalf under a broad grant. When the client stands alone, the grant flips from managed to peer, with all data and relationships intact.
Bring a real PO.
We will show you the carton tree, the dock scan and the leg chain on your own order.