Membership in Depth

Membership in BigLedger is a register of members and four ways of giving them something: points earned on a document line, by a commission-scheme run or from a photographed receipt, and vouchers. This page is what happens behind those screens. The applets themselves are listed on the Membership module page.

Where points come from, and where they go

Every point is a point-transaction line with a type — REWARD, REDEEM, ADJ, EXPIRY, CF or BF, plus an ADJ_INSUFFICIENT adjustment written when a void leaves a member unable to cover a redemption — a currency, a value and a validity window. Five things write such rows:

A sales document. When a document reaches the configured status carrying a member, the backend writes one REWARD (positive) or REDEEM (negative) line per document line that has a point amount and a point currency. The amount got onto the line from a Pricebook Point treatment, or from the cashier redeeming points. Which document type and status qualify is a per-company setting with no screen — and its default is INTERNAL_SALES_ORDER at FINAL so a retailer that earns at the counter must set it to the cash-bill type before the first bill.
The Commission Scheme points run — scheduled, reads the same company setting, applies the scheme’s first Membership Points treatment.
OCR Cash Bill — a price book evaluated on the server against the scanned lines.
Membership Admin — a manual adjustment, written as an ADJ line, or a CSV upload of point transactions.
The birthday-gift processor — points (or vouchers) to members of chosen classes on their birthday, with a validity in months, if you schedule it.

Each earning lot is also a control-account row with its own end date; the expiry run zeroes every lot whose date has passed and writes the EXPIRY line. There is no expiry rule to configure — validity is set where the points are created. Voiding the source document does not take its points off the member’s balance: it removes the lots, where the void is set up for points, but the lines stay and the balance the till shows is unchanged. See Points Setup for what to do instead.

Where the numbers on these screens come from

Every membership figure a cashier or a member sees was written at an earlier moment and is read back, not worked out when you look at it. Knowing which moment wrote it answers most “this number is wrong” questions before you open a record.

The figure	Written when	So, when it looks wrong
The points on a bill line	At the time the line is added, by the till or the sales document, from the price set’s Point treatment. The line keeps the points and the price set’s name; the document keeps no price-book reference	Changing the price book afterwards leaves a bill already rung as it was — How member rewards work
The member’s `REWARD` and `REDEEM` lines	When the document reaches the one type and status the company’s `MEMBER_POINT` configuration names — an internal sales order at `FINAL` unless somebody changed it	A bill that showed points and left none on the member is almost always the wrong document type, not the price book
The balance the till offers	A stored running total per member and currency, updated as each line is written, not recalculated from the member’s lots at the moment of sale	It disagrees with the lots before an expiry run, straight after one, and after a void — Points Setup names all three
A ticket’s `REDEEMED` status	By a job that runs after the bill is finalised, and only for a ticket inside its redeemable dates	The ticket reads `UNREDEEMED` for a while, or for good — Voucher Management → Troubleshooting
What you owe members in points	Nowhere. The product keeps no liability figure	Finance builds it each month from the balances — What You Owe Your Members

What posts to the ledger, and what moves stock

Nothing in this module does either. The two membership document types — point reward and point redeem — exist only as labels: they carry no amount and no quantity, and the journal posting has no entry for them, nor for a voucher, a coupon, a ticket, an MLM program or a lineage (the only “voucher” entries it knows are the payment and receipt vouchers of Financial Accounting). A points redemption or a voucher reaches the ledger only as a line on the cash bill or invoice it settles or discounts — the settlement line, or the points-discount line — and it is that document’s journal handler, documented on the POS General page, that posts. A voucher redemption flips the ticket’s status when the document is processed; it does not post.

What the module has no engine for

Written down because the previous version of these pages, and most descriptions of a loyalty platform, assume them:

No automatic tier progression. A member class is set by hand (or by the POS / storefront default class at creation). No processor reads spend, points or visits to upgrade, downgrade, protect or grace a member.
No expiry-rule screen, no rolling or calendar expiry policy. Each lot expires on its own end date, set when it was earned.
No points liability or breakage accounting. Points post nothing; if you carry a liability for them, you journal it yourself from the balance report.
No points-funded voucher catalogue in the back office. Vouchers are created in Voucher Management and assigned; the one place a member spends points to obtain one is a CP Commerce storefront, where a coupon item priced in redeem points carries a Buy Now button that turns the points into a voucher serial.
No member-class pricing scheme. Pricing schemes on Doc Item Maintenance are price-list templates with no member link; the member-aware price is a Pricebook price set with a Member Class rule.
No override-points or multi-level bonus engine. The MLM tree pays through the Sales Commission posting run of an MLM commission scheme, in money or points, up to ten levels.
No SLA, dashboard, RFM or churn analytics. The reports that exist are listed on the Reports page.

Registry rows that are not documented here

One registry row assigned to this module by name — an e-coupon maintenance applet — is a subsidiary’s product and is excluded from the wiki by decision (2026-09-15). The two Voucher Management rows are both documented; which bundle each installs is pending a registry check.

