IW29 — Display PM Notifications List
IW29 is the display-only list transaction for PM and CS notifications (malfunction reports, maintenance requests, activity reports). It runs a selection report against notification header and item tables and returns an ALV list. No data can be changed from this transaction; double-clicking a line opens the notification in display mode (IW23), not in change mode.
IW29 is the reporting counterpart to IW28, used to pull lists of maintenance notifications by plant, order, equipment, functional location or person responsible for review and monitoring purposes. This page covers the selection logic that most often hides expected data, the tables the list actually reads, and how to diagnose an empty or wrong result set.
Reviewed by an ERPClimb SAP consultant on 15 Sept 2026· 1,007 words
Purpose
IW29 is the list display transaction for PM and CS notifications: malfunction reports, activity reports, and maintenance requests. It presents a multi-field selection screen and returns results as an ALV list, strictly read-only. The structural fact that causes most confusion is that IW29 and IW28 share the same selection screen and near-identical list layout; the only real difference is that IW28 permits mass changes from the list and IW29 does not. A second source of confusion is the default status radio button on the selection screen, which frequently restricts the result to outstanding notifications only, so completed or closed items appear to be missing when they are simply filtered out.
When it is used
IW29 is reached for during reporting and monitoring activity rather than processing: shift handover reviews, weekly backlog checks, KPI extracts, pre-shutdown status reviews, or ad hoc checks of what has been reported against a functional location or equipment. It is preferred over IW28 whenever the user should not be able to accidentally change a notification, and it is often the transaction handed to plant supervisors or reliability engineers who need visibility but not edit rights. In S/4HANA environments with embedded analytics, a Fiori list app covering the same notification data is the equivalent entry point for users working outside the SAP GUI.
How to use it in practice
- Open IW29 and set the organizational restriction: plant or planning plant is mandatory in most configurations.
- Narrow the selection using order number, notification number, equipment, functional location, work center, or person responsible.
- Set the notification date range: creation date, malfunction start, or required end, depending on what is being checked.
- Choose the status selection radio button: outstanding, completed, or all notifications; the default often excludes completed items.
- Execute and review the ALV list; adjust the layout or apply a saved variant to add status, priority, or breakdown duration columns.
- Double-click a line to drill into the notification in display mode (routes to IW23); use this to confirm details, not to edit.
Key data objects
- QMEL - notification header: notification number, type, priority, dates, functional location, equipment, order reference.
- QMFE - notification items: damage and cause codes, object parts affected.
- QMMA - tasks recorded against the notification.
- QMUR - causes recorded against the notification.
- JEST and JCDS - status management, holding the current and historical object status linked via the object number on QMEL.
- IHPA - partner data, including the person responsible and work center assignment shown on the list.
How to prove it in the data
Pull QMEL filtered by plant (IWERK), notification type (QMART), and date range to reproduce the selection the user ran. Take the object number (OBJNR, built from the notification number) and look it up in JEST joined to TJ30T to see the actual current status text; this explains why a notification the user expects to see is excluded under an 'outstanding' filter. Cross-check IHPA for the person responsible filter, since a mismatch there silently drops rows without any error message.
ECC vs S/4HANA
IW29 exists unchanged in S/4HANA and continues to run against the same notification tables; the underlying selection logic and status model were not restructured. The list output uses the standard SAP list viewer as before. For users working in Fiori-first setups, a maintenance notification list app provides equivalent filtering with a more modern interface and easier mass export, but it does not replace IW29 in the GUI-based support workflow.
Common pitfalls and how to diagnose them
- Status filter hiding rows: the outstanding-only default on the selection screen excludes completed and closed notifications; before assuming data loss, rerun with the all-notifications status option.
- Silent authorization gaps: missing authorization on notification type or planning plant returns an empty or partial list with no error, since the authorization check filters rows rather than blocking the transaction; check the user's authorization trace before touching configuration.
- Wrong date field selected: users frequently filter on notification creation date when they mean malfunction start or malfunction end, producing a result set that looks incomplete for the period under review.
- Confusing display with edit: IW29 never allows changes; if a user reports that a field cannot be updated, this is expected behavior, not a bug, and the correct redirect is IW22 or IW28.
- Notification without an order: notifications created without a linked maintenance order show blank order-related columns in the list; this is normal for pure reporting-only notifications and not a data error.
- Layout variant carrying stale filters: a saved ALV layout can carry hidden column filters set by a previous user, producing an apparently short list even though the underlying selection was correct.
Whose problem this is
This is a functional PM or CS issue in almost every case: selection scope, status filters, and authorization for notification types belong to the plant maintenance or customer service configuration owner. ABAP involvement is limited to custom selection-screen fields or enhanced list layouts. A good handover includes the exact selection variant used, the status radio button setting, and the notification number expected to appear but missing.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tcodes/iw29ERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.