IF_001 – Beschreibung von Verwaltungsleistungen lesen

Der Sammlerdienst holt Leistungsdaten vom Redaktionssystem über eine Web-Schnittstelle ab. In den folgenden Abschnitten ist die Schnittstelle im Detail beschrieben.

Inhalt durchsuchen:

Endpunkte

Die bereitgestellten Leistungsdaten in Form von XZuFi-Dateien werden über eine Index-Datei (=einfache Textdatei) mittels einer im Vorfeld bekanntgegebene URL (der Index-Datei) bereitgestellt. Die Index-Datei enthält zeilenweise relative URLs zu den ebenfalls bereitgestellten XZuFi-Dateien, die die zu übertragenden Informationen (z. B. Beschreibungen von Verwaltungsleistungen) enthalten.

Beispiel

/export/20250121/99001009004002/XZUFI20180917083058000000000002.xml
/export/20250121/99002001016001/XZUFI20180917083058000000000003.xml

Der Abruf der Index-Datei vom Sammlerdienst erfolgt über einen HTTP GET Aufruf.

Der Sammlerdienst hat Zugriff auf das Internet als auch auf das Verbindungsnetz des Bundes (NdBVN). Bei der Implementierung der Schnittstelle aufseiten des Quellsystems ist also sicherzustellen, dass die URL für die Index-Datei entweder vom Internet oder aus dem NdB-VN erreichbar ist.

Sicherstellen Datenkonsistenz

Da das Abrufen der XZuFi-Dateien einige Zeit in Anspruch nehmen kann, muss sichergestellt werden, dass die bereitgestellten Daten für die Dauer des Abrufs konsistent sind. Das heißt zum Beispiel, dass alle in der Index-Datei aufgeführten XZuFi-Dateien abrufbar sein müssen.

Aber auch die Daten in den XZuFi-Dateien müssen konsistent sein. Sollten beispielsweise jeweils Daten zur selben Organisationseinheit in mehreren XZuFi-Dateien vorkommen, dürfen diese Daten in nachfolgenden XZuFi-Dateien (entsprechend der Reihenfolge in der Indexdatei) nicht ältere Daten (z. B. veraltete Adressangaben) als in zuvor in der Indexdatei angegebenen XZuFi-Dateien aufweisen.

Beispiel

Eine Organisationseinheit mit der ID 1234 kommt in den XZuFi-Dateien XZUFI20180917083058000000000001.xml und XZUFI20180917083058000000000003.xml vor. Die Angaben (z. B. Bezeichnung, Kontaktdaten) zur Organisationseinheit mit der ID 1234 dürfen in der Datei XZUFI20180917083058000000000003.xml nicht einen älteren Stand (z. B. veraltete Adressangaben) als in der Datei XZUFI20180917083058000000000001.xml besitzen.

Redaktionssysteme können grundsätzlich ihre eigenen Konzepte verwenden, um diese Konsistenz sicherzustellen. Der folgende beispielhafte Ablauf zeigt einen Konzeptvorschlag, der als Orientierungshilfe verwendet werden kann:

Beispielhafter Ablauf

Erster Export eines Redaktionssystems

Anlegen eines neuen spezifischen Unterordners für den Export (z. B. export/20250121)
Alle vorhandenen XZuFi-Dateien exportieren (z. B. export/20250121/XZUFI20180917083058000000000001.xml, usw.)
Neue Index-Datei mit abweichendem Namen im übergeordneten Export-Ordner erstellen (z. B. export/index.gesperrt.txt)
URLs in die neu erstellte Index-Datei schreiben.
Wenn der Schreibvorgang beendet ist, die neu erstellte Index-Datei umbenennen (z. B. von index.gesperrt.txt in index.txt)

Der Sammlerdienst kann jetzt auf die Datei index.txt zugreifen und die XZuFi-Dateien aus dem Ordner /export/20250121 abrufen.

Alle anschließenden Exporte des Redaktionssystems

Anlegen eines neuen spezifischen Unterordners für den Export (z. B. export/20250128)
Gesamtdatenbestand des Redaktionssystems in neue XZuFi-Dateien exportieren (z. B. export/20250128/XZUFI20180917083058000000000001.xml, usw.)
Neue Index-Datei mit abweichendem Namen im übergeordneten Export-Ordner erstellen (z. B. export/index.gesperrt.txt) erstellen.
URLs in die neu erstellte Index-Datei schreiben.
Mit der neu erstellten Index-Datei kann die alte Index-Datei überschrieben werden (z. B. durch Umbenennen von index.gesperrt.txt in index.txt)

Der Sammlerdienst kann jetzt auf die Datei index.txt zugreifen und die XZuFi-Dateien aus dem Ordner /export/20250128 abrufen.

Abruffrequenz

Die Frequenz, mit der die Daten vom Redaktionssystem abgerufen werden sollen, können für jedes Redaktionssystem individuell festgelegt werden. Es ist dabei allerdings zu beachten, dass das Herunterladen und die weitere Verarbeitung der Dateien je nach Datenvolumen einige Zeit in Anspruch nehmen kann.

Üblicherweise findet der Abruf alle 24h statt.

Authentifizierung

Der Zugriff des Sammlerdienstes kann anonym oder abgesichert erfolgen. Für die Absicherung der Schnittstelle kann vom Redaktionssystem als Authentifizierungsmethode HTTP BasicAuthentication (Nutzername, Passwort) verwendet werden. Die Entscheidung, ob die Schnittstelle für den anonymen Zugriff oder nur für den geschützten Zugriff bereitgestellt wird, liegt im Ermessen des Betreibers des Redaktionssystems.

Verschlüsselung der Übertragungswege

Die Übertragung der bereitgestellten Leistungsdaten muss über eine verschlüsselte Verbindung erfolgen, um ausschließen zu können, dass die Daten während der Übertragung manipuliert werden können. Die Verschlüsselung der Übertragungswege erfolgt auf Basis von TLS (mindestens Version 1.2).

Komprimierung

Die Menge der zu übertragenden Daten kann insbesondere bei Flächenländern sehr groß (mehrere GB) werden. Um die Übertragung der Daten zu beschleunigen, kann HTTP-Kompression für das Komprimieren der Daten verwendet werden. Der Sammlerdienst unterstützt die folgenden Komprimierungsverfahren:

gzip
deflate

Die Aktivierung der HTTP-Kompression erfolgt auf dem Webserver, von dem die XZuFi-Dateien durch den Sammlerdienst abgerufen werden.

Anzahl und Ablage der XZuFi-Dateien

In den Redaktionssystemen von einigen Bundesländern werden aufgrund der großen Anzahl von Kommunen sehr viele Leistungen verwaltet. Der XÖV-Standard XZuFi erlaubt im Standard viele unterschiedliche Abbildungen dieser Leistungen in XZuFi-Dateien. Beispielsweise können alle Verwaltungsleistungen in einer XZuFi-Datei oder jede Verwaltungsleistung in einer einzelnen XZuFi-Datei abgebildet werden. Um eine effiziente und konsistente Verarbeitung einer großen Anzahl von Leistungen im Sammlerdienst zu ermöglichen, müssen die Leistungen wie folgt in XZuFi-Dateien exportiert werden.

1. Eine Datei pro LeiKa-Schlüssel

Alle Leistungen, mit dem gleichen LeiKa-Schlüssel, müssen in einer XZuFi-Datei beschrieben werden und jede XZuFi-Datei darf nur Leistungen mit dem gleichen LeiKa-Schlüssel enthalten.

Ist eine Leistung mehreren LeiKa-Schlüsseln zugeordnet, dann soll die Leistung nur in einer XZuFi-Datei enthalten sein. Das exportierende Redaktionssystem kann dabei selbst entscheiden, in welcher der infrage kommenden XZuFi-Dateien die Leistung beschrieben wird.

