Carrier-, Hafen- und Zollmeldungen mit Providern übermitteln

Zweck und Einsatzbereich

NeuraPort besitzt technische Übermittlungspfade für folgende ausgehende Nachrichten einer Seefrachtakte:

Buchungsanfrage und Shipping Instruction über die mandantenbezogene INTTRA-Konfiguration,
VGM für genau einen ausgewählten Container über INTTRA,
Hafenmeldung anhand des UN/LOCODE des Ladehafens,
Ausfuhranmeldung über ATLAS anhand einer bereits angelegten Zollanmeldung.

Aktueller Bedienstand: Der dafür vorbereitete Bereich mit den Aktionen Buchung senden, Shipping Instruction einreichen, VGM übermitteln, Ausfuhrmeldung senden, Ausfuhranmeldung an ATLAS und Nachrichtenprotokoll ist im aktiven Hauptfrontend nicht in den Aktenarbeitsplatz eingebunden. Für Seefracht-Sachbearbeiter gibt es daher derzeit keinen belegten durchgängigen Bedienweg, um diese fünf generischen Provideraktionen aus der Hauptoberfläche auszulösen oder ihr gemeinsames Protokoll zu öffnen. Verwenden Sie keine direkten technischen Aufrufe oder erratenen Kennungen als Ersatz.

Die sichtbare Hafenanmeldung unter Zollanmeldung und die eigenständigen Ausfuhrzollprozesse sind davon getrennte Fachabläufe. Nutzen Sie für einen freigegebenen Hafen- oder Zollprozess ausschließlich diese belegten Oberflächen und die dazugehörigen Anleitungen. Diese Seite beschreibt den vorbereiteten Providerpfad, seine Daten- und Statusgrenzen sowie die Bedingungen für eine spätere kontrollierte Freischaltung.

Eine technisch erfolgreiche Übertragung ist keine fachliche Annahme. Insbesondere bedeutet SENT nur, dass der konfigurierte Anschluss eine HTTP-Antwort ohne Fehlerstatus geliefert hat; eine Carrierbuchung, Hafenfreigabe, VGM-Bestätigung oder Zollannahme ist damit nicht automatisch nachgewiesen.

$TODO: Screenshot – Geplanter Schnittstellenbereich einer vollständig fiktiven Seefrachtakte mit Booking, SI, VGM, Hafen, Zoll und deutlich sichtbarem Simulationshinweis; Aufnahme erst nach belegter Einbindung in das Hauptfrontend$

Voraussetzungen und Berechtigungen

Vor jeder Übermittlung muss die zuständige Schnittstellenadministration den richtigen Provider mandantenbezogen konfigurieren, Verbindung und Nachrichtenspezifikation im vorgesehenen Testsystem abnehmen und den Betriebsmodus eindeutig festlegen. Ein bloß erfolgreicher Verbindungstest bestätigt weder das fachliche Mapping noch die Verarbeitung einer Meldung.

Der technische Übermittlungspfad verlangt Akten bearbeiten und Zugriff auf die Seefrachtakte. Zusätzlich genügt dem gemeinsamen Schnittstellenbereich derzeit eine von vier alternativen Modullizenzen: Ocean Export, Ocean Import, Compliance oder Finance. Dadurch kann eine technisch berechtigte Person den Pfad grundsätzlich auch mit einer fachlich unpassenden Lizenz erreichen. Bis zur Korrektur dürfen Provideraktionen deshalb nur Rollen erhalten, die für den konkreten Prozess, Provider und die externe Wirkung ausdrücklich freigegeben sind.

Aufgabe	Erforderlicher Zugriff
Booking, Shipping Instruction, VGM oder Hafenmeldung technisch auslösen	Akten bearbeiten, Zugriff auf die Akte und mindestens eine der genannten Modullizenzen; aktuell kein eingebundener Hauptfrontend-Bedienweg
Ausfuhranmeldung über den generischen Providerpfad auslösen	Technisch ebenfalls nur Akten bearbeiten und eine alternative Modullizenz; fachlich sind zusätzlich Zoll-Bearbeitungsrecht und eine freigegebene Ausfuhranmeldung erforderlich
Aktenbezogenes Nachrichtenprotokoll lesen	Zugriff auf die Akte; der technische Lesepfad besitzt kein zusätzliches Einzelrecht für Schnittstellenprotokolle
Provider und Live-/Simulationsmodus verwalten	Organisationsadministration beziehungsweise ausdrücklich freigegebene Schnittstellenadministration

