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

Release-Änderungen

Ä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-Postionen 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 Entwicklungs-Umgebung 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 Entwicklungs-Umgebung 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 WsbService-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 eien RefreshBindingResponse erhalten werden, sondern eien 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 Authentifizierungs-Mechanismus genau funktioniert wird im Abschnitt Authentifizierung genauer erläutert.

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

Erste Message senden u. empfangen

Ist der Authentifizierungs-Mechanismus 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 geschehn.

  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

Zurzeit ist das Versenden von SMS in der DEMO-Stage nicht aktiviert. Somit kann dieses Tutorial nicht getestet werden.

Durch die SMS-Lösung wird es Abfallersterzeugern 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 man 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ägen 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/Meldungne). 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. Aktuell ist dies für Clients noch Optional, da man den Entwicklern Zeit zur Umsetzung geben will. Es ist jedoch geplant, dass in Zukunft alle Messages/Meldungen signiert und verschlüsselt werden müssen. In der DEMO-Stage bleibt es 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.

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

ShareDocument

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

<ShareDocumentRequest xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
    <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>
</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öglichen 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.

<ShareDocumentCancellationRequest xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
    <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>
</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.

<QueryUpdateRequest>
    <InterfaceVersionID>1.09</InterfaceVersionID>
    <ConnectorVersionID>...</ConnectorVersionID>
    <UpdateRangeStartUUID>...</UpdateRangeStartUUID>
    <UpdateRangeEndUUID>...</UpdateRangeEndUUID>
    <UpdateRangeStartInclusionIndicator>[true/false]</UpdateRangeStartInclusionIndicator>
    <UpdateRangeEndInclusionIndicator>[true/false]</UpdateRangeEndInclusionIndicator>
</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.

<QueryUpdateResponse>
    <AdditionalUpdatesIndicator>[true/false]</AdditionalUpdatesIndicator>
    <UpdateEvent>...</UpdateEvent>
</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.

<QueryDocumentValidationResultRequest>
    <InterfaceVersionID>1.09</InterfaceVersionID>
    <ConnectorVersionID>...</ConnectorVersionID>
    <ReferredTransactionUUID>...</ReferredTransactionUUID>
</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.

<RetrieveDocumentRequest>
    <InterfaceVersionID>1.09</InterfaceVersionID>
    <ConnectorVersionID>...</ConnectorVersionID>
    <ReferredTransactionUUID>...</ReferredTransactionUUID>
</RetrieveDocumentRequest>

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

<RetrieveDocumentResponse>
    <ForwardSharingEvent>...</ForwardSharingEvent>
    <AuthenticatedDocument>...</AuthenticatedDocument>
</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.

<ShareRetrieverStatusRequest>
    <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)
</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.

<LaunchDocumentActionRequest>
    <InterfaceVersionID>1.09</InterfaceVersionID>
    <ConnectorVersionID>...</ConnectorVersionID>
    <TransactionUUID>...</TransactionUUID>
    <TransportMovementUUID>...</TransportMovementUUID>
    <ActionTypeID collectionID="1276">...</ActionTypeID>
</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.

 
<FailureResponse>
    <FailureID>...</FailureID>
    <FailureText>...</FailureText>
    <ValidationResultItem>...</ValidationResultItem>
</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


  
<RequestWasteTransferIDResponse>
    <WasteTransferID>[vebsv-id]</WasteTransferID>
    <IssueDateTime>...</IssueDateTime>
</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


  
<ShareDocumentRequest xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
    <InterfaceVersionID>...</InterfaceVersionID>
    <ConnectorVersionID>...</ConnectorVersionID>
    <TransactionUUID>[transaction uuid]</TransactionUUID> (1)
    <DocumentUUID>...</DocumentUUID> (2)
    <ChangeReasonID>...</ChangeReasonID>
    <EnvironmentalDataInstance>
        <EnvironmentalDataEnvelope>
            <Document>...</Document> (3)
            <ListedData>...</ListedData> (4)
            <EnvironmentalDataDocument>
                <Document>...</Document> (5)
                <EnvironmentalData>...</EnvironmentalData> (6)
            </EnvironmentalDataDocument>
        </EnvironmentalDataEnvelope>
    </EnvironmentalDataInstance>
    <ds:Signature>...</ds:Signature> (7)
</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


  
<CancelDocumentRequest>
    <InterfaceVersionID>...</InterfaceVersionID>
    <ConnectorVersionID>...</ConnectorVersionID>
    <TransactionUUID>[transaction uuid]</TransactionUUID>
    <DocumentUUID>[transaction uuid to delete]</DocumentUUID> (1)
    <ChangeReasonID>...</ChangeReasonID>
</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


  
<RetrieveDocumentResponse xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
    <ValidationResult>...</ValidationResult> (1)
    <ConsignmentNoteDataInstance>
        <EnvironmentalDataEnvelope>
            <Document>...</Document> (2)
            <ListedData>...</ListedData> (3)
            <EnvironmentalDataDocument> (4)
                <Document>...</Document>
                <EnvironmentalData>...</EnvironmentalData>
            </EnvironmentalDataDocument>
            <ConsignmentNoteDocument>...</ConsignmentNoteDocument> (5)
        </EnvironmentalDataEnvelope>
    </ConsignmentNoteDataInstance>
    <ds:Signature>...</ds:Signature> (6)
</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 Transport bezogene Message oder eine Übergabe-/Übernahme-bezogene Message 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 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:

  • Mit Transport und ohne Streckengeschäft
    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
    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 ortsfeste/mobile Anlage, dann muss Standort ein Registrierter sein

    • Wenn ortsfeste Anlage, dann muss diese zum Standort gehören

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

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
31


  
<TypeAEvent>
    <TypeID collectionID="8926">[gtin]</TypeID> (1)
    <ProcessTypeID collectionID="8113">[gtin]</ProcessTypeID> (2)
    <Date>...</Date> (3)
    <DateTime>...</DateTime>
    <DeviatingAssignmentReasonDescription>...</DeviatingAssignmentReasonDescription> (4)
    <Object> (5)
        <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"> (6)
        [vebsv-id]
    </AssociatedObjectReferenceID>
    <AssociatedObjectDocumentScopeReferenceID roleID="9008390104705"> (7)
        [handover reference]
    </AssociatedObjectDocumentScopeReferenceID>
    <AssociatedObjectDocumentScopeReferenceID roleID="9008390104712"> (8)
        [takeover reference]
    </AssociatedObjectDocumentScopeReferenceID>
    <AssociatedObjectDocumentScopeReferenceID roleID="9008390108345"> (9)
        [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 Angabe, ob es sich um einen "Begleitschein danach" handelt. Aktuell wird diese Art des Begleitscheins nicht unterstützt und dieses Feld kann somit nicht benützt werden.
3 Datum oder Zeitpunkt der Übernahme. Nur ein Element ist auswählbar.
4 Falls die Abfallart von der Übergabe-Deklaration abweicht, wird hier eine Begründung erwartet.
5 Angaben zum Abfall aus Sicht des Empfängers
6 Die VEBSV-ID des Begleitscheins
7 Eine Referenz zu einem Eintrag in ListedData für den Übergeber. Im Streckengeschäft ist diese der direkte Partner des Empfängers.
8 Eine Referenz zu einem Eintrag in ListedData für den Empfänger.
9 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

    • Keine Angabe von <ProcessTypeID> (da zurzeit der Begleitschein danach deaktiviert ist zurzeit)

    • <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 (falls der Empfänger feststellt, dass es sich um verschiedene handelt, sind 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 ortsfeste/mobile Anlage, dann muss Standort ein Registrierter sein

    • Wenn ortsfeste Anlage, dann muss diese zum 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 ortsfeste/mobile Anlage, dann muss Standort ein Registrierter sein

    • Wenn ortsfeste Anlage, dann muss diese zum 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 ortsfeste/mobile Anlage, dann muss Standort ein Registrierter sein

    • Wenn ortsfeste Anlage, dann muss diese zum 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>

  • Keine Angabe eines Kennzeichens oder einer Transportart

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

  • Keine weitere Person/Organisation/LocalUnit

  • Angabe von <TransportId>

  • 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

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

    • 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.

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.

GreenCycle AGAbfallProfi GmbHMüll LogistikTrMsgTrUUIDT1DocUUIDD1VBracketUUIDVB1VSeqNr0TrMsgTrUUIDT2DocUUIDD2VBracketUUIDVB1VSeqNr1

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.

GreenCycle AGAbfallProfi GmbHMüll LogistikTrMsgTrUUIDT1DocUUIDD1VBracketUUIDVB1VSeqNr0TrMsgTrUUIDT2DocUUIDD2VBracketUUIDVB1VSeqNr1ShareDocCancelReqVBracketUUIDVB1

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.

GreenCycle AGAbfallProfi GmbHMüll LogistikTrMsgTrUUIDT1DocUUIDD1VBracketUUIDVB1VSeqNr0

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.

GreenCycle AGAbfallProfi GmbHMüll LogistikTrMsgTrUUIDT1DocUUIDD1VBracketUUIDVB1VSeqNr0TrMsgTrUUIDT2DocUUIDD2VBracketUUIDVB2VSeqNr0RefDocUUIDD1

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.

GreenCycle AGAbfallProfi GmbHMüll LogistikTrMsgTrUUIDT1DocUUIDD1VBracketUUIDVB1VSeqNr0TrMsgTrUUIDT2DocUUIDD2VBracketUUIDVB2VSeqNr0RefDocUUIDD1TrMsgTrUUIDT3DocUUIDD3VBracketUUIDVB2VSeqNr1RefDocUUIDD1ShareDocCancelReqVBracketUUIDVB2

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.

GreenCycle AGAbfallProfi GmbHMüll LogistikTrMsgTrUUIDT1DocUUIDD1VBracketUUIDVB1VSeqNr0TrMsgTrUUIDT2DocUUIDD2VBracketUUIDVB2VSeqNr0RefDocUUIDD1TrMsgTrUUIDT3DocUUIDD3VBracketUUIDVB1VSeqNr1TrMsgTrUUIDT4DocUUIDD4VBracketUUIDVB2VSeqNr1RefDocUUIDD1ShareDocCancelReqVBracketUUIDVB2TrMsgTrUUIDT4DocUUIDD4VBracketUUIDVB3VSeqNr0RefDocUUIDD3
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.

GreenCycle AGAbfallProfi GmbHMüll LogistikTrMsgTrUUIDT1DocUUIDD1VBracketUUIDVB1VSeqNr0TrMsgTrUUIDT2DocUUIDD2VBracketUUIDVB2VSeqNr0RefDocUUIDD1TrMsgTrUUIDT3DocUUIDD3VBracketUUIDVB2VSeqNr1RefDocUUIDD1TrMsgTrUUIDT4DocUUIDD4VBracketUUIDVB3VSeqNr0RefDocUUIDD1TrMsgTrUUIDT5DocUUIDD5VBracketUUIDVB1VSeqNr1

In diesem Beispiel wurde zuerst ein Korrekturvorschlag von GreenCycle 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

In der aktuellen Version sind die beschriebenen Regeln für das Messaging-Webservice noch nicht umgesetzt. Die Implementierung ist erst mit dem nächsten Release geplant. In der Entwicklung eines Clients können bzw. sollten sie aber bereits berücksichtigt werden.

Wenn eine Message(-Reihe) storniert werden kann, so kann sie im aktuellen Status auch korrigiert werden und es kann ein Korrekturvorschlag dazu eingebracht werden. Ist im Folgenden nur von einer Stornierung die Rede, so sind auch Korrekturen u. Korrekturvorschläge mitgemeint.

  • Eine Übergabe-/Übernahme-Message kann immer gesendet werden, solange die Shipment-UUID noch nicht in Verwendung ist. Sie kann nur storniert werden, wenn keine gültige Übernahmebestätigung oder Ablehnungs-Message vorliegt.

  • Eine Übernahmebestätigung ist möglich, wenn eine dazugehörige Übergabe-/Übernahme-Message vorliegt und auch nicht storniert wurde. Auch darf keine gültige Ablehnungs-Message vorliegen. Für das Stornieren gibt es keine Einschränkungen.

  • Eine Ablehnungs-Message kann gesendet werden, wenn eine dazugehörige Übergabe-/Übernahme-Message vorliegt und auch nicht storniert wurde. Auch darf keine gültige Übernahmebestätigung vorliegen. Für das Stornieren gibt es keine Einschränkungen.

  • Die Transport-Message kann gesendet werden, wenn die Transport-UUID noch nicht verwendet wurde. Sie kann nur storniert werden, wenn keine gültige Transportstart-Message vorliegt.

  • Der Transportstart kann gesendet werden, wenn auch eine Transport-Message zum selben Transport vorliegt. Stornieren lässt er sich nur, wenn keine gültige Transportabbruch-Message, keine gültige Transportende-Message und keine gültige Empfangsbestätigung vorliegt.

  • Ein Transport kann nur abgebrochen werden, wenn ein gültiger Transportbeginn, sowie keine gültige Transportende-Message bzw. Empfangsbestätigung existiert. Der Abbruch kann immer storniert werden.

  • Das Transportende kann nur erfolgen, wenn es einen gültigen Transportstart und keinen gültigen Transportabbruch gibt. Storniert kann so lange werden, bis eine gültige Empfangsbestätigung vorliegt.

  • Die Empfangsbestätigung kann gesendet werden, wenn es eine gültige Transportende-Message gibt oder ein Transportstart vorliegt, der nicht abgebrochen wurde. Der Grund dafür ist, dass ein Empfänger auch dann bestätigen können soll, wenn der Transporteur das Senden der Transportende-Message vergessen hat oder aus sonst einem Grund diese nicht sendet. Dadurch ist es dem Empfänger trotzdem möglich, mit seinem Prozess fortzufahren.

Regeln des Begleitschein-Webservices

Im Gegensatz zum Messaging-System sind diese Regeln bereits mit Version 1.9 umgesetzt. Hier gilt erneut dasselbe: Kann eine Meldung storniert werden, so kann sich auch korrigiert werden. Deshalb sind beide immer mitgemeint.

  • Eine Übergabe-Deklaration kann gesendet werden, solange keine andere Übergabe-Deklaration mit derselben VEBSV-ID existiert. Storniert werden kann so lange kein gültiger Transportbeginn vorliegt.

  • Für die Transport-Deklaration gilt dasselbe, wie für die Übergabe-Deklaration. Der Unterschied besteht jedoch darin, dass es sich um den Transportbeginn desselben Transports handeln muss (siehe Komplexe Transporte). Das heißt, liegt nur ein Transportbeginn für einen anderen Transport derselben VEBSV-ID vor, so kann die Transport-Deklaration weiterhin storniert werden.

  • Die Streckenmeldung kann jederzeit eingebracht werden, aber nur solange storniert werden, bis eine Übernahme-, bzw. Ablehnungs-Meldung vorliegt.

  • Die Abfalltransportbeginn-Meldung kann nur eingebracht werden, wenn die Übergabe-Deklaration und die dazugehörige Transport-Deklaration existieren und auch nicht storniert wurden. Sie ist so lange stornierbar, bis entweder die Transportabbruch- oder die Übernahme-/Ablehnungs-Meldung vorliegen.

Mit der Abfalltransportbeginn-Meldung wird der Begleitschein für die Behörde sichtbar und bleibt es, auch wenn der Transportbeginn storniert wurde.

  • Ein Transportabbruch kann nur erfolgen, wenn auch ein gültiger Transportbeginn existiert und auch die Übernahme-, bzw. Ablehnungs-Meldung noch nicht vorliegt. Die Transportabbruch-Meldung selbst kann nicht mehr storniert werden.

  • Um die Übernahme- oder Ablehnungs-Meldung senden zu können, darf keine der beiden bereits existieren. Zudem müssen alle deklarierten Transporte bereits gestartet worden sein. Im Falle eines Streckengeschäfts ist auch die Streckenmeldung notwendig. Stornieren kann man beide Meldungen immer.

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. Nur der Hauptnutzer des Registrierten ist dazu in der Lage. Dieses Applikationspasswort muss, neben dem EDM-Benutzernamen des Hauptnutzers, in der Software hinterlegt werden, sodass die Software beim Aufrufen einer WS-Operation die Authentifizierung ordnungsgemäß durchführen kann.

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 \(k_1\) und \(k_2\) das Connector- und User-Secret, \(m_1\) und \(m_2\) die verwendeten Zeichenfolgen basierend auf einer beliebigen Webservice-Operation und \(s_1\) und \(s_2\) die erzeugten Authentifizierungs-Tags.

Weiters sei \(\text{SHA}_{256}\) die SHA-256 Hash-Funktion und

\[\text{HMAC}_{\text{SHA}-256}: K \times M \rightarrow S, (k, m) \mapsto s\]

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

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

\[s_1 = \text{HMAC}_{\text{SHA}-256}(k_1, m_1)\]

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

\[s_2 = \text{HMAC}_{\text{SHA}-256}(\text{SHA}_{256}(k_2), m_2)\]

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.

Erstellung des HTTP-Authentifizierungs-Headers

Die Authentifizierungsmerkmale werden per HTTP Authorization Header gemäß IETF RFC 7235 für jeden Webservice-Request übergeben. 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 EDM-Hauptbenutzername.

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>

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

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 eines EDM-Accounts hat 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 GreenCycle. 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 meldepflichten Abfall handelt, muss dieser 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 GreenCycle 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

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 Abfälle, die normalerweise meldepflichtig wären, dies nicht sind.

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 GreenCycle von AbfallProfi GmbH zum Umladeort transportiert. Dort wird das Asbest vom Transporteur des zweiten Transports (Eder 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 GreenCycle. 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 GreenCycle.

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 GreenCycle 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 GreenCycle ü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 Schnittstellenbeschreibung

BackwardSharingEvent

Angaben zu einer Verarbeitungsrückmeldung zu einem zuvor erfolgten forward sharing.

BackwardSharingEvent
Name/Typ min..max Definition

TransactionUUID

UUIDIdentifier

1..1

UUID (Universally Unique ID), die für den Aufruf der backward sharing Operation reserviert wurde und diesen Aufruf eindeutig identifiziert.

TransactionDateTime

DateTime

1..1

Zeitstempel, mit dem das EDM Messaging Service die Abarbeitung des backward sharing Aufrufs versehen hat.

ReferredTransactionUUID

UUIDIdentifier

1..1

UUID (Universally Unique ID) des forward sharing Aufrufs, zu dessen Verarbeitung per backward sharing eine Rückmeldung erfolgt.

ReferredTransactionTypeID

ReferenceIdentifier

1..1

Art des forward sharing, z.B. initiales Verteilen, Verteilen einer Korrektur oder Stornieren (Codeliste 6413), zu dessen Verarbeitung eine Rückmeldung erfolgt.

ReferredDocumentUUID

UUIDIdentifier

0..1

UUID (Universally Unique ID) der Message aus dem forward sharing Aufruf, zu dessen Verarbeitung per backward sharing eine Rückmeldung erfolgt.Anmerkung: Diese UUID ist genau dann gesetzt, wenn es sich beim forward sharing, auf das Bezug genommen wird, NICHT um eine Stornierung handelt (siehe ReferredTransactionTypeID-Element).

InterfaceVersionID

VersionIdentifier

1..1

Konstante, die vom Konnektor, über den der Aufruf der backward sharing Operation erfolgt ist, angegeben wurde, und die anzeigt, auf welche Version des Webservice der Konnektor ausgelegt ist.

SharedByConnectorID

StrictReferenceIdentifier

1..1

ID des Konnektors, über den der Aufruf der backward sharing Operation erfolgt ist. Anmerkung 1: Die ID des Konnektors wurde vom EDM Messaging Service erfolgreich überprüft (authentifiziert), andernfalls wäre der backward sharing Aufruf zurückgewiesen worden.Anmerkung 2: Weitere Erläuterungen zu Konnektor-IDs finden sich in der Schnittstellenbeschreibung.

SharedByConnectorVersionID

PredeterminedScopeReferenceIdentifier

1..1

Version des Konnektors, über den der Aufruf der backward sharing Operation erfolgt ist.Anmerkung: Es wird die vom Konnektor gelieferte Versions-Angabe weitergegeben. Eine Überprüfung durch das EDM Messaging Service ist nicht vorgesehen bzw. möglich.

InteroperabilityProfileID

ReferenceIdentifier

0..1

Aus Gründen der Rückwärtskompatibilität ist dieses Element noch vorhanden, wird jedoch nicht mehr verwendet.

SharedByPartyID

StrictReferenceIdentifier

0..*

Die in den EDM Stammdaten zugewiesenen GLNs (Global Location Number)s für jene Beteiligten, die als „Absender“ des backward sharing fungieren. Anmerkung 1: Es können ausschließlich solche Beteiligte als Absender einer backward sharing Operation auftreten, die als Empfänger in der forward sharing Operation, auf welche sich das backward sharing bezieht, genannt sind. Anmerkung 2: Gegenwärtig können über das backward sharing zwei Arten von Information ausgetauscht werden. 1. Der Status der technischen Verarbeitung einer Message hinsichtlich der Übernahme in eine Ziel-DB („Validierung und Speicherung“). 2. Die Inhaltliche Bestätigung der forward sharing Operation einer Übergabe/Übernahme-Message durch einen Benutzer. Diese Form der Bestätigung soll von einem Konnektor dazu verwendet werden Aufträge inhaltlich zu bestätigen um die nächsten Prozessschritte einzuleiten. Beim Aufruf der ShareRetrieverStatus-Operation werden bei der technischen Verarbeitung einer Message keine Beteiligten identifiziert. Eine Zuordnung zu Beteiligten, die als Absender der Verarbeitungsrückmeldung gelten, wird hingegen vom EDM Messaging Service hergestellt. Das SharedByPartyID-Element der BackwardSharingEvent-Struktur enthält genau diese vom EDM Messaging Service hergestellte Zuordnung von Beteiligten.

SharedToPartyID

StrictReferenceIdentifier

1..1

Der Empfänger des backward sharing (des Verteilens einer Verarbeitungsrückmeldung).Anmerkung: Der Empfänger eines backward sharing muss mit dem Absender des forward sharing übereinstimmen, auf welches sich das backward sharing bezieht.

OperationTypeID

ReferenceIdentifier

1..1

Die auf Seite des forward sharing Empfängers durchgeführte Operation bzw. Aktivität, auf die sich die per backward sharing verteilte Rückmeldung bezieht (Codeliste 6801).Anmerkung: An dieser Stelle können gegenwärtig die Werte „Validierung und Speicherung“ (Übernahme in die Ziel-DB) und „Durchsicht und Prüfung durch Benutzer“ (Bestätigungsmessage) angegeben werden.

OperationStatusID

ReferenceIdentifier

1..1

Der Status der in OperationTypeID angegebenen Verarbeitungsoperation, z.B. Erfolg, Erfolg mit Hinweisen, oder Fehler (Codeliste 2089).

StatusReasonID

ReferenceIdentifier

0..1

Einer aus einer vordefinierten Liste von Gründen für den Status der Verarbeitungsoperation bzw. Bearbeitungsaktivität (Codeliste 6838). Anmerkung 1: Die Auswahl eines Grunds ist im Allgemeinen nur im Fehlerfall angegeben (OperationStatusID zeigt an, dass ein Fehler vorliegt).Anmerkung 2: Wenn der Grund für den Status ein anderer ist, als einer, der in Codeliste 6838 definiert ist, dann entfällt die StatusReasonID-Angabe. In diesem Fall soll StatusDecription angegeben sein, und Angaben zum Grund für den Status bzw. Fehler beinhalten.

StatusDescription

DescriptionText

0..1

Textuelle Beschreibung des Status der Verarbeitungsoperation bzw. Bearbeitungsaktivität (Sprache: Codeliste 7632. Ausschließlich Deutsch).

BackwardSharingEvent

AuthenticatedCancellation

Angaben zur Stornierung einer Message, ggf. mit elektronischen Siegeln oder Signaturen versehen.

AuthenticatedCancellation
Name/Typ min..max Definition

DocumentUQ

Cancellation

1..1

Die Angaben zur Stornierung.Anmerkung: „UQ“ steht für Unique. Diese Elementbezeichnung wird gewählt, um die Eindeutigkeit des Elementnamens über alle Namensräume hinweg zu gewährleisten, und so gewisse Attacken in Zusammenhang mit Siegeln und Signaturen zu unterbinden.

ds:Signatureds:Signature

0..*

Elektronische Siegel und/oder Signaturen zur Stornierung, in dem auf dem XMLDSIG-Format basierenden XAdES-Format.Anmerkung: Das Anbringen von Siegeln und/oder Signaturen ist optional.

AuthenticatedCancellation

AuthenticatedDocument

Angaben zu einer Message, bestehend aus Inhalten, Metadaten (z.B. zum Erstellungsdatum) und ggf. elektronischen Siegeln oder Signaturen.

AuthenticatedDocument
Name/Typ min..max Definition

DocumentUQ

Document

1..1

Die Message, die initial oder zur Korrektur verteilt wird, zusammen mit Metadaten und allfälligen Anhängen.Anmerkung: „UQ“ steht für Unique. Diese Elementbezeichnung wird gewählt, um die Eindeutigkeit des Elementnamens über alle Namensräume hinweg zu gewährleisten, und so gewisse Attacken in Zusammenhang mit Siegeln und Signaturen zu unterbinden.

ds:Signatureds:Signature

0..1

Elektronisches Siegel und/oder Signatur zur Message, in dem auf dem XMLDSIG-Format basierenden XAdES-Format. Anmerkung 1: Das Anbringen von einem Siegel und/oder Signatur ist optional.Anmerkung 2: Besitzt die Message selbst ein standardisiertes Format, das bereits Siegel und/oder Signaturen vorsieht, dann sind vorrangig die gemäß diesem Format vorgesehenen Siegel und/oder Signaturen bereitzustellen.

AuthenticatedDocument

Cancellation

Angaben zur Stornierung einer Message bzw einer „Kette von Messages“, die durch Überarbeitungen auseinander hervorgingen.

Cancellation
Name/Typ min..max Definition

VersionBracketUUID

UUIDIdentifier

1..1

Die UUID der zu stornierenden „Kette von Messages“.

ChangeReasonID

ReferenceIdentifier

1..1

Auswahl des Grunds für das Widderrufen einer zuvor erfolgten Übermittlung (Codeliste 7521).

Description

DescriptionText

0..1

Beschreibung bzw. Begründung des Widerrufens (Sprache: Codeliste 7632. Ausschließlich Deutsch zulässig). Anmerkung 1: Die Beschreibung bzw. Begründung des Widerrufens erfolgt ergänzend zur Auswahl des Widerrufungsgrunds in ChangeReasonID.Anmerkung 2: Im Gegensatz zur Auswahl des Widerrufungsgrunds in ChangeReasonID ist nicht für alle Widerrufungen zwingend eine Beschreibung bzw. Begründung in Description erforderlich.

DocumentOriginPartyID

StrictReferenceIdentifier

0..1

Die GLN (Global Location Number), die dem Message- und Stornierungs-Ersteller-Beteiligten in den EDM Stammdaten zugeordnet ist.Anmerkung: In Zukunft wird dieses Feld verpflichtend sein.

Cancellation

ContextIDReference

Verweis auf ein in Beziehung stehendes Objekt, mit einer ID die keine UUID ist, und mit einer Beschreibung der Art der Beziehung.

ContextIDReference
Name/Typ min..max Definition

ContextID

Token64

1..1

ID, welche den jeweilige Kontext, zu dem eine Message in Beziehung steht, identifiziert, z.B. VEBSV-ID.

ContextTypeID

ReferenceIdentifier

1..1

Art des Kontexts, z.B. VEBSV-ID (Codeliste 7688).

ContextIDReference

ContextUUIDReference

Verweis auf ein in Beziehung stehendes Objekt, mit einer ID, welche eine UUID ist (Universally Unique ID), und mit einer Beschreibung der Art der Beziehung.

ContextUUIDReference
Name/Typ min..max Definition

ContextUUID

UUIDIdentifier

1..1

UUID, welche die jeweilige Kontext-Instanz, zu dem eine Message in Beiehung steht, z.B. Vertrag oder Auftrag, eindeutig identifiziert.

ContextTypeID

ReferenceIdentifier

1..1

Art des Kontexts, z.B. Auftrag (Codeliste 7263).

ContextUUIDReference

Document

Message, bestehend aus Kopfdaten (z.B. Erstellungsdatum), Inhalt und allfälligen Anhängen (angehängten Bytefolgen bzw. Dateien).

Document
Name/Typ min..max Definition

DocumentHeader

DocumentHeader

1..1

„Kopfdaten“, d.h. allgemeine Angaben zur übermittelten Message, z.B. UUID und Typ der Message.

DocumentContent

DocumentContent

1..1

Eine Message von dem im DocumentHeader (DocumentTypeID-Element) angegebenen Message-Typ.Anmerkung: Zur besseren Trennung von Message-Formaten und dem EDM Messaging Service sind die Message-Formate nicht in die XML Schema Definitionen für die Inputs und Outputs der EDM Messaging Service Operationen eingebunden. Stattdessen wird das any-Element verwendet, und vom EDM Messaging Service auf Basis einer Message-Typ Codeliste das richtige Message-Format zur Message-Validierung herangezogen.

AttachmentBinaryObject

BinaryObject

0..8

Message-Anhang. Anhänge sind base64-codiert (siehe https://www.w3.org/TR/xmlschema-2/#base64Binary). Anmerkung 1: Pro Message sind gegenwärtig nicht mehr als 8 Anhänge zulässig. Diese Vorgabe ist bereits durch die XML Schema Definition (XSD) für die Request-Daten abgebildet. Anmerkung 2: Ein einzelner Anhang darf – in base64-Codierung – nicht größer als 16 MiB sein, d.h. 16*1024² Bytes. Diese Vorgabe ist bereits durch die XML Schema Definition (XSD) für die Request-Daten abgebildet.Anmerkung 3: Alle Anhänge zusammen dürfen – in base64-Codierung – nicht größer als 64 MiB, d.h. 64*1024² sein. Diese Vorgabe ist nicht durch die XML Schema Definition (XSD) für die Request-Daten abgebildet bzw. abbildbar, und wird durch das EDM Messaging Service somit separat geprüft.

Document

DocumentContent

Message-Inhalt.Anmerkung: (XML-)Formatvorgaben für Message-Inhalte werden von den Formatvorgaben für EDM Messaging Service Inputs und Outputs getrennt verwaltet.

DocumentContent
Name/Typ min..max Definition

DocumentContent

DocumentHeader

Kopfdaten (Metadaten) zu einer Message, z.B. Art der Message und Ersteller.

DocumentHeader
Name/Typ min..max Definition

DocumentTypeID

ReferenceIdentifier

1..1

Art der Message (Codeliste 2551).

DocumentUUID

UUIDIdentifier

1..1

UUID, welche die Message eindeutig identifiziert.

VersionBracketUUID

UUIDIdentifier

1..1

UUID, welche eine Kette von Messages, die durch Überarbeitungen bzw. Korrekturen auseinander hervorgegangen sind, eindeutig identifiziert.

VersionSequenceNumber

NonNegativeInteger8

1..1

Nichtnegative Ganzzahl, die eine Reihenfolge von Messages in einer Kette von Überarbeitungen bzw. Korrekturen definiert.

DocumentDisplayID

AssignmentIdentifier

0..1

Eine ID, die etwa in Benutzeroberflächen oder PDF-Exporten als Dokument-ID aufscheinen soll, z.B Lieferschein-Nummer.Anmerkung: Im Gegensatz zur DocumentUUID bestehen für die DocumentDisplayID keine „universellen“ Eindeutigkeitsanforderungen.

DocumentDesignation

NormalizedString256

0..1

Titel des Dokuments bzw. der Message, z.B. „Lieferschein Probst“. Anmerkung 1: Die DocumentDisplayID hat im DocumentDesignation-Text nicht mit enthalten zu sein.Anmerkung 2: In Fällen, in welchen in Benutzeroberflächen auf das Dokument Bezug genommen werden soll, aber keine DocumentDesignation angegeben ist (z.B. in tabellarischen Message-Darstellungen), wird empfohlen, anstelle der DocumentDesignation die Bezeichnung des Message-Typs anzugeben (über DocumentTypeID aus der betreffenden Codeliste).

ChangeReasonID

ReferenceIdentifier

0..1

Auswahl des Grunds für die Korrektur bei Verwendung der Operation für die Korrektur einer zuvor erfolgten Übermittlung (Codeliste 7521). Anmerkung 1: ChangeReasonID ist genau dann angegeben, wenn es sich bei der Message (aus Sicht des Message-Erstellers) um die Korrektur einer zuvor erstellten Message handelt.

Description

DescriptionText

0..1

Beschreibung bzw. Begründung einer Korrektur (Sprache: Codeliste 7632. Ausschließlich Deutsch zulässig). Anmerkung 1: Handelt es sich bei der Message NICHT um eine Korrektur, DARF das Element Description nicht angegeben sein. Anmerkung 2: Die Beschreibung bzw. Begründung der Korrektur erfolgt ergänzend zur Auswahl des Korrekturgrunds in ChangeReasonID.Anmerkung 3: Im Gegensatz zur Auswahl des Korrekturgrunds in ChangeReasonID ist nicht für alle Korrekturen zwingend eine Beschreibung bzw. Begründung einer Korrektur in Description erforderlich.

ContextUUIDReference

ContextUUIDReference

1..1

Kontextreferenzen für die Message. Mit solchen Referenzen kann ein Beteiligter, der mehrere Messages erstellt bzw. übermittelt, Zusammengehörigkeiten ausdrücken, z.B. welche Messages zum selben Auftrag bzw. Vertrag gehören.

ContextIDReference

ContextIDReference

0..64

Kontextreferenzen, die mit anderen IDs als UUIDs hergestellt werden, z.B. mittels VEBSV-IDs.

DocumentOriginPartyID

StrictReferenceIdentifier

1..1

Die GLN (Global Location Number), die dem Message-Ersteller-Beteiligten in den EDM Stammdaten zugeordnet ist.

ReferencedDocumentUUID

UUIDIdentifier

0..1

Die DocumentUUID, zu welcher man einen Korrekturvorschlag einbringen möchte. Anmerkung 1: Die referenzierte DocumentUUID darf selbst kein Korrekturvorschlag sein.Anmerkung 2: Die referenzierte DocumentUUID muss zum Zeitpunkt des Versendens die aktuellste DocumentUUID innerhalb der VersionBracket-Kette sein.

ObjectUUID

UUIDIdentifier

0..1

Die UUID, welche das Objekt in MasterMessageData eindeutig identifiziert. Ab Interface-Version 1.09 verpflichtend.

DocumentHeader

ForwardSharingEvent

Angaben zu einem forward sharing.Anmerkung: Bei einem forward sharing handelt es sich um das Übermitteln einer Message, einer Message-Korrektur, einem Message-Korrekturvorschlag oder einer Message-Stornierung.

ForwardSharingEvent
Name/Typ min..max Definition

TransactionUUID

UUIDIdentifier

1..1

UUID (Universally Unique ID), die für den Aufruf der forward sharing Operation reserviert wurde und diesen Aufruf eindeutig identifiziert.

TransactionDateTime

DateTime

1..1

Zeitstempel, mit dem das EDM Messaging Service die Abarbeitung des forward sharing Aufrufs versehen hat.

TransactionTypeID

ReferenceIdentifier

1..1

Art des forward sharing, z.B. initiales Verteilen, Verteilen einer Korrektur oder Stornieren (Codeliste 6413).

InterfaceVersionID

VersionIdentifier

1..1

Konstante, die vom Konnektor, über den der Aufruf der forward sharing Operation erfolgt ist, angegeben wurde, und die anzeigt, auf welche Version des Webservice der Konnektor ausgelegt ist.

SharedByConnectorID

StrictReferenceIdentifier

1..1

ID des Konnektors, über den der Aufruf der forward sharing Operation erfolgt ist.Anmerkung: Die ID des Konnektors wurde vom EDM Messaging Service erfolgreich überprüft (authentifiziert), andernfalls wäre der forward sharing Aufruf zurückgewiesen worden.

SharedByConnectorVersionID

PredeterminedScopeReferenceIdentifier

1..1

Version des Konnektors, über den der Aufruf der forward sharing Operation erfolgt ist.Anmerkung: Es wird die vom Konnektor gelieferte Versions-Angabe weitergegeben. Eine Überprüfung durch das EDM Messaging Service ist nicht vorgesehen bzw. möglich.

InteroperabilityProfileID

ReferenceIdentifier

0..1

Aus Gründen der Rückwärtskompatibilität ist dieses Element noch vorhanden, wird jedoch nicht mehr verwendet.

SharedByPartyID

StrictReferenceIdentifier

1..1

Die GLN (Global Location Number), die dem „Absender“-Beteiligten der Message, der Message-Korrektur oder der Message-Stornierung, in den EDM Stammdaten zugeordnet ist.

SharedToParty

Recipient

1..*

Der oder die Empfänger des forward sharing (des Verteilens einer Message, des Verteilens einer Message-Korrektur, oder des Verteilens einer Stornierung).Anmerkung: Das EDM Messaging Service liefert nur jene Empfänger, auf die der abfragende Empfänger Zugriff hat, d.h. nicht notwendigerweise die komplette beim Versenden angebene Empfänger-Liste. Dies ist in der Schnittstellenbeschreibung im Abschnitt „Zugriffsrechte“ erläutert.

ConstraintComplianceIndicator

Indicator

0..1

Sofern für den geteilten Message-Typ Prüfregeln definiert sind, und durch das EDM Messaging Service geprüft wurden, ist dieser Ja/Nein-Wert angegeben, der ausdrückt, ob alle Prüfregeln eingehalten sind.Anmerkung: Ein Nein-Wert an dieser Stelle bedeutet, dass sogenannte Hinweis-Prüfregeln nicht eingehalten sind. Wären Ablehnungs-Prüfregeln nicht eingehalten worden, dann wäre das forward sharing nicht erfolgreich vom EDM Messaging Service entgegengenommen worden, sondern allenfalls per SOAP-Fault (synchron) oder per ProcessingEvent (asynchron) abgehandelt.

DocumentContentAvailabilityIndicator

Indicator

0..1

Ja/Nein-Wert, der angibt, ob die per forward sharing geteilten Inhalte noch vom EDM Messaging Service (insbesondere per RetrieveDocument-Operation) abrufbar sind (true = noch abrufbar). Anmerkung 1: Die Aufbewahrung von geteilten Inhalten am EDM Messaging Service wird nur für begrenzte Zeiträume garantiert. Metadaten zu geteilten Inhalten werden hingegen unbegrenzt durch das EDM Messaging Service aufbewahrt. Es kann deshalb der Fall eintreten, dass am EDM Messaging Service nur noch Metadaten zu geteilten Inhalten verfügbar sind, nicht aber die Inhalte selbst.Anmerkung 2: Der DocumentContentAvailablityIndicator ist genau dann angegeben, wenn es sich bei der Art des forward sharings (siehe TransactionTypeID-Element) NICHT um Stornieren handelt.

AuthenticatedCancellation

AuthenticatedCancellation

0..1

Angaben zur Stornierung einer Message.Anmerkung 1: AuthenticatedCancellation ist genau dann angegeben, wenn es sich bei der forward transaction um eine „Stornierung“ handelt (siehe auch TransactionTypeID).

DocumentHeader

DocumentHeader

0..1

„Kopfdaten“, d.h. allgemeine Angaben zur übermittelten Message, z.B. UUID und Typ der Message.Anmerkung: Solche „Kopfdaten“ sind genau dann angegeben, wenn es sich bei der forward transaction um ein initiales Übermitteln oder ein Korrigieren handelt, nicht jedoch beim Stornieren.

ForwardSharingEvent

ForwardSharingEventRetrieved

Angaben zu einem forward sharing.Anmerkung: Bei einem forward sharing handelt es sich um das Übermitteln einer Message, einer Message-Korrektur, einem Message-Korrekturvorschlag oder einer Message-Stornierung.

ForwardSharingEventRetrieved
Name/Typ min..max Definition

TransactionUUID

UUIDIdentifier

1..1

UUID (Universally Unique ID), die für den Aufruf der forward sharing Operation reserviert wurde und diesen Aufruf eindeutig identifiziert.

TransactionDateTime

DateTime

1..1

Zeitstempel, mit dem das EDM Messaging Service die Abarbeitung des forward sharing Aufrufs versehen hat.

TransactionTypeID

ReferenceIdentifier

1..1

Art des forward sharing, z.B. initiales Verteilen, Verteilen einer Korrektur oder Stornieren (Codeliste 6413).

InterfaceVersionID

VersionIdentifier

1..1

Konstante, die vom Konnektor, über den der Aufruf der forward sharing Operation erfolgt ist, angegeben wurde, und die anzeigt, auf welche Version des Webservice der Konnektor ausgelegt ist.

SharedByConnectorID

StrictReferenceIdentifier

1..1

ID des Konnektors, über den der Aufruf der forward sharing Operation erfolgt ist.Anmerkung: Die ID des Konnektors wurde vom EDM Messaging Service erfolgreich überprüft (authentifiziert), andernfalls wäre der forward sharing Aufruf zurückgewiesen worden.

SharedByConnectorVersionID

PredeterminedScopeReferenceIdentifier

1..1

Version des Konnektors, über den der Aufruf der forward sharing Operation erfolgt ist.Anmerkung: Es wird die vom Konnektor gelieferte Versions-Angabe weitergegeben. Eine Überprüfung durch das EDM Messaging Service ist nicht vorgesehen bzw. möglich.

InteroperabilityProfileID

ReferenceIdentifier

0..1

Aus Gründen der Rückwärtskompatibilität ist dieses Element noch vorhanden, wird jedoch nicht mehr verwendet.

SharedByPartyID

StrictReferenceIdentifier

1..1

Die GLN (Global Location Number), die dem „Absender“-Beteiligten der Message, der Message-Korrektur oder der Message-Stornierung, in den EDM Stammdaten zugeordnet ist.

SharedToParty

Recipient

1..*

Der oder die Empfänger des forward sharing (des Verteilens einer Message, des Verteilens einer Message-Korrektur, oder des Verteilens einer Stornierung).Anmerkung: Das EDM Messaging Service liefert nur jene Empfänger, auf die der abfragende Empfänger Zugriff hat, d.h. nicht notwendigerweise die komplette beim Versenden angebene Empfänger-Liste. Dies ist in der Schnittstellenbeschreibung im Abschnitt „Zugriffsrechte“ erläutert.

ConstraintComplianceIndicator

Indicator

0..1

Sofern für den geteilten Message-Typ Prüfregeln definiert sind, und durch das EDM Messaging Service geprüft wurden, ist dieser Ja/Nein-Wert angegeben, der ausdrückt, ob alle Prüfregeln eingehalten sind.Anmerkung: Ein Nein-Wert an dieser Stelle bedeutet, dass sogenannte Hinweis-Prüfregeln nicht eingehalten sind. Wären Ablehnungs-Prüfregeln nicht eingehalten worden, dann wäre das forward sharing nicht erfolgreich vom EDM Messaging Service entgegengenommen worden, sondern allenfalls per SOAP-Fault (synchron) oder per ProcessingEvent (asynchron) abgehandelt.

ForwardSharingEventRetrieved

ObjectStatus

Angaben dazu, ob automatische Prüfungen eines Begleitscheins Hinweise ergeben bzw. welche Art von Hinweisen sich ergeben.

ObjectStatus
Name/Typ min..max Definition

StatusTypeID

ReferenceIdentifier

1..1

Hinweis-Kriterium (Codeliste 9813).

StatusID

ReferenceIdentifier

1..1

Art der Hinweise, die es in Bezug auf das unter StatusTypeID angegebene Kriterium gibt (Codeliste 2089).

ObjectStatus

PostProcessingEvent

Angaben zum Status von Aktionen bzw. Interaktionen, die das EDM Messaging Service in Folge des erfolgreichen Aufrufs einer schreibenden Operation mit externen Systemen durchführt.Anmerkung: Diese Struktur wird bislang ausschließlich für Rückmeldungen zum Status von SMS-Benachrichtigungen und beim erfolgreichen Erstellen eines Transportdokuments verwendet.

PostProcessingEvent
Name/Typ min..max Definition

TransactionUUID

UUIDIdentifier

1..1

UUID (Universally Unique ID), die dieses Event eindeutig identifiziert.

DateTime

DateTime

1..1

Zeitpunkt, zu dem das EDM Messaging Service die Information zum (neuen) Status der Interaktion mit einem externen System erhalten hat.

ReferredTransactionUUID

UUIDIdentifier

1..1

UUID (Universally Unique ID), die für den Aufruf der forward sharing oder backward sharing Operation reserviert wurde und diesen Aufruf eindeutig identifiziert.

ReferredTransactionTypeID

ReferenceIdentifier

1..1

Art der schreibenden Operation, zu deren Verarbeitung eine Rückmeldung erfolgt (Codeliste 6413).Anmerkung: Zu Verarbeitungsrückmeldungen (ShareRetrieverStatus) sind keine nachfolgenden Interaktionen mit externen Systemen möglich, und somit auch keine "PostProcessingEvents".

OperationTypeID

ReferenceIdentifier

1..1

Die vom EDM Messaging Service mit einem externen System durchgeführte Interaktion, auf die sich die Verarbeitungsrückmeldung bezieht (Codeliste 1313).Anmerkung: Bislang sind nur zu einer einzigen Art von Interaktion Statusbenachrichtigungen möglich, namentlich zu SMS-Benachrichtigungen (GTIN 9008390119037).

TelephoneCommunicationNetworkEndpointID

TelephoneNumberID

0..1

Telefonnummer, auf die sich die Status-Rückmeldung bezieht. Anmerkung 1: Dieses Element ist nur dann in PostProcessingEvent-Instanzen angegeben, wenn sich diese auf SMS-Benachrichtigungen beziehen (OperationTypeID gleich 9008390119037).Anmerkung 2: Wenn dieses Element in PostProcessingEvent-Instanzen zu SMS-Benachrichtigungen fehlt, dann bedeutet das, dass sich die Statusinformation auf sämtliche zu benachrichtigenden Telefonnummern aus dem ursprünglichen Request bezieht.

OperationStatusID

ReferenceIdentifier

0..1

Status der in OperationTypeID angegebenen Operation bzw. Interaktion (Codeliste 2089).Anmerkung: Der Status von Interaktionen mit externen Systemen kann nicht notwendigerweise in allen Fällen automatisch einer der 3 Kategorien „Erfolg“, „Erfolg, mit Hinweisen“, „Fehler“ zugeordnet werden. Daher ist in PostProcessingEvent-Instanzen nicht notwendigerweise ein OperationStatusID-Element enthalten.

ForwardedOperationStatusID

PredeterminedScopeReferenceIdentifier

0..1

Statuscode, wie er vom externen System, mit das EDM Messaging Service interagiert hat, geliefert wurde.Anmerkung: Für Status-Informationen zu SMS-Benachrichtigungen wird hier der vom SMS-Dienst gelieferte Status wiedergegeben.

StatusDescription

DescriptionText

0..1

Textuelle Beschreibung des Status der vom EDM Messaging Service mit einem externen System durchgeführten Interaktion (Sprache: Codeliste 7632).Anmerkung: Im allgemeinen wird an dieser Stelle die vom externen System gelieferte Statusmeldung weitergegeben, allfällig ergänzt um Informationen vom EDM Messaging Service.

ResultLink

[xs:anyURI]

0..1

Liefert den Link zum Transportdokument. Dieser Link hat eine Gültigkeit von 14 Tagen. Ist befüllt wenn es sich um das Ergebnis der Erstellung eines Transportdokuments handelt.

ResultLinkValidityEnd

DateTime

0..1

Zeigt an, wie lange der Link zum Transportdokument gültig ist.

PostProcessingEvent

ProcessingEvent

Angaben zur Verarbeitung des Aufrufs einer schreibenden Operation durch das EDM Messaging Service.

ProcessingEvent
Name/Typ min..max Definition

TransactionUUID

UUIDIdentifier

1..1

UUID (Universally Unique ID), die für den Aufruf der forward sharing oder backward sharing Operation reserviert wurde und diesen Aufruf eindeutig identifiziert.

ProcessingCompletionDateTime

DateTime

1..1

Zeitstempel, mit dem das EDM Messaging Service die Abarbeitung des Aufrufs der schreibenden asynchronen Operation versehen hat.

ReferredTransactionTypeID

ReferenceIdentifier

1..1

Art der schreibenden Operation, zu deren Verarbeitung eine Rückmeldung erfolgt (Codeliste 6413).

OperationTypeID

ReferenceIdentifier

1..1

Die vom EDM Messaging Service durchgeführte Operation, auf die sich die Verarbeitungsrückmeldung bezieht (Codeliste 6801).Anmerkung: An dieser Stelle ist ausschließlich die „Validierung und Speicherung“ vorgesehen.

OperationStatusID

ReferenceIdentifier

1..1

Status der in OperationTypeID angegebenen Verarbeitungsoperation (Codeliste 2089).Anmerkung: Da im Erfolgsfall kein ProcessingEvent-Update generiert wird, sondern ein forward sharing oder backward sharing Update, steht dieser Eintrag gegenwärtig immer auf „Fehler“.

StatusReasonID

ReferenceIdentifier

0..1

Einer aus einer vordefinierten Liste von Gründen für den Status der Verarbeitungsoperation (Codeliste 1701).Anmerkung: Wenn der Grund für den Status ein anderer ist, als einer, der in Codeliste 1701 definiert ist, dann entfällt die StatusReasonID-Angabe. In diesem Fall ist nur StatusDecription angegeben, mit Angaben zum Grund für den Status bzw. Fehler beinhalten.

StatusDescription

DescriptionText

0..1

Textuelle Beschreibung des Status der Verarbeitung durch das EDM Messaging Service (Sprache: Codeliste 7632. Ausschließlich Deutsch).

ProcessingEvent

Recipient

Angaben zum Empfänger einer Message-Übermittlung (bzw. einer Korrektur- oder Stornierungs-Übermittlung).

Recipient
Name/Typ min..max Definition

RecipientID

StrictReferenceIdentifier

1..1

Die GLN (Global Location Number), welche dem Empfänger bzw. Adressat der Message, der Message-Korrektur oder der Message-Stornierung, in den EDM Stammdaten zugeordnet ist.

TransactionPurposeCategoryID

ReferenceIdentifier

1..1

Klassifizierung des beabsichtigten Zwecks des forward sharings an diesen Empfänger, z.B. zur Info oder zur Bearbeitung (Codeliste 2976).

NoteText

String1024

0..1

Eine allfällige Anmerkung bzw. „Begleitnotiz“ vom Absender der Message, der Message-Korrektur oder der Stornierung an den Empfänger bzw. Adressaten.

TelephoneCommunicationNetworkEndpointID

TelephoneNumberID

0..8

Telefonnummern für SMS-Übermittlungen an Empfänger. Anmerkung 1: Mit einzelnen Message-Arten, insbesondere mit der Übergabe/Übernahme-Message, kann durch Angabe einer oder mehrerer Telefonnummern für SMS-Übermittlungen ausgelöst werden, dass das EDM Messaging Service per SMS Empfänger über das Eintreffen einer Message benachrichtigt bzw. per entsprechender URL dem SMS-Empfänger eine Einsichtnahme in die Message sowie allfällige weitere Aktionen ermöglicht.Anmerkung 2: Um gut für die automatische Nutzung geeignet zu sein, definiert das Schema "strenge" Vorgaben in Bezug auf das Muster, dem angegebene Telefonnummern zu entsprechen haben. Insbesondere hat die Nummer, abgesehen von einem möglichen führenden "+", ausschließlich aus Ziffern zu bestehen, d.h. keinerlei Trennzeichen zu enthalten.

Recipient

PublicKeyObject

Informationen zu einem Public Key
PublicKeyObject
Name/Typ min..max Definition

Format

Token64

1..1

Das verwendete Format, womit die Variablen des öffentlichen Schlüssels kodiert wurden. Aktuell beträgt dieser Wert immer "X.509".

Algorithm

Token64

1..1

Beschreibt die Art des Schlüssels. Aktuell handelt es sich immer um RSA-Schlüssel.

Encoded

String1024

1..1

Die kodierten Daten des Schlüssels (in Base64-Form).

PublicKeyObject

UpdateEvent

Angaben zu einem EDM Messaging Service Update (ForwardSharing, BackwardSharing, Processing, PostProcessing oder LaunchDocumentAction).

UpdateEvent
Name/Typ min..max Definition

ForwardSharingEvent

ForwardSharingEvent

0..1

Angaben zu einem forward sharing.

BackwardSharingEvent

BackwardSharingEvent

0..1

Angaben zu einem backward sharing.

ProcessingEvent

ProcessingEvent

0..1

Angaben zur Verarbeitung des Aufrufs einer asynchronen schreibenden Operation durch das EDM Messaging Service. ProcessingEvents sind nur für den Aufrufenden der schreibenden Operation, auf die sich die Angaben beziehen, abrufbar bzw. „sichtbar“.Anmerkung: Ein ProcessingEvent-Update wird nur generiert, wenn eine forward sharing oder eine backward sharing Operation nicht erfolgreich abgearbeitet werden kann. Die erfolgreiche Abarbeitung ist hingegen über entsprechende ForwardSharingEvents oder BackwardSharingEvents ersichtlich.

PostProcessingEvent

PostProcessingEvent

0..1

Angaben zum Status von Aktionen bzw. Interaktionen, die das EDM Messaging Service in Folge des erfolgreichen Aufrufs einer schreibenden Operation mit externen Systemen durchführt. Anmerkung 1: Diese Struktur wird aktuell für 2 Aktionen verwendet: 1. für die Rückmeldungen zum Status von SMS-Benachrichtigungen und 2. Zur Rückmeldung über die Erstellung eines Transportdokuments. Anmerkung 2: PostProcessingEvents kann es nur zu erfolgreichen Aufrufen asynchroner schreibender Operationen geben, d.h. "in Kombination" mit einem ForwardSharingEvent oder BackwardSharingEvent zur selben Transaktion.Anmerkung 3: Wenn beim forward sharing Telefonnummern für SMS-Benachrichtigungen angegeben werden, dann sind unterschiedlichste Fälle in Bezug auf Statusrückmeldungen möglich und zulässig. So ist etwa möglich, dass es zu keinerlei Statusrückmeldung kommt. Es ist aber ebenso möglich, dass es für eine Telefonnummer zu mehreren Statusrückmeldungen (Status-Updates) kommt. Auch bezüglich der Zusammenfassung - wird der Status je Telefonnummer rückgemeldet oder für alle Telefonnummern auf einmal - sind alle Varianten möglich und zulässig. Welche dieser Varianten eintreten, hängt vom SMS-Service ab, das vom EDM Messaging Service genutzt wird. Das EDM Messaging Service gibt solche Statusrückmeldungen eines SMS-Service in PostProcessingEvent-Strukturen weiter.

UpdateSignalEvent

UpdateSignalEvent

0..1

Benachrichtigung dazu, dass es Änderungen an einem vollelektronischen Begleitschein gibt. Anmerkung 1: Die Datenstruktur ist für aus IT-Systemen automatisch generierte Benachrichtigungen zu Updates vorgesehen, und wird bislang ausschließlich für Benachrichtigungen zu Änderungen an einem vollelektronischen Begleitschein genutzt.Anmerkung 2: Das VEBSV Webservice dient zur Übermittlung von Angaben in das Behördensystem. Es ist nicht darauf ausgelegt, Informationen in Unternehmens-Systemen auf einem aktuellen Stand (des Behördensystems) zu halten, und sieht aus diesem Grund auch kein Polling vor. Im Gegensatz dazu ist das EDM Messaging Service auf Polling ausgelegt. Über das EDM Messaging Service empfangene Signale (Benachrichtigungen) zu Begleitschein-Änderungen können somit für Unternehmens-Softwarelösungen als Auslöser herangezogen werden, über das VEBSV Webservice aktuelle Begleitschein-Daten abzurufen.

LaunchDocumentActionEvent

LaunchDocumentActionEvent

0..1

Angaben zu einem LaunchDocumentAction.

UpdateEvent

UpdateSignal

Angaben zum Update eines Begleitscheins.Anmerkung: Diese Angaben stammen aus der EDM VEBSV Anwendung, welche diese Angaben zur Verteilung an das EDM Messaging Service weitergibt.

UpdateSignal
Name/Typ min..max Definition

UpdateDateTime

DateTime

1..1

Zeitstempel des Begleitschein-Updates (von der VEBSV Anwendung stammende Angabe).

TransportID

UUIDIdentifier

0..1

Beschreibung zur einzigartigen Erkennung eines Transports durch die Transport-ID

AffectedObjectID

StrictReferenceIdentifier

0..1

VEBSV-ID des vollelektronischen Begleitscheins, der sich geändert hat.

ObjectStatus

ObjectStatus

0..8

Angaben zur Art der Hinweise, die es zum betreffenden Begleitschein gibt.

TriggerPartyID

StrictReferenceIdentifier

0..1

Die Personen-GLN (Global Location Number), die dem „Auslöser“ des Begleitschein-Updates in den EDM Stammdaten zugeordnet ist.Anmerkung: Das EDM Messaging Service liefert den auslösenden Beteiligten genau dann, wenn der abfragende Konnektor auf für diesen Beteiligten bestimmte Inhalte Zugriff hat. Damit ist „eigenes“ von „fremdem“ Auslösen unterscheidbar. Siehe auch Abschnitt „Zugriffsrechte“ in der Schnittstellenbeschreibung.

TriggerEventCategoryID

ReferenceIdentifier

0..1

Art der Begleitschein-Interaktion - Meldungsübermittlung, Meldungskorrektur oder Meldungsstornierung - welche die Begleitschein-Änderung ausgelöst hat (Codeliste 6413).

TriggerEventTypeID

ReferenceIdentifier

0..1

Die VEBSV-Meldungsart, welche das Update ausgelöst hat (Codeliste 9850).

SharedToPartyID

StrictReferenceIdentifier

1..*

Der oder die Beteiligten, für welche die Informationen zum Update eines Begleitscheins bestimmt sind.Anmerkung: Das EDM Messaging Service liefert nur jene Beteiligten, auf die der abfragende Konnektor Zugriff hat, d.h. nicht notwendigerweise die komplette Liste von Beteiligten, für welche die Informationen bestimmt sind. Dies ist in der Schnittstellenbeschreibung im Abschnitt „Zugriffsrechte“ erläutert.

UpdateSignal

UpdateSignalEvent

Angaben zum Update eines Begleitscheins.Anmerkung: Alle Angaben bis auf die TransactionUUID stammen aus der EDM VEBSV Anwendung, welche diese Angaben zur Verteilung an das EDM Messaging Service weitergibt.

UpdateSignalEvent
Name/Typ min..max Definition

TransactionUUID

UUIDIdentifier

1..1

UUID (Universally Unique ID), mit der im EDM Messaging Service die Benachrichtigung zu Änderungen am vollelektronischen Begleitschein eindeutig identifiziert wird.

TransportID

UUIDIdentifier

0..1

Beschreibung zur einzigartigen Erkennung eines Transports durch die Transport-ID

UpdateDateTime

DateTime

1..1

Zeitstempel des Begleitschein-Updates (von der VEBSV Anwendung stammende Angabe).

AffectedObjectID

StrictReferenceIdentifier

0..1

VEBSV-ID des vollelektronischen Begleitscheins, der sich geändert hat.

ObjectStatus

ObjectStatus

0..8

Angaben zur Art der Hinweise, die es zum betreffenden Begleitschein gibt.

TriggerPartyID

StrictReferenceIdentifier

0..1

Die Personen-GLN (Global Location Number), die dem „Auslöser“ des Begleitschein-Updates in den EDM Stammdaten zugeordnet ist.Anmerkung: Das EDM Messaging Service liefert den auslösenden Beteiligten genau dann, wenn der abfragende Konnektor auf für diesen Beteiligten bestimmte Inhalte Zugriff hat. Damit ist „eigenes“ von „fremdem“ Auslösen unterscheidbar. Siehe auch Abschnitt „Zugriffsrechte“ in der Schnittstellenbeschreibung.

TriggerEventCategoryID

ReferenceIdentifier

0..1

Art der Begleitschein-Interaktion - Meldungsübermittlung, Meldungskorrektur oder Meldungsstornierung - welche die Begleitschein-Änderung ausgelöst hat (Codeliste 6413).

TriggerEventTypeID

ReferenceIdentifier

0..1

Die VEBSV-Meldungsart, welche das Update ausgelöst hat (Codeliste 9850).

SharedToPartyID

StrictReferenceIdentifier

1..*

Der oder die Beteiligten, für welche die Informationen zum Update eines Begleitscheins bestimmt sind.Anmerkung: Das EDM Messaging Service liefert nur jene Beteiligten, auf die der abfragende Konnektor Zugriff hat, d.h. nicht notwendigerweise die komplette Liste von Beteiligten, für welche die Informationen bestimmt sind. Dies ist in der Schnittstellenbeschreibung im Abschnitt „Zugriffsrechte“ erläutert.

UpdateSignalEvent

ValidationResultItem

Angaben zu einem Prüfprotokolleintrag.

ValidationResultItem
Name/Typ min..max Definition

SevereViolationIndicator

Indicator

1..1

Ja/Nein-Angabe, ob die einzelne Prüfregelverletzung zu einer “Ablehnung” führt (ob aufgrund der Prüfregelverletzung die Daten technisch nicht verarbeitet werden konnten), oder es sich um einen (für sich allein nicht zur Ablehnung führenden) Hinweis handelt. “Ja” bedeutet, dass eine Ablehnung vorliegt. Insgesamt (für die Gesamtoperation) liegt eine Ablehnung genau dann vor (RejectionIndicator ist auf true), wenn es mindestens einen Ablehnungs-Prüfprotokolleintrag.“Ja” tritt genau bei der Verletzung solcher Prüfregeln auf, die im Prüfregeldokument als zur Ablehnung führend beschrieben sind.

UserDataDependencyIndicator

Indicator

1..1

Angabe dazu, ob die Prüfregelverletzung in Zusammenhang mit fachlichen Inhalten (also Inhalten, über die Benutzer Kontrolle haben) steht oder nicht. “Ja” bedeutet, dass ein Zusammenhang mit fachlichen Inhalten besteht. Diese Angabe hilft Clients bei der Handhabung des Prüfprotokolls. Steht der “UserDataDependencyIndicator” auf Nein, liegt jedenfalls ein softwareseitiges, für gewöhnlich nicht durch den Benutzer behebbares Problem vor.Anmerkung: “Nein” liegt für genau solche Prüfregeln vor, die im Prüfregeldokument mit dem Hinweis versehen sind, dass sie in erster Linie die korrekte XML-Repräsentation betreffen.

ViolatedConstraintID

StrictReferenceIdentifier

1..1

Nummer / Identifikationszeichenkette der verletzten Prüfregel. Es handelt sich um genau jene Nummern, die im Prüfregeldokument zu Prüfregeln mit angegeben sind, z.B. in der Form “(ID 1234)”.Anmerkung: Da dieselbe Prüfregel mehrfach verletzt sein kann (z.B. einmal für die Herkunftsangaben, und einmal für die Verbleibsangaben), kann dieselbe Prüfregel-ID mehrfach im Prüfprotokoll auftreten.

ResultText

DescriptionText

0..1

Beschreibung der Prüfregelverletzung (Sprache: Codeliste 7632. Ausschließlich Deutsch). Anmerkung: Die Beschreibungen werden im EDM so gestaltet, dass sie möglichst allgemeinverständlich und gut nachvollziehbar sind. Allerdings kann naturgemäß nur auf die fachlichen Inhalte und das XML-Format Bezug genommen werden. Unter diesem Vorbehalt kann, sofern es sich um eine Prüfregelverletzung handelt, für die der UserDataDependencyIndicator auf “ja” steht, der ResultText durch die Client-Software an den Benutzer “durchgereicht” werden.Benutzer werden vielfach jedoch auch den Bezug zu Elementen der grafischen Benutzeroberfläche im Client erwarten. Ein solcher Bezug kann nur durch die Client-Software hergestellt werden. Vielfach kann die Client-Software den Benutzer viel besser unterstützen, z.B. durch Verweise auf betreffende Elemente der grafischen Benutzeroberfläche, als durch bloßes “Durchreichen” der Prüfregelverletzungs-Beschreibungen.

ObjectID

OptionalTypeReferenceIdentifier

0..*

Mit dieser ID kann auf “Objekte” in den übermittelten Dateninhalten verwiesen werden, die in Zusammenhang mit der Prüfregelverletzung stehen, z.B. (nicht-natürliche) Personen oder Standorte. Anmerkung 1: In Datenübermittlungs-Prüfprotokollen können sowohl ObjectID als auch CrossReferenceObjectID-Bezüge enthalten sein. ObjectID wird zur Eingrenzung dessen, auf welchen Teil der übermittelten Dateninstanz sich der Prüfprotokolleintrag bezieht, verwendet. CrossReferenceObjectID-Bezüge werden für sonstige Bezüge verwendet, z.B. auf Stammdateneinträge oder andere bereits übermittelte Meldungen oder Deklarationen.Anmerkung 2: Bezugnahmen können beispielsweise mit im EDM zugewiesenen (Personen, Standort oder Anlagen) GLNs erfolgen. Im Attribut collectionID ist dann die GTIN 9008390104026 aus der Codeliste 1756 angegeben. Diese GTIN steht für EDM.

CrossReferenceObjectID

OptionalTypeReferenceIdentifier

0..*

Mit dieser ID kann auf “Objekte” verwiesen werden, die in Zusammenhang mit der Prüfregelverletzung stehen. Anmerkung 1: In Datenübermittlungs-Prüfprotokollen können sowohl ObjectID als auch CrossReferenceObjectID-Bezüge enthalten sein. ObjectID wird zur Eingrenzung dessen, auf welchen Teil der übermittelten Dateninstanz sich der Prüfprotokolleintrag bezieht, verwendet. CrossReferenceObjectID-Bezüge werden für sonstige Bezüge verwendet, z.B. auf Stammdateneinträge oder andere bereits übermittelte Meldungen oder Deklarationen.Anmerkung 2: Im vorliegenden Webservice wird an dieser Stelle ausschließlich auf bereits zur VEBSV-ID übermittelte Meldungen bzw. Deklarationen Bezug genommen, und zwar mit der vom EDM verwendeten Meldungs-ID (dabei handelt es sich um die für die initiale Übermittlung verwendete Datenübermittlungs-ID bzw. „Transaction ID“). Im Attribut collectionID ist deshalb ausschließlich die GTIN 9008390104026 aus der Codeliste 1756 angegeben. Diese GTIN steht für EDM.

ReferencedValue

String1024

0..1

Handelt es sich bei der Prüfregelverletzung um die “Beanstandung” eines einzelnen Datenwerts, dann kann dieser Wert in “ReferencedValue” mit angegeben werden. Stimmt bei einer übermittelten GLN beispielsweise die Prüfziffer nicht, oder gibt es zu dieser GLN keinen passenden Eintrag im EDM, dann wird in “ReferencedValue” genau diese “beanstandete” GLN zurückgeliefert.Den “beanstandeten Wert” zu kennen, kann dem Benutzer der Client-Software dabei helfen, zu identifizieren, welche Daten welcher Korrektur bedürfen.

ValidationResultItem

FailureResponse

Angaben zu einem bei der Abarbeitung eines Operationsaufrufs aufgetretenen Fehler.

FailureResponse
Name/Typ min..max Definition

FailureID

StrictReferenceIdentifier

0..1

Eine ID (Identifikationszeichenkette), die auf einen Eintrag aus Codeliste 5156 “Fehlerkategorien” verweist und solcherart den Fehler klassifiziert. Anmerkung 1: Für den Client-Endanwender ist die Fehlerkategorie im Allgemeinen unverständlich. Die Fehlerkategorie hat vielmehr den folgenden Nutzen: (a) Abhängig von der Fehlerkategorie kann die Client-Software unterschiedlich auf den Fehler reagieren, z.B. einen Datenübermittlungsversuch automatisch wiederholen oder nicht; und (b) die Fehlerkategorie kann für IT-Personal bei Fehlersuche, Tests, Debugging, usw. hilfreich sein.Anmerkung 2: Eine besondere Bedeutung kommt der Fehlerkategorie 203 “Verletzung von Datenanforderungen” zu. Liegt diese Fehlerkategorie vor, dann wird im FailureResponse auch ein sogenanntes Prüfprotokoll geliefert (siehe ValidationResultItem), welches Aufschluss darüber gibt, durch welche der übermittelten Daten welche Datenanforderungen verletzt sind. Das Prüfprotokoll kann mit jener Datenübermittlungs-ID (transaction ID), die im fehlgeschlagenen Operationsaufruf verwendet wurde, zudem auch separat abgerufen werden, und zwar mit der QueryValidationResult-Operation.

FailureText

DescriptionText

0..1

Eine Beschreibung des Fehlers (Sprache: Codeliste 7632. Ausschließlich Deutsch).Anmerkung: Die Beschreibung des Fehlers kann bei der Fehlersuche durch IT-Personal hilfreich sein. Für den Endanwender ist die Fehlerbeschreibung im Allgemeinen unverständlich. Client-Software sollte diesen Text daher nicht, bzw. nicht ohne entsprechenden Kontext, an Benutzer weitergeben.

ObjectID

ReferenceIdentifier

0..1

Eine ID aus dem Input an die Operation, mit der auf jenen Teil des Inputs verwiesen wird, der ursächlich für den Fehler ist.Anmerkung: Dieses Datenelement wird im vorliegenden Webservice nicht verwendet.

ValidationResultItem

ValidationResultItem

0..*

Prüfprotokoll, bestehend aus den einzelnen Prüfprotokolleinträgen (Informationen zu einzelnen Verletzungen von Vorgaben). Anmerkung 1: Ein Prüfprotokoll ist im FailureResponse genau dann enthalten, wenn über die FailureID angezeigt wird, dass der Operationsaufruf aufgrund der Verletzung von Datenanforderungen (FailureID 203) fehlgeschlagen ist.Anmerkung 2: Ein im FailureResponse enthaltenes Prüfprotokoll beinhaltet Angaben zu mindestens einer Datenanforderungsverletzung, die zur “Ablehnung” (zum Fehlschlagen der aufgerufenen Operation) führt. Darüber hinaus kann auch eine beliebige Zahl von “Hinweis-Datenanforderungen” verletzt sein, d.h. von Datenanforderungen, deren Verletzung nur einen Hinweis liefert, aber nicht zur Ablehnung bzw. zum Operationsabbruch führt. Auch zu allen solchen festgestellten Datenanforderungsverletzungen sind Angaben im Prüfprotokoll enthalten.

FailureResponse

ShareDocumentRequest

Input der ShareDocument-Operation.

ShareDocumentRequest
Name/Typ min..max Definition

InterfaceVersionID

VersionIdentifier

1..1

Konstante, die der Konnektor an die Webservice-Operation übergibt, und die angibt, auf welche Version des Webservice der Konnektor ausgelegt ist.

ConnectorVersionID

PredeterminedScopeReferenceIdentifier

1..1

Version des Konnektors, der den Operations-Aufruf durchführt.

InteroperabilityProfileID

ReferenceIdentifier

0..1

Aus Gründen der Rückwärtskompatibilität ist dieses Element noch vorhanden, wird jedoch nicht mehr verwendet.

AgentPersonName

NameText

0..1

Name der Person (des Client-Benutzers), deren Interaktion mit der Client-Software die Interaktion der Client-Software mit dem Webservice ausgelöst hat. Anmerkung 1: Es handelt sich hierbei um eine "private" Angabe, die ausschließlich für das bei der Webservice-Interaktion authentifizierte Unternehmen mitprotokolliert wird, aber nicht an andere Unternehmen oder Behörden weitergegeben wird. Anmerkung 2: Durch Übermittlung dieser Angabe kann die Nachvollziehbarkeit, wie Webservice-Interaktionen zustandekommen, erhöht werden.Anmerkung 3: Die Angabe des Namens an dieser Stelle ist vor allem für den Fall gedacht, dass die bei der Webservice-Interaktion (per EDM-Benutzername und unter Verwendung des Application Passwords generierten HMAC) authentifizierte Person eine andere Person ist, als diejenige, welche die Webservice-Interaktion unmittelbar ausgelöst hat. Damit kann für diejenigen Personen, die EDM-Benutzername und Application Password in Drittsoftware hinterlegen, nachvollziehbar und kontrollierbar gemacht werden, welche Webservice-Interaktionen in ihrem Namen erfolgen.

AgentTelephoneCommunicationNetworkEndpointID

TelephoneNumberID

0..1

Telefonnummer des Benutzers, dessen Interaktion mit der Client-Software die Interaktion der Client-Software mit dem Webservice ausgelöst hat. Anmerkung 1: Es handelt sich hierbei um eine "private" Angabe, die ausschließlich für das bei der Webservice-Interaktion authentifizierte Unternehmen mitprotokolliert wird, aber nicht an andere Unternehmen oder Behörden weitergegeben wird. Anmerkung 2: Durch Übermittlung dieser Angabe kann die Nachvollziehbarkeit, wie Webservice-Interaktionen zustandekommen, erhöht werden.Anmerkung 3: Die Angabe der Telefonnummer an dieser Stelle ist vor allem für Fälle vorgesehen, in welchen zunächst beim Versand einer Message in der Liste von Empfängern Telefonnummern für SMS-Benachrichtigungen angegeben werden. Erfolgt in Folge von einem dieser Empfänger das Versenden einer Antwort- oder Follow-Up-Message, und spielt dabei das Öffnen einer per SMS erhaltenen URL eine Rolle bei der Identifikation dieses Empfängers, dass sollte beim Versender der Antwort- oder Follow-Up-Message diese Telefonnummer mit angegeben sein.

TransactionUUID

UUIDIdentifier

1..1

Eine vom Client speziell für den konkreten ShareDocument-Aufruf generierte UUID (Universally Unique ID). Anmerkung 1: Mit dieser UUID kann in Folge auf den ShareDocument-Aufruf Bezug genommen werden, z.B. beim Aufruf der ShareRetrieverStatus-Operation (backward sharing). Anmerkung 2: Auch bei Verwendung der Operation zur Korrektur von zuvor übermittelten Daten wird an dieser Stelle eine neu generierte ID benötigt.Anmerkung 3: Wird eine bereits „verbrauchte“ (d.h. zuvor in einer schreibenden Operation verwendete) UUID angegeben, führt dies zum SOAP-Fault.

Recipient

Recipient

0..*

Der oder die Empfänger bzw. Adressaten der „Vorwärts-Transaktion“ (des Verteilens einer Message oder des Verteilens einer Message-Korrektur).

AuthenticatedDocument

AuthenticatedDocument

1..1

Die Message, die initial oder zur Korrektur verteilt wird, zusammen mit Metadaten.

ShareDocumentRequest

ShareDocumentResponse

Output der ShareDocument-Operation.

ShareDocumentResponse
Name/Typ min..max Definition

ResponseTypeID

Token64

0..1

Dem Wert, der in diesem Element als Response geliefert wird, kommt gegenwärtig keine Bedeutung zu.Anmerkung: Die ShareDocument-Operation wird vom EDM Messaging Service asynchron abgearbeitet. Ob der ShareDocument-Aufruf erfolgreich abgearbeitet werden konnte, muss der Client/Konnektor daher per separaten Aufrufen (QueryUpdate) feststellen.

ShareDocumentResponse

ShareDocumentCancellationRequest

Input der ShareDocumentCancellation-Operation.

ShareDocumentCancellationRequest
Name/Typ min..max Definition

InterfaceVersionID

VersionIdentifier

1..1

Konstante, die der Konnektor an die Webservice-Operation übergibt, und die angibt, auf welche Version des Webservice der Konnektor ausgelegt ist.

ConnectorVersionID

PredeterminedScopeReferenceIdentifier

1..1

Version des Konnektors, der den Operations-Aufruf durchführt.

InteroperabilityProfileID

ReferenceIdentifier

0..1

Aus Gründen der Rückwärtskompatibilität ist dieses Element noch vorhanden, wird jedoch nicht mehr verwendet.

AgentPersonName

NameText

0..1

Name der Person (des Client-Benutzers), deren Interaktion mit der Client-Software die Interaktion der Client-Software mit dem Webservice ausgelöst hat. Anmerkung 1: Es handelt sich hierbei um eine "private" Angabe, die ausschließlich für das bei der Webservice-Interaktion authentifizierte Unternehmen mitprotokolliert wird, aber nicht an andere Unternehmen oder Behörden weitergegeben wird. Anmerkung 2: Durch Übermittlung dieser Angabe kann die Nachvollziehbarkeit, wie Webservice-Interaktionen zustandekommen, erhöht werden.Anmerkung 3: Die Angabe des Namens an dieser Stelle ist vor allem für den Fall gedacht, dass die bei der Webservice-Interaktion (per EDM-Benutzername und unter Verwendung des Application Passwords generierten HMAC) authentifizierte Person eine andere Person ist, als diejenige, welche die Webservice-Interaktion unmittelbar ausgelöst hat. Damit kann für diejenigen Personen, die EDM-Benutzername und Application Password in Drittsoftware hinterlegen, nachvollziehbar und kontrollierbar gemacht werden, welche Webservice-Interaktionen in ihrem Namen erfolgen.

AgentTelephoneCommunicationNetworkEndpointID

TelephoneNumberID

0..1

Telefonnummer des Benutzers, dessen Interaktion mit der Client-Software die Interaktion der Client-Software mit dem Webservice ausgelöst hat. Anmerkung 1: Es handelt sich hierbei um eine "private" Angabe, die ausschließlich für das bei der Webservice-Interaktion authentifizierte Unternehmen mitprotokolliert wird, aber nicht an andere Unternehmen oder Behörden weitergegeben wird. Anmerkung 2: Durch Übermittlung dieser Angabe kann die Nachvollziehbarkeit, wie Webservice-Interaktionen zustandekommen, erhöht werden.Anmerkung 3: Die Angabe der Telefonnummer an dieser Stelle ist vor allem für Fälle vorgesehen, in welchen zunächst beim Versand einer Message in der Liste von Empfängern Telefonnummern für SMS-Benachrichtigungen angegeben werden. Erfolgt in Folge von einem dieser Empfänger das Versenden einer Antwort- oder Follow-Up-Message, und spielt dabei das Öffnen einer per SMS erhaltenen URL eine Rolle bei der Identifikation dieses Empfängers, dass sollte beim Versender der Antwort- oder Follow-Up-Message diese Telefonnummer mit angegeben sein.

TransactionUUID

UUIDIdentifier

1..1

Eine vom Konnektor speziell für den konkreten ShareDocumentCancellation-Aufruf generierte UUID (Universally Unique ID).

Recipient

Recipient

0..*

Der oder die Empfänger bzw. Adressaten des Stornierens (des Verteilens der Stornierung).Anmerkung: Für gewöhnlich wird eine Stornierung an alle Beteiligten weitergegeben, an welche zuvor die nunmehr stornierte Message weitergegeben wurde.

AuthenticatedCancellation

AuthenticatedCancellation

1..1

Die Inhalte der Stornierung, z.B. die UUID der zu stornierenden „Kette von Messages“ und der Stornierungsgrund.

ShareDocumentCancellationRequest

ShareDocumentCancellationResponse

Output der ShareDocumentCancellation-Operation.

ShareDocumentCancellationResponse
Name/Typ min..max Definition

ResponseTypeID

Token64

0..1

Dem Wert, der in diesem Element als Response geliefert wird, kommt gegenwärtig keine Bedeutung zu.Die ShareDocumentCancellation-Operation wird vom EDM Messaging Service asynchron abgearbeitet. Ob der ShareDocumentCancellation-Aufruf erfolgreich abgearbeitet werden konnte, muss der Client/Konnektor daher per separaten Aufrufen (QueryUpdate) feststellen.

ShareDocumentCancellationResponse

QueryDocumentValidationResultRequest

Input der QueryDocumentValidationResult-Operation.

QueryDocumentValidationResultRequest
Name/Typ min..max Definition

InterfaceVersionID

VersionIdentifier

1..1

Konstante, die der Konnektor an die Webservice-Operation übergibt, und die angibt, auf welche Version des Webservice der Konnektor ausgelegt ist.

ConnectorVersionID

PredeterminedScopeReferenceIdentifier

1..1

Version des Konnektors, der den Operations-Aufruf durchführt.

InteroperabilityProfileID

ReferenceIdentifier

0..1

Aus Gründen der Rückwärtskompatibilität ist dieses Element noch vorhanden, wird jedoch nicht mehr verwendet.

ReferredTransactionUUID

UUIDIdentifier

1..1

Die Transaction ID, die in jenem Datenübermittlungs-, Datenkorrektur- bzw. Datenstornierungs-Aufruf verwendet wurde, zu dem ein Prüfprotokoll abgerufen wird.

QueryDocumentValidationResultRequest

QueryDocumentValidationResultResponse

Output der QueryDocumentValidationResult-Operation.

QueryDocumentValidationResultResponse
Name/Typ min..max Definition

ValidationResultItem

ValidationResultItem

0..*

Informationen zu einzelnen Verletzungen von Vorgaben.

QueryDocumentValidationResultResponse

QueryUpdateRequest

Input der QueryUpdate-Operation.

QueryUpdateRequest
Name/Typ min..max Definition

InterfaceVersionID

VersionIdentifier

1..1

Konstante, die der Konnektor an die Webservice-Operation übergibt, und die angibt, auf welche Version des Webservice der Konnektor ausgelegt ist.

ConnectorVersionID

PredeterminedScopeReferenceIdentifier

1..1

Version des Konnektors, der den Operations-Aufruf durchführt.

InteroperabilityProfileID

ReferenceIdentifier

0..1

Aus Gründen der Rückwärtskompatibilität ist dieses Element noch vorhanden, wird jedoch nicht mehr verwendet.

UpdateRangeStartUUID

UUIDIdentifier

1..1

Die untere Begrenzung für den ID-Bereich abzurufender Updates. Anmerkung 1: Ob der Bereich inklusive oder exklusive UpdateRangeStartUUID abgefragt wird, kann über das UpdateRangeStartInclusionIndicator-Element gesteuert werden (Voreinstellung: inklusive). Anmerkung 2: Die QueryUpdate-Operation dient in erster Linie dazu, dass ein Konnektor für eine DB „neue“, noch nicht bekannte Updates abruft. Dazu wird die letzte Update-UUID aus dem Output des letzten QueryUpdate-Aufrufs („letzte“ in Bezug auf die Reihenfolge der Updates im QueryUpdate-Output) als UpdateRangeStartUUID -Input an den nächsten QueryUpdate-Aufruf übergeben, zusammen mit einem auf false gesetzten UpdateRangeStartInclusionIndicator. Anmerkung 3: In Fällen, in welchen keine Update-UUID aus dem Output eines vorangegangenen QueryUpdate-Aufrufs bekannt ist (z.B. weil es sich um den ersten QueryUpdate-Aufruf handelt), kann die sogenannte nil UUID verwendet werden (00000000-0000-0000-0000-000000000000). Mit dieser entfällt die untere Begrenzung für den Bereich abzurufender Updates. Dabei ist zu beachten, dass(a) die Abfragbarkeit von Updates mit der QueryUpdate-Operation durch das EDM Messaging Service nur für Updates der letzten 7 Wochen garantiert wird, und „ältere“ Updates im Output der QueryUpdate-Operation somit ggf. fehlen; und (b) dass es unzulässig ist, die QueryUpdate-Operation wiederholt mit der nil UUID als UpdateRangeStartUUID aufzurufen.

UpdateRangeEndUUID

UUIDIdentifier

0..1

Die obere Begrenzung für den ID-Bereich abzurufender Updates. Anmerkung 1: Ob der Bereich inklusive oder exklusive UpdateRangeEndID abgefragt wird, kann über das UpdateRangeEndInclusionIndicator-Element gesteuert werden (Voreinstellung: inklusive).Anmerkung 2: Eine obere Begrenzung für den ID-Bereich sollte im Allgemeinen nur dann angegeben werden, wenn ein dem Konnektor bereits bekannter Update-ID-Bereich (erneut) abgefragt wird. Die QueryUpdate-Operation dient allerdings in erster Linie dazu, neue, noch nicht bekannte Updates abzurufen. Für das Abrufen neuer Updates ist keine obere Begrenzung für den ID-Bereich abzurufender Updates anzugeben (das UpdateRangeEndID-Element entfällt).

UpdateRangeStartInclusionIndicator

Indicator

0..1

Angabe, ob die Updates inklusive jenem mit der in UpdateRangeStartID angegebenen ID abgefragt werden sollen. Anmerkung 1: Wenn QueryUpdate für die Abfrage neuer Updates verwendet wird, dann wird für gewöhnlich die letzte dem Client aus früheren Update-Abrufen bekannte Update-ID als UpdateRangeStartUUID übergeben, in UpdateRangeStartInclusionIndicator der Wert false übergeben, und UpdateRangeEndID nicht gesetzt.Anmerkung 2: Bei fehlender UpdateRangeStartInclusionIndicator-Angabe erfolgt die Abfrage inklusive UpdateRangeStartID (Inklusion ist die Voreinstellung).

UpdateRangeEndInclusionIndicator

Indicator

0..1

Angabe, ob die Updates inklusive jenem mit der in UpdateRangeEndID angegebenen ID abgefragt werden sollen. Anmerkung 1: Bei fehlender UpdateRangeEndInclusionIndicator-Angabe erfolgt die Abfrage inklusive UpdateRangeEndID (Inklusion ist die Voreinstellung).Anmerkung 2: Wird UpdateRangeEndID nicht gesetzt, dann wirkt sich ein allfällig gesetzter UpdateRangeEndInclusionIndicator–Wert nicht auf die Operation aus.

QueryUpdateRequest

QueryUpdateResponse

Output der QueryUpdate-Operation.

QueryUpdateResponse
Name/Typ min..max Definition

AdditionalUpdatesIndicator

Indicator

1..1

Ja/Nein-Angabe dazu, ob über die im Output der QueryUpdate-Operation zurückgelieferten Updates weitere Updates vorliegen und den im Input der QueryUpdate-Operation angegebenen Kriterien entsprechen.Anmerkung: Diese Systematik ist dafür vorgesehen, die Größe des Outputs der QueryUpdate-Operation sowie die Antwortzeiten zu begrenzen. Unter Umständen liefert die QueryUpdate-Operation nicht die Liste aller n Updates, die in den im Operations-Input angegebenen ID-Bereich fallen, sondern nur die ersten m (m kleiner n) Updates. In diesem Fall wird der AdditionalUpdatesIndicator im Output der QueryUpdate-Operation auf true gesetzt, und die Abfrage der Gesamtheit aller Updates kann iterativ mit mehreren QueryUpdate-Aufrufen erfolgen.

Update

UpdateEvent

0..*

Ein einzelnes Update, z.B. mit Angaben zu einem forward sharing (Verteilen einer Message, einer Korrektur oder einer Stornierung). Anmerkung 1: Die Reihenfolge von Updates im Output von QueryUpdate-Aufrufen (die Reihenfolge von Instanzen des Update-Elements) entspricht der durch das EDM Messaging Service für Updates definierten Reihenfolge. Allerdings ist der Output von QueryUpdate-Aufrufen naturgemäß auf solche Updates beschränkt, auf welche Zugriff besteht. Anmerkung 2: Es gibt die folgenden Arten von Updates: - ForwardSharingEvent: Angaben zu einem erfolgreichen forward sharing. Ein einzelner schreibender Zugriff auf das EDM Messaging Service (Aufruf von forward sharing Operationen) kann höchstens ein ForwardSharingEvent auslösen. - BackwardSharingEvent: Angaben zu einem erfolgreichen backward sharing. Ein einzelner schreibender Zugriff auf das EDM Messaging Service (Aufruf von backward sharing Operationen) kann höchstens ein BackwardSharingEvent auslösen. - ProcessingEvent: Vom EDM Messaging Service erstellte Rückmeldung zum Aufruf einer asynchronen schreibenden Operation. Wird bislang ausschließlich in solchen Fällen geliefert, in welchen ein forward sharing oder backward sharing fehlschlägt. - PostProcessingEvent: Informationen zu in Folge der erfolgreichen Verarbeitung durch das EDM Messaging Service erfolgenden Interaktionen mit externen Systemen, z.B. zur SMS-Benachrichtigung. - UpdateSignalEvent: Benachrichtigung dazu, dass es Änderungen an einem vollelektronischen Begleitschein gibt (von der EDM VEBSV Anwendung generierte und an das EDM Messaging Service weitergegebene Benachrichtigung). Anmerkung 3: Asynchrone schreibende Operationen generieren, sofern sie nicht unmittelbart fehlschlagen (SOAP-Fault), die folgenden Updates: (a) Genau ein Update, bei dem es sich entweder um ein ForwardSharingEvent, ein BackwardSharingEvent oder ein ProcessingEvent handelt. (b) Beliebig viele ("0 bis n") PostProcessingEvents.Anmerkung 4: ProcessingEvents und PostProcessingEvents sind immer nur dem Aufrufenden der schreibenden Operation zugänglich, nicht jedoch allfällig in der schreibenden Operation angegeben Empfängern. Die "Sharing-Events" sind hingegen sowohl Aufrufenden als auch Empfängern zugänglich.

QueryUpdateResponse

RetrieveDocumentRequest

Input der RetrieveDocument-Operation.

RetrieveDocumentRequest
Name/Typ min..max Definition

InterfaceVersionID

VersionIdentifier

1..1

Konstante, die der Konnektor an die Webservice-Operation übergibt, und die angibt, auf welche Version des Webservice der Konnektor ausgelegt ist.

ConnectorVersionID

PredeterminedScopeReferenceIdentifier

1..1

Version des Konnektors, der den Operations-Aufruf durchführt.

InteroperabilityProfileID

ReferenceIdentifier

0..1

Aus Gründen der Rückwärtskompatibilität ist dieses Element noch vorhanden, wird jedoch nicht mehr verwendet.

ReferredTransactionUUID

UUIDIdentifier

1..1

Die Datenübermittlungs-ID (transaction ID) aus einer forward sharing Operation, die zum Teilen einer Message oder zum Teilen einer Message-Korrektur genutzt wurde. Mit der RetrieveDocument-Operation wird in Folge die zu dieser forward sharing Operation gehörige Message (ggf. mitsamt Anhängen und Darstellunsgformaten) abgerufen.

RequestStandardFormatHTMLIndicator

Indicator

0..1

Wird dieser Ja/Nein-Wert auf Ja (true) gesetzt, dann wird die Message zusätzlich zum strukturierten elektronischen Format, z.B. XML-Instanz, auch in einem vom EDM Messaging Service generierten einheitlichen Darstellungsformat, im HTML-Format mit inkludiertem CSS-Stylesheet, abgerufen, sofern dies für den betreffenden Message-Typ unterstützt wird.

RequestStandardFormatPDFIndicator

Indicator

0..1

(zurzeit nicht unterstützt) Wird dieser Ja/Nein-Wert auf Ja (true) gesetzt, dann wird die Message zusätzlich zum strukturierten elektronischen Format, z.B. XML-Instanz, auch in einem vom EDM Messaging Service generierten einheitlichen Darstellungsformat, im PDF-Format, abgerufen, sofern dies für den betreffenden Message-Typ unterstützt wird.

RequestEncryptedResponse

Indicator

0..1

(zurzeit nicht unterstützt) Wird dieser Ja/Nein-Wert auf Ja (true) gesetzt, dann wird das angefragte Dokument mit dem im Messaging-System hinterlegten Public-Key des Benutzers verschlüsselt.

RetrieveDocumentRequest

RetrieveDocumentResponse

Output der RetrieveDocument-Operation.

RetrieveDocumentResponse
Name/Typ min..max Definition

ForwardSharingEvent

ForwardSharingEventRetrieved

1..1

Die Angaben zum forward sharing, auf welches mit den RetrieveDocument-Parametern Bezug genommen wurde.

AuthenticatedDocument

AuthenticatedDocument

0..1

Die abgerufene Message mitsamt Metadaten und Anhängen sowie allfälligen Siegeln und Signaturen.

StandardFormatHTMLBinaryObject

BinaryObject

0..1

(zurzeit nicht unterstützt) In diesem Element wird der Message-Inhalt in einer formatierten Darstellung übermittelt, und zwar als HTML-Instanz mit eingebettetem CSS Stylesheet. Anmerkung 1: Die formatierte Darstellung wird base64-codiert übermittelt (siehe https://www.w3.org/TR/xmlschema-2/#base64Binary). Anmerkung 2: Diese formatierte Darstellung wird nur dann geliefert, wenn sie über die RetrieveDocument-Request-Parameter angefordert wurde, und für den betreffenden Message-Typ eine solche Darstellung verfügbar ist. Anmerkung 3: Nähere Erläuterungen zur einheitlichen Darstellung von Messages sind in der Schnittstellenbeschreibung angegeben.Anmerkung 4: Die XML-Attribute beschreiben den Inhalt näher. Die Attribute sind dieselben wie jene des AttachmentBinaryObject-Elements aus der Document-Struktur.

StandardFormatPDFBinaryObject

BinaryObject

0..1

(zurzeit nicht unterstützt) In diesem Element wird der Message-Inhalt in einer formatierten Darstellung übermittelt, und zwar als PDF-Datei. Anmerkung 1: Die formatierte Darstellung wird base64-codiert übermittelt (siehe https://www.w3.org/TR/xmlschema-2/#base64Binary). Anmerkung 2: Diese formatierte Darstellung wird nur dann geliefert, wenn sie über die RetrieveDocument-Request-Parameter angefordert wurde, und für den betreffenden Message-Typ eine solche Darstellung verfügbar ist. Anmerkung 3: Nähere Erläuterungen zur einheitlichen Darstellung von Messages sind in der Schnittstellenbeschreibung angegeben.Anmerkung 4: Die XML-Attribute beschreiben den Inhalt näher. Die Attribute sind dieselben wie jene des AttachmentBinaryObject-Elements aus der Document-Struktur. .

RetrieveDocumentResponse

ShareRetrieverStatusRequest

Input der ShareRetrieverStatus-Operation.

ShareRetrieverStatusRequest
Name/Typ min..max Definition

InterfaceVersionID

VersionIdentifier

1..1

Konstante, die der Konnektor an die Webservice-Operation übergibt, und die angibt, auf welche Version des Webservice der Konnektor ausgelegt ist.

ConnectorVersionID

PredeterminedScopeReferenceIdentifier

1..1

Version des Konnektors, der den Operations-Aufruf durchführt.

InteroperabilityProfileID

ReferenceIdentifier

0..1

Aus Gründen der Rückwärtskompatibilität ist dieses Element noch vorhanden, wird jedoch nicht mehr verwendet.

TransactionUUID

UUIDIdentifier

1..1

Eine vom Konnektor speziell für den konkreten ShareRetrieverStatus-Aufruf generierte UUID (Universally Unique ID).

ReferredTransactionUUID

UUIDIdentifier

1..1

Transaction UUID (Universally Unique ID) des forward sharing Aufrufs, zu dessen Verarbeitung per backward sharing eine Rückmeldung erfolgt.

ReferredTransactionTypeID

ReferenceIdentifier

1..1

Art des forward sharing, z.B. initiales Verteilen, Verteilen einer Korrektur oder Stornieren (Codeliste 6413), zu dessen Verarbeitung eine Rückmeldung erfolgt.

SharedByPartyID

StrictReferenceIdentifier

0..1

Die in den EDM Stammdaten zugewiesene GLN (Global Location Number) für jenen Beteiligten, der als „Absender“ des backward sharing fungiert. Anmerkung: Backward sharing gibt es in 2 Ausprägungen: a) Rückmeldungen zur „Validierung und Speicherung“ (bei der Übernahme in die Ziel-DB). Dies ist eine vom empfangenden Konnektor generierte Rückmeldung, und nicht eine von einem einzelnen Beteiligten generierte Rückmeldung. Beim ShareRetrieverStatus-Aufruf für „Validierung und Speicherung“ wird deshalb unter SharedByPartyID kein Beteiligter angegeben. Damit jede Verarbeitungsrückmeldung auf Seite des Versenders einer Message dennoch Beteiligten zuordenbar ist, stellt das EDM Messaging Service eine solche Zuordnung her.b) „Durchsicht und Prüfung durch Benutzer“ (Bestätigungsmessage). Dabei handelt es sich um eine Rückmeldung, bei der ein identifizierter Benutzer eine Übergabe/Übernahme-Message inhaltlich bestätigt. Hierbei muss unter SharedByPartyID ein Beteiligter (jener, der die Bestätigung melden möchte) angegeben werden. Das ist in der Schnittstellenbeschreibung erläutert.

SharedToPartyID

StrictReferenceIdentifier

1..1

Der Empfänger des backward sharing (des Verteilens einer Verarbeitungsrückmeldung).Anmerkung: Der Empfänger eines backward sharing muss mit dem Absender des forward sharing übereinstimmen, auf welches sich das backward sharing bezieht.

OperationTypeID

ReferenceIdentifier

1..1

Die auf Seite des forward sharing Empfängers durchgeführte Operation bzw. Aktivität, auf die sich die per backward sharing verteilte Rückmeldung bezieht (Codeliste 6801).Anmerkung: An dieser Stelle können gegenwärtig die Werte „Validierung und Speicherung“ (Übernahme in die Ziel-DB) und „Durchsicht und Prüfung durch Benutzer“ (Bestätigungsmessage) angegeben werden.

OperationStatusID

ReferenceIdentifier

1..1

Der Status der in OperationTypeID angegebenen Verarbeitungsoperation, z.B. Erfolg, Erfolg mit Hinweisen, oder Fehler (Codeliste 2089).

StatusReasonID

ReferenceIdentifier

0..1

Einer aus einer vordefinierten Liste von Gründen für den Status der Verarbeitungsoperation bzw. Bearbeitungsaktivität (Codeliste 6838). Anmerkung 1: Die Auswahl eines Grunds ist im Allgemeinen nur im Fehlerfall angegeben (OperationStatusID zeigt an, dass ein Fehler vorliegt).Anmerkung 2: Wenn der Grund für den Status ein anderer ist, als einer, der in Codeliste 6838 definiert ist, dann entfällt die StatusReasonID-Angabe. In diesem Fall soll StatusDecription angegeben sein, und Angaben zum Grund für den Status bzw. Fehler beinhalten.

StatusDescription

DescriptionText

0..1

Textuelle Beschreibung des Status der Verarbeitungsoperation bzw. Bearbeitungsaktivität (Sprache: Codeliste 7632. Ausschließlich Deutsch).

ShareRetrieverStatusRequest

ShareRetrieverStatusResponse

Output der ShareRetrieverStatus-Operation.

ShareRetrieverStatusResponse
Name/Typ min..max Definition

ResponseTypeID

Token64

0..1

Dem Wert, der in diesem Element als Response geliefert wird, kommt gegenwärtig keine Bedeutung zu.Die ShareRetrieverStatus-Operation wird vom EDM Messaging Service asynchron abgearbeitet. Der Ablauf ist in der Schnittstellenbeschreibung erläutert.

ShareRetrieverStatusResponse

ShareSignalRequest

Input der ShareSignal-Operation.

ShareSignalRequest
Name/Typ min..max Definition

InterfaceVersionID

VersionIdentifier

1..1

Konstante, die der Konnektor an die Webservice-Operation übergibt, und die angibt, auf welche Version des Webservice der Konnektor ausgelegt ist.

ConnectorVersionID

PredeterminedScopeReferenceIdentifier

1..1

Version des Konnektors, der den Operations-Aufruf durchführt.

InteroperabilityProfileID

ReferenceIdentifier

0..1

Aus Gründen der Rückwärtskompatibilität ist dieses Element noch vorhanden, wird jedoch nicht mehr verwendet.

TransactionUUID

UUIDIdentifier

1..1

Eine vom Konnektor speziell für den konkreten ShareSignal-Aufruf generierte UUID (Universally Unique ID).

UpdateSignal

UpdateSignal

1..1

Angaben zu dem zu verteilenden Signal und zu den Adressaten des Signals.

ShareSignalRequest

ShareSignalResponse

Output der ShareSignal-Operation.

ShareSignalResponse
Name/Typ min..max Definition

ResponseTypeID

Token64

0..1

Dem Wert, der in diesem Element als Response geliefert wird, kommt gegenwärtig keine Bedeutung zu. Die ShareSignal-Operation wird vom EDM Messaging Service asynchron abgearbeitet. Ob der ShareSignal-Aufruf erfolgreich abgearbeitet werden konnte, muss der Client/Konnektor daher per separaten Aufrufen (QueryUpdate) feststellen.

ShareSignalResponse

RefreshBindingRequest

Input der RefreshBinding-Operation.

RefreshBindingRequest
Name/Typ min..max Definition

InterfaceVersionID

VersionIdentifier

1..1

Konstante, die der Konnektor an die Webservice-Operation übergibt, und die angibt, auf welche Version des Webservice der Konnektor ausgelegt ist.

ConnectorVersionID

PredeterminedScopeReferenceIdentifier

1..1

Version des Konnektors, der den Operations-Aufruf durchführt.

InteroperabilityProfileID

ReferenceIdentifier

0..1

Aus Gründen der Rückwärtskompatibilität ist dieses Element noch vorhanden, wird jedoch nicht mehr verwendet.

TransactionUUID

UUIDIdentifier

1..1

Eine vom Konnektor speziell für den konkreten RefreshBinding-Aufruf generierte UUID (Universally Unique ID).

RefreshBindingRequest

RefreshBindingResponse

Output der RefreshBinding-Operation.

RefreshBindingResponse
Name/Typ min..max Definition

ResponseTypeID

Token64

0..1

Dem Wert, der in diesem Element als Response geliefert wird, kommt gegenwärtig keine Bedeutung zu.

RefreshBindingResponse

LaunchDocumentActionEvent

Angaben zu einem LaunchDocumentAction.

LaunchDocumentActionEvent
Name/Typ min..max Definition

TransactionUUID

UUIDIdentifier

1..1

Eine vom Konnektor speziell für den konkreten LaunchDocumentAction-Aufruf generierte UUID (Universally Unique ID).

OperationTypeID

ReferenceIdentifier

1..1

Die vom EDM Messaging Service durchgeführte Operation, auf die sich die Verarbeitungsrückmeldung bezieht (Codeliste 6801).Anmerkung: An dieser Stelle ist ausschließlich die „Validierung und Speicherung“ vorgesehen.

OperationStatusID

ReferenceIdentifier

1..1

Der Status der in OperationTypeID angegebenen Verarbeitungsoperation, z.B. Erfolg, Erfolg mit Hinweisen, oder Fehler (Codeliste 2089).

StatusReasonID

ReferenceIdentifier

0..1

Einer aus einer vordefinierten Liste von Gründen für den Status der Verarbeitungsoperation (Codeliste 1701).Anmerkung: Wenn der Grund für den Status ein anderer ist, als einer, der in Codeliste 1701 definiert ist, dann entfällt die StatusReasonID-Angabe. In diesem Fall ist nur StatusDecription angegeben, mit Angaben zum Grund für den Status bzw. Fehler beinhalten.

StatusDescription

DescriptionText

0..1

Textuelle Beschreibung des Status der Verarbeitung durch das EDM Messaging Service (Sprache: Codeliste 7632. Ausschließlich Deutsch).

TransportMovementUUID

UUIDIdentifier

1..1

UUID des Transportes, für den das Transportdokument erstellt wurde.

LaunchDocumentActionEvent

LaunchDocumentActionRequest

Input der LaunchDocumentAction-Operation.

LaunchDocumentActionRequest
Name/Typ min..max Definition

InterfaceVersionID

VersionIdentifier

1..1

Konstante, die der Konnektor an die Webservice-Operation übergibt, und die angibt, auf welche Version des Webservice der Konnektor ausgelegt ist.

ConnectorVersionID

PredeterminedScopeReferenceIdentifier

1..1

Version des Konnektors, der den Operations-Aufruf durchführt.

InteroperabilityProfileID

ReferenceIdentifier

0..1

Aus Gründen der Rückwärtskompatibilität ist dieses Element noch vorhanden, wird jedoch nicht mehr verwendet.

AgentPersonName

NameText

0..1

Name der Person (des Client-Benutzers), deren Interaktion mit der Client-Software die Interaktion der Client-Software mit dem Webservice ausgelöst hat. Anmerkung 1: Es handelt sich hierbei um eine "private" Angabe, die ausschließlich für das bei der Webservice-Interaktion authentifizierte Unternehmen mitprotokolliert wird, aber nicht an andere Unternehmen oder Behörden weitergegeben wird. Anmerkung 2: Durch Übermittlung dieser Angabe kann die Nachvollziehbarkeit, wie Webservice-Interaktionen zustandekommen, erhöht werden.Anmerkung 3: Die Angabe des Namens an dieser Stelle ist vor allem für den Fall gedacht, dass die bei der Webservice-Interaktion (per EDM-Benutzername und unter Verwendung des Application Passwords generierten HMAC) authentifizierte Person eine andere Person ist, als diejenige, welche die Webservice-Interaktion unmittelbar ausgelöst hat. Damit kann für diejenigen Personen, die EDM-Benutzername und Application Password in Drittsoftware hinterlegen, nachvollziehbar und kontrollierbar gemacht werden, welche Webservice-Interaktionen in ihrem Namen erfolgen.

AgentTelephoneCommunicationNetworkEndpointID

TelephoneNumberID

0..1

Telefonnummer des Benutzers, dessen Interaktion mit der Client-Software die Interaktion der Client-Software mit dem Webservice ausgelöst hat. Anmerkung 1: Es handelt sich hierbei um eine "private" Angabe, die ausschließlich für das bei der Webservice-Interaktion authentifizierte Unternehmen mitprotokolliert wird, aber nicht an andere Unternehmen oder Behörden weitergegeben wird. Anmerkung 2: Durch Übermittlung dieser Angabe kann die Nachvollziehbarkeit, wie Webservice-Interaktionen zustandekommen, erhöht werden.Anmerkung 3: Die Angabe der Telefonnummer an dieser Stelle ist vor allem für Fälle vorgesehen, in welchen zunächst beim Versand einer Message in der Liste von Empfängern Telefonnummern für SMS-Benachrichtigungen angegeben werden. Erfolgt in Folge von einem dieser Empfänger das Versenden einer Antwort- oder Follow-Up-Message, und spielt dabei das Öffnen einer per SMS erhaltenen URL eine Rolle bei der Identifikation dieses Empfängers, dass sollte beim Versender der Antwort- oder Follow-Up-Message diese Telefonnummer mit angegeben sein.

TransactionUUID

UUIDIdentifier

1..1

Eine vom Konnektor speziell für den konkreten LaunchDocumentAction-Aufruf generierte UUID (Universally Unique ID).

TransportMovementUUID

UUIDIdentifier

1..1

UUIDs jener zuvor über das EDM Messaging Service ausgetauschten Messages, auf welche die Aktion angewandt werden soll. Anmerkung 1: Die Aktion kann nur auf solche Messages angewandt werden, auf die Zugriff besteht, z.B. weil die Message vom Beteiligten, der Aufrufender der LaunchDocumentAction-Operation ist, zuvor verteilt oder empfangen wurde.Anmerkung 2: Wurde eine Message mit der betreffenden UUID von demjenigen Beteiligten, der Aufrufer der LaunchDocumentAction-Operation ist, mehrfach geteilt oder empfangen, dann wird für die Operation die Inhalts-Instanz mit der höchsten im EDM Messaging Service zugewiesenen Reihenfolge-Zahl herangezogen. Dabei handelt es sich für gewöhnlich um die jüngste geteilte oder empfangene Inhalts-Instanz mit dieser DocumentUUID. Die Reihenfolge ist in der Schnittstellenbeschreibung unter der QueryUpdate-Operation erläutert.

ActionTypeID

ReferenceIdentifier

1..1

Art der Aktion, welche auf die ausgewählten Messages angewandt werden soll (Codeliste 1276). Anmerkung: Es gibt bisher nur eine implementierte Aktion (generateTransportInformationAccessLink) namentlich die Erzeugung des Transportdokuments, welches z.B. in Kontroll-Situationen, etwa einer Straßenkontrolle, vorgewiesen werden kann.

LaunchDocumentActionRequest

LaunchDocumentActionResponse

Output der LaunchDocumentAction-Operation.

LaunchDocumentActionResponse
Name/Typ min..max Definition

ResponseTypeID

Token64

0..1

Dem Wert, der in diesem Element als Response geliefert wird, kommt gegenwärtig keine Bedeutung zu.

LaunchDocumentActionResponse

PublicKeyRequest

Input der Public Key Abfrage-Operation.

PublicKeyRequest
Name/Typ min..max Definition

UserID

Token64

1..1

Die GLN der Person oder spezielle IDs. Mit "messaging" erhält man den Public Key des Messaging WebService.

PublicKeyRequest

PublicKeyResponse

Output der Public Key Abfrage-Operation.

PublicKeyResponse
Name/Typ min..max Definition

PublicKey

PublicKeyObject

0..1

Der öffentliche Schlüssel des registrierten Benutzers, bzw. von Messaging. Wurde eine falsche GLN übermittelt oder hat der registrierte Benutzer noch keinen Schlüssel erstellt, so ist dieser Wert leer.

PublicKeyResponse

Datentypen

AssignmentIdentifier
Name/Typ min..max Definition

AssignmentIdentifier

ms:Token64

1..1

Einem Objekt zugeordneter, in einem bestimmten Kontext eindeutiger, und somit in diesem Kontext für die Objektidentifikation geeigneter Wert. Z.B. eine zu einer Firma angegebene Firmenbuchnummer. Zusätzlich zu dem das Objekt identizierenden Wert (Identifikator) erfolgt die Identifikation der Sammlung von Identifikatoren (z.B. Register oder Codeliste, etwa Firmenbuch oder Straßenverzeichnis), der der Wert entstammt.
BinaryObject
BinaryObject
Name/Typ min..max Definition

BinaryObject

[BinaryObjectContentms:BinaryObjectContent]

1..1

Eine als Text repräsentierte Bytefolge (z.B. Datei), zusammen mit beschreibenden Attributen (z.B. Dateiname).

typeID Token64

1..1

Art der Bytefolge bzw. Datei (Codeliste 5988).

mimeCode Token64

1..1

Multipurpose Internet Mail Extensions (MIME) Content-Type Code. Ein solcher Code definiert den Inhalts- bzw. Dateityp, etwa PDF oder PNG. Es sind nicht sämtliche MIME Content Types zulässig, sondern nur die in Codeliste 5563 enthaltenen.

encodingCode Token64

1..1

Ein Multipurpose Internet Mail Extension (MIME) Content Transfer Encoding code der die Art der Repräsentation der Bytefolge als Text angibt.Anmerkung: Es sind nicht sämtliche Transfer-Encoding-Codes zulässig, sondern nur die in Codeliste 2310 enthaltenen. In Codeliste 2310 ist genau eine Codierungsart enthalten, und zwar “base64”, der für die sogenannte Base64-Codierung steht.

filename NormalizedString256

1..1

(Empfohlener) Dateiname für die Bytefolge bzw. Datei, z.B. „Lieferschein.pdf“, inklusive einer allfälligen Dateinamenserweiterung bzw. Dateisuffix (z.B. „.pdf“ im genannten Beispiel).
BinaryObjectContent
Name/Typ min..max Definition

BinaryObjectContent

xs:base64Binary

1..1

Eine Bytefolge in Base64-Codierung.
DateTime
Name/Typ min..max Definition

DateTime

xs:dateTime

1..1

Zeitpunkt (Datum und Uhrzeit).
DescriptionText
DescriptionText
Name/Typ min..max Definition

DescriptionText

[String1024ms:String1024]

1..1

Beschreibungstext, zusammen mit einem Attribut, welches die Sprache angibt.

languageID StrictToken64

1..1

Sprache, in welcher der Beschreibungstext verfasst ist (Codeliste 7632).
Indicator
Name/Typ min..max Definition

Indicator

xs:boolean

1..1

Ja/Nein-Wert (Ja: Eigenschaft trifft zu; Nein: Eigenschaft trifft nicht zu).
NameText
Name/Typ min..max Definition

NameText

xs:normalizedString

1..1

Name.
NonNegativeInteger8
Name/Typ min..max Definition

NonNegativeInteger8

xs:nonNegativeInteger

1..1

Nichtnegative ganze Zahl bestehend aus bis zu 8 Dezimalziffern.
NormalizedString256
Name/Typ min..max Definition

NormalizedString256

xs:normalizedString

1..1

Zeichenkette, die aus maximal 256 Zeichen und aus mindestens 1 Zeichen besteht, und die normalisiert ist.Anmerkung: Eine Zeichenkette gilt genau dann als normalisiert, wenn sie weder Carriage Return (#xD), Line Feed (#xA) noch Tabulatur (#x9) enthält.
OptionalTypeReferenceIdentifier
OptionalTypeReferenceIdentifier
Name/Typ min..max Definition

OptionalTypeReferenceIdentifier

[StrictToken64ms:StrictToken64]

1..1

Referenzierung eines Objekts durch Angabe eines dem Objekt zugeordneten Identifikators. Zusätzlich zum Objekt-Identifkator wird die Identifikation der Sammlung von Identifikatoren (z.B. Register oder Codeliste, etwa Abfallverzeichnis) angegeben, der der Identifikator entstammt.

collectionID StrictToken64

1..1

objectTypeName NameText

0..1
PredeterminedScopeReferenceIdentifier
PredeterminedScopeReferenceIdentifier
Name/Typ min..max Definition

PredeterminedScopeReferenceIdentifier

[Token64ms:Token64]

1..1

Referenzierung eines Objekts durch Angabe eines dem Objekt zugeordneten Identifikators.
ReferenceIdentifier
ReferenceIdentifier
Name/Typ min..max Definition

ReferenceIdentifier

[StrictToken64ms:StrictToken64]

1..1

Referenzierung eines Objekts durch Angabe eines dem Objekt zugeordneten Identifikators. Zusätzlich zum Objekt-Identifkator wird die Identifikation der Sammlung von Identifikatoren (z.B. Register oder Codeliste, etwa Abfallverzeichnis) angegeben, der der Identifikator entstammt.

collectionID StrictToken64

1..1

objectDesignation NormalizedString256

0..1
StrictReferenceIdentifier
StrictReferenceIdentifier
Name/Typ min..max Definition

StrictReferenceIdentifier

[StrictToken64ms:StrictToken64]

1..1

Referenzierung eines Objekts durch Angabe eines dem Objekt zugeordneten Identifikators.Anmerkung: Der Identifikator hat einen einfachen Aufbau zu besitzen. Insbesondere hat er keine anderen Zeichen zu enthalten als Großbuchstaben, Kleinbuchstaben, Ziffern, Bindestrich und Unterstrich. Zudem haben Bindestrich und Unterstrich weder zu Beginn noch zu Ende der Zeichenkette aufzutreten.
StrictToken64
Name/Typ min..max Definition

StrictToken64

xs:token

1..1

Zeichenkette, die aus maximal 64 und aus mindestens 1 Zeichen besteht, und die aus keinen anderen Zeichen besteht als Großbuchstaben, Kleinbuchstaben, Ziffern, Bindestrich und Unterstrich, wobei Bindestrich und Unterstrich weder zu Beginn noch zu Ende der Zeichenkette auftreten.
String1024
Name/Typ min..max Definition

String1024

xs:string

1..1

Zeichenkette, die aus maximal 1024 und aus mindestens 1 Zeichen besteht.
TelephoneNumberID
Name/Typ min..max Definition

TelephoneNumberID

xs:string

1..1

Zeichenkette, die einem "strengen" Muster für Telefonnummern entspricht, insbesondere keinerlei Trennzeichen enthält.
Token64
Name/Typ min..max Definition

Token64

xs:token

1..1

Zeichenkette, die aus maximal 64 und aus mindestens 1 Zeichen besteht, und die weder Carriage Return (#xD), Line Feed (#xA) noch Tabulatur (#x9) enthält, nicht mit einem Leerzeichen beginnt oder endet, und nicht zwei oder mehr unmittelbar aufeinander folgende Leerzeichen enthält.
UUIDIdentifier
Name/Typ min..max Definition

UUIDIdentifier

xs:string

1..1

Universally Unique Identifier (ID, die dem Muster der kanonischen Darstellung von Universally Unique Identifier (UUID) entspricht).
VersionIdentifier
Name/Typ min..max Definition

VersionIdentifier

xs:token

1..1

Versionsangabe.Die Versionsangabe besteht aus maximal 64 Zeichen. Sie besteht aus den folgenden Teilen: "Major Version"-Angabe, gefolgt von einem Punkt (#x2E), gefolgt von der "Minor Version"-Angabe. Sowohl "Major Version" als auch "Minor Version" bestehen ausschließlich aus Ziffern. "Minor Version" besteht aus genau 2 Ziffern.

Messaging-Webservice: Definitionen von Messages

MasterMessageEnvelope

“Umschlag” zu einer Message, bestehend aus “aufgezählten” bzw. referenzierten Objekten, z.B. Angaben zu Unternehmen, und den eigentlichen Inhalten.

MasterMessageEnvelope
Name/Typ min..max Definition

ListedData

MessageListedData

0..1

Aufzählung von “Objekten”, auf die im Message-Inhalt (MessageData-Element) verwiesen wird, z.B. nicht-natürliche Personen oder Standorte.Anmerkung: Solche “Objekte” können auch aus vorangegangenen bzw. übergeordneten Messages stammen, z.B. Angaben zu einer Bestellung. Anstelle der Wiederholung dieser Daten in jeder Message ist lediglich eine Bezugnahme mittels grundlegender Angaben, insbesondere IDs, vorgesehen.

MessageData

MasterMessageData

0..1

Message-Inhalt.

MasterMessageEnvelope

ActualWaypointEvent

Angaben zu einer absolvierten Station eines Transports.

ActualWaypointEvent
Name/Typ min..max Definition

DateTime

DateTime

0..1

Zeitpunkt, an dem die Station absolviert wurde, d.h. das Transportmittel den Standort verlässt, z.B. Transportbeginndatum oder Enddatum.

SiteLocalUnitReferenceID

DocumentScopeReferenceIdentifier

0..1

Bezug auf den Standort, der Station des Transports ist (Bezug auf einen Eintrag aus ListedData/LocalUnit).

PartyReferenceID

DocumentScopeReferenceIdentifier

0..1

Bezug auf das Unternehmen bzw. die Person, die vor Ort Abholung bzw. Entgegennahme abwickelt (Bezug auf einen Eintrag aus ListedData/Organization oder ListedData/Person).

ActualWaypointEvent

Address

Angaben zu einer Adresse.

Address
Name/Typ min..max Definition

Component

AddressComponent

1..*

Adresskomponenten, z.B. Straße, Postleitzahl, und dergleichen. Es sollen genau die für die Zielangabe benötigten Adresskomponenten angegeben sein. Weder sollen benötigte Adresskomponenten fehlen - z.B. werden Angaben zu Örtlichkeit und Postleitzahl fast immer benötigt - noch soll eine Ergänzung um nicht benötigte Angaben erfolgen - z.B. wird die Angabe von Verwaltungseinheiten wie Bundesland oder Bezirk fast nie benötigt.

Address

AddressComponent

Angaben zu einer Adresskomponente, z.B. Straße oder Postleitzahl. Zu einer Adresskomponente wird entweder eine Identifikation (RepresentationID, z.B. Hausnummer), oder ein Auszeichnungstext (z.B. RepresentationDesignation, z.B. Straßenname) angegeben.

AddressComponent
Name/Typ min..max Definition

TypeID

ReferenceIdentifier

1..1

Identifikation des Adresskomponententyps, z.B. Straße oder Ort (Codeliste 6856).

ID

ReferenceIdentifier

0..1

Identifikation einer Adresskomponente des angegebenen Typs, z.B. ISO-Code “040” zur Identifikation des Landes Österreich.Anmerkung: Ausschließlich für Identifikationen vorgesehen, die NICHT als Teil von korrekten Adressrepräsentationen, etwa Anschriften auf Briefen, aufscheinen. Postleitzahlen, Hausnummern oder Türnummern hingegen, die sehr wohl in der jeweiligen korrekten Adressrepräsentationen aufscheinen, werden unter “RepresentationID” angegeben.

RepresentationID

PredeterminedScopeReferenceIdentifier

0..1

Identifikation einer Adresskomponente des angegebenen Typs, z.B. “6714” in Zusammenhang mit Typ “Postgebiet (Postleitzahl)”.Anmerkung: Ausschließlich für Identifikationszeichenketten vorgesehen, die als Teil von korrekten Adressrepräsentationen, etwa Anschriften auf Briefen, aufscheinen, z.B. Postleitzahlen, Hausnummern oder Türnummern. Andere Identifikationen von Adresskomponenten, solche die nicht als Teil von korrekten Adressrepräsentationen aufscheinen, z.B. ISO-Ländercodes, werden unter “ID” angegeben.

RepresentationDesignation

AddressComponentDesignation

0..1

Bezeichnung der Adresskomponente, z.B. für eine Adresskomponente vom Typ “Straße” der Straßenname, etwa “Wiedner Hauptstraße”.

AddressComponent

AssignmentMultiPartIdentifier

Identifikation eines Grundstücks per Katastralgemeindenummer und Grundstücksnummer.

AssignmentMultiPartIdentifier
Name/Typ min..max Definition

PartIdentifier

Token64

2..2

Katastralgemeindenummer und Grundstücksnummer (in dieser Reihenfolge).

AssignmentMultiPartIdentifier

CommunicationNetworkEndpoint

Angaben zu einer Telefonnummer, Faxnummer, E-Mail-Adresse oder Website-Adresse, allgemein “Kommunikationsnetzwerkendpunkt”.

CommunicationNetworkEndpoint
Name/Typ min..max Definition

TypeID

ReferenceIdentifier

1..1

Identifikation der Art des Endpunkts eines Kommunikationsnetzwerks, z.B. E-Mail-Account, Website oder Telefonanschluss (Codeliste 6745).

ID

PredeterminedScopeReferenceIdentifier

1..1

Identifikation des Endpunkts eines Kommunikationsnetzwerks, z.B. E-Mail-Adresse, Website-Adresse (URL) oder Telefonnummer.

CommunicationNetworkEndpoint

Contact

Angaben zu einem Kontakt, z.B. einer Kontaktperson.

Contact
Name/Typ min..max Definition

PersonName

ShortNameText

0..1

Name einer Kontaktperson.

CommunicationNetworkEndpoint

CommunicationNetworkEndpoint

0..4

Telefonnummer, Faxnummer, E-Mail-Adresse oder Website-Adresse, allgemein “Kommunikationsnetzwerkendpunkte”.

Contact

DangerousGoodsDescription

Gefahrstoffbeschreibung und Sicherheitshinweise.

DangerousGoodsDescription
Name/Typ min..max Definition

Description

MultilingualDescription

1..16

Gefahrgut-Beschreibungszeile gemäß Gefahrgutvorschriften wie ADR (z.B. gemäß ADR 2017 Abschnitt 5.4.1.).Beispiel: “UN 1098 ALLYLALKOHOL, 6.1 (3), I, (C/D)”.Anmerkung 1: Handelt es sich um eine Gefahrgut-Beschreibungszeile gemäß ADR 2017, dann sind in dieser Beschreibungszeile die Buchstaben a (UN-Nummer), b (Offizielle Benennung), c (Gefahrzettelmuster), d (Verpackungsgruppe) und k (Tunnelcode) abgebildet, sowie allfällige weiteren Kennzeichnungen gemäß den Unterabschnitten zu 5.4.1, z.B. Kennzeichnung als Abfall gemäß Abschnitt 5.4.1.1.3.Anmerkung 2: Werden Gefahrgut-Beschreibungszeilen in mehreren Sprachen angegeben, dann wird erwartet, dass in IndividualDescription die unterschiedlichen Sprachvarianten derselben Beschreibungszeile angegeben sind. Ein Verteilen der unterschiedlichen Sprachvarianten auf verschiedene Description-Einträge ist hingegen nicht zulässig. Die Sprachvarianten haben für alle Zeilen dieselben zu sein. So ist es beispielsweise unzulässig, eine Zeile nur auf Deutsch anzugeben, wenn eine andere auf Deutsch und Englisch angegeben ist. Ebenso hat die Reihenfolge der Sprachen für alle Beschreibungszeilen dieselbe zu sein.

DangerousGoodsDescription

Dimension

Angaben zu Abmessungen.

Dimension
Name/Typ min..max Definition

WidthMeasure

NumericValue

1..1

Breite (Abstand zwischen linker und rechter Seite) (Größeneinheit: Codeliste 3622).

DepthMeasure

NumericValue

1..1

Tiefe (Abstand zwischen Vorderseite und Rückseite) (Größeneinheit: Codeliste 3622).

HeightMeasure

NumericValue

1..1

Höhe (vertikale Abmessung, Abstand zwischen Unterseite und Oberseite) (Größeneinheit: Codeliste 3622).

Dimension

LocalUnitMeta

Grundlegende Ortsangaben (Angaben zu einer örtlichen Einheit), z.B. zu einem Standort bzw. einer Betriebsstätte.

LocalUnitMeta
Name/Typ min..max Definition

DocumentScopeAssignmentID

DocumentScopeAssignmentIdentifier

1..1

In der XML-Dateninstanz verwendeter ("technischer") Identifikator für den Standort oder die Anlage.

ID

AssignmentIdentifier

0..8

Dem Standort bzw. der Anlage zugewiesene Identifikatoren, jeweils zusammen mit der Identifikation der Sammlung von Identifikatoren (Auswahl eines Eintrags aus Codeliste 9776).Beispiel: GLN, die im EDM zur Identifikation des Standorts verwendet wird (zusammen mit GTIN “9008390104026” für “EDM”).

PredeterminedScopeAssignmentID

PredeterminedScopeAssignmentIdentifier

0..1

Vom initialen Ersteller der Angaben zum Standort oder zur Anlage zugewiesene ID.Anmerkung: Eindeutigkeit wird bei dieser ID nur in einem engen Rahmen erwartet, z.B. nur innerhalb der vom jeweiligen Beteiligten vergebenen IDs (bei von unterschiedlichen Beteiligten zugewiesenen IDs kann es zu Konflikten kommen).

MultiPartID

AssignmentMultiPartIdentifier

0..*

Mehrteilige Identifikatoren zum Standort oder der Anlage (Identifikationsschema: Codeliste 5951).Anmerkung 1: Diese mehrteiligen Identifikatoren werden im vorliegenden Datenformat ausschließlich zur Identifikation von Grundstücken verwendet, auf welchen sich der Standort bzw. die Anlage befinden, d.h. für zweiteilige Kombinationen aus Katastralgemeindenummer und Grundstücksnummer.Anmerkung 2: Die Identifikation von Grundstücken ist als “Ausweichvariante” für Fälle vorgesehen, in welchen weder Punkt-Geodaten noch Adressen bereitgestellt werden können.

Name

LongNameText

0..1

Bezeichnung des Standorts oder der Anlage.

TypeID

ReferenceIdentifier

1..1

Art der örtlichen Einheit (Standort, ortsfeste Anlage oder mobile Anlage, Codeliste 9351).Anmerkung 1: Die Angabe von Anlagen ist nur für den Fall vorgesehen, dass ein Bezug auf den Anlagenregister-Eintrag des EDM mit angegeben wird (d.h. unter “ID” eine EDM-Anlagen-GLN angegeben wird). Andernfalls wird ausschließlich der Standort angegeben. Für im EDM registrierte Standorte wird unter “ID” ebenfalls die GLN des Standort-Eintrags im EDM erwartet. Beim Absendeort kann es sich aber beispielsweise auch um einen nicht im EDM registrierten Standort handeln. In diesem Fall wird als "Art der örtlichen Einheit" der Wert "Standort" erwartet, die “ID”-Angabe entfällt.Anmerkung 2: Für mobile Anlagen werden an dieser Stelle keine Ortsbezüge (z.B. Koordinaten, Adressen, Grundstücksnummern) erwartet. Mobile Anlagen können nicht für sich allein als Ortsbezug angegeben werden (z.B. als Absendeort), sondern nur in Kombination mit einem Bezug auf einen Standort oder eine ortsfeste Anlage (den Aufstellungsort der mobilen Anlage).

Description

MultilingualDescriptionConstrained

0..1

Anmerkungen zum Standort bzw. zur Anlage, oder im Falle von Baustellen Beschreibung der Baustelle.

Address

Address

0..1

Adresse des Standorts oder der Anlage.

gml:Pointgml:Point

0..1

Punkt-Geodaten zum Standort bzw. der Anlage im GML-Point-Format.Anmerkung 1: Es wird die Angabe des Flächenmittelpunkts des Standorts bzw. der Anlage erwartet.Anmerkung 2: Das vorliegende Datenformat unterstützt nur einen Auszug aller gemäß GML-Standard möglichen Point-Angaben. Der unterstützte Auszug ist mit einer von GML abgeleiteten, eigens definierten XSD-Datei vorgegeben.Anmerkung 3: Es wird die Angabe des räumlichen Bezugssystems erwartet (Attribut srsName). Der (jeweilige) Wert hat mit der Zeichenkette “urn:ogc:def:crs:” zu beginnen, und auch darüber hinaus dem OGC URN-Muster für räumliche Bezugssysteme zu entsprechen, z.B. “urn:ogc:def:crs:EPSG::3225”. Die zulässigen räumlichen Bezugssysteme sind in Codeliste 8390 definiert. Im Allgemeinen wird, wenn möglich, die Bereitstellung von “Originaldaten” erwartet, d.h. ohne Umrechnungen zwischen räumlichen Bezugssystemen.

LocalUnitMeta

LogisticUnitObject

Angaben zu einer Logistikeinheit.

LogisticUnitObject
Name/Typ min..max Definition

DocumentScopeAssignmentID

DocumentScopeAssignmentIdentifier

0..1

In der Dateninstanz verwendeter Identifikator für die Logistikeinheit.

UUID

UUIDIdentifier

1..1

Beim initialen Erstellen der elektronischen Logistikeinheits-Dateninstanz automatisch zugewiesene UUID (Universally Unique Identifier).

ID

AssignmentIdentifier

0..8

Identifikatoren, die der Logistikeinheit zugewiesen sind (collectionID aus Codeliste 7300).

Package

PackageCollectionObject

0..1

Art des Behältnisses bzw. der Verpackung der Logistikeinheit, z.B. Fass (Codeliste 3863).

Description

MultilingualDescriptionConstrained

0..1

Beschreibung der Logistikeinheit.

GrossPropertyStatement

PropertyStatement

0..1

Masse der Logistikeinheit inkl. Behältnissen bzw. Verpackung (so vorhanden), sowie gegebenenfalls andere Größen wie Volumen.

NetPropertyStatement

PropertyStatement

0..1

Masse der Logistikeinheit ohne Behältnissen bzw. Verpackung (z.B. Masse des Abfalls), sowie gegebenenfalls andere Größen wie Volumen oder Trockenmasse.

Dimension

Dimension

0..1

Abmessungen der Logistikeinheit.

LogisticUnitObject

MasterMessageData

Inhalte einer Message.

MasterMessageData
Name/Typ min..max Definition

Shipment

ShipmentEvent

0..*

Lieferungen und damit verbundene Dienstleistungen.

TransportMovement

TransportMovementEvent

0..*

Einzelne Transporte.

MasterMessageData

MessageListedData

Aufzählung von “Objekten”, z.B. Personen, mit deren Angaben.Anmerkung: Innerhalb des Dokuments kann auf aufgezählte “Objekte” mit einer ID verwiesen werden. Dadurch unterstützt das Datenformat die Vermeidung von Redundanz: Detailangaben zu einem “Objekt” brauchen nur einmal enthalten zu sein, auch dann wenn mehrfach auf das “Objekt” Bezug genommen wird, z.B. wenn mehrfach auf dasselbe Unternehmen Bezug genommen wird.

MessageListedData
Name/Typ min..max Definition

Person

PersonMeta

0..*

Liste von Personen (Bezug/allgemeine Angaben).Anmerkung: An anderen Stellen im Dokument erfolgen Personenangaben mittels dokumentinterner Verweise auf Einträge der Personen-Liste.

Organization

OrganizationMeta

0..*

Liste von Organisationen (“nicht-natürlichen Personen”) (Bezug/allgemeine Angaben).Anmerkung: An anderen Stellen im Dokument erfolgen Organisationsangaben mittels dokumentinterner Verweise auf Einträge der Organisations-Liste.

LocalUnit

LocalUnitMeta

0..*

Liste von örtlichen Einheiten, z.B. Standorten oder Anlagen, an denen Abholungen erfolgen (Bezug/allgemeine Angaben).Anmerkung 1: An anderen Stellen im Dokument erfolgen Angaben zu örtlichen Einheiten mittels dokumentinterner Verweise auf Einträge der Liste örtlicher Einheiten.Anmerkung 2: Eine genaue Beschreibung, was unter “örtlichen Einheiten” verstanden wird, ist bei der “LocalUnit”-Struktur zu finden.

Shipment

ShipmentEventMeta

0..*

Liste von Lieferungen (Bezug/allgemeine Angaben).

MessageListedData

MultilingualDescription

Beschreibungstext.Anmerkung: Es werden Beschreibungstexte in verschiedenen Sprachen unterstützt. Dies wird im vorliegenden Datenformat insbesondere in Zusammenhang mit Gefahrgutbeschreibungen genutzt, um Gefahrgutbeschreibungen in unterschiedlichen Sprachen, z.B. auch Englisch, zu ermöglichen.

MultilingualDescription
Name/Typ min..max Definition

IndividualDescription

Description

1..4

Beschreibungstext, mit ausgewiesener Sprache.

MultilingualDescription

MultilingualDescriptionConstrained

Beschreibungstext.Anmerkung: Im vorliegenden Datenformat werden an den meisten Stellen Beschreibungstexte in deutscher Sprache erwartet. Die vom “MultilingualDescription”-Typ grundsätzlich unterstützte Möglichkeit, Angaben in mehreren verschiedenen Sprachen zu ermöglichen, wird an diesen Stellen nicht genutzt: “IndividualDescription” ist deshalb hier nicht wiederholbar.

MultilingualDescriptionConstrained
Name/Typ min..max Definition

IndividualDescription

DescriptionConstrained

1..1

Beschreibungstext, mit ausgewiesener Sprache (Deutsch).

MultilingualDescriptionConstrained

MultilingualDesignationConstrained

Bezeichnungstext.Anmerkung: Im vorliegenden Datenformat werden an den meisten Stellen Bezeichnungstexte in deutscher Sprache erwartet. Die vom “MultilingualDesignation”-Typ grundsätzlich unterstützte Möglichkeit, Angaben in mehreren verschiedenen Sprachen zu ermöglichen, wird an diesen Stellen nicht genutzt: “IndividualDesignation” ist deshalb hier nicht wiederholbar.

MultilingualDesignationConstrained
Name/Typ min..max Definition

IndividualDesignation

Designation

1..1

Kennungstext in individuellen Sprachen.

MultilingualDesignationConstrained

SiteServiceEvent

Angaben zu einer im Zuge einer Lieferung am Abholort erfolgenden Dienstleistung.

SiteServiceEvent
Name/Typ min..max Definition

Period

Period

0..1

Zeitraum, in dem das Ereignis stattfindet.

Description

MultilingualDescriptionConstrained

0..1

Beschreibung der Dienstleistung am Abholort.

Contact

Contact

0..1

Vor-Ort-Kontakt für den Erbringer der Dienstleistung.

SiteLocalUnitReferenceID

DocumentScopeReferenceIdentifier

0..1

Bezug auf den Standort, an dem die Abholung erfolgt (Bezug auf einen Eintrag aus ListedData/LocalUnit).

StationaryInstallationLocalUnitReferenceID

DocumentScopeReferenceIdentifier

0..1

Bezug auf die ortsfeste Anlage, an der die Abholung erfolgt (Bezug auf einen Eintrag aus ListedData/LocalUnit).

MobileInstallationLocalUnitReferenceID

DocumentScopeReferenceIdentifier

0..1

Bezug auf die mobile Anlage, an der die Abholung erfolgt (Bezug auf einen Eintrag aus ListedData/LocalUnit).

PartyReferenceID

DocumentScopeReferenceIdentifier

0..1

Bezug auf das Unternehmen bzw. die Person, die vor Ort die Abholung abwickelt (Bezug auf einen Eintrag aus ListedData/Organization oder ListedData/Person).Anmerkung: Dabei kann es sich um den Übergeber (im rechtlichen Sinn) handeln, es kann sich aber auch um davon abweichende Unternehmen handeln.

SiteServiceEvent

OrganizationMeta

Grundlegende Angaben zu einer Organisation, z.B. zu einer juristischen Person.

OrganizationMeta
Name/Typ min..max Definition

DocumentScopeAssignmentID

DocumentScopeAssignmentIdentifier

1..1

In der XML-Dateninstanz verwendeter ("technischer") Identifikator für das Unternehmen bzw. die nicht-natürliche Person.

ID

AssignmentIdentifier

0..8

Dem Unternehmen bzw. der nicht-natürlichen Person zugewiesene Identifikatoren, jeweils zusammen mit der Identifikation der Sammlung von Identifikatoren (Auswahl eines Eintrags aus Codeliste 8131).Beispiel: GLN (Global Location Number), die der nicht-natürlichen Person im EDM zugewiesen ist (zusammen mit GTIN “9008390104026” für “EDM”).Anmerkung: Es wird empfohlen, zu sämtlichen nicht-natürlichen Personen die GLN mit anzuführen, mit der die betreffende Person im EDM registriert ist.

Name

LongNameText

0..1

Bezeichnung des Unternehmens bzw. der nicht-natürlichen Person.

Address

Address

0..1

Sitzadresse des Unternehmens bzw. der nicht-natürlichen Person.

OrganizationMeta

PackageCollectionObject

Angaben zu einem oder mehreren Packstücken desselben Behältnistyps bzw. Verpackungstyps.

PackageCollectionObject
Name/Typ min..max Definition

PackageTypeID

ReferenceIdentifier

0..1

Art des Behältnisses bzw. der Verpackung, z.B. Fass (Codeliste 3863).

PackageTypeDesignation

Designation

0..1

Art des Behältnisses bzw. der Verpackung, z.B. Fass.Anmerkung: Die textuelle Angabe der Art der Verpackung ist für solche Verpackungsarten vorgesehen, für die kein passender Codelisteneintrag existiert.

TotalQuantity

DecimalNonNegativeIntegerNumeral20Digits

1..1

Gesamtzahl der Packstücke des angegebenen Typs.

PackageCollectionObject

Period

Angaben zu einem Zeitraum.

Period
Name/Typ min..max Definition

StartDate

Date

1..1

Beginndatum (erster Tag des Zeitraums).

EndDate

Date

1..1

Enddatum (letzter Tag des Zeitraums).

StartTime

Time

0..1

Beginn-Uhrzeit.

EndTime

Time

0..1

End-Uhrzeit.

Period

PersonMeta

Grundlegende Angaben zu einer Person, z.B. Vorname, Nachname und Geburtsdatum.Anmerkung: Solche Angaben zu natürlichen Personen werden in Dateninstanzen dieses Datenformats etwa dann benötigt, wenn Angaben zu einem Entsorgungsauftrag ausgetauscht werden, der von einer natürlichen Person stammt.

PersonMeta
Name/Typ min..max Definition

DocumentScopeAssignmentID

DocumentScopeAssignmentIdentifier

1..1

In der XML-Dateninstanz verwendeter ("technischer") Identifikator für die Person.

ID

AssignmentIdentifier

0..1

Der natürlichen Person zugewiesene Identifikatoren, jeweils zusammen mit der Identifikation der Sammlung von Identifikatoren (Auswahl eines Eintrags aus Codeliste 1756). Beispiel: GLN (Global Location Number), die der Person im EDM zugewiesen ist (zusammen mit GTIN “9008390104026” für “EDM”).Anmerkung: Im vorliegenden Datenformat ist für natürliche Personen ausschließlich die Angabe von GLNs vorgesehen bzw. möglich, mit welchen diese Personen im EDM registriert sind. Die Angabe anderer Identifikationsnummern ist hingegen nicht vorgesehen.

GivenName

GivenNameText

0..1

Vorname.

FamilyName

FamilyNameText

0..1

Nachname.

GenderID

ReferenceIdentifier

0..1

Geschlecht (Codeliste 4287).

Address

Address

0..1

Anschrift der Person (typischerweise Adresse des Hauptwohnsitzes).

PersonMeta

PlannedWaypointEvent

Angaben zu einer geplanten Station eines Transports.

PlannedWaypointEvent
Name/Typ min..max Definition

Period

<<>>

0..1

Zeitraum, in dem sich das Transportmittel am Standort befindet.Anmerkung: Das Enddatum muss mit dem Beginndatum übereinstimmen, d.h. der Transport muss für einen konkreten Tag angekündigt sein. Diese Vorgabe ist auch per XSD-assert im XML Schema enthalten. Aus Gründen der Einheitlichkeit und der Übereinstimmung mit GS1 XML kommt an dieser Stelle dennoch die Period-Struktur zum Einsatz.

SiteLocalUnitReferenceID

DocumentScopeReferenceIdentifier

0..1

Bezug auf den Standort, der Station des Transports ist (Bezug auf einen Eintrag aus ListedData/LocalUnit).

PartyReferenceID

DocumentScopeReferenceIdentifier

0..1

Bezug auf das Unternehmen bzw. die Person, die vor Ort Abholung bzw. Entgegennahme abwickelt (Bezug auf einen Eintrag aus ListedData/Organization oder ListedData/Person).

LoadingWaypoint

Indicator

1..1

Angabe ob es sich um eine Be- oder Entladung handelt.

TransshipmentWaypoint

Indicator

0..1

Angabe ob es sich um eine Umladung handelt.

InitialSiteLocalUnitReferenceID

DocumentScopeReferenceIdentifier

0..1

Bezug auf den Standort, der die erste bzw. letzte Statition des Transports ist (Bezug auf einen Eintrag aus ListedData/LocalUnit). Nur relevant für Umladewegpunkte (TransshipmentWaypoint=true), da der Wert ansonsten mit SiteLocalUnitReferenceID gleich ist.

InitialPartyReferenceID

DocumentScopeReferenceIdentifier

0..1

Bezug auf das Unternehmen bzw. die Person, die die erste Abholung bzw. letzte Entgegennahme abwickelt (Bezug auf einen Eintrag aus ListedData/Organization oder ListedData/Person). Nur relevant für Umladewegpunkte (TransshipmentWaypoint=true), da der Wert ansonsten mit PartyReferenceID gleich ist.

PlannedWaypointEvent

PropertyStatement

Aussage über eine Eigenschaft, z.B. Masse oder Volumen.

PropertyStatement
Name/Typ min..max Definition

PropertyKindID

ReferenceIdentifier

1..1

Identifikation einer Eigenschaftsart aus einer Codeliste von Eigenschaftsarten, z.B. Masse oder Volumen.Anmerkung: Aus welcher Codeliste von Eigenschaftsarten die Eigenschaftsart stammen muss, hängt vom Kontext ab, in dem PropertyStatement verwendet wird, und ist dort beschrieben.

ValueAssignmentStatement

ValueAssignmentStatement

1..1

Eine Wertzuweisungs-Aussage, z.B. “hat 200kg”.

QuantificationTypeID

ReferenceIdentifier

0..1

Identifikation der Bestimmungsart (gemessen, gerechnet, geschätzt; Codeliste 7299).

MethodID

RelaxedReferenceNoRoleIdentifier

0..1

Identifikation einer Methode, die zur Bestimmung der Eigenschaft angewandt wurde.Anmerkung: Dieses Element ist für eine künftige Verwendung vorgesehen. Gemäß aktueller Datenformat-Spezifikation ist dieses Element nicht zu verwenden.

MethodDescription

MultilingualDescriptionConstrained

0..1

Bezeichnung und/oder Beschreibung der Methode, mit welcher die Eigenschaft bestimmt wurde.

PropertyStatement

ShipmentEvent

Angaben zu einer Lieferung.

ShipmentEvent
Name/Typ min..max Definition

DocumentScopeAssignmentID

DocumentScopeAssignmentIdentifier

0..1

In der Dateninstanz verwendeter Identifikator für die Lieferung.

UUID

UUIDIdentifier

0..1

Beim initialen Erstellen der elektronischen Lieferungs-Dateninstanz automatisch zugewiesene UUID (Universally Unique Identifier).Anmerkung: Die UUID dient eindeutiger Zuordenbarkeit in der maschinellen Verarbeitung. Menschen brauchen mit UUIDs nicht notwendigerweise konfrontiert zu werden (in Benutzeroberflächen, Ausdrucken, usw.). Eine für Menschen einfacher handhabbare, und in Benutzeroberflächen, usw. jedenfalls zu verwendende ID ist in PredeterminedScopeAssignmentID vorgesehen.

PredeterminedScopeAssignmentID

PredeterminedScopeAssignmentIdentifier

0..1

Vom initialen Ersteller der Angaben zur Lieferung zugewiesene ID.Anmerkung 1: Es ist hierbei die Haupt-ID gemeint, die für Menschen die eindeutige Erkennbarkeit gewährleistet, und somit jedenfalls in Benutzeroberflächen, Ausdrucken, usw. mit angegeben sein soll.Anmerkung 2: Eindeutigkeit wird bei dieser ID nur in einem engen Rahmen erwartet, z.B. nur innerhalb der vom jeweiligen Beteiligten vergebenen IDs (bei von unterschiedlichen Beteiligten zugewiesenen IDs kann es zu Konflikten kommen), und innerhalb eines zeitlichen Rahmens von ungefähr einem Jahr (über mehrere Jahre Hinweg kann es zu ID-Konflikten kommen).

ID

AssignmentIdentifier

0..8

Identifikatoren, die der Lieferung zugewiesen sind (collectionID aus Codeliste 7725).

Designation

MultilingualDesignationConstrained

0..1

Bezeichnungstext zur Lieferung.

Description

MultilingualDescriptionConstrained

0..1

Beschreibung der Lieferung.

ShipmentItem

ShipmentItemObject

0..*

Zur Lieferung gehörende Lieferungseinheiten.

Package

PackageCollectionObject

0..*

Angaben zu Art der Behältnisse bzw. Verpackungen und Anzahl der zu dieser Lieferung gehörenden Packstücke.

PickUpSiteService

SiteServiceEvent

0..1

Angaben zur Abholung der Lieferung.

DropOffSiteService

SiteServiceEvent

0..1

Angaben zur Zustellung der Lieferung.

HandOverPartyReferenceID

DocumentScopeReferenceIdentifier

0..1

Bezug auf den Übergeber der Lieferung (Bezug auf einen Eintrag aus ListedData/Party). Anmerkung 1: Entspricht “Shipper” in GS1 XML.Anmerkung 2: Kann als Teil von Begleit- bzw. Beförderungsdokumenten gemäß Gefahrgutvorschriften wie ADR (Buchstabe g gemäß ADR 2017 Abschnitt 5.4.1.1.1) und RID relevant sein - siehe auch DangerousGoods-Element.

IntermediatePartyReferenceID

DocumentScopeReferenceIdentifier

0..*

Angaben zu Streckengeschäftspartner. Anmerkung 1: Die Reihenfolge ist relevant.

TakeOverPartyReferenceID

DocumentScopeReferenceIdentifier

0..1

Bezug auf den Übernehmer der Lieferung (Bezug auf einen Eintrag aus ListedData/Party).Anmerkung 1: Entspricht “Receiver” in GS1 XML.Anmerkung 2: Kann als Teil von Begleit- bzw. Beförderungsdokumenten gemäß Gefahrgutvorschriften wie ADR (Buchstabe g gemäß ADR 2017 Abschnitt 5.4.1.1.1) und RID relevant sein - siehe auch DangerousGoods-Element.

RejectionReasonID

ReferenceIdentifier

0..1

Grund für die Ablehnung der Übergabe bzw. Übernahme (Codeliste 3161).

LastResponseDateTime

DateTime

0..1

Frist (Datum und Uhrzeit) für Rückmeldung zur Teilnahme am Streckengeschäft.

ShipmentEvent

ShipmentEventMeta

Grundlegende Angaben zu einer Lieferung.

ShipmentEventMeta
Name/Typ min..max Definition

DocumentScopeAssignmentID

DocumentScopeAssignmentIdentifier

1..1

In der Dateninstanz verwendeter Identifikator für die Lieferung.

UUID

UUIDIdentifier

1..1

Beim initialen Erstellen der elektronischen Lieferungs-Dateninstanz automatisch zugewiesene UUID (Universally Unique Identifier).Anmerkung: Die UUID dient eindeutiger Zuordenbarkeit in der maschinellen Verarbeitung. Menschen brauchen mit UUIDs nicht notwendigerweise konfrontiert zu werden (in Benutzeroberflächen, Ausdrucken, usw.). Eine für Menschen einfacher handhabbare, und in Benutzeroberflächen, usw. jedenfalls zu verwendende ID ist in PredeterminedScopeAssignmentID vorgesehen.

PredeterminedScopeAssignmentID

PredeterminedScopeAssignmentIdentifier

0..1

Vom initialen Ersteller der Angaben zur Lieferung zugewiesene ID.Anmerkung 1: Es ist hierbei die Haupt-ID gemeint, die für Menschen die eindeutige Erkennbarkeit gewährleistet, und somit jedenfalls in Benutzeroberflächen, Ausdrucken, usw. mit angegeben sein soll.Anmerkung 2: Eindeutigkeit wird bei dieser ID nur in einem engen Rahmen erwartet, z.B. nur innerhalb der vom jeweiligen Beteiligten vergebenen IDs (bei von unterschiedlichen Beteiligten zugewiesenen IDs kann es zu Konflikten kommen), und innerhalb eines zeitlichen Rahmens von ungefähr einem Jahr (über mehrere Jahre Hinweg kann es zu ID-Konflikten kommen).

Designation

MultilingualDesignationConstrained

0..1

Bezeichnungstext zur Lieferung.

ShipmentItem

ShipmentItemMeta

0..*

Grundlegende Angaben zu Lieferungseinheiten, die zu dieser Lieferung gehören.

ShipmentEventMeta

ShipmentItemMeta

Grundlegende Angaben zu einer Lieferungseinheit.

ShipmentItemMeta
Name/Typ min..max Definition

DocumentScopeAssignmentID

DocumentScopeAssignmentIdentifier

1..1

In der Dateninstanz verwendeter Identifikator für die Lieferungseinheit.

UUID

UUIDIdentifier

1..1

Beim initialen Erstellen der elektronischen Lieferungseinheit-Dateninstanz automatisch zugewiesene UUID (Universally Unique Identifier).Anmerkung: Die UUID dient eindeutiger Zuordenbarkeit in der maschinellen Verarbeitung. Menschen brauchen mit UUIDs nicht notwendigerweise konfrontiert zu werden (in Benutzeroberflächen, Ausdrucken, usw.). Eine für Menschen einfacher handhabbare, und in Benutzeroberflächen, usw. jedenfalls zu verwendende ID ist in PredeterminedScopeAssignmentID vorgesehen.

PredeterminedScopeAssignmentID

PredeterminedScopeAssignmentIdentifier

0..1

Vom initialen Ersteller der Angaben zur Lieferungseinheit zugewiesene ID.Anmerkung 1: Es ist hierbei die Haupt-ID gemeint, die für Menschen die eindeutige Erkennbarkeit gewährleistet, und somit jedenfalls in Benutzeroberflächen, Ausdrucken, usw. mit angegeben sein soll.Anmerkung 2: Eindeutigkeit wird bei dieser ID nur in einem engen Rahmen erwartet, z.B. nur innerhalb der vom jeweiligen Beteiligten vergebenen IDs (bei von unterschiedlichen Beteiligten zugewiesenen IDs kann es zu Konflikten kommen), und innerhalb eines zeitlichen Rahmens von ungefähr einem Jahr (über mehrere Jahre Hinweg kann es zu ID-Konflikten kommen).

Designation

MultilingualDesignationConstrained

0..1

Bezeichnungstext zur Lieferungseinheit.

ShipmentItemMeta

ShipmentItemObject

Angaben zu einer Lieferungseinheit.

ShipmentItemObject
Name/Typ min..max Definition

DocumentScopeAssignmentID

DocumentScopeAssignmentIdentifier

0..1

In der Dateninstanz verwendeter Identifikator für die Lieferungseinheit.

UUID

UUIDIdentifier

0..1

Beim initialen Erstellen der elektronischen Lieferungseinheit-Dateninstanz automatisch zugewiesene UUID (Universally Unique Identifier).

LineItemNumber

DecimalPositiveIntegerNumeral8Digits

0..1

Die Nummer der Lieferungseinheit innerhalb der Lieferung (1, 2, …​).

PredeterminedScopeAssignmentID

PredeterminedScopeAssignmentIdentifier

0..1

Vom initialen Ersteller der Angaben zur Lieferungseinheit zugewiesene ID.Anmerkung 1: Es ist hierbei die Haupt-ID gemeint, die für Menschen die eindeutige Erkennbarkeit gewährleistet, und somit jedenfalls in Benutzeroberflächen, Ausdrucken, usw. mit angegeben sein soll.Anmerkung 2: Eindeutigkeit wird bei dieser ID nur in einem engen Rahmen erwartet, z.B. nur innerhalb der vom jeweiligen Beteiligten vergebenen IDs (bei von unterschiedlichen Beteiligten zugewiesenen IDs kann es zu Konflikten kommen), und innerhalb eines zeitlichen Rahmens von ungefähr einem Jahr (über mehrere Jahre Hinweg kann es zu ID-Konflikten kommen).

WasteTypeID

ReferenceIdentifier

0..1

Art des Abfalls.Unterstützte Klassifikationen:1. Österreichische Abfallverzeichnisverordnung (Anlage 5) (collectionID: 5174; Inhalt: Code aus Codeliste 5174);

WasteContaminationTypeID

ReferenceIdentifier

0..*

Kontaminationen des Abfalls (zutreffende Kontaminationsgruppen) (Codeliste 7835).

Description

MultilingualDescriptionConstrained

0..1

Beschreibung der Lieferungseinheit.

Package

PackageCollectionObject

0..1

Angaben zu Art der Behältnisse bzw. Verpackungen und Anzahl der zu dieser Lieferungseinheit gehörenden Packstücke.Anmerkung: Art und Anzahl der Behältnisse (Bruttomasse) ist auch als Teil von Begleit- bzw. Beförderungs-Dokumenten gemäß Gefahrgutvorschriften wie ADR (Buchstabe e gemäß ADR 2017 Abschnitt 5.4.1.1.1) und RID relevant - siehe auch DangerousGoodsDescription-Element.

GrossPropertyStatement

PropertyStatement

0..1

Gesamtmasse der Lieferungseinheit inkl. Verpackungen (so vorhanden), sowie gegebenenfalls andere Größen wie Volumen (PropertyKindID: Eintrag aus Codeliste 4288. NumericValue/@unitID: Eintrag aus Codeliste 8575).Anmerkung: Die Gesamtmasse inkl. Behältnissen (Bruttomasse) ist auch als Teil von Begleit- bzw. Beförderungs-Dokumenten gemäß Gefahrgutvorschriften wie ADR (Buchstabe f gemäß ADR 2017 Abschnitt 5.4.1.1.1) und RID relevant - siehe auch DangerousGoodsDescription-Element.

NetPropertyStatement

PropertyStatement

0..1

Masse der Lieferungseinheit ohne Verpackungen (z.B. Masse des Abfalls), sowie gegebenenfalls andere Größen wie Volumen oder Trockenmasse (PropertyKindID: Eintrag aus Codeliste 9000. NumericValue/@unitID: Eintrag aus Codeliste 8575).Anmerkung: Masse bzw. Volumen sind auch als Teil von Begleit- bzw. Beförderungsdokumenten gemäß Gefahrgutvorschriften wie ADR (Buchstabe f gemäß ADR 2017 Abschnitt 5.4.1.1.1) und RID relevant - siehe auch DangerousGoodsDescription-Element.

LogisticUnit

LogisticUnitObject

0..1

Logistikeinheiten, die zur Lieferungseinheit gehören.

ConsignmentNoteReferenceID

PredeterminedScopeReferenceIdentifier

0..1

“VEBSV-ID” (ID zum elektronischen Begleitscheinverfahren).Anmerkung: Über die sogenannte “VEBSV-ID” (Abfall-Übergabe/Übernahme- bzw. Beförderungs-ID) werden zusammengehörige Angaben zu Abfall-Übergaben/Übernahmen und Abfalltransporten (vor und nach Übergabe/Übernahme bzw. Transport) miteinander in Verbindung gebracht.

DangerousGoodsDescription

DangerousGoodsDescription

0..1

Zur Lieferungseinheit gehörende Sicherheitshinweise für den Umgang mit Gefahrstoffen.Anmerkung: Ein Teil der für Begleit- bzw. Beförderungsdokumente gemäß Gefahrgutvorschriften wie ADR und RID relevanten Angaben, z.B. zu Absender, Empfänger, Masse bzw. Volumen, ist als gewöhnlicher Bestandteil der Beschreibung von Lieferungen vorgesehen (d.h. unabhängig davon, ob es sich um Gefahrgut handelt oder nicht). Im Datenformat werden diese Angaben daher in der Struktur zur Beschreibung von Gefahrgut bzw. Sicherheitshinweisen nicht wiederholt.

ContainsPersistentOrganicPollutant

Indicator

0..1

PersistentOrganicPollutant (POP) Kennzeichen.

ShipmentItemObject

TransportItemObject

Angaben zu Transportgut.

TransportItemObject
Name/Typ min..max Definition

ShipmentItemReferenceID

DocumentScopeReferenceIdentifier

0..1

Bezug auf die Lieferungseinheit, dem das Transportgut entspricht bzw. zu dem es gehört.

ServiceTypeID

PredeterminedScopeReferenceIdentifier

0..1

Art der Dienstleistung (Code/Identifikationsnummer, die der Dienstleistungserbringer der Art von Dienstleistung, d.h. der Abfall/Transportgut-Abholung zugewiesen hat, z.B. Artikelnummer).Anmerkung: Transporte erfolgen im Allgemeinen im Einklang mit zuvor übermittelten Bestellungen. Die Art der Dienstleistung (Dienstleistungsnummer, Artikelnummer) ergibt sich daher im Allgemeinen aus der Bestellung, und braucht in den Angaben zum Transport nicht wiederholt zu werden. Bei Durchführung des Transports kann es jedoch auch passieren, dass Abweichungen zu einer zuvor übermittelten Bestellung festgestellt werden, z.B. dass es sich um eine andere Abfallart handelt. In diesem Fall sind für gewöhnlich korrigierte Bestellangaben auszutauschen. Mit dem ServiceTypeID-Element wird darüber hinaus ermöglicht, direkt in den Transportangaben eine “korrigierte” Dienstleistungs- bzw. Artikel-Nummer zu übermitteln.

WasteTypeID

ReferenceIdentifier

0..1

Art des Abfalls.Unterstützte Klassifikationen:1. Österreichische Abfallverzeichnisverordnung (Anlage 5) (collectionID: 5174; Inhalt: Code aus Codeliste 5174);

WasteContaminationTypeID

ReferenceIdentifier

0..*

Kontaminationen des Abfalls (zutreffende Kontaminationsgruppen) (Codeliste 7835).

Description

MultilingualDescriptionConstrained

0..1

Beschreibung des Transportguts.

Package

PackageCollectionObject

0..1

Angaben zu Art und Anzahl der Behältnisse bzw. Verpackungen.

GrossPropertyStatement

PropertyStatement

0..1

Gesamtmasse des Transportguts inkl. Behältnisse bzw. Verpackungen (so vorhanden), sowie gegebenenfalls andere Größen wie Volumen (PropertyKindID: Eintrag aus Codeliste 4288. NumericValue/@unitID: Eintrag aus Codeliste 8575).

NetPropertyStatement

PropertyStatement

0..1

Masse des Transportguts ohne Behältnisse bzw. Verpackungen (z.B. Masse des Abfalls), sowie gegebenenfalls andere Größen wie Volumen oder Trockenmasse (PropertyKindID: Eintrag aus Codeliste 9000. NumericValue/@unitID: Eintrag aus Codeliste 8575).

ConsignmentNoteReferenceID

PredeterminedScopeReferenceIdentifier

0..1

“VEBSV-ID” (ID zum elektronischen Begleitscheinverfahren).Anmerkung: Über die sogenannte “VEBSV-ID” (Abfall-Übergabe/Übernahme bzw. Beförderungs-ID) werden zusammengehörige Angaben zu Abfall-Übergaben/Übernahmen und Abfalltransporten (vor und nach Übergabe/Übernahme bzw. Transport) miteinander in Verbindung gebracht.

DangerousGoodsDescription

DangerousGoodsDescription

0..1

Zum Transportgut gehörende Sicherheitshinweise für den Umgang mit Gefahrstoffen.Anmerkung 1: Ein Teil der für Begleit- bzw. Beförderungsdokumente gemäß Gefahrgutvorschriften wie ADR und RID relevanten Angaben, z.B. zu Absender, Empfänger, Masse bzw. Volumen, ist als gewöhnlicher Bestandteil der Beschreibung des Transportguts vorgesehen (d.h. unabhängig davon, ob es sich um Gefahrgut handelt oder nicht). Im Datenformat werden diese Angaben daher in der Struktur zur Beschreibung von Gefahrgut bzw. Sicherheitshinweisen nicht wiederholt.Anmerkung 2: In Angaben zu entladenem Transportgut werden im Allgemeinen keine Angaben zu Sicherheitshinweisen für den Umgang mit Gefahrstoffen benötigt.

ContainsPersistentOrganicPollutant

Indicator

0..1

PersistentOrganicPollutant (POP) Kennzeichen.

TransportItemObject

TransportMeansObject

Angaben zu einem Transportmittel, d.h. einem Gerät mit eigenem Motor bzw. Antrieb, das dazu dient, Güter oder andere Gegenstände zu transportieren, z.B. LKW, Zug (Lokomotive), Flugzeug oder Schiff.

TransportMeansObject
Name/Typ min..max Definition

PredeterminedScopeAssignmentID

PredeterminedScopeAssignmentIdentifier

0..1

ID, die dem Transportmittel zugewiesen ist, z.B. LKW-Kennzeichen.

ModeID

ReferenceIdentifier

0..1

Art des Transports, der mit dem Transportmittel durchgeführt wird, z.B. Straße oder Schiene (Codeliste 2939).

TransportMeansObject

TransportMovementEvent

Angaben zu einem Transport, z.B. Transporteur und Art des Transportmittels.

TransportMovementEvent
Name/Typ min..max Definition

DocumentScopeAssignmentID

DocumentScopeAssignmentIdentifier

0..1

In der Dateninstanz verwendeter Identifikator für den Transport.

UUID

UUIDIdentifier

1..1

Beim initialen Erstellen der elektronischen Transport-Dateninstanz automatisch zugewiesene UUID (Universally Unique Identifier).Anmerkung: Die UUID dient eindeutiger Zuordenbarkeit in der maschinellen Verarbeitung. Menschen brauchen mit UUIDs nicht notwendigerweise konfrontiert zu werden (in Benutzeroberflächen, Ausdrucken, usw.). Eine für Menschen einfacher handhabbare, und in Benutzeroberflächen, usw. jedenfalls zu verwendende ID ist in PredeterminedScopeAssignmentID vorgesehen.

PredeterminedScopeAssignmentID

PredeterminedScopeAssignmentIdentifier

0..1

Vom initialen Ersteller der Angaben zum Transport zugewiesene ID.Anmerkung 1: Es ist hierbei die Haupt-ID gemeint, die für Menschen die eindeutige Erkennbarkeit gewährleistet, und somit jedenfalls in Benutzeroberflächen, Ausdrucken, usw. mit angegeben sein soll.Anmerkung 2: Eindeutigkeit wird bei dieser ID nur in einem engen Rahmen erwartet, z.B. nur innerhalb der vom jeweiligen Beteiligten vergebenen IDs (bei von unterschiedlichen Beteiligten zugewiesenen IDs kann es zu Konflikten kommen), und innerhalb eines zeitlichen Rahmens von ungefähr einem Jahr (über mehrere Jahre Hinweg kann es zu ID-Konflikten kommen).

Designation

MultilingualDesignationConstrained

0..1

Bezeichnungstext zum Transport.

Description

MultilingualDescriptionConstrained

0..1

Anmerkungen zum Transport.

Contact

Contact

0..1

Kontaktangaben zum konkreten Transport.

TransportMeans

TransportMeansObject

0..1

Angaben zum Transportmittel, mit dem der Transport durchgeführt wird.

AbortReasonId

ReferenceIdentifier

0..1

Grund für den Transportabbruch (Codeliste 8723).

ActualWaypointEvent

ActualWaypointEvent

0..1

Bereits absolvierte Stationen des Transports, z.B. zum Beladen und Entladen von Lieferungen oder zum Durchführen sonstiger Dienstleistungen.

PlannedWaypointEvent

PlannedWaypointEvent

0..2

Geplante Stationen des Transports, z.B. zum Beladen und Entladen von Lieferungen oder zum Durchführen sonstiger Dienstleistungen.

TransportItem

TransportItemObject

0..*

Angaben zu einem Transportgut.

CarrierPartyReferenceID

DocumentScopeReferenceIdentifier

0..1

Bezug auf den Transporteur (Eintrag aus ListedData/Organization).

TransportMovementEvent

ValueAssignmentStatement

Eine Wertzuweisungs-Aussage, dh eine Aussage über das Annehmen von Werten, z.B. “hat 200kg”.

ValueAssignmentStatement
Name/Typ min..max Definition

NumericValue

NumericValue

0..1

Als Zahl angegebener Wert, potentiell in Kombination mit einer Einheit, z.B. “200kg” (“200 Kilogramm”).Anmerkung: Die Einheit wird über den ISO/UCUM-Code identifiziert.

ValueAssignmentStatement

Datentypen

AddressComponentDesignation
Name/Typ min..max Definition

AddressComponentDesignation

Token120

1..1

Bezeichnung einer Adresskomponente, z.B. für eine Adresskomponente vom Typ “Straße” der Straßenname, etwa “Wiedner Hauptstraße”.
AssignmentIdentifier
AssignmentIdentifier
Name/Typ min..max Definition

AssignmentIdentifier

[Token64Token64]

1..1

Einem Objekt zugeordnete, in einem bestimmten Kontext eindeutige, und somit in diesem Kontext für die Objektidentifikation geeignete Zeichenkette. Z.B. eine zu einer Firma angegebene Firmenbuchnummer. Zusätzlich zu der das Objekt identifizierenden Zeichenkette wird eine Identifikation der Sammlung von IDs angegeben.

collectionID SimpleToken

1..1

Identifikation der Sammlung von Identifikatoren (z.B. Register oder Codeliste), der die angegebene Identifikationszeichenkette entstammt.Anmerkung 1: Wenn es sich bei der Sammlung von Identifikatoren um eine Codeliste handelt, dann wird die 4-stellige Codelisten-Nummer als Identifikation der Sammlung von Identifikatoren angegeben. Wenn es sich bei der Sammlung von Identifikatoren um ein Register handelt, dann wird diejenige ID (GTIN), die dem Register gemäß Codeliste zugewiesen ist, als Identifikation der Sammlung von Identifikatoren angegeben. Die Identifikation der Codeliste selbst kann und soll in diesem Fall nicht angegeben werden.Anmerkung 2: Welche Sammlungen von Identifikatoren zulässigerweise identifiziert werden können, hängt vom Kontext ab, in dem der Datentyp verwendet wird.

collectionDesignation NormalizedString256

0..1

Bezeichnung der Sammlung, aus der die angegebene Identifikationszeichenkette stammt, z.B. “Firmenbuch”.
Date
Name/Typ min..max Definition

Date

xs:date

1..1

Datum, d.h. Identifikation eines Tages.
DateTime
Name/Typ min..max Definition

DateTime

xs:dateTime

1..1

Zeitpunkt.
DecimalNonNegativeIntegerNumeral20Digits
Name/Typ min..max Definition

DecimalNonNegativeIntegerNumeral20Digits

xs:nonNegativeInteger

1..1

Wertebereich, zu dem alle dezimalen Numerale gehören, die aus maximal 20 Ziffern bestehen, und die nichtnegative ganze Zahlen repräsentieren.
DecimalNumeral25Digits
Name/Typ min..max Definition

DecimalNumeral25Digits

xs:decimal

1..1

Wertebereich, zu dem alle dezimalen Numerale gehören, die aus insgesamt maximal 25 Ziffern bestehen, von denen maximal 5 Nachkommastellen sind.
DecimalPositiveIntegerNumeral8Digits
Name/Typ min..max Definition

DecimalPositiveIntegerNumeral8Digits

xs:positiveInteger

1..1

Wertebereich, zu dem alle dezimalen Numerale gehören, die aus maximal 8 Ziffern bestehen, und die positive ganze Zahlen repräsentieren.
Designation
Designation
Name/Typ min..max Definition

Designation

[Token120Token120]

1..1

Zeichenkette, z.B. Wort, Phrase, usw., die der Erkennung und Unterscheidung dient. Beispiele sind Straßennamen und Dokumenttitel.

languageID SimpleToken

0..1

Identifikation der Sprache, in der die Kennung angegeben ist (Codeliste 7632). Für Kennungen, die sprachunabhängig sind, z.B. Nummern, entfällt die Angabe der Sprache.
Description
Description
Name/Typ min..max Definition

Description

[String1024String1024]

1..1

Beschreibungstext.

languageID SimpleToken

1..1

Identifikation der Sprache, in der die Beschreibung angegeben ist (Codeliste 7632).
DescriptionConstrained
DescriptionConstrained
Name/Typ min..max Definition

DescriptionConstrained

[String1024String1024]

1..1

Beschreibungstext in deutscher Sprache.

languageID SimpleToken

1..1

Identifikation der Sprache, in der die Beschreibung angegeben ist (Codeliste 7632).
DocumentScopeAssignmentIdentifier
Name/Typ min..max Definition

DocumentScopeAssignmentIdentifier

xs:token

1..1

In einem Objektkontext angegebener Wert (Identifikator), der innerhalb der Dateninstanz für etwaige Referenzierungen des Objekts verwendet wird.Anmerkung: Für Identifikatoren dieses Typs kann die Eindeutigkeit nur im Dateninstanzkontext vorausgesetzt werden, eine darüber hinausgehende Eindeutigkeit gibt es nicht notwendigerweise. Im Detail bedeutet das: Beim automatisierten ERSTELLEN des Dokuments durch eine Software sind Identifikatoren zu verwenden, die ZUMINDEST innerhalb des Dokuments eindeutig sind. Es genügt also beispielsweise das Durchnummerieren der im Dokument vorkommenden Objekte mit Ganzzahlen {1, 2, …​, n}. Sofern vorhanden eignet sich aber auch die Verwendung von Identifikatoren, die über den Dokumentkontext hinaus eindeutig sind, da diese ebenfalls der Voraussetzung genügen, innerhalb des Dokuments eindeutig zu sein. Beim EINLESEN und VERARBEITEN eines Dokuments darf jedoch ausschließlich die dateninstanzweite Eindeutigkeit der Identifikatoren vorausgesetzt werden. Eine über den Dateninstanzkontext hinausgehende Zuordenbarkeit der Identifikatoren darf nicht angenommen werden!
DocumentScopeReferenceIdentifier
DocumentScopeReferenceIdentifier
Name/Typ min..max Definition

DocumentScopeReferenceIdentifier

[DocumentScopeReferenceIdentifierContentDocumentScopeReferenceIdentifierContent]

1..1

Referenzierung eines Objekts mittels eines an anderer Stelle in der Dateninstanz dem Objekt zugewiesenen, im Dateninstanzkontext gültigen, Identifikators, ohne Möglichkeit der Angabe einer Rolle.
DocumentScopeReferenceIdentifierContent
Name/Typ min..max Definition

DocumentScopeReferenceIdentifierContent

Token64

1..1

Referenzierung eines Objekts mittels eines an anderer Stelle im Dokument dem Objekt zugewiesenen im Dokumentkontext gültigen Identifikators.
FamilyNameText
Name/Typ min..max Definition

FamilyNameText

Token40

1..1

Familienname.
GivenNameText
Name/Typ min..max Definition

GivenNameText

Token40

1..1

Vorname.
Indicator
Name/Typ min..max Definition

Indicator

xs:boolean

1..1

Ja/Nein-Wert (Ja: Eigenschaft trifft zu; Nein: Eigenschaft trifft nicht zu).
LongNameText
Name/Typ min..max Definition

LongNameText

Token120

1..1

Name.
NormalizedString256
Name/Typ min..max Definition

NormalizedString256

xs:normalizedString

1..1

Wertebereich, zu dem alle normalisierten Zeichenketten gehören, die aus maximal 256 Zeichen bestehen. Ausnahme: Die aus 0 Zeichen bestehende Zeichenkette.Anmerkung: Eine normalisierte Zeichenkette ist eine Zeichenkette, die weder Carriage Return (#xD), Line Feed (#xA) noch Tabulatur (#x9) Zeichen enthält.
NumericValue
NumericValue
Name/Typ min..max Definition

NumericValue

[DecimalNumeral25DigitsDecimalNumeral25Digits]

1..1

Zahlenwert, z.B. für eine Größenangabe.Anmerkung: Je nach Größenart kann die Angabe einer Größeneinheit erforderlich sein, z.B. “Kilogramm”, “Millimeter”, “Milligramm pro Liter”.

unitID Token64

0..1

Identifikation einer Größeneinheit, auf die sich die Zahlenwert-Größenangabe bezieht.Anmerkung: Welche Größeneinheiten zulässig sind, hängt vom Kontext ab, in dem der Datentyp verwendet wird.
PredeterminedScopeAssignmentIdentifier
PredeterminedScopeAssignmentIdentifier
Name/Typ min..max Definition

PredeterminedScopeAssignmentIdentifier

[Token64Token64]

1..1

Einem Objekt zugeordneter, in einem bestimmten Kontext eindeutiger, und somit in diesem Kontext für die Objektidentifikation geeigneter Wert. Der Kontext der Vergabe, Zuweisung und Gültigkeit des Identifikators wird nicht explizit deklariert, sondern bei jeder Verwendung des Datentyps individuell vorgegeben.

collectionDesignation NormalizedString256

0..1

Kennungstext für die Sammlung von Identifikatoren.
PredeterminedScopeReferenceIdentifier
PredeterminedScopeReferenceIdentifier
Name/Typ min..max Definition

PredeterminedScopeReferenceIdentifier

[Token64Token64]

1..1

Bezugnahme auf ein Objekt durch Angabe einer dem Objekt zugeordneten Identifikationszeichenkette.Beispiel: Bezugnahme auf eine Website durch Angabe der Website-Adresse (URL).Anmerkung: Die Sammlung von Identifikationszeichenketten, aus der die angegebene Identifikationszeichenkette stammt, wird nicht ausgewiesen, sondern ist durch den Kontext vorbestimmt: Im Falle von Website-Adressen braucht beispielsweise nicht explizit ausgewiesen zu werden, dass es sich um eine durch IANA/ICANN-akkreditierte Registrare registrierte URL handelt. Gleiches gilt beispielsweise für Telefonnummern, Faxnummern, E-Mail-Adressen und Hausnummern.
ReferenceIdentifier
ReferenceIdentifier
Name/Typ min..max Definition

ReferenceIdentifier

[SimpleTokenSimpleToken]

1..1

Bezugnahme auf ein Objekt durch Angabe einer dem Objekt zugeordneten Identifikationszeichenkette.Beispiel: Bezugnahme auf eine Abfallart durch Angabe eine Abfallschlüsselnummer.Anmerkung: Zusätzlich zur Identifikationszeichenkette wird die ID jener Sammlung (z.B. Register oder Codeliste, etwa Abfallverzeichnis) angegeben, aus der die Identifikationszeichenkette stammt.Anmerkung: Auf welche Objekte zulässigerweise Bezug genommen werden kann, hängt vom Kontext ab, in dem der Datentyp verwendet wird.

collectionID SimpleToken

1..1

Identifikation der Sammlung (z.B. Register oder Codeliste), aus der die angegebene Identifikationszeichenkette stammt.Beispiel: Die vierstellige Nummer “3862” zur Identifikation der Codeliste “Länder”.

objectDesignation NormalizedString256

0..1

Bezeichnung des Objekts, auf das Bezug genommen wird.Beispiel: Wird auf Finnland Bezug genommen, dann kann das wie folgt geschehen: Als Identifikationszeichenkette wird “246” eingetragen (dabei handelt es sich um den ISO 3166-1 Code von Finnland), als Identifikation der Sammlung “3862” (das ist die vierstellige Nummer der EDM-“Länder”-Codeliste), und als Objektbezeichnung “Finnland”.
RelaxedReferenceNoRoleIdentifier
RelaxedReferenceNoRoleIdentifier
Name/Typ min..max Definition

RelaxedReferenceNoRoleIdentifier

[Token64Token64]

1..1

Referenzierung eines Objekts durch Angabe eines dem Objekt zugeordneten Identifikators, z.B. Referenzierung einer Abfallart durch eine Abfallschlüsselnummer. Zusätzlich zum Objekt-Identifkator wird die Identifikation der Sammlung von Identifikatoren (z.B. Register oder Codeliste, etwa Abfallverzeichnis) benötigt, der der Identifikator entstammt.Anmerkung: Aus welchen Sammlungen von Identifikatoren das referenzierte Objekt zulässigerweise stammen kann, hängt vom Kontext ab, in dem der Datentyp verwendet wird.Anmerkung: Der Datentyp “RelaxedReferenceNoRoleIdentifier” entspricht “ReferenceNoRoleIdentifier”, besitzt aber im Vergleich zu diesem einen erweiterten, weniger restriktiven Wertebereich.

collectionID SimpleToken

1..1

Identifikation der Sammlung von Identifikatoren (z.B. Register oder Codeliste), der der angegebene Objekt-Identifikator entstammt.Beispiel: Der Wert “3862” zur Identifikation der Codeliste “Länder”.Anmerkung: Welche Sammlungen von Identifikatoren zulässigerweise identifiziert werden können, hängt vom Kontext ab, in dem der Datentyp verwendet wird.

objectDesignation NormalizedString256

0..1

Text, z.B. Name, der Personen dazu dient, das referenzierte Objekt zu erkennen und von anderen Objekten zu unterscheiden.Beispiel: Sollte etwa jener Eintrag aus der Codeliste 3862 (“Länder”) referenziert werden, der die Identifikation “246” trägt, dann wäre als Objekterkennungstext der aus der Codeliste stammende Name des Landes, “Finnland”, naheliegend.Anmerkung: Aus welchen Sammlungen von Identifikatoren das referenzierte Objekt zulässigerweise stammen kann, hängt vom Kontext ab, in dem der Datentyp verwendet wird.
ShortNameText
Name/Typ min..max Definition

ShortNameText

Token50

1..1

Name.
SimpleToken
Name/Typ min..max Definition

SimpleToken

xs:token

1..1

Wertebereich, zu dem alle aus maximal 64 Zeichen bestehenden Zeichenketten gehören, die ausschließlich aus den Klein- und Großbuchstaben A-Z, den Ziffern 0-9, sowie dem Dash und/oder Underscore-Zeichen bestehen, und die nicht mit dem Dash bzw. Underscore-Zeichen beginnen oder enden. Ausnahme: Die aus 0 Zeichen bestehende Zeichenkette.
String1024
Name/Typ min..max Definition

String1024

xs:string

1..1

Wertebereich, zu dem alle aus maximal 1024 Zeichen bestehenden Zeichenketten gehören. Ausnahme: Die aus 0 Zeichen bestehende Zeichenkette.
Time
Name/Typ min..max Definition

Time

xs:time

1..1

Uhrzeit (Zeitpunkt innerhalb eines Tags).
Token120
Name/Typ min..max Definition

Token120

xs:token

1..1

Wertebereich, zu dem alle Token bestehend aus maximal 120 Zeichen gehören. Ausnahme: Die aus 0 Zeichen bestehende Zeichenkette.Anmerkung: Ein Token ist eine Zeichenkette, die weder Carriage Return (#xD), Line Feed (#xA) noch Tabulator (#x9) Zeichen enthält, die nicht mit Leerzeichen (#x20) beginnt oder endet, und die keine Folge von zwei oder mehr aufeinanderfolgenden Leerzeichen enthält
Token256
Name/Typ min..max Definition

Token256

xs:token

1..1

Wertebereich, zu dem alle Token bestehend aus maximal 256 Zeichen gehören. Ausnahme: Die aus 0 Zeichen bestehende Zeichenkette.Anmerkung: Ein Token ist eine Zeichenkette, die weder Carriage Return (#xD), Line Feed (#xA) noch Tabulator (#x9) Zeichen enthält, die nicht mit Leerzeichen (#x20) beginnt oder endet, und die keine Folge von zwei oder mehr aufeinanderfolgenden Leerzeichen enthält
Token40
Name/Typ min..max Definition

Token40

xs:token

1..1

Wertebereich, zu dem alle Token bestehend aus maximal 40 Zeichen gehören. Ausnahme: Die aus 0 Zeichen bestehende Zeichenkette.Anmerkung: Ein Token ist eine Zeichenkette, die weder Carriage Return (#xD), Line Feed (#xA) noch Tabulator (#x9) Zeichen enthält, die nicht mit Leerzeichen (#x20) beginnt oder endet, und die keine Folge von zwei oder mehr aufeinanderfolgenden Leerzeichen enthält
Token50
Name/Typ min..max Definition

Token50

xs:token

1..1

Wertebereich, zu dem alle Token bestehend aus maximal 50 Zeichen gehören. Ausnahme: Die aus 0 Zeichen bestehende Zeichenkette.Anmerkung: Ein Token ist eine Zeichenkette, die weder Carriage Return (#xD), Line Feed (#xA) noch Tabulator (#x9) Zeichen enthält, die nicht mit Leerzeichen (#x20) beginnt oder endet, und die keine Folge von zwei oder mehr aufeinanderfolgenden Leerzeichen enthält
Token64
Name/Typ min..max Definition

Token64

xs:token

1..1

Wertebereich, zu dem alle Token bestehend aus maximal 64 Zeichen gehören. Ausnahme: Die aus 0 Zeichen bestehende Zeichenkette.Anmerkung: Ein Token ist eine Zeichenkette, die weder Carriage Return (#xD), Line Feed (#xA) noch Tabulator (#x9) Zeichen enthält, die nicht mit Leerzeichen (#x20) beginnt oder endet, und die keine Folge von zwei oder mehr aufeinanderfolgenden Leerzeichen enthält
UUIDIdentifier
Name/Typ min..max Definition

UUIDIdentifier

xs:string

1..1

Universally Unique Identifier (ID, die dem Muster der kanonischen Darstellung von Universally Unique Identifier (UUID) entspricht).

Begleitschein-Webservice

Begleitschein-Webservice Schnittstellenbeschreibung

ValidationResultType

Angaben zu einem Prüfprotokoll.

ValidationResultType
Name/Typ min..max Definition

ValidationTypeID

ReferenceIdentifier

1..1

Art des Prüfprotokolls (Codeliste 9813).

ValidationResultTypeID

ReferenceIdentifier

1..1

Gesamtergebnis der Prüfung (Codeliste 2089):1. Erfolg2. Erfolg, mit Hinweisen3. FehlerWie diese Werte zu interpretieren sind, ist in der Schnittstellenbeschreibung im Abschnitt zu Prüfprotokollen erläutert.

ValidationResultItem

ValidationResultItemType

0..*

Die einzelnen Prüfprotokolleinträge (Informationen zu verletzten Prüfregeln).

ValidationResultType

ValidationResultItemType

Angaben zu einem Prüfprotokolleintrag.

ValidationResultItemType
Name/Typ min..max Definition

SevereViolationIndicator

IndicatorType

1..1

Ja/Nein-Angabe, ob die einzelne Prüfregelverletzung zu einer “Ablehnung” führt (ob aufgrund der Prüfregelverletzung die Daten technisch nicht verarbeitet werden konnten).“Ja” bedeutet, dass eine Ablehnung vorliegt.Insgesamt (für die Gesamtoperation) liegt eine Ablehnung genau dann vor (RejectionIndicator ist auf true), wenn es mindestens einen Ablehnungs-Prüfprotokolleintrag gibt.“Ja” tritt genau bei der Verletzung solcher Prüfregeln auf, die im Prüfregeldokument als zur Ablehnung führend beschrieben sind.

HintIndicator

IndicatorType

1..1

Ja/Nein-Angabe, ob die einzelne Prüfregelverletzung zu einem “Hinweis” führt.“Ja” bedeutet, dass ein Hinweis vorliegt.Für die Gesamtoperation liegt ein “Erfolg mit Hinweisen” genau dann vor, wenn es keinen Ablehnungs-Prüfprotokolleintrag gibt, aber mindestens einen Hinweis-Prüfprotokolleintrag.Anmerkung 1: Ein Prüfprotkolleintrag kann nicht gleichzeitig sowohl Ablehnungs-Eintrag (SevereViolationIndicator auf true) als auch Hinweis-Eintrag (HintIndicator auf true) sein.Anmerkung 2: Auf einen Prüfprotokolleintrag kann zutreffen, dass es sich weder um einen Ablehnungs-, noch um einen Hinweis-Eintrag handelt. Ein solcher Eintrag ändert das Gesamtergebnis der Prüfung nicht. Solche Einträge sind auch bei einem Gesamtergebnis “Erfolg” möglich.

UserDataDependencyIndicator

IndicatorType

1..1

Angabe dazu, ob die Prüfregelverletzung in Zusammenhang mit fachlichen Inhalten (also Inhalten, über die Benutzer Kontrolle haben) steht oder nicht.“Ja” bedeutet, dass ein Zusammenhang mit fachlichen Inhalten besteht.Diese Angabe hilft Clients bei der Handhabung des Prüfprotokolls. Steht der “UserDataDependencyIndicator” auf Nein, liegt jedenfalls ein softwareseitiges, für gewöhnlich nicht durch den Benutzer behebbares Problem vor.Anmerkung: “Nein” liegt für genau solche Prüfregeln vor, die im Prüfregeldokument mit dem Hinweis versehen sind, dass sie in erster Linie die korrekte XML-Repräsentation betreffen.

ViolatedConstraintID

StrictReferenceIdentifierType

1..1

Nummer / Identifikationszeichenkette der verletzten Prüfregel. Es handelt sich um genau jene Nummern, die im Prüfregeldokument zu Prüfregeln mit angegeben sind, z.B. in der Form “(ID 1234)”.Anmerkung: Da dieselbe Prüfregel mehrfach verletzt sein kann (z.B. einmal für die Herkunftsangaben, und einmal für die Verbleibsangaben), kann dieselbe Prüfregel-ID mehrfach im Prüfprotokoll auftreten.

ResultText

DescriptionType

0..1

Beschreibung der Prüfregelverletzung.Anmerkung: Die Beschreibungen werden im EDM so gestaltet, dass sie möglichst allgemeinverständlich und gut nachvollziehbar sind.Allerdings kann naturgemäß nur auf die fachlichen Inhalte und das XML-Format Bezug genommen werden. Unter diesem Vorbehalt kann, sofern es sich um eine Prüfregelverletzung handelt, für die der UserDataDependencyIndicator auf “ja” steht, der ResultText durch die Client-Software an den Benutzer “durchgereicht” werden.Benutzer werden vielfach jedoch auch den Bezug zu Elementen der grafischen Benutzeroberfläche im Client erwarten. Ein solcher Bezug kann nur durch die Client-Software hergestellt werden. Vielfach kann die Client-Software den Benutzer viel besser unterstützen, z.B. durch Verweise auf betreffende Elemente der grafischen Benutzeroberfläche, als durch bloßes “Durchreichen” der Prüfregelverletzungs-Beschreibungen.

ObjectID

OptionalTypeReferenceIdentifierType

0..*

Mit dieser ID kann auf “Objekte” in den übermittelten Dateninhalten verwiesen werden, die in Zusammenhang mit der Prüfregelverletzung stehen, z.B. (nicht-natürliche) Personen oder Standorte.Anmerkung 1: In Datenübermittlungs-Prüfprotokollen können sowohl ObjectID als auch CrossReferenceObjectID-Bezüge enthalten sein. ObjectID wird zur Eingrenzung dessen, auf welchen Teil der übermittelten Dateninstanz sich der Prüfprotokolleintrag bezieht, verwendet. CrossReferenceObjectID-Bezüge werden für sonstige Bezüge verwendet, z.B. auf Stammdateneinträge oder andere bereits übermittelte Meldungen oder Deklarationen. In Begleitschein-Prüfprotokollen können ausschließlich CrossReferenceObjectID-Bezüge enthalten sein, aber keine ObjectID-Bezüge.Anmerkung 2: Im vorliegenden Webservice erfolgen diese Bezugnahmen ausschließlich mit im EDM zugewiesenen (Personen, Standort oder Anlagen) GLNs. Im Attribut collectionID ist deshalb ausschließlich die GTIN 9008390104026 aus der Codeliste 1756 angegeben. Diese GTIN steht für EDM.

CrossReferenceObjectID

OptionalTypeReferenceIdentifierType

0..*

Mit dieser ID kann auf “Objekte” verwiesen werden, die in Zusammenhang mit der Prüfregelverletzung stehen.Anmerkung 1: In Datenübermittlungs-Prüfprotokollen können sowohl ObjectID als auch CrossReferenceObjectID-Bezüge enthalten sein. ObjectID wird zur Eingrenzung dessen, auf welchen Teil der übermittelten Dateninstanz sich der Prüfprotokolleintrag bezieht, verwendet. CrossReferenceObjectID-Bezüge werden für sonstige Bezüge verwendet, z.B. auf Stammdateneinträge oder andere bereits übermittelte Meldungen oder Deklarationen. In Begleitschein-Prüfprotokollen können ausschließlich CrossReferenceObjectID-Bezüge enthalten sein, aber keine ObjectID-Bezüge.Anmerkung 2: Im vorliegenden Webservice wird an dieser Stelle ausschließlich auf bereits zur VEBSV-ID übermittelte Meldungen bzw. Deklarationen Bezug genommen, und zwar mit der vom EDM verwendeten Meldungs-ID (dabei handelt es sich um die für die initiale Übermittlung verwendete Datenübermittlungs-UUID bzw. „Transaction ID“). Im Attribut collectionID ist deshalb ausschließlich die GTIN 9008390104026 aus der Codeliste 1756 angegeben. Diese GTIN steht für EDM.

ReferencedValue

String1024Type

0..1

Handelt es sich bei der Prüfregelverletzung um die “Beanstandung” eines einzelnen Datenwerts, dann kann dieser Wert in “ReferencedValue” mit angegeben werden.Stimmt bei einer übermittelten GLN beispielsweise die Prüfziffer nicht, oder gibt es zu dieser GLN keinen passenden Eintrag im EDM, dann wird in “ReferencedValue” genau diese “beanstandete” GLN zurückgeliefert.Den “beanstandeten Wert” zu kennen, kann dem Benutzer der Client-Software dabei helfen, zu identifizieren, welche Daten welcher Korrektur bedürfen.

ValidationResultItemType

FailureResponseType

Angaben zu einem bei der Abarbeitung eines Operationsaufrufs aufgetretenen Fehler.

FailureResponseType
Name/Typ min..max Definition

FailureID

StrictReferenceIdentifierType

0..1

Eine ID (Identifikationszeichenkette), die auf einen Eintrag aus Codeliste 5156 “Fehlerkategorien” verweist und solcherart den Fehler klassifiziert.Anmerkung 1: Für den Client-Endanwender ist die Fehlerkategorie im Allgemeinen unverständlich. Die Fehlerkategorie hat vielmehr den folgenden Nutzen: (a) Abhängig von der Fehlerkategorie kann die Client-Software unterschiedlich auf den Fehler reagieren, z.B. einen Datenübermittlungsversuch automatisch wiederholen oder nicht; und (b) die Fehlerkatgerie kann für IT-Personal bei Fehlersuche, Tests, Debugging, usw. hilfreich sein.Anmerkung 2: Eine besondere Bedeutung kommt der Fehlerkategorie 203 „Verletzung von Datenanforderungen“ zu. Liegt diese Fehlerkategorie vor, dann wird im FailureResponse auch ein sogenanntes Prüfprotokoll geliefert (siehe ValidationResultItem), welches Aufschluss darüber gibt, durch welche der übermittelten Daten welche Datenanforderungen verletzt sind. Das Prüfprotokoll kann mit jener Datenübermittlungs-ID (transaction ID), die im fehlgeschlagenen Operationsaufruf verwendet wurde, zudem auch separat abgerufen werden, und zwar mit der QueryValidationResult-Operation.

FailureText

DescriptionType

0..1

Eine Beschreibung des Fehlers.Anmerkung: Die Beschreibung des Fehlers kann bei der Fehlersuche durch IT-Personal hilfreich sein. Für den Endanwender ist die Fehlerbeschreibung im Allgemeinen unverständlich. Client-Software sollte diesen Text daher nicht, bzw. nicht ohne entsprechenden Kontext, an Benutzer weitergeben.

ObjectID

ReferenceIdentifier

0..1

Eine ID aus dem Input an die Operation, mit der auf jenen Teil des Inputs verwiesen wird, der ursächlich für den Fehler ist.Anmerkung: Dieses Datenelement wird im vorliegenden Webservice nicht verwendet.

ValidationResultItem

ValidationResultItemType

0..*

Prüfprotokoll, bestehend aus den einzelnen Prüfprotokolleinträgen (Informationen zu einzelnen Verletzungen von Vorgaben).Anmerkung 1: Ein Prüfprotokoll ist im FailureResponse genau dann enthalten, wenn über die FailureID angezeigt wird, dass der Operationsaufruf aufgrund der Verletzung von Datenanforderungen (FailureID 203) fehlgeschlagen ist.Anmerkung 2: Ein im FailureResponse enthaltenes Prüfprotokoll beinhaltet Angaben zu mindestens einer Datenanforderungsverletzung, die zur „Ablehnung“ (zum Fehlschlagen der aufgerufenen Operation) führt. Darüber hinaus kann auch eine beliebige Zahl von „Hinweis-Datenanforderungen“ verletzt sein, d.h. von Datenanforderungen, deren Verletzung nur einen Hinweis liefert, aber nicht zur Ablehnung bzw. zum Operationsabbruch führt. Auch zu allen solchen festgestellten Datenanforderungsverletzungen sind Angaben im Prüfprotokoll enthalten.

FailureResponseType

RequestWasteTransferIDRequest

Input der RequestWasteTransferID-Operation.

RequestWasteTransferIDRequest
Name/Typ min..max Definition

InterfaceVersionID

VersionIdentifierType

0..1

Konstante, die der Konnektor an die Webservice-Operation übergibt, und die angibt, auf welche Version des Webservice der Konnektor ausgelegt ist.

ConnectorVersionID

PredeterminedScopeReferenceIdentifier

1..1

Version des Konnektors, der den Operations-Aufruf durchführt.

TransactionUUID

UUIDIdentifier

1..1

Eine vom Client speziell für den konkreten RequestWasteTransferID-Aufruf generierte UUID (Universally Unique ID).Anmerkung 1: Mit dieser UUID kann in Folge auf den RequestWasteTransferID-Aufruf Bezug genommen werden.Anmerkung 2: Wird eine bereits „verbrauchte“ (d.h. zuvor in einem Operationsaufruf verwendete) UUID angegeben, führt dies zum SOAP-Fault.

RequestWasteTransferIDRequest

RequestWasteTransferIDResponse

Output der RequestWasteTransferID-Operation.

RequestWasteTransferIDResponse
Name/Typ min..max Definition

WasteTransferID

StrictAssignmentIdentifierType

1..1

Die neu ausgestellte Abfall-Übergabe/Übernahme bzw. Beförderungs-ID ("VEBSV-ID"), mit der in Folge zusammengehörige Angaben zu Abfall-Übergaben/Übernahmen und Abfalltransporten miteinander in Verbindung gebracht werden.Anmerkung: Bei der VEBSV-ID handelt es sich um eine Ziffernfolge. Zur besseren Lesbarkeit wird sie in EDM Benutzeroberflächen mit einem Bindestrich zwischen Gruppen von je vier aufeinanderfolgenden Ziffern dargestellt.Diese Art der Formatierung wird auch für andere Benutzeroberflächen bzw. Darstellungen, z.B. PDF-Exporte, empfohlen.

IssueDateTime

[xs:dateTime]

1..1

Der Zeitpunkt der Ausstellung der ID durch das EDM.

RequestWasteTransferIDResponse

RetrieveDocumentRequest

Input der RetrieveDocument-Operation.

RetrieveDocumentRequest
Name/Typ min..max Definition

InterfaceVersionID

VersionIdentifierType

0..1

Konstante, die der Konnektor an die Webservice-Operation übergibt, und die angibt, auf welche Version des Webservice der Konnektor ausgelegt ist.

ConnectorVersionID

PredeterminedScopeReferenceIdentifier

1..1

Version des Konnektors, der den Operations-Aufruf durchführt.

WasteTransferID

StrictReferenceIdentifierType

1..1

Eine Abfall-Übergabe/Übernahme bzw. Beförderungs-ID ("VEBSV-ID"), zu der diejenigen Inhalte, auf die der angemeldete EDM-Benutzer Zugriff hat, abgerufen werden.

RequestEncryptedResponse

IndicatorType

0..1

Wird dieser Ja/Nein-Wert auf Ja (true) gesetzt, dann wird das angefragte Dokument mit dem im VEBSV-System hinterlegten Public-Key des Benutzers verschlüsselt.

RetrieveDocumentRequest

RetrieveDocumentResponse

Output der RetrieveDocument-Operation.

RetrieveDocumentResponse
Name/Typ min..max Definition

ValidationResult

ValidationResultType

0..*

Ergebnisse automatisierter Prüfungen der zur Abfall-Übergabe/Übernahme bzw. Beförderungs-ID ("VEBSV-ID") im EDM vorliegenden Daten („Begleitschein-Prüfprotokolle“).Anmerkung: Datenübermittlungs-Prüfprotokolle sind an dieser Stelle nicht enthalten.

tw:ConsignmentNoteDataInstancetw:ConsignmentNoteDataInstance

0..1

Der Gesamtdatenstand zur VEBSV-ID, bestehend aus Meldungen und Deklarationen sowie dem daraus resultierenden „Begleitschein“.Anmerkung 1: Die zur VEBSV-ID gehörenden Daten werden nicht notwendigerweise vollständig retourniert, sondern nur insoweit, als für den angemeldeten EDM-Benutzer der lesende Zugriff zulässig ist.Anmerkung 2: Soweit in Deklarationen und Meldungen Bezug auf Einträge im EDM-Stammdatenregister genommen wurde (z.B. Bezug auf eine im EDM registrierte Person durch Angabe der GLN, die für die Identifikation der Person im EDM verwendet wird), werden die im EDM-Stammdatenregister zu diesen Einträgen vorliegenden Daten (z.B. Name und Anschrift der Person) zurückgeliefert. Diese können von in Deklarationen oder Meldungen übermittelten Angaben abweichen.

ds:Signatureds:Signature

0..1

Elektronische Signatur zur Meldung, in dem auf dem XMLDSIG-Format basierenden XAdES-Format.

RetrieveDocumentResponse

ShareDocumentRequest

Input der ShareDocument-Operation.

ShareDocumentRequest
Name/Typ min..max Definition

InterfaceVersionID

VersionIdentifierType

0..1

Konstante, die der Konnektor an die Webservice-Operation übergibt, und die angibt, auf welche Version des Webservice der Konnektor ausgelegt ist.

ConnectorVersionID

PredeterminedScopeReferenceIdentifier

1..1

Version des Konnektors, der den Operations-Aufruf durchführt.

AgentPersonName

NameText

0..1

Name der Person (des Client-Benutzers), deren Interaktion mit der Client-Software die Interaktion der Client-Software mit dem Webservice ausgelöst hat.Anmerkung 1: Es handelt sich hierbei um eine "private" Angabe, die ausschließlich für das bei der Webservice-Interaktion authentifizierte Unternehmen mitprotokolliert wird, aber nicht an andere Unternehmen oder Behörden weitergegeben wird.Anmerkung 2: Durch Übermittlung dieser Angabe kann die Nachvollziehbarkeit, wie Webservice-Interaktionen zustandekommen, erhöht werden.Anmerkung 3: Die Angabe des Namens an dieser Stelle ist vor allem für den Fall gedacht, dass die bei der Webservice-Interaktion (per EDM-Benutzername und unter Verwendung des Application Passwords generierten HMAC) authentifizierte Person eine andere Person ist, als diejenige, welche die Webservice-Interaktion unmittelbar ausgelöst hat. Damit kann für diejenigen Personen, die EDM-Benutzername und Application Password in Drittsoftware hinterlegen, nachvollziehbar und kontrollierbar gemacht werden, welche Webservice-Interaktionen in ihrem Namen erfolgen.

AgentTelephoneCommunicationNetworkEndpointID

TelephoneNumberID

0..1

Telefonnummer des Benutzers, dessen Interaktion mit der Client-Software die Interaktion der Client-Software mit dem Webservice ausgelöst hat.Anmerkung 1: Es handelt sich hierbei um eine "private" Angabe, die ausschließlich für das bei der Webservice-Interaktion authentifizierte Unternehmen mitprotokolliert wird, aber nicht an andere Unternehmen oder Behörden weitergegeben wird.Anmerkung 2: Durch Übermittlung dieser Angabe kann die Nachvollziehbarkeit, wie Webservice-Interaktionen zustandekommen, erhöht werden.Anmerkung 3: Die Angabe der Telefonnummer an dieser Stelle ist vor allem für Fälle vorgesehen, in welchen zunächst beim Versand einer Message in der Liste von Empfängern Telefonnummern für SMS-Benachrichtigungen angegeben werden. Erfolgt in Folge von einem dieser Empfänger das Versenden einer Meldung, und spielt dabei das Öffnen einer per SMS erhaltenen URL eine Rolle bei der Identifikation dieses Empfängers, dass sollte beim Versender der Meldung diese Telefonnummer mit angegeben sein.

TransactionUUID

UUIDIdentifier

1..1

Eine vom Client speziell für den konkreten ShareDocument-Aufruf generierte UUID (Universally Unique ID).Anmerkung 1: Mit dieser UUID kann in Folge auf den ShareDocument-Aufruf Bezug genommen werden.Anmerkung 2: Wird eine bereits „verbrauchte“ (d.h. zuvor in einem Operationsaufruf verwendete) UUID angegeben, führt dies zum SOAP-Fault.

DocumentUUID

UUIDIdentifier

0..1

UUID jener Dateninstanz, die korrigiert (aktualisiert) werden soll.Anmerkung 1: Diese ID muss genau dann angegeben sein, wenn die ShareDocument-Operation für die Korrektur bereits übermittelter Daten verwendet wird. Bei der initialen Übermittlung darf diese ID nicht angegeben sein.Anmerkung 2: Es sind an dieser Stelle ausschließlich „Transaction IDs“ zulässig, die in einer vorangehenden ShareDocument-Operation für die erfolgreiche initiale Übermittlung von Daten verwendet wurden, und so zur Dateninstanz-ID im EDM wurden.

ChangeReasonID

ReferenceIdentifier

0..1

Auswahl des Grunds für die Korrektur bei Verwendung der Operation für die Korrektur einer zuvor erfolgten Übermittlung (Codeliste 7521).Anmerkung: Wird die ShareDocumentRequest-Operation NICHT für eine Korrektur verwendet (d.h. für eine initiale Übermittlung verwendet), DARF das Element ChangeReasonID NICHT angegeben sein. Wird die Operation für eine Korrektur verwendet, MUSS das Element hingegen angegeben sein.

Description

DescriptionType

0..1

Beschreibung bzw. Begründung einer Korrektur.Anmerkung 1: Wird die ShareDocumentRequest-Operation NICHT für eine Korrektur verwendet, DARF das Element Description nicht angegeben sein.Anmerkung 2: Wird die ShareDocument-Operation für eine Korrektur verwendet, dann erfolgt die Beschreibung bzw. Begründung der Korrektur ergänzend zur Auswahl des Korrekturgrunds in ChangeReasonID.Anmerkung 3: Im Gegensatz zur Auswahl des Korrekturgrunds in ChangeReasonID ist nicht für alle Korrekturen zwingend eine Beschreibung bzw. Begründung einer Korrektur in Description erforderlich.

tw:EnvironmentalDataInstancetw:EnvironmentalDataInstance

1..1

Die übermittelten Inhalte, z.B. Transportdeklaration, Übergabemeldung oder Übernahmemeldung, inklusive Metadaten z.B. zur Erstellung der Dateninstanz.

OmitConsignmentNoteIndicator

IndicatorType

0..1

(zurzeit nicht umgesetzt) Ja/Nein-Angabe dazu, ob im Output des ShareDocument-Aufrufs die Begleitschein-Angaben ENTFALLEN sollen (ja = Angaben sollen entfallen).Anmerkung 1: Bei fehlender OmitConsignmentNoteIndicator-Angabe sind die Begleitschein-Angaben im ShareDocument-Output enthalten.Anmerkung 2: OmitConsignmentNoteIndicator kann beispielsweise dann auf ja (true) gesetzt werden, wenn mehrere ShareDocument-Aufrufe zum selben Begleitschein innerhalb einer kurzen Zeitspanne erfolgen, und nur nach dem letzten dieser Aufrufe der aktualisierte Begleitschein vom Client verarbeitet wird.Anmerkung 3: Bei Entfall der Begleitschein-Angaben entfallen im ShareDocument-Output auch die „Begleitschein-Prüfprotokolle“. Die „Datenübermittlungs-Prüfprotokolle“ sind hingegen auch in diesem Fall im Output enthalten.

RequestEncryptedResponse

IndicatorType

0..1

Wird dieser Ja/Nein-Wert auf Ja (true) gesetzt, dann wird das angefragte Dokument mit dem im VEBSV-System hinterlegten Public-Key des Benutzers verschlüsselt.

ds:Signatureds:Signature

0..1

Elektronische Signatur zur Meldung, in dem auf dem XMLDSIG-Format basierenden XAdES-Format.

ShareDocumentRequest

ShareDocumentResponse

Output der ShareDocument-Operation.

ShareDocumentResponse
Name/Typ min..max Definition

ConstraintComplianceIndicator

IndicatorType

1..1

Ein Ja/Nein-Wert dazu, ob bei der technischen Validierung die Einhaltung von Datenanforderungen festgestellt wurde. Mit diesem Wert wird lediglich die Einhaltung solcher Datenanforderungen angezeigt, die nicht zu einer automatischen Zurückweisung führen.Anmerkung: Im ShareDocument-Output ist – im Gegensatz zum QueryTransactionStatus-Output – kein “TechnicalAcceptanceIndicator” enthalten. Das liegt daran, dass in der “ShareDocument”-Operation eine automatische Zurückweisung jedenfalls per SOAP-Fault rückgemeldet wird. Bei Erhalt eines regulären ShareDocument-Response liegt also jedenfalls keine technische Zurückweisung vor.

ValidationResult

ValidationResultType

1..*

Prüfprotokoll zur initialen Datenübermittlung bzw. zur Datenkorrektur, sowie „Begleitschein-Prüfprotokolle“ zur Gesamtheit der zur betreffenden VEBSV-ID übermittelten Daten unter Berücksichtigung der mit dem ShareDocument-Aufruf neu übermittelten bzw. korrigierten Daten.Anmerkung: Mit dem Request-Parameter OmitConsignmentNoteIndicator kann die Rückgabe der „Begleitschein-Prüfprotokolle“ unterdrückt werden.

tw:ConsignmentNoteDataInstancetw:ConsignmentNoteDataInstance

0..1

Der Gesamtdatenstand zur VEBSV-ID, bestehend aus Meldungen und Deklarationen sowie dem daraus resultierenden „Begleitschein“, soweit auf die Angaben durch den ShareDocument-Aufrufer Zugriff besteht.Anmerkung: Mit dem Request-Parameter OmitConsignmentNoteIndicator kann die Rückgabe dieser Daten unterdrückt werden.

ds:Signatureds:Signature

0..1

Elektronische Signatur zur Meldung, in dem auf dem XMLDSIG-Format basierenden XAdES-Format.

ShareDocumentResponse

CancelDocumentRequest

Input der CancelDocument-Operation.

CancelDocumentRequest
Name/Typ min..max Definition

InterfaceVersionID

VersionIdentifierType

0..1

Konstante, die der Konnektor an die Webservice-Operation übergibt, und die angibt, auf welche Version des Webservice der Konnektor ausgelegt ist.

ConnectorVersionID

PredeterminedScopeReferenceIdentifier

1..1

Version des Konnektors, der den Operations-Aufruf durchführt.

AgentPersonName

NameText

0..1

Name der Person (des Client-Benutzers), deren Interaktion mit der Client-Software die Interaktion der Client-Software mit dem Webservice ausgelöst hat.Anmerkung 1: Es handelt sich hierbei um eine "private" Angabe, die ausschließlich für das bei der Webservice-Interaktion authentifizierte Unternehmen mitprotokolliert wird, aber nicht an andere Unternehmen oder Behörden weitergegeben wird.Anmerkung 2: Durch Übermittlung dieser Angabe kann die Nachvollziehbarkeit, wie Webservice-Interaktionen zustandekommen, erhöht werden.Anmerkung 3: Die Angabe des Namens an dieser Stelle ist vor allem für den Fall gedacht, dass die bei der Webservice-Interaktion (per EDM-Benutzername und unter Verwendung des Application Passwords generierten HMAC) authentifizierte Person eine andere Person ist, als diejenige, welche die Webservice-Interaktion unmittelbar ausgelöst hat. Damit kann für diejenigen Personen, die EDM-Benutzername und Application Password in Drittsoftware hinterlegen, nachvollziehbar und kontrollierbar gemacht werden, welche Webservice-Interaktionen in ihrem Namen erfolgen.

AgentTelephoneCommunicationNetworkEndpointID

TelephoneNumberID

0..1

Telefonnummer des Benutzers, dessen Interaktion mit der Client-Software die Interaktion der Client-Software mit dem Webservice ausgelöst hat.Anmerkung 1: Es handelt sich hierbei um eine "private" Angabe, die ausschließlich für das bei der Webservice-Interaktion authentifizierte Unternehmen mitprotokolliert wird, aber nicht an andere Unternehmen oder Behörden weitergegeben wird.Anmerkung 2: Durch Übermittlung dieser Angabe kann die Nachvollziehbarkeit, wie Webservice-Interaktionen zustandekommen, erhöht werden.Anmerkung 3: Die Angabe der Telefonnummer an dieser Stelle ist vor allem für Fälle vorgesehen, in welchen zunächst beim Versand einer Message in der Liste von Empfängern Telefonnummern für SMS-Benachrichtigungen angegeben werden. Erfolgt in Folge von einem dieser Empfänger das Versenden einer Meldung, und spielt dabei das Öffnen einer per SMS erhaltenen URL eine Rolle bei der Identifikation dieses Empfängers, dass sollte beim Versender der Meldung diese Telefonnummer mit angegeben sein.

TransactionUUID

UUIDIdentifier

1..1

Eine vom Client speziell für den konkreten CancelDocument-Aufruf generierte UUID (Universally Unique ID).Anmerkung 1: Mit dieser UUID kann in Folge auf den CancelDocument-Aufruf Bezug genommen werden.Anmerkung 2: Wird eine bereits „verbrauchte“ (d.h. zuvor in einem Operationsaufruf verwendete) UUID angegeben, führt dies zum SOAP-Fault.

DocumentUUID

UUIDIdentifier

1..1

Die UUID der zu stornierenden Dateninstanz.Anmerkung: Es sind an dieser Stelle nur „Transaction IDs“ zulässig, die für die erfolgreiche initiale Übermittlung von Daten verwendet wurden (ShareDocument-Operation), und so zur Meldungs-ID im EDM wurden.

ChangeReasonID

ReferenceIdentifier

1..1

Auswahl des Grunds für das Widderrufen einer zuvor erfolgten Übermittlung (Codeliste 7521).

Description

DescriptionType

0..1

Beschreibung bzw. Begründung des Widerrufens.Anmerkung 1: Die Beschreibung bzw. Begründung des Widerrufens erfolgt ergänzend zur Auswahl des Widerrufungsgrunds in ChangeReasonID.Anmerkung 2: Im Gegensatz zur Auswahl des Widerrufungsgrunds in ChangeReasonID ist nicht für alle Widerrufungen zwingend eine Beschreibung bzw. Begründung in Description erforderlich.

OmitConsignmentNoteIndicator

IndicatorType

0..1

(zurzeit nicht umgesetzt) Ja/Nein-Angabe dazu, ob im Output des CancelDocument-Aufrufs die Begleitschein-Angaben ENTFALLEN sollen (ja = Angaben sollen entfallen).Anmerkung 1: Bei fehlender OmitConsignmentNoteIndicator-Angabe sind die Begleitschein-Angaben im CancelDocument-Output enthalten.Anmerkung 2: OmitConsignmentNoteIndicator kann beispielsweise dann auf ja (true) gesetzt werden, wenn mehrere CancelDocument-Aufrufe zum selben Begleitschein innerhalb einer kurzen Zeitspanne erfolgen, und nur nach dem letzten dieser Aufrufe der aktualisierte Begleitschein vom Client verarbeitet wird.Anmerkung 3: Bei Entfall der Begleitschein-Angaben entfallen im CancelDocument-Output auch die „Begleitschein-Prüfprotokolle“. Die „Datenübermittlungs-Prüfprotokolle“ sind hingegen auch in diesem Fall im Output enthalten.

RequestEncryptedResponse

IndicatorType

0..1

Wird dieser Ja/Nein-Wert auf Ja (true) gesetzt, dann wird das angefragte Dokument mit dem im VEBSV-System hinterlegten Public-Key des Benutzers verschlüsselt.

CancelDocumentRequest

CancelDocumentResponse

Output der CancelDocument-Operation.

CancelDocumentResponse
Name/Typ min..max Definition

ConstraintComplianceIndicator

IndicatorType

1..1

Ein Ja/Nein-Wert dazu, ob bei der technischen Validierung der Stornierung die Einhaltung von Datenanforderungen festgestellt wurde. Mit diesem Wert wird lediglich die Einhaltung solcher Datenanforderungen angezeigt, die nicht zu einer automatischen Zurückweisung führen.Anmerkung: Im CancelDocument-Output ist – im Gegensatz zum QueryTransactionStatus-Output – kein “TechnicalAcceptanceIndicator” enthalten. Das liegt daran, dass in der “CancelDocument”-Operation eine automatische Zurückweisung jedenfalls per SOAP-Fault rückgemeldet wird. Bei Erhalt eines regulären CancelDocument-Response liegt also jedenfalls keine technische Zurückweisung vor, d.h. die Stornierung konnte durchgeführt werden.

ValidationResult

ValidationResultType

1..*

Prüfprotokoll zur Stornierung, sowie „Begleitschein-Prüfprotokolle“ zur Gesamtheit der zur betreffenden VEBSV-ID übermittelten Daten unter Berücksichtigung der mit dem CancelDocument-Aufruf stornierten Daten.Anmerkung: Mit dem Request-Parameter OmitConsignmentNoteIndicator kann die Rückgabe der „Begleitschein-Prüfprotokolle“ unterdrückt werden.

tw:ConsignmentNoteDataInstancetw:ConsignmentNoteDataInstance

0..1

Der Gesamtdatenstand zur VEBSV-ID, bestehend aus Meldungen und Deklarationen sowie dem daraus resultierenden „Begleitschein“, soweit auf die Angaben durch den CancelDocument-Aufrufer Zugriff besteht.Anmerkung 1: In Folge der Stornierung kann (muss aber nicht) der Zugriff auf sämtliche zur VEBSV-ID übermittelte Daten wegfallen.Anmerkung 2: Mit dem Request-Parameter OmitConsignmentNoteIndicator kann die Rückgabe dieser Daten unterdrückt werden.

ds:Signatureds:Signature

0..1

Elektronische Signatur zur Meldung, in dem auf dem XMLDSIG-Format basierenden XAdES-Format.

CancelDocumentResponse

QueryTransactionStatusRequest

Input der QueryTransactionStatus-Operation.

QueryTransactionStatusRequest
Name/Typ min..max Definition

InterfaceVersionID

VersionIdentifierType

0..1

Konstante, die der Konnektor an die Webservice-Operation übergibt, und die angibt, auf welche Version des Webservice der Konnektor ausgelegt ist.

ConnectorVersionID

PredeterminedScopeReferenceIdentifier

1..1

Version des Konnektors, der den Operations-Aufruf durchführt.

ReferredTransactionUUID

UUIDIdentifier

1..1

Die Transaction UUID, die in jenem Datenübermittlungs-, Datenkorrektur- bzw. Datenstornierungs-Aufruf verwendet wurde, zu dem der Verarbeitungsstatus abgerufen wird.

QueryTransactionStatusRequest

QueryTransactionStatusResponse

Output der QueryTransactionStatus-Operation.

QueryTransactionStatusResponse
Name/Typ min..max Definition

ProcessingCompletionIndicator

IndicatorType

1..1

Ein Ja/Nein-Wert dazu, ob die Verarbeitung des Operationsaufrufs (erfolgreich oder nicht erfolgreich) abgeschlossen ist.Anmerkung: Da die Operationen im vorliegenden Webservice allesamt „synchron“ arbeiten, ist die Verarbeitung bei Erhalt des Response jedenfalls abgeschlossen.

TechnicalAcceptanceIndicator

IndicatorType

0..1

Ein Ja/Nein-Wert dazu, ob der Operationsaufruf erfolgreich verarbeitet werden konnten. “False” zeigt eine automatische technische Zurückweisung an.Anmerkung 1: Im Fall einer technischen Zurückweisung bleibt – abgesehen von Einträgen in technischen Logs und dergleichen – der Server-seitige Status unverändert. Insbesondere besteht bei einem nicht erfolgreichen Aufruf der ShareDocument-Operation zur inititialen Datenübermittlung für Empfänger kein Zugriff auf die übermittelten Inhalte. Ebensowenig erlangen Empfänger Kenntnis über den „Zustellversuch“.Anmerkung 2: Der “TechnicalAcceptanceIndicator” ist nur dann gesetzt, wenn die technische Verarbeitung abgeschlossen ist, d.h. wenn im “ProcessingCompletionIndicator” der Wert “true” zurückgeliefert wird.

ConstraintComplianceIndicator

IndicatorType

0..1

Ein Ja/Nein-Wert dazu, ob bei der technischen Validierung die Einhaltung von Datenanforderungen festgestellt wurde. Mit diesem Wert wird lediglich die Einhaltung solcher Datenanforderungen angezeigt, die nicht zu einer automatischen Zurückweisung führen.Anmerkung 1: Der “ConstraintComplianceIndicator” ist nur dann gesetzt, wenn im “TechnicalAcceptanceIndicator” der Wert “true” zurückgeliefert wird.Anmerkung 2: Ein von der QueryTransactionStatus-Operation zurückgeliefertes Ergebnis mit den Werten ProcessingCompletionIndicator=true, TechnicalAcceptanceIndicator=true und ConstraintComplianceIndicator=false ist so zu verstehen, dass die Operation technisch erfolgreich verarbeitet wurde (z.B. übergebene Dateninstanzen erfolgreich für den oder die Empfänger entgegengenommen wurden), zugleich jedoch auch Hinweise auf potentielle Fehler vorliegen (z.B. unplausible oder inkonsistente Inhalte in übermittelten Daten, Fristversäumnisse, usw.).

QueryTransactionStatusResponse

QueryValidationResultRequest

Input der QueryValidationResult-Operation.

QueryValidationResultRequest
Name/Typ min..max Definition

InterfaceVersionID

VersionIdentifierType

0..1

Konstante, die der Konnektor an die Webservice-Operation übergibt, und die angibt, auf welche Version des Webservice der Konnektor ausgelegt ist.

ConnectorVersionID

PredeterminedScopeReferenceIdentifier

1..1

Version des Konnektors, der den Operations-Aufruf durchführt.

ReferredTransactionUUID

UUIDIdentifier

1..1

Die Transaction UUID, die in jenem Datenübermittlungs-, Datenkorrektur- bzw. Datenstornierungs-Aufruf verwendet wurde, zu dem ein Prüfprotokoll abgerufen wird.

QueryValidationResultRequest

QueryValidationResultResponse

Output der QueryValidationResult-Operation.

QueryValidationResultResponse
Name/Typ min..max Definition

ValidationResultItem

ValidationResultItemType

0..*

Einzelne Prüfprotokolleinträge (Informationen zu verletzten Prüfregeln).

QueryValidationResultResponse

Datentypen

DescriptionType
DescriptionType
Name/Typ min..max Definition

DescriptionType

[twt:String1024Typetwt:String1024Type]

1..1

Beschreibungstext, zusammen mit einem Attribut, welches die Sprache angibt.

languageID tw:SimpleToken

1..1

Sprache, in welcher der Beschreibungstext verfasst ist (Codeliste 7632).
IndicatorType
Name/Typ min..max Definition

IndicatorType

xs:boolean

1..1

Ja/Nein-Wert (Ja: Eigenschaft trifft zu; Nein: Eigenschaft trifft nicht zu).
NameText
Name/Typ min..max Definition

NameText

xs:normalizedString

1..1

Name.
OptionalTypeReferenceIdentifierType
OptionalTypeReferenceIdentifierType
Name/Typ min..max Definition

OptionalTypeReferenceIdentifierType

[tw:ReferenceIdentifiertw:ReferenceIdentifier]

1..1

Referenzierung eines Objekts durch Angabe eines dem Objekt zugeordneten Identifikators. Zusätzlich zum Objekt-Identifikator wird die Identifikation der Sammlung von Identifikatoren (z.B. Register oder Codeliste, etwa Abfallverzeichnis) angegeben, der der Identifikator entstammt.

objectTypeName twt:ShortNameTextType

0..1

Bezeichnung der Objektart.
ShortNameTextType
Name/Typ min..max Definition

ShortNameTextType

twt:Token50Type

1..1

Kurzname
StrictAssignmentIdentifierType
Name/Typ min..max Definition

StrictAssignmentIdentifierType

twt:StrictToken64Type

1..1

Einem Objekt zugeordneter, in einem bestimmten Kontext eindeutiger, und somit in diesem Kontext für die Objektidentifikation geeigneter Wert.
StrictReferenceIdentifierType
Name/Typ min..max Definition

StrictReferenceIdentifierType

twt:StrictToken64Type

1..1

Referenzierung eines Objekts durch Angabe eines dem Objekt zugeordneten Identifikators.Anmerkung: Der Identifikator hat einen einfachen Aufbau zu besitzen. Insbesondere hat er keine anderen Zeichen zu enthalten als Großbuchstaben, Kleinbuchstaben, Ziffern, Bindestrich und Unterstrich. Zudem haben Bindestrich und Unterstrich weder zu Beginn noch zu Ende der Zeichenkette aufzutreten.
StrictToken64Type
Name/Typ min..max Definition

StrictToken64Type

xs:token

1..1

Zeichenkette, die aus maximal 64 und aus mindestens 1 Zeichen besteht, und die aus keinen anderen Zeichen besteht als Großbuchstaben, Kleinbuchstaben, Ziffern, Bindestrich und Unterstrich, wobei Bindestrich und Unterstrich weder zu Beginn noch zu Ende der Zeichenkette auftreten.
String1024Type
Name/Typ min..max Definition

String1024Type

xs:string

1..1

Zeichenkette, die aus maximal 1024 und aus mindestens 1 Zeichen besteht.
TelephoneNumberID
Name/Typ min..max Definition

TelephoneNumberID

xs:string

1..1

Zeichenkette, die einem "strengen" Muster für Telefonnummern entspricht, insbesondere keinerlei Trennzeichen enthält.
Token50Type
Name/Typ min..max Definition

Token50Type

xs:token

1..1

Zeichenkette, die aus maximal 50 und aus mindestens 1 Zeichen besteht, und die weder Carriage Return (#xD), Line Feed (#xA) noch Tabulatur (#x9) enthält, nicht mit einem Leerzeichen beginnt oder endet, und nicht zwei oder mehr unmittelbar aufeinander folgende Leerzeichen enthält.
UUIDIdentifier
Name/Typ min..max Definition

UUIDIdentifier

xs:string

1..1

Universally Unique Identifier (ID, die dem Muster der kanonischen Darstellung von Universally Unique Identifier (UUID) entspricht).
VersionIdentifierType
Name/Typ min..max Definition

VersionIdentifierType

xs:token

1..1

Versionsangabe.Die Versionsangabe besteht aus maximal 64 Zeichen. Sie besteht aus den folgenden Teilen: "Major Version"-Angabe, gefolgt von einem Punkt (#x2E), gefolgt von der "Minor Version"-Angabe. Sowohl "Major Version" als auch "Minor Version" bestehen ausschließlich aus Ziffern. "Minor Version" besteht aus genau 2 Ziffern.

Begleitschein-Webservice: Definitionen von Meldungen

ConsignmentNoteDataEnvelopeOrCollection

Ein “Umschlag” der folgendes beinhalten kann:1. Meldungen/Deklarationen zu Transporten bzw. Übergaben/Übernahmen von gefährlichen Abfällen bzw. POP-Abfällen;2. “Begleitscheine” (die sich bei VEBSV 2.0 aus Inhalten von Meldungen/Deklarationen zusammensetzen).

ConsignmentNoteDataEnvelopeOrCollection
Name/Typ min..max Definition

EnvironmentalDataEnvelope

ConsignmentNoteEnvelope

1..1

Ein “Umschlag” der folgendes beinhalten kann:1. Meldungen/Deklarationen zu Transporten bzw. Übergaben/Übernahmen von gefährlichen Abfällen;2. “Begleitscheine” (die sich bei VEBSV 2.0 aus Inhalten von Meldungen/Deklarationen zusammensetzen).Anmerkung 1: Ein “Umschlag” zeichnet sich allgemein durch folgendes aus:(a) Die Inhalte stammen alle von ein- und demselben Datenbereitsteller;(b) Die Inhalte werden bzw. wurden vom Datenbereitsteller als ein einziges Gesamtdatenpaket bereitgestellt (also insbesondere auch zu einem einzigen Zeitpunkt, und nicht zu mehreren verschiedenen Zeitpunkten).Anmerkung 2: Im vorliegenden Webservice werden zusammengehörige Meldungen/Deklarationen und der sich daraus ergebende “Begleitschein” in einem gemeinsamen “Umschlag” im Response von Operationen wie RetrieveDocument und StoreDocument geliefert. Die originalen “Umschläge”, in welchen die einzelnen Meldungen und Deklarationen übermittelt wurden, werden hingegen nicht zurückgeliefert. Im vorliegenden Webservice befindet sich in jedem Request und Response daher immer nur höchstens ein “Umschlag”.

ConsignmentNoteDataEnvelopeOrCollection

EnvironmentalDataEnvelopeOrCollection

Ein “Umschlag” mit einer Meldung oder Deklaration zum Transport bzw. der Übergabe/Übernahme von gefährlichen Abfällen bzw. POP-Abfällen.

EnvironmentalDataEnvelopeOrCollection
Name/Typ min..max Definition

EnvironmentalDataEnvelope

EnvironmentalDataEnvelope

1..1

Ein “Umschlag” mit einer Meldung und/oder Deklaration zum Transport bzw. der Übergabe/Übernahme von gefährlichen Abfällen.Anmerkung: Ein “Umschlag” zeichnet sich allgemein durch folgendes aus:(a) Die Inhalte stammen alle von ein- und demselben Datenbereitsteller;(b) Die Inhalte werden bzw. wurden vom Datenbereitsteller als ein einziges Gesamtdatenpaket bereitgestellt (also insbesondere auch zu einem einzigen Zeitpunkt, und nicht zu mehreren verschiedenen Zeitpunkten).

EnvironmentalDataEnvelopeOrCollection

Address

Angaben zu einer Adresse.

Address
Name/Typ min..max Definition

Component

AddressComponent

0..*

Adresskomponenten, z.B. Straße, Postleitzahl, und dergleichen. Es sollen genau die für die Zielangabe benötigten Adresskomponenten angegeben sein. Weder sollen benötigte Adresskomponenten fehlen - z.B. werden Angaben zu Örtlichkeit und Postleitzahl fast immer benötigt - noch soll eine Ergänzung um nicht benötigte Angaben erfolgen.

Address

AddressComponent

Angaben zu einer Adresskomponente, z.B. Straße oder Postleitzahl. Zu einer Adresskomponente wird entweder eine Identifikation (RepresentationID, z.B. Hausnummer), oder ein Auszeichnungstext (z.B. RepresentationDesignation, z.B. Straßenname) angegeben.

AddressComponent
Name/Typ min..max Definition

TypeID

ReferenceIdentifier

1..1

Identifikation des Adresskomponententyps, z.B. Straße oder Ort (Codeliste 6856).

ID

ReferenceIdentifier

0..1

Identifikation einer Adresskomponente des angegebenen Typs, z.B. ISO-Code “040” zur Identifikation des Landes Österreich (Codeliste 3862).Anmerkung 1: Ausschließlich für Identifikationszeichenketten vorgesehen, die NICHT als Teil von korrekten Adressrepräsentationen, etwa Anschriften auf Briefen, aufscheinen. Postleitzahlen, Hausnummern oder Türnummern hingegen, die sehr wohl in der jeweiligen korrekten Adressrepräsentationen aufscheinen, werden unter “RepresentationID” angegeben.Anmerkung 2: Im vorliegenden Datenformat ausschließlich für die Identifikation des Landes (in Kombination mit Adresskomponente “Land”, GTIN 9008390104682) vorgesehen.

RepresentationID

PredeterminedScopeReferenceIdentifier

0..1

Identifikation der Adresskomponente des angegebenen Typs, z.B. “6714” in Zusammenhang mit Typ “Postgebiet (Postleitzahl)”.Anmerkung 1: “RepresentationID”-Angaben werden genau für die Adresskomponenten “Postgebiet (Postleitzahl)”, “Haus (Hausnummer)” und “Raumeingang (Türnummer)” erwartet. Für die anderen Adresskomponenten werden hingegen Angaben in “RepresentationDesignation” erwartet.Anmerkung 2: Ausschließlich für Identifikationszeichenketten vorgesehen, die als Teil von korrekten Adressrepräsentationen, etwa Anschriften auf Briefen, aufscheinen, z.B. Postleitzahlen, Hausnummern oder Türnummern. Andere Identifikationen von Adresskomponenten, solche die nicht als Teil von korrekten Adressrepräsentationen aufscheinen, z.B. ISO-Ländercodes (etwa “040” für “Österreich”), werden unter “ID” angegeben.

RepresentationDesignation

AddressComponentDesignation

0..1

Bezeichnung der Adresskomponente, z.B. für eine Adresskomponente vom Typ “Straße” der Straßenname, etwa “Wiedner Hauptstraße”.Anmerkung 1: “RepresentationDesignation”-Angaben werden genau für die Adresskomponenten “Land”, “Ort” und “Straße” erwartet. Für die anderen Adresskomponenten werden hingegen Angaben in “RepresentationID” erwartet.

AddressComponent

AssignmentMultiPartIdentifier

Mehrteiliger Identifikator.Anmerkung 1: Wird im vorliegenden Datenformat ausschließlich für die Identifikation österreichischer Grundstücke verwendet.Anmerkung 2: Die österreichischen Vermessungsämter sind mit der Führung des sogenannten Katasters beauftragt. Dabei handelt es sich - vereinfacht gesagt - um das Register der österreichischen Grundstücke. Der Kataster ist so strukturiert, dass jedem Grundstück eine Nummer zugewiesen ist, die sogenannte Grundstücksnummer, die innerhalb der Menge aller zu einer bestimmten Katastralgemeinde gehörenden Grundstücke eindeutig ist. Mit anderen Worten: Die Grundstücksnummer identifiziert ein Grundstück innerhalb einer Katastralgemeinde. Den Katastralgemeinden sind ebenfalls Nummern zugeordnet, die sogenannten Katastralgemeindenummern, die österreichweit eindeutig sind. Mit anderen Worten: Die Katastralgemeindenummer identifiziert eine Katastralgemeinde in Österreich. Dieser Systematik entsprechend ist die österreichweit eindeutige Identifikation eines Grundstücks mehrteilig (zweiteilig), und setzt sich aus Katastralgemeindenummer und Grundstücksnummer zusammen. Die Angabe einer österreichweit eindeutigen Identifikation eines Grundstücks erfolgt daher unter Verwendung von zwei “PartIdentifier”-Elementen, das erste für die Katastralgemeindenummer, und das zweite für die Grundstücksnummer.

AssignmentMultiPartIdentifier
Name/Typ min..max Definition

PartIdentifier

Token64

2..2

Katastralgemeindenummer und Grundstücksnummer (in dieser Reihenfolge).

AssignmentMultiPartIdentifier

ConsignmentNote

“Begleitschein”.

ConsignmentNote
Name/Typ min..max Definition

Document

ConsignmentNoteDocument

0..1

Allgemeine Angaben zum “Begleitschein”, z.B. VEBSV-ID.

EnvironmentalData

ConsignmentNoteData

0..1

“Begleitschein”-Inhalte, z.B. Angaben zur Übergabe, Übernahme, und bei Streckengeschäften zu weiteren Abfallsammlern.

ConsignmentNote

ConsignmentNoteData

“Begleitschein”-Inhalte, z.B. Angaben zur Übergabe, Übernahme, und bei Streckengeschäften zu weiteren Abfallsammlern.

ConsignmentNoteData
Name/Typ min..max Definition

TransportStartDate

Date

0..1

Datum des Transportbeginns.Anmerkung: Bei Abfall-Übergaben/Übernahmen ohne Transport entfällt das Transportbeginndatum.

TransportStartDateTime

DateTime

0..1

Zeitpunkt des Transportbeginns.Anmerkung: Bei Abfall-Übergaben/Übernahmen ohne Transport entfallen Transportbeginndatum bzw. Transportbeginnzeitpunkt.

InternalTransportIndicator

Indicator

0..1

Ja/Nein-Wert, der angibt, ob es sich sich um einen Begleitschein zu einer innerbetrieblichen Abfallbewegung handelt.

HandOverEvent

ConsignmentNoteHandOverEvent

0..*

Angaben zur Abfallübergabe.Anmerkung: Diese Angaben beziehen sich auf eine oder mehrere “physische” Übergaben, aber nicht auf Übergaben aus einem Streckengeschäft. Wenn ein Streckengeschäft vorliegt, finden sich unter IntermediateTransferEvent Angaben zu den sogenannten “weiteren Abfallsammlern” (Abfallsammlern, die ein Streckengeschäft durchführen).

TakeOverEvent

ConsignmentNoteTakeOverEvent

0..*

Angaben zur Abfallübernahme.Anmerkung 1: Diese Angaben beziehen sich auf eine “physische” Übernahme, aber nicht auf Übernahmen in ein Streckengeschäft. Wenn ein Streckengeschäft vorliegt, finden sich unter IntermediateTransferEvent Angaben zu den sogenannten “weiteren Abfallsammlern” (Abfallsammlern, die ein Streckengeschäft durchführen).Anmerkung 2: Wurden Meldungen mit konsistenten Angaben übermittelt, dann enthält der resultierende Begleitschein Angaben zu genau EINER Abfallübernahme. Inkonsistente Meldungen können jedoch dazu führen, dass im Begleitschein mehrere Übernahmen aufscheinen.

IntermediateTransferEvent

ConsignmentNoteTransferEvent

0..*

Angaben zur Abfall-Übergabe/Übernahme durch “weitere Abfallsammler” (Abfallsammler, die ein Streckengeschäft durchführen).Anmerkung 1: In der Zusammenstellung von Meldungen zu einem “Begleitschein” eruiert EDM nach definierten Regeln die Reihenfolge, in der die Abfall-Übergabe/Übernahme vom Übergeber über allfällige “weitere Abfallsammler” zum Übernehmer erfolgt ist. Die Reihenfolge der IntermediateTransferEvent-Instanzen im “Begleitschein” gibt diese fachliche Reihenfolge wieder.Anmerkung 2: Bei unvollständigen oder inkonsistenten Daten kann die in der vorigen Anmerkung beschriebene Reihenfolge nicht immer eindeutig bestimmt werden, und sich somit bei Vervollständigung oder Korrektur von Meldungen noch ändern.

TransportEvent

ConsignmentNoteTransportEvent

0..*

Angaben zu Transporteuren und den von ihnen durchgeführten Abfalltransporten.

TransportStartEvent

ConsignmentNoteTransportStartEvent

0..*

Abfalltransportbeginnmeldungen.

TransportAbortEvent

ConsignmentNoteTransportAbortEvent

0..*

Transportabbruchmeldungen.

DeclaredWasteObject

ConsignmentNoteWasteObject

0..*

Angaben zum deklarierten Abfall. Anmerkung: Es handelt sich hierbei für gewöhnlich um die Angabe EINER Abfallart und der dazugehörigen Abfallmasse. In bestimmten Fällen, z.B. bei Sammeltouren oder fehlerhaften Meldungen können zu einem Begleitschein aber auch MEHRERE deklarierte Abfallmengen bzw. Abfallarten gehören.

ReceivedWasteObject

ConsignmentNoteWasteObject

0..*

Gemäß den Angaben des Übernehmers tatsächlich übernommener Abfall. Anmerkung 1: Es handelt sich hierbei für gewöhnlich um die Angabe EINER Abfallart und der dazugehörigen Abfallmasse. In bestimmten Ausnahmefällen, insbesondere dann, wenn ein Übernehmer feststellt, dass die gesamte übernommene Abfallmenge aus mehreren Teilmengen besteht, die unterschiedlichen Abfallarten zuzuordnen sind, können zu einem Begleitschein aber auch MEHRERE übernommene Abfallarten gehören. Anmerkung 2: Die Angaben zum tatsächlich übernommenen Abfall sind auch dann in der Dateninstanz vorhanden, wenn sie mit den Angaben zum deklarierten Abfall übereinstimmen. Die Darstellung eines Begleitscheins in der EDM Benutzeroberfläche ist im Unterschied dazu reduzierter: In der Benutzeroberfläche gibt es die deklarierte Abfallart, und “Korrekturzeilen”, die nur dann befüllt sind, wenn es Abweichungen zwischen deklariertem und tatsächlich übernommenem Abfall gibt.

RejectedWasteObject

ConsignmentNoteWasteObject

0..*

Gemäß den Angaben des Übernehmers tatsächlich abgelehnter Abfall.

ConsignmentNoteData

ConsignmentNoteDocument

Allgemeine Angaben (“Kopfdaten”, “Metadaten”) zum Begleitschein, z.B. VEBSV-ID und Begleitscheinart.

ConsignmentNoteDocument
Name/Typ min..max Definition

TypeID

ReferenceIdentifier

0..1

Begleitscheinart (Codeliste 3826).Beispiele: “Normaler Begleitschein”, “Streckengeschäft”, “Kein Transport”.

ProcessTypeID

ReferenceIdentifier

0..1

Angabe, ob es sich um einen “Begleitschein danach” handelt (Codeliste 8113).Anmerkung: Für einen “Begleitschein danach” ist hier die entsprechende GTIN (9008390117347) aus der Codeliste angegeben. Für alle anderen Begleitscheine entfällt ProcessTypeID.

ID

PredeterminedScopeReferenceIdentifier

0..1

Die Abfalltransport- bzw. Übergabe/Übernahme-ID (VEBSV-ID; ID zum vollelektronischen Begleitscheinverfahren) zu der die Begleitschein-Angaben gehören.

DocumentEvent

DocumentEvent

0..*

Angaben zu dokumentbezogenen Tätigkeiten, z.B. zur Dokumentübermittlung.Anmerkung: Zum “Begleitschein” können über DocumentEvent Angaben zur Dokumentübermittlung enthalten sein (GTIN 9008390106600 aus Codeliste 1239). Damit ist die Übermittlung bzw. Freigabe an die Behörde gemeint. D.h. daraus ist ablesbar, ob bzw. seit wann die Behörde Zugriff auf den Begleitschein hat.

ConsignmentNoteDocument

ConsignmentNoteEnvelope

Ein “Umschlag” der folgendes beinhalten kann:1. Meldungen/Deklarationen zu Transporten bzw. Übergaben/Übernahmen von gefährlichen Abfällen;2. “Begleitscheine” (die sich bei VEBSV 2.0 aus Inhalten von Meldungen/Deklarationen zusammensetzen).

ConsignmentNoteEnvelope
Name/Typ min..max Definition

Document

EnvelopeDocument

0..1

Allgemeine Angaben zum “Umschlag” und den darin enthaltenen Daten, z.B. Erstellungsdatum.

ListedData

ListedData

0..1

Aufzählung von “Objekten”.Das sind im vorliegenden Datenformat:1. Nicht-natürliche Personen, z.B. Abfallbesitzer und Transporteure.2. Natürliche Personen, z.B. Kontaktpersonen3. Standorte und Anlagen, z.B. Absendeorte (Beladeorte) und Empfangsorte (Entladeorte).

EnvironmentalDataDocument

EnvironmentalDataDocument

0..*

Einzelne Meldungen bzw. Deklarationen zur Übergabe/Übernahme bzw. zum Transport von Abfällen.

ConsignmentNoteDocument

ConsignmentNote

0..*

“Begleitschein” (elektronisches Äquivalent zum Begleitschein) für gefährlichen Abfall.Anmerkung 1: Der “Begleitschein” setzt sich nach definierten Regeln aus den Inhalten der Meldungen und Deklarationen (siehe EnvironmentalDataDocument-Element) zusammen.Anmerkung 2: Im Allgemeinen sind Angaben zu genau einem Begleitschein enthalten.

ConsignmentNoteEnvelope

ConsignmentNoteHandOverEvent

Angaben zu einer Abfallübergabe.

ConsignmentNoteHandOverEvent
Name/Typ min..max Definition

DocumentScopeAssignmentID

DocumentScopeAssignmentIdentifier

0..1

In der Dateninstanz verwendeter Identifikator für die Abfallübergabe.

Date

Date

0..1

Datum der Übergabe.

DateTime

DateTime

0..1

Zeitpunkt der Übergabe.

Description

MultilingualDescription

0..1

Anmerkungen des Übergebers zur Abfallübergabe.

AssociatedObjectReferenceID

PredeterminedScopeReferenceIdentifier

0..1

Begleitscheinnummer des Übergebers.

AssociatedObjectDocumentScopeReferenceID

DocumentScopeRoleReferenceIdentifier

0..*

Angabe der folgenden Bezüge (Rolle: Codeliste 4639):1. Bezug auf den Übergeber (Rolle: “Übergeber”; Bezug auf Eintrag aus ListedData/Organization oder ListedData/Person). Jedenfalls benötigte Angabe. Keine Mehrfachangabe.2. Bezug auf den Absendeort (Rolle: “Beginnstelle”; Bezug auf Eintrag aus ListedData/LocalUnit).Anmerkung 1: Die Bezugnahme erfolgt jeweils durch Angabe der innerhalb der Dateninstanz zugewiesenen Identifikationszeichenkette, z.B. aus “ListedData/Organization/DocumentScopeAssignmentID” (nicht-natürliche Personen) oder aus “ListedData/Person/DocumentScopeAssignmentID” (natürliche Personen).Anmerkung 2: Für den Absendeort können die folgenden Bezüge angegeben sein: Standort; Standort + ortsfeste Anlage; Standort + mobile Anlage; Standort + ortsfeste Anlage + mobile Anlage. Dementsprechend kann es Mehrfachangaben zur Rolle “Beginnstelle” geben.Anmerkung 3: Für Übergaben/Übernahmen ohne Transport gilt als Absendeort jener Ort, an dem sich der Abfall bei der Übergabe/Übernahme befindet.

ConsignmentNoteHandOverEvent

ConsignmentNoteTakeOverEvent

Angaben zu einer Abfallübernahme.

ConsignmentNoteTakeOverEvent
Name/Typ min..max Definition

DocumentScopeAssignmentID

DocumentScopeAssignmentIdentifier

0..1

In der Dateninstanz verwendeter Identifikator für die Abfallübernahme.

Date

Date

0..1

Datum der Übernahme.

DateTime

DateTime

0..1

Zeitpunkt der Übernahme.

Description

MultilingualDescription

0..1

Anmerkungen des Übernehmers zur Abfallübernahme.

AssociatedObjectReferenceID

PredeterminedScopeReferenceIdentifier

0..1

Begleitscheinnummer des Übernehmers.

AssociatedObjectDocumentScopeReferenceID

DocumentScopeRoleReferenceIdentifier

0..*

Angabe der folgenden Bezüge (Rolle: Codeliste 4639):1. Bezug auf Übernehmer (Rolle: “Übernehmer”; Bezug auf Eintrag aus ListedData/Organization oder ListedData/Person). Keine Mehrfachangaben.2. Bezug auf den Empfangsort (Rolle: “Endstelle”; Bezug auf Eintrag aus ListedData/LocalUnit).Anmerkung 1: Die Bezugnahme erfolgt jeweils durch Angabe der innerhalb der Dateninstanz zugewiesenen Identifikationszeichenkette, z.B. aus “ListedData/Organization/DocumentScopeAssignmentID” (nicht-natürliche Personen) oder aus “ListedData/Person/DocumentScopeAssignmentID” (natürliche Personen).Anmerkung 2: Für den Empfangsort können jeweils die folgenden Bezüge angegeben sein: Standort; Standort + ortsfeste Anlage; Standort + mobile Anlage; Standort + ortsfeste Anlage + mobile Anlage. Dementsprechend kann es Mehrfachangaben zur Rolle “Endstelle” geben.Anmerkung 3: Für Übergaben/Übernahmen ohne Transport gilt als Empfangsort jener Ort, an dem sich der Abfall bei der Übergabe/Übernahme befindet.

ConsignmentNoteTakeOverEvent

ConsignmentNoteTransferEvent

Angaben zur Abfall-Übergabe/Übernahme durch einen “weiteren Abfallsammler” (einen Abfallsammler, der ein Streckengeschäft durchführt).

ConsignmentNoteTransferEvent
Name/Typ min..max Definition

DocumentScopeAssignmentID

DocumentScopeAssignmentIdentifier

0..1

In der Dateninstanz verwendeter Identifikator für die Abfall-Übergabe/Übernahme.

Description

MultilingualDescription

0..1

Anmerkungen des weiteren Abfallsammlers zur Abfall-Übergabe/Übernahme.

AssociatedObjectReferenceID

PredeterminedScopeReferenceIdentifier

0..2

Begleitscheinnummern des weiteren Abfallsammlers.

AssociatedObjectDocumentScopeReferenceID

DocumentScopeRoleReferenceIdentifier

0..*

Angabe der folgenden Bezüge (Rolle: Codeliste 8538):1. Bezug auf den weiteren Abfallsammler (Rolle: “Weiterer Abfallsammler”; Bezug auf Eintrag aus ListedData/Organization oder ListedData/Person). Keine Mehrfachangaben. Ein “weiterer Abfallsammler” ist jemand, der ein Streckengeschäft durchführt, und mit dem übernommenen und gleich anschließend wieder übergebenen Abfall auf keinem seiner Standorte in Berührung kommt.Anmerkung: Die Bezugnahme erfolgt jeweils durch Angabe der innerhalb der Dateninstanz zugewiesenen Identifikationszeichenkette, z.B. aus “ListedData/Organization/DocumentScopeAssignmentID” (nicht-natürliche Personen) oder aus “ListedData/Person/DocumentScopeAssignmentID” (natürliche Personen).

ConsignmentNoteTransferEvent

ConsignmentNoteTransportEvent

Angaben zu einem Transporteur und dessen durchgeführten Abfalltransport.

ConsignmentNoteTransportEvent
Name/Typ min..max Definition

TypeID

ReferenceIdentifier

0..1

Art des Transportmittels, z.B. Straße, Schiene (Codeliste 9572).

Description

MultilingualDescription

0..1

Anmerkungen des Transporteurs zum Abfalltransport.

LoadingUnloadingEvent

TypeCEvent

0..*

Angaben zu den zum Transport gehörenden Belade- und Entlade-Orten.

AssociatedObjectDocumentScopeReferenceID

DocumentScopeRoleReferenceIdentifier

0..*

Angabe der folgenden Bezüge (Rolle: Codeliste 5526):1. Bezug auf den Transporteur (Rolle: “Transporteur”; Bezug auf Eintrag aus ListedData/Organization oder ListedData/Person). Mehrfachangabe nicht zulässig.2. Bezug auf den Veranlasser (Rolle: “Veranlasser”; Bezug auf Eintrag aus ListedData/Organization oder ListedData/Person).Anmerkung 1: Die Bezugnahme erfolgt jeweils durch Angabe der innerhalb der Dateninstanz zugewiesenen Identifikationszeichenkette, z.B. aus “ListedData/Organization/DocumentScopeAssignmentID” (nicht-natürliche Personen) oder aus “ListedData/Person/DocumentScopeAssignmentID” (natürliche Personen).Anmerkung 2: Veranlasser ist derjenige Abfallbesitzer, der den Transport beauftragt.Anmerkung 3: Sofern ein Abfallbesitzer den Transport selbst durchführt, ist dieser Abfallbesitzer sowohl als Transporteur als auch als Veranlasser angegeben (Bezug auf denselben Eintrag aus ListedData/Organization oder ListedData/Person).

TransportId

UUIDIdentifier

0..1

Beschreibung zur einzigartigen Erkennung eines Transports durch die Transport-ID

ConsignmentNoteTransportEvent

ConsignmentNoteTransportStartEvent

Angaben zu einem Abfalltransportbeginn.

ConsignmentNoteTransportStartEvent
Name/Typ min..max Definition

PredeterminedScopeAssignmentID

PredeterminedScopeAssignmentIdentifier

0..1

Identifikation der Beförderungs-Bewegung.Anmerkung 1: Es kann an dieser Stelle eine vom Dateninstanz-Ersteller für die Beförderungsbewegung verwendete ID mit übermittelt werden, um etwa bei einer späteren Sichtung oder Kontrolle der übermittelten Daten diese leichter interpretieren und zuordnen zu können. Zwingend benötigt wird die Angabe hingegen nicht.Anmerkung 2: Bei regelmäßig wiederkehrenden Beförderungsbewegungen kann es sich auch um die Identifikation der Serie von Beförderungsbewegungen handeln, und nicht notwendigerweise die Identifikation der einzelnen Beförderungsbewegung (vergleiche Flug-Nummer).

TypeID

ReferenceIdentifier

0..1

Art des Transportmittels, z.B. Straße, Schiene (Codeliste 2939).

Description

MultilingualDescription

0..1

Anmerkungen zum Abfalltransportbeginn.

Object

TypeBEventObject

0..*

Angaben zum Transportmittel, z.B. Lastkraftwagen, Zug oder Schiff.

LoadingUnloadingEvent

TypeCEvent

0..1

Angaben zum Beladeort, auf den sich die Angaben zum Abfalltransportbeginn beziehen.

AssociatedObjectDocumentScopeReferenceID

DocumentScopeRoleReferenceIdentifier

0..*

Angabe der folgenden Bezüge (Rolle: Codeliste 5526):1. Bezug auf den Transporteur (Rolle: “Transporteur”; Bezug auf Eintrag aus ListedData/Organization oder ListedData/Person). Mehrfachangabe nicht zulässig.

TransportId

UUIDIdentifier

0..1

Beschreibung zur einzigartigen Erkennung eines Transports durch die Transport-ID

ConsignmentNoteTransportStartEvent

ConsignmentNoteTransportAbortEvent

ConsignmentNoteTransportAbortEvent
Name/Typ min..max Definition

TransportId

UUIDIdentifier

0..1

Beschreibung zur einzigartigen Erkennung eines Transports durch die Transport-ID

AbortReasonID

ReferenceIdentifier

0..1

Angaben zum Transportabbruchgrund, z.B. Ladeverlust oder Ablehnung

DateTime

DateTime

1..1

Zeitpunkt der Transportabbruchmeldung

ConsignmentNoteTransportAbortEvent

ConsignmentNoteWasteRejectionEvent

ConsignmentNoteWasteRejectionEvent
Name/Typ min..max Definition

RejectionReasonID

ReferenceIdentifier

0..1

Grund für die Ablehnung der Übergabe bzw. Übernahme (Codeliste 3161).

DateTime

DateTime

1..1

Zeitpunkt der Ablehnungsmeldung

ConsignmentNoteWasteRejectionEvent

ConsignmentNoteWasteObject

Angaben zu einer Menge von weitergegebenem bzw. transportiertem Abfall.

ConsignmentNoteWasteObject
Name/Typ min..max Definition

TypeID

ReferenceIdentifier

0..1

Art des Abfalls (Codeliste 5174).

SubTypeID

ReferenceIdentifier

0..*

Kontaminationen des Abfalls (zutreffende Kontaminationsgruppen) (Codeliste 7835).

Description

MultilingualDescription

0..1

Beschreibung des Abfalls.

PropertyStatement

PropertyStatement

0..1

Masse des Abfalls.

AssociatedObjectDocumentScopeReferenceID

DocumentScopeRoleReferenceIdentifier

0..*

Angabe der folgenden Bezüge (Rolle: Codeliste 4214):1. Bezug auf die Übergabe, für welche die Abfallmenge deklariert wurde, bzw. die Übernahme, für welche die Abfallmenge als übernommene Abfallmenge angegeben wurde (Rolle: “Teil von”; Bezug auf Eintrag aus ConsignmentNoteData/HandOverEvent bzw. ConsignmentNoteData/TakeOverEvent). Keine Mehrfachangaben.Anmerkung 1: Die Bezugnahme erfolgt jeweils durch Angabe der innerhalb der Dateninstanz zugewiesenen Identifikationszeichenkette, z.B. aus “HandOverEvent/DocumentScopeAssignmentID”.Anmerkung 2: Für deklarierte Abfallmengen (Art und Masse) wird ausschließlich auf dazugehörige Übergaben verwiesen (nicht jedoch auf Übernahmen). Für übernommene Abfallmengen (Art und Masse) wird ausschließlich auf dazugehörige Übernahmen verwiesen (nicht jedoch auf Übergaben).Anmerkung 3: Es ist nicht notwendigerweise für jede deklarierte Abfallmenge immer ein Bezug auf eine Übergabe angegeben, und nicht für jede übernommene Abfallmenge immer ein Bezug auf eine Übernahme.

ContainsPersistentOrganicPollutant

Indicator

0..1

Gibt an ob der Abfall ein POP-Abfall ist.

RejectionReasonID

ReferenceIdentifier

0..1

Grund für die Ablehnung des Abfalls (Codeliste 3161). Anmerkung 1: Ist nur in abgelehnten Abfällen enthalten.

ConsignmentNoteWasteObject

DocumentEvent

Angaben zu einer dokumentbezogenen Tätigkeit, z.B. Dokumenterstellung.

DocumentEvent
Name/Typ min..max Definition

TypeID

ReferenceIdentifier

1..1

Art der dokumentbezogenen Tätigkeit, z.B. Dokumenterstellung (Codeliste 1239).Anmerkung: Bei der Übermittlung von Daten über das EDM Webservice (ShareDocument-Operation) sind ausschließlich Angaben zur Dokumenterstellung zulässig, nicht aber zur Dokumentübermittlung. Beim Abruf von Daten bzw. im Response von Datenübermittlungen werden zusätzlich zu allfällig vorhandenen Angaben zur Dokumenterstellung auch Angaben zur Dokumentübermittlung über das EDM Webservice zurückgeliefert.

DateTime

DateTime

1..1

Zeitpunkt der dokumentbezogenen Tätigkeit, z.B. Zeitpunkt der Dokumenterstellung.

DocumentID

AssignmentFlexibleIdentifier

0..3

Dem Dokument bzw. der Dateninstanz bei Erstellung bzw. Übermittlung zugewiesene ID.Anmerkung 1: An dieser Stelle können unter anderem sogenannte Begleitscheinnummern angegeben werden. Damit diese auch von den IT-Systemen als Begleitscheinnummern identifizierbar sind, ist im “collectionID”-Attribut der passende Eintrag aus Codeliste 4251 anzugeben, namentlich die GTIN 9008390117132 für “Begleitscheinnummer”. Für andere Arten von durch Ersteller zugewiesene IDs ist aktuell keine eindeutige Typisierung vorgesehen, für diese entfällt das “collectionID”-Attribut.Anmerkung 2: Codeliste 4251 enthält auch einen Eintrag für das “EDM” (GTIN 9008390104026). Dieser ist bei der Datenübermittlung an das EDM NICHT zu verwenden. Beim Datenabruf aus dem EDM kann jedoch die im EDM für das Dokument bzw. die Dateninstanz verwendete ID geliefert werden. Dabei handelt es sich um jene “Transaction-ID” (Datenübermittlungs-ID), mit der die Dateninstanz an das EDM (initial) übermittelt wurde. Für Korrekturen und Stornierungen angeforderte “Transaction-IDs” treten nicht als EDM-IDs für Dateninstanzen auf.

AssociatedObjectDocumentScopeReferenceID

DocumentScopeRoleReferenceIdentifier

0..*

Folgende Arten von mit der Dokumenterstellung in Verbindung stehenden Bezügen:Bezug auf die “nicht-natürliche Person” oder “natürliche Person”, welche Dokumentersteller ist. (Rolle “Verantwortlicher Akteur” aus Codeliste 1331, Bezug auf einen Eintrag aus “ListedData/Organization” im Falle der nicht-natürlichen Person, bzw. auf “ListedData/Person” im Falle der natürlichen Person).

DocumentEvent

EnvelopeDocument

Allgemeine Angaben (“Kopfdaten”, “Metadaten”) zu einer Gruppe von Dokumenten (“Umschlag”). Zu solchen Metadaten zählen beispielsweise Informationen zum Dokumentersteller und zum Zeitpunkt der Dokumenterstellung.

EnvelopeDocument
Name/Typ min..max Definition

CreationDate

DateTime

0..1

Erstellungszeitpunkt des Dokuments.Anmerkung: Dies ist eine üblicherweise automatisch durch eine IT-Anwendung generierte Angabe, die den Zeitpunkt anzeigt, zu dem das Dokument (die Daten-Serialisierung) erstellt wurde, üblicherweise unter Auslesen von Daten aus einer Datenbank. Der Dokument-Erstellungszeitpunkt liefert keine Aussage darüber, auf welchen Zeitpunkt oder Zeitraum sich die im Dokument repräsentierten Daten beziehen, bzw. zu welchem Zeitpunkt oder Zeitraum diese erfasst wurden!

ReferenceDataVersionDate

Date

0..1

Datum, das den Stand der zum Zeitpunkt der Dokumenterstellung in Verwendung befindlichen Codelisten anzeigt.Anmerkung: Dies ist eine üblicherweise automatisch durch eine IT-Anwendung generierte Angabe. Es handelt sich also um die Angabe, welchen Stand der Codelisten durch die vom Dokumentersteller genutzte Software verwendet wird.

DocumentEvent

DocumentEvent

0..*

Angaben zur Erstellung des “Umschlags” (der Gruppe von Dokumenten).

EnvelopeDocument

EnvironmentalData

Der Meldungsinhalt, Angaben zur Übergabe/Übernahme bzw. zum Transport von Abfällen.

EnvironmentalData
Name/Typ min..max Definition

TypeAEvent

TypeAEvent

0..*

Angaben zu Abfall-Übergaben/Übernahmen (Übergang des Abfallbesitzes von einer Person auf eine andere).

TypeBEvent

TypeBEvent

0..*

Angaben zu einer konkreten Bewegung eines Transportmittels zur Beförderung von Abfällen.

TypeCEvent

TypeCEvent

0..*

Angaben zu Beladungen und Entladungen eines Transportmittels, z.B. eines LKW oder eines Schiffs.

EnvironmentalData

EnvironmentalDataDocument

Dateninstanz bzw. “Dokument” mit Angaben zur Übergabe/Übernahme bzw. zum Transport von Abfällen, z.B. Meldung oder Deklaration.

EnvironmentalDataDocument
Name/Typ min..max Definition

Document

SingleDocument

0..1

Allgemeine Angaben (Metadaten), z.B. Erstellungsdatum und Art der Dateninstanz (“Dokumentart”).

EnvironmentalData

EnvironmentalData

0..1

Inhalte, d.h. Angaben zu Abfall-Übergaben/Übernahmen und Abfalltransporten.

EnvironmentalDataDocument

EnvironmentalDataEnvelope

Ein “Umschlag”, der Angaben zu Übergaben/Übernahmen bzw. Transporten von Abfällen enthält.Anmerkung 1: Ein solcher “Umschlag” zeichnet sich durch folgendes aus:(a) Die Inhalte stammen alle von ein- und demselben Datenbereitsteller;(b) Die Inhalte werden bzw. wurden vom Datenbereitsteller als ein einziges Gesamtdatenpaket bereitgestellt (also insbesondere auch zu einem einzigen Zeitpunkt, und nicht zu mehreren verschiedenen Zeitpunkten).Anmerkung 2: Das VEBSV 2.0-Webservice dient dazu, zeitnah vor, während und nach Übergaben/Übernahmen und Transporten von Abfällen Daten auszutauschen. In einem EDM-Webservice wie diesem, in dem die Häufigkeit der Datenübermittlungen vergleichsweise hoch, und die Größe der einzelnen übermittelten Dateninstanzen entsprechend vergleichsweise klein ist, ist vorgesehen, dass übermittelte “Umschläge” jeweils nur EINEN Inhalt (EnvironmentalDataDocument-Eintrag), d.h. eine Meldung bzw. eine Deklaration, enthalten. In anderen EDM-Webservices, z.B. solchen, die der Übermittlung von Monatsmeldungen dienen, ist hingegen die Übermittlung mehrerer Meldungen innerhalb eines Umschlags möglich.

EnvironmentalDataEnvelope
Name/Typ min..max Definition

Document

EnvelopeDocument

0..1

Allgemeine Angaben zum “Umschlag” und den darin enthaltenen Daten, z.B. Ersteller und Erstellungsdatum.

ListedData

ListedData

0..1

Aufzählung von “Objekten”.Das sind im vorliegenden Datenformat:1. Nicht-natürliche Personen, z.B. Abfallbesitzer und Transporteure.2. Natürliche Personen, z.B. Kontaktpersonen3. Standorte und Anlagen, z.B. Absendeorte (Beladeorte) und Empfangsorte (Entladeorte).Anmerkung: Durch diesen Aufbau des Datenformats ist gewährleistet, dass Angaben zu diesen Personen, Standorten und Anlagen, z.B. Adressen, in jeder Dateninstanz nur einmal enthalten zu sein brauchen, auch wenn auf einen Eintrag mehrfach Bezug genommen wird, z.B. wenn der Übernehmer von Abfällen auch gleichzeitig der Transporteur dieser Abfälle ist.

EnvironmentalDataDocument

EnvironmentalDataDocument

0..*

Die Angaben zur Übergabe/Übernahme bzw. zum Transport von Abfällen.Folgende Arten von Angaben werden unterstützt:1. Übergabedeklaration: Angaben zu beabsichtigten bzw. bevorstehenden Abfall-Übergaben/Übernahmen; die Informationen werden durch den Übergeber der Abfälle bereitgestellt. Beinhaltet die “Abfall-Übergabe/Übernahme-Sicht” (TypeAEvent), aber nicht die “Transportsicht” (TypeBEvent, TypeCEvent). Die Übermittlung via EDM-Schnittstelle erfolgt noch bevor die Übergabe/Übernahme stattfindet. Übergabedeklarationen werden über die EDM-Schnittstelle ausschließlich für Übergaben erwartet, bei welchen es sich NICHT um Übergaben aus einem Streckengeschäft handelt.2. Übergabemeldung: Angaben zur Abfall-Übergabe/Übernahme; die Informationen werden durch den Übergeber der Abfälle bereitgestellt. Beinhaltet die “Abfall-Übergabe/Übernahme-Sicht” (TypeAEvent), aber nicht die “Transportsicht” (TypeBEvent, TypeCEvent). Die Übermittlung via EDM-Schnittstelle erfolgt für gewöhnlich nach erfolgter Übergabe/Übernahme, ggf. auch bereits davor. Übergabemeldungen werden über die EDM-Schnittstelle ausschließlich für Übergaben erwartet, bei welchen es sich um Übergaben aus einem Streckengeschäft handelt.3. Übernahmemeldung: Angaben zur Abfall-Übergabe/Übernahme; die Informationen werden durch den Übernehmer der Abfälle bereitgestellt. Beinhaltet die “Abfall-Übergabe/Übernahme-Sicht” (TypeAEvent), aber nicht die “Transportsicht” (TypeBEvent, TypeCEvent). Die Übermittlung via EDM-Schnittstelle erfolgt für gewöhnlich nach erfolgter Übergabe/Übernahme, insbesondere bei Streckengeschäften ggf. auch bereits davor.4. Eigenüberprüfungsmeldung: Bestätigung einer Abfall-Übergabe/Übernahme. Beinhaltet Angaben zur Übergabe/Übernahme (TypeAEvent). Die Eigenüberprüfung ist das Pendant zur Abfalltransportbeginnmeldung für Übergaben/Übernahmen ohne Transport, und wird ausschließlich für solche Übergaben/Übernahmen erwartet. Die Übermittlung via EDM-Schnittstelle erfolgt für gewöhnlich durch Übergeber oder Übernehmer unmittelbar zum Wirksamwerden der Übergabe/Übernahme.5. Transportdeklaration: Angaben zu beabsichtigten bzw. bevorstehenden Transporten von Abfällen. Beinhaltet die “Transportsicht”, d.h. Abfallbeförderungsbewegungen (TypeBEvent) mit dazugehörigen Beladungen und Entladungen (TypeCEvent). Beinhaltet nicht die rechtliche “Abfall-Übergabe/Übernahme-Sicht” (TypeAEvent). Die Übermittlung via EDM-Schnittstelle erfolgt noch vor Transportbeginn, z.B. durch Transporteure oder Transport-Auftraggeber.6. Abfalltransportbeginnmeldung: Bestätigung des Transportbeginns. Beinhaltet insbesondere Angaben zur betreffenden Beladung (TypeCEvent), aber auch Angaben etwa zum Transportmittel (TypeBEvent). Die Übermittlung via EDM-Schnittstelle erfolgt für gewöhnlich durch den Transporteur unmittelbar vor Transportbeginn.Anmerkung 1: Pro Datenübermittlung (pro ShareDocument-Operationsaufruf) kann immer nur genau eine Meldung bzw. Deklaration übermittelt werden.Anmerkung 2: Bei der Datenübermittlung wird zu allen Abfall-Übergaben/Übernahmen und Beladungen sowie Entladungen jeweils die Angabe einer “VEBSV-ID” (Abfall-Übergabe/Übernahme- bzw. Beförderungs-ID) benötigt. Mit dieser ID sind zusammengehörige Angaben zu Abfall-Übergaben/Übernahmen und Abfalltransporten zu verknüpfen. Die detaillierten Vorgaben zur Verwendung der ID befinden sich in einem eigenen Abschnitt der Schnittstellenbeschreibung.

EnvironmentalDataEnvelope

ListedData

Aufzählung von “Objekten”, z.B. nicht-natürlichen Personen oder Standorten, mit deren Angaben.Anmerkung: Innerhalb der Dateninstanz kann auf aufgezählte “Objekte” mit einer ID verwiesen werden. Dadurch unterstützt das Datenformat die Vermeidung von Redundanz: Detailangaben zu einem “Objekt” brauchen nur einmal enthalten zu sein, auch dann wenn mehrfach auf das “Objekt” Bezug genommen wird, etwa wenn Übernehmer und Transporteur dieselbe Person sind.

ListedData
Name/Typ min..max Definition

Person

Person

0..*

Liste von natürlichen Personen.Anmerkung 1: Im vorliegenden Datenformat werden solche Angaben beispielsweise dann benötigt, wenn es sich bei einem Beteiligten, z.B. einem Abfallübergeber, um eine natürliche Person handelt.Anmerkung 2: An anderen Stellen in der Dateninstanz werden natürliche Personen in Form von Verweisen auf Einträge dieser Liste angegeben.

Organization

Organization

0..*

Liste von Unternehmen oder anderen “nicht-natürlichen Personen”.Anmerkung 1: Im vorliegenden Datenformat werden solche Angaben insbesondere in Zusammenhang mit Übergebern und Übernehmern von Abfällen benötigt, sowie mit Transporteuren.Anmerkung 2: An anderen Stellen in der Dateninstanz werden Unternehmen in Form von Verweisen auf Einträge dieser Liste angegeben.Anmerkung 3: Auf dasselbe Unternehmen kann mehrfach verwiesen werden, z.B. sowohl als Übernehmer, als auch als Transporteur eines Abfalls.

LocalUnit

LocalUnit

0..*

Liste von örtlichen Einheiten, also Standorten oder Anlagen.Anmerkung 1: Im vorliegenden Datenformat werden solche Angaben insbesondere in Zusammenhang mit Absende- und Empfangsorten von Abfalltransporten benötigt.Anmerkung 2: An anderen Stellen in der Dateninstanz erfolgen Angaben zu örtlichen Einheiten in Form von Verweisen auf Einträge dieser Liste.

ListedData

LocalUnit

Angaben zu einem Standort oder einer Anlage.Anmerkung: Das Datenformat sieht drei Möglichkeiten der Angabe vor, wo sich ein Standort bzw. eine stationäre Anlage befindet: Punkt-Geodaten (Koordinaten), Adressen und Grundstücksnummern. Die drei Varianten der Angabe sind kombinierbar. Die Angabe von Grundstücksnummern ist allerdings lediglich als “Ausweichvariante” für Fälle gedacht, in welchen weder Punkt-Geodaten noch Adressen bereitgestellt werden können.

LocalUnit
Name/Typ min..max Definition

DocumentScopeAssignmentID

DocumentScopeAssignmentIdentifier

1..1

Im Dokumentkontext verwendeter Identifikator für den Standort oder die Anlage.

ID

AssignmentIdentifier

0..1

Dem Standort bzw. der Anlage zugewiesene Identifikatoren, jeweils zusammen mit der Identifikation der Sammlung von Identifikatoren (Auswahl eines Eintrags aus Codeliste 9776).Beispiel: GLN, die im EDM zur Identifikation des Standorts verwendet wird (zusammen mit GTIN “9008390104026” für “EDM”).

MultiPartID

AssignmentMultiPartIdentifier

0..*

Mehrteilige Identifikatoren zum Standort oder der Anlage (Identifikationsschema: Codeliste 5951).Anmerkung 1: Diese mehrteiligen Identifikatoren werden im vorliegenden Datenformat ausschließlich zur Identifikation von Grundstücken verwendet, auf welchen sich der Standort bzw. die Anlage befinden, d.h. für zweiteilige Kombinationen aus Katastralgemeindenummer und Grundstücksnummer.Anmerkung 2: Die Identifikation von Grundstücken ist als “Ausweichvariante” für Fälle vorgesehen, in welchen weder Punkt-Geodaten noch Adressen bereitgestellt werden können.

Name

LongNameText

0..1

Bezeichnung des Standorts oder der Anlage.

TypeID

ReferenceIdentifier

0..1

Art der örtlichen Einheit (Standort, ortsfeste Anlage oder mobile Anlage, Codeliste 9351).Anmerkung 1: Die Angabe von Anlagen ist nur für den Fall vorgesehen, dass ein Bezug auf den Anlagenregister-Eintrag des EDM mit angegeben wird (d.h. unter “ID” eine EDM-Anlagen-GLN angegeben wird). Andernfalls wird ausschließlich der Standort angegeben. Für im EDM registrierte Standorte wird unter “ID” ebenfalls die GLN des Standort-Eintrags im EDM erwartet. Beim Absendeort kann es sich aber beispielsweise auch um einen nicht im EDM registrierten Standort handeln. In diesem Fall wird als "Art der örtlichen Einheit" der Wert "Standort" erwartet, die “ID”-Angabe entfällt.Anmerkung 2: Für mobile Anlagen werden an dieser Stelle keine Ortsbezüge (z.B. Koordinaten, Adressen, Grundstücksnummern) erwartet. Mobile Anlagen können nicht für sich allein als Ortsbezug angegeben werden (z.B. als Absendeort), sondern nur in Kombination mit einem Bezug auf einen Standort oder eine ortsfeste Anlage (den Aufstellungsort der mobilen Anlage).

Address

Address

0..1

Adresse des Standorts oder der Anlage.

gml:Pointgml:Point

0..1

Punkt-Geodaten zum Standort bzw. der Anlage im GML-Point-Format.Anmerkung 1: Es wird die Angabe des Flächenmittelpunkts des Standorts bzw. der Anlage erwartet.Anmerkung 2: Das vorliegende Datenformat unterstützt nur einen Auszug aller gemäß GML-Standard möglichen Point-Angaben. Der unterstützte Auszug ist mit einer von GML abgeleiteten, eigens definierten XSD-Datei vorgegeben.Anmerkung 3: Es wird die Angabe des räumlichen Bezugssystems erwartet (Attribut srsName). Der (jeweilige) Wert hat mit der Zeichenkette “urn:ogc:def:crs:” zu beginnen, und auch darüber hinaus dem OGC URN-Muster für räumliche Bezugssysteme zu entsprechen, z.B. “urn:ogc:def:crs:EPSG::3225”. Die zulässigen räumlichen Bezugssysteme sind in Codeliste 8390 definiert. Im Allgemeinen wird, wenn möglich, die Bereitstellung von “Originaldaten” erwartet, d.h. ohne Umrechnungen zwischen räumlichen Bezugssystemen.

LocalUnit

MultilingualDescription

Beschreibungstext.Anmerkung: Im vorliegenden Datenformat werden Beschreibungstexte in deutscher Sprache erwartet. Die vom “MultilingualDescription”-Typ grundsätzlich unterstützte Möglichkeit, Angaben in mehreren verschiedenen Sprachen zu ermöglichen, wird im vorliegenden Datenformat nicht genutzt: “IndividualDescription” ist deshalb im vorliegenden Datenformat nicht wiederholbar.

MultilingualDescription
Name/Typ min..max Definition

IndividualDescription

Description

1..1

Beschreibungstext, mit ausgewiesener Sprache (Deutsch).

MultilingualDescription

Organization

Angaben zu einem Unternehmen, bzw. allgemeiner zu einer “nicht-natürlichen Person”.

Organization
Name/Typ min..max Definition

DocumentScopeAssignmentID

DocumentScopeAssignmentIdentifier

1..1

In der XML-Dateninstanz verwendeter ("technischer") Identifikator für das Unternehmen bzw. die nicht-natürliche Person.

ID

AssignmentIdentifier

0..1

Dem Unternehmen bzw. der nicht-natürlichen Person zugewiesene Identifikatoren, jeweils zusammen mit der Identifikation der Sammlung von Identifikatoren (Auswahl eines Eintrags aus Codeliste 1756).Beispiel: GLN (Global Location Number), die der nicht-natürlichen Person im EDM zugewiesen ist (zusammen mit GTIN “9008390104026” für “EDM”).Anmerkung: Das vorliegende Datenformat ist ausschließlich für die Angabe von in EDM registrierten nicht-natürlichen Personen konzipiert, zusammen mit der dieser Person im EDM zugewiesenen Identifikationsnummer (GLN). Siehe auch Datenanforderungen und Prüfregeln.

Name

LongNameText

0..1

Bezeichnung des Unternehmens bzw. der nicht-natürlichen Person.

Address

Address

0..1

Sitzadresse des Unternehmens bzw. der nicht-natürlichen Person.

Organization

Person

Angaben zu einer (natürlichen) Person, z.B. Vorname und Nachname.

Person
Name/Typ min..max Definition

DocumentScopeAssignmentID

DocumentScopeAssignmentIdentifier

1..1

In der XML-Dateninstanz verwendeter ("technischer") Identifikator für die Person.

ID

AssignmentIdentifier

0..1

Der natürlichen Person zugewiesene Identifikatoren, jeweils zusammen mit der Identifikation der Sammlung von Identifikatoren (Auswahl eines Eintrags aus Codeliste 1756).Beispiel: GLN (Global Location Number), die der Person im EDM zugewiesen ist (zusammen mit GTIN “9008390104026” für “EDM”).Anmerkung: Das vorliegende Datenformat ist ausschließlich für die Angabe von in EDM registrierten Personen konzipiert, zusammen mit der dieser Person im EDM zugewiesenen Identifikationsnummer (GLN). Siehe auch Datenanforderungen und Prüfregeln.

GivenName

GivenNameText

0..1

Vorname.

FamilyName

FamilyNameText

0..1

Nachname.

GenderID

ReferenceIdentifier

0..1

Geschlecht (Codeliste 4287).

Address

Address

0..1

Anschrift der Person (typischerweise Adresse des Hauptwohnsitzes).

Person

PropertyStatement

Aussage über eine Größe.Anmerkung: Im vorliegenden Datenformat ausschließlich für Masse-Angaben, z.B. “2000kg”, genutzt, nicht aber für andere Größen, wie etwa Volumen.

PropertyStatement
Name/Typ min..max Definition

PropertyKindID

ReferenceIdentifier

1..1

Größenart (Codeliste 5618).Anmerkung: Im vorliegenden Datenformat wird als einzige Größenangabe die Angabe der Masse erwartet (Masse des transportierten bzw. weitergegebenen Abfalls).

ValueAssignmentStatement

ValueAssignmentStatement

1..1

Aussage über den Wert der Größe (Masse).Beispiel: “2000kg”.

MethodID

RelaxedReferenceNoRoleIdentifier

0..1

Methode, die zur Bestimmung der Eigenschaft (Abfallmasse) angewandt wurde: Geschätzt, gemessen oder gerechnet (Codeliste 7299).

PropertyStatement

SingleDocument

Allgemeine Angaben zu einem einzelnen Datenobjekt, d.h. zu einem zusammengehörigen Set von Angaben eines bestimmten Typs, z.B. Meldung oder Deklaration. Zu solchen allgemeinen Angaben zählt die Art des Datenobjekts, z.B. die Meldungsart.

SingleDocument
Name/Typ min..max Definition

TypeID

ReferenceIdentifier

0..1

Typ des Datenobjekts (Codeliste 5064).

Description

MultilingualDescription

0..1

Beschreibung bzw. Anmerkungen zum Datenobjekt, z.B. zur Meldung oder zur Deklaration.

DocumentEvent

DocumentEvent

0..*

Angaben zur Erstellung und zur Übermittlung des Datenobjekts, z.B. der Meldung oder der Deklaration.Anmerkung 1: Bei der Übermittlung von Daten an ein EDM Webservice ist dieses Datenelement NICHT zu verwenden, sondern stattdessen ausschließlich EnvironmentalDataEnvelope/Document/DocumentEvent.Anmerkung 2: Beim Abruf von Daten über ein EDM Webservice wird dieses Datenelement befüllt.Erläuterung zu den beiden vorangehenden Anmerkungen: In EDM Webservices wird ausschließlich die Übermittlung von Daten unterstützt, die von EINER Person erstellt wurden, und die Übermittlung ist immer mit EINER Person als Absender verbunden. Die Angaben zur Erstellung und Übermittlung werden daher auf “Umschlagebene” erwartet (EnvironmentalDataEnvelope/Document/DocumentEvent), und gelten für alle Inhalte des Umschlags. Beim Abruf von Daten über das EDM-Webservice können hingegen von unterschiedlichen Personen zu unterschiedlichen Zeitpunkten erstellte und übermittelte Daten innerhalb eines Umschlags zurückgeliefert werden. Die einzelnen Meldungen und Deklarationen innerhalb dieses gemeinsamen Umschlags enthalten daher jeweils für sich Angaben zur Erstellung und Übermittlung.

SingleDocument

TypeAEvent

Angaben zu einer Abfall-Übergabe/Übernahme (zum Übergang des Abfallbesitzes von einer Person auf eine andere).

TypeAEvent
Name/Typ min..max Definition

DocumentScopeAssignmentID

DocumentScopeAssignmentIdentifier

0..1

In der Dateninstanz für die Abfall-Übergabe/Übernahme verwendeter Identifikator.

TypeID

ReferenceIdentifier

0..1

Art der Abfall-Übergabe/Übernahme (Codeliste 8926).Anmerkung 1: Es wird insbesondere zwischen folgenden Arten von Übergaben/Übernahmen unterschieden:1. Abfall-Übergabe/Übernahme ohne Transport: Der Abfallbesitz geht auf eine andere Person über, der Abfall verbleibt aber am selben Ort bzw. wird nicht auf öffentlichen Verkehrswegen befördert.2. Abfall-Übergabe/Übernahme mit Transport, kein Streckengeschäft: Übernahme bzw. Übergabe von Abfall, verbunden mit einem Transport des Abfalls. Der Übernehmer bzw. Übergeber kommt mit dem Abfall an einem seiner Standorte “in Berührung”, führt also KEIN Streckengeschäft durch.3. Abfall-Übergabe/Übernahme mit Transport, Streckengeschäft: Übernahme bzw. Übergabe von Abfall, verbunden mit einem Transport des Abfalls. Der Übernehmer bzw. Übergeber kommt mit dem Abfall an KEINEM seiner Standorte “in Berührung”, führt also ein Streckengeschäft durch.Anmerkung 2: Für Abfall-Übergaben/Übernahmen ohne Transport wird die Angabe einer Begründung erwartet, siehe Datenelemente “ReasonID” und “ReasonDescription”.

ProcessTypeID

ReferenceIdentifier

0..1

Angabe, ob die Daten zur Abfall-Übergabe/Übernahme im Rahmen eines “Begleitschein danach” Ablaufs übermittelt werden (Codeliste 8113).Anmerkung 1: Für einen “Begleitschein danach”-Ablauf ist hier die entsprechende GTIN (9008390117347) aus der Codeliste angegeben. Für gewöhnliche Abläufe gemäß dem vollelektronischen Begleitscheinverfahren entfällt die ProcessTypeID.Anmerkung 2: Die Angabe des “Begleitschein danach”-Ablaufs ist nur innerhalb einer Übernahmemeldung zulässig (siehe SingleDocument/TypeID sowie Datenanforderungen und Prüfregeln).Anmerkung 3: Sofern ein “Begleitschein danach”-Ablauf vorliegt, wird im Element ReasonDescription eine Begründung erwartet (siehe Datenanforderungen und Prüfregeln).

Date

Date

0..1

Datum der Abfall-Übergabe/Übernahme.

DateTime

DateTime

0..1

Zeitpunkt der Abfall-Übergabe/Übernahme.

Description

MultilingualDescription

0..1

Beschreibung bzw. Anmerkungen zur Abfall-Übergabe/Übernahme.Anmerkung: Handelt es sich beim Abfall, der übergeben/übernommen wird, um einen POP-Abfall, dann wird im Beschreibungstext ein Hinweis darauf erwartet (Text “POP-Abfall”).

ReasonID

RelaxedReferenceNoRoleIdentifier

0..*

Auswahl einer Begründung für eine Abfall-Übergabe/Übernahme ohne Transport (Codeliste 8963).Anmerkung: Die Auswahl einer Begründung wird genau dann erwartet, wenn gemäß der Angabe in “TypeID” eine Abfall-Übergabe/Übernahme ohne Transport vorliegt.

ReasonDescription

MultilingualDescription

0..1

Textuelle Begründung für eine Abfall-Übergabe/Übernahme ohne Transport.Anmerkung: Eine textuelle Begründung wird entweder ergänzend zu einer (in “ReasonID” angegebenen) ausgewählten Begründung angegeben, oder alternativ dazu.

DeviatingAssignmentReasonDescription

MultilingualDescription

0..1

Textuelle Begründung für die Zuweisung zu einer Abfallart, die von der zuvor deklarierten Abfallart abweicht, insbesondere bei Korrektur der Abfallart durch den Übernehmer (wenn im Zuge des Empfangs festgestellt wird, dass die tatsächlich in Empfang genommene Abfallart von der erwarteten Abfallart abweicht).Anmerkung: Sofern keine “Korrektur” einer zuvor ausgewiesenen Abfallart vorliegt, wird an dieser Stelle auch keine Begründung erwartet.

Object

TypeAEventObject

0..*

Angaben zum weitergegebenen Abfall (Art und Menge).Anmerkung: Es werden hier Angaben zu GENAU EINER Abfallart und der Menge dieses Abfalls erwartet. Lediglich für Fälle, in welchen im Nachhinein (z.B. beim Empfang der Abfälle) festgestellt wird, dass es sich tatsächlich nicht um EINE Abfallart, sondern um MEHRERE handelt, ist hier die Angabe mehrerer Abfallarten mit den dazugehörigen Mengenangaben vorgesehen (vergleichbar den “Korrekturzeilen” am Papierbegleitschein).

AssociatedObjectReferenceID

RelaxedReferenceRoleIdentifier

0..1

“VEBSV-ID” (Abfall-Übergabe/Übernahme bzw. Beförderungs-ID) (Rolle: “Teil von (untergeordnet)”, GTIN 9008390104576 aus Codeliste 4214; Identifikationsschema: “VEBSV-ID” (EDM), GTIN 9008390104026 aus Codeliste 1756)Anmerkung: Über die sogenannte “VEBSV-ID” (Abfall-Übergabe/Übernahme bzw. Beförderungs-ID) müssen zusammengehörige Angaben zu Abfall-Übergaben/Übernahmen und Abfalltransporten (vor und nach Übergabe/Übernahme bzw. Transport) miteinander in Verbindung gebracht werden. D.h. unterschiedliche Akteure wie Übergeber und Übernehmer haben in ihren jeweiligen Angaben zur selben Abfall-Übergabe/Übernahme bzw. zur selben Abfallbeförderung dieselbe ID zu verwenden. Zur Verwendung der “VEBSV-ID” gibt es in der Schnittstellenbeschreibung einen eigenen Abschnitt.

AssociatedObjectDocumentScopeReferenceID

DocumentScopeRoleReferenceIdentifier

0..*

Angabe der folgenden Bezüge (Rolle: Codeliste 4639):1. Bezug auf Übergeber (Rolle: “Übergeber”; Bezug auf Eintrag aus ListedData/Organization oder ListedData/Person). Jedenfalls benötigte Angabe. Mehrfachangabe nicht zulässig.2. Bezug auf Übernehmer (Rolle: “Übernehmer”; Bezug auf Eintrag aus ListedData/Organization oder ListedData/Person). Jedenfalls benötigte Angabe. Mehrfachangabe nicht zulässig.3. Bezug auf den Absendeort (Rolle: “Beginnstelle”; Bezug auf Eintrag aus ListedData/LocalUnit). Für Übergaben jedenfalls benötigte Angabe, sofern der Übergeber mit dem Abfall physisch in Berührung kommt (kein Streckengeschäft vorliegt).4. Bezug auf den Empfangsort (Rolle: “Endstelle”; Bezug auf Eintrag aus ListedData/LocalUnit). Für Übernahmen jedenfalls benötigte Angabe, sofern der Übernehmer mit dem Abfall physisch in Berührung kommt (kein Streckengeschäft vorliegt).Anmerkung 1: Die Bezugnahme erfolgt jeweils durch Angabe der innerhalb der Dateninstanz zugewiesenen Identifikationszeichenkette, z.B. aus “ListedData/Organization/DocumentScopeAssignmentID” (nicht-natürliche Personen) oder aus “ListedData/Person/DocumentScopeAssignmentID” (natürliche Personen).Anmerkung 2: Für den Absendeort und Empfangsort können jeweils die folgenden Bezüge angegeben werden (für Details siehe Datenanforderungen und Prüfregeln): Standort; Standort + ortsfeste Anlage; Standort + mobile Anlage; Standort + ortsfeste Anlage + mobile Anlage. Dementsprechend kann es Mehrfachangaben zu den Rollen “Beginnstelle” und “Endstelle” geben.Anmerkung 3: Für Übergaben/Übernahmen ohne Transport wird erwartet, dass als Absendeort und Empfangsort jener Ort angegeben wird, an dem sich der Abfall bei der Übergabe/Übernahme befindet.Anmerkung 4: In Übergabedeklarationen und Übergabemeldungen muss der Dateninstanzersteller (siehe EnvironmentalDataEnvelope/Document/DocumentEvent) mit dem Übergeber übereinstimmen. In Übernahmemeldungen muss der Dateninstanzersteller mit dem Übernehmer übereinstimmen. Siehe dazu auch Datenanforderungen und Prüfregeln.

RejectionReasonID

ReferenceIdentifier

0..1

Grund für die Ablehnung der Übergabe bzw. Übernahme (Codeliste 3161).

TypeAEvent

TypeAEventObject

Angaben zum weitergegebenen Abfall.

TypeAEventObject
Name/Typ min..max Definition

TypeID

ReferenceIdentifier

0..1

Art des weitergegebenen Abfalls (Codeliste 5174).Anmerkung 1: In den Angaben zu einer noch nicht erfolgten Abfall-Übergabe/Übernahme wird an dieser Stelle die Abfallart erwartet, für welche die Übergabe/Übernahme VEREINBART wurde. Anmerkung 2: In den Angaben zu einer bereits erfolgten Abfall-Übergabe/Übernahme wird an dieser Stelle die Abfallart erwartet, die TATSÄCHLICH weitergegeben wurde.Anmerkung 3: Angaben zur (ursprünglich) vereinbarten Abfall-Übergabe/Übernahme können von Angaben zur tatsächlichen Abfall-Übergabe/Übernahme abweichen, etwa wenn aufgrund der genaueren Bestimmung des Abfalls am Empfangsort die Zuordnung zu einer anderen Abfallart vorgenommen wird. Aus demselben Grund kann aus der vereinbarten Übergabe/Übernahme EINER Abfallart die tatsächliche Übergabe/Übernahme MEHRERER Abfallarten werden (mehrere “TypeAEventObject”-Instanzen innerhalb von “TypeAEvent”).Anmerkung 4: Handelt es sich beim Abfall, der übergeben/übernommen wird, um einen POP-Abfall, dann wird im Beschreibungstext unter TypeAEvent/Description ein Hinweis darauf erwartet (Text “POP-Abfall”).

SubTypeID

ReferenceIdentifier

0..*

Kontaminationen des weitergegebenen Abfalls (zutreffende Kontaminationsgruppen) (Codeliste 7835).

Description

MultilingualDescription

0..1

Beschreibung des weitergegebenen Abfalls.

PropertyStatement

PropertyStatement

0..1

Masse des weitergegebenen Abfalls.Anmerkung: In den Angaben zu einer noch nicht erfolgten Abfall-Übergabe/Übernahme wird an dieser Stelle die Masse des Abfalls der betreffenden Abfallart erwartet, für welche die Übergabe/Übernahme VEREINBART wurde. In den Angaben zu einer bereits erfolgten Abfall-Übergabe/Übernahme wird an dieser Stelle die Masse des Abfalls der betreffenden Abfallart erwartet, die TATSÄCHLICH weitergegeben wurde. Die im Vorhinein angegebene Masse kann von der im Nachhinein angegebenen Masse abweichen, z.B. aufgrund einer im Zuge des Transports, etwa am Empfangsort, vorgenommenen Verwiegung.

ContainsPersistentOrganicPollutant

Indicator

0..1

PersistentOrganicPollutant (POP) Kennzeichen.

TypeAEventObject

TypeBEvent

Angaben zu einer einzelnen Bewegung eines Transportmittels zur Beförderung von Abfällen.Anmerkung 1: Zu einer Beförderungsbewegung gehören Beladungen und Entladungen. Diese werden separat angegeben (TypeCEvent) und mit der Beförderungsbewegung verknüpft (AssociatedObjectDocumentScopeReferenceID).Anmerkung 2: Im einfachsten Fall gehören zu EINER Beförderungsbewegung EINE Beladung und EINE Entladung. Es kann aber auch komplexere Fälle geben, etwa MEHRERE zu EINER Beförderungsbewegung gehörende Beladungen bei einer sogenannten Sammeltour.Anmerkung 3: Eine einzelne Beförderungsbewegung ist die Bewegung eines Transportmittels von einem ersten Beladeort (ggf. Beladung aus Umladen) bis hin zu einem letzten Entladeort (ggf. Entladen zum Umladen).Beispiel: Wenn ein LKW an einem Tag 4 Mal von A nach B Abfälle transportiert, und dazwischen bzw. danach jeweils leer zum Punkt A zurückfährt, dann liegen 4 einzelne Beförderungsbewegungen vor, jeweils mit Beladeort A und Entladeort B.Anmerkung 4: Im vorliegenden Datenformat ist der Zeitraum der Beförderungsbewegung nicht als eigene Angabe vorgesehen. Vielmehr gibt es den zeitlichen Bezug ausschließlich über die Belade- und Entladezeitpunkte.Anmerkung 5: Die Verknüpfung mit “VEBSV-IDs” (Abfall-Übergabe/Übernahme bzw. Beförderungs-IDs) erfolgt über die einzelnen Beladungen und Entladungen. In den EDM Schnittstellen wird gegenwärtig erwartet, dass sich jede einzelne Transportdeklaration oder andere transportbezogene Dateninstanz auf immer exakt eine “VEBSV-ID” bezieht. Jede Transportdeklaration oder andere transportbezogene Dateninstanz hat sich daher auf genau eine Abfallart zu beziehen, auch dann, wenn in einer Beförderungsbewegung verschiedene Abfallarten (nicht vermischt) gemeinsam transportiert werden. Für Beförderungsbewegungen, bei welchen die Beladung (und Entladung) unterschiedlicher (nicht vermischter) Abfallarten bzw. Güter erfolgt, beschränken sich die Angaben in Transportdeklarationen und anderen transportbezogenen Dateninstanzen auf jene Beladungen und Entladungen, die sich auf eine bestimmte Abfallart (die zur “VEBSV-ID” gehörende Abfallart) beziehen.Anmerkung 6: Wenn sich eine Gesamtbeförderungsbewegung eines Abfalls von einem Absendeort zu einem Empfangsort aus mehreren einzelnen Beförderungsbewegungen zusammensetzt, z.B. Umladungen stattfinden, dann gilt:- Die “zusammengehörigen” einzelnen Beförderungsbewegungen KÖNNEN (müssen aber nicht) gemeinsam (in einem einzigen Datenübermittlungsvorgang) durch dieselbe Person übermittelt werden;- Die “zusammengehörigen” einzelnen Beförderungsbewegungen KÖNNEN (müssen aber nicht) verteilt (auf mehrere Übermittlungszeitpunkte, und/oder auf mehrere Datenübermittler verteilt) übermittelt werden.

TypeBEvent
Name/Typ min..max Definition

DocumentScopeAssignmentID

DocumentScopeAssignmentIdentifier

0..1

In der Dateninstanz für die Beförderungsbewegung verwendeter Identifikator.

PredeterminedScopeAssignmentID

PredeterminedScopeAssignmentIdentifier

0..1

Identifikation der Beförderungs-Bewegung.Anmerkung 1: Es kann an dieser Stelle eine vom Dateninstanz-Ersteller für die Beförderungsbewegung verwendete ID mit übermittelt werden, um etwa bei einer späteren Sichtung oder Kontrolle der übermittelten Daten diese leichter interpretieren und zuordnen zu können. Zwingend benötigt wird die Angabe hingegen nicht.Anmerkung 2: Bei regelmäßig wiederkehrenden Beförderungsbewegungen kann es sich auch um die Identifikation der Serie von Beförderungsbewegungen handeln, und nicht notwendigerweise die Identifikation der einzelnen Beförderungsbewegung (vergleiche Flug-Nummer).

Description

MultilingualDescription

0..1

Beschreibung bzw. Anmerkungen zur Beförderung.

Object

TypeBEventObject

0..1

Angaben zum Transportmittel, z.B. Lastkraftwagen, Zug oder Schiff.

AssociatedObjectDocumentScopeReferenceID

DocumentScopeRoleReferenceIdentifier

0..*

Angabe der folgenden Bezüge (Rolle: Codeliste 5526):1. Bezug auf den Transporteur (Rolle: “Transporteur”; Bezug auf Eintrag aus ListedData/Organization oder ListedData/Person). Jedenfalls benötigte Angabe. Mehrfachangabe nicht zulässig.2. Bezug auf den Veranlasser (Rolle: “Veranlasser”; Bezug auf Eintrag aus ListedData/Organization oder ListedData/Person). Jedenfalls benötigte Angabe. Mehrfachangabe nicht zulässig.Anmerkung 1: Die Bezugnahme erfolgt jeweils durch Angabe der innerhalb der Dateninstanz zugewiesenen Identifikationszeichenkette, z.B. aus “ListedData/Organization/DocumentScopeAssignmentID” (nicht-natürliche Personen) oder aus “ListedData/Person/DocumentScopeAssignmentID” (natürliche Personen).Anmerkung 2: Veranlasser ist derjenige Abfallbesitzer, der den Transport beauftragt.Anmerkung 3: Sofern ein Abfallbesitzer den Transport selbst durchführt, ist dieser Abfallbesitzer sowohl als Transporteur als auch als Veranlasser anzugeben (Bezug auf denselben Eintrag aus ListedData/Organization oder ListedData/Person).

TransportId

UUIDIdentifier

0..1

Beschreibung zur einzigartigen Erkennung eines Transports durch die Transport-ID. Anmerkung: Es muss dieselbe UUID des Transports verwendet werden, wie in Messaging.

AbortReasonID

ReferenceIdentifier

0..1

Angaben zum Transportabbruchgrund, z.B. Ladeverlust oder Ablehnung

TypeBEvent

TypeBEventObject

Angaben zu einem Transportmittel, z.B. Lastkraftwagen oder Schiff.

TypeBEventObject
Name/Typ min..max Definition

PredeterminedScopeAssignmentID

PredeterminedScopeAssignmentIdentifier

0..1

Identifikation des Transportmittels, z.B. Kennzeichen des Lastkraftwagens.

TypeID

ReferenceIdentifier

0..1

Art des Transportmittels, z.B. Straße, Schiene (Codeliste 2939).

Description

MultilingualDescription

0..1

Beschreibung bzw. Anmerkungen zum Transportmittel.

TypeBEventObject

TypeCEvent

Angaben zu Beladungen und Entladungen eines Transportmittels.

TypeCEvent
Name/Typ min..max Definition

DocumentScopeAssignmentID

DocumentScopeAssignmentIdentifier

0..1

In der Dateninstanz für die Beladung bzw. Entladung verwendeter Identifikator.

TypeID

ReferenceIdentifier

0..1

Angabe, ob es sich um eine Beladung oder Entladung handelt (Codeliste 8501).

SubTypeID

ReferenceIdentifier

0..1

Angabe, ob es sich bei der Beladung bzw. Entladung um eine Umladung, z.B. Umschlag, handelt, d.h. an einer Zwischenstation der Übergang von einem Transportmittel auf ein anderes stattfindet. (Codeliste 3789).

Date

Date

0..1

Datum des Transportbeginns.

DateTime

DateTime

0..1

Zeitpunkt des Transportbeginns.

Description

MultilingualDescription

0..1

Beschreibung bzw. Anmerkungen zur Be- bzw. Entladung.

Object

TypeCEventObject

0..1

Angaben zum Abfall, der beladen bzw. entladen wird.

AssociatedObjectReferenceID

RelaxedReferenceRoleIdentifier

0..1

“VEBSV-ID” (ID zum elektronischen Begleitscheinverfahren) (Rolle: “Teil von (untergeordnet)”, GTIN 9008390104576, aus Codeliste 4214; Identifikationsschema: “VEBSV-ID” (EDM), GTIN 9008390104026 aus Codeliste 1756)Anmerkung: Über die sogenannte “VEBSV-ID” (Abfall-Übergabe/Übernahme- bzw. Beförderungs-ID) müssen zusammengehörige Angaben zu Abfall-Übergaben/Übernahmen und Abfalltransporten (vor und nach Übergabe/Übernahme bzw. Transport) miteinander in Verbindung gebracht werden. D.h. unterschiedliche Akteure wie Übergeber und Übernehmer haben in ihren jeweiligen Angaben zur selben Abfall-Übergabe/Übernahme bzw. zur selben Abfallbeförderung dieselbe ID zu verwenden. Zur Verwendung der “VEBSV-ID” gibt es in der Schnittstellenbeschreibung einen eigenen Abschnitt.

AssociatedObjectDocumentScopeReferenceID

DocumentScopeRoleReferenceIdentifier

0..*

Angabe der folgenden Bezüge (Rolle: Codeliste 8076):1. Bezug auf die Bewegung eines Transportmittels zur Beförderung von Abfällen, zu der diese Be- bzw. Entladung gehört (Rolle: “Teil von”; Bezug auf Eintrag aus EnvironmentalData/TypeBEvent). Jedenfalls benötigte Angabe. Mehrfachangabe nicht zulässig.2. Bezug auf den Beladeort bzw. Entladeort (Rolle: “Stelle”; Bezug auf Eintrag aus ListedData/LocalUnit). Jedenfalls benötigte Angabe.3. Bezug auf die Person, die unmittelbar vor der Beladung über den Abfall verfügt, bzw. die unmittelbar im Anschluss an die Entladung über den Abfall verfügt (Rolle: “Verantwortlicher Akteur”, Bezug auf Eintrag aus ListedData/Organization oder ListedData/Person). Jedenfalls benötigte Angabe. Mehrfachangabe nicht zulässig.Anmerkung 1: Die Bezugnahme erfolgt jeweils durch Angabe der innerhalb der Dateninstanz zugewiesenen Identifikationszeichenkette, z.B. aus “ListedData/Organization/DocumentScopeAssignmentID” (nicht-natürliche Personen) oder aus “ListedData/Person/DocumentScopeAssignmentID” (natürliche Personen).Anmerkung 2: Es können mehrere Beladungen zu EINER Beförderung von Abfällen gehören, insbesondere in Zusammenhang mit sogenannten Sammeltouren. Unter den jeweiligen rechtlichen Voraussetzungen kann eine Vermischung im Zuge der Beförderung zulässig sein. Dementsprechend müssen die beladenen Abfallarten nicht notwendigerweise mit den entladenen Abfallarten exakt übereinstimmen.Anmerkung 3: An dieser Stelle wird ausschließlich die “Transportsicht” wiedergegeben. Insbesondere scheinen in dieser Transportsicht bei Streckengeschäften nur jene Übergeber und Übernehmer auf, die mit dem Abfall auch tatsächlich in Berührung kommen. Die Sicht auf die rechtlichen Übergaben/Übernahmen ist hingegen in den Abfall-Übergaben/Übernahmen (EnvironmentalData/TypeAEvent) abgebildet.Anmerkung 4: Beim Umladen, dem Übergang des Abfalls von einem Transportmittel auf ein anderes, ist die Person, die unmittelbar vor der Beladung über den Abfall verfügt, der vorangehende Transporteur, bzw. die Person, die unmittelbar im Anschluss an die Entladung über den Abfall verfügt, der nachfolgende Transporteur. Vorangehender bzw. nachfolgender Transporteur können mit dem aktuellen Transporteur übereinstimmen, müssen aber nicht.

TypeCEvent

TypeCEventObject

Angaben zu einer Menge von Abfall, die beladen bzw. entladen wird.

TypeCEventObject
Name/Typ min..max Definition

TypeID

ReferenceIdentifier

0..1

Art des Abfalls (Codeliste 5174).Anmerkung: In der Transportdeklaration, d.h. in den Angaben zu einem noch nicht erfolgten Transport, wird an dieser Stelle die Abfallart erwartet, für welche die Beladung bzw. Entladung VEREINBART wurde. In der Abfalltransportbeginnmeldung wird an dieser Stelle die Abfallart erwartet, die TATSÄCHLICH beladen bzw. entladen wurde.

SubTypeID

ReferenceIdentifier

0..*

Kontaminationen des Abfalls (zutreffende Kontaminationsgruppen) (Codeliste 7835).

Description

MultilingualDescription

0..1

Beschreibung des Abfalls.

PropertyStatement

PropertyStatement

0..1

Masse des beladenen bzw. entladenen Abfalls.

ContainsPersistentOrganicPollutant

Indicator

0..1

PersistentOrganicPollutant (POP) Kennzeichen.

TypeCEventObject

ValueAssignmentStatement

Eine Aussage darüber, welchen Wert eine Größe annimmt.Beispiel: “2000kg”.

ValueAssignmentStatement
Name/Typ min..max Definition

NumericValue

NumericValue

1..1

Masse in Kombination mit der Masse-Größeneinheit (Größeneinheit: Codeliste 5359).Anmerkung: Im vorliegenden Datenformat sind ausschließlich Masse-Angaben in Kilogramm zulässig (ISO/UCUM-Code “kg”).

ValueAssignmentStatement

Datentypen

AddressComponentDesignation
Name/Typ min..max Definition

AddressComponentDesignation

Token120

1..1

Bezeichnung einer Adresskomponente, z.B. für eine Adresskomponente vom Typ “Straße” der Straßenname, etwa “Wiedner Hauptstraße”.
AssignmentFlexibleIdentifier
AssignmentFlexibleIdentifier
Name/Typ min..max Definition

AssignmentFlexibleIdentifier

[Token64Token64]

1..1

Einem Objekt zugeordneter, in einem bestimmten Kontext eindeutiger, und somit in diesem Kontext für die Objektidentifikation geeigneter Wert. Z.B. eine zu einer Firma angegebene Firmenbuchnummer. Zusätzlich zu dem das Objekt identizierenden Wert (Identifikator) kann die Identifikation der Sammlung von Identifikatoren angegeben werden (z.B. Register oder Codeliste), der der Wert entstammt.

collectionID SimpleToken

0..1

Identifikation der Sammlung von Identifikatoren (z.B. Register oder Codeliste), der der angegebene Wert entstammt.Anmerkung 1: Wenn es sich bei der Sammlung von Identifikatoren um eine Codeliste handelt, dann wird die 4-stellige Codelisten-Nummer als Identifikation der Sammlung von Identifikatoren angegeben. Wenn es sich bei der Sammlung von Identifikatoren um ein Register handelt, dann wird diejenige ID (GTIN), die dem Register in der betreffenden “Register”-Codeliste zugewiesen ist, als Identifikation der Sammlung von Identifikatoren angegeben. Die Identifikation der “Register”-Codeliste selbst, kann und soll in dem Fall, dass es sich bei der identifizierten Sammlung von Identfikatoren um ein Register handelt, nicht angegeben werden!Beispiel: Der Wert “3862” zur Identifikation der Codeliste “Länder”. Etwa die Kombination aus collectionID “3862” und der ID “040” für die Identifikation des Landes Österreich.Beispiel: Die GTIN “9008390104040” zur Identifikation des Österreichischen Firmenbuchs. Etwa die Kombination aus collectionID “9008390104040” und der ID “33393h” für die Identifikation der Firma Palfinger. Anmerkung: Es handelt sich hierbei um ein fiktives Beispiel, die Angabe von Firmenbuchnummern ist im vorliegenden Datenformat nicht vorgesehen.Anmerkung 2: Welche Sammlungen von Identifikatoren zulässigerweise identifiziert werden können, hängt vom Kontext ab, in dem der Datentyp verwendet wird.

collectionDesignation NormalizedString256

0..1

Text, z.B. Name, der Personen dazu dient, die bestimmte Sammlung von Identifikatoren, aus der der angegebene Wert stammt, zu erkennen und von anderen Sammlungen zu unterscheiden, z.B. "Firmenbuch".
AssignmentIdentifier
AssignmentIdentifier
Name/Typ min..max Definition

AssignmentIdentifier

[Token64Token64]

1..1

Einem Objekt zugeordnete, in einem bestimmten Kontext eindeutige, und somit in diesem Kontext für die Objektidentifikation geeignete Zeichenkette. Z.B. eine zu einer Firma angegebene Firmenbuchnummer. Zusätzlich zu der das Objekt identifizierenden Zeichenkette wird eine Identifikation der Sammlung von IDs angegeben.

collectionID SimpleToken

1..1

Identifikation der Sammlung von Identifikatoren (z.B. Register oder Codeliste), der die angegebene Identifikationszeichenkette entstammt.Anmerkung: Wenn es sich bei der Sammlung von Identifikatoren um eine Codeliste handelt, dann wird die 4-stellige Codelisten-Nummer als Identifikation der Sammlung von Identifikatoren angegeben. Wenn es sich bei der Sammlung von Identifikatoren um ein Register handelt, dann wird diejenige ID (GTIN), die dem Register gemäß Codeliste zugewiesen ist, als Identifikation der Sammlung von Identifikatoren angegeben. Die Identifikation der Codeliste selbst kann und soll in diesem Fall nicht angegeben werden.Beispiel: Die GTIN “9008390104026” zur Identifikation des EDM (Elektronisches Datenmanagement in der Umweltwirtschaft), wenn als Identifikationzeichenkette die im EDM zugewiesene GLN (Global Location Number) eines Standorts oder einer Person angegeben wird.

collectionDesignation NormalizedString256

0..1

Bezeichnung der Sammlung, aus der die angegebene Identifikationszeichenkette stammt, z.B. “Firmenbuch”.
Date
Name/Typ min..max Definition

Date

xs:date

1..1

Datum, d.h. Identifikation eines Tages.
DateTime
Name/Typ min..max Definition

DateTime

xs:dateTime

1..1

Zeitpunkt.
DecimalNumeral25Digits
Name/Typ min..max Definition

DecimalNumeral25Digits

xs:decimal

1..1

Wertebereich, zu dem alle dezimalen Numerale gehören, die aus insgesamt maximal 25 Ziffern bestehen, von denen maximal 5 Nachkommastellen sind.
Description
Description
Name/Typ min..max Definition

Description

[String1024String1024]

1..1

Beschreibungstext.

languageID SimpleToken

1..1

Identifikation der Sprache, in der die Beschreibung angegeben ist (Codeliste 7632).
DocumentScopeAssignmentIdentifier
Name/Typ min..max Definition

DocumentScopeAssignmentIdentifier

xs:ID

1..1

In einem Objektkontext angegebener Wert (Identifikator), der innerhalb der Dateninstanz für etwaige Referenzierungen des Objekts verwendet wird.Anmerkung: Für Identifikatoren dieses Typs kann die Eindeutigkeit nur im Dateninstanzkontext vorausgesetzt werden, eine darüber hinausgehende Eindeutigkeit gibt es nicht notwendigerweise. Im Detail bedeutet das: Beim automatisierten ERSTELLEN der Dateninstanz (Serialisierung, z.B. XML-Daten) durch eine Software sind Identifikatoren zu verwenden, die ZUMINDEST innerhalb der Dateninstanz eindeutig sind. Es genügt also beispielsweise das Durchnummerieren der in der Dateninstanz vorkommenden Objekte mit Ganzzahlen {1, 2, …​, n}. Sofern vorhanden eignet sich aber auch die Verwendung von Identifikatoren, die über den Dokumentkontext hinaus eindeutig sind, da diese ebenfalls der Voraussetzung genügen, innerhalb der Dateninstanz eindeutig zu sein. Beispielsweise können für Firmen deren Firmenbuchnummern als dokumentinterne Identifikatoren verwendet werden. Beim EINLESEN und VERARBEITEN eines Dokuments darf jedoch ausschließlich die dateninstanzinterne Eindeutigkeit der Identifikatoren vorausgesetzt werden. Eine über den Dokumentkontext hinausgehende Verwendbarkeit der Identifikatoren darf nicht angenommen werden!
DocumentScopeReferenceIdentifierContent
Name/Typ min..max Definition

DocumentScopeReferenceIdentifierContent

xs:IDREF

1..1

Referenzierung eines Objekts mittels eines an anderer Stelle im Dokument dem Objekt zugewiesenen im Dokumentkontext gültigen Identifikators.
DocumentScopeRoleReferenceIdentifier
DocumentScopeRoleReferenceIdentifier
Name/Typ min..max Definition

DocumentScopeRoleReferenceIdentifier

[DocumentScopeReferenceIdentifierContentDocumentScopeReferenceIdentifierContent]

1..1

Referenzierung eines Objekts mittels eines an anderer Stelle im Dokument dem Objekt zugewiesenen, im Dokumentkontext gültigen, Identifikators. Zusätzlich muss die Rolle des identifizierten Objekts im Kontext des referenzierenden Objekts angegeben werden.

roleID SimpleToken

1..1

Identifikation der Rolle des Objekts, auf das Bezug genommen wird, im Kontext der Bezugnahme.Anmerkung: Welche Rollen zulässigerweise angegeben werden können, hängt vom Kontext ab, in dem der Datentyp verwendet wird.

roleDesignation NormalizedString256

0..1

Bezeichnung der Rolle des Objekts, auf das Bezug genommen wird.Beispiel: Als Rolle einer nicht-natürlichen Person im Kontext einer Tätigkeit kann “Verantwortlicher Akteur” angegeben werden.Anmerkung 1: Dieses Attribut steht für Entwicklungs- und Testphasen zur Verfügung. Mit der Verwendung dieses Attributs kann die unmittelbare Lesbarkeit (durch Entwickler, Tester, usw.) von generierten XML-Instanzen erhöht werden. Für den (Produktiv-)Datenaustausch spielt dieses Attribut keine Rolle.Anmerkung 2: Siehe auch Abschnitt “Identifikationszeichenketten und natürlichsprachige Angaben” im Datenformatbeschreibungsdokument.

objectTypeName Token50

0..1

Bezeichnung der Klasse von Objekten, aus der das Objekt, auf das Bezug genommen wird, stammt.Beispiel: Wird auf ein Unternehmen Bezug genommen, so ist als Bezeichnung der Klasse von Objekten “Unternehmen” naheliegend.Anmerkung: Welche Arten von Objekten zulässigerweise referenziert werden können, hängt vom Kontext ab, in dem der Datentyp verwendet wird.

objectDesignation NormalizedString256

0..1

Bezeichnung des Objekts, auf das Bezug genommen wird.Beispiel: Der Name einer Firma, etwa “Bastrein GmbH”.Anmerkung: Dieses Attribut steht für Entwicklungs- und Testphasen zur Verfügung. Mit der Verwendung dieses Attributs kann die unmittelbare Lesbarkeit (durch Entwickler, Tester, usw.) von generierten XML-Instanzen erhöht werden. Für den (Produktiv-)Datenaustausch spielt dieses Attribut keine Rolle.
FamilyNameText
Name/Typ min..max Definition

FamilyNameText

Token40

1..1

Familienname.
GivenNameText
Name/Typ min..max Definition

GivenNameText

Token40

1..1

Vorname.
Indicator
Name/Typ min..max Definition

Indicator

xs:boolean

1..1

Ja/Nein-Wert (Ja: Eigenschaft trifft zu; Nein: Eigenschaft trifft nicht zu).
LongNameText
Name/Typ min..max Definition

LongNameText

Token120

1..1

Name.
NormalizedString256
Name/Typ min..max Definition

NormalizedString256

xs:normalizedString

1..1

Wertebereich, zu dem alle normalisierten Zeichenketten gehören, die aus maximal 256 Zeichen bestehen. Ausnahme: Die aus 0 Zeichen bestehende Zeichenkette.Anmerkung: Eine normalisierte Zeichenkette ist eine Zeichenkette, die weder Carriage Return (#xD), Line Feed (#xA) noch Tabulatur (#x9) Zeichen enthält.
NumericValue
NumericValue
Name/Typ min..max Definition

NumericValue

[DecimalNumeral25DigitsDecimalNumeral25Digits]

1..1

Zahlenwert für eine Größenangabe.Anmerkung: Zusätzlich zum Zahlenwert selbst ist die Angabe des Bezugs auf eine Größeneinheit erforderlich. Siehe “unitID”.

unitID Token64

1..1

Bezug auf die für die Größenangabe verwendete Größeneinheit.
PredeterminedScopeAssignmentIdentifier
PredeterminedScopeAssignmentIdentifier
Name/Typ min..max Definition

PredeterminedScopeAssignmentIdentifier

[Token64Token64]

1..1

Einem Objekt zugeordneter, in einem bestimmten Kontext eindeutiger, und somit in diesem Kontext für die Objektidentifikation geeigneter Wert. Der Kontext der Vergabe, Zuweisung und Gültigkeit des Identifikators wird nicht explizit deklariert, sondern bei jeder Verwendung des Datentyps individuell vorgegeben.Beispiel: Kennzeichen eines Lastkraftwagens.
PredeterminedScopeReferenceIdentifier
PredeterminedScopeReferenceIdentifier
Name/Typ min..max Definition

PredeterminedScopeReferenceIdentifier

[Token64Token64]

1..1

Bezugnahme auf ein Objekt durch Angabe einer dem Objekt zugeordneten Identifikationszeichenkette.Beispiel: Bezugnahme auf eine Website durch Angabe der Website-Adresse (URL).Anmerkung: Die Sammlung von Identifikationszeichenketten, aus der die angegebene Identifikationszeichenkette stammt, wird nicht ausgewiesen, sondern ist durch den Kontext vorbestimmt: Im Falle von Website-Adressen braucht beispielsweise nicht explizit ausgewiesen zu werden, dass es sich um eine durch IANA/ICANN-akkreditierte Registrare registrierte URL handelt. Gleiches gilt beispielsweise für Telefonnummern, Faxnummern, E-Mail-Adressen und Hausnummern.
ReferenceIdentifier
ReferenceIdentifier
Name/Typ min..max Definition

ReferenceIdentifier

[SimpleTokenSimpleToken]

1..1

Bezugnahme auf ein Objekt durch Angabe einer dem Objekt zugeordneten Identifikationszeichenkette.Beispiel: Bezugnahme auf eine Abfallart durch Angabe einer GTIN (Global Trade Item Number).Anmerkung: Zusätzlich zur Identifikationszeichenkette wird die ID jener Sammlung (z.B. Register oder Codeliste, etwa Abfallverzeichnis) angegeben, aus der die Identifikationszeichenkette stammt.Anmerkung: Auf welche Objekte zulässigerweise Bezug genommen werden kann, hängt vom Kontext ab, in dem der Datentyp verwendet wird.

collectionID SimpleToken

1..1

Identifikation der Sammlung (z.B. Register oder Codeliste), aus der die angegebene Identifikationszeichenkette stammt.Beispiel: Die vierstellige Nummer “3862” zur Identifikation der Codeliste “Länder”.

collectionDesignation NormalizedString256

0..1

Bezeichnung der Sammlung, aus der die angegebene Identifikationszeichenkette stammt.Beispiel: Sollte ein Eintrag aus Codeliste 3862 (“Länder”) referenziert werden, so ist als Sammlungsbezeichnung der Name der Codeliste, “Länder”, naheliegend.Anmerkung: Aus welchen Sammlungen von Identifikatoren das referenzierte Objekt zulässigerweise stammen kann, hängt vom Kontext ab, in dem der Datentyp verwendet wird.

objectDesignation NormalizedString256

0..1

Bezeichnung des Objekts, auf das Bezug genommen wird.Beispiel: Wird auf Finnland Bezug genommen, dann kann das wie folgt geschehen: Als Identifikationszeichenkette wird “246” eingetragen (dabei handelt es sich um den ISO 3166-1 Code von Finnland), als Identifikation der Sammlung “3862” (das ist die vierstellige Nummer der EDM-“Länder”-Codeliste), und als Objektbezeichnung “Finnland”.
RelaxedReferenceNoRoleIdentifier
RelaxedReferenceNoRoleIdentifier
Name/Typ min..max Definition

RelaxedReferenceNoRoleIdentifier

[Token64Token64]

1..1

Referenzierung eines Objekts durch Angabe eines dem Objekt zugeordneten Identifikators, z.B. Referenzierung einer Abfallart durch eine GTIN (Global Trade Item Number). Zusätzlich zum Objekt-Identifkator wird die Identifikation der Sammlung von Identifikatoren (z.B. Register oder Codeliste, etwa Abfallverzeichnis) benötigt, der der Identifikator entstammt.Anmerkung: Aus welchen Sammlungen von Identifikatoren das referenzierte Objekt zulässigerweise stammen kann, hängt vom Kontext ab, in dem der Datentyp verwendet wird.Anmerkung: Der Datentyp “RelaxedReferenceNoRoleIdentifier” entspricht “ReferenceNoRoleIdentifier”, besitzt aber im Vergleich zu diesem einen erweiterten, weniger restriktiven Wertebereich.

collectionID SimpleToken

1..1

Identifikation der Sammlung von Identifikatoren (z.B. Register oder Codeliste), der der angegebene Objekt-Identifikator entstammt.Beispiel: Der Wert “3862” zur Identifikation der Codeliste “Länder”.Anmerkung: Welche Sammlungen von Identifikatoren zulässigerweise identifiziert werden können, hängt vom Kontext ab, in dem der Datentyp verwendet wird.

collectionDesignation NormalizedString256

0..1

Text, z.B. Name, der Personen dazu dient, die bestimmte Sammlung von Identifikatoren, aus der der angegebene Objekt-Identifikator stammt, zu erkennen und von anderen Sammlungen zu unterscheiden.Beispiel: Sollte ein Eintrag aus Codeliste 3862 (“Länder”) referenziert werden, so ist als Sammlungserkennungstext der Name der Codeliste, “Länder”, naheliegend.Anmerkung: Aus welchen Sammlungen von Identifikatoren das referenzierte Objekt zulässigerweise stammen kann, hängt vom Kontext ab, in dem der Datentyp verwendet wird.

objectDesignation NormalizedString256

0..1

Text, z.B. Name, der Personen dazu dient, das referenzierte Objekt zu erkennen und von anderen Objekten zu unterscheiden.Beispiel: Sollte etwa jener Eintrag aus der Codeliste 3862 (“Länder”) referenziert werden, der die Identifikation “246” trägt, dann wäre als Objekterkennungstext der aus der Codeliste stammende Name des Landes, “Finnland”, naheliegend.Anmerkung: Aus welchen Sammlungen von Identifikatoren das referenzierte Objekt zulässigerweise stammen kann, hängt vom Kontext ab, in dem der Datentyp verwendet wird.
RelaxedReferenceRoleIdentifier
RelaxedReferenceRoleIdentifier
Name/Typ min..max Definition

RelaxedReferenceRoleIdentifier

[Token64Token64]

1..1

Referenzierung eines Objekts durch Angabe eines dem Objekt zugeordneten Identifikators, z.B. Referenzierung einer Abfallart durch eine Abfallschlüsselnummer. Zusätzlich zum Objekt-Identifkator wird die Identifikation der Sammlung von Identifikatoren (z.B. Register oder Codeliste, etwa Abfallverzeichnis) benötigt, der der Identifikator entstammt. Zusätzlich kann optional die Rolle des identifizierten Objekts im Kontext des referenzierenden Objekts angegeben werden.Anmerkung: Aus welchen Sammlungen von Identifikatoren das referenzierte Objekt zulässigerweise stammen kann, hängt vom Kontext ab, in dem der Datentyp verwendet wird.Anmerkung: Der Datentyp “RelaxedReferenceRoleIdentifier” entspricht “ReferenceRoleIdentifier”, besitzt aber im Vergleich zu diesem einen erweiterten, weniger restriktiven Wertebereich.

roleID SimpleToken

1..1

Identifikation der Rolle des referenzierten Objekts im Kontext des referenzierenden Objekts.Beispiel: Handelt es sich beim referenzierenden Objekt um ein Dokument, und beim referenzierten Objekt um eine Person, kann über die Rolle angegeben werden, ob es sich bei der Person um den Ersteller, Versender, Empfänger, usw. des Dokuments handelt.Anmerkung: Welche Rollen zulässigerweise angegeben werden können, hängt vom Kontext ab, in dem der Datentyp verwendet wird.

roleDesignation NormalizedString256

0..1

Text, z.B. Name, der Personen dazu dient, die Rolle des referenzierten Objekts zu erkennen und von anderen Rollen zu unterscheiden.Beispiel: Handelt es sich beim referenzierenden Objekt um eine Betriebsstätte, und beim referenzierten Objekt um ein Unternehmen, so könnte der Rollenerkennungstext “Betreiber” lauten.Anmerkung: Welche Rollen zulässigerweise angegeben werden können, hängt vom Kontext ab, in dem der Datentyp verwendet wird.

collectionID SimpleToken

1..1

Identifikation der Sammlung von Identifikatoren (z.B. Register oder Codeliste), der der angegebene Objekt-Identifikator entstammt.Beispiel: Der Wert “3862” zur Identifikation der Codeliste “Länder”.Anmerkung: Welche Sammlungen von Identifikatoren zulässigerweise identifiziert werden können, hängt vom Kontext ab, in dem der Datentyp verwendet wird.

collectionDesignation NormalizedString256

0..1

Text, z.B. Name, der Personen dazu dient, die bestimmte Sammlung von Identifikatoren, aus der der angegebene Objekt-Identifikator stammt, zu erkennen und von anderen Sammlungen zu unterscheiden.Beispiel: Sollte ein Eintrag aus Codeliste 3862 (“Länder”) referenziert werden, so ist als Sammlungserkennungstext der Name der Codeliste, “Länder”, naheliegend.Anmerkung: Aus welchen Sammlungen von Identifikatoren das referenzierte Objekt zulässigerweise stammen kann, hängt vom Kontext ab, in dem der Datentyp verwendet wird.

objectDesignation NormalizedString256

0..1

Text, z.B. Name, der Personen dazu dient, das referenzierte Objekt zu erkennen und von anderen Objekten zu unterscheiden.Beispiel: Sollte etwa jener Eintrag aus der Codeliste 3862 (“Länder”) referenziert werden, der die Identifikation “246” trägt, dann wäre als Objekterkennungstext der aus der Codeliste stammende Name des Landes, “Finnland”, naheliegend.Anmerkung: Aus welchen Sammlungen von Identifikatoren das referenzierte Objekt zulässigerweise stammen kann, hängt vom Kontext ab, in dem der Datentyp verwendet wird.
SimpleToken
Name/Typ min..max Definition

SimpleToken

xs:token

1..1

Wertebereich, zu dem alle aus maximal 64 Zeichen bestehenden Zeichenketten gehören, die ausschließlich aus den Klein- und Großbuchstaben A-Z, den Ziffern 0-9, sowie dem Dash und/oder Underscore-Zeichen bestehen, und die nicht mit dem Dash bzw. Underscore-Zeichen beginnen oder enden. Ausnahme: Die aus 0 Zeichen bestehende Zeichenkette.
String1024
Name/Typ min..max Definition

String1024

xs:string

1..1

Wertebereich, zu dem alle aus maximal 1024 Zeichen bestehenden Zeichenketten gehören. Ausnahme: Die aus 0 Zeichen bestehende Zeichenkette.
Token120
Name/Typ min..max Definition

Token120

xs:token

1..1

Wertebereich, zu dem alle Token bestehend aus maximal 120 Zeichen gehören. Ausnahme: Die aus 0 Zeichen bestehende Zeichenkette.Anmerkung: Ein Token ist eine Zeichenkette, die weder Carriage Return (#xD), Line Feed (#xA) noch Tabulator (#x9) Zeichen enthält, die nicht mit Leerzeichen (#x20) beginnt oder endet, und die keine Folge von zwei oder mehr aufeinanderfolgenden Leerzeichen enthält
Token40
Name/Typ min..max Definition

Token40

xs:token

1..1

Wertebereich, zu dem alle Token bestehend aus maximal 40 Zeichen gehören. Ausnahme: Die aus 0 Zeichen bestehende Zeichenkette.Anmerkung: Ein Token ist eine Zeichenkette, die weder Carriage Return (#xD), Line Feed (#xA) noch Tabulator (#x9) Zeichen enthält, die nicht mit Leerzeichen (#x20) beginnt oder endet, und die keine Folge von zwei oder mehr aufeinanderfolgenden Leerzeichen enthält
Token50
Name/Typ min..max Definition

Token50

xs:token

1..1

Wertebereich, zu dem alle Token bestehend aus maximal 50 Zeichen gehören. Ausnahme: Die aus 0 Zeichen bestehende Zeichenkette.Anmerkung: Ein Token ist eine Zeichenkette, die weder Carriage Return (#xD), Line Feed (#xA) noch Tabulator (#x9) Zeichen enthält, die nicht mit Leerzeichen (#x20) beginnt oder endet, und die keine Folge von zwei oder mehr aufeinanderfolgenden Leerzeichen enthält
Token64
Name/Typ min..max Definition

Token64

xs:token

1..1

Wertebereich, zu dem alle Token bestehend aus maximal 64 Zeichen gehören. Ausnahme: Die aus 0 Zeichen bestehende Zeichenkette.Anmerkung: Ein Token ist eine Zeichenkette, die weder Carriage Return (#xD), Line Feed (#xA) noch Tabulator (#x9) Zeichen enthält, die nicht mit Leerzeichen (#x20) beginnt oder endet, und die keine Folge von zwei oder mehr aufeinanderfolgenden Leerzeichen enthält
UUIDIdentifier
Name/Typ min..max Definition

UUIDIdentifier

xs:string

1..1

Beim initialen Erstellen der elektronischen Logistikeinheits-Dateninstanz automatisch zugewiesene UUID (Universally Unique Identifier).

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. Nicht jede Datenanforderung wird notwendigerweise durch eine Prüfregel geprüft.

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

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).