Inhaltsverzeichnis

Configuration

Das Design der Software kann teilweise vom Kunden selbst unter Administration > System Configuration festgelegt werden. Beispielsweise kann der Hintergrund des Systems durch „Background Color“ geändert werden.

Der Hntergrund der Kopfzeile kann durch „Header Background Color“ geändert werden. Die Foreground colors beschreiben die Farben der Beschriftungen sowohl im System, als auch in der Kopfzeile. Man kann entweder aus der Farbpalette wählen oder den Farbcode der gewünschten Farbe eingeben.

Application Title: Name, der im Browser Tab angezeigt wird.

Default Row Count: Anzahl der standardmäßig angezeigten Result-Zeilen im Suchergebnis. Ist hier „15“ eingestellt, werden standardmäßig 15 Zeilen untereinander angezeigt. Ist die Anzahl der gefundenen Ergebnisse kleiner, werden entsprechend weniger Ergebniszeilen angezeigt. Ist die Anzahl der gefundenen Ergebnisse größer als 15, werden die weiteren Ergebnisse auf nachfolgenden Seiten angezeigt.

Company logo maximum height: beschreibt die Größe des gewählten Logos

Default Menu Type: hier kann das Layout der Menü-Bars geändert werden

Close unrelated sub menus: nicht genutzte, unrelevante Menüs werden eingeklappt

Default Layout Mode: Anwendung wird im Light – oder Darkmodus angezeigt

Default input style: wie werden zu befüllende Felder angezeigt

Search panels locked by default: Suche bleibt nach Auslösen der Suche standardmäßig ausgeklappt (Schloss geschlossen)

Result panels locked by default: Suchergebnis bleibt nach Anwählen eines Ergebnisses standardmäßig ausgeklappt (Schloss geschlossen)

Unterreiter Mailing

Das eTracking ermöglicht es Benachrichtigungen per E-Mail an hinterlegte Adressen zu versenden. Die Mailing Regeln, also zu welchen Zeitpunkten wer benachrichtigt werden soll, wird in den Events hinterlegt.

Im folgenden werden die einzelnen Felder beschrieben:

Checkbox Mailing enabled

Damit das System allerdings Mails verschicken kann, muss die Funktion aktiviert werden.

Es muss das Häkchen in der Checkbox Mailing enabled gesetzt werden.

Ist die Checkbox leer, können keine E-Mails versendet werden.

System email address

Frei wählbare Emailadresse, an die Benachrichtigungen aus dem System gehen sollen

Redirect Mails to

Nur diese Adresse bekommt E-Mails. Die anderen User nicht.

Mail overflow

Wenn die eingetragene Anzahl an Nachrichten überschritten wird, wird das Mailing abgeschaltet.

Die Versendung der E-Mail erfolgt immer von der gleichen E-Mailadresse. Wie diese aussieht, hängt davon ab, wo das System gehosted ist. Ob von der CargoSoft Muttergesellschaft Dakosy oder auf einem vom Kunden gewählten Server. Hierfür wird das Feld System Email Address genutzt.

Wird der Dakosy Mailausgangsserver genutzt, gilt: *kunde*@cargosoft.de
Wird ein anderer Server genutzt, darf die E-Mailadresse nicht auf @cargosoft.de enden.

Rules 2

Abgrenzung Rules und Funktionen von Rules 2

Rules 2 ist die Weiterentwicklung von Rules und lösen diese ab. Durch die Weiterentwicklung gibt es eine deutliche Performanceverbesserung. Alle generellen Funktionen aus Rules wurden in Rules 2 übernommen. Neuentwicklungen erfolgen nur noch in Rules 2. 

Mit den Rules 2 lassen sich im SCM Benachrichtigungen und Berechnungen von Events automatisieren, sowie Notifications im System generieren. Rules sind Reaktionen auf Änderungen im System. 

Rules können anhand eines Triggerevents (bspw. die Erstellung einer Sendung oder das Eintragen eines Zeitstempels) ausgelöst werden und so ein Folgeevent (siehe Status Event Rule) füllen/berechnen oder eine E-Mail versenden.

• Rules 2 ist unter Administration > System > Rules 2 zu finden. 

Das SCM stellt verschiedene Regeltypen für verschiedene Anwendungsfälle bereit, welche im Folgenden detailliert beschrieben werden.

Berechtigungen/Function Groups

Die Function Group für diesen Bereich lautet: Administrate Rules 2

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.

Achtung: Die Berechnung erfolgt nur in eine Richtung! Eintrag "2" = Neuer Wert mindestens 2 Tage größer, Eintrag "-4" = Wert mindestens 4 Tage kleiner.

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.