Guillaume Maillard a écrit 274 commentaires

Le dépôt, nous l'avons déjà : https://code.openconcerto.org

Le temps qui nous manque est passé à s'occuper de nos clients, on a juste besoin de plus d'utilisateurs qui passent le pas du cloud ou prennent un contrat de maintenance afin de nous donner de l'air financièrement.

La version web arrive prochainement.
Avec elle, un tas de changement et aussi une API (json rpc).

Il est vrai que le temps manque, nous avons un carnet de commande rempli à plus de 6 mois.

C'est quoi le concept de "souplesse technique"?

On fait ce qu'on peut avec nos petits moyens (par rapport à Odoo).

Si vous voulez nous aider, profitez du forum d'OpenConcerto pour faire vos retours pour atteindre "la perfection".
On ne vous en voudra pas non plus si plus dépensez quelques euros dans l'histoire ;)

Belle réussite et chapeau d'avoir su gérer une croissance si forte!

Bonjour,

Les immobilisations, oui c'est prévu, cela fait partie de la feuille de route présentée lors du live YouTube (lien dans la dépêche).

Les calculs des immobilisations n'étant pas très compliqués, beaucoup d'utilisateurs se satisfont d'un calcul sur tableur et de la saisie manuelle des écritures associées.

Les deux versions vont partager plus de 90% de leur code, donc à part si plus aucun de nos clients ne veulent utiliser la version desktop, nous continuerons à faire évoluer les deux.

Par contre, vu que l'on sortira une version desktop "client léger", elle risque de prendre le pas sur la version classique dans le coeur des utilisateurs.

Ensuite ce bouton fait appel a du code coté backend

C'est justement le point bloquant. Difficile pour le backend de discuter avec un port USB ou série branché sur le poste local, idem pour les lecteurs RFID, les scanners, et les services du système d'exploitation en général.

Odoo a tendance a contourner avec une approche 100% réseau, quitte à utiliser un Raspberry comme passerelle. Cette approche n'est pas forcement simple ou possible à mettre en œuvre, surtout quand le serveur est sur le cloud.

Le xpath est compilé à la volée lors de la mise à jour du module du coups les erreurs sont détectées immédiatement

Je ne pensais pas forcément à des erreurs syntaxiques. De mon point de vue, une API permet des interactions et des vérifications bien plus poussées qu'un simple fichier de description.
Dans le cas d'Odoo, en plus du xml il faut ajouter un peu de Python pour sortir du cas simple. N'ayant pas vraiment d'expérience dans ce domaine, je ne saurais dire si c'est gênant ou pas.

La version web a été présentée dans la vidéo du live. Cette version sortira cette année, difficile de dire quand, la crise sanitaire et divers gros projets ont "un peu" chahuté nos plannings.

Pour Dolibarr, on ne le voit que par le prisme des clients qui souhaitent migrer vers OpenConcerto, de ce qu'il en ressort c'est effectivement une certaine latence pour la résolution de bugs (un peu plus de 800 bugs non corrigé à ce jour…) et pour les évolutions réglementaires.

Pour les micros budgets, Dolibarr c'est très bien. J'ai vu passé des hébergement "illimité" à 5€ par mois.

La réponse va vous surprendre :)

Le "framework" d'OpenConcerto dédié aux accès base de données supporte MySQL, PostgreSQL, SQLServer et H2, il a donc fallu trouver des dénominateurs communs fiables.

Parmi eux: imposer ces "fameux" guillemets sur les noms et les 'quotes' sur les valeurs, car leurs interprétations dépendent de le base de données ET de leurs réglages par défaut.
En conséquence, mettre les tables en majuscule a été le moyen le plus simple pour décourager fortement l'écritures de SQL à la main, le framework s'occupant de la syntaxe et des bizarreries des différents systèmes.

Merci.

Je ne dénigre pas Node.js ou la tendance NoSQL. Techniquement je vois juste mal comment garantir une comptabilité correcte sans contraintes fortes, ni comment maintenir le demi million de lignes de code Javascript nécessaire à un logiciel qui doit s'occuper de comptabilité, gestion commerciale, paye, etc…

Dolibarr n'est pas un mauvais choix, peut-être que la version web d'OpenConcerto placera ce dernier comme une alternative pour ceux qui ne jurent que par le "zéro install" des applications web. Wait&See.