2. Zuständige Organisationseinheit in einer Datei mit Leistung

Für alle, in einer XZuFi-Datei enthaltenen, Leistungen müssen auch alle für diese Leistungen zuständigen Organisationseinheiten in dieser XZuFi-Datei enthalten sein. Dabei dürfen innerhalb der Organisationseinheit nur Zuständigkeiten zu Leistungen angegeben werden, die in derselben XZuFi-Datei enthalten sind. Leistungen, für welche die betreffende Organisationseinheit zuständig ist, die aber in der jeweiligen XZuFi-Datei nicht enthalten sind (d. h. nicht den jeweiligen LeiKa-Schlüssel besitzen), dürfen nicht im Element <xzufi:zustaendigkeit> angegeben werden.

Wird eine Organisationseinheit mehrfach im Datenimport beschrieben (z. B. in zwei unterschiedlichen XZuFi-Dateien), dann müssen diese Beschreibungen identisch sein. Unterschiede darf es lediglich hinsichtlich der Zuständigkeiten geben. In der jeweiligen Beschreibung einer Organisationseinheit müssen alle Leistungen angegeben sein, die in derselben XZuFi-Datei vorkommen.

3. Verwendung von Spezialisierungen

Unterscheiden sich die Beschreibungen von Leistungen mit dem gleichen LeiKa-Schlüssel in unterschiedlichen Verwaltungsbereichen (z. B. Kommunen) nur marginal, dann soll das Konzept der Spezialisierung verwendet werden, anstatt mehrere größtenteils identische Beschreibungen anzugeben.

Namenskonventionen XZuFi-Dateien

Die Namenskonvention für die XZuFi-Dateien lautet:

XZUFIJJJJMMTTHHMMKKNNNNNNNNNNNN.xml

Dabei sind die einzelnen Teile der Namenskonvention wie folgt zu verstehen / zu ersetzen:

XZUFI = Feste Angabe XZUFI
JJJJMMTT = Erstellungsdatum Jahr Monat Tag (z.B. 20250514)
HHMMKK = Erstellungsuhrzeit Stunde Minute Sekunde (z.B. 210545)
NNNNNNNNNNNN = beliebige Nummer mit führenden Nullen

Beispiel

XZUFI20250512105451000012345678.xml

Verarbeitungsreihenfolge XZuFi-Dateien

Das Online-Gateway verarbeitet die bereitgestellten XZuFi-Dateien gemäß der Reihenfolge, die sich aus den Dateinamen in der Index-Datei ergibt.

Aufbewahrungsfristen XZuFi-Dateien

Vom Redaktionssystem müssen immer die letzten beiden Exporte vollständig aufbewahrt werden. Ältere Exporte können gelöscht werden. Diese Vorgabe ist notwendig, um im Fehlerfall eine umfangreiche Fehleranalyse durchführen zu können.

Nachrichtenformat

Die Übertragung der Leistungsdaten erfolgt auf Basis des XÖV-Standards XZuFi. Langfristig sollten alle Redaktionssysteme ihre Daten ausschließlich in XZuFi Version 2.3.1 (öffnet in neuem Tab) bereitstellen.

In den folgenden Abschnitten ist beschrieben, in welcher Form XZuFi Version 2.3.1 für die Datenübertragung zum PVOG einzusetzen ist.

info

In diesem Abschnitt werden Angaben zur Verwendung von XZuFi gemacht, die unabhängig von der gewählten XZuFi-Version umzusetzen sind.

Angabe der verwendeten Codelisten

In XZuFi ist die Verwendung von Codelisten vorgesehen. Für einige Codelisten gibt es unterschiedliche Versionen. Aus diesem Grund ist bei der Verwendung von Codes aus einer Codeliste in den zugehörigen Attributen jeweils die URI und die Version der Codeliste anzugeben, damit die verwendete Codeliste im Online-Gateway eindeutig identifiziert werden kann.

Beispiel

<xzufi:modulText>
    …
    <xzufi:leikaTextmodul
     listURI="urn:de:xzufi:codeliste:leistungstextmodulleika"
     listVersionID="20150601">
        <code>02</code>
    </xzufi:leikaTextmodul>
    …
</xzufi:modulText>

Eindeutige Identifikation von Objekten

Für die eindeutige Identifikation von Objekten kann in XZuFi in der Regel das Element <xzufi:id> verwendet werden. Da das Online-Gateway Daten aus mehreren Redaktionssystemen verarbeitet, gibt es bestimmte Vorgaben, die bei der Verwendung des Elements <xzufi:id> für die wesentlichen XZuFi-Datentypen zu beachten sind.

Der Schlüsselwert (Inhalt des Elements <xzufi:id>):

muss eindeutig sein,
muss über den Lebenszyklus des Objekts stabil bleiben,
darf keine fachliche Logik enthalten und
wird vom Quellsystem festgelegt.

Folgende Zeichen sind für die Erstellung des Schlüsselwerts erlaubt:

XZuFi 2.3.1
XZuFi 2.2.0

Kleinbuchstaben (a bis z),
Großbuchstaben (A bis Z),
Ziffern (0 bis 9),
Bindestrich (-) und
Unterstrich (_).
Punkt (.).

Da das Online-Gateway Leistungsdaten aus mehreren Redaktionssystemen verarbeitet, muss das Attribut schemeAgencyID innerhalb des Elements <xzufi:id> gesetzt werden. Dieser Wert muss das Redaktionssystem eindeutig identifizieren und damit über alle Redaktionssysteme hinweg eindeutig sein. Um dieses Ziel zu erreichen, ist vorgesehen, dass die Portalverbundteilnehmer dafür ihre Teilnehmernummern der Behördenrufnummer 115 wiederverwenden. In allen Datenlieferungen eines Redaktionssystems darf über alle Lieferungen hinweg nur genau ein Wert für das Attribut schemeAgencyID verwendet werden.

Wenn beispielsweise ein Bundesland Datenlieferung über ein Redaktionssystem bereitgestellt werden, dann muss die Teilnehmernummer für dieses Land verwendet werden. Wenn dagegen einzelne großen Kommune (z. B. Großstadt) unabhängig vom Bundesland eigene Datenlieferung bereitstellen, dann ist die Teilnehmernummer der entsprechenden Kommune zu verwenden.

Wenn keine Teilnehmernummer der Behördenrufnummer 115 verfügbar ist, kann auch eine andere Angabe zur Identifikation des Quellsystems verwendet werden. Es muss allerdings sichergestellt werden, dass nicht mehrere Teilnehmer die gleiche Zeichenkette als ID verwendet.

Der für das Attribut schemeAgencyID verwendete Wert muss dem Betreiber des Online-Gateways vor der Anbindung des Redaktionssystems mitgeteilt werden.

Folgende Zeichen sind für das Attribut schemeAgencyID erlaubt:

Kleinbuchstaben (a bis z),
Großbuchstaben (A bis Z),
Ziffern (0 bis 9),
Bindestrich (-) und
Unterstrich (_).

Beispiel

<xzufi:id schemeAgencyID="S100002"> S1000020010000006848</xzufi:id>

Gültigkeitszeiträume für Objekte

In XZuFi können für diverse Datentypen über das Element <xzufi:gueltigkeit> Gültigkeitszeiträume festgelegt werden.

Beispiel

<xzufi:gueltigkeit>
    <xzufi:beginn>2025-01-01</xzufi:beginn>
    <xzufi:ende>2025-12-31</xzufi:ende>
</xzufi:gueltigkeit>

