Garradin est un logiciel libre de gestion d’association développé depuis sept ans. Il se veut être la solution de gestion de petite et moyenne association la plus complète et la plus simple à utiliser. Il permet la gestion des adhérents et des cotisations, la tenue d’une comptabilité en partie double et l’envoi de courriels entre membres ou à tous les membres. Il contient également un wiki complet, comprenant la possibilité de chiffrer les pages, ainsi qu’un site Web simple mais puissant grâce aux squelettes « à la SPIP ».
Il est léger, rapide et ne demande aucune configuration pour être installé chez n’importe quel hébergeur proposant PHP 5.6 ou plus (tout est stocké dans une base de données SQLite).
Cette nouvelle version 0.9 fait suite à un an de développement et améliore grandement l’importation et exportation de membres via des fichiers CSV et ODS (LibreOffice) ainsi que l’envoi de courriels, et ajoute une fonctionnalité de recherche avancée.
Garradin est également disponible en SaaS sur https://garradin.eu/ (utilisé par plus de 2 000 associations).
Parmi les nouveautés de Garradin 0.9, on peut souligner :
- exportation au format ODS (Office/LibreOffice) ;
- importation flexible de CSV ;
- exportation des recherches de membres ;
- recherche avancée de membres, avec clauses multiples et groupement de clauses ;
- envoi de courriel collectif selon des critères de recherche avancée ;
- possibilité de remettre à zéro la base de données ;
- possibilité de désactiver le site Web public de Garradin (dans ce cas la page d’accueil de Garradin redirigera vers la page administration ou connexion) ;
- ajout d’un bouton permettant de voir ou de cacher le mot de passe sur tous les champs de mot de passe.
De nombreuses améliorations ont aussi eu lieu dans les possibilités offertes aux greffons, notamment la possibilité de déléguer l’envoi de courriels à un greffon.
La version en SaaS Garradin.eu offre désormais aussi une page listant les adresses de courriel de membres qui sont invalides ou revenues en erreur.
Aller plus loin
- Essayer Garradin sur Garradin.eu (513 clics)
- Site du projet (483 clics)
- Journal des modifications (104 clics)
# l'age du développement de Garradin
Posté par ppb31 . Évalué à 7. Dernière modification le 29 octobre 2018 à 07:20.
Bonjour à tous et à toutes
J'utilise Garradin depuis plus de 5 ans et la version 0.2.1 date de 2012 voir: http://dev.kd2.org/garradin/Changelog
Franchement il est simple est pratique ne fait que la gestion des assos ce n'est pas un greffon sur un ERP.
Bien à vous
Pierre-Philippe
[^] # Re: l'age du développement de Garradin
Posté par Loïs Taulelle ࿋ (site web personnel) . Évalué à 3.
Oui, une erreur s'est glissée dans la news. Il faut lire : " développé depuis sept ans".
(On me glisse dans l'IRC qu'un copier/coller mal relu serait le véritable fautif.)
Proverbe Alien : Sauvez la terre ? Mangez des humains !
[^] # Re: l'age du développement de Garradin
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Corrigé, merci.
# Fossil
Posté par mzf (site web personnel) . Évalué à 5.
Garradin semble utiliser Fossil comme gestionnaire de version.
C'est un gestionnaire que l'on rencontre assez peu dans le logiciel libre.
Est-ce possible d'avoir un retour sur les motivations qui ont amené à ce choix ? et un retour à l'utilisation ?
Merci
[^] # Re: Fossil
Posté par Pol' uX (site web personnel) . Évalué à 4.
Perso j'ai rapporté quelques petits correctifs à Garradin le jour ou je l'ai déployé pour une asso.
Fossil a été plutôt un frein pour l'utilisateur de git (et anciennement svn) que je suis. Cet outil me semble vouloir tout faire en moins bien. Un outil comme gitlab a deux générations d'avance (sentiment subjectif, hein) :)
Concernant Garradin, je trouve le logiciel plutôt bien pensé et bien implanté (bonne qualité du code php). Merci aux devs. :) Après le problème est que les assos qui nécessitent ce genre d'outil (dont la taille impose un outil) sont nombreuses à avoir des architectures un peu particulières, et c'est pas facile d'avoir un outils qui colle aux besoins (à titre perso je me suis retrouvé à faire des bidouilles pour tenir compte de configurations particulières). Aussi je trouve la partie wiki/site web un peu trop austère et difficile à prendre en main pour les lusers.
Adhérer à l'April, ça vous tente ?
[^] # Re: Fossil
Posté par BohwaZ (site web personnel, Mastodon) . Évalué à 10. Dernière modification le 29 octobre 2018 à 15:19.
Hello,
;-)
Plusieurs trucs qui me font préférer Fossil :
A mon avis il ne manque que la possibilité d'envoyer des merge request, mais ça finira bien par arriver un jour :) En attendant il suffit de mailer ton fichier .fossil pour que l'autre développeur ait accès à ton code et puisse le merger… Pas compliqué franchement.
Si j'avais du choisir un DVCS de toutes façons ça aurait plutôt été mercurial ou autre mais jamais Git, son utilisation est bien trop complexe et les risques de perdre du taf trop importants.
Pour la partie wiki/site de Garradin je suis d'accord, et toute contribution est la bienvenue :)
« Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)
[^] # Re: Fossil
Posté par freem . Évalué à 3.
Juste, sur ce point, pourrais-tu expliciter un peu plus sur l'intérêt?
Je suis intrigué la. Sans vouloir lancer le troll, j'admets avoir adopté git pour 2 raisons principales:
Du coup, je serais curieux de voir des cas pratiques ou Mercurial est plus simple? Notamment quand l'on vient de SVN (apprendre git à déjà été douloureux, malgré que j'aie toujours vu ses avantages, sinon me serais pas fait chier: c'était juste mes projets perso après tout)
Par contre, j'ai toujours eu une certaine tendresse pour fossil, sans jamais trouver vraiment de raisons de le plébisciter…
[^] # Re: Fossil
Posté par BohwaZ (site web personnel, Mastodon) . Évalué à 6.
http://dev.kd2.org/garradin/ le site est construit à partir de l'API JSON de Fossil
Autre utilisation perso : envoi de mises à jour des tickets par email (bon sur Fossil 2.7 il gère ça tout seul).
Après y'a plein d'autres usages possibles :)
Fossil est écrit en C aussi donc j'ai pas compris ?
Ça fait des années que je fait du Git en milieu professionnel et tous les jours quasiment je dois lire la doc ou chercher comment faire des trucs basiques parce que c'est impossible à s'en souvenir, ses commandes sont mal foutues en possible. "git reset" par exemple a un comportement très différent selon les options, ça devrait être plusieurs commandes séparées, etc. Tout est très tarabiscoté je trouve.
« Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)
[^] # Re: Fossil
Posté par freem . Évalué à 4.
Justement, c'est un des points qui font qu'il m'attire. Tu as oublié de mettre en exergue le point que tu ne comprend pas?
Ma foi, je suis assez d'accord avec toi si je prend la totalité de mon expérience avec git. Ceci était dit, la totalité implique de prendre en compte mon apprentissage initial il y a 8 ans, je pense.
Depuis, porcelain git s'est amélioré et fournit bien souvent des info sur ce que tu veux vraiment faire, mais il est vrai que je ne l'exploite pas à fond.
Par exemple, le reste, j'aimerai que tu développes?
[^] # Re: Fossil
Posté par djibb (site web personnel) . Évalué à -1.
"malgré que j'aie" -> combo ?
Je remarque que sur ce site…. l'orthographe devient n'importe quoi… c'est moi où l'âge moyen de linuxfr diminue ?
Mais où sont les vieux dinosaures quoi ???
[^] # Re: Fossil
Posté par Yth (Mastodon) . Évalué à 4.
Certains se fossilisent, tandis que d'autres se sédimentarisent.
[^] # Re: Fossil
Posté par freem . Évalué à 0.
Il est où, le sujet+verbe+complément?
Les points de suspension, c'est 3 points, pas 4. Et puis, y'a un caractère spécial pour ça.
[^] # Re: Fossil
Posté par jyes . Évalué à 4.
Depuis que j’ai découvert son existence, j’ai toujours trouvé Fossil intéressant sur le principe mais n’ai jamais vraiment appris à m’en servir. Pourtant les tickets distribués avec le répo de code, je trouve le principe excellent. Mais, ce que tu écris ci-dessus est une limitation qui fait que je n’imagine pas l’utiliser un jour. Je ne comprends pas comment tu peux ne pas aimer le rebase et trouver que les risques de perdre du taf trop importants avec Git en même temps. Le rebase, c’est justement ce qui fait qu’en codant, dès que j’ai touché à plus de 10 lignes, j’enregistre un commit. Ce commit n’a pas vocation à durer, mais à m’assurer que je peux revenir à cet état facilement. Une fois que j’ai une fonctionnalité qui marche (ou du moins le crois-je) je regroupe les commits en opérations unitaires liées par la logique (et si j’ai touché d’autres trucs à côté pour me faciliter les tests, je les enlève des commits). J’ajoute des descriptions et j’ai une séquence de commits qui correspondent chacun à un patch le plus indépendant possible des autres et dont l’impact sur le code est clair.
J’ai donc des sauvegardes permanentes de mon code, y compris des commentaires personnels que je ne compte jamais partager, et un historique de développement clair. Comment faire cela sans rebase ?
De plus, en committant tout tout le temps, on se met bien à l’abris des fausses manips, même des "git reset --hard" malencontreux au milieu d'un rebase en cours se retracent finalement bain avec "git reflog".
Bon, comme tu le vois, j’aime bien Git. Mais mon commentaire est surtout là pour que tu m’aides à identifier comment je pourrais modifier ma manière de faire si je voulais utiliser Fossil, pas pour te dire combien Git est mieux. Concrètement, avec Fossil, tu travailles comment ?
[^] # Re: Fossil
Posté par BohwaZ (site web personnel, Mastodon) . Évalué à 3.
C'est mon éditeur qui stocke l'historique des modifs, et quand je suis prêt je commite un truc qui a du sens.
Mais je comprend ta logique de boulot mais ça ne me convient pas du tout perso.
« Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)
[^] # Re: Fossil
Posté par freem . Évalué à 2.
Je t'avoue que je ne vois pas, sur ce coup, et je suis curieux d'en apprendre plus (d'autant qu'on m'a déjà posé la question de pourquoi j'utilise pas rebase: parce ce que je ne sais pas ce que ça fait fut ma réponse honteuse).
Si je te suis, tu commit toutes tes sessions de code sale dans une branche séparée (je suppose, pour la branche) périodiquement, et à la fin, tu prends un morceau de ce commit-ci, un morceau de ce commit-la, pour faire un commit neuf et propre, et ce jusqu'à épuisement du pool de modifications?
Hum, je doute de t'avoir compris en vrai…
[^] # Re: Fossil
Posté par ZeroHeure . Évalué à 2.
Ça doit être ça. Je fais pareil, mais sans rebase : en picorant vers une branche propre.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: Fossil
Posté par freem . Évalué à 4. Dernière modification le 29 octobre 2018 à 20:20.
Pour faire simple, fossil, c'est pas un DVCS, c'est une forge légère.
Tant qu'un projet est indépendant et pas accompagné de bibliothèques semi-externes, c'est probablement la plus adaptée des situations, à conditions de vouloir rester maître de sa forge.
Les avantages et les défauts sont multiples.
Utiliser fossil implique une isolation totale des projets dont on pourrait dépendre. La news parle de dépendance à PHP? Bon. Si à un moment donné, un workaround est construit autour d'un bug d'une certaine version de PHP, comment référencer facilement le ticket sur la dépendance? Impossible.
D'un autre côté, les choses comme le wiki et le bugtrackers sont clonés en même temps que le répo.
On peut aussi citer le fait que, justement, fossil soit tout en un. Donc, on doit se restreindre à cet outil qui est quand même limité en terme de fonctionnalités pour gérer les tickets, un site web, etc.
Franchement, fossil est largement supérieur en terme de fonctionnalités à git. Mais, git, lui, ne fait qu'une seule chose, la fait bien et peut être intégré dans d'autres outils spécialisés dans leur domaine comme redmine.
Pour moi, les deux approches sont intéressantes, même si j'avoue n'avoir que peu exploité fossil.
[^] # Re: Fossil
Posté par BohwaZ (site web personnel, Mastodon) . Évalué à 4.
Chacun sa vue, perso je trouve le gestionnaire de tickets de fossil bien plus puissant que ce qu'on trouve dans gogs ou gitlab, en plus il est scriptable, on peut faire des requêtes SQL pour créer des rapports, etc.
J'ai pas compris de quoi tu parle pour la dépendance PHP ? On peut faire des références entre tickets et commits dans Fossil, ou même référencer des liens externes, et encore mieux on peut lier des "tech notes" au commits ou dans la timeline pour expliquer plus longuement que dans un message de commit.
Fossil s'utilise aussi bien si on utilise des libs externes, j'ai implémenté le support de Fossil dans Composer justement ;)
« Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)
[^] # Re: Fossil
Posté par freem . Évalué à 2.
Ça tombe bien, j'ai parlé de redmine, j'ai toujours détesté les forges git-only, github la 1ere.
L'usage du SQL peut être un réel bénéfice, si et seulement si c'est bien documenté, mais ça implique aussi qu'il faille un dev pour gérer ça, ce qui a un coût en entreprise. En revanche, c'est un coût en moins dans un environnement sans admin, juste des devs dont 1 qui aime les SGBDR.
Je parlais de lier un ticket à un autre ticket d'un autre projet?
[^] # Re: Fossil
Posté par BohwaZ (site web personnel, Mastodon) . Évalué à 5.
Ben comme dans toutes les forges on met un lien vers l'autre ticket ?
« Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)
[^] # Re: Fossil
Posté par freem . Évalué à 2.
Tout dépend du comment. Dans une forge qui mets en vraie relation plusieurs projets, on peut mettre un ticket comme étant dépendant de la résolution de plusieurs projets liés, et qu'il soit résolu automatiquement lors de la cloture de ces derniers.
Ça va au-delà du simple lien http(s)…
[^] # Re: Fossil
Posté par BohwaZ (site web personnel, Mastodon) . Évalué à 3.
Heu je vois pas comment, si les forges des projets sont complètement différentes et indépendantes ? Genre lier entre un gitlab et un github ?
« Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)
[^] # Re: Fossil
Posté par freem . Évalué à 2.
Je n'ai jamais vraiment considéré github comme une forge, mais juste comme un ensemble de repo mit bout à bout…
Bon, j'avoue que mon opinion est de moins en moins tenable, mais dans une forge telle que trac, il est aisé, du fait de la centralisation des tickets, de remonter un ticket au projet qui a le réel problème. Enfin, si le projet en question est hébergé par la même forge et sur le même nom de domaine….
[^] # Re: Fossil
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 0.
Donc il ne faut le comparer à git mais plutôt à gog/github/gitlab/etc.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Fossil
Posté par Yth (Mastodon) . Évalué à 3. Dernière modification le 30 octobre 2018 à 15:13.
Ben c'est aussi un DVCS.
Rien ne t'empêche a priori d'avoir un backend Fossil sur une autre forge, mais la forge Fossil n'utilise que le DVCS Fossil en backend et ne fonctionnerait pas avec un autre.
Donc tu peux comparer Git et Fossil, ou Gitlab et Fossil, ou Github+Git et Fossil, en prenant tout ou partie de Fossil, selon le cas.
Yth.
[^] # Re: Fossil
Posté par freem . Évalué à 2. Dernière modification le 30 octobre 2018 à 19:59.
Et un bugtracker, et un wiki (de mémoire) et un httpd…
Pour moi, si on veut une vraie comparaison, il faut comparer fossil à redmine+git, ou gitlag+git, ou whatever+svn, truc+mercurial, foo+bar.
On peut utiliser fossil comme un simple DVCS, mais on perds dans ce cas l'un des intérêts majeurs de la bête.
Je pense que c'est un peu un outil hors concours en fait. Pour moi, si quelqu'un à besoin un jour d'héberger un projet unique sans chercher à séduire pleins de contributeurs, fossil est superbe.
Admettons quelqu'un qui se crée un BSD (parce qu'ils ont tout le code de tous leurs binaires dans un repo unique), par exemple, je pense que fossil sera un excellent choix (facilité de clonage avec les bugs inclus, on pourrais même imaginer (je suis pas sûr que ça soit faisable) de merger la liste des tickets comme moyen de reporter un bug, pas de dépendance à un dépôt tiers…).
Je crois me souvenir que fossil est par exemple utilisé par sqlite3, qui à très peu (aucune?) de dépendances externes.
Par contre, si on cherche à juste faire un jeu vidéo, je pense que github, gitlab, sourceforge sont plus appropriés, ne serait-ce que parce que la plupart des développeurs ont déjà un compte sur au moins une de ces plate-formes, et qu'il est probable que les autres projets dont on dépends (genre, une lib pour gérer l'interface) seront probablement sur la même, et du coup ça simplifie les échanges.
[^] # Re: Fossil
Posté par ZeroHeure . Évalué à 3. Dernière modification le 31 octobre 2018 à 11:48.
Oui, et pour cause ! c'est le même auteur.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: Fossil
Posté par freem . Évalué à 2.
Et c'est quand même une sacrée preuve que les développeurs croient en leur produit, que de l'utiliser eux-même. D'autant que bon, sqlite est pas vraiment inconnu des développeurs, et j'ai jamais lu ni entendu de mal à son sujet.
Comment, dès lors, ne pas être intéressé par fossil, même sans jamais avoir eu la combinaison temps+motivation pour apprendre à s'en servir?
[^] # Re: Fossil
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 1.
Merci pour la précision.
Il y a des exemples de ce genre de réalisation ? Je serai bien curieux de voir la mise en oeuvre en même temps que de me mettre à fossiliser pour changer.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Fossil
Posté par Yth (Mastodon) . Évalué à 3.
Je ne crois pas qu'il y ait d'exemple.
Mais tu as des commandes classiques de gestion de source, des init, clone, status, diff, branch, update, checkout, push, pull, commit, add, rm, merge…
Donc une forge qui utilise un autre gestionnaire de source doit pouvoir s'interfacer avec Fossil en n'utilisant que les commandes de gestion des sources.
Et en considérant juste ce qui concerne la gestion des sources, on peut comparer git et fossil sur les différentes façon de faire, comment régler les situation courantes, etc.
Le fait que l'outil complet Fossil fasse des choses en plus ne l'empêche pas de recouvrir le domaine d'un Mercurial d'un Git ou d'un Subversion.
Par contre dans ce cas il ne faut pas dire que Fossil est supérieur parce qu'il inclue une forge, dans ce cas ce n'est plus comparable et il faut prendre en considération une forge+git/hg/autre !
Bref, tout ça pour dire qu'on peut comparer Fossil et Git sur la partie gestion de sources.
Yth.
[^] # Re: Fossil
Posté par freem . Évalué à 2. Dernière modification le 07 novembre 2018 à 20:49.
Ce que je retiens de ton message, c'est que, en théorie, c'est possible, mais en pratique ça n'a jamais été fait.
Cela dit, lire ton message me fait me demander si utiliser une forge type redmine (qui ne versionne pas, nous sommes d'accord) qui expose une API (REST, me semble) pour gérer les tickets ne permettrait pas justement de servir d'intermédiaire entre divers projets utilisant chacun divers (D)VCS et bugtrackers… en gros, s'il ne serait pas possible d'utiliser des forges classiques comme des agrégats de forges, ça permettrait vraiment de bosser sans être connecté, tout en permettant de lier des tickets à des tickets d'autres projets. La, fossil serait vraiment une putain de bonne solution!
Parce que bon, qui n'a jamais cherché à intégrer la gestion des tickets à son git, sérieusement? Le wiki, ok, c'est overkill, quoique, ça permets de documenter, ce qu'on a tant de mal à faire… bon, ok, je suis peut-être le seul, mais à voir l'état global des docs de libs, j'en doute…
Mais pas sur la partie intégration avec d'autres logiciels, avec un éco-système.
Je pense très sincèrement que fossil est un projet intéressant, très adapté à certains cas, tout comme git l'est à d'autres, et seules la flemme et la dépendance à un langage interprété m'ont fait rejeter mercurial qui semble de réputation plus adapté à la majorité des projets (la flemme étant l'argument principal, qui n'est pas contrebalancé par la réputée meilleure facilité d'usage).
[^] # Re: Fossil
Posté par Xavier Maillard . Évalué à 3. Dernière modification le 02 novembre 2018 à 11:11.
Je ne connaissais pas du tout ce fossil et je te remercie de me l'avoir fait découvrir. J'utilise (mal) git depuis des années en me disant que c'est totalement démesuré pour mon usage (petits projets persos, gestion de ma configuration, etc.)
Je passe mon temps a rechercher dans la doc de Git comment faire telle ou telle chose ce qui est bien le signe que ce n'est pas approprié pour mon usage et je ne parle pas des moments ou, après des semaines sans l'utiliser, je relis quasiment toute la doc pour refaire des choses toutes simples ;)
Bref, je vais donner sa chance a ce fossil pour voir et si concluant, je pense que je basculerai tout dedans (il faut encore que je trouve le moyen de faire ingurgiter mon repos git dedans ;))
[^] # Re: Fossil
Posté par freem . Évalué à 3.
Sinon, je n'ai jamais utilisé (contrairement à fossil que j'ai utilisé de manière expérimentale et git que j'utilise à la fois au taf et pour mes projets persos, mais sans maîtriser), mais j'en ai lu énormément de bien, mercurial.
Je sais que c'est étrange, normalement on est censé défendre la technologie que l'on utilise, ne serait-ce que par résistance au changement… mais, pour moi, les 3 (D)VCS les plus intéressants sont (pas ordre d'intérêt personnel, pas par ordre d'usage réel personnel) fossil, git, et mercurial.
Fossil à l'avantage d'être une forge, et comme ma religion me dit d'utiliser surtout du code natif ça colle, mais, je ne sais pas encore l'utiliser, surtout dans le cas de projets liés entres eux…
Git permets de référencer d'autres projets, via les submodules, est intégré à toutes les forges qui ne veulent pas gérer le versionnage, et est codé en natif aussi. C'est aussi l'outil le plus célèbre, et le fait que j'ai du apprendre par moi-même d'abord SVN, puis git m'a déjà été dur, alors j'ai surement une forte résistance au changement de ce côté… d'autant que je reste un dev, quelqu'un qui vise à automatiser son propre taf pour être payé à ne rien faire d'emmerdant!
Mercurial est le l'outsider de git.
Il prétends apporter la facilité d'usage, mais rien de plus (pas de fonctionnalités supplémentaires).
Côté subjectif, mercurial… est codé en python, et d'une part le côté interprété du langage et d'autre part mon expérience des paquets pythons dans debian (oh, la jolie dépendance manquante! non, j'ai pas de source, juste vécu trop souvent, et non, c'est pas la faute du langage, juste des dev et empaqueteurs qui ne se basent pas sur un système strictement minimal pour définir leurs dépendances) font que j'ai deux arguments plus ou moins foireux en faveur de ma résistance au changement.
# Super !
Posté par Graveen . Évalué à 3.
Je vais tester ça, ca me semble plus approprié que Dolibarr.
J'ai aujourd'hui 1 asso qui propose 3 activités culturelles, avec chacune dépenses / recettes.
A la fin, je voudrais avoir le détail par activité.
Est ce que cela semble réalisable avec Garradin ?
Je retrouve bien des codes comptables et des catégories mais je ne sais pas s'il est pertinent de créer les miennes (parce que, par exemple, les dépenses de chaque activité sont le défraiement des bénévoles, mais je ne veux pas mettre ça dans un seul compte, puisqu'à l'issue, c'est le ratio d/r par activité qui m'intéresse).
Merci !
[^] # Re: Super !
Posté par BohwaZ (site web personnel, Mastodon) . Évalué à 4.
Regarde dans Exercices & Projets, crée toi un projet et quand tu ajoute une dépense / recette tu lui affecte un projet. C'est l'équivalent Garradin de la compta analytique :)
« Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)
[^] # Re: Super !
Posté par Graveen . Évalué à 2.
Merci, c'est tout à fait ce qu'il me faut…
Bravo !
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.