Page tree
Skip to end of metadata
Go to start of metadata

Einleitung

Mit Hilfe der Anwendung Trackingvorlagen können Vorlagen für Trackingpläne gepflegt werden. Diese Vorlagen legen fest

  1. welche Milestones ein Trackingplan enthält,
  2. wie Milestones erfüllt werden,
  3. welche Aktionen bei der Erfüllung eines Milestones ausgeführt werden sollen,
  4. welche Voraussetzungen erfüllt sein müssen, damit ein Trackingplan aus der entsprechenden Vorlage angelegt wird und
  5. welche unerwarteten Ereignisse (Exceptions) in einem Trackingplan auftreten können.

Achtung

Diese Anwendung richtet sich an erfahrene Benutzer, die mit Tracking-Events und mit EDI-Kommunikation in Scope vertraut sind. Bitte lesen Sie zunächst die Einleitung zur Anwendung (e) Sendungsmonitor, um sich mit den Grundlagen vertraut zu machen.

Übersicht

In der Übersicht werden sämtliche Trackingvorlagen angezeigt. Mit Hilfe der Programmaktionen Neu und Bearbeiten können Trackingvorlagen erstellt beziehungsweise bearbeitet werden. Die Programmaktion Aktualisieren lädt die Liste aller Trackingvorlagen erneut aus der Datenbank.

Im Vorschau-Bereich zeigt eine Tabelle die Anwendbarkeitskriterien der oben ausgewählten Trackingvorlage an (siehe Filter).

Neu

Über den Menüeintrag Individual-Tracking-Vorlage wird eine neue Trackingvorlage erstellt, die keinerlei Bezug zu einer anderen hat. Über den Menüeintrag aus Basis-Tracking-Vorlage kann eine neue Trackingvorlage auf Grundlage einer bereits existierenden Vorlage angelegt werden. Hierfür muss der Benutzer die so genannte Basisvorlage auswählen:

Eine neue Vorlage "erbt" alle Milestone-Vorlagen und Exception-Vorlagen der Basisvorlage. Diese können in der neuen Vorlage strukturell nicht verändert werden, es ist aber möglich, zusätzliche Aktionen oder Alarme für diese einzustellen.

Über die Programmaktion Abhängigkeiten anzeigen sieht man, für welche weiteren Vorlagen die gerade ausgewählte Vorlage als Basisvorlage dient:

In diesem Beispiel ist die Vorlage "Company Tracking Plan" die Basis. Diese Vorlage wurde für "DUS Tracking Plan" als Basis verwendet, in welcher Eigenschaften für die Niederlassung Düsseldorf hinzugefügt wurden. Der Trackingplan "ShipperInterface" wiederum verwendet die Trackingvorlage "DUS Tracking Plan" als Basisvorlage. In dieser Vorlage befinden sich alle Milestone-Vorlagen und Exception-Vorlagen von "Company Tracking Plan" und "DUS Tracking Plan". Außerdem wurden z.B. kundenspezifische EDI-Aktionen für den Geschäftspartner "Shipper" eingestellt.

Durch dieses Vererben von Eigenschaften kann man unkompliziert Tracking Pläne ändern, wenn man die Basis ändert.

Trackingvorlagen bearbeiten

Der Editor für Trackingvorlagen gliedert sich in zwei Reiter: Anwendbarkeit und Milestone-Vorlagen.

Reiter Anwendbarkeit

Name

Im Textfeld Name wird der eindeutige Name der Trackingvorlage vergeben.

Version

Trackingvorlagen werden versioniert abgespeichert, das heißt das bei jedem Speichern einer Trackingvorlage eine neue Version erstellt wird. Dies dient dazu, laufende Trackingpläne, die diese Trackingvorlage verwenden, nicht zu beeinträchtigen und eine konsistente Auswertung zu ermöglichen. Jeder Trackingplan gehorcht genau einer Version einer Trackingvorlage.

EDI-Profil

Das Tracking verwendet für die ausgehende EDI-Kommunikation so genannte EDI-Profile, um Adressen-Identifier, spezielle Referenztypen und Adressaten zu ermitteln. Im Bereich EDI-Profil wird festgelegt, ob das passende EDI-Profil dynamisch aus den Auftragsdaten ermittelt oder ob für alle Vorgänge, die aus dieser Trackingvorlage heraus erstellt werden, ein bestimmtes EDI-Profil verwendet werden soll. Im Dropdown-Feld unter Immer folgendes EDI-Profil: stehen alle EDI-Profile zur Auswahl, die in Scope existieren (siehe EDI-Profile - Stammdaten).

