Enhanced Retropay

An Oracle White Paper March 2006

Retropay by Element (Enhanced)

EXECUTIVE SUMMARY ................................................................................................ 1 OVERVIEW OF RETROPAY (ENHANCED) PROCESSES ................................. 1 Recording Payroll Events................................................................................................ 1 RetroNotification (Enhanced) Process......................................................................... 1 Retro Status ....................................................................................................................... 1 RetroPay Process.............................................................................................................. 2 PAYROLL EVENT MODEL........................................................................................... 2 Dated Tables ..................................................................................................................... 2 Diagnostics.................................................................................................................... 3 Event Updates .................................................................................................................. 4 Diagnostics.................................................................................................................... 6 Process Events.................................................................................................................. 6 Diagnostics.................................................................................................................... 7 Event Groups ................................................................................................................... 8 Diagnostics.................................................................................................................... 8 RETRONOTIFICATIONS PROCESS ........................................................................ 10 RetroNotifications Example .................................................................................... 11 Diagnostics.................................................................................................................. 12 RETROPAY PROCESS ................................................................................................... 13 RETROELEMENTS AND COMPONENTS ............................................................ 14 Retro Components......................................................................................................... 14 Assigning components to Element Types ................................................................. 15 Time Spans ...................................................................................................................... 16 RETRO STATUS WINDOW ......................................................................................... 16 Retro Assignments ......................................................................................................... 16 Retro Entries ................................................................................................................... 17 SWITCHING TO ENHANCED RETROPAY.......................................................... 17 Initializing Retropay (Enhanced) ................................................................................. 19

ii

Retropay by Element (Enhanced)

EXECUTIVE SUMMARY

Retropay by Element has been the recommended way to process retrospective changes that need to be processed in payroll. Retropay by Element (Enhanced) delivers additional features that allow the user to fine tune the way certain elements are processed in Retropay. It also introduces a different way of processing sets of assignments that mean that each assignment is processed more efficiently. This white paper is intended to give the reader an understanding of the setup and workings of the Oracle Payroll Enhanced Retropay system. It is a complimentary paper to the following paper published on Metalink: Note:315966.1 - RetroPay by Element
OVERVIEW OF RETROPAY (ENHANCED) PROCESSES Recording Payroll Events

During the course of managing a persons employee/assignment and related setup data, certain events are recorded in the Payroll Events Model (PEM). Each event record holds data about the type of change, e.g. update, insert or delete, the table and column that changed, the date the change was made and the date on which the change was effective.
RetroNotification (Enhanced) Process

The RetroNotification (Enhanced) process detects assignments that have events in the PEM that were created since the last RetroNotification process. It determines whether the event is one that could cause retrospective pay to be required. If any such events are detected the assignment is recorded in the PAY_RETRO_ASSIGNMENTS table and the elements that are affected are stored in PAY_RETRO_ENTRIES table.
Retro Status

The data stored in PAY_RETRO_ASSIGNMENTS and PAY_RETRO_ENTRIES is accessible in the Retro Status page. Depending on whether the legislation has allowed customers to modify the status it may be possible to control which of the assignments to process in Retropay and to finetune the processing of particular elements.

Retropay by Element (Enhanced) Page 1

RetroPay Process

The RetroPay process uses the data in PAY_RETRO_ASSIGNMENTS and PAY_RETRO_ENTRIES to determine how to reprocess the assignment. For each assignment it uses the REPROCESS_DATE on PAY_RETRO_ASSIGNMENTS to determine how far back to reprocess the assignment. Any payroll actions for the assignment that occurred on or after the REPROCESS_DATE will be rolled back and reprocessed. When a payroll process is rolled back and reprocessed in RetroPay the results are compared against the original run results. Any differences are posted in the payroll period indicated by the EFFECTIVE_DATE of the RetroPay run.
PAYROLL EVENT MODEL

PAY_DATED_TABLES

