Tout ce qui a changé
dans LemonSuperPDP.

2.2.0 (19 octobre 2026)

Les caractéristiques des articles reçus sont conservées. Les attributs qu’un fournisseur porte sur une ligne de sa facture (BG-32 : un nom et une valeur, ou une quantité mesurée) s’ajoutent à la description de la ligne de la facture fournisseur, un par ligne, et s’affichent sur la fiche de la facture reçue. Ils étaient perdus à l’import, et des lignes de même intitulé ne se distinguaient plus. Ils sont lus dans les données de la plateforme, sinon dans le XML d’origine.

La facture vise l’acheteur écrit dans le XML. Quand LemonFacturX 4.2.0 fait de la société du contact « Facturation » l’acheteur, LemonSuperPDP vise cette même société : adresse de facturation électronique (BT-49), contrôles particulier et secteur public, annuaire, e-reporting et bac à sable. La facture partait vers le tiers de la facture alors que le XML portait le SIREN d’une autre société, et la plateforme la rejetait. Sans ce réglage, rien ne change.

2.1.4 (14 octobre 2026)

L’explorateur de l’API REST remarche sur toute l’instance. Depuis la 2.0.4, /api/index.php/explorer/swagger.json répondait 500 dès que le module était activé, pour toutes les API Dolibarr et pas seulement la sienne. Une méthode interne de la classe API était déclarée protégée : Restler, le moteur de l’API, la publiait comme route et, en la documentant, tentait de créer une facture vide, ce qui tuait la requête. Elle est privée, et les trois utilitaires publics de la classe ne sont plus publiés non plus. Les deux routes de lecture, transmissions et invoice/{id}/transmission, ne changent pas.

2.1.3 (14 octobre 2026)

Une facture que l’envoi automatique ne peut pas transmettre ne bloque plus les suivantes. Destinataire absent de l’annuaire, PDF sans Factur-X ou sans cadre de facturation, total négatif : ces factures étaient écartées sans laisser de trace, donc reprises à chaque passage, toujours en premier puisque les plus anciennes, avec une interrogation de l’annuaire à chaque fois. Deux cents suffisaient à ce que plus aucune facture récente ne parte, et la tâche n’affichait que « N ignorée(s) ». Elles passent désormais « Bloquée » : le statut se voit dans la liste des factures, le motif sur la fiche facture et sur l’écran Traitement SuperPDP, avec la date du prochain essai. L’envoi automatique les retente une heure plus tard si la cause tient au PDF, le lendemain sinon, et les factures jamais essayées passent toujours en premier. Une fois la cause levée, inutile d’attendre : la facture s’envoie depuis Traitement SuperPDP, avec le bouton « Envoyer », puisque rien n’est parti. La sortie de la tâche détaille les motifs et le nombre de factures bloquées.

Écarter une facture reçue se fait en toutes lettres. Le geste était un interrupteur sans texte, sous les boutons d’import : il paraissait « éteint » sur une ligne active, et la ligne disparaissait au clic sans dire où. C’est maintenant un lien « Écarter », détaché des boutons, et le message qui suit permet d’annuler. Une facture écartée ne propose plus que « Réintégrer », et la liste indique combien de factures écartées elle masque, avec un lien pour les afficher. Écarter n’envoie rien au fournisseur : pour lui signifier un refus, il faut importer la facture puis la refuser.

2.1.2 (14 octobre 2026)

La liste des factures reçues se filtre par date, montant et statut. Deux plages de dates, la réception et la date de la facture, et une plage de montant TTC, chacune utilisable avec une seule borne. Deux menus s’ajoutent à celui du statut d’import, parce qu’une facture porte trois statuts à la fois qui ne se déduisent pas l’un de l’autre : le cycle de vie (notre réponse au fournisseur, approuvée, refusée, en litige, paiement transmis, ou aucune réponse, et celle du fournisseur ou de la plateforme, encaissée, rejetée, irrecevable, annulée) et la facture fournisseur créée dans Dolibarr (pas encore importée, brouillon, validée non payée, payée, abandonnée, supprimée depuis l’import). On retrouve ainsi « brouillon et refusée » en deux clics. Changer le nombre de lignes par page ne vide plus les filtres.

Une facture dont le contact acheteur a un courriel part de nouveau. Avant l’envoi, le module pose l’adresse électronique de l’acheteur (BT-49) dans le XML. Pour savoir si elle y était déjà, il cherchait une balise dont le nom se terminait par « URIUniversalCommunication », ce qui attrapait aussi le courriel du contact de facturation, publié par LemonFacturX depuis la 4.0.4. L’adresse électronique prenait alors la place de ce courriel, et la plateforme refusait la facture (« URIUniversalCommunication: This element is not expected »). Signalé par un client. Le contact est maintenant laissé intact.

La référence d’une ligne est relue dans la facture d’origine quand la plateforme ne la transmet pas. Sur un relevé de frais de la Banque Populaire, chaque ligne porte sa référence d’opération (« Réf OP:0037428 »). Elle est bien dans le fichier du fournisseur, mais la plateforme ne la rend pas dans les données qu’elle transmet, et la 2.1.1 ne pouvait donc pas la reprendre. Le module la lit maintenant dans le fichier d’origine, XML ou PDF Factur-X, et l’ajoute à la fin de la description, sur une ligne à part. Une ligne dont la plateforme a déjà transmis la référence n’est pas modifiée. Une valeur qui porte déjà son intitulé est reprise telle quelle, sans « Réf. : » devant.

2.1.1 (9 octobre 2026)

L’objet facturé par une ligne reçue n’est plus perdu. Beaucoup de fournisseurs précisent sur chaque ligne ce qu’elle facture : le numéro de série d’un appareil, la ligne téléphonique d’un abonnement, le point de livraison d’un contrat d’électricité, le numéro de châssis d’un véhicule en location. Cette référence était ignorée à l’import, et deux lignes « Abonnement mobile » ou « Loyer véhicule » devenaient impossibles à distinguer dans Dolibarr. Elle est désormais ajoutée à la fin de la description de la ligne de facture fournisseur, avec un libellé clair quand le fournisseur en indique la nature (« N° de série », « N° de châssis », « Point de livraison », « N° de compteur », « Ligne téléphonique », « N° de contrat », « Contrat de location »), et « Réf. » sinon. La fiche de détail d’une facture reçue l’affiche aussi sous la description de chaque ligne. Cette référence sert à lire, pas à rapprocher : le module ne s’en sert jamais pour chercher une facture ou un produit.

Une facture reçue sans SIREN retrouve son fournisseur par le numéro de TVA. Le fournisseur n’était cherché que par son SIREN : une facture qui n’en porte pas, celle d’un fournisseur étranger le plus souvent, partait en quarantaine avec le motif « SIREN absent », et l’écran proposait la liste de tous les fournisseurs. Quand le SIREN manque ou ne désigne aucun tiers, le module cherche maintenant le numéro de TVA du vendeur parmi les fiches tiers, quelle que soit la façon dont il y a été saisi (espaces, points, tirets, minuscules). Un seul tiers le porte : il est retenu, et la note privée de la facture fournisseur le dit pour que la vérification avant validation porte aussi là-dessus. Plusieurs tiers le portent : la facture reste en quarantaine et le motif cite le numéro. Aucun : le motif dit que le SIREN est absent et que le numéro de TVA n’a rien donné. Le choix d’un tiers fait à la main depuis la quarantaine est retenu par numéro de TVA quand la facture n’a pas de SIREN, comme il l’était déjà par SIREN : les factures suivantes du même fournisseur passent sans question.

Le tiers dont le nom correspond est proposé dans l’écran des factures reçues. Pour une facture en quarantaine, le sélecteur de tiers est présélectionné sur le fournisseur dont le nom est celui du vendeur (accents, ponctuation et forme juridique mis à part), ou sur le seul fournisseur dont le nom le contient, avec la mention « Proposé d’après le nom, à vérifier ». Ce n’est qu’une proposition : rien n’est importé sans le clic sur « Importer », et deux sociétés pouvant porter le même nom, le module ne rapproche jamais une facture par le nom seul.

