Discussion :

[bobby5169]

Bonjour à tous;
Je suis en train de concevoir un outil de gestion de pièces de rechanges pour des machines de production.
Aujourd'hui c'est géré sous Excel et beaucoup de pièces sont en double avec des références saisies de manière différentes


Je suis parti sur ma conception MCD mais j'ai du mal à me représenter les différents liens et contraintes entre mes tables

Il s'agit d'un outil très simple pour connaitre les pièces disponibles en magasin, le nombre installé sur le site, et faire des fiches mouvement de sortie et entrée pièces.

Dans la saisie d'écran ci-dessous, j'ai commencé mes cardinalités mais j'ai vraiment du mal avec ce concept, et je souhaiterai faire quelque chose de propre.

Un pièce peut être installée sur une ou plusieurs machine
Une machine à une ou plusieurs pièces de rechange
Une référence de pièce peut être en stockée dans plusieurs lieux



En espérant que vous puissiez me corriger dans les erreur et m'aider à comprendre les cardinalités.

Par avance merci

[marot_r]

Bonjour.

Pour une gestion de stock, il est preferable d'avoir.

tblPiece
ClefPiece
Autres infos (ex : Nom)

tblMouvementStock
ClefMovementStock
DateMovementStock
TypeMouvement (Entrée, Sortie, Stock Initial, Gain sur stock, Perte sur stock)
QteMouvement
PrixUnitairePiece

Pour avoir le stock a une date precices tu fais la somme des mouvements , de la date de debut a la date voulue.

A+

[bobby5169]

Merci de l'info.

En réfléchissant un peu plus je pense qu'il faut que je fasse une tabble d'association entre les PR et les équipements

[marot_r]

Oui cela va correspondre a ton association Monter.

quelque chose comme :

tblPieceMachine
ClefPieceMachine (optionel mais je trouve cela pratique)
ClefPiece
ClefMachine

ou

tblPieceMachine
ClefPieceMachine (optionel mais je trouve cela pratique)
ClefPiece
ClefMachine
DateMontage
DateRetrait

Est-ce que chaque piece est identifiee de maniere unique ?

A+

[marot_r]

Ou tu peux aussi utiliser la table des mouvements si tu travailles une piece a la fois

tblMouvementStock

ClefMovementStock
DateMovementStock
TypeMouvement (Entrée, Sortie, Stock Initial, Gain sur stock, Perte sur stock)
QteMouvement
PrixUnitairePiece
ClefMachine (Pour les montage qui est une sortie et les retrait qui est une entrée)

[bobby5169]

Chaque pièce de rechange a un numéro unique
Chaque Machine a un identifiant unique

Le problème majeur que nous rencontrons aujourd'hui c'est qu'une Piece peut avoir avoir plusieurs références internes, c'est pourquoi je souhaiterai passer sous acces pour faciliter les recherches et la gestion

Exemple :
Carte interface CN axe --> ref constructeur AX37 B72/2 --> Ref interne ET78956Z1
CarteCN axe X --> ref constructeur AX37B72-2 --> Ref interne ET11253T1

Alors que physiquement c'est la même carte

Pour la table mouvement, je souhaite tracer toutes les sorties de pièce. Plusieurs pièces peuvent être sortie sur un même bon de travail

[marot_r]

Bonjour.

Quand je parlais d'intifiant unique je pensais :

1. J'ai 2 pieces identiques l'une est identifiee P1 et l'autre P2 et elles vivent leur vie independament. En tout temps je sais que c'est P1 ou P2 que je manipule.
2. Par opposition mettons a des boulons de 12 ou tu as un tas de boulons de 12 et tu te moques de savoir lequel tu manipules. Tu n'as pas le boulon de 12 No 1, No 2, etc.

Est-ce bien le 1er cas qui s'applique a ce que tu veux faire ?

Pour tes synonymes (meme piece, reference differente) voici comment j'ai resolu ce type de probleme.

