ANTWORT_IR ist nur zu senden wenn Korrespondenzadresse von Lieferadresse abweicht.

Sind die Adressen ident:

ABLEHNUNG_IR mit neuem Response Code:

"Korrespondenzadresse weicht nicht von Anlagenadresse ab"

Erster Vorschlag - die zeitliche Begrenzung, ab wann der Lieferant die Nachfrage stellen kann, zu streichen

 Unsere Praxis zeigt, dass in der Regel die Daten beim Netzbetreiber vorliegen (der Kunde kann die Daten im Portal des Netzbetreibers sehen), aber nicht an den Lieferanten weitergeleitet werden (weil z.B. irgendein Prozess abgebrochen ist). Als Lieferant brauchen wir die Möglichkeit sofort nachzufragen. Die Begründung, dass die Netzbetreiber sonst mit Nachfragen überflutet werden erscheint nicht sachgerecht, weil es an sich um einen Fall handelt, wo der Netzbetreiber der eigentlichen Verpflichtungen nicht nachkommt.

Zweiter Vorschlag - es sollte möglich sein auch historische Verbrauchsdaten nachzufragen (z.B. 12 Monate vor Lieferbeginn).

 Wir haben in der Praxis mehrere Nachfragen gehabt auch historische Kundendaten über unsere Kundenapp darzustellen. Der Kunde sollte eine praktische Möglichkeit haben über eigene Daten, die beim Netzbetreiber aufbewahrt werden, zu verfügen. Die einfachste Möglichkeit wäre, dass der Lieferant auch historische Daten nachfragen kann. Natürlich nur auf Vollmacht des Kunden.

Die angeführte Tabelle Mögliche Kombinationen Messintervall und Versendezyklus bei Anforderungsprozess CP_REQ_CMI enthält eine unzulässige Kombination:

• Für den DeviceType IMS ist eine Übermittlung von QH – Werten nicht möglich.

Bei LPZ – Geräten „Metering Intervall GAS“ wäre noch eine Ergänzung für den Transmission Cycle nötig, da hier auch stündlich Werte übermittelt werden können (ab Oktober 2019 GMMO – VO).

Hier hätte ein Lieferant die Möglichkeit diese Übertragung anzufordern.

Vorschlag – die Authentisierungsmethoden, die für die Wechselprozesse erlaubt sind, auch für REQ_CMI anzuwenden.

 Die Praxis heute ist höchst unterschiedlich. Es gibt NB, die gängigsten Verfahren 1 und 4 sofort anwenden, dann gibt es NB die für die Anwendung von Verfahren 1 und 4 eine separaten Vertrag zwischen den NB und Lieferanten fordern und es gibt NB die einen PDF mit Kundenunterschrift verlangen. Die jetzige Formulierung, dass vor der erstmaligen Anforderung mit dem Netzbetreiber die zu verwendenden Authentifizierungsverfahren abzustimmen sind, trägt nichts zum Datenschutz der Kundendaten bei und verursacht in der Regel nur Ärger bei den Kunden.

 Vorschlag – die 5 Tage Regel abzuschaffen

 Die Regel, dass die REQ_CMI nur für 5 Tage rückwirkend geschickt werden darf verursacht unnötige Komplexität. Es wäre einfacher, dass die REQ_CMI immer ab Lieferbeginn umgesetzt wird. Als Lieferant haben wir Möglichkeit die Daten separat unter David Verordnung ab Lieferbeginn nachzufragen. Die Praxis zeigt, dass meistens die Netzbetreiber nicht bereit sind die CMI Nachfrage sofort umzusetzen. Oft muss die Meldung mehrmals geschickt werden, es vergehen Tage und die 5 Tage Regel verursacht dann Lücken in der Datenübermittlung.

Vorschlag – es sollte für den Lieferanten möglich sein eindeutig festzulegen ob eine jährliche oder monatliche Abrechnung gewünscht ist und im Falle einer jährlichen Abrechnung in welchem Intervall die Teilbeträge zu zahlen sind.

 Mit Smart Meter haben die Kunden eine Wahl der Zahlungsmethoden. Es wäre zweckmäßig, dass der Lieferant die Möglichkeit hat explizit die dem Kundenwunsch entsprechend die Abrechnungsmethoden festzulegen.

 In der Praxis ist es auch vorgekommen, dass der NB die REQ_CMI und die CBC Nachricht geknüpft behandelt haben. Diese Anfrage ist separat von der Anforderung von täglichen Messwerten zu betrachten, weil beim täglichen Anforderung von 15 M Werten geht es vor Allem um die laufende Darstellung des Verbrauchs für die Kunden. Der Kunde kann aber trotzdem die Rechnung auf der Basis der Teilbeträge erwarten. Daher sollte es eine Möglichkeit geben, dass wir die elektronische Netzrechnung entweder auf der Basis von Teilbeträgen oder auf Basis der tatsächlichen Messwerte erhalten.

Wir schlagen vor, statt der Übertragung eines einfachen Strings base64 codiertes HTML zu verwenden. Damit gibt es kein Problem mit der Darstellung und Interpretation von Absätzen, Tabulator, nicht erlaubter Zeichen, usw.

Größenbeschränkung auf ein MB.

Neuer Ablehnungscode "Nachicht nicht lesbar".

Zustimmung erfolgt nur, wenn der Prozess als optional eingestuft wird.

Somit wird in der ABLEHNUNG_MSG ein Response Code

"Prozess wird nicht unterstützt" benötigt.

Lieferantenwechsel steht nicht in Kategorie jedoch in Beschreibung.

Dieser Prozess wurde bei jeder Besprechung von Wien immer abgelehnt und

ist im Massengeschäft nicht anwendbar.

Sollte dieser Prozess trotz vehementen Einspruch von uns per 1.4.2020 kommen, wird die Beantwortung der Mailanfragen mit selbigem Datum bei uns eingestellt.

Der NB hat die Datenhoheit und muss die AENDERUNG_DA seitens des Lieferanten nicht übernehmen. Dieser bekommt jedoch keine Rückmeldung, ob die Änderung übernommen wurde oder nicht. Daher ist sinnvoll eine ABLEHNUNG_DA mit einem Code "Änderungen abgelehnt" zu ergänzen. Eine Änderung würde an den Marktpartner mittels erneuter AENDERUNG_DA übermittelt werden, somit würde mit dieser Lösung die Informationslücke zwischen Übernahme durchgeführt Ja / Ja, aber mit Änderungen und Nein geschlossen werden.

Bei ABLEHNUNG_DA fehlt für den NB , wenn dieser die Lieferadressänderung nicht akzeptiert, ein Response Code "Änderung wird nicht akzeptiert"

Denn NB gibt die Lieferadresse vor und hat in diesem Prozess keine Möglichkeit der Ablehnung.