BAPI_INTERNALORDER_CREATE — Create a CO Internal Order via BAPI

BAPI_INTERNALORDER_CREATE creates a CO internal order, the same object built manually through the internal order create transaction. It builds the order master record: order type, controlling area, description, responsible cost center, profit center, and the settlement rule and status data that determine how costs collected on the order will eventually be moved out. It does not post any costs itself; it only creates the shell that later postings (time confirmations, invoice entries, goods movements) will charge against. It shows up in mass order creation during data migration, in interfaces from adjacent planning systems, and in custom apps that need to spin up statistical or real orders without a user opening the standard maintenance transaction.

Like every classic BAPI, BAPI_INTERNALORDER_CREATE does not commit on its own. The order is created inside the current SAP LUW but stays uncommitted until the caller explicitly calls BAPI_TRANSACTION_COMMIT afterward. Skip that call and the order exists in memory long enough to hand back an order number, then disappears when the transaction ends with no error raised anywhere. This produces a familiar ticket: the interface log shows success and a valid order number, but the order does not exist when anyone looks for it in the system. From the BAPI's own point of view the create genuinely worked; the missing commit is entirely a caller-side gap, not something the BAPI itself can flag.

RETURN is a table, not a single message, and creation either succeeds completely or fails completely. An interface that only checks whether RETURN is empty, or only reads the first row, will misinterpret partial validation output as full success. The safe pattern scans every row for message type E or A; if any exist, the order was not created and ORDER_NUMBER should be ignored even if it came back populated. Type W rows are common and do not block creation - a defaulted profit center, a note about the order's initial status - but interfaces that reject anything non-empty end up failing valid creates and generating false incidents. The opposite mistake is equally damaging: some interfaces only react to a hard dump and never actually parse RETURN content, so a controlling-area mismatch or an unconfigured order type gets logged as a clean success with no order ever created.

BAPI_INTERNALORDER_CREATE still runs on S/4HANA and remains in active use for scripted interfaces and migration loads. Newer integration guidance favors released API services for controlling master data where a suitable one exists for the target release, but there is no blanket confirmation that a replacement API covers every S/4HANA version; check the API catalog for the specific release before treating this BAPI as deprecated. For internal order creation specifically, it remains a commonly used interface rather than something already retired.

This is a developer problem first - commit sequencing and RETURN parsing are code issues, not configuration issues. Functional CO consulting owns the master data rules behind most failures: order type setup, controlling area assignment, cost center validity, and status management profile. A developer escalating a creation failure should bring the full RETURN table content, not a summary of the symptom.

Mirrors the internal order create transaction and its variants. Writes to the shared order master table (AUFK) along with the CO-specific order tables. Sibling BAPIs handle change and list retrieval for the same object, not covered on this page. Postings that later charge against the finished order flow through the standard accounting document and GL posting BAPIs, and related controlling master data - cost centers in particular - is created and read through its own BAPI pair.