BAPI_PR_CREATE — Create Purchase Requisitions with the ME51N-Era BAPI

BAPI_PR_CREATE creates purchase requisitions through the newer purchasing object model used by ME51N. SAP Purchasing documentation explicitly distinguishes it from the older BAPI_REQUISITION_CREATE: BAPI_PR_CREATE is the Enjoy-era interface SAP recommends for purchase requisition creation. It supports the modern PR header/item structures and application validations and should be preferred over the obsolete classic requisition BAPI for on-stack BAPI integration.

The exact structure and table names for this legacy call vary slightly by release, so the parameters below are described by content rather than by asserting a literal ABAP identifier that may not be correct for every system.

Like nearly every classic MM BAPI, BAPI_PR_CREATE does not commit its own work. It builds the requisition inside the current logical unit of work and returns control without releasing database locks or making the document visible to other sessions. The caller must issue an explicit commit afterward. If that call is skipped, the requisition exists only inside the calling program's own database session: it disappears on rollback, on program termination, or at the end of an asynchronous RFC call, while the export field still shows a number that was never actually persisted. This is the source of the classic complaint that the interface reported success and a requisition number, but ME53N cannot find the document.

RETURN is the only reliable success signal; the function module completing without a runtime error is not enough, because BAPI_PR_CREATE, like its siblings, can finish processing normally while reporting rejection only through a row with type E or A in RETURN. An interface that checks only sy-subrc, or that treats a filled export number as proof of success, will log a rejected requisition as created, because a preliminary number can appear even when the document is later rolled back internally. The correct pattern is to scan every row of RETURN for type E or A before deciding the call succeeded, to log type W rows separately since they often carry configuration warnings such as a missing source list or missing info record that explain a release-strategy surprise later, and to never issue the commit until that scan confirms no error row exists. Interfaces that commit unconditionally and only inspect RETURN afterward end up creating requisitions with incomplete account assignment, which then fail during conversion to a purchase order, and the failure gets diagnosed days later, far removed from the actual cause.

SAP Purchasing documentation states that BAPI_REQUISITION_CREATE is an old interface tied to obsolete ME51 and that BAPI_PR_CREATE replaced it for ME51N-era processing. Existing BAPI_PR_CREATE integrations remain relevant in S/4HANA on-premise/private cloud, although new clean-core integrations should also evaluate the released S/4HANA Purchase Requisition API. Do not describe BAPI_PR_CREATE as superseded by BAPI_REQUISITION_CREATE—the relationship is the opposite.

The failures below recur across interfaces built directly on this call rather than on a newer API.

Functional owns the failure when RETURN reports a configuration message: missing account assignment default, blocked document type, or a release strategy step that has not fired yet. Functional needs the exact RETURN row text and the requisition document type used. Developer owns it when the commit was never issued, when RETURN was ignored entirely, or when a warning row was treated as success; developer needs the interface's own trace of the call sequence and the commit call, or the absence of one.

ME51N/ME52N/ME53N are the corresponding Enjoy transactions. EBAN and EBKN are useful diagnostic tables after persistence. BAPI_PR_CHANGE is the matching modern change BAPI. BAPI_REQUISITION_CREATE and BAPI_REQUISITION_CHANGE are legacy classic interfaces that SAP documents as replaced/unsupported for future enhancement; BAPI_PO_CREATE1 is the modern purchasing-order BAPI for follow-on PO creation.