Im Rahmen des Portalverbunds werden ausschließlich Gültigkeitszeiträume für die folgenden Objekte berücksichtigt:

Leistungen (inklusive Textmodulen)
Spezialisierungen
Organisationseinheiten
Zuständigkeiten
Online-Dienste
Formulare

Die zuliefernden Redaktionssysteme müssen dabei sicherstellen, dass die Gültigkeitszeiträume von Objekten, die zueinander in Beziehung stehen ordnungsgemäß gepflegt sind. Das Online-Gateway prüft die Angaben von Gültigkeitszeiträumen nicht auf Sinnhaftigkeit. Wird beispielsweise eine Leistung angegeben und existiert für diese Leistungen für einen bestimmten Zeitraum keine zuständige Organisationseinheit, dann wird diese Leistung für diesen Zeitraum in der deutschlandweiten Suche des Online-Gateways (UI und API) nicht angezeigt. Nur Leistungen, für die zum Zeitpunkt der Suche auch eine zuständige Organisationseinheit ermittelt werden kann, werden in der Suche berücksichtigt.

Unterstützte Leistungstypen

Im Leistungskatalog (LeiKa) des föderalen Informationsmanagement (FIM) sind Leistungen unterschiedlicher Typen enthalten. Die Tabelle enthält eine Übersicht aller aktuell existierenden Typen für Einträge im LeiKa und eine Festlegung, ob Leistungen des jeweiligen Typs auch an das PVOG übertragen werden müssen/können.

Code	Bedeutung	Übertragung an das PVOG
1	Regelungs- und Vollzugskompetenz auf Bundesebene	Durch den Bund
2	Regelungskompetenz auf Bundesebene	Durch die Länder
2a	Regelungskompetenz auf Bundesebene - Vollzug durch Landesebene	Durch die Länder
2b	Regelungskompetenz auf Bundesebene - Ausführungsvorschriften durch Landesebene, Vollzug durch kommunale Ebene	Durch die Länder
3	Regelungskompetenz auf Bundesebene (Abweichungsrecht bzw. ehemals Rahmengesetzgebung)	Durch die Länder
3a	Regelungskompetenz auf Bundesebene (Abweichungsrecht bzw. ehemals Rahmengesetzgebung) - Vollzug durch Landesebene	Durch die Länder
3b	Regelungskompetenz auf Bundesebene (Abweichungsrecht bzw. ehemals Rahmengesetzgebung) - Ausführungsvorschriften durch Landesebene, Vollzug durch kommunale Ebene	Durch die Länder
2/3	Regelungskompetenz auf Bundesebene (Abweichungsrecht bzw. ehemals Rahmengesetzgebung) - Ausführungsvorschriften durch Landesebene, Vollzug durch kommunale Ebene	Durch die Länder
2/3a	Regelungskompetenz auf Bundesebene - Vollzug durch Landesebene	Durch die Länder
2/3b	Regelungskompetenz auf Bundesebene - Ausführungsvorschriften durch Landesebene, Vollzug durch kommunale Ebene	Durch die Länder
4	Regelungskompetenz auf Landesebene	Durch die Länder
4a	Regelungskompetenz auf Landesebene - Vollzug auf Landesebene	Durch die Länder
4b	Regelungskompetenz auf Landesebene - Vollzug durch kommunaler Ebene	Durch die Länder
5	Regelungskompetenz auf kommunaler Ebene	Durch die Länder
6	allgemeine Hinweise mit informativem Charakter, die nicht eine bestimmte Leistungserbringung betreffen	Durch den Bund Durch die Länder (freiwillig)
7	Service- und Sonderrufnummern mit Informationsbedarf in der Bevölkerung	Durch die Länder (freiwillig)
8	derzeit nicht belegt	Nein
9	derzeit nicht belegt	Nein
10	Verwaltungsinterne Leistung	Nein
11	Informationen zu SDG allgemeine Rechte und Pflichten	Durch den Bund
12	Informationen zu SDG Hilfs- und Problemlösungsdienste	Durch den Bund

Es können ebenfalls Mischleistungen angegeben werden. Dabei ist eine Mischleistung eine Leistung, bei der für dasselbe Gebiet mehrere Vollzugsbehörden zuständig sind. Beispielsweise kann bei Mischleistungen, der Vollzug sowohl auf Bundes- als auch auf kommunaler Ebene erfolgen.

Beispiel

<xzufi:transfer.operation.050502>
    …
    <xzufi:schreibe>
        <xzufi:leistung>
            …
            <xzufi:typisierung listURI="urn:de:fim:leika:typisierung" listVersionID=
             "20201204">
                <code>1</code>
            </xzufi:typisierung>
            <xzufi:typisierung listURI="urn:de:fim:leika:typisierung" listVersionID=
             "20201204">
                <code>3</code>
            </xzufi:typisierung>
            …
        </xzufi:leistung>
    </xzufi:schreibe>
    …
</xzufi:transfer.operation.050502>

Geografische Angaben

XZuFi unterstützt für die Beschreibung einer Organisationseinheit im Datentyp xzufi:Anschrift die Angabe von Geokoordinaten (Element <xzufi:geokodierung>). Mithilfe der Geographic Markup Language (GML) kann hier die genaue geografische Position angegeben werden. GML erlaubt unterschiedliche Formate in der die Angaben erfolgen können. Im Wesentlichen geht es um die Angabe des zu verwendenden Koordinatenreferenzsystem (CRS – eng. Coordinate Reference System) im Attribut srsName. Das Online-Gateway unterstützt nur die Angabe des CRS in mithilfe von EPSG-Codes in der folgenden Form:

EPSG:[CODE]

Die Angabe erfolgt über die entsprechende URN im Attribut srsName Element <gml:point>. Über Attribut axisLabels muss die Information über Koordinatenachsen gesetzt werden. Es werden die Achsen aus den Wertebereichen {northing, easting} und {latitude, longitude} unterstützt.

Beispiel (EPSG:4316)

<xzufi:anschrift>
    …
    <xzufi:geokodierung>
        <gml:point srsName="EPSG:4326" axisLabels="latitude longitude" gml:id="
         ID_POINT_GEB_177700_2179">
            <gml:pos>46.1 3.2</gml:pos>
        </gml:point>
    </xzufi:geokodierung>
</xzufi:anschrift>

Beispiel (EPSG:31468)

<xzufi:anschrift>
    …
    <xzufi:geokodierung>
        <gml:point srsName="EPSG:31468" axisLabels="northing easting" gml:id=
         "ID_POINT_GEB_1415_48683">
            <gml:pos>4469654.14 5333879.03</gml:pos>
        </gml:point>
    </xzufi:geokodierung>
</xzufi:anschrift>

Anschriften von Organisationseinheiten

Die Adressen einer Organisationseinheit werden über das Element <xzufi:anschrift> (Datentyp Anschrift) im Datentyp Organisationseinheit übertragen. Es gibt unterschiedliche Typen von Anschriften (z. B. Hausanschrift, Lieferanschrift). Der Typ einer Anschrift wird über das optionale Element <xzufi:typ> im Datentyp Anschrift festgelegt. Es dürfen für das Element nur Werte der Code-Liste urn:de:xzufi:codeliste:anschrifttyp verwendet werden.

Für Datenlieferungen, die Anschriften für Organisationseinheiten enthalten, gelten die folgenden Vorgaben:

Für alle Anschriften muss das Element typ vorhanden sein.

Hierarchien von Organisationseinheiten

Im Standard erlaubt XZuFi die Abbildung von hierarchischen Organisationsstrukturen über die folgenden XML-Kind-Elemente innerhalb des XML-Elements für Organisationseinheiten

<uebergeordneteOrganisationseinheitID>
<untergeordneteOrganisationseinheitID>

