	PACK_DEPOSIT_REFUND v0.02

	Copyright (C) 2025 Environment Agency Austria
	Contact: edm-helpdesk@umweltbundesamt.at

	Commissioned by the Austrian Federal Ministry of Environment (BMK)

	Licensed under the EUPL, Version 1.2 or – as soon they will be approved
	by the European Commission – subsequent versions of the EUPL (the "Licence");

	You may not use this work except in compliance with the Licence.

	You may obtain a copy of the Licence at: http://joinup.ec.europa.eu/software/page/eupl

	Unless required by applicable law or agreed to in writing, work distributed under the licence is distributed
	on an "AS IS" basis, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.

	See the Licence for the specific language governing permissions and limitations under the Licence.

Online-Veröffentlichung

Die jeweils aktuelle Version der Schnittstellenspezifikation ist online unter Getränkeverpackungen Einwegpfand Webservice Beschreibung verfügbar.

Notation

Diese Spezifikation verwendet die in Definitionen und Verweise definierten Begriffe und Akronyme und basiert auf den dort aufgeführten technischen Standards und rechtlichen Vorgaben.

Inhalt und Zweck der Schnittstellenbeschreibung

In Umsetzung von Unionsrecht, insbesondere EU-Verpackungsrichtlinie [PPWD] und EU-Einwegkunsttoffrichtlinie [SUPD], sehen das österreichische Abfallwirtschaftsgesetz 2002 [AWG 2002] und die österreichische Pfandverordnung für Einweggetränkeverpackungen [PfandVO] für 2025 die Einführung eines Pfandsystems für Einweggetränkeverpackungen aus Kunststoff oder Metall vor. Die Verordnung zielt darauf ab, die Rücknahme und das Recycling von Einweggetränkeverpackungen zu fördern und höhere Sammelquoten sowie in Folge Recyclingquoten zu erreichen.

Im 3. Abschnitt sieht die [PfandVO] die Einrichtung einer zentralen Stelle vor, die wesentliche Aufgaben in Zusammenhang mit der Organisation und Durchführung des Pfandsystems übernimmt. Bei dieser zentralen Stelle handelt es sich um die EWP Recycling Pfand Österreich gGmbH, https://www.recycling-pfand.at/.

Gemäß § 24 Abs. 1 der [PfandVO] übermittelt die zentrale Stelle dem BMK jährlich Daten zu bepfandeten Einweggetränkeverpackungen, insbesondere zur Inverkehrsetzung, zur Zurücknahme, zum Recycling, sowie zu dem bei der Herstellung eingesetzten Recyclat.

Für diese jährlichen Übermittlungen hat das BMK im EDM, https://edm.gv.at/, als Teil der Anwendung Verpackung das EDM Getränkeverpackungen Einwegpfand Webservice eingerichtet.

Die vorliegende Schnittstellenbeschreibung ist als Bedienungsanleitung für dieses Webservice zu verstehen. Sie beschreibt die über das Webservice angebotene Funktionalität und wie diese genutzt werden kann.

Zielgruppe der Schnittstellenbeschreibung

Das Dokument richtet sich in erster Linie an solche IT-Analytiker und Entwickler, die für die zentrale Stelle mit der Umsetzung der jährlichen Übermittlungen gemäß § 24 Abs. 1 der [PfandVO] an das BMK befasst sind.

Zusätzlich kann das Dokument auch von Umwelt- und Abfallwirtschaft Fachpersonal genutzt werden, um genauen Aufschluss über Art und Struktur der über das Webservice übermittelten Daten zu erlangen.

Verwendung der Schnittstellenbeschreibung

Die Schnittstellenbeschreibung ist für die Verwendung in Kombination mit den anderen Dateien aus dem Schnittstellenspezifikations-Paket vorgesehen, insbesondere mit den darin enthaltenen [XSD]- und [WSDL]-Dateien, sowie mit den [XML]-Beispiel-Dateninstanzen. Siehe Dateien und Ordner im Spezifikationspaket.

Kontakt

Für Auskünfte zur Schnittstelle steht der EDM Helpdesk zur Verfügung. Den EDM Helpdesk erreichen Sie unter der E-Mail-Adresse edm-helpdesk@umweltbundesamt.at.

Das Portal edm.gv.at enthält im öffentlich zugänglichen Bereich unter Helpdesk weitere Informationen zur Kontaktaufnahme mit dem EDM Helpdesk.

Genutzte Standards und Technologien

[HTTP]/1.1

Alle Interaktionen zwischen Webservice-Client und Webservice folgen dem [HTTP]/1.1 Protokoll. Insbesondere muss der Webservice-Client Webservice-Operationen als [HTTP] Request mit der [HTTP] POST Methode aufrufen, und dabei bestimmte Informationen als [HTTP] Header übermitteln.

[Schematron]

Zur Schnittstellenspezifikation zählt ein Set von regelbasierten Datenprüfungen, welche dabei unterstützen, hinterfragenswerte und überprüfenswerte Datenkonstellationen zu identifizieren. Das Getränkeverpackungen Einwegpfand Webservice wendet diese Prüfungen bei der Datenübermittlung ans BMK automatisch an und liefert ein Prüfprotokoll. Schematron ist ein [XML]- und [XSLT]-basierter Standard zum Spezifizieren (Schreiben/Ausdrücken) und Anwenden regelbasierter Prüfungen.

[TLS] 1.2+

Das Webservice benötigt [TLS] 1.2 oder höher für die Client-Service-Kommunikation. Dies gewährleistet Vertraulichkeit, Integrität und Authentizität. Es handelt sich um dasselbe Verschlüsselungsprotokoll, das auch beim Browsen sicherer Websites (https) zum Einsatz kommt.

[XML] 1.0

An die Behörde übermittelte Daten müssen der XML 1.0 Syntax entsprechen, damit die Schnittstelle sie verarbeiten kann. XML-Dateien sind Textdateien zur Abbildung und zum Austausch strukturierter Daten. Die Auszeichnung bzw. Kennzeichnung der strukturierten Daten in der Textdatei ist sowohl für die maschinelle Verarbeitung gut geeignet, als auch für das die Lesbarkeit durch Menschen.

[XSD] 1.0

Übermittelte Daten müssen eine bestimmte per XSD spezifizierte XML-Struktur aufweisen, damit die Schnittstelle sie verarbeiten kann. Konkret müssen übermittelte Daten bezüglich der im Spezifikationspaket enthaltenen pack_deposit_refund-XSD-Dateien gültig sein, damit die Schnittstelle sie verarbeiten kann. XSD ist ein Standard zur Definition der Struktur und der Datentypen von XML-Dateninstanzen. Bei der Umsetzung einer Anbindung an das Getränkeverpackungen Einwegpfand Webservice kann die im Spezifikationspaket enthaltene XSD-Datei mit Werkzeugen wie XMLSpy, www.altova.com/de/xmlspy-xml-editor, zur Validierung von XML-Instanzen noch vor Übermittlung an das Webservice genutzt werden, und mit Frameworks wie JAXB (Jakarta XML Binding), jakarta.ee/specifications/xml-binding/, für das Generieren und Parsen von XML-Instanzen.

[UTF-8]

Das Getränkeverpackungen Einwegpfand Webservice liefert alle Operations-Outputs in [UTF-8] Zeichenkodierung und erwartet alle Operations-Inputs in [UTF-8] Zeichenkodierung. [UTF-8] ist ein Standard zur Codierung von Zeichenfolgen als Bytefolgen. Der Abschnitt Zeichenkodierung UTF-8 und Unicode-Blocks enthält nähere Informationen dazu, worauf in der Umsetzung einer Webservice-Anbindung i.Z. mit der Zeichenkodierung zu achten ist.

[WSDL] 2.0

Diese Schnittstellenspezifikation verwendet [WSDL] für die formale Definition der Webservice-Operationen mit deren Inputs und Outputs. Innerhalb der [WSDL]-Spezifikation kommt [XSD] für die Definition der [XML]-Datenformate von Operations-Inputs und -Outputs zum Einsatz. Bei der Umsetzung einer Anbindung an das Getränkeverpackungen Einwegpfand Webservice kann die im Spezifikationspaket enthaltene [WSDL]-Spezifikation etwa dafür verwendet werden, mit einem Werkzeug wie SoapUI, www.soapui.org/, automatisiert Beispiel-Requests an das Webservice zu generieren und diese auszuführen.

Zur Erzielung hoher Interoperabilität orientieren sich die Datenstrukturen inklusive Bezeichnungen und Wertebereichen an Standards und Empfehlungen zum Electronic Data Interchange (EDI) wie der UN/CEFACT Core Component Library.

Dateien und Ordner im Spezifikationspaket

Dateien und Ordner

Name	Size	Modified
xml_example_msg	—	2025-02-04 14:25
xml_example_service_input_output	—	2025-02-04 14:25
z_descr_img	—	2025-02-04 14:25
z_val_a_xml_example_msg_base	—	2025-02-04 14:25
z_val_b_xml_example_msg_ruletest	—	2025-02-04 14:25
z_val_c_results	—	2024-09-09 13:17
pack_deposit_refund_doc.html	542 KB	2025-02-04 14:25
pack_deposit_refund_formalvalidationrules.sch	86 KB	2025-02-04 14:20
pack_deposit_refund_formalvalidationrules.xsl	191 KB	2025-02-04 14:20
pack_deposit_refund_message.xsd	20 KB	2025-02-04 14:19
pack_deposit_refund_validationrules_doc.html	53 KB	2025-02-04 14:25
pack_deposit_refund_webservice.wsdl	3 KB	2025-02-04 14:19
pack_deposit_refund_webservice_types.xsd	2 KB	2025-02-04 14:19
svrl.xsd	6 KB	2025-02-04 14:19

Erläuterungen

xml_example_msg/

Enthält für jede der im Getränkeverpackungen Einwegpfand Webservice genutzten Message-Arten genau eine Beispiel-Message.

Die Ausgestaltung dieser Beispiel-Messages orientiert sich vor allem an den folgenden beiden Kriterien:

1. Die Beispiele beinhalten Daten, die zwar einerseits fiktiv (erfunden, willkürlich festgelegt) sind, aber andererseits Ähnlichkeiten mit in der Praxis tatsächlich auftretenden Daten besitzen;
2. Die Beispiele nutzen möglichst viele der XML-Datenelemente, um deren Verwendung zu illustrieren.

xml_example_service_input_output/

Enthält für jede Operation des Getränkeverpackungen Einwegpfand Webservice genau einen Beispiel-Input und Beispiel-Output. Enthält zudem einen Beispiel-[SOAP]-Fault.

z_descr_img/

Für die Ordner, deren Namen mit "z_" beginnt, ist es für gewöhnlich nicht sinnvoll, diese einzeln durchzusehen. Vielmehr verlinkt die HTML-Schnittstellenbeschreibung auf Inhalte dieser Ordner.

Der Ordner z_descr_img enthält die in der Beschreibung pack_deposit_refund_doc.html verwendeten Bilddateien.

z_val_a_xml_example_msg_base/; z_val_b_xml_example_msg_ruletest/; z_val_c_results/

Die Dateien in diesen Ordnern besitzen eine Bedeutung in Zusammenhang mit den zur Spezifikation gehörenden formalen Prüfungen, für die das Spezifikationspaket eine Spezikation per [Schematron]-Datei pack_deposit_refund_formalvalidationrules.sch enthält. Der Abschnitt Formale Prüfungen enthält Links zu den Inhalten dieser Ordner.

Der Ordner z_val_a_xml_example_msg_base/ enthält Beispiel-Input für die formalen Prüfungen. Dabei handel es sich um die Beispiel-Messages aus dem Ordner xml_example_msg/, angereichert um sogenannten ValidationContext. Beim ValidationContext handelt es sich um auf Empfängerseite zu einer empfangenen Message ausgelesenen Daten, z.B. Unternehmens-Stammdaten, Referenzdaten, oder Daten aus zuvor übermittelten Messages. Für die im Ordner z_val_a_xml_example_msg_base/ enthaltenen Dateien gilt, dass sowohl Message-Inhalte als auch ValidationContext fiktive Daten enthalten. Der Ordner z_val_a_xml_example_msg_base/ enthält solchen Beispiel-Input, der allen formalen Prüfungen genügt, also keine Prüfprotokolleinträge auslöst.

Der Ordner z_val_a_xml_example_msg_ruletest/ enthält ebenfalls Beispiel-Input für die formalen Prüfungen. Es handelt sich hierbei um Modifikationen der Beispieldateien aus z_val_a_xml_example_msg_base/, die so ausgestaltet sind, dass sie bestimmte formale Prüfungen auslösen bzw. nicht auslösen.

Der Ordner z_val_c_results/ enthält die Ergebnisse der Anwendung der per [Schematron]-Datei pack_deposit_refund_formalvalidationrules.sch definierten formalen Prüfungen auf die [XML]-Beispieldateien aus den beiden Ordnern z_val_a_xml_example_msg_base/ und z_val_a_xml_example_msg_ruletest/. Die Ergebnisse liegen jeweils im Schematron Validation Report Language (SVRL) [XML]-Datenformat vor, sowie einer daraus aufbereiteten [HTML]-Darstellung.

Der Abschnitt Formale Prüfungen bietet anhand einer Zusammenstellung der Prüfergebnisse aus z_val_c_results/ einen Überblick über die per [Schematron]-Datei pack_deposit_refund_formalvalidationrules.sch spezifizierten formalen Prüfungen.

pack_deposit_refund_doc.html

Die vorliegende Schnittstellenbeschreibung, d.h. die Anleitung zur Verwendung der Schnittstelle.

pack_deposit_refund_formalvalidationrules.sch

„Quelltext“ der für das Getränkeverpackungen Einwegpfand Webservice definierten formalen Prüfungen in der formalen Sprache [Schematron]. Die Umweltbundesamt GmbH als Autorin der Schnittstellenspezifikation hat die im Spezifikationspaket ebenfalls enthaltene Datei pack_deposit_refund_formalvalidationrules.xsl aus diesem Quelltext mittels [SchXslt] generiert.

Durch die Bereitstellung dieses „Quelltexts“ sind die formalen Prüfungen, welche das Getränkeverpackungen Einwegpfand Webservice auf Übermittlungen an die Behörde anwendet, offen und transparent. So kann beispielsweise IT-Personal, das an einer Webservice Anbindung arbeitet, beim Verdacht auf fehlerhafte Spezifikation einer formalen Prüfung den [Schematron]-Quelltext der Prüfregel nach Fehlern durchsuchen.

pack_deposit_refund_formalvalidationrules.xsl

[XSLT]-Instanz, mit der das Getränkeverpackungen Einwegpfand Webservice Übermittlungen an die Behörde formalen Prüfungen unterzieht. Dazu reichert das Getränkeverpackungen Einwegpfand Webservice eine empfangene Message zunächst mit einem ValidationContext an - das sind auf Webservice- bzw. Empfänger-Seite ausgelesene Daten - und unterzieht diese "angereicherte Message" der Transformation aus pack_deposit_refund_formalvalidationrules.xsl. Diese Transformation liefert das Prüfprotokoll im SVRL-Format, welches das Getränkeverpackungen Einwegpfand Webservice als Teil von Signal Messages an die Webservice-Clients ausliefert.

Die Umweltbundesamt GmbH als Autorin der Schnittstellenspezifikation hat pack_deposit_refund_formalvalidationrules.xsl aus dem im Spezifikationspaket ebenfalls enthaltenen Quelltext pack_deposit_refund_formalvalidationrules.sch mittels [SchXslt] generiert.

pack_deposit_refund_message.xsd

Definiert die im Getränkeverpackungen Einwegpfand Webservice genutzten [XML]-Message-Formate unter Verwendung der formalen Sprache [XSD]. Bei der Übermittlung von Messages an die Behörde validiert das Getränkeverpackungen Einwegpfand Webservice empfangene Messages als Teil der Validierung von Operations-Inputs, d.h. es überprüft, ob empfangene Messages bezüglich der in pack_deposit_refund_message.xsd definierten Message-Formate gültig sind. Eine solche Gültigkeit ist eine technische Voraussetzung dafür, dass das Webservice die übermittelte Message verarbeiten kann.

Umgekehrt kann sich an das Getränkeverpackungen Einwegpfand Webservice angebundene Software darauf verlassen (bzw. dies auch validieren), dass die in Operations-Outputs ausgelieferten Messages bezüglich der in pack_deposit_refund_message.xsd definierten [XML]-Message-Formate gültig sind.

Der Abschnitt Message-Formate beschreibt die in pack_deposit_refund_message.xsd definierten [XML]-Strukturen im Detail.

Besitzt eine Abhängigkeit zu svrl.xsd, da SVRL-Prüfprotokolle als Teil der vom Webservice zurückgelieferten Signal Messages auftreten.

pack_deposit_refund_webservice_types.xsd

Definiert die [XML]-Formate für die Inputs und Outputs der Getränkeverpackungen Einwegpfand Webservice Operationen unter Verwendung der formalen Sprache [XSD]. Besitzt eine direkte Abhängigkeit zu pack_deposit_refund_message.xsd, und somit auch eine indirekte Abhängigkeit zu svrl.xsd.

Eine Gültigkeit von Operations-Inputs bezüglich der in packaging_webservice_types.xsd definierten [XML]-Formate ist technische Voraussetzung dafür, dass das Getränkeverpackungen Einwegpfand Webservice eine Webservice-Interaktion erfolgreich abarbeiten kann.

Umgekehrt kann sich an das Getränkeverpackungen Einwegpfand Webservice angebundene Software darauf verlassen (bzw. dies auch validieren), dass Operations-Outputs des Webservice bezüglich der in pack_deposit_refund_webservice_types.xsd definierten Operations-Output-[XML]-Formate gültig sind.

pack_deposit_refund_webservice.wsdl

Beschreibt die Operationen des Getränkeverpackungen Einwegpfand Webservice und deren Inputs und Outputs unter Verwendung der formalen Sprache [WSDL]. Nutzt pack_deposit_refund_webservice_types.xsd direkt, und somit die anderen der zuvor genannten [XSD]-Dateien indirekt.

Kann in der Umsetzung einer Anbindung an das Webservice beispielsweise mit Werkzeugen wie SoapUI, www.soapui.org/, genutzt werden, um automatisiert Beispiel-Requests an das Webservice zu generieren und diese auszuführen.

svrl.xsd

Definiert das Schematron Validation Report Language (SVRL) Datenformat für [Schematron]-Prüfergebnisse in der formalen Sprache [XSD].

pack_deposit_refund_message.xsd nutzt svrl.xsd, besitzt also eine Abhängigkeit zu svrl.xsd.

Allgemeines

Produktiv- und Test-Umgebungen

Endpunkt Produktiv-Umgebung	tbd z.B. https://edm.gv.at/pack_deposit_refund_ws
Endpunkt Benutzertest-Umgebung	tbd z.B. https://vprod.umweltbundesamt.at/pack_deposit_refund_ws

Die beiden Umgebungen erfordern jeweils eigene Zugangsdaten bzw. Freischaltungen. Vergleiche dazu auch den Abschnitt Authentifizierung.

designation-Attribut

Codifizierte Information spielt eine wichtige Rolle in der Informationstechnologie und der automatisierten Informationsverarbeitung, und kommt auch im Getränkeverpackungen Einwegpfand Webservice zum Einsatz, z.B. bei der Identifikation von Packstoffen und Recyclingunternehmen.

Codifizierte Information eignet sich zwar sehr gut für die maschinelle Verarbeitung, ist aber für Menschen im Allgemeinen nicht unmittelbar interpretierbar.

Besonders im Zuge der Entwicklung und des Testens von Software kann es hilfreich sein, [XML]-Dateninstanzen (per Software oder manuell) so zu generieren, dass diese auch durch Menschen, z.B. Entwickler und Tester, gut unmittelbar interpretierbar sind. Um diese Anforderung zu unterstützen, bieten die im Getränkeverpackungen Einwegpfand Webservice verwendeten [XML]-Strukturen zu den meisten für codifizierte Information vorgesehenen Datenelementen die Möglichkeit, eine natürlichsprachige Bezeichnung bzw. Beschreibung der Information in einem designation benannten [XML]-Attribut zu ergänzen.

Die im Spezifikationspaket enthaltenen [XML]-Beispiel-Dateninstanzen illustrieren die Verwendung des designation-Attributs.

Auf das designation-Attribut trifft Folgendes zu:

Die Verwendung des Attributs ist optional. Das gilt für alle Stellen, an welchen das Attribut gemäß [XSD] verwendbar ist;
Das designation-Attribut dient ausschließlich dazu, IT-Personal die Handhabung von [XML]-Dateninstanzen zu erleichtern, z.B. während Entwicklung und Test.

Das bedeutet:

Aus Sicht der an Datenübermittlungen beteiligten Sender und Empfänger sind designation-Attribute definitionsgemäß bedeutungslos. D.h. für Sender und Empfänger ist eine Übermittlung mit darin enthaltenen designation-Attributen inhaltlich gleichwertig zu jener, aus der die designation-Attribute entfernt werden, und zwar unabhängig von den in designation-Attributen vorhandenen Zeichenketten.

Für die IT-Umsetzung bedeutet das:

Die Verarbeitung von empfangenen Dateninstanzen ist so umzusetzen, dass gewöhnliche Empfänger allfällig in empfangenen [XML]-Dateninstanzen enthaltene designation-Attribute nie zu Gesicht bekommen. Für gewöhnlich soll Software die in empfangenen [XML]-Dateninstanzen enthaltene designation-Attribute schlicht ignorieren, also beispielsweise nicht in eine Datenbank übernehmen. Die designation-Attribute könnten hier also allenfalls noch in technischen (für gewöhnliche Endbenutzer nicht zugänglichen) Logs, in welchen die empfangenen [XML]-Dateninstanzen gesamthaft eingetragen werden, aufscheinen.

Die Umsetzung des Getränkeverpackungen Einwegpfand Webservice hält sich an dieses Prinzip. Das Getränkeverpackungen Einwegpfand Webservice ignoriert also bei der Verarbeitung von an die Behörde übermittelten Dateninstanzen darin allfällig enthaltene designation-Attribute. In Übermittlungen an die Behörde enthaltene designation-Attribute bekommt die Behörde nie zu Gesicht.

Auch im speziellen Fall, dass ein in einer Übermittlung enthaltenes designation-Attribut im Widerspruch zur codifizierten Information steht, ist für Sender und Empfänger lediglich die codifizierte Information relevant, nicht jedoch das designation-Attribut. Drückt die codifizierte Information etwa den Packstoff Kunststoff aus (per GTIN 9008390101476), und das dazugehörige designation-Attribut per Zeichenkette »Aluminium« einen anderen Packstoff, so wurde aus Sicht von Sender und Empfänger völlig zweifelsfrei und unwidersprüchlich Kunststoff übermittelt.

TLS-Version

Anbindungen an das Getränkeverpackungen Einwegpfand Webservice müssen [TLS] Version 1.2 oder höher unterstützen.

Zeichenkodierung UTF-8 und Unicode-Blocks

Das Getränkeverpackungen Einwegpfand Webservice liefert alle Operations-Outputs in [UTF-8] Zeichenkodierung und erwartet alle Operations-Inputs in [UTF-8] Zeichenkodierung.

Die Übermittlungen an die Behörde sollen ausschließlich Zeichenketten bzw. Texte enthalten, deren Zeichen aus den ersten 3 [Unicode]-Blocks stammen, d.h. aus Basic Latin, Latin-1 Supplement und Latin Extended-A. Andere Zeichen kann edm.gv.at zwar verarbeiten, insbesondere in der Datenbank speichern. Die in edm.gv.at verwendeten Schriftarten (Fonts) unterstützen die Darstellung anderer Zeichen aber nicht notwendigerweise. Die Behörde sowie andere Benutzer von edm.gv.at können somit in der Benutzeroberfläche und in Exporten/Ausdrucken Texte, die Zeichen aus anderen [Unicode]-Blocks enthalten, nicht lesen.

Zu beachten ist, dass Software bei der Verarbeitung von Dateninstanzen in vielen, aber nicht in allen Fällen eindeutig erkennen kann, ob beim Generieren der Dateninstanz eine falsche Zeichenkodierung verwendet wurde. Anwenden der Latin-1 Codierung auf die Zeichenkette »RÄ®« liefert beispielsweise 52c4ae. Bei dieser aus 3 Bytes bestehenden Bytefolge handelt es sich nicht nur um eine gültige Latin-1-Codierung, sondern zugleich auch um eine gültige [UTF‑8] Codierung, wenngleich von einer anderen Zeichenkette, namentlich »RĮ«.

Wenn das Getränkeverpackungen Einwegpfand Webservice feststellt, dass ein Operations-Input mit falscher Zeichenkodierung erstellt wurde, d.h. wenn die [UTF-8]-Dekodierung des Operations-Inputs fehlschlägt, dann bricht es die Operation mit einem [SOAP] Fault ab.

Um bei der Umsetzung einer Anbindung an das Webservice die Verwendung einer falschen Zeichencodierung beim Generieren von Datenübermittlungen und Operations-Input zuverlässig festzustellen, auch bei möglicher [UTF-8]-Dekodierbarbarkeit von mit falschen Kodierungen erstellten Bytefolgen, empfiehlt die Umweltbundesamt GmbH dem IT-Personal, das an der Umsetzung einer Anbindung arbeitet, Testfälle zu erstellen, welche die Übermittlung von Texten, z.B. Firmenbezeichnungen, mit Umlauten enthalten, und zu überprüfen bzw. überprüfen zu lassen, ob diese Texte auf Empfänger-Seite, d.h. auf Seite der Behörde, korrekt, also mit Umlauten, aufscheinen.

XML Character Escaping und Unescaping

Die Operations-Inputs und Outputs des Getränkeverpackungen Einwegpfand Webservice sind [XML]-Instanzen.

