In the next screen (Figure 3) enter the line-item details, including material number (Material), quantity (Order Quantity), unit of measure (Unit), item category (ItCa), and plant (Plnt).

After you add details for the header and line item, click the save icon in the toolbar (not shown). After you select the save icon, you can view the sales order (e.g., 5011000045) in the Sales tab of the Display Standard Order Overview. To open this screen execute transaction code VA03 and follow menu path Logistics > Sales and Distribution > Sales > Order > Display (Figure 4).

Once created, but with no subsequent process steps completed, the sales order header statuses appear as shown in Figure 5. Credit status, overall blocking status, and system statuses may be different in other environments, depending on the configuration. For example, credit management configuration may result in the failure of the credit check, resulting in a blocked status. Failure of a credit check may be legitimate, but it also may be the result of an SD document not being configured for a credit check. Moreover, by using status profile management, release strategies for sales order documents may differ based on configuration and the use of authorization groups.

To view header statuses from the sales order overview screen while in sales order display mode (transaction code VA03), click the display header icon   in the Display Standard Order Overview screen (refer back to Figure 4).

When the header detail screen appears, click the Status tab to view header statuses (Figure 6).

In a VBUK table in sales and distribution, the fields are either blank or contain the values A, B, or C. To view table entries in VBUK, enter transaction code SE16 and follow menu path Tools > ABAP Workbench > Overview > Data Browser. In the Data Browser screen (not shown), enter table name VBUK and press Enter. On the next screen (not shown), enter the relevant document number and press Enter. The result for sales order 5011000045 is shown in Figure 7.

To view line-item statuses within a sales order, double-click a line item in the Display Standard Order: Overview screen (Figure 4), and in the next screen (Figure 6), click the Status tab. In my example, I selected line item 10. You can view line-item statuses such as the one shown in Figure 8.

To view line-item statuses in VBUP, enter transaction code SE16 and follow menu path Tools > ABAP Workbench > Overview > Data Browser. In the Data Browser screen (not shown) enter table name VBUP and the applicable document number. Press Enter to save your entries. The corresponding values in table VBUP are shown in Figure 9.

If you review the line-item statuses now, at first glance, the header and line-item statuses appear to contain inconsistencies. They have slight differences in the overall status and rejection status. If you trace the header and line-item statuses back to their data sources, the overall status at the header and line-item levels both use the same data element, GBSTA_BEZ, in table structure VBSTT. Yet, the descriptions and table values are different. At the header level, table VBUK contains the value B, and the header status description is Being processed. At the line-item level, table VBUP contains the value A, and the line-item status description is Open.

In this case, you might expect overall statuses to be consistent, prior to any subsequent process steps. However, the variance can be attributed to the difference in function at the header level versus the line-item level. After you execute subsequent functions, such as picking and billing, further divergence in values and descriptions is expected. 

For rejection, both VBUK and VBUP contain value A. However, in the Status tabs, the header and line-item descriptions are different. The header status is Nothing rejected, whereas at the line-item level, the reason for rejection is blank. Again, if you trace back through the data elements, these are two different fields. The header status uses data element ABSTA_BEZ in table structure VBSTT, but the line item uses data element ABGRU in VBAP. 

This example demonstrates the importance of carefully deciphering similar field labels and tracing back to the data source, if necessary, through the data element.

Step 2. Create Outbound Delivery and Picking

After you create a sales order, the next process step is outbound delivery. Delivery includes picking, loading, transporting, and moving goods. For simplicity, this example is limited to picking and moving goods (i.e., posting a goods issue).

To create an outbound delivery document, execute transaction code VL01N and follow menu path Logistics > Sales and Distribution > Sales > Order > Subsequent functions > Outbound delivery. The initial screen in VL01N is automatically populated with reference details from the sales order (Figure 10).

If you select the Status Overview tab prior to picking, all statuses are displayed with the value A (not yet processed) as shown in Figure 11. 

Next, picking was completed for line-item 10 only, and the document statuses are automatically updated (Figure 12). The overall statuses (top section) changed from A to B for picking status and pick confirmation. In addition, the line-item 10 delivery item statuses (the bottom section) changed from A to C for picking and confirmation, while values for lines 20 through 40 remained unchanged. 

