Shipping and outbound operations¶

Move an order out the door: create a shipment, load its LPNs by scanning, manifest it with a carrier, generate labels and documents, dispatch it, and track it to delivery — all from the Shipments page.

A shipment links one or more orders, their LPNs, a carrier, and the tracking documents. It moves through a fixed set of statuses from planning to delivery, with every step written to the shipment's own audit log.

Shipment lifecycle¶

A shipment moves through these statuses, tied to what's happening with the carrier:

stateDiagram-v2
    [*] --> PLANNED: Create
    PLANNED --> LOADING: Start loading session
    LOADING --> PLANNED: Abort loading
    LOADING --> MANIFEST: Complete loading + manifest
    PLANNED --> MANIFEST: Manifest directly
    MANIFEST --> DISPATCHED: Dispatch
    DISPATCHED --> IN_TRANSIT: Carrier tracking
    IN_TRANSIT --> DELIVERED: Proof of delivery
    PLANNED --> CANCELLED: Cancel
    LOADING --> CANCELLED: Cancel
    MANIFEST --> CANCELLED: Cancel

The shipments list page¶

Go to Shipments in the sidebar to open the list view at /shipments.

Filters¶

The list supports filters with bracket notation. Filter state is persisted to the URL, so any view you create can be shared, bookmarked, or reopened with a browser refresh.

The legacy ?status=PLANNED format is still honored and treated as eq. By default the list excludes DELIVERED shipments to keep the active workload front-and-center; toggle the Show delivered filter to include them.

Statuses at a glance¶

The list color-codes each shipment by status:

Bulk actions¶

Select rows with the checkboxes to act on several shipments at once:

Creating a shipment¶

From the shipments list¶

1. Choose Create Shipment on the Shipments page.
2. Choose a creation mode:
   • From orders — pick one or more READY_TO_SHIP orders
   • From staging — consolidate LPNs already sitting in a staging area
   • Empty — create a shell shipment and add orders or LPNs later

3. Enter the shipment details:

   • Customer — auto-filled when created from orders
   • Origin — a warehouse location or a party address
   • Destination — the customer's address, or another warehouse
   • Carrier — optional at creation; you can assign it later
   • Requested pickup date

   Zora generates a shipment number (SHP-XXXX) automatically, and the shipment opens in PLANNED status.

API: POST /shipments — create from orders; POST /shipments/from-staging — create from a staging area consolidation.

From an order detail page¶

On an order in READY_TO_SHIP status, choose Add to Shipment to either create a new shipment with this order, or attach it to an existing PLANNED shipment for the same customer.

Adding orders to an existing shipment¶

From a shipment detail page, choose Add Orders and select the orders to attach.

API: PUT /shipments/:id/orders — body { orderIds: string[], force?: boolean }.

Delivery stops¶

A shipment carrying orders for more than one consignee makes more than one stop. Each stop is a stored record on the shipment rather than something recomputed from addresses every time the page opens, and you set the order the driver visits them in. That sequence is what the bills of lading number themselves against, so it is the route the paperwork describes.

Open a shipment and look at the Orders tab: Delivery Stops sits above the order cards, one numbered row per stop, showing the consignee, how many orders and LPNs are on it, and the BOL revision once one has been issued.

How stops are built¶

Stops reconcile automatically whenever orders join or leave the shipment:

• An order you have already placed on a stop keeps it. Your assignment wins and is never re-derived from the address.
• A newly attached order is grouped by consignee — the same rule the bill of lading uses — and joins the stop its group already sits on, or a new stop appended at the end.
• A shipment with an explicit destination set on it is a single stop, whatever the orders say.
• A stop left with no orders is removed, unless a bill of lading was already issued for it.

Orders converted from a multi-stop delivery request arrive in the sequence the customer asked for.

Reordering stops and moving orders¶

While the shipment is PLANNED or LOADING:

Once the shipment is manifested neither orders nor stops can change, and the section says so instead of offering the controls.

LPN-to-shipment loading workflow¶

Loading is the scan-driven process of moving picked LPNs from staging onto a specific shipment. It runs as a loading session with real-time validation, barcode verification, and optional supervisor overrides.

Starting a loading session¶

1. Open the target shipment and choose Start Loading.

   Zora creates a loading session, locks the shipment against concurrent edits, and moves it to LOADING status.

The loading dashboard shows the expected LPNs (from attached orders and any pre-added LPNs), the loaded count against the total, weight and cube progress, and the session event log.

API: POST /shipments/:id/loading/start.