Mandant und Organisationseinheit werden vor der aktenbezogenen Übermittlung serverseitig geprüft. ADMIN und MANAGER dürfen alle Einheiten ihres Mandanten erreichen; andere Benutzer nur die aktuelle und zusätzlich zugewiesene Einheit. Ein fremder Aktenbezug wird wie eine nicht gefundene Akte behandelt. Das Nachrichtenprotokoll ist zusätzlich auf Datenbankebene nach Mandant getrennt; der Organisationseinheitenzugriff wird über die zugehörige Akte durchgesetzt.

Plattformadministratoren ohne Mandantenkontext dürfen das gemeinsame organisationsweite Nachrichtenprotokoll nicht lesen. Sie sollen keine Providerübermittlung im Namen eines Mandanten ausführen.

Schritt-für-Schritt-Anleitung

Providerbetrieb vorbereiten

Lassen Sie je Zielprozess schriftlich festlegen, welcher Provider, welche Umgebung und welches Nachrichtenprofil verwendet werden. Für Booking, Shipping Instruction und VGM ist im geprüften Pfad ausschließlich INTTRA verdrahtet; ein an der Akte gespeicherter Carrier wählt dort keinen direkten Carrieranschluss.
Lassen Sie die mandantenbezogene Konfiguration, Zugangsdaten, Zieladresse und den passenden Nachrichtenpfad im Provider-Testsystem prüfen. Zugangsdaten gehören ausschließlich in die geschützte Schnittstellenkonfiguration.
Prüfen Sie den Betriebsmodus. Simulation erzeugt Testantworten ohne externe Wirkung. Live darf erst nach fachlicher Mapping-, Negativ- und Quittungsabnahme aktiviert werden.
Lassen Sie für Hafenmeldungen den Ladehafen exakt prüfen. Der vorbereitete Pfad ordnet Hamburg DAKOSY, Bremerhaven DBH, Rotterdam und Amsterdam Portbase sowie Antwerpen ANTWERP/NxtPort zu. Jeder andere oder fehlende UN/LOCODE fällt derzeit unsicher auf DAKOSY zurück und darf nicht gesendet werden.
Legen Sie fest, wie Providerreferenz, fachliche Annahme, Ablehnung und Korrektur in NeuraPort und beim Provider abgeglichen werden. Ein automatischer Eingang von Quittungen ist für diesen Pfad nicht belegt.

Akte und Meldedaten fachlich prüfen

Öffnen Sie die richtige Organisationseinheit und die richtige gespeicherte Seefrachtakte.
Prüfen Sie vor einer Buchungsanfrage mindestens Aktennummer, Carrier/SCAC, Schiff, Reise, Lade- und Löschhafen, ETD, Ware, Gewicht, Gefahrgutangabe, Incoterm und benötigte Containerarten. Der vorbereitete Datensatz trägt unabhängig vom Mandanten NeuraPort GmbH als Bucher ein; damit darf er ohne korrigiertes und abgenommenes Beteiligtenmapping nicht live verwendet werden.
Prüfen Sie vor einer Shipping Instruction zusätzlich Bookingnummer, Shipper, Consignee, Notify Party, Container- und Siegelnummern sowie Containergewichte. Der vorbereitete Datensatz setzt Dokumenttyp, drei Originale und PREPAID fest; diese Werte sind nicht aus einem sichtbaren Freigabedialog ableitbar und müssen vor Livebetrieb mit dem Vertrag abgeglichen werden.
Prüfen Sie vor einer VGM-Meldung Bookingnummer, Containernummer, positives VGM-Gewicht, Einheit, Wiegeverfahren und verantwortliche Partei. Der generische Pfad sendet nur einen Container je Aufruf, auch wenn der vorbereitete Knopf „für alle Container“ beschreibt. Als verantwortliche Partei ist unabhängig vom Mandanten fest NeuraPort GmbH eingetragen; ohne korrigiertes und fachlich bestätigtes Mapping darf diese Meldung nicht live gesendet werden.
Prüfen Sie vor einer Hafenmeldung Ladehafen, MRN-Modus, MRN, Exporteur/EORI, Empfänger, Ware, Gewicht, Schiff/Reise und alle betroffenen Container. Verwenden Sie für den aktuell sichtbaren Fachablauf die getrennte Hafenanmeldung.
Prüfen Sie vor einer Zollmeldung die tatsächlich zur Akte gehörende Ausfuhranmeldung, alle Beteiligten, EORI, Bestimmungsland, Ausgangszollstelle, Warenpositionen und HS-/TARIC-Codes. Verwenden Sie den sichtbaren Ausfuhrzollprozess; der vorbereitete generische Dialog übergibt derzeit keine echte Anmeldungsreferenz und ist nicht verwendbar.

