Verfahrenskonfiguration Pro

> Zurück zur Hauptseite DiPlanCockpit Pro für Mandanten-Administratoren (M-A)

Die Verfahrenskonfiguration, kurz VK, ist das zentrale Element in der Konfiguration. Über Verfahrenskonfigurationen wird je nach Verfahrenssteuerungstyp (kurz V-Typ) der Ablauf des Verfahrens festgelegt. Das heißt, die VK bestimmt den Ablauf des Verfahrens und die vorgesehenen Aufgaben innerhalb eines Verfahrens. Außerdem enthält sie grundlegende Einstellungen zur Zeitplanung.

Es ist eine Default-Stellung für die kommunale Bauleitplanung verfügbar, die Mandanten spezifisch angepasst werden kann. Es lassen sich beliebig viele unterschiedliche VKs konfigurieren, die für jeden V-Typ eigene Abläufe definieren.

Wichtige Hinweise

Jede VK bezieht sich auf Codelisten - sowohl feste als auch (vom Mandanten) änderbare Codelisten. Um Fehler zu vermeiden, muss sichergestellt werden, dass VK und änderbare Codelisten stets auf dem gleichen Stand sind. Das bedeutet:

• Anpassungen in einer VK können Konsequenzen auf änderbare Codelisten haben. = Anpassungen IMMER für VK und änderbare Codelisten umsetzen.
• Entfernung von Codes in änderbaren Codelisten müssen mit Umsicht vorgenommen und mögliche Auswirkungen auf VK(s) geprüft und bei Bedarf umgesetzt werden.
• Einfacher ist es, Einträge / Codes in änderbaren Codelisten ergänzend vorzunehmen, also den Bestand um neue Einträge zu ergänzen.
• Beim Hochladen ist die Reihenfolge wichtig: Angepasste, änderbare Codelisten müssen zuerst hochgeladen werden. Danach folgt die angepasste VK. Wird die Reihenfolge nicht eingehalten, kann es zur Fehlermeldung kommen.
• Für die Änderung von VK und Codelisten empfiehlt sich der Einsatz eines professionellen XLM-Tools, das Validierungs-Funktionen bietet. Diese laufen i.d.R. im Hintergrund ab und zeigen optisch Fehler an, wie falsche Einrückungen im XML-Baum oder fehlende Bestandteile wie der End-Tag eines Elements. Die Validierung erfolgt gegen die Datei diplanung.xsd.

Mehr Details zur Mandanten spezifischen Anpassung von VK + änderbaren Codelisten siehe Abschnitt: Mandanten spezifische Anpassung und Erstellung von Verfahrenskonfigurationen.

Elemente der Verfahrenskonfiguration im Frontend

Der folgende Screenshot mit farblichen Beschriftungen und Markierungen zeigt den Reiter Aufgaben im DiPlanCockpit Pro. Darin sind die meisten Elemente der VK zu sehen, die in den folgenden Abschnitten erklärt werden.

Die gelbe Markierung zeigt jeweils exemplarisch ein Element an, der nächstliegende rote Kasten mit Text die Bezeichnung.

Struktur der Verfahrenskonfiguration

In den folgenden Abschnitten wird eine beispielhafte VK anhand von Screenshots erläutert. Die Zahlen am linken Rand der Screenshots zeigen die Zeilennummern der XML-Datei. Insgesamt sind es im Beispiel 4836. Um eine kompakte Darstellung zu ermöglichen, sind die Bereiche, die für die jeweilige Erläuterung irrelevant sind, eingeklappt. Das ist an den kleinen blauen Pfeilen rechts von den Zeilennummern zu erkennen. Ein Pfeil nach unten bedeutet, dass der Abschnitt aufgeklappt ist. Ein Pfeil nach rechts hingegen heißt, dass an dieser Stelle noch weitere Zeilen sind, die lediglich nicht angezeigt werden. Die Anzahl der ausgeblendeten Zeilen ist in Klammern angegeben. Die Form der Darstellung ist dem verwendeten Programm geschuldet. Bei der Verwendung anderer Programme kann die visuelle Darstellung der XML abweichen.

