Member Classes and Labels
“How does a member move up to Gold?” By hand. A member’s class is set on the member form or by a CSV upload, or given at enrolment by the counter’s or the website’s default class, and nothing in the backend moves a member between classes on spend, points or time. This page is for whoever designs the tiers and the segments: what a class and a label are, which parts of BigLedger read each, and what the card’s end date stops.
GadgetSphere runs three classes — STANDARD, SILVER and GOLD — and a handful of labels such as
NEWSLETTER, GAMING and CORPORATE. The class decides the member’s price and commission rules;
the labels decide who gets which newsletter. Neither changes on its own.
Member class — one per member
A member class is a record with a code, a name, a status, optional
images and aliases, and two tabs in Membership Admin
listing the labels linked to it and the members in it. A member is in exactly one class, chosen on
the member form, set by the MEMBER CLASS column of a CSV upload, or given by
POS_DEFAULT_MEMBERSHIP_CLASS when the counter enrols a walk-in.
What reads the class:
| Reader | What it does with it |
|---|---|
| Pricebook — price set header rule Member Class | The price set applies only when the member on the document is in one of the picked classes; POS General, Sales Invoice, Sales Order and Sales Quotation evaluate it when a line is added |
| Commission Scheme — header rule Member Class | The scheme pays (money or points) only when the document’s member is in a picked class — never on a document with no member; a rule saved with an empty pick list passes unconditionally |
| CP Commerce Admin | The website’s default class for new registrations; a Spending Limit per member class for B2B portals |
| Voucher Management — doc-header rule Member Class | A voucher the till accepts only from members of the picked classes, such as GOLD (it checks the voucher’s rules when the serial is scanned) |
The birthday-gift run (MEMBER_BIRTHDAY_GIFT_PROCESSOR in the Scheduler applet’s processor picker) | Its member-class list restricts birthday points or vouchers to the picked classes |
There is no tier engine. Nothing in the backend promotes or demotes a member: no spend
threshold, no points threshold, no qualification period, no grace period, no annual reset. If
GadgetSphere wants a SILVER member who spent RM 5,000 this year moved to GOLD, someone
changes the class on the form or re-uploads the CSV. Plan the classes as a set of prices and rules
you assign, not as a ladder the system climbs for the member.
A class change recomputes nothing. A price set’s Member Class rule is read at the moment a line is
added to a bill, and the line keeps the points it got; a commission scheme’s Member Class rule is read
when the scheme runs. A member moved from SILVER to GOLD on 1 July earns at the new rate from the next
bill and keeps every line earned before it as it was. The record of when the class changed is the
member’s UPDATED row in Membership Admin’s Audit Trail.
Member label — as many as you like
A label is a tag with a code and a name, grouped under a label list (a label created inside
a list carries the list’s code). A member’s Labels tab links and unlinks them; the CSV upload takes
up to three (LABEL 1 … LABEL 3). Labels have no hierarchy and no effect on the till’s price.
What reads the labels — a push-notification topic, a storefront voucher, a price-set rule and a commission rule — and what each does with them is on Member Labels: who reads a label. Two things there decide how you use labels: a topic subscribes only the registered app devices of labelled members, so a member with no registered device gets nothing, and removing the label does not unsubscribe anyone — that is a separate un-assignment job; and a voucher with a picked label is shown on the storefront’s voucher list only to a signed-in member carrying one of them.
So a label is a reliable way to choose who is told about something — a push-notification topic, a storefront voucher — and an unreliable way to gate a price at the till or a commission, because those two readers do not compare the labels you pick. Use a class for anything that must change what the till charges.
Class versus label, in one line each
- Class: which price list and which commission rules apply to this member — one, assigned.
- Label: which lists this member is on — many, assigned.
Watch the end date, because it stops earning and spending at the till
A membership’s End Date is a separate thing from the class and it catches people out. When it passes, the counter’s point screen refuses before it looks at anything else — it compares today against the member’s End Date and stops — so the member cannot redeem, and the till works out no points for the bill’s lines either. The backend does not read the card’s end date: points a line already carries when the bill reaches FINAL are still awarded. Their points do not expire with the membership. The lots keep their own end dates, the balance stays where it is, and the member is left holding points they can see and cannot spend.
Nothing tells them, and nothing tells you. Someone has to run the Membership Report on End Date
each month and decide what happens to those members — extend, renew as a policy decision, or let
them lapse and pay out the balance as a goodwill adjustment. The check that it is being done is
that no member turns up at GS-KV-01 with a positive balance and an expired card, because that
conversation has no good ending at the till.
Related
- Member setup — create classes and labels before members.
- Reward types — how a class becomes a price.
- Member Classes and Member Labels — the task guides that create them and put members in them.