VA03 — Display a sales order
VA03 opens a sales document in display mode. Nothing can be changed, which makes it the safe transaction for support, audit and analysis work: you read header and item data, conditions, schedule lines, partners, status information and the document flow that shows which deliveries and invoices already exist for the order.
Display mode for sales documents: what to read, how to use the document flow, and why read-only access matters in support work.
Published 20 Sept 2026· 718 words
Esta página ainda não está disponível em português.
What VA03 is for
VA03 shows one sales document exactly as it is stored, with no possibility of changing it. That restriction is the point. Support analysts, auditors, finance users and consultants investigating an issue need to see what was agreed, what was confirmed and what has already flowed downstream, without any risk of triggering a pricing update or a requirement change by accident. It is also the transaction most often granted broadly, because read access to sales documents is far easier to justify in an authorisation concept than change access to the same data.
When it is used in order-to-cash
VA03 is the natural first step in almost every order-to-cash investigation. When a customer says an order was never delivered, when finance asks why an invoice value differs from what the customer expected, or when a delivery cannot be created, the answer usually starts in the document as saved: the confirmed schedule line, the condition that determined the price, the block that stopped processing, or the follow-on documents already created. Consultants also use it during testing and cutover to verify that an interface or a migration produced the document the design intended.
How it is used in practice
Open the document by number, or search by customer, material or customer purchase order reference. Read the header for terms, partners and overall status, the item view for materials, quantities, plants and rejection reasons, and the schedule lines for dates and confirmed quantities. The condition view explains the price rather than merely stating it, which is what pricing disputes actually need. The document flow is the most useful single view: it shows deliveries, goods issues and billing documents created from the order and their processing status, so you can tell whether the problem is in sales, in shipping or in billing before touching anything. On S/4HANA the same document can also be inspected through Fiori sales apps.
Fields and objects that matter
- Sales document number and sales document type, which set the rules the document follows
- Overall processing status and any block, the quickest explanation of why nothing is moving
- Confirmed quantity and delivery date on the schedule line, as opposed to the quantity the customer requested
- Condition detail at header and item level, which shows how the net value was determined
- Document flow, listing the delivery, goods issue and billing documents already created
- Sales document header VBAK, item data VBAP and schedule lines VBEP, the data being displayed
How to prove it in the data
Use VA03 to establish the document state, then verify VBAK/VBAP, VBEP, pricing data and VBFA document flow. On S/4HANA, use status fields in the corresponding sales-document header/item data rather than treating VBUK/VBUP as persistence tables. Compare the same order, item and requested/confirmed dates throughout the analysis.
ECC vs S/4HANA
VA03 remains a current S/4HANA sales-order display transaction. The important technical change is the simplified SD data model: VBUK/VBUP status persistence was eliminated and relevant status fields were moved to document header/item tables such as VBAK/VBAP.
Common pitfalls and how they show up
- Reading the requested quantity and reporting it as confirmed, which sends the wrong answer back to the customer
- Concluding an order was never invoiced without opening the document flow
- Comparing a price against a quotation without checking which condition actually applied
- Assuming display access is harmless from a data-protection point of view; customer and pricing data is still sensitive
- Investigating a rejected line as if it were open, when the rejection reason already explains the missing delivery
- Working from a printout instead of the live document while several changes are being made the same day
Whose problem this is
Primary ownership is SD/O2C. Use VA03 as the read-only starting point, then hand off to ATP/MM, warehouse, Finance, Security or ABAP only after document flow and status evidence identifies the owning component.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Learn this properly
Lessons and topics
Source: ERPClimb — https://erpclimb.com/sap-tcodes/va03ERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.