Defining Retroactive Processing

This chapter provides an overview of the delivered retroactive methods, 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 complex retroactive processing.

Understanding Retroactive Methods

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.

This table provides a comparison between the two methods:

Note. Only segment accumulators can be forwarded. Balance accumulators cannot be forwarded regardless of the retro method.

See Also

Defining Banking Instructions

Integrating with PeopleSoft Enterprise General Ledger

Common Elements Used in This Chapter

This section defines some of the key terms used to describe retroactivity in this chapter.

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 payroll element. 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 recalculation is called retro on retro.

Retro Add

A retro add is a situation in which a previous gross-to-net result set does not exist for a payee, and retroactivity calls for a Pay Process Stat record to be created for the first time.

Note. We discuss the Pay Process Stat record in the chapter on system architecture.

See Batch Processing Output Tables.

Understanding General Rules of Retroactive Processing

This section provides examples of the delivered retroactive calculation methods, and discusses how Global Payroll:

• Tracks recalculated calendars.

• Calculates retro deltas and processes adjustments.

• Loads balance accumulators.

• Stores recalculated results.

• Reverses previous results.

Examples of Retroactive Processing

The examples of corrective and forwarding retro in this section illustrate the basic difference between the two methods: in corrective retro, the recalculated values of elements in the pay run replace the previous calculations, while in forwarding retro, the system uses the recalculated values to compute retro deltas, and then carries the deltas forward as adjustments to elements in the current period.

Example 1: Corrective Retro—No Exceptions

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

This table shows the processing results:

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 Earning 1 replaces its old value. The banking process determines the difference between the net pay from the prior calculation (70) and the recalculation (90) and manages the retro delta (20).

Example 2: Forwarding Retro—No Exceptions

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

This table shows the processing results:

In this example, the system forwards the retro delta for Earning 1 to the current period (period 2), where it is recorded as an adjustment to Earning 1.

Even though the retro method is forwarding, the system does not forward all elements from the first period to the second period:

• The system does not forward the Net Pay accumulator because it already contains the value of Earning 1.

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

• Global Payroll does not forward balance accumulators. This is because they sum the values of elements that have potentially already been forwarded, so moving them into the current period would generate incorrect results.

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

Tracking Recalculated Calendars

Global Payroll tags each Pay Process Stat record with a version and revision number appropriate to the retro method used. These version and revision numbers are the vehicles for tracking recalculation of a calendar period due to retroactivity.

Note. We discuss the Pay Process Stat record in the chapter on system architecture.

See Batch Processing Output Tables.

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:

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 once—and the retro method changes, the numbering scheme becomes more complicated. In the following example, Global Payroll recalculates five consecutive periods using the forwarding method on the first pass, and a combination of forwarding and corrective retro 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 retro, 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 retro 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 Pay Process Stat record to be created for the first time. For example, suppose that a payee initially thought to have been 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 Pay Process Stat record for the period and assign version and revision numbers to it.

The system assigns version and revision numbers as follows:

• Numbering 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 calculation does not exist, and a retro add results in a gross-to-net for the first time, the system labels this calculation V1R2 even though it is technically the first gross-to-net. The reason for this 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 to bring forward to the current period. V1R1 is not used because it does not contain the true results for the period.

• Numbering 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 system labels this first calculation V1R1. The reason for this 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 Pay Process Stat records in retro add situations using forwarding and corrective retro.

Scenario:

In the following retro add situations, it is discovered that a payee who was calculated in period 1 should not have been processed in that period. The calculations for the payee are therefore reversed in Recalc No. 2. When it is later discovered that the payee belongs in that period after all, the system produces a new gross-to-net calculation using the version and revision numbers associated with Recalc No. 3:

Example 1

Example 2

Example 3

