Managing Multiple Resolutions of an Earning or Deduction

This chapter provides an overview of multiple resolutions and discusses how to:

• Generate multiple resolutions using positive input.

• Generate multiple resolutions using element assignments.

• Generate multiple resolutions using accumulator drivers.

• Define interactions between positive input entries and element assignments with user field sets.

• Manage multiple resolutions through a driver when there are earning/deduction assignments and positive input.

• Define element eligibility.

• Define components of a calculation rule when an element has multiple resolutions.

• Define element segmentation with accumulator drivers and driven elements.

• Retrieve data for elements that resolve multiple times.

• Define arrears.

• Use generation control with multiple resolutions.

• Use the always recalculate option.

• Use brackets and formulas to populate user fields.

• Define retroactive considerations.

• Use system elements.

Understanding Multiple Resolutions

You can cause an element to resolve multiple times in a single segment by:

• Slicing or segmenting the element (using element or period segmentation).

  When you segment elements using period or element segmentation, Global Payroll resolves the elements multiple times.

• Entering positive input for an element using an Action Type of Additional, Override, or Resolve to Zero.

  When you enter additional positive input for an element, the element resolves once using the element's rule definition—or if there are element overrides, using the override values. The element resolves again using the values associated with the add-type instance of positive input.

  When you enter multiple positive input overrides, the system resolves them separately by instance number.

• Entering multiple instances of an element on the element assignment pages.

  For example, you could enter the same garnishment multiple times for the same periods or segments. The system assigns an instance number to each entry and processes each one separately.

• Defining an accumulator driver to cause multiple resolutions of an earning or deduction.

  For each instance of the accumulator, there is a corresponding resolution of the earning or deduction that it drives.

This chapter focuses on these types of multiple resolutions:

• Resolutions generated by positive input.

• Resolutions initiated by element assignments.

• Resolutions initiated by accumulator drivers.

Multiple resolutions of an element initiated by segmentation are discussed in the chapter on segmentation.

See Also

Defining Segmentation

Common Elements Used in this Chapter

See Also

Defining Payee Overrides

Working with Positive Input

Generating Multiple Resolutions Using Positive Input

To initiate multiple resolutions of an element using positive input:

1. Define the element with an override level of Payee and Positive Input.

   Do this on the Element Name page for the earning or deduction.

2. Enter positive input for the payee and the element using the Action Type of Additional or Resolve to Zero,or define multiple positive input rows with an Action Type of Override or Additional.

   Do this on the Positive Input page.

Example 1: Using Positive Input Additional Instances to Generate Multiple Resolutions

When you enter additional positive input for an element, the system resolves the element once using the element level definition (or if there are overrides for the element, using the override values), and resolves it again using the additional positive input values. For example, if you define an earning as a flat amount with a value of 1000 EUR at the element level, and enter additional positive input of 500 EUR, Global Payroll resolves the element once using the value of 1000 EUR, and again using a value of 500 EUR.

Example 2: Using Positive Input Override Instances to Generate Multiple Resolutions

If you create more than one positive input entry for an element using the Action Type of Override, the system assigns a different instance number to each entry and resolves them separately. For example, if you define an earning as a flat amount with a value of 100 USD at the element level, and enter two positive input overrides for the element for 200 USD, Global Payroll resolves each entry separately (200 USD + 200 USD), but does not resolve the earning using the element level definition (100 USD).

Example 3: Using Positive Input Resolve to Zero Instances to Generate Multiple Resolutions

If you enter a positive input override as well as a resolve to zero instance, the system resolves the override as well as the resolve to zero row. For example, if you define a deduction as a flat amount with a value of 500 USD at the element level, and enter a positive input override for 200 USD as well as a resolve to zero row, the system resolves the element twice: once for 200 USD and again for 0 USD.

Note. The resolve to zero action does not affect other instances of positive input—it applies only to itself.

See Also

Defining Segmentation

Setting Up Overrides

Working with Positive Input

Pages Used to Generate Multiple Resolutions Using Positive Input

Generating Multiple Resolutions Using Element Assignments

This section provides an overview of multiple resolutions using element assignments, and discusses how to:

• Generate multiple resolutions using element assignments without user fields.

• Generate multiple resolutions using element assignments with user fields.

Understanding Multiple Resolutions Using Element Assignments

In Global Payroll you can cause multiple resolutions of an earning or deduction using element assignments.

There are two ways to do this:

• You can enter multiple earning or deduction assignments with overlapping begin and end dates, without specifying user fields.

• You can define separate instances of an earning or deduction assignment with overlapping begin and end dates, and specify user fields.

Generating Multiple Resolutions Using Element Assignments without User Fields

When the system encounters multiple assignments of an element with overlapping begin and end dates on the earning/deduction assignment pages (without user fields), it resolves each assignment separately, without generating a unique accumulator instance for each resolution.

For example, if you define three instances of Deduction A in July, the system resolves each instance, and sums the results in the auto-generated accumulators for the deduction.

Note. You can define other, non auto-generated accumulators to store each element's resolution separately if you want, but the auto-generated accumulators automatically sum the resolutions.

To generate multiple resolutions of an earning or deduction using element assignments without user fields:

1. Define the earning or deduction on the element definition page.

2. Select Payee as the override level when you define the earning or deduction.

3. Access the Element Assignment By Payee page or the Payee Assignment By Element page, and enter more than one assignment for the same element.

   The system automatically assigns an instance number to each entry to distinguish one assignment from another.

   Note. You can use the Process Order field to control the order in which an element is processed if there is more than one instance of the element per segment.

   When payroll processes the element, it resolves it once for each entry, and sums the results in the auto-generated accumulators.

Example: Earning and Deduction Assignments without User Fields

Consider the following example of a garnishment deduction:

In this example:

• There are three instances of the garnishment on the element assignment pages (instances 1, 2, and 3).

• During payroll processing in July 2003, the deduction resolves three times (once for each element assignment in the same payroll period or segment).

• The system does not create a unique accumulator instance corresponding to each element assigned. Instead, it sums the resolutions in a single accumulator instance.

Generating Multiple Resolutions Using Element Assignments with User Fields

When the system encounters multiple assignments with overlapping begin and end dates and different user field values, it resolves each assignment separately. Depending on the user keys of the accumulators, the system generates separate accumulator instances to store the different resolutions:

• If the user keys on the auto-generated accumulators (or other accumulators created to store the element's resolutions) match the element's user fields, the system generates separate accumulator instances to store each resolution of the element.

  For example, if you define three instances of Deduction A in July, you associate the deduction with the user field Location, and there are deduction assignments for three locations (locations A, B, and C) in a single segment, the system resolves the deduction for each location, and stores the results in separate accumulator instances (one for each location).

• If the user keys on the auto-generated accumulators (or other accumulators created to store the element's resolutions) do not match the element's user fields, the system may or may not sum all resolutions of the element in a single accumulator instance.

  The exact behavior depends on how the system resolves the accumulator keys (if any). For example, assume that Deduction A has a user field of state, and that the corresponding accumulator has a user key of company. If there are two instances of the deduction (one for California and one for New York), and the first instance is associated with company ABC while the second is associated with company DEF, the system would create a separate accumulator instance for each resolution.

To generate multiple resolutions using element assignments with user fields:

1. Define the earning or deduction on the element definition pages.

   For example, define a loan payback deduction called LOAN.

2. Click the User Fields link on the Element Name page for the earning or deduction to access the User Fields page.

   For example, click the User Fields link for the LOAN deduction.

3. Define a user field on the User Fields page so that you can make unique assignments of the element based on user field values.

   For example, define a user field called Loan Type.

4. Define the user field as a variable and specify the name of the variable.

   User fields associated with an earning or deduction must be defined as variables. This is because only variables can be overridden on the element assignment pages.

   Note. To associate a variable with an element using user fields, you must have previously defined the variable on the variable definition pages. You define the value of the variable on the Element Assignment By Payee and Element Detail pages when you assign the element to a payee.

5. (Optional) Click the Copy User Fields button on the Auto-Generated Accumulators page of the earning/deduction definition component to transfer the element's user fields to the auto-generated accumulators.

   If you do this, the system generates a separate accumulator instance for each resolution with a different user field value.

   Note. The system automatically transfers the user fields associated with a deduction to the deduction's auto-generated arrears accumulators—you do not need to copy user keys to the arrears accumulators. However, you must click the Copy User Fields button to transfer user fields to all other auto-generated accumulators.

6. Select Payee override as the override level on the earning or deduction definition.

7. Access the Element Assignment By Payee page or the Payee Assignment By Element page, and enter multiple element assignments for the payee using the Instance Number and the user fields to distinguish one assignment from another.

   When payroll processes the element, it resolves each entry, and generates a separate accumulator instance for each assignment with unique user field values.

   For example, assign the LOAN deduction multiple times to the same payee with different instance numbers and different user field values (different loan types).

Example: Earning and Deduction Assignment with User Fields and Matching Accumulator Keys

Consider the following example of a loan payback deduction:

In this example:

• The loan payback deduction is associated with the User Field Loan Type.

• The user field Loan Type is a user key on the auto-generated accumulators for the LOAN deduction.

• Three loans with different user field values are assigned on the element assignments pages (instances 1, 2, and 3).

• During payroll processing in July, the deduction resolves three times (once for each instance), and the system generates three corresponding accumulator instances.

See Also

Defining Earning and Deduction Elements

Setting Up Accumulators

Defining Payee Overrides

Pages Used to Generate Multiple Resolutions Using Element Assignments

Generating Multiple Resolutions Using Accumulator Drivers

This section provides an overview of multiple resolutions using accumulator drivers, and discusses how to define the basic rules for earnings and deductions that use accumulator drivers.

Understanding Multiple Resolutions Using Accumulator Drivers

In Global Payroll you can define an accumulator driver to cause multiple resolutions of an earning or deduction. For each instance of the accumulator, there is a corresponding resolution of the earning/deduction element that it drives.

To set up an accumulator to drive multiple resolutions of another element, you must define:

• The elements to accumulate in the driver.

• The driver accumulator itself.

• The elements (earnings or deductions) that are driven by the accumulator.

• The user fields to generate separate accumulator instances of the elements that feed the accumulator driver.

Follow these steps to generate multiple resolutions using accumulator drivers:

Note. The steps outlined in this section represent one possible approach to defining an earning or deduction that uses an accumulator driver. Your setup may differ from the one described here.

1. Define the earning or deduction element to accumulate in the accumulator driver.

   For example, define an earning called SALARY.

2. Click the User Fields link on the Element Name page for the earning or deduction to access the User Fields page.

   For example, select the User Fields link on the Earnings Name page for the SALARY element.

3. Associate the earning or deduction with user fields on the User Fields page to generate unique accumulator instances by user field for the different resolutions of the element.

   This field can be a variable or a system element.

   For example, if you are defining a taxable earning (SALARY) that needs to be kept separate by state or location, define a user field called State or Location.

   Note. If you define the user field as a variable, you must have previously defined the variable on the variable definition pages.

4. Define a segment accumulator to store the earning or deduction. The user keys of the accumulator should match the user fields defined for the earning or deduction.

   For example, define an accumulator called State Taxable Gross and use State as an accumulator key to separate taxable earnings by state.

   Note. If you use State as the user key of the accumulator, when the SALARY element resolves for different states, the system will generate unique accumulator instances by state.

5. If the accumulator defined in step 4 drives the resolution of an earning or deduction, identify the accumulator as the driver of that element using the Driver Accumulator field on the Element Name page.

   For example, if you define a tax deduction that should be resolved for each state with taxable earnings, define the State Taxable Gross accumulator as the driver accumulator for the deduction.

   Note. Earnings and deductions automatically inherit the user keys of the driver accumulator to which they are linked. These user keys become the user fields of the earning or deduction element.

Example: Using Accumulator Drivers to Cause Multiple Resolutions

This table lists the instances of a driver accumulator for a state tax deduction:

This accumulator stores earnings, such as salary and overtime, that are taxed at the state level, and has the user key State.

The earnings it accumulates are also associated with the user field State.

The State Taxable Gross accumulator drives multiple resolutions of the State Income Tax deduction.

This deduction is defined as 20% of State Taxable Gross.

There are three resolutions of the state income tax corresponding to the three driver accumulator instances:

In this example:

• Because the user field State is associated with each taxable earning element (for example, salary and overtime earnings), the earnings automatically populate the correct instance of the State Taxable Gross accumulator.

• The State Taxable Gross accumulator is defined as the driver of the State Income Tax deduction.

• The State Income Tax deduction automatically inherits the user keys of the driver accumulator.

• For each occurrence of the driver accumulator, there is a separate resolution of the state income tax deduction.

See Also

Defining Earning and Deduction Elements

Setting Up Accumulators

Defining Basic Rules for Earnings and Deductions Using Accumulator Drivers

This section discusses basic rules for:

• Earnings and deductions that use accumulator drivers.

• Accumulators used as accumulator drivers.

Earnings and Deductions That Use Accumulator Drivers

Earnings and deductions using accumulator drivers must conform to these rules:

• The earning or deduction elements must have the same user fields as the user keys of the driver accumulator.

  Note. Earnings and deductions automatically inherit their user fields from the user keys of the driver accumulator.

• The user fields of the earning or deduction must be in the same order as the user keys of the driver accumulator.

• You cannot define an earning or deduction with a driver and no user key.

  There must be at least one user field (corresponding to a user key on the accumulator) associated with the earning or deduction.

• The only elements that can be resolved multiple times using a driver accumulator are earnings and deductions.

• Earning and deductions driven by an accumulator cannot use their own auto-generated accumulators as drivers.

  Note. As a general rule, an accumulator used as a driver cannot include the element it is driving, because this would create a circular reference.

  Note. The prompt view for the Driver Accumulator field on the earning and deduction Name page automatically excludes auto-generated accumulators.

• An earning or deduction element can have only one driver.

Accumulators Used as Driver Accumulators

Accumulators used as drivers must conform to these rules:

• The only element type that can be used as a driver is an accumulator.

• Only segment accumulators can be used as drivers.

• A segment accumulator used as a driver must be an As Contributing type accumulator.

• There must be at least one user key defined for an accumulator used as a driver.

  Note. On the earning and deduction Name page, the prompt for valid driver accumulators displays only accumulators that are defined as segment and as contributing, and that have at least one user key defined.

• The user keys of the driver accumulator automatically become the user fields of the earning or deduction.

• The system automatically defaults the user keys of the driver to the arrears accumulator.

  You cannot alter the key structure of the arrears accumulator. However, the system does not automatically default the key structure of the driver to other auto-generated accumulators. You can define a different set of keys for these accumulators, or use the same keys.

  Note. If you want to use the same set of keys for all of the auto-generated accumulators, click theCopy User Fields button on the Auto Generated Accumulators page. If you do this, the system generates separate accumulator instances of the driven element based on the key values.

• The system does not prevent you from changing the accumulator keys of a driver after it is associated with an earning or deduction.

  If you do change the user keys, Global Payroll updates the user fields of the earning/deduction to match the accumulator keys. If the driven element is a deduction, the auto-generated arrears accumulators automatically inherit the new key structure. However, you must click the Copy User Fields button to update other auto-generated accumulators, and after an earning or deduction is processed, no additional changes can be made to the driver's user keys (the user keys become unavailable for data entry).

Pages Used to Generate Multiple Resolutions Using Accumulator Drivers

Defining Interactions Between Positive Input Entries and Element Assignments with User Field Sets

This section discusses how Global Payroll processes competing overrides when there are element assignment and positive input entries for the same earning or deduction, and the earnings and deductions have associated user fields.

It explains how Global Payroll:

• Defines user field sets.

• Fills out user field sets.

• Matches earning/deduction assignments with positive input entries.

• Defines the processing order of earning/deduction assignments and positive input entries.

The concepts discussed here are critical to understanding the interaction between positive input entries and element assignments when user fields have been defined.

Important! This section supplements information in the Setting Up Overrides chapter on the interaction between positive input entries and element assignments. You should review the Setting Up Overrides chapter before reading this section.

See Also

Managing Interactions Between Element Assignment Overrides, Positive Input Entries, and Element Definitions

Defining User Field Sets

Global Payroll defines all of the values of the user fields for a given positive input entry or element assignment as a user field set. An earning or deduction can have multiple element assignment and positive input instances, each with its own set of user field values.

For example, the following element assignment and positive input instances for a loan payback deduction are each associated with a different user field set:

Note. In this example, earning/deduction assignment is abbreviated E/D Assignment, and positive input is abbreviated PI.

Filling Out User Field Sets

When an earning/deduction has user fields, the user field values normally come from earning/deduction assignments or positive input entries. Before the system resolves the element, it populates the user fields based on the values entered on the positive input or element assignment pages.

However, if user field values are not defined on the element assignment or positive input pages, the system can retrieve the values from other sources. For example, these values can come from other supporting element overrides (calendar level overrides, or pay group overrides), as well as arrays, formulas, and brackets.

If an earning or deduction with user fields is sliced or segmented, the user fields are populated by slice or segment and may differ from one slice or segment to another.

Matching Earning and Deduction Assignments with Positive Input Entries When There are User Fields

In Global Payroll you can enter multiple element assignment and positive input overrides for the same element within a single pay period, slice, or segment. To manage the competing instructions contained in these overrides, the system matches earning and deduction assignments with their corresponding positive input entries within the same slice or segment, and then determines which elements to resolve and which instructions to follow based on the processing rules described in the Setting Up Overrides chapter of this PeopleBook. In addition, when there are user fields associated with the assigned elements and positive input, the system matches element assignments with positive input entries based on common user field sets.

Note. The system treats element assignments and positive input entries as matching if they are for the same element and occur in the same slice or segment of the pay period and have the same user field sets.

For example:

• Within a given slice or segment, if the user field set of a positive input override matches the user field set of an earning/deduction assignment, the system processes the positive input and not the element assignment.

• Within a given slice or segment, if the user field set of a positive input override does not match the user field set of an earning/deduction assignment, the system processes both the positive input and the element assignment.

In other words, the system treats positive input overrides and element assignments as different elements unless they have matching user field sets; if the user field sets match, the system follows the same processing rules that apply to identical elements without user fields.

See Managing Interactions Between Element Assignment Overrides, Positive Input Entries, and Element Definitions.

Example 1: Partial Matching Between Element Assignments and Positive Input

The deduction LOAN PAYBACK has two user fields:

• User Field 1 = Loan Purpose.

• User Field 2 = Loan Type.

This table lists the positive input entries and element assignments for the deduction:

Note. In this example, earning/deduction assignment is abbreviated E/D Assignment, and positive input is abbreviated PI.

The system resolves three instances of the deduction:

In this example, the system matches positive input Instance 1 with element assignment Instance 1 based on identical user fields and processes only the positive input entry. Because there is no match between positive input Instance 2 and element assignment Instance 2, it processes both instances.

Example 2: Full Matching Between Element Assignments and Positive Input

Deduction A has two user fields:

• User Field 1 = State.

• User Field 2 = City.

This table lists the positive input entries and element assignments for this deduction:

Note. In this example, earning/deduction assignment is abbreviated E/D Assignment, and positive input is abbreviated PI.

The system resolves two instances of the deduction:

In this example, the system matches positive input Instance 1 with element assignment Instance 1, and positive input Instance 2 with element assignment Instance 2. It resolves the positive input entries rather than the element assignments.

Note. Because the value of the base component is not specified in the positive input entries or in the second element assignment, the system goes back to the element assignment and the rule definition for the value of the base.

Example 3: Matching When User Field Values Are Assigned By Another Element

Earning E1 is defined with the user field of State.

The value of State is set by an array and the current value returned by the array is Nevada.

The value of the user field may also be entered as a supporting element override using the element assignment or positive input pages.

This table lists the element assignments and positive input entries for E1:

Note. In this example, earning/deduction assignment is abbreviated E/D Assignment, and positive input is abbreviated PI.

The system resolves three instances of E1:

Example 4: Matching with Additional Type Positive Input

Deduction D1 has a calculation rule of Base x Percent.

It has two user fields:

• User Field 1 = State.

• User Field 2 = City.

This table lists the element assignments and positive input entries for D1:

Note. In this example, earning/deduction assignment is abbreviated E/D Assignment, and positive input is abbreviated PI.

The system resolves two instances of D1:

Because the positive input entry has an action type of Additional, the system resolves the additional instance as well as the deduction assignment; however, the positive input entry does not include a percentage amount, so the system goes to the matching deduction assignment to retrieve the missing percent.

Defining Processing Order

The processing order of an earning or deduction is determined by two factors:

• The element's location and sequence number in a process list or section.

  Process lists and sections help to control the relative order in which different elements are processed.

• The element's process order number.

  The process order is the order in which the system resolves instances of the same element when there are multiple earning and deduction assignments.

Note. You define the relative processing order of multiple instances of the same earning or deduction by using the Process Order field on the Element Assignment By Payee or Payee Assignment By Element pages.

For example, consider these deductions located in the same section of a process list with the following sequence numbers:

When these deductions are assigned to a payee, they are given the following process order:

During payroll processing, the system resolves the main loan deduction before the supplemental loan, because it has the highest priority in the process section. However, there are two instances of the main loan payback deduction. To determine which one to calculate first, the payroll program uses the process order number. In this example, Instance 2 of Main Loan Payback has the highest priority (the lowest process order number), so the system processes it first.

Defining the Process Order in Complex Situations

In the preceding example, the method used to determine the process order is straightforward, because the system is processing only element assignments; however, when element assignments combine with positive input entries, it becomes more difficult to establish a processing sequence.

To do this, the system applies these rules:

Note. The same processing order rules that apply to element assignment and positive input entries in an unsegmented calendar apply in the case of segmented calendars, except that the rules apply per slice or segment. However, there are some additional factors to consider in the case of sliced/segmented calendars. We discuss these later in this chapter.

See Understanding Segmentation with Multiple Resolutions.

The examples in this section illustrate these rules.

Note. These examples show how the system establishes a processing order when there are competing element assignments and positive input entries. The situations represented here occur very infrequently.

Example 1: Defining the Process Order for Multiple Element Assignments and Positive Input Entries

A loan payback deduction has two user fields:

• User Field 1 = Loan Purpose.

• User Field 2 = Loan Classification.

This table lists the element assignments and positive input entries for the loan deduction:

Note. In this example, earning/deduction assignment is abbreviated E/D Ass., positive input is abbreviated PI, and the positive input action types of override and additional are abbreviated Over and Add.

The system resolves six instances of the loan, in the following order:

Following Rule 1, the system resolves the element assignment for 350 first, because it has the lowest process order number (10). It then processes the matching additional positive input entry for 3000.

Note. When an element assignment has a matching additional positive input instance, Global Payroll resolves the element assignment first.

Following Rule 2, the system then processes the positive input entries with the user field set of Car and Personal based on the process order number (30) of the matching element assignment.

In keeping with Rule 2, the system processes the positive input for 500 before the positive input for 600 based on the instance numbers of the positive input entries.

In keeping with Rule 3, the system processes positive input instances without a matching earning/deduction assignment (the positive input entry with the user field set of Bike and Stove) after the entries with matching user field sets.

Example 2: Multiple Earning/Deduction Assignments with the Same User Field Set For More Than One Assignment

A loan payback deduction is defined with these user fields:

• User Field 1 = Loan Purpose.

• User Field 2 = Loan Classification.

This table lists the earning/deduction assignments and positive input entries for the loan deduction:

Note. In this example, earning/deduction assignment is abbreviated E/D Assign., and positive input is abbreviated PI.

The system resolves three instances of the loan payback deduction, in the following order:

In keeping with Rule 1, the process order of the element assignments determines the process order of the positive input entries (thus the element assignment with a process order number of 30 drives the resolution of positive input Instance 1, and so on).

Managing Multiple Resolutions through a Driver When There Are Earning, Deduction, and Positive Input Assignments

This section discusses how Global Payroll processes accumulator-driven elements when there are earning/deduction assignments and positive input entries for the same elements.

It explains how Global Payroll:

• Defines user field sets for earnings and deductions with accumulator drivers.

• Fills out user field sets for an accumulator-driven element.

• Matches element resolutions initiated by accumulator drivers.

• Defines the processing order.

The concepts discussed here are critical to understanding the interaction between accumulator driven elements, positive input entries, and element assignments.

Note. This section supplements the information on the interaction between positive input entries and element overrides in the Setting Up Overrides chapter. You should review the Setting Up Overrides chapter before reading the information in this section.

See Also

Managing Interactions Between Element Assignment Overrides, Positive Input Entries, and Element Definitions

Defining User Field Sets

Earnings or deductions driven by an accumulator inherit their user field sets—their associated user fields and values—from the user keys of the accumulator that drives their resolution.

All earnings and deductions using accumulator drivers must follow these rules:

• The user fields of the earning or deduction must be in the same order as the user keys of the driver accumulator.

• Earnings or deductions cannot be linked to a driver accumulator with no associated user key.

  There must be at least one user field (corresponding to a user key on the accumulator) associated with the earning or deduction.

See Also

Defining Basic Rules for Earnings and Deductions Using Accumulator Drivers

Filling Out User Field Sets

The values of the user fields associated with accumulator-driven elements can come from several different sources. They can come from:

• Supporting element overrides entered on the earning/deduction assignment pages (payee level overrides).

• Overrides values entered at the pay group, calendar, or other levels.

• From arrays, formulas, brackets, or other elements that are set up to populate the user fields.

Matching Element Resolutions Initiated by Accumulator Drivers

In Global Payroll, the same matching rules that apply to element assignments and positive input entries apply in the case of accumulator-driven elements (the matching rules simply extend to the accumulator driven earnings and deductions). In other words, when an element with an accumulator driver instance occurs in the same slice or segment with element assignments and positive input entries, the system compares the user field sets of the element assignments or positive input entries with those of the driver instances to determine to which instances the element assignments and positive input entries apply. A match occurs when the system encounters identical user field sets in the same slice or segment.

See Matching Earning and Deduction Assignments with Positive Input Entries When There are User Fields.

Example 1: Matching Accumulator-Driven Elements with Earning/Deduction Assignments and Positive Input

A tax deduction is defined with a driver accumulator (State Taxable Gross Accumulator).

Every driver instance matches with either an instance of positive input or an element assignment.

The tax deduction has one user field: State.

The tax deduction has a calculation rule of Base x Percent.

Assume that the percent is defined as a formula that uses the state to retrieve the applicable percent.

Assume that the base is defined as CURR_DRIVER_VAL.

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

See Using System Elements.

During payroll processing, the system encounters two instances of the driver:

Note. In this example, earning/deduction assignment is abbreviated E/D Assignment, and positive input is abbreviated PI.

This table lists the earning/deduction assignments and positive input entries for the tax deduction:

The system resolves two instances of the tax deduction in the following order:

In this example:

• There are two instances of the driver element (State 1 and State 2).

• The system matches the driver instance for State 1 with the earning/deduction assignment based on identical user field values.

• The system matches the driver instance for State 2 with the positive input override based on identical user field values.

• The earning/deduction assignment and the positive input entry override the corresponding element definitions.

Example 2: Not All Driver Instances Match with Element Assignments or Positive Input

A tax deduction is defined with a driver accumulator (State Taxable Gross Accumulator).

Not all driver instances match with either an instance of positive input or an element assignment.

The tax deduction has one user field: State.

The tax deduction has a calculation rule of Base x Percent.

Assume that the percent is defined as a formula that uses the state to retrieve the applicable percent, and that the formula returns a value of 3% for states 1, 2, and 3.

Assume that the base is defined as CURR_DRIVER_VAL.

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

See Using System Elements.

During payroll processing, the system encounters three instances of the driver:

Note. In this example, earning/deduction assignment is abbreviated E/D Assign., positive input is abbreviated PI, and the positive input action type of override is abbreviated Over.

This table lists the earning/deduction assignments and positive input entries for the tax deduction:

The system resolves six instances of the tax deduction:

In this example:

• The system matches the accumulator instance for State 1 (6000) with the element assignment for 600. It processes the element assignment and not the accumulator instance (the assignment overrides the accumulator instance).

• The system matches the element assignment for State 5 (175) with its corresponding positive input instance (500). It processes the positive input instance and disregards the element assignment (the positive input overrides the element assignment).

• There are no other user field set matches. The system processes the remaining positive input overrides and the driver occurrences with no matching positive input entry or element assignment (99).

Defining Processing Order

The processing rules that apply when earning and deduction assignments occur with positive input also apply when accumulator driven elements occur in combination with element assignments and positive input:

See Defining Interactions Between Positive Input Entries and Element Assignments with User Field Sets.

• Earning/deduction assignments are calculated first within each unique user field set and dictate the processing order of matching positive input entries.

• After 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, the system processes positive input entries without matching user fields in instance number order.

In addition, the system observes the following rule for accumulator-driven elements:

Driver occurrences with no element assignment or positive input user field set match are processed after positive input entries.

Example: Process Order with Accumulator Driven Elements

A tax deduction is defined with a driver accumulator (State Taxable Gross Accumulator).

Not all driver instances match with either an instance of positive input or an element assignment.

The tax deduction has one user field: State.

The tax deduction has a calculation rule of Base x Percent.

Assume that the percent is defined as a formula that uses the state to retrieve the applicable percent, and that the formula returns a value of 3% for states 1, 2, and 3.

Assume that the Base is defined as CURR_DRIVER_VAL.

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

See Using System Elements.

During payroll processing, the system encounters three instances of the driver:

Note. In this example, earning/deduction assignment is abbreviated E/D Assignment, positive input is abbreviated PI, and the positive input action types of override and additional are abbreviated Over and Add.

This table lists the earning/deduction assignments for the tax deduction:

This table lists the positive input entries for the tax deduction:

The system resolves nine instances of the tax deduction in the following order:

In this example:

• The system processes the user field set with the lowest process order number first (State 1, process order number = 10).

• The system then processes the user field set with the next highest process order number (State 4, process order number = 20).

• The system continues to order and process elements in this way until it runs out of matching user field sets. The last element it processes is a driver occurrence for State 3 with no matching element assignment or positive input entry (the system gives this driver occurrence the highest process order number [the lowest priority].

  Note. The system element CURR_DRIVER_VAL has a value only when an element assignment or positive input entry has a corresponding accumulator driver instance. If there is no corresponding accumulator instance, the value of CURR_DRIVER_VAL is zero. Consequently, when you enter data for earning/deduction assignments or positive input without a driver instance, you must specify the value of the Base and/or Amount fields. Thus, in the current example, the entries for State 4, State 5, and State 6 require a value for the Base or Amount.

Defining Element Eligibility

This section provides an overview of element eligibility and discusses additional eligibility considerations

Understanding Element Eligibility

The standard element eligibility rules apply in the case of multiple resolutions. However, it is important to consider how eligibility is defined when an element resolves multiple times and the element has different user field sets.

Eligibility for an earning or deduction can be defined as:

• By Eligibility Group

  If element eligibility is By Eligibility Group, the element is processed simply by inclusion in the eligibility group assigned to a payee. If the earning/deduction is not in the eligibility group assigned to a payee, the payee is ineligible for the earning or deduction regardless of whether it has multiple earning/deduction assignments or a driver.

• By Payee

  If element eligibility is By Payee, only earning/deduction assignments or positive input entries are eligible for resolution. This is true regardless of whether the element has a driver or driver instances.

Note. The system determines eligibility by slice or segment. For example, if element eligibility for a deduction is defined as By Payee, and there is positive input for the deduction in the first segment of a segmented calendar, the deduction is processed only in the first segment.

In addition to the standard eligibility rules, the following additional rule applies:

Eligibility for an earning or deduction with user fields applies only to that user field set. In other words, a Do Not Apply command applied to an element assignment or a Do Not Process command applied to a positive input entry turns off processing for that user field set only.

The examples in this section illustrate this rule.

Example 1: Eligibility with Element Assignments

A loan payback deduction has these earning/deduction assignments:

Note. In this example, earning/deduction assignment is abbreviated E/D Assignment.

The system resolves one instance of the loan deduction:

Example 2: Eligibility with Positive Input

These positive input entries exist for a state tax deduction:

Note. In this example, positive input is abbreviated PI.

The system resolves one instance of the tax deduction:

See Also

Inserting Elements into Element Groups

Defining Additional Eligibility Considerations

For elements that resolve multiple times as a result of multiple assignments (for example, garnishments and loans), PeopleSoft recommends that you set element eligibility to By Payee. For elements that resolve multiple times as a result of accumulator driver instances, PeopleSoft recommends that you set element eligibility to By Eligibility Group. If you define element eligibility as By Payee for an earning/deduction that is designed to resolve based on driver accumulator instances, the system does not resolve the element unless an assignment is made or there is positive input with an action type of Additional.

Example: A Deduction Set up To Use a Driver Accumulator is Defined as By Payee

A state tax deduction is defined with the element eligibility set to By Payee.

The state tax deduction is defined as Base x Percent, with the percent being 10% of the state taxable gross.

The State Taxable Gross accumulator holds the base and drives the tax deduction.

There is one instance of the driver accumulator:

There is an assignment entered for the state tax deduction:

The system resolves one instance of the deduction for State 1, using the percent and base defined in the calculation rule for the element (10% x 6000 = 60).

Note. If there had been no element assignment in this example, the tax deduction would not have been taken. When eligibility is By Payee, there must be an earning/deduction assignment or a positive input entry of Additional to resolve the element.

Defining Components of a Calculation Rule When an Element Has Multiple Resolutions

When you create an earning or deduction , you can specify that you want to define the amount or a component of the element's calculation rule at the payee level. If you do this, you must enter the amount or the component value on the element assignment or positive input pages. Otherwise, the system will not resolve the element.

However, in the case of elements that resolve multiple time, you need to consider the following before requiring payee level inputs:

• When you set up multiple resolutions that require payee level inputs, the system will not process the element until an amount or the component values are defined for a payee.

• If you specify payee level inputs, and an element has driver accumulator instances, the system only processes the element if there is an assignment or positive input entry with matching user field values (the system ignores driver accumulator instances without a matching positive input or element assignment entry that can provide the value of the missing components). This could result in the element not being processed.

See Also

Setting Up Overrides

Working with Positive Input

Understanding Segmentation with Multiple Resolutions

This section 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.

Element Segmentation with and without Accumulator Drivers

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:

This table contains the accumulator results:

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

See Using System Elements.

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:

This table shows the accumulator results:

This table shows the deduction results:

Proration with Element Segmentation

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

See Using System Elements.

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:

This table contains the accumulator results:

The following table shows the deduction results with proration turned off:

Note. When proration is turned off, the results are overstated.

This table shows the deduction results with proration turned on:

See Also

Proration and Segmentation

Positive Input in a Segmented Calendar When User Field Sets are Defined

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.

See Also

Defining Segmentation

Segmentation Considerations

Filling Out User Field Sets When There is 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 Payee Overrides and Segmentation.

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

The system resolves six instances of the deduction in the following order:

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.

The system resolves six instances of the deduction in the following order:

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.

The system resolves two instances of the tax deduction in the following order:

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.

Defining the Processing Order When There Is Segmentation

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, Defining Segmentation.

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

The system resolves six instances of the deduction in the following order:

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.

The system resolves four instances of the deduction in the following order:

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.

Generating Complementary Rule Instances When There Are Multiple Resolutions with Different User Field Sets

A complementary rule is an earning or deduction that the system resolves automatically to complement an existing element assignment when that assignment's begin and end dates do not encompass the entire pay period.

This section discusses how the system:

• Creates complementary rule instances when there are multiple element assignments and positive input entries for an earning or deduction and the earnings and deductions have associated user field values.

• Defines the process order of complementary rule instances relative to element assignment and positive input entries.

Important! This section supplements the information on complementary rule instances in the Setting Up Overrides chapter. You should review the Setting Up Overrides chapter before reading the information in this section.

See Generating Complementary Rules Instances.

Generating Complementary Rule Instances When There are Multiple Element Assignments and Positive Input Entries with User Field Sets

Complementary rule instances are created only under the specific conditions outlined in the Setting Up Overrides chapter, and the same basic requirements for generating a complementary rule that apply when there are no user fields apply when assignments have associated user field sets.

In addition, the following must be true before the system can generate a complementary rule instance for a specific element assignment:

1. There can be no positive input of the type Override, Resolve to Zero, or Do Not Process with the same user field set in any pay period slice, as this prevents the creation of the complementary rule.

2. There can be no positive input of the type Override or Resolve to Zero already populating the same slice in which the system is attempting to create the complementary rule instance—regardless of whether the positive input has the same user field set as the complementary rule.

Note. The system never generates more than a single complementary rule instance for an assigned element in any slice, even when there are multiple assignments of the same element, and each assignment has a different user field set. For instance, if you assign the same deduction five times in the first slice in a pay period, and apply a different user field set to each assignment, the system generates only one complementary instance in the second slice.

Example: Multiple Assignments with the Same or Different User Field Sets Trigger the Creation of A Single Complementary Rule Instance

Assume that there are two assignments of earning element E1 (calculation rule of Rate x Unit x Percent) and that the assignments have the same user field set. The begin and end dates of the element assignments are June 1 and June 15 respectively:

Note. In this example, element assignment is abbreviated Assign.

The system creates two slices within the calendar based on the assignment begin and end dates (slice 1 = June 1–15; slice 2 = June 16–30).

The system resolves E1 as follows:

1. In slice 1 (June 1–15): 2 x 60 x 100% x .5 (proration factor) = 60

2. In slice 1 (June 1–15): 4 x 60 x 100% x .5 (proration factor) = 120

3. In slice 2 (June 16–31): 5 x 50 x 150% x .5 (proration factor) = 125

The system creates a single complementary rule instance for E1 in slice 2 (June 16–30) by reverting to the rule definition (the definition of the earning specified in the Earning Definition component). Note that the system creates only one complementary rule for the two earning assignments.

Example: A Positive Input Override in One Slice Prevents the Creation of a Complementary Rule in Another Slice

A deduction D1 is set up to trigger element segmentation (and proration) when it is assigned to a payee.

D1 is assigned to a payee with begin and end dates of June 1 – 15.

There is a positive input override for D1 with begin and end dates of June 1 and June 15.

The positive input override and the rule definition share the same user field value.

Note. In this example, element assignment is abbreviated Assign, positive input is abbreviated PI, and the positive input action type of override is abbreviated Over.

The system creates two slices within the calendar based on the assignment begin and end dates (slice 1 = June 1–15; slice 2 = June 16–30).

The system resolves E1 as follows:

1. In slice 1 (June 1–15): 2 x 60 x 100% x .5 (proration factor) = 60

2. In slice 1 (June 1–15): 4 x 60 x 100% x .5 (proration factor) = 120

2. In slice 2 (June 16–30): No complementary rule resolution.

The positive input override in slice 1 (June 1 – 15) prevents the creation of a complementary rule in slice 2 (June 16 – 30). This is because the positive input override has the same user field value (Nevada) as the rule instance that the system attempts to create in slice 2, based on the rule definition entered in the Deduction Definition component.

Example: A Positive Input Override Prevents the Creation of a Complementary Rule Instance in the Same Slice

A deduction D1 is set up to trigger element segmentation (and proration) when it is assigned to a payee.

D1 is assigned to a payee with begin and end dates of June 1 – 10; as a result, the system generates a segmentation trigger with an effective date of June 11.

A segmentation trigger is created as a result of a change in pay rate and deduction D1 is on the segmentation event list; the trigger effective date is June 21.

There is a positive input override for D1 with begin and end dates of June 11 and June 20.

The positive input override and the rule definition do not share the same user field value.

Note. In this example, element assignment is abbreviated Assign, positive input is abbreviated PI, and the positive input action type of override is abbreviated Over.

The system creates three slices within the calendar based on the deduction assignment begin and end dates and the additional segmentation event (slice 1 = June 1–10; slice 2 = June 11–20; slice 3 = June 21–30).

The system resolves D1 as follows:

1. In slice 1 (June 1–15): 3 x 60 x 100% x .33 (proration factor) = 60

In slice 1, the system resolves the earning/deduction assignment.

2. In slice 2 (June 11–20): 4 x 60 x 100% x .33 (proration factor) = 80

Note that the system does not process a complementary rule instance in slice 2. This is because an override in the same period as a complementary rule prevents resolution of the rule. This is true even though the override (user field = Texas) does not have the same user field set as the complementary rule (user field = Nevada).

2. In slice 3 (June 21–30): 3 x 50 x 150% x .33 (proration factor) = 75

The system creates a single complementary rule instance for D1 in slice 3 (June 21–30) by reverting to the rule definition (the definition of the deduction specified in the Deduction Definition component).

Understanding the Processing Order of Complementary Rule Instances

The system uses the process order rules for segmented calendars described earlier to determine which user field set to process first, second, third, and so on when there are element assignment and positive input entries combined with complementary rule instances. In other words, earning/deduction assignments continue to dictate the order of processing; however, the following, additional rules apply when there are complementary rule instances:

When the system generates a complementary rule instance, the resolution order of that instance is determined by the process order number of the element assignment with same user field set (if any) in any slice or segment; within that user field set, however, the system processes the complementary rule instance based on the order of the slice in which it occurs.

Note. If there are multiple element assignments with the same user field set as the complementary rule, the system always uses the lowest process order number from among the assignments to determine the process order.

If there is no user field match between the element assignments and a complementary rule instance, the system processes instances in the order of the slices, using the process order rules described earlier to determine the order. .

The examples in this section illustrate these rules.

Example 1: Process Order When an Element Assignment Shares the Same User Field as the Complementary Rule

An earning E1 is set up to trigger element segmentation (and proration) when it is assigned to a payee.

E1 is assigned to a payee with a begin date of June 16 and a user field value of State = MO; the amount is 3000 and the end date is open.

E1 is assigned to the same payee with a begin date of June 16 and a user field value of State = AR; the amount is 3000 and the end date is open.

At the rule definition level, E1 is defined with a calculation rule of Amount and a user field value of State = MO. The amount is 4000.

Note. In this example, element assignment is abbreviated Assign.

The system resolves three instances of E1 in the following order:

In this example, the process order number of the element assignment with the user field set of MO drives the process order of the matching complementary rule instance; within that user field set, the system processes the complementary rule and associated element assignment in the order of the slices in which they occur (slice 1 before slice 2).

Example 2: Process Order When an Element Assignment Shares the Same User Field as the Complementary Rule

An earning E1 is set up to trigger element segmentation (and proration) when it is assigned to a payee.

E1 is assigned to a payee with a begin date of June 16 and a user field value of State = AR; the amount is 3000 and the end date is open.

E1 is assigned to the same payee with a begin date of June 16 and a user field value of State = MO; the amount is 2000 and the end date is open.

At the rule definition level, E1 is defined with a calculation rule of Amount and a user field value of State = MO. The amount is 4000.

Note. In this example, element assignment is abbreviated Assign.

The system resolves three instances of E1 in the following order:

In this example, as in the previous one, the process order number of the element assignment with the user field set of MO drives the process order of the matching complementary rule instance; within that user field set, the system processes the complementary rule and associated element assignment in the order of the slices in which they occur (slice 1 before slice 2). However, the user field values and process order numbers of the element assignments are reversed in this example (as compared to the previous one). In other words, the assignment with the user field set of AR has a lower process order number (higher priority) than the assignment with the user field set of MO, and is calculated first, respecting slice order.

Example 3: Process Order When an Element Assignment Does Not Share the Same User Field as the Complementary Rule

An earning E1 is set up to trigger element segmentation (and proration) when it is assigned to a payee.

E1 is assigned to a payee with a begin date of June 16 and a user field value of State = KS; the amount is 3000 and the end date is open.

E1 is assigned to the same payee with a begin date of June 16 and a user field value of State = AR; the amount is 2000 and the end date is open.

At the rule definition level, E1 is defined with a calculation rule of Amount and a user field value of State = MO. The amount is 4000.

Note. In this example, element assignment is abbreviated Assign.

The system resolves three instances of E1 in the following order:

In this example, there is no user field set match between the element assignments and the complementary rule instance. The system processes the complementary rule before the assignments following the order of the slices; it processes the assignment with the user field of KS before the assignment with the user field of AR based on their process order numbers.

Retrieving Data for Elements that Resolve Multiple Times

If an earning or deduction has user fields and multiple resolutions occur due to multiple user field sets, the system sums the resolutions when returning a value for the element in a specific segment. The system does not return the value of individual user field instances.

Example: Summing the Value of Individual Instances of an Element

An earning element E2 uses E1 as its base component.

E1 resolves multiple times in a segment, as shown in this table:

Assuming that E2 uses E1 as its base component, the system returns a value of 3500 for E1 when it resolves E2 (2000 + 1000 + 500).

Note. If you need to use the value of individual user field instances of an element in a rule, create segment accumulators with the appropriate user keys. In this example, you could define a segment accumulator for E1 with a user field of State. You could then use this segment accumulator as the base component in the definition of E2.

Defining Arrears

The following rules apply to deduction elements that have user fields and are defined to generate arrears:

• The user fields associated with the deduction automatically default to the auto-generated arrears accumulators as accumulator keys.

  This enables the system to track arrears separately by user field set.

• An arrears payback for a deduction applies only to the instance with matching user field values.

• If a deduction with arrears is sliced but does not resolve—and only the arrears payback is processed—the payback applies to the entire segment rather than to one slice or another in the calendar period.

See Also

Understanding Arrears and Retroactive Processing

Using Generation Control with Multiple Resolutions

Generation control can be set at both the element definition level and the earning/deduction assignment level. Regardless of where generation control is defined it is considered per instance. You can define different generation control parameters for each assignment of an element on the Element Assignment By Payee or Payee Assignment By Element components.

Note. Positive input overrides generation control. In other words, if there is positive input for an element, it is resolved regardless of the generation control parameters.

Note. Retroactive adjustments and arrears paybacks are not affected by generation control, and are always processed.

See Also

Frequency and Generation Control Calculations

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 section 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:

For each resolution of D1, there is a corresponding accumulator instance:

The second time D1 appears on the process list, the system generates only two resolutions:

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:

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:

For each resolution of D1, there is a corresponding accumulator instance:

The second time D1 appears on the process list, the system generates three resolutions, but one resolution has different user field values:

This table shows how the system updates accumulator AC1:

See Also

Defining Element Names

Using Brackets and Formulas to Populate User Fields

When the user fields associated with an earning or deduction assignment are populated by a formula or a bracket, the formula or bracket updates the zero instance of the earning or deduction when it returns a value. In other words, the formula or bracket does not create multiple instances of the element when it populates the user field. For example, assume that earning E1 resolves to 100 USD and that the value of the user field associated with the element is California (user field = State). If the formula or bracket that populates the user field later defines the value of state as Nevada, the system overwrites the earlier value of California and sets the value of the zero instance to Nevada.

See Also

Brackets

Formulas

Defining Retroactive Processing Considerations

This section 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.

Grouping Deltas Using User Field Levels

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:

Note. You set the Retro Delta User Field Level on the User Fields page.

See Defining User Fields for an Earnings Element.

The examples in this section 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:

When Period 1 is recalculated (V1R2), the results are:

The system stores the following deltas for E1 in the result tables:

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:

When Period 1 is recalculated (V1R2), the results are:

The system stores the following deltas for E1 in the result tables:

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:

When Period 1 is recalculated (V1R2), the results are:

The system stores the following deltas for E1 in the result tables:

Note. The system stores deltas by company (User Field 1) in this example.

Processing Retroactive Overrides–Forwarding Options

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.

See Also

Defining Retroactive Processing

Forwarding Deltas with User Fields and User Field Levels

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.

See Also

Grouping Deltas Using User Field Levels

Understanding Complex Retro Processing

Managing Unprocessed Retroactive Deltas

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.

See Also

Managing Unprocessed Retro Deltas

Defining the Retroactive Recalculation Option

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.

See Also

Retroactivity Calculations

Defining Calculation Rules for an Earning Element

Defining Slice Matches and Mismatches

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.

See Also

Retroactivity Calculations

Using System Elements

Global Payroll delivers system elements that you can use to define earnings or deductions that use accumulator drivers to initiate multiple resolutions. The most important of these system elements is CURR_DRIVER_VAL, an element that returns the current value of the driver accumulator when that accumulator is used as the base in the calculation rule of an element.

Example: Using CURR_DRIVER_VAL

When you define an element (earning or deduction) that uses a driver accumulator, you may need to use the driver accumulator in the calculation rule—in addition to using it to drive resolutions of the element.

For example, let's say you define a tax deduction D1 that resolves multiple times based on state taxable earnings. This element is defined as follows:

• State taxable earnings are contained in an accumulator called State Taxable Gross, which has STATE as a user key.

• This accumulator drives resolutions of the tax deduction D1, which has a calculation rule of Base x Percent.

• The percent is defined as a formula that returns a value based on STATE, and the base is taxable gross earnings.

When you define the calculation rule of the element, rather than using the State Taxable Gross accumulator as the base, you can use the system element CURR_DRIVER_VAL to return the current value of the driver accumulator.

There are several advantages of using the system element:

• During processing, the value of an existing driver accumulator instance could change and new instances could be generated, altering the true current values of the accumulator.

  To avoid this problem, the system element CURR_DRIVER_VAL takes a snapshot (copy) of the existing accumulator instances. This snapshot is taken each time the driven earning/deduction is encountered on the process list prior to its resolution, and enables the element to resolve using the correct current values.

• From a performance standpoint, the resolution of an earning/deduction driver is quicker if CURR_DRIVER_VAL is used in the calculation rule than if the accumulator value is accessed directly.

• Using the driver accumulator directly in the earning's or deduction's calculation rule invokes regular accumulator value retrieval logic, which could cause the system to return the wrong row in the accumulator array.

  For example, user key values can change during the resolution of an earning or deduction (via a formula, for example), causing the system to return the wrong driver value (row).

Note. Global Payroll encourages the use of the system element CURR_DRIVER_VAL in place of the driver accumulator to ensure valid results.

Additional System Elements

In addition to CURR_DRIVER_VAL, Global Payroll delivers these system elements which can be used to define earnings/deductions driven by an accumulator:

Note. All of the system elements except ELEM_IS_DRIVER are attributes of an earning or deduction element. ELEM_IS_DRIVER is an attribute of an accumulator.

See Also

Viewing Delivered Elements