Zeitbasierte Statusprüfung verwalten

Zweck und Einsatzbereich

Die zeitbasierte Statusprüfung wertet aktive Seefrachtakten anhand gespeicherter Buchungs-, Container-, VGM-, Zoll- und Termindaten aus. Fällige Übergänge im Modus AUTO können dabei unmittelbar den Aktenstatus ändern. Andere erkannte Übergänge werden im Ergebnis des Laufs als Vorschläge zurückgegeben.

Im geprüften Hauptfrontend gibt es jedoch keinen sichtbaren Weg, diesen mandantenweiten Prüflauf zu starten, Übergangsmodi zu verwalten oder zurückgegebene Vorschläge zu bestätigen. Der technische Dienst bezeichnet den Lauf als regelmäßig auszuführen, aber der Anwendungsstart verdrahtet dafür keinen Scheduler. Verlassen Sie sich deshalb nicht auf eine automatische Prüfung in einem bestimmten Intervall.

Diese Seite beschreibt den kontrollierten betrieblichen Umgang mit dem vorhandenen manuellen Lauf und seine Grenzen. Sie ist keine Anleitung zum Umgehen der Oberfläche über Browserwerkzeuge oder selbst gebaute Aufrufe.

Voraussetzungen und Berechtigungen

Der Lauf ist nur für ADMIN oder MANAGER vorgesehen und verlangt zusätzlich Akten bearbeiten.
In der aktuellen Organisationseinheit muss Ocean Export oder Ocean Import für schreibende Aktionen freigegeben sein. Ein Nur-Lesen-Modul darf den Lauf nicht ausführen.
Ein aktiver Mandantenkontext ist erforderlich. Die Datenbank grenzt die berücksichtigten Akten auf diesen Mandanten ein.
Der Lauf besitzt keine eigene Organisationseinheitenauswahl. Er prüft innerhalb des Mandanten alle von der Datenbank sichtbaren aktiven Akten, nicht nur Akten der aktuell gewählten Einheit. Auch die Aktenrichtung wird je Datensatz nicht noch einmal gegen die aktuell freigegebene Ocean-Lizenz geprüft.
Plattformadministratoren erfüllen den vorgesehenen Kundenrollenvertrag nicht. Der Lauf gehört in einen kontrollierten Kundenmandantenkontext.
Es gibt keine sichtbare Laufhistorie, Vorschlagsliste, Vorschau oder Rückgängig-Funktion. Vor einem Lauf müssen Verantwortlichkeit, Wartungsfenster, Kontrollumfang und Wiederherstellungsweg betrieblich festgelegt sein.

Führen Sie den Lauf in der Pilotphase nur mit vollständig synthetischen Akten aus. Ein Lauf in einem produktiven Mandanten ist erst vertretbar, wenn die Übergangsmodi freigegeben, betroffene Einheiten einbezogen und Parallelaufrufe organisatorisch ausgeschlossen wurden.

Schritt-für-Schritt-Anleitung

Einen kontrollierten manuellen Lauf vorbereiten

Melden Sie sich als ADMIN oder MANAGER im vorgesehenen Mandanten an und wählen Sie eine Organisationseinheit mit schreibender Ocean-Freigabe.
Öffnen Sie die Ocean-Aktenlisten und erfassen Sie vor dem Lauf die Anzahl sowie den Status aller potenziell betroffenen Akten. Beziehen Sie andere Organisationseinheiten desselben Mandanten ausdrücklich ein.
Prüfen Sie bei diesen Akten Buchungsnummer, Container, VGM-Kennzeichen, freigegebene Zollanmeldung, Cargo Closing, ETD, ATD, ETA, ATA und Container-Rückgabe. Ein gespeicherter Wert kann einen unmittelbaren Statuswechsel auslösen.
Prüfen Sie besonders Kreditblockaden vor möglichen Wechseln von Entwurf zu Gebucht. Die Status-Engine verwendet bei automatischen Übergängen nicht dieselbe Kreditprüfung wie der sichtbare manuelle Buchungsschritt.
Stellen Sie sicher, dass kein zweiter Administrator, Job oder Akten-Schreibprozess parallel denselben Lauf startet. Eine technische Lauf- oder Akten-Sperre ist nicht belegt.
Beauftragen Sie den freigegebenen Betriebskanal mit genau einem manuellen Prüflauf. Dokumentieren Sie Mandant, Zeitpunkt, anfordernde Person und erwarteten Umfang außerhalb von NeuraPort, weil der Lauf selbst keine sichtbare Laufakte erzeugt.
Lassen Sie sich unmittelbar die Werte Geprüft, Automatisch angewendet, Vorschläge offen und die zurückgegebenen Vorschläge sichern. Diese Ergebnisliste wird nicht als benutzersichtlicher Arbeitsvorrat gespeichert.

