Version

1.0.0

Fristen

Fachliche Kategorie	Technische Kategorie
Stammdaten der Leistung	XZuFi-basierte Parameter ohne direkten Onlinedienst-Bezug

Fachliche Bedeutung

Fristen

Wertemenge

Eine optionale komplexe Datenstruktur modulFrist, die drei Elemente enthält:

• frist: Eine Menge verschiedener möglicher Fristen. Jede Frist enthält selbst wieder die folgenden Elemente:
  • typ: Codierung des Frist-Typs. Details siehe XZuFi-Dokumentation zu Fristtyp_Erweiterbar.
  • fristauswahl: Eines der beiden folgenden Elemente
    • fristDauer: strukturierte Angabe in Form von von/bis-Dauer
    • fristStichtag: strukturierte Angabe in Form von von/bis-Datum
  • beschreibung: Eine Beschreibung der Frist als internationalisierte Zeichenkette
  • positionAuswahl: Position in der Darstellung aller Fristen pro Modul (Ganzzahl)
  • gueltigkeit: Der Gültigkeitszeitraum, zu dem die Daten dieses Moduls gültig sind.
• beschreibung: textuelle Erläuterungen zu den Fristen (internationalisierte Zeichenkette)
• weiterführenderLink: Link zu weiteren Informationen in Form einer internationalisierten Datenstruktur HyperlinkErweitert.

warnung

Der XZuFi-Standard macht keine Aussage über die Interpretation einer Frist-Dauer-Angabe. So bleibt dort undefiniert, wann die Frist beginnt. Es ist daher fachlich zu klären, ob eine Frist-Dauer-Angabe relativ zum Datum der Antragstellung oder relativ zu einem anderen Datum zu interpretieren ist. Das Ergebnis dieser Klärung ist in der Onlinedienst-Dokumentation zu dokumentieren und in den Texten der Antragsdialoge unmissverständlich zu erklären. Kann überregional keine einheitliche Regelung zur Interpretation von Frist-Dauer-Angaben erreicht werden, muss in den Anbindungsleitfäden klar darauf hingewiesen werden, dass die textuellen beschreibungen der Frist-Abgaben jeweils eine Festlegung liefern müssen, z.B. "Die Frist innerhalb der Sie einen Widerspruch gegen den Bescheid eingelegen können. Die Frist beginnt mit dem Datum des Bescheides."

Wenn hier sogar ein Bedarf für eine Parameter-basierte Steuerung besteht, dann bietet es sich an, dies über Individual-Parameter zu steuern. So könnte ein Parameter mit dem Namens-Schlüssel efa.custom.widerspruchsfrist.beginn und den beiden möglichen Werten bescheiddatum und bescheidzustelldatum vom Onlinedienst individuell festlegt werden. Der Onlinedienst kann dann anhand dieses Parameters seine Dialoge, Texte und ggf. seine Geschäftslogik steuern.

Das modulFrist, das nur maximal einmal vorhanden sein kann, kann selbst wieder mehrere frist-Elemente enthalten, wobei jedes dieser frist-Elemente einen eigenen typ hat. Als mögliche Fristtypen stehen in der Code-Liste urn:xoev-de:fim:codeliste:xzufi.fristtyp die folgenden Werte zur Verfügung:

Code	Beschreibung
001	Anhörungsfrist
002	Antragsfrist
003	Aufbewahrungsfrist
005	Geltungsdauer
006	Genehmigungsfiktion
009	Widerspruchsfrist

Das typ-Element ist in der XZuFi-Spezifikation aber als Datentyp xzufi:Fristtyp_Erweiterbar spezifiziert, kann also auch Typ-Codes aufnehmen, die nicht in der Code-Liste vorhanden sind. Diese werden dann in einem Element typ/nichtgelisteterWert mit Datentyp xoev-lc:String.Latin abgelegt. Hier kann z.B. ein selbst-definierter Code (z.B. X01) abgelegt werden, um dem Onlinedienst einen besonderen Fristtyp zu signalisieren. Die faktische Code-Listen-Erweiterung um diese selbst-definierten Codes muss dann in der Dokumentation des Onlinedienstes und im zugehörigen Roll-Out-Plan dokumentiert werden, damit die Redakteure dieses Feature korrekt nutzen können.

