Alexis de Lattre a écrit 62 commentaires

Merci pour l'encouragement. Je vais essayer de faire ça début d'année prochaine !

Merci pour la suggestion. Oui, je connais Woob ; j'avais même à l'époque développé le module OCA account_invoice_download_weboob qui utilisait Woob pour récupérer les PDFs de factures sur les portails web des fournisseurs pour ensuite importer le PDF en tant que facture fournisseur dans Odoo. Mais mon idée était que le "script Web" s'exécute au niveau du navigateur de l'utilisateur (et non sur le serveur Odoo), avec l'idée de remplir le formulaire de TVA, et ensuite rendre la main à l'utilisateur pour qu'il puisse vérifier/valider/payer. D'où le fait que j'ai concentré mes recherches sur les plugins pour navigateurs Web.

Oui, Odoo gère la TVA sur encaissement. Mais comme je n'aime pas du tout la façon dont Odoo gère la TVA sur encaissement nativement (!), les modules que je publie pour la déclaration de TVA implémentent une autre approche, qui me semble beaucoup plus adaptée. Avec cette nouvelle approche, la propriété "TVA sur encaissement" n'est plus une propriété de la taxe mais une propriété de la facture et aussi une propriété du fournisseur. Ca gère le cas "mixte", où on fait à la fois de la TVA sur encaissement et de la TVA sur les débits (côté client et côté fournisseur).

Oui, il est possible de tenir la comptabilité d'une entreprise sur Odoo Community. Le résultat est "puissant", mais la mise en oeuvre n'est pas "simple". La mise en oeuvre suppose l'assemblage de nombreux modules OCA qu'il faut connaitre, choisir soigneusement, déployer, configurer, etc. Les fonctionnalités de Odoo Community + OCA dans le domaine compta/bancaire/facture électronique/douane sont vraiment très riches et en font certainement le leader des logiciels libres dans ce domaine fonctionnel, mais je ne peux pas dire que ce soit "simple". A l'occasion, je ferai une dépêche ou un journal pour faire le point sur les fonctionnalités de Odoo Community + OCA dans ce domaine, parce que je pense que peu de gens savent l'étendue des fonctionnalités proposées.

Le prix de 89 € ou 129 € que vous indiquez est le prix pour la liasse fiscale (qui est une déclaration annuelle). Le prix pour la déclaration de TVA est de 49 € HT par an par société comme indiqué sur cette page. Teledec propose des prix de gros pour les éditeurs/intégrateurs, ce qui permet de réduire encore très significativement ce tarif.

Si Odoo obtient un jour l'agrément pour la télétransmission de la TVA, ce sera très certainement pour son édition Odoo Enterprise uniquement et pas pour Odoo Community. La solution que je propose fonctionne sur Odoo Community et Odoo Enterprise.

Petite question sur Dolibarr pour Laurent: vous en êtes où sur le support Factur-X sur Dolibarr ?
D'après mes rapides recherches sur Internet (notamment https://www.dolibarr.fr/forum/t/projet-chorus-facturation-de-structure-publique/25944/90 et https://github.com/Dolibarr/dolibarr/issues/8836), j'ai l'impression que ce n'est pas encore abouti. Par curiosité, ça m'intéresse de savoir où en est le support Factur-X dans Dolibarr. Et si vous avez besoin d'aide ou d'expérience sur Factur-X/Chorus Pro, vous pouvez me faire signe.

Désolé d'arriver un peu après la bataille…

