Dit artikel richt zich tot de vertegenwoordigers van de overheidsdiensten die worden geconfronteerd met de uitvoering van binnenkomende e-facturatie: inkoopverantwoordelijken, technische diensten belast met de implementatie van systemen, of elke andere betrokken partij bij deze problematiek.

Zoals werd uitgelegd in de Strategie voor elektronische facturatie van de Belgische overheidssector biedt het Mercuriusplatform een gecentraliseerde elektronische mailroomdienst voor de gezamenlijke Belgische overheid, in het kader van de e-facturatie B2G.

Dit artikel is een vervolg op de omschrijving van het Mercuriusplatform vanuit het standpunt van de overheidssector, ontvanger van deze e-facturen.

Het beperkt zich tot de voornaamste elementen (algemene omschrijving, voornaamste stromen, procedure voor de toetreding, etc.) en de elementen die eigen zijn aan de overheid. Specifieke problemen worden besproken in aparte artikels. Daarnaast worden ook de aspecten die eigen zijn aan de privésector, of die ermee gemeenschappelijk zijn, apart behandeld (bv. gebruik van het Mercuriusportaal). Referenties naar deze verwante artikels, alsook naar andere nuttige informatiebronnen, worden op de gepaste plaatsen in dit artikel ingelast.

Het artikel bestaat uit de volgende afdelingen:

Voorgeschiedenis

De Ministerraad heeft in december 2012 beslist (a) om de Europese strategie te ondersteunen die erop gericht is van elektronische facturatie de meest verspreide wijze van factureren te maken in Europa tegen 2020, en (b) om in dit kader de FOD Budget en Beheer, het Agentschap voor Administratieve Vereenvoudiging, Fedict en de FOD Financiën de opdracht te geven om samen de pilootfase voor e-facturatie en e-scanning B2G te leiden. Fedict heeft het opzetten van het uitwisselingsplatform Mercurius op zich genomen, ter harmonisering van de interface tussen de overheidssector en de privésector, om te vermijden dat de leveranciers (en de overheidsdiensten) worden geconfronteerd met buitensporige verschillen in functie van de gesprekspartner.

Mercurius was toen uitsluitend gebaseerd op een oplossing ontwikkeld door de informaticadiensten van de Europese Commissie, ePRIOR.

Na afloop van de pilootfase werd Mercurius in overeenstemming gebracht met het interoperabiliteitskader PEPPOL. Door de afwezigheid van een dergelijk interoperabiliteitskader waren de overheidsdiensten (en hun leveranciers) immers genoodzaakt om de uitwisselingsvoorwaarden te onderhandelen in functie van de gesprekspartner, wat de uitvoering van e-facturatie op grote schaal uitsloot. PEPPOL lost dit probleem op, voor e-facturatie en meer algemeen voor e-procurement, ten aanzien van de overheidsdiensten en binnen de privésector.  

Om het veld te verbreden voor de uitwisseling van documenten van overheidsdiensten met de privésector en te vergemakkelijken dat de Belgische overheidsdiensten in overeenstemming worden gebracht met de Europese norm wordt Mercurius op dit ogenblik herwerkt. De interface met de overheidsdiensten die niet werd gewijzigd sinds de pilootfase wordt nu aangepast om te voldoen aan de nieuwe noden.

Juridisch kader en samenwerkingsakkoorden

E-facturatie

Richtlijn 2010/45/EU van de Raad van 13 juli 2010 tot wijziging van Richtlijn 2006/112/EU betreffende het gemeenschappelijke stelsel van belasting over de toegevoegde waarde wat de factureringsregels betreft, heeft de papieren factuur en de e-factuur op juridisch vlak gelijkwaardig gemaakt, en daarmee de basisvoorwaarden gecreëerd voor de ontwikkeling van e-facturatie. De Belgische wet heeft deze Richtlijnen geïntegreerd.

