M_BEST_WRK — Purchase Order Plant Authorization
M_BEST_WRK controls which plants a user may work with when creating, changing, displaying, or releasing purchase orders. It checks the plant entered on the PO item against the WERKS values in the user's role, combined with the activity (ACTVT) being performed. It never acts alone — purchasing group, purchasing organization, and document type objects are checked in the same transaction and any one of them can block the user even when M_BEST_WRK itself passes.
This page covers the plant-level authorization check on purchase order documents, the two fields it evaluates, and the transactions that trigger it. It focuses on the diagnostic sequence for a failed check, since M_BEST_WRK almost never fails in isolation and the real blocker is frequently a sibling object rather than this one.
Published 16 Sept 2026· 909 words
What it protects
M_BEST_WRK restricts purchase order activity by plant. Every PO item carries a plant field, and this object checks whether the requesting user is authorized to create, change, display, or release documents for that specific plant. The structural fact that causes most confusion: a purchase order is checked against several authorization objects simultaneously, not just this one. Purchasing group (checked separately), purchasing organization, document type, and plant are all evaluated as parallel gates on the same transaction call. A user can hold full authorization for plant 1000 under M_BEST_WRK and still be denied the document, because the same PO also fails the purchasing group check or the document type check. Consultants who only look at the plant object conclude, wrongly, that the plant authorization is broken, when the actual failing object is a different one entirely.
Fields checked
- ACTVT - the activity being performed: 01 create, 02 change, 03 display, and other values depending on the activity list assigned to the object in that role (release activities use separate codes). A role missing the right ACTVT value blocks the action even if the plant is correctly listed.
- WERKS - the plant value on the purchase order item. Roles typically hold either specific plant codes or an organizational-level derivation from a reference role. A wildcard or overly broad WERKS list is a common over-provisioning mistake, but a missing entry for one plant in a multi-plant company is the far more frequent cause of a failed check.
Where it is checked
- ME21N, ME22N, ME23N - the check fires when the plant field on a PO item is populated or changed, at the point the item is saved or the screen is left, not merely on document open.
- ME28 and other release transactions - checked again during the release step, independent of whatever check happened at creation, which is why a user can create a PO for a plant but fail to release it.
- List and reporting transactions such as ME2M, ME2N, ME2K - checked when the report selection includes a plant restriction, filtering out lines the user is not authorized to see rather than issuing a hard error.
- Background and batch input processing of purchase orders - the check still runs under the executing user's authorizations, which is why mass PO creation jobs fail for plants the batch user was never granted.
How to trace a failed check
Start with SU53 immediately after the failed action, before doing anything else, since it only captures the most recent authorization check in that user session. Confirm the object shown is genuinely M_BEST_WRK and note the WERKS and ACTVT values SU53 displays as failing, not just the object name. If SU53 shows a different object (EKG, EKO, or BSA) instead, stop chasing plant authorization entirely — that is the real blocker. If SU53 is blank or inconclusive, because the check happened in a batch job, a BAPI call, or a prior screen, run an authorization trace (ST01 or the newer trace transaction) for the affected user, reproduce the failing action, and read the trace for every M_ object evaluated during that transaction, not only the one presumed to fail. Hand security the exact WERKS value, ACTVT code, transaction, and timestamp from the trace, not a paraphrase of the error message.
Whose problem this is
Deciding which plants a purchasing user should access is functional — it follows the plant assignment in the purchasing organization structure and the user's actual job scope. Building and assigning the role is security's job. A usable request states the user ID, the exact plant codes needed, the activities required (create, change, display, release), and the transaction where the failure occurred, plus the SU53 or trace output.
Common pitfalls
- A role that lists the correct plant still fails if the ACTVT value for the specific action (e.g. release, code 65 or similar) was never added alongside create and change.
- Fixing M_BEST_WRK and retesting without re-checking EKG, EKO, and BSA wastes a cycle when the document was always going to fail on one of the other three objects.
- Organizational-level derived roles sometimes generate WERKS values from an outdated org assignment; the plant was removed from the user's org unit months ago and the role was never regenerated.
- SU53 only shows the last check performed in that session — if the plant check passed but a later object failed, SU53 will show the later object, leading someone to declare the plant object was never the problem when it was correct all along, or conversely to miss an earlier plant failure that occurred before the visible screen.
- Granting a wildcard on WERKS as a quick fix resolves the ticket but authorizes every plant in the company code, including ones outside the user's actual purchasing scope, and this is usually caught much later in an access review.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-auth-objects/m-best-wrkERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.