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.

Comme expliqué dans l'article « Stratégie du secteur public belge en matière de facturation électronique », la plateforme Mercurius assure un service de « Salle de courrier » (mailroom) électronique centralisée pour l'ensemble du secteur public belge dans le cadre de l'e-facturation B2G.

Le présent article poursuit la description de la plateforme Mercurius, en prenant le point de vue du secteur privé, émetteur de ces e-factures.

Il traite des éléments principaux et spécifiques au secteur privé (description générale, flux principaux, support et assistance... ). Les scénarios particuliers sont détaillés dans des articles connexes. Les aspects communs avec le secteur public sont traités dans des articles séparés (par exemple : « Aide du portail Mercurius »). Des références à ces articles connexes, ainsi que d'autres informations utiles, sont insérées dans le présent article, aux endroits appropriés.

Le présent article se compose des sections suivantes :

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.

Par ailleurs, les conseils des ministres du Gouvernement fédéral et de la Région flamande ont déjà décidé de rendre l'e-facturation B2G obligatoire. Ces décisions sont progressivement transposées en actions juridiques, techniques et promotionnelles par leurs administrateurs respectifs.

Mercurius est le résultat de plusieurs de ces actions. Comme précédemment expliqué, cette mailroom électronique centralisée pour le secteur public, permet aux entreprises de transmettre leurs e-factures à toute entité du secteur public d'une seule et même manière.

Aspects financiers

La solution mise en place par le secteur public belge pour recevoir les e-factures de ses fournisseurs, vise à réduire les coûts à long terme des émetteurs. À court terme, il n'est pas impossible que certains émetteurs doivent faire face à certains coûts, en raison du manque de concurrence sur le marché des solutions, ou du manque de maturité générale, plutôt qu'à des coûts réels et incompressibles. Il convient de tenir compte des aspects suivants :

La solution permet d'atteindre tous les pouvoirs publics belges. Aujourd'hui, le gouvernement fédéral et le Gouvernement régional flamand ouvrent la voie, mais l'objectif est clairement d'offrir une solution qui couvre également les autres régions, les pouvoirs locaux, et toutes les autres entités de droit public, ce qui représente au total 16 % du PIB belge.
La solution est conçue pour être réutilisable également pour toutes les entités du secteur privé belge. En étroite collaboration avec les représentants du secteur privé, le gouvernement met en place de nombreuses actions pour faire de cette potentialité une réalité.
La solution est également parfaitement réutilisable pour joindre les clients étrangers, tant dans le secteur public que dans le secteur privé. De nombreux contacts au niveau européen sont également mis en place pour faire de cette perspective une réalité.
La solution s'intègre complètement à la nouvelle norme européenne. En d'autres termes, le secteur privé a la garantie qu'il n'y aura pas de gros changement de cap lors de l'introduction de la norme européenne dans la stratégie d'e-facturation. Seules des adaptations marginales seront probablement inévitables.
Le portail Mercurius offre une solution aux fournisseurs qui, pour l'une ou l'autre raison, n'ont pas encore de véritable solution d'e-facturation sortante. Cette solution est entièrement gratuite et, pour la plupart des PME belges, est accessible sans aucune formalité administrative. L'utilisation du système de gestion des rôles eGOV, qui permet de donner accès à des employés ou a des tiers (en plus des représentants légaux de l'entreprise), n'est nécessaire que pour les moyennes et grandes entreprises, qui souvent en sont déjà utilisatrices dans d'autres contextes. Ce système rajoute une étape administrative aux utilisateurs du portail Mercurius, mais il est de loin le système le plus commode de gestion des accès.

Belgian Business Experts Group

Un groupe d'experts e-invoicing belge a été fondé en juin 2017. Il aborde des questions telles que « Comment une facture avec escompte doit être exprimée au format BIS ? », « Ce qui rend un numéro de facture unique. », « Comment faire face à la multiplicité des schémas d'identification ? ». C'est un point de rencontre entre différents groupes, chaque groupe ayant ses propres perspectives et préoccupations. La confrontation de ces points de vue dans un état d'esprit constructif accélère la généralisation de la facturation électronique.

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.

La présentation détaillée des aspects propres au secteur public, est traitée dans la section « Mercurius pour le secteur public ».

1. Envoi d'une facture/note de crédit

Flux et composants

Étapes

