BAPI_INSPOPER_RECORDRESULTS — Record QM Inspection Results via BAPI

BAPI_INSPOPER_RECORDRESULTS acts on an existing inspection lot, specifically on one operation within that lot, and records results for the inspection characteristics assigned to it. It mirrors the results recording transaction QE51N (and the older QE01/QE02 family), posting single or summarized characteristic values, valuation codes, and follow-up data such as defect records, without a user opening the SAPGUI screen. It is the usual integration point for LIMS systems, test-bench PLCs, and MES layers that need to push measurement data into QM automatically. It assumes the inspection lot already exists and the target operation is still open for results recording; it does not create the lot and does not perform the usage decision or lot closure — those are separate steps that follow once all required characteristics carry results.

Like the great majority of BAPIs, this one does not commit the database on its own. A successful call only stages the results in the current LUW. If the caller does not issue an explicit commit afterward, the update is rolled back at the end of the session and the characteristic appears never to have received a result, even though the BAPI itself returned clean messages. This is a frequent failure mode in RFC-driven interfaces where the calling program treats the BAPI call as complete once RETURN is checked, and either omits the commit entirely or issues it in a code path that does not execute when results are pushed in a background job or through certain middleware adapters that suppress the follow-up call by default.

RETURN is a table, not a single flag, and multiple characteristics submitted in one call can produce a mix of success and error rows in the same response. Checking sy-subrc after the call is meaningless here; the BAPI does not reliably set it to reflect a per-row failure. The common lazy bug is treating an empty RETURN as the success test and a non-empty one as failure — but a fully successful call routinely returns informational or success rows (type S), so a non-empty table does not mean anything failed. The correct pattern loops over every row and checks specifically for type E or A. A second, more damaging bug is reading only the first row of RETURN when several characteristics were submitted together: one bad characteristic generates an error row while others post cleanly, and interfaces that stop at the first message either miss the later valid postings or wrongly conclude the entire call failed and reprocess characteristics that already succeeded, creating duplicate results downstream.

This BAPI remains valid and is still commonly used for classic QM inspection lots on S/4HANA; no separately released business API or OData service has broadly replaced it for external results-recording interfaces. The Fiori-based results recording apps in S/4HANA use their own internal services rather than this BAPI, but that change affects the UI layer, not the integration layer — LIMS and MES connections built years ago on this call generally continue to work unchanged after an S/4HANA conversion, provided the underlying inspection lot processing itself was not customized around ECC-specific enhancements.

QM functional owns the inspection plan and characteristic master data: whether the characteristic is open for recording, its unit of measure, and valuation settings. Development owns the interface program: parameter mapping, the commit call, and correct RETURN table iteration. When results fail to post, functional needs the lot and operation number and the expected characteristic list; development needs the full RETURN table content and confirmation the commit was actually issued, not assumed.

Mirrors the results recording transaction QE51N. Sits between fetching lot and operation structure and closing the lot: interfaces typically call a lot detail retrieval BAPI first to confirm which characteristics are open, then this BAPI to post values, then a separate completion or usage decision call to close the lot. A result recorded outside tolerance frequently triggers creation of a quality notification as a downstream step in the same integration chain.