Professional Documents
Culture Documents
Cocept of Su24
Cocept of Su24
These tables hold the relationships between the particular transaction and its authorization objects. It is possible to add or subtract the checks performed in the transaction by changing the appropriate flag. The benefit of transaction SU24 occurs when transactions are added to or deleted from Role Groups using the Profile Generator. When new transactions are added, the Profile Generator will add all authorization values maintained in SU24 for the transaction(s). When deleting transaction the Profile Generator will remove all authorization values that are maintained in SU24 for the transaction. Activities performed: Check/Maintain Authorization Values Addition of Authorization Object to tcode Deletion of Authorization Object from tcode
Explanation The object will be inserted along with the values in the role. The object will be checked along with the values during runtime of the transaction. This object will not be inserted into the roles. A check on the object along with the values will be done during the runtime of the transaction The object will not be inserted into the roles and there will not be any check performed during runtime of the transaction
Check
NO
Check
Do not Check
NO
Do Not Check
Status Texts for authorizations Standard: All field values in the subordinate levels of the hierarchy are unchanged from the SAP defaults
Maintained: At least one field in the subordinate levels of the hierarchy was empty by default and has since been filled with a value Changed: The proposed value for at least one field in the subordinate levels of the hierarchy has been changed from the SAP default value. Manual: You maintained at least one authorization in the subordinate hierarchy levels manually (it was not proposed by the Profile Generator). Effect of SU24 changes in Role Groups Authorization objects are maintained in SU24 for a particular transaction code. When a transaction code is added to role, only the authorization objects having check as check indicator value and yes as proposal value, maintained for that tcode will be added into the role group. 1) Adding Tcodes to a role When a new Tcode is added to a role When a new tcode is added to a role, going in either change authorization data or expert mode provides the same result. All the authorizations maintained for the tcode at SU24 level is added to the role. The program adds new standard authorizations for objects in the roles If the authorization default values contain objects that were previously not existing Or only had authorizations in the status Changed or Manual A new standard authorization is not included if the authorization fields contain identical authorizations in the status Standard in both authorizations, and the fields maintained in the old authorizations are empty in the new standard authorization. If there were already authorizations in the status Maintained (active or inactive) or Inactive Standard before the merge, the program compares the values and the maintenance status of all authorization fields to determine whether new standard authorizations must be extended. Changing SU24 values for a tcode If the authorization data is changed for any tcode in SU24 and tcode is already present in the role, then going in the expert mode with option read old data and compare with new data will only reflect the additional changes. Change authorization data will not pull the new data for the tcode maintained at SU24 level 2) Removing Tcodes from the role
When you remove transactions from the role menu, this has the following effect on the authorizations. A standard authorization for which the associated transaction was removed from the role menu is removed during the merge, unless at least one other transaction that remains in the menu uses the same authorization default value. This applies both for active and inactive standard authorizations. Authorizations in the statuses Changed and Manual are not affected by the merge. They are therefore always retained. The table USOBX_C defines which authorization checks are to be performed within a transaction and which not (despite authority-check command programmed ). This table also determines which authorization checks are maintained in the Profile Generator. The table USOBT_C defines for each transaction and for each authorization object which default values an authorization created from the authorization object should have in the Profile Generator. WHEN TO USE SU24 To correct authorization objects that are not linked to transaction codes correctly To correct authorization objects that have unacceptable default values. To change default values to ones that will always be appropriate for all roles that will ever use the transaction. This means having blank fields where you need to allow different roles to have different values. SU22 V/S SU24 SU22 displays and updates the values in tables USOBT and USOBX, while SU24 does the same in tables USOBT_C and USOBX_C. The _C stands for Customer. The profile generator gets its data from the _C tables. In the USOBT and USOBX tables the values are the SAP standard values as shown in SU24. With SU25 one can (initially) transfer the USOBT values to the USOBT_C table. Usually the sap standard tables USOBX and USOBT are not allowed modifications so that we copy the customized tables from these tables so in order to copy the tables we need to go the transaction su25. su22 displays and update the values in standard tables USOBT, USOBX. su24 displays and update the values in customizing tables USOBT_C,
USOBX_C. Why SU25 is required? After upgrading SAP with the new release, you need to make adjustment to the all the roles and transaction codes.SU25 is the transaction code for upgrading profile generator. This has 6 different steps and the execution of these steps depends on whether you were already using profile generator in the last release.
This transaction has 6 steps. This transaction is used to fill the customer tables of the Profile Generator the first time the Profile Generator is used, or update the customer tables after an upgrade. The customers tables of the Profile Generator are used to add a copy of the SAP default values for the check indicators and fieldvalues. These check indicators and field values are maintained in transaction SU24. If you have made changes to check indicators, you can compare these with the SAP default values and adjust your check indicators as needed. Step1: If you have not yet used the Profile Generator or you want to add all SAP default values again, use the initial fill procedure for the customer tables. If you have used the Profile Generator in an earlier Release and want to compare the data with the new SAP defaults after an upgrade, use steps 2a to 2d. Execute the steps in the order specified here. -Step 2a: is used to prepare the comparison and must be executed first. -Step 2b - If you have made changes to check indicators or field values in transaction SU24, you can compare these with the new SAP default values. The values delivered by SAP are displayed next to the values you have chosen so that you can adjust them if necessary. If you double-click on the line, you can assign check indicators and field values. You maintain these as described in the documentation for transaction SU24. Note on the list of transactions to be checked To the right of the list you can see the status which showswhether or not a transaction has already been checked. At first the status is set to to be checked.If you choose the transaction in the change mode and then choose save, the status is automatically set to checked.By choosing the relevant menu option in the list of transactions you can manually set the status to checked without changing check indicators or field values, or even reset this status to to be checked.If you want to use the SAP default values for all the transactions that you have
not yet checked manually, you can choose the menu option to copy the remaining SAP default values. -Step 2c: You can determine which roles are affected by changes to authorization data. The corresponding authorization profiles need to be edited and regenerated. The affected roles are assigned the status profile comparison required. Alternatively you can dispense with editing the roles and manually assign the users the profile SAP_NEW (make sure the profile SAP_NEW only contains the subprofiles corresponding to your release upgrade. This profile contains authorizations for all new checks in existing transactions). The roles are assigned the status profile comparison required and can be modified at the next required change (for example, when the role menu is changed). This procedure is useful if a large number of roles are used as it allows you to modify each role as you have time. -Step 2d: Transactions in the R/3 System are occasionally replaced by one or more other transactions. This step is used to create a list of all roles that contain transactions replaced by one or more other transactions. The list includes the old and new transaction codes. You can replace the transactions in the roles as needed. Double-click the list to go to the role. Step 3: This step transports the changes made in steps 1, 2a, and 2b. Tailoring the Authorization ChecksThis area is used to make changes to the authorization checks. Changes to the check indicators are made in step 4. You can also go to step 4 by calling transaction SU24. -You can then change an authorization check within a transaction.-When a profile to grant the user authorization to execute a transaction is generated, the authorizations are only added to the Profile Generator when the check indicator is set to Check/Maintain.-If the check indicator is set to do not check, the system does not check the authorization object of the relevant transaction. -You can also edit authorization templates that can be added to the authorizations for a role in the Profile Generator. These are used to combine general authorizations that many users need. SAP delivers a number of templates that you can add directly to the role, or copy and then create your own templates, which you can also add to roles. In step 5 you can deactivate authorization objects systemwide. In step 6 you can create roles from authorization profiles that you generated