Who's Online Now
0 registered members (), 3 guests, and 19 spiders.
Key: Admin, Global Mod, Mod
Newest Members
SAI, Balasubramaniam, Dataterrain, Sarathy R, pjchiverton
1258 Registered Users
Recent Posts
Warning: VAT scam
by CT. 19/10/17 09:27 AM
EDI Replacement
by PaulD. 12/10/17 10:27 AM
Future dated records and API
by hpatel15. 10/10/17 08:04 AM
Faster Payments
by pat. 04/10/17 08:56 AM
Additional Org Info: Org Developer DF
by Sarathy R. 04/10/17 06:54 AM
Monthly Data Collection
by hpatel15. 28/09/17 07:33 AM
Top Posters(30 Days)
SBi 2
PaulD 2
CT 1
delboy 1
pat 1
Bobin 1
Popular Topics(Views)
417,709 PAYE RTI
49,884 HR_PF.K RUP4
Previous Thread
Next Thread
Print Thread
Rate This Thread
#11881 - 15/03/17 02:23 PM Limiting the reach of Enhanced Retro  
Joined: Mar 2005
Posts: 1,285
bcooper Offline
bcooper  Offline


*****

Joined: Mar 2005
Posts: 1,285
Earth, Europe, England, here
Hello all.
Yet another question on Enhanced Retro...All linked to our assessment of upgrading from 12.1.3 to 12.2.6

Does anyone know if Enhanced Retro pay will enable us to put a hard limit onto how far back retro could ever go to recalculate payroll periods?

We have the scenario at present with Retropay by Element where, even though we specify the time period we want to retro across, the process can go back further than this – in some cases as far back as the first payment period for the assignment.

This is because retro is finding pre-existing retrospective payments within the period it is processing and these are then retro-ed back to the periods that they were generated for, and so on and so on, until we are in effect, retro-ing the assignment back to its first payment period (up to 13 years worth in the worse cases).

So if we were to switch to Enhanced Retro would the same thing happen? What does Enhanced Retro do when it encounters pre-existing retrospective payments in the period it is retro-ing? Does it only look at the retrospective payments generated by previous Enhanced Retro runs or will it also take into account retrospective payments generated by Retropay by Element? Can Enhanced Retro tell the difference?

The reason for the question is that we are also looking at purging historic Run Results, so ideally we want a buffer of at least a year between the purge year and the max year that retro could go back to.
E.g. if we purge data prior to Apr-2007, we would never want retro running for periods in the tax year 2007-2008 as there is a risk of retro finding differences caused by the purge rather than true differences.
Out initial testing has already found some issues of this type caused by formulae looking back at previous periods, as opposed to balance changes which should be covered by re-initialising balances as part of the purge process.

Any insightful input would be greatly appreciated.

Regards
Barry

#11882 - 15/03/17 02:36 PM Re: Limiting the reach of Enhanced Retro [Re: bcooper]  
Joined: Mar 2005
Posts: 431
paulgos Offline
battle-hardened campaigner
paulgos  Offline
battle-hardened campaigner
****

Joined: Mar 2005
Posts: 431
Gosport
Hi Barry,

This is why we went onto Retro Overlap as this caters for this, in a round about fashion, and will only go back as far as the triggered date of the Retrospective change, and not roll back across over lapping retrospective periods, checking if it needs to recalculating earlier retro pays.

Since being in Retro Overlap we have amost halfed our run timings and 90% of our assignments are only going back 3 months.

The one issue I need to tackle with Oracle is, we have standard link elements for debt management and these elements are never updated, so have a start date as of the effective start of the assignment. When we terminate the assignment it triggers the Recalculation date to be the earliest start date of the element entries, on said assignment, and the recalculation date goes back tens of years.

My suggestion to you would be to flick on Overlap ... simple concurrent process to switch on the Parameter and by the second month of running like this you will see an massive improvement.

