SAP Authorizations CONCLUSION - SAP Basis

Direkt zum Seiteninhalt
Know why which user has which SAP authorization
Since developer authorizations correspond to full authorization, they should only be assigned restrictively. This applies above all to the authorization for "debugging with replace" (see "Law-critical authorizations"). The risk of incorrectly assigned developer authorizations has also increased due to the elimination of additional protection via developer and object keys in S/4 HANA systems (see, among other things, SAP Note 2309060). Developer authorizations for original SAP objects should therefore only be granted here upon request in order to avoid unauthorized modifications. If developer keys are still relevant in the existing SAP release, the existing developer keys in table DEVACCESS should first be checked and compared with the users intended for development.

The aim of authorization concepts is to provide each user with the authorizations required for his or her task in the SAP system in accordance with the rules. A good authorization concept is the cornerstone for efficient and cost-effective authorization assignment.
Change documents
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.

If you want to know more about SAP authorizations, visit the website

The valid programmes or transactions are stored in the SAP TPCPROGS delivery table, but do not follow a uniform naming convention. Part of the transaction code (e.g. AW01N), part of the report name (e.g. RFEPOS00), or the logical database (e.g. SAPDBADA) is relevant here. Logical databases (e.g. SAPDBADA, SAPDBBRF) are basic data selection programmes and are particularly used in financial accounting. The permission checks, including the time period delimitation, are implemented in the logical database and work for all reports based on a logical database (e.g. the RAGITT00 grid is based on SAPDBADA and the RFBILA00 balance sheet report is based on SAPDBSDF). When you copy the values from the TPCPROGS table, the TPC4 transaction is quickly configured.

For the assignment of existing roles, regular authorization workflows require a certain minimum of turnaround time, and not every approver is available at every go-live. With "Shortcut for SAP systems" you have options to assign urgently needed authorizations anyway and to additionally secure your go-live.

Tables with delivery class C (such as customising, found in column A) are the relevant tables in this context.

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.

In the following we show you how you can apply the permission values from the permission trace to your role.
Zurück zum Seiteninhalt