...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
PAGE EN COURS D'ÉDITION - Les liens ne sont pas fonctionnels.
...
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 de facturation électronique 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. : utilisation du Portail Mercurius« 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 :
...
| Table of Contents | ||||
|---|---|---|---|---|
|
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 de facturation électronique du secteur public belgebelge 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.
...
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.
...
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 « Le cycle « 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é (B) ».
1. Réception d'un document (e-facture, e-note de crédit, pièce jointe)
Flux et composants | Séquence |
| Préalable : le fournisseur a préparé une facture sortante dans son propre système comptable.
|
|
portail Mercurius. |
|
portail Mercurius. |
|
|
|
2. Envoi d'une réponse
Flux et composants |
Séquence | |
| 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.
|
|
|
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.
Protocole :
SOAP ( XML over HTTPS ) + WS-Security
Les spécifications techniques complémentaires relevantes peuvent varier d'un intégrateur à l'autre, et sont donc disponibles auprès de ce dernier. voir aussi la section « intégrateurs » ci-dessous.
...
Dans un scénario classique d'utilisation de Mercurius, le client programmera donc une séquence de ces opérations à échéances régulières : (1°) consulter la liste de ces nouveaux documents, (2°) pour chaque nouveau document, (a) relever le document et (b) confirmer bonne réception et autorisation de supprimer le document de la liste des documents en attente.
Les documents actuellement supportés sont :
...
DocumentTypeName | UBL DocumentTypeCode | XSD | format spécification | additional information | |
1 | Invoice | 380 | PEPPOL BIS 4A Invoice (***) |
2 | CreditNote | 81 | PEPPOL BIS 5A Billing (***) |
3 | AttachedDocument (**) | 916 | N.A. (**) | include faq |
Remarques syntaxe : UBL 2.0
(**) Explications complémentaires :
- Ce type de document permet de récupérer les pièces jointes des factures et notes de crédit (PV de réception, conditions générales... ) sous forme de fichier séparé et non nécessairement structurée (PDF, Excel ou tout autre format de fichier).
- Pour des raisons historiques, Mercurius extrait ces fichiers du document PEPPOL BIS dans lequel ils étaient inclus (Base64Encoding), puis les transmet en les associant à des documents XML séparés (de type AttachedDocument), mentionnant l'ID du parent-Document. Pour de plus amples informations, veuillez consulter (a) le XSD de ce document type et la FAQ traitant de attachedDocument.
- La transmission des fichiers proprement dit fait usage du protocole SOAP with Attachment ( {+}https://www.w3.org/TR/SOAP-attachments+ ).
(***) Les expéditeurs transmettent des documents conformes à ces spécifications de format. Cette spécification utilise la syntaxe UBL2.1. Pour des raisons historiques, Mercurius les convertit en UBL2.0. Hormis cette conversion, Mercurius n'effectue aucune transformation. Ces documents de spécification de format définissent donc bien les sémantiques respectives de ces documents. De plus amples informations concernant le cadre d'interopérabilité PEPPOL sont disponibles sur la page suivante : « page officielle de la Belgian PEPPOL Authority » (disponible en anglais uniquement).
...
Cette action nécessite une seule opération : submitApplicationResponse.
Seul un type de document est actuellement supporté :
DocumentTypeName | UBL DocumentTypeCode | XSD | spécification | |
1 | ApplicationResponse | 301 |
Remarque Pour des raisons historiques, la rédaction de la réponse est soumise à une spécification interne, et non la spécification PEPPOL BIS, comme c'est le cas pour les flux entrants. Mercurius convertit la réponse transmise par le client en un document conforme à la spécification PEPPOL applicable, c'est à dire « PEPPOL BIS 36A Message Level Response (EN) »; ceci est expliqué plus en détail sur la page destinée au secteur privé.
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 ».
...
Au cas ou 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 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
...
- 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.
- 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é.
- 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.
- 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.
...
- 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.
- Lancer les développements permettant l'intégration du système comptable à Mercurius.
- En parallèle :
- 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.
- 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).
- 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 :
- 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.
- 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
...
- 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 ».
- Demande d'accès :
- Remarques préalables :
- la demande d'accès se fait via l'introduction d'un Technical Connection Request Form;
- comme précisé, aucune Administrative Autorisation (AARF) n'est requise;
- le nom du service est « e-InvoicingServices/CustomerService V2.00 »;
- 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;
- Connection Data : pas d'application car le service est synchrone;
- Certificate : dès que les certificats (intégration et production) auront été générés, transmettez le Common Name (CN) dans le TCRF.
- Lien vers la procédure sur la page : « Je demande d'accéder à un service web FSB existant ».
- Remarques préalables :
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 Mecurius. Veuillez contacter votre interlocuteur chez BCED, le cas échéant via votre service informatique.