Define S_RFC permissions using usage data
Retain the values of the permission trace to the role menu
If you only want to translate the description of the role, it is recommended to record the PFCG transaction and to change the source language of the role using the Z_ROLE_SET_MASTERLANG report before the LSMW script runs through. The report on how to change the source language can be found in SAP Note 854311. Similarly, you can use the SECATT (Extended Computer Aided Test Tool, eCATT) transaction to perform the translation instead of the LSMW transaction.
If, after an upgrade or after inserting a support package, you have used the SU25 transaction with steps 1 or 2a to bring suggested values to the latest SAP system state, you must restore the suggested values to the customer's organisation levels with the PFCG_ORGFIELD_UPGRADE report. To do this, you must run the report for each field, with the report's search engine showing only the affected organisation levels.
Correct settings of the essential parameters
The authorization check for the authorization objects PS_RMPSORG and PS_RMPSOEH runs as follows following a user entry: The system determines the organizational unit to which the user is assigned. Starting from this organizational unit, the system creates a list of all organizational units that are superior to the organizational unit determined in the first step in the hierarchy. The system determines the set (M1) of all organizational objects that are assigned to these organizational units. The system determines the organizational unit to which the object to be processed is assigned (corresponds to the lead organizational unit in the attributes of the object to be processed). Starting from this lead organizational unit, the system creates a list of all organizational units that are superior to the determined organizational unit within the hierarchy. The system determines the set (M2) of all organizational objects assigned to these organizational units. The system forms the intersection (from M1 and M2) of the matching organizational objects of the user and the object to be processed. The system determines the organizational levels that match for the user and the object being processed. Once a matching organizational level is found, the system performs the authorization check for the other fields of the authorization object (e.g., type of object or activity); if the system cannot determine a common organizational level, processing is rejected. If the user is allowed to perform the requested activity, processing is allowed; otherwise, the system rejects processing.
Define explicit code-level permission checks whenever you start transactions from ABAP programmes or access critical functions or data. This is the easiest and most effective defence to protect your business applications from misuse, because programming-level permission checks can ensure two things: Incomplete or incorrect validation of the executed transaction start permissions will result in compliance violations. Complex permission checks can also be performed adequately for the parameterized use of CALL TRANSACTION.
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.
A central basis for extensively digitized processes are structured specifications that regulate system access and control access rights.
Since the maintenance effort would be too great if individual authorizations were entered in the user master record, authorizations can be combined into authorization profiles.