Discussion :

[robich]

Bonjour Robert,

voilà un a perçu des relations après rectification

[jimbolion]

robich,

Bonjour

Pour défricher le terrain car je pense que deux avis valent mieux qu'un en terme de modélisation, et que cette partie conditionne tout ton projet, je soumets quelques remarques.

1. Une table des codes postaux est t-elle envisagée ? Elle procure de multiples intérêts (envoi de courrier, facilité de saisie...). Dans ce cas pense aux bureaux distributeurs et communes rattachés (un code postal n communes).

2. Le fait de redescendre dans ta table Contrat le numéro du client procure t'il un intérêt quelconque ? Par héritage tu aurais pu le retrouver grâce à la table conducteur. Ce n'est pas forcément une erreur, dans des solutions très complexes (exemple mode hébergé) et l'utilisation récurrentes de requêtes peuvent amener à ce genre de décision.

3. Entre contrats et réservations, je constate une relation 1 à n. J'en déduis donc que pour un contrat x il peut y avoir plusieurs réservations possibles. Dans ce cas parfait, puisque la relation 1 à n est bien indiqué avec la table véhicules. Mais cela revêt une importance (voir point suivant)

4. Tu associes la table sinistre à un contrat. Cela et suivant ma remarque du point 3 t'obliges donc à inscrire dans cette table sinistre le véhicule.
Pourquoi ne pas faire redescendre alors directement ta relation entre tables sinistres et réservations. (tu t'affranchis donc d'une clé et donc de performances accrues). Intérêt supplémentaire à cette relation et non des moindres, c'est qu'elle te permet également de gérer la date sinistre. Dans ton modèle t'es tu posé la question suivante :

Sur le contrat x le conducteur y a pris deux réservations sur la même voiture dans la même journée. Dans ce cas ta table sinistre ne peut déterminer de quelle réservation il s'agit...

5. La table T_Jour se sent orpheline

Pour le reste il y a de la réflexion, j'en conjure... Robert verra peut-être d'autres choses...

Bon courage pour la partie développement... et à bientôt

JimBoLion

[robich]

merci Jimboliom pour tes remarques, pour les tables contrats et réservations comment peux-ton changé pour avoir une contrat pour une réservation, les autres modif je l'ai changé, pour "La table T_Jour se sent orpheline" je doit lié avec quel table?

[Robert1957]

Bonjour robich, Jean-Marie,

2. Le fait de redescendre dans ta table Contrat le numéro du client procure t'il un intérêt quelconque ? Par héritage tu aurais pu le retrouver grâce à la table conducteur. Ce n'est pas forcément une erreur, dans des solutions très complexes (exemple mode hébergé) et l'utilisation récurrentes de requêtes peuvent amener à ce genre de décision.

Je crois que c'est une erreur au niveau de la relation. Si je comprend bien ce que veux faire robich, un contrat peu avoir plusieurs conducteurs et un client peu avoir plusieurs contrat. Donc la table Conducteur est une table intermédiaire pour faire une relation plusieurs à plusieurs. Est-ce bien ça robich? Si c'est le cas la table contrat n'a pas besoin de id_conducteur_FK et la table Table_Conducteur devrait avoir au lieu du champ Id_Conducteur un champ Id_Contrat_FK. La relation un contrat plusieurs conducteurs. Maintenant est-ce que dans un contrat il y a un client responsable, si oui le champ Id_Client_FK est nécessaire pour identifier le client relié à ce contrat ou dans la table Conducteur un champ oui/non pour identifier le conducteur qui signe le contrat.

Sur le contrat x le conducteur y a pris deux réservations sur la même voiture dans la même journée. Dans ce cas ta table sinistre ne peut déterminer de quelle réservation il s'agit...

Très bien vu

pour les tables contrats et réservations comment peux-ton changé pour avoir une contrat pour une réservation

Si un contrat = une réservation je ne suis pas certain du besoin de la table réservation. Dans la table contrat tu pourrais avoir un statut qui indique en réservation et en contrat ou quelque chose du genre.

5. La table T_Jour se sent orpheline

Pour celle-là j'ai un peu d'avance sur toi Jean-Marie. J'ai aidé robich pour un planning et c'est la table pour le formulaire de planning comme dans le tuto de ce nom.

