Tout ce qui a changé
dans LemonBank.

1.1.2 (27 octobre 2026)

Un paiement par carte est enregistré en carte bancaire, plus en virement. Un débit « CB6305 … » rapproché d’une facture créait un règlement en virement, sur le paiement comme sur l’écriture bancaire. Le module lit maintenant le libellé de l’opération : prélèvement d’abord, puis carte (« CB1234 », « CARTE X1234 », « PAIEMENT PAR CARTE »), puis chèque, et virement à défaut. Un prélèvement dont le libellé cite une carte reste un prélèvement. Cela vaut pour les factures comme pour les paiements directs (salaires, charges, TVA, cotisations). Si le mode Carte bancaire ou Chèque est désactivé dans le dictionnaire des modes de paiement, le règlement reste en virement, comme avant. Les règlements déjà enregistrés ne changent pas.

1.1.1 (14 octobre 2026)

Une somme de factures lointaines n’est plus proposée comme correspondance. Un débit AMAZON de 84,87 € du 10 septembre se voyait proposer la somme de deux factures du fournisseur : l’une du 3 septembre (20,99 €), l’autre du 17 février (63,86 €). La piste ne tenait que parce que l’addition tombait à deux centimes du relevé, à sept mois d’écart. Les combinaisons de plusieurs factures se limitent désormais aux pièces dont la date ou l’échéance approche celle de l’opération — 60 jours par défaut, réglable dans la configuration du module. Une facture isolée au montant exact reste proposée quelle que soit son ancienneté : un impayé qu’on régularise tardivement est une correspondance, pas une coïncidence. L’écart toléré sur une somme est par ailleurs plafonné et ne s’élargit plus avec le nombre de pièces, et les factures retenues dans une combinaison sont nommées au journal, avec leur date et leur reste à payer.

Un écart sur une somme de pièces ne passe plus pour un acompte. Quand la somme d’une combinaison n’atteignait pas exactement le montant de l’opération, l’écran annonçait « Montant partiel : l’opération serait enregistrée comme un règlement de 84,87 € » — ce qui présentait le symptôme comme une caractéristique du règlement. L’écart est maintenant nommé pour ce qu’il est, et appelle la vérification. La mention d’acompte reste là où elle est vraie : une facture unique dont le reste à payer dépasse le montant reçu.

Un même mouvement importé deux fois par deux exports différents est écarté. La Banque Populaire propose deux exports OFX des mêmes opérations, qui n’ont rien en commun : ni identifiant, ni référence, ni même libellé. Déposer l’un après l’autre faisait revenir comme nouvelles toutes les opérations déjà importées (180 sur un fichier réel), dont certaines proposées en correspondance sûre vers une facture : autant de règlements en double au premier clic. Le module les reconnaît désormais quand tout concorde (compte, montant au centime, dates à trois jours au plus, un mot du libellé en commun, période couverte par les deux fichiers), un pour un, et les classe dans « Ignorées » avec un motif qui nomme l’opération d’origine, avant toute proposition de rapprochement. Rien n’est effacé, et la ligne se remet en file d’un clic. Le récapitulatif d’import en donne le nombre, et l’alerte de doublons possibles compte désormais aussi les recouvrements entre deux fichiers de même format.

Une opération dont la banque change l’identifiant n’est plus importée deux fois. Une opération exportée le jour même sort avec un identifiant provisoire, remplacé par le définitif au fichier suivant. Sa référence bancaire, elle, ne change pas : elle suffit maintenant à reconnaître l’opération d’un fichier à l’autre de même format, dans une fenêtre de trois jours.

Le rapport à copier du diagnostic garde ses retours à la ligne. Il sortait sur une seule ligne, coupée de « \n » littéraux, et c’est ce texte qu’on collait pour le support. Affichage seul, rien n’est stocké.

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.1.0 — 15 septembre 2026

Deux manques signalés à l’usage : une famille d’opérations que le module ne savait pas lire, et une sélection sans action au bout.

