Aufgabeaktionen

Dieses Kapitel beschreibt die operativen Aktionen innerhalb einer Aufgabe: die Übernahme durch einen Bearbeiter (Claiming), das Abgeben einer Aufgabe (Unclaiming), das Stellen von Rückfragen, die reguläre Bearbeitung sowie die Verknüpfung von Notizen mit dem ERP-System.

Besitzen und Übernahme

Um zu verhindern, dass mehrere Benutzer gleichzeitig widersprüchliche Änderungen an derselben Aufgabe vornehmen, nutzt das System einen Mechanismus namens Claiming. Dieser stellt sicher, dass eine Aufgabe immer nur von einer Person zur Zeit bearbeitet werden kann.

Exklusive Sperrung für Gruppen

Wenn eine Aufgabe einer Gruppe zugewiesen ist, können zunächst alle Mitglieder dieser Gruppe die Aufgabe sehen. Sobald jedoch ein Mitglied die Bearbeitung startet, wird dieses als Besitzer (claimedBy) eingetragen.

Die Folge für das Team:

• Die Aufgabe ist für alle anderen Mitglieder der Gruppe sichtbar aber nicht bearbeitbar.
• Dieser Zustand bleibt bestehen, bis der Aufgabenschritt entweder abgeschlossen, aktiv zurückgegeben oder von einem anderen Gruppenmitglied via „Force Pull“ übernommen wird.

Dauer des Besitzes

Um sicherzustellen, dass Aufgaben nicht unbeabsichtigt blockiert bleiben (z. B. wenn ein Bearbeiter vergisst, eine Aufgabe vor dem Urlaub freizugeben), verfügt das System über eine automatische Aufhebung der Übernahme.

• Frist: 24 Stunden.
• Ablauf: Wenn eine Aufgabe länger als 24 Stunden geclaimt bleibt, ohne abgeschlossen oder manuell zurückgegeben zu werden, hebt der Hintergrunddienst (SYSTEM) die Übernahme automatisch auf.
• Auswirkung: Die Aufgabe wird in den Gruppen-Pool zurückgelegt und steht allen Gruppenmitgliedern wieder zur Verfügung.
• Dokumentation: Die Aktion wird in der Historie als Aufgaben-Übernahme Zeitüberschreitung durch den Benutzer SYSTEM vermerkt.

Aufgabe abgeben

Falls ein Bearbeiter eine Aufgabe übernommen hat, diese aber doch nicht bearbeiten kann (z. B. wegen fehlender Informationen, Arbeitszeitende, Urlaub oder Krankheit), kann er die Aufgabe aktiv wieder abgeben. Durch die Aktion Aufgabe abgeben (Unclaiming) wird die exklusive Sperre aufgehoben und die Aufgabe wieder in den „Pool“ der Gruppe zurückgelegt.

Der Unclaim-Prozess

Technisch passieren dabei folgende Schritte:

• Das Feld claimedBy wird geleert.
• Der Zeitstempel claimedAt wird entfernt.
• In der Historie wird der Eintrag UNCLAIMED mit dem Namen des Bearbeiters vermerkt.

Nach der Abgabe steht die Aufgabe sofort wieder allen Mitgliedern der ursprünglich zugewiesenen Gruppe zur Verfügung.

Force Pull zurück in die Gruppe

Falls eine Aufgabe von einem anderen Benutzer geclaimed wurde und aber diese dringend bearbeitet werden muss (z. B. weil der Kollege nicht verfügbar ist), kann die Aktion Force Pull zurück in die Gruppe verwendet werden.

• Auswirkung: Der aktuelle Claim wird forciert aufgehoben und die Aufgabe in den Pool der Gruppe zurückgelegt.
• Berechtigung: Diese Aktion kann nur von Mitgliedern der Gruppe durchgeführt werden, der die Aufgabe zugewiesen ist.
• Dokumentation: Die Aktion wird in der Historie als FORCE_PULLED vermerkt, inklusive des Namens des Benutzers, der den Pull durchgeführt hat.

Sobald die Aufgabe wieder im Pool liegt, kann jedes andere Gruppenmitglied sie wie gewohnt claimen.

Rückfragen

