BAPI_GOODSMVT_GETDETAIL — Read Details of a Posted Material Document

BAPI_GOODSMVT_GETDETAIL retrieves the header and item data of a material document that has already been posted, regardless of which movement type created it — goods receipt, goods issue, transfer posting, or physical inventory difference. It mirrors the read side of transaction MB03 (Display Material Document), not MB01 or MIGO in create mode. Given a material document number and the fiscal year it belongs to, it returns the header attributes and the full set of line items exactly as stored, with no option to change or reverse the document through this call. It functions as a lookup: confirming what actually got posted after a goods movement, reconciling an interface's own record of a movement against SAP, or pulling movement detail into a monitoring or exception-handling program without touching the document itself.

There is nothing to commit. This BAPI only reads data, so calling BAPI_TRANSACTION_COMMIT afterward has no effect and forgetting it causes no data loss because no database change was ever made. The commit concern that matters here runs the other way: if this BAPI is called immediately after BAPI_GOODSMVT_CREATE in a separate call or a separate logical unit of work, and the creating program has not yet issued its own commit, the document may not be visible to the read yet. That shows up as a spurious document-not-found result rather than a commit failure on this BAPI's own side, and it is easy to misdiagnose as a bug in GETDETAIL when the real cause is timing on the creating process.

RETURN must be scanned for TYPE equal to E or A before anything in GOODSMVT_HEADRET or GOODSMVT_ITEMS is trusted. The common lazy pattern — checking only whether RETURN is empty — fails here because a document-not-found condition, a wrong fiscal year, or an authorization gap all populate RETURN with an error message while leaving the export structures blank rather than raising an exception. A program that skips the RETURN check and reads the empty header structure will see blank posting dates and zero quantities and treat them as real data instead of as a failed lookup. This produces false negatives in reconciliation jobs: a movement that genuinely posted gets reported as missing, or worse, a movement that never posted gets silently treated as a zero-quantity movement and passed downstream. The fix is always the same discipline as with any BAPI: check TYPE first, branch on E/A before touching the export tables, and log the MESSAGE text rather than discarding it, since it usually states plainly whether the document number, the year, or the authorization was the problem.

This BAPI remains valid and supported on S/4HANA for reading posted material document detail. The underlying storage of movement data changed with the consolidated material document table, but the BAPI layer insulates callers from that change, so existing interfaces built on this call do not need rework for that reason alone. No specific successor API has been announced to replace it for this read scenario, and it remains the standard choice where no dedicated OData or API Business Hub service covers the same lookup.

This sits with the interface developer first, since failures are almost always a wrong key (document number, year) or a RETURN check that was never coded. Functional involvement is needed only when the returned data itself is in question — for example, if a document appears to be missing or its quantities look wrong — in which case functional should confirm the document's actual status in MB03 before the developer is asked to change anything.

Corresponds to transaction MB03 (Display Material Document) and reads from the material document header and item tables, historically MKPF and MSEG, consolidated under the newer material document table structure on S/4HANA. Sits alongside BAPI_GOODSMVT_CREATE, which posts the movement this BAPI later reads, and BAPI_GOODSMVT_CANCEL, which reverses it; a reconciliation flow typically calls CREATE, then later calls GETDETAIL to confirm posting, and calls CANCEL only if a reversal is required.