IP10 — Maintenance Plan Scheduling for a Single Plan

IP10 executes the scheduling logic for one maintenance plan: it reads the plan's strategy or single cycle, the cycle counters or time intervals attached to each maintenance item, and computes when the next call is due. If the due date has arrived, it can trigger generation of the associated call object, typically a maintenance order or a notification, depending on how the plan was configured. The structural fact that causes most confusion is that scheduling and calling are two separate events: running IP10 computes and displays due dates as a simulation, but nothing is created in the plant until the call is actually executed, either by the user forcing it inside IP10 or by the background scheduling job picking it up. A plan can look overdue for weeks with nobody noticing because the simulation ran but the call never fired.

IP10 sits between maintenance plan configuration (IP01 to IP03 style maintenance for strategies, and IP02 for the plan itself) and the generation of executable work in IW21 to IW38. A consultant reaches for it during plan setup and testing, to verify that a new cycle set or strategy produces sensible due dates before it goes live, and during incident troubleshooting, to check why one specific plan has not called work when the business expects it. For the full population of plans running in production, the mass job is IP30, executed nightly or periodically in background; IP10 is not the tool for volume scheduling, it is the tool for isolating and explaining the behaviour of a single plan.

In SE16 open MHIS and filter on the maintenance plan number. Compare the scheduled due date field against the actual call date field for the most recent entries; a due date in the past with no corresponding call date confirms scheduling ran but calling did not happen. Take the order or notification number recorded against the last successful call and look it up in the order or notification table to confirm it exists, is not deleted, and has advanced past created status. If the plan uses a counter-based item, check the counter reading table for the object to see whether a reading was posted after the last call date.

IP10 exists and behaves the same way on S/4HANA; the underlying tables MPLA, MPOS, and MHIS are unchanged in structure and purpose. Mass scheduling for production use still normally runs through IP30 as a background job. Some Fiori monitoring apps for maintenance planning exist for viewing plan status and upcoming calls, but the core scheduling logic and the single-plan transaction itself have not been replaced.

This is functional PM/CS territory. The plant maintenance planner or PM consultant owns strategy design, cycle sets, and plan configuration. ABAP involvement is limited to custom logic in call object generation if it has been enhanced. A good handover to Basis, if the issue is background job related, states which job variant runs the mass scheduling and its last successful run time; a handover to functional support should include the plan number, the last MHIS entry, and the status of the last generated order or notification.

IP30 is the mass equivalent used for production scheduling across the whole plan population and is the first place to check whether a background run is even happening. IW31, IW32, and IW33 are relevant once a call generates an order, since order status and completion directly affect whether the next scheduling cycle advances. IE01, IE02, and IE03 matter for counter-based plans, since counter readings live against the equipment master, not the plan. IH01 helps confirm the technical object hierarchy referenced by the plan's maintenance item.