Developer Best Practices for making JDE code modifications

Thanks to all that willing to help me with this question.
I have searched JDEList for what I am asking, and I have found some information. So far, however, I have not been able to find any information on what is "Best Practice" for developing in JDE.
My company is very new to JDE, so we are still in an early learning process. We are currently running EnterpriseOne 9.2.0.

Here is my question:

Using the JDE invoicing proram, R42565, as an example, if I needed to add logic to the UBE at the base level, would it be best practice to add code to R42565 or create a clone/copy, say, R5542565 and make the change there?
What is the best practice for modifying JDE objects such as applications, UBEs, business functions, etc.?
Should I change base JDE code or should I always clone/copy?
What is the best way to handle this for the long haul with regard to ESUs, system upgrades, maintenance, etc.?

Thanks again to anyone willing to discuss this with me. Your time and help is much appreciated.


Legendary Poster
Your going to get a lot of different opinions on this. Some will tell you their opinion is the best practice but that doesn't mean it is the universally accepted "best practice". For example, I have a very strong opinion on the matter and I would consider it best practice but I am sure there are those that will 100% disagree with me.

First off. Have a general rule but don't make it an absolute, be willing to be flexible. Take each thing on a case-by-case basis.

In my opinion, key word "opinion". It is MUCH, MUCH better to modify the pristine object. This is especially true with Interactive applications (APPLs) and Business Functions (BSFNs). Kind of the same with UBEs but too a much lesser extent. In fact in your specific example this would be a case where I would break with our general "rule" of modifying the pristine object and would probably copy and modify. I say this because our R42565 is an absolute mess. We tried to make mods using version overrides and its a nightmare. If I could do it over again, I would copy the pristine object to multiple custom objects, each with its own modifications.

However we have made extensive modifications to the Sales Order module (B4200310/B4200311 and P42101/P4210), Purchase Orders / Receiving and many other modules and objects and I would absolutely do it all over again - a copy and mod in these situations would have bought us nothing and actually would have made pretty much every aspect of the modification more problematic.

Having said all that, if you do modify a pristine object there is certainly things you can mod, things you probably shouldn't mod and things you absolutely should never mod.


VIP Member
my $.02.

Copying objects is a bad idea. There is no mechanism to "rebase" your copy on the original. Once you copy it, you are on your own. You will have to try and keep up the code manually in your copy with an new ESU's.

You either mod the stock object and keep it well documented or attempt to extend the stock object. In case of the R42565, if it's just for printing purposes and you need additional data in it, i would create a new table. Insert data into that table from the R42565 and then call a ube interconnect to process the stock data and then fetch any additional data.

good luck

David Robertson

Reputable Poster
Way back in the good old RPGII days of JDE A4 and A5... oh never mind.

Basically, so long as you have a Pristine environment for reference, there's very little reason to clone the object (any more), unless you deliberately need to separate it from the original process. Document your changes well, mark your code changes well, comment out old rather than delete, all more helpful practices than cloning.


Legendary Poster

Here's my take on it:

Rule 1: If its just a minor change then don't even consider making a custom copy/clone. Just document and move on.

Rule 2: If the Application/UBE is significantly complex and/or performs critical updates to the database then do not make a custom copy of the application. Changes should instead be applied to the standard object (base template if a UBE). Changes should be documented, and re-applied if needed after an upgrade.

Rule 3: If the object in question is referenced by other applications (Row/Form Exits or the object is a BSFN) then do not make a custom copy - its futile to do so unless you in turn customize all of the calling applications . . .

Rule 4: If its a relatively simple application/UBE that doesn't perform critical or complex database updates and you really don't want to have to reapply changes after an update then make your 55 copy (we rarely do this).

Rule 5: Don't perform MAJOR changes to a standard JDE object where in addition to screen or report layout changes you are making substantial additions or revisions to the underlying code. If the changes are that large either make a custom (55) copy of the object and do the changes there -or- create a new (55) object that does what you need without all the baggage of the standard JDE object. Preferably the latter. This rule trumps rules 2 and 3.

Your change to R42565 probably falls under my Rules #1 and #2.

Why do things the copy/clone way?

1. Custom copies of applications do not inherit bug fixes and design changes from the original when a ESU or Update is applied. Consider which is easier, re-applying the changes you know about and have documented . . . or trying to identify what JDE did to the original and applying all of their changes to your copy?

