[noalyss-generale] nouveaux PCA, copropriété et réflexions sur noalyss

[Discussion à propos de NOALYSS , développement , support . . .]

  Bonjour,

  J'ai une question sur les développements en cours et quelques réflexions
à soumettre à propos du module copropriété et de noalyss en général.

La question : je viens de faire un "git pull" du code principal (mais, ne
souhaitant pas encore changer mon installation, je ne l'ai pas testé).
J'ai l'impression que dans la nouvelle compta analytique, les plans
comptables analytiques (PCA dans la suite de ce mail) sont définis
par journal. Est-ce le cas ? Si oui, pourquoi ?

Sinon, quelques réflexions pour la copro.

PCA pour les charges (comptes 6)
=====================

Quand on fait une dépense (comptes 6), il faut savoir qui la payera.
J'utilise pour cela la compta analytique. Afin de produire les annexes
annuelles, il faut encoder pas mal d'infos. Comme les postes de la
compta analytique ne sont pas hiérarchiques (hint : ça serait cool
comme amélioration), j'utilise plusieurs PCA :
* un pour la répartition de charge entre copropriétaire
  les activités sont les clés de répartition de la copro + les copropriétaires
  individuellement (par exemple pour une charge imputable à un seul
  copropriétaire comme le travail demandé en cas de mutation, ...)
  => PCA "obligatoire"
* un pour le type de charge. Les activités sont :
  - charges courantes (ce qui doit/devrait être couvert par le budget voté)
  - charges pour opérations exceptionnelles (analyse amiante des parties 
communes, ...)
  - charges pour travaux votés (réfection toiture, ...)
  - charges pour travaux urgents
  Ici, j'utilise aussi la notion de groupe pour séparer la première activité 
des trois autres
  => PCA "obligatoire"
* un pour les travaux et opérations exceptionnels
  Il y a une activité par travaux/opération exceptionnelle/...
  J'utilise aussi les groupes pour regrouper les activités dans les trois cas
  (op. except., travaux votés et travaux urgents)
  => PCA "optionnel" (correspond en fait à une subdivision du précédent
  pour certaines activités)
* un pour les ressources externes
  Ce plan est utilisé quand une charge doit être financée par l'utilisation
  d'une source de revenue autre que les appels de charges (intérêts d'un
  livret, ...)
  => PCA "optionnel" (la plupart des charges sont payées par appel de fond)

