For customers, consultants and developers 😉
When a user status is changed via PPF action HF_SET_STATUS in the ChaRM Framework, sometimes the message 'You are not authorized to perform the activity selected last' comes up and the user status is reset.
A bit more information on the ChaRM Framework can be found here in the screenshot 'Request for Change - Standard Process Overview':
The message can have different reasons, described in note 1706259. As they are connected to wrong customizing or missing authority, I would like to give you some more information at hand, so the developers out there are able to analyze this for there own.
The possible reasons known to me are:
1.) authority B_USERSTAT
2.) status Lowest/Highest customizing
3.) status history
4.) Implemented Customer BadI Implementation for the User Status
1.) Missing authority for B_USERSTAT is the simplest thing. To check this via debugging set break-points (4 places) in class
CL_IM_CHM1_HF_CHECK_SET (set a break-point for all statements AUTHORITY-CHECK OBJECT 'B_USERSTAT' ).
2.) The Lowest/Highest Customizing defines if you are allowed to go from one user status to another user status. Each user status has a Status Number.
The Lowest - Highest value range defines to which status number you can go back from the current user status.
Take the example below. It is allowed to go from 'Approve Functional Spec' to 'Hard Release Approval', meaning from 15 to 35 because status 15 'Approve Functional is customized to allow next user status from 10 to 90 and 35 is in that range 'Hard Release Approval'.
But back from 'Hard Release Approval' (35) to 'Approve Functional Spec' (15) is not allowed because 'Hard Release Approval' (35) is only customized to set the next user status to 35 to 50 and 'Approve Functional Spec' (15) is out of range.
Please be aware that the user cannot jump to different user status without the customized PPF action to set the user status :-). So, this is just theoretically.
3.) Status history.
This is the most hardest case to explain. The status change history of a document is recorded. In our example again if we go from 'Create Functional Spec' (10) to lets say 'Hard Release Approval' (35) and then to 'Released for Production' (40) our status history from lowest to highest reads...
| Number | Status | Lowest | Highest |
|---|---|---|---|
| 10 | Create Functional Spec | 10 | 90 |
| 35 | 'Hard Release Approval' | 35 | 50 |
| 30 | Released for Production | 20 | 50 |
If I now try to go to 'Development & Unit Test (20) this is forbidden. From a Lower/Highest point of view user status 'Development & Unit Test (20) is allowed to be set because the range is 20-50 and 'Development & Unit Test (20) is in the range but the status history remembers that we were already in status 'Hard Release Approval' (35) and this status has a lowest/highest range customized from 35 to 50 and then this is out of range for 'Development & Unit Test (30).
Note 159553 describes this behaviour.
Then the error comes up like in the screenshot.
And unfortunately it is the same exception for 2.) The Lowest/Highest Customizing which makes it hard to create a specific message for the user.
4.) Implemented Customer BadI Implementation for the User Status
Be aware that there can be additionally BadI implementations for the BadI CRM_ORDER_STATUS which hinder user status change. Described in note 1627673 f.e.
Here is a taste of this :-)...it comes back with the same exception 2 NOT_ALLOWED as well.
The function CRM_ORDER_CHANGE_STATUS is hard to debug as it contains a lot of logic and layers, down from CRM to the user status management.
I had the feeling there are further issues not yet described or recognized by me which can lead to exception 2 NOT_ALLOWED and they have are connected with system status issues but as I was not able to understand and explain it in detail, I will skip this and leave this to more experienced colleagues,
Hope that sheds some light on the issue,
best,
Michael
More information:
I currently discussed my 'feelings' that there are further influences with another collague and I want to share this with you.
5.) If the User status sets an system status this can have further relations as well.
I want to explain this via another example. Take the user status profile of an the standard Request for Change (SMCRHEAD).
The user status 'Approved' (german: Genehmigt) has the 'CAAP' indicator assigned in the 'Transaction'
(User Status Triggers Business Transaction) column. The implications what happens behind can be checked if you choose 'Enviroment->Transactions' in this screen. Then transaction 'BS33' ('Transactions') is displayed which lists all the available transactions.
You can search for CAAP and see it approves the approval procedure. But what does it really do in the background?
If you double-click on the line, you get another screen, listing all the internal system statuses and which ones are set, deleted or not changed when this specific transaction 'CAAP' is set.
Most system status are uneffected but you can see, the system status 'I1385' for 'Approved' is set, the 'I1386' and 'I1387 for 'Rejected' and 'To Be Approved' are deleted. If you know set the cursor on the Business Transaction 'CAAP' field and choose the 'Where-used' icon, you get an overview screen which sheds some light on the dependencies...
Here, it is listed...
- which object types are supported
- which system status is set
- which system status is deleted
- and (important) which system status have dependencies which do not allow the setting of this business transaction
- where the business transaction is used in regard of user statuses in user status profiles
You can see that it is possible to set the 'CAAP' when the document is 'Open' (I1002) but not when it 'Contains Errors' (I1030).
In short that means if you have an standard Request for Change and it contains errors (error messages) you cannot set the status E0004 ('Approved') as the business transaction 'CAAP' cannot be set. This would lead to the same exception 2 NOT_ALLOWED.
- SAP Managed Tags:
7 Comments
