An Oracle 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

4. Business Need ...................................................................................................................... 4

5. Understanding Retropay (Enhanced) Vis-a-Vis Retropay by Element.................. 5

6. Functionality.......................................................................................................................... 5

7. Setup / Process..................................................................................................................... 7

8. Frequently Asked Questions (FAQs)............................................................................ 19

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.

Payroll Events Model (PEM)

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:

A Retropay Component is basically a single recalculation of the affected payroll runs.

Note: Retropay components are delivered by the concerned legislation teams. They cannot be
defined at the time of implementation.

There are two categories of Retro Components:

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

5. Understanding Retropay (Enhanced) Vis-a-Vis Retropay by

Element
Retropay (Enhanced) is an enriched version of the Retropay by Element process. First let us
understand the earlier version - Retropay by Element and then understand what is enriched in
the Retropay (Enhanced) process.

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.

The following section illustrates the setup of Retropay (Enhanced) process.

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

Page 5 of 22
retro element) in the originating period. Retropay identifies the differences and brings those
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.

Retropay (Enhanced) is a two-step process with Run Retro-Notifications Report

(Enhanced) and Run Retropay (Enhanced) process

Running the Retro-Notifications Report (Enhanced) process

Run Retro-Notifications Report (Enhanced) or Retro-Notifications (EnhancedPDF) concurrent

request. This process creates data that stores details of all assignments and entries that require
Retropay because they have had retrospective changes affecting them. Thus, the created data is
known as Retro-Assignments and Retro-Entries. These entries can be viewed in the PDF file
produced by the process and/or through the Retropay Status window, which is a self-service
user interface.

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.

Running the Retropay (Enhanced) process

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:

1) Set Up the Retropay Component

2) Set Up the Retro-Notifications Report
3) Run Retropay Process

Set up the Retropay components

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.

Set Up the Retro-Notifications Report

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:

1. Enabling Dynamic Trigger

Dynamic triggers must be enabled for the functional areas for which any changes needs to be
identified for retro processing.

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:

Table Name Trigger Type

PAY_ELEMENT_ENTRY_VALUES_F Update
PAY_ELEMENT_ENTRIES_F Update
PAY_ELEMENT_ENTRIES_F Insert
PAY_ELEMENT_ENTRIES_F Delete

If required, users can create a new dynamic trigger.

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.

Save the trigger definition.

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

Navigation: Other Definitions > 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.

To group dynamic triggers into functional areas:

Enter a description for the new functional area, or query an existing functional area.
Select one of the following:
Legislation
Business Group
Payroll

Choose the name of the legislation, business group, or 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.

3. Table Event Update

Navigation: Other Definitions > Table Event Updates.

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

Navigation: Other Definitions > 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 assignments 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 assignments 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 assignments non-null event groups.

Page 11 of 22
Create the Retro Elements

Navigation: Total Compensation > Basic > Element Description.

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.

Save the details.

Page 12 of 22
Link Retro Elements

Navigation: Total Compensation > Basic > Link.

Link the defined Retropay element to the appropriate eligibility criteria.

Page 13 of 22
Associate Retro element to Base Element

Navigation: Total Compensation > Basic > Element Description.

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.

Select Retro Components.

Page 14 of 22
Associate Retro Components and Defining Time Spans

Navigation: Total Compensation > Basic > Element Description.

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.

Select the Reprocess Type.

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

Retro Notifications (Enhanced) - PDF

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 assignments Event Groups
(determined via its element entries or the override event group). For each event found it then establishes
the REPROCESS_DATE according to the following rules:

In the case of a DATE_PROCESSED event, the effective date of the change or

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

Navigation: View > 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:

An employee receives a pay award that is backdated to a previous pay period.

The payroll department makes a retrospective correction for an error that occurred in a
previous pay period.
Backdated life event occurs that affects benefit deductions or earnings.
Absence hours were not recorded in a previous period.

2. Does the Retropay process overwrite historical payment records?

Retropay does not overwrite historical payment records. Retropay recalculates all periods that
have retroactive changes whenever a Retropay is run. Retropay does not modify the stored
results for these periods. It creates one or more Retropay entries to receive the process results.

3. When should I run the Retropay Process?

Retropay should be run immediately before the Payroll run and as close to the payroll cut-off
date. The cut-off date is the point at which all data entry for the payroll is complete.

4. When will the retro adjustments be paid?

Retro adjustment is always paid in the first open payroll period or the period derived as per the
date provided in Entry Creation Date parameter of Retropay (Enhanced).

5. Can I exclude assignments from Retropay processing?

Yes, you can exclude assignments from Retropay processing by using Retropay Status page. If
the legislation rule RETRO_STATUS_USER_UPD is set to Y, then you can either exclude the
assignment from Retropay processing (you select Deferred), or include it (you select Awaiting
Processing).

However, if RETRO_STATUS_USER_UPD is set to N, then the assignment is automatically

included in the next Retropay run (it displays in View Retropay Status as Included Awaiting
Processing).

6. What are the meanings of different statuses in the Search region of Retropay Status window?

The different statuses and its purpose is as follows:

Status Purpose / Meaning

All Completed This status displays all assignments with retrospective
implications that are already processed.
All Outstanding This status displays all assignments with retrospective
implications that are not yet processed.

Page 19 of 22
 Awaiting Processing This status indicates that the assignments have cleared for
processing and that the processing will occur in the next
payroll run.
Completed This status indicates that the assignments are processed.
Completed Deferred Users can delete and move deferred retro assignment to
Forever permanently Deferred Status. Permanently Deferred
Assignments cannot be brought back into processing set.
They are marked Completed Deferred Forever.
This status indicates that the retro assignments created by
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.

7. Technically, how does Retropay process identify the assignments?

The Retropay process uses the data in PAY_RETRO_ASSIGNMENTS and PAY_RETRO_ENTRIES

tables to determine how to identify the assignment.

For each assignment it uses the REPROCESS_DATE on PAY_RETRO_ASSIGNMENTS table 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.

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.

For each event found it then establishes the REPROCESS_DATE.

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 groups events in
PAY_RETRO_ENTRIES. The REPROCESS_DATE is the date that the Retropay process will use to
determine how far back in time to go to reprocess the assignment. Once the assignment
processing is complete, the Retro Notifications process updates the PAY_RECORDED_REQUESTS
table setting the RECORDED_DATE to the current date to indicate when the process was run.

Page 20 of 22
9. What are the steps required to process the Retro Process (Enhanced)?

The following steps are required to process the Retro Process (Enhanced).

Change the assignment in the previous pay periods.

Initiate the Retro-Notifications Report (Enhanced) concurrent program.
Review the Retropay Status user interface.
Run the Retropay (Enhanced) concurrent program.
Verify the element entries.

Page 21 of 22
Title: Retropay (Enhanced) A Functional White Paper

Dated: 14-August-2012

By: Vishwanath Kuchibhotla

Contributors:

Oracle Corporation
World Headquarters
500 Oracle Parkway
Redwood Shores, CA 94065
U.S.A.

Page 22 of 22