POS General

The retail checkout counter: cashiers ring up sales and take payment here, and supervisors open and close sessions, run the Z Report and correct a wrong payment method. Each sale becomes a cash bill that, on FINAL, takes the goods out of stock, posts the sale and the money to the ledger and cashbook, and queues the bill for e-Invoice.

Overview

The POS General applet is the retail checkout counter. A cashier opens it on a terminal, scans or picks items, applies member points, vouchers, discounts or free gifts, takes payment by cash, card, e-wallet, voucher, cheque, bank transfer or contra — settling the bill against the customer’s own open documents instead of taking money — and the applet writes a cash bill that — on FINAL — takes the goods out of stock, posts the sale and the money to the ledger and cashbook, and queues the bill for e-Invoice. Supervisors use the same applet to open and close cashier sessions with float counts, review the Cash Bill Listing, run the Z Report and Cashier Collection, correct a wrong payment method after FINAL, swap a wrongly scanned serial number, and approve sell-below-price requests. It can run offline against a local database and sync when the network returns.

Video tutorial

Where it fits

Screens and menus

Route root: applet/tnt/wavelet/erp/pos-general-applet/.

The counter screen (Create Cash Bill)

Tabs: Main; Hold Bill (parked drafts, on a bill that is not FINAL); Transaction Queue (bills waiting to sync in offline mode); Copy From (with POS_COPY_FROM — pull lines from a jobsheet, sales order or sales invoice by document number). Panels reachable from the Main tab: customer / member (Account), sales agent, branch (with POS_CHANGE_BRANCH), others (reference, remarks, backdate), department, item discount, group discount, points discount, e-Invoice buyer details, spending limit, gross profit, previous cash bill, attach / detach drawer, session open / close, float count, cash in / out.

Screenshot withdrawn; a recapture from a demo tenant is on the list.

Item dialog tabs (shown per item type): Details, Item Details, Serial Number, Batch Number, Bin Number, Child Item (bundle), MTO (made-to-order), Grouped Item, Multi Level Discount, Membership Points, Department, Stock Details, Sales History, Swap Serial Number, Approval, Attachment.

Two of those tabs answer a customer’s question and one of them will mislead you, so they are worth describing rather than naming.

Stock Details is eight read-only figures — Balance, Average Cost, Last Cost, Replacement Cost, Minimum and Maximum Selling Price, Minimum and Maximum Purchase Price — and the balance comes from the company-wide current-balance service, not from anywhere near this till. The item search on the same screen filters on the session’s location. So the two disagree by design: a cashier can be looking at a positive Balance on this tab for an item the search will not offer, because the stock is at another location of the branch, or at another branch entirely. Neither number is wrong and nothing on the screen says they are answering different questions. It is also not a cross-branch view — it cannot tell a customer which shop has one. That question needs the Stock Report or Stock Availability applets.

And it is a commercial decision as much as an operational one: this tab puts your average cost, your replacement cost and your price floors on a screen that faces a public room and is read by whoever is on the counter. HIDE_STOCK_DETAILS closes it, POS_SHOW_STOCK_DETAILS re-opens it per role. Grant it to the role that has to hold a price, not to the till.

Sales History (POS_SHOW_SALES_HISTORY) answers what has this customer paid for this item before — Date, Doc No, Qty, Unit Price Std, Unit Discount and Unit Price Txn — which is exactly what a cashier needs before quoting a price to a regular, and exactly the kind of grid that gets quoted from without its scope being known. Its scope, from the request it builds, is narrow in four ways at once:

• This branch only (guid_branch), so a customer who bought the same item at another GadgetSphere shop has no history here.
• FINAL cash bills only. A sale to the same customer on a sales invoice does not appear.
• It needs a customer on the bill. With the walk-in default selected, the tab renders nothing — which is most counter sales.
• Ten rows, and only ten. The request asks for limit: 10 ordered by updated_date descending — the ten most recently touched bills, not the ten most recent sales, so a bill amended last week sits above a sale made yesterday. The More Page control cannot extend it: the component sets its record total to the number of rows it already has, so the test it makes before fetching more is never true.

Read it as “here are up to ten things this customer bought here”, never as “this is what they last paid”.

Settlement: a button per settlement method configured for the branch; types CASH (with six quick-cash buttons), CREDIT_CARD (card no., name, issuer, expiry, approval code, batch, card type — each hideable or mandatory), E_WALLET, VOUCHER, COUPON, CHEQUE, BANK_TRANSFER, member points (points ↔ cash value with a maximum), and Contra against the customer’s open documents when CONTRA_DOCUMENT is on. Rounding is added as a line using the rounding adjustment item.

Cash Bill Listing

Advanced search by date, branch, status, customer, cashier; open a bill to view, edit remarks, email, export as PDF, void, return, reprint (single / multiple print with POS_PRINT_CASHBILL_LISTING).

Supervisor tools

Three things can be done to a bill that is already FINAL, and they reach different distances into the accounts. Swap Serial Number changes which physical unit was sold and no money moves. Settlement Adjustment changes how the bill was paid for, and it rewrites the journal and the cashbook. Approval happens before FINAL and is covered under price floors and ceilings. Each needs both its setting and its permission — turning the setting on is not enough, and the menu simply does not appear if either is missing.

Swap Serial Number. Open the sold line on the bill, or the Swap Serial Number menu, pick the serial that was scanned and the correct available one, and execute. Both stock records are corrected. Nothing on the bill’s value changes, so no report and no journal move — which is exactly why this is the right tool when the right product left the shop under the wrong number, and the wrong tool when the wrong product left. The menu’s own listing is the record: Document Type, Document No, Swap Status, Old Serial Number, New Serial Number, Swap Reason and Error, and the Error column is where a swap that did not take says so. A reprint of the bill shows the new serial: no printout is stored against a document — every print renders the bill’s lines afresh — and the swap rewrites the line. The one copy that keeps the old serial is a PDF already e-mailed to the customer for the e-invoice, which is kept as it was sent; if the customer needs the corrected serial on paper, print the bill again.

What a swap checks, and what it leaves alone. Executing a swap files a request; a background job does the swap a moment later, which is why the history has a Swap Status at all. When the job runs it refuses — status Failed, reason in Error — if the old serial has already come back on a sales return against this line, if old and new are the same, if the new serial is not in stock for this item at the line’s location (its delivery location, otherwise the bill’s store) at that moment, or if the new serial is held on an unfinished document of the same type in the same company. The picker hides most of these already; the job checks again because stock can move between choosing and running.

When it succeeds it rewrites the line’s stock movement and the serial on the bill line, then adds one to the old serial’s balance at that location and takes one off the new serial’s. So the unit you name as “scanned by mistake” becomes sellable again at that branch — which is right only if it really is still on the shelf. It does not re-post anything: the journal, the cost of sales and the bill’s value stay exactly as they were, and the receipt the customer already holds still shows the old serial, so reprint it if they need the right number for a warranty. No screen re-runs a Failed request (the API has a re-run route that no applet calls): fix the cause and swap again. A request left at Processing with nothing in Error means the line had no stock movement of its own for the job to correct, and nothing will move it on.

