Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Leistungsdatum #496

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

mbmueller
Copy link

Closes #472

In Vorbereitung für #434 habe ich ein zusätzliches Leistungsdatum eingeführt. Dieses Feature kann über die Einstellungen aktiviert werden.
Standardmäßig ist das Leistungsdatum identisch zum Buchungsdatum und wird auch immer geändert, wenn man das Buchungsdatum ändert. Erst sobald ein abweichender Wert gesetzt wird, wird das Leistungsdatum nicht mehr mit verändert.
Weißt man eine Sollbuchung zu, wird ebenfalls das Leistungsdatum geändert, sofern es nicht vorher schon manuell oder durch eine Sollbuchung geändert wurde.
Ebenfalls neu ist, dass das Datum einer neuen Sollbuchung automatisch auf das Leistungsdatum der Buchung gesetzt wird.
So dass standardmäßig Leistungsdatum und Sollbuchung konsistent sind, sofern der User sich nicht aktiv dafür entscheidet hier abweichende Werte zu setzen.

Da standardmäßig Datum und Leistungsdatum gekoppelt sind, können die Felder im Hintergrund beim Zugriff auf die Daten synonym verwendet werden, was teilweise eine Aufteilung in Ausführungspfade (abhängig davon ob die Einstellung gesetzt ist) umgeht.

@mbmueller mbmueller enabled auto-merge (squash) November 26, 2024 20:36
@mbmueller mbmueller added the enhancement New feature or request label Nov 26, 2024
@JohannMaierhofer
Copy link

Also ich finde das schon ein Problem dass man jetzt die ganzen Dateien umformatiert und auch an Stellen wo man nichts geändert hat. Wie soll man das reviewen, ich finde aus den vielen Änderungen nicht mehr die Stellen wo es sich nicht um Umformatierung handelt.
Auch jetzt überall die Namen zu ändern von Variablen die schon da sind finde ich auch nicht gut. Wenn man da nichts ändert braucht man die doch nicht umzubenenen. Ich finde auch oft die kurzen Namen wesentlich besser zu lesen als wenn man dann Namen mit 20 Zeichen hat bei denen es schwer wird diese von ähnlichen zu unterscheiden.

@JohannMaierhofer
Copy link

Wenn man jetzt überall den Formatter anwenden will, dann sollte man das in einem eigenen PR machen der nur formatiert und dann gleich für alle Dateien. Ansonsten nur die geänderten Stellen formatieren.

@mbmueller mbmueller force-pushed the feature/leistungsdatum branch from f140ca1 to 24e1f3f Compare November 27, 2024 22:03
@mbmueller
Copy link
Author

Also ich finde das schon ein Problem dass man jetzt die ganzen Dateien umformatiert und auch an Stellen wo man nichts geändert hat. Wie soll man das reviewen, ich finde aus den vielen Änderungen nicht mehr die Stellen wo es sich nicht um Umformatierung handelt. Auch jetzt überall die Namen zu ändern von Variablen die schon da sind finde ich auch nicht gut. Wenn man da nichts ändert braucht man die doch nicht umzubenenen. Ich finde auch oft die kurzen Namen wesentlich besser zu lesen als wenn man dann Namen mit 20 Zeichen hat bei denen es schwer wird diese von ähnlichen zu unterscheiden.

Da hast du recht. Da hatte ich den Formatter wohl zu aggresiv eingestellt (habe jetzt OnSave deaktiviert). Habe außerdem jetzt alle Formatting Changes verworfen, das hat zwar die Git Historie zerstört, kann jetzt aber einfacher reviewed werden.

@JohannMaierhofer
Copy link

Könntest du mir bitte den Hintergrund für dieses Feature beschreiben. Warum braucht man ein Leistungsdatum wenn es von den steuerlichen Vorgaben abweicht. Für das Finanzamt und auch vor dem Verein sollte man die steurlich korrekte Abrechnung vorlegen. Für was ist dann das manipulierte Buchungsklassensaldo gut.

