Diese Dokumentation hat den Zweck, Entwickler bei der Implementierung der Webservice Clients und Integration dieser Clients in bestehende Systeme zu unterstützen.

Release-Änderungen

Bug-Fix Release für 1.10

  • Transport-Message Format D

    • Das Format erfordert nun mindestens einen Transporteur, um Validierungsfehler in der Anwendung zu vermeiden.

    • Aktualisierte Schema-Datei: closed_MessageFormatD.xsd

Änderungen mit Release 1.10

  • Interface-Änderungen: Messaging-Webservice

    • Neue Interface-Version 1.10

      • ShipmentItemObject und TransportItemObject: Wenn eine ConsignmentNoteReferenceID angegeben ist, dann muss das PropertyKind des NetPropertyStatement Masse ("9008390104439") sein und die unitID des NumericValue des ValueAssignmentStatement des NetPropertyStatement "kg" sein.

    • VEBSV Benutzername ersetzt den EDM-Hauptbenutzer Benutzernamen bei der Authentifizierung. Dieser wird gemeinsam mit dem Applikationspasswort zur Webserviceauthentifizierung verwendet.

      • Für bestehende Benutzer wird der EDM-Hauptbenutzer Benutzername für den VEBSV Benutzernamen übernommen.

    • Regeln des Messaging-Webservices wurden implementiert.

  • Interface-Änderungen: Begleitschein-Webservice

    • Name u. Adresse von ListedData-Einträgen (Person, Organization, LocalUnit) sind nun optional, wenn eine GLN angegeben ist.

  • Begleitscheine danach werden nun mit Begleitscheine ohne Transport umgesetzt.

  • SMS-Lösung ist nun freigeschaltet in der DEMO-Stage.

  • Im Abschnitt "Schema-Downloads" finden sich nun auch Beispiele aller Messages und Meldungen.

Änderungen mit Release 1.9

  • Unterstützung von Signaturen und Verschlüsselung - aktuell noch optional

    • Sollten Signaturen u. Verschlüsselung zurzeit deaktiviert sein (nicht nur optional), so müssen die entsprechenden Abschnitte nicht berücksichtigt werden.

  • Änderungen bei der Kommunikation zwischen Beteiligten: Korrekturen, Korrekturvorschläge, Stornierungen

    • Weiterleitung von Messages entfernt

  • Post-Processing-Validierungen Messaging:

    • meldepflichtige Abfälle benötigen eine VEBSV-ID

    • Grund für Transportabbruch mit GTIN "9008390127513" kann nicht mehr verwendet werden

  • Interface-Änderungen: Messaging-Webservice

    • Neue Interface-Version 1.09

      • Maximale Anzahl von Shipment u. TransportMovement auf 1 beschränkt (gilt nun auch für ältere Interface-Versionen)

      • Transport-Start-Message: Angabe des Kennzeichens (Transportmittelkennzeichen) möglich

    • RetrieveDocumentRequest: optionales Feld RequestEncryptedResponse hinzugefügt

    • DocumentHeader: neue Felder ObjectUUID, ReferencedDocumentUUID. ObjectUUID für v1.09 verpflichtend, ansonsten optional.

    • Neues UpdateEvent: LaunchDocumentAction

  • Interface-Änderungen: Begleitschein-Webservice

    • ShareDocumentRequest, RetrieveDocumentRequest, CancelDocumentRequest: optionales Feld RequestEncryptedResponse hinzugefügt

Schema Downloads

Schema Downloads

Einleitung

Das vollelektronische Begleitscheinverfahren 2.0 (kurz VEBSV 2.0) wurde geschaffen, um Begleitscheine von meldepflichtigen Abfällen zu digitalisieren. Dadurch entfällt die physische Erstellung und Aufbewahrung. VEBSV 2.0 besteht aus zwei SAOP-Webservices, sowie mehreren unterstützenden Frontend-Applikationen.

Durch das Messaging-Webservice können Teilnehmer untereinander Daten zu abfallbezogenen Geschäftsfällen austauschen. Zusätzlich werden auch nicht-meldepflichtige Abfälle, sowie sonstige Auftrags-Positionen (sonstige Güter und Dienstleistungen) unterstützt. Transporteure haben zusätzlich die Möglichkeit ein Transportdokument zu erstellen, welches bei etwaigen Kontrollen gültig ist.

Ein Begleitschein setzt sich aus verschiedenen Meldungen zusammen, die von den Beteiligten eigenständig eingemeldet werden. Dafür wird das Begleitschein-Webservice verwendet.

Die folgenden Abschnitte bieten eine Hilfe für die Umsetzung der beiden Webservice Clients. Detaillierte Informationen zum Konzept von VEBSV 2.0 und gezeigte komplexere Fälle unterstützen Entwickler bei der Integration dieser Clients in bestehende Systeme oder helfen bei der Erstellung einer neuen Software.

Tutorials

Als Hilfestellung dafür, die Clients der Webservices zu erstellen und diese in eine bestehende Software zu integrieren oder eine Software zur Datenverwaltung zu implementieren, wird hier auf die wichtigsten Schritte, die dafür nötig sind, näher eingegangen.

Die exakte Implementierung hängt dabei von den verschiedensten Faktoren, wie der verwendeten Programmiersprache, den verwendeten Frameworks, etc., ab und deshalb werden keine konkreten Code-Beispiele gezeigt. Jedoch werden die einzelnen Abschnitte genauer beleuchtet und auf Aspekte eingegangen, die allgemein gültig sind.

Da es während der Entwicklung unweigerlich zu Fehlern kommen wird und das Produkt auf Korrektheit getestet werden soll, wird eine spezielle Entwicklungsumgebung bereitgestellt - die DEMO-Stage. Auf dieser läuft dieselbe Version, wie in der Produktiv-Umgebung. Mit eigens für die DEMO-Stage erstellten Benutzern können die verschiedensten Szenarien durchgeführt werden.

Um Zugang zur Entwicklungsumgebung zu erhalten, muss eine Anfrage an den technischen Support (EDM-Helpdesk) gestellt werden. Darauf hin erhält man ein Set an Testbenutzern und ein sogenanntes Connector-Secret. Dieses wird benötigt, um sich bei den Webservices zu authentifizieren.

Basis-Tutorials

Webservice-Clients erstellen u. Schema-Klassen generieren

Schema-Klassen generieren

Der erste Schritt der Implementierung ist das Erstellen von Schema-Klassen. Hiermit werden die einzelnen Elemente, die in den ".xsd"-Files definiert sind, automatisch in Klassen der verwendeten Programmiersprache umgewandelt. Die einzelnen Schemas können hier heruntergeladen werden.

Ältere Versionen von Frameworks, die aus Schema-Dateien Klassen generieren, unterstützen XSD 1.1 nicht. Daher werden die betroffenen Dateien auch XSD 1.0 konform angeboten. Diese verwenden jedoch keine <xs:assert>, was bei der Validierung eines Requests/einer Response berücksichtigt werden sollte.

Für die Klassen des Messaging-Webservices wird die Datei MessagingServiceTypes.xsd benötigt. Die Klassen der verschiedenen Message-Typen werden aus closed_MasterMessageFormat.xsd generiert. Für die Begleitschein-Schnittstelle wird TransferOfWasteServiceTypes.xsd genutzt.

Webservice-Clients erstellen

Der nächste Schritt ist das Erstellen von Webservice-Clients. Hierzu gibt es auch verschiedene Frameworks, die diese aus "Web Services Description Language"-Files (WSDL) (MessagingService.wsdl und TransferOfWasteService.wsdl) erstellen können. Es ist jedoch auch gebräuchlich, diese manuell zu erstellen.

Die Requests werden als XML in den <soap:Body>-Part eines <soap:Envelope> eingefügt. Anschließend wird der Soap-Request als HTTPS-POST an den Webservice gesendet. Diese Schritte, vom Transformieren des Request-Objekts, bis zum Senden des HTTPS-Post-Requests, werden für gewöhnlich vom verwendeten Framework übernommen.

Die URLs zu den Webservices in der DEMO-Stage sind:

Für die Produktiv-Umgebung sind diese:

Ergebnis überprüfen

Zum Überprüfen des WebService-Clients für das Messaging kann nun ein RefreshBindingRequest gesendet werden. Die XML-Darstellung des RefreshBindingRequest-Objekts ist Folgende, wobei eine zufällig generierte UUID für <TransactionUUID> verwendet werden muss:

<RefreshBindingRequest>
    <InterfaceVersionID>1.09</InterfaceVersionID>
    <ConnectorVersionID>1.00</ConnectorVersionID>
    <TransactionUUID>[transaction uuid]</TransactionUUID>
</RefreshBindingRequest>

Funktioniert alles wie erwartet, so soll als Ergebnis nicht einen RefreshBindingResponse erhalten werden, sondern einen FailureResponse, da die Authentifizierung noch fehlt.

Um den Client des Begleitschein-Webservices überprüfen zu können, kann ein RequestWasteTransferID gesendet werden. Auch hier sollte eine FailureResponse aufgrund der fehlenden Authentifizierung zurückkommen.

Authentifizierung und erster (erfolgreicher) Request

Das Ziel ist nun für beide Webservices einen erfolgreichen Request abzusetzen und anstatt einer FailureResponse, den erwarteten Response zu erhalten. Am besten eignen sich dafür der RefreshBindingRequest und RequestWasteTransferIDRequest.

Die Authentifizierung muss zwischen dem Erstellen eines XML Requests und dem tatsächlichen Senden des Requests durchgeführt werden.

Wie der Authentifizierungsmechanismus genau funktioniert wird im Abschnitt Authentifizierung genauer erläutert.

Ist der Authentifizierungsmechanismus richtig umgesetzt worden, so werden nun keine FailureResponses von den Webservices zurückgegeben, sondern die erwarteten Responses.

Erste Message senden u. empfangen

Ist der Authentifizierungsmechanismus implementiert, so kann die erste Message gesendet werden. Nähere Informationen, wie die Kommunikation zwischen Nutzern, bzw. deren Clients, abläuft, finden sich hier.

Message erstellen

Zuerst wird das Message-Objekt, genauer MasterMessageEnvelope, erstellt. In diesem Tutorial verwenden wir eine Übergabe-/Übernahme-Message. Das Objekt wird so befüllt, dass es dieser XML-Repräsentation entspricht:


  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31


  
<MasterMessageEnvelope>
    <ListedData>
        <Organization>
            <DocumentScopeAssignmentID>handover</DocumentScopeAssignmentID>
            <ID collectionID="9008390104026">[GLN]</ID>
        </Organization>
        <Organization>
            <DocumentScopeAssignmentID>takeover</DocumentScopeAssignmentID>
            <ID collectionID="9008390104026">[GLN]</ID>
        </Organization>
    </ListedData>
    <MessageData>
        <Shipment>
            <UUID>[uuid]</UUID>
            <ShipmentItem>
                <UUID>[item uuid]</UUID>
                <LineItemNumber>1</LineItemNumber>
                <WasteTypeID collectionID="5174">9008390017081</WasteTypeID>
                <NetPropertyStatement>
                    <PropertyKindID collectionID="9000">9008390104439</PropertyKindID>
                    <ValueAssignmentStatement>
                        <NumericValue unitID="kg">100.0</NumericValue>
                    </ValueAssignmentStatement>
                    <QuantificationTypeID collectionID="7299">9008390100028</QuantificationTypeID>
                </NetPropertyStatement>
                <HandOverPartyReferenceID>handover</HandOverPartyReferenceID>
                <TakeOverPartyReferenceID>takeover</TakeOverPartyReferenceID>
            </ShipmentItem>
        </Shipment>
    </MessageData>
</MasterMessageEnvelope>

Was die einzelnen Elemente bedeuten, lässt sich hier nachlesen. Für die GLNs in <Organization> werden die GLNs von den Test-Registrierten verwendet, die Sie vom EDM-Helpdesk erhalten haben. Die zwei UUIDs werden zufällig generiert.

ShareDocumentRequest erstellen und senden

Nun, da die Message erstellt wurde, wird der ShareDocumentRequest erzeugt. Die XML-Repräsentation ist Folgende:


  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27


  
<ShareDocumentRequest>
    <InterfaceVersionID>{{InterfaceVersionID}}</InterfaceVersionID>
    <ConnectorVersionID>1.00</ConnectorVersionID>
    <TransactionUUID>[transaction uuid]</TransactionUUID>
    <Recipient>
        <RecipientID>[GLN sender]</RecipientID>
        <TransactionPurposeCategoryID collectionID="2976">request</TransactionPurposeCategoryID>
    </Recipient>
    <AuthenticatedDocument>
        <DocumentUQ>
            <DocumentHeader>
                <DocumentTypeID collectionID="2551">9008390117712</DocumentTypeID>
                <DocumentUUID>[doc uuid]</DocumentUUID>
                <VersionBracketUUID>[vbracket uuid]</VersionBracketUUID>
                <ContextUUIDReference>
                    <ContextUUID>[context uuid]</ContextUUID>
                    <ContextTypeID collectionID="7263">9008390117408</ContextTypeID>
                </ContextUUIDReference>
                <DocumentOriginPartyID>[GLN sender]</DocumentOriginPartyID>
                <ObjectUUID>[shipment uuid]</ObjectUUID>
            </DocumentHeader>
            <DocumentContent>
                [message envelope]
            </DocumentContent>
        </DocumentUQ>
    </AuthenticatedDocument>
</ShareDocumentRequest>

Die Bedeutungen der einzelnen Elemente werden hier beschrieben. Die UUIDs werden erneut zufällig generiert, wobei der Wert von <ObjectUUID> derselbe sein muss, wie die UUID des Shipment-Elements der Message. Als Wert des <ReciepientID>-Elements muss die Personen-GLN des Nachrichten-Empfängers verwendet werden, als Wert des <DocumentOriginPartyID>-Elements die Personen-GLN des Nachrichten-Senders.

Der Inhalt von <DocumentContent> ist die zuvor erzeugte Message. Diese kann jedoch nicht direkt eingefügt werden, sondern muss vorher in ein XML-Element verwandelt werden.

Wurde das ShareDocumentRequest-Objekt erzeugt, so kann es mit dem Messaging-Client gesendet werden. War der Request erfolgreich, so wird eine ShareDocumentResponse zurückgegeben.

Query-Update

Die fertige Implementierung des Messaging-Clients würde von Zeit zu Zeit Neuigkeiten, die den Nutzer des Clients betreffen, abfragen. Dafür wird die Query-Update-Operation verwendet. Dadurch erhält man eine Liste von UpdateEvents.

Durch das erfolgreiche Senden des ShareDocumentRequest wurde ein solches Event erzeugt. Dieses Event, in diesem Fall ForwardSharingEvent, ist "sichtbar" für den Absender, wie auch alle in der Message angeführten Empfänger.

Dieser QueryUpdateRequest soll nun versendet werden:


  
1
2
3
4
5
6
7
8


  
<QueryUpdateRequest>
    <InterfaceVersionID>1.09</InterfaceVersionID>
    <ConnectorVersionID>1.00</ConnectorVersionID>
    <UpdateRangeStartUUID>[transaction uuid]</UpdateRangeStartUUID>
    <UpdateRangeEndUUID>[transaction uuid]</UpdateRangeEndUUID>
    <UpdateRangeStartInclusionIndicator>true</UpdateRangeStartInclusionIndicator>
    <UpdateRangeEndInclusionIndicator>true</UpdateRangeEndInclusionIndicator>
</QueryUpdateRequest>

Für die UUIDs soll die Transaction-UUID des ShareDocumentRequest verwendet werden. Gemeinsam mit den beiden InclusionIndicator-Elementen ergibt sich, dass man das ForwardSharingEvent der zuvor gesendeten Message erhält.

Einem Messaging-Client ist die Transaction-UUID einer zu empfangenden Message nicht bekannt. Deshalb muss dieser von Zeit zu Zeit beim Messaging-Webservice nachfragen, ob es für den Nutzer sogenannte "Updates" gibt. Dafür wird die QueryUpdate-Operation verwendet. In <UpdateRangeStartUUID> wird dabei die dem Client zuletzt bekannte Transaction-UUID eingefügt. Die Response des QueryUpdates enthält schließlich alle "Updates", die zeitlich nach dem "Update" der angegebenen Transaction-UUID erstellt wurden. In einem "Update" ist nun die Transaction-UUID einer Message enthalten, die dem Nutzer gesendet wurde. Diese Transaction-UUID kann schließlich verwendet werden, um den dazugehörigen Message-Inhalt abzufragen.

Wird das QueryUpdate das erste Mal ausgeführt, wird für <UpdateRangeStartUUID> die NiL-UUID verwendet, wodurch ein Client alle "Updates" des Nutzers erhält.
Empfangen der Message

Durch das Query-Update erhält ein Client nun Neuigkeiten. Wenn es sich um ein ForwardSharingEvent, wie in unserem Fall, handelt, so handelt es sich um eine Message. Diese kann schließlich mit der RetrieveDocument-Operation abgerufen werden.

Bei einem ForwardSharingEvent kann es sich um eine Message, aber auch um die Stornierung einer Message handeln.

Der Request in XML-Repräsentation ist wie folgt, wobei erneut die Transaction-UUID des ShareDocumentRequest verwendet wird:


  
1
2
3
4
5


  
<RetrieveDocumentRequest>
    <InterfaceVersionID>1.09</InterfaceVersionID>
    <ConnectorVersionID>1.00</ConnectorVersionID>
    <ReferredTransactionUUID>[transaction uuid]</ReferredTransactionUUID>
</RetrieveDocumentRequest>

Die Response enthält nun dasselbe AuthenticatedDocument-Object wie der ShareDocumentRequest. Die Inhalte in <DocumentHeader>`werden dazu genutzt, um die Message einem bestehenden Auftrag zuzuordnen bzw. einen neuen Auftrag anzulegen. Der Inhalt von `<DocumentContent>, die eigentliche Message, verändert den bestehenden oder neu angelegten Auftrag.

Weiteres

Es können nun auch andere Messages ausprobiert werden. Detaillierte Informationen, wie sich die verschiedenen Messages zusammensetzen, finden sich in der Schnittstellenbeschreibung. Was jedoch beachtet werden muss, ist, dass Regeln existieren, wann welche Message gesendet werden kann.

Erste Meldung senden

Nachdem die Authentifizierung für den Begleitschein-Client und der RequestWasteTransferIDRequest funktioniert, kann jetzt auch die erste Meldung/Deklaration gesendet werden.

Für dieses Tutorial wird eine Übergabe-Deklaration erstellt und gesendet. Wichtig ist, dass davor die RequestWasteTransferID-Operation durchgeführt wird. Denn dadurch erhält man eine neue VEBSV-ID.

Für jeden meldepflichtigen Abfall muss jeweils eine eigene VEBSV-ID verwendet bzw. bezogen werden und für jeden meldepflichtigen Abfall muss es einen eigenen Begleitschein geben: Die VEBSV-ID steht somit für einen Begleitschein. Jede Meldung/Deklaration zu diesem Abfall verwendet daher dieselbe VEBSV-ID.

Damit die Übersichtlichkeit gewahrt bleibt, wird das Erstellen der Übergabe-Deklaration aufgeteilt. Genauere Information zum Aufbau von Meldungen generell und zum Aufbau der Übergabe-Deklaration im Speziellen finden sich hier.

Erstellung von <EnvironmentalDataDocument>

  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25


  
<EnvironmentalDataDocument>
    <Document>
        <TypeID collectionID="5064">9008390116289</TypeID>
    </Document>
    <EnvironmentalData>
        <TypeAEvent>
            <TypeID collectionID="8926">9008390116371</TypeID>
            <Date>[date in future]</Date>
            <Object>
                <TypeID collectionID="5174">9008390010877</TypeID>
                <PropertyStatement>
                    <PropertyKindID collectionID="5618">9008390104439</PropertyKindID>
                    <ValueAssignmentStatement>
                        <NumericValue unitID="kg">100.0</NumericValue>
                    </ValueAssignmentStatement>
                    <MethodID collectionID="7299">9008390100028</MethodID>
                </PropertyStatement>
            </Object>
            <AssociatedObjectReferenceID roleID="9008390104576" collectionID="9008390104026">366709875396</AssociatedObjectReferenceID>
            <AssociatedObjectDocumentScopeReferenceID roleID="9008390104705" objectTypeName="Unternehmen">handover</AssociatedObjectDocumentScopeReferenceID>
            <AssociatedObjectDocumentScopeReferenceID roleID="9008390104712" roleDesignation="Übernehmer" objectTypeName="Unternehmen">takeover</AssociatedObjectDocumentScopeReferenceID>
            <AssociatedObjectDocumentScopeReferenceID roleID="9008390108338" objectTypeName="Standort">pickUpLocation</AssociatedObjectDocumentScopeReferenceID>
        </TypeAEvent>
    </EnvironmentalData>
</EnvironmentalDataDocument>

Das Datum der Übergabe muss dabei zwingend in der Zukunft liegen. Die Elemente <AssociatedObjectDocumentScopeReferenceID> sind Referenzen zu Einträgen in <ListedData>.

Erstellung von <ListedData>

  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87


  
<ListedData>
    <Organization>
        <DocumentScopeAssignmentID>handover</DocumentScopeAssignmentID>
        <ID collectionID="9008390104026" collectionDesignation="EDM">[GLN]</ID>
        <Name>[Name]</Name>
        <Address>
            <Component>
                <TypeID collectionID="6856">9008390104682</TypeID>
                <ID collectionID="3862">[040]</ID>
                <RepresentationDesignation>[Österreich]</RepresentationDesignation>
            </Component>
            <Component>
                <TypeID collectionID="6856">9008390103951</TypeID>
                <RepresentationDesignation>[city]</RepresentationDesignation>
            </Component>
            <Component>
                <TypeID collectionID="6856">9008390103944</TypeID>
                <RepresentationID>[PLZ]</RepresentationID>
            </Component>
            <Component>
                <TypeID collectionID="6856">9008390103968</TypeID>
                <RepresentationDesignation>[street]</RepresentationDesignation>
            </Component>
            <Component>
                <TypeID collectionID="6856" objectDesignation="Straße">9008390103975</TypeID>
                <RepresentationID>[house number]</RepresentationID>
            </Component>
        </Address>
    </Organization>
    <Organization>
        <DocumentScopeAssignmentID>takeover</DocumentScopeAssignmentID>
        <ID collectionID="9008390104026" collectionDesignation="EDM">[GLN]</ID>
        <Name>[Name]</Name>
        <Address>
            <Component>
                <TypeID collectionID="6856">9008390104682</TypeID>
                <ID collectionID="3862">[040]</ID>
                <RepresentationDesignation>[Österreich]</RepresentationDesignation>
            </Component>
            <Component>
                <TypeID collectionID="6856">9008390103951</TypeID>
                <RepresentationDesignation>[city]</RepresentationDesignation>
            </Component>
            <Component>
                <TypeID collectionID="6856">9008390103944</TypeID>
                <RepresentationID>[PLZ]</RepresentationID>
            </Component>
            <Component>
                <TypeID collectionID="6856">9008390103968</TypeID>
                <RepresentationDesignation>[street]</RepresentationDesignation>
            </Component>
            <Component>
                <TypeID collectionID="6856" objectDesignation="Straße">9008390103975</TypeID>
                <RepresentationID>[house number]</RepresentationID>
            </Component>
        </Address>
    </Organization>
    <LocalUnit>
        <DocumentScopeAssignmentID>pickUpLocation</DocumentScopeAssignmentID>
        <ID collectionID="9008390104026">[GLN]</ID>
        <Name>[Name]</Name>
        <TypeID collectionID="9351">9008390109199</TypeID>
        <Address>
            <Component>
                <TypeID collectionID="6856">9008390104682</TypeID>
                <ID collectionID="3862">[040]</ID>
                <RepresentationDesignation>[Österreich]</RepresentationDesignation>
            </Component>
            <Component>
                <TypeID collectionID="6856">9008390103951</TypeID>
                <RepresentationDesignation>[city]</RepresentationDesignation>
            </Component>
            <Component>
                <TypeID collectionID="6856">9008390103944</TypeID>
                <RepresentationID>[PLZ]</RepresentationID>
            </Component>
            <Component>
                <TypeID collectionID="6856">9008390103968</TypeID>
                <RepresentationDesignation>[street]</RepresentationDesignation>
            </Component>
            <Component>
                <TypeID collectionID="6856" objectDesignation="Straße">9008390103975</TypeID>
                <RepresentationID>[house number]</RepresentationID>
            </Component>
        </Address>
    </LocalUnit>
</ListedData>

Die Werte der GLNs, Namen und Adressen werden von den Test-Registrierten verwendet, die Sie vom EDM-Helpdesk erhalten haben.

Erstellung von <ShareDocumentRequest>

  
1
2
3
4
5
6
7
8
9
10
11


  
<ShareDocumentRequest>
    <InterfaceVersionID>1.00</InterfaceVersionID>
    <ConnectorVersionID>1.00</ConnectorVersionID>
    <TransactionUUID>[uuid]</TransactionUUID>
    <EnvironmentalDataInstance>
        <EnvironmentalDataEnvelope>
            <ListedData>...</ListedData>
            <EnvironmentalDataDocument>...</EnvironmentalDataDocument>
        </EnvironmentalDataEnvelope>
    </EnvironmentalDataInstance>
</ShareDocumentRequest>

Die zuvor erzeugten Elemente werden nun in <EnvironmentalDataEnvelope> eingefügt. Für die Transaction-UUID muss eine neue UUID generiert werden.

Nun kann der Request an das Begleitschein-Webservice gesendet werden und wenn alles korrekt umgesetzt wurde, dann erhält man eine ShareDocumentResponse.

Für die in der Meldung genannten Personen erscheint nun ein ShareSignal-Event im Query-Update.

Weiterführende Themen

Transport-Dokument erstellen

Das Messaging-Webservice bietet die Möglichkeit ein Transportdokument zu erstellen, das vom Transporteur bei einer behördlichen Kontrolle vorgezeigt werden kann. Damit dieses Dokument erstellt werden kann, müssen gewisse Voraussetzungen erfüllt sein. Ansonsten wird die Erstellung vom Webservice verweigert. Die Voraussetzungen sind:

  • Vorhandensein der Übergabedeklarationen, Transportdeklarationen und Abfalltransportbeginnmeldungen zu allen meldepflichtigen Abfällen

  • Vorhandensein folgender Daten über den Transport:

    • Transporteur, Absender des Transports, Empfänger des Transports

    • Beladeort, Abladeort

    • Art des Transports (Straße, Schiene, Wasserweg, Luftweg)

    • Kennzeichen des Transportmittels

    • nicht stornierte Transport-Message

    • nicht stornierte Transportstart-Message

    • Wenn eine Umladung am Beladeort stattfindet, dann müssen der erste Übergeber und der Übergabeort bekannt sein.

    • Wenn eine Umladung am Entladeort stattfindet, dann müssen der Empfänger (also der letzte Übernehmer) und der Empfangsort bekannt sein.

Im Streckengeschäft ist vorgesehen, dass der erste Übergeber und Empfänger nichts voneinander wissen müssen/sollen. Deshalb wird dem Übergeber eine Transport-Message gesendet, die nur den Belade-Wegpunkt enthält. Die Transport-Message des Empfängers besitzt nur den Ablade-Wegpunkt. Auch wenn keine Transport-Message existiert, die beide Wegpunkte enthält, erkennt das Messaging-Webservice, dass die notwendigen Daten vorliegen.

Ist eine dieser Voraussetzungen nicht erfüllt, dann wird ein FailureResponse zurückgegeben.