Mit dem Konstrukt der Organisationshierarchie können zentrale Informationen wie Adressen oder Kontakte in den Redaktionssystemen organisationseinheitenübergreifend und zentral gepflegt werden. Das Online-Gateway unterstützt das Konstrukt der Organisationshierarchie nicht. Alle XZuFi-Dateien, die Organisationseinheiten enthalten, in denen die XML-Kind-Elemente für die Beschreibung einer Organisationshierarchie gesetzt sind, werden nicht weiterverarbeitet. Werden in den Redaktionssystemen Organisationshierarchien verwendet, beispielsweise um Adressen oder Kontakte organisationseinheitsübergreifend zu pflegen, dann muss diese Hierarchie beim Export der Daten für das Online-Gateway aufgelöst werden. Zum Beispiel durch die Übertragung der organisationseinheitsübergreifend gepflegten Informationen in die untergeordneten Organisationseinheiten.

Mehrsprachigkeit

Generell unterstützt XZuFi die Beschreibung von Objekten in mehreren Sprachen. Im Online-Gateway werden grundsätzlich die folgenden Sprachen unterstützt:

Deutsch
Englisch

Bei der Lieferungen von englischen Texten wird die Sprachvariante Britisches Englisch erwartet.

Elemente in XZuFi, die in mehreren Sprachen beschrieben werden können, enthalten jeweils das Attribut languageCode. Für jedes Element, welches das Attribut languageCode enthält, muss eine explizite Angabe der Sprache erfolgen. Folgende Angaben sind für das Attribut languageCode erlaubt:

Sprache Deutsch: de
Sprache Englisch: en

Wird keine Sprache über das Attribut languageCode angegeben, dann wird die XZuFi-Datei, in der das Element enthalten ist, zurückgewiesen und nicht weiter im PVOG verarbeitet. Wird ein nicht zulässiger Wert (siehe oben) im Attribute languageCode angegeben, dann wird die XZuFi-Datei, in der das Element enthalten ist, ebenfalls zurückgewiesen und nicht weiter im PVOG verarbeitet.

Für alle textuellen Beschreibungen muss mindestens die deutsche Variante geliefert werden. Idealerweise werden für alle übertragenen Datenobjekte alle textuellen Beschreibungen sowohl in Deutsch als auch in Englisch geliefert. Mindestens aber für alle übertragenen Datenobjekte, die im Rahmen der SDG-Verordnung an das "Your Europe" Portal der Europäischen Union geliefert werden, müssen alle textuellen Beschreibungen sowohl in Deutsch als auch in Englisch geliefert werden (siehe auch „Übertragung von Informationen im Rahmen der SDG-Verordnung“).

tipp

Das gilt für alle Verwaltungsleistungen, die einem SDG-Informationsbereich (z. B. über das Element <informationsbereichSDG> im Datentyp Leistung in XZuFi 2.3.1) zugeordnet sind, und alle Organisationseinheiten, Spezialisierungen und Online-Dienste, die sich auf diese Leistungen beziehen.

Je nach Datentyp gibt es XZuFi zwei unterschiedliche Möglichkeiten Beschreibungen in mehreren Sprachen festzulegen.

