Daily Cashier Reports

“Cash bills are missing from my Z report.” On this applet that is rarely a device, because its Z Report has no device filter. It is nearly always one of four things: the bill is still a draft, it was voided after you looked, it is dated to another day, or its payment was keyed by a login with no e-mail sign-in, which drops the payment from the takings. Both screens here add the bills up again every time you press SEARCH and store nothing, so the Z Report you printed last night and the one you run this morning can differ, and that difference is the first thing to check. Cashier Collection lists every settlement taken; the Z Report totals one branch for one date. Expect the two to disagree for the same day: the Z Report counts sales returns and Cashier Collection does not, while Cashier Collection counts sales orders, payment vouchers and receipt vouchers that the Z Report never sees.

Overview

Daily Cashier Reports is a read-only reporting applet with two screens: Cashier Collection, a line-level listing of every settlement taken, and the Z Report, the end-of-day summary for one branch and one date. It creates and changes nothing — both screens are single calls to the sales reporting endpoints, rendered in a grid.

The same two reports are also reachable inside POS General. This applet exists so that a manager or back-office user can read them without a POS licence or a till session. Its Z Report is a reduced version of the till’s: no Device filter, no Show Settlement Methods By User or Show Category Details options, no drawer float block and no contra figure. The server also works out the draft, void, return and exchange counts for this screen, and the screen does not display them — so the draft count a supervisor needs at close is on the till’s Z Report, not here.

Where it fits

	Applet	Relationship
Data source	POS General, Sales Invoice (Internal), Sales Return (Internal), Sales Refund Note (Internal)	The Z Report sums exactly these four document types. Cashier Collection reads a different set of six — see Fields
This applet	Daily Cashier Reports	Reads. Writes nothing
Adjacent	Sales Report	Broader sales analysis over the same documents
Where the money lands	Cashbook	The bank and cash accounts the settlements post to

Screens and menus

Two menu entries by default:

Menu item	Route	What it shows
Cashier Collection	`cashier-collection-report`	Every settlement line, filtered by advanced search
Z Report	`z-report`	The end-of-day summary for one branch and one date

A third screen, Cashier Collections By Settlement Type, is built and routed (cashier-collections-settlement-type) with its own backend endpoint, and the settings screen even offers a toggle to hide its menu item — but its entry is commented out of the menu list, and the menu builder only re-inserts entries that exist in that list. No menu entry opens it. The route itself is still registered, so the screen should open if you go straight to its address — the applet’s own address followed by /cashier-collections-settlement-type. That is read from the routing and has not been tried.

Cashier Collection

One grid, twelve columns: Branch, Settlement Method, Doc Type, Doc No, Created Date, Txn Date, Sales Agent, Sales Agent Code, User Create, Device, Amount, Remarks. Filtering is through the shared advanced-search panel, which offers a create-date and a transaction-date range (each with a Day / period selector) alongside the model’s other criteria. Grouping and totalling are done in the grid — drag Branch or Settlement Method into the group bar to get subtotals per payment method.

The branch list is restricted to the branches your API_TNT_DM_ERP_REPORT_CASHIER_COLLECTION_READ permission target allows.

Z Report

A short form — Branch and Date — then SEARCH, with Export to PDF beside it. The grid has three columns, Username, Description and Amount, grouped by Username with the amount summed per group.

The request asks for one day (the same date is sent as both from and to) and restricts the query to four server document types: INTERNAL_SALES_CASHBILL, INTERNAL_SALES_INVOICE, INTERNAL_SALES_RETURN and INTERNAL_SALES_REFUND_NOTE. Anything else — a credit note, a receipt voucher, a journal — is not in the Z Report.

The response is rendered as five blocks in this order:

Settlement totals per payment method, ending in a Total row. Methods with a zero amount are dropped.
Settlement detail — the same payments broken out per user.
Sales: Gross Sales (net amount plus discount, less rounding), Discount, Rounding, and Total Net Sales, then the tax lines.
Categories — one row per item category.
Counts: No. of Transactions, No. of Transaction (Discounted), Item Sold, Item Sold (Discounted).

