Introduction

Introduction: Whenever a user status is set or deleted, the user’s authorization to do so is checked. The status profile, the object type and the authorization key for the user status concerned are checked.

If, for example, you want to ensure that certain user statuses can be changed only by people in a particular group, you assign all those user statuses an authorization key.

Then use authorization object B_USERSTAT to give authorizations for those authorization keys. The authorization object hence links the user with the authorization key.

While working in the last project, came across the below requirement from the client.

Requestor creates the request. So, he shall be able to update notification, for status NSUB (Not Submitted). Then he sends the notification to the Expeditor by moving status to SUB(Submitted).
Once status is SUB, the Expeditor is supposed to update the notification so he should be able to update for SUB notification only. If something is missing, then user will move it to RTN (Return) to send it back to the Requestor. That’s why the requestor also must be able to update status RTN.

This is to restrict users to perform certain set of activity at a significant status in transaction beyond which they are not authorized. This helps in maintaining transaction untouched from users who are not a key decision maker.

Statuses can be defined in configuration in line with the business requirements.

• Prerequisites:

• User should have necessary authorization to define user status profile and authorization key.
• User status and Authorization key to be defined in the PFCG role.

Define status in configuration.

 2. Define Status Profile and Authorization key

• Define Status profile as Not Submitted NSUB, Submitted SUB and Returned RTN

For (NSUB/RTN) status profile YQM_YO_V   and for (SUB) status profile as YQM_YO_U

•     Define Authorization key as ZYO_REQ for NSUB and RTN and ZYO_EXP as SUB
•      Assign the authorization keys to required statuses and save your settings.

3. Define Authorization Role:

3.1) Authorization role is a predefined set of authorization object. These authorization objects administer the scope of work for user in system. Authorization roles are then assigned to user, so that to let them access the system.

We will define notification type in the Auth Object Q_QMEL – eg  YO notification.

3.2) Next, we will search or add authorization object B_USERSTAT in the role. Enter the details as activity, Authorization key, Object category and Status profile as shown in the screen shot.

In this way you can have any number of Authorization key and Status profile combination for one role.

 In the above image we are defining authorization key ZYO_EXP as Expeditor for status profile SUB.

Conclusion/Summary:

It summarizes the use authorization object B_USERSTAT to give authorizations for authorization keys.The authorization object hence links the user with the authorization key.

It also covers the steps that need to be followed for restricting users to modify status of transaction which user is not authorized.

Please let me know if needed any help or support. Please feel free to suggest if any correction will be there. Please do share your feedback and questions in comment box.