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.

...

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.

...

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.

...

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 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 :

...

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

...

• 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 ou 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.

...

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.

...

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

...

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.

...

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.

...

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.

...

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.

...

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

...

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

...

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.