PAY_EVENT_UPDATES

DATED_TABLE_ID TABLE_NAME OWNER SURROGATE_KEY_NAME START_DATE_NAME END_DATE_NAME APPLICATION_ID DYN_TRIGGER_TYPE DYN_TRIGGER_PACKAGE_NAME DYN_TRIG_PKG_GENERATED

EVENT_UPDATE_ID TABLE_NAME COLUMN_NAME CHANGE_TYPE DATED_TABLE_ID EVENT_TYPE

PAY_PROCESS_EVENTS

PAY_EVENT_GROUPS

PAY_DATETRACKED_EVENTS

EVENT_GROUP_ID EVENT_GROUP_NAME EVENT_GROUP_TYPE PRORATION_TYPE

DATETRACKED_EVENT_ID EVENT_GROUP_ID DATED_TABLE_ID COLUMN_NAME UPDATE_TYPE PRORATION_STYLE

PROCESS_EVENT_ID ASSIGNMENT_ID EFFECTIVE_DATE CHANGE_TYPE STATUS DESCRIPTION EVENT_UPDATE_ID ORG_PROCESS_EVENT_GROUP_ID SURROGATE_KEY CALCULATION_DATE RETROACTIVE_STATUS

Dated Tables

The payroll event model is used to capture events that occur whilst using Oracle HRMS. The events that are captured are used in Continuous Calculation, Daily Business Intelligence Reporting and to identify Proration and Retropay events in payroll. It is possible to capture events that result in data being created, modified or deleted in a number of HRMS tables, these tables are identified in PAY_DATED_TABLES. Each table in PAY_DATED_TABLES can be associated with one or more dynamic trigger that is executed when an insert, update or delete occurs. These triggers are built dynamically using the Dynamic

Retropay by Element (Enhanced) Page 2

Trigger generation process and are created based on data entered in the Dynamic Trigger definition form and stored in the following tables:
PAY_TRIGGER_COMPONENTS PAY_TRIGGER_DECLARATIONS PAY_TRIGGER_EVENTS PAY_TRIGGER_INITIALISATIONS PAY_TRIGGER_PARAMETERS PAY_TRIGGER_SUPPORT

Depending on the HRMS table in question, the dynamic trigger will either be created as a database trigger or an API User Hook. Database trigger names will be constructed in the form: {TABLE_NAME}_{UNIQUEID}{U/I/D}_DYT. e.g. PERALLASSIGNMENTSF_50U_DYT. HRMS tables adopting the user hook method have the dynamic trigger package name identified in the column PAY_DATED_TABLES.DYN_TRIGGER_PACKAGE_NAME. This trigger is executed from the HRMS tables row handler AFTER_UPDATE code when a change is made to the table.
Diagnostics

The following SQL statement can be used to find all the PAY_DATED_TABLES and to see whether they use a package or a database trigger to capture events. select DATED_TABLE_ID , APPLICATION_ID , TABLE_NAME , SURROGATE_KEY_NAME , START_DATE_NAME , END_DATE_NAME , BUSINESS_GROUP_ID , LEGISLATION_CODE , DYN_TRIGGER_TYPE , DYN_TRIGGER_PACKAGE_NAME , DYN_TRIG_PKG_GENERATED from pay_dated_tables where nvl(dyn_trig_pkg_generated, 'Y') = 'Y' order by application_id,table_name; The following SQL can be used to determine the individual event triggers and the code that will actually be executed (module_name) that will be generated into the dynamic database trigger or package. select te.event_id

Retropay by Element (Enhanced) Page 3

, te.table_name , te.short_name trigger_name , te.triggering_action , te.generated_flag , te.enabled_flag , tc.module_name from pay_trigger_events te , pay_trigger_components tc where tc.event_id(+) = te.event_id and te.enabled_flag = 'Y' and tc.enabled_flag = 'Y' and te.generated_flag = 'Y' order by table_name;

Event Updates