In vielen Workflows ist es notwendig, Informationen von Personen oder Gruppen einzuholen, die nicht direkt am aktuellen Prozessschritt beteiligt sind. Hierfür steht die Funktion der Rückfrage zur Verfügung.

Fachlicher Zweck

Rückfragen dienen primär dazu, fehlende Informationen oder Klärungen einzuholen, die zwingend benötigt werden, um eine Workflowinstanz im aktuellen Schritt final freigeben oder ablehnen zu können.

Der Rückfrage-Prozess

Eine Rückfrage kann gestellt werden, wenn der aktuelle Workflow-Schritt dies explizit im Blueprint erlaubt (allowInquiry = true). Diese Einstellung muss für jeden einzelnen Schritt individuell hinterlegt werden, in dem die Funktion zur Verfügung stehen soll.

Dabei wird die Aufgabe temporär an eine Zielperson (inquiry_to) delegiert.

Auswahl der Zielpersonen

Bei einer Rückfrage können nicht beliebig alle Personen ausgewählt werden. Das System greift auf die Benutzerverwaltung des microtech ERP zu. Konkret werden Benutzer aus der Tabelle tblUsers zur Auswahl angeboten, die folgende Kriterien erfüllen:

• Aktivitätsstatus: Das Feld für das Gesperrt-Kennzeichen (fldGspKz) muss auf false stehen.
• E-Mail-Adresse: Es muss eine gültige E-Mail-Adresse im Feld fldEMail1 hinterlegt sein (darf nicht leer oder NULL sein).

Fehlende Benachrichtigungen

Aktuell ist technisch keine automatische Benachrichtigung (z. B. per E-Mail) über eine neu eingegangene oder ausstehende Rückfrage implementiert. Nutzer müssen ihre Aufgabenliste aktiv prüfen, um neue Rückfragen zu erkennen.

Verhalten während einer Rückfrage

Sobald eine Rückfrage gestellt wurde, wird der ursprüngliche Bearbeitungskontext gesperrt. Das bedeutet, dass die ursprüngliche Gruppe oder der ursprüngliche Bearbeiter keine regulären Aktionen mehr ausführen kann, bis die Rückfrage geklärt ist.

Dokumentation und Sichtbarkeit

Ein entscheidender Punkt ist die Art der Datenspeicherung:

• Keine ERP-Synchronisation: Die Informationen, die innerhalb einer Rückfrageschleife ausgetauscht werden (Fragen und Antworten), werden nicht in das Feld fldGspInfo (oder andere Felder) im microtech ERP zurückgeschrieben.
• Historie und Protokoll: Der gesamte Austausch wird ausschließlich in der internen Workflow-Historie (Verlauf/Protokoll) festgehalten.
• Langfristige Sichtbarkeit: Diese Einträge bleiben dauerhaft gespeichert. Sie sind für alle Mitglieder der beteiligten Bearbeitergruppen in allen nachfolgenden Schritten des Workflows sichtbar. Dies stellt sicher, dass spätere Entscheider den vollen Kontext der Klärung nachvollziehen können.

Das System speichert hierbei wichtige Metadaten:

• Zeitpunkt: Wann wurde die Rückfrage gestellt (inquiry_at)?
• Absender: Welcher Benutzer und welche Gruppe haben die Frage initiiert?
• Inhalt: Die konkrete Fragestellung (inquiry_text).

Auflösung von Rückfragen

Es gibt drei Wege, wie eine Rückfrage beendet werden kann:

1. Beantwortung: Der Empfänger gibt eine Antwort ein. Die Metadaten werden bereinigt und die Aufgabe kehrt zum Absender zurück.
2. Rückholung (Force Pull): Der Absender oder ein Mitglied der Ursprungsgruppe kann die Rückfrage aktiv zurückziehen, falls sich die Klärung erübrigt hat.
3. Automatischer Timeout: Um Blockaden zu vermeiden, verfügt das System über einen Hintergrundprozess, der Rückfragen nach 24 Stunden automatisch auflöst. In diesem Fall wird die Historie entsprechend markiert.

Aufgabenbearbeitung und regulärer Abschluss

Der Kern der täglichen Arbeit ist die reguläre Bearbeitung einer Aufgabe. Hierbei wählt der Benutzer eine definierte Aktion (action), die den weiteren Weg der Workflowinstanz bestimmt.

