1 zu N Relation abbilden bzw Vereinsverwaltung

[Don Pasquale]

Hallo Leute,

ich möchte so etwas wie eine Vereinsverwaltung und allmonatlich den Mitgliedsbeitrag abbuchen. Da ich aber die Zahlungen nachhalten ( oder sogar korrigieren) möchte reicht es nicht einfach nur einen betrag von einem Feld zu subtrahieren, sondern ich möchte zu jeder Zahlung einen Beleg haben.

Mir fehlt nur gerade die Idee, wie ich das realisieren könnte, bzw. wonach ich suchen soll. Vielleicht gibt es ja schon was ähnliches.

VIelleicht wären Antwortdokumente ( Die Zahlungen) zu einem Hauptdokument ( Das Vereinsmitglied) die Lösung ?

Wer hat eine Anregung für mich ?

Ciao

Don Pasquale

[klaussal]

... bitte bedenken: zahlungsweise monatl. jährlich, quartal etc.
... gibt's da evtl. rabatt bei jährl. zahlung....

mir fallen da etliche schweinereien ein, an die man vorher denken sollte  

[doliman]

Hi,

arbeite mit Antwortdocumenten und den dafür bestehenden LN Klassen, damit habe ich keine Probleme.
Außerdem kommt man sehr schnell und Performant an die Childdocs heran und solche Berechnungen machen zu können.

[Don Pasquale]

@Klaussal

Ich will ja eigentlich nur auf Knopfdruck zu jedem
Hauptdatensatz ein Antwortdokument erstellen,
das zumindest ist der Gedanke über den ich glaube
das am Besten realisiert zu bekommen.
Fehler im Konzept erwarte ich da nicht ( in realitionalen DB´s würde ich einfach einen eindeutigen Schlüssel aus User und Monat machen, dann kann ein Monatsbeitrag nur einmal abgebucht werden)
Wichtig ist im Moment erstmal die technische Umsetzung.

Ciao

Don Pasquale

[Performance]

.. in realitionalen DB´s würde ich einfach einen eindeutigen Schlüssel aus User und Monat machen...

das würde ich nicht in einer RDBMS tun.... denke mal an die 3te Normalform der Entität  



cu

[Don Pasquale]

@Doliman

Danke für deine Antwort. Ich bin mit meiner Idee auf dem richtigen Weg.

@Performance

Ich habe genau diese Anwendung bereits einmal in Paradox , einmal in Access und einmal mit dem C++ Builder gelöst.
So versuche ich Hobby und Beruf zu verbinden. Normalerweise
mache ich so etwas als erstes wenn ich ein neues Tool benutze.

Ich habe  Vereine, diese haben Mitglieder und diese zahlen Monatliche Beiträge.

Ein Schlüssel über diese drei sichert mir, dass ich nur einmal im Monat abbuche.
Wo siehst Du da einen Denkfehler ?
sehr interessiert

Don Pasquale

[Performance]

also da ich ein Teil meines Lebens mit Oracle ähm für Oracle und DB2 verbracht habe meine ich das ein primary key aus user+monat nicht eindeutig sind:
USER      Monat        Jahr
---------------------------------------
userAA   Januar     ->Jahr 1999
userAA   Januar     -> Jahr 2000

select userAA, Monat from tabelle where USER = userAA and MOANT = Januar;
--> ich kenne mich nicht aus mit Paradox aber in oracle würde beim definieren des Schlüssels schon eine Fehlermeldung aufreten.
- oder was meinst du mit Schlüssel ? soll  das NUR ein Index für dich sein ?


edit: oder hast du 3 Tabellen ? ähmmmm....

cu

[Don Pasquale]

Ach so,
Du störst Dich am Monat der alljährlich auftriit.
OK, da hast Du recht. Mit Monat meinte ich
natürlich schon so etwas wie 2003/11.

Ich habe auch keine Vereinsverwaltung sondern
eine Fanzine-Verwaltung. ( Aber bis ich dass erklärt
habe, vergehen ja wochen)

Ciao

Don Pasquale

[Thomas Schulte]

fanzine? Welches Fanzine?

Thomas

[wflamme]

