BESCHREIBUNG DER EVERPACKUNG WEBSERVICE-SCHNITTSTELLE FÜR AMMEL UND...

BESCHREIBUNG DER EVERPACKUNG WEBSERVICE-SCHNITTSTELLE FÜR

SAMMEL- UND VERWERTUNGSSYSTEME

SCHNITTSTELLEN-VERSION: V1.05

BESCHREIBUNGSDOKUMENT-VERSION: V1.00

DOKUMENTERSTELLUNGSDATUM: 4. AUGUST 2015

Bundesministerium für Land- und Forstwirtschaft, Umwelt und Wasserwirtschaft Stubenbastei 5

1010 Wien

Beschreibung der eVerpackung Webservice-Schnittstelle für Sammel- und Verwertungssysteme EDM

© 2015 Umweltbundesamt Seite 2 von 41

INHALTSVERZEICHNIS

1 Einleitung ......................................................................................................................... 3 1.1 Inhalt und Zweck des Dokuments .................................................................................... 3 1.2 Aufbau des Dokuments ................................................................................................... 4 1.3 Verwendung des Dokuments ........................................................................................... 4 1.4 Literaturhinweise ............................................................................................................ 4 1.5 Kontakt .......................................................................................................................... 5 1.6 Schnittstellen-Änderungsverzeichnis ................................................................................. 5

2 Beschreibung des Datenformats ..................................................................................... 6 2.1 Allgemeine Anmerkungen zum Datenformat ..................................................................... 6

2.1.1 Zielsetzungen und Prinzipien der Datenmodellierung ............................................. 6 2.1.2 XML ................................................................................................................... 7 2.1.3 Zeichencodierung: UTF-8 .................................................................................... 7 2.1.4 XML Schema ....................................................................................................... 7 2.1.5 Datenanforderungen und Datenprüfungen ........................................................... 8 2.1.6 Codelisten .......................................................................................................... 9 2.1.7 Identifikationszeichenketten und natürlichsprachige Angaben ...............................10 2.1.8 XML Schema Design Pattern: Venetian Blind ........................................................11

2.2 Einleitung zur nachfolgenden Datenformat-Detailbeschreibung .........................................12 2.2.1 Allgemeines .......................................................................................................12 2.2.2 Datenformat für Meldungen und Datenformat für Marktanteile .............................12

2.3 Datenformat-Überblicksdiagramm ...................................................................................14 2.4 Datenformat-Strukturverzeichnis .....................................................................................14 2.5 Datenformat-Strukturbeschreibung .................................................................................15 2.6 Zuordnung von Fachbegriffen zu Datenelementen ...........................................................26

3 XML Beispieldaten ......................................................................................................... 26 3.1 Allgemeines ...................................................................................................................26 3.2 XML Beispieldaten ..........................................................................................................27 3.3 Erläuterungen ................................................................................................................28

4 Webservice Beschreibung .............................................................................................. 30 4.1 Operationen ..................................................................................................................30

4.1.1 RequestTransactionID ........................................................................................30 4.1.2 ShareDocument .................................................................................................30 4.1.3 QueryTransactionStatus .....................................................................................32 4.1.4 QueryDocumentValidationResult .........................................................................33 4.1.5 RetrieveDocument .............................................................................................35

4.2 Fehlerbehandlung ..........................................................................................................36 4.3 Authentifizierung ...........................................................................................................37 4.4 Wenn unrichtige Meldungsinhalte übermittelt wurden ......................................................37

5 Vorgaben an Software mit Schnittstellenanbindung und an deren Benutzer ............... 37 5.1 Allgemeines ...................................................................................................................37 5.2 Vorgaben, die ausschließlich die Software betreffen .........................................................38

5.2.1 Erstellung und Verarbeitung von Dateninstanzen .................................................38 5.2.2 Persistierung und (De-)serialisierung ...................................................................38 5.2.3 Umgang mit Codelisten ......................................................................................39 5.2.4 Fehlerbehandlung ..............................................................................................39 5.2.5 Authentifizierung ...............................................................................................40

5.3 Vorgaben, die auch den Benutzer der Software betreffen können .....................................40 5.3.1 Authentifizierung ...............................................................................................40 5.3.2 Fristen ..............................................................................................................41



1 EINLEITUNG

1.1 Inhalt und Zweck des Dokuments

Das EDM, das Elektronische Daten-Management in der Umwelt- und Abfallwirtschaft, ermöglicht es,

Meldeverpflichtungen und Registrierungsverpflichtungen im Umwelt- und Abfallbereich elektronisch

abzuwickeln.

Am EDM Anwendungsportal http://edm.gv.at steht neben zahlreichen weiteren Anwendungen die

Teilanwendung eVerpackung zur Verfügung: Über diese Anwendung können unter anderem Sammel- und Verwertungssysteme für Verpackungen Meldungen gemäß Abfallwirtschaftsgesetz 2003 und

Verpackungsverordnung 2014 elektronisch einbringen.

Für die folgenden Arten von Monats- und Jahresmeldungen ist im EDM eine Webservice-Schnittstelle für

die automatisierte elektronische Einbringung durch Sammel- und Verwertungssysteme eingerichtet:

1. Meldung eines Sammel- und Verwertungssystems für Haushaltsverpackungen über die in einem Kalendermonat von seinen Teilnehmern in Verkehr gesetzten oder zum Eigengebrauch

importierten Massen an Haushaltsverpackungen je Tarifkategorie, gemäß § 29b Abs. 3 Abfallwirtschaftsgesetz 2002;

2. Meldung eines Sammel- und Verwertungssystems für Gewerbeverpackungen über die in einem

Kalendermonat von seinen Teilnehmern in Verkehr gesetzten oder zum Eigengebrauch importierten Massen an gewerblichen Verpackungen je Tarifkategorie, gemäß § 29d Abs. 2

Abfallwirtschaftsgesetz 2002;

3. Meldung eines Sammel- und Verwertungssystems für gewerbliche Verpackungen über die Masse

der in einem Kalendermonat bei gewerblichen Anfallstellen abgeholten und beim System entpflichteten Verpackungen je Tarifkategorie, gemäß § 29d Abs. 3 Abfallwirtschaftsgesetz 2002;

4. Meldung eines Sammel- und Verwertungssystems für Haushaltsverpackungen über die von den

Teilnehmern in Österreich im vorangegangenen Kalenderjahr insgesamt in Verkehr gesetzten oder zum Eigengebrauch importierten Massen an Haushaltsverpackungen je Tarifkategorie

(Teilnahmemassen), gemäß § 9 Abs. 6 Z 3 Verpackungsverordnung 2014;

5. Meldung eines Sammel- und Verwertungssystems für Gewerbeverpackungen über die von den

Teilnehmern in Österreich im vorangegangenen Kalenderjahr insgesamt in Verkehr gesetzten

oder zum Eigengebrauch importierten Massen an gewerblichen Verpackungen je Tarifkategorie (Teilnahmemassen), gemäß § 13 Abs. 6 Z 4 Verpackungsverordnung 2014.

Darüber hinaus ermöglicht die Webservice-Schnittstelle das Abrufen von Marktanteilen, die gemäß § 29b Abs. 4 und § 29d Abs. 4 AWG 2002 vom Bundesminister für Land- und Forstwirtschaft, Umwelt und

Wasserwirtschaft berechnet und veröffentlicht wurden. Es können Monats-Marktanteile und Jahres-

Marktanteile abgerufen werden.

Dieses Dokument beschreibt die EDM eVerpackung Webservice Schnittstelle.

Das Dokument richtet sich in erster Linie an solche IT-Analytiker und Entwickler, die mit der Entwicklung der Anbindung von Software an die EDM eVerpackung Webservice Schnittstelle befasst sind.

Zusätzlich kann das Dokument auch von Umwelt- und Abfallwirtschaft Fachpersonal genutzt werden, um genauen Aufschluss über Art und Struktur der über die Schnittstelle übermittelbaren Daten zu

erlangen.

http://edm.gv.at/



1.2 Aufbau des Dokuments

Das Dokument ist wie folgt strukturiert:

Kapitel 1 enthält eine Einleitung, Hinweise zur Verwendung des Dokuments, eine Auflistung von

Literaturhinweisen sowie Kontaktinformationen.

Kapitel 2 enthält eine Beschreibung des XML-Formats für Verpackungs-bezogene Meldungen.

Kapitel 3 enthält illustrative XML-Beispieldaten mit Erläuterungen.

Kapitel 4 beschreibt das Webservice mit seinen Operationen.

Kapitel 5 enthält Vorgaben an Software, für die eine Anbindung an die EDM eVerpackung

Webservice-Schnittstelle implementiert wird

1.3 Verwendung des Dokuments

Diese Schnittstellenbeschreibung wird am EDM Anwendungsportal zusammen mit den folgenden Dateien

veröffentlicht, und ist für die Verwendung in Kombination mit diesen Dateien gedacht:

XML Schema Definition für Verpackungs-Meldungen (Datei mit „xsd“-Endung), zweifach,

einmal mit Beschreibungstexten, und einmal ohne.

Anmerkung: Nähere Informationen dazu, was eine XML Schema Definitions-Datei ist und wozu sie verwendet wird, ist in Abschnitt 2.1.4 auf Seite 7 beschrieben;

WSDL (Web Services Description Language) Beschreibung des Webservice (Datei mit

„wsdl“-Endung)

Datenanforderungen und Prüfregeln (PDF-Datei)

Anmerkung: Nähere Informationen dazu, was Datenanforderungen und Prüfregeln sind, und wozu sie dienen, ist in Abschnitt 2.1.5 auf Seite 8 beschrieben;

XML Beispieldateien (Dateien mit „xml“-Endung) illustrieren anhand von Beispieldaten die

Verwendung der XML-Datenformate

Anmerkung: Erläuterungen zu den XML-Beispielen sind in Abschnitt 3 auf Seite 26 angegeben.

1.4 Literaturhinweise

Zum Verständnis dieser Schnittstellenbeschreibung können die folgenden Dokumente hilfreich oder

erforderlich sein:

RECHTSGRUNDLAGEN:

[1] BGBl. I Nr. 102/2002, Abfallwirtschaftsgesetz 2002, idgF;

[2] Verpackungsverordnung 2014, idgF;

TECHNISCHE STANDARDS:

[1] Extensible Markup Language (XML) 1.1 (Second Edition), W3C Recommendation 16 August 2006, edited in place 29 September 2006;. http://www.w3.org;

[2] ISO/IEC 10646:2003, Information technology – Universal Multiple-Octet Coded Character Set (UCS);

[3] ISO/TS 15000-5:2005, Electronic Business Extensible Markup Language (ebXML) – Part 5: ebXML Core Components Technical Specification, Version 2.01 (ebCCTS);

[4] ONR 192150: 2007 11 01: Datenstrukturen für den elektronischen Datenaustausch in der Abfallwirtschaft; Österreichisches Normungsinstitut;

[5] XML Schema Part 1: Structures Second Edition, W3C Recommendation 28 October 2004; http://www.w3.org;

http://www.w3.org/

http://www.w3.org/



[6] XML Schema Part 2: Datatypes Second Edition, W3C Recommendation 28 October 2004; http://www.w3.org;

[7] UN/CEFACT Core Components Library (CCL) Version 07A; http://www.unece.org;

1.5 Kontakt

Weiterführende Fragen, die durch die vorliegende Schnittstellenbeschreibung bzw. die sonstigen

zugehörigen Dokumente nicht beantwortet werden, können an den EDM Helpdesk gerichtet werden:

(+43 1) 31 304 / 8000

An Werktagen von Montag bis Freitag von 7:00 bis 19:00 Uhr

[email protected].

1.6 Schnittstellen-Änderungsverzeichnis

Version Datum Änderungen

1.00 12.06.2014 Erstveröffentlichung

1.01 16.09.2014 Änderungen ausschließlich an den Datenanforderungen und Prüfregeln – siehe

Datenanforderungs- und Prüfregeldokument.

1.02 16.10.2014 Keine Änderungen an der Schnittstelle – es sind exakt dieselben Operationen, Inputs und Outputs gültig, die auch schon in Version 1.01 gültig waren.

Es wurde jedoch die Art und Weise der Deklaration des Inputs der

ShareDocument-Operation in der WSDL-Datei geändert, um dem Wunsch eines Teilnehmers der Benutzertests zu entsprechen.

1.03 12.11.2014 1. Geringfügige Änderung der Datenanforderungen und Prüfregeln – siehe Datenanforderungs- und Prüfregeldokument;

2. In der Schnittstellenbeschreibung wurde Abschnitt 5, in welchem

Vorgaben an Software und deren Benutzer spezifiziert sind, um die Vorgabe 745 zum Thema Login ergänzt. Siehe Seite 41.

XSD und WSDL sind gegenüber v1.02 unverändert.

1.04 29.05.2015 Das Webservice wurde um die Möglichkeit des Abrufens der veröffentlichten Marktanteile ergänzt (RetrieveDocument-Operation, siehe Seite 35).

Anmerkungen:

1. Die Marktanteils-Informationen werden in der

EnvironmentalDataEnvelope-XML-Struktur zurückgeliefert, die im Webservice bisher schon und auch weiterhin für die Übermittlung von

Verpackungs-Meldungen zum Einsatz kommt;

2. Welche Unterschiede sich in der Verwendung der EnvironmentalDataEnvelope-Struktur einerseits für Verpackungs-

Meldungen, und andererseits für Marktanteils-Informationen ergeben, ist im neuen Abschnitt 2.2.2 auf Seite 12 beschrieben;

3. Das Schnittstellen-Dateien-Paket wurde um Beispieldaten für

Marktanteilsinformationen ergänzt. Siehe Abschnitt 3 auf Seite 26.

1.05 04.08.2015 Das Webservice wurde um die Möglichkeit ergänzt, beim Abrufen der

veröffentlichten Marktanteile eine textliche Beschreibung der

Mitbenutzung von Sammel- und Verwertungssystemen mit abzurufen. Geringfügige Änderung der Datenanforderungen und Prüfregeln – siehe

Datenanforderungs- und Prüfregeldokument.

http://www.w3.org/

http://www.unece.org/

mailto:[email protected]



2 BESCHREIBUNG DES DATENFORMATS

2.1 Allgemeine Anmerkungen zum Datenformat

2.1.1 Zielsetzungen und Prinzipien der Datenmodellierung

Im Folgenden sind einige wichtige allgemeine Zielsetzungen und Prinzipien angeführt, die bei der

Spezifikation des Datenformats angewendet wurden. In den Folgeabschnitten wird dann näher auf einzelne technische Standards und Modellierungsprinzipien eingegangen.

Zukunftstauglichkeit – Flexibilität in Bezug auf allfällig im Laufe der Zeit erforderliche

Änderungen: Das XML-Datenformat ist so konzipiert, dass es möglichst langfristig verwendet werden kann. Das Grundprinzip dabei ist jenes, dass Datenformat-Vorgaben, von denen nicht

ausgeschlossen werden kann, dass sie sich im Laufe der Zeit ändern, als Codelisten abgebildet

sind. Anwendungen, die das Lesen oder Schreiben eines Datenformats unterstützen, können so implementiert werden, dass ein Aktualisieren von lokalen Codelisten-Kopien automatisiert ohne

die Notwendigkeit der Anpassung von Software (Um- oder Neuprogrammierungen) erfolgen kann.

Beispiel: Für die Angabe von Tarifkategorien kommen im Datenformat Codelisten zum Einsatz. Kommt es zukünftig zu Änderungen bei den Tarifkategorien, so gibt es lediglich eine

Aktualisierung der entsprechenden am EDM Anwendungsportal abrufbaren Codeliste. Die XML