When configuring the Payroll Event Model it is necessary to determine the specific events that need to be recorded, these are stored in PAY_EVENT_UPDATES. Each PAY_EVENT_UPDATE record indicates the type of event, i.e. Insert, Update, Delete, and in the case of Updates an indication of the specific column that should be monitored for changes. It also uses the CHANGE_TYPE column to indicate whether the change would be of interest to processes that depend on DATE_EARNED, DATE_PROCESSED, COST_CENTRE or REPORTS. For instance in the case of Retropay it might only be considered necessary to identify changes that were made to the assignment if they occurred on or before the DATE_PROCESSED (EFFECTIVE_DATE) of the payroll run (in the normal course of processing an assignment any changes to the assignment after the EFFECTIVE_DATE of the run would not affect the processing of the run). Thus a PAY_EVENT_UPDATE record might be entered as follows:
Table Name PER_ALL_ASSIGNMENTS_F Column Name EFFECTIVE_START_DATE Event Type UPDATE Change Type DATE_PROCESSED

When an update to PER_ALL_ASSIGNMENTS_F.EFFECTIVE_START_DATE actually occurs it will create a row in PAY_PROCESS_EVENTS with an EVENT_TYPE of DATE_PROCESSED along with the EFFECTIVE_DATE of the change. For the purposes of Retropay it is important to consider carefully the change type required for each event update record, and in order to be able to that it is necessary to understand the effect of a particular change in the payroll run. The change types that affect Retropay are DATE_PROCESSED and DATE_EARNED. To illustrate the effect of these change types consider the following payroll period: A B C

Retropay by Element (Enhanced) Page 4

Effective Date

Date Earned

When processing an assignment the payroll run uses the DATE_EARNED to retrieve elements, it may also use DATE_EARNED when evaluating certain database items whilst processing an element. Otherwise it uses the EFFECTIVE_DATE of the run to determine the values it needs to complete its processing, for instance Global values, User defined table values, assignment values etc.. So in the above example if a change were made at A it would have a material effect irrespective of whether it was being retrieved as of DATE_EARNED or EFFECTIVE_DATE. Change B would only have a material effect if it were being retrieved as of DATE_EARNED. Change C would have no effect on the processing.

Another way to determine which of the dates is required is to consider whether a retrospective change affects the way the build up to gross is calculated. If the change does not affect build up to gross then it is likely that the change affects rates that are picked up as of the EFFECTIVE_DATE (DATE PAID). Consider the following case where an element entry with pay value of 1000 is taxed at 10%. There is a retrospective change of tax rate to 11% effective as of the beginning of the period followed by a change to 12% on a date after the original periods effective date.

10%

11% Effective Date

12% Date Earned

Had the change not occurred the 1000 would have been taxed at 10% on the EFFECTIVE_DATE resulting in a tax of 100. With the 11% and 12% changes the net effect is that the 1000 is taxed at 11% on Date Paid resulting in a tax of 110. The fact that the rate is 12% after Effective Date is irrelevant to the processing for this period because the tax value is determined at the Effective Date.

Retropay by Element (Enhanced) Page 5

In order to limit the amount of work the RetroNotification process has to do the use of DATE_PROCESSED change type ensures that any superfluous changes (i.e. the 12% change) are ignored by the Retro-Notifications report. The element entries are processed as of DATE_EARNED so any change to the 1000 in the retro-period needs to be detected up until Date Earned. Hence it is necessary to detect this change type for changes that affect earnings.
Diagnostics

The following SQL statement can be used to list the Event Updates for each Dated Table. This can be useful when trying to determine which changes will be detected in the PEM.
select peu.DATED_TABLE_ID , pdt.TABLE_NAME , peu.EVENT_TYPE , peu.COLUMN_NAME , peu.CHANGE_TYPE , peu.BUSINESS_GROUP_ID , peu.LEGISLATION_CODE ,event_update_id from pay_event_updates peu , pay_dated_tables pdt where nvl(peu.legislation_code,'&leg_code') = '&leg_code'' and nvl(peu.business_group_id,&bg) = &bg and peu.dated_table_id = pdt.dated_table_id order by TABLE_NAME,EVENT_TYPE,COLUMN_NAME;

