Discussion :

[riad2108]

Bonjour à tous
J'ai développé une application de gestion d'une supérette sous WD17 et HFSQL.
J'ai un fichier contenant des infos sur le produit : désignation, code barre, prix ..... Donc chaque produit a une désignation et un code barre unique. Jusque la tout va bien.
Mon problème: pour le produit (Jus ramy 1.5 L) par exemple , il existe plusieurs gout (fraise, pomme, pèche .....) et chaque gout a son propre code barre.
Je pensais à intégrer plusieurs code barre pour le même produit mais j'ai peur de la dégradation des performances (surtout avec 10.000 et plus)
Ma demande : Si quelqu'un a déjà eu à faire à ce problème je serai très reconnaissant de m'orienter

MERCI

[tatayo]

Bonjour,
C'est marrant, on a eut la même problématique dans mon ancienne boite... il y a 15 ans !
La solution est la suivante: il ne faut pas mettre les codes barre dans le fichier article, mais dans un autre fichier.
Ici il est tout simple: Id de produit et code barre.
Avec un index qui va bien (code barre + id produit), la recherche sera rapide, surtout avec seulement 10000 code barre.

Mais l'exemple que tu donnes n'est pas bon: des goûts différents => des produits différents. Sinon tu ne peux pas savoir lequel est passé en caisse.

Tatayo.

[serendib]

Bonsoir,
Le problème ne doit surtout pas se poser ainsi.
Le principe du code barre étant justement d'être unique.
Donc un produit=un code barre.
(Pour le vin, par exemple, on peut au maximum en avoir 2 : Code barre bouteille et code barre carton)

Lorsque la caissière scanne un code barre, la fraise c'est la fraise, la framboise c'est la framboise.

Peu importe le nombre de produits dans la base de données, meme s'il y en a des milliers,
c'est ainsi qu'il faut raisonner.

[tatayo]

Donc un produit=un code barre.

Non, c'est justement l'inverse: un code barre => un produit, puisqu'un produit peut avoir plusieurs code barres.

Tatayo.

[riad2108]

Merci pour vos réactions
J'avais pensé à la solution de "tatayo" celle de créer un fichier (id_produit+code_barre) mais cela m'obligeais à faire un double parcours :
Lorsqu'on scanne le code barre on lance une recherche sur le premier fichier, une fois le id_produit récupéré on lance une deuxième recherche sur le fichier produits pour obtenir les infos du produit trouvé (prix_achat, prix_vente, stock ......)
d'autre part la solution de "serendib" pose un autre problème :
Si on suppose que pour chaque gout on crée un produit séparé , cela veut dire que lors de l'achat on doit introduire chaque gout tout seul avec sa quantité correspondante et je pense que c un peu lourd si on a 14 gout pour le même produit.

[DelphiManiac]

...Si on suppose que pour chaque gout on crée un produit séparé , cela veut dire que lors de l'achat on doit introduire chaque gout tout seul avec sa quantité correspondante et je pense que c un peu lourd si on a 14 gout pour le même produit.

Quand tu vas commander, tu vas bien préciser à ton fournisseur si tu veux de la fraise ou de la pomme, et toujours quand tu vas devoir commander, il faudra bien que tu saches ce que tu as en stock par parfum ? Il faut donc que tu identifies, d'une manière ou d'une autre, tout les parfums.

Globalement, il a une solution intermédiaire, c'est la gestion des gammes. En gros tu as un produit générique qui regroupe tout les produits de même type : "Jus en 1.5L de telle marque" et tu as une sous-fiche qui identifie le parfum, le code barre de ce parfum, le stock de ce parfum, tout ce qui est spécifique à ce parfum. Accessoirement pour les stocks, il faudrait même que tu gères les entrées/sorties par numéro de lot avec le numéro de lot et la date de péremption de chaque lot.

Cette solution te permets d'avoir des états de stock comptables synthétique (le stock comptable ne s’intéresse qu'a la valorisation de ton stock) : pour le produit "Jus en 1.5L de telle marque" tu en as tant en stock, quelque soit le parfum, par contre pour la gestion de stock en prévision des achats tu sais précisément ce qu'il faut que tu commandes.

[tatayo]

Merci pour vos réactions
J'avais pensé à la solution de "tatayo" celle de créer un fichier (id_produit+code_barre) mais cela m'obligeais à faire un double parcours :
Lorsqu'on scanne le code barre on lance une recherche sur le premier fichier, une fois le id_produit récupéré on lance une deuxième recherche sur le fichier produits pour obtenir les infos du produit trouvé (prix_achat, prix_vente, stock ......)
d'autre part la solution de "serendib" pose un autre problème :
Si on suppose que pour chaque gout on crée un produit séparé , cela veut dire que lors de l'achat on doit introduire chaque gout tout seul avec sa quantité correspondante et je pense que c un peu lourd si on a 14 gout pour le même produit.