In der ersten Variante werden beschreibende Elemente eines Datentyps mehrfach in unterschiedlichen Sprachen angegeben. Die Kardinalität des betreffenden Elements muss dabei 0..n oder 1..n sein. Das Kennzeichen `html`` definiert, ob im Inhalt des Elements HTML-Code enthalten sein kann.

Beispiel

<xzufi:modulText>
    …
    <xzufi:inhalt html="true" languageCode="de">
    Landessportamt
    </xzufi:inhalt>
    <xzufi:inhalt html="true" languageCode="en">
    Regional sports office
    </xzufi:inhalt>
    <xzufi:leikaTextmodul
     listURI="urn:de:xzufi:codeliste:leistungstextmodulleika"
     listVersionID="20250101">
        <code>02</code>
    </xzufi:leikaTextmodul>
</xzufi:modulText>

In der zweiten Variante muss die gesamte (Teil-)Datenstruktur vervielfacht werden.

Beispiel

<xzufi:weiterfuehrenderLink languageCode="de">
    <xzufi:uri>
    https://formularserver.bayern.de/forms/gewerbeanmeldung/index
    </xzufi:uri>
    <xzufi:titel>
    Gewerbeanmeldung mit Ausfüllassistent
    </xzufi:titel>
    <xzufi:positionDarstellung>
    1
    </xzufi:positionDarstellung>
</xzufi:weiterfuehrenderLink>
<xzufi:weiterfuehrenderLink languageCode="en">
    <xzufi:uri>
    https://formularserver.bayern.de/forms/gewerbeanmeldung/index
    </xzufi:uri>
    <xzufi:titel>
    Business registration with fill-in assistant
    </xzufi:titel>
    <xzufi:positionDarstellung>
    1
    </xzufi:positionDarstellung>
</xzufi:weiterfuehrenderLink>

Elemente, für die eine Sprache über das Attribut languageCode angegeben wurde, dürfen keine Elemente enthalten, in denen ein anderer Wert für das Attribut languageCode verwendet wird als im Elternelement. Sprachunabhängige Inhalte, die auf Grundlage dieser Vorgabe mehrfach übertragen werden müssen, müssen in allen Sprachvarianten identisch sein.

Liegt für eine zu übertragende Information (z. B. Leistungsbezeichnung) für eine bestimmte Sprache (z. B. Englisch) keine Übersetzung vor, dann darf das Element in XZuFi, mit dem diese Information übertragen wird, keine Ausprägung für diese betreffende Sprache haben. Eine Ausprägung des Elements in der betreffenden Sprache mit einem leeren Inhalt oder einem Hinweis, dass keine Übersetzung vorliegt, ist nicht zulässig.

Negativ-Beispiel (nicht erlaubt)

<xzufi:modulText>
    …
    <xzufi:inhalt html="true" languageCode="de">
    Landessportamt
    </xzufi:inhalt>
    <xzufi:inhalt html="true" languageCode="en">
    </xzufi:inhalt>
</xzufi:modulText>
…

Negativ-Beispiel (nicht erlaubt)

<xzufi:modulText>
    …
    <xzufi:inhalt html="true" languageCode="de">
    Landessportamt
    </xzufi:inhalt>
    <xzufi:inhalt html="true" languageCode="en">
    No translation available.
    </xzufi:inhalt>
</xzufi:modulText>

Stattdessen darf das betreffende Element nur für die Sprachen ausgeprägt sein, in denen auch eine Übersetzung vorliegt.

Beispiel

<xzufi:modulText>
    …
    <xzufi:inhalt html="true" languageCode="de">
    Landessportamt
    </xzufi:inhalt>
</xzufi:modulText>

Verwenden von HTML in XZuFi

In XZuFi existieren Elemente vom Datentyp xs:string, bzw. xzufi:String.LocalizedHTML, welche längere Beschreibungstexte enthalten können. Hier sind zur Auszeichnung und Strukturierung des Textes gemäß Spezifikation Version 2.3.1 ausgewählte HTML-Tags vorgesehen (siehe Tabelle).

HTML Tag	Attribut	Beschreibung
`<p>`		Abschnitt
`<br>`		Zeilenumbruch
`<h1> <h2> <h3> <h4> <h5> <h6>`		Überschrift
`<b> <strong>`		Fettschrift
`<i> <em>`		Kursivschrift
`<sup> <sub>`		Hoch-/Tiefgestellt
`<ul>`		Unsortierte Liste
`<ol>`		Nummerierte Liste
`<li>`		Listeneintrag
`<a>`	href	Links (Jedoch ist die Nutzung separater Elemente vom Datentyp "HyperlinkErweitert" in den Datenstrukturen zu bevorzugen.)

Neben den in der obigen Tabelle aufgeführten Kombinationen von HTML-Tags und Attributen akzeptiert das PVOG nur noch die in der nachstehenden Tabelle aufgeführten Kombinationen von HTML Tags und Attributen. Alle anderen Kombinationen werden nicht akzeptiert.

HTML Tag	Attribut	Beschreibung	Begründung
`<div>`	lang	Container	Bei der Verwendung bestimmter Werkzeugen (z. B. Google Translator) für die automatisierte Übersetzung von Texten, müssen diese bei einer Veröffentlichung im Internet entsprechend gekennzeichnet werden.

Zudem gibt die XZuFi-Spezifikation Version 2.3.1 vor, dass für alle verwendeten HTML-Tags die spitzen Klammern der Tags in XZuFi durch < (<) und > (>) codiert werden müssen.

Beispiel 1

Darstellung in Benutzeroberflächen:

Punkt 1
Punkt 2

Original HTML-Code:

<ul
    ><li>Punkt 1</li
    ><li>Punkt 2</li></ul
>

XZuFi konformer HTML-Code:

&lt;ul&gt;&lt;li&gt;Punkt 1&lt;/li&gt;&lt;li&gt;Punkt 2&lt;/li&gt;&lt;/ul&gt;

Beispiel 2:

Darstellung in der Benutzeroberfläche:

Wandsbek District Office – Citizen Service Department

Original HTML-Code:

<div lang="en-x-mtfrom-de">Wandsbek District Office – Citizen Service Department</div>

XZuFi konformer HTML-Code:

&lt;div lang=”en-x-mtfrom-de"&gt;Wandsbek District Office – Citizen Service Department;&lt;/div&gt;

Bei der Verwendung von HTML in XZuFi muss beachtet werden, dass die XZuFi-Spezifikation Version 2.3.1 (öffnet in neuem Tab) nicht grundsätzlich für alle Element der Datentypen xs:string, bzw. xzufi:String.LocalizedHTML die Verwendung von HTML erlaubt, sondern nur für ausgewählte Elemente, die längeren beschreibenden Text enthalten. Diese Vorgaben müssen eingehalten werden.

Konformität zu DIN SPEC 91379

Gemäß IT-Planungsrat-Beschluss 2019/16 (öffnet in neuem Tab) müssen alle IT-Verfahren, die dem Bund-Länder übergreifenden Datenaustausch oder dem Datenaustausch mit Bürgern und Wirtschaft dienen, konform zur DIN SPEC 91379 sei.

Für das PVOG bedeutet dies, dass alle Namen (im weiteren Sinne) im PVOG-Datenbestand entsprechend der DIN SPEC 91379 ausgeliefert und abgespeichert sein müssen.

In XZuFi 2.3.1 wird für die betroffenen Elemente der Datentyp din91379:datatype[A|B|C|D] verwendet.

Übertragung von Informationen im Rahmen der SDG-Verordnung

Die SDG-Verordnung der Europäischen Union (öffnet in neuem Tab) verpflichtet Deutschland als Mitgliedsstaat Informationen zu Rechte, Pflichten und Vorschriften, Informationen zu Verwaltungsleistungen und Informationen zu Hilfs- und Problemlösungsdiensten an die EU zu übertragen.

In Deutschland werden diese Informationen dezentral durch Bund, Länder und Kommunen gepflegt und vom Online-Gateway über die angeschlossenen Redaktionssysteme im XZuFi-Datenformat eingesammelt und dem Bund für die Übertragung an die EU bereitgestellt.

Alle drei Regelungsgegenstände (Informationen zu Rechten, Pflichten und Vorschriften, Informationen zu Verwaltungsleistungen und Informationen zu Hilfs- und Problemlösungsdiensten) müssen im XZuFi-Datenformat mithilfe der Datentypen für Verwaltungsleistungen beschrieben (XZuFi 2.3.1: Leistung) werden.

Das Kurzkonzept „LeiKa im Kontext SDG“ (öffnet in neuem Tab, Download) enthält eine detaillierte Beschreibung, Informationen übertragen werden müssen und welche XZuFi-Datenobjekte/-elemente in XZuFi 2.3.1 für die Übertragung von SDG-relevanten Leistungen dafür genutzt werden sollen.

XZuFi 2.3.1

XML-Wurzelelement

XZuFi 2.3.1
XZuFi 2.2.0

Für die Datenübertragung zum PVOG darf in den bereitgestellten XZuFi-Dateien ausschließlich der XZuFi-Datentyp <xzufi:transfer.operation.050502> als Wurzelelement verwendet werden.

Beispiel

<?xml version="1.0" encoding="UTF-8"?>
<xzufi:transfer.operation.050502
 produktbezeichnung=""
 produkthersteller=""
 produktversion=""
 xzufiVersion="2.3.1">
    …
    <xzufi:schreibe>
        …
    </xzufi:schreibe>
    …
</xzufi:transfer.operation.050502>

Für die Datenübertragung zum PVOG darf in den bereitgestellten XZuFi-Dateien ausschließlich der XZuFi-Datentyp <xzufi:transfer.operation.040502> als Wurzelelement verwendet werden.

Beispiel

<?xml version="1.0" encoding="UTF-8"?>
<xzufi:transfer.operation.040502
 produktbezeichnung=""
 produkthersteller=""
 produktversion=""
 xzufiVersion="2.0.0">
    …
    <xzufi:schreibe>
        …
    </xzufi:schreibe>
    …
</xzufi:transfer.operation.040502>

Für die Übertragung von Informationen zum Online-Gateways im Element <xzufi:schreibe nur die folgenden Elemente verwendet werden.

<xzufi:leistung (Verwaltungsleistung)
<xzufi:spezialisierung> (Spezialisierung einer Verwaltungsleistung)
<xzufi:organisationseinheit> (Organisationseinheit, inkl. Zuständigkeiten)
<xzufi:onlinedienst> (Online-Dienst, inkl. Zuständigkeiten)
<xzufi:formular> (Formular, inkl. Zuständigkeiten)

Nachrichten, die weitere Elemente enthalten, werden vom PVOG abgelehnt und nicht weiterverarbeitet.

Verarbeitungsanweisung für Objekte

Zum aktuellen Zeitpunkt wird die Bereitstellung von Delta-Lieferungen mit Verarbeitungshinweisen (wie in diesem Abschnitt beschrieben) vom Online-Gateway nicht unterstützt. Aktuell sind die angebundenen Redaktionssysteme nur in der Lage einen vollständigen Abzug aller Leistungsdaten bereitzustellen. Über einen Abgleich der aktuell gelieferten Daten mit dem bisherigen Gesamtdatenbestand des Online-Gateways werden gelöschte und geänderte Datensätze identifiziert und im Gesamtdatenbestand nachgezogen.

Bei konkretem Bedarf kann die Verarbeitung von Delta-Lieferungen wie unten beschrieben in den Funktionsumfang des Online-Gateways aufgenommen werden.

XZuFi 2.3.1
XZuFi 2.2.0

Grundsätzlich erlaubt XZuFi Version 2.3.1 die Übertragung von Verarbeitungsanweisungen (Schreiben, Löschen) für die wesentlichen Datenobjekte (z. B. Leistungen, Organisationseinheiten, Online-Dienste, Spezialisierungen). Die Übertragung der Verarbeitungsanweisungen erfolgt über die Angabe der entsprechenden Transferoperation (<schreibe> und <loesche>) im Element <xzufi:transfer.operation.050502>.

Grundsätzlich erlaubt XZuFi Version 2.2 die Übertragung von Verarbeitungsanweisungen (Schreiben, Löschen) für die wesentlichen Datenobjekte (z. B. Leistungen, Organisationseinheiten, Online-Dienste, Spezialisierungen). Die Übertragung der Verarbeitungsanweisungen erfolgt über die Angabe der entsprechenden Transferoperation (<schreibe> und <loesche>) im Element <xzufi:transfer.operation.040502>.

Mithilfe dieser Transferoperationen können im Gesamtdatenbestand des Online-Gateways die folgenden Objekte angelegt, aktualisiert und gelöscht, werden:

Leistungen
Spezialisierung
Organisationseinheiten
Online-Dienste
Formulare.

Beispiel (Anlegen oder Aktualisieren einer Leistung):

<?xml version="1.0" encoding="UTF-8"?>
<xzufi:transfer.operation.050502>
    …
    <xzufi:schreibe>
        <xzufi:leistung>
            <xzufi:id schemeAgencyID="S100002">
            S1000020010000006848
            </xzufi:id>
            …
        </xzufi:leistung>
    </xzufi:schreibe>
</xzufi:transfer.operation.050502>

Beispiel (Anlegen oder Aktualisieren einer Organisationseinheit):

Für die Geschäftsobjekte Organisationseinheit und Online-Dienst gibt es jeweils zwei mögliche Datentypen (Organisationseinheit und OrganisationseinheitErweitert, bzw. Onlinedienst und OnlinedienstErweitert) in XZuFi 2.3.1. Dementsprechend muss hier der verwendete Datentyp über das Attribut xsi:type explizit angegeben werden.

<?xml version="1.0" encoding="UTF-8"?>
<xzufi:transfer.operation.050502>
    …
    <xzufi:schreibe>
        <xzufi:organisationseinheit xsi:type="xzufi:OrganisationseinheitErweitert">
            <xzufi:id schemeAgencyID="S100002">
            S1000020020000001234
            </xzufi:id>
            …
        </xzufi:organisationseinheit>
    </xzufi:schreibe>
</xzufi:transfer.operation.050502>

Beispiel (Löschen einer Leistung):

<?xml version="1.0" encoding="UTF-8"?>
<xzufi:transfer.operation.050502>
    …
    <xzufi:loesche>
        <xzufi:klasse listURI="urn:xoev-de:fim:codeliste:xzufi.transfertyp"
        listVersionID="1">
            <code>001</code>
            <name>Leistung</name>
        </xzufi:klasse>
        <xzufi:id schemeAgencyID="S100002">
        S1000020010000006848
        </xzufi:id>
    </xzufi:loesche>
</xzufi:transfer.operation.050502>

info

Auf welchen Verwaltungsobjekte die Verarbeitungsanweisungen angewendet werden können, ist in der XZuFi-Spezifikation Version 2.3.1 festgelegt. Der Datentyp wird über den Code des Datentyps im Element <xzufi:klasse> angegeben.

Identifikation von Verwaltungsleistung

Die eindeutige Identifikation einer Verwaltungsleistung (Abschnitt: <xzufi:leistung>) erfolgt über das Element <xzufi:id> (siehe auch Abschnitt "Eindeutige Identifikation von Objekten").

Beispiel (Leistung aus Hamburg):

<xzufi:transfer.operation.050502>
    …
    <xzufi:leistung>
        …
        <xzufi:id schemeAgencyID="S100002">
        S1000020010000006848
        </xzufi:id>
        …
    </xzufi:leistung>
    …
</xzufi:transfer.operation.050502>

Regionale Gültigkeit von Verwaltungsleistungen

Über das Element <xzufi:gueltigkeitGebietID> muss angegeben werden, für welches Gebiet die allgemeinen Leistungsdaten (z. B. Textmodule) gültig sind. Ergänzungen und Abweichungen hinsichtlich der allgemeinen Leistungsdaten für Teilgebiete müssen mithilfe von Spezialisierungen ausgedrückt werden (siehe Abschnitt „Spezialisierung von Verwaltungsleistungen“).

Für die Angabe ist der zwölfstellige Amtliche Regionalschlüssel (ARS) zu verwenden. Zum Beispiel:

000000000000 (Bund)
090000000000 (Bayern)
010510000000 (Landkreis Dithmarschen)
010010000000 (Stadt Flensburg).

Beispiel (Leistung aus Hamburg):

<xzufi:transfer.operation.050502>
    …
    <xzufi:leistung>
        …
        <xzufi:gueltigkeitGebietID schemeAgencyID="S100002">
        020000000000
        </xzufi:gueltigkeitGebietID>
        …
    </xzufi:leistung>
    …
</xzufi:transfer.operation.050502>

Fachliche Klassifizierung einer Verwaltungsleistung

Die fachliche Klassifizierung einer Verwaltungsleistung geschieht zweistufig. Zunächst erfolgt die Angabe des LeiKa-Typs über das Element <xzufi:typisierung> im Datentyp <xzufi:Leistung>.

Dabei ist zu beachten, dass über das Online-Gateway neben den klassischen Verwaltungsleistungen (Typ 1 bis 5) auch weitere Informationen in mithilfe von XZuFi-Leistungsobjekte übertragen werden (Typ 6 – 12).

Das Element <xzufi:typisierung> muss zwingend angegeben werden.

Beispiel:

<xzufi:transfer.operation.050502>
    …
    <xzufi:schreibe>
        <xzufi:leistung>
            …
            <xzufi:typisierung
            listURI="urn:de:fim:leika:typisierung"
            listVersionID="20240101">
                <code>11</code>
            </xzufi:typisierung>
            …
        </xzufi:leistung>
    </xzufi:schreibe>
    …
</xzufi:transfer.operation.050502>

Darüber hinaus muss jeder Leistung mindestens ein LeiKa-Schlüssel zugeordnet werden. Leistungen ohne LeiKa-Schlüssel werden nicht in den Gesamtdatenbestand des Online-Gateways übernommen.

XZuFi 2.3.1
XZuFi 2.2.0

Die Zuordnung geschieht über das Element <xzufi:referenzLeistungsschluessel> im Element <xzufi:leistung>. Um fehlerhafte LeiKa-Schlüssel überhaupt erkennen zu können, muss über das Attribut schemeVersionID des Elements <xzufi:referenzLeistungsschluessel> die Version des Leistungskatalogs mitgegeben werden, die im Redaktionssystem verwendet wird. Das Attribut schemeURI muss auf den Wert urn:de:fim:leika:leistung gesetzt werden.

Beispiel (Anlegen oder Aktualisieren einer Leistung):

<xzufi:transfer.operation.050502>
    …
    <xzufi:schreibe>
        <xzufi:leistung>
            …
            <xzufi:referenzLeistungsschluessel schemeURI="urn:de:fim:leika:leistung"
            schemeVersionID="20240818">
            09000000025743
            </xzufi:referenzLeistungsschluessel>
            …
        </xzufi:leistung>
    </xzufi:schreibe>
    …
</xzufi:transfer.operation.050502>

Die Zuordnung geschieht über das Element <xzufi:referenzLeika> im Element <xzufi:leistung>. Um fehlerhafte LeiKa-Schlüssel überhaupt erkennen zu können, muss über das Attribut listVersionID des Elements <xzufi:referenzLeika> die Version des Leistungskatalogs mitgegeben werden, die im Redaktionssystem verwendet wird. Das Attribut listURI muss auf den Wert urn:de:fim:leika:leistung gesetzt werden.

Beispiel (Anlegen oder Aktualisieren einer Leistung):

<xzufi:transfer.operation.040502>
    …
    <xzufi:schreibe>
        <xzufi:leistung>
            …
            <xzufi:typisierung listURI="urn:de:fim:leika:leistung"
                listVersionID="20200702">
                <code>11083900129902</code>
                <token>LEIKA_LEISTUNG_BEZEICHNUNG</token>
            </xzufi:typisierung>
            …
        </xzufi:leistung>
    </xzufi:schreibe>
    …
</xzufi:transfer.operation.040502>

In Einzelfällen mag es vorkommen, dass es noch keinen LeiKa-Schlüssel für eine neue Verwaltungsleistung gibt (z. B. neuer LeiKa-Schlüssel beantragt aber noch nicht ausgestellt). In diesen Fällen ist es zulässig vorübergehend einen Ersatzschlüssel zu verwenden. Der Ersatzschlüssel muss wie folgt aufgebaut werden:

TMP_BL_XXXXXXXXXXXXXX

Dabei sind die einzelnen Teile der Namenskonvention wie folgt zu verstehen:

TMP	Feste Angabe TMP
BL	Zweistellige Kennziffer Bundesland nach Amtlichem Regionalschlüssel (z. B. 02 für Freie und Hansestadt Hamburg). Für den Bund wird die Kennziffer 00 verwendet.
XXXXXXXXXXXXXX	Beliebige 14-stellige Ziffernfolge.

Beispiel:

TMP_02_02123456789012

Vorübergehende Ersatzschlüssel müssen ersetzt werden, sobald die offiziellen LeiKa-Schlüssel verfügbar sind.

Beschreibung einer Verwaltungsleistung

Die inhaltliche Beschreibung von Verwaltungsleistungen erfolgt mithilfe von XML-Elementen vom Typ <Textmodul>. Mithilfe einer Code-Angabe wird dem generischen XML-Element eine fachliche Bedeutung zugeordnet. Jedes Textmodul mit einem bestimmten Code (z. B. Code 14) darf im Element <xzufi:leistung> jeweils nur einmal vorkommen.

Die Darstellung einer in XZuFi beschriebenen Leistung in einer grafischen Benutzerschnittstelle kann dann entsprechend erfolgen. Nachfolgend werden die gängigen Codes erklärt und die Verwendung in der grafischen Benutzerschnittstelle an Beispielen demonstriert.

Code	Bedeutung	Grafische Darstellung (Beispiel Bayern-Portal)
02	Leistungsbezeichnung (Offizieller Name der Leistung in der Verwaltung)
03	Leistungsbezeichnung II (Bürgernaher Leistungsname)
05	Kurztext
06	Volltext
07	Handlungsgrundlagen
09	Voraussetzungen
11	Verfahrensablauf
14	Formulare
15	Weiterführende Informationen
16	Hinweise (Besonderheiten)
18	Urheber
22	Zuständige Stelle
23	Ansprechpunkt
24	Teaser
25	Rechtsbehelf

Für die Verwendung von Textmodulen gelten folgende Vorgaben:

Es muss mindestens ein Textmodul mit dem Code 02 oder ein Textmodul mit dem Code 03 vorhanden sein.
Es muss mindestens ein Textmodul mit dem Code 06 vorhanden sein.

URL zur Leistung im ursprünglichen Verwaltungsportal

Damit der Nutzer im Kontext der Suche nach Leistungen auf die originalen Leistungen im ursprünglichen Verwaltungsportal (Quellsystem) zugreifen kann, besteht die Möglichkeit, die dafür notwendigen URLs im XZuFi-Datensatz anzugeben. Die URL für die Weiterleitung ist eine Pflichtangabe im XZuFi-Datensatz und muss für jede Leistung entsprechend mitgegeben werden. Über den im <xzufi:zugangskanal> enthaltenen Code wird beschrieben, wie der Zugang zum ursprünglichen Verwaltungsportal erfolgt.

Beispiel

<xzufi:transfer.operation.050502>
    …
    <xzufi:schreibe>
        …
        <xzufi:leistung>
            …
            <xzufi:modulUrsprungsportal languageCode="de">
                <xzufi:uri>https://www.deep-link-zum-ursprungsportal.de</xzufi:uri>
                <xzufi:titel>Titel</xzufi:titel>
                <xzufi:zugangskanal listURI="urn:xoevde:
                fim:codeliste:xzufi.zugangskanal" listVersionID="1">
                    <code>000</code>
                </xzufi:zugangskanal>
            </xzufi:modulUrsprungsportal>
            …
        </xzufi:leistung>
        …
    </xzufi:schreibe>
    …
</xzufi:transfer.operation.050502>

Spezialisierung von Verwaltungsleistungen

Der XZuFi Standard ermöglicht die grundsätzliche Beschreibung einer Verwaltungsleistung für ein größeres Gebiet (z. B. Bundesland) und Anpassungen der Beschreibung für Teilgebiete (z. B. Landkreise oder Kommunen). Die Anpassungen werden mithilfe von Spezialisierungen vorgenommen.

Jede Spezialisierung muss eindeutig identifizierbar sein. Die Identifikation einer Spezialisierung (Abschnitt: <xzufi:spezialisierung>) erfolgt über das Element <xzufi:id> (siehe auch Abschnitt „Eindeutige Identifikation von Objekten“).

Beispiel

<xzufi:transfer.operation.050502>
    …
    <xzufi:schreibe>
        …
        <xzufi:spezialisierung>
            <xzufi:id schemeAgencyID="L100012">
            L1000120040000006848
            </xzufi:id>
            …
        </xzufi:spezialisierung>
    </xzufi:schreibe>
</xzufi:transfer.operation.050502>

XZuFi 2.3.1
XZuFi 2.2.0

Für jede Spezialisierung muss im Element <xzufi:leistungID> die ID der zu spezialisierenden Leistungen angegeben werden und im Element <xzufi:gebietID> das Teilgebiet, für das die Spezialisierung angewendet werden muss. Die Angabe der Gebiete erfolgt über den Amtlichen Regionalschlüssel (ARS). Es können pro Spezialisierung mehrere ARS angegeben werden. Dabei ist zu beachten, dass die angegebenen Gebiete der Spezialisierung in die Gebiete der eigentlichen Verwaltungsleistung fallen.

Beispiel (Spezialisierung einer Leistung aus Schleswig-Holstein für Flensburg und Kiel)

<xzufi:transfer.operation.050502>
    …
    <xzufi:schreibe>
        …
        <xzufi:spezialisierung>
            <xzufi:leistungID>L1000120010000006848</xzufi:leistungID>
            <xzufi:gebietID schemeAgencyID="L100012">
            010010000000
            </xzufi:gebietID>
            <xzufi:gebietID schemeAgencyID="L100012">
            010020000000
            </xzufi:gebietID>
            …
        </xzufi:spezialisierung>
    </xzufi:schreibe>
</xzufi:transfer.operation.050502>

Für jede Spezialisierung muss im Element <xzufi:idLeistung> die ID der zu spezialisierenden Leistungen angegeben werden und im Element <xzufi:idGebiet> das Teilgebiet, für das die Spezialisierung angewendet werden muss. Die Angabe der Gebiete erfolgt über den Amtlichen Regionalschlüssel (ARS). Es können pro Spezialisierung mehrere ARS angegeben werden. Dabei ist zu beachten, dass die angegebenen Gebiete der Spezialisierung in die Gebiete der eigentlichen Verwaltungsleistung fallen.

Beispiel (Spezialisierung einer Leistung aus Schleswig-Holstein für Flensburg und Kiel)

<xzufi:transfer.operation.040502>
    …
    <xzufi:schreibe>
        <xzufi:spezialisierung>
            <xzufi:idLeistung>L1000120010000006848</xzufi:idLeistung>
            <xzufi:idGebiet schemeAgencyID="L100012">
            010010000000
            </xzufi:idGebiet>
            <xzufi:idGebiet schemeAgencyID="L100012">
            010020000000
            </xzufi:idGebiet>
            …
        </xzufi:spezialisierung>
    </xzufi:schreibe>
</xzufi:transfer.operation.040502>

Die eigentliche Anpassung der Verwaltungsleistung erfolgt über das XML-Element <xzufi:modulSpezialisiert>. Innerhalb des XML-Elements muss zunächst angegeben werden, ob der Inhalt eines bestimmten Leistungsmoduls nur ergänzt werden soll (<xzufi:ersetzung>false</xzufi:ersetzung>)oder ob der Inhalt komplett ersetzt werden soll (<xzufi:ersetzung>true</xzufi:ersetzung>).

Beispiel (Ergänzende Spezialisierung)

<xzufi:transfer.operation.050502>
    …
    <xzufi:schreibe>
        …
        <xzufi:spezialisierung>
            …
            <xzufi:modulSpezialisiert>
                …
                <xzufi:ersetzung>false</xzufi:ersetzung>
            </xzufi:modulSpezialisiert>
            …
        </xzufi:spezialisierung>
    </xzufi:schreibe>
</xzufi:transfer.operation.050502>

Im XML-Element <xzufi:modulSpezialisiert> wird über das XML-Element <xzufi:modul> auch die inhaltliche Anpassung (über das XML-Element <xzufi:inhalt>) und die Zuordnung zu dem anzupassenden Leistungsmodul der übergeordneten Verwaltungsleistung definiert. Bei Leistungsmodulen vom Typ Textmodul, wird die Zuordnung über das XML-Element <xzufi:leikaTextModul> vorgenommen.

Beispiel

<xzufi:transfer.operation.050502>
    …
    <xzufi:schreibe>
        …
        <xzufi:spezialisierung>
            …
            <xzufi:modulSpezialisiert>
                …
                <xzufi:modul xsi:type="Textmodul">
                    <xzufi:inhalt html="false" languageCode="de">
                    Ergänzende/Ersetzende Beschreibung (Spezialisierung)
                    </xzufi:inhalt>
                    <xzufi:leikaTextModul>
                        <code>06</code>
                    </xzufi:leikaTextModul>
                </xzufi:modul>
            </xzufi:modulSpezialisiert>
        </xzufi:spezialisierung>
    </xzufi:schreibe>
</xzufi:transfer.operation.050502>

Folgendes Beispiel aus dem BayernPortal verdeutlicht die Möglichkeiten der Ausprägungen von XZuFi Spezialisierungen.

Beispiel

Zunächst die textuelle Beschreibung der Fristen für die Verwaltungsleistung „Gewerbeanzeige; Gewerbeanmeldung“ im Bundesland Bayern im XZuFi-Format.

<xzufi:transfer.operation.050502>
    …
    <xzufi:schreibe>
        …
        <xzufi:leistung>
            …
            <xzufi:modulText>
                <xzufi:inhalt html="false" languageCode="de">
                Die Anzeige ist vor Beginn der gewerblichen Tätigkeit vorzunehmen.
                </xzufi:inhalt>
                <xzufi:leikaTextmodul listURI="urn:de:xzufi:codeliste:leistungstextmodulleika" listVersionID="20150601">
                    <code>13</code>
                </xzufi:leikaTextmodul>
            </xzufi:modulText>
        </xzufi:leistung>
    </xzufi:schreibe>
</xzufi:transfer.operation.050502>

Die folgende Abbildung zeigt die zugehörige Darstellung der Verwaltungsleistung im bayrischen Verwaltungsportal.

Darstellung allgemeingültiger Informationen am Beispiel Bayern-Portal

Anschließend wird mithilfe einer Spezialisierung der textuellen Beschreibung der Frist für die Verwaltungsleistung „Gewerbeanzeige; Gewerbeanmeldung“ für das Gebiet der Stadt Ingolstadt angepasst.

Beispiel (Spezialisierung einer Leistung aus Schleswig-Holstein für Flensburg und Kiel)

<xzufi:transfer.operation.050502>
    …
    <xzufi:schreibe>
        …
        <xzufi:spezialisierung>
            …
            <xzufi:gebietID schemeAgencyID="L100042">
                091610000000
            </xzufi:gebietID>
            <xzufi:modulSpezialisiert>
                <xzufi:modul xsi:type="xzufi:Textmodul">
                    <xzufi:inhalt html="false" languageCode="de">
                    Die Anzeige ist in Ingolstadt mindestens mit einer vierwöchigen Frist vor Beginn der gewerblichen Tätigkeit aufzunehmen.
                    </xzufi:inhalt>
                    <xzufi:leikaTextmodul listURI="urn:de:xzufi:codeliste:leistungstextmodulleika" listVersionID="20150601">
                        <code>13</code>
                    </xzufi:leikaTextmodul>
                </xzufi:modul>
                <xzufi:ersetzung>false</xzufi:ersetzung>
            </xzufi:modulSpezialisiert>
        </xzufi:spezialisierung>
    </xzufi:schreibe>
</xzufi:transfer.operation.050502>

Endpunkte​

Sicherstellen Datenkonsistenz​

Abruffrequenz​

Authentifizierung​

Verschlüsselung der Übertragungswege​

Komprimierung​

Anzahl und Ablage der XZuFi-Dateien​

Namenskonventionen XZuFi-Dateien​

Verarbeitungsreihenfolge XZuFi-Dateien​

Aufbewahrungsfristen XZuFi-Dateien​

Nachrichtenformat​

Angabe der verwendeten Codelisten​

Eindeutige Identifikation von Objekten​

Gültigkeitszeiträume für Objekte​

Unterstützte Leistungstypen​

Geografische Angaben​

Anschriften von Organisationseinheiten​

Hierarchien von Organisationseinheiten​

Mehrsprachigkeit​

Verwenden von HTML in XZuFi​

Konformität zu DIN SPEC 91379​

Übertragung von Informationen im Rahmen der SDG-Verordnung​

XML-Wurzelelement​

Verarbeitungsanweisung für Objekte​

Identifikation von Verwaltungsleistung​

Regionale Gültigkeit von Verwaltungsleistungen​

Fachliche Klassifizierung einer Verwaltungsleistung​

Beschreibung einer Verwaltungsleistung​

URL zur Leistung im ursprünglichen Verwaltungsportal​

Spezialisierung von Verwaltungsleistungen​

Endpunkte

Sicherstellen Datenkonsistenz

Abruffrequenz

Authentifizierung

Verschlüsselung der Übertragungswege

Komprimierung

Anzahl und Ablage der XZuFi-Dateien

Namenskonventionen XZuFi-Dateien

Verarbeitungsreihenfolge XZuFi-Dateien

Aufbewahrungsfristen XZuFi-Dateien

Nachrichtenformat

Angabe der verwendeten Codelisten

Eindeutige Identifikation von Objekten

Gültigkeitszeiträume für Objekte

Unterstützte Leistungstypen

Geografische Angaben

Anschriften von Organisationseinheiten

Hierarchien von Organisationseinheiten

Mehrsprachigkeit

Verwenden von HTML in XZuFi

Konformität zu DIN SPEC 91379

Übertragung von Informationen im Rahmen der SDG-Verordnung

XML-Wurzelelement

Verarbeitungsanweisung für Objekte

Identifikation von Verwaltungsleistung

Regionale Gültigkeit von Verwaltungsleistungen

Fachliche Klassifizierung einer Verwaltungsleistung

Beschreibung einer Verwaltungsleistung

URL zur Leistung im ursprünglichen Verwaltungsportal

Spezialisierung von Verwaltungsleistungen