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 earnings/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, using instance numbers to cause multiple resolutions of the earning or deduction.

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

   Do this on the Positive Input By Payee page.

   Note. You can enter positive input at other levels as well—for example, at the paygroup and calendar levels.

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 earnings 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 earnings 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 earnings 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 earnings/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 different resolutions of the element:

• 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 different resolutions 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 resolution 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 earnings/deduction definition component to transfer the element's user fields to the auto-generated accumulators.

   If you do this, the system generates different accumulator instances for each resolution with different user field values.

   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 earnings/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 earnings 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 for each resolution of the element.

   This field can be a variable or a system element.

   For example, if you are defining a taxable earnings (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 earnings 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 earnings/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 once 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 earnings/deduction assignments with positive input entries.

• Defines the processing order of earnings/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.

Note. 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 Definitions, Positive Input Entries, and Element Assignment Overrides

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, earnings/deduction assignment is abbreviated E/D Assignment, and positive input is abbreviated PI.

Filling Out User Field Sets

When an earnings/deduction has user fields, it is likely that the values of these fields will come from earning/deduction assignment or positive input entries. Before the system resolves the element, it populates the user fields based on the positive input and element assignment entries.

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 paygroup overrides), as well as arrays, formulas, and brackets.

Matching Earning and Deduction Assignments with Positive Input Entries

To determine how to process an element with both positive input and element assignment entries, the system matches element assignments with positive input entries based on common user fields.

For example:

• If the user field set of a positive input override matches the user field set of an earnings/deduction assignment, the system processes the positive input and not the element assignment.

• If the user field set of a positive input override does not match the user field set of an earnings/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 Definitions, Positive Input Entries, and Element Assignment Overrides.

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, earnings/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, earnings/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. Although it resolves the positive input entries rather than the element assignments, it considers element assignment override values (as well as the element’s rule definition) when calculating deduction amounts.

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

Earnings 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, earnings/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, earnings/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 standard instance; however, the positive input entry does not include a percentage amount, so the system goes to the matching earnings/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 processing order of an earnings/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 deduction. To determine which one to calculate first, the payroll program uses the process order number. In this example, Instance 2 of Main State Tax 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:

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, earnings/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. It then processes the matching additional positive input entry for 3000.

Note. The system processes the element assignment before its corresponding positive input entry—when an element assignment has a matching additional positive input instance, Global Payroll resolves the element assignment first.

Following Rule 1, the process order of the positive input entry for 500 (Resolution 3) comes from the element assignment with the matching user field values of Car and Personal, even though the assignment is overridden by its corresponding positive input entry.

Following Rule 2, the system processes positive input entries with the user field set of Car and Personal based on the process order of the corresponding element assignment—after processing elements with the higher priority user field set of College and Family.

In keeping with Rule 2, the system processes Resolution 3 (Amount = 500) before Resolution 4 (Amount = 600), based on the order 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 Earnings/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 earnings/deduction assignments and positive input entries for the loan deduction:

Note. In this example, earnings/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 lowest process order number from among the element assignments with the same user field values (Car and Personal) determines the process order of the matching positive input entries (thus the element assignment with a process order number of 30 drives the resolution of positive input Instance 1).

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 earnings/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 Definitions, Positive Input Entries, and Element Assignment Overrides

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 earnings/deduction assignment pages (payee level overrides).

• Overrides values entered at the paygroup, 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

The system follows the same rules for accumulator-driven elements that apply when there are only element assignments and positive input entries (except that matching now extends to the accumulator driven elements).

In other words, when an element with a driver accumulator coexists 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 accumulator instances to determine which driver instance the element assignments and positive input entries apply to. A match occurs when the system encounters identical user field sets.

See Matching Earning and Deduction Assignments with Positive Input Entries.

Example 1: Matching Accumulator-Driven Elements with Earnings/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, earnings/deduction assignment is abbreviated E/D Assignment, and positive input is abbreviated PI.

This table lists the earnings/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 earnings/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 earnings/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.

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, earnings/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 earnings/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 (3300).

Defining Processing Order

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

• Earnings/deduction assignments dictate the order of processing and are calculated first within each unique user field set.

