SCUM Selection Greyed Out

[Former Member]

Hi all,

I am trying to enable settings in which will allow role assignment in BOTH CUA and child system. Unfortunately, the selection for "Everywhere" is greyed out in SCUA --> Role/Profile tab. In my work environment, there is a need to allow role assignment in both master and child systems. How o I go with this? Couldn't found anything in Notes & SCN. Thank you for all your feedback!

[jurjen_heeck]

Asrar Razif wrote:

In my work environment, there is a need to allow role assignment in both master and child systems.

Maybe if you tell us a bit more about this requirement we can help you find a workaround.

[Former Member]

Can you imagine what sort of confusion this would create if it were possible?

Cheers,

Julius

[Colleen]

why would you have such a requirement?

[Former Member]

BTW: There is such a requirement in transaction SMSY. But it is rather suspect and uses redistribution (if authorized, but overrides the CUA) and then uses call backs to assign the roles.

Personally I don't see the need for it if the CUA is on the SOLMAN, and if not, then a wizard in the SOLMAN which navigates to the CUA will also do the trick.

Much too complicated....

Cheers,

Julius

[Colleen]

Isn't there also an exception for CUA in relation to position-based security? PRGN_CUST or similar to allow PFUD to update user masters for organisational structure inheritance and then "send" the assignment back to the CUA when CUA is a different system?

I can't remember the note but was asking for user's requirement in case something along these lines

When SMSY is being done by Basis, they get frustrated with CUA in place. Sometimes I'll let them break connection and then fix SCUG/SCUL afterwards for new system setup.

Regards

Colleen

[Former Member]

There are a few exceptions in the user APIs for call backs to the CUA even if redistribution and local SCUM is not set. There are also two passive CUA tolerances for CREATE1 and DELETE which redistribute based on authorizations and not CUA settings.

I think we are getting warmer here...

My explanation -> the user was deleted but still had address data and PPOME assignments. PFUD was / is not running. Then the user ID was recreated (intended for a different person?) and saving in SU01 runs PFUD in their release for indirect assignments as well. The user ID is still mapped in Infotype 0105 and reconnects to the HR-OM role which the "person" still has.

The best way to avoid this is by never deleting user IDs (hard to avoid in CUA) and ensuring unique names and authorizing the redistribution user centrally to only do text comparisons.

In the special case of SMSY the user names follow a naming convention, so if CUA is not on the SOLMAN logical system then I authorize the SOLMAN callback user (only) as if it is a client to send the user to the SOLMAN to than the system can be connected. The roles can then either be added manually or via PPOME (which is perhaps what was attempted here).

Cheers,

Julius

[Colleen]

I think we are getting warmer here...

SCN might need a new award. As much as you dislike gamification, a badge of honour for solving a user's problem with the least amount of information or vagueness provided.

[Former Member]

Lets see what Asrar's feedback has to say about it...

Not being on the same code page is also an attribute of the solution and many unsolved mysteries in SAP.

I think SAP tried to make a few exceptions to transactional CUA intuitive, but that does also create a bit of support type questions when strange things happen.

@ Asrar: Does this explain your problem? Can you provide more details? As an acid test you can run tcode SOUD to check for address data problems between old users and new ones  - this is often a symptom.

Cheers,

Julius