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 — and it is written down in planning/specs/module-applet-membership.md. 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 (`bl_crm_membership_hdr`: 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 the audit trail. 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 (`bl_fi_mst_coupon_hdr`: 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 (`bl_mlm_program_hdr`), 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 `invited_by` 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 row in bl_crm_membership_points_txn_line with a type — REWARD, REDEEM, EXPIRY, CF or BF — 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 (MembershipPointsTxnService.docTypeValid L640–646, processData L648 ff.). 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 (MemberPointConfigUow L16–19, L71–95), 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 (source ADMIN_MANUAL_POINTS_ASSIGNMENT) 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 a date_end; the expiry processor zeroes every lot whose date has passed and writes the EXPIRY line (MembershipCtrlAccAndCurrentBalanceService.expireMembershipPoints L273–276). There is no expiry rule to configure — validity is set where the points are created. Voiding the source document reverses its lines, and adds an adjustment if the member has already spent them.

What posts to the ledger, and what moves stock

Nothing in this module does either. The two membership document types exist only as labels — INTERNAL_MEMBERSHIP_POINT_REWARD(0,0) and INTERNAL_MEMBERSHIP_POINT_REDEEM(0,0) (ServerDocTypes.java L56–57, amount and quantity signum both zero) — and JournalPostingTypeHandler has no entry for them, for a voucher, a coupon, a ticket, an MLM program or a lineage (grep of the handler and of GenericDocumentTypeHandler for MEMBER, POINT, COUPON, MLM: none; the only “voucher” entries 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 (CouponRedemptionProcessorService L38–79); 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 — MembershipClassService and the membership job processors contain no such logic.
No expiry-rule screen, no rolling or calendar expiry policy. Each lot expires on its own date_end, 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. Vouchers are created in Voucher Management and assigned; the product has no screen where a member spends points to obtain one.
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.

Learning path

Core Concepts — customer versus member, classes and labels, point currencies and lots, expiry, the three ways a member gets value.
Configuration — what must exist before the first member, in which applet, in what order.
Use Cases — five shapes on the GadgetSphere backdrop.
Reports — what can be reported, and what cannot.
Best Practices — consequences of how the applets behave.
API Reference — the endpoint families and six worked endpoints.
Related Applets — the two membership tables above, as cards.