Scanning LPNs¶

1. Scan the LPN label with the barcode scanner.

   Zora checks that the LPN exists and is in the current warehouse, that its status is AT_STAGING or otherwise loadable, that its contents belong to the shipment's customer, and that it isn't already loaded on another active shipment.

The scan comes back at one of three levels:

API: POST /shipments/:id/loading/scan-lpn.

Customer mismatch during loading (v1.6)¶

If a scanned LPN's contents belong to a different customer than the shipment, the scan is blocked with an error. There is no "force-load" path from the scanner — this is deliberate. LPNs belonging to the wrong customer must be returned to staging and routed to the correct shipment.

Checking an LPN before loading it¶

To confirm an LPN is loadable before committing it, call POST /shipments/:id/loading/validate-lpn. It runs the same checks as a real scan, but doesn't load anything.

Removing an LPN from an active session¶

If you loaded an LPN by mistake, choose Remove next to its row in the session.

The LPN returns to AT_STAGING status and drops out of the session counters.

API: DELETE /shipments/:shipmentId/loading/lpn/:lpnId with { reason }.

Completing the loading session¶

1. Once the counter reads complete — every expected LPN scanned — choose Complete Loading.

   The session closes and the shipment moves out of LOADING, ready for manifest. Zora issues a bill of lading automatically against the finished load, one per delivery stop, and offers you signature capture on the same device — see Bill of lading.

API: POST /shipments/:id/loading/complete.

Supervisor override for partial loads¶

If a shipment has to ship short — a missing LPN, damaged goods pulled off the truck — a user with the shipment:update permission can complete the session with a supervisor override.

1. Choose Complete with Override.
2. Enter a reason. It's required, and it's written to the audit log.
3. Confirm.

API: POST /shipments/:id/loading/supervisor-override with { action: 'complete_partial', reason }.

Aborting a session¶

To cancel a loading session without saving progress, choose Abort Loading. Every scanned LPN returns to AT_STAGING and the shipment reverts to PLANNED.

API: DELETE /shipments/:id/loading/abort with { reason }.

Carrier assignment and booking¶

Assigning a carrier¶

You can assign a carrier at creation, or any time before manifest.

