BAPI_GOODSMVT_CREATE — BAPI_GOODSMVT_CREATE Goods Movement Posting

BAPI_GOODSMVT_CREATE posts a goods movement against the material inventory management object, producing the pair of documents behind every stock movement: the material document (header and items) and, where relevant, the linked accounting document. It mirrors the manual goods movement transactions MB1A, MB1B, and MB1C, and reproduces the posting logic that sits behind MIGO. It covers goods receipts against purchase orders or production orders, goods issues to cost centers or orders, and transfer postings between storage locations, plants, or stock types. The scenario is not chosen by transaction code but by the combination of GM_CODE (movement category) at header level and the movement type on each item line. It is one of the most heavily used BAPIs in P2P and shop-floor integrations because almost every automated receipt or issue coming from a non-SAP system, scanner, or warehouse control platform runs through it.

BAPI_GOODSMVT_CREATE does not commit the database update itself. The caller must issue BAPI_TRANSACTION_COMMIT, typically with WAIT set, immediately after checking RETURN. If this step is forgotten, the function can still populate GOODSMVT_HEADRET with what looks like a valid material document number and year, but nothing is written to the database once the logical unit of work ends. In RFC or background contexts this produces a specific failure pattern: the calling program logs a successful posting, a downstream read of the material document a moment later returns not found, and the discrepancy only surfaces when someone reconciles interface logs against MSEG.

RETURN is a table, not a single status flag, and success is not the same as an empty table. Every line must be inspected for TYPE equal to E or A; a table that contains only informational or success messages still represents a completed posting, while a single E line anywhere in the set means no document was created regardless of what GOODSMVT_HEADRET shows. A common interface bug is checking IF RETURN IS INITIAL and declaring success on that basis alone, which misses the far more common case where RETURN is non-empty but contains only success text. Another recurring bug is reading only the first line of RETURN when the BAPI raised several messages, discarding the one that actually explains the rejection, such as a closed posting period or a missing storage location. Matching on the MESSAGE text field instead of the ID and NUMBER pair is also fragile, because the text changes with logon language while ID and NUMBER do not.

BAPI_GOODSMVT_CREATE remains valid and widely used in S/4HANA. SAP has not withdrawn it, and it continues to sit behind manual postings and many custom interfaces. For online, user-facing entry the recommended path is MIGO rather than a direct BAPI call, and some newer S/4HANA scenarios expose goods movement posting through released API services intended for cloud and side-by-side extension use. Where those newer services exist and fit the scenario they are worth evaluating, but for classic point-to-point ABAP integration this BAPI is still the standard choice and is not deprecated.

Functional consultants own the movement type, GM_CODE, and organizational data that determine what a valid posting looks like. Developers own the interface code calling the BAPI and the commit logic around it. When a posting fails, the developer needs the full RETURN table dump and the exact payload sent; the functional side needs confirmation of which movement type and reference document were expected for that scenario.

Mirrors the online transactions MB1A, MB1B, MB1C, and the posting step inside MIGO. Writes to the material document header and item tables (MKPF and MSEG) and, where relevant, triggers the linked accounting document. BAPI_GOODSMVT_CANCEL is the correct counterpart for reversing a document created by this BAPI rather than reposting with a negative quantity. BAPI_GOODSMVT_GETDETAIL is used to re-read a posted document for reconciliation after the fact.