VIQMEL table — Maintenance Notification View for List Selection

One row in VIQMEL represents one maintenance notification as seen from the list and selection perspective. The view exists because notification data is split across tables: the generic notification header (type, text, dates, status-relevant fields, created-by) lives in the core notification table, while PM-specific attributes such as equipment number, functional location, malfunction start and end, and breakdown duration live in a separate maintenance-specific extension record created only for PM-type notifications. VIQMEL joins these so that a single flat read returns everything a list transaction needs without the calling program having to know about the split. It is read-heavy infrastructure: reports, matchcodes and the notification worklist run against it, but nothing writes to it directly. QM notifications and other non-PM notification types will show blank in the PM-specific columns because the join partner record does not exist for them.

There is no client field visible on VIQMEL itself in the usual sense because the view already resolves within the current client context, but every selection still runs client-dependent underneath, so cross-client comparisons require going to the source tables directly. QMNUM is unique and highly selective; always lead with it, a date range on ERDAT or STRMN, or MAWERK plus INGRP when scanning a worklist. Avoid open-ended selects on QMART or PRIOK alone in a productive system with years of notification history, the view can return an enormous result set because it inherits the full row count of the underlying notification table. Restrict by plant and date first, then narrow further.

Symptom: a notification appears in an equipment's history in IW28 but a custom report using EQUNR as a filter misses it. Select VIQMEL where EQUNR equals the equipment number and compare QMART and the presence of AUFNR against what the report actually filtered on. If the notification is a QM-type notification rather than PM-type, EQUNR in VIQMEL will be blank even though the equipment is referenced elsewhere, because the PM-specific extension record was never created for that notification type. That confirms the report's join logic, not the master data, is at fault.

VIQMEL continues to exist on S/4HANA and is still the view most PM notification list transactions read from. The underlying notification header table structure is largely unchanged from ECC. Some newer Fiori-based notification apps read from CDS views built for OData exposure rather than from VIQMEL directly, but classic transactions and most custom ABAP reports still hit VIQMEL exactly as they did before. No wholesale replacement of VIQMEL by a compatibility view has occurred; it is not one of the tables affected by the simplified data model changes that hit inventory or finance objects.

The PM functional consultant or maintenance planner owns questions about why a notification does or does not show equipment or location data, since that traces back to notification type configuration. The ABAP or reporting developer owns performance and join-correctness issues when VIQMEL is used inside a custom report. Nobody owns direct data correction on this view, because it is not writable.

EQUI and EQKT hold the equipment master and its description referenced by EQUNR. IFLOT and IFLOTX hold the functional location master and description referenced by TPLNR. AFIH holds the PM-specific extension of a maintenance order created from a notification. IHPA holds partner assignments for the notification's object number. Transactions IW21, IW22 and IW23 create and change notifications and populate the underlying tables; IW28 and IW29 are the primary list transactions that read VIQMEL.