Understanding Segmentation with Multiple Resolutions
This topic discusses:
Element segmentation with and without accumulator drivers.
Proration with element segmentation.
Positive input in a segmented calendar when user field sets are defined.
Filling out and processing user field sets when there is element segmentation.
Defining the processing order when there is segmentation.
When an accumulator used as a driver is sliced, the system observes the following rules:
Slicing of a driver accumulator automatically causes slicing of the earning or deduction that it drives.
If an earning or deduction with an accumulator driver is sliced, the driver value is applied to each slice of the earning/deduction. The driver can then cause multiple resolutions for each slice of that earning or deduction.
Earnings and deductions use accumulator occurrences with matching slice dates.
If a match is not found, the system uses accumulator instances whose slice dates encompass the slice dates of the earning or deduction.
Example 1: Element Segmentation of Earnings and Deductions without Accumulator Drivers
An accumulator AC1 is included in an element segmentation event definition.
AC1 has these members: earnings E1, E2, and E3.
These earnings are automatically included in the segmentation event definition along with the accumulator.
AC1, E1, E2, and E3 are sliced when there is a segmentation trigger.
Assume a monthly pay period with a segmentation trigger defined for January 15.
E1 = 700, E2 = 1000, and E3 = 1500.
This table contains the earning/deduction results:
Earnings |
Instance |
Slice Number |
Slice Dates |
Amount |
---|---|---|---|---|
E1 |
1 |
1 |
January 1–14 |
350 |
E1 |
2 |
2 |
January 15–31 |
350 |
E2 |
1 |
1 |
January 1–14 |
500 |
E2 |
2 |
2 |
January 15–31 |
500 |
E3 |
1 |
1 |
January 1–14 |
750 |
E3 |
2 |
2 |
January 15–31 |
750 |
This table contains the accumulator results:
Accumulator |
Instance Number |
Slice Number |
Slice Dates |
Amounts |
---|---|---|---|---|
AC1 |
1 |
1 |
January 1–14 |
1600 |
AC1 |
2 |
2 |
January 15–31 |
1600 |
Example 2: Element Segmentation of Earnings and Deductions with Accumulator Drivers
An accumulator AC1 is included in an element segmentation event definition.
AC1 has these members: earnings E1, E2, and E3.
These earnings are automatically included in the segmentation event definition along with the accumulator.
AC1 is the driver accumulator for deduction D1.
Slicing of the driver accumulator AC1 automatically causes slicing of the deduction that it drives (D1).
STATE is the user key for AC1; STATE is also a user field for D1.
D1 is defined as Base x Percent (assume the percent is the same for each state).
Base = CURR_DRIVER_VAL and Percent = 15%.
Note: CURR_DRIVER_VAL is a delivered system element that can be used to retrieve the current value of a driver accumulator if that accumulator is used in the calculation of an element. We discuss this and other system elements later in this topic.
Assume a monthly pay period with a segmentation trigger defined for January 15.
E1 = 700, E2 = 1000, and E3 = 1500.
This table contains the earnings results:
Earnings |
Instance |
Slice Number |
Slice Dates |
Amount |
User Field |
---|---|---|---|---|---|
E1 |
1 |
1 |
January 1–14 |
175 |
State 1 |
E1 |
2 |
2 |
January 15–31 |
175 |
State 1 |
E1 |
3 |
1 |
January 1–14 |
175 |
State 2 |
E1 |
4 |
2 |
January 15–31 |
175 |
State 2 |
E2 |
1 |
1 |
January 1–14 |
250 |
State 1 |
E2 |
2 |
2 |
January 15–31 |
250 |
State 1 |
E2 |
3 |
1 |
January 1–14 |
250 |
State 2 |
E2 |
4 |
2 |
January 15–31 |
250 |
State 2 |
E3 |
1 |
1 |
January 1–14 |
375 |
State 1 |
E3 |
2 |
2 |
January 15–31 |
375 |
State 1 |
E3 |
3 |
1 |
January 1–14 |
375 |
State 2 |
E3 |
4 |
2 |
January 15–31 |
375 |
State 2 |
This table shows the accumulator results:
Accumulator |
Instance Number |
Slice Number |
Slice Dates |
Amounts |
User Field |
---|---|---|---|---|---|
AC1 |
1 |
1 |
January 1–14 |
800 |
State 1 |
AC1 |
2 |
2 |
January 15–31 |
800 |
State 1 |
AC1 |
3 |
1 |
January 1–14 |
800 |
State 2 |
AC1 |
4 |
2 |
January 15–31 |
800 |
State 2 |
This table shows the deduction results:
Deduction |
Instance Number |
Slice Number |
Slice Dates |
Amounts |
User Field |
---|---|---|---|---|---|
D1 |
1 |
1 |
January 1–14 |
120 |
State 1 |
D1 |
2 |
2 |
January 15–31 |
120 |
State 1 |
D1 |
3 |
1 |
January 1–14 |
120 |
State 2 |
D1 |
4 |
2 |
January 15–31 |
120 |
State 2 |
If you do not define proration correctly when setting up accumulator driven earnings or deductions, you could get unexpected results.
For example, if you place a driver accumulator on a segmentation event list, you should not prorate the element it drives. This is because slicing the driver automatically causes slicing of both the accumulator members and the driven element. However, if you do not place the driver on a segmentation event list, and the element it drives is on the event list, the driver and the driven element will not be sliced equally, and the two will not match. In a situation like this, you should prorate the driven element.
Example: Element Segmentation of Earnings and Deductions with Accumulator Drivers; Driver Not on Segmentation Event List
The accumulator AC1 drives deduction D1.
AC1 is not included in the element segmentation event definition; D1 is included (when there is segmentation, only D1 is sliced).
AC1 has these members: earnings E1, E2, and E3.
STATE is a user key for AC1 and a user field for D1.
D1 is defined as Base x Percent (assume the percent is the same for each State).
Base = CURR_DRIVER_VAL and Percent = 15%.
Note: CURR_DRIVER_VAL is a delivered system element that can be used to retrieve the current value of a driver accumulator if that accumulator is used in the calculation of an element. We discuss this and other system elements later in this topic.
Assume a monthly pay period with a segmentation trigger defined for January 15.
E1 = 700, E2 = 1000, and E3 = 1500.
This table contains the earnings results:
Earnings |
Instance Number |
Amount |
User Field |
---|---|---|---|
E1 |
1 |
350 |
State 1 |
E1 |
2 |
350 |
State 2 |
E2 |
1 |
500 |
State 1 |
E2 |
2 |
500 |
State 2 |
E3 |
1 |
750 |
State 1 |
E3 |
2 |
750 |
State 2 |
This table contains the accumulator results:
Accumulator |
Instance Number |
Slice Dates |
Amount |
User Field |
---|---|---|---|---|
AC1 |
1 |
January 1–31 |
1600 |
State 1 |
AC1 |
2 |
January 1–31 |
1600 |
State 2 |
The following table shows the deduction results with proration turned off:
Deduction |
Instance Number |
Slice Number |
Slice Dates |
Amount |
User Field |
---|---|---|---|---|---|
D1 |
1 |
1 |
January 1–14 |
240 |
State 1 |
D1 |
2 |
2 |
January 15–31 |
240 |
State 1 |
D1 |
3 |
1 |
January 1–14 |
240 |
State 2 |
D1 |
4 |
2 |
January 15–31 |
240 |
State 2 |
Note: When proration is turned off, the results are overstated.
This table shows the deduction results with proration turned on:
Deduction |
Instance Number |
Slice Number |
Slice Dates |
Amount |
User Field |
---|---|---|---|---|---|
D1 |
1 |
1 |
January 1–14 |
120 |
State 1 |
D1 |
2 |
2 |
January 15–31 |
120 |
State 1 |
D1 |
3 |
1 |
January 1–14 |
120 |
State 2 |
D1 |
4 |
2 |
January 15–31 |
120 |
State 2 |
Normally, when positive input is entered into a segmented calendar, the positive input entry overrides segmentation. However, when user field sets are defined, the override respects the user field set of the positive input entry. In other words, positive input with a specific user field set overrides segmentation for the earning or deduction with the same user field set. Other resolutions of the earning/deduction (whether they come from driver instances or element assignments) with different user field sets are still subject to element segmentation.
When an earning/deduction undergoes element segmentation, the user field set is determined per slice.
Depending on whether user field values come from an element assignment, a positive input entry, or a driver accumulator, the system assigns the correct values as follows:
When User Field Values Come From an Element Assignment: An element assignment typically applies to all slices within a segment, and the user field values associated with the assignment also apply across all of the slices in that segment. However, if you set up your system to trigger element segmentation based on the begin and end dates of an element assignment, the user field values may be different from one slice to another.
When User Field Values Come From Positive Input: A given positive input entry always targets a specific slice or segment. The positive input end date determines the slice or segment to which the positive input entry applies and the user field set applies to that slice or segment only. For example, imagine that an earning is divided into two segments: the first segment has begin and end dates of June 1 and June 15, and the second segment has begin and end dates of June 16 and June 30. If you enter positive input for the earning with an end date of June 10, the positive input falls within the first segment of the pay period, and the user fields associated with the positive input apply to that segment only.
See Segmentation Considerations, Positive Input in a Segmented Calendar When User Field Sets are Defined.
When User Fields Come From a Driver Accumulator: Instances of a driver accumulator have associated user key values. Depending on whether the driver accumulator is on a segmentation event list, the instances may have either slice dates or segment dates. The user key values for each slice or segment of the driver apply to the corresponding segment or slice of the earning or deduction.
Example 1: Element Segmentation with Earning/Deduction Assignments; All Overrides Entered Using Earning/Deduction Assignments
Deduction D1 is included in the element list for a segmentation event.
The deduction does not have an accumulator driver.
Payroll is processed monthly.
The system generates a segmentation trigger with an effective date of June 16.
All user fields are entered as overrides on the element assignment pages.
This table lists the deduction assignments:
Note: In this example, earning/deduction assignment is abbreviated E/D Assignment.
E/D Assignment |
E/D Assignment |
E/D Assignment |
|
---|---|---|---|
Element Name |
D1 |
D1 |
D1 |
Instance Number |
1 |
2 |
3 |
Process Order |
10 |
20 |
30 |
Amount |
1000 |
500 |
600 |
User Field 1 (State) |
State 1 |
State 2 |
State 1 |
User Field 2 (Company) |
AAA |
AAA |
AAA |
The system resolves six instances of the deduction in the following order:
Res. Nbr. |
Slice Nbr. |
Slice Dates |
Amt. |
User Field 1 (State) |
User Field 2 (Company) |
Override Source |
---|---|---|---|---|---|---|
1 |
1 |
June 1– 15 |
500 |
State 1 |
AAA |
Element Assign. |
2 |
2 |
June 16 – 30 |
500 |
State 1 |
AAA |
Element Assign. |
3 |
1 |
June 1– 15 |
250 |
State 2 |
AAA |
Element Assign. |
4 |
2 |
June 16 – 30 |
250 |
State 2 |
AAA |
Element Assign. |
5 |
1 |
June 1– 15 |
300 |
State 1 |
AAA |
Element Assign. |
6 |
2 |
June 16 – 30 |
300 |
State 1 |
AAA |
Element Assign. |
In this example, the user field set for each resolution is entered with the element assignments and applies equally to both slices.
Example 2: Element Segmentation with Earning/Deduction Assignments; Not All Overrides Entered Using Earning/Deduction Assignments
Deduction D1 is included in the element list for a segmentation event.
The deduction does not have an accumulator driver.
Payroll is processed monthly.
The system generates a segmentation trigger with an effective date of June 16.
Not all user fields are entered as overrides on the element assignment pages. A formula determines the value of the Company user field; this field has a different value in each slice.
This table lists the deduction assignments:
Note: In this example, earning/deduction assignment is abbreviated E/D Assignment.
E/D Assignment |
E/D Assignment |
E/D Assignment |
|
---|---|---|---|
Element Name |
D1 |
D1 |
D1 |
Instance Number |
1 |
2 |
3 |
Process Order |
10 |
20 |
30 |
Amount |
1000 |
500 |
600 |
User Field 1 (State) |
State 1 |
State 2 |
State 1 |
The system resolves six instances of the deduction in the following order:
Res. Nbr. |
Slice Nbr. |
Slice Dates |
Amt. |
User Field 1 (State) |
User Field 2 (Company) |
Override Source |
---|---|---|---|---|---|---|
1 |
1 |
June 1– 15 |
500 |
State 1 |
AAA |
Element Assign. |
2 |
2 |
June 16 – 30 |
500 |
State 1 |
ZZZ |
Element Assign. |
3 |
1 |
June 1– 15 |
250 |
State 2 |
AAA |
Element Assign. |
4 |
2 |
June 16– 30 |
250 |
State 2 |
ZZZ |
Element Assign. |
5 |
1 |
June 1– 15 |
300 |
State 1 |
AAA |
Element Assign. |
6 |
2 |
June 16 – 30 |
300 |
State 1 |
ZZZ |
Element Assign. |
The values of the user fields not entered as element assignments are determined by slice and differ by slice.
Example 3: Element Segmentation with Positive Input; All Overrides Entered Using Positive Input
A deduction D1 is included in the element list for a segmentation event.
The deduction does not have an accumulator driver.
Payroll is processed monthly.
The system generates a segmentation trigger with an effective date of June 16.
All user fields are entered as overrides in positive input.
All positive input entries have begin and end dates.
This table lists the positive input entries for the deduction:
Note: In this example, positive input is abbreviated PI, and the positive input action type of override is abbreviated Over.
PI (Over) |
PI (Over) |
|
---|---|---|
Element Name |
D1 |
D1 |
Instance Number |
1 |
2 |
Begin Date |
June 1 |
June 16 |
End Date |
June 15 |
June 30 |
Amount |
1000 |
600 |
User Field 1 (State) |
State 1 |
State 2 |
User Field 2 (Company) |
AAA |
ZZZ |
The system resolves two instances of the tax deduction in the following order:
Res. Nbr. |
Slice Nbr. |
Slice Dates |
Amt. |
User Field 1 (State) |
User Field 2 (Company) |
Override Source |
---|---|---|---|---|---|---|
1 |
1 |
June 1– 15 |
1000 |
State 1 |
AAA |
Positive Input |
2 |
2 |
June 16 – 30 |
600 |
State 2 |
ZZZ |
Positive Input |
Resolution 1 (Slice 1) uses the data defined in positive input Instance 1, and Resolution 2 (Slice 2) uses the data defined in positive input Instance 2.
The same processing order rules that apply when element assignments occur together with positive input entries and driver instances in an unsegmented calendar apply in the case of segmented calendars, except that the rules apply per slice or segment.
For example:
In each slice or segment, earning/deduction assignments are calculated first within each unique user field set and dictate the processing order of any matching positive input entries.
In each slice or segment, after processing earning/deduction assignments, the system processes positive input entries with matching user field sets in instance number order.
Note: If positive input overrides an element assignment, the positive input inherits the processing order of the assignment it replaces.
Next, in each slice or segment, the system processes positive input entries without matching user field sets in instance number order.
After processing the positive input entries, the system processes driver occurrences with no element assignment or positive input user field set match.
Note that these rules govern only the processing order of the elements within each slice or segment. To determine the order of processing among the different slices and segments, the system follows one of the rules described below, depending on the source and type of segmentation (element or period segmentation):
When an assigned element is sliced because it is included in an element list for a segmentation event (element segmentation due to a segmentation event):
In this situation, the system divides the assigned element into different slices, but the same process order number, and in some cases the same user fields and other assignment data, apply to the element in each slice. If this is the case, the system calculates the assignment with the lowest process order number first, followed by all positive input instances with the same user field set, one slice at a time, in the order of the slices (from first slice to last), in each slice in which the user field set occurs, before moving on to the next set. For example, the system processes deduction D1 with a process order number of 10 and the user field of State = California in slice 1, slice 2, and then slice 3 along with any matching positive input, before processing D1 with a process order number of 20 and a user field of State = Nevada in the same slice order. If there are positive input entries without matching user fields, these are processed next, in instance number order rather than in the order of the slices.
When an assigned element is set up to trigger slicing when its begin and end dates do not coincide with the pay period begin and end dates (element segmentation based on assignment dates):
In this situation, the assignment itself triggers element segmentation and there may be other assignments of the same element in each slice of the pay period, each with its own process order number, user fields, and other assignment-specific data. In this case, the system calculates the assignment with the lowest process order number first, followed by all positive input instances with the same user field set, one slice at a time, in positive input instance order, in each slice in which the user field set occurs. It then processes the assignment with the next lowest process order number within its slice, followed by matching positive input entries in instance number order, and so on. If there are positive input entries without matching user fields, these are processed next, in instance number order.
See Matching Earning and Deduction Assignments with Positive Input Entries When There are User Fields, Understanding Segmentation Setup.
When there is period segmentation and all elements—including assigned elements—are divided into different segments.
In this situation the system processes elements in segment order—that is, elements in segment one before those in segment two, and elements in segment two before those in segment three. If there is element segmentation (slicing) within the different segments, then one of the previous two rules applies depending on the cause of the segmentation.
Example 1: Assigned Elements Are Sliced Because They Are On Segmentation Event List; All Overrides Entered Using Earning/Deduction Assignments
A deduction D1 is included in the element list for a segmentation event.
The deduction does not have an accumulator driver.
Payroll is processed monthly.
The system generates segmentation triggers for April 11 and April 21; this divides the pay period into three slices for that element.
Assignments cover the entire pay period.
All user fields are entered as overrides on the element assignment pages.
This table lists the deduction assignments:
Note: In this example, earning/deduction assignment is abbreviated E/D Assignment.
E/D Assignment |
E/D Assignment |
|
---|---|---|
Element Name |
D1 |
D1 |
Instance Number |
1 |
2 |
Process Order |
10 |
20 |
Amount |
900 |
600 |
User Field 1 (State) |
State 1 |
State 2 |
User Field 2 (Company) |
AAA |
AAA |
The system resolves six instances of the deduction in the following order:
Res. Nbr. |
Slice Nbr. |
Slice Dates |
Amt. |
User Field 1 (State) |
User Field 2 (Company) |
Override Source |
---|---|---|---|---|---|---|
1 |
1 |
April 1– 10 |
300 |
State 1 |
AAA |
Element Assign. |
2 |
2 |
April 11– 20 |
300 |
State 1 |
AAA |
Element Assign. |
3 |
3 |
April 21 – 30 |
300 |
State 1 |
AAA |
Element Assign. |
4 |
1 |
April 1– 10 |
200 |
State 2 |
AAA |
Element Assign. |
5 |
2 |
April 11– 20 |
200 |
State 2 |
AAA |
Element Assign. |
6 |
3 |
April 21 – 30 |
200 |
State 2 |
AAA |
Element Assign. |
The system resolves assignments based on the process order number (the lowest process order number receives the highest priority), and within a given user field set, it processes slice 1 first, then slice 2, and finally slice 3 before moving on to the next user field set.
Example 2: Element Segmentation Triggered Directly by Earning/Deduction Assignment; Positive Input Entries with User Fields; All Overrides Entered Using Earning/Deduction Assignments and Positive Input
Deduction D1 is set up to trigger element segmentation (and proration) when it is assigned to a payee with begin and end dates that do not coincide with the period begin and end dates.
Deduction D1 is first assigned to a payee with begin and end dates of April 16–30. Later, it is assigned to the same payee with begin and end dates of April 1–15. This divides the pay period into two slices.
The process order number of the first assignment is lower than the process order number of the second, even though the second assignment has the earlier assignment begin and end dates.
There is positive input for D1 in both slices (April 1–15 and 16–30).
There are user fields associated with all of the element assignment and positive input entries.
Note: In this example, earning/deduction assignment is abbreviated E/D Assignment, positive input is abbreviated PI, the positive input action type of override is abbreviated Over, and the positive input action type of additional is abbreviated ADD.
E/D Assignment |
E/D Assignment |
PI (ADD) |
PI (Over) |
PI (ADD) |
|
---|---|---|---|---|---|
Element Name |
D1 |
D1 |
D1 |
D1 |
D1 |
Instance Number |
2 |
1 |
1 |
2 |
3 |
Process Order |
20 |
10 |
N/A |
N/A |
N/A |
Begin and End Dates |
April 1–15 |
April 16–30 |
April 1–15 |
April 1–15 |
April 16–30 |
Amount |
1000 |
500 |
600 |
200 |
400 |
User Field 1 (State) |
State 1 |
State 2 |
State 2 |
State 1 |
State 2 |
The system resolves four instances of the deduction in the following order:
Res. Nbr. |
Slice Nbr. |
Slice Dates |
Amt. |
User Field 1 (State) |
Override Source |
---|---|---|---|---|---|
1 |
2 |
April 16–30 |
250 |
State 2 |
Element Assign. |
2 |
1 |
April 1–15 |
600 |
State 2 |
Positive Input |
3 |
2 |
April 16–30 |
400 |
State 2 |
Positive Input |
4 |
1 |
April 1–15 |
200 |
State 1 |
Positive Input |
In this example, the element assignment with the lowest process order number (10) is the assignment with the user field value of State 2 in slice 2; it is processed first, followed by the matching positive input additional row in the first slice for 600, and then the matching positive input additional row for 400 in the second slice (all slices in a given user field set are processed one after another in positive input instance order). Lastly, the system processes the positive input override for 200 in slice 1 based on the process order number (20) of the matching element assignment in that slice.