Konsultation Optimierung Customer Processes

Beschreibung

Auf Grund der bisherigen praktischen Erfahrung mit customer processes erfolgte eine
Überarbeitung und Anpassung von Schemen und Prozessen.

Schemaerweiterung MasterData

Das Schema Masterdata wurde um nachstehende Felder erweitert und steht in der Version 01.20 zur Verfügung.

Feld GridInvoiceRecipient ist künftig prozessauslösend. Es wird dadurch das korrekte Umstellungsdatum bei
Anforderung zur Änderung des Netzrechnungsempfängers mit Prozess MD_REQ_GIR (Korrektur 25.07.2019) übermittelt.

Übermittlung des Schaltzustandes eines Zählpunktes (Zählers) über das neue nicht prozessauslösende Feld SupStatus (Versorgungsstatus).
Mittels Prozess CP_REQ_GN kann der Lieferant den aktuellen Schaltzustand beim Netzbetreiber anfordern

Übermittlung des aktuellen Netztarifes über das neue prozessauslösende Feld DSOTariffclass (Tarifklasse Netzbetreiber).
Mittels Prozess MD_REQ_GN (Korrektur 25.07.2019) kann der Lieferant den aktuellen Netztarif anfordern.

Mailadresse des Kunden als optionales Feld EMailCustomer.

Neue Prozessversionen wegen

  • Formulierung Überschneidung mit Wechselprozesse
  • Erweiterung um Prozessschritt mit MessageCode ANTWORT*
  • Prozessschritte in Beschreibung und Prozessdiagrammen 
  • Schemaänderung und Formulierung Prozessdatum (MasterData)
  • Prozesserweiterung (CP_REQ_GIR, CP_REQ_CMI)

Nachstehende Formulierung bei Prozessüberschneidung mit
Wechselprozessen wurde in Anforderungsprozesse aufgenommen

Ein aktiver Anforderungsprozess wird durch Prozessüberschneidung (initiales Prozessdatum
kleiner oder gleich Anforderungsdatum) ohne weitere Nachricht beendet.
Prozessüberschneidungen gelten bei ABM, VZ und WIES. Nach einer Rückabwicklung,
Rücktritt, Storno und Ähnlichem ist der Anforderungsprozess neu zu starten.

In allen Anforderungsprozessen ohne Antwortmöglichkeit wurde ein zusätzlicher
Schritt eingefügt, der den Auslöser über die Annahme der Verarbeitung
informiert (ANTWORT*). Als Responsecode wird die Nachricht 70 (Änderung/Anforderung akzeptiert) verwendet. Die
tatsächliche Übermittlung der durchgeführten Änderung erfolgt entweder über
eine MasterData Nachricht bzw. über bilateral vereinbarte Nachrichten (z.B.
Verbrauchsdaten).

Jede Veröffentlichung eines neuen Prozesses beinhaltet die Einführung
von Bezeichnungen für Prozessschritte in Prozessdiagramme und
Prozessbeschreibung.

Alle Prozesse mit Schemazuordnung MasterData wurden in einer neuen Prozessversion erstellt. In allen
Prozessen MD_CHG* wurde nachstehende Formulierung aufgenommen.

Das Prozessdatum im XML Element MasterData - ProcessDate entspricht dem Änderungsdatum im
Sendersystem und nicht dem Erfassungsdatum. Betroffen sind nur jene Inhalte die
das Attribut Changed enthalten. Alle weiteren, ebenfalls übermittelten Felder
haben einen tagesaktuellen Inhalt.
Gibt es beim Sender kein Gültigkeitsdatum (keine historische Abbildung), so ist
die Änderung mit dem Erfassungsdatum zu senden.
Je ProcessDate ist eine eigene Stammdatenänderung zu senden.

Allen neuen Prozessversionen die das Schema CPNotification in der Version 01.12
verwenden wurde die neue Version 01.13 zugeordnet.

Bei Prozess CP_REQ_CMI ist künftig die Anforderung zur tägliche
Übermittlung der Verbrauchsdaten bei DeviceType LPZ und IMN möglich. Es erfolgt
eine Prüfung von Kombinationen des Mess- und Übertragungsintervalls mit neuem
Ablehnungsgrund 106 (Kombination Mess- und Übertragungsintervall nicht zulässig).