Ich hätte schon einmal ein solches Feature gebraucht als meine Bank bei einem Darlehen die Lastschrift erst am 2. Januar des Folgejahres abgebucht hat. Steuertechnisch gehörten die Zinsen dieser Buchung aber zum vorangegangen Geschäftjahr. Ich habe dann das Datum der Buchung auf den 31.12 gesetzt. Mit deinem Feature könnte man hierfür das Leistungsdatum nehmen. Das würde für mich Sinn machen.
Für diesen Fall fehlt aber einiges in der Implementierung. Dann muss auch das Jahressaldo, Jahresabschluss, Abschreibung bei Anlagenkonten, einfach alles auf das Leistungsdatum umgestellt werden.

So wie ich das aber jetzt verstehe ist das nicht Sinn des Features. Ich könnte es also bei einem echten Bedarf nicht nutzen. Darum scheint mir das eigentlich eine reine Spielerei zu sein und da bin ich mir nicht sicher ob so etwas in unsere Software wirklich gehört. Das könnte zu großer Verwirrung füheren wie in meinem echten Anwendungsfall.

@JohannMaierhofer
Copy link

Ich habe hier noch etwas über das Zufluss und Abfluss Prinzip sowie die 10 Tage Regel gefunden:
https://www.vibss.de/vereinsmanagement/steuern/buchfuehrung-im-sportverein/kontenplan-und-gewinnermittlung/das-zufluss-/abfluss-prinzip

Ich denke dafür wäre das Feature hier zu gebrauchen. Aber eben müsste dann die ganze SW auf dieses Datum umgestellt werden und nicht nur das Buchungsklassensaldo.

@JohannMaierhofer
Copy link

Ich habe gerade eine Idee wie man das steuerkonform sehr einfach lösen kann. Ich würde einfach das bestehende Datum als Leistungsdatum betrachten. Das neue Datum heißt dann Buchungsdatum. Dann kann man bei Bedarf das Datum anpassen. Das Buchungsdatum bleibt beim Datum der Buchung laut Kontoauszug.
Dann funktioniert die ganze SW ohne Änderung weiter. Natürlich müsste bei den Reports mit Buchungen beide Werte ausgegeben werden damit ein Kassenpüfer auch den richtigen Beleg findet.
Das oben beschriebene Überschreiben des Datum in einer Sollbuchung dürfte, denke ich, nicht passieren, da ja auch die Manipulation des Datum in der Buchung nur innerhalb von 10 Tagen um das Geschäftsjahres Ende erlaubt ist. Ansonsten muss dass Datum in der Sollbuchung ja nicht den Datum der Buchung entsprechen.
Ein automatisches setzen eines Datum würde ich sowieso nur machen wenn noch keines gesetzt ist.

@lenilsas
Copy link

lenilsas commented Dec 2, 2024

Ich denke, man sollte solche Buchungen am Jahreswechsel zum richtigen Datum buchen auf ein Geldtransit Konto und eine weitere Buchung vom Geldtransit Konto im Jahr in das die Buchung gehört. So mache ich das immer und ich glaube, dass das auch der normale Weg ist.

Nur in den Fall, dass man Umsatzsteuerpflichtig ist und der Sollbesteuerung unterliegt bräuchte man ein Rechnungsdatum in der Buchung, aber ich denke das sollte für die wenigsten Vereine zutreffen. Und dann wäre auch eine Doppelte Buchhaltung mit Debitoren und Kreditoren Konten besser geeignet als die "einfache" Buchführung von JVerein.

@JohannMaierhofer
Copy link

Das klingt vernünftig. Dann brauchen wir das hier so nicht.

@mbmueller
Copy link
Author

Könntest du mir bitte den Hintergrund für dieses Feature beschreiben. Warum braucht man ein Leistungsdatum wenn es von den steuerlichen Vorgaben abweicht. Für das Finanzamt und auch vor dem Verein sollte man die steurlich korrekte Abrechnung vorlegen. Für was ist dann das manipulierte Buchungsklassensaldo gut.

