[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Phpcompta-contrib] contributeur...
From: |
herve couvelard |
Subject: |
Re: [Phpcompta-contrib] contributeur... |
Date: |
Wed, 10 May 2006 21:53:50 +0200 |
User-agent: |
Mozilla Thunderbird 1.0.2 (X11/20051002) |
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
Re: [Phpcompta-contrib] contributeur...,
herve couvelard <=
Re: [Phpcompta-contrib] contributeur..., herve couvelard, 2006/05/10