Légende:
FAS Federal Authentication Service (service d'authentification des utilisateurs accédant au portail Mercurius)

Préalable : le fournisseur a généré une facture sortante dans son propre système comptable.

Étapes :
1.   Le fournisseur expédie l'e-facture via PEPPOL.
Voir aussi « Étape 1 : le fournisseur envoie sa facture au client » de la page « Cycle de vie d'une facture électronique envoyée au secteur public belge »
2.   Mercurius récupère l'e-facture et la dépose dans le « courrier entrant » du client.
Voir aussi « Étape 2 : Mercurius reçoit la facture (pour le client) » de la page « Cycle de vie d'une facture électronique envoyée au secteur public belge ».
3.   Le client appelle le service Mercurius exposé par son intégrateur, pour retirer son courrier entrant.
Voir aussi « Étape 4 : à son gré, le client ouvre son e-mail » de la page « Cycle de vie d'une facture électronique envoyée au secteur public belge ».
4.   L'intégrateur accède à Mercurius, relève l'e-facture pour le compte du client, et la lui transmet.

Résultat : l'e-facture est transmise au client. Elle est retirée du courrier entrant du client sur Mercurius. Elle reste visible sur le portail Mercurius.

Remarques :
5. À tout moment, le fournisseur, le client et tous les intermédiaires impliqués dans l'échange, peuvent contrôler l'avancement de la transmission via le portail Mercurius.
1a. Le fournisseur qui n'est pas en mesure de transmettre son e-facture sur PEPPOL peut la saisir via le formulaire « Nouvelle facture » sur le portail Mercurius (pour autant qu'il s'agisse d'une facture raisonnablement simple).
1b. Le fournisseur qui a participé à la phase pilote et qui n'est pas encore en mesure de transmettre son e-facture par PEPPOL peut transmettre sa facture via l'interface pilote (temporairement).
3b. Le client n'est pas encore en mesure de recevoir les e-factures. Dans ce cas Mercurius convertit l'e-facture en un document PDF et le transmet à une adresse e-mail préalablement enregistrée dans sa configuration.

La collecte de courrier entrant via le service Mercurius, nécessite l'utilisation de 3 opérations (« inbox request », « retrieve document », « mark document »). Voir plus loin.

2. Réception d'une réponse

Flux et composants

Étapes

Préalable : le client a procédé à l'approbation (ou au rejet) de la facture dans son propre système comptable - voir aussi « Étape 5 : le client traite la facture » de la page « Cycle de vie d'une facture électronique envoyée au secteur public belge ».

Étapes :

Le client appelle le service Mercurius exposé par son intégrateur et soumet sa réponse au fournisseur.
Voir aussi « Étape 6 : le client prépare une réponse à la facture et la transmet à Mercurius » de la page « Cycle de vie d'une facture électronique envoyée au secteur public belge ».
L'intégrateur accède à Mercurius, et transmet la réponse du client.
Mercurius expédie la réponse via PEPPOL.
Voir aussi « Étape 7 : Mercurius envoie la réponse au fournisseur » de la page « Cycle de vie d'une facture électronique envoyée au secteur public belge ».
Le fournisseur retire la réponse via son Access Point (AP). Si l'AP est géré par un tiers (ex. prestataire de service), un accord technico-commercial définit les conditions du processus de retrait de la réponse.

Résultat : la réponse est transmise au fournisseur.

Remarques :
5. Le statut de la facture (« reçu »/« approuvé »/« rejeté ») et les détails de ce statut (motivation), sont consultables sur le portail Mercurius. À tout moment, le fournisseur, le client et tous les intermédiaires impliqués dans l'échange, peuvent également contrôler l'avancement de la transmission via le portail Mercurius.
3a. Le fournisseur ayant envoyé son e-facture via PEPPOL n'est pas toujours capable de récupérer la réponse via PEPPOL. Dans ce cas Mercurius lui transmet la réponse par e-mail, selon des modalités décrites ci-après : « Étape 7 : Mercurius envoie la réponse au fournisseur » de la page « Cycle de vie d'une facture électronique envoyée au secteur public belge ».
3b/4b. Les fournisseurs s'étant connectés pendant la phase pilote, peuvent continuer à utiliser l'interface pilote (pour une durée limitée).

Formats des documents

La section précédente a présenté les flux de documents électroniques entre les correspondants. La présente section expose les caractéristiques des formats s'appliquant à ces documents. La compréhension de ces caractéristiques, et de leur impact sur les échanges, est déterminante.

Préambule

Traditionnellement, l'échange de documents électroniques requiert que l'émetteur et le destinataire s'accordent sur un format pour chaque type de documents concerné par les échanges. Il s'agit d'une condition sine qua non pour que les systèmes IT de chaque correspondant puissent communiquer sans faille.