Der Prozess CP_REQ_GIR kann künftig auch rückwirkend
angefordert werden. Es liegt im Ermessen des Netzbetreibers ob er eine
Umstellung mit Prozessdatum oder zu einem vom ihm errechneten Datum durchführt.
Je nach Umstellungsdatum sind unterschiedliche Responsecodes in der Antwort zu
verwenden. Unabhängig davon, wie die Umstellung des Rechnungsempfängers
erfolgt, ist eine MasterData-Nachricht auszulösen (MD_CHG_BD).

Nicht mehr benötigter Prozess

Es ist seit 01.10.2018 im Vorleistungsmodell möglich den Prozess RP_REQ_IN auch in Fällen ohne Rückforderung von nicht bezahlten
Netzentgelten zu verwenden. In diesem Fall ist im Feld [RepaymentAmount] der Betrag 0,00 einzusetzen.
Daher ist der Prozess CP_REQ_MBI (Anforderung einer
Zwischenablesung mit Abrechnung - Insolvenz) nicht mehr erforderlich.

Neuer Nachrichtenprozess

Zur Übermittlung von prozess- und zählpunktbezogenen Information kann künftig der Nachrichtenprozess MSG verwendet
werden.

Die Nachricht muss auf eine der nachstehenden Objekte Bezug nehmen

  • Bestehenden Prozess (OriginalMessageID)
  • Zählpunkt (MeteringPoint)
  • Rechnungsnummer (InvoiceNumber)

Es erfolgt eine klare Zuordnung zu einem Themenbereich mittels InfoTypes. Ist eine Zuordnung nicht möglich bzw. gibt es für eine
Nachricht einen definierten Prozess kann die Annahme der Nachricht abgelehnt
werden.




 
Fristen
Konsultation Beginn11.06.2019 
Stellungsnahmen bis07.07.2019 
Vorauss. Veröffentlichung05.08.2019 
Testphase ab01.02.2020 
Produktivsetzung06.04.2020 
Abschluss
Entscheidung
Auf Grund der Konsultation wurden zusätzliche Änderungen durchgeführt:
--> Die Verprobung auf MessageCodes im Schema CPNotification 01.13 wurde entfernt. Als Ergänzung werden die verwendeten MessageCodes in einem eigenen Dokument aufgelistet.
--> Die Fristen im Prozess CR_REQ_PT (Anfordern von Verbrauchsdaten) wurden angepasst.
--> Messagetext im Prozess MSG verlangt künftig XHTML als Inhalt. Die Größenbeschränkung wird mit ein MB festgelegt.
--> Auf Grund unterschiedlicher Adressverwaltungen ist es möglich beim Prozess MD_CHG_DA den Empfang der Nachricht mittels ANTWORT_DA zu bestätigen ohne die Änderung zu übernehmen (neuer Responsecode 107).
--> Im Prozess CP_REQ_GIR wurden die Responsecodes 73 (Nachrichtendaten fehlen) und 76 (Ungültige Anforderungsdaten) in den Messagecode ABLEHNUNG_GIR aufgenommen.
Ergänzend noch der Hinweis, dass die Anpassung jener Prozesse, die derzeit noch CPNotification (01.12) verwenden und nicht konsultiert wurden, im 4. Quartal 2019 erfolgen wird.
Die Kommentare können jeweils direkt bei den einzelnen Rückmeldungen nachvollzogen werden.
 

  
DokumenteKeine Dokumente zugewiesen 

Allgemeine Anmerkungen zu der Konsultation

AT006001 Vorarlberger Kraftwerke AG R****n

illwerke vkw stimmt den Optimierungen grundsätzlich zu.

Verbesserungsvorschlag für das Schema CPNotification:

Hier sollte die Verprobung auf die MessageCodes (wieder) entfernt werden, da beinahe jeder neue Prozess eine CPNotification beinhaltet. Dadurch müsste jedes mal eine neue Version des CPNotification-Schemas erstellt werden, was neue Prozessversionen praktisch aller Prozesse nach sich ziehen würde, obwohl diese von keiner Änderung betroffen sind.

Als Ergänzung könnten die verwendeten MessageCodes in der Schemadokumentation bzw. in einem eigenen Dokument aufgelistet werden.

MfG

 

Kommentar


 
Schemaanpassung und Dokumentation werden wunschgemäß durchgeführt

