Changes to JDE objects

t_a_pierce

Active Member
This is a controversial one! It's an unwritten rule that developers must not
under any circumstances make changes to JDE objects. There are pros and cons
either way, but I'm now leaning towards the opinion that for relatively
minor alterations changing the JDE object is acceptable.

Does anyone have a very good reason why we SHOULDN'T change JDE objects? I'd
be interested in hearing as many opinions as poss.

Thanks,

Tim.
 
No1 Opinion is that the 1st update package you get from JDE will wipe out
any changes you have done. So you will have to do them over again and again.

Bob Bushley
Haskel International
Burbank, Ca. U.S.A.

JDE XE(B7333)ver SP13
AS400 ver V4R5
DB2
Windows 2000
 
Hi Tim,
At first, what is your OneWorld release level?
I know a very good reason why do not change JDE objects (but tell the truth, we do it very frequently).

Starting with B7332, ESUs replaced the old method "Paper Fixes" error correction method, so you could have problems with custom mods not only after an upgrade but after an ESU install too.

After an upgrade/ESU, you should revise the changed objects, re-evalute the situations and re-apply the custom mods. Starting with ESUs, this happens much more frequently.

We are managing more releases on more sites. We had bad experiences with Upgrade/ESU with merge, so to be on the safe side we always do it in replace mode. ESUs makes a lot of job for us to revise/retrofit our custom mods. Believe me, I know it very well :))

We can mot avoid JDE object changes because there are several Hungarian issues in our country and several acceptable needs of our partners too.

I couln't be enough wise in this issue.

Zoltán

B7332 SP11, ESU 4116422, Intel NT4, SQL 7 SP1
(working with B7321, B7331, XE too)
 
Tim,

One of the main problems I see in modifying JDE objects is the cumbersome routine of reapplying the mods every time there is an ESU applied on the object. This obviously would involve time and resources based on the complexity of the mod. I have seen a lot of JDE objects being modified in my short experience as a JDE Developer, in spite of all these hassles, basically because of the requirement. So long as there is proper documentation on the mods and you have a knowledgeable resource on hand, I guess the risk's worth taking.

Just an opinion
Yathindra

This is a controversial one! It's an unwritten rule that developers must not
under any circumstances make changes to JDE objects. There are pros and cons
either way, but I'm now leaning towards the opinion that for relatively
minor alterations changing the JDE object is acceptable.

Does anyone have a very good reason why we SHOULDN'T change JDE objects? I'd
be interested in hearing as many opinions as poss.

Thanks,

Tim.



--------------------------
 
Tim,

One of the main problems I see in modifying JDE objects is the cumbersome routine of reapplying the mods every time there is an ESU applied on the object. This obviously would involve time and resources based on the complexity of the mod. I have seen a lot of JDE objects being modified in my short experience as a JDE Developer, in spite of all these hassles, basically because of the requirement. So long as there is proper documentation on the mods and you have a knowledgeable resource on hand, I guess the risk's worth taking.

Just an opinion
Yathindra


This is a controversial one! It's an unwritten rule that developers must not
under any circumstances make changes to JDE objects. There are pros and cons
either way, but I'm now leaning towards the opinion that for relatively
minor alterations changing the JDE object is acceptable.

Does anyone have a very good reason why we SHOULDN'T change JDE objects? I'd
be interested in hearing as many opinions as poss.

Thanks,

Tim.



--------------------------
 
Thanks for the reply Zoltan. We are currently on B7332 looking to 'flick the
switch' over to Xe next week.

I see what you mean but it works both ways. If you make a copy of a JDE
object and then a required ESU appears for the original JDE object, you will
probably have to apply it to your copy ...and I'm not even sure if you can
do that!

The compromise I've come up with (hasn't been agreed yet ;-)) is that small
or cosmetic changes can be made to JDE objects, but larger or procedural
changes require a copy to be made.

I think either way there is a lot of work/documentation involved, not that
I'm complaining, it keeps me in a job!

Tim.
 
Tim,

could you define what you meant by "JDE Objects"?
Its apparent to me from the posts that some people are thinking only of Business Function objects while others are thinking all types of objects (APPL, UBE, etc).

Regardless I don't see how you can avoid modifying objects. You try to minimize doing so as much as possible because JDE will step all over those changes when an ESU is applied. Some changes are highly desirable to improve user processes / reduce cost / improve accuracy, some are mandated in the form of printed documents, some are done for political reasons, and lastly some are done to fix code that JDE can't seem to fix in a timely manner.

The key is to document, document, document all changes.

FWIW,

Larry Jones
[email protected]
OneWorld B733.1, SP 11.3
HPUX 11, Oracle SE 8.1.6
SandBox: OneWorld XE SP15
 
Hi Tim,

I agree with you. Managing custom mods/developments is a big pain in OneWorld but I suppose, it is also a problematical thing in all complex system. Imagine, how could it be possible to do it with success to preserve all customizations on original objects?

I am affraid, there is no way to apply ESUs against copied objects.

On the other hand, have you ever heard about:
1.) Country Server Methodology
2.) Visual ER Compare and ESU handling enhancements (rolled back from XE to B7332).

Regards,
Zoltán

B7332 SP11, ESU 4116422, Intel NT4, SQL 7 SP1
(working with B7321, B7331, XE too)
 
Back
Top