Goal of an authorization concept
THE "TOP SEVEN"
With these methods, we not only help you with the implementation. You can also maintain and manage the solutions yourself afterwards, or you can trust us to run them for you: We call this Customer Success.
The SAP standard offers various ways to record and play on a massive scale. These tools are generally available for all operations in the SAP system, not just for role maintenance. Therefore, they are also more complex to operate, in order to be able to cover as flexibly as possible all possible application scenarios. eCATT is also no exception, so many users are still afraid to use it. But we can tell you from experience: After the second or third time, the creation of the test scripts is so quick that you'll wonder why you haven't always done it this way.
Use usage data for role definition
In principle, all eligibility fields can be upgraded to the organisational level; there are, however, technical exceptions and fields where this is not useful. Technically, the fields that are in the context of testing the startup capability of an application are excluded, i.e. the fields of the S_TCODE, S_START, S_USER_STA, S_SERVICE, S_RFC, S_PROGRAM and S_USER_VAL authorization objects. In addition, you cannot elevate the ACTVT field to the organisation level. Only the fields that can be assigned a value range within a role are meaningful. This must of course be considered across the board for the authorisation concept. For example, fields that have more than one meaning, such as the Authorisation Group (BEGRU), are not suitable for material management. The PFCG_ORGFIELD_CREATE report allows you to define a permission field as an organisation level. The report enters the field in the USORG table, changes the permission proposal values to that field, and performs all the roles that have a shape in the field.
Without generic table logging, certain changes in the system are not traceable. Learn how to turn on table logging in the system for a large set of tables. The SAP system writes change documents for most changes - but not all. Specifically, changes to tables in which the customising is performed are not recorded in the modification documents. This may lead to a lack of comprehensibility of changes. Avoid this by basically enabling table logging and then setting logging for specific additional tables. You should always enable table logging for all clients. However, during a release upgrade it may be necessary to temporarily disable table logging.
The possibility of assigning authorizations during the go-live can be additionally secured by using "Shortcut for SAP systems".
You will then have to limit access to the various departments, for example to the appropriate booking groups, sales organisations or purchasing organisations.
You can also find some useful tips from practice on the subject of SAP authorizations on the page www.sap-corner.de.
This can be business-critical or personal data or even passwords.