Es gibt Edge-Cases, in denen das Messaging-Webservice nicht erkennt, dass nicht alle notwendigen Daten vorliegen. Einer davon ist, wenn eine Stornierung (z.B. der Transport-Message) und das Erstellen des Transportdokuments zur gleichen Zeit erfolgt. In solchen Fällen erfolgt der Fehler-Response asynchron. Nähere Information dazu lassen sich hier nachlesen.

Das Erstellen eines Transportdokuments erfolgt über die LaunchDocumentAction-Operation. Hat der Request die Validierung erfolgreich durchlaufen, so wird anschließend asynchron das Transportdokument erstellt. Hat das Messaging-Webservice das Transportdokument erfolgreich generiert, wird ein LaunchDocumentActionEvent für den Ersteller (den Transporteur) erzeugt, worin sich der Link zum Transportdokument befindet. Dieses enthält eine URL, die zum Transportdokument führt. Das Event selbst ist vom Ersteller über ein Query-Update abrufbar.

Für dieses Tutorial übernimmt der Übergeber die Rolle des Transportorganisators und die des Transporteurs. Dadurch können alle Messages u. Meldungen mit einem Nutzer gesendet werden. Folgende Schritte werden durchgeführt:

  1. Erstellung der Auftragsdaten. Mindestens ein meldepflichtiger Abfall soll enthalten sein.

  2. Abfrage(n) der VEBSV-ID(s)

  3. Die Übergabe-/Übernahme-Message ist für das Ziel, die Erstellung des Transportdokuments, nicht notwendig. Jedoch kann diese der Vollständigkeit halber problemlos gesendet werden.

  4. Senden der Transport-Message. Dabei muss darauf geachtet werden, dass auch alle notwendigen Daten enthalten sind.

  5. Senden der Übergabe-Deklaration u. Transport-Deklaration.

  6. Senden der Transportstart-Message. Wurde das Kennzeichen nicht in der Transport-Message hinzugefügt, dann muss dies spätestens hier geschehen.

  7. Erstellung des Transportdokuments mit einem LaunchDocumentActionRequest.

  8. Nach einer kurzen Wartezeit (wenige Sekunden) wird ein Query-Update durchgeführt, worin sich das LaunchDocumentActionEvent und somit die URL zum Transportdokument befindet.

SMS-Lösung

Durch die SMS-Lösung wird es einem Abfallersterzeuger (bzw. einem ersten Übergeber) möglich, ohne eigener Software an VEBSV 2.0 teilzunehmen, indem dieser über eine Web-Applikation die Übergabe der Abfälle bestätigen kann. Dabei wird für alle meldepflichtigen Abfälle eine Übergabe-Deklaration gesendet. Außerdem wird dem Organisator des Geschäfts, also dem Registrierten, der dem Übergeber die Übergabe-/Übernahme-Message sendete, ein Antwortsignal mittels ShareRetrieverStatus überbracht. Die URL zur Web-Applikation erhält der Übergeber durch eine ihm gesandte SMS.

Der Versand der SMS kann vom Organisator, dem Übernehmer im Falle eines gewöhnlichen Geschäfts oder dem Streckenmelder im Falle eines Streckengeschäfts, getriggert werden. Dazu muss eine spezielle Übergabe-/Übernahme-Message gesendet werden:


  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30


  
<ShareDocumentRequest>
    ...
    <Reciepient>
        ...
        <TelephoneCommunicationNetworkEndpointID>[telephone number]</TelephoneCommunicationNetworkEndpointID>
    </Reciepient>
    <AuthenticatedDocument>
        <DocumentUQ>
            ...
            <DocumentContent>
                <MasterMessageEnvelope>
                    <ListedData>
                        ...
                        <LocalUnit>[handover location]</LocalUnit>
                    </ListedData>
                    <MessageData>
                        <Shipment>
                            ...
                            <PickUpSiteService>
                                ...
                                <SiteLocalUnitReferenceID>[reference to handover location]</SiteLocalUnitReferenceID>
                                ...
                            </PickUpSiteService>
                        </Shipment>
                    </MessageData>
                </MasterMessageEnvelope>
            </DocumentContent>
        </DocumentUQ>
    </AuthenticatedDocument>
</ShareDocumentRequest>

Der erste Punkt, der erfüllt sein muss, ist die Angabe der Telefonnummer, an welche die SMS versendet werden soll. Außerdem muss die Message ein <PickUpSiteService>-Element enthalten, welches den Übergabeort enthält. Der Grund dafür ist, dass beim Bestätigen in der Web-Applikation die Übergabe-Deklaration gesendet wird, welche den Übergabeort enthalten muss.

Für die spezielle Übergabe-/Übernahme-Message gibt es ein eigenes Schema (closed_MessageFormatC_SMSchecks.xsd).

Die folgenden Schritte werden durchgeführt. Dabei ist der Organisator des Geschäfts der Übernehmer:

  1. Erzeugen der Auftragsdaten. Ein meldepflichtiger Abfall muss enthalten sein.

  2. Abfrage(n) der VEBSV-ID(s).

  3. Senden der speziellen Übergabe-/Übernahme-Message.

  4. Sobald die SMS erhalten wurde, kann der erste Übergeber (bzw. ein von ihm dazu Ermächtigter) die Web-Applikation über den Link öffnen und Bestätigen.

  5. Der Übernehmer führt ein Query-Update durch. Darin befinden sich nun mehrere UpdateEvents

    • Ein BackwardSharingEvent durch das Öffnen der Web-Applikation

    • Ein weiteres BackwardSharingEvent durch das Bestätigen

    • Für jeden meldepflichtigen Abfall ein ShareSignalEvent (siehe Signal-Sharing)

Korrekturen, Korrekturvorschläge und Stornierungen

Das Messaging-Webservice bietet die Möglichkeit, bereits versandte Messages zu korrigieren, auf erhaltene Messages mit einem Korrekturvorschlag zu antworten und Messages samt deren Korrekturen mittels Stornierung ungültig zu machen. Nähere Informationen dazu finden sich hier. Auch muss ein Client auf gewisse Regeln achten, wann welche Operation durchgeführt werden kann.

Auch das Begleitschein-Webservice bietet die Möglichkeit, Meldungen zu korrigieren und zu stornieren, wobei es auch hier wieder gewisse Regeln beim Ablauf gibt.

Die Software soll Korrekturen, Korrekturvorschläge und Stornierungen korrekt darstellen:

  • Korrekturen überschreiben die vorangegangene Message vollständig.

  • Eine Stornierung wirkt sich so aus, als wäre die dazugehörige Message-Reihe, samt potenziellen Korrekturvorschlägen, nie gesendet worden.

  • Korrekturvorschläge ändern die tatsächlichen Daten nicht, sie erweitern sie nur.

  • Sollte eine Message (od. deren Korrektur(vorschlag), Stornierung) fehlschlagen, könnte es sein, dass die Software nicht auf dem aktuellsten Datenstand ist (siehe Regeln für das Senden von Messages/Meldungen). Ein Query-Update könnte dies auflösen.

Signaturen u. Verschlüsselung bei Messages/Meldungen einbauen

Seit Release 1.9 unterstützen sowohl das Messaging-Webservice als auch das Begleitschein-Webservice die Möglichkeit, Messages/Meldungen zu signieren und zu verschlüsseln.

Hinweis: Aufgrund der VEBSV-Verordnung müssen Messages und Meldungen signiert und verschlüsselt werden. In der DEMO-Stage ist dies jedoch optional.

Einbindung v. ZAReg und REDA Schnittstellen

ZAReg und REDA sind zentrale Elemente, die von VEBSV 2.0 genutzt werden, weshalb eine Client-Implementierung deren Schnittstellen berücksichtigen muss.

Im Zentralen Anlagenregister (ZAReg) werden alle registrierten Personen/Unternehmen, deren Standorte und Anlagen und weitere Informationen verwaltet. Die Daten daraus werden für jede Message u. Meldung benötigt.

ZAReg Schnittstellenbeschreibung

REDA lässt sich als eine Sammlung von Konstanten verstehen. Es gibt verschiedene Listen, die sich mit den, aus vielen Programmiersprachen bekannten, "Enums" vergleichen lassen. In Messages u. Meldungen wird an vielen Stellen genau ein Eintrag aus einer bestimmten Liste erwartet.

REDA Schnittstellenbeschreibung

Wie geht es weiter?

Webservice-Operationen: Messaging

Das Messaging-Webservice bietet verschiedene Operationen an, um den Datenaustausch zwischen den Beteiligten zu ermöglichen. Die folgenden Abschnitte geben darüber einen Überblick.

Die zu den Operationen gehörenden Requests und Responses werden nicht im vollen Detail gezeigt, sondern nur die Elemente, die für die kommenden Abschnitte relevant sind. Die vollständigen Schema-Definitionen werden hier gezeigt.

Versionierung

Die Versionierung der Schnittstelle wird durch die InterfaceVersionID bestimmt. Diese wird in jeder Anfrage an das Webservice übergeben. Dadurch kann ein Client angeben, auf Grundlage welcher Version der Schnittstelle dieser arbeitet. Das Messaging-Webservice transformiert schließlich eine in einer anderen Version der Schnittstelle gesendete Message in die Ziel-Version. Dadurch wird ermöglicht, dass Clients auch nach Schnittstellenänderungen weiterhin funktionieren.

Bereits veraltete Versionen können bei neueren Releases deaktiviert werden. Z.B. wurde mit der Veröffentlichung der Version 1.09 die Version 1.07 deaktiviert. Das heißt, dass keine Messages mehr in der Version 1.07 angenommen werden. Bereits gesendete Messages in der Version 1.07 können jedoch weiterhin abgerufen werden, in dem sie in eine noch aktive Version umgewandelt werden.

Zwangsweise ergibt sich aus der Transformation von Messages, dass eine beigefügte Signatur keine Gültigkeit mehr besitzt. In diesen Fällen ersetzt das Messaging-Webservice die Signatur durch eine Eigene.

Da sich VEBSV 2.0 noch in der Pilotphase befindet, können Änderungen bestehende Implementierungen beeinflussen – selbst wenn diese noch aktive Versionen nutzen. Bei Änderungen werden die vom Umweltministerium zugelassenen Pilotteilnehmer frühzeitig informiert, damit sie die notwendigen Anpassungen rechtzeitig vornehmen können.

Die aktuelle Interface-Version ist 1.09.

RefreshBinding

Der Zweck der RefreshBinding-Operation ist, einen User mit einer DB-UUID mittels Authentifizierungsdaten zu verknüpfen. Was die DB-UUID ist, lässt sich im Abschnitt Authentifizierung nachlesen. Die Verbindung zwischen User und DB-UUID bleibt 30 Tage lang bestehen.

<ns1:RefreshBindingRequest xmlns:ns1="http://www.umweltbundesamt.at/schema/MessagingService">
    <InterfaceVersionID>1.09</InterfaceVersionID>
    <ConnectorVersionID>...</ConnectorVersionID>
    <TransactionUUID>[transaction uuid]</TransactionUUID>
</ns1:RefreshBindingRequest>

ShareDocument

Durch die ShareDocument-Operation können Beteiligte untereinander Daten zum Geschäftsfall in Form von Messages austauschen.

<ns1:ShareDocumentRequest xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
                      xmlns:ns1="http://www.umweltbundesamt.at/schema/MessagingService">
    <InterfaceVersionID>1.09</InterfaceVersionID>
    <ConnectorVersionID>...</ConnectorVersionID>
    <TransactionUUID>[transaction uuid]</TransactionUUID>
    <Recipient> (1)
        <RecipientID>[GLN of recipient]</RecipientID>
        <TransactionPurposeCategoryID collectionID="2976">...</TransactionPurposeCategoryID>
    </Recipient>
    <AuthenticatedDocument>
        <DocumentUQ>
            <DocumentHeader> (2)
                <DocumentTypeID collectionID="2551">[document type gtin]</DocumentTypeID>
                <DocumentUUID>...</DocumentUUID>
                <VersionBracketUUID>...</VersionBracketUUID>
                <VersionSequenceNumber>...</VersionSequenceNumber>
                <ChangeReasonID collectionID="7521">[change reason id gtin]</ChangeReasonID>
                <Description>...</Description>
                <ContextUUIDReference>
                    <ContextUUID>...</ContextUUID>
                    ...
                </ContextUUIDReference>
                <ContextIDReference>...</ContextIDReference>
                <DocumentOriginPartyID>[GLN of sender]</DocumentOriginPartyID>
                <ReferencedDocumentUUID>...</ReferencedDocumentUUID>
                <ObjectUUID>...</ObjectUUID>
            </DocumentHeader>
            <DocumentContent>...</DocumentContent> (3)
            <AttachmentBinaryObject>...</AttachmentBinaryObject> (4)
        </DocumentUQ>
        <ds:Signautre>...</ds:Signature> (5)
    </AuthenticatedDocument>
</ns1:ShareDocumentRequest>
1 Der Empfänger wird durch die im EDM ZAReg zugewiesene Personen-GLN identifiziert. Es können mehrere Empfänger angegeben werden.
2 Ein DocumentHeader enthält wichtige Informationen um die Nachricht zu einem Geschäftsfall und innerhalb eines Geschäftsfalls zuordnen zu können:

  • Die DocumentTypeID gibt den Typ der Message an. Die verschiedenen Messagearten werden hier vorgestellt.

  • Jede Nachricht ist eindeutig durch die DocumentUUID unterscheidbar.

  • Wird eine Nachricht durch den Absender korrigiert, so hat die Korrektur zwar eine neue einzigartige DocumentUUID, jedoch dieselbe VersionBracketUUID wie die Originalnachricht. Die VersionSequenceNumber muss dabei höher sein als die vorhergehende Nachricht. Genauere Informationen zu Korrekturen finden sich im Abschnitt Korrekturen, Korrekturvorschläge, Stornierungen.

  • Der Grund einer Korrektur muss mittels ChangeReasonID angegeben werden. Zusätzliche Informationen im Description-Element sind hingegen optional.

  • Eine ContextUUID vereint alle Nachrichten, die zum selben Geschäftsfall gehören.

  • Die DocumentOriginPartyID gibt die Personen-GLN des Message-Absenders an. Ab Interface-Version 1.09 ist diese Angabe verpflichtend.

  • Mittels ReferencedDocumentUUID kann auf eine andere Nachricht referenziert werden und dadurch ein Korrekturvorschlag erzeugt werden. Weitere Informationen dazu finden sich im Abschnitt Korrekturen, Korrekturvorschläge, Stornierungen.

  • Die ObjectUUID ist seit Interface-Version 1.09 verpflichtend. Bei Übergabe/Übernahme-bezogenen Messages entspricht dies der ShipmentUUID, bei Transport-bezogenen Messages der TransportMovementUUID. Dadurch werden Messages innerhalb eines Geschäftsfalls einem konkreten Datenobjekt (z.B. Auftrag, Transport) zugeordnet. Welche Message zu welcher Gruppe gehört, wird im Abschnitt Message-Types beschrieben.
3 Das DocumentContent-Element enthält die eigentliche Message.
4 Es können bis zu acht Anhänge einer Nachricht beigefügt werden.
5 Die Signatur ermöglicht es einem Empfänger die Integrität und den Ursprung einer Nachricht zu überprüfen. Im Abschnitt Signaturen und Verschlüsselung wird genauer darauf eingegangen.

ShareDocumentCancellation

Durch diese Operation lässt sich eine Nachricht samt möglicher Korrekturen und Korrekturvorschlägen stornieren. Eine Stornierung selbst lässt sich nicht mehr stornieren und ist somit endgültig. Weitere Informationen dazu finden sich im Abschnitt Korrekturen, Korrekturvorschläge und Stornierungen.

<ns1:ShareDocumentCancellationRequest xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
        xmlns:ns1="http://www.umweltbundesamt.at/schema/MessagingService">
    <InterfaceVersionID>1.09</InterfaceVersionID>
    <ConnectorVersionID>...</ConnectorVersionID>
    <TransactionUUID>...</TransactionUUID>
    <Recipient>...</Recipient>
    <AuthenticatedCancellation>
        <DocumentUQ>
            <VersionBracketUUID>...</VersionBracketUUID>
            <ChangeReasonID collectionID="">[change reason gtin]</ChangeReasonID>
            <DocumentOrigingPartyID>[GLN of sender]</DocumentOrigingPartyID>
        </DocumentUQ>
        <ds:Signature>...</ds:Signature>
    </AuthenticatedCancellation>
</ns1:ShareDocumentCancellationRequest>

QueryUpdate

Ein Benutzer kann durch die QueryUpdate-Operation "Neuigkeiten" abrufen, die UpdateEvents genannt werden. Wie bereits im Abschnitt Spezialfall: QueryUpdate erwähnt, werden bei dieser Operation die User-Angaben weggelassen. Die Zuordnung von Events erfolgt ausschließlich über die DB-UUID.

<ns1:QueryUpdateRequest xmlns:ns1="http://www.umweltbundesamt.at/schema/MessagingService">
    <InterfaceVersionID>1.09</InterfaceVersionID>
    <ConnectorVersionID>...</ConnectorVersionID>
    <UpdateRangeStartUUID>...</UpdateRangeStartUUID>
    <UpdateRangeEndUUID>...</UpdateRangeEndUUID>
    <UpdateRangeStartInclusionIndicator>[true/false]</UpdateRangeStartInclusionIndicator>
    <UpdateRangeEndInclusionIndicator>[true/false]</UpdateRangeEndInclusionIndicator>
</ns1:QueryUpdateRequest>

Dabei gibt er die TransactionUUID des neuesten UpdateEvents an, die er mit der letzten QueryUpdate-Response erhielt. Sollte es sich um den allerersten Aufruf handeln, so wird die sogenannte "Nil-UUID" verwendet.

<ns1:QueryUpdateResponse xmlns:ns1="http://www.umweltbundesamt.at/schema/MessagingService">
    <AdditionalUpdatesIndicator>[true/false]</AdditionalUpdatesIndicator>
    <UpdateEvent>...</UpdateEvent>
</ns1:QueryUpdateResponse>

Als Antwort erhält der Benutzer eine Liste von UpdateEvents, die nach ihrem zeitlichen Auftreten sortiert sind. Dabei beträgt die maximale Anzahl an UpdateEvents pro Response 50. Gibt es mehr als 50 UpdateEvents, so wird dies durch AdditionalUpdatesIndicator angezeigt. Der Benutzer kann dann ein weiteres QueryUpdate ausführen. Dabei wird als UpdateRangeStartUUID die TransactionUUID des letzten UpdateEvents des vorherigen Responses verwendet. Dieser Vorgang lässt sich so lange wiederholen, bis keine weiteren UpdateEvents mehr vorhanden sind.

Es gibt sechs verschiedene Arten von UpdateEvents:

  • ForwardSharingEvent: Erzeugt durch erfolgreiches ShareDocument oder ShareDocumentCancellation. Absender und Empfänger erhalten dieses.

  • BackwardSharingEvent: Erzeugt durch erfolgreiches ShareRetrieverStatus. Sowohl der Absender als auch der Empfänger erhalten dieses Event bei einem QueryUpdate.

  • ProcessingEvent: Wird erzeugt, wenn im Post-Processing die Validierung eines ShareDocument-, ShareDocumentCancellation, ShareRetrieverStatus- oder LaunchDocumentAction-Request fehlschlägt oder ein sonstiger Fehler während dem Post-Processing auftritt. Diese Events sind nur für den Absender sichtbar.

Ein Beispiel für eine Validierung im Post-Processing ist, dass meldepflichtige Abfälle eine VEBSV-ID besitzen müssen, sofern es sich um keinen internen Transport handelt. Da im Webservice selbst der Inhalt der Message nur formal auf Richtigkeit überprüft wird (sprich, ob die Message dem Schema entspricht), erhält der Absender zunächst keinen Fehler mittels eines FailureResponses. Erst in einem späteren Schritt wird überprüft, ob die Message auch inhaltlich korrekt ist.

  • UpdateSignalEvent: Dieses Event wird durch ein ShareSignal erzeugt und ist für alle im ShareSignalRequest angegebenen Personen sichtbar.

  • LaunchDocumentActionEvent: Wird nach einem LaunchDocumentAction erzeugt und ist nur für den Absender sichtbar.

  • PostProcessingEvent: Wird erzeugt, wenn der getriggerte Job vom LaunchDocumentAction erfolgreich war. Falls nicht, wird ein ProcessingEvent erzeugt. Dieses Event ist nur für den Absender des LaunchDocumentActionRequests sichtbar und beinhaltet die erforderlichen Daten um das Ergebnis des Background-Jobs abzurufen.

QueryDocumentValidationResult

Kommt es während dem Post-Processing zu einem Fehler, so wird ein ProcessingEvent erzeugt. Dieses zeigt jedoch nur an, dass ein Fehler aufgetreten ist. Um mehr Informationen über den Fehler zu erhalten wird diese Operation verwendet.

<ns1:QueryDocumentValidationResultRequest
        xmlns:ns1="http://www.umweltbundesamt.at/schema/MessagingService">
    <InterfaceVersionID>1.09</InterfaceVersionID>
    <ConnectorVersionID>...</ConnectorVersionID>
    <ReferredTransactionUUID>...</ReferredTransactionUUID>
</ns1:QueryDocumentValidationResultRequest>
<QueryDocumentValidationResultResponse>
    <ValidationResultItem>...</ValidationResultItem>
</QueryDocumentValidationResultResponse>

RetrieveDocument

Die RetrieveDocument-Operation ist das Gegenstück zur ShareDocument-Operation. Ein Empfänger kann damit eine Nachricht abrufen, die ihm ein anderer Beteiligter gesendet hat. Dabei wird die TransactionUUID angegeben, die vorher über ein QueryUpdate erhalten wurde.

<ns1:RetrieveDocumentRequest xmlns:ns1="http://www.umweltbundesamt.at/schema/MessagingService">
    <InterfaceVersionID>1.09</InterfaceVersionID>
    <ConnectorVersionID>...</ConnectorVersionID>
    <ReferredTransactionUUID>...</ReferredTransactionUUID>
</ns1:RetrieveDocumentRequest>

Im Response ist neben dem ForwardSharingEvent auch das AuthenticatedDocument (dasselbe wie beim ShareDocumentRequest) enthalten.

<ns1:RetrieveDocumentResponse xmlns:ns1="http://www.umweltbundesamt.at/schema/MessagingService">
    <ForwardSharingEvent>...</ForwardSharingEvent>
    <AuthenticatedDocument>...</AuthenticatedDocument>
</ns1:RetrieveDocumentResponse>

ShareRetrieverStatus

Ein ShareRetrieverStatus lässt sich als eine Art Antwort auf ein ShareDocument verstehen. Es wird dazu verwendet um Auftragsanfragen, Korrekturvorschläge, etc. abzulehnen oder zu bestätigen. Weitere Informationen, wie diese Operation verwendet wird, finden Sie in den Abschnitten Stornierungen, Korrekturvorschläge und Streckengeschäft.

<ns1:ShareRetrieverStatusRequest
        xmlns:ns1="http://www.umweltbundesamt.at/schema/MessagingService">
    <InterfaceVersionID>1.09</InterfaceVersionID>
    <ConnectorVersionID>...</ConnectorVersionID>
    <TransactionUUID>...</TransactionUUID>
    <ReferredTransactionUUID>...</ReferredTransactionUUID> (1)
    <ReferredTransactionTypeID collectionID="6413">...</ReferredTransactionTypeID>
    <SharedByPartyID>[gln of sender]</SharedByPartyID> (2)
    <SharedToPartyID>[gln of receiver]</SharedToPartyID> (3)
    <OperationTypeID collectionID="6801">...</OperationTypeID> (4)
    <OperationStatusID collectionID="2089">...</OperationStatusID> (5)
    <StatusReasonID collectionID="6838">...</StatusReasonID> (6)
    <StatusDescription>...</StatusDescription> (7)
</ns1:ShareRetrieverStatusRequest>
1 Die TransactionUUID der ursprünglichen Nachricht.
2 Der Absender des ShareRetrieverStatus und somit ein Empfänger der ursprünglichen Nachricht.
3 Der Empfänger des ShareRetrieverStatus und somit der Absender der ursprünglichen Nachricht.
4 Die Art des ShareRetrieverStatus.
Beispiele: (formale) Validierung, inhaltliche Prüfung, …​
5 Gibt Erfolg oder Misserfolg an.
6 Im Falle eines Misserfolges kann ein Grund aus einer vorgegebenen Liste angegeben werden. Ist der tatsächliche Grund nicht definiert, so muss auf die StatusDescription zurückgegriffen werden.
7 Eine genauere Beschreibung des Status.

Der Message-Empfänger überprüft die Daten und entdeckt, dass die falsche Abfallart verwendet worden ist. Daraufhin würde er ein ShareRetrieverStatus mit der Art "inhaltliche Prüfung" und Status "Misserfolg" zurücksenden. Im Beschreibungsfeld kann näher darauf eingegangen werden.

LaunchDocumentAction

Durch ein LaunchDocumentAction-Request lässt sich im Messaging-Webservice ein Job triggern. Der einzige Job zurzeit ist das Generieren des Transportdokuments.

<ns1:LaunchDocumentActionRequest
        xmlns:ns1="http://www.umweltbundesamt.at/schema/MessagingService">
    <InterfaceVersionID>1.09</InterfaceVersionID>
    <ConnectorVersionID>...</ConnectorVersionID>
    <TransactionUUID>...</TransactionUUID>
    <TransportMovementUUID>...</TransportMovementUUID>
    <ActionTypeID collectionID="1276">...</ActionTypeID>
</ns1:LaunchDocumentActionRequest>

ShareSignal

Wird nur intern verwendet und kann somit von Clients nicht benützt werden. Mit dieser Operation teilt das Begleitschein-System mit, dass eine bestimmte Meldung mit bestimmten Beteiligten eingegangen ist. Ein Client sieht das Resultat jedoch als UpdateSignalEvent im QueryUpdate.

PublicKey

Mit diesem Request kann ein Client den öffentlichen Schlüssel eines anderen Benutzers abfragen, um dessen Signatur überprüfen zu können. Auch lässt sich der öffentliche Schlüssel des Messaging-Webservice dadurch erhalten, um eine Message zu verschlüsseln. Weitere Informationen finden sich im Abschnitt Signaturen und Verschlüsselung.

FailureResponse

Für jede Operation gibt es Validierungen im Webservice. Schlägt die Validierung fehl, so wird eine FailureResponse zurückgegeben, anstatt z.B. eines ShareDocumentResponses.

Fehler im Post-Processing werden durch ProcessingEvent im QueryUpdateResponse angezeigt, da bestimmte Überprüfungen asynchron durchgeführt werden.

 
<ns1:FailureResponse xmlns:ns1="http://www.umweltbundesamt.at/schema/MessagingService">
    <FailureID>...</FailureID>
    <FailureText>...</FailureText>
    <ValidationResultItem>...</ValidationResultItem>
</ns1:FailureResponse>

Webservice-Operationen: Begleitschein-Schnittstelle

Die Aufgabe des Begleitschein-Webservices ist die Erstellung von Begleitscheinen. Im zuvor beschriebenen Messaging-Webservice liegt der Fokus auf der Kommunikation der Geschäftspartner untereinander zur Abwicklung des Gesamtgeschäfts.

Die Aufgabe des Begleitschein-Webservices ist hingegen die Erstellung von Begleitscheinen: Das zentrale Element dabei ist der meldepflichtige Abfall. Je meldepflichtigem Abfall muss ein Begleitschein erstellt werden, der sowohl die "Kette" der (vertragsrechtlichen) Übergaben und Übernahmen als auch alle Transporte, die den jeweiligen Abfall betreffen, enthält.

