Defining Retroactive Processing

This chapter provides an overview of retroactive processing, and discusses how to:

• Set up retroactive processing.

• Forward elements and override the default retroactive method.

• Define trigger event IDs.

• Define backward and forward retroactive limits.

• Manage unprocessed retroactive deltas.

• Understand general rules of retroactive processing.

• Understand complex retroactive processing.

Understanding Retroactive Processing

Retroactivity is the process of going back in time and recalculating prior calendars due to changes that were made after the original calculation was run.

Global Payroll provides two methods for calculating retroactivity:

• Corrective Retro

  The corrective method recalculates the elements of a pay run, updating all balance and segment accumulators. The recalculated run replaces the previously calculated run; however, the original results remain available for auditing and reporting purposes.

• Forwarding Retro

  The forwarding method calculates the differences between the original and recalculated pay runs. The differences between the new and old calculations are carried forward to the current calendar period as an adjustment to elements specified by the user. Unlike corrective retro, forwarding retro does not result in the replacement of the original results. Also, balance accumulators are not updated in the recalculated period but in the current calendar period.

The following table lists the differences and similarities between these methods:

Note. The only kind of accumulator that you can forward is a segment accumulator—an accumulator that stores values for a single segment. You cannot forward balance accumulators regardless of the retro method that you use.

Example 1: Corrective Retro—No Exceptions

In this example, Earnings 1 rate changes from 100 to 120; effective date is in period 1; notified in period 2:

This table shows the processing results for the example above:

In this example, only Earning 1 generates a retro delta. The segment accumulator (Net Pay) is updated. No element is forwarded for processing in the current period, and the new value of Earnings 1 replaces its old value. The banking process determines the difference between the net pay from the prior calculation (70) and the recalculation (90). The banking process then processes the resulting amount of 20.

Note. When the retro method is corrective, the banking process determines if any differences exist between the net pay from the prior calculation and the recalculation. Any differences that result are picked up by the banking process for further handling.

Example 2: Forwarding Retro—No Exceptions

In this example, Earnings 1 rate change from 100 to 120; effective date in period 1; notified in period 2:

This table shows the processing results for the example above:

In this example, the retro delta for Earnings 1 is forwarded for processing to the current period (period 2), where it is recorded as an adjustment to Earnings 1.

Even though the retro method is forwarding, not all elements from the first period are forwarded to the second period:

• The Net Pay accumulator isn't forwarded because it already contains the value of Earnings 1.

  If the Net Pay accumulator had been forwarded along with Earnings 1, Earnings 1 would have been counted twice in the current period.

• Balance accumulators aren’t forwarded in Global Payroll because they sum the values of the elements that have potentially already been forwarded, so moving them into the current period would generate incorrect results.

  Also, balance accumulators aren’t normally used for processing—instead, they store values across multiple periods and don’t need to be moved.

Note. Even when the retro method is forwarding, not all elements in the process list are forwarded. On the Retro Process Overrides page, you must individually select the elements that you want forwarded. No element is forwarded automatically.

See Also

Defining Banking Instructions

Integrating with PeopleSoft Enterprise General Ledger

Understanding Key Terms

A number of key terms related to retroactivity occur throughout this chapter. Understanding how they are used will make it easier to follow the examples of retroactive processing presented here.

Version and Revision Numbers

In the following sections you will see numerous references to version and revision numbers. Global Payroll tags each Payee Process Stat record with a version and revision number appropriate to the retro method being used. These version and revision numbers are the vehicles for tracking recalculation of a calendar period due to retroactivity.

The system defines the original set of output results for a calendar calculation as Version 1, Revision 1 (V1R1). Each subsequent recalculation of the calendar increases either the version number or the revision number depending on the retro method:

Prior Results and Recalculated Results

When retroactive processing occurs for a previously calculated period, new results are created for that period. The new results are called the recalculated results. The results from the previously calculated period are called the prior results.

Recalc Period

A period that has been previously calculated and is being recalculated due to retroactivity.

Retro Deltas

When retroactive processing occurs for a given payee, the system recalculates each element generated for the payee. The system compares the recalculated results to the prior results. The difference between these results is typically called the retro delta. A retro delta represents an increase or a decrease that results in an adjustment to the payee’s earnings or deductions.

Retro on Retro

When a period that has already been processed for retroactivity is processed again due to additional retroactive data changes, the occurrence is called retro on retro.

See Also

Tracking Recalculated Calendars

Defining Retroactivity Defaults

Setting Up Retroactive Processing

To set up retroactive processing, use the Countries (GP_COUNTRY) and the Retro Process Definitions (GP_RTO_PRC_DEFN) components.

This section provides an overview of retroactive processing setup and discusses how to:

• Define the retroactivity defaults at the country level.

• Define a retro process.

See Also

Additional Pages Affecting Retroactive Processing

Understanding Retroactive Processing Setup

The steps for setting up retroactive processing are:

1. Specify the retroactivity defaults.

   Using the Countries page, identify a default retro method—forwarding or corrective—for processing retroactivity. There can only be one default method per country, but this method can be developed into a number of distinct processes and even overridden if required. You also use this page to define the retro method to use where there is a conflict and how retroactivity works with banking and General Ledger.

   On the same page, specify whether to store any delta amount or delta component that has a non-zero value, regardless of the setting on the Element Name (GP_PIN) page.

   See Defining Retroactivity Defaults.

   See Defining Country-Level Setup.

2. Define a process.

   Once you have selected a default method, you can further define this method on the Retro Process Definition page. For example, you can use the forwarding method to calculate periods that come before the pay entity calendar year and corrective retro for periods that follow this date—even though your default retro method is forwarding. If you want, you can also override the default retro method on the Retro Process Definition page.

3. Select elements to be forwarded, and set up overrides to the corrective method.

   If your retro method is forwarding, use the Retro Process Overrides page to individually select elements to be forwarded. Global Payroll does not assume that every element in a process list should be forwarded—even when the retro method is forwarding.

   If your default method is corrective, but you want certain elements to be forwarded, specify the elements you want forwarded on the Retro Process Overrides page.

4. Map retro processes to Event IDs.

   After defining a retro method and process, use the Retro Event Definition page to associate each process that you defined in step 2 with a trigger event ID. This event ID is used to identify the process definition (see Step 5).

5. Define trigger fields.

   Once you have linked a process to an Event ID, you must decide which database records and fields you want to make sensitive to retroactive changes in data. You identify these fields and records on the Trigger Definitions - Trigger Definition page and link them to a trigger event ID that you defined in Step 4. Because the trigger event ID contains information about what process to use, any field or record that is linked to this ID triggers the correct process when it encounters a triggering event.

6. Determine which pay entities allow retroactive processing.

   Use the Pay Entity Retro Limits page to decide whether this pay entity allows retroactive processing of its calendars.

7. Specify backward and forward limits.

   After you have defined your retro method, defined the conditions that trigger retro processing, and specified which pay entities allow retro processing, specify (on the Pay Entity Retro Limits page) the backward and forward limits for retro processing (optional). This tells the system how far back in time to go to recalculate closed calendars that are associated with a pay entity, and how long after a payee has been inactive the payee is to remain eligible for retro processing.

   Note. You can override the backward and forward limits at the payee level using the Retro Limits Assignment page.

8. View, add, and cancel retro triggers.

   Once the online system has generated retro triggers, use the Payee Triggers - Retro page to manage retro events so that retroactive processing takes place only when you want it to—and only in response to the appropriate changes in system data. This page enables you to view retro triggers for each payee; you can also add and cancel triggers on this page.

   Note. Retro trigger data is generated by the online system based on conditions that you specify during setup. You can also manually enter retro trigger rows that were not created automatically.

   Warning! Canceling a trigger does not undo the database change that created the trigger in the first place. If there is retro for some other reason, this change may be picked up when prior periods are recalculated.

9. Manage unprocessed retro deltas.

   During forwarding retro—or when using corrective retro with forwarding exceptions—the system forwards deltas from the recalculated calendar as adjustments to the current calendar when certain conditions (matching criteria) have been met. If forwarded retro deltas cannot be processed because the default matching criteria is not met, you can manually direct the deltas to an appropriate calendar by using the Unprocessed Retro Deltas page.

Pages Used to Set Up Retroactive Processing

Defining Retroactivity Defaults

Access the Countries page.

See Defining Country-Level Setup.

Selecting the Corrective Method for Default Retroactive Processing

If you select Corrective as the Default Retroactive Method, the system completes the following steps when retroactive processing occurs:

1. The system recalculates the elements of the pay run that are defined to be recalculated during retroactive processing.

2. Recalculated values for the elements of the pay run replace the previous calculations.

3. The system updates balance and segment accumulators in the recalculated period.

4. The system computes retro deltas and stores them in the recalculated period.

5. The system computes the retroactive adjustment for elements of the pay run that are defined as forwarding element overrides (on the Retroactive Process Overrides page).

6. The banking process determines if any differences exist between the net pay from the prior calculation and the recalculation. Banking processes the differences.

