DiWaSS-Integration¶
DiWaSS ist das EU-Zentralsystem für die grenzüberschreitende Abfallverbringung. ZEDAL kapselt die Kommunikation mit DiWaSS: Du arbeitest gegen die ZEDAL-API bzw. das .NET-SDK, nicht gegen das EU-SOAP-Interface.
Zwei Rechtsakte sind maßgeblich, und der zweite wird häufig übersehen:
| Rechtsakt | Regelt |
|---|---|
| VO (EU) 2024/1157 (Abfallverbringungsverordnung) | das Verfahren: wer notifiziert, wer zustimmt, welche Nachweise fällig sind |
| DVO (EU) 2025/1290 (Durchführungsverordnung) | die technische Durchführung: Datenmodell, Vorgangsarten und die Authentifizierungspflichten in Artikel 14 |
Für eine Integration ist die Durchführungsverordnung die konkretere Quelle.
Diese Sektion¶
| Seite | Inhalt |
|---|---|
| Rollen | Die sechs Rollen, ihre Slots im Datenmodell, ihre Kardinalitäten (Schema gegen Serverregel), Operator-Kennungen, die Berechtigungs-Bausteine des SDK, Abgrenzung zur NachwV |
| Lebenszyklus | Zustände je Dokumenttyp, Stage-Reihenfolge, das zweistufige Versandverfahren (SaveToZedal → SendToDiwass plus asynchrone Antwort), Anlagenkette, Fristenbegriffe |
| Notification (Company) | Stage für Stage mit Code: Notifizierung anlegen, mit Behörden korrespondieren, nach Zustimmung ändern, stornieren |
| Movement (Company) | Stage für Stage mit Code: Movement anlegen, Transport, Wareneingang, Annahme, Abschluss |
| Authority | Die Behördenseite — Eingangsbestätigung, Nachforderung, Vorbedingungs-Signale, Entscheidung, Rücknahme. Und vor allem: was davon bei dir ankommt und wann |
Dazu die Referenzschicht, die nicht DiWaSS-spezifisch aufgebaut ist, aber überwiegend DiWaSS-Regeln enthält:
| Seite | Inhalt |
|---|---|
| Feldregeln | Pflichtfelder jenseits des Schemas, Nummernformate, kontextabhängige Formate, Felder, die man besser weglässt, Querbezüge, die der Server prüft |
| Codelisten | Abfallschlüssel und listID-Werte, R-/D-Codes, Verpackungsart, HP-Codes, Event-Codes, Schreibweise-Fallen |
| Fehlercodes | Transport- und Fachfehler getrennt, wo eine Ablehnung wirklich steht, Katalog der DiWaSS-Codes |
| Aufrufe und Synchronisation | Aufruffrequenz, Fehlerbehandlung, Abholen fremder Änderungen, Zeitbudgets |
Aufrufe und Synchronisation ist Pflichtlektüre vor dem Produktivgang
Drei Eigenschaften der Schnittstelle bringen jede Integration zu Fall, die sie nicht kennt:
- Die EU verlangt sequenzielle Aufrufe gegen DiWaSS und behält sich bei fortgesetzter Zuwiderhandlung die Sperrung des API-Zugangs vor. Parallelisierung über mehrere Dokumente ist riskant.
- Es gibt keinen Entwurfsstatus über die API. Was über die Oberfläche ein Entwurf wäre, ist über die Schnittstelle bereits eingereicht. Ein fehlerhaft eingereichtes Dokument ist eingereicht.
- Zeitbudgets sind größer als erwartet. Der Client-Default des SDK liegt bei 30 Sekunden; ein Push mit Anhang braucht über 90, mehrstufige Movement-Ketten deutlich mehr — pro Stufe.
Empfohlener Leseweg¶
- Rollen — das Vokabular. Wer welchen Slot besetzt, wer welchen Vorgang auslösen darf, und warum die NachwV-Übersetzung nicht trägt.
- Lebenszyklus — das Ablaufmodell: Stages, Versandverfahren, asynchrone Antwort. Ohne diese Begriffe sind die Schritt-für-Schritt-Anleitungen nicht lesbar.
- Aufrufe und Synchronisation — die Betriebsregeln. Früh lesen, nicht erst beim Debuggen.
- Notification (Company), danach Movement (Company) — der eigentliche Bauplan. Ein Movement existiert nur zu einer konsentierten Notifizierung, deshalb in dieser Reihenfolge.
- Authority — auch wenn du die Behördenrolle nicht baust: Die Zustandswechsel deiner Notifizierung kommen von dort.
- Feldregeln und Codelisten — beim Befüllen nebenbei offen halten. Beide sind Nachschlagewerke, keine Lesestrecken.
Bei der ersten Ablehnung: Fehlercodes. Die Seite erklärt zuerst, wo der Fehler steht — Transportfehler, ValidationErrors, TransferHistory und Transferdetails sind vier verschiedene Orte — und danach, was die Codes bedeuten.
Annex VII (Grünliste)¶
Für Grünlisten-Verbringungen nach Anhang VII gibt es im SDK einen eigenen Handler, CreateAnnex7Handler() (Handler und Lebenszyklus).
Die Stages sind dem Movement strukturell ähnlich, tragen aber eigene Methoden: CreateAnnex7 / SetAnnex7, SetAnnex7CarrierTransfer, SetAnnex7ConsigneeCertificate, SetAnnex7FacilityCertificate, SetAnnex7CertificateOfCompletion, SetAnnex7TakeBack. Versandverfahren, Followup-Intents und Fehlerbehandlung sind dieselben wie bei Notifizierung und Movement.
Eine eigene Schritt-für-Schritt-Anleitung für Annex VII gibt es in dieser Doku noch nicht. Die Rollen- und Lebenszyklus-Konzepte gelten unverändert; die Annex-VII-spezifischen Intents sind in Rollen und Berechtigungen im SDK mit aufgeführt.
Code-Beispiele¶
Die Anleitungen beschreiben die Stages fachlich. Den C#-Code dazu, mit Typen, Pflichtfeldern und Aufrufreihenfolge, zeigt der SDK-Bereich: Notifizierung mit dem SDK, Movement mit dem SDK und Behördenseite mit dem SDK.
Abgrenzung DiWaSS ↔ NachwV¶
- DiWaSS — grenzüberschreitende Verbringung, EU-weit, VO (EU) 2024/1157 und DVO (EU) 2025/1290. Gegenstand dieser Sektion.
- NachwV — nationales Nachweisverfahren, in ZEDAL über andere Module abgebildet. Nicht Gegenstand dieser Sektion.
Eine Mapping-Tabelle „NachwV-Rolle ↔ DiWaSS-Rolle” ist ohne Kontextwissen nicht belastbar. Die strukturellen Unterschiede — und warum sie beim Übersetzen stolpern lassen — stehen unter Rollen → DiWaSS ↔ NachwV.