Der vorliegende Artikel richtet sich an Akteure im Privatsektor, die für den Versand von Rechnungen an belgische staatliche Stellen zuständig oder an solchen Projekten beteiligt sind, z. B.  Abrechnungsmitarbeiter, IT-Teams zur Unterstützung von Finanzabteilungen, externe IT-Dienstleister und/oder Softwareanbieter oder andere, die mit elektronischen Ausgangsrechnungen zu tun haben.

Wie in E-Fakturierungsstrategie des öffentlichen Sektors in Belgien erläutert, fungiert die Mercurius-Plattform als zentrale elektronische Poststelle für den öffentlichen Sektor in Belgien, wenn es um B2G-E-Rechnungsstellung geht.

Darüber hinaus geht es in dem Artikel auch um die einzelnen Teile der Mercurius-Plattform aus Sicht des Privatsektors als Absender von elektronischen Rechnungen.

Er befasst sich mit den wichtigsten Aspekten, die von den betreffenden Akteuren beachtet werden müssen (z. B. allgemeine Beschreibung, Hauptbewegungen, Teilnahmeverfahren usw.). Sonderfälle werden in separaten Artikeln detailliert erläutert. Dasselbe gilt für Themen, die für den öffentlichen Sektor relevant sind (z. B. Nutzung des Mercurius-Portals). Verweise auf die betreffenden Artikel und andere relevante Informationen finden sich im vorliegenden Artikel an den jeweiligen Stellen.

Der vorliegende Artikel umfasst die folgenden Abschnitte:

Rechtlicher Hintergrund

Mit der Richtlinie 2010/45/EU des Rates vom 13. Juli 2010 zur Änderung der Richtlinie 2006/112/EG über das gemeinsame Mehrwertsteuersystem hinsichtlich der Rechnungsstellungsvorschriften wurden elektronische Rechnungen Rechnungen in Papierform gleichgestellt. Damit wurden die Voraussetzungen für eine breitere Nutzung der Möglichkeiten zur E-Rechnungsstellung geschaffen.

Die Richtlinie 2014/55/EU vom 16. April 2014 verpflichtet alle europäischen öffentlichen Stellen, elektronische Rechnungen, die der Europäischen Norm EN16931 (FR) entsprechen, zu akzeptieren und zu verarbeiten. Die Umsetzung in belgisches Recht ist aktuell im Gange.

Ferner haben in Belgien bereits alle föderalen und regionalen Ministerräte beschlossen, die B2G-E-Rechnungsstellung zu erlauben. Die Entscheidungen werden von den jeweiligen Verwaltungen nach und nach in rechtliche, technische und unterstützende Maßnahmen umgesetzt.

Mercurius ist das Ergebnis einiger dieser Maßnahmen. Wie bereits erläutert, macht es diese zentrale elektronische Poststelle für den öffentlichen Sektor dem Privatsektor leichter, alle Kunden aus dem öffentlichen Sektor zuverlässig und kosteneffizient zu erreichen.

Finanzielle Aspekte

Die Lösung des belgischen öffentlichen Sektors für den Erhalt von elektronischen Rechnungen von Lieferanten basiert auf PEPPOL und Mercurius. Das Ziel dabei war es, langfristige Kosten für die Absender zu minimieren. Auf kurze Sicht kann nicht ausgeschlossen werden, dass es aufgrund des mangelnden Wettbewerbs auf dem betreffenden Markt oder durch Verschwendung im Zusammenhang mit Ausreifungsproblemen zu zusätzlichen Kosten kommt. Tatsächliche und nicht reduzierbare Kostensteigerungen sind eher nicht zu erwarten. Folgende Aspekte sind zu berücksichtigen:

