TVAK table — Sales Document Type Customizing Table

Each row in TVAK defines one sales document type, keyed by AUART, and stores the control attributes that govern every sales document created with that type: which document category it belongs to (order, contract, credit memo request, and so on), which transaction group it falls under for status and number range handling, whether it participates in billing and credit management, and which item number increment and screen sequence apply. The row itself contains no business data and no customer or material references. It is pure configuration, changed rarely and only through customizing transport, and every VBAK header record points back to exactly one row here through its AUART value. Consultants read TVAK to understand why a given order type behaves the way it does, not to find open orders or values.

TVAK is small, client-dependent, and fully cached by the application server, so a direct read on AUART is fine and a full table scan is harmless in most systems because row counts rarely run past a few hundred. Always restrict on MANDT even though it feels redundant, because cross-client comparisons during a system copy or transport check are the one scenario where forgetting it causes confusion. There is no date field and no plant, sales org, or customer field to filter on, because the table is not sales-area sensitive; a document type behaves the same in every sales area unless overridden by a separate assignment table.

Symptom: a sales order of type ZOR is not showing up in the credit management worklist even though similar orders of type OR do. Selection: read TVAK for AUART equal to ZOR and AUART equal to OR, compare the credit-relevant and document category settings side by side. If ZOR's category or transaction group differs from OR's, the order is being excluded by design, not by a data error, and the fix belongs in customizing, not in the individual order.

TVAK is unchanged in shape and purpose on S/4HANA. Sales document type customizing still lives here and is still maintained through the same IMG activity and transaction. No compatibility view replaces it because it was never part of the VBAK/VBAP simplification; the redesign in S/4HANA touched document tables and their indexes, not the customizing layer that defines document types.

Sales document type configuration belongs to the SD functional consultant or process owner responsible for order-to-cash customizing, not to Basis or ABAP unless a transport or authorization issue is suspected. Any request to add or change a document type needs sign-off from whoever owns credit management and billing configuration too, since a single AUART change ripples into both.

TVAP holds the item categories permitted or defaulted per sales document type and is maintained from the same configuration screen. VBAK is the transactional header table that carries AUART on every created order. T683 and T683S carry pricing procedure determination logic that consumes the document pricing procedure indicator set in TVAK. Document types are created and changed through the standard sales document type configuration transaction, never written to directly by any order-entry transaction.