Gelöst T6T - Workflow zur Erinnerung wenn Aufbewahrungsfrist kurz vor Ende

[gboehm]

Moin zusammen,

Wenn eine Sendung nicht direkt zugestellt werden konnte und nun im Paketshop wartet, würde ich gerne dem Kunden kurz vor Ablauf der Aufbewahrungsfrist eine kurze Erinnerungs E-Mail senden. Dazu dachte ich, dass ich im Bereich "Versand - Paket - Sendungstatus aktualisiert" eben auf den entsprechenden Sendungsstatus einen Automatischen Workflow lege (Auslösung sofort), der dann einen Manuellen Workflow (Auslösung zeitversetzt) triggert. Dieser sollte dann nach x-Tagen, wenn der Status noch immer "im Paketshop" lautet, die Erinnerung senden.

Aber sehe ich das richtig, dass ich eben aus dem Bereich "Versand - Paket - Sendungstatus aktualisiert" keinen weiteren Worflow im Bereich Paket auslösen kann? Ich bekomme nur "Auftrag" und "Lieferschein erstellt" angeboten. Dort steht aber der Sendungstatus nicht zur Verfügung.

Gibt es eine andere Möglichkeit/Idee, wie man das lösen kann?

 

[Verkäuferlein]

Moin,

interessehalber einmal die Frage, um welchen Versanddienstleister es geht!?

Ich bin gerade dabei, sowas für GLS zu basteln, allerdings sind da meines Erachtens die Status für GLS in T&T noch nicht ganz sauber sortiert.

Meine Idee wäre (als Workaround) einen 2. Workflow direkt beim Auslöseereignis zu triggern, der halt mit x Tagen Verzögerung ausgeführt wird.
Der 1. Workflow schickt dann halt die Info, wo das Paket ist und der 2. erinnert dann später.

Allerdings bin ich mir aktuell nicht ganz sicher, ob dann die Bedingungen auch erst durchlaufen werden, wenn der Ausführungszeitpunkt erreicht ist oder ob die Bedingungen schon beim Triggern geprüft werden und nur die Umsetzung später erfolgt.

Aber auch da könnte man dann z.B. in der auszugebenden Mail nochmal filtern und das für Kundenservice nutzen, indem man sich dann entweder bedankt, dass das Paket abgeholt wurde oder aber darauf hinweist, dass es kurz vor Retoure steht.

Gruß
Verkäuferlein

 

[gboehm]

Bei mir wäre es DHL.
Jede Statusänderung schiebt den WF erst mal in die Queue. Die Bedingung wird erst überprüft, wenn die eingestellt Zeit abgelaufen ist. Wenn Du nun als Zeitversatz zB 5 Tage hast weil die Aufbewahrungsfrist nach 7 Tagen abgelaufen ist, und die Sendung dann noch unterwwegs ist, laufen alle WFs ins leere. Aber der Kunde könnte auch mit mehreren E-Mails bombardiert werden. Am Tag der versuchten Zustellung hast du ja mehrere Statusänderungen (im Zielpaketzentrum, ins Zustellfahrzeugt geladen, konnte nicht zugestellt werden und wird in den Paketshop gebracht, ist im Paketshop angekommen). Für jeden Status, bis auf den letzten Status, der warum auch immer keinen WF triggert, wird der WF in die Queue geschoben. Nach 5 Tagen holt der Worker sie raus und stellt bei jedem einzelnen fest, dass das Paket noch im Paketshop staub ansetzt -> zack 4 E-Mail nur für den Zustelltag.

IMHO ist die einzige saubere Lösung, einen WF bei Status "im Paketshop" sofort auszulösen und damit einen weiteren zeitversetzten in die Queue zu schieben, der dann nach x-Tagen nochmals prüft, ob detr Status noch im Paketshop lagernd ist, um dann die Erinnering zu senden. Damit bekäme der Kunde nur ein Erinnerung und auch nur, wenn die Sendung noch nicht abgholt wurde. Zudem würde die Queue nicht mit unnötigen WF geflutet.

Oder habe ich hier einen Denkfehler 🤔

 

[Verkäuferlein]

IMHO ist die einzige saubere Lösung, einen WF bei Status "im Paketshop" sofort auszulösen und damit einen weiteren zeitversetzten in die Queue zu schieben, der dann nach x-Tagen nochmals prüft, ob detr Status noch im Paketshop lagernd ist, um dann die Erinnering zu senden. Damit bekäme der Kunde nur ein Erinnerung und auch nur, wenn die Sendung noch nicht abgholt wurde. Zudem würde die Queue nicht mit unnötigen WF geflutet.

Oder habe ich hier einen Denkfehler 🤔

