Tim,
Changes as minor as those you made to R42565 do not justify creating a '55' copy of the object. The specific changes will "probably" be picked up by the merge process without any problems. If you did make a '55' copy of R42565 then your 55 copy would NOT be merged. Our custom objects (55-59) are not merged by definition - JDE has no corresponding object with the same name to merge with.
Are you also asking what is the cutoff point for number of customizations in a object past which you should make a customized copy . . .
You'll encounter a variety of opinions on this I suspect. 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.
Your change to R42565 falls under my Rules #1 and #2.
Why do things this 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. The code compare tool in OMW works only with objects of the same name - not renamed copies.
It'll be interesting to hear others take on this.