AT909999 AGCS Gas Clearing and Settlement AG C****i

Die Verrechnungsstellen als Betreiber des Self Storage-Dienst und somit Dienstleister für zurzeit ca. 100 Mandanten in Strom und Gas möchten hiermit folgende Stellungnahme zum laufenden Konsultationsverfahren „Optimierung Customer Processes“ übermitteln:

1)
Vorab eine generelle Frage:
Wurde auch eine neue Version der Marktprozess Gesamtdefinition zur Konsultation gestellt? Die einzige Version, welche auf ebUtilities zu finden ist, lautet „Marktprozesse Version 20180701 02p10.xlsx“ und wurde seit 2018 nicht aktualisiert.

Schemaerweiterung MasterData
2)
„Feld GridInvoiceRecipient ist künftig prozessauslösend. Es wird dadurch das korrekte Umstellungsdatum bei Anforderung zur Änderung des Netzrechnungsempfängers mit Prozess CP_REQ_GIR übermittelt.“
=> Wir ersuchen um Klarstellung, in welchen Fällen ein Prozess ausgelöst wird:
  1. Welcher Wert im Feld GridInvoiceRecipient im Prozess CP_REQ_GIR löst einen neuen Prozess aus?
  2. Welcher Prozess wird durch das Feld GridInvoiceRecipient ausgelöst?
  3. Durch welchen Teilnehmer wird ein Prozess ausgelöst? Falls der Prozess durch den Lieferanten ausgelöst wird:
    - Muss der Lieferant automatisiert einen Prozess auslösen?
    - Soll der Prozess auch durch eine Änderung des Feldes GridInvoiceRecipient in den Stammdaten im System des Lieferanten ausgelöst werden?
  4. Wäre es möglich die Prozess-Auslösung im Prozessdiagramm CP_REQ_GIR einzuzeichnen, damit klar ist in welchem System der Prozess ausgelöst wird?

3)
Übermittlung des aktuellen Netztarifes über das neue prozessauslösende Feld DSOTariffclass (Tarifklasse Netzbetreiber). Mittels Prozess CP_REQ_GN kann der Lieferant den aktuellen Netztarif anfordern=>Hier dürfte sich ein Tippfehler eingeschlichen haben. Prozess CP_REQ_GN existiert nämlich nicht. Vermutlich ist der Prozess MD_REQ_GN gemeint.
=>Wir ersuchen um Klarstellung, in welchen Fällen ein Prozess ausgelöst wird:
  1. Welche Werte können im neuen Feld DSOTariffclass übermittelt werden?
  2. Welcher Wert im Feld DSOTariffclass löst einen neuen Prozess aus?
  3. Welcher ...

...Weiterlesen

 

Kommentar


 
1) Neue Version der Gesamtdefinition wird bei Veröffentlichung zur Verfügung gestellt.

2)
2.1. Nur die Änderung des Netzrechnungsempfängers im System des Netzbetreibers löst die Nachricht MD_CHG_BD aus. Es wird im Feld GridInvoiceRecipient der Wert CUSTOMER oder SUPPLIER eingetragen. Durch das Attribut GridInvoiceRecipient@Changed wird die Information der durchgeführten Änderung übermittelt. Das Prozessdatum gibt den Zeitpunkt der Umstellung bekannt.

2.2. Nur die Änderung des Netzrechnungsempfängers im System des Netzbetreibers löst die Nachricht MD_CHG_BD aus. Im System des Lieferanten erfolgt auf Grund des Prozesses MD_CHG_BD die Umstellung des Netzrechnungsempfängers.

2.3a. Der Lieferant fordert die Änderung des Netzrechnungsempfängers mittels Prozess CP_REQ_GIR an. Es kommt zu einer ABLEHNUNG_GIR oder zu einer ANTWORT_GIR mit Responsecode 70 oder 105. Die tatsächliche Umstellung wird mittels Nachricht MD_CHG_BD durch den Netzbetreiber übermittelt. Ab Übermittlung dieses Prozesses kann der Anforderungsprozess beim Lieferant geschlossen werden.

2.3b. Die Änderung auf Lieferantenseite löst keine MasterData Nachricht aus, da nur Änderungen beim Netzbetreiber relevant sind.