Filter

Filter werden von Scope angewandt, um zu ermitteln, aus welcher Trackingvorlage ein Trackingplan für einen bestimmten Auftrag anzulegen ist. Da diese Filter sich auf bestimmte Auftragseigenschaften beziehen, ist eine Neuanlage von Filtern erst möglich, wenn ein Auftragstyp ausgwählt wurde (nicht alle Auftragstypen haben die selben Eigenschaften). Die Schaltfläche Neu... öffnet einen Dialog, in dem ein neuer Filter definiert werden kann; je nach ausgewählter Auftragseigenschaft wird für das Filterkriterium ein Text- oder ein spezielles Suchfeld angezeigt (z. B. ein Feld für Gewichtseingabe).

Damit eine Trackingvorlage auf eine Sendung zutrifft, müssen alle Filter zutreffen. Gibt es für eine Auftragseigenschaft mehrere Filter, so muss von diesen mindestens einer zutreffen. Umgangssprachlich: Filter der selben Auftragseigenschaft werden mit ODER, Filter verschiedener Auftragseigenschaften mit UND verknüpft.

Beispiel Verknüpfung von Filtern

Trackingvorlage: "Export LAX Kunde ABC Industries":

AuftragseigenschaftWert
DestinationLAX
VersenderShipper A
VersenderShipper B

Sendungen:

VersenderDestinationTrackingvorlage trifft zu
Shipper ALAX(tick)
Shipper BLAX(tick)
Shipper AMIA(error)
Shipper CLAX(error)

Mit Hilfe des Felds Priorität können Sie festlegen, wie stark ein Filter bei der Suche nach einer passenden Trackingvorlage für eine Sendung gewichtet werden soll:

Beispiel Priorität Filter

Trackingvorlage 1: "Export LAX"

Auftragseigenschaft

WertPriorität
ExportagentDSTDUS1
DestinationUSLAX1

Trackingvorlage 2: "Export MyKunde"

AuftragseigenschaftWertPriorität
ExportagentDSTDUS1
AuftraggeberMyKunde2

Bei einer Exportsendung der Niederlassung DSTDUS mit Auftraggeber MyKunde und Bestimmungsort USLAX wird bei oben dargestellter Konfiguration die Trackingvorlage 2 ausgewählt, da jeweils beide Filter zutreffen, der Auftraggeber-Filter aber mit 2 Punkten in den Gesamtwert von Trackingvorlage 2 eingeht.

Freilich kann es trotzdem passieren, dass für eine bestimmte Sendung mehrere Trackingvorlagen gleich gut abschneiden, also nach Anwendung aller Filter den gleichen Gesamtwert haben. Scope wählt in diesen Fällen "willkürlich" aus diesen aus. Solange ein Trackingplan für eine Sendung noch keine erfüllten Milestones beinhaltet, sucht Scope bei jeder Aktualisierung der Sendung nach einer passenderen Trackingvorlage.

Reiter Milestone-Vorlagen

Der Reiter Milestone-Vorlagen gliedert sich in zwei Bereiche: links die Liste aller definierter Milestone-Vorlagen und Exception-Vorlagen, rechts die Eigenschaften des ausgewählten Elements.

Die Liste im linken Bereich ist wie folgendermaßen strukturiert:

EbeneElementeErläuterung
1SendungsabschnittJede Sendung in Scope wird in bestimmte Abschnitte eingeteilt. Je nach Sendungseigenschaften wie Auftragsumfang oder Verkehrsträger werden bestimmte Abschnitte automatisch aktiviert oder ausgeblendet. Z.B. wird bei einem Auftragsumfang "Port to Door" der Sendungsabschnitt "Pick Up" ausgeblendet. Milestones in ausgeblendeten Sendungsabschnitten werden im Trackingplan nicht berücksichtigt. Grundsätzlich sind aber alle Sendungsabschnitte aktiv, unabhängig davon, ob der Trackingplan momentan aussschließlich für eine Export- oder eine Importsendung gilt.
2Milestone-Vorlagen und Exception-VorlagenMilestone-Vorlagen für den jeweiligen Sendungsabschnitt. Außerdem können Exception-Vorlagen für einen Sendungsabschnitt definiert werden, wenn sich Exceptions keinem bestimmten Milestone zuordnen lassen.
3Milestone-spezifische Exception-VorlagenException-Vorlagen, die der Milestone-Vorlage aus Ebene 2 zugeordnet sind (z.B. Exception-Vorlage "FNA" für Milestone-Vorlage "FWB")