Schema Definition hingegen bleibt gänzlich unverändert. Die Datenformat-Spezifikation ermöglicht es daher, Datenformat-lesende oder -schreibende Anwendungen so zu

implementieren, dass die Berücksichtigung von Änderungen bei Tarifkategorien keinen Entwicklungsaufwand und auch keinen sonstigen Administratoren-Aufwand erfordert, sondern die

Anwendungen einfach weiterverwendet werden können.

Bemerkung: Dem Datenformat wird durch die Verwendung von Codelisten eine Flexibilität in Bezug auf Anpassungen verliehen. Dies ist als Vorkehrung zu verstehen, und nicht als Absicht,

die Codelisten tatsächlich häufig zu ändern. Stattdessen werden Codelisten, wie im EDM üblich, auch hinkünftig nur dann geändert, wenn dies unbedingt notwendig ist, etwa aus rechtlichen

Gründen.

Zukunftstauglichkeit – Orientierung an Standards: Es werden Jahr für Jahr neue

Datenformate von unterschiedlichsten Einrichtungen veröffentlicht. Unter anderem wird auf EU-

Ebene an diversen standardisierten Datenformaten gearbeitet, z.B. im Rahmen der INSPIRE und

SEIS-Initiativen. Vor diesem Hintergrund erscheint auch die Wahrscheinlichkeit hoch, dass in absehbarer Zeit neue Datenformat-Spezifikationen, eventuell Standards, entstehen, welche

ähnliche Inhalte abdecken wie das hier vorgestellte Datenformat. Um sicherzustellen, dass das hier vorgestellte Format möglichst in Einklang mit künftigen Entwicklungen steht, dh. möglichst

widerspruchsfrei zu künftig entstehenden Datenformaten ist, ist die Spezifikation des Formats

sehr stark an bestehenden Standards orientiert. Eine vollständige Auflistung der berücksichtigten Vorgaben würde den Rahmen sprengen, daher an dieser Stelle eine beispielhafte Aufzählung:

1. World Wide Web Consortium Extensible Markup Language (XML) 2. World Wide Web Consortium XML Schema

3. UN/CEFACT Core Components Technical Specification 4. UN/CEFACT Core Component Library

5. Joint Committee for Guides in Metrology International vocabulary of metrology (VIM) (Anm.:

zum Joint Committee zählt auch die ISO) 6. International System of Units (SI)

7. EU-Directive Spatial Information Infrastructure INSPIRE (2007/2) 8. EU-Council Directive Units of Measurement (1980/181)

9. Unified Code for Units of Measure

10. ISO 19100 Series Geographic Information

Kriterium Technische Verarbeitbarkeit; Nicht-Kriterien inhaltliche Richtigkeit und

Vollständigkeit von Daten: Das XML-Datenformat ist so spezifiziert, dass eine grundlegende

technische Verarbeitbarkeit, insbesondere das Speichern in relationalen Datenbanken, von gemäß dem Datenformat repräsentierten Informationen, sichergestellt ist. Darüber hinausgehende



Anforderungen an die inhaltliche Richtigkeit und Vollständigkeit von Daten werden durch das XML-Datenformat nicht generell berücksichtigt. Das ist bewusst so gehalten, um möglichst keine

Barrieren für die Repräsentation von Daten, beispielsweise von bereits bestehenden

Datensammlungen, in dem Datenformat zu schaffen: Es handelt sich um eine Anforderung an das Datenformat, dass damit auch die Übermittlung von unvollständigen oder unplausiblen Daten

grundsätzlich möglich ist.

In der elektronischen Datenverarbeitung besteht jedoch auch der Anspruch des möglichst

automatisierten Erkennens von unplausiblen und unvollständigen Daten. Entsprechende

Prüfkriterien – (Nicht-)Einhaltung welcher Bedingungen welche Hinweise auf potentiell falsche oder fehlerhafte Daten liefern soll – müssen, so wie das Datenformat selbst, für alle am

Datenaustausch teilnehmenden Partner transparent und einheitlich sein. Eine Liste solcher Kriterien wird separat vom Datenformat in einem sogenannten Datenanforderungs- und

Prüfregeldokument veröffentlicht (siehe 2.1.5).

2.1.2 XML

XML-Dateien (Extended Markup Language Dateien) sind Text-Dateien, in welchen die Inhalte mit Namen

gekennzeichnet sind und eine hierarchische Struktur aufweisen.

XML-Dateien zeichnen sich insbesondere dadurch aus, dass sie sowohl menschenlesbar, als auch für die

maschinelle Verarbeitung geeignet sind.