The same tool sits on the Sales Invoice and Sales Return line. On a return it moves the two balances the way a sale would — the serial you say was recorded by mistake gains one, and the unit that really came back loses one — and its picker offers only serials already in stock, which the returned unit is not. Treat a wrong serial on a return as a correction to the return itself rather than a swap.

Settlement Adjustment is the correction for a payment rung up under the wrong method — cash keyed for a card, one e-wallet for another. On the bill’s Settlement tab, the Adjustment sub-tab lets you delete the wrong settlement line, add the right one with its details, and press Adjust Settlement.

What that sets off is more than the screen suggests, and it is the part that decides whether last night’s accounts change:

• The document’s settlement lines are deleted and re-added.
• If the bill already has a journal, the journal is deleted and a new one is posted.
• If the cashbook is already posted, every cashbook line for the document is soft-deleted and written again.
• Both come back on the document’s own transaction date, never today’s — so the correction restates the original day on the reports and in the ledger, and a reconciliation done before the adjustment will not reproduce afterwards.
• If either step fails, the adjustment is stamped FAILED with the error message, which is what the Posting Journal error and Posting Cashbook Error columns on the adjustment listing show.
• With DISABLE_POSTING_JOURNAL_CASHBOOK on, the change is recorded on the document and nothing is reposted — the document says one thing and the ledger still says the other until somebody reposts it by hand.

The E-Invoice tab on a cash bill

Shown beside Sales and Settlement whenever the company’s e-invoice status is ENABLED and a bill exists. Four sub-tabs; the first exists only once the bill is FINAL.

The high-value block. On a new bill of RM 10,000 or more at a Malaysian branch (or a company whose e-invoice country is MYS), the till checks the buyer block for a tax number, phone, e-mail, ID number, entity, ID type and address line 1, and shows the banner Regulatory Alert: Transactions of RM 10,000 or more require full Customer Details for E-Invoicing when any is missing. Whether that banner stops the sale depends on the company record: with Enable high sales value validation (Organisation → Company → E-Invoice) switched on, both Final buttons are disabled and the tab label turns red and bold until the block is complete; switched off, the banner shows and Final works, and the bill goes to the Individual Pool after FINAL if the block is incomplete. The check tests presence only — a wrong registration number or a mistyped tax number passes it and is caught later by LHDN. It does not run on an edited draft, only on a bill being created.

Void and the e-invoice. The Void button is offered on any FINAL bill with VOID_DOCUMENT on and POS_VOID_CASHBILL held; it carries no e-invoice condition. Voiding removes the bill from the e-invoice submission queue if it has not been sent yet; a bill whose e-invoice LHDN has already validated stays Valid at LHDN after the void, and needs a cancellation within 72 hours of validation or a credit note (Cancelling and Correcting).

Reports

Two reports live on this applet’s own menu, and they are not two views of one number. Cashier Collection is a list — one row per payment line — and answers what was tendered, by whom, on which till, over a range of days. The Z Report is a summary for one branch, usually over one day, and answers what does this branch owe the safe tonight. Neither of them is the ledger: taking either figure to the accounts is a third step, and it has its own section below — Reconciling a cash-up to the accounts.

Both screens read only this applet’s own document: a FINAL cash bill, and nothing else. That is worth saying twice, because two reports with the same names in the Daily Cashier Reports applet call the same backend endpoints with a wider document list — six types for its Cashier Collection, four for its Z Report — so the same report name opened from the other applet answers a different question and returns a different total (why the two screens will never agree). If two people quote different day totals, establish which applet each of them opened before looking for missing money.

The Z Report’s device picker is a filter, not a partition. Leave it at all devices and every bill of the branch and day is counted; pick one device and only bills carrying that device are. A bill or session with no device — one opened through the API, or on an older build that did not stamp one — is therefore on the all-devices report and on none of the per-device ones, and the per-device reports will not add up to the branch total by exactly those bills. When the tills’ Z Reports do not sum to the day, run the all-devices report before looking for cash.

Cashier Collection — one row per payment line

Every row is one settlement line (txn_type = 'STL_MTHD') on one FINAL cash bill, with the settlement method as Settlement Method, the bill number as Doc No, and the line’s own amount as Amount. The grid arrives grouped by Branch, then Settlement Method; drag any other column into the group bar to re-cut it. Totals are the grid’s, not the server’s.

Where its numbers come from, and the four things the panel does not tell you:

• Amount is the stored line amount, unmodified. The server returns sum(doc_line.amount_txn) with no sign adjustment, and nothing in the browser negates a row. What the cashier keyed is what you see.
• FINAL only. hdr.posting_status = 'FINAL'. A bill parked in Hold Bill because DISABLE_AUTO_POSTING is on has taken money at the counter and is not on this report, and neither is a voided one. On a counter running with auto-posting off, that gap is the first thing to check.
• Contra is not here at all. A contra settlement is not a settlement line; it is a link between two documents. So a day with contra shows less collected on this report than the bills total — correctly, because no money moved.
• Date basis is yours to choose, and you may choose only one. Tick Transaction Date to filter on the bill’s transaction date, or Create Date to filter on when it was keyed; ticking both is refused with Please choose either the date txn or date create filter. With neither ticked the report covers today only — the request falls back to the start and end of the current day. Tick a box and leave its range empty and the bounds become 2022-01-01 to 2099-12-31, which is everything. For a cash-up, Transaction Date is the one that matches the accounts: it is the same column the cashbook line and the journal header take their date from.
• Sales Agent and User Create are two different people. Sales Agent filters on the employee credited with the sale (who the sale is credited to); User Create filters on the login that made the bill. On a counter where one person serves and another rings up, these give different answers to “whose takings are these”.
• The User Create box is live in exactly one of three configurations. With VIEW_OWN_CREATED_TRANSACTIONS_ONLY off, whatever you pick is never sent. With it on and the user holding POS_VIEW_CASHBILL_ALL_USER_CREATE, the choice is sent. With it on and the permission absent, the filter is forced to the user’s own login and the choice is ignored.
• Device is single-select although it sits among multi-selects, and the report is unavailable in offline mode.

Z Report — one branch, one day, and a cash drawer

The form takes Branch (required), Date From and Date To, with an optional Device and, when a session is open, the session. For one day, set both dates to that day. The response is five blocks: takings by payment method, the same broken out per user, the sales block, item categories, and the counts.

