|
Taille: 3160
Commentaire: sauvegarde temporaire... suite tout à l'heure
|
Taille: 5550
Commentaire:
|
| Texte supprimé. | Texte ajouté. |
| Ligne 16: | Ligne 16: |
| * on veut gérer des usagers, il faut donc '''une table''' pour les identifier | * on veut gérer des usagers, il faut donc '''une base de données''' pour les enregistrer |
| Ligne 28: | Ligne 28: |
| * on souhaiterait pouvoir gérer les quota d'impression (via CUPS) * on souhaiterait pouvoir gérer les paiements reçus (abonnement, commande de document, remboursement, état de caisse, bilan mensuel) |
|
| Ligne 33: | Ligne 35: |
| == Les objets de base et leurs relations == | == La base de données == |
| Ligne 37: | Ligne 39: |
| ---- <!> '''Ce qui suit ne doit pas être pris en compte : ce sont des notes temporaires !''' <!> |
Il sert à pouvoir identifier un utilisateur dans la « Vraie Vie »™. |
| Ligne 55: | Ligne 55: |
| ||'''commentaire'''||Un commentaire éventuel|| === L'objet « abonnement » === Il sert à enregistrer la durée d'activité d'un utilisateur. ||'''__id__'''||Identifiant unique d'un abonnement|| ||'''id_personne'''||Identifiant de l'utilisateur concerné|| ||'''date_debut'''||Date de début d'activité|| ||'''date_fin'''||Date de fin d'activité|| == Extension de gestion financière == <!> voir le problème de la monnaie ! <!> === L'objet « paiement_recu » === Il sert à enregistrer le reçu d'un paiement, que ce soit en crédit ou en débit. ||'''__id__'''||Identifiant unique d'un reçu|| ||'''id_personne'''||Identifiant de l'utilisateur recevant le reçu|| ||'''id_implantation'''||Identifiant de l'implantation où est émis le reçu|| ||'''date_saisie'''||Date de saisie du reçu|| ||'''credit'''||Valeur du reçu (pour un versement)|| ||'''debit'''||Valeur du reçu (pour un remboursement)|| ||'''id_recu_origine'''||Lien vers un reçu antérieur dans le cas d'un remboursement après clôture financière|| Note : `credit` indique la somme perçue et `debit` la somme remboursée, dans le même mois ; les remboursements d'un mois sur l'autre devant faire l'objet d'un nouveau reçu pour des raisons de clôture financière mensuelle. Cela permet ensuite de générer un « état de caisse » mensuel qui correspond effectivement au contenu de la caisse à la fin de chaque mois. === L'objet « paiement_abonnement » === Il sert à enregistrer le paiement de l'abonnement. ||'''__id__'''||Identifiant unique d'un paiement d'abonnement|| ||'''id_recu'''||Identifiant du reçu pour le paiement|| ||'''id_abonnement'''||Identifiant de l'abonnement concerné|| ||'''date_paiement'''||Date du paiement|| ||'''prix'''||Valeur du paiement|| === L'objet « paiement_commande » === Il sert à enregistrer le paiement d'une commande. ||'''__id__'''||Identifiant unique d'un paiement de commande|| ||'''id_recu'''||Identifiant du reçu pour le paiement|| ||'''id_commande'''||Identifiant de la commande concernée|| ||'''date_paiement'''||Date du paiement|| ||'''prix'''||Valeur du paiement|| ---- <!> '''Ce qui suit ne doit pas être pris en compte : ce sont des notes temporaires !''' <!> |
|
| Ligne 57: | Ligne 109: |
| * des objets `personne` * des objets `abonnement` * des objets `groupes` * des objets `comptes` * des objets `reçus` |
* des objets `groupe` * des objets `compte` * des objets `commande` |
Cette page présente ma proposition de version 0. -- JeanChristopheAndré
Introduction
Ma vision des choses :
- le logiciel doit comprendre un noyau dur et des extensions
le noyau dur doit consister en ce qui est indispensable, commun à toutes les situations
les extensions consistant alors en ce qui peut être utile d'ajouter, suivant le contexte
- les extensions doivent donc être modulaires, configurables et pouvoir être (dés)activées, selon les besoins
toutes les informations doivent être dans une unique base de données, source pour tout le reste
Partant de là on peut détailler :
- le noyau dur :
on veut gérer des usagers, il faut donc une base de données pour les enregistrer
on veut confier cette gestion à des non-techniciens, il faut donc une interface web
on veut pouvoir étendre les fonctionnalités, il faut donc définir une API
les extensions indispensables :
on veut pouvoir générer une base d'authentification ["MySQL"] (avec libnss-mysql-bg)
on veut pouvoir générer une base d'authentification ["Samba"] (dans MySQL ou des fichiers, via pdbedit)
- on veut pouvoir générer une base d'adéls pour ["postfix"] (dans MySQL ou des fichiers)
- on veut pouvoir générer une base de boîtes aux lettres pour ["dovecot"] (dans MySQL ou des fichiers)
les extensions souhaitées :
on souhaiterait pouvoir générer une base d'authentification ["NIS"] (dans /etc/passwd, /etc/shadow et /etc/group)
- on souhaiterait pouvoir générer une base de boîtes aux lettres pour ["courier"] (dans MySQL ou des fichiers)
- on souhaiterait pouvoir intervenir depuis la ligne de commande (pas moi...)
- on souhaiterait pouvoir gérer les quota d'impression (via CUPS)
- on souhaiterait pouvoir gérer les paiements reçus (abonnement, commande de document, remboursement, état de caisse, bilan mensuel)
les extensions possibles :
- on souhaiterait pouvoir générer une base d'authentification ["LDAP"] (mais... finalement non)
Le noyau dur
La base de données
L'objet « personne »
Il sert à pouvoir identifier un utilisateur dans la « Vraie Vie »™.
id |
Identifiant unique d'une personne |
nom |
Son(ses) nom(s) tel(s) qu'indiqué(s) sur une pièce d'identité |
prenom |
Son(ses) prénom(s) tel(s) qu'indiqué(s) sur une pièce d'identité |
nom_affichage |
Le nom d'affichage souhaité |
genre |
Son genre |
date_naissance |
Sa date de naissance |
adel |
Son adél de contact préférée |
adel_alternative |
Son adél de contact alternative (en cas d'injoignabilité sur la précédente) |
adresse_personnelle |
Son adresse personnelle |
adresse_professionnelle |
Son adresse professionnelle |
telephone_personnel |
Son numéro de téléphone personnel |
telephone_professionnel |
Son numéro de téléphone professionnel |
telephone_mobile |
Son numéro de téléphone mobile |
telephone_fax |
Son numéro de fax |
commentaire |
Un commentaire éventuel |
L'objet « abonnement »
Il sert à enregistrer la durée d'activité d'un utilisateur.
id |
Identifiant unique d'un abonnement |
id_personne |
Identifiant de l'utilisateur concerné |
date_debut |
Date de début d'activité |
date_fin |
Date de fin d'activité |
Extension de gestion financière
voir le problème de la monnaie !
L'objet « paiement_recu »
Il sert à enregistrer le reçu d'un paiement, que ce soit en crédit ou en débit.
id |
Identifiant unique d'un reçu |
id_personne |
Identifiant de l'utilisateur recevant le reçu |
id_implantation |
Identifiant de l'implantation où est émis le reçu |
date_saisie |
Date de saisie du reçu |
credit |
Valeur du reçu (pour un versement) |
debit |
Valeur du reçu (pour un remboursement) |
id_recu_origine |
Lien vers un reçu antérieur dans le cas d'un remboursement après clôture financière |
Note : credit indique la somme perçue et debit la somme remboursée, dans le même mois ; les remboursements d'un mois sur l'autre devant faire l'objet d'un nouveau reçu pour des raisons de clôture financière mensuelle. Cela permet ensuite de générer un « état de caisse » mensuel qui correspond effectivement au contenu de la caisse à la fin de chaque mois.
L'objet « paiement_abonnement »
Il sert à enregistrer le paiement de l'abonnement.
id |
Identifiant unique d'un paiement d'abonnement |
id_recu |
Identifiant du reçu pour le paiement |
id_abonnement |
Identifiant de l'abonnement concerné |
date_paiement |
Date du paiement |
prix |
Valeur du paiement |
L'objet « paiement_commande »
Il sert à enregistrer le paiement d'une commande.
id |
Identifiant unique d'un paiement de commande |
id_recu |
Identifiant du reçu pour le paiement |
id_commande |
Identifiant de la commande concernée |
date_paiement |
Date du paiement |
prix |
Valeur du paiement |
Ce qui suit ne doit pas être pris en compte : ce sont des notes temporaires !
Nous aurons à manipuler :
des objets groupe
des objets compte
des objets commande