2.4. In jedem Messagecode ist definiert wer Sender und Empfänger ist. Im Prozessdiagramm ist bereits jetzt definiert wird er Initiator ist. Es ist geplant den Initiator auch in die Prozessbeschreibung aufzunehmen.

3)
Ja, es betrifft den Anforderungsprozess MD_REQ_GN (Korrektur 25.07.2019)

3.1. Siehe Schemadokumentation zum Feld DSOTariffClass (G, GD, N, ND, U, E) --> Masterdata 01p20 Schemadoku.pdf

3.2. Jede Änderung der definierten Tarifklassen im System des Netzbetreibers löst eine Nachricht MD_CHG_PD an den Lieferanten aus.

3.3. Ob eine Änderung der Tarifklasse einen Prozess im Lieferantensystem auslöste muss durch den jeweiligen Lieferanten festgelegt werden.

3.4a. Der Lieferant löst keinen Prozess aus. Im System des Netzbetreibers ändert sich die Grundlage zur Verrechnung der Systemnutzungskosten. Die tatsächliche Umstellung wird mittels Nachricht MD_CHG_PD übermittelt.

3.4b. Es erfolgt keine Prozessauslösung durch Lieferanten. Die jeweilige Senderichtung ist im Prozessschritt beschrieben (z.B. MD_CHG_PD_S_3)

3.5. siehe 2.4.

4)
4.1. In allen betroffenen Anforderungsprozessen wurde die in der Konsultation beschriebene Formulierung aufgenommen. Zur bessern Übersicht wird eine Tabelle der betroffenen Prozesse zur Verfügung gestellt.

4.2. Die Prüfung erfolgt durch den Netzbetreiber, da bei diesem der Prozess zur Verarbeitung eingeplant ist. Der Lieferant kann jedoch ebenfalls eine Überschneidung feststellen und entsprechende Schritte in seinem System vorsehen.

4.3. Ist das Anforderungsdatum gleich oder nach dem WIES oder ABM Datum, sollte der Prozess unterdrückt werden. Liegt das Datum vorher, ist durch den Lieferant zu entscheiden ob er die Anforderung noch absenden möchte.

4.4. In einer künftigen Version ist die Beendigung der Prozesse durch eine Stornonachricht vorgesehen. Dabei werden die Prozessdiagramme überarbeitet.





AT001002 M****a

Grundsätzlich stimmt Wien Energie der Konsultation zur Optimierung der Customer Processes zu.

Bei allen betroffenen Prozessen, bei welchen aufgrund Prozessüberschneidungen ein aktiver Anforderungsprozess (initiales Prozessdatum kleiner oder gleich Anforderungsdatum) ohne weitere Nachricht beendet wird, ist es sinnvoll die Beendigung mittels einer Storno- bzw. Beendigungsnachricht vom NB an den LIEF zu übermitteln. Damit ist sichergestellt, dass alle betroffenen Marktteilnehmer über die Beendigung des Prozesses informiert sind und in ihren Systemen über denselben Prozessstatus verfügen.

 

Kommentar


 
Die Übermittlung einer Stornonachricht finden wir als sinnvolle Erweiterung. Die Übermittlung ist jedoch auf Grund der Komplexität in einer künftigen Version vorgesehen.

AT011008 A****u

AT011008, Energieallianz Austria GmbH

Der Prozess CP_REQ_MBI muss beibehalten werden.

Der Repaymentprozess ist an die Anwendung des Vorleistungsmodells geknüpft.

Umsatzsteuerrechtlich sind für die Abwicklung und Verrechnung der Netzrechnungen zwischen NB und Lieferant weitere Möglichkeiten zur korrekten Prozessierung der Netzrechnungen definiert. (vgl. Umsatzsteuer-Richtlinien  R.z 1536), nämlich

•           das Beauftragungsmodell und

•           das Maklermodell

Jedes dieser Modelle unterscheidet sich in der Abbildung im Rechnungswesen wesentlich vom Vorleistungsmodell.

Für den Fall, dass sich Marktpartner einvernehmlich für die Prozessierung der Netzrechnungen nach einem dieser o. a. Verrechnungsmethoden entscheiden und damit das Vorleistungsmodell nicht zu Anwendung kommt, wird der Prozess CP_REQ_MBI (Anforderung einer Zwischenablesung mit Abrechnung - Insolvenz) weiterhin benötigt.