Richtlijn 2014/55/EU van 16 april 2014 legt aan alle Europese overheidsdiensten op dat ze de binnenkomende facturen die voldoen aan de Europese norm EN16931 moeten ontvangen en verwerken in elektronische vorm vanaf 19 april 2019 (de niet-centrale overheidsdiensten kunnen eventueel een bijkomend jaar uitstel krijgen). Deze maatregel is coherent met de Strategie voor elektronische facturatie van de Belgische overheidssector. De strategie die hiervoor de basis vormt streeft er duidelijk naar de 'Overheid als inkoper' te gebruiken als hefboom voor de ontwikkeling van het aanbod aan oplossingen en de uitrusting van de uitwisselingspartners, zowel overheid als privé. Men moet er uiteraard over waken dat de oplossingen die toelaten e-facturen naar de overheidsdiensten te versturen herbruikbaar zijn voor e-facturatie naar privéklanten.

Deze richtlijn wordt op dit ogenblik omgezet in Belgisch recht.

Integratoren

Bepalingen regelen de uitwisseling van gegevens binnen de overheidsdiensten (wet van 15 augustus 2012, KB van 7 oktober 2013). Deze bepalingen zijn van toepassing op de interne informatiestromen binnen de overheidsdiensten en vloeien voort uit de ontwikkeling van e-facturatie.

Gebruikersgroepen, denkgroepen

De invoering van e-facturatie en de veralgemening ervan op nationaal grondgebied is geen eenvoudige stap. Het gaat veeleer om een geheel aan veranderingen en diverse processen. De confrontatie van standpunten en regelmatige uitwisseling maken het mogelijk tot een consensus te komen over een gemeenschappelijke en coherente aanpak. In dit kader, onder impuls van de Vlaamse overheid, werd een denkgroep ('de reflectiewerkgroep') opgericht. Deze structuur laat toe ervaringen te delen en zich ervan te verzekeren dat sleutelinformatie juist wordt overgebracht. Op dit ogenblik volstaat de denkgroep om deze rol te vervullen maar het is waarschijnlijk dat, nu de e-facturatie in opmars is, een stevigere structuur nodig is.

Financiële aspecten

De werking van Mercurius doet twee uitgaven ontstaan: de prestaties van de onderaannemer aan wie het operationele aspect van het platform wordt toevertrouwd en de omkadering van deze onderaannemer. 

De prestaties van de onderaannemer vloeien voort uit de uitvoering van een opdracht afgesloten door de opdrachtencentrale. Deze formule laat de cofinanciering van de operationele aspecten toe. Vandaag draagt BOSA DTO de gezamenlijke kosten voor de operationele aspecten. Op korte of lange termijn zullen deze kosten worden verdeeld over de instellingen die van de dienst gebruikmaken, a rato van verdeelsleutels die gebaseerd zullen zijn op de respectieve volumes. De details van deze verdeling moeten nog gedefinieerd worden.

BOSA DTO staat in voor de omkadering van de onderaannemer met zijn eigen budgetten (verwant personeel en verwante opdrachten, bv. tests die het risico op indringing en onttrekking moeten nagaan).

Stromen en componenten

Het artikel De levenscyclus van een e-factuur aan de Belgische overheidssector omschrijft de stappen bij de verwerking van een e-factuur. Dit hoofdstuk vervolledigt die omschrijving, vanuit het standpunt van de overheidssector (* ). Ze (a) bespreekt in detail de informatiestromen die verband houden met de dienst voor het overmaken van e-facturen B2G, alsook de componenten die deze stromen toelaten, (b) geeft een technische inleiding tot deze componenten, en (c) kadert de rol van het netwerk van de dienstintegratoren, die een sleutelrol spelen in dit dossier. De stromen zijn: (1) ontvangst van een e-factuur (of e-creditnota) en (2) terugsturen van een antwoord.

(* ) de gedetailleerde voorstelling van de aspecten die eigen zijn aan de privésector wordt behandeld in het artikel Mercurius voor de privésector.

1. Ontvangst van een document (e-factuur, e-creditnota, bijlage)

2. Terugsturen van een antwoord

Mercurius Web Service