RequestWasteTransferID

Begleitscheine werden durch eine VEBSV-ID identifiziert. Alle Meldungen beinhalten diese VEBSV-ID, um diese einem Begleitschein zuzuordnen. Durch einen RequestWasteTransferIDRequest kann ein Client eine neue VEBSV-ID anfordern.

Das Anfordern einer VEBSV-ID übernimmt nur derjenige, der das Geschäft anlegt. Durch das Messaging-WS wird sie dann den anderen Beteiligten übermittelt.

 

  
1
2
3
4
5


  
<ns1:RequestWasteTransferIDResponse
        xmlns:ns1="http://www.umweltbundesamt.at/wsdl/TransferOfWasteServiceTypes">
    <WasteTransferID>[vebsv-id]</WasteTransferID>
    <IssueDateTime>...</IssueDateTime>
</ns1:RequestWasteTransferIDResponse>

Die Response enthält in <WasteTransferID> die neu generierte VEBSV-ID, welche einen Wert zwischen "1000-0000-0000" und "9999-9999-9999" annehmen kann, wobei die Bindestriche nur zur besseren Lesbarkeit eingefügt wurden.

ShareDocument

Mit dieser Webservice-Operation wird eine Meldung an das Begleitschein-System gesendet. Mit der in der Meldung angegebenen VEBSV-ID kann der Status eines Begleitscheins geändert, bzw., falls es die erste Meldung ist, ein Begleitschein zu dieser VEBSV-ID erstellt werden.


  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20


  
<ns1:ShareDocumentRequest xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
        xmlns:ns1="http://www.umweltbundesamt.at/wsdl/TransferOfWasteServiceTypes"
        xmlns:ns2="http://www.umweltbundesamt.at/schema/EnvironmentalData">
    <InterfaceVersionID>...</InterfaceVersionID>
    <ConnectorVersionID>...</ConnectorVersionID>
    <TransactionUUID>[transaction uuid]</TransactionUUID> (1)
    <DocumentUUID>...</DocumentUUID> (2)
    <ChangeReasonID>...</ChangeReasonID>
    <ns2:EnvironmentalDataInstance>
        <EnvironmentalDataEnvelope>
            <Document>...</Document> (3)
            <ListedData>...</ListedData> (4)
            <EnvironmentalDataDocument>
                <Document>...</Document> (5)
                <EnvironmentalData>...</EnvironmentalData> (6)
            </EnvironmentalDataDocument>
        </EnvironmentalDataEnvelope>
    </ns2:EnvironmentalDataInstance>
    <ds:Signature>...</ds:Signature> (7)
</ns1:ShareDocumentRequest>
1 Jede Meldung besitzt eine eindeutige Transaction-UUID.
2 Wird für die Korrektur einer Meldung verwendet. Dabei wird die TransactionUUID der zu korrigierenden Meldung angegeben. Zugleich wird ein Änderungsgrund mittels <ChangeReasonID> erwartet.
3 Metadaten zur Meldungserstellung (z.B. zum Ersteller selbst oder zum Zeitpunkt der Erstellung)
4 Personen, Organisationen und Standorte, die in den Daten der Meldung referenziert werden.
5 Angaben zur Meldungsart.
6 Inhaltliche Daten der Meldung. Mehr Informationen dazu finden sich im Abschnitt Meldungsarten.
7 Die Signatur ermöglicht es dem Begleitschein-Webservice die Integrität und den Ursprung der Meldung zu überprüfen. Im Abschnitt Signaturen und Verschlüsselung wird genauer darauf eingegangen.

CancelDocument

Mit dieser Operation lassen sich zuvor gesendete Meldungen stornieren.


  
1
2
3
4
5
6
7
8


  
<ns1:CancelDocumentRequest
        xmlns:ns1="http://www.umweltbundesamt.at/wsdl/TransferOfWasteServiceTypes">
    <InterfaceVersionID>...</InterfaceVersionID>
    <ConnectorVersionID>...</ConnectorVersionID>
    <TransactionUUID>[transaction uuid]</TransactionUUID>
    <DocumentUUID>[transaction uuid to delete]</DocumentUUID> (1)
    <ChangeReasonID>...</ChangeReasonID>
</ns1:CancelDocumentRequest>

Wie bei einer Korrektur muss die TransactionUUID der zu stornierenden Meldung und ein Grund für die Stornierung angegeben werden.

RetrieveDocument

Durch die RetrieveDocument-Operation erhält man den aktuellen Begleitschein zu einer VEBSV-ID aus der Sicht des Nutzers.


  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17


  
<ns1:RetrieveDocumentResponse xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
        xmlns:ns1="http://www.umweltbundesamt.at/wsdl/TransferOfWasteServiceTypes"
        xmlns:ns2="http://www.umweltbundesamt.at/schema/EnvironmentalData">
    <ValidationResult>...</ValidationResult> (1)
    <ns2:ConsignmentNoteDataInstance>
        <EnvironmentalDataEnvelope>
            <Document>...</Document> (2)
            <ListedData>...</ListedData> (3)
            <EnvironmentalDataDocument> (4)
                <Document>...</Document>
                <EnvironmentalData>...</EnvironmentalData>
            </EnvironmentalDataDocument>
            <ConsignmentNoteDocument>...</ConsignmentNoteDocument> (5)
        </EnvironmentalDataEnvelope>
    </ns2:ConsignmentNoteDataInstance>
    <ds:Signature>...</ds:Signature> (6)
</ns1:RetrieveDocumentResponse>
1 Eine Liste von Informationen, Warnungen und Fehlern, die den Begleitschein betreffen.
2 Metadaten zur Meldungserstellung (z.B. der Zeitpunkt der Erstellung)
3 Auflistung von Personen, Organisationen und Standorten, die in den Daten der Meldung referenziert werden.
4 Inhalte von Meldungen, die zum Begleitschein beigetragen haben. Hier sollte man beachten, dass Informationen, die ein gewisser Nutzer nicht einsehen darf, gefiltert werden. Besonders im Streckengeschäft oder bei komplexen Transporten wird dies vorkommen. Beispielsweise darf ein Transporteur keine Informationen zu einem anderen Transport einsehen.
5 Das Begleitscheinobjekt, das sich aus allen Meldungen zusammensetzt. Erneut werden gewisse Teile gefiltert, je nachdem ob der Nutzer dazu berechtigt ist.
6 Die vom Begleitschein-Webservice erzeugte Signatur.

QueryTransactionStatus

Damit lässt sich vom Begleitschein-System erfragen, ob eine zuvor gesendete Meldung, Korrektur oder Stornierung erfolgreich verarbeitet wurde oder ob es zu Fehlern oder Warnungen gekommen ist.

QueryValidationResult

Ist es bei einer Meldung, Korrektur oder Stornierung zu einem Fehler oder einer Warnung gekommen, so kann man diese mit dieser Operation erhalten.

Public Key

Mit diesem Request lässt sich der öffentliche Schlüssel des Begleitschein-Webservices abfragen. Weitere Informationen finden sich im Abschnitt Signaturen und Verschlüsselung im Begleitschein-Webservice.

Message-Types (Messaging-Webservice)

Master-Message

Es gibt verschiedene Message-Typen, deren Menge durch das Master-Message-Schema definiert ist. Die Message-Typen können grob in zwei Kategorien unterteilt werden.

Übergabe/Übernahme bezogene Messages:

  • Übergabe-/Übernahme-Message, Message-Format C

  • Übernahmebestätigungs-Message, Message-Format G

  • Ablehnungs-Message, Message-Format I

Transport bezogene Messages:

  • Transport-Message, Message-Format D

  • Transportstart-Message, Message-Format E

  • Transportabschluss-Message, Message-Format F

  • Empfangsbestätigungs-Message, Message-Format F

  • Transportabbruchs-Message, Message-Format H

Die Message-Formate scheinen wirr verteilt worden zu sein, sind jedoch in dieser Form historisch gewachsen.

Jede Message besteht aus zwei Teilen: ListedData und MessageData.

<MessageEnvelope>
    <ListedData>...</ListedData>
    <MessageData>...</MessageData>
</MessageEnvelope>

In ListedData werden Personen, Organisationen und Standorte definiert. Diese werden später innerhalb von MessageData referenziert. Für die Transport-Message existiert außerdem noch ein ShipmentMeta-Element.

Ein MessageData enthält entweder Shipment oder TransportMovement Elemente, je nachdem ob es sich um eine Übergabe-/Übernahme-bezogene Message (Shipment) oder eine Transport bezogene Message (TransportMovement) handelt.

Es werden nun die wichtigsten Inhalte der jeweiligen Message-Formate gezeigt. Hier finden Sie die Definition des Master-Message-Schemas. Dieses ist die Obermenge aller Message-Typen. Für die jeweiligen Restriktionen der verschiedenen Message-Typen stehen die jeweiligen Schema-Dateien zur Verfügung.

Übergabe-/Übernahme-bezogene Message

Übergabe-/Übernahme-Message

Mit der Übergabe-/Übernahme-Message können Abfallübergaben/-weitergaben definiert werden. Der Absender dieser Nachricht ist diejenige Person, die den Geschäftsfall organisiert. Die Empfänger der Nachricht sind die restlichen genannten Personen.

<MessageEnvelope>
    <ListedData>
        ...
    </ListedData>
    <MessageData>
        <Shipment>
            <UUID>[shipment uuid]</UUID>
            <PredeterminedScopeAssignmentID>[Auftrags-ID]</PredeterminedScopeAssignmentID>
            <ShipmentItem>
                <UUID>[shipment item uuid]</UUID>
                <WasteTypeID collectionID="5174">[waste type gtin]</WasteTypeID>
                <PredeterminedScopeAssignmentID>[waste-type]</PredeterminedScopeAssignmentID>
                <WasteContaminationTypeID collectionID="7835">
                    [contamination gtin]
                </WasteContaminationTypeID>
                <NetPropertyStatement>...</NetPropertyStatement>
                <ConsignmentNoteReferenceID>[vebsv-id]</ConsignmentNoteReferenceID>
                <DangerousGoodsDescription>...</DangerousGoodsDescription>
                <ContainsPersistentOrganicPollutant>true</ContainsPersistentOrganicPollutant>
            </ShipmentItem>
            <HandoverPartyReferenceID>handover</HandoverPartyReferenceID>
            <IntermediatePartyReferenceID>intermediate</IntermediatePartyReferenceID>
            <TakeoverPartyReferenceID>takeover</TakeoverPartyReferenceID>
        </Shipment>
    </MessageData>
</MessageEnvelope>

Die Daten werden innerhalb des <Shipment>-Elements angegeben. Diese sind:

  • eine eindeutige UUID

  • eine Auftrags-ID

  • mehrere Abfälle mit den wichtigsten Eigenschaften. Diese sind:

    • eine eindeutige UUID

    • welcher Abfall

    • <PredeterminedScopeAssignmentIdentifier> wird anstatt <WasteTypeID> verwendet, wenn der Abfall in REDA nicht erfasst ist

    • mögliche Kontaminationen

    • das Nettogewicht

    • die VEBSV-ID

    • ADR-Informationen

    • ob es ein POP-Abfall ist

  • der Übergeber, mögliche Streckenpartner und ein Übernehmer

Übernahmebestätigungs-Message

Diese Message wird vom Übernehmer/Empfänger gesendet, wenn alle Abfälle erhalten und überprüft worden sind. Die UUID s in <Shipment> und den <ShipmentItem> s sind dabei die gleichen, wie in der zugehörigen Übergabe-/Übernahme-Message. Die Werte der Abfälle sind dabei so, wie sie der Übernehmer erfasst hat und müssen nicht mit der Übernahme-/Übergabe-Message übereinstimmen (z.B. Angabe einer abweichenden Abfallart).

<MessageEnvelope>
    <MessageData>
        <Shipment>
            <UUID>[shipment uuid]</UUID>
            <PredeterminedScopeAssignmentID>Auftrag X</PredeterminedScopeAssignmentID>
            <ShipmentItem>
                <UUID>[some uuid]</UUID>
                <WasteTypeID collectionID="5174">[waste type gtin]</WasteTypeID>
                <WasteContaminationTypeID collectionID="7835">[contamination gtin]</WasteContaminationTypeID>
                <Description>...</Description>
                <Package>...</Package>
                <GrossPropertyStatement>...</GrossPropertyStatement>
                <NetPropertyStatement>...</NetPropertyStatement>
                <ConsignmentNoteReferenceID>[vebsv-id]</ConsignmentNoteReferenceID>
                <ContainsPersistentOrganicPollutant>true</ContainsPersistentOrganicPollutant>
            </ShipmentItem>
        </Shipment>
    </MessageData>
</MessageEnvelope>

Ablehnungs-Message

Der Übernehmer kann anstatt einer Übernahmebestätigung auch eine Ablehnung senden. Dabei muss der Grund im <RejectionReasonID>-Element spezifiziert werden. Ein möglicher Grund könnte sein, dass es sich um eine andere Abfallart handelt, für welche der Übernehmer keine Berechtigung (Erlaubnis oder Genehmigung) besitzt

<MessageEnvelope>
    <MessageData>
        <Shipment>
            <UUID>[shipment uuid]</UUID>
            <PredeterminedScopeAssignmentID>Auftrag X</PredeterminedScopeAssignmentID>
            <ShipmentItem>
                <UUID>[some uuid]</UUID>
                <WasteTypeID collectionID="5174">[waste type gtin]</WasteTypeID>
                <WasteContaminationTypeID collectionID="7835">[contamination gtin]</WasteContaminationTypeID>
                <Description>...</Description>
                <Package>...</Package>
                <GrossPropertyStatement>...</GrossPropertyStatement>
                <NetPropertyStatement>...</NetPropertyStatement>
                <ConsignmentNoteReferenceID>[vebsv-id]</ConsignmentNoteReferenceID>
                <ContainsPersistentOrganicPollutant>true</ContainsPersistentOrganicPollutant>
            </ShipmentItem>
            <RejectionReasonID collectionID="1234">[rejection reason gtin]</RejectionReasonID>
        </Shipment>
    </MessageData>
</MessageEnvelope>

Transport bezogene Messages

Transport-Message

Mit einer Transport-Message können Transporte organisiert werden. Der Absender ist der Transportorganisator (auch Veranlasser). Dieser muss keine in der Message definierte Rolle einnehmen (siehe Streckengeschäft). Die Empfänger der Message sind die restlichen, in der Message genannten, Personen. Zu einer Übergabe/Übernahme kann es mehrere Transporte geben (siehe Komplexe Transporte).

<MessageEnvelope>
    <ListedData>
        <!-- Persons, organizations, local units -->
        ...
        <Shipment>
            <DocumentScopeAssignmentID>shipment</DocumentScopeAssignmentID>
            <UUID>[shipment uuid]</UUID>
            <PredeterminedScopeAssignmentID>...</PredeterminedScopeAssignmentID>
            <Designation>...</Designation>
            <ShipmentItem>
                <DocumentScopeAssignmentID>shipment_item</DocumentScopeAssignmentID>
                <UUID>[shipment item uuid]</UUID>
                <PredeterminedScopeAssignmentID>...</PredeterminedScopeAssignmentID>
                <Designation>...</Designation>
            </ShipmentItem>
        </Shipment>
    </ListedData>
    <MessageData>
        <TransportMovement>
            <UUID>[transport uuid]</UUID>
            <PredeterminedScopeAssignmentID>[Auftrags-ID]</PredeterminedScopeAssignmentID>
            <TransportMeans>
                <PredeterminedScopeAssignmentID>[transport label]</PredeterminedScopeAssignmentID>
                <ModeID collectionID="2939">[mode gtin]</ModeID>
            </TransportMeans>
            <PlannedWaypointEvent>
                <Period>...</Period>
                <SiteLocalUnitReferenceID>pickup_location</SiteLocalUnitReferenceID>
                <PartyReferenceID>pickup_party</PartyReferenceID>
                <LoadingWaypoint>true</LoadingWaypoint>
                <TransshipmentWaypoint>[true/false]</TransshipmentWaypoint>
                <InitialParyReferenceID>initial_party</InitialParyReferenceID>
                <InitialSiteLocalUnitReferenceID>initial_location</InitialSiteLocalUnitReferenceID>
            </PlannedWaypointEvent>
            <PlannedWaypointEvent>
                ...
                <LoadingWaypoint>false</LoadingWaypoint>
                ...
            </PlannedWaypointEvent>
            <TransportItem>
                <ShipmentItemReferenceID>shipment_item</ShipmentItemReferenceID>
                <ServiceTypeID>[waste-type]</ServiceTypeID>
                <WasteTypeID collectionID="5174">[waste type gtin]</WasteTypeID>
                <WasteContaminationTypeID collectionID="7835">[contamination gtin]</WasteContaminationTypeID>
                <NetPropertyStatement>...</NetPropertyStatement>
                <ConsignmentNoteReferenceID>[vebsv-id]</ConsignmentNoteReferenceID>
                <DangerousGoodsDescription>...</DangerousGoodsDescription>
                <ContainsPersistentOrganicPollutant>true</ContainsPersistentOrganicPollutant>
            </TransportItem>
            <CarrierPartyReferenceID>carrier</CarrierPartyReferenceID>
        </TransportMovement>
    </MessageData>
</MessageEnvelope>

Die Daten werden innerhalb des <TransportMovement>-Elements angegeben. Diese sind:

  • eine eindeutige UUID

  • eine Auftrags-ID

  • das Kennzeichen des Transportmittels und um welche Transportart es sich handelt (Straße, Luft, Wasser, Schiene)

  • der "Ladewegpunkt" (<LoadingWaypoint> ist true), welcher folgende Informationen enthält:

    • einen geplanten Abholzeitraum

    • den Ladeort

    • die am Ladeort zuständige Person

    • ob die Abholung am Wegpunkt eine Umladung ist

      • wenn ja, dann zusätzlich noch den ursprünglichen Ladeort und die dazugehörige Person

  • den "Abladewegpunkt" (<LoadingWaypoint> ist false) mit derselben Struktur

  • Transportgüter mit

    • einer Referenz eines Abfalls in <ListedData>, damit es dem Abfall der Übergabe/Übernahme-Message zugeordnet werden kann

    • einem <ServiceTypeID>-Element, wenn es sich um einen nicht in REDA erfassten Abfall handelt

    • die Abfallart, wenn diese in REDA erfasst ist

    • mögliche Kontaminationen

    • das Nettogewicht

    • die VEBSV-ID

    • ADR-Informationen

    • ob es ein POP-Abfall ist

  • die Person, die den Transport durchführt

Transportstart-Message

Diese Message wird direkt bei Transportstart vom Transporteur an die anderen genannten Personen gesendet. Die UUID in <TransportMovement ist dabei dieselbe, wie in der zugehörigen Transport-Message. Der Zeitpunkt des Transportstarts wird angegeben, wie auch die mitgeführten Abfälle. Sollte sich der tatsächliche Startzeitpunkt vom geplanten unterscheiden, so muss die Transport-Message nicht korrigiert werden, da es sich bloß um geplante Informationen handelt.

<MessageEnvelope>
    <ListedData>
        <Shipment>...</Shipment>
    </ListedData>
    <MessageData>
        <TransportMovement>
            <UUID>[transport uuid]</UUID>
            <ActualWaypointEvent>
                <DateTime>2024-01-01T12:00:00</DateTime>
            </ActualWaypointEvent>
            <TransportItem>...</TransportItem>
        </TransportMovement>
    </MessageData>
</MessageEnvelope>

Transportabschluss- u. Empfangsbestätigungs-Message

Diese Messages werden vom Transporteur, bzw. vom Empfänger gesendet.

<MessageEnvelope>
    <ListedData>...</ListedData>
    <MessageData>
        <TransportMovement>
            <UUID>[transport uuid]</UUID>
            <ActualWaypointEvent>
                <DateTime>[date of unloading/reciption]</DateTime>
            </ActualWaypointEvent>
            <TransportItem>...</TransportItem>
        </TransportMovement>
    </MessageData>
</MessageEnvelope>

Transportabbruchs-Message

Aus verschiedenen Gründen kann es zu Transportabbrüchen kommen, z.B. wenn es durch einen Unfall zu einem Ladeverlust kommt. In solchen Situationen wird eine Transportabbruchs-Message gesendet. Der Grund für den Abbruch muss im <AbortReasonID>-Element spezifiziert werden. Optional kann auch ein Wegpunkt angegeben werden, der den Unfallort beschreibt.

<MessageEnvelope>
    <ListedData>
        <LocalUnit>...</LocalUnit>
        <Shipment>...</Shipment>
    </ListedData>
    <MessageData>
        <TransportMovement>
            <UUID>[transport uuid]</UUID>
            <AbortReasonID collectionId="8723">[abort reason gtin]</AbortReasonID>
            <ActualWaypointEvent>
                <DateTime>2024-01-01T12:00:00</DateTime>
                <SiteLocalUnitReferenceID>...</SiteLocalUnitReferenceID>
            </ActualWaypointEvent>
            <TransportItem>...</TransportItem>
        </TransportMovement>
    </MessageData>
</MessageEnvelope>

Meldungsarten (Begleitschein-Schnittstelle)

Ähnlich zu den verschiedenen Message-Typen, gibt es auch im Begleitschein-System Meldungen, die sich auf die Übergabe/Übernahme beziehen und solche, die sich auf einen Transport beziehen. In den folgenden Abschnitten werden die verschiedenen sogenannten "Type-Events" gezeigt, die den Inhalt der Meldung ausmachen. Diese sind Teil von ShareDocument-Requests.

Anders als beim Messaging-Webservice verwendet das Begleitschein-Webservice keine <xs:assert> in den Schema-Files. Stattdessen sind die Validierungen im Webservice implementiert, welche auch umfangreicher sind als in Messaging. Daher wird bei den einzelnen Meldungen auf die jeweiligen Validierungen eingegangen.

Übergabe-/Übernahme bezogene Meldungen

Diese Meldungen besitzen ein TypeAEvent.

Übergabe-Deklaration

Die Übergabedeklaration wird vom Übergeber des Geschäfts eingebracht und beschreibt den Begleitschein aus dessen Sicht. Dazu gehört an wen, von wo aus und welcher Abfall übergeben wird.


  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29


  
<TypeAEvent>
    <TypeID collectionID="8926">[gtin]</TypeID> (1)
    <Date>...</Date> (2)
    <DateTime>...</DateTime>
    <Object> (3)
        <TypeID collectionID="5174">[waste gtin]</TypeID>
        <SubTypeID collectionID="7835">[contamination gtin]</SubTypeID>
        <PropertyStatement>
            <PropertyKindID collectionID="5618">9008390104439</PropertyKindID>
            <ValueAssignmentStatement>
                <NumericValue unitID="kg">100.0</NumericValue>
            </ValueAssignmentStatement>
            <MethodID collectionID="7299">9008390100028</MethodID>
        </PropertyStatement>
        <ContainsPersistentOrganicPollutant>[true/false]</ContainsPersistentOrganicPollutant>
    </Object>
    <AssociatedObjectReferenceID roleID="9008390104576" collectionID="9008390104026"> (4)
        [vebsv-id]
    </AssociatedObjectReferenceID>
    <AssociatedObjectDocumentScopeReferenceID roleID="9008390104705"> (5)
        [handover reference]
    </AssociatedObjectDocumentScopeReferenceID>
    <AssociatedObjectDocumentScopeReferenceID roleID="9008390104712"> (6)
        [takeover reference]
    </AssociatedObjectDocumentScopeReferenceID>
    <AssociatedObjectDocumentScopeReferenceID roleID="9008390108338"> (7)
        [handover location reference]
    </AssociatedObjectDocumentScopeReferenceID>
</TypeAEvent>
1 Folgende Werte sind erlaubt:

  • Transport mit physischer Abfall-Übergabe bzw. –Übernahme durch den Meldenden
    Dabei handelt es sich um eine gewöhnliche Übergabe. Auch wenn es sich um ein Streckengeschäft handelt, ist dieser Wert zu verwenden.

  • Ohne Transport/Begleitschein am Empfangsort
    Darf nur in absoluten Ausnahmefällen verwendet werden, bei denen der Abfall im Zuge der Abfallübergabe(n) überhaupt nicht transportiert wird, wie z.B. bei Kauf eines Abfallzwischenlagers samt den darin befindlichen Abfällen. Wird dieser Wert ausgewählt, so wird eine Begründung erwartet.
2 Datum oder Zeitpunkt der Übergabe. Nur ein Element ist auswählbar.
3 Angaben zum Abfall:

  • Abfallart (ggf. mit Spezifizierung)

  • Kontamination(en)

  • Angaben zur Masse

  • Angabe ob POP-Abfall oder nicht
4 Die VEBSV-ID des Begleitscheins.
5 Eine Referenz zu einem Eintrag in ListedData für den Übergeber.
6 Eine Referenz zu einem Eintrag in ListedData für den Übernehmer. Im Streckengeschäft ist diese der direkte Partner (sohin der jeweils unmittelbar nachfolgende Geschäftspartner) des Übergebers bzw. Streckengeschäftspartners.
7 Eine Referenz zu einem Eintrag in ListedData für den Übergabeort.

Validierungen im Webservice

  • Grundsätzliche Validierungen

    • Exakt ein TypeAEvent, keine TypeBEvents und TypeCEvents

    • Angabe von <TypeID> und dessen Wert darf nicht "Streckengeschäft" sein

      • Wenn Wert "ohne Transport" beträgt, dann muss <ReasonID> oder <ReasonDescription> angegeben sein

    • Keine Angabe von <ProcessTypeID>

    • Keine Angabe von <DeviatingAssignmentReasonDescription>

    • <Date> oder <DateTime> darf nicht in Vergangenheit liegen

    • Keine Angabe von <RejectionReasonID>

  • Validierungen in Bezug auf den Abfall

    • Genau ein Abfall

    • Die Abfallart muss angegeben sein

    • Kontaminationen müssen eindeutig sein

    • Die angegebene Größenart muss "Masse" sein

    • Das Gewicht in "kg" muss angegeben sein

    • Die Quantifizierungsmethode muss angegeben sein

  • Validierungen in Bezug zu VEBSV-ID

    • Korrekte Angabe der VEBSV-ID

    • Bei Korrektur: selbe VEBSV-ID wie ursprüngliche Meldung

    • Zeitpunkt der Erstellung der VEBSV-ID und angegebene(s/r) Datum/Zeitpunkt nicht mehr als 365 Tage auseinander

  • Validierungen in Bezug zu Personen/Organisationen/LocalUnits

    • Nur die Rollen "Übergeber", "Übernehmer" u. "Beginnstelle" sind erlaubt

    • Exakt eine Person/Organisation mit der Rolle "Übergeber"

    • Exakt eine Person/Organisation mit der Rolle "Übernehmer"

    • Zusammengehörigkeit "Übergeber" und Meldender

    • LocalUnits besitzen die Rolle "Beginnstelle"

    • Der LocalUnit-Typ "Standort" muss vorkommen

    • LocalUnit-Typen dürfen nur je einmal vorkommen

    • Wenn zusätzlich, mittels Anlagen-GLN, eine (ortsfeste oder mobile) Anlage angegeben ist, dann muss auch ein registrierter Standort (mittels Standort-GLN) angegeben sein.

    • Wenn eine ortsfeste Anlage angegeben ist, dann muss diese im ZAReg zum angegebenen Standort gehören

    • Wenn, mittels Standort-GLN, ein im ZAReg registrierter Standort angegeben ist, dann muss dieser zur zugehörigen Person gehören (z.B. erster Übergeber u. Absendeort, Empfänger u. Empfangsort).

