BAPI_ROUTING_CREATE — BAPI_ROUTING_CREATE for Routing Master Data
BAPI_ROUTING_CREATE creates a production routing, the same object maintained through transaction CA01, including header, sequences, operations, material assignment and component assignment. It does not commit its own work, so a missing BAPI_TRANSACTION_COMMIT call leaves the routing rolled back even though the BAPI reports success. The RETURN table must be parsed for message type, not just checked for emptiness.
This page covers what BAPI_ROUTING_CREATE actually builds, which parameters carry the header, operations and material linkage, and why routings appear to succeed in the interface but never reach the database. It concentrates on the RETURN table parsing mistakes and commit omissions that cause silent failures in integration scenarios.
Published 16 Sept 2026· 1,114 words
What it does
BAPI_ROUTING_CREATE creates a group routing, the task list object normally maintained through transaction CA01 (create routing) or CA02 (change). It writes the routing group and group counter, the header data (plant, usage, status, planner group), one or more sequences (standard, parallel, alternative), the operations within each sequence, and the assignment of the routing to a material so it can be used for order scheduling and costing. It is a master data creation BAPI, not a change BAPI: an existing routing group with the same key produces an error rather than an update. It is typically called from custom load programs, migration tooling, or PP-to-PP interfaces that need to generate routings from an external process planning system.
Important parameters
- TASK_LIST_HEADER - the routing header: group, group counter, plant, task list usage, status, deletion indicator, planner group, and validity dates. If group and counter are left blank the system generates them internally.
- SEQUENCE - the sequence table describing standard, alternative and parallel sequences within the routing, including the sequence category and the node numbers that link sequences to operations.
- OPERATION - the operation and suboperation table: control key, work center, plant, base quantity, standard values, and the operation number used by downstream tables to attach components or PRTs.
- MATERIAL_ASSIGNMENT - links the routing group and counter to a material and plant, which is what makes the routing usable for a production order or a rate routing on that material.
- COMPONENT_ASSIGNMENT - assigns BOM components to specific operations, controlling backflush and component allocation at the operation level rather than the order header level.
- PRT_ASSIGNMENT - assigns production resources and tools to operations.
- RETURN - standard BAPI return table of message lines with type, id, number and message text.
Commit behaviour
BAPI_ROUTING_CREATE does not commit. It builds the routing objects in the update task and returns before the database write is finalized. A separate call to BAPI_TRANSACTION_COMMIT is required to make the change durable; without it, the routing is rolled back at the end of the logical unit of work as though nothing happened. The dangerous part is that the BAPI itself can return a clean RETURN table with no error messages, so the caller has every reason to believe the routing was created. It is only on the next attempt to read or use that routing, sometimes in a completely separate program or the next day's batch run, that its absence is discovered.
Return handling
RETURN is a table, and an empty table is the only completely safe signal of success. The recurring bug is checking sy-subrc after the function module call, which for an RFC-enabled function module is almost always zero regardless of application-level failure, or checking only whether RETURN[1] exists rather than scanning every line for type E or A. A routing create can fail partway through: the header writes but an operation is rejected because its work center does not exist in the target plant, and the resulting RETURN table mixes a success message about the header with an error message about the operation, with no single flag summarizing overall success. Correct handling loops the full table, treats any E or A type as a hard failure, and does not call the commit if one is found. Where the group and counter were left blank for the system to generate, they typically come back embedded in a success message's variables rather than as a clean output field, so interfaces that only read TASK_LIST_HEADER back out lose the generated key and later fail to attach materials or components to the routing they just created.
ECC vs S/4HANA
BAPI_ROUTING_CREATE continues to function on S/4HANA and is still the standard interface for programmatic routing creation; there is no widely adopted released public API that fully replaces it for this specific object. Mass data migration during a conversion project typically goes through the migration cockpit's own routing object rather than through this BAPI directly, but custom integrations and legacy interfaces built around it keep working unchanged. No version-specific behavior change to the parameter interface itself should be assumed without checking the target system directly.
Common pitfalls
- Commit omitted: BAPI reports success, routing visible nowhere in CA03 afterward, because the LUW rolled back.
- Generated group and counter not captured from the success message, so a following call that assigns material or components uses a blank or wrong key and fails or attaches to the wrong routing.
- Work center referenced in OPERATION does not exist in the routing's plant: the operation is rejected but the header and other operations still commit, leaving a partial routing that looks complete until someone opens it.
- Sequence and operation node numbers out of sync between the SEQUENCE and OPERATION tables, producing operations that exist in the database but do not display in the expected sequence order in CA03.
- MATERIAL_ASSIGNMENT populated with a plant or material that does not match the header plant, resulting in a routing that exists but cannot be selected for order creation on the intended material.
- Duplicate group key from a retry after a network timeout: the first call actually succeeded and committed, the retry fails with a duplicate-key message that is easy to misread as the original attempt failing.
Whose problem this is
Interface development owns the commit call and RETURN parsing; a missing commit or a swallowed error message in RETURN is a development defect regardless of what the functional team configured. Functional PP owns whether the routing content is correct: right work centers, right control keys, right sequence structure. When a routing appears missing, the first useful evidence is the full RETURN table from the failing call plus the group and counter the interface believed it created, not just a screenshot of CA03 showing nothing.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-bapis/bapi-routing-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.