Reports & Analytics

“Where did this figure come from? Nothing on the screen says.” For a member’s points it is almost always one of three things BigLedger keeps, and they are not the same thing: every point transaction line, a stored running total per member, and one lot per earning with what is left of it. Most of the reports in this module read one of them, a few read the bills or the voucher tickets instead, and one is a file written once and never refreshed. This page says, for each report, what it reads, as at when, and why two that should agree do not — and then who checks them against each other every month, and how they know they are right.

GadgetSphere runs one points currency, GSPTS, across its three companies and 22 branches, and some of its members came over from a previous system with their original join dates. Both facts matter below.

Where each figure comes from

What you are looking at	Where	Reads	As at
A member’s points balance	Membership Admin → the member; the till	The stored running total for that member and point currency, one per member for the whole tenant	Now. Added to as each line is written; set to zero by an expiry run until the rebuild queued behind it lands
Every movement of one member’s points	Member → Point Transaction tab	The transaction lines, live	Each line’s transaction date — for points from a bill, the moment the points job wrote the line, not the bill’s date. Created By is the person who keyed an adjustment. The tab shows no document number
What is still owed, and when it lapses	Member → Points Expiry tab	The lots	Now. Its Balance Amount column is the lot’s original points, not what is left of them
Points earned, spent and expired across members	The API’s transaction-lines query	The transaction lines, filtered by card, point currency, transaction type, item, company, branch and transaction-date range	Live. It returns lines, and the totals are yours to add
Who the members are	Membership Admin → Membership Report	The member records, written to a CSV once, when the job runs	The moment the file was generated. Re-run it for a fresh list
Points transactions that look wrong	The exception report, e-mailed by a Scheduler clock, or its summary API	Lines dated in the last 7 days (or the days the schedule names), plus a whole-history balance check	The moment it runs
Which vouchers were redeemed	Sales Report → Voucher Redemption	The voucher tickets with a redemption date in your range, joined to the document they were redeemed on	Live, by redemption date. The Amount is the bill line’s amount, not the voucher’s face value
Points taken as a discount at the till	POS General → Z Report → Points Discount	The points-discount lines on FINAL bills	Live, by document date. It is ringgit, not points
Points produced by a commission scheme	Sales Commission → Sales Commission Report	A stored commission report that a job writes from each document	When that job ran. A second job turns its points into member point lines
Who changed a member record	Membership Admin → Audit Trail	A stored log row per change	When the change was saved. A manual point adjustment writes no entry here

Voucher Management’s Ticket Management counts, Ticket History and CSV export are the per-voucher and per-serial view of the same tickets Voucher Redemption reads; see Voucher Management.

Why two figures that should agree do not

The member’s balance against the sum of their Point Transaction tab. They agree for most members and stop agreeing in three ordinary ways: an expiry run has zeroed the stored total and the rebuild has not landed yet; the total was floored at zero when lines went below it; or a bill that earned points was voided, which removes its lots and leaves both the lines and the stored total alone. What each case means for the money you owe, and which figure to trust, is in the three figures that should agree. For one member, the recalculation in Membership Admin rebuilds the stored total and the lots from the lines.

The member’s app history against their balance. A line keyed with Display Type HIDDEN stays in the balance and on the Point Transaction tab and is left out of what the member sees. A member who adds up their own history and gets a different number may simply be missing the hidden lines.

The Z Report’s Points Discount against the points redeemed. The Z Report adds up the ringgit discount written on each bill at the moment of sale; the member’s redemption lines are in points. Change the redeem rate mid-month and the two stop being proportional. More serious: a bill can carry a points discount and no redemption line at all, when the company’s points rule names a different document from the one the till finalises — the till accepts it and the member keeps the points (a known issue, reported to engineering). The check is under How you know you got it right.

Gross Sales on the Z Report against Discount plus net sales. Gross Sales always adds the points discount back, whether or not POS_SHOW_MEMBER_POINT_DISCOUNT_Z_REPORT shows the Points Discount line. With the line hidden, Gross Sales less Discount comes out higher than the net sales by the points discount (and any rounding), and that gap is the figure the hidden line would have shown.

The commission report against the member’s points. The report is written by one job and the points by another. A report showing points the member does not have yet usually means the second job has not run.

