{"id":2116,"date":"2017-04-14T06:00:49","date_gmt":"2017-04-14T10:00:49","guid":{"rendered":"https:\/\/www.xiting.us\/?p=2116"},"modified":"2025-10-01T10:43:12","modified_gmt":"2025-10-01T08:43:12","slug":"su24-fields-not-to-maintain","status":"publish","type":"post","link":"https:\/\/xiting.com\/en\/su24-fields-not-to-maintain\/","title":{"rendered":"SU24 Tips & Tricks – Fields you cannot maintain"},"content":{"rendered":"

In previous blog articles, we discussed fields that you should<\/a> and should not<\/a> 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.<\/p>\n

Fields promoted to USORG Organizational levels<\/strong><\/h3>\n

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).<\/p>\n

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.<\/p>\n

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.<\/p>\n

\"SU24<\/a>
Performance Assistant<\/figcaption><\/figure>\n

Fields of objects that you can globally deactivate in SU25<\/strong><\/h3>\n

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.<\/p>\n

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.<\/p>\n

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.<\/p>\n

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.<\/p>\n

It is important to understand that some auditors are against deactivating authorization objects and might recommend setting system parameter auth\/object_disabling_active<\/em> to “no<\/em>” via transaction RZ10, which disables the mechanism. Also, you cannot deactivate “BC” or “HR” objects in SU25 because SAP classifies these objects as “required”.<\/p>\n

\"SU24<\/a>
Globally deactivated objects in SU25<\/figcaption><\/figure>\n

Fields of objects you can locally deactivate in SU24<\/strong><\/h3>\n

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.<\/p>\n

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.<\/p>\n

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.<\/p>\n

\"SU24<\/a>
Locally deactivated objects in SU24<\/figcaption><\/figure>\n

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:<\/p>\n