Screenshot mit Überblick der VK

Erläuterung der Grundstruktur

Den äußeren Rahmen bildet die Angabe des Codes für die jeweilige VK. Im dargestellten Beispiel ist dies der Code 6100. Für jeden gewünschten V-Typ ist eine separate Datei mit einem eindeutigen Code erforderlich. Dieser Code MUSS in der Codeliste Code.Verfahrenssteuerung enthalten sein.

Unterhalb der Verfahrenssteuerung und einmal eingerückt folgt die Angabe der gewünschten Planarten und Verfahrensarten für die VK. Die angegebenen Planarten sollten fachlich zum Verfahrenssteuerungstyp passen. Zulässige Kombinationen sind im XRepository in der Codeliste Planart aufgeführt. Der Eintrag in der Spalte "Übergeordneter Wert" der Codeliste bezeichnet den passenden Verfahrenssteuerungstyp.

An die Verfahrensarten schließen sich allgemeine Angaben zur Zeitplanung an. Anschließend folgt der Hauptteil der VK mit der Auflistung aller Verfahrensschritte. Diese enthalten jeweils Verfahrensteilschritte, Unterverfahrensteilschritte, Aufgaben, Unteraufgaben und schließlich die ActionItems.

Sämtliche ActionItems sind im Detail auf einer eigenen Unterseite beschrieben. Auf dieser Seite folgt eine Erläuterung der übrigen Elemente der VK.

Erläuterung der einzelnen Abschnitte

Zeitplanung

Im Abschnitt zur Zeitplanung wird festgelegt, ob ein Monitoring vorgesehen ist. Im dargestellten Beispiel ist es vorgesehen.

Außerdem wird festgelegt, welcher Termin als Prognosestarttermin dienen soll. Von diesem geht die gesamte Zeitplanung aus. Im Beispiel ist es der Termin "Grobabstimmung". Angegeben ist der entsprechende Code "grobabstimmung" aus der Codeliste Code.Sitzungen, alternativ ist auch ein Code aus Code.SonstigeTermin möglich.

Name	Zweck
monitoring	Angabe, ob ein Monitoring vorgesehen ist.
prognosestarttermin	Definiert den Prognosestarttermin, von dem die Zeitplanung ausgeht.

Verfahrensschritt

Ein Verfahrensschritt ist die oberste Ebene in der Unterteilung eines Verfahrens in mehrere Abschnitte. Er wird durch die Angabe des Codes aus Code.Verfahrensschritte bestimmt. Außerdem erfolgt die Angabe, ob mehrere Durchgänge möglich sein sollen. Aktuell werden Durchgänge auf Ebene der Verfahrensschritte durch das Cockpit nicht unterstützt, sodass die Angabe von "ja" keinen Effekt hat.

Jeder Verfahrensschritt enthält beliebig viele Verfahrensteilschritte. Es ist möglich keinen Verfahrensteilschritt anzugeben, dann wird der Verfahrensschritt jedoch nicht im Cockpit sichtbar.

Die Reihenfolge der Verschachtelung (Verfahrensschritt > Verfahrensteilschritt > Unterverfahrensteilschritt) muss eingehalten werden. In einen Verfahrensschritt direkt einen Unterverfahrensteilschritt einzufügen ist nicht zulässig. Ebenso wenig ist es zulässig, innerhalb eines Verfahrensteilschritts oder einer tieferen Ebene, Verfahrensschritte zu ergänzen.

Name	Zweck
verfahrensteilschritt	Angabe eines untergeordneten Verfahrensteilschritts.
durchgaenge	Bestimmt ob Durchgänge möglich sein sollen. Angabe "ja" oder "nein". Im Cockpit werden Durchgänge für Verfahrensschritte nicht unterstützt.

Eine Besonderheit ist der Verfahrensschritt 9998. Dieser ist obligatorisch mitsamt des Verfahrensteilschritts und der darin aufgeführten Termine. Sie dienen insbesondere dazu, Termine der Stammdatenseite eintragen und speichern zu können. Der dargestellte Abschnitt kann unverändert übernommen werden.

