Setting Up Retroactive Processing

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, effective 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 case, the amount does not change. If it does change, the system also reverses the amount from the element to which the changed amount was forwarded.

Understanding the On Conflict Retro Method

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

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

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

For example, imagine that you assign an employee to Pay Group A. The fiscal year (the retro Method Based On date) begins on January 1, 2000. For the same employee in Pay Group 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 pay groups the Before Method is Forwarding and the After Method is Corrective).

This graphic shows an example of the on conflict retro method.

To recalculate the February pay period, Pay Group A uses corrective retro, while Pay Group 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 avoid this conflict, select a retro conflict method on the Countries page.

Retro Method Decided By

The fields in this group box enable the system to determine the date and year that the retro method varies and are available only if you select 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, the system uses the year associated with the Determine Year By field value.

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

     • First current calendar period is December 1 to December 31, 1999.

     • Year is determined by Period End Date, which is December 31, 1999.

     • Method is based on Pay Entity Calendar Year, which is January 1.

     The retro method change date is therefore January 1, 1999.

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

     • First current calendar period is December 1 to December 31, 1999.

     • Year is determined by Pay Date, which is January 2, 2000.

     • Method is based on Pay Entity Calendar Year, which is January 1.

     The retro method change date is therefore January 1, 2000.

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

     • First current calendar period is March 1 to March 31, 1999.

     • Year is determined by Period End Date, which is March 31, 1999.

     • Method is based on Pay Entity Fiscal Year, which is April 1.

     The retro method change date is therefore April 1, 1998.

2. Determine the retro method to use.

   The system compares the retro method change date 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, the system uses the After Method.

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

The following table shows how the system applies the correct retro method, 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 .

Assume that you have an earning/deduction assignment 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.

In this example, the retro method varies: the retroactive process applicable to December 2002 is forwarding retro, and 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 includes the delta or adjustment in the February amount, while the corrective method reverses and corrects previous entries.

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.

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 earning 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 earning, the "Forward To Element" can be an earning or a deduction.

• When you forward the delta for a deduction, the "Forward To Element" can be an earning 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 earning 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.

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 earning or a deduction, the "Forward To Element" can be either an earning 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 earning 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.

Common Page Elements

Element Overrides

Select the Retro Process Overrides - Element Overrides tab.

Forwarding Options

Select the Retro Process Overrides - Forwarding Options tab.

This example illustrates the fields and controls on the Retro Process Overrides - Forwarding Options tab.

Example: Corrective Retro—with Forwarding Exceptions

Scenario:

• Earning 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 Earning 1 + Earning 2 is forwarded to Earning 2 in the current period.

• Additional element definitions:

  • Earning 1 = Hours worked × Pay Rate.

  • Deduction 1 = 10% of Segment Accumulator.

  • Deduction 2 = 20% of Earning 1.

  • Segment Accumulator = Earning 1 + Earning 2.

  • YTD Accumulator Earning = Earning 1.

YTD Accumulator Deductions = Deduction 1 + Deduction 2

Calendar period, current results, and retroactive adjustment:

In this example, the system replaces the original values of the earnings, deductions, and accumulator elements. While this is consistent with corrective processing, note that the segment accumulator for Earning 1 is forwarded to Earning 2 in the current period. This is an exception to the standard corrective method. Also, Earning 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 Earning 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 earning. 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.

• Banking determines if any difference exists between the net pay from the prior calculation and the recalculation and processes the difference. In this case, the difference is 32.

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

Scenario:

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

• Earning 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—Earning 3.

• Additional element definitions:

  • Deduction 1 = 10% of Earning 1 + Earning 2.

  • YTD Accumulator Earning = Earning 1 + Earning 2.

  • YTD Accumulator Deductions = Deduction 1.

In this example, the system:

• Generates a Net Pay delta (180).

• Replaces the balance accumulator (YTD Earning 1 + Earning 2) in the recalc period because it has been defined to follow corrective behavior (even though the default retro method is forwarding).

When period 1 is recalculated, the system retrieves the Net Pay delta as an adjustment to Earning 3 in period 2. If no other processing 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 system corrects the YTD Accumulator 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.

Retro Period Backward Limit

Use the fields in this group box to limit the number of calendar periods that Global Payroll can reprocess going into the past.

To determine how far back to go, the system compares the backward limit defined on the Retro Limits page to the retro trigger effective date. If the trigger effective date comes before the backward limit date, the system uses the backward limit date to determine the first retro period. If the backward limit date comes before the trigger effective date, the system uses the trigger date to determine the first retro period to process.

Example 1: Using months criteria to determine the first retro period to recalculate.

Global Payroll determines the backward limit by going back two months from the current calendar period begin date of June 1, 1999, providing a 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 are recalculated: April (April 1, 1999 - April 30, 1999) and May (May 1, 1999 - May 31, 1999).

Example 2: Using years, months, and days criteria to determine the first retro period to recalculate (trigger effective date does not exceed backward limit date).

Global Payroll determines the backward limit 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 this limit to the trigger effective date, which (in this example) establishes the first retro period because it does not exceed the backward limit date. Twelve periods are recalculated.

Example 3: Using years, months, and days criteria to determine the first retro period to recalculate (trigger effective date exceeds backward limit date).

Global Payroll determines the backward limit 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 the backward limit date determines the first retro period. Fifteen periods are recalculated.

Retro Period Forward Limit

Use the fields in this group box to specify the amount of time that retroactive data can continue to be processed after a payee is terminated or becomes inactive.

Example 1: Using months criteria to determine the first retro period to recalculate (calendar period does not exceed forward limit).

Global Payroll determines the forward limit 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 criteria to determine the first retro period to recalculate (calendar period exceeds forward limit).

Global Payroll determines the forward limit 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.

Matching Criteria: Managing Unprocessed Retro Deltas

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

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

• The pay group of the deltas that are to be forwarded matches the pay group of the current calendar.

  Note: You can override this requirement by selecting the Deltas Cross Pay Groups option on the Retro Limits page. If you do this, the system automatically brings retro deltas into the current period even if the pay group associated with the deltas does not match the payee's current pay group. However, all other matching criteria must still be met.

  See Retro Limits Page.

• The pay entity of the deltas that are to be forwarded matches the pay entity of the current calendar.

• The run type of the deltas that are to be forwarded matches the run type of the current calendar.

  Note: You can override this requirement by entering additional run types in the Retro Adjustments Sources group box on the Run Types page. If you do this, the system automatically brings retro deltas into the current period for those run types that have been associated with the payee's current run type. However, all other matching criteria must still be met.

  See Defining Run Types, Retro Limits Page.

• The process order timestamp of the retro deltas precedes the process order timestamp of the current Pay Process Stat record.

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

  • Specify the calendar ID and pay group of the target calendar (the target pay group 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).

Example: Manually Forwarding Retro Deltas

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

Segment Data

The fields in the Segment Data group box enable you to identify the source pay group, calendar ID, calendar group ID, and payment keys of the unprocessed retro deltas.

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.

This example illustrates the fields and controls on the Unprocessed Retro Deltas - Values tab.

User Fields

Select the Unprocessed Retro Deltas - User Fields tab.

This example illustrates the fields and controls on the Unprocessed Retro Deltas - User Fields tab.

This tab displays the user fields defined for each element.