Retail Loyalty Program

GadgetSphere wants every walk-in customer at its 22 branches to be a member who earns one GSPTS per ringgit and can spend points at the till. This page follows one customer through that loop and names the applet at each step, for whoever owns the programme or runs the counters. It is the shape most of the other use cases build on.

Before the first bill

What must exist	Where	Why
A point currency `GSPTS` and a points-to-money rate (say 100 points = RM 1)	Membership Admin → PTS CCY Module and PTS to CCY Config	Without a currency nothing is earned; without a rate nothing can be redeemed for money
A card-number rule (running number, IC or mobile)	Membership Admin → Settings → Field Settings	With no rule the applet gives every new member a random six-digit card number — choose the rule before the first member is saved
Member classes `STANDARD`, `SILVER` and `GOLD`	Membership Admin → Member Class	Optional, but the price-book rule below needs them. This page follows a `STANDARD` member; the faster `SILVER` and `GOLD` rates are price sets of their own (Tiered Membership)
The company member-point configuration naming the cash-bill document type (`INTERNAL_SALES_CASHBILL`) and the status `FINAL`	Company API — there is no screen for it, in Membership Admin or in Organisation	The backend awards points only when the document’s type and posting status match this configuration. The default is `INTERNAL_SALES_ORDER` at `FINAL` — leave it unset and cash bills earn nothing
A price book with a POINT treatment (Point Currency `GSPTS`, Operator MULTIPLY, Value 1, Validity Period in days), selected as the POS Default Pricebook	Pricebook; POS General → Default Selection	This is what puts a point amount on each bill line; a member on a bill with no point amounts earns nothing. *Leave Auto Apply Points From Pricebook* switched on** — it is the server’s backstop: the backend reads that POS General setting and, if it is on, fills points into lines that arrived with none. Off, the server adds nothing and says so only in the server log; points the till already put on a line are kept (Reward Types)
A `MEMBER_POINT_DISCOUNT` item, set as the POS Points Discount Item Code	Doc Item Maintenance; POS General → Default Selection	Needed only if you redeem points as a discount line rather than a settlement line
`SHOW_MEMBER` on in POS General	POS General settings	Shows the member panel at the counter

The loop

Enrol at the counter. The cashier opens the member panel in POS General and creates the member: name, mobile number, IC or passport if that is the card-number rule. The class is the POS default (POS_DEFAULT_MEMBERSHIP_CLASS, say STANDARD) and the end date the POS default (POS_MEMBERSHIP_END_DATE). The record is the same membership card you would see in Membership Admin. Creating it here also gives it a customer record, which the till needs: POS General refuses a card with no customer on a bill. A card made elsewhere without one can have one created and bound later by a scheduled processor.
Sell. A flagship smartphone at RM 3,200 and a case at RM 89 go on the bill at GS-KV-01. Because the member is on the bill and the price book’s price set matches (Member Class rule STANDARD, Branch rule, an absolute Valid Date Range), the POINT treatment writes a point amount and the currency GSPTS on each line, with validity dates from the treatment’s Validity Period (Days).
FINAL. The cash bill posts revenue, stock-out and the cashbook exactly as a bill without a member would. Separately, the membership processor sees a document of the configured type at the configured status with a member and eligible lines, and writes one REWARD transaction line per bill line (3,289 points here). The lines’ point start and end dates become the lot’s validity. If none of the lines carries a point amount the document is left unmarked so a retry can pick it up.
Balance. The running total and the per-lot balances are updated by a queued recalculation after the line is written. The member’s Point Transaction tab in Membership Admin shows the row with source, type and dates.
Redeem on the next visit. The customer buys wireless audio for RM 249 and asks to use points. The cashier picks the member-points settlement button; the panel converts points to cash value through the PTS to CCY rate, up to the balance the till loaded when the member was picked. The till enforces that cap on screen; the server does not re-check a points settlement at FINAL, because it is a payment line and the server’s balance check reads only points-discount lines. If the branch prefers the discount-line route, the MEMBER_POINT_DISCOUNT item carries the redemption as a line instead, and that line is checked against the member’s stored balance at FINAL when the bill screen finalises it with a member on the bill (not on every path to FINAL: Reward Types). Either way a REDEEM transaction line is written.
Void. Voiding a bill does not reverse its points: the till keeps offering what the bill earned, and points it redeemed are not given back. If the customer returns the phone they earned 3,200 points on, take the points back with a Point Adjustment on the member, then check the till against the remaining points on the member’s lots — not the Points Expiry tab (Membership in Depth → A stored running total says why the two differ, and what a void and an adjustment each do to them).

What the ledger sees

Nothing from the module itself. Earning a point posts nothing; a redemption reaches the ledger only as the cash bill’s own settlement or points-discount line; and the product keeps no points liability account (Membership in Depth → What posts to the ledger). If your accountant wants one, it is a manual journal from the balance query (What You Owe Your Members).

What does not happen

No tier is upgraded when the customer’s spend crosses a threshold; the class is what you set.
No welcome e-mail, SMS or physical card is generated by the module.
No built-in “50 % of transaction” redemption rule; the POS points settlement method carries its own limit, an amount or a percentage of the bill, and the till caps it at the balance, nothing else. A 50 % cap is that percentage, set on the method.
Points do not expire “24 months from earning” unless the lot carries that end date — the POINT treatment’s Validity Period (Days), the adjustment’s Valid Date To or the CSV column set it, and the scheduled expiry processor then zeroes the lot.

Reports you can run

Membership Admin → Membership Report (CSV by date of birth, start, end, lifetime).
The POS General Z Report, which shows member-point discounts. (Sales Report’s member-reward-redemption route is off the menu and shows sales rows, not points.)
The API: …/membership-points-txn/current-balance/query and …/lines/query — see API Reference.