-
Notifications
You must be signed in to change notification settings - Fork 17
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
base: master
Are you sure you want to change the base?
Leistungsdatum #496
Conversation
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. |
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. |
f140ca1
to
24e1f3f
Compare
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. |
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. 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. |
Ich habe hier noch etwas über das Zufluss und Abfluss Prinzip sowie die 10 Tage Regel gefunden: 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. |
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. |
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. |
Das klingt vernünftig. Dann brauchen wir das hier so nicht. |
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. |
Wie wäre dann der Workflow? Verstehe ich das, so richtig:
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. |
Ja, so habe ich das jetzt verstanden.
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. |
Genau so habe ich das gemeint. Das ist jetzt "nur" für den 10Tages-Zeitraum am Jahresende/Anfang von wiederkehrenden Zahlungen gedacht. |
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.
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. |
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. |
Das sehe ich ganz genauso. Für das Finanzamt, den Kassenbericht für die Kassenprüfer usw. . |
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. |
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. 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. |
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: |
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. |
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. |
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. |
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. 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. |
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 |
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.