[AC-2003] Schéma relationnel base Access

[jmde]

Bonjour et bonne année à tous,

Pour mon association je voudrais créer une base pour réaliser la gestion des cotisations.

Le fonctionnement selon moi serait le suivant :

1ère Etape (suivant le schéma ci-joint)

Une table Familles (Numéro et adresse unique)

Une table Cotisations ( Montant de la cotisation du)

Une table Adhérents (Qui comprend les éléments de la famille)

Une table Détails Cotisations (plusieurs lignes de tarif par adhérent, cette table sera vidée chaque saison)

Une table Tarifs

Une table Caution (le contenu de cette table existe en permanence et devra gérer le remboursement des cautions)

2ème Etape

Si la 1ère étape est correcte je voudrais votre aide pour gérer les règlements chèques et espèces (les cotisations sont payées en plusieurs fois), les od comptables, les remises en banque.

Merci pour votre aide.

Salutations

[ClaudeLELOUP]

Bonjour et meilleurs vœux à toi aussi,

Tu ne précises pas quel genre d'aide tu souhaites.

Quant à ta première étape, il faudrait en connaître un peu plus sur l'organisation de l'association (cotisations ? Cautions ? Adhérents versus Famille ?) pour t’aider à construire le modèle.

[jmde]

Bonjour Claude LELOUP,

Merci pour ta réponse.

L’aide que je souhaite c’est la réalisation du schéma relationnel pour que je puisse créer les tables.

Pour la gestion des adhérents cela se présente de cette façon :

1er cas un adhérent seul :

Selon qu’il s’agit d’un nouveau ou d’un renouvellement.

Pour un nouveau on renseigne la tbl familles, et tbl Adhérents
- Il choisit un entraînement individuel et un entraînement collectif.
- Il doit régler une caution (Type Badge et carte)
- Et une Licence.

Dans ce cas la tbl détailCotisations comporte quatre enregistrements, et il doit
Le total de ces quatre enregistrements (que je pense mettre dans la tbl cotisation).

Ce montant (ou cotisation) il peut le régler en trois fois par chèque ou en espèces.

Pour un renouvellement, on appelle la fiche et on fait les modifications nécessaires. Puis on procède comme pour un nouveau (sauf qu’il ne règle pas la caution).

Pour une famille avec un enfant ou plus, on renseigne les tbl familles (un seul membre est enregistré, il est considéré comme responsable, il peut être adhérent ou pas).

Puis on enregistre dans la tbl Adhérents chaque membre de la famille qui fait une activité.
Et dans la tbl DétailCotisations on procède de la même façon que pour un adhérent seul.

Pour la tbl cotisations, le montant est celui de toutes les lignes de la tblDétailCotisations, et si ce montant dépasse une certaine somme, on applique un forfait famille)

De même certains membres bénéficient d’une réduction de leur cotisations.

Voilà j’espère que cela est clair et pourra t’aider.

Salutations.

[ClaudeLELOUP]

Ce que j’ai compris :

Infos générales

Un adhérent : c’est une personne qui fait au moins une activité (en individuel ou en groupe).
Il doit avoir une licence : cette licence est-elle liée à la personne ou aux activités auxquelles il participe ? L’info Oui/non suffit-elle ou bien ces licences sont à durée déterminée ?
Il doit verser une caution : cette caution est-elle liée à la personne ou aux activités auxquelles elle participe ? L’info du montant versé suffit-elle ?


Dans la table Adhérents, je devrais trouver :
idAdhérent (clé autonum) :
ses coordonnées : identité, adresse…
date de naissance : pour déterminer son âge ;
son tarif de cotisation (par exemple en pourcents du tarif plein, 100 % par défaut) ;
Licence (?) ;
Caution (?) ;
idFamille (ou zéro s’il est seul) voir plus loin.
Chacune de ses activités devrait se trouver dans une table ActivitésAdhérents avec :
idAdhérent ;
idActivité ;
DateDébut ;
DateFin (quand il a renoncé, vide sinon).

Cela suppose que dans le modèle, on doit trouver une table Catalogue des activités avec :
idActivité (clé autonum) ;
dénomination pour chacune (individuel ≠ collectif) ;
montant de la cotisation (voir plus loin).

Si j’ai bien compris, certains adhérents viennent en famille et cette info est utile pour le calcul des cotisations (plafond).
Dans une table Familles, je devrais trouver :
idFamille (clé autonum);
les coordonnées du responsable.
N.B. Si un adhérent est seul, je ne vois pas l’utilité de lui adjoindre une famille.


