QMUR table — Notification Item Causes Table

One row in QMUR represents a single cause recorded against a single item of a notification. When a user works a quality notification and, for a given defect item, opens the causes tab and adds an entry from the cause catalog, that entry becomes a row here. A notification item can have zero, one, or several causes, so QMUR sits one level below QMFE (the item table) in the notification hierarchy, in the same way QMFE sits below QMEL (the notification header). Because the underlying notification data model in SAP is shared across quality notifications, plant maintenance notifications and customer service notifications, QMUR is not exclusively a QM table in the physical sense, even though QM is where it is used most heavily for defect root-cause capture and catalog-based reporting.

MANDT is the client field, restrict on it as always. Never select QMUR by QMNUM alone expecting only quality notification causes back; the notification number range is shared across notification types, so filter through QMEL first on notification type if the report needs to stay QM-scoped. Always carry FENUM in the join to QMFE, otherwise every cause for every item of a multi-item notification returns against every item, producing a cartesian result that looks like duplicated causes. URNUM is only unique within a QMNUM/FENUM combination, not across the table, so it cannot be used as a standalone key in any join.

Symptom: a defect item is closed but the report claims no cause was ever documented. Select QMUR where MANDT equals the current client, QMNUM equals the notification number, and FENUM equals the specific item number. If no rows come back, no cause was recorded against that item, confirmed. Cross-check against QMFE for the same QMNUM/FENUM to make sure the item itself exists and was not renumbered, since a mismatched FENUM after item deletion and re-entry is a frequent false negative.

QMUR is retained in S/4HANA with the same key structure and role as in ECC; the underlying notification data model was not restructured by the S/4HANA conversion. Standard transactions for creating and processing notifications continue to write to it in the same way. Reporting layers built on CDS views may expose cause data through a compatibility or analytical view rather than direct table access, but the physical table and its relationship to QMEL and QMFE is unchanged.

Any question about whether a cause was recorded, why a cause catalog entry is missing, or why a cause code group is not offered on a notification type belongs to the QM functional consultant who owns the catalog and notification type configuration, not to the ABAP developer running the query. Cross-module notification sharing questions with PM or CS teams should be raised jointly since the table is common ground.

QMEL is the notification header and the entry point for scoping any QMUR query. QMFE is the direct parent, one item can carry many QMUR rows. QMMA holds activities recorded at the same item level, often reviewed alongside causes when closing out a defect. The catalog tables behind URGRP and URCOD supply the descriptive text and control which cause codes are valid for a given catalog profile. Notifications are created and processed through the standard QM notification transactions, and PM/CS equivalents write to the same physical tables.