SAP VA01

It creates a sales order, the central SD document capturing a customer’s request to buy, and starts the order-to-cash process.

• Order type; sales area (sales org/channel/division).
• Sold-to and ship-to party (customer).
• Material, quantity, requested delivery date.
• Pricing, availability (ATP) and credit check results.

A sales order is a document that pulls together several pieces of master data and configuration, and almost every failure on the entry screen is one of them missing. In the order they are checked:

• The sales area exists and is assigned. Sales organisation, distribution channel and division, with the plant and company code assignments behind them.
• The customer is extended to that sales area. A customer created for one sales area is invisible in another. This is the single most common "customer does not exist" report.
• The material is extended to the sales organisation and the plant. Sales views on the material master, not just basic data.
• Condition records exist for the pricing procedure the order type resolves to. Missing records give a price of zero or a pricing error rather than a blocked order.
• The order type is configured and permitted for that sales area, with its number range, its document flow and its incompletion procedure.

Worth knowing the order in which these are read, because the error message names the last thing checked rather than the underlying cause.

• Reference a quotation or contract to prefill.
• Check availability and credit status before saving.
• Watch for incompletion log entries that block later steps.

Two more that save time on a real system. The incompletion log is reachable from the order and lists exactly which fields are missing, which is faster than reading the error at save time. And document flow from the order shows everything downstream, which is how you answer whether an order was delivered and invoiced without leaving the transaction.

Saving the order creates rows across several tables, and knowing which is which turns a vague question into a query.

• VBAK the header: order number, type, sales area, sold to, dates, net value.
• VBAP the items: material, quantity, plant, item category.
• VBEP the schedule lines: confirmed quantities and dates, which is where the availability check result lands.
• VBPA the partners: sold to, ship to, bill to, payer, and any others the partner determination added.
• VBKD the business data: payment terms, incoterms, at header and item level.
• VBFA the document flow, once anything follows the order.

The distinction that catches people: the item is not the promise. VBAP says what was ordered and VBEP says what the system confirmed and when, so an order with a line item and no confirmed schedule line is an order the system has not committed to deliver.

• Incomplete order (missing required data) blocking delivery.
• Credit block if the customer exceeds their limit.
• Pricing errors from missing condition records.

The rest of the set, and where the process goes next. VA02 changes an order and VA03 displays it, and the display transaction is the one to give anybody who only needs to look, because change access to sales orders is not a small permission.

Downstream, the order becomes a delivery, then a goods issue, then a billing document, and each of those is a separate transaction with its own document number. See ME21N for the purchasing side of the same pattern and MM01 for the material master the order depends on.

Version note: on S/4HANA the transaction still exists and behaves as described, and the equivalent Fiori applications for creating and managing sales orders are the strategic path. The underlying tables are unchanged for VBAK and VBAP, while the status tables VBUK and VBUP were merged into the header and item tables, so older code and reports reading them will find nothing.

• Entering the order in the wrong sales area. It saves, it is valid, and it is invisible to the team that should process it. The sales area is set at the top of the first screen and almost nobody checks it after the first time.
• Reading the item as a promise. The quantity on the item is what the customer asked for. The confirmed schedule line is what the system will deliver, and they differ whenever availability is short.
• Overtyping a confirmed delivery date. Changing the date on the item does not change whether the stock exists. It changes what the customer is told, which is worse than a late order somebody knew about.
• Changing the sold to party after entering items. Pricing, partner determination and tax all derive from the customer, and not all of them re-run cleanly. Start again rather than edit.
• Ignoring the incompletion log because the order saved. An incomplete order saves and then blocks the delivery, which surfaces days later as a shipping problem rather than an order one.