Membership Admin

The back office of your loyalty programme: members and cards, tiers, point currencies and what a point is worth, manual adjustments and the membership report. Points are earned and redeemed at the counter, in POS General and Sales Invoice, and posted by the backend — this applet configures and audits them. What the screens do not say, and this page does: what one save sets off behind them, where the balance on the Details tab was written and by which job, and a thirty-second check that the card, the transaction list and the sale agree.

Overview

The Membership Admin applet is the back office of the loyalty programme. Marketing and customer-service staff use it to register members and issue cards, group them into member classes (tiers) and labels (segments), define the point currencies members collect and what a point is worth in money, correct balances with manual adjustments, look at each member’s point transactions, expiry rows, suspensions, referrals and multi-level-marketing links, upload members and point transactions from CSV, and generate the membership report. Points themselves are earned and redeemed at the counter — in POS General and Sales Invoice (Internal) — and posted by the backend; this applet configures and audits them.

Where it fits

Three situations, and what each screen shows

The same three questions come up month after month, and each is answered by knowing which record was written when. GadgetSphere Sdn Bhd, 22 branches, is the backdrop.

The shopper enrolled at the till who is not the account you bill. A walk-in at GS-KV-07 buys wireless earbuds and joins at the counter. The till does not match her to anyone quietly: it first asks the backend for customers sharing her phone or e-mail and, if any exist, shows the cashier a dialog with three choices — link to one of them, proceed anyway, cancel. Proceed, or no match at all, creates a brand-new individual customer carrying her name, IC, phone and e-mail, and the card is linked to that. Member Create on this screen behaves differently: with no customer chosen it matches silently — the signed-in login first, then the phone, then the e-mail — and creates a customer only when all three miss. So two members enrolled the same afternoon can end up with a fresh customer each (till) or on a shared office account (this screen), and the Customer Name on the Details tab is the only place that tells you which. Three weeks later she buys a laptop for the small company she runs and wants a proper e-invoice. The bill goes on the company’s trade account; her card goes in the bill’s member field. The points line takes the member from the member field and the account from the document, so she earns the points and the company gets the invoice — that is the design, not a fault. What the e-invoice reads is the customer’s identity, never the card: an IC typed on the member and blank on the company account means a TIN keyed by hand (scenario, with the mechanism).

The member whose points did not arrive. A regular at GS-PEN-02 says her balance has not moved since a 3,200-ringgit purchase last Tuesday. Open her record. The Details tab’s Current Point Balance is a stored row per member and currency, rewritten by a job after every point line; it is not computed when you look. The Point Transaction tab is the lines that job sums. If the sale is not there as a REWARD line, nothing on this applet will put it there — the points writer runs from Finalise on the sales document, and it writes a line only when the bill carried her card, the bill is the one document type and posting status the company’s MEMBER_POINT configuration names, and the line carried a point amount and currency when it was rung. A bill finalised before the cashier attached the card earns nothing, ever; the only remedy is Add Point Adjustment, keyed by someone with the permission and a reason in the remark. If the line is there and the balance still reads short, the stored row is stale — see the check below — and that is repaired by a recalculation, not by another adjustment. The order to work the links in, with one thing to look at per link, is on Membership points and vouchers: symptom, cause, fix.

A class change in the middle of the year. On 1 July the group moves its top spenders from SILVER to GOLD, and GOLD price sets carry a richer Point treatment. Nothing is recomputed. A price set’s Member Class rule is read at the moment a line is added to a bill, and the line keeps the points it got; a commission scheme’s Member Class rule is read when the scheme runs. A member upgraded on 1 July earns at the new rate from the next bill and keeps every line earned before it as it was. Two things follow for whoever runs the tier review: there is no job that promotes or demotes anyone — the class changes when a person saves it here, when an upload re-states it, or when a support data fix does — and the one record of when it changed is the Audit Trail, whose UPDATED row for the member carries the old record and the new one side by side. A member who insists she was gold in June is settled by that row, not by anyone’s memory.

Screens and menus

Route root: applet/wavelet/erp/membership/membership-admin-applet/.

This page carries no captures: every one on file showed a staff member’s photo avatar, and several showed real-looking member names, phone numbers, a developer-named branch or a brand, so all were withdrawn pending captures on a clean demo tenant.

A PTS to PTS Config route (membership-pointstopointscurrencyconversion-listing, point currency → point currency rate) exists but its menu entry is commented out.

Member Create and Membership Edit

