Ziel ist es, dass ein Dienstleister die Einwilligung zur Nutzung bzw. Bereitstellung von kundenbezogenen Daten zu einem bestimmten Zweck und für einen definierten Zeitraum erlangt. 

1.    Der Dienstleister erhält vom Endkunden pro Zählpunkt eine Einwilligung zur Nutzung der kundenbezogenen Daten

2.    Der VNB liefert dem Dienstleister auf Anfrage kundenbezogene Daten.

3.    Der VNB liefert periodisch Daten an den Dienstleister, sofern dies in der Datenfreigabe definiert ist.

4.    Der Endkunde ist vom Dienstleister über die Natur der Datenanfrage aufgeklärt (spezifisch Beschreibung der Daten, Information über den Zweck und die Löschfrist)

1.    Der Dienstleister erhält eine Ablehnung zur Nutzung der kundenbezogenen Daten.

2.    Der VNB verarbeitet die Datenfreigabe-Anfrage nicht rechtzeitig.

3.    Der Kunde gibt die Einwilligung zur Datenfreigabe-Anfrage nicht rechtzeitig.

Verhalten im Fehlerfall

Bei Fehlern verbleiben die angefragten Daten beim VNB im Zustand „nicht freigegeben“.

Der Dienstleister bekommt bei funktionalen Fehlern als Antwort vom VNB eine Ablehnung der Freigabe Anforderung mit einem Fehlercode.

Kann der geforderte Datentyp der Anfrage nicht geliefert werden (z.B. aus technischen Gründen bei 1/4h Werten), dann erfolgt daraus eine Ablehnung (ConsentNotification mit negativem ResponseCode).

Duplikate werden anhand der fachlichen Schlüssel erkannt. Jeweils die erste empfangene Nachricht bei VNB oder Dienstleister wird von diesem als die korrekte Nachricht angenommen. Nach Erhalt der ersten Nachricht empfangene Duplikate werden im Prozess nicht berücksichtigt. Das VNB oder Dienstleister Backend informieren ihre jeweiligen Nutzer über auftretende Nachrichten zur manuellen Problemlösung.

Ist innerhalb von 10 Arbeitstagen nach Erhalt der Datenfreigabe-Anfrage beim VNB keine KundenEinwilligung zur Freigabe erfolgt, sendet der VNB eine Datenfreigabe-Ablehnung (ConsentNotification mit negativem ResponseCode) an den Dienstleister und modifiziert den Status der Datenfreigabe-Anfrage, so dass für den Endkunden keine Einwilligung mehr möglich ist.

Tritt ein Fehler in einem bestehenden energiewirtschaftlichen Prozess auf (z.B. Versand von Lastgängen schlägt fehl) hat dies keinen Einfluss auf den Zustand der Datenfreigabe

Möchte der Dienstleister trotz eines aufgetretenen Fehlers weiterhin auf die Daten zugreifen, muss er den Prozess erneut starten, d.h. eine neue Datenfreigabe-Anfrage senden.

Für die Abwicklung des Datenaustausch stehen folgende Möglichkeiten zur Verfügung:

1. Prozessumsetzung in der eigenen IT-Landschaft: EDA Messenger oder EDA e-mail. Für weitere Infos kontaktieren Sie bitte eda@ebutilities.at.
   
2. Nutzung eines IT Dienstleister (SaaS): EDA Messenger, welcher durch den IT Dienstleister betrieben wird. Für weitere Infos kontaktieren Sie bitte Ihren IT Dienstleister

Es wird erwartet, dass die Datenfreigabe-Anforderung zeitnah nach Eingang der Nachricht im Kundenportal des VNB für den Endkunden sichtbar ist, so dass der diese freigeben kann.

Der Zeitpunkt, an dem der Versand der Daten gestartet wird, ist abhängig von den angefragten Daten.

Generell erfolgt der Versand von zyklischen Daten nach dem Push Prinzip (d.h. VNB versendet automatisch im Rahmen der bestehenden Marktkommunikation).

Das Ab-Datum darf spätestens 30 Arbeitstage in der Zukunft liegen.

Ein Dienstleister benötigt Kundendaten vom VNB, um seine Dienstleistung erbringen zu können.

Befüllung der Felder DateFrom, MeteringInterval, TransmissionCycle abhängig vom RequestedDataType. Detailbeschreibung siehe dazu unter Prozesskategorie -> CCM --> Datentypen

Abgeschlossene Registrierung als Dienstleisters unter www.ebutilities.at.

Der Zählpunkt muss einem Netzbetreiber zugeordnet sein und. für den Zählpunkt muss ein aufrechter Vertrag (abgeschlossene ANM) vorliegen.

7.3.2022

• Neue Prozessverion 0.10

• Neue Schemaversion
• Anpassungen in der Darstellung
• Neuer Subprozess CM_REQ_OFF_QR für Erstellung des QR-Codes
• Neuer Subprozess CM_REQ_OFF_SUB für gemeinsamen CCM Ablauf mit Energiegemeinschaften

• Neue Schemaversion CMNotification (01.10)
• Energiedienstleister anstatt Bereiber einer gemeinschaftlichen Erzeugungsanlage

• Überarbeitung der MessageCodes
• Beschreibung der Responsecodes durchgeführt
• neues PDF für Prozessablauf hinzugefügt

• neue Version 1.00 erstellt
• Einarbeitung der Anmerkungen aus der Konsultation

• Erstfassung erstellt