M_BEST_EKG — Purchasing Group Check for Purchase Orders
M_BEST_EKG restricts purchase order create, change, and display activities based on the purchasing group (EKGRP) stored on the PO. It is checked alongside the other M_BEST authorization objects (document type, purchasing organization, plant), so a user can fail a PO transaction even with EKGRP correctly assigned if one of the sibling objects is missing.
Covers what M_BEST_EKG protects in purchase order processing, its two fields, where SAP actually triggers the check, and the trace sequence for isolating a failure inside the wider M_BEST authorization family. Focuses on the recurring trap of fixing this one object while a sibling object continues to block the same transaction.
Published 16 Sept 2026· 849 words
What it protects
M_BEST_EKG controls access to purchase order maintenance and display, evaluated against the purchasing group recorded on the purchase order header. It belongs to a family of four objects that SAP checks together for every PO operation: document type (M_BEST_BSA), purchasing group (M_BEST_EKG), purchasing organization (M_BEST_EKO), and plant (M_BEST_WRK). The check is an AND across whichever of these are active for the transaction, not an OR. This is the single fact that explains most confusion: a user with perfectly correct EKGRP values in their role can still be blocked because the purchasing organization or plant object is missing or scoped too narrowly. Security teams and functional consultants who treat M_BEST_EKG in isolation waste time re-checking a field that was never the problem.
Fields checked
- EKGRP - the purchasing group value(s) the user is allowed to work with, taken from the purchasing group field on the PO header (or item, for group-specific line assignment). Maintained as a list or range in the role.
- ACTVT - the activity being performed: 01 create, 02 change, 03 display are the ones that matter in practice; some configurations also check other activity codes for release-related steps.
Where it is checked
- ME21N, ME21 - checked on save when creating a purchase order, against the purchasing group entered on the document.
- ME22N, ME22 - checked on save when changing an existing PO, and often again when the change screen is opened for editing.
- ME23N, ME23 - checked for display access; a missing 03 activity here produces the common 'no display authorization' complaint even though the user never intended to edit anything.
- Mass maintenance and release transactions (such as collective release worklists) - checked per document as each PO in the list is processed, so a batch job can partially succeed and partially fail by purchasing group.
- Background creation via MRP conversion, EDI/IDoc inbound processing, and workflow-driven release steps - checked under the processing user's authorization, which is frequently a background or communication user rather than the requester.
How to trace a failed check
Start with SU53 immediately after the failed action, before doing anything else in the session, since SU53 only shows the most recent failed check. Confirm the object shown is M_BEST_EKG and note the EKGRP and ACTVT values SAP tried to check against what the role actually contains. If SU53 is empty or ambiguous, or the failure happened in a background job, run the authorization trace (transaction STAUTHTRACE, or the older ST01 system trace filtered to authorization checks) for the specific user and time window, then reproduce the transaction. Pull the actual purchasing group from the PO document itself (header data) rather than assuming it matches the user's normal working group. Hand the security team: user ID, transaction code, PO number, the exact EKGRP value on the document, the ACTVT expected, and the trace or SU53 screenshot. Also check whether M_BEST_BSA, M_BEST_EKO, or M_BEST_WRK appear in the same trace window, since a fix limited to EKG will not help if one of those is also failing.
Whose problem this is
Functional side identifies which purchasing group(s) the user or business process legitimately needs and confirms the value against the actual PO data. Security maintains the role and the EKGRP field values. A usable request states the user ID, the transaction, the specific purchasing group code required, and whether create, change, or display access is needed, rather than a generic 'give them PO access' ticket.
Common pitfalls
- Role contains M_BEST_EKG with the right purchasing group but M_BEST_WRK or M_BEST_EKO is missing or scoped to a different plant or purchasing org, so the PO still fails; people conclude the EKG fix 'did not work' and re-request the same field.
- User has ACTVT 03 (display) but the process actually needs 02 (change), typically when a requester tries to add a text or attachment to a PO they can otherwise see fine.
- Composite or derived roles inherit an org-level value for EKGRP that was set for a different purchasing group during role build and never updated when a new group was created in configuration.
- A background or communication user (used for IDoc posting or MRP-driven PO creation) is authorized correctly for the requester but the technical user running the job lacks the purchasing group, and the error surfaces as a job failure with no obvious link back to this object.
- SU53 shows a stale or unrelated failure because another authorization check ran after the M_BEST_EKG failure in the same session, sending the investigation down the wrong path; the trace, not SU53 alone, should be treated as authoritative once the picture is unclear.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-auth-objects/m-best-ekgERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.