MPLA table — MPLA - Maintenance Plan Header Table

MPLA stores one row per maintenance plan created in transaction IP01 and maintained in IP02/IP03. The row carries the plan's category (single-cycle plan, strategy plan, or multiple-counter plan), the maintenance strategy assigned to it when relevant, and a link into the generic status management framework so the plan can be active, inactive, or flagged for deletion. It does not carry the equipment or functional location the plan is scheduled against, the task list used, or the order type generated - those live one level down, in the maintenance item table, because a single plan can drive several items against several objects. Scheduling execution (which call dates have fired, which orders or notifications resulted) is not stored statically on MPLA either; it is recorded in the call history table as the deadline monitoring program runs.

MPLA is a small table compared to its children, so the client field MANDT and a restriction on WARPL when the plan number is known are usually enough to keep a lookup fast. When the starting point is a technical object rather than a plan number, do not scan MPLA directly - go through MPOS restricted by EQUNR or TPLNR first, then pull the parent WARPL values into MPLA. When the question is about scheduling status or history, restrict MHIS by WARPL and a date range before joining back, since that table grows with every scheduling run and can be large even when MPLA itself is small.

Symptom: a maintenance plan did not generate the expected order. Select MPLA where WARPL equals the plan number and check MPTYP and the status via OBJNR first - an inactive or deletion-flagged status stops scheduling outright. If the status is active, check MHIS for that WARPL to see the last executed call date and whether a call was skipped or held. Then check MPOS for that WARPL to confirm the object, order type, and task list assignment are actually maintained and not blank.

MPLA is retained in S/4HANA as the maintenance plan header table; the underlying structure has not been replaced or absorbed into a different object. Reporting layers in S/4HANA increasingly expose maintenance plan data through CDS-based views for Fiori apps, but the plan creation and change transactions still write to MPLA and its child tables directly, and consultants troubleshooting scheduling issues still work from MPLA, MPOS, and MHIS rather than from the compatibility views.

The PM/EAM functional consultant owns plan design - category, strategy, cycle sequence - and is the first point of contact when a plan does not schedule as expected. Data volume and archiving of the call history sitting behind MPLA is typically a basis or data management concern once the table grows large, but the functional question of why a specific plan did not fire almost always lands on the maintenance planning consultant, not on basis.

MPOS holds the maintenance items under each plan and is where the technical object, order type, and task list actually sit. MHIS records the call history that shows what scheduling has actually executed. EQUI and IFLOT are the equipment and functional location masters referenced through MPOS. IHPA carries partner assignments such as person responsible, joined through the plan's object number. The plans are maintained through IP01, IP02, and IP03, scheduled through IP10, and monitored through IP30.