Suggestion pour un Dolibarr hors connexion

Bonjour à tous,

Je propose d’ouvrir un nouveau sujet pour répondre à un besoin dont on parle depuis longtemps sur le forum, il s’agit de pouvoir gérer son entreprise avec Dolibarr même lorsqu’un pc client n’est pas connecté au serveur.

En lisant tous les sujets du forum, il s’avère que créer une solution intégrée à Dolibarr en mode « hors connexion » n’est pas possible car trop risqué, et depuis 2017, je n’ai pas vu de projet depuis la proposition d’ATM qui apparemment partait sur le codage d’une application.

Or le besoin est là et je voudrais proposer une autre approche pour contourner le problème.

Description :

Imaginons un serveur qui héberge Dolibarr et un pc client nommé Terminal 1.
Sur Terminal 1, imaginons une sorte de Dolibarr installé sur un serveur LAMP ou WAMP, qui a la même structure (même code, même langage, même arborescence…) mais avec sa propre base de données et ses propres modules. Appelons cette sorte de Dolibarr « DoliTemp » par exemple (attention, j’ai bien dit installé sur Terminal 1). Et limitons l’exemple à l’utilisation de TakePOS.

Etape 1 :

On se prépare à partir sur un salon, par exemple, mais en zone blanche donc pas de réseau (et oui ça arrive encore souvent).

DoliTemp sur Terminal 1 est connecté au réseau : un de ses modules permet d’un clic de copier toutes les tables utiles de Dolibarr dans sa base de données. Une fois cette opération faite, DoliTemp peut passer hors connexion.

A partir de là, pour bien comprendre le principe, les copies des tables lues sur Dolibarr ne seront que lues, elles ne seront pas modifiées, c’est important pour la suite.

Etape 2 :

On arrive sur le stand et on commence à vendre avec TakePOS. On a 2 cas :

  • Cas 1 : soit on vend à un tiers « générique », on n’a pas besoin de vendre à un tiers précis. Dans ce cas c’est simple, il n’y a pas de création de client à gérer.
  • Cas 2 : on doit facturer à un client précis, donc on lit la table des Tiers copiée précédemment sur le serveur pour facturer. Il faudra donc gérer aussi gérer une création de client.

Dans les 2 cas, on facture : ici DoliTemp va puiser les informations dans les tables copiées précédemment dan l’étape 1 pour récupérer le tiers, les produits, les prix, ….

Mais eu lieu de modifier les tables copiées, il va enregistrer les opérations dans ses propres tables avec ses propres codes. Par exemple une facture aura un masque unique avec le nom du terminal (disons T1 dans notre cas) puis par exemple TEMP et le numéro 20200115, ce qui donne T1TEMP20200115.

Ce numéro de facture va servir pour la traçabilité ensuite.

Etape 3 :

On revient sur site et on se connecte au serveur. On ouvre le module de DoliTemp qui permet de faire les transferts vers Dolibarr. DoliTemp va alors faire proprement ce qu’un utilisateur aurait fait s’il avait été connecté. Il récupère les transactions de ses tables et créé de nouvelles factures en mettant éventuellement son code interne « T1TEMPXXXXXXXX » dans le libellé de chaque facture par exemple, pour savoir d’où elle vient. Les informations de paiements sont transmises de la même manière automatiquement. C’est là que je ne sais pas comment il faudrait faire cette moulinette mais j’espère que les développeurs pourront traduire ce que j’explique.

Etape 4 :

Une fois le transfert effectué, DoliTemp lit la base de données de Dolibarr, vérifie que les transactions se sont bien déroulées, verrouillent ses factures temporaires interne pour les archiver et vide les tables copiées au départ sur le serveur Dolibarr pour éviter de repartir avec une base non à jour.

Puis on repasse à l’étape 1 pour un nouveau départ.

Avec ce principe, on ne risque pas d’atteindre à l’intégrité de la base de Dolibarr. On a créé une sorte d’esclave qui a ses propres tables et qui créés ensuite sur dolibarr les transactions automatiquement.

Pourquoi je parlais d’une sorte de Dolibarr ? C’est que DoliTemp pourrais être un Dolibarr modifié, adapté, ce qui éviterait de tout redévelopper. En gros chaque module de Dolibarr pourrait servir pour DoliTemp, mais au lieu de lire et d’écrire sur les tables de Dolibarr, ils liraient les copies de tables de Dolibarr et écriraient sur les propres tables de DoliTemp. On peut toujours modifier le template pour DoliTemp pour éviter de travailler sans s’en rendre compte sur l’esclave.

Dans mon exemple, j’ai pris TakePOS, mais ça doit pouvoir marcher avec le module commercial par exemple.

