Buchungsanfragen im Kundenportal administrieren

Zweck und Einsatzbereich

Unter Kunden-Buchungsanfragen bearbeiten Sie Anfragen, die ein eingeladener Kunde über das Kundenportal eingereicht hat. Sie können eine noch offene Anfrage auf IN_REVIEW, ACCEPTED oder DECLINED setzen und dabei eine Rückmeldung hinterlegen, die der Kunde im Portal sieht.

Die sichtbare Karte enthält nur Route, Status, Kundenreferenz, Warenbeschreibung und eine bisherige Rückmeldung. Kundenname, Anfrageart, Containeranzahl, Equipment, Bereitstellungsdatum, Hinweise, Eingangsdaten, automatische Zuweisung und Routingbegründung werden in dieser Oberfläche nicht angezeigt. Treffen Sie keine fachliche Entscheidung, wenn dafür diese fehlenden Angaben benötigt werden.

Annehmen ist keine Carrier- oder Reedereibuchung und erzeugt in diesem Bedienweg keine operative Akte. Es erfolgt auch keine automatische Providerübermittlung oder E-Mail-Bestätigung. Der Kunde sieht Status und Rückmeldung erst, wenn seine Portalliste neu geladen wird.

Voraussetzungen und Berechtigungen

Sie sind als ADMIN oder MANAGER eines Mandanten angemeldet. Ein Plattformadministrator ist für diesen Weg ausdrücklich nicht zugelassen.
Das Modul Customer Portal ist für den Mandanten und Ihre aktuelle Organisationseinheit freigeschaltet. Für die Liste benötigen Sie Lesezugriff, für Statusänderungen Schreibzugriff. Im Modus Nur lesen bleibt die Liste grundsätzlich lesbar, Änderungen werden serverseitig abgewiesen.
Sie sind Ihrer aktuellen Organisationseinheit zugeordnet und besitzen dort das erforderliche Kundenrecht. Die Standardrollen ADMIN und MANAGER erfüllen diese Rollenprüfung.
Die Anfrage gehört zu Ihrem Mandanten. Buchungsanfragen speichern derzeit keine eigene Organisationseinheit; die interne Liste umfasst deshalb alle Anfragen des Mandanten, auch wenn Kunden einer anderen Einheit zugeordnet sind. Ein Wechsel der aktuellen Einheit begrenzt die Liste nicht fachlich, solange der Modulzugriff dort erlaubt ist.
Der allgemeine Schalter Portal aktiviert ist im geprüften Stand keine verlässliche Sperre für neue Kundenanfragen. Für einen Portalstopp müssen Portalzugänge oder Modulzugriffe wirksam gesperrt und anschließend getestet werden.

Öffnen Sie den Arbeitsbereich Customer Portal und dort Kundenportal verwalten. Alternativ erreichen ADMIN und MANAGER die kompakte Liste unter Einstellungen → Portal-Buchungen. Der Einstellungsweg kann auch dann sichtbar sein, wenn der Modulzugriff später abgewiesen wird.

Schritt-für-Schritt-Anleitung

