Skip to Content

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’:

http://scn.sap.com/community/it-management/alm/solution-manager/blog/2012/07/31/status-flow-of-the-request-for-change-including-approval-procedure-and-charm-framework

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’ ).

authority issue.png

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.

/wp-content/uploads/2013/06/min_227613.png

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…

changed status.png

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.

status history.png

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.

/wp-content/uploads/2013/06/badi_227660.png

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).

SMCRHEAD.png

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.

BS33.png

You can search for CAAP and see it approves the approval procedure. But what does it really do in the background?

BS33 2.png

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.

system status .png

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…

where -used.png

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

system status 2.png

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.

To report this post you need to login first.

7 Comments

You must be Logged on to comment or reply to a post.

  1. Anton Malaiko

    it is not clear for me, in point 3) following the same logic, how system allow change status from ‘Hard Release Approval’ to ‘UAL’ while 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 ‘UAL’ (30).

    (0) 
    1. Michael Vollmer Post author

      Dear Anton,

      you are correct, when creating the example, I oversaw this. I have adapted it. Thanks for the comment, now it should be clear.

      Best Michael

      (0) 
  2. Ravindran Pather

    Hi Guys

    i am inpmlemenyting the badi BADI_BUILD_MESSAGE for Notification in BPMon but the content defined in the Badi is not part of the Notification long text

    i am trying to bring in the Idoc number and text meesage for the errorounous Idoc

    Please can i get assistance for the abaper to bebug

    Thanks

    Ravi

    (0) 
  3. Juan-Carlos Garcia-Garavito

    Hi Michael.  Many thanks for this deep dive. 

    According to item 5, could then we create our own transactions, like CAAP?.  Here is what we are trying to accomplish:

     

    We created a new phase in ZMMJ, but depending on certain criteria during phase “In Development”, we want the user to visualize only one of 2 possible phases:

    – “To be Tested” (standard from SAP today), or our new phase

    – “Dev Performance Test”.

    In order to accomplish that, when phase In Development is happening, at certain point we evaluate the criteria in our Change Document or in the RfC and based on that we could update table CRM_JEST for the Change Document with a new status, which will influence what the user can see when trying to move the Change Document to the next phase.

    Let’s clarify with an example. 

    1. We had previously added a Start or Schedule Condition in phase, e.g. “To be Tested”, like this:   &CRM Service Process.StatusTable& CE X3333

    2. Let say that certain criteria in our Change Document “In Development”, makes that the new status occurs:  X3333. 

    3. When that happens, we update table CRM_JEST for the Change Document with that status X3333.  

    4.  After that is done, then we are fulfilling the Schedule or Start Condition and therefore, when the user tries to change the phase, the only phase he should see is “To be Tested”.

    In theory this can be done, but I do not see how can we add new transactions like CAAP.  We are going to keep digging, but if you know if that is feasible, could you confirm or even suggest another path?

    Many thanks indeed for your time,

    Juan Carlos Garcia Garavito 

    (0) 
    1. Juan-Carlos Garcia-Garavito

      An update:

      After digging a little more we think we found the solution.  It all involves transactions BS32, BS22 and BS12, in that order, to create the Business Transaction and Statuses mentioned above.    

      Then, after having made the entries in CRMC_ACTION_CONF, we are ready to test.  For that, function module BBP_PROCDOC_STATUS_CHANGE can be used to change a document status.   Once that is done, in theory, the Action Definition: Start or Scheduled Condition is triggered.

      Now we have to test all that beauty!!!  

      Michael:  I never thought I was going to get that deep in the configuration of all this.

      Regards and thanks again for the tip.

      Juan

      (0) 

Leave a Reply