Odoo 19 : fiabiliser dates dynamiques et rapports pivots

Le changelog officiel de l’ORM Odoo 19 signale deux évolutions discrètes mais structurantes : les dates dynamiques dans les domaines et la prise en charge de GROUPING SETS pour les vues pivots. Elles concernent directement les filtres temporels, tableaux de bord, automatisations et rapports spécifiques utilisés par la finance, les ventes, le stock ou les opérations.

Ce ne sont pas des promesses de nouveaux indicateurs prêts à l’emploi. Ce sont des capacités de framework. Elles n’améliorent un reporting que si l’intégrateur les utilise correctement et si la migration vérifie que les règles existantes conservent le même sens.

Dates dynamiques : exprimer une période qui avance

Odoo 19 permet d’exprimer des dates relatives dans un domaine avec un langage dédié. Le changement officiel illustre notamment « maintenant moins cinq minutes » et la période comprise entre le lundi précédent et le lundi courant. Le sélecteur de domaine peut ainsi employer l’opérateur de plage sans dépendre des anciennes constructions complexes autour de context_today et relativedelta.

L’intérêt opérationnel est concret : une liste « commandes en retard », une relance « factures échues depuis sept jours » ou un contrôle « interventions de la semaine précédente » doit continuer à avancer avec le calendrier. Une date absolue enregistrée par erreur produit un filtre qui vieillit silencieusement ; une expression dynamique recalcule la borne au moment de l’exécution.

Fuseaux horaires et frontières de période restent des sujets métier

Une syntaxe plus simple ne décide pas si « aujourd’hui » suit l’utilisateur, la société ou le serveur. Elle ne définit pas non plus la semaine fiscale, l’heure de clôture d’un entrepôt ou le traitement d’une activité nocturne. Les champs Date et Datetime n’ont pas la même granularité.

Pour une entreprise belge et une filiale française partageant la même base, l’heure légale est généralement alignée, mais les calendriers, jours ouvrés et procédures de clôture peuvent différer. Un groupe plus international doit tester les changements d’heure et les utilisateurs situés dans d’autres fuseaux. Le besoin métier doit donc être écrit avant le domaine technique.

GROUPING SETS : moins de requêtes, pas moins de gouvernance

GROUPING SETS est une fonction SQL qui calcule plusieurs niveaux d’agrégation dans une même requête. Son support par l’ORM Odoo 19 sert les vues pivots qui demandent, par exemple, des totaux par société, équipe et période ainsi que leurs sous-totaux.

Le gain attendu se situe dans la construction et l’exécution des agrégations, mais la présence de la fonction ne garantit pas qu’un tableau de bord complexe devienne automatiquement rapide. Volumétrie, champs calculés, règles d’accès, index, mesures et personnalisations continuent de déterminer la performance. Il faut mesurer avec des données proches de la production.

Ce qu’une migration Odoo 19 doit inventorier

Les domaines ne vivent pas seulement dans les vues. On les retrouve dans les filtres favoris et partagés, actions, règles d’automatisation, champs calculés, règles d’enregistrement, rapports, modules spécifiques et appels d’intégration. Une migration qui ne teste que l’ouverture des menus peut manquer une borne de date devenue fausse ou une automatisation exécutée sur un périmètre différent.

• Recenser les filtres temporels partagés et les recherches enregistrées critiques.
• Identifier les domaines qui utilisent context_today, relativedelta ou du code évalué.
• Documenter le sens métier de « jour », « semaine », « mois » et « retard ».
• Comparer résultats et volumes avant et après migration sur des dates frontières.
• Tester chaque automatisation avec une horloge et un fuseau maîtrisés.
• Mesurer les pivots lourds avec les mêmes dimensions, droits et volumes.

Configuration standard ou développement spécifique ?

Un filtre utilisateur simple peut souvent rester une configuration standard. Une règle qui déclenche une action sensible, combine plusieurs calendriers ou alimente une interface externe doit être versionnée, testée et supervisée comme du code. De même, un pivot standard peut suffire à l’analyse exploratoire ; un état financier contractuel exige une définition stable des mesures, périmètres et arrondis.

Il faut éviter de présenter ces évolutions comme une raison suffisante de migrer. Elles deviennent utiles lorsqu’un projet souffre de domaines temporels fragiles ou de rapports pivots coûteux. Elles s’inscrivent alors dans une stratégie de migration Odoo, un audit des personnalisations et une démarche de pilotage par des KPI fiables.

Analyse Underside : tester le sens avant la vitesse

Notre recommandation est de créer un petit catalogue de scénarios datés : veille de fin de mois, premier jour du mois, changement d’heure, clôture hebdomadaire et exercice comptable. Pour chacun, l’équipe décrit les enregistrements attendus. Ce jeu devient un test de non-régression pour les domaines, automatisations et rapports.

Pour les pivots, on mesure séparément exactitude et performance. Les totaux doivent d’abord correspondre aux écritures sources et aux droits de l’utilisateur ; le temps de réponse vient ensuite. Cette discipline évite d’accélérer un rapport dont le périmètre est faux ou de remplacer un développement sans preuve fonctionnelle.

Sources officielles

• Odoo 19 — changelog de l’ORM.
• Odoo — implémentation des dates dynamiques dans les domaines.
• Odoo — prise en charge de GROUPING SETS pour les pivots.