BAPI_PR_CREATE — Legacy purchase requisition creation BAPI

BAPI_PR_CREATE creates a purchase requisition, the same object produced manually through transaction ME51N. It generates the header and item records that would normally populate the requisition tables when a demand is raised outside the direct purchase order process, before that demand has been converted into a purchase order, a reservation, or a contract release. It is used mainly in inbound interfaces: maintenance order integration, MRP-driven external systems, supplier or requester portals, and custom workflow tools that need to inject a requisition into the procure-to-pay chain without a user sitting at ME51N. The requisition it creates is subject to the same account assignment rules, source-of-supply checks, and release-strategy configuration that ME51N enforces, so any restriction set on the requisition document type or item category applies to the BAPI call exactly as it would to the manual transaction.

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.

BAPI_PR_CREATE predates the interface SAP has continued to document and extend for requisition creation. BAPI_REQUISITION_CREATE supports multiple items, richer account assignment, and closer alignment with the requisition data model used inside S/4HANA, and is the call new integration work should target. Anything feeding the S/4HANA Fiori requisition apps should use that BAPI or the released OData service rather than this older one. BAPI_PR_CREATE still executes on systems where it has not been retired, but it should not be the starting point for a new build.

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, and ME53N are the transactions that create, change, and display the same requisition manually; the purchase requisition tables (header and account assignment) hold the persisted result once the commit runs. BAPI_PR_CHANGE is the matching update call for an existing requisition, and BAPI_REQUISITION_CREATE is the newer creation call most current projects use instead. Once released, the requisition typically feeds a purchase order created through BAPI_PO_CREATE1.