| Abbreviation | Description |
|---|---|
| EPC | Emirates Platinum Card — the receiving platform |
| LEGACY | The legacy Platinum programme platform — the providing system |
| PII | Personally Identifiable Information |
| DDS | Direct Deduction from Salary |
| HRMS | Human Resource Management System |
| BG_ID | HRMS Business Group Identifier |
| SSO | Single Sign-On |
| AED | United Arab Emirates Dirham |
| VAT | Value Added Tax |
| DPO | Data Protection Officer |
| ICD | Interface Control Document |
| M / O / C | Mandatory / Optional / Conditional |
| TBD | To be determined — registered in section 6.2 |
A one-time bulk file interface transferring member, family, partner, location and benefit data from the legacy Platinum platform into EPC, so that existing members keep their identity and their registered dependants, and the benefit catalogue is populated at cut-over, without re-registration.
EPC operates the Emirates Platinum Card membership programme: employee and dependant enrolment, tiered memberships, partner offers and venue access, and the collection of membership fees by salary deduction. The programme is presently operated on the legacy platform, which is to be decommissioned.
This interface transfers the legacy programme's operational data into EPC so that existing members retain their identity and their registered dependants, and the benefit catalogue is carried across in full, without re-registration. Whether each member's current membership term is migrated with them is open item 1; EPC recommends that it is not.
To define unambiguously, for the Emirates technical team operating the legacy platform:
idPhoto. No photograph files are delivered; see open item 8.| Risk | Mitigation |
|---|---|
| Migrating membership terms carries the largest financial exposure in the programme. Every EPC money operation — refund, renewal and general ledger extract — computes from collection history, and no per-month deduction record appears in the legacy field inventory available to EPC. A member part-way through a salary deduction cycle at cut-over is therefore deducted a second time for months already collected, unless EPC is told how much of the term remains. | Open item 1. EPC's recommendation is that membership terms are not migrated. Identities, registered dependants and the benefit catalogue carry across in full and members enrol on the current EPC cycle, which leaves no money-bearing state resting on history that cannot be reconstructed. Where Emirates prefers to migrate terms, EPC collects only the installments outstanding between cut-over and the term end date, computed from membershipStart, membershipEnd, membershipFee and membershipPaymentPeriod. No collection history is required: EPC's ledger begins at cut-over, nothing already collected is collected again, and money taken before cut-over remains accounted for on the legacy side. |
membershipPaymentType conveys the fee arrangement only and carries no instrument data.Record data is delivered by file. Emirates extracts five sheets and five mapping tables, and where membership terms are migrated a sixth sheet with two further mapping tables, from the legacy platform and delivers them to the agreed transfer location. Identity photographs are not delivered: EPC retrieves each one from the legacy image API. EPC validates the delivery in four stages, loads accepted records, and returns a rejection report naming every refused record by its own key and the field at fault.
No response file is produced. The legacy image API referenced by member.idPhoto is the only legacy interface this migration calls, and its endpoint and credentials are open item 8; no interface is exposed for bulk extraction of the record data, which is why that part of the delivery is by file. The interface is not incremental: each delivery is a complete extract, keyed on the legacy keys so that a redelivery updates previously loaded records rather than duplicating them.
Existing members retain their name, contact details, employing company, grade and registered dependants, and sign in to EPC without re-enrolment.
Conditional on open item 1, and EPC does not recommend it. Where membership terms are migrated, each term is carried across on the membership sheet of section 4.4.3 with its level, dates and fee arrangement, so entitlement is uninterrupted at cut-over and renewal proceeds on the EPC renewal cycle. Where they are not, migrated members hold no term at cut-over and enrol on the current EPC cycle; the treatment of an unexpired legacy term is settled under that open item either way.
Where open item 1 is closed in favour of migrating terms, salary deduction resumes for the installments outstanding at cut-over rather than restarting the term. A term already paid in full carries no outstanding installments and EPC collects nothing further for it.
EPC's collection record begins at cut-over. A refund EPC computes therefore covers only what EPC itself collected; any portion collected by the legacy platform before cut-over is settled by Emirates outside EPC.
Partners, their locations and their published benefits are carried across so the member-facing catalogue is populated at cut-over, including partner imagery and per-location scoping.
Monetary fields are delivered as integer minor units, that is fils. AED 250.00 is delivered as 25000, never as 250. A value left in dirhams is a well-formed integer and cannot be identified as wrong on receipt, so the conversion belongs in the extract. Decimal separators, thousands separators and currency symbols are not accepted and reject the record.
The fields concerned are membership.membershipFee and offer.price.
Dates are ISO 8601. Date-only fields carry no time component and are delivered as YYYY-MM-DD. Timestamp fields are delivered as YYYY-MM-DDThh:mm:ssZ. Payroll periods are delivered as YYYY-MM.
An empty field means that no value is held. It must not be populated with 0, -, N/A, NULL, NA, none or a repetition of the preceding row. EPC applies no substitute value to an empty optional field.
One field inverts this convention and is documented individually: offer.locationIds, where empty denotes all locations of the partner.
EPC stores member types, member sub types and benefit categories as configured references, not as free text. Legacy coded values must therefore be resolved to EPC configuration.
No mapping is inferred. A legacy code with no entry in the corresponding mapping table rejects the record; it is not resolved to a default, a nearest match or a catch-all category. This is deliberate: an incorrectly resolved grade or member type changes a member's entitlement without raising an error anywhere in EPC.
The mapping tables are defined in section 4.4.8. Every distinct value present in the delivered data must appear in them. For grades the requirement is wider: Emirates supplies the complete list of legacy grade values, whether or not each is in current use, so that a value first seen after cut-over resolves rather than failing.
Fields carrying more than one value — keywords, categoryIds, subcategoryIds, locationIds, images, additionalImages, socialLinks and hrmsValue — accept either separator. Comma separation requires the field to be enclosed in double quotes per RFC 4180; semicolon separation requires no quoting.
Every delivered record carries its key — employeeId on the member, family member and membership sheets, id on the partner, location and benefit sheets. EPC retains these in an identifier crosswalk (section 5.4) and quotes them in all rejection reporting. EPC issues its own internal identifiers and does not expose legacy keys on its records.
Two human-facing identifier series are format-constrained in EPC. The membership number is exactly ten numeric digits and the benefit number exactly eight. offer.id is numeric on the legacy platform and is preserved as the benefit number where it conforms and is unique; see open item 4. The membership number is issued by EPC to every migrated member from its own ten-digit series. It is an EPC-facing number and no legacy equivalent is delivered or preserved: the identifiers that join a migrated record to Emirates systems are employeeId for a primary member and dependantId for a dependant, both of which are HRMS identifiers.
Column order within a delivered file is not significant. Column header text must equal the field name given in section 4.4.
| Column | Meaning |
|---|---|
| Field | Field name as delivered, and the column header text expected in the file |
| Type | Data type. String(n) denotes a maximum length of n characters; values exceeding it reject the record and are never truncated |
| Req | M Mandatory, always present · O Optional, may be empty · C Conditional, mandatory in the circumstances stated in the description |
| PII | Y where the field carries personal data, N otherwise |
| Description | Meaning of the field, permitted values, conditional rule, and the EPC field it populates. Not loaded marks a field EPC accepts but does not consume |
Fields of other sheets are referenced in dotted form, for example partner.id. An unqualified field name refers to the sheet under discussion.
Six sheets are delivered, comprising 117 fields, together with seven mapping tables comprising 20 fields. The membership sheet and the membership type and payment period mapping tables are conditional on open item 1, and EPC does not recommend that they are delivered.
Minimum delivery. EPC cannot create a record without the fields marked M. Forty-two fields across the six sheets carry that marking, and they are the whole of what a delivery must contain:
| Sheet | Fields EPC cannot load without | Count |
|---|---|---|
member |
employeeId, email, name, surname, gender, grade, employmentType, companyId, memberStatus |
9 |
membership |
employeeId, membershipType, membershipStart, membershipEnd, membershipPaymentType, membershipPaymentPeriod |
6 |
family_member |
employeeId, dependantId, relation, name, surname |
5 |
partner |
id, brandName, logo, address, country, city |
6 |
partner_location |
id, partnerId, status, address, coordinateLat, coordinateLong, name |
7 |
offer |
id, partnerId, status, offerType, startDate, shortDescription, title, description, categoryIds |
9 |
Every other field is migrated where Emirates holds it and omitted where it does not. EPC loads what is provided and refuses no record for an absent optional field, so a field that the legacy platform cannot supply need not delay the delivery.
Fields marked C are mandatory only in the circumstances stated against them, such as dependantType on a dependant record or price on a fixed-price benefit. One mandatory field has no legacy source: partner_location.name, for which section 4.4.6 gives a construction rule.
| Sheet | Grain | Fields | Depends on |
|---|---|---|---|
partner |
one record per partner | 29 | Programme configuration |
partner_location |
one record per partner branch | 12 | partner |
offer |
one record per benefit | 27 | partner, partner_location, benefit categories |
member |
one record per enrolled person | 31 | Mapping tables, companies |
family_member |
one record per family member of a primary | 9 | member |
membership |
one record per membership term | 9 | member, open item 1 |
| Total | — | 117 | — |
Sheets are loaded in the order listed above, which is determined by referential dependency. Family member records are loaded with their primary member, so that family linkage is established in a single operation.
Grain: one record per enrolled person. Primary members (employees) and dependants share this sheet.
Primary key: employeeId, or employeeId and dependantId in combination for a dependant.
Distinguishing rule: records carrying dependantId and dependantType are dependants; records without them are primary members.
| Field | Type | Req | PII | Description |
|---|---|---|---|---|
| employeeId | String(64) | M | Y | Employee number, as staffId in the legacy platform. Primary key of this sheet and the join key to every other sheet. On a primary member record it populates staffId. On a dependant record it is the join key to the primary member only and is not loaded onto the dependant: EPC holds staffId on primary members alone, unique programme-wide, and links the dependant to its primary by the internal reference derived in section 4.6. |
| String(254) | M | Y | Email address. Unique across the sheet and programme-wide, and lower-cased on load. This field is the EPC login identity and also determines the login method derived in section 4.6. It is mandatory on every row of this sheet, dependants included, because a dependant holding their own membership signs in to EPC in their own right. A dependant with no address of their own, or sharing the address of their primary member, cannot be created: the first rejects E-REQ and the second E-DUP, and because siblings commonly share one address a family arrives part-migrated. This is expected to be the largest single source of rejections in the load; see open item 11. Populates email. |
|
| name | String(100) | M | Y | Given name. Populates name. |
| surname | String(100) | M | Y | Family name. Mandatory even where the legacy platform holds a single combined name; EPC has no combined name field. Populates surname. |
| grade | String(32) | M | N | Employment grade, as equilentGrade in the legacy platform. Resolved through the grade mapping table of section 4.4.8 to the EPC core grade. Values beginning CC. additionally confer cabin crew entitlement; see section 4.6. Populates grade. |
| employmentType | String(64) | M | N | Employment type; see 4.5.2. Resolved through the employment type mapping table of section 4.4.8. An unresolved value rejects the record. Populates memberType. |
| companyId | String(64) | M | N | Employing company, delivered as its HRMS BG_ID, which is the value the legacy platform holds in this field. A company HRMS does not transmit, such as an associated company, has no BG_ID; for its members deliver the EPC company code from the register instead. See 4.5.10. Determines HRMS ownership and SSO availability; see section 4.6. Populates company.id. |
| memberStatus | Enum | M | N | Whether the person is an active member of the legacy programme; see 4.5.5. The legacy platform holds this as membershipStatus, sourced from isActive; it is renamed here because it is the state of the member and not of a membership. Input to the member status derivation of section 4.6. Not loaded directly. |
| gender | Enum | M | Y | male or female. Mandatory for every member, dependants included. It does not appear in the legacy field inventory available to EPC, so Emirates is asked to confirm before delivery that it is held for the whole member population — where it is not, every record rejects rather than some. Populates gender. |
| dependantId | String(64) | C | N | HRMS person identifier of the dependant, as serial_number in the legacy platform. Mandatory on dependant records. Ties this membership to the corresponding family_member entry, and is the identifier by which HRMS recognises the dependant thereafter. Populates dependantId and hrmsFamilyMemberId. |
| idPhoto | String(128) | C | Y | Identity photograph reference. Mandatory where a photograph is held. The value by which the legacy image API returns the photograph, whether an identifier or a path; its form is confirmed under open item 8. EPC retrieves the image rather than receiving it as a file. Determines the photograph review status derived in section 4.6. Populates idPhoto. |
| birthdate | Date | C | Y | Date of birth. Mandatory for dependants, where it determines age eligibility. Requested for primary members: with hrJoiningDate it is the sole input to the EPC alumni classification. Populates birthdate. |
| dependantType | String(64) | C | Y | Relation of the dependant to the primary member, as relation in the legacy platform; see 4.5.3. Mandatory on dependant records. Resolved through the relation mapping table of section 4.4.8. Populates relation and memberSubType, which is the field EPC eligibility rules are evaluated on. |
| maritalStatus | Enum | C | Y | single or married. Primary members only; ignored on dependant records. Mandatory on a primary member who has a dependant or family member whose relation classifies as spouse: EPC refuses to create a spouse record against a member not recorded as married, so an absent value rejects the spouse rather than the primary. Optional otherwise. Populates maritalStatus. |
| oldEmployeeId | String(64) | O | Y | Superseded employee number, as oldStaffId in the legacy platform. Where more than one is held, deliver them separated per 4.3.5. Populates previousStaffIds. |
| middleName | String(100) | O | Y | Middle name. Populates middleName. |
| phone | String(20) | O | Y | Mobile number. E.164 including country code is preferred; Populates phone. |
| isCabinCrew | Boolean | O | N | Whether the member is cabin crew, according to grade. Not loaded — EPC evaluates cabin crew entitlement from grade at rule execution time and stores no flag. Retained for reconciliation against the grade mapping table. |
| addressCountry | String(2) | O | Y | ISO 3166-1 alpha-2 country code of the residential address. Populates address.country. |
| address | String(255) | O | Y | Residential address, street lines only. Country is carried in addressCountry. Populates address.address. |
| createdAt | DateTime | O | N | Original record creation, as memberCreationDatetime in the legacy platform. Where empty, the load timestamp is recorded. Populates createdAt. |
| updatedAt | DateTime | O | N | Last change, as updatedDatetime in the legacy platform. Populates updatedAt. |
| department | String(120) | O | N | Department as held by the legacy platform. Populates department. |
| workAddress | String(255) | O | N | Work location. Populates workAddress. |
| hrJoiningDate | Date | O | Y | Employment start date as held by HRMS. Requested for primary members: no EPC field allows it to be derived, and alumni classification depends on it. Populates hrmsJoiningDate. |
| isRetiree | Boolean | O | Y | true where the person is a retired employee. Distinct from employmentType value Retire, which conveys the same fact where this field is not held. Populates isRetiree. |
| leavingReason | String(255) | O | Y | Reason for leaving, where held. Populates leavingReason. |
| lastDayOfService | Date | O | Y | Final day of service, where held. Populates lastDayOfService. |
| prefEmail | Boolean | O | N | The member's email notification preference. Where empty, EPC applies its own default of enabled; see open item 9. Populates permissions.email. |
| prefSms | Boolean | O | N | The member's SMS notification preference, on the same basis as prefEmail. Populates permissions.sms. |
| note | String(2000) | O | Y | Administrative note, visible to EPC administrators. Free text, which EPC does not validate. Populates note. |
Membership terms are not carried on this sheet. A member may hold more than one membership, so terms are delivered on the membership sheet of section 4.4.3, one record per term. That sheet is delivered only where membership terms are migrated, which is open item 1, and EPC does not recommend that they are.
EPC does not recommend migrating membership terms. Every EPC money operation computes from collection history, none of which exists in EPC for a legacy term, so the sound course is to carry identities, registered dependants and the benefit catalogue and let members enrol on the current EPC cycle. This sheet exists for the case where Emirates elects otherwise, and is delivered only then. The decision, and the treatment of an unexpired legacy term under either course, is open item 1.
Where terms are migrated, EPC collects only the installments outstanding between cut-over and the term end date, computed per section 4.6. No collection history is delivered, nothing already collected is collected again, and any refund EPC computes covers only money EPC itself collected; the pre-cut-over portion remains a legacy matter.
Grain: one record per membership term. A member may hold more than one, so this sheet is not one row per member.
Primary key: employeeId, dependantId and membershipStart in combination.
Conditionality: delivered only where open item 1 is closed in favour of migrating terms. Terms that have ended or lapsed are not delivered, there being no entitlement or collection to carry; see section 6.1.
Field names: the date, fee and arrangement fields keep the names under which they were published on the member sheet, so that each maps one to one from the legacy field inventory; only the sheet they are delivered on has changed. One field is renamed: membershipType is published as primaryMemberType, with secondaryMemberType carrying a FACE card. Those names describe the member, whereas the value describes the membership, and one column now carries both because a member may hold more than one membership.
The tier is resolved, not delivered on this sheet. Rows carry the legacy membership type; the EPC tier it resolves to is stated once per type in the membership type mapping table of section 4.4.8, not stamped on every membership row. That table is the artefact in which the determination of open item 3 is recorded and reviewed before the load.
| Field | Type | Req | PII | Description |
|---|---|---|---|---|
| employeeId | String(64) | M | Y | Member holding this term, as staffId. Must match a member.employeeId within the same delivery. |
| membershipType | Enum | M | N | Type of the membership on this row; see 4.5.4. Resolved through the membership type mapping table of section 4.4.8 to an EPC tier. An unresolved value rejects the record. Populates tierId. |
| membershipStart | Date | M | N | Term start date, as startDate in the legacy platform. Populates the membership startDate. |
| membershipEnd | Date | M | N | Term end date, as expireDate in the legacy platform. Must be later than membershipStart. Populates the membership endDate. |
| membershipPaymentType | Enum | M | N | Fee arrangement, derived by the legacy platform from employment type; see 4.5.6. Only DDS is in scope for migration; see open item 1. Populates the membership paymentType. |
| membershipPaymentPeriod | String(64) | M | N | Payment period, mapped in the legacy platform according to employment and member type. It is how EPC establishes the deduction schedule of the legacy term and therefore how many installments remain at cut-over. Resolved through the payment period mapping table of section 4.4.8 to one of the two schedules EPC operates, monthly or one_time; an unresolved value rejects the record. Not loaded onto the membership record, EPC resolving the go-forward period from the tier eligibility rule at renewal. |
| dependantId | String(64) | C | N | Mandatory where the term belongs to a dependant; empty where it belongs to the primary member. Must match the dependantId of that member record. |
| membershipFee | Integer | O | N | Fee for the term in minor units per 4.3.1. Used by EPC to reconcile the delivered term against the resolved tier and to compute the outstanding installments; not loaded as the charge. |
| membershipLastRenewal | Date | O | N | Date of last renewal. Not loaded — EPC has no counterpart field and reconstructs renewal history from membership records created after cut-over. Retained for reconciliation. |
One membership per row, not per member: EPC holds a member's memberships both in succession, a renewal or a tier conversion appending a further record and superseding its predecessor, and concurrently, a Platinum membership and a FACE card being two memberships active at the same time. Deliver each term Emirates intends to migrate as its own row, a FACE card included; EPC creates one EPC membership per delivered row, each with status active.
Grain: one record per family member of a primary member.
Primary key: employeeId and dependantId in combination.
Relationship to the member sheet: a family member who holds their own membership also appears on the member sheet, carrying the same dependantId. A family member without a membership appears only here; EPC records them in the primary member's family list.
| Field | Type | Req | PII | Description |
|---|---|---|---|---|
| employeeId | String(64) | M | Y | Primary member this family member belongs to, as staffId. Must match a member.employeeId within the same delivery. It identifies the member on whose record the family entry is created and is not itself stored on that entry. |
| dependantId | String(64) | M | N | HRMS person identifier of the family member, as serial_number in the legacy platform. Mandatory for every family member, although the legacy field inventory published it as optional: EPC cannot create a family entry without an identifier for that person, and the identifier has to be the one HRMS uses, or the next HRMS update does not recognise the person and adds a second entry for them. Where Emirates cannot source it from the legacy platform, EPC retrieves it from the HRMS dependant details interface, which carries the same value as DEP_PERSON_ID, and the family member is delivered in a correction cycle. Populates the family entry's HRMS reference, family[].memberId, and on the dependant's own record hrmsFamilyMemberId. |
| relation | String(64) | M | Y | Relation to the primary member; see 4.5.3. Resolved through the relation mapping table of section 4.4.8. Populates family[].relation. |
| name | String(100) | M | Y | Given name. Populates family[].name. |
| surname | String(100) | M | Y | Family name. Populates family[].surname. |
| middleName | String(100) | O | Y | Middle name. Not loaded — EPC holds no middle name on a family entry. Retained for reconciliation, and carried onto the dependant's own record where they hold a membership and appear on the member sheet. |
| phone | String(20) | O | Y | Mobile number. Populates family[].phone. |
| String(254) | O | Y | Email address. Populates family[].email. |
|
| birthdate | Date | O | Y | Date of birth. Populates family[].birthdate. |
Grain: one record per partner organisation.
Primary key: id
| Field | Type | Req | PII | Description |
|---|---|---|---|---|
| id | String(64) | M | N | Legacy identifier for the partner. Unique within the sheet. Retained in the identifier crosswalk; EPC issues its own internal identifier. |
| brandName | String(200) | M | N | Consumer-facing brand name. Populates brandName. |
| logo | String(2048) | M | N | Logo URL or path. Must be reachable over HTTPS at load time, or delivered as a file under section 5.5. A partner without a logo renders an empty tile in the partner directory and on every one of its benefits. Populates brandLogoPath. |
| address | String(255) | M | N | Partner address. Branch addresses are delivered in partner_location. Populates businessAddress. |
| country | String(2) | M | N | ISO 3166-1 alpha-2 country code. Populates country. |
| city | String(100) | M | N | City. Populates city. |
| legalName | String(200) | O | N | Registered legal entity name. Populates legalName. |
| partnerTier | String(64) | O | N | Commercial tier of the partner. Populates partnerTier. |
| categoryId | String(64) | O | N | Partner category. Not loaded — EPC holds categories on the benefit, not the partner. Retained, and used as the reference when resolving a rejected offer.categoryIds. |
| subCategoryId | String(64) | O | N | Partner subcategory. Not loaded, on the same basis as categoryId. |
| coordinateLat | Decimal | O | N | Latitude. Not loaded — EPC holds coordinates per location, not per partner. Retained for reconciliation. |
| coordinateLong | Decimal | O | N | Longitude. Not loaded, on the same basis as coordinateLat. |
| website | String(2048) | O | N | Website URL, absolute and including scheme. Populates website. |
| contactEmail | String(254) | O | Y | Contact email address. Populates primaryContact.email. |
| contactPhone | String(20) | O | Y | Contact telephone number. Populates primaryContact.phone. |
| contracts | String(1000) | O | N | Contract identifiers with their start and end dates, in unstructured form. Not loaded — EPC holds contract data in the three structured contract fields of this sheet. Retained as the source from which those are derived where it can be parsed. |
| createdAt | DateTime | O | N | Creation timestamp. Populates createdAt. |
| updatedAt | DateTime | O | N | Last update timestamp. Populates updatedAt. |
| salesforceId | String(64) | O | N | Salesforce account identifier, where held. Retained in the crosswalk only; EPC holds no Salesforce identifier field on the partner record. |
| contactName | String(120) | O | Y | Name of the primary commercial contact, completing the contact email and telephone. Populates primaryContact.name. |
| partnerGroup | String(100) | O | N | Parent group, where partners are grouped commercially. Populates partnerGroup. |
| heroImage | String(2048) | O | N | Partner hero image, on the same basis as logo. Populates heroImagePath. |
| additionalImages | String(4000) | O | N | Further partner images, separated per 4.3.5, in display order. Populates additionalImagePaths. |
| tradeLicenseNumber | String(64) | O | N | Trade licence number, where held. Populates tradeLicenseNumber. |
| contractReference | String(64) | O | N | Contract reference, where held. Deliver it wherever the contracts field can be parsed; otherwise leave it empty and backfill under open item 2. Populates contractId. |
| contractStartDate | Date | O | N | Contract commencement date, on the same basis as contractReference. Populates contractStartDate. |
| contractEndDate | Date | O | N | Contract expiry date, where held. Populates contractEndDate. |
| accountManager | String(120) | O | Y | Emirates-side account owner. Populates accountAgent. |
| socialLinks | String(2000) | O | N | platform=url pairs, separated per 4.3.5. Platform is one of facebook, instagram, linkedin, x, youtube, tiktok. Populates socialMediaAccounts. |
Grain: one record per partner branch.
Primary key: id
Structural note: EPC holds locations within the parent partner record. There is no independent location entity in EPC, and no location-level timestamps; partnerId, createdAt and updatedAt are retained on this sheet regardless.
| Field | Type | Req | PII | Description |
|---|---|---|---|---|
| id | String(64) | M | N | Legacy identifier for the branch. Unique within the sheet. Referenced by offer.locationIds. |
| partnerId | String(64) | M | N | Owning partner. Must match a partner.id within the same delivery. |
| status | Enum | M | N | Branch status; see 4.5.9. Populates status. |
| address | String(255) | M | N | Branch address. Populates address. |
| coordinateLat | Decimal | M | N | Latitude in decimal degrees, between -90 and 90, minimum five decimal places. Validated on load. Populates coordinates.latitude. |
| coordinateLong | Decimal | M | N | Longitude in decimal degrees, between -180 and 180, on the same basis as coordinateLat. A branch without coordinates cannot appear in map or proximity search. Populates coordinates.longitude. |
| name | String(120) | M | N | Display name for the branch, which EPC requires. Where the legacy platform holds no branch name, deliver the partner brand name qualified by the branch city or a sequence number, for example "Zuma DIFC". Populates name. |
| contactPersonFullName | String(120) | O | Y | Branch contact name. Populates contact.name. |
| contactPersonEmail | String(254) | O | Y | Branch contact email address. Populates contact.email. |
| contactPersonPhone | String(20) | O | Y | Branch telephone number. Populates contact.phone. |
| createdAt | DateTime | O | N | Creation timestamp. Not loaded — EPC holds no location-level timestamps. |
| updatedAt | DateTime | O | N | Last update timestamp. Not loaded, on the same basis as createdAt. |
Grain: one record per benefit offered by a partner.
Primary key: id
No eligibility field is requested on this sheet, and EPC treats a benefit carrying no eligibility rule as visible to every member. If the legacy platform restricts any benefit to a population — by card type, grade, company or otherwise — no field defined here carries that restriction and it is lost at cut-over. This is open item 10 and is not settled.
| Field | Type | Req | PII | Description |
|---|---|---|---|---|
| id | String(64) | M | N | Legacy identifier for the benefit, numeric on the legacy platform. Preserved as the EPC benefit number where it is exactly eight digits and unique; otherwise EPC assigns one and this value is retained in the crosswalk. See open item 4. Populates offerId. |
| partnerId | String(64) | M | N | Offering partner. Must match a partner.id within the same delivery. Populates partnerId. |
| status | Enum | M | N | Publication status; see 4.5.7. Populates status. |
| offerType | Enum | M | N | Benefit type; see 4.5.8. A mapping is required where legacy values differ from the EPC set given there. Determines which of discountPercentage and price is mandatory. Populates offerType. |
| startDate | Date | M | N | First date the benefit is valid. Also determines the EPC publication start date; see section 4.6. Populates startDate. |
| shortDescription | String(500) | M | N | Listing text shown in catalogue results. Populates shortDescription. |
| title | String(200) | M | N | Benefit title as presented to members. Populates name. |
| description | String(8000) | M | N | Detail text shown on the benefit page. Where the legacy platform separates the narrative into the component fields of this sheet, deliver those instead and leave this field to carry the general description. Populates longDescription. |
| categoryIds | String(1000) | M | N | At least one benefit category, separated per 4.3.5, resolved to EPC benefit categories. An unresolvable value rejects the record and is reported for categorisation; it is not filed into a default category. Where the benefit carries none, partner.categoryId is the reference for resolution. Populates categories. |
| discountPercentage | Integer | C | N | Whole percentage between 0 and 100. Mandatory where offerType resolves to discount. Populates percentage. |
| price | Integer | C | N | Fixed member price in minor units per 4.3.1. Mandatory where offerType resolves to special_price. Populates priceValue. |
| keywords | String(2000) | O | N | Search keywords, separated per 4.3.5, 100 characters each. Populates keywords. |
| endDate | Date | O | N | Last date the benefit is valid. Empty denotes open-ended. Also determines the publication end date. Populates endDate. |
| images | String(4000) | O | N | Benefit image URLs, separated per 4.3.5. The first is taken as the hero image and the remainder as the gallery, in the order delivered. Must be reachable over HTTPS at load time. Populates heroImagePath and additionalImagePaths. |
| createdAt | DateTime | O | N | Creation timestamp. Populates createdAt. |
| updatedAt | DateTime | O | N | Last update timestamp. Populates updatedAt. |
| subcategoryIds | String(1000) | O | N | Benefit subcategories, separated per 4.3.5, each belonging to a category delivered in categoryIds. Populates subcategories. |
| locationIds | String(1000) | O | N | partner_location.id values at which the benefit is available, separated per 4.3.5. Empty denotes all locations of the partner and is an explicit value, not a missing one. Populates partnerLocations. |
| quota | Integer | O | N | Total redemption allowance. Empty denotes unlimited. Consumed quantity is excluded by section 6.1 and starts at zero. Populates quota. |
| isFeatured | Boolean | O | N | Whether the benefit is promoted in featured placements. Empty is treated as false. Populates isFeatured. |
| discountInfo | String(4000) | O | N | Discount detail, where the legacy platform holds it separately from description. Populates description.discountInfo. |
| includes | String(4000) | O | N | What the benefit includes. Populates description.includes. |
| guests | String(4000) | O | N | Guest entitlement and conditions. Populates description.guests. |
| howToBook | String(4000) | O | N | Booking instructions. Populates description.howToBook. |
| howToRedeem | String(4000) | O | N | Redemption instructions. Populates description.howToRedeem. |
| termsAndConditions | String(8000) | O | N | Benefit terms and conditions. Populates description.termsAndConditions. |
| disclaimer | String(4000) | O | N | Disclaimer text. Populates description.disclaimer. |
Seven mapping tables are delivered in addition to the sheets of section 4.4.1. They resolve legacy coded values to EPC configuration in accordance with 4.3.4. Five are always delivered; the membership type and payment period mappings are delivered only where membership terms are migrated, and the benefit type mapping only where the legacy benefit types differ from the EPC set.
Where a table resolves to an EPC member type or member sub type, the value delivered is the EPC identifier of that record, not its display name. EPC issues the identifier list when it establishes programme configuration, which precedes delivery, so it is available to Emirates before the mapping tables are due. A name is not accepted in place of an identifier: EPC member type and sub type names are editable and are not unique.
Grade mapping — one record per distinct legacy grade.
| Field | Type | Req | PII | Description |
|---|---|---|---|---|
| grade | String(32) | M | N | Every grade value the legacy platform can hold, whether or not it appears in this delivery. Emirates supplies the complete list, so that a grade first seen in a later HRMS synchronisation resolves rather than failing. |
| coreGrade | Enum | M | N | The EPC core grade the legacy grade resolves to; see 4.5.1. |
| isCabinCrew | Boolean | M | N | Whether the legacy grade denotes cabin crew. See the note below. |
Grade is load-bearing: cabin crew and Face entitlement is not stored in EPC. It is evaluated from the grade at the moment an eligibility rule executes, by testing for the prefix CC.. A grade resolved incorrectly therefore changes what a member is entitled to see and purchase, and no error is raised. Where this table's isCabinCrew disagrees with the prefix rule for any grade, Emirates to advise EPC rather than adjusting the delivered grade.
Employment type mapping — one record per distinct legacy employment type.
| Field | Type | Req | PII | Description |
|---|---|---|---|---|
| employmentType | String(64) | M | N | Every distinct member.employmentType value present in the delivery. The permitted set is given in 4.5.2. |
| memberTypeId | String(64) | M | N | Identifier of the EPC member type the legacy value resolves to, from the list EPC issues with programme configuration. |
| hrmsValue | String(64) | C | N | The value HRMS transmits for this type. Mandatory where HRMS is the ongoing source for the population; empty for populations HRMS does not transmit, such as associated companies. |
Relation mapping — one record per distinct legacy relation.
| Field | Type | Req | PII | Description |
|---|---|---|---|---|
| relation | String(64) | M | N | Every distinct member.dependantType and family_member.relation value present in the delivery. The permitted set is given in 4.5.3. |
| memberSubTypeId | String(64) | M | N | Identifier of the EPC member sub type the legacy relation resolves to, from the list EPC issues with programme configuration. |
| classification | Enum | M | N | spouse, child or none. Determines which dependant eligibility rules EPC applies. |
| maximumAge | Integer | O | N | Age limit applying to the sub type, where one applies. |
| hrmsValue | String(2000) | O | N | HRMS contact type values that resolve to this sub type, separated per 4.3.5. |
Membership type mapping — one record per distinct legacy membership type. Delivered only where membership terms are migrated, and agreed jointly: the legacy types are Emirates', the tiers they resolve to are EPC configuration, and the resolution itself is the determination recorded in open item 3.
| Field | Type | Req | PII | Description |
|---|---|---|---|---|
| membershipType | String(64) | M | N | Every distinct membership.membershipType value present in the delivery. The permitted set is given in 4.5.4. |
| tierId | String(64) | M | N | Identifier of the EPC tier the legacy type resolves to, from the list EPC issues with programme configuration. One tier per legacy type: both courses under open item 3 resolve a legacy type to a single tier, whether that is the live tier of the same level or a dedicated migration tier. |
| taxable | Boolean | M | N | Whether the fee of this legacy type was subject to VAT during the migrated term. EPC computes VAT as at the time a charge was raised rather than as the resolved tier is configured at migration, so this cannot be read back from the tier and is required per open item 3. |
Payment period mapping — one record per distinct legacy payment period. Delivered only where membership terms are migrated.
| Field | Type | Req | PII | Description |
|---|---|---|---|---|
| membershipPaymentPeriod | String(64) | M | N | Every distinct membership.membershipPaymentPeriod value present in the delivery. The legacy platform derives this value from employment and member type and no value set for it has been given to EPC, so the complete list is supplied here. |
| paymentPeriod | Enum | M | N | monthly or one_time. The two deduction schedules EPC operates; it holds no others. A legacy period collected in equal monthly installments resolves to monthly, one collected as a single deduction to one_time. This value is what EPC uses to count the installments outstanding at cut-over, so an incorrect resolution changes how much is collected from the member. |
Benefit type mapping — one record per distinct legacy benefit type. Delivered only where the legacy values differ from the EPC set of 4.5.8; where they are identical, state so and omit the table.
| Field | Type | Req | PII | Description |
|---|---|---|---|---|
| offerType | String(64) | M | N | Every distinct offer.offerType value present in the delivery. |
| epcOfferType | Enum | M | N | The EPC benefit type the legacy value resolves to, from the set given in 4.5.8. It determines which of discountPercentage and price is mandatory on the benefit, so a benefit whose type resolves to discount without a percentage rejects. |
Branch status mapping — one record per distinct legacy branch status.
| Field | Type | Req | PII | Description |
|---|---|---|---|---|
| status | String(64) | M | N | Every distinct partner_location.status value present in the delivery. The values of the legacy PartnerLocationStatus have not been given to EPC, so the complete list is supplied here. |
| epcStatus | Enum | M | N | active or inactive. EPC holds no other status for a branch; see 4.5.9. |
Legacy-side value sets in this section are quoted from the legacy field inventory Emirates supplied. EPC-side sets are the enumerations held in the EPC codebase. No value in this section is drawn from data held in any EPC environment. Where EPC holds a set as configuration rather than code — member types, member sub types, tiers and benefit categories — no list is published here, those being established as programme configuration before delivery and issued to Emirates per section 4.4.8.
| Value | Description |
|---|---|
| EK.01 to EK.14 | The fourteen EPC core grade bands. Fixed in the EPC codebase, so the set is not configuration and does not vary between environments. Delivered as EK. followed by a two-digit band, zero padded. No other value is accepted. |
Each value must appear in the employment type mapping table.
| Value | Description |
|---|---|
| Permanent | Permanent employee. |
| Temporary | Temporary or contract employee. |
| Retire | Retired employee. Conveys the same fact as isRetiree where that field is not held. |
| Dependant | Dependant holding their own membership. |
| Associated Company | Employee of an associated company. HRMS does not transmit this population, so its mapping cannot be inferred. |
Each value must appear in the relation mapping table.
| Value | Description |
|---|---|
| spouse | Spouse of the primary member. |
| child | Child of the primary member. |
| sibling | Sibling of the primary member. |
| in-law | Relation by marriage. |
| parent | Parent of the primary member. |
This field carries the type of the membership on the row, not an attribute of the member holding it. EPC expresses a membership's type as its tier, so each value resolves to one through the membership type mapping table of section 4.4.8; which tier, on what dates and at what fee, is the determination of open item 3.
| Value | Description |
|---|---|
| Regular, Club, Premium | The three legacy Platinum card types. The legacy field inventory states these values without a ranking between them and EPC infers none. |
| Face | The legacy FACE card, which the legacy platform holds in a separate secondaryMemberType field. It is a distinct product rather than a level of the Platinum card, carrying its own fee and its own payroll deduction, and a member may hold it at the same time as a Platinum membership. Deliver it as a membership row of its own; EPC holds it as an add-on tier. |
This field states whether the person is an active member of the legacy programme. It is delivered in a column named memberStatus; the legacy platform holds the same value as membershipStatus, sourced from isActive. It is not the status of a membership — EPC holds a status on the member and a separate status on each membership, and this field is the input to the former only. It carries two values.
| Value | Description |
|---|---|
| active | The person is an active member. Derived to EPC active, pending tier, pending identity photograph or pending invitation acceptance according to section 4.6. |
| inactive | The person is no longer an active member. Derived to EPC inactive, with deactivation source system. No membership is created for them. |
The legacy platform holds no state beyond these two. Every other EPC member state is therefore derived rather than delivered; section 4.6 gives the rules and names the states no migrated member can be placed in.
No status is delivered for a membership. A membership is migrated only where the member holds a current term, and EPC creates it active; a term that has ended or lapsed is not migrated, there being no entitlement or collection to carry.
The legacy platform derives this value from employment type rather than holding it as a stored field, as it does membershipPaymentPeriod. Two arrangements are operated and both are delivered.
| Legacy value | Loaded as | Description |
|---|---|---|
| DDS | salary_deduction |
Direct deduction from salary. The only arrangement in scope for migration; see open item 1. |
| Company Paid | company_paid |
Fee borne by the employing company. |
EPC holds three further arrangements of its own — credit_card, free_dependant and free_of_charge — and none is a migration target. The legacy platform operates no card collection, so no term carries a card arrangement, and free_dependant and free_of_charge have no legacy counterpart. A value outside the two above rejects the record under section 5.2.
| Value | Loaded as | Description |
|---|---|---|
| published | active | Visible to eligible members. |
| unpublished | inactive | Held in the catalogue but not visible. |
| expired | expired | Past its validity period. |
| — | pending | EPC's own fourth status, and the default for a benefit created in EPC. No legacy value resolves to it and no migrated benefit is placed in it; it is stated so that the set is complete. |
The EPC set. Where the legacy values differ from these, they are resolved through the benefit type mapping table of section 4.4.8; an unresolved value rejects the record.
| Value | Description |
|---|---|
| discount | Percentage reduction. discountPercentage is mandatory. |
| special_price | Fixed member price. price is mandatory. |
| special_deal | Non-monetary or bundled offer. |
| lifestyle_hub | Venue access benefit. Requires further fields not defined in this document: access types, per-person pricing, guest and excess-quota day pass rates, and a cancellation window. Emirates to advise whether any legacy benefit is of this type, whereupon an annex will be issued. |
The EPC status set. partner.status is not a field of the partner sheet and is not delivered; it appears here only because the two share a value set, and the third value belongs to it alone.
| Value | Description |
|---|---|
| active | Available to members. |
| inactive | Withdrawn or dormant. |
| pending | Awaiting activation. Applies to partners only. |
Partner status is not delivered. The legacy partner record carries no status field, and every migrated partner is created as pending per section 4.6.
Branch status is delivered. The legacy partner location record carries a status field, though the values of the legacy PartnerLocationStatus have not been given to EPC. Emirates supplies them in the branch status mapping table of section 4.4.8, which resolves each to active or inactive: EPC holds no third status for a branch.
This field says which company employs the member. It never carries a legacy company code, so no company mapping table is required.
EPC keeps a register of the programme's companies listing, for each one, every value that resolves to it. For a company HRMS transmits, those values are its HRMS BG_IDs — which is what the legacy platform already holds in this field. A company may hold more than one. For a company HRMS does not transmit, such as an associated company, there is no BG_ID at all; the register gives that company an EPC company code, and that is the value delivered for its members instead.
Deliver whichever value the legacy platform holds for the member, and the code from the register where it holds none. No value resolves to more than one company, so resolution is unambiguous. A value in neither list rejects the record under section 5.2.
Whether HRMS owns the member's data after migration follows from the company, not from the value delivered; see section 4.6.
EPC has not issued the register yet; it will be added as an annex to this document. Until it is, the code for a company that has no BG_ID is not available, so companyId cannot be completed for its members. See open item 5.
The following are computed by EPC on receipt and must not be delivered. They are documented because several fields in section 4.4 exist solely as inputs to them.
| Derived field | Inputs | Rule |
|---|---|---|
| Member status | member.memberStatus, member.idPhoto, the presence of a membership record and the derived login method |
Decision table below. |
| Login method | member.email, member.companyId |
Corporate SSO where the person's own email domain is an approved SSO domain and their company permits SSO; email and password otherwise. Dependants are evaluated on their own address, not that of the primary member. |
| Core grade | member.grade and the grade mapping table |
Resolved through the grade mapping table. An unmapped grade rejects the record. |
| Cabin crew and Face eligibility | member.grade |
Evaluated at rule execution time from the grade prefix CC. and never stored, which is why isCabinCrew is retained but not loaded. Grade establishes what a member is eligible for, the FACE card included; whether they hold a FACE membership is carried by the membership sheet and is not derived from grade. |
| Benefit publication window | offer.startDate, offer.endDate |
Publication dates equal the validity dates. No separate fields are requested. |
| Photograph review status | member.idPhoto |
Recorded as approved where a photograph is delivered, so migrated members are not required to resubmit. |
| Membership number | — | Issued by EPC to every migrated member from its own ten-digit series. No legacy value is delivered. |
| Partner status | — | Every migrated partner is created as pending, which is the EPC default. A pending partner and its benefits are not returned by any member-facing query, so migrated benefits become visible only as EPC activates each partner after reconciliation. |
| Benefit number | offer.id |
Preserved where the delivered value is exactly eight digits and unique; otherwise assigned by EPC, with the legacy value retained in the crosswalk. |
| Membership record | the membership sheet of section 4.4.3 |
Created only where membership terms are migrated per open item 1. EPC creates one membership per delivered membership record, always with EPC membership status active, resolving the tier per open item 3 and collecting only the outstanding installments computed below. No membership status and no renewal election are delivered, so EPC applies its own defaults and the member sets their preference in EPC. Where the sheet is not delivered, no membership is created and every migrated member resolves to pending tier by rule 3 of the decision table below. |
| Outstanding installments | membership.membershipStart, membershipEnd, membershipFee, membershipPaymentPeriod |
Where terms are migrated, EPC computes the installments falling between cut-over and the term end date and collects only those. A term paid in full in advance yields none. The go-forward payment period is resolved by EPC from the tier eligibility rule at renewal, so membershipPaymentPeriod is not loaded onto the membership record. |
| Primary member link | member.employeeId, member.dependantId |
A dependant record is attached to the primary member carrying the same employeeId, and EPC records its own internal reference to that primary on the dependant. No field conveys this link and none is requested: it is the pairing of the two delivered keys. This is why employeeId on a dependant row is a join key and not that record's own staffId. |
| Membership eligibility rule | the resolved tier, and the member's own attributes | Where terms are migrated, EPC selects the eligibility rule of the resolved tier that the migrated member satisfies and that permits salary_deduction, exactly as it would at enrolment, and records it on the membership. No rule identifier is delivered. The rule is load-bearing after cut-over rather than at it: the payroll feed reads the deduction frequency from it, and renewal resolves the successor rule from it. A tier that carries no rule the member satisfies cannot receive that member's term, and the record is rejected under section 5.2 for Emirates to reconcile under open item 3. |
| HRMS data ownership and registration source | member.companyId |
Members of companies carrying a BG_ID are recorded as HRMS-sourced, which makes name, email, grade, birth date and employee number read-only in the EPC back office thereafter, and determines which records HRMS may subsequently overwrite. Members of a company carrying no BG_ID are not: those fields stay editable in EPC, HRMS never overwrites the record, and the alumni classification is not evaluated for them. See 4.5.10. |
Member status decision table. The first matching rule applies.
| Rule | Condition | Resulting status | Additional fields recorded |
|---|---|---|---|
| 1 | memberStatus is inactive |
inactive | Deactivation source system; deactivation timestamp of the load |
| 2 | idPhoto is empty, or the reference it carries does not resolve |
pending identity photograph | Member is prompted to upload a photograph |
| 3 | No current membership term exists | pending tier | Member is prompted to enrol |
| 4 | Login method resolves to corporate SSO | active | None. The member signs in by SSO and no invitation is issued |
| 5 | Login method resolves to email and password | pending invitation acceptance | Invitation issued only once the load is reconciled, and then at a controlled rate. No migrated member is contacted about their record before reconciliation completes |
EPC transfers no authentication material, so no migrated member holds an EPC credential at cut-over. Rules 4 and 5 divide on how that credential is obtained rather than on whether it exists: an SSO member obtains it from the corporate identity provider at first sign-in, whereas an email and password member must accept an invitation and set one. The two rules exhaust the possible values of the derived login method, so rule 5 is also the default.
Five of the ten EPC member states are unreachable by migration, and by design. States pending invite and pending approval belong to the EPC enrolment journey, which a migrated member does not travel. State pending payment arises only from a charge raised by EPC, and none is raised during the load. States suspended and rejected have no source, the legacy platform holding no state beyond the two values of section 4.5.5. Where Emirates holds suspended members or refused applicants, they are excluded from the extract rather than expressed in it.
| Characteristic | Specification |
|---|---|
| Interface type | One-time bulk file transfer, executed once against non-production and once against production. |
| Direction | Legacy platform to EPC. No response file is produced; results are returned as the rejection report of section 5.3. |
| Format | Excel workbook carrying one sheet per section 4.4 definition; or delimited text, comma separated, conforming to RFC 4180. |
| Encoding | UTF-8 without byte order mark. Line ending CRLF or LF. |
| Header row | Mandatory. Header text must equal the field name given in section 4.4. |
| Manifest | Each delivery is accompanied by a manifest stating, per sheet, the record count and, for delimited files, the SHA-256 checksum. A delivery whose counts or checksums do not reconcile is not processed. |
Validation proceeds in four ordered stages. A record failing a stage is not evaluated by subsequent stages. No stage substitutes a default value for invalid data, other than where a field's description states an EPC default.
| Stage | Check | Error classes |
|---|---|---|
| 1 | Structure. Header presence, encoding, delimiter, column count, manifest reconciliation. | E-FILE |
| 2 | Field. Data type, length, format, mandatory presence, conditional rules and enumerated values. | E-FORMAT, E-LENGTH, E-REQ, E-COND |
| 3 | Code resolution. Mapping tables of section 4.4.8 and EPC configuration. | E-CODE |
| 4 | Referential integrity and uniqueness. Foreign keys within the delivery, and duplicate detection. | E-REF, E-DUP |
The data quality rules enforced across these stages are as follows.
| Rule | Applies to | Action on breach |
|---|---|---|
| Monetary fields are integer minor units per 4.3.1. Decimal separators, thousands separators and currency symbols are not accepted. | membership.membershipFee, offer.price |
Reject record, E-FORMAT |
| Dates and timestamps conform to 4.3.2. Date-only fields carry no time component. | All Date and DateTime fields | Reject record, E-FORMAT |
| An empty field denotes no value and is not populated with a placeholder, per 4.3.3. | All optional fields | Reject record, E-FORMAT |
| Email addresses are unique across the member sheet and programme-wide. | member.email |
Reject record, E-DUP |
| Keys are unique within their sheet; benefit numbers are unique programme-wide. | member.employeeId with dependantId, partner.id, partner_location.id, offer.id |
Reject record, E-DUP |
| Every coded value present in the data is resolvable through the corresponding mapping table or EPC configuration. | member.companyId, member.employmentType, member.grade, member.dependantType, family_member.relation, membership.membershipType, membership.membershipPaymentType, membership.membershipPaymentPeriod, partner_location.status, offer.categoryIds, offer.subcategoryIds, offer.offerType |
Reject record, E-CODE |
The EPC member type a member's employmentType resolves to is one the member's company is configured to admit. EPC holds an eligible member type list per company and creates no member outside it. |
member.employmentType with member.companyId |
Reject record, E-CODE |
| The EPC member sub type a dependant's relation resolves to is one the primary member's company is configured to admit. EPC holds a permitted sub type list per company and creates no dependant or family member outside it. | member.dependantType, family_member.relation, each with the primary's member.companyId |
Reject record, E-CODE |
| The number of dependants of a given sub type held against one primary member does not exceed the maximum that member's company is configured to allow for that sub type; see open item 5. Records are evaluated in the order delivered and it is the surplus that is refused, so a primary member with more children than the configured cap is loaded with as many as the cap admits and the remainder are reported. | family_member and dependant member records, per employeeId and resolved sub type |
Reject surplus record, E-COND |
A primary member carrying a dependant or family member whose relation classifies as spouse is recorded as married. |
member.maritalStatus |
Reject the spouse record, E-COND |
| Every foreign key resolves to a record present in the referenced sheet within the same delivery. | family_member.employeeId, membership.employeeId, membership.dependantId, partner_location.partnerId, offer.partnerId, offer.locationIds |
Reject record, E-REF |
| Text is UTF-8, multi-value fields are separated per 4.3.5, and no field contains a line break. | All String fields | Reject record, E-FORMAT |
| Image URLs resolve over HTTPS at load time. EPC downloads, re-hosts and re-renders assets at display sizes; legacy URLs are never referenced at run time. | partner.logo, partner.heroImage, partner.additionalImages, offer.images |
Record loads, asset reported as W-ASSET |
| Values exceeding a declared String length reject the record. Text is never silently truncated. | All String fields | Reject record, E-LENGTH |
| Conditional fields are present where their stated condition holds and absent where it does not. | member.dependantId, member.dependantType, member.birthdate, member.maritalStatus, member.idPhoto, membership.dependantId, offer.discountPercentage, offer.price |
Reject record, E-COND |
One report is returned per delivery, as a comma separated file. Every rejected record is identified by its own key so that it can be located in the source system without reference to EPC identifiers.
| Column | Content |
|---|---|
| sheet | Sheet name, for example member |
| row | Row number within the delivered sheet, excluding the header |
| key | The record's own key, for example employeeId value 512334 |
| field | Field name at fault, for example grade |
| error_class | Error class per section 5.2 |
| detail | The value received and the reason it was refused |
With the report EPC returns the member count per resolved core grade, for Emirates to confirm against payroll. A grade mapped to the wrong core grade passes every check in section 5.2 and is detectable no other way, while silently changing what the affected members are entitled to.
Corrected records may be redelivered as a partial file containing only the affected rows, carrying the same header. Records already loaded are updated in place, keyed on their key, and are not duplicated. At least one correction cycle should be assumed.
EPC holds, for every delivered record, its legacy key against the identifier and any human-facing number EPC issued to it, so that a record can be traced in either direction during reconciliation.
Non-production and production are separate key spaces. Numbers issued to a record in non-production are not the numbers it receives in production, so the two deliveries must not be reconciled against one another.
| Asset | Specification |
|---|---|
| Identity photographs | Retrieved by EPC from the legacy image API using the reference in member.idPhoto; no photograph files are delivered. JPEG or PNG, re-rendered by EPC to its own display sizes. The API must remain available until the production load is reconciled. A reference the API does not resolve is treated as no photograph, so the member resolves to pending identity photograph and is reported to Emirates. See open item 8. |
| Partner and benefit imagery | Delivered as URLs within partner.logo, partner.heroImage, partner.additionalImages and offer.images where those URLs are reachable per section 5.2. Where they are not, deliver an archive named by the URL basename and advise EPC, which will substitute file references before the load. |
Record counts per sheet are TBD and will be stated by Emirates with the first non-production delivery; see open item 7. EPC sizes the load from the manifest of section 5.1 and does not assume a volume.
The following are withheld from the interface. Exclusion is by agreement and, other than where noted, does not affect reconciliation.
| Field | Sheet | Category | Rationale |
|---|---|---|---|
| passwordHash, loginAttempts, lockedUntil | member | Credential | Authentication material. Migrated members authenticate by SSO or by fresh EPC invitation. |
| invitationToken, invitationExpiresAt | member | Credential | Single-use secrets bound to legacy flows; account-takeover vector. |
| Card and payment instrument data | member | PCI | Instruments are collected directly from members by the payment gateway. membershipPaymentType conveys the arrangement only. |
| Payment and invoice history | payment, invoice | Scope | The legacy platform remains the record for terms purchased before cut-over, and for every amount collected before it. EPC's own collection record begins at cut-over; where a membership term is migrated, EPC collects only the installments outstanding at that point, per section 4.6. |
| Redemption history and consumed quota | redemption, offer | Scope | Usage counters start at zero, so a quota-limited benefit receives its full allowance again at cut-over. Emirates to advise if any benefit's consumed quota must be carried across. |
The following legacy data sets are not migrated.
| Data set | Reason |
|---|---|
| Company | Company records, including their eligible member types and sub types, are now established directly in EPC as programme configuration before delivery, together with the BG_ID each company requires for HRMS resolution. |
Benefit category (OfferCategory) |
Benefit categories and subcategories are now established directly in EPC as programme configuration before delivery. offer.categoryIds resolves against that configuration. |
| Voucher and VoucherCategory | EPC has no voucher capability, so there is no destination for this data. Migrating it would first require the voucher feature to be developed in EPC, which is outside the scope of this interface. |
| Partner Staff User | EPC requires a role and an email address for every partner user, neither of which appears in the legacy inventory, and an invitation cannot be issued without an address. Per-location access is held on the legacy side as locationIds and could be carried, but has no user to attach to. Partner staff are invited individually through the EPC partner portal after migration, and their location access is set at that point. |
Open items 1 to 5 and 8 to 11 must be determined before delivery, and are the critical path: until they are settled the mapping tables and the EPC programme configuration cannot be completed and the load cannot be executed. Open items 6 and 7 may be settled during the correction cycle.
| Ref | Item |
|---|---|
| 1 | Migration of membership terms. First, whether terms are migrated at all. EPC recommends that they are not. Every EPC money operation computes from collection history, none of which exists in EPC for a legacy term, so the sound course is to migrate identities and entitlement shape rather than money-bearing terms. Under that course members enrol on the current EPC cycle, and Emirates determines the treatment of an unexpired legacy term: honoured off-platform until it expires, refunded or absorbed on fresh enrolment, or granted in EPC as a no-fee term running to the legacy end date. Second, where Emirates elects to migrate terms, EPC collects only the installments outstanding at cut-over, computed from the term dates, fee and payment period. This requires no collection history, which the legacy platform does not hold in a form Emirates can extract; it removes the double-deduction exposure entirely; and it confines EPC's ledger, and therefore any refund EPC computes, to money EPC itself collected. Money collected by the legacy platform before cut-over remains a legacy matter, and Emirates is asked to accept that division explicitly. Required from Emirates: confirmation of the decision, and of the deduction schedule on which a legacy term was collected, so that the outstanding installments can be computed. |
| 2 | Partner contract backfill. Neither contractReference nor contractStartDate is required for migration, so this item does not gate delivery. Where the contracts field can be parsed at extraction, deliver both. Otherwise EPC creates the partner without them and Emirates backfills from the Salesforce integration once it completes. Required: confirmation of which route applies and, where the backfill route is taken, the point at which contract data becomes available. |
| 3 | Tier resolution for membership.membershipType. Either the current cycle's live tiers, whereby members join the live tier of their level retaining their own dates, noting that a member's dates need not fall within the tier's validity window and the legacy fee bears no relation to the tier price; or dedicated migration tiers mirroring legacy fees and dates, noting that each requires finance configuration and a VAT flag, that they become visible to members and administrators, and that EPC renewal must be able to resolve a successor tier. VAT applies as at the time a charge was raised, not as configured at migration, so the treatment of each legacy level during the migrated term is required either way. Whichever course is taken, the determination is recorded in the membership type mapping table of section 4.4.8, which carries the resolved tier and the VAT treatment per legacy type. |
| 4 | Conformance of the legacy benefit identifier. Confirmation of whether offer.id is exactly eight digits, so that it can be preserved as the EPC benefit number rather than reassigned. Required evidence is twenty representative benefit records. |
| 5 | Company register and configuration, section 4.5.10. Every value appearing in member.companyId must be configured against a company in EPC beforehand, or the affected members reject. Required from Emirates: the list of companies in the legacy programme and the HRMS BG_IDs each one holds, naming those that hold none so that EPC can issue them a company code instead; and, per company, the largest number of dependants of each relation held against any one primary member. EPC caps that number per company, and a cap set below the legacy maximum truncates families at load under section 5.2, so EPC sets each cap at or above the figure Emirates gives and confirms the configuration back before the first delivery. Determines which populations HRMS owns after migration. |
| 6 | Transfer channel, credentials and retention period for delivered files. |
| 7 | Record counts per sheet, section 5.6, and whether any benefit is of type lifestyle_hub. |
| 8 | Legacy image API. Endpoint, authentication method and rate limit, the form of the idPhoto reference it expects, and the date until which it remains available. EPC retrieves every identity photograph through it, so the production load cannot complete without it. |
| 9 | Notification preferences. Whether the legacy platform holds per-member email and SMS preferences for prefEmail and prefSms. Where it does not, EPC enables both at cut-over, which re-subscribes any member who had opted out. |
| 10 | Benefit eligibility. EPC restricts a benefit to a defined population by an eligibility rule held on the benefit — a rule over member type, sub type, company, grade, core grade, department, tier, age, cabin crew, retiree or alumni status. No such field appears in the legacy benefit inventory given to EPC, and no eligibility field is requested on the offer sheet of section 4.4.7. The consequence, if nothing is supplied, is that every migrated benefit becomes visible to every member: EPC treats a benefit carrying no rule as unrestricted, and it will not infer a restriction that was not delivered. Required from Emirates: what the legacy platform holds about who may see and redeem a benefit — whether restriction is expressed on the benefit itself, on the partner, by card type, by grade, or by any other means, and whether it is held as data at all or applied editorially. Where restrictions exist, EPC will issue an annex defining the field or sheet that carries them; where none exist, Emirates to confirm that a fully open catalogue at cut-over is the intended outcome. This item does not gate the delivery of any other sheet, but it does gate making the migrated catalogue visible to members. |
| 11 | Dependant email addresses. member.email is mandatory on every row of the member sheet and unique programme-wide, dependants included, because a dependant holding their own membership signs in to EPC in their own right. Legacy programmes commonly hold no address for a young dependant, or hold the primary member's address against several of them; the first case rejects E-REQ and the second E-DUP, and because siblings share one address a family arrives part-migrated. EPC expects this to be the largest single source of rejections in the load. Required from Emirates: the count of dependant records holding no address of their own and the count sharing an address with another record, taken before the first delivery so the scale is known; and a determination on how those dependants are to be treated — an address sourced from HRMS, an address collected from the primary member before cut-over, or the dependant migrated as a family entry only under section 4.4.4, holding no membership and no sign-in until an address is supplied. EPC recommends the last as the default for any dependant whose address cannot be sourced, because it migrates the person and the family linkage rather than refusing them. |