Defining Retroactive Processing

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

Set up retroactive processing.
Define trigger event IDs.
Define backward and forward retroactive limits.
Manage unprocessed retroactive deltas.
Understand general rules of retroactive processing.
Understand complex retroactive processing.

Understanding Retroactive Processing

Retroactive (retro) processing refers to the recalculation of prior periods due to changes in payee data that could result in adjustments to entitlement or compensation.

Absence Management uses a form of retroactive processing referred to as corrective retro. With corrective retro, the system:

Recalculates the elements of the absence run that are defined to be recalculated during retroactive processing.
Replaces the previous calculations with the recalculated values for the elements of the run.
Updates balance and segment accumulators in the recalculated period.
Computes retro deltas and stores them in the recalculated period.
Executes a full reversal of the prior calculation results.

The recalculated run replaces the previously calculated run. However, the original run calculations remain available for auditing and reporting purposes. Retro deltas are stored in the recalculated period.

Example 1: Corrective Retro—No Exceptions

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

Re-Calc Option	Calendar Period 1	Prior Results (Old Value)	Re-Calculation (New Value)	Deltas	Corrective Replace Old Value with New Value	Forward Y/N
Always	Earnings 1	100	120	20	Y	N
Always	Deduction 1 (flat amount)	30	30	0	Y	N

This table shows the processing results for the example above:

Calendar Period 2	Current Results	Retro Adjustmt
Earnings 1	120	None
Deduction 1 (flat amount)	30	None

In this example, only Earnings 1 generates a retro delta. The new value of Earnings 1 replaces its old value.

Understanding Key Terms

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

Version and Revision Numbers

In the following sections you will see numerous references to version and revision numbers. Absence Management tags each Payee Process Stat record with a version and revision number. The version number is the vehicle for tracking recalculation of a calendar period due to retroactivity.

The system defines the original set of output results for a calendar calculation as Version 1, Revision 1 (V1R1). Each subsequent recalculation of the calendar increases the version number while the revision number stays at one. For example, the first retro would be Version 2, Revision 1 (V2R1). The second retro would be Version 3, Revision 1 (V3R1), and so forth. (Revision numbers are updated only in Absence Management.)

Prior Results and Recalculated Results

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

Recalc Period

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

Retro Deltas

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

Retro on Retro

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

See Also

Tracking Recalculated Calendars

Setting Up Retroactive Processing

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

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

Define the retroactivity defaults at the country level.
Define a retro process.

Understanding Retroactive Processing Setup

The steps for setting up retroactive processing are:

Specify the retroactivity defaults.

Using the Countries page, select the corrective method for processing retroactivity. (Forwarding retro applies only to Global Payroll.)

Use the Store Non-Zero Delta Component check box to indicate whether you want to store any delta amount or delta component that has a non-zero value, regardless of the setting on the Element Name (GP_PIN) page.

See Defining Country-Level Setup.
Define a process.

Once you have selected a default method for the country, define a retro process on the Retro Process Definition page.
Map retro processes to Event IDs.

Use the Retro Event Definition page to associate each process that you defined in step 2 with a trigger event ID. This event ID is used to identify the process definition (see Step 2).
Define trigger fields.

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

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

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

Note. You can override the backward and forward limits at the payee level using the Retro Limits Assignment page.
View, add, and cancel retro triggers.

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

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

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

Pages Used to Set Up Retroactive Processing

Page Name	Object Name	Navigation	Usage
Countries	GP_COUNTRY	Set Up HRMS, Product Related, Global Payroll & Absence Mgmt, System Settings, Countries, Countries	Define the retro method at the country level.
Retro Process Definition	GP_RTO_PRC_DEFN	Set Up HRMS, Product Related, Global Payroll & Absence Mgmt, Triggers, Retro Process Definitions	Define a retro process.

Defining Retroactivity Defaults

Access the Countries page.

Note. We discuss the Countries page in detail elsewhere in this PeopleBook.

See Defining Country-Level Setup.

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

For Absence Management, this value should always be set to Corrective.

Retro Method Varies

Leave this check box empty. It applies only to Global Payroll.

Retro Method Decided By

