Re: [Dolibarr-dev] activité de dolibarr ? - phpcomta

[Laurent Destailleur (Eldy)]

herve couvelard a écrit :
> Non tu dis "codes la tienne, moi je code la mienne", c'est ce que l'on 
> appelle le developpement collaboratif. Pourquoi coder en double ? la 
> compta expert sera un module proprio et payant ?
Non le module que je développe sera GPL et ce module n'est pas Dolibarr. 
Ce sera une extension (module externe) et pour cette extension je n'ai 
jamais parlé de travail collaboratif. Pour quoi veux-tu m'imposer cela ? 
C'est mon choix, la raison principal est que j'ai une idée un peu 
"nouvelle" et qui me prendrait plus de temps à expliquer qu'à faire et 
je bénéficie déjà d'une aide suffisante.
Le chantier est avancé à 70%
> Remarque cela pourrait avec la gpl, puisque c'est un module externe 
> qui n'est pas LIE mais appelé avec des triggers.
Oui ceux qui veulent faire des modules proprio externes a Dolibarr pour 
s'interfacer avec Sage par exemple en ont aussi le droit. On est dans le 
monde libre n'oubliant pas. Par contre, ils ne seront alors jamais 
intégrer dans le CVS du projet.
> Il ne resterait plus qu'a rendre très difficile l'évolution de la 
> compta 'gratuite' pour pouvoir vendre la payante, mais avec un module 
> compta l'aura' de dolibbar serait parfaite, faut que j'arrete la 
> parano, mais j'ai vu tellement de truc dans le libre par exemple les 
> drivers linuxtant pour les puces modem conextant par exemple des 
> moteurs de fimrware de box ou routeur . . .
> .
>
> >Le module "compta phpcompta" est un module qui alimenterait phpcompta
> > en réaction de chaque action métier comptable de Dolibarr.
>
> C'est TA vision de ce module pourtant ce n'est pas celui que tu codes, 
> pourquoi ? MA vision serait un module vers ou ON transfererait les 
> factures en compta - ce qui est différent, MAIS il faut AVANT gérer 
> les factures au trajet-court c'est à dire saisie directe, par exemple 
> il est un peu idiot de faire un devis, une proposition, une facture, 
> une livraison pour une carte réseau à 5 euros.
Qui impose tout cela aujourd'hui ?  Dolibarr ? D'où vient donc cet idée 
de trajet imposé ? Personnellement une de mes activités n'utilise que 
les factures (ni propal, ni commande, ni livraison, ni meme banque) et 
la compta n'est faite que sur facture. Peut-etre le défaut de 
documentation est la cause de cet idée reçue ?
Donc encore, les developpeurs un peu "documentalistes" pour documenter 
ce qu'on appelle le "workflow" sont les bienvenues.
> et il faut savoir intégrer les factures de téléphone car TOUTES les 
> entreprises ont des factures de téléphones.
>
> >Dans l'initiative "compta phpcompta" (actuellement sans leader), 
> >phpcompta peut garder sa propre base, dolibarr aussi. Je ne vois rien 
> >qui empeche cela. Je le recommanderait meme.
>
> C'est stupide  par nature, cela impose d'avoir 2 moteur de bases de 
> donnée pour faire tourner son applis car erp/crm/compta sont UN seul 
> logiciel métier.
Si 2 appli peuvent tourner chacune sur plusieurs moteurs indépendent, 
rien empeche un utilisateur de décider de le mettre sur le même moteur 
dès lors qu'elles en ont un en commun. Qui peut le plus peu le moins.
Donc appel encore aux testeurs et développeurs.
* Il y a la gestion de mysql à intégrer dans phpcompta (je pense que les 
mainteneurs de ce projet apprécieront ce genre de contribution, à faire 
confirmer par eux)
* Ou bien, la gestion de postgresql à finir dans Dolibarr. Il y a un 
support expérimental mais il faut le tester et le finir. La c'est sur, 
les patch sont bienvenue.
> Dans MON cas (qui ne regarde que moi) je n'intègrerais pas 2 moteurs 
> de base de donnée sur mes machines (mysql+pgsql). de même je 
> n'intègrerais pas php + rubby, il serait dans ce cas aussi simple de 
> coder une partie erp simplifié dans phpcomta on travaillerais 
> directement à avec des documents odt putôt que pdf.
>
> >En fait le gros du travail pour gérer 90% de la compta est même
> >il ne m'en manque pas (en tout cas pas pour gérer 90% de l'activité de
> > compta).
>
> gérer 90% c'est inutile, on ne fait pas 90% d'un bilan
Beaucoup de PME pourtant gère les 10% de cas particulier en manuel en 
dehors de leur soft et font leur bilan en dehors de leur ERP. Et on 
dévelope d'abord le cas général avant de développer les exceptions. 
C'est une question d'ordre issu du bon sens. Donc quand les cas standard 
seront gérés, on pourra développer les cas particuliers et alors des 
réflexions plus profondes seront nécessaire la je partage ton point de 
vue...
> > si quelqu'un veut "diriger" le projet interface vers phpcompta mais
> > qu'il le fasse
>
>
> Il y a beaucoup d'incertitudes et seul un fou/inconscient/très_jeune 
> va prendre le risque de passer des heures à coder un truc dont il ne 
> maitrise pas un bout (le trigger) car il y a un autre projet derrière, 
> mené par le même responsable
> Pourquoi coder un truc alors qu'il y a un truc concurent fermé qui est 
> codé par un responsable du projet même, il y a un risque.
Parce que justement si tu ne veux pas utiliser le module que je 
développe (non requis par Dolibarr rappelons le) parce que tu estimes 
qu'il tarde trop a venir, cela te permet d'avoir quelquechose la ou il 
n'y a encore rien. En faisant le tiens tu n'as simplement pas a attendre 
et ne court aucun risque. Car le systeme des triggers lui ne dépend 
absolument pas de mon module mais fait parti du core de Dolibarr, donc 
tu n'as ainsi pas de dépendance et de risque de faire un dev qui ne peut 
communiquer ou qui sera géner par un autre projet identique. Même lors 
de montée de version de Dolibarr tu as la garanti que la communication 
continue. Ainsi le bon fonctionnement ne dépend que de toi...
Si tu t'y prend autrement, tu peux. Tu peux alors soumettre de gros 
patch qui touche à Dolibarr mais la tu rentreras en conflit avec 
d'autres dev et tu risques d'avoir fais des dev pour rien. Alors 
pourquoi chercher absolument à compliquer les choses et ne pas choisir 
la sécurité.
> >La aussi elle peuvent etre indépendante du moment qu'elles utilisent
> >les triggers.
>
> Pourquoi cette solution; je ne comprends pas pourquoi ce fanatisme à 
> l'égard des triggers, je dois peut-être teubé et ne pas comprendre.
Justement parce que c'est grâce à eux que la plupart des problèmes que 
tu signales disparaissent.
Mais si tu ne veux pas les utiliser, tu peux aussi. C'est ça l'OpenSource.
Mais tu prend alors le risque que si quelqu'un n'aime pas ton dev et 
décide de faire autre chose, son dev entrera en conflit avec le tien ou 
encore tu risque qu'une montée de version Dolibarr viennent casser ton 
travail. En utilisant les triggers pour les interfaces Dolibarr vers 
extérieur et en utilisant les classes métier PHP de Dolibarr 
(societe.class.php, contrat.class.php, etc...) pour les interfaces 
extérieur vers Dolibarr, tu t'affranchis de ce risque. Autre avantage, 
une solution codée par les triggers peut etre commités dans le CVS sans 
aucun besoin de validation. En effet cela ne peut faire tomber Dolibarr. 
Enfin dernièr avantage, c'est beaucoup plus simple à coder, pas besoin 
de rentrer dans tous les méandres de Dolibarr.
Maitenant à toi de faire le choix: Pérénité de tes développements 
aquises grace aux triggers ou risque que ton dev ne cole pas avec celui 
d'un autre (et donc sous entendu que tes patch soit perdus par d'autres 
patch).
N'oublions pas qu'un conseil n'est qu'un conseil, pas une obligation.
> >(A CONDITION d'UTILISER LES TRIGGERS QUI ONT ETE FAIT POUR CELA, C'EST
> >LA SEULE CONTRAINTE ET ELLE SUFFIT POUR GERER 90% DE L'ACTIVITE COMPTA
> >D'UNE PETITE SOCIETE CLASSIQUE).
>
> Tu diras ça aux impôts que tu gère 90% de l'activité compta, les 10% 
> restant c'est quoi ? ton module expert ? Pourquoi coder un module non 
> expert alors ? Sérieusement je vois pas; ou alors il y a tellement de 
> personnes qui codent sur dollibar qu'elles se marchent dessus et il 
> faut les partager sur des modules concurents pour occuper la foule.
>
> je suis désolé, mais je suis un cérébral, j'ai besoin de voir la ligne 
> d'arrivé et le chemin à parcourir avant de partir. Ensuite comme je 
> dis à mes étudiants, la programmation, c'est 80% de réflexion et 20% 
> de développement, je trouve que tu pousses trop à courir au code et 
> pas assez à la reflexion, go go go gogo oui....
Mais la réflexion aussi est bien venue sur n'importe quel module. Les 
leaders qui veulent donc gérer le chantier "réflexion" sont donc aussi 
les bienvenues.... (j'entends réflexion et non juste intention signalée 
par mail). A suivre donc...
Pour info, les réflexions les plus avancées, sur le sujet, dans le monde 
libre sont selon moi l'initiative "PASCOLI" (Projet Comptabilité Libre) 
initié par l'association April:  http://wiki.april.org/Comptabilite.
Je les suis depuis un moment et m'appuit dessus pour le module compta 
expert.
> hervé - sincèrement désolé d'avoir perdu plus d'une 1/2 heure à faire 
> le premier mail qui n'a visiblement pas été lu ou pas compris et 1/2 
> heure à faire se second mail qui aura le même impact.
You welcome.

Le travail communautaire c'est avant tout des développements modulaires 
afin de garantir les indépendances des équipes. Il est clair que ceux 
qui partent dans l'esprit de vouloir faire un gros tout plutôt que des 
modules ou briques d'extensions se heurteront toujours à ce genre de 
problèmes dans le cadre d'un projet communautaire sur un logiciel au 
spectre aussi large que celui d'un ERP/CRM.

--
Laurent Destailleur.
---------------------------------------------------------------
EMail: address@hidden
Web: http://www.destailleur.fr
IM: IRC=Eldy, Jabber=Eldy

AWStats (Author) : http://awstats.sourceforge.net
Dolibarr (Contributor) : http//www.dolibarr.com
CVSChangeLogBuilder (Author) : http://cvschangelogb.sourceforge.net
AWBot (Author) : http://awbot.sourceforge.net