Statusmodelle und Übergänge im Überblick

Zweck und Einsatzbereich

Diese Referenz hilft, den Status eines Objekts im jeweils richtigen Fachmodell zu lesen. NeuraPort besitzt keine belegte universelle Zustandsmaschine: Akte, Container, AWB-Nachricht, Rechnung, Zollanmeldung, Portalvorgang und Lizenz sind getrennte Objekte mit eigenen Regeln. Ein grünes Badge oder ein Endstatus in einem Modell ersetzt daher weder die Prüfung eines anderen Modells noch eine externe Bestätigung.

Nutzen Sie diese Seite zur Einordnung. Für Eingabe, Korrektur und Fehlerbehandlung ist immer die verlinkte Fachseite maßgeblich. Die Begriffe „typisch“ und „zulässig“ beziehen sich ausschließlich auf die dort belegten Bedien- oder Serverwege.

Voraussetzungen und Berechtigungen

Lesen und Ändern folgen je Fachbereich den Objekt-, Mandanten-, Organisationseinheiten-, Rollen- und Lizenzprüfungen. Ein sichtbarer Schalter ist keine Zusage, dass der Schreibaufruf zulässig ist: insbesondere bei Luftfracht, Road, Warehouse und einigen Lizenzansichten können Aktionen sichtbar sein und serverseitig scheitern.

Prüfen Sie vor einem Übergang mindestens Objektidentität, aktuelle Organisationseinheit, Fachmodul und nötiges Einzelrecht. READ_ONLY führt nur bei wirksamer Lizenzdurchsetzung im Modus enforce zur Ablehnung fachlicher Schreib- und Automationsaufrufe. Im Modus audit oder off wird eine negative Lizenzentscheidung nicht als dieselbe Zugriffsschranke durchgesetzt. Einzelheiten stehen bei Lizenzstatus und Zugriffsproblemen.

Schritt-für-Schritt-Anleitung

Identifizieren Sie zuerst das Objekt: Eine Akte, ein Container, eine Nachricht oder eine Rechnung kann neben der Sendung einen eigenen Status besitzen.
Öffnen Sie die zugehörige Fachseite und vergleichen Sie Ausgangszustand, auslösende Aktion und belegte Sperre.
Führen Sie nur einen dort sichtbaren oder ausdrücklich freigegebenen Übergang aus; technische Direktpfade sind kein Ersatz für den Bedienprozess.
Prüfen Sie nach erfolgreicher Aktion Historie, Folgeobjekte und eventuelle Aufgaben. Bei Provider-, Bank-, Behörden- oder Carrierbezug ist die interne Statusänderung nicht automatisch ein externer Nachweis.
Halten Sie bei Widersprüchen, fehlendem Rückweg oder unklarem Ergebnis an und folgen Sie der verlinkten Troubleshooting- oder Fachanweisung.

Feldreferenz

Feld	Pflicht	Bedeutung	Validierung
Objektart	Ja	Legt fest, welches Statusmodell gilt, etwa Akte, Rechnung oder Portalzugang.	Nicht aus einem gleichnamigen Status eines anderen Objekts ableiten.
Aktueller Status	Systemseitig	Gespeicherter Zustand des jeweiligen Objekts.	Historie und erneutes Laden prüfen, wenn die Oberfläche optimistisch anzeigt.
Auslöser	Je Übergang	Benutzeraktion, Fachereignis, Zeitprüfung oder Providerantwort.	Nur den belegten Auslöser verwenden; ein Zeitlauf ist nicht überall garantiert.
Zielstatus	Systemseitig oder auswählbar	Ergebnis eines zulässigen Übergangs.	Ein freier Statuswert ist keine fachliche Freigabe.
Sperre / Voraussetzung	Je Übergang	Recht, Lizenz, Pflichtdaten oder abhängiger Zustand, der vorher erfüllt sein muss.	Serverseitige Prüfung ist maßgeblich.
Nachweis	Je Fachprozess	Historie, Audit, PDF, Referenz oder externe Antwort.	Interner Status allein ersetzt keinen Provider-, Behörden- oder Zahlungsnachweis.

