Orders guide

Process imported and manual orders through fulfilment safely.

Last updated:

Use Sales → Orders to process incoming orders from connected channels and manual entry.

What you can do

  • Search and filter orders
  • Use header quick filters for In progress, To pick, Awaiting payment, and Dispatch SLA at risk (SLA = service-level agreement)
  • Use the Queue dropdown for To allocate, To pick, and Ready to dispatch
  • Use Dispatch SLA for urgency and lateness, including overdue work
  • Open order detail from the linked order number in the Order column
  • Allocate stock
  • Mark orders shipped
  • Mark dispatched orders delivered when delivery evidence is available
  • Cancel orders (where allowed)
  • Contact buyers from supported channel orders
  • Open and print a price-free packing slip from the Pick and pack step
  • Track payment, fulfilment, and delivery status

On narrower layouts, the Order column becomes the primary summary cell. When the standalone Status column is hidden, the order status badge folds into Order. Use the linked order number to open the detail form.

In Sales order lines, an absent SKU is shown as an em dash (—), matching other empty table values. This is a display placeholder, not a stored SKU or a stock link. Existing SKUs keep their Stock item link where one is available.

Search behaviour

The Orders search is designed to match fields users can see in the list:

  • The ChannelWeave order number, for example SO-000945
  • The external order reference shown below the order number
  • The buyer name
  • The visible buyer code / username shown under the buyer name

Full buyer email addresses are searched only for email-like queries, such as queries containing @ or longer values. This avoids short searches matching hidden email domains rather than the visible row content.

Order sources

Orders can come from:

  • eBay
  • Amazon
  • Shopify
  • Website
  • POS (manual entry)
  • Discogs (manual Sales only; automatic order import is not enabled)

Every order has an explicit three-letter transaction currency. New manual orders start with the account inventory valuation currency for review. Connected Channels and Website integrations must provide the order currency; ChannelWeave does not silently treat a missing currency as GBP. Amounts in different currencies are not converted or combined into a false single-currency total. The supported operational currencies are GBP, EUR, USD, AUD, CAD, JPY, CHF, SEK, NOK, and DKK. Amounts have an explicit currency code. Most order displays use the currency's minor units (no decimal places for JPY; two for the other supported currencies). Recorded capture evidence is the deliberate exception below.

Recorded payment precision

On POS orders, Captured payments and the POS payment ledger preserve recorded amounts through four decimal places. Ordinary GBP 12.3400 displays as GBP 12.34, but GBP 0.0001 remains GBP 0.0001 rather than appearing as zero. JPY amounts likewise retain any meaningful recorded fractional digits. Entries and their currency-separated totals come from one database read; no exchange rate, rounding adjustment or extra capture is introduced.

Invalid amounts or currencies show Unavailable with a review warning, not zero or a guessed currency. An empty ledger means no locally recorded captures; it does not prove a provider order is unpaid or that its history is complete.

Capture evidence remains read-only. The ledger stays visible only for POS orders; this does not enable Shopify capture importing or privacy actions. Refunds and the calculation of stored order accounting totals are unchanged.

Exact outstanding and POS capture

Outstanding payment is the stored order gross less exact captures in that currency. It keeps its sign and meaningful digits through four decimal places: a negative value is an overcapture, not zero. Other currencies are never converted, refunds are not netted off, and Shopify's separate current-order summary does not replace the stored accounting basis.

Recording a POS payment requires valid, consistent evidence and an exact, positive balance payable in the currency's normal POS unit. JPY accepts positive whole yen; the other supported currencies accept at most two decimal places. Use plain decimal digits with an integer part, no leading zeros except 0, separators, signs, exponent notation or surrounding whitespace. Amounts are never truncated or rounded into acceptance and must fit the individual ledger limit and the exact outstanding balance.