7. The system executes a full reversal of the prior calculation results and posts the recalculated results to General Ledger.

Selecting the Forwarding Method for Default Retroactive Processing

If you select Forwarding as the Default Retroactive Method, the system completes the following steps when retroactive processing occurs:

1. The system recalculates the elements of the pay run that are defined to be recalculated during retro.

2. Recalculated values for the elements are used to compute the retroactive deltas for the recalculated period, but do not replace the previous calculations.

3. The system updates segment accumulators only. (Note that you can define balance accumulators to behave in a corrective manner at the accumulator definition level and on the Earnings/Deduction Accumulators pages even when the retroactive method is forwarding.)

4. The system computes retroactive deltas and stores them in the recalculated period.

5. The system computes the retroactive adjustment for elements of the pay run that are defined to be forwarded (on the Retroactive Process Overrides page.)

6. The banking process picks up only the net pay from the current period calculation because differences from the prior recalculated periods are included in the current period.

7. In order to address the retroactive changes that impact banking recipients and/or general ledger accounts, the system reverses and reinstates previous payments. An example is presented in the following table. In this example, a deduction with a payment of 100 is made to Recipient 1 in January. In February, the recipient changes to Recipient 2, effectively dated in January, thus triggering retroactive processing. The system posts the following recipient and amount information to banking results:

   Month	Version/Revision	Amount	Recipient	Action
   January	V1R1	100	1	Resolution (last period)
   February	V1R2	(100)	1	Reversal
   February	V1R2	100	2	Reinstatement
   February	V1R1	100	2	Resolution (current period)

   In this example, the amount does not change. If the amount changes, the system also reverses the forwarded amount from the element to which the changed amount was forwarded.

Understanding the On Conflict Retro Method

Retro conflicts occur when the system receives conflicting signals about how to process retro. This can occur when:

• An employee is associated with more than one paygroup or pay entity.

• The retro Method Based On dates defined for these paygroups or pay entities call for different retro methods to be used in processing different calendars with the same period ID during the same calculation period.

Say you assign an employee to Paygroup A. The fiscal year (the retro Method Based On date) begins on January 1, 2000. For the same employee in Paygroup B, the fiscal year begins on 1 March 2000. Assume that a retro event reported in March causes the February pay period to be recalculated and that the method you’ve defined for processing this event varies by Pay Group Fiscal Year (in both paygroups the Before Method is Forwarding and the After Method is Corrective). This situation can be represented as follows:

Understanding the on conflict retro method

To recalculate the February pay period, Paygroup A uses corrective retro, while Paygroup B uses forwarding retro. The same event calls for the use of conflicting retro methods for processing the same period, even though the process definition is the same (the method is forwarding before the Pay Group Fiscal Year and corrective after the Pay Group Fiscal Year). To resolve this conflict, you select a retro conflict method on the Countries page.

Note. The system creates a payee process stat record for each payee for each calendar, including retro. When you specify a retro conflict method, you ensure that consecutive payee process stat records with the same period ID are processed using a single retro method.

Defining a Retro Process

Access the Retro Process Definition page.

Retro Process Definition ID (retroactive process definition ID)	Identifies the retro process you are defining.
Retro Method	The default value is from the Countries page. You can override it.
Retro Method Varies	Select if you want the retro method to vary based on a predefined date. The Retro Method Decided By group box fields become available for entry. You can vary the retro method in relation to the Pay Entity Calendar Year, Pay Entity Fiscal Year, or Pay Group Fiscal Year. For example, you can use forwarding retro to calculate periods that come before the pay entity calendar year, and corrective retro for periods that follow this date—even though your default retro method is forwarding. If you leave this check box cleared, the default retro method (from the Countries page) remains constant across all calendar periods.

Retro Method Decided By

The fields in this group box enable the system to determine the date and year the retro method varies and are available only if you selected Retro Method Varies.

Determining the Date and Retro Method When the Retro Method Varies

The system determines the retro method change date and the retro method as follows:

1. Determine the retro method change date.

   Using the Method Based On and Determine Year By field values, the system determines the day, month, and year on which the retro method varies (the retro method change date). The year is based on the Period End Date or Pay Date of the first current calendar that the payee is included in—depending on the Determine Year By field value. The month of the Period End Date or Pay Date of the current calendar is then compared to the month that appears in the Method Based On field:

   • If the current calendar month is less than the month that you selected in the Method Based On field, the system subtracts one year from the Determine Year By field value to determine the year for the retro method change date.

   • If the month of the first current calendar is greater than or equal to the month in the Method Based On field, then the year that is associated with the Determine Year By field value is used.

     Example 1: Using Period End Date to determine the retro method change date:

     First Current Calendar Period:	December 1 to December 31, 1999
     Determine Year By:	Period End Date	December 31, 1999
     Method Based On:	Pay Entity Calendar Year	January 1
     Retro Method Change Date:	January 1, 1999

     Example 2: Using Pay Date to determine the retro method change date:

     First Current Calendar Period:	December 1 to December 31, 1999
     Determine Year By:	Pay Date	January 2, 2000
     Method Based On:	Pay Entity Calendar Year	January 1
     Retro Method Change Date:	January 1, 2000

     Example 3: Calendar Month is less than Method Based On month:

     First Current Calendar Period:	March 1 to March 31, 1999
     Determine Year By:	Period End Date	March 31, 1999
     Method Based On:	Pay Entity Fiscal Year	April 1
     Retro Method Change Date:	April 1, 1998

2. Determine the retro method to use.

   The retro method change date is compared to the Period End Date of each recalc period:

   • If the Period End Date of the recalc period is greater than or equal to the Retro Method Change Date, then the After Method is used.

   • If the Period End Date of the recalc period is less than the Retro Method Change Date, then the Before Method is used.

The following table shows how the correct retro method is applied, given these conditions:

• Default Retro Method is Forwarding.

• Retro Method Varies is selected.

• Before Method is Forwarding.

• After Method is Corrective.

  To Determine Retro Method Change Date				To Determine Method to Use
  Method Based On	Current Calendar Period	Determine Year By	Retro Change Date	Recalc Period and Method Used
  Calendar Year: January 1	December 1–31, 1999	Period End Date: December 31, 1999	January 1, 1999	#1: November 1–30, 1998/Before Fwd) #2: March 1–31, 1999/After (Cor)
  		Pay Date: January 2, 2000	January 1, 2000	#1: November 1–30, 1998/Before (Fwd) #2: March 1–31, 1999 / Before (Fwd)
  Fiscal Year: July 1	March 1–31, 1999	Period End Date: March 31, 1999	July 1, 1998	#1: May 1–31, 1998/Before (Fwd) #2: November 1–30, 1998/After (Cor) #3: February 1-28, 1999/After (Cor)
  		Pay Date: April 1, 1999	July 1, 1998	#1: May 1–31, 1998/Before (Fwd) #2: November 1–30, . 1998/After (Cor) #3: February 1–28, 1999/After (Cor)
  	August 1-31, 1999	Period End Date: August 31, 1999	July 1, 1999	#1: May 1–31, 1999/Before (Fwd) #2: June 1–30, 1999/Before (Fwd) #3: July 1–31, 1999 /After (Cor)
  		Pay Date: September 1, 1999	July 1, 1999	#1: May 1–30, 1999/Before (Fwd) #2: June 1–31, 1999/Before (Fwd) #3: July 1–31, 1999/After (Cor)

Fwd = forwarding method

Cor = corrective method

Example: Selecting the Use Current Results+Adjustment Check Box to Process General Ledger When the Retro Method Varies Check Box is Selected

Let's suppose that you select:

• The To Process General Ledger check box (in the Use Current Results+Adjustment group box) on the Countries page.

• The Retro Process Varies check box on the Retro Process Definition page.

• The following values in the Retro Process Decided By group box:

  • Method Based On: Pay Entity Calendar Year

  • Determine Year By: Pay Date

  • Before Method: Forwarding

  • After Method: Corrective

You have an Earnings/Deduction Assignment that is dated December 1, 2002 through December 31, 2003. You process payrolls for December 2002 and January 2003, and run the General Ledger process for both months. Subsequently, you change the value of the override, but don't change the dates, so retroactivity dates back to December 1, 2002 when you run payroll for February 2003.

Because the retro method varies, the retroactive process applicable to December 2002 is forwarding retro, whereas the retroactive process applicable to January 2003 is corrective retro. When you run the General Ledger process for February 2003, you will see that both retroactive methods, corrective and forwarding, appear in the General Ledger results. The forwarding method will have the delta or adjustment included in the February amount; the corrective method will reverse and correct previous entries.

Forwarding Elements and Defining Retroactive Overrides

To select elements to be forwarded and to override corrective behavior, use the Retro Process Overrides (GP_RTO_OVR_DEFN) component.

This section discusses:

• Rules for forwarding elements and overriding corrective retro.

• Pages used to forward elements and define overrides.

Understanding Rules for Forwarding Elements and Defining Overrides to Corrective Retro

