Fehler #563
Zahlungeingänge bzw. -ausgänge werden bei Debitoren- bzw. Kreditorenbuchungen in Fremdwährung falsch angezeigt
100%
Beschreibung
In der aktuellen unstable (18.2.2023) sind sowohl im alten wie im neuen Design die Währungen bei den Zahlungseingängen bzw. ausgängen bei Debitoren bzw. Kreditorenbuchungen vertauscht.
Entsprechend werden bei beiden Währungen falsche Zahlen dargestellt, bzw. bei der Standardwährung wird der Betrag angezeigt, der für die Fremdwährung richtig wäre, bei der Fremdwährung wird ein komplett falscher Wert errechnet.
Die Buchungen hingegen werden korrekt ausgeführt und entsprechend auch im Tab 'Buchungen' angezeigt.
Beispiel:
Standardwährung: CHF
Fremdwährung: EURO
Tageskurs der Kreditorenbuchung: 1.1
Buchungssatz: 20 Euro Materialeinkauf an Verbindlichkeiten aus Lieferungen und Leistungen
Zahlungseingang: 20 Euro Tageskurs der Zahlung: 1.3
Bei den Zahlungsausgängen wird aber angezeigt: 20 CHF bzw. 15.38 EURO
Gebucht wird hingegen: 22 CHF Materialeinkauf, 4 CHF Kursverlust und 26 CHF Kasse
siehe angefügte Screenshots
In der 3.7.0 ist das Problem noch nicht vorhanden, da dort bei den Zahlungsein- bzw. ausgängen keine Währungen angezeigt werden, sondern nur der Betrag in Fremdwährung und der Wechselkurs
Dateien
Historie
Von Jan Büren vor fast 2 Jahren aktualisiert
Bei den Zahlungsausgängen wird aber angezeigt: 20 CHF bzw. 15.38 EURO
Gebucht wird hingegen: 22 CHF Materialeinkauf, 4 CHF Kursverlust und 26 CHF Kasse
siehe angefügte Screenshots
In der 3.7.0 ist das Problem noch nicht vorhanden.
Ich hab die Buchung mal gerade in der Werft nachgestellt, genau das wird dort auch gebucht:
Buchungskonto Beschreibung Soll Haben 1600 Kasse 26,00 6800 Porto 22,00 6880 Aufwendungen aus Kursdifferenzen 4,00
Von daher ist es doch logisch, dass du soviele Franken ausgeben musst, wenn Dein Wechselkurs so ungünstig ist.
Kivi denkt ja so: Fremdwährung * x = Hauswährung.
Demnach wäre ja dann 20 * 1,1 = 22 CHF, also korrekt.
Der Zahlungsausgang wäre dann 20 * 1,3 = 26 CHF, also auch korrekt.
In Euro gerechnet hast du dann also 15,38 € gegeben.
Vorher wurde diese Logik noch nie angezeigt und damit dies dem Anwender jetzt bewußter wird, hab ich die zusätzliche Spalte für die umgerechnete Fremdwährung eingeführt.
Hier mein Beispiel in der Werft mit USD und denselben Zahlen (Version 3.7):
Von Andreas Rudin vor fast 2 Jahren aktualisiert
Hallo Jan
"....
In Euro gerechnet hast du dann also 15,38 € gegeben."
Genau das ist eben falsch:
Du hast 20 Euro ausgegeben und das entspricht 26 CHF.
Jetzt zeigt Kivitendo aber an, dass nur 20 Franken ausgegeben wurden, was 15.38 Euro entsprechen würde. Und das stimmt nicht mit der Buchung von 26 Franken überein!
In der Werft, da 3.7.0 ist das Problem noch nicht sichtbar, da dort zu den Beträgen keine Währungen angezeigt werden, sondern nur der Wechselkurs. Die in kivitendo angezeigten Beträge sind die Beträge in US$ und das entspricht wie in den Buchungen korrekt angezeigt wird am Buchungsdatum 22 Euro und am Zahlungsdatum 26 Euro.
Von G. Richardson vor etwa 1 Jahr aktualisiert
Ich muß Andreas da zustimmen, das ist genau falsch herum. Das $form->{paid_$i} in der Maske ist schon in der Fremdwährung, d.h. der umgewandelte Wert ist nicht "fx_paid" (der Wert in der Fremdwährung"), sondern man muß den Wert in der Standardwährung berechnen. Ich habe mal einen Branch mit einer Überarbeitung gepushed (ticket_563_zahlungen_fremdwährung), wo ich das von fx_paid auf defaultcurrency_paid umgestellt habe. Habe das aber nur mit manuellen Zahluungen getestet, nicht mit Bankbuchungen.
Durch die Bankbuchungen kam auch noch ein weiterer Fehler rein, wenn die Zahlung mit Fremdwährung noch nicht gespeichert ist geht die Wechselkursprüfung kaputt (nur bei ar/ap, glaube ich), da es noch keine acc_trans_id gibt.
Das Anzeigen der umgerechneten Standardwährung klappt auch nur beim initialen Öffnen des Belegs, zumindest bei is/ir, sobald man die Seite aktualisiert taucht dort dann immer 0€ auf, da die Neuberechnung in update fehlt.
Die Umstellung wurde offenbar überhaupt nicht mit manuellen Zahlungen getestet. Wäre schön, wenn jemand über meine Änderungen drüberschaut, das verifiziert und auch mit Bankbuchungen testet.
Von Jan Büren vor etwa 1 Jahr aktualisiert
Hallo zusammen,
ich hab das heute mit Bernd und gestern mit Geoff diskutiert.
Mein aktuelle Ergebnis ist, dass es keinen Sinn macht in dem alten Gefüge noch einen Fallunterschied einzubauen der das dann visuell gerade zieht.
Ferner sieht es so aus, dass buchhalterisch (auch für den DATEV-Export) beide Verfahren in Ordnung sind, d.h. es muss jetzt nicht zwingend eine Datenkorrektur in der acc_trans nachträglich erfolgen.
Geoff hat gestern die Idee gehabt den Payment-Code im Bereich Rechnung und FiBu über einen Payment-Controller zu vereinheitlichen.
Das macht meiner Meinung nach sehr viel Sinn, da dabei dann die erlaubten und nicht erlaubten Zustände sowie Darstellungen an einer Stelle wieder zusammengeführt werden und nicht aktuell an vier Stellen parallel.
Der Controller kann dann von den alten Masken aufgerufen werden und der wäre dann auch schon wiederverwendbar wenn wir den Überarbeitungsschritt Invoice-Controller angehen.
Von Andreas Rudin vor 10 Monaten aktualisiert
- Status wurde von Neu zu Erledigt geändert
- % erledigt wurde von 0 zu 100 geändert
Behoben in 3.9.0-beta mit commit 'fx_paid -> defaultcurrency_paid in design40'