• After earnings/deduction assignments, the system processes positive input entries with matching user field sets, followed by positive input entries in instance number order when there is no user field set match.

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

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.

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, earnings/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 earnings/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 define the process order of the various elements in this way until it comes to State 3— a state with a driver occurrence but no matching element assignment or positive input entry. It gives the driver occurrence for this state 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 defining 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 earnings/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 earnings/deduction assignments or a driver.

• By Payee

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

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 earnings/deduction assignments:

Note. In this example, earnings/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 earnings/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

Defining Element Segmentation with Accumulator Drivers and Driver Elements

This section provides an overview of element segmentation with and without accumulator drivers, and discusses how to:

• Define proration with element segmentation.

• Enter positive input in a segmented calendar when user field sets are defined.

• Fill out and process user field sets in a segmented calendar.

Understanding 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 earnings/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 earnings/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:

Defining 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 be out of sync. 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

Entering 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 earnings/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 and Processing User Field Sets in a Segmented Calendar

Global Payroll follows these rules when filling out and processing user field sets in a segmented calendar:

• When an earnings/deduction has 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:

  • Element Assignments: Apply to all slices within a segment.

    Note. Values for user fields not entered through element assignments are determined per slice (this could result in the values being different by slice).

  • Positive Input: A given positive input entry always targets a specific slice. Positive input dates determine the slice into which the positive input entry falls and the user field set applies to that slice only.

    Note. Positive input always overrides segmentation.

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

  • Driver Accumulators: Instances of a driver accumulator have associated user key values. Depending on whether the driver accumulator is on a segmentation event list, the instances may have either slice dates or segment dates. The user key values for each slice or segment of the driver apply to the corresponding segment or slice of the earning or deduction.

• The system processes one user field set at a time, in each slice in which it occurs, before moving on to the next user field set.

  For example, the system processes deduction D1 with the user field set of State = California and Company = AAA in slice 1, slice 2, and then slice 3, before processing D1 with the user field set of State = Nevada and Company = CCC.

  Note. The system uses the matching and process order rules described earlier in this chapter to determine which user field set to process first, second, third, and so on.

  See Matching Earning and Deduction Assignments with Positive Input Entries, Matching Element Resolutions Initiated by Accumulator Drivers.

Example 1: Element Segmentation with Earnings/Deduction Assignments; All Overrides Entered Using Earnings/Deduction Assignments

A deduction D1 is included in an element segmentation event definition.

The deduction does not have an accumulator driver.

Payroll is processed monthly.

A segmentation trigger is defined for April 15.

All user fields are entered as overrides on the element assignment pages.

This table lists the deduction assignments:

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

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

Note. The system resolves assignments in order of process order, and that within a given user field set, the system processes slice 1 first, and then slice 2, before moving on to the next user field set.

Example 2: Element Segmentation with Earnings/Deduction Assignments; Not All Overrides Entered Using Earnings/Deduction Assignments

A deduction D1 is included in an element segmentation event definition.

The deduction does not have an accumulator driver.

Payroll is processed monthly.

A segmentation trigger is defined for April 15.

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, earnings/deduction assignment is abbreviated E/D Assignment.

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

Note. The values of the user fields not entered as element assignments are determined by slice and differ by slice. Also, within a user field set, the system uses process order to determine the element resolution priority.

Example 3: Element Segmentation with Positive Input; Not All Overrides Entered Using Positive Input

A deduction D1 is included in an element segmentation event definition.

The deduction does not have an accumulator driver.

Payroll is processed monthly.

A segmentation trigger is defined for April 15.

Not all user fields are entered as overrides in positive input.

All positive input entries have dates.

This table lists the positive input entries for the deduction:

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

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

Note. Resolution 1 (Slice 1) uses the data defined in positive input Instance 1, and that Resolution 2 (Slice 2) uses the data defined in positive input Instance 2.

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

  However, the system does not process arrears if a deduction does not resolve due to missing payee level data (for example, a deduction is defined with a calculation rule of amount with the Amount Type set to Payee Level). If a deduction instance does not resolve for reasons other than missing payee level data, the arrears payback is processed.

• 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 earnings/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 Earnings/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 earnings 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 can control the level of matching needed to group deltas for a element by defining full or partial user field levels—that is, you can require matching on the first user field only before deltas can be grouped, both the first and second user fields, 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

Forwarding Elements and Defining Retroactive Overrides

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

Managing Unprocessed Retro Deltas

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 Paygroup/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 Earnings 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 earnings/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 and System Data