Effectivement, l'IHM c'est avant tout une histoire d'efficacité et de lisibilité.

On travaille sur l'interface web d'OpenConcerto, en complément de l'interface native.
Je doute que l'on puisse rivaliser avec ce que l'on peut faire sur desktop en standard (multifenêtre, drag&drop, contrôle totale de l'UI, etc…) sans compter les interactions avec l'OS et le matériel (bon courage pour imprimer sur une imprimante d'étiquette industrielle type Zebra depuis le web).
J'ai l'impression qu'il y a une certaine confusion chez les utilisateurs entre "moderne" et "web". Faute surement aux aficionados du html et du javascript, ou de commerciaux pas forcement très calés en IHM.

Au passage, je trouve la situation des développements sur tablettes et téléphones assez ironique, tout le monde plébiscite les applications mobiles natives.

Niveau "extensibilité", cad le point important pour un ERP, de ce que je connais d'Odoo, il s'en sort très bien.
Je ne vois pas spécialement de limite à l'extensibilité d'OpenConcerto, nous avons un système de modules, d'interfaces graphiques dynamiques, etc… dans l'implémentation, l'approche est bien différente, le typage "fort" de Java permet certaines vérifications à la compilation. De plus, nous évitons les fichiers de description (xml, json,…) au maximum pour s'affranchir des erreurs de frappes que l'on ne découvre qu'à l'exécution (de mémoire les interfaces d'Odoo sont décrites en xml (+xpath)).

Bonjour,

Bien vu, généralement nous mentionnons les deux!
La page sur la gestion commerciale est actualisée.

Merci.

Quelques compléments :

Les OpenJDK 8 à 14 sont supportés.

Pour ce qui est du logiciel à installer sur les postes, la prochaine version (2.0) aura également une version Web.

Vous êtes de mauvais poil aujourd'hui vous deux ou est-ce un nouveau sport de balancer des trucs négatifs en mode maxi-flou, le tout de l'ordre d'un ressenti ineffable?

Bref, c'est quoi un look 1990/2000 ? C'est quoi un code 1990/2000 ?
Vous connaissez un peu les logiciels majeurs du marché pour comparer?

Si vous voulez un machin en Node.js et NoSQL, des polices en tailles 32 en mode arc en ciel, vous allez en effet être déçu.

Bonjour,

Est ce que l'on propose des sessions de formation dans des cadres paradisiaque?

Non. Mais on garde l'idée pour les clients ayant envie de financer ce genre de chose ;)

Plus sérieusement, pour ce qui est d'une base de données exemple, OpenConcerto est livré de base avec une base contenant quelques clients, fournisseurs, devis, factures, etc… et rien n'empêche de vous en faire une.

Avant de répondre "N'importe quoi.", merci de balancer quelques chiffres sourcés.
Ca sera beaucoup plus crédible et intéressant.

Oulala, les gris de l'interface ne sont plus vraiment gris et vont fausser l'affinage colorimétrique des millions d'images :)
Je plaisante bien sur! (faut avoir suivi les autres dépêches pour comprendre…)
Le passage à GTK3 est une belle avancée et le changelog bien costaud.

N'étant pourtant pas le dernier à soutenir (et aussi créer) des logiciels libres, je trouve tout cela bien approximatif.
Les logiciels Autodesk et Adobe n'ont pas à ce jour d'équivalent libre, je côtoie assez d'utilisateurs professionnels pour en être absolument convaincu (non pas par de la rhétorique mais par les faits).

Les logiciels libres sont souvent limités par le budget, ce qui se traduit par : petite équipe, documentation mince, suite de tests rares, suivi de version aléatoire, support professionnel inexistant ou lacunaire.
Combien de développeurs à temps complet rémunérés pour GIMP vs Photoshop, LibreOffice vs MS Office?
Le ratio est tellement important que le talent des uns ne peut pas rivaliser avec les moyens des autres.
Et encore… avez vous goûté au publipostage sur LibreOffice?

Imaginons que demain une vraie alternative libre, à par exemple InDesign, soit proposée par un éditeur, qui sera prêt à payer autant (voir plus) que ce que facture Adobe?
(afin que le logiciel puisse fournir le même niveau de stabilité, documentation et support)

Personne.

(à charge: ces 20 dernières années)

Les seuls logiciels libres qui s'en sortent aussi bien que les logiciels propriétaires sont ceux financés par de gros acteurs pour leurs besoins.

J'aimerais vraiment bien qu'un jour, on ait un vrai financement qui permette d'avoir un salaire décent pour le projet, et même d'engager d'autres gens! (petit rêve d'un studio d'animation qui fait des films libres avec plein d'artistes et plein de développeurs qui améliorent les logiciels libres! Mais bon pour l'instant, on n'arrive même pas à avoir de quoi payer un seul temps plein au SMIC, alors notre rêve… on en est loin)

