Stating the Functionality of System and User Statuses

The figure shows a basic example of the relationship between business processes and system status: When a production order is created, the status CRTD Created is set. In Created status, among other things, the order can be scheduled, a material availability check can be performed, and the order can be released (→ column Allowed Business Processes). However, it is not allowed, for example, to print the order and to post goods issues, confirmations and goods receipts (→ column Not Allowed Business Processes). If the order is released, the CRTD Created status is deleted and the REL Released status is set. Now, the previously forbidden business processes are allowed. However, due to the REL Released status, the order cannot be released again.

In the SAP S/4HANA standard, you can post a goods receipt for a production order as soon as the order was released. If you want to ensure that, for example, an order was completely manufactured before the warehouse clerk can post the goods receipt, you can implement this restriction without the necessity of additional programming by assigning a user status profile to a production order type. In our example, the assigned user status profile consists of two statuses GRNO and GROK: The status GRNO forbids posting of the goods receipt; the status GROK does not forbid posting of the goods receipt. The latter is automatically set once the order was confirmed.

We first consider a released order (upper part of the figure): The system status REL Released allows the confirmation of the order and the goods receipt, however, no sequence is specified in which these two business processes must be processed. In our scenario, however, the user status GRNO No Goods Receipt is set in addition. Due to the fact that GRNO forbids posting of the goods receipt, the user cannot post the goods receipt to this order unless the user status changed to GROK.

Now we confirm the order. The system is configured such that the confirmation posting automatically deletes the user status GRNO No Goods Receipt and sets the user status GROK Goods Receipt OK instead. Since the latter does not forbid posting of the goods receipt, the warehouse clerk can now post goods receipt for the production order.

As you can see in this simple example, you can leverage user statuses to forbid the execution of business processes which would be allowed in SAP standard. In addition, you can also automatically set a user status if a certain business process is performed in the system. As a consequence, you can, for example, enforce a sequence in which the user must execute two business processes. Alternatively, you could also define a list of conditions (each condition corresponds to one user status) which must be fulfilled before, for example, an order can be released.

Note

To use user statuses with production orders, you must define a status profiles and assign the status profile to the respective order type in the Customizing activity Define Status Profile. A status profile defines a) the available status values, b) whether status values are initially set, c) the sequence of status values, d) authorizations required to set the values, e) the allowed or forbidden business processes, and f) whether a status value is automatically set when a business process is executed.

In the example above, we limited our discussion to user status profiles on order header level. Since the operations of a production order also have a status management, you can also enrich the default operation status values with a customer-specific user status concept.