Questions avant choix CiviCRM

[michelt]

La gestion du fichier de notre association est actuellement assurée par une application maison développée il y a 8 ans. Son architecture interne, fait que des évolutions importantes demandées ne sont pas faciles à mettre en place. Une des solutions envisagées est d'utiliser CiviCRM.

D'où ma longue liste de questions. J'ai bien vu qu'il existe une section « pré-installation » dans la partie anglaise du forum, mais çà va quand même mieux en français.
Je crois avoir bien regardé la documentation et les forums, mais j'ai pu rater certaines informations. Je précise aussi que je ne connais pas les cms utilisés par Civi et il est possible que certaines de mes questions puissent être résolues via cette sous-couche.
Merci d'avance à tous ceux qui auront pris du temps pour répondre, même à une seule question.

Gestion des adresses.
Nous faisons de manière régulière, des mailings postaux. La majorité de nos adresses se situe en France et pour bénéficier de tarifs postaux avantageux, les adresses doivent être normalisées, ce que nous faisons avec les fichiers de la Poste auxquels nous sommes abonnés. Il ne semble pas que cette intégration soit prévue.
J'ai vu qu'il existe une case à cocher pour standardiser l'adresse selon les normes postales USA si on est abonné au service USPS et que l'extension « Street format parsing Dutch format » utilise des champs distincts pour le numéro et le libellé de la voie. Il doit donc être possible de développer quelque chose.
Est-ce qu'une telle intégration vous paraît compliquée ?

Mais nous avons aussi des adresses dans plus de 160 pays. Dans Civi, la présentation des étiquettes (Nom, adresse) peut se paramétrer au niveau de l'application, mais logiquement, ce paramétrage devrait plutôt être rattaché au pays.
Est-ce qu'une telle adaptation aurait beaucoup d'effets de bord et représenterait du coup, une grosse charge de travail ?

Au bout de 2 retours courriers, nous n'envoyons plus de courrier. Je n'ai pas trouvé de gestion des retours courriers. Cela existe-t-il ?


Gestion des versements.
Les personnes qui saisissent les versements, le font de manière très rapide. Actuellement, cela se fait via la saisie d'un identifiant numérique avec affichage immédiat de certaines données pour confirmation.
Est-ce que l'auto-complétion utilisée dans le « Batch Data Entry » est performante sur 200 000 noms ?

Les chèques, la majorité de nos dons, sont saisis par lots pour être ensuite déposés à la banque avec des listes de remise en banque. Je n'ai rien trouvé qui corresponde.

Je n'ai pas trouvé aussi, comment saisir un versement avec plusieurs affectations : par exemple, un chèque de 100 euros avec 8 euros d'adhésion, 25 euros d'achat de livre et le reste en don.
Est-ce possible ?

Dans Civi, l'édition des reçus fiscaux se fait avec des numéros non consécutifs. Notre commissaire aux comptes exige des numéros consécutifs : une association a-t-elle déjà mis cela en pratique ?

Certaines affectations entraînent des actions :
adhésions ==> édition d'une carte d'adhésion
abonnement ==> génération d'un abonnement à la revue demandée etc.
Je n'ai trouvé que « org.civicoop.triggers », tout récent, qui a l'air de faire quelque chose dans ce sens. Existe-t-il d'autres possibilités ?

Est-ce qu'une simulation du passage en comptabilité est possible (de manière à pouvoir lancer plusieurs fois le passage en comptabilité) ?

Certains donateurs en prélèvement automatique ont des périodicités atypiques qui n'ont pas l'air de pouvoir être traitées par le module existant. Par exemple : prélèvement mensuel sauf décembre, prélèvement mensuel de janvier à juin et rien les 6 autres mois...
Pour gérer cela, nous avons un champs de 12 caractères avec des « 0 » ou des « 1 ».
Nos prélèvements peuvent être multi-affectations, et le premier de l'année, peut générer une adhésion si la personne le souhaite.
Est-ce que tout ceci serait possible ?