Übermittlung, Vorschau und Ergebnis kontrollieren

Im aktuellen Hauptfrontend ist dieser Ablauf nicht ausführbar. Nach einer künftigen belegten Einbindung muss er mindestens so abgenommen werden:

Öffnen Sie den freigegebenen Schnittstellenbereich der Akte und kontrollieren Sie, ob Provider und Live oder Simulation unübersehbar angezeigt werden. Der vorhandene Komponentenentwurf zeigt den Betriebsmodus vor dem Klick nicht dauerhaft an.
Öffnen Sie die Datenvorschau. Im Entwurf besitzen nur Booking, Shipping Instruction und Zoll eine Bestätigungsmaske; fehlende Werte werden dort markiert, blockieren den Versand aber nicht. VGM und Hafenmeldung besitzen keine solche Vorschau oder Verantwortungsbestätigung.
Bestätigen Sie eine Liveübermittlung erst nach Vier-Augen-Prüfung der tatsächlich versendeten Daten. Fehlt eine vollständige Vorschau, brechen Sie ab.
Klicken Sie nach dem ersten Aufruf nicht erneut, solange das Ergebnis ungeklärt ist. Der 24-Stunden-Dublettenschutz gilt nur für erfolgreich protokolliertes Booking und Shipping Instruction und kann bewusst übergangen werden. VGM, Hafen und Zoll besitzen keinen entsprechenden Schutz.
Bewerten Sie das Ergebnis anhand von Betriebsmodus, Meldungstyp, Provider, Status, Zeitpunkt und externer Referenz. Die vorbereitete Protokollansicht zeigt jedoch nur die zehn neuesten Einträge und blendet externe Referenz, Antwortdetails und Fehlertext aus; eine fachliche Klärung erfordert daher die Schnittstellenadministration und den Providerbeleg.
Verwenden Sie SENT oder eine externe Referenz nicht als Annahmebestätigung. Gleichen Sie die Meldung im jeweiligen Providerportal oder über den vereinbarten Quittungskanal ab.

$TODO: Screenshot – Nachrichtenprotokoll einer vollständig fiktiven Seefrachtakte mit getrennten Zuständen SIMULATED, SENT und ERROR sowie anonymisierten Referenzen; Aufnahme erst nach belegter Einbindung und ohne echte Providerdaten$

Feldreferenz

