...
WORK IN PROGRESS - Some links may not work properly - Thank you for your comprehension.
...
Mercurius fur den öffentlicher Sektor (G)
Der vorliegende Artikel richtet sich an Vertreter öffentlicher Behörden, die mit der bevorstehenden Einführung von e-invoicing konfrontiert sind: Einkäufer, technische Dienste, die mit der Einführung von Systemen befasst sind oder jeden, der sich für die Problematik interessiert.
Wie in e-invoicing-Strategie des belgischen öffentlichen Sektors beschrieben, fungiert die Plattform Mercurius als zentralisierte elektronische Poststelle für den gesamten belgischen öffentlichen Sektor im Rahmen von B2G e-invoicing.
Im vorliegenden Artikel soll die Mercurius-Plattform aus Sicht des öffentlichen Sektors, des Empfängers dieser Rechnungen, beschrieben werden.
Er beschränkt sich auf die wesentlichen Elemente (allgemeine Beschreibung, wichtigste Ströme, Einstiegsverfahren usw.) und auf spezielle Aspekte öffentlicher Behörden. Spezifischere Problematiken sind Gegenstand separater Artikel. Außerdem werden die besonderen Aspekte des Privatsektors oder die Aspekte, die der öffentliche Sektor mit ihm gemein hat, ebenfalls separat behandelt (z.B. Nutzung des Mercurius-Portals). Verweise auf diese verwandten Artikel, sowie auf andere nützliche Informationsquellen sind an geeigneter Stelle in den vorliegenden Artikel eingefügt.
Der Artikel ist in folgende Abschnitte gegliedert:
...
Rechtlicher Rahmen und Zusammenarbeitsvereinbarungen
e-invoicing
Die Richtlinie 2010/45/EU des Rates vom 13. Juli 2010 zur Änderung der Richtlinie 2006/112/EU bezüglich des gemeinsamen Mehrwertsteuersystems und der Fakturierungsregeln sorgte für eine Gleichstellung von Papierrechnungen und e-invoices in juristischer Hinsicht, sodass die Grundbedingungen für die Entwicklung von e-invoicing erfüllt sind. Diese Richtlinien wurden in belgisches Recht integriert.
Die Richtlinie 2014/55/EU vom 16. April 2014 schreibt die allen europäischen öffentlichen Behörden vor, eintreffende Rechnungen in einem elektronischen Format, das der europäischen Norm EN16931 (EN) entspricht, ab dem 19. April 2019 (nicht zentralen öffentlichen Behörden wird eventuell eine Frist von einem weiteren Jahr eingeräumt) zu erhalten und zu verarbeiten. Diese Maßnahme entspricht der e-invoicing-Strategie des belgischen öffentlichen Sektors. Die zugrundeliegende Strategie zielt eindeutig darauf ab, den Staat als Einkäufer als Hebel für die Entwicklung von Lösungsangeboten und die Ausstattung von öffentlichen und privaten Austauschpartnern zu nutzen. Natürlich muss dafür gesorgt werden, dass die Lösungen, mit denen sich Rechnungen an Verwaltungen verschicken lassen, auch für das e-invoicing an Privatkunden verwendbar sind.
Diese Richtlinie wird derzeit in belgisches Recht umgesetzt.
...
Bestimmungen zur Regelung des Datenaustauschs innerhalb öffentlicher Behörden (Gesetz vom 25. August 2012 (NL), KB vom 7. Oktober 2013 (FR-NL). Diese Bestimmungen gelten für den internen Informationsfluss in öffentlichen Behörden und in der Folge der Entwicklung des e-invoicing.
...
Ströme und Komponenten
Der Artikel Der Lebenszyklus einer e-invoice an den belgischen öffentlichen Sektor beschreibt die Schritte der Behandlung einer e-invoice. Der vorliegende Abschnitt vervollständigt diese Beschreibung aus Sicht des öffentlichen Sektors . Er (a) beschreibt die Informationsströme in Zusammenhang mit der Übermittlung von B2G e-invoices, sowie die Komponenten, die diese Ströme ermöglichen, (b) führt eine technische Betrachtung dieser Komponenten ein und (c) ordnet die Rolle des Netzes der Dienstintegratoren ein, denen in diesem Bereich eine Schlüsselrolle zufällt. Die Ströme sind: (1) Erhalt einer Rechnung (oder eine Gutschrift) und (2) Übermittlung einer Antwort
die detaillierte Präsentation der besonderen Aspekte des Privatsektors wird auf der Seite Mercurius für den Privatsektor (B) behandelt
1. Erhalt eines Dokuments (e-invoice, e-Gutschrift, Anhang)
Ströme und Komponenten | Reihenfolge |
| Vorher: Der Lieferant hat in seinem eigenen Buchhaltungssystem eine Rechnung vorbereitet
|
2. Übermittlung einer Antwort
Ströme und Komponenten | Reihenfolge |
Vorab: Der Kunde hat die Genehmigung (oder Abweisung) in seinem eigenen Buchführungssystem durchgeführt - siehe auch Schritt 5: Der Kunde bearbeitet die Rechnung. Schritte: 1. Der Kunde fordert den über seinen Integrator zugänglichen Mercurius-Dienst an und übermittelt seine Antwort. Siehe auch Schritt 6: Der Kunde bereitet eine Antwort bezüglich der Rechnung vor und übermittelt sie an Mercurius 2. Der Integrator greift auf Mercurius zu und übermittelt die Antwort des Kunden. 3. Mercurius versendet die Antwort über PEPPOL; siehe auch Schritt 7: Mercurius schickt die Antwort an den Lieferanten 4. Der Lieferant erhält die Antwort über seinen Access Point (AP) entsprechend den spezifischen Modalitäten, die dem Versender bekannt sind. Resultat: Die Antwort wird dem Lieferanten übermittelt. Anmerkungen: 5: Der Status der Rechnung (erhalten/genehmigt/abgewiesen) und die Einzelheiten dieses Status (Begründung) können im Mercurius-Portal eingesehen werden. Der Lieferant, der Kunde und alle am Austausch beteiligten Vermittler können ebenfalls das Fortschreiten der Übertragung über das Mercurius-Portal jederzeit kontrollieren. 1a: Kraft der Vereinbarungen, denen die Dienstintegratoren innerhalb der öffentlichen Behörden unterliegen, wendet sich jeder öffentliche Auftraggeber an seinen Referenzintegrator. Siehe unten. 3a: Der Lieferant, der seine e-invoice über PEPPOL versendet hat, ist nicht immer in der Lage, die Antwort über PEPPOL zu empfangen. In diesem Fall übermittelt ihm Mercurius die Antwort per E-Mail, entsprechend den nachfolgend beschriebenen Modalitäten: Schritt 7: Mercurius schickt die Antwort an den Lieferanten 3b/4b: Der Lieferant, der an der Pilotphase teilgenommen hat und Mercurius weiterhin nutzt, erhält seine Antwort (vorübergehend) über diese Schnittstelle |
Mercurius Web-Service
Wie im vorherigen Abschnitt verdeutlicht, bietet Mercurius einen Dienst, der es öffentlichen Auftraggebern ermöglicht, ihre Rechnungen (und Gutschriften und Anlagen) auf einem komplett elektronischen Weg zu erhalten und die Ergebnisse der Genehmigung dieser Dokumente zu übermitteln.
Der vorliegende Abschnitt beschreibt die Merkmale dieses Dienstes. In der Praxis wird dieser Dienst von den Integratoren bereitgestellt. Dieser Aspekt wird im Abschnitt „Integratoren" eingehender behandelt.
Zu guter Letzt wird dieser Dienst durch ein Portal vervollständigt, das den Vertretern des Kunden (und des Lieferanten) die Möglichkeit bietet, das Fortschreiten der Übertragungen und der technischen Verarbeitung zu überwachen. Dieser Aspekt wird auf einer separaten Seite behandelt
Protokoll:
SOAP ( XML over HTTPS ) + WS-Security
Die relevanten, ergänzenden technischen Spezifikationen können von einem Integrator zum anderen variieren und müssen daher bei diesem erfragt werden. Siehe auch Abschnitt „Integratoren".
...
In einem klassischen Szenario der Nutzung von Mercurius programmiert der Kunde eine regelmäßige Sequenz dieser Operationen: (1°) Einsicht der Liste der neuen Dokumente, (2°) für jedes neue Dokument (a) Abholung des Dokuments und (b) Bestätigung des Eingangs und Genehmigung, das Dokument aus der Liste der wartenden Dokumente zu löschen.
Die derzeit unterstützten Dokumente sind:
...
Document Type Naam | UBL DocumentTypeCode | XSD | Formatspezifikation | zusätzliche Informationen | |
1 | Invoice | 380 | PEPPOL BIS 4A Invoice (***) |
2 | CreditNote | 81 | PEPPOL BIS 5A Billing (***) |
3 | AttachedDocument (**) | 916 | N.A. (**) | FAQ einsetzen |
Bemerkungen
Syntax: UBL 2.0
(**) Zusätzliche Erläuterungen:
...
(***) Die Versender übermitteln die Dokumente entsprechend diesen Formatspezifikationen. Diese Spezifikation verwendet die Syntax UBL2.1. Aus historischen Gründen wandelt Mercurius sie in UBL2.0 um. Abgesehen von dieser Konversion führt Mercurius keinerlei Umwandlung durch. Diese Formatspezifikationsdokumente definieren also die jeweilige Semantik dieser Dokumente. Weitere Informationen bezüglich des Interoperabilitätsrahmens PEPPOL sind auf folgender Seite zu finden: offizielle Seite der Belgian PEPPOL Authority (nur in englischer Sprache verfügbar).
b. Versand einer Antwort
Diese Aktion erfordert eine einzige Operation: submitApplicationResponse
Nur ein Dokumenttyp wird derzeit unterstützt:
...
DocumentTypeName | UBL DocumentTypeCode | XSD | Spezifikation | |
1 | ApplicationResponse | 301 |
Anmerkung
Aus historischen Gründen unterliegt die Abfassung der Antwort einer internen Spezifikation und nicht der PEPPOL BIS Spezifikation, wie dies bei den eingehenden Strömen der Fall ist. Mercurius wandelt die vom Kunden übermittelte Antwort in ein Dokument um, das der anwendbaren PEPPOL-Spezifikation entspricht, d.h. PEPPOL BIS 36A Message Level Response (EN). Dies wird auf der für den privaten Sektor bestimmten Seite näher erläutert.
Besondere Szenarios
Dieser Abschnitt geht auf verschiedene Sonderfälle ein und erläutert, wie sie von Mercurius unterstützt werden
...
Mercurius umfasst eine Komponente, die jedes (eintreffende UND abgehende) Dokument aus Business-Sicht validiert. D.h., dass bestimmte Merkmale des Inhalts des Dokuments kontrolliert werden. Wenn einer dieser Inhalte gegen diese Validierungsregeln verstößt, weist Mercurius das Dokument im Namen des eigentlichen Empfängers ab. Der Empfänger wird nicht über diese Ablehnung informiert. Der Versender dagegen erhält eine Antwort, in der er über die Abweisung und den Grund informiert wird (die Generierung des Antwortdokuments erfolgt nach den Modalitäten, die im Paragraphen „b. Versand einer Antwort" des Abschnitts Mercurius Web-Service beschrieben werden.
Folgende Kontrollen werden durchgeführt:
...
Diese Abweisung ist durch buchhalterische Verpflichtungen gerechtfertigt, denen die Ausstellung einer Rechnung in ordnungsgemäßer Form unterliegt.
Anmerkung: Das Mercurius-Portal bietet allen Portalbenutzern, die befugt sind, auf das Dokument zuzugreifen, die Möglichkeit, die Abweisung festzustellen und den Grund zur Kenntnis zu nehmen. Weitere Informationen zum Thema Mercurius-Portal finden Sie auf der Seite Mercurius Portal hilfe
PDF-Konverter
Mercurius umfasst eine Komponente, die eine e-invoice in ein PDF-Dokument umwandelt und es per E-Mail an eine vorkonfigurierte Adresse übermittelt. Diese Komponente wurde aus zwei Gründen hinzugefügt:
...
Falls der Kunde das Dokument reaktivieren möchte, kann er mittels des Formulars Hilfeanfrage eine Anfrage an das Mercurius Support Team richten (siehe unten, Abschnitt „Support")
Anmerkung: zusätzlich zur Warn-E-Mail bietet das Mercurius-Portal allen Portalbenutzern, die befugt sind, auf das Dokument zuzugreifen, die Möglichkeit, den Ablauf des Dokuments festzustellen. Weitere Informationen zum Thema Mercurius-Portal finden Sie auf der Seite Mercurius-Portal Hilfe.
Aufbewahrung
Die Mercurius-Plattform bewahrt die eingegangenen Dokumente und alle mit diesen Dokumenten verknüpften Mitteilungen für 24 Monate auf. Anschließend wird der Verlauf gelöscht. Es ist jedoch jederzeit möglich, im Falle einer Streitigkeit, sich nach Ablauf von 24 Monaten ergibt, auf ausdrücklichen Antrag auf das Verlaufsprotokoll zuzugreifen
...
Um e-invoices auf Mercurius empfangen zu können, muss sich der Kunde vorab auf Mercurius registrieren. Nach dieser Registrierung wird ein „Posteingang" angelegt". Diese Registrierung erfordert die Verwendung einer Benutzeridentifizierung. In der Regel identifiziert sich der Kunde mittels seiner Registernummer in der Zentralen Datenbank der Unternehmen. Beispiel: SPF BOSA: 0671.516.647.
Ein Kunde, der keine eigene Unternehmensnummer hat, kann sich mittels einer anderen Benutzeridentifizierung identifizieren. Derzeit wird die GLN-Nummer verwendet. Die Übermittlung dieser Identifizierung erfolgt auf seine Kosten.
...
Die Funktion von Mercurius geht mit zweierlei betrieblichen Aktivitäten einher: (a) support day to day und (b) Begleitung der Kunden bei ihrem e-invoicing-Projekt
In beiden Fällen müssen, wenn keine besonderen Umstände vorliegen, Support-Anfragen unter Verwendung des Hilfeformulars übermittelt werden, dass auf der Startseite des Mercurius-Portals zu finden ist (direkte Adresse: Hilfeanfrage).
Normaler Support
Der Support ist wie folgt organisiert:
- Sehen Sie sich zunächst die auf diesen Seiten veröffentlichten Informationen an. BOSA DTO hat viele Stunden Arbeit investiert, um diese Informationsdatenbank zu sammeln, zu strukturieren, zu organisieren und zu übersetzen. Ihre Frage wird sehr wahrscheinlich an irgendeiner Stelle behandelt.
- Falls Sie die Antwort nicht gefunden haben, füllen Sie eine Hilfeanfrage aus. Es wird dringend empfohlen, sich zu identifizieren, so können bestimmte Informationen bereits eingetragen werden, was (1) Ihnen die Arbeit erleichtert und (2) die Möglichkeit bietet, die wesentlichen Daten für einen effizienten und hochwertigen Support zu sammeln.
- Unser Service Desk nimmt Ihre Anfrage entgegen. Unser Service Desk bearbeitet nur häufig gestellte Fragen. Wenn Sie die Online-Dokumentation zur Kenntnis genommen haben, ist es unwahrscheinlich, dass die Mitarbeiter in der Lage sind, Ihnen zu helfen. In diesem Fall leiten Sie Ihre Anfrage an das Mercurius Support Team weiter.
- Dort wird ihre Frage/Ihr Antrag auf der Grundlage der spezifischen Kenntnisse und der Kontakte mit allen am e-invoicing Beteiligten bearbeitet.
...
- Verständnis der Datenströme, der Operationen, die sie ermöglichen und Abstimmung mit dem eigenen System zum Empfang von Rechnungen.
- Einleitung von Entwicklungen, die die Integration des Buchführungssystems in Mercurius erlauben.
- Parallel dazu
- Konfiguration der Integrationsumgebung des Integrators: Kontaktaufnahme mit dem Integrator und Erhalt des Zugangs zum Mercurius-Dienst in der Test-/Integrationsumgebung. Siehe auch Abschnitt „Integratoren"
- Konfiguration eines (oder mehrerer) Kunden in der TEST-Umgebung von Mercurius: Der Verantwortliche muss eine Anfrage über das Formular Hilfeanfrage übermitteln und (1°) die Unternehmensnummer und Bezeichnungen und (2°) den Common Name (CN) des Zertifikats des Systems, das den FSB erfordert, angeben. (eine Anmerkung für die anderen Integratoren hinzufügen, da dies keinen Sinn für ihre Kunden ergibt)
- Sobald die Entwicklungen ausreichend fortgeschritten und die oben genannten Konfigurationen aktiviert sind, können die Online-Tests durchgeführt werden.
- Ergänzende Informationen bezüglich der Test-Umgebung und der Test-Tools sind verfügbar
- Mercurius ist so ausgestattet, dass die Partner Tests sehr autonom durchführen können, darunter auch End-to-End-Tests mit den Pilot-Lieferanten. Eine spezifische Aktivität seitens DTO ist daher in dieser Phase nicht vorgesehen. Selbstverständlich bearbeitet das Mercurius Support Team die in diesem Rahmen eingegangenen Support-Anfragen. BOSA DTO kann bei Bedarf auch an der Ausarbeitung dieser Aktivitäten teilnehmen, beispielsweise, um die Funktion der verfügbaren Instrumente zu erläutern.
- Sobald die Resultate der Online-Tests zufriedenstellend sind, kann das GO-LIVE stattfinden. Es impliziert in der Regel (a) eine Konfiguration der Produktionsumgebung des Integrators und (b) eine Konfiguration der Produktionsumgebung von Mercurius. Diese beiden Konfigurationen erfolgen nach dem Muster der oben beschriebenen Schritte 3a und 3b.
...
Nach Integration der Institutionen in Mercurius werden die Erweiterungs- und Optimierungsphasen geplant, wenn sich neue Anforderungen und Möglichkeiten ergeben. Ausgehend von der Erfassung solcher Anforderungen plant BOSA DTO entsprechende Modifikationen von Mercurius und setzt sie um. Diese Verbesserungen werden anschließend den Institutionen verfügbar gemacht.
Die Reflexionsgruppe (siehe auch oben, Benutzergruppen, Reflexionsgruppen) dient als Plattform für die Erfassung des Bedarfs von Institutionen, für die Priorisierung von Anfragen und zur Vermittlung der Roadmap der Entwicklung von Mercurius.
...
Wie das Diagramm verdeutlicht, spielt der Federal Service Bus (FSB) eine Doppelrolle: (1°) Einerseits verbindet er das Mercurius IT-System mit dem Netzwerk der Integratoren. In diesem Rahmen übernimmt er eine Reihe wesentlicher Sicherheits- und Leistungsfunktionen. (2°) Er stellt den Mercurius-Dienst föderalen öffentlichen Auftraggebern und externen Dienstintegratoren zur Verfügung. Nur die zweite Funktion ist Gegenstand einer Behandlung im Rahmen des vorliegenden Artikels.
Die allgemeinen Bestimmungen des FSB (Unterzeichnung einer Nutzungsvereinbarung, Öffnung von Strömen, Verwendung eines Zertifikats, Berichtswesen, Integrationsumgebung, Support usw.) gelten auch für den Mercurius-Dienst.
Der FSB veröffentlicht eine allgemeine Beschreibung seiner Aufgaben, Dienstleistungen, Verfahren, FAQ und Support-Modalitäten auf folgender Seite:
Administrative Modalitäten
...
- Generierung eines Zertifikats: Dieser Schritt erfordert die Verwendung eines Tools zur Generierung eines Zertifikats (auf Kosten der technischen Abteilung des Antragstellers). In administrativer Hinsicht muss ein klassisches administratives Verfahren befolgt werden, das die Möglichkeit bietet, das Zertifikat mit Gewissheit mit dem Rechtssubjekt zu verbinden, das es zur Identifizierung verwenden wird. Dieses Verfahren ist hier dokumentiert: Ich beantrage ein Zertifikat als FSB-Verbraucher (NL)
- Beantragung eines Zugangs:
- Einleitende Bemerkungen:
- Die Beantragung eines Zugangs erfolgt über die Einreichung eines Technical Connection Request Form
- Wie beschrieben, ist keine administrative Autorisierung (AARF) erforderlich
- Der Name des Dienstes lautet e-InvoicingServices/CustomerService V2.00
- Selbstverständlich ist es notwendig, den Zugang im Rahmen der INTEGRATION zu beantragen, da ein Entwicklungs- und Testzyklus erforderlich ist
- Verbindungsdaten: nicht anwendbar: der Dienst ist synchron.
- Zertifikat: Sobald die Zertifikate (Integration und Produktion) generiert sind, übermitteln Sie den Common Name (CN) im TCRF.
- Link zum Verfahren: Ich beantrage den Zugang zu einem existierenden FSB Web-Service (NL)
- Einleitende Bemerkungen:
ENGLISH [Expand]
Requestors must perform two parallel actions: (1) generate a certificate and (2) request access to the service
- Generate certificate: using the certificates generation procedure and tool (free of charges)
- 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.
- Procedure:
- Request access to the service:
- 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")
- Procedure:
- Remarks over TCRF fill in process:
b) andere öffentliche Auftraggeber
...
Für die Flämische Region/Gemeinschaft spielt die Plattform MAGDA (MAximale GegevensDeling tussen Administraties) die Rolle des regionalen Integrators.
Die folgenden Informationen sind auf der Website von Magda verfügbar:
- Homepage (NL)
- Anschlussprozess MAGDA-Dienste (gilt auch für Mercurius) (NL)
- Kontaktformular MAGDA - allgemeine Fragen (NL)
- technische Dokumentation (Magda - Allgemein) (NL)
Region Brüssel
In der Region Brüssel übernimmt ISR/FIDUS die Aufgabe des regionalen Integrators. Alle Informationen über den Zugang zu Mercurius für diese Zuständigkeitsebene finden Sie auf folgender Seite: FIDUS homepage (FR) FIDUS homepage (NL)
Wallonische Region und FWB
In der Wallonischen Region übernimmt BCED die Rolle des regionalen Integrators. Derzeit bietet BCED die Mercurius-Dienste noch nicht an. Bitte wenden Sie sich an Ihren Ansprechpartner bei BCED, gegebenenfalls über Ihre IT-Abteilung.