Best Of
One Big Beautiful Bill OT Question for taxes, Oracle R12
In Oracle R12, I understand that there is a new balance called qualified overtime earnings which feeds to box 14? For our OT taxes, we feed the OT elements we want into this qualified balance? I am wondering if the system has any options for organizations that have a 37.5-hour workweek rather than 40 since the bill specifies 40 hours worked. Also, our organization does OT over all paid hours and we also have FLSA overtime too (Based in California). How are other organizations handling their tax processes for the end of year 2026 with similar constraints I mentioned above?
Re: dbms_stats.gather_schema_stats option "no_invalidate => false" does not invalidate all cursor
Hi,
asahide wrote "Based on my understanding of Oracle Database's cursor invalidation mechanism, I believe that specifying no_invalidate => false does not always guarantee the immediate invalidation of all related child cursors under certain conditions."
I'm interested to understand cursor invalidation mechanism better. Does anyone know documents or experiences in which command DBMS_STATS.gather_schema_stats( ownname => null, options => 'GATHER AUTO', no_invalidate => false ) does not invalidate cursors immediate even if underlying table got new statistics?
By the way our application problem was solved by generally using dbms_stats.import_schema_stats on empty tables.
Regards,
Werner
Re: dbms_stats.gather_schema_stats option "no_invalidate => false" does not invalidate all cursor
Hi,
thank you for your comments.
Flushing sql area works. Actually sometimes interactively by DBA. I prefer solution with schema privileges. Not all schema APP_1, .. APP_7 should flush at the same time. I would be able to build a solution for flush.
My main question is why NO_INVALIDATE does not work like documented.
Documentation NO_INVALIDATE:
"If set to FALSE, then the procedure invalidates the dependent cursors immediately."
(https://docs.oracle.com/en/database/oracle/oracle-database/19/arpls/DBMS_STATS.html#GUID-6F9A5D56-9F06-412D-8218-D92CDA07180A).
But this does not work in expected way, neither using gather_schema_stats command nor using set_schema_prefs 'NO_INVALIDATE'.
Couple of tables are involved in import processing. 'GATHER AUTO' really update statistic on these tables. But underlying cursor was not invalidated.
I have taken 'GATHER AUTO' instead of 'GATHER' because I want to omit unnecessary disk reads for couple of tables which are not involved in import processing and for which statistic was not stale.
Another very good working solution is an initial schema stat import s from formerly filled tables and use this statistic at the begin of import processing with empty tables. Always fast with good plan. The disadvantage are special cases of DDL changes between application versions, when exported stats came with different DDL than current application version in which data should be inserted.
Regards,
Werner
Re: FCCS migration
Hi @Fernandus
Migrating from HFM to FCC is not a lift-and-shift exercise. It's an opportunity to rethink your consolidation solution rather than recreate your HFM application in the cloud.
The goal should be to leverage FCC's out-of-the-box capabilities, adopt standard processes where possible, and minimize customizations instead of carrying forward everything from HFM.
One of the first things I recommend is requesting an Oracle Cloud Migration Assessment. Oracle evaluates your existing HFM application, identifies customizations, metadata, calculations, integrations, and reporting requirements, and provides a roadmap for moving to Oracle EPM Cloud. This assessment helps you understand the migration effort, highlights potential challenges early, and lays the foundation for a smoother transition.
Thanks,
AK
ApOK
Re: E1: AP: Average number of days to pay supplier invoices
Hello,
Currently there are no standard inquiries or reports in E1 that measure DPO. You'll want to check with the Quest user group, you'll likely find another user who's put together a workaround involving the F0411/F0413 files to get the calculation and report via BI or OVR or a similar reporting tool.
Thanks
FrankD
Re: Recurring random crashes of PSAPPSRV processes and PIA signout finally
Hi - I would not touch any configuration unless you have enough proof especially recycle count. if you look at the dump it served only 1802 and consumed 30GB virtual memory that does not mean it is a resident memory and no evidence of memory leak.
The moment you change this config parameters then you are impacting entire PeopleSoft system but i strongly feel this issue is specific to one transaction. Changing the parameter will not fix your issue as now it consumed 30GB and crashed and when you limit the process memory it prematurely crash.
i would do below.. identify the crash is on specific page or random.
if its a specific page enable the sql+peopelcode trace and along with trace dump will get some clue.
-Velu
Re: Recurring random crashes of PSAPPSRV processes and PIA signout finally
A 30GB virtual memory footprint indicates a severe memory leak, causing OS-level process termination and user signouts. Setting ProcessRestartMemoryLimit=2000 and lowering the Recycle Count to 1000 prevents this, though a domain restart is required to apply the changes.