Bonne journée

[Robert1957]

Bonjour Jean-Marie,

Pour défricher le terrain car je pense que deux avis valent mieux qu'un en terme de modélisation, et que cette partie conditionne tout ton projet, je soumets quelques remarques.

Je suis tout à fait d'accord avec toi. C'est la partie la plus importante et j'ai vu certaines de tes discussions et ton avis est toujours très juste.

Donc ne te gêne pas j'apprend en même temps

Bonne journée

[robich]

Bonjour Robert, Jimbolion

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Si je comprend bien ce que veux faire robich, un contrat peu avoir plusieurs conducteurs et un client peu avoir plusieurs contrat. Donc la table Conducteur est une table intermédiaire pour faire une relation plusieurs à plusieurs. Est-ce bien ça robich

oui c'est bien ça Robert

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Maintenant est-ce que dans un contrat il y a un client responsable, si oui le champ Id_Client_FK est nécessaire pour identifier le client relié à ce contrat ou dans la table Conducteur un champ oui/non pour identifier le conducteur qui signe le contrat.

oui

concernant la table réservation je croix que je vous le laissé ça peut arrivé qu'il y'a une réservation pour plusieurs contrat.
le reste j'ai fait le changement

dans le cas si j'ajoute Une table des codes postaux je doit lié avec quelles tables?

[jimbolion]

Rob et Rob,

concernant la table réservation je croix que je vous le laissé ça peut arrivé qu'il y'a une réservation pour plusieurs contrat.
le reste j'ai fait le changement

dans le cas si j'ajoute Une table des codes postaux je doit lié avec quelles tables?

une table Code Postaux (ID, CodePostal, Commune,TypeCommune)

typeCommune = 1 ou 2

une table TypeDecommunes : 1 = (bureau distributeur) et 2 (commune rattachée)

Dans la table Client, l'id_CodePostal_FK en relation avec l'id de la table codepostaux

Pour la mise en place du formulaire : on tape le code :

possibilité 1 : Une seule entrée on affiche le code + la ville
possibilité 2 : pas d'entrée on affiche le formulaire création
possibilité 3 : plusieurs entrées, on affiche le formulaire présentant la liste des communes, première ligne bureau distributeur, et ensuite trié par commune.

Prévoir existence d'une ou plusieurs entrées avec création d'une nouvelle commune...

Peut tu nous mettre à disposition les nouvelles relations ?

JimBoLion

[robich]

Bonsoir Jimbolion Robert

voilà en pièce jointe les modifications j'espère que j'ai tout met vos propositions, par contre la table type de commune je doit la lié avec quelles tables?

[Robert1957]

Bonjour robich, Jean-Marie,

Quelque petite chose: Les noms de tes tables je les ferais tous de la même façon soit T_Contrat au lieu de Table_Contrat (mon gout personnel). La table T_Réservation deviendrait T_Reservation, je n'aime pas les "é". Dans la table Facture il n'y a pas de date est-ce que ça veut dire que la date de facturation est toujours = à la date de contrat? Dans la table T_Réservation il y a le champ Date_Debut et Heure_D est-ce vraiment nécessaire? Un champ date peut contenir les deux informations dans le même champ. Question de gout perso je crois. Dans la table Contrat il n'y a pas de champ pour le kilométrage, chaque fois que j'ai loué une voiture on inscrivait le km du début et celui de la fin? (mais je ne connais rien à la location de voiture sauf avoir été client)

Pour les communes je laisse Jean-Marie te répondre parce que chez nous un code postal = au max une ville. Et les grande ville ont plusieurs code postaux qui d’ailleurs sont différents de chez-vous. Mon code postal = J0T 1L0.

Bonne journée

[robich]

merci Robert,

je suis bien d'accord avec toi qu'on saisi le kilométrage au moment qu'end prend la voiture ou en le rond, j'ai rectifier ça avec uniformité des noms des tables.

Robich

[jimbolion]

Robert1957, robich