Points by month against sales by month. A points line from a bill is dated when the points job wrote it, not with the bill’s date. For example, a cash bill dated 31 March and finalised on 2 April earns its points on 2 April. Sales reports put it in March; every points figure puts it in April.

Voucher Redemption filtered to one company against that company’s redemptions. The company and branches you choose narrow the document columns, not the rows. A ticket redeemed on GSO’s web order still appears when you ask for GS, with its document columns empty. So does a ticket redeemed directly from the back office, a merchant or the storefront, which has no document at all. Count only rows with a document number when you want one company’s figure (a known issue, reported to engineering).

The Membership Report’s Join Date filter against its Start Date column. The filter reads the date the member record was created; the Start Date column prints the member’s start date, and the record’s creation date only when there is none. For a member keyed on the day they joined they are the same. For GadgetSphere’s members brought over from the previous system, the record was created on import day, so “joined in March” lists everybody imported in March and none of the old members who genuinely joined in a March. This is the commonest shape of member record across the groups we can see (a known issue, reported to engineering).

Cautions on the Membership Report CSV

Filter on the Start Date column, not on Join Date, whenever any of your members were imported. Export with no join dates and filter in the spreadsheet.
Ticking Lifetime does not narrow to lifetime members. It lifts the end-date filter, and the list comes back with every member whose record is not deleted. Lifetime members are the ones whose End Date is 12 December 9999; filter that column.
Inactive and expired members are in it. Every member except deleted ones is listed, with their status in the Status column.
The address columns are not the member’s address. They are the delivery details on one of the documents the member appears on — whichever the database returns first, which may be an old one or a voided one. For a mailing, use the member’s own contact details or the customer record.
It is a file of personal data. Whoever owns the programme decides who holds the Membership Report screen, keeps a note of who exported what and when, and removes an export once it has been used. The Personal Data Protection Act 2010 applies to the file as much as to the screen.
One export runs at a time; a second request while one is generating gets Please wait until the current file finishes before generating additional files.

What the exception report actually checks

The exception report is the only standing check on points in the module, and it is off until somebody schedules it: a Scheduler clock for MEMBERSHIP_POINTS_EXCEPTION_REPORT_PROCESSOR whose properties name the companies, and optionally the recipients. With no company list it sends nothing. With no recipients it goes to each named company’s own e-mail address, and skips a company that has none. It sends only when it finds something.

What it looks for, in plain terms:

Redemptions with the wrong sign or nothing in them — a redemption line with positive, zero or missing points, or a finalised internal sales order (the redemption order) with no points line or a blank member.
Rewards with the wrong sign — a reward line with negative points, or zero points on a scanned receipt line for an item whose price carries points.
Doubles — two redemptions of the same points by the same member within two minutes, or two reward lines on one scanned receipt line.
A scanned receipt line on an inactive or deleted product.
A redemption line recorded with a balance below zero.
A stored balance that does not equal the sum of the member’s lines — across all of history, not the last 7 days.

Three things to know before you rely on it:

Every company gets the whole tenant’s list. The file is titled for one company, but none of the checks is narrowed to it, so GS, GSO and GSD each receive the same rows (a known issue, reported to engineering). Decide who in the group owns the report, so three people do not chase the same member.
The balance check is the first leg of the month-end proof, ready-made. It compares the stored total with the lines for every member. It does not see the lots, so a voided bill whose lots were removed passes it; the three-way proof on What you owe your members still needs the lot figure. And because it has no date window, a mismatch nobody fixes is in every e-mail until somebody runs the recalculation for that member.
Silence proves nothing until you know it ran. No e-mail means nothing was found, or the clock is off, or the company list is empty, or the company has no e-mail address. A line back-dated further than the window is never looked at by the dated checks.

Month-end: who reconciles the points reports, and how they know

The reports do not reconcile themselves, and apart from the exception report’s balance check nothing in the product compares them. At GadgetSphere the person who signs the management accounts owns the points figure, and the programme owner owns the exceptions. On the last day of the month, before the period locks:

