Important Notices and Breaking Changes v12.30

The enhancements described in the related pages below represent significant functional changes that you must be aware of prior to upgrading to this release. Some of these enhancements require specific actions before or immediately after upgrading and are therefore highlighted here for your reference. Please refer to the relevant sections of this What’s New Guide, as identified below, for detailed information about each enhancement and any configuration that is required.

Inclusion of all prior, unprocessed transactions in first pay run

A change has been made in this release whereby when a Normal pay batch is created in the Payroll module, the pay batch will, by default, include unpaid/unprocessed transactions for payees who belong to the pay group of the pay batch irrespective of whether the transactions belong to the following:

• the current (open) pay period

• a prior (closed) pay period.

Because of this, it is important to note that when the first Normal pay batch is processed for a pay group after upgrading, the pay batch could include historic, unprocessed transactions for prior periods.

Leave Reset Rules

As part of the configuration of Leave Types in the Leave module, Reset Rules can be configured to reset the accrual or entitlement balance of the leave and when and how the reset is to occur. Previously, Reset Rules could be configured to reset leave balances at:

• in a pay batch

• in a pay batch on termination only

• when the Leave Service runs.

The first of the abovementioned options has been removed in this release any existing Reset Rules that were configured to rest in a pay batch will default to reset on running of the Leave Service. For more information, see Removal of Reset at Pay Batch Leave Reset Rule.

Attribution of Percentage Based Leave Accruals

A change has been made in this release whereby the job order and client that corresponds to a percentage-based leave accrual, where applicable, will be recorded in the leave accrual transaction details so the cost of the accrual will be attributed to the agency office to which the job order belongs and not the agency office that manages the candidate. For more information, see Attribution of Percentage Based Leave Accruals to Job Order/Client.

Payout of Leave at Termination of Employment

If a payee is eligible to be paid out the balance of unused leave at termination of employment and the payee’s employment type has changed during the course of their employment, please be aware that the balance of leave that is available to be paid out at termination is based on leave accrued based on their current employment type.

Therefore, it is recommended that if it is necessary to change a payee’s employment type and the payee is eligible to receive a payout of unused leave at termination of employment, that the payee’s leave balance be adjusted manually (i.e. at the Leave Accrual stage of a pay batch) before the payee’s employment is terminated to ensure that the leave balance that is available to pay out at termination factors in the accrual prior to the change in employment type.

Negation of Leave Accrual Top-up

An enhancement has been made in this release whereby a leave accrual will be topped up at the Leave Payments pay batch stage in the Payroll module to factor for leave that accrues based on leave taken in the same pay batch (for more information, see Top-up and Recalculation of Leave Accruals). A known issue exists whereby if a subsequent pay batch is processed for the same pay period, any accrual top-up that was triggered in the previous pay batch for that period will be negated. Because of this, any leave that should have accrued on leave taken transactions that were processed in the prior pay batch for the same pay period will not be factored into a payee’s leave accruals automatically. Therefore, if multiple pay batches must be processed for the same pay period, manual leave accrual adjustments might be required to factor in any accrual that should have occurred on leave taken.

Database Schema Breaking Changes for Stimulsoft Reports

A new intermediary database table has been added in this release that will impact any custom Stimulsoft report that relies on a join between the rar.GrossWageBatch and rar.GrossWageBatchPayee database tables. For more information about this change and other database schema changes that may affect existing custom reports, see Database Schema Changes V12.30.

API Breaking Change and Known Issues

This release requires v330 of the API due to a breaking change that makes earlier versions of the API incompatible. Note that there is no functional change to the APIs. However, the new version of the API is required due to the removal of a dependency that affects the Payee API.

The following are also known issues that you must be aware of when consuming the APIs:

1. The Get/UK/payee API does not return the latest HMRC validity period when attempting to retrieve the details of an individual payee. The wrong validity ID is returned and therefore the data retrieved does not correspond to the latest HMRC validity period.

2. The Get/UK/payee API does not return the correct value for the payslipDeliveryMethodId field.

3. The Patch/UK/payee API fails to recognise valid values for the payslipDeliveryMethodId field and therefore any Patch call that includes that field fails to update the corresponding payee record.