• Date basis is the bill’s transaction date, from Date From up to Date To plus one day, exclusive. It is the bill’s transaction date, not the moment it was keyed — so a bill backdated from the Others panel lands on the day it is dated, not the day it was sold. The Cash Drawer Float block keeps only sessions that started on or after Date From and ended before the day after Date To, so a session that closes after midnight shows there only when the range covers both the day it opened and the day it closed.
• FINAL only for money; VOID and DRAFT are counts, not amounts. No. of Void counts posting_status = 'VOID' and No. of Draft counts 'DRAFT'; neither contributes a ringgit to the takings or sales blocks.
• “Per cashier” means the login that created the payment line, resolved through an inner join from doc_line.created_by_subject_guid to an active e-mail-username login. That join is the one to remember: a payment line whose creator has no active login principal of that kind is dropped from the takings block entirely — the row does not appear under another name, it does not appear at all. Cashier Collection joins the same relationship with a LEFT join and keeps the row. If the two reports differ by a whole cashier’s takings, this is where to look before anyone counts the drawer again.
• The sales block’s arithmetic, computed in the browser from the server’s sums: Gross Sales = Total Net Sales + Discount − Rounding, Total Net Sales = Total including TAX, and Total excluding TAX = Total Net Sales − TAX. Total Net Sales is the sum of the goods lines (returns counted negative), so it is sales, not money — it does not know how anything was paid for.
• The Cash Drawer Float block reads four movement types and can only ever show you two. The block looks for the drawer’s OPEN, CASH_IN, CASH_OUT and CLOSE transactions, but only through the drawer each movement is attached to — and the till never attaches a cash-in or cash-out to a drawer. Session open and session close both do; Cash In / Out records the session and not the drawer. So the two movements a reader most expects to find here — the mid-shift drop and the float top-up — are precisely the two that cannot appear. Whatever record your branch keeps of a drop, it is not this block, and the cash-up arithmetic has to take those figures from the cashier’s own slip.
• The Variance line is about cash only — and the Variance is not. The Variance printed under the block is (Closing − (Opening + Cash In − Cash Out)) − Total Net Sales. The first half is cash movement; the second half is every sale, card and e-wallet included. At any counter that takes more than cash, that line is therefore negative by roughly the non-cash takings by design of the arithmetic, not because money is missing — and it is the single most common reason a cash-up “does not tally”. Reconcile the drawer against the Cash row of the takings block instead, which is the figure it can be compared with.
• Two more things about that block. With more than one drawer on the session, the Variance is computed from the last drawer in the list only — the loop assigns rather than accumulates — so a two-drawer counter cannot read a group variance off this report. And the block only counts a session that started on or after the chosen day and ended before the next one: a session still open has no end date, so it produces no float block at all, and a session that closes after midnight is absent from the day it started.
• Contra is a separate figure with its own date. It appears only when CONTRA_DOCUMENT is on (which is also what puts the column there), covers cash bills on both sides, and is filtered on the contra record’s transaction date, not the bill’s. So a contra applied on Tuesday against Monday’s bill appears on Tuesday’s Z Report while the bill itself is on Monday’s.

Why the two can differ on the same day, and which difference is real

Both read FINAL cash bills, both read the same amount_txn column, and for an ordinary retail day they agree on total tender. When they do not, it is one of six things, and only the last is missing money:

Settings and Personalization menus

The Settings menu also carries Printable Format Settings, Device Settings, Return Remarks, Drawer Settings, Free Gift Settings, Email Template, Webhook, Feature Visibility, Release Notes and Applet Log; each does what its name says, and the ones with a consequence are described under Configuration. The entries below are the ones whose reach is not on the screen:

The screenshot that stood here has been withdrawn: the capture showed real rows on a staging tenant carrying identifying data. A replacement taken on a synthetic demo tenant is on the list.

A legacy Pos Settings screen at settings/pos-settings is still routable but is not in the Settings menu; it edits a subset of the same keys plus a Show WHT switch (read by nothing), SERIAL_OPEN_QUEUE and the barcode fields (REGEX, ITEMCODE_LENGTH, ITEMPRICE_LENGTH).

Configuration

Before you can use it

Applet settings

Which layer a setting lives in decides how many branches it changes, and only three layers are branch-aware. This is the first thing a group running more than one counter needs to know, and nothing on the settings screens says it.

The settings form saves its whole value into the one applet-wide settings record, and that record carries no branch, company or user. So switching on HIDE_DISCOUNT, DISABLE_AUTO_POSTING or DISABLE_POSTING_JOURNAL_CASHBOOK switches it on at all 22 counters of a 22-branch group, and there is no per-branch override for any of them.

Inheritance is the exception, not the rule. Exactly two values fall back from branch to company — the Rounding Item and the Group Discount Item, read from the branch first and the company when the branch has none — and the printable format falls back from branch to the applet-wide default at nine sites. Everything else is set exactly once at whichever level owns it, with no fallback: the company’s e-invoice status and chart of accounts are company-only, and the settlement-method links, item category filter, pricing scheme priority and branch e-mail template are branch-only. One trap in the pair that does inherit: unticking Rounding Five Cent on a branch also writes the branch’s Rounding Item back to null, so the branch silently reverts to the company’s item.

Default Selection (settings/default-selection, applet-wide)

Default Customer (DEFAULT_CUSTOMER), Entity Type and Currency are what every new bill starts with. The three adjustment-item codes — Rounding Item (POS_DEFAULT_ROUNDING_GUID), Group Discount Item (POS_DEFAULT_GROUP_DISCOUNT_GUID) and Points Discount Item (POS_DEFAULT_POINTS_DISCOUNT_GUID) — name the items that rounding, a whole-bill discount and a points redemption are added to the bill as, and each of the three needs its item set before it can add its line (Before you can use it). Two settings here do more than their labels say:

Personalization → Default Selection (per user; overrides the above): Default Branch (DEFAULT_BRANCH), Default Delivery Branch / Location (with POS_SHOW_DELIVERY_BRANCH_LOCATION), Default Customer, Default Sales Agent.

Personalization → Offline Settings (per user / terminal)

Branch Settings (settings/branch-settings, per branch): Branch Details (code, name, company) · Default Settlement Method · Item Category Filter (which categories this branch may sell) · Menu List · Pricing Scheme (with priority) · Printable Format (header, footer) and printable image.

Settlement Method Settings (settings/settlement-method): per company / branch, the list of settlement methods offered at the counter — Settlement Method Code, Name, Cashbook, Settlement Type (CASH, CREDIT_CARD, E_WALLET, VOUCHER, COUPON, CHEQUE, BANK_TRANSFER).

Device Settings (settings/device-settings): Devices (Code, Name, MAC address detected through the POS Agent, Branch); Card Terminals (Code, Name, Integration Type CardBiz / Revenue, Transport Mode ECR cable / WIFI, IP Address, Port Name); settlement methods allowed per device. DEVICE_COMPULSORY refuses to sell from an unregistered device.

Drawer Settings (settings/drawer-settings): Drawers (Code, Name); drawer transactions listing (drawer, device, session, start / end). Return Remarks Settings: the reasons offered when SALES_RETURN_REMARKS_LIST is on. Free Gift Settings: Promotion Name, Start / End Date, Status; Qualifying Item Rule (Item Code, Item Code Regex, Item Category, None) with Min Quantity / Min Amount; Free Gift Rule (None, Repeat for Every Qualifying Amount); Branch Rule (Branch Code); Customer Rule (Customer Code, Customer Category); Free Gift Price Source; Auto Add Free Gift.

Application Settings (settings/field-settings) — behaviour toggles this applet reads (off unless stated). Section names are those on the shared screen.

