Journal Hackathon Factur-X le 24-25 janvier 2019 à Paris

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes : aucune
15
17
jan.
2019

Le Forum National de la Facture Electronique (FNFE-MPE) organise un Hackathon sur Factur-X le 24-25 janvier 2019 dans les locaux de GS1 France à Paris.

Pour rappel, Factur-X est une norme franco-allemande de facture électronique, aussi appelée ZUGFeRD 2.0, qui a été publiée en version finale le 31 décembre 2017. Une facture Factur-X est une facture PDF qui embarque un fichier XML à la norme CrossIndustryInvoice (CII) qui décrit la facture de façon structurée. Une facture Factur-X peut donc être lue par un humain avec son lecteur PDF préféré et aussi de façon fiable par un logiciel qui parse le fichier XML contenu à l'intérieur du PDF. Depuis avril 2018, le format Factur-X est supporté par Chorus Pro, la plateforme de facturation électronique de l'administration française. Depuis le 1er Janvier 2019, toutes les entreprises de plus de 10 salariés ont l'obligation d'utiliser Chorus Pro pour facturer l'administration (collectivités locales, fonction publique d'Etat, armée, hôpitaux, …).

L'objectif de ce Hackathon est d'aider les développeurs à implémenter la norme Factur-X dans leurs logiciels. Il y aura des présentations techniques sur Factur-X, des conseils et retours d'expérience d'implémentation, des sessions de développements, etc… Il existe maintenant des librairies opensource pour factur-x dans de multiples langages (Python, Java, PHP, …). Je serai présent pendant les deux jours du Hackathon pour partager mon expérience d'implémentation de Factur-X dans Odoo, aider à l'utilisation de ma librairie Python factur-x et coder dans la joie et la bonne humeur sur Factur-X.

