Permissions and User Root Sets Evaluations
Manual authorizations
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 first two problems can be solved by inserting the correction from SAP Note 1614407. The profile data will not be added to the bill of materials at the time of the roll recording but only when the transport order is released. This ensures consistency between the role's permission data and its profile data. The shared transport job also contains the complete history of changes to the profiles and permissions, so that obsolete data can also be deleted in the target systems.
Implementing the authorization concept in the FIORI interface
Don't simplify your entitlement concept before you know all the requirements, but first ask yourself what you need to achieve. So first analyse the processes (if possible also technically) and then create a concept. Many of the authorisation concepts we found in customers were not suitable to meet the requirements. Some of these were "grown" permission concepts (i.e., requests were repeatedly added) or purchased permission concepts. Many of these concepts had in common that they had been oversimplified, not simply. A nice example is permission concepts that summarise all organisational levels in value roles or organisational roles. There are few examples, such as the role manager of the industry solution SAP for Defence and Security, in which the result of a value role concept is still useful and appropriate for the user. The assumption that you "sometimes" separate all the authorization objects that contain an organisational level is simple, but not useful. We have not found the simplification that only a user without permissions can definitely not have illegal permissions. However, there was always the case that users had far too many permissions and the system was therefore not compliant.
However, you can also use the proof of use in the authorization object maintenance to search for specific implementation sites. To do this, open the authorization object in the SU21 transaction. Open the proof of use via the button and a pop-up window appears for querying usage modes (for example, using the affected authorization object in programmes or classes). After making your selection in the Usage Proof, all of the affected implementations will be tabulated. Double-click to access the relevant code locations.
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.
Some useful tips about SAP basis can be found on www.sap-corner.de.
You have the possibility to amend or supplement the proposals listed here.
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 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.