SAP transaction codeObjectVOV8ModuleSD_O2C

VOV8 — Sales Document Type Configuration

VOV8 maintains the customizing table (TVAK) that defines a sales document type - the code stored in AUART on every order, inquiry, quotation, or contract. It sets defaults for number range, delivery type, billing type, pricing procedure, credit check, and incompleteness procedure at document-type level. It does not control item category, which comes from a separate combination table.

This page covers VOV8, the transaction used to define and adjust sales document type behavior in SD. It focuses on the diagnostic reality: which VOV8 fields cause systemic problems across an entire document type, why item category confusion is the most common false lead, and what breaks when a custom document type is copied without its dependent config being copied along with it.

Reviewed by an ERPClimb SAP consultant on 15 Sept 2026· 1,241 words

Purpose

VOV8 maintains the customizing table that defines a sales document type - the four-character code stored in AUART on every sales order, quotation, contract, or inquiry header. Each row is a bundle of default behaviors: number range, screen sequence group, transaction group (order, inquiry, quotation, contract, scheduling agreement), document pricing procedure, delivery and billing type proposals, credit check group, incompleteness procedure, requirements class link, and text determination procedure. The single structural fact that explains most confusion: VOV8 is one flat screen covering unrelated processing areas (pricing, delivery, billing, credit, texts, partner determination) at document-type level, while item-level behavior - especially item category - is driven by separate combination tables keyed on item category group and usage, not by anything set on this screen. Consultants routinely change a VOV8 field expecting item-level results and get nothing.

When it is used

Reached for when a new custom sales document type is being built, usually by copying an SAP standard type as a template, or when an existing type's default behavior needs adjustment - wrong delivery type proposed, wrong billing type, credit check firing when it should not, or an incompleteness log blocking save unexpectedly. It sits upstream of every transaction that creates a sales document: order, quotation, and contract creation transactions and their Fiori equivalents all read this table the moment a document type is entered on the initial screen. Consultants go to VOV8 rather than the order transaction itself when the defect is systemic - every order of a given type behaves wrong - rather than isolated to one document, which points to master data or a condition record instead. It is also the first stop when a genuinely new process needs its own document type rather than reuse of a standard one.

How to use it in practice

  • Open VOV8 directly or via the IMG path for sales document types under Sales and Distribution config.
  • Position cursor on an existing similar document type and use Copy As rather than creating from blank, to inherit safe defaults.
  • Rename the new code and review every field on the screen; do not assume the copy carries correct pricing, delivery, or billing defaults.
  • Set or verify number range assignment, transaction group, item division, and screen sequence group; treat transaction group as effectively fixed once live documents exist.
  • Set delivery type, order-related and delivery-related billing types, credit check group, incompleteness procedure, and requirements or scheduling settings.
  • Save under a transport request and create a test order in the target system before considering the change complete.

Key data objects

  • TVAK - sales document type customizing header, one row per document type code, holds all the default proposals set on the VOV8 screen.
  • TVAKT - language-dependent short text and description for each document type code.
  • VBAK - sales order header table; the AUART field records which document type was used to create each order, quotation, or contract, and is the table to query to see how many live documents already use a given type.

How to prove it in the data

Query VBAK filtered on AUART equal to the document type in question to see how many live documents already exist before touching transaction group or number range on that type. Separately pull the TVAK entry for that same AUART in SE16 to see the delivery type, billing type, and pricing procedure fields as actually saved, not as someone describes them from memory. If the complaint is a wrong delivery or billing type on new orders, TVAK for that AUART is the record to check first, not the individual sales document.

ECC vs S/4HANA

VOV8 itself is unchanged on S/4HANA and remains the transaction for sales document type customizing, reached through the same IMG path or direct entry. No Fiori app replaces this configuration step, since it is IMG customizing rather than a transactional process. Fiori changed how orders are created and displayed downstream, but those apps still honor the same TVAK entry for document type defaults.

Common pitfalls and how to diagnose them

  • Transaction group changed after go-live - transaction group is structural and drives which screens and number range logic apply; changing it once VBAK rows already exist for that AUART leaves those documents inconsistent with current config. Check VBAK for existing rows on that document type before touching this field.
  • Item category not changing despite VOV8 edits - item category default is not set here; it comes from a separate combination table keyed on document type, item category group, usage, and higher-level item category. If the reported symptom is a wrong item category, the fix is elsewhere; confirm which transaction the requester actually needs changed.
  • New custom document type creates orders but delivery or billing never generates - copying a document type in VOV8 does not copy its copying control entries. Check copying control for the new type as source; with no entry present, the delivery due list or billing due list silently skips the order with no error message.
  • Number range exhausted or never created - VOV8 references a number range object but does not generate the interval itself. If the interval was never created or has run out, order creation fails with a number range error even though the VOV8 entry looks correct.
  • Incompleteness procedure mistaken for a hard block - assigning an incompleteness procedure populates a warning log; whether that blocks save, delivery, or billing depends on status profile and incompletion group settings, not on VOV8 alone.
  • Credit check group change affects every order retroactively - flipping the credit check field on an existing document type changes behavior immediately for all future and in-process orders of that type across every sales area sharing it, a common cause of sudden unexplained credit blocks.
  • Config not transported - VOV8 changes are client-independent; a fix confirmed in a sandbox or config client that never reaches the affected system leaves the original symptom unresolved there.

Whose problem this is

Functional SD problem in nearly all cases; a functional consultant with SD config authorization owns changes here. ABAP involvement is only needed if a user exit or BAdI enforces logic beyond what the VOV8 fields allow, such as custom incompleteness or credit logic. Basis is needed for the transport. A good handover states the document type code, the exact field changed, whether live documents already exist for that type, and the transport number.

Related SAP objects

Reviewed pages this object connects to in the ERPClimb knowledge graph.

Source: ERPClimb — https://erpclimb.com/sap-tcodes/vov8ERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.