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
oups ! Je voulais dire 