It should be noted that in the case of DateTracked Tables (e.g. PER_ALL_ASSIGNMENTS_F) for event types of CORRECTION the column name can be any column on the table whereas for UPDATES the only columns that are recorded are changes to EFFECTIVE_START_DATE and EFFECTIVE_END_DATE. In the latter case the RertoNotification Process determines the specific column that has changed.
Process Events

Any events that are detected and match an event update defined for the legislation or business group will be recorded in PAY_PROCESS_EVENTS. This table identifies the event type, the change type, the object on which the change took place (i.e. the assignment ID or element entry ID) and the date on which the event was effective (EFFECTIVE_DATE). It also records the system date on which the change was actually made (CHANGE_DATE). Process Events that could result in a retropay being required are those that meet the following criteria:
The event was created since the previous RetroNotification process was run

Retropay by Element (Enhanced) Page 6

 The creation date is later than the effective date

For instance if a persons hours changed on 20-MAY-2005 but the change wasnt recorded until 25-MAY-2005 then the event model would have a record showing: CHANGE_DATE = 25-MAY-2005 EFFECTIVE_DATE = 20-MAY_2005 It should be noted that events can have a CREATION_DATE <= EFFECTIVE_DATE, but for Retropay purposes we are only interested in changes where CREATION_DATE > EFFECTIVE_DATE. Even if an event has been created retrospectively it may still be processed as part of a standard payroll run. For instance in the example above the retrospective change would have been processed in a payroll run if the run was performed on or after 25-MAY-2005 as long as the effective date of the run was >= 20-MAY_2005 However if the payroll run was processed with EFFECTIVE_DATE = 15MAY_2005 the retrospective change would be omitted and it would be an event that is processed in the next RetroNotification report.
Diagnostics

The following SQL is useful when investigating RetroPay and RetroNotification issues. It lists out all the payroll events for an assignment ordered according to the date the events were actually logged (most recent change at the top of the list).
select ppe.assignment_id assignment_id, ppe.status status, ppe.description description, ppe.effective_date effective_date, peu.change_type change_type , peu.column_name column_name, pdt.table_name table_name, peu.event_update_id, peu.event_type, ppe.surrogate_key, ppe.creation_date from pay_process_events ppe, pay_event_updates peu, pay_dated_tables pdt where ppe.event_update_id = peu.event_update_id and peu.dated_table_id = pdt.dated_table_id and ppe.assignment_id = :asg_id and ppe.change_type in (DATE_EARNED,DATE_PROCESSED) order by ppe.creation_date desc, ppe.effective_date desc;

Retropay by Element (Enhanced) Page 7

Event Groups

In Retropay an Event Group identifies the specific type of retrospective events that will require the reprocessing of a payroll. Each item in a event group consists of a Table and Column as well as the type of update, insert or delete. For instance if a change of NORMAL_HOURS would require the reprocessing of a payroll run then the Event Group will have the following definition:

Table Name PER_ALL_ASSIGNMENTS_F PER_ALL_ASSIGNMENTS_F

Column Name NORMAL_HOURS NORMAL_HOURS

Update Type Datetrack Update Datetrack Correction

In Enhanced Retropay an assignment is considered to be associated with one or more event groups through its element entries. Each corresponding element type can have an event group. The element types associated with an assignments entries determine the set of event groups that will be examined when processing a given assignment in the RetroNotification (Enhanced) process. If the PEM events for the assignment correspond to any of the events in the event groups then the assignment will be recorded in the PAY_RETRO_ASSIGNMENTS table, this indicates that it needs to be processed by the next RetroNotification process. It is possible to override the event groups that have been specified on the assignments elements by picking an Override Event Group in the RetroNotification (Enhanced) parameters window. The Override Event Group overrides any of the assignments non-null event groups.
Diagnostics