Feld	Pflicht	Bedeutung	Validierung
Betriebsmodus	Ja	Simulation oder Live der mandantenbezogenen Providerkonfiguration	Vor jeder Aktion außerhalb der Akte prüfen; die vorbereitete Aktionsansicht zeigt ihn derzeit nicht dauerhaft an.
Provider	Ja	Zielanschluss der Meldung	Booking, SI und VGM verwenden INTTRA; Zoll verwendet ATLAS; Hafen wird aus dem exakten Ladehafen-UN/LOCODE gewählt.
Aktennummer	Ja	Interne Referenz im ausgehenden Datensatz	Muss zur geöffneten, berechtigten Akte gehören; keine fachliche Provider-Eindeutigkeit garantiert.
Carrier / SCAC	Für Carrierdaten fachlich ja	Reedereikennung in Bookingdaten	Wird in den INTTRA-Datensatz übernommen, wählt aber in diesem Pfad keinen direkten Carrierconnector.
Ladehafen / UN/LOCODE	Für Carrier und Hafen fachlich ja	Ladeort und Auswahl des Hafenproviders	Nur exakt abgenommene Codes verwenden; unbekannte oder fehlende Codes dürfen wegen des DAKOSY-Fallbacks nicht gesendet werden.
Löschhafen / UN/LOCODE	Für Booking fachlich ja	Zielhafen der Seereise	Der Entwurf markiert Fehlen nur als Warnung; Server blockiert nicht zuverlässig.
Schiff / Reise / ETD	Prozessabhängig	Transportdaten für Booking und Hafen	Beim vorbereiteten Bookingknopf blockiert nur ein fehlender Schiffsname; übrige Vollständigkeit fachlich prüfen.
Bookingnummer	Für SI und VGM fachlich ja	Carrierbezug der Folgemeldung	Der SI-Knopf wäre ohne Bookingnummer gesperrt; VGM erzwingt sie serverseitig nicht.
Bucher / verantwortliche VGM-Partei	Für Booking beziehungsweise VGM fachlich ja	Rechtlich oder vertraglich verantwortliche Partei der Meldung	Im vorbereiteten INTTRA-Datensatz fest NeuraPort GmbH statt mandantenbezogener Stammdaten; vor Livebetrieb zwingend korrigieren.
Shipper / Consignee / Notify Party	Prozessabhängig	Beteiligte im Carrier-, Hafen- oder Zolldatensatz	Keine vollständige serverseitige Pflichtfeldprüfung; Schreibweise, Rolle und Datenschutz prüfen.
Ware / HS-Code / Bruttogewicht	Prozessabhängig	Waren- und Gewichtsdaten der Meldung	Fehlende oder Nullwerte werden nicht in allen Pfaden blockiert; Zolltarifierung fachlich bestätigen.
Container / Siegel	Für SI, VGM und Hafen prozessabhängig	Equipment- und Identifikationsdaten	VGM bindet den Container an die Akte, prüft aber Nummer und Siegel nicht vollständig.
VGM-Gewicht / Methode	Für VGM ja	Verifizierte Bruttomasse und SM1 oder SM2	Der generische Providerpfad erzwingt weder ein positives Gewicht noch die zulässige Methode zuverlässig.
Zollanmeldung	Für ATLAS ja	Bereits angelegter Ausfuhrvorgang derselben Akte	Muss technisch zur Akte gehören. Der vorbereitete Hauptfrontend-Entwurf liefert derzeit keine echte Anmeldungsreferenz.
Ausgangszollstelle	Für ATLAS fachlich ja	Zuständige Ausgangszollstelle im Zollnachrichtensatz	Fehlt sie, kann ein Platzhalter eingesetzt werden; damit nicht live senden.
Referenz-ID	Systemseitig	Interne Transportreferenz eines Aufrufs	Kein fachlicher Annahmenachweis.
Externe Referenz	Providerabhängig	Aus der Providerantwort erkannte Nummer	Kann bei Simulation künstlich sein; bei Live wird sie nur aus wenigen bekannten Antwortfeldern oder Mustern erkannt.
Nachrichtenstatus	Systemseitig	SIMULATED, SENT oder ERROR; weitere Statusbezeichnungen sind im Modell vorgesehen	SENT basiert auf dem HTTP-Ergebnis, nicht auf einer nachgelagerten fachlichen Quittung.

Status und mögliche Übergänge

Ausgangszustand	Aktion oder Ereignis	Ergebnis
Keine Konfiguration oder Simulation	Technischer Provideraufruf bei erlaubter Simulation	SIMULATED mit künstlicher Referenz oder simulierter Ablehnung; keine externe Wirkung.
Simulation global gesperrt	Provider wäre nur simulierbar	Aufruf wird abgewiesen; für diesen Versuch entsteht kein Nachrichtenprotokoll.
Livekonfiguration deaktiviert, URL oder Zugang fehlt	Übermittlung	ERROR wird protokolliert; kein automatischer Rückfall auf Simulation.
Livekonfiguration erreichbar	Provider antwortet mit HTTP unter 400	SENT; keine belegte fachliche Annahme oder Quittung.
Liveprovider antwortet mit Fehler oder Netzwerkfehler	Übermittlung	ERROR mit intern gespeichertem Fehler.
Booking oder SI in den letzten 24 Stunden bereits SENT oder ACKNOWLEDGED	Erneuter Aufruf ohne Übersteuerung	Hinweis auf möglichen Doppelversand; noch keine weitere Sendung.
Doppelversandhinweis bei Booking oder SI	Bewusste Übersteuerung	Zweite Übermittlung wird versucht.
VGM, Hafen oder Zoll bereits übermittelt	Erneuter oder paralleler Aufruf	Kein belegter Dublettenschutz; eine weitere externe Wirkung ist möglich.

ACKNOWLEDGED und PENDING können in der vorbereiteten Anzeige dargestellt werden, aber für diesen ausgehenden Pfad ist kein durchgängiger Eingang und keine Statusfortschreibung aus fachlichen Providerquittungen belegt. Ein Eintrag bleibt daher nicht automatisch bis zur Annahme, Freigabe oder Ablehnung synchronisiert.