Verfahrensteilschritt

Verfahrensteilschritte bilden die zweite Ebene in der Strukturierung des Verfahrensablaufs. Sie werden durch die Angabe eines Codes aus Code.Verfahrensteilschritte bestimmt. Außerdem erfolgt die Angabe, ob mehrere Durchgänge möglich sein sollen.

Zu jedem Verfahrensteilschritt können 0 bis beliebig viele Sitzungen und/oder sonstige Termine angegeben werden. Anschließend folgt die Auflistung aller Unterverfahrensteilschritte.

Name	Zweck
durchgaenge	Bestimmt ob Durchgänge möglich sein sollen. Angabe "ja" oder "nein".
sitzung	Sitzung innerhalb des Verfahrensteilschritts.
sonstigerTermin	Sonstiger Termin innerhalb des Verfahrensteilschritts.
unterverfahrensteilschritt	Angabe eines untergeordneten Unterverfahrensteilschritts.

Sitzung

Sitzungen werden über einen Code aus der Codeliste Code.Sitzungscodes bestimmt. Zusätzlich werden mögliche Ergebnisse über die Angabe eines Codes aus Code.Sitzungsergebnistyp festgelegt.

Jede Sitzung enthält die Information, ob sie zeitplanungsrelevant oder nicht zeitplanungsrelevant ist. Bei Relevanz für die Zeitplanung ist ebenfalls anzugeben ob Monitoring- und/oder Prognoserelevanz gewünscht ist. Zusätzlich ist die vorgesehene Wirkung in der Modellberechnung anzugeben. Dies erfolgt über die Verzögerung, Dauer und das Setzen auf Aktiv. Die möglichen Verzögerungsgründe werden hier nicht angegeben, sondern sind je nach V-Typ festgelegt und stammen aus der Codeliste Code.Verzoegerungsgrund.

Für nicht zeitplanungsrelevante Sitzungen ist nur anzugeben, welcher Datumstyp gewünscht ist. Dieser kann ein Datum (Angabe datum), Zeitraum (Angabe zeitraum) oder flexibel (Angabe datum_zeitraum) sein.

Name	Zweck
ergebnistyp	Codeliste der Ergebnistypen.
zeitplanungsrelevant oder nichtzeitplanungsrelevant	Legt Zeitplanungsrelevanz fest.
monitoringrelevant	Legt Monitoringrelevanz fest. Angabe "ja" oder "nein".
prognoserelevant	Legt Prognoserelevanz fest. Angabe "ja" oder "nein".
modellberechnung	Enthält Informationen zur Berechnung in der Zeitplanung.
verzoegerung	Bestimmt die Verzögerung. Angabe als ganze Zahl.
dauer	Bestimmt die Dauer. Angabe als ganze Zahl.
aktiv	(De-)aktiviert den Einfluss auf die Modellberechnung. Angabe "ja" oder "nein".
datumstyp	Beschreibt für nicht zeitplanungsrelevante Termine die Art der Datumsangabe. Angabe "datum", "zeitraum" oder "datum_zeitraum".

Sonstiger Termin

(Hinweis: Des Screenshot zeigt zwei verschiedene sonstige Termine, um möglichst viele Optionen der Konfiguration abzubilden.)

Sonstige Termine werden über einen Code aus der Codeliste Code.SonstigeTermin bestimmt. Zusätzlich wird in der Beschreibung der anzuzeigende Text zu dem sonstigen Termin definiert.

Jeder sonstige Termin enthält die Information, ob er zeitplanungsrelevant oder nicht zeitplanungsrelevant ist. Bei Relevanz für die Zeitplanung ist ebenfalls anzugeben ob Monitoring- und/oder Prognoserelevanz gewünscht ist. Zusätzlich ist die vorgesehene Wirkung in der Modellberechnung anzugeben. Dies erfolgt über die Verzögerung, Dauer und das Setzen auf Aktiv. Die möglichen Verzögerungsgründe werden hier nicht angegeben, sondern sind je nach V-Typ fest vorgegeben.

