Organisationally restrict table editing permissions
User master data
After you have determined the data for the website, you must now generate the initial password and send it by e-mail and unlock the user if necessary. There are also different solutions - we describe a possible course of action. You can generate a password using the GENERATE_PWD import parameter of the BAPI BAPI_USER_CHANGE. The generated password is then set as the initial password and must be changed at the next login by the user. You must also set the PASSWORDX import parameter to display a password change. The generated password is returned using the export parameter GENERATED_PASSWORD. This is required if you want to call the BAPI BAPI_USER_CHANGE from a central system (e.g. from the ZBV) and send the relevant e-mail from that system. You should never save this password, but include it directly in your application in an email. Subsequently, you send this e-mail to the user whose e-mail address you can determine either directly in the SAP system (parameter ADDSMTP of BAPI_USER_GET_DETAIL) or within the scope of your web application (e.g. from the AD). Even if you find the email address in the AD, we advise you not to send the email from there. To avoid the password being unnecessarily transferred, it is better to initiate the despatch within your central SAPS system. In addition, we strongly advise you to send the emails encrypted with the initial passwords. To do this, the implementation of your self-service must set the encryption flag when creating the email. We describe details about the encryption of emails and an alternative sending of the initial password directly from the affected SAP system in Tip 98, "Encrypt emails".
First, select the authorization object that you want to maintain. There can be multiple permissions for each authorization object. Then load the trace data by clicking the Evaluate Trace button. A new window will open again, where you can set the evaluation criteria for the trace and limit the filter for applications either to applications in the menu or to all applications. Once the trace has been evaluated, you will be presented with all checked permission values for the selected authorization object. With the Apply button, you can now take the values line by line, column by column, or field by field. In the left part of the window, you will see the permission values added to the suggestion values already visible. After confirming these entries, you will be returned to the detail view of your role. You can see here the additions to the permission values for your authorization object.
Set password parameters and valid password characters
You know that changing your SU24 data involves mixing the roles in question. Previously, the permission administrators had to select roles from, for example, the SUIM transaction to edit them. Often, the remixing of the respective roles is also forgotten. In order to ensure that you can set the mixing mode for the respective roles directly when maintaining the data in the transaction SU24, the function has been provided here with the respective support packages named in SAP Note 1896191. Correction is used to change the mixing mode for PFCG: On/Off/Roles. The function assigns the shuffle mode to the roles, which corresponds to step 2c of the transaction SU25 (see tip 43, "Customise Permissions After an Upgrade"). You can enable this function by using the value Y for the parameter SU2X_SET_FORCE_MIX in the table PRGN_CUST. The status of the mixing mode can be checked by clicking the button Mixing mode for PFCG: Enquire On/Off. By default, this feature is off. The Roles button (Use in Single Roles) identifies all the roles that the selected application contains and displays them directly in the SU24 transaction. You will receive a list of all matching roles in the SUPC transaction by selecting the Also-to-be-matched roles option, and you can now gradually update the roles.
The chapter on authorization recertification should also be defined in the authorization concept, which is documented in writing. This refers to a regular review of the assigned authorizations in the SAP® system, to be performed at least once a year. 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. This process ultimately ensures that users only have the authorizations in the SAP® system that they actually need. It must therefore be defined in which time period and in which form the departments must receive the information about the assigned authorizations and report back regarding the correctness of the assignment. During preparation, it is therefore necessary to check whether the process has been carried out in accordance with the internal specifications, but also in accordance with possible suggestions for optimization made by the auditor, and whether all the evidence is stored ready to hand for the auditor.
If you get into the situation that authorizations are required that were not considered in the role concept, "Shortcut for SAP systems" allows you to assign the complete authorization for the respective authorization object.
SAP Basis is the foundation of any SAP system. You can find a lot of useful information about it on this page: www.sap-corner.de.
First, consider the transport of your proposed permissions from various development systems to a consolidation system.
So much information... how can you keep it so that you can find it again when you need it? That's what Scribble Papers is great for.
In most cases, an error message occurs and the programme is cancelled.