Der Gedanke war, bspw. wenn ein Mitglied seinen Jahresbeitrag bereits im Dezember bezahlt, ist dieser ja trotzdem dem Jahreshaushalt des nächsten Jahres zuzuordnen. Das das ganze nur in einem Rahmen von 10-Tagen passieren darf, war mir nicht bewusst. Aber dann wäre genau das der Anwendungsfall.

Bis lang sind tatsächlich noch keine Auswertungsmöglichkeiten vorhanden. Das Feature war ja auch wie gesagt eine Vorbereitung für #434. Wollte das nur in einen eigenen PR machen, damit wir genau solche Anmerkungen getrennt vom Budgeting haben.
Natürlich kann ich zusätzlich auch noch implementieren, dass man bei den Salden auswählen kann, ob die nach Buchungs- oder Leistungsdatum sortiert sind.

@mbmueller
Copy link
Author

Ich denke, man sollte solche Buchungen am Jahreswechsel zum richtigen Datum buchen auf ein Geldtransit Konto und eine weitere Buchung vom Geldtransit Konto im Jahr in das die Buchung gehört. So mache ich das immer und ich glaube, dass das auch der normale Weg ist.

Nur in den Fall, dass man Umsatzsteuerpflichtig ist und der Sollbesteuerung unterliegt bräuchte man ein Rechnungsdatum in der Buchung, aber ich denke das sollte für die wenigsten Vereine zutreffen. Und dann wäre auch eine Doppelte Buchhaltung mit Debitoren und Kreditoren Konten besser geeignet als die "einfache" Buchführung von JVerein.

Wie wäre dann der Workflow? Verstehe ich das, so richtig:

  1. Überweisung kommt an
  2. Ich erzeuge eine Umbuchung auf das Transitkonto mit dem Datum der Überweisung
  3. Ich erzeuge eine Umbuchung vom Transitkonto mit dem "Leistungsdatum"

Dadurch wäre ja aber dann das Transitkonto zum Jahreswechsel auch nicht auf 0, womit dieses dann in die Salden mit einfließen würde.

@JohannMaierhofer
Copy link

Wie wäre dann der Workflow? Verstehe ich das, so richtig:

  1. Überweisung kommt an
  2. Ich erzeuge eine Umbuchung auf das Transitkonto mit dem Datum der Überweisung
  3. Ich erzeuge eine Umbuchung vom Transitkonto mit dem "Leistungsdatum"

Ja, so habe ich das jetzt verstanden.

Dadurch wäre ja aber dann das Transitkonto zum Jahreswechsel auch nicht auf 0, womit dieses dann in die Salden mit einfließen würde.

Das wäre aber doch auch richtig. Durch das Verschieben der Buchung ist ja eigentlich auch das Saldo auf dem Girokonto nicht richtig. Das wird durch das Transitkonto ausgeglichen.

Es muss ja das Ergebnis des Buchungsklassensaldo mit dem Saldo Delta der Konten übereinstimmen.

@lenilsas
Copy link

lenilsas commented Dec 2, 2024

Genau so habe ich das gemeint. Das ist jetzt "nur" für den 10Tages-Zeitraum am Jahresende/Anfang von wiederkehrenden Zahlungen gedacht.
So Wie ich es verstanden haben, wolltest du in dem Feature für die Planung auch Buchungen ins "richtige" Jahr verschieben die außerhalb des 10-Tageszeitraums getätigt wurden. Ich denke, das wird man nie ganz hinbekommen, da ja zB. auch was angeschafft werden kann was erst für eine Veranstaltung o.ä. in einem Jahr benötigt wird. Meiner Meinung nach muss man damit leben, dass nicht alle Buchungen im "richtigen" Jahr gebucht sind. Mann könnte die Buchungen auch zu Projekten zusammenfassen, diese sind ja auch Jahresübergreifend möglich.

