M_MSEG_WWA — Goods Movement Authorization by Plant
M_MSEG_WWA controls which plants a user can post goods movements against, checked alongside ACTVT for create, change, display or reversal. It is evaluated separately from the movement type check in M_MSEG_BWA, so a user can have full rights to a movement type and still be blocked because the plant on the document line falls outside their authorized plant list.
This page covers M_MSEG_WWA, the authorization object that restricts goods movement postings by plant. It focuses on how the plant check interacts with the movement type check, where in the MIGO and MB01-family transactions the check actually fires, and how to isolate a plant failure from a movement type failure during troubleshooting.
Published 16 Sept 2026· 841 words
What it protects
M_MSEG_WWA guards the plant dimension of a goods movement: whether a user is allowed to post, change, display, or reverse a material document line for a given plant. The structural fact that causes most confusion is that a goods movement check is split across two separate authorization objects, one for the movement type (M_MSEG_BWA) and one for the plant (M_MSEG_WWA), and both must pass independently for the posting to succeed. A user can hold full rights to movement type 261 and still fail the posting because the receiving or issuing plant on that specific line is not in their M_MSEG_WWA plant list. Stock transfer postings make this worse because a single document can carry two different plants on the same line, and each one is checked.
Fields checked
- ACTVT - the activity being performed against the plant: 01 for create, 02 for change, 03 for display, and separate values used for reversal and cancellation depending on the transaction.
- WERKS - the plant on the material document line being posted, changed, displayed or reversed. This is the plant derived from the goods movement itself, not necessarily the user's home plant.
Where it is checked
- MIGO and its variants (goods receipt, goods issue, transfer posting, subsequent adjustment) check M_MSEG_WWA for every plant that appears on a line item at the point of save.
- The MB01, MB1A, MB1B, MB1C family of classic goods movement transactions checks the object per line before the document is committed to MSEG.
- MBST, the material document reversal transaction, checks M_MSEG_WWA against the plant on the original document, not against any plant entered on the reversal screen.
- Goods movement postings triggered from inbound delivery confirmation, production order backflush, or the BAPI used for external goods movement creation run the same authorization check internally, even though no dialog screen is shown to the user.
- For a stock transfer with two plants on one line, the check runs once for the issuing plant and once for the receiving plant, and either can fail independently.
How to trace a failed check
Start with SU53 run immediately after the failed posting attempt, in the same session, before doing anything else. It shows the object, the field values the system checked, and the values actually held in the user's role. Look specifically at whether the failing object is M_MSEG_WWA or M_MSEG_BWA — the two are often confused because both fire on the same posting attempt, and SU53 lists them separately. If SU53 is empty or the user has already navigated away, run an authorization trace for that user covering the exact transaction and time window, then filter the trace results down to the M_MSEG_WWA entries. Note the WERKS value that failed and the ACTVT that was checked. Hand security three things: the user ID, the exact plant code that failed, and the activity (create, change, display, reversal). Do not hand over a screenshot of the full error message alone; the plant value is the part that actually resolves the ticket.
Whose problem this is
This is a security team change once the failing plant and activity are confirmed, but identifying which plant should be added is a functional call — security cannot guess which plants a given user's process legitimately covers. A good request states the user ID, the plant code from SU53 or the trace, the activity value, and whether the need is temporary (one-off correction) or permanent (recurring process in that plant).
Common pitfalls
- A role that lists the right plant under a different authorization object, such as the plant field in a purchasing object, does nothing for M_MSEG_WWA; each object maintains its own plant authorization independently.
- Stock transfer postings fail against the receiving plant even though the issuing plant is correctly authorized, and the SU53 output can be misread as a movement type problem because both plants and the movement type appear on the same screen.
- Reversal via MBST checks the plant of the original document, so a user who is authorized for the plant they are working in today can still be blocked reversing an old document posted against a plant they no longer cover.
- Adding a wildcard or an overly broad plant range as a quick fix routes around segregation of duties controls built around plant-level responsibility, and gets flagged in the next access review.
- A failed check is frequently misdiagnosed as a movement type restriction and escalated to change M_MSEG_BWA, when the trace, read correctly, shows the plant object failing and the movement type object passing.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-auth-objects/m-mseg-wwaERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.