IW39 — Display Orders List Report

IW39 is the display variant of the order list report, giving multi-selection reporting across maintenance and service orders without granting the ability to save changes. The structural fact that explains most confusion: IW39 is not a separate report engine, it is the exact same ALV list transaction as IW38 running with change authorization withheld. Selection screen tabs, layout variants, sort and total functions, and field catalog are identical. When a consultant double-clicks a line in IW39, the system routes to IW33 (display order) rather than IW32 (change order). Reports of orders 'missing' from IW39 that turn out to exist in the database are almost always caused by the active selection variant or authorization profile restricting the result set, not by any difference in how IW39 reads data compared to IW38.

IW39 sits in the daily and periodic reporting layer of maintenance execution: backlog review, technician workload checks, aging analysis on open orders, KPI extracts for management, and pre-audit list pulls where a change-locked view is preferred deliberately. Consultants reach for it instead of IW38 whenever the list needs to go to someone without order-change authorization, or as a personal habit to avoid touching data while investigating a discrepancy. Compared to Fiori list apps for maintenance orders, IW39 remains the workhorse for ad hoc field selection, free totals and subtotals, and direct export to spreadsheet, and it is usually the first stop when troubleshooting 'why is this batch of orders still open' across many objects at once rather than one order at a time.

Start in SE16N on AUFK filtered by order type and plant to get a raw count, checking the deletion flag field. Join against JEST on the object number to see which status objects are currently active for those orders, then compare against the status filter used on the IW39 selection screen. If AFIH is involved, join on order number to confirm functional location or equipment values match the location filters entered. A gap between the raw table count and the IW39 result count almost always traces to a status or authorization restriction rather than a data problem.

IW39 is available and fully functional on S/4HANA with no structural change from ECC. Fiori analytical apps for maintenance order management overlay the same underlying data with richer filtering and visualization, but IW39 remains widely used for bulk export, custom layouts, and GUI-based ad hoc reporting, and is not deprecated. Consultants working in fallback GUI mode or building batch checks continue to rely on it exactly as before.

Primarily a PM or CS functional consultant's tool, used for reporting and diagnosis rather than configuration. Basis involvement is needed only for authorization object assignment or genuine performance issues surfaced via a trace. ABAP involvement is needed only if a custom field on a CI include or a custom layout requires development. A good handover includes the exact selection variant, the status filter values used, and a comparison of expected versus actual row count.

Pair IW39 with IW38 to understand the change-mode equivalent of the same report engine, since layouts and variants are interchangeable between the two. Review IW32 and IW33 for the single-order drill-down that IW39 routes into. IW29 and IW28 cover the same display/change pattern on the notification side, useful when orders are notification-driven. IP10 and IP30 are worth checking when the orders under review originate from maintenance plans, to confirm the plan scheduling matches what IW39 is reporting.