Notifications are a SAP business object that is used in multiple modules to record structured documentation of a piece of information or a problem.
Notifications have a Notification Type that determines the functionality and interface of the notification. They are used in the following modules:
| Module | Type of Notification |
|---|---|
| PM (Plant Maintenance) | Maintenance Notification |
| PS (Project System) | Claim Notification |
| QM (Quality Management) | Quality Notification |
| CS (Customer Service) | Service Notification |
| LO-ECH (Engineering Change Management) | Change Notification |
As we’ll see below, notifications can be created in many different modules with module-specific transactions. There are, however, very generic transactions for notification management that can be used to create notifications of any type.
These are IQS1 / IQS2 / IQS3 to create, change and display a notification. For less experienced users, there is a set of transactions that makes use of the simplified notification view, removing a lot of fields from the user’s attention and showing only what is important. They can be called with the transaction codes IQS21 / IQS22 / IQS23. There are also generic lists for notifications (IQS8) and notification tasks (IQS9) available. The tasks of a notification can even be managed directly, using IQS12 (change task) and IQS13 (display task).
Maintenance notifications are a very important element in the plant maintenance process. They are usually triggered when a breakdown or damage occurs, or generally when a maintenance activity needs to be performed. Their content informs the maintenance department about the type of maintenance activity to be performed, and about the timeframe of a maintenance task or breakdown. They can be linked to maintenance orders to provide visibility.
Using catalogues, maintenance notifications can contain very detailed information about damages, damage locations, causes or activities, while still allowing structured reporting. Maintenance notifications are often considered as the leading object when it comes to audit-safe maintenance documentation in the SAP ERP system.
Maintenance notifications can be created, changed and displayed using the transactions IW21 / IW22 / IW23. There are maintenance notification lists that are called with IW28 (change maintenance notifications), IW29 (display maintenance notifications) and IW30 (Multi-level notification list). Additionally, there are detail lists such as a list of notification activities (IW64 / IW65), a list of notification tasks (IW66 / IW67), and a list of notification items (IW68 / IW69).
Claims are used in SAP PS to document an extraordinary situation or issue within a project. They are most often used when there are deviations from plan regarding an interaction with a customer or vendor (for example a late delivery that impacts the project plan), but can also relate to an internal activity. This is reflected in the “Partner Type” of the claim.
As with all notification types, it’s possible to define activities and responsible persons to resolve the issue. There is an entire SAP documentation chapter regarding claim management. Claims are created, changed and displayed with the transactions CLM1 / CLM2 / CLM3. Transaction CLM10 provides a list overview of all claims, while CLM11 creates a hierarchical claim list that displays some of the claim contents, such as tasks or activities.
Quality notifications can be used to document issues regarding insufficient quality of goods or services. That includes complaints against a vendor, complaints made by customers, or internal quality problems. Quality notifications can, of course, also be linked with a catalog profile.
The transactions that are used to create and manage quality notifications are QM01 / QM02 / QM03. Apart from that, the exact same transactions that are available in the PM module are also there for QM. These include notification lists such as QM10 (change list), QM11 (display list), and QM19 (multi-level list). The detail lists for tasks (QM12 / QM13), items (QM14 / QM15) and activities (QM16 / QM17) are also available. One additional transaction that PM doesn’t have is QM50, the graphical overview of notification creation that allows quick insights about quality problems.
Service notifications are deduced from maintenance notifications and, in fact, share a lot of their functionality – not surprising since the CS module is built on top of PM. Service notifications are designed as a place to record customer enquiries that can lead to service orders. It is possible to record tasks and activities, and create service orders to trigger follow-up action. It also has some unique functionality, such as the linkage to service contracts (SD contracts) or the triggering of advance shipment for CS orders.
Service notifications share some transactions with maintenance notifications, but they have their own transactions to create (IW51), edit (IW52) and display (IW53) them. They also have their own list transactions for change (IW58) and display mode (IW59). When it comes to notification content however, they share the lists with the PM module: IW64/IW65 (activities), IW66/IW67 (tasks) and IW68/IW69 (items) are used here. Also, the multi-level list for service notifications (IW30) is the same as for plant maintenance.
Change notifications are used to request and/or document changes to product data that is controlled by Engineering Change Management (LO-ECH), such as recipes or bills of material. An Engineering Change Order (ECO) can be created out of a change notification.
LO-ECH does not have its own transactions to manage notifications. Instead, it uses the generic IQSx transactions discussed above to create, edit and display notifications.