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

Last updated on OCTOBER 11, 2016

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.

Symptoms

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 White Paper (<>):

Enhanced Retropay[1].pdf
Page 19


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.

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
than START_DATE.
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.****


  Example:

1. Employee 195950 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 195950, 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).


Cause

Sign In with your My Oracle Support account

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

My Oracle Support provides customers with access to over a
Million Knowledge Articles and hundreds of Community platforms