I need to share my war stories with Overlap as I have had a few howlers and we have one out standing with performance on one assignment takeing 3 hour for this one record to complete, but oracle have got that now down to 1 hour and 40 mins but we are expecting atleast another hour plus to be taken off this.

Cheers



Paul

Last edited by paulgos; 15/03/17 02:38 PM.
#11883 - 15/03/17 02:49 PM Re: Limiting the reach of Enhanced Retro [Re: bcooper]  
Joined: Mar 2005
Posts: 1,250
delboy Offline
The Grand Daddy
delboy  Offline
The Grand Daddy
*****

Joined: Mar 2005
Posts: 1,250
Somewhere in South of England
We have a similar issue with one of our elements. I'd be interested to hear the outcome and solution.

#11884 - 15/03/17 02:56 PM Re: Limiting the reach of Enhanced Retro [Re: delboy]  
Joined: Mar 2005
Posts: 431
paulgos Offline
battle-hardened campaigner
paulgos  Offline
battle-hardened campaigner
****

Joined: Mar 2005
Posts: 431
Gosport
I haven't raised an SR as yet because I have a couple of SR's already open on Retro and I have another I need to create.

As soon as I do, and get an answer, I will update

#11885 - 15/03/17 04:06 PM Re: Limiting the reach of Enhanced Retro [Re: bcooper]  
Joined: Mar 2005
Posts: 1,285
bcooper Offline
bcooper  Offline


*****

Joined: Mar 2005
Posts: 1,285
Earth, Europe, England, here
Thanks for the informative replies.
Would be interested in the war stories and on the resolution to the Standard Link issue (i think we have a few here too!).

#11886 - 15/03/17 04:30 PM Re: Limiting the reach of Enhanced Retro [Re: bcooper]  
Joined: Mar 2005
Posts: 431
paulgos Offline
battle-hardened campaigner
paulgos  Offline
battle-hardened campaigner
****

Joined: Mar 2005
Posts: 431
Gosport
The war stories so far are we have a performance issue on individuals taking in excess of 30 mins per record (max so far has been 2 hours 40 mins), As mentioned earlier, the worse case we had has now been reduced to 1 hour 40 but we want an even better performance than this.

We had a Retro issue where the process was treating Balance Adjustments as is they started at the start of the record. This caused retrospective increased payments for assignments where we used a balance to determine which level of additional payment to be at. Retro was placing the balance adjustment, in memory, at the assignments start date and then again when it was actually created, pushing the level higher than it should have been.

We have Retro refunding a Tax Relief element when the original assignment is terminated and secondary assignment is createdon. Retro is refunding all the way back to the start because it thinks that the new assignment was active at the same time bcause we are using a _PER_PTD balance, saying if this balance is greater than zero, return a message.

I have another that I have not raised yet as it again is to do with balances within Retro. I have enough open as it is and I am finding Oracle Support especially hard work at present as every SR we raised is having text book questions thrown at us and we you point them down the path of where the issue has come from, they still drive the SRO in the worng way and we end up having to get an Oracle Account manager involved to get the Anaylst removed and get the issue passed to Dev.

All these issues have been around in Enhanced Retro, so don't let this put you off going to Overlap. I think this is actuall the way all clients should go because just for the performance side of it alone, its been a good sent. we was at the point of paying for Icaps to try and keep it within our allowable processing weekend (which actually went into week days too) so for us, we are now well within a weekends running, across the board.

#11895 - 22/03/17 08:49 AM Re: Limiting the reach of Enhanced Retro [Re: bcooper]  
Joined: Mar 2005
Posts: 1,285
bcooper Offline
bcooper  Offline


*****

Joined: Mar 2005
Posts: 1,285
Earth, Europe, England, here
Paul, you will be aware of what we are dealing with here (ESR project) from your time here (even if it was a while ago)...