Es liegt ganz sicher nicht im Sinne des Gesetzgebers über die Eliminierung des Prozesses CP_REQ_MBI  nur mehr die Zulässigkeit des Vorleistungsmodells zu postulieren.

 

Kommentar


 
Im Zuge einer Prozessreduzierung wird dieser Prozess aufgelöst.

Es erfolgt eine dahingehende Umformulierung im Prozess RP_REQ_IN, dass dieser nicht nur von Lieferanten im Vorleistungsmodell sondern auch Lieferanten welche Netzrechnungsempfänger sind, verwendet werden kann.

Es erfolgt eine Anpassung der Fristen für die Anforderung im Prozess RP_REQ_IN analog zum Prozess CP_REQ_MBI (15 Arbeitstage vor Ablauf der Anmeldefrist) bis zum 06.04.2020.

AT000002 VERBUND AG

VERBUND AG stimmt dem Konsultationsvorschlag grundsätzlich zu.

Dem Thema "Nicht mehr benötigter Prozess" CP_REQ_MBI (Anforderung einer Zwischenablesung mit Abrechnung - Insolvenz) stimmen wir nicht zu: 

  • aus unserer Sicht ist die Streichung des Prozesses eine Verschlechterung der jetzigen Situation und der Prozess CP_REQ_MBI ist weiterhin erforderlich

  • aufgrund der unterschiedlichen Fristen in den beiden Prozessen ist tlw. eine Rückforderung über RP nicht möglich und könnte daher noch über CP durchgeführt werden

  • die Anforderung über den CP kann länger gestartet werden und würde die Klärung über E-Mails weiterhin ersetzen/minimieren

Fristen CP_REQ_MBI

Die Anforderung ist bis spätestens 15 AT vor Ablauf der Anmeldefrist der Insolvenz zu übermitteln.

Fristen RP_REQ_IN

Die Übermittlung an NB darf spätestens 10 Kalendertagen nach Insolvenzeröffnung erfolgen.

 

Kommentar


 
Im Zuge einer Prozessreduzierung wird dieser Prozess aufgelöst.

Es erfolgt eine Anpassung der Fristen für die Anforderung im Prozess RP_REQ_IN analog zum Prozess CP_REQ_MBI (15 Arbeitstage vor Ablauf der Anmeldefrist) bis zum 06.04.2020.

AT004000 A****i

Stellungnahme Salzburg Netz GmbH zu „Konsultation Optimierung Customer Processes“

Die Schemaerweiterung des Schema „MasterData“ um das Feld EMailCustomer wird von uns als notwendig erachtet, da es ein zeitgemäßer Kommunikationskanal zum Kunden ist und der Datenaustausch der E-Mail Adresse in gleicher Form optional in den Wechselprozessen definiert ist.

Die weiteren Optimierungen der Customer Processes und Ergänzung um einen den neuen Prozess MSG sollte den Datenaustausch vereinfachen und werden begrüßt. 


Salzburg Netz GmbH
Aleksandar Stefanoski



  
  

Betroffene Prozesse

  
  
  

CP_REQ_LPT (02.95) Anforderung einer Lastprofiländerung

  
ProzessCP_REQ_LPT 
Version02.95 
BezeichnungAnforderung einer Lastprofiländerung 
Gültig von01.05.2019 

Stellungnahmen


  
  

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

  
ProzessCP_REQ_GIR 
Version02.95 
BezeichnungAnforderung auf Änderung des Netzrechnungsempfängers 
Gültig von01.05.2019 

Stellungnahmen

AT004000 A****i

Redaktionelle Korrektur, in der Abbildung Prozessdiagramm fehlt der Prozessschritt 18 „CP_REQ_GIR_E_11“ Start Prozess MD_CHG_BD
 

Kommentar


 
Prozessdiagramm wird angepasst

  
  

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

  
ProzessMD_CHG_PD 
Version02.95 
BezeichnungStammdatenänderung - Änderung von Zählpunktdaten 
Gültig von01.05.2019 

Stellungnahmen


  
  

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

  
ProzessMD_CHG_BD 
Version02.95 
BezeichnungStammdatenänderung - Änderung der Abrechnungsdaten 
Gültig von01.05.2019 

Stellungnahmen


  
  

MD_REQ_IR (02.95) Anforderung der Rechnungsadresse

  
ProzessMD_REQ_IR 
Version02.95 
BezeichnungAnforderung der Rechnungsadresse 
Gültig von01.05.2019 