Die folgenden Segmente stehen zur Verfügung:

Pickup: Das Segment ist aktiv, wenn die Sendung Door2Port oder Door2Door ist oder ein Abholauftrag vorliegt.
Delivery to Export Gateway: Das Segment ist aktiv, wenn eine Sendung konsolidierbar ist und Exportgateway und Agent in der Sendung gefüllt sind.
Security Measure: Das Segment ist aktiv, wenn die Sendung Transportart Luft ist.
Export Handling: Das Segment ist immer aktiv.
Export Customs: Das Segment ist immer aktiv.
Delivery to Terminal: Das Segment ist aktiv für Master, Direct, B2B und alle nicht konsolidierbaren Sendungen.
Main Carriage Air: Das Segment ist aktiv, wenn die Sendung Transportart Luft ist.
Main Carriage Sea: Das Segment ist aktiv, wenn die Sendung Transportart See ist.
Main Carriage Road: Das Segment ist aktiv, wenn die Sendung Transportart Strasse ist.
Pickup from Terminal: Das Segment ist aktiv für Master, Direct, B2B und alle nicht konsolidierbaren Sendungen.
Import Customs: Das Segment ist immer aktiv.
Import Handling: Das Segment ist immer aktiv.
Import Warehouse: Das Segment ist immer aktiv.
Delivery to Import Branch: Das Segment ist aktiv, wenn eine Sendung konsolidierbar ist und Importgateway und Importagent in der Sendung gefüllt sind.
Delivery: Das Segment ist aktiv, wenn die Sendung Port2Door oder Door2Door ist oder eine Zustellung vorliegt.

Milestone-Vorlagen der aktuellen Trackingvorlage haben kein eigenes Icon. Stammt die Milestone-Vorlage aus einer Basisvorlage, dann wird dies durch ein Schloss-Icon  gekennzeichnet. Diese Milstone Vorlagen können nicht bearbeitet oder gelöscht werden. Es können jedoch zusätzliche Milestones hinzugefügt werden . Exception-Vorlagen werden mit einem Blitz-Icon  dargestellt.

Über die Schaltflächen im oberen Bereich kann eine neue Milestone-Vorlagen angelegt (grünes Plus) oder gelöscht werden (rotes Kreuz); außerdem können neue Exception-Vorlagen angelegt werden (grünes Plus mit Blitz).Alle Elemente können mit Hilfe von Drag and Drop verschoben werden.

Milestone-Vorlagen

Die Eigenschaften einer Milestone-Vorlage sind in vier Bereiche gegliedert:

Allgemein

Code

Im Feld Code wird die Kurzbezeichnung der Milestone-Vorlage (und damit auch der Milestones auf Auftragsebene) festgelegt. Im vorliegenden Beispiel orientieren sich die Codes an der in der Luftracht üblichen Nomenklatur, also PUP für "Pick up at shipper", REW für "Received at Export Warehouse" und so weiter, es lassen sich aber beliebige Codes verwenden. Die Codes werden z. B. in der Sendungsmonitor-Übersicht angezeigt, um Platz zu sparen.

(warning) Wenn Meilensteine von Master auf House Ebene heruntergebrochen / synchronisiert werden sollen und die Sendungen unterschiedliche Trackingpläne verwenden, muss der Code in beiden Plänen identisch sein, damit das Synchronisieren funktioniert. (warning)

Beschreibung

Im Feld Beschreibung können etwas längere Beschreibungen für die ausgewählte Milestone-Vorlage in verschiedenen Sprachen gepflegt werden. Wenn ausreichend Platz vorhanden ist, wird in Scope diese Beschreibung anstatt des Codes angezeigt.

Auslösende Ereignisse

In der Liste Auslösende Ereignisse stehen alle Eventtypen, auf die dieser Milestone "gemappt" werden soll: Wird ein Event des festgelegten Typs für den zugeordneten Auftrag registriert, so werden dessen Event-Eigenschaften in Hinblick auf die Erfüllung des Milestones interpretiert. Im vorliegenden Beispiel werden Milestones vom Typ DEP beim Eintreffen einer Airline-Nachricht CIMP_DEP aktiviert.

Hinweis

