ERPClimb logoERPClimb
SAP tableObjectQAMRModuleQM

QAMR table — Inspection Characteristic Results

QAMR stores characteristic-level inspection results for inspection lots. SAP documentation names QAMR 'Characteristic: Results'. It contains the summarized or result state for a characteristic after results recording, while individual single values are stored separately in QASE. The record must be interpreted together with the corresponding QAMV specification and inspection-lot context.

QAMR is the granular results layer beneath inspection lot characteristics, storing each single measured value entered during results recording rather than the summarized outcome. This page covers its keys, its joins into the inspection lot data model, and the recurring mistake of treating QAMV aggregates as the whole story when a dispute over a measured value actually lives here.

Published 20 Sept 2026· 850 words

What it stores

One row in QAMR represents a single individual reading recorded against one quantitative inspection characteristic of one inspection lot during results recording. When an inspector enters a series of measurements for a characteristic with a sample size greater than one, each measurement becomes its own row, carrying the value, its sequence position within the sample, and the link back to the lot and characteristic. The table does not store the derived statistics for the characteristic, only the raw inputs those statistics are calculated from. Qualitative or attributive characteristics recorded through code catalogs generally do not populate this table the same way, since those results are coded rather than measured. QAMR is the layer a consultant drops down to when the aggregated result on the characteristic looks wrong and the individual entries need to be checked.

Key fields

  • Inspection lot and characteristic number — primary business context.
  • Result, valuation, and status fields — describe the characteristic-level outcome.
  • Statistical or summarized values — depend on quantitative or qualitative characteristic processing.
  • QAMV — provides the specification that the result is evaluated against.
  • QASE — holds individual single values when single-result recording is used.

How it joins the data model

  • QAMR-PRUEFLOS = QALS-PRUEFLOS
  • QAMR-PRUEFLOS = QAMV-PRUEFLOS and QAMR-MERKNR = QAMV-MERKNR
  • QAMR-PRUEFLOS = QASE-PRUEFLOS
  • QAMR-PRUEFLOS = QAVE-PRUEFLOS

How to read it safely

Always restrict on MANDT and PRUEFLOS before doing anything else, and add MERKNR whenever the question is about one characteristic rather than the whole lot. The table has no plant or material field of its own, those come through QALS, so any selection built directly on material or plant has to join out first. On a site with high inspection volume and many quantitative characteristics with large sample sizes, QAMR grows fast and an unrestricted select is genuinely dangerous; narrow by a date range on QALS or by a specific list of lot numbers before pulling single results. Do not attempt to browse it characteristic by characteristic across a plant, go lot by lot.

How to prove it in the data

Symptom: the usage decision on a lot looks inconsistent with what the inspector remembers measuring. Select QAMR where PRUEFLOS equals the lot number and MERKNR equals the characteristic in question, list MESSWERT ordered by LFDNR, and manually recompute the mean, minimum and maximum from the raw values. Compare that against the aggregated fields on QAMV for the same PRUEFLOS and MERKNR. A mismatch points to a unit conversion, rounding, or entry timing issue rather than a valuation rule problem.

ECC vs S/4HANA

QAMR remains part of the S/4HANA Quality Management inspection-lot data model. SAP archiving documentation continues to identify QAMR as characteristic results. New UI layers do not change the distinction between QAMV specifications, QAMR characteristic results, and QASE single values.

Common pitfalls

  • Treating QAMV as the complete picture and never checking QAMR, which hides rounding, unit conversion, or transcription problems that only show up in the individual readings
  • Assuming one row per characteristic per lot, when in fact a sample size greater than one produces one row per reading, so a row count that looks too high is often correct, not a duplication bug
  • Confusing MERKNR, the lot-specific runtime characteristic number, with the master characteristic key defined in the inspection plan, they are not the same identifier and do not align across lots automatically
  • Expecting a row here for a qualitative or catalog-coded characteristic, absence of quantitative single results for an attributive characteristic is normal, not a data gap
  • Editing QAMR directly to correct a bad reading instead of reprocessing results recording through the proper transaction, which desynchronizes the aggregated values in QAMV and breaks the audit trail expected in a regulated quality process
  • Pulling the table without restricting by PRUEFLOS on a site with heavy inspection volume, which turns a simple check into a long-running, resource-heavy query

Whose problem this is

A question about what QAMR contains for a given lot belongs to the QM functional consultant or the quality engineer who owns results recording configuration. Disagreements about a specific measured value usually also involve the shop floor inspector who entered it, since the table only records what was typed or transferred, not whether the reading itself was accurate.

Related SAP objects

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

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