PC SOFT

FOROS PROFESIONALES
WINDEVWEBDEV y WINDEV Mobile

Inicio → WINDEV 2025 → structure analyse gestion produit
structure analyse gestion produit
Iniciado por GB, 12,abr. 2020 20:02 - 23 respuestas
Miembro registrado
371 mensajes
Publicado el 12,abril 2020 - 20:02
Bonjour,

Je réalise un ERP pour ma société afin de gérer l'intégralité du process commercial et administratif. J'ai déjà bien avancé dans la programmation (client, fournisseur, devis, gestion chantier ...)

J'aborde la gestion de stock et je pense avoir pris un mauvais départ dans l'architecture de l'analyse :

A l'heure actuelle j'ai un fichier produit dans lequel j'ajoute un enregistrement par produit et par fournisseur (le produit X peut avoir 2 fournisseurs différents avec des condition d'achat et de vente différentes, ce qui génère 2 enregistrements dans le fichier).


Je souhaite gérer en stock mes produits mais aussi des consommables. Hors pour ces consommables je souhaite gérer le stock de façon générique ( je veux avoir la quantité en stock du consommable Y, sans forcement gérer la quantité en stock du produit Y acheté chez le fournisseur A ou B). Je veux également pouvoir générer des bons de commande avec les bonnes ref et prix. De ce fait, pour ce fonctionnement il faut 2 fichiers :

- 1 fichier consommable (nom générique et données globale)
- 1 fichier consommable_fournisseur ( ref fournisseur, conditionnement, prix etc ...)

Du coup je n y vois plus très clair quant a l'architecture a adopter sachant que je veux éviter la redondance des données, et de devoir aller cherche des données une fois dans un fichier, une fois dans un autre.

Avez vous des retours d'expérience ou des idées me permettant d'avancer sur ce point ?
Miembro registrado
4.362 mensajes
Publicado el 12,abril 2020 - 23:39
Bonjour,
La démarche est bonne.
Ensuite, il va falloir passer par des requêtes paramétrées.

--
Il y a peut être plus simple, mais, ça tourne
Miembro registrado
371 mensajes
Publicado el 13,abril 2020 - 08:17
Bonjour.

Peux tu etre plus précis ?
Miembro registrado
4.362 mensajes
Publicado el 13,abril 2020 - 10:43
Pour que je sois plus précis, il faudrait que tu le soit aussi. Qu'appelle tu un produit, qu'appelle tu un consommable, quelles sont les recherches que tu veux effectuer.
Ton sous-MLD regroupe ces 3 entités. Il semble (j'ai quand même quelques doutes quant-à la relation Produit-Fournisseur) bien être 3FN ce qui es le minimum vital.

--
Il y a peut être plus simple, mais, ça tourne
Publicado el 13,abril 2020 - 12:06
Il te faut séparer tes tables.
1) table Article - Dans laquelle tu ne mettras qu'une seule fois chaque article pour qu'elle reste propre avec un IDArticles
2) tu créais une table fournisseur contenant un lien vers l'IDArticles

du coup tu n'as plus qu'a faire une requêtes des tes fournisseurs avec IDArticles = IDArticles de ta fiche article sélectionnée.
ça te permet de mettre à jour ton stock dans la fiche Fournisseur d'un article sans toucher les fiches du même article avec d'autres fournisseurs.
De plus pour chaque fournisseur tu peux avoir un tarif different de ton articles, des frais de ports, des infos différentes, etc....

Tu peux faire la même chose pour tous les fichiers et tu auras une analyse propre et claire.
Miembro registrado
371 mensajes
Publicado el 13,abril 2020 - 13:36
Bonjour,

J'appelle un produit un article destiné a être vendu et pouvant être composé d'autre article (produit en général). 1 produit = 1 fournisseur = une condition d'achat et de vente

Un consommable est un article nécessaire à l'accomplissement de l'activité (en gros des vis, des boulons, des chevilles). Un consommable peut être acheté chez plusieurs fournisseur et sera stocké en vrac (je ne différencie par la vis du fournisseur X de la vis du fournisseur Y). Il est en principe pas vendu directement au client, mais cela peut arrivé ponctuellement.

j'ai également des profils ( barres en aluminium ou fer ...) et de tôles. Même principe que les consommables.

J'ai donc créé des types de famille pour pouvoir afficher uniquement les famille adaptées a chaque type d'article.

je pense essentiel de regrouper tous mes articles dans un seul fichier afin d'avoir une souplesse d'utilisation (par exemple si je veux vendre un consommable).
C'est également plus souple pour la gestion de stock (1 fichier article => 1 fichier entrée => 1 fichier sortie)

Pour regrouper mes consommables avec l’appellation générique je pensais créer un fichier qui me sert a stocker les données identique (appellation, quantité mini, qté alerte, emplacement, ref interne pour code barre). Ce fichier ne sera pas relié par une clée.

Qu'en penses tu ?


