Zum Inhalt

Feldregeln

Diese Seite sammelt die Regeln, die DiWaSS serverseitig durchsetzt, die aber nicht aus dem Schema hervorgehen: Nummernformate, kontextabhängige Schreibweisen, Pflichten jenseits von minOccurs, Querbezüge zwischen Dokumentteilen und die Anlagenkette. Die Formate für BMU-Begleit- und Übernahmescheine stehen im Abschnitt BMU; sie folgen aus dem BMU-Schema bzw. den Protos.

Sie richtet sich an dich, wenn du eine clientseitige Vorprüfung baust oder die Ursache einer Ablehnung suchst.

Nicht hier, sondern auf den Nachbarseiten:

  • Wertelisten (Abfallcodes, listID, R-/D-Codes, Verpackungsart, typeID) — Codelisten
  • Bedeutung, Schreibweise und Auswertung der Fehlercodes — Fehlercodes

Warum das Schema nicht als Validierungsgrundlage taugt

Das DiWaSS-XSD und die daraus abgeleiteten Protos beschreiben die Struktur eines Dokuments. Sie beschreiben nicht die Regel, gegen die DiWaSS prüft. Die Abweichung geht in beide Richtungen:

Richtung Beispiel Was das Schema sagt Was DiWaSS tut
Server strenger CertificateOfWasteReceiptType.RejectedQuantity (Movement-Empfang) minOccurs=0 lehnt ohne das Feld ab (REJECTED-QUANTITY-EMPTY)
Server strenger CertificateOfWasteReceiptType.RejectionDescription minOccurs=0, Anmerkung: „Only filled in case of partial rejection” lehnt ohne das Feld ab (REJECTION-DESCRIPTION-EMPTY)
Schema strenger / irreführend WasteCodeType.@listID Schema-Anmerkung nennt EWL, BASEL, YCODE als Beispielwerte nimmt diese alten Werte nicht mehr an — die gültigen Tokens sind andere (Codelisten)
Schema strenger / irreführend AttachmentBinaryObject.@mimeCode Token64, use="required", Doku-Beispiel "image/png" keine MIME-Allowlist; die kontrollierte Liste ist typeID

Das Gegenbeispiel steckt im selben Schema: RejectedQuantity heißt im Annex-VII-Zweig genauso, sitzt dort aber an Annex7CertificateOfWasteReceiptType und ist minOccurs=1. Der Unterschied zwischen den beiden Dokumentarten ist also gewollt — nur ist er im Movement-Schema nicht abgebildet.

Konsequenz für die Client-Validierung

Eine Vorprüfung, die ausschließlich minOccurs/maxOccurs auswertet, lässt Dokumente durch, die DiWaSS ablehnt. Die harten Regeln stehen in den Fehlercodes, nicht im Schema — und die Validierungsliste der Spezifikation ist dabei nicht vollständig. Siehe Fehlercodes.

Über die API gibt es keinen Entwurfs-Zwischenschritt

Das ist der Grund, warum dich so viele Prüfungen gleich beim ersten Aufruf treffen. Die EU-Prozessbeschreibungen sind an dieser Stelle eindeutig:

Weg Zustand nach dem Anlegen
Oberfläche Notifizierung DRAFT, Movement DRAFT — darf unvollständig gespeichert werden
API Notifizierung SUBMITTED, Movement ANNOUNCED

Alles, was die Oberfläche erst beim Absenden prüft, prüft DiWaSS für einen API-Aufrufer sofort. Ein „erst mal anlegen und später vervollständigen” gibt es über die Schnittstelle nicht.

Schreibweise der Fehlercodes

Auf dieser Seite stehen die Codes durchgängig in der Bindestrich-Form, wie DiWaSS sie zur Laufzeit meldet. Die EU-Validierungsliste führt dieselben Codes mit Unterstrich. Details und Normalisierung: Fehlercodes → Schreibweise.

Identifikatoren und Nummernformate

Notifizierungsnummer

Aufbau: <CA-Code><JJ><Laufnummer>i.

Bestandteil Beispiel aus dem Spezifikations-Sample Beispiel
CA-Code BE01 DE01
Jahr, zweistellig 25 26
Laufnummer 000538 999901
Suffix i i
Ergebnis BE0125000538i DE0126999901i

Das Schema erzwingt davon nichts: model:NotificationIdentifierType ist ein Token mit maxLength=100 und ohne Pattern. Die Schema-Anmerkung nennt lediglich eine Konvention — die Nummer beginne „by convention” mit dem ISO-3166-1-alpha-2-Kürzel des Versandstaats. Geprüft wird gegen den vollständigen Behördencode.