Both the outbound delivery document, 5061000469, and picking request, 20140530, were created and subsequently appear in document flow as shown in Figure 13.

   

The outbound delivery document has triggered document status changes not only in its document but also in the sales order. As shown in Figure 14, the sales order header delivery status has changed from Not delivered to Partially delivered.

The value in table VBUK for delivery status also changed from A to B (Figure 15). It remains in this status until all line items in the sales order have been picked.

Sales order line-item statuses were also updated. For line 10, delivery status changed from Not delivered to Fully delivered because the full amount has been picked for the line item (Figure 16). Had the line been partially picked, the status would be Partially delivered.

The value in VBUP for delivery status also correctly changed from A to C (Figure 17) for line-item 10.  However, the delivery statuses for lines 20 and 30 were incorrectly changed from A to C, and line 40 was incorrectly changed from A to B.  Yet, as previously shown in Figure 12, the outbound delivery document was updated accurately for all lines, with pick status and confirmation set to C for line-item 10 only. This is an example of how document statuses can sometimes be updated incorrectly. 

Workaround: Instead of relying on sales order statuses in table VBUP, use the picking statuses in the delivery document, which are maintained separately in VBUP. As shown in Figure 18, delivery document statuses in table VBUP contain the correct values for picking statuses. Use this workaround in coding specifications. In addition, if standard reports are used, ensure this is the data source used for the picking status.

Step 3. Post Goods Issue 

In this step, a goods issue was posted using transaction code VL02N. In this example, all line items in the sales order were picked, followed by posting goods issue (PGI). Both picking and PGI are completed in the Picking tab within the outbound delivery document by entering a value in the field under the Picked Quantity column and selecting the Post Goods Issue button as shown in Figure 19.

These updates triggered status updates within the outbound delivery document. As shown in Figure 20, the overall statuses (top section) now show C (complete) for overall pick status, confirmation, and total goods movement. 

In this step, the goods movement status is not updated in table VBUP for the sales order document.

Workaround: Instead of relying on sales order status in VBUP, use the goods movement statuses in the delivery document. As shown in Figure 21, delivery document statuses in VBUP contain the correct values for goods movement. Use this workaround in coding specifications. In addition, if standard reports are used, ensure this is the data source used for goods movement statuses.

Step 4. Create a Billing Document

To create a billing document, execute transaction code VF01 and follow menu path Logistics > Sales and Distribution > Sales > Order > Subsequent functions > Billing Document. In my example I created billing document 5091000186 using transaction code VF01. In the screen that appears, enter data in the Billing Type and Billing Date field. Enter the sales order document number in the field in the Document column. Click the execute icon (Figure 22). 

After you create the billing document, it appears in the document flow as shown in Figure 23.

Executing the billing process creates an invoice document in SD and a partner document in FI. The billing document triggers updates to the preceding documents in the document flow. In this example, no change has occurred within the sales order header or line-item statuses. However, billing did create a separate table entry in VBUK for outbound delivery document 5061000469, in which the billing status and overall status values are C (Figure 24).

Billing has also updated the outbound delivery document statuses. If you execute transaction code VL02N again and click the Status Overview tab of the screen that appears (Figure 25), you see that the billing statuses are updated with value C.

In this step, the billing statuses are not updated in VBUK (Figure 26) or VBUP (Figure 27) for sales order 5011000045. 

Workaround: Instead of relying on sales order status in VBUP, use the billing statuses in the delivery document. As shown in Figure 28, delivery document statuses in VBUP contain the correct values for billing status. 

In addition, in VBUK the billing document has a separate entry with the correct billing status, as shown previously in Figure 24.

Step 5. Post Incoming Payment 

An incoming payment is processed through FI. In turn, document flow in SD is updated to show the accounting document has cleared (Figure 29). To view document flow for a sales order, display the order by executing transaction code VA03.  While in display mode, from the pull-down menu select Environment > Display document flow and press Enter.  

There tends to be confusion regarding why SD billing creates two invoice documents.  Billing creates an SD bill and an FI invoice, but both are referred to as invoices. Although they have the same document number, they are in fact two separate documents. The FI invoice serves to feed accounting in creating an open receivable, whereas the SD document is used for billing purposes.  It is the FI invoice that is cleared when the customer payment is received and posted.   