@mbmueller
Copy link
Author

So Wie ich es verstanden haben, wolltest du in dem Feature für die Planung auch Buchungen ins "richtige" Jahr verschieben die außerhalb des 10-Tageszeitraums getätigt wurden. Ich denke, das wird man nie ganz hinbekommen, da ja zB. auch was angeschafft werden kann was erst für eine Veranstaltung o.ä. in einem Jahr benötigt wird.

Genau, Hauptanwendungsfall wäre (zumindest bei uns) zwar Ausgaben um den Jahreswechsel, aber auch bspw. Unterkünfte für Februar, die aber schon im August gebucht und gezahlt werden müssen.

Es muss ja das Ergebnis des Buchungsklassensaldo mit dem Saldo Delta der Konten übereinstimmen.

Damit hast du zwar prinzipiell recht, wenn ich aber meine Buchhaltung dem Finanzamt bzw. der Mitgliederversammlung vorlege, dann sollten die Salden ja die Buchungen widerspiegeln, die auch diesem Jahr wirtschaftlich zugeordnet sind.

@mbmueller
Copy link
Author

Damit hast du zwar prinzipiell recht, wenn ich aber meine Buchhaltung dem Finanzamt bzw. der Mitgliederversammlung vorlege, dann sollten die Salden ja die Buchungen widerspiegeln, die auch diesem Jahr wirtschaftlich zugeordnet sind.

Das war der Hauptgedanke dabei, zwei getrennte Daten einzuführen, damit das Buchungssaldo immer mit dem Konto übereinstimmt, während man andererseits auch sehen kann, welche Buchungen in welches GJ gehören.

@JohannMaierhofer
Copy link

JohannMaierhofer commented Dec 2, 2024

Damit hast du zwar prinzipiell recht, wenn ich aber meine Buchhaltung dem Finanzamt bzw. der Mitgliederversammlung vorlege, dann sollten die Salden ja die Buchungen widerspiegeln, die auch diesem Jahr wirtschaftlich zugeordnet sind.

Eben nicht, wie aus dem Text meines Links hervorgeht gilt finanztechnisch das Zuflussprinzip. Es ist so zu buchen wie das Geld geflossen ist. Wenn du also im August bezahlst gehört das in das Jahr in dem der August liegt.
Die Ausnahme davon gibt es nur für 10 Tage um das Geschäftsjahres Ende.

@vinjardin
Copy link

Eben nicht, wie aus dem Text meines Links hervorgeht gilt finanztechnisch das Zuflussprinzip. Es ist so zu buchen wie das Geld geflossen ist. Wenn du also im August bezahlst gehört das in das Jahr in dem der August liegt.
Die Ausnahme davon gibt es nur für 10 Tage um das Geschäftsjahres Ende.

Das sehe ich ganz genauso. Für das Finanzamt, den Kassenbericht für die Kassenprüfer usw. .
Allerdings wäre das Leistungsdatum (oder wie auch immer man es nennen möchte) mit der damit verbundenen Haushaltsplanung der m.E. einfachste Weg den Haushalt eben vernünftig zu planen und dann auch im Folgejahr zu kontrollieren. Auf Jahreshauptversammlungen handhaben wir es so, dass natürlich der Kassenbericht nach oben genannten Kriterien mit Kassenprüfung vorgestellt wird. Dieser ist aber auf Grund der oben genannte Beispiele für verschobene Buchungen was den wirtschaftlichen Erfolg angeht wenig aussagekräftig. Auch kann anhand dessen schwer kontrolliert werden, inwiefern sich der Vorstand an seine Planung gehalten hat.
Daher fände ich die vorgestellte Vorgehensweise mit Leistungsdatum und Haushaltsplanung (vollkommen losgelöst von den bisherigen Auswertungsmöglichkeiten) schon sinnvoll.

@mbmueller
Copy link
Author

mbmueller commented Dec 2, 2024