The fields in this group box apply only to Global Payroll.

Defining Trigger Event IDs

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

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

Understanding Triggers

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

Use the Retro Event Definition page to associate the events (such as retroactive entitlement increases) that are to trigger retro processing to a process that you identified on the Retro Process Definition page. This association—between an event and a process definition—is identified in the system through a trigger event ID.
Use the Trigger Definitions - Trigger Definition page to map trigger fields or records to a trigger event ID that you defined on the Retro Event Definition page. This ID tells the system what process to use when fields or records are modified—it is one of the pieces of processing information that is written to the trigger tables when fields or records are modified. Since the Trigger Definitions - Trigger Definition page is documented in the chapter “Setting Up Triggers,” this section describes only the use of the Retro Event Definition page.

See Also

Defining Triggers

Page Used to Associate a Triggering Event

Page Name	Object Name	Navigation	Usage
Retro Event Definition	GP_RTO_EVT	Set Up HRMS, Product Related, Global Payroll & Absence Mgmt, Triggers, Retro Event Definitions	Associate a triggering event (a change in critical data) with one of the processes that you defined on the Retro Process Definition page.

Associating a Triggering Event With a Process

Access the Retro Event Definition page.

Country

This display-only field is populated based on the country that you selected on the search page.

Trigger Event ID

This display-only field is populated based on the trigger event ID that you selected on the search page.

Link each trigger event ID to one of the processes you defined on the Retro Process Definition page.

Retro Process Definition ID

Select a process that you defined on the Retro Process Definition page to link to the trigger event ID.

Note. Different countries can process the same event differently.

Absence Event

Select if the trigger event ID is for an absence event only.

Example of an Absence Event

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

Note. Absence balance accumulators are always defined as corrective—they must be updated (replaced) at the end of each calculation period.

See Also

Setting Up Triggers

Setting Up Accumulators

Defining Backward and Forward Retroactive Processing Limits

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

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

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

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

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

Understanding Backward Limits

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

Backward Limit Date	This date—defined on the Retro Limits page—establishes the maximum number of periods that the system recalculates going back into the past. This date is only an outer limit; the number of periods that are recalculated can be less than the limit.
Trigger Effective Date	This date—the effective date of the change that triggers retro—sets a theoretical goal for how far back the system goes when calculating retro. When the system determines which periods to process, the backward limit date takes precedence over the trigger date. For example, if the trigger effective date is January 1, 1990, and the backward limit date is January 1, 2000, 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, 2000, then the trigger effective date establishes the number of periods that are recalculated.
No Retro Processing Before Date	This is the date that a payee enters the Absence Management 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.

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

First recalculation period

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

Understanding Forward Limits

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

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

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

Pages Used to Define Backward and Forward Retroactive Processing Limits

Page Name	Object Name	Navigation	Usage
Retro Limits	GP_PYENT_RETRO	Set Up HRMS, Product Related, Global Payroll & Absence Mgmt, Framework, Organizational, Pay Entities, Retro Limits	Define the backward and forward limits for retro processing at the pay entity level.
Retro Limits Assignment	GP_PYE_RTO_LIM	Global Payroll & Absence Mgmt, Payee Data, Create Overrides, Assign Retro Limits	Override, at the payee level, the backward and forward limits for retro processing that you established at the pay entity level on the Retro Limits page.

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

Access the Retro Limits page.

Process Retro

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

Retro Period Backward Limit

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

No Limit - Backward	If you select this option, then retro processing begins with the first period that includes the trigger effective date and goes forward. Selecting this option does not mean that there are no limits to how far back you can go. The No Retro Processing Before field plays a role in determining how far back you can process retro. The No Retro Processing Before field is on the Retro Limits Assignment page.
Limit by Months - Backward and Number of Months - Backward	To define a limit in terms of months, select this option and enter the number of months that the system is to calculate backward. The system determines the maximum number of months to go back starting from the begin date of the first calendar in the current calendar group for the payee.
Limit by Years - Backward and Number of Years - Backward	To define a limit in terms of years, select this option and enter the number of years that the system is to calculate backward. This limit year, in conjunction with the Retro Back Limit Start Month and Retro Back Limit Start Day fields, determines how far back the system goes when processing retroactivity. For example, if Number of Years - Backward is 2, Retro Back Limit Start Month is 06 (June), Retro Back Limit Start Day is 01, and the current period begin date is April 1, 2005, then the backward limit is June 1, 2003. The system allows retroactivity 2 years from the current period begin date, but not prior to June 1 of that year.
Retro Back Limit Start Month	Select the calendar month to use as the backward limit.
Retro Back Limit Start Day	Select the day to use as the backward limit.

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