Ergebnisse fachlich prüfen

Öffnen Sie jede automatisch geänderte Akte und kontrollieren Sie unter Übersicht → Statushistorie Ausgangsstatus, Zielstatus, Systemkennzeichnung und Begründung.
Vergleichen Sie den neuen Status mit der Originalquelle. Ein überschrittenes Plan-Datum allein ist bei Ankunft und Abfahrt nur ein Vorschlagsgrund, kein Nachweis eines tatsächlichen Ereignisses.
Prüfen Sie Kommunikation → Aufgaben. Der globale Statuslauf erzeugt zwar Statushistorie, interne Benachrichtigung und Audit, ruft aber nicht die übliche automatische Aufgabengenerierung des manuellen Statuswegs auf.
Behandeln Sie zurückgegebene Vorschläge als flüchtige Prüfliste. Im Hauptfrontend fehlt ein Vorschlags- und Bestätigungsarbeitsplatz. Ändern Sie einen Status nur über den normalen sichtbaren, schrittweisen Statusweg und nur nach fachlicher Bestätigung.
Laden Sie Aktenliste und betroffene Akten neu. Eine Live-Aktualisierung wird nur best effort ausgelöst und ist kein Abschlussnachweis.
Stimmen die Zähler nicht mit den Akten überein oder ist eine Akte falsch fortgeschritten, stoppen Sie weitere Läufe. Dokumentieren Sie Akte, alten und neuen Status, Trigger und Zeitpunkt für den Betrieb.
Wiederholen Sie den Lauf nicht als vermeintliche Rücknahme. Ein erneuter Lauf kann weitere nun fällige Übergänge anwenden; er setzt keine vorherige Änderung zurück.

Übergangsmodi einordnen

Die technische Konfiguration kennt AUTO, SUGGEST und DISABLED, besitzt aber keine sichtbare Verwaltungsfläche. Ändern Sie diese Konfiguration im aktuellen Stand nicht als Mandanten-Self-Service. Die Regeln werden beim Serverstart global ergänzt und sind nicht nach Mandant oder Organisationseinheit getrennt.

Zudem ist DISABLED derzeit keine belastbare Abschaltung: Ein aktiver Eintrag mit diesem Modus wird vom globalen Lauf wie ein Vorschlag gezählt. Wird ein Konfigurationseintrag auf inaktiv gesetzt, fällt die Engine auf den hinterlegten Standardmodus zurück. Vor einer produktiven Nutzung muss dieser Vertrag technisch korrigiert und mit Negativtests belegt werden.

Feldreferenz

Feld	Pflicht	Bedeutung	Validierung
Geprüft	Systemseitig	Anzahl der im Lauf geladenen, nicht archivierten Akten in den berücksichtigten aktiven Status	Umfasst keine Akten im Status Entwurf, Zugestellt oder Storniert; ist keine Zahl fachlich erfolgreicher Prüfungen.
Automatisch angewendet	Systemseitig	Anzahl der im Lauf ausgeführten AUTO-Übergänge	Statusänderungen erfolgen vor Ausgabe des Ergebnisses; Wert ist keine Vorschau.
Vorschläge offen	Systemseitig	Anzahl aller nicht automatisch ausgeführten Treffer	Umfasst derzeit auch den Modus DISABLED; die Vorschläge werden nicht als sichtbare Aufgaben gespeichert.
Akte	Systemseitig im Vorschlag	Betroffenes Fachobjekt mit interner Referenz und Aktennummer	Nur innerhalb des Mandanten; Ergebnis kann Akten anderer Organisationseinheiten enthalten.
Ausgangsstatus	Systemseitig	Status, für den der Trigger geprüft wurde	Wird unmittelbar vor einer automatischen Änderung noch einmal verglichen, jedoch ohne Zeilensperre.
Zielstatus	Systemseitig	Vorgesehener nächster Status	Muss einen gültigen Statuscode darstellen; im technischen Bestätigungsweg wird ein aktuell vorliegender Vorschlag nicht zwingend erzwungen.
Trigger	Systemseitig	Fachliche Bedingung des Übergangs	Beruht auf gespeicherten Feldern und Status; keine externe Tatsachenbestätigung.
Modus	Konfiguration	AUTO, SUGGEST oder DISABLED	Kein sichtbarer Bedienweg; Abschaltlogik derzeit nicht belastbar.
Konfidenz	Systemseitig im Vorschlag	Fester Bewertungswert des jeweiligen Regelzweigs	Keine statistisch belegte Wahrscheinlichkeit und keine fachliche Freigabe.
Details	Nein	Ausgewählter Auslöserwert, beispielsweise Termin oder Containeranzahl	Kann leer sein; enthält keine vollständige Quellenprovenienz.
Statushistorie	Systemseitig bei Änderung	Alter und neuer Status, Systemkennzeichnung und Grund	Pro angewendetem Übergang gespeichert; kein eigenes Protokoll des gesamten Prüflaufs.
Aktuelle Organisationseinheit	Systemseitig	Kontext für Anmeldung und Ocean-Lizenzprüfung	Grenzt den globalen Lauf selbst nicht auf diese Einheit ein.