1. Open the shipment and choose Assign Carrier.
2. Select the carrier from the dropdown — carriers are configured in Administration → Carriers.
3. Select a service level (Ground, Express, LTL, and so on — pulled from the carrier's configured services).
4. Enter a carrier reference number if the booking was made externally. Optional.

API: PUT /shipments/:id/tracking.

Booking / manifesting¶

Once loading is complete and a carrier is assigned, generate the manifest to mark the shipment ready for carrier pickup.

1. Choose Preview Manifest to review the aggregated LPN contents.
2. Check the totals — weight, cube, piece count, declared value.

3. Choose Manifest Shipment.

   You can also enter a Manifest number (Zora generates one if you leave it blank), a Carrier reference (the carrier's internal booking ID), and a Bill of lading number for LTL or freight shipments.

   The shipment moves to MANIFEST status, every LPN on it moves to SHIPPED and clears out of staging, and the shipment is ready for carrier pickup.

API: GET /shipments/:id/manifest-preview, POST /shipments/:id/manifest.

Dispatch¶

When the carrier picks up:

1. Choose Dispatch on the shipment detail page.

2. Enter or confirm the Tracking number (pre-filled if one is already set), the Actual pickup date/time (defaults to now), and any Notes.

   The shipment and every attached LPN move to DISPATCHED.

API: POST /shipments/:id/dispatch.

Labels and manifests¶

Shipping labels¶

Labels come from the Fabric.js template editor, a drag-and-drop designer for carrier-compliant labels, BOLs, packing slips, and custom forms.

1. From the shipment detail page, choose Generate Label.
2. Select a template, or design one in Administration → Templates.
3. Preview the rendered label — its fields (tracking number, addresses, barcode, LPN counts, weight, customer PO, and so on) are already bound to the shipment's data.
4. Choose Print or Download PDF.

Templates are reusable across shipments. Zora ships with:

• A 4×6 shipping label (ZPL-friendly, barcode-first)
• A letter-size packing slip with itemized contents
• A BOL / Straight Bill of Lading for LTL
• Custom carrier-specific labels

Manifests¶

The manifest is one document covering every LPN and line item on the shipment. Generate it with Manifest Shipment — see Booking / manifesting above.

Download it as a PDF from the shipment detail page; Zora also attaches it to the shipment's document list automatically.

Shipment documents¶

Zora files issued and signed BOL revisions here automatically — see Bill of lading. Upload anything else (customs paperwork, inspection reports, carrier-supplied copies) from the Documents tab.

Documents are scoped to the shipment's customer, so they're visible in billing and the customer portal too.

API: GET /shipments/:id/documents (list), POST /shipments/:id/documents (upload, multipart), GET /shipments/:id/documents/:docId/download, DELETE /shipments/:id/documents/:docId.

Bill of lading¶

Every shipment has a VICS Uniform Straight Bill of Lading that the platform builds from the shipment itself. Consignee, carrier, commodity lines, weights, and warehouse branding are read off the shipment and recomputed every time the document is opened, so it tracks the freight as it is added. It exists from shipment creation — trailer, seal, and PRO are blank until someone fills them in.

Open it from the shipment detail page: Documents tab → Open BOL.

Derived values and overrides¶

The form is derived-plus-override:

• Everything the platform already knows is recomputed from the shipment on every read.
• Anything you type is saved as an override and stays put. A deliberately blank override is kept as a blank rather than falling back to the derived value.
• Each edited field carries a restore control that drops the override and brings the derived value back — POST /shipments/:id/bol/reset.

Fields are grouped to match the printed form: Header, Ship From, Ship To, Third Party Freight Charges Bill To, Carrier, Freight Charge Terms, and Trailer Loaded / Freight Counted, plus the two freight tables (Customer Order Information and Carrier Information).

Four fields write back to the shipment rather than living only on the BOL, so billing and the dispatch screen keep reading the same values:

Trailer loaded / freight counted¶

The two attestation boxes at the foot of the form record who did the physical work, and they are the only fields on the BOL that describe the handover rather than the freight. Both are now fillable in the editor and print as ticked boxes:

Each group takes one tick, never two, matching the printed form. Both are left blank on a draft and stay blank until someone sets them — whether the shipper or the driver loaded the trailer is not known until the trailer is loaded, and pre-selecting an answer would put an unverified claim on a document that gets signed.

Planned load vs. actual load¶

Before anything is loaded, the freight tables describe the planned load derived from the order lines. Once LPNs are on the shipment they describe the LPNs actually loaded. The panel above the form states which basis is in play.

The editor raises amber warnings for conditions that would produce bad paperwork, including:

• No consignee resolved — Ship To must be filled in before printing
• No carrier assigned, so carrier name and SCAC are blank
• Hazmat freight on the shipment — confirm proper shipping name, UN number, and emergency contact
• Loaded handling units allocated to no order, so they appear on no bill of lading
• More order or commodity lines than the eight rows the form prints — attach a continuation sheet

Customer order number and additional shipper info¶

Two columns of the Customer Order Information table are filled from outside the order itself.

Customer order number prints the customer's own purchase order where the platform holds one. The PO is captured on the receiving order the outbound order came from, so it appears on the BOL whenever that link exists. This is the column the consignee reconciles against, and a Zora-generated order number means nothing on their end. Where no PO is on file the column falls back to the platform's order number rather than printing a blank — an unfamiliar reference still beats no reference when someone is matching paperwork to a delivery on a dock.

Additional shipper info prints the distinct lot values on the order, in first-seen order, so a ten-line order of a single lot prints that lot once. The cell is left empty when no line carries a lot.

Multi-stop loads¶

More than one delivery stop means a multi-stop load, and each consignee gets their own bill of lading, so each signs only for the freight coming off the truck at their dock. A stop selector appears above the form; GET /shipments/:id/bol/stops lists them, and every BOL endpoint accepts an optional ?stop= parameter.

The stops the editor tabs through are the shipment's stored stops, in the order you put them in — the BOL numbers each one against that sequence rather than deriving its own. Reorder a stop after a revision has been issued and the affected documents are re-issued under the new number.

Printing, issuing, and signing¶

Save first — all three actions are blocked while there are unsaved edits.

Signatures are drawn on the operator's device. Either party can sign alone, but a signature is only included if the matching printed name is filled in. Submitting stamps both marks into their blocks on the form, files the signed PDF under the shipment documents, and records who signed and when.

Automatic capture at loading completion¶

Completing a loading session issues a bill of lading automatically — one per stop — against the finished load, so the filed document describes the freight actually on the truck rather than what was planned. Signature capture is then offered on the same device while the driver is standing there.

That prompt is skippable on purpose: loads are also closed out from the office, where there is no driver to sign, and the BOL stays available on the shipment either way.

Tracking¶

Viewing tracking¶

The shipment detail page shows a Tracking panel with:

• Current carrier tracking number
• Bill of lading / MBOL / seal / equipment numbers
• Event history from the carrier (when carrier integration is enabled)
• Estimated delivery date

Updating tracking fields¶

Set or update any of these at any point, from the tracking editor: Tracking number, Bill of lading number (BOL), Master bill of lading number (MBOL) for consolidated freight, Carrier reference, Seal number, Equipment number (trailer or container), and Notes.

API: PUT /shipments/:id/tracking.

Status updates¶

You can move a status manually from the detail page (Mark Delivered, Mark In Transit), or Zora updates it automatically from carrier tracking webhooks when that integration is configured. Every change is recorded in the shipment audit log — your user ID for a manual change, the webhook source for an automatic one.

Shipment audit log (v1.6)¶

Every shipment has an audit log, on its own Audit Log tab on the shipment detail page.

What's recorded¶

• Shipment creation, updates, cancellation
• Order attach/detach events (including any customer-mismatch force-add with the user who confirmed)
• LPN add/remove events
• Loading session start, scan, complete, abort, supervisor override
• Manifest, dispatch, tracking updates
• Document upload/delete
• Status transitions (with prior and new status)

Each entry captures who (user ID and display name), when (ISO-8601 timestamp), what (action type), and details (JSON payload with diff and metadata).

Filtering¶

The audit log view supports filters by:

• Action type (e.g. only show loading-session.* events)
• User
• Date range

Exporting¶

Choose Export Audit Log to download a CSV of the currently filtered entries — useful for compliance reporting and customer dispute resolution.

Cancellation¶

Cancelling a shipment rolls back every downstream effect atomically. It is only allowed for shipments in PLANNED, LOADING, or MANIFEST status.

What happens on cancel¶

1. Any active loading session is auto-aborted
2. All attached orders are returned to READY_TO_SHIP status
3. All attached LPNs are returned to AT_STAGING status
4. The shipment status is set to CANCELLED with the cancellation reason, user, and timestamp recorded
5. A shipment.cancelled event is emitted for downstream consumers (notifications, billing)

How to cancel¶

1. Open the shipment and choose Cancel Shipment.
2. Enter a cancellation reason. It's required.
3. Confirm.

API: POST /shipments/:id/cancel with { reason }.

Returns processing¶

Mobile support¶

The loading workflow works on mobile, and it's the better choice on the floor since the camera does the barcode scanning.

• Start Loading, Scan LPN, Complete Loading, Abort, and Remove LPN are all available from the mobile shipment detail page.
• Tracking update and Mark Delivered are available on mobile for drivers and field staff.

See Mobile workflows for the full mobile picking, packing, and loading flow.

Common shipment scenarios¶

Scenario 1: Same-customer multi-order consolidation¶

1. Create a shipment for the customer.
2. Add every ready order with Add Orders.
3. Pick each order — the LPNs land in the customer's staging lane.
4. Start a loading session and scan all the LPNs.
5. Complete loading, manifest, and dispatch.

Scenario 2: Walk-up order added after loading started¶

1. Attach the new order — the shipment is already LOADING, so use Add Orders the same way.
2. Pick the new order; the LPN lands in staging.
3. Scan the new LPN into the active loading session. Zora expands the expected set automatically.
4. Complete loading once the new LPN is verified.

Scenario 3: Customer mismatch at the order stage¶

1. You try to add Customer B's order to Customer A's shipment.
2. Zora blocks it and shows the customer-mismatch dialog with the mismatch list.
3. Cancel, then create or locate Customer B's own shipment instead.

Scenario 4: Short ship (missing LPN at dock)¶

1. Start loading and scan every LPN you can find.
2. One LPN can't be located — call a supervisor.
3. The supervisor chooses Complete with Override and enters a reason, e.g. "LPN LPN-4421 not located — investigating."
4. The shipment manifests short, and the audit log records the override.
5. Once the LPN turns up, create a follow-up shipment for it.

Scenario 5: Cancel and reship¶

1. The customer changes their address after manifest but before dispatch.
2. Cancel the shipment with a reason like "customer address change — reshipping."
3. The orders return to READY_TO_SHIP and the LPNs return to staging.
4. Update the destination on the order, or create a new shipment with the corrected address.
5. Reload and re-manifest.

Troubleshooting¶

API quick reference¶

Related guides¶

• Packing & shipping SOP
• Load planning
• Order processing
• Mobile workflows
• Carrier administration
• Template editor (labels & BOLs)

Need help?¶