BAPI_GOODSMVT_CANCEL — BAPI_GOODSMVT_CANCEL for Reversing Material Documents

BAPI_GOODSMVT_CANCEL reverses an already-posted material document, the same object MBST works against. It does not delete the original document; it posts a new, offsetting material document with reversed quantities and the appropriate movement type, exactly as MBST does when a user cancels a goods receipt or goods issue manually. It is used wherever an interface has posted a goods movement in error, or where a business process needs a programmatic undo step, for example an automated goods receipt that failed a downstream quality check and must be reversed before the vendor invoice is processed. It acts strictly on documents already in MKPF and MSEG. It cannot cancel a document that never existed, and it cannot selectively reverse part of a multi-item document without correct handling of the line item table.

BAPI_GOODSMVT_CANCEL does not commit the reversal to the database on its own. Like the rest of the BAPI_GOODSMVT family, it stages the cancellation and waits for an explicit BAPI_TRANSACTION_COMMIT call, or a rollback if the caller decides the attempt failed. Forgetting the commit is a common mistake in ad hoc test scripts and in interfaces built by someone unfamiliar with the pattern: the RETURN table shows message type S, the call looks like a success, but no reversal document ever appears in MKPF because the underlying work was never written to the database. Programs that call this BAPI in isolation, outside a wrapper that already handles commit, need to add the commit call explicitly and check its own return status too, since a commit failure after a successful cancellation staging is still possible.

RETURN must be scanned for any line with TYPE E or A; a single warning in the table does not mean the cancellation failed, but a single error means it did, even if earlier lines in the same table looked fine. The defect seen repeatedly in real interfaces is trusting the call's success without checking RETURN at all, because the BAPI does not raise a classic exception for most business errors, it reports them as messages. The second, more specific defect: the new reversal material document number is not returned in a dedicated output field the way BAPI_GOODSMVT_CREATE returns one. It is embedded inside the text of a success message in RETURN, something like a confirmation that a document was posted with a given number. Interfaces that need that number for downstream processing, such as linking the reversal to a case record, have to parse that message text or re-derive the document by querying MKPF for the newest entry referencing the original document, both of which are fragile and worth flagging in any code review of a custom wrapper.

BAPI_GOODSMVT_CANCEL continues to work on S/4HANA and remains a normal way to reverse a material document programmatically; there is no publicly announced released successor API specifically for cancellation that supersedes it. Fiori goods movement apps and MIGO both post cancellations through the same underlying logic this BAPI calls, so behaviour is consistent between the classic interface and the newer UI layer. Teams building new S/4HANA integrations should still confirm current guidance for their release before hard-wiring this BAPI into a new interface, since SAP's recommended integration layer for goods movements has been evolving.

Whether a document should be cancelled at all is a functional and business-process decision, usually driven by inventory management or the process owner who created the original movement in error. Interface failures around this BAPI, particularly missing commits and mis-parsed return messages, are developer problems. Functional teams should hand over the material document number, fiscal year, and the exact RETURN table content from the failed call rather than a screenshot of MIGO.

The manual equivalent is transaction MBST, and behind both sits MKPF and MSEG for the header and line items of the original and reversal documents. BAPI_GOODSMVT_CREATE is the sibling call that posts the original movement being cancelled here, and BAPI_GOODSMVT_GETDETAIL is the usual way to confirm a document's current status and line items before attempting a cancellation, avoiding a wasted round trip against a document that cannot be reversed.