So, it’s finally time to upgrade your JD Edwards solution to 9.2. Staying up to date on the latest and greatest version is a smart move; however, upgrades can be overwhelming. It’s difficult to predict potential obstacles prior to implementation, so there’s naturally a fear of the JDE upgrade process. Just like your previous upgrades, you want to be armed with information so that everything goes as smooth as possible.
Here are a few insights to help you minimize wasted effort and prevent that "I wish I knew that then" feeling later:
Evaluate Your JDE Features
New features like UX One, One View Reporting, 64-bit computing, EnterpriseOne Search, and even some other features that have been around for a while (like E1 Pages & CafeOne) should be evaluated to see if they can and should be implemented as part of the upgrade.
- Take a hard look at UX One to see if any of the content would be beneficial to your end users.
- Implement E1 Pages, if you haven't done so already. The latest 9.2 E1 Pages style sheets and icons are visually stunning, and your users will thank you for giving them an easier system navigation option. See sample E1 Page (using latest CSS).
- For other User Defined Objects (UDOs), publish some grid formats as default for some high impacting screens like Voucher Entry or Journal Entry in order to get rid of those pesky "Basic" grids.
- Say goodbye to User ID and password restrictions — With 9.2, you can enable Long User ID functionality, giving you a max of 254 characters for the User ID and 40 characters limitation for passwords. This is especially important if you're looking to integrate a Single Sign-On or LDAP authentication type (so you can integrate all User IDs or go beyond the 10 character limitation)
- Heads up: As soon as you enable the Long User ID functionality, you cannot go back — you must use P98LPSEC instead of P98OWSEC, and the long User ID functionality is permanent. With this functionality you'll also be required to link a Short User ID with the Long User ID (an initial reconciliation with an on-going part of your User ID creation process).
- Overall, if you're upgrading to 9.2, you should consider enabling the Long User ID / Password features so that you don't need to have a separate project for it later on.
Additionally, we recommend you have a limited scope for publishing Personal Forms and CafeOne. These features do require some good end user training (if you were to open up the functionality to all users), but you can also select a few applications and deploy the form updates at *PUBLIC. Publishing a CafeOne form for Payee Control (P0450) and a Personal Form for something like Work Order Entry (P17714) are two great examples that can make the data entry/review much quicker for end users.
The EnterpriseOne Search, although very nifty, can probably be an enhancement that you pursue as a post go-live project. Depending on your resource availability, budget, and ability to execute vision, putting in the EnterpriseOne Search at go-live would be "going the full distance" in terms of enhancing usability.
Overall, you'd like to utilize all of the cool features from 9.2 but you need to have a manageable scope. The above recommendations should help in getting maximum utilization with a low cost/effort.
Avoid Change Fatigue
Doing any sort of upgrade presents a prime opportunity to make some high-impact changes that you wouldn't normally be able to do during regular business operations. Hardware changes, security and menu redesigns, and data conversion fixes are all great examples of things you should take advantage of during this period. But while you want to get the most bang for your buck, you can't change the entire platform at once for the end user. When determining the ultimate scope of the upgrade, ask yourself these questions:
- Is this change urgent or is this a "nice to have?"
- If I don't do this change now, will I ever have the opportunity to do this?
- How will the benefits of this change impact the perception of success for the project?
- Will the effort/difficulty for this change pose a risk to my go-live target dates?
- Just like anything in life, everything is a balance, so choose wisely in determining how much change you're feasibly going to put in for an upgrade project.
Look Out for 9.2 Upgrade "Gotchas"
Whether you're upgrading from XE, 9.0 or another release, there are certain changes that may have happened along the way which impact 9.2, but are not necessarily part of the installation of 9.2 or upgrade instructions. Here are a few to keep in mind:
Next Numbers
As part of data conversion, you'll definitely need the most recent values from your legacy system. However, you can't just copy over the F0002, F00021, and F00022 tables and leave them as is. Over the releases, JDE has added new system codes and new tables that require unique keys. Therefore, after you've transferred the next number data from your existing release to 9.2, be sure to insert records from pristine environment that are net new as well as perform a comparison between pristine and production for the F0002 table. You may need to manually update some of the next number columns for the already existing system codes in P0002. Performing this reconciliation will ensure that you're up to 9.2 standards as well as avoid any potential errors due to missing unique key records.
Check Printing
If you print checks from JDE then you've most likely customized the R04572 object in some way. This will require you to do some retrofitting and in doing so you need to make sure that the code is fully up-to-date; otherwise, you may discover an issue related to check skipping. The issue can be very hard to discover but works like this:
You perform the "Write" for your checks and see that the next number for the bank account is, for example, 10031 with 30 checks in the payment group. When you open the actual PDF for the checks you notice that the checks are actually numbered between 10061-10090 when you were expecting them to be numbered between 10031-10060.
The actual issue can be traced to SAR 8782932 so make sure your R04572 object includes the code for this SAR. Doing the retrofit may cause you to painstakingly update the code manually or cause you to do all the sensitive layout changes, but it still needs to be done and it's much easier to do that exercise during the upgrade as opposed to doing it post go-live. Overall, for an object like check print, you should always be up to date with the latest code so it is supportable by Oracle.
View CSV Reports
You've installed 9.2 and are midway through unit testing and your users started identifying that their CSV reports look funny. The problem they see is that all of the data is in one column instead of their respective columns. At first glance you'll think it's a Windows or MS Excel setting that needs to be adjusted but actually there is an encoding setting that needs to be updated in JDE.
To fix this, go to Unicode Flat File Encoding Configuration Application (P93081) in the FAT client and enter the record for CP1252 encoding at *PUBLIC for *ALL environment and *DEFAULT versions with an Active status. The encoding has more impact than just viewing CSV files so some JDE clients may choose to add individual batch applications into the Program ID field (instead of *DEFAULT).
For more information, see Oracle Support Doc ID 1985620.1.
Bottom line, it is incredibly beneficial to educate yourself on the potential JDE 9.2 upgrade obstacles you could face prior to performing an upgrade to your critical JD Edwards ERP system. We hope that these few tips and tricks help you get started on a smooth transition to JDE 9.2!
As a certified JD Edwards Solution Provider, we're well-versed in managing JDE updates. Our team of experts can easily transition your team onto the latest version, getting you up to speed to reap the benefits of the new JD Edwards as soon as possible.
Download our complimentary guide to get started on your JD Edwards upgrade today!
Or, if you're looking to get your JD Edwards applications into the cloud, download our complimentary eBook as a guide to help to get started.