La fiche de détail d’une facture reçue affiche enfin ses lignes en entier. Seul le montant de chaque ligne apparaissait : la désignation, la quantité, l’unité, le prix unitaire et le taux de TVA restaient vides, la fiche les cherchant sous des noms que la plateforme n’emploie pas. Ils sont maintenant lus là où la plateforme les livre, et le prix unitaire est ramené à l’unité comme il l’est à l’import.

Une facture rejetée se renvoie, une facture refusée ne se renvoie plus. Jusqu’ici, qu’elle ait été rejetée par la plateforme, déclarée irrecevable ou refusée par le client, une facture affichait « Refusée » et le bouton d’envoi revenait dans les trois cas. La norme les distingue, et le module aussi désormais. Une facture rejetée par la plateforme (fr:213) n’a pas été intégrée : une fois la cause corrigée hors de la facture (fiche du client, adresse d’annuaire, réglages), elle se renvoie sous le même numéro, et le PDF Factur-X est régénéré par LemonFacturX au moment du renvoi. Un fichier irrecevable (fr:501) est régénéré puis redéposé. Une facture rejetée pour doublon n’a rien à renvoyer : le premier dépôt a abouti. Une facture refusée par le client (fr:210) ne se renvoie pas : le module indique d’établir un avoir interne, qui ne sera pas transmis, puis une nouvelle facture sous un nouveau numéro.

Le bouton s’appelle « Renvoyer », et il dit pourquoi quand il ne peut pas. Sur la fiche facture, dans la liste « Traitement SuperPDP » et dans l’onglet « Facturation électronique », le bouton n’est actif que dans les cas permis. Ailleurs il reste grisé, et son infobulle donne le motif et le geste à faire ; l’onglet le dit aussi dans un bandeau. Chaque renvoi crée une nouvelle transmission : l’ancienne reste dans l’historique avec son rejet, rien n’est effacé. La liste précise enfin, sous « Refusée », s’il s’agit d’un refus du client, d’un rejet de la plateforme ou d’un fichier irrecevable, avec le motif.

Un avoir interne ne part plus, même à la main. L’avoir qui solde une facture refusée, rejetée ou irrecevable n’a pas à être transmis : l’envoi automatique l’écartait déjà, l’envoi depuis la fiche ou la liste le laissait passer. Il est désormais refusé partout, avec l’explication. L’avoir d’une facture rejetée pour doublon, qui avait bien été déposée, part normalement. L’envoi automatique, de son côté, ne renvoie jamais une facture déjà présentée à la plateforme.

« La facture existe déjà » n’est plus pris pour un envoi réussi sans vérification. Quand la plateforme répond qu’une facture existe déjà sous un identifiant, le module relit cette facture et ne s’y rattache que si elle porte le même numéro et n’a pas été rejetée ; son statut est alors repris tel que la plateforme le connaît. Sinon l’envoi reste en échec, avec la raison. Avant, tout refus citant un identifiant suffisait, et un renvoi refusé pouvait passer pour transmis. « Forcer l’envoi » ne passe plus outre qu’une facture déjà déposée, jamais un refus, un doublon ni un avoir interne.

Quand la plateforme refuse quand même le numéro, le module le dit. En bac à sable, SUPER PDP refuse le renvoi d’une facture rejetée sous le même numéro (« La facture est déjà existante »), alors que la norme le permet. Le module reconnaît ce refus, en français comme en anglais, constate que la facture désignée est le dépôt rejeté, et propose alors l’avoir interne et une nouvelle facture au lieu de laisser « Renvoyer » reproduire le même refus.

Le Factur-X est régénéré, puis la facture part. Quand le renvoi demande un nouveau PDF, le module le régénère par LemonFacturX puis envoie dans la foulée, en deux temps invisibles depuis la fiche facture, l’onglet ou la liste. Faire les deux d’un coup provoquerait une erreur fatale sur les installations où Dolibarr fabrique ses PDF avec sa propre bibliothèque. En envoi groupé, les factures régénérées sont signalées et repartent au lancement suivant.

Bac à sable : un dépôt par charge utile de référence est enfin enregistré. La transmission restait « en attente », sans l’identifiant que la plateforme venait de rendre, et ses statuts n’arrivaient jamais.

2.1.0 (5 octobre 2026)

Une mise à jour par copie de fichiers s’installe toute seule. Jusqu’ici, après avoir remplacé les fichiers du module, il fallait le désactiver puis le réactiver pour que les nouveaux champs, onglets et réglages apparaissent. Sans ce geste, rien ne le signalait, et c’était la première cause des demandes de support. Le module mémorise désormais la version installée : dès qu’un administrateur ouvre une facture, une page du module ou sa configuration après une mise à jour, l’installation est rejouée automatiquement, sans toucher aux factures reçues, aux transmissions ni aux réglages, et un message le confirme. Un utilisateur sans droits d’administration est prévenu une fois qu’un administrateur doit passer. La configuration affiche la version installée et celle des fichiers, avec un bouton « Rejouer l’installation » pour le faire à la demande.

Les factures au secteur public ne partent plus vers SuperPDP, et le module dit pourquoi. Communes, administrations et établissements publics reçoivent leurs factures sur Chorus Pro, que SuperPDP ne dessert pas. Leur envoi échouait sur un message en anglais qui n’expliquait rien (« receiver address does not exist in peppol directory »). Le module reconnaît désormais un client public avant l’envoi : type de tiers « Administration », facture ou fiche client que LemonFacturX traite comme une facture Chorus Pro, adresse de factures publiques saisie sur la fiche, ou annuaire qui présente le client comme une entité publique. L’envoi est alors bloqué, y compris au renvoi forcé et en envoi automatique, avec le motif et le geste à faire : générer le PDF Chorus avec LemonFacturX et le déposer sur le portail Chorus Pro. Sur la fiche facture, le bouton d’envoi est grisé et son infobulle donne la même explication.

Le pré-contrôle d’annuaire ne laisse plus passer les entités publiques. L’annuaire leur connaît des adresses actives, une par établissement, mais aucune à leur seul SIREN et aucune sur le réseau des plateformes : le pré-contrôle concluait à tort que la facture pouvait partir.

Un destinataire introuvable est expliqué en français. Quand la plateforme refuse une adresse inconnue de son réseau, le message enregistré sur la facture dit maintenant quoi faire : facturer sur Chorus Pro si le client est public, sinon saisir son adresse d’établissement sur sa fiche. Le message d’origine reste dans les données de l’événement pour le support.

Une facture reçue que la base refuse n’arrête plus la réception des suivantes. Pour ne jamais perdre une facture, la synchronisation s’arrêtait juste avant celle que la base n’arrivait pas à enregistrer, et la retentait à chaque passe. Si le refus était définitif, plus rien n’entrait, sans autre signe qu’un compteur d’erreurs. La facture est désormais enregistrée une seconde fois sous forme réduite : son identifiant sur la plateforme, son contenu complet tel que la plateforme l’a livré, et le motif du refus. Elle apparaît dans la liste des factures reçues en statut « Erreur », le comptable est prévenu comme pour une quarantaine, et la réception continue. Sa fiche de détail est complète, et son import relit numéro, type, devise et montants dans le contenu conservé : un avoir reste un avoir, une facture en dollars reste en dollars.

Si même la forme réduite est refusée, l’arrêt se voit. Un bandeau sur l’écran des factures reçues dit quelle facture bloque, depuis quand, la dernière tentative et l’erreur de la base. La tâche planifiée le dit dans son résultat, et le journal des échecs de la configuration le note une fois. Le bandeau disparaît de lui-même dès que la facture passe.

Deux champs reçus partaient sans être ramenés à leur colonne : le numéro de TVA du fournisseur et le code type du document. Une valeur hors norme suffisait à faire refuser l’enregistrement. Tous les champs texte reçus sont maintenant ramenés à la largeur de leur colonne, y compris sur une instance qui a désactivé la troncature des textes (réglage MAIN_DISABLE_TRUNC), qui rendait sans effet celle des autres champs.

