ERPClimb logoERPClimb
SAP tableObjectQAVEModuleQM

QAVE table — Inspection Usage Decisions

QAVE stores usage decisions for inspection lots or partial lots. SAP documentation identifies QAVE as 'Usage decisions', including the decision code and timestamp used when the inspection is completed. It is not the characteristic-level pass or fail valuation table; characteristic specifications, results, and single values are handled in QAMV, QAMR, and QASE.

This page covers what a row in QAVE actually represents, the fields a consultant can rely on, how it joins to the inspection lot header and results tables, and the recurring mistakes made when using it to explain a rejected batch or an unexpected usage decision. It also covers ownership and how the table behaves across ECC and S/4HANA.

Published 20 Sept 2026· 1,099 words

What it stores

A row in QAVE represents the valuation of one inspection characteristic for one inspection lot: the conclusion drawn after results were recorded, comparing what was measured or observed against the specification carried on the lot. It answers the question 'was this specific characteristic accepted or rejected', separately from the overall usage decision on the lot header. Quantitative characteristics carry accepted and rejected quantities; qualitative characteristics carry a pass or fail style code. The valuation can be generated automatically by the system from the recorded result against tolerances, or entered and overridden manually by the inspector during results recording. Because the valuation is characteristic-level, a single lot with ten characteristics can have ten QAVE rows, some accepted and some rejected, well before the header-level usage decision is set in QALS.

Key fields

  • Inspection lot or partial-lot context — identifies the object receiving the decision.
  • Usage-decision code and code-group or catalog context — captures the business disposition.
  • Decision date, time, and user — provide audit timing.
  • Follow-up and stock-posting context — can drive subsequent stock or process actions.
  • QALS and JEST — provide inspection-lot header and status context.

How it joins the data model

  • QAVE-PRUEFLOS = QALS-PRUEFLOS, joining each characteristic valuation back to the inspection lot header, its status, and the final usage decision
  • QAVE-PRUEFLOS/MERKNR = QAMR-PRUEFLOS/MERKNR, joining the valuation to the underlying single recorded results (measured values or attributes) that produced it
  • QAVE-PRUEFLOS/MERKNR = QAMV-PRUEFLOS/MERKNR, joining to the characteristic master copy held on the lot, which carries the specification, tolerance, and sampling procedure the valuation was measured against
  • no direct foreign key exists between QAVE and quality notification tables such as QMEL or QMFE; a rejected valuation may trigger a notification through configuration, but the link is procedural, not a database join

How to read it safely

MANDT is the first restriction in any client-dependent SAP system with multiple clients. After that, always restrict on PRUEFLOS; the table has no useful secondary index for browsing by plant, material, or date, because none of those fields live here directly. To find lots for a material or plant, filter QALS first, then use the resulting PRUEFLOS values to select from QAVE. Selecting QAVE without a PRUEFLOS restriction on a live production system is a full table scan across every characteristic of every lot ever created and will be slow. When a lot has several inspection points or partial results, expect several valuation rows per characteristic over time, not just one; check the most recent by whatever sequencing the results recording (QAMR) history implies rather than assuming one row is definitive.

How to prove it in the data

Symptom: a lot's usage decision shows partial rejection but the reason is not obvious from the header alone. Select QAVE where PRUEFLOS equals the lot number, ordered by MERKNR, and read the valuation code per characteristic. Any characteristic showing rejected is a candidate cause. Cross-check that row against QAMR for the same PRUEFLOS and MERKNR to see the actual recorded value or attribute, and against QAMV for the same keys to see the specification and tolerance it was judged against. This chain confirms which specific characteristic drove the rejection and whether the valuation was automatic or manually forced.

ECC vs S/4HANA

QAVE remains the ERP and S/4HANA Quality Management usage-decision table. Current SAP support content explicitly refers to QAVE for header or partial-lot usage-decision details. Fiori Quality apps may expose the same business decision through CDS views, but the semantic role remains usage decision.

Common pitfalls

  • Treating QAVE as one row per lot. It is one row per characteristic per lot; a count of QAVE rows for a material over time massively overstates the number of inspection lots unless grouped by PRUEFLOS.
  • Assuming a characteristic missing from QAVE means it passed. It more often means results were never recorded for it yet, or the lot is still open; absence is not a pass.
  • Reading the valuation code as the final word on quality without checking whether the manual override flag is set. A manually forced acceptance can sit on top of a recorded result that would otherwise have failed tolerance, and that distinction matters in an audit.
  • Confusing QAVE with QAMV. QAMV carries the specification and sampling setup copied onto the lot; it does not tell anyone what actually happened during inspection. Pulling QAMV expecting outcomes is a frequent mistake by people new to the QM data model.
  • Assuming a rejected characteristic in QAVE automatically means the lot's overall usage decision is rejected. The usage decision on QALS is a separate, deliberate step; a characteristic can be rejected while the lot is still accepted if that characteristic does not control the decision, or the decision has not been made at all yet.
  • Mixing quantity-based and code-based valuations in the same aggregate query. Summing an accepted-quantity field across characteristics that are actually valuated by pass or fail code produces a meaningless number.
  • Trusting a BW or reporting extract of QAVE without checking it was refreshed after a lot was reopened and results re-entered. Valuations are recalculated when results change, and a stale extract will show an outcome that no longer matches the live lot.

Whose problem this is

The QM configuration and master data team owns the setup that determines how and when characteristic valuations are generated, including tolerance settings and automatic valuation rules. The plant quality engineer or inspector owns whether a specific recorded valuation, especially a manual override, was correct. Disputes over why a lot was rejected on a specific characteristic sit with quality, not with the functional consultant unless the automatic valuation logic itself is suspected of misconfiguration.

Related SAP objects

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

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