Conversion Rates

The conversion rate says what a point is worth in money — for GadgetSphere, 100 GSPTS = RM 1.00.

Which of the counter’s two point screens reads it is not the same answer, and it decides what your members actually get. POS General has two:

• The member-points settlement panel, beside cash and card, converts in both directions at the rate you set here (the settlement-adjustment screen uses the same arithmetic). Set 50 points = RM 1 and that is what the member gets.
• The separate Add Point Discount screen does not. It looks your rate up and then converts at a hard-coded 100 points to RM 1, in steps of 100, capped at the whole bill — the rate it fetched is worked out and then discarded.

So a tenant on any rate other than 100:1 gives two different answers on the same bill depending on which button the cashier presses, and nothing on either screen says so. Until that is fixed, either set the rate to 100:1 or redeem only through the settlement panel — and if you use the discount line, tell your cashiers which button is the one the programme was priced for.

Where to do this

Membership Admin → PTS to CCY Config → + — see Classes, labels, currencies: Point Currency, Money Currency, Conversion Rate, Status. One active row per point currency and money currency.

Point-to-point. A PTS to PTS Config screen (point currency → point currency, rate, cross-over flag) exists in the applet’s routes, but its menu entry is commented out; you cannot reach it from the sidebar. The PTS CCY Module row carries the cross-over flag, and nothing on the menu lets you set the rate between two currencies. Treat multi-currency conversion as unavailable until the menu returns.

Agree the rate once, with the person who signs off margin

• Get the rate agreed before the row exists, and leave it. This number and the earn rate together are the price of the programme — they multiply out to a permanent discount on every sale, and program design shows the arithmetic. It is a decision for whoever carries gross margin, not for whoever has the applet open.
• Round it so a cashier can say it in one sentence. “100 points is one ringgit” survives a busy Saturday at GS-KV-01; “847 points is ten ringgit” does not.
• Keep one rate row per point currency. The rate row names a money currency, but the till does not compare it with the bill: it loads every row and uses the first one for the point currency. Add a USD row for GSPTS beside the MYR one and a ringgit bill may convert at the dollar rate — which row wins depends on the order the rows come back, not on the bill.

What you owe members if you change it later

Changing this row changes what every point already earned is worth, instantly and silently. No report restates history, no member is notified, and nothing records that the rate ever moved — so if a member redeems the day after a cut, they get less for points they earned under the old promise and there is nothing on any screen to explain it.

The product has no position on this, so the business must have one before the change is made. There are two defensible answers and you pick one:

• Honour the old rate for points already earned. That means announcing a cut-off date, letting members spend at the old rate until it, and accepting the redemption spike in between. The outstanding balance at the old rate is what that costs, and finance can price it before you commit — …/membership-points-txn/current-balance/query.
• Apply the new rate to everything. Cheaper and faster, and it is a change to a published promise. Whether you may do it at all is a question about the terms you wrote (see program design), not about this screen.

Who and when: the programme owner decides, finance prices it, and both happen before the row is edited — the notice period you give members should already be written into the terms. You know it was handled properly if, on the day of the change, a cashier can tell a member what happened to their balance without ringing head office.

When it goes wrong