Zoals geïllustreerd in vorig hoofdstuk biedt Mercurius een dienst aan die de aanbestedende overheidsdiensten toelaat hun e-facturen (en e-creditnota's en bijlagen) volledig elektronisch te ontvangen, en de resultaten van de goedkeuring van deze documenten over te maken.

Deze afdeling omschrijft de kenmerken van deze dienst. In de praktijk wordt deze dienst aangeboden door de integratoren. Dit aspect zal verderop meer gedetailleerd worden behandeld in de afdeling "integratoren".

Tot slot vervolledigt een Portaal deze dienst, waarmee de vertegenwoordigers van de klant (en van de leverancier) de voortgang van het overmaken en de technische verwerking kunnen volgen. Dit aspect wordt behandeld in een afzonderlijke pagina.

Protocol:

SOAP ( XML over HTTPS ) + WS-Security

De pertinente bijkomende technische specificaties kunnen verschillen per integrator en zijn dus bij laatstgenoemde beschikbaar, zie ook de afdeling "integratoren".

Hoe Mercurius de interacties van zijn klanten ondersteunt

Elke klant beschikt over een postvak voor binnenkomende post op Mercurius. Mercurius plaatst daar alle e-facturen, e-creditnota's en bijlagen m.b.t. deze documenten, naarmate ze binnenkomen. Om e-facturen op Mercurius te ontvangen moet men dus de klant registreren op Mercurius, waardoor voor hem een "postvak voor binnenkomende post" wordt aangemaakt. De afdeling "Ondersteuning en begeleiding" legt uit hoe de registratie van een nieuwe klant op Mercurius verloopt. Zodra de klant geregistreerd is, kan hij de dienst gebruiken. De dienst maakt het mogelijk (a) binnenkomende post binnen te halen en (b) antwoorden te versturen die het resultaat zijn van de verwerking van de e-facturen en e-creditnota's.

a. Binnenkomende post ophalen

Post binnenhalen vereist 3 verrichtingen:

• submitInboxRequest: laat toe de lijst met nieuwe documenten te raadplegen die wachten om te worden binnengehaald
• retrieveDocument: laat toe een document binnen te halen
• MarkDocument: laat toe te bevestigen dat het document werd binnengehaald.

In een klassiek scenario voor het gebruik van Mercurius zal de klant dus op regelmatige tijdstippen een sequentie van deze verrichtingen programmeren. (1°) de lijst met de nieuwe documenten raadplegen, (2°) voor elk nieuw document, (a) het document binnenhalen en (b) de goede ontvangst bevestigen en toestemming geven om het document te verwijderen uit de lijst van documenten in de wachtrij.

De documenten die vandaag worden ondersteund zijn de volgende:

Opmerkingen
(* ) Bijkomende uitleg:

• Dit type document laat toe de bijlagen op te halen van e-facturen en e-creditnota's (ontvangst-PV, algemene voorwaarden, etc.) als een apart bestand en niet noodzakelijk gestructureerd (pdf, Excel of een ander bestandsformaat).
• Om historische redenen haalt Mercurius deze bestanden uit het PEPPOL BIS-document waarbij ze ingesloten waren (Base64Encoding), om ze vervolgens over te maken door ze te linken aan afzonderlijke XML-documenten (van het type AttachedDocument), met vermelding van het ID van het parent-Document. Voor meer informatie kunt u (a) de XSD raadplegen van dit documenttype en de FAQ over AttachedDocument (TO DO: deze FAQ maken).
• Het overmaken van de eigenlijke bestanden maakt gebruik van het protocol SOAP with Attachment. 

(**) De afzenders maken e-documenten over in overeenstemming met deze formaatspecificaties. Deze specificatie gebruikt de syntaxis UBL2.1. Om historische redenen zet Mercurius ze om in UBL2.0. Behalve deze omzetting voert Mercurius geen andere transformatie uit. Deze documenten voor formaatspecificatie definiëren dus wel degelijk de respectieve semantiek van deze documenten. Meer informatie over het interoperabiliteitskader PEPPOL is beschikbaar op de volgende pagina: officiële pagina van de Belgische PEPPOL-autoriteit (EN).

2. Sturen van een antwoord

Deze actie vereist slechts een verrichting: submitApplicationResponse

Slechts 1 type document wordt op dit ogenblik ondersteund:

Opmerking 
(* ) Om historische redenen is de opmaak van het antwoord onderworpen aan een interne specificatie, en niet aan de specificatie van PEPPOL BIS, zoals dat het geval is voor de binnenkomende stromen. Mercurius zet het antwoord overgemaakt door de klant om in een document dat in overeenstemming is met de toepasselijke PEPPOL-specificatie, d.w.z. PEPPOL BIS 36A Message Level Response (EN) Dit wordt meer gedetailleerd uitgelegd op de pagina over de privésector.

Bijzondere scenario's

Dit hoofdstuk gaat dieper in op verschillende bijzondere gevallen en hoe die worden ondersteund door Mercurius.

Mercurius Business Pre-Processing

Mercurius omvat een component die elk e-document valideert (binnenkomend EN uitgaand) vanuit het standpunt business, d.w.z. dat het bepaalde kenmerken controleert van de inhoud van het document. Als de inhoud ergens een inbreuk op deze valideringsregels bevat, dan verwerpt Mercurius het e-document in naam van de eindontvanger. De ontvanger wordt niet van deze verwerping op de hoogte gesteld. De afzender ontvangt wel een antwoord dat hem op de hoogte brengt van de verwerping en van de motivering daarvoor (de aanmaak van het antwoorddocument volgt de modaliteiten omschreven in paragraaf "b. Sturen van een antwoord" van de afdeling Mercurius webdienst.

De volgende controles worden uitgevoerd:

• Duplicaat: als Mercurius al dezelfde combinatie DocumentID-DocTypeID-SenderID-ReceiverID heeft ontvangen, dan wordt het e-document beschouwd als een duplicaat en verworpen (* ). Het oorspronkelijke e-document kan altijd opgehaald worden.
• Uitgiftedatum in de toekomst. (* )
• DocumentID is langer dan 250 tekens
• DocumentID bevat speciale tekens (d.w.z. dat ze niet in de ASCII 7 bitstabel staan)

(* ) deze verwerping wordt gerechtvaardigd door de boekhoudkundige verplichtingen waaraan de uitgifte van een factuur volgens de regels van de kunst is onderworpen.
Opmerking: het Mercuriusportaal laat toe dat alle portaalgebruikers die toegang hebben tot het e-document deze verwerping kunnen vaststellen en kennis kunnen nemen van de motivering. Voor meer informatie over het Mercuriusportaal kunt u terecht op de pagina Mercuriusportaal hulp. 

Omzetten in pdf

Mercurius omvat een component die een e-factuur in pdf-document omzet en die per e-mail overmaakt kan worden aan een vooraf geconfigureerd mailadres.  Deze component werd toegevoegd met een dubbel doel:

• de communicatie van de overheidsdiensten vergemakkelijken: het is immers erg moeilijk om uit te leggen aan de leverancier dat de ene instelling klaar is, de andere pas over 3 maanden, nog een andere over 6 maanden, etc. Dankzij de omzetting in pdf kan een geheel van instellingen, idealiter de volledige overheidssector, overgaan tot de ontvangst van e-facturen in een enkele stap. Vervolgens kan elke instelling zijn eigen informaticaproject tot een goed einde brengen en is die er zo van verzekerd dat ze vanaf de eerste dag e-facturen kan ontvangen.
• vermijden dat de afzenders worden bestraft: elke leverancier die de inspanning heeft gedaan de aanbevelingen van de administratie op te volgen hoopt immers dat zijn investering ook binnen een redelijke termijn opbrengt. Dankzij de omzetting in pdf kan hij onmiddellijk zijn nieuw systeem gebruiken om e-facturen over te maken aan een groter aantal gesprekspartners. Deze aanpak doorbreekt de huidige vicieuze cirkel waardoor iedereen zijn beslissing uitstelt om over te gaan tot e-facturatie.

Vervallen e-documenten

In het geval dat een e-document niet werd binnengehaald door de ontvanger na 30 kalenderdagen zal het Mercuriusplatform:

• het e-document als vervallen beschouwen;
• het e-document verwijderen uit het postvak met de binnenkomende post van de ontvanger;
• een waarschuwing per e-mail sturen naar een dienstadres (te configureren in functie van de wensen van de klant) om hem op de hoogte te stellen dat het e-document vervallen is.

In het geval dat de klant het e-document wil reactiveren kan hij een aanvraag daartoe richten tot het Mercurius Support Team via het formulier aanvraag tot assistentie (zie verder, afdeling "ondersteuning")
Opmerking: naast de waarschuwingsmail laat het Mercuriusportaal alle portaalgebruikers die toegang hebben tot het e-document ook toe vast te stellen dat het e-document vervallen is. Voor meer informatie over het Mercuriusportaal kunt u terecht op de pagina Mercuriusportaal hulp.

Bewaarbeleid

Het Mercuriusplatform bewaart de ontvangen e-documenten en alle boodschappen die ermee verband houden gedurende 24 maanden. Daarna worden de sporen ervan gewist. Het is echter altijd mogelijk om toegang te krijgen in geval van een audit bij een geschil dat zich voordoet na 24 maanden, op expliciete aanvraag.

Identificatie van een klant: ondernemingsnummer

Om e-facturen te ontvangen op Mercurius moet men zich vooraf als klant registreren op Mercurius. Deze registratie maakt een "postvak voor binnenkomende post" aan. Deze registratie vereist het gebruik van een identifier. Behoudens uitzonderingen identificeert de klant zich met zijn registratienummer in de Kruispuntbank van Ondernemingen. Voorbeeld: FOD BOSA: 0671.516.647.

De klant die geen eigen ondernemingsnummer heeft kan zich identificeren met een andere identifier. Op dit ogenblik wordt het GLN-nummer gebruikt. Het aanleveren van deze identifier gebeurt door de klant.

Ondersteuning en begeleiding

De werking van Mercurius levert twee types van operationele activiteiten op: (a) ondersteuning van dag tot dag en (b) begeleiding van de klanten bij hun e-facturatieproject.

In de 2 gevallen, en behoudens bijzondere omstandigheden, moeten de aanvragen tot ondersteuning worden overgemaakt door gebruik te maken van het assistentieformulier, gepubliceerd op de onthaalpagina van het Mercuriusportaal (rechtstreeks adres: aanvraag tot assistentie).

Dagdagelijkse ondersteuning

De ondersteuning wordt als volgt georganiseerd:

1. raadpleeg eerst de informatie die werd gepubliceerd op deze pagina's. BOSA DTO heeft vele uren werk geïnvesteerd in het verzamelen, structureren, organiseren en vertalen van deze informatiedatabase. Het is heel waarschijnlijk dat uw vraag ergens wordt behandeld.
2. als u het antwoord niet hebt gevonden, dan vult u een aanvraag tot assistentie in. Er wordt ten zeerste aangeraden om u te identificeren. Dat laat toe bepaalde informatie vooraf in te vullen, wat (1) uw taak verlicht en (2) toelaat essentiële informatie te verzamelen voor een doeltreffende en kwaliteitsvolle ondersteuning.
3. Onze Service Desk ontvangt uw aanvraag. Onze Service Desk behandelt alleen vragen die frequent worden gesteld. Als u in voldoende mate kennis hebt genomen van de online-documentatie is het weinig waarschijnlijk dat de medewerkers u zullen kunnen helpen. In dat geval zullen ze uw aanvraag overmaken aan het Mercurius Support Team.
4. Dat team zal uw vraag/probleem behandelen, waarover het ook gaat, door een beroep te doen op de specifieke kennis en de contacten met alle actoren betrokken bij e-facturatie waarover het beschikt.

Begeleiding van de klanten bij hun e-facturatieproject

De inkoopverantwoordelijken en/of de informaticateams betrokken bij het invoeren van e-facturatie krijgen begeleiding bij hun project. Deze begeleiding kan meerdere aspecten dekken: 

• strategische uitdagingen van het project, hulp bij fundamentele beslissingen (technische en andere)
• technische integratie met het eigenlijke Mercuriusplatform
• het bijhouden van de laatste technologische vernieuwingen en evolutief onderhoud

De begeleiding kan dus starten vóór de technische integratiefase, en zal ook daarna worden voortgezet.

Strategische uitdagingen:

Het invoeren van e-facturatie is niet louter een punctueel technisch project. Het moet veeleer worden gezien als een diepgaande transformatie van lange adem, waarschijnlijk met verschillende stappen. BOSA DTO voert een programma om de overheidsdiensten bewust te maken van deze problematiek. BOSA DTO is beschikbaar voor ontmoetingen om samen de context van de instelling (of instellingengroepering) te bestuderen, en deel te nemen aan de opmaak van de strategie of het actieplan van de instelling. Uiteraard blijft instelling soeverein bij het maken van haar analyse en nemen van haar beslissing. Het is echter erg belangrijk dat ze zo goed mogelijk wordt geïnformeerd. Omdat e-facturatie nog niet voldoende is ontwikkeld, is de informatie erover niet zo eenvoudig beschikbaar, spreken sommige elementen elkaar tegen en zijn die uiteindelijk onvoldoende. In het bijzonder de bijdrage van het PEPPOL-kader wordt ruim misbegrepen; op dezelfde manier worden bepaalde functies van het Mercuriusplatform soms slecht gebruikt omdat men de mogelijkheden ervan niet kent. Deze documentatie wil iets aan deze situatie doen, ter aanvulling van de ontmoetingen binnen de overheidsdiensten.

Samenvattend is de doelstelling van deze ontmoetingen dat de instelling een duidelijk zicht krijgt op de uitdagingen, op de oplossingen die binnen haar bereik liggen, en zo een actieplan kan opstellen. Als voorbeeld zou men op de volgende vragen een antwoord moeten krijgen:

• Wat zijn de grote stappen van mijn project?
• Hoe vereenvoudigt de aangeboden oplossing de uitgifte en ontvangst van e-documenten (→ kosten doen dalen)
• Moet ik de omzetting in pdf gebruiken? Wanneer?
• Welke promotiemaatregelen ten aanzien van mijn leveranciers kan/moet ik nemen?
• (te vervolledigen)

Technische integratie met het Mercuriusplatform

Eens de beslissing is genomen om te integreren met het Mercuriusplatform wordt het technische project opgestart.

1. de gegevensstromen begrijpen, de verrichtingen die ze mogelijk maken, en ze op één lijn brengen met het eigen systeem voor de ontvangst van facturen.
2. de ontwikkelingen opstarten die de integratie van het boekhoudsysteem en Mercurius mogelijk zullen maken
3. parallel daarmee,
   1. configuratie van de integratie-omgeving van de integrator: contact opnemen met de integrator en toegang krijgen tot de Mercuriusdienst in testomgeving/integratie-omgeving. Zie ook de afdeling "integratoren".
   2. configuratie, in de testomgeving van Mercurius, van een klant (of meerdere klanten): de verantwoordelijke moet een aanvraag sturen via het formulier aanvraag tot assistentie en verduidelijken wat (1°) het nummer van de onderneming is of de nummers van de ondernemingen zijn en hoe de benamingen luiden en (2°) wat de Common Name (CN) is van het certificaat van het systeem dat de FSB zal aanroepen.
4. Zodra de ontwikkelingen voldoende gevorderd zijn en de voornoemde configuraties actief zijn kunnen er tests online worden ondernomen.
   1. Bijkomende informatie betreffende de testomgeving en testtools is op aanvraag via het formulier aanvraag tot assistentie beschikbaar.
   2. Mercurius is op een zo'n manier uitgerust dat de correspondenten op een heel autonome manier tests kunnen uitvoeren, met inbegrip van tests van het begin tot het einde met de pilootleveranciers. Geen enkele specifieke activiteit van BOSA DTO wordt dan ook in deze fase voorzien. Uiteraard zal het Mercurius Support Team de verzoeken met support issues opgestart in dit kader behandelen. BOSA DTO kan ook deelnemen aan het op punt stellen van deze activiteiten als dat nodig is, bijvoorbeeld om uit te leggen hoe de beschikbare tools werken.
5. Zodra de resultaten van de tests online bevredigend zijn, kan de go-live plaatsvinden. Dat impliceert doorgaans (a) een configuratie van de productie-omgeving van de integrator en (b) een configuratie van de productie-omgeving in Mercurius. Deze twee configuraties verlopen volgens het model van de stappen 3a en 3b die eerder werden omschreven.

Parallel met het technische project, en om ervoor te zorgen dat de inspanningen daarvan lonen, is het essentieel dat de instelling een project ontwikkelt voor de sensibilisering van haar leveranciers voor het versturen van elektronische facturen. Op dit ogenblik bestaat er geen communicatiemodel dat voldoende generiek en herbruikbaar is om aan de instellingen te worden overgemaakt met het oog op hergebruik voor deze stap. BOSA DTO staat ter beschikking van de instellingen om ze te begeleiden bij hun communicatie-activiteiten.
Opmerkingen:

• In het geval dat de instelling een beroep doet op een onderaannemer voor de technische ontwikkeling en/of activiteiten kan BOSA DTO de technische aspecten en procedure rechtstreeks met de onderaannemer behandelen.
• In het geval dat de integrator nog niet in staat is om de Mercuriusdienst aan te bieden is het mogelijk zich tijdelijk te richten tot de federale integrator (FSB).
• Wanneer de instelling al e-facturen ontvangt en zich die laat overmaken met omzetting naar pdf, dan wordt ze verzocht dit te preciseren in haar aanvragen tot configuratie van Mercurius (test/productie).

Het bijhouden van de laatste technologische vernieuwingen en evolutief onderhoud

Na de integratie van de instelling met Mercurius zullen er uitbreidings- en optimalisatiefases geprogrammeerd worden naarmate er nieuwe noden en opportuniteiten komen. Op basis van deze verzamelde noden programmeert BOSA DTO de wijzigingen van Mercurius die toelaten er een antwoord op te bieden en voert ze uit. Deze verbeteringen worden vervolgens beschikbaar gemaakt voor de instellingen.
De denkgroep (zie ook hoger, Gebruikersgroepen, denkgroepen) dient als platform voor het verzamelen van de noden van de instellingen, om prioriteiten van de aanvragen vast te stellen, en de roadmap te communiceren met de evolutie van Mercurius.

Tests

Het bestaan van de testomgeving van Mercurius vergemakkelijkt de integratiewerken van nieuwe instellingen en nieuwe economische actoren (leveranciers), en de ontwikkeling van nieuwe functies. Deze omgeving, die permanent beschikbaar is, is volledig in overeenstemming met de productie-omgeving (met inbegrip van de identifiers van de correspondenten en de toegangsmachtigingen tot gegevens). Dit laat de correspondenten toe om hun systemen op punt te zetten, volledig geïsoleerd van de productiestromen. De communicatie van de praktische informatie m.b.t. de testomgeving is inbegrepen in de begeleiding van de integratieprojecten van de instellingen met Mercurius.

Integratoren

De systemen van de klanten hebben toegang tot de Mercuriusdienst door de tussenkomst van dienstintegratoren. In overeenstemming met de bepalingen die de uitwisseling van gegevens binnen overheidsdiensten regelen, worden de Mercuriusdiensten aangeboden door de federale en regionale dienstenintegratoren, ten behoeve van hun respectievelijke beleidsniveaus.

a) Federale aanbestedende overheidsdiensten

Algemeen

Zoals geïllustreerd in het diagram vervult de Federal Service Bus (FSB) een dubbele rol: (1°) enerzijds zorgt het voor de verbinding tussen het informaticasysteem Mercurius en het netwerk van de integratoren. In dat kader vervult het een reeks essentiële functies inzake veiligheid en performantie ; (2°) anderzijds biedt het de Mercuriusdienst aan voor de federale aanbestedende overheden en de derden-integratoren van diensten. Alleen de tweede rol zal worden uiteengezet in het kader van dit artikel.

De algemene bepalingen van de FSB (ondertekening van een gebruiksovereenkomst, openen van stromen, gebruik van een certificaat, rapportering, integratie-omgeving, ondersteuning, etc.) zijn ook van toepassing op de Mercuriusdienst.

De FSB heeft een algemene omschrijving van zijn opdrachten, diensten, procedures, FAQ's en ondersteuningsmodaliteiten gepubliceerd op de volgende pagina:

Administratieve modaliteiten

In dit kader, en gelet op het feit dat de Mercuriusdienst toegang geeft tot de facturen van de betrokken partij, bestaat de enige vereiste administratieve verificatie om toegang te krijgen tot de dienst via de FSB erin te verzekeren dat de aanvrager wel degelijk een rechtspersoon is die onder Belgisch publiekrecht valt op federaal niveau.

Technische modaliteiten:

Om toegang te kunnen krijgen tot elke dienst die wordt aangeboden op de FSB zijn twee technisch-administratieve formaliteiten nodig: (1°) een certificaat genereren en overmaken en (2°) de toegang aanvragen aan de beoogde dienst(en)

1. Een certificaat genereren: deze stap vereist het gebruik van een tool voor het genereren van een certificaat (ten laste van de technische dienst van de aanvrager). Administratief moet er een klassieke administratieve procedure worden gevolgd die toelaat het certificaat met zekerheid te linken aan de entiteit die het zal gebruiken om zich te identificeren. Deze procedure wordt hier gedocumenteerd: Ik vraag een certificaat aan als FSB-gebruiker
2. De aanvraag tot toegang:
   1. voorafgaande opmerkingen:
      1. de aanvraag tot toegang gebeurt via het indienen van een Technical Connection Request Form
      2. zoals gepreciseerd is geen enkele Administrative Autorisation (AARF) vereist
      3. de naam van de dienst is e-InvoicingServices/CustomerService V2.00
      4. het is uiteraard nodig de toegang te vragen in INTEGRATIE want een ontwikkelings- en testcyclus is noodzakelijk
      5. verbindingsgegevens: niet van toepassing want de dienst is synchroon.
      6. certificaat: zodra de certificaten (integratie en productie) gegenereerd zijn maakt u de Common Name (CN) over in de TCRF. 
   2. link naar de procedure: Ik vraag toegang tot een bestaande FSB-webdienst.

b) Andere aanbestedende overheidsdiensten