Die Ausnahme davon gibt es nur für 10 Tage um das Geschäftsjahres Ende.

Ich habe mich mit meinem letzten Satz auch hierauf bezogen. Trotzdem gibt es ja noch überhaupt keine Möglichkeit, Buchungen in ein anderes Haushaltsjahr ohne das Datum (das aber mit dem Datum des Kontoauszugs übereinstimmen sollte) zu schieben (auch nicht innerhalb der 10-Tage) sodass diese in den Salden des Vorjahres gar nicht mehr auftauchen.
Sehe es aber ähnlich wie @vinjardin, deswegen waren in diesem Feature auch noch keine Auswertungsmöglichkeiten implementiert, da diese über die Haushaltsplanung erfolgen.

@JohannMaierhofer
Copy link

JohannMaierhofer commented Dec 2, 2024

Das mit den 10 Tagen denke ich ist geklärt wie man das macht.

Euere Argumentation verstehe ich trotzdem nicht. Wenn also in einem Jahr x ein Fest ist und das ein Jahr vorher bezahlt werden muss, dann muss ich in meiner Haushaltsplanung dafür sorgen dass im Jahr vorher das Geld dafür da ist. Darum muss ich diese Ausgabe auch für das Jahr vorher in meiner Haushaltsplanug einplanen und nicht erst für ein Jahr später. Es ist doch dann wohl auch richtig dieses dann im dem Jahr auch zu verbuchen.
Und wenn dann jemand überprüfen will ob man sich an die Planung gehalten hat passt das dann doch zusammen.

Wenn jetzt also ein Feature zur Haushaltsplanung gemacht wird gehe ich davon aus, dass man so für die Folgejahre plant wie es dann auch in der Einnahmen/Ausgaben Abrechnung später ausschaut. Dann kann man den Plan mit dem Ist vergleichen. Da braucht man kein Leistungsdatum dafür.

Und wenn man wirklich später sehen will ob man sich z.B. beim Fest an das Budget gehalten hat, dann kann man das aus dem manipulierten Buchungsklassensaldo auch nicht sehen. Da wäre es dann besser man würde für das Fest ein Projekt anlegen und alle Ausgaben und Einnahmen darauf buchen. Dafür könnte man dann auch eine Projekt bezogene Haushaltsplanung machen.

@vinjardin
Copy link

vinjardin commented Dec 2, 2024

Bei deinem Beispiel würde ich mitgehen wenn man dies so plant und würde ich auch wie du sagst über ein Projekt auswerten. Es geht mir aber um alle Posten des Haushaltes. Anderes Beispiel:
Für das kommende Jahr kann ich die Hallennutzungsgebühren abschätzen die zu zahlen sein werden. Ich plane diese also für das folgende Jahr haushaltstechnisch ein. Diese Gebühren werden beispielsweise halbjährlich von der Stadt abgerechnet. Oft - aber nicht immer - erhalten wir die Rechnung für das 2. Halbjahr aber erst im Februar des darauffolgenden Jahres. Somit sind die Ausgaben in meinem Kassensaldo geringer als erwartet und es scheint als hätte ich gut gewirtschaftet. Die geplanten Gelder sind natürlich noch auf dem Konto vorhanden und fließen dann im Februar ab.
Für das Finanzamt und Kassenprüfung alles egal. Für mich der ich aber pro Jahr sehen möchte inwiefern meine Planung mit den tatsächlichen Posten übereinstimmt problematisch.
Soll heißen für Posten die unerwartet und nicht planbar im "falschen" Haushaltsjahr auftauchen wäre das Feature gedacht.

@JohannMaierhofer
Copy link

Aber so richtig hilft dir das Leistungsdatum Feature dann ja auch nicht. Wenn du am Ende des Jahres sehen willst wie du gewirtschaftet hast, dann weißt du ja immer noch nicht wie teuer die Rechnung im Februar wird. Du musst ja dann bis Februar warten bis die Abbuchung auf dem Konto ist um dann das Leistungsdatum in der Buchung zu setzten.

