Help

Orders — Reimporting an Order

This guide explains what Reimport does, when to use it, what it can safely refresh from the connected ecommerce platform, and what ParcelPilot deliberately preserves.

It also includes the surrounding import and sync-back context so operators can understand how manual Reimport fits into the wider order flow.

What Reimport actually does

Reimport asks the connected ecommerce platform for a fresh representation of an existing order and reconciles upstream-owned information back into the existing ParcelPilot order, subject to ParcelPilot's warehouse safety rules.

Reimport is not:

deleting and recreating the order
force-overwriting every field
resetting warehouse progression
releasing a ParcelPilot fulfilment hold
clearing reservations by itself
rewinding picking, shipment, or despatch evidence
a substitute for editing the source ecommerce order

If you need the state model behind those rules, see Orders — Understanding Order State.

Where the action lives

On Edit Order, Reimport is a standalone top-level header action labelled Reimport.

When available, its tooltip says it will refresh the order with the latest data from the connected sales channel.

When to use Reimport

Use Reimport when the source order changed upstream and ParcelPilot needs a fresh copy of that source-owned information.

Common examples:

the customer changed the delivery address
the customer corrected their email or telephone number
the shipping method changed in the store
the order lines or quantities changed upstream
the source platform changed the upstream order status or payment state

Update the source order in the ecommerce platform first. Reimport does not edit Magento, Shopify, WooCommerce, or any other upstream channel for you.

Manual Reimport versus automatic sync

ParcelPilot has two related behaviours:

Automatic/background sync: the normal integration import flow that keeps orders coming in or updating in the background
Manual Reimport: an explicit operator-requested refresh from Edit Order

Manual Reimport is the right tool when you need to ask, right now, “show me the latest version of this source order and safely reconcile it back into ParcelPilot.”

Manual Reimport does not mean “push my ParcelPilot edits back upstream”. Shipment confirmations and tracking sync are separate workflows.

Freshness and truthful outcomes

Manual Reimport is documented and implemented as a fresh refresh request.

If ParcelPilot cannot retrieve current upstream data, it should tell you that the refresh could not be completed. It should not present an older stored snapshot as though it had just been fetched live.

Current operator-facing outcomes include:

Reimport completed
Reimport completed - no changes
Reimport requires review
Reimport could not refresh the order
Order could not be reimported

In plain language:

Reimport completed means fresh upstream data was retrieved and relevant changes were applied.
Reimport completed - no changes means fresh upstream data was retrieved, but nothing relevant changed.
Reimport requires review means fresh data was retrieved, but one or more changes were intentionally preserved or blocked for safety.
Reimport could not refresh the order means ParcelPilot could not obtain fresh upstream data, so the existing stored order was left unchanged.
Order could not be reimported means the order is unsupported, does not have a matching enabled integration, or the requested rebuild would be unsafe.

Current manual Reimport availability

At the audited code point, manual Reimport is supported for orders from:

Magento
Shopify
WooCommerce
BigCommerce
Amazon
Mirakl
NOTHS

It is intentionally unavailable for other order sources such as manual orders, API-only orders, and unsupported channel integrations.

If the order's source is unsupported, or there is no matching enabled ecommerce integration for that client and tenant, the Reimport action stays visible but unavailable and explains why.

What Reimport can update

Reimport is mainly for source-owned commercial and order-detail information.

At operator level, current refreshable categories include:

customer details
billing details
shipping details
shipping service
order lines
totals
payment details
status information from the source/imported order context
platform metadata and identity details needed to keep the order linked to the correct upstream record

Some of these changes appear immediately in the Edit Order UI, especially customer/contact and shipping information when the order is still operationally safe to update.

What ParcelPilot preserves

Reimport does not treat ParcelPilot warehouse evidence as disposable.

Current ParcelPilot-owned state or evidence that is preserved or safety-protected includes things such as:

ParcelPilot fulfilment hold
warehouse progression/status when it should not be rolled back automatically
shipment evidence
picking and allocation evidence
tracking and carrier evidence
lifecycle policy such as suppressed, archived, blocked, or read-only state
Ops Mode and History Mode context
audit and integration history

