Tout ce qui a changé
dans LemonPOS.

1.1.0 (14 octobre 2026)

Le paiement carte envoyé au TPE. Avec un terminal de paiement relié (Paramètres ▸ Terminal de paiement : adresse IP et port, par terminal), toucher CB envoie le montant au TPE en protocole Caisse-AP sur IP, l’ancien Concert V3 des TPE Ingenico, Verifone et de banque. Le règlement ne s’inscrit qu’une fois la carte acceptée, et le ticket soldé se valide aussitôt. Le bouton Titre-restaurant passe aussi par le TPE, et s’enregistre en titre-restaurant. Carte refusée ou paiement annulé sur le TPE : rien n’est enregistré. TPE injoignable : rien n’est débité, et la carte peut s’encaisser sur le TPE puis s’enregistrer sans lui. Réponse perdue en route : la caisse demande ce qu’affiche le TPE et trace la réponse. Un règlement passé par le TPE ne se retire pas, et l’écran ne se ferme pas avant sa validation. Chaque paiement est écrit au Journal TPE avant de partir : numéro d’autorisation, carte masquée, moyen de paiement. Son filtre « À vérifier » montre les cartes débitées sur un ticket resté non encaissé. Le numéro d’autorisation ne peut pas aller sur le règlement : le cœur l’enregistre sans numéro, et le journal inaltérable le scelle. Un paiement tapé directement sur le TPE s’enregistre toujours : « Déjà payé sur le TPE », puis CB ou Titre-restaurant, et rien n’est renvoyé au terminal. Le même choix est proposé quand le TPE répond « non effectué ». Rembourser, depuis l’historique, et par le TPE. Un ticket encaissé se rembourse depuis l’historique, dans tous les profils, restaurant compris : on choisit les articles, puis carte ou espèces, et un avoir est créé. En carte avec un TPE relié, le remboursement part au terminal (crédit de la carte) ; l’avoir n’est soldé qu’une fois le TPE d’accord. Refus ou annulation : réessayer, « Déjà remboursé sur le TPE », espèces, ou bon d’avoir en boutique. Le profil restaurant n’a ni échange ni bon d’avoir. La version du protocole se choisit par terminal, 3.00 par défaut ou 3.20, qui permet sur certains TPE de renvoyer les tickets à la caisse. Au journal, la carte s’affiche « 507590······3619 » : un PAX envoie les 6 premiers et les 4 derniers chiffres collés. La table du journal impose de désactiver puis réactiver le module après la mise à jour. Sans adresse de TPE, rien ne change.

Le Z ventile la TVA sur place et à emporter, et part en export comptable. En restauration, le taux dépend du mode de consommation : connaître le chiffre sur place et le chiffre à 10 % séparément ne suffit pas à remplir une déclaration. Le ticket Z et le rapport de caisse croisent désormais les deux, HT, TVA et TTC par taux, sur place et à emporter, avoirs de retour compris. À la clôture, un export comptable propose un classeur Excel de trois feuilles (encaissements, TVA, contrôle), aux montants écrits en nombres ; un fichier CSV le remplace si l’installation n’embarque pas PhpSpreadsheet. Limite connue : une facture réglée à cheval sur deux sessions est ventilée dans les deux.

Un bon de cuisine rangé par service. Le bon de préparation n’est plus le modèle de TakePOS, qui listait les articles à plat, avec leur prix. Il porte l’enseigne, l’heure, la table en grand, les couverts et les serveurs, puis les plats rangés en entrées, plats, desserts et « autres », chacun suivi de ses précisions. Un menu n’y figure pas : ses plats y sont, chacun dans son service, marqués « plat du jour ». L’heure est imprimée en grand, les services et les plats sont espacés, et une zone blanche en tête laisse la place à la pince du porte-bons. Le bon suivant d’une même table est titré « Suite de la commande ». Les catégories de chaque service se choisissent dans Paramètres ▸ Bons de cuisine, devinées d’après leur nom tant qu’on n’y a pas touché. Une précision part avec son plat, sur la même imprimante : TakePOS l’envoyait seule sur l’imprimante 1.

