Bonjour à toutes et tous,
Merci de m’avoir répondu !
JBPhenix > Si le tarif d’un produit évolue, dolibarr prend en compte de l’évolution du prix en spécifiant les dates. Votre méthode de fonctionnement est incompréhensible.
C’est plus qu’un tarif qui évolue, c’est 250 produits qui disparaissent, 325 créés, etc. Ensuite (prenons dans cette réponse le cas d’une facture directe avec une ligne produit), il suffit que le produit soit recopié dans une ligne de la facture sans conserver de référence avec la table des produits. C’est, je le crains, conserver à vie des produits dans une table qui est juste incompréhensible.
JBPhenix > D’un point de vue informatique, Supprimer des données dans une db c’est la meilleur occasion pour se retrouver avec des effets de bord de tous les cotés.
Pas du tout, si l’application est conçue en ce sens. Une application de gestion vit. Ses données aussi. Certaines arrivent, d’autres sont modifiées et d’autres encore disparaissent. C’est d’autant plus vrai pour une application susceptible d’accompagner l’entreprise durant toute sa vie.
manunord > On ne supprime pas des données qui ont été utilisées.
À partir du moment où le produit a été inséré dans une ligne de facture, cette ligne devrait devenir indépendante de la table des produits/services, sinon on part effectivement dans une conservation ad vitam æternam.
manunord > Et attention à votre fusion d’utilisateur, il faut une sécurité sur les factures et autres documents à conserver.
Merci pour cette remarque. Pour la NFC-525 et l’inaltérabilité des documents, llx_blockedlog n’est pas contrôlée par la routine d’interdiction d’effacement des utilisateurs. En d’autres termes, l’utilisateur fusionné existe encore dans ces tables. Rien n’est touché. Son index est juste inexistant ou faux (index réaffecté). Et c’est sans importance dans ce contexte car le nom de l’utilisateur est inscrit en clair dans chaque ligne. La traçabilité est sauve (bien joué).
defrance > oui j’ai l’impression qu’il y a confusion entre la table llx_product et la llx_product_price qui contient l’évolution des prix des produits.
Non hélas pas de confusion. Qu’il y ait une table d’évolution des prix est une fonctionnalité utile au moment de l’insertion du produit dans la facture. Qu’une liaison soit maintenue entre des lignes de factures (qui semblent recopier les données issues du produit - je n’ai pas vérifié colonne par colonne) et la table des produits est décision d’architecture qui est limitative.
Si EBP, SAGE ou tous les logiciels de gestion que j’ai pu coder fonctionnaient comme Dolibarr, on ne pourrait pas gérer des catalogues produits volumineux (20K, 50, 100K références) sans cesse refondus, ce qui est le cas dans la plupart des activités de vente… ou d’achats d’ailleurs. Le cas typique étant l’insertion d’énormes tableaux excel en provenance de différents fournisseurs avec des références qui changent sans arrêt. La vraie vie quoi. Et moi, ça m’embête car je rate des placements de Dolibarr à cause de ça… 
C’est d’autant plus rageant qu’avec la compta en partie double, son module de génération XML de prélèvements SEPA et toutes les goodies qu’il contient, Dolibarr n’a plus grand chose à envier aux bidules commerciaux désormais transformés en SAAS bien juteux.
Bon, on va réfléchir à faire autrement, et sans toucher au core de Dolibarr, ni chercher le plugin miracle qui n’existe pas, ni chercher à l’écrire car la prochaine version de core nécessitera de changer plein de trucs.
Bien cordialement à toutes et tous,
Stéphane