• Mit der Lösung können alle öffentlichen Stellen in Belgien erreicht werden. Aktuell haben die Föderalregierung und die flämische Regionalregierung eine Führungsrolle inne; künftig soll die Lösung aber auch auf die anderen Regionen, die Kommunalverwaltungen und alle anderen Organe des öffentlichen Rechts (insgesamt 16 % des belgischen BIP) ausgeweitet werden.
• Die Lösung ist so konzipiert, dass sie auch für Körperschaften des Privatsektors verwendet werden kann. Die Regierung ergreift in Zusammenarbeit mit Vertretern aus dem Privatsektor zahlreiche Maßnahmen, damit dieses Potenzial auch ausgeschöpft werden kann.
• Auch für ausländische Kunden aus dem öffentlichen und dem privaten Sektor ist die Lösung hervorragend geeignet. Auf europäischer Ebene arbeiten ebenfalls viele Stellen an der entsprechenden Umsetzung.
• Die Lösung entspricht vollumfänglich der neuen Europäischen Norm. Es ist also gewährleistet, dass es bei der Umsetzung der Norm in der Strategie zur elektronischen Rechnungsstellung nicht zu einer Kehrtwende kommen wird.
• Das Mercurius-Portal bietet auch den Lieferanten eine Lösung, die - aus welchen Gründen auch immer - noch nicht in der Lage sind, echte elektronische Ausgangsrechnungen zu erstellen. Die Lösung ist komplett gebührenfrei und bedeutet für die meisten kleinen und mittleren Unternehmen in Belgien keinen zusätzlichen Verwaltungsaufwand. Lediglich größere Organisationen müssen das System zur eGOV-Rollenverwaltung berücksichtigen. Dies ist auf den ersten Blick eine zusätzliche Belastung, in der Praxis aber überschaubar.

Belgian Business Experts Group

Im Juni 2017 wurde eine belgische e-Invoicing Experts Group gegründet, die Fragen wie "Wie soll eine Rechnung mit Skonto im BIS-Format ausgedrückt werden", "Was eine Rechnungsnummer einzigartig macht", "Wie man mit der Vielfalt umgehen kann" beantwortet Identifikationssysteme ", .... Es ist ein Treffpunkt zwischen verschiedenen Gruppen, wobei jede Gruppe ihre eigene Perspektive und ihre eigenen Anliegen hat. Die Konfrontation dieser Sichtweisen in einer konstruktiven Denkweise beschleunigt die Verallgemeinerung der elektronischen Rechnungsstellung.

An dieser gemeinsamen Anstrengung beteiligen sich Experten aus allen Bereichen der belgischen Fakturierungslandschaft, die von technischen Experten unterstützt werden. Der belgische Unternehmensverband (NL) stellt die von der Gruppe benötigten Einrichtungen zur Verfügung (logistische Unterstützung, Extranet, Moderation...).

Bewegungen und Bestandteile

Im Artikel Der Weg einer E-Rechnung an eine Instanz des öffentlichen Sektors in Belgien wird erklärt, zu welchen Bewegungen und Verarbeitungsschritten es bei einer elektronischen Rechnung kommt. Die Beschreibung ist aus Sicht eines Unternehmens aus dem Privatsektor verfasst.  Erläutert werden (a) die Datenströme im Zusammenhang mit den Austauschservices bei E-Rechnungen sowie die Bestandteile, die im Hinblick auf die Funktionsfähigkeit erforderlich sind, (b) die technischen Hintergründe zu diesen Bestandteilen und (c) die Bedeutung, die ein Netzwerk aus Dienstleistern, Access Points und Software-Entwicklern in diesem Zusammenhang hat. Die wichtigsten Bewegungen sind (1) der Versand von E-Rechnungen (oder E-Gutschriften) und (2) der Erhalt von Reaktionen.

Detaillierte Informationen zu bestimmten Aspekten im Zusammenhang mit dem öffentlichen Sektor finden sich unter Mercurius für den öffentlichen Sektor.

1. Rechnungen/Gutschriften senden

Bewegungen und Bestandteile

Schritte

Erklärung: FAS Federal Authentication Service (NL) (zur Authentifizierung von Personen beim Zugang zu Mercurius-Leistungen))