Un format comporte deux aspects principaux : (a) sémantique : le document se compose d'éléments d'information décrits de manière à exclure les erreurs d'interprétation; (b) syntaxique : ces éléments communs d'information sont transposés dans une syntaxe, une représentation des données, qu'un système informatique est capable de « lire »/d'« écrire ».

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).

Les résultats de ces workshops ont été ré-employés dans diverses solutions pratiques d'e-procurement, dont (a) la plateforme ePRIOR développée par la Commission européenne et (b) les PEPPOL Business Interoperability Specifications (BIS). Comme déjà expliqué PEPPOL BIS remplit le rôle de « format commun » : si deux correspondants ne disposent d'aucun autre format commun pour l'échange de leurs documents, ils « se rabattent » sur PEPPOL BIS pour échanger.

L'expérience pratique acquise au cours d'une phase pilote (2013-14) réutilisant la plateforme ePRIOR adaptée au contexte belge, a permis au secteur public belge de valider que le recours aux formats CEN BII « Facture » et « Note de crédit », permettait de satisfaire leurs besoins fonctionnels. De ce fait, lors de l'adoption du cadre d'interopérabilité PEPPOL, aucun besoin ne justifiait la prise en charge d'un format autre que le format dénominateur commun - le BIS.

Quoique les formats BIS ne soient pas les plus sophistiqués des formats disponibles, ils sont (a) très bien documentés et (b) accompagnés d'outils de validation, permettant d'automatiser le contrôle de conformité. Ces compléments ont une influence déterminante sur la qualité des échanges basés sur les formats BIS.

Pour toutes ces raisons, le secteur public belge a décidé, pour l'instant, de prendre en charge uniquement le format BIS pour les factures et les notes de crédit.

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.

Spécifications propres aux formats

Documents sortants (facture, note de crédit)

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	UBL-Invoice-2.1.xsd	Peppol BIS Invoice
2	CreditNote	UBL-CreditNote-2.1.xsd	Peppol BIS Credit Note

Le secteur public belge suit strictement le format PEPPOL BIS. La réception est garantie pour tous les documents conformes au BIS.

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	UBL-ApplicationResponse-2.1.xsd	PEPPOL BIS 36A Message Level Response

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.

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

Envoi d'e-documents

Un Access Point (AP) est le seul élément nécessaire pour l'envoi d'e-documents sur PEPPOL. Comme illustré dans la section « Flux typique d'une e-facture B2G » ci-dessus, l'envoi d'un e-document sur PEPPOL est similaire au « dépôt d'une enveloppe dans une boîte aux lettres ». Vous devez uniquement disposer d'accès à un AP qui joue le rôle de la boîte aux lettres.
Vous pouvez mettre en place votre propre AP, mais pour la majorité des entreprises, il est plus efficace d'avoir recours aux services d'une entreprise spécialisée (document service provider). En effet, la plupart des entreprises non spécialisées dans l'informatique (a) ne gèrent pas leur logiciel de facturation sortante - la mise en place d'un AP géré en interne sera donc probablement inutile, car vous devrez toujours y « connecter » votre logiciel de facturation sortante - , et (b) ne disposent pas des compétences en informatique pour le faire correctement/à un coût raisonnable - il ne s'agit pas d'un projet complexe mais, comme dans tout domaine, il nécessite certaines compétences spécifiques pour être mené à bien correctement.

Réception d'e-documents

L'un des aspects importants du cadre d'interopérabilité PEPPOL est que vous ne devez pas connaître les détails techniques de chaque destinataire pour leur envoyer des documents. Comment cela est-il possible ? PEPPOL comporte un registre (* ), actif en permanence, dans lequel toutes les entreprises recevant des e-documents sont enregistrées. Ce registre contient deux informations: (a) où envoyer les e-documents - il s'agit en fait de l'adresse de l'AP du destinataire (l'endroit où le « système postal » doit diriger l'e-document) - et (b) quel format utiliser : tous les destinataires doivent déclarer tous les formats qu'ils prennent en charge (et peuvent donc lire) afin que tous les émetteurs sachent quels formats ils peuvent utiliser. Comme tous les participants doivent toujours être en mesure de gérer le BIS, il est impossible que deux participants ne trouvent pas au moins un format commun.
(* ) le nom exact de ce registre est SMP (Service Metadata Publisher). En fait, il ne s'agit pas d'un seul grand registre, mais plutôt d'un ensemble de registres qui publient le même type d'information de la même manière. Ils se comportent donc collectivement comme s'il s'agissait d'un seul registre.

