SU24 Tips & Tricks – Fields you cannot maintain
In previous blog articles, we discussed fields that you should and should not maintain as SU24 proposals for roles. In this article, we’ll take a closer look at fields that you cannot maintain in SU24 due to technical restraints or configuration options.
Table of Contents
Fields promoted to USORG Organizational levels
If you read the documentation of report PFCG_ORGFIELD_CREATE, then you should also pay attention to the warnings about using it. If you promote a field to an organizational level, it has implications related to its proposals in SU24. Specifically, already present values will be replaced by the USORG variable. As a consequence, you will only be able to maintain the field directly in roles via the profile generator (PFCG).
As a result, all field values for all the objects that use the promoted field will be the same within individual roles. So ideally you should only promote fields that are used by one object only. But if that is the case, I would argue that there shouldn’t be a need to promote the field in the first place.
You must also be aware that the existing values for the promoted field in SU24 will be deleted. That makes backing out of such a change quite difficult unless you update all open fields in all roles again. If you have a lot of roles with a lot of maintained values, then it is nearly impossible.
Fields of objects that you can globally deactivate in SU25
Via transaction SU25 (Installation and Upgrade tool) you can use step 5 “Deactivate Authorization Object Globally,” which allows you to switch off authority-checks against individual authorization objects.
The purpose of this setting is to simplify your authorization concept for objects that you do not want to control, but the code would check regardless. By doing so, you end up with smaller and less error-prone roles as the object cannot ever be a source of authorization errors.
Technically what happens is that this global setting for an authorization object will cause all checks against it to be successful – regardless whether the user has authorization or not. Additionally, SU25 deletes the object from all SU24 proposals for all transactions and it will not be included in any roles. As a result, you will not be able to maintain it in SU24 or PFCG.
Note that despite the term “globally”, this setting is still client dependent. Instead, “globally” means that the setting applies to all transactions associated with the check.
It is important to understand that some auditors are against deactivating authorization objects and might recommend setting system parameter auth/object_disabling_active to “no” via transaction RZ10, which disables the mechanism. Also, you cannot deactivate “BC” or “HR” objects in SU25 because SAP classifies these objects as “required”.
Fields of objects you can locally deactivate in SU24
In addition to the global deactivation in SU25, you can also locally deactivate an authorization object in SU24. Doing so has the same effect as disabling an object in SU25, except that it only affects the transaction context for which you have deactivated it.
SAP uses this mechanism widely for standard transactions because of reused code to perform specific functions, and in some cases, the check in those functions is too strict.
For example, posting from a sub-ledger, such as goods receipt, to the general ledger should not force the user in the warehouse to be able to post directly to the general ledger. Also, in many cases, the authorization concept already is simplified in this way. When specific to a transaction, there is no control requirement for an authorization object which can potentially be checked.
Note that some auditors are principally against this option and might recommend that you set RZ10 system parameter auth/no_check_in_some_cases to “No”, which disables the mechanism. But doing so has numerous disadvantages, including:
- All SAP “no check” indicators will become active but not be in the roles
- SU24 is client independent
- SU25 is client dependent
- RZ11 parameters are not transportable
- Transaction PFCG will switch to display-only mode
- Now read this from bottom to top again and consider the consequences!
You cannot deactivate “BC” or “HR” objects though as these are classed as always necessary and cannot be simplified via SU25. We highly recommend not to change the defaults. You can, however, adjust check indicators in SU24 for your purposes and implementation of the control concept you need.
Field values that do not fulfill the SE93 additional authorization check
When you start a transaction, the SAP kernel will automatically check the authorization for the corresponding object S_TCODE. Plus, SAP offers additional “plausibility” authority-checks that you can maintain in transaction SE93.
If you try to save a change in SU24 for an authorization proposal that conflicts with that in SE93 (the backend table of these additional checks is TSTCA), you will get a message indicating that the “Data was automatically corrected.”
You cannot maintain values in SU24 that conflict with these “additional start authorizations”. As an example, you cannot enter FB01 in display only mode if you cannot at least create journal entries for a company code. The program will not even start, and SU24 will be automatically corrected back to the minimum which it needs.
Conclusion
Using the tips from these first three SU24 Tips & Tricks articles you can achieve a 99% field completion rate of your roles. Plus, you should now have a better understanding of how to make the initial investment in maintaining SU24 correctly. As a result, you will have less maintenance effort in the long run.
Previously in this series:
