Outils pour utilisateurs

Outils du site


cr:reunions_diverses:8_9_avril_2017

Hackathon système d'information des 8 et 9 avril 2017

« Le mot hackathon désigne un événement où un groupe de développeurs volontaires se réunissent pour faire de la programmation informatique collaborative, sur plusieurs jours. » Source.

Objectifs

  • Ne pas avoir de services impayés. Ne pas oublier le problème numéro 1 : les adhérent⋅e⋅s ne savent pas ce qu'il⋅elle⋅s doivent à l'asso !
  • Améliorer la qualité et l'attractivité des services
  • Avoir de la visibilité pour prendre des décisions au sein de l'asso

Bilan

Solution retenue

  • COIN a été retenu pour l'interface adhérent (et gestion de la comptabilité adhérent⋅e⋅s). Raisons :
    • parce qu'il est déjà utilisé par d'autres FAI de la FFDN
    • parce que la techno est connue (Python / Django)
    • parce que l'implémentation actuelle répond grosso-modo à pas mal de nos besoins (même s'il y a nécessité d'adapter des choses)
  • Néanmoins COIN ne répond pas au besoin de comptabilité général (compta fournisseur et autres, absence de fonctionnalités et concepts avancés de compta). Il faut donc un outil dédié à la compta générale. Cet outil sera Tryton.
  • On part donc sur un couple COIN+Tryton.
    • Tryton gérera la partie compta globale (adhérent⋅e⋅s + fournisseurs + etc.)
    • COIN gérera “seulement” la génération des factures, la gestion des paiements et du solde des adhérents
    • COIN fournit aussi l'interface avec les adhérent⋅e⋅s (gestion de stock, interface de résumé des paiements et des factures, services, relance par mail)
    • Tryton doit pouvoir demander à COIN les factures et les paiements enregistrés de manière à ce que les outils soient synchronisés
    • On doit pouvoir importer facilement le .csv de la banque vers COIN/Tryton pour prendre en compte facilement/automatiquement les entrées/sorties d'argent

Ce hackathon s'est concentré sur la partie COIN. Il y a également eu une grosse discussion sur la gestion des factures et des paiements des adhérent⋅e⋅s. Partant du principe qu'il est généralement difficile de faire l'association entre une facture et un virement bancaire (exemple : membre qui aurait 2 mois de VPN de retard qui paye d'un seul coup 40 € pour rattraper le coup et payer quelques mois d'avance), nous abandonnons l'idée d'une correspondance claire entre facture et virement. À la place : les paiements reçus sont automatiquement alloués aux factures les plus anciennes, et un “solde de compte” est affiché aux adhérents.

Travail effectué

  • Création d'un package d'installation Yunohost pour COIN : https://github.com/YunoHost-Apps/coin_ynh
    • Le package permet l'installation sur la racine d'un domaine. COIN n'est pas encore adapté pour une installation dans un sous-dossier
    • L'objectif ici était de préparer le terrain pour rendre possible le déploiement de coin_ynh avec l'appli openvpn_ynh (il serait ainsi possible de monter un couple SI + serveur VPN ipv4 publique, de quoi démarrer un petit FAI).
  • Gestion de la comptabilité des adhérent⋅e⋅s flexible et automatique : https://code.ffdn.org/ARN/coin/commits/flexible-accounting
    • “Découplage” de la notion de paiements/virement et de factures (initialement très couplés dans COIN)
    • Allocation automatique des paiements/virement aux factures les plus anciennes
    • Gestion du solde du compte adhérent⋅e + affichage du solde et des paiements dans l'interface web (en plus des factures)
    • Fonction d'import des virements adhérent⋅e⋅s à partir du CSV du compte bancaire
    • Affectation automatique entre les virements et les adhérent⋅e⋅s (autant que possible en fonction d'infos présentes dans le libellé du virement)
  • Possibilité, pour les nouveaux⋅elles adhérent⋅e⋅s de s'auto-inscrire sur COIN : https://code.ffdn.org/ARN/coin/src/registration
    • Pour s'inscrire, un visiteur remplit le formulaire, il reçoit un mail de validation, il clique dessus et il est connecté directement et une indication de référence à mettre dans le libellé de son virement qui paiera la cotisation s'affiche.
    • Il est possible de désactiver cette fonctionnalité en utilisant le paramètre REGISTRATION_OPEN. Dans ce cas l'affichage est modifié pour un mode de fonctionnement où les administrateur⋅rice⋅s du FAI créent les comptes dans l'interface (rétro compatibilité avec le système des autres FAI utilisant COIN).
    • Le format des libellés de virement est à préciser dans le paramètre BANK_TRANSFER_LABEL
    • Ce code a été proposé dans l'upstream : https://code.ffdn.org/FFDN/coin/pulls/106

Travail restant à faire

Première release avec les fonctionnalités Galette + fonctionnalités comptables de COIN + affichage du solde à partir du CSV de la banque

  • Liée à la gestion automatique de compta adhérente
  • Gérer le cas où un paiement est explicitement lié à une facture
  • Ne pas laisser la possibilité d'une facture à 0 € car, comptablement, une facture correspond à un minimum de 0,01 €. Il n'est pas possible de saisir une facture de 0,00 € dans un programme de comptabilité
  • [IMPORTANT] Avoir de vrais journaux de la comptabilité adhérente “automatisée” dans COIN en cas de soucis
  • Vérifier que le découpage facture↔paiement n'introduit pas de bugs dans des parties non testées de COIN
  • Tester/adapter l'import CSV par rapport au format CSV de la vraie vie et de la vraie banque
  • Gestion des notifications par mail :
    • (pour les admins) pas de CSV importé depuis X semaines
    • (pour les admins et adhérent⋅e⋅s) facture pas payée depuis X semaines
    • (pour les adhérent⋅e⋅s) émission d'une facture
    • (pour les adhérent⋅e⋅s) réception d'un paiement
    • (pour les admins) pas de correspondance trouvée entre un paiement et un⋅e adhérent⋅e ; en attente de correspondance (nécessite probablement de créer un attribut “en attente de matching” pour les paiements)
  • Gérer les “factures” / “pièces comptables” pour les dons et adhésions. Quelle sémantique utiliser dans l'interface ? « Factures et reçus »
  • Possibilité de générer des avoirs (vérifier que c'est possible)
  • Discuter avec les développeur⋅euse⋅s de COIN pour savoir ce qu'il⋅elle⋅s pensent des modifs, idéalement pour merger avec eux. Un mail a été envoyé à la FFDN en ce sens.
  • Afficher les informations VPN/VPS/Housing de l'adhérent⋅e
  • Paramétrer COIN
  • Déployer pour de vrai
  • Importer les données depuis Galette
  • Lier le isp.json à db.ffdn.org afin de mettre automatiquement à jour dans la base de données FFDN le nombre d'adhérent⋅e⋅s à l'asso et le nombre d'abonné⋅e⋅s à chaque service

Release "manipulation des services"

  • Pilotage des services via COIN
    • État de mes services
    • Configuration de mes services (redémarrer VPS, configurer reverses DNS, etc.)
    • Téléchargement .cube
    • Assignation des IPs via COIN
    • (optionnel/bonus) Système de hook sur les événements 'facture payée', 'facture impayée', 'nouvel adhérent', … ? (Possibilité d'interface avec les services (VPS, VPN, Yunohost?))

Release esthétique

  • (optionnel ?) Avoir un CSS cool/moderne/propre

Release "liaison avec Tryton : comptabilité globale super carrée"

  • Installer Tryton (package ynh ? )
  • Tryton : créer l'opération bancaire de cotisation pour les 15 premiers euros
  • Tester Tryton et COIN afin de vérifier que le modèle est valide
    • Tryton
      • Test import banque
      • Test import Facture
      • Import de tiers
      • Saisie facture fournisseurs
      • Vérif de la structure de la BD
      • Export de certains mouvements
      • Test API : bug installation apps » passer par le client loud

COIN envoie à Tryton :

  • les nouveaux adhérent⋅e⋅s (quand le⋅a nouvel⋅le adhérent⋅e est créé dans COIN)
    • ID
    • Nom
    • Prénom
  • la facture (quand une nouvelle facture est créé dans COIN)
    • date
    • montant
    • ID adhérent
    • code comptable (credit) OU offre
    • numéro de facture
  • les paiements et leur affectation automatique

Tryton envoie à COIN

  • Liste des soldes des comptes tiers adhérents
    • ID adhérent
    • solde de son compte
  • Liste des mouvements non lettrés des comptes de tiers adhérents (= facture non payées + virement non associé à une facture)

Remue méninges pré-hackathon des besoins d'ARN en système d'information

  • Mettre à jour ce que dois payer chaque abonné⋅e. Ne pas oublier le problème numéro 1 : Les adhérent⋅e⋅s ne savent pas ce qu'il⋅elle.s doivent à l'asso !
  • Émission de facture
  • Créer des procédures automatisées pour déployer VPN et VPS
  • Relier les comptes adhérents à hub.netlib.re
  • Email automatiques (bienvenu, relances, feedback, etc…)
  • Un système de rapprochement bancaire à partir de l'export CSV des entrées sur le compte bancaire
  • Un système de localisation du stock (un pad https://pad.tetaneutral.net/p/stock ?)
  • Configurer son reverse DNS (VPN, VPS, housing)
  • Des procédures de suivis (paiement fournisseurs ?)
  • Suivi de ce qui a été fait ?
  • Génération de .cube
  • Génération du .json FFDN
  • Liaison avec wifi-with-me
  • Événement
    • Nouvelle adhésion
    • Fin d'adhésion
    • Souscription à un service
    • Nouvelle facture ?
    • Paiement de facture
    • Non-paiement de facture
    • Expiration certificat
  • Espace adhérent:
    • Mes informations (voir légalement parlant si on est obligé de stocker le nom/prénom)
    • Statut cotisation
    • Mes factures
    • Mes dons (non défiscalisés)
    • Mes services
      • Etat de mes services
      • Configuration de mes services (Redémarrer VPS, configurer reverse DNS)
      • Téléchargement .cube
    • Matériel (ce que je prête, ce que l'asso me met à disposition, ce que l'asso stocke chez moi)

Comment faire pour qu'un espace adhérent ne soit pas perçu comme un espace client et encourage plutôt au bénévolat à la participation ?

  • Espace bénévoles/CA
    • Suivi compta
      • Rapprochement bancaire
      • Écriture comptable
  • Dashboard pour bénévoles ARN ?
    • Nombre d'IP dispo par services
    • Nombre d'emplacements dispo dans la demi baie
    • Ressource utilisable pour les VPS
    • Nombre de VPN possible
    • Suivi de la conso
    • Evolution par service du nombre de souscription
    • Suivi des actions
    • Coût moyen par service ???

Comparatif des solutions existantes

  • Odoo 8, 9, 10 ??? (python 2)
    • Le gros soucis c'est la gouvernance de ce projet et sa pérénité
    • package odoo_ynh
    • Il y a quelques modules pour associations
    • Par contre, faire un espace adhérent⋅e⋅s risque d'être galère
  • Dolibar (php)
    • Utilisé par Rhizome et finalement Jocelyn code sur COIN…
    • package dolibar_ynh
cr/reunions_diverses/8_9_avril_2017.txt · Dernière modification: 2017/05/30 16:40 par lg