Für [XML]-Dateninstanzen gelten spezielle Abbildungsregeln für bestimmte Buchstaben im Element- und Attribut-Inhalt – konkret für die Buchstaben »<« (Kleiner-Zeichen, #x3C), »>« (Größer-Zeichen, #x3C) und »&« (Kaufmännisches Und, #x26). Abschnitt 2.4 Character Data and Markup der [XML]-Spezifikation beschreibt diese als XML Character Escaping und Unescaping bezeichneten Abbildungsregeln.

Lautet die Bezeichnung eines Unternehmens beispielsweise Stenau GmbH & Co. KG, dann enthält die XML-Instanz den Namen als <Name>Stenau GmbH & Co. KG</Name>.

Webservice-Clients müssen also beim Generieren von Operations-Input XML Character Escaping anwenden, und beim Verarbeiten von Operations-Ouput XML Character Unescaping. Für das Getränkeverpackungen Einwegpfand Webservice gilt das umgekehrt, es wendet Unescaping auf Input an, und Escaping auf Output.

Um allfällige Probleme in Zusammenhang mit Escaping und Unescaping bereits im Zuge von Umsetzung und Test zuverlässig festzustellen und zu beheben (und nicht erst im Produktivbetrieb zu bemerken), empfiehlt die Umweltbundesamt GmbH dem IT-Personal, das an der Umsetzung einer Webservice-Anbindung arbeitet, Testfälle zu erstellen, welche die Übermittlung von Texten, z.B. Firmenbezeichnungen, mit »&« (Kaufmännisches Und, #x26) enthalten, und zu überprüfen bzw. überprüfen zu lassen, ob diese Texte auf Empfänger-Seite, d.h. auf Seite der Behörde, korrekt aufscheinen.

Authentifizierung

Einleitung

Die Behörde stellt der zentralen Stelle via EDM Helpdesk Zugangsdaten bestehend aus Client-ID und ein Client-Secret aus, und richtet eine Aktivierung bzw. Freischaltung so ein, dass der betreffende Client genau für die zentrale Stelle mit dem Getränkeverpackungen Einwegpfand Webservice interagieren kann.

Für Benutzertest-Umgebung und Produktiv-Umgebung stellt die Behörde jeweils eigene Zugangsdaten aus. Siehe dazu auch den Abschnitt Produktiv- und Test-Umgebungen.

Client-ID und Client-Secret sind in dem von der Zentralen Stelle genutzten Client des Getränkeverpackungen Einwegpfand Webservice zu hinterlegen.

Der Webservice-Client muss bei jeder Webservice-Interaktion mittels Client-ID und Client-Secret einen Nachweis über seine Identität erbringen. Das ist auf 2 Arten möglich:

Per [HTTP Basic Authentication];
Per [HMAC-SHA-256], der mittels [HTTP] Header übermittelt wird.

Die Behörde empfiehlt die Nutzung der [HMAC-SHA-256]-Variante, da diese in Security Tests als sicherer bewertet wird.

Basic Auth

Bei dieser Authentifizierungsvariante übermittelt der Webservice-Client Client-ID und Client-Secret bei jeder Interaktion mit dem Webservice als [HTTP] Authorization Header.

Der allgemeine Aufbau eines [HTTP] Authorization Header lautet:

Authorization: <auth-scheme> <authorization-parameters>

Für das [HTTP Basic Auth] Schema lautet der spezielle Aufbau:

Authorization: Basic <credentials>

Dabei bildet der Webservice-Client die <credentials> Zeichenkette wie folgt:

Zusammensetzen der folgenden 3 Zeichenketten:
- Client-ID
- Die aus einem einzelnen Zeichen, dem Doppelpunkt, bestehende Zeichenkette (» : «, 0x3A)
- Client-Secret
Aus der zusammengesetzten Zeichenkette mittels [UTF-8] Zeichenkodierung eine Bytefolge berechnen;
Auf die Bytefolge [Base64]-Kodierung anwenden, und zwar jene Variante der [Base64]-Kodierung, welche die Zeichen »+« und »/« für die Indexwerte 62 und 63 nutzt, und sogenanntes Padding anwendet, sodass die Länge der resultierenden Zeichenkette ein Vielfaches von 4 ist.

Beispiel:

Für Client-ID BEVERAGE_PACKAGING.CLOUD und Client-Secret 6H!uU3w*hSyuzj lautet die zusammengesetzte Zeichenkette BEVERAGE_PACKAGING.CLOUD:6H!uU3w*hSyuzj.

Anwenden der [UTF-8] Zeichenkodierung auf diese zusammengesetzte Zeichenkette, und anschließendes Anwenden der [Base64]-Kodierung liefert die Zeichenkette QkVWRVJBR0VfUEFDS0FHSU5HLkNMT1VEOjZIIXVVM3cqaFN5dXpq.

Der Webservice-Client authentifiziert sich also gegenüber dem Webservice, indem er in jeder Interaktion mit dem Webservice den folgenden [HTTP] Authorization Header setzt:

Authorization: Basic QkVWRVJBR0VfUEFDS0FHSU5HLkNMT1VEOjZIIXVVM3cqaFN5dXpq

HMAC-SHA-256 Auth

Bei dieser Authentifizierungsvariante übermittelt der Webservice-Client bei jeder Interaktion mit dem Webservice einen wie folgt aufgebauten [HTTP] Authorization Header:

Authorization: EDM1 clientID="<client-id>", clientHMAC="<hmac>"

Die <hmac>-Zeichenkette berechnet der Webservice-Client wie folgt:

Basierend auf dem Operations-Input den stringToSign zusammensetzen;
Eine [HMAC-SHA-256]-Bytefolge berechnen, mit der [UTF-8] Zeichenkodierung von stringToSign als data-Input, und der [UTF-8] Zeichenkodierung des Client-Secret als key-Input;
Auf die aus dem zweiten Schritt resultierende [HMAC-SHA-256]-Bytefolge eine [Base64]-Kodierung anwenden, und zwar jene Variante der [Base64]-Kodierung, welche die Zeichen »+« und »/« für die Indexwerte 62 und 63 nutzt, und sogenanntes Padding anwendet, sodass die Länge der resultierenden Zeichenkette ein Vielfaches von 4 ist.

Bilden des stringToSign für die ShareMessage-Operation:

  stringToSign = transactionUUID + "\n" +
                 messageUUID + "\n" +
                 messageCreationPartyID

Beispiel:

Im Beispiel lautet die Client-ID BEVERAGE_PACKAGING.CLOUD und das Client-Secret 6H!uU3w*hSyuzj.

Es wird der Authorization-Header für folgenden Request bestimmt (Auszug):

<soap12:Envelope>

<soap12:Body>

<pkt:ShareMessageRequest>

<pkt:ClientInterfaceVersionID>0.01</pkt:ClientInterfaceVersionID>

<pkt:ClientVersionID>3.3.2-1</pkt:ClientVersionID>

<pkt:TransactionUUID>483fdc6c-610a-456b-b697-ece275513c9a</pkt:TransactionUUID>

<pkm:ReportUserMessage>

<pkm:MessageUUID>fa140a8e-54c5-494f-8bd8-79edb0462c91</pkm:MessageUUID>

<pkm:MessageCreationUTCTimestamp>2026-02-07T14:56:42.847702Z</pkm:MessageCreationUTCTimestamp>

<pkm:MessageCreationDataFormatVersionID>0.01</pkm:MessageCreationDataFormatVersionID>

<pkm:MessageCreationPartyIDregisterID="GLN.AT">9110032898689</pkm:MessageCreationPartyID>

Der stringToSign lautet hier:

  "483fdc6c-610a-456b-b697-ece275513c9a" + "\n" +
  "fa140a8e-54c5-494f-8bd8-79edb0462c91" + "\n" +
  "9110032898689"

Anwenden der [HMAC-SHA-256]-Berechnung auf die [UTF-8] Zeichenkodierungen von stringToSign (data-Input) und Client-Secret (key-Input) liefert die Bytefolge 4fdd98d803787ce62641e8ef5d127281ec261cd9062b66dfb3397811d413ccd5, hier in Hexadezimal-Darstellung abgebildet.

Anwenden der [Base64]-Kodierung liefert die Zeichenkette T92Y2AN4fOYmQejvXRJygewmHNkGK2bfszl4EdQTzNU=.

Der [HTTP] Authorization Header für den genannten Request lautet somit:

Authorization: EDM1 clientID="BEVERAGE_PACKAGING.CLOUD", clientHMAC="T92Y2AN4fOYmQejvXRJygewmHNkGK2bfszl4EdQTzNU="

Identifikation von Recyclingunternehmen und Recyclingstandorten

Zwei Identifikations-Varianten

In den Übermittlungen an die Behörde kommt die Identifikation von Recyclingunternehmen und Recyclingstandorten vor.

Das Getränkeverpackungen Einwegpfand Webservice unterstützt zwei Varianten der Identifikation von Recyclingunternehmen und Recyclingstandorten in Übermittlungen an die Behörde:

Identifikation ausschließlich mittels ID (Identifikationszeichenkette), und zwar mittels in edm.gv.at zum betreffenden Unternehmen bzw. zum betreffenden Standort eingetragener ID;
Identifikation mittels Kombination aus Name, Sitzadresse und ggf. IDs wie Umsatzsteuer-Identifikationsnummer für Recyclingunternehmen sowie mittels Kombination aus Name und Adresse für Recyclingstandorte.

Die im Spezifikationspaket enthaltenen [XML]-Beispieldateninstanzen illustrieren beide Identifikations-Varianten.

Welche der beiden Identifikations-Varianten wann zu verwenden ist

Für die Anwendung der Identifikations-Varianten gilt das folgende Prinzip:

Die erste Variante - Identifikation ausschließlich per in edm.gv.at verwalteter ID - erwartet die Behörde für alle Unternehmen und Standorte, die im öffentlich zugänglichen Bereich auf edm.gv.at unter "Suchen/Auswerten" auffindbar sind;
Die Nutzung der zweiten Variante - Identifikation per Name und Adresse - erwartet die Behörde nur für jene Unternehmen und Standorte, die im öffentlich zugänglichen Bereich auf edm.gv.at unter "Suchen/Auswerten" nicht auffindbar sind.

Details zur Identifikation per ID

Bei der Identifikation per ID enthält die Übermittlung lediglich die jeweilige ID, z.B. EDM-Personen-GLN in RecoveryPartyID oder EDM-Standort-GLN in RecoverySiteID, ohne weiterführende Angaben wie Name und Adresse des Unternehmens bzw. des Standorts. Ergänzend zur ID enthält das Attribut registerID die ID-Art, z.B. »GLN.EDM« für EDM-Personen-GLN bzw. EDM-Standort-GLN oder »GLN.AT« für GLN der öffentlichen Verwaltung. Diese ID-Arten stammen aus ↗Codeliste 7836.

Es ist auch diese ↗Codeliste 7836, die definiert, mit welchen zum Unternehmen bzw. zum Standort in edm.gv.at eingetragenen IDs das Unternehmen bzw. der Standort in Übermittlungen per Getränkeverpackungen Einwegpfand Webservice identifiziert bzw. referenziert werden kann.

Innerhalb einer Message sind Unternehmen und Standorte jeweils einheitlich zu identifizieren. Beispielsweise müssen innerhalb einer Message alle Unternehmen entweder per »GLN.EDM« oder per »GLN.AT« identifiziert werden. Ein Mischen in dem Sinne, dass ein Teil der innerhalb einer Message auftretenden Unternehmen per »GLN.EDM« identifiziert wird, und ein anderer Teil der Unternehmen per »GLN.AT«, ist nicht zulässig und kann vom Webservice nicht verarbeitet werden.

Details zur Identifikation per Name und Adresse

Es kommt häufig vor, dass bei Übermittlungen an die Behörde auf dasselbe Unternehmen und/oder denselben Standort mehrfach Bezug genommen werden muss. Das ist etwa dann der Fall, wenn sowohl Kunststoff-Einweggetränkeverpackungen als auch Aluminium-Einweggetränkeverpackungen an einen Recyclingstandort X des Betreibers Y übergeben werden - es gibt dann zwei Event-[XML]-Elemente in der Datenübermittlung, eines für den Packstoff Kunststoff und eines für den Packstoff Aluminium, und beide Event-[XML]-Elemente enthalten Unterlemente mit Bezug auf X und Y. Vergleiche den Überblick zur ReportUserMessage.

Das Datenformat weist einen Aufbau auf, der zum Ziel hat, dass für jedes in der Übermittlung auftretende Recyclingunternehmen die Message Angaben zu Name, Sitzadresse und IDs des Unternehmens nur genau 1 Mal enthält, unabhängig davon, wie häufig das Unternehmen in der Übermittlung referenziert werden muss. Dasselbe gilt für Name und Adresse von Recyclingstandorten.

Dafür sind zwei Stellen des [XML]-Datenformats relevant:

ListedData: Eine Auflistung der für die Übermittlung relevanten Recyclingunternehmen und Recyclingstandorte mit Detailangaben und "lokaler" ID. Jedes Unternehmen und jeder Standort tritt hier nur ein Mal auf, unabhängig davon, wie oft in der Übermittlung auf das Unternehmen bzw. den Standort Bezug genommen wird. Die Detailangaben sind:
- Für Unternehmen: Namen, Sitzadresse, und wenn vorhanden bzw. bekannt IDs wie die Umsatzsteuer-Identifikationsnummer;
- Für Standorte: Name und Adresse;
Event: In den Angaben zu Tätigkeiten (Inverkehrsetzen, Übergabe zum Recycling, usw.) erfolgt ein Bezug auf die unter ListedData angeführten Unternehmen bzw. Standorte durch Eintragen der passenden "lokalen" ID in RecoveryPartyLocalReferenceID bzw. RecoverySiteLocalReferenceID.

Wesentliche Voraussetzung für die "lokale" ID ist die Eindeutigkeit innerhalb der Message (Datenübermittlung an die Behörde). Es ist also beispielsweise ein "Durchnummerieren" innerhalb der generierten Message als Unternehmen001, Unternehmen002, usw. und Standort001, Standort002, usw. zulässig.

Wert 0 bei Masse/Anzahl

Das Datenformat unterstützt bei Angaben zur Masse (MassValue) und zur Anzahl (Count) den Wert 0 nicht.

Vielmehr gilt das Prinzip, dass in der [XML]-Dateninstanz nur solche Gruppierungen (nach Packstoff, Getränkekategorie, usw.) anzuführen sind, für welche die (gesamte) Masse bzw. die (gesamte) Anzahl ungleich 0 ist.

Message-Vollständigkeit

Eine User Message besteht aus Message-Teilen. Jeder Message-Teil besitzt genau einen Inhaltstyp, und jeder Inhaltstyp tritt in einer Message-Art nicht öfter als 1 Mal auf. Für die Message-Art Einweggetränkeverpackungen Jahresbericht der zentralen Stelle gemäß §24 Abs. 1 PfandVO gibt es genau 7 Inhaltstypen, darunter beispielsweise In Verkehr gesetzte bepfandete Einweggetränkeverpackungen und Zurückgenommene bepfandete Einweggetränkeverpackungen. Siehe Abschnitt Inhaltstyp-Codes und deren Aufbau für genauere Informationen.

Es gilt nachfolgendes Vollständigkeitskriterium: Jede User Message muss alle für die Message-Art definierten Inhaltstypen enthalten. Konkret muss jeder Einweggetränkeverpackungen Jahresbericht der zentralen Stelle jeden der 7 definierten Inhaltstypen enthalten. Bei Fehlen von einem oder mehreren Inhaltstypen kann das Webservice die Übermittlung an die Behörde nicht verarbeiten. Die Übermittlung des Einweggetränkeverpackungen Jahresberichts der zentralen Stelle an die Behörde schlägt beispielsweise fehl, wenn es darin keinen Message-Teil mit Inhaltstyp Masse des eingesetzten Recyclats bezogen auf die in Verkehr gesetzten Einweggetränkeverpackungen gibt.

Mindestlänge 1 für Zeichenketten

An Operationen des Getränkeverpackungen Einwegpfand Webservice übergebener Input - dazu zählen an die Behörde zu übermittelnde Jahresberichte - enthält unter Anderem Zeichenketten-Angaben, z.B. IDs und Namen von Recyclingunternehmen.

Die zur Schnittstellenspezifikation gehörenden [XSD]s - pack_deposit_refund_message.xsd, usw. - definieren für alle solche Zeichenketten-Angaben eine Mindestlänge von 1 Zeichen. Die Schnittstelle unterstützt also keine Zeichenketten der Länge 0.

Enthält der an Operationen des Getränkeverpackungen Einwegpfand Webservice übergebene Input Zeichenketten der Länge 0, etwa in Form von <Name/> oder <Name></Name>, dann schlägt die vom Webservice vorgenommene [XSD] Validierung des Operations-Inputs fehl. Eine Übermittlung an die Behörde schlägt dann technisch fehl.

Für die Daten-Handhabung auf Sender-Seite und die Umsetzung einer Webservice-Anbindung bedeutet das:

Idealerweise sollen bereits auf Senderseite Zeichenketten der Länge 0 gar nicht erst auftreten bzw. ermöglicht werden;
Wenn in den Ausgangsdaten für Übermittlungen an die Behörde Zeichenketten der Länge 0 dennoch auftreten, dann soll die Software, welche die [XML]-Message generiert, besser das betreffende [XML]-Element aus der generierten Message weglassen (Handhabung analog zu null-Wert) als das Element mit leerem Inhalt in die Message zu schreiben. Sofern es sich um Meldungsinhalt handelt, und sofern die betreffende Angabe in der Übermittlung an die Behörde erforderlich ist, führt das Fehlen des Elements zu einem für Benutzer gut verständlichen Prüfprotokolleintrag der Art "Angabe xy fehlt". Das Vorhandensein des [XML]-Elements mit Inhalt der Länge 0 würde hingegen zu einem für Benutzer unverständlichen technischen Fehler führen, dem genannten [XSD] Validierungs-Fehler.

Leerinhalte

Der vorige Abschnitt beschreibt, dass jeder Einweggetränkeverpackungen Jahresbericht der zentralen Stelle jeden der 7 dafür definierten Inhaltstypen enthalten muss.

Für jeden der 7 Message-Teile gibt es zwei Möglichkeiten:

Nichtleerer Inhalt, d.h. im Berichtsjahr haben betreffende Tätigkeiten stattgefunden (z.B. Inverkehrsetzung durch Erstinverkehrsetzer);
Leerer Inhalt, d.h. im Berichtsjahr haben keine betreffenden Tätigkeiten stattgefunden (z.B. Übergabe zum Recycling durch zentrale Stelle).

Für jeden Message-Teil gibt es als MessagePart-Unterelement ReportingObligationActivityIndicator. Dabei handelt es sich um einen Ja/Nein-Wert, der anzeigt, ob im Berichtsjahr dem Inhaltstyp entsprechende Tätigkeiten stattgefunden haben, die unter eine Berichtspflicht an die Behörde fallen.

Beinhaltet ReportingObligationActivityIndicator den Wert true oder 1 (zutreffend), dann muss der jeweilige Message-Teil mindestens ein Event-Unterelement enthalten.

Beinhaltet ReportingObligationActivityIndicator den Wert false oder 0 (nicht zutreffend), dann darf der jeweilige Message-Teil kein Event-Unterelement enthalten.

Zweck dieser Systematik ist, das Risiko für Fehlinterpretationen von an die Behörde übermittelten Daten zu verringern.

Ohne diese Systematik würde auf Empfänger-Seite bloß implizit aus dem Fehlen bestimmter Angaben schlussgefolgert werden, dass im Berichtszeitraum keine betreffenden Tätigkeiten ausgeübt wurden. Damit könnte beispielsweise die unbeabsichtigte Unvollständigkeit der Daten auf Absender-Seite zu einer Fehl-Schlussfolgerung auf Empfänger-Seite führen. Die explizite Deklaration, ob im Berichtszeitraum entsprechende Tätigkeiten erfolgt sind, verringert das Risiko für solche Fehl-Schlussfolgerungen.

Korrekturen und Aktualisierungen

Das Webservice unterstützt die Übermittlung von Korrekturen und Aktualisierungen.

Um bereits an die Behörde übermittelte Daten zu korrigieren bzw. zu aktualisieren, führt der Webservice-Client für denselben Berichtszeitraum und dieselbe Message-Art, für die er bereits zuvor eine Übermittlung an die Behörde durchgeführt hat, eine neuerliche Übermittlung durch, mit derselben Webservice-Operation (ShareMessage). Abgesehen von aktualisierten Meldungsinhalten unterscheidet sich die Korrektur also nicht von der initialen Übermittlung. Weder sieht das Webservice eigens eine Kennzeichnung als Korrektur vor, noch gibt es für Korrekturen eigens Webservice-Operationen.

Formale Prüfungen gelten für initiale Übermittlungen und Korrektur-Übermittlungen gleichermaßen. Insbesondere ist die Message-Vollständigkeit auch für Korrekturen einzuhalten. Die Korrektur eines Einweggetränkeverpackungen Jahresberichts der zentralen Stelle muss somit - genau wie die initiale Übermittlung - 7 Message-Teile enthalten, für jeden der für diese Message-Art definierten Inhaltstypen genau einen. Wenn die Korrekturen also beispielsweise nur einen der 7 Message-Teile betreffen, dann muss die Korrektur-Übermittlung der Message die anderen 6 Message-Teile unverändert zur vorangegangenen Übermittlung enthalten.

Erstmalige Übermittlungen an die Behörde per Getränkeverpackungen Einwegpfand Webservice für einen Berichtszeitraum und eine Message-Art lösen das Anlegen von (einem oder mehreren) Fachobjekten in edm.gv.at aus. Zwar können bei Korrekturen Leerinhalte übermittelt werden, das Anlegen der Fachobjekte lässt sich aber per Webservice nicht rückgängig machen. Sollte aus Sicht der zentralen Stelle das Löschen eines Fachobjekts erforderlich sein, muss sie den EDM Helpdesk kontaktieren. Siehe Kontakt.

SOAP Faults

Jede Interaktion mit dem Getränkeverpackungen Einwegpfand Webservice kann mit einem [SOAP]-Fault enden.

Wenn das Webservice mit einem [SOAP]-Fault reagiert, dann immer in Kombination mit dem [HTTP] Status Code 500 Internal Server Error, unabhängig von Art des Faults und dem Inhalt der Fault Message.

Das Getränkeverpackungen Einwegpfand Webservice verwendet ausschließlich die im folgenden Schema-Diagramm eingezeichneten Elemente von [SOAP]-Faults:

Fault

Fault/Code/Value

Einer der in [SOAP] 1.2 definierten Werte. Insbesondere Sender oder Receiver.

Fault/Reason/Text

Natürlichsprachige Beschreibung des Fehlers.

Zu beachten ist, dass diese Beschreibung technische Fehlerinformationen enthält, die IT-Personal dabei helfen kann, die Fehlerursache zu identifizieren und den Fehler zu beheben. Der betreffende Text ist – im Unterschied zu den Inhalten einer Signal Message – für gewöhnliche Benutzer im Allgemeinen nicht verständlich, und soll daher gewöhnlichen Benutzern entweder nicht oder nur mit entsprechender Kontextinformation (z.B. den IT-Support zu kontaktieren) angezeigt werden.

Empfohlene Handhabung bestimmter Webservice-Verhalten

Timeout / No respone / Network Errors

Kann unter regulären Umständen auftreten, z.B. während des Deploys einer neuen Version des Webservice.

Reaktion der Software (Senderseite):

- Automatische Übertragungswiederholungen, z.B. stündlich;
- Benutzern Statusinformationen der Übertragung anzeigen (ausstehende EDI-Übertragungen).

Reaktion der Benutzer (Senderseite):

- Normalerweise keine Reaktion erforderlich, abgesehen von der Überprüfung, dass die EDI-Übertragungen nach einer Weile automatisch wieder aufgenommen werden.

Reaktion des IT-Supports (Senderseite): Keine erforderlich.

SOAP Fault

Das Webservice reagiert mit einem SOAP-Fault anstelle eines SOAP-Response.

Beispiele:

- Kann als Reaktion auf eine nicht [XSD]-konforme Anfrage auftreten;
- Kann als Reaktion auf eine fehlgeschlagene Authentifizierung auftreten.

Reaktion der Software (Senderseite):

- Anzeige von Informationen für die Benutzer, dass ein technisches Problem IT-Support erfordert.

Reaktion der Benutzer (Senderseite):

- Problem an den IT-Support auf der Senderseite weiterleiten.

Reaktion des IT-Supports (Senderseite):

- Problem beheben, zum Beispiel mit einem Hotfix;
- Falls erforderlich, EDM IT-Support kontaktieren.

Ablehnungs-Signal (REJECTION)

Das Webservice reagiert mit einem Signal, das eine automatische Ablehnung anzeigt.

Reaktion der Software (Senderseite):

- Anzeige von Informationen zum Übertragungsstatus für die Benutzer, einschließlich SignalID, ReceiverFailureIndicator und SignalDescription, sowie des Prüfprotokolls zur formalen Prüfung, falls in der Signal Message vorhanden;
- Benachrichtigung der Benutzer, dass die Übertragung fehlgeschlagen ist und sie Maßnahmen ergreifen müssen, um die Ursache zu beheben und einen erneuten Übertragungsversuch einzuleiten.

Reaktion der Benutzer (Senderseite):

- Auf der Grundlage der im Signal empfangenen Informationen die Ursache des Übertragungsfehlers beheben und einen erneuten Übertragungsversuch einleiten;
- Falls erforderlich, Benutzer auf der Empfängerseite (Behörde) einbeziehen, z.B. wenn Stammdaten zu Recyclingunternehmen in edm.gv.at falsch eingetragen sind.

Reaktionen des IT-Supports (Senderseite): Keine erforderlich.

Akzeptanz-Signal mit INFO oder WARNING als Ergebnis der formalen Prüfung

Das Webservice reagiert mit einem Signal, das die Entgegennahme der übermittelten Message anzeigt (ACCEPTANCE) und ein INFO- oder WARNING-Gesamtergebnis der formalen Validierung enthält.

Reaktion der Software (Senderseite):

- Anzeige der Informationen zum Übertragungsstatus aus der Signal Message für Benutzer;
- Benachrichtigung von Benutzern, dass die Software Hinweise auf mögliche Inkonsistenzen in den übermittelten Daten festgestellt hat und dass es daher ratsam ist, die übermittelten Daten zu überprüfen und - falls erforderlich - zu aktualisieren und erneut zu übermitteln.

Reaktion der Benutzer (Senderseite):

- Überprüfung der übermittelten Daten auf Basis der im Signal empfangenen Informationen und, falls erforderlich, hinzufügen/bearbeiten von Daten und Auslösen einer erneuten Übermittlung;
- Falls erforderlich, Einbeziehung der Empfängerseite (Behörde). Bei der Überprüfung der Datenübermittlung kann sich beispielsweise herausstellen, dass falsche oder fehlende Daten in edm.gv.at das INFO oder WARNING Prüfergebnis ausgelöst haben. In einem solchen Fall wird zunächst die Korrektur der Daten in edm.gv.at veranlasst, und dann startet ein Benutzer auf der Senderseite eine erneute Übermittlung.

Reaktionen des IT-Supports (Senderseite): Keine erforderlich.

Akzeptanzsignal mit OK als Ergebnis der formalen Prüfung

Das Webservice reagiert mit einem Signal, das die Entgegennahme der übermittelten Message anzeigt (ACCEPTANCE) und ein OK-Ergebnis der formalen Validierung enthält.

Reaktion der Software (Senderseite):

- Anzeige von Übertragungsstatusinformationen aus der Signal Message für Benutzer.

Reaktion der Benutzer (Senderseite): Keine erforderlich.

Reaktionen des IT-Supports (Senderseite): Keine erforderlich.

Service Level

Die Umweltbundesamt GmbH betreibt das Getränkeverpackungen Einwegpfand Webservice entsprechend den allgemeinen Betriebsbedingungen des EDM. Siehe edm.gv.at, "Technische und organisatorische Spezifikationen", "Allgemeine Betriebsbedingungen". Beispielsweise kann das Webservice wegen geplanter Wartungsarbeiten, etwa bei der Inbetriebnahme neuer Releases, dienstags und donnerstags ab 18:00 Uhr Ortszeit (MEZ/MESZ) vorübergehend nicht verfügbar sein.

Codelisten

Einleitung

Codifizierte Information spielt eine wichtige Rolle in der Informationstechnologie und der automatisierten Informationsverarbeitung.

Ein Beispiel für eine Codeliste ist die ISO 3166-1 Liste der Länder, mit Einträgen wie »AT« für Österreich und »DE« für Deutschland.

Software nutzt Codelisten unter anderem dafür, um die in Datenbanken und EDI-Dateninstanzen enthaltene codifizierte Information für Benutzeroberflächen, Ausdrucke, usw. in „lesbare“ Information zu „übersetzen“, also beispielsweise um anstelle eines eines Länder-Codes »AT« die Landesbezeichnung »Österreich« darzustellen.

Das BMK verwaltet in edm.gv.at die für EDM-Anwendungen und Schnittstellen relevanten Codelisten, und stellt diese öffentlich zur Verfügung. Darunter auch die von der Getränkeverpackungen Einwegpfand Webservice Spezifikation genutzten Codelisten.

Codelisten-Veröffentlichung

Das BMK veröffentlicht die in edm.gv.at genutzten Codelisten auf zwei Wegen:

Am Portal edm.gv.at im öffentlich zugänglichen Bereich unter dem Menüpunkt Zuordnungstabellen;
Über ein Codelisten-Webservice für den maschinellen Abruf und die maschinelle Synchronisation von Codelisten. Das BMK veröffentlicht am Portal edm.gv.at im öffentlich zugänglichen Bereich unter dem Menüpunkt Technische und organisatorische Spezifikationen das Codelisten-Webservice-Spezifikationspaket inklusive Schnittstellenbeschreibung.

Alle der in dieser Spezifikation genutzten Codelisten stehen auf beiden Wegen - Portal und Webservice - zur Verfügung.

Statische und dynamische Nutzung von Codelisten

Statische Nutzung

Folgendes charakterisiert die statische Nutzung von Codelisten durch diese Spezifikation:

Die Spezifikation definiert die Menge unterstützter/zulässiger Werte, nicht die Codeliste;
Wenn sich die zugrundeliegende Codeliste ändert, dann spiegeln sich diese Änderungen nicht automatisch in der Spezifikation wider. Vielmehr ist es so, dass eine neue, aktualisierte Version der Spezifikation die Änderungen der zugrundeliegenden Codeliste in die Spezifikation übernehmen kann, z.B. wenn dies sinnvoll oder notwendig scheint. Auch dann, wenn die Übernahme von Änderungen sinnvoll oder notwendig scheint, kann es einen Gestaltungsspielraum dazu geben, wann solche Änderungen in eine neue Version der Spezifikation einfließen. Es könnte beispielsweise naheliegen, solche Änderungen erst im Zuge anderer wichtiger Änderungen in eine neue Version der Spezifikation zu übernehmen, um die Spezifikation möglichst stabil zu halten, d.h. im Laufe der Zeit nur möglichst selten Anpassungen an der Spezifikation vorzunehmen;
Für Softwareentwickler, welche diese Spezifikation in ihrer Software umsetzen, gilt, dass sie die Software generell gut auf Änderungen von durch die Spezifikation verwendeten Codelisten auslegen sollen, in dem Sinne, dass solche Änderungen schnell und kostengünstig realisierbar sind. Das gilt zwar grundsätzlich auch für durch die Spezifikation statisch genutzte Codelisten, allerdings in einem geringeren Ausmaß als für dynamisch genutzte Codeliste. Für in der Spezifikation statisch genutzte Codelisten ist es durchaus legitim, aus Gründen wie Performance oder Komplexitäts-Vermeidung Einschränkungen in Bezug auf die schnelle und kostengünstige Aktualisierung in Kauf zu nehmen. Beispielsweise können Softwareentwickler ein "hartcodieren" von zulässigen/unterstützten Werten aus statisch genutzten Codelisten in Betracht ziehen;
Die zur Spezifikation gehörenden [XSD]s enthalten potentiell eine Enumeration der zulässigen Werte (xs:enumeration). Das erleichtert ggf. die Handhabung der [XSD]s bei der Nutzung in der Umsetzung einer Webservice-Anbindung.

Dynamische Nutzung

Folgendes charakterisiert die dynamische Nutzung von Codelisten durch diese Spezifikation:

Die Codeliste definiert die Menge unterstützter/zulässiger Werte, nicht die Spezifikation selbst;
Die zur Spezifikation gehörenden [XSD]s enthalten keine Enumeration der zulässigen Werte (xs:enumeration);
Änderungen der Codelisten können unabhängig von Änderungen der Spezifikation auftreten, und haben dennoch eine Auswirkung darauf, welche [XML]-Instanzen gemäß dieser Spezifikation als zulässig bzw. unzulässig gelten;
Für Software, welche diese Spezifikation umsetzt, kann es in Bezug auf dynamisch genutzte Codelisten jederzeit vorkommen, dass es aufgrund einer Aktualisierung der Codeliste notwendig wird, ein aktualisiertes Set an Werten zu unterstützen. Das gilt unabhängig von folgendem:
- Veröffentlichung einer neuen Version der Spezifikation. D.h. auch dann, wenn es keine Veröffentlichung einer neuen Version der Spezifikation gibt, muss Software die Änderungen an zugrundeliegenden dynamisch genutzten Codelisten zeitnah unterstützen;
- Weiterentwicklung/Upgrade einer Software, um eine neuere Version der Spezifikation zu unterstützen. D.h. auch dann, wenn die Version der Spezifikation, welche eine Software umsetzt, unverändert bleibt, muss die Software die Änderungen an zugrundeliegenden dynamisch genutzten Codelisten zeitnah unterstützen.
Softwareentwickler sollen Implementierungen auf schnelle und kostengünstige Anpassbarkeit von unterstützten/zulässigen Werten auslegen. Insbesondere:
- Solche Anpassungen sollen keine neuen Software-Builds und Deploys erfordern, sondern beispielsweise per Aktualisierung von Datenbankinhalten oder Konfigurationsdatei-Inhalten möglich sein;
- Solche Anpassungen sollen innerhalb von Stunden möglich sein. Das soll auch dann gelten, wenn es eine große Zahl von Installations- bzw. Ausführungs-Instanzen der Software gibt, und wenn es keine zentralisierte Kontrolle darüber gibt, wo überall Instanzen der Software laufen.

Beispiel

Diese Spezifikation nutzt die ↗Codeliste 3862 der Länder (Staaten) dynamisch. Der Grund dafür ist, dass unabhängig von den in Zusammenhang mit Verpackungen und Verpackungsabfall geltenden Bestimmungen neue Staaten jederzeit entstehen können, oder die Existenz bestehender Staaten enden kann (etwa bei der Vereinigung von Staaten). Darum müssen Softwareentwickler dafür sorgen, dass Software zur jährlichen Übermittlung per Getränkeverpackungen Einwegpfand Webservice im Bedarfsfall sehr schnell, effizient und kostengünstig auf geänderte bzw. neue unterstützte/zulässige Staaten anpassbar ist.

Von der Spezifikation statisch genutzte Codelisten

Von der Spezifikation dynamisch genutzte Codelisten

Webservice-Operationen

Einleitung

Dieser Abschnitt beschreibt die per Datei pack_deposit_refund_webservice.wsdl definierten Webservice-Operationen. pack_deposit_refund_webservice.wsdl beschreibt die Webservice-Operationen mit der standardisierten formalen Sprache [WSDL] 2.0.

Die Umweltbundesamt GmbH hat die nachfolgende Beschreibung automatisiert aus einer annotierten, also um Beschreibungstexte angereicherten, Variante der [WSDL]-Datei pack_deposit_refund_webservice.wsdl generiert. Das Spezifikationspaket enthält diese annotierte Variante der Datei nicht. Auf Anfrage stellt die Die Umweltbundesamt GmbH die annotierte Variante der Datei gerne bereit. Bitte dafür den EDM Helpdesk zu kontaktieren. Siehe Kontakt.

Verzeichnis

Operationen

ShareMessage

Operationen

ShareMessage

Operation zur Übermittlung von Daten an die zuständige Behörde, z.B. zu Einweggetränkeverpackungen.

Anmerkung 1: Die ShareMessage-Operation unterstützt beides:

Initiale Datenübermittlung an die Behörde;
Allfällige Korrektur bzw. Ergänzung von bereits an die Behörde übermittelten Daten.

Anmerkung 2: Die Verwendung der ShareMessage-Operation zur Übermittlung von Korrekturen bzw. Ergänzungen unterscheidet sich NICHT von der Verwendung für die initiale Übermittlung an die Behörde. Das Webservice interpretiert eine neuerliche Übermittlung derselben Message-Art für denselben Berichtszeitraum automatisch als Korrektur/Ergänzung.

Anmerkung 3: Die Verwendung der ShareMessage-Operation zur Übermittlung von Korrekturen bzw. Ergänzungen unterscheidet sich auch in dem Sinn NICHT von der Verwendung für die initiale Übermittlung, als die Operation jeweils VOLLSTÄNDIGE Messages erwartet. Bei Korrekturen und Ergänzungen muss die zentrale Stelle also auch solche Message-Teile neu übermitteln, an welchen sich gegenüber der vorherigen Übermittlung nichts geändert hat.

Anmerkung 4: Die ShareMessage-Operation unterzieht die an die Behörde übermittelten Daten FORMALEN PRÜFUNGEN, und liefert allfällige Ergebnisse solcher formalen Prüfungen im Output (MessageFormalValidationReport).

Port-Typ	PackDepositRefundServicePortType
Input 🠖pkt:ShareMessageRequest	Der Input der ShareMessage-Operation enthält die User Message (ReportUserMessage-Element) mit den an die Behörde zu übermittelnden Inhalten. Anmerkung: Das Webservice unterstützt genau 1 Message-Art - siehe ↗Codeliste 8686: RPT_BVG.YEAR: Einweggetränkeverpackungen-Jahresbericht der zentralen Stelle gemäß §24 Abs. 1 PfandVO.
Output 🠖pkt:ShareMessageResponse	Der Output der ShareMessage-Operation enthält eine Signal Message. Diese enthält Information zum Ergebnis der Verarbeitung der empfangenen User Message, ggf. inklusive Ergebnis der formalen Prüfung (MessageFormalValidationReport). Anmerkung: Auch bei regulärer Verarbeitung des ShareMessage-Aufrufs, d.h. wenn das Webservice NICHT mit einem SOAP-Fault reagiert sondern mit ShareMessageResponse, kann es sein, dass die Übermittlung an die Behörde NICHT erfolgreich war. Das ist insbesondere dann der Fall, wenn die formale Prüfung der übermittelten Daten zu einer automatischen Zurückweisung führt. Wenn die Operation mit ShareMessageResponse reagiert, also NICHT mit einem SOAP-Fault, dann zeigt der SignalID-Wert aus der Signal Message an, ob die Übermittlung an die Behörde erfolgreich war, und zwar mit dem Wert ACCEPTED für eine erfolgreiche Übermittlung, und dem Wert REJECTED für eine automatisiert zurückgewiesene Übermittlung.
Fault	Wenn bei der Verarbeitung des ShareMessage-Aufrufs ein Fehler auftritt, dann reagiert das Webservice mit einem SOAP 1.2 Fault. Das Webservice kann eines oder mehrere der folgenden in SOAP 1.2 definierten Fault-Elemente zur näheren Beschreibung des Fehlers nutzen: Code/Value Code/Subcode/Value Reason/Text

Inputs und Outputs der Webservice-Operationen

Einleitung

Die Umweltbundesamt GmbH hat die nachfolgende Beschreibung automatisiert aus einer annotierten, also um Beschreibungstexte angereicherten, Variante der [XSD]-Datei pack_deposit_refund_webservice_types.xsd generiert. Das Spezifikationspaket enthält diese annotierte Variante der Datei nicht. Auf Anfrage stellt die Die Umweltbundesamt GmbH die annotierte Variante der Datei gerne bereit. Bitte dafür den EDM Helpdesk zu kontaktieren. Siehe Kontakt.

Verzeichnis

Strukturen

ShareMessageRequestType

ShareMessageResponseType

Datentypen

Strukturen

ShareMessageRequestType

ShareMessageRequestType Schema diagram

Input der ShareMessage-Operation.

Name/Typ	min..max	Definition
ClientInterfaceVersionID 🠖pkm:VersionIdentifier	1..1	Konstante, welche der Client dem Webservice bekanntgibt, und welche die Version der Webservice-Spezifikation angibt, die auf der Client-Seite implementiert ist und welche somit der Webservice-Client unterstützt. Anmerkung: Dieses Element ist für Debugging-Zwecke gedacht. Begrenzungen: Die Zeichenkette besteht aus maximal 8 Zeichen Die Zeichenkette setzt sich aus den folgenden Teilen zusammen: "Major Version", gefolgt von einem Punkt (#x2E), gefolgt von der "Minor Version" Sowohl "Major Version" als auch "Minor Version" bestehen ausschließlich aus Ziffern Die "Minor Version" besteht aus GENAU 2 Ziffern Die "Major Version" besteht aus MINDESTENS 1 Ziffer Beispielwert: 1.00
ClientVersionID 🠖pkm:RelaxedIdentifierContent	1..1	Version der Webservice-Client-Software, welche die Webservice-Interaktion durchführt. Anmerkung: Dieses Element ist für Debugging-Zwecke gedacht. Begrenzungen: Die Zeichenkette besteht aus maximal 64 Zeichen Die Zeichenkette besteht aus mindestens 1 Zeichen Die Zeichenkette ist ein sogenanntes Token: Das 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 Beispielwert: 3.3.2-1
TransactionUUID 🠖pkm:UUIDIdentifierContent	1..1	Ein Universally Unique Identifier (UUID) der Version 4 (Zufalls-UUID) in kanonischer Darstellung, der vom Webservice-Client speziell für die Webservice-Interaktion erzeugt wurde und verwendet wird. Anmerkung 1: Dieses Element ist für Debugging-Zwecke gedacht. Anmerkung 2: Der Client benötigt für jede neue Webservice-Interaktion eine neue UUID. Dies gilt auch für Fälle, in welchen die Interaktion zur Aktualisierung von zuvor übermittelten Informationen oder zur Wiederholung einer zuvor fehlgeschlagenen Interaktion verwendet wird. Anmerkung 3: Verwenden einer UUID, die bereits zuvor in einer Webservice-Interaktion als Transaction UUID verwendet wurde, kann zum Fehlschlagen der Interaktion führen (SOAP Fault). Beispielwert: 483fdc6c-610a-456b-b697-ece275513c9a
pkm:ReportUserMessage 🠖pkm:ReportUserMessage	1..1	Die zu übermittelnde User Message. Anmerkung 1: Eine User Message ist eine Message, die "fachliche Inhalte" enthält, z.B. zu Getränkeverpackungen. Anmerkung 2: Der Zweck der Übermittlung einer User Message per ShareMessage Webservice-Interaktion kann einer der beiden folgenden sein: 1. ERSTMALIGE Übermittlung der Informationen an die Behörde 2. AKTUALISIERUNG von bereits zuvor über die Schnittstelle an die Behörde übermittelten Informationen, z.B. Korrektur oder Ergänzung Anmerkung 3: Das Webservice kann übermittelte User Messages nur dann verarbeiten, wenn diese eine inhaltliche Vollständigkeit aufweisen und ein allfälliges Nicht-Auftreten von Tätigkeiten im Berichtszeitraum korrekt abbilden. Die Schnittstellenbeschreibung erläutert dies in den Abschnitten zu Message-Vollständigkeit und zu Leerinhalten.

ShareMessageResponseType

ShareMessageResponseType Schema diagram

Output der ShareMessage-Operation.

Name/Typ	min..max	Definition
ServiceInterfaceVersionID 🠖pkm:VersionIdentifier	1..1	Konstante, die vom Webservice an den Client zurückgegeben wird, und die Version der Schnittstellenspezifikation angibt, die auf Webservice-Seite umgesetzt ist. Anmerkung: Dieses Element ist für Debugging-Zwecke gedacht. Begrenzungen: Die Zeichenkette besteht aus maximal 8 Zeichen Die Zeichenkette setzt sich aus den folgenden Teilen zusammen: "Major Version", gefolgt von einem Punkt (#x2E), gefolgt von der "Minor Version" Sowohl "Major Version" als auch "Minor Version" bestehen ausschließlich aus Ziffern Die "Minor Version" besteht aus GENAU 2 Ziffern Die "Major Version" besteht aus MINDESTENS 1 Ziffer Beispielwert: 1.00
ServiceVersionID 🠖pkm:RelaxedIdentifierContent	1..1	Software-Version des Webservice-EDI-Knotens. Anmerkung 1: Dieses Element ist für Debugging-Zwecke gedacht. Begrenzungen: Die Zeichenkette besteht aus maximal 64 Zeichen Die Zeichenkette besteht aus mindestens 1 Zeichen Die Zeichenkette ist ein sogenanntes Token: Das 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 Beispielwert: 13.4.13
pkm:SignalMessage 🠖pkm:SignalMessage	1..1	Vom Webservice automatisiert generierte Information zum Ergebnis der Verarbeitung der empfangenen User Message, ggf. inklusive Ergebnis der formalen Prüfung der empfangenen User Message. Anmerkung 1: Der Inhalt von Signal Messages, ggf. inklusive Prüfprotokoll zum Ergebnis von formalen Prüfungen, ist dazu bestimmt, Benutzern angezeigt zu werden. Die Inhalte haben den Zweck, Benutzern zu helfen, unbeabsichtigte/unerwünschte Datenkonstellationen zu erkennen und ggf. zu korrigieren. In dem Fall, dass das Webservice die empfangene User Message automatisiert abgelehnt hat, liefern die Inhalte der Signal Message Benutzern Hinweise darauf, was zu tun ist, z.B. welche Angaben zu ergänzen oder anzupassen sind, damit eine neuerliche Übermittlung erfolgreich ist. Anmerkung 2: Wichtigster Inhalt einer Signal Message ist das Element SignalID. Enthält das Element SignalID den Wert ACCEPTED, dann war die Übermittlung an die Behörde erfolgreich. Enthält es den Wert REJECTED, dann war die Übermittlung an die Behörde NICHT erfolgreich. In letzterem Fall hat die Behörde weder Zugriff auf die Daten, deren Übermittlung versucht wurde, noch erfährt sie vom Übermittlungsversuch. In beiden Fällen, ACCEPTED und REJECTED, kann die Signal Message ein nichtleeres Prüfprotokoll enthalten.

Datentypen

Message-Formate

Message-Arten

Im Getränkeverpackungen Einwegpfand Webservice kommen 2 Message-Arten zum Einsatz:

Code	Bezeichnung	Typ	XML Element
`RPT_BVG.YEAR`	Einweggetränkeverpackungen Jahresbericht der zentralen Stelle gemäß § 24 Abs. 1 [PfandVO]	User Message	`ReportUserMessage`
n/a	Signal Message	Signal Message	`SignalMessage`

Message-Arten Inhalte

Code	Bezeichnung	Inhalte
`RPT_BVG.YEAR`	Einweggetränkeverpackungen Jahresbericht	(a) Inverkehrsetzung von bepfandeten Einweggetränkeverpackungen § 24 Abs. 1 Z 1 [PfandVO] (b) Zurücknahme von bepfandeten Einweggetränkeverpackungen § 24 Abs. 1 Z 2 [PfandVO] (c) von Erstinverkehrsetzern zum Recycling übergebene Einweggetränkeverpackungen und recyclierte Verpackungsmaterialien § 24 Abs. 1 Z 3 [PfandVO] (d) von der zentralen Stelle zum Recycling übergebene Einweggetränkeverpackungen und recyclierte Verpackungsmaterialien § 24 Abs. 1 Z 4 [PfandVO] (e) In der Herstellung von PET-Getränkeflaschen und sonstigen Einwegkunststoff-Getränkeflaschen eingesetztes Recyclat § 24 Abs. 1 Z 5 [PfandVO]
n/a	Signal Message	Vom Webservice automatisiert generierte Information zum Status der Verarbeitung einer an die Behörde übermittelten Message, z.B. Annahme oder Ablehnung.

Erläuterungen zur Message-Art-Untergliederung

Das Getränkeverpackungen Einwegpfand Webservice sieht vor, dass Übermittlungen, für welche die gleichen Übermittlungsfrequenzen und Fristen gelten, innerhalb einer einzelnen gemeinsamen Message erfolgen.

Konkret bedeutet das Folgendes:

Dass die zentrale Stelle alle Inhalte gemäß § 24 Abs. 1 [PfandVO] in einer gemeinsamen Message übermittelt;
Dass die zentrale Stelle folglich erst dann an die Behörde übermittelt, sobald ihr zum Berichtsjahr alle Daten gemäß § 24 Abs. 1 [PfandVO] vorliegen, und nicht bereits bei Vorliegen einzelner der Daten (z.B. Vorliegen der Daten zu Z 1 ohne Vorliegen der Daten zu Z 3);
Dass die zentrale Stelle auch im Falle von Korrekturen oder Aktualisierungen jeweils alle in der Message-Art vorgesehenen Inhalte übermittelt, und nicht nur jene, die sich im Vergleich zur vorherigen Übermittlung geändert haben.

Siehe dazu auch die Abschnitte Message-Vollständigkeit und Korrekturen und Aktualisierungen.

Unterstützte Übermittlungs-Richtungen je Message-Art

Code	Bezeichnung	Unterstützte Übermittlung-Richtungen
`RPT_BVG.YEAR`	Einweggetränkeverpackungen Jahresbericht	Business-to-Authority (B2A) Client zu Webservice
n/a	Signal Message	Authority-to-Business (A2B) Webservice zu Client

Message-Formate Überblick

ReportUserMessage

Das Wesentlichste zum Aufbau einer ReportUserMessage:

Die Message kann mehrere Teile enthalten (MessagePart). Jeder Message-Teil besitzt genau einen per Code aus ↗Codeliste 3974 identifizierten Inhaltstyp (ContentTypeID), z.B. Von Erstinverkehrsetzern in Österreich in Verkehr gesetzte bepfandete Einweggetränkeverpackungen. Alle Inhalte eines Typs müssen im selben Message-Teil enthalten sein, d.h. es darf innerhalb einer Message nicht mehrere Teile desselben Typs geben;
Jeder Einweggetränkeverpackungen Jahresbericht der zentralen Stelle muss genau 7 Message-Teile enthalten, also für jeden der für diese Message-Art definierten Inhaltstypen genau einen Teil. Der Abschnitt Message-Vollständigkeit beschreibt das im Detail. Sofern im Berichtszeitraum keine dem Inhaltstyp entsprechende Tätigkeiten erfolgt sind, z.B. die zentrale Stelle keine Einweggetränkeverpackungen zum Recycling übergeben hat, ist der betreffende Message-Teil als leer zu deklarieren. Der Abschnitt Leerinhalte beschreibt das im Detail;
Innerhalb eines Message-Teils befindet sich eine Auflistung (Event) von je nach Inhaltstyp gruppierten Massen (MassValue) und/oder Anzahlen (Count) von Einweggetränkeverpackungen bzw. Verpackungsmaterialien. Die Event-Unterelemente sind abgesehen von MassValue und Count allesamt Gruppierungskriterien, z.B. nach Packstoff (MaterialTypeID), Getränkekategorie (BeverageTypeID) oder Getränkevolumen-Kategorie (BeverageVolumeID). Je Message-Teil darf jede Kombination aus Gruppierungskriterien nicht öfter als einmal auftreten. Beispielsweise darf für den Inhaltstyp "Von Erstinverkehrsetzern in Österreich in Verkehr gesetzte bepfandete Einweggetränkeverpackungen" ein Message-Teil zur selben Kombination aus Packstoff. Getränkekategorie und Getränkevolumen-Kategorie nicht mehrere Masse- und/oder Anzahl-Angaben enthalten;
Um den [XSD]-Aufbau einfach zu halten, definiert die Schnittstellenspezifikation nicht per [XSD], welche Gruppierungskriterien für welchen Inhaltstyp benötigt werden bzw. unterstützt werden - gemäß [XSD] ist keines der Event-Unterelemente zwingend erforderlich - sondern spezifiziert dies per Referenzdaten. Konkret enthält jeder Inhaltstyp-Code aus ↗Codeliste 3974 einen .cSTRCT-Teil, und ↗Codeliste 8261 definiert, welcher .cSTRCT-Wert welche Event-Unterelemente erfordert und unterstützt. Beispielsweise besitzt der Code für den Inhaltstyp "Von Erstinverkehrsetzern in Österreich in Verkehr gesetzte bepfandete Einweggetränkeverpackungen" einen Teil .cSTRCT20, und aus ↗Codeliste 8261 geht aus den STRCT20-Einträgen hervor, dass für diesen Inhaltstyp das Event-Element genau die Unterelemente MaterialTypeID (Packstoff), BeverageTypeID (Getränkekategorie), BeverageVolumeID (Getränkevolumen-Kategorie), MassValue (Masse), und Count (Anzahl) enthalten muss. Welche Gruppierungskriterien bei welchem Inhaltstyp zum Einsatz kommen, das illustrieren zudem die im Spezifikationspaket enthaltenen [XML]-Beispieldateninstanzen. Der Abschnitt Inhaltstyp-Codes und deren Aufbau enthält eine genauere Beschreibung des Aufbaus von Inhaltstyp-Codes;
Einzelne Inhaltstypen verlangen die Angabe von Recyclingunternehmen (RecoveryParty) und Recyclingstandort (RecoverySite), z.B. der Inhaltstyp "Von Erstinverkehrsetzern zum Recycling übergebene Massen an Verpackungsmaterialien ". Die Identifikation erfolgt für gewöhnlich über in edm.gv.at zum Unternehmen bzw. zum Standort eingetragene IDs (Identifikationszeichenketten) in RecoveryPartyID bzw. RecoverySiteID, ist alternativ aber auch per Name und Adresse unter ListedData sowie Bezugnahme mittels "lokaler" IDs in RecoveryPartyLocalReferenceID bzw. RecoverySiteLocalReferenceID möglich. Der Abschnitt Identifikation von Recyclingunternehmen und Recyclingstandorten beschreibt das im Detail.

SignalMessage

Das Wesentlichste zum Aufbau einer SignalMessage:

Wichtigster Inhalt ist das Signal unter SignalID. Der Wert ACCEPTED zeigt an, dass das Webservice die Übermittlung an die Behörde verarbeiten konnte, und die Behörde in Folge Zugriff auf die übermittelten Daten hat. Der Wert REJECTED zeigt an, dass die Übermittlung nicht erfolgreich war. Im REJECTED-Fall hat die Behörde keinen Zugriff auf die Daten, deren Übermittlung versucht wurde, und erfährt auch nicht vom Übermittlungsversuch. Es liegt hier also am Datenübermittler, den Grund für die automatische Zurückweisung der Datenübermittlung festzustellen und ggf. weitere Datenübermittlungsversuche zu unternehmen;
Die Signal Message kann ein Element MessageFormalValidationReport enthalten, und zwar sowohl im ACCEPTED als auch im REJECTED Fall. Dabei handelt es sich um das Prüfprotokoll, also das Ergebnis der vom Webservice auf die übermittelten Daten angewandten formalen Prüfungen. Dieses Prüfprotokoll ist für Endbenutzer auf Seite des Datenübermittlers bestimmt. Detailliertere Informationen zu den formalen Prüfungen befinden sich im Abschnitt Formale Prüfungen.

Inhaltstyp-Codes und deren Aufbau

In jedem Teil einer User Message definiert der Wert im Element ContentTypeID die Art der Inhalte des betreffenden Message-Teils.

Die Webservice-Spezifikation nutzt für das ContentTypeID-Element die Inhaltstypen-↗Codeliste 3974 statisch. Die unterstützten Werte sind direkt in den [XSD]-Dateien als Enumeration hinterlegt. Siehe auch Statische und dynamische Nutzung von Codelisten.

Die ↗Codeliste 3974 enthält für jeden Inhaltstyp einen Code, eine Bezeichnung und eine Beschreibung der Rechtsgrundlage.

Nachfolgend zur Illustration die 7 für das Getränkeverpackungen Einwegpfand Webservice relevanten Einträge der ↗Codeliste 3974:

Code	Kurzbezeichnung	Rechtsgrundlage
`RPT_BVG.YEAR.dPG.aPLC_MKT.tHH.cSTRCT20`	Von Erstinverkehrsetzern in Österreich in Verkehr gesetzte bepfandete Einweggetränkeverpackungen	§ 24 Abs. 1 Z 1 Pfandverordnung für Einweggetränkeverpackungen
`RPT_BVG.YEAR.dPG.aSEP_CLT.tHH.cSTRCT20`	Zurückgenommene bepfandete Einweggetränkeverpackungen	§ 24 Abs. 1 Z 2 Pfandverordnung für Einweggetränkeverpackungen
`RPT_BVG.YEAR.dPG.aHND_RCV.tHH.cSTRCT21`	Von Erstinverkehrsetzern zum Recycling übergebene Massen an Verpackungsmaterialien aus im Rahmen des Vorkaufsrechts übernommenen Einweggetränkeverpackungen	§ 24 Abs. 1 Z 3 Pfandverordnung für Einweggetränkeverpackungen
`RPT_BVG.YEAR.dPG.aRECOVER.tHH.cSTRCT14`	Recyclierte Verpackungsmaterialien aus von Erstinverkehrsetzern im Rahmen des Vorkaufsrechts übernommenen und zum Recycling übergebenen Einweggetränkeverpackungen	§ 24 Abs. 1 Z 3 Pfandverordnung für Einweggetränkeverpackungen
`RPT_BVG.YEAR.dPG.aHND_RCV.tHH.bC.cSTRCT21`	Von der zentralen Stelle zum Recycling übergebene Massen an Verpackungsmaterialien	§ 24 Abs. 1 Z 4 Pfandverordnung für Einweggetränkeverpackungen
`RPT_BVG.YEAR.dPG.aRECOVER.tHH.bC.cSTRCT14`	Recyclierte Verpackungsmaterialien aus von der zentralen Stelle zum Recycling übergebenen Einweggetränkeverpackungen	§ 24 Abs. 1 Z 4 Pfandverordnung für Einweggetränkeverpackungen
`RPT_BVG.YEAR.dPG.aRECOVER.tHH.cSTRCT07`	Masse des eingesetzten Recyclats bezogen auf die in Verkehr gesetzten bepfandeten Einweggetränkeverpackungen aus Kunststoff	§ 24 Abs. 1 Z 5 Pfandverordnung für Einweggetränkeverpackungen

Die ↗Codeliste 3974 besitzt noch eine Reihe weiterer Einträge. Diese weiteren in der obenstehenden Tabelle nicht abgebildeten Einträge spielen jedoch für die per Getränkeverpackungen Einwegpfand Webservice übermittelbaren Inhalte keine Rolle, sondern besitzen eine Bedeutung in Zusammenhang mit anderen Verpackungs-bezogenen Meldungen, z.B. jener der Sammel- und Verwertungssysteme für Verpackungen.

Aus der obenstehenden Tabelle ist ersichtlich, dass die Inhaltstyp-Codes einen besonderen Aufbau besitzen:

Die ersten 12 Stellen identifizieren die Message-Art aus ↗Codeliste 8686, zu welcher der Inhaltstyp gehört. Das Getränkeverpackungen Einwegpfand Webservice unterstützt ausschließlich die Message-Art Einweggetränkeverpackungen Jahresbericht der zentralen Stelle gemäß §24 Abs. 1 [PfandVO]. Diese Message-Art besitzt in ↗Codeliste 8686 den Code RPT_BVG.YEAR, wobei YEAR anzeigt, dass es sich um eine jährliche Meldung handelt, und RPT_BVG für single use beverage packaging report steht;
Der .d Domain (Fachgebiet)-Teil zeigt an, ob es beim Inhalt um Verpackungen geht (.dPG) oder um Einwegkunststoffprodukte (.dPR). Da es bei den via Getränkeverpackungen Einwegpfand Webservice an die Behörde übermittelbaren Inhalten ausschließlich um Verpackungen geht, besitzen alle der in diesen Übermittlungen verwendbaren Inhaltstypen den Domain-Code .dPG;
Der .a Activity (Tätigkeit)-Teil zeigt an, auf welche Tätigkeit sich der betreffende Inhalt bezieht. Bei den via Getränkeverpackungen Einwegpfand Webservice an die Behörde übermittelbaren Inhalten treten die folgenden Tätigkeiten auf:
1. .aPLC_MKT: Inverkehrsetzen (placing on the market)
2. .aSEP_CLT: Zurücknehmen, getrennt sammeln (separate collection)
3. .aHND_RCV: Zur Verwertung bzw. zum Recycling übergeben (hand over for recovery)
4. .aRECOVER: Verwerten bzw. Recyclieren (recover)
Der .t Typ-Teil zeigt an, ob sich der Inhalt auf Haushaltsverpackungen (.tHH) oder gewerbliche Verpackungen (.tCM) bezieht. Alle per Getränkeverpackungen Einwegpfand Webservice an die Behörde übermittelbaren Inhalte beziehen sich auf Haushaltsverpackungen;
Der optionale .b Body (Stelle) Teil zeigt an, auf die Tätigkeit welcher Stelle sich die Inhalte beziehen. In den Übermittlungen per Getränkeverpackungen Einwegpfand Webservice beziehen sich die Inhalte der beiden Inhaltstypen mit .bC-Teil (central body) auf von der zentralen Stelle selbst initiierte Tätigkeiten (Übergaben zum Recycling). Bei den anderen 5 Inhaltstypen geht es hingegen um von Erstinverkehrsetzern initiierte Tätigkeiten;
Der .c Class (Datenstruktur) Teil zeigt an, welche XML-Datenelemente für die jeweiligen Inhalte benötigt bzw. nicht benötigt werden. Dazu kann der jeweilige STRCT-Wert in ↗Codeliste 8261 nachgeschlagen werden. Konkret kommen in den Getränkeverpackungen Einwegpfand Webservice Übermittlungen an die Behörde die folgenden Strukturen zum Einsatz:
1. STRCT07: Masse (MassValue) des eingesetzten Recyclats je Getränkeflaschen-Art (PET-Getränkeflaschen oder sonstige Kunststoff-Getränkeflaschen, SingleUsePlasticBottleTypeID);
2. STRCT14: Masse (MassValue) von Verpackungsmaterialien je Packstoff (MaterialTypeID), Recyclingunternehmen (RecoveryPartyID bzw. RecoveryPartyLocalReferenceID), Recyclingstandort (RecoverySiteID bzw. RecoverySiteLocalReferenceID) und Verwertungsart (RecoveryTypeID). Anmerkung: Der Abschnitt Identifikation von Recyclingunternehmen und Recyclingstandorten enthält genauere Informationen dazu, wie Recyclingunternehmen und Recyclingstandorte in den Übermittlungen an die Behörde anzugeben sind;
3. STRCT20: Masse (MassValue) und Anzahl (Count) von Einweggetränkeverpackungen je Packstoff (MaterialTypeID) - beim Packstoff Kunststoff zusammen mit Getränkeflaschen-Art (PET-Getränkeflaschen oder sonstige Kunststoff-Getränkeflaschen, SingleUsePlasticBottleTypeID) - Getränkekategorie (BeverageTypeID) und Getränkevolumen-Kategorie (BeverageVolumeID);
4. STRCT21: Masse (MassValue) von Verpackungsmaterialien je Packstoff (MaterialTypeID), Recyclingunternehmen (RecoveryPartyID bzw. RecoveryPartyLocalReferenceID) und Recyclingstandort (RecoverySiteID bzw. RecoverySiteLocalReferenceID). Anmerkung: Der Abschnitt Identifikation von Recyclingunternehmen und Recyclingstandorten enthält genauere Informationen dazu, wie Recyclingunternehmen und Recyclingstandorte in den Übermittlungen an die Behörde anzugeben sind.

Einleitung zur Beschreibung der Message-Formate

Die Umweltbundesamt GmbH hat die nachfolgende Beschreibung automatisiert aus einer annotierten, also um Beschreibungstexte angereicherten, Variante der [XSD]-Datei pack_deposit_refund_message.xsd generiert. Das Spezifikationspaket enthält diese annotierte Variante der Datei nicht. Auf Anfrage stellt die Die Umweltbundesamt GmbH die annotierte Variante der Datei gerne bereit. Bitte dafür den EDM Helpdesk zu kontaktieren. Siehe Kontakt.

Verzeichnis

Strukturen

ReportUserMessage

SignalMessage

MessageValidationContext

Substrukturen

CountryList

CountryListElement

FormalValidationReport

ListedData

Party

PartyRegisterList

PartyRegisterListElement

Period

ReportEvent

RegisteredEconomicOperator

RegisteredSite

ReportUserMessagePart

Site

ValidationNodeIndividualData

ValidationNodeIndividualDataRegistration

ValidationNodeReferenceData

Datentypen

BeverageTypeIdentifier

BeverageTypeIdentifierContent

BeverageVolumeIdentifier

BeverageVolumeIdentifierContent

CountryIdentifier

CountryIdentifierContent

CountryTwoLetterIdentifierContent

DateContent

DescriptionContent

DesignationContent

DocumentScopeAssignmentIdentifier

DocumentScopeReferenceIdentifierContent

EconomicOperatorIdentifier

EconomicOperatorRegisterIdentifierContent

GLNIdentifierContent

IndicatorContent

MassUnitIdentifierContent

MassValue

NameContent

PackagingMaterialTypeIdentifier

PackagingMaterialTypeIdentifierContent

PostalAreaIdentifierContent

RecoveryTypeIdentifier

RecoveryTypeIdentifierContent

RelaxedIdentifierContent

ReportUserMessagePartTypeIdentifier

ReportUserMessagePartTypeIdentifierContent

ReportUserMessageTypeIdentifier

ReportUserMessageTypeIdentifierContent

ShortNameContent

SignalIdentifierContent

SingleUsePlasticBottleTypeIdentifier

SingleUsePlasticBottleTypeIdentifierContent

SiteIdentifier

SiteIdentifierContent

SiteRegisterIdentifierContent

TimestampContentType

TrillionCountContent

UUIDIdentifierContent

ValidationResultIdentifierContent

ValueContent

VersionIdentifier

Strukturen

ReportUserMessage

ReportUserMessage Schema diagram

User Message mit Angaben zu Getränkeverpackungen für ein Kalenderjahr, für Übermittlungen der zentralen Stelle an die Behörde.

Name/Typ	min..max	Definition
MessageUUID pkm:UUIDIdentifierContent	1..1	Ein Universally Unique Identifier (UUID) der Version 4 (Zufalls-UUID), der dieser Message von Software bei der Message-Erstellung (Marshalling) zugewiesen wird. Anmerkung 1: Das Datenformat setzt die Abbildung von UUIDs in kanonischer Darstellung voraus. Siehe Beispielwert für eine Illustration der kanonischen Darstellung einer UUID. Anmerkung 2: Dieses Element ist für Debugging-Zwecke gedacht. Beispielwert: 88f69853-f0fb-400e-85a6-d4ab8e4e0027
MessageCreationUTCTimestamp pkm:TimestampContentType	1..1	Ein UTC-Zeitstempel, der den Zeitpunkt angibt, zu dem diese Message-XML-Instanz von Software erzeugt wurde (Marshalling). Anmerkung 1: Dieses Element ist für Debugging-Zwecke gedacht. Begrenzungen: Muss die Bestandteile Jahr, Monat, Tag, Stunde, Minute, Sekunde, Sekundenbruchteil und Zeitzone enthalten; Für die Bestandteile Jahr, Monat, Tag, Stunde, Minute und Sekunde gelten die durch xs:dateTime definierten Begrenzungen. Beispielsweise muss der Monat mit zwei Dezimalziffern ausgedrückt werden, wobei 01 für Jänner steht und 12 für Dezember; Für Sekundenbruchteile ist eine Genauigkeit von exakt 6 Dezimalziffern vorgegeben. Abweichend zu der für xs:dateTime definierten kanonischen Darstellung müssen im vorliegenden Format auch nachstehende Nullen mit angegeben sein; Als Zeitzone ist ausschließlich UTC zulässig. Anmerkung 2: Es gibt formale Prüfungen mit Bezug zum Message-Erstellungszeitpunkt, z.B. Prüfung R737, die besagt, dass ein in der Zukunft liegender Message-Erstellungszeitpunkt unzulässig ist. Beispielwert: 2026-03-25T11:01:35.524380Z
MessageCreationDataFormatVersionID pkm:VersionIdentifier	1..1	Identifikation der (neuesten) Datenformatversion, welche die Software, mit welcher diese Message erstellt wurde, bei der Erstellung von Messages (Marshalling) unterstützt. Anmerkung 1: Dieses Element ist für Debugging-Zwecke gedacht. Anmerkung 2: Es handelt sich um einen statischen Wert, der von der die Message erstellenden Software geschrieben wird. Die Versionsinformation gibt NICHT an, ob die Message tatsächlich Datenelemente verwendet, welche nur die betreffende Version der Datenformatspezifikation vorsieht. Beispiel: Die Software, mit der die Message erstellt wurde, unterstützt v1.04 des Datenformats. Die Message enthält daher einen MessageCreationDataFormatVersionID-Wert von 1.04. Die betreffende Message KANN jedoch auch mit niedrigeren Versionen des Datenformats, wie z. B. 1.02, konform sein, wenn Datenelemente und Werte, die mit neueren Versionen des Formats eingeführt wurden, aufgrund der an die Behörde zu übermittelnden Inhalte zufällig nicht benötigt und verwendet werden. Begrenzungen: Die Zeichenkette besteht aus maximal 8 Zeichen; Die Zeichenkette setzt sich aus den folgenden Teilen zusammen: "Major Version", gefolgt von einem Punkt (#x2E), gefolgt von der "Minor Version"; Sowohl "Major Version" als auch "Minor Version" bestehen ausschließlich aus Ziffern; Die "Minor Version" besteht aus GENAU 2 Ziffern; Die "Major Version" besteht aus MINDESTENS 1 Ziffer. Beispielwert: 1.01
MessageCreationPartyID pkm:EconomicOperatorIdentifier	1..1	Identifikation der zentralen Stelle als Erstellerin der Message und Übermittlerin der Message per EDM Webservice an die Behörde, bestehend aus der Unternehmens-ID im MessageCreationPartyID-Content zusammen mit der Identifikation der Unternehmens-ID-Art im Attribut registerID. Anmerkung 1: Wenn die zentrale Stelle eine andere juristische Person mit der Zusammenstellung und Übermittlung von Informationen beauftragt, so wird an dieser Stelle dennoch die Identifikation der zentralen Stelle benötigt, und NICHT die Identifikation des beauftragten Dienstleisters. Ebensowenig wird an dieser Stelle die Identifikation eines IT-Dienstleisters benötigt. Anmerkung 2: Es wird ein Sender-seitiges Sicherstellen vorausgesetzt, dass der in MessageCreationPartyID angebenene Beteiligte tatsächlich der Message-Ersteller ist. Zu diesem Sender-seitigen Sicherstellen enthält die Schnittstellenspezifikation keine genaueren Vorgaben. Eine der Möglichkeiten für ein Sicherstellen ist beispielsweise, dass diejenige Software, aus der Heraus die Message-Übermittlung ausgelöst wird, die Identität des Übermittlungs-auslösenden Endbenutzers authentifiziert, und überprüft, dass dieser Benutzer die Autorisierung besitzt, für die zentrale Stelle solche Übermittlungen auszulösen. Anmerkung 3: Das Datenformat unterstützt an dieser Stelle die folgenden Arten von Identifikationszeichenketten: a. "GLN der öffentlichen Verwaltung", die zum Unternehmen im österreichischen Unternehmensregister eingetragen ist, in Kombination mit dem Wert »GLN.AT« im Attribut registerID; b. "EDM-GLN" (Global Location Number), in Kombination mit dem Wert »GLN.EDM« im Attribut registerID. Anmerkung 4: Damit die Übermittlung an die Behörde technisch möglich ist, muss die zentrale Stelle die Einhaltung der folgenden Voraussetzungen sicherstellen: a. Es gibt in edm.gv.at einen Registrierten-Eintrag für die zentrale Stelle. b. Die in der Message verwendete Identifikationszeichenkette, z.B. GLN der öffentlichen Verwaltung, ist in edm.gv.at zum Registrierten-Eintrag vorhanden. c. Der Webservice-Client ist in in edm.gv.at registriert, und edm.gv.at enthält die Eintragung einer Freischaltung des betreffenden Client, für die zentrale Stelle mit dem Webservice zu interagieren. Begrenzungen: Die Zeichenkette besteht aus maximal 64 Zeichen; Die Zeichenkette besteht aus mindestens 1 Zeichen; Die Zeichenkette ist ein sogenanntes Token: Das 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. Beispielwert: »9110032898689« in Kombination mit registerID-Attribut »GLN.AT« für die Identifikation der EWP Recycling Pfand Österreich gGmbH.
MessageTypeID pkm:ReportUserMessageTypeIdentifier	1..1	Identifikation der Message-Art. Unterstützte Werte (siehe auch edm.gv.at ↗Codeliste 8686): RPT_BVG.YEAR: Einweggetränkeverpackungen Jahresbericht der zentralen Stelle gemäß §24 Abs. 1 PfandVO
ReportPeriodStartDate pkm:DateContent	1..1	Beginndatum des Berichtszeitraums (erster Tag des Berichtszeitraums). Anmerkung 1: Für Jahresmeldungen muss es sich um den 1. Jänner des betreffenden Jahres handeln. Begrenzungen: xs:date-Wert, der die Bestandteile Jahr, Monat und Tag enthalten muss; Für die Bestandteile Jahr, Monat und Tag gelten die durch xs:date definierten Begrenzungen. Beispielsweise muss der Monat mit zwei Dezimalziffern ausgedrückt werden, wobei 01 für Jänner steht und 12 für Dezember. Beispielwert: 2025-01-01
ReportPeriodEndDate pkm:DateContent	1..1	Enddatum des Berichtszeitraums (letzter Tag des Berichtszeitraums). Anmerkung 1: Für Jahresmeldungen muss es sich um den 31. Dezember des betreffenden Jahres handeln. Begrenzungen: xs:date-Wert, der die Bestandteile Jahr, Monat und Tag enthalten muss; Für die Bestandteile Jahr, Monat und Tag gelten die durch xs:date definierten Begrenzungen. Beispielsweise muss der Monat mit zwei Dezimalziffern ausgedrückt werden, wobei 01 für Jänner steht und 12 für Dezember. Beispielwert: 2025-12-31
ListedData pkm:ListedData	0..1	Aufzählung von Beteiligten und/oder Standorten mit Name und Adresse. Anmerkung 1: Die ListedData-Subelemente bieten die Möglichkeit, RECYCLINGUNTERNEHMEN und RECYCLINGSTANDORTE mit Name, Adresse und ggf. IDs anzuführen. Andere Inhalte sieht ListedData NICHT vor. Anmerkung 2: Bitte den Abschnitt der Schnittstellenbeschreibung zur Identifikation von Recyclingunternehmen und Recyclingstandorten zu beachten. Ein ListedData-Eintrag wird NUR für solche Unternehmen bzw. Standorte erwartet, die in edm.gv.at (noch) nicht eingetragen sind. Da österreichische Recyclingunternehmen und Recyclingstandorte für gewöhnlich in edm.gv.at eingetragen sind, sollte ListedData üblicherweise KEINE Einträge österreichischer Unternehmen bzw. österreichischer Standorte enthalten. Anmerkung 3: Jedes Unternehmen und jeder Standort soll nicht öfter als 1 Mal in ListedData auftreten, auch dann, wenn die User Message in Message-Teilen (MessagePart) auf dieses Unternehmen bzw. diesen Standort per LocalReferenceID mehrfach Bezug nimmt.
MessagePart pkm:ReportUserMessagePart	0..*	Message-Teil. Anmerkung 1: Jeder Message-Teil besitzt einen Inhaltstyp. Der Wert des Unterlements ContentTypeID definiert diesen Inhaltstyp. Anmerkung 2: Es gibt formale Prüfungen mit Bezug zu Message-Teilen. Insbesondere darf gemäß Prüfung R344 innerhalb einer Message jeder Inhaltstyp nicht öfter als ein Mal vorkommen, d.h. innerhalb einer Message dürfen je zwei Message-Teile NICHT vom selben Inhaltstyp sein.

ReportUserMessage wird verwendet in: MessageValidationContext

SignalMessage

SignalMessage Schema diagram

Automatisiert generierte Information zum Ergebnis der Verarbeitung der empfangenen User Message, ggf. inklusive Ergebnis der formalen Prüfung der empfangenen User Message.

Anmerkung 1: Der Inhalt von Signal Messages, ggf. inklusive Prüfprotokoll zum Ergebnis von formalen Prüfungen, ist dazu bestimmt, Benutzern angezeigt zu werden. Die Inhalte haben den Zweck, Benutzern zu helfen, unbeabsichtigte/unerwünschte Datenkonstellationen zu erkennen und ggf. zu korrigieren. In dem Fall, dass das Webservice die empfangene User Message automatisiert abgelehnt hat, liefern die Inhalte der Signal Message Benutzern Hinweise darauf, was zu tun ist, z.B. welche Angaben zu ergänzen oder anzupassen sind, damit eine neuerliche Übermittlung erfolgreich ist.

Anmerkung 2: Wichtigster Inhalt einer Signal Message ist das Element SignalID. Enthält das Element SignalID den Wert ACCEPTED, dann war die Übermittlung an die Behörde erfolgreich. Enthält es den Wert REJECTED, dann war die Übermittlung an die Behörde NICHT erfolgreich. In letzterem Fall hat die Behörde weder Zugriff auf die Daten, deren Übermittlung versucht wurde, noch erfährt sie vom Übermittlungsversuch. In beiden Fällen, ACCEPTED und REJECTED, kann die Signal Message ein nichtleeres Prüfprotokoll enthalten.

Name/Typ	min..max	Definition
SignalMessageUUID pkm:UUIDIdentifierContent	1..1	Ein Universally Unique Identifier (UUID) der Version 4 (Zufalls-UUID), der dieser Signal Message von Software bei der Message-Erstellung (Marshalling) zugewiesen wird. Anmerkung 1: Das Datenformat setzt die Abbildung von UUIDs in kanonischer Darstellung voraus. Siehe Beispielwert für eine Illustration der kanonischen Darstellung einer UUID. Anmerkung 2: Dieses Element ist für Debugging-Zwecke gedacht. Beispielwert: dbc8df75-8234-4860-a671-67bc24cdb816
SignalMessageCreationUTCTimestamp pkm:TimestampContentType	1..1	Ein UTC-Zeitstempel, der den Zeitpunkt angibt, zu dem diese Signal Message-XML-Instanz von Software erzeugt wurde (Marshalling). Anmerkung: Dieses Element ist für Debugging-Zwecke gedacht. Begrenzungen: Muss die Bestandteile Jahr, Monat, Tag, Stunde, Minute, Sekunde, Sekundenbruchteil und Zeitzone enthalten; Für die Bestandteile Jahr, Monat, Tag, Stunde, Minute und Sekunde gelten die durch xs:dateTime definierten Begrenzungen. Beispielsweise muss der Monat mit zwei Dezimalziffern ausgedrückt werden, wobei 01 für Jänner steht und 12 für Dezember; Für Sekundenbruchteile ist eine Genauigkeit von exakt 6 Dezimalziffern vorgegeben. Abweichend zu der für xs:dateTime definierten kanonischen Darstellung müssen im vorliegenden Format auch nachstehende Nullen mit angegeben sein; Als Zeitzone ist ausschließlich UTC zulässig. Beispielwert: 2022-03-25T11:01:35.524380Z
SignalMessageCreationDataFormatVersionID pkm:VersionIdentifier	1..1	Identifikation der (neuesten) Datenformatversion, welche die Software, mit welcher diese Signal Message erstellt wurde, bei der Erstellung von Messages (Marshalling) unterstützt. Anmerkung 1: Dieses Element ist für Debugging-Zwecke gedacht. Anmerkung 2: Es handelt sich um einen statischen Wert, der von der die Signal Message erstellenden Software geschrieben wird. Die Versionsinformation gibt NICHT an, ob die Message tatsächlich Datenelemente verwendet, welche nur die betreffende Version der Datenformatspezifikation vorsieht. Begrenzungen: Die Zeichenkette besteht aus maximal 8 Zeichen; Die Zeichenkette setzt sich aus den folgenden Teilen zusammen: "Major Version", gefolgt von einem Punkt (#x2E), gefolgt von der "Minor Version"; Sowohl "Major Version" als auch "Minor Version" bestehen ausschließlich aus Ziffern; Die "Minor Version" besteht aus GENAU 2 Ziffern; Die "Major Version" besteht aus MINDESTENS 1 Ziffer. Beispielwert: 1.01
SignalMessageTransformationDataFormatVersionID pkm:VersionIdentifier	0..1	Identifikation der Datenformatversion, in welche die ursprüngliche Signal Message aus Kompatibilitätsgründen konvertiert wurde. Anmerkung 1: Dieses Element darf nur dann vorhanden sein bzw. eingefügt werden, wenn eine Datenformatversion-Konvertierung stattgefunden hat. Anmerkung 2: Eine Versionsumwandlung wird dann und nur dann angewendet, wenn der Empfänger in einem Datenaustausch nicht die Version des Datenformats unterstützt, in der die Message beim Sender vorliegt, sondern nur eine niedrigere Version unterstützt. Folglich muss diese Version niedriger sein als die MessageCreationDataFormatVersion. Beispielwert: 1.00
ValidationNodeName pkm:ShortNameContent	1..1	Name der Software, unter welcher jene Software Benutzern bekannt ist, welche die Signal Message auf Basis einer empfangenen User Message automatisiert generiert hat. Anmerkung: Das Getränkeverpackungen Einwegpfand Webservice sieht dieses Element nur zwecks Einheitlichkeit mit anderen in edm.gv.at angewandten Datenaustausch-Protokollen vor. Das Getränkeverpackungen Einwegpfand Webservice setzt dieses Element konstant auf den Wert »edm.gv.at«. Beispielwert: edm.gv.at
ReferredUserMessageUUID pkm:UUIDIdentifierContent	1..1	Ein Universally Unique Identifier (UUID) der Version 4 (Zufalls-UUID), welcher die empfangene User Message identifiziert, auf deren Verarbeitung/Entgegennahme sich die Inhalte des Signals beziehen. Anmerkung 1: Das Datenformat setzt die Abbildung von UUIDs in kanonischer Darstellung voraus. Siehe Beispielwert für eine Illustration der kanonischen Darstellung einer UUID. Anmerkung 2: Die Software, die versucht eine User Message entgegenzunehmen - also das Getränkeverpackungen Einwegpfand Webservice - kopiert die in der empfangenen User Message enthaltene Message-UUID in dieses Element der Signal Message. Beispielwert: fa140a8e-54c5-494f-8bd8-79edb0462c91
ReferredUserMessageTypeID pkm:ReportUserMessageTypeIdentifierContent	1..1	Identifikation der Art der empfangenen User Message, auf welche sich die Signal Informationen beziehen. Anmerkung: Die Software, die versucht eine User Message entgegenzunehmen - also das Getränkeverpackungen Einwegpfand Webservice - kopiert die in der empfangenen User Message enthaltene Message-Art in dieses Element der Signal Message. Unterstützte Werte (siehe auch edm.gv.at ↗Codeliste 8686): RPT_BVG.YEAR: Einweggetränkeverpackungen Jahresbericht der zentralen Stelle gemäß §24 Abs. 1 PfandVO
ReferredTransactionUUID pkm:UUIDIdentifierContent	1..1	Ein Universally Unique Identifier (UUID) der Version 4 (Zufalls-UUID), welcher den Bezug zur Webservice-Interaktion herstellt, mit der die Übermittlung einer User Message versucht wurde. Anmerkung 1: Das Datenformat setzt die Abbildung von UUIDs in kanonischer Darstellung voraus. Siehe Beispielwert für eine Illustration der kanonischen Darstellung einer UUID. Anmerkung 2: Die Software, die versucht eine User Message entgegenzunehmen - also das Getränkeverpackungen Einwegpfand Webservice - kopiert den Inhalt des TransactionUUID-Elements aus jener Webservice-Interaktion, mit der die Übermittlung der User Message initiiert wurde, in dieses Element der Signal Message. Beispielwert: 483fdc6c-610a-456b-b697-ece275513c9a
SignalID pkm:SignalIdentifierContent	1..1	Automatisiert generierte Signalisierung des Gesamtergebnisses der Verarbeitung einer empfangenen User Message. Unterstützte Werte: ACCEPTED: Die Software hat die empfangene User Message akzeptiert. Der Message-Empfang ist für Benutzer auf Empfangsseite ersichtlich, und die Inhalte der empfangenen Message sind für Benutzer auf Empfangsseite zugänglich (ggf. in Abhängigkeit von Rollen und Rechten); REJECTED: Die Software hat die empfangene User Message automatisiert abgelehnt. Auf der Empfangsseite ist für Benutzer im Allgemeinen weder der Übermittlungsversuch ersichtlich, noch sind für diese Benutzer die Inhalte der User Message zugänglich. Anmerkung: Im Fall REJECTED (abgelehnt) ist es für die Benutzer auf der Empfangsseite der User Message Übermittlung so, als ob keine Übermittlung stattgefunden hätte. Weitere Schritte, z.B. das Ergänzen von Daten und der erneute Versuch der Übermittlung, können in einem solchen Fall also für gewöhnlich ausschließlich von Benutzern auf Senderseite eingeleitet werden.
ReceiverFailureIndicator pkm:IndicatorContent	0..1	Ja-/Nein-Angabe dazu, ob für die Ablehnung der empfangenen User Message ein von der Sender-Seite unabhängiger, rein der Empfängerseite zuzuordnender Grund vorliegt. Anmerkung 1: Eine Signal Message MUSS einen ReceiverFailureIndicator enthalten, wenn die SignalID auf REJECTED gesetzt ist. In anderen Fällen DARF sie KEINEN ReceiverFailureIndicator enthalten. Anmerkung 2: »true« steht für eine Ablehnung, die UNABHÄNGIG vom Absender auftritt, z.B. unabhängig von den Inhalt der gesendeten User Message. Beispiel für solch einen Grund ist etwa die Nicht-Verfügbarkeit einer Datenbankverbindung auf Empfängerseite. Eine Signal Message mit einem auf »true« gesetzten ReceiverFailureIndicator ist vergleichbar mit einem SOAP 1.2 Fault mit einem auf den Wert "soap12:Receiver" gesetzten Fault/Code. »true« gibt Benutzern auf Senderseite die Gewissheit, dass eine Behebung des Übermittlungsproblems nur mit Involvierung der Empfängerseite möglich ist. Anmerkung 3: »false« steht für eine Ablehnung, deren Gründe NICHT eindeutig ausschließlich der Empfängerseite zuordenbar sind. Für Benutzer auf Senderseite ist dies als Hinweis zu verstehen, dass eine Chance besteht (wenn auch keine Gewissheit), das Übermittlungsproblem ohne Involvierung der Empfängerseite lösen zu können. Unterstützte Werte: true, false, 1, 0
SignalDescription pkm:DescriptionContent	0..1	Eine natürlichsprachliche Beschreibung des Signals. Anmerkung 1: Dieses Element ist für natürlichsprachliche Inhalte vorgesehen, die NICHT aus einer formalen Prüfung der User Message resultieren. Das Ergebnis einer allfällig durchgeführten formalen Prüfung befindet sich hingegen im Element MessageFormalValidationReport. Anmerkung 2: Wie die natürlichsprachlichen Texte in MessageFormalValidationReport ist auch der SignalDescription-Text dafür vorgesehen, Benutzern angezeigt zu werden. Anmerkung 3: Dieses Datenformat sieht natürlichsprachige Angaben ausschließlich in Deutsch vor. Begrenzungen: Die Zeichenkette besteht aus maximal 1000 Zeichen; Die Zeichenkette besteht aus mindestens 1 Zeichen.
MessageFormalValidationResultID pkm:ValidationResultIdentifierContent	0..1	Das Gesamtergebnis einer formalen Prüfung der empfangenen User Message. Unterstützte Werte (siehe auch edm.gv.at ↗Codeliste 6099): OK: Die formale Prüfung hat KEINE Datenkonstellationen erkannt, die auf unvollständige oder fehlerhafte Daten hinweisen würden, oder auf nicht den Vorgaben entsprechende beschriebene Tätigkeiten oder Objekte. D.h. die formale Prüfung ergab keine Hinweise auf Aspekte, die von Benutzern überprüft werden sollten; INFO: Die formale Prüfung hat Datenkonstellationen erkannt, die darauf hinweisen, dass (a) Daten unvollständig oder fehlerhaft, z.B. inkonsistent, sind, und/oder (b) beschriebene Tätigkeiten oder Objekte nicht den Vorgaben entsprechen, z.B. rechtlichen Bestimmungen oder behördlichen Auflagen, oder (c) beschriebene Tätigkeiten oder Objekte Eigenschaften aufweisen, die in der Praxis selten auftreten; WARNING: Die formale Prüfung hat Datenkonstellationen erkannt, die darauf hinweisen, dass (a) Daten unvollständig oder fehlerhaft, z.B. inkonsistent, sind, und/oder (b) beschriebene Tätigkeiten oder Objekte nicht den Vorgaben entsprechen, z.B. rechtlichen Bestimmungen oder behördlichen Auflagen; ERROR: Die formale Prüfung hat Datenkonstellationen erkannt, die darauf hinweisen, dass (a) Daten unvollständig oder fehlerhaft, z.B. inkonsistent, sind, und/oder (b) beschriebene Tätigkeiten oder Objekte nicht den Vorgaben entsprechen, z.B. rechtlichen Bestimmungen oder behördlichen Auflagen. Anmerkung 1: Das Signal muss nicht notwendigerweise Informationen zu einer formalen Prüfung und deren Ergebnissen enthalten. Z.B. kann das Auftreten einer Exception dazu führen, dass das Web Service gar keine formale Prüfung der empfangenen User Message durchführt. In einem solchen Fall enthält das Signal KEIN Element MessageFormalValidationResultID. Anmerkung 2: Zur Kombination der Elemente INFO, WARNING und ERROR in den Prüfprotokolleinträgen (Element MessageFormalValidationReport) und dem daraus resultierenden Gesamtergebnis (MessageFormalValidationResultID): OK: Das Prüfprotokoll ist "leer", d.h. es enthält weder INFO-, WARNING- noch ERROR-Einträge; INFO: Das Prüfprotokll enthält ausschließlich INFO-Einträge. Es enthält weder WARNING- noch ERROR-Einträge; WARNING: Das Prüfprotokoll enthält KEINE ERROR-Einträge. Es enthält mindestens einen WARNING-Eintrag. Darüber hinaus kann es auch INFO-Einträge enthalten; ERROR: Das Prüfprotokoll enthält mindestens einen ERROR-Eintrag. Darüber hinaus kann es auch INFO- und/oder WARNING-Einträge enthalten. Anmerkung 3: Ein Gesamtergebnis ERROR führt zur automatischen Zurückweisung einer empfangenen User Message. Ein Gesamtergebnis ERROR im Element MessageFormalValidationResultID kann daher nur in Kombination mit dem Inhalt REJECTED im Element SignalID auftreten. Anmerkung 4: Ein zu Anmerkung 3 umgekehrter Schluss ist NICHT zutreffend: Eine Software kann eine empfangene User Message auch dann automatisiert zurückweisen (REJECTED-Wert in SignalID), wenn sie die formale Prüfung durchgeführt hat und diese formale Prüfung OK, INFO oder WARNING ergibt. Die Zurückweisung ist dann nicht auf die formale Prüfung zurückzuführen, sondern auf andere Gründe, z.B. Nicht-Verfügbarkeit einer Datenbankverbindung auf Empfängerseite.
MessageFormalValidationReport pkm:FormalValidationReport	0..1	Das Prüfprotokoll zur formalen Prüfung der empfangenen User Message im Schematron Validation Report Language (SVRL)-Format. Anmerkung: Das Signal muss nicht notwendigerweise Informationen zu einer formalen Prüfung und deren Ergebnissen enthalten.

MessageValidationContext

MessageValidationContext Schema diagram

Eine User Message zusammen mit Kontextinformationen aus edm.gv.at. Diese Datenzusammenstellung dient als Grundlage für die formale Prüfung der User Message.

Anmerkung: In den Inputs und Outputs des Getränkeverpackungen Einwegpfand Webservice kommt diese Struktur NICHT vor. Vielmehr verwendet das Webservice diese Struktur intern zur Durchführung der formalen Prüfungen. Dementsprechend spielt diese Struktur für die Umsetzung einer Anbindung an das Getränkeverpackungen Einwegpfand Webservice keine unmittelbare Rolle.

Name/Typ	min..max	Definition
pkm:ReportUserMessage pkm:ReportUserMessage	1..1	Die empfangene User Message mit Angaben zu Einweggetränkeverpackungen. Der Rest des Validierungskontexts enthält aus edm.gv.at ausgelesene Kontextinformation zur empfangenen Message, z.B. Referenzdaten oder Stammdaten.
InteractingEDINodeID pkm:RelaxedIdentifierContent	0..1	Die ID des Webservice-Clients, der mit dem Getränkeverpackungen Einwegpfand Webservice interagiert, für jene Webservice-Interaktion, aus der die User Message in ReportUserMessage stammt. Anmerkung: Das Getränkeverpackungen Einwegpfand Webservice befüllt dieses Element mit der Client-ID aus jener Webservice-Interaktion, aus der die User Message in ReportUserMessage stammt.
EDIInteractionUTCTimestamp pkm:TimestampContentType	0..1	Ein vom Getränkeverpackungen Einwegpfand Webservice generierter UTC-Zeitstempel, der den Zeitpunkt des Empfangs der User Message angibt.
ValidationNodeName pkm:ShortNameContent	0..1	Name, unter der jene Software, welche die empfangene Message formalen Prüfungen unterzieht, Benutzern bekannt ist. Anmerkung 1: Die per Schematron definierten formalen Prüfungen verwenden diesen Namen ggf. in Prüfprotokoll-Texten. Anmerkung 2: Das Getränkeverpackungen Einwegpfand Webservice setzt dieses Element konstant auf den Wert »edm.gv.at«.
ValidationNodeIndividualData pkm:ValidationNodeIndividualData	0..1	Einzelne Datensätze, die bereits vor dem Empfang der Message in edm.gv.at vorhanden sind. und für die formale Prüfung der empfangenen Message relevant sind. Das Getränkeverpackungen Einwegpfand Webservice befüllt dieses Element auf Basis von in der empfangenen User Message enthaltenen Angaben, z.B. auf Basis von in der User Message enthaltenen IDs von Recyclingunternehmen und Recyclingstandorten. Beispiele: Datensätze zu in edm.gv.at registrierten Unternehmen (für in der empfangenen Message referenzierte Recyclingunternehmen); Datensätze zu in edm.gv.at registrierten Standorten (für in der empfangenen Message referenzierte Reyclingstandorte).
ValidationNodeReferenceData pkm:ValidationNodeReferenceData	0..1	In edm.gv.at vorhandene Referenzdaten, die für die formale Prüfung der empfangenen Message relevant sind. Beispiel: ISO 3166-1-Länderliste

Substrukturen

CountryList

CountryList Schema diagram

Liste von per ISO 3166-1 3-Ziffern Codes identifizierten Staaten.

Name/Typ	min..max	Definition
ListElement pkm:CountryListElement	0..512	Eintrag in der Staatenliste.

CountryList wird verwendet in: ValidationNodeReferenceData

CountryListElement

CountryListElement Schema diagram

Eintrag in einer Staaten/Länder-Referenzliste.

Name/Typ	min..max	Definition
CountryID pkm:CountryIdentifier	1..1	3-Ziffern-ID, die gemäß ISO 3166-1 den Staat identifiziert. Beispiele: 040: Österreich 056: Belgien 276: Deutschland 380: Italien 756: Schweiz
CountryTwoLetterID pkm:CountryTwoLetterIdentifierContent	0..1	Zwei-Buchstaben-ID ("alpha-2"), die gemäß ISO 3166-1 den Staat identifiziert. Beispiele: AT: Österreich BE: Belgien DE: Deutschland IT: Italien CH: Schweiz
ValidityStartDate pkm:DateContent	0..1	Gültigkeitsbeginn des Eintrags, d.h. Datum (Tag), an dem der Staat gemäß ISO 3166-1 zu existieren beginnt. Anmerkung: Für Listeneinträge, zu welchen kein Gültigkeitsbeginn verzeichnet ist, MUSS ValidityStartDate entfallen.
ValidityEndDate pkm:DateContent	0..1	Gültigkeitsende des Eintrags, d.h. Datum (Tag), an dem gemäß ISO 3166-1 die Existenz des Staates endet. Anmerkung: Für Listeneinträge, zu welchen kein Gültigkeitsende verzeichnet ist, MUSS ValidityEndDate entfallen.

CountryListElement wird verwendet in: CountryList

FormalValidationReport

FormalValidationReport Schema diagram

Ergebnis der formalen Prüfung einer empfangenen User Message, im Schematron Validation Report Language (SVRL)-Format.

Name/Typ	min..max	Definition
svrl:schematron-output svrl:schematron-output	1..1	Ergebnis der formalen Prüfung einer empfangenen User Message, im Schematron Validation Report Language (SVRL)-Format. Anmerkung: SVRL unterstützt Rich-Text-Formatierungen in Prüfprotokoll-Eintragstexten (svrl:text-Elemente), z.B. emph-Elemente zur Hervorhebung bestimmter Wörter im Text. Davon macht das vorliegende Datenformat KEINEN Gebrauch, d.h. alle Prüfprotokoll-Eintragstexte sind "plain text" ohne "Markup". Das vorliegende Datenformat verwendet aus diesem Grund, und zur Vereinfachung der Umsetzung einer Schnittstellenanbindung, eine svrl.xsd-Schema-Definition, die von den Autoren des Datenformats so angepasst wurde, dass Rich Text Markup NICHT unterstützt/vorgesehen ist.

FormalValidationReport wird verwendet in: SignalMessage

ListedData

ListedData Schema diagram

Aufzählung von Beteiligten und/oder Standorten mit Name und Adresse.

Name/Typ	min..max	Definition
Party pkm:Party	0..*	Liste von Unternehmen mit Angaben zu Name, Adresse und ggf. IDs. Anmerkung 1: ListedData/Party bietet die Möglichkeit, RECYCLINGUNTERNEHMEN mit Name, Adresse und ggf. IDs zu benennen. Andere Inhalte sieht ListedData/Party NICHT vor. Anmerkung 2: Das Datenformat sieht vor, ausschließlich solche Recyclingunternehmen durch Name, Adresse und ggf. IDs zu benennen, welche NICHT in edm.gv.at eingetragen und über die Registerabfrage auffindbar sind. Anmerkung 3: Für in der Message per Element Event/RecoveryPartyID identifizierte Unternehmen darf ListedData/Party KEINEN Eintrag enthalten. Anmerkung 4: Recyclingunternehmen mit (Haupt-)Sitz in Österreich sind im Allgemeinen in edm.gv.at eingetragen und über die Registerabfrage auffindbar. Message-Ersteller sollen Recyclingunternehmen mit (Haupt-)Sitz in Österreich daher im Allgemeinen NICHT in ListedData/Party eintragen. Siehe formale Prüfung R202. Anmerkung 5: In der Message erfolgt die Benennung von Unternehmen, soweit sie nicht durch Bezugnahme auf einen edm.gv.at Eintrag per Element Event/RecoveryPartyID möglich ist, durch Bezugnahme auf Einträge aus “ListedData/Party” per Element Event/RecoveryPartyLocalReferenceID. Anmerkung 6: Für jeden Unternehmens-Eintrag in ListedData/Party muss zutreffen, dass es innerhalb der Message einen oder mehrere Event/RecoveryPartyLocalReferenceID-Bezüge auf dieses Unternehmen gibt. D.h. die Message darf nur Angaben zu solchen Unternehmen enthalten, für welche die Message Recyclingunternehmen-Bezüge enthält. Siehe formale Prüfung R372. Anmerkung 7: Für jedes Unternehmen darf ListedData/Party nicht mehr als einen Eintrag enthalten, d.h. Angaben zum selben Unternehmen dürfen in ListedData/Party nicht mehrfach enthalten sein.
Site pkm:Site	0..*	Liste von Standorten, mit Angaben zu Name und Adresse. Anmerkung 1: ListedData/Site bietet die Möglichkeit, RECYCLINGSTANDORTE mit Name und Adresse zu benennen. Andere Inhalte sieht ListedData/Site NICHT vor. Anmerkung 2: Das Datenformat sieht vor, dass Message-Ersteller in Messages ausschließlich solche Recyclingstandorte durch Name und Adresse benennen, welche NICHT in edm.gv.at eingetragen und über die Registerabfrage auffindbar sind. Anmerkung 3: Für in der Message per Element Event/RecoverySiteID identifizierte Recyclingstandorte darf ListedData/Site KEINEN Eintrag enthalten. Anmerkung 4: Recyclingstandorte in Österreich sind im Allgemeinen in edm.gv.at eingetragen und über die Registerabfrage auffindbar. Message-Ersteller sollen Verwertungsstandorte in Österreich daher im Allgemeinen NICHT in ListedData/Site eintragen. Siehe formale Prüfung R123. Anmerkung 5: In der Message erfolgt die Benennung von Standorten, soweit sie nicht durch Bezugnahme auf einen edm.gv.at Eintrag per Element Event/RecoverySiteID möglich ist, durch Bezugnahme auf Einträge aus “ListedData/Site” per Element Event/RecoverySiteLocalReferenceID. Anmerkung 6: Für jeden Standort-Eintrag in ListedData/Site muss zutreffen, dass es innerhalb der Message einen oder mehrere Event/RecoverySiteLocalReferenceID-Bezüge auf diesen Standort-Eintrag gibt. D.h. die Message darf nur Angaben zu solchen Standorten enthalten, für welche die Message Recyclingstandort-Bezüge enthält. Siehe formale Prüfung R495. Anmerkung 7: Für jeden Standort darf ListedData/Site nicht mehr als einen Eintrag enthalten, d.h. Angaben zum selben Standort dürfen in ListedData/Site nicht mehrfach enthalten sein.

ListedData wird verwendet in: ReportUserMessage

Party

Party Schema diagram

Angaben zu einem Recyclingunternehmen, z.B. Name und Sitzadresse.

Name/Typ	min..max	Definition
LocalAssignmentID pkm:DocumentScopeAssignmentIdentifier	1..1	Im Kontext der Message-Instanz verwendete lokale Identifikationszeichenkette für das Recyclingunternehmen. Anmerkung 1: Die ID MUSS lokal, d.h. innerhalb der Message-Instanz, eindeutig sein. Es darf also innerhalb der Dateninstanz NICHT zwei oder mehr LocalAssignmentID-Elemente mit demselben Inhalt geben. Das gilt über ALLE LocalAssignmentID-Elemente hinweg, d.h. Eindeutigkeit über alle Party-Einträge hinweg alleine ist NICHT ausreichend. Anmerkung 2: Das Datenformat setzt KEINE über die Message-Instanz hinausgehende Eindeutigkeit der ID voraus. D.h. in zwei verschiedenen Message-Instanzen kann dieselbe Identifikationszeichenkette für unterschiedliche Inhalte stehen, z.B. unterschiedliche Unternehmen. Anmerkung 3: Da global eindeutige IDs, z.B. Umsatzsteuer-Identifikationsnummern, auch lokal eindeutig sind, ist es zulässig (aber nicht erforderlich), in LocalAssignmentID global eindeutige IDs zu verwenden. Dabei ist zu beachten, dass Recyclingunternehmen in der Message nach Möglichkeit über die in edm.gv.at zum Unternehmen eingetragene GLN zu identifizieren sind, durch Eintrag in ReportUserMessage/MessagePart/Event/RecoveryPartyID, und ListedData/Party in diesem Fall KEINEN Eintrag für das Unternehmen enthalten darf. Begrenzungen: Die Zeichenkette besteht aus maximal 64 Zeichen; Die Zeichenkette besteht aus mindestens 1 Zeichen; Die Zeichenkette genügt der xs:ID-Syntax. Insbesondere darf sie nur aus Buchstaben, Ziffern und wenigen sonstigen Zeichen wie Underscore (#x5F) bestehen.
ID pkm:EconomicOperatorIdentifier	0..1	Identifikation des Unternehmens, bestehend aus der Unternehmens-ID im ID-Content zusammen mit der Identifikation der Unternehmens-ID-Art im Attribut registerID. Anmerkung 1: Dynamisch verwendete Codeliste - edm.gv.at ↗Codeliste 7411 definiert die Menge der an dieser Stelle unterstützten ID-Arten, und somit die im Attribut registerID unterstützten ID-Art-Werte. Anmerkung 2: Da das Datenformat vorsieht, in ListedData/Party nur solche Recyclingunternehmen einzutragen, die NICHT in edm.gv.at registriert sind, unterstützt das Datenformat an dieser Stelle die ID-Art "EDM-GLN" (Code »GLN.EDM«) NICHT. Anmerkung 3: Optionale Angabe in Ergänzung zu Name und Adresse, die dazu genutzt werden kann, Datenempfängern die Identifikation des Unternehmens zu erleichtern. Begrenzungen: Die Zeichenkette besteht aus maximal 64 Zeichen; Die Zeichenkette besteht aus mindestens 1 Zeichen; Die Zeichenkette ist ein sogenanntes Token: Das 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. Beispielwert: »DE319559121« (für PreZero Stiftung & Co. KG, 74172 Neckarsulm, Deutschland) im Element-Content, in Kombination mit Wert »VAT.EU« (für Europäische MwSt-Nummer) im Attribut registerID.
Name pkm:NameContent	0..1	Name des Unternehmens bzw. der nicht-natürlichen Person. Anmerkung: Jeder Eintrag eines Unternehmens in ListedData/Party erfordert die Angabe des Unternehmensnamens. Siehe formale Prüfung R467. Begrenzungen: Die Zeichenkette besteht aus maximal 120 Zeichen; Die Zeichenkette besteht aus mindestens 1 Zeichen; Die Zeichenkette ist ein sogenanntes Token: Das 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.
RegisteredOfficeAddressCountryID pkm:CountryIdentifier	0..1	Identifikation des Landes, in dem das Unternehmen seinen (Haupt-)Sitz hat, mittels dreistelligem numerischen ISO 3166-1 Code. Beispiel: Code 276 für Deutschland Anmerkung 1: Die Menge der unterstützten Werte ist in der EDM ↗Codeliste 3862 definiert, welche die Einträge des ISO 3166-1 Standards wiedergibt. Anmerkung 2: Es handelt sich um eine DYNAMISCHE Codelistenreferenz. Das bedeutet, dass Software, die Dateninstanzen dieses Datenformats liest und schreibt, auf Änderungen in der Codeliste vorbereitet sein muss, insbesondere auf das Hinzufügen von Einträgen, und zwar unabhängig von Änderungen des Datenformats. Die jeweils aktuelle Version der EDM ↗Codeliste 3862 kann von der Website edm.gv.at sowie über ein Codelisten-Webservice abgerufen werden. Anmerkung 3: Anstelle der bekannteren zweistelligen Buchstabencodes nutzt das Datenformat dreistellige numerische ISO 3166-1 Codes. Der Grund hierfür liegt darin, dass nur die dreistelligen Codes über längere Zeiträume, z. B. mehrere Jahre, garantiert eindeutig sind. So hat ISO beispielsweise den Buchstabencode CS sowohl der Tschechoslowakei (bis 1993) als auch Serbien und Montenegro (von 2003 bis 2006) zugewiesen. Anmerkung 4: Jeder Eintrag eines Unternehmens in ListedData/Party erfordert die Angabe des Unternehmenssitz-Landes. Siehe formale Prüfung R467.
RegisteredOfficeAddressPostalAreaID pkm:PostalAreaIdentifierContent	0..1	Postleitzahl der (Haupt-)Sitz-Adresse des Unternehmens. Anmerkung: Jeder Eintrag eines Unternehmens in ListedData/Party erfordert die Angabe der Unternehmenssitz-Postleitzahl. Siehe formale Prüfung R467. Begrenzungen: Die Zeichenkette besteht aus maximal 10 Zeichen; Die Zeichenkette besteht aus mindestens 1 Zeichen; Die Zeichenkette ist ein sogenanntes Token: Das 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.
RegisteredOfficeAddressCityName pkm:NameContent	0..1	Name des Orts, in dem das Unternehmen seinen (Haupt-)Sitz hat. Anmerkung: Jeder Eintrag eines Unternehmens in ListedData/Party erfordert die Angabe der Unternehmenssitz-Ortsbezeichnung. Siehe formale Prüfung R467. Begrenzungen: Die Zeichenkette besteht aus maximal 120 Zeichen; Die Zeichenkette besteht aus mindestens 1 Zeichen; Die Zeichenkette ist ein sogenanntes Token: Das 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.

Party wird verwendet in: ListedData

PartyRegisterList

PartyRegisterList Schema diagram

Referenzliste von Registern bzw. Registrierungsverfahren für Unternehmen und andere nicht-natürliche Personen.

Name/Typ	min..max	Definition
ListElement pkm:PartyRegisterListElement	0..128	Eintrag in der Liste von Registern bzw. Registrierungsverfahren.

PartyRegisterList wird verwendet in: ValidationNodeReferenceData

PartyRegisterListElement

PartyRegisterListElement Schema diagram

Eintrag in einer Referenzliste von Beteiligten-Registern bzw. Registrierungsverfahren.

Name/Typ	min..max	Definition
RegisterID pkm:EconomicOperatorRegisterIdentifierContent	1..1	ID des Registers bzw. Registrierungsverfahrens. Beispiele: GLN.AT: Österreichische GLN der öffentlichen Verwaltung GLN.EDM: EDM-GLN (Elektronisches Datenmanagement - Umwelt - Global Location Number) VAT.EU: Europäische MwSt-Nummer
RegisterName pkm:NameContent	0..1	Bezeichnung des Registers bzw. Registrierungsverfahrens.
ValidityStartDate pkm:DateContent	0..1	Gültigkeitsbeginn des Eintrags, d.h. Datum (Tag), an dem das Register/Registrierungsverfahren im Getränkeverpackungen Einwegpfand Webservice erstmals verwendbar ist/war. Anmerkung: Für Listeneinträge, zu welchen kein Gültigkeitsbeginn verzeichnet ist, entfällt ValidityStartDate.
ValidityEndDate pkm:DateContent	0..1	Gültigkeitsende des Eintrags, d.h. Datum (Tag), an dem das Register/Registrierungsverfahren im Getränkeverpackungen Einwegpfand Webservice letztmalig verwendbar ist/war. Anmerkung: Für Listeneinträge, zu welchen kein Gültigkeitsende verzeichnet ist, entfällt ValidityEndDate.

PartyRegisterListElement wird verwendet in: PartyRegisterList

Period

Period Schema diagram

Angaben zu einem Zeitraum.

Name/Typ	min..max	Definition
StartDate pkm:DateContent	0..1	Beginndatum des Zeitraums, d.h. erster Tag des Zeitraums. Anmerkung 1: Bei Angaben zur Stilllegung handelt es sich um das Datum der Stilllegung. Anmerkung 2: Bei Angaben zur Ruhendstellung handelt es sich um das Datums des Beginns der Ruhendstellung.
EndDate pkm:DateContent	0..1	Enddatum des Zeitraums. Anmerkung 1: Bei Angaben zu einer Stilllegung handelt es sich, sofern eine Reaktivierung vorliegt und bekannt und erfasst ist, um den letzten Tag der Stilllegung vor Reaktivierung. Wenn keine Reaktivierung bekannt und erfasst ist, dann entfällt das EndDate-Element. Anmerkung 2: Bei Angaben zu einer Ruhendstellung handelt es sich, sofern bekannt und erfasst ist, wann die Ruhendstellung endet, um das Datum des letzten Tags der Ruhendstellung. Wenn keine Beendigung der Ruhendstellung bekannt und erfasst ist, dann entfällt das EndDate-Element.

Period wird verwendet in: RegisteredEconomicOperator

ReportEvent

ReportEvent Schema diagram

Angaben zu einer Tätigkeit in Zusammenhang mit Einweggetränkeverpackungen, z.B. Inverkehrsetzung oder Zurücknahme.

Name/Typ	min..max	Definition
MassValue pkm:MassValue	0..1	Die Gesamtmasse der zur jeweiligen Einteilung/Gliederung gehörenden Einweggetränkeverpackungen bzw. Verpackungsmaterialien. Begrenzungen: Die Zeichenkette genügt der xs:decimal-Syntax; Insbesondere enthält die Zeichenkette gemäß xs:decimal-Syntax OPTIONAL ein Dezimaltrennzeichen; Insbesondere handelt es sich gemäß xs:decimal-Syntax beim Dezimaltrennzeichen um den Punkt (#x2E), und NICHT um das im deutschsprachigen Raum übliche Komma (#x2C); Insbesondere enthält die Zeichenkette gemäß xs:decimal-Syntax KEINE Tausendertrennzeichen oder sonstigen Zifferngruppierungszeichen; Insbesondere enthält die Zeichenkette gemäß xs:decimal-Syntax OPTIONAL ein »+«/»-« Vorzeichen, wobei Zeichenketten ohne Vorzeichen gleichbedeutend mit Zeichenketten mit »+«-Vorzeichen sind; Die Zeichenkette enthält mindestens 1 Dezimalstelle (Ziffer 0-9); Die Zeichenkette enthält maximal 25 Dezimalstellen (Ziffern 0-9); Die Zeichenkette enthält maximal 5 Nachkommastellen, d.h. von den maximal 25 Ziffern-Zeichen befinden sich maximal 5 HINTER einem Dezimaltrennzeichen; Der Wert ist größer oder gleich 0 (formale Prüfung R408). Beispielwert: 4835.7 Anmerkung: Es gibt formale Prüfungen zur Masse, z.B. Prüfung R162, Prüfung R408, Prüfung R529, Prüfung R953 und Prüfung R956.
Count pkm:TrillionCountContent	0..1	Die Gesamtanzahl zur jeweiligen Einteilung/Gliederung gehörenden Einweggetränkeverpackungen. Begrenzungen: Die Zeichenkette genügt der xs:integer-Syntax; Insbesondere enthält die Zeichenkette gemäß xs:integer-Syntax KEIN Dezimaltrennzeichen; Insbesondere enthält die Zeichenkette gemäß xs:integer-Syntax KEINE Tausendertrennzeichen oder sonstigen Zifferngruppierungszeichen; Insbesondere kann die Zeichenkette gemäß xs:integer-Syntax OPTIONAL ein »+«/»-« Vorzeichen enthalten, wobei Zeichenketten ohne Vorzeichen gleichbedeutend mit Zeichenketten mit »+«-Vorzeichen sind; Die Zeichenkette enthält maximal 14 Dezimalstellen (Ziffern 0-9); Die Zeichenkette enthält mindestens 1 Dezimalstelle; Der Wert ist nicht negativ (formale Prüfung R958). Beispielwert: 13850 Anmerkung 1: Die Begrenzung auf maximal 14 Dezimalstellen bedeutet, dass der höchste abbildbare Wert 100 Billionen (10^14) minus 1 ist, d.h. 99.999.999.999.999. Anmerkung 2: Es gibt formale Prüfungen zur Anzahl, z.B. Prüfung R162, Prüfung R507, Prüfung R953, Prüfung R958 und Prüfung R988.
MaterialTypeID pkm:PackagingMaterialTypeIdentifier	0..1	Der Packstoff, auf den sich die Angaben beziehen. Unterstützte Werte (siehe auch edm.gv.at ↗Codeliste 4824): 9008390106846: Eisenmetalle 9008390106853: Aluminium 9008390101476: Kunststoffe gemäß § 2 Abs. 10 Z 2 AWG 2002
SingleUsePlasticBottleTypeID pkm:SingleUsePlasticBottleTypeIdentifier	0..1	Die Art von Einwegkunststoff-Getränkeflasche, auf welche sich die Angaben beziehen. Unterstützte Werte (siehe auch edm.gv.at ↗Codeliste 9536): 9008390124970: Getränkebehälter - PET-Getränkeflaschen 9008390124987: Getränkebehälter - sonstige Kunststoff-Getränkeflaschen
BeverageTypeID pkm:BeverageTypeIdentifier	0..1	Die Getränkekategorie, auf die sich die Angaben beziehen. Anmerkung 1: Für die Angaben zu Einweggetränkeverpackungen kommt eine an § 14b Abfallwirtschaftsgesetz 2002 angelehnte Einteilung in Getränkekategorien zum Einsatz. Unterstützte Werte (siehe auch edm.gv.at ↗Codeliste 2311): 9008390132531: Bier 9008390132548: Wässer 9008390132555: Saft 9008390132562: Alkoholfreie Erfrischungsgetränke 9008390132586: Wein 9008390132593: Sekt und Spirituosen
BeverageVolumeID pkm:BeverageVolumeIdentifier	0..1	Die Getränkevolumen-Kategorie, auf die sich die Angaben beziehen. Unterstützte Werte (siehe auch edm.gv.at ↗Codeliste 6598): 9008390132609: bis inkl. 0,25 l 9008390132616: über 0,25 l bis inkl. 0,33 l 9008390132623: über 0,33 l bis inkl. 0,5 l 9008390132630: über 0,5 l bis inkl. 0,75 l 9008390132647: über 0,75 l bis inkl. 1 l 9008390132654: über 1 l bis inkl. 1,5 l 9008390132661: über 1,5 l
RecoveryTypeID pkm:RecoveryTypeIdentifier	0..1	Die Verwertungsart, auf die sich die Angaben beziehen. Anmerkung: Das Getränkeverpackungen Einwegpfand Webservice unterstützt ausschließlich die Angabe der Verwertungsart »Recycling«. Damit die Daten einen zu anderen Verpackungs-Meldungen, z.B. jenen der Sammel- und Verwertungssysteme, gleichartigen Aufbau besitzen und in Hinblick auf eindeutige Interpretierbarkeit der übermittelten Angaben verlangt die Schnittstellenspezifikation die Angabe in den entsprechenden Message-Teilen dennoch. Unterstützte Werte (siehe auch edm.gv.at ↗Codeliste 4399): 9008390125045: Recycling
RecoveryPartyID pkm:EconomicOperatorIdentifier	0..1	Identifikation des Recyclingunternehmens per in edm.gv.at zum Verwerter eingetragener Identifikationszeichenkette. Anmerkung 1: Für in edm.gv.at eingetragene Recyclingunternehmen soll ausschließlich diese RecoveryPartyID übermittelt werden. Name und Adresse des Unternehmens sollen in diesem Fall NICHT übermittelt werden, d.h. es soll zum Unternehmen in diesem Fall KEINEN Eintrag unter ListedData/Party geben. Anmerkung 2: Recyclingunternehmen mit Sitz in Österreich müssen für gewöhnlich entsprechend der im AWG 2002 definierten Registrierungsverpflichtungen in edm.gv.at eingetragen sein. Recyclingunternehmen mit Sitz in Österreich sollen in Datenübermittlungen daher genau über das RecoveryPartyID-Element identifiziert werden, nicht aber über Name und Adresse. Siehe formale Prüfung R202. Anmerkung 3: Die Identifikation ist wahlweise mit einer der in edm.gv.at Codeliste 7836 definierten ID-Arten möglich. Es ist NICHT erforderlich, alle Recyclingunternehmen in einer Message-Instanz mit derselben ID-Art zu identifizieren. So ist es beispielsweise zulässig, Unternehmen A per GLN der öffentlichen Verwaltung zu identifizieren, und Unternehmen B per EDM-GLN, unter der Voraussetzung, dass die registerID-Attribut-Werte jeweils passend gesetzt sind, namentlich auf »GLN.AT« für Unternehmen A, und »GLN.EDM« für Unternehmen B. Begrenzungen: Die Zeichenkette besteht aus maximal 64 Zeichen; Die Zeichenkette besteht aus mindestens 1 Zeichen; Die Zeichenkette ist ein sogenanntes Token: Das 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. Beispielwert: »9110015288193« in Kombination mit registerID-Attribut »GLN.AT« für die Identifikation des Verwerters Ecoplast Kunststoffrecycling GmbH.
RecoveryPartyLocalReferenceID pkm:DocumentScopeReferenceIdentifierContent	0..1	Identifikation des Recyclingunternehmens per Verweis auf einen Eintrag aus ListedData/Party. Anmerkung 1: Die hier enthaltene ID MUSS einer ID aus ListedData/Party/LocalAssignmentID entsprechen. Anmerkung 2: Der referenzierte ListedData/Party Eintrag enthält insbesondere Name und Sitzadresse des Recyclingunternehmens. Anmerkung 3: Die Möglichkeit, Recyclingunternehmen (in ListedData/Party) per Name und Adresse zu benennen, ist für in edm.gv.at (noch) nicht registrierte Unternehmen vorgesehen. Anmerkung 4: Recyclingunternehmen mit Sitz in Österreich müssen für gewöhnlich entsprechend der im AWG 2002 definierten Registrierungsverpflichtungen in edm.gv.at eingetragen sein. Recyclingunternehmen mit Sitz in Österreich sollen in Datenübermittlungen daher über das RecoveryPartyID-Element identifiziert werden, nicht aber über Name und Adresse. Entsprechend soll für Recyclingunternehmen mit Sitz in Österreich das RecoveryPartyLocalReferenceID-Element für gewöhnlich NICHT verwendet werden. Siehe formale Prüfung R202.
RecoverySiteID pkm:SiteIdentifier	0..1	Identifikation des Recyclingstandorts per edm.gv.at Standort-GLN. Anmerkung 1: Für in edm.gv.at eingetragene Recyclingstandorte soll ausschließlich diese RecoverySiteID übermittelt werden. Name und Adresse des Recyclingstandorts sollen in diesem Fall NICHT übermittelt werden, d.h. es soll zum Standort in diesem Fall KEINEN Eintrag unter ListedData/Site geben. Anmerkung 2: Recyclingstandorte in Österreich müssen für gewöhnlich entsprechend der im AWG 2002 definierten Registrierungsverpflichtungen in edm.gv.at eingetragen sein. Recyclingstandorte in Österreich sollen in Datenübermittlungen daher über das RecoverySiteID-Element identifiziert werden, nicht aber über Name und Adresse. Siehe formale Prüfung R123. Anmerkung 3: An dieser Stelle unterstützt das Datenformat die Identifikation des Recyclingstandorts ausschließlich per edm.gv.at-Standort-GLN. Daher unterstützt das Attribut registerID ausschließlich den Wert »GLN.EDM«. Begrenzungen: Genau 13 Zeichen, d.h. auch Leerstring unzulässig; Ausschließlich aus Ziffern (0-9) bestehend. Beispielwert: »9008390831878« in Kombination mit registerID-Attribut »GLN.EDM« für die Identifikation des Ecoplast Kunststoffrecycling GmbH Standorts Leibnitz.
RecoverySiteLocalReferenceID pkm:DocumentScopeReferenceIdentifierContent	0..1	Identifikation des Recyclingstandorts per Verweis auf einen Eintrag aus ListedData/Site. Anmerkung 1: Die hier enthaltene ID MUSS einer ID aus ListedData/Site/LocalAssignmentID entsprechen. Anmerkung 2: Der referenzierte ListedData/Site-Eintrag enthält Name und Adresse des Standorts. Anmerkung 3: Die Möglichkeit, Recyclingstandorte (in ListedData/Site) per Name und Adresse zu benennen, ist für Standorte vorgesehen, die für in edm.gv.at (noch) nicht eingetragene Standorte vorgesehen. Anmerkung 4: Recyclingstandorte in Österreich müssen für gewöhnlich entsprechend der im AWG 2002 definierten Registrierungsverpflichtungen in edm.gv.at eingetragen sein. Recyclingstandorte in Österreich sollen in Datenübermittlungen daher über das RecoverySiteID-Element identifiziert werden, nicht aber über Name und Adresse. Siehe formale Prüfung R123.

ReportEvent wird verwendet in: ReportUserMessagePart

RegisteredEconomicOperator

RegisteredEconomicOperator Schema diagram

Angaben zu einem Unternehmen oder einer anderen nicht-natürlichen oder natürlichen Person.

Name/Typ	min..max	Definition
PartyPublicAdminGLNID pkm:GLNIdentifierContent	0..1	GLN der öffentlichen Verwaltung, die zum Unternehmen in edm.gv.at eingetragen ist. Anmerkung 1: Die GLN der öffentlichen Verwaltung stammt aus dem von der Statistik Austria geführten Unternehmensregister. Anmerkung 2: GLNs (Global Location Numbers) müssen die folgenden Bedingungen einhalten: Genau 13 Zeichen, d.h. auch Leerstring unzulässig; Ausschließlich aus Ziffern (0-9) bestehend.
PartyEDMGLNID pkm:GLNIdentifierContent	0..1	GLN (Global Location Number), die in edm.gv.at als Haupt-Unternehmens-ID verwendet wird. Anmerkung 1: Dabei KANN es sich um die GLN der öffentlichen Verwaltung handeln, muss sich aber nicht notwendigerweise um eine GLN der öffentlichen Verwaltung handeln. Alternativ kann es sich um eine GLN aus einem spezifisch für edm.gv.at reservierten Nummernkreis handeln. Anmerkung 2: GLNs (Global Location Numbers) müssen die folgenden Bedingungen einhalten: Genau 13 Zeichen, d.h. auch Leerstring unzulässig; Ausschließlich aus Ziffern (0-9) bestehend.
PartyName pkm:NameContent	1..1	Unternehmensname.
PartyAddressText pkm:DescriptionContent	0..1	Unternehmens-Sitzadresse, angegeben als einfache Zeichenkette. Beispiel: »Saatwinkler Damm 42/43, 13627 Berlin, Deutschland«
RecoveryPartyIndicator pkm:IndicatorContent	0..1	Ja/Nein-Angabe dazu, ob es sich beim Unternehmen laut Eintragung in edm.gv.at um einen Abfallverwerter handelt oder nicht. Anmerkung: “Ja”, ausgedrückt durch den Wert »true« oder »1«, steht dafür, dass es sich um einen Abfallverwerter handelt.
BusinessSuspensionPeriod pkm:Period	0..1	In edm.gv.at eingetragene Angaben zur Stilllegung (Datum der Stilllegung, allfälliges Enddatum der Stilllegung bei Reaktivierung) der Wirtschaftstätigkeit des Unternehmens.
TemporaryBusinessSuspensionPeriod pkm:Period	0..1	In edm.gv.at eingetragene Angaben zur Ruhendstellung (erster Tag der Ruhendstellung, allfällig letzter Tag der Ruhendstellung) der Wirtschaftstätigkeit des Unternehmens.

RegisteredEconomicOperator wird verwendet in: ValidationNodeIndividualDataRegistration

RegisteredSite

RegisteredSite Schema diagram

Angaben zu einer Betriebsstätte (Standort).

Name/Typ	min..max	Definition
SiteEDMGLNID pkm:GLNIdentifierContent	0..1	GLN (Global Location Number), die in edm.gv.at als Haupt-Standort-ID verwendet wird. Anmerkung: GLNs (Global Location Numbers) müssen die folgenden Bedingungen einhalten: Genau 13 Zeichen, d.h. auch Leerstring unzulässig; Ausschließlich aus Ziffern (0-9) bestehend.
SiteName pkm:NameContent	1..1	Standortbezeichnung.
SiteAddressText pkm:DescriptionContent	0..1	Standortadresse, angegeben als einfache Zeichenkette. Beispiel: »Saatwinkler Damm 42/43, 13627 Berlin, Deutschland«
RecoverySiteIndicator pkm:IndicatorContent	0..1	Ja/Nein-Angabe dazu, ob es sich bei dem Standort laut den in edm.gv.at eingetragenen Genehmigungs-Daten um einen Abfallverwertungsstandort handelt oder nicht. Anmerkung: “Ja”, ausgedrückt durch den Wert »true« oder »1«, steht dafür, dass es sich um einen Abfallverwertungsstandort handelt.

RegisteredSite wird verwendet in: ValidationNodeIndividualDataRegistration

ReportUserMessagePart

ReportUserMessagePart Schema diagram

Message-Teil einer Berichts-User-Message, die für Übermittlungen an die Behörde gedacht ist.

Name/Typ	min..max	Definition
ContentTypeID pkm:ReportUserMessagePartTypeIdentifier	1..1	Identifikation des Inhaltstyps des Message-Teils (siehe auch edm.gv.at ↗Codeliste 3974). Anmerkung 1: Diese Datenformat-Spezifiikation setzt KEINE bestimmte Reihenfolge von Inhaltstypen innerhalb einer Message voraus, d.h. die Reihenfolge ist beliebig. Anmerkung 2: Je Message-Instanz darf jeder Inhaltstyp nicht mehr als 1 Mal vorkommen. Unterstützte Werte in der Message-Art »Einweggetränkeverpackungen Jahresbericht der zentralen Stelle gemäß §24 Abs. 1 PfandVO« (»RPT_BVG.YEAR«): RPT_BVG.YEAR.dPG.aPLC_MKT.tHH.cSTRCT20: Von Erstinverkehrsetzern in Österreich in Verkehr gesetzte bepfandete Einweggetränkeverpackungen (§ 24 Abs. 1 Z 1 Pfandverordnung für Einweggetränkeverpackungen) RPT_BVG.YEAR.dPG.aSEP_CLT.tHH.cSTRCT20: Zurückgenommene bepfandete Einweggetränkeverpackungen (§ 24 Abs. 1 Z 2 Pfandverordnung für Einweggetränkeverpackungen) RPT_BVG.YEAR.dPG.aHND_RCV.tHH.cSTRCT21: Von Erstinverkehrsetzern zum Recycling übergebene Massen an Verpackungsmaterialien aus im Rahmen des Vorkaufsrechts übernommenen Einweggetränkeverpackungen (§ 24 Abs. 1 Z 3 Pfandverordnung für Einweggetränkeverpackungen) RPT_BVG.YEAR.dPG.aRECOVER.tHH.cSTRCT14: Recyclierte Verpackungsmaterialien aus von Erstinverkehrsetzern im Rahmen des Vorkaufsrechts übernommenen und zum Recycling übergebenen Einweggetränkeverpackungen (§ 24 Abs. 1 Z 3 Pfandverordnung für Einweggetränkeverpackungen) RPT_BVG.YEAR.dPG.aHND_RCV.tHH.bC.cSTRCT21: Von der zentralen Stelle zum Recycling übergebene Massen an Verpackungsmaterialien (§ 24 Abs. 1 Z 4 Pfandverordnung für Einweggetränkeverpackungen) RPT_BVG.YEAR.dPG.aRECOVER.tHH.bC.cSTRCT14: Recyclierte Verpackungsmaterialien aus von der zentralen Stelle zum Recycling übergebenen Einweggetränkeverpackungen (§ 24 Abs. 1 Z 4 Pfandverordnung für Einweggetränkeverpackungen) RPT_BVG.YEAR.dPG.aRECOVER.tHH.cSTRCT07: Masse des eingesetzten Recyclats bezogen auf die in Verkehr gesetzten Einweggetränkeverpackungen (§ 24 Abs. 1 Z 5 Pfandverordnung für Einweggetränkeverpackungen)
ReportingObligationActivityIndicator pkm:IndicatorContent	1..1	Ja/Nein-Angabe dazu, ob für die Kombination aus Message-Berichtszeitraum und Message-Teil-Inhaltstyp Tätigkeiten erfolgt sind, die unter eine Meldeverpflichtung gemäß Abfallwirtschaftsgesetz bzw. Pfandverordnung für Einweggetränkeverpackungen fallen und von der zentralen Stelle gemeldet werden müssen. Anmerkung 1: Ein auf “Nein” (»false«) gesetztes ReportingObligationActivityIndicator-Element bedeutet, dass für die Kombination aus Berichtszeitraum und Inhaltstyp KEINE Tätigkeiten erfolgt sind, die unter die Meldeverpflichtung fallen und vom Message-Ersteller gemeldet werden müssten. Das kann einen der beiden folgenden Gründe haben: a. Gewöhnlicher Grund - “Leermeldungs-Deklaration”: Die betreffende Meldeverpflichtung ist in Kraft. Für die Kombination aus Berichtszeitraum und Inhaltstyp sind aber keine Tätigkeiten erfolgt, die unter die Meldeverpflichtung fallen und vom Message-Ersteller gemeldet werden müssten. b. Außergewöhnlicher Grund - Die betreffende Meldeverpflichtung ist (noch) nicht in Kraft. Anmerkung 2: Ein Message-Teil darf nur dann “leer” sein, d.h. kein Event-Element enthalten, wenn für den betreffenden Message-Teil in ReportingObligationActivityIndicator deklariert ist, dass KEINE Tätigkeiten erfolgt sind, die unter die betreffende Meldeverpflichtung fallen. Siehe formale Prüfuung R162 und Prüfung R953.
Event pkm:ReportEvent	0..*	Angaben zu einer im Message-Bezugszeitraum ausgeübten Tätigkeit in Zusammenhang mit Einweggetränkeverpackungen, z.B. Inverkehrsetzung, Zurücknahme oder Übergabe zum Recycling. Anmerkung 1: Der ContentTypeID-Inhaltstyp-Wert definiert die Art der Inhalte der Event-Instanzen. Anmerkung 2: Die Kombination der Werte aus ALLEN Unterelementen einer Event-Instanz AUSGENOMMEN MassValue und Count definiert eine Untergliederung, z.B. in Packstoffe oder Getränkekategorien. Zu jeder solchen Untergliederung darf jeder Message-Teil nicht mehr als 1 Angabe enthalten. Zwei oder mehr Massen/Anzahlen je Untergliederung sind nicht zulässig. Konkret ist also das Vorkommen von zwei oder mehr Event-Elemente mit derselben Kombination an Untergliederungs-Werten innerhalb eines Message-Teils nicht zulässig. Siehe auch formale Prüfung R273. Anmerkung 3: Software muss beim Erstellen einer Message darauf achten, nur für solche Untergliederungen Event-Einträge zu generieren, für die es tatsächlich Tätigkeiten im Berichtszeitraum gab und somit eine Masse und/oder Anzahl ungleich 0. D.h. Message-Instanzen dürfen keine Event-Einträge mit einer Masse oder Anzahl von 0 enthalten. Die Schnittstellenbeschreibung erläutert dies im Abschnitt “Wert 0 bei Masse/Anzahl”. Anmerkung 4: Der .cSTRCT-Teil des Inhaltstyps-Werts aus MessagePart/ContentTypeID bestimmt, welche der Unterelemente des MessagePart/Event-Elements benötigt werden bzw. nicht unterstützt werden. Dieser Zusammenhang ist in der Schnittstellenbeschreibung beschrieben, und in maschinell verarbeitbarer Form in edm.gv.at ↗Codeliste 8261 abgebildet. Siehe formale Prüfung R529 und Prüfung R988. Beipiel: Bei einem .cSTRCT07-Inhaltstyp werden genau die Unterelemente MassValue (Masse an eingesetztem Recyclat) und SingleUsePlasticBottleTypeID (Art von Einwegkunststoff-Getränkeflasche) erwartet. Andere Unterelemente, z.B. RecoveryPartyID, dürfen zu einem solchen Inhaltstyp hingegen nicht im Event-Element enthalten sein.

ReportUserMessagePart wird verwendet in: ReportUserMessage

Site

Site Schema diagram

Angaben zu einem Recyclingstandort, z.B. Name und Adresse.

Name/Typ	min..max	Definition
LocalAssignmentID pkm:DocumentScopeAssignmentIdentifier	1..1	Im Kontext der Message-Instanz verwendete lokale Identifikationszeichenkette für den Recyclingstandort. Anmerkung 1: Die ID MUSS lokal, d.h. innerhalb der Message-Instanz, eindeutig sein. Es darf also innerhalb der Dateninstanz NICHT zwei oder mehr LocalAssignmentID-Elemente mit demselben Inhalt geben. Das gilt über ALLE LocalAssignmentID-Elemente hinweg, d.h. Eindeutigkeit über alle Site-Einträge hinweg alleine ist NICHT ausreichend. Anmerkung 2: Das Datenformat setzt KEINE über die Message-Instanz hinausgehende Eindeutigkeit der ID voraus. D.h. in zwei verschiedenen Message-Instanzen kann dieselbe Identifikationszeichenkette für unterschiedliche Inhalte stehen, z.B. unterschiedliche Standorte. Anmerkung 3: Da global eindeutige IDs, z.B. GLNs, auch lokal eindeutig sind, ist es zulässig (aber nicht erforderlich), in LocalAssignmentID global eindeutige IDs zu verwenden. Dabei ist zu beachten, dass Recyclingstandorte in der Message nach Möglichkeit über die in edm.gv.at zum Standort eingetragene GLN zu identifizieren sind, durch Eintrag in ReportUserMessage/MessagePart/Event/RecoverySiteID, und ListedData/Party in diesem Fall KEINEN Eintrag für den Standort enthalten darf. Begrenzungen: Die Zeichenkette besteht aus maximal 64 Zeichen; Die Zeichenkette besteht aus mindestens 1 Zeichen; Die Zeichenkette genügt der xs:ID-Syntax. Insbesondere darf sie nur aus Buchstaben, Ziffern und wenigen sonstigen Zeichen wie Underscore (#x5F) bestehen.
Name pkm:NameContent	0..1	Bezeichnung des Standorts. Anmerkung: Jeder Eintrag eines Standorts in ListedData/Site erfordert die Angabe der Standortbezeichnung. Siehe formale Prüfung R129. Begrenzungen: Die Zeichenkette besteht aus maximal 120 Zeichen; Die Zeichenkette besteht aus mindestens 1 Zeichen; Die Zeichenkette ist ein sogenanntes Token: Das 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.
AddressCountryID pkm:CountryIdentifier	0..1	Identifikation des Landes, in dem sich der Standort befindet, mittels dreistelligem numerischen ISO 3166-1 Code. Beispiel: Code 276 für Deutschland Anmerkung 1: Die Menge der unterstützten Werte ist in der EDM ↗Codeliste 3862 definiert, welche die Einträge des ISO 3166-1 Standards wiedergibt. Anmerkung 2: Es handelt sich um eine DYNAMISCHE Codelistenreferenz. Das bedeutet, dass Software, die Dateninstanzen dieses Datenformats liest und schreibt, auf Änderungen in der Codeliste vorbereitet sein muss, insbesondere auf das Hinzufügen von Einträgen, und zwar unabhängig von Änderungen des Datenformats. Die jeweils aktuelle Version der EDM ↗Codeliste 3862 kann von der Website edm.gv.at sowie über ein Codelisten-Webservice abgerufen werden. Anmerkung 3: Anstelle der bekannteren zweistelligen Buchstabencodes nutzt das Datenformat dreistellige numerische ISO 3166-1 Codes. Der Grund hierfür liegt darin, dass nur die dreistelligen Codes über längere Zeiträume, z. B. mehrere Jahre, garantiert eindeutig sind. So hat ISO beispielsweise den Buchstabencode CS sowohl der Tschechoslowakei (bis 1993) als auch Serbien und Montenegro (von 2003 bis 2006) zugewiesen. Anmerkung 4: Jeder Eintrag eines Standorts in ListedData/Site erfordert die Angabe des Landes, in dem sich der Standort befindet. Siehe formale Prüfung R129.
AddressPostalAreaID pkm:PostalAreaIdentifierContent	0..1	Postleitzahl des Standorts. Anmerkung: Jeder Eintrag eines Standorts in ListedData/Site erfordert die Angabe der Unternehmenssitz-Postleitzahl. Siehe formale Prüfung R129. Begrenzungen: Die Zeichenkette besteht aus maximal 10 Zeichen; Die Zeichenkette besteht aus mindestens 1 Zeichen; Die Zeichenkette ist ein sogenanntes Token: Das 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.
AddressCityName pkm:NameContent	0..1	Name des Orts, an dem sich der Standort befindet. Anmerkung: Jeder Eintrag eines Standorts in ListedData/Site erfordert die Angabe der Standort-Ortsbezeichnung. Siehe formale Prüfung R129. Begrenzungen: Die Zeichenkette besteht aus maximal 120 Zeichen; Die Zeichenkette besteht aus mindestens 1 Zeichen; Die Zeichenkette ist ein sogenanntes Token: Das 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.

Site wird verwendet in: ListedData

ValidationNodeIndividualData

ValidationNodeIndividualData Schema diagram

Einzelne Datensätze, die bereits vor dem Empfang einer User Message auf Empfängerseite vorhanden sind, und einen Zusammenhang mit Inhalten der empfangenen User Message aufweisen.

Beispiele:

Angaben zu Recyclingunternehmen, wie Name und Sitzadresse.

Name/Typ	min..max	Definition
PartyEDINodeActivationIndicator pkm:IndicatorContent	0..1	Ja/Nein-Angabe dazu, ob laut den Daten aus edm.gv.at der Beteiligte aus ReportUserMessage/MessageCreationPartyID (Message-Ersteller und Übermittler) den bei der Webservice-Interaktion identifizierten und authentifizierten Webservice-Client dafür aktiviert (freigeschalten) hat, in seinem Namen - also beispielsweise im Namen der zentralen Stelle - Interaktionen mit dem Webservice durchzuführen.
Registration pkm:ValidationNodeIndividualDataRegistration	0..1	Informationen zu in Zusammenhang mit der empfangenen User Message relevanten, auf Empfängerseite (edm.gv.at) vorhandenen Einträgen zu Recyclingunternehmen und Recyclingstandorten.

ValidationNodeIndividualData wird verwendet in: MessageValidationContext

ValidationNodeIndividualDataRegistration

ValidationNodeIndividualDataRegistration Schema diagram

Angaben zu registrierten Unternehmen und Standorten.

Name/Typ	min..max	Definition
Party pkm:RegisteredEconomicOperator	0..*	Auf Empfänger-Seite (edm.gv.at) vorliegende Datensätze zu Unternehmen, auf die in der empfangenen User Message Bezug genommen wird. In Zusammenhang mit dem vorliegenden Datenformat kann es sich um folgende Arten von Unternehmen handeln: Recyclingunternehmen Message-Ersteller (Zentrale Stelle) Zu befüllen auf Basis der in MessageValidationContext/ReportUserMessage/MessagePart/Event/RecoveryPartyID und MessageValidationContext/ReportUserMessage/MessageCreationPartyID enthaltenen EDM-GLNs und GLNs der öffentlichen Verwaltung.
Site pkm:RegisteredSite	0..*	Auf Empfänger-Seite (edm.gv.at) vorliegende Datensätze zu Standorten, auf die in der empfangenen User Message Bezug genommen wird. In Zusammenhang mit dem vorliegenden Datenformat kann es sich um folgende Arten von Standorten handeln: Recyclingstandort Zu befüllen auf Basis der in MessageValidationContext/ReportUserMessage/MessagePart/Event/RecoverySiteID enthaltenen EDM-Standort-GLNs.

ValidationNodeIndividualDataRegistration wird verwendet in: ValidationNodeIndividualData

ValidationNodeReferenceData

ValidationNodeReferenceData Schema diagram

Auf Empfänger-Seite (edm.gv.at) genutzte Referenzdaten.

Beispiel:

ISO 3166-1 Staatenliste

Name/Typ	min..max	Definition
CountryList pkm:CountryList	0..1	Die auf Empfänger-Seite (edm.gv.at) genutzte Instanz der Liste der dreistelligen numerischen ISO 3166-1-Ländercodes. Anmerkung 1: Die im Message-Format unterstützten Werte sind in der edm.gv.at-Codeliste 3862 definiert, welche die Einträge des ISO 3166-1 Standards wiedergibt. Die am Austausch von Messages beteiligten Akteure sollen daher die Länder-Codelisten der jeweiligen EDI-Knoten mit der edm.gv.at-↗Codeliste 3862 synchronisieren. Für diesen Abgleich stellt edm.gv.at ein Codelisten-Webservice zur Verfügung. Anmerkung 2: Software, die formale Prüfungen mittels XSL-Transformation anwendet, KANN die Effizienz der Prüfung dadurch erhöhen, dass sie das Validierungskontext-Datenelement CountryList nur mit jenen Werten befüllt, die SOWOHL in der empfangenen User Message ALS AUCH in der auf Empfänger-Seite genutzten Liste enthalten sind (Schnittmenge).
InteroperationPartyRegisterList pkm:PartyRegisterList	0..1	Liste von solchen Registern bzw. Registrierungsverfahren, aus welchen Unternehmens-IDs stammen können, die im Getränkeverpackungen Einwegpfand Webservice als "interoperabel" gelten. Anmerkung 1: Mit "als interoperabel gelten" ist gemeint, dass in der Datenübermittlung AUSSCHLIESSLICH die betreffende Unternehmens-ID verwendet werden KANN und SOLL, also OHNE z.B. Name und Adresse, wenn das betreffende Unternehmen auf Empfänger-Seite bereits bekannt bzw. eingetragen ist. Beispiel: In der Erstellung einer Datenübermittlung können und sollen Recyclingunternehmen in ReportUserMessage/MessagePart/Event/RecoveryPartyID AUSSCHLIESSLICH per Unternehmens-ID identifiziert werden, wenn diese Unternehmen in edm.gv.at bereits eingetragen sind. Die vorliegende Referenzliste definiert also u.a. die in ReportUserMessage/MessagePart/Event/RecoveryPartyID verwendbaren Arten von Unternehmens-IDs. Anmerkung 2: edm.gv.at-↗Codeliste 7836 definiert die im Getränkeverpackungen Einwegpfand Webservice als "interoperabel" geltenden Beteiligten-IDs. Anmerkung 3: Die dynamische Nutzung der ↗Codeliste 7836 in der Getränkeverpackungen Einwegpfand Webservice-Spezifikation ermöglicht es im Bedarfsfall, zusätzliche Arten von Beteiligten-IDs zu unterstützen, ohne dafür die Schnittstellenspezifikation anpassen zu müssen. Anmerkung 4: Die Verwendung einer bestimmten ID-Art, z.B. GLN.AT (GLN der öffentlichen Verwaltung) zur "interoperablen" ID-ONLY-Identifikation in einer Datenübermittlung setzt klarerweise voraus, dass die betreffende ID-Art auf Empfängerseite (edm.gv.at) zum Beteiligten mit angegeben bzw. eingetragen ist. Beispieleinträge: GLN.AT: Österreichische GLN der öffentlichen Verwaltung GLN.EDM: EDM-GLN (Elektronisches Datenmanagement - Umwelt - Global Location Number)
DescriptionPartyRegisterList pkm:PartyRegisterList	0..1	Liste von solchen Registern bzw. Registrierungsverfahren, aus welchen Unternehmens-IDs stammen können, die in solchen Fällen in der Beschreibung von Unternehmen verwendet werden, in welchen ein interoperabler Austausch von Unternehmens-IDs NICHT möglich ist. Anmerkung 1: Mit "interoperabler Austausch von Unternehmens-IDs NICHT möglich" sind Fälle gemeint, in welchen ein auf Seite des Übermittlungserstellers identifiziertes Unternehmen am auf Empfänger-Seite (edm.gv.at) NICHT eingetragen ist, und damit ein ID-ONLY-Datenaustausch NICHT möglich ist. In solchen Fällen sollen Unternehmen in der Übermittlung per Name und Adresse identifiziert werden, sowie ergänzend, wenn möglich, per Unternehmens-IDs. Siehe ReportUserMessage/ListedData/Party und ReportUserMessage/ListedData/Party/ID. Anmerkung 2: edm.gv.at-↗Codeliste 7411 definiert die im Getränkeverpackungen Einwegpfand Webservice in der Beschreibung von Unternehmen verwendbaren IDs. Anmerkung 3: Die dynamische Nutzung der ↗Codeliste 7411 in der Getränkeverpackungen Einwegpfand Webservice-Spezifikation ermöglicht es im Bedarfsfall, zusätzliche Arten von Beteiligten-IDs zu unterstützen, ohne dafür die Schnittstellenspezifikation anpassen zu müssen. Beispieleinträge: GLN.AT: Österreichische GLN der öffentlichen Verwaltung VAT.EU: Europäische MwSt-Nummer

ValidationNodeReferenceData wird verwendet in: MessageValidationContext

Datentypen

BeverageTypeIdentifier

Name/Typ	min..max	Definition
BeverageTypeIdentifier pkm:BeverageTypeIdentifierContent	1..1	Identifikation einer Getränkekategorie, in Anlehnung an § 14b Abfallwirtschaftsgesetz 2002.
@designation pkm:DesignationContent	0..1	Natürlichsprachige Bezeichnung der Getränkekategorie. Anmerkung: Das designation-Attribut dient ausschließlich dazu, IT-Personal die Handhabung von XML-Dateninstanzen zu erleichtern, z.B. während Entwicklung und Test. Die Schnittstellenbeschreibung enthält einen eigenen Abschnitt, der näher erläutert, was in Zusammenhang mit dem designation-Attribut zu beachten ist.

BeverageTypeIdentifier wird verwendet in: ReportEvent

BeverageTypeIdentifierContent

Name/Typ	min..max	Definition
BeverageTypeIdentifierContent xs:string	1..1	Identifikation einer Getränkekategorie, in Anlehnung an § 14b Abfallwirtschaftsgesetz 2002. Unterstützte Werte (siehe auch edm.gv.at ↗Codeliste 2311): 9008390132531: Bier 9008390132548: Wässer 9008390132555: Saft 9008390132562: Alkoholfreie Erfrischungsgetränke 9008390132586: Wein 9008390132593: Sekt und Spirituosen

BeverageTypeIdentifierContent wird verwendet in: BeverageTypeIdentifier

BeverageVolumeIdentifier

Name/Typ	min..max	Definition
BeverageVolumeIdentifier pkm:BeverageVolumeIdentifierContent	1..1	Identifikation einer Getränkevolumen-Kategorie.
@designation pkm:DesignationContent	0..1	Natürlichsprachige Bezeichnung der Getränkevolumen-Kategorie. Anmerkung: Das designation-Attribut dient ausschließlich dazu, IT-Personal die Handhabung von XML-Dateninstanzen zu erleichtern, z.B. während Entwicklung und Test. Die Schnittstellenbeschreibung enthält einen eigenen Abschnitt, der näher erläutert, was in Zusammenhang mit dem designation-Attribut zu beachten ist.

BeverageVolumeIdentifier wird verwendet in: ReportEvent

BeverageVolumeIdentifierContent

Name/Typ	min..max	Definition
BeverageVolumeIdentifierContent xs:string	1..1	Identifikation einer Getränkevolumen-Kategorie. Unterstützte Werte (siehe auch edm.gv.at ↗Codeliste 6598): 9008390132609: bis inkl. 0,25 l 9008390132616: über 0,25 l bis inkl. 0,33 l 9008390132623: über 0,33 l bis inkl. 0,5 l 9008390132630: über 0,5 l bis inkl. 0,75 l 9008390132647: über 0,75 l bis inkl. 1 l 9008390132654: über 1 l bis inkl. 1,5 l 9008390132661: über 1,5 l

BeverageVolumeIdentifierContent wird verwendet in: BeverageVolumeIdentifier

CountryIdentifier

Name/Typ	min..max	Definition
CountryIdentifier pkm:CountryIdentifierContent	1..1	Identifikation eines Landes (Nationalstaats) mittels dreistelligem numerischen ISO 3166-1 Code.
@designation pkm:DesignationContent	0..1	Natürlichsprachige Bezeichnung des Landes. Anmerkung: Das designation-Attribut dient ausschließlich dazu, IT-Personal die Handhabung von XML-Dateninstanzen zu erleichtern, z.B. während Entwicklung und Test. Die Schnittstellenbeschreibung enthält einen eigenen Abschnitt, der näher erläutert, was in Zusammenhang mit dem designation-Attribut zu beachten ist.

CountryIdentifier wird verwendet in: CountryListElement, Party, Site

CountryIdentifierContent

Name/Typ	min..max	Definition
CountryIdentifierContent xs:string	1..1	Identifikation eines Landes (Nationalstaats) mittels dreistelligem numerischen ISO 3166-1 Code (edm.gv.at ↗Codeliste 3862) Beispiele: 040: Österreich 056: Belgien 276: Deutschland 380: Italien 756: Schweiz Anmerkung: Dynamisch verwendete Codeliste - edm.gv.at ↗Codeliste 3862 definiert die Menge der in diesem Datenformat unterstützten Werte.

CountryIdentifierContent wird verwendet in: CountryIdentifier

CountryTwoLetterIdentifierContent

Name/Typ	min..max	Definition
CountryTwoLetterIdentifierContent xs:string	1..1	Identifikation eines Landes (Nationalstaats) per ISO 3166-1 Zwei-Buchstaben-ID ("alpha-2"). Beispiele: AT: Österreich BE: Belgien DE: Deutschland IT: Italien CH: Schweiz

CountryTwoLetterIdentifierContent wird verwendet in: CountryListElement

DateContent

Name/Typ	min..max	Definition
DateContent xs:date	1..1	Datum, d. h. Identifikation eines Tages, OHNE Angabe der Zeitzone. Begrenzungen: xs:date-Wert, der die Bestandteile Jahr, Monat und Tag enthalten muss; Für die Bestandteile Jahr, Monat und Tag gelten die durch xs:date definierten Begrenzungen. Beispielsweise muss der Monat mit zwei Dezimalziffern ausgedrückt werden, wobei 01 für Jänner steht und 12 für Dezember. Beispielwert: 2022-03-25

DateContent wird verwendet in: CountryListElement, PartyRegisterListElement, Period, ReportUserMessage

DescriptionContent

Name/Typ	min..max	Definition
DescriptionContent xs:string	1..1	Beschreibungstext. Begrenzungen: Die Zeichenkette besteht aus maximal 1000 Zeichen; Die Zeichenkette besteht aus mindestens 1 Zeichen.

DescriptionContent wird verwendet in: RegisteredEconomicOperator, RegisteredSite, SignalMessage

DesignationContent

Name/Typ	min..max	Definition
DesignationContent xs:normalizedString	1..1	Natürlichsprachige Identifikation, per Name oder Beschreibung. Begrenzungen: Die Zeichenkette besteht aus maximal 256 Zeichen; Die Zeichenkette besteht aus mindestens 1 Zeichen; Die Zeichenkette genügt der xs:normalizedString-Syntax, d.h. sie enthält weder Carriage Return (#xD), Line Feed (#xA) noch Tabulatur (#x9) Zeichen.

DesignationContent wird verwendet in: BeverageTypeIdentifier, BeverageVolumeIdentifier, CountryIdentifier, EconomicOperatorIdentifier, PackagingMaterialTypeIdentifier, RecoveryTypeIdentifier, ReportUserMessagePartTypeIdentifier, ReportUserMessageTypeIdentifier, SingleUsePlasticBottleTypeIdentifier, SiteIdentifier

DocumentScopeAssignmentIdentifier

Name/Typ	min..max	Definition
DocumentScopeAssignmentIdentifier xs:string	1..1	Zu einem in der Message aufgezählten Objekt, z.B. einem Standort, für die Bezugnahme auf dieses Objekt innerhalb der Message zugeordnete Identifikationszeichenkette. Anmerkung: Für Identifikationszeichenketten (IDs) dieses Typs kann die Eindeutigkeit nur innerhalb der einzelnen Message vorausgesetzt werden. Eine darüber hinausgehende Eindeutigkeit gibt es nicht notwendigerweise. Im Detail bedeutet das: Wenn Software eine Message ERSTELLT, muss sie IDs verwenden, die ZUMINDEST innerhalb der Message eindeutig sind. Es genügt also beispielsweise das Durchnummerieren, z.B. »P00« bis »P23«. Sofern vorhanden eignet sich aber auch die Verwendung von IDs, die über die Message hinaus eindeutig sind. Beispielsweise können für Firmen Firmenbuchnummern für die Message-interne Bezugnahme verwendet werden. Beim EINLESEN und VERARBEITEN einer Message darf jedoch ausschließlich die Eindeutigkeit der IDs innerhalb der Message vorausgesetzt werden. Eine über die Message hinausgehende Verwendbarkeit der IDs darf nicht angenommen bzw. vorausgesetzt werden. Begrenzungen: Die Zeichenkette besteht aus maximal 64 Zeichen; Die Zeichenkette besteht aus mindestens 1 Zeichen; Die Zeichenkette genügt der xs:ID-Syntax. Insbesondere darf sie nur aus Buchstaben, Ziffern und wenigen sonstigen Zeichen wie Underscore (#x5F) bestehen und muss innerhalb aller in der XML-Instanz zugewiesenen IDs eindeutig sein.

DocumentScopeAssignmentIdentifier wird verwendet in: Party, Site

DocumentScopeReferenceIdentifierContent

Name/Typ	min..max	Definition
DocumentScopeReferenceIdentifierContent xs:string	1..1	Referenzierung eines Objekts mittels eines an anderer Stelle in der Message dem Objekt zugewiesenen Identifikators. Anmerkung: Die Zeichenkette muss den xs:IDREF-Vorgaben genügen. Das bedeutet insbesondere, dass es innerhalb der XML-Instanz ein Element oder Attribut vom Typ xs:ID mit demselben Wert geben muss. Im vorliegenden Datenformat sind das genau die LocalAssignmentID-Elemente.

DocumentScopeReferenceIdentifierContent wird verwendet in: ReportEvent

EconomicOperatorIdentifier

Name/Typ	min..max	Definition
EconomicOperatorIdentifier pkm:RelaxedIdentifierContent	1..1	Identifikation eines Unternehmens, zusammen mit der Angabe der Art der ID im Attribut registerID. Beispiele für registerID-Werte, und die damit verbundenen Identifikations-Arten (edm.gv.at ↗Codeliste 7836): GLN.EDM: Identifikation per Global Location Number (GLN), die zum Unternehmen in edm.gv.at als primäre ID eingetragen ist; GLN.AT: Identifikation per "Sekundär-ID" bzw. "GLN der öffentlichen Verwaltung", die zum Unternehmen im österreichischen Unternehmensregister eingetragen ist. Anmerkung: Dynamisch verwendete Codeliste - edm.gv.at ↗Codeliste 7836 definiert die Menge der in diesem Datenformat unterstützten registerID-Werte. Begrenzungen: Die Zeichenkette besteht aus maximal 64 Zeichen; Die Zeichenkette besteht aus mindestens 1 Zeichen; Die Zeichenkette ist ein sogenanntes Token: Das 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.
@registerID pkm:EconomicOperatorRegisterIdentifierContent	1..1	ID des Registrierungsverfahrens, aus dem die Beteiligten-ID stammt (edm.gv.at Codeliste 7836). Beispiele: GLN.AT: "Sekundär-ID" bzw. "GLN der öffentlichen Verwaltung", die zum Unternehmen im österreichischen Unternehmensregister eingetragen ist; GLN.EDM: Die Global Location Number (GLN), die zum Unternehmen in edm.gv.at als primäre ID eingetragen ist. Anmerkung 1: In edm.gv.at wird nach Möglichkeit bei der Registrierung eine bereits zum Unternehmen vorhandene "GLN der öffentlichen Verwaltung" als Primär-ID verwendet. In einem solchen Fall stimmt die GLN.EDM mit der GLN.AT überein. Anmerkung 2: Um eine "GLN der öffentlichen Verwaltung" in einer Datenübermittlung an das EDM (mit edm.gv.at als Empfänger-EDI-Knoten) verwenden zu können, muss die "GLN der öffentlichen Verwaltung" zum Unternehmen in edm.gv.at eingetragen sein. Anmerkung 3: Dynamisch verwendete Codeliste - edm.gv.at ↗Codeliste 7836 definiert die Menge der in diesem Datenformat an dieser Stelle unterstützten registerID-Werte.
@designation pkm:DesignationContent	0..1	Natürlichsprachige Bezeichnung des Beteiligten, z.B. Firmenbezeichnung. Anmerkung: Das designation-Attribut dient ausschließlich dazu, IT-Personal die Handhabung von XML-Dateninstanzen zu erleichtern, z.B. während Entwicklung und Test. Die Schnittstellenbeschreibung enthält einen eigenen Abschnitt, der näher erläutert, was in Zusammenhang mit dem designation-Attribut zu beachten ist.

EconomicOperatorIdentifier wird verwendet in: Party, ReportEvent, ReportUserMessage

EconomicOperatorRegisterIdentifierContent

Name/Typ	min..max	Definition
EconomicOperatorRegisterIdentifierContent xs:token	1..1	ID des Registrierungsverfahrens, aus dem die Unternehmens-ID stammt (edm.gv.at Codeliste 7836). Beispiele: GLN.EDM: Die Global Location Number (GLN), die zum Unternehmen in edm.gv.at als primäre ID eingetragen ist; GLN.AT: "Sekundär-ID" bzw. "GLN der öffentlichen Verwaltung", die zum Unternehmen im österreichischen Unternehmensregister eingetragen ist. Anmerkung 1: In edm.gv.at wird nach Möglichkeit bei der Registrierung eine bereits zum Unternehmen vorhandene "GLN der öffentlichen Verwaltung" als Primär-ID verwendet. In einem solchen Fall stimmt die GLN.EDM mit der GLN.AT überein. Anmerkung 2: Um eine "GLN der öffentlichen Verwaltung" in einer Datenübermittlung an das EDM (mit edm.gv.at als Empfänger-EDI-Knoten) zu verwenden, muss die "GLN der öffentlichen Verwaltung" zum Unternehmen in edm.gv.at eingetragen sein. Begrenzungen: Die Zeichenkette besteht aus maximal 16 Zeichen; Die Zeichenkette besteht aus mindestens 1 Zeichen; Die Zeichenkette ist ein sogenanntes Token: Das 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.

EconomicOperatorRegisterIdentifierContent wird verwendet in: EconomicOperatorIdentifier, PartyRegisterListElement

GLNIdentifierContent

Name/Typ	min..max	Definition
GLNIdentifierContent xs:token	1..1	Identifikation per GLN (Global Location Number). Anmerkung: GLNs (Global Location Numbers) müssen die folgenden Bedingungen einhalten: Genau 13 Zeichen, d.h. auch Leerstring unzulässig; Ausschließlich aus Ziffern (0-9) bestehend.

GLNIdentifierContent wird verwendet in: RegisteredEconomicOperator, RegisteredSite

IndicatorContent

Name/Typ	min..max	Definition
IndicatorContent xs:boolean	1..1	Ja/Nein-Wert. Anmerkung: “Ja”, ausgedrückt durch den Wert »true« oder »1«, steht für das Zutreffen einer Eigenschaft. “Nein”, ausgedrückt durch den Wert »false« oder »0«, steht dafür, dass eine Eigenschaft NICHT zutrifft.

IndicatorContent wird verwendet in: RegisteredEconomicOperator, RegisteredSite, ReportUserMessagePart, SignalMessage, ValidationNodeIndividualData

MassUnitIdentifierContent

Name/Typ	min..max	Definition
MassUnitIdentifierContent xs:string	1..1	Identifikation einer Größeneinheit für Massen-Angaben per “Unified Code for Units of Measures” (UCUM) Code mit Unterscheidung von Groß- und Kleinschreibung. Anmerkung: Das vorliegende Datenformat unterstützt für Massen-Angaben ausschließlich die Größeneinheit Kilogramm, für welche der UCUM-Code »kg« zu verwenden ist. Unterstützte Werte (siehe auch edm.gv.at ↗Codeliste 5359): kg: Kilogramm

MassUnitIdentifierContent wird verwendet in: MassValue

MassValue

Name/Typ	min..max	Definition
MassValue pkm:ValueContent	1..1	Masse in Kilogramm. Anmerkung 1: In Ergänzung zum Zahlenwert enthält das Attribut unitID die Identifikation einer Größeneinheit per “Unified Code for Units of Measures” (UCUM) mit Unterscheidung von Groß- und Kleinschreibung. Anmerkung 2: Das vorliegende Datenformat unterstützt für Massen-Angaben ausschließlich die Größeneinheit Kilogramm, für welche der UCUM-Code »kg« zu verwenden ist. Begrenzungen: Die Zeichenkette genügt der xs:decimal-Syntax; Insbesondere enthält die Zeichenkette gemäß xs:decimal-Syntax OPTIONAL ein Dezimaltrennzeichen; Insbesondere handelt es sich gemäß xs:decimal-Syntax beim Dezimaltrennzeichen um den Punkt (#x2E), und NICHT um das im deutschsprachigen Raum übliche Komma (#x2C); Insbesondere enthält die Zeichenkette gemäß xs:decimal-Syntax KEINE Tausendertrennzeichen oder sonstigen Zifferngruppierungszeichen; Insbesondere enthält die Zeichenkette gemäß xs:decimal-Syntax OPTIONAL ein »+«/»-« Vorzeichen, wobei Zeichenketten ohne Vorzeichen gleichbedeutend mit Zeichenketten mit »+«-Vorzeichen sind; Die Zeichenkette enthält mindestens 1 Dezimalstelle (Ziffer 0-9); Die Zeichenkette enthält maximal 25 Dezimalstellen (Ziffern 0-9); Die Zeichenkette enthält maximal 5 Nachkommastellen, d.h. von den maximal 25 Ziffern-Zeichen befinden sich maximal 5 HINTER einem Dezimaltrennzeichen; Der Wert ist größer oder gleich 0 (formale Prüfung R408). Beispielwert: 4835.7
@unitID pkm:MassUnitIdentifierContent	1..1	Identifikation einer Größeneinheit per “Unified Code for Units of Measures” (UCUM) mit Unterscheidung von Groß- und Kleinschreibung. Anmerkung: Das vorliegende Datenformat unterstützt für Massen-Angaben ausschließlich die Größeneinheit Kilogramm, für welche der UCUM-Code »kg« zu verwenden ist. Unterstützte Werte (siehe auch edm.gv.at ↗Codeliste 5359): kg: Kilogramm

MassValue wird verwendet in: ReportEvent

NameContent

Name/Typ	min..max	Definition
NameContent xs:token	1..1	Name. Begrenzungen: Die Zeichenkette besteht aus maximal 120 Zeichen; Die Zeichenkette besteht aus mindestens 1 Zeichen; Die Zeichenkette ist ein sogenanntes Token: Das 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.

NameContent wird verwendet in: Party, PartyRegisterListElement, RegisteredEconomicOperator, RegisteredSite, Site

PackagingMaterialTypeIdentifier

Name/Typ	min..max	Definition
PackagingMaterialTypeIdentifier pkm:PackagingMaterialTypeIdentifierContent	1..1	Identifikation eines Packstoffs.
@designation pkm:DesignationContent	0..1	Natürlichsprachige Bezeichnung des Packstoffs. Anmerkung: Das designation-Attribut dient ausschließlich dazu, IT-Personal die Handhabung von XML-Dateninstanzen zu erleichtern, z.B. während Entwicklung und Test. Die Schnittstellenbeschreibung enthält einen eigenen Abschnitt, der näher erläutert, was in Zusammenhang mit dem designation-Attribut zu beachten ist.

PackagingMaterialTypeIdentifier wird verwendet in: ReportEvent

PackagingMaterialTypeIdentifierContent

Name/Typ	min..max	Definition
PackagingMaterialTypeIdentifierContent xs:string	1..1	Identifikation eines Packstoffs. Unterstützte Werte (siehe auch edm.gv.at ↗Codeliste 4824): 9008390106846: Eisenmetalle 9008390106853: Aluminium 9008390101476: Kunststoffe gemäß § 2 Abs. 10 Z 2 AWG 2002

PackagingMaterialTypeIdentifierContent wird verwendet in: PackagingMaterialTypeIdentifier

PostalAreaIdentifierContent

Name/Typ	min..max	Definition
PostalAreaIdentifierContent xs:token	1..1	Postleitzahl. Begrenzungen: Die Zeichenkette besteht aus maximal 10 Zeichen; Die Zeichenkette besteht aus mindestens 1 Zeichen; Die Zeichenkette ist ein sogenanntes Token: Das 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.

PostalAreaIdentifierContent wird verwendet in: Party, Site

RecoveryTypeIdentifier

Name/Typ	min..max	Definition
RecoveryTypeIdentifier pkm:RecoveryTypeIdentifierContent	1..1	Identifikation einer Art der Verwertung.
@designation pkm:DesignationContent	0..1	Natürlichsprachige Bezeichnung der Verwertungsart. Anmerkung: Das designation-Attribut dient ausschließlich dazu, IT-Personal die Handhabung von XML-Dateninstanzen zu erleichtern, z.B. während Entwicklung und Test. Die Schnittstellenbeschreibung enthält einen eigenen Abschnitt, der näher erläutert, was in Zusammenhang mit dem designation-Attribut zu beachten ist.

RecoveryTypeIdentifier wird verwendet in: ReportEvent

RecoveryTypeIdentifierContent

Name/Typ	min..max	Definition
RecoveryTypeIdentifierContent xs:string	1..1	Identifikation einer Art der Verwertung. Unterstützte Werte (siehe auch edm.gv.at ↗Codeliste 4399): 9008390125045: Recycling

RecoveryTypeIdentifierContent wird verwendet in: RecoveryTypeIdentifier

RelaxedIdentifierContent

Name/Typ	min..max	Definition
RelaxedIdentifierContent xs:token	1..1	Identifikationszeichenkette ohne besondere Wertebereich-Beschränkungen. Begrenzungen: Die Zeichenkette besteht aus maximal 64 Zeichen; Die Zeichenkette besteht aus mindestens 1 Zeichen; Die Zeichenkette ist ein sogenanntes Token: Das 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.

RelaxedIdentifierContent wird verwendet in: EconomicOperatorIdentifier, MessageValidationContext

ReportUserMessagePartTypeIdentifier

Name/Typ	min..max	Definition
ReportUserMessagePartTypeIdentifier pkm:ReportUserMessagePartTypeIdentifierContent	1..1	Identifikation des Inhaltstyps eines Message-Teils.
@designation pkm:DesignationContent	0..1	Natürlichsprachige Bezeichnung bzw. Beschreibung des Inhaltstyps. Anmerkung: Das designation-Attribut dient ausschließlich dazu, IT-Personal die Handhabung von XML-Dateninstanzen zu erleichtern, z.B. während Entwicklung und Test. Die Schnittstellenbeschreibung enthält einen eigenen Abschnitt, der näher erläutert, was in Zusammenhang mit dem designation-Attribut zu beachten ist.

ReportUserMessagePartTypeIdentifier wird verwendet in: ReportUserMessagePart

ReportUserMessagePartTypeIdentifierContent

Name/Typ	min..max	Definition
ReportUserMessagePartTypeIdentifierContent xs:string	1..1	Identifikation des Inhaltstyps eines Message-Teils (siehe auch edm.gv.at Codeliste 3974).

ReportUserMessagePartTypeIdentifierContent wird verwendet in: ReportUserMessagePartTypeIdentifier

ReportUserMessageTypeIdentifier

Name/Typ	min..max	Definition
ReportUserMessageTypeIdentifier pkm:ReportUserMessageTypeIdentifierContent	1..1	Identifikation einer Message-Art.
@designation pkm:DesignationContent	0..1	Natürlichsprachige Bezeichnung der Message-Art. Anmerkung: Das designation-Attribut dient ausschließlich dazu, IT-Personal die Handhabung von XML-Dateninstanzen zu erleichtern, z.B. während Entwicklung und Test. Die Schnittstellenbeschreibung enthält einen eigenen Abschnitt, der näher erläutert, was in Zusammenhang mit dem designation-Attribut zu beachten ist.

ReportUserMessageTypeIdentifier wird verwendet in: ReportUserMessage

ReportUserMessageTypeIdentifierContent

Name/Typ	min..max	Definition
ReportUserMessageTypeIdentifierContent xs:string	1..1	Identifikation einer Message-Art. Unterstützte Werte (siehe auch edm.gv.at ↗Codeliste 8686): RPT_BVG.YEAR: Einweggetränkeverpackungen Jahresbericht der zentralen Stelle gemäß §24 Abs. 1 PfandVO

ReportUserMessageTypeIdentifierContent wird verwendet in: ReportUserMessageTypeIdentifier, SignalMessage

ShortNameContent

Name/Typ	min..max	Definition
ShortNameContent xs:token	1..1	Kurzname. Kurznamen müssen die folgenden Bedingungen einhalten: Die Zeichenkette besteht aus maximal 50 Zeichen; Die Zeichenkette besteht aus mindestens 1 Zeichen; Die Zeichenkette ist ein sogenanntes Token: Das 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.

ShortNameContent wird verwendet in: MessageValidationContext, SignalMessage

SignalIdentifierContent

Name/Typ	min..max	Definition
SignalIdentifierContent xs:string	1..1	Als Antwort auf den Empfang einer User Message automatisiert generiertes und gesendetes Signal. Unterstützte Werte: ACCEPTED: Die Software konnte die empfangene User Message verarbeiten. Der Message-Empfang ist für Benutzer auf Empfangsseite ersichtlich, und die Inhalte der empfangenen Message sind für Benutzer auf Empfangsseite zugänglich (ggf. in Abhängigkeit von Rollen und Rechten); REJECTED: Der Software konnte die empfangene User Message NICHT verarbeiten. Auf der Empfangsseite ist für Benutzer im Allgemeinen weder der Übermittlungsversuch ersichtlich, noch sind für die Benutzer die Inhalte der User Message zugänglich.

SignalIdentifierContent wird verwendet in: SignalMessage

SingleUsePlasticBottleTypeIdentifier

Name/Typ	min..max	Definition
SingleUsePlasticBottleTypeIdentifier pkm:SingleUsePlasticBottleTypeIdentifierContent	1..1	Identifikation einer Art von Einwegkunststoff-Getränkeflaschen.
@designation pkm:DesignationContent	0..1	Natürlichsprachige Bezeichnung der Getränkeflaschen-Art. Anmerkung: Das designation-Attribut dient ausschließlich dazu, IT-Personal die Handhabung von XML-Dateninstanzen zu erleichtern, z.B. während Entwicklung und Test. Die Schnittstellenbeschreibung enthält einen eigenen Abschnitt, der näher erläutert, was in Zusammenhang mit dem designation-Attribut zu beachten ist.

SingleUsePlasticBottleTypeIdentifier wird verwendet in: ReportEvent

SingleUsePlasticBottleTypeIdentifierContent

Name/Typ	min..max	Definition
SingleUsePlasticBottleTypeIdentifierContent xs:string	1..1	Identifikation einer Art von Einwegkunststoff-Getränkeflaschen. Unterstützte Werte (siehe auch edm.gv.at ↗Codeliste 9536): 9008390124970: Getränkebehälter - PET-Getränkeflaschen 9008390124987: Getränkebehälter - sonstige Kunststoff-Getränkeflaschen

SingleUsePlasticBottleTypeIdentifierContent wird verwendet in: SingleUsePlasticBottleTypeIdentifier

SiteIdentifier

Name/Typ	min..max	Definition
SiteIdentifier pkm:SiteIdentifierContent	1..1	Identifikation eines Standorts per bei Registrierung in edm.gv.at zugewiesener edm.gv.at-Standort-GLN (Global Location Number).
@registerID pkm:SiteRegisterIdentifierContent	1..1	ID des Registrierungsverfahrens, aus dem die Standort-ID stammt (edm.gv.at Codeliste 7836). Unterstützte Werte: GLN.EDM: Global Location Number (GLN), die zum Standort in edm.gv.at als primäre ID eingetragen ist.
@designation pkm:DesignationContent	0..1	Natürlichsprachige Bezeichnung bzw. Beschreibung des Standorts. Anmerkung: Das designation-Attribut dient ausschließlich dazu, IT-Personal die Handhabung von XML-Dateninstanzen zu erleichtern, z.B. während Entwicklung und Test. Die Schnittstellenbeschreibung enthält einen eigenen Abschnitt, der näher erläutert, was in Zusammenhang mit dem designation-Attribut zu beachten ist.

SiteIdentifier wird verwendet in: ReportEvent

SiteIdentifierContent

Name/Typ	min..max	Definition
SiteIdentifierContent xs:token	1..1	Identifikation einer Betriebsstätte per bei Registrierung in edm.gv.at zugewiesener edm.gv.at-Standort-GLN (Global Location Number). Begrenzungen: GENAU 13 Zeichen, d.h. auch Leerstring unzulässig; Ausschließlich aus Ziffern (0-9) bestehend.

SiteIdentifierContent wird verwendet in: SiteIdentifier

SiteRegisterIdentifierContent

Name/Typ	min..max	Definition
SiteRegisterIdentifierContent xs:token	1..1	ID des Registrierungsverfahrens, aus dem die Standort-ID stammt. Unterstützte Werte (siehe auch edm.gv.at ↗Codeliste 7836): GLN.EDM: Die Global Location Number (GLN), die zum Standort in edm.gv.at als primäre ID eingetragen ist.

SiteRegisterIdentifierContent wird verwendet in: SiteIdentifier

TimestampContentType

Name/Typ	min..max	Definition
TimestampContentType xs:dateTime	1..1	Zeitstempel (Datum und Uhrzeit) mit Angabe der Zeitzone für UTC. Anmerkung: Diese Information wird automatisch von Software generiert. Benutzer dürfen diese Informationen nicht bearbeiten können. Begrenzungen: xs:dateTime-Wert, der die Bestandteile Jahr, Monat, Tag, Stunde, Minute, Sekunde, Sekundenbruchteil und Zeitzone enthalten muss; Für die Bestandteile Jahr, Monat, Tag, Stunde, Minute und Sekunde gelten die durch xs:dateTime definierten Begrenzungen. Beispielsweise muss der Monat mit zwei Dezimalziffern ausgedrückt werden, wobei 01 für Jänner steht und 12 für Dezember; Für Sekundenbruchteile ist eine Genauigkeit von exakt 6 Dezimalziffern vorgegeben. Auch allfällige nachstehende Nullen müssen mit angegeben sein; Als Zeitzone ist ausschließlich UTC zulässig. Beispielwert: 2022-03-25T11:01:35.524380Z

TimestampContentType wird verwendet in: MessageValidationContext, ReportUserMessage, SignalMessage

TrillionCountContent

Name/Typ	min..max	Definition
TrillionCountContent xs:integer	1..1	Anzahl (Dezimalzahl). Begrenzungen: Die Zeichenkette genügt der xs:integer-Syntax; Insbesondere enthält die Zeichenkette gemäß xs:integer-Syntax KEIN Dezimaltrennzeichen; Insbesondere enthält die Zeichenkette gemäß xs:integer-Syntax KEINE Tausendertrennzeichen oder sonstigen Zifferngruppierungszeichen; Insbesondere kann die Zeichenkette gemäß xs:integer-Syntax OPTIONAL ein »+«/»-« Vorzeichen enthalten, wobei Zeichenketten ohne Vorzeichen gleichbedeutend mit Zeichenketten mit »+«-Vorzeichen sind; Die Zeichenkette enthält maximal 14 Dezimalstellen (Ziffern 0-9); Die Zeichenkette enthält mindestens 1 Dezimalstelle; Der Wert ist nicht negativ (formale Prüfung R958). Beispielwert: 17 Anmerkung: Die Begrenzung auf maximal 14 Dezimalstellen bedeutet, dass der höchste abbildbare Wert 100 Billionen (10^14) minus 1 ist, d.h. 99.999.999.999.999.

TrillionCountContent wird verwendet in: ReportEvent

UUIDIdentifierContent

Name/Typ	min..max	Definition
UUIDIdentifierContent xs:string	1..1	Ein Universally Unique Identifier (UUID) in kanonischer Darstellung.

UUIDIdentifierContent wird verwendet in: ReportUserMessage, SignalMessage

ValidationResultIdentifierContent

Name/Typ	min..max	Definition
ValidationResultIdentifierContent xs:string	1..1	Ergebnis der formalen Prüfung einer empfangenen User Message. Unterstützte Werte (siehe auch edm.gv.at ↗Codeliste 6099): OK: Die formale Prüfung hat KEINE Datenkonstellationen erkannt, die auf unvollständige oder fehlerhafte Daten hinweisen würden, oder auf nicht den Vorgaben entsprechende beschriebene Tätigkeiten oder Objekte. D.h. die formale Prüfung ergab keine Hinweise auf Aspekte, die von Benutzern überprüft werden sollten; INFO: Die formale Prüfung hat Datenkonstellationen erkannt, die darauf hinweisen, dass (a) Daten unvollständig oder fehlerhaft, z.B. inkonsistent, sind, und/oder (b) beschriebene Tätigkeiten oder Objekte nicht den Vorgaben entsprechen, z.B. rechtlichen Bestimmungen oder behördlichen Auflagen, oder (c) beschriebene Tätigkeiten oder Objekte Eigenschaften aufweisen, die in der Praxis selten auftreten; WARNING: Die formale Prüfung hat Datenkonstellationen erkannt, die darauf hinweisen, dass (a) Daten unvollständig oder fehlerhaft, z.B. inkonsistent, sind, und/oder (b) beschriebene Tätigkeiten oder Objekte nicht den Vorgaben entsprechen, z.B. rechtlichen Bestimmungen oder behördlichen Auflagen; ERROR: Die formale Prüfung hat Datenkonstellationen erkannt, die darauf hinweisen, dass (a) Daten unvollständig oder fehlerhaft, z.B. inkonsistent, sind, und/oder (b) beschriebene Tätigkeiten oder Objekte nicht den Vorgaben entsprechen, z.B. rechtlichen Bestimmungen oder behördlichen Auflagen.

ValidationResultIdentifierContent wird verwendet in: SignalMessage

ValueContent

Name/Typ	min..max	Definition
ValueContent xs:decimal	1..1	Dezimalzahl, z. B. gemessener, berechneter oder definierter Wert. Begrenzungen: Die Zeichenkette genügt der xs:decimal-Syntax; Insbesondere enthält die Zeichenkette gemäß xs:decimal-Syntax OPTIONAL ein Dezimaltrennzeichen; Insbesondere handelt es sich gemäß xs:decimal-Syntax beim Dezimaltrennzeichen um den Punkt (#x2E), und NICHT um das im deutschsprachigen Raum übliche Komma (#x2C); Insbesondere enthält die Zeichenkette gemäß xs:decimal-Syntax KEINE Tausendertrennzeichen oder sonstigen Zifferngruppierungszeichen; Insbesondere enthält die Zeichenkette gemäß xs:decimal-Syntax OPTIONAL ein »+«/»-« Vorzeichen, wobei Zeichenketten ohne Vorzeichen gleichbedeutend mit Zeichenketten mit »+«-Vorzeichen sind; Die Zeichenkette enthält mindestens 1 Dezimalstelle (Ziffer 0-9); Die Zeichenkette enthält maximal 25 Dezimalstellen (Ziffern 0-9); Die Zeichenkette enthält maximal 5 Nachkommastellen, d.h. von den maximal 25 Ziffern-Zeichen befinden sich maximal 5 HINTER einem Dezimaltrennzeichen. Beispielwert: 4835.7

ValueContent wird verwendet in: MassValue

VersionIdentifier

Name/Typ	min..max	Definition
VersionIdentifier xs:token	1..1	Versionsinformation. Begrenzungen: Die Zeichenkette besteht aus maximal 8 Zeichen; Die Zeichenkette setzt sich aus den folgenden Teilen zusammen: "Major Version", gefolgt von einem Punkt (#x2E), gefolgt von der "Minor Version"; Sowohl "Major Version" als auch "Minor Version" bestehen ausschließlich aus Ziffern; Die "Minor Version" besteht aus GENAU 2 Ziffern; Die "Major Version" besteht aus MINDESTENS 1 Ziffer. Beispielwert: 1.01

VersionIdentifier wird verwendet in: ReportUserMessage, SignalMessage

Formale Prüfungen

Einleitung

Zweck der Prüfprotokolle ist in erster Linie, Benutzer auf Auffälligkeiten und mögliche Unstimmigkeiten aufmerksam zu machen, und so zum Hinterfragen, Überprüfen und ggf. Korrigieren und Ergänzen von Daten anzuregen. Die Prüfprotokolltexte sind deshalb so formuliert, dass sie im Allgemeinen ohne Zuhilfenahme von technischem Support und ohne Kenntnis der Schnittstellenspezifikation (z.B. XML-Format) interpretierbar und nachvollziehbar sind. Damit für die zentrale Stelle tätige Nutzer die in Prüfprotokollen enthaltenen Informationen tatsächlich für das Hinterfragen und ggf. Korrigieren und Ergänzen von Daten nutzen können, ist es wichtig, IT-Anbindungen an das Getränkeverpackungen Einwegpfand Webservice so zu gestalten, dass Benutzer Zugriff auf die Inhalte der vom Webservice gelieferten Prüfprotokolle erhalten, z.B. über eine Darstellung des Prüfprotokolls in einer Benutzeroberfläche auf Seiten der zentralen Stelle.

Zusätzlich können die Prüfprotokolle auch während Entwicklung und Test helfen, mögliche Fehler oder Unvollständigkeiten der IT-Anbindung an das Getränkeverpackungen Einwegpfand Webservice zu identifizieren und auszubessern.

Außerdem besteht die Möglichkeit, die von der zentralen Stelle genutzte Software so auszugestalten, dass die Einhaltung von (ausgewählten) in den Schematron-Prüfungen abgebildeten Kriterien innerhalb dieser Software sichergestellt bzw. unterstützt wird. Das gibt Benutzern, die für die zentrale Stelle tätig sind, die Gelegenheit, bestimmte Auffälligkeiten und Fehler bereits frühzeitig zu erkennen bzw. zu vermeiden, und nicht erst im Zuge von Übermittlungsversuchen an die Behörde. Ein solches frühzeitiges Erkennen bzw. Vermeiden kann zu effizienteren Abfläufen beitragen.

Der [Schematron]-Quelltext der Prüfungen ist im Spezifikationspaket enthalten. Damit kann IT-Personal exakt nachvollziehen, welche Prüfungen das Webservice auf Übermittlungen an das BMK anwendet, sowie ggf. Verbesserungsbedarf identifizieren.

Die vom Getränkeverpackungen Einwegpfand Webservice statisch verwendete ↗Codeliste 6099 beschreibt die möglichen Gesamtergebnisse formaler Prüfungen – OK, INFO, WARNING und ERROR – sowie die Zusammenhänge mit den Ergebnissen einzelner Prüfungen. Tritt beispielsweise mindestens ein ERROR-Eintrag im Prüfprotokoll auf, dann ist das Gesamtergebnis ERROR. Bei einem ERROR-Gesamtergebnis war die Übermittlung an das BMK technisch nicht erfolgreich. Weder hat die Behörde in diesem Fall Zugriff auf die Daten aus dem Übermittlungsversuch, noch erfährt die Behörde vom Übermittlungsversuch. Zu beachten ist, dass es für ein technisches Fehlschlagen der Übermittlung - angezeigt durch das Signal REJECTED in der Signal Message, mit der das Webservice antwortet - auch andere Gründe geben kann, als die formalen Prüfungen, beispielsweise das Fehlschlagen der Authentifizierung.

Die nachfolgende Liste enthält für jede der definierten formalen Prüfungen einen oder mehrere beispielhafte Prüfprotokolleinträge. Die Umweltbundesamt GmbH hat diese Beispiel-Prüfprotokolleinträge aus den im Spezifikationspaket enthaltenen XML-Beispieldateien und der per Schematron-Datei pack_deposit_refund_formalvalidationrules.sch definierten formalen Prüfungen automatisiert erstellt. Konkret ergibt sich das jeweilige Prüfergebnis durch Anwenden der Transformation pack_deposit_refund_formalvalidationrules.xsl auf die XML-Beispieldateninstanz. Die Umweltbundesamt GmbH hat hierfür den XSLT-Prozessor Saxon in der Version 12.1 von https://www.saxonica.com verwendet. Die zur besseren Lesbarkeit jeweils mit angeführte HTML-Darstellung des Prüfergebnisses ergibt sich durch Anwenden einer weiteren XSL-Transformation.

Das Getränkeverpackungen Einwegpfand Webservice liefert die Ergebnisse formaler Prüfungen übermittelter Daten im SVRL-Format (Schematron Validation Report Language), und zwar als Teil einer Signal Message, konkret im MessageFormalValidationReport-Element.

Liste der Prüfungen

Geprüfte XML Datei	IDs verletzter Prüfregeln	Ergebnisart	Haupt-Prüfprotokoll-Eintragstext	Prüfergebnis im HTML und SVRL Format
example_A_RPT_BVG.YEAR.xml		OK		.html / .xml
violate_R123a_A_RPT_BVG.YEAR.xml	R123	INFO	Die Übermittlung enthält Name und Adresse des Verwertungsstandorts »Nehlsen Cohrs GmbH Standort Schneverdingen«. Die Standortadresse liegt in Österreich. In Österreich gelegene Verwertungsstandorte sollen nach Möglichkeit in Übermittlungen nicht per Name und Adresse benannt werden, sondern mittels der in edm.gv.at zum Standort eingetragenen GLN.	.html / .xml
violate_R129a_A_RPT_BVG.YEAR.xml	R129	ERROR	Die Übermittlung enthält in der Auflistung von Verwertungsstandorten mit Name und Adresse den Standort mit den folgenden Angaben: Land: DE (ID »276«); Postleitzahl: »29640«; Ort: »Schneverdingen«; ID zur Referenzierung innerhalb der Übermittlung: »DE811310738_A«. Dabei fehlt die Bezeichnung des Standorts (Datenelement »Name«).	.html / .xml
violate_R129b_A_RPT_BVG.YEAR.xml	R129	ERROR	Die Übermittlung enthält in der Auflistung von Verwertungsstandorten mit Name und Adresse den Standort mit den folgenden Angaben: Bezeichnung: »Nehlsen Cohrs GmbH Standort Schneverdingen«; Postleitzahl: »29640«; Ort: »Schneverdingen«; ID zur Referenzierung innerhalb der Übermittlung: »DE811310738_A«. Dabei fehlt die Identifikation des Landes, in welchem sich der Standort befindet (Datenelement »AddressCountryID«).	.html / .xml
violate_R129c_A_RPT_BVG.YEAR.xml	R129	ERROR	Die Übermittlung enthält in der Auflistung von Verwertungsstandorten mit Name und Adresse den Standort mit den folgenden Angaben: Bezeichnung: »Nehlsen Cohrs GmbH Standort Schneverdingen«; Land: DE (ID »276«); Ort: »Schneverdingen«; ID zur Referenzierung innerhalb der Übermittlung: »DE811310738_A«. Dabei fehlt die Postleitzahl des Standorts (Datenelement »AddressPostalAreaID«).	.html / .xml
violate_R129d_A_RPT_BVG.YEAR.xml	R129	ERROR	Die Übermittlung enthält in der Auflistung von Verwertungsstandorten mit Name und Adresse den Standort mit den folgenden Angaben: Bezeichnung: »Nehlsen Cohrs GmbH Standort Schneverdingen«; Land: DE (ID »276«); Postleitzahl: »29640«; ID zur Referenzierung innerhalb der Übermittlung: »DE811310738_A«. Dabei fehlt die Bezeichnung des Orts, z.B. Stadt, an dem sich der Standort befindet (Datenelement »AddressCityName«).	.html / .xml
violate_R162a_A_RPT_BVG.YEAR.xml	R162	ERROR	Die Übermittlung enthält in jenem Message-Teil, der sich auf Inhalte der Art »Masse des eingesetzten Recyclats bezogen auf die in Verkehr gesetzten Einweggetränkeverpackungen gemäß § 24 Abs. 1 Pfandverordnung für Einweggetränkeverpackungen« (Code »RPT_BVG.YEAR.dPG.aRECOVER.tHH.cSTRCT07«) bezieht, die Kennzeichung, dass in Bezug auf die Inhaltsart im Berichtszeitraum keine zu berichtenden Tätigkeiten ausgeübt wurden (»ReportingObligationActivityIndicator« auf Wert »false«), der Message-Teil enthält jedoch dennoch Angaben zu Tätigkeiten, z.B. Massen je Untergliederung. Es muss eine Übereinstimmung zwischen (a) der Information, ob zu berichtende Tätigkeiten ausgeübt wurden, und (b) dem Vorhandensein btw. Nicht-Vorhandensein von Masse-/Anzahl-Angaben bestehen.	.html / .xml
violate_R188a_A_RPT_BVG.YEAR.xml	R188	ERROR	In der Übermittlung fehlen Inhalte der Art »Recyclierte Verpackungsmaterialien aus von der zentralen Stelle zum Recycling übergebenen Einweggetränkeverpackungen gemäß § 24 Abs. 1 Pfandverordnung für Einweggetränkeverpackungen« (Code »RPT_BVG.YEAR.dPG.aRECOVER.tHH.bC.cSTRCT14«). Das Datenformat erfordert solche Inhalte. Wenn im Berichtszeitraum keine der Inhaltsart entsprechenden Tätigkeiten ausgeübt wurden, dann muss die Message dennoch einen Message-Teil der betreffenden Inhaltsart enthalten, in diesem Fall mit Leermeldungsdeklaration im Datenelement »ReportingObligationActivityIndicator«.	.html / .xml
violate_R202a_A_RPT_BVG.YEAR.xml	R202	INFO	Die Übermittlung enthält Name und Adresse des Verwertungsunternehmens »Nehlsen Cohrs GmbH«. Die Sitzadresse liegt in Österreich. Verwertungsunternehmen mit Sitz in Österreich sollen nach Möglichkeit in Übermittlungen nicht per Name und Adresse benannt werden, sondern mittels der in edm.gv.at zum Unternehmen eingetragenen GLN.	.html / .xml
violate_R248a_A_RPT_BVG.YEAR.xml	R248	ERROR	Die Übermittlung enthält das Berichtszeitraum-Beginndatum »2025-01-01« und das Berichtszeitraum-Enddatum »2026-12-31«. Das Datenformat unterstützt nur solche Berichtszeiträume, bei welchen Beginndatum und Enddatum innerhalb desselben Kalenderjahres liegen.	.html / .xml
violate_R272a_A_RPT_BVG.YEAR.xml	R272	INFO	Die Übermittlung erfolgt am 11.04.2026. Für das Berichtsjahr 2025 hätte die Übermittlung jedoch bis spätestens zum 10. April 2026 erfolgen sollen.	.html / .xml
violate_R273a_A_RPT_BVG.YEAR.xml	R273	ERROR	Die Übermittlung enthält zwei oder mehr Angaben zu den Inhalten der Art »Recyclierte Verpackungsmaterialien aus von der zentralen Stelle zum Recycling übergebenen Einweggetränkeverpackungen gemäß § 24 Abs. 1 Pfandverordnung für Einweggetränkeverpackungen« (Code »RPT_BVG.YEAR.dPG.aRECOVER.tHH.bC.cSTRCT14«) und den folgenden Gruppierungskriterien: Packstoff »Aluminium« (GTIN 9008390106853); Verwertungsart »Recycling« (GTIN 9008390125045); Verwertungsunternehmen »Saubermacher Dienstleistungs-AG« (GLN.AT 9110015294644); Verwertungsstandort »Saubermacher AG; STO Puchstraße« (GLN.EDM 9008390026076). Das erste Auftreten enthält die folgenden Angaben: Masse 18.349 kg. Das zweite Auftreten enthält die folgenden Angaben: Masse 18.351 kg. Das Datenformat unterstützt je Message-Teil höchstens eine Massen- bzw. Anzahl-Angabe je Gruppierung.	.html / .xml
violate_R298a_A_RPT_BVG.YEAR.xml	R298	ERROR	Die Übermittlung enthält das Berichtszeitraum-Beginndatum »2025-02-15«. Das Datenformat unterstützt nur den 1. Jänner eines Jahres, z.B. »2025-01-01«, als Berichtszeitraum-Beginndatum.	.html / .xml
violate_R334a_A_RPT_BVG.YEAR.xml	R334	ERROR	Die Übermittlung enthält das Berichtszeitraum-Beginndatum »2024-01-01«. Das Webservice unterstützt Übermittlungen nur für Berichtsjahre ab 2025.	.html / .xml
violate_R337a_A_RPT_BVG.YEAR.xml	R337	ERROR	Die Übermittlung enthält den Wert »DE811310738« mehrfach als Übermittlungs-internen Bezug auf Name und Adresse von Verwertungsunternehmen bzw. Verwertungsstandorten. In der Auflistung der Namen und Adressen von Verwertungsunternehmen und Verwertungsstandorten darf jeder als Übermittlungs-interner Bezug zugeordnete Wert nicht öfter als 1 Mal auftreten.	.html / .xml
violate_R344a_A_RPT_BVG.YEAR.xml	R344	ERROR	Die Übermittlung enthält zwei oder mehr Message-Teile mit Inhalten der Art »Masse des eingesetzten Recyclats bezogen auf die in Verkehr gesetzten Einweggetränkeverpackungen gemäß § 24 Abs. 1 Pfandverordnung für Einweggetränkeverpackungen« (Code »RPT_BVG.YEAR.dPG.aRECOVER.tHH.cSTRCT07«). Das Datenformat unterstützt je Inhaltsart höchstens einen Message-Teil.	.html / .xml
violate_R372a_A_RPT_BVG.YEAR.xml	R372	ERROR	Die Übermittlung enthält Name und Adresse des Unternehmens »Nehlsen Cohrs GmbH«. Die Übermittlung enthält jedoch an keiner Stelle einen Bezug auf dieses Unternehmen. Das Datenformat unterstützt die Angabe von Name und Adresse eines Unternehmens nur dann, wenn die Dateninstanz einen oder mehrere Bezüge auf dieses Unternehmen enthält, z.B. als Recyclingunternehmen, an das Getränkeverpackungsmaterialien übergeben wurden.	.html / .xml
violate_R392a_A_RPT_BVG.YEAR.xml	R392	ERROR	Die Übermittlung enthält in der Auflistung von Verwertungsunternehmen mit Name und Adresse dasselbe Unternehmen »Nehlsen Cohrs GmbH« mehrfach. Das Datenformat unterstützt nur solche Auflistungen, in welchen jedes Unternehmen nicht öfter als 1 Mal auftritt.	.html / .xml
violate_R408a_A_RPT_BVG.YEAR.xml	R408	ERROR	Die Übermittlung enthält zu den Inhalten der Art »Von Erstinverkehrsetzern in Österreich in Verkehr gesetzte bepfandete Einweggetränkeverpackungen gemäß § 24 Abs. 1 Pfandverordnung für Einweggetränkeverpackungen« (Code »RPT_BVG.YEAR.dPG.aPLC_MKT.tHH.cSTRCT20«) die Masse -208.550 kg. Das Datenformat unterstützt nur nicht-negative Massen-Angaben. Weitere mit der negativen Masse zusammenhängende Angaben: Packstoff »Kunststoffe« (GTIN 9008390101476); Einwegkunststoff-Getränkeflaschen-Art »Getränkebehälter - PET-Getränkeflaschen« (GTIN 9008390124970); Getränkekategorie »Wässer« (GTIN 9008390132548); Getränkevolumen-Kategorie »über 0,25 l bis inkl. 0,33 l« (GTIN 9008390132616); Anzahl 13.904.500.	.html / .xml
violate_R464a_A_RPT_BVG.YEAR.xml	R464	ERROR	Die Übermittlung enthält zu dem mit Name und Adresse aufgelisteten Verwertungsunternehmen »Nehlsen Cohrs GmbH« die ID »DE811310738« in Kombination mit ID-Art »VAT.DK«. Das Datenformat unterstützt diese ID-Art nicht. Das Datenformat unterstützt hier genau die in edm.gv.at ↗Codeliste 7411 definierten Unternehmens-ID-Arten.	.html / .xml
violate_R467a_A_RPT_BVG.YEAR.xml	R467	ERROR	Die Übermittlung enthält in der Auflistung von Verwertungsunternehmen mit Name und Adresse das Unternehmen mit den folgenden Angaben: VAT.EU: »DE811310738«; Sitz-Land: DE (ID »276«); Sitz-Postleitzahl: »29614«; Sitz-Ort: »Soltau«; ID zur Referenzierung innerhalb der Übermittlung: »DE811310738«. Dabei fehlt die Bezeichnung des Unternehmens (Datenelement »Name«).	.html / .xml
violate_R467b_A_RPT_BVG.YEAR.xml	R467	ERROR	Die Übermittlung enthält in der Auflistung von Verwertungsunternehmen mit Name und Adresse das Unternehmen mit den folgenden Angaben: Bezeichnung: »Nehlsen Cohrs GmbH«; VAT.EU: »DE811310738«; Sitz-Postleitzahl: »29614«; Sitz-Ort: »Soltau«; ID zur Referenzierung innerhalb der Übermittlung: »DE811310738«. Dabei fehlt die Identifikation des Landes, in dem das Unternehmen seinen Sitz hat (Datenelement »RegisteredOfficeAddressCountryID«).	.html / .xml
violate_R467c_A_RPT_BVG.YEAR.xml	R467	ERROR	Die Übermittlung enthält in der Auflistung von Verwertungsunternehmen mit Name und Adresse das Unternehmen mit den folgenden Angaben: Bezeichnung: »Nehlsen Cohrs GmbH«; VAT.EU: »DE811310738«; Sitz-Land: DE (ID »276«); Sitz-Ort: »Soltau«; ID zur Referenzierung innerhalb der Übermittlung: »DE811310738«. Dabei fehlt die Postleitzahl vom Sitz des Unternehmens (Datenelement »RegisteredOfficeAddressPostalAreaID«).	.html / .xml
violate_R467d_A_RPT_BVG.YEAR.xml	R467	ERROR	Die Übermittlung enthält in der Auflistung von Verwertungsunternehmen mit Name und Adresse das Unternehmen mit den folgenden Angaben: Bezeichnung: »Nehlsen Cohrs GmbH«; VAT.EU: »DE811310738«; Sitz-Land: DE (ID »276«); Sitz-Postleitzahl: »29614«; ID zur Referenzierung innerhalb der Übermittlung: »DE811310738«. Dabei fehlt die Bezeichnung des Orts, z.B. Stadt, an dem das Unternehmen seinen Sitz hat (Datenelement »RegisteredOfficeAddressCityName«).	.html / .xml
violate_R491a_A_RPT_BVG.YEAR.xml	R491	WARNING	Die Übermittlung enthält in den Sitzadress-Angaben zum Verwertungsunternehmen »Nehlsen Cohrs GmbH« die Identifikation des Landes (Nationalstaats) CS (ID »891«). Gemäß edm.gv.at ↗Codeliste 3862 gibt es dieses Land seit 02.06.2006 nicht mehr, d.h. das Land hat im Berichtsjahr nicht mehr existiert.	.html / .xml
violate_R495a_A_RPT_BVG.YEAR.xml	R495	ERROR	Die Übermittlung enthält Name und Adresse des Standorts »Nehlsen Cohrs GmbH Standort Schneverdingen«. Die Übermittlung enthält jedoch an keiner Stelle einen Bezug auf diesen Standort. Das Datenformat unterstützt die Angabe von Name und Adresse eines Standorts nur dann, wenn die Dateninstanz einen oder mehrere Bezüge auf diesen Standort enthält, z.B. als Recyclingstandort, an den Getränkeverpackungsmaterialien übergeben wurden.	.html / .xml
violate_R496a_A_RPT_BVG.YEAR.xml	R496	WARNING	Die Übermittlung enthält zu den Inhalten der Art »Von Erstinverkehrsetzern zum Recycling übergebene Massen an Verpackungsmaterialien aus im Rahmen des Vorkaufsrechts übernommenen Einweggetränkeverpackungen gemäß § 24 Abs. 1 Pfandverordnung für Einweggetränkeverpackungen« (Code »RPT_BVG.YEAR.dPG.aHND_RCV.tHH.cSTRCT21«) die Angabe des Verwertungsunternehmens »Saubermacher Dienstleistungs-AG« (GLN.AT 9110015294644). Gemäß Eintrag in edm.gv.at war das Unternehmen im Berichtsjahr stillgelegt, und zwar von 2025-01-01 bis 2025-12-31. Weitere mit der Unternehmens-ID zusammenhängende Angaben in der Übermittlung: Packstoff »Kunststoffe« (GTIN 9008390101476); Verwertungsstandort »Saubermacher AG; STO Puchstraße« (GLN.EDM 9008390026076); Masse 804.365 kg.	.html / .xml
violate_R507a_A_RPT_BVG.YEAR.xml	R507	ERROR	Die Übermittlung enthält zu den Inhalten der Art »Zurückgenommene bepfandete Einweggetränkeverpackungen gemäß § 24 Abs. 1 Pfandverordnung für Einweggetränkeverpackungen« (Code »RPT_BVG.YEAR.dPG.aSEP_CLT.tHH.cSTRCT20«) die Anzahl 0. Das Datenformat unterstützt die Anzahl 0 nicht. Gruppierungen, z.B. Packstoffe, für die im Berichtszeitraum keine entsprechenden Tätigkeiten ausgeübt wurden, sind nicht mit Anzahl 0 zu übermitteln, sondern aus der Übermittlung wegzulassen. Weitere mit der Anzahl 0 zusammenhängende Angaben: Packstoff »Kunststoffe« (GTIN 9008390101476); Einwegkunststoff-Getränkeflaschen-Art »Getränkebehälter - PET-Getränkeflaschen« (GTIN 9008390124970); Getränkekategorie »Alkoholfreie Erfrischungsgetränke« (GTIN 9008390132562); Getränkevolumen-Kategorie »bis inkl. 0,25 l« (GTIN 9008390132609); Masse 277.830 kg.	.html / .xml
violate_R512a_A_RPT_BVG.YEAR.xml	R512	WARNING	Die Übermittlung enthält zu den Inhalten der Art »Von Erstinverkehrsetzern zum Recycling übergebene Massen an Verpackungsmaterialien aus im Rahmen des Vorkaufsrechts übernommenen Einweggetränkeverpackungen gemäß § 24 Abs. 1 Pfandverordnung für Einweggetränkeverpackungen« (Code »RPT_BVG.YEAR.dPG.aHND_RCV.tHH.cSTRCT21«) die Angabe des Verwertungsstandorts »Saubermacher AG; STO Puchstraße« (GLN.EDM 9008390026076). Gemäß Eintrag in edm.gv.at wurde am Standort im Berichtsjahr keine Abfallverwertung durchgeführt. Weitere mit der Standort-ID zusammenhängende Angaben in der Übermittlung: Packstoff »Kunststoffe« (GTIN 9008390101476); Verwertungsunternehmen »Saubermacher Dienstleistungs-AG« (GLN.AT 9110015294644); Masse 804.365 kg.	.html / .xml
violate_R525a_A_RPT_BVG.YEAR.xml	R525	ERROR	Die Übermittlung enthält zu den Inhalten der Art »Recyclierte Verpackungsmaterialien aus von Erstinverkehrsetzern im Rahmen des Vorkaufsrechts übernommenen und zum Recycling übergebenen Einweggetränkeverpackungen gemäß § 24 Abs. 1 Pfandverordnung für Einweggetränkeverpackungen« (Code »RPT_BVG.YEAR.dPG.aRECOVER.tHH.cSTRCT14«) als Übermittlungs-internen Bezug auf Name und Adresse des Verwerters den Wert »DE811310738_A«. Dieser Wert verweist innerhalb der übermittelten Daten nicht auf Name und Adresse eines Unternehmens. Weitere mit dem Verwerter-Bezug zusammenhängende Angaben: Packstoff »Aluminium« (GTIN 9008390106853); Verwertungsart »Recycling« (GTIN 9008390125045); Verwertungsstandort »Nehlsen Cohrs GmbH Standort Schneverdingen«; Masse 78.920 kg.	.html / .xml
violate_R529a_A_RPT_BVG.YEAR.xml	R529	ERROR	In der Übermittlung fehlt zu den Inhalten der Art »Von Erstinverkehrsetzern in Österreich in Verkehr gesetzte bepfandete Einweggetränkeverpackungen gemäß § 24 Abs. 1 Pfandverordnung für Einweggetränkeverpackungen« (Code »RPT_BVG.YEAR.dPG.aPLC_MKT.tHH.cSTRCT20«) die Getränkekategorie (Datenelement »BeverageTypeID«) in Zusammenhang mit den folgenden Angaben: Packstoff »Kunststoffe« (GTIN 9008390101476); Einwegkunststoff-Getränkeflaschen-Art »Getränkebehälter - PET-Getränkeflaschen« (GTIN 9008390124970); Getränkevolumen-Kategorie »bis inkl. 0,25 l« (GTIN 9008390132609); Masse 186.741 kg; Anzahl 12.449.401.	.html / .xml
violate_R529b_A_RPT_BVG.YEAR.xml	R529	ERROR	In der Übermittlung fehlt zu den Inhalten der Art »Von Erstinverkehrsetzern in Österreich in Verkehr gesetzte bepfandete Einweggetränkeverpackungen gemäß § 24 Abs. 1 Pfandverordnung für Einweggetränkeverpackungen« (Code »RPT_BVG.YEAR.dPG.aPLC_MKT.tHH.cSTRCT20«) die Getränkeflaschen-Art (Datenelement »SingleUsePlasticBottleTypeID«) in Zusammenhang mit den folgenden Angaben: Packstoff »Kunststoffe« (GTIN 9008390101476); Getränkekategorie »Alkoholfreie Erfrischungsgetränke« (GTIN 9008390132562); Getränkevolumen-Kategorie »bis inkl. 0,25 l« (GTIN 9008390132609); Masse 280.111 kg; Anzahl 18.674.001.	.html / .xml
violate_R529c_A_RPT_BVG.YEAR.xml	R529	ERROR	In der Übermittlung fehlt zu den Inhalten der Art »Recyclierte Verpackungsmaterialien aus von Erstinverkehrsetzern im Rahmen des Vorkaufsrechts übernommenen und zum Recycling übergebenen Einweggetränkeverpackungen gemäß § 24 Abs. 1 Pfandverordnung für Einweggetränkeverpackungen« (Code »RPT_BVG.YEAR.dPG.aRECOVER.tHH.cSTRCT14«) das Verwertungsunternehmen (Datenelement »RecoveryPartyID« bzw. »RecoveryPartyLocalReferenceID«) in Zusammenhang mit den folgenden Angaben: Packstoff »Aluminium« (GTIN 9008390106853); Verwertungsart »Recycling« (GTIN 9008390125045); Verwertungsstandort »Saubermacher AG; STO Puchstraße« (GLN.EDM 9008390026076); Masse 183.499 kg.	.html / .xml
violate_R529d_A_RPT_BVG.YEAR.xml	R529	ERROR	In der Übermittlung fehlt zu den Inhalten der Art »Recyclierte Verpackungsmaterialien aus von Erstinverkehrsetzern im Rahmen des Vorkaufsrechts übernommenen und zum Recycling übergebenen Einweggetränkeverpackungen gemäß § 24 Abs. 1 Pfandverordnung für Einweggetränkeverpackungen« (Code »RPT_BVG.YEAR.dPG.aRECOVER.tHH.cSTRCT14«) der Verwertungsstandort (Datenelement »RecoverySiteID« bzw. »RecoverySiteLocalReferenceID«) in Zusammenhang mit den folgenden Angaben: Packstoff »Aluminium« (GTIN 9008390106853); Verwertungsart »Recycling« (GTIN 9008390125045); Verwertungsunternehmen »Saubermacher Dienstleistungs-AG« (GLN.AT 9110015294644); Masse 183.499 kg.	.html / .xml
violate_R582a_A_RPT_BVG.YEAR.xml	R582	ERROR	Die Übermittlung enthält in der Auflistung von Verwertungsstandorten mit Name und Adresse denselben Standort »Nehlsen Cohrs GmbH Standort Schneverdingen« mehrfach. Das Datenformat unterstützt nur solche Auflistungen, in welchen jeder Standort nicht öfter als 1 Mal auftritt.	.html / .xml
violate_R636a_A_RPT_BVG.YEAR.xml	R636	WARNING	Die Übermittlung erfolgt am 04.07.2026. Für das Berichtsjahr 2025 hätte die Übermittlung jedoch bis spätestens zum 10. April 2026 erfolgen sollen.	.html / .xml
violate_R683a_A_RPT_BVG.YEAR.xml	R683	ERROR	Die Übermittlung enthält in den Adressangaben zum Verwertungsstandort »Nehlsen Cohrs GmbH Standort Schneverdingen« den Wert »333« als Identifikation eines Landes (Nationalstaats). Das Datenformat unterstützt diesen Wert nicht. Das Datenformat unterstützt hier die Identifikation von Einträgen aus edm.gv.at ↗Codeliste 3862 per 3-Ziffern-ID, z.B. »040« für Österreich. Die edm.gv.at ↗Codeliste 3862 gibt die ISO 3166-1 Liste von Ländern wieder.	.html / .xml
violate_R684a_A_RPT_BVG.YEAR.xml	R684	INFO	Die Übermittlung erfolgt zum Datum »2026-02-07« und enthält das Berichtszeitraum-Enddatum »2026-12-31«, d.h. die Übermittlung erfolgt vor Ablauf des Berichtsjahres. Die Übermittlung soll üblicherweise erst nach Ablauf des Berichtsjahres erfolgen.	.html / .xml
violate_R685a_A_RPT_BVG.YEAR.xml	R685	ERROR	Die Übermittlung enthält zu den Inhalten der Art »Von Erstinverkehrsetzern zum Recycling übergebene Massen an Verpackungsmaterialien aus im Rahmen des Vorkaufsrechts übernommenen Einweggetränkeverpackungen gemäß § 24 Abs. 1 Pfandverordnung für Einweggetränkeverpackungen« (Code »RPT_BVG.YEAR.dPG.aHND_RCV.tHH.cSTRCT21«) die Angabe des Verwerters mit der GLN.AT 9110015294644. In edm.gv.at ist mit dieser ID (GLN) kein Unternehmens-Eintrag auffindbar. Weitere mit der Unternehmens-ID zusammenhängende Angaben in der Übermittlung: Packstoff »Kunststoffe« (GTIN 9008390101476); Verwertungsstandort »Saubermacher AG; STO Puchstraße« (GLN.EDM 9008390026076); Masse 804.365 kg.	.html / .xml
violate_R693a_A_RPT_BVG.YEAR.xml	R693	ERROR	Für die Übermittlung liegt der Berichtszeitraum mehr als 3 Jahre in der Vergangenheit, konkret im Jahr 2025. Die Schnittstelle unterstützt Übermittlungen nur für solche Berichtszeiträume, die höchstens 3 Jahre zurückliegen.	.html / .xml
violate_R699a_A_RPT_BVG.YEAR.xml	R699	WARNING	Die Übermittlung enthält zu den Inhalten der Art »Von Erstinverkehrsetzern zum Recycling übergebene Massen an Verpackungsmaterialien aus im Rahmen des Vorkaufsrechts übernommenen Einweggetränkeverpackungen gemäß § 24 Abs. 1 Pfandverordnung für Einweggetränkeverpackungen« (Code »RPT_BVG.YEAR.dPG.aHND_RCV.tHH.cSTRCT21«) die Angabe des Verwerters »Saubermacher Dienstleistungs-AG« (GLN.AT 9110015294644). Gemäß Eintrag in edm.gv.at war das Unternehmen im Berichtsjahr nicht als Abfallverwerter tätig. Weitere mit der Unternehmens-ID zusammenhängende Angaben in der Übermittlung: Packstoff »Kunststoffe« (GTIN 9008390101476); Verwertungsstandort »Saubermacher AG; STO Puchstraße« (GLN.EDM 9008390026076); Masse 804.365 kg.	.html / .xml
violate_R704a_A_RPT_BVG.YEAR.xml	R704	ERROR	Die Übermittlung enthält das Berichtszeitraum-Enddatum »2025-12-23«. Das Datenformat unterstützt nur den 31. Dezember eines Jahres, z.B. »2025-12-31«, als Berichtszeitraum-Enddatum.	.html / .xml
violate_R737a_A_RPT_BVG.YEAR.xml	R737	ERROR	Die Übermittlung enthält den Message-Erstellungszeitpunkt »2026-02-07T14:56:42.847702Z« und erfolgt zum Zeitpunkt »2026-02-07T14:39:42.847702Z«, d.h. der Message-Erstellungszeitpunkt liegt in der Zukunft. Das Webservice unterstützt die Übermittlung von Messages mit in der Zukunft liegendem Erstellungsdatum NICHT.	.html / .xml
violate_R752a_A_RPT_BVG.YEAR.xml	R752	ERROR	Die Übermittlung enthält ein Gruppierungselement für Angaben von Namen und Adressen von Recyclingunternehmen und/oder Recyclingstandorten, »ListedData«, welches leer ist, d.h. keine XML-Unterelemente enthält. Das Datenformat unterstützt das Gruppierungselement »ListedData« nur bei Vorhandensein von einem oder mehreren XML-Unterelementen, d.h. nur bei Vorhandensein von zumindest einer Namens- und Adress-Angabe zu einem Recyclingunternehmen und/oder einem Recyclingstandort.	.html / .xml
violate_R755a_A_RPT_BVG.YEAR.xml	R755	ERROR	Die Übermittlung enthält die Angabe des Übermittlungs-Erstellers mit der ID »9110032898689« und der ID-Art »GLN.AX«. Das Datenformat unterstützt diese ID-Art nicht. Das Datenformat unterstützt hier genau die in edm.gv.at ↗Codeliste 7836 definierten Unternehmens-ID-Arten.	.html / .xml
violate_R755b_A_RPT_BVG.YEAR.xml	R755	ERROR	Die Übermittlung enthält die Angabe eines Verwertungsunternehmens mit der ID »9110022825107« und der ID-Art »GLN.AX«. Das Datenformat unterstützt diese ID-Art nicht. Das Datenformat unterstützt hier genau die in edm.gv.at ↗Codeliste 7836 definierten Unternehmens-ID-Arten.	.html / .xml
violate_R771a_A_RPT_BVG.YEAR.xml	R771	ERROR	Die Übermittlung enthält in der Auflistung von Verwertungsunternehmen mit Name und Adresse dieselbe Unternehmens-ID »DE811310738« mehrfach, also in den Angaben zu mehreren Unternehmen. Das Datenformat unterstützt nur solche Auflistungen, in welchen jede Unternehmens-ID nicht öfter als 1 Mal auftritt.	.html / .xml
violate_R815a_A_RPT_BVG.YEAR.xml	R815	ERROR	Die Übermittlung enthält zu den Inhalten der Art »Von Erstinverkehrsetzern zum Recycling übergebene Massen an Verpackungsmaterialien aus im Rahmen des Vorkaufsrechts übernommenen Einweggetränkeverpackungen gemäß § 24 Abs. 1 Pfandverordnung für Einweggetränkeverpackungen« (Code »RPT_BVG.YEAR.dPG.aHND_RCV.tHH.cSTRCT21«) die Angabe des Verwertungsstandorts mit der GLN.EDM 9008390026076. In edm.gv.at ist mit dieser ID (GLN) kein Standort-Eintrag auffindbar. Weitere mit der Standort-ID zusammenhängende Angaben in der Übermittlung: Packstoff »Kunststoffe« (GTIN 9008390101476); Verwertungsunternehmen »Saubermacher Dienstleistungs-AG« (GLN.AT 9110015294644); Masse 804.365 kg.	.html / .xml
violate_R853a_A_RPT_BVG.YEAR.xml	R853	INFO	Die Übermittlung enthält zu den Inhalten der Art »Masse des eingesetzten Recyclats bezogen auf die in Verkehr gesetzten Einweggetränkeverpackungen gemäß § 24 Abs. 1 Pfandverordnung für Einweggetränkeverpackungen« (Code »RPT_BVG.YEAR.dPG.aRECOVER.tHH.cSTRCT07«) keine Angaben zu sonstigen Kunststoff-Getränkeflaschen ausgenommen PET-Flaschen für das Berichtsjahr 2028. Gemäß § 24 Abs. 1 Z 5 Pfandverordnung für Einweggetränkeverpackungen erwartet die Behörde diese Angaben ab dem Berichtsjahr 2028.	.html / .xml
violate_R855a_A_RPT_BVG.YEAR.xml	R855	ERROR	Die Übermittlung ENTHÄLT das XML-Attribut »xsi:type« (»type«-Attribut aus dem Namensraum »http://www.w3.org/2001/XMLSchema-instance«). Das Datenformat unterstützt »xsi:type« XML-Attribut-Angaben NICHT.	.html / .xml
violate_R863a_A_RPT_BVG.YEAR.xml	R863	ERROR	Die Übermittlung enthält zu den Inhalten der Art »Recyclierte Verpackungsmaterialien aus von Erstinverkehrsetzern im Rahmen des Vorkaufsrechts übernommenen und zum Recycling übergebenen Einweggetränkeverpackungen gemäß § 24 Abs. 1 Pfandverordnung für Einweggetränkeverpackungen« (Code »RPT_BVG.YEAR.dPG.aRECOVER.tHH.cSTRCT14«) als Übermittlungs-internen Bezug auf Name und Adresse des Verwertungsstandorts den Wert »DE811310738«. Dieser Wert verweist innerhalb der übermittelten Daten nicht auf Name und Adresse eines Standorts. Weitere mit dem Verwertungsstandort-Bezug zusammenhängende Angaben: Packstoff »Aluminium« (GTIN 9008390106853); Verwertungsart »Recycling« (GTIN 9008390125045); Verwertungsunternehmen »Nehlsen Cohrs GmbH«; Masse 78.920 kg.	.html / .xml
violate_R879a_A_RPT_BVG.YEAR.xml	R879	ERROR	Die Übermittlung erfolgt zum Datum »2026-02-07« und enthält das Berichtszeitraum-Beginndatum »2027-01-01«, d.h. die Übermittlung erfolgt vor Beginn des Berichtsjahres. Das Webservice unterstützt Übermittlungen für ein Berichtsjahr erst nach Anbruch dieses Jahres.	.html / .xml
violate_R886a_A_RPT_BVG.YEAR.xml	R886	INFO	Die Übermittlung enthält zu den Inhalten der Art »Von Erstinverkehrsetzern zum Recycling übergebene Massen an Verpackungsmaterialien aus im Rahmen des Vorkaufsrechts übernommenen Einweggetränkeverpackungen gemäß § 24 Abs. 1 Pfandverordnung für Einweggetränkeverpackungen« (Code »RPT_BVG.YEAR.dPG.aHND_RCV.tHH.cSTRCT21«) über alle Packstoffe hinweg die Gesamtmasse 1.417.851 kg, sowie zu den Inhalten der Art »Recyclierte Verpackungsmaterialien aus von Erstinverkehrsetzern im Rahmen des Vorkaufsrechts übernommenen und zum Recycling übergebenen Einweggetränkeverpackungen gemäß § 24 Abs. 1 Pfandverordnung für Einweggetränkeverpackungen« (Code »RPT_BVG.YEAR.dPG.aRECOVER.tHH.cSTRCT14«) über alle Packstoffe hinweg die Gesamtmasse 6.824.351.070 kg. Die Gesamtmasse der recyclierten Verpackungsmaterialien ist für den Berichtszeitraum also größer als die Gesamtmasse der zum Recycling übergebenen Verpackungsmaterialien.	.html / .xml
violate_R886b_A_RPT_BVG.YEAR.xml	R886	INFO	Die Übermittlung enthält zu den Inhalten der Art »Von der zentralen Stelle zum Recycling übergebene Massen an Verpackungsmaterialien gemäß § 24 Abs. 1 Pfandverordnung für Einweggetränkeverpackungen« (Code »RPT_BVG.YEAR.dPG.aHND_RCV.tHH.bC.cSTRCT21«) über alle Packstoffe hinweg die Gesamtmasse 133.501 kg, sowie zu den Inhalten der Art »Recyclierte Verpackungsmaterialien aus von der zentralen Stelle zum Recycling übergebenen Einweggetränkeverpackungen gemäß § 24 Abs. 1 Pfandverordnung für Einweggetränkeverpackungen« (Code »RPT_BVG.YEAR.dPG.aRECOVER.tHH.bC.cSTRCT14«) über alle Packstoffe hinweg die Gesamtmasse 29.559.215 kg. Die Gesamtmasse der recyclierten Verpackungsmaterialien ist für den Berichtszeitraum also größer als die Gesamtmasse der zum Recycling übergebenen Verpackungsmaterialien.	.html / .xml
violate_R931a_A_RPT_BVG.YEAR.xml	R931	ERROR	Die Übermittlung weist das Unternehmen »EWP Recycling Pfand Österreich gGmbH« (GLN.AT 9110032898689) als Ersteller der Übermittlung aus. In der Datenübermittlungs-Interaktion mit dem edm.gv.at Webservice identifiziert und authentifiziert sich der Webservice-Client »RECYCLING_PFAND_AT.CLOUD«. edm.gv.at enthält für »RECYCLING_PFAND_AT.CLOUD« keine aktive (gültige) Freischaltung, im Namen von »EWP Recycling Pfand Österreich gGmbH« (GLN.AT 9110032898689) mit dem Webservice interagieren zu dürfen. Für Übermittlungen an die Behörde ist die Eintragung einer solchen Freischaltung in edm.gv.at jedoch Voraussetzung.	.html / .xml
violate_R942a_A_RPT_BVG.YEAR.xml	R942	WARNING	Die Übermittlung enthält zu den Inhalten der Art »Von Erstinverkehrsetzern zum Recycling übergebene Massen an Verpackungsmaterialien aus im Rahmen des Vorkaufsrechts übernommenen Einweggetränkeverpackungen gemäß § 24 Abs. 1 Pfandverordnung für Einweggetränkeverpackungen« (Code »RPT_BVG.YEAR.dPG.aHND_RCV.tHH.cSTRCT21«) die Angabe des Verwertungsunternehmens »Saubermacher Dienstleistungs-AG« (GLN.AT 9110015294644). Gemäß Eintrag in edm.gv.at war das Unternehmen im Berichtsjahr ruhendgestellt, und zwar von 2020-01-01 bis 2030-12-31. Weitere mit der Unternehmens-ID zusammenhängende Angaben in der Übermittlung: Packstoff »Kunststoffe« (GTIN 9008390101476); Verwertungsstandort »Saubermacher AG; STO Puchstraße« (GLN.EDM 9008390026076); Masse 804.365 kg.	.html / .xml
violate_R953a_A_RPT_BVG.YEAR.xml	R953	ERROR	Die Übermittlung enthält in jenem Message-Teil, der sich auf Inhalte der Art »Masse des eingesetzten Recyclats bezogen auf die in Verkehr gesetzten Einweggetränkeverpackungen gemäß § 24 Abs. 1 Pfandverordnung für Einweggetränkeverpackungen« (Code »RPT_BVG.YEAR.dPG.aRECOVER.tHH.cSTRCT07«) bezieht, die Kennzeichung, dass in Bezug auf die Inhaltsart im Berichtszeitraum zu berichtende Tätigkeiten ausgeübt wurden (»ReportingObligationActivityIndicator« auf Wert »true«), es fehlen aber Angaben zu diesen Tätigkeiten, z.B. Massen je Untergliederung. Es muss eine Übereinstimmung zwischen (a) der Information, ob zu berichtende Tätigkeiten ausgeübt wurden, und (b) dem Vorhandensein btw. Nicht-Vorhandensein von Masse-/Anzahl-Angaben bestehen.	.html / .xml
violate_R956a_A_RPT_BVG.YEAR.xml	R956	ERROR	Die Übermittlung enthält zu den Inhalten der Art »Von Erstinverkehrsetzern in Österreich in Verkehr gesetzte bepfandete Einweggetränkeverpackungen gemäß § 24 Abs. 1 Pfandverordnung für Einweggetränkeverpackungen« (Code »RPT_BVG.YEAR.dPG.aPLC_MKT.tHH.cSTRCT20«) die Masse 0 kg. Das Datenformat unterstützt die Masse 0 nicht. Gruppierungen, z.B. Packstoffe, für die im Berichtszeitraum keine entsprechenden Tätigkeiten ausgeübt wurden, sind nicht mit Masse 0 zu übermitteln, sondern aus der Übermittlung wegzulassen. Weitere mit der Masse 0 zusammenhängende Angaben: Packstoff »Kunststoffe« (GTIN 9008390101476); Einwegkunststoff-Getränkeflaschen-Art »Getränkebehälter - Sonstige Getränkeflaschen« (GTIN 9008390124987); Getränkekategorie »Alkoholfreie Erfrischungsgetränke« (GTIN 9008390132562); Getränkevolumen-Kategorie »über 0,25 l bis inkl. 0,33 l« (GTIN 9008390132616); Anzahl 7.000.000.	.html / .xml
violate_R958a_A_RPT_BVG.YEAR.xml	R958	ERROR	Die Übermittlung enthält zu den Inhalten der Art »Von Erstinverkehrsetzern in Österreich in Verkehr gesetzte bepfandete Einweggetränkeverpackungen gemäß § 24 Abs. 1 Pfandverordnung für Einweggetränkeverpackungen« (Code »RPT_BVG.YEAR.dPG.aPLC_MKT.tHH.cSTRCT20«) die Anzahl -13.904.500. Das Datenformat unterstützt nur nicht-negative Anzahl-Angaben. Weitere mit der negativen Anzahl zusammenhängende Angaben: Packstoff »Kunststoffe« (GTIN 9008390101476); Einwegkunststoff-Getränkeflaschen-Art »Getränkebehälter - PET-Getränkeflaschen« (GTIN 9008390124970); Getränkekategorie »Wässer« (GTIN 9008390132548); Getränkevolumen-Kategorie »über 0,25 l bis inkl. 0,33 l« (GTIN 9008390132616); Masse 208.550 kg.	.html / .xml
violate_R988a_A_RPT_BVG.YEAR.xml	R988	ERROR	Die Übermittlung enthält zu den Inhalten der Art »Von Erstinverkehrsetzern zum Recycling übergebene Massen an Verpackungsmaterialien aus im Rahmen des Vorkaufsrechts übernommenen Einweggetränkeverpackungen gemäß § 24 Abs. 1 Pfandverordnung für Einweggetränkeverpackungen« (Code »RPT_BVG.YEAR.dPG.aHND_RCV.tHH.cSTRCT21«) die Anzahl (Datenelement »Count«) und diese Detailangaben: Packstoff »Aluminium« (GTIN 9008390106853); Verwertungsunternehmen »Saubermacher Dienstleistungs-AG« (GLN.AT 9110015294644); Verwertungsstandort »Saubermacher AG; STO Puchstraße« (GLN.EDM 9008390026076); Masse 456.650 kg; Anzahl 30.138.900. Das Datenformat unterstützt in diesem Zusammenhang keine »Count«-Datenelemente.	.html / .xml
violate_R988b_A_RPT_BVG.YEAR.xml	R988	ERROR	Die Übermittlung enthält zu den Inhalten der Art »Zurückgenommene bepfandete Einweggetränkeverpackungen gemäß § 24 Abs. 1 Pfandverordnung für Einweggetränkeverpackungen« (Code »RPT_BVG.YEAR.dPG.aSEP_CLT.tHH.cSTRCT20«) die Getränkeflaschen-Art (Datenelement »SingleUsePlasticBottleTypeID«) und diese Detailangaben: Packstoff »Aluminium« (GTIN 9008390106853); Einwegkunststoff-Getränkeflaschen-Art »Getränkebehälter - Sonstige Getränkeflaschen« (GTIN 9008390124987); Getränkekategorie »Alkoholfreie Erfrischungsgetränke« (GTIN 9008390132562); Getränkevolumen-Kategorie »bis inkl. 0,25 l« (GTIN 9008390132609); Masse 50.425 kg; Anzahl 3.361.500. Das Datenformat unterstützt in diesem Zusammenhang keine »SingleUsePlasticBottleTypeID«-Datenelemente.	.html / .xml
violate_R988c_A_RPT_BVG.YEAR.xml	R988	ERROR	Die Übermittlung enthält zu den Inhalten der Art »Zurückgenommene bepfandete Einweggetränkeverpackungen gemäß § 24 Abs. 1 Pfandverordnung für Einweggetränkeverpackungen« (Code »RPT_BVG.YEAR.dPG.aSEP_CLT.tHH.cSTRCT20«) das Verwertungsunternehmen (Datenelement »RecoveryPartyID«) und diese Detailangaben: Packstoff »Aluminium« (GTIN 9008390106853); Getränkekategorie »Alkoholfreie Erfrischungsgetränke« (GTIN 9008390132562); Getränkevolumen-Kategorie »bis inkl. 0,25 l« (GTIN 9008390132609); Verwertungsunternehmen »Saubermacher Dienstleistungs-AG« (GLN.AT 9110015294644); Masse 50.425 kg; Anzahl 3.361.500. Das Datenformat unterstützt in diesem Zusammenhang keine »RecoveryPartyID«-Datenelemente.	.html / .xml

Definitionen und Verweise

Begriffe und Definitionen

Diese Schnittstellenbeschreibung verwendet Fachbegriffe wie Einweggetränkeverpackung, Gebindeart, Inverkehrsetzen, Packstoff, Recyclieren, Verpackung und Zurücknehmen entsprechend [AWG 2002], [PfandVO] und [VerpackVO 2014].

Zudem verwendet die Schnittstellenbeschreibung technische Begriffe wie Datenformat, Schema, Schema-Validierung entsprechend der genutzten technischen Standards, z.B. [XML], [XSD] und [Schematron]. Siehe Verweise.

Weitere in der Schnittstellenbeschreibung verwendete Begriffe:

Datenbank

Sammlung von maschinenlesbaren Informationen, die so organisiert sind, dass Zugang, Verwaltung und Aktualisierung leicht und effizient erfolgen können.

Electronic Data Interchange (Elektronischer Datenaustausch)

Strukturierte Art der Übermittlung von elektronisch gespeicherten Daten von ⭧ Datenbank zu ⭧ Datenbank, in der Regel über Telekommunikationsnetze.

Formale Prüfung

Bezieht sich auf die Kombination aus folgendem:

- In einer formalen Sprache definierte Prüfregeln – eine formale Sprache ist maschinenlesbar und hat eine klar definierte Syntax und Semantik;
- Die automatisierte Überprüfung empfangener Messages auf die Einhaltung der in der formalen Sprache definierten Prüfregeln.

Beispiel für eine formale Prüfregel: „Masse muss größer gleich 0.0 sein“ (Mass ge 0.0).

Anmerkung: Der Begriff formale Prüfung kann auch in Abgrenzung zu komplexeren automatisierten Prüfungen verstanden werden, z.B. KI-basierten Prüfungen.

Message

Sammlung von Informationen, die über einen Informationskanal als eine einzige logische Einheit gesendet werden.

Signal Message

Eine ⭧ Message mit einer unterstützenden Funktion im EDI.

Im vorliegenden Webservice kommt eine Signal Message ausschließlich als automatische Antwort des Webservice auf einen Übermittlungsversuch an die Behörde vor, und enthält insbesondere die folgenden Informationen:

1. Information darüber, ob das Webservice die empfangene ⭧ User Message verarbeiten konnte (ACCEPTED Signal) oder ablehnen musste (REJECTED Signal);
2. Ggf. Prüfprotokoll aus der formalen Prüfung der empfangenen ⭧ User Message.

User Message

Eine im EDI ⭧ Message, die Nutzdaten enthält.

In Zusammenhang mit dem Getränkeverpackungen Einwegpfand Webservice sind Nutzdaten Angaben zu Einweggetränkeverpackungen, z.B. deren Inverkehrsetzung und Sammlung.

Siehe auch ⭧ Signal Message.

Akronyme

BMK

Bundesministerium für Klimaschutz, Umwelt, Energie, Mobilität, Innovation und Technologie, https://www.bmk.gv.at/

EDI

Electronic Data Interchange (Elektronischer Datenaustausch)

EDM

Elektronisches Datenmanegement in der Umwelt- und Abfallwirtschaft, vom BMK betriebene e-Government-Lösung, https://edm.gv.at/

GLN

Global Location Number, ein von GS1 spezifiziertes und verwaltetes Identifikationsschema für (Unternehmens-)Standorte

GS1

Global Standards One, ein Netzwerk von Non-Profit-Organisationen, das mit Unternehmensverbänden, Behörden, Regierungen und Hochschulen arbeitet um standardbasierte Lösungen für den elektronischen Datenaustausch (EDI) zu entwickeln, https://www.gs1.org/

GTIN

Global Trade Item Number, ein von GS1 spezifiziertes und verwaltetes Identifikationsschema für Handelsartikel

IEC

International Electrotechnical Commission, eine internationale Normungsorganisation, die Normen für elektrische, elektronische und verwandte Technologien ausarbeitet und veröffentlicht, https://www.iec.ch/

ISO

International Organization for Standardization, ein internationales Normungsgremium, das sich aus Vertretern der verschiedenen nationalen Normungsorganisationen zusammensetzt, https://www.iso.org/

SVRL

Schematron Validation Report Language, ein im [Schematron]-Standard spezifiziertes [XML]-Datenformat für Ergebnisse formaler Prüfungen (Prüfprotokolle)

W3C

World Wide Web Consortium, eine internationale Organisation, die offene Internet-bezogene Standards entwickelt, https://www.w3.org/

Verweise

AWG 2002

Bundesgesetz über eine nachhaltige Abfallwirtschaft (Abfallwirtschaftsgesetz 2002), BGBl. I Nr. 102/2002, idgF.

Base64

The Base16, Base32, and Base64 Data Encodings, RFC 4648, IETF Internet Official Protocol Standards.

HMAC

Keyed-Hashing for Message Authentication, RFC 2104, IETF Internet Standard.

HTML 5

Hypertext Markup Language, Web Hypertext Application Technology Working Group (WHATWG) und W3C Empfehlung.

HTTP/1.1

Hypertext Transfer Protocol, RFC 723x, IETF Internet Standard.

HTTP Basic Authentication

The 'Basic' HTTP Authentication Scheme, RFC 7617, IETF Internet Standard

PfandVO

Verordnung der Bundesministerin für Klimaschutz, Umwelt, Energie, Mobilität, Innovation und Technologie über das Pfand für Einweggetränkeverpackungen aus Kunststoff oder Metall (Pfandverordnung für Einweggetränkeverpackungen), BGBl. II Nr. 283/2023, idgF.

PPWD - EU Packaging and Packaging Waste Directive

European Parliament and Council Directive 94/62/EC of 20 December 1994 on packaging and packaging waste.

Schematron 2016

Information technology, Schema Definition Languages (DSDL), Part 3: Rule-based validation, ISO/IEC 19757-3 Standard.

SchXslt 1.7.1

Ein vollständig in [XSLT] implementierter [Schematron]-Prozessor. Er wandelt eine [Schematron]-Prüfregel-Datei in ein [XSLT]-Stylesheet um. Anwenden der daraus entstandenen [XSLT]-Transformation auf die zu validierende [XML]-Instanz per [XSLT]-Prozessor liefert das SVRL-Prüfprotokoll.

SHA-256

US Secure Hash Algorithms (SHA and SHA-based [HMAC] and HKDF), RFC 6234 IETF Internet Standard.

SOAP 1.2

Lightweight protocol intended for exchanging structured information in a decentralized, distributed environment, W3C Recommendation.

SUPD - EU Single Use Plastics Directive

Directive (EU) 2019/904 of the European Parliament and of the Council of 5 June 2019 on the reduction of the impact of certain plastic products on the environment.

TLS 1.2, 1.3

Transport Layer Security (TLS) Protocol, RFC 5246 and RFC 8446, IETF Internet Standard.

Unicode

Universal character encoding, Standard für die Kodierung von Zeichen, der die Kodierung von geschriebenen Texten für die meisten Sprachen der Welt unterstützt, The Unicode Consortium.

UTC

Coordinated Universal Time, Standard-frequency and time-signal emissions, Recommendation ITU-R TF.460-6, International Telecommunication Union.

UTF-8

8-bit Unicode Transformation Format, [Unicode]-Kodierungsform mit variabler Anzahl von Bytes je Zeichen und ASCII (American Standard Code for Information Interchange)-Kompatibilität, The Unicode Consortium.

VerpackVO 2014

Verordnung des Bundesministers für Land- und Forstwirtschaft, Umwelt und Wasserwirtschaft über die Vermeidung und Verwertung von Verpackungsabfällen und bestimmten Warenresten (Verpackungsverordnung 2014), BGBl. II Nr. 184/2014, idgF.

WSDL 2.0

Web Services Description Language, eine [XML] Sprache zur Beschreibung von Webservices, W3C Recommendation.

XML 1.0

Extensible Markup Language, W3C Recommendation.

XSD 1.0

[XML] Schema Definition Language, W3C Recommendation.

XSLT 2.0

Extensible Stylesheet Language Transformations, W3C Recommendation.

Spezifikations-Änderungsverzeichnis

Änderungsverzeichnis

Version	Datum	Beschreibung / Änderungen
0.02	2025‑02‑04	Prüfregel R693 hinzugefügt. Diese Prüfregel verhindert Datenübermittlungen für mehr als 3 Jahre zurückliegende Berichtszeiträume.
0.01	2024‑09‑04	Interner Erstentwurf

Detailänderungen (diff) gegenüber der Vorversion 0.00

pack_deposit_refund_formalvalidationrules.sch

@@ -1,8 +1,8 @@

<?xml version="1.0" encoding="utf-8"?>

<!--

- PACK_DEPOSIT_REFUND v0.01

+ PACK_DEPOSIT_REFUND v0.02

Contact: edm-helpdesk@umweltbundesamt.at

Commissioned by the Austrian Federal Ministry of Environment (BMK)

@@ -906,10 +906,11 @@

<report id="R248" role="ERROR" test="(substring(current()/../pkm:MessageTypeID, 9) eq 'YEAR') and (format-date(xs:date(../pkm:ReportPeriodStartDate), '[Y]') ne format-date(xs:date(.), '[Y]'))">Die Übermittlung enthält das Berichtszeitraum-Beginndatum »<sch:value-of select="format-date(xs:date(../pkm:ReportPeriodStartDate), '[Y]-[M,2]-[D,2]')"/>« und das Berichtszeitraum-Enddatum »<sch:value-of select="format-date(xs:date(.), '[Y]-[M,2]-[D,2]')"/>«. Das Datenformat unterstützt nur solche Berichtszeiträume, bei welchen Beginndatum und Enddatum innerhalb desselben Kalenderjahres liegen.</report>

+ <report id="R693" role="ERROR" test="(format-date(xs:date(../pkm:ReportPeriodStartDate), '[Y]') eq format-date(xs:date(.), '[Y]')) and exists(/pkm:MessageValidationContext/pkm:EDIInteractionUTCTimestamp) and ((year-from-dateTime(xs:dateTime(/pkm:MessageValidationContext/pkm:EDIInteractionUTCTimestamp))-year-from-date(xs:date(.))) gt 3)">Für die Übermittlung liegt der Berichtszeitraum mehr als 3 Jahre in der Vergangenheit, konkret im Jahr <sch:value-of select="format-date(xs:date(.), '[Y]')"/>. Die Schnittstelle unterstützt Übermittlungen nur für solche Berichtszeiträume, die höchstens 3 Jahre zurückliegen.</report>

<report id="R704" role="ERROR" test="ends-with(current()/../pkm:MessageTypeID, 'YEAR') and (format-date(xs:date(current()), '[Y]-[M,2]-[D,2]') ne format-date(xs:date(current()), '[Y]-12-31'))">Die Übermittlung enthält das Berichtszeitraum-Enddatum »<sch:value-of select="format-date(xs:date(current()), '[Y]-[M,2]-[D,2]')"/>«. Das Datenformat unterstützt nur den 31. Dezember eines Jahres, z.B. »<sch:value-of select="format-date(xs:date(current()), '[Y]-12-31')"/>«, als Berichtszeitraum-Enddatum.</report>

<report id="R684" role="INFO" test="exists(/pkm:MessageValidationContext/pkm:EDIInteractionUTCTimestamp) and (xs:date(current()) gt f:UTCtimestampToDate(/pkm:MessageValidationContext/pkm:EDIInteractionUTCTimestamp,xs:dayTimeDuration('PT1H'))) and not(xs:date(../pkm:ReportPeriodStartDate) gt f:UTCtimestampToDate(/pkm:MessageValidationContext/pkm:EDIInteractionUTCTimestamp,xs:dayTimeDuration('PT1H')))">Die Übermittlung erfolgt zum Datum »<sch:value-of select="format-date(f:UTCtimestampToDate(/pkm:MessageValidationContext/pkm:EDIInteractionUTCTimestamp,xs:dayTimeDuration('PT1H')), '[Y]-[M,2]-[D,2]')"/>« und enthält das Berichtszeitraum-Enddatum »<sch:value-of select="format-date(xs:date(current()), '[Y]-[M,2]-[D,2]')"/>«, d.h. die Übermittlung erfolgt vor Ablauf des Berichtsjahres. Die Übermittlung soll üblicherweise erst nach Ablauf des Berichtsjahres erfolgen.</report>

<report id="R272" role="INFO" test="exists(/pkm:MessageValidationContext/pkm:EDIInteractionUTCTimestamp) and (f:UTCtimestampToDate(/pkm:MessageValidationContext/pkm:EDIInteractionUTCTimestamp,xs:dayTimeDuration('PT2H')) ge xs:date(format-date(xs:date(current())+xs:yearMonthDuration('P1Y'),'[Y]-04-11'))) and (f:UTCtimestampToDate(/pkm:MessageValidationContext/pkm:EDIInteractionUTCTimestamp,xs:dayTimeDuration('PT2H')) le xs:date(format-date(xs:date(current())+xs:yearMonthDuration('P1Y'),'[Y]-06-30')))">Die Übermittlung erfolgt am <sch:value-of select="format-date(f:UTCtimestampToDate(/pkm:MessageValidationContext/pkm:EDIInteractionUTCTimestamp,xs:dayTimeDuration('PT2H')),'[D,2].[M,2].[Y]')"/>. Für das Berichtsjahr <sch:value-of select="year-from-date(xs:date(current()))"/> hätte die Übermittlung jedoch bis spätestens zum 10. April <sch:value-of select="year-from-date(xs:date(current()))+1"/> erfolgen sollen.</report>

- <report id="R636" role="WARNING" test="exists(/pkm:MessageValidationContext/pkm:EDIInteractionUTCTimestamp) and (f:UTCtimestampToDate(/pkm:MessageValidationContext/pkm:EDIInteractionUTCTimestamp,xs:dayTimeDuration('PT2H')) gt xs:date(format-date(xs:date(current())+xs:yearMonthDuration('P1Y'),'[Y]-06-30')))">Die Übermittlung erfolgt am <sch:value-of select="format-date(f:UTCtimestampToDate(/pkm:MessageValidationContext/pkm:EDIInteractionUTCTimestamp,xs:dayTimeDuration('PT2H')),'[D,2].[M,2].[Y]')"/>. Für das Berichtsjahr <sch:value-of select="year-from-date(xs:date(current()))"/> hätte die Übermittlung jedoch bis spätestens zum 10. April <sch:value-of select="year-from-date(xs:date(current()))+1"/> erfolgen sollen.</report>

+ <report id="R636" role="WARNING" test="exists(/pkm:MessageValidationContext/pkm:EDIInteractionUTCTimestamp) and ((year-from-dateTime(xs:dateTime(/pkm:MessageValidationContext/pkm:EDIInteractionUTCTimestamp))-year-from-date(xs:date(.))) le 3) and (f:UTCtimestampToDate(/pkm:MessageValidationContext/pkm:EDIInteractionUTCTimestamp,xs:dayTimeDuration('PT2H')) gt xs:date(format-date(xs:date(current())+xs:yearMonthDuration('P1Y'),'[Y]-06-30')))">Die Übermittlung erfolgt am <sch:value-of select="format-date(f:UTCtimestampToDate(/pkm:MessageValidationContext/pkm:EDIInteractionUTCTimestamp,xs:dayTimeDuration('PT2H')),'[D,2].[M,2].[Y]')"/>. Für das Berichtsjahr <sch:value-of select="year-from-date(xs:date(current()))"/> hätte die Übermittlung jedoch bis spätestens zum 10. April <sch:value-of select="year-from-date(xs:date(current()))+1"/> erfolgen sollen.</report>

</rule>

</pattern>

pack_deposit_refund_message.xsd

@@ -1,8 +1,8 @@

<?xml version="1.0" encoding="utf-8"?>

<!--

- PACK_DEPOSIT_REFUND v0.01

+ PACK_DEPOSIT_REFUND v0.02

Contact: edm-helpdesk@umweltbundesamt.at

Commissioned by the Austrian Federal Ministry of Environment (BMK)

@@ -19,7 +19,7 @@

See the Licence for the specific language governing permissions and limitations under the Licence.

-->

-<xs:schema xmlns:pkm="http://www.umweltbundesamt.at/schema/pack_deposit_refund_message" xmlns:svrl="http://purl.oclc.org/dsdl/svrl" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" targetNamespace="http://www.umweltbundesamt.at/schema/pack_deposit_refund_message" elementFormDefault="qualified" attributeFormDefault="unqualified" version="0.01">

+<xs:schema xmlns:pkm="http://www.umweltbundesamt.at/schema/pack_deposit_refund_message" xmlns:svrl="http://purl.oclc.org/dsdl/svrl" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" targetNamespace="http://www.umweltbundesamt.at/schema/pack_deposit_refund_message" elementFormDefault="qualified" attributeFormDefault="unqualified" version="0.02">

<xs:import namespace="http://purl.oclc.org/dsdl/svrl" schemaLocation="svrl.xsd"/>

<xs:element name="ReportUserMessage" type="pkm:ReportUserMessage"/>

<xs:element name="SignalMessage" type="pkm:SignalMessage"/>

pack_deposit_refund_webservice.wsdl

@@ -1,8 +1,8 @@

<?xml version="1.0" encoding="utf-8"?>

<!--

- PACK_DEPOSIT_REFUND v0.01

+ PACK_DEPOSIT_REFUND v0.02

Contact: edm-helpdesk@umweltbundesamt.at

Commissioned by the Austrian Federal Ministry of Environment (BMK)

@@ -58,7 +58,7 @@

</wsdl:binding>

<wsdl:service name="PackDepositRefundService">

<wsdl:port name="PackDepositRefundServicePort" binding="pks:PackDepositRefundServiceSoap12Binding">

- <soap12:address location="https://secure.umweltbundesamt.at/pack_deposit_refund_ws"/>

+ <soap12:address location="https://edm.gv.at/pack_deposit_refund_ws"/>

</wsdl:port>

</wsdl:service>

</wsdl:definitions>

pack_deposit_refund_webservice_types.xsd

@@ -1,8 +1,8 @@

<?xml version="1.0" encoding="utf-8"?>

<!--

- PACK_DEPOSIT_REFUND v0.01

+ PACK_DEPOSIT_REFUND v0.02

Contact: edm-helpdesk@umweltbundesamt.at

Commissioned by the Austrian Federal Ministry of Environment (BMK)

@@ -19,7 +19,7 @@

See the Licence for the specific language governing permissions and limitations under the Licence.

-->

-<xs:schema xmlns:pkm="http://www.umweltbundesamt.at/schema/pack_deposit_refund_message" xmlns:pkt="http://www.umweltbundesamt.at/schema/pack_deposit_refund_webservice_types" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" targetNamespace="http://www.umweltbundesamt.at/schema/pack_deposit_refund_webservice_types" elementFormDefault="qualified" attributeFormDefault="unqualified" version="0.01">

+<xs:schema xmlns:pkm="http://www.umweltbundesamt.at/schema/pack_deposit_refund_message" xmlns:pkt="http://www.umweltbundesamt.at/schema/pack_deposit_refund_webservice_types" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" targetNamespace="http://www.umweltbundesamt.at/schema/pack_deposit_refund_webservice_types" elementFormDefault="qualified" attributeFormDefault="unqualified" version="0.02">

<xs:import namespace="http://www.umweltbundesamt.at/schema/pack_deposit_refund_message" schemaLocation="pack_deposit_refund_message.xsd"/>

<xs:element name="ShareMessageRequest" type="pkt:ShareMessageRequestType"/>

<xs:element name="ShareMessageResponse" type="pkt:ShareMessageResponseType"/>

svrl.xsd

@@ -1,8 +1,8 @@

<?xml version="1.0" encoding="utf-8"?>

<!--

- PACK_DEPOSIT_REFUND v0.01

+ PACK_DEPOSIT_REFUND v0.02

Contact: edm-helpdesk@umweltbundesamt.at

Commissioned by the Austrian Federal Ministry of Environment (BMK)