Wenn von IMS auf IME umgestellt werden soll, dann wird eine Umstellung 5 Tage in der Vergangenheit nicht möglich sein, da der Zähler die 1/4h Werte in der Regel nicht im Speicher haben wird. 

Als allgemeine Rückmeldung erlauben wir uns anzuführen, dass die Bezeichnung aller Prozesse bzw. der einzelnen Prozessschritte möglichst vereinheitlicht werden sollte.

- Prozess beendet – vs - Datenänderung beendet

- Arbeitstage – vs – AT

- Lieferant – vs – Versorger – vs – Lieferant/Versorger

- ZP ok? – vs – ZP ok?/beliefert?

- Zählpunktscharf im Prozessdiagramm teilweise (ohnehin unter Granularität angeführt)

• Die Prozessnamen (Z.B. MD_CHG_CP) und Prozessschritte (z.B. AENDERUNG_CP)  sollten sprechend gewählt werden. Die jetzige Kurzform ist nicht einprägsam und führt zu Verwechselungen.
• ResponseCode (73) "Nachrichtendaten fehlen" sollte nicht eingeführt werden, sondern die Daten sollten über die XSDs validiert werden. Eventuell ist es dazu nötig, für jede Nachricht eine eigene XSD zu definieren. Das wäre sehr vorteilhaft, denn nur so ist gewährleistet, dass die Nachrichten vollständig und korrekt übermittelt werden. Siehe auch nächste Anmerkung.
• Die XSDs sind nicht typsicher ausgeprägt (die meisten Felder haben eine Kardinalität von 0..1).
  • Besser wäre ein XSD für die einzelnen Nachrichten, um die Struktur der Nachrichten sicherstellen zu können. Wenn nicht als eigenes XSD, dann sollten erweiterte Validierungsmöglichkeiten implementiert werden.
  • Eine Nachricht sollte nur versendet werden können, wenn die Nachricht syntaktisch korrekt ist. Dieser Verfahren wird für die Übertragung der Lieferantenwechselnachrichten über EnergyLink verwendet.
  • Damit würde auch der Responsecode (73) "Nachrichtendaten fehlen" wegfallen
• Ein Beispiel einer Nachricht würde die Dokumentation verbessern.
• Aufzählungen sollten einheitlich als Enum mit aussagekräftigen Namen ausgeprägt werden. Für einige Felder ist dies schon geschehen
  
  • Sector statt 01 / 02 -> POWER und GAS
  • ConsumptionBillingCycle statt 01 -> MONTHLY, ...
  • TransmissionCycle statt D / M -> DAYLY, MONTHLY
  • DisconnectionReason 01 -> Prepayment 02 -> Qualifiziertes Mahnverfahren
• Einheitlich zur Marktkommunikation wäre statt ZIP die Feldbezeichnung PostalCode zu verwenden.
• Für eine optimale Verarbeitung der Prozesse wäre immer auch eine Antwort als Bestätigung notwendig. Ansonsten kann der Sender nicht erkennen, ob seine Nachricht bei Empfänger auch wirklich vollständig verarbeitet wurde. Dass eine Ablehnungsmeldung in den Fällen übersendet wird, ist ...

Mangels Möglichkeit zur Erfassung prozessübergreifender Anmerkungen erlauben wir uns diese hier an dieser Stelle einzutragen:

• Obwohl zum Login Benutzername und Passwort benötigt werden, dürfte ebUtilities keine gesicherte Verbindung (https://) verwenden, wodurch auf dieser Seite eingegebene Passwörter nicht vor Angreifern geschützt wären.
  
• Anwendbare Technische Dokumentationen sollten auch in der Prozess- und Schemata-Datenbank einen entsprechenden Status besitzen - auch um diese von nicht gem. Kapitel 5 der Sonstigen Marktregeln zustande gekommener Dokumentation zu unterscheiden:
  • z.B. „aktive Technische Dokumentation“ für aktuell anwendbare Technische Dokumentation
  • z.B. „inaktive Technische Dokumentation“ für historische Technische Dokumentation
• Es bleibt offen, wie die Umsetzung der für Intelligente Messgeräte definierten Prozesse erfolgt, wenn ein Kunde kein Intelligentes Messgerät hat (z.B. im Falle von Ab- und Wiedereinschaltungen).
• Die Trennung der Anforderungsprozesse für Zwischenablesung, Zwischenablesung - Insolvenz, Zwischenablesung mit Abrechnung, Zwischenablesung mit Abrechnung – Insolvenz und Zwischenabrechnung ohne Ablesung ist verwirrend und erklärungsbedürftig.
• Wir weisen darauf hin, dass mit der Anwendbarkeit der Customer Processes als Technische Dokumentationen gem. Kapitel 5 der Sonstigen Marktregeln auch die Datenbankeinträge für die referenzierten Schemata „Masterdata (01.11)“, „CPRequest (01.11)“, „CPDevStatus (01.10)“, „CPNotification (01.10)“, „MeteringPointList (01.10)“ und „CPDocument (01.11)“ den Status einer Technischen Dokumentation erlangen.
  
• In den Datenbankeinträgen zu diesen Schemata funktionieren die Links im Punkt "Namespace“ nicht.
• In den Prozess- und Schemabeschreibungen werden einige Fachausdrücke und Spezifikationen verwendet (z.B. XML Komposit, Prozessdatum). Eine Erklärung oder Definition an passender Stelle wäre für die Benutzer und die Interpretation der Dokumente hilfreich.
• Wir merken an, dass die Rückforderungsprozesse, wie in...

CR_MSG – nicht in der Konsolidierung

Im Prozessdiagramm ist die Zusatzinfo falsch „ZP im Netzgebiet bzw vom Empfänger versorgt“  Korrektur auf „ZP vom Empfänger versorgt“

„Ende der Leiferantenzuordnung“ – 2x Tippfehler

Betreffend Beschreibung: Diese Daten müssen an jeden Versorger bzw. Netzbetreiber versendet werden, dessen Zählpunkt von der Änderung betroffen ist.

Der Empfänger hat dafür zu sorgen, dass die erhaltenen Datenänderungen nicht wieder an den Sender als neue Änderungen übermittelt werden. Damit sollen „Endlosschleifen“ vermieden werden.

Es kann sich folgende Problematik ergeben:

Lieferant A erhält vom Kunden die Aufforderung der Namensänderung.
Er informiert NB01 und NB02.

NB01 startet daraufhin die graue Kette (NB01 -> Lieferant B -> NB02 -> Lieferant A -> NB01 -> .....).
NB02 startet daraufhin die rote Kette (NB02 - > Lieferant B -> NB01 -> Lieferant A -> NB02 -> …..).

Als Ergebnis werden zwei Kreise geschlossen, die sich theoretisch endlos fortsetzen.

Oder kommt es nur dann zu einer Information an weitere Marktteilnehmer wenn auch eine Datenänderung beim jeweiligen Marktteilnehmer durchgeführt wird? Falls ja, dann würde das die jeweiligen Ketten unterbrechen.

• Bei einer etwaigen Weiterleitung einer solchen Information zwischen unterschiedlichen Lieferanten und Netzbetreibern sind jedenfalls sämtliche datenschutzrechtliche Bestimmungen einzuhalten.

City, Street, StreetNo, Staircase, Floor oder DoorNumber werden bei den Marktpartnern nicht in einheitlicher Form verwendet. Einerseits sind unterschiedliche Strukturen in den Datenbanken möglich und andererseits werden abweichende Orts- bzw. Straßenverzeichnisse geführt.

• Einheitlich zur Marktkommunikation wäre statt ZIP die Feldbezeichnung PostalCode zu verwenden.
• Die Voraussetzungen "Voraussetzung ist ein aufrechter Liefervertrag zum Prozessdatum (ProcessDate)." ist zu kurz gefasst. Alle gerade im Prozess befindlichen Akteure müssen benachrichtigt werden, also z.B. während eines WIES oder ANM auch der LieferantNeu. Gerade in den Wechsel- und Anmeldeprozesen fallen die Schiefstände auf und müssen unbedingt auch an den neuen Lieferanten übertragen werden.
• Es sollte möglich sein bei nicht schlüssigen Daten diese auch nicht zu übernehmen und das in der Antwort mitzuteilen
  

„Datenänderung bearbeiten“ -> ist eigentlich eine Prüfung, daher bitte auf „Datenänderungen prüfen“

Gleiche Prüfung wie bei MD_CHG_CP sinnvoll, „Änderung akzeptiert“, ansonsten mit ResponseCode entsprechend Stellungnahme Wiener Netze Ablehnung senden

• Bei einer etwaigen Weiterleitung einer solchen Information zwischen unterschiedlichen Lieferanten und Netzbetreibern sind jedenfalls sämtliche datenschutzrechtliche Bestimmungen einzuhalten.

• Im Gegensatz zum Prozess „MD_CHG_CP Stammdatenänderung – Namensänderung“ sind bei diesem Prozess keine Fristen angeführt. Wodurch ist dies begründet bzw. ist im Falle einer Änderung der Lieferadresse kein Nachweisdokument über den Prozess MD_VDC zu übermitteln?

Der Prozess ist in der hier beschriebenen Form nicht schlüssig.

Der Netzbetreiber ist der Stammdatenhalter und entscheidet, ob eine Adresse zulässig ist. Sendet nun der Energielieferant dem Netzbetreiber eine Änderung gibt es keine Rückmeldung an den Energielieferanten ob die Adresse tatsächlich im System des Netzbetreibers geändert wurde oder nicht. Das kann in weiterer Folge zu Problemen in der ABM und WIES führen.

z.B. Energielieferant übermittelt Adresse: Wasserstraße 1, der Netzbetreiber kann die gewünschte Umstellung nicht vornehmen da die korrekte Adresse Sonnengasse 10 ist. Der Netzbetreiber hat nun nur die Möglichkeit einen Antwortdatensatz mit 99 Meldung erhalten zu versenden. Die Adresse ändert sich im Netze System nicht. Der Energielieferant erhält keine weitere Meldung.

Eine Lösung wäre: Ablehnung mit Responsecode Adresse nicht übernommen

Durch die Erweiterung im Schema bei der Lieferadresse um das Feld Additional Address (Zusatzdaten zur Adresse) ist auch die Änderung dieses Feldes als Prozessauslöser zu definieren.

• Die Voraussetzungen "Voraussetzung ist ein aufrechter Liefervertrag zum Prozessdatum (ProcessDate)." ist zu kurz gefasst. Alle gerade im Prozess befindlichen Akteure müssen benachrichtigt werden, also z.B. während eines WIES oder ANM auch der LieferantNeu. Gerade in den Wechsel- und Anmeldeprozesen fallen die Schiefstände auf und müssen unbedingt auch an den neuen Lieferanten übertragen werden.
• Es sollten Fristen festgelegt werden, wie schnell eine Änderung der Stammdaten an die Marktpartner versendet werden soll. Vorschlag 24h.
• Zudem sollte festgelegt werden, in welchem Zeitrahmen sich das Änderungsdatum ProcessDate  bewegen kann.
• Nachricht wird nur vom Netz an den Lieferanten versendet. Der Hinweis "Der Empfänger hat dafür zu sorgen, dass die erhaltenen Datenänderungen nicht wieder an den Sender als neue Änderungen übermittelt werden. Damit sollen „Endlosschleifen“ vermieden werden" kann daher entfernt werden.
• Es kann wohl nicht vorkommen, dass sich die Energierichtung eines Zählpunkts ändert, da sich dann auch der MeterCode (OBISNummer) ändern müßte (nicht vorgesehen). Das Feld "EnergyDirection @Changed" sollte entfernt werden.
• Das XSD sollte so definiert sein, dass entweder GasSpecificData oder ElectricitySpecificData Verwendung finden muss.

• Bei einer etwaigen Weiterleitung einer solchen Information zwischen unterschiedlichen Lieferanten und Netzbetreibern sind jedenfalls sämtliche datenschutzrechtliche Bestimmungen einzuhalten.
  

• Bei einer etwaigen Weiterleitung einer solchen Information zwischen unterschiedlichen Lieferanten und Netzbetreibern sind jedenfalls sämtliche datenschutzrechtliche Bestimmungen einzuhalten.
  

• Dem verwendeten Prozessschritt der Ablehnung ist kein Schema zugewiesen.
  

Für den Prüfungsprozessschritt „Rechnungsadresse vorhanden“ ist kein entsprechender Ablehnungsgrund vorhanden.

Bei dem Bilanzierungstyp wird wie folgt unterschieden:

• Stunden LPZ

• Tages LPZ

• Optierer Tage LPZ

• SLP

• Ggf. Fremdlieferung

• Ggf. Aggregat

Bei den Prozessen

Prozess MD_REQ_GN - Anforderung der aktuellen Stammdaten

Prozess PDL_MSG - Senden der Zählpunktliste

soll zusätzlich die Information des Bilanzierungstyps vom Netzbetreiber gesendet werden.

Der Bilanzierungstyp ist auch bei den IDEX AT2 Prozessen Belieferungswunsch, Wechsel und Anmeldung enthalten. In alle Fällen aber nur als optional zu senden.

• MPGasSpecificLPCData: Bilanzierungsmethode (nur für LPZ)

• GasBalancingChangeDate: Umstellung der letztmaligen Bilanzierungsmethode (nur für LPZ)

Aktuell kann die Information beim Netzbetreiber nur außerhalb der IDEX Welt eruiert werden. Die Information ist auch in den MS CONS zur Verbrauchsabrechnung nicht enthalten.

Für den Versorger ist die Information für folgende weiterführende Prozesse notwendig:

• Ausgleichsenergieabrechnung: Der Versorger muss dem Bilanzgruppen-Verantwortlichen den Bilanzierungstyp bekannt geben. Ziel ist es die Ausgleichsenergie so gering wie möglich halten.

• Day ahead Prognose: In der Kundengruppe zwischen 5 und 10 MW (Optierung möglich). Dem Bilanzgruppenverantwortlichen muss klar sein zu welchen Bilanzierungsregime der Kunden zugeordnet ist.

• Die Abrechnung der Regelenergieumlage wird über die Bilanzierungsmethode gesteuert. 

- Aus unserer Sicht ist die Schleife beim Prozessschritt „Fehler bearbeiten“ nicht notwendig

- Im Vergleich zum Prozess CP_REQ_MRB (01.99) - Anforderung einer Zwischenablesung mit Abrechnung - ist hier

  keine Frist für die Übermittlung der Verbrauchsdaten des Netzbetreibers an den Lieferanten vorgegeben

Der Prozessschritt „Ablesung löst das Übermitteln der Verbrauchsdaten aus“ sollte gestrichen werden, da hierzu kein Prozess existiert und mehrere Prozessschritte dahinter stehen.

Wir würden als Prozessschritte vorschlagen:

• Ablesung veranlassen und verarbeiten

• Verbrauchsdaten übermitteln (Format offen)

• Prozess beenden

Bitte im Text ergänzen, dass dieser Prozess nur für DSZ, NonSmart relevant ist, da bei IMS, IME und IMN die Daten täglich/ monatlich erfasst und bereitgestellt werden (eigene Prozesse).

• Der Satz „Sofern es zwingende gesetzliche Grundlagen gibt, die eine explizite Bestätigung der Kostenübernahme für die Ablesung erfordern, ist das Feld „CPRequest – AssumptionOfCosts“ mit dem Wert J zu füllen.“ ist ungenau formuliert und wirft Fragen auf.
• Generell ist anzumerken, dass die Verrechnung von Ablesekosten in der SNE-VO nur gegenüber dem Kunden geregelt ist, nicht jedoch gegenüber Lieferanten.

• Die Trennung der Anforderungsprozesse für Zwischenablesung, Zwischenablesung - Insolvenz, Zwischenablesung mit Abrechnung, Zwischenablesung mit Abrechnung – Insolvenz und Zwischenabrechnung ohne Ablesung ist verwirrend und erklärungsbedürftig.

- Aus unserer Sicht ist die Schleife beim Prozessschritt „Fehler bearbeiten“ nicht notwendig

- Im Vergleich zum Prozess CP_REQ_MBI (01.99) - Anforderung einer Zwischenablesung mit Abrechnung – Insolvenz-

  ist hier keine Frist für die Übermittlung der Verbrauchsdaten des Netzbetreibers an den Lieferanten vorgegeben

- Die reine Bezeichnung „Anmeldefrist“ im Fließtext ist möglicherweise irreführend – Unser Vorschlag wäre „vor

  Ablauf der Anmeldefrist“

Der Prozessschritt „Ablesung löst das Übermitteln der Verbrauchsdaten aus“ sollte gestrichen werden, da hierzu kein Prozess existiert und mehrere Prozessschritte dahinter stehen.

Wir würden als Prozessschritte vorschlagen:

• Ablesung veranlassen und verarbeiten

• Verbrauchsdaten übermitteln (Format offen)

• Prozess beenden

Bitte im Text ergänzen, dass dieser Prozess nur für DSZ, NonSmart relevant ist, da bei IMS, IME und IMN die Daten täglich/ monatlich erfasst und bereitgestellt werden (eigene Prozesse).

• Die Trennung der Anforderungsprozesse für Zwischenablesung, Zwischenablesung - Insolvenz, Zwischenablesung mit Abrechnung, Zwischenablesung mit Abrechnung – Insolvenz und Zwischenabrechnung ohne Ablesung ist verwirrend und erklärungsbedürftig.
• Der Prozess beschreibt nicht nur die Anforderung einer Zwischenablesung bei Insolvenz, sondern auch bei Verlassenschaft. Dies geht jedoch aus dem Titel des Prozesses nicht hervor.
  

Der Prozessschritt „Ablesung löst das Übermitteln der Verbrauchsdaten aus“ sollte gestrichen werden, da hierzu kein Prozess existiert und mehrere Prozessschritte dahinter stehen.

Wir würden als Prozessschritte vorschlagen:

• Ablesung veranlassen und verarbeiten

• Verbrauchsdaten übermitteln (Format offen)

• Prozess beenden
  

• Der „Abschluss einer Rahmenvereinbarung über das Vorleistungsmodell“ sollte in den Punkt „Voraussetzung“ aufgenommen werden.
• Der Satz „Sofern es zwingende gesetzliche Grundlagen gibt, die eine explizite Bestätigung der Kostenübernahme für die Ablesung erfordern, ist das Feld „CPRequest – AssumptionOfCosts“ zu setzen.“ ist ungenau formuliert und wirft Fragen auf. Zudem ist nicht angeführt mit welchem Wert das Feld „CPRequest – AssumptionOfCosts“ zu befüllen ist.
• Generell ist anzumerken, dass die Verrechnung von Ablesekosten zwischen Netzbetreiber und Lieferant in der SNE-VO nicht vorgesehen ist.
• Die Trennung der Anforderungsprozesse für Zwischenablesung, Zwischenablesung - Insolvenz, Zwischenablesung mit Abrechnung, Zwischenablesung mit Abrechnung – Insolvenz und Zwischenabrechnung ohne Ablesung ist verwirrend und erklärungsbedürftig.
  

Der Prozessschritt „Ablesung löst das Übermitteln der Verbrauchsdaten aus“ sollte gestrichen werden, da hierzu kein Prozess existiert und mehrere Prozessschritte dahinter stehen.

Wir würden als Prozessschritte vorschlagen:

• Ablesung veranlassen und verarbeiten

• Verbrauchsdaten übermitteln (Format offen)

• Prozess beenden
  

• Der Prozess beschreibt nicht nur die Anforderung einer Zwischenablesung mit Abrechnung bei Insolvenz, sondern auch bei Verlassenschaft. Dies geht jedoch aus dem Titel des Prozesses nicht hervor.

• Der „Abschluss einer Rahmenvereinbarung über das Vorleistungsmodell“ sollte in den Punkt „Voraussetzung“ aufgenommen werden.

• Die Trennung der Anforderungsprozesse für Zwischenablesung, Zwischenablesung - Insolvenz, Zwischenablesung mit Abrechnung, Zwischenablesung mit Abrechnung – Insolvenz und Zwischenabrechnung ohne Ablesung ist verwirrend und erklärungsbedürftig

Der Prozessschritt „Ablesung löst das Übermitteln der Verbrauchsdaten aus“ sollte gestrichen werden, da hierzu kein Prozess existiert und mehrere Prozessschritte dahinter stehen.

Wir würden als Prozessschritte vorschlagen:

• Ablesung veranlassen und verarbeiten

• Verbrauchsdaten übermitteln (Format offen)

• Prozess beenden
  

• Wenn der „Abschluss einer Rahmenvereinbarung über das Vorleistungsmodell“ eine Voraussetzung für die Anwendung eines Prozesses ist, so sollte dies auch unter dem Punkt „Voraussetzungen“ aufgelistet sein.

• Der Satz „Sofern es zwingende gesetzliche Grundlagen gibt, die eine explizite Bestätigung der Kostenübernahme für die Ablesung erfordern, ist das Feld „CPRequest – AssumptionOfCosts“ mit dem Wert J zu füllen.“ ist ungenau formuliert und wirft Fragen auf.
• Generell ist anzumerken, dass die Verrechnung von Abrechnungskosten zwischen Netzbetreiber und Lieferant in der SNE-VO nicht vorgesehen ist.
• Die Trennung der Anforderungsprozesse für Zwischenablesung, Zwischenablesung - Insolvenz, Zwischenablesung mit Abrechnung, Zwischenablesung mit Abrechnung – Insolvenz und Zwischenabrechnung ohne Ablesung ist verwirrend und erklärungsbedürftig.
  

Betreffend Fehlercode 84 - kein Vorleistungsmodell:

Ist die Umstellung des Netzrechnungsempfängers auf Lieferant im Verwahrungsmodell nicht möglich?

Bitte im Text die Voraussetzungen ergänzen, dass hier eine unterfertigte Rahmenvereinbarung für das Vorleistungsmodell erforderlich ist.

Prozessschritt „Datenänderung beendet“ auf „Prozess beendet“ korrigieren, da auch  der erste Schritt „Start Prozess“ ist.

• Es ist nicht klar, was "Versorgungssicherheitsgründe" sind. Diese sind näher auszuführen oder es sind Verweise herzustellen.
  

Tippfehler im Diagramm

“Medlung bearbeiten“

„Kein (Schalt-) Vereinbarung vorhanden“

• Die Prozessbezeichnung ist auf „CP_REQ_DCS - Anforderung Abschaltung eines intelligenten Messgerätes“ zu ändern. Eine Fernabschaltung eines Digitalen Standardzählers (DSZ) ist selbst nach einem qualifizierten Mahnverfahren nicht möglich, da ein DSZ über keine Fernabschaltfunktion verfügt. Ohne Zustimmung des Kunden kann ein DSZ nicht auf ein Intelligentes Messgerät (IM) umkonfiguriert werden.
• Verweise auf das ElWOG (im ersten Absatz der Beschreibung sowie in Fristen) sollen detailliert angeführt sein.
• Bitte auch auf § 6 Abs 3 END-VO Bezug nehmen: "Abschaltungen von Anlagen von Haushaltskunden und Kleinunternehmen in Folge von Zahlungsverzug dürfen nicht am letzten Arbeitstag vor Wochenenden oder gesetzlichen Feiertagen vorgenommen werden."
• Die Nummerierung unter "Voraussetzungen" bitte prüfen.
  

Der Kunde hat beim Netzbetreiber die Option Out Smart Meter deklariert. Damit darf der Netzbetreiber keine Daten aufzeichnen. Es ist dem Netzbetreiber aber erlaubt, anlassbezogen oder für die jährliche Verbrauchsabrechnung den Ablesewert fernauszulesen. Genauso ist es zulässig sofern ein qualifiziertes Mahnverfahren entweder vom Energielieferanten oder vom Netzbetreiber durchgeführt wurde, die Abschaltung auszulösen. Sowohl der Energielieferant als auch der Netzbetreiber haben im qualifizierten Mahnverfahren die Verpflichtung den Kunden über die Konsequenzen bei Nichtzahlung aufzuklären. Die Schaltung wird entsprechend am Smart Dokument als auch im System abgebildet und kann daher auch historisch nachgewiesen werden. Die Vorgehensweise wäre auch dahingehend schlüssig da wir bei dem Prozess VZ ebenfalls die Schaltung von der Ferne durchführen. Beim VZ Prozess ist der Kunde so wie im qualifizierten Mahnverfahren betroffen da er nach wie vor Mieter / Eigentümer der Anlage ist allerdings seine vertraglichen Verpflichtungen nicht eingehalten hat.

Unklar ist folgende Aussage: Sollte der Zählpunkt den Device Type DSZ besitzen, so hat der Netzbetreiber die Aktivierung der Abschaltfunktion zu dokumentieren. Die Dokumentation wird bereits durch die Abschaltung erfüllt. Eine weitere Dokumentation würde zu einem Mehraufwand führen. Es ist auch unklar wie die Dokumentation erfolgen soll.

Fristen:

Prozess DV_CHG_OFF: bis 15 Uhr. Die Schaltung am Gerät darf bis 15 Uhr erfolgen. Erst nach Rückmeldung der Abschaltung über die Kommunikationssysteme an die Umsysteme und die Erfassung der Sperre wird der Prozess DV_CHG_OFF ausgelöst. Die Kommunikationsstrecke so wie die Erfassung in den Systemen erfordert ebenfalls Zeit und daher kann es vorkommen das der Prozess DV_CHG_OFF später als 15 Uhr ausgelöst wird.

Es wird ein Responsecode benötigt für den Fall das eine Schaltung bei einem Gerät mit zwei Zählpunkt betroffen ist. Wird die Abschaltung nur für einen Zählpunkt angefordert, ist...

Tippfehler im Diagramm

„Zähler bleibt ausgeschalten, weil zB beim NB ebenfalls im Qualifizierte Mahnverfahren“

"Kein (Schalt-) Vereinbarung vorhanden"

• Die Prozessbezeichnung ist auf „CP_REQ_RCS - Anforderung Wiedereinschaltung eines intelligenten Messgerätes“ zu ändern. Eine Wiedereinschaltung eines DSZ ist nicht möglich, da ein DSZ über keine Ferneinschaltfunktion verfügt. Ohne Zustimmung des Kunden kann ein DSZ nicht auf ein IM umkonfiguriert werden.
• Ein Verweis auf § 6 Abs 1 END-VO wäre hilfreich: "Der Verteilernetzbetreiber ist verpflichtet, dem Netzbenutzer die Wiederherstellung des Netzzugangs nach Abschaltung spätestens am nächsten Arbeitstag nach Wegfall der Vertragsverletzung durch den Netzbenutzer und unter der Voraussetzung der Kenntnis des Verteilernetzbetreibers über den Bestand eines aufrechten Liefervertrags bzw. nach Beauftragung durch den Lieferanten anzubieten und durchzuführen."
  

Unter Fristen wird folgendes definiert:

Die Bestätigung mit dem Prozess DV_CHG_ONR wird erst versendet wenn der Zähler die Entsperrung zurückmeldet.

Das steht im Widerspruch zu der Prozessbeschreibung DV_CHG_ONR. Hier wird der Prozess ausgelöst wenn der Zähler einschaltbereit gesetzt wird. Entsperrt ist das Gerät bei Status einschaltbereit physisch gesehen nicht! Erst nach der tatsächlichen Wiederinbetriebnahme am Gerät durch den Kunden ist die Entsperrung erfolgt.

• 100.000 Zählpunkte in einer XML Liste erscheint viel, da die XML Dateien meist in einem Rutsch verarbeitet werden. Hier könnte ein Speicherproblem entstehen!
  Die Anzahl sollte kleiner definiert und in der Prozessdokumentation festgelegt werden.

• Beispiel 5.3 in der Schemadokumentation MeteringPointList falsch:

- Ist der Empfänger der Lieferant, so kann dieser bei der Zählpunktprüfung nicht überprüfen, ob es sich tatsächlich um das 

  Netzgebiet des sendenden Netzbetreibers handelt. Der Lieferant kann nur prüfen, ob er diesen Kunden tatsächlich versorgt

- Der Prozessschritt „Datenänderung beendet“ ist unseres Erachtens nicht erforderlich, da hier lediglich eine Information

  übermittelt wird.

• Dieser Prozess ist vorteilhaft, da der Lieferant dem Kunden frühzeitig Angebote über neue Tarife zusenden kann. Die Forderung nach Kundenzustimmung für die Übermittlung von 1/4h Werten kann dann schon im Vorfeld erfüllt werden und nicht erst nachdem der Zähler schon eingebaut wurde. Der Prozess sollte verpflichtend sein.
  
• Sollten hier nicht auch alle bekannten Geräteinformationen mitgesendet werden und das Element MeteringPointData Pflicht sein?
• Die Fristen sollten klar definiert sein: Z.B.
  
  • spätestens 1 Tag nach Kundeninformation
  • Antwort 2 Tage

• Es wird angeregt diesen Prozess nicht als optional zu deklarieren.
  

• Generell ist zur Übermittlung von Nachweisdokumenten anzumerken, dass es sinnvoll wäre, die Nachweisdaten zu definieren, welche zur Glaubhaftmachung eines Nachweises notwendig sind – und nicht die Nachweisdokumente selbst (Audio-Files, Scans von schriftlichen Vollmachten, etc.) anzufordern. Die Anforderung der Nachweisdaten bzw. der Nachweisdokumente ist nur in begründeten Verdachtsfällen und auf Nachfrage zulässig.

• Es ist zu beachten, dass manche wechselspezifische Nachweise zwingend über die Wechselplattform zu übermitteln sind und diese Prozesse in der technischen Dokumentation der Wechselplattform definiert sind.

• Der Satz „Entweder als physische Datei oder aber auch zur Darlegung einer Willenserklärung“ in der Beschreibung wirft Fragen auf: Was ist eine physische Datei und in welchem Gegensatz steht dazu eine Willenserklärung?

• Falls Nachweisdokumente übermittelt werden, sollten auch Bilddateien wie jpg, gif oder bmp zulässig sein.

• Es gibt aus unserer Sicht keinen Grund, warum Nachweisdokumente nur 1 Jahr lang durch den Empfänger in Evidenz gehalten werden und danach neu übermittelt werden müssen.