Erzeugen und prüfen übernimmt die DiWaSS-Operation validateAndGenerateNotification. Ihr Request hat genau ein Pflichtfeld — caCode — plus optional die zu prüfende NotificationID. Passt der Präfix nicht zum Code, antwortet DiWaSS mit statusCode=NOTOK und INVALID-NOTIFICATION-CA-CODE-PREFIX („Invalid CA code in notification number”).

Welche Behörde den Code stellt, sagt die Spezifikation nicht. Sie spricht nur von „a valid number based on the provided CA code”. Maßgeblich ist die zuständige Behörde am Versandort — im Dokument Submission.ExportState.CompetentAuthority.CompetentAuthorityID, im Notifizierungsformular Block 15 b, Spalte Ausfuhr-/Versandstaat. Solange der Notifizierende bei seiner Versandbehörde registriert ist, fällt der Unterschied zur Registrierungsbehörde nicht auf; im Randfall schon.

Behördencodes gibt es in zwei Längen

DiWaSS führt Behördencodes vierstellig (DE01) und fünfstellig (DE014) — beide kommen im selben Bestand vor, im Notifizierungsformular steht typischerweise die fünfstellige Form, die vergebene Nummer trägt die vierstellige. Ein naives StartsWith kann die beiden Längen nicht auseinanderhalten und ordnet eine Nummer der falschen Behörde zu. Vergleiche nicht auf Präfix, sondern nimm aus allen passenden Kandidaten den längsten.

MovementId und ZEDAL-Transportpapiernummer

Für dieselbe fachliche Sequenz gibt es zwei Formate. Sie sind nicht austauschbar.

Nummer Format Beispiel Vergeben von
DiWaSS-MovementId <NotificationId>.<Sequenz>MOV DE0126999901i.000001MOV DiWaSS beim Anlegen des Movement-Templates
ZEDAL-Transportpapiernummer <NotificationId>.<Sequenz> — fünfstellig, ohne MOV DE0126999901i.00002 ZEDAL

Das stabile Handle innerhalb von ZEDAL ist die ZEDAL-DocumentId, nicht die MovementId: Ein DiWaSS-Movement lebt in genau einem ZEDAL-Dokument, in dem alle Lebenszyklus-Phasen (Announcement, Carrier-Transport, Consignee-Reception, Facility-Reception, Facility-Completion) als Blöcke liegen. Die MovementId existiert erst nach dem ersten Push und ist darauf nur ein Index-Attribut. Halte über mehrstufige Abläufe hinweg die DocumentId fest.

SequenceNumber

MovementDocumentType.SequenceNumber ist Pflicht (minOccurs=1) und vom Typ model:PositiveInteger8 — eine positive Ganzzahl mit höchstens acht Stellen. Sie zählt die Verbringungen innerhalb einer Notifizierung, beginnend bei 1.

Die XSD-Anmerkung des Felds ist eindeutig: „A sequence number typically must not be reused. This also applies when shipments of waste are cancelled. The number of the cancelled shipment must not be reused for a new shipment.”

Es gibt keinen Reservierungsweg für Movement-Sequenzen

Für Notifizierungsnummern existiert ein serverseitiger Vergabeweg. Für Movement-Sequenzen nicht — die Nummer bestimmt der Client. Wer sie fest verdrahtet, kollidiert beim zweiten Lauf auf derselben Notifizierung.

Im .NET-SDK ermittelt client.DocumentNumbers.GetNextMovementSequenceNumber(notificationId) die nächste freie Nummer aus der Liste der Transportdokumente (QueryApi): Filter auf doc.notification_id, höchstes numerisches Suffix + 1; 1, wenn noch keine existiert. Lege Movements einer Notifizierung deshalb nacheinander an.

Beachte die unterschiedliche Stellenzahl: Das DiWaSS-Dokument erlaubt bis zu acht Stellen, die ZEDAL-Transportpapiernummer trägt die Sequenz fünfstellig.

Operator-Identifikatoren

Jede Partei im Dokument ist ein WasteOperatorType und trägt zwei Pflichtangaben:

Feld Typ Bedeutung
PartyUUID model:UuidType (Pattern-geprüft), minOccurs=1 technische Kennung der Partei
OperatorInternalID xs:long, minOccurs=1 Kennung des Beteiligten im DiWaSS-Operator-Verzeichnis