Strecken-Meldung

Diese Meldung wird vom sogenannten Streckenmelder oder Streckenorganisator eingebracht. Diese Rolle fällt meist mit dem Organisator und Initiator des gesamten Geschäfts zusammen, da dieser einen Überblick über alle Teilnehmer haben muss. Mit dieser Meldung wird die gesamte "Kette" der Übergaben/Übernahmen in ihrer tatsächlichen, korrekten Reihenfolge eingebracht.

Da der Streckenorganisator auch im Namen anderer Streckenpartner einmeldet, wird empfohlen, dass eine Bestätigung dafür eingeholt wird. Das Messaging-Webservice bietet mit ShareRetrieverStatus dafür eine Möglichkeit. Hier wird ein Beispiel dazu gezeigt.

 

  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16


  
<TypeAEvent>
    <Date>...</Date> (1)
    <DateTime>...</DateTime>
    <AssociatedObjectReferenceID roleID="9008390104576" collectionID="9008390104026"> (2)
        [vebsv-id]
    </AssociatedObjectReferenceID>
    <AssociatedObjectDocumentScopeReferenceID roleID="9008390104705"> (3)
        [handover reference]
    </AssociatedObjectDocumentScopeReferenceID>
    <AssociatedObjectDocumentScopeReferenceID roleID="9008390104712"> (4)
        [takeover reference]
    </AssociatedObjectDocumentScopeReferenceID>
    <AssociatedObjectDocumentScopeReferenceID roleID="9008390117231"> (5)
        [dropshipping partner reference]
    </AssociatedObjectDocumentScopeReferenceID>
</TypeAEvent>
1 Datum oder Zeitpunkt der Übergaben/Übernahmen. Nur ein Element ist auswählbar.
2 Die VEBSV-ID des Begleitscheins
3 Eine Referenz zu einem Eintrag in ListedData für den ersten Übergeber.
4 Eine Referenz zu einem Eintrag in ListedData für den Empfänger des Streckengeschäfts.
5 Eine Referenz zu einem Eintrag in ListedData für einen Streckenpartner. Diese Rolle kann öfters vorkommen, aber mindestens einmal. Die Reihenfolge ist relevant, d.h. der erste Streckenpartner ist der direkte Partner des Übergebers, der letzte Streckenpartner ist der direkte Partner des Empfängers.

Validierungen im Webservice

  • Grundsätzliche Validierungen

    • Exakt ein TypeAEvent, keine TypeBEvents und TypeCEvents

    • Angabe von <TypeID> und dessen Wert muss "mit Transport mit Streckengeschäft" sein

    • <Date> oder <DateTime> darf nicht mehr als sechs Wochen in der Vergangenheit liegen

    • keine Angabe von <ReasonID> oder <ReasonDescription>

    • Keine Angabe von <ProcessTypeID>

    • Keine Angabe von <DeviatingAssignmentReasonDescription>

    • Keine Angabe von <RejectionReasonID>

  • Keine Angabe zu einem Abfall

  • Validierungen in Bezug zu VEBSV-ID

    • Korrekte Angabe der VEBSV-ID

    • Bei Korrektur: selbe VEBSV-ID wie ursprüngliche Meldung

    • Zeitpunkt der Erstellung der VEBSV-ID und angegebene(s/r) Datum/Zeitpunkt nicht mehr als 365 Tage auseinander

  • Validierungen in Bezug zu Personen/Organisationen/LocalUnits

    • Nur die Rollen "Übergeber", "Übernehmer" und "Weiterer Abfallsammler" sind erlaubt

    • Exakt eine Person/Organisation mit der Rolle "Übergeber"

    • Exakt eine Person/Organisation mit der Rolle "Übernehmer"

    • Mindestens eine Person/Organisation mit der Rolle "Weiterer Abfallsammler"

Übernahme-Meldung

Mit der Übernahme-Meldung bestätigt der Empfänger die Übernahme der Abfälle. Die Eigenschaften des Abfalls werden so angegeben, wie sie der Empfänger erfasst hat, auch wenn sie sich von Angaben der Übergabe-Meldung unterscheiden. Selbst eine andere Abfallart kann angegeben werden, falls dies der Tatsache entspricht.


  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30


  
<TypeAEvent>
    <TypeID collectionID="8926">[gtin]</TypeID> (1)
    <Date>...</Date> (2)
    <DateTime>...</DateTime>
    <DeviatingAssignmentReasonDescription>...</DeviatingAssignmentReasonDescription> (3)
    <Object> (4)
        <TypeID collectionID="5174">[waste gtin]</TypeID>
        <SubTypeID collectionID="7835">[contamination gtin]</SubTypeID>
        <PropertyStatement>
            <PropertyKindID collectionID="5618">9008390104439</PropertyKindID>
            <ValueAssignmentStatement>
                <NumericValue unitID="kg">100.0</NumericValue>
            </ValueAssignmentStatement>
            <MethodID collectionID="7299">9008390100028</MethodID>
        </PropertyStatement>
        <ContainsPersistentOrganicPollutant>[true/false]</ContainsPersistentOrganicPollutant>
    </Object>
    <AssociatedObjectReferenceID roleID="9008390104576" collectionID="9008390104026"> (5)
        [vebsv-id]
    </AssociatedObjectReferenceID>
    <AssociatedObjectDocumentScopeReferenceID roleID="9008390104705"> (6)
        [handover reference]
    </AssociatedObjectDocumentScopeReferenceID>
    <AssociatedObjectDocumentScopeReferenceID roleID="9008390104712"> (7)
        [takeover reference]
    </AssociatedObjectDocumentScopeReferenceID>
    <AssociatedObjectDocumentScopeReferenceID roleID="9008390108345"> (8)
        [takeover location reference]
    </AssociatedObjectDocumentScopeReferenceID>
</TypeAEvent>
1 Die Art der Übernahme, ob es sich um eine Übernahme mit oder ohne Transport handelte. Bei einer Übernahme ohne Transport wird eine Begründung erwartet.
2 Datum oder Zeitpunkt der Übernahme. Nur ein Element ist auswählbar.
3 Falls die Abfallart von der Übergabe-Deklaration abweicht, wird hier eine Begründung erwartet.
4 Angaben zum Abfall aus Sicht des Empfängers
5 Die VEBSV-ID des Begleitscheins
6 Eine Referenz zu einem Eintrag in ListedData für den Übergeber. Im Streckengeschäft ist diese der direkte Partner des Empfängers.
7 Eine Referenz zu einem Eintrag in ListedData für den Empfänger.
8 Eine Referenz zu einem Eintrag in ListedData für den Empfangsort.

Validierungen im Webservice

  • Grundsätzliche Validierungen

    • Exakt ein TypeAEvent, keine TypeBEvents und TypeCEvents

    • Angabe von <TypeID> und dessen Wert darf nicht "Streckengeschäft" sein

      • Wenn der Wert "ohne Transport" beträgt, dann muss <ReasonID> oder <ReasonDescription> angegeben sein

    • <Date> oder <DateTime> darf nicht in der Zukunft liegen und auch nicht mehr als sechs Wochen in der Vergangenheit

    • Keine Angabe von <RejectionReasonID>

  • Validierungen in Bezug auf den Abfall

    • Mindestens ein Abfall (Grundsätzlich darf je VEBSV-ID nur ein Abfall gemeldet werden. Falls aber der Empfänger feststellt, dass es sich in Wahrheit um verschiedene Abfälle handelt, sind im Ausnahmefall mehrere möglich)

    • Die Abfallart muss angegeben sein

    • Kontaminationen müssen eindeutig sein

    • Die angegebene Größenart muss "Masse" sein

    • Das Gewicht in "kg" muss angegeben sein

    • Die Quantifizierungsmethode muss angegeben sein

  • Validierungen in Bezug zu VEBSV-ID

    • Korrekte Angabe der VEBSV-ID

    • Bei Korrektur: selbe VEBSV-ID wie ursprüngliche Meldung

    • Zeitpunkt der Erstellung der VEBSV-ID und angegebene(s/r) Datum/Zeitpunkt nicht mehr als 365 Tage auseinander

  • Validierungen in Bezug zu Personen/Organisationen/LocalUnits

    • Nur die Rollen "Übergeber", "Übernehmer" u. "Endstelle" sind erlaubt

    • Exakt eine Person/Organisation mit der Rolle "Übergeber"

    • Exakt eine Person/Organisation mit der Rolle "Übernehmer"

    • Zusammengehörigkeit "Übernehmer" und Meldender

    • LocalUnits besitzen die Rolle "Endstelle"

    • Der LocalUnit-Typ "Standort" muss vorkommen

    • LocalUnit-Typen dürfen nur je einmal vorkommen

    • Wenn zusätzlich, mittels Anlagen-GLN, eine (ortsfeste oder mobile) Anlage angegeben ist, dann muss auch ein registrierter Standort (mittels Standort-GLN) angegeben sein.

    • Wenn eine ortsfeste Anlage angegeben ist, dann muss diese im ZAReg zum angegebenen Standort gehören

    • Wenn registrierter Standort, dann muss dieser zum Übernehmer gehören

Ablehnungs-Meldung

Aus verschiedenen Gründen kann ein Empfänger die Abfallübernahme verweigern, wodurch anstatt der Übernahme-Meldung eine Ablehnungs-Meldung gesendet wird. Gründe dafür sind z.B., dass es sich um eine andere Abfallart als deklariert handelt und der Empfänger die Annahme dieser anderen Abfallart verweigert oder dass es während des Transports zu einem Ladeverlust kam und so der Empfänger nicht übernehmen kann.


  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27


  
<TypeAEvent>
    <TypeID collectionID="8926">[gtin]</TypeID> (1)
    <Date>...</Date> (2)
    <DateTime>...</DateTime>
    <Object> (3)
        <TypeID collectionID="5174">[waste gtin]</TypeID>
        <SubTypeID collectionID="7835">[contamination gtin]</SubTypeID>
        <PropertyStatement>
            <PropertyKindID collectionID="5618">9008390104439</PropertyKindID>
            <ValueAssignmentStatement>
                <NumericValue unitID="kg">100.0</NumericValue>
            </ValueAssignmentStatement>
            <MethodID collectionID="7299">9008390100028</MethodID>
        </PropertyStatement>
        <ContainsPersistentOrganicPollutant>[true/false]</ContainsPersistentOrganicPollutant>
    </Object>
    <AssociatedObjectReferenceID roleID="9008390104576" collectionID="9008390104026"> (4)
        [vebsv-id]
    </AssociatedObjectReferenceID>
    <AssociatedObjectDocumentScopeReferenceID roleID="9008390104705"> (5)
        [handover reference]
    </AssociatedObjectDocumentScopeReferenceID>
    <AssociatedObjectDocumentScopeReferenceID roleID="9008390104712"> (6)
        [takeover reference]
    </AssociatedObjectDocumentScopeReferenceID> (7)
    <RejectionReasionID collectionID="3161">[gtin]</RejectionReasionID>
</TypeAEvent>
1 Die Art der Übernahme, ob es sich um eine Übernahme mit oder ohne Transport handelte. Bei einer Übernahme ohne Transport wird eine Begründung erwartet.
2 Datum oder Zeitpunkt der Übernahme. Nur ein Element ist auswählbar.
3 Angaben zum Abfall aus Sicht des Empfängers. Dieses Feld ist optional.
4 Die VEBSV-ID des Begleitscheins
5 Eine Referenz zu einem Eintrag in ListedData für den Übergeber. Im Streckengeschäft ist diese der direkte Partner des Empfängers.
6 Eine Referenz zu einem Eintrag in ListedData für den Empfänger.
7 Der Ablehnungsgrund

Validierungen im Webservice

  • Grundsätzliche Validierungen

    • Exakt ein TypeAEvent, keine TypeBEvents und TypeCEvents

    • Angabe von <TypeID> und dessen Wert darf nicht "Streckengeschäft" sein

      • Wenn Wert "ohne Transport" beträgt, dann muss <ReasonID> oder <ReasonDescription> angegeben sein

    • Keine Angabe von <ProcessTypeID>

    • <Date> oder <DateTime> darf nicht in der Zukunft liegen und auch nicht mehr als sechs Wochen in der Vergangenheit

    • Angabe von <RejectionReasonID>

  • Validierungen in Bezug auf den Abfall

    • keiner, einer oder mehrere (optional)

    • Die Abfallart muss angegeben sein

    • Kontaminationen müssen eindeutig sein

    • Die angegebene Größenart muss "Masse" sein

    • Das Gewicht in "kg" muss angegeben sein

    • Die Quantifizierungsmethode muss angegeben sein

  • Validierungen in Bezug zu VEBSV-ID

    • Korrekte Angabe der VEBSV-ID

    • Bei Korrektur: selbe VEBSV-ID wie ursprüngliche Meldung

    • Zeitpunkt der Erstellung der VEBSV-ID und angegebene(s/r) Datum/Zeitpunkt nicht mehr als 365 Tage auseinander

  • Validierungen in Bezug zu Personen/Organisationen/LocalUnits

    • Nur die Rollen "Übergeber", "Übernehmer" sind erlaubt

    • Exakt eine Person/Organisation mit der Rolle "Übergeber"

    • Exakt eine Person/Organisation mit der Rolle "Übernehmer"

    • Zusammengehörigkeit "Übernehmer" und Meldender

Transport-bezogene Meldungen

Eine Transport-bezogene Meldung setzt sich aus TypeBEvent und TypeCEvent Elementen zusammen. Ein TypeBEvent beschriebt Eigenschaften des Transports, während ein TypeCEvent einen Wegpunkt des Transports beschreibt.

Transport-Deklaration

Die Transportdeklaration wird im Vorfeld eingemeldet und kündigt einen Transport an. Sowohl der Veranlasser, als auch der Transporteur können diese einmelden.


  
1
2
3
4
5
6
7
8
9
10
11
12
13
14


  
<TypeBEvent>
    <DocumentScopeAssignmentID>...</DocumentScopeAssignmentID> (1)
    <Object> (2)
        <PredeterminedScopeAssignmentID>[transport means id]</PredeterminedScopeAssignmentID>
        <TypeID collectionID="2939">[transport mode]</PredeterminedScopeAssignmentID>
    </Object>
    <AssociatedObjectDocumentScopeReferenceID roleID="9008390116913"> (3)
        [transport organizer reference]
    </AssociatedObjectReferenceID>
    <AssociatedObjectDocumentScopeReferenceID roleID="9008390116906"> (4)
        [carrier reference]
    </AssociatedObjectReferenceID>
    <TransportId>[transport uuid]</TransportId> (5)
</TypeBEvent>
1 Bezeichnung innerhalb der Meldung; wird in TypeCEvents verwendet
2 Angaben zu Transportmittelkennzeichen und Transportart (Straße, Schiene, Wasserweg, Luftweg)
3 Referenz zu einem Eintrag in ListedData für den Veranlasser
4 Referenz zu einem Eintrag in ListedData für den Transporteur
5 UUID des Transports. Es wird derselbe Wert verwendet, der auch schon in Messaging für denselben Transport verwendet wurde.

Validierungen im Webservice

  • exakt ein TypeBEvent, kein TypeAEvent

  • Angabe von <DocumentScopeAssignmentID>

  • Angabe eines Kennzeichens

  • Angabe der Transportart

  • Exakt eine Person/Organisation mit der Rolle "Veranlasser"

  • Exakt eine Person/Organisation mit der Rolle "Transporteur"

  • Keine weitere Person/Organisation/LocalUnit

  • Angabe von <TransportId>

  • Zusammengehörigkeit von "Veranlasser" oder "Transporteur" mit dem Meldenden

Zur Transportdeklaration gehören außerdem noch zwei Wegpunkte: Einer für den Beladeort und einer für den Abladeort.


  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30


  
<TypeCEvent>
    <TypeID collectionID="8501">[gtin]</TypeID> (1)
    <SubTypeID collectionID="3789">9008390116418</SubTypeID> (2)
    <Date>...</Date> (3)
    <DateTime>...</DateTime>
    <Object> (4)
        <TypeID collectionID="5174">[waste gtin]</TypeID>
        <SubTypeID collectionID="7835">[contamination gtin]</SubTypeID>
        <PropertyStatement>
            <PropertyKindID collectionID="5618">9008390104439</PropertyKindID>
            <ValueAssignmentStatement>
                <NumericValue unitID="kg">100.0</NumericValue>
            </ValueAssignmentStatement>
            <MethodID collectionID="7299">9008390100028</MethodID>
        </PropertyStatement>
        <ContainsPersistentOrganicPollutant>[true/false]</ContainsPersistentOrganicPollutant>
    </Object>
    <AssociatedObjectReferenceID roleID="9008390104576" collectionID="9008390104026"> (5)
        [vebsv-id]
    </AssociatedObjectReferenceID>
    <AssociatedObjectDocumentScopeReferenceID roleID="9008390104576"> (6)
        [transport reference]
    </AssociatedObjectDocumentScopeReferenceID>
    <AssociatedObjectDocumentScopeReferenceID roleID="9008390104583"> (7)
        [party reference]
    </AssociatedObjectDocumentScopeReferenceID>
    <AssociatedObjectDocumentScopeReferenceID roleID="9008390108321"> (8)
        [location reference]
    </AssociatedObjectDocumentScopeReferenceID>
</TypeCEvent>
1 Definiert, ob es ein "Beladeort" oder "Abladeort" ist.
2 Definiert, ob es sich um einen "Umladewegpunkt" handelt.
3 Datum oder Zeitpunkt des geplanten Transports. Nur ein Element ist auswählbar.
4 Angaben zum Transportgut
5 Die VEBSV-ID des Begleitscheins
6 Referenz des TypeBEvents
7 Eine Referenz zu einem Eintrag in ListedData für die zuständige Person.
8 Eine Referenz zu einem Eintrag in ListedData für den Belade-/Abladeort.

Validierungen im Webservice

  • Grundsätzliche Validierungen

    • zwei TypeCEvents, kein TypeAEvent

    • Angabe von <TypeID>, einmal mit "Beladen" u. einmal mit "Entladen"

    • Angabe von <Date> oder <DateTime>

    • Angabe einer Referenz des TypeBEvents

  • Validierungen in Bezug auf den Abfall

    • Genau ein Abfall

    • Die Abfallart muss angegeben sein

    • Kontaminationen müssen eindeutig sein

    • Die angegebene Größenart muss "Masse" sein

    • Das Gewicht in "kg" muss angegeben sein

    • Die Quantifizierungsmethode muss angegeben sein

  • Validierungen in Bezug zu VEBSV-ID

    • Korrekte Angabe der VEBSV-ID

    • Bei Korrektur: selbe VEBSV-ID wie ursprüngliche Meldung

    • Zeitpunkt der Erstellung der VEBSV-ID und angegebene(s/r) Datum/Zeitpunkt nicht mehr als 365 Tage auseinander

  • Validierungen in Bezug zu Personen/Organisationen/LocalUnits

    • Nur die Rollen "Verantw. Akteur" u. "Stelle" sind erlaubt

    • Exakt eine Person/Organisation mit der Rolle "Verantw. Akteur"

    • LocalUnits besitzen die Rolle "Stelle"

    • Der LocalUnit-Typ "Standort" muss vorkommen

    • LocalUnit-Typen dürfen nur je einmal vorkommen

    • Wenn zusätzlich, mittels Anlagen-GLN, eine (ortsfeste oder mobile) Anlage angegeben ist, dann muss auch ein registrierter Standort (mittels Standort-GLN) angegeben sein.

    • Wenn eine ortsfeste Anlage angegeben ist, dann muss diese im ZAReg zum angegebenen Standort gehören

Abfalltransportbeginn-Meldung

Die Abfalltransportbeginn-Meldung wird bei Transportbeginn vom Transporteur eingemeldet. Anschließend ist der Begleitschein auch für die Behörde einsehbar.


  
1
2
3
4
5
6
7
8
9
10
11


  
<TypeBEvent>
    <DocumentScopeAssignmentID>...</DocumentScopeAssignmentID>
    <Object>
        <PredeterminedScopeAssignmentID>[transport means id]</PredeterminedScopeAssignmentID>
        <TypeID collectionID="2939">[transport mode]</PredeterminedScopeAssignmentID>
    </Object>
    <AssociatedObjectDocumentScopeReferenceID roleID="9008390116906"> (4)
        [carrier reference]
    </AssociatedObjectReferenceID>
    <TransportId>[transport uuid]</TransportId>
</TypeBEvent>

Im Unterschied zur Transport-Deklaration wird der Veranlasser hier nicht angegeben. Es wird außerdem nur der "Beladewegpunkt" angegeben.

Validierungen im Webservice

  • exakt ein TypeBEvent, kein TypeAEvent

  • Angabe von <DocumentScopeAssignmentID>

  • Angabe eines Kennzeichens

  • Angabe der Transportart

  • Exakt eine Person/Organisation mit der Rolle "Transporteur"

  • Keine weitere Person/Organisation/LocalUnit

  • Angabe von <TransportId>

  • Zusammengehörigkeit von "Transporteur" mit dem Meldenden


  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17


  
<TypeCEvent>
    <TypeID collectionID="8501">[gtin]</TypeID>
    <DateTime>...</DateTime>
    <Object>...</Object>
    <AssociatedObjectReferenceID roleID="9008390104576" collectionID="9008390104026">
        [vebsv-id]
    </AssociatedObjectReferenceID>
    <AssociatedObjectDocumentScopeReferenceID roleID="9008390104576">
        [transport reference]
    </AssociatedObjectDocumentScopeReferenceID>
    <AssociatedObjectDocumentScopeReferenceID roleID="9008390104583">
        [party reference]
    </AssociatedObjectDocumentScopeReferenceID>
    <AssociatedObjectDocumentScopeReferenceID roleID="9008390108321">
        [location reference]
    </AssociatedObjectDocumentScopeReferenceID>
</TypeCEvent>

Es kann hier nur ein Zeitpunkt für den Transportbeginn angegeben werden, welcher nicht in der Zukunft liegen darf. Der Rest bleibt gleich zur Transport-Deklaration.

Validierungen im Webservice

  • Grundsätzliche Validierungen

    • exakt ein TypeCEvent, kein TypeAEvent

    • Angabe von <TypeID> mit dem Wert "Beladen"

    • Angabe von <DateTime>, keine Angabe von <Date>. Dieses darf nicht in der Zukunft liegen.

    • Angabe einer Referenz des TypeBEvent

  • Validierungen in Bezug auf den Abfall

    • Genau ein Abfall

    • Die Abfallart muss angegeben sein

    • Kontaminationen müssen eindeutig sein

    • Die angegebene Größenart muss "Masse" sein

    • Das Gewicht in "kg" muss angegeben sein

    • Die Quantifizierungsmethode muss angegeben sein

  • Validierungen in Bezug zu VEBSV-ID

    • Korrekte Angabe der VEBSV-ID

    • Bei Korrektur: selbe VEBSV-ID wie ursprüngliche Meldung

    • Zeitpunkt der Erstellung der VEBSV-ID und angegebene(s/r) Datum/Zeitpunkt nicht mehr als 365 Tage auseinander

  • Validierungen in Bezug zu Personen/Organisationen/LocalUnits

    • Nur die Rollen "Verantw. Akteur" u. "Stelle" sind erlaubt

    • Exakt eine Person/Organisation mit der Rolle "Verantw. Akteur"

    • LocalUnits besitzen die Rolle "Stelle"

    • Der LocalUnit-Typ "Standort" muss vorkommen

    • LocalUnit-Typen dürfen nur je einmal vorkommen

    • Wenn zusätzlich, mittels Anlagen-GLN, eine (ortsfeste oder mobile) Anlage angegeben ist, dann muss auch ein registrierter Standort (mittels Standort-GLN) angegeben sein.

    • Wenn eine ortsfeste Anlage angegeben ist, dann muss diese im ZAReg zum angegebenen Standort gehören

Transportabbruchs-Meldung

Wenn der Transport aus verschiedenen Gründen nicht fortgesetzt werden kann und abgebrochen wird, ist es möglich, eine Transportabbruchmeldung zu senden.


  
1
2
3
4
5
6
7
8
9
10
11
12


  
<TypeBEvent>
    <DocumentScopeAssignmentID>...</DocumentScopeAssignmentID>
    <Object>
        <PredeterminedScopeAssignmentID>[transport means id]</PredeterminedScopeAssignmentID>
        <TypeID collectionID="2939">[transport mode]</PredeterminedScopeAssignmentID>
    </Object>
    <AssociatedObjectDocumentScopeReferenceID roleID="9008390116906">
        [carrier reference]
    </AssociatedObjectReferenceID>
    <TransportId>[transport uuid]</TransportId>
    <AbortReasonID collectionID="8723">[gtin]</AbortReasonID>
</TypeBEvent>

Es muss ein Abbruchgrund angegeben werden. Zudem muss eine abgespeckte Version des TypeCEvent angegeben werden.

Validierungen im Webservice

  • exakt ein TypeBEvent, kein TypeAEvent

  • Angabe von <DocumentScopeAssignmentID>

  • Angabe eines Kennzeichens oder einer Transportart

  • Exakt eine Person/Organisation mit der Rolle "Transporteur"

  • Keine weitere Person/Organisation/LocalUnit

  • Angabe von <TransportId>; bei einer Korrektur muss derselbe Wert verwendet werden, wie in der ursprünglichen Meldung

  • Angabe von <AbortReasonID>

  • Zusammengehörigkeit von "Transporteur" mit dem Meldenden


  
1
2
3
4
5
6
7
8
9


  
<TypeCEvent>
    <DateTime>...</DateTime>
    <AssociatedObjectReferenceID roleID="9008390104576" collectionID="9008390104026">
        [vebsv-id]
    </AssociatedObjectReferenceID>
    <AssociatedObjectDocumentScopeReferenceID roleID="9008390104576">
        [transport reference]
    </AssociatedObjectDocumentScopeReferenceID>
</TypeCEvent>

Validierungen im Webservice

  • Grundsätzliche Validierungen

    • exakt ein TypeCEvent, kein TypeAEvent

    • Keine Angabe von <TypeID>

    • Angabe von <DateTime>, keine Angabe von <Date>. Dieses darf nicht in der Zukunft liegen.

    • Angabe einer Referenz des TypeBEvent

  • Keine Angabe eines Abfalls

  • Validierungen in Bezug zu VEBSV-ID

    • Korrekte Angabe der VEBSV-ID

    • Bei Korrektur: selbe VEBSV-ID wie ursprüngliche Meldung

    • Zeitpunkt der Erstellung der VEBSV-ID und angegebene(s/r) Datum/Zeitpunkt nicht mehr als 365 Tage auseinander

  • Keine Angabe zu Personen/Organisationen/LocalUnits

Kommunikation zwischen Beteiligten

Senden - Empfangen - Antwortsignal

Das folgende Diagramm soll zeigen, wie die Kommunikation zwischen zwei Beteiligten funktioniert. Dabei nimmt AbfallProfi GmbH die Rolle des Senders und Müll Logistik die des Empfängers ein. Bei beiden handelt es sich um fiktive Firmen.

