--- title: "Orders" description: "What an Order is (the commercial/billing record grouping shipments), its statuses, the confirm/cancel actions, and why customer fields are inherited from the shipper." url: "https://support.pr-4.orbit.do/en/core-features/orders" locale: "en" lastReviewed: "2026-09-28" --- # Orders What an Order is (the commercial/billing record grouping shipments), its statuses, the confirm/cancel actions, and why customer fields are inherited from the shipper. > **Note:** An `Order` is the commercial record of a customer's booking in Orbit. It groups the cargo moves a customer asked for and carries the customer-side details — who booked, who is billed, and the price — but never the carrier, route or vehicle that actually drives the work. An `Order` answers a single question: *what did the customer book, and who pays for it?* It is the commercial and billing side of a job in Orbit. Each `Order` groups one or more `Shipment`s — the individual cargo moves — and holds the customer, the invoice recipient, the line items and the total price. What an `Order` deliberately does *not* hold is the operational side of the job: the carrier, the driver, the vehicle, the stop sequence, or the rate paid to the carrier. All of that lives on the `Tour`. Keeping the two apart is what lets you re-plan how a job is driven without ever touching what the customer booked or is billed. **Key highlights** * **The commercial record** — customer, invoice recipient, line items and price all live on the `Order`. * **Groups shipments** — one `Order` can hold several `Shipment`s, or none yet if the booking has only just arrived. * **Status follows the work** — an `Order`'s status updates on its own as its shipments progress; you never set it by hand. * **Two clear actions** — you **confirm** a requested order and **cancel** an order; everything else follows automatically. * **Separate from the truck** — the carrier, route and the rate paid for the vehicle live on the `Tour`, never on the `Order`. ## What an Order holds An `Order` carries the commercial facts about a booking: the customer, a separate invoice recipient if one applies, the line items, and the total price the customer pays. When you need to answer “did this booking come in, what did they book, who is billed, and what is the price?”, the `Order` is where you look. If some customer details look empty on an `Order`, they are usually **inherited, not missing**. Contact and address details often live on the linked `Shipper`'s saved record in your address book, and the `Order` reads through to them rather than duplicating them. Open the linked shipper before treating a blank field as a gap. ## How Orders relate to Shipments and Tours Orbit keeps two sides of every job separate: the **commercial** side (what the customer booked and pays — the `Order`) and the **operational** side (who drives it and how — the `Tour`). The two are joined only through the `Shipment`. An `Order` groups one or more `Shipment`s, and each of those shipments is routed onto a `Tour` for execution. There is no direct link from an `Order` to a `Tour` — to move between them, you always go through a shipment. That is why, to find the `Order` behind a tour, you open one of the tour's shipments: each `Shipment` names the `Order` it belongs to. For the fuller picture, see the **Shipments** and **Tours** articles. ## Order statuses An `Order`'s status is a summary of the work underneath it, re-calculated automatically from its shipments. You move an order along by taking actions and by driving its tours — the status simply keeps up. In Orbit MissionControl the orders list groups orders into sections that mirror these states (**Requests**, **Confirmed**, **Completed** and **Cancelled**). | Status | What it means | | ------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `Requested` | A booking has come in but has not yet been accepted — for example a self-service booking through Orbit Hub awaiting your confirmation. It stays here until you confirm it. | | `Confirmed` | The order has been accepted and its shipments are live and being worked. | | `Waiting for Tour Review` | At least one of the order's shipments has finished its tour and is awaiting your review. | | `Completed` | Every shipment that counts towards the order has been delivered. | | `Undeliverable` | Every one of the order's shipments has ended and at least one of them has no cargo left to move, because the goods on it were written off. Read through the API as `failed`. | | `Cancelled` | The order was called off. | The exact wording of these labels can be tailored per organisation and language, so what you see may differ slightly from the terms above. ## The actions you take You work an `Order` through two actions in Orbit MissionControl: * **Confirm Order** — accepts a `Requested` order and turns the booking into a live `Shipment` you can then plan onto a `Tour`. Orders you create yourself start out already `Confirmed`. * **Cancel Order** — calls the order off, and can refund any payments already taken. If the order has routed shipments, Orbit asks how the affected tours should be updated. For an order with shipments, you never edit its status directly: there is no status field to set. Confirming, cancelling, and the progress of the order's shipments and tours are what move it along. A confirmed order with no shipments, such as a box rental, a box sale or a recycling brokerage, is the exception: use Complete Order, wherever you act on the order, its detail page or its context menu in the orders list, to move it to Completed yourself, since there is no shipment to derive that status from. This is final and hands the order to accounting. ## Example Spaceport Shipping Co. in Lisbon books a delivery of two mixed pallets from Madrid to Lyon. Orbit creates an `Order` that groups the two `Shipment`s, records Spaceport as the customer and holds the agreed price. The booking arrives as `Requested`; an operator confirms it, and the order moves to `Confirmed` with both shipments now live and ready to plan. As each pallet is routed onto a tour, driven and delivered, the order tracks along on its own — reaching `Completed` only once both shipments have been delivered. ## Frequently asked questions **Q: When does an order become Completed?** Once every shipment that still counts towards it has been delivered. An order with one shipment delivered and another still in transit stays in progress — that is correct, not stuck. Shipments that were cancelled or failed simply drop out of the count and never hold an order back. **Q: Can an order end any other way?** Yes. An order reads as `Undeliverable` once every one of its shipments has ended and at least one of them has no cargo left to move, because the goods on it were written off. Orbit derives this from the shipments, so undoing the write-off reopens the order. See the [Writing Off Goods That Cannot Be Delivered](https://support.pr-4.orbit.do/en/multi-leg-logistics/writing-off-goods-that-cannot-be-delivered) article. **Q: Can I set an order's status myself?** Not usually. The status is worked out automatically from the order's shipments and their tours: you confirm or cancel the order, and everything else follows. The one exception is a confirmed order with no shipments, such as a box rental, a box sale or a recycling brokerage: use Complete Order, on the order's detail page or its context menu in the orders list, to move it to Completed yourself, since there is nothing else to derive that status from. **Q: Some customer fields look empty — is data missing?** Usually not. Those details are typically inherited from the linked `Shipper`'s saved record. Open the shipper to see them. **Q: Can a carrier see an order?** No. A carrier only ever sees the `Tour` assigned to them and their own rate — never the `Order`, the customer, or the price the customer paid. **Q: How do I get from a tour to its order?** Open one of the tour's shipments. Each `Shipment` names the `Order` it belongs to; there is no direct tour-to-order link. **Q: Can Orders be managed outside Orbit MissionControl?** Yes. Orders can also be created and managed programmatically — see the Orbit API Reference for the available endpoints.