Use the workarounds presented throughout this section in coding specifications. In addition, if standard reports are used, ensure that the data sources used are correct. For additional header statuses, also consider referencing them in table VBAKUK when appropriate.

For custom reports, coding these workarounds requires use of the document flow table VBFA. This table is used to reference document numbers, which, in turn, are used to provide delivery document statuses from VBUP. The ABAP code shown in Figure 30 provides the goods movement status using this approach. To do so, it uses the sales order number as the reference document in table VBFA to retrieve the associated outbound delivery document number. With the delivery document number in hand, the code fetches the goods movement statuses from VBUP.

Financial Reporting

Document statuses are critical to sales order reporting. Understanding them plays an essential role in defining requirements and choosing a solution.

It is always best to use a standard report, if possible. With standard reports, document statuses may be available in the selection screen. You need to know how to use them, alone and in combinations.

An easy method to display standard SD reports is to use transaction code SARP.  Note that SARP isn’t in the SAP menu, but rather must be entered directly in the command field. After executing transaction code SARP, enter SD01 as the report tree and click the execute icon. The SD menu tree is shown in Figure 31.

In the Sales > Sales Orders folder (Figure 32), several SD reports exist, but you quickly find their limitations.  

For example, the List of Incomplete Sales Orders report is a useful tool for editing incomplete sales orders, but it provides no data selection for processing statuses.

The List of Sales Orders report provides the following options: Open sales orders, All orders, and My orders (Figure 33).  To execute this report, enter transaction code SARP directly in the command field. After executing transaction code SARP, enter SD01 as the report tree and click the execute icon. Open the Sales > Sales Orders folder and double-click the List of Sales Orders report to execute.  This report can also be accessed using transaction code VA05.

Digging into the report reveals that the option Open sales orders only checks the overall status at the header level. For effective open order reporting, a report needs flexibility to choose processing statuses at both the header and line-item levels. Moreover, this report could be more useful if the All orders option provided output sufficient to filtering by various header and line-item statuses, but it does not.

The report tree does offer good standard report options for reporting sales orders that are blocked or incomplete, but flexible reports using processing statuses are few. 

One such report that does offer some useful processing status selections is the Selection of Incomplete SD Documents report.  It is executed via transaction code V_UC.  Its selection screen has several document status fields to choose from. If the requirement is to provide a list of all incomplete sales orders, then it suffices to enter the following parameters: SD document category equals C, and overall status is not equal to C (Figure 34). 

Delving further into V_UC reveals some telling facts.  For the sake of simplicity, I use a simple service-related sales order with only one subsequent function: billing. In this example, sales order 1201 was created and billed (Figure 35).

Within the sales order, the billing status is complete. This is reflected by the presence of an invoice in document flow (Figure 35), in header statuses (Figure 36) in which overall status is Completed, and in line-item statuses (Figure 37) in which overall status also is Completed.

Yet, when V_UC is executed with document type C (i.e. sales order) and billing status C (Figure 38), sales order 1201 is not found (Figure 39).

The reason sales order 1201 was not found is because the billing status was never updated in tables VBUK and VBUP for the original sales order. See Figures 26 and Figure 27 for examples for sales order 5011000045.  As a result, in this example for sales order 1201, the V_UC report is misleading. 

To further emphasize the point, when billing status is not equal to C, as shown in Figure 40, sales order 1201 appears in the output (Figure 41). This demonstrates how critical it is to know the source of document statuses used in standard reports, custom reports, and queries.

Developing custom reports is more complex, but common because of the need for flexibility in the specification and use of document statuses. Data sources must be identified, based on the requirements. Often, complex table joins are necessary, as in the example shown in Figure 42. 

If designed properly, custom reports are also likely to contain several selection screen filters, requiring the end user to know, specifically, how to use these fields. Figure 43 is an example of a custom report selection screen for open orders reporting.

If necessary, the filters can be coded into the custom report, but doing so takes away flexibility.

In this section, you have seen that a comprehensive understanding of SD document statuses is needed, whether using standard or custom reports.  Remember that what you think you see is not always what you get.