Bonjour, @hop j’ai un peu creusé la question sur différents aspects … ça demande bien sur à être re-vérifié mais …
a) au niveau purement réglementaire pour les logiciels de caisses il me semble qu’il faut uniquement garder une trace inaltérable des encaissements, peu importe ce qui a été encaissé ce qui compte c’est le montant TTC/HT/TVA
b) dans la table des logs inaltérable se trouve en plus un champ object_data qui contient sous forme sérialisée l’objet de la transaction … qui fini par faire une table très lourde au final pour les entreprises qui ont beaucoup de transactions
donc oui notre lecture du mot « inaltérable » et notre référence à l’idée qu’on s’en fait m’a laissé penser à un « big fail » mais finalement pas tant que ça pour la partie logiciel de caisse.
Cela passe peut être au niveau réglementaire si on utilise Dolibarr en tant que logiciel de caisse.
Mais le problème de fond reste que la modification d’un produit entraine la modification des factures de manière rétroactive. Enfin bientôt ça ne sera plus un problème on a décidé d’abandonner Dolibarr dans notre structure.
Il y a plusieurs raisons qui nous font abandonner Dolibarr, mais la modification rétroactive des factures et autres documents qui contiennent des liaisons avec les produits ou les tiers ça a définitivement scellé son sort et accéléré son abandon.
Dans les autres raisons on a entre autre :
pas de distinction entre les droits création et modification (ça ne correspond pas aux responsabilités des salariés qui utilisent Dolibarr)
pas de stockage à distance des pièces jointes (protocole S3 ou autre)
une gestion du code source qui nous interroge (commits sans PR, PR dont les tests automatisés échouent mais qui sont mergées quand même…)
Sur quoi on va passer ? Sur une solution développée en interne, on a besoin que de la partie commerciale (propale, commande, factures clients, factures fournisseurs), la production, le stock, les expéditions sont déjà gérées par des solutions développées en interne.
On a grosso modo terminé le développement d’une solution headless avec Symfony + API platform en deux mois à deux personnes. C’est finalement assez simple et facile à faire, en partant du principe qu’une propale, une commande, une facture etc c’est exactement la même chose, il n’y a que le nom qui change. Cela se résume en une table « object », une table « object_line », des tables de liaisons et quelques tables annexes (tiers, produit, paiement…)
Un front est en cours de dev avec vue.js
Je me suis aussi interrogé sur le coté respect de la loi, mais finalement il n’en est rien, et cela pour ces raisons en provenance du site indiqué plus haut dans le fil :
Les exceptions
Certains professionnels ne sont pas soumis à l’obligation de certification :
professionnels réalisant uniquement des opérations commerciales avec d’autres professionnels (B to B)
professionnels réalisant exclusivement des opérations exonérées de TVA
professionnels bénéficiant de la franchise en base de TVA (notamment les micro-entrepreneurs)
professionnels bénéficiant du régime de remboursement forfaitaire de TVA agricole
entreprises dont l'intégralité des paiements est réalisée avec l'intermédiation directe d’un établissement de crédit.
Étant dans la case B to B (même si 1% de mon chiffre peut être fait avec du particulier, mais c’est tellement anecdotique …)
Cependant, je vais demandé la certification, il se peut que je fasse des installations pour quelques clients qui pourraient finalement en avoir besoin.
En tout cas, pour rebondir sur ta peur de changement de produit ou client, le problème aux yeux de l’état (pour la FRANCE), c’est la fraude à la TVA, et changer le nom du client ou du produit n’aura aucun impact sur le montant de la TVA à leur payer
Bonjour
Sauf que pouvoir changer le tiers voir le produit d’une facture permet de refiler une facture bidon x fois aux clients tout ça san altérer les logs. Et donc d’encaisser en douce x fois en espèces bien sûr (c’est du vécu)
Quand le logiciel le permet c’est ennuyeux !
Il faut impérativement que ça ne puisse pas se faire.
@+
Sur le fond, je suis totalement d’accord, il ne faut pas que l’on puisse modifier en quoi que ce soit la facture.
Cependant, on parle d’échange en B2B. Car en contrôlant l’entreprise qui reçoit le paiement, ils leur est facile de mettre en lumière ce type de fraude.
Il existe sûrement plein de façons de frauder. On ne les connaît pas toutes. Mais aux yeux de la loi, ce qu’ils regardent pour le cas des règlements en B2C, c’est qu’on ne puisse pas modifier le contenu d’une facture, histoire de faire disparaître des lignes et détourner de l’argent. Et à terme, payer moins de TVA.
De toute façon, ça ne fera jamais de mal à Dolibarr d’augmenter la sécurité sur les logs inaltérables .
Le problème dans mon cas ce n’est pas le fait de pouvoir frauder ou non.
Le gros problème c’est que le changement d’une référence d’un produit va modifier toutes les factures, et fausser toutes les statistiques.
Quand on se retrouve avec des ventes en 2022 d’un produit qui n’a été commercialisé qu’en 2024 ça ne fait pas vraiment sérieux sur les rapports…
@hop Ôte moi d’un doute, normalement ce genre de chose n’est possible que en SQL?
Sinon, il faut annuler le règlement, modifier la facture, modifier la ligne de facture et valider de nouveau etc …
Comment ce fait-il que tu ai un soucis sur ce point ?
C’est que j’essaye de comprendre, c’est au cas ou j’aurai un problème similaire.
Quand on modifie la référence d’un produit dans Dolibarr cela va modifier l’ensemble des factures, commandes, propales… déjà existantes qui contiennent ce produit.
@stefkpl pour simplifier, dans la table qui stocke un document comptable « définitif » (ou "final) il ne faudrait plus avoir de clé étrangère vers des données stockées dans une autre table mais uniquement des données dupliquées à l’instant où le document est généré.
(et ne pas considérer le PDF comme seul « document final »)
C’est valable pour les lignes d’articles comme pour les coordonnées du client.
Ok, je comprends mieux, effectivement, j’avais pensé naïvement qu’il n’y avait pas de liaison mais bien une image à l’instant T de la création du document.
J’ai codé il y a un temps certain une gescom en Delphi et j’ai repris un dev en depuis plusieurs année PHP, qui a le même soucis que présentement., je comprends vraiment mieux.
Effectivement @hop c’est un vrai problème.
C’est corrigeable, ce n’est pas si grave, ce qui m’étonne c’est vu la maturité de Dolibarr, pourquoi personne n’a fait remonter ça avant ?
Et oui, même avec les log, ça n’évite pas le problème. Ce qui est rassurant, c’est que les prix/quantité sont bien persisté en base, mais ça n’est pas suffisant.
Courage à tous ceux qui vont remettre le nez dans le code …
À mon avis ça n’a pas été présenté de telles sortes que ça soit un problème « évident » avec des grosses conséquences potentielles … pour ma part lorsque j’ai mis le doigt dessus c’était sur un « use case » qui n’a pas parlé à @eldy (voir Update product label on propal/invoice/aso · Issue #23611 · Dolibarr/dolibarr · GitHub) et qui lui semblait même être une anti-fonctionnalité
« if we update a label of a product (typo error for example), it is propagated everywhere with no need to change all documents »
Mais à mon avis il est probable qu’avec les nouveaux arguments que nous avons entre les mains une nouvelle proposition d’amélioration argumentée serait vue de manière plus positive …
Ce qui peut nous sembler évident ne l’est pas toujours et avoir beaucoup de points de vues différents (et souvent contradictoires) nous oblige à aller au fond des choses pour trouver des arguments solides. C’est en ce sens que j’aime le forum et les ressources publiques qui permettent de retrouver des traces de pourquoi une décision a été prise, dans quel contexte, pour corriger quel problème et qui potentiellement apporte aussi son lot de bugs auxquels nous n’avions pas forcément pensés !
Ceci est normal.
Par définition les log inaltérables sont inaltérables. Quand une facture est validée, tout son contenu est sauvé en photo. Si tu change la référence d’un produit de A en B, cela n’aura aucun impact dans tes log inaltérables. Le produit dans la log inaltérable restera A. C’est ce qui est voulu.
Note qu’il peut y avoir plusieurs libellé, plusieurs descriptions aussi d’un produit, qui dépendra de la langue d’émission de la facture. Aussi la log inaltérable ne stocke pas les libellés ni description (on est pas tenu de le faire d’ailleurs. Rappelons que la loi finance a pour but de tracer de manière inaltérable les paiements, montant, taux de tva et dates non les factures qui ne sont pas dans le périmètre. Dolibarr a ajouté aussi des log inaltérables sur les factures, mais cela va au dela de la loi. L’idée étant: « Qui peut faire plus peut faire moins »).
Bref, si tu la change ton produit en B et que tu regénère le PDF, le PDF aura un contenu différent de la première version validée. Mais la log inaltérable contiendra toujours la valeur d’origine dans la trace de validation. Un controleur sera donc en droit de te demander pourquoi dans la trace de la facture validée, il y a le code A et dans la trace de réimpression le code B. A toi d’expliquer l’origine de la faute que tu voulais corriger en corrigeant ta ref de produit. Car dans la log inaltérable, ni A ni B ne sont modifiable, meme si tu change ensuite en C. C’est ce qui est attendu.
Une appli de gestion a parfaitement le droit de faire l’objet de correction sur ses documents (sous certaines conditions), la log inaltérable (dédié au paiement) non. Voila pourquoi le produit restera avec la ref produit A au niveau de la log inaltérable. Si tu changes les traductions de tes libellés ou descriptions après coup et que tu regénères le PDF, la log inaltérable aura alors 2 entrées. Une premier pour validation de facture avec la ref A et les infos du produit A au moment de la validation, et enfin une entrée montrant que tu as regénérer ou réimprimer le PDF, et cette fois il y aura l’infos comme quoi la ref est devenu B (si tu as modifié la ref j’entend). Si tu as juste modifié les descriptions, rien n’apparaitra de particulier car les descriptions propre à ton appli de gestion ne sont pas tracés par la log inaltérable (hors périmètre qui doit se limiter au traces de paiement).
que la loi de finance bloque les paiements c’est une chose, mais si je dis à un client ou a mon comptable que j’ai changé le libellé des produits, ses coordonnées, ou les miennes, c’est limite comme modifier un contrat après sa signature…
Je comprend ta logique mais il me semble que ce genre de chose devrait être tracé ou du moins limité par habilitation, mais en tout cas conserver au niveau de la facture les infos qui servent à générer le pdf.
Idéallement il faudrait des fonctions de versionnements. Car ce besoin de versionnement est vrai pour toutes les infos, pas seulement un libellé de produit, mais aussi sa description, son code comptable, son code douane, son pays d’origine, etc… Actuellement Dolibarr ne sait pas encore faire de versionnement. Il y a quelques modules externes qui le permettent en attendant.
A défaut, il est tout a fait possible d’intégrer certaines de ces infos dans la log inaltérable aussi.
Le versioning et la modification des factures sans y toucher, ce sont deux choses différentes,
Là on parle de modifier un élément externe à la facture et que si on a la mauvaise idée de générer à nouveau le pdf, il y a altération de celui-ci
Je suis assez basique dans cette logique mais pour moi, TOUTE les infos présentes dans la facture devraient se retrouver au niveau de la table llx_facture et llx_facturedet et ne pas être modifiable sans doits avancé (et tracé).
