J’ai découvert récemment que Dolibarr ne garantit pas l’immuabilité des factures validées. C’est à dire qu’une facture validée, sur laquelle on ne fait aucune action peut être modifiée sans trace dans les logs inaltérables.
Le problème vient du fait qu’une mise à jour d’un produit au niveau de sa référence ou de son libellé va se répercuter sur toutes les factures qui ont une ligne avec ce produit.
Si j’ai vendu 10 bananes sur une facture et que je modifie la fiche produit en changeant banane pour pomme, je me retrouve avec une facture de vente de 10 pommes.
Cela pose selon moi un gros problème de fiabilité de Dolibarr au niveau des factures.
Normalement ça change uniquement à l’affichage du card.php, mais le PDF qui est le document officiel, lui n’est pas régénéré et reste bien en « bannane »
Je précise que ce changement ne bip pas au niveau de l’inaltération des logs car les bonnes valeurs ne changent pas dans les tables de la factures, mais dans les fait, à la génération d’une nouvelle facture elle est bien modifiée!!!
J’avais déjà relevé le soucis en proposant un correctif qui n’a pas été accepté à l’époque…
On conserve pourtant la ref, le libellé, le montant et la valeur du produit mais on ne s’en sert pas pour la génération du pdf,
Il n’y a pas qu’au niveau des lignes de détails que cela pose problème, mais aussi l’adresse du client, ou du contact…
Pas tant que ça, j’ai aussi ouvert un bug à ce sujet … sans suite, je n’ai pas été jusqu’à faire une PR mais par contre je me suis noté ça comme « big fail » du point de vue conceptuel de dolibarr …
@erics comment ça se passe au niveau de ton module factur X si on change la référence sur la fiche produit ou carrément le numéro SIRET de l’entité facturée ?
Et « big fail » c’est effectivement le bon terme ici.
A priori, rien a changé. Je pense que le seul moyen de modifier le workflow est d’enregistrer dans la table facture les lignes telles qu’elles ont été établies puis de demander à l’utilisateur si les changements éventuels doivent être propoager dans le passé.
Mais c’est pas un dev surlequel j’ai envie de me lancer. désolê
Pour ma part je vais bloquer la possibilité de modifier la référence ou l’intitulé d’un produit si celui-ci est présent dans une facture.
Pour faire référence à un autre fil de discussion , Prestashop gère très bien ce cas de figure, la modification d’un produit n’entraine aucune modification sur les commandes ou factures existantes.
Il y a une autre solution possible c’est d’avoir un historique des versions des produits.
Il faudrait créer un nouvel enregistrement produit à chaque modification, donc un nouvel id en BDD, avec une unicité sur l’id et le numéro de version.
De cette manière la liaison fk_product renvoie sur la bonne version du produit, et on ne garde « utilisable » sur les commandes/factures etc que la dernière version d’un produit.
Cela me semble plus simple à mettre en oeuvre que d’enregistrer dans toutes les tables concernées la ligne produit (propal, commande, facture etc)
mmmmm ça risque de provoquer d’autres effets de bords, c’est un point vraiment délicat qu’il faut analyser proprement et pourquoi pas s’inspirer de ce qui se fait dans d’autres projets … same problem same solution ?
je t’arrête, il y a déjà les champs nécessaire dans les tables des lignes de factures pour gérer cela, juste que l’on ne les utilise pas.
Il faudra sans doute pour être plus en règle en faire de meme avec les informations du tiers (voir meme de la société…),
Bref, toutes les informations nécessaires à la constitution de la facture, doivent se trouver uniquement sur la table llx_facture et llx_facturedet, sinon la log inaltérable ne sert à rien…
Cela ne concerne pas que les factures, tout enregistrement qui fait référence à un produit est concerné.
Il faut par exemple que dans le workflow qu’une propal qu’on transforme en commande qu’on transforme ensuite en facture, puis éventuellement en avoir on garde l’information du produit telle qu’elle était dans la propal.
La solution radicale c’est qu’une fois qu’un produit est référencé quelque part on empêche sa modification au niveau de certains champs (référence, libellé…).
Il suffit alors de créer un nouveau produit si on veut changer le libellé par exemple. La seule chose qui bloque c’est l’impossibilité d’avoir deux produits avec la même référence. D’où l’idée de la gestion de la version sur le produit.
NB: c’est une piste de réflexion, pas une solution miracle
Je parle du produit en lui même. C’est a dire que les infos du produit (ref, libellé) de la propal restent identiques sur la la commande, facture etc
Rien n’empêche de modifier la commande et de changer le produit par la nouvelle version.
En fait rien ne change vraiment par rapport au fonctionnement actuel, on forcerait juste la création d’un nouveau produit si on veut modifier des données « critiques » tel que la référence ou le libellé.
Sauf que - par exemple - la gestion du stock va se retrouver sacrément impactée par cette approche c’est ce que je soulevait par « les effets de bords » mais aussi les stats de ventes par produits etc.
De mon point de vue: j’ai une base article, je pioche un article, l’ensemble des données textuelles est copiée dans la table (devis|commande|facture|objet en cours). Je peux changer le libellé ou le texte du produit ça reste local à l’objet en cours.
Si je vais changer un article rien n’est modifié ailleurs que dans la base article. Et humainement parlant il n’y a QUE des développeurs pour imaginer que ça aille changer quoi que ce soit ailleurs.
L’image qui me vient en tête c’est comme si dans le monde physique le changement d’une étiquette dans l’entrepôt au niveau du stock 2024 puisse aller modifier la ligne du produit concerné dans tous les devis qui ont été établis en 2023 …
À la limite on pourrait proposer un bouton « propager la modification à l’ensemble des objets liés » mais ça serait uniquement pour les brouillons en cours, en aucun cas un document qui peut avoir été communiqué à des tiers, archivé, pdf généré, basculé en compta où je ne sait quoi d’autre.
, Prestashop gère très bien ce cas de figure, la modification d’un produit n’entraine aucune modification sur les commandes ou factures existantes.
