Vorsteuer-/Umsatzsteuer-Verwechslungen vorbeugen

[Niclas]

Um bei Dialogbuchungen keine Verwechslungen von Vorsteuer mit Umsatzsteuer oder umgekehrt zu bekommen, könnte man nach der Auswahl eines Kontos die entsprechenden Steuerkonten in der Zeile filtern. Will man zum Beispiel eine Buchung auf ein Erlöskonto erstellen, sollten auf der rechten nur Umsatzsteuerkonten im Dropdown erscheinen (und eben keine Vorsteuerkonten).

Die Frage ist nun, wie genau soll man nun filtern? Bei welchen Konten braucht müssen welche Steuerkonten auftauchen bzw. nicht auftauchen? Bisher der Vorschlag ist, dass man bei Erlöskonten nur Umsatzsteuerkonten und bei Aufwandskonten nur Vorsteuerkonten anzeigt, wobei Steuerkonten mit Steuerschlüssel 0 immer angezeigt bleiben. Ist das schon alles oder kann man noch strenger filtern/ist das bereits zu viel?

Zweite Frage ist, wie erkennt man in der Datenbank Vor-/Umsatzsteuerkonten. Hierfür wäre eine neue Zeile in der Tabelle tax nötig. D.h. man müsste beim Speichern von Steuern einstellen, ob es sich um Vor- oder Umsatzsteuern handelt. Wenn man weitere Filtermöglichkeiten für alle Kontoarten (Q,A,C,I,E,L) hätte, müsste es dann weitere Unterscheidungsmöglichkeiten geben als blos Vor-/Umsatzsteuer?

In e82db1a7b5f8cfce019012e60a689c9142851a63/erp:

Filtert Steuern bei Dialogbuchungen

Bei Dialogbuchungen kam es in der Vergangenheit zu Verwechslungen
von Umsatz- und Vorsteuer. Für jedes Konto werden daher nun Steuern
nur noch angezeigt, wenn die Steuer so eingestellt ist, dass sie
für die Kontoart des ausgewählten Kontos angezeigt wird.

Implementiert #2249.

Interessant, interessant.

Eine Sache, die mir gar nicht gefällt, ist die Tatsache, dass man plötzlich bei einem Upgrade Dinge angeben muss, die das Programm eigentlich automatisch setzen können sollte. Ein Sonderfall davon ist die Neuinstallation einer DB, bei der sich User dann die Frage stellen: "warum wird man hier plötzlich um Eingaben gebeten!?"

Meiner Meinung nach sollte das Update vollautomatisch die Flags für bekannte (das schöne englische Wort "well-known") Steuern setzen. Bleiben keine unbekannten Steuern übrig, so wird auch keine Eingabe vom Benutzer erfordert.

"Well-known" ist ein Steuersatz dann, wenn:

• Steuerschlüssel passt,
• Steuersatz passt,
• Beschreibung grob passt.

Was ich mir in Perl dafür vorstellen könnte ($tax ist ein Eintrag aus der Datenbank, für den es gerade die Flags zu setzen gilt):

@well_known_taxes = (
  { taxkey => 0,  rate => 0, description => qr{keine.*steuer}i,          categories => 'ALQCIE' },
  #...
  { taxkey => 18, rate => 7, description => qr{inngergem.*erwerb.*erm}i, categories => 'E' },
);

my $well_known_tax = first {
     ($tax->{taxkey}      == $_->{taxkey})
  && ($tax->{rate}        == $_->{rate})
  && ($tax->{description} =~ $_->{description})
} @well_known_taxes;

if ($well_known_tax) {
  # set categories automatically from $well_known_tags->{categories}
} else {
  # remember entry for the user to make a manual decision
}

Das Ziel muss sein, dem Benutzer möglichst geringe Hürden in den Weg zu legen -- und auch möglichst wenig Gelegenheiten, seine Konfiguration allein durch Unwissen komplett zu vergeigen.

In e82db1a7b5f8cfce019012e60a689c9142851a63/erp:

Filtert Steuern bei Dialogbuchungen

Bei Dialogbuchungen kam es in der Vergangenheit zu Verwechslungen
von Umsatz- und Vorsteuer. Für jedes Konto werden daher nun Steuern
nur noch angezeigt, wenn die Steuer so eingestellt ist, dass sie
für die Kontoart des ausgewählten Kontos angezeigt wird.

Implementiert #2249.

