Beiträge abrechnen

[AndyMcNab]

Hi,

jetzt benötige ich nochmal Hilfe.
In der tblMitglieder werden die Beiträge hinterlegt. So kann ich später berechnen welche Einnahmen durch Beiträge erzielt wurden.
Problem:
Es gibt einen Familienbeitrag. D.h. mehrere Mitglieder bezahlen zusammen nur einen Betrag X.
Wenn ich in der Tabelle tblMitglieder jetzt für jeden Familienbeitrag 70 Euro hinterlege bekomme ich bei 3 Mitgliedern 210 Euro. Dabei sind es eigentlich nur 70 Euro, da alle 3 Mitglieder auf den gleichen Familienbeitrag laufen.

Wie kann ich das Ganze so abbilden, dass der Beitrag in tblMitglieder ein Pflichtdfeld bleibt und ich keine Probleme mit der Abrechnung bekomme?

Danke!

[DF6GL]

Hallo,

da gibt es mehrere Möglichkeiten.

Eine wäre:


Führe in tblMitglieder ein weiteres Long-Feld "HauptmgldID" mit zur Unterscheidung, ob es sich beim aktuellen Mitglied um ein Hauptmitglied (der Beiträge zahlt)  oder um ein "Nebenmitglied" (der keine Beiträge zahlt) handelt.

In dieses Feld wird, wenn es sich um "Nebenmitglied" handelt, die ID des dazugehörenden Hauptmitgliedes  eingetragen.

Wenn das Feld leer ist/bleibt, handelt es sich um das Hauptmitglied. Mittels Tabellen-Gültigkeitsregel oder auch im Formular wird der Eintrag des Beitrages nur zugelassen, wenn das Feld leer ist, es sich also um ein Hauptmitglied handelt.

Bei der Berechnung der Einnahmen werden nur die DS berücksichtigt, bei denen "HauptmgldID"  leer ist.

[MzKlMu]

Hallo,
und noch weitere Möglichkeiten.
Ich denke, hier muss mehr Aufwand betrieben werden. Der Beitrag sollte in der Tabelle Mitglieder nicht erfasst werden. Der Beitrag unterliegt ja Änderungen über der Zeit, wie willst Du das berücksichtigen ? Die alten Beiträge müssen ja erhalten bleiben, sonst sind ja die Daten der Vergangenheit falsch. Es fehlten daher noch einige Tabellen. Eine Tabelle zur Bildung von Gruppen (Familien etc.).In diese Tabelle ist jede Person die zu einer Gruppe gehört (auch Einzelpersonen sind dann eine Gruppe) als Fremdschlüssel aufzunehmen.
Dann wird eine Tabelle benötigt die die Beiträge in je einem Datensatz erfasst. Immer fortlaufend, ein neuer Beitrag (wegen Erhöhung) gibt ein neuer Datensatz. Mit einem Feld für das Gültigkeitsjahr.
Der Fremdschlüssel dieses Beitrags wird dann als Fremdschlüssel in einer weiteren Tabelle erfasst. In diese Tabelle kommt dann auch der Fremdschlüssel zur Gruppe. Du kannst Dann beliebig große Gruppen bilden.

In dem Zusammenhang, ich würde alle Personen in einer Tabelle führen und auf die 1:1 Beziehung verzichten. Über Datumsfelder (Eintrittsdatum z.B.) kannst Du problemlos die Art der Personen unterscheiden.
Wenn man jetzt noch bedenkt, dass manche Personen aus dem Verein austreten und 2 Jahre später wieder eintreten, wird das alles noch viel komplizierter.

[AndyMcNab]

Hi,
okay ja, die Möglichkeit klingt auch gut.
Ich hatte mir vorher gedacht eine tblFamilienbeitrag zu machen um die m:n Beziehung zu umgehen.

Wenn ich es mit Haupt- und Nebenmitglied mache kann ich mir dann ein einem Bericht z.B. Rechnung anzeigen lassen wer Hauptmitglied ist, wer die Nebenmitglieder sind die dazu gehören und den Betrag, von dann 70 Euro?!

Ich denke schon!

@MzKlMu

