Enhanced Retro Pay

Enhanced Retropay

An Oracle White Paper

March 2006

ii

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

Retropay by Element (Enhanced) Page 1

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 person’s 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 fine-

tune the processing of particular elements.


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

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

PAY_DATED_TABLES

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

PAY_EVENT_UPDATES

EVENT_UPDATE_ID TABLE_NAME

COLUMN_NAME

CHANGE_TYPE DATED_TABLE_ID

EVENT_TYPE

PAY_EVENT_GROUPS

EVENT_GROUP_ID

EVENT_GROUP_NAME EVENT_GROUP_TYPE

PRORATION_TYPE

PAY_DATETRACKED_EVENTS

DATETRACKED_EVENT_ID

EVENT_GROUP_ID DATED_TABLE_ID

COLUMN_NAME

UPDATE_TYPE PRORATION_STYLE

PAY_PROCESS_EVENTS

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


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 table’s 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


, 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 Column Name Event Type Change Type

PER_ALL_ASSIGNMENTS_F EFFECTIVE_START_DATE UPDATE 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


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

period’s effective date.

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.

Effective Date Date Earned

Effective Date Date Earned

11% 12% 10%


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


• The creation date is later than the effective date

For instance if a person’s hours changed on 20-MAY-2005 but the change wasn’t

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 = 15-

MAY_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;


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 Column Name Update Type

PER_ALL_ASSIGNMENTS_F NORMAL_HOURS Datetrack Update

PER_ALL_ASSIGNMENTS_F NORMAL_HOURS 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 assignment’s 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

assignment’s elements by picking an Override Event Group in the

RetroNotification (Enhanced) parameters window. The Override Event Group

overrides any of the assignment’s 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'


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;


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 assignment’s 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:

Change Effective Date Change Date

RetroNotification

Payroll Period

Run Effective Date Run Date Earned

RetroNotification

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.


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

group’s 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. RetroNotification process RN0 is complete. 2. Changes are made on CD1 and CD2 with effective dates ED1 and ED2

respectively. 3. RetroNotification process RN1 detects changes made since RN0 and

therefore processes changes CD1 and CD2. 4. The earliest effective date found is ED1, so a

PAY_RETRO_ASSIGNMENT record will be created with REPROCESS_DATE = ED1.

Diagram 1 – RetroNotification Process

5. Changes are made on CD3 and CD4 with effective dates ED3 and ED4 respectively.

6. RetroNotification process RN2 detects changes made since RN1 and therefore processes changes CD3 and CD4.

7. The earliest effective date found is ED4, so a PAY_RETRO_ASSIGNMENT record will be created with REPROCESS_DATE = ED4.

ED1

CD1

ED2

CD2

RN1RN0


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

ED1

CD1

ED2

CD2

ED3

CD3 CD4

ED4

RN0 RN1 RN2


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. Rerun RetroNotifications Report

4. 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. Assignment ASG1 has a REPROCESS_DATE of ED1

2. Assignment ASG2 has a REPROCESS_DATE of ED2

3. When the RetroPay RP1 is run it will reprocess Payroll Results for PR1

and PR2 for ASG1.

4. When the RetroPay RP1 is run it will only reprocess Payroll Results for

PR2 only ASG2.


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 Component Name Type

AE Standard Full

CA Retropay Full

PR1 RP1PR2

Asg 1 – ED1 Asg2 – ED2


CN Tax When Earned Limited

CN Tax When Paid Full

DK Standard Full

FI Standard Full

FR Deductions Limited

FR Earnings Full

GB UK_Enhanced_Retro Full

KW Standard Full

NL Replacement Full

NL Standard Limited

NO Standard Full

NZ Backdated Changes Full

NZ Corrections Overpayments Limited

NZ Corrections Underpayments Limited

US Retropay 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 Definition

S Static Original Run Result values and Indirect

results for the Entry will be used in the

Retropay

P Partial Similar to Static, except that the Indirect

results are recalculated.

R Reprocess Full Reprocess


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 retro-

assignment.

Manually set.

Confirmed -

Awaiting

Processing

The Enhanced Retropay process will pick up retro-assignment.

Manually set.

Included -

Awaiting

Processing

The Enhanced Retropay process will pick up retro-assignment.

Automatically set.

Processing The Enhanced Retropay process is currently processing the retro-

assignment or it has errored

Completed by The Enhanced Retropay process has successfully processed a

retro-assignment that was picked up with a status of "Included -


Default Awaiting Processing".

Completed

after

Confirmation

The Enhanced Retropay process has successfully processed a

retro-assignment that was picked up with a status of "Confirmed -

Awaiting Processing ".

All

Outstandaing

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

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


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:

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.

ED1 ED2 ED3

Change Date

ED4

Start Date

RN2

RN1

ED1 ED2 ED3

Change Date

ED4

Start Date

RN2

RN1


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 pre-

START_DATE changes will be processed by the retropay.

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.

Documents

Enhanced Retro Pay