BAPI_PR_CHANGE — Changing a Purchase Requisition via BAPI

BAPI_PR_CHANGE acts on the purchase requisition object, the same EBAN-based document maintained manually through ME52N. It is used to update item data on requisitions already saved in the system: quantities, delivery dates, plant, storage location, account assignment values, short text, and similar item fields. It cannot create a new requisition (that is a separate BAPI's job) and it does not perform release strategy actions or deletion flag removal in a reliable way. It is typically called from interfaces that keep a requisition synchronized with an external planning or procurement system, or from batch jobs that mass-update delivery dates when a supplier confirms a revised schedule. Because it works item by item, header-level attributes that do not exist on a requisition in the same way they exist on a purchase order are out of scope.

BAPI_PR_CHANGE does not commit the database update itself. The change is held in the update task until the calling program explicitly calls BAPI_TRANSACTION_COMMIT. If the caller omits the commit, the BAPI can return a clean RETURN table with no error messages, the calling program logs success, and the requisition is unchanged the moment the session ends because the update was rolled back. This is the single most common cause of intermittent integration failures reported as 'sometimes it works, sometimes it does not' when nothing about the input data actually varies between runs. Interfaces that batch multiple requisition changes in a loop and commit once at the end also need to watch for a single bad item aborting the whole batch if error handling is not isolated per call.

RETURN is a table, not a single flag, and the only reliable check is scanning every row for TYPE E or A. A common defect is checking only the first row, or checking SY-SUBRC after the call, which BAPIs do not reliably set the way classic function modules do. Warnings (TYPE W) are frequently present even on a fully successful change, for example when a delivery date shift triggers a purchasing info record note; treating any non-empty RETURN as failure causes false negatives that block otherwise valid updates. Conversely, treating an empty-looking RETURN as success without checking is what produces silent no-op changes when ITEMDATAX flags were set wrong or the item number did not exist. The correct pattern is to loop the full table, fail the transaction on any E or A row, log W and I rows without failing, and only issue the commit after this evaluation, never before.

BAPI_PR_CHANGE continues to function on S/4HANA and remains the standard BAPI-layer path for changing a purchase requisition from an external or custom program. SAP has not published a newer BAPI that supersedes it for this purpose, and Fiori apps for requisition management call the same underlying business logic rather than a different released API. Custom developments built on this BAPI do not need rework purely because of an S/4HANA migration, though field extensions on EBAN in the source system still need corresponding entries in ITEMDATA and ITEMDATAX to be picked up.

This sits with the interface or ABAP developer first, since most failures trace to a missing commit or an unset X flag rather than to the requisition's master data. The developer needs the exact ITEMDATA and ITEMDATAX payload sent for the failing item and the full RETURN table content, not a summary. Functional gets involved only after that evidence shows a genuine status or release-strategy block on the document itself.

The manual equivalent is ME52N, and the item data mirrors table EBAN with account assignment detail in EBKN. The natural sibling is the requisition creation BAPI used to generate the document in the first place, and BAPI_TRANSACTION_COMMIT is required immediately after any successful change to persist it. Downstream, a changed requisition quantity or delivery date is frequently what triggers a follow-on purchase order change through the corresponding PO-change BAPI.