Personen habe ich mittlerweile in einer Tabelle. Ich würde also jetzt eine tblGruppe machen und jedes Mitglied einer Gruppe zuordnen.
Familienmitglieder also in eine Gruppe und zu jeder Gruppe dann einen Beitrag!
Am Ende also tblPersonen, tblGruppe und tblBeiträge.
In tblGruppe muss ich dann für die Fremdschlüssel aus tblPersonen mehrere Werte zulassen?!

Noch eine Frage:
In tblPersonen ist mein Primärschlüssel aus 3 Feldern zusammengesetzt um doppelte Einträge zu vermeiden und, da die Mitgliedsnummer nicht eindeutig ist!
Wie verweise ich auf den Primärschlüssel, der sich aus Name, Vorname und Geburtsdatum zusammensetzt?!

Danke Euch und VG

[el_gomero]

@ Klaus

siehe auch

http://www.access-o-mania.de/forum/index.php?topic=22512.0

[MzKlMu]

Hallo,
der Primärschlüssel über 3 Felder ist nicht zu empfehlen und machen zusätzlichen Aufwand. Erstelle ein Autowertfeld und verwende dieses einzelne Feld als Primärschlüssel. Über die jetzigen Felder das PS legst einen eindeutigen zusammengesetzten Index. Alle Felder dieses Indexes müssen dann auf Eingabe erforderlich stehen und dürfen keinen Nullstring ("") zulassen. Kann man alles auf  Tabellenebene einstellen.

Eine nicht eindeutige Mitgliedsnammer solltest Du bereinigen und dann auch zukünftig verhindern.

[AndyMcNab]

Okay, also AutoWert als PK und die drei Felder als Index, quasi Indiziert ohne Duplikate!
Ich möchte aber, dass die Kombination aus den dreien einmalig ist! Wie geht das?
Danke Euch!

[MzKlMu]

Hallo,
siehe Access Hilfe >Index >Mehrfeldindex

Beachte auch die anderen Hinweise dazu in #5.

[AndyMcNab]

Danke, habs gefunden! 

Wie wird das denn generell gehandhabt. Sollte ich in jeder Tabelle das einen AutoWert als PK verwendet einen Mehrfachindex anlegen um die Eindeutigkeit der Datensätze sicherzustellen?

[MzKlMu]

Hallo,
ich persönlich bevorzuge immer einen Autowert als Primärschlüssel. Zumal eine Zahl als PS als Primärschlüssel besser geeignet ist als ein Text.
Wenn die Tabelle ein Bestandteil einer Beziehung als 1-Tabelle ist, würde ich immer einen Autowert als PS verwenden und diesen PS dann als FS in den entsprechenden n-Tabellen.

[AndyMcNab]

Für die Beziehungen ist klar ein AutoWert besser geeignet!

Mir geht es darum.
Wenn ich einen AutoWert als Schlüssel habe und über ein Formular einen neuen Datensatz hinzufüge kann ich ja exakt den gleichen Datensatz eingeben. Einmal dann mit AutoWert 1 und einmal mit 2!

[Lachtaube]

Es gibt Vor- und Nachteile, die man im Einzelfall abwägen sollte:
SQL Server: Natural Key Verses Surrogate Key
10 tips for choosing between a surrogate and natural primary key
Surrogate vs. natural/business keys

[MzKlMu]

Hallo,

über ein Formular einen neuen Datensatz hinzufüge kann ich ja exakt den gleichen Datensatz eingeben. Einmal dann mit AutoWert 1 und einmal mit 2!

nein, eben nicht. Ein zusammengesetzter eindeutiger Index (mit den oben beschriebenen Einstellungen) lässt das genau wie ein zusammengesetzter PS nicht zu.
Den gleichen Datensatz mit Autowert 1 und 2 kann es nicht geben.
Der Autowert darf natürlich nicht mit in den Index genommen werden.

[AndyMcNab]

Ja genau!
Das verstehe ich! Meine Frage war dann eben ob man al PK immer einen AutoWert nehmen sollte und dann zusätzlich einen Mehrfachindex für die Eindeutigkeit!?

[MzKlMu]

Hallo,
das lässt sich pauschal nicht beantworten.
Siehe #9 und #11.