BAPI_SALESORDER_SIMULATE — Sales Order Simulation BAPI

BAPI_SALESORDER_SIMULATE acts on the sales order object without creating one. It mirrors the processing that VA01 performs internally when it derives item categories, runs pricing, checks availability and evaluates the credit exposure of a proposed order, but it stops before the document is saved. Nothing is written to VBAK, VBAP or VBEP, no stock is reserved, and no credit limit is consumed. It is used wherever a caller needs to show a customer what an order would cost and when it would ship before that customer commits to placing it: web storefronts, quoting tools, CPQ front-ends, EDI pre-validation layers. Functionally it is the read-only sibling of BAPI_SALESORDER_CREATEFROMDAT2, sharing most of the same input structures so that a simulate call and a create call can be built from the same data assembly code.

The interface reuses most of the structures also used by the create BAPI, since both drive the same internal order processing.

Nothing is committed and nothing needs to be, because the BAPI never stages a document for the update task. Calling BAPI_TRANSACTION_COMMIT afterwards is harmless but pointless, since there is no pending change to flush. The risk is not a missing commit, it is a caller who expects a document number back and finds the relevant output field blank, then either throws an unhandled exception or, worse, silently defaults to a fake or previous order number, which then corrupts logging or reconciliation downstream. Any interface built against this BAPI should be written on the explicit assumption that it never persists anything, not on the assumption that a commit step is simply missing from the call sequence.

RETURN mixes message types in one flat table and the simulation deliberately surfaces messages that in a real create call would be hard stops, alongside messages that are only advisory. A caller who treats an empty RETURN table as the only success criterion misses warnings such as a delivery date being pushed out or a pricing condition failing to find a record, both of which change the commercial result shown to the customer even though they are type W, not E. Conversely, a caller who aborts on any non-empty RETURN table will fail on routine informational messages that carry no real problem. The correct pattern is to inspect TYPE together with the message ID and number for every line, and to treat credit-block and incompleteness messages as decision points rather than blanket failures, since the point of simulate mode is precisely to surface those conditions before the customer is told the order can go ahead. A frequent interface bug is discarding RETURN entirely and relying only on populated output tables as proof the simulation succeeded, which hides exactly the messages the caller was supposed to act on.

BAPI_SALESORDER_SIMULATE remains a valid function-module-based BAPI on S/4HANA and no released successor API specifically replaces the simulate-only use case. Some individual pieces it touches, such as availability checking, have modern equivalents through advanced ATP, but a caller wanting a single combined pricing, availability and credit preview still routes through this BAPI or through direct calls into the same core order-processing logic. There is no deprecation notice against it and no indication a Fiori-era API is intended to take over this specific function.

Most production issues with this BAPI come from treating a clean simulation as a guarantee rather than a snapshot at a point in time.

A mismatch between what simulation shows and what the real order does is primarily a functional configuration question: pricing procedure, condition record validity, availability check group, credit management settings. Development gets involved when the input structures are populated incorrectly or when RETURN is being read incompletely. Functional needs to reproduce the exact same input combination manually in VA01 to prove the discrepancy is not simulation-specific; development needs to provide the full input structures and the complete RETURN table dump from the failing call.

The transaction it mirrors is VA01/VA02 in check or simulate mode. The relevant tables underneath, once a real order exists for comparison, are VBAK, VBAP and VBEP. The sibling BAPIs sharing structures and typically called around the same integration are the create, change, list and status BAPIs for sales orders.