Dit artikel richt zich tot de vertegenwoordigers van de privésector die verantwoordelijk zijn voor de verzending van facturen naar Belgische overheidsinstellingen of betrokken zijn bij dergelijke projecten. Het gaat bijvoorbeeld om facturatieverantwoordelijken, IT-teams die financiële departementen ondersteunen, externe IT-dienstverleners en/of softwareleveranciers of iedereen betrokken bij uitgaande e-facturatie.

Zoals werd uitgelegd in De e-facturatiestrategie van de Belgische overheidssector vervult het Mercuriusplatform de rol van gecentraliseerde elektronische mailroomdienst voor de Belgische overheidssector in het kader van de e-facturatie B2G.

Dit artikel gaat een stap verder door te focussen op de verschillende onderdelen van het Mercuriusplatform zoals die worden gezien vanuit het standpunt van de privésector, verzender van de e-facturen.

Het bespreekt de voornaamste elementen waar dergelijke belanghebbenden zich bewust van moeten zijn zoals een algemene omschrijving, de voornaamste stromen, de procedures voor de onboarding, etc... Bijzondere scenario's worden gedetailleerd uitgelegd in aparte artikels. Onderwerpen die gemeenschappelijk zijn met de overheidssector worden ook uitgelegd in afzonderlijke artikels (bijvoorbeeld: gebruik van het Mercuriusportaal). Verwijzingen naar deze verwante artikels en andere relevante informatie worden op de gepaste plaatsen in dit artikel vermeld.

Dit artikel bestaat uit de volgende paragrafen:

Wettelijke achtergrond

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. Daarmee werden de voorwaarden gecreëerd voor de bredere toepassing van e-facturatie.

Richtlijn 2014/55/EU van het Europees Parlement en de Raad van 16 april 2014 verplicht alle Europese overheidsdiensten elektronische facturen, die voldoen aan de Europese Norm EN16931, te aanvaarden en te verwerken. Dit wordt momenteel omgezet in de Belgische wetgeving..

Bijkomend hebben de Belgische federale en regionale ministerraden al beslist om e-facturatie B2G te verplichten. Deze beslissingen worden geleidelijk omgezet in wetgevende, technische en promotionele acties door de respectievelijke overheidsinstellingen.
Mercurius is het resultaat van verschillende van deze acties. Zoals eerder werd uitgelegd maakt deze gecentraliseerde elektronische mailroomdienst voor de overheidssector het aanzienlijk gemakkelijker voor de privésector om al hun overheidsklanten consistent en kosteneffectief te bereiken.

Financiële aspecten

De oplossing van de Belgische overheidssector om e-facturen van hun leveranciers te ontvangen, een oplossing die gebaseerd is op Peppol en Mercurius, werd ontworpen om de kosten op lange termijn voor de verzenders te minimaliseren. Op korte termijn is het niet onmogelijk dat verzenders kosten zullen hebben wegens het gebrek aan concurrentie op de markt met oplossingen of wegens tekortkomingen veroorzaakt door problemen die verband houden met onvoldoende ontwikkelde toepassingen, veeleer dan dat het gaat om werkelijke en niet-samendrukbare kosten. Men dient rekening te houden met de volgende aspecten:

• de oplossing maakt het mogelijk alle Belgische overheidsinstellingen te bereiken. Vandaag nemen de federale regering en de Vlaamse regering het voortouw, maar de bedoeling is heel duidelijk dat een oplossing wordt aangeboden die ook de andere gewestniveaus dekt, alsook de lokale overheden en alle andere mogelijke instellingen die onder publiekrecht vallen of in totaal 16 % van het Belgische bbp.
• de oplossing werd ontworpen om herbruikbaar te zijn zodat ook alle instellingen van de Belgische privésector bereikt kunnen worden. De overheid onderneemt veel acties om dit potentieel werkelijkheid te laten worden, in nauwe samenwerking met de vertegenwoordigers van de privésector.
• de oplossing is ook perfect herbruikbaar om buitenlandse klanten te bereiken, zowel in de overheids- als de privésector. Er vinden ook veel contacten op Europees niveau plaats om dit in praktijk te brengen.
• de oplossing zorgt voor een complete integratie van de nieuwe Europese Norm. Anders gezegd, de privésector heeft de garantie dat er geen plotse bocht van 180° komt wanneer de Europese Norm wordt geïntroduceerd in de strategie voor e-facturatie.
• het Mercuriusportaal biedt een oplossing voor leveranciers die nog niet in staat zijn de overstap te maken naar echte uitgaande e-facturatie, om welke reden dan ook. Deze oplossing is volledig kosteloos en vereist geen administratieve lasten voor de meeste Belgische kleine en middelgrote ondernemingen. Alleen grotere structuren moeten misschien op de hoogte gesteld worden van het eGOV-systeem voor rollenmanagement. Dat is niet zo moeilijk te gebruiken maar kan aanvankelijk klinken als een bijkomende formaliteit.

