Abrechnungen funktionieren nicht mehr richtig

[JPT77]

Hallo,

ich wollte die Woche die monatliche Abrechnung anstoßen. Leider klappt es aber nicht (viel zu wenige Einträge). Eine Ursache war, dass die Standardbeträge der Beitragsgruppen verschwunden waren.

jetzt sehe ich gerade, die sind schon länger weg. Aber es hat doch immer funktioniert?

2024-02-20:(1,'Vollzahler',NULL,0,0,0,56,30,0,0,0,_binary '\0',''),
2024-03-01:(1,'Vollzahler',NULL,0,0,0,56,30,0,0,0,_binary '\0',''),
2024-03-03:(1,'Vollzahler',NULL,0,0,0,56,30,0,0,0,_binary '\0',''),
2024-03-11:(1,'Vollzahler',NULL,0,0,0,55,30,0,0,0,_binary '\0',''),
2024-04-22:(1,'Vollzahler',NULL,0,0,0,55,30,0,0,0,_binary '\0',''),
2024-06-09:(1,'Vollzahler',NULL,0,0,0,55,30,0,0,0,_binary '\0',''),
2024-07-05:(1,'Vollzahler',NULL,0,0,0,55,30,0,0,0,'\0',''),
2024-09-10:(1,'Vollzahler',NULL,0,0,0,55,30,0,0,0,'\0',''),
2024-10-03:(1,'Vollzahler',NULL,0,0,0,55,30,0,0,0,'\0',''),
2024-10-30:(1,'Vollzahler',NULL,0,0,0,55,30,0,0,0,'\0',''),
2024-11-01:(1,'Vollzahler',NULL,0,0,0,55,30,0,0,0,'\0',''),
2024-11-01:(1,'Vollzahler',30,0,0,0,55,30,0,0,0,'\0',''),

Nach diesem Fix sind es aber zuviele Buchungen.
Es muss also zusätzlich noch verlorengegangen sein, wann die letzte Abbuchung bei Zahlungszeitraum > 1 Monat war.
wo finde ich das im Source, bzw wo wird das festgehalten?

ich war zuletzt auf der 21, habe aber auf die 22 aktualisiert um auszuschliessen, dass ich einem Know-Bug aufgesessen bin.

Vielen Dank

[lenilsas]

Die Abrechnung wird in der Datei: /src/de/jost_net/JVerein/io/AbrechnungSEPA.java durchgeführt.
Hast du bei den Mitgliedern Individuelle Beiträge? Eventuell ist dadurch das fehlen des Betrages in der Beitragsgruppe nicht aufgefallen.
Welche Buchungen sind zu viel? Sind es normale Beiträge oder Zusatzbeträge?

[JPT77]

Ja, ich habe individuelle Beträge. genau die wurden abgerechnet, die anderen nicht. Aber nur diesen Monat. Vorher hat es eigentlich ziemlich zuverlässig funktioniert, obwohl die ja laut Backup schon länger nicht gesetzt waren.

Nach dem Setzen der Default-Beiträge werden jetzt ALLE Beiträge abgerechnet, auch die, die einen längeren Zahlungsrythmus haben und noch nicht fällig wären.

Es hat mit Einstellung ALLE bisher funktioniert. Diese Einstellung war aber jetzt weg, stattdessen dieses HAVIMO usw. zur Auswahl.
Ich glaube aber nicht, dass es sinnvoll ist, "Gleicher Termin für alle" zu setzen, wenn ich unterschiedliche Zahlungsintervalle habe, oder? (das bringt ALLE zurück in die Auswahlliste)

[JohannMaierhofer]

Also ich verstehe das Problem noch nicht ganz und auch nicht warum da früher etwas gehen sollte was jetzt nicht mehr geht.
Was sind den Default-Beiträge und wie können die verschwinden? Wenn du mit Default-Beiträge jetzt den Wert in der Beitragsgruppe meinst dann hat die zumindest kein Code irgendwie bei der Migration gelöscht.
In der Beitragsgruppe gibt man einen Beitrag ein, den sollten alle Mitglieder haben. Über den individuellen Beitrag kann man für Mitglieder von dem in der Beitragsgruppe abweichen. Wenn du mit Default-Beiträge also den Wert in der Beitragsgruppe meinst, dann darf der natürlich nicht 0 sein solange nicht alle Mitglieder einen individuellen Beitrag haben. Ist der Wert in der Beitragsgruppe 0 werden auch nur die abgerechnet, die einen individuellen Beitrag ungleich 0 gesetzt haben. Das war aber denke ich immer schon so.
Eine kleine Änderung gibt es jetzt in 2.8.23. Bisher wurde bei 0 im individuellen Beitrag der Beitrag aus der Beitragsgruppe verwendet. Jetzt passiert das nur wenn bei individuellen Beitrag nichts eingegeben ist. Ist etwas eingegeben wird das verwendet, auch wenn es 0 ist. Bei der Migration nach 2.8.23 wird der Wert 0 gelöscht. Damit sollte sich die SW danach gleich verhalten solange man nicht wieder einen Wert 0 einträgt.

Das mit dem ALLE verstehe ich auch nicht. Den gibt es denle ich immer schon nur bei gleichem Termin für alle. Hat man ein Beitragmodell für unterschiedliche Terminen muss man auswählen für welchen Termin man die Beitragsabrechnung machen will. Da will man doch nicht alle haben sondern nur die die zu diesem Termin fällig sind. Wann ein Mitglied fällig wird muss man in diesem Fall im Mitglied bei Zahlung->Zahlungsweg->Zahlungsrhytmus eingeben. Da müsste bei dir dann unterschiedliche Werte stehen wenn du sagst , dass nicht alle Mitglieder das gleiche Intervall haben.