Member Create (from + on the listing): Member Name (required), Country Code + Mobile No. (required unless the tenant setting NOT_MANDATORY_PHONE_NO is on), IC / Passport, Email, Member ID, Membership End Date (or LIFETIME), Verification Status, Card Type (when Card Types are defined), Branch and Sales Agent (when SHOW_BRANCH / SHOW_SALES_AGENT are on).

The IC / Passport you type here stays on the member. When a member is created without a customer, the screen looks for one by the signed-in login, then by phone, then by e-mail, and only when none matches creates a new individual customer carrying the member’s IC; a matched customer keeps whatever IC it already had, and no later edit of the Details tab puts the IC on it. Two edits do cross over, and you should know which: a change of name, date of birth or gender on the card is copied onto up to five individual customers sharing the card’s e-mail or phone, and onto the cards on them; and the E-Invoice tab writes its buyer name, contact, ID type and number and tax fields straight onto the linked customer. That bites at the e-invoice: the TIN lookup and the buyer block read the customer’s identity, so an IC that is on the card and blank on the customer means a TIN typed by hand on every bill. Put the identity on the customer through the E-Invoice tab or in Customer Maintenance; the one route that writes name, IC and contact onto both at once is the API’s create-with-customer call, which this screen does not use.

Membership Edit opens from a listing row. Tabs (order set under Default Selection): Details, E-Invoice, Member Photos, Labels, Point Transaction, Points Expiry, Upload Attachments, Referrals, MLM, Member Suspension.

Add Point Adjustment: Branch (required), Item Code & Name (required), Point Currency, Point Adjustment (required; positive adds, negative deducts), Transaction Date, Valid Date From / To, Reference Number, Remarks / Reason (optional — the form does not insist on a reason), Display Type (DISPLAY or HIDDEN from the member-facing history). The line is written with transaction type ADJ, the reference number as its description and the remark as its remarks; it carries no source of its own, and the applet’s ADMIN_MANUAL_POINTS_ASSIGNMENT constant is not used by this form. This call writes no Audit Trail entry: the record of who keyed it is the line’s Created By on the member’s Point Transaction tab. The balance job is queued the moment the line is saved, so the Details tab and the till show the new figure on the next read.

Classes, labels, currencies

A member belongs to one class at a time and can carry any number of labels. The class is what a price-book Member Class rule and a commission scheme’s Member Class rule read — at the moment the bill line is added, and at the moment the scheme runs; a line already written keeps its points through any later change of class, and nothing in the backend promotes or demotes a member on its own. Labels are for segmentation, and what a label does in a rule depends on who reads the rule. A price-book Member Label rule is compared with the member’s labels by the web store — on the price book’s price sets, coupons, shipping and the website’s voucher list — and by the OCR document processor. The till and the sales-document screens skip it: their price calculators treat a Member Label rule as satisfied, so a label-only price set applies to every member there (see Pricebook, Troubleshooting). The commission scheme’s Member Label rule matches any member who carries any label, whichever labels the rule names. So a label steers an online price; at the counter every member passes a label rule, and in a commission scheme any label passes it.

Uploads and report

Upload Membership saves the file and queues one import job at once; the listing shows the file’s status, never its rows, so the only feedback you get is FAILED or DONE. One blank END DATE fails the whole file; a row with no name, with neither a mobile number nor an e-mail, or with a class or label code that does not exist is skipped and the file still ends DONE. Every other row is written through the same two paths as the member form: a row whose name and mobile number exactly match a live member updates that member — class, dates, IC, e-mail, status and remarks included, and with it the name, date-of-birth and gender propagation onto customers sharing the phone or e-mail — and any other row creates a member, matching or creating a customer exactly as Member Create does. An upload writes no Audit Trail row, for the file or for the members it changed: the record is the file row’s status and the members’ updated audit fields. So before a bulk re-statement of classes, export or note the members whose class you are about to overwrite; afterwards, the Member Class screen’s member count per class is the quickest sign the file did what you meant.

Upload Member Point Transaction validates its rows on a Checking tab before anything is written; each row sets its own transaction type, so an uploaded ADJ line looks like a keyed one on the member’s Point Transaction tab (read the creator).

Membership Report queues a CSV per request and lists each export with its status and error message. What the export holds, who runs it and what it is for are on Membership reports.

Settings and Personalization menus

Configuration

Before you can use it

Applet settings

Field Settings (settings/field-settings)

The three card-number switches are mutually exclusive (turning one on clears the others).

Default Selection (settings/default-selection): DEFAULT_BRANCH, DEFAULT_LOCATION, DEFAULT_TIMEZONE (the zone the member form and Add Point Adjustment key their dates in), DEFAULT_WEBSITE_CODE (Select Website), and drag-and-drop order of the Membership Edit tabs (MEMBER_DETAILS_TAB_ORDER). Personalization → Default Selection repeats branch and location per user.