Les remises de chèques, enfin reconnues

Une remise de 18 chèques pour 618,09 € affichait « Aucune pièce trouvée dans Dolibarr », alors que les 18 factures étaient encaissées et le bordereau saisi. La cause n’était pas une erreur de l’utilisateur : Dolibarr n’écrit aucune écriture unique pour un bordereau de remise, il garde une écriture par chèque. Le module cherchait donc une écriture de 618,09 € qui n’a jamais existé.

Nouvelle règle R11 : le bordereau natif porte le total et le nombre de chèques, on s’appuie sur lui. Ses écritures sont proposées en un seul bloc et se pointent ensemble. Un bordereau validé passe en correspondance sûre ; un bordereau encore en brouillon est proposé « à vérifier », sa composition pouvant encore changer. Aucun rapprochement n’est jamais appliqué sans clic.

Et quand le relevé annonce une remise sans qu’aucun bordereau ne réponde, le module le dit : il nomme le bordereau existant si ses écritures sont déjà pointées, et sinon renvoie vers Banques ▸ Chèques à encaisser. Il ne crée toujours rien — il rapproche, et il explique ce qui manque.

Une action pour la sélection, même sans correspondance sûre

On pouvait cocher des lignes sans qu’aucun bouton n’apparaisse : la barre d’action ne s’affichait que si la page contenait au moins une correspondance sûre. Les lignes « à vérifier » étaient donc cochables pour rien.

La barre apparaît maintenant dès qu’une ligne porte une proposition. Le bouton compte la sélection en temps réel et se désactive quand rien n’est coché. Et si la sélection contient des lignes que le module n’a pas jugées sûres, la confirmation le dit et les compte : on peut accepter en masse, jamais sans le savoir.

1.0.0 — 8 septembre 2026

Première version publiée. Le module sort de bêta et entre au catalogue de hellolemon.fr. Il rapproche, il ne crée aucune pièce comptable.

• Réglages et connexions conservés lors d’une désactivation/réactivation ; accès aux objets et endpoints renforcés.
• Imports OFX/CSV stricts, CSV multiligne, erreurs de ligne explicites et répétitions légitimes préservées ; extraction PDF bornée en temps et en volume.
• Suggestions refusées écartées des traitements automatiques ; synchronisations concurrentes sérialisées et lots API invalides rejetés.
• Annulation complète des rapprochements groupés ; paiement et factures vérifiés avant tout dépointage.
• Mode observation visible, premier import guidé et actions nommant leur effet réel ; guide utilisateur et licence complète livrés.
• Recette des sources réussie sur Dolibarr 18 à 24 avec MariaDB 10.11. Un paiement natif fictif a aussi été vérifié dans le navigateur. Connexions bancaires réelles et PostgreSQL non certifiés.
• Mode d’emploi administrateur embarqué en français et en anglais, accessible depuis la configuration.
• En-tête natif rétabli sur la configuration ; présentation Lemon sans mention de gratuité.
• Libellé de tolérance de change compatible avec les traductions Dolibarr 18 ; aide des identifiants GoCardless clarifiée.

0.1.1-beta — 2 septembre 2026

Correctifs de sécurité et deux garde-fous nés d’un cas réel en production.

Ne plus proposer de saisir une pièce qui existe

Une opération importée deux fois par deux chemins (l’OFX du relevé, puis le connecteur API) ne retrouvait plus son écriture : la première copie l’avait déjà rapprochée, et le moteur ne regarde que les écritures non pointées — à raison. L’écran concluait « aucune pièce trouvée » et invitait à créer la facture fournisseur, alors qu’elle existait, qu’elle était payée et qu’elle était rapprochée.

Avant toute invitation à saisir, le module cherche maintenant une écriture déjà pointée du même compte, même montant, à quatre jours près, dont la référence bancaire est imbriquée avec celle de la ligne. La preuve du doublon est la référence, pas la coïncidence montant + date : deux prélèvements identiques le même jour, ça existe.