Ein Name genügt nicht. Die OperatorInternalID musst du vorher im Verzeichnis auflösen. Das .NET-SDK bietet dafür IOperatorApi an: FindOperatorForEori(eori), FindOperatorByIdentifier(id, type), FindOperatorByName(name, countryId), FindOperatorByQuery(query, countryId) und GetOperatorById(operatorId) für die Details. Der Suchraum ist dabei zentral auf den Abfallbereich (Activity.Section = "WSR") begrenzt.

Zulässige Identifikator-Typen für die Suche:

Typ Wire-Wert Herkunft
EORI eori model:TracesPartyIdentificationSchemeIdentifierType
VAT (USt-IdNr.) vat model:PartyIdentificationSchemeIdentifierType
NTR (Handelsregister) ntr model:PartyIdentificationSchemeIdentifierType
GLN (GS1) gln model:PartyIdentificationSchemeIdentifierType

Das Attribut @type ist im XSD ein freier xs:token ohne Restriction. In den Spec-Samples sind die Werte durchgängig kleingeschrieben.

Fehlerbilder rund um Operator-Kennungen: OPERATOR-ID-NOT-FOUND, DUPLICATE-OPERATOR-ID sowie die rollenspezifischen CARRIER-OPERATOR-DUPLICATE, WASTE-PRODUCER-OPERATOR-DUPLICATE, TREATMENT-FACILITY-OPERATOR-DUPLICATE. Dieselbe Kennung mehrfach in derselben Rolle führt also zur Ablehnung.

Anhang-Kennungen

Eine zentrale DiWaSS-Attachment-Id hat die Form <Ziffern>ATT, zum Beispiel 26000099901ATT.

ZEDAL_TMP_ATT_ID_… ist keine DiWaSS-Kennung

Sieht die zurückgegebene Kennung aus wie ZEDAL_TMP_ATT_ID_<n>_<m>, ist das eine temporäre ZEDAL-Zwischenablage-Kennung. Sie trägt nur für einen Abruf über denselben Weg. Als attachmentIdentifier an einem DiWaSS-Dokument quittiert DiWaSS sie mit ATTACHMENT-NOT-FOUND. Eine zentrale Kennung liefert der Raw-SOAP-Weg (ISoapProxyApi) auf die DiWaSS-Operation submitAttach.

Ein Anhang lässt sich erst abrufen, wenn er an einem Dokument hängt. Ein Abruf auf einen fremden Anhang antwortet mit USER-AUTHORISATION-PERMISSION-AUTHORITY-DENIED — die Id allein genügt also nicht, die Berechtigung muss zum Operator passen.

Formate mit Kontextabhängigkeit

Ländercode — zwei Formate, zwei Fehlerbilder

Derselbe fachliche Wert hat je nach Aufrufstelle ein anderes Format. Das ist die häufigste Falle überhaupt, weil beide Fehlerbilder auf dieselbe falsche Diagnose führen: „die Behörde gibt es nicht”.

Kontext Format Beispiel Belgien Bei falscher Form
CountryID im Dokument (model:CountryCodeType, Pattern \d\d\d) ISO 3166-1 numerisch, dreistellig mit führender Null 056 Abweisung schon am Schema: SOAP Fault, cvc-pattern-valid: Value '56' is not facet-valid with respect to pattern '\d\d\d'. Die Fachlogik wird nie erreicht.
Verzeichnis-Lookup (FindActivities, ListAuthorities) ISO 3166-1 alpha-2 BE 0 Treffer, kein Fehler, keine Exception.

Beispiel: FindActivities("BE", code: "BE01") liefert einen Treffer, FindActivities("056", code: "BE01") und FindActivities("56", …) jeweils keinen.

Der SDK-Validator schützt dich hier nicht

CountryIdValidator.Validate(...) lässt beide Formen durch — alpha-2 und dreistellig numerisch. Er prüft nur, dass überhaupt eine der beiden vorliegt. Die Verwechslung zwischen den Kontexten kann er nicht erkennen. Ein Wert wie "56" ist keine von beiden und fällt durch.

Wertetabelle und weitere Schreibweise-Fallen: Codelisten → Ländercode.

Abfallschlüssel

Der Codewert selbst ist im Schema völlig ungeprüft: WasteCodeType erweitert model:Token64OrEmpty — freier Token, höchstens 64 Zeichen, kein Pattern, keine Enumeration. Auch das Attribut listID ist inzwischen eine leere Restriction auf xs:token. Beides validiert DiWaSS erst serverseitig gegen das Repository.

Die praktisch wichtigste Regel: EU-Abfallschlüssel gehören mit Gruppen-Leerzeichen ins Feld — 01 03 06, nicht 010306; gefährliche zusätzlich mit Stern (01 04 07*). Alles Weitere zu Werten, Listen-Tokens und Groß-/Kleinschreibung steht in den Codelisten.

