Konsultation Customer Processes 2017/05

  
Beschreibung

Die Prozesskategorie „Customer Processes“ beschreiben eine Vielzahl von Datenaustausch-Prozesse die
benötigt, aber derzeit nicht oder nur unzureichend in den rechtlichen
Grundlagen beschrieben sind.



 



Die Umsetzung der „Customer Processes“ verfolgt über 25 Einzelprozesse mit folgende Zielen:



  • Der Datenabgleich aus Kapitel 10 der Sonstigen Marktregeln Strom
    wird in einer zeitgemäßen Form abgebildet

  • Derzeit liegen für die Sparte Gas keine Datenabgleichsprozesse
    vor. Diese wurden in die Customer Processes integriert

  • Anforderungsprozesse können automatisiert ablaufen (z.B.
    Zwischenlesung, Lastprofiländerung)

  • Im ElWOG erwähnte, aber nicht näher beschriebene Prozesse im
    Zusammenhang mit Smart Metering werden detailliert spezifiziert (z.B.
    Umstellung Abrechnungszyklus, Änderung des Messintervalls, Prepayment,
    Abschaltanforderung, etc.)

  • Umsetzung von Regelungen zum Datenaustausch über den
    Energiewirtschaftlichen Datenaustausch (EDA) – dazu wurden in Vereinbarung mit
    der E-Control und den Verrechnungsstellen entsprechende Möglichkeiten
    ausgearbeitet, welche in der zu konsultierenden Technischen Dokumentation
    angeführt sind.

    Der Datenaustausch über EDA ist für die Marktpartner kostenlos.














 
Fristen
Konsultation Beginn22.05.2017 
Stellungsnahmen bis03.07.2017 
Vorauss. Veröffentlichung01.10.2017 
Testphase ab01.04.2018 
Produktivsetzung01.06.2018 
Abschluss
EntscheidungDie Konsultation ist abgeschlossen.
Ab 1. Juni 2018 kommen ausschließlich die Prozesse in der Version 02.00 zur Anwendung.
Weitere Informationen finden Sie unter dem Menüpunkt "Prozesse"
 

Algemeine Anmerkungen zu der Konsultation


  
  

Betroffene Prozesse

  
  
  

CP_REQ_CMI (01.99) Anforderung auf Änderung des Mess-/Übertragungsintervalls

  
ProzessCP_REQ_CMI 
Version01.99 
BezeichnungAnforderung auf Änderung des Mess-/Übertragungsintervalls 
Gültig von22.05.2017 

Stellungnahmen

AT900559 C****r

 


AT008130 Feistritzwerke-STEWEAG GmbH C****r

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. 

 

Kommentar


 

1/4-h Werte müssen im Zähler gespeichert sein (ElWOG §§83, 84/1, IMA-VO). D.h eine rückwirkende Anforderung muss möglich sein.

AT004002 K****r

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)

...Weiterlesen

 

Kommentar


 

Die Prozessdiagramme werden laufend angepasst und es wird versucht einheitliche Formulierungen zu verwenden.
In Prozessen mit Beteiligung der Sparte Gas lautet die Bezeichnung Versorger.

AT902009 M****r

regiocom alle vertretenen Mandanten:

Allgemeine Anmerkungen zu den Customer Prozessen:


  • 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...

...Weiterlesen

 

Kommentar


 

Keine Änderung der Prozessnamen, da es sich um technische Namen in der Beziehung M2M handelt. In der Umsetzung können beliebige Bezeichnungen für Enduser ausgegeben werden.

Prinzipiell richtig, es soll jedoch nicht bei jeder kleinen Anpassung eine Schemaänderung ausgelöst werden. Dies würde eine Schemenflut verursachen, was dem Wunsch der ECA nach möglichst wenigen Schemen wiederspricht. Umsetzung durch Softwarelieferanten ist dadurch günstiger.

Wie bereits zum vorherigen Punkt angemerkt. Die Auflistung der RC wird auch bei den Wechselprozessen nicht mehr im Schema abgelegt. Die nötigen Validierungen sind in der Prozessbearbeitung (Eingang) zu implementieren.

In den Schemen sind bereits Beispiele enthalten. Auch in den Prozessen werden Beispiele, wenn nötig, angeführt.

Vorerst keine Anpassungen der Enumerations. Soll jedoch im Zuge einer größeren Schemaanpassung berücksichtigt werden.

In der elektronischen Rechnung wird ebenfalls ZIP verwendet. Vereinheitlichung zu den Marktprozessen ist jedoch anzustreben.

Die Sicherheit der Übermittlung ist durch EDA gewährleistet (techn. Acknowledge). Bei vielen Anforderungsprozessen ist eine Antwort nicht möglich, da diese über einen eigenen Prozess abgewickelt wird (Formfreie Übermittlung, MSCONS, Rechnung, …). Es sollen die praktischen Erfahrungen abgewartet werden.

MeteringIntervall anstelle des DeviceTypes im Anforderungs-Schema aufgenommen.

AT011002 A****u

Der Lieferant benötigt im Zuge der Umstellung des Messintervalls Istdaten für die Prognose. Wir ersuchen um Erweiterung des Punkt 4.0, Beschreibung, vorletzter Absatz wie folgt: „… Auf Grund dieser Umstellungen sendet der Netzbetreiber eine MasterData-Nachricht. Bei Umstellung des Messintervalls auf ¼-Stunden übermittelt der Netzbetreiber zeitgleich außerdem eine ConsumptionRecord-Nachricht mit ¼-Stunden-Werten der letzten verfügbaren 8 Wochen.“

 

Kommentar


 

Die derzeitge Anforderung von 5 Tagen in die Vergangenheit soll in der Startphase beibehalten werden. Diese stellt bereits einen Kompromiss zwischen NB und LIEF dar.

AT055000 switch Energievertriebsgesellschaft m.b.H. A****u

Der Lieferant benötigt im Zuge der Umstellung des Messintervalls Istdaten für die Prognose. Wir ersuchen um Erweiterung des Punkt 4.0, Beschreibung, vorletzter Absatz wie folgt: „… Auf Grund dieser Umstellungen sendet der Netzbetreiber eine MasterData-Nachricht. Bei Umstellung des Messintervalls auf ¼-Stunden übermittelt der Netzbetreiber zeitgleich außerdem eine ConsumptionRecord-Nachricht mit ¼-Stunden-Werten der letzten verfügbaren 8 Wochen.“

 