Pour la gestion des cotisations

- On devrait disposer d’un tarif (taux plein) pourquoi pas inclus dans la table des activités.
- Périodiquement, quand la cotisation est due, on déclenche un processus de calcul des cotisations et on alimente une table des cotisations dues.
Cette table Cotisations dues contient
idCotisation ;
l’année ;
une clé qui identifie le débiteur, selon le cas l’adhérent seul ou le responsable de la famille ;
le montant dû.

Au fur et à mesure des paiements, on alimente une table Paiements dans laquelle on trouve pour chaque paiement :
idPaiement(clé autonum) ;
date ;
clé de référence du débiteur ;
le montant encaissé (pour moi, peu importe que ce soit en liquide, par chèque ou virement).

Il me semble qu'avec ces infos, on peut construire un système de suivi.

Pour les od comptables, les remises en banque pas encore compris ce que tu veux faire dans le cadre de cette application.

[jmde]

Bonsoir Claude LELOUP,

Un adhérent : c’est une personne qui fait au moins une activité (en individuel ou en groupe)...........

Oui,
La licence est liée à la personne elle est valable pour une saison sportive.
La caution est liée à la personne c’est la remise d’un Badge ou d’un pass , il faudrait aussi l’info lors du remboursement de la caution.

Je regarde la suite rapidement.

Salutations

[ClaudeLELOUP]

La licence est liée à la personne elle est valable pour une saison sportive.

À mon avis, si le champ "Licence" contient l'année de validité, cela devrait suffire. Le propos n'est-il pas simplement de savoir si oui ou non, l'intéressé est en ordre ?

il faudrait aussi l’info lors du remboursement de la caution.

Si tu enregistres le montant, il te suffit de le ramener à due concurrence lors d'un remboursement partiel ou total.
À mon avis, il suffit de connaître le montant qui appartient à l'adhérent.

[jmde]

Re,

Dans une table Familles, je devrais trouver :
idFamille (clé autonum);
les coordonnées du responsable.
N.B. Si un adhérent est seul, je ne vois pas l’utilité de lui adjoindre une famille.

Cette table familles je la considère aussi comme une table des adresses ce qui m’évite de rajouter ces champs sur la table adhérents.

Qu’en penses-tu ? Cela est-il possible ?

Salutations

[ClaudeLELOUP]

Il me semble que l'adresse est liée à l'adhérent.
Est-ce impensable que les adhérents d'une même famille aient des adresses différentes (familles recomposées par exemple).

En plus, cela t'oblige à disperser dans deux tables, les données d'identité relatives à un adhérent "solo".

[jmde]

Bonjour Charles LELOUP,

Pour éclaircir un petit peu le sujet est-ce que je suis sur la bonne piste en créant ces tables ?

Tbl_Familles
Id_Famille (NumAuto)
+identitée du responsable

Tbl_Adhérents
Id_Adherent (NumAuto)
Id_Famille
Id_Activité
Id_Caution
+identitée de l’adhérent

Tbl_ActivitésAdhérents
Id_ActivitéAdhérent (NumAuto)
Id_Adhérent
Id_Activité

Tbl_CotisationsDues
Id_CotisationDue
Montant

Cela suppose que dans le modèle, on doit trouver une table Catalogue des activités avec :

et

On devrait disposer d’un tarif (taux plein) pourquoi pas inclus dans la table des activités

Pour la tables CataloguesActivités et prix ce n’est pas très clair pour moi.

A quelle table doit être liée LA table CotisationsDues ?


Salutations

[ClaudeLELOUP]

Bonjour Jacques,

Prends l’habitude d’adopter des nommages sans caractères spéciaux (pas de lettres accentuées,espace…)
Lis, pour t’inspirer : conventions typographiques.




TblAdherents
IdAdherent (NumAuto)
IdFamille
IdActivite
Caution (un champ numérique qui contient le montant de la caution qui a été versée)
Licence (un champ qui indique l’année de la validité de sa licence)
+ les éléments de l’identité de l’adhérent

TblActivitesAdherents
Id_ActivitéAdhérent (NumAuto)
IdAdherent
IdActivite
DateDebut (la date depuis laquelle, l’adhérent pratique => pour le calcul des cotisations)
DateFin (vide, si encore en cours => cotisation à calculer)

Tbl_Activites
idActivite (clé autonum)
Activite (le nom en clair)
Cotisation (le tarif plein actuel pour cette activité)

A quelle table doit être liée LA table CotisationsDues ?

À Tbl_Paiements.

[jmde]

Bonjour Claude LELOUP,

