AI translation
This page was translated from German with AI. If in doubt, the German original applies.
eANV: Consignment note and acceptance note¶
The consignment note (Begleitschein, BGS) and the acceptance note (Übernahmeschein, UNS) are documents of the German electronic waste record procedure (eANV) under the Nachweisverordnung (NachwV), the German ordinance on waste records. Their format is specified by an XML schema of the BMU. ZEDAL encapsulates this format: you set typed fields via the BmuDocumentApi (using the .NET SDK, gRPC or REST) and do not write the XML yourself. ZEDAL delivers the documents to the other parties and reports completed consignment notes to the authorities via the ZKS-Abfall.
Availability¶
| Building block | Status |
|---|---|
BmuDocumentApi via gRPC and the .NET SDK |
test environment |
BmuDocumentApi via REST |
to follow |
Storing, relaying, reporting, retrieving (DocumentApi) |
production |
| Qualified signature per layer via the WebSigner | to follow |
.NET SDK with XmlOptions on the BmuDocumentHandler |
from the next release after Zedal.Sdk 1.2.0 |
To find out when the building blocks will be available for your environment, contact ZEDAL support (erp-tools@zedal.de).
Reading order¶
| Page | Content |
|---|---|
| Procedure and roles | who is involved, how layers follow one another, deadlines, collective disposal (Sammelentsorgung), correction and cancellation |
| Consignment note by role (.NET SDK) | a continuous C# example for waste producer, carrier, interim storage facility (Zwischenlager), disposer (Entsorger) and collector (Einsammler) |
| Consignment note and acceptance note | the steps in detail, with the calls via REST |
| Signing with the WebSigner | the signing process from your application’s perspective |
| Field rules → BMU | number formats, quantities and units, field lengths |
| Error codes → BMU | which errors the service reports and how you tell them apart |
Working model¶
The BmuDocumentApi is stateless. You hold the XML:
- Every call sends the current XML along (
doc_xml, base64-encoded in JSON). - Every response returns the typed view (
document) and, if the document has changed, the new XML. You continue working with this XML. - You must keep the XML; without it, the document can be neither read nor changed.
In the SDK, the BmuDocumentHandler takes care of this. It holds DocXml and Document, sends the XML with every call and then updates both properties. The methods for creating and changing return nothing; you read the result from the properties.
A document only enters your ZEDAL document store once you send it to ZEDAL.
Roles and layers¶
The parties are in separate fields of the document:
| Party | BGSDokument (consignment note) |
UNSDokument (acceptance note) |
|---|---|---|
| Waste producer | erzeuger |
erzeuger |
| Carrier | befoerderer1, befoerderer2, befoerderer3 |
befoerderer |
| Disposer | entsorger |
entsorger |
| Interim storage facility | zwischenlager |
– |
A consignment note consists of layers. Writing and signing take place in the current layer (after AddLayer, in the new one). LayerType specifies the type of a layer:
LayerType |
Layer |
|---|---|
VORLAGE |
Template |
ERZEUGER |
Waste producer |
BEFOERDERER |
Carrier |
ENTSORGER |
Disposer |
BEHOERDE |
Authority |
ERGAENZUNG |
Supplement |
ZWISCHENLAGER |
Interim storage facility |
The service treats LAYERTYPE_UNSPECIFIED like VORLAGE, so always specify the type. Template and supplement layers need an ATB role (XmlOptions.atb_rolle, values from Rolle, such as ERZ, BEF, ENT), as does CreateDocument for an acceptance note (ERZ, BEF or ENT).
Adding layers only works for consignment notes
AddLayer works for consignment notes. On an acceptance note, the call fails with CANCELLED for every layer type.
Lifecycle¶
- Create: from a ZEDAL template (
CreateDocumentFromTemplate) or from data (CreateDocument, optionally with a template layer). - Fill in:
UpdateDocumentwrites to the current layer. - Sign:
GetValidSignaturePositionsshows the open signature positions of the current layer. For BMU documents, the SignerApi currently does not place a signature at a specific signature position of a layer; signatures that complete a layer are not yet possible through it. This step will be added as soon as the SignerApi supports it (Signing). - Next layer:
AddLayeradds the layer of the next party; continue with step 2. - Send to ZEDAL: The XML with all layers goes to ZEDAL as a transport document (SDK and gRPC).
Writing fields¶
UpdateDocument only applies fields with meta.in_layer = true. The service ignores a field without this marker, and the call still reports success. Fields you do not send remain unchanged, so you only send what changes. For lists, a non-empty list that you send determines the length of the list in the document.
Validation and drafts¶
XmlOptions controls validation, per call:
| Field | Values |
|---|---|
validation |
VALIDATION_FULL (default for CreateDocument and UpdateDocument): schema and further checks · VALIDATION_MANDATORY: mandatory fields only · VALIDATION_TYPES: data types only · VALIDATION_NONE (default for AddLayer): no validation, e.g. for drafts and templates |
pruefziffer |
PRUEFZIFFER_VALIDATE (default) validates check digits, PRUEFZIFFER_CALCULATE calculates them |
atb_rolle |
role for which the layer is created; mandatory for template and supplement layers and when creating an acceptance note |
Without XmlOptions, CreateDocument and UpdateDocument validate fully, even if you created the document as a draft. Without options, AddLayer does not validate the new layer. If you want different validation for a call, pass the options with exactly that call.
Cancellation¶
You mark a cancellation with the cancel flag when sending to ZEDAL: it marks the submitted version as a cancellation (Send to ZEDAL).