MPOS table — MPOS Maintenance Plan Item Table

A row in MPOS is one maintenance item belonging to one maintenance plan. The maintenance plan (MPLA) carries the scheduling logic - cycle, strategy, start date - while MPOS carries the assignment of that scheduling to an actual technical object and task list. The technical object is not stored directly as an equipment or functional location number; it is stored as a generic object list key (ILOAN) that is resolved in ILOA to whichever object type actually applies. A single maintenance plan often contains more than one MPOS row, for example when several pieces of equipment are serviced on the same call dates under one plan. MPOS does not hold the next due date, the cycle length, or the generated order number - those come from the plan header and the call history table.

MANDT is the client field and must always be restricted. MPOS is not enormous by itself but it is unusable as an entry point without a starting key - do not scan it cold. The practical path is almost always object-first or plan-first: pull the equipment or functional location number, find its ILOAN in ILOA, then select MPOS on ILOAN, or start from a known plan number in MPLA and select MPOS on WARPL. WARPL plus WAPOS is the unique key, so once both are known the lookup is a single-row read. Avoid filtering on task list fields alone (PLNTY, PLNNR, PLNAL) as a starting point; many unrelated items can share the same task list.

Symptom: a piece of equipment is not generating maintenance orders even though its plan looks active. Find the equipment's EQUNR in EQUI, take its ILOAN from ILOA where EQUNR matches, then select MPOS where ILOAN equals that value to get WARPL and WAPOS. From WARPL, check MPLA for the plan's active/deactivated flag and start conditions, and check MHIS for the last recorded call against that WARPL. If MPOS returns no row at all for the resolved ILOAN, the equipment was never assigned to any plan in the first place.

MPOS continues to exist in S/4HANA in the same role, carrying maintenance items beneath a maintenance plan. Maintenance planning has not been restructured in a way that removes or renames this table in publicly documented material, though newer Fiori-based maintenance planning apps may read through compatibility views rather than the table directly. Treat the underlying table structure as stable and verify any specific release behaviour against the system rather than assuming parity with ECC in every detail.

Maintenance planning setup and the correctness of plan-to-object assignments belong to the PM/EAM functional consultant working with the maintenance planning department. Mass corrections or migration-related cleanup of MPOS rows are a data-migration or functional consultant task, not a basis one; basis involvement is only needed for performance issues on very large selections.

MPLA is the maintenance plan header this table hangs off. ILOA resolves the object list key to equipment or functional location. MHIS holds the call and scheduling history for the plan. EQUI and IFLOT are the technical object masters reached through ILOA. AFIH is the order header data reached once a call actually fires. Maintenance items are maintained through the maintenance plan transactions, and task list assignments are maintained through the general or equipment task list transactions.