Merci pour la suggestion, je vais essayer ça, et effectivement je suis certain que cela va fonctionner.
Et c’est bien meilleur que de sélectionner le 1er de la liste…
La modification ne serait-elle pas à intégrer (et généraliser) dans le core sachant qu’elle me semble améliorer l’ergonomie et la productivité ?
Cela pourrait aussi être paramétrable avec une donnée accessible à l’administration…
Bonjour
J’ai vérifié avec un lecteur code barre, il faut surtout ne pas mettre de CR/LF ou autre, uniquement le codebarre .
Fred
Merci pour l’essai, car je n’ai pas eu le temps aujourd’hui.
Mais ce n’est pas une très bonne nouvelle car certaines douchettes ne sont pas paramétrables et d’ailleurs le fait qu’elles envoient le CR/LF est un gain de temps en soi puis que la donnée dans le champ forcément reconnue (car unique) est aussitôt validée, ce qui évite une frappe entrée au clavier…
Je viens de faire l’essai
en fait en 12.0.3 dans le même fichier, je n’ai pas le code que tu indiques donc j’ai cherché :
$conf->global->PRODUIT_USE_SEARCH_TO_SELECT, 0, $ajaxoptions);
J’ai trouvé deux lignes portant ce code :
La ligne 2045 où j’ai remplacé 0 par 1
print ajax_autocompleter($selected, $htmlname, DOL_URL_ROOT.‹ /product/ajax/products.php ›, $urloption, $conf->global->PRODUIT_USE_SEARCH_TO_SELECT, 1, $ajaxoptions);
La ligne 2797 où j’ai fait de même :
print ajax_autocompleter($selected, $htmlname, DOL_URL_ROOT.‹ /product/ajax/products.php ›, $urloption, $conf->global->PRODUIT_USE_SEARCH_TO_SELECT, 1, $ajaxoptions);
Le produit est bien capté sur la zone et au CR/LF (touche entrée) le curseur passe dans la zone de texte en dessous. Il suffit de taper 2 fois sur la touche TAB pour se retrouver à la saisie de la quantité, et on valide le tout par un nouvel appui sur la touche entrée.
Je ne trouve pas ça si mal mais j’ai fait la simulation à la main sans douchette que je n’ai pas sous la main ce soir. Sur le site de démo que j’ai cité, ils ont fait le choix de présélectionner (en bleu) la 1ère ligne systématiquement et le CR/LF (ou touche entrée) la valide, ce qui est efficace si la 1ère ligne convient et aussi pour une douchette car il n’y a qu’une seule ligne ou rien du tout. L’avantage étant que le curseur ne passe pas dans la zone de texte.
Mais le comportement est peut-être différent aussi car ils affichent tous les produits sans taper le moindre caractères, or j’ai plus de 10000 produits et si je fais ça la liste met trop de temps à s’afficher donc je contraints à la frappe préalable d’au moins 2 caractères avant l’affichage de la liste.
Je pense avoir compris ces changements de comportement entre les sites à la validation de la saisie, ils sont bien liés au paramètre du module produits définissant le nombre de caractères à frapper avant que la liste n’apparaisse. Il faut que j’approfondisse ces cas pour optimiser la saisie à la douchette…
Bonjour
Le fonctionnement est différent selon le réglage dans le module produits de la recherche. Si tu désactive la recherche ajax, la selection affiche les produits et le premier résultat est sélectionné et là, la douchette marche avec le cr/lf. Si tu as 10 000 produits, il faut passer en recherche ajax (nombre de caractères déclenchant la recherche etc)
Fred
Nos réponses se sont croisées, je suis d’accord, j’ai modifié la mienne.
Bonjour,
ce matin j’ai approfondi à tête reposée l’impact des réglages du module produits sur la recherche produit de la commande client.
J’ai restitué le code à son état d’origine :(PRODUIT_USE_SEARCH_TO_SELECT, 0,)
J’ai utilisé le navigateur Firefox [83.0 (64 bits)].
Dans la génération automatique de codes à barres, j’ai paramétré le masque EAN13 par défaut à 020{0000000000} (sur 13 caractères car mes codes ont 13 caractères.
Le facteur essentiel de mes problèmes est tout de même le nombre de produits 10890 exactement…
Dans la configuration du module produits,
si le paramètre : Attendre que vous ayez appuyé sur une touche avant de charger le contenu de la liste déroulante des produits = NON
et si le paramètre : Nombre maximum de produits dans les listes déroulantes = 0
Dans commerce, saisie d’une commande client, lorsqu’on clique dans la zone Produits/Services prédéfinis en vente :
- la liste en ajax s’affiche en 5 à 6 secondes, ce qui est déjà rédhibitoire,
- la saisie, alors, d’un code à barres par douchette avec CR/LF déclenche bien la sélection du bon produit mais au bout de 11 secondes d’attente !!! Ce qui est absolument insupportable.
Mais fonctionnellement c’est impeccable.
Ensuite tout changement au paramétrage du module produits provoque le dysfonctionnement complet de la saisie du code à barres par douchette.
Par exemple si le paramètre :
Attendre que vous ayez appuyé sur une touche avant de charger le contenu de la liste déroulante des produits = OUI (quelque soit le nb de caractères choisi de 1 à 3),
Si on laisse le paramètre : Nombre maximum de produits dans les listes déroulantes à 0
- Lorsqu’on tente de saisir à la douchette (avec CR/LF) un code à barres (le même), jamais rien n’est sélectionné. Il semblerait que ça va trop vite pour le système (le CR/LF valide avant que la sélection ait opérée)
- Si on fait la même saisie à la main (ou par copier/collé), donc moins vite, la sélection finie par se faire rapidement mais, sans le patch, la touche entrée est inopérante, il faut descendre sur l’unique produit avec la flèche vers le bas du clavier ou opérer la sélection à la souris.
- Si j’applique le patch :(PRODUIT_USE_SEARCH_TO_SELECT, 1,) aux 2 lignes citées ci-dessus, le code à barres saisi à la main (ou copié/collé) est rapidement remplacé par la référence produit sur la ligne même de saisie et la touche entrée est efficace et fait passer au champ suivant. Mais rien à faire pour qu’une douchette (avec CR/LF, je n’ai que ça sous la main aujourd’hui), ait la même efficacité, le code à barres disparait après le CR/LF et c’est tout.
Si on change le paramètre : Nombre maximum de produits dans les listes déroulantes à autre chose que 0 (500 par exemple) le code barre peut ne pas être trouvé et est rejeté (aucun enregistrement trouvé)…
Si, avec le patch, je reviens à ma config d’origine, la 1ère attente est la même 4 à 5 secondes mais à la saisie par la douchette, le produit est sélectionné plus rapidement, environ 4s ce qui est bien mieux que 11s.
J’ai fait des essais sur Chrome et Edge, dans le cas de l’affichage de tous les produits par ajax. Là c’est carrément pire aucun des deux n’est capable d’afficher la liste, la page se bloque. Ils sont inutilisables dans cette configuration.
Voici donc mon analyse, j’espère qu’elle peut faire avancer la résolution de ce problème qui me semble tourner autour des performances ajax…
Je vais essayer de modifier mon PR github,mais décrire tout ça en anglais, va me prendre un peu de temps 
En fait j’ai été un peu vite, j’ai dû avoir une fois une réaction à 4s, mais en général cela ne change rien, je tourne en moyenne à 10s pour la sélection du produit à la douchette dans cette configuration.
Et puis aussi PRODUCT_DONOTSEARCH_ANYWHERE = 0 ou 1 ne change rien à ces performances…
MAIN_OPTIMIZE_SPEED = 1 non plus…
MAIN_DISABLE_AJAX_COMBOX = 1, à la douchette c’est n’importe quel produit qui est sélectionné sauf le bon !
Bonjour 
concernant ces problèmes de temps de réponses, cela indique vraisemblablement que votre installation est sous Windows avec l’installation classique de DoliWamp
si c’est le cas, il faut installer WampServer, vous devriez essayer le lien suivant
Bonne continuation
Merci pour la suggestion,
mais malheureusement ce n’est pas le cas,
Ma config est sur un serveur distant tout à fait performant :
Version: 12.0.3
OS: Linux Debian 3.16.64-2 (2019-04-01) x86_64
Web server: Apache/2
PHP: PHP 5.6.40
Database: MySQL or MariaDB 5.6.48-log
Sur lequel j’ai aussi un site Magento qui n’a aucun problème de performances (mêmes technos PHP/Mysql).
Maintenant, pour l’appli Dolibarr on peut toujours ajuster des paramètres PHP via php.ini ou .htaccess si nécessaire.
Je pourrais aussi passer en PHP7 pour Dolibarr, mais le problème semble se situer côté client avec ajax.
Bonjour ,
je vois que c’est compliqué et que l’on peut y passer du temps.
Je développe des appli mobiles sur terminal code-barre (smartphone avec scanner intégré). Vous n’avez plus rien à régler, je vous active tout ce qu’il faut sur votre serveur à distance sans changer le code : cela marchera en version supérieure. L’inventaire sera mis à jour dans la base. Cela marche avec peu de réseau wifi (donc sans fils). Bien sur ce n’est plus de l’opensource et le terminal est 10 fois plus cher qu’une douchette, mais vous gagnez du temps.
Cela peut marcher avec un smartphone Android en scan par l’appareil photo mais l’opération est toujours plus lente qu’avec un vrai scanner.
Je devais faire cette appli d’inventaire : elle sera prête 1 semaine après commande
Bonjour,
c’est sans doute très bien mais par rapport à mes besoins cela me semble un peu ressembler à un rouleau compresseur pour écraser ma mouche
Pouvoir saisir des références de produits par lecteur de code à barres simple, avec des performances acceptables devrait, à mon avis, être possible partout où ça peut être nécessaire dans Dolibarr, particulièrement pour les bases riches en nombre de produits où c’est le plus utile. Cela me semble être une fonctionnalité basique.
Mais ce n’est que mon avis 
J’ai trouvé une solution qui marche pour les douchettes à CR/LF (et les autres) mais je ne sais pas si elle est très élégante (il serait plus souple et plus sûr que la modif soit actionnée sur un paramètre de la fonction ajax_autocompleter) et si elle n’a pas d’effet secondaire ailleurs.
En fait il suffit de faire en sorte que le CR/LF (touche ENTER) soit ignoré.
En V12.0.3, j’ai fais ça dans /core/lib/ajax.lib.php dans function ajax_autocompleter
A partir de la ligne 68, je remplace :
$("input#search_'.$htmlname.'").keydown(function(e) { if (e.keyCode != 9) /* If not "Tab" key */ { console.log("Clear id previously selected for field '.$htmlname.'"); $("#'.$htmlname.'").val(""); } });
Par le code :
$("input#search_'.$htmlname.'").keydown(function(e) { if (e.keyCode != 9) /* If not "Tab" key */ { if (e.keyCode == 13) {return false;} /*disable "ENTER" key Zuiko*/ console.log("Clear id previously selected for field '.$htmlname.'"); $("#'.$htmlname.'").val(""); } });
Bien sûr j’ai gardé :les modifications du fichier /core/class/html.form.class.php :
Le seul test que j’ai fait c’est avec la donnée du module Produits
Attendre que vous ayez appuyé sur une touche avant de charger le contenu de la liste déroulante des produits
positionnée à OUI (3 caractères)
Dans ce cas les performances sont excellentes, l’affichage est instantané, qu’on fasse la sélection du produit à la main ou à la douchette. Je n’ai pas vu d’inconvénient, pour ce champ, d’ignorer la touche ENTER.
A tester/approfondir, donc…
J’ai complété mon test en faisant varier cette donnée :
- pour NON cela ne marche pas moins bien mais évidemment avec 10K produits les temps de latence sont insupportables.
- à OUI 1 2 ou 3 caractères la réactivité est au top par contre il ne faut pas limiter le nombre de produit si non il risque de ne pas être trouvé mais ça c’est normal
Il faudrait tester dans d’autres contextes où cet ajax est employé…
Bonjour,
as tu essayé simplement d’insérer un retour a la ligne dans les paramètres de ta douchette ?
Je n’ai pas essayé personnelement.
Si je fais ça dans le code que je propose (ignorer le caractère 13), c’est bien parce que la plupart des douchettes finissent leur saisie par un retour à la ligne (autrement dit : touche ENTER ou CR/LF ou caractère 13 du clavier).
Sur une de celles que j’utilise c’est codé en dur donc cela ne peut pas être changé et de toute façon, dans la plupart des usages ce retour à la ligne est un gain de temps dans la saisie.
Voir le Pull Request #15704 dans la version en développement ou le #15694 sur la V12.0.3
Si le caractère 13 est accepté par la saisie, il arrive trop tôt par rapport à la sélection du produit dans la liste via le javascrpt ajax et efface le champ.
Bonjour à tous,
Je partage mon retour sur la douchette pour Takepos.
J’ai acheté une douchette low cost afin de tester le comportement de TakePos avec douchette (j’ai dolibarr v13.0.2). J’ai été étonnement surprise du bon fonctionnent des deux !
Une fois le curseur dans « recherche », on scanne le produit, puis takepos le trouve, puis il l’ajoute automatiquement au ticket, sans clic supplémentaire. GENIAL ! Entre l’opération de scan et l’ajout du produit à la note, il faut compter 3 à 4 sec maxi.
Cela fonctionne également pour des cartes de fidélité client (si vous avez attribué des code-barres à vos clients bien entendu).
Pas mal du tout pour un premier test. Je vous ferai des retours dans l’opérationnel au quotidien.
La douchette est celle-ci pour ceux que ça peut intéresser : https://www.amazon.fr/gp/product/B01FQTAOKA/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&psc=1
La seule manip que j’ai effectué avant utilisation, est le scan du code-barre pour la langue française. C’est tout.
Simple et efficace ! Je recommande…
A dispo,
Marion
1 « J'aime »
Merci pour ce retour,
Ça confirme que le code que j’ai proposé (et qui a été intégré) tient la route. 
Au top, mille mercis pour le code !
Je ne savais pas que vous l’aviez intégré d’office, c’est extra 
Je mets tout ça en situation réelle mardi prochain au magasin !
Merci encore. 
Et bien qu’en j’expérimente du code qui fonctionne, je le dépose sur Github, il est revu, discuté et si approuvé, intégré. C’est ça la magie de l’open source 
1 « J'aime »