Der Bookingpfad kann eine von der Antwort gelesene externe Referenz als Bookingnummer in die Akte schreiben. Das geschieht derzeit auch bei erlaubter Simulation. Der Zollpfad kann entsprechend eine simulierte MRN in die Zollanmeldung schreiben. Solche Testreferenzen sind keine Betriebsdaten und dürfen nicht in Liveprozesse übernommen werden.

Was im Hintergrund passiert

NeuraPort lädt Akte, Carrier, Häfen, Kunde und Container im Mandantenkontext und erstellt daraus einen ausgehenden Datensatz. Er kann unter anderem Beteiligtennamen, EORI, Akten-, Booking-, B/L-, MRN-, Container- und Siegelnummern, Häfen, Reise, Termine, Ware, HS-Code, Gewichte, Incoterm und Gefahrgutkennzeichen enthalten. Diese Daten werden für die operative Übermittlung nicht anonymisiert: Der externe Provider benötigt sie zur Vertragserfüllung. Providervertrag, Rechtsgrundlage, Datenminimierung, Empfängerländer, Aufbewahrung und Betroffeneninformation müssen deshalb vor Livebetrieb geklärt sein.

Ist eine aktive Livekonfiguration vorhanden, sendet eine gemeinsame Transportschicht den Datensatz über TLS mit API-Schlüssel, Benutzername/Passwort oder Clientzertifikat. Zieladressen werden gegen interne oder unsichere Netzwerkziele geprüft. Die Schicht liefert Transport und Authentifizierung, aber keine nachgewiesene Zertifizierung der konkreten Provider-Nachrichtenprofile. Beim Hafenpfad wird live ein generischer Akten-Datensatz als JSON gesendet, während die Simulation providerspezifische Testformate verwenden kann. Ein erfolgreicher Simulationstest belegt daher nicht, dass der Liveprovider das reale Format akzeptiert.

Der Liveaufruf erfolgt einmal mit einem konfigurierten Timeout. Obwohl die Konfiguration einen Wiederholungswert enthalten kann, verwendet dieser Pfad ihn nicht. Es gibt keine automatische Retry-Warteschlange und keinen stabilen fachlichen Idempotenzschlüssel. Booking und SI prüfen nur vorab, ob in den letzten 24 Stunden bereits ein erfolgreicher Logeintrag vorhanden ist. Parallele Aufrufe können diese Prüfung gleichzeitig passieren.

Nach einem Aufruf speichert NeuraPort Provider, Meldungstyp, Richtung, Status, interne und externe Referenz, Zeitpunkt, Antwort und gegebenenfalls Fehler mandantenbezogen. Im Simulationspfad kann das Protokoll den vollständigen fachlichen Testdatensatz enthalten. Im Livepfad wird als Payloadprotokoll überwiegend nur Ziel und Meldungstyp gespeichert; die Providerantwort wird als strukturiertes Objekt oder gekürzt als Text abgelegt. Die sichtbare vorbereitete Liste zeigt davon nur einen kleinen Ausschnitt.

Die vorhandenen Tests belegen, dass eine unvollständige Livekonfiguration nicht still auf Simulation zurückfällt, dass Livebetrieb Zugangsdaten verlangt, Zertifikatsdateien auf ein verwaltetes Verzeichnis begrenzt sind und global gesperrte Simulation abbricht. Nicht durch gezielte Ende-zu-Ende-Tests belegt sind die fünf vollständigen Meldungswege, Provider-Mappings und Nachrichtenschemata, echte Quittungen, parallele Doppelaufrufe, Retryverhalten, alle Mandanten-/OE-Negativfälle, Vorschau und Bestätigung sowie die sichtbaren Fehler- und Leerzustände.

Typische Fehler und Lösungen