If your retro method is forwarding, you must individually select elements to be forwarded on the Retro Process Overrides page. Global Payroll does not assume that every element in a process list should be forwarded—even when the retro method is forwarding.

If your default method is corrective, but you want certain elements to be forwarded, you must specify the elements you want forwarded on the Retro Process Overrides page.

This section discusses:

• Defining elements to be forwarded.

• Defining overrides to corrective retro.

Defining Elements to Be Forwarded (when the retro method is forwarding)

If your default retro method is forwarding:

• Specify each element that is to be forwarded (on the Retro Process Overrides page).

• The only types of elements that can be forwarded are earnings, deductions and accumulators. (Only deltas from segment accumulators can be forwarded.)

• If an element is an earnings or a deduction, you can either forward the value of the element’s retro delta to the same element, or define a separate “Forward To Element” to receive this value.

• When you forward the delta for an earnings, the “Forward To Element” can be an earnings or a deduction.

• When you forward the delta for a deduction, the “Forward To Element” can be an earnings or a deduction.

• If you forward a segment accumulator, you cannot forward it to the same element (or even a different accumulator) because a segment accumulator can be forwarded only to an earnings or a deduction.

• If the forwarded element contains components and is forwarded to a different element, the component adjustments will be applied only if the Forward To Element” calculation rule is the same. For example, if the element is defined as “Percent of Base” and the “Forward To Element” is defined as a “Percent of Base,” then the differences for the amount and the base are forwarded. If the “Forward To Element” does not obey the same rule, then only the adjustment amount is forwarded.

Note. With forwarding retro, you can define balance accumulators to behave in a corrective manner at the accumulator definition level and on the Earnings/Deduction Accumulators pages.

Defining Overrides to Corrective Retro

If your default retro method is corrective, but you want to forward the delta for a specific element (that is, you want to override the default method for this element):

• You must forward the retro delta to a different element by designating a “Forward To Element” on the Retro Process Overrides page. This element receives the value of the element’s retro delta in the current period. However, you must have already defined the element on one of the element definition pages.

  Note. You cannot forward a retro delta to the same element if your method is corrective.

• The only types of elements that can be forwarded are earnings, deductions and accumulators.

• When you are forwarding the delta for either an earnings or a deduction, the “Forward To Element” can be either an earnings or a deduction.

• When you are forwarding the delta for an accumulator (only segment accumulators can be forwarded), the “Forward To Element” must be an earnings or a deduction (it cannot be another accumulator).

• If the forwarded element contains components and is forwarded to a different element, the component adjustments are applied only if the “Forward To Element” calculation rule is the same. For example, if both the element and the “Forward To Element” are defined as “Percent of Base,” then the differences for the amount and the base are forwarded. If the “Forward To Element” does not follow the same rule, then only the adjustment amount is forwarded.

• If you forward the Net Pay element, banking will not reverse the net pay element from the prior calculation, nor will it insert the new recalculated net pay entry.

Page Used to Define Overrides and Select Elements for Forwarding

Defining Overrides and Selecting Elements for Forwarding

Access the Retro Process Overrides page.

Common Page Elements

Element Overrides

Select the Retro Process Overrides - Element Overrides tab.

Forwarding Options

Select the Retro Process Overrides - Forwarding Options tab.

Forward	This check box is selected if your method is forwarding, and you enter elements for forwarding in the Entry Type and Element Name fields. The forwarded element is forwarded to itself unless you select the Forward to Different Element check box. This check box is also selected for segment accumulators and cannot be changed. (Segment accumulators must be forwarded to a different earning or deduction.)
Forward to Different Element	Select to forward the value of an element to a different element in the current period. If your default method is forwarding, and you specify an element to be forwarded, that element is forwarded to itself unless you select this check box and specify a “Forward To” element. If your default method is corrective and you decided to forward an element, this check box is selected, and you must define the element to receive the value of the original element. If a segment accumulator is selected, this check box is selected automatically and is unavailable for entry.
Forward to Entry Type	This is the type of element that is to receive the value of the original element in the current period when you select Forward to Different Element. Values are Deduction and Earnings.
Forward to Element	Select the name of the “Forwarded To” element that will receive the value of the original element.

Example: Corrective Retro—with Forwarding Exceptions

Scenario:

• Earnings 1 rate changes from 10 to 12; effective date in period 1; notified in period 2.

• Deduction 1 is defined not to be recalculated during retro processing.

• Segment accumulator for Earnings 1 + Earnings 2 is forwarded to Earnings 2 in the current period.

• Additional element definitions:

  • Earnings 1 = Hours worked × Pay Rate

  • Deduction 1 = 10% of Segment Accumulator

  • Deduction 2 = 20% of Earnings 1

  • Segment Accumulator = Earnings 1 + Earnings 2

  • YTD Accumulator Earnings = Earnings 1

YTD Accumulator Deductions = Deduction 1 + Deduction 2

Calendar period, current results, and retroactive adjustment:

In this example, the original values of the earnings, deductions and accumulator elements are replaced when retroactivity is calculated. While this is consistent with corrective processing, note that the segment accumulator for Earnings 1 has been forwarded to Earnings 2 in the current period. There is a forwarding exception to the standard corrective method. Also, Earnings 2 does not contribute to the gross earnings, so it is not included in the net pay calculation.

What happens as a result of forwarding the segment accumulator for Earnings 1?

• Because this accumulator is the basis for calculating Deduction 1 (Deduction 1 = 10% of segment accumulator E1 + E2), forwarding the accumulator delta to the current period results in the system taking any additional deduction in period 2 rather than in the recalc period.

• Forwarding the accumulator delta to the current period would create a problem if deduction 1 were also being calculated in the recalc period—it would result in the deduction being calculated twice based on the same earnings. However, deduction 1 has been defined as do not recalculate on retro, so no new deduction is taken in the recalc period even though E1 increases from 200 to 240.

• The banking process determines if any differences exist between the net pay from the prior calculation and the recalculation. Any differences that result are processed by banking. In this case, the difference is 32.

Example: Forwarding Retro—with Accumulator Defined to Use Corrective Behavior

Scenario:

• Earnings 1 changes from 100 to 200; effective date in period 1; notified in period 2.

• Earnings 2 changes from 100 to 200; effective date in period 1; notified in period 2.

• Deduction 1 is defined as a forwarded element and is forwarded to itself.

• Net Pay Accumulator is forwarded to a different element—Earnings 3.

• Additional element definitions:

  • Deduction 1 = 10% of Earnings 1 + Earnings 2

  • YTD Accumulator Earnings = Earnings 1 + Earnings 2

  • YTD Accumulator Deductions = Deduction 1

In this example, because Net Pay is being forwarded to Earnings 3 in period 2, a delta will be created, though typically this is not done for accumulators. The balance accumulator (YTD Earnings 1 + Earnings 2) is “replaced” in the recalc period—it has been defined to follow corrective behavior even though the retro method is forwarding. When period 1 is recalculated due to retroactivity, the Net Pay delta is retrieved as an adjustment to Earnings 3 in period 2. If this were the only processing that took place, the YTD Accumulator would be incorrect in period 2 because none of the earnings that make up the YTD Accumulator have been forwarded. However, because the YTD Accumulator is corrected in period 1, the balance in period 2 is correctly recorded as 800. Also, the delta for Deduction 1 is forwarded in period 2. This has the effect of correcting the YTD Accumulator Deduction balance in period 2.

See Also

Defining Element Names

Defining Earning and Deduction Elements

Setting Up Accumulators

Defining Trigger Event IDs

To define trigger event IDs, use the Retro Event Definitions (GP_RTO_EVT) component.

This section provides an overview of triggers and discusses how to associate a triggering event with a process.

Understanding Triggers

The mechanism that is used to track online data changes that should trigger retro processing is called a trigger. When a change occurs to a field that has an effective date or begin and end dates, or to a record that has been defined as sensitive to retroactive changes, the system writes a line of data to the trigger tables to enable retroactive processing in the batch. This data includes which payees to process, what periods to consider for recalculation, what process to use, and so forth. At processing time, the system reads this data. You must specify which records and fields should cause data to be sent to the trigger tables in response to retroactive changes:

1. Use the Retro Event Definition page to associate the events (such as retroactive pay increases) that should trigger retroactivity to one of the processes you defined on the Retro Process Definition page. This association—between an event and a process definition—is identified in the system through a trigger event ID.

2. Use the Trigger Definitions - Trigger Definition page to map trigger fields or records to one of the trigger event IDs that you defined on the Retro Event Definition page. This ID tells the system what process to use when fields or records are modified—it is one of the pieces of information that is written to the trigger tables when fields or records are modified.

   Note. Because the Trigger Definitions - Trigger Definition page is documented in the chapter “Setting Up Triggers,” this section describes only the use of the Retro Event Definition page.

Page Used to Associate a Triggering Event

Associating a Triggering Event with a Process

Access the Retro Event Definition page.

