ME52N — Change Purchase Requisition

ME52N opens an existing purchase requisition for editing at header and item level: quantity, delivery date, plant, storage location, account assignment, source of supply, item text, and item status (block, delete, close). It is the maintenance counterpart to creation and display, sharing the same screen layout and item detail tabs. The structural fact that explains most confusion is that a requisition item is not an isolated record — it carries a release status and, once converted, a link to a follow-on document such as a purchase order or RFQ. Editing fields that fall under the active release strategy after the item was already approved resets that approval, sending the item back through the release workflow. Editing fields once a PO already references the item is blocked or has no downstream effect, because the PO, not the requisition, now governs procurement.

Reached for whenever a requisition already exists and needs correction before it becomes a PO: a wrong delivery date caught before conversion, a cost center typo on the account assignment, a missing source of supply that a buyer needs to assign manually, or an item that needs to be blocked or deleted because the need went away. Also used heavily after MRP or a maintenance order generates requisitions automatically, since those often need manual source assignment or account assignment correction before they can be released. Buyers use it in preference to a reporting transaction whenever the change is to a single known requisition number; reporting transactions like the collective lists are used first when the requisition number is not known and needs to be found by material, plant, or requester.

Start in SE16 on EBAN filtered by the requisition number to see current quantity, release indicator, deletion indicator, and closed indicator for each item. Cross-check EKPO filtered by the same requisition number and item to confirm whether a purchase order already exists against that line, which explains locked fields. For history of a specific change, filter CDHDR by object class BANF and the requisition number, then join to CDPOS to see the exact field, old value, and new value, and who made the change and when.

ME52N is fully supported on S/4HANA and behaves the same way functionally; the underlying EBAN and EBKN structures were not restructured the way purchase order tables were. A Fiori app for managing purchase requisitions exists as the modern equivalent for editing and approving requisitions from a worklist, but ME52N remains valid and is still used routinely by purchasing teams, particularly for detailed multi-tab editing that the Fiori app does not fully replicate.

Functional MM territory, owned by the purchasing or buyer team, since every pitfall traces back to release strategy configuration, account assignment rules, or downstream document linkage rather than code. ABAP gets involved only if a custom validation, BAdI, or user exit fires on save and blocks or alters the change unexpectedly. A good handover includes the requisition number, item number, the field changed, the value before and after from CDPOS, and whether a PO or RFQ already exists against the item.

ME53N is the display-only counterpart, useful for confirming current state without risk of triggering a release reset. ME54N handles the manual release step when a change resets approval. ME57 is used to assign or search for a source of supply on a requisition item that lacks one. ME58 and ME59N convert requisition items into purchase orders, either manually or automatically, and are the natural next step once a corrected requisition is ready. ME2M and ME2L are the reporting transactions used to find requisitions needing correction by material or vendor before opening them individually in ME52N.