FBDI inventory item load fails due to UOM mismatch between legacy and Oracle standards

ERP Oracle Fusion Cloud
, , , , , , , ,
1

We’re migrating inventory items from our legacy ERP to Oracle Fusion Cloud 22D using FBDI templates. The load consistently fails with validation errors related to Unit of Measure (UOM) codes. Our legacy system uses custom UOM codes like ‘BX’ for boxes and ‘CS’ for cases, but Oracle’s FBDI template rejects these during import.

The error log shows:


Error: Invalid UOM Code 'BX' for item I-12345
Valid values must exist in FND_UNITS_OF_MEASURE

We’ve checked the FBDI template structure and confirmed our item master data includes the UOM field correctly populated. The issue seems to be with UOM code mapping between systems. We have about 15,000 items using 12 different custom UOM codes that need conversion.

Has anyone dealt with UOM standardization during FBDI inventory loads? Do we need to configure Oracle’s UOM setup before the migration, or is there a mapping capability within the FBDI process itself?

system 2

Let me provide you with a complete solution approach that addresses all three key areas:

1. FBDI Template Structure: Your FBDI template must include these critical columns for UOM handling:

  • ITEM_NUMBER (your item identifier)
  • ORGANIZATION_CODE (inventory org)
  • PRIMARY_UOM_CODE (must be valid Oracle UOM)
  • TEMPLATE_NAME (use the standard Oracle template)

Ensure your CSV uses the exact column headers from Oracle’s ItemImport.xlsm template for 22D.

2. UOM Code Mapping Process: Create a mapping table in your ETL tool with this structure:


Legacy_UOM | Oracle_UOM | Conversion_Factor
BX         | Box        | 1
CS         | Case       | 1
PL         | Pallet     | 1

In your data extraction query, join this mapping table and replace legacy codes:

SELECT item_number, org_code,
       m.Oracle_UOM as PRIMARY_UOM_CODE
FROM legacy_items li
JOIN uom_mapping m ON li.uom_code = m.Legacy_UOM

3. Oracle UOM Configuration Steps:

Before running your FBDI load, complete these setup tasks in Oracle Fusion:

a) Verify Standard UOMs Exist:

Navigate to: Setup and Maintenance > Search: Manage Units of Measure

Confirm Oracle has Box, Case, Pallet, or whatever you’re mapping to

If missing, create them with appropriate UOM class (Quantity)

b) Set Up UOM Conversions:

Navigate to: Setup and Maintenance > Search: Manage Unit of Measure Conversions

Define conversions between your UOMs:

  • 1 Case = 12 Each (if Case contains 12 individual items)
  • 1 Box = 6 Each (if Box contains 6 items)
  • 1 Pallet = 48 Case (if Pallet holds 48 cases)

Set the Base UOM for the Quantity class (typically ‘Each’)

All conversions must reference back to this base UOM

c) Validate UOM Classes:

Ensure all your UOMs belong to the correct UOM class

Conversions only work within the same class

Most inventory UOMs should be in the ‘Quantity’ class

Critical Validation Steps:

  1. Test with a small batch first (50-100 items)
  2. Review the FBDI import log for any UOM-related warnings
  3. After successful import, verify UOM conversions work by creating a test transaction
  4. Check that inventory balances display correctly in different UOMs

Common Gotchas:

  • Oracle is case-sensitive for UOM codes - ‘Box’ ≠ ‘box’
  • Base UOM conversions must be defined as exact decimals (use 0.0833 not 1/12)
  • If you have inter-class conversions (Quantity to Weight), you need item-specific conversion rules
  • FBDI won’t create UOMs or conversions - all setup must be done beforehand

Once your UOM mapping is in your ETL process and Oracle’s UOM configuration is complete, your FBDI loads should process without UOM validation errors. The key is handling the transformation upstream so the FBDI file contains only valid Oracle UOM codes.

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

3

The UOM codes in Oracle Fusion are standardized and must exist in the FND_UNITS_OF_MEASURE table before you can reference them in FBDI loads. Your legacy codes won’t work directly. You need to either create custom UOM codes in Oracle that match your legacy codes, or map your legacy codes to Oracle’s standard UOMs during the ETL process. I’d recommend the mapping approach to maintain Oracle’s standard UOM library.

4

We faced this exact issue last year. You have two options: First, you can set up custom UOM codes in Oracle Fusion through the Manage Units of Measure task in Setup and Maintenance. Navigate to Supply Chain Execution > Product Management > Units of Measure. However, this can create maintenance overhead. Second option is to create a mapping table in your ETL tool that converts legacy UOM codes to Oracle standard codes before generating the FBDI file. For example, map ‘BX’ to ‘Box’ and ‘CS’ to ‘Case’ if those exist in Oracle’s standard library. Check what’s available in your instance first using the Manage Units of Measure screen. The mapping approach is cleaner long-term and you avoid custom configurations that might complicate future updates.

5

Thanks for the quick responses. I checked the Manage Units of Measure and found that Oracle does have ‘Box’ and ‘Case’ as standard UOMs. So mapping seems like the right approach. My question now is - should this mapping happen in the FBDI template itself, or do I need to transform the data before creating the CSV file? Also, what about UOM conversions between units? Our legacy system has conversion rates defined between our custom UOMs.

6

The mapping must happen BEFORE you generate the FBDI CSV file. The FBDI template expects valid Oracle UOM codes in the UOM_CODE column - it doesn’t have built-in mapping functionality. Transform your data during extraction from the legacy system. For UOM conversions, you’ll need to set those up separately in Oracle using the Manage Unit of Measure Conversions task. Define the conversion rates between your mapped UOMs (e.g., 1 Case = 12 Each). These conversions are critical for inventory transactions to work correctly across different UOMs.

7

One thing to watch out for - make sure your UOM class assignments are correct too. Oracle groups UOMs into classes (Quantity, Weight, Volume, etc.) and conversions only work within the same class. When you’re setting up your UOM conversions in Oracle, verify that the base UOM for each class matches your business needs. Also, in your FBDI template, you might need to include both PRIMARY_UOM_CODE and SECONDARY_UOM_CODE columns depending on whether you’re using dual UOM functionality. Review the Item Import FBDI template guide specific to 22D for the complete column requirements.

robert_user 8

Tested this on Oracle Fusion 22D FBDI ItemImport.xlsm and mapping legacy UOM codes to valid Oracle UOM_CODE values in the ETL transformation resolved all inventory item load failures.

9

This is really helpful. Just to confirm my understanding - I need to create a mapping table, transform the data during extraction, and set up UOM conversions in Oracle before running the FBDI load. Are there any gotchas I should watch for during the actual conversion setup?