The following query lists out the event groups and the datetracked events that each event group contains. This can be useful when investigating why a particular event has or has not been detected when processing elements with a particular event group.
select eg.event_group_name , dt.UPDATE_TYPE_MEANING , dt.TABLE_NAME , dt.COLUMN_NAME , dt.BUSINESS_GROUP_ID , dt.LEGISLATION_CODE from pay_datetracked_events_v dt , pay_event_groups eg where eg.event_group_id = dt.event_group_id and nvl(dt.legislation_code,':leg_code') = ':leg_code'

Retropay by Element (Enhanced) Page 8

and nvl(dt.business_group_id,:bg_id) = :bg_id order by eg.event_group_id , dt.table_name , dt.column_name , dt.update_type_meaning;

Retropay by Element (Enhanced) Page 9

RETRONOTIFICATIONS PROCESS

The RetroNotification (Enhanced) process identifies records in PAY_PROCESS_EVENTS that have an EVENT_TYPE of either DATE_PROCESSED or DATE_EARNED and that have been created since the last time the RetroNotification (Enhanced) process was run. It only goes back as far as the last RetroNotification run to ensure that changes that have been processed before are not reprocessed. For each event it determines whether the event corresponds to an event in any of the assignments Event Groups (determined via its element entries or the override event group). For each event found it then establishes the REPROCESS_DATE according to the following rules:
In the case of a DATE_PROCESSED event the effective date of the change or In the case of a DATE_EARNED event the earliest of the effective date of the change or the effective date of the run in which the change would have been processed had it existed when the run was originally processed

To illustrate the last point consider the following diagram:

RetroNotification

RetroNotification

Change Effective Date

Change Date

Payroll Period Run Effective Date Run Date Earned

A RetroNotification process ran prior to a payroll period being processed with Run Effective Date and Run Date Earned as shown. Since then a change has been made with Change Effective Date as shown. A further RetroNotification is then run. The later RetroNotification searches back as far as the earlier RetroNotification for changes that have happened in that period. It detects the change that was made and identifies the effective date of that change. Now, if the change has a type of DATE_PROCESSED the RetroNotification stores the change effective date. If the change has a type of DATE_EARNED the RetroNotification stores the earliest of the change effective date and the Run Effective Date.

Retropay by Element (Enhanced) Page 10

Finally RetroNotifications determines whether there are any sequenced payroll actions that have occurred after this date. If so then it flags the assignment as needing to be reprocess as of the above date. It then records the ASSIGNMENT_ID and REPROCESS_DATE in the PAY_RETRO_ASSIGNMENTS table and the elements that match the event groups events in PAY_RETRO_ENTRIES. The REPROCESS_DATE is the date that the Retropay process will use to determine how far back in time to go to reprocess the assignment. Once the assignment processing is complete the RetroNotifications process updates the PAY_RECORDED_REQUESTS table setting the RECORDED_DATE to the current date to indicate when the process was run.
RetroNotifications Example

Consider the following scenario (see diagram 1): 1. 2. 3. 4. RetroNotification process RN0 is complete. Changes are made on CD1 and CD2 with effective dates ED1 and ED2 respectively. RetroNotification process RN1 detects changes made since RN0 and therefore processes changes CD1 and CD2. The earliest effective date found is ED1, so a PAY_RETRO_ASSIGNMENT record will be created with REPROCESS_DATE = ED1.

RN0 ED1 ED2

RN1

CD1

CD2

Diagram 1 RetroNotification Process 5. 6. 7. Changes are made on CD3 and CD4 with effective dates ED3 and ED4 respectively. RetroNotification process RN2 detects changes made since RN1 and therefore processes changes CD3 and CD4. The earliest effective date found is ED4, so a PAY_RETRO_ASSIGNMENT record will be created with REPROCESS_DATE = ED4.