Les services reçus entrent en service, plus en produit. Toutes les lignes d’une facture reçue entraient en « produit », services compris, ce qui les envoyait au mauvais compte de charge (signalé par un intégrateur). La norme ne dit pas, ligne par ligne, si l’on achète un bien ou un service, mais le cadre de facturation de la facture le dit pour l’ensemble : un cadre S (S1, S4…) fait entrer les lignes en service, un cadre B en bien. Sur une facture mixte (cadre M) ou sans cadre, rien ne change : il n’y a rien de sûr pour trancher ligne à ligne. Une ligne rattachée au produit par défaut du fournisseur garde la nature de ce produit. La note privée de la facture dit quel cadre a décidé. Le cadre est lu dans les données transmises par la plateforme, et à défaut dans le fichier original : un XML se lit toujours, un PDF Factur-X seulement si LemonFacturX est installé.

Une facture dont le client a transmis le paiement l’affiche. Quand l’acheteur signale qu’il a payé (statut « Paiement transmis », fr:211), la facture restait affichée « Acceptée » dans la liste des transmissions : le statut ne changeait rien chez l’émetteur. Elle passe maintenant en « Paiement transmis », avec la couleur de l’acceptation qui le précède, et le filtre de statut le connaît. Ce n’est pas encore « Encaissée » : l’encaissement, c’est vous qui le constatez, et le module le déclare lui-même au règlement de la facture, comme avant. Les factures déjà dans ce cas changent de libellé à la réactivation du module.

Le courriel d’une facture importée dit ce qu’il faut vérifier. Une facture importée automatiquement avec un écart de total ou de ventilation de TVA arrivait annoncée comme les autres : l’écart n’était écrit que dans la note privée de la facture. Le courriel de notification le reprend désormais, sur une ligne « À vérifier », comme un fichier original qui n’a pas pu être joint ou une pièce jointe écartée. Une facture importée sans remarque garde le courriel d’avant.

Quelques centimes d’écart de TVA : la cause et le remède. Sur une facture de nombreuses lignes, la TVA importée pouvait différer de quelques centimes de celle du fournisseur (signalé par un client sur une facture de cinquante lignes). Le fournisseur calcule la TVA une fois par taux, sur le total, comme le veut la norme ; Dolibarr arrondit celle de chaque ligne puis additionne. Le mode d’emploi explique désormais le phénomène et les deux façons de s’aligner : « Recalculer : Mode 2 » sur la fiche d’une facture, ou le réglage MAIN_ROUNDOFTOTAL_NOT_TOTALOFROUND_SUPPLIER pour toutes les factures fournisseurs (MAIN_ROUNDOFTOTAL_NOT_TOTALOFROUND avant Dolibarr 20, qui vaut alors aussi pour les factures clients). Quand l’écart relevé à l’import reste de l’ordre de l’arrondi, un centime par ligne au plus, la note de la facture le dit et rappelle ce réglage s’il n’est pas posé. Le module ne le pose jamais lui-même : c’est un choix qui revient à votre configuration.

2.0.8 (28 septembre 2026)

Les pièces jointes du fournisseur arrivent avec sa facture. Une facture électronique peut transporter ses propres annexes : relevé de consommation, bordereau de livraison, feuille de temps, et souvent le PDF de la facture elle-même quand le fournisseur ne dépose qu’un XML. Le module ne les récupérait pas. Elles sont maintenant rangées dans les fichiers de la facture fournisseur, telles que le fournisseur les a envoyées, sous un nom qui finit par « -pj-superpdp », et l’onglet « Facturation électronique » les liste avec les autres fichiers reçus. Seuls les types admis par la norme passent (PDF, PNG, JPEG, CSV, XLSX, ODS), vérifiés sur leurs premiers octets et pas seulement sur le type annoncé, avec 10 Mo et 20 pièces au plus par facture. Une pièce écartée est signalée sur la ligne de la réception, avec son motif. Une pièce citée par une simple adresse externe n’est jamais téléchargée.

L’aperçu lisible est toujours le rendu de la plateforme. Quand le fournisseur joignait son propre PDF, la plateforme le reprenait comme version lisible : avec les pièces jointes, il serait arrivé deux fois. L’aperçu est désormais toujours le rendu de SUPER PDP, et les pièces toujours celles du fournisseur.

Un XML importé à la main a lui aussi son aperçu, et ses pièces jointes, y compris quand l’import attend en quarantaine le choix du tiers.

Le contenu des pièces jointes ne va jamais en base. Il ne transite que le temps d’être écrit dans le répertoire de la facture ; les données conservées gardent le nom, le type et la taille de chaque pièce. Le modèle renvoyé par la conversion d’un fichier importé à la main était jusqu’ici stocké tel quel, avec le contenu de ses pièces s’il en portait.

La fiche d’une facture reçue rend ses retours à la ligne. L’adresse des parties sortait sur une seule ligne coupée de « \n », et les données brutes s’affichaient d’un bloc.

Un moyen de paiement qui contredit la fiche du fournisseur est signalé. La facture importée garde le moyen de paiement que le fournisseur y a déclaré : c’est la facture qui fait foi. Quand la fiche du fournisseur est réglée autrement, par exemple en prélèvement alors que la facture annonce un virement, une ligne en note privée le dit. Une facture marquée « Virement » peut entrer dans un ordre de virement fournisseur : si le fournisseur prélève déjà, elle serait payée deux fois. Rien n’est ajouté quand la facture ou la fiche ne portent pas de moyen de paiement.

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), l’activation, l’endroit où se trouve le mode d’emploi, et la mise à jour. Le README commence désormais par l’installation.

2.0.7 (22 septembre 2026)

La colonne SuperPDP décalait toute la ligne de filtres de la liste des factures. Elle posait son en-tête et ses cellules, mais rien sur la ligne des filtres ; Dolibarr rendant ces lignes indépendamment, tout ce qui suivait glissait d’un cran. Le sélecteur d’état de la facture se retrouvait sous « SuperPDP », le bouton de recherche sous « État », et rien ne le signalait — ni erreur, ni message : juste un tableau qui ment sur ses colonnes.

La colonne se filtre désormais. « À envoyer » sort en un clic toutes les factures validées qui n’ont jamais été déposées ; les autres états (envoyée, acceptée, refusée, encaissée, en erreur, annulée) se filtrent de la même façon, et le filtre survit à la pagination comme au tri. Le filtre et l’affichage partagent une seule écriture : ce que la liste montre après filtrage est, par construction, ce que la colonne annonce.

Une facture reçue hérite du projet de sa commande fournisseur. Le champ prévu par la norme pour porter votre rattachement interne (BT-11) est vide sur la quasi-totalité des factures reçues : un fournisseur ne connaît pas vos projets. La commande qui a déclenché la facture, elle, le sait. Quand la facture cite une commande qui porte un projet, ce projet est recopié sur la facture créée, et la reprise est tracée en note privée — elle est une déduction du module, pas une mention du fournisseur. Un projet déjà porté par la facture n’est jamais écrasé.

Un rejet pour doublon disait le contraire de ce qu’il signifie. Rangé parmi les rejets, il se lisait comme une facture perdue, alors qu’il dit l’inverse : une facture de ce numéro était déjà arrivée, et le dépôt précédent, lui, a abouti. L’onglet Cycle de vie le signale maintenant comme tel, avec la date du premier dépôt réussi, et le bouton « Rafraîchir » explique au survol qu’il n’y a rien à rafraîchir. Rien à réémettre, et surtout pas d’avoir à établir.

2.0.6 (13 septembre 2026)

Une facture reçue avant une mise à jour restait incomplète pour toujours. Chaque version du module lit un peu plus de ce que la plateforme transmet. Les factures entrées avant gardaient les champs que la version de l’époque ignorait, et une réception déjà importée n’acceptait plus aucune action. Le seul contournement était de supprimer la facture à la main puis de redéposer le fichier par l’import manuel — ce qui laissait derrière une réception pointant vers une facture disparue.