AbfallProfi GmbHEDM MessagingMüll LogistikShareDocumentRequestTrUUIDT1ContextUUIDC1VBracketUUIDVB1VSeqNr0DocUUIDD1RecipientsMüll LogistikContentXXXMessageShareDocumentResponseOKQueryUpdateRequestStartRangeT0IncludeStartfalseQueryUpdateResponseForw.Sh.EventT1RetrieveDocumentRequestTrUUIDT1RetrieveDocumentResponseTrUUIDT1ContextUUIDC1VBracketUUIDVB1VSeqNr0DocUUIDD1ContentXXXMessageShareRetrieverStatusRequestTrUUIDT2RefTrUUIDT1StateSuccessTextsome text...ShareRetrieverStatusResponseOKQueryUpdateRequestStartRangeT1IncludeStartfalseQueryUpdateResponseBackw.Sh.EventT2

Wie im Abschnitt Messaging WS-Operationen beschrieben, wird ein ShareDocument dazu verwendet, um Daten zum Geschäftsfall auszutauschen, indem Messages versendet werden. Diese Message findet sich im DocumentContent-Element. Sofern der ShareDocumentRequest erfolgreich validiert wurde, erhält der Sender ein ShareDocumentResponse. Die TransactionUUID wird hier simpel als T1 angegeben.

Durch das Polling mittels QueryUpdate erhält ein Benutzer Neuigkeiten, die ihn betreffen. In diesem Beispiel wird T0 als die TransactionUUID angenommen, die dem Benutzer zuletzt bekannt war. Als Antwort erhält Müll Logistik nun das ForwardSharingEvent, das für das vorherige ShareDocument erzeugt wurde. Neben dem DocumentHeader, der einem Benutzer ermöglicht das Event zuzuordnen, ist auch die TransactionUUID des ShareDocumentRequests enthalten.

Mit dieser kann schließlich das gesamte Dokument durch ein RetrieveDocument erhalten werden.

Ein Empfänger einer Nachricht kann schließlich eine Antwort als Signal mit einem ShareRetrieverStatus senden. Dabei wird die TransactionUUID des ursprünglichen ShareDocumentRequests angegeben. Das daraus erzeugte BackwardSharingEvent kann schließlich der ursprüngliche Sender, erneute durch ein Polling, abrufen.

Da die Kommunikation sich im Detail recht kompliziert als Diagramm darstellt und viel Platz einnimmt, wird folgend eine kompaktere Darstellung verwendet.

AbfallProfi GmbHMüll LogistikXXXMessageTrUUIDT1ContextUUIDC1VBracketUUIDVB1VSeqNr0DocUUIDD1

Die Art der Message wird direkt beim "Nachrichten-Block" als Kopfelement angegeben. Die Empfänger werden durch Pfeile symbolisiert. Schwarz, wenn das Validieren erfolgreich war und Rot, wenn es fehlschlug.

Das "Backward-Sharing" wird mit einem weiteren Pfeil vom Empfänger zum Absender dargestellt. Dabei steht Grün für eine "positive" und Rot für eine "negative" Antwort.

Der Inhalt des "Nachrichten-Blocks" kann sowohl Header-Informationen als auch explizite Informationen innerhalb der Message enthalten. Jedoch werden nur die Informationen dargestellt, die für das jeweilige Beispiel relevant sind.

Senden mit Post-Processing Fehler

Das Messaging-Webservice selbst überprüft nur, ob der konkrete Message-Inhalt eines ShareDocument-Request dem Schema entspricht. Inhaltliche Überprüfungen werden erst im Post-Processing durchgeführt. Dabei entstehende Fehler sind für den Absender daher nur asynchron sichtbar.

Ein Beispiel für eine Validierung, die erst im Post-Processing passiert, ist das Überprüfen der Abfälle. Ist ein Abfall meldepflichtig oder ein POP-Abfall, dann muss dieser auch eine VEBSV-ID beinhalten. Fehlt diese, so wird die Message "abgelehnt" und ein Processing-Event erzeugt. Weitere Validierungen sind im Kapitel Weitere Post-Processing Validierungen Dokumentiert.

AbfallProfi GmbHEDM MessagingMüll LogistikShareDocumentRequestTrUUIDT1...RecipientsMüll LogistikContentXXXMessagew. post-proc.errorShareDocumentResponseOKQueryUpdateRequestStartRangeT0IncludeStartfalseQueryUpdateResponseQueryUpdateRequestStartRangeT1EndRangeT1IncludeStarttrueIncludeEndtrueQueryUpdateResponseProc.EventT1Q.Doc.ValidationRequestRefTrUUIDT1Q.Doc.ValidationResponseValidationResults...

Wie das Diagramm zeigt, sendet AbfallProfi GmbH eine Message mit einem inhaltlichen Fehler und erhält trotzdem eine ShareDocument-Response mit Status "OK". Führt der angegebene Empfänger nun ein Polling durch, so enthält die Liste der Update-Events kein Event, dass vom Absender der Nachricht erstellt wurde.

Führt der Absender jedoch ein Polling durch, in diesem Fall will er exakt das Update-Event vom ShareDocument, so enthält die Response ein Processing-Event. Dieses zeigt an, dass ein Fehler im Post-Processing aufgetreten ist.

Der Absender kann nun mittels eines QueryDocumentValidationResult-Request mehr Informationen über den Fehler erhalten. Die Antwort enthält schließlich eine Liste an Fehlern.

Korrekturen, Korrekturvorschläge und Stornierungen

Damit Empfänger einer Nachricht ihre eigene Sicht auf einen Geschäftsfall mitteilen können, stellt das Messaging-Webservice weitere Funktionen bereit, die insbesondere die folgenden Probleme vermeiden sollen:

  • Jeder Beteiligte kann die Daten eines anderen verändern.

  • Niemand kann sicher sein, dass jeder jede Nachricht erhalten hat.

Aus diesen Problemen wurden die folgenden Prinzipien hergeleitet:

  • Der initiale Ersteller bestimmt die tatsächlichen Daten.

  • Das Messaging-Webservice gewährleistet, dass der initiale Ersteller und die Empfänger einer Nachricht immer denselben Datenstand besitzen.

  • Unnötige Nachrichten, bzw. Nachrichten ohne Auswirkungen sollen verhindert werden.

  • Der Datenstand soll jederzeit rekonstruierbar sein.

Aus diesen Prinzipien folgt, dass nur der initiale Ersteller einer Nachricht die Daten korrigieren bzw. stornieren kann. Empfänger der Nachricht können sogenannte Korrekturvorschläge einbringen. Jedoch entscheidet nur der initiale Ersteller, ob oder in welcher Form diese Korrekturvorschläge umgesetzt werden sollen. Detaillierte Regeln, die sich aus den oben genannten Prinzipien ergeben, werden in den folgenden Unterabschnitten genauer erläutert. Alle vorgestellten Regeln werden vom Messaging-Webservice validiert und bei einem Verstoß wird die Nachricht nicht zugelassen.

Wichtige Begrifflichkeiten

  • Initialer Ersteller: Ersteller der ursprünglichen Nachricht

  • Ursprüngliche Nachricht/Message: die erste Nachricht der Message-Reihe

  • Message-Reihe: die ursprüngliche Nachricht und alle Korrekturen; alle Nachrichten/Messages derselben Message-Reihe besitzen dieselbe VersionBracketUUID

  • Aktuelle Nachricht/Message: die aktuellste Nachricht der Message-Reihe

  • Referenzierte Nachricht/Message: die Nachricht, auf die sich ein Korrekturvorschlag bezieht

Korrekturen

Eine Korrektur einer Nachricht wird erstellt, indem eine neue Message mittels ShareDocument gesendet wird. Dabei wird dieselbe VersionBracketUUID wie in der ursprünglichen Nachricht verwendet. Die VersionSequenceNumber muss dabei höher sein als die der aktuellen Nachricht. Die TransactionUUID und DocumentUUID sind hingegen immer einzigartig. Nur der initiale Ersteller kann eine Korrektur erstellen.

MüllMeister 24(Erster Übergeber)AbfallProfi GmbH(Empfänger, Veranlasser)Müll Logistik(Transporteur)TrMsgTrUUIDT1DocUUIDD1VBracketUUIDVB1VSeqNr0TrMsgTrUUIDT2DocUUIDD2VBracketUUIDVB1VSeqNr1

Weitere wichtige Regeln sind:

  • Eine Korrektur muss dieselben Empfänger besitzen wie die ursprüngliche Nachricht.

  • Eine Korrektur benötigt zwingend eine ChangeReasonID.

  • Eine stornierte Message-Reihe kann nicht mehr korrigiert werden.

  • Folgende Elemente müssen im DocumentHeader einer Korrektur gleich bleiben:

    • DocumentTypeID: Der Typ der Nachricht muss dieselbe bleiben.

    • ObjectUUID: Die Nachricht muss dasselbe Datenobjekt betreffen.

    • DocumentOriginPartyID: Der Nachrichtenersteller muss derselbe bleiben.

    • ContextUUID: Die Korrektur muss zum selben Auftrag gehören.

Eine Korrektur überschreibt die aktuell gültigen Daten komplett. Besitzt die ursprüngliche Nachricht nur einen Abfall und es soll ein weiterer hinzufügt werden, so reicht es nicht aus, dass die Korrektur nur den neuen Abfall enthält. Die Korrektur muss beide Abfälle enthalten.

Stornierungen

Eine Stornierung wird auf eine gesamte Message-Reihe angewendet. Dabei wird die VersionBracketUUID für die ShareDocumentCancellation verwendet. Daraus ergibt sich auch, dass eine Korrektur nicht zurückgenommen werden kann. Man kommt jedoch zum vorherigen Datenstand zurück, indem man erneut korrigiert und dabei den dieselben Daten verwendet, die vorher gültig waren. Nur der initiale Ersteller kann die Stornierung durchführen.

MüllMeister 24(Erster Übergeber)AbfallProfi GmbH(Empfänger, Veranlasser)Müll Logistik(Transporteur)TrMsgTrUUIDT1DocUUIDD1VBracketUUIDVB1VSeqNr0TrMsgTrUUIDT2DocUUIDD2VBracketUUIDVB1VSeqNr1ShareDocCancelReqVBracketUUIDVB1

Zusätzlich gibt es noch folgende Regeln für Stornierungen:

  • Eine Stornierung muss dieselben Empfänger besitzen, wie die ursprüngliche Nachricht.

  • Bereits stornierte Reihen können nicht erneut storniert werden.

  • Eine Stornierung braucht zwingend eine ChangeReasonID.

Wie kann ein Empfänger einer Message-Reihe eine Stornierung bewerkstelligen? Nur ein initialer Ersteller kann die tatsächlichen Daten bestimmen. Daraus ergibt sich auch, dass ein Empfänger keine Stornierung durchführen kann.

Ein Empfänger kann dem Absender jedoch signalisieren, dass dieser einer Stornierung vornehmen soll. Dies geschieht durch ein ShareRetrieverStatus-Request mit negativen Status. Wichtig dabei ist das Wort "signalisieren". Der Absender kann weiterhin entscheiden, ob er die Stornierung durchführt oder nicht.

Das folgende Diagramm soll dieses Signalisieren darstellen.

MüllMeister 24(Erster Übergeber)AbfallProfi GmbH(Empfänger, Veranlasser)Müll Logistik(Transporteur)TrMsgTrUUIDT1DocUUIDD1VBracketUUIDVB1VSeqNr0

Korrekturvorschläge

Damit ein Empfänger einer Nachricht die aus seiner Sicht gültigen Daten mitteilen kann, gibt es Korrekturvorschläge. Diese könnten z.B. verwendet werden, um den Ersteller der Nachricht auf Fehler hinzuweisen. Aber auch Felder, die in der Nachricht freigelassen wurden, da diese Informationen im Bereich eines Empfängers liegen, können dadurch ergänzt werden. Wie es der Name bereits impliziert, handelt es sich bloß um Vorschläge. Wie diese Vorschläge miteinbezogen werden, liegt beim initialen Ersteller.

MüllMeister 24(Erster Übergeber)AbfallProfi GmbH(Empfänger, Veranlasser)Müll Logistik(Transporteur)TrMsgTrUUIDT1DocUUIDD1VBracketUUIDVB1VSeqNr0TrMsgTrUUIDT2DocUUIDD2VBracketUUIDVB2VSeqNr0RefDocUUIDD1

Um eine Nachricht als Korrekturvorschlag zu kennzeichnen, wird im DocumentHeader des ShareDocumentRequest das Feld ReferencedDocumentUUID verwendet. Der Wert dieses Feld ist dabei die DocumentUUID der ursprünglichen Nachricht. Neben der TransactionUUID und DocumentUUID, die immer einzigartig sein müssen, hat ein Korrekturvorschlag auch seine eigene VersionBracketUUID.

Die Regeln für Korrekturvorschläge sind:

  • Der Ersteller des Korrekturvorschlags muss ein Empfänger der ursprünglichen Nachricht sein.

  • Falls der initiale Ersteller selbst ein Empfänger ist, so darf dieser keinen Korrekturvorschlag erstellen.

  • Der einzige Empfänger des Korrekturvorschlags ist der initiale Ersteller.

  • Ein Empfänger kann nur einen "aktiven" Korrekturvorschlag erstellen. Ein Korrekturvorschlag gilt als aktiv, wenn:

    • der Korrekturvorschlag selbst nicht storniert ist.

    • die referenzierte Nachricht die aktuelle innerhalb der Message-Reihe ist.

  • Es gibt keine Korrekturvorschläge von Korrekturvorschlägen.

  • Die referenzierte Nachricht muss zum Zeitpunkt des Sendens die aktuelle Nachricht sein.

  • Der DocumentHeader muss für die folgenden Elemente dieselben Werte wie die referenzierte Nachricht enthalten:

    • DocumentTypeID: Der Typ der Nachricht muss dieselbe bleiben.

    • ObjectUUID: Die Nachricht muss dasselbe Datenobjekt betreffen.

    • ContextUUID: Der Korrekturvorschlag muss zum selben Auftrag gehören.

Korrekturen und Stornierungen von Korrekturvorschlägen

Ein Korrekturvorschlag kann selbst wieder korrigiert oder storniert werden. Dabei gelten die gleichen Regeln wie für Korrekturen und Stornierungen.

MüllMeister 24(Erster Übergeber)AbfallProfi GmbH(Empfänger, Veranlasser)Müll Logistik(Transporteur)TrMsgTrUUIDT1DocUUIDD1VBracketUUIDVB1VSeqNr0TrMsgTrUUIDT2DocUUIDD2VBracketUUIDVB2VSeqNr0RefDocUUIDD1TrMsgTrUUIDT3DocUUIDD3VBracketUUIDVB2VSeqNr1RefDocUUIDD1ShareDocCancelReqVBracketUUIDVB2

Für die Korrekturen von Korrekturvorschlägen gilt nun auch, dass der Wert des ReferencedDocumentUUID-Elements gleich bleiben muss. Außerdem gilt für das Korrigieren und Stornieren von Korrekturvorschlägen, dass die referenzierte Nachricht auch die aktuelle Nachricht sein muss. Dies ist der Fall, wenn die ursprüngliche Message-Reihe nach einem Korrekturvorschlag korrigiert worden ist. Der simple Grund dafür ist, dass man Änderungsvorschläge für nicht mehr gültige Daten einbringen würde und somit unnötigen Aufwand erzeugt. Will man jedoch weitere Änderungen einbringen, so muss ein neuer Korrekturvorschlag mit eigener VersionBracketUUID erstellt werden, der die aktuelle Nachricht referenziert. Das folgende Diagramm soll diese Regeln verdeutlichen.

MüllMeister 24(Erster Übergeber)AbfallProfi GmbH(Empfänger, Veranlasser)Müll Logistik(Transporteur)TrMsgTrUUIDT1DocUUIDD1VBracketUUIDVB1VSeqNr0TrMsgTrUUIDT2DocUUIDD2VBracketUUIDVB2VSeqNr0RefDocUUIDD1TrMsgTrUUIDT3DocUUIDD3VBracketUUIDVB1VSeqNr1TrMsgTrUUIDT4DocUUIDD4VBracketUUIDVB2VSeqNr1RefDocUUIDD1ShareDocCancelReqVBracketUUIDVB2TrMsgTrUUIDT4DocUUIDD4VBracketUUIDVB3VSeqNr0RefDocUUIDD3
Akzeptieren und Ablehnen von Korrekturvorschlägen

Ein explizites Akzeptieren oder Ablehnen von Korrekturvorschlägen gibt es nicht. Korrekturvorschläge haben den Status "offen" und "geschlossen" bzw. "aktiv" und "nicht aktiv". Der einzige Weg, die tatsächlichen Daten zu verändern, ist durch eine Korrektur des initialen Erstellers. Wenn man nun nur die Header-Daten der Korrektur berücksichtigt, so kann man nicht darauf schließen, ob Änderungen vom Korrekturvorschlag übernommen wurden. Vielleicht wurden sie übernommen, vielleicht wurde auch mit völlig anderen Daten korrigiert. Vielleicht wurden die Daten der Korrektur aus mehreren Korrekturvorschlägen verschiedener Empfänger zusammengesetzt.

Um trotzdem einen Informationsaustausch zu ermöglichen, ob nun Änderungen von Korrekturvorschlägen miteinbezogen oder abgelehnt werden, kann die Webservice-Operation ShareRetrieverStatus verwendet werden. Durch Verwendung von Status und Freitext Felder können Antworten, wie "abgelehnt, weil …​", "angenommen, aber …​", etc. formuliert werden.

MüllMeister 24(Übergeber)AbfallProfi GmbH(Empfänger, Veranlasser)Müll Logistik(Transporteur)TrMsgTrUUIDT1DocUUIDD1VBracketUUIDVB1VSeqNr0TrMsgTrUUIDT2DocUUIDD2VBracketUUIDVB2VSeqNr0RefDocUUIDD1TrMsgTrUUIDT3DocUUIDD3VBracketUUIDVB2VSeqNr1RefDocUUIDD1TrMsgTrUUIDT4DocUUIDD4VBracketUUIDVB3VSeqNr0RefDocUUIDD1TrMsgTrUUIDT5DocUUIDD5VBracketUUIDVB1VSeqNr1

In diesem Beispiel wurde zuerst ein Korrekturvorschlag von MüllMeister AG abgelehnt, woraufhin dieser korrigiert und schließlich akzeptiert wurde. Gleichzeitig wurde ein weiterer Korrekturvorschlag von Müll Logistik akzeptiert. Für die Korrektur der initialen Nachricht wurden nun die Änderungen von beiden Seiten eingearbeitet.

Für Softwarehersteller und Benutzer ist es jedoch wichtig zu beachten und zu verstehen, dass es beim Signalisieren von "Annehmen" bzw. "Ablehnen" in der Praxis viele Spielarten geben kann. So könnte der initiale Ersteller ein Ablehnen signalisieren, bei einer Korrektur die Änderungen aber eins zu eins übernehmen. Dasselbe gilt auch umgekehrt für das Akzeptieren und mit völlig anderen Daten korrigieren. Auch ist es möglich, dass akzeptiert wird, ohne ein Signal zu senden oder trotz des akzeptierten Signals keine weitere Korrektur mehr folgt. Die Signale sollten verstanden werden, wie "Der initiale Ersteller hat gesagt, dass die Änderungen übernommen werden", was nicht gleichzusetzen ist mit: "Der initiale Ersteller hat die Änderungen übernommen". Denn, nur die Inhalte der aktuellen Nachricht sind die tatsächlichen Daten.

Senden einer Meldung und Query-Update in Messaging

Wurde eine Meldung (bzw. deren Korrektur oder Stornierung) erfolgreich eingebracht, so erhält das Messaging-System eine Benachrichtigung vom Begleitschein-Webservice. Mit diesen Informationen wird ein UpdateSignal-Event erzeugt. Dieses enthält die VEBSV-ID des Begleitscheins, um welche Meldungsart es sich handelte und ob es eine Einmeldung, Korrektur oder Stornierung war. Dieses Event können alle durch ein Query-Update empfangen, die auch in der Meldung genannt wurden. Zusätzlich enthält es noch die Transport-UUID, falls es sich um eine Transport-bezogene Meldung handelte. Dadurch kann ein Client auf einfache Weise abfragen, ob bestimmte Meldungen zu Abfällen bereits erfolgt sind und diese Information dazu nutzen, um den aktuellen Status des Geschäftsfalls zu bestimmen.

Wie bereits erwähnt, erhalten nur die in der Meldung genannten Personen das UpdateSignal-Event. Wird diese Information trotzdem benötigt, auch wenn man in der Meldung nicht erwähnt wird, so gibt es weiterhin die Möglichkeit der RetrieveDocument-Operation des Begleitschein-Webservices. Mit dieser erhält man den aktuellen Begleitschein aus Sicht des Nutzers.

Im Streckengeschäft erhält der Empfänger das UpdateSignal-Event der Übergabe-Deklaration nicht. Wird jedoch ein RetrieveDocument durchgeführt, so enthält der Begleitschein ein DeclaredWasteObject-Element, das aufgrund der Übergabe-Deklaration existiert.

Regeln für das Senden von Messages und Meldungen

Durch Korrekturen und Stornierungen ergeben sich eine Vielzahl an möglichen Status (States) und Zustandsübergängen (State-Transitions) eines Datenobjekts (Übergabe/Übernahme, Transport, Begleitschein, Abfall, …​). Beispielsweise wird die zugrundeliegende Transport-Message eines Transports storniert, nachdem dieser bereits gestartet wurde. Man würde vielleicht die Stornierung als Client ignorieren, da sie zu diesem Zeitpunkt unsinnig wirkt. Was jedoch, wenn anschließend die Transportstart-Message ebenfalls storniert wird? Ist die Transport-Message noch aktiv, sprich nicht storniert? Oder greift die Stornierung der Transport-Message nun im Nachhinein?

Man erkennt, dass die Antwort darauf nicht trivial ist. Zudem ist dies nur ein Beispiel von vielen. Es ergeben sich eine Vielzahl von Ausnahmefällen, die von einem Entwickler berücksichtigt werden müssen, um Stabilität und eine korrekte Darstellung der Daten zu gewährleisten. Dies würde zu einem enormen Aufwand ausarten und könnte auch zu einem unterschiedlichen Datenstand zwischen Beteiligten führen, weil ein anderer Client die Ausnahmefälle anders interpretieren könnte.

Um diesem Problem zu begegnen, validieren die beiden Webservices neu ankommende Messages/Meldungen, indem sie diese mit bereits gesendeten Messages/Meldungen desselben Datenobjekts in den Kontext setzt und prüft, ob die aktuelle Message/Meldung gesendet werden kann oder nicht. Dabei stellen die Webservices sicher, dass bestimmte Messages, Meldungen, Korrekturen oder Stornierungen zu gewissen Zeitpunkten nicht gesendet werden können. Dadurch müssen Clients die Vielzahl an Ausnahmezuständen nicht berücksichtigen.

Regeln des Messaging-Webservices

Wann können welche Messages gesendet werden?

Wann im Messaging-Webservice welche Messages gesendet werden können, kann mithilfe von Zustandsdiagrammen dargestellt werden. Es folgen ein Zustandsdiagramm für transportbezogene Messages und eines für Übergabe-/Übernahme-Messages. Die Diagramme sind etwas vereinfacht. Genauere Regeln werden im Folgenden erläutert.

  • In einem Zustand können die Messages, die gesendet werden können, um diesen Zustand zu erreichen, auch gesendet werden. Beispiel: Im Zustand Transport gestartet können immer noch TransportStart Messages gesendet werden.

  • In einem Zustand können immer die Messages korrigiert und Korrekturvorschläge für Messages eingereicht werden, die gesendet werden können, um diesen Zustand zu erreichen. Beispiel: Im Zustand Transport gestartet können TransportStart Messages korrigiert werden.

  • Um mittels Stornieren einer Message in einen neuen Zustand zu kommen, müssen alle Messages storniert werden, die gesendet wurden, um in den Zustand zu kommen. Beispiel: Wenn zwei TransportStart Messages gesendet wurden müssen auch wieder zwei TransportStart Messages storniert werden, um in den Zustand Transport geplant zu kommen.

Wie genau die Zustandsübergänge aussehen, ist auch im letzten Diagramm am Beispiel "Zustand Transport gestartet" zu sehen.

Diagram Zustände Transportbezogene Messages
Zustände Transportbezogene Messages
Diagram Zustände Übergabe-/Übernahme-Message
Zustände Übergabe-/Übernahme-Message
Diagram Beispiel "Zustand Transport gestartet"
Beispiel "Zustand Transport gestartet"
Weitere Post-Processing Validierungen

Im Messaging-Webservice gibt es noch weitere Validierungen bei denen Post-Processing Fehler entstehen können.

  • Der Absender einer Transportstart-Message, Transportabschluss-Message oder Transportabbruchs-Message muss der Transporteur sein.

  • Der Absender einer Empfangsbestätigungs-Message muss der Empfänger sein.

  • Der Absender einer Übernahmebestätigungs-Message, muss der Übernehmer sein.

  • Wenn eine Transportstart-Message gesendet wird müssen folgende Daten in einer aktiven Transport-Message angegeben sein:

    • Transporteur

    • Übernehmer und Übernahmeort

    • Übergeber und Übergabeort

    • Transportmittel wenn es nicht in der Transport-Message angegeben ist

    • Transportart wenn sie nicht in der Transport-Message angegeben ist

  • Wenn eine Transportstart-Message gesendet wird müssen alle aktiven Transport-Messages den gleichen Inhalt für folgende Daten haben:

    • Transportgüter

    • Transporteur

    • Übernehmer und Übernahmeort

    • Übergeber und Übergabeort

    • Transportmittel wenn es nicht in der Transport-Message angegeben ist

    • Transportart wenn sie nicht in der Transport-Message angegeben ist

  • Wenn eine Message gesendet wird, in der Adressen in ListedData-Objekten angegeben werden, müssen für alle Adressen mindestens folgende Adresskomponenten angegeben werden: Land, Postleitzahl, Straße, Ort, Hausnummer

Regeln des Begleitschein-Webservices

Allgemeine Regeln

  • Die nachfolgenden Regeln gelten ab Version 1.9 des Begleitschein-Webservices.

  • Stornierung und Korrektur:

    • Jede Meldung, die storniert werden kann, kann auch korrigiert werden.

    • In der Beschreibung sind daher Storno und Korrektur immer gemeinsam zu verstehen.

  • Die Identifikation der Vorgänge erfolgt über die VEBSV-ID.

Übergabe-Deklaration

  • Eine Übergabe-Deklaration kann gesendet werden, wenn noch keine andere Übergabe-Deklaration mit derselben VEBSV-ID existiert.

  • Eine Übergabe-Deklaration ist stornierbar, solange kein gültiger Transportbeginn existiert.

Transport-Deklaration

  • Für die Transport-Deklaration gelten grundsätzlich dieselben Regeln wie für die Übergabe-Deklaration.

  • Besonderheit bei komplexen Transporten:

    • Die Transport-Deklaration bezieht sich immer auf den Transportbeginn desselben Transports.

    • Existiert lediglich ein Transportbeginn eines anderen Transports mit derselben VEBSV-ID, bleibt die Transport-Deklaration weiterhin stornierbar.

Streckenmeldung

  • Eine Streckenmeldung kann jederzeit eingebracht werden.

  • Sie ist jedoch nur bis zum Vorliegen einer Übernahme- oder Ablehnungs-Meldung stornierbar.

Abfalltransportbeginn-Meldung

  • Die Abfalltransportbeginn-Meldung kann nur gesendet werden, wenn:

    • eine Übergabe-Deklaration existiert und nicht storniert wurde, und die dazugehörige Transport-Deklaration existiert und nicht storniert wurde.

  • Die Meldung ist stornierbar, bis eine der folgenden Meldungen vorliegt:

    • Transportabbruch-Meldung oder

    • Übernahme- bzw. Ablehnungs-Meldung.

  • Mit dem Senden der Abfalltransportbeginn-Meldung wird der Begleitschein für die Behörde sichtbar.

    • Diese Sichtbarkeit bleibt dauerhaft bestehen, auch wenn der Transportbeginn später storniert wird.