Retropay by Element (Enhanced) Page 11

RN0 ED4 ED1 ED2

RN1 ED3

RN2

CD1

CD2

CD3

CD4

Diagram 2 RetroNotification Process with additional changes

Diagnostics

The following SQL can be used to determine whether an assignment has been recorded in PAY_RETRO_ASSIGNMENTS:
select * from pay_retro_assignments where assignment_id = :asg_id; select * from pay_retro_assignments a , pay_retro_entries e where a.assignment_id = :asg_id and a.retro_assignment_id = e.retro_assignment_id;

The following SQL will show when the last RetroNotification process was run for a particular assignment:
select recorded_date from pay_recorded_requests where attribute_category = 'RETRONOT_ASG' and attribute1 = :asg_id;

It should be noted that there is no explicit record of when earlier RetroNotification runs were performed. (ER 4947381 has been raised to store the previous RetroNotifcation date). However it is possible to determine the date of the last RetroNotification process by looking at the date of the previous RetroNotification concurrent process. The following SQL statement can be used to find this date:
select pyr.payroll_name , to_char(request_date,'DD-MON-YYYY') from fnd_concurrent_requests cr , fnd_concurrent_programs_vl cp , pay_payrolls_f pyr where cr.concurrent_program_id = cp.concurrent_program_id and cp.application_id = 801

Retropay by Element (Enhanced) Page 12

and

cp.user_concurrent_program_name = 'Retro-Notifications Report (Enhanced)' and to_char(pyr.payroll_id) = substr(argument10,12,length(argument10)) order by 1,2 desc;

The RetroNotifications process is a PL/SQL program that is initiated from a concurrent program. Diagnostic information can be retrieved from this process as follows: 1. Enable FND Diagnostics Set profile values as follows: FND: Diagnostics = Yes FND: Debug Log Level = Statement FND: Debug Log Enabled= Yes FND: Debug Log Module = % 2. Clear down the log table
delete from fnd_log_messages;

3. 4.

Rerun RetroNotifications Report Extract results from the trace

select * from fnd_log_messages order by log_sequence desc;

RETROPAY PROCESS

The RetroPay process uses the data in PAY_RETRO_ASSIGNMENTS and PAY_RETRO_ENTRIES to determine how to reprocess the assignment. For each assignment it uses the REPROCESS_DATE on PAY_RETRO_ASSIGNMENTS to determine how far back to reprocess the assignment. Any sequenced payroll actions for the assignment that occurred on or after the REPROCESS_DATE will be rolled back and reprocessed. Consider the following scenario: 1. 2. 3. 4. Assignment ASG1 has a REPROCESS_DATE of ED1 Assignment ASG2 has a REPROCESS_DATE of ED2 When the RetroPay RP1 is run it will reprocess Payroll Results for PR1 and PR2 for ASG1. When the RetroPay RP1 is run it will only reprocess Payroll Results for PR2 only ASG2.

Retropay by Element (Enhanced) Page 13

PR1

PR2

RP1

Asg 1 ED1

Asg2 ED2

Diagram 3 RetroPay Process for 2 assignments When a payroll process is rolled back and reprocessed in RetroPay the results are compared against the original run results. Any differences are posted in the payroll period indicated by the EFFECTIVE_DATE of the RetroPay run.
RETROELEMENTS AND COMPONENTS Retro Components

One of the key features of Enhanced Retropay is the ability to control how individual elements are treated when being reprocessed in Retropay. Different types of Retropay processing are controlled by Retropay Components that are attached to element types in the Retro Component window. Retropay Components are currently delivered by legislation teams and cannot be defined by implementation teams. Retro Components fall into the following 2 categories:
Full Recalculation - where the whole run needs to be rolled back and rerun to correctly process a change to an entry, for example, a change to Salary might need a full recalculation because it affects Tax and Overtime. Limited Recalculation - where a run is partially rolled back and is therefore less expensive, such as a change to Tax, which does not affect any other elements.