Status und mögliche Übergänge

1. Seefrachtakte und Aufgaben

Autoritativer Kontext: Die sichtbare Ocean-Folge lautet Entwurf → Gebucht → VGM ausstehend → VGM eingereicht → Zoll ausstehend → Zoll freigegeben → Verladen → Unterwegs → Angekommen → Zugestellt; aus jedem nicht abgeschlossenen Zustand ist Storniert möglich. Zugestellt und Storniert sind im sichtbaren Ablauf Endzustände. Der direkte Weg erlaubt nur den nächsten Schritt; Buchung kann durch eine Kreditblockade gesperrt sein. Statusvorschläge, Engine-Modi und ein periodischer Scheduler sind nicht vollständig als sichtbarer oder garantiert laufender Prozess belegt. Details: Aktenstatus und Aufgaben und zeitbasierte Statusprüfung.

2. Container, VGM und Free Time

Autoritativer Kontext: VGM ist kein Aktenstatus: pro Container wechselt es von ausstehend zu eingereicht, wenn Gewicht, Methode und Zeitstempel gespeichert sind. Sind alle Container erfasst, kann die zugehörige VGM-Aufgabe erledigt und der Aktenübergang ermöglicht werden; das ist keine Carrierbestätigung. Free Time wird unabhängig als OK, bald fällig oder überfällig aus Fristen abgeleitet; Rückgabe ist offen oder zurückgegeben. Ein sichtbarer Rücksetzweg für VGM ist nicht belegt. Details: Container, VGM und Free Time.

3. Ocean-Import und Konsolidierung

Autoritativer Kontext: Die Importakte verwendet technisch dieselbe lineare Aktenfolge wie Ocean-Export; Pre-Alert, Delivery Order, Zollfreigabe und Archivierung sind getrennte Kennzeichen und ändern sie nicht automatisch. Neue Konsolidierungen starten OPEN, akzeptieren technisch aber Freitextstatus; ein sichtbarer Wechsel fehlt. Beim Entfernen einer Akte wird die Konsolidierungs-ID entfernt, die Ladungsart bleibt jedoch LCL. Diese fehlende UI-State-Machine nicht durch Freitext oder Rückschlüsse aus der Akte ersetzen. Details: Ocean-Import und Konsolidierung.

4. Luftfracht, AWB, eAWB und FSU

Autoritativer Kontext: Luftfrachtakten folgen Entwurf → Angefragt → Gebucht → Übernommen → Im Flug → Angekommen → Verfügbar → Zugestellt → Abgeschlossen; Abweichung kann zwischen Flug, Ankunft und Storno liegen, Storniert ist ein Endzustand. Ist-Meilensteine schreiben nur zulässige Fortschritte. Separat wechseln eAWB-/Ausgangsnachrichten über VALIDATED → TRANSMITTED → ACCEPTED/REJECTED oder bei Fehler zu FAILED; eine angenommene Nachricht wird nicht erneut übertragen. FSU und Tracking dürfen den Aktenstatus nur vorwärts setzen. Providerannahme und eine Simulation sind strikt zu unterscheiden. Details: Luftfrachtakten und Nachrichten, Buchung und Tracking.

5. Road, Tour, Stopp und eCMR

Autoritativer Kontext: Ein Road-Auftrag beginnt DRAFT und wird bei Tourzuordnung PLANNED; Lieferstopp DELIVERED/COMPLETED setzt den Auftrag auf DELIVERED. Stopps folgen PLANNED → EN_ROUTE → ARRIVED → LOADED/DELIVERED/COMPLETED. eCMR ist getrennt: ohne Empfängersignaturobjekt DRAFT, sonst derzeit SIGNED; eine erlaubte Simulation kann ACCEPTED setzen. Die Signatur wird dabei nicht hinreichend verifiziert, Wiederholungen sind möglich und sichtbare Bedienwege fehlen für mehrere technische Übergänge. Als rechtssicheren Nachweis nicht verwenden. Details: Straßentransport, eCMR und Telematik.