Wechseln Sie über Arbeitsbereich zu Customer Portal und öffnen Sie Kundenportal verwalten. Scrollen Sie zu Kunden-Buchungsanfragen. Alternativ wählen Sie Einstellungen → Portal-Buchungen.
Prüfen Sie, ob Karten geladen werden. Keine offenen oder vergangenen Anfragen. kann sowohl einen echten Leerstand als auch einen Lade- oder Zugriffsfehler bedeuten, weil die Komponente keinen eigenen Lade- und Fehlerzustand zeigt.
Lesen Sie Route, Rohstatus, Kundenreferenz, Warenbeschreibung und Bisherige Rückmeldung. Die Statuswerte werden in der Karte nicht ins Deutsche übersetzt.
Prüfen Sie vor einer Entscheidung die vollständige Kundenanforderung über den dafür freigegebenen betrieblichen Weg. Containeranzahl, Equipment, Bereitstellungsdatum, freie Hinweise, Kundenidentität und automatische Zuweisung sind in der Administrationskarte nicht sichtbar.
Wählen Sie für eine fachlich noch offene Prüfung In Prüfung. Wählen Sie Annehmen nur, wenn die Spedition die Anfrage weiterbearbeiten will, oder Ablehnen, wenn sie nicht übernommen wird. Es gibt keinen zusätzlichen Bestätigungsdialog für die Statusentscheidung.
Nach jeder der drei Aktionen öffnet sich Rückmeldung an den Kunden (optional):. Geben Sie einen klaren, nicht vertraulichen Text ein. Die bisherige Rückmeldung ist nicht vorausgefüllt; übernehmen Sie sie bewusst, wenn sie erhalten bleiben soll.
Verlassen Sie sich nicht auf Abbrechen im Rückmeldedialog: Im geprüften Stand wird die Statusaktion trotzdem ausgelöst. Auch ein leerer Text kann die bisherige Rückmeldung entfernen. Wählen Sie daher keine Aktionsschaltfläche probeweise und prüfen Sie nach einem Fehlklick sofort den tatsächlichen Status.
Warten Sie auf Kundenanfrage aktualisiert und kontrollieren Sie die neu geladene Karte. Informieren Sie die zuständige operative Stelle separat; eine Statusänderung legt keine Akte an und sendet keine Carrierbuchung. Der Kunde muss seine Portalseite neu laden, um Status und Rückmeldung zu sehen.

Feldreferenz

Feld	Pflicht	Bedeutung	Validierung
Route	Systemseitig	Eingereichter Start- und Zielort in der Form Von → Nach	Beide Angaben wurden beim Eingang mit mindestens 2 und höchstens 255 Zeichen geprüft; die Administrationsansicht kann sie nicht ändern.
Status	Systemseitig	Technischer Bearbeitungsstand der Anfrage	Wird als Rohwert wie NEW, ROUTED, IN_REVIEW, ACCEPTED, DECLINED oder CONVERTED angezeigt.
Kundenreferenz	Nein	Vom Kunden angegebene Referenz	Höchstens 100 Zeichen; fehlt sie, erscheint Keine Referenz.
Warenbeschreibung	Nein	Freier Kurztext zur angefragten Ware	Höchstens 2.000 Zeichen; wird neben der Referenz angezeigt.
Bisherige Rückmeldung	Nein	Zuletzt gespeicherter, im Kundenportal sichtbarer Text	Erscheint nur, wenn ein nicht leerer Text gespeichert ist. Es gibt keine sichtbare Versionshistorie.
Rückmeldung an den Kunden (optional)	Nein	Neuer Text, der zusammen mit der Statusentscheidung gespeichert wird	Serverseitig höchstens 4.000 Zeichen. Der Dialog besitzt keinen Zeichenzähler und übernimmt den bisherigen Text nicht. Leer oder abgebrochen kann den bisherigen Text entfernen.
In Prüfung	Nein	Setzt eine offene Anfrage auf IN_REVIEW	Öffnet denselben Rückmeldedialog wie die Abschlussaktionen und ist auch aus IN_REVIEW erneut möglich.
Annehmen	Nein	Setzt eine offene Anfrage auf ACCEPTED	Danach sind in dieser Oberfläche keine weiteren Aktionen möglich. Keine Akten- oder Providerwirkung.
Ablehnen	Nein	Setzt eine offene Anfrage auf DECLINED	Danach sind in dieser Oberfläche keine weiteren Aktionen möglich. Es wird keine gesonderte Benachrichtigung versendet.

Folgende gespeicherte Angaben sind kein Feld dieser sichtbaren Administrationskarte: Anfrageart, Containeranzahl, Equipment, Bereitstellungsdatum, Kundenhinweise, Kunde, Portalnutzer, Erstell- und Bearbeitungszeitpunkt, Bearbeiter, Zuweisung und Routingbegründung. Eine Bearbeiterzuweisung ist technisch vorgesehen, besitzt hier aber keinen sichtbaren Auswahl- oder Änderungsweg.

Status und mögliche Übergänge

