EBOM import throws duplicate component error during BOM migration despite data cleansing

Migrating engineering BOMs to SAP PLM 2022 and hitting duplicate component errors. We ran data cleansing scripts on source data to remove duplicates before migration, but SAP still rejects BOMs during import.

Error from LSMW log:


BOM 800123: Duplicate component detected
Component M-45678 appears at item 10 and 30
BOM structure validation failed

Our cleansing logic checks for duplicate material numbers within each BOM. The source data shows unique entries, but after import SAP flags duplicates. About 200 BOMs affected out of 3,500 total. This is blocking the entire EBOM migration. Could this be a positioning or counter field issue rather than actual duplicates?

I’ve seen this exact issue. The problem is usually in how the item counter (STLKN) and item node (STPOZ) fields are populated during migration. These internal SAP fields must be unique and sequential. Your LSMW recording might not be capturing these correctly.

SAP allows the same material with different item categories IF there’s a valid business reason (like phantom assemblies). However, your migration is failing because the item numbers (POSNR field) might be conflicting. SAP uses a combination of material number + item category + item number to determine uniqueness. Check your LSMW mapping for the POSNR field - it should increment sequentially and uniquely within each BOM. The error message showing ‘item 10 and 30’ suggests your item numbering has gaps or overlaps that create logical duplicates when SAP validates the BOM structure.

Complete solution addressing all three focus areas:

Data Cleansing Enhancement: Your current cleansing logic only checks material number uniqueness, but SAP’s duplicate detection is more complex. Enhance your pre-migration cleansing to check these key field combinations:

  1. Material Number (IDNRK) + Item Category (POSTP) + Installation Point (EINBP)
  2. Item Number (POSNR) must be unique within BOM
  3. Item Node Number (STPOZ) sequencing

Revised cleansing query:

SELECT BOM_ID, COMPONENT, ITEM_CAT,
  COUNT(*) as OCCURRENCES
FROM LEGACY_BOM_ITEMS
GROUP BY BOM_ID, COMPONENT, ITEM_CAT
HAVING COUNT(*) > 1

This identifies true duplicates from SAP’s perspective. For the 200 affected BOMs, run this analysis to find the root cause patterns.

Duplicate Detection Rules: SAP PLM 2022 uses table STPO (BOM items) with these uniqueness constraints:

  • Primary key: STLTY (BOM category) + STLNR (BOM number) + STLKN (item counter)
  • Business key: Material + Item Category + Installation Point within same parent

Your error ‘Component M-45678 appears at item 10 and 30’ indicates the item numbering (POSNR field) has duplicates or the internal counters aren’t sequential. SAP assigns STLKN automatically during BOM creation, but LSMW direct table updates might bypass this logic.

BOM Structure Validation Implementation: Switch from LSMW direct table load to BAPI_MATERIAL_BOM_GROUP_CREATE. This BAPI handles duplicate detection and item counter assignment automatically:

Key configuration in BAPI call:

  • MATERIAL: Parent material number
  • PLANT: Plant code
  • BOM_USAGE: Usage (1=production, 2=engineering)
  • ITEMS table: Component details with proper sequencing

The BAPI validates:

  1. No duplicate material + item category combinations
  2. Sequential item numbering (10, 20, 30…)
  3. Valid object dependencies
  4. Installation point consistency

For your 200 affected BOMs, implement this remediation process:

Step 1 - Identify Patterns (1 day): Analyze the 200 failures to categorize root causes:

  • True duplicates (same material, same item category) - Requires business decision
  • Item numbering conflicts - Fix item counter assignment
  • Item category mismatches - Standardize L vs N usage

Step 2 - Data Remediation (2 days): For true duplicates where component appears twice with identical attributes:

  • Consolidate into single BOM line
  • Sum quantities if applicable
  • Document business rationale for consolidation

For item numbering issues:

  • Regenerate POSNR field in increments of 10 (10, 20, 30…)
  • Ensure no gaps or overlaps within each BOM
  • Reset counter for each parent material

Step 3 - Migration Approach Change (3 days): Replace LSMW with BAPI-based migration:

  1. Extract cleansed BOM data to flat file
  2. Create ABAP program reading flat file
  3. Call BAPI_MATERIAL_BOM_GROUP_CREATE for each BOM
  4. Capture return messages for error handling
  5. Commit successful BOMs, log failures for review

Sample structure:


LOOP AT lt_bom_data INTO ls_bom.
  CALL FUNCTION 'BAPI_MATERIAL_BOM_GROUP_CREATE'
    EXPORTING
      material = ls_bom-parent
  COMMIT WORK.
ENDLOOP.

Step 4 - Validation (1 day): Post-migration validation checks:

  • Compare BOM item counts: Legacy vs SAP (transaction CS03)
  • Verify no duplicate components in SAP BOMs
  • Check item numbering is sequential
  • Validate BOM explosion works correctly

The BAPI approach adds 20% to migration time but eliminates duplicate errors through built-in validation. For 3,500 BOMs with 200 failures (5.7% error rate), the BAPI conversion prevents rework and ensures clean BOM structure in SAP PLM 2022.

Critical success factor: Enhanced data cleansing BEFORE migration using SAP’s duplicate detection rules, not just material number uniqueness. This reduces the failure rate from 5.7% to under 1%.

Interesting. I checked and found that some components DO appear multiple times with different item categories - one as ‘L’ (stock item) and another as ‘N’ (non-stock). Is this allowed in SAP or should we consolidate?

Run this validation query on your source data before migration: SELECT BOM_NUMBER, COMPONENT, ITEM_CATEGORY, COUNT() FROM LEGACY_BOM GROUP BY BOM_NUMBER, COMPONENT, ITEM_CATEGORY HAVING COUNT() > 1. This will show you the true duplicates from SAP’s perspective.

SAP considers components duplicate based on multiple fields, not just material number. Check if your BOMs have the same component with different item categories (L vs N) or different installation points. That would create ‘logical duplicates’ that SAP rejects even though material numbers differ.

Your data cleansing logic needs to match SAP’s duplicate detection rules. SAP checks component + item category + object dependencies together, not just material number. Enhance your cleansing script to include these additional fields in the uniqueness check.