[AC-2007] Sous-Formulaire lié à une liste déroulante du formulaire principal

[Same03]

Bonjour,

J'ai créé un Formulaire "FormulaireEnregistrementHeure" qui a pour objectif d'enregistrer les heures effectué par projet.

Par conséquent :

- Dans le formulaire principal, j'ai positionnais une liste déroulante "lstNum_Affaire" qui permet de choisir l'affaire où nous allons enregistrer des temps.

- Dans le sous-formulaire, il y a les noms des opérateurs qui travaillent sur le projet, la dénomination de l'opération que l'opérateur effectue, la semaine concerné, le jour et le temps par jour.

J'ai essayé de faire en sorte que lorsque je choisi un Num_Affaire dans le formulaire principal, les noms des opérateurs, les opérations qu'ils ont réalisé, la semaine, le jour et les heures déjà faite s'affiche automatiquement mais ne concernant que l'affaire que j'ai choisi dans la liste déroulante du formulaire principal !

Malgrès avoir regarder tous les cas similaires qu'il y a sur le forum et les FAQ, je n'ai pas réussi à le faire fonctionner, je dois avoir mal fait quelque chose dès le début ou il me manque certainement des bases.

Je mets à votre disposition la base que j'ai réalisé pour que vous puissiez visualiser les choses. Elle est en version 2003-2007.

[Triton972]

Bonjour,
J'ai téléchargé ton projet et j'ai quelques questions, au préalable, sur tes données :

1 affaire = 1 client.
1 affaire peut avoir plusieurs projets
cela me parait logique sauf que la donnée "Id_Client" dans "Table_Projet" est redondante (donc dangereux et source de tracas à terme)

Mais au vu de tes tables et de ton schéma relationnel :

1 lot peut être rattaché à plusieurs projets
et
1 opération peut être rattachée à plusieurs projets

me paraissent douteux.

Confirmes-tu bien cette logique ?
Cordialement,

[Same03]

En effet,
1 affaire = 1 client
Mais 1 client peut aussi avoir plusieurs affaires et aussi plusieurs projet
C'est pour ça que j'avais mis Id_Client dans la table Projet et c'est aussi pour essayer d'avoir le client correspondant au projet quand je choisi dans la liste déroulante Num_Affaire du formilaire FormulaireEnregistrementHeure
Mais si tu dis que c'est inutile et qu'on peut faire sans, je te suis.

Et oui, le Nom d'un lot peut être rattaché à plusieurs affaires et plusieurs projet car ça serait trop lourd de créer un nom pour chaque lot de chaque affaire et projet. Mais si ceci peut poser problème, je pense que ça ne coûte rien d'essayer de créer un code pr les lots ! La table pourra le supporter mais c'est tout le système autour qu'il va falloir revoir (les autres outils)

Les opérations peuvent également être rattachées à plusieurs projet car les projets se ressemblent beaucoup et il est rare que de nouvelles opérations soient utilisées.

Merci de te pencher sur mon problème !

J'ai avancé depuis que j'ai posé cette discution ! je vais mettre en pièce jointe la base en l'état actuelle des choses

[Same03]

voici la base actualisée :

Cordialement,

[Triton972]

Bonjour,

Bon j'ai l'impression que tu confonds le modèle "physique" et le modèle "conceptuel" de tes données (langage Merise).
Je m'explique :
Avant de savoir comment tu vas bâtir ta base de données (modèle physique) il faut savoir ce que tu veux manipuler et leurs logiques sous-jacentes (modèle conceptuel). De l'un (conceptuel) découlera l'autre (physique). Ils sont proches mais différents !
Créer une table et des liens pour éviter de recopier plusieurs fois le même texte c'est une chose mais ce n'est peut être pas la première à prendre en compte.

Exemple : Lot

