|
From: | Mélopie |
Subject: | Re: [noalyss-generale] Réécriture du plugin COPROPRIÉTÉ |
Date: | Wed, 30 Nov 2016 22:11:28 +0100 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 |
Le 30/11/16 à 18:00,
address@hidden a écrit :
J'imagine que les procédures sont bien souvent identiques. Au niveau du développement, il faut limiter les spécificités. Pour moi qui ne suis pas programmeur, je le conçoit comme le rapport entre html et css, dans la façon de dissocier comment ça fonctionne et comment ça apparaît, à moins que cela puisse se concevoir comme la localisation d'un programme. J'imagine en fait que ce n'est pas si simple, mais il y a certainement un tronc commun à dégager.Message: 3 Date: Wed, 30 Nov 2016 15:59:50 +0100 From: Vincent Danjean <address@hidden> To: address@hidden Subject: Re: [noalyss-generale] Réécriture du plugin COPROPRIÉTÉ Message-ID: <address@hidden> Content-Type: text/plain; charset=utf-8 Bonjour, Le 29/11/2016 à 21:45, Dany De Bontridder a écrit : Très juste.Pour le point 1 , je vais déjà regarder comment avoir un écran plus potable , la configuration est un point difficile et essentielle , elle est commune jusqu'à présent à la Belgique et à la France .Voici quelques réflexions que je vous livre suite à mon expérience de syndic bénévole (en France) depuis presque 3 ans : - une copro, ça évolue. On pense tout de suite aux ventes de lots, mais il y a aussi les nouvelles clés, les clés existantes qui évoluent (pour mon cas, aménagement d'une comble en appartement => MAJ de tous les millièmes), les lots qui sont redécoupés autrement, ... Si on veut être capable de (re)générer un rapport à une date donnée, ça signifie qu'on doit garder tout cet historique. On peut aussi décider qu'on ne génère de rapport qu'avec la configuration existante. - les clés de répartition sont une donnée essentielle. Certaines sont fixes (ie définies dans le règlement), d'autres sont variables (par exemple basées sur des relevés de compteurs), il faut le prévoir - faire les calculs (et surtout les arrondis au centime près) de charges par lot (et pas par copropriétaire). Car, quand un copropriétaire vend une partie seulement de ses lots, on a besoin de l'info par lot (et il vaut mieux que la sommes de charges par lot redonne bien exactement la somme du copropriétaire). - L'idée que les clés de répartition puissent regrouper des éléments différents: pour un lot avec un garge et un lot sans garage par exemple, j'imagine qu'il y a une clé de répartition pour les appart' et une pour les garages. - Le fait qu'une clé puisse changer et pas forcément à un changement d'exercice (vente d'un lot, d'une partie d'un lot, relevé de compteur à une date quelconque). Ce serait intéressant de lister de la façon la plus exhaustive possible les cas épineux ou non, qui se présentent.Si ces réflexions peuvent vous aider, profitez en. Pour ma part, j'avais commencé ma compta avec noalyss en encodant pas mal de meta information avec les plans comptables analytiques. Ça marchait globalement bien (j'avais toute l'info dans noalyss) mais, pour l'exploiter, j'avais besoin de traitements complexes. J'extrayais donc l'info de noalyss (avec wget + des pages d'export CSV de Noalyss ou d'autres que j'avais ajoutées) et je la retraitais ensuite (principalement avec R) avant de la mettais en forme avec LaTeX. Au final, un simple 'make' me reconstruisait tous mes PDF automatiquement depuis ma compta. Je me suis trouvé sérieusement limité quand ma copropriété a évolué (nouvelles clés, nouveaux lots, ... j'ai presque tout eu) Là, c'est du pidgin pour moi.et surtout la charge de boulot pour maintenir mes extensions à noalyss était importante à chaque nouvelle version (et ce n'était clairement pas assez bien fait pour être incorporé dans noalyss). J'ai donc préféré basculer vers un enregistrement de ma compta dans des fichiers textes (format ledger) qui simplifient beaucoup la gestion de l'historique (avec git) et l'extraction de données pour traitements automatiques complexes ensuite. J'ai, par contre, perdu l'aspect interface utilisateur (qui m'a bien aidé quand j'ai débuté) et l'aspect multi-utilisateurs (que je n'utilisais pas beaucoup en pratique mais qui me plaisait). J'imagine que ça l'est aussi pour beaucoup. L'objectif serait (on peu rêver et on est là pour ça) de permettre à un syndic ou un copropriétaire novice de se sentir porté pas-à-pas pour mener à bien la tenue d'une compta formellement irréprochable, transmissible et supervisable par un tiers compétent (commissaire aux comptes) auquel on fournirait les codes d'accès adaptés pour valider, annoter ou corriger ladite compta sans trop de sueur. Pour les vidéo-conf ou tchats dont parle Dany, ce serait peut-être intéressant d'en préparer le programme sur base du plan en 6 points cité plus haut, ou d'un autre développé à la lumière des cas de figures rencontrés par Vincent.Je suis donc très content que Noalyss se développe en direction des copropriétés et je suis ces développements avec intérêt. Cordialement, Vincent Danjean Bonne soirée! |
[Prev in Thread] | Current Thread | [Next in Thread] |