Point of Sale Module
This module is the checkout counter: one cash bill, settled on the spot by cash, card, e-wallet, voucher, coupon, cheque, bank transfer, points or contra, and balanced at the end of the shift. The bill is normally FINAL at once; everything it sets off in the books follows a moment later, each piece as its own background job, and most of what goes wrong at a counter goes wrong in that gap, after the customer has left. Invoices on terms have their own Sales module, sharing the document engine, master data and the moment — FINAL — a bill becomes an accounting fact.
Start here.
- Opening a branch or a payment method? Read Configuration — it includes the counter hardware and offline mode — then Payment aggregators and settlement for the payment buttons, and run the thirty-second check in Core concepts §6 on the first bill.
- The drawer does not match the till at cash-up? Count it against the Z Report’s Cash row: Balancing the Drawer works out what you should have found and names the difference. Next morning, Reconciling the Day’s Cash-Up to the Accounts ties the day to the books.
- Working the counter — ringing up, fixing a bill? Cash Sales Workflow walks it step by step.
- A customer bringing something back? It is returned on a new bill, never the old one: Take it back on the till.
- A number at the till looks wrong? Start from the table in Core concepts §5; when two reports disagree, Reports says which figure each one counts, and When two numbers don’t tally routes the rest.
The module’s pages
Applets in this module
Membership is an editorial judgement — the product has no module↔applet relationship in its data.
| Applet | What it is for |
|---|---|
| POS General | The checkout counter: the cash bill, its settlement, session open and close, float counts, the till’s Z Report and settlement adjustment |
| POS Customer Display | The second screen the shopper sees. It writes no document |
| Daily Cashier Reports | Read-only: its own Z Report and Cashier Collection, for balancing a shift |
One registry applet belongs to this module and has no page yet: Exchange Return Refund Policy. The hand-off queue that pushes finalised documents to external systems, with the electronic-shelf-label sync history, is Custom Processor, listed under Sales.
What the till does not do, and what to do instead
| It does not | What to do instead |
|---|---|
| Work out the drawer difference at session close. The cashier enters one closing total; the closing denomination count and the close remarks are not kept | The supervisor counts the drawer, compares it with opening float + cash in − cash out + cash takings (the Z Report’s Cash row, not its Variance line), and records the difference and its reason on paper. Balancing the Drawer is the procedure |
| Pre-select the branch’s default Voucher or E-Wallet method. The other seven branch defaults apply | The cashier picks the voucher or e-wallet method on the payment screen |
| Take its payment buttons from the platform’s built-in list of payment channels, which is reference data only | The buttons at the till are the settlement methods you set up and link to each branch (Payment aggregators and settlement) |
| Limit a void to the same day. Any FINAL bill with no later document against it can be voided by a user holding the void permission, and the server’s e-invoice check does not stop it | Give the void permission to supervisors only, void the same day as a house rule, and read the bill’s E-Invoice tab first (why) |
Related documentation
- Sales guides — cash sales, balancing the drawer, banking the day’s takings
- What a void undoes — what voiding a cash bill leaves standing
- Sales module — returns and refund notes for goods sold on terms (a till sale is returned on the till)