Belgian Business Experts Group

Een Belgische e-Invoicing Experts Group werd opgericht in juni 2017. Het behandelt vragen als "hoe moet een factuur met contante korting worden uitgedrukt in het BIS-formaat", "wat maakt een factuurnummer uniek", "hoe om te gaan met de veelheid van identificatieschema's ", .... Het is een ontmoetingsplaats voor verschillende groepen, waarbij elke groep zijn eigen perspectief en zorgen heeft. De confrontatie van deze gezichtspunten in een constructieve mindset, versnelt de veralgemening van e-facturatie.

Business Experts uit alle hoeken van het Belgische facturatielandschap, ondersteund door technische experts, nemen deel aan deze gezamenlijke inspanning. De Vereniging van Belgische Ondernemingen biedt de faciliteiten die de groep nodig heeft (logistieke ondersteuning, extranet, moderatie, ...).

Stromen en componenten

Het artikel De levenscyclus van een e-factuur aan de Belgische overheidssector legt de stromen uit bij de verwerking van een e-factuur. Dit hoofdstuk geeft meer details bij deze omschrijving, vanuit het standpunt van de privésector (business).  Het (a) legt de gegevensstromen uit die verband houden met het uitwisselen van diensten m.b.t. e-facturen en de componenten die nodig zijn om de stroom operationeel te maken, (b) geeft een technische inleiding tot deze componenten en (c) kadert de beslissende rol van een netwerk van dienstverleners, toegangspunten en software-oplossingen die handelen in deze context. De voornaamste stromen zijn (1) een e-factuur (of e-creditnota) verzenden en (2) een antwoord ontvangen.
Gedetailleerde informatie over specifieke aspecten m.b.t. de overheidssector kunt u vinden op Mercurius voor de overheidssector.

1. Een e-factuur/e-creditnota verzenden

2. Een antwoord ontvangen

Documentformaten

Het voorgaande hoofdstuk toont de stroom van de e-documenten tussen correspondenten. Dit hoofdstuk geeft nuttige uitleg bij de formaatvereisten die van toepassing zijn op deze e-documenten. Het is erg belangrijk dat men zich ervan bewust is, op voldoende gedetailleerde wijze, hoe formaten de uitwisseling tussen correspondenten kunnen beïnvloeden.

Voorafgaand

De uitwisseling van elektronische documenten vereist typisch dat de verzender en de ontvanger een uitwisselingsformaat overeenkomen - voor elk type document dat dient te worden uitgewisseld. Dit is een conditio sine qua non voor de IT-systemen van de beide correspondenten zodat zij elkaar "luid en duidelijk" kunnen verstaan en zonder problemen kunnen samenwerken.

Een formaat behelst twee basisaspecten: (a) de semantiek: het document bestaat uit informatie-elementen die op een dergelijke manier worden omschreven dat interpretatiefouten uitgesloten worden; (b) de syntaxis: deze gemeenschappelijke informatie-elementen worden vertaald in een syntaxis, een voorstelling van gegevens, die een IT-systeem kan lezen/schrijven/begrijpen. 
In 2011 heeft een beperkte maar representatieve groep actoren uit diverse milieus besloten om verschillende workshops te houden met als doel te komen tot een set sectoroverschrijdende en grensoverschrijdende formaten voor de meeste procurementdocumenten (catalogus, bestelling, antwoord op de bestelling, het verzenden van advies, factuur, creditnota, etc.). De CEN BII workshops (EN) hebben de CEN Business Interoperability Interface (BII) WorkGroup Agreements (WGA) opgeleverd, waar de CEN BII-formaten Peppol deel van uitmaken.

