T683 table — Pricing Procedure Header Table

Each row in T683 identifies one pricing procedure by its key, for example RVAA01 for standard order pricing or RVWA01 for a wholesale variant. The pricing procedure itself is nothing more than a name that other tables and other customizing objects point to. The actual content of a procedure, meaning which condition types appear, in what order, with which from-and-to step ranges and which requirement routines and alternative calculation types, is not stored in T683 at all but in the associated step table. T683 is therefore best understood as the anchor record: it gives the procedure a name and a small set of control attributes, and everything downstream, from condition determination in the sales document to account determination in billing, resolves through that name.

T683 is a narrow customizing table. Confirmed fields are limited to the client and the procedure key itself; the descriptive text seen in V/08 sits in a companion text table rather than in T683.

T683 is a hub, not a leaf. The procedure key from T683 is the join field into the table that actually carries the pricing logic, and it is the target value produced by the determination tables that decide which procedure a given sales area and document combination should use.

T683 itself is tiny, one row per procedure, so selectivity is not the concern here; the risk is reading it in isolation and assuming it explains behaviour. Always restrict by client first, then look up the exact KALSM value from the document or from the determination table rather than guessing a procedure name. The table never explains why a procedure was chosen for a given document, only that the procedure exists. To understand behaviour, pivot immediately to the step table for the content and to the determination table for the reason a specific procedure was selected.

Symptom: a condition type the business expects is missing from a sales order's pricing screen. Confirm the procedure in use from the document (VBKD-KALSM or the pricing analysis screen in the order), then select T683 by that KALSM to confirm the procedure exists and is not a typo. If it resolves, the real answer is not in T683 but in T683S for that same KALSM, checking whether the condition type step is present, active, and not excluded by a requirement routine.

T683 continues to exist as a physical customizing table on S/4HANA and the pricing procedure structure has not changed shape. There is no compatibility view replacing it for standard SD pricing, since the classic condition technique remains the pricing engine for sales and billing documents. Newer pricing capabilities introduced with S/4HANA, where applicable, sit alongside the classic condition technique rather than replacing T683 or T683S.

Most confusion around T683 comes from treating it as if it held the pricing logic itself.

Pricing procedure content is an SD functional configuration decision, owned by the SD pricing consultant together with the business stakeholder who defines the pricing policy. Any change request that says a price is wrong should be routed through pricing analysis in the document first; T683 itself is rarely where the fix happens, but it is where the consultant confirms which procedure is even in play.

T683S carries the step-level content of each procedure maintained in V/08. TVAK holds the document pricing procedure indicator per sales document type, and KNVV holds the customer pricing procedure indicator per sales area; both feed the determination logic that ultimately selects a KALSM value from T683. VBKD stores the resolved document pricing procedure at the sales document level. KONV holds the actual condition records applied to a document once the procedure has run.