QM02 — Change Quality Notification
QM02 changes an existing quality notification created in QM01 - adding or editing defect items, tasks, activities, causes and partners. The notification type fixed at creation determines the tab layout and field selection and cannot be changed here. Editing is gated by system and user status; a completed or closed notification shows most fields greyed out until the status is reset.
This page covers QM02, the transaction for changing a quality notification after creation, including how status controls editability and which tables receive the changes. It focuses on the diagnostic patterns behind locked fields, missing partner data, and catalog code errors that consultants hit when processing notifications day to day.
Reviewed by an ERPClimb SAP consultant on 15 Sept 2026· 1,011 words
Purpose
QM02 opens an existing quality notification - a customer complaint, internal problem report, or vendor complaint - for editing. The notification type assigned when the record was created in QM01 is permanent; it drives which tabs appear (items, tasks, activities, causes, actions), which partner functions are expected, and which catalogs are offered for coding defects. Most confusion around QM02 traces back to system and user status: a notification that has reached a completed or closed status will render most input fields as display-only, and consultants who do not check status first waste time assuming a field is broken or authorization is missing when it is simply locked by the notification's own lifecycle state.
When it is used
QM02 is reached constantly during the life of a notification: adding defect items as more information comes in, assigning tasks and activities to responsible people, recording root cause analysis, attaching corrective action plans, or updating the priority and due dates. It is also the entry point for triggering follow-up documents such as returns, debit memos, or 8D reports where those are linked to the notification workflow. Fiori equivalents for notification monitoring and mass processing exist in some S/4HANA landscapes, but line-level defect and task editing routinely still happens through QM02 because the GUI screen exposes every field the Fiori list view does not.
How to use it in practice
- Call QM02 and enter the notification number directly, or use the matchcode search by reference object, material, or creation date
- Review the header data screen - notification type, priority, status - before touching anything else
- Navigate to the relevant tab: item/defect data, tasks, activities and actions, causes, or partners
- Add or edit the required data; check whether required fields (cause code, task code) are enforced by the catalog profile
- Change status if needed (put in process, complete task, etc) using the status functions, not by editing dates alone
- Save; watch for partner determination errors or catalog validation errors on save
Key data objects
- QMEL - notification header: notification number, type, priority, reference object, dates
- QMFE - notification items: individual defects recorded against the notification
- QMUR - causes: root cause codes linked to defect items
- QMMA - tasks: corrective or preventive tasks assigned with responsible party and due date
- QMSM - activities: actions actually carried out against a task
- JEST and JCDS - status management: current and historical system/user status of the notification object
How to prove it in the data
In SE16 on QMEL, filter by QMNUM to confirm notification type, creation user and date, and current status flags. Cross-check JEST filtering on object number (object type QMEL plus the notification number, zero-padded) to see which status is active and whether it is a lock-relevant status. Pull QMFE and QMMA for the same QMNUM to compare what the user claims they entered against what actually saved - a common gap is a defect item entered on screen but never saved because a required catalog field was blank.
ECC vs S/4HANA
QM02 remains available on S/4HANA and the underlying tables are unchanged for standard notification processing. Some landscapes offer a Fiori app for browsing and mass-updating notifications, but detailed editing of defect items, tasks and causes is still commonly done through QM02 because the Fiori list views do not expose every field the classic screen does. No structural redesign of the notification data model has occurred.
Common pitfalls and how to diagnose them
- Status lock - fields appear greyed with no error message; check JEST for the notification's current system and user status before assuming an authorization problem, then reset or advance status through the proper status function rather than trying to force a field open
- Catalog code not available - a defect or cause code the user expects to select does not appear in the dropdown; this means the code is not assigned to the catalog profile linked to this plant and notification type combination, not that the code does not exist system-wide
- Partner determination failure on save - notification type requires a partner function (sold-to, ship-to, responsible person) that was never populated at creation and QM02 refuses to save the change until it is filled
- Notification locked by another user - enqueue error on open; usually a colleague has the same notification open in change mode and has not saved or exited cleanly
- Task completion blocked - business completion of a task fails because a required field (completion date, actual cost, or a mandatory activity) is missing, and the error message points to the task line, not the header
- Follow-up document link broken - a return or debit memo created from the notification cannot be found later because the link was made before the notification was saved, leaving the document reference orphaned
Whose problem this is
Functional QM territory in almost every case - status confusion, catalog configuration, and partner determination are all customizing issues, not code issues. Escalate to ABAP only if a user exit or screen enhancement is suspected of blocking a save. Escalate to Basis only for persistent lock table entries. A good handover includes the notification number, the exact status shown in JEST, and the screen/tab where the error occurred.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tcodes/qm02ERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.