offres déjà nombreuses...

• [^]Re: offres déjà nombreuses...

  Posté par Jeff_ (Jabber id, ) le 29/08/2008 à 14:52. (lien). Évalué à 2.

  ou openERP et bien d'autres... pourquoi ne citer qu'openaguila ?

  --
  "L'informatique, c'est comme le sexe : c'est mieux quand c'est gratuit" [Linus]

quid des références?

• [^]Re: quid des références?

  Posté par Laurent Destailleur (page perso, ) le 29/08/2008 à 09:02. (lien). Évalué à 5.

  Je reviens sur tes remarques:
  
  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.

  • [^]Re: quid des références?

    Posté par Jerome Alet (page perso, ) le 29/08/2008 à 10:24. (lien). Évalué à 2.

    Question à propos de la gestion du multilinguisme (non je n'ai pas regardé le site web ni lu la doc) : je voudrais savoir si Dolibarr permet de choisir la langue à utiliser en fonction du client, afin que les courriers soient envoyés en Anglais à un client parlant cette langue, en Français à un autre, etc... et ceci indépendamment de la langue choisie dans l'interface utilisateur ?
    
    

    • [^]Re: quid des références?

      Posté par Laurent Destailleur (page perso, ) le 29/08/2008 à 17:50. (lien). Évalué à 1.

      Oui, il faut activer le mode multilangue.
      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.

      • [^]Re: quid des références?

        Posté par Jerome Alet (page perso, ) le 29/08/2008 à 19:06. (lien). Évalué à 2.

        C'est dommage qu'elle ne soit pas stockée au niveau de chaque client, car on peut imaginer que ça ne change pas beaucoup dans le temps pour un client donné.
        
        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 (page perso, ) le 29/08/2008 à 19:11. (lien). Évalué à 1.

          Oui c'est en effet une modification simple à faire et qui est envisagée...

  • [^]Re: quid des références?

    Posté par guppy () le 29/08/2008 à 10:25. (lien). Évalué à 3.

    En ce qui concerne php4, le gros soucis à mon avis c'est qu'il n'est plus supporté :
    http://www.php.net/archive/2008.php#id2008-08-07-1

    • [^]Re: quid des références?

      Posté par godzom () le 29/08/2008 à 10:56. (lien). Évalué à 2.

      Certes, mais il est encore présent chez de nombreux hébergeurs!

  • [^]Re: quid des références?

    Posté par rvalyi () le 29/08/2008 à 11:45. (lien). Évalué à 3.

    Ok,
    
    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 (page perso, ) le 29/08/2008 à 19:08. (lien). Évalué à 1.

      Oui pour l'aspect objet, Dolibarr n'a surement pas la même puissance qu'OpenERP.
      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(...)

    • [^]Re: quid des références?

      Posté par Cyrille de Lambert (Jabber id, page perso, ) le 30/08/2008 à 00:31. (lien). Évalué à 3.

      Bonjour,
      
      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.

      --
      Auguria (www.auguria.net), conseil et intégration en gestion intégrée (ERP) libre

      • [^]Re: quid des références?

        Posté par rvalyi () le 09/09/2008 à 22:35. (lien). Évalué à 1.

        Salut, Cyrille,
        
        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 () le 09/09/2008 à 23:26. (lien). Évalué à 1.

        Encore un complément:
        
        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 (Jabber id, page perso, ) le 10/09/2008 à 22:34. (lien). Évalué à 1.

          Concernant OpenBravo, je crois beaucoup au projet green qui permettra de mettre définitivement fin à l'héritage Compiere qui est lourd. En effet, avoir un système de persistance ou un framework propre est actuellement une aberration. De plus, il y a effectivement trop de dépendance par rapport au bases de données.
          
          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

          --
          Auguria (www.auguria.net), conseil et intégration en gestion intégrée (ERP) libre

Pour la demo c'est http://demo1.dolibarr.org (et non .rog)

Dolibarr ! Dolibarr barr barr !

• [^]Re: Dolibarr ! Dolibarr barr barr !

  Posté par Laurent Destailleur (page perso, ) le 29/08/2008 à 23:25. (lien). Évalué à 1.

  Avec un tel clip, il va falloir renommer légèrement le projet.