QMFE table — QMFE - Quality Notification Defect Items

One row in QMFE represents a single defect entry logged against a quality notification. A notification header in QMEL can carry several distinct defects, and each of those gets its own line in QMFE, identified by a running item number within the notification. The row records which defect was found (via a code group and code taken from the QM catalog), and where on the object or product the defect was located (object part code group and code). QMFE does not itself explain why the defect happened or what was done about it, those belong to the cause table and the activity table respectively, both keyed off the same notification and item number. Because catalogs and code groups are configured per plant and per notification type, the meaning of a given code in QMFE only makes sense once the catalog profile in force for that notification is known.

Always restrict by MANDT first, this is a client-dependent table and cross-client selects are meaningless in practice. QMNUM is the most selective field, a single notification typically has a handful of defect items, so pulling by QMNUM is cheap. Selecting broadly by FEGRP or FECOD across the whole table to count how often a defect occurs is expensive and, more importantly, not directly comparable unless every row selected shares the same catalog profile, plant, and notification type. Join to QMEL first to filter by plant, notification type, and creation date before aggregating on FEGRP/FECOD, otherwise the aggregation mixes catalogs that use the same code number for different meanings.

Symptom: a plant reports that the same defect keeps recurring on a material. Select QMFE joined to QMEL on QMNUM, restrict QMEL by the material and plant fields and by a creation date range, then group the result by FEGRP and FECOD. A high count on one specific code group and code combination, consistent across notifications, confirms a recurring defect pattern for that material rather than a one-off complaint. Cross-check the catalog profile behind that code group before quoting the defect description in a report.

QMFE is retained in S/4HANA as a transparent table with the same structural role it had in ECC. The QM notification data model has not been rebuilt around a new CDS-based persistence layer in the way some logistics tables have, so consultants moving from ECC continue to read and join QMFE the same way. Notification transactions continue to write to it directly. Treat any specific release claim about field additions with caution and verify against the system in front of the reader rather than this page.

A discrepancy in defect data is a QM functional consultant's problem first, since catalog profiles, code groups, and notification type configuration determine what a row in QMFE means. The plant quality department owns the business judgment of whether a defect classification is correct. Catalog master data changes go through whoever administers the QM catalogs, not through the business user entering the notification.

QMEL is the notification header that every QMFE row belongs to. QMUR carries the causes assigned against a defect item, QMMA carries the activities or tasks recorded against it. QPGR and QPCT hold the code group and code master data that give FEGRP and FECOD their meaning, maintained through catalog configuration transactions. Notifications are created and changed through the standard QM notification transactions, which are what actually write and update rows in QMFE.