Basis Errors and Solutions

Symptom

Changes to the role and/or profile assignments of a user cause profile assignments to disappear without the user administrator being informed about this by the system.
Only the end user notices the loss of authorizations since certain transactions can no longer be executed or cannot be executed without errors occurring.
In transaction SU01, this error can also occur when any changes are made to the user master.

Other terms

SU01, SU10, PFCG,
BAPI_USER_ACTGROUPS_ASSIGN, BAPI_USER_LOCACTGROUPS_ASSIGN,
BAPI_USER_PROFILES_ASSIGN, BAPI_USER_LOCPROFILES_ASSIGN

Reason and Prerequisites

This problem is caused by the different system behavior between saving and reading the profile assignments. While up to 311 profiles are written to the database when you save profile assignments, the system only considers 300 profiles when reading the profile assignments.

Solution

Use the Note Assistant to implement the correction instructions or import the relevant Support Package.

Caution:
If you want to use the correction instructions, you must carry out the following manual tasks:
1. Create the new SUSR_USER_PROFS_BUFFER_SAVECHK function module in the SUU2 function group (SUSR package) with the following attributes:

Attributes – Process type:
‘Normal function module’ and
‘Start immediately’Short text:
‘User/profile assignment object: Checks before saving’

Import:
Parameter name Type spec. Reference Type Optional
USERNAME TYPE XUBNAME X
USE_MESSAGE_TYPE TYPE BAPI_MTYPE
Pass Value Default value
X
X ‘E’
Short text
User name
Message type: S Success, E Error, W Warning, I Information, A AbortChanging:
Parameter name Type spec. Reference Type Optional Pass Value
RETURN TYPE BAPIRETTAB
Short text
Return structure
Caution:
Since the BAPIRETTAB table type is only available as of Release 6.10, you must use BAPIRET2_T as the reference type in Releases 4.6C and 4.6D.
The correction is now also available in Release 4.6B.
Since Release 4.6B does not contain any table type for the BAPIRET2 structure in the dictionary, you must create the following table entry in the interface of the function module instead of the changing entry:
Parameter name Type spec. Reference Type Optional Pass Value
RETURN LIKE BAPIRET2
The source code is implemented using the Note Assistant.2. Add the following import parameter to the interface of the function module SUSR_INTERFACE_PROF:
Parameter NamePTYPEType spec.TYPEReference TypeUSR10-TYPDefault value’G'OptionalYesPass ValueYes
If you use Basis Release 7. 00, Basis Release 6.40 with at least Support Package SAPKB64013, or Basis Release 6.20 with at least Support Package SAPKB62055 in your system, you neednotperform the following manual changes. If you use these releases, SNOTE makes the changes automatically.

You can only receive the changed short and long texts for message 263(01) with the Support Package.

Explanations for the new functions in the affected transactions:

Once this correction is implemented, the maximum possible number of 312 profiles per user can now be managed correctly. This limit is a default value determined by the length of the PROFS field in table USR04 and the maximum length of a profile name. This invalidates the previous limit of 300 profiles.
For design reasons, the maintenance transactions unfortunately behave differently for systems with and without Central User Administration (CUA) as soon as the number of possible profiles per user is exceeded:
1.Systems without CUASU01:
The administrator cannot save a user if the number of profiles is higher than 312. Control reverts to change mode. To allow other roles/profiles to be deleted, the roles/profiles that are newly assigned prior to the error message appears out are not automatically removed from the display.SU10:
The desired changes made to the role and/or profile assignment of a user are not applied. The corresponding error message appears in level 3 of the log.
All other changes to this user are implemented.PFCG (with direct assignment of users to a role and with indirect assignments from the HR):
If you want to assign a user who already has 312 assigned profiles to a new role, the user master comparison prevents additional profiles from being assigned to the user.PFUD (with AUTO_USERCOMPARE=NO and indirect assignment from the HR):
(see PFCG)BAPI interface
(BAPI_USER_ACTGROUPS_ASSIGN and BAPI_USER_PROFILES_ASSIGN):
If the list of roles and/or profiles exceeds the 312 limit, no change is made. The RETURN table contains the corresponding error message 01 263.2.Systems with CUAa)CUA child system
If the SCUM settings (distribution parameters of the CUA) for roles/profiles are set to’Local’, the child system behaves like a system without CUA.
However, if these are set to’Global’:only indirect role assignments can be set locally by means of HR. Here, the child system reacts in the same way as in a system without CUA. Transactions SU01, SU10 and PFCG do not allow any direct profile and/or role assignments.the change requests that arrived by IDoc are rejected and the error 01 263 is returned to the central CUA system, which is then visible to this user in transaction SCUL.b)Central CUA system
If the SCUM settings (distribution parameters of the CUA) for roles/profiles are set to’Local’, the child system behaves like a system without CUA.
However, if these are set to’Global’, the following applies to transactions SU01, SU10 and the BAPIs BAPI_USER_LOCACTGROUPS_ASSIGN and BAPI_USER_LOCPROFILES_ASSIGN:
The design for the CUA makes it impossible to have the same behavior as in a system without CUA.All changes are accepted and distributed. Only the update in the corresponding child system recognizes the error and verifies it. The required changes to the roles and/or profile assignments are not applied. This also applies to roles and/or profile assignments for the central system itself.Caution:
The changes made in the central system to roles and/or profile assignments are stored in the tables for the Central User Administration (USL04 and USLA04). If these change requests were rejected by child systems because the maximum number of profiles per user was exceeded, these table entries cannot automatically be undone due to the design of the system. The visible information in transaction SU01 in the central system, therefore, no longer corresponds with the actual status in the child systems.
In this case, you must undoallchanges that you made to the role and/or profile assignments.
The corrections from Note 704412 allow you to eliminate this inconsistency for the affected users as of Release 6.20. To do this, use the new function of transaction SCUG that was provided with Note 704412 to import role and profile assignments again.
This function is only available in the central CUA system if you implemented the corrections specified in Note 847295.
Unlike a CUA child system, the ‘User’ tab page is ready for input in transaction PFCG in the central CUA system.
When you assign a user to this role, a local role assignment is always created in the central CUA system, regardless of the content of the ‘Target system’ field in the ‘Menu’ tab page (see also Note 511200). The system reacts as it would without a CUA. In addition, the tables of the CUA (USL04 and USLA04) are also adjusted.