Il est à noter que ces PCA sont utiles indépendamment des journaux
utilisés (d'où ma question au dessus après avoir vu les logs des commits)

On devrait pouvoir faire quelques vérifications :
* les comptes 6 ne sont pas les mêmes pour les charges courantes et
  pour les charges travaux/op excep.
* il faut une entrée dans le 3ième PCA si, et seulement si, dans le 2ième
  PCA on n'est pas en charge courante,
* ...

Mais ces vérifications sont assez dures à faire si les PCA sont gérées
indépendamment du plugin copro. Dans le meilleur des mondes, il faudrait :
- que des PCA puissent être "gérés" par des plugins. Par gérer, j'entends
  que la création du PCA et la gestion de ses activités (création/modif/
  suppression) doive se faire par le plugin
- que les règles de validation puissent être spécifiées par le plugin
  (obligatoire/optionnel mais aussi contrainte d'intégrité)

Cela dit, ce point n'est pas prioritaire dans mon idée : dans un premier
temps, on peut faire ce qui est nécessaire manuellement avec une
bonne documentation.

À propos des recettes de la copropriété
========================
Les recettes de la copro sont de deux types :
- les recettes externes (intérêts, ...)
  => Ceux là ne me semblent pas poser de problème
- les appels de fonds (charges courantes (provisoires ou définitives)
  ou charges exceptionnelles)

Pour l'instant, un appel de fond est encodé avec une seule transaction.
Avantages :
* on identifie bien l'appel de fond dans la compta générale
* on peut utiliser facilement les mêmes PCA que précédemment
  => j'ai fait du code pour que le premier PCA (répartition des charges)
  soit pré-rempli à partir du budget (qui connaît les clés à utiliser pour
  les diverses dépenses) ou à partir de la clé choisie (pour un appel de
  fond par montant)
Inconvénients :
* il faut un journal de type divers (ça n'apparaît pas dans
  comptabilité/recettes)
* on n'a pas de date d'échéance et encore moins de date de
  payement (il y en aura une par copropriétaire)

Je pense de plus en plus qu'une meilleure manière de faire est
d'encoder un appel de fond avec une transaction par copropriétaire.
Avantages :
* on peut utiliser un journal de recettes
* on a une date d'échéance et de payement (par copropriétaire)
Inconvénients :
* comment éviter qu'un appel de fond soit partiellement modifié/supprimé
  => par exemple, si on supprime une transaction, faut-il supprimer en
  cascade toutes les transactions de cet appel de fond ?
* mon développement précédent devient inutile (c'est d'ailleurs un peu
  pour ça que je ne l'ai pas rendu publique) et il y a pas mal de code à
  développer (par exemple pour créer plein de transactions en une seule
  fois)

À propos de l'organisation générale du code
==========================
  J'ai l'impression qu'il y a des possibilités de factoriser de grosses
parties du code de noalyss tout en facilitant des développements
futurs de plugins particuliers. En particulier, j'ai l'impression qu'il
y a plein d'endroits où on sélectionne des comptes/transactions
puis on les affiche/imprime/exporte. Et qu'à chaque fois, le code
est réécrit car des détails changent.

  Mon idée serait d'avoir la possibilité :
- un plugin doit pouvoir indiquer qu'il étend les transactions (en gros,
  on peut faire un join ou join left ou join right de la table des transactions
  vers une table supplémentaire)
- un plugin doit pouvoir indiquer qu'il propose des sélecteurs (simple) de
  transaction supplémentaire
- une classe générique pour afficher un sélection de comptes/transactions
  L'interface ici doit être générique pour que le code qui l'utilise (impression
  du grand livre par exemple) ne connaisse pas à l'avance les sélecteurs
  affichés (ajouts de certains par les plugins par exemple)
  => il faut prévoir dès le début qu'on pourra avoir plusieurs sélecteurs dans
  une même page web (préfix pour les variables POST)
  => il faut que l'utilisateur de cette classe puisse imposer des sélections
  non modifiables par l'utilisateur (toutes les pages "impressions" ne
  pourront pas conduire aux mêmes résultats)
  => il faut pouvoir proposer un sélecteur par défaut (qui affichera le
  même genre de sélection qu'actuellement) choisi par l'utilisateur de la
  classe mais qui pourra être changé (dynamiquement avec un bouton
  "sélection étendues" ou dans les préférences ou ...) pour faire des
  sélections complexes voire très complexes (expression booléenne
  de sélection simple ou complexes, ...)
- une classe générique qui prend les résultats de la classe précédente
  et effectue une sélection d'informations. Là encore, il faut que l'utilisateur
  de cette classe puisse spécifier les info qu'il veut absolument et celles qui
  sont optionnelles pour lui.

Avec ce genre de chose, on devrait pouvoir :
- factoriser plein de code (dans la plupart des menus "impressions" au moins)
- développer plus facilement de nouvelles fonctionnalités (écran affichant
  uniquement certaines transactions, par exemple celles liées aux appels
  de fond, ...)
Et ça peut se faire progressivement :
1) mise en place du framework générique
2a) utilisation pour les nouvelles fonctionnalités
2b) remplacement progressif du code existant par des appels à ce framework
2c) développement de plugins de sélecteurs complexes qui assemblent des
  sélecteurs simples (ceux de base de noalyss ou ceux définis par les plugins)


  Voilà mes idées pour l'instant (mais avec un gros manque de temps
libre pour développer)
  S'il y a des développeurs php (ce que je ne suis pas, le codage de ces
choses me demandent donc du temps) qui souhaitent développer
noalyss soit savoir comment s'y prendre, je veux bien discuter de
ces idées et des interfaces nécessaires pour les réaliser (sous réserve
que Dany soit également d'accord avec ces propositions)

  Cordialement
    Vincent