Create permissions for customising
Authorization object documentation
Partners delivering their developments also maintain the proposed values for their applications in the transaction SU22. If customers are developing systems that supply other system landscapes than your system landscape and require different SU24 suggestion values per system, the proposed values in transaction SU22 will be maintained. The profile generator uses only the values of the transaction SU24 in your customer environment as a data base. To maintain the suggestion values, you can use both the System Trace data for permissions from the ST01 or STAUTHTRACE transaction and the data from the permission trace in the SU24 transaction (see Tip 39, "Maintain suggestion values using trace evaluations").
In order to provide user authorisation support, you often need their information. However, there is also the possibility to view missing permissions centrally for all users. If a user has a permission issue, a ticket is usually displayed at support. However, it is difficult for a support worker to understand permissions errors because they have different permissions and are often missing detailed information about the application where the permission error occurred. In practice, therefore, support staff often help themselves by asking the user to send a screenshot of the transaction SU53. Because this transaction shows the last failed permission check. In many cases, however, the information displayed there is not helpful to the permission administrator. You may have seen that a screenshot from the SU53 transaction shows a missing permission for typical base authorization objects, such as S_ADMI_FCD, S_CTS_ADMI, or S_TRANSLAT, but you know that your check has nothing to do with the actual permissions problem in the application. So you need the opportunity to see for yourself.
What to do when the auditor comes - Part 1: Processes and documentation
Conceptually, the user types Database User and Technical User are distinguished. Database users are users that represent a real person in the database. As soon as a Database User is deleted, all (!) database objects created by this Database User are also deleted. Technical users are users who perform technical tasks in the database. Examples include the SYS and _SYS_REPO users, which allow administrative tasks such as creating a new database object or assigning privileges.
In order to make a well-founded statement about the complexity and the associated effort, a fundamental system analysis is required in advance. The results obtained from this form an excellent basis for estimating the project scope and implementation timeframe.
Authorizations can also be assigned via "Shortcut for SAP systems".
The website www.sap-corner.de offers a lot of useful information about SAP authorizations.
And if it is, the question is which authorization concept in SAP HCM is the right one.
There are several ways to view the implementation of permission checks: Either you jump directly from the system trace for permissions to the appropriate locations in the programme code, or you go over the definition of the authorization objects.