Mengen

Aspekt Regel
Struktur model:MassVolumeMeasureType hat zwei Kinder: MassMeasure und VolumeMeasure — beide minOccurs=0. Eine strukturell leere Menge ist schema-valide.
Einheiten Es gibt kein Einheiten-Feld. Masse ist immer in Tonnen, Volumen immer in Kubikmetern.
Zahlformat model:Decimal25Fraction5Type — höchstens 25 Stellen insgesamt, höchstens 5 Nachkommastellen.

Die Spezifikationsliste führt für fehlende Mengenangaben MASS-VOLUME-NOT-FOUND.

Freitexte sind mehrsprachig

Jedes Beschreibungsfeld ist ein DescriptionType — eine Liste von Description-Einträgen, jeder mit einem languageID-Attribut. Zwei Details, die im Schema locker und serverseitig streng sind:

Aspekt Schema Praxis
languageID optionales Attribut, Pattern [a-z][a-z] — also kleingeschrieben, de nicht DE DiWaSS führt MISSING-LANGUAGE-DESCRIPTION und INVALID-LANGUAGE-DESCRIPTION
Textlänge model:String1024 — höchstens 1024 Zeichen, mindestens 1 längere Texte fallen bereits am Schema

Datums- und Zeitfelder

Datumsfelder sind xs:date ohne Zeitanteil — StartDate, ReceiptDate, CompletionDate, RecoveryDisposalApproximateDate, DecisionDate. Nur der Signaturzeitpunkt (SignatureType.timestamp) ist ein xs:dateTime.

„Werktag“ heißt Montag bis Freitag

Wenn du Fristen aus der Verbringungsverordnung im Client vorrechnest: Der Begriff „Werktag” bzw. „working day” bedeutet dort Montag bis Freitag, nicht der deutsche Rechtsbegriff aus § 193 BGB, der den Samstag einschließt. Die Verordnung definiert ihn nicht; die deutsche Fassung übersetzt dieselbe englische Wendung „working days” mal als „Werktage”, mal als „Arbeitstage”. Maßgeblich ist VO (EWG, Euratom) Nr. 1182/71 Art. 2 Abs. 2 („alle Tage ausser Feiertagen, Sonntagen und Sonnabenden”), bestätigt durch die deutsche Vollzugspraxis (LAGA M25). Eine Mo–Sa-Zählung rechnet die Frist zu kurz.

Offen bleibt, wessen Feiertage gelten — bei Behörden in Versand-, Durchfuhr- und Bestimmungsstaat ist das nicht eindeutig, und innerhalb Deutschlands unterscheiden sie sich je Bundesland.

Anhänge: welches Feld ist wirklich kontrolliert

Ein Anhang (AttachmentBinaryObject) trägt vier Pflicht-Attribute. Nur eines davon ist eine kontrollierte Liste — und es ist nicht das, das man erwartet:

Attribut Typ Kontrolliert?
typeID BinaryAttachmentClassificationCodeType ja — echte XSD-Enumeration mit 27 Werten (FacilityPermit, LiabilityInsurance, FinancialGuarantee, WasteAnalysis, OtherAnnex, …). Fachliche Klassifikation des Dokuments, kein Dateiformat. Vollständige Liste: Codelisten
mimeCode Token64, use="required" nein — freier String, max. 64 Zeichen, keine Enumeration, kein Pattern. Das "image/png" in der Schema-Doku ist ein Beispiel, keine Beschränkung. Es gibt keine MIME-Allowlist.
filename NameType, max. 256 Zeichen, use="required" nein
containsPersonalData xs:boolean, use="required" —

Die Sammelkategorie unter den typeID-Werten verlangt eine zusätzliche Erläuterung: Die Spezifikationsliste führt ATTACHMENT-TYPE-OTHER mit dem Schlüssel waste.error.attachment.type.other.no.comment. In welchem Feld die Erläuterung erwartet wird, sagt die Spezifikation nicht.

Pflichtfelder jenseits des Schemas

Die folgenden Felder sind im XSD optional, werden von DiWaSS aber verlangt. Die Spalte Beleg unterscheidet, woher die Regel stammt:

  • Praxis — in der Praxis aufgetreten
  • Spezifikationsliste — Eintrag in der EU-Validierungsliste; der genaue Auslöser ist dort nicht beschrieben
