ME53N — Display Purchase Requisition

ME53N opens a purchase requisition in display mode using the same Enjoy screen framework as ME52N and ME51N, with a header area, an item overview grid, and a lower detail area split into tabs for material data, quantities/dates, valuation, account assignment, source of supply, and status. The one structural fact that explains most confusion: ME53N shares its screen layout, personalization settings, and even its authorization object family with the create and change transactions, so a user who cannot see a tab or a field in ME53N usually has the same restriction in ME52N, and the fix is rarely transaction-specific. Because it is display-only, it is the transaction to hand to anyone auditing a requisition, checking why a purchase order was not generated, or confirming release status without any risk of triggering a change document.

ME53N sits between requisition creation (manual via ME51N, or automatic from MRP, a maintenance order, a project, or a sales order) and conversion into a purchase order or outline agreement item. A buyer opens ME53N to confirm a requisition has cleared release strategy before attempting conversion, a requester uses it to check whether their request has been actioned, and a controller uses it to verify account assignment or cost center before financial postings occur. In practice, consultants reach for ME53N during incident triage far more than during normal processing: it is the fastest way to see release status, deletion indicator, and source-of-supply assignment in one screen before deciding whether the problem lives in the requisition itself or downstream in the purchase order or in MRP.

In SE16N pull EBAN filtered on BANFN for the requisition number and check the FRGKZ (release indicator) and LOEKZ (deletion indicator) fields directly rather than trusting the screen icon, since the icon can be misread when multiple release codes are involved. Join EBAN to EBKN on BANFN and BNFPO to compare account assignment lines against the source cost object. To confirm whether a purchase order was ever created, filter table EKPO on BANFN and BNFPO and check whether any line references the requisition; an empty result with a release indicator showing complete means the requisition is releasable but was never converted, which points at a buyer workload or MRP follow-up issue rather than a data issue.

ME53N continues to function unchanged on S/4HANA as the classic GUI display transaction for purchase requisitions, and remains the transaction most functional consultants use for troubleshooting because it exposes tabs and technical fields not always surfaced in the Fiori equivalent. S/4HANA adds Fiori apps for managing and approving purchase requisitions, including a My Purchase Requisitions type app for requesters and approval worklist apps for approvers, but these are workflow-oriented views rather than full replacements for the detailed tab structure in ME53N.

This is a functional MM/purchasing issue in nearly every case: release strategy configuration, purchasing group assignment, and account assignment logic are all customizing and master data, not code. Basis involvement is only relevant if authorization objects are misassigned at the role level. A good handover includes the requisition number, the exact tab and field showing the unexpected value, and the EBAN release indicator read directly from the table rather than the screen icon.

ME52N and ME51N are the change and create counterparts sharing the same screen and authorization framework, and issues diagnosed in ME53N almost always need to be resolved there. ME54N is the dedicated release transaction when a requisition is stuck awaiting individual release rather than the collective release available inline. ME57 and ME58 are the buyer-facing worklists for assigning sources and converting released requisitions into purchase orders, and are the next stop once ME53N confirms a requisition is release-complete but unconverted. ME2M and ME2L are reporting transactions useful for finding requisitions in bulk by material or vendor when the single-document view in ME53N is not enough.