L'accès au hackathon est gratuit ; il faut simplement s'enregistrer au préalable.

  • # Lopin compris

    Posté par  . Évalué à 2.

    Je ne comprends pas la logique qui consiste à Em barquer le XML (CII) dans le PDF. On peut toujours reconstruire le PDF à partir du XML si jamais on en a besoin (Qui pourrait en avoir besoin ?). Éventuellement, on peut passer le PDF inliné ou en pièce attachée du XML.

    Par ailleurs, Chorus permet déjà la gestion des pièces jointes. Il suffisait de demander à envoyer le PDF par ce canal.

    • [^] # Re: Lopin compris

      Posté par  . Évalué à 8. Dernière modification le 18 janvier 2019 à 12:06.

      J’imagine que c’est plus simple de transmettre un fichier PDF, contenant les données permettant de reconstruire ce même PDF, plutôt qu’un "obscure" fichier XML nécessitant un logiciel permettant de construire un PDF pour pouvoir lire humainement les données, et ce quelque soit l’environnement.

      Du point de vue utilisateur non technique ça se tient : on a le PDF, il est directement exploitable partout où un lecteur PDF est disponible. Et si besoin, ce même PDF permet à d’autres logiciels d’être exploité grâce au XML qu’il embarque.

      Ce qui rentre d’ailleurs parfaitement dans le cadre de XML : être lu par des machines et non par des humains.

      • [^] # Re: Lopin compris

        Posté par  . Évalué à 0.

        Cette norme est sur des échanges B2B, pas pour être imprimée et « lue par un humain ».

        Pour info, Cross Invoice Industry (le XML) est un standard porté par l’UN/CEFACT, pas vraiment « obscur ».

        • [^] # Re: Lopin compris

          Posté par  (site web personnel) . Évalué à 4.

          Il a écrit la même chose.
          c'est pas la norme qui est obscure, mais le XML pour un humain,

          "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

        • [^] # Re: Lopin compris

          Posté par  . Évalué à 1.

          Depuis la page en français décrivant Factur-x :

          L’objectif premier de Factur-X est de permettre aux fournisseurs, émetteurs de factures de créer des factures à valeur ajoutée, contenant un maximum d’informations sous forme structurée, suivant leur capacité à les produire sous cette forme, et de laisser les clients destinataires libres d’utiliser ou pas les données et / ou la presentation lisible, en fonction de leurs besoins et de leur maturité en matière d’automatisation de traitement.
          Le PDF serait donc une souplesse.

          • [^] # Re: Lopin compris

            Posté par  . Évalué à 2.

            La souplesse, c'est qu'on va continuer de voir des échanges de PDF par mail. En cas d'anomalie, les "humains" seront capables de rééditer la facture depuis leur GED ou
            depuis leur "ERP" et de l'envoyer à leur interlocuteur par mail.

            Pour moi, c'est un constat d'échec.

    • [^] # Re: Lopin compris

      Posté par  (site web personnel) . Évalué à 4.

      Le dirlo que ces détails n'intéresse pas, jetterait aussitôt le fichier XML. Tandis que le PDF il le lit puis l'ajoute à Odoo et me demande pourquoi des fois c'est pas magique (difficile de lui faire retenir que certains PDF incorporent des données XML utilisées par Odoo grâce au module d'Alexis de Lattre.

      "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

      • [^] # Re: Lopin compris

        Posté par  . Évalué à 2.

        Ce dirlo est du côté de l’emetteur De la facture ou du réceptionnaire ?

        • [^] # Re: Lopin compris

          Posté par  (site web personnel) . Évalué à 2. Dernière modification le 18 janvier 2019 à 12:33.

          À la réception. Comme l'a très bien dit un commentaire plus haut, on a besoin d'un truc lisible par des humains sans devoir installer d'autres outils. Le dirlo pourrait dont aussi être à l'émission, pour contrôler le résultat. Je te rapelle qu'une facture contient aussi un tas de mentions légales, parfois des notes et des conditions de vente, des logos, etc. éléments qu'on ne place pas en compta, donc pas dans le XML.

          "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

          • [^] # Re: Lopin compris

            Posté par  . Évalué à 5.

            "Je te rappelle qu'une facture contient aussi un tas de mentions légales, parfois des notes et des conditions de vente, des logos, etc. éléments qu'on ne place pas en compta, donc pas dans le XML."

            Juste un "petit" point de détail. Le XML dont on parle, c'est un format "normé" qui respecte un standard rigoureux. Tu n'as pas besoin des logos, mentions légales, etc. pour en faire une facture valide. Quand tu mets en place ce genre de chose entre un fournisseur et un client, tu mets aussi en place les messages XML qui valident que la facture a été bien reçue, qu'elle est conforme à ce qui était attendu, que tu vas la payer.

            Si la facture est non conforme ou erronée, tu envoies à ton fournisseur (qui s'est encore
            planté le gros boulet), un message XML qui lui notifie son erreur.
            Quand tu as validé et payé ta facture, tu envoies à ton fournisseur (qui a été sage) un autre message XML qui lui dit que tu as payé la facture no X à telle date avec le numéro de virement Y, ça lui permet de rentrer automatiquement dans sa compta, et d'affecter ses comptables à faire des trucs intéressants comme contrôler les notes de frais.

            Si en tant que client, tu veux être capable de consulter la facture PDF à la demande
            (en cas de litige par exemple), il y a des solutions pour ça. Quand tu tombes à 0,1 %
            de litiges, tu peux même affecter un humain pour les traiter.

            Si en tant que client, tu veux recevoir uniquement du PDF, il y a déjà des normes pour ça,
            qui gère les échanges sécurisés, les signatures, etc.
            C'est pas génial, mais ça permet à la DAF de venir discuter avec la DSI.

            Sur ces sujets là, il faut réfléchir au processus global, pas uniquement au "format" des
            échanges.

            Petit rappel de mon coté : la facture est un document qui intéresse d'autres personnes que
            l'émetteur et le destinataire, par exemple les services de l'état … on ne peut pas faire
            n'importe quoi au prétexte que c'est plus souple …
            Certains risquent de se faire pincer très fort dans les mois qui viennent.

    • [^] # Re: Lopin compris

      Posté par  (site web personnel) . Évalué à 5.

      Je ne comprends pas la logique qui consiste à Embarquer le XML (CII) dans le PDF. On peut toujours reconstruire le PDF à partir du XML si jamais on en a besoin (Qui pourrait en avoir besoin ?).

      Il y a, a minima, l'intérêt de pouvoir afficher « 10 € » dans le pdf et inscrire 10 000 € dans le xml.

      Adhérer à l'April, ça vous tente ?

  • # LaTeX

    Posté par  (site web personnel) . Évalué à 3.

    C'est une excellente approche d'un point de vue libriste : ça permet de distribuer le produit fini pour ceux qui le souhaitent, tout en y accolant la source pour les rares occasions où elle servira.

    Le même problème se pose par exemple avec LaTeX : quand j'envoie mes énoncés à mes collègues je leur transmet le pdf qui est destiné à être lu. Mais s'ils veulent réutiliser, ou corriger ce serait plutôt la source qui leur conviendrait.

    Voir ce journal m'a poussé à dégainer une recherche, et un outil très efficace existe en LaTeX pour la même fonctionnalité :
    embedfile, qu'on peut employer ainsi : 

    \documentclass{article}