Feld XSD-Kardinalität Serverregel Fehlercode Beleg
Submission.Notifier minOccurs=0 Pflicht NOTIFIER-OPERATOR-IS-REQUIRED Spezifikationsliste
Submission.Consignee minOccurs=0 Pflicht CONSIGNEE-OPERATOR-IS-REQUIRED Spezifikationsliste
Submission.Carrier minOccurs=0, maxOccurs=unbounded mindestens einer CARRIER-OPERATOR-IS-REQUIRED Spezifikationsliste
Submission.WasteProducer minOccurs=0, maxOccurs=unbounded mindestens einer WASTE-PRODUCER-OPERATOR-IS-REQUIRED Spezifikationsliste
Submission.ExportState minOccurs=0 Pflicht DISPATCH-IS-REQUIRED Spezifikationsliste
Submission.ImportState minOccurs=0 Pflicht DESTINATION-IS-REQUIRED Spezifikationsliste
PartyType.Contact je Beteiligtem minOccurs=0 Pflicht, rollenweise geprüft NOTIFIER-CONTACT-IS-REQUIRED, CONSIGNEE-CONTACT-IS-REQUIRED, PRODUCER-CONTACT-IS-REQUIRED, CARRIER-CONTACT-IS-REQUIRED, FACILITY-CONTACT-IS-REQUIRED Spezifikationsliste
Submission.ShipmentOriginAddress Element ist Pflicht, aber der Typ ist eine choice aus zwei optionalen Elementen — eine leere Struktur ist schema-valide inhaltlich Pflicht SHIPMENT-ORIGIN-ADDRESS-REQUIRED, daneben SHIPMENT-ORIGIN-ADDRESS-BAD und SHIPMENT-ORIGIN-ADDRESS-PARTY Spezifikationsliste
Submission.PhysicalCharacteristicDescription minOccurs=0 bedingt Pflicht PHYSICAL-CHARACTERISTICS-DESCRIPTION-REQUIRED Spezifikationsliste
LanguageDescriptionType.@languageID optionales Attribut Pflicht MISSING-LANGUAGE-DESCRIPTION Spezifikationsliste
CertificateOfWasteReceiptType.RejectedQuantity (Movement-Empfang) minOccurs=0 Pflicht REJECTED-QUANTITY-EMPTY Praxis
CertificateOfWasteReceiptType.RejectionDescription (Movement-Empfang) minOccurs=0, Anmerkung „nur bei Teilzurückweisung” Pflicht REJECTION-DESCRIPTION-EMPTY Praxis

Die letzten beiden Zeilen stehen in keiner Fassung der Spezifikationsliste

REJECTED-QUANTITY-EMPTY und REJECTION-DESCRIPTION-EMPTY sind in der Praxis aufgetreten und in der EU-Validierungsliste nicht enthalten. Rechne damit, dass weitere Codes fehlen, und behandle jeden unbekannten Code als gültige Ablehnung.

Felder, die man besser weglässt

ShipmentOriginAddress im Movement

Dasselbe Feld, zwei Dokumentarten, zwei Kardinalitäten:

Dokument Kardinalität
Notifizierung (SubmissionType.ShipmentOriginAddress) Pflicht
Movement (MovementDocumentType.ShipmentOriginAddress) minOccurs=0, maxOccurs=1

Ist das Feld im Movement gesetzt, gleicht DiWaSS es gegen die Absendeadresse der konsentierten Notifizierung ab und lehnt jede Abweichung mit MOVEMENT-SHIPMENT-ORIGIN-ADDRESS-MISMATCH-NOTIFICATION ab. Bleibt es weg, übernimmt DiWaSS die Adresse aus der Notifizierung und der Push geht durch.

Default: nicht setzen

Eine im Client fest verdrahtete Absendeadresse koppelt den gesamten Movement-Pfad an genau eine Notifizierung und bricht still, sobald deren Adresse abweicht oder auf eine andere Notifizierung umgestellt wird. Der Fehlertext nennt zwar „mismatch”, zeigt aber meist auf veraltete Stammdaten im Client, nicht auf ein kaputtes Movement.

movementIdentifier beim Anlegen

MovementTemplateType.movementIdentifier ist minOccurs=0. Beim Create lässt du es leer — DiWaSS vergibt die MovementId und gibt sie in der Antwort zurück (MovementTemplateOperationResponse.movementId). Beim Update muss es gesetzt sein.

Felder, die es nicht gibt

Abfallbezeichnung am Movement-Empfang

Die DiWaSS-Oberfläche verlangt am Movement-Empfang ein Pflichtfeld „Designation and composition of the waste received”. Über die Schnittstelle existiert dieses Feld dort nicht.

