Run the System Trace for Permissions (ST01 or STAUTHTRACE transaction) to record permission checks that you want to include in the role (see Tip 31, "Optimise Trace Evaluation"). Applications are logged through the Launch Permissions checks.
If you want to allow users to access only individual table rows, you can use the S_TABU_LIN authorization object, which allows access to specific rows of a table for defined organisational criteria. A prerequisite for this type of permission is that the tables have columns with such organisational values, such as the work, country, accounting area, etc. You must now configure these organisational values in the system as organisational criteria that represent business areas; serve as a bridge between the organisational columns in the tables and the permission field in the authorization object. Since the organisational criteria are found in several tables, this eligibility check need not be bound to specific tables and can be defined across tables.
How is it possible to jump from one transaction to another without checking the eligibility for the target transaction? With the CALL TRANSACTION statement! In this tip, we will explain how you can grant permissions for jumps from one transaction to another using the ABAP CALL TRANSACTION command, or actively determine which checks to perform. The CALL TRANSACTION statement does not automatically check the user's permission to perform the invoked transaction. If no verification takes place in the invoked programme, it must be installed in the calling programme by adding additional features for the eligibility check.
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.
If you get into the situation that authorizations are required that were not considered in the role concept, "Shortcut for SAP systems" allows you to assign the complete authorization for the respective authorization object.
In addition, there is the challenge of limiting access to the audited financial years.
Under the item Adjustment of the permission checks (optional) are the transactions SU24 for the maintenance of the value of the proposal, the transaction AUTH_SWITCH_OBJECTS for the global elimination of the authorization objects as well as the transaction SE97 for the maintenance of transaction startup permissions checks (see Tip 76, "Maintain transaction start permissions when calling CALL TRANSACTION").