VIelleicht wären Antwortdokumente ( Die Zahlungen) zu einem Hauptdokument ( Das Vereinsmitglied) die Lösung ?

Wer hat eine Anregung für mich ?

Ich würd's gewissermaßen mit Soll- und Haben-Dokumenten machen, die nach Mitglied/Zeit kategorisiert sind. Keine Antwortdokumente!

Vorteil: Summenbildung/Fehlbetäge direkt in Ansichten bzw. Guthaben pro Mitglied, insgesamt, pro Periode etc.
Raten-/Teilzahlungen, Gutschriften etc alles unproblematisch möglich.

[Don Pasquale]

@wflamme,

das hört sich sehr gut an, nur richtig begriffen habe ich es noch nicht. Ist mir peinlich, aber magst Du mir das nochmal erklären ?
( Gaanz langsam :-) )

Ciao

Don Pasquale

[wflamme]

Also es geht um mehr oder weniger regelmäßige Forderungen und Zahlungen von Mitgliedern. Da hätten wir dann also auch schon die drei wesentlichsten Dinge beisammen, um die es in den Ansichten grundsätzlich gehen wird:
-MitgliederNr/Name
-Zeit/Datum
-irgendwelche Forderungen und Zahlungen

Bei Beträgen interessieren ja immer die Summen und Notes kann in seinen Ansichten ja Summen bilden. Auch über Hierarchien hinweg, mit Teilsummen. Sehr hübsch anzuschauen.
Die Summenbildung funktioniert aber leider nur mit Hauptdokumenten/-formularen, nicht mit Antwortdokumenten.

Also fällt eine Hierarchie auf Antwortbasis schonmal flach, da müssen Kategorien her, zB die ganz oben aufgezählten. Wenn Du zB davon ausgehst daß Du ein Mitgliedsformular M hast und Deine Forderungen F regelmäßig und komplett erhebst, aber die Zahlungen Z nicht immer komplett eintreffen, dann kannst Du Dir zB die Mitgliedsnr in das Feld Forderungen vererben (also Mitglied anwählen und eine Forderung erstellen) und wenn jemand für eine Forderung zahlt, dann markierst Du die Forderung und erstellst eine Zahlung, wobei Du dann Mitgliedsnr und Forderung an die Zahlung vererbst.
Nun nimmst Du Forderungen und Zahlungen in eine Ansicht, kategorisierst nach Mitglied, dann nach Forderung und läßt Dir rechts die Beträge vorzeichenrichtig summieren. Dann hast Du die Grundstruktur schon, siehst auf Anhieb die  akt. Mitgliedssaldi, darunter das, was zu jeder Forderung noch offen ist (bzw. ein eventuelles Plus) und im letzten Detail auch noch die Einzelzahlungen.

[Don Pasquale]

@wflamme,

Super, ich musste zwar 3 mal lesen, aber das hatt sich gelohnt.

Die Summenbildung funktioniert aber leider nur mit Hauptdokumenten/-formularen, nicht mit Antwortdokumenten.

Das ist ja ein Ding, ich habe bisher nie mit antwortdokumenten
gearbeitet, das war mir neu.
Da hast Du mir massig fehl-Arbeit erspart.
Vielen Dank
Ciao
Don Pasquale

[wflamme]

Danke für die Blumen.

Da bin ich nämlich einmal gründlich bei einer Anwendung reingefallen.. tolle Responsestrukturen erstellt und all das. Und dann, ganz, ganz zum Schluß fand jemand, daß man da nur noch eine Summenspalte bräuchte, aber das wäre ja bei Notes kein Problem....
:-)))

Sowas merkt man sich dann. Seither ein Standardpunkt auf der Checkliste....

[Don Pasquale]

 

Das kommt mir so bekannt vor.

"Das ist ja ganz schön, können Sie das jetzt noch so programmieren, dass es aussieht wie Outlook oder Windows"

Aaah


Ciao

Don Pasquale

[wflamme]

Antwort:
Gut. Kein Problem: Bevorzugen Sie die Absturzmeldung in Standardfarben, reicht eine kryptische Fehlermeldung und wollen Sie noch eine Verzögerungsschleife vorher?

[Don Pasquale]

 

[Tränen abwisch]
[tief Lufthol]

Genial


Don Pasquale