cancel
Showing results for 
Search instead for 
Did you mean: 

Missing change document for object: bug or missing functionality?

nicolas_busson
Active Contributor
0 Kudos

Hello,

As I do not have enough authorizations to create a Poll in this place, I'm just asking this simple question to see what your opinion is:

if you do not see all changes made on a standard SAP object in its change documents (example: you change a customer firstname, you'll see who changed what and when, but if you change customer lastname nothing is recorded). Would you say:

1) There is a missing functionality in the software that you need to develop yourself?

2) Or there is a bug SAP support needs to fix?

Cheers,

Nick.

Accepted Solutions (1)

Accepted Solutions (1)

Jelena
Active Contributor
0 Kudos

As long as the customer did not do something to disable the change tracking and the fields are very similar (like first name and last name in this example), I'd go with option 2.

nicolas_busson
Active Contributor
0 Kudos

Hello Jelena,

Thanks for chiming in! To be more precise regarding this issue, no change doc was disabled, and the problem lies in device location (I'm working for a Utility company that is distributing electricity):

- If you change the room number or floor where the device is located, change docs are created.

- If you change the building where the device is located, no change docs...

In other words: if you change a device location and make a "small" mistake (you fill-in 3rd floor when it should have been 4th floor for example), you can always see who made that mistake. But if you screw it up completely and select a completely wrong building, it seems that it is SAP standard design not to log anything... and SAP seems to consider it a best practice to use pen & paper to keep a note of what was done:

And the best thing is: we created a Z transaction a long time ago to include the 5 lines of coding that were missing in SAP standard to log every change correctly. So I decided to post this question on SCN because according to me BAD piece of information is worse than NO information at all (and as far as changeDocs are concerned, incomplete means bad to me because you get the wrong impression that no change ever occur -- while if you had no changeDocs at all you could still doubt it).

So it's just that I'm still wondering if incident processors really believe what they say... or keep trying to make me close any incident they find too hard to fix.

Cheers!

Nick.

Jelena
Active Contributor
0 Kudos

I don't know anything about IS-U, so I might be off on this, but based on the limited information in your post and in the note 1810101 on Improvement Finder site I don't see much logic in the SAP response. It could be respondent's Yoda-like grammar or some translation issue, but I don't get at all why adding a change document is "a difficult point" and what security has to do with it.

If the 'Change document' checkbox is checked in SE11 then the change document should be created. The whole "difficult" development is to call a function module, as far as I recall. Not a rocket science. The argument "there is no error because it is based on our very bad design and we were too lazy to add a few additional lines" seems rather laughable.

The Improvement Finder page does not say anything about specifically excluding change documents. It just goes about the new functionality. I can only guess that change documents were not specifically put in the specification, but perhaps it was because it was just expected. E.g. we don't put in the spec that changes need to be written to the database, some things are just implied.

Even though technically it is not an error, personally I don't see any valid reason why this must not be done. Again, it's not my area of expertise, but I strongly suspect that the whole talk about the complexity is a brush-off. "Shorry, couldn't make it".

P.S. I'm curious how this would work in "The Cloud".

nicolas_busson
Active Contributor
0 Kudos

Jelena you nailed it. As always.

Answers (6)

Answers (6)

nicolas_busson
Active Contributor
0 Kudos

Dear all,

I just wanted to write a note to thank all of you: it seems this post got enough attention for SAP support to review its initial position and provide an OSS note that is finally fixing the problem:

2251238-ES64: No change documents when you reassign device locations

So big up to SCN community. Really appreciated your support.

Cheers,

Nick.

Jelena
Active Contributor
0 Kudos

Thanks for an update, Nicholas! Really glad to hear SAP came around after all. Kudos to someone who chose not to hide behind The Design and make it right. "Where there is a will, there is a way".

Private_Member_7726
Active Contributor
0 Kudos

The big risk of changing poor "legacy" code

Cheers

Jānis

Jelena
Active Contributor
0 Kudos

So, let me get that straight - in the cases when buggy code was introduced by a note all the possible scenarios were tested? By that logic SAP would be either stuck in the 70s or have no bugs whatsoever. Neither of which is the case, from what I see. Probably some employees didn't get the memo.

stephenjohannes
Active Contributor
0 Kudos

Unless the field is on a different segment of the business object, then I will call it bug or bad design by SAP.  You know like using BDC for inbound vendor master creation via IDOC on ECC 6.0 or not having any real-user exits in the ADRMAS idoc type.

That being said I think Luis was wrong about SAP Press authors being part of the kind souls group.  I would instead add them to the "tortured souls" group.  I really can't complain about the documentation gap today for SAP solutions.   You really never learned SAP R/3 unless you had to use physical CD documentation ( what's help.sap.com ) and the red & white ABAP book.

Take care,

Stephen

former_member182421
Active Contributor
0 Kudos

I would try to add my 2 cents.

Option 2, if I don't have any point in the help sap (preferably) or KBA which explains the functional or technical constraints.

<Ranting mode=ON>I won't say anything new here, but all of your suffered the SAP learning process, most of the gaps between official documentation and the certificaction program, which IMHO must be sufficente to know how the system behaves, are resolved via some kind souls who blogs on SCN or dealing with SAP consultants/developers via marketplace, this information, usually gets lost at the end of the incident and of course not included in any official document, oh I was about to forget the SAP Press books, well, I guess we can include the authors to the kind souls group as I don't belive they got any richer. Nick you just praticipated in one of the Jerry's Wang blogs, claiming for that, so I guess you are pretty fired up to be hones I'm, I hate invest mots of my energies trying to figure out how a finished product works because "the instructions" are not completed or accurated, dealing with the delays of the suppor when I got stuck and the product is not behaving as It should, etc. Man, I hate this stuff...

</Ranting>

Of course, If there wasn't any ranting I would choose option 1

Cheers!

Luis

appasaheb_nagargoje
Active Participant
0 Kudos

Option number 2

JL23
Active Contributor
0 Kudos

my vote: 2

nicolas_busson
Active Contributor
0 Kudos

Thanks Jurgen!

That's my vote too of course... but I wanted to check with more people as I've got an incident opened for weeks now where SAP Support insists on option 1. And the most surprising is: I can find oss notes flagged as "program error" that are dealing with the very same issue. So I don't know what the general rule is in this case... but there must be one I guess.

JL23
Active Contributor
0 Kudos

I had a similar case earlier this year. I had an error that was fixed for 46c with note 320644 but still present in 606, took me about 2 months to convince the Support, but finally got 2150695


We have more than 2000 followers together,  a few of them should be able to add their voice to this discussion to make some pressure