Add Additional Data for Sickness Absences

It is possible that an absence that needs to be migrated is linked to one or more previous absences.

In such a case, there are two possibilities:

You can migrate all the absence records for the entire chain.

Migrate only the last absence in the chain. In this case, additional information is required for that absence (see below). When using this migration option, you should bear in mind:

If the start date of the first absence record is changed the override information will be lost.

You should ensure that the transition date is before the start date of the earliest absence being loaded. It is suggested that a date of 1-Jan-1951 is used.

For customer currently using SSP solution the transition date will be when you want to start processing in the new way.

You must set up absences including type, plan, and elements with an effective date earlier than the date of the first absence to be migrated.

Additional data entry is available specifically for data migration and is located on the Absence Case page in the legislative information area.

If you don't wish to enter the overrides for each individual entry through the UI you can use the HDL functionality, you will need to:
  1. Load the absences into the application. This will then automatically create any SSP cases that are required.
  2. Next, identify the case reference that requires the override fields updated and use the case reference for an HDL upload to the override fields in the associated cases.

Additional Data Fields:

Field Name Description
Disable earnings check Set this to yes if you require no earnings check to be done.
Consumed Waiting days When you use a single absence for migration then this field describes the number of waiting days that have already been used by previous absences. The days will be processed in this migrated absence.
Consumed SSP Weeks If the employee has consumed SSP entitlement before the migrated absence record, then it is specified here. It is used to calculate the 28 weeks limit.
Original Start Date If the sickness has a long history of linked absences that aren't migrated, provide the start date of the first linked absence. It is used to calculate the 3 years limit and overrides the application determined value.
Disqualified Reason If the employee was not entitled to SSP for the absence being migrated, enter the certificate name that indicates the reason for disqualification. For example, LEL not reached or On Strike.
Number of Normal Scheduled Days for First Week If the employee has an absence during the first week of hire the application is unable to ensure the normal schedule. The user can enter here the number of days for the employees normal schedule.
Disable Earnings Check If you select this check box, the application does not check against the lower earnings limit (LEL), and assumes that the LEL is exceeded. Use this to bypass the LEL check for periods where payment data is not available.

It is possible that some of the existing absence payments were manually stopped in your legacy application by manual intervention from an administrative user. If the reason for nonpayment cannot be automatically detected by the process, the reason needs to be indicated in the Disqualifying Reason field. You can do this in mass using the HCM Data Loader (HDL). The following examples show how you can handle these scenarios:

An absence record was found ineligible for SSP payment because the employee’s average weekly earnings did not reach the LEL. Later, the administrative user found that a mistake was made in the employee’s salary and updated the absence to be paid. In this example, select the check box Disable Earnings Check.

An employee was taken into legal custody while on sick leave. For this reason, the absence payment was stopped. The Disqualified Reason needs to be set to “Taken into Legal Custody”.

For further information on how to use those additional fields, see Setting Up and Migrating UK Statutory Absences (Document ID 2234239.1), UK Statutory Absences Migration Document.