Bug multicompany et TAKEPO

Bonjour, il y a un bug concernant TAKEPOS en utilisation multicompany,
en effet , le module takepos , crée un ticket provisoire qui n’utilise pas d’ID (prov) avec la numérotation actuelle de dolibarr , mais il crée un prov-pos-0-1. ET donc sur toutes les entité c’est le même , donc si sur l’entité 2 je change le nom du client , ça change le nom du client sur les autres factures des autres entités . qu’elle soit provisoire ou non .
en espérant avoir été clair.

Merci

Bonjour, avez vous trouver une solution?

Bonjour,

Je rencontre le même problème depuis le déploiement sur un groupe de 6 établissements, ce qui provoque de nombreuses erreurs, j’avais échangé avec @regis concernant ce problème mais il m’avait été remonté qu’après concertation avec les éditeurs de takepos, le problème n’était pas constaté…
Mon problème est toujours identique et les établissements ont régulièrement des erreurs.
Avez-vous pu régler le problème @Thomas_H ?
@regis avez-vous une solution à apporter éventuellement ou une suggestion?

Toute aide serait la bienvenue.

merci à tous.

Je me suis finalement penché sur le problème… :sweat_smile:

Pour corriger ce « bug » qui n’en est pas vraiment un, c’est plutôt une mise en compatibilité de takepos avec le multicompany, il faut modifier plusieurs fichiers, je pense qu’une modification du code source de dolibarr est nécessaire étant donné que takepos est intégré nativement et que les entrée de multicompany aussi, voici un proposition de correction.

modifier la numérotation provisoire en transformant toutes les entrées:
'PROV-POS'
en
'PROV-POS-' .(isset($conf->entity) ? $conf->entity : 1) .' - '

cette modification doit être faite dans les fichiers suivants :

racine (dolibarr/htdocs/takepos)

  • floors.php
  • freezone.php
  • invoice.php
  • pay.php
  • receipt.php
  • reduction.php
  • split.php

racine (dolibarr/htdocs/societe)

  • list.php

J’espère que ca pourra aider quelqu’un, je peux fournir mes fichiers et/ou mon code si besoin.

@Inovea @regis @eldy

1 « J'aime »

Pour pouvoir avancer, il est important d’avoir un process le plus simple possible pour reproduire le bug. Avez vous pu identifier une manip qui produit le bug systématiquement quand on la répète. Si oui, pouvez vous la décrire ?

Bonjour @eldy,

Pour reproduire le comportement, il suffit de se mettre en environnement multicompany avec 2 sociétés au minimum, 1 seul terminal dans chaque pdv.

  • Se rendre sur Takepos sur l’entité 1
  • ouvrir un ticket en ajoutant un article ou en selectionnant un client

une ligne est alors crée dans la bdd avec le la réf ‹ PROV-POS1 ›, celle-ci contient l’ensemble des données du ticket en cours sur l’entité 1

  • Se rendre sur Takepos sur l’entité 2
  • ouvrir un ticket en ajoutant un article ou en selectionnant un client

une autre ligne est ajouté dans la base de donnée avec la même référence, celle-ci reprend l’ensemble des informations du ticket en cours pour la seconde entité.

se rendre dans les encaissements (dans takepos toujours ndlr) pour encaisser le ticket sur l’entité 1, on obtient une erreur, cela valide les 2 entrées en n’en formant qu’une avec des informations mélangées comme le client de l’entité 2, le montant de l’entité 1… ensuite il est nécessaire de se rendre dans le liste des factures et passer la facture à 0 puisqu’on ne peux pas la supprimer (à moins de passer par la base de donnée et de supprimer toutes les entrées correspondantes).

la solution que j’ai proposé n’est pas forcément la seule option à considérer, on pourrait très bien imaginer d’ajouter la condition de l’entité au moment des requêtes sql des différents fichiers.

exemple :

$sql .= "WHERE entity = '" . $conf->entity . "'";

J’espère que ca aidera, je reste à disposition si besoin.

Bonjour, désolé pour la réponse tardive .
Ma solution à été de me tourner vers un développeur .
J’ai fait développer TAKEPOS Plus que vous trouvez dans le dolistore .
Il à corrigé ce bug et apporté d’autre amélioration .
Thomas

Bonjour @Thomas_H,

Merci de votre retour, je suis allé chercher le module mais ne l’ai pas vu sur le store, c’est un développement personnalisé j’imagine qu’il ne vous est accessible qu’à vous, à moins que je n’ai pas cherché correctement. je serais intéressé de savoir ce qu’apporte ce module si vous aviez la gentillesse et le temps de me détailler ses fonctionnalités.

effectivement il n’y est plus , je ne sais pas si on a le droit de mettre des liens externe .
voila la description sur leurs site , effectivement c’était des corrections et demande interne , mais qui servent à d’autre j’en suis sûr . Et en plus de mon multicompany pour un réseau de magasin en franchise , je l’ai installer dans 5 société différentes pour des amis , shop physique de manga , et 3 pizzeria + 1 pizzeria à moi .Bref utile . Voilà la description :

Caractéristiques Clés :

Regroupement des Ventes : Ce module permet de regrouper toutes les ventes en parallèle dans une sélection unique, simplifiant ainsi la gestion des transactions multiples. Utilisé surtout en pizzeria où les ventes reste en attente le temps jusqu’à la fin de soirée .

Modification des Tiers : Vous avez la possibilité de modifier et d’ajouter des informations globales telles que le nom et la ville d’un tiers directement depuis une fenêtre contextuelle, offrant un gain de temps considérable.

Recherche Rapide : Profitez d’une recherche rapide en temps réel (en Ajax) dans les listes des tiers et des factures directement depuis Takepos, facilitant ainsi la localisation rapide des informations nécessaires.

Fiche client simplifié , avec le choix de ce que l’on veux afficher

Affichage de l’Information du Contact : affiche le nom du contact, son numéro de téléphone et son adresse sur le ticket, permettant une interaction personnalisée avec les clients.

J’y au aussi rajouter la gestion des points de fidélité en plus .

et les retours produit pour un échange rapide en magasin , sans faire de facture d’avoir,

Voila , j’ai fait une bonne description la plus complète et il me semble d’avoir rien oublié.
Si besoin n’hésite pas .

La condition sur l’entité est en effet requise.
Il est normal qu’on ait 2 ref PROV-POS1-x, car ce sont dans 2 sociétés différentes, qui ne se voit pas (l’unicité est assuré grace au champ entity).
Il n’y a donc pas lieu d’ajouter l’entity ou id dans les ref provisoires. Elles sont deja unique dans chaque société. Et quand on lit on est sensé avoir aussi un filtre sur l’entité pour exclure les autres.
Je n’ai pas réussi à reproduire le probleme avec le process décrit en develop.

Quelle version de dolibarr as-tu ?
As tu la fonction bar/restaurant à on ou off ?

la condition de l’entité n’est implémentée dans le code de la version que j’utilise (18.0.2), ce qui pose problème…
la version bar/restaurant est à off et n’a jamais été activée.
pour contourner le problème, j’ai opté pour la solution que j’avais proposé, cela fonctionne à présent.

Je n’ai pas tenté de reproduire le bug sur une version ultérieure mais puisque tu ne le reproduis pas, j’imagine que cela a été corrigé ou modifié depuis.

merci @eldy pour ton aide.