Reimport refreshes source-owned information into the existing order. It does not erase the fact that warehouse work or accounting-sensitive evidence already exists.

Shipping address and contact safety

This is the most common operator use case.

If the customer changes delivery or contact details upstream before warehouse execution has materially started, Reimport can normally refresh:

the shipping address snapshot
shipping email
shipping telephone
customer/contact details

The safety boundary is stricter than “before despatch”.

ParcelPilot only treats the operational shipping destination as freely mutable while the order is still free of downstream fulfilment evidence such as shipment evidence, fulfilment commits, inventory deduction, allocations, picking evidence, shipment-linked allocations, serialised allocation evidence, channel fulfilment evidence, or accounting export evidence.

Once that kind of evidence exists, ParcelPilot may still refresh the non-operational upstream shipping snapshots for reference, but it can preserve the operational ship_to destination used by active warehouse work and tell the operator that review is required.

Changing an order before despatch

This is the recommended workflow when the warehouse must pause while the customer changes the source order.

Open the order in ParcelPilot.
Choose Warehouse -> Hold fulfilment.
Make the required change in the connected ecommerce platform.
Return to ParcelPilot.
Click Reimport.
Review the Reimport result and updated order details.
Confirm the requested change is present.
Choose Warehouse -> Release hold.
Warehouse processing can continue if no other blocker remains.

Why this is the safe workflow:

the ParcelPilot hold immediately blocks further warehouse execution
the hold preserves the current reservation
Reimport refreshes source-owned data
Reimport does not clear the local hold for you
Release removes only the local hold; it does not override other blockers

For the meaning of blockers, lifecycle, Ops Mode, and History Mode, see Orders — Understanding Order State.

Upstream hold versus ParcelPilot hold

An upstream hold in Magento or another sales channel is not the same thing as Hold fulfilment in ParcelPilot.

changing the upstream order to an on-hold state is a source workflow change
Hold fulfilment is the immediate ParcelPilot warehouse pause

If the goal is “make sure the warehouse does not pick or despatch this order while I update the source order”, use the ParcelPilot hold first. Do not rely on an upstream hold change being synchronised quickly enough to act as the immediate local warehouse pause.

Order lines and demand changes

Reimport can refresh upstream line and quantity changes, but it does not assume that changing demand is always safe once warehouse work has started.

Current behaviour at operator level is:

if the upstream line change is still operationally safe, ParcelPilot can rebuild fulfilment demand and reconcile reservations to the revised order
if only non-inventory details changed, Reimport avoids churning reservations unnecessarily
if existing warehouse evidence makes a demand rebuild unsafe, ParcelPilot stops instead of silently rewriting the order under active warehouse work

In practical terms, do not treat Reimport as a freeform way to rewrite picked, allocated, or shipped demand.

Reservations

Two rules matter here:

a ParcelPilot fulfilment hold preserves reservations
a safe demand change during Reimport can require reservation reconciliation

That means:

Hold does not release stock.
Reimport does not automatically clear reservations just because it ran.
If the revised upstream demand changes what should be reserved, ParcelPilot can recalculate the reservation when that recalculation is safe.
If reservation recalculation would be unsafe because warehouse activity already exists, ParcelPilot flags that instead of silently corrupting the order's warehouse state.

Cancellations

If a fresh upstream payload moves the order into a cancellable cancelled state, Reimport can make the order non-actionable and run the same shared cancellation cleanup used elsewhere.

For eligible unshipped orders, that can include releasing reservation demand and clearing unshipped allocation or picking metadata.

If shipment or deduction evidence already exists, Reimport does not use cancellation to roll that warehouse evidence back automatically.

See Orders — eCommerce workflow, suppression, archive, GDPR & accounting.

What the result messages mean

Reimport feedback is category-based.

Typical meanings are:

Updated: ParcelPilot refreshed one or more source-owned categories such as customer details, shipping details, shipping service, order lines, totals, or payment details.
Preserved: ParcelPilot intentionally left a protected operational category unchanged.
Review required: one or more changes could not be safely applied automatically and need operator attention.

So “completed” does not mean “every visible field was overwritten.”

No-change result

Reimport completed - no changes is a legitimate successful outcome.