Ondertussen werden de CEN BII-reeksen hergebruikt door veel praktische eProcurement-oplossingen, in het bijzonder door (a) het ePRIOR-platform ontwikkeld door de Europese Commissie en (b) de Peppol Business Interoperability Specification (BIS). Peppol BIS vervult de rol van "gemeenschappelijk noemer-formaat", wat betekent dat als twee correspondenten geen gemeenschappelijk formaat kunnen identificeren om documenten uit te wisselen, ze "terugvallen" op het gebruik van PEPPOL BIS.

Tijdens een pilootfase (2013-14) waarin het ePRIOR-platform werd gebruikt, afgestemd op de Belgische context, valideerde de Belgische overheidssector dat de CEN BII documenttypes voor facturen en creditnota's, al hun specifieke informatienoden dekte.

Toen het Peppol -interoperabiliteitskader werd aangenomen waren er geen specifieke businessnoden die de ondersteuning van een ander formaat dan dat van de gemeenschappelijke noemer - BIS - rechtvaardigden.

Hoewel BIS niet het meest geavanceerde beschikbare formaat is, is het wel extreem goed gedocumenteerd en ondersteund door validatietools. Deze extra tools dragen zeker bij tot de kwaliteit van de uitwisselingen.

Om al deze redenen besloot de Belgische overheidssector alleen de BIS-formaten voor e-facturen en e-creditnota's te ondersteunen, althans voorlopig.

Uiteraard zal de Belgische overheidssector, ingevolge Richtlijn 2014/55/EU zijn systemen upgraden om ook de Europese Norm EN16931 (EN) te ondersteunen in de nabije toekomst. Merk daarbij op dat de EN 16931-vereisten ook een afstemming met CEN BII inhouden. Anders gezegd, het EN 16931-ontwerp integreert de migratie van CEN BII voor e-facturen en e-creditnota's.

Formaatspecificaties

uitgaande documenten (e-factuur, e-creditnota)

Zoals aangehaald hierboven ondersteund de Belgische overheidssector de volgende formaten: Peppol BIS voor e-facturen en Peppol BIS voor e-creditnota's. De volgende tabel is een samenvatting van de technische informatie die vereist is om documenten zo voor te bereiden dat ze gegarandeerd ontvangen kunnen worden door de Belgische overheidssector (maar, uiteraard, die niet noodzakelijk goedkeuren).

De Belgische overheidssector volgt nog steeds strikt Peppol BIS. Alle documenten die aan BIS voldoen worden gegarandeerd ontvangen.

binnenkomende documenten (business response)

In een correct geïmplementeerde operationele interactie voor e-facturatie verzendt de klant een antwoord naar de leverancier. Het Peppol -kader biedt nog geen geschikt documenttype, waarmee bedoeld wordt een formaat dat werd ontworpen om business responses te verzenden. Het Invoice Response-formaat zou heel binnenkort beschikbaar moeten worden. In tussentijd biedt Peppol een ander formaat aan, de Message Level Response (MLR). Dit formaat werd ontworpen om technische feedback te verzenden, maar kan worden gebruikt als alternatieve oplossing om business responses te verzenden. De Belgische overheidssector gebruikt deze alternatieve oplossing. Zodra het Invoice Response-formaat beschikbaar is, zal de Belgische overheid een scenario opstellen om de migratie zo vlot mogelijk te laten verlopen.

Het business response documenttype is nog niet beschikbaar, wat betekent dat er nog geen BIS-documenttype bestaat. Daarom heeft de Belgische overheidssector beslist het MLR-documenttype te gebruiken, tot er een geschikter documenttype beschikbaar is.

Opmerkingen:

• Om de business response te ontvangen zoals hierboven uitgelegd, moet de verzender van de e-factuur hebben verklaard dat hij in staat is MLR te ontvangen in de Peppol Transport Infrastructure. Zie de volgende afdeling.
• Message Level Response (MLR) is niet verplicht. De afdeling "Bijzondere scenario's" bevat ook aanvullende nuttige gedetailleerde informatie over de inhoud van de MLR.

E-documenten verzenden/ontvangen - belangrijke informatie

E-documenten verzenden

Het enige wat u nodig hebt om e-documenten te verzenden via Peppol is een Access Point (AP). Zoals geïllustreerd werd in het hoofdstuk Typische stroom van een e-factuur B2G hierboven, verloopt het verzenden van een e-document via Peppol zoals "een enveloppe in de postbus stoppen". Het enige wat u nodig hebt, is toegang tot een AP dat fungeert als een postbus.