Country	This display-only field is populated based on the country that you selected on the search page.
Trigger Event ID	This display-only field is populated based on the trigger event ID that you selected on the search page. Link each trigger event ID to one of the processes you defined on the Retro Process Definition page.
Retro Process Definition ID	Select a process that you defined on the Retro Process Definition page to link to the trigger event ID. Note. Different countries can process the same event differently.
Absence Event	Select if the trigger event ID is for an absence event only.

Example of an Absence Event

The Absence Event indicator determines the first calendar for recalculation, which avoids processing calendars unnecessarily. Selection of the indicator depends on such things as the processing order of the calendars for a particular period, as well as what absence related trigger definitions have been defined and to which retro events they point. When the indicator is set to yes, processing can start at the first absence calendar instead of the first calendar that qualifies after checking retro limits.

For example, company A runs the payroll process once a month. The calendar group is composed of two calendars. The first calendar is for payroll, and the second one is for absence. This order is always maintained. Assume that the month of January has been processed. The payroll calendar is processed for January, while the absence calendar is processed in January to feed the February payroll calendar. The current period is February. Changes are made to January absence data. Retro triggers for absence back to January are generated and point to a retro event ID where the absence indicator is set to yes. When the batch is processed for February, retroactive processing goes back to January. The first and only calendar that is recalculated is the absence calendar. The payroll calendar is ignored for retro processing.

Note. Absence balance accumulators are always defined as corrective—they must be updated (replaced) at the end of each payroll calculation period. Because balance accumulator behavior is driven by the retro method, when your default method is forwarding, remember to define the absence balance accumulator behavior as “Use Corrective” when you define your accumulators on the accumulator definition pages.

See Also

Setting Up Triggers

Understanding Absence Management

Setting Up Accumulators

Defining Backward and Forward Retroactive Processing Limits

To define backward and forward retroactive processing limits, use the Pay Entities (GP_PYENT) and Assign Retro Limits (GP_PYE_RTO_LIM) components.

After you have defined your retro method and the events that will trigger retro processing, you specify the backward and forward limits for retro processing. This tells the system how far back in time to go to recalculate closed calendars (backward limit) and how long after a payee who has been inactive or terminated is eligible for retroactive processing (forward limit).

Note. You can override backward and forward limits you define at the pay entity level using the Retro Limits Assignment page at the payee level.

To define backward and forward retroactive processing limits, use the Pay Entities (GP_PYENT) component.

This section provides overviews of backward limits and forward limits, and discusses how to:

• Define backward and forward limits for retro processing at the pay entity level.

• Define backward and forward limits for retro processing at the payee level.

Understanding Backward Limits

The number of periods that are recalculated is determined by the interaction of the following dates:

The following diagram illustrates the interaction of the dates that determine the number of past periods that are recalculated.

First recalculation period

The first recalculation period is determined by comparing the trigger effective date to the backward limit date and comparing both dates to the calculation begin date.

Understanding Forward Limits

When the system calculates retroactivity for inactive payees, it first determines whether it is still within the forward limits. If it is, the system determines how far back it can go based on the backward limits.

Determining forward limits is easier than determining backward limits because there are no trigger effective dates to compare to forward limits, and you don’t consider the No Retro Processing Before Date. You just decide how long a payee is eligible for retroactive payment after his or her last inactive date. If the payee is eligible, then the guidelines (for backward limits) that are described above apply for determining the number of past periods to recalculate.

For forward limits to apply, a payee must be inactive in all jobs (EMPL_STATUS on the Job record is used to validate the payee’s status). A payee is considered inactive if the EMPL_STATUS value is D (deceased), R (retired), T (terminated), V (terminated pension payout), or X (retired-pension administration). If a payee has multiple jobs, the highest effective date of all rows that are returned is used as the inactive date.

Pages Used to Define Backward and Forward Retroactive Processing Limits

Defining Backward and Forward Limits for Retro Processing at the Pay Entity Level

Access the Retro Limits page.

Process Retro

This field determines whether this pay entity allows retro to be processed. You can override it at the payee level.

Retro Period Backward Limit

In this group box, you limit the number of calendar periods that the system goes back when processing retroactivity.

Using Backward Limit Criteria to Determine the First Retro Period to Recalculate

Example 1: Using months criterion.

The backward limit is determined by going back two months from the current calendar period begin date of June 1, 1999, providing a backward limit date of April 1, 1999. The system compares the backward limit date to the trigger effective date. The trigger effective date precedes the backward limit date, so the system uses the backward limit date to determine the first retro period. Two periods will be recalculated. April (April 1, 1999−April 30, 1999) and May (May 1, 1999−May 31, 1999).

Example 2: Using years, months, and days criteria (trigger effective date does not exceed backward limit date).

The backward limit is determined by going back one year (the start year is determined by the year of the begin date of the first calendar) and applying the month and day that are defined: The result is a backward limit date of March 15, 1998. The system compares the limit to the trigger effective date, which (in this example) is used to determine the first retro period because it does not exceed the backward limit date. Twelve periods will be recalculated.

Example 3: Using years, months, and days criteria (trigger effective date exceeds backward limit date).

The backward limit is determined by going back one year (the start year is determined by the year of the begin date of the first calendar) and applying the month and day that are defined: The result is a backward limit date of March 15, 1998. The system compares that date to the trigger effective date, which (in this example) exceeds the backward limit date, so that the backward limit date determines the first retro period. Fifteen periods will be recalculated.

Retro Period Forward Limit

In this group box, specify the amount of time that retro can continue to be calculated after a payee is terminated or becomes inactive.

Using Forward Limit Criteria to Determine the First Retro Period to Recalculate

Example 1: Using months criterion (calendar period does not exceed forward limit).

The forward limit is determined by going forward 12 months from the inactive date. The current calendar period does not exceed the forward limit, so retro processing can occur. The retro triggers are compared to the backward limits to continue the process.

Example 2: Using months criterion (calendar period exceeds forward limit).

The forward limit is determined by going forward 3 months from the inactive date. The current calendar period (in this example) exceeds the forward limit, so retro processing cannot occur. The retro triggers are ignored and marked as used.

Defining Retro Processing Limits at the Payee Level

Access the Retro Limits Assignment page.

No Retro Processing Before	This date is the date when Global Payroll begins processing calculations for a payee. It is set by the system, but you can override it. The system cannot process retroactivity for a payee prior to this date. If a payee has multiple jobs, be sure that this date is correct, to support all jobs.
Use Pay Entity Retro Limits	Select to use the retro limits that are defined for the pay entity to which the payee belongs. When this check box is selected, the system uses the values from the pay entity definition, and all other fields on this page, other than No Retro Processing Before, are unavailable for entry. When this check box is cleared, the Process Retro check box becomes available for entry, and the system uses the values that were entered at the payee level, rather than those that were entered at the pay entity level.
Process Retro	Select if you want the retro calculation to be processed. If you select this check box, the fields in the Backward Limit and Forward Limit group boxes become available for entry.

See Also

Defining Backward and Forward Limits for Retro Processing at the Pay Entity Level

Managing Unprocessed Retro Deltas

This section provides an overview of forwarding retro deltas and discusses how to manage unprocessed retro deltas.

Understanding Forwarding Retro Deltas

During forwarding retro—or when using corrective retro with forwarding exceptions—the system forwards adjustments from the recalculated calendar to the current calendar when the following conditions have been met:

For each EmplID (employee ID)/Empl Rec# (employee record number) combination:

• The paygroup of the delta that is to be forwarded matches the paygroup of the current calendar.

• The pay entity of the delta that is to be forwarded matches the pay entity of the current calendar.

• The run type of the delta that is to be forwarded matches the run type of the current calendar.

• The process order timestamp of the retro delta precedes the process order timestamp of the current payee process status record.

• If these conditions are not met, you can (on the Unprocessed Retro Deltas page) manually forward adjustments to the appropriate target calendar from the source calendar that generated the retro deltas.

When to Forward Retro Deltas

Suppose that a payee moves from paygroup A to paygroup B at the beginning of the current period, and that previous periods must be recalculated due to retroactivity. The current calendar for paygroup B no longer matches the original calendar from which adjustments are being retrieved (paygroup A). In situations like this—when paygroups no longer match—you must tell the system where to forward the retro deltas.

Page Used to Manage Unprocessed Retro Deltas

Managing Unprocessed Retro Deltas

Access the Unprocessed Retro Deltas page.

On this page, you:

• Specify the calendar ID and paygroup of the target calendar (the target paygroup must have the same pay entity as the source calendar).

• Redirect the deltas to another element (optional).

• Mark the deltas as do not process (if you do not want them to be forwarded at all).

Segment Data

For Selected Deltas

In this group box, specify an action for unprocessed retro deltas.

Common Page Elements

Forwarding Options

Select the Unprocessed Retro Deltas - Forwarding Options tab.

Values

Select the Unprocessed Retro Deltas - Values tab.

Unit	This value is a component of the element.
Base	This value is a component of the delta amount for the element.

User Fields

