Points Setup

Setting up points is four decisions in Membership Admin and two that are made somewhere else — and the two made elsewhere are the ones behind “the bill showed points and the member has none”. Membership Admin holds what a point is called, what it is worth and how long it lives. How many points a bill earns is set in the price book, and whether those points ever reach the member is decided by one company-level record that no Membership Admin screen shows. This page walks the chain from the line on the bill to the balance at the till, says who in the business owns each decision, and gives you a thirty-second test for the first bill.

Agree the earn rate and the point’s value in the same meeting. They multiply out to the price of the programme, and they are set in two different applets, often by two different people. At GadgetSphere, one GSPTS for every RM 1 spent and 100 GSPTS to RM 1 gives back 1 % of every member sale. Double the earn rate on accessories in the price book and that line gives back 2 %, whatever the rate row in Membership Admin says.

Where the points on a bill come from

A point is a transaction line: a member, a currency, a signed value, a validity window and a source (a document line, an adjustment, an import, a commission run, a scanned receipt, an expiry). A bill’s points pass through three stages before the member can spend them, and each stage can stop them without an error on the bill.

Something puts a number on the line

Membership Admin holds the currency and the rate, but not the earning rate. The number of points on a document line is put there by one of three things:

1. a Pricebook price set with a Point treatment, evaluated by POS General or the sales document applet when the line is added (DEFAULT_PRICEBOOK, PRICEBOOK_POINTS_AUTO_APPLY). With PRICEBOOK_POINTS_AUTO_APPLY on, the server also fills in points on a saved cash bill or sales invoice for lines that arrived with none — and that pass, unlike the till, ignores a price set with no Member Class rule (Pricebook Configuration);
2. the scheduled Commission Scheme membership-points run, which reads a scheme’s Membership Points treatment and Validity Period (Days);
3. the OCR Cash Bill processor, which evaluates a price book against a receipt the member photographed.

The points the cashier sees on the bill are this number, stored on the line. They are not yet the member’s.

A job after Finalise turns the line into the member’s points

Finalising a document starts a chain of follow-on jobs, and one of them writes the member’s point lines. It turns each line that has both a point amount and a point currency into a transaction line — REWARD when positive, REDEEM when negative — with the line’s point start and end dates as the lot’s validity. It does that only when three things hold:

• the bill has a member on it;
• the document is the type the company’s MEMBER_POINT configuration names, and
• it is at the posting status that configuration names.

That configuration defaults to INTERNAL_SALES_ORDER at FINAL and has no screen (see the Organisation page); it is set through the company API. A company that sells at the till and leaves the default earns nothing from its cash bills: the till shows points on every line, and no point line is ever written. Where companies have changed the record, they have almost always pointed it at the cash bill at FINAL.

The record belongs to one company, not the tenant. That is what lets a group award on the document each arm actually completes: GadgetSphere Sdn Bhd (GS) on the cash bill its 22 tills finalise, and GadgetSphere Online (GSO) on the sales order its web store raises. It names one type, so a single company that sells both ways has to choose which one awards.

A company can delay the award instead. A company setting holds the points back a set number of days after Finalise — long enough, say, for a 14-day return window to close — and then applies the same type-and-status test. A bill voided inside the window is no longer at FINAL when the test runs, so it never awards and there is nothing to claw back. Points that arrive this way are written as adjustment lines with no end date, so they never expire, and none of the applets we searched sets the number of days: it is a request to BigLedger support, and very few companies use it.

The job runs only where your tenant subscribes it. Which follow-on jobs a Finalise starts is your tenant’s trigger configuration, which none of the applets we searched edits. If a test bill passes every check on this page and still writes no point line, ask BigLedger support to confirm the points job is subscribed for your tenant.

Correcting the record later does not reach bills already finalised. The job tests the document once, when it is finalised, and a FINAL document cannot be taken back to draft to run it again. The backend has a repair that re-awards, for one company, every member document that has points on its lines and no point lines yet — the documents that now match the corrected record are awarded, back to the first one. It has no button in any applet, so it is a request to BigLedger support. Before you ask, decide with finance whether every one of those old bills should award: a year of cash bills arriving in a single run moves every member’s balance at once, and the points arrive with the validity dates their lines carried, some of them already past.

A stored running total is what the till offers

The balance a cashier sees is not added up from the lots at the moment of the sale: it is a stored running total, one per member and currency, added to as each point line is written, and the till turns it into the cash value it offers for redemption at the rate row. Most of the time it equals the sum of the member’s unexpired lots. It differs at three moments:

• A lot has passed its end date and the expiry run has not come yet. A member holding 4,000 points, 1,200 of them in a lot that ended on 31 March, still shows 4,000 after that date. The till offers all of it until the scheduled elimination run writes the expiry line — and if that run is not scheduled, it never does.
• The expiry run has just been. Writing an expiry line sets the stored total to zero, not to 4,000 less 1,200. A rebuild queued straight afterwards restores 2,800 from the transaction lines; until it lands — or for good, if it is lost — the member shows 0.
• A bill that earned points has been voided. Where your company’s void is set up to handle points, it removes that bill’s lots, but it takes nothing off the stored total, so the till goes on showing the voided points. Nothing corrects this later: the bill’s point lines stay on the member’s record, and every rebuild counts them. Void a bill that earned 500 points and the till still offers those 500 next month.

