Inside B2B Orders.
How corporate bookings actually work.

The problem it solves

Most of what the platform does is retail-style: one shipment, from port A to port B, tracked as a single unit. Corporate freight-forwarding clients don't book that way. One client relationship might mean one booking that eventually becomes a dozen or more containers, each potentially going to a different destination, each with its own shipper, consignee, and paperwork, all part of the same commercial arrangement.

That's what B2B Orders models: a parent booking record that can hold many containers, running as a genuinely parallel track alongside the standard Shipment flow, sharing the same vessels, voyages, and ports, but never forced through the same one-shipment-at-a-time structure.

Containers only become visible on the platform's live tracking map when someone deliberately links them to a real shipment, never automatically. That's the design choice above in practice, not an oversight.

The lifecycle

An order moves through a clear, linear path. Nothing auto-advances it: generating a document doesn't move the order forward, linking a container doesn't either. Every transition is a deliberate action, whether from the order page, an edit form, or the API, and every change is logged.

Two more status tracks run independently underneath the order itself:

So a single order can genuinely be "confirmed" at the top level while its containers are scattered across different points in their own journeys, which matches how real freight forwarding actually works.

What's actually captured

An order records where a booking came from (email, WhatsApp, phone, portal), the client's own reference number so a booking that started as a WhatsApp message stays traceable back to it, the feeder vessel and voyage, and both ports, though the destination port is often deliberately left blank at the order level, since it genuinely varies per container.

Vessels aren't always a single entity. For tugboat-and-barge operations, the order form has a completely separate section for tug and barge vessel names, because one "vessel" field can't represent that combination. When a container later gets linked to a real shipment, the two are stitched into one string, because the tracking and map layer downstream only understands a single vessel name field.

Each individual container is where the real detail lives: container and seal numbers, size and type (including reefer, open-top, flat-rack, tank), full or empty status, shipper, consignee, notify party, commodity and HS code, dangerous-goods classification, weight and measurement, the liner, and even stowage position, bay, cell, and tier.

Notably, there's no pricing anywhere in this system. No rate, price, amount, or currency field exists on any B2B record. This is a purely operational and documentary system: it manages bookings and paperwork, not billing.

The document engine

This is the most interesting part of the feature. B2B orders generate real, versioned paperwork: Booking Confirmations, Pre and Final Loading Lists, Discharging Lists, Cargo Manifests, and Bills of Lading, plus a set of document types that are upload-only because they originate from external parties, customs forms, work orders, shipping instructions.

A few things make this genuinely solid:

• Two rendering paths, one fallback. Booking Confirmations try to render through a customizable template system first, so admins can actually design how it looks, but if that tool isn't available on the server, it silently falls back to a built-in generator with no external dependency. The feature keeps working either way; only the fanciness is conditional.
• Every document is versioned, and old versions are never deleted. Generate the same Booking Confirmation five times and you get five downloadable versions, each logged. We've seen a real Bill of Lading regenerated seven separate times on one order, every version still sitting there.
• CSV isn't a blanket toggle. Loading and Discharging Lists support CSV export. Booking Confirmations, Cargo Manifests, and Bills of Lading explicitly refuse it, each for its own reason, a summary document doesn't decompose into rows, a legal document has a fixed layout. That's a deliberate call made per document type, not a generic feature flag.
• Row heights are computed before drawing. A long shipper name or cargo description just makes that row taller on the page. Nothing on a generated document is ever silently truncated.
• F4/Folio paper size (215×330mm) is a first-class option, alongside A4, Letter, and Legal, because that's genuinely the common paper size in Indonesian logistics and customs paperwork, not an oversight added later.

One real Bill of Lading, regenerated seven times on the same order. All seven are still sitting there, downloadable.

Uploaded documents, the ones that arrive from an agent, liner, or customs office rather than being generated, share the exact same table, history, and versioning as generated ones. The two are only distinguished by a note on the record, not a separate system. It's one unified document history per order, regardless of who produced the paper.

The supporting cast

• Pre-alerts. Staff pick documents and recipients, and the system sends one email per recipient with every selected document attached, a deliberate choice over spamming one email per file. Contacts without an email address are shown but can't be selected, so nothing silently fails to send.
• Contacts are scoped per order, not global. Each order builds its own list of who needs to be looped in, client team, destination agent, liner contact, finance, which is exactly the pool the pre-alert feature draws from.
• Bills of lading can split one order across multiple BLs, by liner, by destination, however the real shipment needs organizing, with a warning if you try to move a container that's already assigned to a different BL, rather than silently reassigning it.
• A spreadsheet-style grid editor for bulk-editing containers: arrow-key navigation, paste a block of data from Excel and watch it fill across rows and create new ones if needed, right-click to insert or delete rows. It's built to feel like editing a spreadsheet, not a web form.
• Bulk Excel import that reads real-world files tolerantly. In testing against actual sample sheets, the column-matching stayed honest about how messy real files are: it tolerates a known typo in a header, a stray space in another, and deliberately leaves one genuinely ambiguous column unmapped rather than guessing wrong, after a real file turned out to have both a "Destination" and a "Final Destination" column that meant different things.

Built to integrate

Externally, B2B Orders exposes a small, focused REST API: list and fetch orders, create one, update its status, and update a whitelist of general fields. Containers, documents, bills of lading, and contacts are web-only today, not exposed over the API yet. Two webhook events exist, order created and order status changed, fired consistently whether the change came from the web interface or the API, each cryptographically signed so a receiving system can verify it genuinely came from SEALUTION.

Where this came from

This module exists because one real client's operation didn't fit the standard booking flow, and we built the platform to fit them instead of asking them to change. We told that story in full here. This page is the deeper, how-it-actually-works follow-up to that story.