Meldung oder Beobachtung	Ursache	Lösung
Provideraktionen oder Nachrichtenprotokoll fehlen in der Akte	Der vorbereitete Schnittstellentab ist im aktiven Hauptfrontend nicht eingebunden.	Keinen Direktweg verwenden. Für Hafen und Zoll die belegten Fachoberflächen nutzen; Carrierpfad als Produktlücke melden.
Akte nicht gefunden	Akte gehört zu einem anderen Mandanten oder liegt außerhalb des erlaubten Einheitenbereichs.	Richtige Organisationseinheit und Aktenzugriff prüfen lassen; keine fremde Kennung verwenden.
Aktion wird trotz fachlich falschem Modul technisch angeboten	Der gemeinsame Pfad akzeptiert mehrere alternative Modullizenzen und prüft nicht jedes Fachrecht.	Nicht senden; Rolle und Lizenz fachlich korrigieren lassen.
… ist nicht live konfiguriert; Simulation ist in Produktion deaktiviert	Für den Provider ist kein nutzbarer Liveanschluss vorhanden und Simulation ist global gesperrt.	Schnittstellenadministration einschalten; keine Testreferenz manuell eintragen.
Live-Schnittstelle ist deaktiviert	Provider steht auf Live, ist aber nicht aktiv.	Konfiguration und Freigabe prüfen; nicht wiederholt senden.
Keine API-URL konfiguriert oder Live-Schnittstelle ohne Zugangsdaten	Livekonfiguration ist unvollständig.	Zugang und Ziel ausschließlich in der Schnittstellenadministration vervollständigen und erneut abnehmen.
Fehler bei Buchungsübermittlung, Fehler bei SI-Übermittlung, Fehler bei VGM-Übermittlung, Fehler bei Zollmeldung oder Fehler bei Hafenmeldung	Konfiguration, Netzwerk, Providerantwort oder interne Verarbeitung ist fehlgeschlagen.	Nicht blind wiederholen. Providerstatus, Protokoll und externe Verarbeitung zuerst durch die Administration klären.
Fehler bei der Übermittlung ohne Detail	Der vorbereitete Frontendentwurf ersetzt den konkreten Serverfehler durch eine Sammelmeldung.	Zeitpunkt, Akte und Aktion dokumentieren und Schnittstellenprotokoll administrativ prüfen lassen.
Doppelversand erkannt	Booking oder SI wurde innerhalb von 24 Stunden bereits erfolgreich protokolliert.	Providerreferenz und Fachstatus prüfen; Trotzdem senden nur nach dokumentierter Freigabe.
Kein Doppelversandhinweis bei VGM, Hafen oder Zoll	Für diese Meldungen existiert im generischen Pfad kein entsprechender Schutz.	Vor jedem weiteren Klick externen Status prüfen; Wiederholung nur kontrolliert ausführen.
Hafenprovider passt nicht zum Ladehafen	UN/LOCODE fehlt, ist nicht exakt unterstützt oder fällt auf DAKOSY zurück.	Nicht senden; Ladehafen und Providerzuordnung technisch korrigieren und im Testsystem abnehmen.
SENT, aber keine Buchung, Freigabe oder Annahme beim Provider	HTTP-Transport war erfolgreich, fachliche Antwort wurde aber nicht ausgewertet oder nicht zurückgespielt.	Providerportal beziehungsweise vereinbarten Quittungskanal prüfen; Vorgang bis zur Klärung offen halten.
Simulation meldet Erfolg, Akte enthält aber eine Bookingnummer oder Zollanmeldung eine MRN	Simulationsreferenz wurde in das Fachobjekt geschrieben.	Referenz als Testwert sperren und fachlich bereinigen lassen; Datensatz nicht in Live übernehmen.
VGM-Schaltfläche verspricht alle Container, protokolliert aber nur einen	Der vorbereitete Entwurf wählt nur den ersten Container mit VGM, sonst den ersten Container.	Nicht als Sammelübermittlung behandeln; jeden Container separat und extern kontrollieren.
Provider erhält NeuraPort GmbH als Bucher oder verantwortliche VGM-Partei	Der vorbereitete Nachrichtensatz verwendet eine feste Partei statt Mandantenstammdaten.	Nicht live senden; Beteiligtenmapping korrigieren, mit Provider abnehmen und erst danach freigeben.
Simulierte Ablehnung erscheint als Erfolgsmeldung	Der vorbereitete Entwurf wertet jeden simulierten Rückgabewert als Erfolg, auch wenn die Simulation eine Ablehnung liefert.	Detailstatus administrativ prüfen; Simulationsmeldung nicht als Abnahme verwenden.
Protokoll zeigt nur zehn Einträge und keine Antwortdetails	Die vorbereitete Aktenliste begrenzt und verkürzt die Darstellung.	Vollständige Historie und externe Referenzen über die freigegebene Administrationsprüfung abgleichen.