Understanding General Rules of Retroactive Processing
This topic provides examples of the delivered retroactive calculation methods, and discusses how Global Payroll:
Tracks recalculated calendars.
Calculates retro deltas and processes adjustments.
Loads balance accumulators.
Stores recalculated results.
Reverses previous results.
The examples of corrective and forwarding retro in this topic illustrate the basic difference between the two methods: in corrective retro, the recalculated values of elements in the pay run replace the previous calculations, while in forwarding retro, the system uses the recalculated values to compute retro deltas, and then carries the deltas forward as adjustments to elements in the current period.
Example 1: Corrective Retro—No Exceptions
In this example, Earning 1 rate changes from 100 to 120; effective date is in period 1; notified in period 2:
Re-Calc 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 |
Not applicable |
Net Pay (segment accumulator) |
70 |
90 |
Y |
N |
|
Not applicable |
YTD Accumulator Earning 1 |
100 |
120 |
This table shows the processing results:
Calendar Period 2 |
Current Results |
Retro Adjustment |
---|---|---|
Earning 1 |
120 |
None |
Deduction 1 (flat amount) |
30 |
None |
Net Pay |
90 |
None |
YTD Accumulator Earning 1 |
240 |
In this example, only Earning 1 generates a retro delta. The segment accumulator (Net Pay) is updated. No element is forwarded for processing in the current period, and the new value of Earning 1 replaces its old value. The banking process determines the difference between the net pay from the prior calculation (70) and the recalculation (90) and manages the retro delta (20).
Example 2: Forwarding Retro—No Exceptions
In this example, Earning 1 rate change from 100 to 120; effective date in period 1; notified in period 2:
Re-Calc 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 |
Not applicable |
Y |
Always |
Deduction 1 (flat amount) |
30 |
30 |
0 |
Not applicable |
Y |
Not applicable |
Net Pay (segment accumulator) |
70 |
90 |
20 |
Not applicable |
N |
Not applicable |
YTD Accumulator Earning 1 |
100 |
Not applicable |
Not applicable |
Not applicable |
N |
This table shows the processing results:
Calendar Period 2 |
Current Results |
Retro Adjustment |
---|---|---|
Earning 1 |
120 |
20 |
Deduction 1 (flat amount) |
30 |
None |
Net Pay |
110 |
None |
YTD Accumulator Earning 1 |
240 |
None |
In this example, the system forwards the retro delta for Earning 1 to the current period (period 2), where it is recorded as an adjustment to Earning 1.
Even though the retro method is forwarding, the system does not forward all elements from the first period to the second period:
The system does not forward the Net Pay accumulator because it already contains the value of Earning 1.
If the Net Pay accumulator had been forwarded along with Earning 1, Earning 1 would have been counted twice in the current period.
Global Payroll does not forward balance accumulators. This is because they sum the values of elements that have potentially already been forwarded, so moving them into the current period would generate incorrect results.
Note: Even when the retro method is forwarding, Global Payroll does not forward all elements in the process list. On the Retro Process Overrides page, you must individually select the elements that you want forwarded. No element is forwarded automatically.
Global Payroll tags each Pay Process Stat record with a version and revision number appropriate to the retro method used. These version and revision numbers are the vehicles for tracking recalculation of a calendar period due to retroactivity.
Note: We discuss the Pay Process Stat record in the topic on system architecture.
See Batch Processing Output Tables.
The system defines the original set of output results for a calendar calculation as Version 1, Revision 1 (V1R1). Each subsequent recalculation of the calendar increases either the version number or the revision number depending on the retro method:
Field or Control |
Definition |
---|---|
Corrective Retro |
When the retro method is corrective, the version number increases by 1 and the revision number stays at 1. 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. |
Forwarding Retro |
When the retro method is forwarding, the version number stays the same and the revision number increases by 1. For example, the first forwarding retro is Version 1, Revision 2 (V1R2). The second forwarding retro (retro on retro) is Version 1, Revision 3 (V1R3), 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 Used When Calculating Retro on Retro
When the system calculates retro on retro—that is, when a period is recalculated more than once—and the retro method changes, the numbering scheme becomes more complicated. In the following example, Global Payroll recalculates five consecutive periods using the forwarding method on the first pass, and a combination of forwarding and corrective retro on the second pass.
Scenario:
The retro method changes from corrective to forwarding in period 3 when retro is first processed. The second time that retro is processed, the method changes from forwarding to corrective in the same period.
In the following table, P1 to P6 represent periods 1 to 6.
Description |
P1 |
P2 |
P3 |
P4 |
P5 |
P6 |
---|---|---|---|---|---|---|
Version and revision number for original calculation. |
V1R1 |
V1R1 |
V1R1 |
V1R1 |
V1R1 |
V1R1 |
Initial recalculation method changes from corrective to forwarding in period 3. |
Corrective |
Forwarding |
||||
Version and revision numbers for initial recalculation. |
V2R1 |
V2R1 |
V1R2 |
V1R2 |
V1R2 |
V1R2 |
Recalculation method changes from forwarding to corrective in period 3. |
Forwarding |
Corrective |
||||
Second recalculated version and revision numbers. |
V2R2 |
V2R2 |
V2R1 |
V2R1 |
V2R1 |
V2R1 |
When forwarding follows corrective retro, the revision number increases by 1, and the version number remains the same as it was in the last maximum corrective run. However, when corrective retro follows forwarding, the version number increases by 1, and the revision number goes back to 1. This has important consequences for how the system calculates retro deltas.
Version and Revision Numbers in Retro Adds
A retro add is a situation in which a previous gross-to-net does not exist for a payee, and retroactivity calls for a Pay Process Stat 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 is no gross-to-net for January, so when January is processed for retro, the system must create a Pay Process Stat record for the period and assign version and revision numbers to it.
The system assigns version and revision numbers as follows:
Numbering retro adds when the retro method is forwarding.
When the retro method is forwarding, the revision number must be greater than 1. If a previous gross-to-net calculation does not exist, and a retro add results in a gross-to-net for the first time, the system labels this calculation V1R2 even though it is technically the first gross-to-net. The reason for this is that forwarding retro does not replace the original results of a calculation with new ones, but uses them to generate retro deltas. V1R2 is created only to calculate the deltas to bring forward to the current period. V1R1 is not used because it does not contain the true results for the period.
Numbering retro adds when the retro method is corrective.
When the retro method is corrective, a previous gross-to-net does not exist, and a retro add results in a gross-to-net for the first time, the system labels this first calculation V1R1. The reason for this is that corrective retro replaces the results of the prior pay 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 Pay Process Stat records in retro add situations using forwarding and corrective retro.
Scenario:
In the following retro add situations, it is discovered that a payee who was calculated in 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 gross-to-net calculation using the version and revision numbers associated with Recalc No. 3:
Example 1
Period/Recalculation |
Retro Method |
Numbering |
---|---|---|
Period 1 (original calculation) |
Not applicable |
V1R1 |
Recalc No. 1 |
Corrective |
V2R1 |
Recalc No. 2 |
Reversal (corrective) |
V3R1 |
Recalc No. 3 |
Add (corrective) |
V4R1 |
Example 2
Period/Recalculation |
Retro Method |
Numbering |
---|---|---|
Period 1 (original calculation) |
Not applicable |
V1R1 |
Recalc No. 1 |
Corrective |
V2R1 |
Recalc No. 2 |
Reversal (corrective) |
V3R1 |
Recalc No. 3 |
Add (forwarding) |
V3R2 |
Example 3
Period/Recalculation |
Retro Method |
Numbering |
---|---|---|
Period 1 (original calculation) |
Not applicable |
V1R1 |
Recalc No. 1 |
Forwarding |
V1R2 |
Recalc No. 2 |
Reversal (forwarding) |
V1R3 |
Recalc No. 3 |
Add (forwarding) |
V1R4 |
Example 4
Period/Recalculation |
Retro Method |
Numbering |
---|---|---|
Period 1 (original calculation) |
Not applicable |
V1R1 |
Recalc No. 1 |
Forwarding |
V1R2 |
Recalc No. 2 |
Reversal (forwarding) |
V1R3 |
Recalc No. 3 |
Add (corrective) |
V2R1 |
This topic provides information about how the system calculates retro deltas and processes adjustments.
Calculating Retro Deltas
In forwarding retro, the Delta = New Value - Old Value (where the old value is the value from the last revision of the previous calculation [maximum revision]).
Period 1 |
Value of Earning 1 (E1) |
Delta |
---|---|---|
V1R1 |
20 |
Not applicable |
V1R2 |
30 |
E1 (V1R2) - E1 (V1R1) = 10 |
V1R3 |
40 |
E1 (V1R3) - E1 (V1R2) = 10 |
In corrective retro, the Delta = New Value - Old Value (where the old value is the value from the previous version, Revision 1).
Period 1 |
Value of E1 |
Delta |
---|---|---|
V1R1 |
20 |
Not applicable |
V2R1 |
30 |
E1 (V2R1) - E1 (V1R1) = 10 |
V3R1 |
40 |
E1 (V3R1) - E1 (V2R1) =10 |
When calculating deltas, the system includes in the old value of an element (earning or deduction) any adjustments that were forwarded to it from recalculated periods. Similarly, the new value of an element calculated for the current period includes adjustments that were forwarded to it as a result of a recalculation in previous periods.
Period 1 |
Value of E1 |
Delta |
---|---|---|
V1R1 |
25 (20 + 5 Adjustment) |
Not applicable |
V1R2 |
35 (30 + 5 Adjustment) |
E1 (V1R2) - E1 (V1R1) = 10 |
V1R3 |
45 (40 + 5 Adjustment) |
E1 (V1R3) - E1 (V1R2) = 10 |
Note: There is an exception to the rule that the new value of an element always contains adjustments that were forwarded to that element when it was calculated in a previous run. This exception is discussed in Example 3 under Deltas and Adjustments When The Retro Method Changes.
Calculating Deltas When Corrective Follows Forwarding
In the case of corrective retro—or when corrective follows forwarding—the system defines the old value as the previous version, Revision 1. Take the following example of a period which is recalculated twice due to retro—first using forwarding retro, and again using corrective retro. If the value of earning E1 equals 20 in period 1 (V1R1), increases to 30 in the first recalculation (V1R2), and increases again to 40 in the last recalculation (V2R1), the system derives the deltas as follows:
Retro Method |
Period 1 |
Value of E1 |
Delta |
---|---|---|---|
Not applicable |
V1R1 |
20 |
Not applicable |
Forwarding |
V1R2 |
30 |
E1 (V1R2) - E1 (V1R1) = 10 |
Corrective |
V2R1 |
40 |
E1 (V2R1) - E1 (V1R1) = 20 |
To calculate the second retro delta in V2R1, when the retro method changes from forwarding to corrective, the system subtracts the value of E1 in the previous version, revision 1 (20) from the new value of E1 (40). It ignores E1 in V1R2 (the previous version, Revision 2) because V1R2 is a virtual calculation and doesn't represent the last true value.
Processing Adjustments
When the retro method is forwarding, the system calculates the adjustment to carry forward by summing the deltas for an element across all of the recalculated periods. If you have defined payment keys, the system sums the calculated deltas by payment key rather than creating a single adjustment amount.
Example 1: Processing Deltas and Adjustments in Forwarding Retro
The following example of retro on retro illustrates how the system calculates deltas and processes adjustments when using the forwarding method.
Scenario:
In period 2, E1 changes from 10 to 20. The first retro calculation involves retro in period 2 back to period 1.
In period 3, E1 changes from 20 to 30. The second retro calculation involves retro in period 3 back to period 1.
Ver/ Rev # |
Load YTD Balances (load year-to-date balances) |
Period 1 |
Load YTD Balances |
Period 2 |
Load YTD Balances |
Period 3 |
---|---|---|---|---|---|---|
V1R1 |
Load 0 |
E1 = 10 |
Load 10 |
E1 = 30 (20 + 10) |
Load 40 |
E1 = 50 (30 + 0 + 10) |
Net Pay = 10 |
Net Pay = 30 |
Net Pay = 50 |
||||
YTD E1 = 10 |
YTD E1 = 40 |
YTD E1 = 90 |
||||
V1R2 |
Load 0 |
E1 = 20 Delta = 10 |
Load 10 |
E1 = 40 (30 + 10) Delta = 10 |
||
YTD E1 = 10 |
YTD E1= 40 |
|||||
V1R3 |
Load 0 |
E1 = 30 Delta = 10 |
||||
YTD E1 = 10 |
In this example, the system calculates retro deltas by subtracting the old value of E1 from the new value of E1 (the old value is defined as the last revision of the previous calculation).
First retro calculation:
Period 1 (V1R2): E1 = 20.
Delta = 10 [20 (V1R2) - 10 (V1R1)]. Pulled in to period 2 (V1R1) as an adjustment.
Period 2 (V1R1): E1 = 30 (20 + 10 Adj). Adjustment from period 1 (V1R2).
Second retro calculation (retro on retro):
Period 1 (V1R3): E1 = 30.
Delta = 10 [30 (V1R3) - 20 (V1R2)]. Pulled in to period 3 (V1R1) as an adjustment.
Period 2 (V1R2): E1 = 40 (30 + 10 Adj). Adjustment carried forward from period 2 (V1R1).
Delta =10 [40 (V1R2) - 30 (V1R1)]. Pulled in to period 3 (V1R1) as an adjustment.
Period 3 (V1R1): E1 = 50 (30 + 10 Adj + 10 Adj). Adjustments from period 1 (V1R3) and period 2 (V1R2).
The adjustment is the sum of all retro deltas. In P2 (V1R1), the adjustment to E1 is 10. In P3 (V1R1), the adjustment to E1 is the sum of the adjustments from the recalculation of periods 1 (V1R3) and 2 (V1R2), or 10 + 10.
Note: Because periods 1 and 2 are processed using forwarding retro, the YTD accumulator is not updated each time these periods are recalculated. When the balances are loaded before each recalculation, the system uses the YTD balance from the prior period, V1R1. Revision 1 is always loaded when the method is forwarding.
Example 2: Processing Deltas in Corrective Retro
The following example of retro on retro illustrates how the system calculates deltas when using the corrective method.
Scenario:
In period 2, E1 changes from 10 to 20. The first retro calculation involves retro in period 2 back to period 1.
In period 3, E1 changes from 20 to 30. The second retro calculation involves retro in period 3 back to period 1.
Version/ Revision Number |
Load YTD Balances |
Period 1 |
Load YTD Balances |
Period 2 |
Load YTD Balances |
Period 3 |
---|---|---|---|---|---|---|
V1R1 |
Load 0 |
E1 = 10 |
Load 20 |
E1 = 20 |
Load 60 |
E1 = 30 |
Net Pay = 10 |
Net Pay = 20 |
Net Pay = 30 |
||||
YTD E1 = 10 |
YTD E1 = 40 |
YTD E1 = 90 |
||||
V2R1 |
Load 0 |
E1 = 20 Delta = 10 |
Load 30 |
E1 = 30 Delta = 10 |
||
Net Pay = 20 |
Net Pay = 30 |
|||||
YTD E1 = 20 |
YTD E1 = 60 |
|||||
V3R1 |
Load 0 |
E1 = 30 Delta = 10 |
||||
Net Pay = 30 |
||||||
YTD E1 = 30 |
In this example, the system calculates retro deltas by subtracting the old value of E1 from the new value of E1 (the old value is defined as the value of the previous calculation [previous version, Revision 1]). The deltas of E1 are not marked for forwarding.
There are no adjustments to the value of E1 (as in forwarding retro) because corrective retro replaces the old value with the new value.
First retro calculation:
Period 1 (V2R1): E1 = 20
Delta = 10 [20 (V2R1) - 10 (V1R1)]. New value replaces old value.
Net Pay = The banking process determines if any difference exists between the net pay from the prior calculation and the recalculation. In this instance, the difference is 10.
Second retro calculation (retro on retro):
Period 1 (V3R1): E1 = 30.
Delta = 10 [30 (V3R1) - 20 (V2R1)]. New value replaces old value.
Net Pay = The banking process determines if any difference exists between the net pay from the prior calculation and the recalculation. In this instance, the difference is 10.
Period 2 (V2R1): E1 = 30.
Delta = 10 [30 (V2R1) - 20 (V1R1)]. New value replaces old value.
Net Pay = The banking process determines if any difference exists between the net pay from the prior calculation and the recalculation. In this instance, the difference is 10.
Note: Because periods 1 and 2 are processed using corrective retro, the YTD accumulator is updated each time a period is recalculated. When balances are loaded before each recalculation, the system uses the balance from the calculation with the highest version number, Revision 1 in the previous period.
Example 3: Processing Deltas and Adjustments When the Retro Method Changes
When calculating retro deltas, the system generally defines the new value of an element as containing the same adjustments as the old value. However, when a period is processed using forwarding retro and reprocessed using corrective retro (the retro method changes from forwarding to corrective), the procedure for calculating deltas becomes more complicated.
This example shows what happens when the method for calculating retroactivity changes from forwarding to corrective.
Scenario:
Retro in period 3 back to period 1 due to a change in E1 from 10 to 30. Retro method is forwarding.
Retro in period 4 back to period 2 due to a change in E1 from 30 to 40. Retro method changes to corrective for period 2 and then back to forwarding for period 3. E1 is defined as a forwarding exception (it is forwarded to E2 in period 4).
Version / Revision Number |
Period 1 |
Method |
Period 2 |
Method |
Period 3 |
Period 4 |
---|---|---|---|---|---|---|
V1R1 Forwarding |
E1 = 10 |
E1 = 10 |
E1 = 70 (30 + 20 + 20) |
E1 = 30 (40 - 10) E2 = 30 |
||
V1R2 Forwarding |
E1 = 30 Delta = 20 |
E1 = 30 Delta = 20 |
||||
V2R1 Method Corrective |
E1 = 40 Delta = 30 |
V1R2 Method Forwarding |
E1 = 60 (40 + 20) Delta = <10> |
First retro calculation:
Period 1 (V1R2): E1 = 30.
Delta = 20 [30 (V1R2) – 10 (V1R1)]. Pulled in to period 3 (V1R1) as an adjustment.
Period 2 (V1R2): E1 = 30.
Delta = 20 [30 (V1R2) - 10 (V1R1)]. Pulled in to period 3 (V1R1) as an adjustment.
Period 3 (V1R2): E1 = 70 (30 + 20 Adj + 20 Adj). Adjustments from period 1 (V1R2) and period 2 (V1R2).
Second retro calculation (retro on retro):
Period 2 (V2R1): E1 = 40.
Delta = 30 [40 (V2R1) - 10 (V1R1)]. Pulled in to period 4 (V1R1) as an adjustment to E2.
Period 3 (V1R2): E1 = 60 (40 + 20 Adj). Adjustment carried forward from period 1 (V1R1).
Delta = <10> [60 (V1R2) - 70 (V1R1)]. Pulled in to period 4 (V1R1) as an adjustment.
Period 4 (V1R1): E1 = 30 (40 - 10 Adj). Adjustments from period 3 (V1R2) and E2 = 30 adjustment from Period 2 (V2R1).
In this example, the first retro calculation in period 2 involves a change in the value of E1 from 10 to 30, resulting in a delta of 20. When period 2 is recalculated using corrective retro, the value of E1 increases from 30 to 40. Note that the system does not calculate the new delta as 40 (E1, V2R1) - 30 (E1, V1R2), as it would if the method were forwarding, but as 40 (E1, V2R1) - 10 (V1R1). This is because the old value in corrective retro is defined as the previous calculation (previous version, Revision 1), not as the previous revision.
This creates the following problem, which the system must resolve:
The first retro calculation results in a delta of 20 being forwarded to period 3.
The second, corrective calculation results in a delta of 30 being pulled into period 4. This delta includes not just the difference between the value of E1 in V2R1 (40) and the previous value of E1 in V1R2 (30), but the already forwarded difference between the value of E1 in V1R2 and V1R1 (30 - 10 = 20). Consequently this difference (20) is counted twice.
How does the system compensate for this? The answer depends on how the delta for period 3 is recalculated. The new value of an element is normally defined as containing the same adjustments as those in the old value. However, when the retro method changes from forwarding to corrective, the delta that appears to be "double-counted" (the delta from period 2 V1R2 in this example) is not included in the new value of E1 when the period to which it was forwarded is recalculated. When the system calculates the delta for period 3, the new value does not contain the adjustment to E1 from period 2, V1R2, but only the adjustment from period 1, V1R2.
Before the system recalculates elements during retro, it loads balances to produce the correct value for the balance accumulators. The rule used to load balances varies depending on whether you are using forwarding or corrective retro.
If you're using forwarding retro, the system loads the balance for the element that is being recalculated from the previous period, V1R1.
Using Example 1, presented earlier (see Calculating Retro Deltas and Processing Adjustments):
Period 1 (V1R1): The system loads a balance of 0 for E1 (this is the first period, and E1 has not yet been calculated).
Period 2 (V1R1): The system loads the YTD balance of E1 (10) from period 1 (V1R1).
Period 3 (V1R1): The system loads the YTD value of E1 (40) from the period 2 (V1R1).
If your method is corrective, the system loads the balance for the element from the calculation with the highest version number in the previous period.
Using Example 2, presented earlier (see Calculating Retro Deltas and Processing Adjustments):
Period 1 (V1R1): The system loads a balance of 0 for E1 (this is the first period, and E1 has not yet been calculated).
Period 2 (V1R1): The system loads the YTD balance for E1 (20) from the calculation with the highest version number in period 1 (V2R1).
Period 2 (V2R1): The system loads the YTD balance for E1 (30) from the calculation with the highest version number in period 1 (V3R1).
Period 3 (V1R1): The system loads the YTD balance for E1 (60) from the calculation with the highest version number in period 2 (V2R1).
During retroactive processing the system recalculates each payment 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, regardless of the method.
Stores the new calculation results for each payee. If the retro method is corrective, the system replaces the prior results with new ones in the recalculated period. These results represent the true results for that period. If the retro method is forwarding, these results do not represent the true value but a virtual value.
Stores retro deltas for earnings and deductions for each segment in GP_RSLT_DELTA, in the recalc period in which they were generated by the calendar group ID that recalculated the calendar ID.
Stores segment accumulator deltas that are defined to be forwarded.
Note: All earning and deduction deltas are stored, regardless of the method used. Accumulator deltas aren't stored unless they are defined to be forwarded (and only segment accumulators can be forwarded).
There are several situations in which the system does not calculate retro deltas by subtracting old values from new values. In these situations, to calculate the deltas, the system reverses the old results and cancels prior calculations. The system adds the resulting negative values to any new values that may have been generated for the period (as long as they share the same payment keys) and moves the results to the current period (if the retro method is forwarding).
Reversal occurs when:
The segment dates of the recalc period don't match those of the prior period.
The payment keys of the recalc period/segments don't match those of the prior period/segments.
In this case, the system sums deltas by payment key (that is, only deltas with the same payment keys are summed) before forwarding them to the appropriate slice or segment in the current period.
A payee who was calculated as part of a calendar is later discovered to not belong in the calendar.
In this case, the system reverses prior calculations for the payee. For example, this could occur in a retroactive transfer situation in which a payee is transferred in January, but the transfer is not recorded until February. The January period would need to be reversed entirely.
Following is an example of a related situation that requires a more selective reversal of prior results:
A retroactive calculation takes place on a calendar period that had adjustments for a payee's earnings pulled into it from previous periods (so that the payee received adjustments in addition to his or her current pay). Later, the payee must be reversed out of this calendar. In such a situation, you might need to preserve the adjustments that were forwarded to the calendar that is being reversed because those adjustments came from a calendar that is not being reversed. The system has been programmed to recognize situations like this and preserves the forwarded adjustments.
In Global Payroll, 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 Global Payroll 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.
Image: Interaction of dates used to determine the number of past periods to recalculate
This diagram illustrates the interaction of the dates used to determine the number of past periods to recalculate.
![Interaction of dates used to determine the number of past periods to recalculate](img/i-cd7d26dn-6d5d.png)
The Global Payroll 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.