Je joins une photo du schéma relationnel pour qu’on puisse discuter sur ce que l’on a fait.

De même je joins une autre photo que je viens de retrouver qui montre le cheminement d’une inscription manuelle.

Deux remarques :

Au début de chaque saison on doit partir avec une table AdhérentsActivités vide, donc le champ Datedebut et Datefin ne doit-il pas être mis dans la table Adhérents ?

Pour la nouvelle saison les personnes qui ne renouvellent pas n’apparaissent plus. Comment
Vais-je gérer le suivi des remboursements des cautions badge et Pass (vraiment, tu es contre une table caution).

Salutations

[Richard_35]

Bonjour Jmde et Claude (et excellente année 2012, pleine de ballade à vélo, Claude !),

Je me permets de m'immiscer, désolé...

Cela me semble dommage de doublonner les adresses dans deux tables différentes, notamment, si l'adhérent loge au même endroit que sa famille, ce qui, somme toute, est fréquent...

La notion d'adhérent multi-famille pourrait, également, être prise en compte.

Suggestion (souligné=clé primaire, #=clé étrangère) :

TblAdherent(IdAdherent, Nom, ...) ;
TblFamille(IdFamille, Nom, ...) ;
TblAdresse(IdAdresse, Numero, Voie, ...) ;
TblAdherent_Famille(#IdAdherent, #IdFamille, ...) ;
TblAdherent_Adresse(#IdAdherent, #IdAdresse, Principale (O/N), ...) ;
TblFamille_Adresse(#IdFamille, #IdAdresse, Principale (O/N), ...).

==> les relations sont relativement évidentes.

Mais bon, cela complique peut-être trop la chose...

[ClaudeLELOUP]

Je joins une photo du schéma relationnel pour qu’on puisse discuter sur ce que l’on a fait.

tblCivilité et tblVilles
Cela intervient dans une zone de liste, je ne les lierais pas comme tu le fais.

tblTarifs
Je ne comprends pas CpteProduit et Cpte Regroupement.

tblCotisationsDues
Je crois que tu devrais y trouver : l’année ;
une clé qui identifie le débiteur, selon le cas l’adhérent seul ou le responsable de la famille ;
le montant dû.

tblPaiements
idPaiement
idCotisationDue
date (à laquelle tu as encaissé)
Montant
Reference (pour toi retrouver la trace du paiement dans la compta)

tblBanques et tblModePaiements
Je n’en vois pas l’intérêt.

De même je joins une autre photo que je viens de retrouver qui montre le cheminement d’une inscription manuelle.

OK, cela interviendra pour concevoir la programmation du calcul des cotisations.

Au début de chaque saison on doit partir avec une table AdhérentsActivités vide

Personnellement, je ne procèderais pas ainsi.
D’autant qu’il y a sans doute des cotisations de l’exercice passé qui ne sont pas réglées.
Je m’organiserais pour travailler dans la continuité.

Comment vais-je gérer le suivi des remboursements des cautions badge et Pass

Dans tblAdherents tu as Badge et Pass :
- le champ est à zéro et l’adhérent est toujours actif => il doit verser ;
- le champ enregistre le montant de la caution et l’adhérent est toujours actif => tout va bien ;
- le champ enregistre le montant de la caution et l’adhérent n’est plus actif => tu dois lui rembourser (ou éventuellement, l’imputer sur des cotisations encore dues).

Je me permets de m'immiscer, désolé...

Mais tu aurais tort de nous priver de tes bons conseils !
Bien content de te croiser. Bonne année à toi !

Cela me semble dommage de doublonner les adresses dans deux tables différentes

Dans le schéma que je propose, il n’y a pas doublon.
S’il s’agit d’un adhérent « solo », il aura idFamille = 0.
S’il s’agit d’un membre d’une « famille », il pointera vers son responsable dont l’adresse peut être différente.

La notion d'adhérent multi-famille pourrait, également, être prise en compte

D’après ce que j’ai compris, cette notion de « famille » est utilisée pour le calcul d’une réduction des cotisations. Je suppose qu’un même adhérent ne peut pas cumuler des réductions en se faisant adopter plusieurs fois. Resquilleur, va !

[jmde]

Bonjour Claude LELOUP ?

tblCivilité et tblVilles
Cela intervient dans une zone de liste, je ne les lierais pas comme tu le fais

Mais alors comment ?

tblTarifs
Je ne comprends pas CpteProduit et Cpte Regroupement.

C’est pour faire les OD comptables, chaque prix a un compte comptable qui lui est propre. Je donnerai quelques exemples plus tard.

tblCotisationsDues
Je crois que tu devrais y trouver : l’année ;

Pas besoin puisque ça ne peut concerner qu’un exercice voir plus loint.

Une clé qui identifie le débiteur, selon le cas l’adhérent seul ou le responsable de la famille ;

Oui mes laquelle ? Moi j’aurais aimé la clé de la table famille, mais tu m’as fait enlever celle de l’adhérent seul.

tblBanques et tblModePaiements
Je n’en vois pas l’intérêt.

Oui mais j’ai besoin de savoir le non de la banque, le numéro de chèques, et si le paiement se fait en espèce.

Personnellement, je ne procèderais pas ainsi.
D’autant qu’il y a sans doute des cotisations de l’exercice passé qui ne sont pas réglées.

Non je ne peux vraiment pas faire cela, d’abord parce qu’on ne me le demande pas, puis parce que ce n’est pas une comptabilité que je fais.
Les tables cotisations et activités adhérents doivent être vides au début de la saison. Tout au plus je pourrais dupliquer les tables En N-1 avant de les vider.

Dans tblAdherents tu as Badge et Pass :

Il me faut absolument une table caution et remboursement des cautions avec numéro de chèques, Le mode de remboursement, la date.

A+

Salutations

[ClaudeLELOUP]

Bonjour Jacques,

Oui mes laquelle ? Moi j’aurais aimé la clé de la table famille, mais tu m’as fait enlever celle de l’adhérent seul.

Par exemple (idAdherant*1.000.000) + idFamille.

Mais, soyons clairs, pour ce poste comme pour les autres, j'ai essayé de te dire comment je m'y prendrais.
C'est évidemment à toi de décider.

À+.

[f-leb]

Bonjour à tous,

je m’immisce à mon tour mais j’ai une suggestion. Vous m’arrêtez si je suis à côté de la plaque ou si le travail est trop bien avancé pour faire marche arrière

Après avoir survolé la discussion concernant toutes ces personnes, qu’elles soient adhérentes ou pas, responsables de famille ou pas, finalement on peut dire que ce sont toutes des personnes
Je propose de mettre tout ce petit monde dans la table Personne (en tassant bien…)


Si une personne est un jeune dont on doit renseigner le responsable de famille, on le fait en ajoutant une ligne dans la table PersonneResponsable (la personne responsable étant aussi une personne vous me suivez !).

Toutes les personnes ne sont pas forcément des adhérents mais si c’est le cas, on complète la table Adherent.

Ensuite, on peut raccorder les autres tables à la table générique Personne, ou à la table des adhérents ou encore à la table des personnes responsables selon les règles de gestion.

Notez qu’avec les assistants, il est assez facile de préparer des requêtes permettant :
- de retrouver la personne responsable d’un jeune en particulier
- de lister tous les jeunes pris en charge par un responsable en particulier
- de lister seulement les personnes qui sont des adhérents ou au contraire lister les personnes qui ne sont pas des adhérents, etc…

Voilà voilà…
Bon week-end.

[ClaudeLELOUP]

Fabien.

[f-leb]

bonjour Claude,

attendons la réaction de jmde et ne crions pas victoire tout de suite...

Envoyé par ClaudeLELOUP

Personnellement, je ne procèderais pas ainsi.
D’autant qu’il y a sans doute des cotisations de l’exercice passé qui ne sont pas réglées.
Je m’organiserais pour travailler dans la continuité.

Je ferais pareil. On rajoute un champ/une table pour prendre en compte les saisons, ou un drapeau (un champ booléen ?) pour "désactiver" un adhérent.

Si le volume de données devient trop important, on peut mettre en place une procédure de suppression/archivage pour les enregistrements les plus anciens ou les adhérents "désactivés" en s'assurant que toutes les cotisations sont réglées.

[Richard_35]

Bonjour Fabien et Claude,

Envoyé par Fabien

Je propose de mettre tout ce petit monde dans la table Personne (en tassant bien…)

==> ... ... ... ... sur la forme ;

==> ... ... sur le fond.

[jmde]

Bonjour ClaudeLELOUP,

Je reprends le projet de schéma que différents problèmes mon tenu éloigné.

La solution de f-leb semble apporter l’unanimité, et ces celle-là que je vais adopter. Il est dailleur plus pertinent de parler de table personnes plutôt que de table familles.

Donc un grand merci à toi, ainsi qu’à f-leb, et Richard.

Je mettrais le tag résolu un peu plus tard, pour le cas où j’aurais encore besoin de vous.

Salutations

Jacques