A balance such as GBP 10.0001, an overcapture, unavailable evidence, other-currency/non-POS captures or a recorded refund requires review. No rounding adjustment, refund netting or automatic reconciliation is performed. A Paid label with an empty capture ledger is not permission to take another payment. Cancelled or unknown lifecycle states also block recording.

New POS orders with no payment state, or unpaid, awaiting_payment or pending, are eligible only with no recorded captures. partially_paid requires positive captures below gross. A consistent paid order has nothing left to capture; other or contradictory payment states require review. Dispatched/delivered orders are not newly prohibited from recording an otherwise eligible payment.

The server locks and rereads the order and capture evidence on submission. Capture, payment-status update, audit event and one-use submission nonce commit together. Exact settlement sets Paid; a smaller valid capture sets Partially paid. Reading the page never updates payment status.

A committed duplicate submission is refused. If the entire transaction fails, its nonce rolls back too. After an uncertain response, refresh and check the ledger before retrying: a new nonce without an external reference is a new submission, not proof of the same payment. Concurrent captures are serialised; later edits can still create discrepancies that need review.

This implementation is verified in an isolated synthetic database only. It is not approval to activate provider importing or privacy processing.

Authenticated POS payment forms

Opening an order requires a current, active, email-verified session, an unexpired password and permission to read Sales orders. Recording payment also requires permission to record POS payments; a browser form or an API key alone does not grant that permission.

The POS form includes a session-bound security token, separate from the one-use submission nonce. If the form is rejected with Please reload the order, reload it while signed in before trying again. The security token is bound to the signed-in user and account; another session's form cannot be used. Existing sequential tabs and retries reuse the token, but simultaneous first-time page loads can require a reload if one session save replaces the other's token. Order pages containing the form are not cacheable.

Missing, repeated or invalid security tokens and a supplied mismatched Origin are refused before any payment transaction. Repeated or file-valued payment fields are also refused rather than silently choosing one value. These refusals do not consume the submission nonce or create a capture. After an uncertain payment response, still check the ledger before retrying; CSRF protection does not replace the duplicate-payment rules above.

Verification remains isolated and synthetic. This does not activate provider importing, privacy processing or a Sandbox/Production deployment.

Tax on manual lines and refunds

Select an account-managed Tax code when adding a manual order line. The code's rate at save time is applied to the line net amount and recorded on that line. No tax code calculates zero line tax without asserting a legal tax classification. Changing an account rate does not recalculate recorded lines.

Manage codes and rates in Settings → Tax codes. These are manual selections, not automatic country-based tax determination. Shipping tax remains an explicitly entered amount.

Order summaries, line amounts and refunds use Tax as the generic label. An order with zero recorded tax is described as No recorded tax, not automatically as zero-rated or exempt. A positive order tax total requires the refund tax amount so net and tax can be recorded separately.

Typical fulfilment flow

  1. Review new/in-progress orders.
  2. Confirm stock allocation. Allocation reserves specific warehouse balance slices in FEFO order when lot/expiry data is present.
  3. Complete picking, then open the packing slip when a price-free order-contents sheet is needed for the parcel.
  4. Dispatch the order. Dispatch consumes the reserved slices, writes dispatch inventory movements, and records product cost for margin reporting.
  5. Update tracking/shipping details.
  6. Mark the order delivered once carrier, channel, or customer evidence confirms receipt.
  7. Monitor exceptions (for example cancelled or blocked orders).

Orders must be fully allocated before dispatch. This keeps stock, bin reservations, pick work, and COGS aligned to the same warehouse source of truth.

The packing slip is a live view of the order in your account. Before dispatch it shows active quantities that remain to be dispatched; after dispatch or delivery it shows dispatched quantities. It does not store a packed state, confirm that packing happened, or act as an invoice.

Cancellation requests, allocations and refunds

A buyer cancellation request is not itself a cancelled order. In Inbox → Messages, Accept cancellation opens the linked order's cancellation workflow; opening the link does not submit the decision.

