Einzelbuchung in eine Sammelbuchung zusammenfassen (Lastschrift)

[jundl]

Hallo Frederic,

wie im ersten Post schon geschrieben suchen wir nach einem geeignetem Programm um einen SW-Wechsel durchzuführen.
(JVerein hat dafür auch sehr viele Vorteile anzubieten)
Im alten Programm ist es so, das eine Familien mit Kindern und Spartenbeiträgen nur einen Gesamtbetrag mit einer Abbuchung belastet werden.
Und daran wollten wir auch erst einmal nichts ändern um die Leute nicht in Diskussion zu bringen (so nach dem Stil: vorher war alles Besser).

Nicht alles auf eine Person zu buchen, macht es für den Kassenwart übersichtlicher welches Mitglied welche Zusatzleistungen bezieht. Auch bei Nachfragen von unseren Mitgliedern ist man dann aussagekräftiger bei der personenbezogener Kostenverteilung. Möglicherweise ist damit auch die Pflege und Auswertung einfacher.


Grüße
Jörg und Lutz

[jundl]

Hallo,

im Hibiscus-Forum hatte ich vor Tagen einen Beitrag eingestellt, der sich um das Thema "automatisches Laden" von Sepa-Dateien befasste. Aber halt auch mit Augenmerk auf dieses aktuelle JVerein-Thema "Zusammenfassung ..."

Daraus ergaben sich interessante Einblicke in Interna der JVerein-Software, die ich hier nur mit dem Link auf das Hibiscusforum aufzeigen möchte

http://www.onlinebanking-forum.de/forum ... hp?t=19898


Jörg

[Frederic]

Hallo Jörg und Lutz,

ich weiß nicht ob es sinnvoll ist, zu versuchen, euch von eurem Kurs abzubringen. Ich mach's trotzdem nochmal kurz: den Mitgliedern müsst ihr ohnehin die neuen Mandatsreferenzen mitteilen. Da könnt ihr dann auch drauf schreiben, dass aufgrund der Funktionsweise eurer neuen Software zukünftig für jedes Familienmitglied ein separater Bankeinzug erfolgt. Ich kann mir wirklich nicht vorstellen, dass dies einen Volksaufstand erzeugt. Schon gar nicht, wenn ihr ohnehin nur einmal jährlich einzieht.

Oder halt, wie vorgeschlagen, alle Zusatzbeiträge der Familie an das zahlende Mitglied hängen. Welche der beiden Varianten "übersichtlicher" ist, liegt sehr im Auge des Betrachters. Ich sehe das so: die Zusatzbeiträge in JVerein sind wirklich nur das: Zusatzbeiträge. Sie sind keine "Zusatzleistungsverwaltung". Für mich persönlich ist es daher sogar schlüssiger und übersicherlicher, wenn es alles am Zahler hängt. Wenn jemand eine Frage zu seinem Bankeinzug hat, ist es sehr viel praktischer wenn das alles am Zahler hängt und ich nicht alle Familienmitglieder einzeln abklappern muss.

Wenn natürlich die nicht-zahlende Ehefrau anruft weil sie vergessen hat, welche Zusatzleistungen sie gebucht hat, hat man den Mehraufwand, dass man beim Zahler statt ihr selbst nachsehen muss.

Was ihr eigentlich wollt, ist eine Erweiterung des Datenmodells von JVerein - nämlich die Trennung von "Mitglied" und "Zahler" in zwei Tabellen, so dass man einem Zahler mehrere Mitglieder zuordnen kann. Aber das wäre schon eine ziemlich große Änderung, die das Programm auch wieder ein gutes Stück komplexer macht.

Viele Grüße,
Frederic.

[jundl]

Hallo Frederic,

ich finde es ja immer sehr gut wenn es in Diskussionen zur Betrachtung vieler Blickwinkel kommt.

Ich möchte deine Anmerkungen in zwei Antworten formulieren.

1.) Ist es besser alle Beiträge an einen Zahler anzuhängen und dies schon in der Mitgliederverwaltung ?
Dazu nur einen sachlichen Fall. Was ist zu tun wenn ein Kind einer Familie den Sportverein verläßt oder die Sparte wechselt (wo der Beitrag anders ist) ?
Der Kassenwart bekommt die Kündigung (Peter wechselt oder geht) und hat nun die Aufgabe den richtigen Spartenbeitrag aus dem Sammelbetrag rauszusuchen (wo jetzt eigentlich ein Tabelle existieren müsste mit der Aufschlüsselung Kind zu Spartennutzung). Damit der Gesamtbetrag später wieder richtig ist.

Bei unserem Vorschlag der getrennten Kostenverwaltung brauchen wir das Kind nur löschen oder die Zusatzbeträge neu vergeben.