Transportabbruch-Meldung

  • Ein Transportabbruch kann nur erfolgen, wenn:

    • ein gültiger Transportbeginn existiert, und

    • noch keine Übernahme- oder Ablehnungs-Meldung vorliegt.

  • Die Transportabbruch-Meldung selbst ist nicht stornierbar.

Übernahme- bzw. Ablehnungs-Meldung

  • Eine Übernahme- oder Ablehnungs-Meldung kann nur gesendet werden, wenn:

    • keine der beiden Meldungen bereits existiert, und

    • alle deklarierten Transporte gestartet wurden, und

    • bei einem Streckengeschäft zusätzlich eine Streckenmeldung vorliegt.

  • Sowohl die Übernahme- als auch die Ablehnungs-Meldung sind jederzeit stornierbar.

Authentifizierung

Neben der Authentifizierung des Benutzers wird auch die Identität der verwendeten Software überprüft. Dafür werden zwei Schlüssel benötigt, das User-Secret und das Connector-Secret. Das User-Secret wird in Folge auch Applikationspasswort genannt.

Ein Softwarehersteller der einen Client für die beiden Webservices entwickelt, muss ein Connector-Secret beim EDM-Helpdesk beantragen. Neben dem mit dem Connector-Secret erstellten HMAC wird auch eine Connector-ID übermittelt. Das Connector-Secret und die Connector-ID müssen in der Software hinterlegt werden.

Jede Instanz einer ausgelieferten Anwendung verwendet dasselbe Connector-Secret und dieselbe Connector-ID.

Ein Benutzer Ihrer Software muss sich das Applikationspasswort im EDM-Portal selbst erzeugen. Beim Erzeugen des Applikationspassworts muss auch ein VEBSV Benutzername angegeben werden. Nur Hauptbenutzer und Nebenbenutzer mit der Rolle "Benutzerverwalter" des Registrierten sind dazu in der Lage. Das Applikationspasswort muss, gemeinsam mit dem VEBSV Benutzernamen, in der Software hinterlegt werden, sodass die Software beim Aufrufen einer WS-Operation die Authentifizierung ordnungsgemäß durchführen kann.

Das Applikationspasswort muss sicher und vor unbefugten Zugriffen geschützt gespeichert werden. Wenn der Verdacht besteht, dass das Applikationspasswort an die Öffentlichkeit gelangt ist, muss der User (bzw. der Hauptbenutzer oder Benutzerverwalter) ein neues Applikationspasswort generieren.

Erstellung der Authentifizierungs-Tags

Für die Authentifizierung des Zugriffs auf die Webservices wird HMAC SHA-256 verwendet.

HMAC ist die Abkürzung für Hash-based Message Authentification Code und ist ein Verfahren, bei dem ein Geheimschlüssel (Shared Secret) gemeinsam mit einer Nachricht und einer Hash-Funktion verwendet wird, um einen sogenannten "Authentifizierungs-Tag" zu erzeugen. Dabei ist SHA-256 die verwendete Hash-Funktion.

Es gibt Zahlreiche implementierungen von HMAC in Kombination mit SHA-256, auf die zurückgegriffen werden sollte.

Die für die HMAC als Nachricht zu verwendende Zeichenfolge hängt von der Webservice-Operation ab. Es werden für die User- u. Connector-Authentifizierung jeweils verschiedene Zeichenfolgen verwendet. Diese ähneln sich jedoch.

Für das Messaging-Webservice gilt Folgendes:

(Die Werte in den spitzen Klammern <> sind nicht als XML Tags gemeint. Sie sind mit den tatsächlichen Werten zu ersetzen.)

Operation Verwendete Inhalte Für die HMAC zu verwendende Zeichenfolge

ShareDocument

TransactionUUID
DocumentUUID

Connector:
<TransactionUUID>\n<DocumentUUID>\nShareDocument

User:
<TransactionUUID>\n<DocumentUUID>

ShareDocumentCancellation

TransactionUUID
VersionBracketUUID

Connector:
<TransactionUUID>\n<VersionBracketUUID>\nShareDocumentCancellation

User:
<TransactionUUID>\n<VersionBracketUUID>

ShareRetrieverStatus

TransactionUUID

Connector:
<TransactionUUID>\n\nShareRetrieverStatus

User:
<TransactionUUID>\n

RefreshBinding

TransactionUUID

Connector:
<TransactionUUID>\n\nRefreshBinding

User:
<TransactionUUID>\n

LaunchDocumentAction

TransactionUUID

Connector:
<TransactionUUID>\n\nLaunchDocumentAction

User:
<TransactionUUID>\n

QueryUpdate

UpdateRangeStartUUID

Connector:
<UpdateRangeStartUUID>\n\nQueryUpdate

User:
keine User-Authentifizierung

RetrieveDocument

ReferredTransactionUUID

Connector:
<ReferredTransactionUUID>\n\nRetrieveDocument

User:
<ReferredTransactionUUID>\n

QueryDocumentValidationResult

ReferredTransactionUUID

Connector:
<ReferredTransactionUUID>\n\nQueryDocumentValidationResult

User:
<ReferredTransactionUUID>\n

Ähnlich wird die Zeichenkette für die Authentifizierung zum Begleitschein-Webservice zusammengesetzt. Jedoch wird immer exakt ein Inhalt des Requests verwendet:

Operation Verwendeter Inhalt Für die HMAC zu verwendende Zeichenfolge

ShareDocument

TransactionUUID

Connector
<TransactionUUID>\nShareDocument

User:
<TransactionUUID>

CancelDocument

TransactionUUID

Connector
<TransactionUUID>\nCancelDocument

User:
<TransactionUUID>

RequestWasteTransferID

TransactionUUID

Connector
<TransactionUUID>\nRequestWasteTransferID

User:
<TransactionUUID>

QueryTransactionStatus

ReferredTransactionUUID

Connector
<ReferredTransactionUUID>\nQueryTransactionStatus

User:
<ReferredTransactionUUID>

QueryValidationResult

ReferredTransactionUUID

Connector
<ReferredTransactionUUID>\nQueryValidationResult

User:
<ReferredTransactionUUID>

RetrieveDocument

WasteTransferID

Connector
<WasteTransferID>\nRetrieveDocument

User:
<WasteTransferID>

Seien k1 und k2 das Connector- und User-Secret, m1 und m2 die verwendeten Zeichenfolgen basierend auf einer beliebigen Webservice-Operation und s1 und s2 die erzeugten Authentifizierungs-Tags.

Weiters sei SHA256 die SHA-256 Hash-Funktion und

HMAC Definition

die HMAC Funktion mit SHA-256 als Hash-Funktion.

Das Authentifizierungs-Tag für das Connector-Secret wird folgendermaßen berechnet:

Conncector HMAC Formula

Das Authentifizierungs-Tag für das User-Secret wird hingegen folgendermaßen berechnet:

User HMAC Formula

Daraus ergibt sich, dass das Connector-Secret direkt verwendet wird, wohingegen das User-Secret zuerst mit SHA-256 gehasht wird, bevor es in der HMAC Funktion verwendet wird.

Folgend werden die Authentifizierungs-Tags als Connector-HMAC und User-HMAC bezeichnet.

Beispiele

HMACs für RefreshBinding (Messaging-Webservice)

// initialization
contentConnector      = "d66d48bb-5891-462a-8cbb-6444ea7a0be9\n\nRefreshBinding"
connectorSecretBase64 = "c2VjcmV0Qnl0ZXNWYWx1ZQ=="
connectorSecretHex    = "736563726574427974657356616c7565"

contentUser           = "d66d48bb-5891-462a-8cbb-6444ea7a0be9\n"
appPwBase64           = "Mjc2NTQ4OTA3MTg3NjQ3MTE="
appPwBaseHex          = "3237363534383930373138373634373131"
appPwSHA256Hex        = "5a528ffa8debae672c496a203cf8ea96d92062e2d905cbbcb5a23c660f4ca27a"

// connector HMAC
connectorHMACHex      = "93035c03874d41709de679ad9a07b8c28f5b009cc4399828979a91ce00b4dbe6"
connectorHMACBase64   = "kwNcA4dNQXCd5nmtmge4wo9bAJzEOZgol5qRzgC02+Y="

// user HMAC
appPwSHA256Hex        = "5a528ffa8debae672c496a203cf8ea96d92062e2d905cbbcb5a23c660f4ca27a"
userHMACHex           = "7b35d82a0d234b515b5425b39051423c117b79246d7565f0438085921673cb3e"
userHMACBase64        = "ezXYKg0jS1FbVCWzkFFCPBF7eSRtdWXwQ4CFkhZzyz4="

HMACs für ShareDocument (Messaging-Webservice)

// initialization
contentConnector      = "d66d48bb-5891-462a-8cbb-6444ea7a0be9\n41e5d8df-7043-4f94-bcc6-25c6a5cf817f\nShareDocument"
connectorSecretBase64 = "c2VjcmV0Qnl0ZXNWYWx1ZQ=="
connectorSecretHex    = "736563726574427974657356616c7565"

contentUser           = "d66d48bb-5891-462a-8cbb-6444ea7a0be9\n41e5d8df-7043-4f94-bcc6-25c6a5cf817f"
appPwBase64           = "Mjc2NTQ4OTA3MTg3NjQ3MTE="
appPwBaseHex          = "3237363534383930373138373634373131"
appPwSHA256Hex        = "5a528ffa8debae672c496a203cf8ea96d92062e2d905cbbcb5a23c660f4ca27a"

// connector HMAC
connectorHMACHex      = "58ee2a509225b2a1994f3bddd9c24f824c2ece96194c9c29f18efe4c9116c1b4"
connectorHMACBase64   = "WO4qUJIlsqGZTzvd2cJPgkwuzpYZTJwp8Y7+TJEWwbQ="

// user HMAC
userHMACHex           = "05a78a98bf1992cba78fa35374172ec223e245ccca3a452456b2b107ed4186e9"
userHMACBase64        = "BaeKmL8Zksunj6NTdBcuwiPiRczKOkUkVrKxB+1Bhuk="

HMACs für RequestWasteTransferID (Begleitschein-Webservice)

// initialization
contentConnector      = "d66d48bb-5891-462a-8cbb-6444ea7a0be9\nRequestWasteTransferID"
connectorSecretBase64 = "c2VjcmV0Qnl0ZXNWYWx1ZQ=="
connectorSecretHex    = "736563726574427974657356616c7565"

contentUser           = "d66d48bb-5891-462a-8cbb-6444ea7a0be9"
appPwBase64           = "Mjc2NTQ4OTA3MTg3NjQ3MTE="
appPwBaseHex          = "3237363534383930373138373634373131"
appPwSHA256Hex        = "5a528ffa8debae672c496a203cf8ea96d92062e2d905cbbcb5a23c660f4ca27a"

// connector HMAC
connectorHMACHex      = "f4b1beaed6bea403ba7da256ce55e0e83e19b5bb221a3ee250da6ece8d26bea2"
connectorHMACBase64   = "9LG+rta+pAO6faJWzlXg6D4ZtbsiGj7iUNpuzo0mvqI="

// user HMAC
userHMACHex           = "5d161f49a2fec77d2efacec9118a57e8da5a728e9bc0a76b60e2392d2899aa2d"
userHMACBase64        = "XRYfSaL+x30u+s7JEYpX6Npaco6bwKdrYOI5LSiZqi0="

Erstellung des HTTP-Authentifizierungs-Headers

Die Authentifizierungsmerkmale werden per HTTP Authorization Header gemäß IETF RFC 7235 für jeden Webservice-Request übergeben, der Authentifizierung benötigt. Es wird ein sogenanntes Custom Scheme mit dem Namen "EDM0" und den folgenden Authentifizierungsparametern verwendet:

Parameter Beschreibung

connectorID

Die bei der Registrierung eines Connectors ausgestellte ID.

connectorHMAC

Der Connector-HMAC in Base64-Kodierung. Wie dieser erstellt wird, ist im vorherigen Abschnitt beschrieben.

dbUUID

Eine UUID, die mit einem Registrierten verknüpft ist. Im nächsten Abschnitt wird darauf näher eingegangen.

userID

Der VEBSV Benutzername.

userHMAC

Der User-HMAC in Base64-Kodierung. Wie dieser erstellt wird, ist im vorherigen Abschnitt beschrieben.
Example 1. Beispiel eines SOAP-Requests mit Authentifizierung
POST /soap-endpoint HTTP/1.1 +
Authorization: EDM0 connectorID="<connector-id>",connectorHMAC="<connector-hmac-base-64>",dbUUID="<db-uuid>",userID="<user-id>",userHMAC="<user-hmac-base-64>"
Content-Type: text/xml; charset=utf-8
...

<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
                  xmlns:web="http://www.example.com/webservice">
   <soapenv:Header>...</soapenv:Header>
   <soapenv:Body>
      <web:ShareDocumentRequest>
         ...
      </web:ShareDocumentRequest>
   </soapenv:Body>
</soapenv:Envelope>

Die Authentifizierungsparameter werden mit bloß einem ',' (Beistrich) zusammengesetzt. Werden zusätzlich Leerzeichen hinzugefügt, so wird es zu einem Fehler führen.

Spezialfall: QueryUpdate

Für die QueryUpdate-Operation werden im Authorization-Header die User-Angaben weggelassen. Der Authorization-Header würde dann wie folgt aussehen:

EDM0 connectorID="<connector-id>",connectorHMAC="<connector-hmac-base-64>",dbUUID="<db-uuid>"

Das heißt, dass die Authentifizierung des Benutzers ausschließlich über die DbUUID erfolgt. Das Verknüpfen der beiden erfolgt über eine RefreshBinding-Operation. Es gibt zwei Gründe dafür:

  • Ein Polling kann von einem Benutzer nur jede Minute durchgeführt werden. Hat ein Benutzer mehrere Instanzen des Clients laufen, so kann jeder Client den Benutzer eine eigene DbUUID zuweisen und somit können diese Clients unabhängig voneinander Polling-Operationen durchführen.

  • Lösungen, die von verschiedenen Registrierten gleichzeitig verwendet werden, können die Updates aller Nutzer auf einmal abfragen und müssen dies nicht für Jeden einzeln tun. Dazu werden alle Registrierten mit derselben DbUUID verknüpft.

Signaturen und Verschlüsselung

Der Prozess für das Signieren und Verschlüsseln von Meldungen/Messages befindet sich derzeit noch in der Validierungsphase und wird gegebenenfalls angepasst. Es wird daher empfohlen, diese Funktionen aktuell noch nicht zu implementieren. Sobald Signatur und Verschlüsselung finalisiert sind, wird rechtzeitig über die Umsetzung informiert.

Die beiden Webservices unterstützen Signaturen und Verschlüsselung, um die Integrität und Vertraulichkeit der Nachrichten sowohl zwischen Benutzern, als auch zwischen Benutzern und Webservice zu gewährleisten. Aktuell können die kryptografischen Methoden optional verwendet werden, um sicherzustellen, dass noch nicht unterstützende Clients weiterhin funktionieren. In Zukunft wird die Verwendung von Signaturen und Verschlüsselung jedoch verpflichtend sein.

Für die Umsetzung wurden die vom World Wide Web Consortium veröffentlichten Standards XML Signature Syntax and Processing (XMLDSig) und XML Encryption Syntax and Processing (XMLEnc) verwendet.

In den weiteren Unterabschnitten zeigt eine Schritt-für-Schritt-Anleitung, wie Signaturen und Verschlüsselung in den Messaging- und Begleitschein-Webservices verwendet werden. Auch werden potenzielle Fehlerquellen, sowie sonstige wichtige Informationen erläutert.

Für die Implementierung wird empfohlen, auf bereits existierende Bibliotheken zurückzugreifen, um die Wahrscheinlichkeit von Fehlern und die daraus resultierenden Sicherheitsrisiken zu minimieren.

Verwaltung eigener Schlüssel

Für beide Webservices wird dasselbe Schlüsselpaar verwendet. Der Public Key des Schlüsselpaars kann im EDM hinterlegt werden. Dazu muss ein Benutzer im EDM-Portal zum VEBSV 2.0-Bereich navigieren. Unter dem Reiter "Einstellungen" findet sich ein Unterpunkt namens "Verschlüsselung". Hier können Public Keys hochgeladen und verwaltet werden. Der Public Key muss die PEM-Form eines Keys im "X.509" (SubjectPublicKeyInfo) Format sein. Die Schlüssellänge des RSA Key-Pairs muss mindestens 2048 Bit und darf maximal 4096 Bit betragen. Nur der Hauptbenutzer und "Benutzerverwalter" Nebenbenutzer des Registrierten haben Zugriff auf diesen Bereich.

generate key pair 1

Public-Key-Requests

Sowohl das Messaging-Webservice, als auch das Begleitschein-Webservice bieten eine Schnittstelle an, um Public-Keys abzufragen. Bei beiden erhält man eine PublicKeyResponse der das Format und den Algorithmus des Public-Keys enthält, sowie die Base64-kodierten Daten des Schlüssels selbst.

Beim PublicKeyRequest des Messaging-Webservices wird eine "UserID" angegeben. Dabei handelt es sich um die GLN der Person, dessen öffentlicher Schlüssel angefragt wird. Außerdem können für die "UserID" die Spezialwerte "messaging" und "vebsv-ui" angegeben werden. Dadurch erhält man den Public-Key des Messaging-Webservices, bzw. der Frontend-Applikationen. Wozu diese beiden Schlüssel verwendet werden, wird in den folgenden Abschnitten, wo die Signatur und Verschlüsselung für das Messaging-WebService gezeigt wird, erläutert.

Der PublicKeyRequest des Begleitschein-Webservices benötigt keine Parameter. Es wird immer der Public-Key des Begleitschein-Webservices zurückgegeben. Der Grund dafür ist, dass im Begleitschein-System nur Meldungen an das EDM gesendet werden. Ein Begleitschein setzt sich aus den Meldungen aller Beteiligten zusammen. Mit Messaging kommunizieren die Beteiligten untereinander und benötigen daher den Public-Key des jeweils anderen.

Messaging

Versenden einer signierten und verschlüsselten Nachricht

Erstellung des ShareDocument-Requests

Zuerst erstellt die Client-Software den ShareDocument-Request. Dabei wird auch die zu versendende Message in Form eines MessageEnvelope-Elements dem DocumentContent-Element hinzugefügt.


  
1
2
3
4
5
6
7
8
9
10
11
12
13
14


  
<ShareDocumentRequest xmlns:ns1="...">
    ...
    <AuthenticatedDocument>
        <DocumentUQ>
            <DocumentHeader>...</DocumentHeader>
            <DocumentContent>
                <ns1:MessageEnvelope>
                    <ListedData>...</ListedData>
                    <MessageData>...</MessageData>
                </ns1:MessageEnvelope>
            </DocumentContent>
        </DocumentUQ>
    </AuthenticatedDocument>
</ShareDocumentRequest>

Die gesamte Message, sprich die Zeilen 7-10 im obigen Beispiel, werden folgend signiert und verschlüsselt.

Signatur erstellen und hinzufügen

Das Signieren erfolgt im Wesentlichen in zwei Schritten.


  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41


  
<ShareDocumentRequest xmlns:ns1="..."
    xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
    ...
    <AuthenticatedDocument>
        <DocumentUQ>
            <DocumentHeader>...</DocumentHeader>
            <DocumentContent>
                <ns1:MessageEnvelope> (1)
                    <ListedData>...</ListedData>
                    <MessageData>...</MessageData>
                </ns1:MessageEnvelope>
            </DocumentContent>
        </DocumentUQ>
        <ds:Signature>
            <ds:SignedInfo> (2)
                <ds:CanonicalizationMethod
                    Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                <ds:SignatureMethod
                    Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
                <ds:Reference> (1)
                    <ds:Transforms>
                        <ds:Transform
                            Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                    </ds:Transforms>
                    <ds:DigestMethod
                        Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                    <ds:DigestValue>...</ns2:DigestValue>
                </ds:Reference>
            </ds:SignedInfo>
            <ds:SignatureValue>...</ds:SignatureValue> (2)
            <ds:KeyInfo> (3)
                <ds:KeyValue>
                    <ds:RSAKeyValue>
                        <ds:Modulus>...</ds:Modulus>
                        <ds:Exponent>...</ds:Exponent>
                    </ds:RSAKeyValue>
                </ds:KeyValue>
            </ds:KeyInfo>
        </ds:Signature>
    </AuthenticatedDocument>
</ShareDocumentRequest>
1 Erstellung des Hash-Wertes
Zuerst wird der Hash-Wert des gesamten MessageEnvelope-Elements erstellt. Dazu wird das Element <ds:Reference> verwendet. Das Transform-Element gibt an mit welchem Algorithmus das MessageEnvelope-Element "normalisiert" wird. Dieses normalisierte Element dient nun als Input der Hash-Funktion, die mit <ds:DigestMethod> angegeben wird. Das Ergebnis wird Base64-kodiert in <ds:DigestValue> gespeichert.

Frameworks kodieren byte-Arrays oft selbst in Base64. Daher sollte darauf geachtet werden, dass der Hash-Wert und in Folge auch der Signatur-, sowie der Verschlüsselungswert nicht doppelt Base64-kodiert werden.
2 Erstellung des Signatur-Wertes
Danach wird der Signatur-Wert erstellt. Dazu wird das gesamte SignedInfo-Element verwendet. Dieses SignedInfo-Element wird ebenso zuerst "normalisiert" mit dem Algorithmus, der in <ds:CanonicalizationMethod> definiert ist. Das Ergebnis wird anschließend mit dem angegebenen Algorithmus in <ds:SignatureMethod> signiert. Dazu wird der private Schlüssel des Benutzers verwendet. Das Resultat wird in Base64-Form <ds:SignatureValue> gespeichert.
3 Informationen zum verwendeten Schlüssel hinzufügen
Zu guter Letzt wird noch der zugehörige Publik-Key vom verwendeten Private-Key dem Signatur-Element hinzugefügt. Der Grund dafür ist, dass, falls in Zukunft ein Benutzer mehrere Schlüsselpaare verwenden kann, der Empfänger weiß, mit welchem öffentlichen Schlüssel die Nachricht geprüft werden kann.

Das Messaging-Webservice überprüft die Signatur und gibt eine FailureResponse zurück, wenn die Validierung fehlschlägt. Die FailureID hat dabei den Wert INVALID_REQUEST_DATA (202). Der FailureText enthält eine genauere Beschreibung des Fehlers.

Es gibt drei verschiedene Validierungen, die das Messaging-Webservice durchführt:

  1. Überprüfung von Konstanten
    Da der XML-Signatur-Standard viele verschiedene Algorithmen unterstützt, müssten alle Clients all diese Algorithmen unterstützen, um Signaturen anderer überprüfen zu können. Deshalb lässt das Messaging-Webservice nur die Algorithmen zu, die im obigen Beispiel gezeigt werden. Ebenfalls muss das KeyInfo-Element in dieser Form präsent sein.

  2. Überprüfung von <ds:KeyInfo>
    Es wird überprüft, ob der angegebene öffentliche Schlüssel existiert und ob dieser dem Benutzer zugeordnet ist.

  3. Überprüfung von Hash- u. Signatur-Wert

Ein häufiger Fehler ist, dass die Signatur vor dem "Marshalling" erstellt wird, d.h. bevor die Objekte final in XML umgewandelt werden. Dadurch kann passieren, dass der Überprüfer einen völlig anderen Hash- bzw. Signatur-Wert erhält.


  
1
2
3
4
5


  
<ds:SignedInfo>
    <ds:CanonicalizationMethod .../>
    <ds:SignatureMethod .../>
    <ds:Reference>...</ds:Reference>
</ds:SignedInfo>

Das obere und untere Beispiel unterscheiden sich bloß in einer Leerzeile. Beide würden aber einen völlig verschiedenen Signatur-Wert ergeben.


  
1
2
3
4
5
6


  
<ds:SignedInfo>

    <ds:CanonicalizationMethod .../>
    <ds:SignatureMethod .../>
    <ds:Reference>...</ds:Reference>
</ds:SignedInfo>
Verschlüsseln und Ersetzen des MessageEnvelope-Elements

Die verwendete Technik nennt sich hybride Verschlüsselung. Dabei wird der zu verschlüsselnde Inhalt zuerst durch ein symmetrisches Verfahren verschlüsselt. Der symmetrische Schlüssel wird anschließend mit dem öffentlichen Schlüssel durch ein asymmetrisches Verfahren verschlüsselt. Dies ist der Standard bei XML-Verschlüsselung. Gründe dafür sind, dass das symmetrische Verfahren deutlich schneller ist und so nur relativ wenige Daten asymmetrisch verschlüsselt werden müssen. Außerdem lässt sich generell nur eine begrenzte Menge an Daten mit einem asymmetrischen Verfahren verschlüsseln.

Der Empfänger der Verschlüsselung ist das Messaging-Webservice. Daher wird auch der öffentlichen Schlüssel des Messaging-Systems für die asynchrone Verschlüsselung verwendet.

Folgende Schritte sind für die Verschlüsselung notwendig, welche nicht zwingend in exakt dieser Reihenfolge stattfinden müssen:

  1. Public-Key vom Messaging-Webservice anfragen
    Mit folgenden Request wird der Public-Key angefragt:

    
  
    1
2
3

    		
  
    <PublicKeyRequest>
    <UserID>messaging</UserID>
</PublicKeyRequest>

    Der öffentliche Schlüssel des Messaging-Systems kann auch im Client gespeichert werden, da er sich nicht allzu oft ändert. Es wird empfohlen, den Schlüssel erst erneut anzufragen, wenn das Senden aufgrund der Verschlüsselung fehlschlägt.

  2. Erstellung eines zufälligen symmetrischen Schlüssels

  3. <MessageEnvelope> symmetrisch verschlüsseln
    Dabei wird <MessageEnvelope> samt Inhalt mit einem <xenc:EncryptedData>-Element ersetzt, welches nun die verschlüsselten Daten, sowie ein Element, dass die verwendete Verschlüsselungsmethode angibt, enthält.

  4. Asymmetrische Verschlüsselung des symmetrischen Schlüssels
    Zudem wird <xenc:EncryptedData> ein <ds:KeyInfo>-Element hinzugefügt, welches wiederum ein <xenc:EncryptedKey>-Element enthält. Darin wird erneut die verwendete Verschlüsselungsmethode, als auch die verschlüsselten Daten des symmetrischen Schlüssels angegeben.

Der Request sieht nun wie folgt aus:


  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33


  
<ShareDocumentRequest xmlns:ns1="..."
    xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
    ...
    <AuthenticatedDocument>
        <DocumentUQ>
            <DocumentHeader>...</DocumentHeader>
            <DocumentContent>
                <xenc:EncryptedData
                    xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
                    <xenc:EncryptionMethod
                        Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc"/>
                    <ds:KeyInfo>
                        <xenc:EncryptedKey>
                            <xenc:EncryptionMethod
                                Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p">
                                ...
                            </xenc:EncryptionMethod>
                            <xenc:CipherData>
                                <xenc:CipherValue>...</xenc:CipherValue>
                            </xenc:CipherData>
                        </xenc:EncryptedKey>
                    </ds:KeyInfo>
                    <xenc:CipherData>
                        <xenc:CipherValue>...</xenc:CipherValue>
                    </xenc:CipherData>
                </xenc:EncryptedData>
            </DocumentContent>
        </DocumentUQ>
        <ds:Signature>
            ...
        </ds:Signature>
    </AuthenticatedDocument>