Some legislations setup their Components so that they will perform a complete replacement of the results of an affected run. Thus, if the system detects that a delta is needed, instead of just creating the delta for the entry concerned, it negates ALL the results for that Run and creates them in the current period. Also for legislations carrying our full replacement Retropay, there is an additional requirement to be able to override the date earned on certain elements during Retropay, this can be done by specifying the name of a procedure that will be called to override the date. The following table shows a list of components that have been delivered by legislations at the time of writing: Legislation AE CA Component Name Standard Retropay Type Full Full

Retropay by Element (Enhanced) Page 14

CN CN DK FI FR FR GB KW NL NL NO NZ NZ NZ US

Tax When Earned Tax When Paid Standard Standard Deductions Earnings UK_Enhanced_Retro Standard Replacement Standard Standard Backdated Changes Corrections Overpayments Corrections Underpayments Retropay

Limited Full Full Full Limited Full Full Full Full Limited Full Full Limited Limited Full

Assigning components to Element Types

When implementing Enhanced Retropay one of the setup steps is to indicate the component that will used to reprocess each element, this is done in the Recalculation tab in the element types window. As part of this definition a Reprocess Type must be entered to indicate how the Element is to be processed in the Retropay. This column can take the following values: Lookup Code Meaning S Static Definition Original Run Result values and Indirect results for the Entry will be used in the Retropay Similar to Static, except that the Indirect results are recalculated. Full Reprocess

P R

Partial Reprocess

Retropay by Element (Enhanced) Page 15

For Full Recalculation components, only Reprocess can be set for this value. However, Limited Recalculation Components also have Static and Partial options.
Time Spans

Another key feature introduced with Enhanced Retropay is the ability to post retrospective changes into different retro elements depending on the time elapsed since the original payroll run was performed and the type of change being made. For example, the user can specify that a change to an element entry should be retropaid onto element A if the change has occurred in the last month, or onto element B if the change in question happened 6 months ago. Another key feature in this area is that retro elements can be specified for both customer and seeded elements.
RETRO STATUS WINDOW Retro Assignments

As described in the earlier section on RetroNotifications, assignments that are deemed to need retroprocessing are stored in PAY_RETRO_ASSIGNMENTS and the element entries that have been detected as requiring reprocessing are identified in PAY_RETRO_ENTRIES. The new RetroPay Status page has been delivered to allow customers to view the assignments that will be reprocessed in Retropay. In addition if the legislation has enabled modification of these records it is also possible to manually control the assignments that will be processed and to fine-tune the way the elements are processed. On the Retro Status window there is a Status field with the following values: Deferred The Enhanced Retropay process will not pick up retroassignment. Manually set. Confirmed Awaiting Processing Included Awaiting Processing Processing Completed by The Enhanced Retropay process will pick up retro-assignment. Manually set. The Enhanced Retropay process will pick up retro-assignment. Automatically set. The Enhanced Retropay process is currently processing the retroassignment or it has errored The Enhanced Retropay process has successfully processed a retro-assignment that was picked up with a status of "Included -

Retropay by Element (Enhanced) Page 16

Default Completed after Confirmation All Outstandaing

Awaiting Processing". The Enhanced Retropay process has successfully processed a retro-assignment that was picked up with a status of "Confirmed Awaiting Processing ". Used for query purposes in the Retro-Status page. Returns retro-assignments with a status of : "Confirmed Awaiting Processing", "Deferred", "Included - Awaiting Processing", "Processing".

There is a legislation rule named "RETRO_STATUS_USER_UPD" that determines whether the localization permits the manual intervention in the RetroAssignments or not. If it is set to yes, the retro-assignment can have either a status of Deferred" or "Confirmed - Awaiting Processing", users can switch the status between Deferred" and "Confirmed - Awaiting Processing. When the rule is set to N or doesn't exists, then manual intervention is not allowed and the records are created with default status as "Included - Awaiting Processing".
Retro Entries

