Reports & Analytics
Reporting in this module is thin and honest: a few CSVs, one report screen, and the API. The previous version of this page described a “reporting matrix” of four reports, three of which do not exist.
What you can run
| Question | Where | What it gives |
|---|---|---|
| Who are our members, by birthday, start or end date, lifetime? | Membership Admin → Membership Report | A CSV in the report queue, with status and error message per run |
| Who changed which member record, when, from which device? | Membership Admin → Audit Trail | Applet code, table, action, user, device, dates |
| What did one member earn, redeem, lose to expiry? | Membership Admin → member → Point Transaction and Points Expiry tabs | Every transaction line with source, type, dates; every lot with balance and next expiry check |
| Points earned and redeemed by card, item and transaction type across members | The API’s transaction-lines query (GET …/membership-points-txn/lines/query) | Filter by card, point currency, transaction type, item, company, branch and date range; it returns the lines, and the totals are yours to add up. (Sales Report has a member-reward-redemption route, off its menu, but it shows sales rows and no points) |
| Which vouchers were redeemed, where, on which document? | Sales Report → Voucher Redemption | Redemption date, voucher code / name / type, serial, amount, statuses, company, branch, location, document, entity; filter by company, voucher code, date redeemed |
| Tickets generated, assigned, redeemed for one voucher; a ticket’s full trace | Voucher Management → Ticket Management counts; Ticket History; the CSV export | Per voucher and per serial |
| Member-point discounts given at the counter today | POS General → Z Report | Discounts and member-point discounts per cashier and session (POS_SHOW_MEMBER_POINT_DISCOUNT_Z_REPORT adds the column) |
| Commission and points produced by a commission scheme, including MLM uplines | Sales Commission → Sales Commission Report | Money and Point per report; Member, MLM Member and MLM Program columns; Line Item traces each figure to the scheme |
| Points transactions that look wrong | The exception-report run (MEMBERSHIP_POINTS_EXCEPTION_REPORT_PROCESSOR in the Scheduler applet’s processor list) or the exception-report summary API | A CSV per company of nine checks — redemptions with positive, zero or empty points, rewards with negative or zero points, the same points twice for one member within two minutes, an OCR line on an inactive product, a balance mismatch, a redemption without enough balance — over the last 7 days, e-mailed to the recipients the schedule names or else to each company’s own e-mail address, and only when something is found. The schedule must name the companies, or it sends nothing |
| Anything else | The API — the current-balance, transaction-lines and membership-card queries | Filter by card, currency, dates, class; see API Reference |
What does not exist
- A points liability valuation. Outstanding points post no journal, so nothing in the ledger
shows what you owe your members. The figure is the current-balance total multiplied by
your PTS to CCY rate — and nobody in BigLedger produces it for you. The stored balance still
counts points past their end date until the expiry sweep has run, so take the figure after it. Someone in finance runs
that query at each month-end, before the period is locked, and books the movement as an accrual
by manual journal. You know it is right the way you check any accrual: this month’s balance
minus last month’s must equal points earned, plus adjustments, minus points redeemed, minus
points expired over the same dates — and the transaction-lines query gives you those four by
transaction type (
REWARD,ADJ,REDEEM,EXPIRY). Leave out the adjustments and the check fails by exactly the birthday gifts, storefront points and manual corrections of the month. If the balance moved and your sales did not, an earning rule changed. The full procedure — valuing it, the breakage assumption, releasing it at expiry, and which company in a group owes it — is what you owe your members. - Tier retention or revenue by class. No report joins sales to member class. The sales reports filter by customer, category, salesman and item — not by member class. So whether a tier changes behaviour is answered outside the product: export the members of each class with the membership-card query, match them to sales by customer, and compare the same members before and after they were promoted. Whoever owns the programme does this before the next promotion round, because the alternative is promoting on a feeling.
- Campaign ROI or redemption rate. Voucher Redemption gives redemptions; Ticket Management gives generated and assigned counts; the ratio is yours to divide. The harder half is what the ratio means — a redemption rate far below the earn rate is normally a broken programme rather than a saving, and the four causes to rule out before you celebrate it are in program design. And a claim that the programme drove incremental sales needs a comparison the product cannot make for you: members against comparable non-members over the same period, not members before and after joining.
- Expired-points totals over a period. Query the transaction lines for transaction type
EXPIRYin the date range. - A dashboard. There is none in the module; the platform’s report builder is not documented here.
- Points outstanding by company or by branch. The stored balance carries neither — there is one balance per member and point currency for the whole tenant. The member record has a company and a branch, but that is where the member was registered, not where the points were earned. The transaction lines do carry company and branch (a document’s own, or what the adjustment form was given), so group finance builds the split from the transaction lines rather than from the balance, and knows it is right when the companies’ figures sum back to the tenant-wide total.
- A branded statement the member can be given. We show a balance in a storefront widget; there is no statement document with your logo on it. When a member disputes a balance, what you send them is the Point Transaction export with a covering note — so decide who produces that and what it looks like before the first dispute, rather than during it.