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

[Laurent Destailleur (Eldy)]

herve couvelard a écrit :
>  Je voudrais également dire à ceux qui critiquent que le
> > manque de diplomatie ne fera pas avancé le projet, et qu'il serait plus
> > judicieux d'apporter des remarques constructives qui font évoluer ce 
> > logiciel
> > si prometteur.
En effet, je dirais meme pire, cela le ralenti.
> > Nico
>
> Bonjour,
>
> Je suis entièrement d'accord avec ce point, MAIS, il vaut mieux des 
> critiques que du silence.
>
> Lorsque j'ai contacté dolibarr, il y a longtemps, personne ne m'a 
> répondu, et j'avais codé AVANT une journée pour 'voir', je n'ai pas 
> sorti de patch car c'était juste une proff of concept de 
> transformation en écriture comptable suivant des modèles de moulinette 
> et un travail de compréhension sur la structure dolibarr. je n'ai pas 
> eu de réponse, même pas de bonjour, bienvenu, qu'est-ce que tu 
> veux_faire/fais , quel est ton expérience etc... Rien que le silence, 
> je me proposais de travailler sur la compta (la VRAI avec bilan et tout).
> Devant l'absence de réponse et la structure du code, qui est 'assez 
> complexe' [et qui pourrait être simplifiée], j'ai laissé tomber (c'est 
> a dire repoussé ultérieurement en me consacrant à autre choses - car 
> effectivement les gens ont d'autres  activités, une vie sociale et que 
> les journées de travail peuvent faire difficilement plus de 12/15 
> heures.)
>
> 6 mois plus tard, une autre personne parle de compta et même topo, on 
> lui dit un module expert est en cours (en gros : dégage),
Qui as dit cela ? J'ai dit que "MA" solution de compta expert est en 
cours et est fermé (car peut etre certains préfère attendre meme si je 
suis incapable de donner de date de dispo). Mais que tout autre 
initiative concurrente est la bienvenue (je me suis meme proposé sur la 
page wiki pour apporter conseil pour tout autre initiatives concurrente. 
Attention à bien lire !
> puis intervient la synergie avec phpcompta que je connais aussi 
> puisque je pense/pensais faire un portage mysql. Ensuite le troll 
> mysql/pgsql est intervenu (j'ai même marché dedans) et plus rien, 
> devant l'abscence de réponse clair en provenance de dolibarr, dany a 
> aussi laissé tombé alors que ce n'est pas un branleur dany, il "porte" 
> phpcompta, DONC il y a une problématique qu'il serait bon de 
> résoudre[1]. Je n'ai pas la prétention d'apporter une réponse dont 
> personne ne veut, juste mon oeil extérieur de contributeur frustré et 
> raté.
>
> J'adore la remarque : apporter un patch, on va l'intégrer.On peut 
> faire un patch de 50 lignes pour corriger un bug ou ajouter un lien, 
> une fonctionnalité, mais un patch de 2000 lignes pour la comta, 
> comprenant la modification de tables sql, créations de nouvelles, la 
> modification de certaines structures j'aimerais bien voir cela en 
> fait.[2]
Et si, un patch de 2000 lignes s'intègre sans problème ! 
Je considère meme cela comme un patch de taille moyenne.
> Si une compta experte est en cours ou trouver le patch pour voir ou 
> cela en est ? comment travailler dessus en sachant que notre travail 
> sera rejetté car non compatible avec ce qu'il y a en cours.
> Doit on faire une compta experte ou un 'appel extérieur phpcompta', 
La encore je fais un redit (Merci de bien lire les mails). Ce sont 2 
initiatives différentes:
La "compta experte" est un module indépendant qui ne nécessitera pas 
phpcompta.
Le module "compta phpcompta" est un module qui alimenterait phpcompta en 
réaction de chaque action métier comptable de Dolibarr.

Ces sont deux projets différents tous les 2 très utiles mais qui peuvent 
etre menés sans aucun lien entre les 2. L'utilisateur choisirait lequel 
des 2 il veut utiliser. Ou un 3eme si quelqu'un.
> doit on passer phpcompta en mysql ?
Je ne vois pas pourquoi. 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.
> Plein de questions qui restent sans réponses. Devant ces incertitudes, 
> nous ne savons pas encore si nous désirons intégrer dolibarr/phpcomta 
> dans nos configurations, car même si le projet est VIVANT et 
> PRODUCTIF, il nous semble un peu FERME (mais peut être est-ce une 
> impression !). Ce n'est pas la fermeture en soit qui nous dérange, on 
> s'en fout de ne pouvoir commiter nous même, mais il n'y a pas de 
> discours CLAIR sur ce qu'il se fait, ce qui doit se faire, comment, 
> avec qui, dans quel ordre. une visons à moyen terme. un projet : ou 
> est dolibarr dans 6 mois ?
>
> Pour ajouter de la compta et/ou une interface phpcompta IL FAUT un 
> cadre CLAIR ET DIRECTIF ou tout le monde sache dans quel sens cela se 
> déplace pour ne pas travailler pour rien, ou alors (et nous ne le 
> désirons pas) il faut prendre le dernier cvs à jour et travailler en 
> interne sur SA propre version et intégrer des diffs manuellement au 
> fur et  mesure que dolibarr avance: cela s'appelle un FORK sauvage et 
> c'est_mal(t).
Mais ce cadre directif a déjà était donné !
Donc je répète, un module phpcompta est le bienvenu et pour le réaliser 
il n'y a pas besoin d'un gros patch !
Il n'y a meme pas besoin de modifier Dolibarr en fond. En fait le gros 
du travail pour gérer 90% de la compta est même possible sans modifier 
Dolibarr (a l'exception d'ajouter des entrées dans le menu vers des 
nouvelles page issus du module phpcompta,  comme la page de 
configuration des identifants de connexion à la base phpcompta, infos 
qui seront utilisé par les triggers, ou des pages de reportings, mais 
ajouter des entrées dans un menu c'est pas un gros patch).
Tout le reste s'intègre grâce au systeme des triggers Dolibarr. Un 
module d'intégration à phpcompta peut donc être réaliser sans 
difficultés sur le même principe que le module d'interface avec 
Webcalendar qui s'interface à le calendrier sans code dans Dolibarr 
(probablement moins de 100 lignes spécifiques ont été mises dans 
Dolibarr et 100 lignes, c'est absolument pas un gros patch !). Et 
webcalendar reçoit plus d'évenement que la compta (car en plus des 
paiement, commandes, etc, le module webcalendar réagit aussi aux 
évenement création d'utilisateurs, etc...)

Sinon tu évoque le fork. Un fork n'est pas mal en soit. Le principe de 
la GPL est justement de permettre cela. Qd deux grands mouvements 
d'évolutions sont souhaités pour satisfaire 2 besoins complètement 
différents et que les modifications pour cela ne peuvent coexsiter, 
c'est nécessaire... Mais ici ce serait un gaspi car si le but est 
d'intégrer phpcompta, il n'y a absoluemnt pas besoin de cela. Le plus 
dur a été fait grâce aux triggers. Et si cette principe est utilisé il 
n'y a aucun risque de casser quoi que ce soit. Le module peut etre 
intégrer sans risque (quelque soit la taille du patch, 10 000 à 20 000 
lignes ne me semble pas exclut, on a fait pire). En effet, si le 
principe des triggers est utilisé, dans le pire des cas, ce qui peut 
arriver c'est juste que le module soit mal fait et que l'utilisateur 
doivent le désactiver parcequ'il ne marche pas mais cela ne dégradera 
pas Dolibarr. L'architecture modulaire sert à cela. Et si il n'y a pas 
assez d'evenement gérer par les triggers, je suis pret à en intégrer 
autant que nécessaire, mais tous ceux requis pour une compta sont déjà 
la normallement puisque je fais moi meme un module compta expert 
indépendant de Dolibarr et qui se base dessus et il ne m'en manque pas 
(en tout cas pas pour gérer 90% de l'activité de compta).

Maintenant il ne suffit pas de dire y a plein de monde qui veulent 
faire, il  faut le faire. Donc je répète si quelqu'un veut "diriger" le 
projet interface vers phpcompta mais qu'il le fasse mais surtout qu'il 
le FASSE et non pas qu'il se contente de dire faudrait faire (pour 
l'instant c'est surtout ce qui se passe, dommage), mais j'ai espoir car 
ce serait une énorme plus value !.
Et je répète pour la nième fois, ceci peut être intégrer les yeux fermé 
à Dolibarr du moment que le développement s'est appuyé sur le principe 
des triggers. C'est la seule directive qui soit nécessaire !
Donc avis aux porteurs du projet phpcompta, on attend tous avec 
impatience une livraison d'un tel dev !
Pourquoi avoir arrêté après une bonne lancée... dès lors que les 
triggers sont utilisés, ce projet peut être mené avec une aide des 
équipes de Dolibarr très minime. Il y a déjà tout ce qui faut pour gérer 
le gros du travail. Après oui il y a des spécificités comme les factures 
de téléphone, qui nécessite une modif plus de fond de Dolibarr mais 
attendons d'avoir déjà le coeur capable de gérer 90% des cas avant de 
vouloir gérer les 10% manquants.
> Je/nous avons un peu de travail en retard, donc nous pouvons repousser 
> notre décision d'intégration d'un erp/crm/compta et le choix est assez 
> large, nous en avons essayé pas mal, des biens et moins bien. Dolibarr 
> et phpcompta nous semble les 2 sur la bonne voie, il serait dommage de 
> ne pas intégrer ceux-la pour un simple problème de COMMUNICATION.
En effet, cela viendra mais personnellement je ne peux travailler sur 2 
modules différents, voila pourquoi pour ce qui est du module "interface 
phpcompta", je compte sur les soumissions extérieurs. J'ai mis en place 
les triggers justement pour que d'autres ensuite puissent réaliser ce 
genre de module sans être dépendant de l'équipe Dolibarr. Donc go go go...

Et rien n'empeche encore d'autres initiatives. La aussi elle peuvent 
etre indépendante du moment qu'elles utilisent les triggers. C'est 
dailleurs le cas de la compta expert en cours mais si un autre projet 
compta expert bis peut se faire, pas de problème. 3 c'est miexu qu'un.
Je n'ai jamais dit qu'il ne fallait qu'1 initiative. Bien au contraire. 
L'utilisateur peut très bien avoir le choix entre le module initiative1 
ou initiative2 ou encore initiative intégration phpcompta. C'est 
justement pour cela que la seule contrainte est d'utiliser les triggers 
car cela permet plusieurs modules issus de groupes de travail différents 
sans problème majeurs de conflits. L'utilisateur activera le module qui 
l'intéresse.

Et la aussi je répète ce que j'ai déjà répondu à ceux qui veulent, je 
veux bien aussi aider/conseiller ces autres initiatives mais je n'ai pas 
le temps de développer sur plusieurs projets en même temps. Mais je 
reste convaincu qu'un module d'intégration avec phpcompta pourrait etre 
géré/mené par une autre équipe sans problème (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).

Bon maintenant donc assez parlé, eh bien au boulot !

--
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