Sperren auf Kundenwunsch (Rahmenworkflow)
Einsatzmöglichkeiten
Der Workflow
Sperren auf Kundenwunsch
(ISUDISCON212) ermöglicht Ihnen, einen Kunden auf dessen Wunsch hin zu sperren. Der Workflow kann nur aus dem Umfeld des Front-Office heraus gestartet werden, d.h. es exisitieren für diesen Workflow keine auslösenden Ereignisse.
Der Workflow ist so modelliert, dass die Wiederinbetriebnahme sofort nach einer erfolgten Sperrung angestoßen wird. Der Grund ist, dass im System nicht ermittelbar ist, wann die Wiederinbetriebnahme wiederangestoßen werden soll. Allerdings besteht für die Kunden die Möglichkeit, z.B. eine Containervariable mit einem Datum einzuführen und gesteuert über dieses Datum (welches manuell bei der Sperrückmeldung erfasst werden muss) eine Wiederinbetriebnahme anzustoßen.
Voraussetzungen
Es muß ein entsprechender Front-Office-Prozeß eingerichtet sein. Weitere Informationen finden Sie unter Front-Office-Prozessmanager .
Ablauf
Der Ablauf des Rahmenworkflows für die Sperrung auf Kundenwunsch ist fast identisch mit dem Ablauf des Rahmenworkflows Sperren/Wiederinbetriebnahme Inkasso , weshalb hier nur auf die Unterschiede eingegangen wird:
In diesem Workflow wird nicht auf das Ereignis
Sperrgrund obsolet
(Disconnect.DisconReasonObsolete) gewartet, da bei einer Sperrung auf Kundenwunsch im System nicht erkennbar ist, wann diese obsolet wird.
Da im System nicht erkennbar ist, wann die Sperrung wiederinbetriebgenommen werden soll, wurde im Bereich Wartezustand ein weiterer Zweig aufgenommen, in dem auf die Rückmeldung eines Sperrauftrags gewartet wird.
Tritt dieses Ereignis ein, wird sofort danach der Workflow Wiederinbetriebnahmeauftrag erstellen gestartet, d.h. es wird sofort nach der Erfassung einer Sperrung die Wiederinbetriebnahme angestoßen.