Ces lignes quittent « À traiter » pour « Ignorées » avec leur motif — comptées dans le récapitulatif de relance, remises en file d’un clic. Rien n’est effacé.

Dire qu’un règlement du même montant est déjà enregistré

Le garde-fou anti-doublon ne regardait qu’à cinq jours de l’opération : il vise le même encaissement rapproché deux fois de suite. Un règlement identique enregistré six semaines plus tôt passait sous son radar, et la ligne s’affichait « correspondance sûre » avec un bouton Rapprocher.

Un avertissement nomme désormais le règlement homonyme (montant, date, référence) avant le clic. Il ne bloque pas : un échéancier à traites égales est parfaitement normal.

Sécurité

• Le numéro de compte lu dans un relevé (<ACCTID> d’un OFX) est une chaîne libre, dans un fichier fourni par l’utilisateur. Il ressortait tel quel à l’écran et dans le motif de rejet enregistré. Il est désormais réduit, à la source, aux caractères qu’un numéro de compte peut contenir.
• Le bloc de diagnostic destiné à être copié au support ne transmet plus les soldes du relevé en entier, ni les requêtes SQL journalisées en mode débogage, ni l’arborescence du serveur.
• Motif d’ignorance et nom de tiers passent par strip_tags avant affichage.
• Filtre d’entité ajouté sur la lecture du compte bancaire visé.

0.1.0-beta — 1er septembre 2026

Première version confiée à un testeur extérieur. Le module rapproche les opérations d’un relevé bancaire avec les pièces déjà saisies dans Dolibarr — factures clients et fournisseurs, TVA, salaires, charges, échéances de prêt, notes de frais. Il ne crée jamais de document comptable : il enregistre le règlement d’une pièce existante, ou pointe une écriture déjà enregistrée.

Alimentation

• Import de relevé OFX, CSV et PDF. Le profil Banque Populaire est calibré sur 62 relevés, le profil Fiducial sur 5.
• Un fichier contenant plusieurs relevés (un par compte, comme l’export Banque Populaire) est réparti automatiquement d’après le numéro de compte porté par chaque relevé. Si un seul compte n’est pas identifiable, rien n’est importé.
• Déduplication à trois niveaux : identifiant de la source, empreinte de la ligne, puis référence bancaire — y compris entre deux sources qui écrivent la même référence différemment.
• Connecteur GoCardless Bank Account Data pour qui dispose déjà d’un compte chez eux (leurs inscriptions sont fermées depuis juillet 2025).

Rapprochement

Neuf règles, de la plus sûre à la plus prudente : écriture déjà enregistrée, facture ouverte du bon sens, combinaison de factures, montant approchant d’un tiers reconnu, opération sans pièce, pièce non facturée (salaire, charge, TVA, prêt), tiers reconnu sans facture, facture en devise étrangère.

• Une écriture non pointée portant exactement la référence du relevé est retenue seule : il n’y a rien à créer, seulement à pointer.
• Plusieurs écritures dont la somme fait le relevé sont proposées ensemble (un fournisseur qui prélève en une fois les factures du jour).
• Le tiers deviné dans le libellé est corrigeable, et la correction s’apprend.

Garde-fous

• Double paiement refusé : une pièce portant déjà un règlement du même montant à quelques jours près n’en reçoit pas un second, sauf confirmation explicite — jamais en traitement de masse. Le contrôle a lieu sous verrou, à l’intérieur de la transaction.
• Annulation d’un rapprochement : dépointe l’écriture, rouvre la facture, supprime le règlement créé par le module, remet l’opération à traiter. Refusée si l’écriture est déjà passée en comptabilité.
• Refus d’une suggestion : définitif, la proposition écartée ne revient pas.

Limites connues de cette version

• Recette menée sur une seule instance et une seule banque.
• Le rapprochement automatique est volontairement rare : la plupart des correspondances attendent une validation.
• Les échéances de prêt d’un même contrat portent souvent la même référence d’un mois sur l’autre ; seule leur date les distingue.