Oui, on cherche une solution pour que ce soit gratuit pour nos utilisateurs Odoo Online & Odoo Enterprise, tout comme on fait pour les connections banquaires et autres. (donc pas dans la version community, car on va devoir prendre les frais à notre charge)
Mais Odoo Online Comptabilité est gratuit avec hébergement & support; c'est ce qu'utilise les fiduciaires comme: https://www.youtube.com/watch?v=OsVZgFLYNrU . (une app est toujours gratuite avec Odoo, hors une fidu n'a besoin que de la comptabilité pour ses clients).
Posté par pinky .
En réponse à la dépêche Sortie d’Odoo 14.
Évalué à 9.
Dernière modification le 06 octobre 2020 à 12:50.
Quelqu'un pourrait expliquer quel est le modèle d'Odoo aujourd'hui ?
C'est un modèle open core; 80% de nos apps sont open source, et 20% sont propriétaires. Il n'y a pas de dépendances fortes entre les deux, afin que les utilisateurs open source ne soient pas "forcés" de prendre du propriétaire.
On ne cherche pas à faire basculer les utilisateurs open source sur l'offre payante. Ce n'est pas notre modèle car 1/ on souhaite que ODoo COmmunity soit le meilleur logiciel de gestion open source en tant que tel, et 2/ on ne peut pas vendre des apps à un utilisateur open source: on le frustrerait.
C'est comme si on avait deux produits, pour deux marchés différents: on a un produit open source pour ceux qui veulent du libre (de loin le logiciel de gestion le plus complet en open source) et on a des fonctions payantes en plus pour ceux qui en ont les moyens. Mais les utilisateurs Odoo Community restent sur Odoo Community, et les utilisateurs Enterprise restent sur Enterprise.
L'avantage c'est que le produit payant (Odoo Enterprise) finance 100% de nos développements open source; cela nous permet d'avoir ~200 développeurs temps plein qui améliorent le produit open source.
Exemple d'apps open source:
- CRM, ventes, gestion de stock, fabrication, achats, website builder, eCommerce, facturation, HR, gestion de projets, etc.
Exemple d'apps propriétaires:
- comptabilité, Studio
Certains peuvent voir le modèle open core comme une force négative contre le produit open source. Cela a été le cas pour certains éditeurs. Mais pour Odoo ce n'est pas du tout le cas, c'est même l'inverse: si on peut développer un si bon produit open source, c'est parcequ'on est financé par les revenus d'Odoo Enterprise.
On contribue aujourd'hui 10x plus à l'open source qu'il y a 3 ans, lorsque l'on n'avait pas ce modèle open core. Simplement parcequ'on peut payer plus de développeurs qui améliorent Odoo Community.
Posté par pinky .
En réponse à la dépêche Sortie d’Odoo 14.
Évalué à 10.
Dernière modification le 06 octobre 2020 à 12:36.
Ce n'est pas tellement lié au modèle open core, mais au fait qu'une migration de ce genre de logiciel est extrêmement complexe: chaque société est différente, a des workflows différents, a des custos, … Ce n'est pas juste une migration de données: mais des changements de workflows, des adaptations de custo, du support/formation des utilisateurs, …
C'est tellement complexe que c'est un marché de service, et non juste un produit à acheter: Odoo a un département avec des dizaines d'employés pour assurer ce service.
Du coup, cela donne deux possibilités:
- utiliser les outils open source: gratuit mais il faut y passer du temps à tester et adapter soi même
- utiliser le service payant
Avec, ou sans modèle open core, ce serait la même chose; c'est simplement du service autour du logiciel. Pour ma part, je trouve cela fair; les utilisateurs ne sont pas "bloqués" au sens où ils peuvent le faire eux même avec les outils communautaires, mais ceux qui ont les moyens peuvent faire appels aux services de pro (soit chez un partenaire, soit chez l'éditeur; là non plus, il n'y a pas de lockin)
--> note: je suis parti pris, car fondateur de Odoo.
Posté par pinky .
En réponse à la dépêche Sortie d’Odoo 14.
Évalué à 4.
Dernière modification le 06 octobre 2020 à 07:26.
Les mises a jour ne sont malheureusement pas simples. Il y a deux approches:
- pour Odoo community, il y a le projet OpenUpgrade: c'est pas parfait, c'est donc pour des développeurs: https://github.com/OCA/OpenUpgrade
- pour les utilisateurs Odoo Enterprise, le service est compris dans l'abonnement. S'il veut upgrader sur cette version, il peut alors utiliser le service ici: https://upgrade.odoo.com (dans ce cas, Odoo SA s'occupe de tout: upgrade, tests, amelioration des scripts pour sa dB particulière…)
Si vous testez le nouvel éditeur de site web, les devs seraient heureux d'avoir votre feedback;
- ce que vous avez réussi à faire, ou pas
- est-ce qu'il vous manque des options dans la barre de droite?
- est-ce que le résultat est joli: idéalement, une photo d'écran, ou l'URL du site et le temps qu'il vous a fallu pour le faire
J'oubliais, on a open sourcé le module carte de fidélité depuis Odoo 13. Il est donc, depuis Odoo 13, dans Odoo Community.
Le service de migration est gratuit pour Odoo Enterprise, si le commerçant est dans une version antérieure.
Mais j'attendrais la v14 qui sort dans 7 semaines pour faire un upgrade; il y a pleins d'améliorations pour les modules qu'il utilise: POS, Website, eCommerce, achats, …
Je suis le fondateur d'Odoo, voici quelques éléments si cela peut aider:
il n'est malheureusement pas possible de renégocier le prix avec Odoo: notre stratégie est d'offrir les prix les plus bas du marché mais on n'a pas de marge pour proposer moins. Nos prix sont en ligne, et ne sont pas négociés sauf si >500 users. (transparence totale)
si le commerçant a des soucis de cash, il peut passer en mode mensuel, c'est un peu plus cher: 197€ / mois pour le même scope.
si, au contraire, il veut diminuer le coût long terme, il peut demander du multi-année. Je n'ai plus la grille en tête, mais on fait de l'ordre de 15% pour 3 ans. (pas certain)
les prix ne vont pas augmenter dans le futur; au contraire, on cherche en permanence a voir si on peut plutôt diminuer. Ces 5 dernières années, les seuls changements de prix étaient des diminutions (seul studio a diminué en France, mais on a diminue bcp d'autres pays). Même si on changeait d'avis, son contrat contient une clause garantissant max 7% d'augmentation aux clients existants.
s'il utilise Odoo Enterprise, il n'héberge peut-être pas chez Odoo. Il peut économiser en passant sur Odoo Online (hébergement gratuit pour les clients Enterprise)
Il n'y a pas de comptabilité dans Odoo Community: ni les features, ni le certificat obligatoire en France. Il y a des extra features dans la communauté, mais rien pour une vrai compta complète, et le certificat nécessaire en France. (Je signe les certificats: vu que je peux être tenu responsable en cas d'utilisation d'un Odoo non conforme, je préfère être clair car :)
Je suis parti pris, mais pour le scope: eCommerce, POS, Compta, Stock, achats, ventes… 197€/mois ou 1900€ par an, ce n'est rien. Le prix comprend: support illimité 24/24, upgrades, hébergement haute disponibilité (5 serveurs: 3 backups dans deux data centers différents, 2 serveurs de prod réplication, emails, …).
Selon ma connaissance du marché, n'importe quelle alternative pour le même scope sera bcp plus chère, et sera nécessairement avec une solution bcp moins bien (plusieurs soft a intégrer ensembles, et pas du niveaux 'Odoo); que ce soit avec du libre, ou du proprio d'ailleurs.
Ce lien concerne un module qui ne fait pas partie de Odoo, un module tiers de l'OCA. Je n'ai pas creusé plus que cela, mais probablement un bug dans leur code qui court-circuite l'ORM standard. L'ORM Odoo traite bien les décimal correctement. Voici un test fait rapidement (sur une branch master-nochange-fp, mais le comportement est le même depuis les premières versions de Odoo): http://tinyurl.com/y263r7cx
En fait, le contexte de decimal ne doit pas être mis à jour pour chaque variable. Dans le pratique on définit une fois la précision des calcules intermédiaires (les valeurs par défaut prec=28, Emin=-999999, Emax=999999 sont bien dans la majorité des cas). Et on arrondit le résultat final à la précision attendue.
Faire cela amène les même désavantages que d'utiliser un float; si tu ne travailles pas avec la bonne précision, il faut alors quantize() manuellement à certains endroits dans le code. (e.g.lors de comparaisons, ou avant de storer, calcul de taxes, …)
Le débat revient juste à choisir quel côté du trade-off on préfaire:
- float: performance, flexibilité / facilité de code
- decimal: permettre de gérer des nombres avec plus de 16 chiffres
Odoo a prit le parti que les nombres à plus de 16 chiffres n'apparaissent pas dans les domaines concernés par les decimal (typiquement la compta). Mais, même si à l'avenir, dans un domaine fonctionnel particulier, on a vraiment besoin de gérer des très grands nombres, rien n'empêche d'utiliser un type Decimal dans le code (et les représentations DB sont Numeric); c'est juste que ce cas ne s'est jamais produit.
PS: je t'invite a chercher sur google "tryton issue quantize" pour prendre du recul --> les deux approches ont leurs inconvénients.
Je serais intéressé d'avoir un feedback sur vont besoins qui n'ont pas été couverts par le standard. Pouvez-vous m'envoyer une liste par email (fp AT odoo DOT com)? On va justement définir notre roadmap v14, dans qq semaines.
Voici l'explication de notre choix pour l'implémentation des floats: Odoo gère bien les chiffres comme des decimal au niveau de PostgreSQL (numeric), mais comme des floats en mémoire (ORM). C'est pour moi le meilleur compromis car:
- tout est bien stocké en decimal après chaque opération dans la DB (tronqué correctement en fonction de la devise / UoM / …). C'est pratique car un champ a bien un contexte défini (précision, rounding), alors que les variables intermédiaires dans le code n'en ont pas nécessairement.
- cela ne pose strictement aucun problème d'arrondi pour des use cases business (les float Python sont des double C --> 11 bits exposant, 52 bits valeur), le seul risque est de ne pas faire une comparaison correcte à 0, lorque vous développez un module custo.
Utiliser le type decimal en Python serait en fait beaucoup plus compliqué, principalement à cause des getcontext() -> on ne ferait que déplacer le problème (comparaison à 0) à toutes les opérations arythmétique (mise en place du bon contexte à chaque calcul, au lieu de s'appuyer sur la définition du champ lorsque l'on stocke la valeur).
Par exemple, lorsque vous faites: Prix TTC = Pric HTVA * Quantité * Discount * TVA, chacune des variables ont des précisions différentes, il faudrait alors démultiplier les appels à decimal.getcontext().prec = X. Calculer en float, et tronquer à la fin (lorsque la variable Prix TTC est ensuite écrite dans le champ amount_total pour qui une précision est définie) est à la fois plus performant, et beaucoup plus simple. On considère le risque d'erreur négligeable car il faut un montant à 1016 chiffres pour avoir un risque de un cent. (ce que probablement aucune société au monde n'a dans ses comptes, sur un seul document)
Le risque de bug par un développeur de module est pour moi beaucoup plus grand si Odoo n'utilisait que des decimals, au lieu de cette approche mixte (à cause des multiples définitions de contexte, alors qu'ici c'est délégué à la définition du champ de l'objet). Sans compter les multiples exceptions TypeError lorsque l'on multiplie un vrai float (discount/quantity) par un decimal.
D'une manière générale, à chaque nouvelle version, Odoo Community reçoit énormément de nouvelles fonctions et améliorations. On garde le même ratio depuis quelques années: 80% de nos développements sont sur Odoo Community (la version open source), et 20% sont sur Odoo Enterprise (les extras features propriétaires).
Bien sûr, à chaque nouvelle version, on améliore beaucoup de features. Il y a donc des comportements qui changent, et des corner cases qui peuvent ne plus être supportés. C'est une gestion de produit normale, Odoo s'améliore très vite, cela induit beaucoup de changement. Mais notre mentalité est de rester le plus compatible possible (très peu de suppressions, même s'il peut y en avoir), et ce qui est open source reste open source.
Dans tout ls cas, il n'y a aucune volonté de diminuer la version open source par rapport à la version propriétaire. Au contraire; les revenues générés par Odoo Enterprise sont majoritairements investis pour améliorer le version community. (raison pour laquelle Odoo Community avance bcp plus vite que tous les autres acteurs libres)
Je suis parti pris car je suis co-auteur du jeu. Je suis également fondateur et CEO d'une société de 660 employés (Odoo).
Je pense au contraire que Scale-up!, représente bien les challenges d'un entrepreneur moderne. Le jeu ne couvre pas les aspects stratégiques de la gestion d'entreprise, mais plus les aspects d'execution. (Et un entrepreneur passe la majorité de son temps dans l'exécution, très peu dans les reflections stratégiques)
Scale-up! ne couvre évidemment pas toutes les fonctions d'un entrepreneur, mais les processus proposés couvrent quand même de nombreux besoins: achats, ventes, gestions de projets et services, organisation d'un entrepôt avec barcodes, fabrication, lancement d'une boutique en ligne, création d'une app sur mesure.
Nous aidons des centaines d'entreprises a améliorer leur gestion. Et, très souvent, cela passe par mettre en place des processus efficaces. C'est clé pour faciliter la croissance.
Je dirais que c'est un état d'esprit que nous avons développé :
- notre priorité est de réussir le projet (dans les temps et budget), pas de satisfaire le client (en faisant tout ce qu'il veut).
- la majorité des demandes clients ne sont pas utiles: on peut faire tout aussi bien autrement. On a prit l'habitude de challenger la demande
- on sensibilise le client au coût de la dette technique en faisant payer la maintenance des le début, comprenant support illimité, correction de bogues, et migrations.
- il faut des chefs de projets qui ont une très grande connaissance du produit et du métier du client, et qui ne sont surtout pas developpeurs
Nous avons déployés ~900 industries dans le manufacturing, sans développement spécifique. Je suis donc curieux de voir ce qu'il vous manque comme fonctionnalité (pour quoi avez-vous dû faire des développements spécifiques)?
Pour bien connaître la concurrence (NetSuite, Ms. Dynamics, SAP B1), je trouve qu'Odoo a beaucoup plus en standard. Très souvent, dans les appels d'offres que ous faisons, nous répondons avec un seul outil (Odoo), alors que les concurrents doivent faire des connecteurs avec différents outils car tout n'est pas de base chez eux (ex: maintenance, plm, configurateur produit, portail pour pièces détachées, workcenter control panel, reporting avancé…)
Bien sûr, Odoo n'a pas tout, mais je doute qu'il ait moins que Dynamics, Netsuite ou SAP BO.
Je ne suis pas certain de comprendre votre commentaire. Déjà en v11, Odoo a les nomenclatures multi-niveaux, les non conformités, les lots, les chutes, la consommation progressive des matières. Vous semblez dire que ce n'est pas efficace, pouvez-vous préciser?
Odoo a un moteur de rapport super puissants (cube, pivot, graphs) et la v12 apporte des dashboards ala Google Analytics. Mais Odoo n'a pas de vocation a faire du reporting sur différentes DB, comme le ferait un outil de BI.
Et pour la compta Odoo en v9, il me semble que l'interfaçage avec de
grandes banques françaises et la majorité des nouveautés en
comptabilité sont uniquement disponible dans la version Enterprise
qui est non-libre. Tu confirmes ?
Oui et non. La plupart des fonctionnalités v9 en compabilité sont dans Odoo Community, la version Open Source. (tout le refactoring v9 en fait, sauf les nouveaux rapports et les banques)
L'interface avec les banques est dans Odoo Enterprise. Ce sont des accords à plus de 200k€ par an pour obtenir de tels accès. Même si c'était open source, ce serait inutilisable car la seule manière de faire est de prendre un contrat pour tous les clients et de reventiler les coûts par client. Hors comme on a un coût par banque interfacée en plus du coût fixe (~0.7€), on ne peut pas mettre cela libre.
En Belgique, le gouvernement a introduit le même principe pour les restaurants, ce qu'ils appellent la "boite noire". C'est encore pire car il faut s'interfacer avec un hardware propriétaire et assez cher que chaque restaurant doit acheter (350€). Cela n'a pas empêché Odoo de se certifier, nous avons obtenu la certification il y a 3 jours.
Même si je trouve que ces projets de loi sont stupides (ceux qui veulent tricher trouveront toujours le moyen de tricher), je ne pense pas que ce soit un frein aux logiciels libres. Il y a toujours des moyens de contourner la loi.
Ce que nous avons du faire, c'est faire un fork avec une autre license, non libre. (mais qui est identique à Odoo standard) La contrainte n'est cependant pas que pour les logiciels libres, les logiciels propriétaires sont soumis aux mêmes problèmes de certifications dès qu'ils font un changement. Je pense qu'on doit même pouvoir faire sans un fork.
Bref, cela ne doit pas nous empêcher de faire des softs de comptabilité ou de gestion de caisse. Chez Odoo, on compte bien faire passer la certification française. (et je suis sûr qu'on trouvera des failles dans la loi/certification pour faire évoluer le logiciel en limitant les coûts de certifications. La loi, c'est comme les logiciels, c'est pleins de trous de sécurité)
Autre note: je vous invite à tester Odoo Comptabilité pour la France, c'est une tuerie depuis la v9. On s'interface même avec plusieurs grandes banques françaises pour automatiser la réception des extraits et paiements SEPA.
[^] # Re: Not free enough
Posté par pinky . En réponse à la dépêche L'Agenda de Odoo Experience, et lancement Odoo 16. Évalué à 3.
Pour la compta, vous pouvez toujours utiliser Odoo Community avec les modules libres de l'OCA pour compléter la compta.
Normalement, il y a un sélecteur de langue dans le footer. Sinon, voici le lien pour passer en français: https://odoo.com/fr_FR
[^] # Re: intéressant
Posté par pinky . En réponse à la dépêche Odoo : support de la déclaration de TVA avec télétransmission. Évalué à 2. Dernière modification le 08 décembre 2021 à 09:37.
Oui, on cherche une solution pour que ce soit gratuit pour nos utilisateurs Odoo Online & Odoo Enterprise, tout comme on fait pour les connections banquaires et autres. (donc pas dans la version community, car on va devoir prendre les frais à notre charge)
Mais Odoo Online Comptabilité est gratuit avec hébergement & support; c'est ce qu'utilise les fiduciaires comme: https://www.youtube.com/watch?v=OsVZgFLYNrU . (une app est toujours gratuite avec Odoo, hors une fidu n'a besoin que de la comptabilité pour ses clients).
[^] # Re: Alternatives à Odoo
Posté par pinky . En réponse à la dépêche L’envolée de Odoo, le logiciel de gestion open source. Évalué à 6.
Il vaut mieux prendre ces deux liens-ci pour les docs:
- eLearning: https://odoo.com/slides
- Documentation: https://www.odoo.com/documentation
Le lien pré-cité concerne les vieilles versions d'Odoo et devrait être déprécié d'ici qq mois.
[^] # Re: Test Odoo
Posté par pinky . En réponse à la dépêche Sortie d’Odoo 14. Évalué à 9. Dernière modification le 06 octobre 2020 à 12:50.
C'est un modèle open core; 80% de nos apps sont open source, et 20% sont propriétaires. Il n'y a pas de dépendances fortes entre les deux, afin que les utilisateurs open source ne soient pas "forcés" de prendre du propriétaire.
On ne cherche pas à faire basculer les utilisateurs open source sur l'offre payante. Ce n'est pas notre modèle car 1/ on souhaite que ODoo COmmunity soit le meilleur logiciel de gestion open source en tant que tel, et 2/ on ne peut pas vendre des apps à un utilisateur open source: on le frustrerait.
C'est comme si on avait deux produits, pour deux marchés différents: on a un produit open source pour ceux qui veulent du libre (de loin le logiciel de gestion le plus complet en open source) et on a des fonctions payantes en plus pour ceux qui en ont les moyens. Mais les utilisateurs Odoo Community restent sur Odoo Community, et les utilisateurs Enterprise restent sur Enterprise.
L'avantage c'est que le produit payant (Odoo Enterprise) finance 100% de nos développements open source; cela nous permet d'avoir ~200 développeurs temps plein qui améliorent le produit open source.
Exemple d'apps open source:
- CRM, ventes, gestion de stock, fabrication, achats, website builder, eCommerce, facturation, HR, gestion de projets, etc.
Exemple d'apps propriétaires:
- comptabilité, Studio
Certains peuvent voir le modèle open core comme une force négative contre le produit open source. Cela a été le cas pour certains éditeurs. Mais pour Odoo ce n'est pas du tout le cas, c'est même l'inverse: si on peut développer un si bon produit open source, c'est parcequ'on est financé par les revenus d'Odoo Enterprise.
On contribue aujourd'hui 10x plus à l'open source qu'il y a 3 ans, lorsque l'on n'avait pas ce modèle open core. Simplement parcequ'on peut payer plus de développeurs qui améliorent Odoo Community.
[^] # Re: procédure de mise à jour
Posté par pinky . En réponse à la dépêche Sortie d’Odoo 14. Évalué à 10. Dernière modification le 06 octobre 2020 à 12:36.
Ce n'est pas tellement lié au modèle open core, mais au fait qu'une migration de ce genre de logiciel est extrêmement complexe: chaque société est différente, a des workflows différents, a des custos, … Ce n'est pas juste une migration de données: mais des changements de workflows, des adaptations de custo, du support/formation des utilisateurs, …
C'est tellement complexe que c'est un marché de service, et non juste un produit à acheter: Odoo a un département avec des dizaines d'employés pour assurer ce service.
Du coup, cela donne deux possibilités:
- utiliser les outils open source: gratuit mais il faut y passer du temps à tester et adapter soi même
- utiliser le service payant
Avec, ou sans modèle open core, ce serait la même chose; c'est simplement du service autour du logiciel. Pour ma part, je trouve cela fair; les utilisateurs ne sont pas "bloqués" au sens où ils peuvent le faire eux même avec les outils communautaires, mais ceux qui ont les moyens peuvent faire appels aux services de pro (soit chez un partenaire, soit chez l'éditeur; là non plus, il n'y a pas de lockin)
--> note: je suis parti pris, car fondateur de Odoo.
[^] # Re: procédure de mise à jour
Posté par pinky . En réponse à la dépêche Sortie d’Odoo 14. Évalué à 4. Dernière modification le 06 octobre 2020 à 07:26.
Les mises a jour ne sont malheureusement pas simples. Il y a deux approches:
- pour Odoo community, il y a le projet OpenUpgrade: c'est pas parfait, c'est donc pour des développeurs: https://github.com/OCA/OpenUpgrade
- pour les utilisateurs Odoo Enterprise, le service est compris dans l'abonnement. S'il veut upgrader sur cette version, il peut alors utiliser le service ici: https://upgrade.odoo.com (dans ce cas, Odoo SA s'occupe de tout: upgrade, tests, amelioration des scripts pour sa dB particulière…)
# On est demandeur de feedback sur l'éditeur de sites web
Posté par pinky . En réponse à la dépêche Sortie d’Odoo 14. Évalué à 7.
Si vous testez le nouvel éditeur de site web, les devs seraient heureux d'avoir votre feedback;
- ce que vous avez réussi à faire, ou pas
- est-ce qu'il vous manque des options dans la barre de droite?
- est-ce que le résultat est joli: idéalement, une photo d'écran, ou l'URL du site et le temps qu'il vous a fallu pour le faire
# On démarre aujourd'hui, mercredi.
Posté par pinky . En réponse à la dépêche Agenda d’Odoo Experience. Évalué à 3.
L'événement débute aujourd'hui a 2h, sur https://experience.odoo.com
[^] # Re: Feedback sur Odoo
Posté par pinky . En réponse au journal Comment quitter Odoo Enterprise ?. Évalué à 7. Dernière modification le 09 août 2020 à 00:33.
J'oubliais, on a open sourcé le module carte de fidélité depuis Odoo 13. Il est donc, depuis Odoo 13, dans Odoo Community.
Le service de migration est gratuit pour Odoo Enterprise, si le commerçant est dans une version antérieure.
Mais j'attendrais la v14 qui sort dans 7 semaines pour faire un upgrade; il y a pleins d'améliorations pour les modules qu'il utilise: POS, Website, eCommerce, achats, …
# Feedback sur Odoo
Posté par pinky . En réponse au journal Comment quitter Odoo Enterprise ?. Évalué à 10. Dernière modification le 09 août 2020 à 00:24.
Je suis le fondateur d'Odoo, voici quelques éléments si cela peut aider:
Il n'y a pas de comptabilité dans Odoo Community: ni les features, ni le certificat obligatoire en France. Il y a des extra features dans la communauté, mais rien pour une vrai compta complète, et le certificat nécessaire en France. (Je signe les certificats: vu que je peux être tenu responsable en cas d'utilisation d'un Odoo non conforme, je préfère être clair car :)
Je suis parti pris, mais pour le scope: eCommerce, POS, Compta, Stock, achats, ventes… 197€/mois ou 1900€ par an, ce n'est rien. Le prix comprend: support illimité 24/24, upgrades, hébergement haute disponibilité (5 serveurs: 3 backups dans deux data centers différents, 2 serveurs de prod réplication, emails, …).
Selon ma connaissance du marché, n'importe quelle alternative pour le même scope sera bcp plus chère, et sera nécessairement avec une solution bcp moins bien (plusieurs soft a intégrer ensembles, et pas du niveaux 'Odoo); que ce soit avec du libre, ou du proprio d'ailleurs.
[^] # Re: float vs decimal
Posté par pinky . En réponse à la dépêche « Scale‐Up! » : un jeu éducatif pour apprendre la gestion d’entreprise. Évalué à 4. Dernière modification le 24 juillet 2019 à 19:21.
Tests des champs float & monetary:
https://github.com/odoo/odoo/blob/12.0/odoo/addons/test_new_api/tests/test_new_fields.py#L430
[^] # Re: float vs decimal
Posté par pinky . En réponse à la dépêche « Scale‐Up! » : un jeu éducatif pour apprendre la gestion d’entreprise. Évalué à 5.
Ce lien concerne un module qui ne fait pas partie de Odoo, un module tiers de l'OCA. Je n'ai pas creusé plus que cela, mais probablement un bug dans leur code qui court-circuite l'ORM standard. L'ORM Odoo traite bien les décimal correctement. Voici un test fait rapidement (sur une branch master-nochange-fp, mais le comportement est le même depuis les premières versions de Odoo): http://tinyurl.com/y263r7cx
Faire cela amène les même désavantages que d'utiliser un float; si tu ne travailles pas avec la bonne précision, il faut alors quantize() manuellement à certains endroits dans le code. (e.g.lors de comparaisons, ou avant de storer, calcul de taxes, …)
Le débat revient juste à choisir quel côté du trade-off on préfaire:
- float: performance, flexibilité / facilité de code
- decimal: permettre de gérer des nombres avec plus de 16 chiffres
Odoo a prit le parti que les nombres à plus de 16 chiffres n'apparaissent pas dans les domaines concernés par les decimal (typiquement la compta). Mais, même si à l'avenir, dans un domaine fonctionnel particulier, on a vraiment besoin de gérer des très grands nombres, rien n'empêche d'utiliser un type Decimal dans le code (et les représentations DB sont Numeric); c'est juste que ce cas ne s'est jamais produit.
PS: je t'invite a chercher sur google "tryton issue quantize" pour prendre du recul --> les deux approches ont leurs inconvénients.
[^] # Re: odoo est-il encore libre ?
Posté par pinky . En réponse à la dépêche « Scale‐Up! » : un jeu éducatif pour apprendre la gestion d’entreprise. Évalué à 8. Dernière modification le 22 juillet 2019 à 17:18.
Je serais intéressé d'avoir un feedback sur vont besoins qui n'ont pas été couverts par le standard. Pouvez-vous m'envoyer une liste par email (fp AT odoo DOT com)? On va justement définir notre roadmap v14, dans qq semaines.
Voici l'explication de notre choix pour l'implémentation des floats: Odoo gère bien les chiffres comme des decimal au niveau de PostgreSQL (numeric), mais comme des floats en mémoire (ORM). C'est pour moi le meilleur compromis car:
- tout est bien stocké en decimal après chaque opération dans la DB (tronqué correctement en fonction de la devise / UoM / …). C'est pratique car un champ a bien un contexte défini (précision, rounding), alors que les variables intermédiaires dans le code n'en ont pas nécessairement.
- cela ne pose strictement aucun problème d'arrondi pour des use cases business (les float Python sont des double C --> 11 bits exposant, 52 bits valeur), le seul risque est de ne pas faire une comparaison correcte à 0, lorque vous développez un module custo.
Utiliser le type decimal en Python serait en fait beaucoup plus compliqué, principalement à cause des getcontext() -> on ne ferait que déplacer le problème (comparaison à 0) à toutes les opérations arythmétique (mise en place du bon contexte à chaque calcul, au lieu de s'appuyer sur la définition du champ lorsque l'on stocke la valeur).
Par exemple, lorsque vous faites: Prix TTC = Pric HTVA * Quantité * Discount * TVA, chacune des variables ont des précisions différentes, il faudrait alors démultiplier les appels à decimal.getcontext().prec = X. Calculer en float, et tronquer à la fin (lorsque la variable Prix TTC est ensuite écrite dans le champ amount_total pour qui une précision est définie) est à la fois plus performant, et beaucoup plus simple. On considère le risque d'erreur négligeable car il faut un montant à 1016 chiffres pour avoir un risque de un cent. (ce que probablement aucune société au monde n'a dans ses comptes, sur un seul document)
Le risque de bug par un développeur de module est pour moi beaucoup plus grand si Odoo n'utilisait que des decimals, au lieu de cette approche mixte (à cause des multiples définitions de contexte, alors qu'ici c'est délégué à la définition du champ de l'objet). Sans compter les multiples exceptions TypeError lorsque l'on multiplie un vrai float (discount/quantity) par un decimal.
[^] # Re: odoo est-il encore libre ?
Posté par pinky . En réponse à la dépêche « Scale‐Up! » : un jeu éducatif pour apprendre la gestion d’entreprise. Évalué à 10.
D'une manière générale, à chaque nouvelle version, Odoo Community reçoit énormément de nouvelles fonctions et améliorations. On garde le même ratio depuis quelques années: 80% de nos développements sont sur Odoo Community (la version open source), et 20% sont sur Odoo Enterprise (les extras features propriétaires).
Bien sûr, à chaque nouvelle version, on améliore beaucoup de features. Il y a donc des comportements qui changent, et des corner cases qui peuvent ne plus être supportés. C'est une gestion de produit normale, Odoo s'améliore très vite, cela induit beaucoup de changement. Mais notre mentalité est de rester le plus compatible possible (très peu de suppressions, même s'il peut y en avoir), et ce qui est open source reste open source.
Dans tout ls cas, il n'y a aucune volonté de diminuer la version open source par rapport à la version propriétaire. Au contraire; les revenues générés par Odoo Enterprise sont majoritairements investis pour améliorer le version community. (raison pour laquelle Odoo Community avance bcp plus vite que tous les autres acteurs libres)
Plus d'infos sur un blog publié récemment: https://www.odoo.com/blog/odoo-news-5/post/odoo-community-enterprise-532
[^] # Re: Pas réaliste
Posté par pinky . En réponse à la dépêche « Scale‐Up! » : un jeu éducatif pour apprendre la gestion d’entreprise. Évalué à 10.
Je suis parti pris car je suis co-auteur du jeu. Je suis également fondateur et CEO d'une société de 660 employés (Odoo).
Je pense au contraire que Scale-up!, représente bien les challenges d'un entrepreneur moderne. Le jeu ne couvre pas les aspects stratégiques de la gestion d'entreprise, mais plus les aspects d'execution. (Et un entrepreneur passe la majorité de son temps dans l'exécution, très peu dans les reflections stratégiques)
Scale-up! ne couvre évidemment pas toutes les fonctions d'un entrepreneur, mais les processus proposés couvrent quand même de nombreux besoins: achats, ventes, gestions de projets et services, organisation d'un entrepôt avec barcodes, fabrication, lancement d'une boutique en ligne, création d'une app sur mesure.
Nous aidons des centaines d'entreprises a améliorer leur gestion. Et, très souvent, cela passe par mettre en place des processus efficaces. C'est clé pour faciliter la croissance.
[^] # Re: BI
Posté par pinky . En réponse à la dépêche Odoo Experience, le 3 octobre 2018. Évalué à 4. Dernière modification le 17 septembre 2018 à 07:27.
Je dirais que c'est un état d'esprit que nous avons développé :
- notre priorité est de réussir le projet (dans les temps et budget), pas de satisfaire le client (en faisant tout ce qu'il veut).
- la majorité des demandes clients ne sont pas utiles: on peut faire tout aussi bien autrement. On a prit l'habitude de challenger la demande
- on sensibilise le client au coût de la dette technique en faisant payer la maintenance des le début, comprenant support illimité, correction de bogues, et migrations.
- il faut des chefs de projets qui ont une très grande connaissance du produit et du métier du client, et qui ne sont surtout pas developpeurs
Voici un blog qui explique comment limiter les développements.
[^] # Re: BI
Posté par pinky . En réponse à la dépêche Odoo Experience, le 3 octobre 2018. Évalué à 3. Dernière modification le 12 septembre 2018 à 12:09.
Nous avons déployés ~900 industries dans le manufacturing, sans développement spécifique. Je suis donc curieux de voir ce qu'il vous manque comme fonctionnalité (pour quoi avez-vous dû faire des développements spécifiques)?
Pour bien connaître la concurrence (NetSuite, Ms. Dynamics, SAP B1), je trouve qu'Odoo a beaucoup plus en standard. Très souvent, dans les appels d'offres que ous faisons, nous répondons avec un seul outil (Odoo), alors que les concurrents doivent faire des connecteurs avec différents outils car tout n'est pas de base chez eux (ex: maintenance, plm, configurateur produit, portail pour pièces détachées, workcenter control panel, reporting avancé…)
Bien sûr, Odoo n'a pas tout, mais je doute qu'il ait moins que Dynamics, Netsuite ou SAP BO.
[^] # Re: BI
Posté par pinky . En réponse à la dépêche Odoo Experience, le 3 octobre 2018. Évalué à 3. Dernière modification le 06 septembre 2018 à 23:35.
Par curiosité, que manque-t-il a v11? Light par rapport a quel logiciel?
[^] # Re: BI
Posté par pinky . En réponse à la dépêche Odoo Experience, le 3 octobre 2018. Évalué à 3.
Je ne suis pas certain de comprendre votre commentaire. Déjà en v11, Odoo a les nomenclatures multi-niveaux, les non conformités, les lots, les chutes, la consommation progressive des matières. Vous semblez dire que ce n'est pas efficace, pouvez-vous préciser?
Odoo a un moteur de rapport super puissants (cube, pivot, graphs) et la v12 apporte des dashboards ala Google Analytics. Mais Odoo n'a pas de vocation a faire du reporting sur différentes DB, comme le ferait un outil de BI.
# Vidéo d'introduction et agenda
Posté par pinky . En réponse à la dépêche Odoo Experience, le 3 octobre 2018. Évalué à 6.
Voici une vidéo d'introduction sur base des images de l'année passée. Cela donne une bonne idée de l'ambiance de l'événement.
Les premiers talks ont étés publiés, l'agenda des 150 talks sera complet avant fin de la semaine
[^] # Re: ou ça ?
Posté par pinky . En réponse à la dépêche Odoo, éditeur de logiciel de gestion libre, sort une nouvelle application Odoo Email Marketing. Évalué à 2.
Ce n'est pas un module a telecharger a part, il fait partie du repo officiel de Odoo.
# Video
Posté par pinky . En réponse à la dépêche Odoo, éditeur de logiciel de gestion libre, sort une nouvelle application Odoo Email Marketing. Évalué à 3. Dernière modification le 14 janvier 2017 à 03:41.
Voici une video pour se rendre compte de l'application.
https://youtu.be/pBX9t7L0PuA
Je pense que c'est la premiere application libre de mass mailing ayant un editeur de mails au niveau des services comme mailchimp.
[^] # Re: Odoo 10 : sortie officielle
Posté par pinky . En réponse à la dépêche Odoo Experience: lancement de Odoo 10. Évalué à 3.
Ce n'est pas la v10, mais une RC (release candidate)
[^] # Re: Il faut relativiser
Posté par pinky . En réponse à la dépêche Projet de loi de finances FR 2016 : interdiction des logiciels libres de comptabilité et de caisse. Évalué à 3.
Oui et non. La plupart des fonctionnalités v9 en compabilité sont dans Odoo Community, la version Open Source. (tout le refactoring v9 en fait, sauf les nouveaux rapports et les banques)
L'interface avec les banques est dans Odoo Enterprise. Ce sont des accords à plus de 200k€ par an pour obtenir de tels accès. Même si c'était open source, ce serait inutilisable car la seule manière de faire est de prendre un contrat pour tous les clients et de reventiler les coûts par client. Hors comme on a un coût par banque interfacée en plus du coût fixe (~0.7€), on ne peut pas mettre cela libre.
# Il faut relativiser
Posté par pinky . En réponse à la dépêche Projet de loi de finances FR 2016 : interdiction des logiciels libres de comptabilité et de caisse. Évalué à 10.
En Belgique, le gouvernement a introduit le même principe pour les restaurants, ce qu'ils appellent la "boite noire". C'est encore pire car il faut s'interfacer avec un hardware propriétaire et assez cher que chaque restaurant doit acheter (350€). Cela n'a pas empêché Odoo de se certifier, nous avons obtenu la certification il y a 3 jours.
Même si je trouve que ces projets de loi sont stupides (ceux qui veulent tricher trouveront toujours le moyen de tricher), je ne pense pas que ce soit un frein aux logiciels libres. Il y a toujours des moyens de contourner la loi.
Ce que nous avons du faire, c'est faire un fork avec une autre license, non libre. (mais qui est identique à Odoo standard) La contrainte n'est cependant pas que pour les logiciels libres, les logiciels propriétaires sont soumis aux mêmes problèmes de certifications dès qu'ils font un changement. Je pense qu'on doit même pouvoir faire sans un fork.
Bref, cela ne doit pas nous empêcher de faire des softs de comptabilité ou de gestion de caisse. Chez Odoo, on compte bien faire passer la certification française. (et je suis sûr qu'on trouvera des failles dans la loi/certification pour faire évoluer le logiciel en limitant les coûts de certifications. La loi, c'est comme les logiciels, c'est pleins de trous de sécurité)
Autre note: je vous invite à tester Odoo Comptabilité pour la France, c'est une tuerie depuis la v9. On s'interface même avec plusieurs grandes banques françaises pour automatiser la réception des extraits et paiements SEPA.
Testez si votre banque est supportée ici: https://www.odoo.com/page/accounting-features
Essayez Odoo Compta ici: https://www.odoo.com/page/accounting