Für nicht zeitplanungsrelevante sonstige Termine ist nur anzugeben, welcher Datumstyp gewünscht ist. Dieser kann ein Datum (Angabe datum), Zeitraum (Angabe zeitraum) oder flexibel (Angabe datum_zeitraum) sein.

Sonstige Termine können außerdem über eine oder mehrere Angaben einer "eigenschaft" verfügen. Es stehen unterschiedliche Datentypen zur Verfügung (siehe Tabelle), mit denen weitere Informationen zu einem Termin angegeben werden können.

Name	Zweck
beschreibung	Anzuzeigende Beschreibung des sonstigen Termins.
zeitplanungsrelevant oder nichtzeitplanungsrelevant	Legt Zeitplanungsrelevanz fest.
monitoringrelevant	Legt Monitoringrelevanz fest. Angabe "ja" oder "nein".
prognoserelevant	Legt Prognoserelevanz fest. Angabe "ja" oder "nein".
modellberechnung	Enthält Informationen zur Berechnung in der Zeitplanung.
verzoegerung	Bestimmt die Verzögerung. Angabe als ganze Zahl.
dauer	Bestimmt die Dauer. Angabe als ganze Zahl.
aktiv	(De-)aktiviert den Einfluss auf die Modellberechnung. Angabe "ja" oder "nein".
datumstyp	Beschreibt für nicht zeitplanungsrelevante Termine die Art der Datumsangabe. Angabe "datum", "zeitraum" oder "datum_zeitraum".
eigenschaft	Beschreibt zusätzliche Informationen zu dem Termin. Umfasst "name", "typ" und optional "codelistName".
name	Benennt die "eigenschaft" des Termins. Angabe als String.
typ	Beschreibt das Datenformat der "eigenschaft" des Termins. Optionen: "TEXT", "FLOAT", "INTEGER", "BOOLEAN", "DATE", "URL", "CODELIST"
codelistName	Benennt die zu referenzierende Codeliste, wenn der "typ" der "eigenschaft" "CODELIST" ist.

Unterverfahrensteilschritt

Unterverfahrensteilschritte bilden die dritte Ebene in der Strukturierung des Verfahrensablaufs. Sie werden durch die Angabe des Codes aus Code.Unterverfahrensteilschritte bestimmt. Die Angabe bei "pflicht" legt fest, ob der Unterverfahrensteilschritt immer aktiviert sein soll (Angabe "ja"), oder ob er optional und manuell aktivierbar sein soll (Angabe "nein"). Außerdem erfolgt die Angabe, ob mehrere Durchgänge möglich sein sollen. Aktuell werden Durchgänge auf Ebene der Unterverfahrensteilschritte durch das Cockpit nicht unterstützt, sodass die Angabe von "ja" keinen Effekt hat.

In jedem Unterverfahrensteilschritt können 0 bis beliebig viele Aufgaben enthalten sein. Unterverfahrensteilschritte werden auch dann dargestellt, wenn sie keine Aufgaben enthalten.

Name	Zweck
pflicht	Legt fest, ob der Unterverfahrensteilschritt verpflichten oder optional ist. Angabe "ja" oder "nein".
durchgaenge	Bestimmt ob Durchgänge möglich sein sollen. Angabe "ja" oder "nein". Im Cockpit werden Durchgänge für Unterverfahrensteilschritte nicht unterstützt.
aufgabe	Angabe einer untergeordneten Aufgabe.

Aufgabe

Aufgaben sind in Unterverfahrensteilschritten enthalten. Pro Unterverfahrensteilschritt sind 0 bis beliebig viele Aufgaben möglich.

Jede Aufgabe benötigt eine eindeutige ID zur Identifikation und eine Beschreibung, die im Cockpit angezeigt wird. Optional kann eine Bedingung angegeben werden, wann die Aufgabe angezeigt werden soll. Im dargestellten Beispiel wird die Aufgabe nur angezeigt, wenn der sonstige Termin "InfoFoeb_Zeitraum" als Eigenschaft den Code 2000 erhalten hat.