Custom Status (settings/custom-status): ENABLE_CUSTOM_STATUS_1…5, each with Header (ENABLE_CUSTOM_STATUS_HDR_n) and Line (ENABLE_CUSTOM_STATUS_LINE_n) switches, a name (NAME_CUSTOM_STATUS_HDR_n / _LINE_n) and a value list (LIST_CUSTOM_STATUS_HDR_n / _LINE_n). Header statuses 1 and 2 appear as extra status fields on the member Details tab. Custom statuses are labels only — they do not change whether a member can earn or redeem.

Card Type (settings/card-type): Card Type Code, Card Type Name, Description. When at least one exists, Card Type becomes a drop-down on the member form.

Keys in the settings model with no UI: NOT_MANDATORY_PHONE_NO (read: makes mobile number optional), department / tax ENABLE_*, PRINTABLE.

Document behaviour settings

Not applicable — no documents. Point behaviour that is fixed in the backend:

Feature visibility / permissions

API: API_TNT_DM_CRM_MEMBERSHIP_CARD_HDR_{READ,CREATE,UPDATE}; report: API_TNT_DM_ERP_REPORT_MEMBERSHIP_POINTS_REWARD_REDEMPTION_READ.

Client-side permissions registered for this applet (2): ALLOW_EDIT_MEMBERSHIP_POINTS (add point adjustments and edit Points Expiry dates when DISALLOW_EDIT_MEMBERSHIP_POINTS is on) and EDIT_MEMBERSHIP_END_DATE (edit the Membership End Date field).

Fields

Member — see Member Create / Membership Edit above. Required: Member Name; Country Code and Mobile No. (unless NOT_MANDATORY_PHONE_NO); IC / Passport when it is the card number; Card Type when card types exist; Membership End Date or LIFETIME.

Member Class: Membership Class Code, Membership Class Name (both required), Status; Labels and Members tabs; images and aliases.

Member Label: Label Code, Label Name (required), Label List. Member Label List: Label List Code, Label List Name (required); labels created inside a list carry the list code.

Point currency (PTS CCY Module): Membership Point Currency Code, Name, Conversion Rate, Point-to-point cross-over conversion, Status. PTS to CCY Config: Point Currency, Money Currency, Conversion Rate, Status. PTS to PTS Config: Point Currency (from / to), Conversion Rate, cross-over flag, Status.

Upload Membership CSV columns (Sample Format): MEMBER NAME, GENDER, DATE OF BIRTH, COUNTRY CODE, MOBILE NO., IC/PASSPORT, EMAIL, MEMBER CLASS, JOIN DATE, START DATE, END DATE, MEMBERSHIP STATUS, REMARKS, LABEL 1, LABEL 2, LABEL 3. Member class and labels must already exist by code; MEMBER NAME and MOBILE NO. together are the key that decides whether a row updates an existing member or creates one.

Upload Member Point Transaction CSV: download Sample Format → Member Point Txn on the screen for the exact header (member card number, company and branch code, point currency, points, transaction type and date, description, validity and document reference). Rows are validated on the Checking tab before import.

Membership Report: Date of Birth from / to, Start Date from / to, End Date from / to, Life Time; output is a CSV in the report queue.

Lifecycle and effects

Records are ACTIVE / INACTIVE (members can additionally be suspended for a date range and carry a Verification Status). There is no document lifecycle; what there is, and what the screen never shows, is the chain each save starts.

Member Create, on this screen. The save checks the create permission, attaches a customer (found by sign-in, phone or e-mail, else created with the member’s name, IC, phone and e-mail), refuses only an empty or duplicate card number, writes the member, and then — after the write, before you see the response — writes an Audit Trail row holding the new record, queues two webhook events for integrations (the full card and a minimal one), and queues a contact-search job that looks for contacts sharing the e-mail or phone and hands on to a second job keyed on the member. The applet fetches the running card number only after the save, which is why a missing running-number configuration leaves a saved member with a random number.

Membership Edit. The save checks the update permission for that member, reads the old record, writes the new one, and then: if the name, date of birth or gender changed, copies them onto up to five individual customers sharing the card’s e-mail or phone and onto the cards on those customers; writes an Audit Trail row holding old and new; queues the same two webhook events and the contact-search job. Deleting a member writes an Audit Trail row holding the deleted record. The E-Invoice tab is a separate save, onto the customer.

