Erstellt vor 2 Jahren
Geschlossen vor 14 Monaten
#2130 closed Fehler (fixed)
Kontorahmen SKR4 enthält doppelte Steuerschlüssel
| Erstellt von: | andreas.rudin@… | Verantwortlicher: | |
|---|---|---|---|
| Priorität: | normal | Meilenstein: | |
| Komponente: | kivitendo ERP | Version: | 3.0.0 |
| Schweregrad: | normal | Stichworte: | |
| Beobachter: | andreas.rudin@… |
Beschreibung
Eine neu installierte Datenbank mit dem in Kivitendo mitgelieferten SKR4 Kontenrahmen enthält in der Tabelle tax zwei Steuerschlüssel doppelt:
taxkey 3 (chart_id 66):
einmal mit id 375 und einmal mit id 388
taxkey 9 (chart_id 33):
einmal mit id 379 und einmal mit id 389
Inkonsistent scheint mir ausserdem, dass die Steuerschlüssel 0 (Keine Steuer) und 1 (Ust-frei) in der Spalte "rate" den Satz von 0.0000 eingetragen haben,
die Steuerschlüssel 10 und 11 hingegen keinen Eintrag in der Spalte "rate" haben.
(alle 4 Steuerschlüssel haben keinen Eintrag in den Spalten "chart_id" und "taxnumber")
Änderungshistorie (4)
comment:1 Geändert vor 2 Jahren durch Niclas
comment:2 Geändert vor 2 Jahren durch m.bunkus@…
Das geht nicht. Die DATEV hat ja beschlossen, dass bei Mehrwertsteuererhöhungen der Steuerschlüssel (bei uns: tax.taxkey) gleich bleibt, sich aber der Steuersatz ändert.
Deswegen gibt es ja mehrere Zeilen für Steuerschlüssel 3, 9 und 19 (jeweils 16 und 19%). Das ist so gewollt und normal! Der erste Teil des Bugreports ist damit ungültig.
Inkonsistenz mit Wert 0: hmm, good point, für taxkey == 11 sollte der ebenfalls auf 0 und nicht auf SQL NULL stehen.
Dann tax.chart_id: diese Spalte gibt an, auf welches Konto Steuern zu buchen sind. Gibt es keine Steuern (also wenn rate == 0), so wird natürlich auch kein Konto dazu benötigt. Das ist also auch OK.
Summa summarum: es bleibt von diesem Bugreport nur die Merkwürdigkeit mit rate IS NULL bei Steuerschlüssel 11.
comment:3 Geändert vor 14 Monaten durch m.bunkus@…
comment:4 Geändert vor 14 Monaten durch m.bunkus@…
- Lösung auf fixed gesetzt
- Status von new nach closed geändert

Eine Lösung wäre die Steuerschlüssel in der Tabelle tax einfach als unique oder Primärschlüssel zu definieren. Die zweite Inkonsistenz ist dadurch zwar noch nicht gelöst, aber immerhin kann es dann keine doppelten Einträge mehr für einen Steuerschlüssel geben.
Im Moment tritt das Problem bei uns vor allem beim Steuerschlüssel 0 auf, da es theoretisch gleichzeitig Einträge mit Steuern und Steuerschlüssel 0, als auch Einträge ohne Steuern und Steuerschlüssel 0 in der Tabelle tax geben kann. Siehe hierzu auch #2129 und #2128.