BAPI_QUALNOT_CREATE — Create a Quality Notification via BAPI

BAPI_QUALNOT_CREATE creates a quality notification, the same object edited on screen through QM01, QM02 and QM03. It supports the standard notification types delivered with QM (customer complaint, complaint against vendor, internal problem report) and any custom type configured on top of them. In one call it can populate the notification header, item lines describing defects, cause records, tasks and activities, and partner assignments. It is the standard entry point for integrations that raise a quality notification automatically, for example from a returns process, a batch rejection in an external warehouse system, or an inbound complaint recorded in a CRM or portal application. It does not process the notification further; follow-up steps such as adding tasks after creation, changing status, or closing the notification are separate BAPIs.

BAPI_QUALNOT_CREATE does not commit the database update itself. The notification number returned in NOTIFHEADER_EXPORT is generated during the call, but the record is only persisted after the caller invokes BAPI_TRANSACTION_COMMIT (or the equivalent commit step in the calling framework). If the caller forgets, the number appears valid in the response and downstream logic proceeds as if the notification exists, but the update task rolls back at the end of the session or program and the notification is never written to the database. This produces a particularly confusing defect pattern: the interface log shows a successful call with a plausible number, but QM03 reports the notification does not exist. It is one of the first things to verify when a receiving system swears it got a number back that SAP cannot find.

RETURN is a table, not a single message, and every line must be inspected, not just the first one. A common interface bug checks only whether RETURN is initial, or checks the TYPE of the first line, and treats anything else as success. Header creation can succeed while individual item, cause or partner lines fail validation, leaving a notification with a valid number but missing the defect data the business process actually needed. The correct pattern loops over RETURN and treats any line with TYPE 'E' or 'A' as a hard failure requiring rollback of any local commit already issued, and logs 'W' lines even when the overall call is treated as successful, since warnings often flag a catalog code that was silently defaulted or a partner that was dropped because the determination procedure did not expect that partner function. Interfaces that swallow RETURN entirely and rely on NOTIFHEADER_EXPORT being non-blank are the most frequent source of notifications with a number but no usable content.

BAPI_QUALNOT_CREATE remains a supported and commonly used interface for quality notification creation on S/4HANA. There is no single released OData or API Business Hub service that has fully replaced generic notification creation across all notification types; where a specific Fiori app exists for a narrow scenario it may expose its own service, but custom and legacy integrations continue to call this BAPI directly. It is reasonable to keep using it for new integration work unless a specific released API has been confirmed for the exact notification type and scenario in question.

This is primarily a developer problem: the BAPI contract, the commit step and the RETURN loop are interface code. Functional QM consultants own the evidence the developer needs to diagnose failures: the catalog profile assigned to the plant and notification type, the partner determination procedure, and a working manual creation in QM01 to prove the configuration accepts the same codes the interface is sending.

Mirrors transaction QM01 for creation and QM02/QM03 for change and display. The notification header lands in table QMEL; item, cause, task and activity data land in the corresponding notification detail tables. Sibling BAPIs cover the rest of the lifecycle: one to change an existing notification, one to add tasks or actions to a notification already created, and one to retrieve notification details for verification after creation.