BAPI_INSPECTIONLOT_GETDETAIL — Read Inspection Lot Header and Status Detail

The BAPI acts on a single inspection lot, the QM object stored in table QALS and displayed via transaction QA03. Given a lot number it returns the same header information a user sees on the QA03 initial and overview screens: material and plant, lot origin (goods receipt, in-process, etc.), inspection type, creation and target dates, sample size basis, and the current system and user status of the lot. It performs no write, no status change and no usage decision posting. It exists so that custom reports, interfaces to external quality systems, and monitoring jobs can pull lot status without opening a dialog transaction or reading QALS directly, which is unsupported and version-fragile.

The interface is narrow by design: one import key, one or two exporting structures, and the standard return table. Anything beyond header-level detail (characteristics, results, samples) requires a separate call.

The BAPI writes nothing, so there is no commit to forget. Calling BAPI_TRANSACTION_COMMIT afterward has no effect on this call specifically; it is harmless but pointless if issued only for this BAPI. The practical risk runs the other way: if this read is bundled inside the same LUW as a preceding write BAPI (for example a usage decision or a results recording call) and the caller has not yet committed that write, GETDETAIL will return the pre-change status because it reads committed data, not the in-memory state of the current transaction. Interfaces that read the lot immediately after posting a change in the same call sequence, expecting to see the new status, are the ones that get burned by this.

On a successful lookup RETURN is empty; an empty table is the actual success signal, not the presence of data in INSPECTIONLOT. When the lot number does not exist, is not padded to twelve characters, or the user lacks display authorization for that plant or inspection type, RETURN carries an E-type message and the exporting structures come back initial - blank material, blank plant, zero quantities. The recurring bug is code that skips the RETURN check entirely because the call is 'just a read', then proceeds to use the blank INSPECTIONLOT fields as if they were real data: reports show a zero-quantity lot for material X, interfaces mark a lot as closed when it was never found, dashboards silently drop rows instead of flagging them as lookup failures. Always test RETURN for entries of type E or A before touching any exporting field, and log the message text rather than assuming a generic 'not found'.

The BAPI remains valid and functionally unchanged on S/4HANA; there is no formal successor BAPI for this specific read. For new Fiori-based or side-by-side extension scenarios, a released OData or API-based read on the inspection lot may be a better fit and should be checked against the current API catalogue before building new interfaces, but for existing ECC-style custom programs and batch interfaces this call still works without modification and does not require migration.

Most failures trace back to how the lot number is passed or to assumptions about what the BAPI does not return.

This sits with the interface or ABAP developer first, since the usual defect is a malformed lot number or an unchecked RETURN table rather than a QM configuration problem. Functional QM involvement is needed only when the returned status genuinely disagrees with what QA03 shows for the same lot, in which case the developer should supply the exact NUMBER value sent and the full RETURN content.

The transaction it mirrors is QA03, inspection lot display. The underlying table is QALS for the header; related characteristic and results tables sit behind separate detail BAPIs, not this one. On the write side, BAPI_INSPOPER_RECORDRESULTS posts the operation results this BAPI does not return, and BAPI_QUALNOT_CREATE creates a quality notification that is sometimes triggered off the status this BAPI reports.