IW31 — Create Plant Maintenance Order

IW31 creates a maintenance order: the object that carries planned operations, work centers, components, and costs for a piece of maintenance work, whether corrective, preventive, or inspection related. The order can stand alone or be created with reference to a notification, a piece of equipment, or a functional location. The single structural fact that explains most confusion around IW31 is that the order type chosen on the initial screen is not a label, it is a configuration key that determines the number range, the screen layout (which tabs and fields appear), the default settlement rule behavior, and which object information (equipment, functional location, cost center) is mandatory versus optional. Two consultants entering what looks like the same job under two different order types can end up with orders that behave completely differently at release, confirmation, and settlement.

IW31 is reached for in two situations: creating a maintenance order directly for planned or unplanned work with no prior notification, or converting an already-created notification (from IW21 or IW22) into an order for execution. It sits between the demand-recognition step (a notification, a maintenance plan call, or a breakdown report) and execution (confirmation via IW41, goods movement, time entry). If a maintenance plan is scheduling recurring work, the order is usually generated automatically through the plan call rather than typed manually into IW31, so a consultant reaching for IW31 by hand is usually handling either ad hoc corrective work or a manual conversion from a notification that was not auto-converted.

To confirm an order exists and what it points to, pull AUFK on the order number to get order type and plant, then AFIH on the same order number to see the functional location, equipment, and notification link. Cross-check ILOA using the object number stored on AFIH to confirm the object list entry actually resolves to a valid equipment or functional location master record. To confirm status, filter JEST on the order's object number for the current status flag set to X; a missing release status (I0002 equivalent) explains why goods movements or confirmations are being rejected downstream.

IW31 remains available and functionally unchanged in its core logic on S/4HANA; order type configuration, number ranges, and the underlying tables behave the same way. S/4HANA adds a Fiori app for creating maintenance orders with a simplified layout aimed at planners, but the classic GUI transaction continues to be used heavily, particularly for orders with complex operation lists or component structures that the Fiori app does not fully expose. There is no forced replacement of IW31.

This is functional PM ground first: order type configuration, settlement profiles, work center assignment, and object list issues are all customizing or master data problems for the PM consultant to resolve. Escalate to ABAP only when a custom user-exit or BAdI implementation is rejecting valid data at save. Escalate to Basis for number range exhaustion or authorization failures. A good handover includes the order number (if one was created), the order type, the exact error message text, and whether the failure happened at save or later at release/confirmation.

Read IW21 and IW22 first to understand how notifications feed into order creation and what gets carried across at conversion. IW32 and IW33 cover changing and displaying the order after creation, including release and technical completion. IW38 and IW39 are the list transactions used to find and mass-process orders once volume grows beyond single-order handling. IL01/IL02/IL03 and IE01/IE02/IE03 cover the functional location and equipment masters that IW31 depends on for a clean object reference, and IP10 explains how orders get generated automatically from a maintenance plan rather than typed manually.