Inbound Orders: The Manifest That Doesn’t Lie

Every truck that pulls into the dock has a story. The contract says one thing. The driver says another. The pallet labels say a third. The inbound order is where those stories converge — and where, if it’s done right, they get reconciled before the assets become inventory.

Five inbound types

An inbound order has a type that says what kind of arrival it is: standard (a one-off purchase or trade-in), lease return (end-of-lease equipment with chargeback rules on the order), buyback (you sold it, the customer is sending it back), recycling (downstream-only, no resale), or donation. The type describes the commercial nature of the shipment. The workflow the assets run through comes from the contract the order is placed under — the workflow template was chosen when that contract was created, and it is the same for every order beneath it.

Numbers and statuses

Each order gets a number like INB-2026-00017, issued per tenant per year by a database counter that two colleagues creating orders at the same second cannot collide on. The order moves through draft, confirmed, in transit, arrived, receiving, received, and then completed or cancelled. Your team advances the status step by step and can step it back where their role allows. Edit order — client, contract, contact details, expected quantity, planned arrival, references, notes — is available up to Received; after that the order is locked, with the reason on screen, because the record of what arrived should not drift after it arrived.

Manifests

Every inbound order can carry an expected manifest — the line items the client said are coming, imported from Excel or CSV. The manifest is not the truth, it is the claim. Receiving is where the claim gets reconciled against reality: the matching tab shows each line as matched, pending, partial, missing or extra, and pending lines can be bulk-received with one condition when 200 identical machines show up exactly as promised. Export CSV writes the received assets and the still-open manifest lines into one file, for the client who wants to see both columns side by side.

Photo report

Every inbound order has a photo report — a print-friendly view of the photos your operators took at intake, anchored to the order. It is the artefact that prevents the “this Dell had a cracked hinge when it arrived, no it didn’t” argument three weeks later. If the order has no received assets yet, or assets but no photos, the report says so in a visible warning, and printing or saving to PDF asks for confirmation first. An empty report can be useful internally; it should never leave the building looking like evidence.

Where the order came from

An inbound order that started life as a collection shows that collection in its header, so anyone on the dock can check where the goods were promised, planned and delivered before receiving began. If the automatic handoff from a delivered collection failed, the collection page keeps a Create inbound order button until an order is linked — same creation path, no manual re-entry.

Why an order is not a session

An inbound order is the contractual claim. A receiving session is the physical reception. They’re separate entities for a reason — see the receiving-sessions article. The order stays open across multiple sessions if a single shipment arrives in two trucks, and the received-assets tab searches across everything received under the order before it paginates, so the eighth pallet’s serials are as findable as the first’s.