dolibarr-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Dolibarr-dev] Documentation


From: Benoit Mortier
Subject: Re: [Dolibarr-dev] Documentation
Date: Tue, 12 Oct 2004 07:48:45 +0200
User-agent: KMail/1.6.2

Le lundi 11 Octobre 2004 23:59, Eldy a écrit :
> Rodolphe Quiedeville wrote:
> > Salut,
> >
> > Je rappelle l'adresse du wiki des dev à l'occasion de l'arrivée d'un
> > nouveau développeur.
> >
> > http://www.dolibarr.com/wikidev/index.php/Accueil
> >
> > Je sais que vous êtes surement comme moi assez allergique à écrire de
> > la doc, mais cela devient de plus en plus critique, j'ai moi même du
> > mal par moment à tout suivre, et je corrige de plus en plus de bug
> > généré par les nouveaux arrivants par méconnaissance de
> > l'environnement global.
> >
> > A moins de bosser sur des parties bien spécifiques du code, il serait
> > bien de communiquer un peu plus, et au minimum sur cette liste.
> Donc, voici quelques mots pour rattraper mon retard :
>
> Personnellement je travaille surtout sur :
>
> - l'internationnalisation: C'est un chantier permanent (surtout que
> j'attaque tous les modules en même temps) mais ce qu'on peut en dire est
> dispo à
> http://www.dolibarr.com/wikidev/index.php/Documentation_traducteur
>
> - la doc doxygen: Son grand avantage est de voir (une fois toutes les
> sources commentés) les différences dans l'organisation des sources ou de
> mettre en évidence
> la redondance de code ou fonctions. A ce propos, la doc doxygen
> représente à ce jour 1500 fichiers et cela va encore grossir, je suggère
> donc de ne pas inclure la doc doxygen dans les sources CVS mais juste le
> script perl (qui existe dejà sous le nom dolibar-doxygen-build.pl) qui
> permet de la générer. A la charge de la personne qui fait le package de
> distribution (rpm, deb ou zip) de générer la doc si il veut l'inclure.
> Cela permettrait d'éviter d'avoir 1500 fichiers (et à terme
> probablemenent 3000) qui ralentisse les update cvs. Je fais le ménage ?

D'accord, ainsi que les premieres docs non doxygen qui trainent toujours 
dans le cvs.

le reperoire dolibarr-phpdoc

> Mes chantier futurs :
>
> - Développer/terminer la gestion des "caisses", sur le même modèle que
> les comptes bancaires. Je ferais donc un plagiat de la gestion des
> comptes bancaires pour gérer des caisses de liquides, en enlevant
> l'aspet "rapprochement" qui n'a pas de sens sur une caisse. Le module
> caisse ne servirait qu'aux utilisateurs qui gèrent une caisse (comme les
> commerçant) ou aux associations (qui ont souvent une caisse liquide
> également). On pourrait créer autant de caisse que l'on veut
> (actuellement une seule est permise et non intégré dans les autres
> modules), comme pour les comptes bancaire. Finir ce module est une de
> mes priorités futures car c'est un prérequis pour ma deuxième priorité :

cela m'interesse fortement

> - La comptabilité: Le but est de permettre à qui utilise de dolibarr de
> pouvoir sortir des rapports officiels comptables (bilan, compte de
> résultat, grand livre) sans connaissance en compta. Je vois 2 modes de
> travail pour la gestion comptable qui sera au choix de l'utilisateur.
> * Le mode manuel: Dans ce mode l'utilisateur, lorsqu'il saisie une
> transaction bancaire ou une facture, saisit les comptes comptables de
> débit et crédit sur lesquels il impute ces mouvements. Ce mode la, je le
> mets de côté pour l'instant, je ne m'y attaquerais qu'après le mode
> automatique et sous réserve que ce soit la vocation de dolibarr de faire
> de la compta détaillée.
> * Le mode automatique: L'utilisateur n'a rien à faire de particulier si
> ce n'est utiliser les fonctions de dolibarr (factures, comptes
> bancaires). Comme pour les rapports officiels, les transactions doivent
> etre classés dans des comptes normalisés, j'ai ajouté une table appelée
> llx_c_accounttingsystem dans laquelle on a la liste de tous les comptes
> qui existent (je n'ai saisi que le Plan de Compte Général Français
> Abrégé pour l'instant qui est suffisant pour une PME/PMI ou un
> indépendant). C'est assez difficile à expliquer par écrit comment ca va
> fonctionnera car c'est de la compta et c'est assez compliqué, aussi je
> préfère attendre d'être avancé un peu plus sur le développement car ce
> sera alors beaucoup plus simple d'expliquer le fonctionnement des
> rapports comptables, avec des exemples, une fois que ces rapports seront
> disponibles. Je fournirais donc des explications ultérieurement dans le
> wiki au fur et à mesure que j'ajouterais ces rapports.

si tu m'explique un peu plus en détail je peut mettre le PCMN ( plan 
compable minimum normalise belge) aussi dans le système

> > Par exemple j'ai vu une modif des constantes qui ajout un email pour
> > du mailing vers les clients/prospects, cette fonctionnalité est assez
> > stratégique et demandée par beaucoup d'utilisateur, les dev
> > pourraient-ils nous en toucher quelques mots ici.
>
> Ca m'interesse aussi une telle fonction. Ca marcherait comment ?

ce qui est dans le cvs est une version beta qu'un de nos clients avait 
besoin pour un mailing groupe

Pour l'instant elle prend juste tout les prospects et envoie un mail avec un 
sujet et un corps de texte, elle va automatiquement mettre dans les actions 
une action réalisée genre envoi email.
 

la deuxieme version devrait voir le jour le semaine prochaine ;-)

Cette deuxieme version devrait permettre d'ajouter des attachements, 
utiliser la classe dolimail ;-), permettre d'envoyer a des prospects qui 
non pas encore eu de mail etc...

Les fonctionnalites sont encore en discution avec mon collegue.

Toute les idées sont les bienvenues

Je travaille sur les modules suivants, par ordre d'importance :

1) Finir le support postgresql : j'ai pousse une nouvelle version des tables 
dans le cvs

2) Ameliorer le programe d'installation : supporter les deux databases sans 
problèmes

3) Passer le système d'authenfication en ldap en plus des insertions dans la 
base de données, ce qui permettrait de se connecter sur webcalendar et 
d'autres applications de manière standardisée.

Améliorations prévues :

4) creer un repertoire classes dans le htdocs et y mettre toutes les classes 
qu'on trouve dans le root de htdocs

5) permettre d'utiliser les libraries du système pour fpdf etc.. nécéssaire 
pour 6) 

6) Faire un package debian

Voila,

Toute les critiques sont bienvenues

-- 
Benoit Mortier
OpenSides sprl
Linux Engineer




reply via email to

[Prev in Thread] Current Thread [Next in Thread]