« Réimporter », depuis la liste des réceptions. Le bouton supprime la facture fournisseur brouillon et la recrée depuis le document déjà reçu. Il refuse dans trois cas : une réception jamais importée, une facture qui n’est plus un brouillon — une pièce comptable ne se supprime pas parce qu’un mapping a changé — et une facture qui porte un règlement : le cœur de Dolibarr ne teste pas les paiements avant de supprimer une facture fournisseur, et sans ce garde-fou la suppression laisserait un paiement orphelin. Ce que le rejeu écrase : la saisie faite à la main sur le brouillon, d’où la confirmation à l’écran. Ce qu’il ne touche pas : le tiers, souvent le résultat d’un arbitrage manuel en sortie de quarantaine, et les statuts de cycle de vie — approuver ou refuser est un acte opposable au fournisseur, déjà parti chez lui.

Deux frais de pied sans libellé ne se distinguaient plus. Le libellé (BT-97/BT-104) est facultatif, et souvent vide : sur une facture réelle, deux charges sans libellé donnaient deux lignes « Frais document » que rien ne séparait. Le code du motif (BT-98/BT-105) est désormais repris entre parenthèses — c’est l’information que l’aperçu de la facture affiche en tête de colonne.

2.0.5 (10 septembre 2026)

Les frais de pied de document n’arrivaient jamais. Une facture reçue portant des frais de port ou de traitement en pied de document entrait dans Dolibarr minorée d’autant. Le module cherchait ces frais sous une clé que la plateforme n’utilise pas ; les remises, elles, passaient bien, ce qui rendait la chose invisible à l’œil. Seul le contrôle de total le notait, dans une note privée que personne ne lit.

Une facture reçue livre maintenant ce qu’elle contient vraiment. La plateforme fournit le modèle complet de la facture ; le module n’en lisait qu’une douzaine de champs. Arrivent la référence acheteur (BT-10) dans un champ cherchable — Microsoft y place le numéro de son récapitulatif de facturation, seul lien entre une facture Dolibarr et ce que le client voit dans le portail de son fournisseur —, les notes et les conditions de paiement en note publique, puisqu’elles portent les mentions de pénalités de retard et l’indemnité de 40 €, la période de service des lignes, l’unité de quantité, la date d’exigibilité de la TVA et le moyen de paiement.

Les rattachements suivent : un avoir désigne la facture qu’il corrige, la référence de commande relie à la commande fournisseur, et le code projet au projet — sur correspondance exacte uniquement, un rattachement faux se propageant sans jamais se voir. Le montant déjà réglé, l’arrondi, le bénéficiaire différent du vendeur, le représentant fiscal et le compte de paiement annoncé sont recopiés en note privée. Ce dernier est recopié et rien d’autre : un RIB de tiers qui se mettrait à jour tout seul depuis une facture entrante, c’est la fraude au virement dans sa forme la plus simple.

Le contrôle de cohérence regarde aussi la TVA, taux par taux. Le total TTC seul ne voit pas deux erreurs qui se compensent : un article à 20 % au lieu de 5,5 % et un autre à l’inverse donnent le bon total et la mauvaise TVA. Or c’est la ventilation qui part en comptabilité et sur la déclaration.

Les avoirs reçus : trois défauts, dont un qui faussait la facture. Un avoir annonce ses montants en positif — la norme fait porter le sens par le type du document, jamais par le signe — quand Dolibarr, lui, stocke un avoir en négatif. Le module comparait les deux tels quels : il signalait un écart du double du montant sur chaque avoir importé, et l’alerte s’affichait à l’endroit précis où l’on demande au comptable de vérifier avant de valider. Le contrôle de ventilation de TVA ci-dessus avait la même faille, en une alerte par taux.

Le troisième défaut, lui, ne se voyait pas dans les alertes : Dolibarr n’offre aucun moyen de mettre, dans un avoir, une ligne qui vient en moins. Une remise de pied s’ajoutait donc à l’avoir au lieu d’en être retranchée — un avoir de 1 000 € avec 50 € de remise entrait à 1 050 €. Les frais de pied, eux, vont bien dans le sens de l’avoir. Recetté sur Dolibarr 23 : la remise revient à sa place et y reste, y compris après un recalcul des totaux de la facture.

Au passage, un montant négatif affiché dans un avertissement s’écrivait avec une décimale de trop (« -8244.490 » à côté de « 8244.49 ») : la fonction d’affichage de Dolibarr compte le signe comme un chiffre. Les avertissements du module formatent désormais leurs montants explicitement.

À l’installation. La référence acheteur (BT-10) est enregistrée à l’activation du module : une mise à jour par simple copie des fichiers demande une désactivation puis une réactivation pour que ce champ existe. Le reste de l’import fonctionne sans.

2.0.4 (4 septembre 2026)

Annulation d’une facture (statut fr:220). Le scénario prévu par la norme quand une facture part en litige est de l’annuler, puis d’émettre une rectificative qui la référence. Le module savait faire les deux tiers du chemin — LemonFacturX produit la rectificative, l’onglet Cycle de vie sait poster un statut — mais pas l’annulation elle-même : le code existait dans le module, avec un commentaire disant « pas encore par nous ».

« Annulée » se propose désormais dans l’onglet Cycle de vie d’une facture transmise, tant qu’elle n’a pas été encaissée : une fois l’argent encaissé, il n’y a plus de cycle de vie à annuler, le recours est un avoir. Le geste retire la facture du circuit chez l’acheteur et rien ne l’y remet : il demande donc une confirmation explicite, contrôlée côté serveur et pas seulement à l’écran.

Deux effets de bord qu’il fallait traiter en même temps. Une facture annulée porte maintenant son propre statut de transmission — sans quoi elle serait restée affichée « Acceptée » dans la liste — et elle n’est plus proposée au renvoi, puisqu’elle a bel et bien été déposée. Et « Annulée » étant, avec « Encaissée », l’un des deux seuls statuts que les deux parties peuvent poser, notre propre annulation s’affichait dans la colonne de l’acheteur, comme si c’était lui qui avait annulé notre facture.

Voir ce que contient une facture reçue. La liste des factures reçues montrait l’en-tête et un lien vers la facture fournisseur créée, jamais le contenu. Quand une réception tombait en quarantaine, on décidait donc de l’importer à l’aveugle. Le numéro ouvre maintenant une fiche de détail : lignes, ventilation TVA, adresses des deux parties, conditions de paiement, cycle de vie, et les données brutes de la plateforme repliées en bas pour le cas technique.

Rien n’est retéléchargé : la plateforme livre déjà le modèle structuré, il n’était simplement affiché nulle part. Une réception dont la plateforme n’a pas fourni ce modèle le dit clairement, au lieu d’aligner des blocs vides.

La frise du cycle de vie est celle de l’onglet des factures fournisseurs, et plus une copie : les deux écrans la construisent maintenant au même endroit. C’est ce qui permet à une réception en quarantaine — qui n’a pas encore de facture fournisseur, donc pas d’onglet — d’afficher son cycle de vie.

La colonne d’actions se lit en toutes lettres, au choix. Les gestes du cycle de vie acheteur étaient rendus en icônes, le libellé vivant dans l’infobulle. Le choix se défend — cinq libellés dans une cellule de liste débordaient — mais il ne convient pas à tout le monde : un comptable qui approuve et refuse au même endroit veut lire ce qu’il clique.

Un réglage à trois positions règle la question : icône seule, texte seul, ou les deux. Il vaut pour toute la colonne, y compris « ignorer » et « réactiver ». En mode texte les gestes s’empilent, un par ligne : la cellule grandit en hauteur, jamais en largeur — c’est exactement le problème qui avait motivé les icônes. Le défaut reste l’icône seule, donc une installation en service ne voit rien changer. L’infobulle, qui porte le code du statut, reste affichée dans les trois cas.

Une API de lecture, pour la supervision. Deux routes en lecture seule : l’état de transmission d’une facture, et la liste des transmissions avec ses compteurs. Savoir qu’un dépôt échoue chez un client supposait jusqu’ici de se connecter à son Dolibarr.