For an eligible order, completed local cancellation releases existing stock allocations and marks the order and its lines cancelled. It does not increase the physical stock balance. An order with no allocations has no reservations to release. Cancellation is blocked for dispatched or delivered orders and where order lines already have dispatched quantities.

After Cancel order completes successfully, the sidebar's Orders count is refreshed on the redirected page without waiting for the normal badge-cache expiry. Cancelled orders are excluded; if no active orders remain, the badge is hidden. A failed or rolled-back cancellation does not clear the cached count. This refresh is scoped to the current account, not other accounts or already-open pages.

Cancel order opens a confirmation dialog; opening it does not contact eBay. All channels use this shared dialog, with wording matched to the order's channel:

  • eBay: explains the check-first workflow below. Buyer messaging, local-only maintenance and relist options appear only for eBay orders.
  • Other channels: names the channel and explicitly states that cancellation is local-only. Yes, cancel locally cancels the ChannelWeave order; it does not cancel the order on the original channel, issue a refund or notify the buyer. Manage any channel cancellation or refund separately.
  • POS: also uses Yes, cancel locally, with an explicit warning that cancellation does not reverse a payment, issue a refund or notify the buyer. Handle any refund separately through the original payment method.

Local-only describes the cancellation and payment action. Releasing allocations can still queue the normal listing-availability updates; it does not add physical stock. The action-panel wording follows the same channel distinction.

When you confirm the normal eBay action, ChannelWeave first reads the current order from eBay:

  • A matching Fulfillment order with cancelStatus.cancelState = CANCELED is reconciled locally without another cancellation, approval, refund or buyer message. The audit event records eBay confirmation, not the newly selected cancellation reason. Local payment status and refund records are unchanged.
  • Otherwise, the existing cancellation eligibility checks and submission apply. Pending or closed request text is not proof of completed cancellation.
  • A failed, malformed or wrong-order read stops the action without cancelling the local order. Shipment or reservation conflicts also block local changes.

If eBay reports an existing cancellation during eligibility or submission, ChannelWeave re-reads the order before proceeding. A newly confirmed cancellation is reconciled rather than approved again. If a submission was already attempted before that confirmation, the completion notice says so.

The explicitly selected Local-only maintenance option skips the eBay read and all cancellation/buyer-message calls. A cancelled local order therefore does not, by itself, prove that the provider cancellation or refund has completed. The optional relist action still creates only a local draft; publishing is separate.

eBay order sync also reconciles provider-confirmed cancellations. It uses the same local cancellation transaction: order and lines become cancelled, existing bin reservations are released once, and availability updates are queued for affected published listings. Already-cancelled orders do not have their lines reopened or stock reallocated by later eBay snapshots. Zero-line orders can also be marked cancelled. Dispatched/delivered orders, channel shipment evidence, or allocations without matching stock/bin reservations fail closed instead of partially applying a cancellation.

Sync reconciliation does not send another eBay cancellation, issue a refund, or create a refund amount from the order total. Payment status is read from the provider separately; existing refund records are refreshed only when eBay returns the matching refund reference. Refunds initiated outside ChannelWeave are not automatically added as new local refund records by this sync.

Keep payment outcomes and physical returns separate from released reservations. Do not manually add stock just because a cancellation request or refund exists. For a worked one-unit example and seller checklist, read A cancellation request is not a cancelled order.

Fulfilment ownership

ChannelWeave tracks fulfilment progress separately from fulfilment ownership. Fulfilment status answers how far through fulfilment is this order?, while fulfilment owner and service answer who is responsible for fulfilment, and through which service?.

Seller-managed eBay, Shopify, Website, and POS orders default to seller-owned, seller-managed fulfilment. Amazon marketplace orders can later distinguish merchant-fulfilled (Amazon MFN) from Amazon-fulfilled (Amazon FBA) work, and non-Amazon orders fulfilled via Amazon are recorded as Amazon MCF.

When a single order uses different fulfilment owners or services by line, the order level shows Mixed; each line keeps its exact owner and service.

