Warum lassen sich Aufträge aus v3.5.8 in v3.7.0 nicht mehr öffnen?

Question

Nach dem Update von v3.5.8 auf v3.7.0 lassen sich alte Aufträge nicht mehr öffnen und die folgende Fehlermeldung liefert den Hinweis warum:

tax_amount != 0 but no chart_id for taxkey 1004 tax 965 at /var/www/kivitendo-erp/SL/DB/Helper/PriceTaxCalculator.pm line 133.

Das Verhalten tritt sowohl

1. nach dem beschriebenen Update und mit alten Aufträgen auf, als auch
2. nach dem DROP und Reinitialisieren der DBs (Auth und Mandant) auf, wenn man im Jahr 2023 Aufträge im Jahr 2020 anlegen möchte (z.B. Auftragsdatum = 01.01.2020 & Lieferdatum = 12.07.2020).

Ich konnte bisher herausfinden, dass vor dem Update die 'chart_id' 65 aus der Tabelle 'tax' sowohl zur 'id' 376 als auch zur 'id' 965 gehörte. Das kann eigentlich wegen eines Constraints nicht sein.

SELECT chart_id, rate, taxkey, taxdescription, id, chart_categories, skonto_sales_chart_id FROM tax WHERE id=965 OR id=376 ORDER BY chart_id;

liefert für die v3.5.8:

chart_id | rate | taxkey | taxdescription | id | chart_categories | skonto_sales_chart_id |
---------+---------+--------+----------------+-----+------------------+-----------------------+
65 | 0.16000 | 5 | Umsatzsteuer | 376 | I | 129 |
65 | 0.16000 | 3 | Umsatzsteuer | 965 | I | 129 |

und für die v3.7.0 nach dem DB-Update:

chart_id | rate | taxkey | taxdescription | id | chart_categories | skonto_sales_chart_id |
---------+---------+--------+----------------+-----+------------------+-----------------------+
65 | 0.16000 | 5 | Umsatzsteuer | 376 | I | 129 |
| 0.16000 | 3 | Umsatzsteuer | 965 | I | 129 |

Der Versuch den alten Zustand in der Tabelle 'tax' wieder herzustellen scheiter wegen eines Constraints:

=# UPDATE tax set chart_id=65 WHERE id=965;
ERROR:  duplicate key value violates unique constraint "chart_id_unique_tax"
DETAIL:  Key (chart_id)=(65) already exists.

Nach dem Tausch der 'chart_id' für die 'id'-Werte 965 und 376 funktioniert das öffnen der Aufträge wieder.

=# UPDATE tax set chart_id=NULL WHERE id=376;
=# UPDATE tax set chart_id=65 WHERE id=965;

Die Einträge sehen wie folgt aus:
chart_id | rate | taxkey | taxdescription | id | chart_categories | skonto_sales_chart_id |
---------+---------+--------+----------------+-----+------------------+-----------------------+
65 | 0.16000 | 3 | Umsatzsteuer | 965 | I | 129 |
| 0.16000 | 5 | Umsatzsteuer | 376 | I | 129 |

• Gibt es für dieses Verhalten bereits einen offiziellen Lösungsansatz/Patch?

• Welche Seiteneffekte kann der von mir angewendete Patch haben?

Answer 1

Hallo,

Kurz nach dem 3.7-Release gab es einen Fix, der Dein Problem evtl. löst.

Den könntest Du mal probieren.

commit 1f3fcb1bee47863e964e97677f33e9d51a21ada7
Date:   Mon Sep 19 13:33:35 2022 +0200

    DB-Skript zuviel in der 3.6 korrigiert.

Viele Grüße
Bernd

Comments

Hallo,

so schnell hatte ich gar nicht mit einer Antwort gerechnet. Super und vielen Dank. Gibt es irgend eine Möglichkeit solche Antworten selber zu finden oder ist das implizites Wissen?

Viele Grüße
Franz

---

Hallo,

naja - ganz implizit ist das nicht, denn man kann sich die ja commits anschauen. Aber das geht natürlich nicht immer und dauerhaft.

Das Forum hier und der Bug-Tracker sind da schon gute Anlaufpunkte. Für die, die auch selber entwickeln (wollen) evtl. auch die devel-Mailingliste und das IRC.

Evtl. ist es auch mal sinnvoll - mit einem Backup in der Hand - einfach mal die neuste git-Version zu testen und zu schauen, ob der Fehler weg ist.

Viele Grüße
Bernd