Publicado el 13,abril 2020 - 14:34
Bonjour,
La relation avec Fournisseur me pose problème. Je pense qu'elle ne respecte même pas la 2FN. En effet l'IDArticle permet de retrouver l'IDFournisseur dans la table ARTICLE. (Les pros me corrigeront)
De plus l'inconvénient de votre méthode est qu'elle va présenter des limites au moment de l'inventaire et de l'évaluation des stocks de produits. Imaginer que vous ayez plusieurs articles identiques livrés par différents fournisseurs. Vos requêtes risques d'être assez complexes à gérer.
Vous pouvez vous retrouver pour un même produit avec des prix_Public différents etc...
Au moment de la vente, lequel des produits vous vendez (ils sont identiques),...
Je pense judicieux de créer une table de relation entre Article et Fournisseur qui va renseigner les informations spécifique à chaque fournisseur (prix, ReférenceFournisseur, etc...)
C'est mon avis, il y a peut-être mieux...

Bon Dév
Miembro registrado
4.362 mensajes
Publicado el 13,abril 2020 - 16:12
J'ai 3 remarques (en fait 2 car on rencontre 2 fois le même problème)
-Tu dis qu'un fournisseur fournit plusieurs article et qu'un article peut être acheté chez plusieurs fournisseurs. Cela n’apparaît pas dans ton MLD, il faut une table de relation entre Article et Fournisseur
-En ce qui concerne les Famille/Sous famille, il est préférable d'utiliser une relation réflexive. Cela a en plus l'avantage de pouvoir décliner les sous-familles à l'infini. e.g. Fixation : Rivet, vis, clou etc. Clou : Clous à bois, clou à béton etc.
-Il en va de même pour les articles. L'article est (ou pas) composé d'articles.
Enfin, les consommables, le consommable est un type d'article. Il y a 2 écoles pour détailler cela, la plupart du temps en fonction des attributs "non communs".
Si ce nombre est important, on utilise l'héritage, sinon, on ajoute un attribut "type". En fonction de la valeur de cet attribut, les traitements seront différents.

--
Il y a peut être plus simple, mais, ça tourne
Miembro registrado
371 mensajes
Publicado el 13,abril 2020 - 16:40
Merci de tes réponses.
Donc il faut une table article_fournisseur qui lie idfournisseur et id article.

Dans un devis je vais inserer l id article fournisseur ds mon fichier ligne_devis. L article du fichier article ne va pas me servir dans ce cas la !?


Liaison reflexive : je souhaite me limiter a famille sous famille et des caracteristiques pour les consommable ( diam longueur matiere). Est elle bien necessaire pour le coup ?
Miembro registrado
371 mensajes
Publicado el 13,abril 2020 - 16:42
Qu entends tu par attribut ?
Miembro registrado
4.362 mensajes
Publicado el 13,abril 2020 - 17:42
GB a écrit :
Liaison reflexive : je souhaite me limiter a famille sous famille et des caracteristiques pour les consommable ( diam longueur matiere). Est elle bien necessaire pour le coup ?

-1 C'est nettement plus "propre"
-2 C'est plus facile à utiliser
-3 Cela correspond à ta priorité : ne pas avoirs à chercher dans plusieurs tables. cf 1
Qu entends tu par attribut ?

Un attribut, dans le langage "conceptuel", c'est ce que l'on appelle une colonne dans le langage MLD, ce que Windev appelle une rubrique

--
Il y a peut être plus simple, mais, ça tourne
Miembro registrado
371 mensajes
Publicado el 13,abril 2020 - 23:40
Je vois. Je vais modifier mon analyse sur ces deux points
Miembro registrado
371 mensajes
Publicado el 14,abril 2020 - 21:01
Bonsoir

Concernant les fichiers article et article_fournisseur, as tu ou quelqu un a t il une idée sur la façon de gerer l ajout de donnée dans ces deux fichiers ?

Une fiche produit pour ajouter les données communes et une table pour ajouter chaque article_fournisseur et ses données individuelles ?
Miembro registrado
4.362 mensajes
Publicado el 14,abril 2020 - 22:23
Ou le contraire :
On a le "catalogue fournisseur" i.e. la liste des produit d'un fournisseur, et on peut avoir les fournisseurs d'un article avec entre autre les tarifs, ça dépend de ce que l'on veut en faire.

--
Il y a peut être plus simple, mais, ça tourne
Miembro registrado
371 mensajes
Publicado el 16,abril 2020 - 20:52
Bonsoir,

J'ai avancé dans la réflexion de la conception de la gestions des produits. Toute la difficulté réside dans le fait que les différents articles ne seront pas forcement utilisés de la même manière, néanmoins il faut arriver a les faire rentrer dans la structure des différents fichiers.

J'en arrive à cette idée au travers d'exemple :
un fichier article générique (lien entre le famille et article)
un fichier article fournisseur (lien entre article générique et fournisseur)


on peut avoir par exemple :

