on 05-05-2009 3:35 PM
Hi All,
I am trying to turn on change docs to track changes made to additional data (class type 017) for DIRs stored in the DMS. Can anyone give me some directions?
Thanks in advance,
Bill Pickett
Hi Bill
Have you tried turning this on under spro - cross apps - classification - classes - object types and classes
On the object table select Draw - then double click 017 under object types. There should be an option to select change docs. (also check "multiple objects required" as this is also a requirement for change docs) It may list some programs you have to start to enable the multiple objects allowed functionality if they are required.
I normally prefer not to use 017 and make my own copy of it for any modifications.
Regards,
Athol
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks for the answer about the new items - that makes total sense to me.
The more I dig into this the more difficult it seems to become. In our investigation this morning it seems that in previous projects there has been custom code written against the KSSP and AUSP tables for class 017 characteristics. The program that has to be executed before the Change Docs can be enables seems to change the key pointers in those tables and there's a fear this 'fix' may break the custom code.
Further investigation is going on right now. I have turned this one over to the technical managers to hash out the lessor of the evils...
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hello Athol,
Actually I had overlooked this until I found OSS Note 65124 and realized we had not implemented it for class type 017. This directed me in exactly the same direction as you did.
I am curious tho' - can you expand on your reasons of not using class 017 for the Draw Object and making your own copy?
Thanks - as always your answers are right on the money,
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
There are a couple of reason but part of it is following the whole "Don't change SAP standard, rather create a copy with a z naming convention for changes principle".
As a consulting company and given the fact that we are not the owners of the system, we sometimes don't have the opportunity to investigate if any objects are used elsewhere and in some cases, users themselves aren't aware that they are using the system in other areas (for example, some people don't realise that documents in the DMS are used in other areas like EH&S). By creating copies, we eliminate the possibility of making a change which may adversely affect another working area of the system that the project initiator is unaware of. It doesn't happen often that you make a change that impacts on others, but i'd rather take precautions than solve the issues afterwards.
We've also found that in some cases customers are incorrectly using something for the wrong purpose. For example, we found someone using the document structure type for reporting areas in another area of PM so we couldn't implement EasyDMS because they had changed one of the standard object types.
Edited by: Athol Hill on May 6, 2009 10:38 PM
User | Count |
---|---|
91 | |
8 | |
7 | |
4 | |
4 | |
3 | |
3 | |
3 | |
3 | |
3 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.