Changement de logique :
La fin de uom.category dans Odoo 19

Votre module inventaire vient de perdre son filet de sécurité

Si vous planifiez une migration Odoo 18 → 19 et que votre entreprise utilise des Unités de Mesure personnalisées, lisez cet article avant de lancer la mise à jour.

Odoo 19 a complètement supprimé le modèle uom.category. Pas déprécié, pas masqué derrière un paramètre — supprimé du code source. À sa place, un nouveau champ relative_uom_id sur uom.uom définit les relations de conversion directement entre unités.

Pourquoi est-ce important ? Parce que chaque module personnalisé qui référence uom.category — qu'il s'agisse d'un rapport d'inventaire, d'un calculateur de nomenclature (BOM), ou d'un outil de comparaison de prix d'achat — va planter lors de la mise à jour. Et si la migration des données est mal gérée, vos valorisations de stock historiques, vos calculs de coût moyen et vos couches FIFO peuvent se corrompre silencieusement.

Nous l'avons découvert lors d'une migration pilote pour un distributeur alimentaire multi-entrepôts. Leur logique UdM personnalisée touchait 14 modules. Cet article est le guide que nous avons construit pour résoudre le problème.

Comment Odoo 19 a restructuré les Unités de Mesure (et pourquoi c'est important)

Dans Odoo 18 et versions antérieures, les conversions d'UdM étaient organisées via une hiérarchie basée sur les catégories :

• uom.category regroupait les unités liées (ex. : « Poids » contenant kg, g, lb, oz)
• Chaque enregistrement uom.uom appartenait à exactement une catégorie via category_id
• Au sein d'une catégorie, une unité était marquée comme « référence » (uom_type = 'reference')
• Les conversions entre unités nécessitaient le même category_id

Le modèle Odoo 19 élimine complètement la table intermédiaire. À la place :

• Chaque enregistrement uom.uom possède désormais un champ relative_uom_id pointant directement vers l'unité depuis laquelle il se convertit
• L'unité de référence pointe vers elle-même (relative_uom_id = self)
• Les champs factor et rounding subsistent, mais expriment le ratio par rapport à relative_uom_id
• La conversion inter-unités est résolue en remontant la chaîne relative_uom_id jusqu'à un ancêtre commun

C'est architecturalement plus propre. Cela supprime une table SQL entière, simplifie le chemin de requête ORM pour les conversions et — point crucial — permet à Odoo de prendre en charge nativement les conversions chaînées multi-étapes que le modèle plat par catégorie ne pouvait pas exprimer sans bricolage.

Logique de migration des données : transférer le code UdM d'Odoo 18 vers 19

Les scripts de mise à jour officiels gèrent les enregistrements uom.uom standard. Mais si vous avez des modules personnalisés qui référencent uom.category — clés étrangères, filtres de domaine, champs calculés ou logique Python — vous avez besoin d'une stratégie de migration manuelle.

Voici le modèle de migration que nous utilisons chez Octura Solutions :

from odoo import api, SUPERUSER_ID
import logging

_logger = logging.getLogger(__name__)


def migrate(cr, version):
    """
    Pré-migration : Remapper les références uom.category
    vers relative_uom_id avant la suppression de la table.
    """
    env = api.Environment(cr, SUPERUSER_ID, {})

    # Étape 1 : Construire un mapping catégorie → UdM de référence
    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()}

    # Étape 2 : Pour chaque UdM non-référence, définir relative_uom_id
    # vers l'unité de référence de son ancienne catégorie
    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(
                "UdM %s : aucune unité de référence trouvée "
                "pour la catégorie %s — correction manuelle requise",
                uom_id, cat_id,
            )

    # Étape 3 : Les unités de référence pointent vers elles-mêmes
    cr.execute("""
        UPDATE uom_uom
        SET relative_uom_id = id
        WHERE uom_type = 'reference'
    """)

    # Étape 4 : Remapper les clés étrangères personnalisées
    # Exemple : 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(
        "Pré-migration terminée : %d catégories remappées",
        len(cat_to_ref),
    )

Principes clés derrière ce script :

Pourquoi ce changement technique fait économiser de l'argent à votre entreprise

Pour le lecteur non-technique : voici ce que la suppression de uom.category signifie concrètement pour votre résultat net.

Exemple concret : Pour un fabricant de taille moyenne avec 200 produits et 8 UdM personnalisées, une migration propre coûte environ 3 000 à 5 000 € en temps de conseil. Une migration bâclée qui corrompt les valorisations de stock ? Nous avons vu des factures de remédiation dépasser 25 000 € — sans compter la perturbation métier d'un entrepôt gelé pendant 2 semaines le temps de réparer les données.