projekt kivitendo

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):

https://www.kivitendo.de/kivi/ap.pl?action=edit&id=709

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.

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.

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.