Best Practices

The mechanics of the till are on Core concepts and in full on the POS General reference. This page is the other half of the job: the decisions a counter still needs a person to make, and where BigLedger helps, where it does not, and who picks it up when it does not.

Give the drawer one owner at a time, and change the owner deliberately

A drawer that two people used is a drawer neither of them can answer for. BigLedger records who opened the session and which login pressed CLOSE, and nothing about the hours in between — and on the Z Report, takings are attributed to the login that keyed each payment line.

So a mid-shift hand-over is a close and a re-open: the person leaving counts, closes, and the person arriving opens a new session with that count as their float. Four minutes, and it is the difference between “this branch was RM 60 short today” and “the second shift was RM 60 short.”

Nothing enforces this. POS_CLOSE_SESSION, POS_FLOAT_CASH_IN_OUT and POS_ATTACH_DRAWER are registered permissions that no current screen checks; the Session menu appears for anyone once session and float control is on. So “only the person on the till closes it” is a branch rule, and the evidence it was kept is the signed count slip — see Balancing the Drawer.

Never let two people share one login

This one sentence carries more of BigLedger’s counter controls than any setting on this page. The audit trail, the void list, the price overrides, the Z Report’s per-cashier split and the whole client-side permission model all resolve to the login that did it. Share a login between two cashiers and every one of them stops being evidence at the same moment — not degraded, worthless.

If the reason for sharing is that a relief cashier has no login, the fix is a login, not a shortcut. If the reason is speed, the cost of the shortcut is that no shortage can ever be attributed again.

Keep the person who benefits from an exception away from authorising it

BigLedger models this properly in exactly one place, and it is worth understanding because it is the pattern to copy everywhere else.

When a cashier tries to sell below a floor price, the till raises a one-time approval request naming an approver. The approver authenticates on the cashier’s terminal with their own Akaun login — an e-mail address or mobile number and a password, together, as a login — and the till releases the line only if the authenticated person is the approver the request named. Anyone else gets “User is not the assigned approver.” The grant is kept as a request-history row naming who approved what.

Two consequences:

• A supervisor is typing their own credential into a shop-floor terminal. That is a real trade-off and your branch should decide it consciously: it is the thing that makes the record trustworthy, and it is also the thing a cashier could watch being typed. Change the password if it is ever shoulder-surfed, and never let the supervisor “leave themselves logged in to save time” — that hands the exception power to the counter permanently.
• Everywhere else, the separation is yours to keep. Void, discount, price edit, settlement adjustment and serial swap are plain permissions with no approver step. If a cashier holds them, they can correct their own mistakes silently. Decide that deliberately rather than by default.

Grant the counter’s permissions on purpose — the default is not a safe one

The whole of your control at the till is the set of 31 client-side permissions on POS General, and a client-side permission can only ever add a capability. That produces a failure mode people get backwards.

An unconfigured till is not a wide-open till. With no permissions granted, every grant-shaped control — void, return, discount, price edit, staff pricing, gross profit, the audit trail, settlement adjustment, serial swap — is unavailable to everyone, including supervisors. The price floors, which default off, have nothing to prohibit, because typing a price is itself a grant and is off too. So what you get is a counter where nothing can be corrected and the supervisor’s tools do not appear at all — and the shop works around it by sharing a supervisor’s login, which is how you lose the audit trail (above).

The practical rule: before go-live, sit at a real till as a real cashier role and as a real supervisor role, and check that each one can do exactly what it should and no more. There is no report that will tell you this. The menu that is missing and the menu that should have been missing look identical from a desk.

Teach the counter what to do when a control is simply absent

A cashier who meets a button that is not there concludes “not for me” and moves on. Sometimes that is right and sometimes it is a broken grant, and the two look the same — a list that renders empty rather than a refusal is the shape to watch for, because a silent authorisation failure at the counter looks exactly like “there are no options”.

So the instruction to the counter is: an empty list is a report, not an answer. Name the screen, the time and what you expected; a supervisor checks the permission rather than the data. This costs a cashier ten seconds and saves the alternative, which is a shop quietly deciding that a feature does not work.

Decide what a cashier refuses, and give them the sentence to say

Half the pressure at a counter is a customer asking for something the cashier is not authorised to give: a bigger discount, a return without a receipt, a price that was on a shelf label last week. The job is to refuse without arguing and keep the queue moving, and that needs three things decided in advance and written where the till is:

1. What this branch will do without a supervisor — and the honest answer is usually “nothing that changes a price or reverses a sale.”
2. Who to call, by name and by shift, not “a supervisor”.
3. What the customer is told meanwhile. A refusal with a named next step is not an argument; a refusal with “the system won’t let me” is.

