historique des adhésions / cotisations modifiées lorsque le type de membre change

[daraelmin]

J'imagine que le souci est le même avec le module originel, mais il a plus d'impact dans adherentplus car dans votre module, les cotisations sont plus intiment liée au de type membre.

Dans adherentplus, on peut "lier" le type d'adhérent au prix de la cotisation, c'est parfait. Cependant, lorsque le membre change de type, par exemple, s'il devient retraité, passe de "animateur" à "professionnel", etc. L'ensemble de son historique est modifié. Du moins dans le tableau affiché dans l'onglet "adhésion" de sa fiche membre.

En soit, ça ne pose pas de problème de comptabilité puique la somme reste la même, mais, pour des raisons statistiques, c'est génant.

Idéalement, il faudrait pouvoir conservé le type de membre dans la cotisation et/ou l'affichée comme tel.

[ptibogxiv]

Désolé mais je viens tester cela est fonctionnel, comme les autres soucis, il y a bien un soucis dans votre installation, l'historique ne change pas dans mes installation de test et live

[ptibogxiv]

a tester ici https://dolidemo.ptibogxiv.net/

[daraelmin]

Après inspection, dans la base de donnée, la table subscription semble conservé le type de membre dans la colonne fk_type, il s'agit donc juste d'un problème d'affichage.

Je suggère de modifier simplement dans la ligne 693 dans e fichier adherentsplus/subscription.php comme suit. Original : $sql = "SELECT d.rowid, d.firstname, d.lastname, d.societe, d.fk_adherent_type as type,"; Proposition: $sql = "SELECT d.rowid, d.firstname, d.lastname, d.societe, d.fk_adherent_type, c.fk_type as type,";

Comme je n'ai pas eu le temps de voir si, dans la requête, le d.fk_adherent_type, à son importance, je l'ai laissé, mais c'est le c.fk_type qu'il faut stocker dans "Type" pour qu'il figure comme tel dans le tableau de paramètre php et donc dans le tableau

[ptibogxiv]

@daraelmin par contre si vous veniez d'-une version avant la v11 et sans adhérentsplus l'historique des types d'adhésions n'etait pas sauvegardé d'où cette affichage etrange (la seule solution est d'intervenir en base pour réattribuer un type a toutes vos cotisations deja enregistrées)

[daraelmin]

Effectivement, je dois réimporter l'historique des types de cotisations une fois votre module installé pour le visualiser, mais même lorsque je le fais (testé avec un seul membre), il ne s'affiche pas.

C'est le type du mebre qui prend le dessus. D'où le problème soulevé. C'est logique puisque la requete sql stocke le type de membre depuis la table adherent.

Avec la modif que je propose,le problème est résolu car effectivement, ce n'est qu'un souci d'affichage

[ptibogxiv]

mais ça c'est le fonctionnement du core et je n'ai pas le soucis, il doit persister un problème ou du cache serveur car dans le code en dessous justement si il n'y a pas de type lié a l'adhésion c'est le type de l'adhérent qui s'affiche

[daraelmin]

Ah ok, je comprends mieux le problème.

C'est une différence de conception: perso, je préfère ne rien afficher dans le doute, mais comme tout le monde n'utilise pas votre module, il faut afficher le type d'adhérent lorsqu'il n'y a rien.

Néanmoins, cela ne vaudrait-il pas le coup de modifier le subscription.php dans votre module ?

Il me semble préférable d'afficher qu'on ne sait pas pour certaines cotisations, car, puisque normalement tout est stocké, on sait, cela donne une mauvaise vision de la situation d'une personne, mais je ne sais pas quels sont les mécanismes cachés.

De notre point de vue, pour des questions juridiques et d'assurances, l'historique est particulièrement important. Il nous faut savoir si les mebres étaient couvert jusqu'à 10 ans en arrière. Si on ne voit rien, on va chercher dans les dossiers papiers archivés, mais si on voit qqch, on risque de se dire que c'est vrai, surtout un utilisateur lambda.

C'est trop risqué dans mon cas.

[ptibogxiv]

Je comprend mais c'est un bout de code que je synchronise avec le module de base, je ne laisse différent que les choses non encore intégrées dans le core (plus facile à maintenir niveau compatibilité et sécurité). mon module à vocation a disparaitre quand tout sera dans le module de base ce qui prend du temps pour intégrer tous les modeles d'association qui ont des cotisations selon plein de procédés.. Ce module complémentaire permet simplement l'ajout/modification plus rapidement d'ou l'importance de la numérotation du module qui doit être la meme que le core pour raison de compatibilité

[daraelmin]

Ok, merci pour les explications

[daraelmin]

J'ai proposé un dix qui a été accepté dans la V13. Il est bien pris en compte dans le module adhérent officiel, mais lorsqu'on active adhérentplus, on revient à l'ancienne interface.

https://github.com/Dolibarr/dolibarr/pull/14747#issue-487544663

[ptibogxiv]

Il faut donc que je pousse cela dans ma surcharge de page

[daraelmin]

Top

[ptibogxiv]

mis à jour et je vous ai fait le changement dans votre dolibarr