Ausgangsstatus	Aktion oder Ereignis	Ergebnis
Neue Kundenanfrage ohne automatische Zuweisung	Portal nimmt Anfrage an	NEW
Neue Kundenanfrage mit ermittelter Zuweisung	Automatisches Routing	ROUTED; Zuweisung und Begründung bleiben in der Karte unsichtbar.
NEW oder ROUTED	In Prüfung	IN_REVIEW; Bearbeiter und Bearbeitungszeitpunkt werden technisch gesetzt.
NEW, ROUTED oder IN_REVIEW	Annehmen	ACCEPTED; Statusentscheidung ist im Adminweg abgeschlossen.
NEW, ROUTED oder IN_REVIEW	Ablehnen	DECLINED; Statusentscheidung ist im Adminweg abgeschlossen.
IN_REVIEW	In Prüfung erneut	Status bleibt IN_REVIEW; Rückmeldung und Bearbeitungsdaten werden erneut ersetzt.
ACCEPTED, DECLINED oder CONVERTED	Erneute Statusänderung	Wird abgewiesen; die Aktionsschaltflächen sind in der Karte bereits ausgeblendet.
Jeder Status außer CONVERTED	Gesonderte technische Übernahme in einen Straßenauftrag	Ein Straßenauftrag entsteht und die Anfrage wird CONVERTED; dafür gibt es in dieser Administrationskarte keine sichtbare Aktion. Auch ACCEPTED und DECLINED werden dort derzeit nicht gesperrt.

Was im Hintergrund passiert

Eine Portal-Anfrage ist an Mandant, Kunde und Portalnutzer gebunden. Die Kundenoberfläche sendet derzeit keine auswählbare Anfrageart; dadurch wird die Anfrage als QUOTE behandelt. Das Routing sucht deshalb zunächst einen festen Vertriebsbetreuer des Kunden und danach die konfigurierte Vertriebsleitung. Die alternative automatische Operations-Verteilung ist über das sichtbare Kundenformular nicht erreichbar.

Findet das Routing einen Bearbeiter, wird ROUTED gespeichert, andernfalls NEW. Die interne Karte zeigt weder den Bearbeiter noch die Routingbegründung oder einen Qualitätsscore. Obwohl der technische Aktualisierungsweg eine aktive Person desselben Mandanten als Bearbeiter akzeptieren kann, sendet die aktuelle Oberfläche keine Bearbeiterauswahl mit.

Die interne Liste filtert streng nach Mandant, aber nicht nach Kunde oder Organisationseinheit. Die Datenbankrichtlinie ergänzt die Mandantengrenze. Die Modulprüfung verwendet dagegen Ihre aktuelle Organisationseinheit. Dadurch kann ein in einer Einheit freigeschalteter ADMIN oder MANAGER Buchungsanfragen anderer Einheiten desselben Mandanten sehen und bearbeiten.

Bei jeder Statusänderung ersetzt NeuraPort die vorhandene Rückmeldung und speichert die handelnde Person sowie den Bearbeitungszeitpunkt. Eine sichtbare Status- oder Rückmeldungshistorie gibt es nicht. Der Änderungsweg verwendet weder eine Versionsnummer noch eine sichtbare Sperre; nahezu gleichzeitige Entscheidungen können sich daher überschreiben.

ACCEPTED und DECLINED sind nur für diesen Bearbeitungsweg Endzustände. Die Änderung erzeugt keine Sendungsakte, Buchungsnummer, Provideranfrage oder Kunden-E-Mail. Ein gesonderter technischer Weg kann eine Anfrage in einen Straßenauftrag übernehmen und auf CONVERTED setzen; er besitzt keine sichtbare Aktion in dieser Karte und sperrt derzeit auch angenommene oder abgelehnte Anfragen nicht. Das Portal liest den jeweils aktuellen Status und dieselbe Rückmeldung beim nächsten Laden seiner Anfragenliste.

Für das Auflisten, Aktualisieren, Routing, den Mandanten- und Organisationseinheitenscope, parallele Entscheidungen sowie die interne und die Kundenoberfläche wurden im geprüften Bestand keine gezielten automatisierten Tests gefunden.

Typische Fehler und Lösungen

