Hi,

Retropay(Enhanced) is unable to pickup the changes on the UDT values.

Any idea on that.Is there any configuration missing?

thanks
KP/..

Hi KP,

This has always been a problem. I take it you are simply making a backdated change to a value in a UDT. Retropay relies on triggers that are set by changes to, in the main, the person assignment or element entries. As nothing has changed against the person retropay doesn't know who to re-calculate. With Retropay by Element you could always get round the problem by manually creating an assignment set. Not sure how this would work in Enhanced Retropay.

Delboy

Hmm..........Ya I am wondering how to get this done.I have to raise SR.

I'm sure i've done some work on custom retro triggers for items that are not supported out of the box - i'd have to check through my code archive to be sure.

Will get back to you on this one.

Hi Baz,

Did you happy to come across any custom retro code? I'm on the hunt for some ideas on adding code to the pay_group_event_pkg..

Thanks

Marina

Hi Marina,

Hope this info helps you.

Have a quick look into the Event group ( total compensation --> Basic --> Event group), in the list of tables available for the retro event group, PAY_USER_COLUMN_INSTANCES_F is available,which is the user defined table. I guess by including this in your retro event group, the retro should pickup the changes. i have not tested, please check and confirm.

Cheers
Sudhir

Hi Sudhir,

We have found that when pay_user_column_instances_f and ff_globals is in the event group and there is no code in the pay_group_event_pkg, any chance to a global value or udt causes all employees being returned in the retro report.

Support have told us that we need to add some custom code to the package, and I'm struggling to find any examples of what has been done before. I need to make sure I'm on the right track!

Take care

Marina

Wotcher Lubble

I think we do something of that nature here, but not with UDTs. We have a process which populates/updates PAY_RETRO_ASSIGNMENTS with relevant recalc dates based on changes to things like Grade rate.

With anything like this, the trick is to be able to establish a list of assignments that make use of the entity that has had a change of some kind. In the case of stuff to do with grades, that's fairly straightforward - the grade_id is on the assignment of course.

For UDTs, however, the water becomes a whole lot muddier. For one thing, it's highly likely that you will have many different UDT structures defined which rely on completely different items of information to determine the end result cell value. The issue is further complicated by the number of rows/columns that might be defined. If that wasn't complicated enough for you, you have to add in the fact that ultimately, the reference row/column values that are used to seek a particular cell value might themselves be derived in some way - at the end of the day, UDTs are accessed by formulas (via the get_table_value function of course) of which there may be many, and themselves all different. In short, your custom code would have to pre-empt what cell value the formula would have returned from the relevant UDT, in the case of each assignment

There, have I cheered you up now?

Phew!!! That was a mouthful.

Hello CT,

Slightly off topic, but in relation to the Retro against Grade Points issue you mentioned (I realise you already have a working solution), an alternative approach is to use Grade Ladders, through Total Compensation Setup Wizard. This results in the creation of Pay Proposals and associated element entries whenever an employee's grade point is changed, or the associated grade point values are changed. Hence, you basic pay formula is MUCH simpler, and the standard retro events and proration functionality also operates.

Doesn't help with changes to UDT's though.

Regards,

Peter.