Aucune route d’écriture, et ce n’est pas un oubli : déposer une facture, c’est la transmettre légalement ; la refuser, c’est un acte opposable au fournisseur. Ça se protège par un droit Dolibarr dédié, pas par la possession d’un jeton API.

Les frais de pied de document n’étaient jamais importés. Une facture qui porte des frais en pied — port, dossier, gestion — entrait minorée d’autant. La cause est un nom de champ : le module lisait document_level_charges, qui n’existe pas ; les frais sont sous charges. Les remises, elles, passaient bien, ce qui rendait la chose invisible. Seul le contrôle de total signalait l’écart, dans une note privée que personne ne lit.

Les factures reçues arrivaient amputées de la moitié de leur contenu. La plateforme livre le modèle complet de la facture ; le module n’en lisait qu’une douzaine de champs. Ce qui manquait n’était pas du décor.

Les notes du fournisseur (BG-1) se perdaient. Elles portent les mentions légales de pénalités de retard et l’indemnité forfaitaire de 40 € des articles L.441-10 et D.441-5 du code de commerce : elles doivent rester lisibles sur la pièce. Elles arrivent maintenant en note publique, avec leur code de sujet. Rien n’est trié — décider qu’une mention du fournisseur est dispensable n’est pas le rôle du module.

La période de service de chaque ligne (BG-26) se perdait aussi. Sur un abonnement, c’est elle qui dit ce qu’on paie, et à quel exercice la charge se rattache : une facture émise le 7 septembre peut couvrir jusqu’au 5 octobre. Dolibarr porte ces deux dates nativement.

Arrivent également l’unité de quantité, la date d’exigibilité de la TVA (BT-7, dont la colonne existait depuis toujours sans être alimentée), le moyen de paiement, les conditions de paiement, et la référence acheteur (BT-10) dans un champ complémentaire dédié, cherchable. Ce dernier mérite un mot : la norme le destine au routage interne de l’acheteur, mais des émetteurs y placent leur propre référence de suivi. Microsoft y met le numéro de son récapitulatif de facturation, celui qui ouvre la facture dans son portail — sans ce champ, il n’y avait plus aucun moyen de relier une facture Dolibarr à ce qu’on voit chez son fournisseur.

Une facture reçue se rattache à ce qu’elle concerne. Un avoir désigne désormais la facture qu’il corrige (BG-3) : il était jusqu’ici correctement typé, mais orphelin. Une facture qui cite un numéro de commande (BT-13) est reliée à la commande fournisseur correspondante, et une référence de projet (BT-11) au projet. Dans les trois cas, sur correspondance exacte uniquement : un rattachement faux se propage sans jamais se voir.

Ce que la facture dit et qu’il vaut mieux savoir avant de payer. Un montant déjà réglé (BT-113) — le total TTC n’est alors plus ce qu’il reste à payer —, un arrondi (BT-114), un bénéficiaire différent du vendeur, qui signale un affacturage, un représentant fiscal, et les coordonnées bancaires annoncées sur la facture : tout cela est désormais écrit en note privée.

Les coordonnées bancaires sont recopiées, jamais enregistrées sur la fiche du fournisseur. Un RIB de tiers qui se met à jour tout seul depuis une facture entrante, c’est la fraude au virement dans sa forme la plus simple : il suffit d’envoyer une facture. Changer un RIB reste une décision humaine.

Le contrôle de cohérence regarde la ventilation de TVA. Le contrôle du seul total TTC ne voit pas deux erreurs qui se compensent : un article à 20 % au lieu de 5,5 % et un autre à l’inverse donnent le bon total et la mauvaise TVA. Or c’est la ventilation qui part en comptabilité.

⚠️ Le champ « Référence acheteur » est créé à l’activation du module. Une mise à jour par simple copie des fichiers ne le crée pas : il faut désactiver puis réactiver le module. Sans ça, la référence n’est pas enregistrée — le reste de l’import fonctionne normalement.

2.0.3 (3 septembre 2026)

Le statut du cycle de vie apparaît dans la liste. « Approuvée » ou « Refusée » est ce que vous avez répondu à votre fournisseur, et c’est irréversible : c’est l’information la plus utile de la ligne. Elle s’affichait en petit gris sous le badge d’import, donc moins lisible que le statut d’import, qui lui n’apprend rien.

Le statut porte maintenant sa propre pastille, colorée selon ce qu’il signifie — favorable en vert, défavorable en rouge, en attente d’une suite en orange — et non selon son numéro. La réponse du fournisseur se distingue par un fond plein, avec sa provenance au survol.

Un SIREN ponctué retrouve son fournisseur. Le rapprochement d’une facture reçue avec le tiers Dolibarr ne nettoyait que les espaces. Un SIREN saisi « 424.761.419 » ou « 424-761-419 » — les deux se voient en base, personne ne saisit un identifiant deux fois de la même façon — ne correspondait à rien : la facture partait en quarantaine avec « aucun tiers ne correspond » alors que le fournisseur existait, et l’utilisateur en créait un doublon. Points, tirets et barres sont désormais ignorés des deux côtés de la comparaison. Remonté par un client sur une facture OVH.

Un statut que la plateforme refusera n’est plus proposé. Selon la règle de traitement qu’elle calcule, une facture reçue n’accepte pas toujours les statuts d’approbation ou de refus : certains flux partent en déclaration au portail public et n’échangent rien entre acheteur et vendeur. Le module répercutait alors une erreur brute de l’API — « HTTP 400 : les factures B2BInt ne supportent que le statut fr:212 » —, qu’aucun utilisateur ne peut interpréter, après avoir proposé le bouton.

Les gestes du cycle de vie ne s’affichent plus sur ces factures, la règle est indiquée au survol, et une tentative directe est refusée en français avant tout appel réseau.

Le choix du fournisseur en quarantaine devient cherchable. C’était une liste déroulante fabriquée à la main, sans recherche, qui déversait tous les fournisseurs d’un bloc — inutilisable passé quelques centaines de fiches. Le sélecteur natif de Dolibarr reprend sa place, avec sa recherche au clavier et son autocomplétion sur les grosses bases. La colonne ne pousse plus le tableau hors de la fenêtre, et la liste ne déborde plus de l’écran.

Un onglet « Facturation électronique » sur la facture fournisseur. Côté client, chaque facture portait son onglet de suivi. Côté fournisseur, rien : l’information existait, mais seulement sur l’écran des factures reçues. Depuis la facture elle-même, on ne voyait ni d’où elle venait, ni où elle en était.

L’onglet montre l’origine, le numéro du fournisseur, la date de réception, le statut et le motif s’il y en a un, une frise chronologique à trois colonnes — votre fournisseur, la plateforme, vous — reconstituée depuis les dates de la réception et la trace agenda de chaque statut émis, motifs compris, ainsi que les fichiers reçus — la pièce d’origine et, le cas échéant, l’aperçu lisible. Un badge sur l’onglet signale les factures venues de la plateforme. Une facture saisie à la main le dit, plutôt que d’afficher un écran vide.

Les gestes — approuver, refuser, suspendre — restent sur l’écran des factures reçues, qui porte déjà leurs garde-fous. Les dupliquer, c’est deux chemins à maintenir et un qui finira par diverger.

La référence article du fournisseur est conservée. Le XML porte, pour chaque ligne, l’identifiant que le fournisseur donne à son article (BT-155). Il était ignoré à l’import. Il arrive désormais dans la colonne « Réf. produit fournisseur » de la ligne de facture — c’est l’identifiant le plus stable d’une dépense, là où un libellé se réécrit d’une facture à l’autre, et c’est aussi le meilleur critère de rapprochement pour l’affectation comptable.

Une facture reçue en XML devient lisible. Beaucoup de grands émetteurs déposent un XML nu plutôt qu’un PDF portant le XML. C’est conforme — le fichier structuré est la facture — mais personne ne lit du CII à l’œil nu. Le module demande désormais à la plateforme sa version lisible et la range à côté de l’original, sous le nom {numéro}-apercu-superpdp.pdf.

