BAPI_MATERIAL_BOM_GROUP_CREATE — Create a Material BOM Group via BAPI
BAPI_MATERIAL_BOM_GROUP_CREATE creates a new material BOM group with its first alternative and component items, mirroring the initial screen and item entry of transaction CS01. It does not commit automatically, so BAPI_TRANSACTION_COMMIT must follow, and the RETURN table must be checked line by line because item-level errors can sit underneath a header line that looks like success.
This page covers what BAPI_MATERIAL_BOM_GROUP_CREATE does when creating material BOMs from an interface or migration program, its key parameters, and the return-table and commit mistakes that cause BOMs to look created but not persist, or to persist with silently dropped components. It also flags the plant, usage, and duplicate-group conditions that most often break the call in real projects.
Published 16 Sept 2026· 1,064 words
What it does
BAPI_MATERIAL_BOM_GROUP_CREATE creates a new material BOM group for a given material, plant, and BOM usage, along with the first alternative and its component items. It is the API equivalent of transaction CS01, Create Material BOM. The object it acts on is the BOM header (the group and alternative) plus the item lines that define components, quantities, and item categories. It is typically called from data migration programs, from custom master data creation flows that need to generate BOMs alongside materials, or from integration layers that push engineering data from a PLM system into SAP. It belongs to the PP-BD-BOM master data domain and sits alongside the sibling BAPIs used to change and read the same object.
Important parameters
Confirmed parameters, described in words where the exact structure name is not certain.
- MATERIAL - the material number the BOM group is being created for, same field as the CS01 initial screen
- PLANT - the plant assigning the BOM, drives which plant-specific checks (unit, procurement) are applied to items
- BOM_USAGE - the usage indicator, e.g. production or engineering, that determines which item categories and checks apply
- VALID_FROM - the validity start date of the alternative being created
- ITEM - the table of BOM item lines, carrying component material, item category, component quantity and unit for each line
- RETURN - the standard return table carrying one line per message with type, id, number, and message text
- BOM_GROUP - export parameter returning the generated BOM group number and alternative number once the call succeeds
Commit behaviour
The BAPI does not commit the database change itself. A successful call populates BOM_GROUP and returns success messages, but the group and its items exist only in the internal session until BAPI_TRANSACTION_COMMIT is called explicitly. If the caller forgets the commit, the program appears to finish cleanly, the BOM group number is returned as if real, and any subsequent read of that number in the same or a later session fails to find it because the change was rolled back at the end of the logical unit of work. This is the single most common reason a migration batch reports full success but leaves no BOMs behind in the target system.
Return handling
RETURN is a table, not a single flag, and it must be scanned for every line with TYPE equal to E or A, not just checked for emptiness. A common interface bug is testing only whether RETURN is initial and treating that as success; a warning line (TYPE W) about a duplicate BOM usage, an inconsistent unit of measure, or a component not extended to the plant can sit alongside an apparently clean header message. Another recurring bug is reading only the first line of RETURN and ignoring later lines that report item-level rejection, which leaves the BOM group created with fewer components than the source data intended. Interfaces built to log only ID and NUMBER without the MESSAGE text also make root-cause analysis slower, because the same ID and NUMBER combination can mean different things depending on which item line triggered it. The safe pattern is to log the full RETURN table, fail the transaction on any E or A line, and only commit when the table contains no error-level entries.
ECC vs S/4HANA
This BAPI remains valid on S/4HANA and is still the interface commonly used for programmatic material BOM creation; no separately released replacement API has superseded it. Fiori apps for BOM maintenance and the newer OData-based services for engineering BOMs sit on top of the same underlying BOM maintenance logic rather than replacing this BAPI outright. Projects building new interfaces should still confirm current recommended integration options for the specific S/4HANA release in use, but this BAPI has not been formally deprecated.
Common pitfalls
Failures that show up repeatedly in interface and migration work built on this BAPI.
- BOM usage passed does not match what is configured as valid for the material type, rejected at header level before any item is processed
- component material exists but is not extended to the plant given in the call, rejected at item level while the header line still shows success
- a BOM group for the same material, plant, and usage combination already exists, so the call silently creates a new alternative under the existing group instead of the group the caller expected
- component base unit of measure does not match the unit passed on the item line, producing a conversion error that is easy to miss if only the header return is checked
- engineering change management active on the BOM object type without a change number supplied, producing a rejection that reads like a generic authorization or lock error
- calling the BAPI in a loop without an explicit commit between iterations, so an early failure rolls back BOM groups that were reported as created in the same LUW
Whose problem this is
Functional PP or CS master data ownership covers BOM usage configuration, item category rules, and engineering change management setup. Development ownership covers the interface logic: whether RETURN is checked line by line, whether commit is called, and whether the caller retries safely on partial failure. The evidence functional needs from development is the full RETURN table content and the commit call sequence; the evidence development needs from functional is confirmation of which BOM usage and change management setup is expected for the material in question.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-bapis/bapi-material-bom-group-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.