BAPI_PRODORD_CREATE — Create a Production Order via BAPI
BAPI_PRODORD_CREATE creates a production order for a material and plant, mirroring the manual creation path of transaction CO01. It triggers BOM explosion and routing selection like the online transaction, returns the new order number in an export parameter, and requires an explicit BAPI_TRANSACTION_COMMIT to persist. It does not release the order.
This page covers what BAPI_PRODORD_CREATE actually does when creating a production order outside CO01, the parameters that matter, and why RETURN has to be read message by message rather than just checked for emptiness. It also covers the commit trap, the recurring master-data pitfalls that let an order be created empty or not at all, and where the object sits relative to its sibling BAPIs for release, detail read, and confirmation.
Published 16 Sept 2026· 1,092 words
What it does
BAPI_PRODORD_CREATE creates a production order for a material at a plant, mirroring the manual creation path of transaction CO01 rather than the planned order conversion path of CO40. Called with a material, plant, order type and quantity, it triggers the same BOM explosion and routing selection logic the online transaction runs, populating order components and operations from master data unless overridden through the table parameters. It is used by interfaces and custom programs that need to generate production orders without a user sitting in CO01, typically from external planning systems, custom demand-to-order logic, or batch conversion programs that bypass the standard MRP run. It does not release the order; release is handled by a separate call.
Important parameters
The interface is narrower than the online transaction screen; most order header detail is either derived from material master and order type customizing or passed through a small set of import parameters, with two table parameters available for overriding what BOM and routing determination would otherwise supply.
- MATERIAL - the material number the order is created for, drives BOM and routing determination
- PLANT - the plant in which the order is created and where BOM/routing lookup runs
- ORDER_TYPE - production order type, controls number range, order category, and which scheduling and costing profile applies
- QUANTITY - the order quantity and unit of measure
- NUMBER - export parameter returning the production order number generated in the current work process
- RETURN - standard return table carrying every message raised during BOM explosion, routing selection, scheduling and costing
- Table parameters for components and operations - optional, let the caller add or override the material components and routing operations that BOM/routing master data would otherwise supply automatically
Commit behaviour
BAPI_PRODORD_CREATE does not commit. The order exists only inside the current work process until BAPI_TRANSACTION_COMMIT is called explicitly afterward. Forgetting the commit is a recurring integration bug: the BAPI returns a production order number in NUMBER as though creation succeeded, the caller logs success, and the order is rolled back at the end of the logical unit of work with nothing written to the database. The order number handed back was never reserved beyond that call, so a subsequent lookup through BAPI_PRODORD_GET_DETAIL or transaction CO03 comes back with the order not existing, and the interface team spends time chasing a number the functional side can never find.
Return handling
RETURN is a message table, not a single flag, and the whole table has to be scanned rather than just checked for emptiness. Filtering only on message type E or A and treating everything else as success misses warnings that matter operationally: BOM not found for the plant, routing not found, component shortage, or a missing work center that leaves the order created but with no operations attached. An order created with only warnings still gets a value back in NUMBER, so callers that stop checking once NUMBER is populated end up pushing incomplete orders into shop floor execution, discovered later when confirmation or goods issue fails because there is nothing on the order to confirm against. The message ID and message number in RETURN identify exactly which master data element is missing and should be logged verbatim rather than the free text alone, because the free text is not always sufficient on its own and the ID/number pair is what a functional consultant needs to trace the missing BOM, routing, or work center back to its master data transaction.
ECC vs S/4HANA
BAPI_PRODORD_CREATE remains valid on S/4HANA for classic discrete production orders; there is no S/4-only replacement for this specific creation step, and it has not been announced as deprecated. What has changed around it is the surrounding process: S/4 favors driving order creation from MRP or from planned order conversion rather than direct manual creation, and release and confirmation increasingly go through their own dedicated APIs. For process orders the object model and BAPI set are different, so this BAPI should not be assumed to work for a process order scenario.
Common pitfalls
- Order created without components or operations because BOM or routing was not found at order creation time; RETURN carries only a warning, so the order looks successful but is functionally empty
- Material not extended to the plant or MRP area; RETURN carries an error but a batch loop continues to the next material without flagging which one failed
- Missing BAPI_TRANSACTION_COMMIT after a successful call, so the order number returned is never persisted and disappears at the end of the LUW
- Costing not triggered synchronously with order creation in every configuration, leaving the order without a cost estimate until a separate costing run, which then blocks settlement later
- Calling the BAPI in a tight loop for mass order creation without committing between calls, leading to lock contention on the order number range and on material master records
- Scheduling parameters left at default producing basic dates that do not match the requirement date driving the order, discovered only when the shop floor questions why the order due date is wrong
Whose problem this is
Functional consultants own the master data conditions: material extended to plant and MRP area, BOM and routing existing and not locked, order type configured with a valid scheduling and costing profile. Developers own correct parameter mapping and full RETURN handling, including the commit. When an order comes back empty or missing, the evidence to hand over is the RETURN table content with message IDs, not a screenshot claiming an order number was created.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-bapis/bapi-prodord-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.