• Brussels Hoofdstedelijk Gewest en daarmee verbonden lokale overheden: ISR/FIDUS
• Vlaamse Gemeenschap en daarmee verbonden lokale overheden: MAGDA/VSB
• Waals Gewest, Federatie Wallonië-Brussel en daarmee verbonden lokale overheden: BCED

Vlaamse Gemeenschap

Voor het Vlaams Gewest/de Vlaamse Gemeenschap vervult het platform MAGDA (MAximale GegevensDeling tussen Administraties) de rol van regionale integrator.
De volgende informatie is beschikbaar op de site van MAGDA:

• Hoofdpagina
• Aansluitingsproces MAGDA-diensten (ook van toepassing op Mercurius)
• Contactformulier MAGDA - algemene vragen
• Technische documentatie (MAGDA - Algemeen)

Brussels Hoofdstedelijk Gewest

In het Brussels Hoofdstedelijk Gewest vervult ISR/FIDUS de rol van regionale integrator. Voor alle informatie m.b.t. de toegang tot Mercurius voor dit beleidsniveau kunt u de volgende pagina raadplegen: FIDUS homepage         NL: FIDUS homepage

Waals Gewest en Federatie Wallonië-Brussel

In het Waals Gewest vervult BCED de rol van regionale integrator. Op dit ogenblik biedt BCED de diensten van Mercurius nog niet aan. Gelieve uw contactpersoon bij BCED te contacteren, of in voorkomend geval, uw informaticadienst.