Genau das meinte ich, der Workflow löst erst aus, wenn der Zustellstatus sinngemäß "Zugestellt im Paketshop" ist.

Meine Idee wäre (als Workaround) einen 2. Workflow direkt beim Auslöseereignis zu triggern, der halt mit x Tagen Verzögerung ausgeführt wird.
Der 1. Workflow schickt dann halt die Info, wo das Paket ist und der 2. erinnert dann später.

Der 1. Workflow also am Tag der Verfügbarkeit im Paketshop (Trigger unter Versand wäre dann "Paket -> Sendungsstatus aktualisiert" und Du musst dann als Bedingung für die Ausführung den entsprechenden Status hinterlegen).
Der 2. Workflow dann mit Ausführungsplan 3-5 Tage verzögert mit dem Reminder (gleicher Trigger, gleiche Bedingungen).

Dann bekommt der Kunde mindestens 1, aber maximal 2 Mails.

Bei DHL bekommst Du dazu weitere Infos hier:
https://guide.jtl-software.de/jtl-s...ung-in-filiale-packstation-oder-bei-nachbarn/
https://guide.jtl-software.de/jtl-s...ce/workflow-paket-wurde-in-filiale-abgegeben/

Da kannst Du dann auch die Filial-Adresse / Packstationsadresse mit aus dem Sendungsstatus ausgeben.

Bei GLS fehlen mir dazu leider noch die nötigen Infos, welche Status es genau gibt und ob man möglicherweise auch den Paketshop und die Öffnungszeiten aus der Sendungsverfolgung auslesen kann.

 

[gboehm]

Dann bekommt der Kunde mindestens 1, aber maximal 2 Mails.

hmmmmmm......... funktioniert das denn tatsächlis so bei Dir? Würde mich ehrlich gesagt wundern.

Evtl bin ich ja komplett auf dem Holzweg. Aber das Problem ist doch die verzögerte Ausführung. Dein 2. WF würde ja nicht nur beim 1. Ereignis in die Queue geschoben, sondern auch bei allen anderen!

Das ist mal ein exemplarische Sendungsverlauf. Ignorieren wir mal, dass die Sendung am 19.01 abgeholt wurde, sondern gehen davon aus, dass sie da länger lag(liegt).


So wie ich den Ablauf der WFs verstehe, läuft das folgendermassen:
Bei verzögerter Auslösung würde jedes! dieser Ereignisse den WF (Dein 2. WF) in die Queue schieben. Etwaige Bedignung sind hierbei egal. Bei einer Verzögerung von 3 Tagen würde der Worker am 20.01. dann alle WFs vom 17.01. hervorkramen. Zu diesem Zeitpunk interssiert aber nicht mehr der Sendungstatus als der WF getriggert wurde, sondern nur noch der jetzige. Und da stellt der Worker fest, dass Sendungsstaus = "in der Filiale" ist - und zwar bei allen drei WFs. Ergo werden drei E-Mails gesendet. Das Gleiche einen Tag später, wenn dann die Ereignisse vom 18.01. dran sind. Auch hier ist der Sendungsstatus noch immer "in der Filiale". Also, gleich nochmals 5 E-Mails.

Bitte 🙏sage mir, dass hier falsch liege....

Bei DHL bekommst Du dazu weitere Infos hier:
https://guide.jtl-software.de/jtl-s...ung-in-filiale-packstation-oder-bei-nachbarn/
https://guide.jtl-software.de/jtl-s...ce/workflow-paket-wurde-in-filiale-abgegeben/

Ja, die kenne ich. Hier wird der Kunde informiert, dass die Sendung wo anders liegt. Die habe ich auch. Das funktioniert, da hier WFs ja direkt und unmittelbar und nicht verzögert ausgeführt werde.

 

[Verkäuferlein]

Bitte 🙏sage mir, dass hier falsch liege....

Das war ja mein Zweifeln an der ganzen Geschichte, ob es tatsächlich so funtkioniert.

Grundsätzlich ist das alles aus meiner Sicht nur ein Workaround, aber wir können ja leider nur mit dem Arbeiten, was zur Verfügung steht.
Wenn man JTL das als Feature-Request auferlegt, wird es meiner Erfahrung nach erstmal wegdiskutiert und dann ggf. 2034 mal umgesetzt.

Und da stellt der Worker fest, dass Sendungsstaus = "in der Filiale" ist - und zwar bei allen drei WFs. Ergo werden drei E-Mails gesendet. Das Gleiche einen Tag später, wenn dann die Ereignisse vom 18.01. dran sind. Auch hier ist der Sendungsstatus noch immer "in der Filiale". Also, gleich nochmals 5 E-Mails.

