Discussion :

[f-leb]

Bonjour à tous,

je peux jouer avec vous ? J'ai quelques questions...

La société est composé du Siège Social, de l’Établissement AAA, l'établissement BBB, l'établissement CCC (avec possibilité de créer de nouveaux établissements) .

J'ai un doute sur le périmètre comme je ne vois pas de table Société, si l'application concerne une société ou plusieurs sociétés (avec chacune leurs établissements) ?

Pour chaque établissement, les pôles prédéfinis sont les même.
Les pôles sont au nombre de 4 : Administration, Logistique, Technique et Médical
Il y a un pôle administratif par établissement

Chaque établissement a donc exactement les 4 pôles si j'ai bien compris, non ? Il y a-t-il une possibilité qu'un établissement ne possède pas de pôle "logistique" par exemple ?

Chaque établissement via un pôle, commande les produits auprès des fournisseurs rattachés au pôle.
Les pôles sont là pour cloisonner chaque type de produit acheté. Ainsi pour chaque pôle, un ou plusieurs fournisseurs y sont associés. Pour l'ensemble de la société les fournisseurs restent les même.

Il faudrait donc associer fournisseurs&pôles, voire avec les sociétés s'il y en a plusieurs (cf. ma 1ère question). À voir...

- l'établissement BBB commande "une boite de pansement" chez le fournisseur "MERCURO" qui par nature est lié au pôle "Médical"
Pour l'ensemble de la société les fournisseurs restent les même.

Cela signifie que le pôle médical de l'établissement CCC (de la même société que l'établissement BBB) se fournit également chez MERCURO, non ?
Est-ce qu'un même fournisseur peut fournir plusieurs pôles ? (a priori non sauf à envisager que MERCURO fournisse aussi des crayons pour le pôle bureautique).


On va attendre que Jimbolion revienne de sa ballade VTT pour la suite...

[CaiiLle]

Bonjour à vous deux ,

Jimbalion, je ne sais pas si des "cadeaux" sont envisageables, cependant pour lancer le début des hostilités, je vais devoir enregistrer les stocks réels actuels (peut-être que ce détail se rapproche de ton interrogation).



F-leb, toute aide est bonne à prendre !!

• La BDD ne servira que pour une seule société et ses 4 établissements (ajouts possible après de futurs agrandissements)

• Dans un souci de simplicité, chaque établissement a exactement les 4 pôles !

• Un ou plusieurs fournisseurs par pôle, quelque soit l'établissement passant commande

• Quelque soit l'établissement, il se fournit chez le même fournisseur
  A priori, le fournisseur MERCURO ne fournit que pour le pôle mécidal, bien que je n'en ai pas la certitude. Partons du principe que si !!!
  
  Je demanderai confirmation pour ce paramètre, lundi !!

Merci pour tes questions qui éclaircissent encore davantage le projet

Cordialement,

[jimbolion]

F-leb,

Ravi que tu participes au débat.

Donc pour répondre à tes questions

J'ai un doute sur le périmètre comme je ne vois pas de table Société, si l'application concerne une société ou plusieurs sociétés (avec chacune leurs établissements) ?

