Anyone been testing or implemented RUP4 for next year end. Got any war stories or issues.

Delboy

Come on Guys,

Surely I can't be the only one testing RUP4??

Delboy

Sorry Del...
Yes we have been testing RUP4.
Think main issue we have encountered have been linked to the re-application of existing customisations (RUP4 has made some of our mods and tweaks redundant so an extensive round of regression testing has been taking place).

Hand on heart i cannot say if we have hit any genuine issues with it yet - mainly because i am not directly involved with the testing of it.

I will ask around on site.

Regards

Hi Baz,

As a heads up. If you are running enhanced retropay........beware.

We implemented enhanced retropay in sept due to appalling run times in retropay by element. We managed to get combined run time of 24 hours (we ran the process twice each month against different element sets) to 1.5 hours. With RUP4 this increased to 8 hours. The selling point of enhanced retropay was that it did not recalculate back to the start of time each month, considerably improving performance. It seems that the new version in RUP4 has reverted back to its old ways.

We currently have a SR with Oracle, so watch this space.

Regards,

Delboy

Ah deep joy. I will pass on that nugget to the testing team

cheers

Baz

We have completed RUP4 testing and I don't see much issues now. Except BACS output file changes.


cheers
KP/..

Hi KP,

How has the file changed.

Cheers,

Delboy

Guessing this is the one where the *.a01 file is no longer produced

Hi Delboy,

After RUP4, When BACS process is completed, it will not genreate the p<req_id>.a01 file and it is creating the o<req_id>.out

To generate the p<req_id>.a01 file, we have set STD_FILE_NAME rule to 'Y' into' pay_aciton_paramters' table.Then BACS generates the p<req_id>.a01 as required and also o<req_id>.out file too.

Hope this help you


cheers
kp/..

Hi Delboy,

We have the same problem,will you be kind enough to share the SR number.

Apologies made a mistake in previous e-mail.

Thanks
Alero

We hit some strange issue after RUP4, Payslip Generation - Selfservice process is hanging/strucks up and not finishing at all.

This seems to be a major performance issue.

Issue got resolved after restarting the server.

Surprisingly RUP4 went ok for us!

Gary

You can't be running payroll and using enhanced retropay then.

Delboy

We are not using enhanced retro, but are using payroll. I think we have had a few performance issues but these have been resolved.

I've just got my grubby mits on RUP7 for 11i - was planning to trash my 11i vision instance over easter with it.

Eh? Where did RUP7 come from if we are only up to RUP4?

Delboy

Did you mean RUP7 on Release 12?

Delboy

Also experiencing some local difficulties here, attributable to RUP4 by all accounts - something has generated spurious potential life events with occurred dates (LF_EVT_OCRD_DT) way, way, way into the future - and then promptly processed them. It is causing us some serious grief here, not the least of which reason is because we can't seem to void or back them out via any API I know of. Anyone else found this, and gotten round it?

No, definently said Rup7 on the packet (download).
Patch number (for Windows 32bit) is 6241631

Aaah, that's the ATG patch. I think we are on RUP6.

Delboy

Yes, sorry (blush blush)

I'll get my coat

Hi All

We are racing the clock trying to finish the install of the RUP4 patches and have hit an issue with hrglobal.

Error is ORA-20001: The name 'LUMP_SUM_E_PAYMENTS_ASG_RUN' is already used by a User Entity

Anyone seen this before?
We have an SR open but Easter and large amounts of chocolate is slowing the resolution.

Oracle Support came through with a data fix. Fix applied and patch completed.

DELETE FROM ff_compiled_info_f
WHERE formula_id IN
(SELECT fdu.formula_id
FROM ff_fdi_usages_f fdu
WHERE fdu.item_name LIKE 'LUMP_SUM_E_PAYMENTS%');
DELETE FROM ff_fdi_usages_f WHERE item_name LIKE 'LUMP_SUM_E_PAYMENTS%';
DELETE FROM ff_database_items WHERE user_name LIKE 'LUMP_SUM_E_PAYMENTS%';
DELETE FROM ff_user_entities WHERE user_entity_name LIKE 'LUMP_SUM_E_PAYMENTS%';