...

Inhaltsverzeichnis

...

Sollten Ihnen einzelne Rules-Typen nicht zur Verfügung stehen, setzen Sie sich bitte mit Ihrem Ansprechpartner bei CargoSoft in Verbindung.

Darstellung einzelner Rule Types

Tracking Event Rule

Eine generelle und sehr vielseitige Regel für Benachrichtigungen.

Logik

Wenn sich ein Event ändert oder neu hinzugefügt wird oder ein Dokument hochgeladen wird, wird eine Benachrichtigungs-Email versendet .

Das System generiert je Dokumententyp ein Event im Hintergrund. Dieses Event kann zusätzlich als Source Event verwendet werden.

Beispiele

·         Geplante Schiffsabfahrt ändert sich um 3 Tage

·         Nach Schiffsabfahrt wird das tatsächliche Abfahrtsdatum als neues Event hinzugefügt

·         In der eAkte wird der Dokumententyp „Handelsrechnung“ hinzugefügt

HTML-Mailing (Bei Primefaces standardmäßig aktiviert!)

Ab Version 2021.2 lässt sich für die TrackingEventRuleBeta (Rules 2) anstatt einer reinen Text E-Mail auch eine HTML- Mail darstellen. Diese kann dann anhand verschiedener Formatierungen gestaltet werden und kann auch Bilder, Hyperlinks usw. enthalten.

Eingestellt wird das HTML Mailing unter Administration > System > Configuration > System settings > TrackingEventRule_htmlMail = true.

ACHTUNG: Beim Setzen des Settings werden alle vorhandenen TrackingEventRules automatisch konvertiert. Allerdings gehen dabei die Textumbrüche verloren und müssen einmalig neu gesetzt werden.

Erläuterung der einzelnen Felder und Funktionen

...

1.)   Name: (Pflichtfeld)

Der Name der Regel. Für interne Identifizierung – Name taucht nicht in der gesendeten Mail auf.

2.)   Activate:

Nur, wenn der Haken gesetzt wird, ist die Regel aktiv und wird ausgeführt.

3.)   SCObject-Type: (Pflichtfeld)

 Beschreibt verschiedene Level der Sendung:

·         TransportOrder (Spezialfälle – nicht im Standard)

·         XTransportOrder (Shipmentebene – Standard)

·         Container / XTransportOrderPosition  (Container- bzw. Colliebene)

4.)   Project:

 Eine Regel kann auf ein bestimmtes Projekt bezogen werden.

Feld leer = gilt für alle Projekte

5.) Direction:

Auswahl Export oder Import. Somit kann gefiltert werden, dass die Regel z.B. nur bei Import Shipments greift.

Feld leer = gilt für alle Directions

Achtung: Es gibt keine Direction Transport im Tracking. Der Mode of Transport wird im Zuge der Übertragung an das SCM auf Export oder Import gemapped.

6.)   Mode of Transport:

Es besteht die Möglichkeit, die Regel auf bestimmte MOT´s zu beschränken.

Feld leer = gilt für alle MOT´s.

7.) Source Event:

Das Event, bei dessen Befüllung oder Änderung die Regel ausgelöst werden soll.

Mögliche Source Events sind:

·         container_“Event“ / xtransportorderposition_“Event“ = Events auf Container- bzw. Colliebene

·         documenttype_available_“Doc ID“ = E-File Dokumentenkategorie

·         xtransportorder_“Event“ = Events auf Shipmentebene

Achtung: Die Art des Source Event muss logisch mit Feld 3.) übereinstimmen.

Beispiel: zu einem gewählten SCObject-Type XTransportOrder passt ein Event xtransportorder_departure

8.) Source Event Type:

Es wird bestimmt, auf welchen Datumstyp (ACT/EST/SCH) sich die Regel beziehen soll

·         ACT = Actual

·         EST = Estimated

·         SCH = Scheduled (Spezialfälle – nicht im Standard)

9.) Observe change of:

Für Änderungsbenachrichtigungen wichtig! Hier kann ein Schwellwert definiert werden, den die Änderung von alter zu neuer Eventzeit/-datum mindestens überschreiten muss. In diesem Feld wird eingestellt, ob es sich um Tage, Stunden oder Minuten handeln soll. Im nächsten Feld wird dann der Wert dazu hinterlegt.

ACHTUNG: Feld 9.) und 10.) funktionieren NUR in Kombination.

10.)  Observe offset:

In diesem Feld wird eingestellt, wie viel Tage / Stunden oder Minuten der Wert vom ursprünglichen Wert abweichen muss damit die Regel ausgeführt wird.

...

11.)  Execute on shipment create:

Wenn der Haken gesetzt ist, wird die Regel NUR beim Erstellen des Shipments (manuell durch User im eShipment oder automatisch durch z.B. Tracking Schnittstelle aus dem TMS = „Create-event“) ausgeführt

Ist der Haken nicht gesetzt, wird erst NACH der ersten Übertragung auf das Source Event geprüft.

Bei Änderungsmails sollte der Haken nicht gesetzt werden. Ist der Haken nicht gesetzt, wird die Regel lediglich bei Updates des Shipments ausgeführt.

12.)  Execute on event create:

Wenn der Haken gesetzt ist, wird die Regel NUR beim Erstellen eines Events (manuell durch User im eShipment / eTracking oder automatisch durch z.B. Tracking Schnittstelle aus dem TMS) ausgeführt. Ist der Haken nicht gesetzt wird nur bei einer Änderung „alter Wert auf neuer Wert“ getriggert. Das Event muss also vorher schon ein Datum beinhaltet haben, damit die Regel ausgeführt wird.

