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.
...
| Table of Contents | ||||
|---|---|---|---|---|
|
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..
...
Stromen en componenten | Stappen |
| Voorafgaand: de leverancier heeft een uitgaande factuur voorbereid in zijn eigen facturatie-omgeving. Stappen:
Resultaat: de e-factuur werd verzonden naar de klant. Ze wordt binnengehaald uit het "postvak in" van 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 de uitwisseling via het Mercuriusportaal. 1a: de leverancier die niet in staat is om zijn e-factuur te verzenden via PEPPOL kan die e-factuur aanmaken met het formulier voor een nieuwe factuur op het Mercuriusportaal (als het gaat om een redelijk eenvoudige factuur) 1b: de leverancier die al verbinding heeft gemaakt tijdens de pilootfase en nog niet in staat is om zijn e-factuur via PEPPOL te verzenden kan zijn factuur verzenden met de pilootinterface (werkt tijdelijk nog maar verdwijnt op korte termijn) 3b: 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 dat wordt verzonden naar het adres van de klant dat vooraf werd geregistreerd in de configuratie. Het binnenhalen van de boodschappen in het "postvak in" via de Mercuriusdienst vereist 3 verrichtingen (inbox request, retrieve document, mark document). Zie verder. |
...
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 deel van uitmaken.
...
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.
...
DocumentTypeName | syntaxis (XSD) | semantiek | |
1 | Factuur | PEPPOL Peppol BIS 4A Invoice | |
2 | CreditNota | PEPPOL Peppol BIS 5A BillingCredit Note |
De Belgische overheidssector volgt nog steeds strikt PEPPOL BIS. Alle documenten die aan BIS voldoen worden gegarandeerd ontvangen.
...
DocumentTypeName | UBL DocumentTypeCode | syntaxis (XSD) | semantiek | |
1 | Message Level Response | 301 |
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.
...
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.
...
De bovenstaande omschrijving stemt overeen met de PEPPOL BIS 36A Message Level Response (EN).
Bijzondere scenario's
| Anchor | ||||
|---|---|---|---|---|
|
...
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.
...
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.
...
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.
...
- 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.
...
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.
...
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
...
- 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.
- Als u het antwoord op uw vraag niet kunt vinden, dan vult u de aanvraag tot ondersteuning in.
- Die is ook beschikbaar op de homepagina van het Mercuriusportaal.
- 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.
- 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.
- 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.