Skip to content

Program Design Best Practices

Design the programme around the four records the product has — the member and its class, the price set, the point lot, the voucher — and the handful of processors you schedule. Everything below is a consequence of how those behave.

Earning

  • Set the company member-point configuration first. Points are awarded only when a document’s server type and posting status match the company’s MEMBER_POINT configuration; with no configuration the defaults are INTERNAL_SALES_ORDER and FINAL. A retailer earning on cash bills must set the cash-bill type through the company API — there is no screen in Membership Admin or Organisation.
  • Put the earning rule on a price set, not in your head. The point amount on a bill line comes from a POINT treatment (price source, operator, value, currency, Validity Period in days) on a price set whose header rules match. A member on a bill with no point amounts earns nothing, and the document is left unmarked so a later retry can pick it up.
  • Use Single Line rules for item conditions. The counter calculator never reads the Multi Line tab, applies Doc Hdr rules as AND, and ignores Company, Member Label, Currency, Settlement Method and OCR Company header rules.
  • One price book per consuming applet. POS General, Sales Invoice, Sales Order and Sales Quotation each evaluate only the book named in their Default Selection.
  • The Commission Scheme route awards points from Level 0 only, from the first treatment, on a schedule; use it when the rule needs employee category, sales group or document-type conditions a price set cannot express.

Classes

  • Decide the class by hand and write down the rule. No processor upgrades or downgrades a class. If GOLD means “RM 5,000 in a year”, someone reviews the points report and changes the field; make that a monthly task with an owner.
  • Two or three classes. Each class that matters needs its own price set(s), voucher rules and birthday schedule; the cost of a class is the records behind it.
  • Never put tier logic on a label. Labels are for segmentation and newsletter topics.

Currencies and expiry

  • One currency unless a balance must be shown separately. A second currency is a second balance, a second PTS to CCY rate, and a second set of lots — not a different kind of expiry.
  • Every earning path must carry an end date. The POINT treatment’s Validity Period, the commission treatment’s Validity Period (Days), the adjustment form’s Valid Date To, the CSV’s validity columns. A lot without date_end never expires.
  • Schedule the three processors in the Scheduler applet: expiry elimination, expiry reminder e-mail, and zero-balance status update. None runs unless scheduled.
  • Set the PTS to CCY rate before go-live and leave it. Balances are in points; the rate is applied at redemption, so changing it changes what every outstanding point is worth.
  • Redemption at POS is a settlement or a discount line. Decide which, and configure either the points settlement method or the MEMBER_POINT_DISCOUNT item. The only cap is the POS points maximum and the balance check at FINAL.

Vouchers

  • Choose the type by what it sits on. SETTLEMENT redeems on a settlement line; PRODUCT on a product line; DISCOUNT changes the amount by its treatment; REWARDS adds points.
  • Set Voucher Limit Per Customer and Daily Limit explicitly — the defaults are 1 and 0 (unlimited).
  • Dates are rules, not gates. Put Event Date Range and Redemption Date Range on the Doc Hdr tab and schedule the expiry-checking call; redemption itself does not read the dates.
  • Recurring vouchers: one run a day. The creation processor duplicates vouchers if it runs more often.
  • Birthday gifts are a schedule you create, per class, as points (with a validity in months) or as vouchers.

What not to design for

Automatic tier progression, qualification windows, grace periods, anniversary rewards, a rewards catalogue, partner or charity redemption, a points liability posting — the product has none of them, and a programme brief that assumes them will fail at configuration time.