Je suis un important contributeur de l'OCA, en particulier sur le support de la comptabilité et la localisation française. A titre d'exemple, je suis l'auteur initial et/ou le principal contributeur des modules OCA suivants :
- virement SEPA,
- prélèvement SEPA,
- LCR directes,
- import de fichier de relevé de compte CFONB (il existe aussi des modules OCA pour les fichiers OFX, QIF et CAMT),
- la génération de factures Factur-X et UBL,
- import de factures Factur-X et UBL (et aussi PDF simple via invoice2data),
- connecteur vers Chorus Pro avec support de l'API Chorus via PISTE,
- la DEB (Déclaration d'Echanges de Biens) avec export XML pour pro-douane,
- la DES (Déclaration Européenne des services) avec export XML pour pro-douane,
- la DAS2 (i.e. déclaration d'honoraires) avec export de fichier au format exigé par teled.impots.gouv.fr,
- du FEC (module repris par l'éditeur en v9, et dupliqué dans l'OCA pour amélioration à partir de la v10),
- des cut-offs (produits constatés d'avance, charges constatées d'avance, factures non parvenues, factures à établir)
- les relances clients par mail/lettre/téléphone

Effectivement, Odoo Community ne permet pas de faire de la comptabilité. Mais par contre, Odoo Community + OCA permet de tenir une comptabilité française complète. La quasi-totalité de mes clients tiennent leur compta dans Odoo Community + OCA (seuls quelques uns tiennent encore leur compta dans le logiciel de leur expert comptable).

La paye n'est pas tenue dans Odoo ; elle est tenue dans un logiciel de paye et les écritures de paye sont importées chaque mois dans Odoo via le module-qui-va-bien.
Les immobilisations sont parfois tenues dans Odoo via le module OCA de gestion des immos (qui marche bien) ; parfois elles sont encore dans le logiciel d'immo de l'expert comptable et les écritures sont importées dans Odoo.
La liasse fiscale n'est pas générée par Odoo mais par un logiciel dédié à cette tache. Je suis l'auteur d'un module OCA qui permet d'exporter d'Odoo une balance comptable au format EBP Compta, et les logiciels de liasse fiscale permettent d'importer des balances à ce format, ce qui va permettre de remplir automatiquement le bilan et le compte de résultat de la liasse fiscale. Chez nous, on utilise teledec.fr pour la génération et la télé-transmission de la liasse fiscale (logiciel SaaS) et on importe notre balance comptable au format EBP compta en 3 clics.

Tout ça pour dire qu'on peut parfaitement tenir sa comptabilité dans Odoo Community + OCA. On le fait dans pas mal de boites ; on le fait même dans une PME cotée en bourse. Et la loi Sapin2 permet aux intégrateurs comme nous de générer une attestation nominative de conformité pour nos clients qui en ont besoin (le scope des entreprises concernées par cette obligation à été réduit au début du mandat de Macron, il n'y a maintenant que les entreprises qui font du B2C et/ou qui acceptent les règlements en cash… je simplifie un peu !).

Par contre, comme les nouvelles versions d'Odoo sortent tous les ans, pour éviter de passer trop de temps à porter les modules OCA par rapport au temps passé à les améliorer et à en développer de nouveau, j'avais initié l'idée de ne pas travailler sur toutes les versions d'Odoo, mais seulement sur une version sur deux. L'idée était de ne pas appliquer la règle "une version sur deux" bêtement, mais d'analyser les changements introduits dans chaque version d'Odoo, d'évaluer les bénéfices et les risques de chaque version, et de "choisir" les versions sur lesquelles on veut travailler. Il s'est avéré que, depuis la v8, les gros changements très impactants sont intervenus dans les versions impaires (v9 : ré-écriture des modules compta, vente et achats ; v11 passage à python3 et changements importants dans la gestion de stock ; v13 fusion de l'objet facture et écriture comptable), alors que les versions paires étaient moins "révolutionnaires". Et du coup, j'ai travaillé sur les modules compta de l'OCA sur les versions 8, 10 et 12. Et je compte bien travailler le v14 dès sa sortie prévue en Octobre prochain (je n'ai pas entendu parler de grosses révolutions dans la branche master depuis la v13).
Donc, si vous voulez utiliser Odoo Community + OCA pour une entreprise française, je vous conseille de choisir les versions paires, car la plupart des modules OCA que je maintiens seront déjà portés.

Dans tous les cas, je veux renouveller ici mon engagement sur le développement et le support d'une comptabilité complète avancée en logiciel libre sur Odoo Community + OCA. Et je peux témoigner du fait qu'il existe d'autres contributeurs OCA très actifs et très pointus en compta qui travaillent aussi dans ce domaine.

Je pense que la communauté Odoo n'a pas assez communiqué sur le fait qu'il était possible de tenir une comptabilité française complète avec Odoo Community + OCA. J'ai pour objectif d'améliorer cela dès que les modules de compta OCA seront portés en v14.

P.S. : et j'ai prévu de porter en v14 le module OCA qui permet d'envoyer automatiquement le montant au lecteur CB depuis le POS via le protocole Concert sur USB/série. Avec le passage du module POS de gestion des cartes de fidélité dans la version Community en v13, je crois que vous aurez tout ce qu'il vous faut pour utiliser Odoo Community + OCA en v14.

Quand on utilise Odoo Community, la migration se fait par OpenUpgrade, qui est un projet de l'OCA (Odoo Community Association). OpenUpgrade est une alternative aux services de migration de l'éditeur. Personnellement, j'utilise OpenUpgrade pour toutes les migrations que je réalise pour mes clients depuis 5 ans et j'en suis très satisfait. La dernière migration que j'ai réalisé avec OpenUpgrade était une migration de Odoo v7 à Odoo v12 ! Le gros avantage est d'avoir une maîtrise complète du process de migration de la base de donnée et la transparence sur les modifications apportées aux données.

Je confirme ce qui est dit plus haut. Certes, Odoo v10 utilise python 2.7 (le passage à python 3 a été fait avec Odoo v11). Python 2.7 et Odoo v10 ne sont plus officiellement supportés.

Mais le rythme de mise-à-jour des ERPs ne correspond pas toujours au rythme d'évolution de l'informatique moderne. Pour donner un ordre d'idée, avant de basculer sur Odoo pour la campagne 2018, ce moulin à huile utilisait une application dédiée développée en interne qui tournait sous Mac OS 9. La seule solution pour faire tourner Mac OS 9 est dans une machine virtuelle, et, d'après ce que j'avais compris, les rares machines virtuelles qui supportaient encore Mac OS 9 était des logiciels pour Mac OS X… en version PowerPC !
Quand on compare un logiciel pour Mac OS 9 qui tourne dans une VM sur un Mac PowerPC à Odoo v10 en python 2.7 sous Ubuntu 18.04 LTS, alors on relativise la problématique de l'obsolescence :)

Mais on est bien conscient qu'il faut évoluer; et la migration sur Odoo v14 est déjà planifiée.

Dans le domaine des ERP (PGI en français, progiciels de gestion intégrés, terme qui désigne les logiciels tout-en-un qui font la compta, la gestion de stock, la fabrication, l'administration des ventes, les achats, la CRM, etc…), une verticalisation métier désigne un développement logiciel générique qui adapte l'ERP à un certain secteur d'activité. Par exemple, une usine agroalimentaire n'aura pas les même problématiques qu'un équipementier télécom, ou qu'un fabricant d'avions. Ils auront tous besoin de générer des stocks, les fabrications et les achats… mais ensuite les attentes et les problèmes à résoudre sont très différents. Habituellement, on réalise des développement spécifiques pour adapter l'ERP au métier du client. Mais, si il existe une verticalisation métier, on va utiliser l'ERP générique complété par la verticalisation métier, et ça réduira fortement des développements spécifiques nécessaires, vu que la plupart des besoins particuliers au métier du client seront couverts par les modules de verticalisation métier.

Si ton "client" public n'utilise pas de code service, alors il faut que la balise "BuyerReference" du XML soit vide ou non présente.

Est-ce que la balise "BuyerReference" est présente dans le XML en pièce jointe du PDF que tu as déposé sur Chorus (dans l'idéal, la balise ne devrait pas apparaître) ?
Si la balise apparaît, que vaut la cellule B12 du 2e onglet de ton ODS ? Est-elle bien vide ?
Si ta cellule B12 vaut "0", modifie la formule pour mettre par exemple:

=T($Facture.C18)

comme ça, B12 est vide quand le champ C18 du 1er onglet est vide.
J'ai modifié le modèle de facture il y a qq jours pour utiliser cette formule…

Tout d'abord, il faut que le flux passe à l'état "intégré". Pour cela, il faut aller dans le menu "Suivi des flux" (il faut activer cet espace au préalable si vous ne voyez pas cette entrée de menu), rechercher dans les flux et vérifier l'état du flux en question. D'après mon expérience, il faut entre quelques minutes et 36h pour qu'un flux passe à l'état "intégré".
Une fois que le flux est passé à l'état "intégré", on peut voir la facture dans le menu "Factures émises > Rechercher".

Un très grand merci pour cette série de logos. Cela m'a permis d'avancer dans ma réflexion et d'aboutir à ce que je souhaitais. J'ai publié à l'instant la version 0.22 avec le nouveau logo pour le projet, et un autre plus simple pour l'entrée de menu (la très petite taille empêche de toute façon de faire des choses compliquées). J'espère qu'il vous plaira.

J'en profite pour mentionner la journée de la facture électronique qui se déroule à Paris Jeudi 16 Janvier dans les locaux de GS1. Je serai présent toute la journée et je participerai à la conf de 10h15 "Atelier pratique Factur-X" pour présenter l'extension LibreOffice (et une autre petite surprise… que je dois finir de coder d'ici là !).

Merci pour cette proposition de logo. Ca serait effectivement super d'avoir un logo pour cette extension LibreOffice, plutôt que de squatter le logo de Factur-X profil minimum. Je me permets de suggérer quelques idées d'évolution du logo, pour le rendre plus compréhensible et plus lisible (compte tenu du fait qu'il est affiché en toute petite taille) : supprimer l'étoile et la flèche rouge, et les remplacer pour un gros X rouge. Qu'en pensez-vous ? Ce n'est peut-être pas très subtil, mais vu la taille à laquelle il est affiché, il est difficile de mettre des subtilités.

Concernant votre 2e point : il doit être possible de facturer un particulier en Factur-X sans SIRET. D'ailleurs, j'ai un peu amélioré les formules dans le 2e onglet pour que le champ SIRET soit vide et non égale à 0 quand le champ SIRET client est vide dans le 1er onglet. Pour moi, le but est de générer une facture Factur-X profil minimum en B2B, B2C et B2G.

Je viens de faire le test avec l'extension version 0.20 et le modèle de facture correspondant à la version 0.18, et ça marche bien sans soucis (j'ai testé avec le modèle français et anglais). Je pense que votre fichier modèle ODS en 0.18 est corrompu…

D'une manière générale, il est possible d'utiliser d'anciens modèles de facture avec les dernières versions de l'extension. En effet, le but est de pouvoir mettre à jour l'extension sans avoir besoin de modifier votre modèle de facture personnalisé.

Suite à votre suggestion, j'ai sorti à l'instant une version 0.20 qui ajoute une nouvelle entrée de menu "Fichier > Exporter au format Factur-X". A télécharger sur https://github.com/akretion/factur-x-libreoffice-extension/releases/

Je suis content que cette extension vous plaise !

Pour répondre à vos 2 points:

1. Déplacer le bouton est très simple: menu "Affichage > Barre d'outils > Controle de formulaire" puis cliquer sur le bouton en haut à droite (icone doigt + OK) qui permet de basculer sur le mode "Conception". Une fois en mode conception, vous n'avez plus qu'à sélectionner le bouton et à le déplacer. A la fin, il faut sortir du mode conception en cliquant sur le même bouton en haut à droite. Mais sinon, l'idée d'une barre d'outil avec une icone est intéressante…
2. Je ne connaissais pas cette case à cocher, mais c'est une bonne idée ! J'ai implémenté cette fonctionnalité dans ma dernière release 0.19 que j'ai publié à l'instant. Vous me direz si ça correspond bien à ce que vous attendiez !

Petite chose à faire attention quand vous mettez à jour : vérifiez que le fichier est bien nommé "factur-x_macro.oxt" (et qu'il n'a pas été renommé automatiquement factur-x_macro.oxt(1)" car vous l'auriez téléchargé dans le même répertoire que la version précédente de l'extension) quand vous procédez à la mise à jour de l'extension, sinon le bouton ne marchera plus. En effet, le bouton contient le chemin vers l'extension, qui est désignée par le nom du fichier au moment de l'installation (c'est bizarre, mais c'est comme ça !).

Dans invoice2data, il y a plusieurs modules d'entrée possible ; par défaut, c'est le module pdftotext qui est utilisé (texte brut extrait du PDF), mais il existe aussi un module d'entrée tesseract (OCR opensource, utile quand le PDF est issu du scan d'une facture papier… mais ce sera évidemment moins fiable que l'extraction de texte brut) et un autre basé sur Google Vision (service en ligne de Google qui fait du machine learning/IA, cf https://cloud.google.com/vision/?hl=fr)

La liste des modules d'entrée d'invoice2data se trouve dans ce morceau de code:
cf https://github.com/invoice-x/invoice2data/blob/master/src/invoice2data/main.py#L25

Oui, seuls les 2 premiers onglets du tableur sont utilisés par la macro. Le 1er onglet est exporté en PDF ; le 2e onglet permet de générer le XML. Dans le 2e onglet, seules les valeurs des cellules de la 2e colonne sont utilisées. Il est possible de changer les formules de la 2e colonne de l'onglet 'Données'.

Oui, bien sûr ! Seule la position des champs de la colonne valeur du 2e onglet (onglet données), ainsi que leur type (date, nombre, …), doit être conservée.

Merci pour ton retour… c'est effectivement un bug. Je l'ai corrigé dans la version 0.17, à télécharger sur https://github.com/akretion/factur-x-libreoffice-extension/releases

Est-ce que tu pourras confirmer que ça marche bien pour toi avec cette version ?

Pour les factures non factur-X, j'utilise la librairie Python invoice2data:

https://github.com/invoice-x/invoice2data

Avec cette lib, le PDF est d'abord converti en texte brut (donc le PDF ne doit pas être issu d'un scan), puis il va chercher le template (fichier YAML) qui correspond au fournisseur (via des mots clés tel que le numéro de TVA ou SIRET), puis il utilise les regexp indiquées dans le template pour extraire les données essentielles (date, numéro de facture, total HT, total TTC). Il y a déjà des templates pour plusieurs grandes entreprises françaises gros émetteurs de factures (EDF, Orange, SFR, Free, … cf https://github.com/invoice-x/invoice2data/tree/master/src/invoice2data/extract/templates/fr) et tout le monde est invité à en contribuer.

Il faut quand même faire l'effort de préparer un template par fournisseur ; donc ça va bien pour les fournisseurs récurrents, mais pas pour les fournisseurs ponctuels.

Et quelle est la version utilisée de l'extension LibreOffice pour Factur-X ?
Dans la version 0.15, il y avait un bug qui provoquait un plantage de la macro quand le numéro de TVA de l'émetteur n'était pas renseigné (et 2 autres erreurs de ce genre). Je l'ai corrigé dans la version 0.16.
Est-ce que l'erreur se produit avec la facture modèle en français (sans changer aucune donnée dedans) ? Si la réponse est non et que tu utilises bien la version 0.16, peux-tu m'envoyer le fichier ODS avec les modifications que tu as effectué pour que je puisse reproduire le bug ?

Bonne idée ! J'ai ajouté un commentaire dans le bug report pour suggérer d'avoir un vrai support des pièces jointes dans l'export PDF de LibreOffice et de l'utiliser pour leur fonctionnalité de PDF Hybride… ça ferait d'une pierre deux coups !

Merci pour l'info concernant ArchLinux ; j'ai mis à jour la procédure d'install en conséquence.

Je confirme : quand on utilise la fonction "PDF Hybride (fichier ODF incorporé)", l'incorporation du fichier ODF n'est pas fait sous forme d'une pièce jointe (/Names /EmbeddedFiles /Names dans le Catalog du PDF), mais sous une autre forme (/AdditionalStreams directement dans le trailer du PDF). Comme j'avais encore jamais vu cette entrée /AdditionalStreams dans le trailer d'un PDF, j'ai été regardé dans la spec de la norme PDF (PDF Reference 1.7 d'Adobe, 6th edition) : a ma grande surprise, il n'y a aucune mention du terme "AdditionalStreams" dans la spec PDF !!! J'ai fait une petite recherche Internet à ce sujet, et je suis tombé sur ce bug report de LibreOffice qui dit que la clé "/AdditionalStreams" est une clé propriétaire inventée par LibreOffice (alors que la spec PDF interdit l'ajout de clés propriétaires) et que le PDF "hybride" généré n'est donc pas conforme à la norme PDF, et suggérant d'utiliser au contraire les pièces jointes PDF (qui a non seulement l'avantage d'être conforme au standard PDF, mais aussi l'avantage de donner la possibilité à l'utilisateur de voir que ce PDF est spécial avec l'ODF embarqué quand il ouvre le PDF dans son lecteur PDF habituel, et aussi d'extraire l'ODF du PDF avec un simple lecteur PDF, sans avoir besoin de LibreOffice pour cela). A ce stade du bug report, la réponse a été de dire que les lecteurs PDF ne sont pas dérangés par cette clé propriétaire et que donc ce n'était pas un bug prioritaire ! Comme quoi, on peut s'appeler LibreOffice, être partisan du format ouvert OpenDocument et ne pas respecter les autres normes comme PDF… très surprenant !