Dolibarr 3.0.0

Posté par (page perso) . Modéré par patrick_g. Licence CC by-sa
20
24
avr.
2011
Bureautique

La version 3.0 finale de Dolibarr ERP/CRM est sortie. C’est une évolution majeure. Tous les modules fonctionnels ont été améliorés et d’autres fonctionnalités ajoutées. Si l’application a été internationalisée sur le plan technique depuis la version 2.6, c’est à partir de cette version qu’elle l’est également sur le plan fonctionnel (Canada pas encore supporté).

Les fonctionnalités et règles de développements ont également été enrichies afin d’améliorer la qualité et l’efficacité de la plate‐forme de greffons complémentaires DoliStore. Aussi, la plupart des modules de cette plate‐forme ont été mis à jour en parallèle et sont disponibles en même temps que la sortie de Dolibarr.

Dolibarr est un logiciel modulaire (vous avez les fonctions que vous voulez) dédié à la gestion d’entreprises ou d’associations orienté vers la simplicité (il n’est pas nécessaire d’avoir de connaissances informatiques ni pour l’installer, ni pour le paramétrer, ni pour l’utiliser).

Il cible les TPE / PME, professionnels indépendants, petites entreprises ou associations.

Voici une liste de changements de la 3.0 par rapport à la 2.9.

Pour les utilisateurs :

  • édition de la date des bordereaux de remise de chèque ;
  • ajout d’un journal de vente et achat ;
  • création d’une facture fournisseur depuis une commande fournisseur ;
  • ajout d’une météo sur le tableau de bord ;
  • ajout d’un module PayPal ;
  • amélioration du module GED ;
  • classement des lignes par glisser‐déposer ;
  • importation des adhérents par l’assistant d’importation ;
  • possibilité de générer des cartes de visite pour un adhérent particulier ;
  • attachement des pièces jointes sur une carte d’adhérent ;
  • possibilités supplémentaires de filtrages sur certaines listes ;
  • affichage de l’e-mail automatique qui sera envoyé avant son envoi ;
  • le processus de mise à jour a été amélioré pour PostgreSQL ;
  • les produits ont 2 statuts (en vente et en achat) ;
  • nombreuses autres options pour gérer les spécificités de certains pays ;
  • création d’une facture depuis une adhésion ;
  • réorganisation des menus pour plus de clarté ;
  • éditeur d’image sur les photos ;
  • le paquet pour Ubuntu fonctionne aussi sur Debian ;
  • amélioration des performances.