Die Liste möglicher Eventtypen ist sehr umfangreich. Wir haben jedoch, aus Rücksicht auf die allgemeine Scope-Performance, nicht an allen Stellen, an denen ein Event erstellt wird, Triggerpunkte eingebaut, um Milestones auf ihre mögliche Befriedigung hin zu untersuchen. Sichere Kandidaten sind Events, die

  • über eine Schnittstelle empfangen werden (z.B. alle Eventtypen, die mit CIMP_ beginnen),
  • Workflowevents sind (z.B. "Sendung abgeschlossen", "Rechnung storniert") oder die
  • für die Kommunikation zwischen Modulen wichtig sind (z.B. alle Zollevents).


Kriterien

Im Bereich Kriterien werden alle weiteren Event-Kriterien angezeigt, die erfüllt sein müssen, um den entsprechenden Milestone zu befriedigen. Mit den Schaltflächen Neu... und Löschen können Event-Kriterien hinzugefügt beziehungsweise entfernt werden.

Die Definition von Event-Kriterien beinhaltet die Angabe der Ereignisattribute (Dropdown-Feld je nach ausgewähltem Eventtyp), der Auswertungsmethode, eines statischen Werts (je nach Ereignisattribute, z. B. Textfeld, Gewichtsfeld, Ortsfeld, usw.) oder einer Auftragseigenschaft (Dropdown-Feld mit passenden Auftragseigenschaften). Die Auswertungsmethode legt fest, ob zur Befriedigung des Kriteriums der Wert des ersten oder des letzten Events oder die Summe der Werte aller Events herangezogen wird.

Das abgebildete Beispiel lässt sich also so interpretieren: Das Ereignisattribut location des ersten DEP-Events muss mit der Auftragseigenschaft Abgangsort Hauptlauf übereinstimmen, damit der Milestone befriedigt wird.

Ort

Für die Ermittlung des geplanten Ortes eines Milestones gibt es zwei Verfahren: Entweder ist in der Milestone-Vorlage ein fixer Ort definiert (Radio-Button Fix:: und Suchfeld für Orte) oder der Ort wird dynamisch aus einer Auftragseigenschaft ermittelt (Radio-Button Ort aus Auftragseigenschaft: und Dropdown-Feld für Auftragseigenschaft).

Die folgenden Orte stehen zur Verfügung:

  • Versender Ort: Feld "nächster UNLOCODE" in der Geschäftspartner Pflege
  • Empfänger Ort: Feld "nächster UNLOCODE" in der Geschäftspartner Pflege
  • Auftraggeber Ort: Feld "nächster UNLOCODE" in der Geschäftspartner Pflege
  • Exportagent Ort: Feld "nächster UNLOCODE" in der Geschäftspartner Pflege
  • Importagent Ort: Feld "nächster UNLOCODE" in der Geschäftspartner Pflege
  • Zollagent Ort: Feld "nächster UNLOCODE" in der Geschäftspartner Pflege
  • Abgangsort: Eingetragener Vorlauf in der Sendungserfassung "Allgemein" Reiter
  • Ankunftsort: Eingetragener Vorlauf in der Sendungserfassung "Allgemein" Reiter
  • Abgangsort Hauptlauf: Eingetragener Hauptlauf in der Sendungserfassung "Allgemein" Reiter
  • Ankunftsort Hauptlauf: Eingetragener Hauptlauf in der Sendungserfassung "Allgemein" Reiter
  • Ladehafen Hauptlauf: Eingetragener Hauptlauf in der Sendungserfassung "Allgemein" Reiter (Seefracht Import / Export)
  • Löschhafen Hauptlauf: Eingetragener Hauptlauf in der Sendungserfassung "Allgemein" Reiter (Seefracht Import / Export)
  • Abholstelle / Lieferstelle: Wenn "Gewünschte Abholzeit" / "Gewünschte Lieferzeit" im Allgemein Reiter der Sendung eingetragen ist, wird der Versender Ort (Feld "nächster UNLOCODE" in der Geschäftspartner Pflege) gezogen. Wenn keine Abhol/Lieferzeit eingetragen ist, aber Transportaufträge existieren, wird die Zeit und der Ort auf der Transportorder gezogen

Verantwortliche Partei