Wenn du also irgenwie nun ALLE ausgewählt hast, dann hast du ja auch den gleichen Termin für alle gesetzt. Dann werden aber auch alle abgerechnet. Das ist ja auch dann so gewollt, das bedeutet ja ALLE. Da ist ja auch das Feld Zahlungsrythmus beim Mitgleid ausgeblendet weil es keine Bedeutung hat.

Wenn du also mit individuellen Intervallen abrechnen willst dann musst du jetzt mal das Beitragsmodell auf "Monatlich mit ... zu fixen Terminen" wählen. Dann bei den Mitgliedern angeben zu welchem Termin sie zahlen, also Monatlich, Vierteljährig etc. Im Abrechnungslauf wird dann ausgewählt für welche Termine abgerechnet werden soll. Alle Mitglieder die dann hiervon betroffen sind sollten abgerechnet werden.
Könntest du das so einfach mal machen. Wenn es damit nicht geht sollten wir weiter schauen ob es wirklich einen Fehler gibt.

[JPT77]

Alle Mitglieder die dann hiervon betroffen sind sollten abgerechnet werden.

Wovon genau ist das dann abhängig? vom zahlungstermin oder von dem Datum der letzten Buchung? (wo wird das festgehalten?)

Beim Mitglied unter Zahlung->Zahlungsweg->Zahlungsrhytmus unterhalb Zahlungsweg gibst du an wann das Mitglied zahlen soll. Da kannst du wählen zwischen Jährlich, Halbjärlich, Vierteljährig oder Monatlich.
Beim Abrechnungslauf gibst du dann an welche betroffen sind, also z.B. Vierteljährig und Monatlich. In dem Fall sind dann alle Mitglieder dran die Vierteljährig oder Monatlich gesetzt haben.

Willst du es noch feiner musst du das Beitragsmodell auf .... zu flexiblen Terminen setzen. Dann kannst du beim Mitglied noch genauer auswählen wann es zahlen muss.
Und nun, da sehe ich auch wieder den Modus "Alle" beim Abrechnungslauf. Wahrscheinlich hast du das dann bisher genutzt. Dann musst du hier aber auch den Abrechnungsmonat auswählen den du abrechnen willst. Dann werden wieder alle Mitglieder die betroffen sind abgerechnet. Beim Mitglied setzt man dann ja entweder Monatlich oder feste Monate.

Probier also dann doch das hier mal aus. Wenn es nicht geht muss man wirklich nach einem Fehler suchen.

Vielleicht ist aber auch das Problem durch die Umstellung beim individuellen Beitrag verursacht. Da sollte nun statt 0 nichts mehr drinnen stehen. Nur noch Werte ungleich 0. Wenn du da nach der Migration zu 2.8.23 bei Mitgliedern eine 0 eingetragen hast dann wird dieses nicht mehr abgerechnet! Also alle 0 rauslöschen wenn du das gemacht hast.

[JohannMaierhofer]

Was mir auffällt, dass es in der Datenbank zwei Spalten gibt: die eine nennt den Zahlungsrythmus ("zahlungsrhytmus") und die andere ("zahlungstermin") spezifiziert, wann dieser Zahlungsrythmus fällig ist. Also beispielsweise "Jährlich (Januar)" oder "Quartalsweise (Feb, Mai, August... oder so)". Diese Daten kann ich aber von der GUI aus nicht setzen. Möglicherweise funktionierte meine Abrechnung deshalb bisher. weil ich diese Werte manuell (SQL) gesetzt hatte.

Leider sind die Werte dieser beiden Spalten kodiert und nicht im Klartext. (die sind in enum Zahlungstermin definiert)

Ist die Spalte obsolete?

Man kann beim Beitragsmodell auch zu flexiblen Terminen auswählen. Dann kann man auch die Monate wie z.B. Januar auswählen. ich glaube dazu ist es gedacht.

[JPT77]

Oh ja, das wars.
Es muss auf ".. zu flexiblen Terminen" stehen.
Vielen Dank für eure Hilfe!
Wie hat sich das bloss verstellt?
Wo finde ich diese Einstellung in der Datenbank? Dann gucke ich mal, wann sich das geändert hat.

Noch eine Kleinigkeit: Abrechnungslauf läuft nicht durch, wenn Geschlecht nicht gesetzt.

[JPT77]

Tabelle Einstellung, Spalte Beitragsmodell.
Und ja, die hat sich irgendwann im Laufe des Oktobers verändert von 10 auf 5.
Wenn ich es nicht manuell gesetzt habe, dann muss es wohl beim Upgrade auf die 21 passiert sein?
Aber das Release ist eigentlich viel älter?

Ich hatte in der letzen Zeit mit dem Arch AUR Build von JVerein gearbeitet,
https://aur.archlinux.org/packages/jverein
das steht zwar mittlerweile auf 22, diese Version wollte er bei mir aber nicht automatisch installieren. deswegen hatte ich es deinstalliert und manuell über die Pluginverwaltung installiert.

meine installhistory auf zwei verschiedenen Systemen:

[2024-06-07T21:43:55+0200] [ALPM] installed jverein (2.8.21-1)
[2024-06-07T21:57:37+0200] [ALPM] removed jverein (2.8.21-1)
[2024-06-11T21:11:31+0200] [ALPM] installed jverein (2.8.21-1)
[2024-10-30T19:03:23+0100] [ALPM] removed jverein (2.8.21-1)

[2024-08-10T16:08:58+0200] [ALPM] installed jverein (2.8.21-1)

Also nein, von einem Update kann es nicht verursacht worden sein. Lassen wir es wohl darauf beruhen.

[JPT77]

PS: du hast irgendwie versehentlich meine erste Antwort bearbeitet als du geantwortet hast. dort steht jetzt deine Lösung drin, ist etwas irritierend...