Verfahrenskonfiguration Pro: Unterschied zwischen den Versionen

Aus DiPlanung

Zeile 97: Zeile 97:
  
 
==== Sitzung ====
 
==== Sitzung ====
[[Datei:ImageVKSitzung.png|links|mini|440x440px]]
+
[[Datei:ImageVKSitzung.png|links|474x474px|alternativtext=|rahmenlos]]
 
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.
 
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.
  
Zeile 191: Zeile 191:
  
 
==== Unterverfahrensteilschritt ====
 
==== Unterverfahrensteilschritt ====
[[Datei:ImageVKUVTS.png|links|mini|408x408px]]
+
[[Datei:ImageVKUVTS.png|links|436x436px|alternativtext=|rahmenlos]]
 
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.
 
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.
  
Zeile 210: Zeile 210:
  
 
==== Aufgabe ====
 
==== Aufgabe ====
[[Datei:ImageVKAufgabe.png|zentriert|mini|719x719px]]
+
[[Datei:ImageVKAufgabe.png|zentriert|719x719px|alternativtext=|rahmenlos]]
 
Aufgaben sind in Unterverfahrensteilschritten enthalten. Pro Unterverfahrensteilschritt sind 0 bis beliebig viele Aufgaben möglich.
 
Aufgaben sind in Unterverfahrensteilschritten enthalten. Pro Unterverfahrensteilschritt sind 0 bis beliebig viele Aufgaben möglich.
  
Zeile 232: Zeile 232:
  
 
==== Unteraufgabe ====
 
==== Unteraufgabe ====
[[Datei:ImageVKUnteraufgabe.png|zentriert|mini|531x531px]]
+
[[Datei:ImageVKUnteraufgabe.png|zentriert|531x531px|alternativtext=|rahmenlos]]
 
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.
 
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.
  

Version vom 18. Oktober 2024, 12:44 Uhr

> 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[Bearbeiten | Quelltext bearbeiten]

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[Bearbeiten | Quelltext bearbeiten]

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[Bearbeiten | Quelltext bearbeiten]

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[Bearbeiten | Quelltext bearbeiten]

Erläuterung der Grundstruktur[Bearbeiten | Quelltext bearbeiten]

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. Daran 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[Bearbeiten | Quelltext bearbeiten]

Zeitplanung[Bearbeiten | Quelltext bearbeiten]

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[Bearbeiten | Quelltext bearbeiten]

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.

ImageVS9998.png

Verfahrensteilschritt[Bearbeiten | Quelltext bearbeiten]

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[Bearbeiten | Quelltext bearbeiten]

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 die Art der Datumsangabe. Angabe "datum", "zeitraum" oder "datum_zeitraum".

Sonstiger Termin[Bearbeiten | Quelltext bearbeiten]

ImageSonstigeTermine.png

(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[Bearbeiten | Quelltext bearbeiten]

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[Bearbeiten | Quelltext bearbeiten]

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[Bearbeiten | Quelltext bearbeiten]

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[Bearbeiten | Quelltext bearbeiten]

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.