BAPI_REQUISITION_CREATE — BAPI for Creating Purchase Requisitions
BAPI_REQUISITION_CREATE creates one or more purchase requisition items, mirroring transaction ME51N. It builds header-less requisitions directly at item level, accepting material, plant, quantity, account assignment and item category per line. It does not commit automatically, so the caller must explicitly commit the LUW or the requisition is rolled back despite the BAPI returning what looks like a valid requisition number.
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 16 Sept 2026· 1,036 words
What it does
BAPI_REQUISITION_CREATE creates purchase requisition items against the business object behind purchase requisitions, functionally equivalent to what ME51N produces in dialog. A purchase requisition in SAP has no true header the way a purchase order does; each item is essentially independent, carrying its own material or short text, plant, storage location, quantity, delivery date, item category and account assignment. The BAPI is used to generate these item lines programmatically, most commonly from external planning systems, custom MRP-adjacent logic, e-procurement front ends, or batch conversion routines that turn demand signals into procurement documents. It supports both stock and account-assigned requisitions, and both standard and service or subcontracting item categories, though the depth of data it accepts for exotic item categories is limited compared to what the dialog transaction allows.
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
BAPI_REQUISITION_CREATE continues to function in S/4HANA and is not formally withdrawn, but new integration work is generally steered toward the released purchase requisition API surface built for S/4HANA extensibility, which offers cleaner field-level control and better alignment with the simplified data model. Existing interfaces built on this BAPI are not forced to migrate and typically keep working after conversion, but new custom development, particularly anything exposed through the extensibility framework or side-by-side extensions, should use the released API rather than adding new calls to this older BAPI.
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.