Example 1: Using months criterion.

Trigger Effective Date	Current Calendar Period	Backward Limit	First Retro Period
February 15, 2005	June 1, 2005−June 30, 2005	2 months = April 1, 2005	April 1, 2005–April 30, 2005

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

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

Trigger Effective Date	Current Calendar Period	Backward Limit	First Retro Period
June 30, 2004	June 1, 2005−June 30, 2005	Year =1, Month = 3, Day = 15 (March 15, 2004)	June 1, 2004−June 30, 2004

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

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

Trigger Effective Date	Current Calendar Period	Backward Limit	First Retro Period
February 28, 2004	June 1, 2005−June 30, 2005	Year = 1, Month = 3, Day =15 (March 15, 2004)	March 1, 2004−March 31, 2004

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

Retro Period Forward Limit

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

No Limit - Forward	If you select this option, retro can be processed indefinitely for inactive payees belonging to this Pay Entity. Although eligible for retro processing, the inactive payee is still restricted by the backward limits.
Limit by Months - Forward and Number of Months - Forward	To define the forward limit in terms of months, select this option and enter the number of months to continue calculating retroactivity after a payee becomes inactive. The system determines the maximum number of months using the Inactive date of the last active job.
Limit by Years - Forward and Number of Years - Forward	To define your limit in terms of years, select this option and enter the number of years beyond the inactive date to process retro. The year, in conjunction with Retro Fwd Limit Start Month and Retro Fwd Limit Start Day, determines how far forward from this inactive date the system goes when processing retroactivity.
Retro Fwd Limit Start Month (retro forward limit start month)	The calendar month to use as the forward limit in conjunction with the year in the Number of Years - Forward field.
Retro Fwd Limit Start Day (retro forward limit start day)	The day to use as the forward limit in conjunction with the year and month entered in the Number of Years - Forward and Retro Fwd Limit Start Month fields. So, for example, if the Number of Years is 2, the Retro Fwd Limit Start Month is 06 (June), the Retro Fwd Limit Start Day is 01, and the termination date is January 1, 2005, the limit for processing retroactivity would be June 1, 2007. In this example, the system knows to allow retroactivity for 2 years from the Inactive date, but not after June 1 of that year.

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

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

Inactive Date	Current Calendar Period	Forward Limit	Eligible for Retro Processing?
January 1, 2005	June 1, 2005−June 30, 2005	12 months (January 31, 2006)	Yes

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

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

Inactive Date	Current Calendar Period	Forward Limit	Eligible for Retro Processing?
January 31, 2005	June 1, 2005−June 30, 2005	3 months (April 30, 2005)	No

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

Defining Retro Processing Limits at the Payee Level

Access the Retro Limits Assignment page.

No Retro Processing Before

This date is the date when Absence Management begins processing calculations for a payee. It is set by the system, but you can override it. The system cannot process retroactivity for a payee prior to this date. If a payee has multiple jobs, be sure that this date is correct, to support all jobs.

Use Pay Entity Retro Limits

Select to use the retro limits that are defined for the pay entity to which the payee belongs. When this check box is selected, the system uses the values from the pay entity definition, and all other fields on this page, other than No Retro Processing Before, are unavailable for entry. When this check box is cleared, the Process Retro check box becomes available for entry, and the system uses the values that were entered at the payee level, rather than those that were entered at the pay entity level.

Process Retro

Select if you want the retro calculation to be processed. If you select this check box, the fields in the Backward Limit and Forward Limit group boxes become available for entry.

Additional Pages Affecting Retroactive Processing

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

