Transport orders # Statuses explained: orders, consignments, trips and actions Every status from order to action result: what each one means, what changes it and how a change moves through orders, consignments and trips. Updated 7 October 2026 Transportial tracks work at four levels, and each level has its own status. Most of them depend on each other: what happens to an action on a trip decides the status of its consignment, and the consignments decide the status of the order. This article lists every status, what it means and what changes it. ## How the statuses connect | Level | What it describes | Who changes it | | ---------------------------------- | ------------------------------------------------------------------ | ----------------------------------------------------------------------------------------- | | **Action** (life cycle and result) | One stop or task, such as loading at a warehouse, and how it went. | The trip it is on, the driver, the board computer, the vehicle's position, or a planner. | | **Trip** | One vehicle's journey with its stops. | Planners, drivers, board computers and some platform settings. | | **Consignment** | One shipment within an order. | Mostly automatic: calculated from the life cycles and results of its actions. | | **Transport order** | The customer's order as a whole. | Accept, decline and cancel are manual. After that it is calculated from its consignments. | The order and consignment statuses are recalculated every time a trip with their consignments is saved, so they follow the work as it is carried out. Changing a trip, starting it, completing an action or ending it all count as a save. A stop that starts or completes by itself because of the vehicle's position, and updates from sea and air tracking, show in the order and consignment at the next save of the trip. The statuses work the same for road, sea, air and rail trips. ## Transport order statuses | Status | Meaning | | ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Draft** | Not finished yet, for example an order read from an e-mail or document that still needs checking. | | **Requested** | Requested by a customer, for example through the customer portal, and waiting for you to accept it. Orders that customers create are always requested. | | **Accepted** | Accepted, with at least one consignment not yet planned. Orders you create yourself start here. | | **Partly planned** | Some of the work is on trips, but not all of it. Also shown while a consignment requires replanning or is only partly completed. | | **Planned** | Every consignment is planned on trips. | | **Current** | Every consignment is in transit or completed. | | **Realised** | Every consignment is completed. | | **Turned down** | A requested or draft order that you declined. | | **Cancelled** | The order is cancelled. | ### What changes the order status | Change | Trigger | Also happens | | -------------------------------------------------------- | ------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------- | | Draft → Requested | **Save as request** on a draft order. | \- | | Requested or Draft → Accepted | **Accept**. | All consignments become **Confirmed**. A linked quote is accepted. | | Requested or Draft → Turned down | **Decline**. | All consignments are cancelled and their tenders are closed. | | Requested or Accepted → Cancelled | **Cancel**, on one order or several in the list. | Consignments that are not planned yet are cancelled. Planned consignments and their trips are left alone. | | Accepted → Partly planned → Planned → Current → Realised | Automatic, from the consignment statuses. | When the order becomes **Realised** and has no invoice yet, its invoices are created if your pricing invoices at the end of the order. | | Any → any | **Bulk edit**, when your platform allows editing the status there. | Only the status changes. Nothing else follows. | The automatic order status follows these rules, first match wins: 1. A consignment requires replanning → **Partly planned**. 2. A consignment is not planned at all → **Accepted**. 3. All consignments planned → **Planned**. 4. Some consignments (partly) planned → **Partly planned**. 5. All consignments completed → **Realised**. 6. All consignments in transit or completed → **Current**. 7. A consignment is partly completed → **Partly planned**. Cancelling an order does not cancel its trips. Before you cancel an order with planned consignments, cancel or change the trips first. See [Cancel, remove or split a trip](/en/help/cancel-or-split-trip). ## Consignment statuses | Status | Meaning | | ----------------------- | ------------------------------------------------------------------------------------------------------------------------- | | **Draft** | Its order is a draft. | | **Requested** | Its order is requested and not accepted yet. | | **Confirmed** | Accepted, nothing planned yet. The consignment is in the planning pool. | | **Partly planned** | Some of its actions are on a trip, others are not. | | **Planned** | All outstanding actions are on trips. | | **Partly underway** | A trip with some of its actions has started; other actions are not planned yet. | | **In transit** | Being carried out: the trips with its actions have started, or an action is in progress. | | **Partially completed** | Some actions are done, others still need planning, for example after a first leg in a multi-leg transport. | | **Completed** | Every action is done. | | **Cancelled** | The consignment is cancelled. | | **Requires replanning** | Something went wrong, such as a failed delivery or a trip cancelled half-way, and a planner needs to plan the rest again. | ### How the consignment status is calculated On each trip save, Transportial looks at all actions of the consignment, including those of its goods. First match wins: 1. An action failed and has not been redone successfully → **Requires replanning**. 2. All actions realized → **Completed**. 3. All actions projected or realized → **In transit**. 4. All actions planned or realized → **Planned**. 5. All actions requested → **Confirmed**. 6. A mix of requested and realized → **Partially completed**. 7. A mix of requested and actual → **In transit**. 8. A mix of requested and projected → **Partly underway**. 9. A mix of requested and planned → **Partly planned**. **Requires replanning** stays until every remaining action is on a trip again and the failed action has been redone successfully by a later action of the same type. ### Manual changes * Accepting, declining or cancelling the order sets its consignments as described above. * On a consignment that is **Confirmed**, the options menu offers **Cancel** to cancel only that consignment. Use it before the consignment is planned; a consignment on a trip is recalculated from its actions on the next trip save. * Accepting a bid on a tender does not change the consignment status. **Accept and plan** puts it on a new trip, which then sets it to **Planned**. ## Trip statuses | Status | Meaning | | ---------------------- | ----------------------------------------------------------------------------------------------------------------- | | **Draft** | Being prepared. Its actions stay requested. | | **Requested** | Proposed but not accepted into the plan, for example by the optimizer. Its actions stay requested. | | **Accepted** | Part of the plan. New trips start here. Its actions become planned straight away. | | **Confirmed** | Ready to go. It is sent to the board computer and, for a forwarded trip, the booking goes to the carrier. | | **In transit** | Started. It is the vehicle's current trip. | | **Pending completion** | The trip has ended and waits for a planner to check it. Only used when your platform requires planner completion. | | **Completed** | Closed. End-of-trip invoicing runs. | | **Cancelled** | No longer carried out. | ### What changes the trip status | Change | Trigger | Also happens | | -------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | New → Accepted | Creating a trip, or splitting an order into trips. | Actions become planned. | | New → Requested | The optimizer proposes the trip. | \- | | Accepted → Confirmed | **Confirm** on the trip (needs a vehicle), in the right-click menu, or for several trips on the plan board. | All actions are set to planned. The carrier booking is sent. Board computer planning is sent. | | Confirmed → In transit | **Start trip** by a planner or the driver, or the first execution reported by the board computer. | Actions become projected. If the vehicle is near the first stop, that stop starts; otherwise the drive to it starts. | | In transit → Completed or Pending completion | **End trip** or **End trip & start next**, or automatically when all actions are done and **Finish Trip On Actions Complete** is on. | All remaining actions are realized. The trip's start and end times are taken from its stops. The vehicle is released. On **Completed**, end-of-trip invoices are created. | | Pending completion → Completed | **Complete trip**. | End-of-trip invoices are created. | | Any → Cancelled | **Cancel** on one trip or several, or the optimizer replacing a trip. | See _What cancelling does_ below. | Some tracking integrations for sea and air shipments set **In transit** and **Completed** straight from the carrier's updates. See [Trip statuses: confirm, start and finish](/en/help/trip-status-lifecycle) for the steps in the app. ### Forwarded trips and the carrier's order A trip run by a carrier under a capacity contract also gets a forwarded transport order for that carrier. Its status follows the trip: | Trip status | Forwarded order status | | ----------------------------- | ---------------------- | | Draft, Requested | Requested | | Accepted | Accepted | | Confirmed | Planned | | In transit | Current | | Pending completion, Completed | Realised | | Cancelled | Cancelled | The carrier booking has its own status: **Draft** when it is created, **Submitted** when the trip is saved, **Cancelled** when the trip is cancelled. Ferry and carrier integrations can report **Pending confirmation**, **Confirmed** or **Failed**. See [Capacity contracts](/en/help/capacity-contracts). ### Plan status and route status Next to its status, a trip in progress shows whether it runs to plan: * **Plan status** per stop: **OK**, **Too early** or **Too late**, by comparing the expected arrival (or the actual arrival, once there) with the stop's time window, with five minutes of tolerance. The trip shows the plan status of its next open stop, and stays **Too late** while any open stop is too late. A cancelled trip has no plan status. * **Route status**: **On route** or **Off route**, by comparing the vehicle's last position with the planned route. ## Action life cycle Every action, such as a stop, a load, an unload or the drive between two stops, has a life cycle: | Life cycle | In OpenMove | Meaning | | ------------- | ----------- | --------------------------------------------------------------------------------------- | | **Requested** | Requested | Not on a trip yet, or on a draft or requested trip. The action is in the planning pool. | | **Planned** | Planned | On an accepted or confirmed trip. | | **Projected** | Projected | The trip has started and the action is coming up. | | **Actual** | In progress | Happening now: the driver started it or the vehicle arrived. | | **Realized** | Completed | Finished. The time and the result are recorded; the result tells whether it succeeded. | A stop holds sub-actions, such as loading, unloading and coupling a trailer. Starting or completing a sub-action also moves its stop, and the stop is realized when its last sub-action is. Completing a stop starts the drive to the next stop, and starting a stop ends the drive to it. ### What changes the life cycle | Change | Trigger | | ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Requested → Planned | The action is put on a trip that is accepted or later. Confirming the trip sets all its actions to planned again. | | Planned → Projected | **Start trip**. | | → Actual | **Make current** on the action, the driver starting it in OpenMove or on the board computer, or the vehicle arriving at the location (see the setting below). | | Actual → Realized | **Complete** on the action, the driver completing it, or the vehicle leaving the location. | | All → Realized | **Complete all actions** on a trip in transit (does not end the trip), or **End trip** (realizes every open action, including ones that never happened). | | → Requested | Cancelling the trip returns actions it did not carry out to the planning pool. | * **Arrival and departure.** When the vehicle's position enters the geofence of the next stop, the stop starts. When the vehicle leaves it again (or moves more than 500 metres away when the location has no geofence), the stop is completed and the next drive starts. Arrival can be switched off with **Automatically start actions on arrival at the location**; departure always completes the stop. * **Actions without a trip.** Coupling and uncoupling actions planned straight on a vehicle, driver or trailer start automatically once their start time has passed, when **Automatically execute planned attach/detach actions** is on. * **Locked actions.** Actions that are actual or realized can no longer be moved or removed. To fix the times of a realized action, use **Edit times**. ## Action results When an action is completed, it gets a result that tells how it went: | Result | Meaning | Effect | | ------------------------------------ | ------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------- | | **Done** | Carried out as planned. This is the default. | None. | | **Partly done** | Only part was done, for example fewer pallets loaded. OpenMove asks for a reason. | Counts as done: the consignment can still be completed. Check the remarks and goods counts. | | **Not able to do** | Not carried out, for example the receiver was closed or refused the goods. OpenMove asks for a reason. | Starts replanning (see below). | | **Cancelled** | Called off. Only reported by board computers and integrations. | Counts as done. | | **Cancelled - requires re-planning** | Set by Transportial on the remaining actions after a failure, so they can be planned again. | Keeps the consignment on **Requires replanning**. | Besides the status, a result can hold a reason, remarks, photos, signatures and documents, the goods counted or scanned per line, questionnaire answers, answers that differ from the order data, and a new date the receiver asked for. The driver fills these in OpenMove, through the action result questionnaire your platform set up per action type, or on the board computer. Planners set results with **Complete** or **Complete all actions**. See [Execute a stop in OpenMove](/en/help/openmove-execute-a-stop) and [OpenMove questionnaires](/en/help/openmove-questionnaires). ### What a failed action triggers When an action is completed as **Not able to do**, or with a new date the receiver asked for: 1. The consignment's remaining actions on that trip are closed with **Cancelled - requires re-planning**. 2. The consignment becomes **Requires replanning**, and the order **Partly planned**. 3. The team managers of the order get a notification: _Action Failed - Re-planning Required_ or _Delivery Rescheduled - Re-planning Required_. 4. A planning exception is opened. It closes by itself once the consignment is replanned. See [Handle planning exceptions](/en/help/exceptions-view). Plan the consignment's remaining work on a new trip. When the action is later done successfully, the consignment status follows its actions again. Goods have no status of their own. Loading and unloading are recorded on the actions, and the goods counts in the result show what was actually handled. ## What cancelling does ### Cancelling a trip What happens depends on the **Trip cancellation** settings of your platform. With all of them on (the default): * Actions the trip did not carry out go back to **Requested**, in the planning pool, without ETA or plan status. * A stop the driver started but did not finish also goes back. * For a consignment that was part-way, an action is added that records where the goods are now, so the rest can be planned from there. * That consignment becomes **Requires replanning**, and the order's team managers get a _Trip Cancelled - Re-planning Required_ notification. * The vehicle is released, expected costs of the trip are removed and the carrier booking is cancelled. ### Cancelling a consignment or an order * Cancelling an order cancels the consignments that are still **Requested** or **Confirmed** and closes their tenders. Consignments on trips are not touched. * Declining a requested order cancels all its consignments. * Removing an order cancels all its consignments. ## Settings that change the life cycles Platform administrators find these under **Settings** › **Environment** › **Planning**. See [Platform settings](/en/help/platform-settings). | Setting | Default | Effect | | ---------------------------------------------------------- | -------------- | ------------------------------------------------------------------------------------------------------------------------- | | **Require planner completion before a trip can finish** | Off | **End trip** leads to **Pending completion**. A planner must click **Complete trip**, which also creates the invoices. | | **Finish Trip On Actions Complete** | Off | The trip ends by itself as soon as all its actions are realized. | | **Automatically start actions on arrival at the location** | On | A stop starts when the vehicle enters the location's geofence. | | **Automatically execute planned attach/detach actions** | On | Coupling and uncoupling actions planned without a trip start at their start time. | | **Completing grouped actions** | **One by one** | Whether drivers complete the actions at one location one by one, choose which to do together, or do all of them together. | | **Trip cancellation** | All on | What cancelling a trip does, as described above. | | **Action Result Questionnaires** | None | Questions the driver answers per action type. Answers can set the result and its reason. | Trips are never confirmed automatically, and orders from customers are never accepted automatically. Invoices are created at the end of a trip or order only when your pricing is set to invoice at that moment. ## Related statuses ### Quotes **Draft** → **Open** when you send it → **Accepted** or **Declined** by the customer, in the app or through the shared link. **Invoiced** once an invoice is made from it, by hand or automatically when its order is realised. **Cancelled** is set by hand. Accepting a quote also accepts its order. See [Quotes](/en/help/quotes). ### Invoices Invoices created automatically start as **Draft**; an invoice of 0 becomes **Paid** at once. Incoming invoices of a team with managers wait in **Waiting for approval** until a manager sets **Approved** or **Rejected**. Sending makes an invoice **Open**. Reminders make it **Reminded**. It becomes **Paid** when the open amount reaches zero, through your accounting package, a payment provider or a payment you register. **Too Late** and **Cancelled** are set by hand. See [Invoices](/en/help/invoices). ### Tenders and bids A tender is **Open** when published and **Closed** once you accept a bid. A bid is **Offered**, then **Accepted**, **Declined** or **Not chosen** (when another bid wins). A counter offer declines the old bid and creates a new one. Cancelling the consignment or declining the order closes its tender. See [Review and accept bids](/en/help/review-and-accept-bids). ### eCMR consignment notes **Issued** → **In transit** once the sender and carrier have signed for the take-over → **Delivered** when the consignee signs, or when delivery is recorded without the consignee because they refused or were absent (when your platform allows it). An eCMR can be **Cancelled** only before anyone has signed. Reservations and corrections are recorded on the note but do not change its status. The eCMR status is separate from the action life cycle: completing an unloading does not deliver the eCMR, and the other way around. ### Timeslot bookings A dock booking starts as **Requested**, or **Confirmed** straight away when the location confirms bookings automatically. It can be **Cancelled**. ### To-dos and planning exceptions A to-do follows its column on the board: **To do**, **In progress** or **Completed**. It shows **Overdue** once its deadline has passed and it is not completed. Planning exceptions are **Open** until you accept or dismiss them, or until they are closed automatically because the problem is solved. ## Summary: what one change sets in motion | Event | Result | | -------------------------------------- | -------------------------------------------------------------------------------------------------------------------- | | Order accepted | Consignments **Confirmed**; linked quote accepted. | | Consignment put on an accepted trip | Actions planned → consignment **Planned** → order **Planned** or **Partly planned**. | | Trip confirmed | Actions planned; board computer and carrier receive the trip. | | Trip started | Actions projected → consignment **In transit** → order **Current** once all its consignments are underway. | | Action completed as **Not able to do** | Remaining actions closed → consignment **Requires replanning** → order **Partly planned**; planners notified. | | Trip ended | All actions realized → consignments **Completed** → order **Realised** → invoices created when your pricing says so. | | Trip cancelled | Open actions back in the planning pool; part-way consignments **Requires replanning**; booking cancelled. | | Order cancelled | Unplanned consignments **Cancelled**; trips keep running. | ## Related articles * [Trip statuses: confirm, start and finish](/en/help/trip-status-lifecycle) * [Work with stops and actions](/en/help/trip-actions-and-stops) * [Add consignments and goods](/en/help/consignments-and-goods) * [Edit, duplicate, cancel or remove a transport order](/en/help/edit-duplicate-cancel-transport-order) * [Execute a stop](/en/help/openmove-execute-a-stop) * [Cancel, remove or split a trip](/en/help/cancel-or-split-trip) ## Still need help? Our support team is happy to answer any question about Transportial. [Contact support](/en/contact)[Report an issue](/en/report-issue) --- Canonical page: https://transportial.com/en/help/status-lifecycles