Vorab: Der Lieferant erstellt in seiner eigenen Software eine Ausgangsrechnung. Schritte: Der Lieferant versendet die elektronische Rechnung über das PEPPOL-Netzwerk Siehe auch: Schritt 1: der Lieferant sendet seine Rechnung an den Kunden. Mercurius holt die elektronische Rechnung ab und leitet sie in den Posteingang des Kunden. Siehe auch: Schritt 2: Mercurius erfasst die Rechnung (für den Kunden). Der Kunde nutzt den von seinem Integrator bereit gestellten Mercurius-Service, um alle seine eingehenden E-Dokumente abzuholen. Siehe auch: Schritt 4: der Kunde ruft die Mail in seinem Posteingang zu einem Zeitpunkt seiner Wahl ab. Der Integrator stellt eine Verbindung zu Mercurius her, holt die Rechnung im Namen des Kunden ab und sendet sie an diesen. Ergebnis: Die elektronische Rechnung wurde an den Kunden gesendet. Sie wird aus dem Posteingang in Mercurius abgerufen und bleibt im Mercurius-Portal sichtbar. Hinweise: 5: Der Lieferant, der Kunde und alle anderen am Austausch beteiligten Akteure können den Fortgang jederzeit über das Mercurius-Portal verfolgen. 1a: Lieferanten, die nicht in der Lage sind, elektronische Rechnungen über PEPPOL zu senden, können das neue Rechnungsformular auf dem Mercurius-Portal nutzen (Voraussetzung: es handelt sich um relativ einfache Rechnungen). 1b: Lieferanten, die in der Pilotphase bereits angeschlossen waren, aber noch nicht in der Lage sind, elektronische Rechnungen über PEPPOL zu senden, können für den Versand die Pilot-Schnittstelle (vorübergehend noch aktiv) nutzen. 3b: Wenn Kunden noch nicht in der Lage sind, elektronische Rechnungen anzunehmen, konvertiert Mercurius diese E-Rechnungen in ein pdf-Dokument und sendet dieses an die in der Konfiguration gespeicherte Kundenadresse. Für den Abruf der Nachrichten aus dem Posteingang über Mercurius sind drei Handlungen erforderlich (Inbox-Abfrage, Dokument abrufen, Dokument markieren). Mehr dazu später.

2. Reaktionen erhalten

Dokumentenformate

Im vorigen Abschnitt wurde dargelegt, wie sich die elektronischen Dokumente zwischen den Akteuren bewegen. An dieser Stelle folgen nun nützliche Erläuterungen zu den Anforderungen an das Format dieser elektronischen Dokumente. Es muss unbedingt hinreichend berücksichtigt werden, dass das Format sich auf den Austausch auswirkt.

Vorab

Beim Austausch von elektronischen Dokumenten einigen sich Absender und Empfänger in der Regel für jeden Dokumententyp vorab auf ein bestimmtes Format. Dabei handelt es sich um eine Conditio sine qua non, denn anderenfalls sind die IT-Systeme der Beteiligten nicht in der Lage, einander zu verstehen und reibungslos miteinander zu interagieren.

Zwei Aspekte sind im Hinblick auf das Format besonders wichtig: (a) Semantik: das Dokument besteht aus Informationselementen, die so beschrieben sind, dass Interpretationsfehler ausgeschlossen werden können, und (b) Syntax: die Informationselemente werden in eine Syntax, also eine Darstellungsform, umgewandelt, die ein IT-System lesen und schreiben kann. 

2011 haben einige repräsentativen Akteure mit verschiedenen Hintergründen mehrere Workshops veranstaltet, bei denen einige sektor- und grenzüberschreitende Formate für die gängigsten Beschaffungsunterlagen (Kataloge, Aufträge, Auftragsbestätigungen, Versandscheine, Rechnungen, Gutschriften usw.) ermittelt werden sollten. Das Ergebnis der CEN-BII-Workshops waren die CEN Business Interoperability Interface (BII) WorkGroup Agreements (WGA) mit den CEN-BII-Formaten.

Inzwischen wurden die CEN-BII-Ergebnisse bereits in zahlreichen praktischen E-Procurement-Lösungen verwendet, so etwa (a) in der von der Europäischen Kommission entwickelten Plattform ePRIOR und (b) in der PEPPOL Business Interoperability Specification (BIS). Diese PEPPOL BIS stellt einen kleinsten gemeinsamen Nenner dar. Wenn also zwei Akteure sich nicht auf ein gemeinsames Format für den Dokumentaustausch einigen können, bietet PEPPOL BIS eine Lösung.

Im Rahmen eines Pilotprojekts (2013/14) wurde die ePRIOR-Plattform an die Situation in Belgien angepasst. Dabei kam der öffentliche Sektor in Belgien zu dem Schluss, dass die CEN-BII-Dokumente für Rechnungen und Gutschriften sämtliche Informationsanforderungen erfüllen.

Bei der Annahme des PEPPOL-Interoperabilitätsrahmens gab es keine speziellen Unternehmensanforderungen, die für ein anderes Format als BIS als kleinster gemeinsamer Nenner sprachen.

