VA12 — Change Sales Inquiry

VA12 opens an existing sales document of type IN (inquiry) for change. An inquiry carries header data, items, quantities and validity dates like any sales document, and it can hold pricing conditions, but it has no delivery or billing relevance of its own. The structural fact that causes most confusion: an inquiry behaves like a full sales order in the transaction (same screens, same item category logic, same pricing procedure determination) but exists purely as a record of a customer request. Changing it after a quotation or order has already been copied from it does nothing to that downstream document. Consultants coming from order processing expect changes to cascade; they do not, because copy control runs once, at creation of the follow-on document, not continuously.

Used in the earliest stage of the order-to-cash cycle, before a binding quotation exists, when a customer asks what something would cost or whether it is available and the answer needs to be recorded rather than just quoted verbally. A sales rep or inside sales admin reaches for VA12 to correct quantities, extend an expired validity period, add a partner, or fix pricing on an inquiry that was saved with wrong data. Many implementations skip the inquiry step entirely and start the pre-sales cycle at the quotation, so VA12 sees far less traffic than VA22 or VA42 in practice. There is no dedicated Fiori app for inquiry maintenance in common use; this remains a classic GUI transaction even on S/4HANA.

Pull VBAK filtered on AUART equals IN and the document number or sold-to party in question to confirm the document is genuinely an inquiry and check its validity dates and deletion status. Join to VBAP on VBELN to see current item quantities and rejection reasons. Query VBFA with VBELV equal to the inquiry number to list every follow-on document created from it and compare the copied values against the current VBAP values; a mismatch confirms the change happened after the copy ran. Pull CDHDR/CDPOS on object VERKBELEG for the document number to see the exact field-level change history and who made it.

The transaction and the underlying document type IN are unchanged on S/4HANA; VA12 still runs as a classic GUI transaction. The main technical difference is that pricing condition records sit in PRCD_ELEMENTS rather than KONV, which matters for anyone querying pricing data directly but not for day-to-day use of the transaction. No standard Fiori app replaces inquiry maintenance; organizations that use inquiries at all typically keep this step entirely in SAP GUI.

Functional SD, owned by whoever configures sales document types and pricing for the pre-sales cycle. ABAP involvement is limited to custom pricing routines or user exits touching inquiry processing. A clean handover includes the inquiry number, the document type, whether a follow-on document already exists per VBFA, and the specific field or price the user believes is wrong.

VA11 and VA13 are the create and display counterparts for the same document type and share the same pitfalls around pricing refresh and validity. VA21, VA22 and VA23 are the quotation-level equivalents and are the more common target once an inquiry item is accepted; understanding copy control from inquiry to quotation is the natural next topic. VOV8 holds the document type configuration that governs validity period defaults and copy control behavior referenced in the pitfalls above. VK11, VK12 and VK13 are where the underlying pricing condition records live if a price discrepancy on the inquiry traces back to a condition record rather than to the document itself.