Neue Steuerzonen und Ausgabe in den Vorlagen

Question

Hallo,

wir wollen Kivitendo mit neuen Steuerzonen nutzen (wir werden in Zukunft auch in UK/FR Umsatzsteuer melden).
Das funktioniert soweit im Kivitendo auch korrekt (also neue Steuerkonten, Steuerschluessel und Steuerzonen anlegen, Aufträge und Rechnunen anlegen und die zugehörigen Automatikbuchungen).

Ein Fehler kommt dann aber bei den Vorlagen. Hier wird dann bei der klassichen Schleife

<%foreach tax%>

\multicolumn{5}{l}{<%taxdescription%>} & <%tax%> \kwaehrung \\

<%end tax%>

bei allem Steuerzonen ausser Standard 1/2/3/4 quasi immer ein vollkommen falscher Steuertext <%taxdescription%> ausgegeben (also von einer falschen Steuerzone/ Steuerschluessel).
Die ebenfalls in den Vorlagen abfragbare Variable <%taxzone_id%> hingegen liefert die korrekt ID zur Steuerzone. Es ist jedoch wenig praktikabel, hier die Vorlagen auf Datenbank_IDs anzupassen.
In der Kivi-Maske wird noch bei den Summen der Rechnung der richtige Steuertext angezeigt.

Verstehen wir hier die Technik von Kivitendo nicht? Bzw. woher kommen die Steuerdaten für die Vorlagen, damit wir uns einmal auf die Suche nach dem Problem machen können.

Wenn jemand auch neue Steuerzonen nutzt, ist das Problem bekannt, oder ist es gar keines und jemand gibt uns bitte einen Tip was wir falsch machen.

Wir nutzen aktuell die 3.4.1, aber der gleiche Fehler tritt auch in der Online-Demo Steigmann 3.5.x-beta auf.

Grüße,

Dirk Marklewitz

Answer 1

Die Daten für die Schleife der Steuerinformationen für die Rechnungsdruckvorlage werden hier gefüllt:

https://github.com/kivitendo/kivitendo-erp/blob/034ba526051bdcb8ff4506abe0c860f66cd0e74f/SL/IS.pm#L510

Die Beschreibung kommt letztendlich aus tax.description, dafür muß aber auch alles korrekt verknüpft sein. Habe das nicht getestet, aber beim Debuggen würde ich dort anfangen.

In OE.pm gibt es nochmal das Gleiche.

Answer 2

Hallo,

ich habe das Problem nun gefunden und für uns befriedigend gelöst, wobei es insgesamt nicht ideal ist und ein Problem in der Struktur von Kivitendo ist. Ich konnte es mit einer kleinen Änderung aber schon gehörig verbessern. Es besteht zwar immer noch die Gefahr, das es zu falschen Ausgaben kommen kann, aber sie ist bedeutend geringer.

Problembeschreibung:
Wenn mehrere Steuerschluessel das gleiche Automatikkonto nutzen, kommt es zu Fehlern.

60 Umsatzsteuer Grossbritannien 20,00 % 3817 Umsatzsteuer aus in anderen EG-Land stpfl. Lieferungen
61 Umsatzsteuer Frankreich 20,00 % 3817 Umsatzsteuer aus in anderen EG-Land stpfl. Lieferungen
70 Steuerpflichtige EU-Lieferung zum vollen Steuersatz Grossbritannien 20,00 % 3817 Umsatzsteuer aus in anderen EG-Land stpfl. Lieferungen
71 Steuerpflichtige EU-Lieferung zum vollen Steuersatz Frankreich 20,00 % 3817 Umsatzsteuer aus in anderen EG-Land stpfl. Lieferungen

Beim Konto 3817 muss man dies aber tun (Umsatzsteuer aus in anderen EG-Land stpfl. Lieferungen), wenn man in mehr als einem anderen Land versteuert (3817 ist dafür ein Sammelkonto).
Bei der Ausgabe der Steuerzonentexte über den Steuerschlüssel wird nun immer nur das Automatikkonto als Suchindex genutzt, was im obigen Fall aber nun nicht mehr eindeutig ist

Hier wird beim Druck vom Auftraegen (oe.pm) und Rechnungen (is.pm) das taxobject gesucht mit

my $tax_obj = SL::DB::Manager::Tax->find_by(taxnumber => $form->{"${item}_taxnumber"});

wobei {item}_taxnumber das jeweilige Automatikkonto ist und als Schlüssel nicht eindeutig. Leider ist an dieser Stelle kein eindeutiger Rückwärtsindex vorhanden (könnte man natuerlich programmieren), aber mit dem {item}_description (dem Text des Steuerschlüssels, dieser ist vorhanden) kommt man nun dem Schlüssel schon bedeutend näher in der Eindeutigkeit, und in Kombination sollte es für die meisten Fälle dann genügen und erspart weitergehende Änderungen.

my $tax_obj = SL::DB::Manager::Tax->find_by(taxnumber => $form->{"${item}_taxnumber"}, taxdescription => $form->{"${item}_description"});

Die Änderung betrifft die Dokumentenausgabe/Druck von Auftragen (oe.pm) und Rechnungen (is.pm).

Damit kommt man dann auf korrekte Auftrags- und Rechnungstexte (jedenfalls, solange man nicht Automatikkonto UND Schlüsseltext zusammen doppelt).

An wen müsste man sich denn melden, damit dies so in Kivitendo geändert wird (damit wir nicht noch mehr Änderungen in unser diff bekommen).

Grüße,

Dirk Marklewitz

Comments

Hi Dirk,
dein Ansatz möglichst viel im Standard abzubilden ist sehr sinnvoll.
Darauf baue ich auch beim Partnermodell, d.h. es ist sinnvoller sich aktiv in die Mitentwicklung einzuklinken, bevor man seine eigenen Änderungen immer hinterherpflegen muss.

Ihr habt hier zwei Optionen:

1. Sich selber als Entwicklungspartner qualifizieren
2. Einen Entwicklungspartner mit der Integration in den Standard für diese Änderungen beauftragen

Gruß,