feature/automatische verbuchung von steuern #65
Conversation
…teuer gebucht werden soll, kann jetzt angegeben werden
- zusätzlich gibt es nun eine DependecyId in der Buchung, welche abhängige Buchungen in einer Splitbuchung anzeigt (über die DB Id ist dies nicht möglich, weil der erst generiert wird, wenn alles gespeichert wird)
- Verwendungszweck ohne Bachtung der Groß/Kleinschreibung - Ignorieren zusaetzliche Felder von Bankseite am Verwendungszweck (IBAN) - Stichtag im Abrechnungslauf anstatt Datum des Mitgliedskontos zur Zeitraumselektion benutzen
…von-steuern' into feature/automatische-verbuchung-von-steuern
…sche-verbuchung-von-steuern
|
Mir persönlich sind das echt zu viele Änderungen auf einmal. Ich kann hier nicht wirklich erkennen, was die alle bewirken. Kleinere PRs lassen sich deutlich besser reviewen und können dadurch auch einfacher in den Master-Branch übernommen werden. |
|
Kann ich verstehen. Das Problem bei Neuerungen/features ist aber oftmals, dass viel neuer Code dazukommt. Schließlich soll der Code auch keine Konflikte auslösen und lauffähig sein. Wie wäre dein Lösungsansatz hieraus kleinere PR zu erstellen? |
|
Kleinere PR: Ein PR sollte nur genau ein Feature enthalten. Laut den Commit-Kommentaren (siehe oben) sind hier aber eine ganze Reihe von Änderungen zusammengefasst:
|
|
Wenn gewünscht trenne ich den Branch von VinRud und Acrux-dev in zwei separate PR. Die commits werden aber nicht kleiner. Weiterhin werden dann zwei Update Dateien (Update0420 und Update0421) benötigt, welche in Abhängigkeit zueinander stehen. |
|
Lauffähige PRs auf jeden Fall. @NicoB77 Kannst du hier helfen? Ich kann den PR nicht überblicken - da stecke ich nicht tief genug im Code von JVerein drin. |
|
Auf den ersten Blick haben die beiden Branches keine Abhängigkeiten, daher wäre es gut, den PR aufzuteilen. Wegen der Datenbankupdates würde ich jeden PR so anlegen, dass er direkt gemerged werden kann (d.h. immer mit der nächsten Nummer, aktuell Update0419) und erst als letzten Schritt nach Approval gegebenenfalls den Konflikt durch Umbenennen der Update-Datei lösen. Dann muss keine Reihenfolge eingehalten werden, und es kann nicht versehentlich ein PR mit fehlerhaftem Datenbankupdate gemerged werden. Spätestens nach dem Merge sollte auch das Handbuch angepasst werden. Ich habe frühestens am Wochenende Zeit, mir das anzusehen. |
|
Verstehe. Dann mache ich das mal. |
In diesem PR sind die Steuer Erweiterungen von VinRud jverein#61 und Acrux-dev Acrux-dev@16115e7 enthalten.
Wegen der DB Updates ist dieses PR abhängig von #58 und sollte anschließend implementiert werden. (PR #58 = Update0419 | PR #64 = Update0420)