The branch list here is restricted by the API_TNT_DM_ERP_Z_REPORT_READ permission target.

Export to PDF renders the grid as it stands through the shared PDF exporter, with the Amount column right-aligned. There is no separate “print” action — print the PDF. The applet titles the PDF with the report’s date, so write the time you printed it on the copy you keep.

A recorded walkthrough of these two reports is available: Daily Cashier Reports (video).

Configuration

Before you can use it

What	Where	Why
Branches	Organisation	Both screens are branch-scoped
Settlement methods	Organisation	The Settlement Method column and the Z Report’s payment blocks
The read permission targets `API_TNT_DM_ERP_Z_REPORT_READ` and `API_TNT_DM_ERP_REPORT_CASHIER_COLLECTION_READ`	Settings → Permission Set / Role Permission	Without a branch target on these, the branch drop-down comes back empty
Sales documents of the four counted types	POS General and the sales applets	There is nothing to report otherwise

No GL code, numbering or tax configuration is needed: this applet posts nothing.

Applet settings

Settings live on this applet’s own Field Settings screen, not the shared one. The settings menu has three entries, Field Settings, Default Selection and Custom Resource Bundle Configuration (the screen’s own labels); a Release Notes route exists with no menu entry. Personalization has one entry, Default Selection.

Five keys are bound to a control, saved by SAVE, and read at runtime:

Setting	What it controls	Default	Effect when changed
Allow viewing own created transactions only (`VIEW_OWN_CREATED_TRANSACTIONS_ONLY`)	Restricts the Cashier Collection grid to rows the current user created	off (null until first save)	On: a user sees only their own collections, unless they hold the `ALLOW_VIEW_TRANSACTION_ALL_USER_CREATE` permission
Hide Z-Report Menu (`HIDE_ZREPORT_MENU`)	Removes the Z Report menu entry	off	The entry can be restored per role with the `SHOW_ZREPORT_MENU` client-side permission
Hide Cashier Collection By Settlement Type Menu (`HIDE_CASHIER_COLLECTION_BY_SETTLEMENT_MENU`)	Would remove that menu entry	off	No effect — the entry is commented out of the menu list, so the screen is unreachable either way
Default Transaction Date Range (`DEFAULT_TRANSACTION_DATE`)	How far back Cashier Collection’s From date starts when the screen opens	unset, which behaves as 1 Month	1 Day starts it today, 1 Week a week back; unset or 1 Month a month back. The To date stays today
Sorting Order (`SORTING_ORDER`)	Despite its name, which date box is ticked when Cashier Collection opens	unset	Choosing Create Date ticks the Create Date box; anything else, including unset, ticks Transaction Date. It does not sort the grid: the order it patches into the panel is never sent with the search

Eight toggles on the same screen are decoys. Under Lines Settings (Unit Discount, SST/VAT/GST, WHT, Blanket Order) and Department Settings (Segment, G/L Dimension, Profit Center, Project) the slide toggles carry no formControl binding at all. They can be switched, they are never read, and SAVE does not persist them.

Default Selection sets the applet-wide Default Branch and Default Location; Personalization → Default Selection overrides them per user, and the Z Report pre-fills its Branch field from the personal setting.

Feature visibility and permissions

Two client-side permission codes are checked and both are seeded:

Code	What it does
`SHOW_ZREPORT_MENU`	Restores the Z Report menu entry for a role even when `HIDE_ZREPORT_MENU` is on
`ALLOW_VIEW_TRANSACTION_ALL_USER_CREATE`	Lets a user see other users’ rows on Cashier Collection when `VIEW_OWN_CREATED_TRANSACTIONS_ONLY` is on

Server-side, the applet requests the API_TNT_DM_ERP_Z_REPORT_READ permission at start-up; the Cashier Collection screen declares API_TNT_DM_ERP_REPORT_CASHIER_COLLECTION_READ as its branch read permission. Both are target permissions — they decide which branches appear, not merely whether the screen opens.