XML [1] ist ein vom World Wide Web Consortium (http://www.w3.org) veröffentlichter Standard.

2.1.3 Zeichencodierung: UTF-8

XML Dateien können – so wie alle Text-Dateien – in verschiedenen Zeichencodierungen gespeichert sein, z.B. ISO 8859-1 oder UTF-8.

Unicode und UTF-8 [2] sind als ISO-Standard veröffentlicht. UTF-8 zählt zu den gebräuchlichsten Zeichencodierungen. Auf bereits bestehende Funktionen zur Speicherung von Text in UTF-8

Zeichencodierung kann in nahezu allen Programmiersprachen zurückgegriffen werden. Auch alle

gängigen textverarbeitenden Programme unterstützen diese Codierung.

Das in diesem Dokument beschriebene Webservice setzt eine Codierung von Request- und Response-

Daten in UTF-8 voraus – siehe die Vorgabe mit der ID 628 auf Seite 38.

2.1.4 XML Schema

Die hochzuladenden Dateien müssen gewisse Strukturvorgaben einhalten, um verarbeitet werden zu

können. Diese Strukturvorgaben betreffen insbesondere Anzahl, Anordnung und Kennzeichnung der zu übermittelnden Inhalte, und sind daher mit Formularvorlagen im papierbasierten Meldewesen

vergleichbar.

Für die Festlegung von Strukturvorgaben für XML Dateien existieren mehrere Standards. Der

verbreitetste davon ist XML Schema [5],[6], ein ebenfalls vom World Wide Web Consortium

(http://www.w3.org) veröffentlichter Standard.

Die Strukturvorgaben für XML-Dateien sind als XML Schema definiert. Diese XML Schema Dateien

besitzen die Dateiendung “.xsd” und stehen am EDM Anwendungsportal zum Download zur Verfügung.

Für Dokumentationszwecke steht weiters jeweils ein sogenanntes „annotated XML Schema“ (mit

Kommentaren versehenes XML Schema) zur Verfügung. Die Kommentare entsprechen genau den Beschreibungstexten aus dieser Schnittstellenbeschreibung.

Eine XML Datei heißt gültig bezüglich eines XML Schemas, wenn sie die im XML Schema definierten

Strukturvorgaben einhält. Es gibt Anwendungen und Funktionsbibliotheken, sogenannte XML Schema Validatoren, mit deren Hilfe es möglich ist, bei vorliegendem XML Schema und vorliegender XML Datei die

XML Datei zu validieren, dh deren Gültigkeit bezüglich des XML Schemas zu überprüfen. Mit solchen Validatoren lässt sich also schon vor einem Upload überprüfen, ob eine XML Datei den Strukturvorgaben

des XML Schemas entspricht.

XML-Dateien, die bezüglich der veröffentlichten XML Schema Dateien nicht gültig sind, werden beim Upload abgelehnt.

http://www.w3.org/

http://www.w3.org/



2.1.5 Datenanforderungen und Datenprüfungen

Diese Schnittstellenbeschreibung und die zugehörigen XML Schema Definitions-Datei (xsd-Datei)

beschreibt die Grundvoraussetzungen für die Interaktion zwischen einer Software-Anwendung und dem

EDM über das eVerpackung Webservice.

Über diese Grundvoraussetzungen hinaus gibt es weitergehende Anforderungen an Form und Inhalt

übermittelter Daten. Damit sind Anforderungen wie die folgende gemeint: „Beginn und Ende des angegebenen Zeitraums haben innerhalb desselben Kalenderjahres zu liegen“.

Solche sogenannten Datenanforderungen werden aus mehrerlei Gründen nicht innerhalb der

vorliegenden Schnittstellenbeschreibung dokumentiert, sondern in einem separaten Dokument: Zum Einen sind Datenmodell-und Schnittstellenbeschreibungs-Veröffentlichungen im Allgemeinen sehr schlecht

dafür geeignet, darin fachliche Anforderungen an Daten allgemeinverständlich und übersichtlich wiederzugeben. Zum Anderen müssen Schnittstellen möglichst stabil sein, dh. möglichst lange möglichst

unverändert bleiben, um hohen technischen Anpassungsaufwand zu vermeiden. Insbesondere muss

vermieden werden, dass die Notwendigkeit entsteht, Software neu zu kompilieren, auszuliefern bzw. zu installieren. Anpassungen bei Datenanforderungen sind hingegen wesentlich unproblematischer. Solche

Anpassungen behält sich das EDM vor. Wird beispielsweise von einer zuständigen Behörde festgestellt, dass ein bestimmter (formal erkennbarer) inhaltlicher Fehler in den Meldungen sehr häufig auftritt, so

kann als Service für Meldende und deren IT-Dienstleister eine neue Datenanforderung spezifiziert und veröffentlicht werden, die dabei unterstützt, diesen Fehler zu vermeiden.

Datenanforderungen sind von Datenprüfungen, die in IT-Anwendungen implementiert sind, zu

unterscheiden. Datenanforderungen gelten unabhängig davon, ob in IT-Anwendungen dazugehörige Datenprüfungen implementiert sind oder nicht.

Die Abarbeitung von Operationsaufrufen des EDM Webservice kann auf die folgenden Arten verlaufen:

1. Es tritt keine Ausnahmesituation auf – der Operationsaufruf kann regulär abgearbeitet werden,

es wird ein gewöhnlicher Response geliefert (kein SOAP-Fault);

2. Es tritt eine Ausnahmesituation („Exception“) auf – der Operationsaufruf kann nicht regulär abgearbeitet werden. Das wird dadurch signalisiert, dass anstelle des Response, wie ihn die

reguläre Abarbeitung eines Aufrufs liefert, ein SOAP-Fault zurückgemeldet wird.

In Zusammenhang mit Datenprüfungen ist weiter zu unterscheiden:

a. Die Ausnahmesituation tritt auf, weil Daten an das Webservice übergeben wurden, von welchen die Webservice-Operation feststellt, dass verpflichtend einzuhaltende

Datenanforderungen nicht eingehalten sind.

Erkennbar ist dieser Fall daran, dass im SOAP-Fault als Fehlerkategorie „Verletzung von Datenanforderungen“ (Code 203 aus Codeliste 5156) angegeben ist.

b. Die Ausnahmesituation tritt aus anderen Gründen auf, etwa weil die Authentifizierung fehlschlug, oder der authentifizierte EDM-Benutzer nicht über ausreichende

Berechtigungen verfügt, oder wegen Wartungsarbeiten am EDM.

Bei der Übermittlung von Daten (ShareDocument-Operation) erfolgt – sofern nicht aufgrund von Fehlern wie etwa Verletzung der XML Schema Vorgaben oder falsche Zeichencodierung die Abarbeitung

schon zuvor abgebrochen werden muss – automatisch eine Überprüfung der Einhaltung jener Datenanforderungen, für die es Datenprüfungen gibt. Es steht dann ein Validierungsergebnis

(auch „Prüfprotokoll“ genannt) zur Verfügung:

Im Fall 1 „reguläre Abarbeitung“:

o Zugriff auf das Validierungsergebnis besteht für all jene, die auch Zugriff auf die

übermittelten Dokumente besitzen, jedenfalls aber für Sender und Empfänger

(zuständige Behörde);

o Das Validierungsergebnis enthält lediglich Hinweise auf potentiell fehlerhafte

Daten. Eine Verletzung von verpflichtend einzuhaltenden Datenanforderungen wurde nicht festgestellt, andernfalls wäre die reguläre Abarbeitung der Webservice-Operation

abgebrochen worden;



Im Fall 2.a „Ausnahmesituation aufgrund der Verletzung verpflichtend einzuhaltender

Datenanforderungen“:

o Die Operation konnte nicht ordnungsgemäß abgearbeitet werden. An die Operation

übergebene Dokumente wurden vom Webservice nicht entgegengenommen. Es besteht

daher über das Webservice auch für niemanden Zugriff auf diese Dokumente;

o Ein Validierungsergebnis steht zur Verfügung, und zwar ausschließlich für jenen EDM-

Benutzer, der beim Aufruf der ShareDocument-Operation authentifiziert wurde;

o Das Validierungsergebnis – die Liste von Nicht-Einhaltungen von Datenanforderungen –

enthält mindestens einen Eintrag, der auf die Nicht-Einhaltung einer verpflichtend

einzuhaltenden Datenanforderung aufmerksam macht;

o Im Validierungsergebnis könnnen darüber hinaus auch Hinweise auf potentiell fehlerhafte

Daten enthalten sein, die für sich allein nicht zu einer Ausnahmesituation, d.h. dem Abbruch der Abarbeitung der Webservice-Operation geführt hätten;

Im Fall 2.b „Ausnahmesituation aus anderen Gründen“:

o Es gibt kein Ergebnis der Validierung von Datenanforderungen, da die Abarbeitung der Webservice-Operation aus nicht mit Datenanforderungen zusammenhängenden Gründen

abgebrochen wurde.

Es wird empfohlen, die Einhaltung von Datenanforderungen bereits Client-seitig zu überprüfen. Das ist vor allem eine Usability-Frage: Im vom EDM gelieferten Validierungsergebnis kann lediglich darauf Bezug

genommen werden, welche XML-Dateninhalte eine Prüfregelverletzung bewirken. Der Konnex zu Benutzeroberfläche-Elementen der Client-Software fehlt darin zwangsläufig. Durch die Client-seitige

Überprüfung kann ein solcher Konnex hergestellt werden.

2.1.6 Codelisten

Das Datenformat sieht unter anderem die Identifikation von Objekten vor, und zwar nach den folgenden

beiden Prinzipien:

1. Identifikation von Personen, Standorten, oder Anlagen, die im elektronischen Register für

Anlagen- und Personen-Stammdaten registriert sind. Zur Identifikation solcher Personen,

Standorte, oder Anlagen sind jeweils die GLNs (Global Location Numbers) zu verwenden, die im Zuge der Registrierung vergeben wurden. Eine Abfrage der registrierten Personen, Standorte und

Anlagen ist am EDM Anwendungsportal möglich;

2. Identifikation von Objekten aus vorgegebenen Listen. Ein Beispiel ist die Auswahl einer

Größeneinheit für einen Massenangabe, z.B. Kilogramm, aus einer vorgegebenen Liste von Größeneinheiten. Solche Listen, die die in einem bestimmten Kontext vorgegebene Auswahl von

Einträgen festlegen, werden Codelisten genannt. Für jeden Eintrag existiert ein Code, z.B. eine

GTIN (Global Trade Item Number), der diesen Eintrag identifiziert.

Die in einem bestimmten Kontext zulässigen Codes, z.B. die Codes, die zur Auswahl einer Größeneinheit

zulässig sind, sind bewusst nicht im XML Schema hinterlegt. Der wichtigste Grunde dafür: Codelisten können sich häufiger ändern, ohne dass sich an der Schnittstelle etwas ändert. Entsteht beispielsweise

aufgrund einer Unabhängigkeitserklärung ein neuer Staat, so muss die Liste der zur Auswahl stehenden

Nationalstaaten angepasst werden. An den Meldungsinhalten selbst hat sich nichts geändert. Wären die zulässigen Codes im XML Schema hinterlegt, so müsste bei jeder Aktualisierung von Codelisten auch das

XML Schema aktualisiert werden, wodurch es für gewöhnlich notwendig wäre, Software anzupassen.

Anstelle der Hinterlegung im XML Schema sind die Codelisten am EDM Anwendungsportal

(http://edm.gv.at) unter dem Menüpunkt „Zuordnungstabellen“ veröffentlicht. Zudem ist ein Webservice für den Bezug von Codelisten in Vorbereitung.

Die Verweise auf Codelisten sind direkt in den Datenelementbeschreibungen angegeben,

typischerweise durch den Zusatz „(Codeliste xxxx)“ zum Beschreibungstext, z.B. „Identifikation der Sprache, in der die Beschreibung angegeben ist (Codeliste 7632)“. Am EDM Anwendungsportal

http://edm.gv.at ist es möglich, die Auswahl genau jener Codelisten anzuzeigen, die im vorliegenden Datenformat verwendet werden. Dazu wird unter „Zuordnungstabellen“ unter dem Punkt „Gruppierung

nach Schnittstellen für den elektronischen Datenaustausch“ dem passenden Link gefolgt.

http://edm.gv.at/

http://edm.gv.at/



2.1.7 Identifikationszeichenketten und natürlichsprachige Angaben

Identifikationszeichenketten sind für die eindeutige Interpretierbarkeit, die Interoperabilität, sowie die

Möglichkeit der Automatisation von Abfragen und Auswertungen von Daten von großer Bedeutung.

Beispiele für Identifikationszeichenketten:

Identifikationszeichenketten, z.B. GTINs (Global Trade Item Numbers), die genutzt werden um

einen Bezug auf einen Codelisten-Eintrag herzustellen, z.B. um eine Verpackungs-Tarifkategorie

zu identifizieren;

Identifikationszeichenketten, z.B. Firmenbuchnummern oder GLNs (Global Location Numbers),

die genutzt werden, um Personen, Orte, Anlagen oder andere „Objekte“ zu identifizieren.

Die Bedeutung von Identifikationszeichenketten am Beispiel der Interoperabilität: Durch die Verwendung

einheitlicher Identifikationszeichenketten können dieselben Daten ohne „Übersetzungen“ in verschiedenen Sprachräumen (deutsch, französisch, englisch, usw.) interpretiert und verarbeitet werden.

Würden nur natürlichsprachige Bezeichnungen verwendet, so wären Datenübersetzungen erforderlich.

Identifikationszeichenketten ohne natürlichsprachige Elemente sind für sich alleine für Menschen zumeist

nicht interpretierbar, sondern erfordern ein „Nachschlagen“, z.B. die Suche einer Firmenbuchnummer im Firmenbuch oder die Suche einer Telefonnummer im Telefonbuch.

Die im vorliegenden Dokument beschriebenen Datenformate sind mit den folgenden Ansprüchen

konzipiert:

1. Die Daten müssen für die automatisierte Verarbeitung und Auswertung gut geeignet sein;

2. Daten sollen soweit vollständig angegeben werden können, dass sie von Menschen unmittelbar interpretierbar sind, dass also gewöhnliche Sprachkenntnisse und Allgemeinbildung genügen, um

die Daten interpretieren zu können, und dass kein „Nachschlagen“ in Codelisten oder Registern

erforderlich ist.

Eine „technischer“ formulierte Variante dieses Anspruchs: Gemäß XML-Datenformat sollen Daten

so angegeben werden können, dass einfache Transformationen (XSLT, XSL-FO) ohne „Lookups“ genügen, um aus diesen XML-Daten beispielsweise PDF-Dateien zu generieren, die mit

gewöhnlichen Sprachkenntnissen und Allgemeinbildung ohne weiteres „Nachschlagen“

unmittelbar interpretierbar sind.

Dem wird wie folgt Rechnung getragen:

1. Das Datenformat sieht für die meisten Angaben von Identifikationszeichenketten die zusätzliche Angabe natürlichsprachiger Identifikationselemente, z.B. Namen oder Beschreibungen vor.

Illustriert an dem XML-Beispiel (Zeile 82) aus Abschnitt 3 (S.26):

<TypeID collectionID="6893" objectDesignation="Papier">9008390101414</TypeID>

Im „objectDesignation“-Attribut befindet sich die natürlichsprachige Beschreibung – „Papier“ –

der GTIN 9008390101414 aus Codeliste 6893 (Tarifkategorien für Gewerbeverpackungen).

2. Maßgeblich für die Interpretation der Inhalte ist jedenfalls die Identifikationszeichenkette;

3. Dass Identifikationszeichenketten und natürlichsprachige Identifikationselemente zusammenpassen, liegt in der Verantwortung der für das Dokument verantwortlichen Person;

4. Passen Identifikationszeichenketten und natürlichsprachigen Identifikationselementen nicht zusammen, ist das ein schwerer inhaltlicher Mangel. Eine Zurückweisung des Dokuments kann

die Folge sein;

5. Überprüfungen, dass Identifikationszeichenketten und natürlichsprachige Identifikationselemente zusammenpassen, werden je nach Erfordernissen im EDM auch automatisationsgestützt

durchgeführt. Passen Identifikationszeichenketten und natürlichsprachige Identifikationselemente nicht zusammen, so kann das auch zur automatischen technischen Zurückweisung von

Dokumenten führen.



2.1.8 XML Schema Design Pattern: Venetian Blind

Es gibt verschiedene sogenannte Design Patterns für ein XML Schema. Die gängigsten davon sind unter

den Namen Russian Doll, Salami Slice, Venetian Blind und Garden of Eden bekannt.

Wie in Abschnitt 2.1.1 dargestellt, werden Schnittstellen-Spezifikationen für EDM aus einem syntaxunabhängigen Datenmodell abgeleitet. Das syntaxunabhängige Datenmodell enthält eine

Sammlung von semantischen Bausteinen (die Core Components und Business Information Entities). Um den modulartigen, kompakten und weitestgehend redundanzfreien Aufbau aus dem syntaxunabhängigen

Datenmodell in XML Schema Definitionen zu übernehmen, werden die Bausteine durchwegs als

sogenannte global types abgebildet. Das sind benannte und damit wiederverwendbare XML Schema Typdeklarationen. Dieser Ansatz ist genau der Venetian Blind XML Schema Design Pattern.

Ein Beispiel zur Illustration, was das in der Praxis bedeutet: Eine Adressstruktur braucht im XML Schema nur 1 Mal (als complex type) deklariert zu werden, auch dann, wenn die Adressstruktur an mehreren

Stellen in der hierarchischen Struktur verwendet wird (z.B. für eine Absender- und eine Empfänger-

Adresse).

Auch für die vorliegende Schnittstellenbeschreibung ergibt sich aus diesem Design Pattern ein sehr

konkreter Nutzen: Die Beschreibung kann modulartig erfolgen, dh es erfolgt eine Beschreibung der Komponenten (complex types) zusammen mit der Information, an welchen Stellen die Komponenten

verwendet werden. Auf diese Weise kann auch die Beschreibung von sehr umfassenden Schnittstellen kompakt und weitgehend redundanzfrei erfolgen.



2.2 Einleitung zur nachfolgenden Datenformat-Detailbeschreibung

2.2.1 Allgemeines

Nachfolgend wird das im Webservice verwendete XML-Datenformat durch Auflistung der Datenformat-

Strukturen beschrieben. Diese Beschreibung gibt Aufschluss darüber, welche Datenelemente gemäß XML Schema Definition im Datenformat vorgesehen sind, und welche Inhalte in den jeweiligen

Datenelementen erwartet werden (Semantik).

Die Veröffentlichungen zur Schnittstelle beinhalten zwei Varianten derselben XML Schema Definition (xsd-Datei): Eine mit Beschreibungen versehene Variante, in welcher die in den jeweiligen Datenelementen

erwarteten Inhalte direkt in der XML Schema Definition in sogenannten „Annotationen“ angegeben sind, und eine zweite Variante, in der keine solche Beschreibungen enthalten sind.

Die nachfolgende Datenformat-Strukturbeschreibung ist automatisiert aus der „annotierten“ Variante der XML Schema Definition erstellt. Sie enthält also insbesondere keine

zusätzlichen oder von der annotierten XML Schema Definition abweichenden Informationen.

Die Datenformat-Strukturbeschreibung ist so angelegt, dass sie die wesentlichen Vorgaben aus der Datenformat-Spezifikation gut lesbar wiedergibt. Unter anderem soll so auch Personen ohne XML Schema

Kenntnisse die Möglichkeit gegeben werden, die Datenformatvorgaben nachzuvollziehen, z.B. für eine fachliche oder juristische Evaluierung.

Ein wesentlicher Aspekt von XML ist die Möglichkeit der hierarchischen Strukturierung von Daten. Siehe

dazu die XML-Beispieldaten aus Abschnitt 3 (S.26). Strukturen (Listen von Datenelementen und/oder Substrukturen) können mehrfach als Substrukturen auftreten. Die Datenformat-Strukturbeschreibung

listet die Dokument-Struktur mit ihren Substrukturen und deren „Verschachtelung“ auf.

Das Datenformat definiert lediglich den „technischen Rahmen“, d.h. Voraussetzungen für die

technische Verarbeitbarkeit der Daten. Die technischen Rahmenbedingungen erfüllende Dateninstanzen sind nicht notwendigerweise in einem fachlichen Sinn gültig. Über diesen

grundlegenden technischen Rahmen hinausgehende Anforderungen an die Daten sind separat im

Datenanforderungs-Dokument veröffentlicht.

In der Datenformat-Strukturbeschreibung ist mit min..max die Wiederholbarkeit der Elemente in der

jeweiligen Struktur angegeben:

1..1 Das Element muss in Dateninstanzen innerhalb der Struktur genau ein Mal enthalten sein.

0..1 Das Element muss „0 bis 1“ Mal enthalten sein. Es handelt sich also um ein optionales Element.

Es dürfen nicht mehrere dieser Elemente in der Dateninstanz enthalten sein.

1..* Mindestens ein solches Element muss in Dateninstanzen enthalten sein.

Es können mehrere dieser Elemente in Dateninstanz enthalten sein.

0..* Es handelt sich um ein optionales Element.

Es können mehrere dieser Elemente in der Dateninstanz enthalten sein.

Auch diese Angaben zur Wiederholbarkeit definieren lediglich den technischen Rahmen: Aus der „0..1“ oder „0..*“ Wiederholbarkeit eines Elements ist ablesbar, dass es in der Menge aller technisch gültigen

Dateninstanzen einzelne Dateninstanzen geben kann, die dieses Element nicht enthalten. Es ist daraus hingegen nicht ablesbar, dass ein „Weglassen“ dieses Elements (ohne dem Zutreffen weiterer

Voraussetzungen) fachlich zulässig ist. Genauere Vorgaben dazu, unter welche Angaben unter welchen Umständen erforderlich sind, finden sich in den separat veröffentlichten Datenanforderungen.

2.2.2 Datenformat für Meldungen und Datenformat für Marktanteile

Für das Übermitteln von Meldungen wird dieselbe XML-Struktur verwendet (EnvironmentalDataEnvelope), die auch für das Abrufen von Marktanteilen verwendet wird.

In den zu EnvironmentalDataEnvelope im folgenden Abschnitt angegebenen Definitionen ist daher sowohl die Abbildung von Meldungsinhalten beschrieben, als auch die Abbildung von Marktanteilen in dieser

Struktur.



Im Folgenden wird darüber hinaus ein tabellarischer Überblick darüber gegeben, wodurch sich die Abbildung von Meldungsinhalten und die Abbildung von Marktanteilen unterscheiden:

Datenelement Meldung Marktanteils-Dokument

Document/TemporalExtent Enthält den Berichtszeitraum, auf den sich die Meldungsinhalte beziehen, z.B. Kalendermonat oder Kalenderjahr, in dem Verpackungen in Verkehr gesetzt wurden

Enthält den Kalendermonat oder das Kalenderjahr, in dem die Marktanteile “gelten”. Im Fall der Monats-Marktanteile ist das jener Monat, in welchem die sich aus Inverkehrsetzungs-Monatsmeldungen ergebenden Marktanteile für die Aufteilung der zu übernehmenden und

verwertenden Verpackungen auf Sammel- und Verwertungssysteme herangezogen werden

ListedData/Organization Enthält Angaben zum meldenden Sammel- und Verwertungssystem

Enthält Angaben zu allen Sammel- und Verwertungssystemen, auf die sich die Marktanteile beziehen

EnvironmentalDataDocument/ Document/TypeID

Enthält die Meldungsart (Bezug auf einen Eintrag aus Codeliste 2181), z.B. „Inverkehrsetzungs-Massen-Monatsmeldung Haushalt“

Enthält die Marktanteilsdokumentart (Bezug auf einen Eintrag aus Codeliste 4140), z.B. „Monatliche Marktanteile Haushaltsverpackungen“

EnvironmentalData/Event Da alle Massenangaben zum selben Sammel- und Verwertungssystem und zum selben Zeitraum gehören, ist nur maximal ein Event-Eintrag angegeben

Für jedes Sammel- und Verwertungssystem, zu dem das Dokument Marktanteilsinformationen enthält, gibt es einen eigenen Event-Eintrag

Event/ AssociatedObjectDocumentScope ReferenceID

Braucht nicht verwendet zu werden bzw. enthält alternativ einen Bezug auf das meldende Sammel- und Verwertungssystem (zu dem die Inverkehrsetzungs-Massen gehören)

Enthält einen Bezug auf jenes Sammel- und Verwertungssystem, zu dem die Marktanteils-Angaben gehören

Object/TypeID Enthält die Tarifkategorie (Bezug auf einen Eintrag aus Codeliste 2606 für Haushaltsverpackungen, bzw. auf einen Eintrag aus Codeliste 6893 für Gewerbeverpackungen)

Enthält die Sammelkategorie (Bezug auf einen Eintrag aus Codeliste 3918 für Haushaltsverpackungen, bzw. auf einen Eintrag aus Codeliste 8205 für Gewerbeverpackungen)

PropertyStatement/ PropertyKindID Enthält die Art der angegebenen Größe (Bezug auf einen Eintrag aus Codeliste 5618) – es handelt sich fix um „Masse“ (die Codeliste enthält nur diesen einen Eintrag)

Enthält die Art der angegebenen Größe (Bezug auf einen Eintrag aus Codeliste 8852) – es handelt sich fix um „Massenanteil“ (die Codeliste enthält nur diesen einen Eintrag)

ValueAssignmentStatement/ NumericValue

Enthält den numerischen Wert der Masse

Enthält den numerischen Wert des Marktanteils

ValueAssignmentStatement/ NumericValue/@unitID

Enthält die Größeneinheit (Bezug auf einen Eintrag aus Codeliste 5359) – es handelt sich fix um „Kilogramm“ (die Codeliste enthält nur diesen einen Eintrag)

Enthält die Größeneinheit (Bezug auf einen Eintrag aus Codeliste 8759) – es handelt sich fix um „Prozent“ (die Codeliste enthält nur diesen einen Eintrag)



2.3 Datenformat-Überblicksdiagramm

2.4 Datenformat-Strukturverzeichnis

EnvironmentalDataEnvelope .......................................................................................................15 Address ...................................................................................................................................15 AddressComponent ...................................................................................................................16 DocumentEvent ........................................................................................................................17 EnvelopeDocument ...................................................................................................................18 EnvironmentalData ....................................................................................................................18 EnvironmentalDataDocument .....................................................................................................19 Event ......................................................................................................................................19 EventObject .............................................................................................................................20 ListedData ...............................................................................................................................20 MultilingualDescription ..............................................................................................................20 Organization ............................................................................................................................21 Period .....................................................................................................................................21 PropertyStatement ....................................................................................................................22 SingleDocument ........................................................................................................................22 TemporalExtent ........................................................................................................................22 ValueAssignmentStatement ........................................................................................................23



2.5 Datenformat-Strukturbeschreibung

EnvironmentalDataEnvelope

Dokument oder Dokumente zu Verpackungen. Zusätzlich zu den eigentlichen Inhalten gibt es auch “Kopfdaten” (Metadaten), z.B. zur Erstellung des Dokuments.

Name/Typ min..max Definition

Document EnvelopeDocument (S.18)

1..1 “Kopfdaten” (Metadaten), z.B. zur Erstellung der Meldungen bzw. zur Erstellung der Marktanteils-Dokumente.

ListedData ListedData (S.20)

0..1 Aufzählung von “Objekten”, z.B. Personen, mit deren Angaben. Anmerkung 1: In Meldungen enthält diese Aufzählung ausschließlich Angaben zum meldenden Sammel- und Verwertungssystem für Verpackungen. Anmerkung 2: In Marktanteils-Dokumenten enthält diese Aufzählung Angaben zu den Sammel- und Verwertungssystemen für Verpackungen, auf die sich die Marktanteile beziehen, sowie allfällig zum Dokumentersteller (BMLFUW).

EnvironmentalDataDocument EnvironmentalDataDocument (S.19)

1..* Dokument oder Dokumente in Zusammenhang mit Verpackungen und deren Inverkehrsetzung, z.B. Meldungen zu Import, Abholung, Sammlung bzw. Verwertung oder Dokumente zu Marktanteilen von Sammel- und Verwertungssystemen.

Address

Angaben zu einer Adresse.


Component AddressComponent (S.16)

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

Address wird verwendet in: Organization (S.21)



AddressComponent

Angaben zu einer Adresskomponente, z.B. Straße oder Postleitzahl. Typischerweise wird zu einer Adresskomponente entweder eine Identifikation (z.B. Hausnummer), oder ein Auszeichnungstext (z.B. Straßenname) angegeben, nicht jedoch beides zugleich (also z.B. Straßenidentfikation und Straßenname zugleich).


TypeID ReferenceIdentifier (S.25)

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

ID ReferenceIdentifier (S.25)

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

RepresentationID PredeterminedScopeReferenceIdentifier (S.25)

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

RepresentationDesignation AddressComponentDesignation (S.23)

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

AddressComponent wird verwendet in: Address (S.15)



DocumentEvent

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



1..1 Art der dokumentbezogenen Tätigkeit, z.B. Dokumenterstellung (Codeliste 6468).

Date Date (S.23)

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

DocumentID PredeterminedScopeAssignmentIdentifier (S.25)

0..1 Dem Dokument zugewiesene ID, z.B. vom Dokumentersteller dem Dokument zugewiesene ID.

AssociatedObjectDocumentScopeReferenceID DocumentScopeOptionalRoleReferenceIdentifier (S.24)

0..* Mit der Tätigkeit in Verbindung stehende (nicht-natürliche) Personen, z.B. Dokumentersteller. Bezug auf eine dokumentintern unter “ListedData/Organization” angegebene nicht-natürliche Person. Die Referenzierung erfolgt durch Angabe der dokumentintern mittels “DocumentScopeAssignmentID” zugewiesenen Identifikationszeichenkette.

DocumentEvent wird verwendet in: EnvelopeDocument (S.18)



EnvelopeDocument

Allgemeine Angaben (“Kopfdaten”, “Metadaten”) zu einer Gruppe von Dokumenten. Zu solchen Metadaten zählen beispielsweise Informationen zum Dokumentersteller, zum Zeitpunkt der Dokumenterstellung sowie Angaben zum Zeitraum, auf den sich die Angaben beziehen.


ReferenceDataVersionDate Date (S.23)

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

Description MultilingualDescription (S.20)

0..1 Beschreibungstext zur Dateninstanz. Anmerkung 1: Dieses Datenelement ist bei der Meldungsübermittlung nicht zu verwenden - siehe Datenanforderung 5804. Anmerkung 2: In diesem Datenelement wird bei der Marktanteilsabfrage, sofern im Request angefordert, und sofern vorhanden, eine textliche Beschreibung der Mitbenutzung von Sammel- und Verwertungssystemen bereitgestellt.

TemporalExtent TemporalExtent (S.22)

1..1 Für Meldungen: Berichtszeitraum, auf den sich die Meldungsinhalte beziehen, z.B. Kalendermonat oder Kalenderjahr. Für Marktanteile: Zeitraum, d.h. Kalendermonat oder Kalenderjahr, in dem die Marktanteile “gelten”. Die Monats-Marktanteile “gelten” in jenem Monat, in welchem die sich aus Inverkehrsetzungs-Monatsmeldungen ergebenden Marktanteile für die Aufteilung der zu übernehmenden und verwertenden Verpackungen auf Sammel- und Verwertungssysteme herangezogen werden. Dabei handelt es sich um den auf den Inverkehrsetzungs-Berichtszeitraum zweitnachfolgenden Kalendermonat.

DocumentEvent DocumentEvent (S.17)

0..1 Angaben zu dokumentbezogenen Tätigkeiten, z.B. zur Dokumenterstellung.

EnvelopeDocument wird verwendet in: EnvironmentalDataEnvelope (S.15)

EnvironmentalData

Angaben zu Inverkehrsetzung, Import, Abholung, Sammlung bzw. Verwertung von Verpackungen, bzw. Angaben zum Marktanteil von Sammel- und Verwertungssystemen.


Event Event (S.19)

0..* Angaben zu einer Tätigkeit in Zusammenhang mit Verpackungen, z.B. Inverkehrsetzung und Import zum Eigengebrauch, oder Abholung von entpflichteten Verpackungen bei gewerblichen Anfallstellen. Anmerkung 1: Auf welche Art von Tätigkeit sich die Angaben beziehen, ist durch die Meldungsart vorgegeben. Anmerkung 2: Jeder Event-Eintrag bezieht sich auf genau ein Sammel- und Verwertungssystem. Darum enthalten Verpackungs-Meldungen höchstens einen Event-Eintrag (und sind andernfalls ungültig), Marktanteils-Dokumente enthalten im Allgemeinen jedoch mehrere Event-Einträge.

EnvironmentalData wird verwendet in: EnvironmentalDataDocument (S.19)



EnvironmentalDataDocument

Einzelnes Dokument zu Verpackungen. Zusätzlich zu den eigentlichen Inhalten gibt es auch “Kopfdaten” (Metadaten), z.B. zum Typ des Dokuments.


Document SingleDocument (S.22)

1..1 Allgemeine Angaben zum Dokument, z.B. Art des Dokuments.

EnvironmentalData EnvironmentalData (S.18)

1..1 Die Inhalte des Dokuments, d.h. Angaben zu Inverkehrsetzung, Import, Abholung, Sammlung bzw. Verwertung von Verpackungen, bzw. Angaben zum Marktanteil von Sammel- und Verwertungssystemen.

EnvironmentalDataDocument wird verwendet in: EnvironmentalDataEnvelope (S.15)

Event

Angaben zu einer Tätigkeit in Zusammenhang mit Verpackungen, z.B. Inverkehrsetzung und Import zum Eigengebrauch, oder Abholung von entpflichteten Verpackungen bei gewerblichen Anfallstellen.


Object EventObject (S.20)

1..* Angaben zu den mit der Tätigkeit in Zusammenhang stehenden Verpackungsmengen je Tarifkategorie, z.B. in Verkehr gesetzte Verpackungsmengen.

AssociatedObjectDocumentScopeReferenceID DocumentScopeRoleReferenceIdentifier (S.24)

0..1 Bezug auf das Sammel- und Verwertungssystem, zu dem die Angaben gehören (Rolle: Codeliste 1331, z.B. “Verantwortlicher Akteur”, z.B. der für die Inverkehrsetzungen verantwortliche Akteur). Anmerkung 1: Dieses Datenelement dient dazu, um in Marktanteils-Dokumenten den Bezug zwischen Marktanteilen und Sammel- und Verwertungssystemen herzustellen. Anmerkung 2: In Meldungen beziehen sich die Angaben immer auf das meldende Sammel- und Verwertungssystem (durch Teilnehmer des meldenden Sammel- und Verwertungssystems in Verkehr gesetzte, zum Eigengebrauch importierte bzw. abgeholte Verpackungen). In Meldungen kann daher der Bezug auf das Sammel- und Verwertungssystems an dieser Stelle entfallen. Sofern jedoch ein Bezug angegeben ist, muss es sich in Meldungen um den Bezug auf das meldende Sammel- und Verwertungssystem handeln.

Event wird verwendet in: EnvironmentalData (S.18)



EventObject

Angaben zu einer Menge von Verpackungen einer Tarifkategorie bzw. einer Sammelkategorie.



1..1 Tarifkategorie bzw. Sammelkategorie, zu der die Verpackungen zählen. Anmerkung 1: Für Verpackungsmeldungen ist, je nach Meldungstyp, ein Bezug auf eine Haushaltsverpackungs-Tarifkategorie (Codeliste 2606) oder eine Gewerbeverpackungs-Tarifkategorie (Codeliste 6893) angegeben. Anmerkung 2: Für ein Marktanteils-Dokument ist, je nach Dokumentart, ein Bezug auf eine Haushaltsverpackungs-Sammelkategorie (Codeliste 3918) oder eine Gewerbeverpackungs-Sammelkategorie (Codeliste 8205) angegeben.

PropertyStatement PropertyStatement (S.22)

1..1 Für Meldungen: Masse der zur angegebenen Tarifkategorie gehörenden Verpackungen. Für Marktanteils-Dokumente: Marktanteil des Sammel- und Verwertungssystem in Bezug auf die zur angebenen Sammelkategorie gehörenden Verpackungen. Anmerkung: Für Meldungen handelt es sich abhängig vom Kontext (Meldungsart) um die Masse von in Verkehr gesetzten oder zum Eigengebrauch importierten Verpackungen der jeweiligen Tarifkategorie, oder um die Masse von bei gewerblichen Anfallstellen abgeholten entpflichteten Verpackungen der jeweiligen Tarifkategorie.

EventObject wird verwendet in: Event (S.19)

ListedData

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


Organization Organization (S.21)

0..* Liste von “nicht-natürlichen Personen”. Anmerkung 1: An anderen Stellen im Dokument erfolgt die Angabe nicht-natürlicher Personen durch Bezugnahme auf Einträge aus “Organization”. Anmerkung 2: In Meldungen enthält diese Aufzählung ausschließlich Angaben zum meldenden Sammel- und Verwertungssystem für Verpackungen. Anmerkung 3: In Marktanteils-Dokumenten enthält diese Aufzählung Angaben zu den Sammel- und Verwertungssystemen für Verpackungen, auf die sich die Marktanteile beziehen, sowie allfällig zum Dokumentersteller (BMLFUW).

ListedData wird verwendet in: EnvironmentalDataEnvelope (S.15)

MultilingualDescription

Beschreibungstext, der in einer von mehreren verschiedenen Sprachen angegeben sein kann.


IndividualDescription Description (S.23)

1..1 Beschreibungstext, der in einer von mehreren Sprachen angegeben sein kann. Anmerkung: Im vorliegenden Datenformat werden ausschließlich deutschsprachige Beschreibungstexte verwendet.

MultilingualDescription wird verwendet in: EnvelopeDocument (S.18)



Organization

Angaben zur nicht-natürlichen Person, z.B. zu einem Sammel- und Verwertungssystem.


DocumentScopeAssignmentID DocumentScopeAssignmentIdentifier (S.24)

1..1 Im Dokumentkontext verwendeter Identifikator für die nicht-natürliche Person.

ID AssignmentIdentifier (S.23)

1..1 Allgemeine Identifikatoren des Unternehmens bzw. der nicht-natürlichen Person, jeweils zusammen mit der Identifikation der Sammlung von Identifikatoren (Auswahl eines Eintrags aus Codeliste 1756). Anmerkung: In den Verpackungsmeldungen wird als Identifikator ausschließlich jene GLN (Global Location Number) erwartet, die dem Sammel- und Verwertungssystem im EDM (Elektronisches Datenmanagement in der Umwelt- und Abfallwirtschaft, vom Lebensministerium betriebenes Register) zugeordnet ist.

Name LongNameText (S.24)

1..1 Name des Unternehmens bzw. der nicht-natürlichen Person.

Address Address (S.15)

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

Organization wird verwendet in: ListedData (S.20)

Period

Angaben zu einem Zeitraum.


StartDate Date (S.23)

1..1 Beginndatum (erster Tag des Zeitraums).

EndDate Date (S.23)

1..1 Enddatum (letzter Tag des Zeitraums).

Period wird verwendet in: TemporalExtent (S.22)



PropertyStatement

Aussage über eine Größe. Beispiel: “Hat eine Masse von 2000kg”.


PropertyKindID ReferenceIdentifier (S.25)

1..1 Identifikation der Größenart. Anmerkung 1: In Meldungen als Bezug auf einen Eintrag aus Codeliste 5618 angegeben, namentlich GTIN 9008390104439 für die Größe “Masse”. Anmerkung 2: In Marktanteils-Dokumenten als Bezug auf einen Eintrag aus Codeliste 8852 angegeben, namentlich GTIN 9008390104446 für die Größe “Massenanteil”.

ValueAssignmentStatement ValueAssignmentStatement (S.23)

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

PropertyStatement wird verwendet in: EventObject (S.20)

SingleDocument

Allgemeine Angaben (“Kopfdaten”, “Metadaten”) zu einem einzelnen Dokument, z.B. die Art des Dokuments.



1..1 Die Art des Dokuments. Anmerkung: Für Meldungen als Bezug auf einen Eintrag aus Codeliste 2181 angegeben, z.B. mittels GTIN 9008390106914 für “Inverkehrsetzungs-Massen-Monatsmeldung Haushalt”. Für Marktanteils-Dokumente hingegen als Bezug auf einen Eintrag aus Codeliste 4140 angegeben, z.B. mittels GTIN 9008390109465 für “Monatliche Marktanteile Haushaltsverpackungen”.

SingleDocument wird verwendet in: EnvironmentalDataDocument (S.19)

TemporalExtent

Angaben zu einem Zeitraum.


Period Period (S.21)

1..1 Zusammenhängender Zeitraum, charakterisiert durch Beginn- und Enddatum.

TemporalExtent wird verwendet in: EnvelopeDocument (S.18)



ValueAssignmentStatement

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


NumericValue NumericValue (S.25)

1..1 Als Zahl angegebener Wert in Kombination mit einer Größeneinheit. Anmerkung 1: In Meldungen handelt es sich um die Angabe einer Masse, z.B. “200kg” (“200 Kilogramm”). Anmerkung 2: In Marktanteils-Dokumenten handelt es sich um die Angabe eines Massenanteils, z.B. “45.95%” (“45.95 Prozent”). Anmerkung 3: Die Marktanteile werden mit einer vorgegebenen Genauigkeit (Anzahl von Stellen) berechnet, und werden in allen Veröffentlichungsformaten (z.B. Veröffentlichung am EDM-Portal, Abruf über das eVerpackung-Webservice) mit derselben Genauigkeit wiedergegeben. Seit dem Gültigkeitsdatum Mai 2015 werden die Marktanteile auf die Genauigkeit von zwei Prozent-Nachkommastellen berechnet und gerundet, und zwar so, dass die Summe jedenfalls exakt 100% ergibt (z.B. 66.67%, 33,33%). Anmerkung 4: Gemäß dem XML Schema Datentyp für Dezimalzahlen (“xs:decimal”) wird in der XML-Dateninstanz der Punkt als Dezimaltrennzeichen verwendet, und nicht - wie in Österreich und Deutschland üblich - das Komma.

ValueAssignmentStatement wird verwendet in: PropertyStatement (S.22)

Datentypen

Name Definition

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

AddressComponentDesignation wird verwendet in: AddressComponent (S.16)

Name Definition

AssignmentIdentifier Einem Objekt zugeordnete Identifikationszeichenkette. Z.B. eine zu einer nicht-natürlichen Person angegebene GLN (Global Location Number).

1..1 collectionID Identifikation der Sammlung, aus der die angegebene Identifikationszeichenkette stammt (Codeliste 1756). Beispiel: Angabe der GTIN (Global Trade Item Number) 9008390104026 als Bezugnahme auf das EDM, wenn als AssignmentIdentifier eine bei der Registrierung im EDM zugeordnete GLN (Global Location Number) angegeben wird.

AssignmentIdentifier wird verwendet in: Organization (S.21)

Name Definition

Date Datum, d.h. Identifikation eines Tages.

Date wird verwendet in: DocumentEvent (S.17), EnvelopeDocument (S.18), Period (S.21)

Name Definition

Description Beschreibungstext.

1..1 languageID Identifikation der Sprache, in der die Beschreibung angegeben ist (Codeliste 7632).

Description wird verwendet in: MultilingualDescription (S.20)



Name Definition

DocumentScopeAssignmentIdentifier Zu einem im Dokument aufgezählten Objekt, z.B. einer nicht-natürlichen Person, für die Bezugnahme auf dieses Objekt innerhalb des Dokuments zugeordnete Identifikationszeichenkette. Anmerkung: Für Identifikationszeichenketten (IDs) dieses Typs kann die Eindeutigkeit nur im Dokumentkontext vorausgesetzt werden, eine darüber hinausgehende Eindeutigkeit gibt es nicht notwendigerweise. Im Detail bedeutet das: Beim automatisierten ERSTELLEN des Dokuments durch eine Software sind IDs zu verwenden, die ZUMINDEST innerhalb des Dokuments eindeutig sind. Es genügt also beispielsweise das Durchnummerieren der im Dokument vorkommenden Objekte mit Ganzzahlen {1, 2, ..., n}. Sofern vorhanden eignet sich aber auch die Verwendung von IDs, die über den Dokumentkontext hinaus eindeutig sind, da diese ebenfalls der Voraussetzung genügen, innerhalb des Dokuments eindeutig zu sein. Beispielsweise können für Firmen deren Firmenbuchnummern als für dokumentinterne Bezugnahmen genutzte IDs verwendet werden. Beim EINLESEN und VERARBEITEN eines Dokuments darf jedoch ausschließlich die dokumentinterne Eindeutigkeit der IDs vorausgesetzt werden. Eine über den Dokumentkontext hinausgehende Verwendbarkeit der IDs darf nicht angenommen werden!

DocumentScopeAssignmentIdentifier wird verwendet in: Organization (S.21)

Name Definition

DocumentScopeOptionalRoleReferenceIdentifier Bezugnahme auf ein Objekt, z.B. eine nicht-natürliche Person, mittels der in der Aufzählung des Objekts zugeordneten Identifikationszeichenkette. Zusätzlich kann die Rolle des Objekts, auf das Bezug genommen wird, angegeben werden.

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

0..1 roleDesignation Bezeichnung der Rolle des Objekts, auf das Bezug genommen wird. Beispiel: Als Rolle einer nicht-natürlichen Person im Kontext einer Tätigkeit kann “Verantwortlicher Akteur” angegeben werden.

DocumentScopeOptionalRoleReferenceIdentifier wird verwendet in: DocumentEvent (S.17)

Name Definition

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

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

0..1 roleDesignation Bezeichnung der Rolle des Objekts, auf das Bezug genommen wird. Beispiel: Als Rolle einer nicht-natürlichen Person im Kontext einer Tätigkeit kann “Verantwortlicher Akteur” angegeben werden.

DocumentScopeRoleReferenceIdentifier wird verwendet in: Event (S.19)

Name Definition

LongNameText Name.

LongNameText wird verwendet in: Organization (S.21)



Name Definition

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

1..1 unitID Bezug auf die für die Größenangabe verwendete Größeneinheit. Anmerkung 1: In Meldungen als Bezug auf einen Eintrag aus Codeliste 5359 angegeben, namentlich Code “kg” für “Kilogramm”. Anmerkung 2: In Marktanteils-Dokumenten als Bezug auf einen Eintrag aus Codeliste 8759 angegeben, namentlich Code “%” für “Prozent”.

NumericValue wird verwendet in: ValueAssignmentStatement (S.23)

Name Definition

PredeterminedScopeAssignmentIdentifier Einem Objekt zugeordnete Identifikationszeichenkette (ID). Anmerkung: Der Kontext, aus dem die Identifikationszeichenkette stammt, wird nicht angegeben, sondern ist an jenen Stellen, an denen dieser Datentyp verwendet wird, explizit vorgegeben. Beispiel: Von einem Dokumentersteller dem Dokument zugeordnete ID.

PredeterminedScopeAssignmentIdentifier wird verwendet in: DocumentEvent (S.17)

Name Definition

PredeterminedScopeReferenceIdentifier Bezugnahme auf ein Objekt durch Angabe einer dem Objekt zugeordneten Identifikationszeichenkette (ID). Anmerkung: Der Kontext, aus dem die ID stammt, wird nicht angegeben, sondern ist an jenen Stellen, an denen dieser Datentyp verwendet wird, explizit vorgegeben. Beispiel: Bezugnahme auf eine Website durch Angabe der Website-Adresse (URL).

PredeterminedScopeReferenceIdentifier wird verwendet in: AddressComponent (S.16)

Name Definition

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

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

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

ReferenceIdentifier wird verwendet in: AddressComponent (S.16), DocumentEvent (S.17), EventObject (S.20), PropertyStatement (S.22), SingleDocument (S.22)



2.6 Zuordnung von Fachbegriffen zu Datenelementen

Abholung

Im Datenformat: Event (S.19) in EnvironmentalData (S.18) Anmerkung: Auf welche Art von Tätigkeit – z.B. Inverkehrsetzung oder Abholung – sich die Angaben im Event-Element beziehen, ist durch die →Meldungsart vorgegeben

Einheit

Im Datenformat: Siehe →Größeneinheit Größeneinheit

Im Datenformat: unitID-Attribut des NumericValue-Elements vom Typ NumericValue (S.25) in ValueAssignmentStatement (S.23)

Inverkehrsetzung

Im Datenformat: Event (S.19) in EnvironmentalData (S.18) Anmerkung: Auf welche Art von Tätigkeit – z.B. Inverkehrsetzung oder Abholung – sich die Angaben im Event-Element beziehen, ist durch die →Meldungsart vorgegeben

Marktanteil

Im Datenformat: NumericValue in ValueAssignmentStatement (S.23) Meldungsart

Im Datenformat: TypeID in SingleDocument (S.22) Mitbenutzung

Im Datenformat: Description in EnvelopeDocument (S.18) Sammel- und Verwertungssystem

Im Datenformat: Organization (S.21) in ListedData (S.20) (grundlegende Angaben zum Sammel- und Verwertungssystem). Bezugnahmen auf Sammel- und Verwertungssysteme können in AssociatedObjectDocumentScopeReferenceID angegeben sein, und zwar in DocumentEvent (S.17) sowie in Event (S.19)

Sammelkategorie

Im Datenformat: TypeID in EventObject (S.20) Tarifkategorie

Im Datenformat: TypeID in EventObject (S.20) Verpackungsmenge (Menge von Verpackungen einer Tarifkategorie)

Im Datenformat: Object vom Typ EventObject (S.20) in Event (S.19)

3 XML BEISPIELDATEN

3.1 Allgemeines

Die Schnittstellenspezifikation wird mit zwei XML-Beispieldateien ausgeliefert:

1. packaging.xml Illustriert die Abbildung von Verpackungs-Inverkehrsetzungs-

Meldungsinhalten im XML-Format.

2. marketshare.xml Illustriert, wie Marktanteils-Informationen im XML-Format wiedergegeben

werden.

Die packaging.xml Beispieldaten sind im nachfolgenden Abschnitt 3.2 unverändert wiedergegeben.

Der darauffolgende Abschnitt 3.3 enthält Erläuterungen zu den packaging.xml Beispieldaten.

Die marketshare.xml Beispieldaten entsprechen demselben EnvironmentalDataEnvelope-Format, dem

auch die packaging.xml Beispieldaten entsprechen. Die Prinzipien der Abbildung von Meldungsinhalten

im XML-Format sind den Prinzipien der Abbildung von Marktanteilsinformationen im XML-Format sehr

ähnlich – die wenigen Unterschiede sind in Abschnitt 2.2.2 auf Seite 12 zusammengefasst.

Um die Webservice-Beschreibung übersichtlich und kompakt zu halten, werden nachfolgend

ausschließlich die packaging.xml Beispieldaten wiedergegeben und erläutert, nicht aber die

marketshare.xml Beispieldaten. Um nachzuvollziehen, wie Marktanteils-Informationen im XML-Format



wiedergegeben werden, empfiehlt es sich daher, die marketshare.xml Datei zu öffnen und

durchzulesen.

3.2 XML Beispieldaten

001 <?xml version="1.0" encoding="UTF-8"?> 002 <pk:EnvironmentalDataEnvelope xsi:schemaLocation="http://www.umweltbundesamt.at/schema/EnvironmentalData

Packaging.xsd" xmlns:pk="http://www.umweltbundesamt.at/schema/EnvironmentalData" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

003 <Document> 004 <ReferenceDataVersionDate>2013-12-20</ReferenceDataVersionDate> 005 <TemporalExtent> 006 <Period> 007 <StartDate>2014-01-01</StartDate> 008 <EndDate>2014-01-31</EndDate> 009 </Period> 010 </TemporalExtent> 011 <DocumentEvent> 012 <TypeID collectionID="6468" objectDesignation="Dokumenterstellung">9008390106594</TypeID> 013 <Date>2014-02-07</Date> 014 <DocumentID>IVS201401a</DocumentID> 015 <AssociatedObjectDocumentScopeReferenceID roleID="9008390104583" roleDesignation="Verantwortlicher

Akteur">ORH</AssociatedObjectDocumentScopeReferenceID> 016 </DocumentEvent> 017 </Document> 018 <ListedData> 019 <Organization> 020 <DocumentScopeAssignmentID>ORH</DocumentScopeAssignmentID> 021 <ID collectionID="9008390104026">9008390918302</ID> 022 <Name>Recycling Högmoos</Name> 023 <Address> 024 <Component> 025 <TypeID collectionID="6856" objectDesignation="Straße">9008390103968</TypeID> 026 <RepresentationDesignation>Rudolf-Simmon-Straße</RepresentationDesignation> 027 </Component> 028 <Component> 029 <TypeID collectionID="6856" objectDesignation="Hausnummer">9008390103975</TypeID> 030 <RepresentationID>23</RepresentationID> 031 </Component> 032 <Component> 033 <TypeID collectionID="6856" objectDesignation="Postleitzahl">9008390103944</TypeID> 034 <RepresentationID>5660</RepresentationID> 035 </Component> 036 <Component> 037 <TypeID collectionID="6856" objectDesignation="Ort">9008390103951</TypeID> 038 <RepresentationDesignation>Taxenbach</RepresentationDesignation> 039 </Component> 040 <Component> 041 <TypeID collectionID="6856" objectDesignation="Land">9008390104682</TypeID> 042 <ID collectionID="3862">040</ID> 043 <RepresentationDesignation>Österreich</RepresentationDesignation> 044 </Component> 045 </Address> 046 </Organization> 047 </ListedData> 048 <EnvironmentalDataDocument> 049 <Document> 050 <TypeID collectionID="2181" objectDesignation="Inverkehrsetzungs-Massen-Monatsmeldung

Gewerbe">9008390106921</TypeID> 051 </Document> 052 <EnvironmentalData> 053 <Event> 054 <Object> 055 <TypeID collectionID="6893" objectDesignation="Papier">9008390101414</TypeID> 056 <PropertyStatement> 057 <PropertyKindID collectionID="5618" objectDesignation="Masse">9008390104439</PropertyKindID> 058 <ValueAssignmentStatement> 059 <NumericValue unitID="kg">4100</NumericValue> 060 </ValueAssignmentStatement> 061 </PropertyStatement> 062 </Object> 063 <Object>



064 <TypeID collectionID="6893" objectDesignation="Glas">9008390101421</TypeID> 065 <PropertyStatement> 066 <PropertyKindID collectionID="5618" objectDesignation="Masse">9008390104439</PropertyKindID> 067 <ValueAssignmentStatement> 068 <NumericValue unitID="kg">8300</NumericValue> 069 </ValueAssignmentStatement> 070 </PropertyStatement> 071 </Object> 072 </Event> 073 </EnvironmentalData> 074 </EnvironmentalDataDocument> 075 <EnvironmentalDataDocument> 076 <Document> 077 <TypeID collectionID="2181" objectDesignation="Abholungs-Massen-Monatsmeldung

Gewerbe">9008390106938</TypeID> 078 </Document> 079 <EnvironmentalData> 080 <Event> 081 <Object> 082 <TypeID collectionID="6893" objectDesignation="Papier">9008390101414</TypeID> 083 <PropertyStatement> 084 <PropertyKindID collectionID="5618" objectDesignation="Masse">9008390104439</PropertyKindID> 085 <ValueAssignmentStatement> 086 <NumericValue unitID="kg">2700</NumericValue> 087 </ValueAssignmentStatement> 088 </PropertyStatement> 089 </Object> 090 <Object> 091 <TypeID collectionID="6893" objectDesignation="Glas">9008390101421</TypeID> 092 <PropertyStatement> 093 <PropertyKindID collectionID="5618" objectDesignation="Masse">9008390104439</PropertyKindID> 094 <ValueAssignmentStatement> 095 <NumericValue unitID="kg">800</NumericValue> 096 </ValueAssignmentStatement> 097 </PropertyStatement> 098 </Object> 099 </Event> 100 </EnvironmentalData> 101 </EnvironmentalDataDocument> 102 </pk:EnvironmentalDataEnvelope>

3.3 Erläuterungen

Für Bezüge auf Codelisten-Einträge wird generell im Attribut „collectionID“ die 4-stellige Nummer

der Codeliste angegeben, und im Element-Content die jeweilige ID des Eintrags, z.B. in Zeile 91

die GTIN 9008390101421 für die Tarifkategorie „Glas“, und in Zeile 42 der ISO-Code 040 für Österreich;

Die XML-Daten beginnen mit den Kopfdaten zur gesamten Meldung im Element „Document“ in

Zeile 3. Im Sub-Element „TemporalExtent“ in Zeile 5 ist der Berichtszeitraum angegeben. Beim

Beispiel handelt es sich um eine Monatsmeldung, die sich auf den Monat Jänner 2014 bezieht;

Eine gesamte Monatsmeldung oder Jahresmeldung kann eine oder mehrere einzelne

Monatsmeldungen oder Jahresmeldungen enthalten. Im Beispiel sind zwei einzelne

Monatsmeldungen enthalten, jeweils beginnend mit dem Element „EnvironmentalDataDocument“, und zwar in den Zeilen 48 und 75;

Die Kopfdaten zu den einzelnen Meldungen befinden sich – analog zu den Kopfdaten der

gesamten Meldung – in „Document“-Unterelementen (Zeilen 49 und 76). Darin ist im Element

„TypeID“ jeweils der Meldungstyp angegeben, und zwar durch Bezug auf einen Eintrag aus Codeliste 2181. Im Beispiel sind zwei Monatsmeldungen enthalten – die sich beide auf Jänner

2014 beziehen – und zwar eine Inverkehrsetzungs-Monatsmeldung für gewerbliche Verpackungen und eine Abholungsmassen-Monatsmeldung;



Die Verpackungsmassen je Tarifkategorie sind in den wiederholbaren „Object“-Elementen

angegeben, und zwar im Beispiel in den Zeilen 54, 63, 81 und 90. Aus dem Beispiel ist auch ersichtlich, dass nur jene Tarifkategorien aufgelistet werden, für die tatsächlich

Inverkehrsetzungen, Eigenimporte bzw. Abholungen stattgefunden haben. Ein Anführen von

Tarifkategorien mit einer Massenangabe von „0“ sollte hingegen vermieden werden;

Mit dem „Object“-Subelement „TypeID“ wird ein Bezug auf eine Tarifkategorie angegeben. Je

nach Art der Meldung wird ein Bezug auf eine Haushaltsverpackungs- oder Gewerbeverpackungs-

Tarifkategorie angegeben. Für Haushaltsverpackungs-Tarifkategorien erfolgt der Bezug auf einen Eintrag der Codeliste 2606, für Gewerbeverpackungs-Tarifkategorien erfolgt der Bezug auf einen

Eintrag der Codeliste 6893. Da im Beispiel beide enthaltenen Monatsmeldungen sich auf

gewerbliche Verpackungen beziehende Meldungen sind, sind alle im Beispiel enthaltenen Bezüge auf Tarifkategorien Bezüge auf Einträge der Codeliste 6893;

Mit den „PropertyKindID“-Elementen wird die Art der angegebenen Größe deklariert. Da in den

Verpackungsmeldungen ausschließlich die Angabe der Masse von Verpackungen je Tarifkategorie gefordert ist, sind die „PropertyKindID“-Elemente in Verpackungsmeldungen immer gleich – sie

enthalten immer einen Bezug auf die Größe „Masse“ mittels der GTIN 9008390104439 aus Codeliste 5618;

Die Masse selbst (von Verpackungen je Tarifkategorie) wird in den „NumericValue“-Elementen

angegeben. Im Attribut „unitID“ wird die Größeneinheit angegeben, durch einen Bezug auf einen

Eintrag aus Codeliste 5359. In Verpackungsmeldungen ist ausschließlich die Größeneinheit Kilogramm mit dem standardisierten Code „kg“ zulässig. Der Zahlenwert der Masse wird als

Inhalt der „NumericValue“-Elemente angegeben – siehe Zeilen 59, 68, 86 und 95;

Zu den Kopfdaten der gesamten Meldung zählen auch Angaben zur Erstellung der Meldung im

Element „DocumentEvent“ in Zeile 11. Wichtig ist hier die Angabe des Dokumenterstellers, der

als „verantwortlicher Akteur“ der Dokumenterstellung in Zeile 15 eingetragen ist. Als

Dokumentersteller ist jedenfalls das Sammel- und Verwertungssystem anzugeben, auf dessen Tätigkeiten sich die Meldungen bzw. Berichte beziehen. Allfällige Beauftragungen oder

Bevollmächtigungen zur Erstellung der Meldung sollen in dieser Angabe zur Dokumenterstellung unberücksichtigt bleiben. Gemäß Datenanforderungen kann eine Meldung nur dann technisch

akzeptiert werden, wenn die für den Aufruf der Webservice-Operationen übermittelten Authentifizierungsdaten zu einem im EDM registrierten Benutzer zu gehören, der im EDM als zu

jenem Sammel- und Verwertungssystem gehörig registriert ist, das in der Meldung als

Meldungsersteller bzw. meldendes Sammel- und Verwertungssystem angegeben ist;

Einige grundlegende Angaben zum meldenden Sammel- und Verwertungssystem, die für ein

einzelnes System über verschiedene Meldungen hinweg im Allgemeinen immer gleich bleiben,

werden unter „ListedData“ im Element „Organization“ erwartet. Zu diesen grundlegenden Daten gehören die GLN (Global Location Number), die zum Sammel- und Verwertungssystem im EDM

eingetragen ist, der Name, und die Sitzadresse. Im Beispiel finden sich diese Angaben in Zeile 19

und den darauffolgenden Zeilen.



4 WEBSERVICE BESCHREIBUNG

4.1 Operationen

4.1.1 RequestTransactionID

Fordert eine ID (Identifikationszeichenkette) vom EDM eVerpackung Webservice an. Eine solche

„Transaction ID“ wird für den Aufruf bestimmter anderer Webservice-Operationen benötigt, insbesondere für die ShareDocument-Operation, und kann für genau einen solchen nachfolgenden Aufruf verwendet

werden.

Die „Transaction ID“-Systematik dient vor allem Folgendem:

1. „Idempotenz“: Fälle, in welchen idente Webservice-Aufrufe mehrfach eintreffen, etwa aufgrund

von technischen Problemen im Netzwerk, werden erkannt, und so verarbeitet, als wäre der Aufruf nur einmal eingetroffen. Damit wird beispielsweise verhindert, dass ausgelöst durch

technische Probleme unbeabsichtigt Mehrfachmeldungen entstehen;

2. Zuverlässigkeit: Wenn ein Webservice-Client keine Antwort auf einen Request erhält, z.B. in einer

„Timeout“-Situation, kann mittels der „Transaction ID“ dennoch eindeutig festgestellt werden, ob der Request verarbeitet wurde oder nicht.

Input:

Zur RequestTransactionID-Operation gibt es keinen Input.

Output:

Name Type Definition

TransactionID 1 .. 1 StrictAssignmentIdentifier

Die ID (Identifikationszeichenkette), die vom EDM für

einen nachfolgenden Aufruf einer Webservice-

Operationen reserviert wurde.

IssueDateTime 1 .. 1 xsd:dateTime

Der Zeitpunkt der Ausstellung der ID durch das EDM. Anmerkung: Der Zeitpunkt der Ausstellung wird

deswegen vom EDM geliefert, weil dies für die

Nachvollziehbarkeit der erfolgten Interaktionen zwischen den Softwareinstanzen, z.B. im Zuge von

Fehlerbehebungsmaßnahmen, von Nutzen sein kann.

4.1.2 ShareDocument

Mit dieser Operation werden Dokumente (Meldungen) „geteilt“. Dokumentinhalte werden in das EDM

übernommen, und stehen dort für den Empfänger zur Einsicht und zum Abruf zur Verfügung.

Über das eVerpackung Webservice ist das Übermitteln von Verpackungs-bezogenen Meldungen

ausschließlich an die zuständigen Behörden möglich. Aus diesem Grund ist keine explizite Angabe von Empfängern in der Operation vorgesehen.

Für den Aufruf der Operation wird eine zuvor mit der Operation „RequestTransactionID“ angeforderte

„Transaction ID“ benötigt. Die beim Aufruf verwendete „Transaction ID“ kann in Folge verwendet werden, um den Übermittlungsstatus abzufragen („QueryTransactionStatus“) bzw. Validierungsergebnisse

abzufragen („QueryDocumentValidationResult“).

Die „ShareDocument“-Operation funktioniert im folgenden Sinn synchron: Wenn die „ShareDocument“-

Operation eine reguläre Antwort (Response) liefert, d.h. keinen SOAP-Fault, dann bedeutet das, dass die

Dokumente bzw. Meldungen erfolgreich zur technischen Validierung entgegengenommen werden



konnten, und dass die technische Validierung zu keiner automatischen Zurückweisung der übermittelten Dokumente bzw. Meldungen führte. Bei einer regulären Antwort der Operation kann die technische

Validierung jedoch sehr wohl Hinweise auf potentiell fehlerhafte Daten ergeben haben.

Bei einer automatischen technischen Ablehnung haben Empfänger (zuständige Behörden) weder Zugriff auf die Meldungsinhalte, noch erlangen sie Kenntnis über die versuchte Meldungsübermittlung. Ergab die

technische Validierung lediglich Hinweise auf potentiell fehlerhafte Daten, jedoch keine automatische Ablehnung, so haben Empfänger vollen Zugriff auf die übermittelten Dokumente bzw. Meldungen,

inklusive der Hinweise aus der technischen Validierung.

Die „ShareDocument“-Operation funktioniert im folgenden Sinn atomar: Der Empfänger, d.h. die zuständige Behörde, erhält entweder alle enthaltenen Einzelmeldungen oder keine. Eine teilweise

Zustellung von Meldungen gibt es nicht: Werden an die „ShareDocument“-Operation mehrere Einzelmeldungen übergeben, und ist mindestens eine der Einzelmeldungen dergestalt, dass eine

automatische technische Zurückweisung ausgelöst wird, dann wird keine der übergebenen Einzelmeldungen zugestellt. D.h. selbst solche Einzelmeldungen, die für sich allein keine technische

Zurückweisung auslösen würden, werden in diesem Fall nicht zugestellt.

Input:


TransactionID 1 .. 1 StrictReferenceIdentifier

Eine zuvor mit der “RequestTransactionID”

angeforderte und noch nicht “verbrauchte” “Transaction ID”.

EnvironmentalDataEnvelope

1 .. 1 EnvironmentalDataEnvelope

Eine Verpackungs-Monatsmeldung oder Jahresmeldung, die mit der “ShareDocument”-

Operation an die zuständige Behörde übermittelt wird.

Anmerkung 1: Die Monatsmeldung oder Jahresmeldung kann aus mehreren einzelnen Monatsmeldungen oder

Jahresmeldungen bestehen. Eine Monatsmeldung kann beispielsweise eine Meldung zu Inverkehrsetzung von

gewerblichen Verpackungen und eine weitere Meldung

zur Abholung von Verpackungen von gewerblichen Anfallstellen beinhalten.

Anmerkung 2: Das Meldungs-Datenformat ist in Abschnitt 2 (S.6ff) im Detail beschrieben.

Output:


ConstraintViolationIndicato

r

0 .. 1 Indicator

Ein ja/nein-Wert dazu, ob bei der technischen

Validierung die Verletzung von Datenanforderungen festgestellt wurde. Mit diesem Wert wird lediglich die

Verletzung solcher Datenanforderungen angezeigt, die nicht zu einer automatischen Zurückweisung führen.

Anmerkung 1: Im ShareDocument-Output ist – im

Gegensatz zum QueryTransactionStatus-Output – kein “TechnicalAcceptanceIndicator” enthalten. Das liegt

daran, dass in der “ShareDocument”-Operation eine automatische Zurückweisung jedenfalls per SOAP-Fault

rückgemeldet wird. Bei erhalt eines regulären ShareDocument-Response liegt also jedenfalls keine

technische Zurückweisung vor.



Anmerkung 2: Ein ConstraintViolationIndicator=true ist

so zu verstehen, dass die an die “ShareDocument”-Operation übergebenen Meldungen erfolgreich für den

Empfänger, d.h. die zuständige Behörde, technisch entgegengenommen werden konnten, dass es zugleich

jedoch auch Hinweise auf potentiell unrichtige bzw. fehlerhafte Inhalte der übermittelten Meldungen gibt.

4.1.3 QueryTransactionStatus

Mit dieser Operation wird der Status einer zuvor mittels „ShareDocument“ gestarteten

Meldungsübermittlung abgefragt.

Als Aufrufer muss derselbe EDM-Benutzer authentifiziert werden, der auch beim Aufruf der „ShareDocument“ Operation authentifiziert wurde.

Diese Operation kann beispielsweise dann verwendet werden, wenn bei der „ShareDocument“-Operation ein „Timeout“ auftritt. Damit lässt sich dann feststellen, ob die aufgerufene Operation trotz Timeout

ausgeführt wurde.

Wurde vom Webservice keine Transaktion mit der als Input an die QueryTransactionStatus-Operation

angegebenen Transaktions-ID verzeichnet (das Webservice hat kein Aufruf der ShareDocument-

Operation mit der angegebenen ID verzeichnet), dann wird der QueryTransactionStatus-Aufruf mit einem SOAP-Fault quitiert.

Input:


TransactionID 1 .. 1 StrictReferenceIdentifier

Eine zuvor mit “RequestTransactionID” angeforderte und anschließend in einem “ShareDocument”-Aufruf

verwendete “Transaction ID”.

Output:


ProcessingCompletionIndic

ator

1 .. 1 Indicator

Ein ja/nein-Wert dazu, ob die technische Validierung

der übermittelten Meldungen bereits abgeschlossen ist. Anmerkung: Da die “ShareDocument”-Operation

synchron arbeitet, ist das Validieren der übermittelten

Meldungen bei Erhalt des “ShareDocument”-Response jedenfalls abgeschlossen.

TechnicalAcceptanceIndicator

0 .. 1 Indicator

Ein ja/nein-Wert dazu, ob die übermittelten Meldungen technisch akzeptiert werden konnten. “False” zeigt eine

automatische technische Zurückweisung an. Bei einer

technischen Zurückweisung haben Empfänger weder Zugriff auf die an die ShareDocument-Operation

übergebenen Meldungen, noch haben sie Kenntnis über den Zustellversuch.

Anmerkung: Der “TechnicalAcceptanceIndicator” ist nur dann gesetzt, wenn die technische Validierung

abgeschlossen ist, d.h. wenn der im

“ProcessingCompletionIndicator” der Wert “true” zurückgeliefert wird.



ConstraintViolationIndicato

r

0 .. 1 Indicator

Ein ja/nein-Wert dazu, ob bei der technischen

Validierung die Verletzung von Datenanforderungen festgestellt wurde. Mit diesem Wert wird lediglich die

Verletzung solcher Datenanforderungen angezeigt, die nicht zu einer automatischen Zurückweisung führen.

Anmerkung 1: Der “ConstraintViolationIndicator” ist nur dann gesetzt, wenn im “TechnicalAcceptanceIndicator”

der Wert “true” zurückgeliefert wird.

Anmerkung 2: Ein von der QueryTransactionStatus-Operation zurückgeliefertes Ergebnis mit den Werten

ProcessingCompletionIndicator=true, TechnicalAcceptanceIndicator=true und

ConstraintViolationIndicator=true ist so zu verstehen,

dass die an die “ShareDocument”-Operation übergebenen Meldungen erfolgreich für den

Empfänger, d.h. die zuständige Behörde, technisch entgegengenommen werden konnten, dass es zugleich

jedoch auch Hinweise auf potentiell unrichtige bzw. fehlerhafte Inhalte der übermittelten Meldungen gibt.

4.1.4 QueryDocumentValidationResult

Operation für die Abfrage des Ergebnisses der technischen Validierung der an einen zuvor erfolgten

„ShareDocument“-Aufruf übergebenen Meldungsinhalte.

Als Aufrufer muss ein EDM-Benutzer authentifiziert werden, der gemäß EDM Stammdaten zum Sender (zur selben Person, zu der auch jener EDM-Benutzer gehört, der beim Aufruf der „ShareDocument“-

Operation authentifiziert wurde) oder Empfänger (zuständige Behörde) des Dokuments gehört.

Die „QueryDocumentValidationResult“-Operation ist insbesondere für die folgenden Verwendungsarten

ausgelegt:

1. Der Webservice-Client erfährt von der technischen Zurückweisung der beim „ShareDocument“-

Aufruf übergebenen Meldungsinhalte. Mit dem „QueryDocumentValidationResult“-Aufruf werden

anschließend die konkreten Gründe, d.h. die konkreten Vorgabenverletzungen abgefragt.

Anmerkung 1: Auch bei einer technischen Zurückweisung kann das Validierungsergebnis Einträge

zu solchen Vorgabenverletzungen enthalten, die nicht zu einer automatischen Zurückweisung führen, sondern lediglich ein Hinweis auf potentiell fehlerhafte Daten sind. Bei einer technischen

Zurückweisung enthält das Validierungsergebnis aber mindestens einen Eintrag, der eine

automatische Zurückweisung ausgelöst hat.

Anmerkung 2: Die „ShareDocument“-Operation kann aus unterschiedlichen Gründen

fehlschlagen. Eine Klassifikation des Grunds wird in der SOAP-Fault Nachricht mittels Bezug auf einen Eintrag aus Codeliste 5156 mitgeliefert. Tritt beim ShareDocument-Aufruf ein SOAP-Fault

auf, dann ist ein Validierungsergebnis ausschließlich dann verfügbar, wenn als Fehlerklassifikation „Verletzung von Datenanforderungen“ (Code 203) zurückgeliefert wird. In anderen Fällen, z.B.

wenn die Operation aufgrund fehlgeschlagener Authentifizierung oder unzureichender

Berechtigungen nicht ordnungsgemäß ausgeführt werden konnte, steht kein Validierungsergebnis zum Abruf zur Verfügung. In diesem Fall führt ein Aufruf der QueryDocumentValidationResult-

Operation selbst wieder zu einer Ausnahmefall-Beendigung, d.h. einem SOAP Fault.

2. Der Webservice-Client erfährt von der erfolgreichen technischen Validierung der beim

„ShareDocument“-Aufruf übergebenen Meldungsinhalte (kein Fault bei ShareDocument, bzw.

QueryTransactionStatus liefert als „TechnicalAcceptanceIndicator“ den Wert „true“). Der Client erfährt jedoch auch über das Vorliegen von Datenanforderungs-Verletzungen

(„ConstraintViolationIndicator“ ist auf „true“ gesetzt), was als Hinweis darauf, dass die Meldungsinhalte möglicherweise inkorrekt oder unbplausibel sind, zu werten ist. Mit dem

„QueryDocumentValidationResult“-Aufruf werden anschließend die konkreten Datenanforderungs-

Verletzungen abgefragt.



Input:


DocumentID 1 .. 1 StrictReferenceIdentifier

Eine zuvor mit “RequestTransactionID” angeforderte

und anschließend in einem “ShareDocument”-Aufruf verwendete “Transaction ID”.

Output:


ValidationResultItem 0 .. * ValidationResultItem

Informationen zu einzelnen Verletzungen von Vorgaben

durch die an die “ShareDocument”-Operation übergebenen Meldungsinhalte.

ValidationResultItem


SevereViolationIndicator 1 .. 1 Indicator

Ja/Nein-Angabe dazu, ob die Vorgabenverletzung schwerwiegend in dem Sinn ist, dass sie zu einer

automatischen technischen Zurückweisung der Inhalte

führt. Anmerkung: Bei einer automatischen technischen

Zurückweisung werden die an die ShareDocument-Operation übergebenen Inhalte vom EDM nicht

verarbeitet, und stehen somit auch nicht den Empfängern, d.h. den zuständigen Behörden, zur

Verfügung. UserDataDependencyIndicator

1 .. 1 Indicator

Ja/Nein-Angabe dazu, ob die Vorgabenverletzung potentiell in direktem Zusammenhang mit von

Benutzern kommenden Inhalten und Angaben, d.h. den Meldungsinhalten selbst, stehen kann.

ViolatedConstraintID 1 .. 1 StrictReferenceIdentifier

ID der verletzten Datenanforderung.

ResultText 0 .. 1 Description

Beschreibung der Vorgabenverletzung.

ObjectID 0 .. 1 OptionalTypeReferenceIdentifier

Mit dieser ID kann auf ein “Objekt” innerhalb der an

die “ShareDocument”-Operation übergebenen Meldungen verwiesen werden, welches in ursächlichem

Zusammenhang mit der Vorgabenverletzung steht. Theoretisches Beispiel: Bei Angaben zu einer Person

wird der Vorname benötigt, fehlt jedoch in den an die



“ShareDocument”-Operation übergebenen Daten. Als

“ObjectID” in “ValidationResultItem” wird diejenige ID zurückgeliefert, die in den an die “ShareDocument”-

Operation übergebenen Daten der Person zugewiesen ist.

4.1.5 RetrieveDocument

Operation für die Abfrage der für einen konkreten Monat bzw. für ein konkretes Jahr gültigen Marktanteile, die gemäß § 29b Abs. 4 und § 29d Abs. 4 AWG 2002 vom Bundesminister für Land- und

Forstwirtschaft, Umwelt und Wasserwirtschaft berechnet und veröffentlicht wurden.

Anmerkungen:

1. Mit dem Zeitraum, in dem die Marktanteile „gelten“, ist für Monats-Marktanteile jener Zeitraum

gemeint, in welchem die sich aus Inverkehrsetzungs-Monatsmeldungen ergebenden Marktanteile für die Aufteilung der zu übernehmenden und verwertenden Verpackungen auf Sammel- und

Verwertungssysteme herangezogen werden. Dabei handelt es sich um den auf den Inverkehrsetzungs-Berichtszeitraum zweitnachfolgenden Kalendermonat;

2. Wird die RetrieveDocument-Operation für einen Kalendermonat aufgerufen, für den keine bzw. noch keine Marktanteile veröffentlicht wurden, führt dies zu einer Ausnahmesituation (Exception,

d.h. SOAP Fault, Fehlerkategorie 202 „Unzulässige Request-Daten“ aus Codeliste 5156). Analog

gilt das für die Abfrage von noch nicht veröffentlichten Jahres-Marktanteilen;

3. Gegenwärtig sieht EDM eVerpackung eine automatische Berechnung und anschließende

Veröffentlichung von Monats-Marktanteilen am 28. jedes Kalendermonats um 23:59 Uhr vor. Zum Beispiel werden die für den Mai geltenden Marktanteile, die aus den Inverkehrsetzungs-

Meldungen vom März berechnet werden, am 28. April um 23:59 berechnet und anschließend

veröffentlicht. Eine automatisierte Abfrage der Monats-Marktanteile sollte frühestens an dem auf den 28. folgenden Tag (29. desselben Monats oder, sofern es sich um

einen Monat mit nur 28 Tagen handelt, 1. des Folgemonats) um 0:10 erfolgen;

4. Im EDM eVerpackung Webservice werden Beschränkungen für die maximale Anzahl von

Zugriffen pro Benutzer und Zeiteinheit (für diverse Zeiteinheiten wie z.B. Stunde, Tag, Monat) festgelegt und nach Bedarf (d.h. wenn zu häufige Zugriffe Probleme verursachen) angepasst

bzw. ergänzt. Ein korrekter RetrieveDocument-Aufruf kann daher auch aufgrund zu häufigen

Zugriffs fehlschlagen.

Input:


YearNumeric 1 .. 1 IntegerYear

Kalenderjahr des Gültigkeitszeitraums, für den die

Marktanteile abgerufen werden, z.B. 2015.

MonthNumeric 0 .. 1 IntegerMonth

Monat des Gültigkeitszeitraums, für den die

Marktanteile abgerufen werden, z.B. 1 für “Jänner” oder 12 für “Dezember”.

Um Jahresmarktanteile abzurufen, wird die Monats-

Angabe weggelassen.

RequestJointUseDescriptio

nIndicator

0 .. 1 Indicator

Ja/Nein-Wert, der angibt, ob zu den Marktanteilen auch

die textliche Beschreibung der allfälligen Mitbenutzung von Systemen durch andere Sammel- und

Verwertungssysteme mit abgerufen werden soll. Siehe

dazu auch das Description-Element in EnvelopeDocument (S.18)

Anmerkung: Nur bei Angabe eines “true”-Wertes wird



die textliche Beschreibung abgerufen, nicht aber bei

Angabe eines “false”-Wertes oder bei Weglassen der RequestJointUseDescriptionIndicator-Angabe.

Output:


EnvironmentalDataEnvelop

e

1 .. 1 EnvironmentalDataEnvelope

Marktanteilsdokument für den angefragten

Gültigkeitszeitraum. Die EnvironmentalDataEnvelope-Struktur ist in

Abschnitt 2 (S.6ff.) beschrieben.

4.2 Fehlerbehandlung

Bei Webservice-Aufrufen können Situationen eintreten, die eine gewöhnliche Abarbeitung des Aufrufs verhindern (Ausnahmesituation – „Exception“). Ein Beispiel für eine solche Ausnahmesituation ist das

Fehlen von Berechtigungen für den lesenden oder schreibenden Datenzugriff. Für solche Ausnahmesituationen wird die sogenannte „SOAP Fault“-Systematik verwendet. Das heißt: Anstelle eines

gewöhnlichen Response liefert das Webservice einen speziellen Fault-Response. Im EDM eVerpackung

Webservice ist die Struktur für die Inhalte eines solchen Fault-Response für alle Webservice-Operationen die gleiche. Diese Struktur wird im Folgenden beschrieben.


FailureID 0 .. 1 StrictReferenceIdentifier

Eine ID (Identifikationszeichenkette), die auf einen

Eintrag aus Codeliste 5156 “Fehlerkategorien” verweist und solcherart den Fehler klassifiziert.

Anmerkung: Die Fehlerkategorie kann bei der Fehlersuche durch IT-Personal hilfreich sein. Für den

Endanwender ist die Fehlerkategorie im Allgemeinen

unverständlich.

FailureText 0 .. 1 Description

Eine Beschreibung des Fehlers.

Anmerkung: Die Beschreibung des Fehlers kann bei der Fehlersuche durch IT-Personal hilfreich sein. Für den

Endanwender ist die Fehlerbeschreibung im

Allgemeinen unverständlich.

ObjectID 0 .. 1 ReferenceIdentifier

Ein Verweis auf ein “Objekt” innerhalb der

übermittelten Request-Daten, zu dem die Angaben als ursächlich für das Auftreten des Fehlers zu sehen sind.

Anmerkung: Der Verweis auf ein “Objekt” innerhalb der

übermittelten Request-Daten kann bei der Fehlersuche durch IT-Personal hilfreich sein. Für Endanwender ist

ein solcher Verweis im Allgemeinen unverständlich.

Für die Verarbeitung solcher SOAP-Faults gilt es zu berücksichtigen, dass das Auftreten eines solchen

Fehlers in vielen Fällen weder vom Endanwender verursacht ist, noch von diesem behebbar ist. Die bei

einem SOAP-Fault zurückgelieferten Inhalte sind somit auch nicht dafür gedacht, von der Client-Software dem Anwender „ungefiltert“ mitgeteilt zu werden, sondern dienen in erster Linie dazu, IT-Personal die

Möglichkeit zu geben die Ursachen für den Fehler zu identifizieren und wenn notwendig zu beheben. Für



den Anwender genügt bei den meisten Fehlerkategorien ein Hinweis, dass ein technischer Fehler vorliegt, und dass bei wiederholtem Auftreten des Fehlers Support durch IT-Personal eingeholt werden soll.

4.3 Authentifizierung

Beim eVerpackung Webservice handelt es sich um ein durch HTTP Basic Authentication abgesichertes Service. Bei jedem Service Aufruf muss daher ein HTTP Authorization Header mit einer Base64 codierten

username:password Kombination eines EDM-Benutzers (Haupt- oder Neben-Benutzer) mitgeschickt

werden.

Für einen User „max“ mit Passwort „test“ würde zum Beispiel der Base64 codierte String „max:test“ wie

folgt lauten: „dXNlcjp0ZXN0==“. Der HTTP Request Header für Basic Authentication müsste demnach

folgenden Eintrag enthalten:

Authorization: Basic dXNlcjp0ZXN0==

Schlägt die Authentifizierung fehl wird ein SOAP Fault retourniert. Siehe auch Abschnitt 4.1.5.

HTTP Basic Authentication wird von zahlreichen Entwicklungsumgebungen unterstützt. Die Spezifikation

kann unter http://www.ietf.org/rfc/rfc2617.txt abgerufen werden.

4.4 Wenn unrichtige Meldungsinhalte übermittelt wurden

Die durch ein Sammel- und Verwertungssystem an eine Behörde übermittelten Meldungsinhalte können

sich im Nachhinein als unrichtig herausstellen.

Das Webservice sieht keine Operationen vor, die eigens auf das Zurückrufen von Meldungen ausgelegt

sind. Vielmehr ist die vorgesehene Vorgangsweise grundsätzlich die, für den selben Meldungszeitraum

(Kalendermonat oder Kalenderjahr) neuerlich eine Meldung zu übermitteln. Durch eine solche neuerliche Übermittlung einer Meldung für denselben Berichtszeitraum werden zuvor übermittelte Meldungen für

diesen Berichtszeitraum als zurückgerufen und für ungültig erklärt aufgefasst. Für Empfänger (zuständige Behörden) bleibt technisch der Zugriff auf solche zurückgerufenen und für ungültig erklärten Meldungen

bestehen.

Für das neuerliche automatisierte Übermitteln von Meldungen für einen Berichtszeitraum, für den bereits Meldungen übermittelt wurden, behält sich das EDM sowohl Einschränkungen, als auch das Abändern

solcher Einschränkungen vor. Typische Beispiele für solche Einschränkungen sind die Folgenden:

1. Einschränkung auf zeitliche Nähe der Meldungsübermittlung zum Berichtszeitraum;

2. Einschränkung auf eine maximal mögliche Anzahl von Meldungs-Widerrufungen und Neueinbringungen.

Aufgrund solcher Einschränkungen kann das neuerliche Übermitteln einer Meldung für denselben

Berichtszeitraum zunächst zu einer automatischen Zurückweisung führen. Ist dies der Fall, so ist durch den Meldenden Kontakt mit der zuständigen Behörde aufzunehmen, um die Freischaltung für die

neuerliche Übermittlung der Meldung anzufordern.

5 VORGABEN AN SOFTWARE MIT SCHNITTSTELLENANBINDUNG UND AN DEREN

BENUTZER

5.1 Allgemeines

Zur Schnittstellenspezifikation zählen auch die im Folgenden aufgelisteten Vorgaben an Software, für die eine Schnittstellenanbindung umgesetzt wird, sowie Vorgaben an Benutzer dieser Software. Die

Zielsetzungen hinter diesen Vorgaben sind unter anderem ein friktionsfreies, sicheres und für Anwender

gut benutzbares Zusammenspiel von Software-Produkten mit dem EDM.

http://www.ietf.org/rfc/rfc2617.txt



5.2 Vorgaben, die ausschließlich die Software betreffen

5.2.1 Erstellung und Verarbeitung von Dateninstanzen

Vorgabe 1 (ID 341): Generierte Dateninstanzen MÜSSEN bezüglich der am EDM Anwendungsportal

veröffentlichten XML Schema Definition gültig sein.

Anmerkung: Es darf insbesondere nicht möglich sein, dass Nutzer der Software durch ihre Interaktion mit der Software (z.B. Eingabe unsinniger Daten oder Weglassen erforderlicher Daten) das Generieren

ungültiger Dateninstanzen auslösen können.

Beispiel: Eine Software bietet in der Benutzeroberfläche ein Formular zur Erfassung von in Verkehr gesetzten Verpackungsmengen je Tarifkategorie, sowie die Möglichkeit des Erstellens bzw. Übermittelns

einer XML-Dateninstanz zu in Verkehr gesetzten Verpackungsmengen je Tarifkategorie. Ein Software-Benutzer hat zu einer Verpackungsmenge eine Tarifkategorie ausgewählt, aber noch keine Masse

angegeben, und wählt nun die Funktion „XML-Export/Übermittlung“. Gemäß XML-Datenformat ist die Angabe der Masse von Verpackungen verpflichtend. Würde die Software eine XML-Dateninstanz erstellen,

in der die Angabe der Masse zu einer Verpackungsmenge fehlt, so handelte es sich um eine ungültige

Dateninstanz, und die Software wäre mangelhaft. Vielmehr ist es Aufgabe der Software, den Benutzer darauf aufmerksam zu machen, dass die vorliegenden Angaben unzureichend sind um eine gültige Dateninstanz zu erzeugen. ■

Vorgabe 2 (ID 628): Bei der Zeichencodierung generierter Dateninstanzen MUSS es sich um UTF-8

handeln. ■

Vorgabe 3 (ID 705): Generierte Dateninstanzen MÜSSEN allen der folgenden am EDM

Anwendungsportal veröffentlichten Datenanforderungen entsprechen:

1. Datenanforderungen die als verpflichtend gekennzeichnet sind. Das sind insbesondere solche Datenanforderungen, zu der die Beschreibung enthalten ist, dass eine Verletzung zur

Zurückweisung der Dateninstanz führt;

2. Datenanforderungen welche die Kennzeichnung enthalten, sich in erster Linie auf die korrekte XML-Repräsentation von Daten zu beziehen. ■

Vorgabe 4 (ID 394): Software SOLL so implementiert sein, dass generierte Dateninstanzen ALLEN am

EDM Anwendungsportal zur Schnittstelle veröffentlichten Datenanforderungen entsprechen.

Anmerkung: Diese Vorgabe impliziert unter anderem das folgende Verhalten von Software: Sind von Benutzern stammende Angaben auf eine Weise unvollständig oder inkonsistent, die das Erstellen einer

allen Datenanforderungen genügenden Dateninstanz verhindert, dann soll durch die Software keine Dateninstanz erstellt oder übermittelt werden, sondern stattdessen der Software-Benutzer auf das Fehlen oder die Inkonsistenz von Daten aufmerksam gemacht werden. ■

Vorgabe 5 (ID 816): Bei der Verarbeitung von Dateninstanzen MÜSSEN Dateninstanzen, welche

sämtliche der als verpflichtend gekennzeichneten Datenvorgaben – insbesondere Gültigkeit bezüglich des

XML Schemas und Einhaltung aller als verpflichtend gekennzeichneten Datenanforderungen – erfüllen, akzeptiert werden und dürfen nicht automatisch zurückgewiesen werden.

Anmerkung: Eine bei der Verarbeitung akzeptierte Dateninstanz kann in Folge von einem Menschen inhaltlich nicht akzeptiert bzw. zurückgewiesen werden. Diese Vorgabe bezieht sich lediglich auf ein

automatisches Zurückweisen, welches es ausschließlich unter den genannten Voraussetzungen geben darf. ■

5.2.2 Persistierung und (De-)serialisierung

Vorgabe 6 (ID 549): Funktionen zur Entgegennahme und Persistierung von Dateninstanzen MÜSSEN in

Bezug auf die Inhalte (XML-Element- und Attributwerte) abwandlungsfrei und verlustfrei sein.

Datenabwandlungen und Verluste MÜSSEN für die gesamte Dauer der Persistierung ausgeschlossen sein.

Anmerkungen:

Dateninstanzen MÜSSEN so persistiert werden, dass die persistierten Daten für das Erstellen

einer XML-Instanz geeignet sind, die sich von der entgegengenommenen XML-Instanz in den

Inhalten (XML-Element- und Attribut-Inhalte) nicht unterscheidet.

Dateninstanzen brauchen NICHT so persisitiert zu werden, dass eine exakte Reproduktion der

entgegengenommenen XML-Instanz grundsätzlich möglich ist. Unterschiede zwischen

entgegengenommener XML-Instanz und aus persistierten Daten generierter bzw. generierbarer XML-Instanz sind zulässig, sofern sie nicht die Inhalte betreffen. Beispiele für solche nicht die



Inhalte betreffenden Unterschiede zwischen XML-Instanzen sind in der W3C Empfehlung „Canonical XML“ beschrieben. Werden etwa in einer XML-Instanz Tabulatorzeichen zur

Einrückung von XML-Tags verwendet, und in der anderen stattdessen Leerzeichen, so sind die

beiden XML-Instanzen zwar als Byte- oder Zeichenfolge nicht exakt übereinstimmend, inhaltlich aber dennoch äquivalent.

De facto bedeutet diese Vorgabe auch, dass entgegengenommenene und verarbeitete XML-

Element- und Attributwerte allesamt einzeln für sich persistiert werden müssen. Es sind inbesondere die folgenden Arten der Persistierung nicht geeignet:

1. Entgegengenommene Element- oder Attributwerte stimmen mit Werten aus Stammdaten

überein, auf welche die Daten entgegennehmende Software Zugriff hat. Anstelle die Element- und Attributwerte einzeln für sich zu persistieren wird lediglich ein Verweis auf

den Stammdateneintrag gespeichert;

2. Entgegengenommene Element- oder Attributwerte stimmen mit Werten aus Codelisten

überein, auf welche die Daten entgegennehmende Software Zugriff hat. Anstelle die Element- und Attributwerte einzeln für sich zu persistieren wird lediglich ein Verweis auf

den Codelisteneintrag gespeichert.

Diese Arten der Persistierung sind aus dem folgenden Grund nicht geeignet: Für Anpassungen von Stamm- und Referenzdaten soll unabhängig von deren Historisierung jedenfalls sichergestellt

sein, dass deren Anpassungen keine automatischen (und im allgemeinen unbeabsichtigten) Änderungen von Meldungsinhalten nach sich ziehen. ■

5.2.3 Umgang mit Codelisten

Vorgabe 7 (ID 216): Software MUSS so implementiert werden, dass eine Aktualisierung von Codelisten

bzw. ein Verwenden der Software mit aktualisierten Codelisten ohne neues Kompilieren, Ausrollen und Installieren der Software möglich ist. ■

Vorgabe 8 (ID 481): Im EDM werden über ein Webservice Codelisten zum Abruf angeboten. Software

DARF NICHT so implementiert werden, dass jeder Zugriff auf Codelisten ad hoc und unmittelbar über das EDM Webservice erfolgt. Stattdessen MUSS Software mit „lokalen Kopien“ der Codelisten arbeiten. Das

EDM Webservice zum Bezug von Codelisten DARF NICHT für andere Zwecke verwendet werden als das Initialisieren und Aktualisieren solcher „lokaler Codelisten-Kopien“. ■

Vorgabe 9 (ID 634): Es wird EMPFOHLEN, Software so zu implementieren, dass die Verfügbarkeit

aktualisierter Codelisten in regelmäßigen Abständen automatisch geprüft wird.

Anmerkung: Eine solche Überprüfung der Verfügbarkeit aktualisierter Codelisten ist durch Implementierung einer Anbindung an das EDM Codelisten-Webservice möglich. ■

Vorgabe 10 (ID 788): Wird von Software in regelmäßigen Abständen automatisiert die Verfügbarkeit

aktualisierter Codelisten geprüft, dann SOLL die Prüfung auf die Verfügbarkeit aktualisierter Codelisten zumindest alle 30 Tage erfolgen. ■

Vorgabe 11 (ID 580): Wird von Software in regelmäßigen Abständen automatisiert die Verfügbarkeit

aktualisierter Codelisten unter Verwendung des EDM Webservice für Codelisten geprüft, dann DARF die

Prüfung auf die Verfügbarkeit einer aktualisierten Liste nicht öfter als ein Mal alle 12 Stunden erfolgen, und SOLL nicht öfter als ein Mal alle 24 Stunden erfolgen. ■

Vorgabe 12 (ID 909): Wenn bei der Entgegennahme bzw. Verarbeitung von Daten geprüft wird, ob in

den entgegengenommenen Daten enthaltene Identifikationszeichenketten gültig in dem Sinn sind, dass sie mit der zu einem Codelisten-Eintrag gehörigen Identifikationszeichenkette übereinstimmen, dann

MUSS folgende Bedingung eingehalten werden: Eine automatisierte Zurückweisung darf nur dann erfolgen, wenn sichergestellt ist, dass die von der empfangenden Software genutzten Codelisten-Kopien

mindestens so aktuell sind wie die vom Dokumentersteller bzw. der dokumenterstellenden Software genutzten Codelistenkopien. ■

5.2.4 Fehlerbehandlung

Vorgabe 13 (ID 757): Tritt bei einem Webservice-Request eine Ausnahmesituation („Exception“) auf,

d.h. ein SOAP-Fault, dann SOLL es dazu Client-seitig einen Log-Eintrag geben. ■

Vorgabe 14 (ID 530): Wird ein Webservice-Request (oder eine Folge von Webservice-Requests) durch

eine Benutzerinteraktion ausgelöst, und tritt dabei eine Ausnahmesituation, d.h. ein SOAP-Fault, auf,

dann SOLL der Benutzer darüber informiert werden, dass die Interaktion der Software mit dem EDM-Webservice fehlschlug. ■



Vorgabe 15 (ID 530): Wird ein Benutzer über das Fehlschlagen einer Interaktion mit dem EDM-

Webservice informiert, dann SOLL mit den Informationen, die das EDM-Webservice als Beschreibung des Fehlers in der SOAP-Fault Nachricht liefert, in der Information an den Benutzer ausschließlich auf eine der

beiden folgenden Arten umgegangen werden:

1. Die vom EDM Webservice gelieferte Beschreibung des Fehlers wird dem Benutzer NICHT bzw. nicht unmittelbar angezeigt.

Beispiel: Das EDM Webservice liefert als Fehlerbeschreibung die Fehlerkategorie-ID „101“ für „Authentifizierung fehlgeschlagen“. Diese Information (der Code 101) wird dem Benutzer nicht

unmittelbar angezeigt. Der Benutzer sollte aber in diesem Fall sehr wohl darauf aufmerksam

gemacht werden, dass die Authentifizierung fehlschlug. Aber eben NICHT durch unmittelbares Anzeigen der (nicht für Benutzer bestimmten) Informationen aus der SOAP-Fault-Nachricht;

2. Die vom EDM Webservice gelieferte Beschreibung des Fehlers wird dem Benutzer so angezeigt, dass offensichtlich ist, dass nicht der Benutzer selbst dazu angehalten ist, sich mit dieser

Information auseinanderzusetzen, sondern dass dem Benutzer diese Information nur deswegen angezeigt wird, damit er sie im Bedarfsfall an Software-Servicepersonal weitergeben kann. ■

5.2.5 Authentifizierung

Vorgabe 16 (ID 284): Ein Vorhalten von EDM-Zugangsdaten durch die Client-Software für Webservice-

Aufrufe ist grundsätzlich gestattet. Bevor EDM-Zugangsdaten vorgehalten werden MUSS zunächst jedoch eine explizite Einwilligung des Benutzers eingeholt werden. ■

Vorgabe 17 (ID 405): Es ist zulässig, dass die Einwilligung zum Vorhalten von EDM-Zugangsdaten durch

Software, die als Client gegenüber EDM Webservices agiert, vom einem Benutzer der Software über einen Dialog in einer graphischen Benutzeroberfläche der Software eingeholt wird. Dazu MUSS

Folgendes gewährleistet sein:

1. Der Benutzer MUSS gegenüber der Software authentifiziert sein, z.B. per Username und Passwort angemeldet;

2. Für die Einwilligung zum Vorhalten von EDM-Zugangsdaten MUSS der Benutzer zumindest die folgenden beiden Interaktionen durchführen:

a. Setzen einer „Checkbox“ oder eines vergleichbaren Interaktionselements zur Erklärung

der Einwilligung;

b. Drücken einer Schaltfläche (eines „Buttons“) zur Bestätigung der Einwilligung. ■

Vorgabe 18 (ID 852): Vorgehaltene EDM-Zugangsdaten MÜSSEN in der Software so verwaltet werden,

dass Unbefugte keinen Zugriff auf diese Zugangsdaten erhalten.

Anmerkung: Insbesondere DÜRFEN EDM-Zugangsdaten jedenfalls NICHT ohne Verschlüsselung gespeichert werden. ■

Vorgabe 19 (ID 939): Für Benutzer, deren EDM-Zugangsdaten eine Software für Webservice-Aufrufe

vorhält, MUSS diese Software dem Benutzer die Möglichkeit bieten, die vorgehaltenen EDM-

Zugangsdaten zu jedem beliebigen Zeitpunkt zu aktualisieren bzw. zu löschen.

Anmerkung: Daraus leitet sich auch ab, dass für durch User-Interaktionen unmittelbar ausgelöste EDM-Webservice-Aufrufe, für die das EDM Webservice ein Fehlschlagen der Authentifizierung rückmeldet, der

Benutzer die Möglichkeit haben MUSS, die in der Software für Webservice-Aufrufe hinterlegten Zugangsdaten sofort und unmittelbar zu aktualisieren. ■

5.3 Vorgaben, die auch den Benutzer der Software betreffen können

5.3.1 Authentifizierung

Vorgabe 20 (ID 954): Die beim Aufruf jeder Webservice-Operation per HTTP Basic Authentication

Header übermittelten Zugangsdaten MÜSSEN einen im EDM registrierten Benutzer authentifizieren. ■

Vorgabe 21 (ID 308): Sei B der durch die per HTTP Basic Authentication Header übermittelten

Zugangsdaten im EDM authentifizierte Benutzer. Sei zudem S das in den Dokumentmetadaten des Inputs zur ShareDocument-Operation angegebene meldende Sammel- und Verwertungssystem (siehe

DocumentEvent-Datenelement auf Seite 17). Folgendes MUSS zutreffen: Es gibt zu S einen

Stammdateneintrag im EDM, und gemäß EDM-Stammdaten ist B ein zu S gehörender EDM-Benutzer. ■



Vorgabe 22 (ID 745): Sei S das in den Dokumentmetadaten des Inputs zur ShareDocument-Operation

angegebene meldende Sammel- und Verwertungssystem (siehe DocumentEvent-Datenelement auf

Seite 17). Folgendes MUSS zutreffen: Es gibt zu S einen Stammdateneintrag im EDM, und es gab bereits mindestens einen Login am EDM-Portal http://edm.gv.at durch einen zu S gehörenden Benutzer. ■

5.3.2 Fristen

Vorgabe 23 (ID 681): Verpackungs-Monatsmeldungen SOLLEN bis spätestens zum 21. Tag des auf den

Berichtsmonat folgenden Monats über das EDM Webservice an zuständige Behörden übermittelt werden.

Beispiel: Sich auf den März beziehende Monatsmeldungen sollen spätestens am 21. April übermittelt werden.

Anmerkung: Vom EDM Webservice werden Monatsmeldungen, die nicht vor dem 1. Tag des

zweitnachfolgenden Monats übermittelt werden (im Beispiel ist das der 1. Mai) für gewöhnlich automatisch zurückgewiesen. ■

Vorgabe 24 (ID 490): Verpackungs-Jahresmeldungen SOLLEN bis spätestens zum 10. April des auf das

Berichtsjahr folgenden Jahres über das EDM Webservice an zuständige Behörden übermittelt werden.

Beispiel: Sich auf das Jahr 2014 beziehende Jahresmeldungen sollen spätestens am 10. April 2015 übermittelt werden. ■

http://edm.gv.at/

BESCHREIBUNG DER EVERPACKUNG WEBSERVICE-SCHNITTSTELLE FÜR AMMEL UND...

Documents

Transcript of BESCHREIBUNG DER EVERPACKUNG WEBSERVICE-SCHNITTSTELLE FÜR AMMEL UND...