A supervisor spots all three the same way: add up the points the member’s lots still hold — the remaining points on each lot from the lot query in the membership API — and compare the figure with the till. Do not add up the member’s Points Expiry tab for this: its Balance Amount column shows each lot’s original points, so a lot the member has partly spent counts in full there and the till looks short when it is not. Higher at the till means a lot past its end date or a voided bill; zero at the till against live lots means the rebuild after an expiry did not land, and the recalculation in Membership Admin puts it right. The recalculation does not fix a voided bill: it rebuilds the lots from the member’s point lines, the voided bill’s lines among them, so the two figures agree again with the voided points in both.

What a void does not do. It does not give back points a bill redeemed: void a bill that paid with 300 points and the member stays 300 down, at the till and in the lots. To return them, post a positive Add Point Adjustment on the member. To take back points a voided bill earned, a negative adjustment brings the till figure right, but if the void has already removed the bill’s lots it also draws the same points from the member’s other lots, so the lots then hold too little. Compare the two figures after any adjustment. In one narrow case, when the bill’s points were partly spent and the member holds less than half of what it earned, the void writes an automatic adjustment and the till shows zero until the member’s next transaction. After that transaction the balance comes back higher than before the void. Walk the chain before you adjust anything.

How points fit with the rest of membership

• What must exist first. A point currency and its rate row; a price book whose price sets carry a Point treatment and name a member class (the server’s fill-in skips a price set that names none); that book as DEFAULT_PRICEBOOK on every terminal that should award; the MEMBER_POINT record pointed at the document your branches finalise; and, for expiry, a clock in the Scheduler for the expiry run. Miss the price book and the line carries no points; miss the record and the line’s points never reach the member; miss the clock and lots past their end date stay spendable.
• What it makes possible. Spending at the till (Cash Conversion), birthday points (Rewards Setup), and the month-end liability figure finance builds from the balances (What You Owe Your Members).
• The sibling, and when to choose it. Points reward every member of a class on every bill and are spent like money; a voucher is the reward for one member or one campaign. Within points, a price set awards on the bill as it is rung up, while the commission scheme run awards later, by rules a price set has no place for — a sales agent’s category, a customer type, a date range.
• What breaks elsewhere when it is wrong. The MEMBER_POINT record is read by the job after Finalise, by the commission scheme points run and by the delayed award, so changing it moves all three at once — repoint it at the cash bill and the commission run starts counting cash bills too. A terminal whose DEFAULT_PRICEBOOK is switched to a weekend promotion book stops awarding tier points for the weekend, because prices and points live in the same price sets.
• What it pairs with in practice. POS General: points earned on bills and spent at the till are by far the commonest reward in use.

How you know the first bill worked, before the branches go live

Thirty seconds, once per company, before the programme reaches all 22 branches — and again after anyone touches the price book or the MEMBER_POINT record. It belongs to whoever configured the tenant, with the person who agreed the earn rate beside them.

1. At GS-KV-01, ring up one accessory for a test member and look at the line’s points before you take payment. A RM 100 accessory at one point per ringgit should show 100. A different number is the price book, not membership.
2. Finalise the bill. In Membership Admin, open the test member’s Point Transaction tab: a REWARD line for 100, dated today, should appear a moment after Finalise, because the job runs once Finalise has returned. If it is not, the MEMBER_POINT record is the first suspect, the points job the second.
3. On the member’s Details tab, the current point balance has gone up by 100, and the Points Expiry tab lists a new lot of 100 for the bill. That tab’s Balance Amount is each lot’s original points, not what is left of it, so add it up against the till only while none of the test member’s points have been spent or deducted; otherwise compare the till with the lots’ remaining points as above.
4. Back at the till, call the member up: the cash value offered for 100 points is RM 1.00 at 100 GSPTS to RM 1.

On a company that delays the award, step 2 comes the agreed number of days later, as an adjustment line rather than a REWARD. Write the four figures down with the date; the next time anyone asks whether points were ever working, that note is the answer.

When it goes wrong

What points are not

They are not a ledger entry. INTERNAL_MEMBERSHIP_POINT_REWARD and INTERNAL_MEMBERSHIP_POINT_REDEEM carry amount and quantity signum 0 and have no journal rule. The previous version of this section described journal entries on issue and redemption and a breakage recognition step; none of that exists. The only ledger effect of a redemption is whatever the cash bill itself posts — the points settlement or the points-discount line on the bill — which belongs to POS General.

So the points you owe your members appear in no account until somebody puts them there. That is a month-end job for whoever signs the management accounts: take the balances, value them at the redemption rate, allow for the share that will never be spent, and post the movement by journal. What You Owe Your Members is that procedure, step by step.

Read next

Currency Configuration is the first decision, and everything else on this page names the currency it creates. When a member says their points are missing, go to Membership points and vouchers — troubleshooting instead.