QMMA table — Quality Notification Activities Table

One row in QMMA represents a single activity (Massnahme) recorded against a quality notification: an action taken, planned, or documented as part of processing that notification. Each entry carries its own sequential activity number within the notification, a start and end date/time for the activity's execution, the user who created the record, and a catalog code and code group that classify what kind of activity it was (containment, root cause analysis, corrective action, and so on, depending on how the catalog profile for that notification type is configured). The table only reflects what someone actually typed into the Activities section of the notification; it says nothing about whether the underlying physical work was completed unless the dates and status fields are checked as well.

Always restrict by MANDT and, before anything else, by QMNUM. QMMA is shared across every notification type in the client, so a select without a notification number filter scans an unbounded quality-management history. Because MANUM only distinguishes activities within one notification, treat QMNUM plus MANUM as the effective key when joining to anything else. The date fields AUSVN and AUSBS are free-text entry dates typed by whoever logged the activity; they are not validated against the notification's own status history, so they can be blank, inconsistent, or in the future.

To confirm whether corrective action was ever documented against a notification, select QMMA where QMNUM equals the notification number. If rows exist, check AUSVN and AUSBS to see whether a start or completion date was actually entered, not just whether a row exists. Cross-check against QMEL to see the notification's current status, since an activity can be logged without the notification itself being closed.

QMMA continues to exist as a classic transparent table in S/4HANA and is still populated by the same notification processing logic that writes it in ECC. There is no widely known compatibility view replacing it, and no structural change to its key fields. Notification maintenance through the Fiori quality notification apps still writes to this classic structure underneath.

The QM configuration owner (catalog profiles, code groups, code assignment for notification types) decides how activities get classified. The quality engineer or process owner working the notification owns whether an activity entry is accurate and complete. This is a functional question about notification handling, not a basis or data model question.

QMEL is the notification header this table always joins back to. QMFE holds the notification items and QMUR the causes recorded against those items. QASE carries tasks scheduled against the notification, a separate concept from the activities in QMMA. QPGR and QPCD hold the code group and code catalog texts that give MNGRP and MNCOD their meaning. Entries are created and changed through the standard notification maintenance transactions.