The setting of a particular user status allows or restricts certain operations to be performed. For example, under Plant Maintenance, an order or notification cannot be released until a certain status is set, and in order to reach that status, other statuses must first be reached through the completion of certain tasks or activities. Understanding how status profiles are setup will assist with troubleshooting, security unit testing, and overall security design for statuses.
In Enterprise Asset Management, each order can only be associated with one status profile, though a status profile can be associated with many orders. An order is not required to be associated with a status profile.
Below are some helpful tables when setting up the SAP user status security:
Useful Transactions for Security
OIOG – Maintenance Order Status Profile
BS02/OIBS – Maintain Status Profiles
BS03 – Display Status Profiles
OIOA – Order Types
TJ10 – Authorization Keys in Status Management
TJ20 – Status profiles
TJ21 – Permitted object types for status profile
TJ30 – User Status
T003O – Order Types
TQ80 – Notification types
OIOG – This transaction shows all status profiles that are associated with its respective order.
BS02/OIBS/BS03 – Transaction shows all defined status profiles
TJ10 – Table shows all defined authorization keys
TJ20 – Table shows all defined status profiles
TJ21 – Table shows permitted object types for status profiles
TJ30 – Lists status profiles and its associated user statuses along with the authorization key.
T0030 – Similar to transaction OIOG, this lists all orders and its respective status profile
TQ80 – Similar to table T0030 except for notifications.
Sequential and Non-sequential User Statuses
Sequential User Statuses – Only one status can be set at one time, in some cases, the statuses must be set in a particular order.
Non-sequential statuses – These statuses can be set at any time. Multiple statuses can be set at the same time as well.
At the very bottom, the status profile associated with the order is listed. Only one status profile can be associated with an order, though the status profile may be used in more than one order
The B_USERSTAT Authorization Object
The B_USERSTAT authorization object is the primary authorization object that is used to control access to the statuses.
Activity – This field has only two options. A value of 01 allows for the setting of a status and a value of 06 is to delete/remove the status. The removing of status authorization applies mainly to non-sequential user statuses (where check boxes are used). In sequential user statuses, the selection of another status does not call an authorization check on activity 06 on the deselected status. It will only call an authorization check for activity 01 for the new status selected and if it is allowed.
Authorization Key – This will give the user access to the specified authorization key. Values here correspond to table TJ10. Authorizations are used to restrict user statuses in the status profiles (table TJ30). Some authorization keys are never configured into our Security rules. This is usually done when statuses are never to be changed or done solely by an interface.
Object Category – Depending on the where the status profile is used, the above example only gives the user access to status profiles that are associated with maintenance orders (ORI). Some statuses may be used in multiple object categories. You can look up which object categories the status profile may be used in table TJ21.
Status Profile – This field allows access to specified status profiles. If the user does not have access to the status profile, the user will not be able to set the status whether or not an auth key is assigned to the user status or not.
The picture below is an overview of table TJ30. This table will assist with identifying which authorization keys are needed for each user statuses and whether one is defined.
- Name of status profile
- Status Number
- Highest Status Number
- Lowest Status Number
- Authorization Key
- Status Description
Note the Status Number, Highest Status Number, and Lowest Status Number columns. Those statuses that do not have a number indicated are known as non-sequential user statuses and those with a number are known as sequential user statuses.
Troubleshooting User Statuses
Users may mistaken SAP error messages as Security errors. If a user is unable to set a status, we should first determine if setting that particular status is allowed based on its current status. If you only have the order type and the user status the error is occurring on, you can check table T003O for the status profile, then look up the particular status via table TJ30 (for orders) or TQ80 (for notifications). This will tell you whether it could possibly be a security error, configuration, or user error.
The table below is pulled from TJ30 for sequential user statuses found in the ZORDER01 status profile.
|StatusProfile||Status Number||High||Low||Auth key||Status||Status Description|
|ZORDER01||20||25||20||RPLN||Needs to be Replanned|
|ZORDER01||30||40||25||WIP||Work in Progress|
|ZORDER01||35||40||30||PFT||Perform Functional Test|
For this profile ZORDER01, initial status is set as INPL. From INPL, the status can be set only to PLND. From PLND, you can go back to INPL or to RPLN or SCHD. Once it goes to RPLN, it cannot go back to PLND. The below diagram shows how the user statuses can be set. If the user tries to set a different status, the person will get an error that may appear to be a Security error. From TJ30, you can determine whether it is a legitimate Security error or configuration error for these user statuses.
From configuration, a user cannot set to WIP from RPLN, PFT from SCHD, WIP from PLND, etc. User may receive an error if they try to set the statuses like so. From configuration, we can see that it is not a Security error.
Because EAM sometimes rely heavily on the B_USERSTAT security authorization, it is imperative that other security team members consult the EAM security resource before configuring other security roles with this auth object. A user with the right combination of roles containing a starred out (*) B_USERSTAT authorization could cause problems for the EAM team.