@vinjardin
Copy link

vinjardin commented Dec 2, 2024

Das ist korrekt, und ließe sich dann nur über das mögliche besagte Haushaltsplanungstool als noch ausstehende Ausgabe oder ähnliches (@mbmueller ?) umsetzen, bis es dann tatsächlich zu der Buchung kommt.
Also wenn man so will macht es nur in dem Zusammenhang Sinn, um über den Jahresverlauf auch immer überprüfen zu können ob man sich quasi auf Sollkurs befindet.
Nur im Februar / März die Endergebnisse wären allerdings erstmal für eine mögliche Übersicht bezüglich Jahreshauptversammlung dann auch ein cooler Schritt.

@mbmueller
Copy link
Author

Das ist korrekt, und ließe sich dann nur über das mögliche besagte Haushaltsplanungstool als noch ausstehende Ausgabe oder ähnliches (@mbmueller ?) umsetzen, bis es dann tatsächlich zu der Buchung kommt.

Das hatte ich so bislang nicht geplant. Sondern ich hätte das dann alles über die Leistungsdaten gemacht. Ob und wie das Feature dann genau genutzt wird muss natürlich jeder Kassenwart für sich selbst entscheiden. Und das Leistungsdatum war ja eben genau dafür gedacht, dass für Kassenprüfung und Finanzamt die Buchungen mit den tatsächlichen Zu- und Abflüssen übereinstimmen, ich planerisch aber Buchungen dort einsortieren kann wo sie (planerisch) relevant sind.

@mbmueller
Copy link
Author

Das hatte ich so bislang nicht geplant.

Das einzige was mir hierfür einfallen würde wäre dafür noch Sollbuchungen zu verwenden und diese als Forderungen und Schulden zu betrachten.

@JohannMaierhofer
Copy link

Jetzt habe ich noch eine letzte Frage. Mir schaut es so aus als ob das Leistungsdatum für das Feature Wirtschaftsplanung zwingend notwendig ist. Das verstehe ich jetzt nicht.
Ich kann doch auch eine Wirtschaftsplanung basierend auf dem unmanipulierten Datensatz machen. Wie auch oben von vinjardin erklärt dient für die Steuer und für die Kassenprüfer der unmanipulierte Datensatz. Ich mache auch eine Wirtschaftplanung mit Planungen für die nächsten Jahre und mache für das letzte Jahr eine Gegenüberstellung von Plan und Ist. Aber alles eben auf den Daten die im regulären Buchungsklassensaldo sind und Steuer konform sind. Dieses ist bei mir auch die Basis für den Bericht auf der Mitgliederversammlung. Ich selbst kenne keine manipulierten Berichte die ich vorlegen würde.
Um die Wirtschaftsplanung nutzen zu können sollte diese also vom Leistungsdatum entkoppelt sein. Wenn ich keine manipulierten Daten brauche, brauche ich kein Leistungsdatum, kann aber trotzdem die Wirtschaftsplanung machen.

So wie ich die Forderung an das Leistungsdatum inzwischen sehe wäre das nur eine susätzliche Art Planung bzw. Darstellung der Daten. Derjenige der das nutzen würde, würde dann wohl auch zwei Arten der Wirtschaftsplanung durchführen. Einmal konform zu den steuerlichen Vorgaben und dann zusätzlich mit den manipulierten Daten. So verstehe ich die Diskussion inzwischen.

@mbmueller
Copy link
Author

Jetzt habe ich noch eine letzte Frage. Mir schaut es so aus als ob das Leistungsdatum für das Feature Wirtschaftsplanung zwingend notwendig ist. Das verstehe ich jetzt nicht.

Das war bisher das von dem ich ausgegangen bin. Grundsätzlich steht aber nix dagegen, dass auch für das normale Datum zu implementieren. Mehr dazu in #434

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Leistungsdatum von Buchungsdatum trennen
4 participants