BAPI_PLANNEDORDER_CREATE — BAPI_PLANNEDORDER_CREATE creates a planned order
BAPI_PLANNEDORDER_CREATE creates a single planned order in table PLAF, mirroring transaction MD11's manual planned order creation. It requires POHEADER and POHEADERX to pass field values, returns the new order number in PLANNEDORDER, and needs an explicit BAPI_TRANSACTION_COMMIT afterward. Reading only the first line of RETURN instead of scanning the full table is the most common integration defect built around it.
Covers what BAPI_PLANNEDORDER_CREATE does, its header and flag parameters, and why it depends on an explicit commit call to persist anything. Focuses on the RETURN table handling mistakes, order type gaps, and master data omissions that cause planned orders to appear created but end up empty, unpersisted, or with missing components in real interfaces.
Published 16 Sept 2026· 1,124 words
What it does
BAPI_PLANNEDORDER_CREATE creates a single planned order for a material in a plant, the same object MD11 creates when a planner adds a planned order manually outside the regular MRP run. The planned order carries order type, total quantity, start and finish dates, MRP controller and procurement details, and depending on the order type and material master settings it can trigger BOM and routing explosion to populate components and operations the same way an MRP run would. It is used in custom demand-driven interfaces, external planning system integrations, manual correction tools that need to inject a planned order without running the regular planning transactions, and data migration loads where legacy planned orders are recreated in SAP. On success it writes a new record to the planned order table PLAF.
Important parameters
The interface follows the usual BAPI pattern of a header structure paired with a flag structure: a value only takes effect if the matching flag is set.
- POHEADER - header structure carrying material number, plant, order type, total planned order quantity, start date, finish date, MRP controller and procurement type
- POHEADERX - flag structure with an X for every field in POHEADER that should actually be transferred; a field left blank here is ignored even if POHEADER carries a value
- PLANNEDORDER - export parameter returning the number of the newly created planned order
- RETURN - standard return table of message lines carrying every message the call generated, including warnings that do not stop order creation
- component and dependent requirement tables exist for callers who want to override the BOM-exploded component list directly, but most interfaces leave these empty and let standard component determination run based on order type and material master settings
Commit behaviour
BAPI_PLANNEDORDER_CREATE does not commit on its own. Like the rest of the classic BAPI interface it validates and buffers the new planned order within the current SAP LUW and returns the order number as if the record already exists, but nothing is written to PLAF until BAPI_TRANSACTION_COMMIT is called afterward with WAIT set. Forgetting the commit is the most common cause of intermittent failures in custom interfaces: the calling program reads back PLANNEDORDER, logs success, and the record simply is not there on the next read because the LUW rolled back at the end of the work process. This is worse in background jobs, where the missing commit produces no error at all, only a silent gap between what the log claims and what a display transaction shows.
Return handling
RETURN is a table, not a single message, and reading only the first line is the single most common interface bug built around this BAPI. A successful creation can still carry warning lines about component shortages, BOM explosion failures, or date adjustments buried further down the table; code that checks only the first entry will treat a partially broken planned order as a clean success. The correct pattern loops the full table, treats any line with type E or A as a hard failure, and does not assume PLANNEDORDER is trustworthy just because the first row is empty. The reverse failure also happens: RETURN carries only warnings, PLANNEDORDER is filled, but no commit follows, so the interface logs a warning-only success while the order never reaches the database. Interfaces built to stop scanning at the first message rather than reading the whole table have shipped defects into production, because SAP orders messages by internal processing sequence, not by severity.
ECC vs S/4HANA
BAPI_PLANNEDORDER_CREATE remains valid on S/4HANA. There is no released successor API that supersedes it for planned order creation, and the classic table PLAF still underlies the planned order object in S/4HANA the same way it did in ECC. MRP Live and the newer planning apps generate planned orders through their own internal logic rather than through this BAPI, but for custom interfaces that need to create a planned order programmatically outside of a planning run, this is still the standard entry point, with no deprecation attached to it.
Common pitfalls
Most failures around this BAPI trace back to one of a small set of causes, roughly in the order worth checking.
- Missing BAPI_TRANSACTION_COMMIT after a returned PLANNEDORDER number: the interface logs success, the number is never written to PLAF, and the gap only surfaces when someone tries to display the order and finds nothing
- Order type not configured for the material's MRP type or procurement type: the BAPI creates the header but skips BOM and routing explosion, producing a planned order with no components, which fails silently at later conversion to a production order
- Material not extended to the plant, or missing MRP view: RETURN carries a generic error that does not name the missing view, easy to miss in an automated loop that only checks whether an order number came back
- Requested start or finish date falling on a non-working day in the plant's factory calendar: the system shifts the date without raising an error, so the created planned order dates do not match what the interface requested
- Looping the BAPI for bulk creation without an individual commit per order, which produces intermittent locking or leaves a batch of orders half-persisted when the job aborts partway through
Whose problem this is
Functional PP consultants own order type customizing, MRP type and procurement type on the material master, and BOM or routing status, the things that decide whether components get exploded. Developers own the commit sequence and full RETURN table handling. When a planned order comes out with no components, functional needs to confirm the order type settings before developers get blamed; when orders vanish after an apparent success, developers need to prove a commit call was actually made.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-bapis/bapi-plannedorder-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.