One of the things we need to take into account is whether Enhanced Retro can differentiate between retro payments generated by Enhanced and those generated by Retro-by-element.
Whilst we could use the Overlap to set a back-stop for Enhanced Retro, what happens if, when it is examining a given pay period, it detects payments generated by a previous historic retropay-by-element process? Will it have to go back to the triggering pay period for those entries?

You can see what i am getting at here? We could easily end up in an avalanche, where one retro period triggers an examination of a previous one, which in turn triggers...etc etc

We are looking at a purge solution to try and reduce the size of our system, so are looking at purging (archiving off) payroll history. We'd like to be in a position whereby we can retain X number of years of pay history and be comfortable knowing that retro will not sneakily try and go back beyond our cut-off date.

Regards
Barry

#11896 - 22/03/17 09:52 AM Re: Limiting the reach of Enhanced Retro [Re: bcooper]  
Joined: Mar 2005
Posts: 431
paulgos Offline
battle-hardened campaigner
paulgos  Offline
battle-hardened campaigner
****

Joined: Mar 2005
Posts: 431
Gosport
Hi Barry,

As you may be aware, where I am at present, we have an equally large number of employees on our payroll, but unlike yourselves, ours is within one business group and a few payrolls. For us, even though we would like to have a cut off date for retrospective recaculations, Overlap has allowed us to get our Retro process to complete within a weekend, reducing run times by more than 50%

As I mentioned in a previous post, we do face issues with the Standard Element links we have, and the fact these element in question are never updated so when someone is terminated, Retro does go back as far as the the hire date of the said employee and if they have been in employement longer that the implementation of Oracle for this client then it goes to the start.

I am going to raise a defect with Oracle on this to see if we can get this changed but in relation to your comment;

"what happens if, when it is examining a given pay period, it detects payments generated by a previous historic retropay-by-element process? Will it have to go back to the triggering pay period for those entries?"

what we have found is it will only go back as far as the Triggered date. So, unless you are terminating an employee, we never found it to go back any further than the triggered date and unlike Retro Enhance, is never moved this Trigger Date even if there was a Retro element in the period it went back to. If it was still doing this it would have been a NO to this solution because this would not have help us at all.

Overlap would be something I would recommend be implemented regardless of what you are aiming to do, as it will help with performance in the short term and stop the rolling back over previous periods of Retro Pay like Enhance does now.

I remember when we went over to Enhance, from the good old standard Retro Pay by Element, and we were sold the story the Enhanced work how I have found Overlap works now but what Oracle failed to relay was they hadn't actually invented the Overlap solution as yet so we have suffered until now.

Switch it on in a Test environment and give it a go. Perfomance in the first month actually increases as it is bedding in all the information is requires so not to keep going back unnecessarely and then from month 2 the performace change is impressive.

What we did to acheive a two month Retro Run was to take a back up the day before we run Retro Pay, which is a week after Retro Notifications was completed, which meant we had a week of updates that we could use in our second Retro run, instead of trying to create a large number of updates.

Cheers


Paul

#11897 - 22/03/17 03:51 PM Re: Limiting the reach of Enhanced Retro [Re: bcooper]  
Joined: Mar 2005
Posts: 1,285
bcooper Offline
bcooper  Offline


*****

Joined: Mar 2005
Posts: 1,285
Earth, Europe, England, here
Awesome reply Sir. Thank you


Moderated by  CT, delboy 

Forum Statistics
Forums48
Topics2,193
Posts11,868
Members1,258
Most Online90
Mar 5th, 2017
Today's Birthdays
No Birthdays
Recent vacancies
Top Posters(All Time)
CT 2,086
bcooper 1,285
delboy 1,250
paulgos 431
SBi 425
Gus 252
pat 249
vkumar 223
October
S M T W T F S
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31
Powered by UBB.threads™ PHP Forum Software 7.6.0
Page Time: 0.025s Queries: 15 (0.006s) Memory: 2.7980 MB (Peak: 2.9899 MB) Zlib disabled. Server Time: 2017-10-21 19:36:35 UTC