Rappelons que Dolibarr est un logiciel modulaire (on n'active que les fonctions que l'on désire) de gestions d'entreprises, d'indépendants ou d'associations. En terme plus techniques, c'est un ERP et CRM. C'est un projet OpenSource basé sur un serveur WAMP ou LAMP (Apache, MySQL, PHP).
Dolibarr vient compléter les offres déjà nombreuses de logiciels de cette catégorie comme OpenBravo, OpenERP (exemple TinyERP), Neogia, Compiere, etc. mais se démarque par le fait qu'ici tout est fait pour offrir de la simplicité :
- Simple pour l'installation (avec un installeur DoliWamp pour Windows pour ceux qui ignorent comment un serveur WAMP) ;
- Simple pour l'utilisation (fonctions modulaires pour ne pas surcharger les menus, informations claires à la saisie) ;
- Simple pour le développement (pas de frameworks lourds). Dolibarr intègre en effet sa propre architecture (design patterns) permettant à tout développeur d'être tout de suite opérationnel sans connaissances particulières autre que le PHP).
Dans cette version, on y trouve les modules suivants (tous optionnels) :
- Gestion de catalogue de produits et services
- Gestion de stock
- Gestion des comptes bancaires
- Annuaires des prospects et/ou client et/ou fournisseurs
- Annuaires des contacts
- Gestion des actions/taches avec un agenda intégré (ou lien avec webcalendar)
- Gestion des commandes
- Gestion des propositions commerciales
- Gestion de contrats de services
- Gestion des factures clients et fournisseurs
- Gestion des paiements
- Gestion des virements bancaires
- Gestion des expéditions
- Export PDF de tous les éléments (factures, propositions commerciales, commandes, bons expéditions, etc...)
- Gestion de la TVA NPR (non perçue récupérable - pour les utilisateurs français des DOM-TOM)
- Gestion des adhérents d'association
- Gestion des dons
- Gestion de marque-pages
- Fonctions d'EMailing de masses vers les clients, prospect ou utilisateurs Dolibarr
- Rapports
- Fonctions d'exports
- Connectivité LDAP
Les autres grandes caractéristiques sont les suivantes :
- Application multi-utilisateurs avec différents niveaux de permissions par module.
- Plusieurs gestionnaires de menus (possibilité de différencier les menus pour les utilisateurs internes ou externes comme les clients ou fournisseurs)
- Application simple à utiliser.
- Plusieurs thèmes visuels.
- Code simple et facilement personnalisable.
- Fonctionne avec MySQL 3.1 ou plus (les autres bases de données ne sont pas encore supportées).
- Fonctionne avec PHP 4.3 ou plus.
Les nouveautés par rapport à la 2.2 :
Voici une liste générale des changements plus détaillés, apportés dans la version 2.4 par rapport à la version précédente 2.2 :
Pour les utilisateurs :
- Ajout du module calendrier (module agenda) avec export ical/vcal/rss.
- Amélioration du look et graphiques (merci artichow).
- Ajout des numéros téléphone et de fax sur les adresses de livraisons.
- Ajout d'un outil de personnalisation de menu.
- Réduction de la mémoire utilisée.
- Les triggers sont maintenant automatiquement activés/désactivés en fonction du module auquel ils s'appliquent.
- Fix boucle infinie sur calendrier en popup.
- Changement dans les traductions pour rendre l'utilisation plus claire.
- Ajout d'une alerte en cas d'envoi d'email avec un utilisateurs sans email source.
- Ajout module clicktodial.
- Ajout propriété privée/publique sur les contacts. Ceci permet d'intégrer dans Dolibarr ces adresses personnelles.
- Le code NAF français accepte 5 caractères.
- La définition d'un prix fournisseur peut se faire en HT ou TTC.
- Ajout d'un module de numérotation générique qui offre plus de souplesse sur le choix de numérotation des références des éléments gérés (pour mieux coller aux conventions en vigueur de l'utilisateur ou à son logiciel de compta).
- Ajout de fonctions d'exports prédéfinies supplémentaires avec assistants (stocks, fournisseurs, taxes...).
- Ajout d'une fonction de log d'événements de sécurités (logon, modification de mots de passes).
- On peut lier tout document (y compris factures fournisseurs et commandes) à un projet.
- Possibilité de joindre plusieurs fichiers à un mail lors d'envoi de factures, commandes ou propositions commerciales par mail.
- Possibilité de choisir la précision des ces prix (nombre de décimal). Certains pays ne gèrent pas de décimal sur les montants.
- Gestion des la localisation pour les séparateurs décimal et milliers.
- Plus d'informations dans les pages d'information système.
- Ajout d'un onglet prévision trésorerie sur un compte.
- Divers changements mineurs (fonctionnalités, esthétiques).
- Ajout compatibilité avec Firefox 3.
- Gestion compatibilité PHP6/MySQL6.
- Corrections de bugs.
Pour les traductions :
- Ajout de l'espagnol.
- Ajout de l'anglais australien.
Pour les développeurs :
- Nettoyage de code mort :
Remplacement de phplot et phplot5 par artichow.
Remplacement de cryptograph par artichow.
- Fonction login externalisé en modules.
- Mise a jours des squelettes exemples pour ajouter des fonctions ou modules à Dolibarr et rendre ces développements au plus simple.
- Ajout d'un outil pour généré les classes PHP de mappage de table automatiquement.
- Ajout d'une vérification de version de Dolibarr pour conditionner l'activation de modules.
- Modification dans l'installeur Web pour être compatible avec le nouvel installeur Windows DoliWamp (voir note plus bas).
Autres nouveautés :
Cette sortie s'accompagne de nombreuses autres améliorations. En voici les principales :
DoliWamp
Dorénavant, les versions de Dolibarr sont aussi fournis sous un package nommé DoliWamp qui est un installateur clé en main pour Windows et qui installe Apache, Mysql et PHP en plus de Dolibarr via un simple .exe.
Voila qui va contenter les utilisateurs les moins expérimentés.
http://www.nltechno.com/dolibarrwin
Le wiki
Le wiki de documentation francophone a été upgradé et la documentation développeur bien complétée. Ainsi on y trouve maintenant les normes de développement et un tutoriel complet pour ajouter des modules fonctionnels dans Dolibarr (que ce soit l'ajout de nouveaux menus, écrans, modules de numérotations, d'ajout de boites sur la page d'accueil, de module de génération de modèle de document PDF, etc...)
http://wiki.dolibarr.org
Une démo en ligne
La démo en ligne a été mise à jour pour refléter la version 2.4.
http://demo1.dolibarr.org
Acceleo
Les amélioration d'architecture de cette version ont permis aussi de voir arriver un outil pour générer des nouveaux modules dans Dolibarr par modélisation UML. Voir le site Acceleo et le greffon Dolibarr pour plus d'informations.
http://www.acceleo.org/pages/ferme-de-modules/fr
Les problèmes connus :
Les utilisateurs de Belgique doivent configurer la langue dans Dolibarr à fr_FR et non fr_BE car fr_BE pose un problème d'interprétation des montants qui se retrouvent anormalement multipliés ou divisés par 100 ou 1000.
Rappelons de plus que Dolibarr n'intègre pas encore les fonctionnalités suivantes :
- Pas de comptabilité analytique (uniquement gestion de trésorerie).
- Dolibarr ne gère qu'une seule monnaie à la fois (mono-devise).
- Ne gère pas la double tva (Fédérale / provinciale) du Canada.
- Dolibarr ne contient pas de module de paie.
- Dolibarr ne fait pas le café (c'est le wiki qui le dit !).
Aller plus loin
- Site web Dolibarr francophone (245 clics)
- Site web Dolibarr anglophone (15 clics)
- Module UML2Dolibarr pour Acceleo (47 clics)
- Le wiki Dolibarr (49 clics)
- DoliWamp (10 clics)
- Wikipédia Dolibarr (10 clics)
# offres déjà nombreuses...
Posté par Francois Revol (site web personnel) . Évalué à 2.
http://openaguila.org/
[^] # Re: offres déjà nombreuses...
Posté par jeffcom . Évalué à 2.
# quid des références?
Posté par rvalyi . Évalué à 6.
Perso, c'est OpenERP qui m'a le plus impressionné des tous ceux que j'ai pu tester pendant les 9 mois d'étude pour le livre blanc Smile, j'ai jamais rien trouvé à redire sur sa conception bluffante et à mon humble avis y'a des éditeurs qui vont plus trop rigoler dans quelques années.
En ce qui concerne Dolibarr, l'usage de PHP4 (pas très objet; me paraissait hasardeux tant un ERP est complexe: comment masquer et maîtriser la complexité à long terme sans abstraction objet?) et la caractère peu international du projet m'ont fait douté lorsque je l'ai passé en revue il y a presque un an. En effet, les projets open source qui percent sont rarement des projets non anglophones sans concession, fût-ils développés par des français car ils possèdent alors un base d'utilisateurs/contributeurs d'autant pus large.
L'impression que me laisse encore Dolibarr, c'est que la modularité applicative y est presque nulle: c'est à prendre ou à laisser; si ça ne vous convient pas, il faut hacker le code là oui l'est ou le détourner très en amont sans réutiliser rien du tout. Bref bonjour l'évolutivité et pas de phénomène de catalyse ou chacun peut réinjecter aisément le travail d'autres tierces parties (je ne parle pas de la simple addition de fonctionnalité assurés par le système actuel de modules, mais bien de l'altération des fonctions existantes). Quand je vois par exemple la maturité d'un openERP qui adapte tout seul la structure de la base quand on injecte des plugins qui viennent tuner exactement là ou on le voulait avec la précision d'un bon code objet, ou que je vois l'effervescence des modules tierces contribués qui exploitent ce système pleinement, je me dis que c'est juste autre chose.
Le problème du manque de modularité d'un ERP libre, à mon sens, c'est que si l'ERP ne permet pas de faire des choses très spécifiques avec des coûts de dev maitrisés, alors hélas les produits propriétaires de grande consommation tendent à être souvent plus compétitifs. Bref je n'imagine pas d'autre issue que la faculté de personnalisation à outrance compétitive, à moins qu'un jour ces logiciels atteignent la maturité d'un Firefox ou d'un OpenOffice mais j'en doute, ne serait-ce que par la complexité des métiers et des lois associées qui divisent les communautés déjà maigres en autant d'entités qu'il y a des pays/législations.
Reste que la barrière d'entrée semble plus basse sur Dolibarr que sur la majorité des autres ERP, le côté francophone, s'il est sans doute un handicap à long terme, hisse sans doute néanmoins Dolibarr au dessus de certains concurrent pour un usage hexagonal. Bref, pourquoi pas si Dolibarr semble répondre d'office à 90% des besoin, sinon mieux vaut accepter une barrière d'entrée plus haute mais des abstractions ensuite plus pérennes.
Au fait, je vois que Dolibarr est intégré avec OSCommerce apparemment. Puisque Magento est souvent désigné comme le successeur d'OSCommerce, Je signale donc au passage qu'à Smile on a bossé sur un connecteur (open source) OpenERP / Magento.
mes 0,02$
Raphaël Valyi.
[^] # Re: quid des références?
Posté par Laurent Destailleur (site web personnel) . Évalué à 5.
A ce jour, Dolibarr est complètement en anglais tout comme le site web (dolibarr.org) et l'anglais est devenu avec la 2.4 la langue officielle du projet (le français sera maintenau, il y a donc 2 langues officielles), bien qu'il reste encore beaucoup de commentaires de code en français (mais la la bascule se fera au fur et à mesure des modifications). L'expérience que j'ai d'AWStats, autre projet dont je m'occupe, prouve que tu as entièrement raison sur le fait qu'un projet OpenSource a besoin d'être internationnalisé sans concession pour s'imposer (95% des contributions extérieurs sur AWStats viennent de l'étranger alors que le projet était français au départ). C'est pour cela que Dolibarr est un maintenant un projet anglophone à ce jour. Seul le wiki doit encore être traduit en anglais pour que la bascule soit complète (le forum reste bilangue).
Pour ce qui est du PHP4, Dolibarr est bien un développement en PHP Objet, mais de l'objet compatible PHP4. C'est à dire que les méthodes static et privés/publiques sont présentes mais sans le mot clé "static" ou "private" qui ne sont pas utilisés afin d'avoir une compatibilité sur tous les PHP qui représente encore une base très importante chez de nombreux hébergeurs.
Quand à la modularité d'architecture, c'est aujourd'hui cité comme un point fort des utilisateurs Dolibarr. Une installation vierge de Dolibarr se fait nue, c'est à dire qu'après une installation avec la 2.4, on ne trouvera dans le menu que les éléments de configuration des comptes utilisateurs et la page pour activer les modules fonctionnels. Et tous les modules sont optionnels y compris la gestion des tiers qui dans de nombreux ERP fait parti du noyau même de l'application. Une association pourra par exemple n'activer que le module de gestion des adhérents et ne rien avoir en rapport avec les clients ou fournisseurs si elle veut se limiter à ses cotisations d'adhésion ni ne faire de gestion de comptes.
Il est vrai qu'il s'agit plus d'une modularité fonctionnelle, parfois plus technique comme par exemple le nouveau module agenda/calendrier qui a été fait sur ce principe et a pu être développé dans un coin sans concertation des équipes Dolibarr, puis intégrer en quelques minutes dans le CVS sans risques, alors qu'il s'interface pourtant avec tous les autres modules.
En effet, le système des triggers applicatifs (toute action métier déclenche un trigger) que n'importe qui peut intercepter en plaçant un fichier trigger dans un répertoire facilite également grandement cette modularité et l'interfaçage avec tout type de logiciel extérieur. Mais il peut aussi être utilisé pour changer le comportement interne de l'application. Il est ainsi possible de changer le workflow sans toucher au code (comme par exemple faire en sorte qu'une commande soit crée dès qu'une facture est crée ou l'inverse). On utilise les classes métiers existantes pour faire l'insertion et on utilise le mécanisme des triggers pour que cette méthode soit déclenchée, mais on ne touche pas au code existant. Ceci permet de modifier le comportement interne et tout module extérieur peut amener ses triggers pour changer ce comportement.
Il est vrai, je pense, que c'est une approche différente que celle que tu évoques pour OpenERP et que je ne connais pas, Dolibarr ne faisant pas d'altération de base existante mais uniquement des "compléments" (ajout de tables liées à des tables existantes ou simplement nouvelles tables), ajout de code. Mais cela suffit pour permettre de récupérer des modules développés par des éléments extérieurs très rapidement, car cela revient juste à copier des nouveaux fichiers (mais ceci n'était pas encore opérationnel il y a 1 an) et c'est aussi cette nouveauté qui a permis à la société Auguria de fournir un outils de génération de modules complémentaires basés sur UML et acceleo qui peuvent s'ajouter dans Dolibarr sans impact sur le noyau du projet.
Bref, avec la 2.4 un module applicatif extérieur amène ses écrans, ses habilitations, ses entrées dans les menus, ses triggers (pour permettre à d'autres sous module de s'interfacer aussi sans impact sur le module), ses boites pour la page accueil, ses filtres d'exports, ses règles de sélection d'email pour le module d'emailing de masse, etc... Ceci je pense répond au défaut que tu as évoqué que pour qu'un projet récupère l'adhésion de contributeurs, il doit y avoir isolation du code afin de faciliter les intégrations. C'est d'ailleurs l'effort principal qui a été fait dans la 2.4.
Il y a donc eu de très gros progrès en 1 an depuis l'évaluation de Smile, que j'ai d'ailleurs lu avec grand intérêt et que je trouve très bien faite. Je pense qu'à cet époque le choix d'écarter Dolibarr était justifié (pour toutes les raisons que tu as évoqués d'ailleurs). Gageons que pour une prochaine étude, Dolibarr rentre à nouveau dans la course.
Sinon, Dolibarr ne cherchera pas à remplir 100% des besoins comme le font certains ERP, la politique à ce jour et de plutot viser les 95%, car ce sont les 5% manquant qui amènent une forte complexité dans ce genre d'outils pour les intégrateurs et utilisateurs. Hors l'objectif de Dolibarr et de se positionner sur la simplicité, ce qui fait que Dolibarr vise les PME et indépendants mais pas les grosses entreprises qui elles peuvent être couvertes par des ERP plus anciens et ont des besoins plus important.
C'est donc une orientation différente mais volontaire.
PS: Merci pour ton livre blanc, il est très instructif. Si une mise à jour doit être faite dans les années qui viennent, pense à venir refaire un tour du côté de Dolibarr. La croissance d'adhésion de Dolibarr que l'on connait actuellement laisse présager encore de nombreux progès en 2008.
Expert ERP CRM Open Source et (Dolibarr ERP CRM, Odoo, ...)
[^] # Re: quid des références?
Posté par Jerome Alet (site web personnel) . Évalué à 2.
[^] # Re: quid des références?
Posté par Laurent Destailleur (site web personnel) . Évalué à 1.
Ainsi quand tu génrère tes PDF (facture ou autre), tu as le choix de la langue de génération. Par contre la langue reste présélectionnée sur celle de l'utilisateur car elle n'est pas stocké au niveau du client, il faut donc la choisir dans la liste à chaque génération de PDF.
Expert ERP CRM Open Source et (Dolibarr ERP CRM, Odoo, ...)
[^] # Re: quid des références?
Posté par Jerome Alet (site web personnel) . Évalué à 2.
En tout cas c'est une fonctionnalité dont j'ai besoin et que j'attendais de voir apparaître avant d'essayer ce logiciel que je surveillais du coin de l'oeil (lointain) depuis quelques années... C'est décidé il faut vraiment que je l'essaie, maintenant !
[^] # Re: quid des références?
Posté par Laurent Destailleur (site web personnel) . Évalué à 1.
Expert ERP CRM Open Source et (Dolibarr ERP CRM, Odoo, ...)
[^] # Re: quid des références?
Posté par guppy . Évalué à 3.
http://www.php.net/archive/2008.php#id2008-08-07-1
[^] # Re: quid des références?
Posté par godzom . Évalué à 2.
[^] # Re: quid des références?
Posté par rvalyi . Évalué à 3.
merci, post très éclairant. En effet, j'ai vu qu'il y avait encore beacoup de français uniquement dans votre doc et code, mais savoir que vous avez concience d'allez vers l'international est déjà une très bonne nouvelle.
Je n'étais pas non plus au courant du système de trigger PHP et workflows.
L'approche type Pareto: ne pas essayer de tout faire mais rester simple me paraît très valide.
Si le PHP4 que vous utilisez est objet, c'est plutôt rassurant. Hélas je n'avais pas pu m'en assurer dans le temps imparti.
Au fait, OpenERP ne fait pas de alter table ou de suppression de donnée sauvage à l'installation d'un module: il dit juste attention il faudra faire quelque chose. Ceci afin d'éviter les pertes de données accidentelles. En revanche, la gestion des dependances entre modules et les mécanismes d'héritage des objets métiers et de vues est extrèmement puissant. Je n'ai vue aucun autre ERP mature qui faisait ça (peut être ERP5 mais nous avions du mal à croire à la base Zope en général pour les PME en dehors d'une optique SaaS).
Bref, oui, nous allons surveiller ça. D'autant qu'il semble que Dolibar dispose d'une commaunauté contente, ce qui est un énorme plus et c'est très différents de certaines solutions J2EE dont les rares clients (pas les notres) n'ont de cesse de se plaindre.
Je crois aussi que Dolibarr répond bien aux attentes des TPE ou il y aurait un connaiseur de PHP, alors que d'autres ERP comme OpenERP, Openbravo ou Compiere visent des boîtes plus grosses et nécessitent en contreparitie un investissement supérieur (l'investissement sera surtout supérieur pour Compiere ou Openbravo ici).
Nous allons faire une mise à jour de notre livre blanc d'ici quelques jours. Hélas pas le temps de remettre Dolibarr sur le tapis pour l'instant. On le mentionnera un peu plus dans un paragraphe c'est promis. On va surtout mettre à jour les progrès indéniables de Compiere 3.1 (bien qu'on le répète pas très ouvert), les progrès (énormes) d'OpenERP 4.4 et son changenment de de nom consommé, le mode appliance d'Openbravo ou encore la difficile traversée du désert de Neogia qui ne donne pas trop signe de vie cette année.
Cordialement,
Raphaël Valyi.
[^] # Re: quid des références?
Posté par Laurent Destailleur (site web personnel) . Évalué à 1.
A ce jour, l'objet est surtout utilisé comme classe de mapping des tables en ActiveRecord. L'héritage est donc souvent utilisé uniquement pour les parties communes techniques de composants (classes de gestion de base ou classes des modules ou sous-modules qui partagent des méthodes techniques propre au fonctionnement générique). Le wiki http://wiki.dolibarr.org/index.php/Langages#Motifs_d.27organ(...) explique un peu les choix fait sur les motifs d'organisation du code et de liaison aux bases.
C'est donc un support minimal mais suffisant pour qui veut manipuler les entités métiers Dolibarr sans connaitre le modèle physique tout en s'assurant la pérénité de ces dev. On ira jamais aussi loin qu'OpenERP sur ce point je le pense (même quand on rétablirait l'utilisation des mots clés purement objet) mais comme tu le fait remarquer nous cherchons à contenter les TPE qui ont juste un connaisseur PHP, voir aucun informaticien et pour cela l'utilisation objet au sens métier suffit souvent sans forcément aller à l'utilisation au sens technique (mais nous irons surement car cela ouvre des portes à quantité d'outillage intéressant, comme des outils d'audit de code ou autre plus efficaces dans ce cas).
Si le guide Smile des ERP peut vivre, ce serait génial car tout va si vite dans le monde Open et cela faisait un moment que je cherchait une étude aussi complète qui me permette de jauger comment situer Dolibarr vis à vis des autres ERP, aussi si elle pouvait rester "up to date", j'en serais à suivre.
Je comprends parfaitement que tu ne puisses remettre sur le tapis Dolibarr maintenant, cela nécessite j'imagine un investissement démultiplié tout autant qu'il y a de produits à analyser. Ton travail va toutefois être plus facilité maintenant que nous avons mis en place une documentation plus digne de nos ambitions sur le wiki. De plus nous n'avions presque jamais communiqué sur le projet jusqu'ici attendant une version qui soit "digne" plutôt que de se faire de la mauvaise publicité d'entrée. Et cette version est peut etre atteinte avec la 2.4 que j'ai longtemps hésité à appeler 3.0 compte tenu du nbre de modification. Mais je réserve ce chiffrage à l'arrivée dela compta analytique. La documentation utilisateur reste toutefois encore pauvre, l'accent ayant été mis sur la documentation développeur avec la 2.4. Mais nous avons conscience de nos faiblesses et les critiques constructives sont toujours la bienvenue. Elles ont permis de confirmer notre perception de nos défaut et par conséquent nous conforte dans les choix fait récemment.
Sinon pour répondre à une de test questions sur les références d'utilisateur, nous avons il y a quelques temps mis en place une page de liens où les utilisateurs peuvent se déclarer sur le site:
http://www.dolibarr.org/index.php?option=com_weblinks&ca(...)
Expert ERP CRM Open Source et (Dolibarr ERP CRM, Odoo, ...)
[^] # Re: quid des références?
Posté par Cyrille de Lambert (site web personnel) . Évalué à 3.
En ce qui concerne la société Auguria, nous réservons effectivement Dolibarr au TPE/PME qui ont une problématique métier simple. C'est l'application la plus efficace et la moins risquée à mettre en place pour de petites budgets.
Autrement, nous voyons coté OpenERP ou OpenBravo.
Je trouve que des applications comme OpenErp ne sont pas faciles à prendre en main et qu'il y un gros effort à faire au niveau ergonomique. De plus, j'ai de gros doutes concernant la montée en charge vue l'architecture.
J'ai pourtant préconisé cette application plusieurs fois dernièrement pour sa richesse fonctionnelle et sa correspondance avec le besoin. De plus, je sais que l'interface web peut permettre des améliorations ergonomiques importantes.
OpenBravo me séduit beaucoup et je pense que je vais privilégier à l'avenir cette application pour certains besoins complexes.
Il faut faire du cas par cas. Dans tous les cas, nos concurrents sont les logiciels propriétaires. D'ailleurs SAP Business One passe en force sur beaucoup de petites PME voir TPE en ce moment et il est grand temps pour les ERP libres de montrer de quoi ils sont capables.
Je serais d'ailleurs intéressé pour mener des actions communes de communication avec d'autres acteurs des logiciels de gestion libres. Nous avons besoin de les légitimer.
Cyrille de Lambert
PS : J'aimerais que nous puissions décliner les principes des générateurs MDA sur d'autres applications que Dolibarr. Ceci peut faire gagner beaucoup de temps et nous permet de nous focaliser sur le fonctionnel.
[^] # Re: quid des références?
Posté par rvalyi . Évalué à 1.
c'est mon point de vue et pas forcément celui de la société qui m'emploie et qui a financé le livre blanc, mais sache que j'aurais vraiment beaucoup de mal à recommander Openbravo sur OpenERP. A la rigueur OpenbravoPOS pour les points de ventes qui est une solution lourde mais techniquement valide.
Sinon ça serait vraiment ma deuxième propositions pour les gens exclusivement paranoïaques au Python (pourtant plus facile à apprendre que Java), mais ecore une fois je pense qu'il n'y a pas photo sur le fonctionnel, la conception et la dynamique réelle. J'avoue qu'il m'a fallu 2 mois pour changer d'avis après avoir par erreur écarté OpenERP pensant qu'il s'agissait d'un client lourd simpliste (j'avais regardé le code et en avais vu tellement peu que j'étais loin d'imaginer que la couverture fonctionnelle était triple). Mais ensuite je n'ai jamais changé d'avis.
Faut voir aussi qu'Openbravo, si avec leurs 18 millions de dollars levés au total il n'arrivent pas à faire, dans quelques mois/années, quelque chose qui chatouille un peu ce qu'a fait un étudiant en école (OpenERP), alors ça seraient vraiment des manches (m'enfin ça se voit aussi les millions engloutis en mauvaises solutions, on dira d'ailleurs bien ça de SAP un jour). Personnellement je sais déjà où j'aurais mis mes billes mais ne faisons pas ici de procès d'intention.
OpenERP4.4 va sortir d'ici environ un mois et je pense que questions améliorations d'ergonomie tu seras servi (petite entrevue ici pour la gestion de projet, sur le client GTK: http://fptiny.blogspot.com/2008/09/reviewed-project-manageme(...) ). OpenERP ne donne certes pas la liberté d'une page HTML faite à la mano, mais on peut quand même pas mal customizer l'engin.
Bonne chance,
Raphaël Valyi.
[^] # Re: quid des références?
Posté par rvalyi . Évalué à 1.
question MDA: y'en a déjà un moyen pour OpenERP:
http://www.openobject.com/index.php?option=com_content&t(...)
cliques sur la deuxième démo 'generate the objects'.
Perso je pense que l'idée du MDA est une faillite intellectuelle, c'était valide à l'époque reine des EJB et autres bloatwares où il s'agissait avant tout de pisser du code tant le langage ou les frameworks étaient abérrants. A partir du moment ou tu as des langages+frameworks type Rails qui te permettent d'exprimer bien plus en quelques mots de prog déclarative sans avoir à aller connecter des flêches en se demandant combien coutera l'outil qui dessine les flêches demain (Neogia s'est bien planté avec PoseidonUML qui est devenu payant, ils n'ont même pas encore fini de payer leur migration sur l'UML fait dans Netbeans, jusqu'au prochain abus du fabricant d'outils...
Je considère qu'OpenERP est à peu près aussi bien conçu que Rails en terme d'API (disons que c'est ce qui s'en rapproche le plus en terme d'ERP) et je ne vois pas tellement comment on peut exprimer de façon plus canonique un besoin fonctionnel que le minimum d'instructions de code mis en jeux, c'est cela qui me donne une très grande confiance.
Après oui, c'est vrai OpenERP pourrait s'essayer à un peut plus de vitesse. Mais ils ont quand même 2 niveaux de cache dans leur ORM, comme sur Hibernate et pas comme sur Compiere ni Openbravo qui ont d'ailleurs sans doute un base plus faible de testeurs capables. Et au pire, sur les points chauds avérés tu peux toujours bourriner du PL/SQL à papa pour accélérer à la même vitesse d'un Openbravo ou un Compiere (mais la différence avec eux c'est que le PL/SQL reste l'ultime option et qu'on est pas obligé d'en arriver là d'office). Concédons que ces derniers peuvent tourner sur Oracle contrairement à OpenERP. Reste que depuis que ma dernière version du livre blanc en Mai, eTiny est devenu 3 fois plus rapide environ et nombre de partenaires ont fait état de déploiements avec des milliers de mouvements de stock ou comptables par mois. J'avoue que je suis en passe de ne plus me faire de souci de ce côté-ci, je corrige d'ailleurs notre livre blanc en ce sens.
Au fait, en creusant encore: oui décidemment Dolibarr semble avoir beaucoup progressé et sera sans doute un bon choix pour les très petites structures qui ne peuvent pas investir sur quelque chose de plus gros. Il s'agît en effet d'une niche qui était mal remplie par les les offres concurrentes.
Cordialement,
Raphaël Valyi.
[^] # Re: quid des références?
Posté par Cyrille de Lambert (site web personnel) . Évalué à 1.
En ce qui me concerne, je pense que le MDA est une bonne manière de générer le squelette des modules de façon homogène.
Le problème OFBiz/Neogia, sur lequel j'ai un peu développé (j'ai fait à une époque le premier site ecommerce français avec cette solution), vient de l'architecture plutôt étrange et d'une base OFBiz *archi buguée* et déprimante. Le MDA ne peut s'exprimer que sur une architecture valide. De plus, cette application est anti ergonomique au possible et très difficilement paramétrable sans programmation (comme pour les enchainements d'étapes ... même OpenERP est largement meilleur sur ce point là). Pas terrible pour un ERP.
Je n'ai pas tourné le dos à OpenERP mais je refuse d'apprendre un autre langage. Alors, je fait appelle à des société partenaires lorsque je dois implémenter une nouvelle fonctionnalité.
Cyrille
# Pour la demo c'est http://demo1.dolibarr.org (et non .rog)
Posté par grafit . Évalué à 2.
# Dolibarr ! Dolibarr barr barr !
Posté par Sten Spårvagnhög (site web personnel) . Évalué à 1.
http://www.youtube.com/watch?v=PgVDie1V3Q4
[^] # Re: Dolibarr ! Dolibarr barr barr !
Posté par Laurent Destailleur (site web personnel) . Évalué à 1.
Expert ERP CRM Open Source et (Dolibarr ERP CRM, Odoo, ...)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.