Re: How to apply ESU\'s
Hi Don,
Sorry its taken me a couple of days to get back to you - I've been busy for a go-live prior to Focus !
To answer your questions in order :
1. I cannot answer this question entirely - since I no longer work for JDE myself - but I can make a half-hearted guess at their approach.
From reading the documentation with all of the updates - it is not necessary from JD Edwards perspective to implement any of the ESU's - in fact, they have certainly made statements to prevent implementation of ESU's if they do not directly address an issue in your implementation. Therefore this can be interpreted a number of ways. Primarily, and with common sense - JDE do not want to foul up your nice reliable implementation of OneWorld just because some Advanced Transportation function is not correctly working at a single customer in Iceland - they will provide a fix on the ESU to address the issue - and if you have the same issue, then you will probably be instructed to implement the ESU. However, the BAD thing about ESU's is the fact that JDE have started combining different support issues in a single ESU release. This means that although you have an issue, for example, with a Sales Update report not working - you may be instructed to install an ESU that "Fixes" the above islandic issue - but that inadvertantly fouls up a Financial application that you were working on. My opinion is that JDE support (because they do not truthfully understand how every customers implementation works) would like to see fewer permutations by "forcing" customers to implement updates - but the reality is that every customer uses the software differently, both from a data perspective and an application perspective.
If I modify a JD Edwards interactive application like P4210 - does that automatically mean that JDE will not support issues in the B4200310 function that the interactive app calls ? In theory JDE should support any issue as far as they can in their software - no matter how that software is being used - but I know that reality is far from perfect.
2. By following the directions in the guide - this becomes easier since you can use Visual ER Compare to compare an ESU code-fix against Development. It is good practice to only modify JDE code as a last resort.
3. see above. Solution is for JDE to stop combining SAR's that are unrelated. This is going to cause them (and has) more issues than the older system - hence they need to work out their direction here.
4. I personally do not see an issue in the way of implementing the ESU's to pristine. After all, the standard JD Edwards installation routines directly go against pristine as it is. If there is a drop-dead issue at a customer site - and JDE really, really want to test in a "pure" pristine environment - I don't think there is an issue because you don't build packages in pristine ! As long as the packages do not get built, then the central objects do not affect the runtime.
Thank you for the complement by the way. I am surprised at the lack of response for this thread - it seemed to me that I might have been going off at a tangent by creating this whitepaper and addressing something that may not have been an issue ! However, I have seen a large number of downloads on my website - so I believe that more people have the issue and less want to discuss it !
I hope all is going well - if you have any questions, please don't hesitate to contact me !
Jon Steel
Xe Upgrade Specialist
erpSOURCING LLC
ERP Sourcing
http://www.erpsourcing.com
[email protected]