Le ticket et l’addition dans l’ordre du repas. Boissons, entrées, plats (menus et formules compris), desserts, puis le reste, l’ordre de saisie gardé dans chaque groupe. L’écran de caisse garde l’ordre de saisie. Un service « Boissons » s’ajoute aux trois autres dans les Paramètres, deviné d’après le nom (boissons, alcools, vins, bières…). Les précisions de préparation (« Bien cuit », « Sauce échalote ») ne s’impriment plus sur le ticket, l’addition ni le ticket cadeau : elles restent sur le bon de cuisine. La composition d’un menu, elle, reste.

Réimprimer un bon de cuisine. Un bon perdu ou taché se réimprime : « Réimprimer le bon », sous le ticket dès qu’une ligne est partie, ressort ce qui est déjà envoyé pour la table, sur les mêmes imprimantes, titré DUPLICATA en blanc sur noir. Rien n’est marqué ni envoyé de nouveau.

Des précisions par catégorie, qui s’ouvrent à l’ajout. Chaque groupe de précisions (Cuisson, Accompagnement, Sauce…) peut viser des catégories d’articles : la cuisson ne s’offre plus que sur les plats, plus sur un crumble. Un groupe réglé pour s’ouvrir à l’ajout ouvre la fenêtre dès qu’on ajoute l’article ; pour un menu, ses plats s’ouvrent l’un après l’autre. Un tel article ne se regroupe plus sur une ligne existante, même avec le regroupement de TakePOS actif : deux bavettes, deux lignes, deux cuissons. Le champ texte des Paramètres devient un tableau, un groupe par ligne. Les groupes existants sont repris tels quels et valent pour tous les articles, comme avant.

Un bon de cuisine que l’imprimante n’a pas pris n’est plus perdu. Le bouton « Envoyer en cuisine » passait par TakePOS, qui marque les lignes « parties en production » que l’imprimante ait imprimé ou non : imprimante éteinte ou sans papier, la caisse affichait « envoyé », la cuisine n’avait rien, et un second appui n’envoyait plus rien. L’envoi passe maintenant par LemonPOS : une ligne n’est marquée partie que si son imprimante l’a prise, l’échec est affiché avec le nom de l’imprimante, et un nouvel appui renvoie les lignes restées en attente. Une imprimante réseau injoignable répond en 3 secondes au lieu de figer la caisse une minute. Le routage (catégories, trois imprimantes, modèle du bon) reste celui de TakePOS.

« Servi par » et « Encaissé par » sur le ticket. La ligne « Serveur » nommait celui qui avait validé la vente : avec des serveurs qui prennent les commandes sur leur téléphone et une caisse qui encaisse au comptoir, tous les tickets portaient le nom de la caisse. Le ticket nomme maintenant les serveurs, d’après l’auteur de chaque article (le pourboire, ajouté à l’encaissement, n’en fait pas un serveur), et la personne qui a encaissé ; une seule ligne si c’est la même. L’addition, pas encore encaissée, ne porte que « Servi par ». Le partage d’addition garde l’auteur de chaque article sur les tickets des convives. Il faut un compte Dolibarr par personne.

Les bons de cuisine se règlent depuis LemonPOS. Une section « Bons de cuisine » dans les paramètres rassemble ce que TakePOS éparpille sur trois écrans : activation, imprimante de commande et catégories de chacune des trois, modèle du bon. Ce sont les réglages de TakePOS eux-mêmes, pas une copie : les changer d’un côté les change de l’autre.

L’installation s’explique dès l’ouverture du ZIP. Un fichier INSTALL.txt, en français et en anglais, donne les deux façons d’installer le module (depuis le menu de Dolibarr, sans décompresser, ou par copie dans custom), son activation, où trouver le mode d’emploi, et comment le mettre à jour.

1.0.0 (2026-09-24)

Première version distribuée. Les numéros antérieurs (voir plus bas) désignent un prototype interne, pas des versions distribuées.

LemonPOS est une caisse construite au-dessus de TakePOS. Le TakePOS standard reste disponible en secours. Les factures, les paiements, le stock, le contrôle de caisse et le journal inaltérable passent par les flux du cœur.

Interface de caisse