Jedes frist-Element kann seine eigenen Gültigkeits-Zeiträume haben, so dass ein Redakteur bereits im Januar eine Antragsfrist für das erste Halbjahr und eine abweichende Antragsfrist für das zweite Halbjahr einpflegen kann. Da ein frist-Element auch mehrere Gültigkeits-Zeiträume haben kann, ist es möglich ein frist-Element in jedem ersten Halbjahr der folgenden zehn Jahre gültig zu setzen, während ein anderes frist-Element in jedem zweiten Halbjahr der folgenden zehn Jahre gültig ist. Die Angabe einer frist ohne gueltigkeit bedeutet, dass diese Angabe zu jedem Zeitpunkt gültig ist.

Es muss bei der Pflege der frist-Elemente aber sichgestellt werden, dass die Angaben typ und gueltigkeit so gewählt werden, dass zu keinem Zeitpunkt mehrere frist-Elemente mit demselben typ gleichzeitig gültig sind. Oder anders ausgedrückt: Zu jedem Zeitpunkt darf es höchstens ein gültiges frist-Element für jeden typ geben.

Für eine detaillierte Darstellung dieser Datenstruktur wird hier auf die XZuFi-Dokumentation verwiesen.

Verortung im Datenmodell

Die Fristen werden in einem optionalen Element modulFrist abgelegt, das Teil des Elements Leistung ist.

Codebeispiel XZuFi 2.2

info

• Das folgende Codebeispiel zeigt nicht alle Features des modulFrist-Elements.

    <xzufi:leistung>

      <xzufi:modulFrist>
        <xzufi:beschreibung languageCode="de">Sechs Wochen vor der vorgesehenen Inbetriebnahme</xzufi:beschreibung>
        <xzufi:beschreibung languageCode="en">Six weeks before the planned commissioning</xzufi:beschreibung>
      </xzufi:modulFrist>

    </xzufi:leistung>

Ermittlungsmöglichkeit PVOG API

Zunächst ermittelt der Onlinedienst die Daten der Leistungsbeschreibung (siehe Abschnitt Ermittlung der Daten der Leistungsbeschreibung mit Hilfe der PVOG-API).

In der Response findet sich ein Element modulFrist:frist[], das die gesuchten Informationen enthält. Von allen frist-Elementen muss der Onlinedienst diejenigen weiter auswerten, deren Element gueltigkeit[] ein Element enthält, das zeitlich mit den zeitlichen Daten der Antragsstellung¹ übereinstimmt.

Jedes frist-Element enthält entweder ein typ:code:code-Element, oder ein typ:nichtGelisteterWert-Element, das den typ der frist enthält.

Jedes frist-Element enthält weiterhin ein fristauswahl-Element, das wiederum ein fristDauer-Element oder ein fristStichtag-Element enthält. Ein fristDauer-Element besteht aus vier Angaben:

• dauer: Ganzzahl-Angabe der minimalen Frist
• einheit:code: Code der Einheit der minimalen Frist aus der Code-Liste urn:xoev-de:fim:codeliste:xzufi.zeiteinheit
• dauerBis: Ganzzahl-Angabe der maximalen Frist
• einheitBis:code: Code der Einheit der maximalen Frist aus der Code-Liste urn:xoev-de:fim:codeliste:xzufi.zeiteinheit

Ein fristStichtag-Element besteht aus zwei Elementen:

• von: Datum, zu dem die Frist beginnt
• bis: Datum, zu dem die Frist endet

