Hallo Manuel,
Zuerst mal zur Installation: Das Update lief auf 2 Instanzen ohne Fehlermeldungen. Durchgeführt habe ich es auf die gleiche Art wie die letzten 3-4 Updates, die alle immer erfolgreich waren. Also das würde ich jetzt mal als Fehlerquelle ausschließen - nicht zuletzt auch aufgrund meiner Ergebnisse bei der Fehlersuche.
Um den Fehler reproduzieren zu können, muss bei den Stammdatensätzen für die Umsatzsteuer im Feld Name ein MWST-Code eingegeben sein. z.B. also „018“ oder was immer halt sinnvoll ist. Es ist kein Pflichtfeld, aber wenn etwas angegeben ist, dann funktioniert die Änderung in den Buchungszeilen nicht.
Ich habe die entsprechenden Stellen im Code auch gefunden und kann nachvollziehen, was passiert. Nur beheben kann ich es nicht auf geeignete Art und Weise.
Wenn man das Logging aktiviert sieht man den enthaltenen Wert in der Variable $txtva recht gut.
Als Beispiel kann der Aufruf der Funktion price2num aus der Klasse facture.class.php in Zeile 3314 genommen werden.
Die Funktion price2num ist dann in der Klasse functions.lib.php. Dort sieht man ab Zeile 4727 dass allfällige Sonderzeichen, wie z.B. Klammern, aus der Variablen rausgefiltert werden.
Somit wird aus dem z.B. ursprünglich enthaltenen Wert „20 (020)“ (zusammengesetzt aus dem MWSt-Prozentsatz und dem in den MWSt Stammdaten eingetragenen Wert aus dem Feld „Name“) der Wert „20020“. Dieser Wert ist dann kein gültiger Prozentsatz mehr (gottseidank).
Also wenn ich den Programmcode ansehe, ist das Verhalten für mich schlüssig und nachvollziehbar.
Meiner Ansicht nach gibt es keinen Grund, den Inhalt des Feldes $txtva durch die Konvertierung in price2num zu schicken (das wird bei den analogen insert-Funktionen zum Einfügen einer neuen Belegzeile auch nicht gemacht sondern nur beim Update). An den Stellen, die ich gefunden habe, wird dieses Feld ohnehin separat nochmal behandelt um den Inhalt gegebenenfalls auf Prozentsatz und vat-src-code aufzuteilen (siehe z.B. Zeile 3330 in facture.class.php).
Um 12.0.4 für mich verwenden zu können, habe ich in der Funktion price2num gleich zu Beginn folgenden Code eingebaut:
if (preg_match(’/((.*))/’, $amount)) {
return $amount; // $txtva can have format ‚5.0(XXX)‘ or ‚5‘
}
Diese Korrektur verlässt sich aber auf die Tatsache, dass kein Fall in der Anwendung auftritt, in dem tatsächlich fälschlicherweise eine Klammer oder ein sonstiges betroffenes Sonderzeichen in einem Feld auftaucht, das mithilfe der Funktion price2num standardisiert werden soll. Für mich ist das also nur als Workaround tauglich, weil ich nicht abschätzen kann, was im Rest der Applikation passiert.
Deswegen wäre es fein, wenn jemand, der tiefer in der Entwicklung von Dolibarr eingebunden ist, sich um einen nachhaltigen Bugfix kümmern könnte.
Ich hoffe, dass die Beschreibung jetzt klarer ist und dass das hier auch der richtige Kanal ist, um solche Fehler zu melden.
Und danke, fürs drum kümmern!
LG Peter