Pro Milestone kann eingestellt werden, welche Partei für dessen Erledigung verantwortlich ist. Die Einstellung kann anhand eines fixen Geschäftspartners (statisch) oder anhand einer bestimmten Rolle einer Sendung (dynamisch) ermittelt werden. Die verantwortliche Partei wird im Trackingplan angezeigt; außerdem können Benutzer nach dieser im (e) Sendungsmonitor filtern. Verfügt die verantwortliche Partei über einen Zugang zum Web Tracking und Tracing, so kann sie eine Liste aller Sendungen abrufen, für die sie momentan verantwortlich ist. Z.B. würde ein Fuhrunternehmer alle Sendungen sehen, für deren Abholung oder Zustellung er zuständig ist. Die verantwortlichen Parteien werden auch im Qualitätsbericht aufgelistet, um eine Lieferantenbeurteilung zu unterstützen.

Bestätigung

Im Bereich Bestätigung kann festgelegt werden, ob fehlgeschlagene Milestones durch einen Benutzer bestätigt werden müssen oder nicht. Soll eine Bestätigung eingerichtet werden, muss zudem die Codeliste mit möglichen Gründen für die Abweichung angegeben werden (siehe Bestätigungs-Codelisten).

Sichtbarkeit Web

Trackingpläne sind über die Anwendung Web Tracking und Tracing für externe Parteien einsehbar. Mithilfe der Sichtbarkeit kann bestimmt werden, ob ein bestimmter Milestone sichtbar sein soll und ob ein Milestone über die Web-Tracking-und-Tracing-Anwendung erfüllbar ist. Folgende Einstellungen sind möglich:

EinstellungSichtbarkeitErfüllbarkeit
Unsichtbar oder leerDer Milestone wird in der Web-Tracking-und-Tracing-Anwendung unter keinen Umständen angezeigtDer Milestone ist über die Web-Tracking-und-Tracing-Anwendung nicht erfüllbar
SichtbarDer Milestone wird allen Benutzern der Web-Tracking-und-Tracing-Anwendung angezeigtDer Milestone ist über die Web-Tracking-und-Tracing-Anwendung nicht erfüllbar
Sichtbar, von allen erfüllbarDer Milestone wird allen Benutzern der Web-Tracking-und-Tracing-Anwendung angezeigtDer Milestone ist über die Web-Tracking-und-Tracing-Anwendung von allen Benutzern erfüllbar
Sichtbar, von verantwortlicher Partei erfüllbarDer Milestone wird allen Benutzern der Web-Tracking-und-Tracing-Anwendung angezeigtDer Milestone ist über die Web-Tracking-und-Tracing-Anwendung von Benutzern, die der momentan verantwortlichen Partei zugeordnet sind, erfüllbar

Tatsächliche Zeit bei manueller Erledigung

Für die Ermittlung der tatsächlichen Zeit gibt es zwei Möglichkeiten. Zum einen dürfen die Benutzer die tatsächliche Zeit eintragen. Im zweiten Fall ist eine manuelle Erfassung nicht möglich. Scope setzt die Systemzeit als Erledigungszeit für den Milestone.

Planzeit

Der Zeitplan einer Milestone-Vorlage legt fest, wie der geplante Zeitpunkt einer Milestone-Erfüllung ermittelt werden soll und in welchem Zeitrahmen ein Milestone überhaupt erfüllt werden kann:

Geplanter Zeitpunkt

Es stehen drei Verfahren zur Verfügung, um den geplanten Zeitpunkt der Milestone-Erfüllung zu ermitteln. Für alle drei Verfahren kann mit Hilfe des Offsets ausgehend vom initialen geplanten Zeitpunkt eine Zeitspanne addiert oder subtrahiert werden (Angabe in Stunden).

Relativ zu einem anderen Milestone

Der geplante Zeitpunkt des Milestones wird über den geplanten Zeitpunkt eines anderen Milestones ermittelt. Der Offset wird absolut addiert, Lokalzeiten können also abweichen; Beispiel: Planzeit M1 (DEFRA): 1.6.2012 22:00, Offset: +2h -> Planzeit M2 (GBLHR) 1.6.2012 23:00.

Wird die Planzeit aus einem anderen Milestone berechnet, kann ferner festgelegt werden, ob sie aus der geplanten oder gegebenenfalls der tatsächlichen Zeit des anderen Milestones berechnet werden soll, Beispiel:


ARRRCFNFDDLV
EinstellungAuftragseigenschaft ETDRelativ ARR (tatsächlich) + 2hRelativ RCF (tatsächlich) + 1hRelativ ARR (Plan) + 12h
Planzeit12:0014:2015:2002:00
Ist-Zeit12:20


Auftragseigenschaft