POS Settings

Five of those switches decide something the switch itself does not show.

CONTRA_DOCUMENT adds the Contra button to the payment panel, which settles a bill against the customer’s own open documents instead of taking money — how an unapplied credit or an over-payment is spent at the counter. The same key also decides whether the Z Report carries its Contra column, so switching contra off after a month of using it removes the figure that explained the difference between takings and sales from the report as well as the button from the till.

READ_MYKAD puts a Read MyKad button on the customer create, add and address screens, filling the identity block from the card through the POS Agent. It is worth more than the keystrokes it saves: the identity number it writes is the field an Individual e-invoice submission needs, and typing that by hand at a busy counter is where wrong identity numbers come from — wrong ones pass the till’s presence check and are refused later by LHDN.

AUTO_APPLY_MTO re-matches made-to-order lines every time a line is added, POS_MTO_USE_COMBINED_ITEMS lists the combined item instead of its parts, and POS_COUNT_MTO_CHILD_QTY counts child quantities in the bill total.

POS_GROUP_SAME_ITEM_CODE merges a rescanned item into the line already on the bill — but only when every price component matches to the cent. The merge key is item code, transaction price, net price, standard price, unit discount, unit tax and withholding tax, so the same item at a price somebody typed stays a second line, which is usually what you want and never what you expect. The first line is the one kept, the second is deleted after its amounts have been backed out, and made-to-order lines are excluded from the merge entirely. The same switch changes how a group discount promotion forms its groups: on, quantities of the same item code are summed; off, the lines are sliced into groups of N in list order and a partial group is discarded. Nothing turns this on for you, and turning it on changes both behaviours at once — treat it as a deliberate choice for a counter that rescans the same item often, not a default to leave alone.

EMAIL_CUSTOMER with EMAIL_SENDER, EMAIL_TITLE and EMAIL_BODY mails the receipt from the Cash Bill Listing; the template itself is maintained on the Email Template screen.

Auto UI, Gen Doc Listing, Fields, Create & Print

Doc Settings, Entity Details, Lines, Department, Line item tabs

The rest of the Lines section is one long family of column switches, and a list of them tells you nothing a glance at the screen does not: DISABLE_ITEM_LISTING, HIDE_SALES_AGENT, HIDE_TARIFF_CODE, HIDE_UOM, HIDE_QTY_BASE, HIDE_QTY_UOM, HIDE_UOM_TO_BASE_RATIO, HIDE_UNIT_PRICE_*, HIDE_UNIT_DISCOUNT*, HIDE_AMOUNT_*, HIDE_DISCOUNT_AMOUNT_EXCL_TAX, HIDE_TAX_CONFIG_SELECTION and HIDE_WHT_CONFIG_SELECTION each remove one column from the line grid. What is worth knowing is what hiding one actually does. These remove the fields themselves in the line grid and the item dialog, so hiding a field takes away the cashier’s ability to choose a value — it does not take the value off the document. Hide the tax-code picker and the line still carries the item’s or the scheme’s tax code, and still posts the tax. Use these to simplify a counter, not to stop something being recorded.

Line Permission — price floors and ceilings

When a blocked price is entered, the cashier can raise an approval request naming an approver; a supervisor holding ALLOW_APPROVE_SELL_BELOW_PRICE approves or rejects it in the Approval menu, or releases the line there and then on the Approval tab.

What the Approval tab actually asks for is a login, and that is the most control-relevant fact on this page. The two boxes — Email or Mobile Number and Password — are not an identifier or a shortcut password: they are sent together as one login request. The component then compares the authenticated subject against the request’s approver_subject_guid and refuses anyone else with “User is not the assigned approver.” On success it writes the grant to the one-time permission request history, naming who approved which line.

Three things follow, and they are the difference between a control and a habit:

• The exception is authorised by a named person, not by a shared code. There is no per-scheme override code anywhere in this applet. A supervisor cannot delegate this by telling someone a number.
• The record is worth having. The request history is the only list in the product of who released which price, and it is the first thing to pull when a margin pattern is being investigated.
• A supervisor is typing their own platform credential into a shop-floor terminal, in front of the cashier who asked for the exception. That is a real trade-off and the business should take it deliberately: it is what makes the record trustworthy, and it is also a password that can be watched being typed. The mitigation is procedural — the supervisor never stays logged in on the till “to save time”, because that hands the exception power to the counter permanently.

Credit Card Settings: HIDE_ / MANDATORY_ for CARD_NO, NAME, CARD_ISSUER, CARD_EXPIRY, APPROVAL_CODE, BATCH, CARD_TYPE.

Keys read by the code with no toggle on any screen: ENABLE_HIGH_VALUE_SALES_VALIDATION (on a bill of 10,000 or more, the e-Invoice submission type is forced to Individual — Single General and Consolidated are disabled; on its own it requires no buyer field and does not block FINAL — but see Enable high sales value validation on the company record under The E-Invoice tab on a cash bill, which does), ENABLE_FILTER_BY_TODAYS_TXN (listing defaults to today), STAFF_PURCHASE_BRANCH, EMPLOYEE_DISCOUNT, SERIAL_OPEN_QUEUE, SHOW_TABLE_NO, ROUNDING_OPTION, SALES_NAMING, SALES_RETURN_NAMING.

Branch Settings — what each tab actually reaches

Settings › Branch Settings › pick a branch. Seven tabs, saved per branch, and they do not all reach the same layer: two change what the counter can find, one changes what it charges, one only changes what is pre-selected, and one is a rounding flag that travels attached to something else.

Why the item search hides things. The counter’s Add Item search asks only for items with stock above zero at the session’s location — and so do the child-item search and the offline sync. For basic items and their aliases only, an item needs an ACTIVE stock record at exactly that location with a ledger quantity above zero. Service and non-stock items are unaffected. So an item can be absent from the search for three different reasons that look identical on screen: no stock at your branch’s location, stock sitting at a different location, or the item’s category being outside the branch’s Item Category Filter. Only the first is about stock.

A zero-total bill settles itself. A cash bill whose total reaches exactly zero — a full return or a cancelled line against a sale on the same bill — must still balance, because FINAL checks that the item lines and the settlement lines agree. If such a bill carries no settlement line at all, the server generates one for zero against the most recently created ACTIVE cash settlement method linked to this branch. It does not consult the branch’s Default Settlement Method tab. So the newest cash method on the branch collects these zero entries, and if that happens to be an administrative or area float rather than the shop’s own till cash, that is where they appear. With no cash method linked to the branch at all, no line is generated.

Document behaviour settings

Feature visibility / permissions

API: TNT_API_DOC_INTERNAL_SALES_CASHBILL_{CREATE,READ,UPDATE,DELETE}_TGT_GUID; API_TNT_DM_ERP_REPORT_CASHIER_COLLECTION_{READ,ADMIN,OWNER}; API_TNT_DM_ERP_Z_REPORT_{READ,ADMIN,OWNER}.

Client-side permissions registered for this applet (31 ACTIVE):

