Lack of know-how
Define a user group as mandatory field in the user root
As the rolls pass, the value ranges for the field in question are searched within a role. Automatic cleanup occurs by writing both value ranges together in all fields. Therefore, you should clean up these entries before you start and create two different roles if necessary. The PFCG_ORGFIELD_CREATE report provides a test run that allows you to identify all the affected roles. The Status column provides an overview of the status of the permission values. If the status is yellow, there are different value ranges for the field within the role; the role must therefore be adjusted.
In the SCUA transaction, which you typically use to create or delete a ZBV distribution model, you can temporarily disable a subsidiary system. This option is disabled by default. To enable it, you must make changes in the customising of the PRGN_CUST table. Open the PRGN_CUST table either directly or via the customising in the SPRO transaction in the respective subsidiary system.
SAP Security Automation
Small companies would theoretically benefit from an authorization tool. However, in many cases the tools are too costly, so the cost-benefit ratio is usually not given.
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".
With "Shortcut for SAP systems" you can automate the assignment of roles after a go-live.
This is done based on evaluation paths in the org tree.
Before you enable the use of the SCC4 transaction setting for role maintenance, you should release existing role transports to avoid recording conflicts.