Typ Feld vorhanden?
Annex7CertificateOfWasteReceiptType (Annex VII) ja — WasteDesignationCompositionDescription, minOccurs=1
Annex7CertificateOfCompletionType (Annex VII) ja — wasteDesignationCompositionDescription
CertificateOfWasteReceiptType (Movement-Empfang) nein
CertificateOfWasteReceiptBaseType (Consignee-Empfang) nein — trägt nur RecipientParty, ReceiptDate, AdditionalInformation
TransportAnnouncementType (Movement-Ankündigung) nein

Das inhaltlich verwandte Feld im Movement-/Notifizierungszweig heißt SubmissionType.WasteDesignationDescription — ohne „Composition” — und sitzt an der Notifizierung (Pflicht, Block 12 Anhang IA), nicht am Empfangszertifikat. Die XSD-Annotation am Movement-WasteClassification verweist für Zusatzangaben ausdrücklich dorthin.

Kein einziger DiWaSS-Typ trägt beide Felder. Es ist also keine Typverwechslung, sondern eine Divergenz zwischen Oberfläche und Schnittstelle auf EU-Seite. Am Movement-Empfang lässt sich die Angabe nicht übermitteln.

Querbezüge, die der Server prüft

DiWaSS validiert nicht nur einzelne Felder, sondern Beziehungen zwischen Dokumentteilen und zwischen Dokumenten. Das Schema drückt keine davon aus.

Kontingent: Anzahl der Verbringungen

Submission.ShipmentQuantity (model:PositiveInteger8, Pflicht) ist laut XSD-Anmerkung „the total intended number of shipments under this notification” — Block 4 Anhang IA. Die Zahl der angelegten Begleitformulare darf diesen Wert nicht überschreiten.

Ein ordnungsgemäß annulliertes Formular zählt dabei nicht mit, ein liegengelassenes schon (DVO (EU) 2025/1290 Art. 17 Abs. 7 und 8). In Verbindung mit der Regel, dass Sequenznummern nicht wiederverwendet werden dürfen, heißt das: Annulliere sauber, statt Entwürfe liegenzulassen.

Fehlercode aus der Spezifikationsliste: MOVEMENT-TEMPLATE-INVALID-TOTAL-NUMBER.

Zuständigkeit der Durchfuhrbehörde

AUTHORITY-ID-NOT-FOUND ist eine Zuständigkeits-, keine Existenzaussage

Nicht jede WSR-Behörde darf Durchfuhrbehörde sein — und das Behördenverzeichnis sagt nicht, welche. Benennst du in Submission.TransitState eine Behörde ohne Durchfuhrzuständigkeit, lehnt DiWaSS die Notifizierung mit AUTHORITY-ID-NOT-FOUND: Authority <code> not found ab, obwohl die Behörde existiert und Status=VALID trägt.

Beispiel: BE004 und BE002 werden als Transit-CA angenommen, BE01 (OVAM) und BE003 abgelehnt. Am deutlichsten an DE014 — dieselbe Behörde wird im selben Dokument als Export- und Import-CA akzeptiert und als Transit-CA abgelehnt.

Das Verzeichnis hilft dabei nicht weiter: Alle belgischen Behörden liefern in FindActivities("BE") identische Activity-Daten. Transitfähige und nicht transitfähige Behörden sind darin nicht zu unterscheiden. Eine Behördenauswahl im Client kann die Eignung deshalb heute nicht vorab prüfen — der Fehler fällt erst beim Absenden auf. Plane die Ablehnung als normalen Ablauf ein, nicht als Ausnahme.

Zweiter, unabhängiger Weg zur selben Meldung: der numerische Ländercode im Verzeichnis-Lookup (siehe oben). Trenne bei so einem Symptom zuerst, welcher der beiden Pfade sie erzeugt hat.

R-/D-Kennung an vier Stellen

Die Unterscheidung Verwertung/Beseitigung steht in einem Vorgang mehrfach:

Stelle Feld Wertebereich
Notifizierung, Gesamtaussage Submission.DestinedForRecoveryDisposal R / D
Notifizierung, je Anlage RecoveryDisposalFacilityType.FacilityTypeCode R / D
Notifizierung, geplante Verfahren DisposalRecoveryOperations.RecoveryDisposalTypeCode (Pflicht, unbounded) R1–R13, D1–D15
Movement, Empfangszertifikat CertificateOfWasteReceiptType.FacilityTypeCode und .RecoveryDisposalTypeCode R/D bzw. R1–R13, D1–D15