Kommentar


 

Die derzeitge Anforderung von 5 Tagen in die Vergangenheit soll in der Startphase beibehalten werden. Diese stellt bereits einen Kompromiss zwischen NB und LIEF dar.

AT011008 A****u

Der Lieferant benötigt im Zuge der Umstellung des Messintervalls Istdaten für die Prognose. Wir ersuchen um Erweiterung des Punkt 4.0, Beschreibung, vorletzter Absatz wie folgt: „… Auf Grund dieser Umstellungen sendet der Netzbetreiber eine MasterData-Nachricht. Bei Umstellung des Messintervalls auf ¼-Stunden übermittelt der Netzbetreiber zeitgleich außerdem eine ConsumptionRecord-Nachricht mit ¼-Stunden-Werten der letzten verfügbaren 8 Wochen.“

 

Kommentar


 

Die derzeitge Anforderung von 5 Tagen in die Vergangenheit soll in der Startphase beibehalten werden. Diese stellt bereits einen Kompromiss zwischen NB und LIEF dar.

AT109999 E-Control Austria J****r

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 Dok...

...Weiterlesen

 

Kommentar


 

Diese Stellungnahme zur gesicherten Verbindung wurde an die Entwickler der Seite weitergeleitet.

Es ist eine Selektion nach Status eines Prozesses bzw. Schemas möglich. Bei Prozessen soll die Filterung nach Grundlagen wieder ermöglicht werden.

Schaltprozesse für Kunden ohne intelligentes Messgerät wurden derzeit aufgrund der erhöhten Komplexität nicht umgesetzt, sind jedoch als mögliche zukünftige Prozesse vorgemerkt.

Die Trennung der Anforderungsprozesse für Ablesung und Abrechnung dient zur einfacheren Steuerung beim Empfänger, da vielfach unterschiedliche Stellen dafür zuständig sind.

Referenzierende Schemen sind immer Bestandteil der technischen Dokumentation.

Es wurde eine eigene Kategorie für Dokumente angelegt die nicht Teil der technischen Dokumentation ist (nicht konsultiert).

Links zu Namespace und eb:Location wurden deaktiviert

Für Fachausdrücke und Begriffe soll ein Glossar entstehen welches auf ebUtilites veröffentlicht wird.

Rückforderungsprozesse haben derzeit als Grundlage nur "Branchenvereinbarung" und sind nicht Teil der Konsultation.

Derzeitige Prozesse zur Anforderung von Lastprofiländerungen, Granularitäts- und Periodizitätsänderungen sind ausreichend.

Es wird versucht die referenzierenden Gesetze und Verordnungen in den Grundlagen zu erfassen.

Diese Stellungnahme zum Texteditor wurde an die Entwickler der Seite weitergeleitet.

Fristen werden klarer formuliert.

Zustimmungserklärung für 1/4-h Werte soll für ein Jahr bestehen bleiben (entspricht dem normalen Belieferungszeitraum). Es soll jedoch nicht alle Jahre eine neue Vollmacht angefordert werden. Die Neuübermittlung ist jedoch nur dann nötig wenn auch ein entsprechender Anforderungs- bzw. Änderungsprozess ausgeführt wird.

AT001000 Wiener Netze M****l

Fristen unklar:

Einerseits hat der Netzbetreiber 5 Arbeitstage ab Prozessdatum für die Umstellung, andererseits kann der Energielieferant 5 Arbeitstage rückwirkend die Anforderung senden. Somit müsste der Netzbetreiber am selben Tag den Prozess erledigen. Vorschlag: Die Umstellung seitens des Netzbetreibers ist mit Datum des Einlangen der Anforderung binnen 5 Arbeitstagen vorzunehmen.
 
Für die Umstellung wird eine Parametrierung am Zähler benötigt sofern die 1/4 Stunden Werte durch den Kundenwunsch beim Netzbetreiber nicht bereits aktiviert sind.

Es ist möglich, dass die Umstellung zum Prozessdatum nicht möglich ist - Zähler nicht kommunikativ. Weiters kann eine rückwirkende Parametrierung nicht durchgeführt werden. 
Somit sollte sich das Prozessdatum je nach Fall auf das Datum der erstmaligen Übermittlung der 1/4 Stunden Werte verschieben.

 

Kommentar


 

Fristen wurden klarer formuliert.
RC91 wurde ergänzt
1/4-h Werte müssen im Zähler gespeichert sein (ElWOG §§83, 84/1, IMA-VO). D.h eine rückwirkende Anforderung muss möglich sein.


  
  

CR_REQ_PT (01.99) Anfordern von Verbrauchsdaten (gem. DAVID Verordnung)

  
ProzessCR_REQ_PT 
Version01.99 
BezeichnungAnfordern von Verbrauchsdaten (gem. DAVID Verordnung) 
Gültig von22.05.2017 

Stellungnahmen

AT004000 W****r

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

 

Kommentar


 

Der Prozess zur Verbrauchsdatenermittlung ist in einer eigenen Konsultation behandelt worden.
Die Anpassungen im Prozessdiagramm zum Prozess CR_MSG in der Version 02.00 wurden vorgenommen.


  
  

MD_CHG_CP (01.99) Stammdatenänderung - Namensänderung

  
ProzessMD_CHG_CP 
Version01.99 
BezeichnungStammdatenänderung - Namensänderung 
Gültig von22.05.2017 

Stellungnahmen

AT008130 Feistritzwerke-STEWEAG GmbH C****r


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.


...Weiterlesen

 

Kommentar


 

Klarstellung in Prozessdokumentation 02.00 angeführt, dass nur eine Datenänderung diesen Prozess auslöst. Keine Weiterleitung an andere Marktteilnehmer, wenn im System keine Stammdatenänderung durchgeführt wird.

AT902009 M****r

regiocom:

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.

 

Kommentar


 

Die finale Bestätigung des WIES wird ab 10/2017 auf einen Arbeitstag vor Wechselstichtag verkürzt. Daher sollte es nur selten zu Abweichungen kommen.
Bei ANM wird die finale Bestätigung erst nach dem Stammdatenumbau versandt und sollte alle bis dahin aufgetretenen Änderungen beinhalten.
Derzeit besteht die Möglichkeit durch den Lieferanten über den Prozess MD_REQ_GN die Stammdaten anzufordern.
Die ersten Erfahrungen mit MD sollen abgewartet werden und danach können derartige Anpassungen vorgenommen werden.