tblPiece
ClefPiece (un numero sequentiel utilise en interne par l'application).
Autres infos.

tblSynPiece

ClefSynonyme
ClefPiece
Synonyme

Avec cela tu peux avoir autant de references que tu veux pour une meme piece.

Une facon un peu moins "propre", mais qui peut marcher aussi tres bien si c'est pour des humains, est d'avoir tous les synonymes dans un meme champ.

ex :

1245 | CarteCN axe X | AX37 B72/2 | ET78956Z1, ET11253T1

Ainsi tu as l'info pour les refs internes et tu peux faire une recherche dessus mais dans l'appli tu te sers de 1245 la clef systeme.
Attention c'est viable si tu as peu de synonyme sinon verifier qu'il n'est pas deja la peut etre penible et il est prudent de classer tes synoymes par exemple en ordre alpahbetique croissant.

Aussi tu peux peut-etre considerer avec des Type de pieces mettons le type CarteCN axe X

et avoir pour chaque piece :

tblPeiece

ClefPiece
ClefType (clef de CarteCN axe X par exemple)
Reference

Et tu peux imaginer avoir des synonymes pour les types si necessaire.

L'idee est que l'utilisateur ait l'illusion qu'il a du choix mais toi en interne tu ne gardes qu'un numero unique (ClefPiece).
Ce qui en plus a des des vertues normalisatrices car l'application n'utilise a l'affichage qu'un seul libelle donc les doublons se trouve elimine de la vue ... et loin des yeux, loin du coeur c'est bien connu :-).

Pour la table mouvement, je souhaite tracer toutes les sorties de pièce. Plusieurs pièces peuvent être sortie sur un même bon de travail

Comme tu enregistres les pieces individuellement ce n'est pas un probleme.

Si tu le souhaites tu peux avoir :

tblBonTravail

ClefBonTravail
Autres infos (ex : DateBonTravail)

tblMouvement

ClefMouvement
ClefBonTravail
ClefPiece
TypeMouvement
Autres infos

A+

[bobby5169]

Bonjour.
Merci beaucoup pour ta réponse.
C'est bien le premier cas qui s'applique.
Ta solution avec mot clés me parait très bien, je pense que je vais partir comme ça.

D'après toi vaut'il mieux que je fasse une table d'association pièce/ Equipement? Ou dans équiepement une liste de choix avec option choix multiple est une solution viable (et plus facile à mettre en oeuvre)?

[marot_r]

Bonjour.

Ceci est un AVIS et ne represente que mon opinion : Les champs a choix multiple sont selon moi une "heresie".

Bon plus argumente que sur le principe de la fois :-).

Quand tu crees un champ a choix multiple, tu crees en faite une table dans un champs et les enregistrements deviennent un peu plus delicats a traiter et utiliser.
Donc personnellement je prefere une table d'association qui se comportment comme toutes les tables et avce lequel je peux utiliser tous les trucs et objets d'interface d'Access.
Le seul avantage que je vois aux champs a choix multiple, c'est que l'inteface avec selection dans la liste est assez agreeable et intuitive et que tu n'as pas creer un sous-formulaire pour faire la saisie de l'assotation.

Un truc a propos du developpement d'appli Access, battit tes tables et tes relations puis essaye "a la main" directement dans les tables la saisie d'une ou deux informations (ou cas typiques) pour voir si cela repond a tes besoins.
Une fois que tu as commence a construire ton interface et tes requetes et autres, modifier la structure de ta BD peut devenir plus penible et long.
Les tables et relations sont les fondations de ton appli donc y passer un peu de temps est rentable.
Et aussi il serait etonnant que tu fasses un truc parfais des la 1ere fois.
J'ai monte pour moi une mini appli d'inventaire (juste 2 tables) et j'ai modifie mes tables plusieurs fois car certains besoins ne sont apparus qu'a l'usage et d'autres avaient ete mal anticipes.
Donc pense a ton modele mais n'y passe pas une ertenite.

A+

[bobby5169]

Pour résumer j'ai finalement fait une table:

• Equipement
• Pieces de rechange
• Assos PR équipement

Ca permettra de faire déjà un très gros travail sur la qualité des données.

La partie stock et mouvement viendra par la suite.
En tous cas Marot_r merci de tes conseils