Stellungnahmen

AT001000 Wiener Netze G****r

ANTWORT_IR ist nur zu senden wenn Korrespondenzadresse von Lieferadresse abweicht.

Sind die Adressen ident:

ABLEHNUNG_IR mit neuem Response Code:

"Korrespondenzadresse weicht nicht von Anlagenadresse ab"




 

Kommentar


 
Die Übermittlung einer Rechnungsadresse soll, unabhängig davon ob sie ident mit der Lieferadresse ist, erfolgen.

  
  

MD_REQ_GN (02.95) Anforderung der aktuellen Stammdaten

  
ProzessMD_REQ_GN 
Version02.95 
BezeichnungAnforderung der aktuellen Stammdaten 
Gültig von01.05.2019 

Stellungnahmen


  
  

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

  
ProzessCR_REQ_PT 
Version02.95 
BezeichnungAnfordern von Verbrauchsdaten (gem. DAVID Verordnung) 
Gültig von01.05.2019 

Stellungnahmen

AT113041 Spotty Smart Energy Partner GmbH H****k

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

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

 

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

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

 

 

Kommentar


 
Erster Vorschlag:
Die Fristen zur Anforderung der Verbrauchsdaten werden folgendermaßen geändert.

Bei täglicher Übermittlung darf frühestens 3 Arbeitstage nach dem erwarteten Erhalt angefordert werden.
Bei monatlicher Übermittlung darf frühestens am 6. des Monats angefordert werden.

Zweiter Vorschlag:
Es ist derzeit nicht vorgesehen Verbrauchsdaten die nicht im Versorgungszeitraum des Lieferanten sind, anzufordern.
Zukünftig könnte jedoch analog zur Zusendung von LPZ Daten auch IMS Daten im Zuge des WIES an den neuen Lieferanten gesandt werden. Diese Anforderung ist jedoch nicht Teil dieser Konsultation.
Auch im Zuge der Einführung des Customer Consent Management soll diese Möglichkeit diskutiert werden.

  
  

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

  
ProzessCP_REQ_CMI 
Version02.95 
BezeichnungAnforderung auf Änderung des Mess-/Übertragungsintervalls 
Gültig von01.05.2019 

Stellungnahmen

AT008000 T****.

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

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

 

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

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

 

Kommentar


 
In der aktuellen Tabelle (noch nicht veröffentlicht) wird darauf hingewiesen, dass es sich um den DeviceType vor Anforderung handelt. Bei IMS soll die Anforderung von QH möglich sein.

AT113041 Spotty Smart Energy Partner GmbH H****k

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

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

 Vorschlag – die 5 Tage Regel abzuschaffen

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

 

Kommentar


 
Auf Grund der derzeitigen gesetzlichen Grundlage konnte keine einheitliche Vorgangsweise zur Übermittlung der Authentifizierungsverfahren festgelegt werden. Das von allen Netzbetreibern akzeptierte Verfahren ist 51 mit beiliegendem PDF. Lieferanten sollen bei ECA den Wunsch zur Änderung der gesetzlichen Grundlagen einbringen.

Die 5 Tage Regel bleibt vorerst bestehen.
Sobald die ElWOG §§ 76 und 84a eine gemeinsame Zustimmung ermöglichen, kann die Anforderung in die Anmelde- bzw. Wechselprozesse aufgenommen werden.


  
  

CP_REQ_CBC (02.95) Anforderung auf Änderung Abrechnungszyklus

  
ProzessCP_REQ_CBC 
Version02.95 
BezeichnungAnforderung auf Änderung Abrechnungszyklus 
Gültig von01.05.2019 

Stellungnahmen

AT008000 T****.

Korrektur der Beschreibung der Prozessschritte: Es muss eine MD_CHG_BD (Abrechnungsdaten) versandt werden und keine MD_CHG_PD (Zählpunktdaten).
 

Kommentar


 
Richtigstellung erfolgt

AT113041 Spotty Smart Energy Partner GmbH H****k

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

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

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

 

