ParcelPilot
Help

Orders — Understanding Order State

Use this guide when an order looks confusing because multiple status-style fields are visible at once.

ParcelPilot deliberately keeps source-owned statuses, warehouse progression, lifecycle policy, monitoring/history flags, and local blockers separate.

The short version

An order can be:

  • Active in lifecycle terms
  • Operational in Ops Mode terms
  • still blocked from warehouse work right now

That is normal.

Operational does not always mean actionable, and Active does not mean the warehouse should ignore blockers.

Where to look on Edit Order

The Order state panel on Edit Order shows the current model in one place:

  • Payment status
  • eCommerce status
  • Warehouse status
  • Lifecycle
  • Ops mode
  • History mode
  • ParcelPilot hold
  • Warehouse actionability

If the order is blocked, the panel also shows the current blocker message.

Ownership matrix

Field What it means Who effectively owns it
Payment status Commercial payment state such as paid or outstanding Usually the upstream source for imported orders; ParcelPilot for manual orders
eCommerce status The upstream platform workflow status The ecommerce platform
Warehouse status ParcelPilot warehouse progression such as new, picking, despatched, or complete ParcelPilot warehouse workflow
Lifecycle ParcelPilot local visibility and retention policy ParcelPilot
Ops Mode Whether the order belongs in the live working queue or monitoring-only visibility Derived from ParcelPilot client operating mode and stored order context
History Mode Whether the order is pre-go-live history rather than live warehouse work ParcelPilot import policy
ParcelPilot hold A local fulfilment pause without changing warehouse status or reservations ParcelPilot

The status-style fields explained

Payment status

Payment status is not the same thing as warehouse readiness.

  • It describes whether the order is paid, outstanding, refunded, or similar.
  • Imported orders normally treat payment status as source-owned and refresh it from the connected platform.
  • Manual ParcelPilot orders can set payment status locally when ParcelPilot is the source of truth.
  • Some integrations can block warehouse processing when payment is still outstanding.
  • A paid order can still be blocked for another reason.
  • An outstanding order does not always block warehouse work unless the client's integration policy says it should.

eCommerce status

This is the status coming from the sales channel.

Examples might include an upstream order being on hold, cancelled, completed, or refunded.

ParcelPilot uses that upstream status to decide things such as:

  • whether the order should reserve stock
  • whether the warehouse should process it
  • whether it should become locally blocked or read-only

Warehouse status

Warehouse status is ParcelPilot's own fulfilment progression.

Common statuses include:

  • New: imported or created, with no warehouse start recorded yet
  • Picking: warehouse work has started
  • Fulfilled: fulfilment has been completed locally
  • Despatched: the goods have left the warehouse
  • In transit: carrier tracking shows movement
  • Out for delivery: carrier is attempting delivery
  • Delivered: delivered tracking state
  • Complete: ParcelPilot treats the order as complete
  • Cancelled: the order should not progress further
  • On hold: an operational hold state in the warehouse status itself
  • Awaiting stock: fulfilment cannot proceed until stock is available

Warehouse status is only one part of the picture. It does not replace shipment evidence, fulfilment status, or upstream status.

Lifecycle

Lifecycle is ParcelPilot's local policy state for the order record.

Current lifecycle states include:

  • Active: visible and not hidden by lifecycle policy
  • Blocked: visible, but locally marked as blocked
  • Read only: visible, but retained as a non-operational record
  • Suppressed: intentionally removed from live operational views
  • Archived: retained for longer-term history or finance use outside normal live views

Lifecycle answers a different question from warehouse status. It is about how ParcelPilot keeps or hides the record, not how far a picker got.

Ops Mode

Ops Mode answers whether the order belongs in the normal live warehouse queue or should remain visible only for monitoring.

  • Operational: the order belongs in the live queue if nothing else blocks it
  • Monitoring only: the order stays visible, but the warehouse should not work it as live fulfilment

Ops Mode is not a complete blocker summary. See Orders - Ops Mode.

History Mode

History Mode answers whether the order is a live warehouse order or pre-go-live history.

  • Live warehouse order: normal live order
  • Pre-go-live history: imported for visibility, search, finance, support, or returns, but not for live ParcelPilot fulfilment

Pre-go-live history orders stay read-only for warehouse execution even if other fields look operational.

ParcelPilot hold

The Hold fulfilment action creates a ParcelPilot-only local hold.

This is different from an upstream on-hold status.

When a ParcelPilot hold is active:

  • ParcelPilot keeps the current reservations in place
  • ParcelPilot does not change the warehouse status just because the hold was applied
  • shipment creation, picking, and other warehouse execution paths are blocked until the hold is released
  • releasing the hold removes only this local blocker; other blockers can still remain

