When configuring the Pay Summary Recalc background job, consider the following recommendations:
You should schedule the Pay Summary Recalc background job to run once a day, during off-peak hours.
You shouldn’t schedule multiple versions of the job to examine different sites. When scheduling the job, configure it to run daily and leave the Site selection list blank so that the job includes all sites when it runs.
When the job is scheduled daily, it’s often unnecessary to run it on-demand. You might only need to do so if, for example, there are changes to an employee’s employment status or work assignment that need to be reflected in their pay before the pay commit for the current pay period.
When running the job on-demand, limit its lookback period to ensure optimal performance.
Number of Pay Periods to Examine
Depending on your needs, you might require that the job examines recent or older pay periods. Typically, you should customize the job’s lookback period based on whether you’re scheduling the job or running it on-demand.
It’s recommended that you configure the Weeks before today setting with the number equal to the length of your pay period, based on your pay group configuration. This applies to both scheduled and on-demand jobs. For example, if your organization contains monthly pay groups, enter 4 in this field to configure a 4-week lookback period.
If you’re running the job on-demand using the Date start and Date end settings, Dayforce examines the calculation period containing the effective dates rather than the date range you specify. For example, consider a job with the following configuration:
- Date start: February 6
- Date end: February 10
The organization running the job has bi-weekly pay periods and calculation periods that run in unison. One calculation period runs from February 1 to 14. Because the job’s date start and date end fall within this calculation period, the job examines the period from February 1 to 14, rather than February 6 to 10.
If you run the job for an effective period that crosses a calculation period, the job examines both calculation periods. Continuing the previous example: the second calculation period for February runs from February 15 to 28. If you specify an examination start date of February 10 and an end date of February 17, the job examines both February 1 to 14 and February 15 to 28 (that is, the whole month of February).
Scheduled Job
When scheduling the background job, configure it to run for the current and previous pay periods:
- In the Weeks before today field, enter the number of weeks in your pay period. For example, if your pay period is equal to two weeks, enter 2. When this field is configured in this manner, Dayforce always includes your most recent pay period when calculating changes.
- In the Weeks after today field, enter 0. This represents the current pay period.
On-Demand Job
To examine a short period in the past when running the job on-demand, configure the Weeks before today field with the appropriate value, and enter a negative value in the Weeks after today field to define a specific lookback period for the job. For example, to only examine the 12th week in the past, configure the fields as follows:
- Weeks before today: 12
- Weeks after today: -11
Alternatively, you can specify dates in the Date start and Date end field to examine a specific calculation period. Remember that Dayforce examines the calculation period that contains the dates you enter in these fields, rather than the specific duration of dates you specify.
When running the background job on-demand, you might require that the job examines a large number of weeks in the past. It isn’t recommended that you run the job on a single ad hoc basis for a large number of weeks, because the likelihood of the job engine miscalculating data is increased when it examines a large quantity of data.
To examine a larger number of weeks on-demand, you should configure the job to run a few times in manageable segments, equal in length to your pay period. For example, say you want the job to examine the last 16 weeks, or four pay periods. You should run the job four times on-demand, with the following cascading lookback period configuration that examines 4-week segments:
- Pay Summary Recalc 1:
- Weeks before today: 16
- Weeks after today: -12
- Pay Summary Recalc 2:
- Weeks before today: 12
- Weeks after today: -8
- Pay Summary Recalc 3:
- Weeks before today: 8
- Weeks after today: -4
- Pay Summary Recalc 4:
- Weeks before today: 4
- Weeks after today: 0
It’s recommended that you limit the scope of the Pay Summary Recalc background job (that is, the locations, pay groups, and employees considered when the job engine runs) based on whether you’re scheduling the job or running it on-demand, as follows:
| Job Type | Considerations |
|---|---|
| On-Demand |
|
| Scheduled |
|
Further, consider how you should configure the following settings:
| Setting | Considerations |
|---|---|
| Recalculate transmitted periods | When this checkbox is selected, Dayforce recalculates pay periods that fall within the specified time range, even if they’ve already been transmitted. |
| Skip attendance calculation |
This checkbox governs whether the job calculation includes or excludes attendance data. To avoid retro issues that might occur when recalculating attendance data from the past, it’s recommended that you enable this setting to exclude attendance data from the job’s scope. Instead, you can use the Attendance Recalc background job to recalculate the same attendance data without risking the recalculation of other records in Dayforce. See Attendance Recalc. |
| Site | When no site is specified, the job runs for the entire organization. Depending on the organization size, this can have a major impact on the job’s processing time. |
| Target scope |
This setting dictates whether the job includes or excludes changes queued for a pay summary recalculation. When left clear or when All is selected, Dayforce runs all changes for the selected period and for any past periods queued for processing by the job. When set to Strict, Dayforce runs changes only for the time range configured for the job and excludes retro changes. However, if pay for a specific week was already transmitted and changes were made to the employee’s pay, retro pay might be created when the data queued for the job is processed and the Recalculate transmitted periods setting is enabled. |
If there are performance issues when the Pay Summary Recalc background job runs in your instance of Dayforce, you can configure the job to run as a multi-threaded task in Dayforce’s database. This requires the appropriate access and an advanced understanding of Dayforce’s database.
Multi-threading can resolve some timeout and latency issues for organizations with large numbers of employees.
| Setting | Description |
|---|---|
PsrIsMultithreading
|
Due to the impact of multi-threading, it can be enabled only through a script in the database level of the client table. To enable multi-threading, set the PsrIsMultithreading field to 1. |
PsrMultithreadingBatchSize
|
Controls the size of the org that’s processed when the Pay Summary Recalc job runs. If the number of employees included in the job’s scope exceeds this number, an additional thread runs to process the additional employees. You can cater the |
RuleEngineEmployeeBatchSize
|
Dictates how many employees are saved in a batch to the database when the Pay Summary Recalc job runs. |