RetroPay (Enhanced) and Retro-Notification Report (Enhanced) [ID 305663.

1]
https://support.oracle.com/epmos/faces/SearchDocDisplay?_adf.ctrl-
state=l99sy1g0y_4&_afrLoop=107449909854965




RetroPay (Enhanced) and Retro-Notification Report (Enhanced) (Doc
ID 305663.1)
To
Bottom



Retropay (Enhanced) and Retro-
Notification Report (Enhanced)
This document provides North American Oracle Payroll clients setup and usage information
for Retropay (Enhanced) and Retro-Notification (Enhanced) PDF.
Updated: 30-Jul-2007
For US customers, this functionality was delivered in one-off patch 4241247 and was later
included in HRMS Family Pack K (July 2005). For CA customers, this functionality is only
included in HRMS Family Pack K (July 2005).
Originally there was a single version of Retropay that aggregated the results. This process is
called RetroPay (a.k.a. RetroPay by Aggregate). For the North American localizations (US
and CA) Retropay by Element followed this. Retropay (Enhanced) is built on top of the
Retropay by Element solution. Note: RetroPay by Run is not supported in the US or CA.
Retropay by Element greatly improved Oracle Payroll's retroactive calculation mechanism.
Changes are calculated at the lowest possible level, run result values. The RetroPay by
Element process was an enhancement for calculating a breakdown of retroactive payments by
element. The primary benefit of this was recording the payment associated with the elements
and time periods from which they were earned.
RetroPay (by Aggregate) aggregated the payments over a period or a multiple period interval
as lump-sum retroactive adjustments in the regular payment period. The RetroPay by
Element process brought finer granularity to the retropay process. The Retropay (Enhanced)
solution is implemented to provide added flexibility and additional features. RetroPay
(Enhanced) replaces RetroPay by Element but retains its original characteristics.
RetroPay by Element produced multiple retroactive element entries for each element entry,
which has been changed for each payroll period. This functionality continues with Retropay
(Enhanced).
For retropay to function properly, there must be retrospective entries made to payroll periods
already processed. For example, if you want to run retropay for Regular Salary, Overtime,
Shift Differential, you must enter your base element (not the retro element) in the originating
period. Retropay identifies the differences and bring those differences forward into the
current pay period. For each of the elements showing a difference between original and new
entries, the process creates, in the current payroll period, a nonrecurring retroactive element
with one or more element entries holding the identified differences.
The differences detected by the retropay process must go into the earliest open payroll
period. If the updates to the elements have been entered, they will be processed by
Retropay. You can run multiple retro processes (of the same retro type) for the same period.
For example, run retro process A and then retro process B prior to running your payroll
process. The differences detected in 'A' will not be picked up again in 'B' but all differences
go into the current period.
Retro 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 order. If payroll has been run, you must roll back the payroll process before rolling
back retro.
IMPORTANT NOTE: Only one retropay process can be used at a given time. Running more
than one type of retropay concurrent process at a time may result in incorrect results being
calculated. It is not possible to adopt the use of Retropay (Enhanced) and continuing to use
the RetroPay (by Aggregate) process.
If you utilize the QuickPay functionality and QuickPays will be included in the retrospective
periods for which RetroPay by Element is run, ensure that you have enabled the QuickPay
Exclusion functionality. For further details refer to 'About Oracle HRMS Family Pack H'
(Note: 277349.1) and Note:279773.1 - GUIDE TO THE QUICKPAY EXCLUSIONS DATA
UPDATE PROCESS
Retropay (Enhanced) is a two-stage process:
First process:
Run the Retro-Notification Report (Enhanced) - PDF concurrent request. The process
creates data that stores details of all assignments and entries that require retropay because
they have had retrospective changes affecting them. This 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 new RetroPay Status window, which has a self-service user
interface.
Second process:
Run the Retropay (Enhanced) process. This process drives off the new data tables to only re-
process those assignments with changed data and only re-process historical data back to the
required effective date.
The Retropay (Enhanced) process has the following features:
- Users are provided the additional ability to setup Retropay summary elements for seeded
elements. You are not currently able to do this with RetroPay by Element.
- The process reprocesses based on the earliest assignment reprocess date (as opposed to the
user supplied date). Hence the process runs for as far back in time as is necessary for each
individual assignment. This change enhances the performance of the process.
Implementation for North American Oracle Payroll
Customers
If you have never used RetroPay by Element:
Application of HRGLOBAL enables Retropay (Enhanced). RetroPay (by Aggregate)
continues to appear in the list of values for the seeded Request Groups; however, RetroPay by
Element will no longer be available. You are not required to run the "Generic Upgrade
Mechanism" process.
Current RetroPay by Element Users:
Running the Generic Upgrade Mechanism process enables Retropay (Enhanced) if you are
currently using RetroPay by Element. A new value "Upgrade Elements for Enhanced
Retropay for all US Business Groups" or "Upgrade Elements for Enhanced Retropay for
all CA Business Groups" is available in the Name parameter of the Generic Upgrade
Mechanism process.
If you have previously run RetroPay by Element, application of HRGlobal does not enable
Retropay (Enhanced). Running the Generic Upgrade Mechanism process controls this. This
allows you to determine when you are ready to move from RetroPay by Element to Retropay
(Enhanced).
The Generic Upgrade Mechanism process identifies all elements included in Element Sets of
the type "Run Set" and checks if the element set has been used in the RetroPay by Element
process based on payroll actions. If this is the case, the process upgrades these elements to
support Retropay (Enhanced).
The upgrade process/application of HRGlobal/application of the patch performs the
following:
- Creation of a Retro Component for all the elements that are upgraded.
- Recalculation Tab and the Retro Component button on the Element Description window is
enabled.
- Retro element (if one currently existed) is moved under Retro Component.
- Creation of a new seeded Event Group called Regular Earnings. This event group is
attached to the seeded elements such as Regular Salary, Regular Wages, etc. It can be
selected for user-defined elements.
- Removal of the Retropay by Element process from the List of Values for seeded Request
Groups
NOTE: If you have not used RetroPay by Element previously these are inserted by
HRGLOBAL.
The HRGlobal patch inserts data into these additional retro tables:
PAY_RETRO_COMPONENTS
PAY_RETRO_DEFINITIONS
PAY_RETRO_DEFN_COMPONENTS
PAY_TIME_SPANS
PAY_TIME_DEFINITIONS
The Generic Upgrade Mechanism process upgrades each element which then inserts data into
these additional retro tables:
pay_retro_component_usages (stores Full Recalculation)
pay_e (stores retro element name)
Definitions
Retropay Component:
A Retropay Component is basically a single recalculation of the affected payroll runs.
Currently when Retropay is processed, internally the process rolls back the affected Payroll
Runs then recalculates them to find the changes and brings those deltas into the current
period.
There is one component seeded for the both US and CA called Retropay'. This component
supports Full Recalculation. Full Recalculation is where the entire 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 Overtime.
Setup
1) Enable Dynamic Triggers and Create your event group.
Refer to Oracle Applications Online Help for details on creating Event Groups and enabling
Dynamic Triggers. As part of the upgrade, there is an Event Group delivered called Regular
Earnings. You can use this event group or you can create your own event group (see
MetaLink Note: 216951.1)
2) Create the retro earnings element.
If you have previously defined retro elements for use in RetroPay by Element, as a result of
the Generic Upgrade Mechanism process, that element has been moved from the original
RetroPay Element field found on the Recalculation tab to the new Retro Element field
discussed in Step 3 below. If you have not previously run RetroPay by Element or you are
using seeded elements, you may want to define a retro element.
Navigation > Total Compensation > Basic > Earnings
Generally, this earnings element is a non-recurring element and has similar attributes as the
base element. Create the link for this element and cost appropriately. This step is NOT
mandatory. Creation of a retro element may be necessary if:
- the retro amount is to be displayed separately from the base element's amount
- costing of the retrospective amount is handled differently then the base element
- formulas for other elements need to exclude the retro calculated amount
- the element impacts overtime (or overtime premium). When the RetroPay Enhanced process
is run, the retrospective runs are re-processed and hours or earnings entered retrospectively
and processed during this retro calculation use the FLSA balances which determine the rate
of pay. If you use this same base element as your 'retro' element, this element continues to
feed the FLSA balances and your retro amount brought forward into the current pay period
may incorrectly impact the employee's overtime calculation in the current pay period. For
additional details on FLSA and defining overtime/overtime premium elements, refer to
MetaLink note: 338245.1.
If a retro element is not defined, the difference is shown with the base element.
3) Complete Element Type Setup
As a result of the Generic Upgrade Mechanism process, this step is completed for elements
that were included in an Element Set that has previously been used in a RetroPay by Element
process.
IT IS IMPORTANT THAT THIS STEP BE COMPLETED FOR ALL ELEMENTS TO BE
USED IN RETROPAY ENHANCED INCLUDING THE SEEDED ELEMENTS (i.e.
Regular Salary, Regular Wages, Overtime etc.). Before logging a Service Request (SR),
verify your setup is complete even if it is anticipated that this was done automatically for you
during the upgrade.
If you have not previously run RetroPay by Element, you must manually complete this step.
Navigation > Total Compensation > Basic > Element Description > query base element
The Element Type setup for Retropay is handled on the Recalculation tab of the Element
Description window.
Select the Recalculation Events. This is the event group defined in step 1 above. After
entering the Recalculation Event and saving, click on the Retro Components button.
The Recalculation window is divided into two sections.
The top section indicates how the element is to be processed in Retropay Component. The
Reprocess Type indicates how the Element is to be processed in Retropay. For the US, there
is one Component available called Retropay and one Reprocess Type called Reprocess.
IMPORTANT: The Default Component check box must be checked.
The second half of this window relates to the entry that is to be created for the delta. The
Element Type used for the new Entry is based on a set of rules around the time since the
Payroll Run was performed and the type of change being made. Start of Time and End of
Time are the available choices for the Time Span From and To.
If applicable, select the Retropay Element. An element for seeded elements (i.e. Regular
Salary, Time Entry Wages) can now be added.
As a result of the Generic Upgrade Mechanism process, if you previously had defined a retro
element, that element has been moved from the original RetroPay Element field found on the
Recalculation tab to this field. If you have not previously run RetroPay by Element or you are
using seeded elements, you must define your retro element (if applicable) and complete this
step.
Running the Processes
The Retropay (Enhanced) process uses a different mechanism for identifying the assignments
to be processed. Retropay (by Aggregate) and RetroPay by Element previously identified
assignments by an Assignment Set and recalculated all the payroll runs between the supplied
start and end date.
This approach is inefficient because each assignment should only be recalculated for the
period that they need to be. For example, if Assignment A needs to be recalculated from 16th
March and Assignment B from the 16th April, currently both were processed from the 16th
March.
With RetroPay (Enhanced) an assignment set is no longer used. The concept of creating a
request to retropay an assignment is now introduced. The request takes the form of
identifying the assignment to process and the date from which the recalculation will take
place.
There are three ways to make a request for an assignment to be retrospectively paid:
1) Retro-Notification Report (Enhanced) PDF. This process generates the requests.
2) Details can be entered manually in the new self-service (framework) form
3) API
Note: Retropay (Enhanced) no longer uses an assignment set. You must use either Retro-
Notification Report (Enhanced), the new RetroPay Status form or the API.
Retro-Notification (Enhanced) PDF Parameters:
Payroll (required)
Overriding Event Group
Template Name (required) there is one template currently called Retro-Notifications Report
(Enhanced)
As with the previous version (Retro-Notification Report provided several years ago), the
process creates a report that displays all assignments that have had a Datetracked Event
identified in the Retro Event Group you defined. Retro-Notification can be run more than
once for the same time frame. Assignments are not dropped off this report until the Retropay
(Enhanced) process is run.
This report has been added for the appropriate seeded payroll request groups. If you have a
custom request group, you must add this new request.
Retropay Status Window
This form appears on the navigator, but you must be logged into the E-Business Suite Home
page to access it. This form has been added for all seeded responsibilities. If you have custom
menus or responsibilities, you must add this form.
The assignments identified by the Retro-Notification Report (Enhanced) PDF process will
be displayed. You can further enter, update and delete retropay assignment requests. The
form also shows 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 you manually enter an assignment, you 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 API
New with HRMS FPK RUP2 (June 2007) MetaLink readme Note: 422918.1
Use a Rapid Upload API to Collect Any Outstanding Entries for Retrospective Pay
New Package
PAY_RETRO_STATUS_LOAD. It contains:
Loading RetroPay Assignments and Entries (Load_Retro_Asg_and_Entries)
Updating or Deleting RetroPay Assignments (Update_or_Delete_Retro_Asg)
This API creates records in pay_retro_assignments allowing Enhanced RetroPay to process
the employees just as it would do if the RetroNotifications report was run instead. The API is
provided to allow mass loading of the tables when a selective review of events in the system
is not required. In other words, you must know who and when to include the individual
assignments. It loads the retro assignments and the retro entries (which contain details of the
components).
Retropay (Enhanced)
The RetroPay by Element process used an Element Set to indicate which element changes
should be brought forward. An Element Set is no longer required. The setup of the Retro
Components now identifies the elements to be used by the retropay process.
Parameters:
Effective Date (required)
Payroll (required)
Retropay (Enhanced) is a sequenced action. This means the Effective Date must be later than
your last event. For example: your current payroll period is April 16 to 29. Your previous
payroll's check date was April 22. The Effective Date would be any date between April 23
and the end date of the current payroll run, which is April 29.
Retropay (Enhanced) produces multiple retroactive element entries for each element entry,
which changed for each payroll period. Elements with exact names will be combined on the
statement of earnings (SOE), check, deposit advice and online payslip.
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 that the difference is from. There is a 'Retrospective' check box
also. This check box will be checked for any entry created by the Retropay (Enhanced)
process.
This process has been added for the appropriate seeded payroll request groups. If you have a
custom request group, you must add this new request.
In HRMS Family Pack K (July 2005), a new Discoverer workbook HRMS - Retropay
Element Entry Details with GRE and Salary Proposals has been provided. There was also a
Retro Discoverer Workbook provided in HRMS Family Pack J. Refer the the About HRMS
Family Pack J document available on MetaLink. The original workbook is modified in
HRMS Family Pack K. There are two new columns added. Refer to the About HRMS
Family Pack K Document available on MetaLink for additional information.