Warehouse transfer API integration fails due to invalid unit of measure mapping

ERP Infor CloudSuite
, , , , , , , ,
1

Our custom warehouse management integration is failing when creating transfer orders via the ION API. We’re getting consistent validation errors related to unit of measure mismatches between the source and destination warehouses.

The API response shows:

{
  "error": "Invalid UOM",
  "detail": "Unit 'EA' not valid for item IM-4782"
}

What’s strange is that ‘EA’ (Each) is defined in our UOM master data and works fine for sales orders and purchase orders. The items transfer correctly through the UI, but the API rejects the same payload. We’ve verified master data alignment across warehouses, but something in the payload validation logic seems stricter than the UI validation. Running ICS 2021. Any insights on UOM mapping requirements specific to transfer APIs?

2

The transfer API has stricter UOM validation than the UI because it doesn’t apply the same default conversion rules. Check if your item master has the UOM explicitly assigned at the warehouse level, not just globally. The API validates against warehouse-specific item configurations, while the UI falls back to global defaults.

3

I’ll walk you through the complete solution based on what we’ve identified. The problem has three layers that all need addressing.

Layer 1: UOM Mapping Table Your warehouse-specific UOM mappings are incomplete. The transfer API validates against ITMWHSUOM, which stores item-warehouse-UOM combinations. Even though ‘EA’ exists globally, each warehouse needs explicit item-UOM associations for transfer validation.

To fix this, use the bulk approach mentioned earlier. Export current ITMWHSUOM data, identify missing entries for your 3,000 items, and prepare an import file with these required fields:


ITEM_NUMBER,WAREHOUSE_ID,UOM_CODE,CONVERSION_FACTOR,BASE_UOM
IM-4782,WH01,EA,1.000,EA
IM-4782,WH02,EA,1.000,EA

Import through ION Data Lake using the Item Warehouse UOM template.

Layer 2: Master Data Alignment Verify that your base UOM in the item master matches what you’re using in transfers. The API performs a two-step validation: first checks if the UOM exists in ITMWHSUOM, then validates the conversion path from transaction UOM to base UOM. Mismatches here cause the “Invalid UOM” error even when the mapping exists.

In Item Master Maintenance, confirm the base UOM field for affected items. If items show different base UOMs across warehouses, standardize them before proceeding.

Layer 3: Payload Validation Your API payload needs both transaction and base UOM for proper validation. Update your integration code:

transferPayload.put("transactionUOM", "EA");
transferPayload.put("baseUOM", "EA");
transferPayload.put("conversionFactor", 1.0);

The API uses this to validate the conversion path exists in the mapping table.

Testing Strategy After implementing these fixes, test with items that previously failed. Monitor the API response - if you still see UOM errors, check the ION message logs for the specific validation rule triggering. Common remaining issues include case sensitivity in UOM codes (EA vs ea) or missing conversion factors in the mapping table.

The UI works because it applies default conversion rules and auto-populates missing warehouse mappings on-the-fly. The API requires explicit configurations to ensure data integrity across automated integrations. This design prevents invalid UOM combinations from entering the system through API calls that bypass UI validation.

4

Also verify your payload includes the base UOM from the item master. The API expects both the transaction UOM and base UOM for conversion validation. If you’re only sending the transaction UOM, it can’t validate the conversion path properly.