Hello there,
Une première personne m'a répondu pour préciser la demande et peut-être
proposer un devis.
Ça m'a fait détailler les choses, je partage ici, c'est peut-être pas
adapté ? Toujours dans l'idée que ça peut inspirer du monde,
correspondre ou ressembler à vos besoin, pour créer des outils les plus
polyvalents possible... et les co-financer :)
À suivre !
Fanch
=========
J'essaie d'affiner les paramètres possibles :
UnE bénéficiaire peut utiliser différents véhicules
Config :
- un véhicule, c'est : id_ouature, nom, coût moyen kilométrique, un
compte 706&id_ouature
- unE bénéficiaire, c'est : [les champs de la fiche membre, incluant un
champ oui/non cotisation au service], un compte usager 410&id_membre,
solde du compte 410&id_membre
- une méthode de calcul programmable pouvant utiliser les champs de
véhicule, bénéficiaire et trajet
Saisies :
- un trajet, c'est : id_ouature, id_membre, date-heure début, date-heure
fin, km parcourus
[[Note : Pour le moment on n'est pas dans le détail des trajets et on ne
tient compte que de la distance parcourue , mais à terme le prix d'usage
pourrait tenir compte de la durée d'utilisation : ces infos pourraient
être envoyées directement par un ordinateur embarqué, avec accès par
badge RFID id_membre. ]]
- la méthode de calcul renvoie le prix du trajet et l'écrit au débit du
compte 410&id_membre et au crédit du compte 706&id_ouature lié
- le résultat du calcul est écrit en tant que nombre, fixé au jour du
calcul : si les variables du calcul changent ultérieurement en config,
le résultat n'est pas recalculé
- un règlement de bénéficiaire est saisi en compta au débit du compte 5
correspondant et au crédit du compte 410&id_membre
- à chaque opération le concernant, le champ solde du compte
410&id_membre est actualisé
Pour ce que je comprends qu'il est pertinent de préciser, je crois que
l'essentiel est là.
La gestion des charges, comptes 6xy&id_ouature, pour chaque véhicule,
peut se faire en compta analytique, avec un projet par véhicule, un
projet pour des charges communes...
Après évidemment on peut imaginer toutes sortes de raffinements pour la
gestion : une synthèse par membre de toutes les opérations et le solde,
faire des envois mail de relevés de compte en sélectionnant par champs
(par exemple solde du compte 410&id_membre <=0, ou tous les membres
ayant utilisé tel véhicule)... C'est peut-être pas spécifique, ça
rejoint la fonctionnalité base de requêtes SQL prédéfinies, déjà évoquée
par ailleurs, mais avoir une présentation en document exportable serait
super.
Aucune idée de la meilleure structure à prévoir pour la plus grande
polyvalence... Ça ressemble :
- aux cotisations qui "peuvent également être utilisées pour suivre les
activités auxquelles sont inscrits les membres de l'association", il y a
le lien avec la compta ;
[[ mais un plugin doit "NE PAS ajouter, modifier ou supprimer
directement des données dans la base de données de Garradin (hormis dans
sa propre table)" ? ]]
- à la fiche membre dont les champs sont entièrement paramétrables.
Et si on remplace "véhicule" par "n'importe quel bien ou
service", on
obtient un outil hyper polyvalent, pour des usages collectifs récurrents
et facturés individuellement, en fonction de variables paramétrables
liées aux biens ou services et aux bénéficiaires.
Pour synthétiser et aller vers la polyvalence :
En fait les tables : véhicules, bénéficiaire ou usagerE, trajet, seraient idéalement
définies sur mesure comme la fiche membre de Garradin, avec une variété plus grande de
type de champ : manque en particulier dans la fiche membre le type nombre décimal pour le
champ coût moyen kilométrique de la table véhicule par exemple, ou pour définir un
champ coefficient tarifaire dans la table usagerE.
On entrevoit les fonctionnalités génériques du plugin, qui doit permettre de définir :
- une nouvelle table du plugin en la nommant, et en lui attribuant autant de champs
qu'on veut, des types les plus variés ;
- une nouvelle méthode de calcul pouvant utiliser tous les champs existants dans les
tables de la base (de Garradin et du plugin) ;
- un nouveau formulaire de saisie pouvant porter sur tous les champs existants du plugin
et incluant les méthodes de calculs existantes.
Un plugin - base de données programmable, en somme ?
//////////////
D'où la structure de tables que je proposais :
- un véhicule, c'est : id_ouature, nom, coût moyen kilométrique, un compte
706&id_ouature
- unE bénéficiaire, c'est : [les champs de la fiche membre, incluant un champ
oui/non cotisation au service], un compte usager 410&id_membre
- un trajet, c'est : id_ouature, id_membre, date-heure début, date-heure fin, km
parcourus
Et il faut rajouter une méthode de calcul programmable pouvant utiliser les champs de
véhicule, bénéficiaire et trajet pour renvoyer le coût du trajet.
Et en l'occurrence ça se passerait comme ça :
- la méthode de calcul renvoie le coût du trajet et l'écrit au débit du compte
410&id_membre et au crédit du compte 706&id_ouature
- un règlement de bénéficiaire est saisi en compta au débit du compte 5 correspondant
et au crédit du compte 410&id_membre
- à chaque opération le concernant, le champ solde du compte 410&id_membre est
actualisé