U kunt uw eigen AP opzetten maar voor de meeste bedrijven is het efficiënter om een beroep te doen op de diensten van een gespecialiseerd bedrijf, een IT-dienstverlener. De meeste bedrijven die geen IT-bedrijven zijn zullen namelijk (a) hun uitgaande facturatiesoftware niet bedienen - dus een intern bediend AP opzetten zal wellicht niet eens helpen omdat u dan nog steeds een "plug" nodig hebt voor uw uitgaande facturatiesoftware - en (b) hebben niet de IT-vaardigheden om dit correct/kosteneffectief te doen - het is geen complex project maar, zoals in de meeste domeinen, zijn er wel gespecialiseerde vaardigheden nodig om het correct uit te voeren.

E-documenten ontvangen

Een van de sleutelaspecten van het Peppol -interoperabiliteitskader is dat u de technische details van elke ontvanger niet hoeft te kennen om in staat te zijn e-documenten te verzenden. Hoe is dat mogelijk?  Peppol heeft een register (* ) dat altijd actief is waarin alle bedrijven die e-documenten ontvangen worden geregistreerd. Dat register bevat twee types informatie (a) waar de e-documenten naartoe moeten worden verzonden - dat is eigenlijk het adres van het AP van de ontvanger (waarbij het "postsysteem" moet aangeven welke route het e-document moet volgen) - en (b) welk formaat moet worden gebruikt: alle ontvangers moeten alle formaten aangeven die ze kunnen ondersteunen (en dus lezen), zodat alle verzenders kunnen zien welk formaat kan worden gebruikt. Omdat alle deelnemers altijd in staat moeten zijn om BIS te verwerken is het onmogelijk dat twee deelnemers niet op zijn minst 1 gemeenschappelijk formaat vinden.

(* ) de exacte naam van dit register is SMP (Service Metadata Publisher). Het gaat in feite niet om 1 enkel groot register maar om een set van registers die dezelfde informatie op dezelfde manier publiceren zodat ze zich collectief gezien gedragen alsof het om 1 enkel register zou gaan.

Klanten ontvangen e-facturen en e-creditnota's

Alle bedrijven die binnenkomende e-facturatie implementeren zullen, zoals alle Belgische overheidsinstellingen, in dit register registreren dat ze in staat zijn e-facturen en e-creditnota's te ontvangen. De exacte omschrijving van de mogelijkheid om te ontvangen ziet er als volgt uit:

busdox-docid-qns::urn:oasis:names:specification:ubl:schema:xsd:Invoice-2::Invoice##urn:www.cenbii.eu:transaction:biitrns010:ver2.0:extended:urn:www.peppol.eu:bis:peppol5a:ver2.0::2.1

busdox-docid-qns::urn:oasis:names:specification:ubl:schema:xsd:Invoice-2::Invoice##urn:www.cenbii.eu:transaction:biitrns010:ver2.0:extended:urn:www.peppol.eu:bis:peppol4a:ver2.0::2.1

busdox-docid-qns::urn:oasis:names:specification:ubl:schema:xsd:CreditNote-2::CreditNote##urn:www.cenbii.eu:transaction:biitrns014:ver2.0:extended:urn:www.peppol.eu:bis:peppol5a:ver2.0::2.1

Zoals u kunt zien en verwachten in de context van e-facturatie zijn deze gegevens geschikt om automatisch te worden verwerkt, NIET om een gesprek te voeren tussen personen.

Leveranciers ontvangen een antwoord

Alle bedrijven die uitgaande e-facturatie implementeren worden, zoals de leveranciers van de Belgische overheidsinstellingen, uitgenodigd om in dit register te registreren in welke mate ze in staat zijn e-documenten te ontvangen. De exacte omschrijving van de mogelijkheid om te ontvangen ziet er als volgt uit: 

busdox-docid-qns::urn:oasis:names:specification:ubl:schema:xsd:ApplicationResponse-2::ApplicationResponse##urn:www.cenbii.eu:transaction:biitrns071:ver2.0:extended:urn:www.peppol.eu:bis:peppol36a:ver1.0::2.1

De bovenstaande omschrijving stemt overeen met de Peppol BIS 36A Message Level Response (EN).

Bijzondere scenario's

Deze afdeling gaat over verschillende bijzondere operationele en technische scenario's en legt uit hoe Mercurius daarmee omgaat.

Niet-naleving van het Peppol BIS-formaat

