The ManageForce Blog

8 Quick Tips to Elevate Your JD Edwards Support

Posted by Grant McIver | 8/29/18 9:38 AM

It seems that no matter what system we’re on for JD Edwards, there are certain things that we check for and enable/disable. For those of us who work with JD Edwards day in and day out these are “no brainers,” also known as processes/best practices we follow that are second nature to us, but less obvious to those less immersed or experienced with the technology.

Sometimes we even question why Oracle hasn’t made them default upon installation/upgrade. For example, for years on the Work with Submitted Jobs screen clients had to publish a default grid or ask users to create their own grid so that jobs were ordered in descending (latest and greatest at the top of the list). A feature that was finally created in a JDE 9.0 release.

Below is my list of top 8 things that you can easily check out.

Address Book Auditing

Looking for a quick way to track changes in the Address Book (including base record, Supplier Master, Customer Master, Who’s Who)? This functionality is available and can be easily enabled by changing the processing options on the Master Business Function (MBF) applications. We just write the “after” image. However, some clients like to see all Address Numbers and, in that case, we recommend doing a SQL insert for the current records and then letting the “after” image take care of the rest. If you’re interested in having those SQL queries then please contact ManageForce.



Screen Shot 2018-08-28 at 8.56.00 AM

AR and AP Master Business Functions

Most of the time, the settings for AR and AP Master Business Functions (P03B0011 / P0400047) remain untouched. It can be easy to miss these things as they aren’t (easily) found on the menus. But on these MBF processing options, it is a good idea to enable the Date Edits options (at least the warning) on both AP and AR. If you don’t enable these options you might start seeing data entry errors whereby you have invoice dates way into the future (e.g. the year 2118). This will have an impact on your Due Dates and payment processing as the Due Date is based on the Invoice Date. These settings are very easy to change and prevent getting bad data into your AP and AR modules.



Furthermore, if you use the Sales module then it may be a good idea to set the Credit Memo Due Date to be “1 - Use Payment Terms” on the P03B0011 options, otherwise, you’ll start seeing 2nd lines on your invoices.


Single Threaded Queues

There are certain batch jobs that need to be run on single threaded queues otherwise you might encounter significant issues. One issue may be table deadlocks but the other (and more serious consequence) could be integrity issues. The AP Payments Update job (R04575) should definitely be set to a single-threaded queue because if a payment group is updated twice concurrently then you could end up with duplicate payments in the G/L. Fixing those duplicates can be very difficult (requiring SQL updates and GL Reposts). Changing the queue on R04575 is something that can be accomplished very easily and quickly, check now to see which queue R04575 is running on your system.

For more information see See Oracle Doc ID 2060820.1.

Menu Tasks

When designing menus, it is very handy to know whether the menu task came with JDE or was created by you (the client). An easy way to begin that separation is to update the Processing Options on P9000. For example, on the Task ID prefix we’ve set the value to be “MF” instead of “JDE” and anytime we see a task that starts with MF, we know that it was created by us. You can be even more fancy and build logic into your Task ID conventions by including module prefixes (e.g. MFAB = ManageForce Address Book). Again, updating the processing options is something that you can do quickly and easily at any time.


Security on R053951/2/3

For any client that uses JDE Time Entry / Payroll, we strongly recommend you check any “41” or “51” batch types at posted status. Why is that a problem? A “41” batch turns into a “7” batch and a “51” batch turns into a “P” batch during posting. When we see those posted “41/51” batches, this tells us the batch actually never made it to the General Ledger. The cause of this is missing security on (R053951 / R053952 / R053953) objects which get called during the posting (R09801) process. For those objects we will typically add them to *PUBLIC so there is never any worry of those objects missing for a user who post payroll batches. Those objects pose no harm and are never run on their own (manually or via the menu), therefore, adding them to *PUBLIC just makes sense. If you happen to notice some 41/51 batches at the posted status then you can check F063951 table in databrowser to see if the missing G/L lines are still available to post and in that case, you can simply post those jobs to the G/L by resetting the batch status.

Security on P0115

Securing the Address Book is an important part of the overall security setup but did you know that there is a bug on the Action Security for Phone Numbers screen? If you have a classic deny all set up whereby the Action Security is denied at *PUBLIC, there is a bypass on screen P0115 that is a failure for action security (users will still be able to enter a record). This issue is mentioned in SAR 7355285 (and is still open with Oracle). To fix this, you need to put an extra security line at *PUBLIC specifically for object P0115. Therefore, your security setup should look something like this:


Screen Shot 2018-08-28 at 8.58.00 AM

Role Chooser Settings

Ever notice a dropdown list for your roles on the top right corner where you sign-out? Most likely this is the result of your Role Chooser record not being up-to-date. To fix this, simply go to P95921 application, choose Form | Enable Role Chooser and click on Save. That’s it, what happens is a value in the table changes from Blank to 0. This change occurred sometime around JDE 9.0 and if you’ve upgraded, you probably didn’t touch this record.



App Query Security on P0092/P00950

You may see this warning/error on applications whenever you try to do an open find (no filters / search parameters). Mostly this is for your protection so that you don’t kill the database with a large open query. But by default, these errors are enabled on the P0092 - User Profiles and P00950 - Security Workbench screens and they can be very annoying when you’re trying to do analysis on users and roles. In our opinion, there is no reason to have these warnings/errors for these two screens.



To correct this, go to application P95950|W98950B (or go through P00950 >> Form >> Set Up Security >> App Query Security), find the records for P0092/P00950, select into each record check the disabled button.

Ready to go conquer your JDE support now?

The reality is that to effectively manage and optimize your JDE technology, you need someone who can give it the time and attention it requires (which is a lot), but many companies simply don’t have the bandwidth.

If you’re struggling to keep your JDE E1 Environment performing at its best, it might be time for a new support solution. At ManageForce we work with companies to find the right management balance for their business. Drop us a line to get started today.



Topics: Oracle, JD Edwards, JD Edwards Upgrade

Written by Grant McIver


Recent Posts