Select the Unprocessed Retro Deltas - User Fields tab.

This tab displays the user fields defined for each element.

See Also

Defining User Fields for an Earnings Element

Additional Pages Affecting Retroactive Processing

In addition to the pages and procedures described earlier in this chapter, several other pages affect retro processing. These pages are of two types—general setup pages and calendar setup. The following table describes these pages:

Understanding General Rules of Retro Processing

The information in this section is meant to provide an in-depth picture of how the system processes retroactivity.

This section discusses how Global Payroll:

• Tracks recalculated calendars.

• Calculates retro deltas and processes adjustments.

• Loads balance accumulators.

• Stores recalculated results.

• Reverses previous results.

Tracking Recalculated Calendars

In this section are numerous references to version and revision numbers. Global Payroll tags each Payee Process Stat Record (payee process status record) with a version number and a revision number that is appropriate for the retro method that is being used. These numbers are used to track the recalculation of a calendar period due to retroactivity.

The system defines the original set of output results for a calendar calculation as Version 1, Revision 1 (V1R1). Each subsequent recalculation increments either the version number or the revision number, depending on the retro method:

The system uses these numbers to determine which calculations to use as the old and new values when processing retro deltas.

Version and Revision Numbers Used When Calculating Retro on Retro

When the system calculates retro on retro—that is, when a period is recalculated more than one time—and the retro method changes, the numbering scheme becomes more complex. In the following example, five consecutive periods are recalculated using the forwarding method on the first pass and a combination of forwarding and corrective on the second pass.

Scenario:

The retro method changes from corrective to forwarding in period 3 when retro is first processed. The second time that retro is processed, the method changes from forwarding to corrective in the same period.

In the following table, P1 to P6 represent periods 1 to 6.

When forwarding follows corrective, the revision number increases by 1, and the version number remains the same as it was in the last maximum corrective run. However, when corrective follows forwarding, the version number increases by 1, and the revision number goes back to 1. This has important consequences for how the system calculates retro deltas.

See Calculating Retro Deltas and Processing Adjustments.

Version and Revision Numbers in Retro Adds

A retro add is a situation in which a previous gross-to-net does not exist for a payee, and retroactivity calls for a payee process status record to be created for the first time. For example, it is determined that a payee whom you thought was hired in February was actually hired in January. There is no gross-to-net for January, so when January is processed for retro, the system must create a payee process status record for the period and assign version and revision numbers to it.

• Retro adds when the retro method is forwarding.

  When the retro method is forwarding, the revision number must be greater than 1. If a previous gross-to-net does not exist, and a retro add results in a gross-to-net for the first time, the calculation is labeled V1R2 even though it is technically the first gross-to-net. The reason is that forwarding retro does not replace the original results of a calculation with new ones, but uses them to generate retro deltas. V1R2 is created only to calculate the deltas that are to be brought forward to the current period. V1R1 is not used because these are not the true results for the period.

• Retro adds when the retro method is corrective.

  When the retro method is corrective, a previous gross-to-net does not exist, and a retro add results in a gross-to-net for the first time, the first calculation is labeled V1R1. The reason is that corrective retro replaces the results of the prior pay calculation (it does not use them only to create retro deltas), so when a period is added, it treats this period as if it were the original one.

The following tables illustrate how the system numbers payee process status records in retro add situations using forwarding and corrective retro.

Scenario:

In the following retro adds, it is discovered that a payee who was calculated as part of period 1 does not belong to that period. The calculations for the payee are therefore reversed in Recalc No. 2. When the payee is later added back because is it discovered that he or she belongs to the calendar after all, a new gross-to-net is created using the version and revision numbers that are indicated in Recalc No. 3.

In each example, all calculations for the payee are reversed in Recalc No. 2 when the payee is eliminated from the calendar. When the payee is later restored (when it is discovered that he or she belongs in the original calendar), a new gross-to-net is created. The new calculation uses the numbering that is indicated in Recalc No. 3.

See Also

Retroactive Adds

Retroactive Deletes

Calculating Retro Deltas and Processing Adjustments

This section provides information about how the system calculates retro deltas and processes adjustments.

Calculating Retro Deltas

In forwarding retro, the Delta = New Value - Old Value (the old value is the value from the last revision of the previous calculation [maximum revision]).

In corrective retro, the Delta = New Value - Old Value (the old value is the value from the previous version, Revision 1).

When you calculate deltas, the old value of an element (earning or deduction) includes any adjustments that were forwarded to it from recalculated periods. Similarly, the new value of an element (earning or deduction) calculated for the current period includes adjustments that were forwarded to that element as a result of a recalculation in the previous period.

Note. There is an exception to the rule that the new value of an element always contains adjustments that were forwarded to that element when it was calculated in a previous run. This exception is discussed in Example 3 under Deltas and Adjustments When The Retro Method Changes.

Calculating Deltas When Corrective Follows Forwarding

With corrective retro—or when corrective follows forwarding—the system defines the old value as the previous version, Revision 1. Take the following example of a period, which is recalculated twice due to retro—first using forwarding retro and again using corrective retro. If the value of earnings E1 equals 20 in period 1 (V1R1), increases to 30 in the first recalculation (V1R2), and increases to 40 in the last recalculation (V2R1), the deltas are derived as follows:

To calculate the second retro delta in V2R1, when the retro method changes from forwarding to corrective, the system takes the new value of E1 (40) and subtracts the value of E1 in the previous version, Revision 1 (20). It skips over the value of E1 in V1R2 (the previous version, Revision 2) because V1R2 is a virtual calculation and doesn’t represent the last true value.

Processing Adjustments

If the retro method is forwarding, the rule for calculating adjustments is that the forwarded adjustment is equal to the sum of all calculated deltas for an element (per element). If you have defined payment keys, the calculated deltas are summed respecting those keys.

See Payment Keys with Forwarding Retro.

Example 1: Processing Deltas and Adjustments in Forwarding Retro

The following example of retro on retro illustrates how the system calculates deltas and processes adjustments when using the forwarding method.

Scenario:

• In period 2, E1 changes from 10 to 20. The first retro calculation involves retro in period 2 back to period 1.

• In period 3, E1 changes from 20 to 30. The second retro calculation involves retro in period 3 back to period 1.

In this example, the system calculates retro deltas by taking the new value of E1 minus the old value of E1 (old value is defined as the last revision of the previous calculation).

First retro calculation:

• Period 1 (V1R2): E1 = 20

  Delta = 10 [20 (V1R2) − 10 (V1R1)]. Pulled in to period 2 (V1R1) as an adjustment.

• Period 2 (V1R1): E1 = 30 (20 + 10 Adj). Adjustment from period 1 (V1R2).

Second retro calculation (retro on retro):

• Period 1 (V1R3): E1 = 30

  Delta = 10 [30 (V1R3) − 20 (V1R2)]. Pulled in to period 3 (V1R1) as an adjustment.

• Period 2 (V1R2): E1 = 40 (30 + 10 Adj). Adjustment carried forward from period 2 (V1R1).

  Delta =10 [40 (V1R2) − 30 (V1R1)]. Pulled in to period 3 (V1R1) as an adjustment.

• Period 3 (V1R1): E1 = 50 (30 + 10 Adj + 10 Adj). Adjustments from period 1 (V1R3) and period 2 (V1R2).

  The adjustment is the sum of all retro deltas. In P2 (V1R1), the adjustment to E1 is 10. In P3 (V1R1), the adjustment to E1 is the sum of the adjustments from the recalculation of periods 1 (V1R3) and 2 (V1R2), or 10 + 10.

Note. Because periods 1 and 2 are processed using forwarding retro, the YTD accumulator is not updated each time these periods are recalculated. When the balances are loaded before each recalculation, the system uses the YTD balance from the prior period, V1R1. Revision 1 is always loaded when the method is forwarding.

Example 2: Processing Deltas in Corrective Retro

The following example of retro on retro illustrates how the system calculates deltas when using the corrective method.

Scenario:

• In period 2, E1 changes from 10 to 20. The first retro calculation involves retro in period 2 back to period 1.

• In period 3, E1 changes from 20 to 30. The second retro calculation involves retro in period 3 back to period 1.

