@FHenry
il n’y aucune trace dans les logs inaltérables lorsque l’on modifie l’intitulé ou la référence d’un produit. Cela modifie l’ensemble des factures qui utilisent ce produit.
Il en est de même lorsque l’on modifie un tiers, la facture est modifiée sans aucune trace.
Aucune action n’est nécessaire sur la facture pour qu’elle soit modifiée.
Preuve en images, la facture est passée de la société A à la société B, et le produit de Whisky à Jus de pomme sans aucune trace dans les logs inaltérables
1 « J'aime »
en un mot « big fail » … je n’avais pas été jusqu’à parler des logs inaltérables ici mais c’était bien le fond de la surprise …
1 « J'aime »
Bonjour
Un petit up sur ce sujet qui montre le côté faillible des logs. Je sais bien que rien n’est infaillible ce n’est pas le sujet de la discussion. Le souci est que c’est un peu facile.
Pour éviter cette faille, ne pourrait on pas intégrer dans les calculs de clefs un hash du nom du client, les hash des noms de produits.
Changer les noms ensuite changerait forcément la clef finale ?
Quoi d’autres ajouter ?
Bon dimanche à tous…
@+
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.
1 « J'aime »
Bonjour,
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.
Hello @hop
C’était l’unique objectif de ce dev : proposer une conformité par rapport à la réglementation des logiciels de caisse 
Le ticket reste ouvert et je pense qu’il y aura des évolutions en ce sens ça me semble impossible autrement
dommage, vos contributions en particulier sur le forum vont nous manquer !
1 « J'aime »
On bascule en janvier 2025, il faudra me supporter encore un peu 
Dommage ! Sur quoi allez vous passer si on peut le dire et quels manques ?
@+
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
1 « J'aime »
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.
Voir mon message précédent :
@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 …
C’est remonté depuis plusieurs années, et à ma connaissance les correctifs proposés ont été refusés. Va comprendre Charles…
À 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 !