The app also reads POS_SHOW_Z_REPORT, POS_SHOW_CASHIER_COLECTION_REPORT, EXCLUDE_ACCOUNT_CODE_ITEM_TYPE_AT_ITEM_SEARCH (hides account-code items from item search) and the ALLOW_<TYPE>_ITEM_PRICE_EDIT family, none of which are registered for this applet (see Troubleshooting).

Three of these rows are privacy decisions, and nothing on the screen frames them as such. A counter faces a public room, and the person on it is usually the least senior member of staff.

And the exposure no setting covers: the e-Invoice buyer block asks for a tax number, an identity number and an address, at a counter, out loud. The till validates presence and never correctness, so reading a number back to confirm it buys nothing and costs the customer their privacy. Take it from the customer’s own document or screen, and confirm by showing rather than announcing.

Fields

Header (Main and Others panels)

Lines (txn_type = PNS, doc type INTERNAL_SALES_CASHBILL; return lines INTERNAL_SALES_RETURN; trade-in lines INTERNAL_PURCHASE_TRADE_IN)

Settlement lines: Settlement Method and Amount always required; card fields per MANDATORY_*; points lines carry points and cash value. The sum of settlement + contra must equal the bill total. Contra is not one of these lines — it is a separate record linking this bill to the customer’s own open documents, with the total shown on the bill’s header. That is why it settles a bill without money moving, why it never appears on Cashier Collection, and why the Z Report carries it as a separate figure on its own date — see Reports.

Session: Session Code, Session Name, Opening Amount (required), Remarks; Float Count by denomination; Cash In / Out (type, amount, remarks); Closing Amount (required). What each screen actually stores is not what the fields suggest, and it decides what evidence a shift leaves behind:

Three practical consequences, because none of this is visible on the screen: the opening count can be proved note by note and the closing count cannot, so print the closing count before pressing CLOSE; a cashier’s explanation of a difference has nowhere to live in the product, so it belongs on the printed slip; and a mid-shift drop is invisible to the day’s own report, so the paper record is the record. The procedure built on all three is Balancing the Drawer.

Upload Cashbill: Delimiter is mandatory; the helper validates branch code, GL code, segment / dimension / profit-centre / project codes and tax codes per row and reports them in the Checking step; the listing shows File Name, Format, Process Status and Error Message.

Lifecycle and effects

FINAL validation (backend, in addition to the generic checks): total of sales lines must equal settlement lines plus contra — otherwise FINAL is refused; location must equal the branch’s default location; customer must not be blacklisted for credit limit or credit term (ENTITY_BLACKLISTED); serial, bin and batch quantities must match; stock balance when SHOW_ITEM_STOCK_BALANCE; redeemed points within balance; forex rate when the currency differs. A zero-amount bill gets a zero settlement line generated automatically. When the bill has a member, missing reward and redeem point lines are generated on save using this applet’s point settings. Coupon redemptions and commission-scheme rules that apply to sales invoices also apply to cash bills.

A spending limit is not in that list, and the correction matters. No document validator references spending limits at all: the calculation runs in a secondary job processor after finalise, which computes usage and suspends the entity’s status — it throws nothing, so a bill that breaks a customer’s limit always goes through. What does stop something is a client-side quota check at the counter, before the line is even added — see The staff purchase below. Two published pages already stated the FINAL position correctly, including Credit Sales Workflow; this page was the one that was wrong.

Journal — SALES handler, amount signum +1:

Stock: each PNS line writes an inventory transaction of −quantity at the branch location; return lines +quantity; trade-in lines (INTERNAL_PURCHASE_TRADE_IN, quantity signum +1, amount signum −1) bring the traded-in unit in and reduce the amount due.

Settlement Adjustment deletes and re-adds settlement lines on a FINAL bill and re-posts the cashbook side (unless DISABLE_POSTING_JOURNAL_CASHBOOK). Swap Serial Number exchanges the sold serial for another available one and fixes both stock records.

Z Report (FINAL bills only): collections by settlement method per cashier, sales by item category, discounts and member-point discounts, tax, items sold, void and draft counts, session opening / closing / cash in / cash out, contra amount.

e-Invoice: INTERNAL_SALES_CASHBILL maps to e-Invoice type 01 (Invoice); VOID removes the bill from the submission queue; branch-level consolidated e-Invoices include cash bills.

What FINAL sets off, and what decides whether it happens

Pressing Final is not a save. It calls its own endpoint, and what that endpoint does — after the validation above — is write the bill to FINAL, allocate the branch and device running numbers, and then queue two jobs: the main posting job and a message-template job that every finalised document gets whatever its type. Every consequence a cashier expects — stock out, journal, cashbook, points, e-invoice — happens after that, in separate background jobs, each in its own transaction. This is why a bill can be FINAL, printed and handed over, while its journal does not exist yet or fails.

The main posting job does not contain the list of what to run. It asks for it, and three things decide the answer:

1. What is linked to it centrally. A few of the follow-on jobs are for sales orders and the commerce front end and never fire for a cash bill. The ones a retailer cares about: inventory transaction lines, journal posting, cashbook transaction lines, membership points, e-invoice sales document matching and e-invoice posting, coupons (selling, purchasing and redemption), non-stock and trade-in lines, sales commission, forex gain and loss, spending limits, intercompany transactions and the serial / batch / bin unlock.
2. Whether your tenant has each one switched on. A follow-on job runs only where your tenant holds a trigger configuration for it — there is no default-on. Each is opted into on its own: journal posting, the cashbook, inventory transaction lines, e-invoice matching, membership points and the spending-limit check each need their own trigger configuration, and any one of them can be missing while the rest are present. Nothing at the counter shows you which are on.
3. Whether the company has overridden the list. A company can carry an include or exclude list of posting jobs; an exclude list drops the named jobs for every document at that company, an include list restricts the run to exactly those named. It is a company-level setting with no screen on this applet.

So “FINAL posts the journal” is true of a normal installation and is not a law. A counter with no journal-posting configuration behind it produces no journal at all, ever — a till running without a ledger is a supported way to buy this product, not a fault. The practical consequence for a reader: if cash bills finalise cleanly and no journal appears anywhere in the tenant, the GL mapping is not the thing to check. The subscription is.

One thing the till deliberately does not set off: the webhook. The document webhook and the sales contract processor are queued only for INTERNAL_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, not through that topic.

How to tell whether the posting happened

Nothing on this applet answers that question. The counter shows FINAL, prints the receipt and moves on; the Cash Bill Listing has no posting-status column; and there is no cash-bill Posting tab in this applet. The only grid here that carries posting state is the Settlement Adjustment history — Posting Journal, Posting Journal error, Posting Cashbook, Posting Cashbook Error, Settlement Update Status, Settlement Update Error (those six columns are removed when DISABLE_POSTING_JOURNAL_CASHBOOK is on) — and that reports on the adjustment, not on the bill.

So the routes below live in other applets. There are three, in increasing order of how many bills they answer for at once, and a reader doing a cash-up will usually want the second.

