Re: [noalyss-generale] Plugin copropriété

[Vincent Danjean]

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
>