Falsche Buchung auf Mitgliedskonto

[noschm]

Hallo,

eher zufällig stoße ich beim Testen der 2.6.1 auf einen Fehler, den ich nach dem letzten Abrechnungslauf in der 2.4.2 vorfinde:

Mitglied zahlt jährlich per Überweisung. Aus dem (jährlichen) Abrechnungslauf von heute ist jetzt auf dem Konto eine Soll-Stellung i. H. v. 240,00 Euro (sieht also aus als wenn der Jahresbeitrag als monatlicher Beitrag ermittelt worden ist). Merkwürdig nur, dass ich noch andere Mitglieder dieser Art habe - bei denen ist alles korrekt. Einziger Unterschied: Dieses eine Mitglied ist im letzten Jahr eingetreten. Habe ich jetzt manuell im Mitgliedskonto korrigiert. Aber mir wäre schon wohler, wenn jemand eine Idee hätte, was ich da falsch gemacht haben könnte.

Gruß
Norbert

[heiner]

Welches Beitragsmodell hast du eingestellt? Arbeitest du mit Individuellen Beiträgen? Beim Beitrasmodell "monatlich mit monatlicher, vierteljährlicher, halbjährlicher oder jährlicher Zahlungsweise" in Verbindung mit individuellen Beiträgen gab es ein Problem.

Heiner

[noschm]

Hallo Heiner,

Beim Beitrasmodell "monatlich mit monatlicher, vierteljährlicher, halbjährlicher oder jährlicher Zahlungsweise" in Verbindung mit individuellen Beiträgen gab es ein Problem.

genau mit der Zusammenstellung arbeite ich. Hat bei allen anderen Mitgliedern/Konstellationen bislang auch reibungslos funktioniert. Nur bei diesem einen (neuen) Mitglied jetzt mal nicht ....
Darf ich Deiner Antwort entnehmen, dass ich nach Umstieg auf 2.6.x damit keinen "Ärger" mehr haben dürfte?

Gruß
Norbert

[heiner]

Hallo Norbert,

den Bug habe ich heute gefixed. Versuche es mit der Vorabversion 2.6.2 unter https://sourceforge.net/projects/jverei ... versionen/

Heiner

[noschm]

den Bug habe ich heute gefixed. Versuche es mit der Vorabversion 2.6.2 unter https://sourceforge.net/projects/jverei ... versionen/
Heiner

Hallo Heiner,

habe mit der 2.6.1 tatsächlich ein identisches Verhalten feststellen können - alle Abbuchungen waren i. O., nur das Mitgliedskonto dieses einen Mitgliedes (Überweiser) war (wieder) falsch.
Jetzt habe ich mein Datenverzeichnis aus Version 2.4.2 genommen und Jameica/hibiscus mit den nightly builds neu installiert und dann die 2.6.2 (Dev 450) eingerichtet.

Dann meinen noch unter 2.4.2 erzeugten Abrechnungslauf "jährlich" gelöscht und neu erstellt - und jetzt werden sämtliche Lastschriften mit diesem Fehler erzeugt (also überall der unter abweichender Beitrag gespeicherte Wert x12 genommen).
(Für das Geld hätten wir sicher eine sinnvolle Verwendung, aber das lassen unsere Mitglieder sicher so nicht mit sich machen ... )

Hier hat sich ganz offensichtlich etwas in der Abrechnungslogik verändert - meiner Meinung nach zum Negativen

Gruß
Norbert

[noschm]

Guten Abend,

da ich eigentlich davon ausgehe, dass Heiner sehr gewissenhaft programmiert und auch selbst testet (so ist auf jeden Fall mein Eindruck bis heute) - das mit 2.6.2 beobachtete Verhalten also "gewollt" ist - vermute ich jetzt fast, dass ich mich womöglich (erneut) mit dem allseits beliebten Thema "Beitragsmodelle" auseinander zu setzen habe ...

Bisher habe ich diesen vermeintlichen "Bug" für ein "Feature" gehalten - um folgendes Beitragsmodell abzubilden:

Wir haben einen JAHRESbeitrag (der leider historisch gewachsen ist, durch die Euro-Umstellung "krumm" wurde und oberhalb eines Mindestbeitrages von jedem Mitglied bei Eintritt frei gewählt werden darf).
Der Beitrag kann jährlich, halbjährlich oder quartalsweise in entsprechenden Teilbeträgen gezahlt werden (auch nach Wunsch des Mitgliedes).
Also je JAHRESbeitrag eine Beitragsgruppe eingerichtet und bei den Mitgliedern dann jeweils einen "abweichenden" Betrag gepflegt. An irgendeiner Stelle hatte ich verstanden, dass dieser Beitrag dann bei dem entsprechend hinterlegten Zahlungsrhythmus (jährlich, halbjährlich, quartalsweise) berücksichtigt wird. Aber halt ohne weitere Berechnung (im Sinne einer Multiplikation mit einer Anzahl Monate).

Habe ich jetzt an dieser Stelle bislang etwas falsch verstanden? Ich halte unser Beitragsmodell nicht für so untypisch Gibt es vielleicht auch weitere Tester mit einer solchen Konstellation? Bis einschließlich Version 2.6.1 kam und komme ich, bis auf einen einzigen bislang entdeckten Fall (zuletzt eingetretener "Überweiser"), mit dieser Logik prima hin. Werde jetzt gerade doch ein wenig nervös, was da in den nächsten Tagen vielleicht an Arbeit auf mich zukommt ....