Da musst Du dann natürlich geschickt mit Bedingungen arbeiten. Das Auslöseereignis ist ja eine Veränderung im Tracking.
Allerdings hast Du natürlich recht, dass man das ein bisschen durchspielen muss, ob z.B. auch das konkrete Trigger-Ereignis (also der Status zum Zeitpunkt des Triggerns berücksichtigt werden kann oder nur der aktuelle).
Möglicherweise ist die Bedingung "Versandmeldung" das Triggerereignis und "Sendungsstatus" der aktuelle Status zum Zeitpunkt des Ausführens des Workflows bei den Bedingungen.

Du kannst aber in den Bedingungen ja z.B. auch prüfen, ob die Abgabe in der Filiale tatsächlich vor x Tagen war (Sendungsstatusverlauf).

Es wird ja dann eben kein Workflow ausgelöst, sondern der aktuelle Paketstatus auf Zutreffen der Bedingung geprüft und dann der Workflow verworfen oder gestartet.

Kommt jetzt der Status "LA" mit dem Sendungsinfo enthält "liegt ab sofort" rein, löst der 1. Workflow aus, durchläuft die Bedingungen und schickt eine Mail.

Der 2. Workflow wird zur Ausführung in x Tagen ausgelöst. Sind x Tage rum und der Status ist "zugestellt", wird der 2. Workflow verworfen.
Beide Workflows werden zwar auch bei jeder anderen Status-Änderung getriggert, aber eben durch die Bedingungen verworfen.

Bei Korrekten Bedingungen sollte es also maximal zu 2 e-Mails an den Kunden kommen.

Soll heißen, es wäre grundsätzlich schon besser, wenn der 1. Workflow (Bedingung: Sendungsstatus "In Filiale" + != "Zugestellt") den 2. Workflow (Meldung = "In Filiale" + Sendungsstatus != "Zugestellt") triggern könnte, aber wenn Du die Ausführung der Workflows in eine möglichst auslastungsfreie Zeit legst (allerdings geht glaube ich die Kombi aus Anzahl Tagen/Stunden und bestimmter Uhrzeit nicht und wäre dann vom Eingang des Tracking-Status abhängig), werden halt vielleicht ein paar 100 Mal (je Nach Paketmenge / Veränderung des Zustellstatus) in der Nacht die Bedingungen geprüft und der zugehörige Workflow verworfen.

Perfekt ist es nicht, aber ein möglicher Ansatz...

 

[gboehm]

hmmmm...... so ganz überzeugt bin ich noch nicht. Werde das erstmal mit E-Mails an mich ausprobieren, bevor ich möglicherweise den Kunden voll spamme.

 

[holzpuppe]

Hallo Leute,

die Abfrage wie/wo/was gerade ein Paket macht, nervt mich seit Monaten.
Der im Guide angepriesene Workflow funktioniert nicht mehr.
Im Workflow wird nur die letzte Meldung, die im Zusammenhang "Zustellfahrzeug" steht, berücksichtigt.
Was danach als "Info" kommt ist dem Workflow egal. Und genau das ist das Problem.
Im Workflow kannst du nur die "CNRFC" triggern. HNDDE und HLDCC sieht du zwar in T&T als Meldung, aber als Trigger geht es halt nicht.
„Did is scheiße.“

 

[holzpuppe]

Okeee....ich sehe ich hatte bei

Du kannst aber in den Bedingungen ja z.B. auch prüfen, ob die Abgabe in der Filiale tatsächlich vor x Tagen war (Sendungsstatusverlauf).

das übersehen. Tatsächlich könnte man darüber die Filiale herausfiltern.
Aber ich bin zu doof dafür.
Ich denke mir man muss erstmal die Anzahl der Meldungen erhalten, also:

{{ Vorgang.Sendungsstatusverlauf.Anzahl | Minus: 1 }}

Minus 1 da das erste Objekt mit Null anfängt zu zählen.
Danach könnte man in einer if-Schleife alle Zahlen durchgehen, bis man den Zustandcode "CNRFC", "HNDDE" oder "HLDCC" erhält.

{{ Vorgang.Sendungsstatusverlauf.6.Externer_Zustand }}

Theoretisch sind die Zahlen Null bis vier unnötig, da hier nix relevantes steht. 🤷‍♀️ (Aber ich habe schon gesehen, dass die Meldungen unter Umständen auch verdreht sein können.)
Und dann noch die Meldung mit:

{{ Vorgang.Sendungsstatusverlauf.6.Meldung}}

ausgeben.
Um es dann noch hübsch zu machen könnte man noch die letzte Meldung, falls die Anzahl des Sendungsstatusverlauf größer ist, ausgeben. Falls der Kunde doch schneller war als die Abfrage. XD
Und hier hören meine Fähigkeiten mit dotliquid auf. 🙈