Rewards Setup

Membership Admin decides who a member is — the class, the labels, the point currency. What a member gets back is configured somewhere else, mostly in applets that also serve customers who are not members at all. That is deliberate: the one price book a GadgetSphere till reads for walk-ins is the same book that gives Gold members 5 % off, so a member rule is one more price set, not a second pricing system to keep in step.

What a member’s bill actually writes

None of this is on the screen, and it decides every answer to “why didn’t she get her points?”

• The price and the points are worked out at the till at the time the line is added, and stored on the line: the points as the line’s point amount and point currency, the price set’s name in the line’s description. That name is the only trace of which price set priced the line — the document records no price-book reference, so six months later it is all you have to go on.
• Points become a member’s points only on one document type, at one status. The company’s MEMBER_POINT configuration names a single document type and posting status (by default an internal sales order at FINAL); a document of any other type writes no point transaction, however many points its lines carry. Points Setup has where that configuration lives — it is the first thing to check when the till shows points and the member has none.
• The balance the cashier sees is a stored running total, not recalculated from the lots at the moment of sale. It usually agrees with the member’s lots and departs from them at three named moments, all on Points Setup.
• A voucher is marked redeemed by a job that runs after the bill is finalised — where your tenant’s trigger configuration starts it on FINAL — and only for tickets inside their redeemable dates at that moment. A ticket outside them stays unredeemed with no message on the bill (Voucher Management → Lifecycle).
• Nothing here posts to the ledger by itself. Points carry no journal; a voucher posts nothing of its own. The money side of a reward is whatever the cash bill itself posts — the discount on the line, the points or voucher settlement line.

Which one to use

• Something every member of a tier should get without asking — a price set with a Member Class rule. Automatic, at the till and on sales documents alike. Name the class on every price set meant to award points, because the server’s fill-in pass discards a price set with no Member Class rule.
• Something one person, or one campaign, should get — a voucher rather than a price set. It is the only reward that can be given to this member and not the next one: a RM 50 apology after a late repair, a launch-weekend code.
• A segment that is not a tier — a label, but only online. The web store honours a voucher’s Member Label rule; the till and the sales-document price calculators ignore a Member Label price rule and treat it as satisfied (Member Labels). A label is an online and marketing segment; a class is a counter segment.
• One price for one account — the customer’s own item pricing in Customer Maintenance, not membership.

In practice, points earned on bills and spent at the till are by far the commonest reward, vouchers much rarer, and a group that has never issued one loses nothing by starting with points alone. Once the price sets carry a Member Class rule, the same classes let you target vouchers and the birthday gift without building anything twice.

The birthday gift

The one reward that runs on its own. A clock you schedule for MEMBER_BIRTHDAY_GIFT_PROCESSOR in the Scheduler gives each member of the classes it names either points (a currency, an amount, a validity in months — 12 if left empty) or one new ticket of each voucher it lists. No screen in Membership Admin sets it up: you pick the processor under Select Processor and type its settings on the Json tab, which opens empty. GadgetSphere’s version — 500 GSPTS for Gold members, valid three months — is:

{
  "gift_type": "POINTS",
  "check_frequency": "DAILY",
  "point_currency": "<guid of GSPTS>",
  "point_amount": 500,
  "points_validity_in_months": 3,
  "member_class_guids": ["<guid of GOLD>"],
  "send_mail": false
}

Four things the Json tab will not tell you:

• The run keeps no record of who it has gifted. With DAILY it picks members whose birthday is today; with anything else it picks everyone born this month. So a DAILY gift needs a clock that fires once a day, and a monthly gift a clock that fires once a month — the platform’s own helper pairs them the same way, daily for DAILY and on the 1st otherwise. A monthly gift on a daily clock gives every member born that month the gift every day; Run Now gives it again.
• The class list must be there. [] means every class; leaving the key out stops the run with an error before anyone is gifted. The classes and the point currency are named by their internal identifier (GUID), not their code.
• A member with no date of birth is never picked, and with DAILY a 29 February birthday matches only in a leap year.
• A birthday voucher belongs to the member’s linked customer. The ticket is assigned to the customer record the member is linked to, unless the voucher allows anonymous use — and redemption on a bill checks the ticket against the bill’s customer. A staff card linked to a company account puts the birthday voucher on the company (the member who is not the customer).

Birthday points are written as an adjustment line and added straight to the stored balance, so they are spendable at the till the moment the run finishes. A points gift sends no e-mail even when the Json asks for one; a voucher gift sends one per voucher to members with a valid address. We have no record of the gift having run in production yet: treat the first run as the test, on a class that holds only a test member. A seasonal campaign builds one end to end.

Order

Each step depends on the one before it: what a step names must exist before you can pick it.

1. Items and, if the price book will use them, item categories, in Doc Item Maintenance — a price set’s line rules point at them.
2. Member classes in Membership Admin — the price book’s Member Class rule and the birthday gift’s class list both refer to them.
3. The point currency and rate, then the MEMBER_POINT document type, if points are part of it.
4. The price book and its price sets; then set it as DEFAULT_PRICEBOOK on each POS terminal and sales document applet that should apply it, alongside PRICEBOOK_POINTS_AUTO_APPLY wherever points should apply without the cashier opening the Membership Points tab.
5. Vouchers, if any, their rules, and the VOUCHER / COUPON settlement methods on each branch that accepts them.
6. The birthday clock, last, because it names classes, a currency and vouchers by identifier.
7. A test bill per class at GS-KV-01 before the campaign goes live across 22 branches.

What breaks elsewhere when one of these is wrong

• The terminal’s DEFAULT_PRICEBOOK. A terminal reads one book. Point it at a weekend promotion book and every Gold price and every Point treatment in the tier book stops applying at that terminal for the weekend — prices and points together, because they live in the same price sets.
• The MEMBER_POINT document type. Wrong for how you sell, and every branch’s bills show points that never reach a member, while the till keeps offering the old balance.
• A price set with a Point treatment and no Member Class rule. It awards at the till and awards zero on every line the server fills in — an invoice keyed without points, a line the till missed.

When it goes wrong

What rewards do not do

• They do not post to the ledger by themselves. Nothing books a points or voucher liability; the cash bill’s own lines are the only money that moves.
• The birthday gift does not remember. It gives once per run to whoever matches, deleted members included; the clock’s frequency is the only thing between a member and a second gift.
• A bill line takes one price set. Gold 5 % off accessories and Gold double points on accessories in two price sets give the line one or the other, whichever has the higher priority — Tiered Membership shows the two builds that work.
• Tickets do not expire on a schedule. A ticket past its redeemable date still reads as valid; its dates are what the counter and the finalise step test, so set them on every voucher.

How you know it worked

One test member per class, one bill each, thirty seconds per bill. Finalise a bill at GS-KV-01 for the test Gold member with one accessory on it. On the bill, the accessory line’s discount description names the price set you expected. In Membership Admin, open the member, Point Transaction tab: a REWARD line for the points is there, dated today. If it is not, the document type is the first suspect, not the price book. For a voucher, the ticket’s row in Voucher Management → Ticket Management shows REDEEMED and the bill’s number in Redeem Invoice No. For the birthday gift, the test member’s Point Transaction tab shows an ADJ line with the remark BIRTHDAY POINTS!!! — once, not once per run.

Read next

• Pricebook Configuration — the rules the till evaluates, and the ones it ignores. Start here; it is where most member rewards live.
• Points Setup — where the points on a bill come from, and the three moments the balance disagrees with the lots.
• Membership points and vouchers — troubleshooting — walking the chain when a member says points are missing.