Verteilung von Mehraufwand aktivieren
Information
- In der Anwendung soll die Möglichkeit zur Verfügung gestellt werden, die Mehrbuchungen von Ressourcen auf übergeordnete Ressourcen zu verteilen. Dies soll eine alternative Berechnungsvariante zu der zurzeit im PLANTA-Standard verwendeten Berechnungsvariante sein.
- Gleichzeitig sollen diese Buchungen historisiert werden, um diese ggf. wieder rückgängig zu machen.
- Nähere Informationen zu der Anwendung finden Sie hier.
Aktivierung
Information
- Diese Funktionalität wird über die folgenden Events auf der Tabelle DT472 Belastungen realisiert:
- server.scheduling.insert_booking_event
- server.scheduling.update_booking_event
- server.scheduling.delete_booking_event
- Die Funktionalität kann somit an- bzw. abgeschaltet werden kann, indem man diese drei Events (de)-aktiviert unter System-Customizer → Events → Datengesteuerte Events.
Funktionsweise
Information
- Alle drei Events rufen Jython-Funktionen an, die für sämtliche logischen Änderungen verantwortlich sind – das heißt, die Terminrechnung selbst (im Native Code) wird nicht berührt. Stattdessen sorgt der neue Algorithmus dafür, dass nach dem Einfügen/Ändern/Löschen von Belastungen mit Ist-Aufwand, aber noch vor der Terminrechnung, Änderungen in die Belastungen und Rest-Aufwände von Ressourcenzuordnungen geschrieben werden, und zwar auf so eine Art und Weise, dass die folgende Terminrechnung daran nichts mehr ändert.
- Der Jython-Code hierfür befindet sich komplett in der Datei
jython/server/scheduling/scheduling.py,
das Verzeichnisjython
direkt unter dem Planta-Serververzeichnis. - Die Standard-Implementierung verwendet die übergeordnete Ressource als Ziel-Ressource, auf die die dann die überschüssige Belastung gebucht wird. Dies kann in
scheduling.py
-Datei individuell geändert werden, in dem die Funktionfind_customized_resource_assignment_for_load
überschrieben wird (siehe Kommentare hierzu im Source-Code). - Logisch gesehen wird (
in der Funktion
find_resource_assignment_for_load
), wann immer eine Ziel-Ressourcenzuordnung gesucht wird, zunächst die Funktionfind_customized_resource_assignment_for_load
ausgeführt, und, falls diese None zurückliefert, findet ein Fallback auffind_group_resource_assignment
statt, welche eine Ressourcenzuordnung mit der übergeordneten Ressource sucht. - Falls dies nicht erwünscht ist – also, falls nur eine anders geartete Logik in
find_customized_resource_assignment_for_load
ausgewertet werden soll, und die Einzelressourcenzuordnung als Ziel-Ressourcenzuordnung gewählt werden soll, wennfind_customized_resource_assignment_for_load
None zurückliefert, sollte die Zeilefind_customized_resource_assignment_for_load
in der Funktionfind_group_resource_assignment
auskommentiert werden.
Historisierung
Information
- In der Datentabelle 805 Buchungshistorie werden alle getätigten Ist-Buchungen (und Stornierungen) gespeichert. Anhand der in der Tabelle gespeicherten Daten wird auch die Reihenfolge bestimmt, in der die Buchungen zurückgesetzt werden.
- Bei jeder Ist-Buchung wird ein neuer Datensatz in dieser Tabelle angelegt(jeweils mit nächsthöherer POSITION, falls es bereits Einträge für Belastungen mit dieser LOAD_UUID gibt), wobei LOAD_ACT und evtl. BOOKED_EFFORT gesetzt wird.
- Falls eine Buchung sowohl Rest-Belastung von ihrer eigenen Ressourcenzuordnung als auch von ihrer Ziel-Ressourcenzuordnung reduziert, gibt es zwei Datensätze.
- Bei Stornierungen einer bestimmten Belastung wird dabei immer in umgekehrter Reihenfolge der Datensatz-Erstellung (nach dem Attributt Position) nach allen Datensätzen gesucht, die mittels LOAD_UUID dieser Belastung zugeordnet sind. In diesen wird nun entsprechend CANCELLED_EFFORT und evtl. CANCELLED_BOOKED_EFFORT gesetzt, was dazu führt, dass diese Aufwände bei zukünftigen Stornierungen nicht mehr berücksichtigt werden.
- Auch hier können mehrere Datensätze in einer Stornierung geschrieben werden.