Best Of
Re: Retroactive Pay on Subsequent Prior Paychecks
I think our September meeting might talk about Payroll Year-End Insights and / or OBBBA. We may discuss Retro Pay in October or November..
Re: Retroactive Pay on Subsequent Prior Paychecks
Hi,
It shouldn't be an issue. I think if you run through this example and calculate the retro, you'll see the March paycheck in the retro calc results.
Write back if you experience issues and we can run through your setup.
Also - retro pay is a topic we would love to discuss at a future Quest Payroll for North America SIG meeting. Feel free to message me if you're interested in that!
Link to the group:
Re: lsass.exe (Local Security Authority Process) runs high CPU on all of my PeopleSoft servers
Hi - Do you have Kerberos /LDAP or NTLM? LSASS will run when your services are running with domain user so in non prod we run multiple domains so that runs heavily. Usually it will be mis configuration.
Quick test would be shutdown all peopelsoft domains and see if you still see the spike to isolate peopelsoft is causing or native windows have issues.
Also check your event viewer to see any repeated errors which will show if any issues.
-Velu
Re: Peformance after full Pkg deploy
Yes, this is expected after a full package as the serialized specs need to be regenerated. You can consider "Automatic Pre-Generation of Serialized Objects" , if not setup already.
Re: Segmentation due to TAX_LOCATION_CD change mid-period sets "OK to Pay" = N on Additional Pay line
Hi - this isn't something I would expect. Additional Pay is kind of weird on a mid-period change, but I wouldn't expect one segment of it to be unchecked ok to pay…I vote create a SR
Re: Segmentation due to TAX_LOCATION_CD change mid-period sets "OK to Pay" = N on Additional Pay line
PeopleSoft Payroll has been around for a long time, and if a split occurs like in your scenario, then by default the row is entered through the cobols being processed so the user can see if the system does it right to your expectations. However, the Ok to Pay is turned off to require a review to make sure all is right before confirming.
Do you have a step in your Payroll Process by which you run a report and ensure all of the Ok to Pay unchecked is correct before you Final Calc and Confirm? If you do not, it is a common practice especially in cases where a triggered event creates a non-common/expected row.
This is just my thoughts, so of course I welcome fellow members to chime in.
David L
DHLuding
Re: Handling Garnishments Based on Net Wages in PeopleSoft
That helped greatly. Thanks Nicole!
Re: unable to save automatic package discovery server parameter in Server Manager Miscellaneous section
Hello,
I recommend you to raise an SR on component Server Manager with Oracle Global Support to help you on this issue.
It needs to be triaged from a Server Manager point of view why this is reverted, you would need to provide the e1agent.log with finest logging Enterprise Server and Server Manager Console logs.
Sincere regards
Johan
Re: "/ by zero" Exception When Run Any Query in SQL Developer
Hi Bruno,
Thank you for your post.
as for your questions:
yes, with sqlplus it's OK.
I've reinstalled sqldeveloper but still the same issue.
Database version is 19.27
Yes, I'll change profile username :)
BR,
Re: too many parse errors
Thanks for the feedback - that's interesting to know.
It prompted me to revisit the example I published a few years ago in this note.
With my example error I didn't find the text in v$sqltext, but I did find part of it in v$sqlstats. My initial guess about the difference is that your statement is syntactically correct, so the whole text got into x$kglob and was flagged for exposure in v$sqltext before the object validity was checked, but my statement was syntactically incorrect so the only bit that got into x$kglob was the text up to the syntax error and the code to flag it for exposure in v$sqltext was bypassed.
It's also interesting that my test showed the whole statement in the alert log for 12.2, 18.1 and 19.11, but your alert log in 19.28 didn't show the statement. Possibly a change in behaviour, possibly related again to the nature of the error.
Regards
Jonathan Lewis