Fields

Nothing here is created or edited, so the only fields are the ones you search with — and on both screens the search panel decides the answer more than most people realise.

Z Report — two boxes, and only one is checked

Branch is required, and SEARCH stays disabled until it is filled; Date is not, and defaults to today. The date box carries a Date is not valid message in the template with no validator behind it, so it never appears. Clear the date and the server substitutes the current moment, so the report covers from now until the same time tomorrow — next to nothing, with no warning. Branch is pre-filled from your personal default branch (Personalization → Default Selection), not the applet-wide one, so two colleagues open the same screen on two different branches.

The branch list is not the tenant’s branch list: it is the branch target on your API_TNT_DM_ERP_Z_REPORT_READ permission. No target means no branches, and the screen still opens.

Cashier Collection — six criteria, and three traps in them

Criterion	What it does
Branch	Multi-select, from the `API_TNT_DM_ERP_REPORT_CASHIER_COLLECTION_READ` target
Sales Agent	Multi-select over employee entities — the sales agent recorded on the document, not the cashier who took the money
Device	Single-select, despite sitting among multi-selects. One till at a time
Create Date and Transaction Date	Two separate ranges, each behind its own checkbox, and you may tick only one. Ticking both is refused with Please choose either the date txn or date create filter
User Create	Multi-select — but see the trap below

Three things the panel does not tell you:

The screen opens with one date box already ticked and a From date a month back. Which box is set by Sorting Order, and how far back by Default Transaction Date Range (see Applet settings); the To date is today. So an untouched search returns up to a month of rows, not one day. Untick both boxes and the request falls back to the start and end of the current day. Tick a box but leave its range blank, and the bounds become 2022-01-01 to 2099-12-31 — effectively everything.
The User Create filter does nothing unless Allow viewing own created transactions only is switched on. With that setting off, whatever you choose in User Create is never put in the request. With it on and you holding ALLOW_VIEW_TRANSACTION_ALL_USER_CREATE, your choice is sent; with it on and you not holding the permission, the filter is forced to your own login and your choice is ignored. So the box is live in exactly one of three configurations.
There is no Settlement Method filter, although Settlement Method is a column. To see one payment method, drag that column into the grid’s group bar — the grouping is the filter.

A keyword shorter than three characters is refused with Search keyword must be more than 2 characters.

Why the two screens will never agree

They do not read the same documents. The Z Report asks for four server document types; Cashier Collection asks for six, and they overlap in only three:

Document type	Z Report	Cashier Collection
`INTERNAL_SALES_CASHBILL`	✓	✓
`INTERNAL_SALES_INVOICE`	✓	✓
`INTERNAL_SALES_REFUND_NOTE`	✓	✓
`INTERNAL_SALES_RETURN`	✓	—
`INTERNAL_SALES_ORDER`	—	✓
`INTERNAL_PAYMENT_VOUCHER`	—	✓
`INTERNAL_RECEIPT_VOUCHER`	—	✓

So a day with returns reconciles differently on the two screens, and a day with receipt vouchers or payments out reconciles differently again. Neither screen is wrong; they answer different questions, and nothing on either says so. Reconcile the Z Report against the till and Cashier Collection against the bank.

One more sign convention: on Cashier Collection the Amount column is negated in the browser for INTERNAL_PAYMENT_VOUCHER and INTERNAL_SALES_REFUND_NOTE rows, so money out shows as a negative number and the column totals correctly. The stored amount on those documents is positive.

And “per person” means two different things. The Z Report’s Username is the login that keyed each payment line, found through that login’s e-mail sign-in; a payment line whose creator has none is left out of the takings and of the Total, with no row to say so. Cashier Collection’s User Create is the login that created the document, and it keeps every line whoever keyed it. When the two differ by exactly one person’s takings, look at that person’s sign-in before anyone recounts cash (POS General › Reports).

Lifecycle and effects