Der geplante Zeitpunkt des Milestones wird aus einer Auftragseigenschaft (Dropdown-Feld mit "Zeit"-Eigenschaften des Auftragstyps) ermittelt (im Beispiel "Estimated Time of Departure - ETD"). Hier finden Sie eine Übersicht der verfügbaren Planzeiten.

Funktion

Der geplante Zeitpunkt des Milestones wird mit Hilfe einer Spezialfunktion ermittelt. Momentan steht nur die Funktion "Anlagezeitpunkt" zur Verfügung: Bei Auswahl dieser Funktion wird der geplante Zeitpunkt des Milestones beim Anlegen des Milestones mit der aktuellen Uhrzeit vorbelegt.

Sensitivität

Im Bereich Sensitivität wird festgelegt, in welchem Zeitraum eine Milestoneerfüllung als "planmäßig" gilt. Die Angaben beziehen sich auf den geplanten Zeitpunkt des Milestones. Es ist ratsam, eine Sensitivität anzugeben, da Scope sonst Planzeit und Eventzeit auf Millisekunden-Niveau vergleicht; ein Milestone würde also nur unter besonders günstigen Umständen erfüllt.

Gleicher Tag

Wird für einen Milestone das passende Event am selben Tag des geplanten Zeitpunkts registriert, so kann dieser erfüllt werden. Für die Auswertung wird die jeweilige Zeitzone des Milestone-Orts herangezogen (siehe Ort).

Zeitfenster (Stunden)

Mit Hilfe der Eingabefelder für untere und obere Grenze kann, relativ zum geplanten Zeitpunkt, ein Zeitfenster spezifiziert werden, in dem ein Milestone befriedigt werden kann. Zeitangaben können mit englischen Abkürzungen gemacht werden, also z. B. "1h" für "eine Stunde" oder "2d" für "zwei Tage". Es sind keine negativen Werte zulässig.

Beispiel Milestone RCF

Zeitplan:

AuftragseigenschaftEstimated Time of Arrival (ETA)
Offset+4h
Zeitfenster-6h, +12h

Sendung:

DestinationUSLAX
ETA2012-06-01 13:37

Ergebnis Planzeitfenster:

Untere Grenze2012-06-01 11:37 (Pacific Time)
Obere Grenze2012-06-02 05:37 (Pacific Time)

Öffnungszeiten

Über dieses Feld kann eine Strategie definiert werden, wie die Öffnungszeiten der verantwortlichen Partei berücksichtigt werden sollen. Die Öffnungszeiten der verantwortlichen Partei werden aus der Standard-Lieferadresse übernommen (siehe auch Partnerpflege, Reiter Abhol-/Lieferaddressen). Die Öffnungszeiten an Feiertagen (siehe Holiday Appliance) werden wie Sonntage behandelt.Wenn die verantwortliche Partei nicht bestimmt werden kann oder bei der verantwortlichen Partei keine Öffnungszeiten gepflegt sind, werden die von Scope ermittelte Planzeit und das zugehörige Zeitfenster verwendet.

Zur Auswahl stehen die folgenden Strategien

  • k.A.
  • Forward (Cutoff)
  • Forward (Flex)
  • Backward (Flex)
k.A.

Die Öffnungszeiten werden nicht berücksichtigt. Planzeit und Zeitfenster werden so verwendet wie sie von Scope rechnerisch bestimmt werden. Das kann dazu führen, dass eine Aktion ausserhalb der Öffnungszeiten erwartet wird und entsprechende Alarme erzeugt werden.

Forward (Cutoff)

Wenn die Planzeit in ein Öffnungsintervall fällt, wird dieses Intervall verwendet. Wenn die verantwortliche Partei zur Planzeit nicht geöffnet hat, wird das nachfolgende Öffnungsintervall bestimmt. Planzeit und Zeitfenster werden in das bestimmte Öffnungsintervall verlegt, wobei der späteste Zeitpunk gleich bleibt und ggf. auf die Grenze des Intervalls gekürzt wird.

Forward (Flex)

Wenn die Planzeit in ein Öffnungsintervall fällt, wird dieses Intervall verwendet. Wenn die verantwortliche Partei zur Planzeit nicht geöffnet hat, wird das nachfolgende Öffnungsintervall bestimmt. Planzeit und Zeitfenster werden in das bestimmte Öffnungsintervall verlegt, wobei der späteste Zeitpunkt relativ zur neuen Planzeit gelegt wird (in den Grenzen des Öffnungsintervalls).

Backward (Flex)

