Defining Retroactive Processing Considerations
This topic discusses:
Grouping deltas using user field levels.
Processing Retroactive Overrides — Forwarding Options.
Forwarding deltas with user fields and user field levels.
Managing unprocessed retroactive deltas.
Defining the retroactive recalculation option.
Slice mismatches.
Global Payroll enables you to group or separate deltas for an earning or deduction based on matching user field sets. You control the level of matching needed to group deltas for an element by defining the match requirements—that is, you can require matching on the first user field only before deltas can be grouped, on both the first and second user fields, on the first, second, and third user fields, and so on.
To control how the system groups retroactive deltas for forwarding to the current period, select one of the following user field levels when you define an earning or deduction element:
|
User Field Level |
Description |
|---|---|
|
None |
Element level grouping (all deltas combined regardless of differences between user field sets) |
|
Group through User Field 1 |
Partial set (only User Field 1 must be identical to combine deltas) |
|
Group through User Field 2 |
Partial set (only User Fields 1 and 2 must be identical to combine deltas) |
|
Group through User Field 3 |
Partial set (only User Fields 1, 2, and 3 must be identical to combine deltas) |
|
Group through User Field 4 |
Partial set (User Fields 1, 2, 3, and 4 must be identical to combine deltas) |
|
Group through User Field 5 |
Partial set (User Fields 1, 2, 3, 4, and 5 must be identical to combine deltas) |
|
All User Fields Defined |
Complete set (all user fields must be identical to combine deltas) |
Note: You set the Retro Delta User Field Level on the User Fields page.
See Earnings - User Fields for Element <name> Page.
The examples in this topic illustrate how deltas are grouped or separated based on the user field level.
Example 1: User Field Level = None
Assume that there is retroactive processing in Period 2 back to Period 1, and that the user field level is set to None for element E1.
The retroactive method is forwarding.
The results for Period 1 (V1R1) are:
|
Earnings |
Instance |
Amount |
User Field 1 (State) |
User Field 2 (Location) |
User Field 3 (Company) |
|---|---|---|---|---|---|
|
E1 |
1 |
300 |
State 1 |
Location 1 |
ABC |
|
E1 |
2 |
200 |
State 1 |
Location 2 |
DEF |
|
E1 |
3 |
150 |
State 3 |
Location 3 |
ABC |
When Period 1 is recalculated (V1R2), the results are:
|
Earnings |
Instance |
Amount |
User Field 1 (State) |
User Field 2 (Location) |
User Field 3 (Company) |
|---|---|---|---|---|---|
|
E1 |
1 |
400 |
State 1 |
Location 1 |
ABC |
|
E1 |
2 |
300 |
State 1 |
Location 2 |
DEF |
|
E1 |
3 |
200 |
State 3 |
Location 3 |
ABC |
The system stores the following deltas for E1 in the result tables:
|
Earnings |
Delta Number |
Delta |
User Field 1 (State) |
User Field 2 (Location) |
User Field 3 (Company) |
|---|---|---|---|---|---|
|
E1 |
1 |
250 |
Note: Because deltas are stored at the element level, the system sums the deltas for each user field set (100 + 100 + 50 = 250). No user field values are stored.
Example 2: User Field Level = All User Fields Defined (Complete Set)
Assume that there is retroactive processing in Period 2 back to Period 1, and that the user field level requires a complete user field match to group retroactive deltas.
The retroactive method is forwarding.
The results for Period 1 (V1R1) are:
|
Earnings |
Instance |
Amount |
User Field 1 (State) |
User Field 2 (Location) |
User Field 3 (Company) |
|---|---|---|---|---|---|
|
E1 |
1 |
300 |
State 1 |
Location 1 |
ABC |
|
E1 |
2 |
200 |
State 1 |
Location 2 |
DEF |
|
E1 |
3 |
150 |
State 3 |
Location 3 |
ABC |
When Period 1 is recalculated (V1R2), the results are:
|
Earnings |
Instance |
Amount |
User Field 1 (State) |
User Field 2 (Location) |
User Field 3 (Company) |
|---|---|---|---|---|---|
|
E1 |
1 |
400 |
State 1 |
Location 1 |
ABC |
|
E1 |
2 |
300 |
State 1 |
Location 2 |
DEF |
|
E1 |
3 |
200 |
State 3 |
Location 3 |
ABC |
The system stores the following deltas for E1 in the result tables:
|
Earnings |
Delta Number |
Delta |
User Field 1 (State) |
User Field 2 (Location) |
User Field 3 (Company) |
|---|---|---|---|---|---|
|
E1 |
1 |
100 |
State 1 |
Location 1 |
ABC |
|
E1 |
2 |
100 |
State 1 |
Location 2 |
DEF |
|
E1 |
3 |
50 |
State 3 |
Location 3 |
ABC |
Note: Because the user field level requires a complete match to sum retroactive deltas, the system stores the deltas separately by user field set.
Example 3: User Field Level = Through User Field 1 (Partial Set )
Assume that there is retroactive processing in Period 2 back to Period 1, and that the user field level requires a match through User Field 1 to group retroactive deltas.
User Field 1 is Company.
The retroactive method is forwarding.
The results for Period 1 (V1R1) are:
|
Earnings |
Instance |
Amount |
User Field 1 (Company) |
User Field 2 (State) |
User Field 3 (Location) |
|---|---|---|---|---|---|
|
E1 |
1 |
300 |
ABC |
State 1 |
Location 1 |
|
E1 |
2 |
200 |
DEF |
State 1 |
Location 2 |
|
E1 |
3 |
150 |
ABC |
State 3 |
Location 3 |
When Period 1 is recalculated (V1R2), the results are:
|
Earnings |
Instance |
Amount |
User Field 1 (Company) |
User Field 2 (State) |
User Field 3 (Location) |
|---|---|---|---|---|---|
|
E1 |
1 |
400 |
ABC |
State 1 |
Location 1 |
|
E1 |
2 |
300 |
DEF |
State 1 |
Location 2 |
|
E1 |
3 |
200 |
ABC |
State 3 |
Location 3 |
The system stores the following deltas for E1 in the result tables:
|
Earnings |
Delta Number |
Delta |
User Field 1 (Company) |
User Field 2 (State) |
User Field 3 (Location) |
|---|---|---|---|---|---|
|
E1 |
1 |
150 |
ABC |
||
|
E1 |
2 |
100 |
DEF |
Note: The system stores deltas by company (User Field 1) in this example.
When you forward an element to another element (regardless of the retroactive method), Global Payroll requires that both the user field set and the user field level of the element to be forwarded match the user field set and user field level of the forward to element.
When deltas are summed and forwarded to the current period from previous periods, Global Payroll observes these rules:
Deltas for an element are forwarded to the first segment in the current calendar (first resolved instance).
If the first segment is sliced, the system forwards adjustments to the first slice within the first segment.
If an earning or deduction fails to resolve in the current period because of generation control or missing payee level data, the retroactive adjustment for the element is pulled into the current period as the first instance.
If there is a retroactive adjustment only instance (a forwarded adjustment instance without a corresponding current period instance), the adjustment instance is resolved with segment dates, not slice dates.
If there is a retroactive adjustment in conjunction with a positive input or rule resolution, the retroactive adjustment is added to the first instance resolved.
If there is an arrears payback for a deduction in the current period but the deduction itself is not resolved, the arrears payback and the adjustment are brought in to create a single instance using segment dates.
These additional rules apply when there are user field levels defined for an element:
If the user field level is None, the system forwards the deltas to the first instance of the earning or deduction in the current period; these deltas assume the user field values of the first instance.
If there is no current instance, the adjustment becomes the first instance and uses the segment dates to fill out the user field set.
If the user field level is All User Fields Defined (complete set), all of the user fields associated with the deltas come in with the retroactive adjustments.
If the user field level is partial (Through User Field 1,2, 3, 4 and so on), the system forwards the deltas to the first instance of the element that matches the partial set.
If there is no match, segment dates are used to fill out the user field set.
These additional rules apply to earnings and deductions with or without user fields, and to elements with and without a driver:
If there is more than one instance of an element in the current period with matching user field values, the system applies the adjustments to the first instance.
The system allows only one retroactive adjustment per user field set.
The system adds the adjustment to the first instance of the user field set, and this instance is saved with the dates associated with it.
If there are no current instances of an element with a matching user field set, the adjustment resolves by itself using the segment dates.
A new user field set results in a new additional instance of the element.
The Review Unprocessed Retro Deltas component displays retroactive deltas by instance and user field set. However, the following attributes on the Review Unprocessed Retro Deltas component apply at the element level rather than at the instance or user field set level:
Retro Delta Match Action (Default Match, Do Not Process, or Apply to Calendar).
Forward to pay group/Calendar.
Note: Using the Review Unprocessed Retro Deltas component, you can target unprocessed retroactive deltas to specific calendars and change the element that the delta is forwarded to. Both the user field set and the user field level of the element to be forwarded must match the user field set and level of the forward to element.
The Retro Recalculation Option on the Calculation page of the earning and deduction definition component applies at the element level, not at the instance level. For example, if you set the Retro Recalculation Option to Always Recalculate for an instance of a deduction with a user field value of State = California, you cannot set the option to Do Not Recalculate for an instance with a user field value of State = New York.
During retroactive processing, if an earning or deduction element is defined as Do Not Recalculate, the system returns the old value for the element, along with all of its component elements. However, if there is a segment or slice mismatch between the period being recalculated and the prior calculated period, the system ignores the Do Not Recalculate designation and recalculates the element.