The programme owner clears the exception list. Every member in the balance-mismatch rows is either recalculated or written up with a reason; every double and every wrong-signed line has a named cause.
Finance takes the three figures at one moment — the month’s lines by type from the transaction-lines query, the stored balances from the current-balance query, and the lots — and proves them against each other, then values the lots. That procedure, with the treatment of lapsed points and breakage, is What you owe your members.
Finance ties the till to the points. The month’s Points Discount, turned into points at the redeem rate, should be close to the month’s redemption points. It will not match to the sen: the Z Report dates a bill by its document date and the points line by when it was written, so a bill back-dated into the month, or finalised after it, sits in different months on the two. A gap the size of whole bills is the other cause — bills that never reached a member’s points — and the three-bill check below finds them.
The voucher owner counts the month’s redemptions from Voucher Redemption, per company from the rows with a document, and the direct redemptions (the rows without one) separately, so a voucher honoured on the web store is not counted against a branch.

How you know you got it right

Three checks, each a few minutes:

Three bills from the Z Report. Pick three bills with a points discount and open each member’s Point Transaction tab. Each bill should be there as a REDEEM line for the points it took, dated when the bill was finalised. A bill that is not there means the company’s points rule does not name the document your tills finalise — fix the rule before you trust any redemption figure (see Points Setup).
The balance check is empty. The latest exception e-mail has no Inconsistent point balance rows, or each one has been recalculated or explained.
The movement explains itself. Points earned, less spent, less expired, plus adjustments, over the month, equals the change in the lot total. If it fails by a round figure, look for a month of adjustments left out: birthday gifts, storefront points and manual corrections all arrive as adjustments.

When a figure looks wrong

What you see	Why	What to do
The member’s balance is 0, and their Point Transaction tab adds up to more	An expiry run zeroed the stored total and the rebuild has not landed	Run the recalculation for that member in Membership Admin
The till gave a points discount and the member still has the points	The company’s points rule names a different document from the one the till finalises	Point the rule at the till’s document (Points Setup), then adjust the members it missed
A “joined in March” export lists long-standing members, or misses new ones	Join Date filters on when the record was created	Export without join dates and filter the Start Date column
A Lifetime export lists everybody	The tick lifts the end-date filter	Filter the End Date column for 12 December 9999
Voucher Redemption for `GS` shows rows with no document	Other companies’ redemptions, and direct redemptions, are not filtered out	Count rows with a document number only; its Location Code column shows the document date, so read Branch Code instead
The same exception e-mail arrives once per company	Every named company gets the tenant-wide list	Name one owner for it; schedule it for one company if one copy is enough
A member’s March points are in April	Points lines carry the date the points job wrote them	Expected for a bill finalised after the month; compare on the bill’s date when it matters

What has no report, and who does the job instead

The liability in ringgit. Outstanding points post no journal, so nothing in the ledger shows what you owe your members. Finance builds it from the lots at each month-end and books the movement by manual journal — What you owe your members.
Points outstanding by company or by branch. The stored balance and the lots carry neither. The transaction lines from a bill carry the bill’s company and branch, and expiry lines carry none, so group finance builds the split from the lines and the contra rows that pair each redemption or expiry with the earning it drew on. It is right when the companies sum back to the tenant total.
Revenue or retention by member class. No sales report filters by member class. Whoever owns the programme exports each class’s members, matches them to sales by customer, and compares the same members before and after promotion — before the next promotion round, not after it.
Campaign return or redemption rate. Voucher Redemption gives redemptions and Ticket Management gives generated and assigned counts; the ratio is yours to divide. A redemption rate far below the earn rate is normally a broken programme, not a saving — program design has the causes to rule out. A claim that the programme drove extra sales needs members compared with similar non-members over the same period.
Expired points over a period. Query the transaction lines for type EXPIRY in the date range. If none appear for months, check whether an expiry clock exists before reading it as “nothing lapsed”.
A statement for the member. When a member disputes a balance, what you send is the Point Transaction export with a covering note. Decide who produces it, and whether it includes hidden lines, before the first dispute rather than during it.
A dashboard. The module has none.

How this fits with the rest of membership

What must exist first. A points rule per company that names the document your branches finalise, a redeem rate, and an expiry clock if points are to lapse (Points Setup). Without the first, the Z Report shows discounts that never reach the member’s points.
What it makes possible. A month-end figure for the liability, a monthly exception review, and an answer to a member’s dispute that you can show them.
The sibling. POS reports read the same bills from the till’s side; the Sales Report holds Voucher Redemption.
What breaks elsewhere when it is wrong. An unexplained mismatch left in the stored balance is what the till offers the member next time; a Membership Report filtered on Join Date sends a campaign to the wrong members.
What it pairs with. What you owe your members for the month-end procedure, and Walk the chain when one member’s points look wrong.