Peut être qu'il est temps de mettre côté les corrections et développements de nouvelles fonctionnalités, pour s'occuper de ce point, que me semble être d'une priorité quasi absolue, car conditionne le reste.

Nul besoin de m'incendier avec des "oui bien sur, yaka" ou "plus facile à dire qu'à faire".
Il est beaucoup plus facile de s'occuper du "commercial" que de coder.
Une partie des utilisateurs est surement prête à acheter quelques choses, ça peut être un manuel, l'accès à des versions "bleeding edge", etc…
Bref, pas envie de m’étendre la dessus, car beaucoup d’énergie va être déployer pour m'expliquer qu'il ne faut pas faire ci ou ça…

Dans le "monde" des ERPs, la montée en version est payante dans la majorité des cas.
Pire encore, elle est parfois impossible.
Avec OpenConcerto, nous récupérons des clients Sage (principalement, mais pas seulement) qui n'ont pas mis à jour leur logiciels pendant plus de 5 ans. Devant se mettre à la page, ils décident "d'acheter" la nouvelle version à prix d'or, car trop leur version est trop ancienne pour juste "acheter" une mise à jour. Petit hic, l'éditeur ne sait pas (ou "plus") migrer les données de son propre logiciel.

Sur le papier, proposer des mises à jour de base de données c'est assez simple.
Dès que l'on manipule des centaines de tables, soit des milliers et des milliers de champs, ça devient compliqué car chaque module (même non customisé) peut monter en version indépendamment des autres et utiliser des champs "communs".
Au final, on se retrouve a garantir que chaque module peut monter en version individuellement, mais l'ensemble des modules, pris à des versions différentes, l'opération est plus coton. Les changements de structure de base nécessitent des petits programmes ("moulinettes") qui vont "redispatcher" les données, programmes qui doivent être assez clairvoyantes pour anticiper les changements apportées aux données par d'autres modules.
C'est d'ailleurs pourquoi dans le cas d'OpenConcerto, pour passer de la version 1.3.2 à la version 1.6.3, il faut passer par la version 1.4, 1.5, 1.6 puis 1.6.3.

Dans le cas d'Odoo, la mise au point de l'upgrade doit être titanesque, pas étonnant donc qu'elle soit payante vu la complexité et le risque de problèmes.

(ici on parle de données critiques pour l'entreprise, pas de place pour la bidouille).

J'aime beaucoup le "c'est pour ça".
Donc, si la durée de validité est 4 fois plus courte, il n'y aura pas 4 fois plus de loupés?
Par quelle magie?

Merci pour ces précisions. Super boulot.

Développer ce genre de solution soi même ne coûte en effet presque rien en matériel, mais que dire du temps passé ?
Je serais assez curieux de savoir combien tu facturerais un tel développement si quelqu'un te demandait de le faire (en partant de rien comme tu l'as fait).

Permets moi d'ajouter quelques remarques :

• il est plus simple de falsifier une compta informatique que papier (d'où la fameuse loi de finance visant à rendre plus facilement auditable les logiciels de caisse, suite à de nombreuses fraudes permises volontairement par certains éditeurs). Une ligne barrée, modifiée, une page manquante, ça se voit facilement sur un libre de vente.
• arrondir est commun et est parfaitement légal si favorable au client. Cela permet de se simplifier la vie dans la gestion de caisse.
• concernant les banques, les encaissements de toute nature (pas que les CBs) sont "taxés", en moyenne à 0.5%, ce qui est loin d'être négligeable.