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:

Geschichte

Der Ministerrat beschloss im Dezember 2012, (a) die europäische Strategie zur umfassenden Einführung der elektronischen Fakturierung in Europa bis 2020 zu unterstützen und (b) in diesem Rahmen den FÖD Haushalt und Geschäftsführungskontrolle, den Dienst für administrative Vereinfachung, Fedict und den FÖD Finanzen zu beauftragen, gemeinsam eine Pilotphase für B2G e-invoicing und e-scanning durchzuführen. Fedict übernahm die Einführung der Austauschplattform Mercurius, die die Schnittstelle zwischen dem privaten und dem öffentlichen Sektor harmonisiert, um zu vermeiden, dass Lieferanten (und öffentliche Behörden) mit übermäßigen Ungleichheiten zwischen Ansprechpartnern konfrontiert werden.

Mercurius basierte damals ausschließlich auf einer Lösung, die von den Informatikabteilungen der Europäischen Kommission entwickelt wurde: ePRIOR.

Nach Abschluss der Pilotphase wurde Mercurius auf den Interoperabilitätsrahmen PEPPOL abgestimmt. Das Fehlen eines solchen Interoperabilitätsrahmens schränkt nämlich die Verwaltungen (und ihre Lieferanten) bei der Vereinbarung von Austauschbedingungen ein, was eine Einführung von e-invoicing im großem Maßstab ausschließt. PEPPOL löst dieses Problem für e-invoicing und allgemeiner für e-procurement gegenüber den öffentlichen Behörden und innerhalb des Privatsektors.  

Um den Bereich des Austauschs von Dokumenten zwischen öffentlichen Behörden und dem Privatsektor zu erweitern und die Konformität der belgischen öffentlichen Behörden mit der europäischen Norm zu gewährleisten, wird Mercurius überarbeitet. Die Schnittstelle mit den öffentlichen Behörden, die seit der Pilotphase nicht modifiziert wurde, wird jetzt angepasst, um neuen Anforderungen gerecht zu werden.

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.

Integratoren

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.

Benutzergruppen, Reflexionsgruppen.

Die Einführung von e-invoicing und ihre allgemeine Verbreitung auf nationalem Territorium ist kein einfacher Schritt. Es handelt sich vielmehr um eine Fülle von Veränderungen und vielfältigen Prozessen. Gegenüberstellung von Sichtweisen und regelmäßiger Austausch ermöglichen eine Einigung über gemeinsame und kohärente Ansätze. In diesem Rahmen wurde auf Anregung der flämischen Regierung eine Reflexionsgruppe gebildet. Diese Struktur erlaubt den Austausch von Erfahrungen und die Gewährleistung, dass die Schlüsselinformationen wirklich weitergegeben werden. Derzeit reicht die „reflexie groep" aus, um diese Aufgabe zu erfüllen, es ist jedoch wahrscheinlich, dass mit der Aufwärtsentwicklung von e-invoicing eine robustere Struktur erforderlich wird.

Finanzielle Aspekte

Die Funktion von Mercurius bringt in zweierlei Hinsicht Kosten mit sich: die Leistungen des Subunternehmers, dem der Betrieb der Plattform anvertraut wird und die Betreuung dieses Subunternehmers. 

Die Leistungen des Subunternehmers ergeben sich aus der Ausführung eines Auftrags in der Zentrale für öffentliche Aufträge. Dieser Ansatz erlaubt die Kofinanzierung von Aktivitäten. Derzeit trägt BOSA DTO sämtliche Betriebskosten. Früher oder später werden diese Kosten auf die Institutionen umgelegt, die vom Dienst profitieren, anteilig zu Verteilungsschlüsseln, die auf den jeweiligen Mengen basieren. Die Details dieser Aufteilung müssen noch definiert werden.

BOSA DTO sorgt für die Betreuung des Subunternehmers mit eigenem Budget (Personal und entsprechende Aufgaben, z.B. Eindring- und Ausschleusungstests).

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

