Defining Segmentation

This chapter provides an overview of segmentation and discusses how to:

• Set up segmentation.

• Manage segmentation.

Understanding Segmentation Setup

Segmentation refers to the process of calculating all or a subset of elements in a process list in separate slices or segments. You can segment components of pay based on events such as changes in compensation or employee status during a pay period. For example, if an individual changes jobs during a pay period and your organization separates components earned in the first job from those earned in the second job, you can set up the system to trigger segmentation of earnings results on the payslip when there’s a change to the job change action/reason field in PeopleSoft Enterprise Human Resources.

This section discusses:

• Types of segmentation.

• Relationship of period, segment, and slice dates.

• Basic rules of element resolution.

• Effective-dated element definitions.

• Rules for slicing accumulators and accumulator members.

• Rules for parent and child element resolutions.

• Segmentation and payee overrides.

• Proration and segmentation.

• Retroactive processing and segmentation.

• Positive input with segmentation.

• Segmentation system elements.

Types of Segmentation

Global Payroll offers two types of segmentation:

• Period segmentation.

  This type of segmentation is applicable when data that changes midperiod, such as a compensation rate, requires all elements in the process list to be calculated repeatedly on either side of the change date. The system divides the pay period (defined by the pay period begin and end dates) into two or more distinct segments and treats each segment as a complete and separate payroll calculation. It calculates each element in the process list for each segment, so a payee has multiple gross-to-net processes, payslips, and Payee Process Stat records. The system calculates each element more than once, using components that were effective during the different time slices.

• Element segmentation.

  This type of segmentation is applicable when data that changes midperiod requires the affected element (and perhaps a subset of other elements) to be calculated repeatedly on either side of the change date. (Each subperiod is called a slice.) The system segments only the elements that you select and it creates separate result columns only for the specified elements. In element segmentation, there’s only one gross-to-net result set.

Selecting Elements to Segment

With period segmentation, the system segments all elements on the process list automatically. With element segmentation, you must specify which elements in the process list to slice. To do this, you add the elements to be segmented to an element list that you define using the Segmentation Event Definition page that is described in this chapter.

See Also

Defining Segmentation Events and Types

Relationship of Period, Segment, and Slice Dates

For every pay period, the system generates begin and end dates for:

• Periods

  The pay period—monthly, biweekly, or weekly—used to group and calculate a payee’s earnings. Each period has a begin and end date and can be sliced or segmented.

• Segments

  A subperiod of time in the normal pay period that’s created due to period segmentation. Each segment represents a separate gross-to-net calculation of every element in the period and has begin and end dates. It can be sliced if an element in the segment is calculated separately on either side of the slice date.

• Slices

  The span of time into which an element is segmented due to element segmentation. Unlike a segment or period, it doesn’t represent a separate gross-to-net process, because it affects only a limited set of elements in a period or segment. Like a segment, a slice has begin and end dates.

All three sets of dates (period, segment, and slice) are generated, regardless of whether a period is sliced or segmented. The begin and end dates for periods, segments, and slices, are stored in the output result tables for the period and made available as system-computed elements for use in other calculations.

Example 1: Unsegmented Period

In an unsegmented period the number of periods equals the number of segments, which equals the number of slices. All three have identical begin and end dates.

This diagram illustrates the relationship between period, segment, and slice begin and end dates for an unsegmented period.

An unsegmented period

Example 2: Segmented Period

This diagram shows a period with two segments; segment 1 contains a sliced element:

A segmented period

Basic Rules of Element Resolution

This section discusses the basic rules of element resolution for period and element segmentation.

Using Period Segmentation

With period segmentation, all elements are resolved once for each segment.

Using Element Segmentation

When using element segmentation:

• Primary elements are resolved once in each slice, only if the element is defined to be sliced.

• Supporting elements are resolved once in each slice if the element is defined to be sliced.

  A supporting element is also resolved in each slice if it’s a component of an element that’s defined to be sliced. Suppose that an earnings element E1 is sliced. If this element uses a duration element (a supporting element) that measures years of service, and the value of earnings E1 is based on the years returned by the duration element, the duration element is resolved whenever E1 is resolved, because it’s a component of E1.

Note. To define the elements to be sliced, you use the Segmentation Event Definition page.

