QM03 — Display Quality Notification

QM03 displays an existing quality notification: header data, item/defect lines, causes, tasks and activities, and any linked object reference such as equipment, material or functional location. It is functionally identical to QM02 in layout but strips out all editing rights. The one structural fact that explains most support tickets against QM03 is that the notification is a multi-level document, not a single record: the header (QMEL) can look complete while its items (QMFE), causes (QMUR) or tasks (QMMA) are empty, blank, or not yet created, because each level is maintained and saved independently and none of them are mandatory for the header to exist.

QM03 is reached for whenever someone needs to review a notification without the risk of accidentally changing it: audits, management review, a support agent checking status before escalating, or a consultant confirming what was actually saved after a user complains a change 'disappeared'. It sits after QM01 (create) and alongside QM02 (change) in the notification lifecycle, used any time a read-only view is sufficient or the user's authorization profile only permits display. On S/4HANA, the Fiori app for managing quality notifications increasingly replaces QM03 for day-to-day review, but QM03 remains the fastest route when working directly from a notification number pulled from a report or a batch job log.

In SE16 pull QMEL filtered on QMNUM to confirm the notification exists and check its QMART (type) and creation user. Join to QMFE on QMNUM to see whether item lines exist and how many. If the header looks fine but the screen shows no defect data, QMFE will be empty for that QMNUM, confirming the item level was never populated rather than lost. For status disputes, pull JEST filtered on OBJNR built from the notification number (object type QMEL) and compare against JCDS for the status change timeline; a task showing open in QMMA while the header carries system status closed points to a mismatch between header and task status, not a data error.

QM03 still exists and behaves the same on S/4HANA; the underlying tables (QMEL, QMFE, QMUR, QMMA) are unchanged. What has shifted is the preferred access route: the Fiori app for managing quality notifications is positioned as the primary interface for business users, with QM03 retained mainly for consultants, batch processing follow-up, and cases where the classic GUI screen structure is needed to see all sub-levels at once without navigating multiple Fiori tiles.

This is a QM functional issue in almost all cases: notification type configuration, catalog profile assignment and status profile design are functional decisions. Escalate to ABAP only if a custom user exit or BAdI is manipulating notification data on save. Escalate to Basis or security only for authorization object failures. A good handover includes the notification number, the specific tab or field the user expected to see data in, and the SE16 pull showing what is actually stored.

QM01 and QM02 are the create and change counterparts and should be understood first, since QM03 is their read-only shadow. QS21 and QS23 cover the catalog and code group master data that determines what appears in the item and task tabs. QE01 and QE51N are worth reviewing when a notification originates from or references a results recording process. The QA0x and QA3x inspection lot transactions are relevant when the notification was triggered from an inspection lot rather than entered manually, since the reference chain between lot and notification is a frequent source of display confusion.