Setting Up Retroactive Processing
To set up retroactive processing, use the Countries (GP_COUNTRY) and the Retro Process Definitions (GP_RTO_PRC_DEFN) components.
|
Page Name |
Definition Name |
Usage |
|---|---|---|
|
Countries |
GP_COUNTRY |
Define the retro method at the country level. |
|
Retro Process Definitions |
GP_RTO_PRC_DEFN |
Define a retro process. |
|
Retro Event Definition |
GP_RTO_EVT |
Associate a triggering event (a change in critical data) with one of the processes that you defined on the Retro Process Definition page. |
|
Retro Limits |
GP_PYENT_RETRO |
Define the backward and forward limits for retro processing at the pay entity level. |
|
Retro Limits Assignment |
GP_PYE_RTO_LIM |
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. |
Follow these steps to set up retroactive processing:
Specify the retroactivity defaults.
Using the Countries page, select the corrective method for processing retroactivity. (Forwarding retro applies only to Global Payroll.)
See Countries Page.
Define a retro 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 trigger event IDs.
Use the Retro Event Definition page to associate the retro process you defined in step 2 with a trigger event ID. This event ID tells the system how to process data changes to the records or fields you make sensitive to retroactive data changes in step 4 (see below).
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 3. 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.
Determine which pay entities allow retroactive processing.
Use the Pay Entity Retro Limits page to enable retroactive processing of calendars in a pay entity.
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.
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 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.
Use the Countries page (GP_COUNTRY) to define the retro method at the country level.
Navigation:
Note: We discuss the Countries page in detail elsewhere in this documentation.
See Countries Page.
Use the Retro Process Definitions page (GP_RTO_PRC_DEFN) to define a retro process.
Navigation:
This example illustrates the fields and controls on the Retro Process Definitions page.
Field or Control |
Description |
|---|---|
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.
Use the Retro Event Definitions page (GP_RTO_EVT) to associate a triggering event (a change in critical data) with one of the processes that you defined on the Retro Process Definition page.
Navigation:
This example illustrates the fields and controls on the Retro Event Definitions page.
The mechanism that is used to track online data changes that should trigger retroactive processing is called a trigger. In Absence Management, 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:
On the Retro Event Definitions page, associate each of the retro processes defined on the Retro Process Definitions page with a trigger event ID.
On the Trigger Definitions page, identify the records and fields that should trigger retroactive processing when data is modified or updated retroactively.
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 another topic, this topic describes only the use of the Retro Event Definitions page.
See Understanding Trigger Definition Setup.
Field or Control |
Description |
|---|---|
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.
Use the Retro Limits page (GP_PYENT_RETRO) to define the backward and forward limits for retro processing at the pay entity level.
Navigation:
This example illustrates the fields and controls on 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 Absence Management 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.
Field or Control |
Description |
|---|---|
Process Retro |
Select to enable retroactive processing at the pay entity level. You can override your selection at the payee level. |
Acm Adjustments Persist(accumulator adjustments persist) |
Select to retain adjustments to accumulator balances when retroactive processing causes an accumulator to be recalculated in a prior period. This option may be needed because Absence Management does not automatically include adjustment amounts when recalculating accumulator balances. For example, if you select this check box and reprocess a prior period in which an accumulator with a value of 100 received an adjustment of 10, the system computes the incoming balance as the sum of the original accumulator and the user-entered adjustment, and returns a value of 110. Otherwise, the system ignores the adjustment and returns a balance of 100. Note: The preferred approach to managing accumulator balances is to correct the elements (entitlements or takes) that contribute to the accumulator, rather than to adjust the accumulator directly. This is because other accumulators that store period-to-date amounts or other values based on the calculation of the same elements will not be automatically updated, possibly resulting in calculation or reporting errors. Note: To adjust accumulator balances, use the Adjust Accumulator Balance page. |
Deltas Cross Pay Groups |
Leave this check box empty. It applies only to Global Payroll. |
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 date limits how far back in time you can go to process retroactivity. |
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 can calculate into the past. 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 years, select this option and enter the number of years that the system is to calculate into the past. 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 can go 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. |
Example 1: Using months criterion to determine the first retro period to recalculate.
|
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 |
Absence Management determines the backward limit by going back two months from the current calendar period begin date of June 1, 2005, providing a 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 are recalculated. April (April 1, 2005−April 30, 2005) and May (May 1, 2005−May 31, 2005).
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).
|
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 |
Absence Management 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, 2004. The system compares the 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 will be recalculated.
Example 3: Using years, months, and days criteria to determine the first retro period to recalculate (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 |
Absence Management 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, 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
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.
Field or Control |
Description |
|---|---|
No Limit - Forward |
If you select this option, retroactive data 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 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 the forward limit in years, select this option and enter the number of years beyond the inactive date to process retro. The year, in conjunction with the Retro Fwd Limit Start Month and Retro Fwd Limit Start Day, determines how long after the inactive date the system allows retroactivity processing. |
Retro Fwd Limit Start Month (retro forward limit start month) |
Enter 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. 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. |
Example 1: Using months criterion to determine the first retro period to recalculate (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 |
Absence Management 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 criterion to determine the first retro period to recalculate (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 |
Absence Management 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.
Use the Assign Retro Limits page (GP_PYE_RTO_LIM) to 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.
Navigation:
This example illustrates the fields and controls on the Assign Retro Limits 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 topic we discuss only the fields that are unique to the Retro Limits Assignment page.
Field or Control |
Description |
|---|---|
No Retro Processing Before |
This date is the date when Absence Management begins processing 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 retroactivity to be processed. If you select this check box, the fields in the Backward Limit and Forward Limit group boxes become available for data entry. |