Example of Period Segmentation

In period segmentation, all elements are calculated once for each segment and there are multiple gross-to-net processes.

This table lists examples of elements and the associated period segmentation rules:

Assume that E1 represents base pay and that the value of E1 increases from 10,000 to 20,000 on September 16, triggering the segmentation of the September pay period into two equal parts. This scenario is represented in this table:

In this example, all the elements on the process list are segmented and there are two separate gross-to-net processes.

Example of Element Segmentation

When you use element segmentation, the system segments only those elements that are included in the list of elements to be segmented. The system performs only one gross-to-net calculation.

This table lists examples of elements and associated segmentation rules:

Assume that E1 represents base pay and that the value of E1 increases from 10,000 to 20,000 on September 16, triggering the slicing of element E1 into two equal parts. This scenario is represented in this table:

E1 is sliced once on September 16, resulting in two separate calculations for E1—one for each slice. There is only one gross-to-net process, and the Net Pay element represents the sum of E1 in each slice and E2 in each slice minus D1 (deduction 1).

See Also

Defining Segmentation Events and Types

Effective-Dated Element Definitions

All effective-dated elements contain a Definition as of Date field that tells the system which effective-dated row to use when retrieving the definition of an element. Options include calendar period begin date, calendar period end date, and payment date.

The same Definition As Of Date definition is used for all segments and slices within the period.

See Also

Understanding the Process of Selecting Definition As Of Dates

Rules for Slicing Accumulators and Accumulator Members

This section describes the rules for slicing accumulators and accumulator members.

Using Period Segmentation

With period segmentation, every element and supporting element is segmented—a situation cannot exist in which an element is segmented but the accumulator to which it belongs isn’t segmented.

Using Element Segmentation

The slicing of a member of an accumulator does not cause slicing of the accumulator, but the slicing of an accumulator causes all member elements to be sliced.

Rules for slicing an accumulator that is used as a driver are covered in the chapter that discusses multiple resolutions of earnings and deductions.

See Also

Defining Element Segmentation with Accumulator Drivers and Driver Elements

Rules for Parent and Child Element Resolutions

When an element is composed of (or based on) other elements, the system defines those other elements as child elements and the elements that are based on them as parent elements. Elements and supporting elements can be parents or children.

Say Tax A is a percentage of earnings E1 and earnings E2 (Tax A = 10% × ( E1 + E2)). In this example, Tax A is the parent and earnings E1 and earnings E2 are the children. The concept of child and parent elements is central to understanding how an element that’s based on other elements is resolved.

Matching and Mismatching Slices and Segments

During period segmentation, all elements are segmented equally, and parent and child elements always match.

During element segmentation, parent and child elements can be sliced equally, or one may be sliced more than the other. For example, the parent might be included in the list of elements to segment, while the child is not. If the parent and child slices are identical, the parent and child are said to match; if they are not identical, they are referred to as mismatching.

Global Payroll follows specific rules for processing matching and mismatching elements. These rules are illustrated in the following examples.

Examples 1–7: Parent Element Is a Primary Element or a Supporting Element

The following cases use these elements:

• Earnings E1 = Percent of F1 (supporting element)

• Earnings E3 = Percent of E2 (primary element)

• F1 = 100 (supporting element)

• E2 = 100 (primary element)

This table summarizes the examples that follow in this section. The child and parent slices in these examples do not always match, as indicated in the Match/No Match column.

Note. The following examples show the results with and without proration. Prorated amounts are in parentheses.

Case 1

Assumptions:

E2 (primary element) = 100

E3 (primary element) = 10% of E2

Proration on E3

Scenario: Parent is sliced; child is not sliced. Child is a primary element.

Each slice of E3 uses the full value of the child (E2), producing a warning message.

Case 2

Assumptions:

E2 (primary element) = 100

E3 (primary element) = 10% of E2

Proration on E2

Scenario: Parent is sliced; child is sliced. Child is a primary element.

When the parent's slice dates equal the child's slice dates, the parent uses the child's value. Although the slice dates match, without proration, the results may be incorrect.

Case 3

Assumptions:

E2 (primary element) = 100

E3 (primary element) = 10% of E2

Proration on E2

Scenario: Parent is sliced; child is sliced more. Slices partially match. Child is a primary element.