6. Warehouse, ASN, Ausgang und Inventur

Autoritativer Kontext: ASN läuft EXPECTED → PARTIAL → RECEIVED. Ausgang läuft RELEASED → PICKED → PACKED → STAGED → HANDED_OVER, Pickaufgaben OPEN → PICKED; Inventur verwendet OPEN, COUNTED oder RECOUNT und wird erst danach POSTED. Retouren werden von RECEIVED mit RESTOCK oder SCRAP zu CLOSED. Bei Inventuren kann der angezeigte Gesamtstatus zu früh COUNTED sein; Inventur- und Retourenabschluss besitzen keine belegte Wiederholungssperre. Daher Erfolg und Bewegungen einmalig kontrollieren. Details: Lagerprozesse.

7. CRM, Lead, Verkaufschance, Angebot und Aktivität

Autoritativer Kontext: Leads können qualifiziert und dann zu Kunden konvertiert werden, ihr sichtbarer Textstatus ist jedoch frei setzbar und erzwingt keine Reihenfolge. Verkaufschancen haben die Phasen Erstkontakt → Qualifiziert → Angebot → Verhandlung → Gewonnen, während Drag-and-drop auch Sprünge und Rückschritte zulässt. Angebote wechseln sichtbar Entwurf → Versendet; Angenommen, Abgelehnt und Abgelaufen sind vorgesehen, aber nicht sichtbar ausführbar. Nur ein angenommenes Angebot kann zu Konvertiert und einer Entwurfsakte führen. CRM-Aufgaben/Wiedervorlagen wechseln nach Erledigung aus offen in erledigt, ohne sichtbaren Rückweg. Details: Leads und Kontakte, Ratenanfragen und Angebote und CRM-Aktivitäten.

8. Aktendokument und Version

Autoritativer Kontext: Upload oder Erzeugung erstellt Version 1 als Aktuell; eine neue Fassung wird aktuell, Wiederherstellen markiert eine vorhandene ältere Version erneut aktuell. Dokumente können gesperrt und über einen fachlich freigegebenen Prozess wieder entsperrt werden. Gesperrte Dokumente dürfen weder geändert noch gelöscht werden; die dokumentierten Sperrgrenzen und Abnahmehinweise stehen unter Aktendokumente und Versionen und operative Dokumente.

9. Rechnungen, Zahlungen und Exportbatches

Autoritativer Kontext: Rechnungen gehen DRAFT → FINAL beziehungsweise Korrekturentwurf zu CORRECTION; Storno aus Entwurf erzeugt CANCELED, aus FINAL einen separaten finalen Korrekturbeleg. Bezahlt-Markierung verändert den Lebenszyklus nicht und hat keinen Rückweg. Zahlungen werden intern Offen, Zugeordnet/Manuell oder Teilbetrag und können wieder aufgehoben werden; das bewegt kein Geld. Exportbatches beginnen PREPARED, doch der Server akzeptiert freie Großbuchstaben und Rücksprünge; EXPORTED setzt Zeitpunkte, die beim Rücksprung bleiben. Daher weder Rechnungsfinalität noch Buchhaltungsabgabe aus einem bloßen Batchwert ableiten. Details: Rechnungslebenszyklus, Zahlungen und Buchhaltungsexporte.

10. Zoll und Compliance

Autoritativer Kontext: Ausfuhr folgt sichtbar Entwurf → Eingereicht → Angenommen → Freigegeben; Abgelehnt und Storniert haben keinen belegten UI-Übergang. Der Server erzwingt die Folge nicht durchgehend, Freigabe ist kein Behördennachweis. Einfuhr beginnt Entwurf, wird test- oder livegemeldet Angemeldet, kann In Verwahrung sein und wird Freigegeben; bei Gatewayfehlern kann Abgelehnt entstehen, ein sichtbarer Weg zu Erledigt fehlt. Exportkontrolle liefert Manuelle Prüfung, Genehmigungspflichtig oder Gesperrt; ein neu erreichbares Freigegeben ist nicht belegt. Jede Prüfung ist ein separater Historieneintrag. Details: Ausfuhranmeldungen, Einfuhranmeldungen und Exportkontrollprüfungen.