Blocked does not always mean the same thing

An order can be blocked because of different layers of state.

Common examples:

  • Operational blocker: the order is cancelled, refunded, monitoring-only, already despatched, externally fulfilled, on hold, locally held, awaiting payment under policy, or contains outbound-blocked measured items
  • History blocker: the order is pre-go-live history and remains read-only
  • Lifecycle blocker: the record is retained but locally marked blocked or read-only

That is why two orders can both say “blocked” but need different next actions.

Current code-backed warehouse blockers

ParcelPilot currently blocks live warehouse execution when the order is blocked for reasons such as:

  • the client is in Monitoring only mode for this order
  • fulfilment is handled externally rather than by ParcelPilot warehouse stock
  • the order is refunded
  • the order is cancelled
  • a ParcelPilot fulfilment hold is active
  • the warehouse status is On hold or Awaiting stock
  • the order has already been fulfilled, despatched, in transit, out for delivery, delivered, complete, or otherwise already has non-retryable shipment evidence
  • payment is outstanding and the integration policy blocks warehouse work on outstanding payment
  • the order contains measured items that ordinary outbound workflows do not support
  • the upstream workflow bucket itself is non-operational, such as cancelled, on hold, or completed
  • the order is marked as Pre-go-live history

ParcelPilot uses the same blocker model across the Edit Order state summary and warehouse execution paths such as shipment creation and mobile picking.

What changes warehouse status

Printing packing documents

Printing a packing slip or combined packing documents can move an order from New to Picking.

That is intentional. ParcelPilot treats printing as a signal that fulfilment work has started.

Bulk fulfilment hold actions

The Orders list now exposes explicit bulk hold actions instead of a generic warehouse-status editor.

  • Hold fulfilment applies the ParcelPilot local fulfilment hold to each eligible selected order.
  • Release fulfilment hold removes that local hold.

Important:

  • these actions do not change the underlying warehouse status
  • they preserve existing reservations
  • they do not create shipment or fulfilment evidence
  • they use the same local-hold blocker model as the single-order Hold fulfilment and Release hold actions

Shipment creation and tracking

Normal outbound dispatch should start from Create shipment and the correct Shipment method.

Status updates on their own do not replace the shipment workflow.

Tracking can then update warehouse-facing order progression, for example:

  • In transit tracking can update the order to In transit
  • Out for delivery tracking can update the order to Out for delivery
  • Delivered tracking can update the order to Complete

Notes:

  • tracking-driven updates do not normally move an order backwards
  • cancelled orders are not auto-updated by tracking
  • merged-group tracking updates can apply across the merge group
  • correction workflows such as Reverse Dispatch can legitimately reopen an order when fresh evidence no longer supports the old terminal state

See Correcting a dispatched order if the question is how to unwind dispatch evidence safely.

Reimport and order state

Use Re-import from source when the upstream system changed details such as contact information, address, shipping method, or lines.

Reimport refreshes upstream-owned details, but it does not behave like a blanket reset.

  • ParcelPilot can preserve local protective state such as a local fulfilment hold
  • ParcelPilot can preserve operational fields when warehouse activity means they should not be rolled back automatically
  • the reimport outcome can now explain which categories were updated, preserved, or blocked for review

For the full import and reimport workflow, see Orders — Reimporting an Order.

Troubleshooting flow

When an order looks inconsistent, check the fields in this order:

  1. Check Warehouse actionability and read the current blocker message.
  2. Check whether ParcelPilot hold is active.
  3. Check History Mode for pre-go-live history.
  4. Check Ops Mode for monitoring-only visibility.
  5. Check Warehouse status for on-hold, awaiting stock, or already-despatched style states.
  6. Check Payment status and eCommerce status for upstream blockers such as outstanding, cancelled, or refunded.
  7. If the issue is shipment-specific, use Why Can't I Create a Shipment?.

Worked example

Laurie wants the warehouse to stop work on an imported order while the customer fixes the delivery address upstream.

Safe workflow:

  1. Use Hold fulfilment on the order.
  2. Update the source order in the ecommerce platform.
  3. Run Re-import from source.
  4. Review what changed.
  5. Use Release hold only when the order is ready to re-enter live warehouse execution.

This avoids changing warehouse status just to pause fulfilment, and it keeps the order's local protective blocker separate from the upstream edit.

Order status, fulfilment status, and shipment status are different

ParcelPilot keeps these concepts separate:

  • Warehouse status is the order's warehouse-facing progression
  • Fulfilment status describes whether quantity is still outstanding
  • Shipment status describes the shipment's own transport or carrier state

After a correction, those values should be read together rather than forced into one badge.

For the operator workflow and examples, see Correcting a dispatched order and Orders — Partial Shipments.