M_MSEG_BWA — Goods Movement Type Authorization Object
M_MSEG_BWA controls which movement types a user may post in Inventory Management, checked against the ACTVT and BWART fields whenever a goods movement is saved. It fires together with M_MSEG_WWA (plant), so a user needs both the movement type and the plant authorized for the same posting or the whole document fails, regardless of which check is reported first.
This page covers M_MSEG_BWA, the authorization object that restricts goods movement postings by movement type and activity in MM Inventory Management. It focuses on where the check actually fires, how to read a failed check correctly against its companion object M_MSEG_WWA, and the pitfalls that make an apparently complete role still reject valid postings.
Published 16 Sept 2026· 892 words
What it protects
M_MSEG_BWA guards the posting of goods movements by movement type. Every line item in a material document carries a movement type (BWART) such as 101 for goods receipt against a purchase order, 261 for goods issue to an order, or 561 for initial entry of stock, and the system checks whether the user is authorized for that specific movement type and activity before the document is saved. The structural fact that causes most confusion is that this object never decides authorization alone. It is checked alongside M_MSEG_WWA, which restricts the plant, and both must pass for the same line item. A role that lists the right movement types but the wrong plant, or vice versa, still fails the posting, and the failure looks identical from the user's side regardless of which object actually blocked it.
Fields checked
- BWART - the movement type being posted, such as 101, 102, 201, 261, 311, 561. Roles typically list an explicit set of values rather than a wildcard, because movement type is the main lever for segregation of duties in inventory postings.
- ACTVT - the activity being performed against that movement type, generally create (01). Some role designs also separate change or reversal handling through activity values, but the movement-type-specific reversal codes (for example 102 as the reversal of 101) are more commonly controlled through BWART itself rather than through ACTVT.
Where it is checked
- MIGO, the primary goods movement transaction, checks this object per line item at the point of posting, after the user selects the movement type on the document header or item.
- MB1A, MB1B and MB1C, the classic goods issue, transfer posting and other-goods-receipt transactions, check the object the same way when the document is saved.
- MB01 and MB31 for goods receipt against a purchase order or production order fire the check at save, tied to the movement type derived from the order category.
- MBST, the material document cancellation transaction, checks the object against the reversal movement type it generates, which is often a different BWART value from the original posting and must be separately authorized.
- BAPI_GOODSMVT_CREATE and related inventory management BAPIs perform the identical authorization check internally, so interface-driven and batch postings are subject to the same restriction as dialog transactions.
How to trace a failed check
Start with SU53 immediately after the failed posting, while the session is still open, since the buffer only holds the most recent checks. Look specifically for M_MSEG_BWA in the list and note the BWART and ACTVT values shown as required versus what the user's role actually contains; do not stop at the first failed object shown, because M_MSEG_WWA for the plant is frequently checked in the same operation and SU53 may only surface one of them depending on check order. If SU53 is empty or inconclusive, run an authorization trace for the user covering the exact transaction and movement type, then filter the trace output to M_MSEG_BWA and M_MSEG_WWA together. Hand security the transaction used, the exact movement type value attempted (including whether it was a reversal-generated movement type rather than the one the user typed), the plant, and the user ID and timestamp from the trace, rather than a general description like 'cannot post goods receipt'.
Whose problem this is
This is a joint problem. Functional identifies which movement types the business process legitimately requires, including any automatically generated follow-on movement types and reversal codes; security decides how those values are distributed across roles, since movement type is a common segregation-of-duties boundary. A good request names the transaction, the exact BWART and plant combination, the activity, and whether the requirement is a one-time fix or a role design gap.
Common pitfalls
- A role authorizes the receipt movement type (101) but not its reversal (102), so users can post goods receipts but cannot cancel their own mistakes, which looks like a bug but is often intentional control.
- Movement type lists are built from what testers happened to use, missing less common but valid values like 311/312 for plant-to-plant transfer or 501/502 for receipt without a purchase order, so the failure only surfaces weeks later on a rare transaction.
- A posting involves an automatically generated follow-on movement type, such as one triggered by account-assignment logic on the original entry, and the role authorizes the movement type the user typed but not the one the system generates behind it.
- The failure is blamed entirely on M_MSEG_BWA when M_MSEG_WWA for the plant is the actual blocker, because SU53 displayed only one of the two failed checks and nobody ran the full trace.
- Deliberate restriction of sensitive movement types such as 561 or 562 (initial entry of stock) is read as a role defect and escalated for a broad fix, when the correct action is a controlled, audited exception rather than widening the role.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-auth-objects/m-mseg-bwaERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.