This applet is read-only. It creates no documents, writes no journal, moves no stock and holds no state of its own beyond the five settings above.

Screen	What it reads	How
Cashier Collection	Settlement lines	The `cashier-collections/backoffice-ep` sales-report endpoint under the tenant ERP reports prefix
Z Report	Payments, sales, categories and transaction counts for one branch and date, over `INTERNAL_SALES_CASHBILL`, `INTERNAL_SALES_INVOICE`, `INTERNAL_SALES_RETURN`, `INTERNAL_SALES_REFUND_NOTE`	The `z-report` sales-report endpoint
Cashier Collections By Settlement Type (unreachable)	The same collections grouped by settlement type	The `cashier-collections-settlement-type/backoffice-ep` endpoint

Every figure is added up again when you press SEARCH

Nothing on either screen is a stored figure: each one is recomputed at SEARCH from the sales documents and their lines as they stand at that moment, for the branch and the documents' transaction date you chose. The only snapshot of a day is the PDF you export. That is why a figure can move after you have read it, and the table says what moves each one.

The figure	Added up from	So it moves when
One row per payment method, and the Total row	The payment lines of FINAL documents of the four types, dated that day; a return’s or refund note’s payment carries the document’s minus sign. Zero rows are dropped, and the Total is added in your browser from the rows shown	A bill dated that day is finalised from draft, voided, or arrives late from an offline till
Per-user rows	The same payment lines, grouped by the login that keyed each one, through that login’s e-mail sign-in	As the payment rows. And a line whose creator has no e-mail sign-in is missing from the start — from the method rows and the Total too
Gross Sales, Discount, Rounding, Total Net Sales, TAX	The goods lines of the same documents, returns counting negative. Gross Sales is worked out in your browser as Total Net Sales plus Discount less Rounding, and Total including TAX is the same figure as Total Net Sales	As the payment rows. A sales invoice on credit terms adds here and nothing to the payment rows, because it carries no payment line
Categories	The goods lines, grouped by the category on the item record as it is now, not as it was on the day	Somebody re-categorises an item: every past Z Report that sold it changes
No. of Transactions and Item Sold	Counts over the same FINAL documents; Item Sold is base quantity, returns negative, rounding and discount adjustment lines left out	As the payment rows
Draft, void, return and exchange counts	Worked out by the server for this request, then not displayed	— read them on the till’s Z Report in POS General
Drawer float, cash in and cash out	Not requested: they need a till session, and this screen sends none	— on the till’s Z Report, with a session chosen
Cashier Collection’s Amount	Each document’s payment lines, summed per payment method, at the amount keyed; FINAL only, on the date column you ticked	As the payment rows, and also when you tick Create Date instead of Transaction Date

A bill reaches both screens at FINAL, before the books. FINAL commits the bill; the journal and the cashbook line are written afterwards by background jobs. A bill can therefore be on both screens here and not yet in the cashbook or the ledger, and a day that matches here still needs the posting checks in POS General.

GS-KV-01’s day, read the next morning

GadgetSphere’s branch GS-KV-01 trades on three tills. At 22:05 the supervisor runs this Z Report for the branch and the day and exports the PDF: Cash RM 6,240.00, Card RM 14,385.50, E-wallet RM 2,870.00, Total RM 23,495.50. Three things happen that the PDF does not show:

At 22:20, after the PDF, a card bill of RM 899.00 that was rung twice is voided.
Till 2 runs with auto-posting off, and a laptop bill of RM 1,299.00 sits parked as a draft — the customer has paid, and the bill was never finalised.
A customer leaves a RM 500.00 e-wallet deposit on a sales order for a phone arriving next week.

The next morning you check the day from the back office, with this applet:

