WMMBXY message type — IDoc for Goods Movement from External Warehouse
WMMBXY is the inbound IDoc message type used to post a goods movement (receipt, issue, or transfer) into SAP MM/WM when the physical confirmation originates in an external warehouse management system. It travels from the external WMS into SAP, creating or updating a material document; it has no outbound output-determination counterpart of its own.
This page covers the WMMBXY IDoc message type, which reports goods movements executed in an external or decentralized warehouse system back into SAP as material documents. It focuses on the partner profile and process code setup required for the inbound flow, and on the sequence to follow when an IDoc lands with an error status instead of posting.
Reviewed by an ERPClimb SAP consultant on 16 Sept 2026· 949 words
What it carries
WMMBXY carries goods movement data - a goods receipt, goods issue, or stock transfer - from an external system into SAP, where it is posted as a material document. The typical sender is a non-SAP warehouse management system, an automated storage and retrieval system, or a middleware layer sitting between a physical warehouse and SAP, often integrated through a BTP integration suite or equivalent middleware. Direction is inbound to SAP only: the external system confirms that a physical movement has happened - a pallet picked, a bin confirmed, a receipt scanned - and that confirmation is translated into this IDoc so SAP can update stock quantities and values accordingly. It is the functional mirror of the transfer order data SAP sends outward telling the external system what to move; WMMBXY is the completion of that movement being reported back for financial and quantity posting.
Segments
The IDoc carries a header-level segment and one or more item-level segments. Segment tags in the traffic have not been independently verified here and should be confirmed against the active IDoc type before relying on the exact names.
- Header segment: movement type, plant, storage location, posting date, document date, and a reference to the external document or confirmation number
- Item segment: material number, batch, quantity, unit of measure, storage type and storage bin, and an indicator distinguishing receipt from issue
- Optional serial number segment when the material master requires serial number management for the movement
Configuration
Inbound processing needs a partner profile in WE20 for the sending logical system, with WMMBXY set up under inbound parameters, a process code pointing to the function module that posts the goods movement, and processing mode set to either trigger immediately or run via a collection job. The port in WE21 must match how the external system actually connects - tRFC for a classic ALE link, or a proxy or channel definition when the exchange runs through BTP integration middleware. The IDoc type assigned in the partner profile must exactly match what the sender produces; a mismatch between IDoc type versions is a frequent silent cause of segment misalignment. Since WMMBXY is inbound-only, there is no NAST output determination to configure; if it is distributed via ALE, the distribution model in BD64 must include this message type for the relevant logical systems.
What to inspect when it fails
- WE02 or WE05: check the current status of the IDoc; status 51 (application error) is the most common outcome and points to a genuine posting problem, not a technical one
- Read the actual error text attached to the status record; it is usually the same message a user would get trying the movement manually in MIGO - blocked material, invalid storage bin, movement type not allowed for the storage location, or insufficient stock for an issue
- WE19: replay the IDoc with corrected field values to confirm whether the fix is in the data or in the mapping
- WE20: confirm the process code on the inbound partner profile still points to the correct function module and that the IDoc type matches the sender
- WE21 and, if applicable, the middleware's own message monitor: confirm the payload arriving at SAP already contains the correct values before assuming SAP corrupted anything
- SM37: if processing is scheduled rather than immediate, confirm the collection job actually ran and picked the IDoc up
Whose problem this is
Functional MM/WM owns the diagnosis of any status 51 error - movement type, storage location, storage bin, and material master configuration behind the rejection. Basis or the interface/integration team owns the port, partner profile, connectivity to the external system, and the scheduling of inbound processing jobs. Handover should include the IDoc number and exact error text so the interface side can confirm whether the failure is in transport or in application posting.
Common pitfalls
The reflex is to reprocess the failed IDoc from BD87 without touching anything else. Since a status 51 error is an application-level rejection - the same rejection a user would hit posting the movement manually - reprocessing an unchanged IDoc simply reproduces the same error and burns a retry cycle. The IDoc needs its underlying data corrected, either at the source system or through a controlled edit and reprocess in WE19, before resubmission does anything useful.
- Errors surface as ordinary MM posting messages, which makes them look identical to a manual MIGO mistake; this leads to disputes between the interface team and the functional team over whether the problem is 'the IDoc' or 'the master data'
- An IDoc can be structurally valid and still get rejected only at the point of accounting or valuation, so the failure shows up later in the process than expected
- Missing batch or serial number data that the material master requires is a frequent, easily missed rejection cause when the external system was not configured to send it
- Because there is no output determination to monitor for this message type, a silent stop on the sending side - the external system simply stopping transmission - produces no error anywhere in SAP; it only becomes visible as a gap in stock movements days later
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-idoc/wmmbxyERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.