Les deux fichiers cohabitent, et c’est délibéré : l’aperçu ne remplace jamais la pièce déposée par le fournisseur, qui reste la seule justificative. Le nom du fichier le dit, pour quelqu’un qui ouvrirait le répertoire sans connaître le module. Un aperçu qui échoue n’est jamais une erreur d’import — c’est un confort en moins, pas une facture perdue.

Un fichier d’origine manquant est signalé à l’écran. Quand l’import réussissait mais que l’attache du fichier échouait, l’écran affichait « Importée » en vert et rien d’autre : le motif ne vivait que dans une infobulle sur le badge, que personne ne survole quand tout a l’air d’aller. Il s’affiche maintenant à l’écran, à côté du message de succès.

Sortie d’une route dépréciée par la plateforme. Le téléchargement passait par /invoices/{id}/download, que SUPER PDP annonce comme supprimée dans la v1 de son API. Le module utilise désormais /invoices/{id}?format=…, son remplaçant — celui-là même qui permet de demander la version lisible.

2.0.2 (1er septembre 2026)

Correction de l’envoi groupé, qui n’émettait aucune requête. Le bouton « Oui » de la fenêtre de confirmation ne produisait aucune requête : la fenêtre restait à l’écran et rien ne se passait, sans le moindre message. Les identifiants des factures sélectionnées voyageaient dans des champs nommés avec des crochets, que la bibliothèque JavaScript de Dolibarr refuse comme sélecteur ; l’erreur interrompait le bouton en silence. La sélection transite désormais par un champ à nom simple.

Une facture ignorée dit pourquoi. L’envoi groupé se contentait de compter — « 1 transmise, 1 ignorée » — et le motif n’apparaissait qu’en envoi unitaire. Il fallait ouvrir chaque facture pour comprendre. Le motif s’affiche maintenant facture par facture après le récapitulatif : destinataire absent de l’annuaire des plateformes, PDF sans Factur-X, facture déjà transmise. Au-delà de quinze factures concernées, le reste est annoncé plutôt que déroulé.

« Régénérez le PDF » ne s’affiche plus quand régénérer ne servirait à rien. Un envoi est refusé lorsque le Factur-X embarqué ne porte pas le processus métier (BT-23), parce que la plateforme rejetterait la facture sans expliquer pourquoi. Le message invitait à régénérer le PDF — ce qui est le bon conseil, mais seulement si le générateur installé sait produire ce champ.

LemonFacturX ne l’émet que depuis sa version 3.0.0. En deçà, l’utilisateur régénérait indéfiniment le même document sans comprendre. Le module lit désormais la version installée à côté de lui et, si elle est trop ancienne, demande la mise à jour en nommant la version installée et celle qui est nécessaire.

2.0.1 (27 août 2026)

Un acompte n’échappe plus au statut « Encaissée ». La TVA sur un acompte est exigible à son encaissement quel que soit le régime de l’entreprise et quelle que soit la nature de ce qui est vendu — l’option pour la TVA sur les débits est écartée par un paiement reçu avant le débit, et ne peut de toute façon pas retarder l’exigibilité (art. 269-2-c du CGI).

Le module ne regardait que le type des lignes : un acompte sur une vente de biens ne déclenchait donc aucun statut « Encaissée », alors que la réglementation le rend obligatoire pour les prestations de services et les factures d’acompte. Sous option pour les débits, aucun acompte n’était déclaré du tout.

La règle vit à un seul endroit : la correction vaut aussi bien pour la déclaration automatique au règlement, pour le rattrapage périodique que pour l’envoi manuel depuis l’onglet Cycle de vie.

Le module dit pourquoi il ne déclarera pas d’encaissement. Quand une facture ne relève pas des données de paiement — vente de biens, ou option pour les débits — l’onglet Cycle de vie l’indique désormais à l’ouverture. Le message existait, mais seulement après un clic sur l’envoi manuel : celui qui attendait une déclaration automatique n’avait aucune explication et pouvait croire à une panne. La cause la plus fréquente est une prestation saisie comme un produit dans la fiche article, et le message le rappelle.

Une facture fournisseur supprimée ne laisse plus une réception muette. Supprimer une facture fournisseur créée depuis une facture reçue laissait la réception rattachée à un enregistrement disparu. La colonne « Facture fournisseur » restait vide sans rien dire, et l’on ne distinguait plus « pas encore importée » de « importée puis supprimée ».

La liste affiche maintenant « facture supprimée », et la réception est automatiquement détachée : elle repasse en « nouvelle », donc réimportable, avec la trace de ce qui s’est passé. Le cas se produit pour de bon — un comptable supprime une facture en brouillon sans savoir d’où elle vient.

2.0.0 (19 août 2026)

Ménage interne, sans effet visible mais pas sans conséquence. Le classement des statuts en colonnes existait en deux exemplaires qui se contredisaient, et comme la valeur enregistrée primait sur le calcul, chaque réactivation du module réinstallait une régression d’affichage corrigée le 14 août — figée en données cette fois. Une seule source désormais, et la rétro-alimentation qui la contredisait a disparu.

Les repères de synchronisation étaient écrits hors entité : deux sociétés d’une même instance auraient partagé le même curseur, les factures de l’une faisant sauter celles de l’autre. Ils sont par entité, avec reprise automatique de l’ancienne valeur — sans quoi la première passe après mise à jour aurait rebalayé tout l’historique.

Le critère qui définit une facture transmissible était recopié à quatre endroits ; il n’en a plus qu’un. Et deux actions restées d’anciens boutons ont été retirées, dont une qui permettait d’appeler la plateforme en boucle par une URL fabriquée à la main.

Le sort des déclarations d’e-reporting est remonté. Le module déposait transactions et paiements, marquait « Envoyée », et n’en reparlait jamais. Or c’est le lot constitué par la plateforme — par nature et par période — que le portail public accepte ou rejette, parfois longtemps après le dépôt. Une déclaration rejetée restait donc affichée comme transmise, et le rejet n’existait nulle part : la même cécité que sur les rejets de facture, sur le troisième et dernier flux. La synchronisation relit désormais ces lots, reporte leur sort sur chaque ligne concernée, l’affiche en rouge quand c’est un rejet, et fait échouer la tâche planifiée pour que ça se voie.

L’acheteur voit les réponses de son fournisseur. Le suivi des statuts ne regardait que les factures émises : un statut posé par le fournisseur sur une facture reçue n’était rattachable à rien et se retrouvait purement écarté, le curseur avançant par-dessus. Suspendre une facture revenait donc à parler dans le vide — la réponse prévue par la norme, « Complétée », n’arrivait jamais. Ces statuts sont désormais portés par la réception elle-même, dans une colonne distincte de celle qui garde nos propres émissions, tracés dans l’agenda de la facture fournisseur et affichés dans la liste. Seuls les statuts que la norme attribue à l’autre partie sont retenus : l’API renvoie aussi nos propres émissions, qui reviendraient sinon s’afficher comme des réponses.

Le commentaire du vendeur est transmis, lui aussi. Saisi dans l’onglet cycle de vie, il était conservé en local — l’utilisateur croyait l’avoir envoyé. Même correctif que celui appliqué au flux acheteur.

Un montant contesté est désormais qualifié. L’approbation partielle transmettait un montant sans dire ce qu’il représentait : la plateforme du vendeur ne pouvait pas savoir s’il s’agissait de la part approuvée ou de la part écartée. Une liste normalisée le précise, montant approuvé TTC par défaut.

Cinq étapes de transport Peppol s’affichaient en code brut : elles ont leur libellé. Et la devise d’une facture reçue est tronquée défensivement, comme le sont déjà le nom du fournisseur et le numéro de facture.

Le mode d’emploi rattrape le module. Six sections s’ajoutent à l’onglet « Mode d’emploi » de la configuration, dans l’ordre où on en a besoin : l’adresse à laquelle part une facture, quand l’encaissement est déclaré et quand il ne l’est pas, ce que signifie un rejet du portail public et le piège du renvoi sous le même numéro, le refus de repasser une facture déposée en brouillon, les quatre réponses possibles à une facture reçue avec l’obligation de motif normalisé, et pour finir ce que le module ne fait pas à votre place.