Pour un produit
Fichier famille : Famille fermeture (type P) > sous famille volet roulant (parent = fermeture)
Fichier article_générique : volet roulant électrique
Fichier article_fournisseur : volet roulant électrique chez fournisseur 1, volet roulant électrique chez fournisseur 2

Pour un consommable
Fichier famille : famille visserie (type CONS) > sous famille vis bois (parent = visserie) > éventuellement sous famille = au type de tête (ronde, fraisée, ... ????)
Fichier article_générique : vis bois 5x60
Fichier article_fournisseur : vis bois 5x60 fournisseur 1, vis bois 5x60 fournisseur 2

Pour un profil ou tôle
Fichier famille : famille tôle (type PROF) > sous famille tôle aluminium > sous famille tôle aluminium laquée
Fichier article_générique : tôle aluminium 15/10eme RAL 9016
Fichier article_fournisseur : tôle aluminium 15/10eme RAL 9016 fournisseur 1, tôle aluminium 15/10eme RAL 9016 fournisseur 2

Est ce que la structure est adaptée ou adaptable ?

La difficulté :
- bien identifier ce qu'est une famille, une sous famille niv 1... niv X d'un produit générique.
- comment différencier ce qui peut être une sous famille de ce qui peut être une caractéristique ?

Qu'en pensez vous ?
Miembro registrado
291 mensajes
Publicado el 17,abril 2020 - 09:25
De mon côté

Je classe un article en Famille et Sous-famille puis en Catégorie et Sous-Catégorie
Dans Catégorie et Sous-Catégorie, se trouvent les dimensions de l'article

Bien cordialement
Miembro registrado
371 mensajes
Publicado el 17,abril 2020 - 20:56
J'ai modifié ma base pour avoir les 3 fichiers nécessaires (fournisseur, article, article_fournisseur).

Reste a faire les fenetres et tester avec quelques exemples. C'est a priori moins intuitif que mes premières idées, mais ça doit surement etre plus efficace dans la globalité d'utilisation.


@Gemin1961 : peux tu détailler comment tu utilise catégorie et sous catégorie (la structure ?) les liaisons ?
Miembro registrado
4.362 mensajes
Publicado el 18,abril 2020 - 14:38
A peu de chose près ton MLD devrait ressembler à ça : https://mega.nz/file/i2IgQSAI… (impossible d'uploader l'image.)
Il y a un chaînage avant et un chaînage arrière au niveau de Catégorie, mais le chaînage arrière devrait suffire.
Une catégorie est telle que FK_CatégoriePrincipale=0 (ou NULL selon la valeur par défaut), une sous-catégorie telle que FK_SousCatégorie=0.
Le cas FK_CatégoriePrincipale=0 et FK_SousCatégorie=0 correspond à une catégorie principale dans la mesure où l'on a une cardinalité 1-1 au niveau de la sous-catégorie (ie une sous catégorie nécessite 1 catégorie principale et 1 seule)

--
Il y a peut être plus simple, mais, ça tourne
Miembro registrado
371 mensajes
Publicado el 18,abril 2020 - 17:57
j'ai bien cette architecture. Toutefois dans ton exemple les catégorie/sous catégorie sont équivalentes a mes famille/sous famille.

Gemin1961 a l'air d'avoir des famille/sous famille et des catégorie/sous catégorie. je voudrais avoir un exemple concret pour comprendre le sens et l utilisation de cette architecture
Miembro registrado
4.362 mensajes
Publicado el 19,abril 2020 - 10:28
J'ai l'impression qu'il utilise l'architecture suivante :
Famille : Fixation/Sous-famille vis, clou, rivet
Catégorie clou à bois, clou à béton/Sous-catégorie dimensions de chaque clou

--
Il y a peut être plus simple, mais, ça tourne
Miembro registrado
371 mensajes
Publicado el 19,abril 2020 - 13:10
Possible;


Je m'oriente vers une architecture (ensemble caractéristique, caractéristique, valeur caractéristique ) afin de gérer les différentes dimensions ou autre des consommables (ex : diamètre, longueur, tête, empreinte, volume, couleur...)
Je pense suivre l'architecture de l'exemple WD gestion commercial...

Qu'en penses tu ?
Miembro registrado
371 mensajes
Publicado el 24,abril 2020 - 13:01
Bonjour,

Je poursuis la finalisation de l'analyse

Dans l'exemple WD gestion commerciale, les ensemble sont rattachés au produit (article dans mon analyse) et les caractéristiques au déclinaison_produit (article_fournisseur dans mon analyse).
Je ne comprends pas la finalité d'une telle liaison ? Pourriez vous m'éclairer ?

Pour rappel, je souhaite pouvoir remonter les stock au niveau des articles en faisant le total du stock des articles_fournisseur



Miembro registrado
371 mensajes
Publicado el 25,abril 2020 - 21:08
Up
Miembro registrado
371 mensajes
Publicado el 01,mayo 2020 - 10:07
Bonjour

Personne n a d d'idée ?