BOM import fails with 'Invalid UOM' error in EBOM management after recent UOM master update

PLM Oracle Agile PLM
, , , , , , , ,
1

Our BOM import process through Web Services is consistently failing with an ‘Invalid UOM’ error message. We’re importing engineering BOMs from our ERP system (SAP) into Agile 9.3.5, and approximately 30% of our BOM lines are rejected during validation.

The error log shows:


Error Code: 5502 - Invalid UOM value 'EA' for item P-12345
Validation failed at line 47 of import file
BOM import terminated with 156 errors

We’ve verified that ‘EA’ (Each) exists in our UOM master list and is marked as active. The same UOM values work fine when manually creating BOM lines through JavaClient. This is causing significant ECO delays as we have to manually re-enter rejected BOM data. The BOM import validation seems overly strict compared to manual entry, and we’re wondering if there’s a Web Services cache issue that’s not recognizing recently added UOMs.

2

The UOM values are exact matches, including case. I checked the list IDs and we’re referencing ‘UOM’ which is the standard list. Could this be related to list value API names versus display names? Our import uses the display name ‘EA’ but maybe the API expects something different?

3

You hit the nail on the head. Web Services imports require the API name, not the display name. Go to Admin > Lists and check your UOM list. Click on ‘EA’ and look at the ‘API Name’ field. It’s probably something like ‘EACH’ or ‘EA_UNIT’. Your import XML needs to use that exact API name. JavaClient is more forgiving and translates display names automatically, but the Web Services layer doesn’t do that translation. This catches a lot of people during migrations.

4

Check the exact spelling and case sensitivity of your UOM values. Web Services validation is stricter than JavaClient. Also, verify that the UOM list ID in your import XML matches the list used by the Part class. We had a similar issue where we were referencing the wrong list.

5

I’ve dealt with this exact scenario multiple times during ERP integrations. The solution requires addressing all three focus areas systematically.

UOM Master Maintenance: First, export your complete UOM list with API names. In JavaClient, go to Admin > Data Settings > Lists, select ‘UOM’, and use File > Export. The export includes both display names and API names. Here’s what you’ll see in the export:


Display Name,API Name,Description,Enabled
Each,EACH,Single unit,TRUE
Piece,PC,Individual piece,TRUE

Create a mapping table in your SAP extraction script that converts SAP UOM codes to Agile API names. Common mappings: SAP ‘EA’ → Agile ‘EACH’, SAP ‘PC’ → Agile ‘PC’, SAP ‘M’ → Agile ‘METER’.

BOM Import Validation Rules: The Web Services validation is stricter because it bypasses the UI layer’s automatic lookups. Your import XML must use exact API names in the UOM field:

<BOMLine>
  <ItemNumber>P-12345</ItemNumber>
  <Quantity>10</Quantity>
  <UOM>EACH</UOM>
</BOMLine>

The validation process checks: (1) UOM exists in master list, (2) UOM is enabled, (3) UOM is valid for the item’s class, (4) API name matches exactly. Display name matching only works in JavaClient, not via Web Services.

Web Services Cache Issue: You’re correct about the cache problem. When you add new UOM values through the admin interface, the Web Services layer caches the old list for up to 30 minutes. To force immediate recognition:

  1. After adding new UOM values, clear the Web Services cache: Admin > Server Management > Web Services > Cache Management > Clear List Cache
  2. Alternatively, restart the Agile Application Server (faster than waiting for cache expiration)
  3. For automated imports, add a 5-minute delay after UOM updates before running imports

Implementation Best Practices:

  1. Pre-validation Script: Create a validation script that runs before your BOM import. It should:

    • Query Agile for current UOM list (with API names)
    • Compare SAP UOM values against the list
    • Flag unmapped values before import attempts
    • Auto-create missing UOMs if appropriate

  2. Error Handling: Modify your import to handle validation errors gracefully:

    • Log failed lines with specific UOM mismatches
    • Continue processing valid lines instead of terminating
    • Generate exception report for manual review

  3. Standardization: Work with your ERP team to standardize UOM codes. If possible, align SAP UOM codes with Agile API names to eliminate mapping complexity.

Immediate Fix for Your Current Issue:

Run this analysis on your failed import file:

  1. Extract all unique UOM values from the 156 failed lines
  2. Compare against your exported Agile UOM list (API names)
  3. Update your SAP extraction to use the correct API names
  4. Clear Web Services cache
  5. Re-run the import

For the ‘EA’ specifically, check if your Agile system has it as ‘EACH’ (most common), ‘EA’ (less common), or ‘EA_UNIT’ (rare but possible). The API name is what matters, not the display name.

After implementing these changes, your import success rate should improve to 98%+. The remaining 2% will typically be items with class-specific UOM restrictions that require manual review.

6

Checked for duplicates and found none. Carlos, I think you’re right about the API name issue. I’m updating our SAP extraction script to map to API names. Question: is there a way to export all UOM list values with both display names and API names for reference? Would save time creating the mapping table.

7

Also worth checking: do you have duplicate UOM entries in your list? Sometimes during system upgrades or list imports, duplicate display names get created with different API names. The validation might be finding multiple matches and failing. Run a query on the list values table to check for duplicates.