Preventive Maintenance Plan Not Generating Next Call
Most commonly the previous call's maintenance order was never technically completed, and the plan's completion requirement flag is holding the next cycle back. Other frequent causes are a missing or failed deadline monitoring background job, a plan or item deactivation flag left set, or a performance-based plan waiting on a counter reading that nobody posted.
Covers why a strategy or single-cycle maintenance plan stops producing orders or notifications on schedule, working through completion requirement logic, deadline monitoring job failures, deactivation flags, and counter-reading gaps. Gives the check sequence through the scheduling overview and job monitoring, and separates data fixes from configuration changes that need a transport.
Published 16 Sept 2026· 1,113 words
The business symptom
Maintenance planning or the shop floor reports that a piece of equipment is overdue for its scheduled inspection or lube round and no work order exists for it. Sometimes it is phrased as the plan stopped working after last month, or the plant says this used to come automatically and now nothing shows up in the work list. Occasionally it surfaces as a compliance finding: an inspection interval required by regulation or insurance was missed because the system never raised the call. The complaint is rarely phrased as a scheduling problem at first, it is phrased as a missed maintenance event, and someone eventually notices the maintenance plan itself has not moved forward on its scheduling overview.
The configuration behind it
- Completion requirement active on the plan and the previous call's order was never technically completed or confirmed. For plans with completion requirement, the next call is only calculated after the prior order reaches technical completion, so an order left in released or partially confirmed status silently blocks all future scheduling, even though the plan looks healthy.
- Deadline monitoring background job not scheduled, cancelled, or running against the wrong plant or plan group. Time-based and performance-based scheduling is only recalculated when the deadline monitoring step actually runs; if the periodic job was removed during a system refresh or basis maintenance window, plans simply stop advancing with no error visible to the planner.
- Performance-based or multiple-counter plan waiting on a counter reading. If nobody has posted a measurement document against the linked measuring point, performance-based scheduling has no data to calculate the next call date and the cycle sits idle indefinitely.
- Deactivation indicator set on the maintenance plan or on an individual maintenance item, often left over from a previous decommissioning or test transport that was never reverted.
- Strategy sequence exhausted because the maintenance strategy is not marked as cyclic. Once the last package in a non-cyclic strategy has fired, scheduling stops by design rather than by error, and this is frequently mistaken for a bug.
- Call horizon percentage set too high, so the system correctly calculates a next date but will not generate the call object until much closer to due date than the business expects.
- Scheduling parameters changed mid-cycle, for example shifting the start date or cycle length after calls have already been generated, leaving the scheduling algorithm with an inconsistent basis date.
What to check
- IP19 or the scheduling overview for the plan: check the last call date, the status of the cycle, and whether the next planned date was ever calculated.
- IW39: check the status of the maintenance order or notification generated by the last call. If it is not technically complete, that is very likely the block.
- SM37: check whether the periodic deadline monitoring job actually ran on schedule and completed without errors, and for which plant or plan group selection it executed.
- IP30: run deadline monitoring manually in test or list mode for the specific plan to see what the system calculates and whether it flags a reason for not generating a call.
- IK17 or the relevant measuring point display: for performance-based plans, confirm a recent counter reading exists and is dated after the last call.
- IP02 or IP03: open the plan itself and check the deactivation indicator, the completion requirement flag, the call horizon, and the scheduling parameters against what the business expects.
How to prove it in the data
Pull the scheduling overview for the plan and line it up against the order list for the equipment or functional location over the same period: show the last generated order number, its technical completion date if any, and the date deadline monitoring last executed successfully for that plan or plan group from the job log. If performance-based, add the last posted counter reading date. That triple, plan status, order completion status, and job execution history, is what turns anecdotal a business anecdote into a diagnosable case.
Resolution path
If the block is an incomplete predecessor order, this is a data fix: get the order technically completed or confirmed through the normal process, then rerun deadline monitoring for that plan. If the deadline monitoring job itself was not scheduled or was cancelled, this is an operational fix owned by basis or the PM job scheduler, restore the recurring background job; no transport is needed unless the job variant selection criteria were also wrong, in which case the variant change may need to move through transport depending on how job variants are managed in that landscape. A deactivation flag left on the plan or item is a data fix, reactivate in IP02 and rerun scheduling. A missing counter reading is a data fix, post the measurement document. A non-cyclic strategy that has legitimately exhausted its sequence is a configuration decision, not a defect, correcting it to cyclic behavior is a change to the maintenance strategy master and should go through transport with sign-off, since it affects every plan using that strategy. A call horizon or scheduling parameter that is simply set wrong for this plan is a data change inside the plan itself and does not need a transport.
The fix people try first (and why it fails)
The reflex fix is to create the missing order manually in IW31 to satisfy the immediate business demand, or to force the plan forward by entering a fabricated completion date on the old order just to unblock scheduling. Both mask the underlying block instead of fixing it. The manual order breaks the audit trail back to the plan and the next cycle will hit exactly the same wall next time. Faking a completion date corrupts the maintenance history used for reliability reporting and can misrepresent when work actually happened, which becomes a problem in an audit or a warranty claim.
Whose problem this is
The PM planning team or plant maintenance key user owns the plan configuration and completion discipline; basis or the job scheduling owner owns the recurring deadline monitoring job. The handover note should carry the plan number, the last call's order number and its completion status, the deadline monitoring job log for the relevant run, and whether the fix applied was a data correction or a strategy configuration change requiring transport.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-functional-issues/preventive-maintenance-plan-not-scheduling-the-next-callERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.