Trace Document takes a Server Doc Type (INTERNAL_SALES_CASHBILL) and the bill’s Server Doc No — the same number the Cash Bill Listing shows as Doc No — and returns the document’s date, amount, posting status and posting journal, then runs its checks. Two of them matter here: Missing Journal and Missing Cashbook, both of which apply to a cash bill. Each failed check carries a Resolve button that posts the missing artefact, and a Repost button appears when the document is already POSTED. Repost deletes the journal before it builds the new one and shows no message when it fails, so open the bill’s Journal Txn grid after pressing it; if it is empty, use Resolve on Missing Journal. The badge does not say why. The backend’s own message — MISSING_DEFAULT_GL_CODE: DEBTOR, MISSING_CASHBOOK: STL_MTHD [code], TOTAL_DEBITS_AND_TOTAL_CREDITS_NOT_BALANCES — appears only once you press Resolve and it fails again.

Missing Journal is the one to run for a whole night’s takings. Pick Server Doc Type INTERNAL_SALES_CASHBILL, set Date From and Date To to the trading date, press SEARCH, and you get every FINAL cash bill in that range whose posting_journal is empty — with Branch, Amount and Amount Settlement, so you can total what is missing before fixing anything. Tick the rows and press CREATE and it posts each one, writing POSTED / SUCCEED back into the grid on success and the error code into the Remarks column on failure: the code alone, such as MISSING_DEFAULT_GL_CODE, without the part of the message that names which default is missing. That write-back, the same one on Data Fix below, and Status on the Stock Flow Report’s Difference Listing (which carries the full message) are where you see, per document in a list, why a posting failed.

Missing Journal rebuilds journals only. A night whose bills failed for a settlement method with no cashbook is missing its cashbook lines as well, so Cash Level and Bank Reconciliation stay short after every journal is back. The cashbook half has its own list, in the Data Fix applet under Cashbook › Missing Cashbook. Pick INTERNAL_SALES_CASHBILL, set Date From and Date To (both open on today), and press SEARCH. You get every FINAL cash bill in the range that has a settlement amount and no cashbook line. Tick the header box and press CREATE: each row’s Remarks reads SUCCEED, or the error code if its settlement method still has no cashbook. It is the same repair as Resolve on Missing Cashbook, for a whole range, and a bill that already has its line is not written twice. Data Fix is an administrator’s applet; if it is not on your menu, ask BigLedger support to add it to your login.

Before you press anything, check you are allowed to. The three screens in the table above open without a client-side permission — there is no per-check gate on Trace Document — but their Resolve, Repost and CREATE buttons post real accounting entries, and the server refuses them unless you hold one of API_TNT_DM_ERP_FI_JOURNAL_OWNER / _ADMIN / _CREATE for the journal and one of API_TNT_DM_ERP_CASHBOOK_TXN_OWNER / _ADMIN / _CREATE for the cashbook. They are repairs, not enquiries: each one writes a journal or a cashbook line dated on the document’s transaction date, so if that day sits in a period finance has already reported, agree it with them first.

What none of them will tell you is whether the journal or cashbook subscriber is switched on for your tenant at all. There is no job-failure screen anywhere in the product — every diagnostic above infers a failure from an artefact that is absent, and nothing raises an alert when a secondary job fails (how work actually runs → what this will not do). The distinction is worth establishing before changing anything: Missing Journal on one bill is a repair, while every bill missing its journal, at every branch, is the subscription described above and no amount of GL mapping will change it.

Reconciling a cash-up to the accounts

A cash-up involves four numbers, and none of them is a restatement of another. Taking them in the wrong order, or comparing two that were never meant to be equal, is where most of a night is lost.

Step 1 — settle the date basis before comparing anything. Everything downstream of the counter uses the bill’s transaction date, not the moment it was keyed: the Z Report filters on it, the cashbook line copies the bill’s transaction date onto itself, and the journal header takes the same date and records the posting moment separately. So run the Z Report for the trading date, and if you use Cashier Collection as well, tick Transaction Date and not Create Date. A bill backdated from the Others panel moves on all three together — which is the point of backdating, and also why a backdated bill is invisible on the day it was actually sold.

Step 2 — take the till figure from the takings block, not the Variance line. Run the Z Report with Device on All first (a bill written without a registered device is excluded from any device-specific run — see Troubleshooting). Read the takings block: one row per settlement method, plus Contra where it applies. That is the gross tender, and it is the number the accounts have to explain.

Step 3 — compare cash against the drawer, and only cash. Expected drawer movement is Opening + Cash In − Cash Out + cash takings; the count at Close should match it. Do not use the printed Variance, which subtracts Total Net Sales — every sale, card and e-wallet included — from a cash-only movement, and is therefore negative by roughly the non-cash takings at any counter that accepts a card.

Step 4 — take each method to its own cashbook. A settlement method names the cashbook it posts to (Cashbook → Settlement Method); there is no single “takings” account, and a branch with a cash till, a card acquirer and two e-wallets reconciles four accounts.

Open Cashbook › Enquiries › Query Cashbook Transaction. It asks for Company and Cashbook (both required, one each), a Date From / Date To and an optional Payee, plus a keyword box that needs three characters and searches the cashbook code and name, the reference, and the document number — so a single bill can be found by typing its Doc No. The date it filters on is date_txn_doc, which is the bill’s transaction date, so it agrees with Step 1 by construction.

The grid is Doc Short Code · Document No · Branch · Payee · Reference · Remarks · Transaction Date · Cashbook · Debit · Credit · Credit Card Details · Balance, with a synthesised Opening Balance row at the top and no total row at the bottom — the screen builds one and does not display it. Debit and Credit are two renderings of one stored figure — a positive amount is shown as Debit, a negative one as Credit — and Balance runs down the grid from the opening, so the period’s movement is the last row’s Balance less the Opening Balance row’s. Compare that movement against the takings block for that method, and never add the two columns together. For the same figure without the subtraction, Cashbook › Enquiries › Cash Level over the same dates shows it as In/Out, one row per cashbook (where Cash Level’s figures come from). Clicking a row opens the source document with a Journal tab beside it, which is the shortest way from a cashbook figure to the double entry behind it.

Step 5 — expect the cashbook to be lower than the till, by a computable amount. This is the single most common reason a cash-up “does not tally”, and nothing on either screen says it. The cashbook line is the tender less the settlement method’s charges — open_amount = (amount_txn − charges) × amount_signum — and the journal agrees with it: the cashbook GL line is posted at |amount| − |charges| and the charge goes out as its own line against the company’s SETTLEMENT_CHARGES default GL code. Charges are configured on the settlement method itself, either as a rate on the tendered amount plus an optional surcharge or as a flat amount. So a card method charging a merchant fee reports the gross swipe at the till and the net receipt in the cashbook, and the difference is the fee — which is also what the acquirer’s statement will show, and why the cashbook is the figure Bank Reconciliation can actually match.

Step 6 — when a bill is on the till report and nowhere in the accounts, the posting did not happen, and the route to prove it and fix it is How to tell whether the posting happened. Work one bill first: a single Missing Journal is a repair, while every bill missing its journal is the subscription described under What FINAL sets off and no amount of GL mapping will change it.

