inmake DOCS
Docs / CRM & Studio / Orders, invoices & carts

Orders, invoices & carts

Managing orders and their invoices; leftover carts.

Orders#

Shop › Orders lists every order with its status, customer, total and date. Orders are created by the storefront through the Process routes — CRM & Studio edits them, it does not place them. (The Ready orders dashboard widget lists what is waiting to ship and links into it; it does not change anything by itself.)

Opening an order gives you:

  • Status — the order's current state on the left, and every state it may legally move to next as a button beside it. Picking one confirms what will happen, then writes it: the platform runs the consequences (stock, payment, invoice numbering) and records the hop in the order's history. Cancel order closes it, releases reserved stock and cancels any uncaptured payment — it does not refund a captured one.
  • Items — each line with its product name, picture and price, and whether the stock check cleared it: confirmed, out of stock, or not checked when the check has not run. Those marks come from the check itself and are not edited by hand; Re-check stock runs it again over the whole order. Below the lines: subtotal, discounts, credits, VAT and total.
  • Payment — the service (and, for a payment gateway, the method), its state, the amount, and every payment attempt made against the order. Refresh payment re-reads the live payment from Stripe or the gateway when a notification was missed. An order paid in cash, on delivery or by bank transfer shows Pay at handover until the money is in: Mark paid records it (and Mark unpaid takes back a payment you marked by mistake) — both for owners and admins; a cash-on-delivery order is marked paid by itself when the carrier, or the project's order system, reports it delivered. A yellow payment alert appears when a gateway reported money the platform could not act on by itself — the order was paid after it was closed, paid without the payment ever being recorded, refunded at the gateway, or reported with a different amount. Settle it in the gateway's own portal, then an owner or manager presses Resolved. Refunds are not supported here — use your payment provider.
  • Delivery — the delivery address and contact, editable and saved with the page's Save; and the shipping service, when the project has one.
  • Order system — when an order-system module is installed: where the order went, see Order system below.
  • Shipment — the carrier, the delivery method and pickup point the customer chose, the tracking number and the last tracking event. Create shipment (from a ready or confirmed order with a complete address) books it with the carrier; Print label opens the label (ZPL downloads); Refresh asks the carrier for news; Cancel shipment cancels it at the carrier where the carrier allows it. The shipment moves the order status by itself — shipping when it is booked, delivery when it is out for delivery or waiting at the pickup point, completed when delivered — and every tracking event lands in the order's history. The platform also checks live shipments on its own every half hour.
  • Customer, Invoice, Promo, the internal Note, and the full status history. Besides the status hops the history lists events, each with an icon and its outcome: Shipment rows are the carrier's tracking events (with the parcel state), and rows reported by provider modules — Processing (the order system's events: pushed, accepted, packed, shipped, delivered, returned, cancelled, warnings and reference changes), Payment, Invoice — appear the same way.
  • Advanced — the raw document editor, for managers, when a field has no home above.

Status changes and the payment actions take effect immediately. The note and the delivery address are buffered and land when you press Save.

An order that stays confirmed but unpaid past its deadline is closed automatically by the platform's hourly sweeper; the deadline is shown on the status card while it applies.

Order system#

A project can hand its paid orders to an external order system (a warehouse, an ERP, an order hub) through an installed module that provides orders. Pick it in Settings › Setup › Order under Order system — owners and admins only; a module must be enabled and verified before it can be picked, and a disabled or unverified one stays listed but greyed out. The switch is recorded in the processor history below the picker (when, to what, by whom). Switching never moves orders that are already waiting at the previous module: they stay with it, and the switch tells you how many there are. With a module selected, the section also shows its configuration card, how many orders are currently waiting for it, and Auto-update status from the order system (saved with the section).

From then on every order is pushed once, when it first becomes ready (or active) with its number. A push that fails never holds the order — it keeps its status, and the order page says what went wrong. The Order system card on the order shows:

  • the system's own order number and when it last reported, its status (Pushed, Accepted, Packed, Shipped, Delivered, Returned, Cancelled), the packages it shipped with their tracking links, Open in {system} when the system gave a back-office link, and its warnings;
  • while a push is open: Sending to the order system, or after two minutes The order system did not answer, with Retry now; a failed push shows the error and whether the system thinks a retry will help, with Retry now and — for owners and admins — Reassign, which pushes the order through the project's current order system instead (check the old one first, it may already hold the order);
  • Push now on a ready, active, shipping or delivery order that was never pushed (e.g. one created past ready, or numbered before the module was selected).

With Auto-update status on, the system's reports move the order: Shipped → shipping, Delivered → completed (which issues the invoice), Returned → returned. A platform shipment (Shipment card) takes precedence — then the reports are only recorded. A Cancelled report never changes the order by itself; the card shows a banner and you decide. Closing a pushed order sends the cancellation to the system when the module supports it; if that fails, the card lists the warning and the order has to be cancelled there by hand. To be told about cancellations, add an orders notification hook with the filter processing.status: cancelled on update.

Invoices#

Invoices are generated for orders and listed under Shop › Invoices — the project never creates one by hand. Opening one shows the issued document: who issued it and who it was billed to, the billed lines with their VAT and totals, and the links back to the order and the customer. Beside them is a preview of the invoice as the customer receives it, rendered from the project's invoice template (custom → legacy → the bundled default), with HTML / Print / Web tabs and a fullscreen view.

Send to customer e-mails the invoice to the address on it, after confirming the recipient.

An invoice is a snapshot taken when its order completed, so nothing on the page is editable — corrections go through Advanced, which replaces the whole document and is for managers only. The number sequence and the issuer details come from Settings › Setup › Invoice; an issuer left empty there falls back to the project address. An invoice issued by an invoicing module shows the provider's document instead — see Invoicing provider.

Carts#

Shop › Carts lists leftover storefront carts — age, owner, items, expiry — with single and bulk delete; clicking a row opens the cart's items (each SKU links to its product) and the shopper's locale, promotions and note. Carts are inert pre-order documents written only by the storefront; they expire on their own, fire no hooks and cannot be edited.

Access#

The commerce capability: read to see the lists, write to change statuses or delete carts and to Retry now / Push now an order. Switching the order system and Reassign are for owners and admins.