AT004000 W****r

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

AT109999 E-Control Austria J****r

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

 

Kommentar


 

Eine prüfung der datenschutzrechtlich relevanten Aspekte erfolgt innerhalb eines separaten Projekts im Herbst 2018.

Grundsätzlich werden keine Daten übermittelt, die nicht für einen reibungslosen Ablauf zwingend erforderlich sind.

AT001000 Wiener Netze M****l


  
  

MD_CHG_DA (01.99) Stammdatenänderung - Änderung der Lieferadresse

  
ProzessMD_CHG_DA 
Version01.99 
BezeichnungStammdatenänderung - Änderung der Lieferadresse 
Gültig von22.05.2017 

Stellungnahmen

AT008130 Feistritzwerke-STEWEAG GmbH C****r

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.


AT902009 M****r

regiocom:

  • 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

 

Kommentar


 

Die Bezeichnung ZIP ist gleich wie bei der elektronischen Rechnung gewählt.

Finale Bestätigung des WIES wird ab 10/2017 auf einen Arbeitstag vor Wechselstichtag verkürzt. Daher sollte es nur selten zu Abweichungen kommen.
Bei ANM wird die finale Bestätigung erst nach dem Stammdatenumbau versandt und sollte alle bis dahin aufgetretenen Änderungen beinhalten.
Derzeit besteht die Möglichkeit durch den Lieferanten über den Prozess MD_REQ_GN die Stammdaten anzufordern. Erfahrungen mit MD sollen vorerst abgewaretet werden.

Erfahrungen mit MD abwarten.

AT004000 W****r

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

 

Kommentar


 

Die Anpassung des Prozessdiagramms wurde vorgenommen.

Hinsichtlich Bestätigung der Adressänderung sollen vorerst Erfahrungen abgewartet werden. Bei den damaligen Diskussionen wurde nur bei der Namensänderung die Bestätigung der durchgeführten Änderungen eingefordert. Hinsichtlich Adressbezeichnung müsste eine generelle Normierung der Straßen und Ortsbezeichnungen erfolgen. LIEF sendet Teststr., Netzbetreiber übernimmt die Änderung mit Teststraße. Ist eine positive oder negative RM erforderlich oder eine weitere Übermittlung von Stammdaten?

AT109999 E-Control Austria J****r

  • 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?

 

Kommentar


 

Prüfung der datenschutzrelevanten Inhalte und Abläufe erfolgt im Herbst 2018

Nachweisdokument ist nur für Namensänderung vorgesehen (Urkunde, Firmenbuch, …).
Für Adressänderung wurde vorerst kein Bedarf eines Nachweisdokumentes ermittelt.

AT001000 Wiener Netze N****r

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.

 

Kommentar


 

Zusatzdaten zur Adresse wurden als prozessauslösend (Schema und Doku) aufgenommen.

Hinsichtlich Bestätigung der Adressänderung sollen vorerst Erfahrungen abgewartet werden. Bei den damaligen Diskussionen wurde nur bei der Namensänderung die Bestätigung der durchgeführten Änderungen eingefordert. Hinsichtlich Adressbezeichnung müsste eine generelle Normierung der Straßen und Ortsbezeichnungen erfolgen. LIEF sendet Teststr., Netzbetreiber übernimmt die Änderung mit Teststraße. Ist eine positive oder negative RM erforderlich oder eine weitere Übermittlung von Stammdaten?


  
  

MD_CHG_PD (01.99) Stammdatenänderung - Änderung von Zählpunktdaten

  
ProzessMD_CHG_PD 
Version01.99 
BezeichnungStammdatenänderung - Änderung von Zählpunktdaten 
Gültig von22.05.2017 

Stellungnahmen

AT001002 T****r

Seitens WE wird auch eine Übermittlung des Anschlusswertes in kwh – entsprechend dem vereinbarten Ausmaß der Netznutzung – gefordert. Diese Änderung sind im Masterdata zu den prozessauslösenden Werten hinzuzufügen. 

 

Kommentar


 

Eine Schemaänderung hinsichtlich der Übermittlung des Strombezugsrechts (in kW bzw. kWh) soll derzeit nicht vorgenommen werden. Da diese Information von keinem weiteren Unternehmen benötigt wird, soll hier eine bilaterale Vereinbarung zur Übermittlung getroffen werden. Es könnte z.B. der Abschnitt AdditionalData im Schema MasterData verwendet werden.

AT902009 M****r

regiocom:

  • 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.

 

Kommentar


 

Finale Bestätigung des WIES wird ab 10/2017 auf einen Arbeitstag vor Wechselstichtag verkürzt. Daher sollte es nur selten zu Abweichungen kommen.
Bei ANM wird die finale Bestätigung erst nach dem Stammdatenumbau versandt und sollte alle bis dahin aufgetretenen Änderungen beinhalten.
Derzeit besteht die Möglichkeit durch den Lieferanten über den Prozess MD_REQ_GN die Stammdaten anzufordern. Erfahrungen mit MD abwarten.
Die tägliche Übermittlung der Daten wurde als Empfehlung in der Prozessdoku eingefügt
Der Hinweis in Bezug auf Endlosschleifen wurde in Prozessdoku entfernt
MasterData - EnergyDirection in Prozessdoku und Schema nicht mehr prozessauslösend
ODER-Verknüpfung zwischen ElectricitySpecificData und GasSpecificData in MeteringPointData wurde im Schema aufgenommen

AT004000 W****r

Im Prozessdiagramm „ZP im Netzgebiet bzw. vom Empfänger versorgt“ bitte Korrektur auf „ZP vom Empfänger versorgt“. Bezeichnung Header „nur“ überflüssig bei „nur Netzbetreiber -> Lieferanten“

 

Kommentar


 

Anpassungen im Prozessdiagramm wurden vorgenommen.

AT109999 E-Control Austria J****r

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

 

Kommentar


 

Prüfung der datenschutzrelevanten Inhalte und Abläufe erfolgt im Herbst 2018


  
  

MD_CHG_BD (01.99) Stammdatenänderung - Änderung der Abrechnungsdaten

  
ProzessMD_CHG_BD 
Version01.99 
BezeichnungStammdatenänderung - Änderung der Abrechnungsdaten 
Gültig von22.05.2017 

