Fehlercodes¶

Eine Übermittlung nach DiWaSS kann auf zwei völlig verschiedenen Ebenen scheitern. Die beiden Ebenen haben unterschiedliche Fehlerformate, stehen an unterschiedlichen Stellen der Antwort und erfordern unterschiedliche Reaktionen. Wer sie verwechselt, baut eine Fehlerbehandlung, die abgelehnte Dokumente für zugestellt hält.

Diese Seite beschreibt beide Ebenen, zeigt, wo die Details jeweils stehen, und listet die bekannten fachlichen Fehlercodes von DiWaSS. Wie die BMU-Schnittstelle Fehler meldet, steht im Abschnitt BMU.

Zwei Fehlerebenen¶

	Transportfehler	Fachliche Ablehnung
Wer meldet	ZEDAL-Plattform	DiWaSS
Woran erkennbar	gRPC-Status ≠ `OK`, HTTP ≥ 400	Fehlercode im Antwortinhalt
Aufruf technisch erfolgreich	nein	ja — typischerweise HTTP 200
Fehlerformat	gRPC-Statuscode + Detailtext	`code` + `description` je Befund
Zeitpunkt	synchron	teils synchron, teils asynchron
Reaktion	Aufruf wiederholen, Zugang/Parameter prüfen	Dokument korrigieren und neu übermitteln

Der wichtigste Satz auf dieser Seite

Eine fachliche Ablehnung steckt in einer technisch erfolgreichen Antwort. Ein Integrator, der nur den HTTP-Status oder das Ausbleiben einer RpcException prüft, sieht eine abgelehnte Übermittlung nie. Beide Ebenen müssen getrennt ausgewertet werden.

Der Weg eines Dokuments und die Stellen, an denen es scheitern kann:

flowchart TD
    A[Client] -->|"gRPC / REST"| B[ZEDAL-Plattform]
    A -.->|"Transportfehler:<br/>RpcException / HTTP ≥ 400"| A
    B --> C{Schema-Prüfung}
    C -->|"Verstoß"| D["ValidationErrors<br/>(RPC bleibt erfolgreich)"]
    C -->|"konform"| E[Versand an DiWaSS]
    E --> F{DiWaSS-Antwort}
    F -->|"statusCode = OK"| G[angenommen]
    F -->|"statusCode = WARNING"| H["angenommen, mit Warnungen"]
    F -->|"statusCode = NOTOK"| I["abgelehnt, mit Fehlerliste"]
    I --> J["TransferHistory / LastError<br/>DiwassTransferFailedException"]

Innerhalb der fachlichen Ebene gibt es noch einmal zwei Stufen, die nicht dasselbe sind:

Schema-Validierung durch ZEDAL — synchron, feldgenau, mit Pfad in das Dokument. Landet in ValidationErrors und lässt den Aufruf nicht scheitern.
Fachliche Prüfung durch DiWaSS — überwiegend asynchron, nach dem Versand. Landet in der Versandhistorie und in den Transferdetails. Die Codes aus dem Katalog unten stammen aus dieser Stufe.

Ein Dokument kann schema-konform sein und trotzdem von DiWaSS abgelehnt werden. Der umgekehrte Fall existiert ebenfalls: DiWaSS erzwingt Pflichten, die das generierte Schema nicht hergibt — siehe Schema ist keine ausreichende Vorprüfung.

Transportfehler¶

gRPC¶

Ein fehlgeschlagener Aufruf wirft eine RpcException. Auszuwerten sind zwei Felder:

Feld	Inhalt
`Status.StatusCode`	gRPC-Statuscode — die maschinenlesbare Klassifikation
`Status.Detail`	Freitext des Servers, plattformabhängig strukturiert (siehe unten)

try
{
    await handler.SendToDiwass();
}
catch (RpcException ex)
{
    // Transport level: the call did not get through.
    Console.Error.WriteLine($"{ex.Status.StatusCode}: {ex.Status.Detail}");
}

REST¶

Der REST-Gateway übersetzt den gRPC-Status in einen HTTP-Status und legt den Originalstatus in den Antwortkörper:

{
  "code": 3,
  "message": "INVALID_DOCID(6b4575ne)",
  "details": []
}

code ist nicht der HTTP-Status

Das Feld code trägt den numerischen gRPC-Statuscode, nicht den HTTP-Status. 3 ist INVALID_ARGUMENT und kommt als HTTP 400 an. Wer auf code prüft, muss die gRPC-Nummerierung verwenden.

Die Übersetzung ist fest verdrahtet:

gRPC-Status	HTTP
`OK`	200
`INVALID_ARGUMENT`, `FAILED_PRECONDITION`, `OUT_OF_RANGE`	400
`UNAUTHENTICATED`	401
`PERMISSION_DENIED`	403
`NOT_FOUND`	404
`ALREADY_EXISTS`, `ABORTED`	409
`RESOURCE_EXHAUSTED`	429
`CANCELLED`	499
`UNIMPLEMENTED`	501
`UNAVAILABLE`	503
`DEADLINE_EXCEEDED`	504
alle übrigen (u. a. `UNKNOWN`, `INTERNAL`, `DATA_LOSS`)	500

Der Sammelfall am Ende der Tabelle ist der häufigste Stolperstein: UNKNOWN kommt als HTTP 500 an. Ein HTTP 500 ist deshalb nicht zwingend ein Plattformdefekt — er kann eine reguläre fachliche Zurückweisung des Backends transportieren, deren Detailtext im message-Feld steht.

Symbole im Detailtext¶

Ein Teil der Plattform meldet Fehler als Symbol im Detailtext, optional mit der betroffenen Objekt-Id in Klammern, mehrere Befunde mit | verkettet:

NO_ACCESS(39910-5)|NO_ACCESS(39911-5)

Die Klammer enthält keine Fehlernummer