Beide Elemente enthalten wiederum drei alternative Angaben datum, monatTag und tag, die das betreffende Datum spezifizieren. Die Alernativn erlauben es, das Datum absolut ("1. April 2025") oder wiederkehrend ("jährlich zum 31. Mai", "monatlich zum 21.") anzugeben.

Daneben enthält das modulFrist-Element weitere Angaben, wie einen internationalisierten Beschreibungstext und einen internationalisierten weiterführenden Link. Details können der API-Spezifikation entnommen werden.

Ermittlungsmöglichkeit FIT-Connect Routing API

Der Onlinedienst benutzt den Endpunkt /routes mit den URL-Parametern zur Identifikation des gesuchten Adressaten, z.B. leikaKey = <LeikaId der Leistung> und ars = <ARS des gesuchten Gebiets> und erhält eine JSON-Datenstruktur als Response.

In dieser Datenstruktur enthält das Element route[]:deadline:description, das einen internationalisierten Text enthält. Der Text beschreibt die Fristen in der angegebenen Sprache. Der Text wird dem Element beschreibung des modulText-Elements entnommen und beschreibt die potenziell komplexe Fristsetzung gesamtheitlich.

Die strukturierten Daten aus den frist-Element (XZuFi-Typ xzufi:FristMitTyp) stehen in der FIT-Connect Routing API Stand Q2/2024 nicht zur Verfügung.

Ermittlungsmöglichkeit DVDV API

(Der Parameter kann nicht über das DVDV-API ermittelt werden)

Best Practices

Bezüglich hyperlinkErweitert sind unbedingt die Hinweise zu Internationalisierten Datenstrukturen zu beachten!

Die Konfiguration von Fristen ist komplex und es ist ggf. nicht zu erwarten, dass alle Redaktionssysteme alle Features der xzufi:FristMitTyp-Datenstruktur unterstützen. Beispielsweise könnte die Angabe eines nichtGelisteterWert-Wertes nicht möglich sein. Auch ist ggf. eine komplexe fachliche Fristen-Regelung nicht oder nur mit extremem Aufwand in der Datenstruktur abzubilden: Wenn eine Frist z.B. immer am zweiten Dienstag im Kalendermonat beginnt, so müsste für jeden Monat und auf unbestimmte Zeit in die Zukunft jeweils ein frist-Element angelegt werden. In einer solche Situation kann nur auf die Notwendigkeit einer strukturierten Frist-Beschreibung verzichtet werden. Statt dessen muss sich die Notwendigkeit der Parametrisierung auf das Element frist/typ und frist/beschreibung beschränken - sofern eine Notwendigkeit für die Angabe von Parameter-Werten überhaupt fachlich gegeben ist. Das frist/beschreibung-Element enthält dann eine (internationalisierbare) natürlichsprachliche Beschreibung wie "Die Frist beginnt jeweils am zweiten Dienstag im Kalendermonat." Die Steuerung von Geschäftslogik im Onlinedienst bezüglich der Fristen (z.B. Abweisen von Antragswünschen außerhalb der Antragsfrist) ist dann nicht möglich.

Onlinedienste müssen so implementiert werden, dass sie gegenüber Fehlern in den Parameter-Werten tolerant sind und z.B. bei mehreren frist-Elementen vom gleichen typ und mit überlappender gueltigkeit nur eine Warnung anzeigen, dass die Anzeige der Frist für diesen Typ aktuell nicht möglich sei. Eine Steuerung der Geschäftslogik, z.B. das Ablehnen einer Antragstellung bei fehlender oder fehlerhafter Frist-Angabe in den Parametern, ist aus diesen Gründen riskant und muss sorgfältig fachlich geprüft werden. In jedem Fall ist eine solche Logik sorgfältig in der Dokumentation des Onlinedienstes zu dokumentieren.

Footnotes

1. Zeitpunkt der Antragstellung oder Zeitpunkt, für den der Antrag gestellt wird, etc. Diese Regeln sind fachlich jeweils für die Leistung zu klären ↩