Status und mögliche Übergänge

Ausgang	Ziel	Bedingung im Prüfsystem	Standardwirkung im globalen Lauf
Entwurf	Gebucht	Buchungsnummer vorhanden	Standard AUTO, aber der globale Lauf lädt Entwürfe nicht und führt diesen Schritt daher nicht aus. Ein anderer Akten-Schreibweg kann ihn dennoch anstoßen.
Gebucht	VGM ausstehend	Mindestens ein Container vorhanden	AUTO
VGM ausstehend	VGM eingereicht	Alle Container sind als VGM eingereicht gekennzeichnet	AUTO
VGM eingereicht	Zoll ausstehend	Kein zusätzlicher Feldnachweis	AUTO
Zoll ausstehend	Zoll freigegeben	Mindestens eine freigegebene Zollanmeldung vorhanden	AUTO
Zoll freigegeben	Verladung	Cargo-Closing-Datum ist erreicht oder überschritten	SUGGEST
Verladung	Unterwegs	ATD vorhanden	Standard AUTO; bei nur überschrittenem ETD immer SUGGEST
Unterwegs	Angekommen	ATA vorhanden oder ETA überschritten	Immer SUGGEST
Angekommen	Zugestellt	Alle vorhandenen Container sind als zurückgegeben markiert	Immer SUGGEST

Pro Akte wird in einem Lauf höchstens der aktuell fällige nächste Schritt ermittelt. Eine automatisch fortgeschrittene Akte kann daher erst bei einem späteren Lauf oder einem weiteren Akten-Schreibvorgang erneut fortschreiten.

Was im Hintergrund passiert

Beim Serverstart ergänzt NeuraPort fehlende globale Übergangsregeln. Der Anwendungsstart startet eine Lizenz- und eine Luftfracht-Tracking-Schleife, aber keine Schleife für die Seefracht-Statusprüfung. Die im Diensttext erwähnten 15 Minuten sind damit keine belegte Betriebsfrequenz.

Unabhängig vom globalen Lauf kann die Status-Engine nach dem Speichern einer Akte oder nach einem manuellen Statuswechsel aufgerufen werden. Dadurch können AUTO-Übergänge unmittelbar nach einer Feldänderung eintreten. Fehler dieses nachgelagerten Automationsaufrufs werden dort abgefangen; die ursprüngliche Aktenänderung kann trotzdem erfolgreich bleiben.

Der globale Lauf lädt nicht archivierte Akten in den Status Gebucht bis Angekommen, prüft je Akte genau den zum aktuellen Status passenden Regelzweig und wendet AUTO sofort an. Die gesamte Ausführung wird am Ende gemeinsam gespeichert. Ein unbehandelter Fehler kann den vollständigen Lauf zurücksetzen; ein Ergebnis pro fehlgeschlagener Akte oder ein Wiederaufnahmezustand ist nicht vorhanden.

Bei einer Änderung schreibt die Engine Statushistorie und Audit, erzeugt eine interne Statusbenachrichtigung und versucht eine Live-Aktualisierung. Der ausführende Administrator wird dabei nicht als Akteur des Laufs gespeichert; die Änderung erscheint als SYSTEM. Der Lauf erzeugt weder einen dauerhaften Laufdatensatz noch automatisch die Aufgaben und Dokumente, die der normale Statusservice bei bestimmten manuellen Übergängen anstößt.

Mandantentrennung wird durch den authentifizierten Kontext und erzwungene Datenbankrichtlinien geschützt. Eine zusätzliche Organisationseinheiten-, Aktenzuweisungs- oder Richtungsprüfung findet im globalen Lauf nicht statt. Der Lauf kann deshalb mit einer schreibenden Ocean-Freigabe der aktuellen Einheit auch Akten anderer Einheiten und der anderen Ocean-Richtung desselben Mandanten erreichen.

