Configuration
Nothing at the till is configured at the till. A cash bill draws on company structure, GL defaults, cashbooks, items, customers, tax codes and printable formats that all live elsewhere. Two gaps refuse FINAL in front of a customer: a till location that is not the branch’s default location, and settlement that does not equal the bill. Most of the rest are read only by the posting that runs after FINAL, so the bill finalises and the posting fails later, with the bill FINAL and no journal — or, for the sales and tax codes, nothing fails at all and the ledger is quietly wrong. This page lists what must exist, where it is set, and what each gap looks like, so you can recognise it from its symptom.
The order below is a dependency order, not a rule the product enforces. Nothing stops you doing it out of sequence; you will simply hit the failures later — on the first Saturday.
1. Company structure
| What | Where | If it is missing |
|---|---|---|
| Company, branch, location | Organization | The platform refuses a document with no company or no location, so no bill is saved until they exist |
| The branch’s default location, and the till’s location matching it | Organization | A cash bill whose location is not the branch’s default location is refused at FINAL: the location does not match the branch’s default location. This one is checked at FINAL; a branch with no default location recorded is not checked at all |
| Fiscal periods open for the transaction date | Chart of Account | FINAL is refused — this one is checked before FINAL |
2. General ledger defaults
The company default GL mapping is where every posting resolves when a line carries no code of its own. For the till you need, at minimum:
SALES · SALES_DISCOUNT · OUTPUT_TAX · DEBTOR (the receivable account, used whenever the bill’s customer has an AR/AP type) — SETTLEMENT_CHARGES as soon as any settlement method carries a charge — and COGS, which the bill’s posting does not use but month-end cost-of-goods-sold processing does
Set in Chart of Account.
An unmapped sales or output-tax code does not stop anything — and that is the danger. FINAL
never checks these codes; the journal is written by a posting job a moment later. That job leaves out
any line it cannot place, then builds the customer’s receivable line from whatever is left, so the
journal still balances and posts. Take a RM 106 bill — RM 100 of goods, RM 6 SST — paid in cash, with
no SALES code: the journal debits the cash book RM 106, credits output tax RM 6, and credits
trade debtors RM 100 against the walk-in customer. Sales for the day are RM 100 short, and the
receivable account carries a RM 100 credit, as if you owed the customer the money. With OUTPUT_TAX
unmapped instead, sales are right, SST payable is RM 6 short, and the RM 6 sits on trade debtors.
The bill reads FINAL, the cash book is right, a journal exists, and no message appears anywhere.
How you would notice: a day of nothing but cash bills should not move trade debtors at all. If the receivable account in the trial balance moves, or stops agreeing with the debtor ageing (which is built from the documents, not the journal, and so never shows the gap), or the ledger’s sales for the day fall short of the Z Report’s net sales, a line was dropped. Before go-live, check that every sales, tax and charge code has a company default, then post one test bill and read its journal.
Of the company defaults, only a missing receivable code stops the posting — with
MISSING_DEFAULT_GL_CODE: DEBTOR (or DEBTOR_NON_TRADE), bill FINAL, no journal — and only on a
bill that needs a receivable line. A cash bill paid in full whose every line found an account
balances by itself and never asks for the receivable code. One settled partly by a contra against
the customer’s documents does need it, and so does one where another missing code left a line out.
So on a bill paid in full, that error means a sales, tax, rounding or charge code is missing as
well: map that one, not only the receivable. And if the bill’s customer has no AR/AP type at all, there is no receivable line to
absorb the gap: then the dropped line leaves the journal unbalanced and the job fails with
TOTAL_DEBITS_AND_TOTAL_CREDITS_NOT_BALANCES. Those two are the cases Financial Report → Error
Checking → Trace Document finds; the silent one it does not. Which case your till is in depends on
the walk-in customer’s AR/AP type, on the customer record.
3. Money in
| What | Where | If it is missing |
|---|---|---|
| Settlement methods, each linked to a cashbook and a GL code, and enabled for the branch | Cashbook → Settlement Method Settings, then POS General → Branch Settings | FINAL succeeds; the cashbook job fails afterwards with MISSING_CASHBOOK or MISSING_GL_CODE: STL_MTHD [code] — bill FINAL, no cashbook line, no journal; Error Checking › Trace Document → Resolve |
| Tax codes for the rates you charge | Tax Configuration | No tax line has a code to carry. A tax code with no output-tax GL behind it raises no error: the tax is left out of the journal and lands on trade debtors (§2) |
4. What you sell, and who you sell it to
| What | Where | Note |
|---|---|---|
| Items, with barcodes, and serial / batch / bin tracking where used | Doc Item Maintenance | Serial validation at FINAL is a setting; when on, a serial not in stock at the location is rejected |
| Adjustment items — rounding, group discount, member-point discount | Doc Item Maintenance | Without the rounding item, a bill whose settlement does not exactly equal its lines is refused |
| A default walk-in customer, entity type and currency | Customer Maintenance, then POS General → Default Selection | The till has nobody to sell to |
| Pricing scheme, and a pricebook if you price by branch | Pricebook |
5. The till itself
| What | Where | If it is missing |
|---|---|---|
| Printable format for the cash bill, with branch header and footer | POS General → Branch Settings | Nothing prints |
| POS Agent running on the terminal, with its port | POS General → Personalization | Drawer, card terminal and customer display do not respond |
| The customer-facing second screen | POS Customer Display | It reads the till’s own browser database, so it must run in the same browser profile on the same machine — a different browser, device or private window shows a permanently idle screen |
6. Members and points, if you run loyalty
The company’s member-point configuration decides which document type awards points and at which posting status. Points are awarded only when both match and the bill carries a member. The backend’s default awarding document is the sales order, so points on a cash bill and none in the member’s balance mean the configuration names another document — or your tenant holds no points subscriber. You also need at least one point currency and a point-to-money rate. Choose a card-number rule before go-live as well: with none switched on, the member form gives each member a random six-digit card number, checked against nothing but existing cards. All in Membership Admin.
7. Permissions — including the ones that are targets, not switches
The cash bill needs its four API permissions
(TNT_API_DOC_INTERNAL_SALES_CASHBILL_CREATE / READ / UPDATE / DELETE).
The two cashier reports are different, and each needs its permission granted the right way on
Daily Cashier Reports:
API_TNT_DM_ERP_Z_REPORT_READ and API_TNT_DM_ERP_REPORT_CASHIER_COLLECTION_READ are granted
with branch targets. Granted without a branch, the permission exists and the branch drop-down
is empty. It is a filter, not a yes/no.
At the till, the 31 POS client-side permissions are what separate a cashier from the person they
call over — discount, void, edit price, sell below cost, and ALLOW_APPROVE_SELL_BELOW_PRICE. They
are delivered through user groups.
Grant them deliberately, because the empty default is not the safe one. A client-side permission can only ever add a capability, so a till with none configured is not a wide-open till: it is one where 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, so nothing can be corrected at the counter and the supervisor’s tools do not appear at all. The shop then works around it by sharing a supervisor’s login, and every attribution the till records stops meaning anything.
And three of them are registered but unread. POS_CLOSE_SESSION, POS_FLOAT_CASH_IN_OUT and
POS_ATTACH_DRAWER exist in the catalogue and no current screen checks them — the Session and Cash
In / Out menus appear for anyone once SESSION_FLOAT_CONTROL is on. Do not plan a custody rule
around them. The way to confirm what you have actually granted is to sit at a real till as the
cashier role and again as the supervisor role, and try each action. There is no report that will
tell you; a menu that is missing because you hid it and a menu that is missing because a grant
failed look identical from a desk.
What success looks like
Ring up one item at the till and settle it in cash, then check all four in five minutes:
- The bill has a document number.
- The stock report for that item at that branch is one lower.
- The ledger shows a debit to the settlement method’s cashbook GL and a credit to Sales, with output tax split out.
- The Z Report for today shows the bill.
If any one of the four is missing, the failure is in the section above that supplies it.
A fifth check, if your branches run sessions, and it takes a shift rather than five minutes: open a session with a float, record a cash out, close it, and confirm what survived. You should find the opening count stored note by note, the closing total stored, and neither the closing denominations nor either Remarks box — and the cash-out movement will not be on the Z Report’s float block at all. That is the product working as built, and it is the reason a branch needs a paper procedure to go with it: Balancing the Drawer.
Common mistakes
| Mistake | Symptom |
|---|---|
| Till location not the branch’s default location | Every cash bill from that till refused at FINAL with a location mismatch |
| No rounding adjustment item | FINAL is refused — settlement and lines differ by cents |
SALES or OUTPUT_TAX not mapped | No error. The journal posts with the sales or tax missing and the same amount credited to trade debtors — the receivable moves on a cash-only day, and the ledger’s sales fall short of the Z Report (§2) |
| Settlement method has a cashbook but no GL code | MISSING_GL_CODE: STL_MTHD [code] |
| Z Report permission granted without branch targets | Branch drop-down empty; the report looks broken |
| Expecting the till’s Z Report to equal the day’s takings | It counts cash bills only — its request carries no document-type list and the backend defaults it that way. A standalone sales return, a credit note, a receipt voucher and a journal are not in it. (The four-type Z Report — cash bill, sales invoice, sales return, sales refund note — is the one in the Daily Cashier Reports applet) |
| Customer display on a different device or browser | Permanently idle screen — it reads the till’s own browser database |