OpenConcerto 1.0 , un nouvel ERP libre

Posté par . Modéré par Christophe Guilloux.
Tags :
20
18
fév.
2011
Bureautique
La première version de logiciel OpenConcerto vient de sortir. OpenConcerto est un logiciel complet de gestion d'entreprise incluant : gestion commerciale, comptabilité, paye et point de vente (caisse).

Il est disponible pour Linux, MacOS et Windows.

Le logiciel est sous licence GPL et téléchargeable dès maintenant en version 1.0 sur toutes les plateformes.

À la différence des solutions habituelles que l'on peut trouver dans les logiciels libres, OpenConcerto n'est pas une application web mais une application riche.

Cette application écrite en Java repose sur des bases de données libres dont MySQL, PostgreSQL et H2. OpenConcerto est un progiciel de gestion intégré (ERP) qui se verra enrichi rapidement par de nouveaux modules.
Au niveau des fonctionnalités, vous trouverez les grands classiques des produits « en boîte », mais également les éléments d'un ERP complet comme la gestion multi-société, multi-poste, multi-utilisateur ou encore la traçabilité.

Devis, factures, avoirs, commandes, règlements et bons de livraison, tout y est. Le logiciel permet de gérer facilement clients, fournisseurs, achats, ventes, articles et stocks. La gestion commerciale est directement liée à la comptabilité (norme française) ce qui évite les doubles saisies.

L'accent est porté pour l'instant sur le retour utilisateur afin de pouvoir fournir une base la plus complète possible. Le logiciel s'adresse à un public large :
  • l'autoentrepreneur, qui y trouvera de quoi réaliser devis, factures, paye et comptabilité ;
  • la petite entreprise, qui y verra une solution multiposte complète ;
  • la moyenne entreprise, qui économisant un coût de licence pourra investir dans la création de modules spécifiques à son activité.
Développé depuis plusieurs année par ILM Informatique, le logiciel est en production depuis quatre ans sous forme de développements spécifiques. Ayant acquis un bon niveau de stabilité et d'utilisabilité, OpenConcerto a été réduit à un noyau généraliste.

