QM01 — Create Quality Notification

QM01 opens a notification header where a defect, complaint or internal problem is recorded against a reference object. The notification type entered on the initial screen (Q1 customer complaint, Q2 complaint against vendor, Q3 internal problem report, or a Z-variant) is the single decision that shapes everything that follows: which tabs are visible, which partner roles are proposed, which defect catalogs are offered on the item tab, which status profile governs the workflow, and which follow-on actions (tasks, corrective action requests) are available. Two notifications created through QM01 on the same day can look and behave completely differently if their notification types are configured differently. Most confusion reported against 'QM01' is really a notification-type customizing gap, not a transaction defect.

QM01 is reached for whenever a quality event needs a formal, trackable record: a customer return with a complaint, a batch rejected by a vendor's delivery, or an internal nonconformance found outside a formal inspection lot. It sits between the event (goods receipt, customer return, shop floor finding) and the corrective action cycle (causes, tasks, activities). Where defects are found during inspection processing, results recording can generate a notification automatically, so QM01 is used less for inspection-driven defects and more for ad hoc or externally reported issues. In S/4HANA a Fiori app covering notification creation and processing exists as an alternative front end, but the underlying object and much of the field logic are unchanged from the GUI transaction.

Pull the notification number range from QMEL filtered on QMART (notification type) and, if the report is about a specific object, on MATNR or the equipment/functional location field. Join to QMFE on QMNUM to see whether defect items actually saved with a valid catalog code and code group. Cross-check JEST for the object number derived from the notification to confirm the current status matches what the user reports; a notification stuck at an early status usually shows only the initial system status set with no follow-on entries in QMMA.

The notification object and its core tables are unchanged on S/4HANA; QM01 still functions as the GUI creation transaction and remains in active use. S/4HANA adds a Fiori app for creating and processing quality notifications aimed at shop floor and quality users who do not need the full GUI screen set, but it writes to the same underlying tables. Business partner unification affects how customer and vendor partner data resolves behind the scenes, but the notification type customizing model that drives QM01's behavior is the same as in ECC.

Functional QM consultant owns notification type and catalog customizing, and is first line for any QM01 complaint. ABAP gets involved only if a custom screen exit, BAdI or workflow tied to the notification type is suspected. A clean handover states the notification type, plant, the exact tab or field affected, and whether the same issue reproduces on a different notification type in the same plant.

QM02 and QM03 are the change and display counterparts and are where most post-creation troubleshooting continues, since a notification's status history and task log are visible there. QS41 governs the catalog assignment that QM01's item tab depends on, and QS21 defines the code groups those catalogs reference; both are the first stop when defect codes are missing or wrong. QE51N is worth reviewing separately because results recording can generate notifications automatically, which explains notifications appearing without anyone having run QM01 manually.