T683S table — Item Category Determination Table
T683S is the customizing table behind item category determination in sales documents (transaction VOV4). One row maps a combination of sales document type, item category group, item usage, and higher-level item category to a default item category (PSTYV) written to VBAP, plus a flag for whether that default can be changed manually on the order.
Covers what T683S stores, its key determination fields, how it joins to VBAK and VBAP, and the diagnostic reflexes for when an order line shows an unexpected item category. Focused on separating true determination-table issues from manual overrides, copy control, and stale material master data.
Reviewed by an ERPClimb SAP consultant on 15 Sept 2026· 980 words
What it stores
T683S stores the item category determination rules maintained through the VOV4 configuration transaction. One row represents a single combination of sales document type, item category group (carried from the material master onto the order item), item usage, and higher-level item category, resolving to a default item category value. This value is written into VBAP-PSTYV when a sales document item is created without reference to a preceding document. The table also carries an indicator for whether the determined item category can be overridden manually on the document. It does not store transactional data itself; it is pure configuration consulted at document-save time by the item category determination logic inside standard sales order processing.
Key fields
- AUART - sales document type, first key of the determination combination
- MTPOS - item category group, normally inherited from the material master sales data and carried onto VBAP
- PSTYV - item category, the result of the determination and the value written to VBAP-PSTYV
- usage field (item usage, mapped from VBAP usage indicator) - distinguishes special processing such as free goods or text items; exact technical field name should be confirmed against the current data dictionary before quoting it in scripts
- higher-level item category field - used for sub-items such as BOM components or free goods, keying determination on the parent item's category rather than the header alone; exact technical field name should be verified before use in a query
How it joins the data model
- VBAK-AUART = T683S-AUART
- VBAP-MTPOS = T683S-MTPOS
- VBAP-PSTYV = T683S-PSTYV (the result written on document creation)
- T683-PSTYV = T683S-PSTYV (the item category master record that the determined value must exist in)
How to read it safely
T683S is small and fully client-dependent, so MANDT plus AUART is enough to pull a readable slice for a single sales document type. There is no meaningful selectivity problem here; the table has at most a few hundred rows per client. The risk is not performance but misreading blank key values: many configurations include a fallback row with an empty item category group or empty usage that acts as a catch-all for everything not matched by a more specific row. Always sort results so that fully specified rows are checked before the blank-key fallback, otherwise the wrong rule looks like the one that fired.
How to prove it in the data
To confirm why a given order line got item category TAN instead of an expected value, take the order's AUART from VBAK, the MTPOS and usage indicator actually stored on that VBAP row, and the PSTYV of the higher-level item if one exists, then look up T683S for the matching AUART with those exact values, falling back to the blank-MTPOS or blank-usage row if no specific match exists. The row found should return the PSTYV seen on the order; if it does not, the value was set by another mechanism, not by determination.
ECC vs S/4HANA
T683S is retained in S/4HANA as a standard customizing table maintained through the same VOV4 activity; it has not been replaced by a CDS compatibility view because it is configuration, not master or transactional data subject to the usual simplification list treatment. The determination logic that reads it during sales document processing is unchanged in shape, though surrounding logic such as advanced ATP or newer pricing procedures can influence which item category path is actually exercised for a given scenario.
Common pitfalls
- Assuming the item category on an existing order reflects what T683S currently says: the value in VBAP-PSTYV is fixed at document creation; changing the T683S entry afterward has no effect on orders already saved.
- Forgetting that orders created with reference to a preceding document (quotation, contract) get their item category from copy control settings, not from T683S; checking T683S first on a referenced document wastes time.
- Confusing VBAP-MTPOS with the current material master item category group; if the material master value was changed after the order was created, the order still carries the old MTPOS and the old determined category.
- Overlooking the higher-level item category dimension, so two lines with the same document type and material end up expected to have the same item category when one is a sub-item of a BOM or free-goods structure and is keyed differently.
- Missing the blank-key fallback row and concluding no rule exists for a combination, when in fact a generic row is catching it silently.
- Treating the manual-override indicator as a hard rule; even when it appears to allow manual change, other configuration or authorization can still block or permit changes independently of this table.
- Editing T683S directly in a client to fix a live order problem, then being surprised the open order is unaffected while only new orders pick up the change.
Whose problem this is
The SD or order-management functional consultant owns the T683S configuration, maintained via VOV4 as part of sales document customizing. Where the input MTPOS comes from the material master, the MM or master-data team owns getting that item category group set correctly on the material; basis is not normally involved since this is pure customizing.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tables/t683sERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.