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 Verzeichnis jython 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 Funktion find_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 Funktion find_customized_resource_assignment_for_load ausgeführt, und, falls diese None zurückliefert, findet ein Fallback auf find_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, wenn find_customized_resource_assignment_for_load None zurückliefert, sollte die Zeile find_customized_resource_assignment_for_load in der Funktion find_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.