BAPI_MATERIAL_STOCK_REQ_LIST — Read-Only BAPI for Stock Requirements List Data

BAPI_MATERIAL_STOCK_REQ_LIST retrieves the stock/requirements situation for a material at plant or MRP area level, the same data set that transaction MD04 renders as a running list. Each line it returns corresponds to an MRP element: physical warehouse stock, open purchase orders, planned orders, production or process orders, reservations, and sales order requirements, each carrying a date and a quantity, together forming the same cumulative available-quantity picture MD04 shows the planner. It is a query, not a maintenance BAPI. Nothing it does creates, changes, or deletes a document. It exists so external planning tools, supplier portals, or reporting layers can pull the MD04 view programmatically instead of requiring a user to open the transaction and read the screen manually.

This is a read-only BAPI. It does not post, change, or delete anything, so there is no commit to worry about. Calling BAPI_TRANSACTION_COMMIT after it has no effect because the database was never touched. Interfaces sometimes call it in the same wrapper as posting BAPIs and add a commit reflexively out of habit; it is harmless here but worth removing so the next person reading the interface code does not assume a change was made.

RETURN must be scanned for message type before the MRP_ELEMENTS table is trusted. An empty RETURN table does not guarantee a meaningful result; it can also mean the material/plant combination has no open MRP elements at all, which is a valid business state, not an error. Conversely, a type E entry pointing at an invalid plant or a material not extended to that plant means MRP_ELEMENTS will be empty for a completely different reason, and treating both cases the same in downstream logic causes false 'no demand' conclusions that ripple into supplier communication or replenishment decisions. Interfaces that only check whether MRP_ELEMENTS has rows, and skip RETURN entirely, are the most common bug: a locked MRP data area or a temporary read failure returns zero rows with a warning in RETURN that nobody looked at, and the caller reports 'no stock, no requirements' when the truth is 'could not read'. Always pair the row count check with an explicit RETURN scan for type E or A before drawing any conclusion.

In S/4HANA the equivalent screen is the Stock/Requirements List Fiori app, built on newer CDS-based data sources rather than the classic MD04 read logic. BAPI_MATERIAL_STOCK_REQ_LIST still works in compatibility mode and continues to return the expected structure, but new integration work should first check whether a released OData or API Business Hub service covering the same stock/requirements list exists for the target release, since those are built for external consumption and tend to be better documented and supported than a classic BAPI wrapper around an MD04-era function.

Functional MM/PP owns what the stock/requirements picture for a material should look like and whether MRP area logic applies; that side should be able to reproduce the same numbers in MD04 for comparison. Development owns the extraction wrapper, the RETURN handling, and any caching or batching logic; when the interface disagrees with MD04, the first ask is a side-by-side screenshot of MD04 against the raw MRP_ELEMENTS dump for the same material, plant, and timestamp.

The transaction it mirrors is MD04, the individual stock/requirements list. It draws on the same underlying stock and MRP element data that MMBE, MD04, and the MRP run itself use, without exposing a specific table name here since the read logic spans several planning tables. Siblings in the same reporting family include the material availability check BAPI and the material detail lookup BAPI, both used alongside it when an interface needs the full picture: current stock, ATP, and master data together.