Member Creation
A member record is the loyalty identity: card number, name, mobile, class, labels, join and end dates, and — behind it — a customer entity that the sales documents put on the bill. Members are created in four places: the Membership Admin form, the Upload Membership CSV, the POS General member panel at the counter, and CP Commerce’s post-registration configuration. This page is for whoever enrols members: the rule to choose before the first one, the form, and how each new member finds its customer.
Before the first member
Pick the card-number rule before you key anyone, because the card number is the key every points call and every till lookup uses. Field Settings offers three switches, and turning one on turns the others off — see Applet settings:
- IC number — the card number is the IC / Passport you key, so that field becomes the one that matters.
- Mobile number — the card number is the mobile number without its
+. GadgetSphere, whose members are identified by phone at the till, uses this. - Custom running number — the screen will not let you save this switch without a starting number. The member is saved first and the number is fetched straight after.
Leave all three off and the save still works: the screen gives the member a random six-digit card number. Nobody chose that number, so nobody can quote it at the till; if it happens to clash with an existing card the save is refused and you save again.
The rule decides who can be a member. Card numbers must be unique, so under the mobile-number rule a second person on the same phone — a spouse, a child on a parent’s line — is refused with a card-number-already-exists error. Decide before go-live whether shared phones are your members' reality; if they are, use the IC rule or a running number.
Failed to generate card_no running number comes from the custom running number when its configuration row is missing — a switch set some other way than this screen, for example. By then the member already exists, with the random six-digit number.
Where to do this
Membership Admin → Member Listing → + — see
Member Create and Membership Edit.
Required: Member Name; Phone Number (one box with a country picker, required whatever the settings say);
IC / Passport when it is the card number; Membership End Date or LIFETIME. Card Type is not on this
form: set it afterwards on the member’s Details tab.
The customer record does not have to exist first
When you save a member with no customer, the backend goes looking for one in this order, and takes the first it finds:
- an entity linked to the member’s login (the Membership Admin form sends none, so this step only matters for members who register themselves);
- an entity with the same phone number;
- an entity with the same e-mail.
If nothing matches, it creates a new customer from the member’s name, IC, phone and e-mail.
What this means for you: create members from whichever end the data arrives, but keep phone numbers and e-mails clean. A shared family phone, or a branch’s own number keyed as a placeholder, attaches every new member to whoever already owns that number — and their bills go onto that customer.
Two other routes behave differently, and they matter if your data arrives by import or integration:
- The API’s with-customer route (used by an integration or a migration) matches the customer by customer code only, and copies the member’s name, IC, phone, e-mail and address onto it, overwriting what the customer record held.
- The scheduled
ENTITY_LINKING_FOR_MEMBER_PROCESSOR(in the Scheduler applet’s processor picker) does no matching. It gives every member with no customer a brand-new one, named from the part of the e-mail before the@, without the member’s name or IC. It is not a default clock, so it runs only if you schedule it — and if you do, expect customers that need their names fixed before anyone invoices them.
The other direction also exists: a customer’s Membership tab shows the plan and points, and CP Commerce post-registration can create the member, the customer, or both. Every route, and the details that decide which customer a member is matched to, are on Customer and Member → How each route attaches a member to a customer.
When it goes wrong
| Symptom | Cause | Fix |
|---|---|---|
| Failed to generate card_no running number | The custom running number is switched on but its configuration row is missing. The member was already saved, with a random six-digit card number | Field Settings → save the switch again with a Card Running Number, which creates the missing row. Members saved in the meantime keep their six-digit numbers |
| Members with six-digit card numbers nobody recognises | No card-number rule was switched on when they were created | Choose a rule in Field Settings before the next member |
| A new member’s bills land on someone else’s customer account | The phone or e-mail matched an existing entity when the member was saved | Re-point the member at the right customer; clean placeholder phone numbers out of your customer list |
| Phone number demanded for a walk-in who will not give one | The create form always requires it; NOT_MANDATORY_PHONE_NO changes only the E-Invoice tab’s buyer contact box | Register the member with a number they agree to give |
You expected branch targets on API_TNT_DM_CRM_MEMBERSHIP_CARD_HDR_READ to limit which members a user sees | They do not narrow the member listing | Control who holds the permission (Personal data and PDPA) |
| Join Date a day out | Default Timezone | Default Selection |
Read next
- Registering a Loyalty Member — the task guide that enrols a member start to finish.
- Bulk Import — loading an existing list by CSV.
- Customer and Member — why the card and the customer are two records.