Our middleware system is uploading BOMs to SAP PLM 2021 using BAPI_MATERIAL_BOM_GROUP_CREATE but consistently fails with return message ‘Material XXXXXXXX does not exist or is not activated’.
The materials definitely exist - I can see them in MM03. The BAPI call structure looks correct and works fine in our test system with the same material numbers.
CALL FUNCTION 'BAPI_MATERIAL_BOM_GROUP_CREATE'
EXPORTING
material = '100000123'
plant = '1000'
bom_usage = '1'
IMPORTING
return = ls_return.
* ls_return-type = 'E'
* ls_return-message = 'Material 100000123 does not exist'
We’re calling the BAPI via RFC from our Java middleware. Material master data was extended to PLM views last month. Could this be related to material master extension timing or middleware mapping?
The root cause involves all three areas you mentioned. Let me break down the complete solution:
BAPI Input Structure Validation:
The BAPI_MATERIAL_BOM_GROUP_CREATE has strict input requirements that differ from GUI transaction CS01. Your input structure needs proper formatting:
* Correct BAPI call structure:
ls_header-material = '000000000100000123'. "18 chars with leading zeros
ls_header-plant = '1000'.
ls_header-bom_usage = '1'.
ls_header-alternative = '01'. "Must be 2 chars
ls_header-valid_from = sy-datum. "Required, not optional
The BAPI validates several fields that MM03 doesn’t enforce strictly. Ensure you’re passing:
VALID_FROM date (mandatory, even though GUI defaults it)
ALTERNATIVE as 2-character string (‘01’ not ‘1’)
BOM_USAGE as single character (‘1’ not ‘01’)
BASE_QUAN with proper unit of measure
Material Master Extension Requirements:
When materials are extended to PLM views, there’s a multi-step activation process. Check these aspects:
Run transaction MMPI to verify PLM activation status. Materials must show ‘Active’ status in PLM context.
Check table MARA field VPSTA (maintenance status) - it should be blank or ‘1’, not ‘2’ (blocked) or ‘3’ (marked for deletion).
Verify the material is extended to the correct plant in table MARC. The BAPI validates plant-specific data that might not exist even if the material exists globally.
Check engineering change management status - if the material is in an ECO that hasn’t been released, the BAPI will reject it. Use transaction CC04 to verify.
Middleware Mapping Validation:
Your Java middleware needs robust validation before calling the BAPI:
// Java middleware validation example
String materialPadded = String.format("%018d",
Long.parseLong(materialNumber));
// Validate material exists via BAPI_MATERIAL_GET_DETAIL first
JCoFunction checkMat = destination.getRepository()
.getFunction("BAPI_MATERIAL_GET_DETAIL");
checkMat.getImportParameterList()
.setValue("MATERIAL", materialPadded);
Implement these middleware checks:
Call BAPI_MATERIAL_GET_DETAIL first to validate material existence and retrieve proper internal format
Verify plant assignment by checking PLANTDATA table in the return
Validate material type allows BOM creation (MATL_TYPE field)
Check authorization by calling BAPI_MATERIAL_AUTHORITY first
Additional Validation Steps:
Use transaction SU53 immediately after the failed BAPI call to check for authorization issues
Enable BAPI logging in transaction SLG1 with object ‘BAPI’ and subobject ‘BOM’ to see detailed error messages
Check SM58 for any stuck tRFC calls that might be causing locking issues
Review table STPO to ensure no orphaned BOM items are blocking the creation
The most common issue is the combination of improper material number padding AND missing VALID_FROM date in the BAPI call. After fixing both, add the pre-validation check using BAPI_MATERIAL_GET_DETAIL in your middleware flow to catch these issues before attempting BOM creation.
This draft is based on general SAP PLM knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.
Check if the material is extended to the plant you’re specifying. Use MM02 to verify the material-plant combination exists. The BAPI is very strict about plant assignments. Also verify the material type is allowed for BOM creation - some material types like services or non-valuated materials can’t have BOMs attached to them in certain configurations.
This smells like a leading zeros issue in your middleware mapping. SAP internal material numbers are 18 characters with leading zeros, but external systems often store them without padding. Your middleware might be sending ‘100000123’ when SAP expects ‘000000000100000123’. Check your Java RFC client configuration and ensure you’re using proper material number conversion. The JCo library has specific methods for this - look at the material number conversion exits in your SAP system (transaction OMSL) and implement the same logic in your middleware.
Good point about leading zeros. I added the padding logic but still getting the same error. I noticed in our test system the materials were created more recently. Could there be a timing issue with material master extension? The materials were extended to PLM views only last month. Do I need to wait for some background job to complete or is there a material activation step I’m missing?
Check transaction MMPI to see if the materials are properly activated in PLM. When you extend materials to PLM views, they need to be activated in the PLM context. Also verify table MARA field LVORM (deletion flag) and VPSTA (maintenance status) - if these are set incorrectly, the BAPI will reject the material even though it exists. Run SE16 on table MARA with your material number and check these fields.
I’ve dealt with this exact scenario before. The BAPI has strict authorization and validation checks. Make sure your RFC user has authorization object C_STUE_BER (BOM authorization) with proper activity and plant assignments. Also check if you’re passing the BOM_USAGE parameter correctly - for PLM BOMs, you typically need usage ‘1’ or ‘5’. Verify your middleware is not accidentally passing empty strings or null values for required fields like VALID_FROM date. The BAPI is less forgiving than the GUI transactions.