Non, il suffit de faire une requête avec une jointure entre les deux fichiers:

Code sql :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
select produit.*
from produit
inner join code_barre on code_barre.idproduit = produit.idproduit
where code_barre.cb_c_valeur = 'XXX'

Bref rien d'insurmontable, surtout avec seulement 10000 codes barres.

Tatayo.

[serendib]

riad2108

Je développe depuis plus de vingt ans un logiciel de gestion commerciale basé sur l'EAN13.
J'ai de très nombreux Clients dont une enseigne GD très connue en France.
Tu feras comme tu l'entends mais je peux te garantir qu' un produit (unité consommateur) ne peut avoir qu'un gencod.
Il t'est par contre possible dans la fiche article de réserver 3 rubriques Gencod :
- L'EAN13 de base (Unité)
- L'EAN13 Carton (même produit vendu par 12 par exemple)
- L'EAN13 Palette (même produit au moment de l'expédition et de la réception, donc non utilisé en caisse)
mais l'EAN13 de base (unitaire) DOIT être UNIQUE.
et au moment de la création de l'article dans ton appli tu dois vérifier que ce gencod n'a pas déjà été utilisé par autre produit.
(doublons interdits)

Je te conseille donc fortement d'avoir autant de produits que de Gencods unitaires différents.
Je te rappelle que le principe du Gencod est d'uniformiser et de standardiser l'échange d'infos
entre fabricants, centrales d'achats, négociants et distributeurs.
Ainsi, un jus de fruits 1.5L framboise, en termes EAN13, n'a rien à voir avec une jus de fruits 1.5L fraise
ni même avec un jus de fruits 0.5.L framboise.
Le problème se corse avec les produits à poids variable.
Certaines enseignes changent même de gencod sur les promos !
Et penses au textile, où là il ne s'agit plus de parfums mais de coloris multipliés chacun par des tailles !!!
Si à la caisse il faut attendre que le logiciel cherche le bon Gencod...
De toute façon, il te faut gérer le stock et les PA/PV de chaque produit, donc...

Donc, un dernier conseil : un gencod unitaire=1 produit ou 1 produit=1 gencod unitaire ( ce qui revient au même)
Peu importe le nombre de produits, ce ne doit pas être ton critère de choix.
Avec les bécanes d'aujourd'hui, même 100 000 produits, ça ne pose plus vraiment de problème.
C'est souvent le cas dans hypermarchés, alors ta supérette...
Et de toute façon, crois-moi, tu n'as pas vraiment le choix.

Maintenant tu peux suivre tous les conseils que tu veux...

[R&B]

De l'intérêt du MCD pour comprendre les relations entre les informations du dictionnaire des données...
Ainsi que des bases dans ce métier que représente la codification normalisée des articles depuis 40 ans !

bon courage !

[tatayo]

Je suis d'accord sur tout, sauf ceci:

Tu feras comme tu l'entends mais je peux te garantir qu' un produit (unité consommateur) ne peut avoir qu'un gencod.