Pour les développeurs :

  • la bibliothèque jQuery est chargée par défaut dans Dolibarr ;
  • suppression de nombreuses bibliothèques au profit de jQuery (PWC, Scriptaculous, Prototype) ;
  • plus de jeux de tests unitaires ;
  • ajout d’un champ « ref_ext » sur tous les objets pour permettre à une application externe de stocker son id dans des processus externes de synchro ;
  • fonctionne avec MySQL 5.5 ;
  • mutualisation de code.
  • # Balls of steel

    Posté par . Évalué à 3.

    Cet outil complet est une vraie merveille qui conjugue simplicité, facilité et efficacité.

    Je déplore juste la manque de gestion de Taxes multiples comme au Canada.

    Avis aux développeurs !!!

    • [^] # Re: Balls of steel

      Posté par . Évalué à 1.

      Entièrement d'accord, un super outils, que j'utilise presque quotidiennement.
      Simple, interface sobre et efficace, bref pour utiliser le terme marketing à la mode une bonne "expérience" utilisateur.
      Il manque pour le diffuser à mes relations :
      - le paramétrage des emails d'envois , la signature par exemple, du mail de relance qui existait et qui n'existe plus. Il suffit de changer le sujet d'accord, mais c'était sympa de n'avoir qu'à cliquer et hop relance envoyée.
      - et surtout la mise en page des pdf. Même si on ne le fait qu'une fois, la mise en page est particulièrement laborieuse pour l'instant. La mise en page est importante pour les devis et les factures car c'est l'image d'une société/PME qui est représentée.
      - et des exports vers une compta comme ciel.
      - Et pour une PME qui vends à l'export, il y a des points bloquants, mais à chaud , je ne me souviens plus ce qui bloquait.

      Et enfin c'est un logiciel libre sous licence GPL.

  • # Un peu de réflexion sur le thème

    Posté par . Évalué à 3.

    Je suis toujours heureux de voir des solutions libre pour des produits reconnus d'utilité publique comme un ERP. Par contre, en ayant fait un tour rapide des produits que j'ai pu essayer ou dont j'ai pu constater les fonctionnalités, je m'aperçois qu'ils incluent tous des fonctions comme la gestion d'un calendrier, de la gestion documentaire, de la messagerie, etc, plutôt que de s'y interfacer.

    Supposons que j'aie installé PHPiCalendar (ou WebCalendar), que j'utilise Thunderbird pour la gestion de mes calendriers, que j'aie installé KnowledgeTree pour ma GED et que j'aie déjà un système Postfix/DSPAM/Amavis/Cyrus IMAP. Je dois souvent faire un choix quant à celui dont je devrais me passer ou convertir, est-ce exact?

    Donc ma question est: pourquoi ne pas avoir choisi d'interfacer ce type de produits avec d'autres, s'accomplissant de leur tâche parfaitement, plutôt que de les englober?

    • [^] # Re: Un peu de réflexion sur le thème

      Posté par (page perso) . Évalué à 4.

      Peur-être parce que, pour quelqu'un qui n'a pas déjà installé tous ces services, il est beaucoup plus simple d'installer et configurer uniquement un système complet homogène plutôt que d'installer puis essayer de faire communiquer différentes briques hétérogènes.

    • [^] # Re: Un peu de réflexion sur le thème

      Posté par (page perso) . Évalué à 3.

      J'ai exactement le même réflexe que toi: pourquoi diable refaire ce qui existe déjà ? Et pourquoi obliger l'utilisateur à prendre ce système de messagerie alors qu'il en a déjà un qui lui convient. Et surtout, si j'ai un logiciel de compta, un ERP, un machin et un truc, je me retrouve avec 4 messageries et 4 calendriers qui ne partagent pas les mêmes informations.

      A mon avis la raison est qu'il n'y a pas de standard pour interfacer tout cela.
      Ceux qui développent un ERP le font pour leur besoin. Alors zou, ils ajoutent la messagerie maison qu'ils développent, hop ils collent leur calendrier idéal, etc.

      • [^] # Re: Un peu de réflexion sur le thème

        Posté par (page perso) . Évalué à 2.

        A mon avis la raison est qu'il n'y a pas de standard pour interfacer tout cela.

        Ben, il y a quand même iCalendar pour les calendriers et IMAP pour le mail. Et il existe de bon serveur libre pour IMAP (pour iCalendar, je ne sais pas).

        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

        • [^] # Re: Un peu de réflexion sur le thème

          Posté par (page perso) . Évalué à 3.

          iCalendar et IMAP sont un bon départ, mais n'ont rien à voir en terme de fonctionnalités par rapport à ce qu'on trouver au sein des logiciels de travail en groupe.

          La question suivante est peut-être: un standard "puissant" va-t'il émerger dans un avenir proche ?

          • [^] # Re: Un peu de réflexion sur le thème

            Posté par . Évalué à 2.

            iCalendar et IMAP sont un bon départ, mais n'ont rien à voir en terme de fonctionnalités par rapport à ce qu'on trouver au sein des logiciels de travail en groupe.

            Peux tu détailler stp? Qu'est ce qu'il y a de si différent? Peut être voudrais tu un logiciel de travail en groupe capable d’agréger les informations a partir de plusieurs iCalendar?

    • [^] # Re: Un peu de réflexion sur le thème

      Posté par . Évalué à 2.

      Je pense qu'une des raisons est qu'un ERP est un produit de type 'complet'
      Et puis faut bien enfermer un peu le client si on veut pouvoir le facturer. Parce que si c'etait aussi modulaire que ca on pourrait changer l'ERP tres facilement par un autre...

      • [^] # Re: Un peu de réflexion sur le thème

        Posté par (page perso) . Évalué à 1.

        Cela pourrait être une des raisons pour certains ERP en effet.
        Ce n'est pas la philosophie dans Dolibarr dans la mesure ou toute donnée est exportable en format csv pour migrer vers un autre ERP. Reste toutefois encore à l'ERP cible d'etre capable de tout importer, ce qui est une autre affaire.
        Chaque module est de plus bien à 100% optionnel (tables indépendantes, écran indépendant, etc) pour minimiser au maximum cet inconvénient inhérent aux ERP. Mais l'exercice est pa toujour facile, en tout cas, l'équipe a bien conscience de ce problème et les évolutions essaient justement d'aller à l'encontre de ce défaut.

        Responsable Agence Bordeaux de la société Open Source TecLib (http://www.teclib.com)

    • [^] # Re: Un peu de réflexion sur le thème

      Posté par (page perso) . Évalué à 3.

      Pour répondre à la question, il faut savoir que ta remarque a bien été prise en compte. Ainsi, le module calendrier interne est totalement optionnel.
      Le choix fait est, compte tenu du nombre important de systeme est interface a gerer, que l'application devait permettre des interfacages tiers par modules complémentaires. Ensuite, a charge des applications tiers ou autres développeurs de développer ses interfaces.
      Hors s'interfacer avec d'autres appli n'est pas si simple que cela. Car ces autres appli ne fournissent pas les api ou web services pour. Par exemple, dans les anciennes versions de dolibarr, il y avait un module pour webcalendar rendant completement inutile le module agenda interne. Mais hélas, il fallait attaquer la base directement par manque d'interface fournie par webcalendar. Cela faisait modifier le module a chaque nouvelle version de webcal. Ce module a donc du être abandonné.
      Dans l'autre sens, il y a aussi les fonctions d'export au format ical ou rss qui sont disponibles, te permettant de voir les évènements Dolibarr dans ton thunderbird ou autre.

      Le choix a donc bien été fait de s'interfacer avec d'autres outil en mettant en place une archi permettant cela (systeme des triggers). Mais cette derniere n'est utilisable que si les appli tierces fournissent des interfaces d'accès branchables sur ces triggers, ce qui est encore trop rarement le cas.
      Certains systemes le sont par contre car fournissant des API stables et figés (exemple, le LDAP qui est parfaitement interfaçable, les flux RSS, ou cerains systeme comme Paypal, Paybox, Google, OVH, ...). Dans ces cas la on trouve le module qui permet de faire le lien.

      Responsable Agence Bordeaux de la société Open Source TecLib (http://www.teclib.com)

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.