</ShareDocumentRequest>

Der Request kann nun an das Messaging-Webservice gesendet werden.

Empfangen einer signierten und verschlüsselten Nachricht

Empfangen einer signierten und verschlüsselten Nachricht

Da die Verschlüsselung zurzeit optional ist, hat der RetrieveDocument-Request ein neues, optionales Feld, welches angibt, ob die RetrieveDocument-Response vom Messaging-Webservice verschlüsselt werden soll.


  
1
2
3
4


  
<RetrieveDocumentRequest xmlns="....">
    ...
    <RequestEncryptedResponse>true</RequestEncryptedResponse>
</RetrieveDocumentRequest>

Ist der Wert dieses Feldes auf true gesetzt, so wird die Response verschlüsselt und sieht wie folgt aus:


  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18


  
<RetrieveDocumentResponse xmlns:ns1="..."
    xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
    <ForwardSharingEvent>...</ForwardSharingEvent>
    <AuthenticatedDocument>
        <DocumentUQ>
            <DocumentHeader>...</DocumentHeader>
            <DocumentContent>
                <xenc:EncryptedData
                    xmlns:xenc="http://www.w3.org/2001/">
                    ...
                </xenc:EncryptedData>
            </DocumentContent>
        </DocumentUQ>
        <ds:Signature>
            ...
        </ds:Signature>
    </AuthenticatedDocument>
</RetrieveDocumentResponse>

<xenc:EncryptedData und <ds:Signature> besitzen dieselben Strukturen, wie in Versenden einer signierten und verschlüsselten Nachricht bereits gezeigt wurde.

Da auch Signaturen zurzeit optional sind, enthält die Response nur welche, wenn der Sender diese hinzugefügt hat.

Entschlüsseln und ersetzen von EncryptedData-Element

Wird beim Versenden zuerst signiert und dann verschlüsselt, so wird beim Empfangen in umgedrehter Reihenfolge gearbeitet. Zuerst wird entschlüsselt und dann wird die Signatur überprüft. Folgende Schritte sind für diesen Teil dabei notwendig:

  1. Private-Key des Benutzers vom Key-Store laden.

  2. Damit wird der symmetrische Schlüssel entschlüsselt. Verschlüsselungsdaten u. -algorithmus finden sich in <EncryptedKey>.

  3. Mit diesem kann nun die Message entschlüsselt werden. Verschlüsselungsdaten u. -algorithmus finden sich in <EncryptedData>.

  4. <EncryptedData> mit <MessageEnvelope> ersetzen.

Dadurch sollte die Response wie folgt aussehen:


  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17


  
<RetrieveDocumentResponse xmlns:ns1="..."
    xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
    <ForwardSharingEvent>...</ForwardSharingEvent>
    <AuthenticatedDocument>
        <DocumentUQ>
            <DocumentHeader>...</DocumentHeader>
            <DocumentContent>
                <ns1:MessageEnvelope>
                    ...
                </ns1:MessageEnvelope>
            </DocumentContent>
        </DocumentUQ>
        <ds:Signature>
            ...
        </ds:Signature>
    </AuthenticatedDocument>
</RetrieveDocumentResponse>

Wird der Message-Inhalt mit den XML-Schema-Definitionen validiert, so muss dies zwingend nach dem Entschlüsseln erfolgen.
Überprüfung der Signatur

Mit einem PublicKey-Request lässt sich der öffentliche Schlüssel des Absenders empfangen.

Auch hier empfiehlt es sich, öffentliche Schlüssel anderer selbst zu speichern, da sie sich diese wahrscheinlich nicht allzu oft ändern. Wenn die Überprüfung fehlschlägt, so kann ein neuer PublicKey-Request abgesetzt werden.

Wie in Signatur erstellen und hinzufügen gezeigt, ist der Public-Key des Absenders in der Signatur enthalten. Jedoch könnte die Signatur von einer dritten Person ersetzt worden sein. Daher sollte der Schlüssel der PublicKey-Responses verwendet werden. Nur, falls in Zukunft mehrere Schlüsselpaare pro User erlaubt werden, kann der beigefügte Schlüssel verwendet werden, den richtigen auszuwählen.

Für die Überprüfung der Signatur gibt es zwei Arbeitsschritte - wobei die Reihenfolge dabei egal ist:

  • Überprüfung des Hash-Wertes

  • Überprüfung des Signatur-Wertes

Die anzuwendenden Transformationen und Algorithmen sind in <ds:Signature> angegeben und durch Vorgaben des Messaging-Webservices sogar konstant.

Es gibt zwei Spezialfälle in diesem Zusammenhang:

  1. Wurden Messages durch das Transportmodul gesendet, so hat die Signatur den folgenden Inhalt:

    
  
    1
2
3
4
5
6

    		
  
    <ds:Signature>
    ...
    <ds:KeyInfo>
        <ds:KeyName>vebsv-ui</ds:KeyName>
    </ds:KeyInfo>
</ds:Signature>

    D.h., dass die Signatur vom Transportmodul erstellt wurde.

  2. Benutzt der Empfänger eine andere Interface-Version als der Absender, so muss das Messaging-Webservice die Message umwandeln. Weitere Informationen zur Versionierung siehe Versionierung. Dadurch wird die Signatur des Absenders ungültig, weshalb Messaging diese mit einer eigenen ersetzt.

    
  
    1
2
3
4
5
6

    		
  
    <ds:Signature>
    ...
    <ds:KeyInfo>
        <ds:KeyName>messaging</ds:KeyName>
    </ds:KeyInfo>
</ds:Signature>

Beide Public-Keys können mit dem PublicKey-Request erhalten werden, indem für UserID der Wert von <ds:KeyName> benutzt wird.

Begleitschein-Webservice

Signaturen u. Verschlüsselungen im Begleitschein-Webservice funktionieren analog zum Messaging-Webservice. Daher wird in diesem Abschnitt nur auf die Unterschiede eingegangen.

Ein prinzipieller Unterschied ist, dass im Begleitschein-System nur Benutzer mit dem Webservice kommunizieren. Daher besteht keine Notwendigkeit eines Zugriffes auf die Public-Keys anderer Benutzer. Man braucht nur den öffentlichen Schlüssel des Begleitschein-Webservices, welcher durch einen PublicKey-Request angefragt werden kann. Jedoch läuft dieser nun gegen das Begleitschein-Webservice. Der Request selbst besitzt keine Parameter. Die Response hat die gleiche Struktur wie die des Messaging-WebServices.


  
1


  
<PublicKeyRequest />

Versenden einer signierten und verschlüsselten Meldung

Erstellen der Meldung

Zuerst wird die Meldung als ShareDocument-Request angelegt, welches das Element <ns1:EnvironmentalDataInstance> enthält, dass die relevanten Daten enthält.


  
1
2
3
4
5
6


  
<ShareDocumentRequest xmlns:ns1="...">
    ...
    <ns1:EnvironmentalDataInstance>
        ...
    </ns1:EnvironmentalDataInstance>
</ShareDocumentRequest>
Signieren und Verschlüsseln

Das Signieren und Verschlüsseln erfolgt in derselben Weise, wie beim Messaging-Webservice. Jedoch wird der Public-Key des Begleitschein-Systems verwendet und das Element, welches signiert und verschlüsselt wird, nun <ns1:EnvironmentalDataInstance> ist.

Das Resultat sieht wie folgt aus:


  
1
2
3
4
5
6
7
8
9
10
11


  
<ShareDocumentRequest xmlns:ns1="..."
    xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
    xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
    ...
    <xenc:EncryptedData>
        ...
    </xenc:EncryptedData>
    <ds:Signature>
        ...
    </ds:Signature>
</ShareDocumentRequest>
Senden und Response erhalten

Im Gegensatz zum Messaging-Webservice, wo der ShareDocument-Response keine relevanten Daten enthält, beinhaltet der ShareDocument-Response des Begleitschein-Webservices wichtige und schützenswerte Daten, den aktuellen Begleitschein aus Sicht des Benutzers. Daher wird die Response vom Begleitschein-System verschlüsselt und signiert. Da der ShareDocument-Response exakt denselben Inhalt liefert wie der RetrieveDocument-Response und dabei dasselbe zu verschlüsselnde und signierende Element besitzt, wird erst später darauf eingegangen.

Empfangen eines signierten und verschlüsselten Begleitscheins

Aufgrund der vorübergehenden Optionalität kann der Client, wie im Messaging-System, entscheiden, ob die Response verschlüsselt werden soll.


  
1
2
3
4


  
<RetrieveDocumentRequest>
    ...
    <RequestEncryptedResponse>true</RequestEncryptedResponse>
</RetrieveDocumentRequest>

Der verschlüsselte und signierte Response hat diese Form:


  
1
2
3
4
5
6
7
8
9
10
11


  
<RetrieveDocumentResponse xmlns:ns1="..."
    xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
    xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
    ...
    <xenc:EncryptedData>
        ...
    </xenc:EncryptedData>
    <ds:Signature>
        ...
    </ds:Signature>
</RetrieveDocumentResponse>

Eine CancelDocument-Operation besitzt ebenfalls ein Element, mit dem die Response verschlüsselt werden kann.
Entschlüsselung der Daten und Überprüfung der Signatur

Das Entschlüsseln und Überprüfen funktioniert in derselben Weise wie in Messaging. Wichtig dabei ist, dass die Entschlüsselung vor der Schema-Validierung erfolgt, falls eine solche durchgeführt wird.


  
1
2
3
4
5
6


  
<RetrieveDocumentResponse xmlns:ns1="...">
    ...
    <ns1:ConsignmentNoteDataInstance>
        ...
    </ns1:ConsignmentNoteDataInstance>
</RetrieveDocumentResponse>

Message-Flow

Dieser Abschnitt soll zeigen, wie der Datenfluss gesamter Geschäftsfälle zwischen verschiedenen Clients ausfällt. Dabei wird ersichtlich, welche Nachricht von wem an wen und zu welchem Zeitpunkt gesendet wird. Dadurch erschließt sich auch, welcher Nutzer welche Informationen zu einem gewissen Zeitpunkt besitzt. Die in den beispielhaften Geschäftsfällen erwähnten Firmen sind fiktiv.

Jeder gezeigte Geschäftsfall wird durch ein Diagram grob beschrieben.

simple external carrier

Da die wichtigsten Daten darin bereits enthalten sind, wird in den Ablaufdiagrammen meist darauf verzichtet, diese erneut zu zeigen, womit diese kompakter und übersichtlicher werden.

showcase detailed compact

Wenn es jedoch notwendig erscheint, dann werden auch mehr Informationen zu den einzelnen Nachrichten gezeigt.

Einfache Geschäftsfälle

Einfacher Geschäftsfall mit externen Transporteur und mit meldepflichtigen Abfall

simple external carrier

In diesem Beispiel übergibt die Firma AbfallProfi GmbH 100 kg Asbest an die Firma Müll Logistik. Müll Logistik beauftragt den Transport und wird daher auch Veranlasser genannt. Als Transporteur fungiert die Firma MüllMeister. Diese bringt den Abfall schließlich von A nach B. Natürlich könnte auch die Firma AbfallProfi GmbH die Rolle des Transportbeauftragers einnehmen.

mf simple external carrier

Da es sich bei Asbest um einen begleitscheinpflichtigen Abfall handelt, muss für die Übergabe ein Begleitschein verwendet bzw. der Behörde gemeldet werden. Der erste Schritt ist daher eine VEBSV-ID beim Begleitschein-Webservice, der im Ablaufdiagramm mit "VEBSV 2.0" betitelt wird, anzufordern. Müll Logistik wird für dieses Beispiel als Initiator definiert und führt daher diese Anfrage durch. Die Antwort des WebService enthält die VEBSV-ID, welche hier V1 beträgt.

Aufgrund der Initiator-Rolle ist es auch Müll Logistik der die Übergabe-/Übernahme-Message sendet. Neben Informationen, wie wer ist Übergeber, wer ist Übernehmer, um welchen Abfall und welche Menge handelt es sich, weiß Abfall Profi GmbH jetzt über die notwendigen UUIDs und der VEBSV-ID Bescheid. Dadurch ist es dessen Client-Software möglich, andere Messages dieses Auftrags richtig zuzuordnen, bzw. ist es der Software nun möglich, selbst Messages und Meldungen richtig erstellen und versenden zu können.

Die Rolle des Initiators hätte genauso gut auch AbfallProfi GmbH übernehmen können und hätte somit die VEBSV-ID angefordert, als auch die Übergabe-/Übernahme-Message gesendet.

Jede Message beinhaltet im DocumentHeader-Element eine ContextUUID, welche bei jeder Message des gleichen Auftrags dieselbe ist. Diese bietet für eine Software den einfachsten Weg, Messages einem Auftrag zuzuordnen.

AbfallProfi GmbH, hier in der Rolle des Übergebers, kann nun, da er im Besitz der VEBSV-ID ist, die Übergabe-Deklaration einmelden.

Da Müll Logistik im Vorhinein als Transportbeauftrager, bzw. Veranlasser, definiert wurde, fällt es dieser Firma zu, die Transport-Message zu senden. Diese wird nun auch an den Transporteur MüllMeister gesendet. Nun wissen alle Beteiligte, wann der Transport stattfindet, von wo und wohin er stattfindet, welche Abfälle transportiert werden sollen und auch wer der Transporteur ist. Außerdem werden wieder UUIDs, sowie die VEBSV-ID ausgetauscht.

Der Transportbeauftrager hat auch die Aufgabe, den Transport bei der Behörde anzukündigen und schickt daher auch die Transport-Deklaration. Diese beinhaltet auch die TransportUUID. Der Grund dafür wird in einem späteren Abschnitt, wo Komplexe Transporte gezeigt werden, klar.

Da ohne Transport-Deklaration die Transport-Beginn-Meldung nicht gesendet werden kann, ist es auch dem Transporteur möglich den Transport zu deklarieren. Ansonsten würde es bei einem Versäumnis des Transportbeauftragers zu einem Stillstand kommen.

Wenn der Transporteur bereit zur Abfahrt ist, sendet dieser die Transport-Start-Message und Transport-Beginn-Meldung. Dabei wird dieselbe TransportUUID verwendet, wie sie mit der Transport-Message vorgegeben wurde.

Wurde erfolgreich abgeladen, dann sendet der Transporteur die Transport-Ende-Message. Der Empfänger bestätigt dies mit einer Empfangs-Bestätigungs-Message. Beide verwenden dabei wieder die zugehörige TransportUUID.

Wenn der Übernehmer, hier Müll Logistik, den Abfall begutachtet hat, sendet dieser die Übernahme-Bestätigungs-Message (mit der richtigen ShipmentUUID) und meldet die Übernahme-Meldung ein.

Einfacher Geschäftsfall mit externen Transporteur und ohne meldepflichtigen Abfall

Wenn kein meldepflichtiger Abfall vorliegt, dann können Meldungen an das Begleitschein-System völlig außer Acht gelassen werden. Der Ablauf beim Versenden der Messages bleibt gleich. Auch wird keine VEBSV-ID benötigt.

mf simple external carrier only msg

Einfacher Geschäftsfall ohne externen Transporteur und ohne meldepflichtigen Abfall

Hierbei handelt es sich um noch eine simplere Form des Geschäftsfalls. Die Rolle des Transporteurs wird vom Übernehmer hier ausgeführt. In diesem Beispiel werden alle Messages von Müll Logistik gesendet.

mf simple internal carrier

Einfacher Geschäftsfall mit Begleitscheinart "Ohne Transport"

Wenn die Begleitscheinart "Ohne Transport" verwendet wird, werden auch keine Transport-bezogenen Meldungen und Messages versendet. Dabei muss in der Übergabe-Deklaration und der Übernahme-Meldung eine Begründung, welche in der REDA-Liste 8963 definiert sind, angegeben werden.

Die Begleitscheinart "Ohne Transport" darf nur in absoluten Ausnahmefällen verwendet werden, bei denen der Abfall im Zuge der Abfallübergabe(n) überhaupt nicht transportiert wird, wie z.B. bei Kauf eines Abfallzwischenlagers samt den darin befindlichen Abfällen.
mf simple without transport

Interne Transporte

internal transport

Bei einem internen Transport handelt es sich beim Übergeber und Empfänger um dieselbe Person. Der Abfall (od. die Abfälle) wird von einem Standort der Person zu einem anderen Standort derselben Person transportiert. Das Besondere bei internen Transporten ist, dass nur während der Beförderung der Abfälle ein "Transportdokument" mitgeführt werden muss, dass jedoch über den Empfang der Abfälle keine Meldung an die Behörde erfolgen muss.

mf internal transport

Da AbfallProfi GmbH sowohl Übergeber als auch Empfänger ist, gibt es keinen Message-Empfänger für die Übergabe-/Übernahme- und Übernahmebestätigungs-Message. Daher müssten diese Messages nicht gesendet werden. Jedoch ist es möglich, die Messages sich selbst zu senden, was einige Vorteile bringt.

Erstens ist eine Message jederzeit(*) abrufbar. Wird aus irgendeinem Grund der Client beim Benutzer neu aufgesetzt, so kann der Auftrag anhand der Messages wiederhergestellt werden. Des Weiteren, sollte bei beiden Standorten jeweils eine Instanz des Clients laufen, so sind die Daten auf beiden Seiten auch verfügbar.

Die transportrelevanten Messages werden wie gehabt gesendet.

(*) Nur die Header-Daten sind jederzeit abrufbar. Der Message-Inhalt selbst wird nach einem Jahr vom Messaging-System gelöscht.

Komplexe Transporte

Ein komplexer Transport von Abfällen vom ersten Übergeber zum Empfänger kann in mehrere Einzeltransporte unterteilt werden. Jeder Transport hat dabei seine eigene UUID um unterschieden werden zu können. Auch kann der Transporteur bei jedem Transport ein anderer sein. Nur der Veranlasser, bzw. Transportorganisator, ist für alle Transporte derselbe.

Geteilte Transporte

Geteilte Transporte sind nötig, wenn nicht alle Abfälle auf einem Transportfahrzeug Platz haben. Selbst eine Abfalleinheit kann geteilt werden.

splitted transport

Da die hier übergebenen 30 Tonnen für einen Transport zu viel sind, wird der Abfall auf zwei Fahrten aufgeteilt.

mf splitted transport

Es werden hier zwei Transporte definiert. Dabei verwenden sie dieselbe ShipmentItemUUID (WasteUUID im Diagram) als auch dieselbe VEBSV-ID. Die Abfallmasse wird jedoch auf beide Transporte aufgeteilt. Jeder Transport hat auch seine eigene TransportUUID.

Die Transporte werden bei diesem Beispiel sequentiell durchgeführt. Jedoch ist es auch möglich, die Transporte parallel durchzuführen.

Nun ist auch klar, warum die TransportUUIDs auch den Meldungen beigefügt werden müssen. Dadurch werden sie unterscheidbar.

Transporte mit Umladen

Bei dieser Art von Transport werden die Abfallgüter an einem bestimmten Umladeort umgeladen. Ein häufig auftretendes Beispiel ist, dass die Abfälle vom Erzeuger zum nächsten Bahnhof verfrachtet werden. Von dort aus befördert die Bahn die Abfälle zum Zielbahnhof, von wo aus sie schließlich zum Abfallsammler transportiert werden.

transshipped transport

In diesem Beispiel werden die 100 kg Asbest durch MüllMeister von AbfallProfi GmbH zum Umladeort transportiert. Dort wird das Asbest vom Transporteur des zweiten Transports (Eber Transporte) entgegengenommen und zu Müll Logistik gebracht. Beide Transporte wurden von Müll Logistik organisiert.

mf transshipped transport

Das Umladen wird in den Wegpunkt-Objekten (PlannedWaypointEvent) angegeben. Dabei wird als Person der nachfolgende/vorhergehende Transporteur angegeben und als Standort der Umladeort.

Außerdem müssen bei "Umlade-Wegpunkten" zusätzlich eine Person und ein Standort beigefügt werden. Bei "Belade-(Umlade-)Wegpunkten" ist dies der erste Übergeber und der Übergabeort. Bei "Ablade-(Umlade-)Wegpunkten" wird der letzte Empfänger und der Empfangsort verwendet. Der Grund dafür ist, dass diese Personen und Standorte letztendlich am Transportdokument stehen müssen.

Streckengeschäft

Bei einem Streckengeschäft gibt es neben dem ersten Übergeber und dem Empfänger noch weitere Teilnehmer. Dabei übergibt der erste Teilnehmer seinen Abfall an den ersten Streckenpartner, bzw. der erste Streckenpartner übernimmt den Abfall vom ersten Übergeber. Der erste Streckenpartner übergibt den Abfall wiederum an den nächsten Teilnehmer und so weiter. Letztendlich übernimmt der letzte Empfänger den Abfall vom letzten Streckenpartner. Dabei is wichtig zu verstehen, dass die Streckenpartner den Abfall nie physisch besitzen, denn der Transport findet nach wie vor zwischen dem ersten Übergeber und dem Empfänger statt.

Einer der Teilnehmenden übernimmt im Streckengeschäft die Rolle des sogenannten "Streckenmelders" bzw. "Streckenorganisator". Diesem fallen bei solchen Geschäftsfällen besondere Aufgaben zu.

In den allermeisten Fällen werden die Rollen des Streckenmelders und des Veranlassers (Transportorganisator) von derselben Person eingenommen, da gewöhnlich nur dieser den Überblick über das gesamte Geschäft besitzt.

Einfaches Streckengeschäft

simple dropshipping

Dies stellt die einfachste und gewöhnlichste Form des Streckengeschäfts dar. In diesem Beispiel ist Müll Logistik der einzige Streckengeschäftspartner. Dieser initiiert auch das Geschäft und ist weiters der Veranlasser. Zugleich übernimmt Müll Logistik die Rolle des Streckenmelders und sendet somit die Streckengeschäftsmeldung an die Behörde.

mf simple dropshipping

Der Streckenmelder, hier Müll Logistik, sendet jeweils eine Message an AbfallProfi GmbH und MüllMeister. Bei der ersten wird der Übergeber mit AbfallProfi GmbH und der Übernehmer mit Müll Logistik genannt. Bei der anderen ist der Übergeber nun Müll Logistik und der Übernehmer MüllMeister.

Bei beiden Übergabe-/Übernahme-Messages werden dieselben UUIDs verwendet. Dies ist wichtig, um die Abfälle des Transports richtig zuordnen zu können.

D.h. AbfallProfi GmbH und MüllMeister wissen nichts voneinander. Deshalb muss nun auch die Transport-Message gesondert behandelt werden, um die Anonymität zu bewahren. Dem Übergeber wird nur der "Belade-Wegpunkt" der Message beigefügt und dem Übernehmer nur der "Ablade-Wegpunkt".

Hier wurden beide Transport-Messages auch dem Transporteur gesendet. Dieser hat dadurch beide Wegpunkte. Alternativ könnte man auch eine vollständige Message dem Transporteur senden. D.h. eine Client-Implementierung sollte mit beiden Fällen umgehen können.

Neu hinzu, im Vergleich zu gewöhnlichen Geschäften, kommt die Streckenmeldung. Diese beinhaltet alle an dem Geschäft beteiligten Personen.

Die restlichen transportbezogenen Messages werden wie gewohnt gesendet. Die Übernahme-Bestätigungs-Message geht anfangs nur an den Streckenmelder. Dieser leitet die Message dem Übergeber, im Sinne von einer neuen Message mit demselben Inhalt, weiter.

Einfaches Streckengeschäft (Variation)

Nun wird dasselbe Geschäft wie vorhin betrachtet, bloß, dass die Rolle des Streckenmelders und Veranlassers von MüllMeister übernommen wird. Es soll dabei nur auf die Unterschiede zum vorigen Beispiel eingegangen werden.

mf simple dropshipping variation

Hier sendet der Streckenmelder die Übergabe-/Übernahme-Message an die beiden anderen Beteiligten, in welcher auch alle genannt sind. Da sich auch alle "kennen", so muss die Transport-Message nun auch nicht gesondert behandelt werden. Auch die Übernahme-Bestätigungs-Message wird an alle Beteiligten direkt gesendet.

Am besten lässt sich das Streckengeschäft in zwei Gruppen aufteilen, die wir hier der Einfachheit wegen als "linke" u. "rechte Gruppe" benennen. In der linken sind alle links vom Streckenmelder (inklusive) und in der rechten alle rechts vom Streckenmelder (inklusive). Alle in derselben Gruppe erhalten auch dieselben Messages. In diesem Beispiel gibt es keine rechte Gruppe.

Streckengeschäft mit mehreren Streckenpartnern

Hier noch ein vollständiges Beispiel, mit mehreren Streckenpartnern. Jede Gruppe besteht aus Übergeber/Übernehmer, Streckenpartner und Streckenmelder. Der Streckenmelder wird auch den Transport selbst durchführen. Dieses Beispiel lässt sich noch beliebig weiter skalieren.

mf big dropshipping

Da der Streckenmelder das Einmelden der anderen Streckengeschäftspartner übernimmt, sollte dieser die Streckenmeldung nur nach dem Erhalt aller Zusagen vornehmen. Dazu kann die Funktion des ShareRetrieverStatus verwendet werden, welche im Diagram mit grünen Pfeilen visualisiert sind. In einer Übergabe-/Übernahme-Message lässt sich zudem ein Zeitpunkt angeben, bis wann der Streckenmelder eine Bestätigung bzw. Ablehnung erwartet.

Sonstiges

Transportabbruch

Aus verschiedensten Gründen kann es während eines Transports zu einem Abbruch kommen. Unterschieden wird zwischen Abbruch mit Folgetransport und Abbruch ohne Folgetransport (Ladeverlust).

simple external carrier

Als Beispiel wird erneut ein einfaches Geschäft mit externen Transporteur verwendet. Zuerst wird der Fall mit Folgetransport betrachtet. Gründe dafür können vielfältig sein. Etwa kann es zu einem Bruch des Transportmittels kommen und ein neuer Fahrer muss Übernehmen.

mf transport abort follow up

Kommt es zu einem Abbruch mit Folgetransport, so wird eine Transport-Abbruch-Message und die Transport-Abbruch-Meldung gesendet. Als Grund wird Abbruch mit Folgetransport verwendet. Der exakte Wert dafür kann über die REDA-Schnittstelle erfragt werden. Für die Abbruchs-Message kann optional ein Standort hinzugefügt werden.

Nun muss ein neuer Transport angelegt werden, welcher dann normal ausgeführt wird. Dabei könnte auch ein anderer Transporteur ausgewählt werden. Als Beladeort kann der ursprüngliche Beladeort verwendet werden. Auch kann der Standort aus der Transport-Abbruch-Message ausgewählt werden.

Nun wird ein Abbruch mit Ladeverlust gezeigt. Die Gründe dafür könnten Diebstahl oder ein sonstiger Verlust, wie Versickerung im Erdreich, sein.

mf transport abort loss

Erneut wird eine Transport-Abbruch-Message und die Transport-Abbruch-Meldung gesendet. Da der Empfänger den Abfall nun nie erhält, kann dieser eine Übernahme-Ablehnungs-Message und Übernahme-Ablehnungs-Meldung senden. Optional könnte der Empfänger jedoch auch die Übernahme bestätigen und als Masse den Wert "0" verwenden.

Ablehnungen