Zwar ist BIS nicht gerade das fortschrittlichste Format, es ist aber hervorragend dokumentiert und wird durch Validierungstools unterstützt. Derartige Hilfsprodukte tragen definitiv zur Qualität des Austauschs bei.

Aus all diesen Gründen hat sich der öffentliche Sektor in Belgien vorläufig dafür entschieden, die BIS-Formate für Rechnungen und Gutschriften zu unterstützen.

Mit Blick auf die Richtlinie 2014/55/EU wird der öffentliche Sektor natürlich seine Systeme aktualisieren und in nächster Zukunft auch die Europäische Norm EN19631 (EN) unterstützen. Im Übrigen ist in der EN 16931 auch eine Ausrichtung auf CEN BII vorgesehen. EN 16931 sieht also auch eine Migration von CEN BII Invoice vor.

Formatvorgaben

Ausgangsdokumente (Rechnungen, Gutschriften)

Wie oben bereits erwähnt, werden die folgenden Formate vom öffentlichen Sektor in Belgien unterstützt: PEPPOL BIS Invoice und PEPPOL BIS Credit Note. In der nachstehenden Tabelle sind die technischen Anforderungen für eine erfolgreiche Übermittlung der Dokumente an die öffentlichen Stellen in Belgien zusammengefasst (selbstverständlich ohne Garantie für eine Genehmigung).

Der öffentliche Sektor in Belgien hält sich streng an PEPPOL BIS. Alle Dokumente, die die BIS-Norm erfüllen, können erfolgreich übermittelt werden.

Eingangsdokumente (Business-Reaktion)

Bei einer ordnungsgemäß implementierten Business Interaction für elektronische Rechnungen übermittelt der Kunde dem Lieferanten eine Reaktion auf seine Rechnungen. Bei PEPPOL steht bisher kein geeigneter Dokumententyp zur Verfügung. Allerdings wird an einem Format für Reaktionen auf Rechnungen gearbeitet. Bis zur Fertigstellung steht in PEPPOL ein alternatives Format, nämlich die Message Level Response (MLR) zur Verfügung. Dieses ist für technisches Feedback gedacht, kann aber auch für Business-Reaktionen verwendet werden und wird dafür auch von den belgischen öffentlichen Stellen genutzt. Sobald ein Format für Reaktionen auf Rechnungen verfügbar ist, wird die belgische Regierung ein entsprechendes Übergangsszenario erarbeiten.

Da noch kein BIS-Dokument für Business-Reaktionen verfügbar ist, hat sich der öffentliche Sektor in Belgien dafür entschieden, so lange den Dokumententyp MLR zu verwenden.

Hinweise:

• Damit die vorstehend beschriebenen Business-Reaktionen empfangen werden können, muss der Absender der Rechnung die MLR-Empfangsmöglichkeit in der PEPPOL-Transportinfrastruktur bestätigt haben (siehe nächster Abschnitt).
• Das Format Message Level Response (MLR) ist nicht zwingend vorgeschrieben. Im Abschnitt „Sonderfälle" sind auch nützliche Zusatzinformationen über die MLR-Inhalte zu finden.

E-Dokumente senden/empfangen - wichtige Informationen

E-Dokumente senden

Alles, was Sie für den Versand von elektronischen Dokumenten über PEPPOL brauchen, ist ein Access Point (AP). Wie im Abschnitt Typischer Verlauf einer elektronischen B2G-Rechnung oben erläutert, wird beim Versand eines elektronischen Dokuments über PEPPOL gewissermaßen ein Umschlag in einem elektronischen Postfach abgelegt. Benötigt wird lediglich ein Zugang zu einem AP, der als Postfach fungiert.

Natürlich können Unternehmen auch selbst einen AP einrichten. Effektiver ist es aber, dafür die Dienste eines Spezialisten, also eines IT-Dienstleisters in Anspruch zu nehmen. Die meisten, nicht auf IT spezialisierten Unternehmen (a) betreiben ihre Software für Ausgangsrechnungen nicht selbst, sodass ein intern betriebener AP keinen Sinn ergeben würde, da keine Verbindung zur Fakturierungssoftware besteht, und (b) verfügen nicht über die für eine gut funktionierende und kosteneffektive Lösung erforderlichen IT-Kenntnisse. Die Sache ist zwar nicht wirklich komplex, aber wie in jedem Geschäftsbereich sind doch bestimmte Fachkenntnisse nötig.

E-Dokumente erhalten

