Orders, Shipments & Refunds

Orders and Shipments

An order is the record of a sale, and everything about it hangs off that one row.

Where to find it

Architect Panel → Commercial:

• Carts — the cart itself and its options

Architect Panel → Data:

• Datastores — then View Data on the cart table, and look for the row actions

What the order holds

An order number, the customer, the shipping method and weight band, the net total, discount, shipping, tax and gross total with currency, the delivery and billing addresses with the delivery country, and a status.

Addresses are stored on the order rather than referenced, which is correct — an order should show where it was actually sent, not where the customer lives now.

The row actions are the detail

An order offers Basket Contents, Payments and Refunds. Those three answer nearly every question anybody asks about an order, and they are not visible until you look for them.

Lines carry their own price and tax

And their own status. That is what allows part of an order to be cancelled, refunded or back-ordered without disturbing the rest, and it is why the order total is a record of what was charged rather than a calculation to be re-run.

Payments are separate from the order

An order can have more than one payment, each with its method, reference, amount and result. So a partial payment, a retry after a failure, or a deposit followed by a balance all record properly.

Shipments are separate too

A shipment carries its own shipping method, weight band, delivery address and tracking number, with lines naming which products and which stock records went in it.

That means an order can ship in parts — which happens constantly, and is impossible to record honestly if dispatch is a flag on the order.

Shipment lines reference stock

Not just the product. So you know which batch a customer received, which is what makes a targeted recall possible and what settles a dispute about which version of a product was sent.

Give status a defined meaning

Order status drives what everybody does. Write down what each value means and who moves it, because a status set inconsistently is worse than no status — it looks authoritative and is not.

Keep tracking numbers on the shipment

With the method’s tracking prefix set, they become links. A customer who can see where their parcel is does not contact you.

Worked example

A shop dispatches multi-line orders in whatever parts are ready, recording a shipment per parcel with its tracking number and the stock records used. A customer query about a missing item was answered from the order in under a minute: two shipments, one delivered, one still in transit.

Recommendations

• Look for the row actions — the detail is behind them.
• Record a shipment per parcel, not a flag on the order.
• Reference stock on shipment lines for traceability.
• Define what each status means in writing.

Refunds

A refund is a record against an order, with lines naming what is being refunded and why.

Where to find it

Architect Panel → Commercial:

• Carts — the cart itself and its options

Architect Panel → Data:

• Datastores — then View Data on the cart table, and look for the row actions

The structure

• The refund — against an order, with notes and a status.
• Refund lines — each naming an order line, a reason and its own status.
• Refund payments — how the money went back, with method, reference, amount and currency.

Three levels because refunds are rarely simple: part of an order, for different reasons, sometimes returned by more than one route.

Reasons are defined, not typed

Refund reasons are a list you maintain — arrived damaged, wrong item received, and whatever else your business sees. Choosing from a list rather than typing is what makes refunds analysable.

Which is the point: refund reasons are the cheapest quality data you will ever collect. A supplier whose products arrive damaged, a product whose description misleads, a picking process that sends the wrong thing — all of it is visible in the reasons, and invisible in free text.

Keep the list short and distinct

Six or seven reasons that clearly differ. A long list means people pick the first plausible one, and the data stops meaning anything.

Refund per line, not per order

Even when refunding everything. Line-level refunds tell you which product had the problem; an order-level refund tells you an order was refunded, which is much less useful.

The payment record matters

Recording how the money went back — method, reference, amount — is what lets finance reconcile refunds against the gateway. Without it, a refund in the shop and a refund in the payment provider are two facts nobody can connect.

Decide who can refund

Refunding is giving money away, and the permission to do it should be deliberate. Most shops want a value threshold above which a second person is involved.

Refunds and stock

A refunded item may or may not come back into stock — damaged goods do not. Decide the rule and apply it consistently, because stock that quietly includes returned damaged items is stock you cannot sell.

Read the reasons monthly

Not the refund total. The total tells you what it cost; the reasons tell you what to fix, and fixing the cause is the only thing that reduces the total.

Worked example

A shop refunds line by line against a list of six reasons, recording the return payment reference each time. A monthly review of reasons showed a third of damage refunds came from one product line, which turned out to be packaged inadequately; changing the packaging removed most of them.

Recommendations

• Refund per line, always, with a reason.
• Six or seven distinct reasons, no more.
• Record the return payment so finance can reconcile.
• Review reasons monthly, not just totals.