Merci pour l'info pour Fedora. J'ai mis à jour le README sur github pour dire qu'il n'y avait pas besoin de paquets supplémentaires pour faire marcher l'extension LibreOffice Factur-X. Je suis content que ça ait marché du premier coup chez toi :)
J'en profite pour faire une petite demande : si vous utilisez une distribution Linux autre que Debian ou Ubuntu (ou leurs dérivés) et que vous êtes prêt à tester mon extension LibreOffice pour Factur-X, ça m'intéresse de savoir si vous avez besoin d'installer un paquet non installé par défaut pour supporter les macros Python sous LibreOffice (sur Debian/Ubuntu, il faut ajouter le paquet libreoffice-script-provider-python).
Cela me permettra de compléter les instructions d'installation actuelles où seules Ubuntu et Debian sont mentionnées.
Le jour où la fonction d'export PDF de LibreOffice supportera l'ajout de pièce jointes (ce qui n'est pas le cas actuellement, en tout cas pas sur la version de LibreOffice présente dans Ubuntu 18.04), alors on pourra se passer de ma librairie python factur-x qui post-process le PDF généré par LibreOffice pour ajouter le fichier "factur-x.xml" en pièce jointe. Développer le post-processing du PDF pour ajouter la pièce jointe en LibreOffice Basic me semble hyper-difficile.
Si un jour LibreOffice supporte nativement l'ajout de pièces jointes dans l'export PDF, ça permettrait de re-développer cette extension et de la simplifier énormément… et pourquoi pas d'abandonner le python pour LibreOffice Basic !
Je n'ai pas encore discuté de cette feature avec des développeurs LibreOffice… il faudrait d'abord que je vérifie que la feature n'est présente ni dans une version super récente ni dans le trunk.
D'ailleurs, il y a des cas où on a besoin de déposer une pièce jointe sur Chorus en plus de la facture (genre un PV de recette de travaux qui a déclenché la facture), et, dans ce cas, il faut que ce soit une pièce jointe supplémentaire dans la facture PDF. Pour l'instant, mon extension LibreOffice ne le permet pas, mais ça ne serait pas très difficile à développer (vu que ma lib python factur-x le supporte). Je le ferai si je rencontre qqun qui en a besoin…
Vous dites "de base, cela ne va pas très en profondeur". Je pense que cela fait partie de la stratégie d'Odoo : garder un système simple, et faire en sorte qu'il soit facilement extensible pour pouvoir insérer de la complexité aux endroits où c'est nécessaire (via des modules communautaires ou des modules spécifiques). C'est vrai qu'on peut parfois être énervé de ne pas trouver telle fonctionnalité particulière qui serait utile à notre activité, mais cela permet de garder un logiciel relativement simple et accessible, ce que beaucoup d'utilisateurs apprécient. C'est d'ailleurs souvent un point fort qui est cité quand on compare Odoo aux gros ERP proprios type SAP.
Par contre, je ne suis pas d'accord sur votre commentaire "On est quand même très loin de solutions propriétaires comme celles de Cegid, Divalto, Sage…", qui est objectivement faux. En tant qu'intégrateur Odoo, on est régulièrement en concurrence avec ces acteurs là, et cela ne nous fait plus peur du tout. J'ai par exemple remplacé Sage X3 (le plus gros des ERP de la gamme Sage) dans une entreprise industrielle cotée sur Euronext : Odoo (v8 au début du projet, v10 actuellement) gère les ventes, les achats, les stocks (tracabilité par lot, multi-entrepots, dates de péremption) et la comptabilité complète (oui, on peut gérer dans Odoo la comptabilité d'une société cotée en bourse). La gestion de production n'est pas faite dans Odoo, mais elle ne l'était pas non plus dans Sage X3 ; elle est gérée par une application métier développée en interne, et interfacée avec Odoo via les webservices. J'oublie de préciser qu'ils utilisent Odoo v10 Community (et de nombreux modules communautaires/OCA), donc il n'y a pas de coûts de licence.
le rythme de sortie des versions d'Odoo est très rapide (une nouvelle version par an ces dernières années)
porter les modules OCA prend du temps, surtout si on veut que le travail soit bien fait,
dans certaines versions, l'éditeur fait de très gros changements structurels (v9 par exemple) qui sont fait parfois un peu trop rapidement… ce qui n'est pas sans poser qq problèmes,
pour réussir des projets Odoo Community complexes avec un grand périmètre fonctionnel (CRM, vente, stock, production, achat et comptabilité, avec une vraie comptabilité complètement tenue dans Odoo), il faut très très bien connaître Odoo et les modules OCA.
Avec le temps, j'ai constaté qu'on avait à peine fini de porter les modules OCA sur une nouvelle version d'Odoo qu'il fallait déjà s'attaquer à les porter sur la suivante, ce qui laissait peu de temps pour améliorer les modules OCA et les enrichir au niveau des fonctionnalités.
J'ai donc adapté ma stratégie en travaillant sur une version d'Odoo sur 2. J'ai travaillé sur Odoo v8 et sur Odoo v10. Je n'ai pas travaillé sur Odoo v9 ni sur Odoo v11. Attention, je n'applique pas bêtement cette stratégie : je la combine avec une analyse fine des changements opérés dans chaque version et du risque associé à chacun de ces changements. Donc je ne peux pas dire dès à présent que je travaillerai sur la v12 ; je confirmerai ma décision lors de la présentation de la v12 par l'éditeur.
Vous pouvez regarder les 3 scripts fournis avec la lib pour avoir des exemples d'utilisation des méthodes… voir utiliser directement ces scripts. Pour l'extraction, c'est le script "facturx-pdfextractxml", cf https://github.com/akretion/factur-x/blob/master/bin/facturx-pdfextractxml L'aide de la commande montre la façon de l'utiliser, mais je vais donner un exemple ici:
facturx-pdfextractxml ~/Facture-facturx.pdf /tmp/factur-x-extracted.xml Le fichier /tmp/factur-x-extracted.xml sera créé et contient le fichier XML.
Je ne suis pas d'accord avec l'affirmation "Il n'y a plus de compta libre sur Odoo". Quand on utilise Odoo Community complétée avec les modules OCA nécessaires pour la bonne tenu d'une compta, on obtient une très bonne compta totalement opensource, y compris la partie bancaire (virements SEPA, prélèvements SEPA, import de relevés de comptes OFX/QIF/CFONB ; on a même un export de la balance dans un format accepté par les logiciels de liasse fiscale). Personnellement, je déploie Odoo v10 Community (+ modules OCA évidemment) avec la comptabilité en production chez la quasi-totalité de mes clients (à l'exception de qq clients où la comptabilité est tenue dans le logiciel de l'expert comptable). Certes on pourrait dire "oui mais on ne peut pas tenir sa compta uniquement avec Odoo Community… sans le compléter avec des modules OCA, donc Odoo Community seul n'est plus suffisant pour tenir sa compta". C'est vrai… mais c'était déjà comme ça sur les versions antérieurs d'Odoo (à un moindre degré), donc rien de fondamentalement nouveau sous le soleil…
Je suis désolé, je ne comprends toujours pas votre critique d'origine.
Vous pouvez déposer des factures sous forme de simple fichier XML sur Chorus, et on vous laisse le choix entre UBL et CII, donc vous pouvez choisir celui que vous préférez (je crois comprendre que vous préférez UBL !). Dans ce cas, il n'y a pas du tout besoin de PDF, donc c'est encore plus simple.
Effectivement, le tableau récapitulatif des balises XML est fourni sous forme de fichier XLSX… les libristes comme nous auraient préféré un format non Microsoft, c'est sûr !
Toutes les normes officielles de l'AFNOR sont payantes, sauf celles qui sont rendues obligatoires par la loi, qui doivent alors être diffusées gratuitement. Pour l'instant, la norme sémantique européenne EN 16931 n'est pas rendue obligatoire par la loi, donc la norme est malheureusement payante (190,41 € quand on sélectionne "1 utilisateur" au lieu des "3 utilisateurs" par défaut). Le FNFE aurait préféré que cela soit gratuit, mais ce n'est pas eux qui décident. Par contre, on peut implémenter Factur-X sans acheter la norme sémantique EN 16931 ; les documents fournis avec Factur-X (tous gratuits) sont suffisants. Et, si on veut implémenter que le UBL XML ou CII XML pour Chorus, la doc de Chorus (gratuite) est suffisante. Personnellement, je n'ai pas acheté la norme EN 16931, car je n'en ai pas ressenti le besoin pour le moment.
Par contre, le truc que je trouve dommage, c'est d'avoir besoin d'un certificat RGS 1* pour se connecter à l'API Chorus. J'ai acheté le mien l'année dernière (certificat "Serveur Client Certigna RGS 1*" acheté sur TBS Internet) et il m'a coûté 240 € HT pour 1 an… et, d'après ce que je vois, le prix est maintenant de 285 € / an ! 19% d'inflation ! Et il y a tellement de formats de certificat différents pour l'administration qu'on s'y perd… ce tableau intitulé "RGS : Quel certificat pour quelle télé-procédure ?" en est le parfait exemple. Je trouve que tous ces certificats demandés pour des procédures administratives devraient être fournis gratuitement par le tribunal de commerce. Cela éviterai ce business artificiel et non productif de vente de certificats…
Effectivement, quand on pense que tout ce travail sur le support des commandes/factures électroniques dans Odoo est parti au départ d'une idée d'un de mes associés qui voulait gagner un peu de temps pour saisir ses billets Capitaine Train dans sa comptabilité et qui avait codé en Septembre 2015 un petit script pour lire les reçus PDF de Capitaine Train… que de chemin parcouru ! Je suis content que ce travail vous plaise.
Mais le vrai gain concret pour nous sera quand on commencera à recevoir des factures d'électricité/gaz/téléphone/Internet/hébergement en Factur-X. Certains membres du FNFE très gros émetteurs de factures ont dit qu'ils prévoyaient de commencer à diffuser leurs factures au format Factur-X fin 2018/début 2019… encore un peu de patience ! Mais je pense qu'on pourrait commencer dès maintenant à interpeller certains opérateurs/hébergeurs sur ce sujet… la somme du temps qui pourrait être gagné par leurs clients pour la saisie de leurs factures chaque mois en compta est énorme !
Je ne comprends pas votre critique sur "notre élite informatique nationale". Au niveau des standards pour décrire une facture en XML, il a toujours existé 2 grands standards internationaux concurrents: UBL (écrit par l'OASIS et devenu ensuite une norme ISO) et CII (écrit par UN/CEFACT, qui est un organisme de normalisation des nations unies pour la standardisation dans le commerce et qui est l'auteur des normes EDIFACT… donc un vrai poids lourd dans ce domaine). ZUGFeRD avait choisi CII et non UBL pour le fichier XML embarqué dans le PDF, et donc Factur-X (qui s'appelle aussi "ZUGFeRD 2.0") utilise logiquement CII. Donc, dans les faits, rien n'a été inventé par notre "élite informatique nationale".
Si j'avais su… ! Effectivement, Evince sait lire les fichiers embarqués : dans la barre latérale, il faut sélectionner "Pièces jointes" dans la liste déroulante (qui affiche "Vignettes" par défaut). En fait, je n'avais même pas vu qu'on pouvait sélectionner autre chose que "Vignettes" :(
Donc les lecteurs PDF par défaut de Gnome et KDE savent lire les pièces jointes des PDFs, c'est super !
D'ailleurs, il faudrait se bouger pour implémenter la possibilité de signer un PDF en utilisant une lib Python libre. A ma connaissance, aucune lib Python libre ne propose cette fonctionnalité. Pour l'instant, le module Odoo dispo dans l'OCA qui permet de signer les PDFs (report_qweb_signer) utilise une lib Java: https://github.com/OCA/reporting-engine/tree/8.0/report_qweb_signer Il existe une lib Python proprio qui signe des PDFs, disponible ici : http://www.kryptokoder.com/index.html
Merci pour l'info ! C'est une bonne nouvelle de savoir qu'il existe un lecteur PDF libre capable de lister les fichiers intégrés (comme je ne suis pas sous KDE, je ne l'avais pas testé). Est-ce que Okular sait aussi vérifier les signatures des PDFs ?
Le développement des modules de gestion des dons (ainsi que les modules de gestion des messes et des séjours) a été un travail rémunéré, dans le cadre du projet de déploiement d'Odoo à l'abbaye. J'ai fait en plus de nombreuses améliorations bénévolement, notamment le portage en nouvelle API, les tests automatiques YAML et la conformité aux standards de code d'OCA.
Pour info, un projet de basculement à Odoo de cette envergure, si on compte les développements génériques, les développements spécifiques, le paramétrage, l'accompagnement/formation, les bug fix, le portage en v8 de nombreux modules etc… c'est environ 16 semaines-homme de travail intensif pour un développeur Odoo expérimenté. Ce temps n'inclue pas le développement des scripts de migration des données, car cette partie du travail a été entièrement réalisé par les moines. Le projet a démarré en Mars 2014 pour un basculement en prod le 1er Janvier 2015.
Effectivement, le rendu osm-fr est vraiment très bien. J'utilise maintenant tile.openstreetmap.fr par défaut en remplacement d'openstreetmap.org. Il manque seulement un truc dans le rendu "osm-fr" : les fontaines d'eau (amenity=drinking_water). Elles n'apparaissent pas, même au niveau de zoom maxi.
D'après mes lectures, Marble a l'air effectivement d'être le logiciel le plus adapté pour accéder à OSM en offline depuis un PC Linux. Pour ceux qui utilisent Ubuntu, le paquet "marble" a une dépendance sur "kde-runtime", ce qui n'est pas complètement innocent. Il y a d'ailleurs un bug ouvert sur Launchpad pour réclamer un paquet "marble-qt" (cf https://bugs.launchpad.net/ubuntu/+bug/781644), qui aurait une dépendance uniquement sur la lib Qt et pas sur KDE. Ce paquet "marble-qt" existe dans un repo non officiel mais pas pour Ubuntu 13.04 : http://www.getdeb.net/software/Marble%20QT
Je viens de découvrir dans le "Résumés des activités récentes d'OSM" #16, qu'il existe maintenant une carte papier Michelin de Clermont-Ferrand et de ses environs basée sur OSM ! Plus de détails dans cet article très intéressant intitulé OSM met la gomme, qui précise que Michelin a fait des contributions à la carte OSM à l'occasion de la réalisation de cette carte papier.
Les deux premiers connecteurs sont développés et maintenus par Akretion (ma société) et Camptocamp ; les deux derniers sont développés par Akretion. Avec tous ces connecteurs, OpenERP est à mon avis l'ERP OpenSource le plus "prêt à l'utilisation" pour les e-commerçants !
SAP ne fait évidemment pas 10 672 milliards d'euros de chiffre d'affaire en 2009, mais 10 672 millions d'euros, soit 10,6 milliards, ce qui est déjà énorme.
Effectivement, j'aborde surtout les aspects techniques et fonctionnels, parce qu'ils sont les seuls communs à toutes les sociétés. Pour les aspects de gestion de projet et d'organisation, ça varie beaucoup d'une société à l'autre et on ne peut pas faire de retour d'expérience général.
Combien de temps ça prend à déployer ?
En moyenne, pour un projet avec des développements spécifiques à réaliser et des reprises de données : 6 mois.
Mais pour un projet sans reprise de donnée (autre qu'une balance comptable au premier jour de l'exercice) et sans développement spécifique (par exemple, une boutique en ligne qui va bénéficier de tous les modules matures qu'on a développé sur les connecteurs Magento, Amazon, eBay et bientôt PrestaShop et qui n'a pas de besoins "supplémentaires" dans un premier temps), cela peut être beaucoup plus rapide, genre 1 mois.
Comment se passent les récupérations de donnés ?
Quand les anciennes données sont mal structurées dans des bases sur lesquelles le client ne connaît même pas le mot de passe (voir n'y a pas accès car il avait une offre de SaaS propriétaire et l'accès à la base de donnée lui a été refusé) : pas très bien.
Quand les anciennes données sont bien structurées dans des bases propres : ça se fait bien, même si ce n'est pas la partie la plus "fun" du métier.
Quelles sont les résistances internes ?
Dans les petites boites avec un seul niveau de hiérarchie : il n'y en a généralement pas.
Dans les PME de plusieurs dizaines de personnes avec des chefs de service qui ne sont pas d'accord entre eux, ça peut être plus difficile. Si le chef de projet OpenERP côté client n'a pas de pouvoir dans sa boite, c'est un vrai frein.
Dans la partie "La comptabilité avec OpenERP", je parle spécifiquement de l'acceptation de la comptabilité d'OpenERP par les comptables.
Comment le produit résiste à l'épreuve des ans ?
En terme de croissance de la base de donnée : aucun pb. Postgres rulèz.
Il y a la problématique des migrations d'une version à l'autre, qui n'est pas facile et que je n'aborde pas pour le moment dans le document. Ca serait bien d'en parler, il y a pas mal de choses à dire sur le sujet.
Faut-il intervenir souvent chez le client ?
Oui, on intervient souvent (à distance). Comme je l'ai montré, OpenERP a pas mal de bugs, et, même si la plupart du temps ils ne sont pas trop durs à corriger, il faut quand même prendre le temps de le diagnostiquer, le reproduire, le corriger, tester le patch, le déployer et le remonter à l'éditeur. On a aussi beaucoup de questions "comment je fais telle chose dans l'ERP ?" ou "j'ai fait telle bêtise, comme on répare/revient en arrière ?". Après, ce n'est pas non plus anormal : on a installé le logiciel qui est au centre de l'informatique de gestion de la société, c'est une pièce maîtresse de son système d'information, c'est logique qu'on soit plus sollicité qu'un installateur d'IPBX ou de VPNs.
Vous dites :
> Mais en fait ce document est une analyse technique d'OpenERP.
> C'est bien, mais ça ne donne aucune idée de l'intérêt du logiciel pour une entreprise. Qu'il soit bien ou pas techniquement n'est qu'un point relativement mineur.
Tout d'abord, le document ne parle pas que de la technique, mais aussi des aspects fonctionnels, qui sont clé dans le choix d'un ERP. A mon sens, ces deux critères sont les plus importants pour choisir le logiciel de gestion de votre entreprise (en plus de l'aspect libre/opensource et des critères économiques). Le critère technique est particulièrement important pour les sociétés qui vont faire des développements spécifiques importants sur leur ERP. Quand une boite investi des dizaines ou des centaines de milliers d'euros en développements spécifiques sur son ERP, ça serait bien qu'elle s'intéresse à la technologie dans laquelle elle investi !
Effectivement, Jitsi supporte le partage d'écran (quand j'avais essayé sous Linux, ça ne marchait pas avec openjdk mais seulement avec le jdk d'Oracle). Moi, je suis toujours à la recherche d'un autre client Jabber libre qui supporte le partage d'écran… Jisti c'est bien, mais moi j'ai un laptop seulement 2 Go de RAM non extensible, donc ça le fait pas :-(
Vous avez bien bossé les gars, OpenERP 6.1 est vraiment une grande release ! En plus, les perfs de l'interface Web ont été grandement améliorées, cf mon bench
Il faut continuer le travail sur la revue des merge proposals de la communauté ; vous en avez accepté beaucoup, c'est super, mais il y en a encore un certain nombre en attente de review. Si on continue comme ça sur OpenERP avec des fonctionnalités innovantes + du clean-up de code + des review sérieuses des merge proposals de la communauté, alors je pense qu'OpenERP est promis à un bel avenir.
[^] # Re: Procédure d'install pour distro Linux autre que Ubuntu/Debian
Posté par Alexis de Lattre (site web personnel) . En réponse à la dépêche Extension LibreOffice pour générer des factures Factur‑X. Évalué à 2.
Merci d'avoir testé sous Mageia ; j'ai mis à jour la section installation de la doc.
[^] # Re: Procédure d'install pour distro Linux autre que Ubuntu/Debian
Posté par Alexis de Lattre (site web personnel) . En réponse à la dépêche Extension LibreOffice pour générer des factures Factur‑X. Évalué à 4.
Merci pour l'info pour Fedora. J'ai mis à jour le README sur github pour dire qu'il n'y avait pas besoin de paquets supplémentaires pour faire marcher l'extension LibreOffice Factur-X. Je suis content que ça ait marché du premier coup chez toi :)
# Procédure d'install pour distro Linux autre que Ubuntu/Debian
Posté par Alexis de Lattre (site web personnel) . En réponse à la dépêche Extension LibreOffice pour générer des factures Factur‑X. Évalué à 5.
J'en profite pour faire une petite demande : si vous utilisez une distribution Linux autre que Debian ou Ubuntu (ou leurs dérivés) et que vous êtes prêt à tester mon extension LibreOffice pour Factur-X, ça m'intéresse de savoir si vous avez besoin d'installer un paquet non installé par défaut pour supporter les macros Python sous LibreOffice (sur Debian/Ubuntu, il faut ajouter le paquet libreoffice-script-provider-python).
Cela me permettra de compléter les instructions d'installation actuelles où seules Ubuntu et Debian sont mentionnées.
[^] # Re: Ça a l'air super
Posté par Alexis de Lattre (site web personnel) . En réponse à la dépêche Extension LibreOffice pour générer des factures Factur‑X. Évalué à 8.
Le jour où la fonction d'export PDF de LibreOffice supportera l'ajout de pièce jointes (ce qui n'est pas le cas actuellement, en tout cas pas sur la version de LibreOffice présente dans Ubuntu 18.04), alors on pourra se passer de ma librairie python factur-x qui post-process le PDF généré par LibreOffice pour ajouter le fichier "factur-x.xml" en pièce jointe. Développer le post-processing du PDF pour ajouter la pièce jointe en LibreOffice Basic me semble hyper-difficile.
Si un jour LibreOffice supporte nativement l'ajout de pièces jointes dans l'export PDF, ça permettrait de re-développer cette extension et de la simplifier énormément… et pourquoi pas d'abandonner le python pour LibreOffice Basic !
Je n'ai pas encore discuté de cette feature avec des développeurs LibreOffice… il faudrait d'abord que je vérifie que la feature n'est présente ni dans une version super récente ni dans le trunk.
D'ailleurs, il y a des cas où on a besoin de déposer une pièce jointe sur Chorus en plus de la facture (genre un PV de recette de travaux qui a déclenché la facture), et, dans ce cas, il faut que ce soit une pièce jointe supplémentaire dans la facture PDF. Pour l'instant, mon extension LibreOffice ne le permet pas, mais ça ne serait pas très difficile à développer (vu que ma lib python factur-x le supporte). Je le ferai si je rencontre qqun qui en a besoin…
[^] # Re: Passer sur Odoo pour une petite compta libérale
Posté par Alexis de Lattre (site web personnel) . En réponse à la dépêche Odoo génère la première facture Factur-X déposée sur Chorus Pro. Évalué à 3.
Libre à vous de faire le rabat-joie…
Vous dites "de base, cela ne va pas très en profondeur". Je pense que cela fait partie de la stratégie d'Odoo : garder un système simple, et faire en sorte qu'il soit facilement extensible pour pouvoir insérer de la complexité aux endroits où c'est nécessaire (via des modules communautaires ou des modules spécifiques). C'est vrai qu'on peut parfois être énervé de ne pas trouver telle fonctionnalité particulière qui serait utile à notre activité, mais cela permet de garder un logiciel relativement simple et accessible, ce que beaucoup d'utilisateurs apprécient. C'est d'ailleurs souvent un point fort qui est cité quand on compare Odoo aux gros ERP proprios type SAP.
Par contre, je ne suis pas d'accord sur votre commentaire "On est quand même très loin de solutions propriétaires comme celles de Cegid, Divalto, Sage…", qui est objectivement faux. En tant qu'intégrateur Odoo, on est régulièrement en concurrence avec ces acteurs là, et cela ne nous fait plus peur du tout. J'ai par exemple remplacé Sage X3 (le plus gros des ERP de la gamme Sage) dans une entreprise industrielle cotée sur Euronext : Odoo (v8 au début du projet, v10 actuellement) gère les ventes, les achats, les stocks (tracabilité par lot, multi-entrepots, dates de péremption) et la comptabilité complète (oui, on peut gérer dans Odoo la comptabilité d'une société cotée en bourse). La gestion de production n'est pas faite dans Odoo, mais elle ne l'était pas non plus dans Sage X3 ; elle est gérée par une application métier développée en interne, et interfacée avec Odoo via les webservices. J'oublie de préciser qu'ils utilisent Odoo v10 Community (et de nombreux modules communautaires/OCA), donc il n'y a pas de coûts de licence.
[^] # Re: Passer sur Odoo pour une petite compta libérale
Posté par Alexis de Lattre (site web personnel) . En réponse à la dépêche Odoo génère la première facture Factur-X déposée sur Chorus Pro. Évalué à 4.
Bonne question ! Je pars d'un constat :
Avec le temps, j'ai constaté qu'on avait à peine fini de porter les modules OCA sur une nouvelle version d'Odoo qu'il fallait déjà s'attaquer à les porter sur la suivante, ce qui laissait peu de temps pour améliorer les modules OCA et les enrichir au niveau des fonctionnalités.
J'ai donc adapté ma stratégie en travaillant sur une version d'Odoo sur 2. J'ai travaillé sur Odoo v8 et sur Odoo v10. Je n'ai pas travaillé sur Odoo v9 ni sur Odoo v11. Attention, je n'applique pas bêtement cette stratégie : je la combine avec une analyse fine des changements opérés dans chaque version et du risque associé à chacun de ces changements. Donc je ne peux pas dire dès à présent que je travaillerai sur la v12 ; je confirmerai ma décision lors de la présentation de la v12 par l'éditeur.
[^] # Re: Bibliothèque factur-X
Posté par Alexis de Lattre (site web personnel) . En réponse à la dépêche Odoo génère la première facture Factur-X déposée sur Chorus Pro. Évalué à 3.
Vous pouvez regarder les 3 scripts fournis avec la lib pour avoir des exemples d'utilisation des méthodes… voir utiliser directement ces scripts. Pour l'extraction, c'est le script "facturx-pdfextractxml", cf https://github.com/akretion/factur-x/blob/master/bin/facturx-pdfextractxml L'aide de la commande montre la façon de l'utiliser, mais je vais donner un exemple ici:
facturx-pdfextractxml ~/Facture-facturx.pdf /tmp/factur-x-extracted.xml
[^] # Re: Passer sur Odoo pour une petite compta libérale
Posté par Alexis de Lattre (site web personnel) . En réponse à la dépêche Odoo génère la première facture Factur-X déposée sur Chorus Pro. Évalué à 6.
Je ne suis pas d'accord avec l'affirmation "Il n'y a plus de compta libre sur Odoo". Quand on utilise Odoo Community complétée avec les modules OCA nécessaires pour la bonne tenu d'une compta, on obtient une très bonne compta totalement opensource, y compris la partie bancaire (virements SEPA, prélèvements SEPA, import de relevés de comptes OFX/QIF/CFONB ; on a même un export de la balance dans un format accepté par les logiciels de liasse fiscale). Personnellement, je déploie Odoo v10 Community (+ modules OCA évidemment) avec la comptabilité en production chez la quasi-totalité de mes clients (à l'exception de qq clients où la comptabilité est tenue dans le logiciel de l'expert comptable). Certes on pourrait dire "oui mais on ne peut pas tenir sa compta uniquement avec Odoo Community… sans le compléter avec des modules OCA, donc Odoo Community seul n'est plus suffisant pour tenir sa compta". C'est vrai… mais c'était déjà comme ça sur les versions antérieurs d'Odoo (à un moindre degré), donc rien de fondamentalement nouveau sous le soleil…
[^] # Re: OpenConcerto
Posté par Alexis de Lattre (site web personnel) . En réponse à la dépêche Odoo génère la première facture Factur-X déposée sur Chorus Pro. Évalué à 10.
Je suis désolé, je ne comprends toujours pas votre critique d'origine.
Vous pouvez déposer des factures sous forme de simple fichier XML sur Chorus, et on vous laisse le choix entre UBL et CII, donc vous pouvez choisir celui que vous préférez (je crois comprendre que vous préférez UBL !). Dans ce cas, il n'y a pas du tout besoin de PDF, donc c'est encore plus simple.
Effectivement, le tableau récapitulatif des balises XML est fourni sous forme de fichier XLSX… les libristes comme nous auraient préféré un format non Microsoft, c'est sûr !
Toutes les normes officielles de l'AFNOR sont payantes, sauf celles qui sont rendues obligatoires par la loi, qui doivent alors être diffusées gratuitement. Pour l'instant, la norme sémantique européenne EN 16931 n'est pas rendue obligatoire par la loi, donc la norme est malheureusement payante (190,41 € quand on sélectionne "1 utilisateur" au lieu des "3 utilisateurs" par défaut). Le FNFE aurait préféré que cela soit gratuit, mais ce n'est pas eux qui décident. Par contre, on peut implémenter Factur-X sans acheter la norme sémantique EN 16931 ; les documents fournis avec Factur-X (tous gratuits) sont suffisants. Et, si on veut implémenter que le UBL XML ou CII XML pour Chorus, la doc de Chorus (gratuite) est suffisante. Personnellement, je n'ai pas acheté la norme EN 16931, car je n'en ai pas ressenti le besoin pour le moment.
Par contre, le truc que je trouve dommage, c'est d'avoir besoin d'un certificat RGS 1* pour se connecter à l'API Chorus. J'ai acheté le mien l'année dernière (certificat "Serveur Client Certigna RGS 1*" acheté sur TBS Internet) et il m'a coûté 240 € HT pour 1 an… et, d'après ce que je vois, le prix est maintenant de 285 € / an ! 19% d'inflation ! Et il y a tellement de formats de certificat différents pour l'administration qu'on s'y perd… ce tableau intitulé "RGS : Quel certificat pour quelle télé-procédure ?" en est le parfait exemple. Je trouve que tous ces certificats demandés pour des procédures administratives devraient être fournis gratuitement par le tribunal de commerce. Cela éviterai ce business artificiel et non productif de vente de certificats…
[^] # Re: Typo
Posté par Alexis de Lattre (site web personnel) . En réponse à la dépêche Odoo génère la première facture Factur-X déposée sur Chorus Pro. Évalué à 6.
Merci :)
Effectivement, quand on pense que tout ce travail sur le support des commandes/factures électroniques dans Odoo est parti au départ d'une idée d'un de mes associés qui voulait gagner un peu de temps pour saisir ses billets Capitaine Train dans sa comptabilité et qui avait codé en Septembre 2015 un petit script pour lire les reçus PDF de Capitaine Train… que de chemin parcouru ! Je suis content que ce travail vous plaise.
Mais le vrai gain concret pour nous sera quand on commencera à recevoir des factures d'électricité/gaz/téléphone/Internet/hébergement en Factur-X. Certains membres du FNFE très gros émetteurs de factures ont dit qu'ils prévoyaient de commencer à diffuser leurs factures au format Factur-X fin 2018/début 2019… encore un peu de patience ! Mais je pense qu'on pourrait commencer dès maintenant à interpeller certains opérateurs/hébergeurs sur ce sujet… la somme du temps qui pourrait être gagné par leurs clients pour la saisie de leurs factures chaque mois en compta est énorme !
[^] # Re: OpenConcerto
Posté par Alexis de Lattre (site web personnel) . En réponse à la dépêche Odoo génère la première facture Factur-X déposée sur Chorus Pro. Évalué à 6.
Je ne comprends pas votre critique sur "notre élite informatique nationale". Au niveau des standards pour décrire une facture en XML, il a toujours existé 2 grands standards internationaux concurrents: UBL (écrit par l'OASIS et devenu ensuite une norme ISO) et CII (écrit par UN/CEFACT, qui est un organisme de normalisation des nations unies pour la standardisation dans le commerce et qui est l'auteur des normes EDIFACT… donc un vrai poids lourd dans ce domaine). ZUGFeRD avait choisi CII et non UBL pour le fichier XML embarqué dans le PDF, et donc Factur-X (qui s'appelle aussi "ZUGFeRD 2.0") utilise logiquement CII. Donc, dans les faits, rien n'a été inventé par notre "élite informatique nationale".
[^] # Re: Typo
Posté par Alexis de Lattre (site web personnel) . En réponse à la dépêche Odoo génère la première facture Factur-X déposée sur Chorus Pro. Évalué à 3.
Je confirme ! Le lien est bon ; c'est le texte du lien qui est mauvais.
[^] # Re: Lecteurs PDF capables de voir les documents intégrés
Posté par Alexis de Lattre (site web personnel) . En réponse à la dépêche Premier module libre de facturation électronique pour Odoo. Évalué à 2.
Si j'avais su… ! Effectivement, Evince sait lire les fichiers embarqués : dans la barre latérale, il faut sélectionner "Pièces jointes" dans la liste déroulante (qui affiche "Vignettes" par défaut). En fait, je n'avais même pas vu qu'on pouvait sélectionner autre chose que "Vignettes" :(
Donc les lecteurs PDF par défaut de Gnome et KDE savent lire les pièces jointes des PDFs, c'est super !
[^] # Re: Lecteurs PDF capables de voir les documents intégrés
Posté par Alexis de Lattre (site web personnel) . En réponse à la dépêche Premier module libre de facturation électronique pour Odoo. Évalué à 4.
D'ailleurs, il faudrait se bouger pour implémenter la possibilité de signer un PDF en utilisant une lib Python libre. A ma connaissance, aucune lib Python libre ne propose cette fonctionnalité. Pour l'instant, le module Odoo dispo dans l'OCA qui permet de signer les PDFs (report_qweb_signer) utilise une lib Java: https://github.com/OCA/reporting-engine/tree/8.0/report_qweb_signer Il existe une lib Python proprio qui signe des PDFs, disponible ici : http://www.kryptokoder.com/index.html
De plus en plus, il est demandé à ce que les factures PDF soit signées pour qu'elles aient une valeur probante, cf par exemple https://chorus-factures.budget.gouv.fr/accueil/aidePdfSigne
et c'est même écrit dans la loi depuis 2013, cf ces explications : http://www.journaldunet.com/management/expert/56880/vos-factures-sont-elles-conformes-aux-nouvelles-regles-applicables.shtml
En résumé, il est encore possible d'envoyer des PDFs non signés, mais il faut alors une "piste d'audit documentée" pour pouvoir rattacher la facture à un contrat/BL et fournir tous les autres documents relatifs à la vente. Alors que, si la facture est un PDF signé, il n'y a besoin de rien d'autre que la facture, donc c'est plus simple.
Et il faudrait aussi un lecteur PDF libre capable de vérifier les signatures…
[^] # Re: Lecteurs PDF capables de voir les documents intégrés
Posté par Alexis de Lattre (site web personnel) . En réponse à la dépêche Premier module libre de facturation électronique pour Odoo. Évalué à 3.
Tu peux trouver une douzaine de factures ZUGFeRD de test ici : https://github.com/akretion/account-invoicing/tree/8.0-add-pdf-invoice-import/account_invoice_import_zugferd/test/invoices (c'est le jeu d'exemple fourni par la FeRD).
[^] # Re: Lecteurs PDF capables de voir les documents intégrés
Posté par Alexis de Lattre (site web personnel) . En réponse à la dépêche Premier module libre de facturation électronique pour Odoo. Évalué à 3.
Merci pour l'info ! C'est une bonne nouvelle de savoir qu'il existe un lecteur PDF libre capable de lister les fichiers intégrés (comme je ne suis pas sous KDE, je ne l'avais pas testé). Est-ce que Okular sait aussi vérifier les signatures des PDFs ?
[^] # Re: Moines développeurs ?
Posté par Alexis de Lattre (site web personnel) . En réponse à la dépêche Communauté Odoo : L'abbaye du Barroux développe les modules de gestion des dons. Évalué à 10.
Le développement des modules de gestion des dons (ainsi que les modules de gestion des messes et des séjours) a été un travail rémunéré, dans le cadre du projet de déploiement d'Odoo à l'abbaye. J'ai fait en plus de nombreuses améliorations bénévolement, notamment le portage en nouvelle API, les tests automatiques YAML et la conformité aux standards de code d'OCA.
Pour info, un projet de basculement à Odoo de cette envergure, si on compte les développements génériques, les développements spécifiques, le paramétrage, l'accompagnement/formation, les bug fix, le portage en v8 de nombreux modules etc… c'est environ 16 semaines-homme de travail intensif pour un développeur Odoo expérimenté. Ce temps n'inclue pas le développement des scripts de migration des données, car cette partie du travail a été entièrement réalisé par les moines. Le projet a démarré en Mars 2014 pour un basculement en prod le 1er Janvier 2015.
Alexis
[^] # Re: Moteur de rendu
Posté par Alexis de Lattre (site web personnel) . En réponse au journal OpenStreetMap : pourquoi vous devriez l'utiliser. Évalué à 1.
Effectivement, le rendu osm-fr est vraiment très bien. J'utilise maintenant tile.openstreetmap.fr par défaut en remplacement d'openstreetmap.org. Il manque seulement un truc dans le rendu "osm-fr" : les fontaines d'eau (amenity=drinking_water). Elles n'apparaissent pas, même au niveau de zoom maxi.
[^] # Re: Appli hors-ligne sous linux?
Posté par Alexis de Lattre (site web personnel) . En réponse à la dépêche OpenStreetMap : pourquoi vous devriez l'utiliser. Évalué à 5.
D'après mes lectures, Marble a l'air effectivement d'être le logiciel le plus adapté pour accéder à OSM en offline depuis un PC Linux. Pour ceux qui utilisent Ubuntu, le paquet "marble" a une dépendance sur "kde-runtime", ce qui n'est pas complètement innocent. Il y a d'ailleurs un bug ouvert sur Launchpad pour réclamer un paquet "marble-qt" (cf https://bugs.launchpad.net/ubuntu/+bug/781644), qui aurait une dépendance uniquement sur la lib Qt et pas sur KDE. Ce paquet "marble-qt" existe dans un repo non officiel mais pas pour Ubuntu 13.04 : http://www.getdeb.net/software/Marble%20QT
[^] # Re: quelques liens pour commencer
Posté par Alexis de Lattre (site web personnel) . En réponse au journal OpenStreetMap : pourquoi vous devriez l'utiliser. Évalué à 10.
Je viens de découvrir dans le "Résumés des activités récentes d'OSM" #16, qu'il existe maintenant une carte papier Michelin de Clermont-Ferrand et de ses environs basée sur OSM ! Plus de détails dans cet article très intéressant intitulé OSM met la gomme, qui précise que Michelin a fait des contributions à la carte OSM à l'occasion de la réalisation de cette carte papier.
[^] # Re: Et la vente en ligne ?
Posté par Alexis de Lattre (site web personnel) . En réponse à la dépêche OpenERP 7 vient de sortir. Évalué à 1.
Et en plus des modules de connexion à Magento et PrestaShop, nous avons aussi développé des modules de connexion à Amazon et Ebay :
Les deux premiers connecteurs sont développés et maintenus par Akretion (ma société) et Camptocamp ; les deux derniers sont développés par Akretion. Avec tous ces connecteurs, OpenERP est à mon avis l'ERP OpenSource le plus "prêt à l'utilisation" pour les e-commerçants !
[^] # Re: Volumétrie
Posté par Alexis de Lattre (site web personnel) . En réponse à la dépêche OpenERP 7 bêta : la gestion d'entreprise simplifiée. Évalué à 2.
SAP ne fait évidemment pas 10 672 milliards d'euros de chiffre d'affaire en 2009, mais 10 672 millions d'euros, soit 10,6 milliards, ce qui est déjà énorme.
Selon cet article http://www.zdnet.fr/actualites/resultats-sap-boucle-une-bonne-annee-2011-39767521.htm le chiffre d'affaire de SAP en 2011 était de 14,2 milliards.
[^] # Re: Rabat joie
Posté par Alexis de Lattre (site web personnel) . En réponse à la dépêche Expérience de déploiements d’OpenERP dans des entreprises françaises. Évalué à 9.
Effectivement, j'aborde surtout les aspects techniques et fonctionnels, parce qu'ils sont les seuls communs à toutes les sociétés. Pour les aspects de gestion de projet et d'organisation, ça varie beaucoup d'une société à l'autre et on ne peut pas faire de retour d'expérience général.
Combien de temps ça prend à déployer ?
En moyenne, pour un projet avec des développements spécifiques à réaliser et des reprises de données : 6 mois.
Mais pour un projet sans reprise de donnée (autre qu'une balance comptable au premier jour de l'exercice) et sans développement spécifique (par exemple, une boutique en ligne qui va bénéficier de tous les modules matures qu'on a développé sur les connecteurs Magento, Amazon, eBay et bientôt PrestaShop et qui n'a pas de besoins "supplémentaires" dans un premier temps), cela peut être beaucoup plus rapide, genre 1 mois.
Comment se passent les récupérations de donnés ?
Quand les anciennes données sont mal structurées dans des bases sur lesquelles le client ne connaît même pas le mot de passe (voir n'y a pas accès car il avait une offre de SaaS propriétaire et l'accès à la base de donnée lui a été refusé) : pas très bien.
Quand les anciennes données sont bien structurées dans des bases propres : ça se fait bien, même si ce n'est pas la partie la plus "fun" du métier.
Quelles sont les résistances internes ?
Dans les petites boites avec un seul niveau de hiérarchie : il n'y en a généralement pas.
Dans les PME de plusieurs dizaines de personnes avec des chefs de service qui ne sont pas d'accord entre eux, ça peut être plus difficile. Si le chef de projet OpenERP côté client n'a pas de pouvoir dans sa boite, c'est un vrai frein.
Dans la partie "La comptabilité avec OpenERP", je parle spécifiquement de l'acceptation de la comptabilité d'OpenERP par les comptables.
Comment le produit résiste à l'épreuve des ans ?
En terme de croissance de la base de donnée : aucun pb. Postgres rulèz.
Il y a la problématique des migrations d'une version à l'autre, qui n'est pas facile et que je n'aborde pas pour le moment dans le document. Ca serait bien d'en parler, il y a pas mal de choses à dire sur le sujet.
Faut-il intervenir souvent chez le client ?
Oui, on intervient souvent (à distance). Comme je l'ai montré, OpenERP a pas mal de bugs, et, même si la plupart du temps ils ne sont pas trop durs à corriger, il faut quand même prendre le temps de le diagnostiquer, le reproduire, le corriger, tester le patch, le déployer et le remonter à l'éditeur. On a aussi beaucoup de questions "comment je fais telle chose dans l'ERP ?" ou "j'ai fait telle bêtise, comme on répare/revient en arrière ?". Après, ce n'est pas non plus anormal : on a installé le logiciel qui est au centre de l'informatique de gestion de la société, c'est une pièce maîtresse de son système d'information, c'est logique qu'on soit plus sollicité qu'un installateur d'IPBX ou de VPNs.
Vous dites :
> Mais en fait ce document est une analyse technique d'OpenERP.
> C'est bien, mais ça ne donne aucune idée de l'intérêt du logiciel pour une entreprise. Qu'il soit bien ou pas techniquement n'est qu'un point relativement mineur.
Tout d'abord, le document ne parle pas que de la technique, mais aussi des aspects fonctionnels, qui sont clé dans le choix d'un ERP. A mon sens, ces deux critères sont les plus importants pour choisir le logiciel de gestion de votre entreprise (en plus de l'aspect libre/opensource et des critères économiques). Le critère technique est particulièrement important pour les sociétés qui vont faire des développements spécifiques importants sur leur ERP. Quand une boite investi des dizaines ou des centaines de milliers d'euros en développements spécifiques sur son ERP, ça serait bien qu'elle s'intéresse à la technologie dans laquelle elle investi !
[^] # Re: Google chat
Posté par Alexis de Lattre (site web personnel) . En réponse au journal Skype. Évalué à 1.
Effectivement, Jitsi supporte le partage d'écran (quand j'avais essayé sous Linux, ça ne marchait pas avec openjdk mais seulement avec le jdk d'Oracle). Moi, je suis toujours à la recherche d'un autre client Jabber libre qui supporte le partage d'écran… Jisti c'est bien, mais moi j'ai un laptop seulement 2 Go de RAM non extensible, donc ça le fait pas :-(
[^] # Re: Bravo !
Posté par Alexis de Lattre (site web personnel) . En réponse à la dépêche Sortie de OpenERP 6.1. Évalué à 2.
Vous avez bien bossé les gars, OpenERP 6.1 est vraiment une grande release ! En plus, les perfs de l'interface Web ont été grandement améliorées, cf mon bench
Il faut continuer le travail sur la revue des merge proposals de la communauté ; vous en avez accepté beaucoup, c'est super, mais il y en a encore un certain nombre en attente de review. Si on continue comme ça sur OpenERP avec des fonctionnalités innovantes + du clean-up de code + des review sérieuses des merge proposals de la communauté, alors je pense qu'OpenERP est promis à un bel avenir.