My Oracle Support Banner

Duplicate Retropay Entries are Created After Switching from Retropay by Element to Enhanced Retropay (Doc ID 1400226.1)

Last updated on JUNE 07, 2021

Applies to:

Oracle HRMS (Singapore) - Version 12.1.3 and later
Oracle Payroll - Version 12.1.3 and later
Information in this document applies to any platform.


For Singapore payroll localization:

After switching from Retropay by Element to Enhanced Retropay, if a retroactive entry is made for an assignment with an effective date prior to the switch, retro entries that were previously processed by Retropay by Element are created again by Retropay Enhanced.  This is true for all entries after the effective date of the current (new) retroactive entry.  This is a known 'side effect' from switching from Retropay by Element to Enhanced Retropay and is documented on page 19 of the Enhanced Retropay technical brief  (<>):

Enhanced Retropay[1].pdf
Page 19

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
The RetroNotification (Enhanced) process uses the date on the
PAY_RECORDED_REQUESTS table to determine the events to process. If
there has been a change since the last time the RetroNotifications process ran then
it will be detected regardless of how far back in time the EFFECTIVE_DATE is.

If the EFFECTIVE_DATE is before the earliest START_DATE that was used
with Retropay by Element then changes that were previously ignored by retropay
could now be detected.

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
update pay_retro_assignments
set reprocess_date = START_DATE
where reprocess_date < START_DATE;

***[NOTE - THIS IS THE CUSTOMER'S ISSUE ===>] "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.****


1. Employee xxxxxx was paid Retro Handphone Allowance in April 2011 Monthly pay period, for allowances from Feb & March 2011 (original earned dates).  Processed via Retropay by Element

2. Converted from Retropay by Element to Enhanced Retropay as of 01-JUL-2011

3. On 01-SEP-2011, a COLA element entry was entered for same employee effective 01-Jan-2011.

4. Run Retro-Notifications report and see entries for employee xxxxxx , for both COLA and Handphone Allowance.  Reprocess date is 01-JAN-2011.

5. Run Retropay Enhanced and see the Retro Handphone Allowance elements are the same ones that were processed by Retropay by Element back in April 2011.

Need a code fix to prevent duplicate entries when running Retropay (Enhanced).


To view full details, sign in with your My Oracle Support account.

Don't have a My Oracle Support account? Click to get started!

In this Document

My Oracle Support provides customers with access to over a million knowledge articles and a vibrant support community of peers and Oracle experts.