Logic Shift:
The Death of uom.category in Odoo 19

Your Inventory Module Just Lost Its Safety Net

If you're planning an Odoo 18 → 19 migration and your business relies on custom Units of Measure, you need to read this before you touch that upgrade button.

Odoo 19 has completely removed the uom.category model. Gone. Not deprecated, not hidden behind a feature flag—deleted from the codebase. In its place, a new relative_uom_id field on uom.uom defines conversion relationships directly between units.

Why should you care? Because every custom module that references uom.category—whether it's a custom inventory report, a manufacturing BOM calculator, or a purchase price comparison tool—will break on upgrade. And if the data migration is handled incorrectly, your historical stock valuations, average cost calculations, and FIFO layers can silently corrupt.

We discovered this the hard way during a pilot migration for a multi-warehouse food distributor. Their custom UoM logic touched 14 modules. This article is the playbook we built to fix it.

How Odoo 19 Restructured Units of Measure (And Why It Matters)

In Odoo 18 and earlier, UoM conversions were organized through a category-based hierarchy:

• uom.category grouped related units (e.g., "Weight" containing kg, g, lb, oz)
• Each uom.uom record belonged to exactly one category via category_id
• Within a category, one unit was marked as the "reference" (uom_type = 'reference')
• Conversions between units required them to share the same category_id

The Odoo 19 model eliminates the intermediary table entirely. Instead:

• Each uom.uom record now has a relative_uom_id field pointing directly to the unit it converts from
• The reference unit points to itself (relative_uom_id = self)
• The factor and rounding fields remain, but they now express the ratio relative to relative_uom_id
• Cross-unit conversion is resolved by walking the relative_uom_id chain up to a common ancestor

This is architecturally cleaner. It removes an entire SQL table, simplifies the ORM query path for conversions, and—critically—allows Odoo to support chained multi-step conversions that the flat category model couldn't express without hacks.

Data Migration Logic: Moving Custom UoM Code from Odoo 18 to 19

The official upgrade scripts handle standard uom.uom records. But if you have custom modules that reference uom.category—foreign keys, domain filters, computed fields, or Python logic—you need a manual migration strategy.

Here's the migration pattern we use at Octura Solutions:

from odoo import api, SUPERUSER_ID
import logging

_logger = logging.getLogger(__name__)


def migrate(cr, version):
    """
    Pre-migration: Remap uom.category references
    to relative_uom_id before the table is dropped.
    """
    env = api.Environment(cr, SUPERUSER_ID, {})

    # Step 1: Build a mapping of category → reference UoM
    cr.execute("""
        SELECT id, category_id
        FROM uom_uom
        WHERE uom_type = 'reference'
    """)
    cat_to_ref = {row[1]: row[0] for row in cr.fetchall()}

    # Step 2: For each non-reference UoM, set relative_uom_id
    # to the reference unit of its former category
    cr.execute("""
        SELECT id, category_id
        FROM uom_uom
        WHERE uom_type != 'reference'
    """)
    for uom_id, cat_id in cr.fetchall():
        ref_id = cat_to_ref.get(cat_id)
        if ref_id:
            cr.execute("""
                UPDATE uom_uom
                SET relative_uom_id = %s
                WHERE id = %s
            """, (ref_id, uom_id))
        else:
            _logger.warning(
                "UoM %s: no reference unit found for "
                "category %s — manual fix required",
                uom_id, cat_id,
            )

    # Step 3: Reference units point to themselves
    cr.execute("""
        UPDATE uom_uom
        SET relative_uom_id = id
        WHERE uom_type = 'reference'
    """)

    # Step 4: Remap any custom foreign keys in your modules
    # Example: custom_inventory_report.uom_category_id
    cr.execute("""
        UPDATE custom_inventory_report r
        SET reference_uom_id = u.id
        FROM uom_uom u
        WHERE u.category_id = r.uom_category_id
          AND u.uom_type = 'reference'
    """)

    _logger.info(
        "Pre-migration complete: %d categories remapped",
        len(cat_to_ref),
    )

Key principles behind this script:

Why This Technical Change Saves Your Business Money

For the non-technical reader: here's what the removal of uom.category actually means for your bottom line.

Concrete example: For a mid-size manufacturer with 200 products and 8 custom UoMs, a clean migration costs roughly $3,000–5,000 in consulting time. A botched migration that corrupts stock valuations? We've seen remediation bills exceed $25,000—not counting the business disruption of a frozen warehouse for 2 weeks while data is repaired.