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. It is written for the operations manager who sets the rules for every branch and the branch supervisor who keeps them, and each practice says who decides, when, what you will see when it slips, and how you know it held.

Meet the example. GadgetSphere Sdn Bhd runs 22 branches across three companies. On a Thursday at GS-KV-07 the cash drawer on till 2 is RM 60 short. Two cashiers worked that till, one supervisor corrected a payment method at four o’clock, and the till lost its connection for an hour after lunch. Whether anyone can say whose RM 60 it was depends almost entirely on decisions made before Thursday, and the practices below are those decisions.

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 credited to the login that created each bill.

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 the till’s code never 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.

Who decides: the operations manager, once, for every branch. What you see when it slips: a session listing with one session covering two cashiers’ hours, and a shortage nobody can place. How you know it held: each day’s session listing shows one opener per session, and every session has a count slip signed by the person who closed it.

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.

Give each login an e-mail sign-in, too. The till’s Z Report finds each cashier through their e-mail user name, and a bill created by a login without a live one drops out of the per-cashier takings with nothing on the report to say so — a known issue, reported to engineering. Cashier Collection still lists those bills, which is how you notice.

How you know it held: the per-cashier lines of the day’s Z Report add up to the same total as Cashier Collection for that day, and every name on either is one person.

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 a basic (stock) item below a floor price, the till raises a one-time approval request naming an approver; other kinds of line are not checked against a floor. 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 decision is recorded against the approver, so the request history names 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.

How you know it held: the approval history for the month names supervisors only, and none of them appears as the cashier on the bills they approved.

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, read by the till’s screen. They are controls on the screen, by design: a bill written through the API does not consult them, and that is the reason a group integrating another channel keeps its own rules there.

On the till, a control takes one of three shapes, and the default differs by shape — which is why people get the default backwards:

So an unconfigured till is wrong in both directions at once. Nothing can be corrected — no void, no discount, no settlement adjustment, and the supervisor’s tools do not appear at all — while every cashier can take a return and read your costs. The shop then works around the first half by sharing a supervisor’s login, which is how you lose the evidence (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. No report will tell you this. The menu that is missing and the menu that should have been missing look identical from a desk.

Who decides: the operations manager writes the list of what each role may do; whoever administers roles grants it. How you know it held: the two sit-at-the-till checks, repeated after every change to a role.

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: a role whose report permission has no branches attached sees an empty branch drop-down on the Z Report, not an error — and 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. There are three common answers, and each has a cost:
   • Nothing that changes a price or reverses a sale. The cleanest record and the longest queue on a busy Saturday; the supervisor becomes the bottleneck, and the pressure to share their login rises.
   • Small corrections up to a fixed amount, such as a discount of RM 20 or a same-day void. Faster, and every cashier holding the permission can then correct their own mistakes with nobody else looking — so the supervisor reviews the void list and discount split daily instead of approving each one.
   • Anything the cashier judges right, reviewed afterwards. The fastest counter, and the review is the only control left; it works only where someone actually does it.
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 bill whose payments do not equal its goods to the sen 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 replaces the bill’s journal and cashbook lines on the bill’s original date rather than reversing them, 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.

How you know it held: every settlement adjustment in the listing for the week matches a line on a shift’s paperwork, and none is dated in a period finance has already closed.

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 — across the groups we can see, very few hide a member’s phone number or date of birth at the counter.

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. Hiding them costs the cashier a way to confirm a member by sight; showing them puts both on a screen a stranger can read. How you know your choice holds: open the member search at a real till and confirm the columns are where you decided — gone from the grid and from the column chooser, or present.

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 it is open to every cashier until HIDE_STOCK_DETAILS is switched on; POS_SHOW_STOCK_DETAILS then reopens it for a role. The gross-profit panel (POS_GROSS_PROFIT) is the other way round: nobody sees it until it is granted. 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. How you know it held: sign in as the cashier role, open any item, and confirm the tab is where you decided.

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.

Who decides all three: whoever owns personal data and pricing confidentiality for the group — usually not the branch.

Empty the offline queue before you count the drawer

A till running in offline mode keeps selling when the connection drops and holds its finalised bills in a queue in that browser on that till. When the connection returns, it sends them, oldest first, and each keeps the date it was rung up on. Four things follow for the person closing the day:

• The Z Report you print before the queue empties is short. For example, at GS-KV-07 the hour offline after lunch was 9 bills, RM 1,840.00 of them paid in cash, that the server had not yet seen. Count against a Z Report printed then, and the drawer looks RM 1,840.00 over; sign it, and the same Z Report run on Friday disagrees with the signed copy.
• The queue only sends while the till is connected and offline mode is still on. Switch offline mode off at that till before it has emptied and it stops sending — and the Transaction Queue tab goes with it, so the bills are still waiting on that till with nothing on screen to say so.
• In offline mode, a draft stays on that till. The queue sends only finalised documents, so a draft kept there (an edit you chose to keep, or a card payment that could not finalise) waits until someone finalises it at that till.
• Sync waits for the connection. The queue’s sync button and every re-sync under Offline Settings refuse while the till is offline, so fix the connection first.

So at close the supervisor checks that the till’s Transaction Queue tab — present while offline mode is on — is empty before printing the Z Report, and if a till comes back late, re-runs the affected day and compares it with the signed copy. How you know it held: every queue is empty at close, and the next morning’s re-run of yesterday’s Z Report matches the signed PDF.

Do three reconciliations every day, not one

Every figure at a till is a live figure, recomputed each time you run the report, from the bills as they stand at that moment: the Z Report stores nothing. A bill that arrives late from an offline till, a bill backdated by someone holding the permission, or a settlement adjustment changes yesterday’s answer tomorrow. That is why each check below ends with something exported and signed — the export is the only fixed copy of the day. The full routine, with the figures for one Saturday, is on Reports › Closing the day.

Counted cash against the Z Report’s Cash row

Per till, before the cashier leaves. The expected figure is one you work out yourself, because nothing in BigLedger computes it: the Cash row, plus the opening float, less any cash dropped mid-shift. The method is Balancing the Drawer.

Each payment method’s cashbook against its row on the Z Report

The next morning, Cashbook › Enquiries › Query Cashbook Transaction for each payment method’s cashbook, against that method’s row on the signed Z Report. Cash agrees to the sen; card and e-wallet are lower by exactly the method’s charges. This is the one that catches a payment method pointing at the wrong cashbook, which the Z Report cannot see because it never looks at an account. (The Daily Summary sales report will not do this job: it reads receipt and payment vouchers, not cash bills.)

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. An empty list means every FINAL bill has its journal.

Who owns each

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. At GadgetSphere the branch supervisor owns the first at close, and finance owns the second and third the next morning. 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.

Two that fail quietly rather than loudly:

• Scan the test item, then pick it from Add Item. A scanned barcode takes the branch’s Default Pricing, or the applet’s default scheme when that is empty; Add Item takes the highest-priority scheme in the branch’s own list. If the two prices differ, two settings disagree — and your cashiers will find out at the counter.
• Set up the return reasons. A reason is never required: with the reasons list switched off, the cashier gets a free-text box, and with it on and no reasons loaded, the only choice is Others. Either way a return taken without a proper reason is a return nobody can analyse afterwards — which is the whole point of collecting it.

When a practice has slipped — what you will see

The till checks a member’s points balance on screen before it accepts a redemption; the server repeats that check only when the caller asks, and the till does not ask. That is a screen control, like the client-side permissions: a redemption arriving through the API is held to whatever that channel checks.

How you know the practices are holding

Once a month, at one branch, in fifteen minutes:

1. Sign in as the cashier role at a real till. Confirm Stock Details, returns and the member columns are exactly where your rules put them, and that void and settlement adjustment are absent.
2. Sign in as the supervisor role and confirm void, settlement adjustment and the approval history appear.
3. Open last week’s session listing: one opener per session, a signed count slip for each.
4. Re-run last Saturday’s Z Report and compare it with the signed PDF. Every difference has a written reason.
5. Run Missing Journal for last week’s cash bills. The list is empty.

If all five pass at a different branch each month, the practices are being kept and not merely written down.

What these practices depend on, and what they touch

What must exist first. Every practice here depends on one login per person, with an e-mail sign-in, and on roles that were granted on purpose — without those, the evidence each practice relies on does not exist. The drawer practice requires session and float control to be switched on.

What becomes possible. A drawer with one owner and a signed slip lets you name a shortage instead of absorbing it. A reconciled cashbook is what the bank reconciliation of the card and e-wallet accounts starts from.

The sibling, and when to use which. Balancing the Drawer is the step-by-step count for one cashier at close; this page is the set of rules a group writes once, rather than a procedure. Use the guide at the till, this page in the meeting that decides the rules.

What breaks elsewhere if this is wrong. A payment method on the wrong cashbook breaks reconciliation for every branch that uses it. A settlement adjustment made after a day was reconciled unmatches that day in the bank reconciliation. An unmapped sales code moves trade debtors in Financial Accounting on a day of pure cash sales.

What it pairs with in practice. Where the counter redeems points, the counter rules are written alongside the membership rules — who may take a redemption, and who corrects a member’s balance when one goes wrong. The programme’s side is on Membership › Best practices.

Read next

Reports — where each end-of-day figure comes from, and the full routine for closing the day so that it stays closed.