Slice 1 of the parent and child match, so the system sums the child slices (slice 1, in this example). For the second slice of E3 (the parent), the system sums slice 2 and slice 3 of E2 (the child), because the begin date of slice 2 and end date of slice 3 match slice 2 of E3 (the parent). This scenario will generate a warning message.

Case 4

Assumptions:

E2 (primary element) = 100

E3 (primary element) = 10% of E2

Proration on E2

Scenario: Parent is sliced; child is sliced less. Slices partially match. Child is a primary element.

Generally, if the child is a primary element, it should be on the same list of elements to be segmented as the parent element. This ensures that both the child and parent have matching slices. Otherwise, the above scenario could occur and should be avoided.

The resolution is twofold. When there are exact matches (as in slice 1 of the parent and the child), the system uses the child’s value. If the parent or the child has proration turned on, the result is correct. The second resolution of the parent sums all resolutions of the child (200, in this example), resulting in an overcalculated amount. This is because the system cannot get a match on the slice dates for the parent and the child. Even with proration turned on, the amount of the child is overstated (see the amounts in parentheses).

Case 5

Assumptions:

E2 (primary element) = 100

E3 (primary element) = 10% of E2

Proration on E2

Parent is sliced. Child is sliced. No match on slice dates. Child is a primary element.

Generally, if the child is a primary element, it should be on the same list of elements to be segmented as the parent element. This ensures that both the child and parent have matching slices. Otherwise, the above scenario could occur and should be avoided.

As in the second resolution in Case 5, when the parent’s slice dates do not match any child slice dates, the system sums the value of all child slices for each resolution of the parent, resulting in a warning message.

Case 6

Assumptions:

E2 (primary element) = 100

E3 (primary element) = 10% of E2

Proration on E2

Parent is not sliced. Child is sliced. No match on slice dates. (Slice dates are not applicable to the parent.) Child is a primary element.

When the parent isn’t sliced, and the child is—and the child is a primary element—the resolution of the parent element sums the values of all resolutions of the child, generating a warning message.

Case 7

Assumptions:

E1 (primary element) = 10% of F1

F1 (supporting element) = 100

Proration on E1

Parent is sliced. Child is not sliced. Child is a supporting element.

Slice 1 of E1 resolves child for the slice 1 time period. F1 is sliced because, as a supporting element child, it will resolve for each parent’s slice.

Note. A parent element that is on the process list as well as the list of elements to be segmented, dictates the time period of the slice periods. If the supporting element is populated through an array, bracket, or a formula, then that array, bracket or formula element must be on the same list of elements to segment as the parent. (Define the list of elements to segment using the Element List grid on the Segmentation Event Definition page that is described in this chapter.)

General Rules for Warning Messages

If the child element is a primary element and its slice dates don’t match the parent’s slice dates, the following situations can cause warning messages:

• Parent is sliced. Child isn’t sliced (see Case 1).

• Parent is sliced. Child is sliced. The slice dates of the parent don’t match the slice dates of the child (see Cases 3, 4, and 5).

• Parent isn’t sliced. Child is sliced (see Case 6).

If the child element is an accumulator, a warning message is issued whenever the accumulator’s slice dates don’t match the parent’s slice date.

Segmentation and Payee Overrides

You can define two types of overrides at the payee level:

• Primary element overrides.

• Supporting element overrides.

Both types of overrides are called payee overrides, and the system follows the same basic rules for applying these overrides to segmented and unsegmented periods. Generally, when a pay period has period or element segmentation, payee overrides are applied to a segment based on the segment end date and the end date of the override, following the rules below. The rules are the same for primary and supporting element overrides at the payee level; only primary element overrides are discussed here. Any minor differences in these two types of overrides are clarified in the following examples.

The rules for applying overrides at the payee level are:

• Primary element overrides apply to earnings, deduction, absence entitlement, and absence take elements, and the overrides must have begin dates. End dates are not required.

  Supporting element overrides apply to elements such as variables, formulas, arrays, and brackets.

• If an override is to apply to a segment, the end date of the override must equal or be greater (or blank) than the end date of the segment (see Overrides 3 and 4 in the diagram that follows).

• An override can apply to more than one segment if the end date of the override is greater than one segment’s end date and greater than or equal to the subsequent segment’s end date (or blank) (see Override 3 in the diagram that follows).