How the pieces depend on each other

What must exist first. A member needs only Membership Admin: choosing a customer is optional, and when none is chosen the backend looks for one by the member’s sign-in, then phone, then e-mail, and creates a new individual customer only when none matches. Points depend on more, and in order — a point currency and its rate, a price book whose price sets carry a Point treatment, that book set as DEFAULT_PRICEBOOK on each terminal, and a MEMBER_POINT configuration that names the document you actually sell on. How member rewards work → Order has the full sequence. Anything meant to happen by itself — expiry, the birthday gift, the commission points run, recurring vouchers — also depends on a clock in the Scheduler.

What a class makes possible. One member class lets you price (a Pricebook price set with a Member Class rule), target vouchers (a voucher’s Member Class rule) and choose who gets the birthday gift. Set the tier once and three features read it.

Siblings, and when to use which.

A class or a label? Use a class for anything the counter must honour. Use a label for the web store, push messages and campaign lists: the web store honours a label rule label by label, while the till and the sales-document price calculators treat a Member Label price rule as met by everybody. Member Labels has the six readers and what each does with a label.
Price-book points or commission-scheme points? A price book puts the points on the line as it is rung. A Commission Scheme awards later, in a scheduled run, by rules a price set does not have — sales-agent category, customer type, a date range. Choose the scheme when the reward depends on who sold, or on the period, rather than on what was sold.
A voucher or points? Points accumulate on the member and are spent at the till. A voucher is a ticket with its own dates and its own rules, and a birthday voucher belongs to the customer the member is linked to, not to the card, unless the voucher allows anonymous use.

What breaks elsewhere when this module is set up wrong.

The MEMBER_POINT document type. Wrong for how you sell, and every branch’s bills show points that never reach a member.
A terminal’s DEFAULT_PRICEBOOK. Point it at a weekend promotion book and tier prices and points stop together at that terminal, because they live in the same price sets.
Identity kept on the member and not the customer. The e-invoice reads the customer’s identity number, and editing a member leaves the customer record as it was — so the buyer’s IC is blank on the e-invoice although it is on the card (scenario 024).
The birthday clock. A monthly gift on a daily clock gives the gift again every day of the month.

What it pairs with in practice. Membership is almost always used alongside POS General: points earned on bills and spent at the till are by far the commonest reward, and vouchers are much rarer. Where a company has changed its MEMBER_POINT configuration at all, it has almost always pointed it at the cash bill.

When it goes wrong

A membership complaint usually arrives as “the points are wrong”. The cause is generally one setting, in a place the screen in front of you does not show.

Symptom	Cause	Fix
Bills show points at the till; the member’s Point Transaction tab has nothing	The bill is not the document type, or not at the status, that the company’s `MEMBER_POINT` configuration names. At its default it awards on internal sales orders only	Point the configuration at the cash bill; it is set through the company API — Points Setup
The till offers a member more than their lots still hold — the remaining points from the lot query, not the Points Expiry tab, whose Balance Amount is each lot’s original points	A lot passed its end date and no expiry run has come, or a bill that earned points was voided	Walk the chain before you post any adjustment
Every customer, member or not, gets the member price at the till	The price set uses a Member Label rule, which the till treats as met	Use a Member Class rule for the counter — Member Labels
Members received the birthday gift more than once	The gift keeps no record of who it has gifted and gives again on every run that matches: a monthly gift on a daily clock, or Run Now pressed	Match the clock to the frequency — Birthday Gift
A birthday voucher used on a bill stays `UNREDEEMED`	The ticket belongs to the member’s linked customer, the voucher does not allow anonymous use, and the bill is for another customer	Put the member’s own customer on the bill — How member rewards work
The IC is on the member and the e-invoice cannot find it	The e-invoice reads the linked customer’s identity	Chase it in membership
Points past their end date are still spendable, month after month	The expiry run is a scheduled job and the tenant has no clock for it	Create the clock in the Scheduler, then check a member, not the run

How you know it worked

Thirty seconds, one test member, at GS-KV-01. Ring a cash bill for the test member with one item whose price set carries a Point treatment, and finalise it. Then:

Membership Admin → the member → Point Transaction tab. A REWARD line for those points, dated today. If it is missing, suspect the MEMBER_POINT document type before the price book.
The member’s Points Expiry tab. A new lot for those points. Its Balance Amount is the lot’s original points, not what is left, so the tab adds up to the till’s figure only while none of the member’s points have been spent or deducted. To check the stored total against the lots for anyone else, use the lots’ remaining points from the lot query — Points Liability.
Scheduler listing. A row for MEMBERSHIP_EXPIRY_POINTS_ELIMINATION_PROCESSOR reading ACTIVE, and one for every other membership job you rely on. The clock reads only ACTIVE rows, so a membership job without one is not run on any schedule.