In this example, the system calculates retro deltas by taking the new value of E1 minus the old value of E1 (the old value is defined as the value of the previous calculation (previous version, Revision 1). The deltas of E1 are not marked to be forwarded.

There are no adjustments to the value of E1 (as in forwarding retro) because corrective retro replaces the old value with the new value.

First retro calculation:

Period 1 (V2R1): E1 = 20

• Delta = 10 [20 (V2R1) − 10 (V1R1)]. New value replaces old value.

• Net Pay = The banking process determines if any differences exist between the net pay from the prior calculation and the recalculation. Banking processes any differences that result. In this instance, the difference is 10.

Second retro calculation (retro on retro):

• Period 1 (V3R1): E1 = 30

  • Delta = 10 [30 (V3R1) − 20 (V2R1)]. New value replaces old value.

  • Net Pay = The banking process determines if any differences exist between the net pay from the prior calculation and the recalculation. Banking processes any differences that result. In this instance, the difference is 10.

• Period 2 (V2R1): E1 = 30

  • Delta = 10 [30 (V2R1) − 20 (V1R1)]. New value replaces old value.

  • Net Pay = The banking process determines if any differences exist between the net pay from the prior calculation and the recalculation. Banking processes any differences that result. In this instance, the difference is 10.

Note. Because periods 1 and 2 are processed using corrective retro, the YTD accumulator is updated each time a period is recalculated. When balances are loaded before each recalculation, the system uses the balance from the calculation with the highest version number, Revision 1 in the previous period.

Example 3: Processing Deltas and Adjustments When the Retro Method Changes

When calculating retro deltas, the system generally defines the new value of an element as containing the same adjustments as the old value. However, when a period is processed using forwarding retro and reprocessed using corrective retro (the retro method changes from forwarding to corrective), the procedure for calculating deltas becomes more complex.

This example shows what happens when the method for calculating retroactivity changes from forwarding to corrective.

Scenario:

• Retro in period 3 back to period 1 due to a change in E1 from 10 to 30. Retro method is forwarding.

• Retro in period 4 back to period 2 due to a change in E1 from 30 to 40. Retro method changes to corrective for period 2 and then back to forwarding for period 3. E1 is defined as a forwarding exception (it is forwarded to E2 in period 4).

First retro calculation:

• Period 1 (V1R2): E1 = 30

  Delta = 20 [30 (V1R2) – 10 (V1R1)]. Pulled in to period 3 (V1R1) as an adjustment.

• Period 2 (V1R2): E1 = 30

  Delta = 20 [30 (V1R2) − 10 (V1R1)]. Pulled in to period 3 (V1R1) as an adjustment.

• Period 3 (V1R2): E1 = 70 (30 + 20 Adj + 20 Adj). Adjustments from period 1 (V1R2) and period 2 (V1R2).

Second retro calculation (retro on retro):

• Period 2 (V2R1): E1 = 40

  Delta = 30 [40 (V2R1) − 10 (V1R1)]. Pulled in to period 4 (V1R1) as an adjustment to E2.

• Period 3 (V1R2): E1 = 60 (40 + 20 Adj). Adjustment carried forward from period 1 (V1R1).

  Delta = <10> [60 (V1R2) − 70 (V1R1)]. Pulled in to period 4 (V1R1) as an adjustment.

• Period 4 (V1R1): E1 = 30 (40 − 10 Adj). Adjustments from period 3 (V1R2) and E2 = 30 adjustment from Period 2 (V2R1).

In this example, the first retro calculation in period 2 involves a change in the value of E1 from 10 to 30, resulting in a delta of 20. When period 2 is recalculated using corrective retro, the value of E1 increases from 30 to 40. Note that the system does not calculate the new delta as 40 (E1, V2R1) − 30 (E1, V1R2), as it would if the method were forwarding, but as 40 (E1, V2R1) − 10 (V1R1). This is because the old value in corrective retro is defined as the previous calculation (previous version, Revision 1), not as the previous revision.

This creates the following problem, which the system must resolve:

• The first retro calculation results in a delta of 20 being forwarded to period 3.

• The second, corrective calculation results in a delta of 30 being pulled into period 4. This delta includes not just the difference between the value of E1 in V2R1 (40) and the previous value of E1 in V1R2 (30), but the already forwarded difference between the value of E1 in V1R2 and V1R1 (30 −10 = 20). Consequently this difference (20) is counted twice.

How does the system compensate for this? The answer depends on how the delta for period 3 is recalculated. The new value of an element is normally defined as containing the same adjustments as those in the old value. However, when the retro method changes from forwarding to corrective, the delta that appears to be “double-counted” (the delta from period 2 V1R2 in this example) is not included in the new value of E1 when the period to which it was forwarded is recalculated. When the system calculates the delta for period 3, the new value does not contain the adjustment to E1 from period 2, V1R2, but only the adjustment from period 1, V1R2.

Loading Balance Accumulators

Before elements are recalculated during retro, balances must be loaded to produce the correct value for the balance accumulators. The rule used to load balances varies depending on whether you are using forwarding or corrective retro.

If you’re using forwarding retro, the system loads the balance for the element that is being recalculated from the previous period, V1R1.

Using Example 1, presented earlier:

• Period 1 (V1R1): The system loads a balance of 0 for E1 (this is the first period, and E1 has not yet been calculated).

• Period 2 (V1R1): The system loads the YTD balance of E1 (10) from period 1 (V1R1).

• Period 3 (V1R1): The system loads the YTD value of E1 (40) from the period 2 (V1R1).

If your method is corrective, the system loads the balance for the element from the calculation with the highest version number in the previous period.

Using Example 2, presented earlier:

• Period 1 (V1R1): The system loads a balance of 0 for E1 (this is the first period, and E1 has not yet been calculated).

• Period 2 (V1R1): The system loads the YTD balance for E1 (20) from the calculation with the highest version number in period 1 (V2R1).

• Period 2 (V2R1): The system loads the YTD balance for E1 (30) from the calculation with the highest version number in period 1 (V3R1).

• Period 3 (V1R1): The system loads the YTD balance for E1 (60) from the calculation with the highest version number in period 2 (V2R1).

Storing Recalculated Results

When a trigger starts retroactive processing for a payee, the system recalculates each payment that is generated for the payee from the date of retroactivity forward. The system compares the recalculated results to the original results. If there is a difference between them, the system:

1. Stores prior results for auditing purposes, regardless of the method.

2. Stores the new calculation results for each payee. If the retro method is corrective, the system replaces the prior results with new ones in the recalculated period. These results represent the true results for that period. If the retro method is forwarding, these results do not represent the true value but a virtual value.

3. Stores retro deltas for earnings and deductions for each segment in GP_RSLT_DELTA, in the recalc period in which they were generated by the calendar group ID that recalculated the calendar ID.

4. Stores segment accumulator deltas that are defined to be forwarded.

Note. All earning and deduction deltas are stored, regardless of the method used. Accumulator deltas aren’t stored unless they are defined to be forwarded (and only segment accumulators can be forwarded).

See Also

Defining Retroactivity Defaults

Reversing Previous Results

There are several situations in which the system does not calculate retro deltas by subtracting old values from new values. In these situations, to calculate retro deltas, the system reverses the old results and cancels prior calculations. The system adds the resultant negative values to any new values that may have been generated for the period (as long as they share the same payment keys) and moves the results to the current period (if the retro method is forwarding). Reversal occurs when:

• The segment dates of the recalc period don’t match those of the prior period.

• The payment keys of the recalc period/segments don’t match those of the prior period/segments.

  Deltas are summed respecting payment keys (that is, only deltas with the same payment keys are summed) before being forwarded to the appropriate slice or segment in the current period.

• A payee who was calculated as part of a calendar is later discovered to not belong in the calendar.

  Calculations for the payee are reversed. For example, this could occur in a retroactive transfer situation in which a payee is transferred in January, but the transfer is not recorded until February. The January period would need to be reversed entirely.

Following is an example of a related situation that requires a more selective reversal of prior results:

A retroactive calculation takes place on a calendar period that had adjustments for a payee’s earnings pulled into it from previous periods (so that the payee received adjustments in addition to his or her current pay). Later, the payee must be reversed out of this calendar. In such a situation, you might need to preserve the adjustments that were forwarded to the calendar that is being reversed because those adjustments came from a calendar that is not being reversed. The system has been programmed to recognize situations like this and preserves the forwarded adjustments.

See Also

Segmentation and Retro

Payment Keys with Forwarding Retro

Understanding Complex Retro Processing

This section provides detailed information about the way Global Payroll handles retro in a variety of complex situations.

This section discusses:

• Segmentation and retro.

• Payment keys with forwarding retro.

• Retroactivity and positive input.

• Retroactive deletes.

• Retroactive adds.

• Currency changes.

Segmentation and Retro

Segmentation can affect retro processing when:

• A segmented period is being recalculated for retro, and the segmentation dates of the original calculation don’t coincide with those of the recalculation.

  This is called a segment mismatch, and it affects how retro deltas are calculated.

• Retro deltas are forwarded to a period that is segmented or sliced.

Note. Segmentation also affects how the Retro Recalculation Option of Do Not Recalculate is handled.

See Defining Segmentation.

Calculating Deltas in Matched and Mismatched Segments

The way that Global Payroll calculates deltas varies depending on whether the segmentation dates and payment keys of the prior period match those of the recalc period.

When Segments Match

When segment dates match and payment keys are the same, the system recalculates the original segments (to determine the new values for each segment), subtracts the old value from the new value for each element of pay (to determine the retro deltas), and writes new results to the output tables. (See Example 1: Retro With Matching Segments in this section.)

When Segments Don’t Match

When segments don’t match, the system treats the old and new values as if they belong to separate segments.

• The system creates reversal segments for each segment that existed in the prior calculation and then creates new recalc segments.

• A reversal segment does not have any results because it does not go through gross-to-net processing. The only results that are written to the output result tables are for deltas and balance accumulators. For calculating deltas, the new values are assumed to be 0.

The new recalc segments go through gross-to-net processing and generate the new values. The new values are written to the output result tables. For calculating deltas, the old values are assumed to be 0.

See Defining Segmentation, Defining the Organizational Structure.

Example 1: Retro with Matching Segments

When the segment dates of the recalc period match those of the original period, retro processing is straightforward. Following is an example of retro going back to a segmented period.

Scenario:

• The original January pay period is segmented due to a change in paygroup that is effective on 16 January.

• The January pay period must be recalculated for retro due to a change in E1 from 300 to 600 that is effective on January 1.

Retro with matching segments

When the January pay period is reprocessed during retro, the original segmentation dates are preserved. To determine the deltas for these segments, the system first matches segment 1 to segment 1 and segment 2 to segment 2. Then it subtracts the old value of E1 for each segment from the new value (E1 is defined to be prorated). As with retro without segmentation, the system recalculates each segment in the period and writes new values for each segment to the result output tables.

Note. In this and subsequent examples, the original and recalculated calendars are marked with version and revision numbers (V1R1, V1R2, and so forth) for tracking recalculation of a calendar period due to retroactivity.

See Tracking Recalculated Calendars.

Example 2: Retro with Mismatched Segments

When the segment dates of the recalc period don’t match those of the prior period, the system calculates retro deltas as described earlier in Calculating Deltas in Matched and Mismatched Segments.

Following is an example of retro going back to a segmented period. In this example, when the period is reprocessed during retro, the prior segmentation dates change:

Retro with mismatched segments

Scenario:

• The original January pay period is segmented when a payee moves from company ABC to company DEF, effective January 11.

• The original pay period is recalculated when the effective date of the payee’s company transfer changes from January 11 to January 16 (that is, the segmentation date changes from January 11 to January 16).

• The payee’s earnings (E1) are 620 and are defined to be prorated.

In this example, the original January pay period is segmented due to a change in company ID effective on the eleventh of the month. The January calendar is reopened for retro processing when the effective date of the company transfer changes from January 11 to January 16, which means that the segment dates for the original and recalculated periods do not match. When recalculating the calendar period for January, the system cannot match segment to segment as in the previous example—segments 1 and 2 no longer have exact counterparts in the recalculated period.

The values of segment 1 and 2 are reversed, resulting in negative deltas of −200 and −420 for segments 1 and 2, respectively. Then the system creates new recalc segments with unique, segmented status records in the recalc period—segments 3 and 4, whose deltas are 300 and 320. The system writes new values for each segment to the output result tables. For the reversal segments, only the balance accumulator and delta output result tables are updated.

Note. When slice dates change, the differences between the original and recalc periods do not affect the calculation of the retro deltas. Only changes in the segmentation dates create the need for reversal segments.

Example 3: Mismatch in Changing Payment Key Values

One more situation that the system recognizes as a segment mismatch occurs when the value of a payment key (for example, company ID) changes between a prior calculation and the recalculation. The system treats the old and new calculations as belonging to separate segments—just as if the segment dates no longer matched.

See Payment Keys with Forwarding Retro.

Forwarding Adjustments in Retro with Segmentation

The way that Global Payroll forwards adjustments varies depending on whether retro deltas are being forwarded to a sliced or segmented calendar and whether payment keys have been defined. Regardless of the situation, the system observes the following rules:

• As in retro without segmentation, the system uses retro matching criteria to determine whether it can forward deltas to a calendar in the current period.

  The system forwards deltas only where the employee ID, record number, pay entity, paygroup, and run type of the source calendar are the same as that of the target calendar in the current period.

• If all retro matching criteria are satisfied, but the current period is segmented, the system sums and forwards deltas to the first segment in the current calendar.

  If that segment is sliced, the system forwards the adjustments to the first slice in that segment.

• If you have defined payment keys based on criteria such as company ID, contract number, establishment, or department ID, adjustments are forwarded only to the first segment in the current calendar that has the same payment keys as the forwarded adjustments (after all retro matching criteria have been satisfied).

  If that segment is sliced, the system forwards the adjustments to the first slice in that segment. If the system finds no segment with matching payment keys, it creates a new segment in the current period to which to forward the adjustments. The dates of the new segment are those of the calendar period as a whole, regardless of whether the current period is segmented.

Note. The system uses retro matching criteria to determine whether to pull adjustments into the current period. If all the criteria are satisfied, the system forwards the deltas. If payment keys are used (in addition to the standard matching criteria), the system checks these keys to determine where to forward the adjustment. If the current period—or a segment in that period—has the same payment keys, the system forwards the adjustment to the first segment (or, if sliced, to the first slice in that segment) in the current period with matching payment keys. Only when the system finds no segment with matching payment keys does it create a new segment to which to forward the adjustments.

See Payment Keys with Forwarding Retro.

Example 1: Element Segmentation with Retro

The following example of element segmentation with retro illustrates how the system forwards deltas to the current period (assume that all retro matching criteria have been satisfied and that there are no payment keys).

Scenario:

• Retro in period 3 back to period 1 due to a change in the value of E1 from 310 a month to 620 a month on January 16 (assume that E1 is defined to be prorated).

• E1 is on the element list for element segmentation and causes E1 to undergo segmentation into slice 1 and slice 2 in mid period—a period that was originally not segmented.

The following diagram shows an example of element segmentation in the recalc period and no segmentation in the current calendar; there are no payment keys and retro match criteria are satisfied.

Example of element segmentation in recalc period and no segmentation in current calendar

• Delta 155 is created in period 1; V1R2 is forwarded to period 3, V1R1, segment 1.

• Delta 310 is created in period 2; V1R2 is forwarded to period 3, V1R1, segment 1.

When the system calculates retro deltas for period 1, it subtracts the old value of E1 in period 1 (310) from the sum of E1 in slices 1 and 2 (155 + 320). Just as in retro without segmentation, the system forwards all deltas to the current period (March) using retro matching criteria.

Example 2: Period Segmentation Combined with Retro

The following example of retro with period segmentation illustrates how the system moves retro deltas from a segmented recalc period into a segmented current period, selecting the first slice/segment as the forwarding target using retro matching criteria.

Scenario:

• Retro in period 3 is back to period 1 due to a change in department ID (from department A to department B) on January 16, which triggered period segmentation in the January recalc calendar (assume that the original period was not segmented).

• The value of E1 increases from 310 a month to 620 a month in March, retroactive to January 1 (assume that E1 is defined to be prorated).

• On March 16, the department ID changes from department B to department C. This affects only the current period, resulting in a segmented current calendar.

The diagram below shows an example of period segmentation in both the recalc period and the current calendar; no payment keys are used and retro match criteria are satisfied.

Example of period segmentation in recalc period and current calendar

• Delta 310 is created in period 1; V1R2 is forwarded to period 3, V1R1, segment 1.

• Delta 310 created in period 2; V1R2 is forwarded to period 3, V1R1, segment 1.

The system calculates retro deltas for January by summing the deltas for the reversal segment (segment 1) with segments 2 and 3. And when it calculates the deltas for February, it subtracts the value of E1 in V1R1 from E1 in V1R2. The system then pulls the deltas from the January and February recalc periods (310 + 310) into the first segment of the current calendar that satisfies the retro matching criteria—that is, segment 1 in the March payroll calendar.

Example 3: Period Segmentation Combined with Retro—Payment Keys Used

The following scenario illustrates how the system handles retro deltas when retro matching criteria have been satisfied, a payment key has been defined (in addition to the standard retro matching criteria), but the payment key of the recalc period does not match that of the current calendar.

Scenario:

• The value of E1 increases from 310 a month to 620 a month in March, retroactive to January 1. This causes the January and February calendars to be recalculated.

• On March 1, the payee transfers from company ABC to company DEF. Company ID is defined as a payment key.

• On March 16, the department ID changes from department A to department B. This affects only the current period, resulting in a segmented current calendar.

Example of company defined as a payment key (retro match criteria are satisfied)

• Delta 310 is created in period 1; V1R2 is forwarded to period 3, V1R1, segment 3.

• Delta 310 is created in period 2; V1R2 is forwarded to period 3, V1R1, segment 3.

When the system first calculates the retro deltas for January and February, it tries to pull them into the first segment of the current calendar (March) based on retro matching criteria. However, the deltas that are to be forwarded were generated for a payee in company ABC, and the payee is now in company DEF (there was a company transfer on March 1). Because Company has been defined as a payment key, deltas cannot be forwarded to the first segment of the current calendar (March) even though all other retro matching criteria have been satisfied. Therefore, the system creates a separate segment with the same begin and end dates as the March pay period and moves the deltas into the new segment.

Note. These examples refer only to forwarding retro because only forwarding retro generates adjustments to be processed in the current period—unless your method is corrective, and you have defined elements to be forwarded. In the case of corrective retro combined with segmentation, the system calculates retro deltas as it does in the above examples. However, unlike forwarding retro, recalculated values for the elements replace the previous calculation. Differences between the net pay from the previously calculated period and the recalculated period are determined and processed by banking.

Payment Keys with Forwarding Retro

Payment keys affect how adjustments are forwarded to the current period when retro is processed.

See Defining the Organizational Structure.

Payment Keys and Forwarding

When the payment keys of the current period do not match those of the period that is being recalculated, adjustments must be managed as a separate gross-to-net in the current calendar period. For example, Company has been defined as a payment key. A payee who is working in company ABC moves to company DEF in the current period. There is retro going back to a prior calendar when the payee was in company ABC, and there are adjustments to the payee’s current period coming from the prior calendar. The adjustments are associated with company ABC, and the current period is associated with company DEF. In this situation, the adjustments are managed as a separate gross-to-net in the current period.

When deciding whether and where to forward adjustments, the system:

1. Determines whether retro matching criteria have been satisfied.

   If matching criteria have been satisfied, the system pulls retro deltas into the current period as adjustments.

2. Checks to see if you have defined payment keys based on criteria such as company ID, contract number, establishment, and department ID.

   If you have defined payment keys, the system checks those keys to determine where to forward the adjustments. If the value of the payment keys that are attached to the forwarded adjustments is the same as the value in the current period, the system forwards adjustments to the first segment in the current period that has matching payment keys. If that segment includes slices, the system forwards adjustments to the first slice in that segment.

3. Creates a new segment in the current period (when it finds no segment with matching payment keys) to which to forward the adjustments.

   The system manages the adjustments as a separate gross-to-net in the current period. The dates of the new segment are the dates of the calendar period as a whole, regardless of whether the current period is segmented.

   The new segment has the status Inactive in Segment and goes through the process list like any other gross-to-net calculation. Earnings and deductions are resolved again in this segment. The result may not be what you want for this type of segment. To prevent the earnings and deductions from being resolved again in this segment, the user can define a generation control element to exclude segments with the status Inactive in Segment.

   Positive input (PI) that is targeted to this calendar, as well as any generated PI section, will not be processed again in the Inactive in Segment segment, regardless of generation control.

See Defining Calculation Elements, Defining Processing Elements, Working with Positive Input.

Example 1: No Change in Payment Key Values

When the payment keys of the current period match those of the period that is being recalculated, the system forwards the adjustments to the current period. No new segments are created. Consider the following example of retro in February going back to January.

Scenario:

• Company ID is defined as a payment key.

• A payee’s earnings (E1) change from 500 to 900 retroactive to January. As a result, period 1 must be recalculated.

No change in payment key values

Delta 400 is created in period 1; V1R2 is forwarded to period 2, V1R1, segment 1.

See Tracking Recalculated Calendars.

Example 2: Payment Key Value Changes in Current Calendar Period

When payment keys in the current period do not match those in the period that is being recalculated, the system creates a new segment in the current period to which to forward the adjustments. Consider the following example of retro in February going back to January.

Scenario:

• Company ID is defined as a payment key.

• A payee’s earnings (E1) change from 500 to 900 retroactive to January. As a result, period 1 must be recalculated.

• On February 1, the payee transfers from company ABC to company DEF.

Payment key value changes

Delta 400 is created in period 1; V1R2 is forwarded to period 2, V1R1, segment 2.

Because the payee in this example moves from company ABC to company DEF in February, the payment keys in the current calendar (February) no longer match those in the calendar that is being recalculated (January). As a result, the system creates a new segment (segment 2) in February into which to pull the adjustments from period 1, V1R2. The begin and end dates of the new segment are identical to those in the current period (February 1−28).

See Tracking Recalculated Calendars.

Payment Keys and Retro Deltas

If the value of a defined payment key changes retroactively, so that a calendar that is associated with one set of payment keys must be reprocessed using payment keys with changed values, the system recognizes this condition as a segment mismatch. If a segment match on payment keys doesn’t exist between the prior and the current periods, a new segment is created in the current period for the forwarded adjustment that results from the deltas that have old payment keys. This process is illustrated in the example below.

Scenario:

• A payee moves from company ABC to company DEF in February. The change is retroactive to January.

• Company ID is defined as a payment key.

• The payee’s earnings (E1) change from 500 to 900 retroactive to January. As a result, period 1 must be recalculated.

Payment keys and retro deltas

• Delta <500> is created in period 1; V1R2 is forwarded to period 2, V1R1, segment 2.

• The delta 900 created in period 1, V1R2 is forwarded to period 2, V1R1, segment 1.

To calculate the retro delta for E1 in January, the system cannot match the new value of E1 (900) to the old value of E1 (500) and compute the difference as it ordinarily would (900 − 500 = 400). The old and new versions of E1 belong to different segments, are linked to different payment keys, and are no longer treated as counterparts. To determine the deltas, the system must first reverse the old value of E1 in V1R1; that is, it treats the prior calculation of E1 in period 1 as having no corresponding value in the new segment and subtracts 500 from 0 to generate a negative −500. Likewise, it sees the new calculation of E1 in period 1 as having no corresponding value in the old segment and subtracts 0 from 900 to generate a new value of 900 for E1.

Note. A segment mismatch also occurs when there is segmentation, and the segment dates of a recalculated period do not match those of the original period.

Summing Deltas by Payment Key

The preceding example illustrates another consequence of using payment keys, which is that deltas that are being summed and forwarded must respect payment keys. Only deltas with the same payment keys are summed to be forwarded; deltas that are associated with one set of payment keys cannot be forwarded to an element that is associated with a different set of payment keys. In the preceding example, the delta <500> that is created in period 1, V1R2, is not added to the delta 900 that is created in period 1, V1R2, because the deltas are associated with different payment keys.

See Also

Segmentation and Retro

Retroactivity and Positive Input

To correct an instance of positive input, you make the correction in the pay period in which the original entry was made. For example, if it is July, and you need to correct positive input that was entered in May, you access the Positive Input page for the May calendar and add, delete, or correct the instance.

If you have defined retroactive triggers to detect the online changes, the system recalculates the calendar period using your changes when you run the next payroll cycle for the payee.

See Also

Making Retroactive Adjustments to Positive Input

Retroactive Deletes

A retroactive delete occurs when there is a retroactive termination, a retroactive paygroup transfer, or a retroactive change in pay system. In all cases the information is received after the actual effective dates for these changes. The result is that gross-to-nets were calculated when they should not have been and these results must be completely reversed.

Example 1: Paygroup Transfer with Forwarding Retro

Scenario:

• In period 1, the payee is in paygroup A. E1 = 100.

• In period 2, the payee transfers paygroups retroactively to paygroup B, effective in period 1. E1= 200.

• The retro calculation involves retro in period 2 back to period 1.

• In period 1, V1R2, E1 is reversed completely. No new segment is created because the payee should not have a gross-to-net calculation during this period for paygroup A.

• The E1 delta of <100> for period 1, V1R2 is not processed for the current calendar (period 2) because the payee is no longer in paygroup A. If the current calendar is for paygroup B, the delta is not pulled in as an adjustment until you manually redirect the unprocessed delta to a target calendar for paygroup B.

Retroactive Adds

A retroactive add occurs when there is a retroactive hire or a retroactive paygroup transfer. With a retroactive hire, there is no previous calculation (prior gross-to-net). In the case of a retroactive paygroup transfer, the retro add refers to the paygroup to which the payee is transferred.

Example 1: Retroactive Add with Forwarding Retro

Scenario:

• In period 2, information is received regarding a new payee that is hired in period 1.

• The first retro calculation involves retro in period 2 back to period 1.

• In period 1, V1R2 represents the retro processing for that period. The revision number is 2 even though Version 1 never existed, because the method is forwarding, and the recalculation does not represent the true results.

• The delta for period 1, V1R2 is pulled into period 2, V1R1 as an adjustment.

Currency Changes

When a calendar is reprocessed for retroactivity, Global Payroll uses the original processing currency. This is important because with retroactivity it is necessary to recalculate prior periods in the same currency as the original calculation for the pay period. So, for example, if you were to change the processing currency at the pay entity level between the recalc period and the current period, the difference between the new value and the old value would still be computed in the currency of the original calculation. This means that retro deltas are converted to the processing currency of the period that they are pulled into. The system uses the current segment’s exchange rate information (exchange rate type and exchange rate effective date (defined at the payee level) to do the currency conversion.

For example, from January 1998 to June 1998, the currency is French francs. In July, the company decides to use the euro. In July, retroactivity for a payee is effective in June 1998. Everything pertaining to the recalculation is done using French francs. When the delta is calculated, it is calculated in French francs and then converted to the euro using the exchange rate information as of the current segment. Retro adjustments are brought forward into the current period in euros.

Tips for Retroactive Processing

The following table provides hints on using retroactive processing.

See Also

Defining Retroactivity Defaults

Using Calendars

Retroactive Triggers