Upload Membership. One job per file, queued as the file is saved; each good row runs the create or update path above — with their customer matching, their propagation and their webhook events, but without the Audit Trail rows, which only the screen’s calls write.

Points. This applet writes no REWARD or REDEEM line. Those come from Finalise on the sales document: one primary job, a points writer subscribed per tenant, one line per eligible document line, and a balance job per line that rewrites the member’s stored balance in that currency as the sum of their active lines. The two things this applet does write — an ADJ line from Add Point Adjustment and a date change on a lot from Points Expiry — queue that same balance job, or not at all (a lot edit changes when points lapse, not how many there are now).

Suspension. Creating one moves the End Date out by the duration and saves the member through the ordinary update, so the propagation and the webhook events above run; deleting it moves the End Date back.

Check yourself in thirty seconds: three figures that must agree

Pick one member who bought something this week, and open the record.

1. Details tab — note Current Point Balance for the point currency. That is the stored row, as the balance job last left it.
2. Point Transaction tab, same currency — add up the Points column: REWARD and a positive ADJ add, REDEEM, EXPIRY and a negative ADJ take away. The sum must equal the figure on the Details tab, because the job writes the row as exactly that sum over the member’s active lines. If it does not, the stored row is stale — the three moments that produce a stale row are before an expiry run, straight after one, and after a void — and the repair is a recalculation, never an adjustment to make the numbers meet.
3. The sale — open this week’s bill in Sales Invoice (Internal) or at the till. A line that earned points shows Points Rewarded and the amount inside its item name; that amount is the REWARD line’s Points, and the line’s Source reads as the points writer’s own name. If the bill shows points and the tab has no line for it, the bill did not meet the writer’s three conditions, and the chain on the troubleshooting page says which.

Pass is three figures that agree. The disagreements do occur in practice — a small share of stored rows across the groups we can see, concentrated in a few — so the check is worth running on a member a complaint names before anyone keys an adjustment.

Who reads the Audit Trail, and when

This applet records and does not watch, and it records less than the screen names suggest. What it does record is one row per save made through a screen or the API on a member (from this screen and from the till), a class, a label, a label list, a point currency, a points-to-money rate, a suspension, an MLM link, and a point transaction header; each row carries the action, the table, and the old and new record side by side, so a question such as who changed this member’s class, and from what is answered by opening the row. What it does not record: a point adjustment keyed on Add Point Adjustment (the record of it is the line itself on the member’s Point Transaction tab — transaction type ADJ, its date, branch, item, reference and remark, and Created By — and that answers who changed this member’s points, and when, only when somebody opens it); a date change on a Points Expiry lot; a label added to or removed from a member; an upload, or any member an upload changed; and anything a job wrote — the REWARD, REDEEM and EXPIRY lines, the stored balance, the name copied onto a customer. There is no alert, no digest, no threshold and no approval step anywhere in the applet, and DISALLOW_EDIT_MEMBERSHIP_POINTS plus ALLOW_EDIT_MEMBERSHIP_POINTS decide who may adjust, never whether an adjustment was reasonable.

So the control is a standing monthly read by somebody who does not work a till: every ADJ line for the month, with its remark, its branch and its creator. The remark is optional on the form, so an adjustment with no reason is itself something to ask about. (The Upload Member Point Transaction file sets each row’s transaction type itself, so an uploaded ADJ line looks the same; read the creator, not the type alone.) The population is small — these and any uploaded files are the only points in the system a person entered. They know the month is clear when every adjustment can be matched to a complaint, a goodwill decision or a correction somebody else asked for, and when none of the HIDDEN Display Type lines is hidden for a reason they would be uncomfortable explaining. Lot dates moved on the Points Expiry tab leave no row, so the same reader looks at the lots of any member whose points should have lapsed and did not. The three frauds this is looking for are named in security and compliance.

Related applets

• MLM Admin Applet — the programs, participants, invitations and lineage behind the MLM tab; Pricebook — the Member Class rules and Point treatments that put point amounts on document lines. Point currencies and their money rates are this applet’s own PTS CCY Module and PTS to CCY Config.
• POS General, Sales Invoice (Internal) — where points are earned and redeemed, and where the till enrols a member through its own duplicate dialog.
• Customer, Organisation, Doc Item Maintenance — linked customer, company point configuration, adjustment items.
• Voucher Management, Commission Scheme, Sales Report — vouchers, MLM commissions, reward-redemption report.
• OCR Cash Bill — a third source of points: receipts a member uploads from other merchants, scored against a price book.

Troubleshooting

Related documentation

• Membership module
• Membership applets
• Membership points and vouchers: symptom, cause, fix
• The member who is not the customer