Gestion de revues payantes
Nous éditons 2 revues payantes. N'ayant pas la rigueur de parution de « The Monthly» donné en exemple dans le blog, nous gérons les abonnements au numéro, et non via des dates de début et de fin d'abonnement. Quelqu'un a-t-il mis en place ce type de gestion ?

Nous avons aussi d'autres revues gratuites. Les données de la première ligne des étiquettes dépendent de la revue. Est-ce possible ?

"Sas" de création
Dans certains cas, la création de personnes, faite par des régions, doit être validée/contrôlée par un autre secrétariat. Cette fonctionnalité vous paraît-elle compliquée à implanter ?

Postgresql
Nous utilisons Postgresql depuis 8 ans et préférerions le garder. Son utilisation avec Civi n'a pas l'air simple.
J'ai vu qu'un projet d'utilisation de Doctrine avec Civi était en cours. Cela résoudrait le problème. Savez-vous si cela a des chances d'aboutir et si oui, quelqu'un a-t-il une idée du délai : 6 mois, 2 ans... ?

[mathieu]

Bonjour,

Bienvenue aux forums de CiviCRM

Je vais tenter de répondre à certains points, mais j'espère que d'autres participants de ce forum pourront fournir d'autres pistes également.

Nous faisons de manière régulière, des mailings postaux. La majorité de nos adresses se situe en France et pour bénéficier de tarifs postaux avantageux, les adresses doivent être normalisées, ce que nous faisons avec les fichiers de la Poste auxquels nous sommes abonnés. Il ne semble pas que cette intégration soit prévue.

J'ai vu qu'il existe une case à cocher pour standardiser l'adresse selon les normes postales USA si on est abonné au service USPS et que l'extension « Street format parsing Dutch format » utilise des champs distincts pour le numéro et le libellé de la voie. Il doit donc être possible de développer quelque chose.
Est-ce qu'une telle intégration vous paraît compliquée ?

Par défaut, CiviCRM sauvegarde l'adresse de deux façons:

1- l'adresse telle que entrée par l'utilisateur
2- les différentes parties de l'adresse, soit le numéro civique, le nom de la rue, type de rue, direction, etc.

Par contre, dans ce 2e cas, seulement les adresses dans le format des États-Unis et Canada sont reconnues. C'est ce problème que l'extension "street format parsing" tente de résoudre.

Les systèmes de normalisation, dont USPS, aident à normaliser l'adresse pour obtenir l'écriture formelle. Par exemple, au Québec, quelqu'un pourrait écrire: "123, rue St Joseph, app 4", mais l'adresse serait normalisée à "4-123, rue Saint-Joseph". Je vois que la Poste en France semble offrir un service équivalent. Je ne pense pas que ce soit difficile d'écrire une extension qui puisse s'intégrer avec ce service.

Mais nous avons aussi des adresses dans plus de 160 pays. Dans Civi, la présentation des étiquettes (Nom, adresse) peut se paramétrer au niveau de l'application, mais logiquement, ce paramétrage devrait plutôt être rattaché au pays.
Est-ce qu'une telle adaptation aurait beaucoup d'effets de bord et représenterait du coup, une grosse charge de travail ?

Bonne question. Je ne suis pas sûr. Il faudrait que je recherche un peu plus. Je pense que c'est possible d'implémenter en code (un "hook") pour mieux gérer le formattage.

Au bout de 2 retours courriers, nous n'envoyons plus de courrier. Je n'ai pas trouvé de gestion des retours courriers. Cela existe-t-il ?

Deux options:

1- avoir un "type d'adresse" qui indique que c'est pour des adresses invalides (retours de courriers)
2- et/ou utiliser la case à cocher "ne pas envoyer de courrier" dans les préférences de communication, et ajouter une note à la fiche de contact pour expliquer pourquoi ne pas envoyer de courrier (ou ajouter un champ personnalisé pour catégoriser les raisons, car j'imagine que si le courrier est retourné, il y a une action à prendre par après pour retrouver la bonne adresse)..

Les personnes qui saisissent les versements, le font de manière très rapide. Actuellement, cela se fait via la saisie d'un identifiant numérique avec affichage immédiat de certaines données pour confirmation.
Est-ce que l'auto-complétion utilisée dans le « Batch Data Entry » est performante sur 200 000 noms ?

Le "Batch data entry" (mises à jours en lot) est assez limité, 100 contacts à la fois, je pense.

Il y a surement des alternatives possibles, comme d'utiliser un formulaire "profil" pour auto-compléter le nom de contact, selon son identifiant numérique, mais je préfère ne pas trop promettre la lune à cet égard. Au pire, c'est assez facile de faire de nouveaux formulaires, soit avec le module "webform" pour le CMS Drupal, soit directement avec l'API de CiviCRM.

Une dernière option est l'importation de transactions par CSV (Excel).

Les chèques, la majorité de nos dons, sont saisis par lots pour être ensuite déposés à la banque avec des listes de remise en banque. Je n'ai rien trouvé qui corresponde.

Je ne suis pas sûr ce qu'est une "liste de remise en banque", mais est-ce que ça correspondrait à l'entrée des contributions dans CiviCRM, puis les associer à un "lot" de transactions pour un dépôt? (c.f. "CiviAccounts")

Je n'ai pas trouvé aussi, comment saisir un versement avec plusieurs affectations : par exemple, un chèque de 100 euros avec 8 euros d'adhésion, 25 euros d'achat de livre et le reste en don.
Est-ce possible ?

Oui, il faut activer une grille de prix (ou grille tarifaire, selon la traduction, aka "price grid" en anglais). Sinon, saisir les 3 contributions séparément?

Dans Civi, l'édition des reçus fiscaux se fait avec des numéros non consécutifs. Notre commissaire aux comptes exige des numéros consécutifs : une association a-t-elle déjà mis cela en pratique ?

Pour les reçus fiscaux, je recommanderais l'extension "CDN tax receipts": https://github.com/jake-mw/CDNTaxReceipts/

C'est développé pour le Canada, mais devrait fonctionner en France. Un hic: je pense qu'en France, le montant du don doit être indiqué sous forme de texte ("cent cinquante euros", plutôt que 150 EUR), mais c'est un changement assez mineur, et quelqu'un l'a peut-être déjà fait. c.f. Xavier de CiviCoop.

[...]
Postgresql
Nous utilisons Postgresql depuis 8 ans et préférerions le garder. Son utilisation avec Civi n'a pas l'air simple.
J'ai vu qu'un projet d'utilisation de Doctrine avec Civi était en cours. Cela résoudrait le problème. Savez-vous si cela a des chances d'aboutir et si oui, quelqu'un a-t-il une idée du délai : 6 mois, 2 ans... ?

C'est prévu pour CiviCRM 5.0, mais ça risque de prendre encore au moins 1 an avant d'aboutir. La prochaine version à sortir sera CiviCRM 4.5 bientôt (d'ici 1-2 mois?), puis davantage d'efforts seront orientés vers 5.0. Cette version apportera aussi un changement important à la gestion des formulaires (probablement AngularJS). C'est certain que cela aboutira, cependant, mais c'est une question de temps et de ressources. Le développement est généralement payé par des projets clients ou des subventions. Si votre organisation en a les moyens, votre participation dans ce processus sera grandement appréciée
https://civicrm.org/participate/support-civicrm

PS: il y a des fournisseurs CiviCRM qui pourraient vous intéresser, dont Talcod.net, situé à Paris, et CiviCoop.org, dont certains développeurs sont francophones (ex: Xavier).

[michelt]

Bonjour et merci de votre réponse.
Quelques précisions:

Je ne suis pas sûr ce qu'est une "liste de remise en banque", mais est-ce que ça correspondrait à l'entrée des contributions dans CiviCRM, puis les associer à un "lot" de transactions pour un dépôt? (c.f. "CiviAccounts")

Par exemple 300 chèques sont saisis par lots de 100 chèques. Lors du dépôt des chèques dans la banque, on remet 3 paquets de 100 chèques. Chaque paquet est accompagné d'une liste reprenant le montant total du lot, le nombre de chèques etc. et de la liste (nom, prénom, montant...) des chèques contenus dans ce paquet.
Lors de la saisie, chaque versement est du coup associé à un numéro de lot.

Un hic: je pense qu'en France, le montant du don doit être indiqué sous forme de texte ("cent cinquante euros", plutôt que 150 EUR), mais c'est un changement assez mineur

Non, ce n'est pas une obligation si le montant numérique est entouré d'étoiles (***150,00*** euros). C'est encore plus facile à programmer ;-)

[petednz]

bonjour - re batch entry of cheques

i may be able to demo a form we built using Drupal Forms that is used for entering many cheques,

it has autocomplete fields for finding the existing civi contacts - or create new ones

it has ability to add as many new 'rows' as needed as you work - haven't yet tested with many 100s though.

in our case some of the payments have to cover multiple people - for example a 'branch' pays a cheque in and it must cover the membership of 10 people, or a cheque covers 4 people in the family and each name needs to be entered to create 4 new contacts.

Our work on this is paused but if you are interested we can probably organise to show it to you.

[xavier]

Certains donateurs en prélèvement automatique ont des périodicités atypiques qui n'ont pas l'air de pouvoir être traitées par le module existant. Par exemple : prélèvement mensuel sauf décembre, prélèvement mensuel de janvier à juin et rien les 6 autres mois...
Pour gérer cela, nous avons un champs de 12 caractères avec des « 0 » ou des « 1 ».
Nos prélèvements peuvent être multi-affectations, et le premier de l'année, peut générer une adhésion si la personne le souhaite.
Est-ce que tout ceci serait possible ?

Comment se fait le prélèvement? Sepa?

Les contributions périodiques ne permettent pas, pour le moment, de faire le système que tu évoques. Cela dit (en tout cas pour sepa), cela serait possible de rajouter cette fonctionalité

Certaines affectations entraînent des actions :
adhésions ==> édition d'une carte d'adhésion
abonnement ==> génération d'un abonnement à la revue demandée etc.
Je n'ai trouvé que « org.civicoop.triggers », tout récent, qui a l'air de faire quelque chose dans ce sens. Existe-t-il d'autres possibilités ?

La manière standard d'ajouter ce type de fonctionalités est de développer une extension, qui va etre appelée quand creation d'un membership et générer la carte.

En principe, il n'y a pas de problèmes de mise à jour si vous utilisez les hooks et API pour ces fonctions.

Dans tous les cas, votre système est complexe et il y aura des choses spécifiques, soit contribuer à une amélioration dans le core, soit comme extension. C'est le bénéfice d'un logiciel libre, on est pas limité à ce qu'il fait par défaut


Pour info, j'ai développé les reçus fiscaux pour Wikimedia France, il ne serait sans doute pas difficile d'en faire qqchose de générique. La version canada il me semble avait un probleme pour etre utilisée en France, mais je ne me souvient plus (et cela a peut etre été réglé depuis).

X+

[michelt]

@petednz
Thanks for your reply. For some payments, we get the same case : one payment for multiple people.
If we choose CiviCRM, I think we will be interested to see your form.

@Xavier
Merci, et oui, les prélèvements se font via SEPA.

Nous sommes bien conscients que ce que l'on veut n'est pas simple. Et je n'ai pas parlé de plusieurs fonctionnalités que je n'ai pas du tout vu dans Civi.
Participer au développement d'un logiciel libre est un gros plus pour le choix de cette solution, mais la complexité de l'architecture sous-jacente (Drupal) et une probable reprise des données aussi plus complexe qu'une solution maison sont à mettre dans la balance.
On continue de regarder.

[xavier]

Pour info, il y a tres peu d'utilisation de drupal dans civicrm (principalement pour la gestion des utilisateurs) car il fonctionne aussi avec Wordpress et Joomla.

Cela serait bien que tu viennes à notre conférence à Londres http://london2014.civicrm.org/ cela te donnerais une bonne vue de la communauté et la direction prise par Civi et les fonctionnalités prévues.