release-3.0.0-7-g357d134 erzeugt in Tabelle acc_trans Einträge in die neue Spalte tax_id, die nicht in der Tabelle tax existieren.

[andreas.rudin@…]

Das Datenbankupgrade mit release-3.0.0-7-g357d134 erzeugt in der Tabelle acc_trans eine neue Spalte tax_id.

Der Wert für tax_id wird offensichtlich mit dem Wert von taxkey entsprechend der Tabelle tax erzeugt.

Dort wo die Tabelle acc_trans jedoch keinen Eintrag in der Spalte taxkey enthält, wird einfach als tax_id 0 geschrieben, auch wenn es diese id in der Tabelle tax nicht gibt.
(Das gleiche passiert auch, wenn ein taxkey vorhanden ist, der in der Tabelle tax nicht existiert.)

==> Anstatt hier eine Inkonsistenz in der Datenbank zu erweitern oder sogar zu erzeugen, sollte vor dem Datenbankupdate eine Überprüfung der Einträge in der Spalte taxkey der Tabelle acc_trans stattfinden und bei fehlenden oder falschen Einträgen eine entsprechende Fehlermeldung erscheinen und möglichst auch ein Hinweis, wie das Problem behoben werden kann.

Ist es vielleicht falsch, dass ein Eintrag in der acc_trans ohne Steuern ist, wenn kein Eintrag bei taxkey in der acc_trans oder der taxkey nicht in der Tabelle taxkeys (sprich keine Verlinkung zur Tabelle tax) vorhanden ist?

Wenn ja, dann stimme ich dir vollkommen zu und es bleibt wohl nichts anderes übrig als die fehlerhaften Einträge während des Upgrates überprüfen zu lassen. Und wie wird dann zum Beispiel beim DATEV-Export der richtige Steuersatz ermittelt? Irgendwie müsste man ja dann auch auf die gleiche Weise an die tax_id kommen oder nicht?

Falls nein, so muss lediglich ein Standardwert in der Tabelle tax mit Steuersatz 0% her. Hierfür hatte ich beim Upgrate 0 ausgewählt, was allerdings zu Problemen geführt hat, da es in der Schweiz keinen Eintrag in tax mit id=0 gibt. Zugegeben, sauberer wäre gewesen, dass man die id aus tax für den Steuerschlüssel=0 abfragt, was leider aber auch nicht die Lösung ist, da es in der Schweiz ebenfalls keinen Steuerschlüssel=0 gibt. Es gibt wohl zwei Lösungen hierfür:

Entweder wir legen einfach einen neuen Eintrag in tax an mit id=0 und ohne Steuern an; oder der Standardwert für keine Steuern muss irgendwie ermittelt werden, anstatt einfach hartcodiert im Upgrate zu stehen. Offen bleibt dann aber auch, wie dieser ermittelt werden soll?

Für den Fall "keine Steuern" muss es einen Steuerschlüssel geben. Ansonsten funktioniert das ganze System nicht gut & nicht durchgehend.

Beispiel. Wenn du eine Lieferung in die EU hast, und der Empfänger zahlt dort die Steuern, musst du ja hier nicht zahlen. Das ist Steuerzone 1.

Nehmen wir also eine Buchungsgruppe 19%, daraus die income_accno_id_1. Dazugehöriges Konto ist z.B. "8320 | Erlöse aus im and.EG-Land steuerpfl.Lieferungen".

Schauen wir mal nach, wie es sich dort mit Steuern verhält:

mbkivicapeit=> select * from taxkeys where chart_id = 152 order by startdate desc limit 1;
 id  | chart_id | tax_id | taxkey_id | pos_ustva | startdate  
-----+----------+--------+-----------+-----------+------------
 757 |      152 |    382 |        10 |           | 1970-01-01

Die 152 ist mein Wert aus meiner Buchungsgruppe. Aha, hat also eine Steuer. Und wie sieht die aus?

mbkivicapeit=> select * from tax where id = 382;
 chart_id |  rate   | taxnumber | taxkey |                 taxdescription                 |           itime            |           mtime            | id  
----------+---------+-----------+--------+------------------------------------------------+----------------------------+----------------------------+-----
      196 | 0.00000 | 1767      |     10 | Im anderen EU-Staat steuerpflichtige Lieferung | 2012-12-14 16:11:12.496583 | 2012-12-14 16:28:58.303524 | 382

Sprich: wenn in einem Kontenrahmen keine Steuer mit Rate 0 existiert, dann bekommt man in unserem Programm an mehreren Stellen echte Probleme.

Du kannst nicht davon ausgehen, dass diese Steuer eine bestimmte ID hat -- aber existieren muss der Steuersatz und die dazugehörigen Einträge in taxkeys!

Gibt es diese Einträge in einem Steuerrahmen nicht, so ist das ein separates Problem, das zuerst gefixt werden muss (über ein zweites DB-Upgradescript; und dein Script sollte dann tunlichst von diesem zweiten Script abhängen).

Ja, das ist schon klar. Allerdings ist nicht klar, welchen taxkey man auswählen sollte, falls es mehrere Einträge mit 0% Steuern gibt, was ja durchaus möglich ist.

Meiner Meinung nach sollten wir fest von Steuerschlüssel 0 für keine Steuer ausgehen. Ist ja auch so in DATEV vorgesehen. Bei Installationen die keinen DATEV-Export brauchen und nicht für Deutschland sind
müsste es einen Steuerschlüssel 0 trotzdem zwingend geben, kann man ja prüfen.
Steuerschlüssel 0 ist auch bei den Umbuchungen für die Bestandsmethode hart im Programmcode drin.

Von mir aus, ja.

Wird durch Commit b4359a89d5d7c6183983aeb959244ac20b1320de behoben. Hier wird nämlich eine Dependency zu einem Update-Script gesetzt, das die Existenz von Steuerschlüsseln mit Wert 0 sichert.