Le présent article s'adresse aux représentants des pouvoirs publics, confrontés à la mise en œuvre de l'e-facturation entrante : responsables d'achats, services techniques chargés de l'implémentation des systèmes, 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 mailroom électronique centralisé 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 public, destinataire de ces factures.

Il se limite aux éléments principaux et propres aux pouvoirs  publics (description générale, flux principaux, procédure d'embarquement... ). Des problématiques plus spécifiques font l'objet d'articles séparés. Par ailleurs, les aspects propres au secteur privé, ou communs avec celui-ci, sont également traités séparément (ex. « Mercurius pour le secteur privé »). Des références à ces articles connexes, ainsi qu'à d'autres sources d'information utiles, sont insérées dans le présent article, aux endroits appropriés.

L'article se compose des sections suivantes :

Historique

Le Conseil des Ministres a décidé en décembre 2012 (a) de soutenir la stratégie européenne visant à faire de la facturation électronique le mode le plus répandu en Europe à l'horizon 2020, et (b) dans ce cadre, de charger le SPF Budget et Contrôle de Gestion, l'Agence pour la Simplification Administrative, Fedict et le SPF Finances de mener ensemble une phase pilote d'e-facturation et d'e-scanning B2G. Fedict a pris en charge la mise en place de la plateforme d'échange Mercurius, harmonisant l'interface entre le secteur privé et le secteur public, de manière à éviter que les fournisseurs (et les pouvoirs publics) ne soient confrontés à d'excessives disparités d'un interlocuteur à l'autre.

La plateforme Mercurius était alors exclusivement basée sur une solution développée par les services informatiques de la Commission Européenne, ePRIOR.

À issue de la phase pilote, Mercurius a été mise en conformité avec le cadre d'interopérabilité PEPPOL. En effet, l'absence d'un tel cadre d'interopérabilité contraint les administrations (et leurs fournisseurs) à négocier, interlocuteur par interlocuteur, les conditions de l'échange, ce qui exclut une mise en œuvre à grande échelle de l'e-facturation. PEPPOL résout ce problème, pour l'e-facturation et plus généralement pour l'e-procurement,  vers les pouvoirs publics et au sein du secteur privé.  
Afin d'étendre le champ des échanges de document des pouvoirs publics avec le secteur privé, et de faciliter la mise en conformité des pouvoirs publics belges avec la norme européenne, Mercurius est en cours de refonte. L'interface avec les pouvoirs publics, qui n'a pas été modifiée depuis la phase pilote, est maintenant adaptée en vue de répondre aux nouveaux besoins.

Cadre juridique et accords de collaboration

e-facturation

La Directive 2010/45/UE du Conseil du 13 juillet 2010 modifiant la Directive 2006/112/EU 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 (cliquez sur le lien pour plus d'information).

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 corresponde à la norme européenne EN16931, à partir du 19 avril 2019 (les pouvoirs publics non centraux peuvent éventuellement bénéficier d'un délai d'un an supplémentaire).   Cette mesure est cohérente avec la Stratégie du secteur public belge en matière de facturation électronique. En effet, la stratégie qui la sous-tend vise clairement à utiliser l'État acheteur comme levier pour le développement de l'offre de solutions, et l'équipement des partenaires d'échanges, publics et privés. Il faut bien évidemment veiller à ce que les solutions permettant d'expédier les factures aux administrations, soient réutilisables pour l'e-facturation vers les clients privés.

Cette directive est en voie de transposition en droit belge.

Intégrateurs

Des dispositions régissent les échanges de données au sein des pouvoirs publics (loi du 15 août 2012, A.R. du 7 octobre 2013). Ces dispositions s'appliquent aux flux d'informations internes aux pouvoirs publics et consécutifs au développement de l'e-facturation.

Groupes d'utilisateurs, groupes de réflexion

L'adoption de l'e-facturation et sa généralisation sur le territoire national, n'est pas une simple étape. C'est plutôt un ensemble de changements et de processus divers. Des confrontations de points de vue et des échanges  réguliers permettent de converger sur des approches communes et cohérentes. C'est dans ce cadre que, à l'impulsion de la Vlaamse overheid, un groupe de réflexion a été constitué. Cette structure permet de partager les expériences et de s'assurer que les informations clé passent bien. À l'heure actuelle le reflexie groep suffit à remplir ce rôle, mais il est probable qu'avec l'essor de l'e-facturation, une structure plus robuste soit nécessaire.

Aspects financiers

Le fonctionnement de Mercurius engendre deux dépenses : les prestations du sous-traitant auquel sont confiées les opérations de la plateforme et l'encadrement de ce sous-traitant. 
Les prestations du sous-traitant découlent de l'exécution d'un marché en centrale de marché. Cette formule permet le cofinancement des opérations. À ce jour, BOSA DTO assume l'ensemble des coûts d'opération. À une plus ou moins brève échéance, ces coûts seront répartis entre les institutions bénéficiaires du service, au prorata de clés de répartition basées sur les volumes respectifs. Les détails de cette répartition doivent encore être définis.

BOSA DTO assure l'encadrement du sous-traitant sur ses budgets propres (personnel et missions connexes, p.ex. tests d'intrusion et d'exfiltration).

Flux et composants

L'article « Cycle de vie d'une facture électronique envoyée au secteur public belge » décrit les étapes du traitement d'une e-facture. La présente section complète cette description, du point de vue du secteur public (*) . Elle (a) détaille les flux d'information liés au service de transmission d'e-factures B2G, 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 intégrateurs de service, qui joue un rôle clé dans le dossier. Les flux sont: (1) réception d'une facture (ou d'une note de crédit) et (2) renvoi d'une réponse.

(*) la présentation détaillée des aspects propres au secteur privé est traitée à la page « Mercurius pour le secteur privé ».

1. Réception d'un document (e-facture, e-note de crédit, pièce jointe)

2. Envoi d'une réponse

Service Web Mercurius

Comme illustré à la section précédente, Mercurius expose un service qui permet aux pouvoirs adjudicateurs de recevoir leurs factures (et notes de crédit et pièces jointes) par voie entièrement électronique, et de transmettre les résultats de l'approbation de ces documents.

La présente section décrit les caractéristiques de ce service. En pratique, ce service est exposé par les intégrateurs. Cet aspect sera traité plus en détail à la section « Intégrateurs » ci-dessous.

Enfin, ce service est complété d'un portail, lequel permet aux représentants du client (et du fournisseur) de suivre l'avancement des transmissions et des traitements techniques. Cet aspect est traité dans une page séparée.

Les aspects techniques intrinsèques du service web Mercurius font l'objet d'une documentation séparée, consultable en Anglais uniquement à la page suivante : « Mercurius platform - Simpl.ePRIOR service - technical documentation ».

Scénarios particuliers

Cette section explore différents cas particuliers et explique comment ils sont supportés par Mercurius.

Mercurius Business Pre-Processing

Mercurius comporte un composant qui valide tout document (entrant ET sortant) d'un point de vue business. c'est à dire qu'il contrôle certaines caractéristiques du 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 (la génération du document de réponse suit les modalités décrites au paragraphe « b. Envoi d'une Réponse » de la section « Service Web Mercurius » ).

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 (* ) . Le document d'origine peut toujours être récupéré.
• date d'émission dans le futur. (* )
• le DocumentID est plus long que 250 caractères.
• le DocumentID  comporte des caractères spéciaux (c'est à dire, ne figurant pas dans la table ASCII 7 bits).

(* ) ce rejet se justifie par les obligations comptables auxquelles sont soumises l'émission d'une facture en bonne et due forme.

Remarque: le portail Mecurius permet, à tous les portal users autorisés à accéder au document, de constater ce rejet et de prendre connaissance de la motivation. Pour plus d'information au sujet du portail Mercurius, veuillez vous référer à la page « Aide du Portail Mercurius ».

Convertisseur PDF

Mercurius comporte un composant qui convertit une e-facture en document PDF et le transmet par e-mail à une adresse pré-configurée.  Ce composant a été ajouté dans un double but :

• Faciliter la communication des services publics : en effet, il est très malaisé d'expliquer aux fournisseurs que telle institution est prête, telle autre dans 3 mois, telle autre dans 6 mois, etc. Grâce au convertisseur PDF, tout un ensemble d'institutions, idéalement tout le secteur public, peut passer à la réception d'e-factures en une seule étape. Ensuite, chaque institution peut mener à bien son propre projet informatique, et est assuré de recevoir des e-factures dès le premier jour.
• Éviter que les expéditeurs soient pénalisés : en effet, tout fournisseur qui a fait l'effort de suivre les recommandations de l'administration, espère pouvoir rentabiliser son investissement dans des délais raisonnables. Grâce au convertisseur PDF, il peut immédiatement utiliser son nouveau système pour transmettre des factures à un plus grand nombre d'interlocuteurs. Cette approche transforme l'actuel cercle vicieux qui fait que tout le monde retarde sa décision, en un cercle vertueux, incitant chacun à passer à l'e-facturation.

Documents expirés

Au cas où un document n'a pas été relevé par son destinataire après 30 jours calendrier, la plateforme Mercurius :

• considère que le document est expiré;
• retire le document du bac à courrier entrant du destinataire;
• envoie un e-mail d'alerte à une adresse de service (configurable en fonction des désirs du client) notifiant l'expiration du document.

Au cas où le client souhaite réactiver le document, il peut adresser une demande au Mercurius Support Team via le formulaire de demande d'assistance (voir plus loin, section "support").

Remarque: en plus du mail d'alerte, le portail Mercurius permet, à tous les portal users autorisés à accéder au document, de constater l'expiration du document; Pour plus d'information au sujet de portail Mercurius, veuillez vous référer à la page « Portail Mercurius aide ».

Rétention

La plateforme Mercurius conserve les document reçus et tous les messages associés à ces documents pendant 24 mois. Après, les traces sont supprimées. Cependant, il est toujours possible d'accéder à des traces d'audit en cas de litige intervenant après 24 mois, sur demande explicite.

Identification d'un client : numéro d'entreprise

Pour recevoir des e-factures sur Mercurius, il faut préalablement s'enregistrer comme client sur Mercurius. Cet enregistrement crée un « bac à courrier entrant ». Cet enregistrement nécessite l'emploi d'un identifiant. Sauf exception, le client s'identifie au moyen de son numéro d'enregistrement dans la Banque Carrefour des Entreprises (BCE). Exemple: SPF BOSA: 0671.516.647.

Le client qui n'a pas de numéro d'entreprise propre, peut s'identifier au moyen d'un autre identifiant. Actuellement, le numéro de Global Location Number (GLN) est utilisé. La fourniture de cet identifiant est à sa charge.

Support et accompagnement

Le fonctionnement de Mercurius engendre des activités opérationnelles de deux types : (a) support day to day et (b) accompagnement des clients dans leur projet d'e-facturation.

Dans les 2 cas, et sauf circonstances particulières, les demandes de support doivent être transmises en utilisant le formulaire d'assistance, publié sur la page d'accueil du portail Mercurius (lien direct : « demande d'assistance »).

Support au jour le jour

Le support est organisé comme suit :

1. Consultez tout d'abord les informations publiées dans ces pages. 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.
2. Si vous n'avez pas trouvé la réponse, remplissez une demande d'assistance. Il est vivement conseillé de s'identifier, cela permet de pré-remplir certaines informations, ce qui (1) allège votre tâche, et (2) permet de recueillir des données essentielles pour un support efficace et de qualité.
3. Notre Service Desk reçoit votre demande. Notre Service Desk ne traite que les questions fréquemment posées. Si vous avez bien pris connaissance de la documentation en ligne, il est peu probable que ses agents soient en mesure de vous aider. Dans ce cas, ils transmettront votre demande au Mercurius Support Team.
4. Ce dernier traitera votre question / votre demande quelle qu'elle soit, fort de sa connaissance spécifique et de ses contacts avec tous les intervenants de l'e-facturation.

Accompagnement des clients dans leur projet d'e-facturation

Les responsables d'achat et / ou les équipes informatiques impliquées dans l'adoption de l'e-facturation, bénéficient d'un accompagnement de leur projet. Cet accompagnement peut couvrir plusieurs aspects : 

• enjeux stratégiques du projet, aide aux décisions fondamentales (techniques et autres);
• intégration technique avec la plateforme Mercurius proprement dit;
• veille et maintenance évolutive.

L'accompagnement peut donc démarrer avant la phase d'intégration technique, et se poursuivra généralement après.

Enjeux stratégiques :

L'adoption de l'e-facturation n'est pas seulement un projet technique ponctuel. Il faut plutôt le considérer comme une transformation profonde et de longue haleine, probablement jalonnée d'étapes. BOSA DTO mène un programme de conscientisation des pouvoirs publics face à cette problématique. BOSA DTO est disponible pour des rencontres afin d'étudier ensemble le contexte de l'institution (ou du groupement d'institutions), et de participer à l'établissement de la stratégie ou du plan d'action de l'institution. Bien entendu, l'institution reste souveraine dans son analyse et sa prise de décision. Il est néanmoins très important qu'elle soit informée au mieux. La faible maturité de l'e-facturation a pour effet que les informations ne sont pas aisément disponibles, sont souvent contradictoires, et au final insatisfaisantes. En particulier, la contribution du cadre PEPPOL est largement incomprise; de même, certaines fonctions de la plateforme Mercurius sont parfois mal exploitées faute de les connaître. La présente documentation vise à pallier à cette situation, en complément avec les rencontres au sein des pouvoirs publics.

En conclusion, l'objectif de telles rencontres est que l'institution en ressorte avec une vue claire des enjeux, des solutions à sa portée, et puisse établir un plan d'action.

À titre d'exemple, les questions suivantes devraient obtenir une réponse :

• Quelles sont les grandes étapes de mon projet ?
• Comment la solution offerte simplifie-t-elle l'émission et de la réception des e-documents (→ réduction des coûts) ?
• Dois-je passer par le convertisseur PDF ? Quand ?
• Quelles mesures de promotion envers mes fournisseurs prendre ?
• ...

Intégration technique avec la plateforme Mercurius

Une fois que la décision est prise de s'intégrer avec la plateforme Mercurius, le projet technique démarre.
Les étapes du processus d'intégration avec Mercurius sont :

1. Comprendre les flux de données, les opérations qui les permettent, et les accorder avec son propre système de réception de factures.
2. Lancer les développements permettant l'intégration du système comptable à Mercurius.
3. En parallèle :
   1. Configuration de l'environnement d'intégration de l'intégrateur : contacter son intégrateur et obtenir les accès au service Mercurius en environnement de test / d'intégration. voir aussi section « Intégrateurs » ci-après.
   2. Configuration, dans l'environnement de TEST de Mercurius,  d'un client (ou plusieurs) : le responsable doit envoyer une demande via le formulaire de demande d'assistance précisant (1°) le ou les numéros d'entreprises et dénominations et (2°) le Common Name (CN) du certificat du système qui appellera le Federal Service Bus (FSB).
4. Une fois que les développements sont suffisamment avancés, et que les configurations précitées sont actives, des tests en ligne peuvent être entrepris.
   • Des informations complémentaires concernant l'environnement de test et les outils de test sont disponibles à la demande via le formulaire de demande d'assistance.
   • Mercurius est outillé de manière telle que les correspondants puissent mener des tests de manière très autonome, y compris des tests de bout en bout avec des fournisseurs pilotes. Aucune activité spécifique de la part de DTO n'est dès lors prévue dans cette phase. Bien sûr, la Mercurius Support Team traitera les requêtes de support émises dans ce cadre. BOSA DTO peut également participer à la mise au point de ces activités si c'est nécessaire, par exemple pour expliquer le fonctionnement des instruments disponibles.
5. Une fois que les résultats de tests en ligne sont satisfaisants, le GO-LIVE peut avoir lieu. Il implique généralement (a) une configuration de l'environnement de Production de l'intégrateur et (b) une configuration de l'environnement de Production de Mercurius. Ces deux configurations se déroulent sur le modèle des étapes 3a et 3b décrites plus haut.

Parallèlement au projet technique, et afin d'en rentabiliser les efforts, il est essentiel que l'institution développe un projet de sensibilisation de ses fournisseurs à l'envoi de factures électroniques. À l'heure actuelle, il n'existe pas de modèle de communication suffisamment générique et réutilisable, pour être transmis aux institutions en vue d'une réutilisation pour cette étape. BOSA DTO est à la disposition des institutions pour les accompagner dans leurs activités de communication.

Remarques:

• Au cas où l'institution fait appel à un sous-traitant pour les développements et / ou les activités techniques, BOSA DTO peut traiter les aspects techniques et la procédure directement avec le sous-traitant.
• Au cas où l'intégrateur n'est pas encore en mesure d'exposer le service Mercurius, il est possible de s'adresser temporairement à l'intégrateur fédéral (FSB).
• Lorsque l'institution reçoit déjà des e-factures et se les fait transmettre via le convertisseur PDF, elle est invitée à le préciser dans ses demandes de configuration de Mercurius (test / production).

Veille technologique et maintenance évolutive

Postérieurement à l'intégration de l'institution à Mercurius, des phases d'extension et d'optimisation seront programmées au fur et à mesure de l'émergence de nouveaux besoins et opportunités. À partir de la collecte de ces besoins, BOSA DTO programme et exécute les modifications de Mercurius permettant d'y répondre. Ces améliorations sont ensuite rendues disponibles aux institutions.

Le Groupe de Réflexion (voir aussi plus haut, « Groupes d'utilisateurs, groupes de réflexion ») sert de plateforme de collecte des besoins des institutions, d'établissement des priorités des demandes, et de communication du roadmap d'évolution de Mercurius.

Tests

L'existence de l'environnement de test de Mercurius, facilite les travaux d'intégration de nouvelles institutions et de nouveaux opérateurs économiques (fournisseurs), et le développement de nouvelles fonctions. Cet environnement, disponible en permanence, est pleinement conforme à l'environnement de production (en ce compris les identifiants des correspondants et les autorisations d'accès aux données). Ceci permet aux correspondants de mettre au point leurs systèmes en parfaite isolation des flux réels. La communication des informations pratiques à propos de l'environnement de test, est incluse dans l'accompagnement des projets d'intégration des institutions à Mercurius.

Intégrateurs

Les systèmes des clients ont accès au service de Mercurius par l'entremise des intégrateurs de service. Conformément aux dispositions régissant les échanges de données au sein des pouvoirs publics, les services de Mercurius sont exposés par les intégrateurs de service fédéraux et régionaux, à destination de leurs niveaux de pouvoir respectifs.

a) Pouvoirs adjudicateurs fédéraux

Généralités

Comme le diagramme l'illustre, le Federal Service Bus (FSB) remplit un double rôle: (1°) d'une part il connecte le système informatique Mercurius au réseau des intégrateurs. Dans ce cadre il assume une série de fonctions essentielles de sécurité et de performance; (2°) il expose le service Mercurius pour les pouvoirs adjudicateurs fédéraux et les intégrateurs de services tiers. Seul le deuxième rôle fait l'objet d'un exposé dans la cadre du présent article.

Les dispositions générales du FSB (signature d'une convention d'utilisation, ouverture de flux, utilisation d'un certificat, reporting, environnement d'intégration, support...) s'appliquent également au service Mercurius.

Le FSB publie une description générale de ses missions, services, procédures, FAQs et modalités de support à la page suivante :

Modalités administratives

Dans ce cadre, et étant donné que le service Mercurius donne accès aux factures de la partie intéressée, la seule vérification administrative requise pour accéder au service via le FSB, consiste à s'assurer que le demandeur est bien une personne morale de droit public belge liée au niveau fédéral.

Modalités techniques :

Pour pouvoir accéder à tout service exposé sur le FSB, deux formalités technico-administratives sont nécessaires : (1°) générer et transmettre un certificat et (2°) demander l'accès aux service(s) visé(s).

1. Génération d'un certificat : cette étape nécessite l'emploi d'un outil de génération de certificat (à charge du service technique du demandeur) . Administrativement, il y a lieu de suivre une procédure administrative classique, permettant de lier avec certitude le certificat à l'entité qui va l'utiliser pour l'identifier. Cette procédure est documentée ici : « Je demande un certificat de consommateur FSB ».
2. Demande d'accès :
   1. Remarques préalables :
      1. la demande d'accès se fait via l'introduction d'un Technical Connection Request Form;
      2. comme précisé, aucune Administrative Autorisation (AARF) n'est requise;
      3. le nom du service est  « e-InvoicingServices/CustomerService V2.00 »;
      4. il est bien entendu nécessaire de demander l'accès en environnement d'INTÉGRATION, car un cycle de développement et de test s'impose;
      5. Connection Data : pas d'application car le service est synchrone;
      6. Certificate : dès que les certificats (intégration et production) auront été générés, transmettez le Common Name (CN) dans le TCRF. 
   2. Lien vers la procédure sur la page : « Je demande d'accéder à un service web FSB existant ».

b) Autres pouvoirs adjudicateurs

• Région Bruxelloise et pouvoir locaux associés : ISR / FIDUS;
• Vlaamse gemeenschap et pouvoir locaux associés :  MAGDA / VSB;
• Région Wallonne, Fédération Wallonie Bruxelles et pouvoir locaux associés : BCED.

Vlaamse Gemeenschap

Pour la Région / Communauté flamande, la plateforme MAGDA (MAximale GegevensDeling tussen Administraties) joue le rôle d'intégrateur régional.
Les informations suivantes sont disponibles sur le site de Magda :

• Hoofdpagina
• Aansluitingsproces MAGDA-diensten (aussi d'application pour Mercurius)
• Contactformulier MAGDA - algemene vragen
• technische documentatie (Magda- Algemeen)

Région Bruxelloise

En Région bruxelloise, ISR / FIDUS assure le rôle d'intégrateur régional. Pour toute information relative à l'accès à Mercurius pour ce niveau de pouvoir, veuillez consulter la page suivante : « FIDUS homepage ».

Région Wallonne et FWB

En Région wallonne, BCED assure le rôle d'intégrateur régional. Pour le moment BCED n'expose pas encore les services Mercurius. Veuillez contacter votre interlocuteur chez BCED, le cas échéant via votre service informatique.