Setting Up the Programme

You set up the programme, ring up the first member’s bill, and the till shows points. Then the member’s record shows nothing: nothing failed, and nothing complained. When that happens on a new setup, the cause is nearly always outside Membership Admin. Either the company setting that decides which document awards points was never changed, or the job meant to run on a schedule was never given a clock. This page puts setup in the order a new company meets it and says who in the business decides each part. It ends with a first bill you can check in a few minutes. The pages under Configuration carry each part in detail.

Who decides what, before anyone opens a screen

The programme is three decisions made by three different people. None of them is a screen, so write them down first. Program Design walks through each one.

The programme owner (usually marketing) decides the tiers, who is in each, the earning rate per tier, and how long points live. In BigLedger the earning rate becomes a price set, the tiers become member classes, and the life of a point is set on every source that awards one. There is no single form for it.
Finance decides what a point is worth in ringgit and carries what you owe members each month. BigLedger books no liability for points (What You Owe Your Members).
Whoever runs the tills decides, for each company, which document awards points and which terminals apply the member price book. For GadgetSphere Sdn Bhd that is the cash bill at all 22 branches.

The one setting BigLedger itself has to apply for you is the company’s member-point configuration, covered below. Ask for it as soon as the third decision is made, not after the first complaint.

The order that works

Each step names something the step before it created, so work down the list.

Step	What	Where	Why here
1	Companies, branches, locations	Organisation	Members, adjustments and point transactions are branch-scoped
2	A card-number rule	Membership Admin → Field Settings	Running number, IC number or mobile number. With none of the three switched on, the applet gives the member a random six-digit card number and saves anyway, so choose the rule before the first member
3	Member classes and labels	Membership Admin	The price book’s Member Class rule and the birthday gift name them. See Member Setup
4	A points currency and a points-to-money rate	Membership Admin → PTS CCY Module, PTS to CCY Config	See Points Setup
5	The member-point configuration, once per company	Company API, set by your BigLedger contact	Which document type and posting status award points, and take them off. Defaults below
6	Where the point amounts come from	Pricebook POINT treatment, a Commission Scheme membership-points treatment, or OCR Cash Bill	See Rewards Setup
7	The counter	POS General: `SHOW_MEMBER`, a `MEMBER_POINT_DISCOUNT` item, `DEFAULT_PRICEBOOK`	Members are looked up, earn and redeem here
8	The scheduled processors	Scheduler	Expiry, the commission-scheme points run, birthday gifts. None is a default clock. Not the “expiry reminder” processor: it expires points and sends no e-mail
9	Members	Membership Admin, one at a time or by CSV	Last, because every earlier step is something a member record refers to

The setting with no screen

The backend awards points for a document only when three things are true at once:

the document header carries a member;
its document type is the one the company’s member-point configuration names;
its posting status is the one that configuration names.

Those two values live in a company-level member-point configuration that neither Membership Admin nor Organisation shows. When it has never been set the defaults are Sales Order and FINAL. A GadgetSphere branch whose members buy at the till therefore has to have the awarding document set to the cash bill through the company API, so ask your BigLedger contact. Until then its bills will never earn a point, and nothing on any screen will say why.

Four things about that setting that a programme brief usually gets wrong:

It is per company, not per group. The backend reads it from the company on the document, so GS, GSO and GSD each need their own. Setting it for GS does nothing for the online arm.
It names one document type. A company that sells both at the till and on sales invoices has to choose which one earns. Points on the other kind of document stay on the bill line and never reach the member.
The same pair decides when points are taken off. A redemption is written to the member by the same job that writes the earnings, on the same document type and status. At FINAL the backend checks a points-discount line against the member’s balance on a cash bill or sales invoice, whatever the setting says. So on a company still at the default, a member can spend the points you gave them by adjustment or import, and their balance never goes down. Check this before you load opening balances.
The record has a second pair, for “out” documents, and nothing reads it. An integrator who fills it in expecting it to govern redemptions has changed nothing.

The job that writes points after FINAL is a follow-on job that a new tenant is subscribed to by default. No screen shows the subscription. If the type and status are right and the bills still earn nothing, that subscription is the next thing to ask BigLedger about.

What depends on what

What must exist first. A point amount on a bill line depends on four things: a price set with a Point treatment, a terminal whose DEFAULT_PRICEBOOK names that book, a point currency, and a member on the bill. Whether that amount then reaches the member depends on the member-point configuration. Whether it ever expires depends on a clock in the Scheduler. Each comes from a different applet, and each fails silently on its own.

