10-08-2007 2:27 PM
The Parameter Tab in SU01 record in CUA does not contain the same list of Parameter IDs (PIDS) that are in the child systems. How do we enter these PIDS into the CUA system? Is this done manually?
Thank you,
John
10-08-2007 6:01 PM
If your master and child are different system [example master = ECC 6.0 and child = SRM 5.0] you difinitely need to set your SCUM settings with "Parameters" local. You have to enter the parameters in the child system.
If you leave the SCUM "Parameters" to global, you will get errors in SKUL stating that the parameters do not exist.
In summary, set SCUM to local and make the PIDs changes on the child system.
10-08-2007 5:14 PM
Hi John,
PIDs and CUA are often a bit of a pain. Check out note <a href="https://service.sap.com/sap/support/notes/395841">395841</a> for further info.
If the PID values are not read into the central system when you pull the users in then you could update them manually by getting the data from table USR05 in the child systems. It depends whether you want the same values to be in the master & the child systems or you just distribute a few key ones and the client PIDs be updated as & when required (e.g when user sets an FI view) by setting the field to be Proposal in tx SCUM
Hope that answers your question,
Cheers
Alex
Message was edited by:
Alex Ayers
10-08-2007 6:01 PM
If your master and child are different system [example master = ECC 6.0 and child = SRM 5.0] you difinitely need to set your SCUM settings with "Parameters" local. You have to enter the parameters in the child system.
If you leave the SCUM "Parameters" to global, you will get errors in SKUL stating that the parameters do not exist.
In summary, set SCUM to local and make the PIDs changes on the child system.
10-08-2007 6:52 PM
Hi John (Navarro)
Note 395841 deals with that if you <i>really</i> want to maintain your PID's centrally. Basically it suppresses the idoc error in SCUL
Cheers
Alex
10-08-2007 8:54 PM
Thank you for the clarification. SCUL not SKUL.
No need for notes... I based most of my post on experience. LOL!
10-08-2007 10:12 PM
Alex also said <i>"really"</i> and not "really".
PIDs can in most cases, particularly for their application areas, be set by the user somewhere anyway (locally), or in transaction SU3. It has been discussed here before, that they should not be used for "security" purposes, but rather to memorize preferences of the user, or at most security-irrelevant preferences of the program used by the user.
From my experience, many users and admins dont know what a PID is anyway.
Did you train the users to be carefull, and how to efficiently use them?
Disclaimer: I have no exposure to PIDs in CUA.
Cheers,
Julius
Message was edited by: Julius Bussche
Ohhhh... carefull using the smiley feature. It truncated the rest of my post and removed all hard returns. Will need to test that again.
10-08-2007 9:08 PM
Thank you to everyone who replied.
We are justing going to leave the PIDs in the repective systems and allow them to be set there instead of within the CUA.
Peace,
John