enhanced retro pay
TRANSCRIPT
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 by Element (Enhanced) Page 2
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
Retropay by Element (Enhanced) Page 3
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
Retropay by Element (Enhanced) Page 4
, 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
Retropay by Element (Enhanced) Page 5
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%
Retropay by Element (Enhanced) Page 6
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 7
• 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;
Retropay by Element (Enhanced) Page 8
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'
Retropay by Element (Enhanced) Page 9
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 10
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.
Retropay by Element (Enhanced) Page 11
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
Retropay by Element (Enhanced) Page 12
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
Retropay by Element (Enhanced) Page 13
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.
Retropay by Element (Enhanced) Page 14
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
Retropay by Element (Enhanced) Page 15
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
Retropay by Element (Enhanced) Page 16
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 -
Retropay by Element (Enhanced) Page 17
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.
Retropay by Element (Enhanced) Page 18
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
Retropay by Element (Enhanced) Page 19
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.