Pour la gestion des stocks s’il y a, ce qui me parait le plus simple est d’effectuer un transfère de stock dans l’étape 1. On part au salon avec un stock physique, c’est logique. DoliTemp va lire le stock et décrémenter le stock au fur et à mesure des ventes. Mais lorsque le stock arrive à 0, DoliTemp interdit la vente sous peine de passer en négatif. C’est une sécurité. Au retour (étape 3), pas besoin de transmettre le stock puisque celui-ci peut être décrémenté lors du transfert des factures. Eventuellement, DoliTemp peut vérifier après transfert la concordance des stocks entre Dolibarr et DoliTemp lors de l’étape 4.

Voilà maintenant il serait intéressant d’avoir une discussion ouverte sur ce projet avec les développeurs pour voir la faisabilité et si le principe est bon. Cela part d’un besoin personnel pour mon entreprise et je propose, si un développeur est intéressé par ce projet, de commencer à le financer. Évidemment ce code devra rester libre pour tous et accessible gratuitement selon notre logique open source, ça va de soi.

Merci à tous de m’avoir lu et merci d’avance pour les retours.

Seb

Bonjour :slightly_smiling_face:
Si DoliTemp est la référence :
Comment deux personnes différentes vont elles faire pour créer des factures chacune de leur coté par exemple? Elles risquent d’avoir le même numéro non ?

Et si entre temps quelqu’un fait des modifications dans le DOlibarr source ?
Et les factures édités sur le salon par DolibarTemp avec leurs Numéros provisoire sont donc des « fausses » factures, vu qu’elle vont avoir un autre numéro une fois re-intégré dans Dolibarr source ? On donne quoi au client sur le salon? La fausse facture ?
Comment faire certifier ce mécanisme complexe et incertain ?
Etc.

1 J'aime

Merci pour vos premières réponses !

Alors non, DoliTemp n’est pas la référence, c’est bien Dolibarr qui le reste. DoliTemp ne fait qu’enregistrer des transactions le temps du hors ligne, une sorte de buffer. Donc lors de la mise en ligne, Dolibarr attribue des numéros définitifs uniques comme si un utilisateur entrait les factures sur Dolibarr, et même s’il y a plusieurs terminaux, cela ne devrait pas poser de problème.

Comme DoliTemp ne fait que des numéros provisoires uniques et ne change pas la base de Dolibarr, tout le monde peut continuer à travailler sur Dolibarr sans problème. La numérotation définitive se fera lors de la connexion du terminal distant. Et même s’il n’y a plusieurs terminaux en circulation, chaque code provisoire reste unique.

En revanche :

Là c’est effectivement compliqué ! Au départ je suis parti sur l’idée d’un POS sans facturation, juste des tickets. Mais si on doit facturer sur place et éditer les factures, ça se corse… Et pourtant c’est le cœur du problème.

Pour la certification, il me semble que le principal est que Dolibarr le soit, DoliTemp n’est qu’un outil tampon, mais cela ne résout pas le problème des « fausses factures ».
Il serait intéressant de voir si légalement, on peut rajouter une extension avec une chaine alphanumérique aléatoire, par exemple :
FA1912-0132 -DF
La on a rajouté DF, il pourrait y avoir un doublon FA1912-0132 -RX qui ne gênerait pas mais est-ce légal ??? et pratique ?

Ce qui est légalement possible, c’est d’avoir deux séries de numérotation de facture, justifiées par des contraintes techniques. C’est la solution.
Si tu communiques une facture sur un poste « détaché », celle-ci doit répondre à toutes les exigences réglementaires, donc avoir son numéro définitif.
Il est clair que Dolibarr n’a pas été conçu dans cette voie. Ça risque d’être lourd. Je n’imagine une réalisation que module par module.
Le plus compliqué dans les systèmes de synchronisation, c’est l’intervention concurrente sur les mêmes données. Par exemple, une offre a été faite, un utilisateur la modifie d’un côté, mais de l’autre, elle passe au statut acceptée et facturée. Comment les réconcilie-t-on ? En pratique, on ne peut pas. Il faut concevoir le système pour que cela n’arrive pas.
Personnellement, je n’en aurais aucun usage. Mais je suis loin d’être représentatif.

Bonsoir Yves57,

