Maintain derived roles
View system modifiability settings
For each form of automated derivative of roles, you should first define an organisational matrix that maps the organisational requirements. To do this, you must provide data on each organisation in a structured form.
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.
Set up permissions to access specific CO-PA measures
In order to transport this table entry, you must go to the object list of the transport order in transaction SE09 and manually create an entry there with object key R3TR TABU KBEROBJ. Double-click on the key list, and you will be taken to the care image where you have to create an entry with *. This will transport all entries in the KBEROBJ table starting with a space. You must then move the RESPAREA field to the organisational level. Please follow the instructions in our Tip 49, "Add New Organisation Levels". If you use more than one Cost Centre or Profit Centre hierarchy with inheritance logic for the permissions, you must set this in the Customising cost accounting circles through the transaction OKKP. There you can decide in the year independent basic data which hierarchies you want to use. In the basic data for the year, you then define which hierarchies should be used per fiscal year. You can use up to three hierarchies for entitlement award for cost centres and profit centres.
You can now assign transactions to these roles. Experience has shown that roles should remain application-specific and that a distinction between book or investing, changing and reading roles is also useful. There will be regular transactions used in multiple roles. You should not overestimate the often demanded freedom of redundancy. However, for critical transactions or transactions that are involved in a functional separation conflict, it is recommended that they be kept in a separate role. In general, roles should not contain too many transactions; Smaller roles are easier to maintain and easier to derive. Also, assigning them does not quickly lead to the problem that users have too many permissions. If you keep the necessary functional separations in place, you have already prepared them as a takeaway.
Assigning a role for a limited period of time is done in seconds with "Shortcut for SAP systems" and allows you to quickly continue your go-live.
Add SAP Note 1695113 to your system.
This check is necessary because sending an encrypted e-mail is cancelled if more than one valid certificate to an e-mail address is found.