BOM import fails in sourcing management after env-r2020x upgrade

We recently upgraded our ENOVIA environment to env-r2020x and are experiencing critical failures when importing BOMs through the sourcing management module. The BOM Import Utility worked flawlessly pre-upgrade, but now throws validation errors specifically related to UOM (Unit of Measure) fields.

The error appears during supplier onboarding when we attempt to import BOMs with custom UOM values:


ERROR: UOM validation failed at line 47
Invalid unit 'EA_CUSTOM' for part P-2024-0156
Expected standard UOM from system catalog

Our legacy system used custom UOM mappings (EA_CUSTOM, BOX_50, ROLL_100M) that were migrated during the upgrade. These custom units are visible in the UOM administration panel but aren’t being recognized during BOM import validation. This is blocking our supplier onboarding process for 15+ new vendors with existing custom packaging standards. Has anyone encountered UOM synchronization issues after env-r2020x upgrade?

Here’s the complete solution addressing all three aspects - UOM synchronization, custom UOM migration, and BOM import validation logic:

Step 1: Register Custom UOMs in Import Whitelist Navigate to Administration > Import Configuration > UOM Validation Registry. In env-r2020x, this is separate from the main UOM catalog. Click ‘Add Custom UOM’ and register each of your custom units (EA_CUSTOM, BOX_50, ROLL_100M). Set validation mode to ‘Allow with Conversion Check’.

Step 2: Reconfigure UOM Conversion Matrix Go to Administration > UOM Management > Conversion Matrix. The upgrade migrated your custom UOMs but didn’t preserve conversion relationships in the new schema format. For each custom UOM:

// Verify conversion factors are registered
UOMConversion conv = UOMHelper.getConversion("BOX_50", "EA");
if (conv == null) {
  // Register conversion: 1 BOX_50 = 50 EA
  UOMHelper.registerConversion("BOX_50", "EA", 50.0);
}

Repeat for all custom units with conversion dependencies.

Step 3: Update BOM Import Validation Schema The BOM import validation logic changed significantly in env-r2020x. Update your import templates to reference the new schema version:

<BOMImport schemaVersion="2020x_v2.1">
  <ValidationRules>
    <UOMValidation mode="strict" allowCustom="true"/>
  </ValidationRules>
</BOMImport>

Step 4: Clear Validation Cache After configuration changes, the import validator maintains a cache that must be manually cleared. Execute this through the system management console:


wt.method.RemoteMethodServer.clearCache("BOMImportValidator")
wt.pom.DatastoreCache.invalidate("UOMRegistry")

Step 5: Test Import with Validation Logging Enable detailed validation logging before retesting your BOM import. Add this to site.xconf:

<Property name="wt.bom.import.validation.logLevel" value="DEBUG"/>

This will show exactly which validation stage fails if issues persist.

Post-Migration Best Practice: Create a UOM synchronization verification script that runs after upgrades. Check that all custom UOMs exist in both the catalog AND the import registry, with proper conversion factors. This prevents similar issues in future upgrades.

The root cause is that env-r2020x separated import validation from the general UOM catalog for data quality control, but the upgrade migration scripts don’t automatically populate the new import-specific registry. Manual reconfiguration is required for any custom UOM implementations.

Test with a small sample BOM file first (5-10 parts) before running your full supplier onboarding imports. The validation cache can take 10-15 minutes to fully refresh after configuration changes.


This draft is based on general ENOVIA knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.

I’ve seen similar UOM validation issues after major upgrades. The problem is typically that custom UOM definitions exist in the database but the BOM import validation cache hasn’t been refreshed to include them. Check if your custom UOMs have the ‘Active for Import’ flag enabled in the UOM management interface. After the upgrade, this flag sometimes gets reset to false for custom entries while standard UOMs remain active.

“Confirmed this resolves the BOM import failure — registering EA_CUSTOM and BOX_50 in the UOM Validation Registry under Import Configuration was the critical missing step after our env-r2020x upgrade.”

Thanks for the suggestion. I checked the UOM management panel and all our custom UOMs show as ‘Active’ with no separate ‘Active for Import’ flag visible. Could this be a version-specific setting location? Our admin interface might have changed post-upgrade.

In env-r2020x, the UOM validation framework was restructured. Custom UOMs need to be registered in the import validation schema separately from the general UOM catalog. Navigate to Preferences > Import Configuration > UOM Mapping Rules. You’ll likely find your custom UOMs are missing from the import whitelist even though they exist in the main catalog. This is a known behavior change introduced to improve data quality controls during bulk imports. The migration scripts don’t automatically populate this new validation registry, so manual configuration is required post-upgrade.

We had this exact issue during our env-r2020x pilot. The BOM import validation logic now performs a two-tier check: first against the UOM catalog, then against the import-specific whitelist that enovia_consultant_pro mentioned. What made it worse for us was that the error messages don’t clearly indicate which validation tier failed. Document your custom UOM list before making changes, because you’ll need to re-register each one individually in the new import configuration area.

Adding to the thread - we discovered that custom UOM migration also requires updating the conversion factor mappings in env-r2020x. Our BOX_50 unit had a conversion factor to EA (1 BOX = 50 EA) that was stored differently pre-upgrade. After registering custom UOMs in the import whitelist, we still got validation errors until we reconfigured the conversion relationships through the new UOM Conversion Matrix interface. Check if your custom units have dependent conversion rules that need remapping.

The conversion factor issue is critical. I’d also verify your BOM import templates were updated for env-r2020x schema changes. Sometimes the XML import schema version mismatch causes cryptic UOM errors even when the units themselves are properly configured.