\usepackage{embedfile}
%Ajouter manuellement chaque fichier à inclure...
\embedfile{TD2.tex}
\begin{document}

\end{document}

    « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace

  • # Réflexion drôle

    Posté par  . Évalué à 5.

    Ce hackaton et le format Factur-X ont l'ai vraiment intéressants. Cependant, je me demande ce qui arriverait si un acteur générait volontairement des PDF qui ne correspondent pas aux données XML ?

    • [^] # Re: Réflexion drôle

      Posté par  . Évalué à 5.

      Il risquerait de se faire pincer très fort …

      Pour être plus sérieux, si l'acteur est le fournisseur :

      a. si le client a tout automatisé et qu'il traite le XML en premier, il va vérifier
      que la facture XML correspond au bon de commande (ou à l'avis de réception) de l'étape
      précédente. Si oui, il va poubelliser le PDF, valider la facture, faire l'archivage légal
      et la passer en paiement puis passer à la facture suivante, sinon, il va ouvrir le PDF et
      demander des "explications" à son fournisseur (ou le balancer à la DGCCRF).

      b. si il traite le PDF en premier, à réception, il va rentrer la facture PDF dans un outil
      de workflow / GED indexées avec les données incluses dans le XML. Un opérateur humain va
      ouvrir le PDF dans l'outil de workflow ressortir le bon de commande (ou l'avis de réception)
      de l'étape précédente, constater le problème, ouvrir un dossier de litige dans son outil de
      workflow / GED, et l'envoyer au service "litige" pour qu'ils envoient un courrier au fournisseur
      un courrier standard au bout du délai légal ( 30 jours ? / 60 jours ? ), ça lui fera les pieds.

      Le plus drôle, c'est que si le fournisseur déploie une nouvelle version de son soft qui
      est buggée, le client peut se retrouver avec à traiter simultanément des factures conformes
      et des non conformes …

      • [^] # Re: Réflexion drôle

        Posté par  . Évalué à 1.

        En résumé : le PDF lisible par les humains, accompagné d'un XML est dans tous les cas plus long à traiter qu'un PDF tout court car il faut faire plus de vérifications.
        --> poubelle

  • # PDF hybride

    Posté par  . Évalué à 3. Dernière modification le 18 janvier 2019 à 18:20.

    C'est un peu comme les PDF hybride de LibreOffice qui incluent le source ODT. L'inconvénient, c'est que les documents PDF et PDF hybrides ont la même extension .pdf. Donc personne ne sait que le PDF est hybride et personne n'utilise ce format très pratique par exemple dans les ministères et dans les collectivités où les personnes changent souvent de poste et où leur ordinateur est "nettoyé" et souvent leur messagerie aussi (ce qui est d'ailleurs très pratique pour ne plus être responsable des cadavres dans les placards). Dommage, une simple extension différente, par exemple .hpdf aurait fait décoller les PDF hybrides.

    • [^] # Re: PDF hybride

      Posté par  (site web personnel) . Évalué à 2. Dernière modification le 21 janvier 2019 à 21:40.

      Le souci c’est que ton .hpdf ne serait lisible probablement que sous Linux et quelques rares autres systèmes puisque des systèmes comme Windows ne se servent que de l’extension pour choisir quel logiciel pour ouvrir un logiciel et que cette extension serait forcément inconnue de la part des lecteurs pdf existants, surtout les proprios très répandus… suivez mon regard…

      À la rigueur un .odt.pdf ferait l’affaire, l’association avec le lecteur de pdf sur la base de l’extension .pdf fonctionnerait, et l’association avec libreoffice sur la base de l’extension .odt.pdf aussi, et le nom serait explicite, mais c’est un peu vraiment trop moche.

      ce commentaire est sous licence cc by 4 et précédentes

      • [^] # Re: PDF hybride

        Posté par  . Évalué à 1. Dernière modification le 21 janvier 2019 à 22:04.

        Si les lecteurs PDF libres et LibreOffice se mettent d'accord pour lire un standard .hpdf, ils se répandront et un jour ou l'autre, deviendront un standard adopté par tout le monde, comme PNG etc. Ce n'est qu'une question de temps.

        • [^] # Re: PDF hybride

          Posté par  (site web personnel) . Évalué à 3. Dernière modification le 22 janvier 2019 à 10:02.

          comme PNG etc. Ce n'est qu'une question de temps.

          15 ans ?

          PNG est l’exemple-type du standard qui a mis 15 ans à décoller, d’ailleurs si les éditeurs sont frileux avec les autres formats (lossless webp, flif…) c’est aussi à cause de ça, on en a tellement chié qu’on n’ose pas se lancer dans autre chose parce qu’on est en droit de penser qu’on risque d’être seul pendant au moins 15 ans (alors qu’on sera peut-être seul pendant 15 ans pour la seule raison que les autres ont peur de ne pas être seul pendant 15 ans)…

          En fait c’est quoi un PNG ? Un PNG est un format d’image qui n’utilise pas un algorithme de compression adapté aux images, ça utilise zlib, oui oui, comme gzip. Pour simplifier un peu un PNG est un zip avec un format custom.

          La compression PNG n’est absolument pas adaptée à la compression d’image. D’ailleurs, une image non compressée en tga ou bmp dans un 7z fait mieux, tout simplement parce que 7z ou xz compresse mieux que zip ou gz.

          La seule chose qu’il y a de spécifique aux images dans PNG c’est qu’il y a une multitude de profils, en réalité PNG fait reposer sa (relative) performance sur les optimiseurs. Un optimiseur va regarder s’il y a pas beaucoup de couleur et si ça vaut le coup faire une palette, un optimiseur va regarder si le canal alpha a pas beaucoup de variations et si ça vaut le coup faire une palette, voire faire du canal alpha une image 1bit (noir et blanc), ou le supprimer s’il ne sert à rien, un optimiseur va regarder si le canal alpha est complètement transparent et donc virer tout ce qu’il y a dans les canaux RGB (ce qui est alors une destruction car certains usages peuvent avoir à traiter les canaux indépendamment), etc.

          Il y a donc une très grande quantité de formats PNG existants qui combinent ces différentes variations :

          • RGB normal
          • RGB palette
          • RGB niveaux de gris
          • RGB noir et blanc
          • Alpha palette
          • Alpha niveaux de gris
          • Alpha noir et blanc

          et d’autres…

          Ça signifie aussi que si on veut réellement optimiser ses images en taille et bénéficier de ces profils PNG qui ne sont pas là pour rien, on commence à utiliser des combinaisons très peu testées vu qu’en réalité personne n’optimise, et PAF! le PNG.

          Il faut considérer que 20 ans après on ne peut compter sur la prise en charge de PNG que dans ses profils les plus courant, c’est à dire qu’il faut être prudent avec les optimiseurs, c’est à dire qu’on doit être prudent avant d’utiliser la seule fonctionnalité qui, dans PNG, est à peu-près spécifique à la compression d’image.

          PNG est une catastrophe. On utilise PNG pour la seule raison qu’on en a chié pendant 20 ans. Ça fait 23 ans que PNG est sorti et j’ai corrigé il y a 6 mois un bug de chargement de certains formats de PNG dans un logiciel qui est presque aussi vieux, ça fait juste peur. En fait les plus gros utilisateurs de ce logiciel aujourd’hui préfèrent mettre des giga-octets de TGA non compressés dans leur dépôts git plutôt qu’utiliser PNG, ça en dit long…

          PNG était le pire exemple à donner.

          ce commentaire est sous licence cc by 4 et précédentes

Suivre le flux des commentaires

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