• Plan de salle groupé par salles nommées (Salle, Terrasse : les étages TakePOS reçoivent des noms), instances de « Vente directe » configurables, tables créées en lot depuis les Paramètres.
• Catalogue : catégories ordonnées et colorées par leurs fiches de tags, favoris, recherche, photos des produits, image de la catégorie pour un produit sans photo, badge de disponibilité du jour.
• Ticket : couverts, à emporter, client, note libre, offerts tracés, remises, pavé Prix / Qté / Remise.
• Précisions sur les articles (« Saignant », « Sans poivron »), en lignes à 0 € sous l’article, imprimées sur le bon de préparation. Liste réglable dans les Paramètres, précision libre toujours possible.
• Profils de caisse : « Restaurant, café, bar » ou « Commerce, boutique, atelier ». La séparation d’un ticket existe dans les deux, avec deux logiques : au restaurant on partage l’addition entre convives et ce qui reste au pot commun se divise à parts égales ; en boutique on sépare en plusieurs tickets et rien ne se divise, ce qui n’est pas attribué reste sur le premier ticket. Le profil masque ce qui n’a pas de sens dans le métier (tables et salles, couverts, plats du jour, menus composés, note sans détail) et ajuste le vocabulaire (« Libérer la table » devient « Abandonner la vente »). Les réglages correspondants disparaissent de la configuration et du mode d’emploi sans être effacés : rebasculer de profil retrouve la caisse telle qu’elle était. Offerts, ardoise, crédits et prises en charge restent indépendants du profil.
• Client : la création au comptoir ouvre une fiche (particulier ou entreprise, nom, téléphone, courriel, adresse). Avec LemonSirene, la raison sociale interroge l’annuaire des entreprises et remplit identité, adresse, SIREN, SIRET, TVA, type de tiers, effectifs et forme juridique ; l’adresse interroge la Base Adresse Nationale. SIREN, SIRET et numéro de TVA restent saisissables à la main. Changer de client réaligne sa remise permanente sur les lignes remisées automatiquement.
• Mode téléphone et tablette : produits en liste, ticket en panneau plein écran, barre de résumé, pavés à la demande.

Service à plusieurs appareils

• Chaque écriture sur une table se fait dans une transaction, sous le verrou de la facture. Deux serveurs qui tapent un coca sur la même table au même instant donnent deux cocas.
• Deux appareils qui ouvrent la même table vide au même instant se retrouvent sur le même ticket.
• L’écran relit le ticket affiché et le plan de salle toutes les 5 secondes, sauf pendant une saisie, une fenêtre ouverte, un partage ou un encaissement en cours, et quand l’onglet est caché. Une addition modifiée sur un autre appareil pendant l’encaissement est signalée.

Partage de l’addition

• Attribution d’articles par convive et pot commun divisé à parts égales. Chaque convive reçoit un ticket aux vrais produits (quantités fractionnées, ajustements ventilés par taux de TVA). La somme des tickets égale l’addition au centime, taux par taux.
• Les plats des menus, les précisions et les offerts suivent leur article sur chaque ticket, et reviennent avec lui sur la table.
• Les tickets des convives portent leur table (« 12-PAX3 »). Un partage n’efface jamais les convives impayés d’une autre table.
• Tant que des convives d’une table attendent d’être encaissés, on ne repartage pas cette table. Un bandeau « Partage en cours » propose « Encaisser » et « Revenir à la table », et le plan de salle signale les convives à encaisser.
• Un convive à qui rien n’échoit n’a pas de ticket. Un convive à 0 € (tout offert) est finalisé sans règlement.
• Le partage est refusé si l’addition a changé entre-temps sur un autre appareil.
• Quitter l’encaissement en cours de partage : sans convive encaissé, le partage est défait et l’addition revient entière ; avec des convives encaissés, ceux-ci le restent et le reste à régler revient sur la table.
• Chaque ticket de convive peut recevoir son propre client (facture nominative).
• Une prise en charge reprise sur la table suit les tickets des convives : elle est soldée quand le dernier est encaissé.
• « Libérer la table » est refusé tant que des convives de cette table attendent. « Revenir à la table » recrée le ticket de la table s’il a disparu.
• TakePOS standard : l’enchaînement des convives va du premier au dernier sans boucler ; un convive laissé sans payer attend sur la table.

Encaissement