Stellungnahmen

AT902009 M****r

regiocom:
auch hier: 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.

 

Kommentar


 

Finale Bestätigung des WIES wird ab 10/2017 auf einen Arbeitstag vor Wechselstichtag verkürzt. Daher sollte es nur selten zu Abweichungen kommen.
Bei ANM wird die finale Bestätigung erst nach dem Stammdatenumbau versandt und sollte alle bis dahin aufgetretenen Änderungen beinhalten.
Derzeit besteht die Möglichkeit durch den Lieferanten über den Prozess MD_REQ_GN die Stammdaten anzufordern. Erfahrungen mit MD abwarten.

AT004000 W****r

Im Prozessdiagramm „ZP im Netzgebiet bzw. vom Empfänger versorgt“ bitte Korrektur auf „ZP vom Empfänger versorgt“. Bezeichnung Header „nur“ überflüssig bei „nur Netzbetreiber -> Lieferanten“

 

Kommentar


 

Anpassung im Prozessdiagramm wurde vorgenommen.

AT109999 E-Control Austria J****r

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

 

Kommentar


 

Prüfung der datenschutzrelevanten Inhalte und Abläufe erfolgt im Herbst 2018


  
  

DV_CHG_ONR (01.99) Geräte Verbindungsstatus einschaltbereit

  
ProzessDV_CHG_ONR 
Version01.99 
BezeichnungGeräte Verbindungsstatus einschaltbereit 
Gültig von22.05.2017 

Stellungnahmen


  
  

DV_CHG_OFF (01.99) Geräte Verbindungsstatus ausgeschaltet

  
ProzessDV_CHG_OFF 
Version01.99 
BezeichnungGeräte Verbindungsstatus ausgeschaltet 
Gültig von22.05.2017 

Stellungnahmen

AT109999 E-Control Austria J****r

  • Dem verwendeten Prozessschritt der Ablehnung ist kein Schema zugewiesen.

 

Kommentar


 

Schema wurde zugewiesen


  
  

MD_REQ_IR (01.99) Anforderung der Rechnungsadresse

  
ProzessMD_REQ_IR 
Version01.99 
BezeichnungAnforderung der Rechnungsadresse 
Gültig von22.05.2017 

Stellungnahmen

AT004002 K****r


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




 

Kommentar


 

Prüfung im Diagramm nicht nötig, da Rechnungsadresse gesetzlicher Rechnungsbestandteil ist und somit zu übermitteln ist.


  
  

MD_REQ_GN (01.99) Anforderung der aktuellen Stammdaten

  
ProzessMD_REQ_GN 
Version01.99 
BezeichnungAnforderung der aktuellen Stammdaten 
Gültig von22.05.2017 

Stellungnahmen

AT900559 C****r

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. 


...Weiterlesen

 

Kommentar


 

Soll in nächster Schemaänderung berücksichtigt werden. Die Erstellung eines neuen Anforderungsprozesses wurde vorgemerkt (ähnlich wie CP_REQ_LPT).

AT001002 T****r

Seitens WE wird auch eine Übermittlung des Anschlusswertes in kwh – entsprechend dem vereinbarten Ausmaß der Netznutzung - gewünscht. Dieser Wert soll im Masterdata-Schema ergänzt werden.

 

Kommentar


 

Eine Schemaänderung für die Übermittlung des Strombezugsrechts (in kW bzw. kWh) wird nicht vorgenommen. Umsetzungsvorschlag: Treffen einer bilateraler Vereinbarung zur Übermittlung. Es könnte z.B. der Abschnitt AdditionalData im Schema MasterData verwendet werden.

AT011008 A****u

Es gibt einen Widerspruch bezüglich des Prozessdatums. Laut 4.0, Beschreibung, ist Prozessdatum immer das Tagesdatum, laut 7.0, Fristen, darf man in der Anfrage ein Prozessdatum bis zu 3 Monate in die Vergangenheit wählen. Wir würden das Tagesdatum bevorzugen

 

Kommentar


 

Änderung erfolgt. Die Anfrage liefert als Ergebnis den Ist-Stand der Daten des Marktpartners. Das Prozessdatum entspricht sowohl bei der Anforderung als auch bei der Antwort dem Tagesdatum


  
  

CP_REQ_LPT (01.99) Anforderung einer Lastprofiländerung

  
ProzessCP_REQ_LPT 
Version01.99 
BezeichnungAnforderung einer Lastprofiländerung 
Gültig von22.05.2017 

Stellungnahmen

AT902009 M****r

regiocom:
Antwort Nachricht notwendig.

 

Kommentar


 

Die Antwort erfolgt via Übermittlung MasterData (Aufgrund Änderung des Lastprofils) oder mittels Ablehnung.

AT011002 A****u

Bei Punkt 7.0, Fristen, sollte am Ende hinzugefügt werden: „Der NB hat in angemessener Zeit eine Lastprofiländerung durchzuführen oder eine Ablehnung zu schicken. Das Fehlen einer konkreten Frist darf nicht zum Ignorieren von Anfragen führen.“

 

Kommentar


 

Änderung "Fristen" unter ergänzende Informationen: Da unter Umständen umfangreiche Datenerhebungen und der Einbau von Messungen zur Verifizierung der Lieferanten/Versorgeranfrage notwendig sind, ist der Netzbetreiber für die Änderung des Lastprofiles an keine konkreten Fristen gebunden. Die Änderung ist aber auf jeden Fall nach einem positiven Entscheid durchzuführen oder im Falle eines negativen Entscheides (auf Grund einer Kontrollmessung) abzulehnen.

AT055000 switch Energievertriebsgesellschaft m.b.H. A****u

Bei Punkt 7.0, Fristen, sollte am Ende hinzugefügt werden: „Der NB hat in angemessener Zeit eine Lastprofiländerung durchzuführen oder eine Ablehnung zu schicken. Das Fehlen einer konkreten Frist darf nicht zum Ignorieren von Anfragen führen.“

 

Kommentar


 

