Core Concepts
Three ideas explain almost everything surprising about the till. Learn them once here and the POS General page stops being a list of screens.
1. FINAL is the only moment that matters
A cash bill has a posting status. DRAFT means nothing has happened: the bill is editable, the ledger has not heard of it, and no stock has moved. FINAL is the event — but it is not a save and it is not one call. Pressing Final writes the status, allocates the branch and device running numbers, and queues a job. Everything a cashier thinks of as “the sale” — the journal, the cashbook line for each settlement, the stock movement, the member’s points, the e-Invoice queue entry — is done afterwards by separate processors, each in its own transaction, each one switched on for your tenant separately. VOID queues a different job with a narrower fan-out.
Three consequences people meet the hard way:
- Nothing stands between a cashier and FINAL except having the applet installed. There is no sign-off step (see §3).
- It is not instant, and “it did not post” is usually “it has not finished yet”. On a busy Saturday a stock line or a journal can appear a moment after the bill does. Telling the two apart before escalating is a real skill and it is worth teaching: how work actually runs.
- A void is not a rewind. Finalise has thirty-two registered subscribers and a void has ten, so several things Finalise starts have no void counterpart at all — the traded-in unit register among them, which means a voided trade-in leaves its unit standing. What a void does, what it leaves on purpose, and when BigLedger refuses one outright are on What a void undoes.
One thing the till deliberately does not set off: the webhook. The document webhook and the sales-contract processor are queued only for a sales invoice, so an integration subscribed to document events hears nothing when a shop sells something. Cash bills reach an integration through the API and the e-invoice chain instead.
2. What a cash bill posts
The cash bill’s document type carries amount signum +1 and quantity signum −1 on every line: money in, stock out. At FINAL that is Dr the settlement methods’ cashbook GL codes / Cr Sales and Output Tax, and a stock movement out of the line’s location. There is no cost-of-sales line on the bill’s journal — cost of goods sold is posted by month-end processing.
| Document | Amount | Quantity | Effect at FINAL |
|---|---|---|---|
| Cash bill (POS General) | +1 | −1 | Money in, stock out, journal, cashbook lines, e-Invoice queued |
That makes it the retail twin of the Sales module’s invoice, and the two are counted together by the sales reports and the commission run. The full family of sales documents and what each one posts is on the Sales module’s core concepts.
3. The one approval at the till, and the one hard stop
BigLedger’s document-approval engine covers three document types only — Purchase Order, Purchase Requisition and Stock Requisition. No cash bill consults it.
The one approval-shaped thing at the till is the sell-below-price request: a cashier who tries
to go under a floor price can raise a request naming an approver, and a supervisor holding
ALLOW_APPROVE_SELL_BELOW_PRICE releases that one line. It routes nothing and signs off nothing
else.
It is worth knowing exactly what that release is, because it is the product’s only built-in separation of duties. The approver authenticates on the cashier’s own terminal with their Akaun login — an e-mail address or mobile number and a password, together — and the till releases the line only if the authenticated person is the approver the request named; anyone else is refused with “User is not the assigned approver.” The grant is kept as a one-time request-history row naming who approved what. So the record is trustworthy, and the trade-off is that a supervisor types their own credential at a shop-floor terminal. Decide that consciously rather than discovering it.
Everything else that separates a cashier from a supervisor — discount, void, edit price, sell below cost, close session, cash in and out — is a plain client-side permission on POS General with no approver step at all. Whoever holds it can use it on their own work, silently. That is the gap your branch procedure has to cover, and how to cover it is on Best practices.
A cash bill has no credit limit to check. The one hard stop on a customer is the blacklist,
which rejects the cash bill with ENTITY_BLACKLISTED. That is somebody’s credit-control decision
arriving at the counter, not a fault — the cashier’s job is to name who can resolve it, not to find
a way past it by selling to a different entity.
4. How a wrong bill is reversed
flowchart TD
Q{"What went wrong?"}
Q -->|"The whole bill was a mistake,<br/>same day, at the till"| V["VOID the cash bill<br/>(ten subscribers, not thirty-two)"]
Q -->|"Goods are coming back later"| R["Sales Return<br/>stock in, sale reversed"]
Q -->|"Money back and goods back"| RN["Sales Refund Note"]
VOID is the till’s own action. Sales Return and Sales Refund Note are documents of the Sales module.
Which of these to use is a judgement, not a lookup, and it is made in front of the customer: is the original sale wrong (void), or was it right and the goods are coming back (return)? Getting it wrong is not a posting error you can see — it is a day’s figures that quietly stop meaning what the branch thinks they mean.
When e-Invoice is switched on, the VOID button disappears from a Sales Refund Note and the Cancellation tab replaces it; and a return that has already been submitted to LHDN cannot be voided until the e-Invoice side is dealt with.