Points Redemption Strategies
A GadgetSphere member with 12,000 GSPTS (RM 120 at 100 points = RM 1) buys an ultraportable
laptop for RM 3,499 at GS-PEN-01. There are three ways the points, or a voucher, can reduce what
they pay. Each is a different line on the cash bill, and the ledger sees each differently.
1. Points as a settlement line
The cashier picks the member points settlement button in
POS General. The panel converts points to cash
through the PTS to CCY rate up to the configured maximum; the customer pays the rest by card. At
FINAL the backend validates the redeemed points against the balance and writes a REDEEM
transaction line, drawn down from the member’s lots through contra rows.
Ledger: the cash bill posts its full revenue; the points settlement is one of the bill’s settlement-method lines and posts the way the cash bill’s settlement lines post (see the POS General page). That is the cash bill’s posting, not the module’s.
2. Points as a discount line
If the branch is configured with a Points Discount Item Code (POS_DEFAULT_POINTS_DISCOUNT_GUID,
a MEMBER_POINT_DISCOUNT item from
Doc Item Maintenance), the redemption
becomes a negative line on the bill using that item. Revenue is reduced by RM 120; the customer
pays RM 3,379. The same REDEEM transaction line is written.
Ledger: revenue is lower by the discount, posted to the discount item’s GL code. Again the cash bill’s posting.
3. A voucher
A SETTLEMENT voucher from Voucher Management
(face value RM 100, a FIXED quantity of tickets, a Member Class rule) is redeemed by scanning the
ticket serial: it must sit on a settlement-method line of the bill; a PRODUCT voucher must sit
on a product line. Redemption flips the ticket’s redemption status — it does not check the
redemption date range, which is why the expiry-checking call exists — and the ticket’s history
shows Redeemed against the bill. No membership points move unless the voucher is a REWARDS
voucher with a points treatment.
Ledger: the voucher line is a settlement line of the bill. There is no voucher-liability or breakage journal anywhere in the backend.
What the membership tables record
| Event | Row written |
|---|---|
| Earning | bl_crm_membership_points_txn_line, txn_type = REWARD, one per document line with a point amount; a control-account lot with date_start / date_end |
| Redemption (1 or 2) | A REDEEM line; contra rows against the lots it consumed; bl_crm_membership_points_current_balance updated by the queue processor |
| Void of the bill | The bill’s lines reversed; an adjustment line for any shortfall if the balance is now insufficient |
| Expiry | An EXPIRY line and the lot zeroed, by the scheduled elimination processor |
None of these rows carries an amount signum: INTERNAL_MEMBERSHIP_POINT_REWARD(0,0) and
INTERNAL_MEMBERSHIP_POINT_REDEEM(0,0) in ServerDocTypes, no JournalPostingTypeHandler
entry. A points balance is not a liability account in BigLedger. If Finance wants to carry
one, it is a manual journal from the current-balance/query API each month-end.
Online
On a CP Commerce storefront the checkout widget can enable membership points and cash vouchers; the cart order earns points through the same document-and-status rule, run by the CP Commerce member-points processor, and the storefront shows the balance with the Membership Points Counter widget (CP Commerce Admin).
What the old page had and the product does not
A rewards catalogue with point prices and separate rewards inventory; “smart redemption suggestions” and minimum-purchase tiers; partner rewards (cinema, streaming, dining, hotel) with a partner API; charitable donations with tax receipts and leaderboards; gift-voucher generation from points with a 12-digit code and a member wallet; a 50 %-of-transaction cap; burn-rate analytics. The only redemption paths are the three above, and the only limits are the POS points maximum, the balance check at FINAL, and a voucher’s per-customer and daily limits.