Ce dernier point mérite d’être lu : le module transporte et suit, il ne garantit pas que votre compte est bien réglé ni que vos dépôts sont acceptés. C’est à l’utilisateur de le vérifier.

Le paragraphe sur les rejets BR-FR-21 en bac à sable est daté d’août 2026 : la limitation a pu être levée depuis, le texte le dit désormais au lieu d’affirmer.

L’adresse de facturation électronique a son propre champ. Elle se saisissait jusqu’ici dans « Id. prof. 5 » du tiers — qui porte en France le numéro EORI, l’identifiant douanier. Le détournement n’était documenté nulle part : un client qui renseignait son EORI, usage parfaitement légitime, voyait son numéro de douane partir comme adresse de destination de ses factures. Mauvais destinataire, sans le moindre signal.

Un champ dédié apparaît sur la fiche tiers, « Adresse de facturation électronique ». À la mise à jour, les valeurs qui étaient bien des adresses — celles qui contiennent « : » ou « _ » — sont reprises automatiquement ; les numéros EORI restent où ils sont, intacts, et ne sont plus lus. Dans le doute, rien n’est déplacé : un EORI effacé serait pire que le mal.

Et la règle d’adressage, qui n’était écrite nulle part, l’est maintenant dans l’onglet « Mode d’emploi » de la configuration : adresse déduite du SIREN par défaut, champ dédié pour imposer autre chose, deux écritures acceptées, et l’absence de repli pour un client étranger.

Les rejets du PPF n’arrivaient jamais jusqu’à vous. La colonne qui stocke le code de statut d’un événement était limitée à 16 caractères. Or quatorze des quarante-trois codes de la plateforme sont plus longs — et ce sont exactement ceux qui portent les mauvaises nouvelles : « Flux 1 rejeté par PPF » en fait dix-neuf. MySQL, dans son réglage courant, ne raccourcit pas une valeur trop longue : il refuse la ligne. Les étapes rassurantes entraient donc, le rejet non. Une facture refusée par le portail public s’affichait comme transmise, avec le statut « Déposée » et rien d’autre. Le curseur de synchronisation s’avançant sans attendre l’enregistrement, l’événement perdu ne revenait jamais.

La colonne est élargie, les vingt-et-une étapes du dialogue avec le PPF ont un libellé — elles s’affichaient en clair technique — et un rejet fait maintenant virer le badge au rouge, ce qu’il ne faisait pas davantage. Trois autres colonnes de la même famille ont été élargies avant qu’elles ne mordent.

Surtout, la mécanique ne peut plus perdre en silence : un enregistrement refusé retient la synchronisation juste avant lui au lieu de l’enjamber, et le dit dans le résultat de la tâche planifiée. Elle piétine bruyamment plutôt que d’avancer en perdant les rejets en route.

L’encaissement se déclare selon la loi, plus selon une case. L’article 290 A du code général des impôts attend les données de paiement pour les prestations de services exigibles à l’encaissement, et pour elles seules : une vente de biens est exigible à la livraison, et sous option « TVA sur les débits » l’exigibilité repart à la facture. Le module envoyait le statut « Encaissée » pour tout, tout en laissant une case pour ne rien envoyer du tout — faux dans les deux sens. Il applique désormais la règle, en s’appuyant sur le régime de TVA de l’instance, et ne retient dans les montants déclarés que les lignes concernées. Sur une facture mixte, chaque règlement est ventilé au prorata du total réel. Le même filtre s’applique à l’e-reporting des paiements aux particuliers. La case subsiste en dérogation, avec ce qu’elle implique écrit en toutes lettres.

Un avoir qui solde une facture refusée ne part plus. Les spécifications l’interdisent : l’annulation comptable d’une facture refusée ou rejetée ne doit pas produire de données réglementaires. L’envoi automatique écarte maintenant ces avoirs-là, et eux seuls — un avoir commercial ordinaire part normalement.

Le retard de rattrapage est visible et rattrapable. Le module ne déclare jamais rétroactivement : les encaissements antérieurs à la mise en service ne partaient pas, sans que rien ne le signale. L’écran de traitement affiche désormais leur nombre et permet de les déclarer d’un geste délibéré.

Le régime de TVA du compte plateforme est relevé et comparé à celui de Dolibarr, avec un avertissement en cas d’écart. Il pilote le calendrier de transmission côté plateforme et n’était lu nulle part : un compte mal réglé ne se voyait pas.

Les statuts d’objet métier du portail (250, 251, 601) sont reconnus en lecture, distingués des statuts de facture qui portent les mêmes mots.

Le cycle de vie acheteur au complet, et les motifs pris dans la norme. L’écran des factures reçues n’offrait que deux gestes, Approuver et Refuser. La norme en prévoit quatre de plus, et leur absence se payait cher : faute de pouvoir approuver partiellement, il fallait refuser une facture pour une référence de commande manquante. Approbation partielle (fr:206), mise en litige (fr:207) et suspension (fr:208) sont désormais proposées.

Surtout, les gestes offerts dépendent de ce qui a déjà été émis. Une facture approuvée ne propose plus « Refuser » — on ne refuse pas ce qu’on a accepté, on le met en litige. L’ancien écran laissait faire, et la plateforme finissait par renvoyer une erreur que rien n’expliquait. La règle est appliquée aussi côté serveur : une URL fabriquée à la main ne passe pas.

Les codes motifs sont embarqués. Ils étaient à saisir à la main, ce qui donnait un rejet de la plateforme au moindre écart. Les 51 codes MDT-113 de l’annexe A v1.4 de la XP Z12-012 sont maintenant proposés en liste, filtrée selon le statut choisi — 13 codes pour une approbation partielle, 25 pour un litige, 13 pour un refus. Le piège est que « Refusée » a deux colonnes dans la norme, B2B et B2G, et qu’une reprise tierce répandue les fusionne : elle fait croire que AUTRE ou QUALITE_ERR valent pour un refus B2B, alors qu’ils relèvent du litige. C’est la colonne B2B qui est retenue ici, et la plateforme la confirme.

Le commentaire libre est transmis au fournisseur. Il était saisi, puis conservé en local seulement. Il est désormais transmis dans la note de statut (MDT-114), là où le fournisseur peut le lire. L’approbation partielle transmet en plus la donnée contestée — identifiant BT, valeur attendue, montant retenu — sans quoi « approuvée partiellement » n’apprend rien à celui qui la reçoit.

Côté vendeur, l’onglet Cycle de vie masque le champ motif pour les statuts qui n’en attendent pas, au lieu de proposer les 51 codes en vrac.

Corrections. L’écran « Traitement SuperPDP » tombait en page blanche : il appelait le bandeau bac à sable sans inclure la bibliothèque qui le définit. La configuration ré-enregistrait le secret de la plateforme à chaque affichage — le test « ce secret est-il en clair ? » portait sur la valeur déjà déchiffrée par Dolibarr, donc toujours vrai. Enfin, le verrou de démonstration ne protégeait que les identifiants de production : les identifiants de bac à sable sont désormais verrouillés eux aussi, à l’affichage comme à l’écriture.

Statuts de l’annexe v1.4 reconnus en lecture : fr:214 Visée, fr:220 Annulée, fr:221 ERREUR_ROUTAGE et fr:224 à fr:228 (affacturage) ne s’affichent plus comme des codes bruts. Ils ne sont pas encore émettables.

Un encaissement déclaré par règlement, plus un seul au solde. Une facture réglée en trois fois ne donnait qu’une déclaration fr:212, portant le montant total et datée du dernier versement. C’est faux pour qui est à la TVA sur les encaissements : l’exigibilité naît à chaque versement, à sa date et pour son montant. Le statut est d’ailleurs répétable au sens de la norme XP Z12-012.

Chaque règlement a désormais sa propre déclaration, avec sa quote-part ventilée par taux de TVA — le dernier taux absorbe le résidu d’arrondi, la somme déclarée vaut exactement l’encaissement. Rien à ressaisir : la déclaration est rattachée au règlement, donc un encaissement déjà déclaré ne repart jamais.