Das Schema koppelt diese Stellen nicht — jede ist für sich valide. Die Spezifikationsliste führt DISPOSAL-RECOVERY-DOES-NOT-MATCH; welche der Stellen DiWaSS gegeneinander prüft, steht dort nicht. Halte sie konsistent.

Codeliste der R-/D-Verfahren: Codelisten.

Vorkonsentierte Anlage

Submission.PreConsentIndicator ist ein Pflicht-Boolean. Die Spezifikationsliste führt dazu zwei eigene Fehlercodes — DESTINED-PRE-CONSENT-REQUIRED und FACILITY-NOT-PRE-CONSENTED. Setze das Flag also nicht pauschal auf true; unter welchen Bedingungen die beiden Codes ausgelöst werden, beschreibt die Liste nicht.

Empfang und Abschluss gehören zur selben Anlage

Die Movement-Spezifikation ist eindeutig: „Completion must be done by/for the SAME facility which received.” Das Schema erzwingt das nicht. Empfangs- und Abschlusszertifikat haben getrennte Dokument-Ids und keinen Fremdschlüssel aufeinander.

Die Paarung musst du selbst herstellen — über RecipientParty ↔ RecoveryDisposalParty bzw. ActualSiteOfDisposalOrRecovery, nicht über Listenpositionen. Beide Listen sind im Retrieval unbounded; ihre Reihenfolge trägt keine Aussage.

Unveränderliche Angaben

Nach dem Anlegen einer Notifizierung lassen sich beteiligte Länder, beteiligte Behörden und der Notifizierende nicht mehr ändern — so die EU-Prozessbeschreibung. Fehlercodes: OPERATORS-CANNOT-CHANGE, AUTHORITIES-CANNOT-CHANGE.

Für alles Übrige gilt: Eine eingereichte Notifizierung ist nur änderbar, solange mindestens eine Nachforderung offen ist. Der zugehörige Code ist HAS-REQUEST-INFORMATION-OPEN. Details zum Änderungsfenster: Lebenszyklus.

In der Spezifikation offen

Ob DiWaSS den Carrier eines Movements gegen die Carrier-Liste der Notifizierung prüft, ist in der Spezifikation nicht beschrieben. Bekannt ist nur, dass TransportAnnouncement.Carrier im Movement Pflicht und unbounded ist, während Submission.Carrier in der Notifizierung schema-optional ist, und dass die Spezifikationsliste MULTIPLE-DOC-FOR-CARRIER (waste.error.multiple.documents.same.carrier) führt.

Anlagenkette

Eine DiWaSS-Notifizierung beschreibt keine einzelne Empfangsanlage, sondern eine Kette. Submission.RecoveryDisposalFacility ist minOccurs=1, maxOccurs=unbounded (Block 10) — die Notifizierung führt 1 + n Anlagen. Der Grund ist Art. 15 VO (EU) 2024/1157: Geht eine Verbringung zur vorläufigen Verwertung oder Beseitigung, müssen alle nachfolgenden Anlagen zusätzlich zur ersten im Formular angegeben werden.

Drei Booleans pro Anlage

An jeder Anlage hängt FacilityType.OperationalIndicators (FacilityOperationalIndicatorsType). Alle drei Felder sind Pflicht:

Indikator Bedeutung Folge
InterimFacility Die Anlage führt ein vorläufiges Verfahren durch Art. 15(1): Alle Anlagen, in denen die nachfolgende Behandlung vorgesehen ist, müssen zusätzlich zur ersten vorläufigen im Notifizierungsformular stehen
NextSubsequentInterimOrNonInterimFacilityInSameCountry Weitergabe an eine Anlage im Bestimmungsstaat Art. 15(5): keine neue Notifizierung, kein neues Movement. Der Nachweis kommt als Artikel-15-Bescheinigung an der Notifizierung zurück.
NextSubsequentInterimOrNonInterimFacilityInAnotherCountry Weitergabe in den Versandstaat, einen anderen Mitgliedstaat oder einen Drittstaat Art. 15(7)/(8): neue Notifizierung mit eigenen Movements

Der Auslandsfall ist ein neuer Vorgang, kein Folgeschritt

Innerhalb des Bestimmungsstaats verlängert sich die Kette nur dokumentarisch — es entstehen keine neuen Movements. Geht die Lieferung dagegen über die Grenze, brauchst du eine vollständig neue Notifizierung mit eigenem Nummernkreis, eigener Behördenbeteiligung und eigenen Movements.

