Interface 1 Mapping

Identification of members

The membership number is the only unique number that is received, the pay centre is known and hence the search to establish the correct scheme and member reference number record is limited to the pay centre list across the schemes.

If the member is found as an active member, the system will confirm that the initials and date of birth are the same as on Interface 1.  If they are the same, the changed fields will be updated as per the existing process. 

If the member is found but is an exit in progress, an exit finalised or a deferred record, the system will insert a new membership record for the person.  There will not always be a full record received and hence the company reference number will be used to double check if initials and date of birth match.

If the member is not found within the pay centre and the membership number is outside of the range of the pay centre, the system will read for the other pay centres for that principle employer to determine if the member is an employer transfer.  If the membership is still not found, a format error will be produced as the reference number range on SAP has a problem and the users must make the decision.

If an employer transfer is suspected, refer to the BLMODE table under Leavers below for the fields that will provide confirmation.

The PSCHIND is the same as the Vision membership group for the contribution category. 

Translations

Scheme indicator and non UK indicator

PSCHIND AI, PI, AW and AT – these in combination with the UK indicator and members date of birth when joining the scheme are used to create contribution, benefit and investment categories.

PSCHIND indicator of FP

When a Pension Scheme Indicator (PSCHIND) of 'FP' and associated Pension Scheme Date (PSCHDTE) is received on the Interface 1 file, Vision will use this data along with the new member number generated to trigger the creation of a new membership record, but linked to the existing person record.  The existing membership will be processed as an annuitant.  This record should have the following categories:

-  Benefit Category of BA20 - Life Assurance Only Flexible Retirement

-  Contribution Category of C20 - No contributions

-  Investment Category of I07 - Members with no Individual Investments. 

This record will retain the original active staff number which will continue to link to the active SAP.

SMPDTE

SMPDTE is used to determine when a member changes from statutory maternity/adoption leave to company or unpaid maternity/adoption leave and to update the service history accordingly.  The end of statutory maternity leave is notified to UK Pension Administration as an SMPDTE on the Interface 1 basic file as follows:

-  Move Code M         for a member that goes on Statutory Maternity Leave

-  Move Code K         for a member that goes on Statutory Adoption Leave

This will be received and translated as follows:

-  M = AMS     service history record of statutory maternity leave

-  K = AAS      service history record of statutory adoption

When members are due back, a SMPDTE date will be received which will indicate the end of the statutory maternity/adoption leave period, which will then create a move code of AMB (maternity) or AAB (adoption).  Some members may return to normal service before the end of their statutory maternity/adoption leave and this will be received as MOVCDE E (ARB).

MOVE CODE

MOVE CODE A will be hardcoded as follows:

The following values will be updated on the conversion values to map to the correct membership group on Vision.

Note:

The number fields have an actual decimal point in all the files for amount fields except for the DC/DB Money Purchase record.

Membership group allocation

Leavers

Employees who exit the bank have a Leaving Date (BLDATE) and a Leaving Reason (BLMODE) on the Interface 1 file.  These codes trigger various updates dependant on what scheme the member is in and what type of leaver they are. 

When Interface 1 is loaded the system will take the BLMODE, and if there is an exit date, store the BLMODE in the exit reason field by enabling a new field for the business system of Exit Reason.  The users will configure the conversion value for the BLMODE to the correct event that is on the Benefit Rules. 

The new field to be sent on the BJU3AR interface will be enabled and if the event does not map to an event for that member’s category for the claims process, a message is written to the error log with the incorrect event and the exit reason will be reset to blank by not updating the event on the exit benefit request. 

If the exit date is in a future cycle, then keep rolling the member forward until the exit date is within the cycle date.

The exit date and exit reason is mandatory and hence if one is missing, this is a rule and validation error.

The Benefit Payment Process will take care of the eligibility checks and appropriate service checks with resulting permutations.

The BLMODEs in use are in the current list below:

BLMODE

For reporting purposes, when the exit record is updated to the core data, if the date received is different to the current exit date, a message is written to the error log. 

Exits greater than 3 months old will be reported as a format error in the error log.

For BJU3AR, the exit reason will be included if there is a difference.  The core date is always taken as the correct date.  The users are able to do a cancellation with change of exit date in the current benefit payment functionality.  This will only be applicable to future dated exits, as exits that are in progress and have dropped from the cycle will be rejected as a format error if they are received on Interface 1 again.

New entrants to the scheme and transfers

Based on a check of the National Insurance Number and date of birth, the system verifies whether the new joiner on the file already has a record on Vision.  If they do not, a new record will be created.  If they do, Vision will determine whether the member is an inter-group transfer or a member who has previous service in the bank but left and has now rejoined.  If the former, a determination will be made as to whether the member should have continuous service under their existing scheme membership or whether their existing scheme membership needs to be deferred and the member set up with a new scheme membership. 

Vision will use the surname, initials, date of birth and identification/national insurance number to establish the uniqueness of the person.

The rules regarding whether member should stay in an existing scheme or move schemes are as follows:

Legal Entity changes

Note:

For most transfers, the table above shows that the member would retain continuous service in their existing scheme.  However, for the 7 transfer scenarios at the bottom of the table, the member will be moved from PIP to Afterwork. 

The NI category is not known at the time of the Interface 1 loading as the NI category is on Interface 4 and hence to identify and perform the changes, the above table is hard coded in the module.

If the BLMODE = ‘C’, the member is being transferred. 

-  If the scheme is Afterwork, the member remains on Afterwork and hence updates the client relationship to show the change of employment relationship if this is the transferring in pay centre/employer.  If this is the pay centre that the member is already on, the member will be marked as being ‘transferred out’ without transferring him in until he enters as a new entrant on that pay centre.

-  If the scheme is PIP and the member is on pay centre GROUP or WEALTH and the member moves to the pay centre BARCAP, the member must stay on PIP and the client relationship must be updated to show that the employer has changed, otherwise the member must move to AFTERWORK.  This means that a new membership record must created on the scheme AFTERWORK and that the PIP scheme must be end-dated as the record is going to become deferred.

-  If the scheme is Afterwork and the member moves to the BARCAP pay centre, the member must move to the PIP scheme.

-  There are a few hundred members on PLC contracts that are in GPP arrangements with Scottish Equitable or Friends Provident and who are therefore not in any UK schemes.  If these members had an inter-group transfer onto any other contract type, they would have to join either Afterwork or PIP.  In such cases, they may come across on the interface file flagged as being an inter group transfer, but Vision would not hold a current active record for them, therefore a new person and membership record would need to be created.

If the BLMODE is a ‘C’ and the program cannot find a membership record, then create a membership record in the scheme which must be translated from the rules above.

For the valid members that are being transferred in, i.e. no scheme change, ensure that they appear on the existing transfer report.

If the MOVCDE = ‘C’, the member is joining the pay centre and the same logic as above must be applied.

New joiners are identified on the file with a MOVCDE of ‘A’.

-  Each Afterwork or PIP new joiner must be allocated to the relevant benefit, contribution and investment categories as derived based on various combinations of PSCHIND, NONUKIND plus age at date of joining (as derived from DJSCH - DOB).  The mandatory contributions should start from date joined scheme.  The Benefit Categories will be allocated as follows using the conversion values.  If the value of PSCHIND = ‘AI’, allocate according to the age of the member to the correct membership group age band. 

-  The tables below are an example.

Table key

Afterwork

PIP

Contribution Categories will be allocated as follows using the combination of 2 fields:

Afterwork

PIP

Investment Categories will be allocated as follows using the combination:

Afterwork

PIP

-  If the PSCHIND field is blank and the member is a new joiner, a rule and validation error will occur. 

-  If the date joined scheme, the move date and the PSCHDTE are not the same, the new joiner will be flagged as a rule and validation error.

-  If the PSCHIND and the PSCHDTE are missing, a rule and validation error will be displayed if they are missing as these fields are mandatory.

-  In the BJU3AR interface program, if the territory parameter at a scheme level for the Internal Earnings Cap (IEC) currently set at £123,600 has been exceeded, then if the salaries being stored exceed this value, write a message to the error log with the detail and a clear message that the users can filter on.

NI category conversions:

Format errors

If there are duplicates being loaded with different membership reference numbers, there will be a format error with duplicate membership for surname, initials, date of birth, NI number and company reference number and hence 2 live memberships in the same scheme. 

The selection is required on a format error to reject the one record and not to reject all the format errors as some should be edited and resubmitted.

Absence breaks

If a member goes on / returns from an absence break, a movement code (MOVCDE) and associated date (MOVDTE) is sent on the Interface 1 file.  This should be used to update the member’s service history record on Vision to close the existing entry and add the new entry to reflect the change.  The volume of movement codes on the files received is usually highest on the Tuesdays as new joiners and returns to work mostly occur on a Monday.

Set up Leave Type permitted values and conversion values for the MOVCDEs as per the following table.  The translation in the table below must change to be the actual service codes that benefits will be using.  This will create the payroll service record and the member load of BJU3AR will create this data on the member values table for schemes with the scheme indicator of the new structure, which is currently managed by the Vendor.

Leave type permitted values

Conversion values for MOVCDE

Change of non-UK indicator

This trigger is used to determine when a member changes to or from a UK payroll and is triggered by a NONUKIND and NONUKDAT on the interface file. 

Any changes to NONUKIND and NONUKDAT should be recorded on the member's record, with historical entries also retained.  The NON-UK indicator – this is to create the offshore service in the payroll component and for the member load to store this data on the member values table for the benefits process to reference.

Maternity leave

This trigger is used to determine when a member changes from statutory maternity or adoption leave to company or unpaid maternity or adoption leave and to update the Service History accordingly. 

The end of statutory maternity leave is notified to UK Pension Administration as an SMPDTE on the Interface 1 basic file.  When this occurs create a service record equal to AMB.