Maintenance Notification Stuck, Will Not Complete

Planner or technician tries to close a notification and the status will not move to completed. In business language: the order is done, the equipment is running again, but the notification stays open in the worklist week after week no matter how many times someone tries to save it. Sometimes a message names a missing field or a locked status; sometimes nothing visible happens and the status simply reverts on save. Usually reported by plant maintenance planners clearing the weekly backlog, or by controlling and reliability engineering when they notice notifications still open against orders that were technically completed and settled months earlier. Often escalated as a system defect, when in most cases the notification-order dependency or a mandatory field on the notification type is doing exactly what it was configured to do.

Run IW28 for the notification type in question, selecting status not completed, and cross-check the linked order status column: a cluster where the order shows technically complete but the notification does not proves the sequencing dependency rather than a data entry gap. Separately, pull the same list with malfunction start/end blank to isolate the missing-field pattern. A high count against one notification type and not others points at that type's configuration.

If the order is not technically complete, that is a process sequencing issue, not a configuration defect: complete the order first in IW32, then return to the notification. If required malfunction, catalog or partner fields are missing, that is a data fix done directly on the notification in IW22, no transport needed. If open tasks or follow-up actions are blocking closure, close or delete them individually before retrying the header completion. If the block is the status profile sequence or a mandatory field flagged at the notification type level in the IMG, that is a configuration change owned by the PM functional consultant, requires impact analysis against other notification types sharing the same profile, and moves through a transport. Authorization gaps are resolved by the security team adding the missing object to the relevant role, again outside the functional configuration.

The reflex fix is to change the notification status directly in the underlying status table or through a background correction program, bypassing the business transaction check entirely. It appears to work because the notification shows as completed afterward, but it skips the validation that the status sequence exists to enforce, leaves malfunction or catalog data permanently blank, and can leave the notification and its linked order out of sync in a way that breaks later settlement or reporting queries. It also sets a precedent that gets repeated on every future stuck notification instead of fixing the missing field once.

Day to day, the plant maintenance planner or technician owns getting the data entered and the order sequence right. The PM functional consultant owns the notification type, status profile and catalog profile configuration. A handover note should list the affected notification numbers, the exact block message seen, the linked order's status, and whether the pattern is data (one-off) or configuration (systemic across a notification type).