Query the Data from an HCM Personnel Root Record
Use the authorisation route to identify proposed values for customer developments
In addition to these requirements, other settings can ensure that the transaction can be performed without verification: Verification of eligibility objects is disabled by check marks (in transaction SU24). This is not possible for SAP NetWeaver and SAP ERP HCM authorization objects, i.e. it does not apply to S_TCODE checking. The checks for specific authorization objects can be globally off for all transactions (in transaction SU24 or SU25). This is only possible if the profile parameter AUTH/NO_CHECK_IN_SOME_CASES is Y. In addition, executable transactions may also result from the assignment of a reference user; the reference user's executable transactions are also taken into account.
The SAP authorization default values are the basis for role creation and are also the starting point for SAP authorization management. For this purpose, the SU22 SAP authorization default values must be transported via SU25 into the customer-specific SU24 tables. The consistency of the default values should therefore be checked beforehand using the SU2X_CHECK_CONSISTENCY report. If inconsistencies exist, they can be corrected using the report SU24_AUTO_REPAIR. Detailed information regarding the procedure can be found in SAP Note 1539556. In this way, you can not only clean up your SU24 values, but at the same time achieve a high-performance starting position for role and authorization administration.
Do not assign SAP_NEW
The function block was obviously not intended for this use, but our procedure does not affect the programme process and we are not aware of any limitations resulting from this use. You can also apply this procedure to other BTEs that pass data in a similar form. However, you should always exercise caution and check whether the application has already created sum records or whether there are other dependencies. Finally, you will need to create a product you have developed (you can define the name yourself) in the FIBF transaction and assign it to Business Transaction Event 1650 along with the customer's own function block, as shown in the following figure. A custom product may include several enhancements. It forms a logical bracket around the extensions and thus provides a better overview. In addition, it allows for a targeted activation or deactivation of the implementations.
Configuration validation uses the CCDB's configuration data to reconcile settings. To do this, you define your customer-specific security settings technically in a target system. This contains the specifications for the configuration of SAP systems. You can also define a target system based on the settings of an existing system and adapt it to your requirements. Then you compare the settings of your SAP systems with this target system on a daily basis and get an overview of the deviations. Since there may of course be different security requirements for the systems in your landscape (e.g. development and production systems), you can define different target systems with the appropriate settings. You then start the comparison with a target system for the relevant systems. Alternatively, you can compare to an actual system; For example, this is a useful function in the context of a roll-out.
Authorizations can also be assigned via "Shortcut for SAP systems".
The ZBV's change documents are written for the USER_CUA change document object.
At www.sap-corner.de you will also find a lot of useful information on the subject of SAP authorizations.
For these reasons, SAP has introduced Security Patch Day (every other Tuesday of the month), which will allow you to better plan for implementing the security advisories.