M_BEST_BSA — Purchase Order Document Type Authorization
M_BEST_BSA controls which purchase order document types (BSART values such as NB, UB, FO) a user can create, change or display, combined with an activity check. It is one of a set of M_BEST_* objects checked together for any PO action, so a failure here is often mistaken for a plant or purchasing organization authorization problem.
This page covers what M_BEST_BSA restricts on purchase order processing, the fields it checks, and where in the ME21N/ME22N/ME23N flow the check fires. It focuses on tracing a failed check back to the exact document type and activity involved, since SU53 alone rarely tells the full story when several M_BEST_* objects fail in sequence.
Published 16 Sept 2026· 875 words
What it protects
M_BEST_BSA guards the ability to create, change or display a purchase order of a given document type. The document type (BSART) is the first thing the system evaluates when a PO transaction is opened, and it drives numbering, field control and workflow, so SAP checks it as its own authorization dimension rather than folding it into plant or purchasing organization checks. The structural fact that causes most confusion: a PO authorization decision is never made on one object alone. M_BEST_BSA, M_BEST_WRK, M_BEST_EKG and M_BEST_EKO are all evaluated for the same document, and the user needs a passing result in every one of them for that specific combination. A role can carry the correct plant and purchasing group values and still fail purely because the document type list in M_BEST_BSA does not include the type on screen.
Fields checked
- BSART - the purchasing document type being processed, for example NB for a standard order, UB for a stock transfer order, or FO for a framework order. The role must list every document type the user is expected to work with, not just the most common one.
- ACTVT - the activity being performed against that document type: 01 for create, 02 for change, 03 for display. A user can be authorized to display all document types but only create a subset, and the two activities must be granted separately per BSART value.
Where it is checked
- ME21N at the point the document type is set on the initial screen, before any header or item data is processed, and again if the user changes the document type mid-session.
- ME22N and ME23N when the existing PO is opened, checked against its stored BSART with activity 02 or 03 respectively.
- ME28 and other release transactions, where the check runs against the document type of the PO being released even though the release itself is separately authorized.
- Background and interface creation paths such as PO creation via BAPI, IDoc inbound processing, and conversion of a purchase requisition into a PO (ME59N or similar), all of which run the same check under the processing user's authorization.
- Workflow-driven approval steps, where the workflow runtime user or the approving user is checked against the document type before the next step is allowed to proceed.
How to trace a failed check
Start with SU53 run immediately after the failure, in the same session, before any other transaction is touched. Confirm M_BEST_BSA appears with a red failed mark and note the BSART and ACTVT values shown against it. If SU53 shows a different M_BEST_* object as the last failure (WRK, EKG, EKO), that does not mean BSA passed, it only means BSA was not the last one evaluated in that particular call; do not assume the document type is fine just because it is not on the SU53 screen. Where SU53 is inconclusive or the user has already navigated away, run a full authorization trace (ST01 or the newer trace transaction) filtered on object M_BEST_BSA, reproduce the failing transaction, and capture the exact BSART and ACTVT combination presented to the check. Hand the security team the user ID, transaction code, the document type value, the activity code, and the timestamp of the trace, not a general description like PO creation is blocked.
Whose problem this is
Functional consultants determine which document types a given role genuinely needs, security builds and maintains the authorization values. A useful request to security names the user or role, the transaction, the specific BSART values and activity codes required, and the business scenario (standard purchasing versus stock transfer versus framework order) so the values are not padded beyond what is needed.
Common pitfalls
- A role that includes the right document type for one plant is assumed to cover all plants, but M_BEST_BSA has no plant field of its own, so the failure people are actually hitting is a separate M_BEST_WRK gap, not this object.
- Adding a new document type to a purchasing process (for example introducing a stock transfer order type alongside standard orders) and forgetting that BSA needs the new BSART value added explicitly, even though EKG and WRK already cover the scenario.
- Granting ACTVT 01 and assuming display is included; display is a separate activity value and its absence causes a failure on report or list transactions that otherwise look unrelated to creation rights.
- Concluding from a single SU53 screenshot that the whole authorization concept is broken and requesting a broad SAP_ALL-style fix, when the actual gap is one missing BSART entry for one document type.
- Testing only with the most common document type during role validation, so a gap surfaces weeks later on a rarely used type like a framework order or a subcontracting PO type.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-auth-objects/m-best-bsaERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.