J'ai suivi les indications de CaiiLle, on peut même imaginer au dessus des sociétés des centrales. En l’occurrence, rien n'empêcheras un jour de créer une table société et faire redescendre l'ID de la société dans l'établissement (tomorrow is another day comme disait mon ancien prof d'infos).

Chaque établissement a donc exactement les 4 pôles si j'ai bien compris, non ? Il y a-t-il une possibilité qu'un établissement ne possède pas de pôle "logistique" par exemple ?

Sur ce point, tout est question de modèle, rien n’empêche dans le modèle de créer un établissement avec seulement 2 pôles (si une contrainte doit être fixé, elle ne pourra l'être que par code)

Il faudrait donc associer fournisseurs&pôles, voire avec les sociétés s'il y en a plusieurs (cf. ma 1ère question). À voir...

J'ai évoqué cette problématique avec CaiiLle à ce sujet, elle a fait une réponse claire et précise en ce point. Toutefois, je te rejoins sur cette idée et c'est pour cela que le produit associé au fournisseur dans la table produit n'est pas celui descendu dans la table tarif : cette subtilité permet donc à un pôle de changer de fournisseur pour un produit donné. Idéalement, j'aurai crée une ternaire de ce type :

T_Produit_Fournisseur (Id_Produit_Fournisseur, Id_Produit_FK, ID_Fournisseur_FK)

Cette table pourra toujours être inséré ultérieurement

Pour ta dernière question, elle relève du point 1 (la confirmation du message de CaiiLle me laisse penser que pour l'instant il est urgent de ne rien faire).

CaiiLle je continuerai ce soir sur ton modèle

Bonne soirée

JimBoLion

[f-leb]

Bonsoir Jimbolion et CaiiLle,

J'ai un doute sur le périmètre comme je ne vois pas de table Société, si l'application concerne une société ou plusieurs sociétés (avec chacune leurs établissements) ?

J'ai suivi les indications de CaiiLle, on peut même imaginer au dessus des sociétés des centrales. En l’occurrence, rien n'empêcheras un jour de créer une table société et faire redescendre l'ID de la société dans l'établissement (tomorrow is another day comme disait mon ancien prof d'infos).

Si un fournisseur F1 est attaché au pôle P1 pour tous les établissements d'une même société S1, je me demandais si F1 fournissait également le même pôle P1 des établissements d'une société S2.
Pas forcément et dans ce cas il faudrait associer les fournisseurs aux pôles et aussi aux sociétés.
Si le périmètre de l'appli ne concerne qu'une seule société, la question ne se pose plus...

Chaque établissement a donc exactement les 4 pôles si j'ai bien compris, non ? Il y a-t-il une possibilité qu'un établissement ne possède pas de pôle "logistique" par exemple ?

Sur ce point, tout est question de modèle, rien n’empêche dans le modèle de créer un établissement avec seulement 2 pôles (si une contrainte doit être fixé, elle ne pourra l'être que par code)

Si chaque établissement a exactement les 4 pôles possibles, je ne vois pas l'utilité de la table de jonction Tbl_pole_Etablissement, c'est pour cela que je posais la question.

Après, wait and see et attention aux évolutions...

Bonne fin de soirée.

[jimbolion]

f-leb et CaiiLle bonsoir,

Ta remarque concernant la jontion Tbl_pole_Etablissement est tout à fait judicieuse. CaiiLle a parlé à terme de plusieurs établissements futurs, je n'ai pas encore acquis la certitude que chacun de ces nouveaux établissements dispose bien des 4 pôles.

CaiiLle je te fourni le MLD tel que je le pense et après validation de F-LEB.
Je t'envoie également la copie de la base et ses structures.

Bonne soirée

JimBoLion

[CaiiLle]

Jimbolion,

A première vue le MLD fait peur, pleines de tables et une multitude de relations. Je comprends que j'avais un mal fou à paramétrer la BDD.

Pour les établissements nouveaux, je ne sais pas si les 4 pôles en seront rattachés. La table Tbl_pole_etablissement est judicieux. Ainsi, si l'établissement DDD est créé, nous pourrions paramétrer les pôles Administration et médical sans les 2 autres.

Merci beaucoup pour votre aide Jimbalion,

A partir de ton travail, je peux maintenant préparer les requêtes et formulaires ?

Bonne nuit,

[jimbolion]

CaiiLle,

Il ne faut surtout pas s'inquiéter d'un MLD, la plupart des tables sont ce que l'on appelle des List Of Values et permettent de typer un champ dans ta table

Tbl_TypeMouvement ; E ou S
Nature_Mouvement : Casse, vente,vol,standard
...

Un fournisseur a été rattaché à un pôle comme suggéré dans tes messages. Si le même fournisseur est rattaché à tous les pôles pour une commande bureautique, cette contrainte pourrait être supprimée.

Pour des questions supplémentaires, n'hésites pas à reprendre contact avec moi.

La redondance d'informations (il n'y en a pas dans le modèle que je te propose) n'est pas nécessairement une erreur non plus. Lorsque tu en seras à la partir impression ou statistiques, il peut être intéressant de redescendre une clé dans une table (cela élimine les relations en cascade et donc le temps de traitement).

Pour la partie IHM, je te conseillerai de voir avec la partie technique l'architecture existante et procéder à une analyse globale de ton projet. En dessinant des écrans et en définissant les règles, on se rend compte bien souvent (F-Leb le rappelait dans son post) que certaines choses risquent d'évoluer (des adaptations mineures sont sans conséquences mais un oubli majeure remettra en cause tout ton développement).

Pour la partie Développement, je suis de l'avis de Nico84 (Access est t'il le meilleur produit de developpement pour du multi sites : un client léger semble mieux adapter dans ton cas)

En tout cas, reviens vers nous si nécessaire et bon courage

JimBoLion

[CaiiLle]

Jimbolion bonjour,

Merci pour toutes ces informations !!

1. Comme j'ai pu te dire précédemment, je n'ai aucunes connaissances sur d'autre produit de développement (c'est surement pour cette raison que l'on a fait appel à moi pour Access). Qu'est ce qu'un client léger ? Comment le mettre en place ?

2. Pour le MLD, il y a certaine table que je ne connais pas le fonctionnement :
- La table mouvement fait office de table "gestion des stocks" ?
Le champ id_MouvementAchat_FK n'est rattaché à aucune autre table, est-ce normal ?

- Comment fonctionnent les tables User ? En d'autres terme, comment paramétrer le login de chaque utilisateur ? Il te faut probablement la nature de diffusion de la BDD, si c'est du multi-site ou pas et donc retour à la remarque 1 ?

3. Je peux ajouter à ma guise des champs dans les tables produit, fournisseur, établissement, etc... ? (adresse, CP, ville, tél, fax, etc... )

Je vous tiens informé dans la journée, je vais dans un premier temps leur proposer ce que tu m'as "modéliser" puis je passerai aux autres questions (IHM et moyen de diffusion (multi-site).

Bonne journée,

[jimbolion]

CaiiLle bonjour,

Alors pour répondre à la question 1 : Client léger (=mode hébergé) : pas d'appli sur le poste client (cf php ou asp). L'accès se fait par un navigateur sur des serveurs chez ce que l'on appelle des hébergeurs (ex. OVH)

La table mouvement concerne la gestion de stock (tu m'as demandé de l'implémenter dans le modèle)

Le champ id_MouvementAchat_FK correspond à l'ID achat (clé de redondance cyclique). Cette clé permet d'identifier l'Id Mouvement achat pour le vente (ne peut exister en l’occurrence que pour un mouvement de type Vente).

Pour le paramétrage des logins Utilisateurs, chaque Login et Mot de passe sera attribué par l'administrateur système (toi en l’occurrence). Tu pourras laissé le choix à chaque user de modifier son PassWord (sauf si tu souhaites gérer un Mot de Passe unique afin de référence l'établissement). La discussion dans un des messages précédents.

Pour la partie table, il est bien évident que tu peux et même doit rajouter des champs (quelques règles à établir avant : fournisseur : adresse facturation, livraison par exmeple...)

JimBoLion

[nico84]

Bonjour à tous,

Access est un super produit pour développer de petites applications locales car il inclut à la fois une base de données et un logiciel de description d'écrans. Par contre il est très limité :
- par la taille des données (2 Go quand même)
- par le nombre d'utilisateurs (de l'ordre de la dizaine)
- et surtout par le réseau car c'est le PC de l'utilisateur qui réalise tous les traitements. Pour cela le serveur lui envoie un gros volume de données (plus ou moins bien bloquées pendant ce temps pour les autres) ce qui nécessite un réseau haut débit (donc local).

D'où le "client lourd" (client=utilisateur).

Au contraire avec une base SQL ou Oracle et une programmation adaptée il est possible que le serveur fasse 90% du travail et n'envoie au client que des écrans de saisie et/ou de résultat. C'est ce qu'on voit sur le web mais aussi avec les progiciels conçus pour les grandes entreprises. On parle alors de "client léger" car le logiciel est conçu pour fonctionner avec plusieurs dizaines voire milliers d'utilisateurs sans surcharger les réseaux.

Il serait dommage de se lancer dans ce projet avec access pour découvrir quand il sera fini que ça marche super bien sauf quand on s'en sert...

J'ajoute que sur un parc de PC important et hétérogène, access est aussi très lourd à maintenir car les versions d'office, windows et access (tous produits microsoft !) posent en permanence des problèmes de compatibilité. Si les différents sites sont très éloignés cela peut vite tourner au cauchemar à chaque achat d'un nouveau PC

Le fait de ne connaitre qu'access (et encore pas très bien) n'est pas un très bon argument

[jimbolion]

Nico84,

Merci encore pour ces précisions, je ne veux pas être le seul à tirer sur la sonnette d'alarme.
Ton avis est éminemment précieux et conforte ma position.

Cela en tout cas ne remet pas en cause le modèle CaiiLle.

JimboLion

[CaiiLle]

Bonjour à tous,

Je reviens vers vous pour vous faire un point concernant les quelques questions en suspens.

1. Type de diffusion
La société est paramétrée sur un réseau type petite entreprise. Le responsable du parc informatique m’a indiqué posséder un TSE (terminal réseau).

Il faut compter une vingtaine d’utilisateurs et autant de PC.


2. Fournisseur
Je vous confirme qu’un fournisseur est rattaché qu’à un pôle.

• Un fournisseur n’a qu’un pôle,
• Un pôle a un ou plusieurs fournisseurs.

3. Volumétrie des données
Nous sommes en présence d’une trentaine de fournisseurs maximum. Il faut compter au maximum 100 produits par fournisseurs.

Au grand maximum, la table « produit » gérera 3000 références.

Concernant la volumétrie « commande », il y a une commande par mois, par fournisseur et par établissement.


4. Gestion de stock
Jimbolion, le modèle que tu m’as créé permet-elle de connaitre le nombre de produit par établissement (gestion de stocks par établissement) ?

Chaque établissement gère en toute autonomie ses stocks produits.

(Cf : remarque n°5 – Gestion commandes)


5. Gestion de commandes

Je vous apporte mon nouveau lot de couac !!! Quelle poisse…

Dans un souci d’économie, la société a mis en place une gestion des commandes « regroupée ».

Je m’explique (voir le fichier joint gestion des validations devis commandes.docx)

• Pour les pôles Médical et Technique, une responsable assure la validation des commandes.

L’établissement AAA commande 10 pansements chez MERCURO. (Idéalement DEVIS n°…)
L’établissement BBB commande 20 pansements chez MERCURO. (Idéalement DEVIS n°…)

La responsable valide les DEVIS de chacun des établissements ce qui en découle une unique commande de 30 pansements (gain sur les frais de ports).

Lorsqu’une commande « regroupée » est créée la responsable du pôle médical souhaite « avoir la possibilité de » choisir son lieu de livraison unique. Elle se chargera de dispatcher les produits dans les bons établissements.

• Pour les pôles Logistique et Administratif, la personne en charge de créer ses devis, les validera et génèrera la commande.

Dans ce cas, la création de la table T_Devis, nous permettra de répondre à la problématique de la Remarque n°4 – Gestion de stock ?


Merci pour vos remarques et aides.

Je me sens tellement "petit"

Cordialement,

[jimbolion]

CaiiLle,

Reponse 1

Le TSE (Terminal passif) permet d’échanger avec un serveur situé dans l’Entreprise (Type Windows 2003 ou 2008 Server). L’avantage de ce système, c’est qu’il est relativement facile à installer et à maintenir, les échanges concernent uniquement les transactions claviers et déport d’affichage. Il y aurait plusieurs façons d’envisager la problématique soit en partageant la frontale ou en installant une frontale par session ouverte (pas de risque de collision mais une maintenance plus complexe). J’ai pas utilisé TS avec autant d’utilisateurs connectés, et malheureusement je ne pourrais te garantir la stabilité sur ce type d’architecture (attention je ne dis pas que cela est impossible). En outre, et ce sur les versions d’Access 2000, l’inconvénient de ce système résidait dans l’utilisation de la méthode requery qui désactivait systématiquement le clavier numérique.
Pour le nombre de sessions, je suppose que tous les utilisateurs ne seraient pas connectés en même temps, il faudrait penser à gérer les sécurités en contrôlant le nombre d’utilisateurs connectés (il existe différentes techniques). Donc sur cette partie, qu’en penses donc le service technique ? Des membres sur ce forum ont peut être vécus cette expérience, ouvrir un nouveau message serait à envisager..

Reponse 2

Pour les commandes d’un même type (exemple bureautique), le fournisseur est-il le même pour tous les pôles. (La question est un peu différente). En d’autres termes, peut-il y avoir deux fournisseurs bureautiques (xx et yy) pour deux pôles différents. La question revient et j’insiste car dans ce cas la clé étrangère de la table fournisseur peut disparaître.

Reponse 3

En ce qui concerne la volumétrie, ce ne sont pas trop les données catalogues qui sont importantes (mais c’est bien de les identifier). Je souhaite plutôt connaitre le nombre moyens d’articles dans une commande ainsi que le nombre de sorties. Cela permettra de déterminer le nombre de mouvements par mois et implémenter dans le modèle une fonction archivage. (dans une deuxième dorsale par exemple).

Reponse 4

Oui le modèle permet de connaitre le nombre de produits commandés par établissement. Si tu regardes la table commandes tu y trouves l’Id User rattaché à l’établissement. Maintenant rien ne t’empêches de redescendre l’ID établissement (Cela fait partie des redondances acceptables).

Reponse 5

Pour le regroupement des commandes, pas de soucis, il faut mettre en place une ternaire permettant de définir une liste de commandes associées à un user (user du pôle et la liste des Id Commandes). Cette problématique existe dans de nombreuses gestions multi-sites (table de jonction). Cette table devra alors comporter le user du pôle que l’on pourra supprimer de ta table commandes et qui servira éventuellement de flag de validation à la commande.

JimBoLion

[CaiiLle]

Jimbolion,

1. Type de diffusion

Le responsable du parc informatique m'informe qui mettra en place sur le TSE, l'application Access et la base de données.

Il n'y aura qu'un utilisateur connecté à la fois.


2. Fournisseur

Après validation, il y a un même fournisseur pour tous les pôles Adm.

Le pôle fait office de clé de répartition (comptabilité).

Le pôle administratif sert de cloissonnement à tous les achats type bureautique.
Le pôle mécidal sert de cloissonnement à tous les achats type médical.

Et chaque fournisseur est spécialisé dans le pôle où il est rattaché.


3. Volumétrie des données

• 1 commande par établissement, par fournisseur et par mois (pour une moyenne de 30 produits).
• 1 sortie par semaine, par établissement, par produit

4. Gestion de stock
Nous allons partir sur l'idée de redescendre l’ID établissement.

Merci beaucoup !!


5. Gestion de commandes

Ainsi, en insérant une nouvelle table T_Devis ainsi que la ternaire (id user pole, id devis) la validation par le responsable du pôle generera une unique et finale commande pour un fournisseur donné ?


Merci,

Cordialement,

[jimbolion]

CaiiLle,

En voilà des bonnes nouvelles.

Donc pour la modif du modèle (id_fournisseur dans pôle, id_etablissement) ainsi que la ternaire, je te laisse faire si tu veux et te donnerai mon avis.

Pour le contrôle utilisateur, nous mettrons en place un contrôle spécifique afin de vérifier le nombre de personnes connectées.

Avant d'aller trop loin dans le Dev (après 1 ihm), la génération d'un Setup et la mise en place sur ts s'avèrera nécessaire (contrôle performance + clavier numérique + impressions). Juste afin de valider la viabilité du projet.

JimBoLion

[CaiiLle]

Jimbolion,

Les tables sont modifiées et créées. Cependant, je ne sais pas quoi faire des tables Tbl_Devis et Tbl_UserPole_Devis (au centre du MLD).

Une pôle peut avoir plusieurs fournisseurs ! Mais un fournisseur qu'un seul pôle. Donc la création de la clé étrangère ID_Fournisseur_FK dans la table Pôle ne pose-t-il pas problème ?
Il est plus judicieux de laisser ID_Pole_FK dans la table fournisseur ?


Pour la partie login et mots de passes, tu m'as perdu en route !! Je crois que j'ai peut être sous-estimé mes capacités..


Pour l'IHM, si j'ai compris, tu souhaites un schéma du type de présentation que je souhaite donner au projet ? En d'autre terme le style de navigation ?

J'ai déjà mon idée la-dessus. Je le schématise sur feuille et je vous la scanne.


Qu'est ce que le Setup ?
Cette partie, ce sera le responsable du parc informatique qui va s'en charger. Il n'est pas à ma disposition demain mardi.


Je comptais avancer en attendant. Je dois dans la mesure du possible, présentation l'outil vendredi. Étant embauché en CDD pour l'occasion...

[jimbolion]

CaiiLle bonsoir,

La table Tbl_Devis correspond à la table Tbl_Commandes je suppose.

Faut t'il renommer ta table TBL_Commandes dans ce cas ?

Ne sous estimes pas tes capacités. Combien de temps dure ton CDD afin d'évaluer la durée et la viabilité de ton projet ?

Pour la partie Setup, on te guidera (il y a suffisamment de compétences sur ce forum).

Après dessine tes écrans, cela aura trois avantages : montrer à tes responsables comment va s'organiser ton projet, rectifier avec eux les erreurs eventuelles et permettre de mieux comprendre aux membres les enchainements.

Je t'accompagnerai volontiers sur la réussite de cette application (en dehors de mon temps professionnel).

JimBoLion

[jimbolion]

Formalises tout çà dans un document type Word (existant, ecrans et règles).

Merci d'avance

JimBoLion

[CaiiLle]

Jimbolion,

Table Devis
La table Devis correspond à la saisie effectué par l'employé.
Le responsable valide.
Il en découle une commande

Donc, après avoir échanger avec le responsable du parc informatique.

Il y aura une Table Devis, Validation, Table Commande

Tout en sachant que la Table Commande peux regrouper 1 ou plusieurs Devis.

Caiille

[jimbolion]

CaiiLle bonsoir,

Il nous faut donc intercaler une table devis (pas de soucis) avant la commande. Il y a deux possibilités :

1. Le devis est accepté (ou rejeté) dans son intégralité
2. La devis est accepté en partie

De ces deux réponses, le modèle sera différent. En cas d'acceptation partielle il est nécessaire d'avoir deux tables, un refus ou acceptation ne remet pas en cause l'idée du modèle.

Dans l'attente de ta réponse

JimBoLion