Sur les règles de nommage une table (=une collection d'enregistrements) on met un S

Exemple T_Contrats

le nom du champ au singulier (ID_contrat) et Camel Case : http://fr.wikipedia.org/wiki/CamelCase

Mais là c'est du pinaillage.... pas d'accent, pas d'espaces sont des règles essentielles

Pour le reste je vous fait un retour dans la journée demain.

Peut-on également avoir les mêmes conducteurs pour plusieurs clients (genre courtiers). Faut t-il gérer ce cas ?

Je valide le reste du modèle dans la journée demain.

Bonne soirée à vous deux

JimBoLion

[robich]

j'ai trouvé un logiciel que je trouve vraiment complet mais je n'arrive pas à posté la démo ici le nom (azloc) et je veux m'inspirer de quelque fonctionnalité dedans mais je ne sais pas si c'est réalisable sur Access (les placements de icones, la façon de recherche client voiture etc...?

[robich]

jimbolion, Robert1957,

Peut-on avoir plusieurs conducteurs pour la même réservation

oui au moins 2 conducteurs

Peut-on également avoir les mêmes conducteurs pour plusieurs clients (genre courtiers). Faut t-il gérer ce cas

non juste des locations de voitures normal sans courtier.

mrci pour votre Aide encore

[Robert1957]

Bonjour robich,

Je viens d'aller voir, c'est tout à fait faisable mais c'est assez ambitieux comme projet. Il y a beaucoup de travail pour réaliser un tel projet. Je n'ai pas télécharger la version d'essai puisque je n'aurai pas réellement le temps de regarder tout ça mais de ce que j'ai vu il n'y a pas de problème Access peut gérer tout ça.

Bonne soirée

[jimbolion]

Robich, Robert

J'ai posément repris l'ensemble des contraintes définies sur ce sujet. J'en arrive à la conclusion que tous les cas de situation doivent être gérées.

Je soumets Robert à ta validation l'architecture suivante :



Quelques explications :

Le modèle reprend toutes les conditions évoquées sur nos points précédents :

1. Relations Code Postal -> commune (aucune difficulté). Nous reviendrons sur ce point lors de la constitution des formulaires.

2. Un client peut établir plusieurs contrats (Relation 1 à plusieurs entre clients et contrats) - Aucune difficulté

3. Un contrat peut générer n réservations (Relation 1 à plusieurs entre Contrats et Réservations) - Aucune difficulté. Par jointure on peut donc établir la liste des réservations pour un client sur une période. But atteint

4. Pour une réservation 1 à n conducteurs. Difficulté moyenne
a) J'ai donc créé une table conducteurs avec une relation sur la table client. Les informations nom et prenom de la table conducteurs ne redondent pas nécessairement avec la table client (le client n'est peut-être pas le conducteur, le client est une Entreprise....). De ce fait, et sans vouloir gérer la gestion des courtiers (cas marginal), on peut créer deux conducteurs pour la même personne affectée à des clients différents. Si ce cas devait se généraliser, il faudrait intercaler une table de jonction (à priori non nécessaire dixit Robich).
b) Création d'une table de jonction (TJ_ConducteursReservations). Cette table nous permet pour une réservation donnée de sélectionner l'ensemble des conducteurs affectées. En réfléchissant bien, j'imagine une Entreprise avec n chauffeurs mais seulement 1 affecté à une réservation (j'imagine déjà la conception du formulaire avec ListBox proposant la liste des conducteurs par client). Cette table permet donc d'affecter de un à n conducteurs sur une réservation. La question de l'index s'est posé : nous aurions pu choisir un index composite (conducteur + réservation), j'ai choisi de recréer un index afin de faciliter l'intégration d'une clé étrangère dans la table Sinistres.