Kommentar


 
Es ist geplant, dass der Lieferant im Zuge des WIES bzw. der ANM den gewünschten Abrechnungszyklus bereits im Vorhinein bekanntgeben kann.
Der Intervall der Teilbeträge wird durch den Netzbetreiber festgelegt und ist in der Rahmenvereinbarung zwischen Netzbetreiber und Lieferant festgelegt (siehe Mustervertrag auf www.ebUtilites.at §3 Zahlung der Rechnung). Es steht dem Lieferanten jedoch frei dem Kunden andere Zahlungsintervalle anzubieten.

Es gibt keine Verknüpfung zur Anforderung eines Messintervalls und Änderung des Abrechnungszyklus. Eine Änderung des Messintervalls führt zu keiner Änderung des Abrechnungszyklus.

  
  

MSG (00.95) Übermitteln einer Nachricht

  
ProzessMSG 
Version00.95 
BezeichnungÜbermitteln einer Nachricht 
Gültig von01.05.2019 

Stellungnahmen

AT004000 Salzburg Netz GmBH C****r

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

 

Größenbeschränkung auf ein MB.

Neuer Ablehnungscode "Nachicht nicht lesbar".

 

Kommentar


 
Messagetext verlangt künftig XHTML als Inhalt. Die Größenbeschränkung wird mit ein MB festgelegt.

AT008000 T****.

Eine MSG führt i.d.R. zu Rückfragen, wodurch der Prozess MSG möglicherweise nur bedingt nützlich wird, da dieser nur zur Informationsweitergabe dienen kann. Eine Erweiterung des ProcessCodes ANTWORT_MSG um einen Code "Rückfrage vorhanden" könnte dem Abhilfe schaffen.
 

Kommentar


 
Eine Antwortnachricht kann auf eine bestehende Nachricht referenziert werden.

AT001000 Wiener Netze G****r

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

Somit wird in der ABLEHNUNG_MSG ein Response Code

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


Lieferantenwechsel steht nicht in Kategorie jedoch in Beschreibung.


Dieser Prozess wurde bei jeder Besprechung von Wien immer abgelehnt und

ist im Massengeschäft nicht anwendbar.

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


 

Kommentar


 
Der Prozess wurde von allen Anwesenden und der ECA akzeptiert und als sinnvolle Ergänzung gesehen.

  
  

MD_CHG_CP (02.95) Stammdatenänderung - Namensänderung

  
ProzessMD_CHG_CP 
Version02.95 
BezeichnungStammdatenänderung - Namensänderung 
Gültig von01.05.2019 

Stellungnahmen


  
  

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

  
ProzessMD_CHG_DA 
Version02.95 
BezeichnungStammdatenänderung - Änderung der Lieferadresse 
Gültig von01.05.2019 

Stellungnahmen

AT008000 T****.

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

 

Kommentar


 
Auf Grund unterschiedlicher Adressverwaltungen ist es möglich den Empfang der Nachricht mittels ANTWORT_DA zu bestätigen ohne die Änderung zu übernehmen (neuer Responsecode 107).

AT001000 Wiener Netze G****r

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

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


  
  

MD_ANN_DT (02.95) Vorabinformation über geplanten Smart Meter Einbau

  
ProzessMD_ANN_DT 
Version02.95 
BezeichnungVorabinformation über geplanten Smart Meter Einbau 
Gültig von01.05.2019 

Stellungnahmen


  
  

CP_REQ_MRD (02.95) Anforderung einer Zwischenablesung

  
ProzessCP_REQ_MRD 
Version02.95 
BezeichnungAnforderung einer Zwischenablesung 
Gültig von01.05.2019 

Stellungnahmen


  
  

CP_REQ_MDI (02.95) Anforderung einer Zwischenablesung - Insolvenz

  
ProzessCP_REQ_MDI 
Version02.95 
BezeichnungAnforderung einer Zwischenablesung - Insolvenz 
Gültig von01.05.2019 

Stellungnahmen


  
  

CP_REQ_MRB (02.95) Anforderung einer Zwischenablesung mit Abrechnung

  
ProzessCP_REQ_MRB 
Version02.95 
BezeichnungAnforderung einer Zwischenablesung mit Abrechnung 
Gültig von01.05.2019 

Stellungnahmen


  
  

CP_REQ_BIL (02.95) Anforderung einer Zwischenabrechnung ohne Ablesung

  
ProzessCP_REQ_BIL 
Version02.95 
BezeichnungAnforderung einer Zwischenabrechnung ohne Ablesung 
Gültig von01.05.2019 

Stellungnahmen