Creation and use of a transaction SU24N proposal data variant (Part 2)
My first blog post on the new transaction SU24N, which is available for SAP ERP system as of SAP_BASIS ABAP Release 7.54, was primarily about a general overview and the presentation of the changes or innovative enhancements to SU24 tcode that target on the authorization check link between SAP objects that can be mapped to a technical role and the authorization objects, fields and field values called out in the ABAP code. Now, as already announced in part 1, this blog will focus on the biggest milestone in the context of authorization proposal values and their control. This is the creation of proposal data variants.
Consider the typical problems where the business departments or internal controls require different authorization variants for the execution of an individual transaction or service. Missing authorizations are found during trace evaluations or when the tester identifies an authorization error during the execution of a particular transactions. For example, the control of the cockpit transaction BP in Display and Attachment/Change or in Vendor and Customer Authorizations. Transaction FS00 is also often subject to display and maintenance restrictions. Unfortunately, this cannot be solved quickly and easily with best-practice role construction with the existing SU24 transaction and updates to tables USOBT_C and USOBX_C. In the past, administrators had to adjust the default values for the respective transaction codes (usually deleting authorization field values to leave the field blank) and then maintain the required authorizations for the varying access scenarios according to the specifications in the different respective roles. This always led to a large maintenance effort, which increased exponentially with process changes or transaction SU25 upgrades. Now, thanks to transaction SU24N and its proposal data variants, this is over, saving this time-consuming transaction maintenance, whether for SAP standard transactions or custom transactions (e.g., parameter transaction). Predefined restrictions in the default values can be maintained using the proposal data variants and then implemented into the job function roles. In the context of SAP S/4HANA and the associated simplification and consolidation of functions and applications, such granular differentiation is more essential than ever.
This blog will now show how to create an SU24N variant and what to consider during implementation, giving the tools to build up individual and tailor-made best-practices authorization concepts according to the use of the default values and with a one-time initial effort.
Table of Contents
Creation of a proposal data variant
First, execute transaction SU24N. Then select a transaction to update to create a proposal data variant. To be able to present a practical description of the check indicator, the separation of display and maintain in the context of transaction FS00 (G/L accounts master maintenance – central) is discussed here in the further detail. This is very important, because in many organizations the G/L account maintenance is often limited for a certain number of end users, but a large portion of users must be able to view this information. To identify proper authority-check statements, select transaction FS00 and execute the selection (Figure 1).
In the maintenance window, select the button for creating variants in the top menu navigation bar. Then assign a variant name and a short description. Make sure that the variant name starts with a customer namespace (e.g., Z or Y). In this case, the display variant of the FS00 is named Z_FS00_ANZ. When the proposal data variant is saved, a window opens to store the variant in the repository by means of an object catalog entry (Figure 2).
This not only enables the exact assignment of this proposal data variant within the repository and the corresponding developer package, but also the transport with the subsequent workbench order (Figure 3).
At this point, display values are maintained in the respective auth object fields of the created proposal data variant, as shown in Figure 4, 03 (display), 08 (display documents), or F4 (F4 help).
The same can be done for the create/change proposal data variant (Z_FS00_ANL_AEN) of the tcode FS00 where two variants are now showing below the standard transaction FS00 after completion of the activity (Figure 5).
Integration of the proposal data variant into a role
Now, the first two proposal data variants have been created. The variant can now be brought into the respective roles as a standard authorization object (preferably job function roles as a reference role). There is virtually no technical implementation for the corresponding proposal data variant to take effect. As a result, their respective characteristics can be automatically integrated into the profile in the next steps of maintenance of the technical role by the expert mode processing function of the authorization profile, without additional effort thanks to default value variants.
To do this, execute transaction PFCG. For existing job function roles, e.g., in the area of financial accounting (key users), the FS00 is usually already included, at least in the context of best-practice role building. Otherwise, add the transaction code object via the role menu. To choose the appropriate SU24N proposal data variant, click on the new tab, “Application”, which contains all possible proposal data variants based on the stored transactions. Choose the new create/maintain variant and uncheck the option of the transaction FS00 without a variant listed. (Figure 6).
Representation of the authorization profile
Continue to the Authorizations tab of the role accessing the expert mode for profile generation and select “Read old status and merge with new data” in the Define Maintenance Type pop-up window. As a result, the system compares the current profile data with the proposal data according to transaction SU24N and recognizes that it has been updated due to the proposal data variant. This can also be validated by the where-used list of the respective authorization objects. An example of such a change during variant Z_FS00_ANL_AEN is the authorization object F_SKA1_KTP (Figure 7).
In the where-used list, the new proposal data variant identifies this authorization object including the field and values and no longer the values of the initial transaction FS00 (Figure 8). An additional column, “Application Variant”, is now available, and including the newly created variant, Z_FS00_ANL_AEN.
Result
This blog helps to understand how to create individual and customized authorization proposal data variants. This enables a tailor-made control of the authorization default values and authorizations within the individual job functions, not only reducing role maintenance effort considerably, but also guaranteeing the standard use of authorizations as well as the expandability of variants and roles during SAP upgrades.
To learn more about Xiting‘s best practices security concepts approach to role building or to receive comprehensive advice during an SAP S/4HANA authorization migration or an authorization redesign, Xiting is here to help. In addition, Xiting offers a variety of different services and products to support in the maintenance of authorizations in all SAP systems. See our Xiting live webinar on SAP authorizations with XAMS.
- Top Pain Points in SAP Fiori Authorizations and Their Solutions – An Experience Report - 27. November 2023
- The Risk Control Framework (CRAF) by Xiting AG – Put an end to critical authorizations and Segregation of Duties (SoD)! - 27. November 2023
- The TOP 20 SAP IT base tables with special protection requirements in SAP S/4HANA - 7. September 2023