Einer der wichtigsten Aspekte des PEPPOL-Interoperabilitätsrahmens besteht darin, dass für den Versand von elektronischen Dokumenten die technischen Details zum jeweiligen Empfänger nicht bekannt sein müssen. Möglich wird das durch ein ständig aktives Register (* ), in dem alle Unternehmen, die elektronische Dokumente erhalten, verzeichnet sind. Dieses Register enthält zweierlei Informationen: (a) wohin die elektronischen Dokumente gesendet werden müssen, d. h. die Adresse des AP des Empfängers (an die das Postsystem das Dokument leiten soll) und (b) welches Format verwendet werden soll; sämtliche Empfänger müssen dabei alle Formate angeben, die sie unterstützen (also lesen) können, damit die Möglichkeiten für die Absender ersichtlich sind. Da sämtliche Teilnehmer BIS verarbeiten können müssen, ist es unmöglich, dass nicht mindestens ein gemeinsames Format gefunden wird.

(* ) Der Name dieses Registers lautet SMP (Service Metadata Publisher). Tatsächlich handelt es sich dabei nicht um ein einzelnes, sondern um mehrere Register, mit denen die gleiche Art von Informationen in der gleichen Weise veröffentlicht wird. Sie verhalten sich also gemeinsam wie ein einzelnes Register.

Kunden erhalten elektronische Rechnungen und Gutschriften

Alle Körperschaften, die mit elektronischen Eingangsrechnungen arbeiten, u. a. alle öffentlichen Stellen in Belgien, verzeichnen die Empfangsmöglichkeit für elektronische Rechnungen und Gutschriften in diesem Register. Die Beschreibung dieser Empfangsmöglichkeiten sieht so aus:
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

Wie im Zusammenhang mit einer elektronischen Rechnungsstellung zu erwarten, sind die Datensätze so gestaltet, dass sie automatisch verarbeitet werden können; für Diskussionen zwischen Menschen sind sie nicht gedacht.

Lieferanten erhalten Reaktionen

Alle Körperschaften, die mit elektronischen Ausgangsrechnungen arbeiten, darunter die Lieferanten der öffentlichen Stellen in Belgien, sind aufgefordert, in dem Register die geeignete Empfangsmöglichkeit zu verzeichnen. Die Beschreibung dieser Empfangsmöglichkeiten sieht so aus: 
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
Die vorstehende Beschreibung entspricht dem PEPPOL BIS 36A Message Level Response.

Sonderfälle

In diesem Abschnitt geht es um einige unternehmerische und technische Sonderfälle sowie um den Umgang damit in Mercurius.

Nichteinhaltung des PEPPOL BIS-Formats

Jede E-Rechnung, die mit dem PEPPOL BIS-Format übereinstimmt, aber den Formatvalidierungsschritt nicht besteht, wird von einer zwischen dem PEPPOL AP und Mercury installierten Komponente "gefiltert". Lieferanten (E-Invoice-Absender) und ihre IT-Subunternehmer müssen daher sicherstellen, dass nur E-Rechnungen versendet werden, die das Format PEPPOL BIS erfüllen.
Diese Bestimmung ergibt sich aus den folgenden Überlegungen:

• Im Abschnitt Dokumentenformate können Lieferanten (oder ihre IT-Subunternehmer) die Dokumentformatanforderungen kennen, mit denen Regierungen umgehen können.
• Angesichts der weit verbreiteten elektronischen Rechnungsstellung ist die Einhaltung dieser Anforderungen unerlässlich.
• Die PEPPOL Rahmen, die wichtigste technische Referenz für uns veralgemeningsprogramma für E-Invoicing, spricht mich für einen bewährten Ansatz zur Bereitstellung von hohen Qualität führt, flussbasierte Formate. Insbesondere
  • das PEPPOL-BIS-Format, das Format von dem belgischen öffentlichen Sektor unterstützt hat Werkzeuge Validierung auf einer gemeinsame Technologie (Schematron) basieren, wodurch es möglich wird, die Kontrollen für die Einhaltung des Formats zu automatisieren.
  • Standardverträge, die Betreiber binden, verbieten die Übertragung von nicht konformen Dokumenten in dem Format, das sie einhalten sollen. Nichts verpflichtet den Adressaten, solche Dokumente zu lesen.
