Point of Sale Module
This module is the checkout counter: one cash bill, settled on the spot by cash, card, e-wallet, voucher, points or contra, rung up all day at speed, and balanced at the end of the shift. The receipt prints first; everything the bill 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. Raising an invoice on terms is a different job, done by different people, with different failure modes — so the business-to-business documents have their own Sales module. The two share a document engine, the same master data, and the single moment — FINAL — at which a bill becomes an accounting fact.
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. Creates a cash bill, settles it by cash, card, e-wallet, voucher, points or contra, and on FINAL starts the jobs that take the goods out of stock, post the journal and the cashbook line, and queue the bill for e-Invoice. Also holds session open/close, float counts, the Z Report and settlement adjustment. |
| POS Customer Display | The second screen the shopper sees. It writes no document at all; it reads the till’s browser database and shows the basket. |
| Daily Cashier Reports | Read-only. The 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 — and carries the electronic-shelf-label sync history a branch uses — is Custom Processor, listed under Sales because it works on any FINAL sales document.
What reaches the ledger
One document. The cash bill’s server document type carries amount signum +1 and quantity signum
−1 on every line — money in, stock out — and FINAL starts all of this in background jobs, not in
the button press: Dr the settlement methods’ cashbook GL codes / Cr Sales and Output Tax; stock out
at the line’s location; a cashbook line per settlement; the e-Invoice queue entry; and, if the bill
carries a member, the point transaction — but only where the company’s member-point configuration
names the cash bill, because the backend’s default awarding document is the sales order. There is
no cost-of-sales line: cost of goods sold is a month-end journal. The bill posts through the
SALES journal handler — the same one the Sales module’s invoice uses — so the two are counted
together by the sales reports and the commission run.
Each of those jobs is a separate subscriber that a tenant switches on separately, which is why
“FINAL posts the journal” is true of a normal installation and is not a law. One card sale at
GS-KV-03, followed through all nine consequences, is on
Core concepts › One bill, followed through.
A cash bill that was wrong is voided the same day. A void is narrower than a finalise — eleven subscriber links in the registry, one of them confined to sales orders, against thirty-two — so it is not a rewind, and what it leaves standing on purpose is on What a void undoes. Goods that come back later go through a Sales Return or a Sales Refund Note — documents of the Sales module. Neither of those appears on the Z Report the cashier presses in POS General, which reads FINAL cash bills only; a return taken at the counter does, because it is return lines on a cash bill. The Z Report of the same name in Daily Cashier Reports does count returns and refund notes, so the two disagree by design.
Where the figures at the till come from
At a counter the question is rarely how do I ring this up — the screen shows that. It is why is this figure not the one I expected. Each figure below is either written once by a job and kept, or worked out again every time somebody looks, and knowing which tells you where to look.
| The figure | Written when, from what | So, when it looks wrong |
|---|---|---|
| The price on a bill line | Chosen at the counter, by how the item was added. A scanned barcode takes the price from the branch record’s Default Pricing field, or the applet’s Default Pricing Scheme when that is empty. An item picked in Add Item takes the highest-priority scheme in the branch’s Pricing Scheme list that the item is priced in. A cashier can switch a line only to the schemes linked to their role; a customer with a pricing scheme of their own has it pre-selected; and changing the customer on the bill re-prices every line | One item rung up at two prices, scanned against picked, is the two routes disagreeing — line the branch’s default up with the top of its priority list (POS General › Branch Settings) |
| The takings on the till’s Z Report | Summed on the server each time you run it, from FINAL cash bills whose transaction date is the chosen day; with a device chosen, only bills stamped with that device | Bills missing: run it with Device on All. A backdated bill counts on the day it is dated, not the day it was keyed (Reports) |
| Variance on the same report | Worked out in your browser: the drawer’s cash movement minus total net sales of every tender | Negative by roughly the day’s card and e-wallet takings — arithmetic, not missing money. Balance the drawer against the Cash row (Balancing the Drawer) |
| The cashbook line | Written by the posting job: the tender less the settlement method’s charges, dated the bill’s transaction date | Lower than the till by the card fee, every day, by design — it is the figure the acquirer pays you, which is why Bank Reconciliation can match it |
| The journal | Written by the posting job, resolving each line’s GL code from the item, the settlement method and the company defaults at that moment | A line whose code resolves to nothing is left out and the customer’s receivable line absorbs it, so the journal still balances (Configuration §2) |
| The cost on the bill’s line, and the counter’s gross profit | The costing step writes the cost back onto the line after the stock movement exists; the counter’s gross-profit panel reads the item’s moving average live | A margin report run seconds after a busy hour can read lines with no cost yet, which looks like selling at zero cost. Neither reconciles bill by bill with the ledger (Core concepts §2) |
| Cost of sales in the ledger | A month-end journal, rewritten on every run, from opening stock, purchases and closing stock — no line of any bill is read | Empty for the month until month-end processing runs |
| A member’s points from a bill | Point lines are written on the bill at save; the points transaction by its own job, only where the company’s member-point configuration names the cash bill | Points on the bill and none in the member’s balance: the configuration names another document — by default the sales order — or your tenant holds no points subscriber (Configuration §6) |
Three things this module is often believed to do, and does not
It does not approve anything. There is no sign-off step on a cash bill. The only “approve” at
the till is the line-level sell-below-price grant: a cashier who tries to go under a floor
price raises a request, and a supervisor holding the approve-sell-below-price permission
(ALLOW_APPROVE_SELL_BELOW_PRICE) releases that one line. It routes nothing and signs off nothing
else. Everything else that separates a cashier from a supervisor is a client-side permission with
no approver step — so the separation of duties is the branch’s procedure, set out on
Best practices.
It does not check a credit limit — a cash bill has no credit. The one hard stop on a customer
at the till is the blacklist, which rejects the cash bill with ENTITY_BLACKLISTED. That is
somebody’s credit decision arriving at the counter; the cashier’s job is to name who can lift it.
It does not balance a drawer. The session-close screen stores the closing total and computes no difference between it and the float; the Z Report prints a Variance, but that line subtracts total net sales — card and e-wallet included — from the cash movement, so it is not the drawer difference either; the money moving in and out mid-shift never reaches the shift’s own report; the closing denominations are not stored and the closing remark is not saved. The arithmetic, the explanation and the custody chain belong to the branch — Balancing the Drawer is the procedure, and Banking the Day’s Takings picks the money up where the product does.
What this module needs from others
| Module | What it supplies |
|---|---|
| Core | Customer Maintenance (the walk-in customer and any member’s record), Doc Item Maintenance (items and the adjustment items for rounding, group discount and member-point discount), Organization (company, branch and the branch’s default location), Pricebook, Tax Configuration, Cashbook and its settlement methods |
| Financial Accounting | The Chart of Account company defaults every posting resolves against — DEBTOR (the receivable; its absence stops the posting of a bill that needs a receivable line), SALES, SALES_DISCOUNT, OUTPUT_TAX, SETTLEMENT_CHARGES once any method carries a charge, and COGS for month-end cost-of-sales processing |
| Inventory | Stock Balance, Stock Report, Non Stock and Trade In for counter trade-ins |
| Sales | Sales Return and Sales Refund Note for goods that come back after the day; Sales Report and Sales Commission, which count cash bills alongside invoices |
| Membership | Membership Admin — the member, the point currency and the rate |
| E-Invoice | The submission pipeline every FINAL cash bill is queued into |
How the pieces depend on each other
What must exist first, and how you find out it does not. Apart from a closed fiscal period, only
two gaps refuse FINAL with the customer standing there: a till location that is not the branch’s default location, and
settlement that does not equal the bill’s lines to the cent — the gap a rounding adjustment
item exists to close. Everything else is read by the posting jobs afterwards. Settlement
methods each need a cashbook, and the cashbook a GL code, or the bill finalises and its
posting fails later with MISSING_CASHBOOK or MISSING_GL_CODE. The company needs a receivable
default (DEBTOR) — the one default whose absence raises an error, and only on a bill that needs a
receivable line, such as one settled partly by a contra or one where another code is missing — and
sales, output-tax and charge defaults, whose absence raises nothing at all. The ordered list, with the symptom of each
gap, is Configuration.
What a FINAL bill makes possible. The month’s consolidated e-invoice, built from the pool rows FINAL bills leave behind; bank reconciliation against cashbook lines that already carry the acquirer’s net; loyalty — points earned on the bill and redeemed as a settlement; the commission run, which credits the bill to its sales agent; and the Sales module’s reports.
Siblings, and when to use which.
- Cash bill or sales invoice? The invoice is the same journal handler with credit terms. Use it when the customer pays later, when the sale must be dated more than a week back (the till’s backdate stops at seven days), or when an integration must hear about the sale — the document webhook is queued only for a sales invoice. Use the cash bill when the money arrives with the goods.
- Void, return or settlement adjustment? Void when the bill itself was a mistake, the same day. A Sales Return or Refund Note when the sale was right and the goods come back. A settlement adjustment when only the tender was wrong — Cash pressed for a card: it keeps the bill FINAL and replaces the old journal and cashbook lines rather than reversing them (Changing the method after the sale).
- Which Z Report? The till’s reads cash bills only and carries the session and drawer blocks; Daily Cashier Reports’ reads four document types. Agree with finance which one is the day’s figure.
What breaks elsewhere when this module is set up wrong.
- A settlement method pointing at the wrong cashbook breaks bank reconciliation for every branch that links it, because one method is shared by all of them. The Z Report cannot see it — it never looks at an account, and nor does the daily collection summary, which reads receipt and payment vouchers only. The check that does is each method’s cashbook in Cashbook › Enquiries › Query Cashbook Transaction against the Z Report’s takings for that method (Reconciling a cash-up, Step 4).
- A card method with charges and no
SETTLEMENT_CHARGESdefault moves every card fee into trade debtors against the walk-in customer, and the receivable account stops agreeing with the ageing. - A settlement adjustment on a bill in a month already reconciled silently unmatches the old cashbook line, and the signed-off reconciliation no longer balances. Undo the match first.
- Switching e-invoicing on for a company changes what a void means for its sales documents; for the cash bill, cancel the e-invoice first and void second (Core concepts §4).
What it pairs with in practice. The journal and cashbook subscribers travel together: the cashbook line is the reconciliation’s half of the same posting, so a tenant with one and not the other has sales in the ledger and nothing for the bank side to match. Membership changes the counter most — once a member is on the bill, the member class is what the till prices by, not the member’s labels (Core concepts › Member labels). And e-invoicing pairs with the void rules above.
When it goes wrong
Trouble at a counter usually shows up as a number that looks wrong, after the customer has gone. The cause is generally one setting, somewhere the till does not show.
| What you see | Why | What to do |
|---|---|---|
| Every bill from one till is refused at FINAL with a location mismatch | The till’s location is not the branch’s default location | Line them up in Organization (Configuration §1) |
| FINAL is refused because settlement and lines differ by a few cents | No rounding adjustment item | Create it and set it on the branch or company (Configuration §4) |
| Every bill at every branch is FINAL and none has a journal | The journal subscriber is not switched on for your tenant — not a GL-mapping problem | Ask BigLedger support which posting subscribers your tenant holds before anyone touches the chart of accounts (Core concepts §5) |
| One bill is FINAL with no journal and no cashbook line | Its posting job failed: the settlement method has no cashbook, the cashbook has no GL code, or DEBTOR is unmapped | Fix the method or the default, then Trace Document → Resolve on both halves (Payment aggregators › Common mistakes) |
| Trade debtors move on a day of nothing but cash sales; the ledger’s sales fall short of the Z Report | A SALES, OUTPUT_TAX or SETTLEMENT_CHARGES default is unmapped: the line was left out and the receivable absorbed it | Map the default, then repost the affected bills (Configuration §2) |
| The till’s Z Report misses bills that are in the Cash Bill Listing | A device was chosen on the report, and those bills were written without one or on another | Run it with Device on All; then register the terminal |
| The Variance line shows a large shortfall every night | It subtracts the takings of every tender from a cash-only movement | Reconcile the drawer against the Cash row (Balancing the Drawer) |
| The same item rings up at two prices | Scanned and picked items read different pricing settings | Make the branch’s Default Pricing the top of its priority list (above) |
| An item the stock report shows is missing from the counter’s search | No stock at the session’s location, or the item’s category is outside the branch’s filter | Check stock by location, then the Item Category Filter (POS General › Troubleshooting) |
| A payment button is missing, or appears twice | The method is not linked to the branch, its link is not active, its item carries no settlement type, or it was linked twice | Payment aggregators › Common mistakes |
| You voided a cash bill and its e-invoice still reads Valid | The void never reaches LHDN | Request cancellation in My E-Invoice Admin within 72 hours of validation; after that, a credit note (Core concepts §4) |
How you know it worked
Nothing on the till answers this: it shows FINAL, prints, and moves on. Run this once on the first
bill of every new branch and every new settlement method, before the first night’s cash-up depends
on it. Ring up one small item at GS-KV-03, settle it by card, give the jobs a moment, then:
- The bill. Financial Report › Error Checking › Trace Document, cash bill, the bill’s Doc No: a posting journal is shown and the Missing Journal and Missing Cashbook checks both pass.
- The money. Cashbook › Enquiries › Query Cashbook Transaction on the card method’s cashbook, the same Doc No: one line, for the tender less the method’s charges, dated today.
- The stock. Stock Balance for that item at the branch’s default location is one lower.
If any of the three is missing, the row above with the same symptom names the page that fixes it. For a whole day rather than one bill, Ledger And Journal › Error Checking › Missing Journal for the cash bill type lists every FINAL bill with no journal behind it — an empty list is the result you want. Who runs it, and when: the branch supervisor every day, as the third of the three daily reconciliations, and finance on the first trading day after any change to a settlement method or a company default GL code. BigLedger schedules none of these checks and raises no alert when a posting job fails, so each needs a name against it at the branch.