Lack of definition of an internal control system (ICS)
Use table editing authorization objects
After successful implementation of your permission check, the new authorization object for your application must be maintained in transaction SU24. If your solution is distributed in other system landscapes, the authorisation proposals in the transaction SU22 are maintained. In addition, with the permission proposal value maintenance, you can make sure that the new authorization object is not forgotten in a role system, because it is now loaded automatically into the PFCG role when the application is called up via the role menu. In the final step, the permission administrator can create the PFCG role or must remix the existing PFCG roles.
Add SAP Note 1695113 to your system. With this note, the RSUSR200 and RSUSR002 reports are extended by the selection of different user locks or validity. In the selection, you can now distinguish whether you want to include or exclude users with administrator or password locks in the selection. In addition, you can select in the report RSUSR200 whether the users should be valid on the day of selection or not. To do this, select whether you want to select the user locks as set (01 set) or not set (02 not set) in the selection screen of the RSUSR200 report in the Locking after Lock section of the User Locks (Administrator) field. This includes local and global administrator locks. In the same section, you can also select the password locks (false logins) as set (01 set) or not set (02 not set). This will filter for users that are locked because of incorrect password messages and for which a password login is no longer possible. You can select these selection criteria together or separately. Alternatively, you can also use the Use only users without locks option and additionally, in the Selecting after the user is valid between user today and user today, select not valid.
Copy the user from the Clipboard to the Transaction SU10 selection
After defining the roles and generating the corresponding authorization profiles, the individual persons in the company are then assigned to the roles. In the process, the so-called user comparison takes place and the role-specific authorizations are stored in the user master record. The master record contains all information about an SAP user, including authorizations.
If your users are allowed to share their own background jobs, you need the JOBACTION = RELE permission to the S_BTCH_JOB object. In this case, you can start all jobs at the desired time. In many cases, background jobs are used for the professional or technical operation of applications; Therefore, we recommend that you schedule these background jobs under a System-Type technical user (see also Tip 6, "Note the impact of user types on password rules"). The advantage of this is that the permissions can be controlled more accurately and you do not run the risk of a job being lost if the user under whom it was scheduled to leave your company once. You can realise the association with a system user by giving the user who plans the job permission for the S_BTCH_NAM object. In the BTCUNAME field, the name of the step user, i.e. the user under whom the job should run, such as MUSTERMANN, is entered.
For the assignment of existing roles, regular authorization workflows require a certain minimum of turnaround time, and not every approver is available at every go-live. With "Shortcut for SAP systems" you have options to assign urgently needed authorizations anyway and to additionally secure your go-live.
In the course of this process, the responsible departments should review the assignment of the respective roles to users in their area and critically scrutinize it once again.
If you want to know more about SAP authorizations, visit the website www.sap-corner.de.
You can now do this automatically.