Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Mercurius voor de overheidssector (G)

...


WORK IN PROGRESS - Some links may not work properly - Thank you for your comprehension.

...



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:

...

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.

...

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.

...

Stromen en componenten

Het artikel De levenscyclus van een elektronische factuur verstuurd naar de Belgische overheidssector omschrijft de stappen bij de verwerking van een e-factuur. Dit hoofdstuk vervolledigt die omschrijving, vanuit het standpunt van de overheidssector (star). 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.
(star) de gedetailleerde voorstelling van de aspecten die eigen zijn aan de privésector wordt behandeld in het artikel Mercurius voor de privésector (B)

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

Stromen en componenten

Sequentie


Legenda:
FAS Federal Authentication Service (om de authenticiteit van personen te controleren wanneer ze verbinding maken met diensten op Mercurius)

Voorafgaand: de leverancier heeft een uitgaande factuur voorbereid in zijn eigen boekhoudsysteem
Stappen:

  1. de leverancier verstuurt de e-factuur via PEPPOL. Zie ook Stap 1: de leverancier stuurt zijn e-factuur naar de klant
  2. Mercurius haalt de e-factuur binnen en plaatst ze in de "binnenkomende post" van de klant. Zie ook Stap 2: Mercurius ontvangt de e-factuur (voor de klant)
  3. de klant maakt gebruik van de Mercuriusdienst die wordt aangeboden door zijn integrator om zijn binnenkomende post binnen te halen. Zie ook Stap 4: wanneer hem dit uitkomt, haalt de klant zijn berichten op uit zijn inbox
  4. de integrator maakt verbinding met Mercurius, haalt de e-factuur binnen voor de klant en maakt die aan hem over.

    Resultaat: de e-factuur wordt overgemaakt aan de klant. Ze wordt verwijderd uit de binnenkomende post van de klant op Mercurius. Ze blijft zichtbaar op het Mercuriusportaal.
    Opmerkingen:
    5: op elk ogenblik kunnen de leverancier, de klant en alle actoren betrokken bij de uitwisseling de voortgang controleren van het overmaken via het Mercuriusportaal
    1a: de leverancier die niet in staat is om zijn e-factuur over te maken op PEPPOL kan die ingeven op het Mercuriusportaal (voor zover het gaat om een redelijk eenvoudige factuur)
    1b: de leverancier die heeft deelgenomen aan de pilootfase en die nog niet in staat is om zijn e-factuur met PEPPOL over te maken kan zijn e-factuur (tijdelijk) overmaken met de pilootinterface
    3c: de klant is nog niet in staat om e-facturen te ontvangen. In dat geval zet Mercurius de e-factuur om in een pdf-document en maakt het die over aan een e-mailadres dat vooraf werd geregistreerd in de configuratie. Zie verder (Omzetten in pdf)
    Het verzamelen van de binnenkomende post via de Mercuriusdienst vereist 3 verrichtingen (inbox request, retrieve document, mark document).  Zie verder.

...

Stromen en componenten

Sequentie