Elke e-factuur die in overeenstemming wordt geacht met het Peppol BIS-formaat, maar die de formatievalidatiestap niet doorstaat, wordt "gefilterd" door een component die is geïnstalleerd tussen de PEPPOL AP en Mercurius. Leveranciers (e-factuurafzenders) en hun IT-onderaannemers moeten er daarom voor zorgen dat alleen e-facturen die aan het Peppol BIS-formaat voldoen, worden verzonden.
Deze bepaling komt voort uit de volgende overwegingen:

• In de sectie Documentformaten kunnen leveranciers (of hun IT-onderaannemers) de documentformaatvereisten kennen die overheden aankunnen.
• In een context van wijdverbreide e-facturering is naleving van deze vereisten essentieel.
• Het Peppol -kader, dat de belangrijkste technische referentie vormt voor ons veralgemeningsprogramma voor e-facturering, pleit voor een bewezen aanpak die leidt tot de implementatie van hoogwaardige, op formaten gebaseerde stromen. Met name,
  • het Peppol BIS-formaat, het formaat dat wordt ondersteund door de Belgische publieke sector, is uitgerust met validatietools op basis van een veel gebruikte technologie (schematron), waardoor het mogelijk wordt de besturingselementen voor de conformiteit van het formaat te automatiseren.
  • standaardcontracten die exploitanten binden, verbieden de overdracht van niet-conforme documenten in het formaat dat zij geacht worden te respecteren. Niets verplicht de geadresseerde om dergelijke documenten te lezen.
• Daarom wordt elke e-factuur die geacht wordt in overeenstemming te zijn met het Peppol BIS-formaat maar die de formatievalidatiestap niet doorstaat, "gefilterd" door een component geïnstalleerd tussen de PEPPOL AP en Mercurius.
• afzenders (of hun IT-onderaannemers) kunnen de validatie van hun e-facturen volledig automatiseren VOORDAT ze worden verzonden, met behulp van dezelfde validatiehulpmiddelen als het bovenstaande filter, aangezien deze hulpmiddelen openbaar en kosteloos worden verspreid.
• Ten slotte is de Mercurius-Portal uitgerust met een online opzoekprogramma voor testberichten: de afzender (of zijn IT-onderaannemer) kan de e-factuur via Peppol verzenden in de testomgeving en vervolgens online controleren. als het bericht is aangekomen en niet is bedorven door een fout. deze tool vermijdt spreidingsfouten in de feitelijke facturatiestromen.

Business Response: inhoud van de MLR

Het antwoord dat wordt gegenereerd door de Belgische overheidssector bevat een response code, die een hogere betekenis aan het antwoord geeft. Het kan nuttig zijn dat de leveranciers, of hun IT-collega's of IT-leveranciers, deze codes begrijpen. Hierna volgt een tabel die deze informatie uitlegt:

Business response: de leverancier ondersteunt Peppol BIS MLR niet - zie diagram, sequentie 3a

Zoals uitgelegd in de vorige afdeling zal de leverancier het elektronische antwoord alleen ontvangen als hij heeft geregistreerd dat hij in staat is Peppol MLR te ontvangen. Als dat (nog) niet het geval is, dan zal (zoals stroom 3a in het diagram hierboven illustreert) Mercurius een alternatieve bezorgingsmethode voorzien: via e-mail. Mercurius zal in de oorspronkelijke e-factuur zoeken naar het e-mailadres van de leverancier en zal de antwoordinformatie van de MLR naar dit e-mailadres verzenden, in een formaat dat door mensen gelezen kan worden. Het e-mailadres wordt uit het volgende UBL-gegevenselement van de e-factuur gehaald:

           Invoice/AccountingSupplierParty/Contact/ElectronicMail

Als dit gegevenselement leeg is (of niet vermeld) in de oorspronkelijke e-factuur, dan kan er ook geen e-mail worden gestuurd. De enige manier waarop de leverancier het antwoord dan kan verifiëren, is door verificatie op het Mercuriusportaal. Voor meer informatie over het Mercuriusportaal kunt u de volgende pagina raadplegen: Mercuriusportaal hulppagina.

Mercurius Business Pre-Processing

Het Mercuriusplatform omvat een bijzondere component die elk document valideert (binnenkomend EN uitgaand) vanuit het business standpunt. Dat wil zeggen dat het bepaalde kenmerken controleert op inhoud van het document. Als de inhoud ergens een inbreuk op deze valideringsregels bevat, dan verwerpt Mercurius het 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 (het antwoorddocument).