What becomes possible once it is set. The same member classes that price the bill also target vouchers and choose who gets the birthday gift. One set of classes serves all three, with nothing built twice. See Rewards Setup.

Which source of points to use. Use a price set with a Member Class rule for points every member of a tier earns on every bill, worked out at the till. Use a commission scheme when the rule needs something a price set does not have, such as a sales-agent category, a customer type or a date range; it awards in a scheduled run rather than at the till. Use OCR Cash Bill only for receipts from other merchants that a member photographs.

What breaks elsewhere when one is wrong.

Wrong setting	Who notices, and where
The member-point configuration, for one company	Every branch of that company: bills show points, members get none, and on the default redemptions are never taken off
One terminal’s `DEFAULT_PRICEBOOK`	That terminal only: member prices and member points stop together, because they live in the same price sets
No clock for the expiry run	Nobody at first: points never expire, the till keeps offering them, and the figure finance carries for unexpired points keeps growing
A price set with a Point treatment and no Member Class rule	Invoices and any line the server fills in: it awards at the till and zero on the server’s pass

What it is used alongside. A member is usually linked to a customer record. The e-invoice reads the customer, not the member, and a staff card linked to a company account puts that member’s birthday voucher on the company (the member who is not the customer).

Where the numbers in your first check come from

The points on the bill line are worked out when the line is added, and stored on the line. Changing the price book afterwards leaves a bill already rung as it was.
The member’s REWARD line is written by the follow-on job a moment after FINAL, not by the FINAL itself. It is written only on the configured type and status.
The balance the till shows is a stored running total per member and currency, not recalculated from the member’s lots. It departs from the lots at three moments, named on Points Setup.

What is not configurable, because it does not exist

Each absence below is somebody’s job instead. Program Design has the full list, with who, when, and how they know it worked.

No automatic tier upgrade. A member class is assigned by hand (or by CSV). No processor moves a member between classes on spend, visits or time. The programme owner reviews tiers on a date in the diary, changes the class, and checks that the class counts moved by the promotions approved.
No expiry rule screen. Each point lot carries its own validity dates; a scheduled processor expires the lots whose end date has passed. Whoever administers the tenant creates the clock at go-live. The day after its first run, they look for an EXPIRY line on a member whose lot had ended. See Expiry Rules.
No ledger posting. The membership point document types carry no amount and no quantity, and the journal posting engine has no entry for them. Points are not a liability account in BigLedger. Finance books the liability by manual journal each month-end (What You Owe Your Members).
No pricing scheme per member class. Member pricing is a price book rule, not a pricing-scheme link. See Rewards Setup.

When it goes wrong

Symptom	Cause	Fix
The bill showed points; the member’s Point Transaction tab has nothing	The bill is not the type, or not at the status, that company’s member-point configuration names	Ask your BigLedger contact to set it for that company; then check the next bill
One company’s members earn and another company’s do not	The configuration was set for one company only	Set it for each company that sells to members
Members spend points at the till and their balance does not drop	The company is still on the default, so no `REDEEM` line is written	Set the configuration to the cash bill; take the spent points off with a negative Add Point Adjustment per member
Type and status are right, and bills still earn nothing	The tenant is not subscribed to the follow-on points job	Ask BigLedger to check the subscription; no screen shows it
Points past their end date are still spendable	No `ACTIVE` clock for the expiry run	Create one in the Scheduler (Expiry Rules)
Gold prices and points stop at one terminal	That terminal’s `DEFAULT_PRICEBOOK` names another book	POS General → Default Selection on that terminal
Card numbers look random, and not like the IC or phone numbers you expected	No card-number rule was chosen before members were created	Member Creation

A member who says their points are missing gets the walk-the-chain procedure before anybody adjusts anything.

What success looks like

Create one member at GS-KV-01 with class STANDARD; confirm a card number was assigned.
Use Add Point Adjustment to post +100 GSPTS with a Valid Date To a year out; check the Point Transaction and Points Expiry tabs.
At a POS terminal with SHOW_MEMBER on, ring up a bill for that member. If the company’s awarding document is the cash bill, a REWARD line appears after FINAL; if not, nothing does.
Redeem 50 points on a second bill. The bill shows the points settlement or the points-discount line, and the member’s Point Transaction tab shows a REDEEM line. If the line is missing, the balance has not really dropped. Go back to the configuration before any member spends a point.
Void the second bill and look again: the 50 points are not returned. A void does not reverse points in either direction; post a Point Adjustment to give them back.
In the Scheduler, the expiry processor has a row reading ACTIVE.