Versions Compared

Key

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

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.

...

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.

...

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

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.

...


Document Type Naam

UBL DocumentTypeCode

syntax (XSD)

Formaat specificatieSemantic

Bijkomende informatie

1

Factuur

380

UBL-Invoice-2.01.xsd(* )

PEPPOL Peppol BIS 4A Invoice (***)


2

CreditNota

81

UBL-CreditNote-2.01.xsd(* )

PEPPOL Peppol BIS 5A BillingCredit Note (***)


3

Bijlage (**)

916

UBL-AttachedDocument-2.01.xsd(* )

N.A. (**)

FAQ toevoegen


Opmerkingen
(* ) syntaxis: UBL 2.0(**) 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).

...

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.

...

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:

...

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

...

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.

...

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

...

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.

...

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.

...

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

...