IW22 — Change Plant Maintenance Notification

IW22 opens an existing PM notification for editing. It is where a planner or technician records what was actually found and done against a reported malfunction, activity request, or maintenance request: damage codes, causes, tasks, completed activities, partner assignments, and long text. The one structural fact that explains most confusion is that a notification is not the same object as a maintenance order, even when one was generated from the other. Editing the notification in IW22 does not automatically rewrite order data, and once the notification reaches certain statuses (in process, order-linked, completed) large parts of the screen lock for editing, sometimes silently reducing to display-only fields rather than throwing an obvious error.

Used constantly during the life of a notification: right after breakdown reporting to add technical findings, during maintenance execution to log causes and tasks, and at closeout to enter completion data before the notification is set to completed. Planners reach for IW22 over the equivalent Fiori app when they need catalog code entry across multiple tabs, bulk technical detail, or fields that the simplified Fiori notification apps do not expose. Fiori apps for creating and processing notifications cover the day-to-day technician workflow well; IW22 remains the fallback when a field, catalog profile, or partner function is only reachable from the classic screen.

Pull QMEL by QMNUM to confirm current status, creation and change dates, and object reference. Join QMFE, QMUR, QMMA, QMSM on QMNUM to see whether the item, cause, task, and activity rows a user claims to have entered actually exist. Check JEST for the same object number to see the full status history and confirm whether a completed or order-linked status was set before the edit attempt, which explains why fields appeared locked. Compare AENAM/AEDAT on QMEL against the user's claimed change time to rule out a save that never committed.

IW22 exists on S/4HANA and behaves the same as in ECC; the underlying notification tables and status logic are unchanged. Fiori apps for processing and changing maintenance notifications provide the same core functionality with a simplified layout aimed at technicians on mobile devices, but they typically expose a subset of the fields available in IW22, particularly around catalog code detail and partner maintenance. Complex notification editing, especially involving multiple items or causes, is still commonly done in IW22 even on S/4HANA.

Functional PM issue in almost all cases: status logic, catalog profile assignment, and partner determination are all PM customizing. Basis gets involved only for authorization object assignment or table locking during mass changes. A good handover includes the notification number, current status from JEST, the exact field that will not save, and whether a linked order exists.

Read IW21 first to understand what gets set at creation that later constrains IW22, then IW23 to see the display-only view a technician gets when they lack change authorization. IW28 and IW29 are the list transactions for finding notifications in bulk when tracing a data issue across many records. IW31 and IW32 cover the order side, essential for understanding why a linked order stops the notification from behaving the way IW22 alone would suggest. IE02 and IL02 are worth knowing because notification object references point to equipment or functional location records maintained there.