QASE table — Inspection Characteristic Results Table
QASE holds the recorded result for a single inspection characteristic evaluated within a specific inspection lot, one row per characteristic per sample or inspection point. It sits below the inspection lot header (QALS) and above the usage decision (QAVE), and is the table results-recording transactions actually write to when an inspector enters a measured value or a qualitative finding.
This page covers what a row in QASE represents, the fields safe to rely on, and how to join it back to the inspection lot, quantity, and characteristic master tables. The pitfalls section focuses on the mistakes made when using row counts and characteristic numbers in QASE as if they were plan-level or cross-lot identifiers.
Published 16 Sept 2026· 996 words
What it stores
One row in QASE is one recorded result for one inspection characteristic, tied to a specific inspection lot and typically to a specific sample or partial lot draw. When an inspection lot has ten characteristics copied from its plan and results are recorded across three samples, expect up to thirty rows here, not ten, and fewer if some characteristics were skipped as optional or not yet recorded. The table stores the raw entry made during results recording, not the final usage decision and not the plan definition itself. It is the granular evidence of what was actually measured or judged against a characteristic, before that evidence is rolled up into an overall lot evaluation and, eventually, a usage decision.
Key fields
- MANDT - client, mandatory restriction on any direct selection
- PRUEFLOS - inspection lot number, ties every result row back to its header record in the lot table
- MERKNR - internal characteristic number within the lot; sequential and lot-specific, not the same numbering as the characteristic in the inspection plan
- VORGLFNR (unconfirmed exact spelling) - counter identifying which sample, partial lot, or inspection point the result belongs to; treat as present in concept even if the literal field name needs verification
- a recorded value or evaluation field carrying the measured value for quantitative characteristics or the qualitative finding code for attributive ones; field name should be confirmed in the ABAP dictionary before being hard-coded into a report
How it joins the data model
- QASE-PRUEFLOS = QALS-PRUEFLOS - every result row belongs to exactly one inspection lot header
- QASE-PRUEFLOS = QAVE-PRUEFLOS - the usage decision for the lot is made after all required characteristic results are present
- QASE-PRUEFLOS = QAMR-PRUEFLOS - lot-level quantity data (inspected, rejected, accepted quantities) sits alongside the characteristic-level results
- QASE-PRUEFLOS = QAMV-PRUEFLOS - assignment/partial-lot data for the same lot
- characteristic identity traces conceptually back to the plan-level characteristic (PLMK, allocated via PLMZ) that was copied into the lot when it was created, but the lot-internal MERKNR in QASE cannot be joined directly to PLMK's characteristic number without going through the copy step
How to read it safely
Always restrict by MANDT and PRUEFLOS before touching this table; it is one of the higher-volume QM tables in plants running 100 percent inspection with many characteristics per lot, and an unrestricted scan is expensive. The normal path is to select the inspection lot list first from QALS using plant, material, or date range, then pull QASE rows for that specific PRUEFLOS set. Do not attempt to filter meaningfully on MERKNR alone across lots, since the number is only unique within a single lot.
How to prove it in the data
Symptom: a characteristic result looks missing or wrong for a specific inspection lot. Selection: read QASE for that PRUEFLOS, list every MERKNR row, and count them against the number of characteristics defined on the lot's inspection plan. A shortfall points to a characteristic that was skipped rather than corrupted. For a suspect value, compare the recorded entry against the plan's tolerance range and then check whether the usage decision in QAVE for the same PRUEFLOS was already set, which would explain why a correction is being resisted.
ECC vs S/4HANA
QASE continues to exist as a transparent table in S/4HANA and remains the underlying store for the classic results recording transactions. No specific compatibility CDS view replacing this table is confirmed here, and the classic QM inspection lot data model, including the split across lot header, quantities, assignment, and characteristic results, is largely retained rather than redesigned.
Common pitfalls
- Treating the row count in QASE as the sample size: it reflects results actually recorded, not the sample plan, and a characteristic marked optional or exempted under a skip-lot or relaxed inspection rule leaves no row without raising any error
- Joining MERKNR across different inspection lots as if it identified the same characteristic: the number is lot-internal and can differ for the identical characteristic on two lots of the same material
- Assuming the value stored is the final accepted-or-rejected evaluation: it is the raw recorded entry, which an inspector can still override manually before the usage decision is set, so the row alone does not tell the whole story
- Deleting or reversing an inspection lot outside the proper cancellation transaction and expecting QASE to clean up consistently: orphaned or stale result rows can persist and confuse later reporting
- Direct table updates to QASE bypassing the results recording transaction, which desynchronizes the lot's completion status from what is actually stored here, producing lots that allow a usage decision despite incomplete results, or the reverse
Whose problem this is
The quality engineer or QM master data owner is responsible for the characteristic and plan definitions that determine what should appear in QASE. The actual row-level content is owned by whoever performs results recording, typically an inspector or a production operator using the standard transaction. A functional or technical consultant gets pulled in for extraction, reconciliation, or when result rows and lot status disagree.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tables/qaseERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.