• Daher wird jede E-Rechnung, die als mit dem PEPPOL BIS-Format übereinstimmend angesehen wird, aber den Formatvalidierungsschritt nicht besteht, durch eine zwischen dem PEPPOL AP und Mercury installierte Komponente "gefiltert".
• Absender (oder ihr IT-Subunternehmer) ihre e-Rechnungen Validierung kann vollständig automatisiert werden, bevor sie gesendet werden, die gleichen Validierungstools wie der obigen Filter verwenden, da diese Werkzeuge öffentlich und kostenlos verbreitet werden.
• Schließlich hat das Mercury-Portal ein Online-Suche Programm, um Nachrichten zu testen, den Absender (oder IT-Subunternehmer), die E-Rechnung kann durch PEPPOL in der Testumgebung senden und dann online überprüfen. wenn die Nachricht angekommen ist und nicht durch einen Fehler verdorben wurde. Dieses Tool vermeidet Streufehler in den tatsächlichen Abrechnungsbewegungen.

Business-Reaktionen: MLR-Inhalte

Die von den belgischen öffentlichen Stellen erstellten Reaktionen enthalten einen Reaktionscode, der Aufschluss über die Bedeutung der Reaktion gibt. Für Lieferanten, IT-Mitarbeiter und IT-Anbieter kann es sinnvoll sein, diese Codes zu verstehen. Die Bedeutungen sind in der nachstehenden Tabelle zusammengefasst.

Business-Reaktion: der Lieferant unterstützt PEPPOL BIS MLR nicht - siehe Diagramm, Sequenz 3a

Wie oben bereits erläutert, erhält der Lieferant die Reaktion nur dann elektronisch, wenn er die Empfangsmöglichkeit für PEPPOL MLR registriert hat. Ist dies (noch) nicht der Fall, so gibt es bei Mercurius (wie unter 3a im vorstehenden Diagramm dargestellt) eine Alternative: den Versand per E-Mail. Mercurius sucht im Original der elektronischen Rechnung nach der E-Mail-Adresse des Lieferanten und sendet die Reaktionsinformationen aus der MLR in einem für Menschen lesbaren Format an diese Adresse. Die Ermittlung der E-Mail-Adresse erfolgt anhand des folgenden UBL-Datenelements:
            Invoice/AccountingSupplierParty/Contact/ElectronicMail

Ist dieses Element in der Originalrechnung leer, so kann keine E-Mail gesendet werden. In diesem Fall kann der Lieferant die Reaktion nur über das Mercurius-Portal einsehen. Weitere Informationen über das Mercurius-Portal finden Sie auf der Hilfeseite zum Mercurius-Portal.

Mercurius Business-Vorverarbeitung

Die Mercurius-Plattform umfasst eine spezielle Komponente zur Prüfung aller Dokumente (ein- UND ausgehend) nach unternehmerischen Gesichtspunkten. Dabei werden bestimmte inhaltliche Merkmale des Dokuments kontrolliert. Stellt Mercurius dabei eine Verletzung der Validierungsregeln fest, so wird das Dokument für den Endempfänger abgelehnt. Der Empfänger wird über diese Ablehnung nicht informiert. Der Absender erhält eine Reaktion (Reaktionsdokument), in der ihm die Ablehnung und die Gründe dafür mitgeteilt werden.

Folgende Kontrollen werden dabei durchgeführt:     

• Dopplungen: Wenn Mercurius die Kombination DocumentID-DocTypeID-SenderID-ReceiverID bereits erhalten hat, geht die Plattform von einer Dopplung aus und lehnt das Dokument ab. Es wird ein Reaktionscode 380:3 (bzw. 81:3 für Gutschriften) erstellt (* ). Das Originaldokument ist noch verfügbar.     
• Ausstellungsdatum in der Zukunft: Es wird ein Reaktionscode 380:4 (bzw. 81:4 für Gutschriften) erstellt (* ).
• DocumentID ist länger als 250 Zeichen: Es wird ein Reaktionscode 380:4 (bzw. 81:4 für Gutschriften) erstellt.
• DocumentID enthält exotische Zeichen (nicht in der 7-bit-ASCII-Tabelle enthalten):  Es wird ein Reaktionscode 380:4 (bzw. 81:4 für Gutschriften) erstellt.

(* ) Die Ablehnung ist aufgrund der Buchhaltungsvorschriften für die ordnungsgemäße Ausstellung einer Rechnung gerechtfertigt.