Änderung "Fristen" unter ergänzende Informationen: Da unter Umständen umfangreiche Datenerhebungen und der Einbau von Messungen zur Verifizierung der Lieferanten/Versorgeranfrage notwendig sind, ist der Netzbetreiber für die Änderung des Lastprofiles an keine konkreten Fristen gebunden. Die Änderung ist aber auf jeden Fall nach einem positiven Entscheid durchzuführen oder im Falle eines negativen Entscheides (auf Grund einer Kontrollmessung) abzulehnen.

AT011008 A****u

Bei Punkt 7.0, Fristen, sollte am Ende hinzugefügt werden: „Der NB hat in angemessener Zeit eine Lastprofiländerung durchzuführen oder eine Ablehnung zu schicken. Das Fehlen einer konkreten Frist darf nicht zum Ignorieren von Anfragen führen.““

 

Kommentar


 

Änderung "Fristen" unter ergänzende Informationen: Da unter Umständen umfangreiche Datenerhebungen und der Einbau von Messungen zur Verifizierung der Lieferanten/Versorgeranfrage notwendig sind, ist der Netzbetreiber für die Änderung des Lastprofiles an keine konkreten Fristen gebunden. Die Änderung ist aber auf jeden Fall nach einem positiven Entscheid durchzuführen oder im Falle eines negativen Entscheides (auf Grund einer Kontrollmessung) abzulehnen.

AT004000 W****r

Nach der Entscheidung „ZP OK?/ Beliefert?“ ist aus unserer Sicht ein Prozessschritt  „Datenänderungen prüfen“ notwendig, da eine Entscheidung ohne Prüfung nicht sinnvoll ist.


  
  

CP_REQ_MRD (01.99) Anforderung einer Zwischenablesung

  
ProzessCP_REQ_MRD 
Version01.99 
BezeichnungAnforderung einer Zwischenablesung 
Gültig von22.05.2017 

Stellungnahmen

AT004002 K****r

- 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

 

Kommentar


 

Die Überarbeitung des Prozessdiagrammes erfolgt im Zuge der Prozessüberarbeitung aufgrund Anforderung für Stromkosteninfo.

Die fehlenden Fristen wurden ergänzt

AT004000 W****r


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).




...Weiterlesen

 

Kommentar


 

Prozessrelevanz für DSZ/NONSMART in der Beschreibung ergänzt.
Die Definition der Verbrauchsdatenübermittlung für NONSMART und DSZ ist nicht Bestandteil dieses Anforderungsprozesses und kann daher wie bisher formfrei erfolgen.

AT109999 E-Control Austria J****r

  • 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.

...Weiterlesen

 

Kommentar


 

Mit der Bestätigung verpflichtet sich der Lieferant ggf. verrechnete Ablesekosten zu übernehmen. Die Entscheidung einer Weiterverrechnung an den Kunden obliegt dem Lieferant.

Die Trennung sind erforderlich um auch in nicht "hochautomatisierten" Softwaresystemen bereits auf Prozessebene zu erkennen um welche Anforderung es sich handelt da diese in den Unternehmen in unterschiedlichen Bereichen bearbeitet werden.

AT001000 Wiener Netze M****l

Bei diesem Prozess werden die Verbrauchsdaten erst mit der nächsten Abrechnung des Netzbetreibers über MSCONS übermittelt.

Sollen die Verbrauchsdaten innerhalb der Durchführung des Prozesses übermittelt werden, muss noch geklärt werden, in welcher Form dies erfolgen soll. MSCONS übermittelt derzeit nur abgerechnete Verbrauchsdaten.

 

Kommentar


 

Die Definition der Verbrauchsdatenübermittlung für NONSMART und DSZ ist nicht Bestandteil dieses Anforderungsprozesses und kann daher wie bisher formfrei erfolgen.


  
  

CP_REQ_MDI (01.99) Anforderung einer Zwischenablesung - Insolvenz

  
ProzessCP_REQ_MDI 
Version01.99 
BezeichnungAnforderung einer Zwischenablesung - Insolvenz 
Gültig von22.05.2017 

Stellungnahmen

AT004002 K****r

- 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“

...Weiterlesen

 

Kommentar


 

Die Überarbeitung des Prozessdiagrammes erfolgt im Zuge der Prozessüberarbeitung aufgrund Anforderung für Stromkosteninfo.

Die fehlenden Fristen wurden ergänzt

AT004000 W****r

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).




...Weiterlesen

 

Kommentar


 

Prozessrelevanz für DSZ/NONSMART in der Beschreibung ergänzt.
Die Definition der Verbrauchsdatenübermittlung für NONSMART und DSZ ist nicht Bestandteil dieses Anforderungsprozesses und kann daher wie bisher formfrei erfolgen.

AT109999 E-Control Austria J****r

  • 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.

 

Kommentar


 

Die Trennung sind erforderlich um auch in nicht "hochautomatisierten" Softwaresystemen bereits auf Prozessebene zu erkennen um welche Anforderung es sich handelt da diese in den Unternehmen in unterschiedlichen Bereichen bearbeitet werden.

Verlassenschaft wurde aus der Prozessbeschreibung entfernt.

AT001000 Wiener Netze M****l

Bei diesem Prozess werden die Verbrauchsdaten erst mit der nächsten Abrechnung des Netzbetreibers über MSCONS übermittelt.

Sollen die Verbrauchsdaten innerhalb der Durchführung des Prozesses übermittelt werden, muss noch geklärt werden, in welcher Form dies erfolgen soll. MSCONS übermittelt derzeit nur abgerechnete Verbrauchsdaten.

 

Kommentar


 

Die Definition der Verbrauchsdatenübermittlung für NONSMART und DSZ ist nicht Bestandteil dieses Anforderungsprozesses und kann daher wie bisher formfrei erfolgen.


  
  

CP_REQ_MRB (01.99) Anforderung einer Zwischenablesung mit Abrechnung

  
ProzessCP_REQ_MRB 
Version01.99 
BezeichnungAnforderung einer Zwischenablesung mit Abrechnung 
Gültig von22.05.2017 

Stellungnahmen

AT004000 W****r

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

...Weiterlesen

 

Kommentar


 

Die Definition der Verbrauchsdatenübermittlung ist nicht Bestandteil dieses Anforderungsprozesses und erfolgt entsprechend der Versendung von Verbrauchsdaten nach einer Abrechnungsdurchführung.

AT109999 E-Control Austria J****r

  • 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.

...Weiterlesen

 

Kommentar


 