Jeder Abschluss eines Schrittes wird lückenlos in der Historie dokumentiert. Dabei werden nicht nur der gewählte Folgeschritt, sondern auch alle eingegebenen Kommentare und getroffenen Entscheidungen revisionssicher gespeichert. Führt ein Schritt zu keinem weiteren Folgeschritt, wechselt die Instanz in einen der Endzustände wie APPROVED (Genehmigt), REJECTED (Abgelehnt) oder COMPLETED (Abgeschlossen).

Integration von ERP-Notizen

Ein wesentlicher Bestandteil der Workflow-Bearbeitung ist der Austausch von textuellen Informationen mit dem microtech ERP. Dies stellt sicher, dass der Kontext vom Start bis zum Abschluss lückenlos dokumentiert ist.

Start: Initialer Hinweis aus dem ERP

Wenn ein Workflow in microtech büro+ gestartet wird, kann ein initialer Kommentar mitgegeben werden, um dem ersten Bearbeiter wichtige Informationen mit auf den Weg zu geben.

• Herkunft: Das Feld fldInExtBeaInfo (Textfeld für externe Bearbeitungsinformationen) in der Tabelle tblTransactions.
• Darstellung: Dieser Text wird automatisch als erster Eintrag in der Workflow-Historie (Verlauf) hinterlegt.
• Nutzen: Der Hinweis ist für den ersten Bearbeiter sofort sichtbar und bleibt für alle weiteren Beteiligten im Protokoll dauerhaft nachvollziehbar.

Abschluss: Rückmeldung der Ergebnisse

Nachdem ein Workflow final abgeschlossen wurde, schreibt die Engine eine Zusammenfassung aller relevanten Ereignisse zurück in das ERP. Dies ist besonders wichtig, damit Kollegen im ERP-System die Entscheidung (Freigabe/Ablehnung) nachvollziehen können, ohne den Workflow-Client öffnen zu müssen.

• Ziel: Das Feld fldGspInfo (Info-Feld des Vorgangs) in microtech.
• Inhalt: Es werden alle während des Workflows erfassten Kommentare gesammelt übertragen. Interne Rückfrageschleifen werden dabei zur Wahrung der Übersichtlichkeit ausgelassen.
• Format: Jede Aktion wird in einer neuen Zeile nach folgendem Schema dokumentiert: Datum Uhrzeit, Name des Arbeitsschritts, Name des Bearbeiters: Kommentar
• Logik: Die Informationen werden im ERP-Feld oben angestellt (Prepend). Vorhandene Texte bleiben erhalten und werden nach unten verschoben, sodass die aktuellste Entscheidung immer sofort sichtbar ist.

Auswirkungen auf die ERP-Sperre

Die Synchronisation der Ergebnisse hat direkte Auswirkungen darauf, ob ein Beleg in microtech nach dem Workflow wieder für Änderungen freigegeben wird:

• Bei Ablehnung: Der Beleg wird im ERP grundsätzlich dauerhaft gesperrt, um spätere Manipulationen am abgelehnten Vorgang zu verhindern.
• Bei Freigabe: Der Beleg wird normalerweise wieder entsperrt. Ausnahme: Wenn während des Workflows Kommentare oder Notizen erfasst wurden, bleibt der Beleg auch nach der Freigabe gesperrt, um die Unveränderbarkeit der zurückgeschriebenen Prozess-Historie in fldGspInfo zu gewährleisten.

Transparenz

Durch diese Integration fließen fachliche Entscheidungen und Begründungen direkt in die gewohnte ERP-Umgebung zurück und sind dort revisionssicher archiviert.

Berechtigungsmodell im Überblick

Das Berechtigungssystem steuert dynamisch, wer zu welchem Zeitpunkt Lese- oder Schreibrechte hat:

• Normalzustand: Die Aufgabe ist für den zugewiesenen Benutzer oder die Mitglieder der zugewiesenen Gruppe sichtbar und bearbeitbar.
• Rückfrage: Die Schreibrechte liegen primär bei der Person, an die die Rückfrage gerichtet wurde (inquiry_to).
• Administration/Eskalation: Mitglieder der Ursprungsgruppe können „Force Pull“ nutzen, um entweder aktive Rückfragen zurückzuholen oder geclaimte Aufgaben forciert in den Gruppen-Pool zurückzugeben.