Abweichenden Zahlungsweg bei Zusatzbeträgen

[lenilsas]

Jetz kann bei Zusatzbeträgen ein abweichender Zahlungsweg festgelegt werden. Wenn Standard ausgewählt ist wird der beim Mitglied hinterlege Zahlungsweg verwendet

Resolves #420, resolves #421

[JohannMaierhofer]

In der Lasche Zusatzbeträge in den Mitglied Details fehlt die Spalte für Zahlungsweg.

[JohannMaierhofer]

Sollte der Zahlungsweg auch in den Zusatzbetrag Vorlagen gespeichert und angezeigt werden?

[tolot27]

Sollte der Zahlungsweg auch in den Zusatzbetrag Vorlagen gespeichert und angezeigt werden?

Ja, dass wäre gut. So habe ich es auch in #420 vorgeschlagen.

[lenilsas]

Sollte der Zahlungsweg auch in den Zusatzbetrag Vorlagen gespeichert und angezeigt werden?

Ich dachte, dass das nicht nötig ist. wenn ihr meint mache ich das aber noch

[lenilsas]

Habe alle Kommentare eingearbeitet

[JohannMaierhofer]

Ich sehe gerade, dass es in der Zusatzbeträge Tabelle im Mitglied in der Überschrift eine Kleinschreibung gibt.
Das "nächste..." und "letzte..." sollte groß geschrieben werden.
Kannst du das noch machen weil die Datei sowieso geändert wurde.

[lenilsas]

Habe Standard zum Zahlungsweg hinzugefügt so dass er auch in den Listen angezeigt wird

[JohannMaierhofer]

Habe Standard zum Zahlungsweg hinzugefügt so dass er auch in den Listen angezeigt wird

Super, danke

[JohannMaierhofer]

Jetzt hätte ich noch einen Vorschlag. Könntest du in ZusatzbetragImpl den insertCheck erweitern so dass er bei Lastschrift prüft ob das Mitglied eine IBAN gesetzt hat und ein Mandat Datum. Da könnte man den entsprechenden Teil aus MitgliedImpl übernehmen.

Ich finde es besser das hier schon zu prüfen als dass es später zur Fehlermeldung im Abrechnungslauf kommt.

Eigentlich könnte man dann noch beim MitgliedImpl prüfen ob es einen Zusatzbeitrag mit Basislastschrift hat. Dann müsste man auch den Check machen. Aber vielleicht ist das etwas zuviel. Dann läuft man halt in die Meldung beim Abrechnungslauf.

[lenilsas]

Hab den Test eingebaut

[JohannMaierhofer]

Hab den Test eingebaut

Wie ist das denn bei Vollzahler Konfiguration? Wird dann bei Zusatzbeträgen auch das Konto des Vollzahler genommen? Wenn ja müsste der Check hier noch erweitert werden.

[lenilsas]

Wie ist das denn bei Vollzahler Konfiguration? Wird dann bei Zusatzbeträgen auch das Konto des Vollzahler genommen? Wenn ja müsste der Check hier noch erweitert werden.

Ja, das stimmt. Es nur die Frage ob das wirklich so sein soll, dass auch bei abweichendem Zahlungsweg der Vollzahler zahlt, oder soll es in dem Fall das mitglied selbst sein?

[tolot27]

Wie ist das denn bei Vollzahler Konfiguration? Wird dann bei Zusatzbeträgen auch das Konto des Vollzahler genommen? Wenn ja müsste der Check hier noch erweitert werden.

Ja, das stimmt. Es nur die Frage ob das wirklich so sein soll, dass auch bei abweichendem Zahlungsweg der Vollzahler zahlt, oder soll es in dem Fall das mitglied selbst sein?

Wenn bei einem Mitglied ein Vollzahler konfiguriert ist, sollte das meiner Meinung nach für alle Zahlungen gelten. Bisher gibt es da ja noch keine Differenzierung und wenn ich es richtig sehe, läuft das bis jetzt auch schon so.
Wenn das gewollt ist, wäre das vielleicht ein anderer PR. Ursprünglich ging es bei dem PR ja um den Zahlungsweg und nicht wer zahlt - obgleich das natürlich zusammenhängt.

[lenilsas]

Test hinzugefügt und Merge Konflikte behoben

[JohannMaierhofer]

Jetzt habe ich noch einen Kommentar zu RechnungControl wenn das damit gemerged ist.
In RechnungControl Zeile 309 wird der Filter ohneabbucher behandelt. Er fragt nach dem Zahlungsweg des Mitglieds. Hier müsste bei Vollzahler aber dieser geprüft werden und bei Zusatzbeträgen jetzt auch was dort steht. Allerdings kann sich das dort ja auch seit der Erstellung der Rechnung geändert haben.
Man müsste hier eigentlich den Zahlungsweg der Sollbuchungen der Rechnung prüfen, also über die Sollbuchungen iterieren.
ohneabbucher wäre dann wenn mindestens eine Sollbuchungen nicht Basislastschrift ist.

