Understanding General Rules of Retro Processing
This topic provides an example of a retroactive calculation and discusses how Absence Management:
Tracks recalculated calendars.
Loads balance accumulators.
Stores recalculated results.
Set backward and forward limits.
In this example, Earning 1 rate changes from 100 to 120; effective date is in period 1; notified in period 2:
|
Recalc Option |
Calendar Period 1 |
Prior Results (Old Value) |
Re-Calculation (New Value) |
Deltas |
Corrective Replace Old Value with New Value |
Forward Y/N |
|---|---|---|---|---|---|---|
|
Always |
Earning 1 |
100 |
120 |
20 |
Y |
N |
|
Always |
Deduction 1 (flat amount) |
30 |
30 |
0 |
Y |
N |
This table shows the processing results for the example above:
|
Calendar Period 2 |
Current Results |
Retro Adjustment |
|---|---|---|
|
Earning 1 |
120 |
None |
|
Deduction 1 (flat amount) |
30 |
None |
In this example, only Earning 1 generates a retro delta. The new value of Earning 1 replaces its old value.
Absence Management tags each Payee Process Stat Record with a version number to track the recalculation of a calendar period due to retroactivity.
The system defines the original set of output results for a calendar calculation as Version 1, Revision 1 (V1R1). Each subsequent recalculation increments the version number by 1. The revision number stays the same. For example, the first corrective retro is Version 2, Revision 1 (V2R1). The second corrective retro (retro on retro) is Version 3, Revision 1 (V3R1), and so forth.
The system uses these numbers to determine which calculations to use as the old and new values when processing retro deltas.
Version and Revision Numbers in Retro Adds
A retro add is a situation in which a previous calculation does not exist for a payee, and retroactivity calls for a payee process status record to be created for the first time. For example, suppose that a payee initially thought to have been hired in February was actually hired in January. There are no calculations for January, so when January is processed for retro, the system must create a payee process status record for the period and assign version and revision numbers to it. In this case, the first calculation is labeled V1R1. The reason is that corrective retro replaces the results of the prior calculation (it does not use them only to create retro deltas), so when a period is added, it treats this period as if it were the original one.
The following tables illustrate how the system numbers payee process status records in retro add situations:
Scenario:
In the following retro add situation, it is discovered that a payee who was calculated as part of period 1 should not have been processed in that period. The calculations for the payee are therefore reversed in Recalc No. 2. When it is later discovered that the payee belongs in that period after all, the system produces a new calculation using the version and revision numbers that are indicated in Recalc No. 3.
|
Period/Recalculation |
Numbering |
|---|---|
|
Period 1 (original calculation) |
V1R1 |
|
Recalc No. 1 |
V2R1 |
|
Recalc No. 2 (reversal) |
V3R1 |
|
Recalc No. 3 (add) |
V4R1 |
In each example, all calculations for the payee are reversed in Recalc No. 2 when the payee is eliminated from the calendar. When the payee is later restored (when it is discovered that he or she belongs in the original calendar), new calculations are created. The new calculation uses the numbering that is indicated in Recalc No. 3.
Before the system recalculates elements during retro, it loads balances to produce the correct value for the balance accumulators.
The system loads the balance for the element from the calculation with the highest version number in the previous period.
When a trigger starts retroactive processing for a payee, the system recalculates each calculation that is generated for the payee from the date of retroactivity forward. The system compares the recalculated results to the original results. If there is a difference between them, the system:
Stores prior results for auditing purposes.
Replaces the prior results with new ones in the recalculated period and stores the new calculation results for each payee.
These results represent the true results for that period.
In Absence Management, you use the Pay Entity Retro Limits page to establish default backward and forward limits for retro processing. These defaults tell the system how far back in time to go to recalculate closed calendars that are associated with a pay entity, and how long after a payee becomes inactive he/she is eligible for retro processing.
To determine how far back in time to go to process retroactivity, the system compares the backward limit defined on the Pay Entity Retro Limits page to the following system dates:
Trigger Effective Date.
This date—the effective date of the change that triggers retroactive processing—establishes a theoretical goal for how far back in time to go to recalculate data. When the system determines which periods to process, the backward limit date takes precedence over the trigger effective date. For example, if the trigger effective date is January 1, 1990, and the backward limit date is January 1, 1995, the backward limit date stops all calculations prior to (and including) that date. By contrast, if the backward limit date is January 1, 1990, and the trigger effective date is January 1, 1995, then the trigger effective date establishes the number of periods to recalculate.
No Retro Processing Before Date.
This is the date that a payee enters the Absence Management system. This date takes precedence over the trigger effective date and the backward limit date because no matter what these dates are, there is no historical data to recalculate before the No Retro Processing Before Date.
This diagram illustrates the interaction of the dates used to determine the number of past periods to recalculate.
The Absence Management system determines the first recalculation period by comparing the trigger effective date to the backward limit date and comparing both dates to the calculation begin date.
The process for determining forward limits is less complex than for backward limits, because the system does not compare trigger effective dates to either the forward limit or the No Retro Processing Before Date. It only needs to determine whether payees are within the forward limits defined on the Pay Entity Retro Limits page. If a payee is within these limits, the system applies the backward limits to determine the number of past periods to recalculate.
For forward limits to apply, a payee must be inactive in all jobs (EMPL_STATUS on the Job record is used to validate the payee's status). A payee is considered inactive if the EMPL_STATUS value is D (deceased), R (retired), T (terminated), V (terminated pension payout), or X (retired-pension administration). If a payee has multiple jobs, the highest effective date of all rows that are returned is used as the inactive date.