De verificaties worden als volgt uitgevoerd:     

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

(* ) Deze verwerping wordt gerechtvaardigd door de boekhoudkundige verplichtingen waaraan de uitgifte van een factuur volgens de regels van de kunst is onderworpen.

Voor leveranciers zou deze Mercuriusdienst niet belangrijk moeten zijn. De ervaring leert echter dat veel leveranciers niet voldoen aan de business rules die worden geverifieerd tijdens deze validatie. Daarom moeten, in de praktijk, veel leveranciers in de toekomst toegang hebben tot deze informatie.

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

Tests uitvoeren

Omdat de veralgemening van e-facturatie en e-procurement een nieuw gegeven is, bestaat de legitieme behoefte om tests uit te voeren. Veel aspecten en onderdelen van de oplossingen (zowel in de overheids- als in de privésector) zijn echter relatief nieuw en dus is het vaak moeilijk om tests te organiseren/delicaat om ze te interpreteren. Daarom heeft de overheid sterk geïnvesteerd in een robuuste en gecontroleerde end-to-end testinfrastructuur. Dat maakt e-facturatie B2G testen eenvoudig. Bijkomend kunnen veel componenten van deze testinfrastructuur hergebruikt worden door instellingen uit de privésector, volledig kosteloos, om te verifiëren of hun gedeelte van de oplossing inderdaad volledig voldoet.

Informatie voor leveranciers

Als uw uitgaand facturatiesysteem een testomgeving heeft of in staat is om e-facturen te produceren om tests uit te voeren (wat betekent dat ze niet werkelijk geboekt worden) en voor de testomgeving van de klanten, dan hebt u alles wat u nodig hebt om testfacturen naar de overheidssector in test te verzenden.

Om testfacturen te verzenden naar de overheidssystemen in test:

• moet de verzendende AP opzoeken wat de ontvanger allemaal in staat is te ontvangen door gebruik te maken van de SMK in plaats van de SML.
  • SML staat voor Service Metadata Locator. Het is het gecentraliseerde systeem dat AP's die opzoeken wat de ontvanger allemaal in staat is te ontvangen omleidt naar de SMP van de ontvanger (zie ook "E-documenten verzenden/ontvangen - belangrijke informatie" hierboven).
  • de SMK is het alter ego van de SML, in de testinfrastructuur.
  • alle instellingen van de overheidssector worden geïdentificeerd met exact dezelfde identifiers in de echte omgeving (productie) en in de testomgeving. Dat gebeurt om het risico op verwarring van identificatienummers te minimaliseren.
• om snel de status van de verzending in de testomgeving te controleren is de volgende online tool beschikbaar via de homepagina van Mercurius: Test document opzoeken.
• op elk ogenblik kunt u ook alle ontvangen verkeer verifiëren, zowel in test als in productie, door het Mercuriusportaal te gebruiken. Voor meer gedetailleerde instructies over het gebruik van het Mercuriusportaal kunt u terecht op de pagina Mercuriusportaal hulppagina.

Bijkomende informatie voor de IT--sector

Vertegenwoordigers van de IT-sector kunnen tools gebruiken die beschikbaar zijn op het web om hun systemen te valideren. Er zijn veel tools online beschikbaar voor de validering van verschillende formaten en versies. Deze tools valideren het Peppol BIS-formaat, niet de inhoud ervan. Er wordt echter sterk aanbevolen de mogelijkheid om e-documenten in een geldig formaat te produceren apart te valideren, afzonderlijk van de inhoudelijke aspecten.

De sector van de IT-dienstverleners kan ook het Mercuriusportaal gebruiken om alle verkeer met Mercurius op te sporen en te volgen, dankzij de eGOV-rol "Mercurius_AP". Dit is van toepassing op het verkeer in zowel test als productie. Meer informatie hierover is beschikbaar in de procedure voor onboarding die wordt omschreven in de afdeling Access Points van de officiële pagina van de Belgische Peppol -autoriteit (EN). Deze pagina bevat ook veel nuttige informatie voor de IT-sector m.b.t. het uitvoeren van testactiviteiten en andere doeleinden.

Voor meer gedetailleerde instructies over het gebruik van het Mercuriusportaal kunt u tot slot ook terecht op de pagina Mercuriusportaal hulppagina.

