Member Classes and Labels
GadgetSphere runs three classes — STANDARD, SILVER, 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 |
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 member who spent RM 5,000 this year moved from SILVER 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.
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 price.
What reads the labels:
| Reader | What it does with it |
|---|---|
| Topics in CP Commerce Admin | A background assignment job subscribes the app devices of members carrying a linked label to the topic, for push notifications. A member with no registered device gets nothing, and removing the label does not unsubscribe anyone — that is a separate un-assignment job |
| A voucher’s header rule Member Label | On the storefront’s list of a website’s vouchers, a voucher with picked labels is shown only to a signed-in member who carries one of them — a members-only offer without a separate campaign |
| Pricebook price set header rule Member Label | Declared on the rule form, but the client-side calculator ignores it — the rule is treated as satisfied on sales documents; only the OCR processor’s generic nodes read it |
| Commission Scheme header rule Member Label | Passes when the member has any label link; the picked labels are not compared |
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 or a commission until those two rules are fixed. 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 spending and not earning
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. 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.