SAPFree referencePDF, Excel, Word exportSAP ECC / S/4HANA

SAP PM Notification Types Reference (M1, M2, M3)

In SAP Plant Maintenance, every piece of work starts as a notification. This reference lists the delivered notification types, the transactions you use to process them, the tables behind them and the statuses you will see, so you can answer a support question or design a report faster.

Download:

Code	Kind	Name	What it is and where you use it
M1	Notification type	Maintenance request	Delivered type for requesting work on a technical object without a failure. Often raised by operators or planners.
M2	Notification type	Malfunction report	Delivered type for failures. Carries breakdown indicator and malfunction start and end for downtime analysis.
M3	Notification type	Activity report	Delivered type for recording work done without a prior request, such as inspections or short tasks.
Z-types	Notification type	Customer notification types	Projects often add types for safety, quality or near miss so workflows and reporting stay separate.
IW21	Transaction	Create notification	Create a notification against equipment, functional location or assembly.
IW22	Transaction	Change notification	Edit text, items, causes, tasks and activities. Create an order from the notification here.
IW23	Transaction	Display notification	Read-only view of the notification and its history.
IW28	Transaction	Change notification list	List editing with selection by status, priority, planner group or dates.
IW29	Transaction	Display notification list	Read-only list for reporting and export.
QMEL	Table	Quality notification header	Header of every notification, including PM types. Holds notification number, type, dates and priority.
QMFE	Table	Quality notification items	Item level data such as damage code and object part.
QMUR	Table	Quality notification causes	Cause records linked to items.
QMSM	Table	Quality notification tasks	Task records on the notification.
QMMA	Table	Quality notification activities	Activity records on the notification.
OSNO	System status	Outstanding notification	Notification created and not yet taken into process.
NOPR	System status	Notification in process	Work on the notification has started.
NOPR+ORAS	System status	Order assigned	ORAS shows that an order is assigned to the notification.
NOCO	System status	Notification completed	Notification completed. Completion usually requires the required end date and time fields.
DLFL	System status	Deletion flag	Notification marked for archiving and deletion.
Catalog B	Catalog type	Object parts	Catalog used to code which part of the object was affected.
Catalog C	Catalog type	Damage	Catalog used to code the damage found.
Catalog 5	Catalog type	Causes	Catalog used to code the cause of the damage.
Catalog A	Catalog type	Activities	Catalog used to code what was done.
Catalog profile	Master data	Catalog profile	Assigned to equipment or functional location. Decides which code groups appear on notifications.
Priority	Field	Notification priority	Comes from a priority type assigned to the notification type. Drives required start and end dates.
Breakdown	Field	Breakdown indicator	Flags that the object was down. Used for downtime and availability reporting.
Malf start/end	Field	Malfunction start and end	Dates and times used to calculate breakdown duration and MTTR reporting.
Req start/end	Field	Required start and end	Planned window for the work, often derived from priority.
Planner group	Field	Planner group	Group responsible for planning and often used to filter lists and workflows.

Delivered types, status text and catalog codes vary by release and by project customizing. Check Customizing for Notification Types and catalog profiles in your own system.

Get a downtime query for your notifications

Tell us your release and we will send a read-only query pattern for breakdowns by object and cause. Optional, the reference is free without it.

Optional. The tool and every export work without this. No spam.

How to use the reference

Type a code or word to filter. Search M2 to see the malfunction report row, search QM to list the notification tables, or search Catalog to see the coding catalogs. Use the Kind column to narrow to transactions or statuses. Export the visible rows to Excel to attach to a design document or a test plan. If you are writing a query, filter by Table and use the rows as a quick reminder of which table holds the header, items, causes, tasks and activities.

M1, M2 and M3 explained

The three delivered types map to three business events. A maintenance request, M1, asks for work when nothing is broken. A malfunction report, M2, records a failure and carries the breakdown indicator and malfunction start and end, which feed downtime and MTTR reporting. An activity report, M3, records work already done. Many plants keep these three and add types for specific workflows such as safety observations. The type controls the screen layout, the priority type, the number range, the status profile and which fields are mandatory, so plan a type per workflow instead of one type with many optional fields.

Catalogs and why they matter

Failure analytics in SAP depends on consistent coding. A catalog profile is assigned to equipment or a functional location and decides which code groups the user can pick for object part, damage, cause and activity. If the profile is missing, users type free text and your reports have nothing to group on. Design the code groups around the failures you actually see and keep them short enough for operators to use on a handheld device. Review the top codes quarterly and retire the ones nobody uses.

Assign catalog profiles at equipment class or functional location level
Limit each code group to a manageable list
Use object part plus damage plus cause for failure pattern reporting
Train planners to correct bad coding before order settlement

Common mistakes

Typical problems are leaving breakdown and malfunction dates optional so downtime reports are empty, creating notifications without a technical object so history cannot be analysed, and using one type for everything. Another is closing notifications before the order is complete, which breaks the link between request and work. Make completion dates mandatory where you rely on them, and review status settings when you build a workflow.

Frequently Asked Questions

What are the standard notification types in SAP PM?

The delivered types are M1 maintenance request, M2 malfunction report and M3 activity report. Most projects keep these and add their own types for safety, quality or project specific workflows. Check your own Customizing for the final list.

Which table stores PM notifications?

The notification header is stored in QMEL. Items are in QMFE, causes in QMUR, tasks in QMSM and activities in QMMA. They are shared with quality notifications, so filter by notification type when you report on PM.

How do I create an order from a notification?

Open the notification in IW22 and use the function to create an order, or create the order in IW31 and enter the notification number. The status ORAS then shows that an order is assigned, and the notification keeps the link.

What is the breakdown indicator for?

It marks that the technical object was out of service. Together with malfunction start and end it feeds breakdown duration, availability and MTTR reports. If it is not mandatory on your malfunction type, downtime reports will often be incomplete.

If your failure coding is inconsistent, Netray can help analyse notification text and propose clean catalog codes over your own data, on premises if required.

Talk to an Expert Explore More Free Tools

Related Tools

SAP

More SAP tools

See all

Back to All Tools