Le solde d’une facture part immédiatement, comme avant. Les encaissements partiels, eux, sont déclarés par la synchronisation automatique, dans le quart d’heure. C’est délibéré : enregistrer un règlement ne doit jamais attendre la plateforme, sous peine de bloquer la saisie — au comptoir en particulier.

L’écran de suivi ne bascule en « payée » qu’au solde réel de la facture : un acompte déclaré ne la fait plus passer pour réglée.

Rien n’est déclaré rétroactivement. Comme pour l’envoi automatique, une borne est posée à la première passe : les règlements enregistrés avant la mise à jour ne sont jamais déclarés tout seuls — une déclaration réglementaire rétroactive ne se décide pas à votre place. Le rattrapage manuel reste possible depuis l’onglet « Cycle de vie », et il déclare alors la facture entière.

Une facture déjà déposée ne peut plus être repassée en brouillon. Un numéro déposé auprès de la plateforme ne peut plus jamais être redéposé : le rouvrir, le corriger et le revalider produisait une facture qui ne correspondait plus à ce que la plateforme et le client avaient reçu, sans que rien ne le signale. Le module refuse maintenant l’opération et explique pourquoi — la correction passe par un avoir.

Le verrou ne se déclenche que sur un dépôt réel : tant que la facture n’est pas expédiée elle reste librement modifiable, et un envoi en bac à sable ne verrouille rien. Il se désactive dans la configuration du module.

1.9.0 (15 août 2026)

Le module vous prévient qu’une mise à jour existe. Le descripteur déclare url_last_version, le fichier de version publié sur hellolemon.fr. Dolibarr le lit et signale « nouvelle version disponible » dans la liste des modules, à condition que la vérification y soit activée ; la page de configuration du module, elle, affiche le bandeau sans rien avoir à activer.

Jusqu’ici aucune instance ne pouvait apprendre qu’une version plus récente était sortie : ni Dolibarr ni le DoliStore n’interrogent quoi que ce soit d’eux-mêmes.

Le contrôle de version ne passe plus par GitHub. Les dépôts sont privés, l’appel à l’API des releases ne pouvait plus aboutir. Le bandeau lit maintenant le même fichier que Dolibarr. Toujours un seul appel réseau sortant pour cette vérification, mis en cache 24 h, échecs compris.

Ce fichier de notes de version, et l’onglet qui l’affiche, jusque-là vide.

1.8.0 (14 août 2026)

Activer et désactiver le module ne perd plus rien. remove() sauvegarde désormais toutes les constantes du module dans documents/ avant de rendre la main, et init() restaure celles qui manquent sans écraser ce qui existe. Les constantes à valeur saisie ne sont plus déclarées au descripteur, qui les réinitialisait à chaque bascule.

L’onglet de cycle de vie dit qui parle. Les statuts fr:200 à fr:203 s’affichent dans la colonne SuperPDP, et chaque colonne indique son émetteur — vous, SuperPDP, ou votre client. Une facture soldée affiche un message d’état final propre au lieu d’évoquer un refus.

1.7.1 (3 août 2026)

Le rapprochement des tiers à la réception n’avait jamais fonctionné : corrigé. Ajout d’une garde sur le BT-23 (une facture qui en manque est rejetée par la plateforme avec un message opaque) et d’une mémoire de quarantaine. Portabilité PostgreSQL (IFNULL → COALESCE, verrou OAuth portable). Retrait de l’affectation catalogue, qui n’avait jamais été livrée.

1.6.4 (30 juillet 2026)

Exemples d’adresses électroniques inventés retirés de l’aide du bac à sable. AFRelationship positionné à « Alternative » sur les PDF réinjectés (signalé par un client).

1.6.3 (30 juillet 2026)

Une substitution inopérante du bac à sable passait silencieusement : elle est maintenant détectée et signalée (signalé par un client).

1.6.2 (28 juillet 2026)

L’encaissement est déclaré même quand la facture était payée avant d’être transmise — le statut fr:212 n’était émis que dans l’autre ordre. Nouvelle option « Déclarer l’encaissement à la plateforme », active par défaut. Bandeau d’état SuperPDP directement sur la fiche facture, sans ouvrir l’onglet. Les événements ppf:* sont rangés côté plateforme et non plus côté client.

1.6.1 (24 juillet 2026)

Le PDF Factur-X produit par un module tiers est maintenant trouvé à l’envoi (signalé en production). Documentation du mode délégation : enregistrement de l’URL de redirection côté holding, section dédiée dans l’onglet Aide.

1.6.0 (22 juillet 2026)

Mode délégation : authentification OAuth en Authorization Code, pour gérer plusieurs sociétés à travers le tunnel SuperPDP. Cycle de vie du jeton de rafraîchissement durci.

1.5.1 (22 juillet 2026)

Bac à sable : le BT-49 est rendu cohérent avec le BT-47 fictif, ce qui corrige un rejet BR-FR-21.

1.5.0 (18 juillet 2026)

Envoyer depuis la liste des factures, à la ligne ou en lot, avec une colonne « SUPER PDP » triable indiquant le statut ou le reste à envoyer, et l’action de masse native de Dolibarr. Envoi automatique par tâche planifiée, en marche avant uniquement : le cron ne revient jamais sur des factures antérieures à son activation. Onglet « Aide » intégré, réglages réorganisés en sections, menus « Traitement ».

1.4.2 (9 juillet 2026)

Durcissement et confort, à la lumière de l’analyse du module officiel e-invoicing.

1.4.1 (9 juillet 2026)

LemonFacturX n’est plus une dépendance dure. Le module transporte tout Factur-X valide embarqué dans la facture, quel que soit l’outil qui l’a produit.

1.4.0 (8 juillet 2026)

Confort d’exploitation : bouton « Rafraîchir », notification par courriel à la réception d’une facture fournisseur.

1.3.0 (3 juillet 2026)

Cycle de vie aligné sur la norme XP Z12-012, édition juin 2026.

1.2.3 (1er juillet 2026)

Correctif d’empaquetage sur l’onglet de cycle de vie (séquence d’inclusion).

1.2.2 (1er juillet 2026)

Sécurité : secrets chiffrés en base, isolation multi-entité, TLS, droits.

1.2.1 (1er juillet 2026)

Injection du BT-49, renvoi forcé, migration des flux vers fr:212, action manuelle sur les statuts. Correction d’un enregistrement qui ne pouvait ni effacer les champs vidables ni conserver le format transmis.

1.2.0 (25 juin 2026)

Onglet « Facturation électronique » sur la facture : la frise du cycle de vie. Manifeste dmm.json pour l’installation et la mise à jour en un clic via DoliModuleManager.

1.1.0 (11 juin 2026)

Bouton « Créer le tiers et importer » sur les factures reçues mises en quarantaine faute de tiers correspondant.

1.0.1 (11 juin 2026)

La détection d’un client non assujetti retient le type Particulier ou l’indicateur « Assujetti à la TVA » à Non.

1.0.0 (11 juin 2026)

Première version stable, couvrant tout le périmètre de la réforme : émission unitaire et en lot, réception des factures fournisseurs, cycle de vie côté acheteur, import manuel, pré-contrôle de l’annuaire et e-reporting B2C.

0.4.0 (11 juin 2026)

Import des factures fournisseurs reçues via SUPER PDP.

0.3.0 (4 mai 2026)

Transmission bloquée pour les factures adressées à des particuliers. Contrôle de cohérence entre le SIREN de la société et celui de l’application OAuth, au test de connexion comme au diagnostic. Migration de l’identifiant de module vers la plage officielle Lemon (210009).

0.2.1 (24 avril 2026)

Documentation.

0.2.0 (24 avril 2026)

Événements SUPER PDP poussés dans l’agenda de la facture. Récupération automatique d’une transmission déjà rattachée à la facture. Validation de l’adresse du point d’accès en HTTPS, correction d’une divulgation de chemin.