Retro Entry records are stored with the corresponding Retro Assignment and indicate the Retro Component that will be used to process the element entry in Retropay. Retropay processes components starting with the lowest priority in the Retropay Entry table and continuing in order of increasing priority. If the legislation has enabled the feature customers can change the component that an entry is process in, thereby overriding the component and reprocess type that was defined in the Element Type screen.

SWITCHING TO ENHANCED RETROPAY

When running Retropay by Element the RetroNotification process takes a START_DATE parameter that determines how far back the process should search for events that could cause retrospective changes of pay. This limits the changes that processed to those with an EFFECTIVE_DATE on or after the START_DATE. The RetroNotification (Enhanced) process uses the date on the PAY_RECORDED_REQUESTS table to determine the events to process. If there has been a change since the last time the RetroNotifications process ran then it will be detected regardless of how far back in time the EFFECTIVE_DATE is.

Retropay by Element (Enhanced) Page 17

If the EFFECTIVE_DATE is before the earliest START_DATE that was used with Retropay by Element then changes that were previously ignored by retropay could now be detected. To illustrate this consider the following:

Start Date ED4 ED1 ED2 ED3

RN2 RN1

Change Date

Diagram 4 RetroNotification (Retropay by Element)

In this scenario a company has a policy of running Retropay by Element back to the beginning of the year (START DATE). A change is made on CHANGE DATE with an EFFECTIVE_DATE of ED4. Other retrospective changes ED1, ED2 and ED3 already exist. In Retropay by Element both RetroNotification processes RN1 and RN2 will detect change ED3. (N.B. although this assignment will be identified as needing to be processed the retropay process will only produce delta values once). Changes ED1, ED2 and ED4 will be ignored because they are prior to START_DATE.

Suppose the company had run RetroNotification process RN1 and then they changed to Retropay Enhanced. The PAY_RECORDED_REQUESTS.RECORDED_DATE would record the date that RN1 was run so the RetroNotification process RN2 would only detect changes made after RN1 date. It would therefore detect the change made on CHANGE_DATE.

Start Date ED4 ED1 ED2 ED3

RN2 RN1

Change Date

Retropay by Element (Enhanced) Page 18

Diagram 5 RetroNotification (Enhanced)

The change on CHANGE_DATE has an EFFECTIVE_DATE of ED4 so a record in PAY_RETRO_ASSIGNMENTS would be created with a REPROCESS_DATE of ED4. When the Retropay runs it will reprocess payroll actions from ED4 onwards and it would therefore reprocess the change made on ED1 and ED2 as well as ED3. This will therefore produce different results from Retropay by Element.
Initializing Retropay (Enhanced)

If the scenario described above is likely to occur then it is possible to update each of the PAY_RETRO_ASSIGNMENT records after the 1st RetroNotification (Enhanced) process has run to ensure that the REPROCESS_DATE is no earlier than START_DATE.
update pay_retro_assignments set reprocess_date = START_DATE where reprocess_date < START_DATE;

This approach has the limitation that if in the future another change is made with EFFECTIVE_DATE earlier than START_DATE then once again the preSTART_DATE changes will be processed by the retropay.

Retropay by Element (Enhanced) Page 19

Retropay by element (Enhanced) March 2006 Author: John Rhodes Contributing Authors: Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA 94065 U.S.A. Worldwide Inquiries: Phone: +1.650.506.7000 Fax: +1.650.506.7200 www.oracle.com Oracle Corporation provides the software that powers the Internet. Oracle is a registered trademark of Oracle Corporation. Various product and service names referenced herein may be trademarks of Oracle Corporation. All other product and service names mentioned may be trademarks of their respective owners. Copyright 2002 Oracle Corporation All rights reserved.