2.) Was wollen wir eigentlich ?
Wir wollen keine Umstrukturierung des Datenmodell. Wir wünschen nur eine Zusammenführung der Einzelabbuchungen zu einer Gesamtabbuchung je IBAN. Und schlagen möglicherweise die Koexistenz beider Varianten vor. Siehe Hibiscus-Link

Ich bin mir auch nicht sicher ob ich das mit der Änderung des Datenmodells richtig verstanden habe. Zumindest habe wir das nicht zwingend gefordert.
(äh ist das nicht die Familienfunktion ?)

Ich weiß nicht ob unsere Forderung hier nicht zu sehr nach noch größeren Anforderung inspiriert. Was wir eigentlich gar nicht wollen.


Grüße
Jörg

[Frederic]

Hallo Jörg,

warum das Zusammenfassen mit dem jetzigen Datenmodell von JVerein nicht so einfach möglich ist, wurde doch im Hibiscus-Forum schon erklärt: in JVerein hat jedes Mitglied eine eigene Mandatsreferenz. Und diese wird in der SEPA-Lastschrift mit an die Bank übergeben. Daher kann man nicht so einfach zwei Lastschriften mit unterschiedlicher Mandatsreferenz zusammenfassen. Was macht denn euer Shellskript? Welche Mandatsreferenz nimmt denn das? Versucht es irgendwie herauszufinden, wer der "Hauptzahler" ist?

Man könnte JVerein so ändern, dass die Mandatsreferenzen manuell eingegeben werden können und dabei doppelte Werte erlaubt sind. Aber das würde eine Hölle an Fehlermöglichkeiten eröffnen.

Das einzige sinnvolle wäre m. E., das "Fremdzahlermodell" inhaltlich im Datenmodell abzubilden. Das könnte mit einem weiteren Zahlungsweg "anderes Mitglied zahlt" (neben Überweisung/Barzahlung/Lastschrift) gemacht werden. Oder eben, noch viel stringenter, mit einer Tabellentrennung zwischen Mitglied und Zahler.

Aber ich glaube weiterhin, ihr macht euch da völlig unnötige Sorgen. Weder die getrennten Einzüge noch alle Zusatzbeiträge beim Zahler sind wirklich schlimm.

Viele Grüße,
Frederic.

[jundl]

Hallo Frederic


wenn du den Beitrag im Hibiscus-Forum vollständig gelesen hast, dort stand auch

Bei dem heutigen Verfahren wird stur davon ausgegangen: Jede Mandats-Referenz-Nummer ist ein SEPA-Mandat.

Obwohl Kinder gar kein SEPA-Mandat ausstellen können da sie kein Konto haben.

... JVerein hat jedes Mitglied eine eigene Mandatsreferenz. Und diese wird in der SEPA-Lastschrift mit an die Bank übergeben.

D.h. Eine Einzelüberweisung mit Kind-Mandatsreferenz vom IBAN des Vaters wird der Bank übermittelt. Kann das Funktionieren, wenn der Vater eigentlich eine andere Mandatsreferenz hat, die auf ein gültiges SEPA-Mandat verweist. Heißt dann wieder ein SEPA-Mandat (eine IBAN) -> 2 JVerein-Mandatsreferenzen ! (Ob das dann nicht ein gar ein Fehler wäre ??)

Ich glaube es wird nicht deutlicher dies hier nochmal alles zu wiederholen was im Hibiscus-Forum schon dokumentiert wurde.

Was das Script macht: kann man deutlich im angehängten Bild weiter oben sehen !!!


Grüße
Jörg

[Frederic]

[...]Obwohl Kinder gar kein SEPA-Mandat ausstellen können da sie kein Konto haben.

Wie gesagt, es ist eine Beschränkung des JVerein-Dateinmodells bzw. der hinterlegten Logik, dass jedes Mitglied eine eigene, automatisch generierte Mandatsreferenz hat.

Was mir jetzt allerdings noch eingefallen ist: es gibt da doch schon was in JVerein - das habe ich nur noch nie selbst verwendet. Und zwar bei den Beitragsgruppen die Beitragsarten "Familie: Zahler" und "Familie: Angehöriger". Damit kann man wohl jetzt schon eine Art Fremdzahlerrelation angeben. Verwendet ihr diese Funktion? Es wäre möglich, dass JVerein diese Information auch für die Zusatzbeiträge nutzt. Ob es das wirklich tut, weiß ich nicht.

Eine Einzelüberweisung mit Kind-Mandatsreferenz vom IBAN des Vaters wird der Bank übermittelt. Kann das Funktionieren, wenn der Vater eigentlich eine andere Mandatsreferenz hat, die auf ein gültiges SEPA-Mandat verweist. Heißt dann wieder ein SEPA-Mandat (eine IBAN) -> 2 JVerein-Mandatsreferenzen ! (Ob das dann nicht ein gar ein Fehler wäre ??)

