Membership Module

Membership in BigLedger is a register of members and four ways of giving them something. The Membership Admin applet holds the members — one row per card, with a class, any number of labels, a verification status and a join / end date — and the point currencies they collect and what a point is worth in money. Points are then earned in three places that this module only configures: on a sales document line that carries a point amount (from a Pricebook point treatment), from the scheduled membership-points run of a Commission Scheme, and from a third-party receipt a member photographs for OCR Cash Bill. Vouchers — codes, serial-numbered tickets, discount and settlement rules — are defined in Voucher Management Applet V2 (and its older build, Voucher Management) and redeemed at the counter or in the cart. Referral trees — who introduced whom, up to ten levels deep — are the MLM Admin Applet’s, and pay out only through an MLM-type commission scheme.

This page is a map, not a manual. Each applet’s own reference page carries its screens, settings, fields and failure modes. This page says which applets are in the module, what each one records, where points and vouchers actually come from and go — and, because the previous version of this page and the pages under it described a loyalty engine the product does not have, what the module has no engine for.

Applets in this module

Membership is an editorial judgement — the product has no module↔applet relationship in its data. This module owns six documented registry applets; a seventh registry row is a subsidiary’s product and is not documented here (see Registry rows that are not documented here).

Applet	What it records
Membership Admin	Members (card number, member ID, referral code, class, verification status, join / start / end date or lifetime, suspensions), member classes (tiers — a manual assignment), labels and label lists (segments), point currencies and point-to-money rates, manual point adjustments, the per-member point transaction and expiry views, CSV uploads of members and point transactions, the Membership Report and a log of who changed what, from which device. Master data: no document, no posting
Commission Scheme	The rules (which documents qualify — branch, company, document type, date, customer type, member class, sales-agent category, items) and treatments (how much per level) for sales commission and for membership points; Sales Groups; tiered Pricing Models. A scheme’s Membership Points treatment is the scheduled points source; its `MLM` commission type is what makes a referral tree pay
Voucher Management Applet V2	Vouchers (SETTLEMENT, DISCOUNT, REWARDS or PRODUCT; FIXED, DYNAMIC, IMPORT or INVENTORY quantity), their tickets (serial numbers with assignment, validity, cancellation and redeemable status), rules (document-header and line rules), treatments, website links for the storefront, recurring vouchers on a recurrence rule, ticket imports and scanned events. Master data: no posting
Voucher Management	The earlier build of the same applet — Voucher, Ticket and Scanned Event only. Both registry rows are active and both point their documentation at the V2 page; which bundle each row installs is pending a registry check
MLM Admin Applet	Referral programs, their participants (members enrolled in a program, each with an invite key and QR link), the lineage (one upline→downline edge per row, level computed 1…10), invitations sent through a contact-centre channel and accepted through a registration endpoint, and entity contacts — named people under a customer who are not yet members
OCR Cash Bill	The receipt-to-points pipeline: a member’s photographed third-party bill, the text-extraction result, merchant and line matching, and the price book that turns matched lines into point transactions

Supporting applets, owned by other modules and used here

Applet	Owner	Why Membership needs it
POS General	Point of Sale	Where a member is identified at the counter, where points are earned on the bill and redeemed as a settlement or a points-discount line, and where a voucher or coupon is taken as payment or as a line. The cash bill’s journal is the only ledger effect anything in this module ever has
Sales Invoice (Internal), Sales Order (Internal)	Sales	The other documents that can carry a member and point lines; the sales order is the document type the backend awards points on by default when a company has not said otherwise
Sales Commission Applet	Sales	Runs the posting cycle that evaluates commission schemes — including the walk up an MLM lineage — and pays the result; its reports carry Member, MLM Member and MLM Program columns
Pricebook	Core	Price sets whose header rules read the member’s class, and whose Point treatment is what puts a point amount on a document line. The only member-aware pricing in the product
Doc Item Maintenance	Core	The item a manual point adjustment is booked against; the `MEMBER_POINT_DISCOUNT` item POS uses for a points redemption line; Voucher (`COUPON`) items that record voucher stock; the `MEMBERSHIP` item type
Customer Maintenance	Core	The customer entity a member may be linked to (optional — a member can exist without one, and a processor can create the entity later); its Membership tab; credit control, which lives here and not in any membership applet
Organisation	Core	Companies and branches every member, adjustment and voucher rule is scoped to; the company-level member-point configuration that decides which document type and status award points — set through the company API, with no screen in any applet
CP Commerce Admin	E-Commerce	Post-registration can create the member; the storefront shows the class and balance widgets, links vouchers to a website, applies a per-class spending limit, and is where a referral link’s invite key lands
Sales Report	Sales	The Voucher Redemption report and a member-reward-redemption route
Scheduler	platform tool	The crontab that runs the expiry, reminder, zero-balance, birthday-gift, commission-points and recurring-voucher processors — none of them runs unless scheduled
Unified Contact Center	Digital CRM	The e-mail, SMS and WhatsApp endpoints an MLM program sends its invitations through; contact merging attaches a conversation to a membership

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 — Rewards Setup
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. Rewards Setup → 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 the remaining balances on their Points Expiry tab add up to	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 — Rewards Setup → The 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 — Rewards Setup
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. Add up the remaining balances and compare the total with the balance the till offers the member on the next bill. Equal means the stored total and the lots agree.
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.