IE02 — Change Equipment Master Record

IE02 opens an existing equipment master record for editing. Equipment represents a physical or logical object tracked individually for maintenance, cost, and history purposes: a pump, a vehicle, a piece of production machinery, a meter. The transaction exposes the record as a set of tabs (general data, location, organization, structure, classification, partner, warranty, permits, MRP for PM, and others depending on configuration). The single fact that explains most support tickets against IE02 is that equipment data is not one flat record. General data lives in one time-independent table; location, cost center, and installation data live in a time-dependent table with validity periods. Changing where equipment is installed, or which cost center it belongs to, does not update a field in place. It closes the current time slice and opens a new one, which is why equipment history looks like a list of overlapping periods rather than a single current value.

IE02 is reached after IE01 creation, whenever an existing piece of equipment needs a change: installation at or removal from a functional location, a change of maintenance planning plant or planner group, addition or update of classification characteristics, a warranty extension, a change of superior equipment in an equipment structure (equipment BOM), or a status change such as deactivation. It also gets used during mass data corrections after a plant reorganization, when equipment needs to be reassigned to new cost centers or functional locations in bulk (usually scripted rather than done one record at a time in the GUI). Consultants reach for IE03 instead when only a look is needed, for IL02 when the change belongs to the functional location rather than the equipment, and for the Fiori equipment management app on S/4HANA when the change is a routine field update that the app covers.

In SE16 on EQUZ, filter by equipment number and list all rows ordered by validity end date. More than one row confirms an installation or organizational change history exists; the row with the far-future end date is the current segment. Cross-check the location fields on that current row against ILOA to see which functional location, cost center, and plant are actually assigned today. If a user reports a change that did not take, check JEST for an active status that blocks the field group in question before assuming the save failed silently.

IE02 runs unchanged in SAP GUI on S/4HANA, writing to the same EQUI and EQUZ structures. A Fiori app for managing equipment exists and covers common changes such as location reassignment and status updates, but it does not expose every tab available in IE02, so consultants still fall back to the GUI transaction for classification, permits, or less common field groups. No underlying data model restructuring took place for equipment master data.

Functional PM/EAM consultant owns IE02 configuration, field selection, and status profile design. ABAP gets involved only for custom fields added through the standard enhancement points on the equipment master or for BAdI-driven validation logic. A clean handover states the equipment number, the exact tab and field affected, the current EQUZ validity dates, and the active system status, not just 'the change did not save'.

IE01 is the creation counterpart and worth reviewing first to understand which fields are mandatory at creation versus editable later. IE03 is the display-only view, useful for confirming a change landed without risking an accidental edit. IL02 is the equivalent change transaction for functional locations and shares the same time-dependent data pattern, so understanding one clarifies the other. IH01 shows the equipment structure and functional location hierarchy, useful for confirming installation and superior equipment changes actually took effect in context. IW32 is worth knowing because open orders against the equipment are a common source of the enqueue lock pitfall described above.