ACHTUNG: Das Feld prüft IMMER BEIDE Event types (EST und ACT) des Source events.

13.)  Trigger Mode (nur sichtbar, wenn die Berechtigung vorhanden ist):

Es kann eingestellt werden, wann die Regel ausgeführt werden soll

·         Trigger at Source Event Date: Die Regel wird an dem Datum ausgeführt, welches in dem Source Event eingetragen ist.

·         Trigger at Source Event Date Change: Die Regel wird ausgeführt, sobald sich das Source Event ändert

14.)  Act Exists?:

·         Not important: Die Einstellung wird ignoriert

·         No: Die Regel wird nur ausgeführt, wenn das Actual-Datum des Source Events nicht gefüllt ist

Achtung: Die Einstellung No + Source Event Type „ACT“ wäre ein Logikfehler und die Regel würde nicht korrekt auslösen.  

·         Yes: Die Regel wird nur ausgeführt, wenn das Actual-Datum des Source Events gefüllt ist

15.)     Est Exists?:

·         Not important: Die Einstellung wird ignoriert

·         No: Die Regel wird nur ausgeführt, wenn das Estimated-Datum des Source Events nicht gefüllt ist

Achtung: No + Source Event type „EST“ ist ein Logikfehler!

·         Yes: Die Regel wird nur ausgeführt, wenn das Estimated-Datum des Source Events gefüllt ist

16.)  Trigger past EST events:

·         Date can be in the past: Die Regel wird auch ausgeführt, wenn das Tagesdatum nach dem Estimated Datum liegt, sprich das Estimated Datum darf zum Zeitpunkt der Ausführung der Regel in der Vergangenheit liegen.

Achtung: Wenn das Source Event „ACT“ lautet, immer diese Einstellung wählen.

·         Date can not be in the Past: Die Regel wird nur ausgeführt, wenn das Tagesdatum vor dem Estimated Datum liegt, sprich das Estimated Datum darf zum Zeitpunkt der Ausführung der Regel nicht in der Vergangenheit liegen.

·         Date must be in the Past: Die Regel wird nur ausgeführt, wenn das Tagesdatum nach dem Estimated Datum liegt, sprich das Estimated Datum muss zum Zeitpunkt der Ausführung der Regel in der Vergangenheit liegen. 

·         keine Auswahl: Die Einstellung wird ignoriert und die Regel immer ausgeführt.

17.)  Event Offset:

Es kann die Anzahl der Tage definiert werden, wann die Regel vor oder nach dem Eintreten des Source Events ausgeführt werden soll.

Beispiele:

a.)   -1 = 1 Tag vorher

b.)   -2 = 2 Tage vorher

c.)   1 = 1 Tag danach

d.)   2 = 2 Tage danach

e.)   0 oder keine Eingabe = Zu dem Zeitpunkt des Events

18.)  Notify Responsible:

Wird der Haken gesetzt, dann erhält der verantwortliche Mitarbeiter (im Normalfall derjenige, der die TMS-Position angelegt hat) zusätzlich zum eigentlichen Empfänger die E-Mail.

19.)  Link Mail:

Die generierte Mail wird im E-Mail Interface angezeigt. Um das gewünschte Verhalten ausführen zu könne, ist es notwendig, dass der entsprechende Document Type als Shipment Doc klassifiziert wird.

20.)  „Send Mail to Creator (Person)“:

Ist die Checkbox aktiviert, wird zusätzlich zum eigentlichen Mailempfänger, eine E-Mail an den Creator eines eShipments gesendet, sofern an dessen Person eine Mailadresse hinterlegt ist.

21.)  Mail subject:

Betreff der E-Mail. Die Platzhalter aus Feld „Mail text“ können auch hier verwendet werden.

22.)  Mail text:

Hier wird der eigentliche Text der E-Mail definiert.

Der Mailtext kann aus festem Text und/oder Platzhaltern bestehen.

Per Mouseover werden die möglichen Platzhalter (in geschweiften Klammern {}) angezeigt.

Diese können in genau dieser Schreibweise eingefügt werden und werden dann mit den Inhalten aus den Sendungsdaten überschrieben[SS1] .

23.)  Filter:

 Per Filter kann definiert werden:

·         Dass die Regel nur auslöst, wenn bestimmte Transportbeteiligte / Incoterms / Adressgruppen in der Sendung enthalten sind

·         Dass die Regel nur auslöst, wenn bestimmte Transportbeteiligte / Incoterms / Adressgruppen in der Sendung NICHT enthalten sind (via Exclude-Funktion)

Es ist immer eine Mehrfachauswahl möglich.

Ist kein Filter gesetzt, löst die Regel immer aus, unabhängig von den o.g. Faktoren.

Gleiche Filter (z.B. 1. Consignee = Firma ABC, 2. Consignee = Firma DEF) werden mit "ODER" verknüpft.

Unterschiedliche Filter (z.B. 1. Consignee = Firma ABC, 2. Incoterm = FOB) werden mit "UND" verknüpft.

24.)  Send Mail to:

Hier wird der eigentliche E-Mail-Empfänger hinterlegt. Es ist immer eine Mehrfachauswahl möglich.

·         Direct email: Eine direkte Mailadresse kann eingetragen werden. Per Komma-Separierung können mehrere Adressen eingetragen werden.

·         Fixed person: Eine Person kann eingetragen werden. Die Person muss in den Stammdaten mit E-Mailadresse hinterlegt sein.

·         Related party: Hier können Transportbeteiligte (z.B. Shipper oder Consignee) eingetragen werden. Das System prüft dann, wer in diesem Fall der entsprechende Teilnehmer ist. Es wird dann immer die allgemeine E-Mailadresse aus der Company verwendet.

Image Removed