5. Concernant les sinistres, une clé étrangère héritant de la table TJ_ConducteursReservations (d'où la clé unique vu au point 4). Cette relation permet d'identifier le conducteur incriminé dans la gestion du sinistre sur une réservation. Aucune difficulté

6. Les interventions. J'ai rajouté une table de nature type interventions. La vidange, une intervention courante ne va pas être ressaisi à chaque fois. Détail bénin.

7. Concernant les factures. Une facture est composée de 1 à n contrats. Nous aurons donc une table de jonction permettant d'associer à n contrats une seule facture (TJ_ContratsFactures). Difficulté moyenne

J'ai pris posément le temps de réfléchir à tout les cas envisagés, je pense que le modèle ne souffre d'aucune faille ! sauf nouvelle information de la part de Robich. Je n'ai pas redescendu l'exhaustivité des champs, vous comprendrez...

Robert, tu me diras ce que tu en penses...
Robich, regarde comment sont construits les règles de nommage. Tu verras qu'en appliquant de suite de bonnes pratiques, tu vas te simplifier la vie après.. un peu de rigueur au démarrage mais quels gains de temps après. La viabilité de ton projet est basé sur la modélisation, j'ai quelques anecdotes savoureuses sur des modèles mal pensés (et c'est souvent sur les dernières briques du programme qu'on se rend compte de ses erreurs : états, statistiques...) mais c'est un autre sujet...
Robich, pour confirmer les dires de Robert le projet est ambitieux... mais réalisable ! Il va falloir travailler sur beaucoup de domaines (sql, VBA, formulaires...). De nombreuses solutions sont données dans la Faq ou les articles, n'hésite pas à les consulter. Des membres seront là pour t'aider à mener à bien ton projet.


Bonne journée à tous les deux

JimBoLion

[robich]

Bonjour Jombilion, Robert

merci pour le travail que tu as réaliser, pour plus de détails sur mon projet en commençant tout simplement par un client qui appel pour réservé une voiture (il peut donné un a compte) pour une période j'ouvre mon planning (réservation (VHL)) je choisi la voiture demandé par le client je clic sur la première date il m'ouvre une formulaire pour saisir les dates et les heures avec un couleur orange par exemple je valide il m'ouvre le formulaire pour saisir justes le nom prénom dans un premier temps je confirme avec un case à couché ou faire l'opération à l'envers l'essentiel qu'il y'a une liaison entre le planning et le formulaire.
il arrive le client le jour prévu donc j'ouvre le formulaire je complète les renseignements et je valide case à coché, la réservation bascule en contrat dis la validation et au même temps sur la planning couleur bascule en vert pour savoir que cette voiture et déjà en location. donc le client paye et donne une caution ça peut être un chèque ou liquide.
sur le formulaire réservation ou contrat je croix qui doit avoir des sous-formulaire pour voiture(saisir le model matriculation et KLM D et R), + 2 conducteur, j'avais pensé s'il est possible d'ajouter la résumé facturation juste total en euro pendant la période qui loue.
je clic sur ok ou imprimé la facture détaillé, dans le cas ou l'intéressé fait un accident je suis en mesure de saisir tout et savoir la prochaine fois qui à fait une accident.

concernant l'application peut être utilisant le ruban mieux que le menu je croix (disponibilité (par jour, par période)), réservation ( crée, modifier, supprimé, historique,confirmé), contrat (crée, modifier, supprimé historique), Analyse ( jour, mois, année) pour savoir les chiffres des contrats avec le montant soit journalier ou du mois ou par année.
enfin un fond de caisse au forme d'une formulaire qui est lié automatiquement avec les entrées (facture) et les sortie (intervention) pour compte en réel l'argent.

c'est à peu prés ce que je veux dans ce projet je croix que le model de jombilion prend la totalité ou pas mal du chose que j'ai cité. Vous prenez quoi de ce que j'ai proposé si vous avez d'autre aidez je suis preneur.

merci encore à vous deux

[jimbolion]

robich,

Pas de problèmes particulier ! Je vois les enchaînements. L'ordre hiérarchique du modèle peut se prendre à l'envers dans la châine de traitement, mais dans l'injection dans les tables elle suit un ordre logique

1. Vérification dans le planning (date et heure) -> infos sur le tarif
2. Si ok j'affiche le client ou le crée
3. je crée un nouveau contrat (ou j'associe à un contrat existant) -> cette étape peut être transparente (sauf si saisie d'acompte)
4. Je crée la réservation
5. Je saisis les conducteurs (cette étape peut se faire le jour de la prise du véhicule) -> optionnel
6. Le jour de la réservation (modification / suppression / ajout de conducteurs), on renseigne les infos concernant nb km...
7. Jour de la restitution -> facture -> encaissements
7. pour le reste c'est du sinistre, de l'entretien...

enfin un fond de caisse au forme d'une formulaire qui est lié automatiquement avec les entrées (facture) et les sortie (intervention) pour compte en réel l'argent.

il faut si tu souhaites gérer les encaissements une table règlements mais attention on peut avoir des règlements pour 1 à n factures dans le principe et de 1 à n règlements pour la même facture. Concernant le fonds de caisse, c'est un peu comme une gestion de stocks, des entrées d'espèces + des sorties d'espèces + gestion des vols dans la caisse, des dépenses pris sur les espèces de la caisse. Dans ce cas il faut envisager aussi les remises d'Espèces et tant qu'à faire la gestion des chèques (bordereaux). Il faut également envisager (on touche à du concret) les modifications de règlements et les erreurs d'encaissements. Je connais parfaitement cette problématique, car je la pratique tous les jours.

La partie caisse complexifie énormément ton modèle, mais avec l'énorme avantage que cette partie là peut être rajoutée par la suite.

Une question cependant, combien estimes tu ton temps de travail sur ce projet ? (en partant de 0)

Je te donnerais mon avis ensuite pour une personne comme moi ou Robert !

JimBoLion

[robich]

Bonjour Jombilion,

concernant la durée de projet pour ma part je doit le terminé pour fin mai!! pour une phase d'essaye mois juin est ce que c'est réalisable?

[jimbolion]

Robich,

Au delà de l'applicatif il y a un tas de choses à gérer ! Gestion de la dorsale et frontale, statistiques... et le fameux planning

C'est plus qu'ambitieux...

C'est le temps que je me donnerai en partant de zéro en terme d'outils... cela fait 3 mois !

Il faut tenir compte des tests, correctifs et peut être documentation... et attention à ne pas se laisser déborder. Dans un projet au fur et à mesure de la réalisation, on te demandera toujours des petites choses bien sympa... donc définir le périmètre initial (et ne pas en sortir règle universelle)

1. Ton modèle (quasi terminé)
2. Test écrans : Enchaînements -> dessins succints
3. Ta charte (boutons, couleur) : quelque chose d'uniforme
4. Tes états (lister les documents)
5. Tes statistiques

Une fois que tout est clair (et pour cela bien 2-3 semaines de réflexion)

Ensuite tu quantifies le nombre de formulaires :

(complexes : suivant ton expérience entre 1 et 3 jours)
(moyens : suivant ton expérience entre 0.5 jours et 1 jour)
(simples : entre 1 heure et 4 heures) - Boîte de dialogue, codes postaux, natures interventions...

Les fonctions hors formulaires (fonctions accessibles depuis tous les formulaires : exemple injection / suppression....) - Compter 1 semaine
les outils (liaison frontale - dorsale) : 1 Jour / boîte de dialogue.. tu trouveras de nombreux exemples prêts à l'emploi

Etats à décliner : complexes (1.5 J) / simples (0.5 Jours)

Les requêtes stockées (environ 20 mn par requête)

Les statistiques (1 heure par stat)

Le planning (toutes les opérations : 1 semaine)

Tu fais la somme et tu rajoutes 20% pour les correctifs (d'où l'utilisation de fonctions déportées avec passage d'arguments : on ne réécrit pas 10 fois la même fonction pour faire la même chose ou presque) - Pour les tests, toi seul connaît les points critiques donc orienter les tests pour plus d'efficacité (10 % du temps total) - La documentation 10 %


Mais cela suppose une bonne pratique (pas de temps de latence entre chaque découpage). La réponse à une question sur un forum (comme DVP) n'est pas réactif.

Tu fais la somme de tout (mais n'oublies rien) et tu obtiens des valeurs moyennes constatées sur la conduite de projets. En fait pour les phases de débordements, les réunions et explications tu rajoutes 15 % au total global calculé.

Voili, voilou

JimBoLion

[robich]

jimbolion,

je n'ai pas pensé qui prendra tout ce temps mais si il faut plus de temps il faut!! mais je veut essayé de le finir pour fin mai et de ne pas compliqué les choses, d'ailleurs il faut un truc simple que tout le monde sache travaillé dessus au moins.
au moins pour la planning j'en ai la même model presque que j'ai fait avec Robert juste à l'adapter pur ce projet.
concernant l'encaissement et le fond de caisse en peu l'adapter à ton model?