Job reassignPerformerAfterXDaysOfInactivity

Allgemeines

Mit diesem Job ist es möglich, eine Aufgabe automatisch einem anderen Bearbeiter zuzuordnen, wenn diese zu lange nicht bearbeitet wurde.

Anwendungsgebiete

Das klassiche Anwendungsgebiet ist, wenn der aktuell zugewiesene der Aufgabe, momentan auf Urlaub ist und somit die Aufgabe nicht bearbeiten kann.

Abwesenheitsstrategie

Ob ein Mitarbeiter momentan abwesend ist oder nicht, wird durch die gewählte Abwesenheitsstrategie evaluiert, wobei es hier 2 verschiedene Varianten gibt:

• TaPersonAbsenceResolver
• WfPersonAbsenceResolver

Grundsätzliche lesen beide Strategien die erfolgten Zeitbuchungen des aktuellen Bearbeiters im Zeitraum von X Tagen in die Vergangenheit. Die Interpretation, ob der User dabei als abwesend gilt oder nicht, obliegt der Strategie.

TaPersonAbsenceResolver

Diese Strategie geht davon aus, dass eine Person nur dann als abwesend gilt, wenn diese im Beobachtungszeitraum (X Tage in die Vergangenheit), weder im Büro noch im Home-Office oder in Form einer Dienstreise oder mobile Working eingebucht war. Das entsprechende Kriterium stellt hierbei dar, ob eine Buchung mit einem "produktiven" Fehlgrund oder eine reine Anwesenheitsbuchung im Beobachtungszeitraum existiert. Nur wenn keine solche existiert, gilt die Person als abwesend.

WfPersonAbsenceResolver

Diese Strategie verändert die Strategie um festzustellen, ob eine Person als abwesend zu klassifizieren ist. Bei dieser Strategie wird ausschliesslich der aktuelle Tag geprüft auf diesem muss die Person muss zumindest eine Abwesenheitsbuchung (ganztägig, oder untertägig) aufweisen, welche einen Fehlgrund  verwendet, der Vertreter "aktiviert". Diese Fehlgründe können am Mandanten oder im Systemparameter WfOptions.absenceCodesActivatingDeputy definiert werden. Zusätzlich darf an diesem Tag kein Anwesenheits- oder produktive Fehlgrundbuchung vorhanden sein.

Es reicht nicht, dass keine Buchungen existieren. Damit sollen Negativzeiterfasser, welche nur Abwesenheiten aufzeichnen, ebenso erfasst werden können.

Um zu verhindern, dass eine Aktivität - auf Grund zu langer Inaktivität - mehrmals neu zugewiesen wird, wird in der Prozessinstanz eine boolsche Workflow-Variable gepflegt, die beim erstmaligen neu zuweisen auf true gesetzt wird. Bei späteren versuchten Neuzuweisungen, wird dann immer zuerst das Flag geprüft, ob schon eine Neuzuweisung erfolgt ist, oder nicht.

Für jede in der Prozessdefinition verwendete Rolle, werden folgende Workflow-Variablen vom Typ Boolean erwartet:

1. reassignedTo<roleName>
2. reassignedToSpecificRole_<roleName>

Im ersten Fall geht es darum, die automatische Weiterleitung an den zuständigen Rolleninhaber des aktuellen (nicht verfügbaren) Rolleninhabers zu finden (z.b. den Vorgesetzten des Vorgesetzten) und dann diese Neu-Zuweisung in der Variable zu dokumentieren.Im zweiten Fall geht es darum, die automatische Weiterleitung an einen zuständigen Rolleninhaber für eine andere Rolle zu dokumentieren.

Die mehrfache Neuzuweisung einer unbearbeiteten Aktivität durch diesen Job bedarf der Existenz der oben definierten Workflow-Variablen im Prozess. Ab Version 4.13.0 werden diese beim Speichern von simplen Prozess-Definitionen automatisch angelegt. Früher angelegt Prozessdefinitionen müssen neue abgespeichert werden, damit diese angelegt werden. Prozessinstanzen von in der Vergangenheit angelegten Prozessdefinitionen haben diese Flags nicht.

Jobkonfiguration

• Prozessdefinition, deren Instanzen bearbeitet werden sollen:
  mittels Doppel Liste werden hier die Prozessdefinitionen ausgewählt auf die dieser Job zugreifen soll
• Rollen
  im Drop-down werden die verfügbaren Rollen angezeigt
• Anzahl der inaktiven Tage
• Absenz Strategie
  im Drop-down werden die verfügbaren Strategien angezeigt
• TaPersonAbsenceResolver
• WfPersonAbsenceResolver
• Schicke Neuzuweisungs-Mail
• Mail Betreff
• Mail Inhalt

Felder