dolibarr-dev
[Top][All Lists]
Advanced

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

Re: [Dolibarr-dev] Documentation


From: Rodolphe Quiedeville
Subject: Re: [Dolibarr-dev] Documentation
Date: Tue, 12 Oct 2004 10:06:31 +0200
User-agent: Mozilla Thunderbird 0.8 (X11/20040926)

Benoit Mortier wrote:
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

Cette partie est assez critique et non prioritaire à mon avis dans un premier temps.

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

idem 4, je préfère embarquer le code, vu les problèmes que l'on a eu avec pear je sui frileux pour utiliser les librairies externes, de plus la librairie pdf n'est pas très souvent mise à jour et suffisemment light pour etre embarquée.





reply via email to

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