Oracle Payroll Retropay (Enhanced) - A Functional White Paper
Oracle Payroll Retropay (Enhanced) - A Functional White Paper
Oracle Payroll
Retropay (Enhanced) – A
Functional White Paper
Page 1 of 22
www.oracle.com
Table of Contents
1. Overview ............................................................................................................................................. 3
2. Definitions ........................................................................................................................................... 3
3. References........................................................................................................................................... 4
6. Functionality ....................................................................................................................................... 5
Page 2 of 22
1. Overview
This white paper describes and illustrates the functionality, usage, and setting up of Enhanced
Retropay process. This white paper assumes that users are aware of payroll functionalities and
familiar with Retropay by Element process.
This white paper explains the functional part of the Enhanced Retropay process. The technical
details are available in the white paper “Enhanced Retropay - An Oracle White Paper”. The
reference section of this white paper lists other related documents.
This white paper presents screen shots to assist you with the set up and the process of Enhanced
Retropay process. The setup section explains the components required for setting up of the
Retropay (Enhanced) feature and the process section describes running of the Retropay
(Enhanced) process.
The Frequently Asked Questions section is available to guide you with the queries you may have
while running this process.
Note: Terms ‘Enhanced Retropay’ and ‘Retropay (Enhanced)’ are interchangeably used in this
document. Both the terms refers to the same functionality.
2. Definitions
Retropay:
Retropay is a process that recalculates the amount to pay an employee in the current period to
account for retrospective changes that occurred in previous payroll periods.
Retro Elements:
Retro elements are the elements which are used for the purpose of retro processing.
Payroll Event:
A payroll event is any routine or exceptional occurrence that acts as a precondition for further
processing. For example, one can specify that a particular event or group of events should trigger
prorated calculations or Retropay notifications.
The event capture process is performed using the Payroll Events Model (PEM), based around the
use of Dynamic Triggers.
Retro Notification:
Retro Notification is a process which identifies the list of assignments for which retro processing
is required.
Page 3 of 22
Retropay Component:
Note: Retropay components are delivered by the concerned legislation teams. They cannot be
defined at the time of implementation.
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 may require a recalculation as it
affects the Taxation and Overtime calculations.
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.
3. References
The following list of documents provides comprehensive information on the payroll processing
and Retropay process.
Document Document ID
Enhanced Retropay - An Oracle White Paper. MOS Note ID 373148.1
Payroll Processing Management Guide. Part No. B31618-02
Retropay by Element. MOS Note ID 315966.1
Setup Steps For Retro-Notification Report (PAYRPRNP). MOS Note ID 216951.1
Retropay (Enhanced) and Retro-Notification Report MOS Note ID 305663.1
(Enhanced).
Additional Documentation On Dynamic Triggers. MOS Note ID 1153207.1
Oracle Payroll 'Retropay Functionality Overview' MOS Note ID 877282.1
Frequently Asked Questions (FAQ).
Retropay Overlap - A Technical White Paper. MOS Note ID 842307.1
What Localizations Support 'Retropay By Element' and MOS Note ID 1118267.1
‘Retropay Enhanced’.
Oracle Payroll 'Retropay' Frequently Asked Questions MOS Note ID 1336267.1
(FAQ).
Additional Payments including Retro, Bonus and MOS Note ID 395853.1
Commissions (Australia).
Retrospective Processing (Enhanced) in China. MOS Note ID 414426.1
4. Business Need
Businesses across the world may require processing payments retrospectively. For example, a
change to an employee’s Basic Pay in the previous pay period or a few periods earlier may
require retro processing. Since the previous period payroll is processed, disbursed, and closed, it
cannot be rerun. Moreover, this change cannot be reflected in the current period as it may have
tax impact, if the previous period falls in the previous tax year.
In this situation, the payroll needs to be re-processed for that previous period and paid in the
current period. The Retropay process helps users accomplish making payments to retrospective
changes.
Page 4 of 22
A Retropay process is typically run as a first stage in preparing the data to be processed in a
payroll period. It is a mechanism that enables retrospective changes made in completed payroll
periods to be detected and to be re-evaluated so that payments or deductions that should have
been made or taken in prior periods can be made or taken in the current period.
Retropay by Element is a concurrent process and runs using the following parameters:
• Assignment Set
• Element Set
• Start Date
• Effective Date
Retropay process rolls back in memory for each assignment in the provided Assignment Set for
any payroll action of type Payroll Run, Quick Pay, Balance Adjustment, or Reversal. Then, this
process reprocesses each of these payroll actions sequentially by considering any retrospective
changes that have occurred. Each process is rerun using the effective date that was originally
used in the original payroll action. Once the original payroll action has been rerun, the run results
of elements included in the element set are compared against (original elements) their
corresponding run results from the original run. The differences detected in any run results for a
numeric input value are stored in a retro element that is created in the payroll period defined by
the effective date parameter (usually the current payroll period). It should be noted that the
output of the Retropay process is just the retro element entries that are created in the current
period. Original payroll runs remain unaltered. Retro processing happens in memory and the
differential amount is paid / deducted in the current period.
Once the Retropay process is complete, the payroll run for the current period can be processed.
This includes the retro entries that are processed as direct entries.
However, the Retropay by Element process requires a human intervention. A pay clerk or an
administrator needs to inform the pay administrator about the changes. The pay administrator
then needs to create assignment set(s), element set(s) to include all employees and elements for
which Retropay needs to be processed.
Retropay (Enhanced) eliminates the need for human intervention. Retro Notification (Enhanced)
identifies the change events recorded in the Payroll Event Model (PEM) and creates the retro
assignments. Retro Process (Enhanced) picks these assignments for retro processing.
6. Functionality
For Retropay to function properly, there must be back-dated changes made to previous payroll
periods that have already been processed. For example, if users want to run Retropay for
Basic/Regular Salary, Overtime, or Premium Pay, they must update their base element (not the
retro element) in the originating period. Retropay identifies the differences and brings those
Page 5 of 22
differences forward into the current pay period or period derived depending on the Entry
Creation Date parameter of Retropay (Enhanced) process. For each of the elements showing a
difference between original and new entries, the process creates in the current payroll period or
period derived depending on the Entry Creation Date parameter of Retropay (Enhanced) process,
a non-recurring retroactive element with one or more element entries holding the identified
differences.
The differences detected by the Retropay process are picked by the earliest open payroll period
or period derived depending on the ‘Entry Creation Date’ parameter of Retropay (enhanced)
process. If the updates to the elements have been entered, they will be processed by Retropay.
Users can run multiple retro processes (of the same retro type) for the same period. For
example, users can run retro process A and then retro process B prior to running payroll
process. The differences detected in 'A' will not be picked up again in 'B' but all differences will
reflect into the current period or period derived depending on the ‘Entry Creation Date’ parameter
of Retropay (Enhanced) process.
Retropay (Enhanced) processes can be rolled back if necessary. Retropay is a sequenced action.
It is similar to the other Oracle Payroll processes. If multiple retro processes are run, they must
be rolled back in that order. If payroll has been run, users must roll back the payroll process
before rolling back retro.
The Retro-Notifications Report is designed to identify any changes that take place within the
application that impact a prior pay period which has already been processed. This process
identifies those assignments that may need to be re-processed (Retropay) in order to include the
retrospective changes and accordingly produces a list.
This report automatically creates data in retro assignments and retro entries.
Once the report has been run, a payroll administrator can analyze the results and can determine
all the identified assignments that require reprocessing.
Run the Retropay (Enhanced) process. This process runs on those assignments which were
identified by Retro Notification report and distributes amounts or corrections that have been
identified by the Retro Notification Report.
Page 6 of 22
7. Setup / Process
The setting up of the Retropay process involves the following steps:
The Retropay component determines the default style of Retropay processing for any localization.
For example, user can specify whether the default style is “Tax When Paid” or “Tax When
Earned”. One of the key features of Retropay (Enhanced) 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 delivered by Legislation teams and cannot be defined during
implementation.
Retro-Notifications report is used to identify any changes that have a retrospective effect for
payrolls that have already been run. User can define the relevant types of change by setting up
an event group to specify the changes. Setting up of Retro Notification report involves the
following steps:
Page 7 of 22
Navigation: Other Definitions > Dynamic Triggers
Dynamic triggers are designed to be selectively enabled and disabled by administrators. They can be
enabled for specific legislations, business groups, and payrolls. Dynamic triggers can be grouped into a
functional area so that multiple triggers can be used in a single operation. A number of predefined
dynamic triggers are delivered with Oracle HRMS.
Find a trigger that already exists. Existing triggers are referred to as static triggers. User can also create a
new trigger. Any new triggers that users create are referred to as dynamically generated triggers. It is
essential to enable the required triggers to ensure that payroll processing updates each database table
correctly. The recommended minimum list of triggers to enable retro notification report is as follows:
Select Dynamic Database Triggers. Enter a description for the trigger. This description will appear as a
comment in the generated code.
Select the table on which this trigger operates.
Select the action type for the trigger:
Page 8 of 22
• Insert - the trigger may be created after Insert.
• Update - the trigger may be created after Update.
• Delete - the trigger may be created after Delete.
Once the trigger definition is saved, the table on which a trigger is run cannot be changed. Similarly any
Action (such as Insert, Update, and Delete) that the trigger performs also cannot be changed.
2. Functional Areas
Users can use Functional Areas to group Dynamic Triggers. A functional area can be made applicable for
Legislation, Business Group, or Payroll. The functional area relevant to Continuous Calculation is called
'INCIDENT REGISTER'. Enabling the Incident Register for a Business Group generates and enables all
required triggers.
Use the Dynamic Trigger Functional Area Grouping window to include all triggers for the functional area
into a single group.
Enter a description for the new functional area, or query an existing functional area.
Select one of the following:
• Legislation
• Business Group
• Payroll
Page 9 of 22
Select the description of each trigger to be assigned to the functional area.
Enable or disable this grouping for this legislation, business group, or payroll.
Users can specify groupings for legislation only, business group only, or payroll only, or specify any
combination of these. If users do not select any of these options, then the triggers operate on all
occasions.
Table Event Updates are used for recording the events. When there are changes to employee data, this
may also imply changes to current or retrospective payroll run results for that employee. For example: an
employee receives an adjustment in the current pay period, but the adjustment was first incurred in a
previous payroll period. To identify when critical changes such as these have occurred, users can define
each change as a table event.
Page 10 of 22
4. Define 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 an event group consists of a Table and Column as well as Update
Type such as Update, Insert, Delete, Correction, Delete Future, End Date, and Purge.
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 Retro Notification (Enhanced) process. If the PEM events for
the assignment correspond to any of the events in the event groups, this indicates that the assignment
needs to be processed by the next Retro Notification process. After the Retro Notification process is run,
the corresponding assignment will be recorded in the PAY_RETRO_ASSIGNMENTS table. You can override
the event groups that have been specified on the assignment’s elements by selecting a value in Override
Event Group parameter in the Retro Notification (Enhanced) concurrent program. The Override Event
Group overrides any of the assignment’s non-null event groups.
Page 11 of 22
Create the Retro Elements
Create required elements for Retro purpose. For example, set the classification as ‘Earnings’ and type as
‘Non Recurring’. Provide other values as required for your legislation. Ensure that the input values of the
retro element should be exactly same as that of the base element.
Note: Element classification in the above illustration is given as example. Element classification differs
based on how individual legislation handles retro element processing in payroll.
Page 12 of 22
Link Retro Elements
Page 13 of 22
Associate Retro element to Base Element
Select Recalculation Events. The list of values for Recalculation Events contains the Event Groups defined
earlier for Retropay. Choose the appropriate Event Group for the element.
Page 14 of 22
Associate Retro Components and Defining Time Spans
In the Retropay Components region of the Retropay Element window, choose the component field, and
select an appropriate component from the list of values.
Retropay Component usages assign the components to the salary elements you created, ensuring all the
elements recalculate with the latest values.
If you select Static, then Retropay will not process any changes to the element when running the relevant
component. If the value ‘Reprocess’ is selected then the Retropay will perform full reprocess of all
changed entries. For reprocess type, Partial, the process is similar to Static, except that only the indirect
results are recalculated.
Opting for the Reprocess Type ensures the element changes process.
Ensure that ‘Default Component’ check box is checked for one of the selected components.
Note: ‘Static’ and ‘Partial’ Reprocess types are not available in some localizations.
The element time span usage determines which retro element to bring forward the differences into,
based on the period in which the retroactive change occurred in relation to the current period.
Page 15 of 22
You must define your Retropay elements and components before defining the element time spans.
Process
Navigation: Processes and Reports > Submit Processes and Reports > Retro-Notifications Report
(Enhanced) – PDF.
The Enhanced Retro-Notifications report uses the Payroll Events Model to identify what changes have
occurred to the underlying data. If these changes correspond to the retrospective types of change that
users want to be notified about, then these changes appear on the Retro-Notifications report.
The Retro Notification (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 Retro Notification (Enhanced) process was run. It only goes back as far as the last Retro
Notification 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:
Page 16 of 22
• 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.
Retropay Status
The assignments identified by the Retro-Notification Report (Enhanced) – PDF process will be displayed.
Users can further enter, update, and delete Retropay assignment requests. The Retro Status page also
displays a status indicating whether the request has been processed. The Retropay assignment requests
will be processed when the next Retropay (Enhanced) process is run.
If assignment is manually entered then, users must also include the Retro entries/component for that
assignment in this window.
Retropay entry details are linked to Retropay assignment requests. This indicates which components
should be processed by the Retropay (Enhanced) for a particular element entry.
Retropay Status window can be used to control how one want to process changes that have a
retrospective impact. Use the Retropay Status window to identify any assignments that have changes
implying retrospective processing or specify how one would like to process any outstanding retrospective
changes or confirm that the application has processed the specified requests.
Page 17 of 22
Run Retropay (Enhanced)
Navigation: Processes and Reports > Submit Processes and Reports > Retropay (Enhanced).
Retropay (Enhanced) is a sequenced action. This means the effective date must be later than the last
event. Effective date is the date on which the derived retro element entries need to be created.
Retropay (Enhanced) produces multiple retroactive element entries for each element entry, which
changed for each payroll period. Elements with exact names are combined on the Statement of Earnings
(SOE), Check/Cheque, Deposit Advice, and online Payslip.
Note: Combining of same elements in the SOE, Check, and Deposit Advice may defer from legislation to
legislation. In some localization, the retro elements may not necessarily be combined on the Deposit Slip,
Check Writer or Payslip. According to different legislative requirements, the retro elements for some
earnings elements may be broken out and reported for each period.
The detail of the period the retro element was generated as a result of is displayed on the Entries window
in the current payroll period. The element entry's Original Date Earned is populated with the pay period.
The Retrospective check box will be checked for the entry created by the Retropay (Enhanced) process.
Page 18 of 22
8. Frequently Asked Questions (FAQs)
1. Why to run Retropay Process?
Run the Retropay process to ensure that your payroll run for the current period reflects any back
dated payments or deductions. Backdated adjustments can occur when:
Page 19 of 22
the system are deferred forever. These retro assignments are
not processed in the future nor reported with the new status.
Deferred This status indicates that an assignment were scheduled for
processing, but that the processing was deferred and will not
occur until the status is changed to Confirmed: Awaiting
Processing, or Included: Awaiting Confirmation.
Processing This status indicates that the assignments are being
processed.
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.
8. Technically, how does Retro Notifications (Enhanced) process identify the assignments?
The Retro-Notifications Report (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 (creation_date in pay_process_events table) since the last time the Retro-Notifications
Report (Enhanced) process was run (recorded_date in pay_recorded_requests table). It only
goes back as far as the last Retro Notification run to ensure that changes that have been
processed before are not reprocessed.
Retro Notifications determines whether there are any sequenced payroll actions that have
occurred after this date. If yes, then the application identifies the assignments that need to be
reprocessed. 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 Retro Notifications process updates the PAY_RECORDED_REQUESTS
table setting the RECORDED_DATE to the current date to indicate when the process was run.
9. What are the steps required to process the Retro Process (Enhanced)?
The following steps are required to process the Retro Process (Enhanced).
10. Can I provide default values for retro element in the Retro Element setup? If yes, then what is
the impact of providing the default values?
Oracle recommends that you do not provide any default input values for the retro elements
either at element level or element link level. Input values of retro elements are populated during
Page 20 of 22
the retro process. During the retropay processing, if default input values exist, then the retro
elements are created even there are no changes to the original element.
Page 21 of 22
Title: Retropay (Enhanced) – A Functional White Paper
Dated: 17-December-2013
Contributors:
Oracle Corporation
World Headquarters
500 Oracle Parkway
Redwood Shores, CA 94065
U.S.A.
Page 22 of 22