Gebruikersassistentie en ondersteuning

Mercurius is een openbare dienst. Het wordt potentieel gebruikt door 50.000 leveranciers en 5.000 klanten of zelfs op nog grotere schaal, gelet op de rotatie van leveranciers in de overheidssector. Deze cijfers geven aan hoe groot de nood aan ondersteuning is. Een erg ruime waaier aan privé- en overheidsinstellingen komt in aanmerking om het platform te gebruiken, en om support issues in te dienen. Hier rekening mee houdend is het essentieel voor BOSA DTO om te verzekeren dat de ondersteuning voldoende reikwijdte heeft, voldoende beschreven wordt, goed georganiseerd is en ook daadwerkelijk gebruikt wordt.

Reikwijdte

De overheid voorziet assistentie voor bedrijven en overheidsinstellingen m.b.t. het gebruik van het Mercuriusplatform en -portaal.

Er wordt ook informatie voorzien om hen te helpen vertrouwd te geraken met het Peppol -interoperabiliteitskader. Deze assistentie is echter beperkt tot gemeenschappelijke kennis. De overheid heeft niet de opdracht geavanceerde technische ondersteuning te bieden aan personen die PEPPOL-oplossingen opzetten of in de handel brengen.

De overheid biedt wel bijkomende technische ondersteuning aan bedrijven uit de IT-sector die hun producten integreren met Mercurius via Peppol . Dit houdt ook het raadplegen en registreren van de ontvangstcapaciteiten in op smp.belgium.be (EN).

Organisatie

Voorafgaande opmerking voor leveranciers

Ook al wordt de e-factuur elektronisch verstuurd, het blijft in de eerste plaats nog steeds een factuur. U moet nog steeds uw vertegenwoordiger voor e-procurement bij de klant contacteren wanneer u vragen hebt over de verwerking van de factuur. Werd ze ontvangen? Werd ze goedgekeurd? Etc... Als er zich een technisch probleem stelt met de e-factuur dan zal uw vertegenwoordiger voor e-procurement in staat zijn uw vragen te beantwoorden, tenzij de e-factuur Mercurius niet heeft bereikt.

Als de e-factuur Mercurius niet heeft bereikt, dan zal er zich in de meeste situaties een probleem stellen met de verlener van uw IT-oplossing of Access Point (AP) (intern of extern) en moet dit met hem worden besproken (bv. ongeldig Peppol BIS formaat).

Nu dit verduidelijkt is, volgt hierna een omschrijving van de voorzieningen inzake assistentie en ondersteuning die de overheid levert.

1. Lees eerst de beschikbare informatie. BOSA DTO heeft vele uren werk geïnvesteerd in het verzamelen, structureren, organiseren en vertalen van de informatiedatabase. Het is heel waarschijnlijk dat uw vraag ergens wordt behandeld.
2. Als u het antwoord op uw vraag niet kunt vinden, dan vult u de aanvraag tot ondersteuning in.
   1. Die is ook beschikbaar op de homepagina van het Mercuriusportaal.
   2. We moedigen aan dat u zich identificeert op deze pagina zodat kostbare informatie kan worden verzameld die (1) uw taak gemakkelijker maakt en (2) toelaat essentiële informatie te verzamelen over rollenmanagement om de ondersteuning te vergemakkelijken en deze ondersteuning naar een hoger niveau te tillen.
3. Onze centrale service desk zal verzekeren dat de aanvraag tot ondersteuning correct geïdentificeerd wordt in de tool voor de follow-up van ondersteuning en uw aanvraag zo snel mogelijk behandelen. Zij zijn echter alleen verantwoordelijk voor het behandelen van frequent gestelde vragen. Als u niet vond wat u zocht in onze uitgebreide kennisdatabase, dan is het waarschijnlijk dat zij u niet zullen kunnen helpen. In dat geval wordt uw aanvraag overgemaakt aan het Mercurius Support Team.
4. Het Mercurius Support Team zal uw vraag beantwoorden en uw probleem behandelen. Het Mercurius Support Team behandelt alle aanvragen tot ondersteuning die overblijven. Zij zorgen voor de verdere analyse van het geval, valideren of het binnen de reikwijdte van de dienst valt en verzekeren dat het probleem tijdig wordt aangepakt en opgelost, of welk intern of extern team daar moet bij betrokken worden.