Berechnete Felder in Dolibarr

Ein berechnetes Feld ist ein ergänzendes Attribut, dessen Wert nicht eingegeben, sondern von einer Formel berechnet wird. Ein Bruttopreis, die Anzahl Kartons auf einer Auftragszeile, die Firmenbezeichnung des Partners auf der Karte eines Kontakts.

Alles Folgende wurde am 15. Oktober 2026 auf einer neuen Installation von Dolibarr 24.0.2 getestet. Die Sicherheitsregeln der Formeln (Whitelist, erlaubte Variablen) stehen ausführlich in der Notiz Berechnetes Feld abgelehnt seit Dolibarr 23: diese Anleitung fasst sie zusammen und geht weiter.

Ein berechnetes Feld anlegen

Das Feld wird in der Einrichtung des betroffenen Moduls angelegt: Start › Einstellungen › Module/Anwendungen, Zahnrad des Moduls (Produkte, Aufträge, Partner…), Reiter Ergänzende Attribute. Für eine Dokumentzeile nehmen Sie den Reiter Ergänzende Attribute (zu Positionen/Zeilen).

Füllen Sie Bezeichnung, Code und Typ aus. Der Typ bestimmt das Anzeigeformat: mit dem Typ „Fließkommazahl“ zeigte unser Bruttopreis 10,55. Die Formel kommt in das Feld Berechnetes Feld. Sichtbarkeit bestimmt, wo das Feld erscheint, und Anzeige im PDF, ob es gedruckt wird.

Eine Verwechslung aus dem Forum: „berechnetes Feld“ ist kein Typ. Man wählt einen normalen Typ und trägt dann die Formel ein.

Die Regeln

• Der Datensatz der Karte heißt $objectoffield. Seine Eigenschaften liest man mit ->: $objectoffield->price, $objectoffield->qty.
• Eine Arbeitsvariable muss $var1, $var2… heißen. Jede andere Variable wird abgelehnt.
• Um ein anderes Objekt zu lesen: ($var1 = new Product($db)), dann $var1->fetchNoCompute(id). fetch() wird abgelehnt.
• Nur Funktionen der Whitelist sind erlaubt (round, min, max, abs, dol_now…).
• Kein Punkt außerhalb einer Zahl. Ein Text wie 'n.a.' lässt die ganze Formel scheitern: „dot char is forbidden if not strictly between 2 numbers“. Schreiben Sie 'na'.
• Keine SQL-Abfrage.

Eine abgelehnte Formel zeigt statt des Werts eine Meldung, die mit Bad string syntax to evaluate beginnt.

Achtung: das Beispiel in der Hilfe von Dolibarr funktioniert so nicht. Es verwendet eine Variable $reloadedobj, die Dolibarr 24 selbst ablehnt („found use of $ not matching pattern“). Ersetzen Sie sie durch $var1.

Getestete Formeln

Alle wurden in der Oberfläche angelegt und auf der Karte geprüft.

Bruttopreis eines Produkts (Attribut der Produkte, Typ Fließkommazahl):

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

Produkt zu 10 netto, 5,5 % MwSt.: die Karte zeigt 10,55.

Anzahl Kartons auf einer Auftragszeile (Attribut der Auftragszeilen). Das Produkt hat ein Ganzzahl-Attribut cond (6 pro Karton):

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

Zeile mit 12 Stück: 2. Das Ergebnis wird auch in einer Spalte des Auftrags-PDFs gedruckt, mit „Anzeige im PDF“ = 1 und der Vorlage eratosthene. Das PDF schreibt es mit Punkt („1.5“).

Firmenbezeichnung des Partners auf der Karte eines Kontakts (Attribut der Kontakte):

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

Die Karte des Kontakts zeigt die Firmenbezeichnung des Partners.

Verschachtelte Bedingungen:

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

Funktioniert in 24.0.2. In 21.0.4 wurde sie abgelehnt (gleiche Formel, gleiche Auswertungsfunktion: abgelehnt in 21.0.4, akzeptiert in 20.0.4 und 24.0.2). Wenn eine solche Formel bei Ihnen nicht geht, prüfen Sie Ihre Version.

Eine Funktion zur Whitelist hinzufügen

Die Liste steht in conf/conf.php, Zeile $dolibarr_main_restrict_eval_methods. Eine neue 24er-Installation schreibt sie bereits dort hinein: fügen Sie Ihre Funktion am Ende hinzu, ohne etwas zu entfernen. Das ganze Vorgehen steht in der Notiz zur Whitelist.

Getestet: strtoupper($objectoffield->label) wird abgelehnt, nach dem Hinzufügen von strtoupper akzeptiert. Akzentbuchstaben bleiben dabei aber klein („CAFé MOULU“). Mit mb_strtoupper in der Liste erhält man „CAFÉ MOULU“.