• Saisie « décimale automatique » (7-8-0 donne 7,80 €), plusieurs modes sur un même ticket, rendu monnaie en grand. Seules les espèces rendent la monnaie ; un autre mode est plafonné au reste dû.
• Avant de payer, l’addition est relue : si elle a bougé sur un autre appareil, rien n’est encaissé et l’écran affiche le nouveau total.
• Après le règlement, c’est le reste dû de la facture qui fait foi. S’il reste quelque chose, l’écran le réclame (« Encaisser le reste ») au lieu d’annoncer « encaissé ».
• Le message d’erreur renvoyé par TakePOS est affiché quand il refuse un encaissement.
• Un ticket ne passe jamais en négatif.
• Un règlement supérieur au dû est refusé : si le dû baisse après la saisie (article retiré ailleurs, pourboire retiré), les règlements sont à ressaisir. Un crédit ne s’impute pas par-dessus des règlements saisis, et on ne change pas de table pendant un encaissement.
• Ticket à 0 € (crédit ou offerts) : finalisé sans règlement.

Crédits (avoirs, acomptes)

• Avoirs, acomptes convertis et trop-perçus du client consommables sur la note. Un crédit plus gros que la note est fractionné au montant exact, le reliquat reste disponible.
• Un crédit imputé ne traverse ni un partage, ni un retour à la table, ni une prise en charge, ni un changement de client : il aurait été consommé deux fois. On le retire, puis on l’impute sur le bon ticket.
• Une ligne de crédit se retire (droit « Encaisser »), elle ne se modifie pas.
• Deux confirmations simultanées d’un même crédit passent l’une après l’autre : la seconde trouve le crédit déjà consommé.

Boutique : codes-barres et retours

• Lecteur de codes-barres : un lecteur USB ou Bluetooth (qui se comporte comme un clavier) ajoute l’article scanné au ticket en cours, hors des champs de saisie et des fenêtres ouvertes. Le code est le champ Code-barres de la fiche produit. Dans la recherche, un code suivi d’Entrée ajoute l’article, et le début d’un code filtre le catalogue.
• Retours d’articles (profil Commerce, droits « Encaisser » et création de factures) : toujours à partir d’un ticket encaissé, retrouvé dans les trente derniers ou par son numéro, saisi ou scanné. La caisse crée un avoir Dolibarr rattaché au ticket d’origine, aux prix, remises et taux de TVA de la vente, et ne laisse jamais rendre plus que le vendu moins le déjà-rendu : le ticket d’origine est verrouillé pendant le retour.
• Quatre dédommagements : espèces ou carte (remboursement enregistré sur l’avoir, compté au Z), échange (le montant se déduit du ticket en cours, le reste devient un bon d’avoir) et bon d’avoir.
• Stock : les articles rendus reviennent dans l’entrepôt du terminal, sauf ceux comptés abîmés (« deux stylos rendus dont un abîmé » remet un stylo en stock).
• Bon d’avoir : numéro de l’avoir en clair et en code-barres, sans date limite, au nom du client du ticket d’origine. Il s’utilise à l’encaissement par son numéro, saisi ou scanné ; un bon entamé garde son reste sous le même numéro et se réimprime à son nouveau montant.
• Le ticket de caisse et le ticket cadeau portent leur numéro en code-barres dans ce profil.
• Le nombre de tickets du rapport et du Z ne compte pas les avoirs.

Ardoise

• Ticket validé sans paiement (flux différé du cœur) sur un vrai client. Onglet dédié, règlement groupé de plusieurs tickets en un seul paiement.
• Le compte bancaire et le mode de règlement viennent de la configuration du terminal, côté serveur.
• Les tickets sont verrouillés avant le règlement : deux appareils qui règlent la même ardoise ne l’encaissent pas deux fois.

Dispo du jour et menus

• Mise en place du service (« j’ai 6 blanquettes »), décompte en direct recalculé sur les tickets du jour, blocage à l’épuisement. Le serveur refuse aussi un plat épuisé, quel que soit l’appareil.
• Plat du jour saisi au clavier : il devient un service de la catégorie « Carte du jour », repris tel quel s’il revient. Exige le droit de créer des produits ou des services.
• Menus et formules : chaque plat choisi devient une ligne à 0 € sous le menu (cuisine, stock et dispo décomptés, le chiffre reste sur le menu). Seuls les plats de la dispo du jour se choisissent, six au plus, contrôlés côté serveur. Les plats suivent la quantité du menu ; une ligne incluse ne prend ni prix, ni quantité, ni remise.