Réception d'une e-facture et d'une e-credit note par le client

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.

Réception de la réponse par le fournisseur

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.

Scénarios particuliers

Cette section explore différents cas particuliers et explique comment ils sont pris en charge par Mercurius.

Non-respect du format PEPPOL BIS

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.

Business Response : contenu du MLR

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

Business Response : le fournisseur ne prend pas en charge PEPPOL BIS MLR - voir diagramme, séquence 3a

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 ».

Mercurius Business Preprocessing

La plateforme Mercurius comporte un composant qui valide tout document (entrant ET sortant) d'un point de vue business : cela signifie qu'il contrôle certaines caractéristiques de contenu du document. Si un de ces contenus viole une de ces règles de validation, Mercurius rejette le document au nom de son destinataire final. Le destinataire n'est pas informé de ce rejet. L'expéditeur, lui, reçoit une réponse notifiant le rejet et la motivation (le document de réponse).
Les contrôles effectués sont les suivants :

Doublon : si Mercurius a déjà reçu la même combinaison DocumentID-DocTypeID-SenderID-ReceiverID, il considère que c'est un doublon et le rejette. Il émet un code de réponse 380:3 (ou 81:3 pour une note de crédit) (* ). Le document d'origine peut toujours être récupéré.
Date d'émission dans le futur. Il émet un code de réponse 380:4 (ou 81:4 pour une note de crédit)(* ).
Le DocumentID est plus long que 250 caractères. Il émet un code de réponse 380:4 (ou 81:4 pour une note de crédit).
Le DocumentID comporte des caractères exotiques (c'est à dire, ne figurant pas dans la table ASCII 7 bits). Il émet un code de réponse 380:4 (ou 81:4 pour une note de crédit).

(* ) 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 ».

Exécution de tests

Étant donné que la généralisation de l'e-facturation et de l'e-procurement sont des thèmes assez nouveaux, il est vivement recommandé de se livrer à un minimum de tests. En même temps, le contexte novateur ne facilite ni l'organisation des tests ni l'interprétation de leurs résultats. C'est pourquoi les pouvoirs publics ont considérablement investi dans une infrastructure de test de bout en bout, robuste et stable, qui facilite les tests de l'e-facturation B2G, et peut également être utile pour certaines phases de tests de l'e-facturation B2B.

Informations pour les fournisseurs (y compris leurs équipes techniques)

Vous éprouvez le besoin de faire certains tests. Si votre système de gestion de la facturation sortante dispose d'un environnement de test, ou s'il peut produire des factures à des fins de tests (c'est-à-dire des factures qui ne seront pas réellement comptabilisées) et de les envoyer vers l'environnement de test des clients, alors vous disposez de tous les éléments nécessaires pour envoyer des factures de test au secteur public. Dans le cas contraire, vous devez vous adresser au responsable de votre système.
Pour envoyer des factures vers les systèmes de test du gouvernement :

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 ».

Informations complémentaires pour le secteur informatique

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 ».

Support et accompagnement

Mercurius est un service d'utilité publique. Il s'adresse à 5.000 institutions et 50.000 fournisseurs, voire plus si l'on considère la rotation des fournisseurs du secteur public. De tels volumes (et la diversité sous-jacente dans l'utilisation du service) impliquent nécessairement des activités de support conséquentes. Il est dès lors essentiel pour BOSA DTO de veiller à évaluer, décrire, organiser et délivrer correctement ces activités support.

Portée

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

Même si l'e-facture est transmise par voie électronique, elle reste avant tout une facture. Pour toute question concernant son traitement, vous devez toujours vous adresser au responsable d'achat chez votre client. Ce qui est reçu, ce qui est approuvé... En cas de problème technique avec l'e-facture, votre responsable d'achat pourra répondre à vos questions, sauf si la facture n'est pas parvenue à Mercurius. Dans ce cas, il s'agit la plupart du temps d'un problème lié à votre fournisseur de solution informatique ou à l'Access Point (AP) (interne ou externe). Il convient donc généralement de signaler le problème à ce dernier. Les outils et procédures décrites ci-après visent à aider chaque partie à traiter les problèmes efficacement, et non à « contourner » ces interlocuteurs !

Description des modalités de support

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.
1. La demande d'assistance est également disponible à la page d'accueil du portail Mercurius.
2. 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.

Browser not supported