Plane das im Datenmodell ein: Der Übergang ist keine Statusänderung an einem bestehenden Vorgang, sondern der Anfang eines zweiten. Ein Feld, das die neue Notifizierung ausdrücklich mit ihrer Vorgängerin verknüpft, ist in der Spezifikation nicht beschrieben — referenceNotificationId ist laut Schema-Anmerkung die von der Versandbehörde vergebene Nummer der Notifizierung selbst, keine Vorgänger-Referenz. Die Verknüpfung musst du selbst führen.

Genau eine Anlage schließt die Kette ab

Die Spezifikationsliste führt dafür zwei eigene Fehlercodes:

Code Schlüssel
NON-SUBSEQUENT-FACILITY-IS-REQUIRED waste.notification.non.subsequent.facility.must.exist
NON-SUBSEQUENT-FACILITY-MANY waste.notification.non.subsequent.facility.many

Mindestens eine Anlage ohne Folgeanlage muss vorhanden sein, und mehrere sind zu viel. Nach der Logik der Indikatoren schließt eine Anlage die Kette ab, wenn beide NextSubsequent…-Felder false sind — die Spezifikation formuliert das nicht ausdrücklich aus.

Artikel-15-Bescheinigung hängt an der Notifizierung

Nicht am Movement. FacilityCompletionUnderArticle15Type trägt:

Feld Kardinalität
notificationId minOccurs=1
movementIdentifier minOccurs=1, maxOccurs=unbounded
recoveryDisposalParty, wasteClassification, completionDate, acceptedQuantity je minOccurs=1

Dass movementIdentifier unbounded ist, ist kein Zufall: Eine Folgeanlage verarbeitet Material aus mehreren Verbringungen, die Beziehung ist n:m, und die Bescheinigung nennt die Verbringungen, die sie abdeckt.

Im .NET-SDK: NotificationDocumentHandler.SetFacilityCompletionUnderArticle15(FacilityCompletionUnderArticle15Type).

Der Movement-Status aggregiert über die Kette

facilityReception und facilityCompletion sind im Retrieval beide unbounded, während consigneeReception auf maxOccurs="1" steht. Die Statusübergänge hängen laut EU-Spezifikation jeweils am ersten Ereignis:

  • ANNOUNCED → MOVING: beim ersten Carrier-Transfer-Zertifikat
  • ANNOUNCED/MOVING → RECEIVED: beim ersten Empfangszertifikat
  • RECEIVED → COMPLETED: beim Abschlusszertifikat

RECEIVED heißt „mindestens eine Anlage hat quittiert“

Nicht „die Empfangsanlage hat” und erst recht nicht „alle haben”. Bei einer vorläufigen Anlage ist es die erste Station. Ebenso heißt COMPLETED nicht, dass die Verwertungskette abgeschlossen ist — das vorläufige Verfahren ist ein Abschluss, der Nachweis über das nachfolgende Verfahren läuft danach noch, und zwar an der Notifizierung als Artikel-15-Bescheinigung. Eine Oberfläche, die bei COMPLETED „fertig” zeigt, behauptet mehr als der Status trägt.

Details zu den Statuswerten und ihrem Fundort im Dokument: Lebenszyklus.

BMU (Begleit- und Übernahmeschein)

Die Regeln gelten für BGSDokument und UNSDokument. Wie streng der Dienst prüft, legt XmlOptions.validation fest, siehe BMU-Anleitung → Prüfung und Entwurf.

Feld Regel
bgs_nr 14 Zeichen: „1” und 13 Ziffern
uns_nr, uns_nrn 14 Zeichen: „2” und 13 Ziffern
nachweis_nr 12 Zeichen: „EN” oder „SN”, ein Buchstabe aus ABCDEFGHIKLMNPRS, dann 9 Zeichen
abfallschluessel 6 Ziffern nach der Abfallverzeichnis-Verordnung (AVV), ohne Leerzeichen
menge in Tonnen; bis 8 Stellen, davon 3 Nachkommastellen
volumen in Kubikmetern; bis 8 Stellen, davon 3 Nachkommastellen
abfallbezeichnung höchstens 255 Zeichen
vermerke höchstens 64000 Zeichen

Die Einheit trägst du nicht ein, sie steht im Schema fest. Anders als bei DiWaSS gehört der Abfallschlüssel hier ohne Gruppen-Leerzeichen ins Feld. bgs_nr, uns_nr und nachweis_nr tragen neben der Nummer (nr) eine Prüfziffer (pruefziffer); der Dienst prüft sie standardmäßig und berechnet sie mit XmlOptions.pruefziffer = PRUEFZIFFER_CALCULATE.

Weiterführend