Page Type	Page Name	Description
General Setup	Pay Entity - Processing Details	Define payment keys. Retro adjustments respect payment key values when they are applied to a segment.
Calendar Setup	Run Types	Specify the run types that can process retro triggers. The run type is linked to a calendar, which is linked to a calendar group. If at least one calendar in the group is defined to process retro triggers, the calendar group uses the information defined for the run type as the default to process retro triggers.
Calendar Setup	Calendars - Definition	Specify the population of payees to choose for a calendar run. You can also select payees with retro triggers (active or inactive) for processing, if selected payees with retro triggers will be included.
Calendar Setup	Calendar Group	Define whether to process or not process retro triggers defaults from Run Type. If at least one calendar allows retro triggers to be processed, the Process retro triggers check box will be selected, otherwise it will be cleared. It can be cleared to not process retro triggers. However, it may not be set to process retro triggers if the default has the check box cleared.

Understanding General Rules of Retro Processing

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

This section discusses how Absence Management:

Tracks recalculated calendars.
Calculates retro deltas and processes adjustments.
Loads balance accumulators.
Stores recalculated results.
Reverses previous results.

Tracking Recalculated Calendars

In this section are numerous references to version and revision numbers. Absence Management tags each Payee Process Stat Record (payee process status record) with a version number to track the recalculation of a calendar period due to retroactivity.

The system defines the original set of output results for a calendar calculation as Version 1, Revision 1 (V1R1). Each subsequent recalculation increments the version number by 1. The revision number stays the same. For example, the first corrective retro is Version 2, Revision 1 (V2R1). The second corrective retro (retro on retro) is Version 3, Revision 1 (V3R1), and so forth.

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 in Retro Adds

A retro add is a situation in which a previous calculation does not exist for a payee, and retroactivity calls for a payee process status record to be created for the first time. For example, it is determined that a payee whom you thought was hired in February was actually hired in January. There are no calculations for January, so when January is processed for retro, the system must create a payee process status record for the period and assign version and revision numbers to it. In this case, the first calculation is labeled V1R1. The reason is that corrective retro replaces the results of the prior calculation (it does not use them only to create retro deltas), so when a period is added, it treats this period as if it were the original one.

The following tables illustrate how the system numbers payee process status records in retro add situations:

Scenario:

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

Period/Recalculation	Numbering
Period 1 (original calculation)	V1R1
Recalc No. 1	V2R1
Recalc No. 2 (reversal)	V3R1
Recalc No. 3 (add)	V4R1

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

See Also

Retroactive Adds

Retroactive Deletes

Calculating Retro Deltas and Processing Adjustments

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

Calculating Retro Deltas

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

Period 1	Value of E1	Delta
V1R1	20
V2R1	30	E1 (V2R1) − E1 (V1R1) = 10
V3R1	40	E1 (V3R1) − E1 (V2R1) =10

Example: Processing Deltas

Following is an example of how the system calculates deltas for retro on retro.

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.

Version/ Revision Number	Load YTD Balances	Period 1	Load YTD Balances	Period 2	Load YTD Balances	Period 3
V1R1	Load 0	E1 = 10	Load 200	E1 = 20	Load 60	E1 = 30
V2R1	Load 0	E1 = 20 Delta = 10	Load 30	E1 = 30 Delta = 10
V3R1	Load 0	E1 = 30 Delta = 10

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

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

First retro calculation:

Period 1 (V2R1): E1 = 20

Delta = 10 [20 (V2R1) − 10 (V1R1)]. New value replaces old value.
Second retro calculation (retro on retro):

Period 1 (V3R1): E1 = 30

Delta = 10 [30 (V3R1) − 20 (V2R1)]. New value replaces old value.
Period 2 (V2R1): E1 = 30

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

Loading Balance Accumulators

Before elements are recalculated during retro, balances must be loaded to produce the correct value for the balance accumulators.

The system loads the balance for the element from the calculation with the highest version number in the previous period.

Storing Recalculated Results

When a trigger starts retroactive processing for a payee, the system recalculates each calculation 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:

Stores prior results for auditing purposes.
Replaces the prior results with new ones in the recalculated period and stores the new calculation results for each payee.

