Champs calculés dans Dolibarr

Un champ calculé est un attribut supplémentaire dont la valeur n’est pas saisie : elle est calculée par une formule. Un prix TTC, un nombre de cartons sur une ligne de commande, le nom commercial du tiers sur la fiche d’un contact.

Tout ce qui suit a été testé le 15 octobre 2026 sur une installation neuve de Dolibarr 24.0.2. Les règles de sécurité des formules (liste blanche, variables autorisées) sont détaillées dans la note Champ calculé refusé depuis Dolibarr 23 : ce guide en rappelle l’essentiel et va plus loin.

Créer un champ calculé

Le champ se crée dans la configuration du module concerné : Accueil › Configuration › Modules / Applications, roue crantée du module (Produits, Commandes, Tiers…), onglet Attributs supplémentaires. Pour une ligne de document, prenez l’onglet Attributs supplémentaires (lignes).

Remplissez le libellé, le code et le type. Le type sert au format d’affichage : avec le type « Décimal », notre prix TTC s’affichait « 10,55 ». La formule se saisit dans la zone Champ calculé. Le réglage Visibilité décide où le champ apparaît, et Sur les PDF s’il est imprimé.

Une confusion vue sur le forum : « champ calculé » n’est pas un type. On choisit un type normal, puis on remplit la formule.

Les règles à connaître

• L’objet de la fiche s’écrit $objectoffield. Ses propriétés se lisent avec -> : $objectoffield->price, $objectoffield->qty.
• Une variable de travail doit s’appeler $var1, $var2… Une autre variable est refusée.
• Pour lire un autre objet : ($var1 = new Product($db)), puis $var1->fetchNoCompute(id). fetch() est refusé.
• Seules les fonctions de la liste blanche sont acceptées (round, min, max, abs, dol_now…).
• Pas de point en dehors d’un nombre. Un texte comme 'n.a.' fait échouer toute la formule : « dot char is forbidden if not strictly between 2 numbers ». Écrivez 'na'.
• Pas de requête SQL.

Une formule refusée affiche, à la place de la valeur, un message qui commence par Bad string syntax to evaluate.

Attention : l’exemple donné dans l’aide de Dolibarr ne fonctionne pas tel quel. Il utilise une variable $reloadedobj, que Dolibarr 24 refuse lui-même (« found use of $ not matching pattern »). Remplacez-la par $var1.

Des formules testées

Toutes ont été créées dans l’interface et relues sur la fiche.

Prix TTC d’un produit (attribut des produits, type Décimal) :

$objectoffield->price * (1 + $objectoffield->tva_tx / 100)

Produit à 10 € HT, TVA 5,5 % : la fiche affiche 10,55.

Nombre de cartons sur une ligne de commande (attribut des lignes de commande). Le produit a un attribut entier cond (6 par carton) :

(($var1 = new Product($db)) && $var1->fetchNoCompute($objectoffield->fk_product) && ($var2 = ($var1->array_options['options_cond'] * 1)) > 0) ? round($objectoffield->qty / $var2, 1) : 'na'

Ligne de 12 unités : 2. Le résultat s’imprime aussi dans une colonne du PDF de la commande avec « Sur les PDF » = 1 et le modèle eratosthene. Le PDF l’écrit avec un point (« 1.5 »).

Nom commercial du tiers sur la fiche d’un contact (attribut des contacts) :

($var1 = new Societe($db)) && ($var1->fetchNoCompute($objectoffield->socid) > 0) ? $var1->name_alias : ''

La fiche du contact affiche le nom commercial du tiers.

Conditions imbriquées :

$objectoffield->id == 1 ? 'premier' : ($objectoffield->id == 2 ? 'second' : 'autre')

Elle fonctionne en 24.0.2. Elle était refusée en 21.0.4 (même formule, même fonction d’évaluation : refus en 21.0.4, acceptée en 20.0.4 et en 24.0.2). Si une formule de ce genre ne marche pas chez vous, regardez votre version.

Ajouter une fonction à la liste blanche

La liste se règle dans conf/conf.php, ligne $dolibarr_main_restrict_eval_methods. Une installation neuve en 24 l’y écrit déjà : ajoutez votre fonction à la fin, sans rien retirer. La marche à suivre complète est dans la note sur la liste blanche.

