Erstellung einer Workflowvorlage Die Mindestkonfiguration: Wann ist eine Workflowvorlage „gültig“? Eine Workflowvorlage ist in dieser App erst dann vollständig einsetzbar, wenn mindestens diese Kriterien erfüllt sind: Aktiv = Ja  (die Vorlage muss aktiv sein) Primäre Tabelle  ist gesetzt Regelsatz ist vorhanden (wird beim Setzen der Primärtabelle automatisch erstellt/aktualisiert) Mindestens ein normaler Schritt (Schritttyp = Normal)  ist vorhanden Mindestens ein Workflowauslöser  ist vorhanden und  aktiv Wenn Sie die Vorlage aktivieren, führt die App eine Validierung aus und zeigt ggf. eine Fehlerliste an. Schritt 0 – Unterstützte Tabellen & Ereignisse prüfen (Pflichtwissen) Was sind „AWF Unterstützte Tabellen“? In  „AWF Unterstützte Tabellen“  pflegen Sie, welche Tabellen überhaupt als Primärtabelle auswählbar sind. Wichtig: In der Workflowvorlage können  nur unterstützte Tabellen  als Primärtabelle gewählt werden. Pro unterstützter Tabelle werden zusätzlich gepflegt: Workflowereignisse  (welche Events als Auslöser genutzt werden dürfen) Default-Tabellen initialisieren Da  AWF Unterstützte Tabellen  nicht direkt per Tell Me suchbar ist, rufen Sie die Seite so auf: Öffnen Sie  AWF Workflowvorlagen . Öffnen Sie eine Vorlage (oder legen Sie eine neue Vorlage an). Im Bereich  „Primäre Tabelle“  öffnen Sie das Lookup von  „Primäre Tabellen-ID“ . In der geöffneten Liste  AWF Unterstützte Tabellen  Aktion  „Standardtabellen initialisieren“ ausführen (wird auch direkt beim Öffnen initialisiert). Bestätigen. Diese Aktion initialisiert bzw. repariert die Standardkonfiguration. Workflowereignisse pro Tabelle ansehen Auf  AWF Unterstützte Tabellen : Aktion  „Workflowereignisse“ : zeigt gültige Workflowereignisse für die Tabelle   Workflowvorlage erstellen Neue Workflowvorlage anlegen Öffnen Sie  AWF Workflowvorlagen . Neu . Füllen Sie im Bereich  Allgemein : Code  (eindeutig) Beschreibung Aktiv  zunächst  Nein  (empfohlen) Primärtabelle setzen (entscheidend, da dies die Tabelle ist, für den der Workflow gestartet wird) In der Workflowvorlage (Karte) zum Bereich  „Primäre Tabelle“ . Feld  „Primäre Tabellen-ID“  auswählen. Es öffnet sich die Liste  AWF Unterstützte Tabellen . Tabelle auswählen. Prüfen, ob  „Primäre Tabelle Bezeichnung“  automatisch gefüllt wird. Was dabei im Hintergrund passiert: Die App erstellt/aktualisiert automatisch einen Regelsatz für die Vorlage. Die Primärtabelle wird automatisch als  Primäre Tabelle  im Rule Set hinterlegt. Dokumenttyp/Belegart filtern Ältere Versionen kannten eine  Primäre Belegart  direkt in der Workflowvorlage. Diese Konfiguration wurde durch die  Regel-Engine  ersetzt. Wenn Sie den Workflow z. B. nur für bestimmte Belegarten starten oder unterschiedliche Schritte je Belegart abbilden möchten, lösen Sie das jetzt über  Regelbedingungen : 1. Öffnen Sie den passenden Bereich (z. B. Workflowauslöser → Regeln anzeigen ) 2. Legen Sie eine Regelbedingung an (Aktion Bedingungen anzeigen ). 3. Wählen Sie als Quellfeld z. B. "Belegart" (Feld der Primärtabelle bzw. einer zugehörigen Tabelle). 4. Setzen Sie Operator/Wert (z. B. „= Auftrag“). Audit Trail als PDF speichern Wenn ein Workflow erfolgreich abgeschlossen wird, kann der Audit Trail automatisch als PDF-Datei in den  Dokumentanhängen  des Quelldatensatzes gespeichert werden. Konfiguration In der  AWF Workflowvorlage  → Feld  „Audit Trail in Anhänge speichern"  = Ja. Beim erfolgreichen Abschluss des Workflows wird der Audit-Trail-Bericht automatisch als PDF generiert und als Dokumentanhang an den Quelldatensatz angehängt. Anhänge-FactBox In der  AWF Workflowinstanz-Karte  werden Anhänge aus zwei Quellen kombiniert angezeigt: Anhänge des Quelldatensatzes  (z. B. eingescannte Rechnungen) Anhänge der Workflowinstanz  (z. B. generierte Audit-Trail-PDFs) Damit haben Genehmiger und Administratoren alle relevanten Dokumente an einem Ort. Zugehörige Tabellen konfigurieren (optional) Warum brauche ich zugehörige Tabellen? Die Rule Engine kann Bedingungen nicht nur auf der Primärtabelle prüfen, sondern auch auf  zugehörigen Tabellen  (z. B. Kopf/Zeilen). Diese zugehörigen Tabellen definieren Sie in der Vorlage im Bereich: Zugehörige Tabellen (technisch: „DXP Rule Set Tables bzw. Regelsatztabellen“) Zugehörige Tabelle hinzufügen In der Vorlage im Abschnitt  Zugehörige Tabellen  eine neue Zeile anlegen. Tabellen-ID  wählen (Lookup). Beziehung zur Primärtabelle definieren: Beziehungsfeld 1 (Feldnummer in der Related Table) Primärfeld 1  (Feldnummer in der Primärtabelle) Optional zusätzlich Beziehungsfeld 2 / Primärfeld 2 usw. Faustregel: Beziehungsfeld(er) = „Fremdschlüssel“ in der zugehörigen Tabelle Primärfeld(er) = die passenden Schlüssel-/Referenzfelder in der Primärtabelle Wichtig: Ohne korrekt definierte Relation kann die Regel-Engine Felder der zugehörigen Tabelle nicht sauber gegen den aktuellen Datensatz auswerten. Schritte definieren Grundstruktur der Schritte In der Vorlage gibt es den Abschnitt  Schritte . Ein Schritt enthält u. a.: Schritt Code Schritt Name Reihenfolge Schritttyp  (Normal / Error / Final) Datensatzbearbeitung erlauben Zuständigkeitslogik Genehmigungen / Zugehörige Genehmigungen : optional Zeilen-Genehmigungen aktivieren ( Zugehörige Genehmigung aktivieren ) und Genehmigungsmodus festlegen Ersten „Normal“-Schritt anlegen Im Abschnitt  Schritte  →  Neu . Schritttyp = Normal . Schritt Code und Schritt Name  vergeben. In der Karte Art des Zuständigen  festlegen und Zuständiger setzen. Wichtiges Systemverhalten: Beim Anlegen des ersten Normal-Schritts erzeugt die App automatisch: einen  Error -Schritt (Code z. B.  ERROR ) einen  Final -Schritt (Code z. B.  FINAL ) Zuständigkeit konfigurieren Auf der  AWF Schritt -Karte pflegen Sie: Art des Zuständigen Zuständiger Einschränkungsart Genehmiger Hinweise: Bei  Salesperson/Purchaser  wird der Zuständige automatisch aus dem Datensatz (Verkäufer/Einkäufer) abgeleitet. Bei  Workflow User Group  muss eine Workflow-Benutzergruppe existieren und Mitglieder haben. Wenn ein Schritt keinen gültigen Zuständigen auflösen kann, wird der Workflow zur Laufzeit typischerweise in den Fehlerschritt verschoben. Fälligkeitsdatumsformel (Due Date) In der  AWF Schritt -Karte kann eine  Fälligkeitsdatumsformel  konfiguriert werden: Feld:  Fälligkeitsdatumsformel  (z. B.  <+3D> ,  <+1W> ,  <+2W> ) Wenn gesetzt, erhalten Genehmigungseinträge, die in diesem Schritt erzeugt werden, automatisch ein Fälligkeitsdatum. Das Fälligkeitsdatum ist relevant für: Die Anzeige in  „Zu genehmigende Anforderungen" Die  Eskalations-Engine  (Eskalationsschritte basieren auf dem Fälligkeitsdatum) Standard-BC-Fälligkeitsbenachrichtigungen Schritt-Regeln: Wie wechselt der Workflow zum nächsten Schritt? Die App nutzt die DEXPRO Rules Engine, um zu bestimmen: welche Regel passt zu welchem  nächsten Schritt gewechselt wird ob der Zuständige überschrieben wird ob automatisch genehmigt wird und ob die Aktion für die Kopfgenehmigung, zugehörige Genehmigungen (Zeilen) oder beides gilt. Wenn keine Regel definiert ist, ist die jeweilige Konfiguration des Schrittes gültig. Regelgruppe pro Schritt („Regeln anzeigen“) In der  Schritte -Liste den gewünschten Schritt markieren. Aktion  „Regeln anzeigen“ . Wenn noch keine Regelgruppe hinterlegt ist, erstellt die App automatisch eine  Regelgruppe  und trägt sie im Schritt ein. Regeln anlegen (DEXPRO Core) In der geöffneten Seite  Regeln : Neu . Regelcode  und  Regelname  setzen. Sequenz/Priorität vergeben. Aktiv = Ja . Optional: Bedingungsverknüpfung (UND/ODER) Datensatzabgleichsart (Beliebiger Datensatz / Alle Datensätze)   Advanced-Workflow Felder auf der Regel pflegen (Nächster Schritt, Automatisch Genehmigen, Zuständigen Überschreiben) In der Regel gibt es den Bereich  „DEXPRO Advanced Workflow“: Regelaktion setzen (Lookup/Drilldown) und die gewünschte Aktion auswählen, z. B. Schrittübergang Zuständigen überschreiben Automatisch genehmigen Bei Schrittübergang zusätzlich Nächster Schritt wählen (Lookup zeigt die nächsten möglichen Schritte). Wenn zugehörige Genehmigungen aktiv sind: Gilt für setzen (Kopf / Nur Zugehörige / Kopf und Zugehörige). Bei Zuständigen überschreiben: Art des Zuständigen und Zuständiger pflegen. Bedingungen (Regelbedingungen) hinzufügen In der Regeln-Seite: Aktion  „Bedingungen anzeigen“ . Pro Bedingung eine Zeile hinzufügen: Quelltabellen-ID  (Primärtabelle oder zugehörige Tabelle) Quellfeld-ID  (Feld) Vergleichsoperator  (Operator) Wert  (Wert; AssistEdit bei Enum/Boolean/Between/In Set) Tipp:  Wenn Sie Bedingungen über zugehörige Tabellen nutzen, muss die Relation in  Zugehörige Tabellen  korrekt gepflegt sein. Regeln testen (ohne echten Workflow) Auf der Regeln-Seite gibt es: Regel testen Regelgruppe testen Damit prüfen Sie Regeln/Regelbedingungen gegen einen Beispieldatensatz, bevor Sie echte Workflows starten. Workflowauslöser konfigurieren Workflowauslöser bestimmen,  wann  eine neue Workflowinstanz gestartet wird. In der Vorlage heißt der Abschnitt  „Workflowauslöser“ . Vorlagenauslöser: Grundfelder In der Vorlage → Abschnitt  Workflowauslöser . Neu . Feld  Workflowereignis  auswählen (AssistEdit → Liste „AWF Tabellen Workflowereignisse“). Aktiv = Ja . Priorität  festlegen (Reihenfolge bei mehreren passenden Auslösern). Trigger-Regeln: Wann darf ein Auslöser feuern? Im Auslöser gibt es  Regelgruppencode . Über die Aktion  „Regeln anzeigen“ : Auslöser markieren. Regeln anzeigen . Regeln/Regelbedingungen wie in Schritt-Regeln pflegen. Wichtiges Systemverhalten: Wenn  keine Regelbedingungen  für diese Trigger-Regelgruppe existieren, gilt der Auslöser als erfüllt (der Trigger feuert dann grundsätzlich).   OnAfterModify: Überwachte Felder Für das Event  OnAfterModify  gibt es die Aktion  „Überwachte Felder“ . Auslöser mit Workflowereignis  OnAfterModify  markieren. Aktion  „Überwachte Felder“ . Felder auswählen (Lookup über „Fields Lookup“). In der aktuellen Implementierung wird ein OnAfterModify-Auslöser  nur dann  gestartet, wenn  mindestens ein überwachtes Feld  gepflegt ist  und  sich dieses Feld tatsächlich geändert hat. Wenn keine überwachten Felder gepflegt sind, wird der Auslöser bei OnAfterModify nicht gestartet. Workflowaktion bei Abschluss In der Vorlage gibt es den Abschnitt  „Workflowaktion“ . Aktion bei Abschluss ausführen  aktivieren. Aktion bei Abschluss  wählen (abhängig von der Primärtabelle): Release / Reopen (nur für bestimmte Belegtabellen) Benutzerdefinierte Aktion (Codeunit/Report) Feldwertzuweisungen festlegen Wenn  Feldwertzuweisungen festlegen  gewählt ist, erscheint der Abschnitt  Feldwertzuweisungen . Bereinigung (Aufbewahrung & Bereinigung) Unter  Bereinigungskonfiguration : Automatische Bereinigung aktiviert Aufbewahrungsfrist für Bereinigung  (DateFormula, z. B.  -1M ) Zusätzlich gibt es die Aktion: „Alte Instanzen bereinigen“ Modul: Eskalations-Engine Die Eskalations-Engine überwacht automatisch überfällige Genehmigungsanforderungen und führt definierbare Eskalationsschritte aus. Damit lassen sich Erinnerungen, automatische Delegierungen oder Neuzuweisungen zeitgesteuert abbilden. Funktionsweise Die Eskalation wird über einen  Aufgabenwarteschlangenposten  gesteuert, der regelmäßig alle offenen Genehmigungseinträge prüft. Für jeden überfälligen Eintrag wird geprüft, ob ein Eskalationsschritt fällig ist (basierend auf  „Überfälligkeitsdauer"  relativ zum Fälligkeitsdatum der Genehmigung). Eskalationsschritte können auf  Vorlagenebene  (gelten als Standard für alle Schritte) und/oder auf  Schrittebene  (überschreiben die Vorlageneinstellung für diesen Schritt) definiert werden. Der höchste bereits ausgeführte Eskalationsschritt wird im Genehmigungseintrag im Feld  „Eskalationsstufe"  nachgehalten, damit kein Schritt doppelt ausgeführt wird. Voraussetzungen Der  Eskalations-Aufgabenwarteschlangenposten  muss eingerichtet und aktiv sein (siehe  AWF Einrichtung ). Die Genehmigungseinträge müssen ein  Fälligkeitsdatum  haben (konfigurierbar über  „Fälligkeitsdatumsformel"  im Schritt). Eskalationsschritte konfigurieren Auf Vorlagenebene (Standard für alle Schritte) In der  AWF Workflowvorlage  → Abschnitt  „Eskalationsschritte" . Neu . Felder ausfüllen: Schrittnr. : Laufende Nummer (bestimmt die Reihenfolge). Beschreibung : Beschreibung des Eskalationsschrittes (z. B. „Erinnerung nach 1 Tag"). Überfälligkeitsdauer : Datumsformel relativ zum Fälligkeitsdatum (z. B.  <+1D>  = 1 Tag nach Fälligkeit,  <+1W>  = 1 Woche nach Fälligkeit). Eskalationsaktion : Aktion, die bei Erreichen der Überfälligkeitsdauer ausgeführt wird. Aktiviert : Ja/Nein. Auf Schrittebene (überschreibt Vorlagenebene) In der  AWF Schritt -Karte → Abschnitt  „Eskalationsschritte" . Schritte anlegen wie oben beschrieben. Wenn ein Workflowschritt eigene Eskalationsschritte hat, werden die Vorlagen-Eskalationsschritte für diesen Schritt  nicht  berücksichtigt. Eskalationsaktionen Aktion Beschreibung Benachrichtigung senden Sendet eine Eskalations-Benachrichtigung (über die Standard-BC-Benachrichtigungsmechanik). Delegieren Delegiert die Genehmigung automatisch über die BC-Standard-Stellvertreterkette (aus „Genehmigungsbenutzereinrichtung"). Neu zuweisen Weist die Genehmigung an einen definierten Empfänger neu zu. Dabei werden  Empfängerart  und  Empfängercode  konfiguriert (Benutzer oder Workflow-Benutzergruppe). Benutzerdefinierte Aktion Führt ein benutzerdefiniertes Objekt aus (Codeunit oder Report). Optional kann der Quelldatensatz übergeben werden ( Quelldatensatz übergeben ). Empfänger konfigurieren (bei „Benachrichtigung senden" und „Neu zuweisen") Empfängerart : Genehmiger (konkreter Benutzer) oder Workflow-Benutzergruppe. Empfängercode : Benutzer-ID oder Code der Workflow-Benutzergruppe. Bei „Neu zuweisen" wird die Genehmigung auf den neuen Empfänger umgeleitet. Bei „Benachrichtigung senden" erhält der Empfänger eine Eskalationsbenachrichtigung. Regelbasierte Eskalation (optional) Eskalationsschritte können optional einen  Regelgruppencode  haben. Wenn gesetzt, wird der Eskalationsschritt nur ausgeführt, wenn die Regelbedingungen der Regelgruppe für den aktuellen Datensatz zutreffen. Fälligkeitsdatum und Eskalation Damit die Eskalation sinnvoll funktioniert, muss im Schritt eine  Fälligkeitsdatumsformel  gepflegt sein: Im Schritt: Feld  „Fälligkeitsdatumsformel"  setzen (z. B.  <+3D>  = Fälligkeit 3 Tage nach Erstellung der Genehmigung). Die Eskalationsdauer addiert sich zum Fälligkeitsdatum: Wenn die Fälligkeitsdatumsformel  <+3D>  und die Überfälligkeitsdauer  <+1D>  beträgt, wird der Eskalationsschritt 4 Tage nach Erstellung der Genehmigung ausgeführt. Wenn ein Genehmigungseintrag  kein Fälligkeitsdatum  hat, wird eine Eingabeaufforderung zur manuellen Eingabe angezeigt, sofern nötig. Modul: Ablehnungseinstellungen (Rejection Handling) Das Ablehnungsverhalten im Advanced Workflow ist konfigurierbar und steuert, was passiert, wenn ein Genehmiger eine Genehmigungsanforderung ablehnt. Standardverhalten (ohne besondere Konfiguration) Ablehnung im ersten Schritt : Der Workflow wird abgebrochen (Status → Abgebrochen). Ablehnung in einem späteren Schritt : Der Workflow kehrt zum  vorherigen Schritt  zurück, und die Genehmigung wird neu erstellt. Ablehnungsgruppe für zugehörige Genehmigungen (Zeilen) Wenn Sie zugehörige Genehmigungen (Zeilen-Genehmigungen) nutzen, können Sie festlegen, an wen abgelehnte Zeilen-Genehmigungen neu zugewiesen werden: Konfiguration auf Vorlagenebene In der  AWF Workflowvorlage  → Bereich  Ablehnungseinstellungen : Ablehnungsgruppe für Zugehörige verwenden  = Ja Art des Standard-Zuständigen für Ablehnung  Genehmiger / Workflow-Benutzergruppe / Verkäufer/Einkäufer Standard-Zuständiger für Ablehnung : Konkreter Benutzer oder Gruppe Konfiguration auf Schrittebene (überschreibt Vorlagenebene) In der  AWF Schritt -Karte → Bereich  Ablehnungsverhalten : Ablehnungsgruppe für Zugehörige verwenden  = Ja Art des Standard-Zuständigen für Ablehnung und Standard-Zuständiger für Ablehnung  wie oben Wenn ein Schritt eigene Ablehnungseinstellungen hat, überschreiben diese die Vorlageneinstellungen. Ablehnungsgruppe für Kopf-Genehmigungen Normalerweise führt eine Ablehnung der Kopf-Genehmigung zum Rücksprung in den vorherigen Schritt (oder zum Abbruch im ersten Schritt). Alternativ können Sie konfigurieren, dass die Kopf-Ablehnung den Workflow  im aktuellen Schritt  behält und an eine Ablehnungsgruppe neu zuweist: Ablehnungsgruppe für Kopfablehnung verwenden  = Ja Art des Zuständigen für Kopfablehnung : Genehmiger / Workflow-Benutzergruppe / Verkäufer/Einkäufer Zuständiger für Kopfablehnung : Konkreter Benutzer oder Gruppe Die Konfiguration ist sowohl auf  Vorlage-  als auch auf  Schrittebene  möglich (Schrittebene überschreibt Vorlagenebene). Ablehnungsgrund und Neuzuweisung bei Zeilen Beim Ablehnen einer zugehörigen Genehmigung öffnet sich ein Dialog: Ablehnungsgrund : Pflichtfeld – warum wird die Zeile abgelehnt? Neuer Zuständiger : Vorausgefüllt mit der konfigurierten Ablehnungsgruppe, kann aber manuell angepasst werden. Empfängertyp : Genehmiger / Workflow-Benutzergruppe / Verkäufer/Einkäufer Benutzer  oder  Workflow-Benutzergruppe  (je nach Art)