Prises en charge

• Le client confie un article et repart avec un bon imprimé. Le support est une commande client validée, jamais une facture ; un prix à 0 € est accepté (« à chiffrer »). Au retour, la recherche accepte le numéro de bon, le nom ou le téléphone.
• Une prise en charge ne se reprend pas deux fois : déjà chargée sur un ticket en cours, elle est refusée.
• Elle est classée facturée, liée à la facture des deux côtés, quand le dernier ticket qui la porte est encaissé (ou mis sur l’ardoise, ou finalisé à 0 €).

Ouverture, clôture et ticket Z

• Ouverture avec fond de caisse suggéré, clôture Z native (attendu, compté, écart pour les espèces, la carte et les chèques), état permanent dans l’en-tête.
• Le Z est scellé dans le journal inaltérable de Dolibarr. Depuis Dolibarr 23, ce journal ne retient que la clôture émise par close(). Une clôture faite par valid() restait valide, mais n’y entrait pas.
• Réglage « Le service peut passer minuit ». Non par défaut, comme Dolibarr : un Z par journée civile, et la caisse se verrouille à minuit tant que la journée n’est pas clôturée. Oui : le service déborde sur le lendemain, jamais plus de 24 heures après l’ouverture, et son Z porte la journée où il a commencé.
• Réglage « Exiger l’ouverture de la caisse » exposé dans les Paramètres.
• Le ticket Z imprimé est celui de LemonPOS, sur l’imprimante ticket ou par la page z.php. Il compte ce que la clôture enregistre : tous les paiements du terminal depuis le Z précédent, chaque paiement dans un Z et un seul. Le rapport du cœur, lui, relit la journée civile de la fiche et ne montre qu’une partie d’un service passé minuit.

Historique et rapport

• Historique par journée comptable (entre deux Z) ou par jour civil, limité au terminal courant, coût borné.
• Rapport jour, semaine ou mois. Les ventes (chiffre d’affaires, TVA, offerts) sont comptées à la date de facture, ardoises comprises ; les encaissements à la date du règlement. Tuiles « Encaissé » et « Ventes à crédit », sur place et à emporter, ventilation par mode et par taux.
• Offerts comptés à la quantité, sans arrondi à l’unité : un café offert laissé au pot commun d’un partage à trois compte pour un tiers par convive encaissé.

Impression

• LemonPOS compose le ticket de caisse, l’addition, la note, le ticket cadeau, l’avoir d’un retour, le bon d’avoir et le ticket Z, et les envoie à l’imprimante du terminal (module Imprimante ticket). Le modèle du cœur imprime la référence du produit avant son libellé, ne sait pas taire les prix et ne produit pas de tableau de TVA. LEMONPOS_OWN_RECEIPT = 0 rend le ticket de caisse au modèle du cœur ; l’addition, la note et le ticket cadeau restent composés par LemonPOS.
• Le ticket, la note et le ticket cadeau portent la date et l’heure de la vente, celles du dernier règlement, y compris à la réimpression. La date de facture n’a pas d’heure dans Dolibarr : elle imprimait « 00:00 ».
• Le ticket reprend les règlements et le rendu monnaie, et garde SIRET et TVA intracommunautaire. L’enseigne, l’accroche et le pied viennent de TakePOS ▸ Ticket (TAKEPOS_RECEIPT_NAME, TAKEPOS_HEADER, TAKEPOS_FOOTER).
• Section « Ticket » dans les Paramètres : quatre interrupteurs (mentions légales, détail par article, tableau de TVA, ligne « Servi par ») et le choix d’imprimer les accents.
• Accents imprimés sans casser le document (mesures en caractères), guillemets « » translittérés, une précision toujours sur une seule ligne.
• Sans imprimante ticket, les documents s’ouvrent dans le navigateur.

Parité avec le TakePOS natif

