The technical background and rules for the merge process of authorizations are documented in SAP note
113290 - PFCG: Merge process for authorization data maintenance
To illustrate the described rules, here are some simple examples, which will help to explain the behavior of PFCG in the most common cases. Image/data in this document is from SAP internal systems, sample data, or demo systems. Any resemblance to real data is purely coincidental.
First thing to know is, how the status of the authorization fields and the entire authorization itself is set:
When an authorization initially is inserted automatically by the merge function, all fields and the authorization have the status ‘Standard’.
If the administrator enters values into an empty Standard field, the status changes to ‘Maintained’.
If the administrator enters values into a Standard field, where proposed values exist, the status changes to ‘Changed’.
If at least one field of an authorization has the status ‘Maintained’, the entire authorization gets the status ‘Maintained’. If at least one field of an authorization has the status ‘Changed’ the authorization gets the status ‘Changed’, no matter, if also fields with status ‘Maintained’ are contained.
With this knowledge we can know, how this authorization has been inserted initially:
This example contains the authorizations for a fictive transaction ZMERGE.
The authorization T-Y055125200 for object S_PROGRAM contains the fields P_GRUOUP and P_ACTION. Both have the status ‘Maintained’. That means, initially, when the authorization was created (Status ‘Standard’) both fields have been empty, means, the defined proposal in SU24 contained no values for those fields:
The administrator entered the value Z* to field P_GROUP (resulting in the status ‘Maintained’ then) and BTCSUBMIT into P_ACTION (resulting in the status ‘Maintained’ then also).
This is important to know!
A common case is now, that the system was updated with support packages or was upgraded.
This role is contained in the result of SU25 step 2c.
Or, the administrator performs any change to the content of the role menu, resulting in a new merge of the existing authorizations.
What happens is, that the existing authorization for S_PROGRAM gets ‘Deleted’ and replaced by a new authorization. It is not clear yet, why.
Let’s have a look at the new situation in PFCG after the merge:
In the right frame we can see that the old authorization with status ‘Maintained’ is deleted (mind the technical name of the authorizations to see the change. Old: T-Y055125200 vs. New: T-Y055125201).
In the main frame we can see that a new authorization with status ‘Standard’ is inserted, with the value BTCSUBMIT in the field P_ACTION.
One main rule described in SAP note 113290 for existing authorizations with status ‘Maintained’ is:
The authorization remains, if the same fields of the actual SU24-proposal are filled with values as in the original authorization (= the standard authorization, which was entered during the initial merge in the past) of the existing authorization.
This condition is not met in the above example, as the field P_ACTION contains (now) a value in the SU24 proposal.
When the old authorization T-Y055125200 was created, both proposal fields have been empty. We know that, as the old authorization had both fields filled with values and the field status have been ‘Maintained’. (Remind above mentioned behavior: empty standard field, enter values->status is changed to ‘Maintained’)
The merge creates now a new standard authorization T-Y055125201, containing the actual SU24 values, visible in the left frame of above screenshot.
Actual SU24 values:
But why is the existing authorization deleted?
We know already that the original authorization has bee created from a proposal, where both fields of S_PROGARM contained no values (because both fields of the deleted authorization contained values and had the status ‘Maintained’).
But the actual proposal contains a value in field P_ACTION.
So, the merge cannot find a proposal for S_PROGRAM (with both fields empty) for the entries in the role menu. Therefore, this authorization is deleted. The merge cannot know that this old authorization belongs to the existing T-code. The merge checks only the actual proposals and not any history.
This is a typical behavior after an update/upgrade, when authorizationproposals are changed by SAP (SU22) and taken over into SU24 (with SU25 step 2a).
A similar behavior can be noticed of course if both fields in the proposal would contain these values:
P_ACTION = SUBMIT
P_GROUP = Z*
Based on the initial authorization from above:
The result after the merge is then:
It looks weird, that the existing authorization T-Y055125200 is deleted and a new authorization
T-Y055125201 is inserted – both having the same values! But only, if we would not know the above rules and the different maintenance status of the fields.
The new standard authorization is inserted as there exists no authorization, which’s original (with status ‘Standard’) had the same fields filled with values as the actual proposal (we know, that both fields of the original standard authorization and its proposal were empty, because both fields of the deleted authorization contained values and had the status ‘Maintained’).
Consequently because of the same reason the old authorization is deleted, as there is no entry in the role menu, which has a proposal for S_PROGRAM with both fields empty.
It does not matter, that the new standard authorization contains the same values, as the old, deleted authorization.
Special case: authorizations with status ‘Changed’
Authorizations with status ‘Changed’ exist if values of an existing Standard authorization are added or removed by the administrator.
Based on the last example with a proposal for both fields, P_GROUP = Z* and P_ACTION = BTCSUBMIT, the administrator has added a value SAP* to field P_GROUP. The old authorization looks then like this:
At the next merge of authorizations, the situation is then:
According to SAP note 113290 authorizations with status ‘Changed’ do not participate in the merge process. But the merge of the authorization data includes the authorization default value (standard authorization) once again, from which the changed authorization was generated. So as if the changed authorization would not exist at all.
As of the corrections of SAP note 2421626 – PFCG/PFCGMASSVAL: Improved handling of authorizations with the status “Changed”
for each authorization that switches to the maintenance status "Changed" because of a field value change, the transactions PFCG and PFCGMASSVAL automatically insert the relevant default authorization with the status "Standard inactive", unless at least one other authorization in the status "Standard" or "Maintained” exists for the same object and contains the authorization default value.
If that inactive standard authorization was not deleted, the repeated adding during the merge of the standard authorization can be avoided.
Related notes and KBAs:
KBA 2093228 - PFCG | display changes after merging authorizations - SAP Note 2086293 [VIDEO]
SAP Note 113290 - PFCG: Merge process for authorization data maintenance
SAP Note 1539556 - FAQ | Administration of authorization default values
SAP Note 2421626 – PFCG/PFCGMASSVAL: Improved handling of authorizations with the status “Changed”
SAP Note 2632422 - Authorization objects deleted after merging authorizations
I hope this blog helps a bit to understand some of the 'miracles' of the merge process in PFCG.