39910-5 ist die Id des betroffenen ZEDAL-Objekts, nicht Teil des Fehlercodes. Wer den kompletten String als Code behandelt, kann zwei gleichartige Fehler nicht zusammenfassen. Trenne am ersten (.

Die Klammer kann auch leer bleiben (INVALID_DOCID()) oder ganz fehlen (UNKNOWN_FORMAT). Bekannte Symbole:

Symbol	gRPC-Status	Auslöser
`INVALID_DOCID`	`INVALID_ARGUMENT`	Dokument-Id leer oder syntaktisch unbrauchbar
`INVALID_FILEID`	`INVALID_ARGUMENT`	Akten-Id leer oder syntaktisch unbrauchbar
`INVALID_TEMPLATEID`	`INVALID_ARGUMENT`	Vorlagen-Id leer oder syntaktisch unbrauchbar
`INVALID_PAR`	`UNKNOWN`	Parameterwert außerhalb des zulässigen Bereichs; der Klammerinhalt nennt den Parameternamen
`NO_ACCESS`	`UNKNOWN`	Zugriff auf ein fremdes Objekt
`DOC_NOT_IN_INBOX`	`UNKNOWN`	das Dokument liegt nicht (mehr) im Posteingang
`UNKNOWN_FORMAT`	`UNKNOWN`	Importdaten in einem nicht erkannten Format
`SUBMISSION_EXISTS`	`UNKNOWN`	für die Akte besteht bereits eine Einreichung
`GOT_NO_SUBMISSION`	`UNKNOWN`	die Operation setzt eine Einreichung voraus, es gibt keine
`UNABLE_TO_OPEN`	`UNKNOWN`	das Zielobjekt lässt sich nicht zum Bearbeiten öffnen

Keine abschließende Liste

Die Liste ist nicht abschließend; einige Symbole gibt es in zwei Schreibweisen mit gleicher Bedeutung (DOC_NOT_EXISTS / DOCUMENT_NOT_EXISTS, DOC_IS_SECRET / DOCUMENT_IS_SECRET, INVALID_PAR / INV_PAR). Verlasse dich in Ablaufentscheidungen auf den gRPC-Statuscode, nicht auf das Symbol. Nutze das Symbol für Diagnose und Protokoll.

Zeitüberschreitungen¶

Eine Zeitüberschreitung ist ein Transportfehler und keine Ablehnung. Das Dokument kann trotzdem angekommen sein. Nach einem Timeout gilt: erst den Zustand abfragen, dann entscheiden — nicht blind erneut senden.

Wert	Größe	Konsequenz
Client-Default-Timeout des SDK (`IZedalClient.DefaultTimeout`)	30 s	für DiWaSS-Dokumentversand zu knapp
Push mit Anhang	über 90 s	mindestens 180 s ansetzen
Mehrstufige Movement-Ketten	bis etwa 5 Minuten pro Stufe	180 s reichen dort nicht
Fremd-Updates (Behörden-Nachforderung, Decision) bis zur Sichtbarkeit im ZEDAL-Bestand	etwa 2 bis 3 Minuten	nicht sofort nach dem Ereignis abfragen

Das Timeout wird pro Aufruf über ZedalCallContext gesetzt:

var ctx = new ZedalCallContext(timeoutSeconds: 180);
await handler.SendToDiwass(ctx);

Null bedeutet nicht unbegrenzt

0 ergibt eine Deadline von „jetzt” und lässt jeden Aufruf mit DEADLINE_EXCEEDED scheitern. Das SDK weist 0 deshalb mit ArgumentOutOfRangeException zurück. Unbegrenzt ist ZedalCallContext.NoTimeout (-1).

Zu Wiederholungen nach Fehlern gibt die EU eine ausdrückliche Vorgabe: technische Fehler dürfen nicht sofort erneut versucht werden, sondern erst nach einer angemessenen Wartezeit; Aufrufe, die an fehlerhaften Daten gescheitert sind, dürfen ohne Korrektur der Daten überhaupt nicht wiederholt werden. Aufrufe sind zudem sequenziell abzusetzen — der jeweils nächste erst, nachdem der vorige beantwortet ist.

Drosselung durch DiWaSS¶

DiWaSS begrenzt die Zahl gleichzeitiger Aufrufe. Wird die Grenze überschritten, antwortet die Plattform mit einem Server-Fault, dessen Meldungstext ConcurrentRequestsLimitExceededException enthält (kommt als HTTP 500 / env:Server).

Drosselung ist kein fachlicher Fehler

Das Dokument ist in Ordnung, der Server war beschäftigt. Das ist der einzige Fall, in dem ein automatischer Retry richtig ist. Bewährt hat sich ein Backoff im Bereich von 20 Sekunden über mehrere Versuche — und ein Protokolleintrag je Wiederholung, damit ein Lauf nicht stillschweigend erfolgreich wirkt, während die Gegenseite in Wahrheit überlastet war.

Erkenne die Drosselung eng an genau diesem Marker und wiederhole nichts anderes automatisch. Ein Retry auf einen fachlichen Fehler erzeugt nur denselben Fehler noch einmal — und verstößt gegen die EU-Vorgabe oben.

Vermeiden lässt sie sich, indem Aufrufe strikt sequenziell abgesetzt werden. Mehrstufige Abläufe — etwa eine Movement-Kette über mehrere Beförderer — laufen bei paralleler Ausführung mit hoher Wahrscheinlichkeit hinein.

Fachliche Fehler: wo sie stehen¶

Fachliche Befunde erreichen den Aufrufer über drei getrennte Oberflächen. Sie sind nicht redundant — jede trägt etwas, das die anderen nicht haben.

Oberfläche	Herkunft	Befüllt bei	Struktur
`ValidationErrors`	ZEDAL-Schemaprüfung	jeder Mutation (`Set`, `Create`, `Submit*`)	`path` + `error`
`TransferHistory` / `LastError`	Versandversuche an DiWaSS	`Refresh()` über die typisierten `Get*`-Endpunkte	`code` + `message`
`DiwassTransferFailedException.Details`	DiWaSS-Antwort auf den Versand	`WaitForDiwassTransfer()`	`code` + `description`, getrennt nach Errors und Warnings

1. Schema-Validierung — `ValidationErrors`¶

Jede BXA-Antwort trägt eine Validierungsliste. Ist das Dokument schemakonform, ist die Liste leer; sonst enthält sie je Verstoß ein Tupel aus Pfad und Meldung.

public IList<ValidationError> ValidationErrors { get; protected set; }
public bool HasValidationErrors => ValidationErrors.Count > 0;

ValidationError hat genau zwei Felder:

Feld	Inhalt
`path`	Objektpfad auf die fehlerhafte Stelle im Dokument, JSONPath-artig auf den Proto-Feldnamen
`error`	Meldungstext zu diesem Pfad

Validierungsfehler lassen den Aufruf nicht scheitern

Sie werden neben der regulären Antwort durchgereicht. Es fliegt keine Exception, der gRPC-Status bleibt OK. Wer HasValidationErrors nicht abfragt, arbeitet mit einem fehlerhaften Dokument weiter.

await handler.SetSubmission(submission);

if (handler.HasValidationErrors)
{
    foreach (var v in handler.ValidationErrors)
    {
        Console.Error.WriteLine($"{v.Path}: {v.Error}");
    }
    return; // do not send
}

Refresh() setzt die Liste nicht zurück, weil der Get-Endpunkt keine Validierungsfehler liefert. Der Inhalt stammt also immer von der letzten Mutation.

2. Versandhistorie — `TransferHistory`, `HasError`, `LastError`¶

Die Versandhistorie führt Erfolge und Fehlversuche in einer Liste, neuester Eintrag zuerst:

public IList<TransferEntry> TransferHistory { get; protected set; }
public bool HasError => TransferHistory.Count > 0 && !TransferHistory[0].Success;
public ErrorInfo LastError => HasError ? TransferHistory[0].Error : null;

Typ	Feld	Inhalt
`TransferEntry`	`OccurredAt`	Zeitpunkt des Versuchs (UTC)
	`Success`	`true` bei erfolgreicher Zustellung
	`RequestName`	auslösende Operation, z. B. `SetSubmission`
	`Error`	gesetzt genau dann, wenn `Success == false`
`ErrorInfo`	`Code`	maschinenlesbarer Fehlercode — hier stehen die Codes aus dem Katalog
	`Message`	Meldungstext

Zwei Eigenschaften, die regelmäßig missverstanden werden:

Mutationen füllen die Historie nicht. Set*- und Submit*-Antworten tragen keine transfer_history; nach einer Mutation ist die Liste leer. Befüllt wird sie über Refresh(), das die typisierten GetNotification / GetAnnex7 / GetMovement aufruft.
Die Historie ist serverseitig begrenzt. Ältere Einträge werden verworfen. Sie ist kein vollständiges Audit-Log.

await handler.Refresh();

if (handler.HasError)
{
    var e = handler.LastError;
    Console.Error.WriteLine($"Transfer failed: {e.Code} — {e.Message}");
}

3. Transferdetails — `WaitForDiwassTransfer`¶

WaitForDiwassTransfer(timeout, pollInterval) pollt den Versandstatus, bis er terminal ist:

`DocumentTransferStatus`	Bedeutung	Verhalten der Methode
`CREATED`	Versand angelegt	weiter pollen
`IN_PROGRESS`	Versand läuft	weiter pollen
`DELIVERED_TO_RECIPIENT_INBOX`	zugestellt	kehrt zurück
`RECEIVED_RECEIPT_POSITIVE`	positiv quittiert	kehrt zurück
`RECEIVED_RECEIPT_NEGATIVE`	negativ quittiert — fachliche Ablehnung	wirft `DiwassTransferFailedException`
`CANCELLED`	Versand abgebrochen	wirft `DiwassTransferFailedException`

Wird der Status nicht rechtzeitig terminal, fliegt eine TimeoutException — das ist keine Ablehnung, siehe Zeitüberschreitungen.

Die Exception trägt die vollständigen Transferdetails:

public GetTransferDetailsResponse Details { get; }

Darin liegen unter DiwassTransferDetails zwei getrennte Listen, Errors und Warnings, jeweils mit Code und Description.

try
{
    await handler.WaitForDiwassTransfer(
        timeout:      TimeSpan.FromSeconds(180),
        pollInterval: TimeSpan.FromSeconds(10));
}
catch (DiwassTransferFailedException ex)
{
    foreach (var err in ex.Details.DiwassTransferDetails.Errors)
    {
        Console.Error.WriteLine($"DiWaSS error {err.Code}: {err.Description}");
    }
    foreach (var w in ex.Details.DiwassTransferDetails.Warnings)
    {
        Console.Error.WriteLine($"DiWaSS warning {w.Code}: {w.Description}");
    }
}
catch (TimeoutException)
{
    // Not a reason for rejection — check the state afterwards via Refresh().
}

pollInterval muss mindestens 1 Sekunde betragen; kleinere Werte weist die Methode mit ArgumentOutOfRangeException zurück.

Nach dem Warten neu laden

WaitForDiwassTransfer lädt das Dokument nicht automatisch nach. Serverseitig ergänzte Felder — etwa die vergebene Notifizierungsnummer — sieht erst, wer danach ReloadFromZedal() aufruft.

Aufbau der DiWaSS-Antwort¶

Unter den ZEDAL-Oberflächen liegt immer dieselbe Antwortstruktur der EU-Schnittstelle:

Element	Inhalt
`statusCode`	`OK`, `WARNING` oder `NOTOK`
`errors`	0..n Befunde, je `code` + `description`
`warnings`	0..n Befunde, je `code` + `description`

So sieht eine reale Ablehnung aus — hier auf eine Einreichung, bei der eine Betreiber-Id nicht auflösbar war:

<responseStatus>
  <statusCode>NOTOK</statusCode>
  <errors>
    <code>OPERATOR-ID-NOT-FOUND</code>
    <description languageID="en">Operator 999999999 not found</description>
  </errors>
</responseStatus>
<notificationId>UNKNOWN</notificationId>

Beachte notificationId = UNKNOWN: bei einer abgelehnten Einreichung vergibt DiWaSS keine Nummer. Wer die Antwort ungeprüft ausliest, speichert UNKNOWN als Notifizierungsnummer.

Errors und Warnings können in derselben Antwort stehen:

<response>
  <statusCode>NOTOK</statusCode>
  <errors>
    <code>MANDATORY_ELEMENT_MISSING</code>
    <description languageID="en">Element "actualQuantity" is mandatory in block 3
      of Annex VII. Please provide at least one of MassMeasure or VolumeMeasure
      with a positive value.</description>
  </errors>
  <warnings>
    <code>OPTIONAL_ATTACHMENT_MISSING</code>
    <description languageID="en">Attachment references were expected but none
      were found.</description>
  </warnings>
</response>

Daraus folgen drei Regeln für die Auswertung:

WARNING ist eine Annahme. Das Dokument ist angenommen, DiWaSS hat Anmerkungen. Warnungen dürfen nicht wie Ablehnungen behandelt werden — sonst blockierst du gültige Vorgänge.
warnings erscheint auch bei NOTOK. Die Liste ist nicht an den Status gekoppelt. Der Status entscheidet über Annahme oder Ablehnung, nicht die Frage, welche Listen befüllt sind.
errors ist eine Liste. Eine Ablehnung nennt oft mehrere Befunde gleichzeitig. Wer nur den ersten anzeigt, schickt den Anwender in mehrere Korrekturrunden hintereinander.

Neben dieser Antwortstruktur kennt die EU-Schnittstelle noch eigene Fault-Typen für Fälle, die gar nicht erst zu einer fachlichen Antwort führen: PermissionDeniedExceptionType, CertificatePermissionDeniedExceptionType, InvalidParametersExceptionType und BusinessRulesValidationExceptionType. Sie tragen je Befund ID, Message und optional Field. Über die ZEDAL-Oberflächen erscheinen sie als Meldungstext, nicht als eigener Code.

Schema ist keine ausreichende Vorprüfung¶

DiWaSS setzt Pflichten durch, die im generierten Schema nicht als Pflicht stehen. Eine clientseitige Vollständigkeitsprüfung allein gegen minOccurs reicht deshalb nicht aus.

Beispiel: RejectedQuantity und RejectionDescription sind am Movement-Empfangszertifikat als minOccurs=0 annotiert. DiWaSS lehnt eine Übertragung ohne diese Felder trotzdem ab — mit REJECTED-QUANTITY-EMPTY und REJECTION-DESCRIPTION-EMPTY. Im Annex-VII-Kontext ist dasselbe Feld ausdrücklich minOccurs=1; die Abweichung ist also gewollt und kein Übertragungsfehler.

Der umgekehrte Fall existiert ebenfalls: mimeCode an Anhängen ist im Schema ein freies Pflichtfeld ohne Wertebeschränkung — es gibt keine MIME-Allowlist. Die kontrollierte Liste ist typeID, die fachliche Klassifikation des Anhangs.

Schreibweise: Bindestrich gegen Unterstrich¶

Derselbe Fehler, zwei Schreibweisen

Die EU-Spezifikationsliste führt die Codes mit Unterstrichen (ATTACHMENT_NOT_FOUND). In seinen Antworten meldet DiWaSS sie mit Bindestrichen (ATTACHMENT-NOT-FOUND). Ein direkter Zeichenkettenvergleich zwischen empfangenem Code und Katalogeintrag schlägt deshalb fehl, obwohl beide denselben Fehler meinen.

Bekannte Paare — links die Schreibweise der Spezifikationsliste, rechts die in DiWaSS-Antworten:

In der Spezifikationsliste	In DiWaSS-Antworten
`ATTACHMENT_NOT_FOUND`	`ATTACHMENT-NOT-FOUND`
`AUTHORITY_ID_NOT_FOUND`	`AUTHORITY-ID-NOT-FOUND`
`OPERATOR_ID_NOT_FOUND`	`OPERATOR-ID-NOT-FOUND`
`WASTE_CLASSIFICATION_INVALID_CODE`	`WASTE-CLASSIFICATION-INVALID-CODE`
`INVALID_NOTIFICATION_CA_CODE_PREFIX`	`INVALID-NOTIFICATION-CA-CODE-PREFIX`
`BAD_REQUEST_NOTIFIER`	`BAD-REQUEST-NOTIFIER`
`USER_AUTHORISATION_PERMISSION_AUTHORITY_DENIED`	`USER-AUTHORISATION-PERMISSION-AUTHORITY-DENIED`

Verlass dich auf keine der beiden Schreibweisen

Die Regel ist nicht durchgängig: die Beispielantworten der Spezifikation verwenden ihrerseits Unterstriche (MANDATORY_ELEMENT_MISSING, OPTIONAL_ATTACHMENT_MISSING). Es gibt also keine Schreibweise, auf die du dich beim Vergleich verlassen kannst. Normalisiere beide Seiten.

static string NormalizeDiwassCode(string code) =>
    code?.Trim().ToUpperInvariant().Replace('_', '-');

Der Katalog unten führt die Codes in der Schreibweise der jeweiligen Quelle. Codes, die in DiWaSS-Antworten vorkommen, aber in der Liste fehlen, sind mit Bindestrichen notiert.

Katalog der DiWaSS-Fehlercodes¶

Die folgenden 187 Codes stammen aus der Validierungsliste der DiWaSS-Spezifikation (Validations-messages.xlsx, Spalten „Code” und „Label for description”). Ergänzt sind Codes, die in der Praxis aufgetreten sind und in der Liste fehlen.

So sind die Tabellen zu lesen:

Code — der Bezeichner, wie ihn die Quelle führt. Zum Vergleich mit einer Serverantwort erst normalisieren.
Label — der Übersetzungsschlüssel, den DiWaSS zu diesem Code führt. to.be.created heißt: die EU hat für diesen Code noch keinen Beschreibungstext vergeben. Das betrifft 23 der 187 Codes.
Bedeutung — die Aussage des Codes, abgeleitet aus Bezeichner und Label.
Ursache und Auflösung — nur ausgefüllt, wo die Ursache bekannt ist. Ein — heißt „keine Angabe”, nicht „tritt nicht auf”.

Diese Liste ist nicht abschließend

Real auftretende Codes fehlen darin. REJECTED-QUANTITY-EMPTY, REJECTION-DESCRIPTION-EMPTY, MOVEMENT-SHIPMENT-ORIGIN-ADDRESS-MISMATCH-NOTIFICATION und MOVEMENT-DATE-BEFORE-NOTIFICATION-DATE sind in der Praxis aufgetreten, stehen aber in keiner Fassung der Spezifikationsliste. Sie sind unten in ihrer jeweiligen Themengruppe mitgeführt und als (nicht in der Liste) gekennzeichnet. Behandle jeden unbekannten Code als gültigen Fehler und melde ihn uns — die Liste wächst nur so.

Das Label ist kein eindeutiger Schlüssel

Mehrere Codes teilen sich denselben Übersetzungsschlüssel. participation.party.not.allowed steht für sieben verschiedene Codes, und waste.notification.shipment.date.empty für zwei. Schalte deine Logik immer auf den Code, nie auf das Label.

Abfallklassifizierung und Abfallangaben¶

Code	Label	Bedeutung	Ursache und Auflösung
`WASTE_CLASSIFICATION_INVALID_CODE`	`waste.error.classification.code`	Ein Abfallcode ist ungültig — der Wert selbst, nicht sein Fehlen.	Häufigste Ursache: fehlende Gruppen-Leerzeichen. DiWaSS erwartet EU-Abfallschlüssel als `01 03 06`, nicht `010306`; gefährliche Abfälle zusätzlich mit Stern (`01 04 07`). Keiner der 890 Codes der offiziellen LoW-Liste steht dort ohne Leerzeichen. Zweite Ursache: veraltetes `listID`.* Die zulässigen Listennamen sind keine Schema-Enum mehr, sondern lose Token, die serverseitig geprüft werden — aktuell u. a. `LoW`, `Basel_A`, `Basel_B`, `OECD`, `y-code`, `h-code`, `un_class`, `wsr_a3`/`wsr_a3a`/`wsr_a3b`/`wsr_a4`, `hp_codes`, `customs_codes`, `nat_exp`/`nat_imp`, `un_no`, `un_shipping`, `Other`, `unlisted`. Die alten Werte (`BASEL`, `EWL`, `YCODE`, `NATEXP`, `UNNUM`, `ANNEX3A`, …) passieren das Schema, werden vom Server aber abgelehnt. Dritte Ursache: HP-Code im H-Code-Feld. HP-Codes gehören in die Liste `hp_codes` und dort ohne das `EU`-Suffix — obwohl der Verordnungstext in Feld 14 (viii) `HP14 EU` vorsieht. Feld (viii) trägt ausschließlich Basel-H-Codes.
`WASTE_CLASSIFICATION_REQUIRED`	`waste.notification.waste.classification.required`	Die Abfallklassifizierung fehlt vollständig.	Abzugrenzen von `WASTE_CLASSIFICATION_INVALID_CODE`: dieser Code meint „nicht vorhanden”, jener „vorhanden, aber ungültig”.
`USUAL_DESCRIPTION_MANDATORY`	`waste.notification.usual.description.must.exist`	Die übliche Abfallbezeichnung fehlt.	—
`DESIGNATION_DESCRIPTION_REQUIRED`	`waste.notification.designation.description.required`	Bezeichnung und Zusammensetzung des Abfalls fehlen.	—
`PHYSICAL_CHARACTERISTICS_CODES_REQUIRED`	`waste.notification.physical.characteristics.codes.required`	Die Codes zur physikalischen Beschaffenheit fehlen.	—
`PHYSICAL_CHARACTERISTICS_DESCRIPTION_REQUIRED`	`waste.notification.physical.characteristics.description.required`	Die Beschreibung der physikalischen Beschaffenheit fehlt.	—
`PACKAGING_TYPE_CODES_REQUIRED`	`waste.notification.packaging.type.codes.required`	Die Verpackungsart fehlt.	Die DiWaSS-Verpackungsliste ist nicht deckungsgleich mit der klassischen Notifizierungsliste: sie führt zusätzlich „Ballen” als 9, „Sonstiges” rutscht damit auf die 10. Prüfe nie gegen ein Zahlenliteral, sondern gegen die Liste, aus der das Feld befüllt wird.
`PACKAGING_SPECIAL_HANDLING_REQUIRED`	`waste.notification.packaging.special.handling.required`	Angaben zu besonderen Handhabungsvorschriften fehlen.	—
`OPERATIONS_CODES_REQUIRED`	`waste.notification.operations.codes.required`	Die D-/R-Codes des Verfahrens fehlen.	—
`OPERATIONS_TECHNOLOGY_REQUIRED`	`waste.notification.operations.technology.required`	Die Angabe zur eingesetzten Technologie fehlt.	—
`OPERATIONS_REASON_REQUIRED`	`waste.notification.operations.reason.required`	Die Begründung der Verbringung fehlt.	—
`DISPOSAL_RECOVERY_DOES_NOT_MATCH`	`disposal.recovery.does.not.match`	Beseitigung und Verwertung passen nicht zusammen.	—
`CUSTOM_CODES_MANDATORY`	`custom.codes.mandatory`	Zollcodes sind für diesen Vorgang Pflicht.	Zollcodes gehören in die Liste `customs_codes`.
`MASS_VOLUME_NOT_FOUND`	`mass.volume.not.found`	Die Mengenangabe (Masse oder Volumen) fehlt.	—

Parteien und Kontakte¶

Code	Label	Bedeutung	Ursache und Auflösung
`NOTIFIER_OPERATOR_IS_REQUIRED`	`waste.notification.notifier.must.exist`	Der Notifizierende fehlt.	—
`CONSIGNEE_OPERATOR_IS_REQUIRED`	`waste.notification.consignee.must.exist`	Der Empfänger fehlt.	—
`WASTE_PRODUCER_OPERATOR_IS_REQUIRED`	`waste.notification.producer.must.exist`	Der Abfallerzeuger fehlt.	—
`CARRIER_OPERATOR_IS_REQUIRED`	`waste.notification.carrier.must.exist`	Der Beförderer fehlt.	—
`TREATMENT_FACILITY_OPERATOR_IS_REQUIRED`	`waste.notification.facility.must.exist`	Die Behandlungsanlage fehlt.	—
`ARRANGER_OPERATOR_IS_REQUIRED`	`waste.notification.arranger.must.exist`	Der Veranlasser fehlt.	—
`NOTIFIER_CONTACT_IS_REQUIRED`	`waste.notification.notifier.contact.must.exist`	Die Kontaktdaten des Notifizierenden fehlen.	—
`CONSIGNEE_CONTACT_IS_REQUIRED`	`waste.notification.consignee.contact.must.exist`	Die Kontaktdaten des Empfängers fehlen.	—
`PRODUCER_CONTACT_IS_REQUIRED`	`waste.notification.producer.contact.must.exist`	Die Kontaktdaten des Erzeugers fehlen.	—
`CARRIER_CONTACT_IS_REQUIRED`	`waste.notification.carrier.contact.must.exist`	Die Kontaktdaten des Beförderers fehlen.	—
`FACILITY_CONTACT_IS_REQUIRED`	`waste.notification.facility.contact.must.exist`	Die Kontaktdaten der Anlage fehlen.	—
`ARRANGER_CONTACT_IS_REQUIRED`	`waste.notification.arranger.contact.must.exist`	Die Kontaktdaten des Veranlassers fehlen.	—
`CONSIGNEE_CONTACT_IS_MISSING`	`waste.notification.consignee.contact.must.exist`	Zweiter Code mit demselben Label wie `CONSIGNEE_CONTACT_IS_REQUIRED`.	—
`PRODUCER_CONTACT_IS_MISSING`	`waste.notification.producer.contact.must.exist`	Zweiter Code mit demselben Label wie `PRODUCER_CONTACT_IS_REQUIRED`.	—
`CARRIER_CONTACT_IS_MISSING`	`waste.notification.carrier.contact.must.exist`	Zweiter Code mit demselben Label wie `CARRIER_CONTACT_IS_REQUIRED`.	—
`FACILITY_CONTACT_IS_MISSING`	`waste.notification.facility.contact.must.exist`	Zweiter Code mit demselben Label wie `FACILITY_CONTACT_IS_REQUIRED`.	—
`ARRANGER_CONTACT_IS_MISSING`	`waste.arranger.contact.missing`	Die Kontaktdaten des Veranlassers fehlen.	—
`OPERATOR_NOTIFIER_NAME_EMPTY`	`waste.error.invalid.notifier.name`	Der Name des Notifizierenden ist leer.	—
`OPERATOR_CONSIGNEE_NAME_EMPTY`	`waste.error.invalid.consignee.name`	Der Name des Empfängers ist leer.	—
`OPERATOR_CARRIER_NAME_EMPTY`	`waste.error.invalid.carrier.name`	Der Name des Beförderers ist leer.	—
`OPERATOR_TREAT_FAC_NAME_EMPTY`	`waste.error.invalid.treat.fac.name`	Der Name der Behandlungsanlage ist leer.	—
`OPERATOR_FIELD_MISSING`	`waste.operator.field.missing`	An einem Betreiber fehlt ein Pflichtfeld.	—
`PRODUCER_IS_MISSING`	`waste.notification.producer.required`	Der Erzeuger ist für diesen Vorgang Pflicht und fehlt.	—
`PRODUCERS_NOT_ALLOWED`	`waste.notification.producer.not.allowed`	In dieser Konstellation sind keine Erzeuger zulässig.	—
`WASTE_PRODUCER_OPERATOR_DUPLICATE`	`waste.notification.producer.duplicate`	Derselbe Erzeuger ist mehrfach eingetragen.	—
`CARRIER_OPERATOR_DUPLICATE`	`waste.notification.carrier.duplicate`	Derselbe Beförderer ist mehrfach eingetragen.	—
`TREATMENT_FACILITY_OPERATOR_DUPLICATE`	`waste.notification.facility.duplicate`	Dieselbe Anlage ist mehrfach eingetragen.	—
`DUPLICATE_OPERATOR_ID`	`waste.notification.duplicate.operator.id`	Dieselbe Betreiber-Id kommt mehrfach vor.	—
`NON_SUBSEQUENT_FACILITY_IS_REQUIRED`	`waste.notification.non.subsequent.facility.must.exist`	Eine abschließende (nicht nachgelagerte) Anlage fehlt.	Eine Notifizierung führt 1 + n Anlagen. Genau eine muss die abschließende sein. Die Kettenposition steuern die drei Indikatoren in `FacilityType.OperationalIndicators`.
`NON_SUBSEQUENT_FACILITY_MANY`	`waste.notification.non.subsequent.facility.many`	Es ist mehr als eine abschließende Anlage angegeben.	Wie oben — genau eine Anlage darf ohne Nachfolger stehen.
`CONFIDENTIAL_EXPLANATION_MISSING`	`waste.notification.facility.confidential.explanation.required`	Zur Vertraulichkeitskennzeichnung der Anlage fehlt die Begründung.	—
`SIGNATURE_IS_REQUIRED`	`waste.notification.signature.required`	Eine Unterschrift fehlt.	—
`SIGNATURES_ARE_REQUIRED`	`waste.notification.signatures.required`	Mehrere Unterschriften fehlen.	—
`SIGNATURE_MISMATCH`	`waste.notification.signatures.no.match`	Die Unterschrift passt nicht zur erwarteten Partei.	—
`DECLARATION_EMAIL_IS_MISSING`	`waste.notification.signatures.email.required`	Zur Erklärung fehlt die E-Mail-Adresse.	—
`DECLARATION_DOES_NOT_MATCH_PARTY`	`waste.declaration.mismatch.party`	Die Erklärung gehört nicht zur angegebenen Partei.	—
`DECLARATION_SIZE`	`waste.declaration.size`	Die Anzahl der Erklärungen stimmt nicht.	—
`DECLARATION_PRODUCER_SIZE_DOES_NOT_MATCH_PRODUCERS_SIZE`	`declaration.producers.size.mismatch`	Die Zahl der Erzeuger-Erklärungen weicht von der Zahl der Erzeuger ab.	Je Erzeuger genau eine Erklärung.
`PRODUCER_DECLARATION_NOT_FOUND`	`waste.producer.declaration.not.found`	Zu einem Erzeuger fehlt die Erklärung.	—

Verzeichnis, Behörden und Länder¶

Code	Label	Bedeutung	Ursache und Auflösung
`AUTHORITY_ID_NOT_FOUND`	`waste.authority.id.not.found`	Die angegebene Behörde wurde nicht aufgelöst. Realer Meldungstext: `AUTHORITY-ID-NOT-FOUND: Authority <code> not found`.	Das ist eine Zuständigkeits-, keine Existenzaussage. Nicht jede WSR-Behörde darf Durchfuhrbehörde sein, und das Behördenverzeichnis sagt nicht, welche. Beispiel: `BE004` und `BE002` werden als Transit-Behörde angenommen, `BE01` und `BE003` abgelehnt; `DE014` wird im selben Dokument als Export- und Import-Behörde akzeptiert und als Durchfuhrbehörde abgelehnt. Alle Behörden eines Landes liefern im Verzeichnis identische Activity-Daten — transitfähige und nicht transitfähige sind darin nicht unterscheidbar. Der Fehler fällt erst beim Submit auf. Zweiter, unabhängiger Weg zu derselben Meldung: die Behördensuche `FindActivities` findet nur über den alpha-2-Ländercode (`"BE"`). Derselbe Aufruf mit dem numerischen Code (`"056"`) liefert 0 Treffer — ohne Fehler, ohne Exception, einfach eine leere Liste. Bei dieser Meldung zuerst trennen, welcher der beiden Pfade sie erzeugt hat.
`AUTHORITY_ID_MISMATCH`	`waste.authority.id.mismatch`	Die Behörden-Id passt nicht zum erwarteten Wert.	—
`AUTHORITY_NOT_FOUND`	`to.be.created`	Die Behörde wurde nicht gefunden.	—
`COMPETENT_AUTHORITY_NOT_FOUND`	`competent.authority.not.found`	Die zuständige Behörde wurde nicht gefunden.	—
`AUTHORITY_IS_REQUIRED`	`to.be.created`	Eine Behördenangabe fehlt.	—
`AUTHORITY_DOMAIN_NOT_FOUND`	`to.be.created`	Die Domäne der Behörde wurde nicht gefunden.	—
`AUTHORITY_DOMAIN_DONT_MATCH_DOCUMENT`	`to.be.created`	Die Domäne der Behörde passt nicht zur Dokumentart.	—
`NOT_NOTIFICATION_AUTHORITY`	`not.notification.authority`	Die Behörde ist für diese Notifizierung nicht zuständig.	—
`AUTHORITY_CANNOT_BE_CONNECTED`	`participation.party.not.allowed`	Die Behörde darf in dieser Rolle nicht beteiligt werden.	Sieben Codes teilen sich dieses Label — die Unterscheidung steckt allein im Code.
`AUTHORITY_DISPATCH_CANNOT_BE_CONNECTED`	`participation.party.not.allowed`	Die Versandbehörde darf nicht beteiligt werden.	—
`AUTHORITY_DESTINATION_CANNOT_BE_CONNECTED`	`participation.party.not.allowed`	Die Bestimmungsbehörde darf nicht beteiligt werden.	—
`AUTHORITY_TRANSIT_CANNOT_BE_CONNECTED`	`participation.party.not.allowed`	Die Durchfuhrbehörde darf nicht beteiligt werden.	Siehe `AUTHORITY_ID_NOT_FOUND` — Durchfuhrzuständigkeit ist aus dem Verzeichnis nicht ableitbar.
`AUTHORITY_HAS_TO_BE_CONNECTED`	`participation.party.not.allowed`	Die Behörde muss beteiligt werden.	—
`AUTHORITY_DISPATCH_IS_CONNECTED_AND_MANAGE_NOTIFIERS`	`participation.party.not.allowed`	Die Versandbehörde ist angebunden und verwaltet Notifizierende.	—
`AUTHORITY_DISPATCH_IS_CONNECTED_AND_DONT_MANAGE_NOTIFIERS`	`participation.party.not.allowed`	Die Versandbehörde ist angebunden, verwaltet aber keine Notifizierenden.	—
`PARTICIPATION_PARTY_NOT_AUTHORITY`	`participation.party.not.authority`	Die als Behörde geführte Partei ist keine.	—
`PARTICIPATION_PARTY_001`	`participation.party.not.allowed`	Beteiligung dieser Partei nicht zulässig.	In der Quelle steht hinter dem Label ein abgeschnittenes Codefragment — ein Artefakt der Liste, kein Teil des Schlüssels.
`AUTHORITY_IS_NOT_IN_EU`	`to.be.created`	Die Behörde liegt außerhalb der EU.	—
`OPERATOR_IS_NOT_IN_EU`	`to.be.created`	Der Betreiber liegt außerhalb der EU.	—
`TRANSIT_AND_DESTINATION_ARE_NOT_EU`	`to.be.created`	Weder Durchfuhr- noch Bestimmungsstaat liegen in der EU.	—
`OPERATOR_NOT_FOUND`	`to.be.created`	Der Betreiber wurde nicht gefunden.	—
`OPERATOR_ID_NOT_FOUND`	`waste.operator.id.not.found`	Die Betreiber-Id wurde nicht aufgelöst. Realer Meldungstext: `Operator <id> not found`.	Die Id in `OperatorInternalID` existiert im DiWaSS-Betreiberverzeichnis nicht. Betreiber-Ids sind vor dem Zusammenbau des Dokuments über das Verzeichnis aufzulösen, nicht zu raten oder aus Testdaten zu übernehmen. Die Einreichung wird komplett abgelehnt und trägt in der Antwort `notificationId = UNKNOWN`.
`CA_CODE_NOT_FOUND`	`ca.code.not.found`	Der Behörden-Code existiert nicht.	DiWaSS führt Behörden-Codes in unterschiedlichen Längen (vier- und fünfstellig, z. B. `DE01` und `DE014`). Ein naiver `StartsWith` unterscheidet die beiden nicht.
`CA_CODE_LENGTH_ISSUE`	`ca.code.length.issue`	Der Behörden-Code hat eine unzulässige Länge.	Siehe oben — die Länge ist nicht einheitlich.
`CA_CODE_COUNTRY_NOT_FOUND`	`ca.code.country.not.found`	Zum Behörden-Code ist kein Land auflösbar.	—
`COUNTRY_NOT_FOUND`	`country.not.found`	Der Ländercode wurde nicht gefunden.	Im Dokument ist der Ländercode dreistellig numerisch mit führender Null (`056`, XSD-Pattern `\d\d\d`). Ein zweistelliger Wert wird nicht fachlich abgelehnt, sondern schon vom Schema verworfen und erreicht die Fachlogik nie. Im Verzeichnis-Lookup gilt das Gegenteil: dort trägt nur alpha-2 (`BE`).
`COUNTRY_INFO_NOT_FOUND`	`to.be.created`	Zum Land liegen keine Stammdaten vor.	—
`DISPATCH_IS_REQUIRED`	`waste.dispatch.required`	Der Versandstaat fehlt.	—
`DISPATCH_COUNTRY_NOT_FOUND`	`waste.dispatch.country.not.found`	Der Versandstaat wurde nicht gefunden.	—
`DESTINATION_IS_REQUIRED`	`waste.destination.required`	Der Bestimmungsstaat fehlt.	—
`DESTINATION_COUNTRY_NOT_FOUND`	`waste.destination.country.not.found`	Der Bestimmungsstaat wurde nicht gefunden.	—
`TRANSIT_COUNTRY_NOT_FOUND`	`waste.transit.country.not.found`	Der Durchfuhrstaat wurde nicht gefunden.	—
`FACILITIES_ARE_OUT_OF_EXPECTED_LOCATION`	`to.be.created`	Anlagen liegen außerhalb des erwarteten Gebiets.	—
`FACILITY_NOT_PRE_CONSENTED`	`facility.not.preconsented`	Die Anlage ist nicht vorab zugelassen.	—
`ADDRESS_NOT_FOUND`	`address.not.found`	Die Adresse wurde nicht gefunden.	—
`SHIPMENT_ORIGIN_ADDRESS_REQUIRED`	`waste.notification.shipment.origin.address.required`	Die Versandadresse fehlt.	—
`SHIPMENT_ORIGIN_ADDRESS_MISSING`	`waste.notification.shipment.origin.address.required`	Zweiter Code mit demselben Label wie `SHIPMENT_ORIGIN_ADDRESS_REQUIRED`.	—
`SHIPMENT_ORIGIN_ADDRESS_BAD`	`waste.notification.shipment.origin.address.bad`	Die Versandadresse ist unbrauchbar.	—
`SHIPMENT_ORIGIN_ADDRESS_PARTY`	`waste.notification.shipment.origin.address.party`	Die Versandadresse passt nicht zur angegebenen Partei.	—
`MOVEMENT-SHIPMENT-ORIGIN-ADDRESS-MISMATCH-NOTIFICATION`	(nicht in der Liste)	Die Versandadresse im Begleitformular weicht von der Adresse in der konsentierten Notifizierung ab.	`ShipmentOriginAddress` ist im Begleitformular optional — anders als in der Notifizierung, wo dieselbe Struktur Pflicht ist. Ist sie gesetzt, gleicht DiWaSS sie gegen die Notifizierung ab und lehnt jede Abweichung ab. Bleibt sie weg, übernimmt DiWaSS die Adresse aus der Notifizierung und der Push geht durch. Empfehlung: das Feld im Begleitformular nicht setzen, außer der Abgleich soll ausdrücklich geprüft werden.

Mengen und Sendungen¶

Code	Label	Bedeutung	Ursache und Auflösung
`SHIPMENTS_NUMBER_REQUIRED`	`waste.notification.shipments.number.required`	Die Gesamtzahl der vorgesehenen Verbringungen fehlt.	Das ist Feld 4 der Notifizierung. Die Zahl der Begleitformulare darf diese Gesamtzahl nicht überschreiten; ein ordnungsgemäß annulliertes Formular zählt nicht mit, ein liegengelassenes schon.
`MOVEMENT_TEMPLATE_INVALID_TOTAL_NUMBER`	`waste.error.mov.template.invalid.total.number`	Die Gesamtzahl im Begleitformular ist unzulässig.	Siehe oben — das Kontingent aus Feld 4 ist ausgeschöpft oder die Angabe widerspricht der Notifizierung.
`INDIVIDUAL_SHIPMENT_REQUIRED`	`waste.notification.individual.shipment.required`	Für diese Verbringungsart ist eine Einzelverbringung anzugeben.	—
`INDIVIDUAL_SHIPMENT_SHOULD_BE_ONE`	`one.individual.shipment`	Bei Einzelverbringung ist genau eine Verbringung zulässig.	—
`INTENDED_FIRST_DEPARTURE_REQUIRED`	`waste.notification.intended.period.first.departure.required`	Der erste vorgesehene Versandtermin fehlt.	—
`INTENDED_LAST_DEPARTURE_REQUIRED`	`waste.notification.intended.period.last.departure.required`	Der letzte vorgesehene Versandtermin fehlt.	—
`SHIPMENT_DATE_EMPTY`	`waste.notification.shipment.date.empty`	Das Versanddatum fehlt.	—
`SHIPMENT_DATE_MISSING`	`waste.notification.shipment.date.empty`	Zweiter Code mit demselben Label wie `SHIPMENT_DATE_EMPTY`.	—
`MOVEMENT-DATE-BEFORE-NOTIFICATION-DATE`	(nicht in der Liste)	Das Startdatum des Begleitformulars liegt außerhalb des Verbringungszeitraums der Notifizierung.	Der Zeitraum steht in der konsentierten Notifizierung als `ShipmentPeriod` mit `FirstStartDate` und `LastStartDate`. Das Startdatum des Begleitformulars muss innerhalb dieses Fensters liegen. Ein fest verdrahtetes Datum in Testdaten läuft mit der Zeit aus dem Fenster heraus und bricht dann still.
`REJECTED-QUANTITY-EMPTY`	(nicht in der Liste)	Die zurückgewiesene Menge fehlt am Empfangszertifikat.	Das Feld `RejectedQuantity` ist am Movement-Empfangszertifikat im Schema `minOccurs=0`, DiWaSS lehnt eine Übertragung ohne es trotzdem ab. Immer setzen. Im Annex-VII-Kontext ist dasselbe Feld ausdrücklich Pflicht — die Abweichung ist gewollt.
`REJECTION-DESCRIPTION-EMPTY`	(nicht in der Liste)	Die Begründung der Zurückweisung fehlt am Empfangszertifikat.	Wie `REJECTED-QUANTITY-EMPTY`: schema-optional, serverseitig Pflicht.

Anhänge¶

Code	Label	Bedeutung	Ursache und Auflösung
`ATTACHMENT_NOT_FOUND`	`attachment.not.found`	Der referenzierte Anhang ist DiWaSS unbekannt.	Typische Ursache: eine ZEDAL-Zwischen-Id statt einer DiWaSS-Id. Ein Upload über den ZEDAL-Dokumentweg legt den Anhang zwischen und vergibt eine temporäre Kennung der Form `ZEDAL_TMP_ATT_ID_<n>_<m>`. Diese trägt nur für einen Abruf über denselben Weg — DiWaSS kennt sie nicht. Eine zentrale DiWaSS-Anhang-Id hat die Form `<ziffern>ATT`. Als `attachmentIdentifier` an einem Dokument ist nur die DiWaSS-Id brauchbar.
`ATTACHMENTS_NOT_FOUND`	`attachments.not.found`	Mehrere referenzierte Anhänge sind unbekannt.	Wie oben.
`ATTACHMENT_MUST_EXIST`	`attachment.must.exist`	Für diesen Vorgang ist ein Anhang Pflicht.	—
`ATTACHMENT_TYPE_EMPTY`	`waste.error.invalid.attachment.type`	Die fachliche Klassifikation des Anhangs fehlt.	Gemeint ist `typeID` — die kontrollierte Liste (`DealerBrokerContract`, `LiabilityInsurance`, `FinancialGuarantee`, `WasteAnalysis`, `FacilityPermit`, `TakebackInformation`, …). Nicht `mimeCode`: das ist ein freies Pflicht-Textfeld ohne Allowlist.
`ATTACHMENT_TYPE_OTHER`	`waste.error.attachment.type.other.no.comment`	Zur Klassifikation „Sonstiges” fehlt der erläuternde Kommentar.	—
`ATTACHMENT_FILE_EMPTY`	`waste.error.invalid.attachment.file`	Der Anhang hat keinen Inhalt.	—
`LINKED_ATTACH_NOT_FOUND`	`to.be.created`	Ein verknüpfter Anhang wurde nicht gefunden.	In der Quelle steht hinter dem Code ein abgeschnittenes Codefragment (`(Builder.warning(i18n`) — ein Artefakt der Liste, kein Teil des Codes.
`ATTACH_INDICATOR_NOT_MATCH`	`to.be.created`	Der Anhang-Indikator passt nicht zu den tatsächlich angehängten Dateien.	Artefakt in der Quelle wie bei `LINKED_ATTACH_NOT_FOUND`.

Nummern und Formate¶

Code	Label	Bedeutung	Ursache und Auflösung
`INVALID_NOTIFICATION_CA_CODE_PREFIX`	`invalid.notification.ca.code.prefix`	Der Präfix der Notifizierungsnummer passt nicht zum übergebenen Behörden-Code.	Die Notifizierungsnummer ist aufgebaut als `<CA-Code><JJ><Laufnummer>i`, Beispiel `BE0125000538i`. Der Präfix ist der Code der zuständigen Behörde am Versandort — im Dokument `ExportState.CompetentAuthority.CompetentAuthorityID`, in der Oberfläche Block 15 b, Spalte Ausfuhr-/Versandstaat. Die Nummer ist damit erst anforderbar, wenn dieser Block befüllt ist. Achtung auf die Länge: DiWaSS führt Behörden-Codes vier- und fünfstellig (`DE01` neben `DE014`); die vergebene Nummer trägt nicht zwingend den vollen Code des Dokuments.
`INVALID_NOTIFICATION_FORMAT`	`invalid.notification.format`	Die Notifizierungsnummer hat ein unzulässiges Format.	Format wie oben.
`DUPLICATED_NUMBER`	`waste.notification.number.already.exist`	Die Notifizierungsnummer ist bereits vergeben.	Nicht ohne neue Nummer wiederholen — ein erneuter Aufruf mit derselben Nummer scheitert identisch.
`NUMBER_EMPTY`	`waste.notification.number.empty`	Die Notifizierungsnummer fehlt, ist hier aber Pflicht.	—
`NUMBER_IS_NOT_EMPTY`	`waste.notification.number.not.empty`	Es ist eine Notifizierungsnummer gesetzt, obwohl hier keine stehen darf.	Tritt beim Anlegen auf, wenn die Nummer erst vom Server vergeben werden soll.
`NOTIFICATION_NUMBER_NOT_PRESENT`	`to.be.created`	Die Notifizierungsnummer fehlt.	—
`NOTIFICATION_NUMBER_IS_NOT_EMPTY`	`to.be.created`	Es ist eine Notifizierungsnummer gesetzt, obwohl keine stehen darf.	—
`SUBMISSION_MUST_EXIST`	`waste.notification.number.not.exist`	Zur angegebenen Nummer existiert keine Einreichung.	—
`MOVEMENT_MUST_EXIST`	`waste.movement.number.do.not.exist`	Zur angegebenen Nummer existiert kein Begleitformular.	Zwei Nummernformate nicht verwechseln: die ZEDAL-Transportpapiernummer `<NotificationId>.<Sequenz>` ohne `MOV` und die DiWaSS-Movement-Id `<NotificationId>.<Sequenz>MOV`. Die Sequenznummer wird nicht serverseitig reserviert; sie kommt über `GetNextMovementSequenceNumber(notificationId)`.
`TRANSPORT_MUST_EXIST`	`waste.transport.number.do.not.exist`	Zur angegebenen Nummer existiert keine Beförderung.	—
`CERTIFICATE_MUST_EXIST`	`waste.certificate.number.do.not.exist`	Zur angegebenen Nummer existiert kein Zertifikat.	—
`INVALID_ANNEX7_NUMBER_PREFIX`	`invalid.annex7.prefix`	Der Präfix der Annex-VII-Nummer ist unzulässig.	—
`INVALID_ANNEX7_NUMBER_FORMAT`	`invalid.annex7.format`	Die Annex-VII-Nummer hat ein unzulässiges Format.	—
`ANNEX7_NUMBER_NOT_FOUND`	`annex7.not.found`	Zur Annex-VII-Nummer existiert kein Dokument.	—
`ANNEX7_NUMBER_SEQUENCE_NOT_FOUND`	`annex7.sequence.not.found`	Die Sequenz der Annex-VII-Nummer wurde nicht gefunden.	—
`ANNEX7_NUMBER_SEQUENCE_LENGTH_ISSUE`	`annex7.sequence.length.issue`	Die Sequenz der Annex-VII-Nummer hat eine unzulässige Länge.	—
`MISSING_LANGUAGE_DESCRIPTION`	`missing.language.description`	Zu einem mehrsprachigen Feld fehlt die Sprachangabe.	—
`INVALID_LANGUAGE_DESCRIPTION`	`invalid.language.description`	Die Sprachangabe ist unzulässig.	—

Lebenszyklus und Reihenfolge¶

Code	Label	Bedeutung	Ursache und Auflösung
`SUBMISSION_DOC_EMPTY`	`waste.notification.invalid.submission.document`	Das Einreichungsdokument fehlt oder ist leer.	—
`DECISION_MUST_EXIST`	`waste.decision.not.exist`	Der Vorgang setzt eine Entscheidung voraus, es gibt keine.	—
`DECISION_ALREADY_EXIST`	`waste.decision.already.exist`	Für diese Behörde liegt bereits eine Entscheidung vor.	—
`DECISION_TYPE_EMPTY`	`waste.error.invalid.decision.type`	Die Art der Entscheidung fehlt.	—
`DECISION_DATE_EMPTY`	`waste.error.invalid.decision.date`	Das Datum der Entscheidung fehlt.	—
`DECISION_DOC_EMPTY`	`waste.error.invalid.decision.document`	Das Entscheidungsdokument fehlt.	—
`DECISION_TACIT_ONLY_FOR_TRANSIT`	`waste.error.invalid.tacit.decision`	Eine stillschweigende Zustimmung ist nur für die Durchfuhr zulässig.	Versand- und Bestimmungsbehörde müssen ausdrücklich entscheiden.
`ACKNOWLEDGMENT_DATE_EMPTY`	`waste.error.invalid.ack.date`	Das Datum der Empfangsbestätigung fehlt.	—
`ACKNOWLEDGMENT_DOC_EMPTY`	`waste.error.invalid.ack.document`	Das Dokument zur Empfangsbestätigung fehlt.	—
`INVOLVED_PARTY_HAS_PROVIDED_ACKNOWLEDGE`	`involved.party.has.provided.acknowledge`	Die Partei hat bereits bestätigt.	—
`INVOLVED_PARTY_HAS_PROVIDED_DECISION`	`involved.party.has.provided.decision`	Die Partei hat bereits entschieden.	—
`HAS_REQUEST_INFORMATION_OPEN`	`has.request.information.open`	Es ist noch eine Nachforderung offen.	Eine offene Nachforderung blockiert den weiteren Ablauf. Fallstrick bei der Zustandsbestimmung: die Antwort auf eine Nachforderung steht in der `requestInformation`-Liste, nicht in `replyRequestInformation` — die bleibt leer. Bestimme den Zustand nie über die Länge dieser Listen, sondern über die Followup-Intents.
`REQUEST_INFORMATION_MUST_EXIST`	`request.information.must.exist`	Der Vorgang setzt eine Nachforderung voraus.	—
`REQUEST_INFORMATION_ID_IS_MANDATORY`	`request.information.id.is.mandatory`	Die Id der Nachforderung fehlt.	—
`REQUEST_CHANGE_MUST_EXIST`	`request.change.must.exist`	Der Vorgang setzt einen Änderungsantrag voraus.	—
`REQUEST_CHANGE_ID_IS_MANDATORY`	`request.change.id.is.mandatory`	Die Id des Änderungsantrags fehlt.	—
`REQUEST_CHANGE_ROUTE_IS_MANDATORY`	`request.change.route.is.mandatory`	Beim Änderungsantrag fehlt die Routenangabe.	—
`REQUEST_CONTENT_IS_MANDATORY`	`request.content.is.mandatory`	Der Inhalt des Antrags fehlt.	—
`CA_ROLE_IS_MANDATORY`	`ca.role.is.mandatory`	Die Rolle der Behörde fehlt.	—
`AGREEMENT_IS_MANDATORY`	`agreement.is.mandatory`	Die Zustimmung fehlt.	—
`CONDITION_NOT_MET`	`condition.not.met`	Eine Vorbedingung des Vorgangs ist nicht erfüllt.	Generischer Reihenfolgefehler. Der begleitende Meldungstext nennt die Bedingung.
`OPERATORS_CANNOT_CHANGE`	`to.be.created`	Die Betreiber dürfen in diesem Zustand nicht geändert werden.	Nach Konsens ist das Dokument gesperrt. Ein Änderungsfenster öffnet sich erst wieder durch eine behördliche Nachforderung oder einen Änderungsantrag.
`AUTHORITIES_CANNOT_CHANGE`	`to.be.created`	Die Behörden dürfen in diesem Zustand nicht geändert werden.	Wie oben.
`DESTINED_REQUIRED`	`waste.notification.destined.required`	Die Angabe zum Bestimmungszweck fehlt.	—
`DESTINED_PRE_CONSENT_REQUIRED`	`waste.notification.destined.pre.consent.required`	Die Angabe zur Vorabzustimmung fehlt.	—
`DUE_TAKEBACK_REQUIRED`	`waste.notification.due.takeback.required`	Die Angaben zur Rücknahme fehlen.	—
`DUE_ILLEGAL_SHIPMENT_REQUIRED`	`waste.notification.due.illegal.shipment.required`	Die Angaben zur illegalen Verbringung fehlen.	—
`PROP_CARRIED_OUT_EMPTY`	`waste.notification.invalid.properly.carried.out`	Die Bestätigung der ordnungsgemäßen Durchführung fehlt.	—
`MOVEMENT_TEMPLATE_INVALID_DOCUMENT`	`waste.error.mov.template.invalid.document`	Das Begleitformular ist in diesem Zusammenhang unzulässig.	—
`MULTIPLE_DOC_FOR_CARRIER`	`waste.error.multiple.documents.same.carrier`	Für denselben Beförderer liegen mehrere Dokumente vor.	—
`NOTIFICATION_SCENARIO_NOT_PRESENT`	`to.be.created`	Das Verbringungsszenario ist nicht angegeben.	—
`BAD_REQUEST_NOTIFIER`	`bad.request.notifier.and.role`	Notifizierender und Rolle passen nicht zusammen.	Tritt auf, wenn beim Anlegen einer Einreichung bereits eine Notifizierungsnummer im Dokument steht. Setz beim Anlegen keine Nummer, außer du hast sie vorher über den Reservierungsweg erhalten. Bleibt die Nummer weg, vergibt DiWaSS sie selbst.

Berechtigungen und Benutzerkontext¶

Code	Label	Bedeutung	Ursache und Auflösung
`WASTE_UNKNOWN`	`waste.unknown`	Unspezifizierter Fehler.	Sammelcode. Der begleitende Meldungstext ist hier die einzige Information.
`WASTE_ACTION_NOT_ALLOWED`	`waste.user.cannot.execute.action`	Der Benutzer darf diese Aktion nicht ausführen.	—
`WASTE_CREATE_NOT_ALLOWED`	`waste.user.cannot.create.notification`	Der Benutzer darf keine Notifizierung anlegen.	—
`WASTE_UPDATE_NOT_ALLOWED`	`waste.user.cannot.update.notification`	Der Benutzer darf die Notifizierung nicht ändern.	—
`WASTE_DELETE_NOT_ALLOWED`	`waste.user.cannot.delete.notification`	Der Benutzer darf die Notifizierung nicht löschen.	—
`USER_OPERATION_NOT_ALLOWED`	`to.be.created`	Die Operation ist für diesen Benutzer nicht zulässig.	—
`USER_CONTEXT_IS_REQUIRED`	`to.be.created`	Der Benutzerkontext fehlt.	—
`USER_HAS_TO_BELONG_TO_OPERATOR`	`to.be.created`	Der Benutzer muss dem Betreiber zugeordnet sein.	—
`UPDATE_USER_IS_NOT_USER_CREATOR`	`to.be.created`	Nur der Ersteller darf ändern.	—
`INSUFFICIENT_USER_PERMISSIONS`	`waste.insufficient.user.permissions`	Die Berechtigungen reichen nicht aus.	—
`USER_AUTHORISATION_PERMISSION_AUTHORITY_DENIED`	`waste.user.authorisation.permission.authority.denied`	Zugriff verweigert — die Berechtigung deckt das Objekt nicht ab.	Tritt u. a. beim Abruf eines fremden Anhangs auf: die Anhang-Id allein genügt nicht, die Zugangsdaten müssen zum Betreiber passen.
`USER_AUTHORISATION_REQUESTS_NOT_FOUND`	`waste.user.authorisation.requests.not.found`	Es liegen keine Berechtigungsanträge vor.	—
`USER_AUTHORISATION_REQUESTS_VALIDATION_ERRORS`	`waste.user.authorisation.requests.validation.errors`	Die Berechtigungsanträge enthalten Validierungsfehler.	—
`CURRENT_PARTY_NOT_ALLOWED_ACT_ON_BEHALF`	`waste.current.party.cannot.act.on.behalf`	Die aufrufende Partei darf nicht in Vertretung handeln.	—
`ON_BEHALF_CA_MUST_EXIST`	`waste.onbehalf.ca.must.exist`	Bei Handeln in Vertretung fehlt die vertretene Behörde.	—
`ON_BEHALF_CA_MUST_EXIST_IN_DOCUMENT_CONTENT`	`waste.onbehalf.ca.must.exist.in.document.content`	Die vertretene Behörde muss auch im Dokumentinhalt stehen.	—
`ON_BEHALF_OPERATOR_MUST_EXIST_IN_DOCUMENT_CONTENT`	`waste.onbehalf.operator.must.exist.in.document.content`	Der vertretene Betreiber muss auch im Dokumentinhalt stehen.	—
`INVOLVED_PARTY_MUST_EXIST_IN_DOCUMENT_CONTENT`	`waste.involved.party.must.exist.in.document.content`	Die beteiligte Partei muss im Dokumentinhalt stehen.	—
`INVOLVED_PARTY_IS_NOT_AN_OPERATOR_OF_THE_REQUIRED_TYPE`	`involved.party.is.not.an.operator.of.the.required.type`	Die beteiligte Partei hat nicht den geforderten Betreibertyp.	—
`IMPORT_SCENARIO_USER_PROFILE_NOT_ALLOWED`	`to.be.created`	Das Benutzerprofil ist für das Import-Szenario nicht zugelassen.	—
`EXTRA_EU_SCENARIO_USER_PROFILE_NOT_ALLOWED`	`to.be.created`	Das Benutzerprofil ist für Verbringungen außerhalb der EU nicht zugelassen.	—
`ENTITY_NOT_FOUND`	`waste.error.entity.not.found`	Das referenzierte Objekt existiert nicht.	Generischer Nicht-gefunden-Code.

Annex VII (grüne Liste)¶

Code	Label	Bedeutung	Ursache und Auflösung
`GREEN_LISTED_DOCUMENT_NOT_FOUND`	`waste.green.listed.document.not.found`	Das Annex-VII-Dokument wurde nicht gefunden.	—
`GREEN_LISTED_MOVEMENT_MUST_EXIST`	`waste.green.listed.movement.number.do.not.exist`	Zur Nummer existiert keine Annex-VII-Verbringung.	—
`GREEN_LISTED_CARRIER_TRANSPORT_MUST_EXIST`	`waste.green.listed.carrier.transport.number.do.not.exist`	Zur Nummer existiert keine Beförderung.	—
`GREEN_LISTED_CONSIGNEE_RECEPTION_MUST_EXIST`	`waste.green.listed.consignee.reception.number.do.not.exist`	Zur Nummer existiert kein Empfang durch den Empfänger.	—
`GREEN_LISTED_FACILITY_RECEPTION_MUST_EXIST`	`waste.green.listed.facility.reception.number.do.not.exist`	Zur Nummer existiert kein Anlagenempfang.	—
`GREEN_LISTED_FACILITY_COMPLETION_MUST_EXIST`	`waste.green.listed.facility.completion.number.do.not.exist`	Zur Nummer existiert keine Abschlussbescheinigung der Anlage.	—
`GREEN_LISTED_TAKE_BACK_CERTIFICATE_MUST_EXIST`	`waste.green.listed.take.back.certificate.number.do.not.exist`	Zur Nummer existiert keine Rücknahmebescheinigung.	—

Codes aus Beispielantworten der Spezifikation¶

Diese beiden Codes stehen nicht in der Validierungsliste, kommen aber in den Beispielantworten der Spezifikation vor. Ihr Wortlaut ist damit belegt, ihre genaue Auslösebedingung nicht.

Code	Bedeutung	Beleg
`MANDATORY_ELEMENT_MISSING`	Ein Pflichtelement fehlt. Die Beschreibung nennt Element und Block, im Beispiel: `actualQuantity` in Block 3 des Annex VII.	Beispielantwort mit `statusCode = NOTOK`
`OPTIONAL_ATTACHMENT_MISSING`	Anhang-Referenzen wurden erwartet, aber keine gefunden. Steht als Warnung, nicht als Fehler.	dieselbe Beispielantwort, in `warnings`

MANDATORY_ELEMENT_MISSING ist der Sammelcode für fehlende Pflichtelemente. Die eigentliche Information steht in der description — die trägt den Elementnamen und den Block. Zeige sie dem Anwender unverkürzt an.

Unbekannter Fehlercode¶

Die Spezifikationsliste ist unvollständig, und DiWaSS erweitert ihre Prüfungen laufend. Trifft dich ein Code, der hier nicht steht, ist das kein Fehler deiner Integration.

Behandle ihn als gültige Ablehnung — nicht als Fehlschlag der Verarbeitung. Konkret:

Nicht automatisch wiederholen. Die EU-Vorgabe ist eindeutig: ein an fehlerhaften Daten gescheiterter Aufruf darf ohne Korrektur der Daten nicht erneut abgesetzt werden.
Code und Meldungstext unverändert protokollieren und dem Anwender anzeigen. Ein unbekannter Code mit Klartext ist für ihn brauchbarer als „Übermittlung fehlgeschlagen”.
Kein Mapping auf einen Ersatzcode und keine stille Unterdrückung.

Und melde ihn uns. Nur so wächst diese Seite. Nützlich sind:

Angabe	Warum
Code und Meldungstext, unverändert	die Schreibweise ist Teil der Information
ausgelöste Operation	verortet die Prüfung im Ablauf
Zeitpunkt (UTC) und Zielsystem	ermöglicht die serverseitige Zuordnung
ZEDAL-Dokument-Id	verortet den konkreten Vorgang
ob `errors` oder `warnings`	entscheidet, ob es eine Ablehnung war

BMU¶

Die BmuDocumentApi meldet Fehler als gRPC-Status, über REST als HTTP-Status nach der Tabelle oben. So sehen die bekannten Fälle aus:

Situation	Status	Detail
`UpdateDocument` ohne `doc_xml`	`CANCELLED`	leer
`CreateDocument` mit unvollständigem Begleitschein bei voller Prüfung	`CANCELLED`	leer
`CreateDocument` für einen Übernahmeschein ohne ATB-Rolle	`CANCELLED`	leer
`AddLayer` auf einem Übernahmeschein	`CANCELLED`	leer
Jeder Aufruf mit `doc_xml`, das sich nicht als BMU-Dokument laden lässt	`INTERNAL`	technische Meldung des Formats

CANCELLED kommt hier vom Server

In diesen Fällen hat der Dienst die Anfrage abgelehnt, dein Client hat nichts abgebrochen. Das Detail ist leer, die Fälle lassen sich an der Antwort also nicht unterscheiden. Prüf deine Anfrage gegen die Tabelle: XML mitgeschickt, Prüfstufe passend (XmlOptions), ATB-Rolle gesetzt, Layer nur beim Begleitschein. Über REST kommt CANCELLED als HTTP 499 an.