11. Portal und Tracking

Autoritativer Kontext: Portal-Buchungsanfragen laufen administrativ NEW/ROUTED → IN_REVIEW → ACCEPTED/DECLINED; abgeschlossene Anfragen werden im geprüften Weg nicht weiter geändert. Eine Annahme erzeugt nicht automatisch Akte oder Carrierbuchung. Portal-VGM wechselt von offen zu erfasst und besitzt keine sichtbare Korrektur. Trackingtoken können aktiv oder deaktiviert sein; ein abgelaufener oder unbekannter Token ist kein Trackingstatus der Akte. Öffentlicher Komponentenstatus wird aus operational/degraded/outage/maintenance/unknown abgeleitet, kann aber ohne nachweislich aktuelle Liveüberwachung irreführend Operational zeigen. Details: Portal-Anfragen und Dokumente, Buchungsanfragen administrieren und Service-Status.

12. Lizenz und Verfügbarkeit

Autoritativer Kontext: Vertragsstatus ACTIVE, PAST_DUE, CANCELED und EXPIRED sowie Modulstatus ACTIVE, TRIAL, READ_ONLY und SUSPENDED bilden ein eigenes Zugangsmuster. Ablauf eines Trial führt zu SUSPENDED; READ_ONLY, PAST_DUE und CANCELED lassen regulär nur Lesen/erlaubten Export zu, EXPIRED und SUSPENDED sperren. OE-Aktivierung ist zusätzlich aktiv/inaktiv und ersetzt weder Benutzerzuweisung noch Rolle. In audit/off kann eine negative Lizenzentscheidung weiterlaufen; nur enforce ist die belegte Blockade. Details: Mandantenlizenzen und Plattformlizenzen.

Was im Hintergrund passiert

Statushistorien, Auditspuren, Folgeaufgaben, Providerantworten und Hintergrundprüfungen sind fachlich verschieden. Eine erfolgreiche interne Mutation kann daher eine Aufgabe abschließen, eine Historie schreiben oder einen Export vorbereiten, ohne eine externe Übermittlung, Zustellung, Zahlung, Zollannahme oder rechtssichere Signatur zu belegen.

Mehrere Modelle sind bewusst als unvollständig dokumentiert: Ocean-Engine-Vorschläge sind nicht sichtbar vollständig bedienbar, Konsolidierungs- und Exportbatchwerte haben keine wirksam erzwungene State-Machine, und technische Road-/Warehouse-Wege sind nicht vollständig im UI vertreten. Diese Referenz löst solche Widersprüche nicht auf; sie benennt die Grenzen für eine sichere operative Entscheidung.

Typische Fehler und Lösungen

Beobachtung	Einordnung	Nächster Schritt
Aktion ist sichtbar, wird aber abgewiesen	UI und effektive Rechte/Lizenz sind nicht deckungsgleich.	Objekt-OE, Einzelrecht und Lizenzmodus prüfen; nicht per Direktaufruf umgehen.
Status scheint nach dem Speichern zurückzuspringen	Optimistische Anzeige, Paralleländerung oder unzulässiger Übergang.	Neu laden und Historie prüfen; nur den belegten Folgeschritt wiederholen.
Interner Status wird als externe Bestätigung gelesen	Provider-, Bank-, Carrier- oder Behördennachweis fehlt.	Referenz, Quittung oder freigegebenen Außenprozess prüfen.
Kein Rückweg oder freie Statuswerte vorhanden	Das Modell ist unvollständig oder serverseitig nicht erzwungen.	Fachseite und offene Produktfragen heranziehen; keine Korrektur erfinden.
Zeit- oder Automatikübergang ist ausgeblieben	Scheduler, Modus oder Trigger ist nicht garantiert.	Fachliche Voraussetzungen prüfen und den vorgesehenen Betriebsprozess einschalten.