It means ParcelPilot did obtain fresh current upstream data, but there was nothing relevant to update.

This is different from:

fresh data being unavailable
a protected change being preserved for safety
the order being unsupported for manual Reimport

When Reimport requires review

Reimport requires review means ParcelPilot refreshed the source order, but it could not safely apply everything automatically.

Examples include:

operational shipping details were preserved because warehouse activity already exists
reservation recalculation was blocked because active warehouse evidence means the demand change needs manual review

Read the notification carefully. A successful fetch does not always mean a full overwrite was safe.

When Reimport is unavailable or fails

If Reimport says it could not refresh the order:

do not assume the current ParcelPilot values were freshly confirmed upstream
do not keep clicking Reimport expecting it to override protected warehouse state
check whether the integration is enabled and whether the upstream platform is currently reachable
confirm the source order was actually changed upstream

If ParcelPilot says the order could not be reimported for safety reasons, treat that as an intentional fail-closed protection and review the live warehouse evidence before making further changes.

How ecommerce orders first arrive in ParcelPilot

Importing orders from an ecommerce platform

Go to Client Integrations.
Create or edit the integration for the client.
Configure credentials and enable the integration.

Once connected, orders from that ecommerce platform will appear in Orders.

The integration's Order workflow policy controls more than just whether orders appear:

which upstream buckets are imported
which imported orders reserve stock
which orders the warehouse is allowed to process
what should happen when upstream marks an order completed or cancelled
whether completed/cancelled orders are retained for accounting, audit, or GDPR reasons

This is especially important for avoiding old cases where deleted ecommerce orders simply reappeared from the source platform.

Pre-go-live history imports

If a client is onboarding and you need old ecommerce orders visible in ParcelPilot before warehouse fulfilment actually starts:

Open the client's ecommerce integration.
Set ParcelPilot fulfilment start date to the agreed go-live date.
Turn on Import pre-go-live orders as read-only history.

Behaviour of those older imported orders:

they stay visible in Orders for search, reporting, finance, support, and returns
they are marked as Pre-go-live history
operational row actions still render for workflow inspection when the current integration policy would allow them live, but they stay disabled with an explanatory tooltip
they do not reserve stock or deduct stock
they do not enter warehouse work queues such as awaiting pick or awaiting shipment booking
they do not create or push ParcelPilot fulfilment confirmations back to the ecommerce platform

This is intended for transition history and externally fulfilled backlog, not for live ParcelPilot fulfilment.

Upstream cancelled orders

When an imported or reimported upstream payload lands in the integration's Cancelled workflow bucket, ParcelPilot can retain the order for audit or support while still removing live warehouse demand.

Current implemented behaviour:

if policy says cancelled orders should release reservation on upstream cancel, ParcelPilot runs the shared cancellation cleanup workflow
plain reserved orders release reservation demand
picked or on-pick serial orders also clear unshipped allocations and picked metadata
stock propagation for this path is reservation-release only
the emitted stock event is order_reservation_released
ParcelPilot does not emit picking_reset or picking_unit_unallocated for cancellation
shipped or already deducted orders are not restocked or reset automatically during reimport

Automatic sync and manual Reimport together

The same connected integration provides both the normal background import/update path and the manual Reimport workflow.

For daily operations:

use background sync to keep normal order traffic flowing
use manual Reimport when one existing order needs an immediate fresh check and reconciliation

If an order is merged for fulfilment, or warehouse execution has already progressed, handle Reimport carefully and review the outcome rather than assuming every upstream change will apply operationally.

Syncing fulfilment information back to the ecommerce platform

The main “sync back” workflow is pushing shipment tracking or fulfilment confirmations after you create shipments.

Typical flow:

Create a shipment for the order.
Confirm the shipment has a tracking number or other fulfilment evidence.
Push tracking back to the ecommerce platform, or use Re-sync Tracking if needed.

Requirements:

the client integration must allow pushing shipment confirmations
pre-go-live history orders are never pushed back upstream, even if shipment push is enabled for the live integration

Troubleshooting:

if pushing tracking does nothing, first confirm the client integration is enabled and shipment confirmation push is turned on
if the upstream order cannot be found, Reimport the order first and then retry tracking sync