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.

Where to do this

Membership Admin → Member Listing → + — see Member Create and Membership Edit. 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.

Before the first member

A card-number rule must be on, or the save fails with Failed to generate card_no running number. Field Settings offers three mutually exclusive switches — a custom running number, the IC number, or the mobile number — see Applet settings. GadgetSphere, whose members are identified by phone at the till, uses the mobile number.

The customer record does not have to exist first

The previous version of this page said the customer must be created in Core before the member. It need not. When a member is created without an entity_hdr_guid, the backend looks for an entity linked to the same login, then one with the same phone, then one with the same e-mail, and creates a new entity if none matches (MemberCardService.matchMembershipToEntity, L79–L99, called from createMembercard L110–L113). A scheduled ENTITY_LINKING_FOR_MEMBER_PROCESSOR does the same for older members whose entity is null. 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.

What this means for you: create members from whichever end the data arrives, but keep phone numbers and e-mails clean — a wrong phone matches the wrong entity, and the bill goes onto that customer.

When it goes wrong