Evtl. wäre es einfacher man würde bei Rechnungen nur Sollbuchungen zusammen fassen die die gleiche Zahlungsart haben. Dann könnte man die Zahlungsart in der Rechnung speichern und hat es hier mit dem Filter einfacher.
Das würde vielleicht sowieso Sinn machen. Oft schickt man eine Rechnung oder Mahnung nur für Rechnungen bei denen nicht per Lastschrift bezahlt wird. Wenn in der Rechnung aber Lastschrift und Überweisung gemischt ist bekommt man beides gemahnt.

PS: Es wäre vielleicht schön wenn man im Rechnung View bei klick auf eine Sollbuchung zur Sollbuchung springen könnte.

Der Kommentar wäre auch etwas für einen eigenen PR, siehe #468

[tolot27]

Ich teste gerade das Feature. Sieht von der Umsetzung und Visualisierung ganz gut aus. Was jedoch nicht wie erwartet funktioniert, ist die kompakte Abbuchung wenn der Zahlungsweg auf Überweisung steht. Dann werden die Zusatzbeträge nicht zu einer Summe zusammengefasst, zumindest keine negativen und positiven (bei positiver Summe).
Da ich die E-Mails mit der Zahlungsaufforderung immer vor dem Abrechnungslauf versende und da die Überweisungssumme ausgegeben wird, haben die Leute schon überwiesen. Die beim Abrechnungslauf gebildeten mehreren Sollbuchungen lassen sich dann nicht automatisch der einen Überweisung zuordnen.
Hier wäre es schön, wenn "kompakte Abbuchung" funktionieren würde. Das könnte jedoch auch in einem separaten PR gemacht werden, da dieser eigentlich seinen gewünschten Zweck erfüllt. Dann müsste man vermutlich auch "kompakte Abbuchung/Überweisung" oder besser "kompakte Sollbuchung" schreiben.

[lenilsas]

Hier wäre es schön, wenn "kompakte Abbuchung" funktionieren würde. Das könnte jedoch auch in einem separaten PR gemacht werden, da dieser eigentlich seinen gewünschten Zweck erfüllt. Dann müsste man vermutlich auch "kompakte Abbuchung/Überweisung" oder besser "kompakte Sollbuchung" schreiben.

Das ist nur eine kompakte Abbuchung, das heißt es wird eine Lastschrift für mehrere Sollbuchungen erstellt. Daher bleiben bei jedem Zahlungsweg mehrere Sollbuchungen bestehen. Ich würde empfehlen erst denAbrechnungslauf durchzuführen, anschließend die Rechnungen erstellen und versenden (in der Nigthly Version ist hier das Vorgehen anders als bisher)
Hierfür würde eher ein Featur benötigt um einer Buchung mehrere Sollbuchungen zuzuordnen.
In diesem PR wurde an dem Vorgehen nichts geändert.

[tolot27]

Ich würde empfehlen erst den Abrechnungslauf durchzuführen, anschließend die Rechnungen erstellen und versenden.

Das werde ich mir ansehen. Bisher habe ich nicht mit Rechnungen gearbeitet, da man da (bisher) immer ein PDF hatte, ich jedoch direkt im Nachrichtentext die Informationen haben wollte. Aber das ist OT hier.

Also von mir aus kann der PR merged werden.

[JohannMaierhofer]

Also von mir aus an der PR merged werden.

Dann musst du nur noch das Review approven. Dann kann man mergen. Es geht nur mit zwei Appovals.

Ich sehe gerade, dass du kein Mitglied bist, dann kannst du das wohl nicht.

Vielleicht solltest du ein Issue mit der Bitte um Aufnahme stellen.

[tolot27]

Also von mir aus an der PR merged werden.
Vielleicht solltest du ein Issue mit der Bitte um Aufnahme stellen.

Kann ich machen. Allerdings kenne ich das bei anderen Projekt so, dass man dafür erstmal bisl was contributed haben muss und auch qualifizierte Reviews gemacht haben muss, bevor man die approval permission bekommt. Wenn ihr das anders handhabt, dann gern (#479).

[tolot27]

Da ich schon alles getestet habe und es soweit funktioniert, habe ich mich nun auf den Code Review beschränkt. Teilweise hast du Code-Formattierungen korrigiert, oft jedoch bei ifs selbst keine angewendet. Mir scheint, dass bei dir der code formatter nicht automatisch aktiv ist.
Das sieht jetzt irgendwie pingelig aus. Allerdings bräuchten wir sonst die Diskussion um Code Style (#384) nicht führen.

[lenilsas]

Ich habe die Formatierung angepasst.
Die {} bei ifs sind nicht im Formatter enthalten, ich habe jetzt die "Clean Up" Funktion über den Code laufen lassen, das hat die fehlenden {} hinzugefügt, es sieht dadurch nach vielen Änderungen aus, ist alles aber nur Formatierung.

[tolot27]

Für mich passt es so. Ich schlage jedoch vor, dass wir in Zukunft Formatierungen nur bei den geänderten Kodezeilen durchführen (Menüeintrag "Format Element"). Ansonsten könnte es viel schneller zu Merge Conflicts kommen, wenn jeder von uns bei seinen verschiedenen Branches ein Rebase macht. Das war auch meine ursprüngliche Intention. Ich wollte nicht gleich die ganzen Dateien "korrekt" formatiert sehen.