2. Some applications / UBEs have hard-coded connections from other applications / UBEs. What are you going to do when you need to change a SO Master BSFN or P4210 itself? Each may be referenced from multiple sources.


Legendary Poster
FYI in our shop (two JDE IT people) there are 244 standard E1 Objects that we've "touched" in some manner.
The majority of these customizations are minor in nature (add a field to a grid or report, add more row exits to other apps, etc). There's some that are mid-level in complexity and scope (P4210 and related objects comes to mind). Past that everything else we've done as 55 (net new) objects - about 800 of those.

It DOES make upgrades a long process - adding at least 3 months to the upgrade process to reevaluate, reapply, and test every change to a standard object. But we find it worthwhile in how we've streamlined business processes with these changes.

I DON'T believe copying/cloning objects protects you during an upgrade. Changes to tables, data structures, business functions, etc can break a cloned app/ube that didn't get the changes Oracle made to the standard object to accommodate changes in other objects.

My 2 cents.


Reputable Poster
I am with Larry on this one. regarding commercial documents, there is a way to keep the modifications to standard objects to a minimum

Example: changes to invoice/order acknowkedgement print are often dictated by customers or different companies using same JDE instance (multi-company, global, rollouts) It is very often changes to the layout, printing additional information on the document etc.. Obviously, if it is a layout change only, then this could be done in BIP. but adding additional information or driving some information dynamically rather than from processing options or the template is a different beast

I favor the approach where
1. We use standard R42565 but set the processing options to populate EDI tables for invoices / order ack + Make one slight modification to call a secondary UBE to perform the actual printout

2. Create separate UBE for every major requirement. This secondary UBE is triggered from R42565, reads the EDI tables and produces the document. All custom logic will reside in this UBE

This way we can keep the modifications to standard R42565 to a minimium and put all custom logic into the print-UBEs (55-objects)

And same approach for purchase order print.. R43500 -> EDI tables -> Localized UBEs to print the purchase order



Legendary Poster
You are on 9.2 and my understanding of 9.2 is upgrades are far simpler than earlier releases due to the way Oracle merge the newer objects on upgrade. i.e only the CHANGED objects from the last release.
So if P4210 in 9.3 is no different to the P4210 in 9.2, you won't get a new P4210 object

This is such a hot topic I agree with everyone and almost everyone is saying different things :)

Whatever you do......most important thing is to have good modification marks in your code.
The OMW project, the Change Request number, a link to the documentation somehow (I paste in URLs and names of where it's held)

If it's a small change to a base E1 object, just modify it.

I've touched 12 APPL objects, 5 UBEs and 4 BSFNs in my 5 years here in my job.

I also keep a track of ALL objects I've cloned (if the change is BIG). As ESUs to the master object maybe required in my clone. I can add the PAR file here for that if anyone wants that, if needed.
Last edited:


Well Known Member
I believe those earlier have laid out the reasons for deciding to modify or clone and typically I am in favor of making the modification. In addition to good modification marks as mentioned earlier it is important to be "surgical" with your modifications. Try to use business functions or custom UBEs when possible to encapsulate your changes and custom functionality. That way there is only some added variables and a function or UBE call to document and re-apply in the native JDE object when it does come time to upgrade. Plus it is easier to see and understand what was changed in my opinion.


Legendary Poster

What the other contributors have said makes sense. Depending on the requirement, you can:

1) modify the standard object to accomplish what you need - when upgrading all mods need to re-applied
2) add a small modification to the standard object (APPL, UBE, BSFN, NER etc) to call a custom (55) object under specific circumstances (and at the right spot in the standard processing) and add the you custom processing to the 55 object - smaller re-application of mods when upgrading

I'll share a (short) story to emphasize the cloning issues raised by others:

Firstly, I need to point out that I was not involved nor consulted nor aware about this. It was done by a PL/SQL consultant who had to learn JDE to accomplish the task. I was called on to attempt to "fix" things when it started to break years later.

We needed to import and allocate receipting from a custom system to JDE - in a non-standard way. Standard UBEs were cloned and modified. These were never "reset" to the base standard objects. During an upgrade, we tried, but could not "reset" the objects as the processing had changed too much during the intervening years. Now we are stuck with the old processing, which doesn't process the same way it used to (when it was first done). It is also highly likely that some of the old objects will soon be made obsolete and be removed - breaking the processing permanently, requiring a complete rebuild.