Step 7 — check what was corrected after the cash-up. A Settlement Adjustment made this morning restates last night: the rebuilt journal and cashbook lines carry the bill’s own transaction date, not today’s, so the figures you reconciled before the correction will not reproduce after it, and nothing on either report marks the row as corrected. The mechanism, what it deletes and rebuilds, and the bank-reconciliation trap are under Supervisor tools; the Posting Journal and Posting Cashbook columns on the adjustment’s own listing are where you see whether the repost succeeded.

What this applet will not do, and it matters most to a group. There is no facility to compare, copy, export or import settings between branches. No screen shows two branches side by side, no control copies one branch’s configuration onto another, the settings grids switch grid export off on seven of them, and the branch listing selects one row at a time. The one multi-branch action is linking a settlement method to several branches at once on the method’s Branch tab, and even that sends one request per branch. Nothing on the server does it either: there is no bulk operation that takes a set of branches.

What that leaves you is a short list, not a long one, because the layer table above says most settings are applet-wide and cannot differ between branches at all. Only six things are per branch, and these are the whole of a branch audit:

1. The branch’s linked settlement methods — Settlement Method Settings, the Branch tab of each method. This is the one that produces a missing button or a tender posting to the wrong account.
2. Each linked method’s cashbook and GL code, and its charges — set on the method itself, so shared by every branch that links it (Cashbook → Settlement Method).
3. The seven Branch Settings tabs: Details (rounding item, rounding five cent, group discount item), Default Settlement Method, Item Category Filter, Menu List, Pricing Scheme priority, Printable Format and Printable Image.
4. The branch’s default location, in Organisation — FINAL refuses a bill whose location differs from it.
5. The devices registered to the branch, and their card terminals — an unregistered terminal is what takes a bill out of a device-filtered Z Report.
6. The API permission targets that decide which branches a person’s Z Report and Cashier Collection drop-downs offer.

Record those six for the branch you have just fixed, and that is your baseline; there is no report that would show another branch drifting from it, so the comparison is a recurring task somebody has to own.

The one genuine multi-branch control is Settings → Settlement Method Settings → pick a method → Branch → Add, whose branch grid is multi-select: one settlement method is linked to every branch you tick in a single submit. Its mirror on Branch Settings adds many methods to one branch, and the ADD on Branch Settings → (branch) → Settlement Method does nothing at all — see Troubleshooting.

How you know the day’s takings reached the accounts

Two checks, run by two people at two times. The first proves the till’s record is complete before the drawer is counted; the second proves the accounts received it. Each has an answer you can read in under a minute, and the answer to look for is nothing: an empty list, a zero, a match.

At the till, before the session is closed — the supervisor, on the branch’s own terminal:

1. Run the Z Report for the branch with Date From and Date To both on the trading date and Device on All. Read No. of Draft first. It counts this branch’s bills dated in that range that are still DRAFT, and none of them is in the takings. Anything above zero is a bill to finalise or discard from Hold Bill before you count — on a counter running with DISABLE_AUTO_POSTING, a draft may already hold the customer’s money.
2. Count the drawer against the Cash row, as When the drawer is genuinely short sets out: opening float plus the Cash row plus cash in less cash out, with the cash-in and cash-out figures from the cashier’s slip. Print the closing count before pressing CLOSE; it is not stored.
3. Hold each card and e-wallet row against the provider’s own slip for the day — the settlement report your card terminal prints, the e-wallet merchant summary. A cash shortage matched by a card overage of the same amount is a tender keyed to the wrong method, not missing money.

In the back office, the next morning — the accounts clerk. Not straight after close: posting happens in background jobs after FINAL, so a bill finalised a minute ago can still be on its way.

4. Ledger And Journal › Error Checking › Missing Journal, Server Doc Type INTERNAL_SALES_CASHBILL, Date From and Date To on the trading date, SEARCH. The grid should be empty. It covers every branch at once and has a Branch column, so one search answers for the whole group. Each row is a FINAL bill with an amount and no journal; one row is a repair, every bill of the day is the posting subscription (What FINAL sets off).
5. Data Fix › Cashbook › Missing Cashbook, same type and date. Also empty. A row here is a bill whose payment never reached a cashbook, usually a settlement method with no cashbook. Where the cashbook watchdog clock is scheduled on your tenant, such a line is retried by itself every 15 minutes once the method has its cashbook, so by morning this list holds only what retrying could not fix (who writes a cashbook line); the journal is not retried that way, which is why step 4 comes first.
6. Cashbook › Enquiries › Cash Level, the trading date. Each method’s cashbook should show an In/Out equal to that method’s row on the Z Report less the method’s charges. When a cashbook also carries other documents — receipt vouchers, transfers, or several branches’ card takings — open it in Query Cashbook Transaction and total only this branch’s cash-bill rows instead.
7. Open one card bill’s journal: Ledger And Journal › Journal Transaction, search its document number, View, Line Items. A bill paid in full whose every line found an account carries the cashbook, sales and tax lines — and a fee line when the method carries a charge — and no trade-debtors line. A trade-debtors line on such a bill — for the card fee, or for a sales or tax amount — means a GL code did not resolve and the journal balanced by putting the gap on the customer (see Before you can use it). Sample a card bill because it exercises the fee mapping as well as the sales and tax ones; a new item or a new method is worth one more sample on the day it is first sold.

What success looks like: No. of Draft is 0; the drawer matches or the difference is reported; Missing Journal and Missing Cashbook are both empty; each cashbook’s In/Out is its takings row less charges; and the sampled journal has no debtor line. If all five hold, the day is in the accounts as the till recorded it. They do not prove the till recorded it right — a wrong method or a wrong price is still a wrong record — which is what steps 2 and 3 are for.

The staff purchase is a quota, not a price

Every shop sells to its own staff, and the wrong way to do it is the obvious one: let the cashier type a lower price. This applet has a purpose-built path instead, and it is worth knowing because nothing on the screen announces it.

It is built on the customer record, not on the item. An employee buys as themselves — their own customer entity, carrying a spending limit — and the till behaves differently for that customer in two ways:

• The line is refused at the quota, when you add it. When the customer’s spending-limit line is enabled and its per-item maximum is one, the counter counts what the limit has already used plus what is in the basket, and refuses the add with “Customer account has reached the maximum quantity quota for this month”. This is enforcement at the point of choice — before a price is discussed, not after a bill is finalised — and it is the only place a spending limit stops anything, because no FINAL validator consults one.
• Price editing on that line is granted by its own permission. With the quota check engaged, whether the price can be edited at all comes down to POS_EDIT_PRICING_STAFF_PURCHASE and nothing else — so the person who may price a staff purchase can be a different person from the one who may price anything else.

STAFF_PURCHASE_BRANCH is what makes the customer listing look the limit up in the first place; the key is read by the code and has no toggle on the settings screen, which is why it looks absent. EMPLOYEE_DISCOUNT is read when the customer entity is flagged as an employee and passed into the line dialog, and what it changes on the line is not established — the input exists and no template binding for it was found. Do not plan a staff discount around it until somebody settles that.