OpenConcerto est le troisième projet open source d'ILM Informatique, après jOpenDocument (récompensé par Sun Microsystems Award en 2008) et jOpenRay.
  • # Ou es le module de caisse ?

    Posté par . Évalué à  2 .

    Je cherche a lancer le module de caisse mais ne trouve pas ou il est dans les menus.
    De plus est il envisage un import a partir d'OpenBravo ?

    Sur la page support il y a:
    Nous vous conseillons vivement de consulter
    le guide de guide démarrage <- lien mort en plus de la typo
    pour découvrir le fonctionnement du logiciel.

    Le guide ne parle pas de grand chose par allieurs, et le module caisse n'est pas aborde.

    Je cherche avant tout un module caisse plus efficace que OpenBravo POS, La partie comptable francaise a l'air tres claire par contre.
    • [^] # Re: Ou es le module de caisse ?

      Posté par . Évalué à  3 .

      La page support est corrigée. Merci de l'avoir signalé, il y a tellement de choses à vérifier lors d'une mise en ligne... et les yeux finissent par ne plus rien voir!

      Pour la caisse, bien vu, c'est un exécutable à part que nous n'avons pas inclus pour la version 1.0. Non pas qu'elle soit non fonctionnelle, mais nécessite d'écrire une documentation. Encore un peu de patience ;)

      S'interfacer aux douchettes et imprimantes tickets n'est pas forcément aisé, car ces matériels sont loin de suivre des standards. Si tu connais par coeur les modèles de matériel POS que tu veux utiliser, je me ferrais un plaisir de t'indiquer si la version actuelle est compatible.

      Pas encore eu le temps d'évaluer en détail OpenBravo POS, mais je ne vois pas ce qui empêcherais de coder un import.
      • [^] # Re: Ou es le module de caisse ?

        Posté par . Évalué à  0 .

        L'imprimante ticket est la classique Epson tm-t88 en usb , qui fonctionne tres bien sous open bravo après configuration des marges.
        Bon ben j'attends le module POS pour dire ce que j'en pense.
        OpenBravo POS étant plutôt délaissé par rapport a l'ERP, et le code relativement abscons (application lourde pensée modulaire par scripting et chargement de classe a la volée, je veux bien...mais bon des fois il faut se rappeler que c'est une caisse, pas un système expert...)
        Je l'utilise en 'production' depuis un an, entre les messages d'erreurs purs qui remontent en popup et diverses limitations incompréhensibles, Ça reste pourtant ce qui il y a de mieux en 'gratuit' et accessible pour un petit commerce.
  • # Wow

    Posté par . Évalué à  2 .

    Gros boulot. Félicitation à ILM pour libérer un tel produit, qui me semble d'ores et déjà promis à un bel avenir.

    Comment le logiciel se positionne t-il par rapport à GestionNX, et par rapport à la concurrence comme OpenERP, OpenBravo ou Dolibarr ?
    • [^] # Re: Wow

      Posté par . Évalué à  2 .

      Merci. 500 visites sur le site ce jour d'après google analytics, c'est encourageant.

      GestionNX c'est le nom commercial de l'ancêtre de OpenConcerto. On peut voir OpenConcerto comme une synthèse des différents développements spécifiques que nous avons pu faire autours de GestionNX. L'idée est de monter en puissance niveau fonctionnalité, sous forme de modules, autours d'un noyau et réaliser les développements spécifiques en modules.

      Je vois plutôt OpenConcerto comme une autre solution libre, pas vraiment un concurrent à un autre projet libre. La concurrence est à chercher du côté des éditeurs de logiciels propriétaires.

      La grande différence technique est que nous avons fait le choix de ne pas baser le logiciel sur des technologies web. Pour le confort d'utilisation bien sûr, mais également pour éviter de bloquer les clients en cas de coupure internet (s'il part dans une offre hébergée).
      • [^] # Re: Wow

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

        que nous avons fait le choix de ne pas baser le logiciel sur des technologies web. Pour le confort d'utilisation bien sûr, mais également pour éviter de bloquer les clients en cas de coupure internet (s'il part dans une offre hébergée).

        On peut très bien avoir les technologies web en local sur le poste, qui peut le plus peut le moins. Ce n'est donc absolument pas un argument pour ne pas choisir des technologies web (ça ne veut pas dire qu'il n'y a pas de bonne raisons pour choisir ce type de développement, juste qu'il faut le choisir pour de bonnes raisons)
        • [^] # Re: Wow

          Posté par . Évalué à  0 .

          'On peut très bien avoir les technologies web en local sur le poste, qui peut le plus peut le moins.'
          Cela necesite aussi l'installation d'un serveur web sur le poste client, qui pour la majorite des cas des petites entreprises est deja beaucoup trop 'lourd' pour l'emploi qui va en etre fait.
          De plus question code, ils est autrement plus simple de travailler sur une appliation riche que sur du web (mon humble avis, mais dans ce cas, il suffit de savoir coder en java, alors qu'en techno web, il faut non seulement savoir configurer un serveur web, savoir ou sont les traces, connaitre au bas mots trois ou quatre langage differents et surtout deployer et autrement plus complexe (mettre le serveur a jour, l'arreter le relancer comme y faut pour rafraichir, gestion des cookies, editer la page web qui va avec etc etc)

          Le web applicatif ne repond qu'a une seule problematique:le deploiment. Et ca fait vraiment pas lourd compare a tous les inconvenients que ca pose par ailleurs.

          A utiliser le navigateur pour une application je prefere encore largement une applet...bien plus ergonomique.
          • [^] # Re: Wow

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

            Cela necesite aussi l'installation d'un serveur web sur le poste client, qui pour la majorite des cas des petites entreprises est deja beaucoup trop 'lourd' pour l'emploi qui va en etre fait.

            Si tu parles de serveur lourd en consommation mémoire, il existe des alternatives relativement légères à Apache httpd.

            « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

            • [^] # Re: Wow

              Posté par . Évalué à  0 .

              'Si tu parles de serveur lourd en consommation mémoire, il existe des alternatives relativement légères à Apache httpd. '
              Non je parle de lourd en 'maintenance'.
              Quand une appli lourde plante a la rigueur, tu la reinstalles ou 'repare', si les donnees ne sont pas corrompues ca repart tout de suite;
              Une appli qui se partage entre un seveur web, le navigateur, une base de donnee installee, quand ca plante il faut commencer a avoir une vraie expertise pour savoir ou ca plante.
              Et ca c'est globalement hors de la portee de 99% des utilisateurs.
          • [^] # Re: Wow

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

            Cela necesite aussi l'installation d'un serveur web sur le poste client, qui pour la majorite des cas des petites entreprises est deja beaucoup trop 'lourd' pour l'emploi qui va en etre fait.

            Wow... Que de préjugés sur ce qui existe.
            http://www.gnu.org/software/libmicrohttpd/
            http://dlib.net/network.html#http

            Il y a des arguments valides pour utiliser du développement non web, mais la difficulté d'installation n'en est clairement pas une (c'est juste une lib en plus!)
            • [^] # Re: Wow

              Posté par . Évalué à  0 .

              Lis mon explication, lourd ce n'est pas qu'une question d'encombrement memoire ou de taille de disque dur (ce dont j'ai d'ailleurs rarement grand chose a foutre sur un poste client).
              C'est surtout une question de maintenance pour l'utilisateur, qui se retrouve avec plusieurs process, et quand y en a un qui plante, savoir lesquels il faut arreter relancer.
          • [^] # Re: Wow

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

            Les points que tu mentionnent sont spécifique à Java peut-être ? Car en python par exemple on peut très bien déployer une application web sans avoir à installer de serveur http ni apprendre plusieurs langages. OpenERP en est un exemple il me semble. Personnellement il m'arrive de déployer des applications web sous windows à l'aide d'un simple exe.

            Ceci dit ça n'a pas grande importance, bravo pour le travail et sa diffusion.

        • [^] # Re: Wow

          Posté par . Évalué à  3 .

          Tout à fait d'accord avec toi, une application en web en local n'a pas de soucis de dépendance du bon fonctionnement de la liaison internet, mais comme je l'indiquais, nous ne somme pas convaincu de la pertinence du "tout navigateur" pour faire une application de gestion en réseau (local).

          Un forum, un webmail, un CMS ou un bugtracker c'est très bien dans un navigateur, mais quand il faut commencer à discuter avec une imprimante série, une douchette code à barres et un tiroir caisse... on est bien content d'avoir un peu plus que HTML/CSS/JavaScript.
          • [^] # Re: Wow

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

            mais quand il faut commencer à discuter avec une imprimante série, une douchette code à barres et un tiroir caisse...

            La, tu parles du back-end, qui peut très bien être en dur, ça ne dit rien sur la présentation, le front-end, qui peut être "web" en ayant le back-end plus compatible avec les API de l'OS.
            C'est un choix (personnellement, je développe une GUI "lourde" aussi) car on a plus de choix dans l'interaction avec l'utilisateur, mais l'argument de la compatibilité avec le matériel est mauvais, car il y a un mélange entre back-end et front-end.

            Encore une fois, le choix peut être pertinent, je soulève juste que l'argumentation sur le choix n'est pas pertinent, et qu'il vaut mieux ne pas avoir choisi la technologie pour cette raison, mais pour de bonnes raisons vraiment liée à la partie présentation.
  • # Code source et installation

    Posté par . Évalué à  1 .

    Un logiciel qui donne envie d'être testé. Mais étant un manche, je n'arrive n'y a trouver le code source ni un guide d'installation (le premier m'aurait éviter de chercher le second). Une idée ?
    • [^] # Re: Code source et installation

      Posté par . Évalué à  3 .

      Pour le tester, le plus simple est de télécharger la version monoposte, prête à l'emploi.
      Sous linux, il y a un script ".sh", pour windows un exe et sous MacOS le .app qui va bien. Dans tous les cas, quelques double clic s (voir triple clics) suffiront.

      Le code source arrive "bientôt", nous avons besoin d'encore un peu de temps pour factoriser des petites choses. Et comme du code sans documentation, ça ne sert a rien, on se donne quelques jours supplémentaires pour écrire de quoi bien démarrer.

      Bons tests!
      • [^] # Re: Code source et installation

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

        Ah! Le code est pas encore dispo! Violation de GPL!
        J'appelle RMS, il bloquera l'accès aux bureaux des développeurs jusqu'à ce que le code soit en ligne!

        (Zut! Il est devant chez moi et je peux plus sortir...)
      • [^] # Re: Code source et installation

        Posté par . Évalué à  1 .

        OK, je m'en doutais un peu. Merci pour la réponse à pas d'heures.
        Je trouve dommage pour vous de créer l'évènement en ouvrant un tel projet (ce qui demande du boulot) et de ne pas en profiter à fond. Il faudra recréer le buzz pour que des développeurs redonnent une chance à votre projet.
        Pour la doc, c'est indispensable bien sur, mais parser rapidement le code d'un projet en dit souvent aussi très long (ne serait que déterminer les frameworks utilisés, le mode de build, l'organisation générale et permet aussi aux codeurs Java de rentrer directos dans le projet....).
        En tout état de cause, bonne chance à OpenErpInJava / oupss OpenConcerto, le monde des entreprises demande des ERP libres et même si ce n'est pas le premier, le coté sérieux, client lourd en Java s'il vous plait, manque cruellement dans la panoplie des applications actuelles (et c'est bien plus facile à vendre que du python ou php dans les sociétés).
  • # Application riche

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

    OpenConcerto n'est pas une application web mais une application riche.

    A l'heure du tout web et du tout nuage, qu'est ce qui a conduit à faire ce choix ?
    • [^] # Re: Application riche

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

      Je ne sais pas ce qui eux les a conduits à ce choix, mais quand je regarde autour de moi, petite PME, artisans, agriculteurs... la plupart utilisent des outils genre EBP et consorts, soit des applications locales simples à installer et à démarrer. Je "plussoie" leur choix.

      L'application web nécessite une garantie sur le fonctionnement des accès Internet en plus de la garantie du fonctionnement de la machine locale. C'est encore assez fragile, surtout pour des gens dont ce n'est pas le métier, et s'il y a des prestataires nécessaires pour être sûr que ça tourne, c'est un coût souvent non négligeable en plus.
    • [^] # Re: Application riche

      Posté par . Évalué à  2 .

      c'est bien le problème actuellement ...

      il y a des technologies "tendances" et si tu n'utilises pas les technologies "tendances" tu passes pour un "as been" même si ce n'est pas du tout adapté au besoin.

      on commence déjà par étudier le problème et ensuite on choisit une techno ... on ne fait pas l'inverse ...

      sauf quand on est DSI qui n'a jamais mis les mains dans le cambouis et qui lit 01 Informatique et qui veut se la péter auprès de ses collègues dans les réunions ...
    • [^] # Re: Application riche

      Posté par . Évalué à  3 .

      Pour faire court, disons que développer une application web c'est avant tout se battre contre les limitations des navigateurs, la latence réseau et les débits pas toujours terribles.

      Côté "OnCloud", OpenConcerto est techniquement prêt. Base de données sur le cloud et logiciel lancé en utilisant webstart, ca fonctionne très bien sur une liaison 3G.
      L'interface graphique du logiciel étant asynchrone, les problèmes liés à la latence et aux débits sont résolus. Nous avons des clients qui utilisent le logiciel à travers des liaisons VPNs en ADSL pour faire du multisite et multisociété et sont ravis de voir que les performances sont là.

      Pour donner une idée des limitations que nous ne voulions pas avoir, voici un exemple concret: l'édition de facture.
      Imaginons qu'un client ait dans sa "procédure qualité" la contrainte qu'une facture doit être toujours imprimée en 2 exemplaires (une pour la société, une pour le client):
      - Un ERP web, proposera un bouton "imprimer" qui créera la facture (souvent en PDF) sur le serveur, l'enverra au navigateur de l'utilisateur, la visionneuse du système prendra le relais pour afficher le document, l'utilisateur cliquera "imprimer", 2 fois. Cela prend plusieurs clics et plusieurs secondes.
      - Avec OpenConcerto, le bouton imprimer peut lancer directement l'impression sur l'imprimante en 2 exemplaires sans rien demander à l'utilisateur. On pourrait même mémoriser qui imprime quoi et quand.
      • [^] # Re: Application riche

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

        Pour donner une idée des limitations que nous ne voulions pas avoir, voici un exemple concret: l'édition de facture.

        Je dirais que c'est un mauvais exemple. Il suffit que le serveur génère un PDF qui contient deux fois la facture et ça résoud le problème.

        « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

      • [^] # Re: Application riche

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

        A te lire, je dirai plutôt que vous aviez en interne des développeurs qui maitrisaient mieux les clients lourds que les technos web.
        Car désolé de le dire, mais faire des applis riches, avec mode offline, avec ergonomie top, ne nécessitant pas un débit énorme, ca fait sans problème. Faut juste avoir les compétences.

        Faut bien voir que tout l'industrie y passe et je n'imagine pas que ca reviendra en arrière. Et je ne l'espère pas non plus car c'est un vrai plaisir d'avoir des technos web qui permettent du multi-plateforme, avec des IHM bcp plus belles que ce qui se fait en client lourd, et surtout basées sur des standards.

        Tiens, si je ne me trompe pas, OpenERP vient de TinyERP qui a l'origine était un client lourd et a migrer vers le web. Ils n'ont pas garder aussi l'ancien client ?
        • [^] # Re: Application riche

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

          Tiens, si je ne me trompe pas, OpenERP vient de TinyERP qui a l'origine était un client lourd et a migrer vers le web. Ils n'ont pas garder aussi l'ancien client ?

          Si, le client GTK reste disponible.

        • [^] # Re: Application riche

          Posté par . Évalué à  0 .

          'avec des IHM bcp plus belles que ce qui se fait en client lourd,' Ce qui n'a rien a voir avec la technique mais que simplement un client lourd s'intègre au bureau parce que le codeur ne s'amuse pas a faire un theme specifique, alors que sur le web on va faire appel a un graphiste pour faire un beau CSS...(ou pas) Sinon vrai question, ca fonctionne bien le drag and drop en web ? (meme si je peste que 99% des clients lourds le font pas alors qu'ils pourraient)

  • # Mocèle de développement / financement...

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

    Je viens d'aller faire un tour sur le site web.

    Q? Avec une distribution gratuite du logiciel, comment pensez-vous vous financer et pouvoir passer du temps à l'améliorer (ie. quel modèle commercial) ?

    Idées:
    * contributions volontaires
    * tickets de support [*]
    * liste d'évolutions demandées, possibilité de financer une évolution particulière, et développement en conséquence
    * commercialisation de boites avec CD d'installation + docs papier
    * formations, kits de formation
    * service de conversion des données d'autres systèmes vers celui-ci
    * ...

    [*] En cas de problème géographique, il peut être intéressant d'avoir un réseau d'indépendants vers qui renvoyer les utilisateurs si vous ne pouvez fournir le service sur place à cause de la distance.
    [**] Pourrait intéresser des gens qui sont enfermés dans un système verrouillé et qui pourraient ainsi passer à autre chose.

    Bonne continuation, j'ai plusieurs fois eu des demandes ("toi qui t'y connais" alors que je ne suis qu'informaticien), et je n'avais rien trouvé de probant en open source qui ressemble à un soft comme EBP par exemple (avec tout son côté verrouillage), les softs communautaires étant soit trop légers, soit prévus déjà pour du client serveur dans le cadre d'entreprise conséquente et nécessitant un support informatique fort.
    • [^] # Re: Mocèle de développement / financement...

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

      Bravo les gars. Ca fait toujours plaisir de voir que des boites se lancent dans un business model OpenSource.

      Tiens, petit conseil en passant : mettez plus en valeur des screenshots ou screencasts, c'est un des premiers trucs que les gens vont voir sur le site d'un outil.

      Et 2e conseil : mettez vous à la place de quelqu'un qui veut vous acheter quelque chose. Et bien c'est pas hyper clair actuellement. genre, tu vas là : http://www.openconcerto.org/fr/support_pro.html et ca redirige là http://www.ilm-informatique.fr/ , et ca y est : t'es perdu.
    • [^] # Re: Mocèle de développement / fi

      Posté par . Évalué à  2 .

      Nous avons déjà quelques idées pour construire un modèle économique viable (pour les utilisateurs comme pour nous).

      Parmi elles:

      • vente d'un manuel d'utilisation
      • commercialisation de services et de support (sur site, par téléphone, emails) via partenaires et en direct
      • développements spécifiques de modules (fonctionnalités, imports, interfaces à d'autres systèmes...)
      • formations
      • fourniture de solutions clef en main (matériel, logiciels, installation et maintenance En gros, tout ce que nous faisons déjà pour nos clients.

      Nous serions très contents d'avoir quelques contributions spontanées (en pub ou en code), pour cela nous préparons les documentations nécessaires.

      Nous pensons aussi à mettre en place un système de mutualisation des financements de développement sur des modules. En effet, tout le monde n'a pas forcément un budget conséquent pour un logiciel de gestion.

      Il n'est pas rare pour nous de voir des clients "subir" un logiciel en boîte qui ne nécessiterait pourtant que quelques modifications pour être éfficace. La politique de l'éditeur étant de faire un logiciel qui peut "convenir" à tous, ça ne risque pas d'arriver... Un bon argument pour choisir OpenConcerto.

      J'imagine aussi que certains acheteurs verront en OpenConcerto une bonne base pour un système informatique performant et préféreront investir en développement une partie du budget économisé en licence.

      Au risque de surprendre, même si OpenConcerto ne rapporte que quelques centimes, nous continuerons à le développer et à le faire vivre en opensource. Tout simplement car nous avons déjà des clients qui l'utilisent depuis quelques années et qui n'ont pas envie de s'en passer.
      Le temps nécessaire à contribuer nos développements dans OpenConcerto est négligeable face à ce qu'un projet opensource nous apporte: visibilité et crédibilité. jOpenDocument a déjà fait beaucoup et au vu des 1400 visites enregistrées par google analytics en 2 jours pour OpenConcerto, nous sommes assez optimistes!

      • [^] # Re: Mocèle de développement / fi

        Posté par . Évalué à  0 .

        'Nous pensons aussi à mettre en place un système de mutualisation des financements de développement sur des modules. ' A mon humble avis c'est ca qu'il faut. Je peux modifier le code pour ajouter un bouton qui me permettra de dire combien il y avait de personnes a payer un ticket. Mais je ne payerais pas plus de 5 euros pour une telle fonctionalite, meme si je sais que ca prends quelques heures a faire ca proprement, donc bien plus cher que 5 euros. Seulement c'est une fonction de base qui je le sais servira a d'autres. Hors il suffit d'une vingtaine de clients interesse et ca vaut le coup. 5 euros c'est pas grand chose, donc pas du style a dire 'J'ai pas envie de payer pour les autres' mais suffisant pour motiver beaucoup de petit commerce a franchir le pas (les caisses informatises pros sont en general tres thematisee, donc offrant une vraie plus value), mais aussi assez cheres pour celui qui n'a pas un commerce qui fait ed gros volumes de ventes. Je trouve d'ailleurs que beaucoup d'ERP libre negligent totalement le cote caisse, alors que c'est la base pour un commerce ! Et quand je dis caisse c'est toute ce qui concerne le 'client' particulier (que ca soit devis, caisse, creation d'offre promotionelle etc) A croire qu'il ne veulent pas toucher aux petits sans le sous et ne veulent bosser qu'avec du BtoB

  • # Un ERP ?

    Posté par . Évalué à  3 .

    J'ai testé la version monoposte. Je suppose qu'elle est isofonctionnelle avec la version multiposte. En tout cas, aussi intéressante puisse-t-elle être, ce n'est pas un ERP. Les possibilité de configuration sont faibles, pas de gestion fine des droits (un utilisateur est administrateur ou simple utilisateur), peu de modules et impossibilité de supprimer par exemple le module de compta, pas de moteur de workflow, ... En outre existe t-il un framework qui facilite la création de nouveaux modules, comme le propose OpenERP avec OpenObject ?

    Il y a deux trucs que je trouve pénibles: les boites de dialogues s'ouvrent toutes dans le coin supérieur gauche de mon écran alors que pour toutes mes applications chaque fenêtre s'ouvrent au milieu de la fenêtre parente conformément à la config. de mon KDE 3.5 et enfin il y a les champs obligatoires dont le fond clignote lentement .... Grrrr! :-)

    Je l'ajoute quand même dans la liste des projets à suivre.

    • [^] # Re: Un ERP ?

      Posté par . Évalué à  2 .

      OpenConcerto est bel et bien un ERP. Je comprend très bien qu'on puisse facilement passer à côté vu que nous avons encore pas mal de doc à écrire :)

      Pour la configuration, il ne faut pas mélanger les préférences et la configuration de l'ensemble. La gestion des droits est là et est très compléte (Menu Structure), il est possible par exemple de gérer indépendament les droits sur chaque action (tables) pour: ajout, modification, suppression et accès en lecture. Ces droits sont par utilisateur. Les menus se simplifient en fonction des droits associés. Il est possible de gérer les droits par "ensemble". Il est aussi tout à fait possible de supprimer le module de compta et de modifier les workflow.

      Nous avons mis l'accent sur la possibilité de créer des modules pour ajouter des fonctionnalités, changer des comportements, faire des imports, etc... Encore un peu de patience, nous allons fournir doc et outils. Vous verrez que nous avons un système efficace d'accès aux bases de données et d'UI.

      Pour les boîtes de dialogues, est ce que cela touche toutes les fenêtres du logiciel? Peut-on en savoir un peu plus sur votre distribution, version de java, etc? Le logiciel doit également mémoriser la position des fenêtres, est ce que cela fonctionne?

      Que proposez vous pour remplacer le fond jaune clignotant des champs pas ou incorrectement remplis?

      • [^] # Re: Un ERP ?

        Posté par . Évalué à  1 .

        Pour les boîtes de dialogues, est ce que cela touche toutes les fenêtres du logiciel?

        Presque toutes. Informations, Astuces, Préférences et Sauvegarde de la base s'affichent au milieu de l'écran, les autres (ou presque je n'ai pas tout testé) s'affichent en haut à gauche.

        Peut-on en savoir un peu plus sur votre distribution, version de java, etc?

        • Debian Lenny,
        • KDE 3.5.10,
        • java version "1.6.0_22", Java (TM) SE Runtime Environment (build 1.6.0_22-b04), Java HotSpot(TM) Client VM (buold 17.1-b03, mixed mode, sharing)

        Le logiciel doit également mémoriser la position des fenêtres, est ce que cela fonctionne?

        A l'exception de la fenêtre principale qui persiste à vouloir s'afficher en haut à gauche, elles conservent leurs positions absolues.

        Que proposez vous pour remplacer le fond jaune clignotant des champs pas ou incorrectement remplis?

        Je trouve le clignotement pénible. Un simple fond de couleur ne suffit-il pas ?

Suivre le flux des commentaires

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