[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [noalyss-generale] Plugin copropriété
From: |
Vincent Danjean |
Subject: |
Re: [noalyss-generale] Plugin copropriété |
Date: |
Mon, 28 Dec 2015 15:39:46 +0100 |
User-agent: |
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.22) Gecko/20091109 Lightning/0.8 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 |
Le 28/12/2015 12:24, Dany De Bontridder a écrit :
> Bonjour,
>
> Je commence à travailler sur les plugins . Pour l'instant je suis sur celui
> de copropriété , si vous avez des idées d'améliorations, n'hésitez pas à en
> parler.
>
> Il y a déjà des tâches sur le suivi (*http://tinyurl.com/q6rectj)*, toute
> participation bienvenue : doc , idée , code ...
Je crois que j'avais déjà mis quelques idées sur le wiki (mais je ne retrouve
plus où sur le coup).
Voici quelques idées supplémentaires après 2 ans de pratique :
A faire les calculs de répartition (appels de fond et, plus tard, répartition
des charges réelles) par lot (et pas par copropriétaire). Raison : quand un
copropriétaire vend (ou loue) une partie de ses lots, on a besoin des
répartitions par lot. Si les calculs dans la compta ont été fait par
copropriétaire, on risque quelques centimes d'écart entre la situation du
copropriétaire et la somme de ses lots.
Cela dit, même si le calcul se fait par lot (arrondi au centime pour
chaque lot puis somme), ne mettre qu'une seule transaction par copropriétaire
(sinon, le décompte par copropriétaire devient illisible)
B si possible, automatiser un peu (tout ?) la vente d'un (ensemble de) lot(s)
C si possible, automatiser les calculs de fin d'exercice :
- répartition des charges réelles
- gestion des travaux et opérations exceptionnelles multi-annuelle
(traitement différent pour les opérations closes et celles encore en cours)
[nécessite des informations supplémentaires]
- gestion des charges en payées d'avance (report sur comptes spéciaux pour
réapparaître sur l'exercice comptable suivant)
- clôture et réouverture de l'exercice comptable
D se débrouiller pour que les appels de fonds se fassent avec un journal
de vente (pour savoir si un copropriétaire est en retard de paiement) [on
en avait discuté, ce point n'était pas simple]
E prévoir le fait qu'une copropriété évolue :
- ajout de lots en cours d'année
- changement des millièmes (on a eu une expertise judiciaire qui a eu comme
conséquence un recalcul complet des millièmes, mais ça peut aussi être
dû à la construction d'un appart dans des combles par exemple)
A est technique mais simple
B est plus technique mais reste raisonnable
C se fait aussi assez bien si on la les infos. Pour ma part, je les encode
dans des PCA :
- un pour la clé de répartition à utiliser
- un pour le type de charges (courantes, travaux votés, opérations
exceptionnelles)
- un pour l'identification des travaux ou op. except (vide ssi types charges
== courantes)
- un pour les ressources affectées (en cas de revenus autres que les appels
de fond)
- un pour indiquer les charges récupérables auprès des locataires (non requis
mais
pratique si on veut pouvoir indiquer aux copropriétaires les charges
récupérables
auprès de leur locataires)
D me semble plus ardu (mais je manque de recul pour avoir une opinion tranchée)
E demandera de la réflexion
Voilà donc quelques éléments de réflexion, en espérant que ça t'aide.
Cordialement,
Vincent
> Merci
>
>
>
>
>
> ---
> NOALYSS est un Serveur de Comptabilité et de Gestion libre
>
> NOALYSS is an ERP Server opensource focused on accountancy
>