Using the Always Recalculate Option
The Always Recalculate option on the earning and deduction Name page (GP_PIN) applies at the element level, not the instance level. For example, if you set the Always Recalculate option to Yes for an instance of a deduction with a user field value of State = California, you cannot set the option to No for an instance with a user field value of State = New York. If an earning or deduction is set to recalculate, all resolutions from the initial calculation are replaced with resolutions resulting from the recalculation.
When the Always Recalculate option is turned on, the system updates the accumulators to which the elements contribute so that if previously calculated values change or a user field set no longer exist, the accumulators and arrears are cleared of the old values.
The examples in this topic show how the accumulators are updated.
Note: The recalculation of an earning or deduction typically results from placing the element on the process list more than once, or from multiple passes of the net pay validation process.
Example 1: Recalculation of an Element Results in a Different Number of Instances
Deduction D1 adds to accumulator AC1.
The initial balance stored in AC1 is zero (0).
The first time the system encounters D1 on the process list, it resolves the deduction three times:
|
Instance |
Resolved Amount |
User Field 1 (State) |
User Field 2 (Location) |
Slice Dates |
|---|---|---|---|---|
|
1 |
5000 |
State 1 |
Location 1 |
January 1 - January 31 |
|
2 |
1000 |
State 2 |
Location 2 |
January 1 - January 31 |
|
3 |
3500 |
State 3 |
Location 3 |
January 1 - January 31 |
For each resolution of D1, there is a corresponding accumulator instance:
|
Sequence |
Amount |
User Field 1 (State) |
User Field 2 (Location) |
Slice Dates |
|---|---|---|---|---|
|
1 |
5000 |
State 1 |
Location 1 |
January 1 - January 31 |
|
2 |
1000 |
State 2 |
Location 2 |
January 1 - January 31 |
|
3 |
3500 |
State 3 |
Location 3 |
January 1 - January 31 |
The second time D1 appears on the process list, the system generates only two resolutions:
|
Instance |
Resolved Amount |
User Field 1 (State) |
User Field 2 (Location) |
Slice Dates |
|---|---|---|---|---|
|
1 |
5500 |
State 1 |
Location 1 |
January 1 - January 31 |
|
2 |
4000 |
State 2 |
Location 2 |
January 1 - January 31 |
Note: The system does not store the result for State 3 in the Earning/Deduction Results table (GP_RSLT_ERN_DED).
This table shows how the system updates accumulator AC1:
|
Sequence |
Amount |
User Field 1 (State) |
User Field 2 (Location) |
Slice Dates |
|---|---|---|---|---|
|
1 |
5500 (5000 - 5000 + 5500) |
State 1 |
Location 1 |
January 1 - January 31 |
|
2 |
4000 (1000 - 1000 + 4000) |
State 2 |
Location 2 |
January 1 - January 31 |
|
3 |
0 (3500 - 3500 + 0) |
State 3 |
Location 3 |
January 1 - January 31 |
Example 2: Recalculation of an Element Results in the Same Number of Instances with Different User Field Sets
Deduction D1 adds to accumulator AC1.
The initial balance stored in AC1 is zero (0).
The first time the system encounters D1 on the process list, it resolves the deduction three times:
|
Instance |
Resolved Amount |
User Field 1 (State) |
User Field 2 (Location) |
Slice Dates |
|---|---|---|---|---|
|
1 |
5000 |
State 1 |
Location 1 |
January 1 - January 31 |
|
2 |
1000 |
State 2 |
Location 2 |
January 1 - January 31 |
|
3 |
3500 |
State 3 |
Location 3 |
January 1 - January 31 |
For each resolution of D1, there is a corresponding accumulator instance:
|
Sequence |
Amount |
User Field 1 (State) |
User Field 2 (Location) |
Slice Dates |
|---|---|---|---|---|
|
1 |
5000 |
State 1 |
Location 1 |
January 1 - January 31 |
|
2 |
1000 |
State 2 |
Location 2 |
January 1 - January 31 |
|
3 |
3500 |
State 3 |
Location 3 |
January 1 - January 31 |
The second time D1 appears on the process list, the system generates three resolutions, but one resolution has different user field values:
|
Instance |
Resolved Amount |
User Field 1 (State) |
User Field 2 (Location) |
Slice Dates |
|---|---|---|---|---|
|
1 |
5500 |
State 1 |
Location 1 |
January 1 - January 31 |
|
2 |
2500 |
State 2 |
Location 2 |
January 1 - January 31 |
|
3 |
2000 |
State 4 |
Location 4 |
January 1 - January 31 |
This table shows how the system updates accumulator AC1:
|
Sequence |
Amount |
User Field 1 (State) |
User Field 2 (Location) |
Slice Dates |
|---|---|---|---|---|
|
1 |
5500 (5000 - 5000 + 5000) |
State 1 |
Location 1 |
January 1 - January 31 |
|
2 |
2500 (1000 - 1000 + 2500) |
State 2 |
Location 2 |
January 1 - January 31 |
|
3 |
2000 |
State 4 |
Location 4 |
January 1 - January 31 |
|
4 |
0 (3500 - 3500 + 0) |
State 3 |
Location 3 |
January 1 - January 31 |