Le 2 octobre 2011 19:43, Cyrille de Lambert <[email protected]>a écrit :
> OpenERP est trop lord pour pas mal d'entreprise. Très coûteux à mettre en > place pour des petites PME/TPE. > Dolibarr représente un atout important, tant en terme d’ergonomie qu'en > terme de performances. > Par contre, il manque des atouts importants pour les entreprises : > > - Règles de prix impossibles à utiliser en masse > - Produits déclinables inexistants > - Export non filtrables > - etc ... > > > Je rajouterai la partie comptable et analytique > > > Ça fait partie des thèmes sur lesquels on dois bosser et qui me semblent > plus urgents que les aspects purement techniques. > C'est le fonctionnel qui attire l'utilisateur final. > > > > Le 02/10/2011 10:28, olivier geffroy a écrit : > > Nous étions en offre saas "openerp online" pour un client et je suis > extrêmement déçu à la fois par ce projet "open-source" et la société Openerp > > Il manquait a dolibarr pour ce client : > > - module compta > > Ce module fobctione très bien mais il faut configurer le plan comptable > La partie POS génère la moitié des écritures comptables et dés que l'on passe en multi société la compta devient un vrai problème surtout si personnalisation du plan comptable et je passe sur les déclarations de TVA, grand livre et journaux ....... on est très très loin d'un sage compta ou d'un compta expert.(mon client est un ancien commissaire au compte et la compta sous openerp l'a définitivement dégouté du produit) > > - module POS > > Exacte. Comme sur Dolibarr, l'idéal est d'intégrer OpenBravo POS. > Nous avons déjà fais une intégration OpenERP/OpenBravo POS. Nous le faisons > dès que nous pouvons avec Dolibarr. > J'utilise openbravo pos pour mes restaurants et j'avoue qu'une liaison openbravo pos avec dolibarr serait un plus > > - module GPAO > > Nous avons créé un module basé sur la norme OBM/ABE -> > http://www.tbm-software.com/ConceptOBMABE.html > J'aimerais faire un jour la même chose avec Dolibarr mais il y a du boulot. > Fifo, lifo, prix de revient....si on creuse la production c'est comme la compta beau a l'extérieur, immonde quand on creuse > > - module multi warehouse > > Ça fonctionne bien. > En mono société je suis d'accord, en multi société ça transforme Openerp en un château de carte Pour terminer je pense que l'idée de regis est bonne car avec un peu plus de technique (et de module) Dolibarr pourrai s'attaquer aux marchés des PME de 10 a 100 personnes. > > Hors ces modules existent sous Openerp mais sont loin, très loin d'être > fonctionnels > > > > Le 2 octobre 2011 10:07, Cyrille de Lambert < > [email protected]> a écrit : > >> Nous avons plusieurs implémentations OpenERP et il est vrai que cette >> application rame très rapidement. >> Ce n'est pas un problème de base (relationnelle PostgresSQL) mais plutôt >> de framework qui est très consommateur en ressource. >> C'est une application qui ne donne pas satisfaction sur l'aspect perfs. >> Ça commence à peiner avec 3 utilisateurs, même en faisant des efforts >> d'indexation importants. >> >> >> Le 02/10/2011 09:29, olivier geffroy a écrit : >> >> Il est clair que ces technologies consomment beaucoup plus de ressources, >> ce qui n'est pas très grave vu la montée en puissance des serveurs et la >> virtualisation >> >> Le gros problème chez Openerp était la non utilisation de cette puissance >> (pour résumé que ce soit sur un céleron ou sur un octoprocesseur, l'erp >> tourne de la même façon) >> >> En utilisant une base de donnée postgres (optimisé régulièrement pour les >> requêtes) et un système virtualisé sous proxmox (avec un serveur de donnée, >> un serveur apache ....) cela devrai améliorer les performances. >> >> Le 2 octobre 2011 09:13, Régis Houssin <[email protected]> a >> écrit : >> >>> Nous avons des clients avec une base de 30000 produits et c'est tout >>> aussi catastrophique avec le fonctionnement actuel de Dolibarr >>> >>> >>> ----------------------------------------- >>> Régis Houssin >>> Tél. +33633020797 >>> http://www.dolibarr.fr >>> http://www.dolibox.fr >>> >>> Le 2 oct. 2011 à 09:01, olivier geffroy <[email protected]> a écrit : >>> >>> Bonjour, >>> >>> Je suis d'accord avec cyrille, je sors d'une implantation d'openerp qui >>> fonctionne sur ce modèle et les performances sur de gros volumes (40 000 >>> clients) sont catastrophiques >>> >>> Par contre pour les utilisateurs et les codeurs c'est beaucoup plus >>> souples, mais personnellement ce que j'apprécie dans mon dolibarr et ce >>> depuis 6 ans c est la rapidité et la simplicité du produit. >>> >>> >>> >>> Le 2 octobre 2011 07:52, Régis Houssin <[email protected]>a >>> écrit : >>> >>>> Quoi qu'il en soit ça reste un test :-) >>>> >>>> >>>> ----------------------------------------- >>>> Régis Houssin >>>> Tél. +33633020797 >>>> http://www.dolibarr.fr >>>> http://www.dolibox.fr >>>> >>>> Le 2 oct. 2011 à 01:04, Cyrille de Lambert < >>>> [email protected]> a écrit : >>>> >>>> Ce type de sujet revient régulièrement dans différents projets >>>> techniques. >>>> Il y a 7 ans, on nous prédisait la mort du SQL au profit des bases XML >>>> qui reprennent les avantages que tu décris hormis le fait de ne pas avoir >>>> besoin de décrire ses documents. >>>> Ce que j'en ai vu : >>>> >>>> - Performances catastrophiques pour des gros volumes de donnée >>>> - Pas très adapté à des applications métier. >>>> >>>> Pour faire les tests, il faut le faire sur des dizaines de milliers >>>> d'enregistrements en base sur une machine standard. >>>> En effet, ce type de techno est très consommateur. >>>> Je ne pense pas que ce soit mature pour l'instant. >>>> >>>> Cyrille >>>> >>>> Le 01/10/2011 21:48, Régis Houssin a écrit : >>>> >>>> au contraire, pas de jointure, un "document" contient toutes les >>>> informations >>>> un champ n'est créé que si il est renseigné >>>> de plus un module externe n'a pas besoin de créer ces propres tables >>>> pour rajouter des champs dans une fiche produit, il suffit qu'il rajoute >>>> ces enregistrement dans la fiche produit et le champ est créé >>>> automatiquement dans le "document" >>>> (un document est un enregistrement dans mongoDB, un document = une fiche >>>> produit par exemple) >>>> plus besoin d'avoir tout un tas de table avec jointure ! >>>> en natif tu peux modifier un champ seul, plus besoin de créer tout un >>>> tas de fonction et de requête php pour modifier un champ >>>> la sortie est au format json ou array, plus besoin de traitement, tu >>>> peux utiliser les données directement avec du jquery par exemple, >>>> (datatables !!) >>>> >>>> de toute façon je vais faire des tests et je mettrais une démo en ligne >>>> >>>> >>>> Le 01/10/11 20:08, Cyrille de Lambert a écrit : >>>> >>>> Salut Régis, >>>> >>>> Je trouve que c'est un mauvaise idée pour une question de performance. >>>> Je ne pense pas qu'un projet comme NoSQL soit conçu pour des systèmes >>>> de gestion mais plutôt pour des outils de GED. >>>> >>>> Cyrille >>>> >>>> >>>> >>>> Le 01/10/2011 18:49, Régis Houssin a écrit : >>>> >>>> Bonjour, >>>> >>>> afin de mieux gérer les modules externes, la personnalisation des fiches >>>> ou des listes je suis en train de réfléchir à une méthode différente de >>>> stockage des données et je me penche actuellement sur le NoSQL >>>> http://fr.wikipedia.org/wiki/NoSQL >>>> >>>> et plus particulièrement à MongoDB >>>> http://fr.wikipedia.org/wiki/MongoDBhttp://lacantine.ubicast.eu/channels/mongofr/ >>>> >>>> Nous allons faire des tests sur un fork de Dolibarr tout en gardant une >>>> synchronisation entre les projets >>>> >>>> Si des développeurs ayant des connaissances en MongoDB ou très motivés >>>> par cette technologie sont intéressés pour participer à ce projet, merci >>>> de me contacter je vous associerai au projet Doliforge. >>>> >>>> Ce projet reste encore un test et n'a pas encore la vocation de >>>> remplacer la version actuelle ! >>>> >>>> Cordialement, >>>> >>>> Cordialement, >>>> >>>> _______________________________________________ >>>> >>>> Dolibarr-dev mailing list >>>> [email protected] >>>> https://lists.nongnu.org/mailman/listinfo/dolibarr-dev >>>> >>>> >>>> _______________________________________________ >>>> Dolibarr-dev mailing list >>>> [email protected] >>>> https://lists.nongnu.org/mailman/listinfo/dolibarr-dev >>>> >>>> >>> >>> >>> -- >>> Olivier GEFFROY >>> JEFFINFO Sarl >>> >>> Tel : 06 08 63 27 40 >>> Mail : [email protected] >>> >>> _______________________________________________ >>> Dolibarr-dev mailing list >>> [email protected] >>> https://lists.nongnu.org/mailman/listinfo/dolibarr-dev >>> >>> >>> _______________________________________________ >>> Dolibarr-dev mailing list >>> [email protected] >>> https://lists.nongnu.org/mailman/listinfo/dolibarr-dev >>> >>> >> >> >> -- >> Olivier GEFFROY >> JEFFINFO Sarl >> >> Tel : 06 08 63 27 40 >> Mail : [email protected] >> >> >> _______________________________________________ >> Dolibarr-dev mailing >> [email protected]https://lists.nongnu.org/mailman/listinfo/dolibarr-dev >> >> >> _______________________________________________ >> Dolibarr-dev mailing list >> [email protected] >> https://lists.nongnu.org/mailman/listinfo/dolibarr-dev >> >> > > > -- > Olivier GEFFROY > JEFFINFO Sarl > > Tel : 06 08 63 27 40 > Mail : [email protected] > > > _______________________________________________ > Dolibarr-dev mailing > [email protected]https://lists.nongnu.org/mailman/listinfo/dolibarr-dev > > > _______________________________________________ > Dolibarr-dev mailing list > [email protected] > https://lists.nongnu.org/mailman/listinfo/dolibarr-dev > > -- Olivier GEFFROY JEFFINFO Sarl Tel : 06 08 63 27 40 Mail : [email protected]
_______________________________________________ Dolibarr-dev mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