Wenn die Planzeit in ein Öffnungsintervall fällt, wird dieses Intervall verwendet. Wenn die verantwortliche Partei zur Planzeit nicht geöffnet hat, wird das vorherige Öffnungsintervall bestimmt. Planzeit und Zeitfenster werden in dieses Öffnungsintervall verlegt, wobei der früheste Zeitpunkt relativ zur neuen Planzeit gelegt wird (in den Grenzen des Öffnungsintervalls).

Beispiele

Öffnungszeiten der verantwortlichen Partei: Montag - Freitag 8-12 und 13-17 Uhr

Planzeit 04:00, Zeitfenster -3 Stunden / + 5 Stunden

StrategieAngepasste PlanzeitUntere GrenzeObere Grenze
k.A.04:0001:0009:00
Forward (Cutoff)08:0008:0009:00
Forward (Flex)08:0008:0012:00
Backward (Flex)-1 17:00-1 14:00-1 17:00


Planzeit 10:00, Zeitfenster -3 Stunden / + 5 Stunden

StrategieAngepasste PlanzeitUntere GrenzeObere Grenze
k.A.10:0007:0015:00
Forward (Cutoff)10:0008:0012:00
Forward (Flex)10:0008:0012:00
Backward (Flex)10:0008:0012:00

Zeitzonen

Die Öffnungszeiten werden immer in der Zeitzone des Meilensteins interpretiert.


Aktionen

Der Reiter Aktionen ermöglicht es, weitere Prozesse anzustoßen, sobald ein Milestone erfüllt wurde. Im linken Bereich des Reiters sind alle durchzuführenden Aktionen aufgelistet, im rechten Bereich kann die jeweils ausgewählte Aktion bearbeitet werden. Mit Hilfe der Schaltflächen Neu... und Löschen können weitere Aktionen angelegt beziehungsweise bestehende Aktionen gelöscht werden. Die Definition von Aktionen wird weiter unten beschrieben.

Alarme

Im Reiter Alarme können Benachrichtigungen für unerfüllte Milestones eingerichtet werden. Mit Hilfe der Schaltflächen Neu... und Löschen können neue Alarme definiert beziehungsweise der ausgewählte Alarm gelöscht werden. Pro Alarm wird eine Aktion ausgeführt. Im oberen Bereich des Reiters ist zusätzlich einzustellen, wann der Alarm ausgeführt werden soll. Im Feld Zeitpunkt ist eine Zeitspanne einzugeben, die zum jeweils ausgewählten Referenzzeitpunkt addiert beziehungsweise von diesem subtrahiert werden soll (Auswahlliste  nach und  vor ). Als mögliche Referenzzeitpunkte stehen der Anfang des Planzeitfensters , der Geplante Zeitpunkt und das Ende des Planzeitfensters zur Verfügung.

Exception-Vorlagen

Im Reiter Allgemein einer Exception-Vorlage werden Name, Beschreibung, Trigger-Ereignisse und sonstiges Verhalten einer Exception festgelegt. Im Reiter Aktionen kann eingestellt werden, welche Aktionen beim Auftreten einer Exception ausgeführt werden sollen.

Code

Sprachunabhängige Kurzbezeichnung der Exception.

Name

Ausführlicher Name der Exception. Hier können auch Übersetzungen für verschiedene Sprachen eingetragen werden.

Ereignistypen

Welche Ereignistypen führen dazu, das diese Exception "getriggert" wird?

Singleton-Exception

Gilt ein wiederholtes Auftreten eines Ereignistyps als neue Exception oder ist es ausreichend, wenn die Exception auf einem Trackingplan einmalig registriert wird?

Auto-Erledigung bei Milestone-Erfüllung

Diese Option ist nur für Exception-Vorlagen aktiv, die einer bestimmten Milestone-Vorlage zugeordnet sind. Ist die Option aktiv, so gelten offene Exceptions als behandelt, wenn der dazugehörige Milestone erledigt wird.

Response-Codes

Für die Auswertung der Ursache oder der Behandlung aufgetretener Exceptions ist es hilfreich, kodierte Werte zu verwenden. In diesem Feld kann festgelegt werden, aus welcher Codeliste diese Werte stammen dürfen.

Aktionen

Typ

