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 ...
Ç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
* 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.
* 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.
* module multi warehouse
Ça fonctionne bien.
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] <mailto:[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]
<mailto:[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 <tel:%2B33633020797>
http://www.dolibarr.fr
http://www.dolibox.fr
Le 2 oct. 2011 à 09:01, olivier geffroy <[email protected]
<mailto:[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]
<mailto:[email protected]>> a écrit :
Quoi qu'il en soit ça reste un test :-)
-----------------------------------------
Régis Houssin
Tél. +33633020797 <tel:%2B33633020797>
http://www.dolibarr.fr
http://www.dolibox.fr
Le 2 oct. 2011 à 01:04, Cyrille de Lambert
<[email protected]
<mailto:[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/MongoDB
http://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] <mailto:[email protected]>
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
_______________________________________________
Dolibarr-dev mailing list
[email protected] <mailto:[email protected]>
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
--
Olivier GEFFROY
JEFFINFO Sarl
Tel : 06 08 63 27 40
Mail : [email protected] <mailto:[email protected]>
_______________________________________________
Dolibarr-dev mailing list
[email protected] <mailto:[email protected]>
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
_______________________________________________
Dolibarr-dev mailing list
[email protected] <mailto:[email protected]>
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
--
Olivier GEFFROY
JEFFINFO Sarl
Tel : 06 08 63 27 40
Mail : [email protected] <mailto:[email protected]>
_______________________________________________
Dolibarr-dev mailing list
[email protected] <mailto:[email protected]>
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
_______________________________________________
Dolibarr-dev mailing list
[email protected] <mailto:[email protected]>
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
--
Olivier GEFFROY
JEFFINFO Sarl
Tel : 06 08 63 27 40
Mail : [email protected] <mailto:[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