Ohne Einstieg in die programmtechnischen Details fällt mir dazu ein, dass es hierfür bereits hinreichende Lösungsansätze gibt, wenn ein Blick über den Tellerrand erfolgt. So gibt es beispielsweise die "Automatikkonten" bei Moneyplexx, die an der Kategorie hängen (der ein Konto zugeordnet werden kann, aber nicht muss) und somit beim "Dialogbuchen" dafür sorgen, dass eine Zahlung auf ein Erlöskonto automatisch die korrekten Steuern "umbucht", was im Moneyplexx-(und Wiso, und Lexware und, und, und...) Jargon dann "Splitbuchung" heißt.

Ich tue mich schwer damit, dass hier die völlige Freiheit der Kontenwahl (inkl. potentiell einstellbarem grobem Unfug) gegen eine Teilbeschneidung des Benutzers getauscht wird, die dann letztendlich doch keinen echten Mehrwert bringt, denn ich muss jetzt immer noch wissen, was richtig ist, ich kann es halt nur noch halb versemmeln.

Beispiel Moneyplexx: Dort werden die Kategorien in der freien Eingabe Rot und Blau eingefärbt. Ohne Erklärung ist sofort klar, wann welche Farbe verwendet werden muss, selbst wenn Kategorien den selben Namen haben. Das (Farben bzw. Kategorie "Einnahme / Ausgabe", Automatikkonten) kenne ich vergleichbar auch aus anderen Produkten. Ich hab mir die halt auch mal angesehen, frei nach dem Motto "auch andere Mütter haben schöne Töchter".

Die auffällige Lösungsähnlichkeit bei verschiedenen Anbietern lässt vermuten, dass das der Erwartungshaltung vieler Anwender entspricht, deshalb sollten wir erwägen, bei Lösungen zumindest die Frage stellen, warum es andere so machen, wie sie es machen. Im konkreten Fall habe ich dazu eine klare Meinung: Weil´s leicht nachvollziehbar, sinnvoll und hilfreich ist.

Nachtrag: Wir kennen ja ebenfalls Automatikkonten, die Funktion als solche gibt es also schon. Weshalb auf die im Rahmen des Dialogbuchens nicht zugegriffen wird/werden kann, weiß ich nicht, halte es jedoch für prüfenswert.

Ein Bug, der hierdurch hereingekommen ist: die Reihenfolge der Upgradescripte ist bozo. Bei mir wurde gerade steuerfilterung.pl vor tax_constraints.sql ausgeführt. Letzteres weiß aber von der neuen Spalte tax.chart_categories nichts und versucht, eine Zeile in tax ohne diese Spalte einzufügen.

Ich habe das über entsprechende Einträge in @depends gelöst; pushe gleich.

Hierauf bitte in Zukunft verstärkt achten.

16%

Beim Upgrade ist man allerdings noch etwas verwirrt, wenn man neu anlegt und dann einem die 16% Rate entgegenspringt (s.a. Bildschirmfoto).

Ferner wäre es noch schön die Prüfungen die wir beim Kunden hierfür gemacht haben auch als selftest zu spendieren, insofern sie automatisch abbildbar sind.

Ich öffne das kurz an dieser Stelle.

Hmmm. Ggf. ist das Upgrade noch nicht mit einem neuen Mandanten durchgeführt worden, jetzt kann ich im Dialog nur mit 16% buchen.

Bei einem neuen Mandanten sollte man schon direkt den aktuellen Steuersatz nehmen.

Ich vermute, dass hier Information beim Upgrade abgeschnitten wird (Zeige nur einen Steuersatz zu einem Steuerschlüssel an).

Ok, werde das ganze nochmal mit neuen Mandanten testen. Das Problem ist wahrscheinlich, dass der 16%-Steuersatz beim Upgrade automatisch erkannt wird und daher muss man den während des Updates eingeben. Vorgegeben ist immer, dass der Steuersatz bei allen Konten auftaucht. Die Idee ist einfach, dass nicht erkannte Steuern nicht angefasst werden und diese dann für alle Konten zur Verfügung stehen. Heißt also, eigentlich sollte die 16%-Steuer also auch nicht mehr auftauchen, wenn keine 19%-Steuer auftaucht.

Welches Konto willst du denn mit 19% bebuchen? Kann sein, dass wir die Möglichkeiten zu buchen zu stark eingeschränkt haben.

Mit 29d544f90be28bd2282986230318b06f5c534a3b werden jetzt auch alle Steuern vom Kontenrahmen SKR04 erkannt.

Bitte beachten: Steuersätze werden nur angezeigt bei Konten, die auch mit der Steuer bebucht werden dürfen. Die Häkchen einfach entfernen und die Steuer wird nicht mehr angezeigt. Hab den Text beim Update jetzt auch noch etwas erweitert, hoffe, dass das jetzt klar beschrieben ist für alle die andere Kontenrahmen/Steuern? benutzen...