Best Of
Re: PRP for Secure 2.0 Section 603 - ETA
PriyanshuG, we are still trying to apply all our tax update patches… I guess you didn't have the compiler error for the COBOL programs.
Wendy Ho
Re: Database set up as Non-Unicode; "hidden" characters are being saved to Voucher DISTRIB_LINE descrs
Debbie - it depends on where you would like to make the change.. lets say if you are ok storing the data as is in DB then you can check if they accept UTF-8 and add below code in SQR.
open output $file_name as 1 for-writing record=32000
encoding='UTF-8'
If vendor only supports ASCII
! Replace non-breaking space (0xA0) with normal space
let $descr = replace($descr, x'00A0'x, ' ') ! Replace smart quotes with regular quotes
let $descr = replace($descr, x'201C'x, '"')
let $descr = replace($descr, x'201D'x, '"') ! Replace en dash with regular dash
let $descr = replace($descr, x'2013'x, '-')
If you want to strip the characters at peoplecode itself then we can write there as well.. let me know which one you like?
-Velu
Re: Please, make Knowledge Base documents more friendly for external bookmarking tools
Hi Margi,
"Known Issues" mentions other problems than mine. My suggestion is to improve metadata of Knowlegde Base documents by adding basic thins like "Title" and "KB" number to them. I'm not sure if you noticed but now they do not even have unique titles - so when bookmarked by the browser they all are "Knowledge Articles":
So bookmarking - which is the only current replacement for "Favorites" - is very difficult. One has to manually change bookmark name to something meaningfull. The other issue: shortening longer titles - makes this task even harder because full title is not available anywhere in the doc.
mickyw
Re: Please, make Knowledge Base documents more friendly for external bookmarking tools
Hearing our frustration, adding the information in our support portal, . . all is not a solution it's only like giving some painkiller to a patient , it won't help and it's really not helping?! how long has it been since this failed disaster migration?! how long? how long we're facing issues that's affecting our business?? how long are we affected with customers?!!
How long?!!!
I even can't rely on the very basic function which is searching?!!
Searching itself is a big mess? is a huge failure? I remember very well when I used to search through old classic MOS and how I used to get the results? the relevant to my search ? to what I'm typing? to the keywords I'm using?!! Nothing is working the same anymore!!
Please at lease if really Oracle is listening or caring about its partners is to roll back the migration !!! Or you don't have a roll back plan in the very first place??!! Oracle the big database company selling migration services to all its worlwide customers doesn't have a roll back plan?!!!
Is is this possible or acceptable anyway?! Or again it's us , your partners or even customers you don't care about?!!
I really can't get it at all!! There is no single explanation other than that really this was Oracle intention in the first place!!!
Re: 27 vs 26 bi-weekly paychecks in CY 2026
Hi - I don't recall ever doing anything special. I searched through MOSC and there were some documents mentioned (links are updated because the old links won't work anymore):
Benefits Administration Annual Amounts not Correct for 27 Pay Periods
EPY: Garnishment exemption amounts can be incorrect with 27/53 pay periods in year
EPY: Bi-Weekly Employees Compensation Reduced Due to 27 Payroll Periods
EPY: How do 27 or 53 Annual Pay Periods Effect the Tax Calculation for US Taxes
EPY: Setting Up 27 Pay Periods for Bi-weekly Pay Using PS_FREQUENCY_TBL
EPY: Garnishment Flat Amount Calculation Can Differ when 27 or 53 Pay Periods
Re: 27 vs 26 bi-weekly paychecks in CY 2026
Our agency went ahead and began testing payrolls, as we did not want employee pay to be reduced. The pay period 12/19/25-1/1/26 calculated gross the same amount in test, not reduced. We were thinking ours might be counting paycheck dates since we will have 27 pay periods but still only 26 paychecks. Our payroll staff also intends to run every payroll until they can get to 12/18/26-12/31/26…I believe they wanted to confirm insurance. We were thinking we were in situation (3) on the following article (included in Nicole's response above) and therefore might have had to plan to customize the PSPPYRUN COBOL:
Our staff is somewhere around May 2026 of their testing and has not yet reached the final pay period of 2026. We are optimistic since 12/19/25-1/1/26 looked okay.
Re: Standby database MRP problem WAIT_FOR_GAP
Yes, I understand now. Thanks I will try to fix the problem with unregister.
LunaTaxi
Re: Patch 38764390: SECURE 2.0 SECTION 603 ROTH CATCH-UP PATCH 2 - PEOPLECODE FOR ROTH THRESHOLD CHECKBO
Thank you very much for the information. We'll request to download all 5 patches.
Sheetal
Re: Patch 38764390: SECURE 2.0 SECTION 603 ROTH CATCH-UP PATCH 2 - PEOPLECODE FOR ROTH THRESHOLD CHECKBO
Hi Sheetal,
As stated in the initial announcement on this thread, PRP 38764390 was posted on December 19. It included patch 38750590.
Regards,
Joyce
