ME55 — Collective Release of Purchase Requisitions

ME55 is a list transaction: it pulls all purchase requisitions matching a selection variant that are pending release, and lets the user mark several of them for release in one save instead of opening each in ME54N. The structural fact that drives most confusion is that ME55 does not release requisitions in general, it releases them for one release code at a time, at whatever level of the assigned release strategy is currently due. A requisition can sit in the list, look releasable, and still fail to release because a prior release level in a multi-level strategy has not yet been cleared by someone else. The transaction respects the release strategy configuration entirely; it adds no logic of its own beyond batching the release action.

ME55 sits between requisition creation and requisition conversion into an RFQ or purchase order. A requester creates the PR in ME51N, the release strategy determined on the item blocks conversion until released, and the approver uses ME55 to clear a backlog of pending items on a recurring basis, for example daily or after a purchasing group meeting. A consultant reaches for ME55 rather than ME54N when the business problem is a queue of unreleased requisitions rather than one specific document someone is asking about; for a single PR, ME54N is faster because it opens the document directly. In S/4HANA, Fiori approval apps increasingly take over this role for end users, with ME55 remaining as the classic fallback for bulk operational releases.

In SE16 on EBAN, filter by BANFN for the requisition in question and check the release indicator and release status fields against the release strategy configured for that requisition's purchasing organization, document type and value. Compare the current status against what the strategy defines as fully released; a status that is not the final one confirms a level is still outstanding. Cross-check EKGRP and BSART to confirm the item matches the selection variant used in ME55, and check LOEKZ to rule out the item being deleted or blocked, which removes it from the collective release list even though it looks open in ME53N.

ME55 is available unchanged on S/4HANA as a classic collective release transaction; the release strategy logic and the tables it touches are the same as in ECC. What has changed is the front end: Fiori approval apps for purchase requisitions increasingly handle release for casual approvers, particularly where workflow-based release is configured, while ME55 remains the tool of choice for purchasing staff clearing a bulk worklist directly in the GUI. No structural or functional redesign of the transaction itself has occurred.

Functional MM/procurement owns the release strategy configuration, release code assignments and authorization roles that determine what appears in ME55. ABAP involvement is limited to custom logic in strategy determination, if any exists. A good handover includes the requisition number, the release code expected to see it, and the current release status pulled from EBAN, not just a screenshot of an empty list.

ME54N is the single-document release transaction and the natural comparison point for understanding why a specific requisition behaves differently in ME55. ME51N is where the requisition and its release strategy determination originate, worth checking when a document unexpectedly changes strategy mid-cycle. ME57 and ME21N are the downstream steps once release clears, useful for confirming a requisition actually needed release at all versus already being converted. ME2M and ME2L give reporting views across requisitions that help build the right selection variant for a recurring ME55 worklist.