Pour avoir bossé chez l'éditeur d'un ERP (et de son logiciel d'encaissement), et maintenant chez un "client final" de l'ERP en question, je peux te garantir le contraire.
J'ai par exemple souvent le cas de fournisseurs qui changent le code barre d'un produit d'une saison à l'autre. Avec un seul code barre par article, c'est cuit...

On a actuellement un peu moins de 300000 codes barres dans notre base, et pour des raison de praticité sur la caisse on "ajoute" en code barre la référence de l'article, la ref fournisseur... bref sur la caisse on doit avoir une moyenne de 5 codes barres par article, soit plus d'un millions de code barre renseignés.
Et ça ne pose absolument aucun problème de recherche. Il suffit d'un index sur le code barre.

Tatayo.

[R&B]

Hmmm, le débat est un problème de point de vue.
un article fournisseur/fabriquant n'a bien qu'un seul gencode....
Mais coté magasin, c'est le contraire. Heureusement qu'il va devoir gérer plusieurs gencode pour un seul article.

Je vous renvoie à la bouteille d'une boisson gazéifiée célèbre à la robe ondulée et rouge (effet TDF 2014 encore visible).
Le magasin n'a cure de savoir quel a été son fabriquant... il vends bien toujours la même bouteille. En caisse il va donc biper tout ces codes pour pointer le même article. Mais là on est en train de faire le travail de notre jeune ami qui plus est dans le mauvais forum.

[serendib]

Je suis d'accord sur tout, sauf ceci:

Pour avoir bossé chez l'éditeur d'un ERP (et de son logiciel d'encaissement), et maintenant chez un "client final" de l'ERP en question, je peux te garantir le contraire.
J'ai par exemple souvent le cas de fournisseurs qui changent le code barre d'un produit d'une saison à l'autre. Avec un seul code barre par article, c'est cuit...

Tatayo.

C'est vrai, Tatayo, mais selon le principe même de l'EAN13, si le fournisseur change son code, il faut créer un nouvel article conforme à la spécification de ce fournisseur au moment de l'achat si l'on veut respecter ce principe.
Bien sûr on peut passer outre, mais ce n'est pas très orthodoxe.
Et que dire alors des problèmes de traçabilité très à la mode à notre époque ?

Comme je l'ai dit plus haut il fera comme il veut, mais personnellement avec les gencods, je tiens à rester strictement dans les clous.
D'ailleurs mes Clients l'exigent.
Pour moi, si norme il y a, il faut s'y conformer, mais ça n'engage que moi.
Si le gencod ne servait qu'à passer rapidement des articles en caisse, il suffirait à chacun de créer son propre EAN13 bidon.
Mais l'EAN13, c'est bein plus que celà.

D'autant qu'à part la multiplication des produits, ça ne pose pas de problèmes majeurs.

Encore une fois chacun fait comme il l'entends.
Comme dit R&B "Le magasin n'a cure de savoir quel a été son fabriquant", mais alors à quoi bon normaliser ?
On est plus du tout dans l'esprit EAN13.

[serendib]

Hmmm, le débat est un problème de point de vue.
Mais là on est en train de faire le travail de notre jeune ami qui plus est dans le mauvais forum.

Bien sûr !
C'est tout sauf un problème lié à windev, ni même à la programmation.
On veut être strict, ou permissif.
Point final.
Mais il voulait un conseil, il en a 3.

[R&B]

Serendib, je comprends ton orthodoxie sur le sujet et le rappel à la loi (norme).
Je pense même que tu es fondamentalement dans le vrai.

Sauf erreur c'est le fabriquant qui fixe le gencode qui n'est pas forcément (et même très rarement) le fournisseur de la supérette. C'est donc là notre divergence d'usage.

Cela va devenir plus drôle quand la supérette recevra une palette de bouteilles de la boisson citée précédemment depuis sa centrale d'achat comportant des packs de 6 fabriqués dans des usines différentes et livrés à des moments différents à l'entrepôt (d'où la palette différenciée).
Notre gestionnaire va devoir biper la réception chaque pack et non pas la palette pour alimenter le stock de chaque fiche associée à un seul gencode. Il mettra aussi les prix à jour de toutes les fiches concernées etc...
Dans le cas des jus, effectivement ce sont des articles différents par parfum car il peut avoir besoin d'ajuster son stock en conséquence de ses vente... mais pour un même parfum, qu'il doive gérer par gencode nous renvoie au problème ci-dessus.

D'où un renvois à l'analyse de son besoin qui ne gère pas toute la chaine de distribution mais le dernier maillon de commercialisation.

Mais il voulait un conseil, il en a 3.

Désolé si chaque question de cet espace doit être gérée par le premier qui répond.
C'est noté.

[serendib]

R&B,
Ne sois pas désolé, je me suis peut-être mal exprimé.
Je voulais dire : il a demandé conseil, il a 3 avis, donc 3 orientations possibles.
A lui de faire le tri dans ce qui a été dit.
Je ne prétends pas détenir la vérité, je donne simplement la démarche orthodoxe.
Mais bien sûr, comme tu le dis fort justement et plus élégamment, on peut se la carrer où l'on veut

[alassanediakite]

Salut
Je pense qu'il faut raisonner en terme de finalité (utilisation) du code barre.

Hmmm, le débat est un problème de point de vue.

Le code barre est là pour accélérer l'accès à un produit? comme ...

Lorsque la caissière scanne un code barre, la fraise c'est la fraise, la framboise c'est la framboise.

alors un code barre personnalisé suffit.
Le code barre est utilisé pour ...

Je te rappelle que le principe du Gencod est d'uniformiser et de standardiser l'échange d'infos
entre fabricants, centrales d'achats, négociants et distributeurs.

alors un code barre normalisé est obligatoire. Mais cela doit résoudre le premier problème (je suis parfaitement d'accord avec un code barre=un produit).

...dans le mauvais forum.

Si un modérateur peut le déplacer dans le forum de conception nous pourrions peut être bénéficier l'avis du débutant fsmrel.
@+
PS: R&B, vos prof de français ont dû vous prendre en référence plus d'une fois (assez clair, simple et beau)

[riad2108]

Bonsoir et merci pour vos réponses
finalement j'ai opté pour la solution de "Tatayo" en créant un fichier "CODE-BARRE" avec comme rubriques "id" "id_produit" et "code-barre".
Donc chaque produit peut avoir plusieurs codes barres que se soit par parfum, fournisseur ou fabrique .
A mon avis cela facilite l’intégration des produits lors de l'achat mais aussi lors de l'inventaire.
Merci encore pour vos réactions
je marque comme résolu