Gruß
Norbert

[heiner]

Hallo Norbert,

beim Beitragsmodel "monatlich mit monatlicher, vierteljährlciher, halbjährlicher, jähricher Fälligkeit" wird bei der Beitragsgruppe der monatliche Beitrag angegeben. Beim Mitglied wird der Zahlungsrhytmus angegeben. Die Abrechnung multipliziert den Beitrag je nach Fälligkeit mit 1,3,6 oder 12.

Die jetzt vorgenommene Änderung in der Vorabversion 2.6.2 betrifft die individuellen Beiträge des Mitglieds. Da habe ich mich ins Bockshorn jagen lassen. Die multipliziert jetzt den individuellen Beitrag auch. Das ist aber vollkommener Blödsinn. Das werde ich gleich zurückbauen. Siehe Download.

Heiner

[noschm]

Die jetzt vorgenommene Änderung in der Vorabversion 2.6.2 betrifft die individuellen Beiträge des Mitglieds. Da habe ich mich ins Bockshorn jagen lassen. Die multipliziert jetzt den individuellen Beitrag auch. Das ist aber vollkommener Blödsinn. Das werde ich gleich zurückbauen. Siehe Download.

Heiner

Hallo Heiner,

habe mir gerade die 2.6.2 (Dev 454) gezogen und getestet - das läuft immer noch falsch

Gruß
Norbert

[heiner]

Hallo Norbert,

kannst du noch mal die genaue Fallkonstellation posten?

Heiner

[noschm]

Hallo Heiner,

kannst du noch mal die genaue Fallkonstellation posten?

gerne doch. Also ....

Wir haben einen Jahresbeitrag, der vom Mitglied beim Eintritt frei festgelegt werden kann, mindestens aber 20,00 Euro jährlich betragen muss. Zahlung kann jährlich, halbjährlich oder vierteljährlich erfolgen. Fälligkeit ist jeweils der erste Tag des gewählten Zeitraumes (bei jährlicher Zahlung also der 01.01., bei halbjährlicher Zahlung der 01.01. und der 01.07. und bei den Quartalszahlern der 01.01., 01.04., 01.07. und 01.10.).

Beitragsmodell in den Einstellungen = "monatlich mit monatl., viertel-, halb- oder jählicher Zahlungsweise"

Für jeden vorkommenden Jahresbeitrag (und davon haben wir historisch und durch die Euro-Umstellung leider ein paar mehr ) habe ich eine Beitragsgruppe angelegt, die im Namen den Beitrag enthält (also z. B. "Beitrag 18,41"). Zusätzlich ist der zu zahlende Jahresbeitrag aber auch als "Betrag" hinterlegt.

Beim Mitglied wird gepflegt:
- die Beitragsgruppe (s. o.),
- der gewünschte Zahlungsrhythmus (jährlich, halbjährlich, vierteljährlich) und
- ein individueller Beitrag (wird von mir manuell ermittelt aus Jahresbeitrag und Zahlungsrhythmus)

Die Abrechnung nehme ich wie folgt vor:
- Modus = jährlich/halbjährlich/vierteljährlich (je Zahlungsrhythmus aber einen eigenen Lauf)
- die Fälligkeitstermine gibt mir JVerein ja vor (hier ändere ich nichts - aktuell sind das der 13.01. bzw. 08.01.2014)
- Stichtag = 01.01.2014
- Zahlungsgrund = "test"
- Option "SEPA-Datei drucken" wird ausgewählt
- Abbuchungsausgabe steht auf Datei

Mit der Version 2.4.2 habe ich auf diese Weise erfolgreich in den letzten 2 Jahren jedes Quartal meine Abrechnungen machen können (und habe ich das am 01.01.2014 auch zum letzten Mal erfolgreich getan - keine einzige Rücklastschrift ). Bei diesem letzten Lauf ist mir, allerdings erst in meinem Test mit der 2.6.1 , aufgefallen, dass ein Mitglied, dass im letzten Jahr neu eingetreten ist und per Überweisung zahlt, plötzlich auf dem Mitgliedskonto eine Sollstellung in Höhe des von mir gepflegten individuellen Beitrages (siehe oben) multipliziert mit 12 hatte. Und in der 2.6.2 fand ich dieses Phänomen dann bei allen Lastschriften.

Ich habe dann übrigens ein wenig probiert - und einmal den individuellen Beitrag = 0,00 gesetzt. Die Jahresabrechnung hat trotzdem (bei einem Jahresbeitrag von 20,00 Euro) wieder 240,00 Euro daraus gemacht. Das scheint also nicht (oder nicht nur) irgendwo bei diesen individuellen Beiträgen zu liegen.

Habe gerade auch noch einmal sämtliche von mir installierten Plugins auch noch einmal aktualisiert - Ergebnis bleibt das gleiche.

Und jetzt bist wieder Du dran, Heiner. Was läuft hier falsch? Bin gespannt ....

Viele Grüße aus SH
Norbert