Note the maintenance status of permissions in roles and their impact
Customise Permissions After Upgrade
There are several ways to view the implementation of permission checks: Either you jump directly from the system trace for permissions to the appropriate locations in the programme code, or you go over the definition of the authorization objects. To view the permission checks from the permissions system trace, start the trace from the STAUTHTRACE transaction and run the applications you want to view. Now open the evaluation of the Trace. In the Programme Name column, you can see the programme that includes the Permissions Check. Double-click to go directly to the code site where the permission check is implemented.
At www.sap-corner.de you will also find a lot of useful information on the subject of SAP authorizations.
So much information... how can you keep it so that you can find it again when you need it? That's what Scribble Papers is great for.
For users for which no user type has been defined in the ZBV, either the default user type of the subsidiary system or the user type defined by the local measurement programme (transaction USMM) run is reported in the Contractual User Type column. In this case, no value is reported in the Value column in the control centre. If the user type has been defined via a local run of the surveying programme and this type of user is not stored in the ZBV, you should re-import the licence data for this user from the subsidiary system into the ZBV using the transaction SCUG. If there are users in the daughter systems for which the value in the columns of the Contractual User Type and Value in ZBV Central differ, either the IDoc of the ZBV has not yet been processed, or the user type has been changed locally. In these cases, you should check what the differences are and also correct them.
Standard authorisation
In most cases, customizing is performed using transaction SPRO. However, this is only the initial transaction for a very comprehensive tree structure of further maintenance transactions. Most customizing activities, however, consist of indirect or direct maintenance of tables. Therefore, a random check of the authorization structure in this environment can be reduced to table authorizations. In the case of delimited responsibilities within customizing (e.g. FI, MM, SD, etc.), attention should therefore be paid here to an appropriate delimitation within the table authorizations. Independent of assigned transaction authorizations within customizing, a full authorization on table level combined with a table maintenance transaction such as SM30 practically corresponds to a full authorization in customizing. Normal customizing by user departments generally refers to client-specific tables. Access to system tables should therefore be restricted to basic administration if possible.
A temporary shutdown of Central User Management is usually not recommended. However, in certain cases it may be necessary. We will show you what pre- and post-processing is required to avoid data inconsistencies. In complex SAP landscapes where the Central User Administration (ZBV) is used, there may be cases where you want to temporarily remove a subsidiary system from the ZBV without having to delete this system or shut down the entire ZBV, for example if you want to create users in a subsidiary system at short notice.
The possibility of assigning authorizations during the go-live can be additionally secured by using "Shortcut for SAP systems".
In addition to existing authorization objects, you can also create your own authorization objects and select existing authorization fields such as Activity (ACTVT).
This relationship is set to the User ID.