BAPI_REQUISITION_CREATE — Legacy BAPI_REQUISITION_CREATE — Obsolete Purchase Requisition Interface
BAPI_REQUISITION_CREATE is the legacy purchase requisition creation BAPI associated with the old ME51 processing model. SAP Purchasing documentation states that this interface was replaced by BAPI_PR_CREATE when ME51 was superseded by ME51N, and the old BAPI is no longer supported for future enhancement. Keep it only as a legacy-support reference, not as the recommended interface for new development.
This page covers what BAPI_REQUISITION_CREATE actually creates, which tables carry the mandatory data, and why interfaces built on it silently lose requisitions when commit or return checking is done carelessly. It also addresses account assignment errors, release strategy timing, and where the BAPI sits relative to newer purchase requisition APIs in S/4HANA.
Published 20 Sept 2026· 924 words
What it does
BAPI_REQUISITION_CREATE is the older purchase requisition BAPI from the classic ME51 generation. It can still be encountered in long-lived integrations, but SAP Purchasing documentation explicitly states that the old BAPI_REQUISITION_CREATE/BAPI_REQUISITION_CHANGE pair was replaced by BAPI_PR_CREATE/BAPI_PR_CHANGE with the Enjoy transactions. ERPClimb should therefore document this page primarily for legacy troubleshooting and migration, not recommend it for new interfaces.
Important parameters
- REQUISITION_ITEMS - mandatory table of item lines: material or short text, plant, storage location, quantity, unit of measure, delivery date, requisition type and item category. This is where the created requisition number and item number are returned after the call.
- REQUISITION_ACCOUNT_ASSIGNMENT - one row per item requiring account assignment, carrying cost center, internal order, WBS element or similar depending on account assignment category; mandatory whenever the item category demands it.
- REQUISITION_ITEM_TEXT - long text lines attached to individual requisition items, used for item note or item text fields visible in ME52N.
- RETURN - standard BAPIRET2-style message table; carries success confirmation, warnings and hard errors, and is the only reliable indicator of whether the requisition actually persisted.
Commit behaviour
The BAPI does not commit the database update itself. It builds the requisition in the current LUW and returns a requisition number that looks final, but nothing is written to the EBAN table until a separate explicit commit call closes the transaction. Interfaces that call the create BAPI and then simply check the returned number as proof of success, without issuing the commit, will see the requisition vanish on the next read. This is one of the most common causes of a functional user reporting a requisition number that ME53N cannot find: the create step ran clean, the commit step was never called or was called on a different session, and the work was rolled back at the end of the program.
Return handling
RETURN must be scanned for any line with TYPE equal to E or A before treating the call as successful; a populated requisition number in REQUISITION_ITEMS does not by itself mean the item was created, because the BAPI can partially populate output structures even on failure. The recurring interface bug is checking only whether RETURN is empty. RETURN is frequently non-empty on a fully successful call because informational and warning messages are appended routinely, for example about release strategy determination or default value substitution, and code that treats any non-empty RETURN as failure aborts perfectly good creations. The opposite bug is just as common: code that treats any populated RETURN as noise and never inspects TYPE, and so ships requisitions with rejected account assignments or missing mandatory fields straight past validation, because the error message was sitting unread in the table while the batch job logged 'completed successfully'.
ECC vs S/4HANA
SAP states that the classic ME51/ME21 generation and associated old BAPIs such as BAPI_REQUISITION_CREATE are obsolete and no longer the supported target for future enhancements. For current on-stack requisition creation, use BAPI_PR_CREATE where the BAPI pattern is still appropriate; for new S/4HANA clean-core integration, evaluate the released Purchase Requisition API. Existing legacy calls may still exist technically, but availability does not make them strategic or supported for new development.
Common pitfalls
- Missing or mismatched account assignment category and account assignment data throws an error inside RETURN rather than a hard dump, and is easy to miss if only the requisition number is checked.
- Release strategy is evaluated at save, not at the moment the BAPI runs; a requisition can be created successfully and still sit blocked from conversion to a purchase order because release characteristics were not what the interface assumed.
- Service and subcontracting item categories often need additional service line or component data that this BAPI does not fully expose, forcing developers to fall back to screen-based BDC or a different API for those item categories.
- Deleted flag and item-level blocking are not visible in the create response; a requisition can be created and then immediately flagged for deletion by a background job or workflow, which the interface has no way of detecting from the BAPI call alone.
- Bulk creation loops that forget to commit per batch, or commit too early inside a loop, either lose data on rollback or fragment what should be one LUW into many, causing partial failures that are hard to reconcile afterward.
Whose problem this is
Interface failures around commit handling, RETURN parsing and LUW boundaries are developer issues, not configuration issues. Account assignment rejections, release strategy surprises and item category restrictions are functional territory and need the MM or procurement consultant to confirm what the configuration actually expects before the interface is changed. The evidence that settles the argument is the RETURN table content from the actual failing call, not a description of what should have happened.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-bapis/bapi-requisition-createERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.