eANV: Begleitschein und Übernahmeschein

Begleitschein (BGS) und Übernahmeschein (UNS) sind Belege des elektronischen Abfallnachweisverfahrens (eANV) nach der Nachweisverordnung (NachwV). Ihr Format gibt ein XML-Schema des BMU vor. ZEDAL kapselt dieses Format: Du setzt typisierte Felder über die BmuDocumentApi (per .NET SDK, gRPC oder REST) und schreibst das XML nicht selbst. ZEDAL stellt die Belege den übrigen Beteiligten zu und meldet abgeschlossene Begleitscheine über die ZKS-Abfall an die Behörden.

Verfügbarkeit

Baustein	Stand
BmuDocumentApi über gRPC und das .NET SDK	Testumgebung
BmuDocumentApi über REST	folgt
Speichern, Vermitteln, Melden, Abholen (DocumentApi)	Produktion
Qualifizierte Signatur je Layer über den WebSigner	folgt
.NET SDK mit XmlOptions am BmuDocumentHandler	ab Zedal.Sdk 1.3.0

Wann die Bausteine für deine Umgebung bereitstehen, erfährst du beim ZEDAL-Support (erp-tools@zedal.de).

Leseweg

Seite	Inhalt
Verfahren und Rollen	wer beteiligt ist, wie Layer aufeinander folgen, Fristen, Sammelentsorgung, Korrektur und Storno
Begleitschein je Rolle (.NET SDK)	durchgehendes C#-Beispiel für Erzeuger, Beförderer, Zwischenlager, Entsorger und Einsammler
Begleitschein und Übernahmeschein	die Schritte im Detail, mit den Aufrufen über REST
Signieren mit dem WebSigner	der Signaturvorgang aus Sicht deiner Anwendung
Feldregeln → BMU	Nummernformate, Mengen und Einheiten, Feldlängen
Fehlercodes → BMU	welche Fehler der Dienst meldet und woran du sie unterscheidest

Arbeitsmodell

Die BmuDocumentApi ist zustandslos. Das XML hältst du:

• Jeder Aufruf schickt das aktuelle XML mit (doc_xml, in JSON base64-kodiert).
• Jede Antwort liefert die typisierte Sicht (document) und, wenn sich das Dokument geändert hat, das neue XML. Mit diesem XML arbeitest du weiter.
• Aufbewahren musst du das XML; ohne es lässt sich das Dokument weder lesen noch ändern.

Im SDK übernimmt das der BmuDocumentHandler. Er hält DocXml und Document, schickt das XML bei jedem Aufruf mit und aktualisiert danach beide Properties. Die Methoden zum Anlegen und Ändern geben nichts zurück, das Ergebnis liest du an den Properties ab.

In deinen ZEDAL-Bestand kommt ein Dokument erst mit dem Versand an ZEDAL.

Rollen und Layer

Die Beteiligten stehen in eigenen Feldern des Dokuments:

Beteiligter	BGSDokument (Begleitschein)	UNSDokument (Übernahmeschein)
Erzeuger	erzeuger	erzeuger
Beförderer	befoerderer1, befoerderer2, befoerderer3	befoerderer
Entsorger	entsorger	entsorger
Zwischenlager	zwischenlager	–

Ein Begleitschein besteht aus Layern. Geschrieben und signiert wird im aktuellen Layer (nach AddLayer im neuen). Den Typ eines Layers gibt LayerType an:

LayerType	Layer
VORLAGE	Vorlage
ERZEUGER	Erzeuger
BEFOERDERER	Beförderer
ENTSORGER	Entsorger
BEHOERDE	Behörde
ERGAENZUNG	Ergänzung
ZWISCHENLAGER	Zwischenlager

LAYERTYPE_UNSPECIFIED behandelt der Dienst wie VORLAGE, gib den Typ also immer an. Vorlage- und Ergänzungslage brauchen eine ATB-Rolle (XmlOptions.atb_rolle, Werte aus Rolle, etwa ERZ, BEF, ENT), ebenso CreateDocument für einen Übernahmeschein (ERZ, BEF oder ENT).

Layer anhängen geht nur beim Begleitschein

AddLayer funktioniert für Begleitscheine. Auf einem Übernahmeschein scheitert der Aufruf für jeden Layertyp mit CANCELLED.

Lebenszyklus

1. Anlegen: aus einem ZEDAL-Muster (CreateDocumentFromTemplate) oder aus Daten (CreateDocument, wahlweise mit Vorlagelayer).
2. Füllen: UpdateDocument schreibt in den aktuellen Layer.
3. Signieren: GetValidSignaturePositions zeigt die offenen Signaturstellen des aktuellen Layers. Layer-genaue Signatur: folgt. Die SignerApi signiert BMU-Dokumente derzeit als Ganzes, BmuSigningOptions wird nicht ausgewertet (Signieren).
4. Nächster Layer: AddLayer hängt den Layer des nächsten Beteiligten an, weiter mit Schritt 2.
5. An ZEDAL senden: Das XML mit allen Layern geht als Transportdokument an ZEDAL (SDK und gRPC).

Felder schreiben

UpdateDocument übernimmt nur Felder mit meta.in_layer = true. Ein Feld ohne diese Markierung ignoriert der Dienst, und der Aufruf meldet trotzdem Erfolg. Nicht mitgeschickte Felder bleiben unverändert, du schickst also nur, was sich ändert. Bei Listen bestimmt eine mitgeschickte, nicht leere Liste die Länge der Liste im Dokument.

Prüfung und Entwurf

XmlOptions steuert die Prüfung, und zwar pro Aufruf:

Feld	Werte
validation	VALIDATION_FULL (Standard bei CreateDocument und UpdateDocument): Schema und weitere Prüfungen · VALIDATION_MANDATORY: nur Pflichtfelder · VALIDATION_TYPES: nur Datentypen · VALIDATION_NONE (Standard bei AddLayer): keine Prüfung, etwa für Entwürfe und Muster
pruefziffer	PRUEFZIFFER_VALIDATE (Standard) prüft Prüfziffern, PRUEFZIFFER_CALCULATE berechnet sie
atb_rolle	Rolle, für die der Layer angelegt wird; Pflicht für Vorlage- und Ergänzungslayer und beim Anlegen eines Übernahmescheins

Ohne XmlOptions prüfen CreateDocument und UpdateDocument vollständig, auch wenn du das Dokument als Entwurf angelegt hast. AddLayer prüft den neuen Layer ohne Optionen nicht. Willst du bei einem Aufruf eine andere Prüfung, gib die Optionen bei genau diesem Aufruf mit.

Storno

Einen Storno markierst du beim Versand an ZEDAL mit dem Flag cancel: Es kennzeichnet die übergebene Version als Stornierung (An ZEDAL senden).