• Ticket cadeau : après encaissement et depuis l’historique, le même ticket sans les prix. Réglage du cœur (TAKEPOS_GIFT_RECEIPT) repris dans les Paramètres, proposé dans le profil Commerce, retiré quand le cœur le retire (restrictions de la version certifiée).
• Impression automatique du ticket à l’encaissement (TAKEPOS_AUTO_PRINT_TICKETS).
• Bouton « Tiroir » : ouvrir le tiroir-caisse sans vente, par l’imprimante ticket du terminal.
• Bons de préparation : bouton « Envoyer en cuisine ». Le cœur répartit les lignes entre ses imprimantes selon la catégorie du produit et n’envoie que ce qui ne l’a pas encore été. Une ligne déjà partie en production ne se retouche plus sans le droit prévu (takepos->editorderedlines).
• TakePOS standard : bouton « Partager », liste des tickets en cours, bouton de retour vers la caisse Lemon, masquage de « Fractionner la vente ». Chacun se retire dans la section « TakePOS standard » des Paramètres.

Pourboire

• Bouton Pourboire sur l’écran d’encaissement : le client arrondit, y compris par carte. Le montant s’ajoute au ticket en ligne à 0 % de TVA, pas en règlement supérieur à la facture. Retaper corrige, taper 0 retire.
• Le compte comptable n’est pas imposé : il est porté par le service désigné dans les Paramètres. Seul le type bloque : un produit (géré en stock) est refusé, un service est exigé. Une TVA non nulle ou un compte de vente absent sont signalés en rouge dans les Paramètres, sans bloquer la caisse.

Titres-restaurant

• Un compte à choisir dans les Paramètres, et le bouton apparaît en caisse. LemonPOS crée ou réactive au besoin le mode de règlement « Titre-restaurant ». Pas de rendu monnaie, montant plafonné au reste dû.

Droits

• Deux droits LemonPOS, tous deux vérifiés côté serveur : « Utiliser la caisse » et « Encaisser ». « Encaisser » n’est pas donné par défaut à un nouvel utilisateur.
• Droits du cœur respectés : TakePOS « Modifier les lignes » pour supprimer une ligne, vider ou libérer une table non vide, changer un prix ou baisser une quantité (ajouter, augmenter, offrir et remiser restent libres) ; prix minimum du produit ; création de client (societe->creer) ; recherche de clients (societe->lire) ; création de plat du jour (produit->creer ou service->creer) ; bon de prise en charge (commande->lire et périmètre du cœur) ; retour d’articles (facture->creer).
• Profil de caisse appliqué côté serveur sur toutes ses fonctions.

Paramètres

• Un Enregistrer n’écrit que les réglages affichés. Ceux que la page masque restent intacts : les mentions légales du ticket quand le ticket LemonPOS est coupé, les réglages d’un autre profil.
• Comptes titres-restaurant propres à un terminal préservés.
• Nouvelle section « TakePOS standard ».
• Vérification de mise à jour : lecture de https://hellolemon.fr/dolibarr/versions/lemonpos.txt (url_last_version), gardée 24 heures, échec compris.

Compatibilité

• Dolibarr 22 et 23, PHP 7.4 et plus, MySQL, MariaDB et PostgreSQL. Recetté sur Dolibarr 23 avec MariaDB et avec PostgreSQL 16.

Sécurité et robustesse

• Données de l’annuaire filtrées avant d’être posées sur un tiers.
• Erreurs SQL tenues hors de l’écran, détail au journal.
• Sorties JSON sûres dans un <script>.
• Gardes de propriété par place sur chaque écriture, jeton CSRF sur toute écriture, multi-entité.

Code

• Licence GPL v3 (LICENSE).
• Fonctions partagées regroupées dans core/lib/lemonpos.lib.php.
• Clés de traduction complétées en français et en anglais.
• Paramètre de version sur les feuilles chargées par toutes les pages.

Prototype interne (2026-07, jamais distribué)

Étiqueté proto-1.0.0 dans le dépôt (il portait v1.0.0 jusqu’à la sortie de la version 1.0.0) : un prototype interne, conservé comme point de repère et non comme version publiée.

• Split PAX dans TakePOS : division d’un ticket en N factures égales avec bouton « Individuel » sur l’écran de règlement, navigation automatique entre convives.
• Masquage du « Fractionner la vente » natif, bouton « Tickets en cours », navigation catégories (retour parent, fil d’Ariane).