Testé : strtoupper($objectoffield->label) est refusée, puis acceptée une fois strtoupper ajoutée. Mais elle laisse les lettres accentuées en minuscule (« CAFé MOULU »). Avec mb_strtoupper ajoutée à la liste, on obtient « CAFÉ MOULU ».

Chaque fonction ajoutée élargit ce qu’une formule peut faire sur votre serveur : n’ajoutez que ce dont vous avez besoin.

Fiche, liste, PDF, base : où est la valeur ?

Par défaut, un champ calculé n’est pas enregistré en base : la colonne reste vide, même après avoir enregistré la fiche. La formule est recalculée à chaque affichage.

• Sur la fiche et sur le PDF : la valeur est juste.
• Dans les listes, elle peut être fausse. Dans la liste des produits, notre prix TTC affichait 10 au lieu de 10,55. En liste, la formule ne dispose que d’une partie des propriétés de l’objet : ici, pas le taux de TVA. Le code de Dolibarr le signale lui-même. Une formule qui ne lit que des propriétés chargées par la liste s’affiche correctement.

Enregistrer la valeur en base : l’option cachée et son piège

Dolibarr a une option, absente des menus, qui enregistre le résultat des formules : MAIN_STORE_COMPUTED_EXTRAFIELDS. Pour l’activer : Accueil › Configuration › Divers, nom MAIN_STORE_COMPUTED_EXTRAFIELDS, valeur 1, Ajouter. Dans le formulaire des attributs, la mention « Stocker le champ calculé » apparaît alors à côté de la formule, avec un avertissement.

Ce que nous avons constaté :

• la formule est calculée à l’enregistrement de la fiche, et le résultat est écrit en base ;
• la liste affiche alors la valeur enregistrée, qui est juste (10,55) ;
• les fiches existantes restent vides tant qu’elles ne sont pas enregistrées à nouveau ;
• Dolibarr prévient lui-même : la valeur n’est recalculée que quand l’objet est modifié. Si la formule dépend d’un autre objet (le conditionnement du produit, par exemple), la valeur enregistrée devient fausse quand cet autre objet change.

Le piège : une seule formule en erreur bloque l’enregistrement de tous les attributs de la fiche. Avec l’option active et un champ calculé refusé sur les produits, nous avons modifié un attribut normal (le conditionnement, de 6 à 8). L’enregistrement a échoué avec « Data too long for column ‘ancien’ at row 1 », et la modification a été perdue. Le message d’erreur de la formule, trop long, ne tient pas dans la colonne. Une fois les formules refusées corrigées ou supprimées, tout s’est enregistré normalement.

Avant d’activer cette option, ouvrez une fiche de chaque type concerné et vérifiez qu’aucun champ calculé n’affiche « Bad string syntax to evaluate ».

Ce qu’un champ calculé ne peut plus faire

Une somme ou une requête sur d’autres enregistrements, comme le total des cotisations d’un adhérent ou un délai de paiement moyen, n’est plus possible. Les requêtes SQL sont refusées. Les solutions sont dans un module :

• un trigger qui calcule la valeur et l’écrit dans un attribut normal quand l’objet change ;
• une tâche planifiée qui la recalcule ;
• une fonction fournie par le module, ajoutée à la liste blanche (voir la note sur la liste blanche).

Ce que nous n’avons pas testé

• Les autres versions dans l’interface : les comparaisons 20.0.4 et 21.0.4 portent sur la fonction d’évaluation seule, avec les mêmes formules.
• Les autres modèles PDF qu’eratosthene.
• L’option MAIN_STORE_COMPUTED_EXTRAFIELDS avec plusieurs entités (multisociété), et l’ajout d’une ligne de document par l’interface avec cette option.

En résumé

• Un champ calculé = un type normal + une formule dans « Champ calculé ».
• $objectoffield pour la fiche, $var1 pour un autre objet, fetchNoCompute(), pas de point dans les textes, pas de SQL.
• L’exemple de l’aide de Dolibarr utilise $reloadedobj : remplacez par $var1.
• La valeur est juste sur la fiche et le PDF, parfois fausse dans les listes, absente de la base.
• MAIN_STORE_COMPUTED_EXTRAFIELDS l’enregistre, mais une formule en erreur bloque alors l’enregistrement de toute la fiche.

Si une formule résiste, le diagnostic à 90 € consiste à regarder votre instance avec vous pendant une heure, puis à vous remettre par écrit la cause et ce que coûterait la correction.