Le présent article s'adresse aux représentants du secteur privé, confrontés à la mise en œuvre de l'e-facturation à destination des pouvoirs publics: responsables de la facturation, les équipes IT qui épaulent les départements financiers, les prestataires externes de service IT et/ou les fournisseurs de logiciels, ou tout autre intéressé à la problématique.
...
Cadre juridique
Le Conseil de la Directive 2010/45/EU du 13 juillet 2010 modifiant la Directive 2006/112/EC relative au système commun de taxe sur la valeur ajoutée en ce qui concerne les règles de facturation, a rendu la facture papier et l'e-facture équivalentes sur le plan juridique, créant les conditions de base du développement de l'e-facturation. Ces directives ont été transcrites en droit belge.
La Directive 2014/55/EU du 16 avril 2014, impose à tous les pouvoirs publics européens de recevoir et de traiter les factures entrantes sous format électronique qui correspondent à la norme européenne EN16931. Cette directive est en voie de transposition en droit belge.
...
Des experts métiers de tous les horizons du paysage de la facturation en Belgique, soutenus par des experts techniques, participent à cet effort commun. La Fédération des Entreprises de Belgique fournit les facilités nécessaires au groupe (support logistique, extranet, modération.... ).
...
| Info | ||
|---|---|---|
| ||
Extranet du groupe belge d'experts en e-invoicing (réservé aux membres): https://extranet.vbo-feb.be/SitePages/Home.aspx . |
Flux et composants
L'article « Cycle de vie d'une facture électronique envoyée au secteur public belge » décrit le flux et le traitement d'une e-facture. La présente section complète cette description, du point de vue du secteur privé (entreprises). Elle (a) détaille les flux d'information liés au service de transmission d'e-factures ainsi que des composants qui permettent ces flux, (b) introduit une vue technique de ces composants et (c) situe le rôle du réseau des prestataires de service, des access points et des éditeurs de logiciel, qui jouent un rôle clé dans ce contexte. Les principaux flux sont : (1) envoi d'une e-facture (ou d'une e-credit note) et (2) réception d'une réponse.
...
Flux et composants | Étapes |
| Préalable : le fournisseur a généré une facture sortante dans son propre système comptable.
|
...
En 2011, un petit groupe d'acteurs représentatifs de divers secteurs a tenu des ateliers visant à définir un ensemble de formats intersectoriels et transfrontaliers pour la plupart des types de document intervenant dans le cycle d'achat (catalogue, bon de commande, réponse à une commande, avis d'envoi, facture, note de crédit...). Les workshops CEN BII ont permis de définir une suite de formats pour ces types de documents, appelée les CEN Business Interoperability Interface (CEN BII) WorkGroup Agreements (WGA).
...
Suite à l'instauration de la Directive 2014/55/EU, le secteur public belge procédera à la mise à jour de ses systèmes afin de prendre également en charge la norme européenne EN16931 dans un proche avenir. Note : l'alignement au format CEN BII figure parmi les exigences de la norme EN 16931. En d'autres termes, la conception de la norme EN 16931 intègre la migration de la facture CEN BII.
...
Comme expliqué précédemment, le secteur public belge prend actuellement en charge les formats suivants : PEPPOL BIS Invoice et CreditNote. Le tableau suivant résume les informations requises pour préparer les documents de manière à garantir leur réception par le secteur public belge (ce qui ne veut pas dire que les documents seront approuvés).
DocumentTypeName | syntax (XSD) | semantic | |
1 | Invoice | ||
2 | CreditNote |
Le secteur public belge suit strictement le format PEPPOL BIS. La réception est garantie pour tous les documents conformes au BIS.
| Warning |
|---|
Par ailleurs, la plupart des entités s'attendent à ce que la facture comporte un numéro de bon de commande valide (dans l'UBL data element "orderReference"), car il s'agit de l'élément clé pour un traitement correct de la facture entrante. Si cette information est manquante, la facture risque d'être rejetée. |
Documents entrants (business response)
Dans une interaction e-facturation correctement mise en œuvre, le client transmet une réponse au fournisseur. Le cadre PEPPOL ne propose pas encore un type de document adapté, c'est-à-dire un format conçu pour l'envoi de business responses. Le format Invoice Response, qui comble ce besoin, sera disponible sous peu. Entretemps, PEPPOL comporte un autre format, le Message Level Response (MLR). Ce format est conçu pour renvoyer un feedback technique, mais peut être utilisé comme « plan B » pour envoyer une business response. Le secteur public belge utilise ce format dans ce but. Quand le format Invoice Response sera disponible, le gouvernement belge mettra en place un système de migration fluide de Message Level Response vers Invoice Response.
DocumentTypeName | UBL DocumentTypeCode | syntax (XSD) | semantic | |
1 | Message Level Response | 301 |
Remarques :
- Pour recevoir la business response telle que décrit ci-dessus, l'émetteur de la facture doit avoir déclaré les capacités de réception MLR dans l'infrastructure de transport PEPPOL. Pour plus de détails, voir la section suivante.
- Le Message Level Response (MLR) n'est pas obligatoire. La section « Scénarios particuliers » comporte également des informations supplémentaires détaillées sur le contenu du MLR.
| Info |
|---|
L'un des principaux avantages du cadre PEPPOL est qu'il permet de lever les entraves à l'interopérabilité découlant de la coexistence de nombreux formats différents. Tout comme les humains s'expriment en plusieurs langues, les machines ont besoin de nombreux formats. En effet, différentes machines fonctionnant pour différents secteurs et liées à des besoins et des schémas commerciaux très variés, chercheront naturellement le format optimal dans leur propre contexte. Cela engendre une certaine fragmentation entre les îlots de correspondants. L'existence de prestataires de services spécialisés, fonctionnant dans des îlots d'intervenants commerciaux dans une approche « 3-corners », est probablement la conséquence et non la cause de ce processus d'isolement. Grâce au cadre PEPPOL, tous ces formats peuvent continuer à être utilisés, à condition qu'ils ne soient pas imposé par un interlocuteur à l'autre. Le format « dénominateur commun » permet les échanges lorsque aucun autre format commun aux deux interlocuteurs n'existe |
...
Envoi/réception d'e-documents - informations importantes
...
Toutes les entreprises qui mettent en œuvre l'e-facturation, comme tous les pouvoirs publics belges, inscrivent dans ce registre la capacité de réception des e-factures et des e-credit notes. La description exacte de la capacité de réception se présente comme suit :
busdox-docid-qns::urn:oasis:names:specification:ubl:schema:xsd:Invoice-2::Invoice##urn:www.cenbii.eu:transaction:biitrns010:ver2.0:extended:urn:www.peppol.eu:bis:peppol5a:ver2.0::2.1
busdox-docid-qns::urn:oasis:names:specification:ubl:schema:xsd:Invoice-2::Invoice##urn:www.cenbii.eu:transaction:biitrns010:ver2.0:extended:urn:www.peppol.eu:bis:peppol4a:ver2.0::2.1
busdox-docid-qns::urn:oasis:names:specification:ubl:schema:xsd:CreditNote-2::CreditNote##urn:www.cenbii.eu:transaction:biitrns014:ver2.0:extended:urn:www.peppol.eu:bis:peppol5a:ver2.0::2.1
NB : comme vous pouvez le constater, et comme l'on peut s'y attendre dans un contexte d'e-facturation, ces enregistrements sont adaptés au traitement automatique, PAS aux discussions entre humains.
...
Toutes les entreprises qui mettent en œuvre l'e-facturation sortante, comme les fournisseurs des pouvoirs publics belges, sont invitées enregistrer la capacité de réception appropriée dans ce registre. La description exacte de la capacité de réception se présente comme suit :
busdox-docid-qns::urn:oasis:names:specification:ubl:schema:xsd:ApplicationResponse-2::ApplicationResponse##urn:www.cenbii.eu:transaction:biitrns071:ver2.0:extended:urn:www.peppol.eu:bis:peppol36a:ver1.0::2.1
La description ci-dessus correspond à PEPPOL BIS 36A Message Level Response.
| Anchor | ||||
|---|---|---|---|---|
|
...
Toute e-facture réputée conforme au format PEPPOL BIS mais qui ne passe pas l'étape de validation du format, est « filtrée » par un composant installé entre l'AP PEPPOL et Mercurius. Les fournisseurs (expéditeurs d'e-factures) et leurs sous-traitants doivent donc bien veiller à n'expédier que des e-factures respectant bien le format PEPPOL BIS.
Cette disposition découle des considérations suivantes :
- La section « Formats des documents » permet aux expéditeurs de factures (ou leurs sous traitant informatiques) de connaître les exigences de format des documents que les pouvoirs publics sont capables de traiter.
- Dans un contexte de généralisation de l'e-facturation, le respect de ces exigences est essentiel.
- Le cadre PEPPOL, qui forme la principale référence technique de notre programme de généralisation de l'e-facturation, préconise une approche éprouvée menant à la mise en place de flux de haute qualité basés sur le respect des formats. En particulier :
- le format PEPPOL BIS, qui est le format supporté par les pouvoirs publics belges, est pourvu d'outils de validation basés sur une technologie très répandue (« Schematron »), permettant d'automatiser le contrôle du respect du format;
- les contrats types qui lient les opérateurs, proscrivent la transmission de documents non conformes au format qu'ils sont réputés respecter. Rien n'oblige son destinataire à en prendre connaissance.
- Par conséquent, toute facture réputée conforme au format PEPPOL BIS mais qui ne passe pas l'étape de validation du format, est « filtrée » par un composant installé entre l'AP PEPPOL et Mercurius.
- Les expéditeurs (ou leurs sous-traitants) peuvent parfaitement automatiser la validation de leurs e-factures AVANT de les expédier, en utilisant les mêmes outils de validation que le filtre précité, car ces outils sont distribués publiquement et gratuitement.
- Enfin, le portail Mercurius est pourvu d'un outil en ligne de recherche de messages de test: l'expéditeur (ou son sous-traitant) peut transmettre l'e-facture via PEPPOL dans l'environnement de test, puis contrôler en ligne si le message est bien parvenu et n'est pas entaché d'erreur. cet outil permet d'éviter de propager les erreurs dans les flux de facturation réels.
...
La réponse générée par le secteur public belge contient un code de réponse qui confère à la réponse une signification importante. Il peut être utile que les fournisseurs ou leurs collègues/fournisseurs spécialisés dans l'informatique comprennent ces codes. Le tableau ci-dessous présente les informations consolidées :
Code | Valeur | Remarque | Légende de la remarque |
81:1 | Note de crédit approuvée | 1 : Si la réponse porte un code 81:2 ou 380:2, elle contient également une description textuelle expliquant le rejet. Cette description est fournie par le client. | |
81:2 | Note de crédit rejetée | 1 | |
81:3 | ID de la note de crédit existe déjà | 2 | |
81:4 | Violation d'une hard business rule | 2 | |
380:1 | Facture approuvée | 2 : Les codes 81:3, 81:4, 380:3 et 380:4 sont liés au business preprocessing exécuté par Mercurius. Voir le paragraphe suivant pour plus d'informations. | |
380:2 | Facture protestée | 1 | |
380:3 | ID de la facture existe déjà | 2 | |
380:4 | Violation d'une hard business rule | 2 |
...
Comme expliqué dans la section précédente, le fournisseur recevra la réponse par voie électronique uniquement s'il a enregistré la capacité de réception PEPPOL MLR. S'il ne l'a pas (encore) fait, Mercurius prévoit d'utiliser l'e-mail comme alternative, comme l'illustre le flux 3a du diagramme ci-dessus. Mercurius cherche l'adresse e-mail du fournisseur dans l'e-facture originale et transmet les informations de réponse contenues dans le MLR à cette adresse e-mail, en utilisant un format lisible par l'humain. L'adresse e-mail est extraite de l'élément de donnée UBL suivant :
Invoice/AccountingSupplierParty/Contact/ElectronicMail
Si cet élément de donnée est vide dans l'e-facture d'origine, il est impossible d'envoyer un e-mail. Dans ce cas, la seule façon pour le fournisseur de vérifier la réponse est de cliquer sur « Portail Mercurius ». Pour en savoir plus sur le Portail Mercurius, consultez la « Rubrique d'aide du portail Mercurius ».
...
(* ) Ce rejet se justifie par les obligations comptables auxquelles est soumise l'émission d'une facture en bonne et due forme.
En principe les fournisseurs ne doivent pas se soucier de ce service Mercurius. Cependant, l'expérience indique que de nombreux fournisseurs ne se conforment pas nécessairement aux business rules vérifiées par cette validation. En pratique, de nombreux fournisseurs doivent donc avoir accès à cette information.
Note : Le Portail Mercurius permet à tous les utilisateurs autorisés d'accéder au document, de constater ce rejet et de prendre connaissance de la motivation. Pour en savoir plus sur le Portail Mercurius, consultez la « Rubrique d'aide du Portail Mercurius ».
...
- l'AP d'expédition doit rechercher les capacités de réception du destinataire à l'aide du SMK au lieu du SML.
- Le SML est le Service Metadata Locator. C'est le système central qui redirige les AP qui cherchent les capacités de réception vers le SMP du destinataire (voir aussi « Envoi/réception d'e-documents - informations importantes » ci-dessus).
- Le SMK est l'équivalent du SML dans l'infrastructure de test.
- Tous les pouvoirs publics sont identifiés à l'aide des mêmes identifiants dans l'environnement réel (de production) et dans l'environnement de test. Cela permet de réduire les risques de confusion des numéros d'identification.
- L'outil en ligne suivant permet de contrôler rapidement le statut de la transmission dans l'environnement de test : Consultation des documents test.
- le Portail Mercurius permet également de vérifier à tout moment l'ensemble du trafic lié à la réception de documents, dans l'environnement de test comme dans celui de production. Pour en savoir plus sur le Portail Mercurius, consultez la page : « Aide du portail Mercurius ».
...
Les représentants du secteur informatique peuvent disposer de ressources sur le web pour valider leurs systèmes. Il existe de nombreux outils de validation de format en ligne. Ils valident le format PEPPOL BIS, non le contenu. Il est cependant vivement recommandé de valider la capacité de produire des documents dans le format valide, séparément des autres aspects liés au contenu.
Grâce au rôle eGOV « Mercurius AP », le secteur des prestataires de service informatique peut également utiliser le Portail Mercurius pour contrôler tout le trafic avec Mercurius et en assurer le suivi, tant dans l'environnement de test que dans celui de production. La procédure d'embarquement décrite à la section « Access Points » de la page officielle de la Belgian PEPPOL Authority (EN) comporte des informations complémentaires à ce sujet. Cette page comporte également des informations utiles pour le secteur de l'informatique concernant la conduite des tests et d'autres objectifs.
Finalement, pour en savoir plus sur le portail Mercurius, consultez la page : « Aide du portail Mercurius ».
...
Les pouvoirs publics fournissent, aux entreprises et aux pouvoirs publics, une assistance à l'utilisation de la plateforme et du portail Mercurius.
Il assure également une assistance relative au cadre d'interopérabilité PEPPOL. Cette assistance se limite toutefois au principes fondamentaux du cadre. En effet, le gouvernement n'a pas pour mission d'assurer un support technique approfondi de ceux qui souhaitent installer ou commercialiser des solutions pratiques, qu'elles ré-emploient ou non les ressources du cadre PEPPOL.
Enfin, les pouvoirs publics assurent une assistance technique spécifique aux entreprises du secteur informatique, dans deux domaines particuliers: (a) suivi des flux transitant par Mercurius et (b) enregistrement et consultation des capacités de réception sur smp.belgium.be.
Organisation
Remarque préliminaire à l'attention des fournisseurs
...
- Consultez les informations disponibles. BOSA DTO a investi de longues heures de travail pour collecter, structurer, organiser et traduire cette base d'information. Votre question est très probablement traitée quelque part.
- Si vous n'avez pas trouvé la réponse, remplissez une demande d'assistance.
- La demande d'assistance est également disponible à la page d'accueil du portail Mercurius.
- Il est vivement conseillé de vous identifier ; vous pouvez ainsi remplir au préalable certaines informations, ce qui (1) allège votre tâche, et (2) permet de recueillir des données essentielles sur la gestion de rôle pour faciliter le support et le rendre plus efficace.
- Notre Service Desk s'assure de l'identification correcte de la demande d'assistance dans l'outil de suivi et traite votre demande le plus rapidement possible. Le service est toutefois uniquement responsable de la gestion des questions fréquemment posées. Si vous n'avez pas trouvé ce que vous cherchiez dans nos pages d'information, il est peu probable que ses agents soient en mesure de vous aider. Dans ce cas, ils transmettront votre demande à la Mercurius Support Team.
- La Mercurius Support Team traite votre question et gère votre problème. La Mercurius Support Team prend en charge toutes les demandes d'assistance restantes. Les membres de l'équipe analysent le cas, confirment qu'il entre dans le champ d'activité du service et veillent à le traiter et à le résoudre rapidement à l'aide de toutes les équipes internes ou externes appropriées.
...