Re-run the Z Report for GS-KV-01 and the same date, and lay it beside last night’s PDF. Card now reads RM 13,486.50 and the Total RM 22,596.50: RM 899.00 lower. Every difference between a re-run and the printed copy is a bill dated that day that changed after printing — voided, finalised from draft, or arrived late from an offline till. A voided bill is on neither screen here; the till’s Z Report counts it under No. of Void.
Run Cashier Collection with Transaction Date ticked, From and To both on the trading date, Branch GS-KV-01, and drag Doc Type into the group bar under Settlement Method. Per method, the cash bill, sales invoice and refund note rows total the Z Report’s row for that method — unless the day had a standalone sales return (on the Z Report only), a payment keyed by a login with no e-mail sign-in, or a bill in a second currency (both explained under POS General › Reports). The sales order, receipt voucher and payment voucher rows are money the Z Report never counts: here, the RM 500.00 e-wallet deposit.
Hold each card and e-wallet provider’s slip against Cashier Collection’s subtotal for that method, not against the Z Report, because the provider counts every payment, deposits included. The card terminal’s settlement shows RM 13,486.50 — the double swipe was reversed at the terminal, so the void was right and the PDF was not. The e-wallet merchant summary shows RM 3,370.00: RM 2,870.00 of bills plus the RM 500.00 deposit. The bank credits these later less the provider’s charges, which is what the cashbook carries (POS General › Reconciling a cash-up to the accounts).
Ask the branch for the till’s No. of Draft, or open the till’s Z Report in POS General yourself. This applet’s Z Report does not display the draft count, and a draft is on neither of its screens — so the RM 1,299.00 the laptop customer paid is invisible here. A draft that holds money is finalised or discarded from Hold Bill on the till before the day is called closed.
Then check the books: Missing Journal, Missing Cashbook and Cash Level, in that order, as POS General › How you know the day’s takings reached the accounts sets out.

Verify the day held

The re-run equals the printed PDF, or every difference is named (here, one RM 899.00 void); each card and e-wallet slip equals its method’s Cashier Collection subtotal (here, e-wallet RM 3,370.00 with the deposit); the till’s No. of Draft is 0 once the laptop bill is finalised; and the posting checks come back empty. Write the reason for every difference on the printed copy — the screen will not remember it for you.

Related applets

What must exist first. A document reaches either screen only at FINAL, so a draft holding a customer’s money is on neither. The two read permissions need branch targets, or the Branch list is empty. Settlement methods name the payment rows. Every login that takes payments needs an e-mail sign-in, or its payments drop out of the Z Report’s takings and Total.

What becomes possible. Someone with no POS licence and no till session — an accounts clerk, an area manager — can check any branch’s day from the back office, the morning after, and hand the result to the cashbook and bank reconciliation.

The sibling, and when to use which. POS General carries reports with the same names. Use the till’s Z Report at close: it has the draft and void counts, the drawer float, a device filter and a date range, and it reads cash bills only. Use this applet’s the next morning: it adds sales invoices, sales returns and refund notes taken at the counter, and covers one date. Use Cashier Collection, from either applet, when a total is wrong and you need the lines. Which Z Report is a group’s official day figure is a decision for your finance team, and POS › Reports sets out what each choice costs.

What breaks elsewhere if this is wrong. Nothing posts from here, so a wrong setting changes no ledger. The harm is a decision taken on the wrong figure: a shortage chased that is a void, a deposit counted as a sale, a branch left off because the permission target missed it. The two settings that act reach further than one person: Hide Z-Report Menu hides the entry from every role not granted its restoring permission, and Allow viewing own created transactions only narrows Cashier Collection for everyone without the matching permission.

What it pairs with in practice. The PDF exported at close, Cashier Collection grouped by method against the providers’ slips, and the posting checks and cashbook enquiry in POS General and Cashbook the next morning.

POS General — where the cash bills and settlements are taken, and where the fuller Z Report lives.
Sales Invoice (Internal), Sales Return (Internal), Sales Refund Note (Internal) — the other three document types the Z Report counts.
Sales Order (Internal) — deposits taken on an order are on Cashier Collection and on no Z Report.
Sales Report — analysis across the same documents, not restricted to one day.
Cashbook — the accounts the settlements post to; reconcile the Cashier Collection totals against them.
Organisation — branches, locations and settlement methods.