• If the end date of the override is less than the end date of the segment, the override doesn’t apply to that segment (see Overrides 1 and 2 in the diagram that follows).

• Primary element overrides are prorated if the element is defined to be prorated.

  With supporting element overrides, the supporting element is prorated if it’s a component of an element that’s defined to be prorated and that element is segmented.

• Payee overrides must be Active as of the segment end date.

This diagram shows an example of a primary element override:

A primary element override

• Overrides 1 and 2 apply to neither segment, because their end dates come before the end dates of Segments 1 and 2.

• Override 3 applies to Segments 1 and 2 equally, because its end date is greater than the first segment’s end date and greater than or equal to the second segment’s end date.

• Override 4 applies to Segment 1 because its end date is greater than or equal to the end date of Segment 1 and less than the end date of Segment 2.

• Override 5 applies to Segment 2, because its end date is equal to the end date of Segment 2 and its begin date is after the end date of Segment 1.

The following examples offer a more detailed view of how payee overrides are applied to segmented and unsegmented periods:

Scenario: Two payees are eligible to receive an earnings element (E1) whose value is 100. Assume that Payee 1 has no segmentation and that Payee 2 has period segmentation in the January pay period. The segment dates for Payee 2 are January 1, 2005−January 15, 2005 and January 16, 2005–January 31, 2005. The payees have identical supporting element overrides, and the pay period being processed is January 1, 2005–January 31, 2005. This table lists cases that show how the system applies primary element overrides:

Note. In this example, override is abbreviated Over.

Note. Although these examples refer to period segmentation, the same basic rules apply to element segmentation—if a sliced element is overridden at the payee level, the override applies to the slices just as it applies to segments with period segmentation.

See Also

Setting Up Overrides

Proration and Segmentation

This section discusses:

• Segmentation with proration.

• Segmentation without proration.

Segmentation with Proration

To have the system prorate a segmented earnings, deduction, or frequency-based entitlement element, specify proration as part of the element's definition. Then, when segmentation or slicing occurs, the element automatically calls the appropriate proration rule.

You must define the proration rule to use in segmentation processing, because the rule is not hard-coded. Generally, a proration rule that you define consists of a numerator, representing the slice or segment, and a denominator, representing the entire pay period.

You can determine how to define the numerator and denominator that constitute the proration factor. The numerator and denominator can be any of these elements:

• Accumulator

• Count

• Duration

• Formula

• Variable

Note. When you define a proration element, the Always Recalculate check box on the Proration Name page is automatically selected. This is to ensure that the system correctly calculates the proration factor when there is element segmentation.

Segmentation without Proration

To apply segmentation without proration, select the No Proration option on the Rounding/Proration page of the Earnings/Deduction Definition component or the Absence Entitlement component.

Example: Segmentation without proration.

This table provides an example of segmentation without proration:

Note. You can slice or segment a period without applying proration, but an element cannot be prorated unless there is segmentation.

Assume that E1 represents base pay and that E1 is sliced on September 16, halfway through the pay period. None of the interrelated elements are defined to be prorated. This scenario is represented in this table:

Because E1 is not defined to be prorated, the system incorrectly calculates the value of E1 in each slice (slices 1 and 2) as 20,000 (the true value in each slice should be 20,000 × ½). This leads to additional errors: When E2 is calculated, the system sums up E1 in each slice, to yield a value of 40,000 × 10% (the correct amount is 20,000 × 10%). Similarly, A1 resolves to 44,000 instead of 22,000. And E3, defined as A1 × 10%, resolves to 44,000 × 10%, yielding 4,400 (the correct result is 2,200).

It’s important to understand why segmentation does not automatically result in proration. For example, if E2 is a percentage of E1 and both are sliced, E1, but not E2, is prorated.

Note. When you define a proration element, the Always Recalculate check box on the Proration Name page is automatically selected. This is to ensure that the system correctly calculates the proration factor when there is element segmentation.

Retroactive Processing and Segmentation

When a retroactive trigger is generated in response to an event, the system writes the effective date of the change to trigger occurrence tables. The system uses this date to determine how far back in time to recalculate closed periods, using this logic:

• Without backward limits, the system takes the effective date of the change that triggers retroactive processing, returns to the first calendar period in which the effective date falls, and calculates the entire period and everything forward.

• If the effective date of the retroactive change falls midperiod, the system doesn’t automatically segment the period or use proration when recalculating original pay items (because it tries recalculating the entire period).

• Segmentation triggers remain active and available to the system because they may be needed for future retroactive processing.

See Also

Defining Backward and Forward Retroactive Processing Limits

Trigger Table Data

Defining Retroactive Processing

Positive Input with Segmentation

Like payee level overrides, positive input enables you to override the value of an element in a pay period. And like payee overrides, positive input uses begin and end dates (the begin and end dates are optional with positive input). Thus, when a calendar pay period has period or element segmentation, positive input is assigned to a segment or slice based on the end date of the instance. Unlike payee overrides, positive input is applied only to a single element or slice and is never prorated. Other rules that affect the assignment of positive input are:

• If the begin and end dates of the instance precede the calendar begin date, positive input is assigned to the first segment or slice.

• When no begin or end date is specified for the instance, the system assigns the instance to the last segment or slice in the pay period.

  It’s assumed that the end dates for the instance and calendar are the same.

• If the end date of the instance falls after the calendar end date, the instance is not processed.

See Also

Segmentation Considerations

Segmentation System Elements

This table lists the system elements that are delivered for segmentation:

Setting Up Segmentation

This section provides an overview of setting up segmentation and discusses how to:

• Define segmentation events and types.

• Define trigger fields.

Understanding Segmentation

To set up segmentation:

1. Define an event ID and segmentation type on the Segmentation Event Definition page.

   Segmentation can be caused by events such as paygroup transfers, pay entity transfers, and new hires. The system does not automatically know what type of segmentation (period or element) to apply to an event. When you create an event ID, you specify:

   • The type of segmentation to use.

   • The elements to slice (for element segmentation only).

2. Define the fields that trigger segmentation on the Trigger Definition page, and link them to the event ID.

   These fields become trigger fields, which trigger segmentation in response to changes in payee data. By attaching the event ID to a field, you tell the system what type of segmentation to use when the event occurs.

See Also

Setting Up Triggers

Segmentation Triggers

Pages Used to Set Up Segmentation

Defining Segmentation Events and Types

Access the Segmentation Event Definition page.

Country	Displays the country that uses the trigger event ID defined on this page. Event IDs are defined by country because one country (or organization in a country) might decide to process an event by segmenting one subset of elements (in the case of element segmentation), whereas another might decide to process the same event by segmenting a different subset of elements. Or one country might use period segmentation while another uses element segmentation to process the same event.
Trigger Event ID	Displays the trigger event ID that you entered to access this page. This ID tells the system which segmentation type to use to process segmentation events and which elements to segment if you use element segmentation.
Segment Type	Select a segment type. Options are Period and Element. See Types of Segmentation.
Effective Date	Enter the effective date of the trigger event ID. You can enter multiple effective-dated rows for each trigger event ID if the trigger event definition changes.
Status	Select the status of the trigger event ID. Options are Active and Inactive.

Element List

If you use element segmentation to process an event, you must specify which elements in the process list should be sliced, because element segmentation affects only a limited set of elements. Enter the elements to be segmented in the Element List group box.

See Also

Defining Backward and Forward Retroactive Processing Limits

Trigger Table Data

Defining Retroactive Processing

Defining Trigger Fields

Access the Trigger Definition page.

On this page you define the fields that trigger segmentation, and link them to an event ID.

Note. The Trigger Definition page is also used to define iterative and retroactive triggers.

See Also

Setting Up Triggers

Managing Segmentation

Trigger data is generated automatically by the online system based on the conditions that you specify during setup. After the online system generates segmentation triggers, use the Review Triggers - Segmentation page to manage those triggers so that segmentation occurs only when you want it to—and only in response to appropriate changes in system data.

This section discusses how to view, add, and cancel segmentation triggers.

Page Used to Manage Segmentation

Viewing, Adding, and Canceling Segmentation Triggers

Access the Review Triggers - Segmentation page.

Use this page to view segmentation triggers for each employee ID/employee record combination. You can also manually add and delete trigger rows through this page.

See Also

Setting Up Triggers

Viewing and Managing Triggers