Das ist überhaupt kein Problem. Mandat-IBAN ist keine 1:1-Beziehung, es kann beliebig viele Mandate für eine IBAN geben. Hier gibt's dann halt ein Mandat 4-1 für "Lutz zahlt seine eigene Beiträge", ein Mandat 5-1 für "Lutz zahlt den Fußball-Beitrag für seinen Sohn (?)" usw.

Was das Script macht: kann man deutlich im angehängten Bild weiter oben sehen !!!

Da sehe ich, dass vier Lastschriften mit den gleichen Kontodaten aber unterschiedlicher Mandatsreferenz zusammengefasst werden und dabei alle auf eine der drei Mandatsreferenzen (die 2-1) umgebogen werden. Meine Frage war: wie kommt euer Shellskript darauf, diese 2-1 zu nehmen und nicht eine der anderen? In den Eingangsdaten für euer Skript ist keine Fremdzahlerreferenz vorhanden (außer so eine Heuristik wie: man sucht nach dem Text "Jahresbeitrag").

Grüße,
Frederic

[jundl]

Hallo Frederic

Script-Funktion:
Hatte ich kurz im Forum Hibiscus in meinem vorletztem Post beschrieben.

P.S.: Für meine Bash-Skript-Lösung habe ich den identischen IBAN-Einträgen den Zahlereintrag mit der Kennung "2/Deneke ..." als Master-IBAN-Träger verwendet (Allso Zahl/). Weil dieser einen Mitgliedsbeitrag zahlt !

Die Funktion Familienbeitrag (Zahler/Angehöriger) verwenden wir schon.

Grüße
Jörg

[Frederic]

Ja, das meinte ich mit Heuristik. Da kann es obskure Sonderfälle geben, z. B. wenn es mehrere Hauptbeiträge für eine IBAN gibt, oder gar keinen.

Rein aus Neugierde habe ich jetzt mal die Familien-Beitragsarten ausprobiert. Und das ist in der Tat keine richtige Fremdzahlerrelation, auch wenn es erst mal so klingt. Mann kann bei "Familie: Angehöriger" keinen Beitrag eingeben, der muss auf 0,00 Euro stehen. Und wenn man beim Angehörigen einen individuellen Beitrag in den Mitgliederdaten hinterlegt, oder eben Zusatzbeiträge, wird das weiterhin dem Angehörigen belastet, nicht dem Zahler.

Eine "echte" Fremdzahlerfunktion wäre schon ganz nett, da stimme ich euch zu. Natürlich wird es garantiert auch Leute geben, die das jetzige Verhalten bevorzugen.

Und: nachdem ich jetzt gesehen habe, dass bei Verwendung der Familien-Beitragsarten direkt im Mitglied doppelklickbare Verlinkungen zum Zahler bzw. den Angehörigen vorhanden sind, sehe ich noch weniger als zuvor ein Problem darin, die Zusatzbeiträge einfach beim Zahler anzulegen.

Grüße,
Frederic

[jundl]

Hallo,

Und: nachdem ich jetzt gesehen habe, dass bei Verwendung der Familien-Beitragsarten direkt im Mitglied doppelklickbare Verlinkungen zum Zahler bzw. den Angehörigen vorhanden sind, sehe ich noch weniger als zuvor ein Problem darin, die Zusatzbeiträge einfach beim Zahler anzulegen.

Das sieht halt jeder scheinbar etwas anders. Beispiel habe ich oben schon aufgezeigt.
Kosten dem zuordnen bei dem Sie anfallen !

Es schleicht mich das Gefühl, das unser Wunsch eine unmögliche Forderung darstellt und wir auf unterschiedlichste Weise darauf hingewiesen werden, von dir jetzt schon in mehren Posts es anders zu machen als wir es wünschen und vom Programm auch möglich ist. Ich kann leider deine Funktion in diesem Forum nicht klar deuten, man könnte aber meinen du müsstes die Software auf unseren Wunsch hin abändern (und das will keiner der Projekt-Entwickler).


Bitte last uns diese Diskussion zum Topic bald beenden es dauert (für diese "Kleinigkeit" vor Kunde) schon viel zu lange ! Ich würde mich freuen wenn der mir einzig bekannte Softwareentwickler für JVerein "Heiner" ein Stellungnahme zu einer möglichen Umsetzung mal formuliert
(und wenn er die Änderung nicht machen will habe ich auch Verständnis, dafür brauche ich nicht einmal seine Begründung. Aber es wäre mal ein Status !!!!! ).
Weil immer wieder dieses Ping-Pong der Argumente und es geht doch auch anders bin ich langsam leid !

Es kommt auch nichts Neues an Ideen mehr hinzu.


Jörg