Troubleshooting

Symptom	Cause	Fix
The Branch drop-down is empty on either screen	Your role has no branch target on `API_TNT_DM_ERP_Z_REPORT_READ` (Z Report) or `API_TNT_DM_ERP_REPORT_CASHIER_COLLECTION_READ` (Cashier Collection). This is a target filter, not a yes/no permission — the screen still opens	Add the branches to the permission target
Last night’s printed Z Report and this morning’s re-run differ	Both are worked out at SEARCH. A bill dated that day was voided, finalised from draft or arrived late from an offline till after the PDF	Step 1 of GS-KV-01’s day; write each difference on the printed copy
A customer paid, and the money is on neither screen	The bill is still a draft — on a till with auto-posting off, a parked bill can hold money	Read No. of Draft on the till’s Z Report; finalise or discard the bill from Hold Bill
A card or e-wallet slip is higher than the Z Report’s row	Deposits on sales orders and payments on receipt vouchers are on the slip and never on a Z Report	Compare the slip with Cashier Collection’s subtotal for that method
Total Net Sales is higher than the payment Total	A sales invoice on credit terms adds goods lines and no payment line	Expected; the gap is that day’s invoices on terms
One cashier’s takings are missing from the Z Report and present on Cashier Collection	That login has no e-mail sign-in, so the Z Report’s takings leave its payment lines out	Report it to BigLedger support with the login, and take that person’s figures from Cashier Collection
A past day’s category totals have changed	Categories are read from the item record as it is now	Expected after a re-categorisation; keep the PDF if the split matters
The Z Report total does not match the day’s takings	The Z Report counts only `INTERNAL_SALES_CASHBILL`, `INTERNAL_SALES_INVOICE`, `INTERNAL_SALES_RETURN` and `INTERNAL_SALES_REFUND_NOTE`. Credit notes, debit notes and receipt vouchers are excluded	Reconcile the excluded documents separately, or use Sales Report
The Z Report and Cashier Collection disagree for the same day	They read different document types — the Z Report counts sales returns, Cashier Collection does not; Cashier Collection counts sales orders, payment vouchers and receipt vouchers, the Z Report does not	Expected. See Why the two screens will never agree
Cashier Collection returns a month of rows when you wanted one day	The screen opens with a date box ticked and the From date a month back (Default Transaction Date Range unset or 1 Month)	Set From and To to the day, or set the range to 1 Day
Cashier Collection covers only today although you set dates	Both date boxes are unticked, so the request falls back to today	Tick Create Date or Transaction Date (not both)
The Z Report comes back almost empty	The Date box was cleared, and the server took the current moment instead	Pick the date again
A User Create choice is ignored on Cashier Collection	The filter is only sent when Allow viewing own created transactions only is on; with it off, the box does nothing	Switch the setting on, or filter in the grid
The Z Report shows one day only	The form has a single Date field and the request sends it as both from and to	Run it once per day
A user sees no rows on Cashier Collection	`VIEW_OWN_CREATED_TRANSACTIONS_ONLY` is on and the user created none of the day’s collections	Grant `ALLOW_VIEW_TRANSACTION_ALL_USER_CREATE`, or clear the setting
The Z Report menu entry is missing	`HIDE_ZREPORT_MENU` is on for the tenant	Grant `SHOW_ZREPORT_MENU` to the role, or clear the setting
The Cashier Collections By Settlement Type screen is missing from the menu	Its menu entry is commented out; the hide setting for it has no effect either way	Go to the applet’s address followed by `/cashier-collections-settlement-type`; the route is registered (read from the routing, not tried).
Toggles under Lines Settings or Department Settings do nothing	They have no form binding and are not saved.	Ignore them
An AG Grid Error toast appears after SEARCH	The report endpoint returned an error; the applet surfaces the message verbatim under that heading	Read the message; the usual causes are an out-of-range date or a branch you have no target for
Export to PDF is empty	The grid is empty — export renders what is on screen	Run SEARCH first