IP30 — Deadline Monitoring for Maintenance Plans

IP30 executes deadline monitoring across a selection of maintenance plans. For each plan it checks the scheduling parameters - cycle length, counter readings, factory calendar, scheduling indicator - and, where the next due point falls inside the call horizon, creates the call object: a maintenance order, a notification, or both, depending on plan configuration. It also advances the plan's completion/scheduling status and writes the resulting call to the plan's history. The structural fact that causes most confusion is that IP30 always operates on a selection set, never a single plan in isolation. A plan that 'did not generate an order' is almost always a plan excluded from the selection, blocked by status, or not yet due, rather than a defect in the scheduling engine itself.

IP30 sits at the operational heart of preventive maintenance. It normally runs as a background job, once daily or per shift, so that due maintenance plans generate their next order automatically without a planner touching the transaction. Consultants reach for it manually in three situations: testing a new maintenance strategy or plan before releasing the background job, investigating why an expected order or notification did not appear on schedule, and forcing a rerun after correcting scheduling parameters or a counter reading. It is not used for single ad hoc work order creation - that goes through IW31 - and it is not a display tool for plan history, which is better reviewed through the plan itself or IH01.

Start in MHIS filtered on the maintenance plan number, sorted by planned call date descending. Compare the last entry's planned date and status against MPLA for that plan - specifically the scheduling indicator and the next-call date the plan currently carries. If MHIS shows no new row for a date that has passed, the plan was either excluded from the last IP30 selection, deactivated, or blocked by a deletion or completion status on MPLA. Cross-check the generated order in AUFK or notification in VIQMEL by call number to confirm the call object actually exists downstream.

IP30 is unchanged in structure and logic on S/4HANA and remains a classic GUI transaction; there is no full Fiori replacement for the mass scheduling run itself. Fiori apps exist to monitor upcoming and overdue maintenance plans and to review call history, which consultants use to spot scheduling gaps before diving into IP30, but the actual deadline monitoring job configuration and execution still runs through IP30 or its background job variant.

Functional PM/EAM owns the scheduling configuration - strategies, cycles, call horizon, and plan status - and is first responder for a missing call. Basis owns the background job that runs IP30 on a schedule and any failed job alerts. A handover to functional should include the plan number, the expected versus actual next call date from MPLA and MHIS, and whether the last background job run completed without error.

IP10 gives the scheduling overview across plans and is the natural first stop before drilling into a single plan's IP30 history. IW31 and IW21 are where the call object - order or notification - lands and can be inspected once IP30 confirms a call was generated. IH01 helps locate the object list behind a maintenance item when a plan appears to be missing its equipment or functional location assignment. IW38 and IW39 are useful to confirm whether an order created by IP30 actually progressed or was left in an unreleased state.