Oui effectivement, l’utilisation d’une numérotation spécifique est autorisée par la loi. Elle est généralement utilisée lorsque la numérotation classique est incompatible avec l’organisation de l’entreprise. Généralement dans ce cas c’est le préfixe qui change pour que la règle de la numérotation continue puisse s’appliquer.
Donc dans notre cas, on pourrait attribuer en préfixe une lettre par poste et évidemment une lettre pour le serveur.
Après tu parles de synchronisation mais ce n’est pas l’idée que je présente. On est en sens unique de DoliTemp vers Dolibarr. L’idée que je propose ne permet pas de modifier avec DoliTemp une facture existante sur Dolibarr, de la valider,… et surtout en mode hors connexion. Dans l’autre sens, personne sur Dolibarr ne peut modifier une facture qui n’existe pas encore dans sa base et qui n’est présente que sur le terminal itinérant. L’outil DoliTemp ne sert seulement qu’à créer des factures dans un cadre bien précis pour éviter de saisir à la main les transactions du jour lorsque qu’il n’y a pas de réseau.
Et je disais plus haut qu’une fois le transfert effectué, et vérifier, DoliTemp verrouille ses propres écritures et efface les données copiées au départ. Ce n’est donc pas une base en doublon a synchroniser, c’est seulement un lieu de stockage tampon en attendant l’écriture des factures dans Dolibarr.
Il faudrait peut-être que j’arrive à faire un schéma plutôt que de faire un long discours… Ce n’est pas facile d’expliquer par écrit.

Bonjour a tous
Pour la facturation c’est assez simple a mettre en œuvre en fait. C’est un terminal de paiement de type caisse autonome qui synchronise sa base clients et produits avant départ pour ensuite décharger les factures sur numérotation spécifique. Pour le stockage il faut avoir un entrepôt autonome forcément !
Le compliqué comme le dit @pm17 c’est toutes les mise a jour autour. Le changement de téléphone sur le terminal doit il prévaloir sur Dolibarr voir un autre terminal ?
On est aujourd’hui de plus plus connecté donc cette problématique devrait disparaître non ?
@+

Dans la présentation de ton premier message, c’était plus large que ça. Tu donnais la caisse comme exemple uniquement.
Maintenant, tu as le droit de restreindre la question initiale.

Slt

J ai rien dit moi :sweat_smile:

:upside_down_face: oups ! Je voulais dire @yves57 désolé !

Bonjour à tous et merci pour vos réponses,

Oui c’est exactement ça ! Ceci résume bien ce que je recherche en limitant à la caisse.

Oui c’est là la difficulté d’où :

Et oui, je pensais large car ce principe de lire la base au départ puis de créer une numérotation spécifique me paraissait applicable à tous les modules, je voyais surement trop large.
Ceci dit, mon besoin personnel se limite qu’à la caisse pour le PdV et ceci avec un seul tiers générique, on a pas besoin de demander le nom des tiers qui nous achète sur un marché, quand vous achetez votre baguette de pain, personne ne vous demande votre nom. L’avantage est que l’on n’a plus le problème de la gestion des tiers cité par @philazerty.

Quitte a demander un développement, je me disais, « autant que ça serve pour tout le monde et que les fonctionnalité soient large », mais si c’est trop compliqué, la discussion peut s’orienter vers un projet de caisse autonome qui suffit. Et puis il vaut mieux commencer par quelque chose de simple.

Ce qui m’intéresse, c’est d’avoir votre avis sur le principe du système présenté dans mon premier message avec comme base du code php comme Dolibarr exécuté sur un serveur LAMP ou WAMP selon le système ? Cela permettrait-il de récupérer les codes existants sur Dolibarr pour les adapter ?

La question que je me pose : comment gérer les logs inaltérables pour pouvoir certifier cette caisse autonome ? Est-ce que le fonctionnement actuel de la génération de logs sur la caisse pourrait être reproduit en local puis ensuite les logs transférés avec les factures sur Dolibarr ? Quels sont vos avis ?

Et j’oubliais de cité :

C’est une bonne remarque ! Reste à savoir quand ? La fibre optique en déploiement sur nos territoires ruraux devrait être fonctionnelle en 2024, mais la couverture réseau 3G ou 4G n’est pas à l’ordre du jour dans les zones peu peuplées. Mais on peut imaginer qu’une fois la fibre déployée, des relais hertziens pourront être plus facilement implantés pour améliorer la couverture.

Ceci dit, la question est de savoir aussi s’il ne serait pas intéressant de faire une caisse autonome pour s’affranchir des problèmes ou des pannes de réseaux et vendre malgré tout. Ça nous est arrivé de tomber sur un réseau saturé avec des temps de latence de fou, ou carrément HS, et dans ce cas, il n’y a plus qu’à sortir le cahier et le stylo…

Bonjour,

Le plus simple reste quand même de faire un clone de Dolibarr avant de partir sur le salon puis re-integrer la sauvegarde dans le serveur une fois le salon terminé.

Bonjour :slightly_smiling_face:
Oui mais le souci c’est quand plusieurs personnes s’en servent en même temps.