Ein möglicher Anwendungsfall für die Ablehnung der Übergabe/Übernahme wurde bereits beim Beispiel Transportabbruch mit Ladeverlust gezeigt. Dabei wird als Ablehnungsgrund "Abfall wird nicht übernommen" verwendet.

Der zweite Anwendungsfall ist, wenn der Empfänger bei exakter Prüfung eine andere Abfallart feststellt, für die keine Berechtigungen besessen wird, oder der falsch deklarierte Abfall aus sonstigen Gründen nicht übernommen werden kann/will.

Sammeltouren

Sammeltouren werden zurzeit noch nicht nativ unterstützt. Aktuell werden sie als getrennte und eigenständige Geschäfte betrachtet und genauso durchgeführt. D.h. werden Abfälle von Firma A und Firma B mit demselben Transport zum Empfänger C gebracht, gibt es zwei getrennte Transporte die durchgeführt und zwei eigenständige Abfälle die übernommen werden.

Messaging-Webservice

Messaging-Webservice

Begleitschein-Webservice

Begleitschein-Webservice

Glossar

Deutscher Begriff Beschreibung Englischer Begriff

Abfallart

Aus rechtlicher Sicht sind Abfallarten in der österreichischen Abfallverzeichnisverordnung 2020 festgelegt. Die Zuordnung eines Abfalls hat zu jener Abfallart zu erfolgen, die den Abfall in seiner Gesamtheit am besten beschreibt. Das aktuelle Abfallverzeichnis ist am EDM-Portal hier abrufbar: EDM Portal - Aktuelles Abfallverzeichnis

Zu jeder Abfallart gehört eine Schlüsselnummer und eine Bezeichnung. Bei manchen Abfallarten gibt es eine Abfallspezifizierung. Gefährliche Abfälle sind im Abfallverzeichnis mit einem "g" gekennzeichnet. Beispiele:

  • 12601 g Schmier- und Hydrauliköle, mineralölfrei

  • 17101 77 g Rinde aus der Be- und Verarbeitung gefährlich kontaminiert

Weiters ist unter den Zuordnungstabellen am EDM-Portal die Referenzliste "Abfallverzeichnis gemäß Österreichischer Abfallverzeichnisverordnung" veröffentlicht, in der jeder Abfallart eine eigene GTIN zugeordnet ist: EDM Portal - Aktuelle Liste - 5174: Abfallverzeichnis gemäß Österreichischer Abfallverzeichnisverordnung

waste type

Abfallübergabe

Der Begriff „Abfallübergabe“ bezeichnet aus abfallwirtschaftsrechtlicher Sicht die Übertragung der (zivilrechtlichen) Verfügungsgewalt über einen Abfall von einer Person (Übergeber) an eine andere Person (Übernehmer). Abfallübergaben können grundsätzlich physisch stattfinden aber auch "rein rechtlich" erfolgen. Bei "rein rechtlichen" Abfallübergaben wird im VEBSV-Kontext aber von "Abfallweitergabe" (siehe unten) gesprochen.

Eine Abfallübergabe findet zwischen verschiedenen Rechtspersonen bzw. Unternehmen statt. Wird ein Abfall innerbetrieblich "übergeben", also von einem Standort eines Unternehmens zu einem anderen Standort desselben Unternehmens transferiert, so wird dieser Vorgang im VEBSV-Kontext der Einfachheit halber auch als "Abfallübergabe" abgebildet.

Rechtlicher Hinweis: Keine "Abfallübergabe" ist die physische Übergabe des Abfalls an einen bloßen Transporteur, der den Abfall im Auftrag des Abfallbesitzers nur befördert.

waste handover

Abfallweitergabe

Der Begriff „Abfallweitergabe“ ist ein Spezialfallfall der "Abfallübergabe" und bezeichnet im VEBSV-Pilotprojekt einen Vorgang, bei dem von einem Geschäftspartner („nur“ rechtlich) übernommener Abfall an eine andere Person übergeben (= weitergegeben) wird.

waste forwarding

Abfallübernahme

Der Begriff „Abfallübernahme“ bezeichnet aus abfallwirtschaftsrechtlicher Sicht sowohl eine physische als auch eine "rein rechtliche" Übernahme von Abfall, bei der die (zivilrechtliche) Verfügungsgewalt von einer Person (Übergeber) an eine andere Person (Übernehmer) übertragen wird.

Im VEBSV-Kontext wird der Begriff "Abfallübernahme" speziell für die Bezeichnung der physischen Abfallübernahme durch den Empfänger der Abfälle verwendet.

waste takeover

Abladeort

Ein Ort, an dem der Abfall von einem Transportmittel abgeladen wird. Es kann sich dabei um den Empfangsort oder um einen Umladeort handeln.

  • Der Abladeort ist nicht immer der endgültige Bestimmungsort des Abfalls.

drop-off location

Abschnitt

Bezeichnet den Transportabschnitt. Dieser Parameter wird verwendet um den vorliegenden Transport, vor allem wenn mehrere erfolgen A-B-C-D, klar zu definieren.

einfacher Transport (A-B): Abschnitt: Absendeort zum Empfangsort

komplexer Transport (A-B): Abschnitt: Absendeort zum Abladeort

komplexer Transport (B-C): Abschnitt: Beladeort zum Abladeort

komplexer Transport (C-D): Abschnitt: Beladeort zum Empfangsort

section

Absendeort

Der Ort, an dem der Abfall vom ersten Übergeber (physisch) übergeben wird.

In der Transportdeklaration und in der Abfalltransportbeginnmeldung wird der Absendeort als Beladeort abgebildet.

Auch Übergabeort genannt.

handover location

ADR

ADR steht als Abkürzung für: Accord européen relatif au transport international des marchandises dangereuses par route, auf Deutsch: Europäisches Übereinkommen über die internationale Beförderung gefährlicher Güter auf der Straße.

Gemäß ADR ist unter anderem während des Transports gefährlicher Güter ein Beförderungspapier mitzuführen, auf welchem die wichtigsten Informationen zu diesem Gut, zum Absender, Transporteur und Empfänger aufgeführt sind. Ein Transport gefährlicher Abfälle auf der Straße fällt häufig unter die Bestimmungen des ADR.

adr

Aktuelle Message/Aktuelle Nachricht

Die aktuelle Message einer Message-Reihe ist die, die die höchste VersionSequenceNr besitzt. Mit anderen Worten: Die aktuelle Message ist die letzte Korrektur einer Message-Reihe, bzw. die Message selbst, sollte es noch keine Korrekturen geben.

current message

Begleitschein

Der Begleitschein ist ein Dokument, das bei der Übergabe eines gefährlichen Abfalls oder POP-Abfalls erstellt wird und das den Transport des Abfalls begleitet: Wer gefährliche Abfälle oder POP-Abfälle einer anderen Rechtsperson (Übernehmer) übergibt oder sie in der Absicht, sie einer anderen Rechtsperson zu übergeben, zu diesem befördert oder befördern lässt, hat Art, Menge, Herkunft und Verbleib der gefährlichen Abfälle und seine Identifikationsnummer in einem Begleitschein zu deklarieren.

Besondere Gefahren, die mit der Behandlung verbunden sein können, sind bekannt zu geben. Besonderheiten der Abfälle, insbesondere ob es sich um POP-Abfälle handelt, sind bekannt zu geben.

Die Begleitscheindaten müssen der Behörde via EDM gemeldet werden.

Je Abfall muss es einen Begleitschein geben.

Ausnahmen:

  • Keine Begleitscheinpflicht besteht für Problemstoffe.

  • Private Haushalte sind nicht begleitscheinpflichtig.

  • Bei notifizierungspflichtiger grenzüberschreitender Abfallverbringung gibt es andere Dokumente

Aus IT-Sicht: Pro VEBSV-ID gibt es einen "Begleitschein". Dieser Umfasst die Summe aller Deklarationen/Meldungen + Validierungen; Jeder User sieht dabei nur die Informationen, die er auch sehen darf.

consignment note

Begleitscheinnummer

Wird auf "Papier-Begleitscheinen" und im EBSM-System verwendet (wird in VEBSV nicht verwendet): Auf Papier-Begleitscheinen muss eine fortlaufende Begleitscheinnummer angeführt werden, dabei kann sowohl der Übergeber, als auch der Übernehmer eine Nummer zur Identifizierung des Begleitscheins angeben.

Die Begleitscheinnummer setzt sich zusammen aus einer fortlaufenden Nummer, der Jahreszahl und einer GLN.

Sie ermöglicht eine eindeutige Zuordnung von Abfalltransporten und deren Dokumentation.

consignment note number

Begleitschein-Webservice

Im Begleitschein-Webservice werden die gemeldeten Begleitscheindaten der Behörde zugänglich gemacht. Im Kontext von VEBSV 2.0 steht ein Begleitschein dabei für einen meldepflichtigen Abfall. Dieser beinhaltet die Kette der Übergaben und Übernahmen, als auch alle Transporte, die diesen Abfall betreffen.

Auch genannt: Begleitscheinsystem

ebs, ebs-webservice

Beladeort

Ein Ort, an dem der Abfall auf ein Transportmittel aufgeladen wird. Es kann sich dabei um den Absendeort oder um einen Umladeort handeln.

In der Transportdeklaration und in der Abfalltransportbeginnmeldung wird der Absendeort als Beladeort abgebildet.

pick-up location

Beteiligte

Werden die Teilnehmer an einem Geschäftsfall (Übergeber, Übernehmer, Empfänger) bezeichnet.

participant

Datenanforderung

Bedingung, deren Einhaltung in Zusammenhang mit der Erfassung bzw. Übermittlung von Daten notwendig oder empfohlen ist.

data requirement

Einfacher Transport

Ein "einfacher" Transport liegt vor, wenn der Abfall direkt und ohne Umladen vom Absendeort des ersten Übergebers zum Entladeort beim Empfänger transportiert wird.

simple transport

Einfaches Streckengeschäft

Ein Streckengeschäft mit nur einem "Streckengeschäftspartner":

Ein einfaches Streckengeschäft liegt vor, wenn ein Abfallsammler (= Streckengeschäftspartner) einen Abfall direkt vom Übergeber (= seinem Geschäftspartner) zu einem Empfänger (= ebenfalls ein Geschäftspartner des Abfallsammlers) transportiert oder transportieren lässt, ohne dass hierbei ein Standort des Abfallsammlers berührt wird.

simple drop-shipping

Einzeltransport

Ein Transport von Abfällen oder ein einzelner Abschnitt aus einem Transport von Abfällen, bei dem das Transportmittel von einem "Beladeort" zu einem "Abladeort" fährt. Es wird ein einzelnes Transportmittel mit einem bestimmten Transportmittelkennzeichen benutzt.

Innerhalb eines "Einzeltransports" findet kein Umladen statt.

Beispiele:

  • Ein Transportmittel fährt genau einmal von einem Absendeort zum Empfangsort (Abladeort).

  • Die Fahrt eines LKWs von 3 Aufladeorten zum Empfangsort bei einer Sammeltour.

  • Die Fahrt eines Zugs vom Absendeort zu einem Umladeort.

Fährt ein LKW mehrfach von einem Aufladeort zu einem Abladeort, so handelt es sich hingegen dabei um mehrere Einzeltransporte.

single transport

Empfänger

Der Übernehmer, der in einem Geschäft den Abfall tatsächlich physisch übernimmt bzw. übernommen hat.

Receiver

Empfangsort

Der Ort, an dem der Abfall final vom Empfänger (physisch) übernommen wird.

In der Transportdeklaration In der XML-Schnittstelle (TypeCEvent) wird der Empfangsort als Entladeort, bei dem kein Umladen stattfindet, abgebildet.

takeover location

Entsorgungsnachweis

Im Modul Entsorgungsnachweis können Abfallübergaben und –beförderungen von im Wege des VEBSV gemeldeten, begleitscheinpflichtigen Abfällen nachvollzogen werden. Das Modul umfasst eine Liste aller Begleitscheine: Es gibt eine Übersichtsliste, in der nur die wichtigsten Details nur im Überblick angezeigt werden (jede Zeile entspricht einem Begleitschein).

Die gesamte Kette an Übergaben und Übernahmen sowie die Beförderung vom ersten Übergeber bis hin zum letzten Übernehmer sind ersichtlich, sobald diese im Wege des EDM an die Behörde gemeldet wurden.

Waste disposal

ERP-System

Ein IT-System einer der am Abfalltransport beteiligten Personen.

ERP-System

Ersteller einer Message/Meldung

Bezeichnet den Registrierten, der eine Message/Meldung erstellt und gesendet hat. Nur der Ersteller kann die Message/Meldung korrigieren oder stornieren.

message creator

Erster Übergeber

Jene Person/Unternehmen von dem der Abfall ursprünglich stammt (rechtlich). Der Übergeber, der in einem Geschäft den Abfall tatsächlich besitzt/besaß.

First handover

Firmensitz

Offizielle Adresse bzw. Sitz der Verwaltung eines Unternehmens.

e.g.
Graf-Zeppelin-Platz 1
AT-5020 Salzburg

head office

Geschäftszahl/Referenznummer

Eine von einem Meldenden vergebene Geschäftszahl/Referenznummer, wie zum Beispiel eine Auftragsnummer, die für Deklarationen/Meldungen verwendet wird.

order number

GLN

Global Location Number; im EDM-Kontext handelt es sich um eine vom EDM-System zugeteilte eindeutige Identifikationsnummer. GLN werden im EDM in folgenden Ausprägungen verwendet: Personen-GLN, Standort-GLN, Anlagen-GLN.

gln

GTIN

Global Trade Item Number; im EDM-Kontext eine vom EDM-System verwendete Kodierung für bestimmte Inhalte (z.B. Abfallarten, Transportarten) entsprechend der am EDM-Portal (edm.gv.at) veröffentlichten Zuordnungstabellen.

gtin

Hauptorganisator

Diese Rolle existiert nur im Messaging. Der Hauptorganisator sendet die initialen Übergabe-Übernahme-Messages bzw. ÜgÜn-Messages an seine direkten Partner.

Main organizer

Initiale Message / Initiale Nachricht / Ursprüngliche Message / Ursprüngliche Nachricht

Die initiale Message einer Message-Reihe ist die, die die niedrigste VersionSequenceNr besitzt. Mit anderen Worten: Die initiale Message ist die erste Message einer Message-Reihe, auch wenn diese Korrekturen besitzt.

initial message

Interner Transport

Bei einem internen Transport ist der erste Übergeber und der Empfänger derselbe Registrierte. Der Absende- u. Empfangsort unterscheiden sich jedoch.

Ein Streckengeschäft ist bei einem Streckengeschäft nicht möglich. Beim internen Transport kann es sich aber um einen komplexen Transport handeln.

Interne Transporte zeichnen sich dadurch aus, dass meldepflichtige Abfälle nicht eingemeldet werden müssen. Daher ist für diese auch keine VEBSV-ID zu beantragen.

internal transport

Kennzeichen

Kennzeichen des Transportmittels; Parameter für den Transport um diesen eindeutig einem Transportmittel zuordnen zu können

  • im Straßentransport z.B.: Nummernschild des Transportfahrzeugs

  • beim Schienentransport z.B.: Zugkennung/Wagonnummer/Container ID

mean-id, licence plate

Komplexer Transport

Ein Transport wird "komplex" genannt, wenn sich der Gesamttransport aus mehreren Einzeltransporten zusammensetzt. Parallele Transporte und Transporte mit Umladung können dabei beliebig kombiniert werden.

complex transport

Kopfdaten (einer Deklaration/Meldung)

Die Kopfdaten einer Deklaration/Meldung sind Meldender, Zeitpunkt der Erstellung des Dokuments, für die Meldung vergebene Geschäftszahlen/Referenznummern.

header data

Korrektur (einer Meldung/Deklaration/Nachricht)

Korrektur einer bereits übermitteltem Meldung/Deklaration/Nachricht.

correction

Link Administration

Im Entsorgungsnachweis und Transportmodul können User registrierter Personen ("EDM-User", aber keine Behördenuser) Links erstellen, damit andere Mitarbeitende, die keinen EDM-Zugang besitzen, die Applikationen ebenfalls benutzen können. Dadurch kann z.B. der Lenker des Transportmittels Zugriff auf den ihn betreffenden Transport bekommen oder ein Mitarbeiter eines bestimmten Standortes Zugriff auf die den Standort betreffenden Entsorgungsnachweise.

Die Links können auf verschiedene Weise eingeschränkt werden (z.B. Beschränkung auf Transporte, bei denen ein bestimmtes Transportmittelkennzeichen angegeben ist oder Beschränkung auf Begleitscheine, die einen bestimmten Standort betreffen).

Zusätzlich besitzt der EDM-User eine Ansicht aller aktiven Links, die dort auch gelöscht werden können.

Auch "Aktive Links" genannt.

Link administration

Masse

Ist ein Parameter der die Menge/Masse des Abfalles spezifiziert. Die Masse wird im VEBSV in kg erwartet (z.B. 50,0 kg).

mass

Meldung

Datenaustausch eines Beteiligten an das Behörden-Begleitscheinsystem.

notification

Messaging-Webservice

Ermöglicht den Datenaustausch mittels Nachrichten zwischen den Beteiligten.

Messaging-Webservice

Message/Nachricht

Datenaustausch zwischen den Beteiligten. Unterscheidung zwischen Übergabe/Übernahme bezogenen Nachrichten und Transport bezogene Nachrichten.

message

Message-Reihe

Diese beinhaltet eine Message samt ihrer Korrekturen. Alle Messages einer Message-Reihe besitzt dieselbe VersionBracketUUID, unterscheiden sich aber durch die VersionSequenceNr, indem jede neue Korrektur eine höhere VersionSequenceNr besitzt.

message series

Erstübermittlung (einer Meldung/Deklaration)

Erstmalige Übermittlung einer Meldung/Deklaration.

Paralleler Transport

Wenn mehrere Transporte zwischen zwei Abschnitten erfolgen, werden diese als parallele Transporte bezeichnet.

parallel transport

Problemstoffe

Gefährliche Abfälle, die üblicherweise in privaten Haushalten anfallen. Weiters gelten als Problemstoffe jene gefährlichen Abfälle aller übrigen Abfallerzeuger, die nach Art und Menge mit üblicherweise in privaten Haushalten anfallenden gefährlichen Abfällen vergleichbar sind. In beiden Fällen gelten diese Abfälle so lange als Problemstoffe, wie sie sich in der Gewahrsame der Abfallerzeuger befinden.

Handelt es sich um Problemstoffe, so besteht keine Begleitscheinpflicht.

Prüfregel

Eine Prüfregel überprüft, ob eine Datenanforderung eingehalten wird oder nicht.

test rule

POP

Persistente organische Schadstoffe (Persistent Organic Pollutants), sind eine Gruppe von organischen Verbindungen, die toxische Eigenschaften haben, in der Umwelt persistieren, sich in Nahrungsketten anreichern und eine Gefahr für die menschliche Gesundheit und die Umwelt darstellen. Sie werden nicht nur auf EU-Ebene durch die EU-POP-Verordnung, sondern weltweit durch das Stockholmer Übereinkommen reguliert.

Abfälle, die POP enthalten, sind begleitscheinpflichtig.

pop

REDA

Referenz Datenbank

reda

RID

Ordnung über die internationale Eisenbahnbeförderung gefährlicher Güter; Vergleichbar mit ADR (siehe oben) - für den Transport auf der Schiene.

rid

Sammeltour

Bei einer Sammeltour holt ein Abfallsammler Abfälle nacheinander von mehreren Übergebern ab und bringt sie gemeinsam zu einem Empfangsort.

SMS Lösung

Bestätigung eines per SMS erhaltenen Links am Smartphone ersetzt die Unterschrift des Abfallübergebers am Begleitschein: Wenn ein erster Übergeber kein eigenes ERP-System zur Teilnahme an VEBSV verwendet, so kann er bzw. eine von ihm dazu ermächtigte Person die Daten über die Abfallübergabe bestätigen (oder ablehnen), die von seinem direkten Partner (sein Übernehmer) angegeben wurden. Sind meldepflichtige Abfälle vorhanden, dann werden für diese auch ÜG-Deklarationen an das Behörden-Begleitscheinsystem gesendet.

Voraussetzung zur Nutzung der SMS-Lösung ist, dass der erste Übergeber im EDM registriert ist.

SMS solution

Streckengeschäft

Sind erster Übergeber und Empfänger keine direkten Geschäftspartner, so spricht man von einem Streckengeschäft. D.h. in diesen Geschäften existiert zumindest ein weiterer Abfallsammler (= Streckengeschäftspartner), der als unmittelbarer Geschäftspartner des Abfallübergebers und als unmittelbarer Geschäftsparter des Empfängers fungiert - sohin existieren mindestens drei Teilnehmer an einem Streckengeschäft.

Streckengeschäftspartner verfügen rechtlich über die Abfälle, nehmen diese aber im Regelfall nicht physisch in Besitz. Theoretisch kann es eine unbeschränkte Anzahl an Streckengeschäftspartnern geben. Ein Streckengeschäft kann in mehrere "Teilstrecken" unterteilt werden, bei denen es jeweils einen Übergeber und einen Übernehmer gibt.

Drop shipping

Streckengeschäftspartner

Rechtlicher Inhaber des Abfalls - besitzt Abfall jedoch im Regelfall nicht physisch (ausgenommen: Streckengeschäftspartner, der gleichzeitig Transporteur ist). Ein Streckengeschäftspartner schließt zivilrechtlich in eigenem Namen und auf eigene Rechnung Verträge über den Abfall.

drop shipping partner

Streckenmelder

Jene Person, die den Überblick über alle Teilnehmer eines Streckengeschäfts hat und der die Strecken-Meldung versendet. Diese Rolle fällt meist mit dem Organisator und Initiator des gesamten Streckengeschäfts zusammen.

Auch Streckenorganisator genannt.

main organizer

Transport mit Umladung

Bezeichnet Transporte bei denen der Beladeort oder/und Abladeort ein Umladeort ist.

transshipped transport

Transportart

Bezeichnet die Art des Transportes zum Beispiel Straße, Schiene, Wasserweg, Luftweg. Die Transportart bezieht sich dabei immer nur auf einen bestimmten "Abschnitt" eines Transports, der mit einem konkreten Transportmittel (mit einem Transportmittelkennzeichen) erfolgt (daher gibt es in VEBSV keinen "kombinierten Transport")

transport mode

Transportbeginn

Start des Transports: Transport-Datum, Transport-Uhrzeit z.B.

  • 18.01.2024, 03:59

transport start

Transportbegleitdokumente

Dokumente, welche – zusätzlich zu den gemäß AWG 2002 mitzuführenden Dokumenten - beim Transport mitzuführen sind oder mitgeführt werden, z.B. das ADR-Beförderungspapier, Frachtbrief, Lieferschein.

Für VEBSV 2.0 ist derzeit das ADR-Beförderungspapier relevant.

transport documents

Transporteur

Kann in drei Ausprägungen vorkommen:

  1. Person, die Abfälle im Auftrag des Abfallbesitzers nur befördert, oder

  2. jener am Geschäft Beteiligte, der die Beförderung der Abfälle operativ durchführt, oder

  3. Abfallübergeber, der die Beförderung der Abfälle zum Empfänger selbst vornimmt.

Ist ein diejenige Person, die den Überblick über alle Teilnehmer eines Streckengeschäfts hat und der die Strecken-Meldung versendet. Diese Rolle fällt meist mit dem Organisator und Initiator des gesamten Streckengeschäfts zusammen.

Auch Streckenorganisator genannt.nsporteur am Geschäft (als Abfallsammler) beteiligt, so ist er im Regelfall auch der Transportorganisator.

Carrier

Übergabe

Betrifft nicht nur einen einzelnen Abfall. Bezieht sich auf alle Abfälle eines Geschäftsfalles (Messaging-Webservice), während sich die Abfallübergabe nur einen bestimmten Abfall bezieht (Begleitschein-Webservice). Siehe Abfallübergabe.

handover

Übernahme

Betrifft nicht nur einen einzelnen Abfall. Siehe Abfallübernahme. Bezieht sich auf alle Abfälle eines Geschäftsfalles (Messaging-Webservice), während sich die Abfallübernahme nur einen bestimmten Abfall bezieht (Begleitschein-Webservice). Siehe Abfallübernahme.

takeover

Übergeber

Jemand, der einen Abfall übergibt.

handover

Übermittlung (einer Meldung/Deklaration)

Damit ist sowohl die Erstübermittlung als auch die Korrektur einer Meldung/Deklaration gemeint.

transfer

Übernehmer

Jemand, der einen Abfall übernimmt. (Hinweis: unbeachtlich ist, ob es sich um jemanden handelt, der den Abfall "rein rechtlich" (aufgrund von Verträgen) oder auch tatsächlich (physisch) übernimmt: in beiden Fällen wird vom "Übernehmer" gesprochen. Allerdings wird der "letzte" Übernehmer, der den Abfall physisch übernimmt, als "Empfänger" bezeichnet.)

Takeover

Umladeort

Ein Ort, an dem der Abfall von einem Transportmittel auf ein anderes Transportmittel umgeladen wird. Sowohl der Beladeort als auch der Abladeort können ein Umladeort sein.

transhipment location

VEBSV

Vollelektronisches Begleitscheinverfahren. Der vollelektronische Begleitschein setzt sich zusammen bzw. entsteht aus den Deklarationen bzw. Meldungen zu einer VEBSV-ID.

VEBSV

VEBSV-ID

Zwölfstellige Nummer, Format: 1234-1234-1234

Eine VEBSV-ID steht für einen Begleitschein und somit für einen meldepflichtigen Abfall.

Die VEBSV-ID ist eine vom EDM-System generierte Identifikationsnummer.

VEBSV-ID

Veranlasser / Transportorganisator / Transportveranlasser

Derjenige, der den Transport organisiert bzw. so die Beförderung der Abfälle "veranlasst".

Transport organizer

Wegpunkt

Ein Transport beinhaltet immer zwei Wegpunkte, wobei einer sich auf das Beladen und der andere sich auf das Entladen bezieht.

Ein Wegpunkt setzt sich zusammen aus:

  • einem Standort

  • einer Person

  • Datum oder Zeitpunkt

Weiters können Wegpunkte in geplante und tatsächliche Wegpunkte unterteilt werden. Bei Transport-Messages und -Deklarationen spricht man von geplanten Wegpunkten. Bei Transportstart-, Transportende- und Empfangsbestätigungs-Messages bzw. bei Abfalltransportbeginn- und Transportabbruchs-Meldungen spricht man von tatsächlichen Wegpunkten. Daher wird das Datum/der Zeitpunkt auch als geplant oder tatsächlich interpretiert.

waypoint

XML

XML steht für Extensible Markup Language (englisch für „erweiterbare Auszeichnungssprache“). Das ist eine Sprache zur Darstellung hierarchisch strukturierter Daten in Form von Textdateien. XML wird u. a. für den Austausch von Daten zwischen Softwaresystemen eingesetzt.

XML

Webservice-Schnittstelle

Definiert gültige Requests die ein Webservice empfangen kann und definiert das Format des Response.

Webservice-interface

Webservice-Client

Übernimmt die Kommunikation mit dem Webservice

Webservice-Client

Webservice

Die Software, die Requests von Webservice-Clients entgegennimmt und verarbeit.

Client

ZAReg

Das Akronym steht für "Zentrales Anlagen Register"; es handelt sich um das Stammdatenregister gemäß § 22 Abfallwirtschaftsgesetz 2002 (AWG 2002). ZAReg ist das Herzstück des EDM-System (edm.gv.at).