These results represent the true results for that period.

Understanding Complex Retro Processing

This section discusses:

Segmentation and retro.
Retroactive deletes.
Retroactive adds.

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.

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

See Defining Segmentation.

Calculating Deltas in Matched and Mismatched Segments

The way that Absence Management 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.

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. The only results that are written to the output result tables are for deltas and balance accumulators. For calculating deltas, the new values are assumed to be 0.

The new recalc segments generate the new values. The new values are written to the output result tables. For calculating deltas, the old values are assumed to be 0.

Note. When the value of a payment key (for example, company ID) changes between a prior calculation and the recalculation, the system handles the situation as a segment mismatch. That is, it treats the old and new calculations as belonging to separate segments—just as if the segment dates no longer matched.

See Defining Segmentation.

Retroactive Deletes

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

Retroactive Adds

A retroactive add occurs when there is a retroactive hire or a retroactive paygroup transfer. With a retroactive hire, there is no previous calculation. In the case of a retroactive paygroup transfer, the retro add refers to the paygroup the payee is transferred to.

Tips for Retroactive Processing

The following table provides hints on using retroactive processing.

Question	Answer
Can Absence Management calculate retro across countries?	The default retro method, retro process definitions, and trigger event IDs are defined by country. The system does not calculate retro across countries. However, if a payee transfers to another country, and it’s later discovered that the payee should have received additional entitlement while employed in the first country, it might be possible to process retro for that payee even though he or she is inactive in the original country. This depends on the forward limits that apply at the pay entity level and other processing rules that determine how long after a payee is inactive he or she remains eligible for retroactive processing.
What happens when multiple triggers are generated and each points to a different retro process definition?	Suppose that multiple retro events occur, causing multiple retro triggers to be written to the trigger tables. If these triggers call for that calendar run to be processed (recalculated) using different process definitions, a conflict will occur. In such a situation, where the events that cause retroactive processing activate the application of more than one process definition for the same payee in the same calendar, the system writes an error message and does not process retro. Only the current period is calculated. Retro triggers are not marked as processed. Note. The retro conflict method that is specified on the Countries page does not apply to the conflict situation described here. In this situation, the retro conflict method will not resolve the conflict. However, you can change the event ID that is associated with the retro trigger, using the Payee Trigger Retro Expanded page. For a payee, you cannot have more than one process definition resulting from the retro events that cause retroactivity for that calendar run. The same process must apply for all calendars in the calendar group.

Question

Answer

Can Absence Management calculate retro across countries?

The default retro method, retro process definitions, and trigger event IDs are defined by country. The system does not calculate retro across countries. However, if a payee transfers to another country, and it’s later discovered that the payee should have received additional entitlement while employed in the first country, it might be possible to process retro for that payee even though he or she is inactive in the original country. This depends on the forward limits that apply at the pay entity level and other processing rules that determine how long after a payee is inactive he or she remains eligible for retroactive processing.

What happens when multiple triggers are generated and each points to a different retro process definition?

Suppose that multiple retro events occur, causing multiple retro triggers to be written to the trigger tables. If these triggers call for that calendar run to be processed (recalculated) using different process definitions, a conflict will occur. In such a situation, where the events that cause retroactive processing activate the application of more than one process definition for the same payee in the same calendar, the system writes an error message and does not process retro. Only the current period is calculated. Retro triggers are not marked as processed.

Note. The retro conflict method that is specified on the Countries page does not apply to the conflict situation described here. In this situation, the retro conflict method will not resolve the conflict. However, you can change the event ID that is associated with the retro trigger, using the Payee Trigger Retro Expanded page.

For a payee, you cannot have more than one process definition resulting from the retro events that cause retroactivity for that calendar run. The same process must apply for all calendars in the calendar group.

See Also

Setting Up Retroactive Processing

Defining Segmentation

Retro Process Definition ID (retroactive process definition ID)	Identifies the retro process you are defining.
Retro Method	For Absence Management, this value should always be set to Corrective.
Retro Method Varies	Leave this check box empty. It applies only to Global Payroll.

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

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