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

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:

Bonjour ci-joint une application pour android avec interface pour export ou import au format xls ou txt.

gestion stock
lecteur à distance.

XScanpet.

Bonne journée.

1 « J'aime »

Parfait pour ne pas investir dans une douchette, ou un lecteur code-barres sans-fil ! Merci !

Même question… Pour ce qui est de l’applicatif, du software… interface avec Dolibarr ? (implémentation de champs sur les fiches produits, sur les fiches réceptions fournisseurs / Expés clients / Retours, etc…)

On en est plus très loin, faudrait juste réussir à convaincre les mains dévs d emettre ça sur la roadmap… car ce n’est pas un « module » mais une fonctionnalité essentielle dont beaucoup d’ERP se targuent… :happy:

Salut Defrance, pour ta demande de dév, elle rejoint celle que j’avais faite il n’y a pas si longtemps, à part que l’on ne fabrique pas… as-tu vu les pull de csalvador et rdoursenaud sur les 2 écrans replenish.php et replenishorders.php sur le github ?

ça pourrait t’être utile, non ?

Un petit lecteur code sous Android

http://www.amazon.fr/high-tech/dp/B00CLT2GIM

Il manque juste une petite interface avec DOLIBARR sous ANDROID…

Bonne Journée…

Bonjour,

Oui c’est un lecteur intéressant mais il en existe des tas sur le marché. Les problèmes sont toujours les mêmes : l’interfaçage avec Dolibarr, les champs multi-packing, la fiche commande reconnaissant les scans automatiquement…

Je ne connais pas la procédure à suivre pour faire évoluer cet aspect WMS de Dolibarr mais il est malheureusement (pour le moment) insuffisant pour traiter de façon physique nos commandes dans notre société.

Bonne soirées à tous.

@Devred
Ne mutualiserait-on pas notre besoin auprès d’un développeur certifié ?
@Benjac recherche aussi des fonctions similaires…

Y4a plus qu’à trouver un CDC commun et faire développer, non ?