Modélisation d'une information de suivi de stock Résolu/Fermé

Question

Bonjour, 

je rencontre des difficultés pour modéliser une information en vue de compléter une application Web. Voici le problème:

- les téléphones sont retirés du magasin en lot ( 10 ou 50 unités ou même plus)  par le service de Liaison  
- Ces téléphones sont ensuite codifiés ( enregistrer les numéros de série) 
- Après validation par le responsable du service, le téléphone est remis au vendeur ( pour une prestation de service)
-  Un téléphone affecté peut être retourné au service de liaison pour réparation à l'atelier ou pour non disponibilité du vendeur.

On aimerait connaitre:

- les téléphones codifiés et  affectés
- Les téléphones codifiés et en attente de validation
- Les téléphones affectés et retournés et en attente d'une nouvelle affectation
- les réparation effectuées sur un téléphone
- la 1ère date de mise en service d'un téléphone

J'ai pu créer les tables  codification, Affectation,Réparation et Instance  mais je ne parviens pas à créer les relations entre ces tables .

Je voudrais signaler que cette analyse est un nouveau  module d'une application de gestion de stock que j'ai développée et mise en exploitation. Entre autres produits en stock il y a ce téléphone que je voudrais faire le suivi.

S'il vous plait, pouvez vous m'aider ou me me mettre sur le chemin? 

Merci

Ichigo D Labu · Answer

Bonjour,

je ne suis pas d'accord avec toi sur les nom de table : je crois que codification et affectation désigne la même opération. ensuite la validation est une opération distinct c'est pourquoi on va ajouter une table "Validation" pour la table Réparation je suis d'accord mais je n'ai as compris l'utilité de la table Instance !?

A mon avis soit tu crée une autre table nommé "Retour" ou bien tu regroupe la  "retour" et "réparation" dans une même table avec un champ "Type" pour faire la différence ( moi je suis avec la 1er solution elle est plus simple)
 
Pour les autre Table les champs seront comme suite :

