Skip to content

POS Orders

The Orders screen is every sale taken at a POS terminal terminal, and nothing else. Website orders are not here.

That filter is the point. This is the list you check when you want to know what the shop took, not what the whole business took.

Go to DevDiggers Plugins → MultiPOS → Orders.

The MultiPOS orders list with order, status, revenue and staff attribution columns

Column What it shows
Order Order number and customer name, with a details toggle
Status & Date The WooCommerce status and when it was placed
Revenue The order total and the payment method used
Staff Attribution The outlet and the cashier who rang it up

Order, Status & Date and Revenue are sortable. Click a heading to reorder.

This column is the reason the screen exists.

The Staff Attribution column on a MultiPOS order row

Every POS order stores the outlet and the cashier who created it. WooCommerce has no idea who was standing at the POS; MultiPOS records it on the order itself.

That is what makes a discrepancy answerable. A refund nobody remembers, a discount nobody authorised, a void at closing time: all of them have a name attached.

The toggle on each row expands it into the full line items, so you can read what was in the basket without leaving the list.

It is the fastest way to check a disputed order. You get the basket without opening WooCommerce.

The outlet filter above the MultiPOS orders list

Screen Options at the top right sets how many rows show. It defaults to 20.

Raise it before an end-of-month check. Paging through six pages of orders is how a row gets missed.

What a POS order looks like in WooCommerce

Section titled “What a POS order looks like in WooCommerce”

Open WooCommerce → Orders and POS sales sit alongside website ones. MultiPOS adds an Order Type column so you can tell them apart at a glance.

The WooCommerce orders list with the Order Type column added by MultiPOS

An order tagged POS was taken at a POS terminal terminal. One tagged Website came through checkout.

The column is filled from the outlet stored on the order, so it cannot go wrong. An order with no outlet was not a POS sale.

  • The billing address is the shop’s, not the customer’s. POS orders are addressed to the outlet on purpose, because the sale happened there and tax should follow the shop’s location.
  • The status may already be Completed. Initial Order Status under Configuration → General ships as Completed. That is right for a counter sale and wrong if you still have to pack it. Change it there, not here.

The Initial Order Status dropdown on the General tab

There are two places to refund a POS order, and they are not equivalent.

From the terminal, with the green Refund button on the order details panel. This is the one to use for a customer standing at the counter: it writes a transaction row, so the drawer count stays right. It is a Pro feature. See How to Refund an Order.

The Refund button at the foot of the POS order details panel

From WooCommerce, with the ordinary refund controls on the order screen. MultiPOS does not take a POS order over once it exists, so notes, emails and refunds all behave normally.

A WooCommerce order showing its refund line, the refunded total and a net payment of zero

An admin refund writes no transaction row, so cash handed back at the counter is not deducted from the drawer figure. Record it as a manual cash-out on the day it happens, or refund from the terminal in the first place.

The MultiPOS transactions list showing each payment with its cashier, method and totals

Stock goes back correctly from either place, including to the right branch on a per-outlet stock store.