Berechtigungsobjekt: STASTATUSEVENTKO
| Hierbei handelt es sich um ein Stammdatenprogramm zur Definition der von diversen Schnittstellen zurückgegebenen Statusarten und den Folgen daraus. |
| Beispiele: IMP Platform (Dakosy), Champ, ZAPP-Air, Ocean Insights, Portbase oder Oceanbooking. |
Frage:
|
| Die Aktionen, die aus zurückgemeldeten Statusarten resultieren, werden pro Provider in den Stammdaten hinterlegt. Provider meint hierbei den Lieferanten der Status, z.B. Champ oder die IMP Platform. |
| Der Abruf von Statusanfragen erfolgt über den Reiter Statusanforderung einer Position an den jeweiligen Provider. |
| Die aktuellen Daten werden auf dem Reiter EDI-Status im Auftrag angezeigt. |
Schritt 1: Provider als CS Codes hinterlegen
In den Stammdaten ADMIN → CS ADMIN → CS CODES werden die Provider in Form von Codes hinterlegt.
Schritt 2: Statusevents definieren
Im Kopfbereich kann nun der in den Codes hinterlegte Provider ausgewählt werden.
In den Positionsdaten werden nun die Statusarten erfasst, die von diesem Provider gesendet werden.
Zu jedem Status können die Aktionen erfasst werden.
Tabellen: statuseventko_t und statuseventpo_t (Master - Detail).
| Feld | Funktion |
|---|---|
| Statuscode | Der Statuscode zusammen mit der Niederlassung (kann angegeben sein oder XXX für alle) ist pro Zeile in statuseventpo_t für einen Provider eindeutig. |
| Niederlassung | Über die Niederlassung kann beispielsweise definiert werden, dass FRA eine Info per Mail erhalten möchte bei einem DEP-Status von TRAXON, Niederlassung HAM jedoch nicht. Der eingetragene Wert im Feld Niederlassung wird gegen die Stammdaten geprüft. Eine Übernahme des Wertes erfolgt nur, wenn der Wert in den Stammdaten vorhanden ist. Zusätzlich ist der Eintrag XXX ohne Stammdatensatz erlaubt. |
| Info an User | Hier wird in den Mitarbeiteroptionen nachgesehen, ob der Mitarbeiter eine Message hat und ob er zusätzlich eine eMail erhalten möchte. |
| Info per Task | Hat aktuell keine Funktion. |
| Mailverteiler für Info | Hier kann ein Mailverteiler eingetragen werden, an den die Nachricht gehen soll. |
| füllt Feld | Füllt das jeweilige Feld im Auftrag. Im unteren Bereich gibt es die Möglichkeit, nach Bereich und Modus zu steuern. Details siehe nachfolgendes Kapitel. → Ist ein Code in füllt Feld hinterlegt und die Checkbox Daten überschreiben aktiviert, wird bei Empfang des Statuscodes aus der Schnittstelle das entsprechende Feld im Auftrag aktualisiert. |
| Statusart | Der eingetragene Wert im Feld Statusart wird gegen die Stammdaten geprüft. Eine Übernahme des Wertes erfolgt nur, wenn der Wert in den Stammdaten vorhanden ist. Die Übertragung von Sendungsdaten per Schnittstelle kann durch das Setzen eines Auftragsstatus erfolgen. |
| Update Unterpos. | Sollen Statusmeldungen, die in eine Consol-Sendung eingehen, an die Unterpositionen weitergegeben werden, aktivieren Sie diese Checkbox für den gewünschten Statuscode. |
| Daten überschr. |
→ Ist ein Code in füllt Feld hinterlegt und die Checkbox Daten überschreiben aktiviert, wird bei Empfang des Statuscodes aus der Schnittstelle das entsprechende Feld im Auftrag aktualisiert. |
Füllt Feld-Regeln
Statusevents 'füllt Feld' nach Bereich unterscheiden
Im unteren Bereich gibt es die Möglichkeit, Statusrückmeldungen nach Bereich (Import/Export) und nach Modus (Air/Sea/KEP usw.) zu steuern.
Eingaben pro Modus/Bereich werden priorisiert beachtet.
Per Rechtsklick können Zeilen zu dem ausgewählten Status hinzugefügt werden.
Diese Zeile kann auch kopiert werden, hierbei werden jedoch die Felder Modus und Bereich geleert, da Doppeleintragungen nicht möglich sind.
Statusevents, welche pro Modus/Bereich hinterlegt sind, werden derzeit nur für die Standard EDI-Schnittstellen ausgewertet.
Rückmeldungen der Provider Traxon, Atlas, Zapp Air/Sea (über 4gl Programm) beachten Statusevents pro Modus/Bereich derzeit noch nicht.
Status inklusive Hafen/Transshipmenthafen
Wird beim Empfang eines Status ein Hafen übermittelt, wird dieser mit dem Ankunfts- bzw. Abgangshafen des Auftrags abgeglichen, sofern für den Status die füllt-Feld-Regel 002 oder 003 hinterlegt ist.
→ Stimmt der Hafen mit denen des Auftrags überein, wird die Füllt-Feld-Regel angewendet.
→ Bei nicht Übereinstimmung wird die Regel nicht beachtet und die Felder des Transportwegreiters nicht gefüllt.
Bei der Füllt-Feld-Regel 003 wird auch der Transshipmenthafen ausgewertet:
Sollte der Hafen der Endbestimmung nicht mit dem Hafen des Status übereinstimmen, wird der Hafen gegen den Transshipmenthafen geprüft:
→ Passen die Häfen: Stimmen die Häfen überein, werden die Felder eakopf_t.ank_tship_dat und eakopf_t.ank_tship_zeitank gesetzt.
→ Passen die Häfen nicht: Stimmen die Häfen nicht überein, wird kein Datum (Ankunfts- und Transshipment-Datum) gesetzt.
Wird über die Schnittstellen (Statusnachricht) kein Hafen übertragen und es soll die Füllt-Feld-Regel 003 angewendet werden, wird die Prüfung der Häfen übersprungen und es wird das Datum der Endbestimmung (Ankunftsdatum) gesetzt.
Champ: Tatsächliche Ankunft im Ladehafen/Abgangsflughafen
Bei Rückmeldungen von Champ kann die füllt-Feld-Regel 011 (Tats. Ankunft im Ladehf./Abgangsflughf.) eingestellt werden.
Damit wird das Feld Tats. Ankunft im Ladehf./Abgangsflughf im Transportwegreiter mit den Daten aus der Rückmeldung gefüllt.
ZAPP-Air: Tatsächliche Lagerung auswerten
Man kann zum Statusevent GIN (Gate-In für Zapp-Air) die füllt-Feld-Regel 010 (tats. Lagerung) eintragen.
Mit der Gate-In Meldung, wird das Feld Lagerung-Tatsächl.Termin/Zeit im Transportwegreiter gefüllt.
ATLAS CURREL: Verzollt je Container
Mit der ATLAS CURREL Nachricht (dort werden die Container zurückgemeldet) werden die Felder im Auftrag Warenbeschreibung → Container: Verzollung am/um (eawarecon_t.verzollung_am und verzollung_zeit) gefüllt, sofern in den Statusevents füllt-Feld-Regel 008 (tats. Verzollung am) eingetragen ist.
Statusevents → Statuscodes
In den Stammdaten ADMIN → STATUSARTEN → STATUSEVENTS wird für jeden Provider definiert, in welchen Aufträgen er verwendet werden kann.
Hierzu wurde ein Erfassungsbereich unterhalb der Statuscodes geschaffen.
