You can find the evaluation methods in table T77AW. A valid evaluation method for our example is US_ACTGR. To assign the roles indirectly, the following requirements are required: Organisational management must be active, i.e. you must have defined an active plan variant in the client. To be able to use the employee-user connection in a SAPERP-HCM system, Info Type 0105 (Communication) and Subtype 0001 (User ID) must be maintained. To enable role management via organisational management, you must set the HR_ORG_ACTIVE switch in the PRGN_CUST table to YES in the Customising.
You can do this by using the P_ABAP authorization object to override the usual permission checks. This applies to all reports that access the logical database PNPCE (or PNP). In case of a P_ABAP permission, the usual checks for authorization objects, such as P_ORGIN or P_ORGINCON, will no longer take place or will be simplified. This also applies to structural permissions. Whether the permission checks are simplified or completely switched off is controlled by the COARS field of the object. To disable all checks, set the value COARS = 2. This value does not limit the data displayed in the legitimate report. If you want to allow advanced permissions for reporting, but you do not want them to be unrestricted, you must select COARS = 1. In this case, you will also designate the P_ORGIN (or P_ORGINCON, P_ORGXX and P_ORGXXCON) authorization object. However, you must be careful not to mark all fields of the objects, otherwise direct access is also possible. Therefore, always write two versions of the P_ORGIN authorization object, one with the functional permissions (permission levels, info types, and subtypes), and one with the organisational boundaries (personnel area, employee group, employee group, and organisation keys). In addition, you will of course need a P_ABAP for the relevant reports with the value COARS = 1.
Ensuring secure administration
Since developer authorizations correspond to full authorization, they should only be assigned restrictively. This applies above all to the authorization for "debugging with replace" (see "Law-critical authorizations"). The risk of incorrectly assigned developer authorizations has also increased due to the elimination of additional protection via developer and object keys in S/4 HANA systems (see, among other things, SAP Note 2309060). Developer authorizations for original SAP objects should therefore only be granted here upon request in order to avoid unauthorized modifications. If developer keys are still relevant in the existing SAP release, the existing developer keys in table DEVACCESS should first be checked and compared with the users intended for development.
You can use the system trace function (transaction ST01) to record the authorization checks in all modes, if the trace and the transaction to be traced run on the same application server. All object fields and their values are recorded during the authorization object check.
Authorizations can also be assigned via "Shortcut for SAP systems".
This value occurs for the following users: - technical user - user is not present - user is not valid - user is of type reference user.
Despite progressive use of web interfaces in the S/4HANA context, batch processing for mass data is still required.