IW23 — Display Maintenance Notification
IW23 opens a maintenance or quality notification in display-only mode, showing header data, items, causes, tasks, activities, and any linked order. It is the read-only counterpart to IW22 (change) and IW21 (create). Most confusion around it comes from users expecting to edit fields that are simply locked because the transaction itself is display-only, not because of an authorization or status problem.
This page covers IW23, the transaction used to view an existing maintenance notification without changing it. It focuses on how the notification data model splits across header, item, cause and task tables, and on the diagnostic checks that separate a real data problem from a display-only false alarm.
Reviewed by an ERPClimb SAP consultant on 15 Sept 2026· 1,123 words
What it does
IW23 renders an existing maintenance notification for viewing: header data (functional location, equipment, priority, dates), items describing the malfunction, causes, and the tasks or activities logged against it. It is functionally read-only regardless of the user's change authorization elsewhere in the system. The one fact that explains most support tickets on this transaction is that a notification's data lives across several linked tables (header, items, causes, tasks), not one flat record, so a field that looks missing on the main screen may simply be sitting on a different tab or subscreen, or may genuinely not have been entered when the notification was created. IW23 does not show order costs directly even when an order is linked; that detail belongs to the order display transaction.
When it is used
IW23 is the reflex tool whenever someone needs to check what was actually recorded on a notification without risking an accidental change: verifying a breakdown description before approving an order, checking who reported a fault and when, confirming whether a notification has already been converted into an order, or reviewing catalog codes (damage, cause, activity) during a quality review. Helpdesk and shift-handover checks often start here before escalating to IW22. On S/4HANA, the same review is commonly done through the Fiori 'Manage Maintenance Notifications' app or a monitoring app when the user needs a worklist rather than a single record; IW23 remains the fast path when the notification number is already known.
How to use it
- Start IW23 from the SAP Easy Access menu or by transaction code entry.
- Enter the notification number directly if known, or use the matchcode to search by functional location, equipment, order, or reported-by user.
- Alternatively, run IW28 or IW29 to get a worklist of notifications, then double-click a line to jump into display mode.
- Review the header tab for type, priority, dates, and location or equipment reference.
- Check the item, cause, and task tabs for damage codes, root cause codes, and any follow-up actions recorded.
- Check the 'order' field on the header to see whether the notification has been converted to a maintenance order, and note that order costs are not shown here.
Key fields
- QMEL - notification header: notification number, type, functional location, equipment, dates, priority, linked order number.
- QMFE - notification items: individual malfunction entries with damage code and code group.
- QMUR - causes recorded against the notification.
- QMMA - tasks or activities planned or completed on the notification.
- JEST and JCDS - current and historical status records for the notification's status profile.
- STXH and STXL - long text objects for header and item notes if long text was entered instead of a coded item.
How to prove it in the data
Pull the header from QMEL filtered on QMNUM to confirm the notification exists and to read its priority, functional location, equipment, and any order number in the order field. Cross-check current status by reading JEST for that object key and filtering on the notification's object type, then decode the status codes against the status profile. To confirm items, causes, or tasks are actually populated rather than just not visible on the screen, query QMFE, QMUR, and QMMA respectively on the same QMNUM; an empty result set there, not a display glitch, is the real explanation when a tab looks blank.
ECC vs S/4HANA
IW23 continues to function as a classic transaction on S/4HANA and the underlying notification tables (QMEL, QMFE, QMUR, QMMA) are not renamed or restructured the way order-related tables were. The practical difference is on the front end: S/4HANA offers Fiori apps for managing and monitoring notifications with worklist and analytics capability that IW23 does not provide. For a single known notification number, IW23 remains a faster and equally valid way to check the record.
Common pitfalls
- Perceived edit lock: user reports IW23 will not let them change a field. This is expected behavior, not a bug; the fix is to use IW22, not to chase an authorization trace on IW23.
- Notification appears empty on a tab: the item, cause, or task subscreen shows nothing. Check whether the data was ever entered by querying QMFE, QMUR, or QMMA directly; frequently the notification was created with only a long text description and no coded items, so the coded-item tab is legitimately blank.
- Notification not found: entering a number returns no result. Confirm the number range matches notification number ranges, rule out a typo against an order number (order and notification number ranges can look similar), and check whether the notification was archived or deleted, which removes it from online display entirely.
- Status looks stale: notification shows an open status while the linked order is technically closed, or vice versa. Read JEST/JCDS for both objects; notification and order status are maintained separately and only synchronized at defined points in the process, so a mismatch during the workflow is often correct, not corrupt data.
- Catalog codes show as blank or as raw codes instead of descriptions: this points to a mismatch between the notification's catalog profile and the code group/catalog master data, not a display transaction fault.
- Order field is blank when a follow-up order was expected: confirms the notification was never technically converted to an order; check whether someone created a standalone order instead of using the notification-to-order conversion, which would leave no link back in QMEL.
Whose problem this is
This is a functional PM or CS problem in almost every case; IW23 itself rarely breaks. Escalate to ABAP only if a custom field or enhancement on the notification screen fails to render. A good handover includes the notification number, which tab or field looks wrong, and the output of a direct SE16 check on the relevant table (QMEL/QMFE/QMUR/QMMA) so the functional owner is not asked to re-verify data that has already been confirmed present or absent.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tcodes/iw23ERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.