Understanding Segmentation with Multiple Resolutions

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.

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.

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.

  See Understanding Overrides.

• 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.

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.

  See Understanding Segmentation Setup.