Bonjour,
j’ai soulevé un problème sur l’immuabilité des factures dans ce fil
Selon moi Dolibarr ne garantit pas l’intégrité des données des factures, et il me semble donc difficile de pouvoir émettre un certificat de conformité.
1 « J'aime »
Bonjour FHenry,
Merci pour votre réponse.
Dans ce cas, qui pourrait me transmettre une certification de conformité à moi même puisque c’est moi qui installe mon propre dolibarr ? (ce serait un comble que je doive passer par un prestataire externe qui réaliserait le même travail que celui que je fais pour mes propres clients)
Bonjour @hop
Oui mais dans la « blockchain » du module log inaltérable il y a aura la trace.
- condition d’inaltérabilité : le logiciel utilisé doit permettre d’enregistrer toutes données relatives aux règlements sans qu’elles puissent être altérées
- condition d’archivage : le logiciel doit prévoir une période d’archivage où les données sont figées et datées avec un dispositif technique garantissant l’intégrité des informations.
Dolibarr réponds à ces obligations avec les log inaltérables, « l’immuabilité des factures » n’est pas une des clauses requises
@Jeff351
Ce que dit ce site qui est gouv.fr :
Concernant les logiciels multifonctions (comptabilité/gestion/caisse), seules les fonctions caisse enregistreuse/encaissement, et non l’ensemble du logiciel, devront être certifiées.
Je ne suis pas juriste, mais cela ne semble concerner que les encaissements réalisés a partir de la caisse. Est-ce vraiment le cas ? C’est votre cas ? Vous encaissez des particulier avec la caisse de Dolibarr ?
Non justement, cela permet de modifier la facture sans aucune trace dans les logs inaltérables.
On peut également modifier le destinataire d’une facture en modifiant simplement le contact facturation sans laisser de trace dans les logs inaltérables.
Les logs inaltérables sont défaillants sur ces points, donc il ne garantissent rien.
Bonjour,
une assez bonne solution pourrait être d’inclure le document généré (pdf) dans le journal inaltérable.
Cela augmenterait considérablement l’espace de stockage requis mais permettrait une conformité totale (également dans d’autres pays, par exemple en Allemagne, où la représentation optique de la facture, c’est-à-dire le pdf, doit être archivée de manière inaltérable).
2 « J'aime »
@hop,
biensur qu’il y a bien la trace de modification dans les Journaux Inaltérables, on voi bien d’ailleurs que la facture à été validé 2 fois, si il y a justification en cas de contrôle pas de pb.
L’important c’est la traçabilité et la traçabilité est inaltérable (dans le sens inaltérable avec l’interface web de Dolibarr, par ce que si on sais faire, on peux trafiquer la table et recalculé le hash de la blockchain, c’est pour cela l’état dit qu’on ne peux pas s’auto certifier).
@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…
