ME59N — Automatic Purchase Order Creation from Requisitions

ME59N takes a selection of purchase requisitions and converts eligible items into purchase orders in one run, replacing the manual item-by-item work of ME21N or ME57. The structural fact that explains most confusion: ME59N does not choose a vendor or decide sourcing logic on the fly. It only executes conversions where the requisition item already has a fixed, unambiguous source of supply (an info record, contract, or scheduling agreement) and is flagged as eligible for automatic PO generation. If that assignment is missing, ambiguous, or blocked, the item is skipped and shows up in the error log rather than as a created PO. Consultants who expect ME59N to 'find' a vendor the way a buyer would in ME57 are working against how the transaction is designed.

ME59N sits at the conversion step of P2P, downstream of requisition creation (manual, MRP-generated, or via ME51N) and requisition release if a release strategy is active. It is the tool of choice for high-volume, low-value, repetitive procurement where sourcing is already contractually fixed, such as MRP-driven stock replenishment against a running contract or scheduling agreement. It is typically scheduled as a background job rather than run interactively. Consultants reach for ME21N or ME57 instead when sourcing still needs a decision, negotiation, or manual vendor selection; ME59N is for the volume that has already been resolved upstream and just needs to be turned into paper.

In SE16 on EBAN, filter by the requisition number range used in the run and check whether the fields holding the resulting purchase order number and item are populated; blank fields on an item that should have converted point to a skipped item, not a silent success. Cross-check the release indicator field to confirm the requisition was actually released before the run. For items that did convert, join EBAN's stored PO number and item to EKPO on the corresponding key to confirm the PO header and item exist and match the expected vendor from the source of supply.

ME59N exists and behaves the same way on S/4HANA; the eligibility logic around fixed sources, release status, and auto-PO flags has not materially changed. S/4HANA offers a Fiori app oriented around automatic purchase order creation for similar mass-conversion scenarios, but the underlying prerequisites a consultant needs to check when conversions fail are the same ones documented here regardless of which front end triggered the run.

This is a functional MM procurement issue in the vast majority of cases: source of supply maintenance, release strategy configuration, and vendor master blocks are all functional master data and configuration. Basis involvement is limited to background job scheduling or authorization failures preventing the job from running at all. A good handover includes the selection variant used, the full error log with reason codes per skipped item, and the requisition numbers that failed, not just a note that the job produced fewer POs than expected.

ME54N is the natural predecessor when requisitions are stuck unreleased, and its release strategy status should be the first check before touching ME59N configuration. ME57 is the manual equivalent for assigning a source and converting an individual item, useful for clearing the error log one item at a time rather than fixing upstream master data. ME11 governs the info record conditions and validity that determine whether a source counts as fixed and eligible for automatic conversion. MK02 is where vendor purchasing blocks are checked and lifted when a vendor block is the reason items are skipped.