QAMR table — Single Results Table for QM Characteristics

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.

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.

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.

The table structure and its role in results recording carried forward into S/4HANA without a known compatibility view or renaming. The underlying process, quantitative results feeding the aggregated characteristic record, is unchanged. Newer Fiori-based results recording apps write through the same data model, so QAMR remains the place to look for individual readings regardless of which front end was used to enter them.

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.

QALS is the inspection lot header everything joins through. QAMV holds the aggregated characteristic result, mean, valuation and status, one level above QAMR. QASE carries the sample data that determines how many single results are expected. QAVE holds the lot's usage decision once results recording is complete. Results recording and lot processing transactions such as the standard record-results and change-lot transactions write to these tables together, never to QAMR in isolation.