Voraussetzungen wurden ergänzt.
Mit der Bestätigung verpflichtet sich der Lieferant ggf. verrechnete Ablesekosten zu übernehmen. Die Entscheidung einer Weiterverrechnung an den Kunden obliegt dem Lieferant.

Die Trennung sind erforderlich um auch in nicht "hochautomatisierten" Softwaresystemen bereits auf Prozessebene zu erkennen um welche Anforderung es sich handelt da diese in den Unternehmen in unterschiedlichen Bereichen bearbeitet werden.


  
  

CP_REQ_MBI (01.99) Anforderung einer Zwischenablesung mit Abrechnung - Insolvenz

  
ProzessCP_REQ_MBI 
Version01.99 
BezeichnungAnforderung einer Zwischenablesung mit Abrechnung - Insolvenz 
Gültig von22.05.2017 

Stellungnahmen

AT004002 K****r

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

 

Kommentar


 

Beschreibung wurde entsprechend angepasst

AT004000 W****r

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

...Weiterlesen

 

Kommentar


 

Die Definition der Verbrauchsdatenübermittlung ist nicht Bestandteil dieses Anforderungsprozesses und erfolgt entsprechend der Versendung von Verbrauchsdaten nach einer Abrechnungsdurchführung.

AT109999 E-Control Austria J****r

  • 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

     

    Kommentar


     

    Voraussetzungen wurden ergänzt.
    Verlassenschaft wurde aus Beschreibung entfernt.

    Die Trennung sind erforderlich um auch in nicht "hochautomatisierten" Softwaresystemen bereits auf Prozessebene zu erkennen um welche Anforderung es sich handelt da diese in den Unternehmen in unterschiedlichen Bereichen bearbeitet werden.

    AT001000 Wiener Netze N****r

    Der Netzbetreiber kann vor dem Energielieferanten Kenntnis über eine Insolvenz erlangen und leitet seine notwendigen Schritte ein. Der Netzbetreiber hat aber keine Möglichkeit den in Vorleistung befindlichen Energielieferanten davon in Kenntnis zu setzen. Hier sollte noch eine Lösung für die Kommunikation ausgehend vom Netzbetreiber angedacht werden.

     

    Kommentar


     

    Dieser Prozess ist nicht vorgesehen um den NB über eine Insolvenz zu informieren sondern regelt lediglich vom Lief gegebenfalls benötigte Abrechnung.


      
      

    CP_REQ_BIL (01.99) Anforderung einer Zwischenabrechnung ohne Ablesung

      
    ProzessCP_REQ_BIL 
    Version01.99 
    BezeichnungAnforderung einer Zwischenabrechnung ohne Ablesung 
    Gültig von22.05.2017 

    Stellungnahmen

    AT001002 T****r

    Beim Energielieferant melden sich Kunden oft mit einem selbst abgelesenen Zählerstand. Daher soll analog der ZUEM im Wechselprozess auch bei diesem Prozess eine Zählerstandsübermittlung durch den Energielieferant möglich sein.

    AT004000 W****r

    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

    ...Weiterlesen

     

    Kommentar


     

    Die Definition der Verbrauchsdatenübermittlung ist nicht Bestandteil dieses Anforderungsprozesses und erfolgt entsprechend der Versendung von Verbrauchsdaten nach einer Abrechnungsdurchführung.

    AT109999 E-Control Austria J****r

    • 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.

    ...Weiterlesen

     

    Kommentar


     

    Voraussetzungen wurden ergänzt.

    Die Trennung sind erforderlich um auch in nicht "hochautomatisierten" Softwaresystemen bereits auf Prozessebene zu erkennen um welche Anforderung es sich handelt da diese in den Unternehmen in unterschiedlichen Bereichen bearbeitet werden.


      
      

    CP_REQ_GIR (01.99) Anforderung auf Änderung des Netzrechnungsempfängers

      
    ProzessCP_REQ_GIR 
    Version01.99 
    BezeichnungAnforderung auf Änderung des Netzrechnungsempfängers 
    Gültig von22.05.2017 

    Stellungnahmen

    AT008130 Feistritzwerke-STEWEAG GmbH C****r

    Betreffend Fehlercode 84 - kein Vorleistungsmodell:

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


     

    Kommentar


     

    Das Verwahrungsmodell wird nicht gesondert erwähnt, da es nach derzeitigem Wissensstand bei keinem Lieferanten in Ö mehr in Verwendung ist.

    AT001002 T****r

    Dieser Request soll auch vom NB angestossen werden können.

     

    Kommentar


     

    Anforderung durch NB muss noch geklärt werden (ist in Rahmenvereinbarung Vorleistungsmodell so vorgesehen)
    Anforderung durch NB betrifft nur Auflösung der gemeinsamen Rechnungslegung. Eine Zuordnung der gemeinsamen Rechnungslegung durch den NB ist nicht möglich.
    Der Umbau dieses Prozesses hat größere Auswirkungen, die in dieser Konsultation nicht mehr berücksichtigt werden können. Eine Anpassung ist jedoch so rasch wie möglich vorzunehmen.

    AT004000 W****r

    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.

     

    Kommentar


     

    Voraussetzungen ergänzt und Prozessdiagramm geändert.


      
      

    CP_REQ_CBC (01.99) Anforderung auf Änderung Abrechnungszyklus

      
    ProzessCP_REQ_CBC 
    Version01.99 
    BezeichnungAnforderung auf Änderung Abrechnungszyklus 
    Gültig von22.05.2017 

    Stellungnahmen

    AT902009 M****r

    regiocom:
    Antwort als Bestätigung notwendig.

     

    Kommentar


     

    Die Antwort erfolgt durch MasterData MD_CHG_BD

    AT004000 W****r

    Eine Voraussetzung ist u.a., dass der Lieferant Netzrechnungsempfänger ist => korrekt, falls ja, muss dies bei „Zählpunkt prüfen“ zusätzlich geprüft werden, ansonsten sind die Voraussetzungen zu korrigieren.

     

    Kommentar


     

    Im Prozessdiagramm aufgenommen


      
      

    CP_REQ_APR (01.99) Anforderung Aktivierung Prepaymentverfahren

      
    ProzessCP_REQ_APR 
    Version01.99 
    BezeichnungAnforderung Aktivierung Prepaymentverfahren 
    Gültig von22.05.2017 

    Stellungnahmen

    AT004000 W****r

    Tippfehler -> Keine (Schalt-) Vereinbarung vorhanden

     

    Kommentar


     

    Beschreibung korrigiert

    AT109999 E-Control Austria J****r

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

     

    Kommentar


     

    Versorgungssicherheitsgrund in den Voraussetzungen näher definiert.


      
      

    CP_REQ_DPR (01.99) Anforderung Deaktivierung Prepaymentverfahren

      
    ProzessCP_REQ_DPR 
    Version01.99 
    BezeichnungAnforderung Deaktivierung Prepaymentverfahren 
    Gültig von22.05.2017 

    Stellungnahmen


      
      

    CP_REQ_DCS (01.99) Anforderung Abschaltung eines intelligenten Messgerätes, bzw. eines DSZ

      
    ProzessCP_REQ_DCS 
    Version01.99 
    BezeichnungAnforderung Abschaltung eines intelligenten Messgerätes, bzw. eines DSZ 
    Gültig von22.05.2017 

    Stellungnahmen

    AT004002 K****r

    In diesem Prozess erfolgt die Prüfung der technischen Anforderungen erst nach sonstiger Überprüfung (Zähler bereits ausgeschaltet). Die Ablehnung erfolgt in den meisten Prozessen einheitlich über eine Prozesslinie; in diesem Prozess jedoch in mehreren voneinander getrennten – jedoch eigentlich inhaltlich gemeinsamen – Ablehnungsprozessen.

     

    Kommentar


     

    Keine prozessuale Auswirkung. Dient nur der Übersichtlichkeit des Prozessdiagrammes um kreuzende Linien zu vermeiden.

    AT001002 T****r

    Eine zusätzliche Rückbestätigung nach Prüfung DSZ wird seitens WE als nicht sinnvoll erachtet und soll entfallen. Stattdessen wird gefordert, dass die Anforderung einer Abschaltung nach 12:00 Uhr erfolgen kann, da auf Lieferantenseite noch die Bearbeitung der Zahlungseingänge des laufenden Tages abgearbeitet werden müssen.

     

    Kommentar


     

    Die Fristen werden vorerst belassen. Aufgrund von Erfahrungswerten in der realen Abwicklung, können Prozessanpassungen zukünftig erfolgen.

    AT004000 W****r

    Tippfehler im Diagramm

    “Medlung bearbeiten“

    „Kein (Schalt-) Vereinbarung vorhanden“

     

    Kommentar


     

    Tippfehler wurden korrigiert.

    AT003100 LINZ STROM Netz GmbH

    Aus Sicht der LINZ STROM Netz GmbH (LSN) ist die Prozessbezeichnung auf "Anforderung Abschaltung eines intelligenten Messgerätes" zu ändern. Der Zusatz "bzw. eines DSZ" ist für LSN nicht erforderlich, da bei Vorliegen einer opt out-Vereinbarung mit dem Kunden (Parametrierung des Zählers als DSZ) entsprechend den Vorgaben der Definition in den SoMa Kap.1 jedenfalls keine Fernschaltung vorgenommen wird.

     

    Kommentar


     

    Prozessbezeichnung korrigiert, siehe dazu auch Stellungnahme der ECA.

    AT109999 E-Control Austria J****r

    • 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.

     

    Kommentar


     

    Änderung der Prozessbezeichnung erfolgt.
    Verweis auf § ElWOG und END-VO wurden in der Beschreibung und Fristen eingefügt.
    Nummerierung "Voraussetzungen" wurde korrigiert.

    AT001000 Wiener Netze N****r

    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 Abschaltu...

    ...Weiterlesen

     

    Kommentar


     

    Siehe Stellungnahme ECA


      
      

    CP_REQ_RCS (01.99) Anforderung Wiedereinschaltung eines intelligenten Messgerätes, bzw. eines DSZ

      
    ProzessCP_REQ_RCS 
    Version01.99 
    BezeichnungAnforderung Wiedereinschaltung eines intelligenten Messgerätes, bzw. eines DSZ 
    Gültig von22.05.2017 

    Stellungnahmen

    AT004002 K****r

    In diesem Prozess erfolgt die Prüfung der technischen Anforderungen erst nach sonstiger Überprüfung (Zähler bleibt ausgeschaltet). Die Ablehnung erfolgt in den meisten Prozessen einheitlich über eine Prozesslinie; in diesem Prozess jedoch in mehreren voneinander getrennten – jedoch eigentlich inhaltlich gemeinsamen – Ablehnungsprozessen.

     

    Kommentar


     

    Keine prozessuale Auswirkung. Dient nur der Übersichtlichkeit des Prozessdiagrammes um kreuzende Linien zu vermeiden.

    AT004000 W****r

    Tippfehler im Diagramm

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

    "Kein (Schalt-) Vereinbarung vorhanden"

     

    Kommentar


     

    Tippfehler korrigiert

    AT003100 LINZ STROM Netz GmbH

    Aus Sicht der LINZ STROM Netz GmbH (LSN) ist die Prozessbezeichnung auf "Anforderung Wiedereinschaltung eines intelligenten Messgerätes" zu ändern. Der Zusatz "bzw. eines DSZ" ist für LSN nicht erforderlich, da bei Vorliegen einer opt out-Vereinbarung mit dem Kunden (Parametrierung des Zählers als DSZ) entsprechend den Vorgaben der Definition in den SoMa Kap.1 jedenfalls keine Fernschaltung vorgenommen wird.

     

    Kommentar


     

    Siehe dazu Stellungnahme ECA

    AT109999 E-Control Austria J****r

    • 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."

     

    Kommentar


     

    Prozessbezeichnung wurde geändert, Verweis END-VO wurde eingefügt.

    AT001000 Wiener Netze N****r

    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.


     

    Kommentar


     

    Formulierung in der Prozessbeschreibung und den Fristen wurde angepasst "... wenn der Zähler die Einschaltbereitschaft zurückmeldet (dh der Zähler kann durch den Kunden manuell freigegeben werden)"


      
      

    PDL_MSG (01.99) Senden der Zählpunktliste

      
    ProzessPDL_MSG 
    Version01.99 
    BezeichnungSenden der Zählpunktliste 
    Gültig von22.05.2017 

    Stellungnahmen

    AT902009 M****r

    • 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:
    <NumberOfMessages>2014-08-13</NumberOfMessages>
    <CurrentMessageNumber>2014-08-13</CurrentMessageNumber>
    Hier sollte auch nochmal klar gestellt werden, was in den Feldern stehen soll und unbedingt NumberOfMessages korrekt mit der Anzahl der Nachrichten zu füllen ist.



     

    Kommentar


     

    Hinsichtlich Größe sollen vorerst Erfahrungen gesammelt werden.

    Beispiel in Schemadoku wird angepasst.


      
      

    MD_ANN_DT (01.99) Vorabinformation über geplanten Smart Meter Einbau

      
    ProzessMD_ANN_DT 
    Version01.99 
    BezeichnungVorabinformation über geplanten Smart Meter Einbau 
    Gültig von22.05.2017 

    Stellungnahmen

    AT004002 K****r

    - 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.




    ...Weiterlesen

     

    Kommentar


     

    Prozessdiagramm angepasst

    AT001002 T****r

    Eine Information über den geplanten Einbau von Smart Metern soll für alle Netzbetreiber verpflichtend sein.

     

    Kommentar


     

    Der Lieferant wird nach dem Einbau ohnehin informiert. Es sollen Erfahrungen hinsichtlich dieses Prozesses gesammelt werden. Er bleibt vorerst optional.

    AT902009 M****r

    regiocom:

    • 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

     

    Kommentar


     

    Der Lieferant wird nach dem Einbau ohnehin informiert. Es sollen Erfahrungen hinsichtlich dieses Prozesses gesammelt werden. Er bleibt vorerst optional.

    Vorerst keine Ergänzungen hinsichtlich Fristen da optional.

    AT011002 A****u

    Der Prozess muss verpflichtend sein, optional ist nicht ausreichend. Nach welchen Kriterien wird entschieden, ob die Nachricht übermittelt wird oder nicht?

     

    Kommentar


     

    Der Lieferant wird nach dem Einbau ohnehin informiert. Es sollen Erfahrungen hinsichtlich dieses Prozesses gesammelt werden. Er bleibt vorerst optional.

    Netzbetreiber entscheidet hinsichtlich Übermittlung.

    AT055000 switch Energievertriebsgesellschaft m.b.H. A****u

    Der Prozess muss verpflichtend sein, optional ist nicht ausreichend. Nach welchen Kriterien wird entschieden, ob die Nachricht übermittelt wird oder nicht?

     

    Kommentar


     

    Der Lieferant wird nach dem Einbau ohnehin informiert. Es sollen Erfahrungen hinsichtlich dieses Prozesses gesammelt werden. Er bleibt vorerst optional.

    Netzbetreiber entscheidet hinsichtlich Übermittlung.

    AT011008 A****u

    Der Prozess muss verpflichtend sein, optional ist nicht ausreichend. Nach welchen Kriterien wird entschieden, ob die Nachricht übermittelt wird oder nicht?

     

    Kommentar


     

    Der Lieferant wird nach dem Einbau ohnehin informiert. Es sollen Erfahrungen hinsichtlich dieses Prozesses gesammelt werden. Er bleibt vorerst optional.

    Netzbetreiber entscheidet hinsichtlich Übermittlung.

    AT004000 W****r

    Bezeichnung Header „nur“ überflüssig bei „nur Netzbetreiber -> Lieferanten“ Prozessdiagramm „ZP im Netzgebiet bzw vom Empfänger versorgt“ => Korrektur auf „ZP vom Empfänger versorgt“

     

    Kommentar


     

    Prozessdiagramm geändert

    AT003100 LINZ STROM Netz GmbH

    Die LINZ STROM Netz GmbH (LSN) befürwortet den optionalen Ansatz. Die Vorabinformation ist in das bestehende Prozess- und IT-Umfeld schwierig integrierbar. Roll out-Umsetzung und Planung können voneinander abweichen. Eine Statusänderung beim Device-Type wird ohnedies über den Masterdata-Prozess mitgeteilt.  Die LSN schätzt den Nutzen für den Lieferanten als gering ein.

     

    Kommentar


     

    Es ist gesetzlich geregelt wer zu informieren ist – keine Regelung dass Lieferant informiert werden muss.
    Prozess bleibt vorerst optional

    AT109999 E-Control Austria J****r

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

     

    Kommentar


     

    Der Lieferant wird nach dem Einbau ohnehin informiert. Es sollen Erfahrungen hinsichtlich dieses Prozesses gesammelt werden. Er bleibt vorerst optional.


      
      

    MD_VDC (01.99) Übermittlung eines Nachweisdokumentes

      
    ProzessMD_VDC 
    Version01.99 
    BezeichnungÜbermittlung eines Nachweisdokumentes 
    Gültig von22.05.2017 

    Stellungnahmen

    AT004002 K****r

    Der Prozessschritt „Datenänderung beendet“ ist unseres Erachtens nicht erforderlich, da hier lediglich eine Information übermittelt wird.

     

    Kommentar


     

    "Prozess beendet" in Prozessdiagramm aufgenommen

    AT004000 W****r

     

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

     

    Kommentar


     

    "Prozess beendet" in Prozessdiagramm aufgenommen

    AT109999 E-Control Austria J****r

    • 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.

    ...Weiterlesen

     

    Kommentar


     

    Dazu gibt es keine einheitliche Meinung, da durch die Formulierung „ausdrücklichen Zustimmung“ im ElWOG, Unternehmen verpflichtet sind ein Dokument anzufordern.
    Erst nach Annahme der von der Branche erstellten Verhaltensregeln durch die Datenschutzbehörde (Bundeskanzleramt) kann diese Verpflichtung entfallen.

    Vollmachten und Nachweisdokumente der Wechselprozesse sind hiervon nicht betroffen.

    Der Begriff "physisch" wurde entfernt. Formulierung wurde angepasst.

    Die Zulässigkeit weiterer Formate ist technisch jederzeit möglich.

    Ist nicht auf alle Dokumente anwendbar (Heiratsurkunde, Firmenbuchauszug)
    Die Zustimmungserklärung für 1/4-h Werte soll für ein Jahr bestehen bleiben (entspricht dem normalen Belieferungszeitraum).
    Es soll jedoch nicht alle Jahre eine neue Vollmacht angefordert werden. Die Neuübermittlung ist nur dann nötig wenn auch ein entsprechender Anforderungs- bzw. Änderungsprozess ausgeführt wird.