1. Erhalt eines Dokuments (e-invoice, e-Gutschrift, Anhang)

Ströme und Komponenten

Reihenfolge

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

Vorher: Der Lieferant hat in seinem eigenen Buchhaltungssystem eine Rechnung vorbereitet Schritte: Der Lieferant versendet die e-invoice über PEPPOL. Siehe auch Schritt 1: Der Lieferant sendet seine Rechnung an den Kunden Mercurius legt die e-invoice im Posteingang des Kunden ab. Siehe auch Schritt 2: Mercurius nimmt die Rechnung entgegen (für den Kunden) Der Kunde fordert den über seinen Integrator zugänglichen Mercurius-Dienst auf, seine eingegangene Post zu entnehmen. Siehe auch Schritt 4: Der Kunde öffnet seine E-Mail Der Integrator greift auf Mercurius zu, entnimmt die e-invoice für den Kunden und übermittelt sie ihm. Resultat: Die e-invoice wird dem Kunden übermittelt. Sie wird dem Posteingang des Kunden in Mercurius entnommen. Sie bleibt im Mercurius-Portal sichtbar Anmerkungen: 5: Der Lieferant, der Kunde und alle am Austausch beteiligten Vermittler können das Fortschreiten der Übertragung über das Mercurius-Portal jederzeit kontrollieren 1a: Der Lieferant, der nicht in der Lage ist, seine e-invoice auf PEPPOL zu übermitteln, kann sie im Mercurius-Portal eingeben (sofern es sich um eine einigermaßen simple Rechnung handelt) 1b: Der Lieferant, der an der Pilotphase teilgenommen hat und noch nicht in der Lage ist, seine e-invoice über PEPPOL zu übermitteln, kann seine Rechnung über die Pilot-Schnittstelle (vorübergehend) übermitteln 3c: Der Kunde ist noch nicht in der Lage, e-invoices zu empfangen. In diesem Fall wandelt Mercurius die e-invoice in ein PDF-Dokument um und übermittelt dieses an eine vorher in der Konfiguration festgehaltene E-Mail-Adresse. Siehe unten (PDF-Konverter) Die Abholung aus dem Posteingang über den Mercurius-Dienst erfordert 3 Aktivitäten (inbox request, retrieve document, mark document).  Siehe unten.

2. Übermittlung einer Antwort

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

Wie Mercurius die Interaktionen seiner Kunden unterstützt

Jeder Kunde verfügt über einen „Posteingang" auf Mercurius. Mercurius legt dort sämtliche e-invoices, e-Gutschriften und Anlagen bezüglich dieser Dokumente, entsprechend ihrem Eintreffen, ab. Um e-invoices auf Mercurius empfangen zu können, muss sich der Kunde daher auf Mercurius registrieren, worauf ein „Posteingang" für ihn angelegt wird. Im Abschnitt „Unterstützung und Begleitung" wird erläutert, wie die Registrierung eines neuen Kunden in Mercurius abläuft. Sobald der Kunde registriert ist, kann er den Dienst nutzen. Der Dienst erlaubt (a) die Abholung der eingehenden Post und (b) den Versand von Antworten, die aus der Verarbeitung der e-invoices und e-Gutschriften resultieren.

a. Abholung der eingehenden Post

Diese Abholung beinhaltet 3 Operationen:

• submitInboxRequest: erlaubt  die Einsicht der Liste neuer Dokumente, die auf Abholung warten
• retrieveDocument: erlaubt die Abholung eines Dokuments
• MarkDocument: Bestätigung, dass das Dokument abgeholt wurde.

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:

Bemerkungen
(* ) Zusätzliche Erläuterungen:

• Dieser Dokumenttyp erlaubt die Abholung der Anhänge von Rechnungen und Gutschriften (Empfangsprotokoll, allgemeine Bedingungen usw.) in Form einer separaten und nicht unbedingt strukturierten Datei (PDF, Excel oder jedes andere Dateiformat).
• Aus historischen Gründen extrahiert Mercurius diese Dateien aus dem PEPPOL BIS Dokument, in dem sie enthalten waren (Base64Encoding), übermittelt sie dann und verknüpft sie mit separaten XML-Dokumenten (des Typs AttachedDocument), unter Angabe der ID des übergeordneten Dokuments. Weitere Informationen  entnehmen Sie bitte (a) dem xsd dieses Dokumenttyps und der FAQ zum Thema attachedDocument (TODO: diese FAQ produzieren)
• Die Übertragung der eigentlichen Dateien erfolgt mittels des Protokolls SOAP with Attachment.

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

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 Business Pre-Processing

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:

• Doppelung: Wenn Mercurius dieselbe Kombination DocumentID-DocTypeID-SenderID-ReceiverID bereits erhalten hat, wird von einer Doppelung ausgegangen und das Dokument wird abgewiesen (* ). Das ursprüngliche Dokument kann nach wie vor abgeholt werden.
• Ausstellungsdatum in der Zukunft. (* )
• Die DocumentID ist länger als 250 Zeichen
• Die DocumentID enthält exotische Zeichen (d.h., sie erscheinen nicht in der ASCII-7-bit-Tabelle)

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

• Erleichterung der Indikation der öffentlichen Dienste: Es ist nämlich sehr schwierig, dem Lieferanten zu erklären, dass die eine Institution bereit ist, eine andere in drei Monaten, wieder eine andere erst in sechs Monaten usw. Dank des PDF-Konverters kann eine ganze Gruppe von Institutionen, im Idealfall der gesamte öffentliche Sektor, in einem einzigen Schritt auf den Empfang von e-invoices umstellen. Anschließend kann jede Institution ihr eigenes Informatikprojekt durchführen und hat die Gewissheit, dass Sie ab dem ersten Tag e-invoices erhält.
• Vermeidung der Benachteiligung von Versendern: Jeder Lieferant, der die Mühe auf sich genommen hat, den Empfehlungen der Verwaltung nachzukommen, hofft natürlich, dass sich seine Investition innerhalb angemessener Frist rentiert. Dank des PDF-Konverters kann er sein neues System sofort einsetzen, um Rechnungen an eine größere Zahl von Geschäftspartnern zu übermitteln. Mit diesem Ansatz wird der Teufelskreis, der dazu führt, dass jeder seine Entscheidung verschiebt, in einen positiven Kreislauf umgewandelt, bei dem jeder den Anreiz erhält, auf e-invoicing umzustellen.

Abgelaufene Dokumente

Falls ein Dokument von seinem Empfänger nach 30 Kalendertagen noch nicht abgeholt wurde, verfährt die Mercurius-Plattform wie folgt:

• Sie geht davon aus, dass das Dokument abgelaufen ist
• Sie entfernt das Dokument aus dem Posteingang des Empfängers
• Sie schickt eine Warn-E-Mail mit einer Mitteilung über den Ablauf des Dokuments an eine Serviceadresse (die abhängig von den Wünschen des Kunden konfiguriert werden kann).

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

Identifizierung eines Kunde: Unternehmensnummer

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.

Unterstützung und Begleitung

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:

1. 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.
2. 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.
3. 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.
4. Dort wird ihre Frage/Ihr Antrag auf der Grundlage der spezifischen Kenntnisse und der Kontakte mit allen am e-invoicing Beteiligten bearbeitet.

Begleitung der Kunden bei ihrem e-invoicing-Projekt

Die an der Einführung von e-invoicing beteiligten Einkäufer und/oder Informatikteams profitieren von einer Begleitung ihres Projekts. Diese Begleitung kann mehrere Aspekte abdecken: 

• strategische Herausforderungen des Projekts, Hilfe bei grundlegenden (technischen und anderen) Entscheidungen
• technische Integration mit der eigentlichen Mercurius-Plattform
• Überwachung und auf die Weiterentwicklung bezogene Pflege

Die Begleitung kann also vor der Phase der technischen Integration beginnen und dauert in der Regel danach noch an.

Strategische Herausforderungen:

Die Einführung von e-invoicing ist nicht nur ein punktuelles technisches Projekt. Sie muss vielmehr als grundlegende, langwierige Umformung betrachtet werden, die wahrscheinlich in Schritten erfolgt. BOSA DTO führt ein Programm zur Aufklärung der öffentlichen Behörden über diese Problematik durch. BOSA DTO steht für Treffen zur Verfügung, um gemeinsam den Kontext der Institution (oder der Gruppe von Institutionen) zu prüfen und an der Entwicklung der Strategie oder des Aktionsplans der Institution teilzunehmen. Natürlich bleibt die Institution in ihrer Analyse und ihrer Entscheidungsfindung souverän. Dennoch ist es sehr wichtig, dass sie optimal informiert wird. Die geringe Reife von e-invoicing führt dazu, dass Informationen nicht ohne weiteres verfügbar sind, dass sie oft widersprüchlich sind und dass sie letzten Endes unbefriedigend sind. Insbesondere der Beitrag des PEPPOL-Rahmens wird oft missverstanden; ebenso werden bestimmte Funktionen der Mercurius-Plattform aus Unkenntnis bisweilen unzureichend genutzt. Die vorliegende Dokumentation soll diese Situation beheben, ergänzend zu Treffen innerhalb der öffentlichen Behörden.

Das Ziel derartiger Treffen besteht zusammenfassend darin, der Institution einen klaren Überblick der Herausforderungen und der verfügbaren Lösungen zu bieten und ihr zu helfen, einen Maßnahmenplan zu entwickeln. Beispielsweise dürften folgende Fragen beantwortet werden:

• Welche wesentlichen Schritte umfasst mein Projekt
• Wie vereinfacht die angebotene Lösung Versand und Empfang von e-Dokumenten (→ Kostensenkung)
• Benötige ich den PDF-Konverter? Wann?
• Welche Maßnahmen soll ich zur Förderung gegenüber meinen Lieferanten treffen?
• (zu vervollständigen)

Technische Integration mit der Mercurius-Plattform

Sobald die Entscheidung zur Integration mit der Mercurius-Plattform getroffen ist, wird das technische Projekt eingeleitet.

1. Verständnis der Datenströme, der Operationen, die sie ermöglichen und Abstimmung mit dem eigenen System zum Empfang von Rechnungen.
2. Einleitung von Entwicklungen, die die Integration des Buchführungssystems in Mercurius erlauben.
3. Parallel dazu
   1. Konfiguration der Integrationsumgebung des Integrators: Kontaktaufnahme mit dem Integrator und Erhalt des Zugangs zum Mercurius-Dienst in der Test-/Integrationsumgebung. Siehe auch Abschnitt „Integratoren"
   2. 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(n ) 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)
4. Sobald die Entwicklungen ausreichend fortgeschritten und die oben genannten Konfigurationen aktiviert sind, können die Online-Tests durchgeführt werden.
   1. Für weitere Informationen über die Testumgebung und die Testtools verwenden Sie bitte das Support-Anfrageformular.
   2. 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.
5. 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.

Parallel zum technischen Projekt und um die Bemühungen rentabel zu gestalten, ist es wichtig, dass die Institution ein Projekt zur Sensibilisierung ihrer Lieferanten für den Versand elektronischer Rechnungen entwickelt. Derzeit existiert kein ausreichend allgemeines und verwendbares Kommunikationsmuster, das zwecks Verwendung in dieser Phase an die Institutionen übermittelt werden könnte. BOSA DTO steht den Institutionen zur Verfügung, um sie in ihren Kommunikationsaktivitäten zu begleiten.
Anmerkungen:

• Falls die Institution einen Subunternehmer mit der Entwicklung und/oder technischen Aktivitäten befasst, kann BOSA DTO die technischen Aspekte und das Verfahren direkt mit dem Subunternehmer bearbeiten.
• Falls der Integrator noch nicht in der Lage ist, den Mercurius-Dienst bereitzustellen, kann man sich vorübergehend an den föderalen Integrator (FSB) wenden.
• Wenn die Institution bereits e-invoices erhält und sie über den PDF-Konverter übermittelt, sollte sie dies in ihren Konfigurationsanfragen für Mercurius (Test/Produktion) angeben.

