IW38 — Change PM Orders List Editing Transaction
IW38 selects a list of maintenance or service orders by plant, order type, planner group, work center or status, and lets the planner change several of them at once directly from the ALV list or drill into individual orders. It is the multi-order counterpart to IW32, used for mass release, mass technical completion, mass closing and date shifts.
IW38 is the worklist transaction planners use to select and mass-change PM/CS orders rather than opening each order individually. This page covers the selection logic, what can actually be changed inline versus what forces a drill-down to IW32, and the diagnostic order for the failures that show up most often: over-broad selections, locked orders, status blocks and silent authorization rejections.
Reviewed by an ERPClimb SAP consultant on 15 Sept 2026· 1,150 words
Purpose
IW38 runs a selection report against maintenance and service orders and returns an ALV list that supports both mass actions and navigation into individual orders. The structural fact that causes most confusion is that IW38 and IW39 share the same underlying selection engine; IW38 is not a different data model, it is the same list with edit rights switched on. A second source of confusion is that not every column on the list is truly editable in place. Status changes, priority, dates and some header fields can be changed via mass change functions on the selected rows, but operations, components, permits and long text require double-clicking into the order, which opens IW32 in change mode for that single order.
When it is used
IW38 is reached for whenever a planner or consultant needs to work a backlog rather than one order: releasing a batch of orders after weekly planning, technically completing a set of orders after a shutdown, shifting basic dates across a work center's queue, or pulling a reconciliation list of orders in a given status for a plant. IW32 is the right tool when a single order needs detailed work on operations, components or costs. A Fiori worklist app is the right tool when the site has moved planners onto the Fiori experience and needs simple mass release from a tile; IW38 stays the tool of choice when the requirement is heavier filtering, layout variants, subtotals, or export to a spreadsheet for offline analysis.
How to use it in practice
- Call IW38.
- Fill in selection criteria: order type, plant, planner group, main work center, system status, basic start or finish date range. Leaving all fields open triggers a full-table selection and a performance warning on any sizeable system.
- Execute to bring up the ALV order list.
- Adjust the layout to bring in the fields needed for the task at hand: dates, status, cost, settlement rule indicator.
- Select one or more rows and use the mass change or mass status function from the menu, or double-click a row to open that order in IW32 for detailed change.
- Save.
Key data objects
- AUFK - order master record: order number, order type, plant, business area, responsible cost center.
- AFKO - order header for scheduling data: basic start and finish dates, scheduled dates.
- AFVC and AFVV - order operation data, only reached when the list drills into an individual order.
- JEST - current object status per order or operation, keyed on object number.
- JCDS - status change history, one row per status transition, used to confirm when a mass action actually fired.
- ILOA - link from the order's object number to the functional location or equipment it is maintaining.
How to prove it in the data
Pull the object number from AUFK for the orders in question, filtered by order type and plant. Join to JEST on OBJNR, filtering INACT blank to see the currently active status codes. To confirm a mass action from IW38 actually landed, check JCDS for the same object number and look at the change timestamp and user against the time the planner ran the transaction. If a date shift was expected, compare AFKO-GSTRP and GLTRP before and after against what the planner intended; a mismatch usually means the row was selected but the mass change was rejected silently by a status block, not that the transaction failed to save.
ECC vs S/4HANA
IW38 is available unchanged on S/4HANA and remains fully supported; it has not been withdrawn or replaced. The underlying master tables AUFK and AFKO are unchanged. S/4HANA adds Fiori worklist apps for maintenance orders that cover simple mass release and status change scenarios with a lighter interface, but they do not fully replace IW38's selection depth and layout flexibility for heavier planning and reconciliation work.
Common pitfalls and how to diagnose them
- Over-broad selection: no plant or date restriction entered, the system starts a full scan across all order types and either times out or returns a list too large to be usable. Fix by re-running with at least plant plus a date or status restriction rather than raising a background job memory parameter.
- Status block on mass change: a mass release or mass technical completion is requested on orders that carry a user status which does not permit that transition, or that are missing a settlement rule required before closing. The list shows the rows as selected but nothing changes after the action; check the individual order's status log via IW33 or the JCDS history before assuming the transaction is broken.
- Order locked by another session: a planner has the same order open in change mode elsewhere, IW38's mass action fails for that one row with an enqueue message while the rest of the batch processes normally. Isolate the failing order and check who holds the lock rather than re-running the whole batch.
- Field not editable from the list: attempting to change operation-level or component-level data directly in the ALV; these fields are display-only at list level and require the double-click into IW32. This is expected behavior, not a bug.
- Silent authorization rejection: the user can select and display orders outside their planning plant or planner group but the mass change is rejected for those rows without a clear pop-up if the authorization check is buried in a background-style mass function. Confirm the user's authorization object for plant and planner group before escalating as a technical defect.
Whose problem this is
This is functional PM/EAM territory in the first instance. Basis gets involved only if an over-broad selection is causing a genuine database load or timeout issue. ABAP gets involved only if a custom mass change exit or enhancement was built on top of the standard list. A good handover includes the selection variant used, the specific order numbers affected, the status or date expected versus what actually landed, and the JCDS history for at least one affected order.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tcodes/iw38ERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.