M_BEST_EKO — Purchase Order Check by Purchasing Organization

M_BEST_EKO restricts purchase order activity to specific purchasing organizations. It is one of four objects SAP checks together for purchase orders - the others cover plant, purchasing group and document type - and all four must pass for the action to succeed. The structural fact that causes most confusion: the purchasing organization value used in the check is not typed in by the user, it is derived from the purchase order header (or from the item's plant, for plant-assigned purchasing organizations). A buyer can hold perfect authorization for the purchasing organization they think they are working in and still fail the check if the document's actual purchasing organization is different, for example because a plant was reassigned to a new purchasing organization and the role was never updated to match.

The check fires inside the purchase order transactions - ME21N on create, ME22N on change, ME23N on display, and ME28 or the release transactions when a PO is released - at the point the system resolves the document's purchasing organization, before it lets the user proceed into the item overview or saves the document. It also fires in list and reporting transactions that filter or display purchase orders by purchasing organization, such as ME2N, ME2M and similar list transactions, and in message output and output determination steps that touch the purchase order. Background and batch processing that creates or changes purchase orders, including conversion from purchase requisitions and scheduling agreement releases, runs through the same check because it calls the same underlying purchase order logic. The check is not tied to a single screen; any code path that opens, saves, or lists a purchase order object triggers it for the purchasing organization derived from that document.

Start with SU53 immediately after the failure, before doing anything else in the session, since SU53 only shows the last failed check and gets overwritten. Look specifically for M_BEST_EKO in the list rather than assuming the first M_BEST_* object shown is the culprit - a failure can show multiple objects in this family and only one may actually be short. If SU53 is inconclusive or the session has moved on, run the authorization trace (transaction ST01 on older systems, STAUTHTRACE on current ones) for the user, reproduce the failing step, then filter the trace output to M_BEST_EKO and note the EKORG and ACTVT values the system actually checked. Compare that EKORG value against what the user expected - it may not match the purchasing organization the buyer believes they are working in. Hand the security team the transaction code, the ACTVT value, and the exact EKORG value from the trace, not the purchasing organization name the buyer typed or selected on screen.

This is a security team fix once the functional side has confirmed the correct purchasing organization and activity from the trace. A usable request states the user ID, the transaction, the ACTVT and EKORG values pulled from ST01/STAUTHTRACE or SU53, and confirmation of which purchasing organization the user's job actually requires - not the one they assumed.