Orders — eCommerce Workflow, Suppression, Archive, GDPR & Accounting

This guide explains how ParcelPilot now handles ecommerce orders across Magento, Shopify, WooCommerce, BigCommerce, Amazon, Mirakl, eBay, TikTok, Etsy, and NOTHS.

The goal is to keep one consistent operational model even though each platform uses different raw statuses.

The shared workflow buckets

Every ecommerce order is mapped into one of four buckets:

Operational: the order still needs warehouse work.
On hold: keep it visible if needed, but do not let the warehouse process it yet.
Completed: upstream says the order is already fulfilled/shipped/finished.
Cancelled: upstream says the order should no longer be fulfilled.

The client integration decides separately whether each bucket should be:

imported
reserved
processed
retained

That separation is the main fix for older cases where “allowed to process” and “should import at all” were effectively mixed together.

Local lifecycle states

An order can also have a local ParcelPilot lifecycle state:

Active: normal working order.
Blocked: visible, but intentionally prevented from warehouse work.
Read only: kept for history/accounting but not operational.
Suppressed: hidden from live warehouse activity without deleting the record.
Archived: kept for longer-term history/finance/audit use outside the operational queue.

Why suppress instead of delete?

For ecommerce orders, delete is usually the wrong workflow.

If the source platform still considers the order importable, it may simply come back on the next sync. That was the root of the old “we deleted it and it reappeared” behaviour.

Use these actions instead:

Suppress From Warehouse: keeps the order record, removes it from the live warehouse flow, and releases any undeducted reservation.
Archive: keeps the order for longer-term history, finance, or audit use, and also releases any undeducted reservation.
Anonymise PII: removes personal/customer-identifying data while keeping order numbers and operational facts for GDPR, audit, or accounting reasons.

Reservations

The workflow policy separates reservation from processing.

That means you can now choose patterns like:

import on-hold orders for visibility, but do not reserve stock yet
keep completed orders for accounting, but never reserve stock for them
keep cancelled orders for audit, but never let them affect warehouse stock demand

By default, suppressing or archiving an undeducted ecommerce order releases its reservation automatically.

Completed orders for accounting/history

Some clients will want completed orders in ParcelPilot even though the warehouse should never touch them again.

Typical reasons:

export to accounting software
reconciliation
customer-support history
operational reporting

Those orders should usually be:

imported
marked read only
not reserved
not processable

That gives finance/history visibility without polluting the live warehouse queue.

Cancelled orders

Cancelled orders should normally be excluded from live warehouse work entirely.

Good default pattern:

do not import them unless audit/support needs them
never reserve stock for them
never allow warehouse processing
keep them only when there is a real audit, support, or traceability reason

If retained, they are best treated as read-only or archived records.

What cancellation does in ParcelPilot

When an unshipped order is cancelled, ParcelPilot uses one shared cleanup workflow across status changes, bulk cancellation, importer cancellation, reimport cancellation, and lifecycle suppress/archive reservation release.

For eligible unshipped orders it will:

delete unshipped allocation rows for the order
clear picked serial markers from line metadata
clear picked and picking-plan metadata
reset picking back to pending
release outstanding reservation demand from the inventory adjustment ledger

If the order was already shipped or inventory-deducted, ParcelPilot does not use this workflow to restock or undo fulfilment.

Picked or on-pick serial orders

If a picked order is cancelled before shipment:

the scanned or allocated serial links are cleared from the order metadata
unshipped order_line_allocations rows are deleted
picked_at and picked_by are cleared
reservation is released and sellable stock can return upstream

Shipped or deducted orders

If the order already has shipments or inventory.deducted_at:

ParcelPilot does not restock it automatically through cancellation
shipped allocation history is kept
the warehouse status is not forcibly rewritten back from fulfilled or shipped states during reimport

Stock propagation on cancellation

Cancellation stock propagation is reservation-release only.

when reservation quantity is actually released, ParcelPilot emits order_reservation_released
cancellation does not emit picking_reset
cancellation does not emit picking_unit_unallocated

This is intentional because the externally relevant stock change is the increase in sellable stock caused by releasing reservation demand.

Suppress and archive

Suppress and archive keep ecommerce orders out of the live queue without deleting them.

both actions release any undeducted reservation through the same shared cleanup path
neither action changes the warehouse status to Cancelled
both preserve the order record for audit, accounting, or support use

Upstream cancellation policy

When the integration workflow policy imports cancelled orders and the integration is configured to release reservation on upstream cancel:

importer cancellation applies the same cleanup path after the order is imported or updated
reimport cancellation applies the same cleanup path when the refreshed upstream payload moves the local order into a cancellable cancelled state
already shipped or deducted orders are preserved rather than rolled back

GDPR / PII anonymisation

ParcelPilot can keep operational facts while removing customer-identifying data.

Use Anonymise PII when you need to support GDPR-style deletion/redaction requests but still retain:

order number
line items
quantities
status history
shipment/accounting/audit references

Reporting and filters

The Orders list now supports lifecycle-style visibility more directly.

Useful columns/filters include:

Lifecycle
Accounting
GDPR
filters for suppressed, archived, anonymised, and accounting exportable

Audit logs also include lifecycle events such as suppression, archive, reservation release, anonymisation, and upstream reactivation.

Recommended defaults

For most warehouse-led ecommerce clients:

import operational orders
import on-hold orders only if visibility helps the ops team
reserve only operational orders
process only operational orders
keep completed orders only when accounting/history needs them
keep cancelled orders only when audit/support needs them
use suppress/archive instead of deleting ecommerce orders locally