Ne mogu baš da se udubljujem u tvoj model, ali evo nekoliko smernica:

Dakle, ti pružaš neke USLUGE članovima. Za te usluge postoje CENOVNICI. Za tvoje potrebe, treba da analiziraš EFEKTE koje su kampanje imale (ukupno prikupljeno novca, broj novih članova). Potrebno je takođe pratiti FINANSIJSKE promene.
Tvoj sistem bi trebalo da bude neka mešavina CRM-a (customer relationship management) i knjigovodstvanog sistema.

Iz postavljenog pitanja je potpuno jasno da ne poznaješ knjigovodstvo. To ni ne čudi jer je to relativno nova tekovina (ovako kakvo je danas, počelo je da se koristi oko 12. veka, a nije se menjalo od 15. veka).

Procedura za prikupljanje podataka o finansijskim promenama bi trebala da bude ovakva:

Član X želi usluugu u1. Tada se formira OBAVEZA člana x za plaćanje usluge u1 i to tako što se upiše na DUGOVNOJ strani računa člana X iznos za uslugu u1.
Kada član X uplaćuje u potpunosti ili parcijalno za neku uslugu, tada se na POTRAŽNOJ strani računa člana X upisuje plaćeni iznos i1
Stanje računa člana X koje se računa kao sum(POTRAŽNIH strana) - sum(DUGOVNIH strana) biće negativna ako član X nije sve platio, biće 0 ako je sve platio, a veća od 0 ako je preplatio.

U slučaju da član X sada želi uslugu u2 (na primer to je promena kategorije) tada se knjiži OBAVEZA (nazovi je upgrade fee) po ceni od cena(u2)-cena(u1).

Dakle u onom tvom payment objektu (bolje bi ime bilo booking entry) fali ti jedno polje koje će ti reći da li je u pitanju DUGOVNA ili POTRAŽNA strana, tj, OBAVEZA ili IZMIRENJE obaveze.

Po tvome znači da kada se unese npr. Članarina za 2011 godinu moram za svakog člana unijeti i red u tabelu zaduzenja a kada dode do uplate u taj red unijeti uplatu tako da razlika treba biti 0.

Ja sam mislio i na problem kada dode do izmjene kategorije člana (jer na osnovu kojoj kategoriji pripada i njegov iznos članarine se mijenja), npr.

Ako je Član Samac ona članarina iznosi 10EUR, a sljedece godine se oženi i onda je u kategoriji BRACNI PAR i članarina iznosi 20EUR.

Posto sam mislio dinamicno racunati iznose uplata i onda ih usporedivati sa iznosima definisanim za kategorije, pojavljivat ce se razlika za vec ispunjene obaveze clanarine.

Treba ti nekoliko tablela i osnovna je

CLAN - maticni podaci, tj generalije clanova (id, ime, prezime,...)
USLUGA - opis sa cenom, ali predvidi i datum jer se cena moze promeniti (id, naziv, cena, vazi_od, vazi_do,...)

zatim jedna gde ces da to povezes, recimo

CLANARINA - gde ces napraviti vezu izmedju clanova i kategorija, predvidi i datum (od/do) jer je moguce "napredovati" (id_clan, id_usluga, vazi_od, vazi_do,...)

i na kraju gde ces na osnovu prethodnog napraviti tabelu promena, obaveze i uplate i onda se lako vidi ko ti duguje (dosta vazno za ovaj posao), a imas i analitiku kada ti je ko platio, to ce se videti na kartici

PROMENE (id_clan, id_usluga, datum, vrsta_promene, obaveza, uplata,...), a podatak vrsta_promene je dobar kandidat da se napravi tabela
VRSTA_PROMENE (id, opis,...) gde ces unositi zaduzenja i razduzenja

a pod clanarina moze da bude i stavka popust ako neko plati na vreme ili do odredjenog roka

Evo sta sam uradio:

1. u tabelu payments sam dodao dva polja (potrazuje,duguje). Kada dode do unosa nove usluge ili clanarine napravit cu opciju zaduzi clanove, i onda ce program za svakog clana unijeti zaduzenje u kolonu duguje, a kada oni budu placali onda unosim uplatu u kolonu potrazuje.

2. dodao sam da veza partners - categories bude M-M, onda ce clan moci imati vise kategorija cija ce suma (svaka kategorija ima odredenu visinu clanstva) praviti ukupan iznos za tu clanarinu ili uslugu, A posto sam napravio zaduzenje nece biti problema kada dode do promjene kategorije.

EVO SLIKE MODELA