Meldung oder Beobachtung	Ursache	Lösung
Keine offenen oder vergangenen Anfragen. trotz erwarteter Anfrage	Liste ist wirklich leer oder Laden, Sitzung, Lizenz beziehungsweise Recht ist fehlgeschlagen.	Nicht sofort als Leerstand werten. Seite kontrolliert neu laden, aktuelle Einheit und Portalmodul prüfen; bei Fortbestand Betrieb mit Zeitpunkt informieren.
Kundenanfrage zeigt nur Route und wenige Angaben	Die Administrationskarte blendet mehrere gespeicherte Anfragedetails aus.	Keine Entscheidung auf unvollständiger Grundlage treffen; fehlende Angaben über den freigegebenen betrieblichen Weg verifizieren.
Status steht als NEW, ROUTED oder IN_REVIEW da	Die Oberfläche zeigt technische Rohwerte ohne Übersetzung.	NEW als neu, ROUTED als automatisch zugewiesen und IN_REVIEW als in Prüfung behandeln; keine externe Bestätigung daraus ableiten.
Anfrage konnte nicht aktualisiert werden	Recht, Schreiblizenz, Sitzung, Mandantenzuordnung, Status oder Eingabe wurde abgewiesen.	Neu laden und tatsächlichen Status prüfen. Bei Nur lesen keine wiederholten Schreibversuche; Modulstatus administrativ klären.
Abgeschlossene Buchungsanfrage kann nicht mehr geändert werden	Anfrage steht bereits auf ACCEPTED, DECLINED oder CONVERTED.	Keine technische Direktänderung versuchen. Korrektur nach betrieblichem Verfahren dokumentieren und an den verantwortlichen Betrieb geben.
Buchungsanfrage nicht gefunden	Anfrage gehört nicht zum eigenen Mandanten oder ist nicht mehr erreichbar.	Kennung nicht verändern oder erraten; Mandant und Sitzung prüfen und den Vorfall melden.
Keine Organisation zugeordnet	Mitarbeiterkonto besitzt keinen Mandantenkontext.	Mit dem korrekten internen Konto anmelden; keine Plattformrolle als Ersatz verwenden.
Nur Organisations-Admins oder Manager erlaubt	Rolle ist weder ADMIN noch MANAGER, oder das Konto ist Plattformadministrator.	Zuständige Person mit zulässiger Mandantenrolle hinzuziehen.
Rückmeldedialog mit Abbrechen geschlossen, Status ändert sich trotzdem	Abbrechen stoppt die Mutation im aktuellen Stand nicht.	Karte sofort neu laden, Status und Rückmeldung prüfen und eine falsche offene Entscheidung kontrolliert korrigieren. Bei einem Endstatus Betrieb einschalten.
Bisherige Rückmeldung ist nach Statuswechsel verschwunden	Dialog war leer oder wurde abgebrochen; der alte Text wird nicht vorausgefüllt und kann ersetzt werden.	Vor einer offenen Statusänderung vorhandenen Text bewusst übernehmen. Bei abgeschlossenem Status fehlende Rückmeldung außerhalb des UI-Wegs klären.
Zwei Bearbeiter sehen unterschiedliche Entscheidungen	Nahezu gleichzeitige Änderungen besitzen keine Versionsprüfung oder Sperre.	Nicht parallel bearbeiten, vor dem Klick neu laden und Ergebnis unmittelbar kontrollieren; Konflikt dokumentieren.
Kunde sieht neuen Status nicht	Portalliste wurde noch nicht neu geladen; es gibt keine Push- oder E-Mail-Benachrichtigung aus diesem Weg.	Kunden um kontrolliertes Neuladen bitten und Rückmeldung über den vereinbarten Kommunikationsweg bestätigen.
ACCEPTED, aber keine Buchungsnummer oder Akte	Annahme ist nur der Status der Portal-Anfrage.	Operative Akte und externe Buchung getrennt nach dem freigegebenen Prozess anlegen und bestätigen.
Eine angenommene oder abgelehnte Anfrage steht später auf CONVERTED	Der gesonderte technische Straßenauftrag-Weg sperrt diese beiden Admin-Endstatus derzeit nicht.	Zugehörigen Straßenauftrag und Entscheidung fachlich prüfen, keine zweite Übernahme auslösen und den Konflikt an den Betrieb melden.
Im Modus Nur lesen bleiben Aktionsschaltflächen sichtbar	Oberfläche deaktiviert die drei Schaltflächen nicht anhand des Modulstatus.	Nicht klicken; Modulstatus klären oder in eine schreibberechtigte Einheit wechseln. Serverseitige Abweisung nicht umgehen.