Das Dropdown-Feld Typ ermöglicht die Auswahl der durchzuführenden Aktion. Es stehen folgende Typen zur Verfügung:

  • Eventnachricht: Versand von Eventnachrichten über EDI. (warning) Nur nach Rücksprache mit Riege Software International nutzen!
  • Email: Versand einer einfachen E-Mail-Nachricht mit Standardtext
  • Cargo 2000 Message: Versand einer Eventnachricht an das Cargo 2000 CDMP-F (warning) Nur nach Rücksprache mit Riege Software International nutzen!
  • In Inbox ablegen: Die zugehörige Akte wird im Ordner Inbox des Empfängers abgelegt.
  • Scope-Benachrichtigung: Dem Empfänger wird in Scope eine Popup-Benachrichtigung angezeigt, sofern er gerade eingeloggt ist. Sollte der Benutzer nicht eingeloggt sein, wird eine Nachricht in seiner "Benachrichtigungsinbox" abgelegt.
  • Milestone synchronisieren: Es muss für alle Sendungen die gleiche Trackingvorlage verwednet weden, damit die Synchronisation der Milestones auf alle Sendungen angewendet werden kann. Hier ein Beispiel: Wird eine Mastersendung angelegt, müssen alle Haussendungen das gleiche Trackingtemplate haben, damit die Synchronisation erfolgreich durchgeführt werden kann. Die Meilensteine werden dann von der Mastersendung automatisch auf die Haussendungen übertragen.

Event-Code

Insbesondere für EDI-Kommunikation kann es erforderlich sein, einen speziellen Code für die Milestone-Erfüllung zu verweden. Im Feld Event-Code wird ein solches "Mapping" eingetragen.

Event-Beschreibung

Im Feld Event-Beschreibung kann eine kurze Beschreibung der Milestone-Erfüllung eingetragen werden, die im Rahmen der Aktion verwendet werden kann (z. B. Erklärung in einer Email, FTX-Feld in einer EDI-Nachricht).

Absender

Für einige Aktionen wird ein Absender benötigt, der normalerweise automatisch ermittelt wird. Mit der Option Fixen Wert für Absender verwenden kann diese automatische Ermittlung ausgeschaltet werden.

Beispiel: Bei einer Email-Aktion ist der automatisch ermittelte Absender normalerweise der Sachbearbeiter der Sendung (max.mustermann@riege.de), die Emails sollen aber vom Verteiler-Email-Konto der Abteilung verschickt werden (dus_export@riege.com).

Empfänger

Es gibt verschiedene Möglichkeiten den Empfänger der Nachricht zu bestimmen.

  • Sachbearbeiter: Die Nachricht wird an den Sachbearbeiter der Sendung geschickt.
  • Auftragseigenschaft: Die Nachricht wird an einen Sendungsbeteiligten, welcher aus einem Dropdownmenü ausgewählt werden kann, übermittelt.
  • Benutzer: Ein Fixer Wert kann für den Benutzer (Scope-Nutzer) eingegeben werden.
  • E-Mail-Adresse: Ein Fixer Wert für eine E-Mail-Adresse kann erfasst werden. Wird keine valide E-Mail Adresse erfasst, so gibt Scope eine Warnung aus. Das Format muss wie folgt erfasst werden: lokaler_Teil@globaler_Teil z.B. max.mustermann@riege.de
  • Verantwortliche Partei: Die Verantwortliche Partei wird im Allgemeinen Reiter der Milestone-Vorlage definiert
  • Konsolidierte Sendungen: Wenn der Milestone eines Master oder Super Haus erledigt wird, werden die untergeordneten Milestones der erfassten Haussendungen ebenfalls erledigt.
  • E-Mail Empfänger Details
    • Kontakt der Adresse: Allgemein die E-Mail-Adresse, welche beim Versender in der Sendung hinterlegt ist.
    • Hauptkontakt des Partners: E-Mail-Adresse die im Reiter "Allgemein" beim Geschäftspartner hinterlegt ist.
    • Kontaktname des Partners mit Rolle: Alle Partner die im Reiter "Ansprechpartner" beim Geschäftspartner hinterlegt wurden und die entsprechende Rolle haben.

Es kann entweder ein statischer oder ein dynamischer Empfänger ausgewählt werden. Ein statischer Empfänger kann z. B. die Emailadresse eines zentralen Verteilers oder eine spezielle EDI-Adresse sein. Wird ein dynamischer Empfänger gewählt, so ermittelt Scope bei der Auswertung des Milestones einen passenden Empfänger aus der angegebenen Auftragseigenschaft (je nach Typ Email-Empfänger oder EDI-Adressen).

Achtung!

Bei statischer Adressierung erfolgt keinerlei Validierung oder Plausibilisierung.