Who does what, and when. The quota is set on the employee’s customer record, by whoever maintains customer master data, before the first staff sale — not at the till and not by the cashier. The cashier’s part is to ring the sale against the employee’s own customer record rather than the walk-in default, which is also what makes a staff purchase reviewable afterwards. How anyone knows it is working: ring one staff sale over the quota and confirm the refusal message appears; then check that the same employee’s purchases can be listed from the Cash Bill Listing by customer. If a staff sale is going through as a walk-in with an edited price, none of this control exists on it.

When the drawer is genuinely short

Reconciling a cash-up to the accounts answers the opposite question — why is the difference I am looking at not a shortage? This section is for the case where it is, and it is the question the counter actually asks.

Establish the expected figure first, and understand that you are the one establishing it. No screen and no report in this product subtracts what should be in the drawer from what is: the Z Report gives opening, closing, cash in and cash out as four separate sums and never differences them, and the one line labelled Variance is a different calculation entirely (above). The comparison is:

Opening float  +  the Z Report's Cash row  +  cash in  −  cash out   vs.   the count

with the cash-in and cash-out figures taken from the cashier’s own slip, because those lines never reach the report (Fields → Session).

Then name which of four things the difference is. They need four different actions and only one of them is money.

And the rule the product only half-enforces: report a difference, never quietly correct it. The two actions that would make a day’s figures agree — VOID and Settlement Adjustment — are both permission-gated, which is this applet’s own way of saying they belong to somebody other than the person holding the drawer. If a cashier role holds either of them, that is a configuration choice and it removes the only separation there is. The counter-facing procedure built on this section is Balancing the Drawer.

What this applet will not do about any of it. It computes no variance, keeps no record of why one happened (the closing Remarks box is not saved), produces no exception report, raises no alert on a run of voids or a pattern of discounts, and records nothing at all when a drawer is opened outside a cash sale — there is no no sale function, and the drawer is kicked only on a cash settlement with POS_CASH_DRAWER_CASH on. Each of those is a review somebody at the branch performs from the six screens listed under the module’s reports page, on a named day, or it does not happen.

Where the cost of sales comes from

A cash bill’s journal has no cost of sales line, and this surprises people who have used other systems. The sales journal has exactly seven lines it can post to — debtor, sales, sales discount, sales return, output tax, forex gain, forex loss — and no inventory or COGS among them. Nothing the counter does debits cost of sales.

The ledger gets its cost of sales periodically, from Financial Report’s month-end run, using the oldest formula in the book: COGS = opening stock + purchases − purchase returns − closing stock. The closing figure comes from the month-end closing stock record, either the system’s computed value or a value keyed by hand, per stock class — and the run deletes the period’s previous COGS journal and writes a new one each time it is executed. Separate COGS_RAW, COGS_WIP, COGS_FG and COGS_NSTI codes are posted against their matching stock-balance codes where a company uses them.

Two things follow that a cashier and a manager both need to hear:

• Gross profit on the counter is not gross profit in the ledger. The panel behind SHOW_GROSS_PROFIT and the SHOW_MA_COST column read the item’s moving-average cost, computed per line; the ledger’s cost of sales is a period calculation that never looks at a line. They answer different questions and will not reconcile bill by bill.
• The document line does carry a cost, and it arrives late. Once the inventory transaction lines exist, costing runs and writes the cost back onto the bill’s lines — under four methods side by side: moving average, weighted average, FIFO and LIFO. A margin report run seconds after a busy hour can therefore be reading lines whose cost has not been written yet, which looks exactly like selling at zero cost.

Which dimension the journal line ends up with

Branch, segment, dimension, profit centre and project sit on the bill’s header and on every line, independently of one another — branch is its own column, so a profit centre is a second cut rather than a restatement of where the sale happened. When the journal is built, the two levels are not treated the same:

• Sales, tax and charge lines take the value from the document line, falling back to the header when the line is blank.
• The entity side — the debtor line and the cashbook line, the money half of the entry — always takes the header’s, whatever the lines carry.

So on a bill whose lines are split across two profit centres, revenue and tax divide between them and the cash or receivable does not: it lands whole on the header’s. A profit-centre report that balances on revenue and not on cash is not wrong, and this is why. If profit-centre cash matters to you, split the sale into two bills rather than two lines.

The customer on the bill is a copy

When you pick a customer, the counter copies that customer’s identity block onto the bill — code, name, status, e-mail, phone, GL code, identity number and type, entity type, currency — rather than pointing at the record. Editing it on the bill changes the bill alone; pushing a correction back to the customer record is a separate act. That is what makes a reprinted receipt from March match the one handed over in March, and it is also why correcting a member’s phone number at the till this afternoon does nothing for this morning’s bills. Two things are not frozen: the AR/AP type that decides the control account is read live at posting time, and an entity merge deliberately rewrites the snapshot on every document pointing at the surviving record. Full mechanism: the entity snapshot.

Who the sale is credited to

Three sources can fill the Sales Agent, and they are consulted in an order nothing on the screen shows:

1. Your own default — Personalization → Default Selection → Default Sales Agent (DEFAULT_SALESAGENT). If this is set, it wins, and the auto-detection setting is not even consulted.
2. The logged-in employee, when ENABLE_EMPLOYEE_LOGIN_AUTO_DETECTION is on and you have no personal default. The applet resolves the employee linked to your login.
3. The branch’s Default Sales Entity, which is applied only when ENABLE_EMPLOYEE_LOGIN_AUTO_DETECTION is off. Turning auto-detection on silently switches the branch default off.

That order decides whose sale it is, and the sales commission processor is one of the secondaries a FINAL cash bill triggers — so it decides whose commission it is as well. When a commission dispute lands on your desk, ENABLE_EMPLOYEE_LOGIN_AUTO_DETECTION is the first thing to look at: it decides both which employee the bill is credited to and whether the branch default was consulted at all.

Related applets

• POS Customer Display — the shopper-facing second screen. It reads this applet’s offline draft out of the same browser IndexedDB database, so it only mirrors a counter running in the same browser profile.
• Daily Cashier Report — Z Report and Cashier Collection in a report-only applet.
• Sales Return (Internal) — returns that need their own document; POS returns are lines on the bill.
• Sales Invoice (Internal) — the credit-terms sibling; same journal handler, and it earns points only if the company’s member-point setting names the sales invoice instead of the cash bill (Points Setup).
• Non Stock and Trade In — NSTI items received through trade-in lines.
• Membership Admin, Voucher Management Applet V2 — members, points currencies and rates, vouchers and coupons used at the counter.
• Customer, Inv Item Maintenance, Doc Item Maintenance, Pricebook, Organisation — master data.
• Cashbook, Chart of Account, Tax Configuration — posting setup.
• Stock Balance, Bank Reconciliation, Sales Report, Receipt Voucher (Internal), My E-Invoice Portal — downstream.

Troubleshooting

Related documentation

• Point of Sale module and its configuration page
• Daily tasks video library — cash bill creation, discounts, settlement and reports
• Sales Workflow applets