Codification :
 - NA : numéro d'affection ( tu met le numéro de série carrément )
 - Date d'affection
 - Agent ( celui qui a fait l'affectation si tu veux
 -...plus d'autre champs qui pourront te servir après.

Validation :
 -NV : Numéro de validation 
 -NA : Numéro d'affectation (clé étrangère)
 -ResponsableS: Resposable de service qui va valider.
 -Vendeur:a qui on a remis les téléphone.(numéro o nom c'est ton choix )

Réparation:
 -NR:Numéro de réparation.
 -NA : Numéro d'affectation (clé étrangère)
 -NV : numéro de validation pour laissé une trace sur qui a fait la validation.
 -DateR:Date de la réparation.
 -Techenicien:Celui qui a fais la réparation(si tu veux)

Retour:
 -NRt:Numéro de retour.
 -NA : Numéro d'affectation (clé étrangère)
 -NV : numéro de validation pour laissé une trace sur qui a fait la validation.
 -DateR:Date de Retour.


Je pense que avec cette modélisation tu peux créer des requêtes pour faire le suivie des téléphone.

Bonne chance

pulls · Answer

Merci de vouloir m'aider,

je vous remercie mille fois de votre disponibilité.

En effet , je pense qu'il y a un malentendu  sur les tables codification et affectation. En effet:

- Codification consiste à enregistrer le numéro de série du téléphone dans la base de données, c'est le service de liaison qui fait ce travail, le travail du magasinier se limite seulement à sortir, à la demande, un lot de téléphone et de mettre à sa disposition.

- Affectation consiste à donner un téléphone à un vendeur, un téléphone peut bien être codifier sans être affecter.

Vous voyez bien qu'il ne s'agit pas de la même opération.

je ne sais pas si vous êtes du même avis avec moi qu'il faut 2 tables distinctes?



Cordialement

Ichigo D Labu · Answer

Bonjour,

Oui maintenant que vous avez mentionner que les deux opération sont réalisés par deux services différent, deux tables distinct sont favorables 

le schéma des autres tables vous convient-t-il ?




Cordialement.

pulls · Answer

Merci,

le schéma que vous m'avez proposé est très intéressant , puisque je pourrais faire mes requêtes en sortie suivant les objectifs. Mais j'ai une préoccupation.  

Je vous ai expliqué que quand un produit sort du magasin, il doit être codifié ( enregistrement de la série) ensuite une autre opération consiste à affecter ce produit au vendeur. Mais je ne sais pas à quelle table, lié le champ codification et le champ affectation. Pour être plus clair voici une partie de schémas existant et en exploitation. il s'agit d'une application de gestion de stock:

1er module déjà en exploitation

PRODUIT ( idProduit, libelle, idFournisseur#)

MOUVEMENT( idMouvement, date, typeMouvement ( entrée ou sortie), quantité, idville#, idProduit#, expediteur, destinataire)

DISTRIBUTION( idDistribution, idProduit#, idVille#, date, vendeur, quantité) // il s'agit ici de la distribution des consommables, car on distingue 2 types de produit au magasin, les consommables et  le materiel comme le téléphone, les consommables sont directement consommé sur le terrain alors que le matériel a une durée de vie et c'est ce suivi du materiel sur le terrain qui fait l'objet du 2ème module de l'application.

2ème module à intégrer

CODIFICATION( idCodification, dateCodification, agent, idMouvement#) // ici j'ai lié la table codification à la table mouvement, puisque en connaissant l'id d'un mouvement, on peut connaitre le produit correspondant. Je ne sais pas si vous trouvez cela logique?

AFFECTATION( idAffectation, dateAffectation, dateFinAffectation, codeVendeur, idCodification#)

VALIDATION ( idValidation, idCodification#, responsable) // j'ai lié la validation à la codification, je ne sais pas si c'est logique?

RETOUR( idRetour, idAffectation#, dateRetour)

REPARATION( idReparation, idRetour#, dateReparation, technicien)



NB: les clés étrangères sont suivies d'une dièse


Voilà donc le schémas que je propose avec l'aide de Tchigo. s'il vous plait, je voudrais que vous m'aidiez à relever les éventuelles incohérences; il s'agit de ma première application après mes études et je suis en stage préemploi.

Cordialement.

Ichigo D Labu · Answer

Bonjour,

Pour la table Codification je pense aussi que la lier a la table Mouvement est logique puisque le lien avec la table Produit est direct.

Cependant si j'ai bien compris le sens de la démarche qui est :
Codification -> Validation -> Affectation -> Retour -> Réparation

La logique dis que les clés étrangères migrent dans le même sens de cela les Tables Validation et Affectation seront comme suite :

AFFECTATION( idAffectation, dateAffectation, dateFinAffectation, codeVendeur, idValidation#) 

VALIDATION ( idValidation, idCodification#, responsable) 

Pour le reste je pense que c'est Ok.

Je répondrait a vos question aussi tôt que je le pourrais.


Bonne chance.

pulls · Answer

Merci Tchigo,

votre remarque sur la structure de la table AFFECTATION est vraiment pertinente, c'est la clé de la table validation qui doit migrer dans cette table.

Je voudrais completer le sens de ma démarche que tu as mis en evidence:

Codification -> Validation -> Affectation -> Retour -> Réparation
  ------------------------------------------------------- |  --------- | ------------
   --------------------------------------------------------V ---------V-------------
    ------------------------------------------ ------------- stockage----------------


( pointillé à ignorer, juste pour caler les flèches descendantes)

En effet les téléphones retourné en bon état , parce que le vendeur est indisponible, sont stocké au service de liaison en attente d'une nouvelle affectation; et justement c'est pour cela que j'avais créé la table INSTANCE; car un téléphone retourné en bon état ou un téléphone qui sort de la réparation doit être stocké quelque part, d'ou la nécessite de la table INSTANCE.

Je ne sais pas si vous êtes du même avis que moi.

Une autre préoccupation s'il vous plait. Comment les téléphone de la table INSTANCE peuvent être de nouveau reaffectés, si je crée une clé étrangère idInstance# dans la table AFFECTATION, ça doit former une boucle; et je crois avoir lu quelque part que ce n'est pas recommandé.  Qu'est-ce que vous en pensez s'il vous plait?

Merci


Cordialement.

Ichigo D Labu · Answer

Salut,

Si j'ai bien compris la Table Instance a pour But de spécifier les téléphones non affecter ?

A mon avis pas besoin d'une Table instance!rien n'empêche que les Tables Retour et Réparation elles même peuvent nous donner l'information qu'on veux puisque un téléphone qui existe dans l'un de ces Tables est d'office un téléphone en instance a condition qu'il n'ai qu'une seul et unique affectation.une requête fera l'affaire.

en ce qui concerne le cas ou un téléphone subit une 2éme affectation, je ne sais pas qu'elle est la procédure mais on principe une téléphone ne peut subir une second affectation que si il est déjà passer par la table Retour ou Réparation, mais la table comme elle est maintenant permettra de faire une second affectation puisque on a q'une seul clé Primaire IdAffectation et le champ Date fera indice pour différencier les affectations d'un même téléphone a condition bien sure que l'affectation n'est possible qu'une seul fois par jour.tous dépend des contraints.


Je voudrais bien savoir avec quel outil du développe le module comme ça on sera sur la même longueur d'onde.


Cordialement

pulls · Answer

Salut Cher ami, 

J'ai été malade et j'ai interrompu le travail depuis près d'une semaine.

En effet, vous avez raison par rapport à la table Instance, une simple requête pourra nous permettre de connaitre les téléphones non affectés, non expédiés, en reparation, ou au rébus ( qui ne peuvent plus être réparés).

voici enfin ce que j'ai défini comme table:

1er module déjà en exploitation 


PRODUIT ( idProduit, libelle, idFournisseur#) 

 // il s'agit ici des consommables pour le téléphone comme encre, rouleau papier pour  imprimante

MOUVEMENT( idMouvement, date, typeMouvement ( entrée ou sortie), quantité, idville#, idProduit# ou idAccessoires# ou idMaterie# ou idSuppAcc#, expediteur, destinataire) 



DISTRIBUTION( idDistribution, idProduit#, idVille#, date, vendeur, quantité) // il s'agit ici de la distribution des consommables, 


2ème module à intégrer 

ACCESSOIRE( idAccessoire, avec Support? ( oui ou non), libelle, idFournisseur#)

SUPPORT_ACCESSOIRE( idSuppAcc, libelle, idFournisseur#)

MATERIEL ( idMateriel, avec accessoire? ( oui ou non) , libelle, idFournisseur#)


// Nouveau: je viens d'ajouter ces 3 précédentes tables, par rapport aux nouvelles informations; en effet un téléphone pour fonctionner doit avoir un numéro ( Accessoires) et un numéro pour fonctionner doit avoir une puce ( SUPPORT_ACCESSOIRE) , une puce sur un numéro peut se griller et être remplacée par une autre puce de numéro de série différent, et un numéro avec sa puce peut passer d'un téléphone à un autre téléphone , exemple : si la puce d'un téléphone sur le terrain ( affecté) se grille, on peut prendre une puce sur le téléphone en réparation pour le secourir et ça peut rester définitif dans ce téléphone. 


CODIFICATION( idCodification, dateCodification, idAgent#, idMouvement#, n° série) 

// ici j'ai lié la table codification à la table mouvement, puisque en connaissant l'id d'un mouvement, on peut connaitre le produit correspondant. 

ASSOC_ACCESSOIRE( idAssocAc, dateDebut, dateFin, idCodification# (  pour accessoire), idCodification# (  pour support))

// ici on associe un support ( puce) à un accessoire ( numéro téléphone)

ASSOC_MATERIEL ( idAssocMat, dateDebut, dateFin, idCodification#( pour materiel),  idAssocAc#)

// ici on associe un accessoire ( numéro de téléphone ) avec son support ( puce) à un matériel ( téléphone)


VALIDATION ( idValidation, idAssocMat#,agent,responsable) 

// ici on fait valider un téléphone complet ( avec accessoire) avant affectation ou Expédition

AFFECTATION( idAffectation, dateAffectation, dateFinAffectation, codeVendeur, 
idValidation#) 

EXPEDITION( idExpédition, datedepart, villeDepart, dateArrivée, villeArrivee,idValidation#, agentDepart,agentArrivee)


REPARATION( idReparation, idAffectation#, idExpédition#,dateReparation, technicien) 


REBUS ( idRebus, idReparation#, prix vente, observation, dateRebus)



Voici mes préoccupations:

1- Je ne sais pas si ma logique est correcte et souple.

2- J'ai créé 4 tables pour les différents produits:
      a) Table produit  pour les consommables
      b) Table matériel pour les téléphones
      c)  Table Accessoire pour les numéros téléphone
      d)  Table Support_Accessoire pour les puces de téléphone

Vous me direz que l'autre solution , était de creer , un seule table produit qui contiendra tout ça, avec un champ typeProduit pour consommable, materiel, accessoire et support _accessoire; mais vu la nature des champs des différentes tables , j'ai éclaté en 4 tables. L'une des conséquence de ma démarche , est que pour faire un mouvement de stock( voir table mouvement), je dois préciser avec des boutons radio, s'il s'agit d'un consommable, d'un materiel, d'un accessoire ou d'un support accessoire.  Je ne sais pas si c'est optimisé d'éclater en plusieurs tables?


3- La table CODIFICATION contient : la codification du matériel ( téléphone), la codification des accessoires ( numéro tel) et la codification des supports accessoires ( puce téléphone).  Est ce que c'est optimisé de mettre toutes les codification dans une même table?  car je pouvais créer 3 table: codification_materie, codification_accessoire, codification_support_accessoire.
 Quelle est la solution optimale?

Je vous remercie de votre précieuse aide

Cordialement.

Modélisation d'une information de suivi de stock

8 réponses

Discussions similaires