Name	Zweck
id	Eindeutige ID der Aufgabe.
bedingung	Bedingung in Platzhalter-Syntax, wann die Aufgabe angezeigt werden soll.
beschreibung	Anzuzeigende Beschreibung der Aufgabe.
unteraufgabe	Unteraufgabe der Aufgabe, enthält die ActionItems.

Unteraufgabe

Unteraufgaben sind in beliebiger Anzahl in Aufgaben enthalten und umfassen beliebig viele ActionItems. ActionItems sind auf einer eigenen Unterseite beschrieben. Um ein ActionItem einer Aufgabe hinzuzufügen, muss eine Unteraufgabe vorhanden und das ActionItem darin ergänzt werden. Direkt in eine Aufgabe ohne Unteraufgabe ActionItems hinzuzufügen ist nicht möglich.

Analog zu Aufgaben benötigt je Unteraufgabe eine eindeutige ID zur Identifikation und eine Beschreibung, die im Cockpit angezeigt wird. Optional kann auch für Unteraufgaben eine Bedingung angegeben werden, wann sie angezeigt werden soll. Im dargestellten Beispiel wird die Unteraufgabe nur angezeigt, wenn der Hauptbezirk Harburg ist.

Name	Zweck
id	Eindeutige ID der Aufgabe.
bedingung	Bedingung in Platzhalter-Syntax ob die Unteraufgabe angezeigt werden soll.
beschreibung	Anzuzeigende Beschreibung der Aufgabe.
Auflistung der ActionItems	Liste der ActionItems.

Mandanten spezifische Anpassung und Erstellung von VK

Mit dem DiPlanCockpit Pro wird für Stage-Systeme die "Verfahrenskonfiguration Beispiel Bebauungsplan" mit dem Code 6100 ausgeliefert. Für die Erstellung eigener VK kann diese als Grundlage dienen, sodass keine VK von Grund auf neu geschrieben werden muss. Es empfiehlt sich auf dem Stage System die VK auszuarbeiten und zu testen, anschließend kann sie in ihrer finalen Version im Produktivsystem hochgeladen und verwendet werden.

Für die Verwaltung der VK ist zu empfehlen, eine fortlaufende Nummerierung für die Codes zu verwenden. Technisch betrachtet, können beliebige Codes für eine VK vergeben werden, solange sie jeweils nur einmal verwendet werden, sprich eindeutig sind. Für einen einfacheren Überblick bietet sich jedoch eine Verwendung von vierstelligen Zahlencodes an, wie bei der mitgelieferten VK mit dem Code 6100. Beispielsweise können für VK für Bebauungspläne Codes im Format 6xxx verwendet werden und für andere Planarten entsprechend ein anderer Zahlenbereich.

Für die Anpassung der VK ist folgender Arbeitsprozess empfehlenswert:

1. Schritt: Konzeption

• Sichten der VK und der Codelisten.
• Fachliche Konzeption der VK und der dazugehörigen Einträge in Codelisten.

Wichtig: Wenn keine Anpassung der änderbaren Codelisten anliegt, geht es mit dem 2. Schritt weiter. Wenn Codelisten angepasst werden sollen, erfolgt dies zuerst nach der Schritt-Anleitung für Codelisten. Erst danach steht der 2. Schritt dieser Anleitung an.

2. Schritt: Anpassen der Verfahrenskonfiguration

Das mitgelieferte VK dient als Kopiervorlage, die 1..n-fach vervielfältigt und angepasst werden kann.

Hinweis: Es ist sinnvoll, für die Anpassung ein IDE Tool zu verwenden wie Visual Studio Code oder IntelliJ, um den Code im Hintergrund laufend validieren zu lassen. (IDE = Integrierte Entwicklungsumgebung). Die Prüfung der Formatierung lässt sich per „Shift + Alt + L“ anstoßen.

3. Schritt: Hochladen ins DiPlanCockpit

Das Hochladen der angepassten Verfahrenskonfiguration erfolgt im Admin-Bereich im Reiter Konfiguration, den Nutzer mit der Rolle M-A aufrufen können. Angepasste Codelisten sind zuerst hochzuladen.