Fehler #192
»Kontoauszug verbuchen« kommt mit multipler Zuweisung nicht zurecht
0%
Beschreibung
Wird beim Verbuchen eines CSV-Imports eine Rechnung verschiedenen Positionen zugewiesen, so ist das prinzipiell ja OK (z.B. mehrere Teilzahlungen innerhalb desselben Zeitrahmens). Es kann aber durchaus vorkommen, dass die Rechnung nach Abarbeitung der ersten Zuweisung komplett bezahlt ist. Beim Verbuchen der zweiten Zuweisung kommt es dann zu einem Fehler in `SL::DB::Invoice::pay_invoice`, weil der offene Betrag halt inzwischen 0 ist. Konkrete Fehlermeldung:
`Fehler! invalid amount for payment_type 'without_skonto': 0 at /opt/kivitendo/produktiv/SL/Controller/BankTransaction.pm line 415`
Der Prozess bricht an der Stelle ab. Der Code sollte statt dessen zum Einen damit klarkommen, und zum Anderen darf der Prozess nicht abbrechen, weil ansonsten die komplette Arbeit der manuellen Rechnungszuweisung für den Popo ist.
Viel sinnvoller wäre, den Prozess normal fortzusetzen und anschließend alle so fehlgeschlagenen Verbuchungen noch mal detailliert aufzulisten, damit die Bearbeiterin entsprechend reagieren kann.
Das ist auch kein rein theoretisches Problem. Bei uns hat ein Kunde eine Rechnung schlicht doppelt bezahlt: einmal als Bestandteil einer Sammelüberweisung für mehrere Rechnungen, einmal einzeln. Das fiel bei der Zuweisung schlicht nicht auf, weil halt über 100 Positionen zugewiesen werden mussten.
Direkte Zuweisung an Jan auf Geheiß von Geoff ;)
Historie
Von Peter Schulgin vor mehr als 8 Jahren aktualisiert
Habe soeben einen weiteren Fall mit derselben Fehlermeldung:
Eine Verkaufsrechnung wurde per SPEA-Lastschrift bezahlt.
Danach erfolgte eine SEPA-Rücklastschrift seitens der Bank (vermutlich Konto nicht gedeckt).
Die o.g. Fehlermeldung tritt auf beim Versuch die Rücklastschrift zu verbuchen.
Vermutlich wird tatsächlich "open_amount" verwendet...
Von Peter Schulgin vor mehr als 8 Jahren aktualisiert
Habe soeben einen weiteren Fall mit derselben Fehlermeldung zu Gesicht bekommen:
Eine Verkaufsrechnung wurde per SPEA-Lastschrift bezahlt.
Danach erfolgte eine SEPA-Rücklastschrift seitens der Bank (vermutlich Konto nicht gedeckt).
Die o.g. Fehlermeldung tritt auf beim Versuch die Rücklastschrift zu verbuchen.
Vermutlich wird tatsächlich "open_amount" verwendet...
Von G. Richardson vor mehr als 8 Jahren aktualisiert
Multiple Zuweisung in der Maske ist ein Problem, die ist nicht darauf ausgelegt. daß eine Rechnung mehr als 1x in einem Durchlauf angesprochen wird. Derzeit werden sogar alle anderen Vorschläge für eine Rechnung entfernt, sobald die Rechnung zugewiesen wurde - hier war die Idee, daß wenn eine Rechnung zu mehreren Kontoauszugszeilen passen könnte (gleiche Punktzahl), aber nur eine richtig ist, die falschen Zuweisung verschwinden sobald man die richtige auswählt. Das beisst sich aber mit dem Fall hier.
Ganz konsequent ist das aber nicht, man kann nämlich trotzdem eine weitere Zuweisung per "Rechnung zuweisen" hinzufügen.
Zu der Problembeschreibung:
Mit Martins Patch 92e2fb5927 hat sich das Verhalten geändert. Jetzt bekommt die letzte Rechnung eine Überzahlung und ist damit noch offen, wahrscheinlich ist das erwünscht.
Mosus Einwand, daß das nicht einfach so passieren sollte, ist natürlich weiterhin berechtigt: wenn das automatisch passiert und der Benutzer nicht eingreifen kann, sollte zumindest eine Mitteilung generiert werden, daß es eine Überzahlung gab, um die man sich kümmern sollte. Ansonsten merkt man das erst, wenn man sich die offenen Posten anschaut.
Kompliziertere Fälle (eine Mischung aus mehreren Rechnungen, Gutschriften, Skonto, ...) sollte man für die Maske wahrscheinlich erst gar nicht probieren, und stattdessen beim Popup "Rechnung zuweisen" ansetzen. Derzeit wird das Ergebnis der dortigen Zuweisung wieder an die Maske "Kontoauszug verbuchen" zurückgeschickt, das müßte man wahrscheinlich ändern so daß man direkt aus dem Popup heraus Zahlungen verbuchen kann. Dort hätte man neben den besseren Filtermöglichkeiten auch die Möglichkeit sich vor dem Buchen die Gesamtsummen der Zuweisungen anzuzeigen. Z.B. wenn der Kunde per Sammelüberweisung mehrere Rechnungen bezahlt hat, aus dem Verwendungszweck aber nicht ersichtlich ist, welche, und man etwas herumprobieren muß. Das sind v.A. Fragen des Interfacedesigns.
Von Martin Helmling vor mehr als 8 Jahren aktualisiert
Der Commit 92e2fb59 löst das Problem nicht, dass ganz bezahlte Rechnungen (open_amount=0) nicht mehr rückgebucht werden können.
Jedoch wird bei einer Banktransaktion, die mehrere Rechnungen betrifft, eine Überzahlung nicht wie bisher einfach weggeworfen,
sondern die letzte (oder einzigste) Rechnung einer Transaktion wird überbezahlt.
Sorry das mit dem "fix Redmine #192" war falsch.
Von Moritz Bunkus vor mehr als 8 Jahren aktualisiert
- Status wurde von Neu zu Gelöst geändert
Ich habe hierzu mehrere Commits gemacht, die das Problem erst mal
deutlich sauberer machen, als es vorher war. Ich schließe diesen Bug
daher.
Mein Ziele waren, die Maske deutlich widerstandsfähiger gegenüber
Fehlbedienungen sowie der BenutzerIn transparenter zu machen, was bei
Problemen passiert.
Weitere Verbesserungen sind natürlich OK, z.B. dass in der Maske
bereits festgelegt werden kann, welche Rechnungen wie unterzahlt
verbucht werden sollen, wenn eine Zahlung eben nicht gleich der Summe
der offenen Beträge ist.
- 66d468b093e7c4510722f22b4a0c069cb95e6117 »Bankauszug verbuchen: Warnungen/Fehler anzeigen; pro Zeile eine DB-Transaktion«
Hier wird zum Einen eine Datenbank-Transaktion eingeführt, die
verhindern, dass grobe Fehler mit inkonsistentem Datenbankzustand
belohnt werden.
Weiterhin wird hier der Grundstein dafür gelegt, dass während der
Bearbeitung auftretende Fehler und Warnungen der BenutzerIn
nachträglich in Tabellenform übersichtlich angezeigt werden, anstatt
die Funktion gleich komplett abzubrechen (bei Exceptions) oder nur
unübersichtlich angzeigt werden (Warnungen als Flash).
Das Datenbank-Transkations-Verhalten ist wie folgt:
1. Bei einer Ausnahme: Rollback und Anzeige in Tabelle als Fehler
2. Bei einem Fehler: Rollback und Anzeige in Tabelle als Fehler
3. Bei einer Warwnung: Commit und Anzeige in Tabelle als Warnung
4. Wenn kein Problem auftrat: Commit, keine Anzeige in Tabelle
Wenn in keiner der Zahlungen Warnungen oder Fehler auftreten, so wird
die Fehlertabelle auch nicht angezeigt.
- 0631432e58e8c70312adae94db3e41dd36bc6e30 »Bankauszug: Transaktionsrichtung mit Belegrichtung abgleichen«
Es war möglich, einer Transaktion beliebige Einkaufs- und
Verkaufsrechnungen zuzuweisen. Somit war es problemlos machbar, einer
erhaltenen Zahlung eine Verkaufsrechnung zuzuweisen.
Mit diesem Commit werden falsche Zahlungsrichtungen abgewiesen und gar
nicht durchgeführt. Zugelassen ist: erhaltene Zahlungen mit
Verkaufsrechnungen und stornierten Einkaufsrechnungen; gemachte
Zahlungen mit Einkaufsrechnungen und stornierten Verkaufsrechnungen.
»Abgewiesen« heißt: die Zahlung wird als Fehler in der Fehlertabelle
angezeigt und nicht verbucht.
- 0c93bf2085b5cca69cb831fd90a50ed0ec6b8601 »Bankauszug: Unterzahlung mehrerer Rechnungen verhindern«
Wenn mehrere Rechnungen ausgewählt werden, so verteilt der Algorithmus
schlicht den Betrag der Überweisungen auf die Rechnungen in der
Reihenfolge, in der die Rechnungen ausgewählt wurden. Dabei wird so
lange der volle offene Betrag bezahlt wie möglich, der Rest kommt auf
die folgende Rechnung.
Allerdings ist für das Programm nicht ersichtlich, welche Anteile
welcher Rechnungen des Kunden/Lieferanten tatsächlich damit beglichen
wurden.
Also muss verhindert werden, dass das passiert; eine Warnung genügt
nicht. Die Zahlung wird daher als Fehler in der Fehlertabelle
angezeigt und nicht verbucht.
Ist nur eine Rechnung zugewiesen, so bleiben Unterzahlungen problemlos
möglich und auch sinnvoll (z.B. Abschlagszahlungen, regelmäßige
Teilzahlungen, Irrtümer).
Dieser Commit kann nachträglich natürlich noch entschärft werden, wenn
z.B. die Masken so erweitert werden, dass die BenutzerIn im Vorfeld
genau steuern kann, welche Rechnungen unterzahlt werden sollen.
- 20392548f2e8ed92478542893df9852d6987e031 »Bankeinzug: bei Überzahlung eine Warnung ausgeben«
Eine Überzahlung ist oftmals OK oder unvermeidbar, sollte aber von der
BenutzerIn begutachtet werden. Daher wird die Zahlung durchaus
verbucht und im Anschluss an das Verbuchen eine Warnung in besagter
Tabelle angezeigt, aus der die BenutzerIn die Möglichkeit hat, die
Rechnungen direkt anzusteuern.
Von Moritz Bunkus vor mehr als 8 Jahren aktualisiert
Moritz Bunkus schrieb:
…
- 0631432e58e8c70312adae94db3e41dd36bc6e30 »Bankauszug: Transaktionsrichtung mit Belegrichtung abgleichen«
…
Mit diesem Commit werden falsche Zahlungsrichtungen abgewiesen und gar
nicht durchgeführt. Zugelassen ist: erhaltene Zahlungen mit
Verkaufsrechnungen und stornierten Einkaufsrechnungen; gemachte
Zahlungen mit Einkaufsrechnungen und stornierten Verkaufsrechnungen.
Ist natürlich Quark: ich meine hier nicht die Stornos, sondern die
Gutschriften. Letztlich basiert der Check aber nicht auf den
Belegtypen, sondern auf dem Vorzeichen der Zahlungen:
- Bei eingehenden Zahlungen sind nur Verkaufsbelege mit positiver
Summe und Einkaufsbelege mit negativer Summe zugelassen.
- Bei ausgehenden Zahlungen sind nur Verkaufsbelege mit negativer
Summe und Einkaufsbelege mit positiver Summe zugelassen.