Im Grunde sollten Lieferanten mit diesem Mercurius-Service nichts zu tun haben. In der Praxis zeigt sich allerdings, dass die Vorschriften, auf die hin die Kontrolle erfolgt, von vielen Lieferanten nicht eingehalten werden. Diese Lieferanten benötigen dann Zugang zu den betreffenden Informationen.

Hinweis: Das Mercurius-Portal ermöglicht allen Benutzern des Portals den Zugang zum Dokument und somit zur Information über die Ablehnung und den Grund dafür. Weitere Informationen über das Mercurius-Portal finden Sie auf der Hilfeseite zum Mercurius-Portal.

Durchführung von Tests

Da die elektronische Rechnungsstellung und die elektronische Beschaffung erst langsam allgemein üblich werden, besteht noch erhöhter Testbedarf. Die Durchführung der Tests und die Auslegung der Ergebnisse werden allerdings dadurch erschwert, dass viele Aspekte und Teile der Lösungen (sowohl im öffentlichen als auch im privaten Sektor) relativ neu sind. Aus diesem Grund hat die Regierung in eine leistungsstarke und kontrollierte End-to-end-Testinfrastruktur investiert, die das Testen bei der B2G-Rechnungsstellung erleichtert. Darüber hinaus können viele Komponenten dieser Infrastruktur gebührenfrei auch von Einrichtungen aus dem Privatsektor für die Überprüfung ihres Teils der Lösung auf seine Kompatibilität hin genutzt werden.

Informationen für Lieferanten

Wenn es für Ihr Ausgangsrechnungssystem eine Testumgebung gibt oder Rechnungen für Testzwecke (die also nicht tatsächlich gebucht werden) erstellt und an die Testumgebung des Kunden gesendet werden können, steht einem Versand von Testrechnungen an öffentliche Stellen nichts mehr im Wege.
So senden Sie Testrechnungen an die Testsysteme der Regierung:

• Der Versand-AP muss unter Verwendung des SMK anstelle des SML nach den Empfangsmöglichkeiten des Empfängers suchen.
• SML steht für Service Metadata Locator. Es handelt sich dabei um das zentrale System, das APs, die nach Empfangsmöglichkeiten suchen, zum Empfänger-SMP umleitet (siehe auch oben „E-Dokumente senden/empfangen - wichtige Informationen").
• Der SMK ist sozusagen das Alter Ego des SML in der Testinfrastruktur.
• Alle öffentlichen Einrichtungen werden in der realen Umgebung (Produktion) und in der Testumgebung anhand genau der gleichen Kennungen identifiziert. So soll die Gefahr einer Verwechslung von Kennnummern möglichst gering gehalten werden.
• Für eine schnelle Kontrolle des Übertragungsstatus in der Testumgebung steht das folgende Online-Tool zur Verfügung: Test document lookup.
• Über das Mercurius-Portal können Sie jederzeit auch sämtliche Eingänge in der Test- sowie der Produktionsumgebung kontrollieren. Genauere Anweisungen zur Nutzung des Mercurius-Portals finden Sie auf der Hilfeseite zum Mercurius-Portal.

Zusatzinformationen für die IT-Branche

Mitarbeiter aus der IT-Branche können für die Validierung ihrer Systeme Mittel aus dem Internet nutzen. Online stehen zahlreiche Tools zur Formatvalidierung bereit. Sie alle validieren das Format PEPPOL BIS, nicht aber den Inhalt. Allerdings wird auch nachdrücklich empfohlen, die Fähigkeit, Dokumente in einem gültigen Format zu produzieren, unabhängig von inhaltlichen Aspekten zu überprüfen.

Über das Mercurius-Portal können IT-Dienstleister mithilfe der eGOV-Rolle „Mercurius_AP" auch ihre gesamten Transaktionen mit Mercurius verfolgen. Dies gilt sowohl für Test- als auch für Produktionstransaktionen. Weitere Informationen dazu sind in der Beschreibung des Teilnahmeverfahrens im Abschnitt „Access Points" auf der offiziellen Seite der belgischen PEPPOL-Behörde verfügbar. Dort finden sich auch nützliche Hinweise zu Tests und anderen Aktivitäten für die IT-Branche.

Genauere Anweisungen zur Nutzung des Mercurius-Portals finden Sie auf der Hilfeseite zum Mercurius-Portal.

Anwenderhilfe und Support

Mercurius ist ein öffentlicher Service. Die Zahl der potenziellen Benutzer beträgt bei den Kunden 5000 und bei den Lieferanten 50 000 oder sogar noch mehr, da die Fluktuation bei den Lieferanten im öffentlichen Sektor recht hoch ist. Diese Zahlen vermitteln einen Eindruck davon, wie hoch der Support-Bedarf ist. Viele unterschiedliche öffentliche und private Einrichtungen können die Plattform nutzen und auf Probleme stoßen. Für BOSA DTO ist es daher von entscheidender Bedeutung, dass der Support gut geplant, beschrieben, organisiert und sinnvoll genutzt wird.

Reichweite

Die Regierung bietet Unternehmen und öffentlichen Stellen Unterstützung bei der Nutzung der Mercurius-Plattform und des zugehörigen Portals.

Außerdem informiert sie über den PEPPOL-Interoperabilitätsrahmen. Allerdings ist die Unterstützung auf allgemeines Wissen beschränkt. Ein erweiterter technischer Support für Personen, die PEPPOL-Lösungen entwickeln oder vermarkten ist nicht Aufgabe der Regierung.

Ferner leistet die Regierung zusätzlichen technischen Support für IT-Unternehmen, die ihre Produkte über PEPPOL in Mercurius integrieren möchten. Dazu zählt auch die Beratung sowie die Registrierung von Empfangsmöglichkeiten auf smp.belgium.be (EN).

Organisation

Vorabbemerkung für Lieferanten

E-Rechnungen werden zwar nur elektronisch versandt, sind aber in erster Linie immer noch Rechnungen. Bei Fragen zur Verarbeitung der Rechnung wenden Sie sich daher am besten an den Beschaffungsmitarbeiter beim jeweiligen Kunden. Ist die Rechnung eingegangen? Wurde sie genehmigt? Bei technischen Problemen mit der E-Rechnung ist Ihr Beschaffungsmitarbeiter der richtige Ansprechpartner, es sei denn, die Rechnung ist nicht bei Mercurius eingegangen.

In diesem Fall liegt meist ein Problem bei Ihrem IT-Anbieter oder beim Access Point (AP) (intern oder extern) vor und es sollte mit diesem Anbieter geklärt werden.

Davon abgesehen bietet die Regierung folgende Unterstützung und Support-Leistungen.

1. Bitte immer erst die verfügbaren Informationen lesen. BOSA DTO hat viele Stunden in die Zusammenstellung, Strukturierung, Organisation und Übersetzung der Wissensdatenbank investiert. Wahrscheinlich ist auch Ihre Frage darin aufgeführt.
2. Wenn Sie keine Antwort auf Ihre Frage finden, füllen Sie bitte die Support-Anfrage aus.
3. Sie ist auch auf der Homepage des Mercurius-Portals verfügbar.
4. Wir bitten Sie, auf der Seite Angaben zu Ihrer Person zu machen. Mit den so gesammelten Informationen (1) wird die Sache für Sie leichter und (2) erhalten wir wichtige Angaben zur Rollenverwaltung und können den Support so weiter verbessern.
5. Wenn Sie nicht genau wissen, wie das Support-Anfrage-Formular zu verwenden ist, sehen Sie sich bitte die folgende Seite an, die sie durch die einzelnen Abschnitte führt: Wie wird das Support-Anfrage-Formular von Mercurius verwendet? (EN).
6. Unser zentraler Servicedesk sorgt dafür, dass Ihre Support-Anfrage im Follow-up-Tool ordnungsgemäß gekennzeichnet wird und erledigt Ihre Anfrage so schnell wie möglich. Allerdings sind die Mitarbeiter dort nur für häufig gestellte Fragen zuständig. Sollten Sie in unserer umfangreichen Datenbank keine Antwort auf Ihre Frage gefunden haben, so werden Sie vermutlich auch vom Servicedesk keine erhalten. In diesen Fällen wird Ihre Anfrage an das Mercurius-Support-Team weitergeleitet.
7. Das Mercurius-Support-Team beantwortet Ihre Frage und löst Ihr Problem Das Mercurius-Support-Team ist für alle weiteren Support-Anfragen zuständig. Sie analysieren den Fall, prüfen, ob er innerhalb der Reichweite des Support-Service liegt und sorgen - ob intern oder extern - für eine rechtzeitige Bearbeitung und Lösung.