Für parallele Läufe sind weder globale Lease noch Akten-Zeilensperren oder ein eindeutiger Idempotenzschlüssel belegt. Zwei gleichzeitig gestartete Prüfungen können denselben Ausgangszustand bewerten. Der Status wird vor dem Anwenden zwar erneut verglichen, aber nicht atomar reserviert; doppelte Historien, Benachrichtigungen oder widersprüchliche Zähler sind deshalb nicht ausgeschlossen.

Gezielte automatisierte Tests für den manuellen Gesamtlauf, alle Trigger, DISABLED, inaktive Regeln, Mandanten-/OE-/Richtungsscope, Kreditblockade, Aufgabenwirkung, Fehlerrollback, Parallelität oder Schedulerverdrahtung wurden nicht gefunden. Die Funktion bleibt deshalb als betriebsabhängig und nicht als allgemein freigegebener Self-Service einzuordnen.

Typische Fehler und Lösungen

Meldung oder Beobachtung	Ursache	Lösung
Kein Menüpunkt oder Startknopf vorhanden	Der manuelle Prüflauf ist nicht in das Hauptfrontend eingebunden.	Nicht mit Browserwerkzeugen umgehen. Einen kontrollierten Lauf über den freigegebenen Betriebskanal beauftragen.
Nur ADMIN oder MANAGER	Die angemeldete Rolle ist für den Lauf nicht zugelassen.	ADMIN oder MANAGER im Kundenmandanten verwenden; Rolle nicht nur für diesen Lauf hochstufen.
Keine Berechtigung: EDIT in shipments	Akten-Bearbeitungsrecht fehlt.	Rollen- und Einzelrechte prüfen lassen.
Modul ist nicht gebucht, gesperrt oder nur lesbar	In der aktuellen Organisationseinheit fehlt eine schreibende Ocean-Freigabe.	Lizenzstatus und Einheit prüfen; keinen Lauf über eine fremde Einheit erzwingen.
Erwartete Akte wurde nicht geprüft	Akte ist archiviert, noch Entwurf, bereits Zugestellt oder Storniert, gehört zu einem anderen Mandanten oder war durch Datenbankregeln nicht sichtbar.	Status, Archivkennzeichen und Mandantenkontext prüfen. Entwürfe werden vom globalen Lauf ausdrücklich nicht geladen.
Unerwartete Akten anderer Einheiten wurden geändert	Der globale Lauf besitzt keinen Filter auf die aktuelle Organisationseinheit.	Weitere Läufe stoppen, alle Einheiten des Mandanten kontrollieren und den Betrieb informieren.
Vorschläge offen ist größer als die fachlich erwartete Zahl	Auch DISABLED-Treffer werden als Vorschlag gezählt; wiederholte Läufe liefern nicht bestätigte Vorschläge erneut.	Ergebnis einzeln prüfen, nicht als Arbeitsvorrat oder Abschaltnachweis verwenden.
Inaktiv gesetzte Regel wirkt weiter	Eine inaktive Konfiguration wird nicht als Sperre, sondern wie ein fehlender Eintrag behandelt; der Standardmodus greift.	Konfiguration nicht als Not-Aus verwenden; technische Korrektur und Test verlangen.
Status ist geändert, aber erwartete Aufgabe fehlt	Der globale Engine-Weg ruft die normale Aufgabengenerierung nicht auf.	Akte unter Kommunikation → Aufgaben prüfen und den vorgesehenen Aufgabenprozess kontrolliert ausführen.
Akte wurde trotz Kreditblockade automatisch gebucht	Der automatische Engine-Weg verwendet die Kreditprüfung des manuellen Buchungsschritts nicht.	Weitere Automatik stoppen, Status und Kreditentscheidung fachlich eskalieren und den Kontrollpfad technisch korrigieren lassen.
Ergebnis fehlt oder Lauf bricht vollständig ab	Ein Datenbank-, Status- oder Laufzeitfehler hat die gemeinsame Transaktion beendet.	Nicht unkontrolliert wiederholen. Zeitpunkt und Ausgangsstatus sichern, Betrieb prüfen lassen und erst danach einen einzelnen Wiederholungslauf freigeben.
Doppelte oder widersprüchliche Historieneinträge	Parallele Läufe oder konkurrierende Aktenänderungen wurden nicht durch eine belegte Sperre serialisiert.	Läufe stoppen, Historie und Audit sichern und technische Bereinigung durch den Betrieb veranlassen.
Status ändert sich nicht alle 15 Minuten	Eine periodische Statusschleife ist im Anwendungsstart nicht verdrahtet.	Keine Frequenz versprechen. Scheduler, Ownership, Monitoring und Sperrvertrag vor Aktivierung ausdrücklich festlegen.