Voorafgaand: de klant is overgegaan tot de goedkeuring (of verwerping) van de factuur in zijn eigen boekhoudsysteem - zie ook Stap 5: de klant verwerkt de factuur.
Stappen:

  1. de klant maakt gebruik van de Mercuriusdienst die wordt aangeboden door zijn integrator en maakt zijn antwoord over; zie ook Stap 6: de klant bereidt een antwoord op de factuur voor en maakt dat over aan Mercurius
  2. de integrator maakt verbinding met Mercurius, en maakt het antwoord van de klant over.
  3. Mercurius verstuurt het antwoord via PEPPOL; zie ook Stap 7: Mercurius stuurt het antwoord naar de leverancier
  4. de leverancier haalt het antwoord binnen via zijn Access Point (AP), volgens de modaliteiten die specifiek zijn voor hem en die de afzender onbekend zijn, wie hij ook is.

    Resultaat: het antwoord is overgemaakt aan de leverancier.
    Opmerkingen:
    5: De status van de e-factuur (ontvangen / goedgekeurd / verworpen) en de details van die status (motivering) kunnen geraadpleegd worden op het Mercuriusportaal. Op elk ogenblik kunnen de leverancier, de klant en alle actoren betrokken bij de uitwisseling er ook de voortgang controleren van het overmaken via het Mercuriusportaal.
    1a: krachtens de akkoorden die de dienstintegrators binnen de overheidsdiensten regelen, richt elke aanbestedende overheidsdienst zich tot zijn referentie-integrator. Zie verder.
    3a: de leverancier die zijn e-factuur via PEPPOL heeft verstuurd, is niet altijd in staat om het antwoord via PEPPOL te ontvangen. In dat geval stuurt Mercurius hem een antwoord via e-mail, volgens de modaliteiten die hierna worden omschreven: Stap 7: Mercurius stuurt het antwoord naar de leverancier
    3b/4b: de leverancier die heeft deelgenomen aan de pilootfase en die blijft gebruiken ontvangt zijn antwoord (tijdelijk) via die interface

...

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:

...


Document Type Naam

UBL DocumentTypeCode

XSD

formaat specificatie

bijkomende informatie

1

Factuur

380

UBL-Invoice-2.0.xsd(star)

PEPPOL BIS 4A Invoice (***)

 


2

CreditNota

81

UBL-CreditNote-2.0.xsd(star)

PEPPOL BIS 5A Billing (***)

 


3

Bijlage (**)

916

UBL-AttachedDocument-2.0.xsd(star)

N.A. (**)

FAQ toevoegen

Opmerkingen
(star) syntaxis: UBL 2.0
(**) Bijkomende uitleg:

...

(***) 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:

...


Document Type Naam

UBL DocumentTypeCode

XSD

specificatie

1

ApplicationResponse

301

UBL-ApplicationResponse-2.0.xsd

 ePRIOR_FAQ20_Application_Response.doc (star)

Opmerking 
(star) 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 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:

...

(star) 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 help

...

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.

...

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.

...

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

...

  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.

...

  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 beschikbaar:
      1. Hoe kan men testfacturen overmaken aan zichzelf (via Mercurius)? (EN)
      2. Kan ik de geldigheid van mijn testfactuur nagaan vooraleer ze wordt verstuurd? (EN)
      3. Hoe kan ik controleren of mijn testfactuur goed is aangekomen (bij Mercurius en verder)? (EN)
    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.

...

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.

...

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

...

  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

ENGLISH [Expand]
Requestors must perform two parallel actions: (1) generate a certificate and (2) request access to the service 

  1. Generate certificate: using the certificates generation procedure and tool (free of charges) 
    1. Preamble: this is a quite standard security procedure, using the services of a subcontractor (QuoVadis). Customer has to generate the ad-hoc security artefacts (keystore,  keys and Certificate Signing request(CSR)), and  upload the CSR to the self-service site for certificates generation; then he can download the certificate afterwards. However, to access this self-service site, he first needs to go through a procedure that identities him as the representative of the organization/person he is requesting a digital certificate for. This requires filling in and signing forms, involving the legal representative of the involved organization. More details in the procedure description.
    2. Procedure: 
  2. Request access to the service: 
    1. Remarks over TCRF fill in process: 
      • There is no administrative access request involved, so no AARF info to fill in
      • Name of the service:  e-InvoicingServices/CustomerService V2.00
      • securedEchoService [nb: all consumers have default access on this service. This service is important to test the FSB connectivity in a first phase. Therefore we recommend to start your integration works using this service. Use the business service only afterwards]
      • connection data: the service is synchronous so you don't have to fill in the Response information
      • certificate: please mention the certificate Common Name (CN) that you defined in the certificate generation procedure (see section "generate certificate")
    2. Procedure:

b) Andere aanbestedende overheidsdiensten

...

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:

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

...