Where BigLedger refuses, it refuses for a reason and the reason is on screen. A blacklisted customer is rejected at FINAL with ENTITY_BLACKLISTED — that is a credit-control decision somebody took, not a fault, and the cashier’s job is to name who resolves it, not to find a way round it by selling to a different entity. A settlement that does not match the bill to the cent is refused — almost always a missing rounding line, not a price problem, and never a reason to change a price to make it fit.

Defer the corrections that can wait, and leave evidence when you do

Some things have to be fixed now and some must not be fixed in front of a customer. The dividing line is whether money or stock moves.

Now, at the counter: a serial scanned wrong (Swap Serial Number — no money moves); a bill that was entirely a mistake, same day (VOID, with a reason).

Later, by a supervisor: a payment rung up under the wrong method (Settlement Adjustment). It deletes and reposts the journal and the cashbook on the bill’s original date, which restates a day finance may already have reconciled. Doing it at four o’clock with three people in the queue is how a RM 20 correction becomes a bank-reconciliation break.

Deferring is fine; deferring silently is not. What has to survive is the bill number, what is wrong with it and who noticed — and the till has no place to write that down. The Remarks box on the session’s closing screen is not saved. So it goes on the shift’s paperwork, and the supervisor clears the list before the day’s takings are reconciled.

Decide what the queue behind the customer is allowed to read

A counter screen faces a public room. Two settings exist for exactly this and they are usually left at their defaults because nobody has framed them as a privacy decision.

Member details. POS_HIDE_DOB and POS_HIDE_MEMBER_PHONE_NO remove the date-of-birth and phone columns from the member search — and they also suppress them from the column tool panel, so a cashier cannot put them back. Switch them on unless a specific counter task needs the field. How you know it worked: open the member search at a real till and confirm the columns are gone from the grid and from the column chooser.

Your own costs and margins. The item’s Stock Details tab shows the company’s average cost, last cost, replacement cost and the four price floors and ceilings, and POS_GROSS_PROFIT shows margin on the bill. Both are legitimate for a supervisor deciding whether to hold a price. Both are also a screen a customer can read over a shoulder, and a number a leaving employee can remember. Grant them to the role that needs them, not to the till.

And the part no setting covers. Buyer identity for an e-invoice — a tax number, an identity-card number, an address — is collected at a counter, out loud, in public. Collect only what the document needs, read it back quietly or not at all, and never repeat an identity number to confirm it. The till checks that these fields are present, never that they are correct, so a mistyped number passes the counter and fails later at the authority — which means the reading-back has to be done with the customer’s own screen or paper, not by a cashier announcing it.

Do three reconciliations every day, not one

1. Counted cash against the Z Report’s Cash row, per till, before the cashier leaves — and the expected figure is one you work out yourself, because nothing in BigLedger computes it. The method is Balancing the Drawer.
2. The daily collection summary against the cashbooks. This is the one that catches a settlement method pointing at the wrong cashbook, which the Z Report cannot see because it never looks at an account.
3. A spot check that finalised bills have journals. A bill can sit at FINAL with no journal behind it when a default GL code is unmapped — the posting job fails after FINAL — and nothing at the counter says so. Financial Report › Error Checking › Trace Document for one bill; Ledger And Journal › Error Checking › Missing Journal for a whole day.

Each of these has an owner or it does not happen. BigLedger schedules none of them, alerts on none of them, and does not notice when one is skipped. Put a name against each at the branch, and let the evidence be the exported report rather than somebody’s memory.

Fix the three go-live failures before go-live

The till’s location matching the branch’s default location, the rounding adjustment item, and a GL code on every settlement method. The first two fail at FINAL, with a customer standing there. The third lets the bill finalise and fails the posting afterwards, with the customer gone and nobody told. All three are on the Configuration page. Then check the ones that never fail: every sales, output-tax and settlement-charge code needs a company default. Without one, the line is left out of the journal and trade debtors take up the amount — on a RM 106 bill (RM 100 goods, RM 6 SST) with no sales code, sales are RM 100 short and the receivable carries a RM 100 credit, while the bill, the cashbook and the journal all look correct. You notice it when trade debtors move on a day of cash sales, or the ledger’s sales fall short of the Z Report. Post one test bill before go-live and read its journal.

And one that fails quietly rather than loudly: set up the return reasons. Until somebody adds the codes, the Reason drop-down on a counter return is empty, and a return taken without a reason is a return nobody can analyse afterwards — which is the whole point of collecting it.