Jede hinzugefügte Funktion erweitert, was eine Formel auf Ihrem Server tun kann: fügen Sie nur hinzu, was Sie brauchen.

Karte, Liste, PDF, Datenbank: wo steht der Wert?

Standardmäßig wird ein berechnetes Feld nicht in der Datenbank gespeichert: die Spalte bleibt leer, auch nach dem Speichern der Karte. Die Formel wird bei jeder Anzeige neu berechnet.

• Auf der Karte und im PDF: der Wert stimmt.
• In Listen kann er falsch sein. In der Produktliste zeigte unser Bruttopreis 10 statt 10,55. In einer Liste hat die Formel nur einen Teil der Eigenschaften des Objekts: hier nicht den Steuersatz. Der Code von Dolibarr sagt das selbst. Eine Formel, die nur von der Liste geladene Eigenschaften liest, wird richtig angezeigt.

Den Wert in der Datenbank speichern: die versteckte Option und ihre Falle

Dolibarr hat eine Option, die in keinem Menü steht und das Ergebnis der Formeln speichert: MAIN_STORE_COMPUTED_EXTRAFIELDS. Zum Aktivieren: Start › Einstellungen › Erweiterte Einstellungen, Name MAIN_STORE_COMPUTED_EXTRAFIELDS, Wert 1, Hinzufügen. Im Formular der Attribute erscheint dann neben der Formel der Hinweis „Berechnetes Feld speichern“, mit einer Warnung.

Was wir festgestellt haben:

• die Formel wird beim Speichern der Karte berechnet und das Ergebnis in die Datenbank geschrieben;
• die Liste zeigt dann den gespeicherten Wert, und der stimmt (10,55);
• bestehende Datensätze bleiben leer, bis sie erneut gespeichert werden;
• Dolibarr warnt selbst: der Wert wird nur neu berechnet, wenn das Objekt geändert wird. Hängt die Formel von einem anderen Objekt ab (zum Beispiel der Packungsgröße des Produkts), wird der gespeicherte Wert falsch, sobald sich dieses andere Objekt ändert.

Die Falle: eine einzige fehlerhafte Formel blockiert das Speichern aller ergänzenden Attribute der Karte. Mit aktiver Option und einem abgelehnten berechneten Feld bei den Produkten haben wir ein normales Attribut geändert (die Packungsgröße, von 6 auf 8). Das Speichern schlug fehl mit „Data too long for column ‘ancien’ at row 1“, und die Änderung ging verloren. Die Fehlermeldung der Formel ist zu lang für die Spalte. Nachdem die abgelehnten Formeln korrigiert oder gelöscht waren, wurde alles normal gespeichert.

Bevor Sie diese Option aktivieren, öffnen Sie einen Datensatz jedes betroffenen Typs und prüfen Sie, dass kein berechnetes Feld „Bad string syntax to evaluate“ anzeigt.

Was ein berechnetes Feld nicht mehr kann

Eine Summe oder eine Abfrage über andere Datensätze, etwa die Summe der Beiträge eines Mitglieds oder eine durchschnittliche Zahlungsdauer, ist nicht mehr möglich. SQL-Abfragen werden abgelehnt. Die Lösungen gehören in ein Modul:

• ein Trigger, der den Wert berechnet und in ein normales Attribut schreibt, wenn sich das Objekt ändert;
• ein geplanter Job, der ihn neu berechnet;
• eine vom Modul bereitgestellte Funktion, zur Whitelist hinzugefügt (siehe die Notiz zur Whitelist).

Was wir nicht getestet haben

• Andere Versionen in der Oberfläche: die Vergleiche mit 20.0.4 und 21.0.4 betreffen nur die Auswertungsfunktion, mit denselben Formeln.
• Andere PDF-Vorlagen als eratosthene.
• Die Option MAIN_STORE_COMPUTED_EXTRAFIELDS mit mehreren Mandanten (Multicompany) und das Hinzufügen einer Dokumentzeile über die Oberfläche mit dieser Option.

Zusammenfassung

• Berechnetes Feld = normaler Typ + Formel in „Berechnetes Feld“.
• $objectoffield für den Datensatz, $var1 für ein anderes Objekt, fetchNoCompute(), kein Punkt in Texten, kein SQL.
• Das Beispiel in der Hilfe von Dolibarr nutzt $reloadedobj: durch $var1 ersetzen.
• Der Wert stimmt auf der Karte und im PDF, ist in Listen manchmal falsch und fehlt in der Datenbank.
• MAIN_STORE_COMPUTED_EXTRAFIELDS speichert ihn, aber eine fehlerhafte Formel blockiert dann das Speichern der ganzen Karte.

Wenn eine Formel nicht will: die Diagnose für 90 € heißt, eine Stunde lang Ihre Instanz mit Ihnen anzusehen und Ihnen dann schriftlich die Ursache und die Kosten der Korrektur zu geben.