Plusieurs Codes-barres par réf, et autre que EAN ?

Bonjour à tous, je me permets de lancer un petit lot de questions sur les codes-barres, dans doliBARR :

-Comment gérer plusieurs codes-barres pour une même référence ?
(certains fournisseurs changent le C.B. en cours de vie du produit et parfois 1 produit « équivalent » est commandé chez 2 fournisseurs différents (à un prix parfois différent, mais a les mêmes propriétés… 250ml d’alcool 70% modifié, par exemple…)

-Y-a-t’il possibilité de scanner des codes barres à 13 caractères classiques, mais aussi d’autres types de codes-barres (j’ai un fabricant qui inclut après les 13 chiffres, le N° de lot et la date de péremption !) est-ce que la douchette va le prendre (oui, je pense) mais est ce que la « case » sera bien remplie (assez de place dans le champ de la BDD ?)

- il n’y pas de module « code-barre » éditable qui ferait la liste des produits avec leurs différents codes-barres (si on peut en mettre plusieurs) ?
Bien sûr c’est aussi possible d’activer les C.B. et d’exporter llx_product de phpmyadmin et de renseigner tous les codes barres sur excel avec en fin de scan sur la douchette un retour chariot, pour aller vite et le réinjecter « à la barbare » SI un produit = code barre unique et toujours le même type de code barre.

-J’ai beaucoup de fabricants qui ont 2 voire 3 codes-barre :
1 code barre EAN 13 ou autre
1 code barre lot et date de péremption (super utile pour pas se taper les petits caratères, éviter le doute et remplir ça difficilement pendant la réception des produits…
1 code barre pour la position dans le stock (ou autre, je sais pas trop quoi)

Si je veux me servir des codes barres déjà présents sur les produits, dur dur, je dois anticiper quel sera le comportement de Dolibarr avec ces codes… donc je me permet de vous demander un retour d’expérience pour ceux qui gèrent leurs commandes/stocks/expé/récep… avec un lecteur de code-barres… y’a t-il du monde ???

Normalement, un produit = 1 code barre puisque celui ci est créé par le fabricant. Donc que le produit vient de DUPOND ou DURAND normalement ça ne change rien ou alors ce ne sont pas les mêmes produits/fabricants.

Les douchettes CB ne prennent que les CB standards. Du moins pour celles que j’ai installé, C39 ou EAN128 je crois mais il y en a d’autres. Le n° de lot risque comme la date de changer à chaque livraison donc à exclure. Le CB avec lot et date fait plutôt partie d’un stock et non d’une référence produit d’un catalogue. Le module équipement ne serait il pas adapté à vos besoins pour suivre tout ça.

Le CB peut être utilisé pour toute saisie dans Dolibarr, c’est ni plus ni moins qu’un clavier.

Bonjour Phil et merci de tes réponses,

Je veux savoir jusqu’où on pourrait aller avec le module code barres natif…

Dans l’idéal (ce que j’ai vu dans d’autres entreprises ou sites e-commerce assez pointus, mais très productifs…)

-Etendre le module codes barres (qui n’est que sur les produits et clients) aux commandes fournisseurs/clients et expé/receptions.

-Je bippe le code barre de ma commande fournisseur (validée, imprimée et accrochée au tableau des « commandes en attente de récpetion » dans mon stock)
= ouverture de la fiche réception
-Je bippe les produits qui sont dans le carton où les codes barres seront préalablement renseignés et existants (5 produits A et 3 produits :sunglasses:
-Je ventile et ferme la commande fournisseur à l’aide de la souris ou à l’aide d’un code barre au bas de ma commande fournisseur, si elle est complète je ferme à reception totale,
sinon je ferme à reception partielle à l’aide d’un autre code barre (codes barres spéciaux qui déclencheraient des actions, à voir si faisable…)

Pareil pour les commandes clients, je bippe le code barre de la commande client (validée et imprimée sur le tableau de mon stock « commandes clients validées »)
et cela m’ouvre la fiche expédition de la commande, je bippe les produits que j’ai vaillemment collectés dans mon stock… etc… etc… etc… :wink:

J’ai un ERP totalement intégré à Magento qui fait ça magnifiquement bien, malhereusement il rame trop, buggue à mort à cause de nouvelles extensions, ne me permet pas de piloter aussi finement ma gestion que Dolibar… et m’a coûté un bras !

Pour les différents codes-barres, oui c’est plutôt rare, mais parfois j’ai une réf du style « COTB » Boules de coton, que je commande chez A ou chez B et donc COTB de chez A n’a pas le même code barre que COTB de chez B (ni le même prix, ni le même fk_product_fournisseur d’ailleurs :wink: )
et même si je commande toujours chez mon fournisseur C des produits avec un code barre extra-long avec le n° d elot et la date de peremption dessus, ce code barre n’est pas toujours le même… exemple ?

Pour le module produits et numéros de série, j’étais vachement enthousiaste sur l’intitulé du topic et le CdC de base : « Produits et numéros de série »…
Mais en fait un équipement est un produit de consommation avec un cycle de vie plutôt moyen/long avec pleins d’états qui en découlent, d’où le recours aux évènements, etc…
Mais un consommable, que je réceptionne et expédie 20 fois par mois en grosses quantités, n’a pas lieu d’avoir des évènements liés.
Honnêtement j’ai vraiment la flemme de créer un équipement lié au produit :wink: alors que 2 codes-barres et/ou 3 ou 4 champs supplémentaires liés aux mouvements de stock et fk_product_fournisseur suffiraient…

Je m’auto-réponds que cette fonctionnalité commence à faire défaut gravement à une entreprise dans le médical, gérant obligatoirement N° de série / de lot et Dates de péremption (je pense que pour l’alimentaire c’est la même chose…)

Bref… je serai bientôt exclu de chez certains client qui passent des normes NF et qui exigent ces 2 champs sur les BL. Pour l’instant je vais le mettre à la main, puis, on va essayer de développer un peu le module commande_fournisseur_dispatch pour y implémenter N° Lot et date de péremption.

Je vais créer un sujet nommé commande_fournisseur_dispatch :wink:

@ + !

Faites des essais avec le module équipements, rien ne vous oblige à enregistrer des évènements. la traçabilité peut être traitée là je pense.

Merci de votre réponse,

Oui, pour chaque petit produit de mes lots je peux gérer la traçabilité, unitairement… Mais c’est trop fin, je dois créer un n° de série comme un lot pour plusieurs dizaines ou centaines de produits !

Mais si mon lot fait 513 références, je dois créer 513 équipements dans l’état actuel des choses.

et si mon client en commande 226, je dois joindre 226 équipements.

Je ne peux pas non plus creer un N) de série pour chaque « lot » homogène car plusieurs lots peuvent de retrouver chez plusieurs clients et je dois savoir combien de produits de chaque lot (et pas simplement lot X est chez tel client, je dois savoir tel qté de produits du lot X est chez tel client.)

J’espère que c’est + clair et que ça peut vous avancer (ainsi que Defrance dans vos réflexions sur le développement du module).

Bien à vous,
Hubert

Bonjour à vous,

J’ai attentivement lu votre topic et souhaiterais vous faire part de quelques réflexions.

Depuis maintenant quelques mois je tente de trouver une solution pour gérer les produits de notre catalogue avec leurs codes-barres afin de limiter les erreurs et surtout augmenter notre efficacité. Ici mon problème ne touche pas la BBD car tous les codes-barres des produits sont existants. De plus la notion de lot ou de péremption ne nous touche pas car nous vendons des produits électriques.

Nos problèmes se trouvent aux niveaux ci-dessous :

Le conditionnement du produit car celui-ci est composé de 3 niveaux :

  • Niveau 1 (unitaire) : 1 pièce composée du code-barres EAN13 qui est déjà renseigné dans Dolibarr

  • Niveau 2 (medium) : 3,10 ou 12 pièces en fonction des types de produit avec un code-barres EAN14 sur le package.

  • Niveau 3 (large) : 30 pièces et plus en fonction des types de produit avec un autre code-barres EAN14 sur le package.

Notre problème est que Dolibarr ne gère pas ces niveaux de packaging et par conséquent ne comprend pas que lorsqu’un code-barres EAN14 est scanné qu’il faut compter 10 fois la pièce (par exemple).

Par ailleurs, Dolibarr n’est pas adapté pour la reconnaissance « active » d’une commande fournisseur ou client. Ce que nous souhaitons c’est qu’une fois sur la fiche de commande, de pouvoir scanner dans le désordre tous les produits de la commande fournisseur ou client et qu’ainsi Dolibarr attribut ces données aux lignes de la commande. Ensuite on valide et cela incrémente les stocks pour la commande fournisseur ou alors on expédie si c’est une commande client. Le processus est le même que celui décrit par Hubz plus haut.

Aujourd’hui, je ne sais pas s’il vaut mieux tenter d’intégrer ces fonctionnalités à Dolibarr ou bien réaliser une passerelle avec un WMS.

En espérant que quelqu’un pourra faire avancer ma réflexion voir peut-être même nous proposer une solution !

Bonne journée à tous

Bonjour Devred !

Je suis rassuré que quelqu’un cherche les mêmes fonctionnalités…
En plus, la fonctionnalité que vous décrivez pour les codes barres des cartons me fait également défaut… Il faudrait ajouter une notion de « packaging achat » sur la fiche produit fournisseur ou dans les « prix fournisseurs » du produit (là où on demande la qté mini par prix, par exemple ?) avec proposition de scan du code barre « global » pour le renseigner au moment des réceptions/expéditions.

>>> Certains vont vous donner la solution : Créez un produit « à composer » et passez par le module « composition (ou production) » pour « produire » à partir des gros produits (ou cartons), un sous-ensemble de produits unitaires.
Soit un produit : AMPOULE CARTON MINI (code barre EAN14) = 3 AMPOULES (code barre EAN13)
donc si vous avez 3 CARTON MINI d’AMPOULES, vous « produisez » ou vous pouvez produire 9 AMPOULES.
J’espère que c’est clair, mais ce n’est pas testé, ça ne résoud en rien le problème et ça rajoute au moins 3 étapes chronophages à la réception du produit !<<<

Mis à part la notion de « lot » ou « péremption » (que j’écris toujours à la main sur le BL de mes clients en cherchant sur le conditionnement du produit…), les fonctionnalités décrites ne sont étonnement pas beaucoup traitées sur le forum, roadmap, Doliforge ou autre…

Il faudrait un super-développer (comme Eldy, Phil, Defrance, FHenry, et tous ceux qui commit sur le github…) pour créer un module basique (sur github?) à tester par nous, car le CDC est déjà bien détaillé dans ce sujet… non ?

Merci de votre intérêt et j’espère qu’on trouvera de la suite dans nos idées, car notre efficacité, compétitivité et santé en dépendent !

Hubert

Bonjour HubZ !

Je suis moi aussi content de savoir que certaines sociétés utilisant Dolibarr ont besoin d’implémenter ces fonctionnalités.

Aujourd’hui j’ai envisagé trois pistes pour tenter de gérer avec efficacité nos réceptions/expéditions :

1ère : Mettre à disposition un iPad pour le magasinier sur lequel il peut accéder à l’ERP avec une connexion wifi. C’est loin d’être la méthode la plus efficace mais c’est actuellement la solution que nous utilisons.

2ème : Développer une interface sur un écran de 5 pouces (par exemple un iPod touch) équipé d’un lecteur de codes-barres. Pour cette option j’ai déjà un devis basé sur un cahier des charges détaillé que nous avions réalisé. Cependant le prix total (réception et expédition des commandes) s’élevait à 13 000.00€ par conséquent je n’ai pas donné suite à cette option.

3ème : Mettre en place une passerelle avec un Warehouse Management Systems. Cette solution est actuellement celle qui me semble la meilleure et la plus rationnelle. En effet, faire développer Dolibarr nécessiterait de modifier tout un pan de l’interface pour la gestion des expéditions et des réceptions. Pas mal de fonctionnalités sont manquantes (voir le listing ci-dessous, non exhaustif) ce qui induirait des développements lourds. Pour finir, nous ne connaissons pas encore l’ensemble de nos besoins vis-à-vis du traitement du stock et de ce fait un WMS nous permettrait d’anticiper ces futures exigences.

  • Gestion des codes-barres EAN14 et des différents packagings

  • Indication de position du produit dans le stock (allée, rayon, casier…)

  • La possibilité de scanner tous les produits d’une commande dans le désordre sans devoir placer le curseur sur chacun des champs respectifs.

  • Créer une interface adaptée au terminal mobile sur lequel l’opérateur travaillera.

De plus, ce que nous souhaitons, ce n’est pas une simple douchette. Nous voulons que l’opérateur puisse voir la commande sur son terminal et en même temps scanner les produits. Il pourra ainsi connaître le stock, l’emplacement du produit, faire un inventaire sur une partie du stock durant son temps libre… Le terminal n’est pas encore sélectionné mais nous avons déjà trouvé de nombreuses choses intéressantes :

 Version iPod touch
http://www.posguys.com/mobile-barcode-scanner_67/ipdt380-for-ipod_1244/

 Version WMS
http://solutionspme.lemondeinformatique.fr/articles/lire-un-terminal-mobile-sur-le-bras-734.html

En conclusion, l’idée de faire évoluer Dolibarr pour gérer ce type de besoin est alléchant cependant aujourd’hui aucun développeur ne semble vouloir se lancer dans le projet. Par ailleurs, je ne dis pas que l’idée de la liaison avec un WMS est la plus simple mais cela semble être la solution la plus rationnel et complète actuellement.

Ps : A propos de ta solution avec un produit composé, c’est super bien pensé mais c’est aussi une sacré usine à gaz.

Devred

Merci de ton retour, en effet, un WMS paraît intéressant mais je te propose de lire : https://sites.google.com/site/nowaksim/mes-projets-d-ecole/auditdesolutionswmsopensource

C’est une étude complète des WMS open-source assez bien faite, elle montre dans sa conclusion que choisir un WMS c’est aussi demander du développement complémentaire… et un WMS payant coûterait combien ?

A savoir qu’openERP (que j’ai regardé en WMS et ERP…) est déjà une usine à gaz, in-développable et longue à comprendre pour les utilisateurs, souvent néophytes en la matière et qu’au final cela revient plus cher qu’un Dolibarr quasi-complet, prise en main rapide et fiable…

C’est dommage de ne pas avoir de retour de main-développeurs Dolibarr sur le sujet… A bon entendeur… bon weekend !

  • Gestion des codes-barres EAN14 et des différents packagings

> Modif de l’onglet Prix Fournisseurs avec les packagings et codes-barres associés

  • Indication de position du produit dans le stock (allée, rayon, casier…)

> Créer un attribut supplémentaire « Emplacement » sur la page produit et le faire apparaitre sur le pdf de préparation des expéditions (picking list)
+ L’idéal sera de créer une pick-list de toutes les commandes (écran suppl. avec sélection des commandes complètes « to pick » selon l’emplacement pour gagner du temps dans la ramasse, puis de re-dispatcher les produits selon chaque commande, plutôt que de faire des A/R aux mêmes endroits dans le stock pour différentes commandes …

  • La possibilité de scanner tous les produits d’une commande dans le désordre sans devoir placer le curseur sur chacun des champs respectifs.

> Modif de l’écran des expéditions avec un champ supplémentaire, soit par produit, soit un champ code-barre « intelligent » (reconnait le produit scanné selon le code barre enregistré) !

  • Créer une interface adaptée au terminal mobile sur lequel l’opérateur travaillera.

Dolibarr s’affiche bien sur une tablette (Galaxy GT P1000 en 3G ou Wifi) ou un netbook Asus EEEPC en wifi ou clé 3G

De plus, ce que nous souhaitons, ce n’est pas une simple douchette. Nous voulons que l’opérateur puisse voir la commande sur son terminal

> d’où l’intérêt de « rester » sur Dolibarr, et de développer un module ou d’ajouter ces fonctionnalités au Core… il va falloir mobiliser un main-dév et faire du lobbying !

Eh bien dis comme ça je dirais qu’il faut lancer le projet tout de suite !

Je vais tacher de me renseigner sur les différents WMS compatibles mais aussi adaptés à nos types d’activité. De plus, je vais aussi regarder le compte-rendu que tu as posté plus haut afin d’accroître ma connaissance sur le sujet.

Quelques remarques sur les développements que tu suggères :

- Gestion des codes-barres EAN14 et des différents packagings :
> Modif de l’onglet Prix Fournisseurs avec les packagings et codes-barres associés

–> Je pense que l’intégrer ici est une bonne idée. Tu trouveras ci-dessous les infos dont je dispose et que je cherche à intégrer à la BDD de Dolibarr :
Ref produit EAN13 Qte Haut Larg Prof Masse EAN14
A9F77210 3606480094125 1 75 36 95 210
A9F77210 3606480094125 6 80 98 225 1330 13606480094122
A9F77210 3606480094125 66 300 300 400 15070 43606480094123

- Indication de position du produit dans le stock (allée, rayon, casier…)
> Créer un attribut supplémentaire « Emplacement » sur la page produit et le faire apparaitre sur le pdf de préparation des expéditions (picking list)
+ L’idéal sera de créer une pick-list de toutes les commandes (écran suppl. avec sélection des commandes complètes « to pick » selon l’emplacement pour gagner du temps dans la ramasse, puis de re-dispatcher les produits selon chaque commande, plutôt que de faire des A/R aux mêmes endroits dans le stock pour différentes commandes …

–> Oui c’est assurément une très bonne idée car cela augmenterait d’une façon non négligeable le nombre de commandes/heure traitées.

- La possibilité de scanner tous les produits d’une commande dans le désordre sans devoir placer le curseur sur chacun des champs respectifs.
> Modif de l’écran des expéditions avec un champ supplémentaire, soit par produit, soit un champ code-barre « intelligent » (reconnait le produit scanné selon le code barre enregistré) !

–> Cette fonctionnalité est à mon avis la plus importante à intégrer à Dolibarr. Une fois sur la fiche de la commande fournisseur ou client il faut absolument pouvoir scanner tous les produits sans que l’opérateur soit obligé de préciser quel produit il va scanner. Sans cette première fonctionnalité le reste ne servira à rien.

- Créer une interface adaptée au terminal mobile sur lequel l’opérateur travaillera.
Dolibarr s’affiche bien sur une tablette (Galaxy GT P1000 en 3G ou Wifi) ou un netbook Asus EEEPC en wifi ou clé 3G

–> Je crois que le choix du terminal mobile est le premier point sur lequel il faut se pencher. Nous avons tenté d’établir les exigences auxquelles le terminal doit répondre :

- Nous souhaitons que notre opérateur ait les mains libres, du moins le maximum possible. Par exemple, nous recevons souvent les produits de nos fournisseurs par palette composée de colis d’environ 10-15 kilos. Nous pensons que pour une reconnaissance active et efficace des produits packagés, l’opérateur a besoin de ses deux mains.

- La liaison avec Dolibarr se fera en Wi-Fi dans notre entrepôt.

- Le terminal sera évidemment résistant aux chocs.

- Le terminal devra avoir un écran tactile afin que l’opérateur puisse accéder facilement aux informations qui lui sont nécessaires.

- Ce que nous souhaitons, ce n’est pas une simple douchette. Nous voulons que l’opérateur puisse voir la commande sur son terminal mais aussi par exemple faire un inventaire sur une partie du stock durant les creux d’activité de la journée.

- Enfin il faudra que le terminal soit léger, pratique à utiliser et peu encombrant.

Actuellement nous envisageons deux types de terminaux :

- 1- Le premier type de solution que nous souhaitons mettre au point s’inspire directement d’un produit Motorola : http://solutionspme.lemondeinformatique.fr/articles/lire-un-terminal-mobile-sur-le-bras-734.html
Je pense que ce type de solution est réellement l’avenir du flash/picking cependant je pense que pour une TPE comme la notre ce produit est un peu démesuré. Ce niveau d’équipement ne correspond peut être pas vraiment au volume traité mais qui peut le plus peut le moins !
Ce que nous souhaitons, c’est nous inspirer de cette solution : une petite tablette (Archos 5 IT) fixée sur l’avant-bras de l’opérateur équipée d’un lecteur au doigt connecté en USB.

- 2 - Le second type de solution est celui basé sur un iPod touch équipé d’un scanner : solutionspme.lemondeinformatique.fr/arti...sur-le-bras-734.html
Cette solution est aussi très bonne à nos yeux, le seul défaut que nous voyons par rapport à la solution précédente est que l’opérateur perd une main ^^ Toutefois, ce type de terminal semble plus simple à mettre en place.

Voilà à peu près tout ce que nous avons pût observer ces derniers mois sur l’intégration de cette technologie au sein de notre entreprise.

Bon samedi !

Devred

Bonjour à tous,

Comme je l’ai indiqué dans mon précédent post je pense que la première chose sur laquelle nous devons nous intéresser c’est de savoir sur quel type de terminal nous voulons travailler. Pour le cas de notre société nous avons envisagé les possibilités suivantes :

  • Numéro 1 (le plus abordable) : Equiper un PC d’une douchette portable et amener les produits jusqu’à lui. Dans le cadre de la réception de nos commandes cette solution est envisageable car nos réceptions se font globalement toujours à l’entrée de l’entrepôt. Toutefois, dans le cadre de la préparation des commandes clients nous aurons très peu d’intérêt à utiliser ce type de solution car cela impliquerait d’aller chercher les produits dans les rayons, les ramener vers le PC puis les scanner.

Prix du lecteur : de 100.00€ HT à 250.00€ HT.

  • Numéro 2 (l’intermédiaire) Equiper un Smartphone (Samsung S Wifi 5) d’un lecteur de code-barres de type KDC 400. La solution est assez novatrice tout en restant accessible pour les PME. De plus, l’opérateur peut aisément préparer une commande client voir même plusieurs en en même temps.

Prix: Samsung S Wifi 5 (150.00€ HT) + Lecteur KDC 400 (354.00€ HT) = 504.00€ HT
Lien utile : http://www.mobilscan.fr/KDC400.html

  • Numéro 3 (le plus évolué) : Comme je l’ai exprimé plus haut nous sommes tentés par le produit Motorola WT4090 équipé d’un lecteur de code-barres au doigt. Cette solution comporte de nombreux avantages (avoir les 2 mains libres par exemple) cependant son prix est trop important pour notre volume d’utilisation. Nous avons par conséquent tenté de trouver une solution alternative gardant les mêmes avantages que le produit de Motorola. La solution trouvée est d’associer un KDC 200 équipé de son gant avec un Smartphone positionné sur l’avant-bras. L’opérateur a ainsi ses deux mains libres, garde une ergonomie totale avec l’écran tactile du Smartphone et peut accéder aux différentes informations sur la commande en toute simplicité.

Prix : Samsung S Wifi 5 (150.00€ HT) + Lecteur KDC 200 / iOS (353.00€ HT) + gant avec bouton sur l’index (81.00€ HT) = 584.00€ HT
Lien utile: - KDC glove : http://www.mobilscan.fr/Glove.html
KDC 200 : http://www.mobilscan.fr/KDC200.html

Voilà l’étendue de mes recherches quant aux différents terminaux du marché. Evidement ce n’est pas exhaustif mais cela donne déjà une idée de ce qui est possible de faire.

A partir de maintenant, la question qui se pose est comment intégrer les développements précédemment exprimés dans un Smartphone ? Faut-il créer des écrans spécifiques à Dolibarr ou bien voir grand tout de suite en créant une application ?

Si des développeurs souhaitent se pencher sur la question, nous attendons leurs avec impatience. Nous nous devons d’investir dans cette technologie avant que le volume de commandes traitées ne nous pose un problème et que nous nous fassions dépasser.
Bonne journée à tous.

Ps : Je n’ai aucune action chez KDC, j’ai simplement trouvé leur produit grâce à Google :wink:

Bonne journée à tous

Devred

Réactions aux différentes réponses pour ma part :

- Equiper un PC d’une douchette portable et amener les produits jusqu’à lui
Ou s’équiper d’un PC avec une autonomie suffisante en Wifi ! (Un netbook tient souvent plus de 3 heures…)
Dans ce cas, il faut juste équiper l’entrepôt du WIfi, d’un chariot pour le PC et poser les colis et une douchette (Filaire ou non selon le buget)

Pour les numéros 2 et 3 : je suis enthousiaste mais déjà, développer des écrans spécifiques dans Dolibarr coûtera plus de 1000€ et prendra certainement 3 semaines. Pour les adapter sur des terminaux spéciaux et/ou créer une application spécifique, on sera hors budget, hors délais (si tant est que quelqu’un ici sache développer cela…) et hors intérêt de la communauté Dolibarr certainement.


- Gestion des codes-barres EAN14 et des différents packagings :
> Modif de l’onglet Prix Fournisseurs avec les packagings et codes-barres associés

–> Je pense que l’intégrer ici est une bonne idée. Tu trouveras ci-dessous les infos dont je dispose et que je cherche à intégrer à la BDD de Dolibarr :
Ref produit EAN13 Qte Haut Larg Prof Masse EAN14
A9F77210 3606480094125 1 75 36 95 210
A9F77210 3606480094125 6 80 98 225 1330 13606480094122
A9F77210 3606480094125 66 300 300 400 15070 43606480094123

…Tu as oublié la notion de prix (n’oublions pas que nous sommes dans l’onglet Prix/fournisseurs). Bien sûr le prix sera recalculé unitairement, comme c’est déjà le cas actuellement.


- La possibilité de scanner tous les produits d’une commande dans le désordre sans devoir placer le curseur sur chacun des champs respectifs.
> Modif de l’écran des expéditions avec un champ supplémentaire, soit par produit, soit un champ code-barre « intelligent » (reconnait le produit scanné selon le code barre enregistré) !

–> Cette fonctionnalité est à mon avis la plus importante à intégrer à Dolibarr. Une fois sur la fiche de la commande fournisseur ou client il faut absolument pouvoir scanner tous les produits sans que l’opérateur soit obligé de préciser quel produit il va scanner. Sans cette première fonctionnalité le reste ne servira à rien.

Oui, c’est celle qui nous fera gagner un temps précieux :
Côté commande fournisseur :
A la réception : Si le produit ne possède pas de code-barre EAN 13, Dolibarr doit demander si l’on souhaite en enregistrer un (Oui/non) SI oui, alors le curseur se place dans le champ qui va bien et on le bippe. si non, le curseur se place dans le champ qté et on met la qté à la main.

Côté commande client : c’est déjà bien expliqué je pense.
Mais il ne faudra pas oublier un petit code barre pour valider l’expé en total ou en « partiel »


Maintenant si tous les main-dévs (ou simplement Dolibarr Preferred Partner ou même simples développeurs…) sont en vacances (ou concentrés sur d’autres focntions…), on ne va pas avoir de réponse tout de suite, et c’est déjà inquiétant de ne générer que si peu d’intérêt s’il nous ont lu…

Bonjour à tous,

Globalement je ne pense pas que Dolibarr pourra intégrer toutes ces développements dans les mois à venir, d’ailleurs ce n’est pas peut être pas non plus la fonctionnalité maitresse de Dolibarr que de gérer de façon opérationnelle un stock.

Je suis actuellement en train de me rapprocher de différents WMS afin d’élaborer une passerelle avec Dolibarr, quelques contacts prometteurs ont été réalisés. Nous avons comme objectif de mettre en place cette solution à la rentrée afin d’être complètement opérationnel au cours de la fin d’année.

Bonne journée

eh m… alors, je me serais donc trompé d’outil ?
Moi je reste convaincu que Dolib va me gérer opérationnellement mon stock…
Mais comme ça n’intéresse personne d’autre que vous, je désespère !

Exemple : Je vais surement financer du code pour affiner la gestion « stock théorique » / « stock réél » par produit (et pas par commandes clients vs commandes fournisseurs) qui ne se base pas sur les entrées et sorties réelles mais sur les « états de commande » (Validée, envoi en cours, Traitée, etc…) e
t donc, si une commande est en "envoi en cours et qu’il reste à expédier des reliquats, ce n’est pas pris en compte dans le stock théorique…

Voyez-vous ?

Et donc sur quel WMS partiriez-vous et quel budget cela nécessitera et combien de temps d’adaptations ?

il y a aussi ce genre d’outil des lecteurs autonome qui déverse leur scan quand on les branche sur le pc
http://www.solumag.fr/catalog/Lecteur-code-barre/Lecteur-sans-fil/Porte-clefs-Memoire-Opticon-OPN2001

Sinon j’ai une commande pour un dev de gestion des commandes fournisseurs à partir des commandes client
pour faire simple :
je regarde produits dans les commandes clients validé et brouillon
en fonction du stock (et de la composition des produits commandés), je détermine un prévisionnel de commande fournisseurs
ex : pour le produit X composé de Y et de Z
j’ai A produit A en commande validé
j’ai B produit B en commande brouillon
j’ai C produit A en stock
j’ai de quoi fabriquer D produit X à partir de mon stock de Y et de Z
-> Je détermine la quantité de X et Y à commander pour fournir mes commandes A et B et une fois les chiffres validés, je génère les commandes fournisseurs .

Si il s’agit de produit non composé c’est un peu plus simple…

Sympa le lecteur code-barres comme cela, on pourrait envisager cette solution, mais dans ce cas, comment on « exporte les codes-barres » des commandes à préparer et comment on les réimporte pour alimenter les réceptions fournisseurs et expéditions ?

Ce ne sont pas tant les solutions matérielles qui manquent, comme le montrait Devred, il y a pas mal de choses assez pratiques…
Ce sont plutôt les solutions logicielles qui feraient défaut à s’interfacer avec le matériel.

Les développements proposés sont très intéressants :

  • La gestion de stock affinée au produit et non à la commande est en effet un développement nécessaire pour améliorer le module de stock de Dolibarr.

  • De plus, le module de génération de commandes fournisseurs en fonction des commandes clients est aussi très prometteur. J’ai déjà entendu parler de ce développement sur un autre topic et nous serons surement l’un de vos clients si le module est mis au point.

Par ailleurs, le lecteur que vous proposé est en effet, intéressant mais cela ne correspond pas à notre volonté d’intégration. Nous avons essayé ce type de lecteur de code-barres dans une société partenaire et cela a été un échec total. Les problèmes étaient que les codes-barres se perdaient lorsque l’appareil n’avait plus de batterie, les opérateurs scannaient deux fois le même code-barres sans le savoir et la liaison USB était bien trop longue et fastidieuse.

Enfin, comme le précise HubZ, ce n’est pas un problème de hardware car il y a des tas de solutions mais clairement un problème de software.

Voir sur le Github ou la Forge pour les commits et la proposition de Rdoursenaud concernant un « stock replenishment »,

https://doliforge.org/tracker/?func=detail&aid=918&atid=247&group_id=144

bien sûr la fonction proposée sera basique, mais adaptable au besoin, j’attends un devis pour la correction des gestions de stock théorique « à la ligne produit » (en tenant compte des expé et réceptions effectives et bien réelles) et non plus les etats de commande.

Pour les lecteurs Code barres, on attend déjà de voir les champs implémentés… et remplissables avant de s’aventurer sur un lecteur :wink: