Re: [Phpcompta-contrib] contributeur...

[herve couvelard]

je recopie mon précédent mail, je l'ai pas vu passer..

Bonjour,

je commence tout juste à regarder et j'ai envoyé sur la liste un visuel 
de ma graphiste. L'objectif est en même temps (quitte à repasser dans le 
code) de retoucher le code pour proposer des améliorations, et changer 
un peu le style css.
La compta francaise est* supporté puisque c'est une partie double, 
maintenant tout n'est pas pret pour être l'unique logiciel de compta 
complet et indépendant, les bilans et compte de résultas sont au format 
belge, mais ce n'est pas long à écrire, je n'ai pas vu de déclaration 
mensuelle de TVA etc . . . .
- En clair NON c'est pas un logiciel compta pour la france MAIS oui ca 
va le devenir car je/avec_ceux_qui_veulent le réaliserait pendant le 
portage.
- Le portage sous mysql va sa faire en archirecturant pour que le 
portage puisse se faire sur toutes les bases de données ensuite, donc ce 
ne sera pas le plus vite possible car il faut bien refléchir avant 
d'agir ;-) .
- Pour Dolibar/phpcomta car il va y avoir un bout de erp dans phpcompta, 
j'ai vu les premisses dans les menus. L'objectif que je défendrais est 
un erm plus court (c'est à dire plus proche dans la gestion client) pas 
forcement comme dolibarr qui est surdimensionné pour plein de pme. un 
erp beaucoup plus simple serait le bienvenue sur le marché. J'ai prévu 
aussi de faire un api d'import d'autres logiciels pour permettre à 
dolibar d'ere le soft compta de plein de crm/erp car nombre d'entre eux 
n'ont pas de compta partie double 'facile' (sans magouille) et COMPLETE 
(jusqu'au bilan) et pas juste une compta client fournisseur.
Une des solutions est une import bloc : toutes les écritures suivant un 
format cvs pré-établie (ou avec moulinette transformante) ET un import 
en séquentiel par exemple pour coupler un autre soft en direct ex :
import_telecom (134,45)-> passe les 3 écritures suivant modele 
import_telecom présent dans phpcompta.
J'ai prévu également un module import-export mysql<--> postgrsql pour 
faciliter des migrations inter-base et la vérifiation de la cohérence 
des 2 applis.

voici copied'un mail avec dany sur nos échanges sur le portage
---------------Mail 1 ------------------------------------
DANY
> Oui, je voulais aussi te dire, ok pour *ajouter* le support MySql, 
>mais Postgresql doit rester disponible, donc tu vas devoir entre autre

HERVE
Oui, bien entendu, je n'avais même pas imaginé que ce puisse être autrement.

> 1) Ajouter dans setup.php, la possibilité de choisir soit l'un soit 
>l'autre ou alors un paramètre dans constant.php à changer manuellement.


Probablement pour le moment un paramètre manuel dans constant.php pour 
le moment, on verra a pouvoir choisir dans le setup, mais on en est 
malheureusement pas là. Je me suis fadé l'installation de pgsql juste 
pour voir que mes modifications ne heurtent pas pgsql avant de te faire 
un diff.


> 2) si tu changes du code php, faire en sorte que psql soit toujours 
>fonctionnel donc pas de changement du style: remplacer pg_fetch par 
>mysql_fetch, il va p-e falloir utiliser une bibliothèque pour 
supporter >les 2 ou une petite classe db pour les connections, execution 
de query >et le retour de tableau (pas longue du tout), mais comme cela 
ne >suffira pas, il y aura p-e des portions de code du style :
> if ( mysql_support  == true )     {
>     $sql_query="wwww";
>      }     else     {
>     $sql_query="XXXXX";
>     }
> $db->ExecuteQuery($sql_query);

Je ne sais pas encore comment traiter la chose, je vais essayer 
différentes choses et je te proposerais un/des trucs avec de me lancer 
en vrai. Est-ce que certaines optimisation de code peut être proposé en 
même temps (quite à repasser pas mal de chose, autant permettre un oeil 
neuf de mettre son grain de sel ?)

Pour la première idée général c'est de faire une strucutre

sql
     -fichier-commun.php
     -fichier-commun2.php
     -/pgsql
        -fichier_base1.php
           [ function toto(){}
             funtion tata(){}
       ]
        -fichier_base2.php
     -/mysql
        -fichier_base1.php
          [ function toto(){}
            funtion tata(){}
       ]
        -fichier_base2.php
[....]
Avec dans les fichiers_basesX.php QUE des fonctions sql-> retour tableau

cela des avantages et des inconvénients
Avantages -> il n'y a pas besoin de rescroller tous les fichiers
           'adverses' pour modifier des choses.
         -> On évite des if et des switch un peu partout
         -> Tout le code de chaque base de donnée est centralisé au même
            endroit.
    -> il est facile de coder pour une nouvelle base de donné : on
           copie l'arborescence de la bbd la plus proche de la nouvelle
           et on retouche les fonctions sql.

Inconvénients -> il faut savoir ce qui se passe dans le fichier
                 'adverse'(mais normalement on le sait en intégrant
                  les diffs)
              -> il faut 'écrire' les fonctions 'mirroirs' pour que
                 l'applis fonctionne sur les 2 bases.
              -> il faut retoucher à la structure de l'appli pour
                  séparer les fonctions avec sql des fonctions sans sql.


Est-ce que c'est une idée stupide ?
Si non stupide comment faire :
créer des nouveaux fichiers sql en supprimant ces fonctions des fichiers 
mélangés au fur et à mesure ?


>3) j'aimerais favoriser les procédures stockées

Euh.... je ne connais pas et ce n'est pas dispo mysql 4. Mais l'un 
n'empèche pas l'autre.

> 4). un bon travail d'équipe c'est quand on discute souvent de ce 
qu'on >fait, de ce qu'on veut, peut faire ;-)


Oui, je peux avoir tendance (et aimer) discuter\wtroller sur le bien 
fondé de ce que je fais (et je suis d'accord avec moi) donc je 
n'enverrais jamais un patch de 500 Ko, mais des 'petits bouts' proof of 
concept pour avoir ton avis.

> A méditer et discuter:
> constant.php
> -----------------
> $database="mysql";
>
> database.inc.php
> -----------------------
> require_once("constant.php");
>
> include ("class_".$database."_support.php");
>
>
> class_postgresql_support.php
> ----------------------------------------
> transformer postgres.php en object et intègrer ici.


J'aime pas l'objet en client serveur (vieux troll réchauffé), je prefère 
coder moins vite et avoir un code plus véloce. Si je me fais rien de 
bien/facile/portable/intégrable on reviendra sur cette idée ensuite.
------------------------------------------------------------------------------


Donc voila ou on en est. je fais des expérience en ce moment ( et tout 
le monde peut en faire) pour chercher le moyen le mieux pour facilter
1 - le maintien des 2 branches
2 - permettre la mise en place *facilement* d'autres branches.

je suis a l'écoute de toutes les idées.

voila...
hervé
 je reposte le lien du graphique si il était pas passé à la postérité
:-)


http://www.patrimoine-pour-demain.com/php_compta.png




Marc Barilley a écrit :

> Bonjour,
>
> Je me présente : je m'appelle Marc Barilley et je suis développeur. 
J'ai regardé PHPCompta il y a un certain temps lorsque nous cherchions, 
dans ma société, des outils nous permettant de faire notre comptabilité. 
A l'époque, la compatibilité avec la norme française ne semblait pas 
acquise (nous sommes une société établie à Paris). Il semble que ce soit 
maintenant supporté, ce qui m'a tout simplement amené à m'intéresser à 
nouveau au projet.
> Par ailleurs, je suis aussi de très près le développement de Dolibarr 
auquel j'ai apporté quelques contributions.
> J'ai lu les archives des listes de diffusion pour voir ce qui se 
passait sur le projet et arriver avec déjà un peu de "background". Je 
peux consacrer du temps au développement d'outils lorsque cela profite 
aussi à ma société. Notre philosophie est de profiter un maximum du 
logiciel libre et de rendre un maximum à la communauté lorsque nous 
développons sur des outils de ce type. Aujourd'hui, nous sommes donc 
très intéressé par PHPCompta.
> Par contre, il y a principalement trois points qui nous empêchent de 
déployer et de profiter immédiatement de ce logiciel :
> - la norme comptable française est-elle bien respectée ? je pense 
qu'il est assez facile de répondre à cette question par un oui/non ;-)
> - nous disposons d'un serveur dédié mais celui-ci ne comporte pas de 
base PostgreSQL, seulement un MySQL. Pour des raisons sur lesquelles je 
ne m'étendrai pas ici, je ne souhaite pas installer de serveur 
PostgreSQL sur ce serveur. J'ai lu dans les archives qu'un portage vers 
MySQL est en cours. Où en est-il ? Je suis près à donner un coup de main 
pour faire avancer le schmilblick le plus vite possible, ce point étant 
réellement bloquant pour nous.
> - comme mentionné plus haut, nous utilisons Dolibarr pour notre suivi 
commercial. Le projet Dolibarr est en ce moment en pleine effervescence 
côté organisationnel et fonctionnel. Une grosse discussion a eu lieu 
récemment sur l'opportunité ou non d'intégrer un système comptable dans 
Dolibarr. Moi, je pense que si un logiciel comptable existe déjà, autant 
l'utiliser et ce, d'autant plus si ses sources sont ouverts. Ce qui 
m'intéresse est donc de développer une passerelle entre les deux 
applications pour éviter les doubles saisies (sincèrement, je ne me vois 
pas expliquer à mon gérant qu'il devra maintenant saisir deux fois les 
factures : une dans Dolibarr et une dans PHPCompta).
>
> Voilà où en sont mes réflexions. Je suis prêt à m'investir dans le 
projet pour qu'il réponde à mes attentes. D'après les archives de liste 
que j'ai consultées, il semble que je ne sois pas le seul à exprimer ces 
besoins. La communauté y gagnerait donc aussi.
>
> Je voudrais commencer par apporter ma contribution au portage MySQL. 
Peut-on me faire un petit topo de ce qui est fait / reste à faire ? 
Quelle est la branche CVS concernée ?
>
> Merci.
>
> Marc Barilley
> Océbo
>
>
>
> _______________________________________________
> Phpcompta-contrib mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/phpcompta-contrib
>





Marc Barilley a écrit :
> Bonjour,
>
> Je me présente : je m'appelle Marc Barilley et je suis développeur. J'ai 
> regardé PHPCompta il y a un certain temps lorsque nous cherchions, dans 
> ma société, des outils nous permettant de faire notre comptabilité. A 
> l'époque, la compatibilité avec la norme française ne semblait pas 
> acquise (nous sommes une société établie à Paris). Il semble que ce soit 
> maintenant supporté, ce qui m'a tout simplement amené à m'intéresser à 
> nouveau au projet.
> Par ailleurs, je suis aussi de très près le développement de Dolibarr 
> auquel j'ai apporté quelques contributions.
> J'ai lu les archives des listes de diffusion pour voir ce qui se passait 
> sur le projet et arriver avec déjà un peu de "background". Je peux 
> consacrer du temps au développement d'outils lorsque cela profite aussi 
> à ma société. Notre philosophie est de profiter un maximum du logiciel 
> libre et de rendre un maximum à la communauté lorsque nous développons 
> sur des outils de ce type. Aujourd'hui, nous sommes donc très intéressé 
> par PHPCompta.
> Par contre, il y a principalement trois points qui nous empêchent de 
> déployer et de profiter immédiatement de ce logiciel :
> - la norme comptable française est-elle bien respectée ? je pense qu'il 
> est assez facile de répondre à cette question par un oui/non ;-)
> - nous disposons d'un serveur dédié mais celui-ci ne comporte pas de 
> base PostgreSQL, seulement un MySQL. Pour des raisons sur lesquelles je 
> ne m'étendrai pas ici, je ne souhaite pas installer de serveur 
> PostgreSQL sur ce serveur. J'ai lu dans les archives qu'un portage vers 
> MySQL est en cours. Où en est-il ? Je suis près à donner un coup de main 
> pour faire avancer le schmilblick le plus vite possible, ce point étant 
> réellement bloquant pour nous.
> - comme mentionné plus haut, nous utilisons Dolibarr pour notre suivi 
> commercial. Le projet Dolibarr est en ce moment en pleine effervescence 
> côté organisationnel et fonctionnel. Une grosse discussion a eu lieu 
> récemment sur l'opportunité ou non d'intégrer un système comptable dans 
> Dolibarr. Moi, je pense que si un logiciel comptable existe déjà, autant 
> l'utiliser et ce, d'autant plus si ses sources sont ouverts. Ce qui 
> m'intéresse est donc de développer une passerelle entre les deux 
> applications pour éviter les doubles saisies (sincèrement, je ne me vois 
> pas expliquer à mon gérant qu'il devra maintenant saisir deux fois les 
> factures : une dans Dolibarr et une dans PHPCompta).
>
> Voilà où en sont mes réflexions. Je suis prêt à m'investir dans le 
> projet pour qu'il réponde à mes attentes. D'après les archives de liste 
> que j'ai consultées, il semble que je ne sois pas le seul à exprimer ces 
> besoins. La communauté y gagnerait donc aussi.
>
> Je voudrais commencer par apporter ma contribution au portage MySQL. 
> Peut-on me faire un petit topo de ce qui est fait / reste à faire ? 
> Quelle est la branche CVS concernée ?
>
> Merci.
>
> Marc Barilley
> Océbo
>
>
>
> _______________________________________________
> Phpcompta-contrib mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/phpcompta-contrib