copying jde objects

When is it a good idea to copy an original JDE object and modifying it to suit your requirement Vs creating a fresh new one when developing a customised one.

Eg a user wants a UBE to do more than R47071 does.You copy R47071 to create R5647071 and add in extra functionality.

You could also write a barn new UBE .
When is it a good idea to write afresh Vs copy?
Any guidelines ,thoughts idead ?thanks

OW ERP8.0 SP 23 HP UX Oracle 9i

I don't think there is a simple answer or hard and fast rules. There are
a couple of things I think about when deciding whether to modify or
copy.



1. Will the base functionality ever need to be executed on its own?
If this is

Re: RE: copying jde objects

Hi Ellen,
Your reply was truncated -could you please re reply?
Thank you for your feedback.I sincerely appreciate it!
Thanks

Re: RE: copying jde objects

I would like to re-awaken this thread. We are having this discussion in our department and I would be interested in people's opinion. I do not want to share my opinions at this time so as not to bias the conversation but I will be more then happy to down the road. Thanks in advance.

OK CRF,

You are asking what is the cutoff point for number of customizations in a standard JDE object past which you should make a customized copy . . .

You'll encounter a variety of opinions on this. Here's my take on it:

Rule 1: If its just a minor change then don't even consider making a custom copy. 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.


There's my opinion on the subject.

It all depends on the requirements and what you will gain or lose. My main rule is never mod a JDE base program but do like you said and copy it to a R56***. But if the JDE UBE is complex and the requirements of changes are minimal and you don't change the main processing or flow of the UBE then I would copy and mod the new one. You just have to do a little homework on it. How much time/$ would it cost to copy the mod versus a new one and what is the cost of the mod on an ongoing basis. Some upgrades won't impact your mods or your copied UBES others that may update files you may want to redo the mods. It all depends. I don't have a real formula that I can give you but it is something you are going to have to think about. Do you have a change management committee, if so they may help or even set guidelines. For the sake of SOX we have a ChgMgt Committee but us developers really set what is our "standards". Also you would want to present to the user a choice if it cost much more to do it from scratch. Good luck and I hope I helped at least a little ~Angelis~

I think Larry's set of rules pretty much sums it up for me, and Angelis makes some valid points too.

Another method I would suggest is to use NER's where ever possible in this situation. It helps to minimise the amount of customisation going into the standard object. Write the custom code in an NER and then all you need is a single line call in the standard object to call your custom NER. It makes re-application after an upgrade much simpler.

Thanks for the input guys. I agree with the set of rules listed. It really helped to back up my views in our discussions. Thanks again.