Core Concepts
Six records make up the Membership module, and most mistakes with it come from assuming a seventh that does not exist — a tier engine, an expiry rule, a points ledger account. This page defines each record as the applet that owns it defines it, with the table it lands in. The pages under it take one record each.
| Term | What it is | Where it lives | Read more |
|---|---|---|---|
| Member (membership card) | One row per card: card number, member ID, referral code, class, labels, verification status, join / start / end date or lifetime, suspensions. May link to a customer entity; need not | bl_crm_membership_hdr (+ _ext) | Customer and member |
| Member class and member label | A class is the one tier a member is in — code, name, status. A label is a tag; a member can carry many, grouped into label lists. Both are assigned by hand | bl_crm_membership_class_hdr; label and label-list tables | Classes and labels |
| Point currency | A named unit members collect — code, name, conversion rate, cross-over flag, status — plus a point-to-money rate per currency | bl_crm_membership_points_currency, bl_crm_membership_points_to_currency_rate | Point currencies and balances |
| Point transaction line | Every earn, redemption, expiry or adjustment, with a source, a validity window and a display flag | bl_crm_membership_points_txn_line | Point currencies and balances |
| Point lot and running balance | Each earning creates a lot with its own end date and remaining balance; redemptions draw lots down; a separate row keeps the running total per member and currency | bl_crm_membership_points_ctrl_acc (+ _ctrl_contra_details), bl_crm_membership_points_current_balance | Points expiry |
| MLM lineage | Which participant of an MLM program invited whom, as uplines and downlines | bl_mlm_* | below |
What a member is not
A member is not a customer. The membership card is its own record; it may carry an
entity_hdr_guid pointing at a customer, and the backend can create that customer for it, but a
member with no customer earns and redeems points just the same. The Customer Maintenance
record is what carries credit terms, addresses and tax identity; the card carries the loyalty side.
A member is not a login. The e-commerce storefront’s post-registration step can create a member for a new login, and the contact centre can merge a contact with a card, but neither is required for a card to exist.
What the module has no engine for
- No tier engine. A member’s class is set on the member form, by CSV upload, or by the counter default. Nothing in the backend moves a member between classes on spend, points or time — there is no threshold, no qualification period, no grace period.
- No expiry rule screen. Points expire lot by lot on the end date each lot was given when it was earned; a scheduled processor sweeps the lots that have passed it.
- No points journal.
ServerDocTypesdeclaresINTERNAL_MEMBERSHIP_POINT_REWARD(0,0)andINTERNAL_MEMBERSHIP_POINT_REDEEM(0,0)— amount and quantity signum both zero — andJournalPostingTypeHandlerhas no membership entry. A redemption reaches the ledger only through the cash bill it settles or discounts, and that posting belongs to POS General. - No points-to-points conversion screen. The route exists in the applet; its menu entry is commented out. The currency record carries a cross-over flag and nothing on the screens uses it.
Three ways a member gets value
| Path | What happens at the counter | Owned by |
|---|---|---|
| Member pricing | A price book whose price set has a Member Class rule changes the unit price or discount on the line when the member is on the bill | Pricebook |
| Points | Points earned on earlier bills settle part of this one, or arrive as a points-discount line | Membership Admin holds the balance; POS General redeems |
| Vouchers | A voucher or coupon serial is scanned and taken as settlement or as a line | Voucher Management |
Reward types sets the three side by side.
MLM — lineage, program, commission
The Membership Admin member form has two tabs for referral selling: Referrals (who this member
invited and who invited them) and MLM (pick a program, then the member’s uplines and downlines
with level, invite method and status). Behind them are the bl_mlm_* tables, served by seven
controllers under core2/tnt/dm/mlm/ — programs, program participants, lineages (with
/uplines/{guid} and /downlines/{guid}), invitations and their acceptance, entity contacts and
a program-to-contact-centre-endpoint link. The MLM Admin Applet
is the screen over those tables.
An MLM program carries a commission_scheme_guid. A Commission Scheme
whose commission type is MLM is applied by the sales-commission posting run: for each qualifying
document it walks the customer’s lineage in bl_mlm_lineage_hdr and pays each upline at level n
the scheme’s Level n treatment, up to ten levels. That is the whole of what the product does with
a lineage — money through the Sales Commission Applet,
points through the same scheme’s Membership Points treatment. There is no separate “override
points” engine.
flowchart LR
C[Customer entity] -. optional link .- M[Member card]
M --> K[Class · one]
M --> L[Labels · many]
M --> T[Point transaction lines]
T --> LOT[Point lots<br/>end date each]
T --> BAL[Running balance<br/>per currency]
M -. program .- MLM[MLM lineage]
What to read next
- Configuration — what must exist before the first member earns a point.
- Use cases — the shapes the module supports, on the GadgetSphere backdrop.