BAPI_ALM_NOTIF_CREATE — BAPI_ALM_NOTIF_CREATE for PM CS Notifications

BAPI_ALM_NOTIF_CREATE acts on the PM/CS notification object, the same object edited through transactions IW21, IW22 and IW23. It mirrors IW21's create screen: header data, one or more items describing the problem, causes, tasks to be carried out, activities already performed, partner assignments, and long text. Which fields become mandatory depends entirely on the notification type passed in, since notification type customizing controls screen fields, catalog profiles, and partner determination in the same way it does for the online transaction. The BAPI is the standard entry point used by interfaces from external maintenance systems, IoT/condition-monitoring platforms, and custom malfunction-reporting apps that need to raise a notification without a user sitting at IW21.

The BAPI does not commit. It builds the notification in the update task and returns a notification number optimistically, but nothing is written to the database until BAPI_TRANSACTION_COMMIT is called explicitly by the caller in the same logical unit of work. Interfaces that omit the commit call see a notification number come back, log it as created, and move on, only to find later that IW23 cannot display it because the update was rolled back at session end or by a subsequent error. This is one of the most common causes of number gaps and mismatched reconciliation reports between the source system and SAP.

RETURN is a table, not a single message, and every line has to be inspected individually by its TYPE field (E, A, W, I, S). Checking only whether NOTIFICATION came back non-blank is not sufficient, because the BAPI can populate the notification number in a buffer before the error occurs downstream in item, cause, or partner processing, and can also return a number in a test or simulation-like sequence that never gets committed. A properly written wrapper loops the RETURN table, treats any line with TYPE E or A as a hard failure, discards the returned number in that case, and only proceeds to commit when no error-level line exists. Interfaces built by reading only the first row of RETURN, or by string-matching on a message text instead of TYPE, break the first time SAP changes a message's wording or issues the error on a later row, and then silently accept partially built notifications as successful.

BAPI_ALM_NOTIF_CREATE remains fully usable on S/4HANA and has not been formally superseded for general-purpose notification creation from custom or middleware interfaces. Certain line-of-business scenarios, such as mobile asset management apps, use newer OData-based services for notification creation, but those are scoped to specific Fiori applications rather than being a drop-in general replacement. For custom point-to-point or middleware integrations, this BAPI is still the standard call.

Functional PM/CS consulting owns the notification type configuration, catalog profile assignment, and partner determination procedure that the BAPI depends on, and should be able to reproduce the same creation manually in IW21 with identical field values. Development owns the interface code, specifically the RETURN table filtering logic and the explicit commit call. When a notification silently fails to appear, the first question is whether the manual IW21 equivalent succeeds with the same data before blaming the interface.

The transaction it replicates is IW21, with IW22 and IW23 for change and display. Underlying tables include the notification header and item tables (QMEL and related item/cause/activity tables). Sibling interfaces in the same family cover order creation from the resulting notification and equipment or functional location master data referenced in the header.