Amazon MCF fulfilment requests are created from non-Amazon sales orders only. When Amazon accepts an MCF create request, ChannelWeave records Amazon MCF ownership for the selected lines and recomputes the order summary, but it does not change the order lifecycle status or move warehouse stock.

Enterprise safeguards

Sales-order actions are protected by role permissions. Read-only users can view orders, while allocating, deallocating, dispatching, delivering, cancelling, refunding, capturing payment, creating, and editing orders can be granted separately.

Mutating order forms include duplicate-submit protection, so a browser refresh, double-click, or retry cannot submit the same action twice.

Manual fulfilment actions lock the order and relevant order lines while they run. Allocation, deallocation, cancellation, dispatch, delivery, POS payment capture, line changes, buyer contact, channel ingestion, and refund submission also write to the order's operational history so actions remain auditable.

Buyer and order maintenance

From order detail you can:

  • Review buyer and address details
  • Update editable order fields
  • Review line-level status and quantities
  • Delete one or more selected order lines before dispatch starts. If selected lines have allocated stock, ChannelWeave releases those reservations before removing the lines and recalculating order totals. Lines with a retained Discogs order identity link cannot be deleted.
  • Review the optional costing estimate when Settings → Costing & overhead is enabled. This shows recorded FIFO product cost, estimated overhead, and contribution after recorded costs without changing the order total.
  • Use Contact buyer when the order channel has a supported messaging route

Sales order line quantities are entered and displayed in the stock item’s sales/listing unit when a stock item is linked. ChannelWeave also stores the base inventory quantity on the line so allocation, dispatch, warehouse movements, and stock history stay aligned with the stock item’s base unit.

Existing manual Discogs Sales can be linked to reviewed Orders CSV evidence in Discogs tools. Several Sales can belong to one Discogs order without being merged or financially changed. A linked Sale must keep its Discogs Channel and either no external order reference or the linked order reference. Another Sale cannot claim that retained reference through the create/edit forms. Review deletion does not remove these identity safeguards; replacing or unlinking bindings is not yet available.

Contact buyer supports:

  • Amazon orders through Amazon's order-scoped SP-API Messaging actions. The app checks the allowed actions for the order before sending.
  • eBay orders when the order has a buyer username and an eBay item id on a line.
  • Website orders when the order has a valid buyer email and the Website reply relay is configured.

Outbound contact is stored in Inbox → Messages so the sent message remains visible with the order's channel badge. Amazon inbound buyer-message import is not a general SP-API feed, so buyer replies still need to be monitored through Seller Central unless a supported Amazon message source is added.

Payment badges use staff-friendly wording. For example, orders waiting for payment are shown as Awaiting payment.

Dispatched means the order has left the business or been handed to the carrier. Delivered means there is delivery evidence that the recipient received it. Dispatch SLA reporting stops at dispatch; delivery confirmation is tracked as the post-dispatch outcome.

For Shopify orders, ChannelWeave can receive fulfilment webhook updates. Shopify fulfilment success moves the order to Dispatched, and Shopify delivered shipment evidence moves the order to Delivered while preserving the delivery timestamp/tracking evidence in the order shipping details.

This payment state applies only to active orders. Once an order becomes Dispatched, Delivered, or Cancelled, ChannelWeave automatically normalises Awaiting payment to Unpaid.

Costing estimate

If a customer enables Settings → Costing & overhead, sales order detail adds an informational costing block. The estimate uses the configured predetermined overhead rate and recorded product cost from dispatch.

The block is deliberately conservative:

  • it never changes the order total, stock valuation, or live prices
  • it shows amounts only when the sales-order currency, costing-policy currency, and inventory valuation currency match
  • revenue-based overhead waits until refund tax splits are complete, because net revenue must be known first
  • product cost may show as zero before dispatch has recorded product cost

eBay notes

For eBay orders, ChannelWeave supports standard cancellation and refund workflows where marketplace rules allow.