conceptuel : Un lot, en temps que tel, représente une ensemble d'activité spécifique qui vont faire partie d'un ensemble (un objet) cohérent. Il aura un comportement spécifique (Identifié par son identifiant : IdLot) et devra être rattaché à l'objet "Père" ( a priori le Projet ...?). Un lot (même si sa désignation est identique) ne peut rattaché qu'à un seul père. (comme 2 personnes qui portent le même prénom ne sont pas "systématiquement" (et loin s'en faut!) fils du même père).
La clé "étrangère" (IdProjet) doit donc être dans l'objet (table) Lot.

Physique : Le problème : "d'éviter de recopier un libellé" doit être traité différemment. Par exemple en faisant appel à une autre table dont l'identifiant serait présent dans la Table Lot .... bla bla bla
Il y a beaucoup à dire sur le sujet.

Mais un système de données bien pensé et bien conçu est indispensable et incontournable et ce travail doit être fait AVANT de s'occuper de "Technique".

Il y a beaucoup de liens intéressants sur le net (et livres aussi) sur le sujet.

Je reste à ton écoute. Bonne découverte

[Same03]

J'ai appliqué tes conseils sur pour l'identifiant projet dans la table lot !
A force d'être sur le projet, je me mélange un peu les pinceaux.
Mais tout ce que tu as dit sur le modèle MERISE (Conceptuel) et le modèle je connais. J'ai d'ailleurs bien effectué le MCD et le MLD.

J'ai effectué tes conseils pour l'identifiant projet dans la table lot.

- J'aimerai pouvoir rafraichir (ou filtrer) le sous-formulaire avec la liste déroulante du formulaire principal lstNum_Affaire.

- J'aimerai aussi que quand on choisi un numéro d'affaire dans la liste déroulante lstNum_Affaire le client et la date limite qui lui correspondent s'affiche automatiquement.

Je joint la base dans l'état actuel où elle est :

Cordialement.

[Triton972]

Bonjour,

En examinant plus attentivement tes tables je n'ai pas bien compris ta Table Table_Num_Affaire. Il y a plusieurs fois la même valeur pour Num_Affaire et on trouve aussi dans Num_Affaire : Aucun et Tous !!??

Je suis passé à côté au début de nos échanges

Que veux tu faire de cette table ?

Ta logique ne serait pas plutôt :

• 1 Projet est rattaché à un Client et un seul. Un Projet est identifié par un N° d'Affaire (?)
• 1 Lot est rattaché à un Projet et un seul. Un projet peut avoir plusieurs Lots.
• 1 Opération est rattachée à un Lot et un seul. Un Lot peut avoir plusieurs Opérations.

on verra les autres données après ...

Si telle est ta logique :

Si tu as 3 objets ainsi liés tu devrais avoir 3 formulaires. Les requêtes source des formulaires devant être "fabriquées" à partir des informations du formulaire "père" (par SQL dans VBA) ou être liés directement (ce qui est plus simple et préférable quand on le peut ...).

• Requête du Formulaire "Projet" basée sur la table Table_Projet (qui faudra consolider en fct du point précédent)
• Requête du Formulaire "Lot" basée sur la table Table_Lot (dans celle-ci on a bien la clé Id_Projet donc c'est OK)
• Requête du Formulaire "Opération" basée sur la table Table_Opération (il manquerait la clé Id_Lot)

L'idée est d'abord de pouvoir "gérer" l'ensemble de ton arborescence "Projet-(Affaire)-Lot-Opération". C'est à dire de pouvoir ce déplacer dans l'ensemble des branches, les créer les supprimer ... et ensuite compléter avec les autres données (Opérateur, Semaine, Jour, Heure)

Qu'en penses-tu ?

Formulaire1 : Mise à jour, consultation Affaire + client. La requête doit être basée que sur Table_Num_Affaire

[Same03]

Bonjour,

Aucun et Tous, sont là pour le future formulaire de recherche afin de pouvoir rechercher le nombre d'affaire réalisé par un même opérateur ou le nombre de fois qu'une opération a était effectué par affaire.

Dans la Table_Num_Affaire il n'y a pas plusieurs fois le même Num_Affaire.

Mais dans la Table_Projet, il y a plusieurs fois le même Num_Affaire, car :
- Un projet est décomposé en plusieurs Affaires
- Et la Table_Projet est là pour recceuillir tous les détails d'un procjet, les opérations,les opérateurs, la date limite, les temps (Heure/J), lot, semaine, client, jour, par conséquent il faut une ligne par opérateur.

Ensuite pour la logique :

- 1 projet est bien rattaché à un seul client mais un client peut être rattaché à plusieurs projets (liaison ou relation 1;n)
- Un projet est composé de plusieurs affaires et une affaire est rattaché à un seul projet (n;1)
- Ici, le nom des lots est le même pour tous les Projets, et même pour toutes les affaires. Donc 1 lot peut correspondre à plusieurs projets et plusieurs affaires et un projet peut avoir plusieurs fois le lot 1 mais une affaire non. Donc pour la relation lot affaire ça donne (n;1) et pour la relation lot/projet ça donne (n/n). Mais de manière plus concrète, tactile et logique, en effet, un lot ne peut être rattaché qu'a une affaire et même qu'a un projet. Donc pour la relation lot/affaire ça donnerai (1;1) et pour la relation lot/projet ça donnerait aussi (1;1). Mais comment faire pour garder une dénomination libre (c'est-à-dire recommencer par le Lot1 pour chaque nouvelle affaire démarée) de manière à ne pas rendre plus lourd la bureaucratie.
- 1 opération peut être effectuée sur plusieurs lots en même temps et même plusieurs lots les un à la suite des autres et un lot est réalisé en utilisant plusieurs opérations différentes (liaison n;n)

Ta solution de 3 formulaires je l'ai en quelque sorte déjà mis en place, puisqu'il y a un formulaire déstiner à enregistrer les nouveaus projets composé du Num_Affaire, du Client, de la Date limite. Par conséquent je peux créer et supprimer un projet.

Ensuite, j'ai créer un formualaire pour enregister et supprimer une nouvelle opération, un autre pour enregistrer et supprimer une dénomination opérateur, un autre pour créer un nouveau lot (du genre Lot 9), un autre pour créer un une nouvelle semaine (du genre Semaine 11).

J'ai lu ta proposition de faire un formulaire reliant, Num_Projet, Num_Affaire, Client, lot, date limite et opération. Mais comment faire, puisqu'un projet peut avoir plusieurs Num_Affaire et plusieurs opérations ? ça se ferais donc aussi avec un sous-formulaire. Le formulaire principal permettrait de choisir les enregistrements que l'on veut faire et le sous-formulaire permettrait de voir les enregistrements effectués ?

Mais ensuite comment lié l'opérateur à l'opération concerné qui est elle même relié au num affaire et au num projet ? pareille pour les heures par opération, les jours, les semaines et les temps. Sachant que par la suite je dois faire une somme de toutes les heures effectuées par semaine sur une opération, pour un opérateur sur un projet pour le comparer aux heures prévues et ensuite faire un totale de toutes les heures effectuées par semaine pour avoir un apperçu des heures consommées.

Il me faut donc un formulaire me permettant de voir, le Num_Affaire, le Nom_Client, la date limite, Le lot, les opérateurs qui ont travaillé sur l'affaire, le temps qu'ils ont effectué sur une opération par jour et le temps qu'ils ont travaillé par semaine et ensuite le temps total depuis le début du projet. C'est le deuxième formulaire que je voulais faire qui en même temps permettait de faire des recherches, c'est-à-dire n'obtenir que :

- les temps par opérateur pour un Numéro d'affaire choisi
- les temps en fonction d'un type d'opération pour un Numéro d'affaire choisi
- les temps par semaine pour un Numéro d'affaire choisi
- les temps par jour pour un Numéro d'affaire choisi
- les opérateurs ayant pu travailler sur un Numéro-D'affaire
- les opérations qui composent un Numéro_Affaire
- Toutes les opérations qui ont étaient créées (d'où la présence de Aucun dans la liste Num_Affaire)
- Toutes les affaires demandées par un Client
- Toutes les opérations qui ont été réalisé par le même opérateur

En bref, il faut pouvoir effectué ttes les recherches possibles avec le Numéro d'affaire (ou sans ou tous), le Nom Client ou tous les client, le Nom d'un opérateur ou tous les opérateurs, les semaines, les jours, les lots, les opérations et les jours.

[Triton972]

Bonjour,
Bon ca commence à se décanter
Pour commencer :
Aucun problème particulier pour faire toutes les analyses que tu veux faire. C'est la force de la Base de Données !
On verra tout çà dans un 2° temps, il y a des techniques qui marchent bien.
Pour compléter la connaissance de ta logique, j'ai besoin de quelques compléments d'information :

1 - Concernant les opérations : Je crois comprendre que ce sont des "opérations-types" : Tu peux en faire une liste, a priori, c'est ce que tu as fait dans la table ?

2- les lots suivent-ils la même logique ou non ? je m'explique. Est-ce que tous les "Lot 1 " sont composés des mêmes opérations ou non ? si oui, cela voudrait que l 'on pourrait constituer, a priori, tous les "type de lot" avec leur composition Oui/non ?

3-Je crois comprendre que les "Opérateurs" sont affectés aux "Opérations". 1 Opérateur peut travailler sur plusieurs opérations différentes (j'espère !!) par contre, est-ce que 2 (ou plusieurs ) opérateurs peuvent travailler sur la même opération ? Quand je dis "même opération" il faut comprendre "l'opération x du lot y de l'affaire z du projet z"; Pour simplifier est-ce le "cablage de la platine xyz" peut être commencé par l'opérateur 1 et finis par l'opérateur 2 Oui/non ?

4- Comment comptes-tu enregistrer les temps passés par opération et par opérateur ?

Date début, heure début ---- Date fin, heure fin
éventuellement plusieurs jours (si l'opération dure plusieurs jours) et la "machine" calcule la durée
ou
Date jj/mm/aa durée opération

5- Je "sens" bien ton MCD comme çà :

Client (1,n) --- Projet (1,1)
Projet (1,n) --- Affaire (1,1)
Affaire (1,n) --- Lot (1,1)
Lot (1,n) --- Opération (1,1)
Opération (1,1) --- Opération-Type (1,n) (sous réserve des tes explications)
Opération (1,n) --- Opérateur (1,n)

Dans la relation entre Opération(1,n) et Opérateur (1,n) on trouvera les dates et durées.

6- pour la fabrication "automatique" du nom des lots (voir aussi question 2), on pourra le traiter facilement (valeur par défaut dans la table ou un peu de code ...)

Avec ce MCD plus les informations complémentaires qu'il faut rajouter dans certains objets (exemple : date limite, durée prévue, etc ...) on doit pouvoir constituer les formulaires qui t'intéressent !
@+

[Same03]

Bonjour,

1- oui se sont des opérations types et oui j'en ai fait une liste dans la base mais ce n'est qu'un échantillon et en plus elle est vouée à évoluer régulièrement

2- Oui les lots d'une même affaire utilise les même opérations types. Mais je ne vois pas l'intérêt de constituer les lots avec un Oui/Non. Je veux juste savoir quel lot est concerné.

3- Oui les "Opérateurs" sont affectés aux "Opérations". Et en effet, 1 opérateur peut travailler sur plusieurs Opérations différentes et Plusieurs Opérateurs peuvent faire la même Opération. Car il arrive que la réalisation de l'objet final soit faite quasiment de A à Z par le même opérateur mais il arrive également que les Opérations soient réparties entre plusieurs Opérateurs. Exemple : Fauteuil1 décomposé en fabrication structure métallique, installation mousse, installation tissu. Opérateur1 effectue la structure mettalique, Operateur2 installe la mousse, Opérateur1 installe le tissu et cela sur tous les fauteuils du lot1, puis sur le lot2, Opérateur1 effectue la fabrication de la structure, installe la mousse et installe le tissu sur 5 fauteuil, Opérateur2 effectue la fabrication de la structure, installe la mousse et installe le tissu sur les 5 autres fauteuils. Et oui, si l'Opérateur est absent le lendemain et qu'il a commencer à installer la mousse la veille, l'Opérateur2 peut le finir à sa place le lendemain.

4- Pour enregister les temps passer par opération et par opérateur ça donne ça :

Opérateur1 OpérationA Semaine1 Lundi 5 Mai 8h00
Opérateur2 OpérationB Semaine1 Lundi 5 Mai 1h20
Opérateur2 OpérationC Semaine1 Lundi 5 Mai 6h40
Opérateur1 OpérationA Semaine1 Mardi 6 Mai 1h50
Opérateur2 OpérationC Semaine1 Mardi 6 Mai 1h30
Opérateur1 OpérationC Semaine1 Mardi 6 Mai 1h30

(je vais changer la table heure parce que actuellement elle est en numérique et je ne peut pas mettre le h mais les enregistrer en heure avec le "h" risque peut être de compliquer les choses lorsque je vais vouloir les additionner pour connaîte le temps total par semaine par exemple, donc je passerais certainement en 1,20 pour 1h20)

Et ensuite dans mon formulaire analyse je pensais optenir par des listes déroulantes rechercher et des boutons Et/OU en choisissant dans la liste déroulante Opérateur : Opérateur 1 :

Opérateur1 OpérationA Semaine1 Lundi 5 Mai 2011 8h00
Opérateur1 OpérationA Semaine1 Mardi 6 Mai 2011 1h30
Opérateur1 OpérationC Semaine1 Mardi 6 Mai 2011 1h30
Total : 11h00

Ou en choisissant dans la liste déroulante opérateur : Opérateur2 et dans la lsite déroulante Opération : OpérationC

Opérateur2 OpérationC Semaine1 Lundi 5 Mai 2011 6h40
Opérateur2 OpérationC Semaine1 Mardi 6 Mai 2011 1h30
Total :8h10

Ou en choisissant seulement dans la liste déroulante Opération : OpérationC

Opérateur1 OpérationC Semaine1 Mardi 6 Mai 2011 1h30
Opérateur2 OpérationC Semaine1 Lundi 5 Mai 2011 6h40
Opérateur2 OpérationC Semaine1 Mardi 6 Mai 2011 1h30
Total : 9h40 Durée Prévue : 10h00 Gain(-)/Perte(+) : 0h20

Du coup en te donnant cet exemple je me rend compte également que ma table_Jour ne sert à rien. Il faudrait plutôt que j'intégre dans la table_Projet, une ligne Date ou Jour en choisissant comme type de donnée Date/Heure. Mais ce type de donnée n'a pas l'aire de donner le nom du jour, il donne juste le numéro. Je pense qu'il y a une moindre importance que le nom du jour n'y soit pas.

Il faudrait qu'a chaque recherche effectuer, l'utilisateur du formulaire analyse puisse obtenir une feuille résumant ses données qu'il n'aurait plus qu'a imprimer, du genre avec une recherche par Opérateur obtenir en cliquant sur un bouton :

Logo de la société

Numéro Affaire : XXXX Client : XXXX Date Limite : XXX

Analyse de l'Opérateur1 :

Opérateur1 OpérationA Semaine1 Lundi 5 Mai 2011 8h00
Opérateur1 OpérationA Semaine1 Mardi 6 Mai 2011 1h30
Opérateur1 OpérationC Semaine1 Mardi 6 Mai 2011 1h30
Total : 11h00 Durée Prévue : /

5- Le MCD donne :

Client (1,n) --- Projet (1,1)
Projet (1,n) --- Affaire (1,1)
Affaire (1,n) --- Lot (1,1) (En sachant que les nom seront les même entre les affaires. Exemple : Affaire1 décomposée en Lot1, Lot2, Lot3 (qui sont en réalité unique)
Affaire2 décomposé également en Lot1, Lot2, Lot3 mais si cela pose problème il y a moyen de spécilaisé ces lot en mettant le numéro d'affaire devant le nom du lot du genre : 104009DBRLot1
Lot (1,n) --- Opération (1,n) [Opération = Opération_Type]
Opération (1,n) --- Opérateur (1,n)

Et oui, entre les Opérations et les Opérateurs je comprend qu'on trouve la date et la durée.

Pour la durée prévue, il me le faut par opération mais aussi par projet exemple :

Opération C Durée Prévue/Opération : 10h
ProjetII Durée Prévue/Projet : 850h

Donc l'idéal serait que quand l'utilisateur de la base fait une recherche par opération que le temps prévue pour l'opération s'affiche et que si c une recherche par opérateur que rien dans la zone de texte durée prévue par opération un slache s'affiche "/". Pareille pour Durée par projet, que celle si s'affiche uniquement quand l'utilisateur fait une recherche par projet et que si ce n'est pas le cas que ça affiche un "/" dans la zone de texte de "Durée_Prévue/Projet".
Il faut également mettre en avant les gains ou les pertes de temps par rapport à la durée prévue.

Mais si cela n'est pas possible, peut-être vaudrait mieux t-il créer un premier formulaire d'analyse par opération et un deuxième formulaire d'analyse pour les Projet et ensuite un troisième formulaire qui permettra d'obtenir les temps par lot, par opérateur, par semaine, par jour ! Qu'en dis-tu ?

Cordialement,

A+

[Triton972]

Bonjour,

OK !

D'abord, ne te complique pas la vie avec des tables semaine, jour, heure. On trouvera d'autre façon de faire plus simples : Il y a beaucoup de fonctions autour des variables "date" (utilisation de la fonction "format" entre autre ...) qui permet de retrouver la semaine, le mois, le nom du jour, etc ...
Je note que tu souhaites enregistrer les durées Opération/Opérateur sous le format : Date jj/mm/aaaa + durée (en minutes ? que l'on pourra convertir au format xx h yy mn).

Il faudra créer une table supplémentaire : Table_Duree dans laquelle on retrouvera :

Id_Duree --- Numéro Auto (Id de la table)
Id_Operation (clé étrangère) ---- Numérique
Id_Lot (clé étrangère) ---- Numérique
Id_Operateur (clé étrangère) ---- Numérique
Date_Suivi ---- Date/heure (format date/abrégé)
Duree --- Numérique (entier, décimales=0) : Nbre de minutes passées par l'opérateur "Id_Operateur" pour l'opération-type "Id_Operation" du lot "Id_Lot" pour la date "Date_Suivi"

Id_Lot étant relié aux objets en amont, il identifie de façon unique : l'affaire donc le projet donc le client. Par une requête on peut donc tout retrouver.

Les tables Table_Heure, Table_Jour, Table_Semaine ne me paraissent pas très utiles pour l'instant.

Table_Client : Il y a le minimum : un nom
Table Projet : Il devrait avoir :

Id_Projet
Id_Client
Date_Limite

peut-être à ajouter (?)

un libellé : Libelle_Projet
une date de création : Date_Creation

Table_Affaire :
Id_Num_Affaire (identifiant)
Num_Affaire : Libellé (nom) de l'affaire
Id_Projet (clé étrangère)

Id_client est inutile car on le retrouve en remontant par Id_Projet

Table_Lot :
Id_Lot (identifiant)
Nom_Lot (que l'on peut "fabriquer" plus ou moins automatiquement ...)
Id_Affaire (clé étrangère)

Id_Projet est inutile on le retrouve en remontant par Id_Affaire

Table_Operation :
Id_Operation (identifiant)
Denomination_Operation

c'est tout !
Id_Operateur sera dans Table_Duree
On pourrait, par contre, rajouter à ce niveau : Durée standard de réalisation ou autres informations de cette nature ... (la durée standard te permettrait de calculer automatiquement la durée "standard" de tes lots, donc de tes affaires, donc de tes projets ! )

Table_Operateur : OK

Table_Duree : Nouvelle table vu plus haut :
Id_Duree
Id_Operation
Id_Lot
Id_Operateur
Date_Suivi
Duree

Après on fabrique les requêtes sous-jacentes et les formulaires (sous-formulaires), état (sous-état) tomberont comme des fruits mûrs (il ne restera que l'ergonomie à peaufiner ...).

On commence par traiter les formulaires de "gestion" :
Saisie, consultation, mise à jour, suppression de toutes les tables décrites plus haut
puis on s'attaque au formulaires (et états associés) d'analyse et de recherche multi-critères.

Qu'en penses-tu ? (définition des tables et programme ...)
@+

[Same03]

Bonjour,

Merci beaucoup ! Je suis désolé d'avoir mis longtemps à te répondre, j'ai eu un problème internet !

Donc oui pour le temps j'aimerai l'enregistrer en minutes pour faciliter les calculs mais qu'on puisse convertir en format xx h yy mn

on peut supprimer les tables heures, jour et semaine si tu veux mais je l'ai avais mise en place pour aller plus vite dans les enregistrements et les recherches.

Je suis d'accord pour la table supplémentaire : Table_Duree

Pour la table Table_Projet je suis d'accord avec sa compostion :

Id_Projet
Id_Client
Date_limite
Date_Creation
Libelle_Projet

Pour la table Table_Client je suis également d'accord :

Id_Client
Nom_Client

Pour la table Table_Affaire je suis également d'accord :

Id_Num_Affaire
Num_Affaire
Nom_Affaire
Id_Projet

Je valide également la Table Table_Lot :

Id_Lot
Nom_Lot (unique ou pas, si il faut qu'il soit unique, il suffirait de mettre le N° d'affaire suivi de Lot1 ou Lot2 ...)
Id_Affaire

Je valide également la table Table_Operation :

Id_Operation
Denomination_Operation

Mais pour la durée prévue par opération par affaire, comment allons nous faire, parce qu'une opération_type pour l'affaire 1 peut durée plus longtemps que la même opération_type pour l'affaire 2 car par exemple l'opération cablage peut être plus longue pour l'affaire 2 car il y a plus de cable à mettre que pour l'affaire 1 alors que c'est tout de même l'opération cablage.
Ainsi, ici, la notion de durée standard ne peut pas être utilisé, il faut mettre une durée spécifique pour chaque affaire.
Donc comment allons-nous pouvoir indiquer le temps prévu pour un lot, le temps prévu pour un ptojet, le temps prévu pour une affaire, le temps prévu pour une opération et le temps prévu par opérateur pour une opération.
Je pensais intégrer ses temps dans les tables du genre :

Table_Affaire :

Id_Affaire
Num_Affaire
Id_Projet
Temps_Prevu_Affaire

Table_Projet

Id_Projet
Id_Client
Date_Limite
Date_Cration
Libelle_Projet
Temps_Prevu_Projet

Table_Lot

Id_Lot
Nom_Lot
Temps_Prevu_Lot

Mais je n'arrive pas à caser le temps prévu par opération à moins qu'on personalise les opérations du genre

Id_Operation Nom_Operation Operation_Affaire Temps_Prevu_Operation
01 Cablâge 1063DBRCablâge 48h00 (48,00)
06 Cablâge 1049DBECablâge 64h00 (64,00)

Qu'en penses-tu ? ou sinon se référer à la table Table_Duree

Table_Operateur : OK

Je valide également la Tâble_Duree :

Id_Duree
Id_Operation
Id_Lot
Id-Operateur
Date_Suivi (que j'appelerai plutôt Jour)
Durée

Et je me disais de rajouté ds cette table le temps prévus par Opération (Temps_Prevu_Operation) et le temps prévu par opérateur pour une opération (Temps_Prevu_Operateur_Operation.

LE programme me va très bien aussi.

Je me lance à transformer les tables ?
Qu'entends-tu par formulaire de consultation (parce que pour moi le formulaire de consultation c'était le dormulaire de recherche) ?

Peux tu m'indiquer les requêtes qui vont être nécessaires pour la réalisation du formulaire d'enregistrement (Saisi) et de consultation ? Pour les formulaire de mise à jour, j'ai juste à me baser sur les tables !

Quels sont les relations à mettre en place ?

Je me lance de ce pas sur les Changements des tables et sur les formulaires de mise à jour.
J'attend tes réponses pour les requêtes, les relations et Temps_Prevu_Operation ; Temps_Prevu_Operateur ; Temps_Prevu_Lot ; Temps_Prevu_Projet ; Temps_Prevu_Affaire.

[Triton972]

Bonsoir,

On va régler simplement le problème de durée des opérations :
Les "opération type" vont aller dans une table :

Table_Operation_Type :

Id_Operation_Type
Denomination_Operation_Type

Table_Operation : devient spécifique à un Lot et reprend le libellé de Opération_Type :

Id_Operation
Id_Lot
Id_Operation_Type (on récupère le libellé par ce biais)
Duree_prévu_Operation (pour le lot sélectionné)


On garde la même table : Table_Duree sauf que Id_Operation pointe vers la nouvelle table Operation (tu me suis ?)

On pourra tout remonter et tout calculer pour les durées prévues avec les relations :
Durée d'un lot, d'un projet, d'une affaire.

On utilisera une fonction qui transformera une durée en minutes dans le format hh mm

OK ?
Je reviens vers toi demain, pour la suite ...

[Same03]

Bonjour,

Je pense qu'il y a une confusion, il n'existe pas de distinction entre Denomination_Operation et Opération_Type se sont les mêmes. Ainsi ça donnerais les tables suivantes :

Table_Denomination_Operation (qui permettra de faire une liste déroulante sans répition, de mettre à jour les opérations) :

Id_Denomination_Opearation
Denomination_Operation

Table_Operation (qui va permettre d'enregistrer les opérations qui doivent être effectuées pour un lot et une affaire) :

Id_Operation
Id_Lot
Id_Denomination_Operation (récupération du libéllé à l'aide de l'identifiant)
Duree_Prevue_Operation (pour le lot sélectionné)

Donc pour la table Table_Duree ça donne ça :

Id_Duree
Id_Denomination_Operation
Id_Lot
Id_Operateur
Date_Suivi
Duree
Temps_Prevu_Operateur_Operation

Il faut tout de même rajouté le Temps_Prevu_Lot ; Temps_Prevu_Projet ; Temps_Prevu_Affaire ; Temps_Prevu_Semaine

Je le fait et o pire on supprimera les lignes concernées.

[Triton972]

Bonjour,

Ok pour Table_Denomination_Operation.

Table_Duree peut rester comme ca mais avec la "nouvelle" table Table_Operation on peut faire un peu plus simple en pointant directement vers celle-ci au lieu de pointer vers Lot et Denomination_Operation.
Cela pourrait donner :

Table_Duree ça donne ça :

Id_Duree
Id_Operation
Id_Operateur
Date_Suivi
Duree
(Temps_Prevu_Operateur_Operation pas ici ! Si tu veux determiner un standard prévu par Opération et par Opérateur il faudrait alors rajouter encore une table !! As-tu vraiment besoin de cette donnée ?)

Concernant les durées (j'ai l'air d'insister ...). Si la durée de ton lot est la somme des durees de toutes ses operations de ce lot, durée de l'affaire la somme des durées de tous ses lots, etc ... On peut les calculer facilement avec une fonction ou dans une requête. ce qui préférable.

Désolé de passer autant de temps sur les données et d'être aussi tatillon mais on ira bcp plus vite dès que tout sera ok

cordialement,
@+
On calcule

[Same03]

Bonjour,

très bien pour les Temps_Prevu_Lot ; Temps_Prevu_Affaire ; Temps_Prevu_Operateur_Operation on fera avec des sommes ou division pour le temps prévu par opérateur par opération en fonction des temps prévus par opération. Donc avec la division pas besoin de faire une table supplémentaire non ?

Et oui le temps prévu pour un opérateur par opération m'est indispensable !

Je rechange tous ça et je met la base en lien !

[Triton972]

Bonsoir,

Concernant les durées prévues par opération et par opérateur : Si effectivement 1 opération (d'un même lot, d'une même affaire, d'un même projet) est prévue d'être effectuée par plusieurs opérateurs à qui tu vas donner des objectifs de durée d'exécution, il faudra les piéger dans une table similaire à Table_Duree_Operation qui pourrait être Table_Duree_Prevue_Operation (avec "Duree prévue" au lieu de "Duree realisee"). Par contre, je ne comprends pas comment tu répartis le travail entre les opérateurs si l'opération est le plus petit "découpage" technique de ton activité (il n' y a pas de tâches dans une opération ??!! rassures-moi!).

Si par contre, une opération est démarrée par Operateur1 puis continuée par Operateur2 et finie par Operateur3 alors pas besoin de table supplémentaire ! On pourra "calculer" une sorte de "vitesse standard" que l'on pourra comparer à la réalisation effective. Je m'explique :

SI l'opération "xyz" est prévue d'occuper 40 heures/homme on a 100 % réalisé = 40 heures.
Opérateur1 a passé 8 heures sur l'opération "xyz" et estime son avancement (sa contribution à la réalisation de l'opération "xyz") à 20 % alors on peut dire qu'il est dans le "rythme" (40 h=100% => 10% d'avancement=4h donc 8h= 20% !!). Si il n'a avancé que de 15% il est en retard et on peut calculer ce retard (15% aurait du l'occuper pendant 6 h, il a consommé 8 h ==> il a perdu 2 h) ... Donc on peut tout gérer en piegant la "durée par opération par opérateur" et "l'avancement de l'opérateur pour l'operation". Cette dernière donnée pouvant alors être facilement intégrée dans Table_Duree ...
Quelle option te semble t-elle plus proche de tes objectifs ?

Concernant requêtes et formulaires. Je verrais bien, dans 1° temps, 6 formulaires principaux:

1- Un "gros formulaire" basée sur une requête basée sur Table_Projet (formulaire unique) et 3 sous-formulaires incorporés dans le formulaire principal :
Un sous-formulaire (formulaire continu) basé sur requête_Table_Affaire (on créé un lien Père-Fils avec le formulaire principal pour simplifier la prise en compte de la liaison)
Un sous-formulaire (formulaire continu) basé sur requête_Table_Lot (relié au sous-formulaire précédent par un peu de code VBA ou requête paramétrée (on verra) qui permettra d'identifier tous les lots d'une affaire du projet.
Un dernier sous-formulaire (formulaire continu) basé sur requete_Table_Operation (même type de fonctionnement que le précédent) qui listera les opérations du lot sélectionné et permettra de saisir les durées prévues d'exécution.
C'est un peu scabreux (bcp de sous-formulaires avec mise à jour des requetes sous-jacentes) mais ca permet d'avoir un seul écran pour faire toute ta saisie.
Remarque: on ferra dans les "bons sous-formulaires" les calculs et l'affichage des durées prévues

2 - Un peu la même chose avec en plus : un sous-formulaire pour saisir les réalisations (date, durée, avancement (?)) basée sur requete_Table_Duree
Remarque : Idem. On ferra les calculs des temps réels, ecart , etc... dans les "bons sous-formulaires"

C'est les 2 plus compliqués. Les 4 autres :

3 - Un formulaire continu pour lister tous les projets avec possibilité de se connecter sur 1) ou 2).

4 - Un formulaire pour créer, consulter, mettre à jour les "clients"

5 - Un formulaire pour créer, consulter, mettre à jour les "dénomination_opérations"

6 - Un formulaire pour créer, consulter, mettre à jour les "opérateurs"

Remarque : On peut "sophistiquer" la création des 3 dernieres tables en la rendant possible lors de la saisie du formulaire 1) (à voir + tard)
Le formulaire d'analyse et de recherche multicritère est spécifique : A faire après.

Bien y a plus qu'a ! Qu'en penses-tu ?

[Same03]

Tout d'abord je présente mes excuses pour le temps de réalisation des tables et du coup du temps tardif de ma réponse. J'ai vraiment pas de chance ces dernier temps avec informatique, d'abord internet et ensuite mon PC qui lâche.

J'en pense que je n'arrive pas à imaginer le résultat des 2 gros formulaires et du coup je ne vois pas comment construire les requêtes pour que ça corresponde.

Je te propose donc de te donner la nouvelle base avec les tables construites comme on en avait parlé. Et montre moi ce que donne les 2 gros formulaires.

Je me chargerai ensuite des autres.

On fait comme ça ?

[Triton972]

Bonjour,

Je te joins quelques éléments :

- Quelques modifications dans les tables pour les rendre cohérentes par rapport à nos discussions.
- Les requêtes principales pour gérer le 1° formulaire de mise à jour.
- Le 1° gros formulaire (avec ses sous-formulaires).

J'ai fait ca vite donc l'ergonomie n'a pu du tout été travaillé (je te le laisse ...) et j'ai fait des vérifications sommaires. C a l'air de marcher mais on n'est pas à l'abri de quelques soucis, surtout qu'il y a un peu de code ...

Dis-moi ce que tu en penses afin que l'on puisse passer à la suite : saisie des temps de réalisation.

@+

[Same03]

Bonjour,

Tout d'abord, desole pour le manque des accents, je suis sur un clavier QWERTY la majorite des jours.

1ere information : Suite a un probleme de Communication il s'avere que Projet = Affaire c'est pour cela que je ne l'avais pas mis dans les tables. Donc on peut supprimer Projet et le remplacer par affaire. ca donne :

Table_Affaire :

Id_Affaire
Numero_Affaire
Libelle
Date_Limite
Date_Creation

ensuite si je comprend le 1er gros fromulaire : Frm_Projet_1 correspond au formulaire qui me permettra de faire des recherches ? Puisque tu dis qu'on passera ensuite a la saisie des temps de realisation.

Sauf que j'ai besoin d'un Formulaire qui me permet de faire des recherches par listes deroulantes : Nom_Client, Numero_Affaire, Denomination_Operation, Denomination_Operateur, Lot, Date, Periode.

En utilisant un bouton radio ("Et/Ou") comme ds l'exemple que je vais mettre en piece jointe sauf que ca ne marche pas, je n'ai pas de lien entre le fomulaire principal et le sous formulaire.

Je pensais donc n'avoir que deux formulaires :
- un formulaire principal avec toutes les listes deroulantes de recherche et l'option Et/OU
- Un sous fomulaire lie qui affiche les resultats sous la forme suivante :
Num_Affaire; Client; lot; Operateur; Operation; Date; Duree de realisation; Duree_Prevu_operation

Apres je sais pas du tout comment ajouter le temps par lot, par projet, par operateur et les temps prevus pour tout ca

Je pensais ajouter des lignes totaux en dessous du sous formulaire :

Total temps realise par lot ; Temps prevus pour ce lot choisi dans la recherche
Total Temps realise sur l'affaire; Temps prevu pour l'affaire choisi dans la recherche

Autre point, par la Suite, les Id_que l'on retrouve vont-ils disparaitre (etre caches) parce ceci va perturber les utilisateurs. Se sont des informations surperflues et l'objectif de la base est de pouvoir analyser au plus vite.

Regarde l'exemple des formulaires que je t'envoi et dis moi ce que tu en penses ?

en piece jointe tu as la base qui contient le formulaire de recherche : FormulaireRecherche. C'est a peut pret ca qu'il faut sauf que les donnes du haut doivent etre en liste deroulante, que dans la grille en dessous il faut en plus la date, la duree de realisation et la duree prevue par operation par Operateur

Avec en dessous les lignes dont j'ai parle ci-dessus qu'on a dit qu'on obtiendrait en faisant des calculs.

ca te va ?

Cordialement.