SAP AUTHORIZATIONS: THE 7 MOST IMPORTANT REPORTS
What to do when the auditor comes - Part 1: Processes and documentation
In the SCC4 transaction, first check whether eCATT is allowed to run. Then start the SECATT transaction. As you get started, you can define and modify test scripts and test configurations. First, create a test script. Think of it as a blueprint or a flow rule for how to create new derived roles. The test script will contain your recording later. Give the script a talking name, such as Z_MASSENGERATION_DERIVATIVES. Then click the Create Object button. You will now go to the Attribute tab, where you specify the general frame data. Then click the Editor tab. Now it goes to the recording, in the eCATT language called patterns. Click the Pattern button and specify that you want to record the PFCG transaction by selecting the UIAncontrol and TCD (Record) settings. The system will propose to call the interface "PFCG_1"; You can simply confirm this. Confirmation of the dialogue will immediately start the recording; They therefore end up in the PFCG transaction. We want to record the creation of a single role derived from a reference role. Complete the appropriate steps in the PFCG transaction and try to avoid unnecessary steps - every step you take will make your recording bigger and less cluttered. Enter the name of the derived role - we can influence it later when playing with eCATT - and specify the role. Now assign the reference role. Note that the PFCG transaction is actually executed, so the role is actually created in the system! Now maintain the permissions and organisation levels. If possible, use organisational level values in the note, which you can find well in other numbers later on, i.e. about 9999 or 1234. After generating and saving the role, you will be returned to eCATT. There you will be asked if you want to accept the data and confirm with Yes.
It is important that, if necessary, the database is converted to an SAP S/4HANA database. In addition, various technical system components must be analyzed and adapted to the new environment. But restructuring must also be carried out at the organizational level. For example, the "old", or current, authorization concept must be analyzed, evaluated and, if necessary, fundamentally revised.
Our services in the area of SAP authorizations
These single roles can also be combined into composite roles. I recently discussed the special features of this in the article "SAP Authorizations Mass Maintenance Single Role Assignments in Composite Roles per Function Module (FuBa) or Transaction Code", but here I would rather discuss the roles and assignment of authorization object field values in role maintenance with the PFCG for an authorization overview.
You can also remove customer-specific organisational levels and convert them to a simple permission field. The report PFCG_ORGFIELD_DELETE serves for this purpose. It removes the permission field from the USORG table and changes the permission proposal values to that field. Finally, it goes through all the rolls that contain a shape to the field. However, it does not restore the old location of the field, because summarised values will no longer be separated when the field is elevated to the organisational level. Instead, the aggregated values are entered separately in each field. The PFCG_ORGFIELD_DELETE report also provides a value aid that shows only the customer's organisational levels. You can also use this value aid to determine all customer-specific organisational levels.
With "Shortcut for SAP systems" you can automate the assignment of roles after a go-live.
If you want to know more about SAP authorizations, visit the website www.sap-corner.de.
A clear role concept enables a modular structure of authorizations without having to create separate roles for each user.
Besides if the default values from the SU24 still have open fields and here entries have been made, a MAINTENANCE appears next to the berechitgungsobjekt and with manually added authorization objects a MANUAL.