Technische Überwachung und auf die Weiterentwicklung bezogene Pflege

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.

Tests

Die Existenz der Testumgebung von Mercurius erleichtert neuen Institutionen und neuen Wirtschaftsakteuren (Lieferanten) die Integration und die Entwicklung neuer Funktionen. Diese permanent verfügbare Umgebung entspricht uneingeschränkt der Produktionsumgebung (einschließlich der Benutzeridentifizierungen der Partner und der Genehmigungen für den Datenzugriff). So können die Partner ihre Systeme, von den tatsächlichen Strömen vollkommen isoliert, entwickeln. Die Übermittlung von praktischen Informationen über die Testumgebung ist Teil der Begleitung der Projekte zur Integration von Institutionen in Mercurius.

Integratoren

Die Systeme der Kunden haben durch Vermittlung von Dienst-Integratoren Zugang zum Dienst von Mercurius. Gemäß den Bestimmungen zur Regelung des Datenaustauschs innerhalb öffentlicher Behörden werden die Dienste von Mercurius von den Integratoren des föderalen und regionalen Dienstes für ihre jeweiligen Zuständigkeitsebenen bereitgestellt.

a) föderale öffentliche Auftraggeber

Allgemeines

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

In diesem Rahmen und unter Berücksichtigung der Tatsache, dass der Dienst Mercurius Zugang zu Rechnungen der Betroffenen Partei bietet, besteht die einzige administrative Überprüfung, die erforderlich ist, um über den FSB auf den Dienst zuzugreifen, darin, zu überprüfen, ob der Antragsteller tatsächlich eine juristische Person belgischen öffentlichen Rechts und mit der föderalen Ebene verbunden ist.

Technische Modalitäten:

Um Zugang zu allen auf dem FSB bereitgestellten Diensten zu haben, sind zwei technisch-administrative Formalitäten erforderlich: (1°) Generierung und Übermittlung eines Zertifikats und (2°) Anforderung des Zugangs zum/zu den gewünschten Dienst(en)

1. 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)
2. Beantragung eines Zugangs:
   1. Einleitende Bemerkungen:
      1. Die Beantragung eines Zugangs erfolgt über die Einreichung eines Technical Connection Request Form
      2. Wie beschrieben, ist keine administrative Autorisierung (AARF) erforderlich
      3. Der Name des Dienstes lautet  e-InvoicingServices/CustomerService V2.00
      4. Selbstverständlich ist es notwendig, den Zugang im Rahmen der INTEGRATION zu beantragen, da ein Entwicklungs- und Testzyklus erforderlich ist
      5. Verbindungsdaten: nicht anwendbar: der Dienst ist synchron.
      6. Zertifikat: Sobald die Zertifikate (Integration und Produktion) generiert sind, übermitteln Sie den Common Name (CN) im TCRF.
   2.  Link zum Verfahren:  Ich beantrage den Zugang zu einem existierenden FSB Web-Service (NL)

ENGLISH [Expand]
Requestors must perform two parallel actions: (1) generate a certificate and (2) request access to the service 

1. Generate certificate: using the certificates generation procedure and tool (free of charges) 
   1. 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.
   2. Procedure: 
      • Ik vraag een FSB consumer certificaat aan
      • fr
2. Request access to the service: 
   1. 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")
   2. Procedure:
      • nl
      • Je demande d'accéder à un service web FSB existant

b) andere öffentliche Auftraggeber

• Region Brüssel und entsprechende lokale Behörden: ISR/FIDUS
• Flämische Gemeinschaft und entsprechende lokale Behörden:  MAGDA/VSB
• Wallonische Region, Föderation Wallonie-Brüssel und entsprechende lokale Behörden: BCED

Flämische Gemeinschaft

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.