Example 4

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 (where 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 (where the old value is the value from the previous version, Revision 1).

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

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

In the case of 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 earning E1 equals 20 in period 1 (V1R1), increases to 30 in the first recalculation (V1R2), and increases again to 40 in the last recalculation (V2R1), the system derives the deltas as follows:

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

Processing Adjustments

When the retro method is forwarding, the system calculates the adjustment to carry forward by summing the deltas for an element across all of the recalculated periods. If you have defined payment keys, the system sums the calculated deltas by payment key rather than creating a single adjustment amount.

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 subtracting the old value of E1 from the new value of E1 (the 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 subtracting the old value of E1 from the new 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 for forwarding.

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 difference exists between the net pay from the prior calculation and the recalculation. 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 difference exists between the net pay from the prior calculation and the recalculation. 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 difference exists between the net pay from the prior calculation and the recalculation. 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 complicated.

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 the system recalculates elements during retro, it loads balances 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 (see Calculating Retro Deltas and Processing Adjustments):

• 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 (see Calculating Retro Deltas and Processing Adjustments):

• 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

During retroactive processing 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 the deltas, the system reverses the old results and cancels prior calculations. The system adds the resulting 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.

  In this case, the system sums deltas by payment key (that is, only deltas with the same payment keys are summed) before forwarding them 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.

  In this case, the system reverses prior calculations for the payee. 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

Setting Backward and Forward Retro Limits

In Global Payroll, you use the Pay Entity Retro Limits page to establish default backward and forward limits for retro processing. These defaults tell 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 becomes inactive he/she is eligible for retro processing.

To determine how far back in time to go to process retroactivity, the system compares the backward limit defined on the Pay Entity Retro Limits page to the following system dates:

• Trigger Effective Date.

  This date—the effective date of the change that triggers retroactive processing—establishes a theoretical goal for how far back in time to go to recalculate data. When the system determines which periods to process, the backward limit date takes precedence over the trigger effective date. For example, if the trigger effective date is January 1, 1990, and the backward limit date is January 1, 1995, the backward limit date stops all calculations prior to (and including) that date. By contrast, if the backward limit date is January 1, 1990, and the trigger effective date is January 1, 1995, then the trigger effective date establishes the number of periods to recalculate.

• No Retro Processing Before Date.

  This is the date that a payee enters the Global Payroll system. This date takes precedence over the trigger effective date and the backward limit date because no matter what these dates are, there is no historical data to recalculate before the No Retro Processing Before Date.

This diagram illustrates the interaction of the dates used to determine the number of past periods to recalculate.

First recalculation period

The Global Payroll system determines the first recalculation period by comparing the trigger effective date to the backward limit date and comparing both dates to the calculation begin date.

The process for determining forward limits is less complex than for backward limits, because the system does not compare trigger effective dates to either the forward limit or the No Retro Processing Before Date. It only needs to determine whether payees are within the forward limits defined on the Pay Entity Retro Limits page. If a payee is within these limits, the system applies the backward limits to determine 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.

Setting Up Retroactive Processing

To set up retroactive processing, use the Countries (GP_COUNTRY), Retro Process Definitions (GP_RTO_PRC_DEFN), Retro Process Overrides (GP_RTO_OVR_DEFN), Retro Event Definitions (GP_RTO_EVT), Pay Entities (GP_PYENT), and Assign Retro Limits (GP_PYE_RTO_LIM) components.

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

• Define retroactivity defaults at the country level.

• Define a retro process.

• Forward elements and define retroactive overrides.

• Define trigger event IDs.

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

• Define retro processing limits at the payee level.

• Manage unprocessed retro deltas.

See Also

Additional Pages Affecting Retroactive Processing

Understanding Retroactive Processing Setup

Follow these steps to set up retroactive processing:

1. Select a default retro method.

   On the Countries page, identify a default retro method—forwarding or corrective—for processing retroactivity. There can be only one default method per country, but you can develop this method into a number of distinct processes and even override it if necessary.

   In addition, use this page to define the retro method to apply where there is a conflict and to define how retroactivity should work with banking and General Ledger.

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

   See Defining Retroactivity Defaults.

   See Defining Country-Level Setup.

2. Define a retro process.

   Further define the retro 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 when the default retro method is forwarding. 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 the default retro method is forwarding, use the Retro Process Overrides page to individually select elements to forward. Global Payroll does not assume that every element in a process list should be forwarded—even when the default method is forwarding.

   If the default retro method is corrective, but you want to forward certain elements, identify the elements to forward on the Retro Process Overrides page.

4. Map retro processes to trigger event IDs.

   Use the Retro Event Definition page to associate the retro process you defined in step 2 with a trigger event ID. The event ID tells the system how to process data changes to the records or fields you make sensitive to retroactive data changes in step 5 (see below).

5. Define trigger records and fields.

   After mapping retro processes to event IDs, you must decide which database records and fields will trigger retroactive processing in response to data changes. You identify these fields and records on the Trigger Definitions component (GP_TRGR_SETUP) and link them to one of the trigger event IDs that you defined in Step 4. Because trigger event IDs identify retro process definitions, any field or record that is linked to this ID triggers the correct process in response to a data change.

   Note. We discuss the Trigger Definitions component in the chapter on trigger setup.

   See Setting Up Triggers.

6. Determine which pay entities allow retroactive processing.

   Use the Pay Entity Retro Limits page to enable retroactive processing of calendars in a pay entity.

7. Specify backward and forward limits.

   There are two pages on which you can set backward and forward limits:

   • Use the Pay Entity Retro Limits page to establish default 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 becomes inactive he/she is eligible for retro processing.

   • If necessary, override the default backward and forward limits for specific payees using the Retro Limits Assignment page.

8. View, add, and cancel retro triggers.

   After the online system generates retro triggers, use the Payee Triggers - Retro page to manage retro events so that retroactive processing takes place 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 are 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, 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 situation can be represented as follows:

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

Note. The system creates a Pay Process Stat record for each payee for each calendar, including retro. When you specify a retro conflict method, you ensure that consecutive Pay 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 value of this field defaults 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. When you select this check box, the Retro Method Decided By group box fields become available for data 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 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:	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 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.

Forwarding Elements and Defining Retroactive Overrides

Access the Retro Process Overrides page.

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.

Note. With forwarding retro, you can define balance accumulators to behave in a corrective manner at the accumulator definition level and on the Earning/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 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.

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:

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

See Also

Defining Element Names

Defining Earning and Deduction Elements

Setting Up Accumulators

Defining Trigger Event IDs

Access the Retro Event Definition page.

The mechanism that is used to track online data changes that should trigger retroactive processing is called a trigger. In Global Payroll, you set up triggers by identifying the records and fields that should trigger retroactive processing in response to data changes, and by defining the retro process definition to use to process these changes:

See Setting Up Triggers.

1. On the Retro Event Definition page, associate each of the retro processes defined on the Retro Process Definition page with a trigger event ID.

2. On the Trigger Definitions page, identify the records and fields that should trigger retroactive processing when data is modified or updated retroactively.

3. On the Trigger Definitions and Trigger Definitions - Field Values pages, associate the records and fields identified in step 2 with one of the trigger event IDs you defined in step 1. Because each ID is linked to a process definition, the system can automatically apply the correct retro process when one of these records of fields is modified or updated.

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

See Also

Setting Up Triggers

Understanding Absence Management

Setting Up Accumulators

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

Access the Retro Limits page.

After you have defined a retro method and the events that trigger retro processing, you must specify the backward and forward limits for retro processing at the pay entity level. This tells the system how far back in time to go to recalculate closed calendars, and how long a payee is eligible for retroactive processing after being inactivated or terminated.

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.

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.

Defining Retro Processing Limits at the Payee Level

Access the Retro Limits Assignment page.

Note. The fields on this page are almost identical to those on the Retro Limits page. To view definitions of the shared fields, return to the section on the Retro Limits page. In this section we discuss only the fields that are unique to the Retro Limits Assignment page.

See Also

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

Managing Unprocessed Retro Deltas

Access the Unprocessed Retro Deltas page.

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 Rec# (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 Defining Backward and Forward Limits for Retro Processing at the Pay Entity Level.

• 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, Defining Backward and Forward Limits for Retro Processing at the Pay Entity Level.

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

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 described earlier in this chapter, several other pages affect retro processing. These pages are of two types—general setup pages and calendar setup pages. The following table describes these pages:

Understanding Complex Retro Processing

This section provides detailed information about the way Global Payroll handles retroactivity 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 system manages the Retro Recalculation Option of Do Not Recalculate.

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. When calculating deltas, the new values are assumed to be 0 (delta = new value [0] – old value).

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. When calculating deltas, the old values are assumed to be 0 (delta = new value – old value [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, as shown in the following example of retro going back to a segmented period.

Scenario:

• The original January pay period is segmented due to a change in pay group 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, 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 output result 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 the calendar periods.

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 earning (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

The Global Payroll system also recognizes the following situation as a segment mismatch: when the value of a payment key (for example, company ID) changes between a prior calculation and the recalculation, Global Payroll 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 based 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. In other words, the system forwards deltas only when the employee ID, record number, pay entity, pay group, and run type of the source calendar match those of the target calendar in the current period.

  Note. You can override pay group matching 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. In addition, you can override run type matching by specifying additional valid 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 additional types even though the deltas do not match the payee's current run type. However, all other matching criteria must still be met.

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

• 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 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, these deltas 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 is defined as a payment key, the 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 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, are not 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 earning (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 earning (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 earning (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.

When calculating 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 an important rule: when summing and forwarding deltas, the system sums only deltas with the same payment keys, and deltas that are associated with one set of payment keys cannot be forwarded to an element linked to different keys. In the preceding example, the delta (<500>) created in period 1, V1R2, is not added to the delta (900) 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, make the adjustment 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, 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 pay group 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 are calculated when they should not have been and these results must be completely reversed.

Example 1: Pay Group Transfer with Forwarding Retro

Scenario:

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

• In period 2, the payee transfers pay groups retroactively to pay group 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 pay group 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 pay group A. If the current calendar is for pay group B, the delta is not pulled in as an adjustment until you manually redirect the unprocessed delta to a target calendar for pay group B.

Retroactive Adds

A retroactive add occurs when there is a retroactive hire or a retroactive pay group transfer. With a retroactive hire, there is no previous calculation (prior gross-to-net). In the case of a retroactive pay group transfer, the retro add refers to the pay group 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