Konsultation WECHSELPROZESS
| Beschreibung | Konsultation zur Adaptierung der technischen Dokumentation zum ENERGYlink Die Verrechnungsstellen haben gemeinsam mit Markteilnehmern und Branchenvertretern künftige Änderungen von Prozessen diskutiert und entsprechende Änderungsvorschläge erarbeitet. Die Änderungsvorschläge betreffen im Wesentlichen die nachstehend angeführten Punkte:
Die in den Dokumenten beschriebenen Änderungen sollen nach heutigem Plan mit 06.09.2021 produktiv umgesetzt werden. Dieser Termin wurde in Abstimmung mit Markteilnehmern und Branchenvertretern festgelegt. Die Abweichung vom regulären Release-Termin „Oktober 2021“ resultiert aus den speziellen Anforderungen seitens des Verteilergebietsmanagers (AGGM), welche die Umsetzung der Gas-Marktmodell-Verordnung 2020 (GMMO-VO 2020) betreffen. Der Bereich „Ergänzende Dokumente und Links - nicht Teil der Konsultation“ enthält Dokumente, welche keine Änderungen enthalten, aber dennoch Teil der technischen Dokumentation zum ENERGYlink ab September 2021 sind. Wir ersuchen Sie etwaige Stellungnahmen bis spätestens Montag, 13.07.2020 direkt auf der Homepage www.ebutilities.at unter der Rubrik „Konsultationen“ einzutragen oder alternativ an kundenservice@energylink.at zu übermitteln. Fragen zu den Änderungen der technischen Dokumentation können bis 13.07.2020 und darüber hinaus unter kundenservice@energylink.at gestellt werden. Nach Abschluss der Konsultation werden die finalen Dokumente für die geplante Umsetzung auf www.ebutilities.at sowie www.energylink.at veröffentlicht. ======================================================================= UPDATE 26.11.2020:Nachdem der ursprüngliche Grund für eine Vorverlegung des Herbst-Termins 2021 von 04.10.2021 auf 06.09.2021 nun entfällt (Gas-Marktmodell-Verordnung tritt lt. E-Control erst im April 2022 in Kraft), wurde mit den Branchenvertretern bei Oesterreichs Energie abgestimmt wieder auf den Oktober-Termin (04.10.2021) für die Produktivsetzung zu gehen. | |
| Fristen | ||
|---|---|---|
| Konsultation Beginn | 12.06.2020 | |
| Stellungsnahmen bis | 13.07.2020 | |
| Vorauss. Veröffentlichung | 14.08.2020 | |
| Testphase ab | 02.08.2021 | |
| Produktivsetzung | 04.10.2021 | |
| Abschluss | ||
|---|---|---|
| Entscheidung | Die Verrechnungsstellen bedanken sich für die Teilnahme an der Konsultation zur Adaptierung der technischen Dokumentation zum ENERGYlink. Auf Grund der Stellungnahmen im Rahmen der Konsultation wurden die folgenden zusätzlichen Änderungen seitens der Verrechnungsstellen durchgeführt: 1) Das Prozessdiagramm RTANM wurde folgendermaßen geändert (siehe A2.18 [RTANM] Vertragsrücktritt bei ANM_V02.20): a) Entfernung Prozessschritt „Information des Kunden über Beendigung der Lieferantenzuordnung“ in der Spalte „Netzbetreiber (NB)“ b) Ergänzung neuer Prozessschritt „Information des Kunden über die Konsequenzen eines fehlenden Energieliefervertrages“ in der Spalte „Lieferant Aktuell (LA)“ direkt nach Prozessschritt „FINALE_RTANM empfangen“. 2) die Beschreibungen der Response Codes im Prozess RAANM und Prozess RAABM wurde folgendermaßen geändert bzw. präzisiert (siehe a1.1-datendefinition_responsecodes_05.00_v0.5 und Spezifikation zur Umsetzung der Wechselverordnung V6.5): a) Code 131: Beschreibung: Daten passen nicht zur ConversationID Allgemeine Beschreibung: Die Daten der ConversationID auf die sich die ANFRAGE_RAABM/ANFRAGE_RAANM bezieht (ReferenceConversationId) passen nicht zu den Stammdaten der Anfrage. Die ReferenceConversationId dient als Referenz auf den ursprünglichen Prozess bei Rückabwicklung (ANM oder ABM). Der Netzbetreiber prüft, ob der ursprüngliche Prozess (ReferenceConversationId) eine ANM bzw. ABM ist. Der Netzbetreiber prüft zudem, ob der ZP im ursprünglichen Prozess (ReferenceConversationId) mit dem ZP im Prozess RAANM/RAABM übereinstimmt. b) Code 132: Die Rückabwicklungsprozesse wurden mehrfach geändert und aus aktueller Sicht wird der Code „Kunde wurde zum angefragten Datum nicht vom Lieferant versorgt“ nicht (mehr) benötigt, weil in der ANFRAGE_RAABM/ANFRAGE_RAANM kein Datum übermittelt wird. Folglich wurde Code 132 entfernt. c) Code 135: Beschreibung: Kunde in der Anfrage stimmt nicht mit Kunde in der Anlage beim Empfänger überein Allgemeine Beschreibung: Prüfung, ob die Felder ZP und Name1 aus der Nachricht ANFRAGE_RAABM/ANFRAGE_RAANM mit den Feldern ZP und Name1 bei der Anlage im Empfänger-System übereinstimmen. 3) Die inhaltlich doppelte Textpassage bei Prozess RTANM in der Zeile Zweck des Prozesses wurde entfernt: „Der Lieferant informiert den Netzbetreiber über einen gültigen Vertragsrücktritt laut FAGG.“ (siehe Spezifikation zur Umsetzung der Wechselverordnung V6.5, Kapitel 1.15.5.1) 4) Der 12. Absatz im Kapitel 1.15.2.4 zum Prozess ANM wurde folgendermaßen geändert (siehe Spezifikation zur Umsetzung der Wechselverordnung V6.5, Kapitel 1.15.2.4): „Sofern der Lieferant in der ANFRAGE_ANM das Feld Kennzeichen über „Versorgung letzter Instanz“ = True übermittelt, muss der Netzbetreiber keine manuelle Suche/Identifikation vornehmen, eine diesbezügliche Kennzeichnung kann ignoriert werden.“ 5) In der textuellen Spezifikation wurden zum besseren Verständnis die Begriffe „gewünschter Abrechnungszyklus“ (bei ANFRAGE_WIES und ANFRAGE_ANM) und „tatsächlicher Abrechnungszyklus“ (bei VERBRAUCH_WIES, ERSTE_WIES, FINALE_WIES und FINALE_ANM) eingearbeitet (siehe Spezifikation zur Umsetzung der Wechselverordnung V6.5). Im Datendefinition-Excel bzw. im XSD-Format wird nur ein Feld Abrechnungszyklus (ConsumptionBillingCycle) verwendet, um eine irrtümliche Befüllung des falschen Feldes zu vermeiden. 6) Der Wertebereich zum neuen Feld Abrechnungszyklus wurde geändert: 01, 12 -> MONTHLY, YEARLY (siehe a1.0-datendefinition_05.00_v0.5) 7) Der 12. Absatz im Kapitel 1.14.4.4 zum Prozess WIES wurde folgendermaßen geändert (siehe Spezifikation zur Umsetzung der Wechselverordnung V6.5, 1.14.4.4): Es ist möglich, dass der Netzbetreiber dem Abrechnungszyklus-Anforderungswunsch in der Nachricht ANFRAGE_WIES nicht entsprechen kann (z.B. bei nicht geeignetem Zählertyp), deshalb hat der Lieferant die Inhalte der Bestätigung durch den Netzbetreiber im VERBRACH_WIES, ERSTE_LN_WIES, FINALE_LN_WIES jedenfalls noch einmal zu prüfen. 8) Der 15. Absatz im Kapitel 1.15.2.4 zum Prozess ANM wurde folgendermaßen geändert (siehe Spezifikation zur Umsetzung der Wechselverordnung V6.5, 1.15.2.4): Es ist möglich, dass der Netzbetreiber dem Abrechnungszyklus-Anforderungswunsch in der Nachricht ANFRAGE_ANM nicht entsprechen kann (z.B. bei nichtgeeignetem Zählertyp), deshalb hat der Lieferant die Inhalte der Bestätigung durch den Netzbetreiber im FINALE_ANM jedenfalls noch einmal zu prüfen. 9) Der MessageCode der neuen Nachricht im Prozess STO wurde folgendermaßen geändert: FINALE_DREI_STO -> FINALE_VGM_STO (siehe a1.0-datendefinition_05.00_v0.5, Spezifikation zur Umsetzung der Wechselverordnung V6.5 und A2.10 [STO] Stornierung V04.10) Die finalen Dokumente (inklusive der technischen Austauschdaten WSDL und XSD) für die geplante Umsetzung per 06.09.2021 sind auf www.ebutilities.at sowie www.energylink.at veröffentlicht. | |
Betroffene Prozesse |
|
WECHSELPROZESS (05.00) Wechselprozess Allgemein |
|
| Prozess | WECHSELPROZESS | |
| Version | 05.00 | |
| Bezeichnung | Wechselprozess Allgemein | |
| Gültig von | 04.10.2021 |
- ✓ AT000002 A****n hat zugestimmt
- ✓ AT001002 B****l hat zugestimmt
- ✓ AT004000 A****i hat zugestimmt
- ✓ AT001000 Wiener Netze G****r hat zugestimmt
Stellungnahmen
AT004000 A****i
Sehr geehrte Damen und Herren,
folgende Anmerkungen unsererseits zur vorliegenden Konsultation
1. Aufnahme einer Klarstellung zur Information an den Kunden über Konsequenzen eines Vertragsrücktrittes im Prozess RTANM (Spezifikation Kapitel 1.15.5.1 und 1.15.5.4)
Es ist wünschenswert, eine einheitlich Vorgehensweise zur Kundeninformation von einem Marktteilnehmer vorzusehen (Netzbetreiber oder Lieferant). Im VZ-Prozess ist die Kundeninformation weiterhin durch den Netzbetreiber vorgesehen.
Falls der Entwurf beibehalten wird, ist das Prozessdiagramm richtigzustellen, da die Kundeninformation noch als Prozessschritt beim Netzbetreiber enthalten ist.
4. Aufnahme Response Code im Prozess RAANM und Prozess RAABM (Kapitel 1.15.4 und Kapitel 1.16.3)
Es ist unklar, wie sich der neue Response Code „Kunde Prozessdokument stimmt nicht mit Kunde Anlage überein“ zu den bestehenden Response Codes „Daten passen nicht zur ConversationID“ und „Kunde wurde zum angefragten Datum nicht versorgt“ unterscheidet. Bitte um Klarstellung.
8. Aufnahme neue Nachricht ERSTE_VGM_WIES im Prozess WIES (Kapitel 1.14.4)
Der Zeitpunkt für die Übermittlung der „ERSTE_VGM_WIES“ sollte mit den „ERSTE_LA/LN_WIES“ übermittelt werden, da hier mögliche Einwände bereits abgewickelt wurden. Somit ist ein konsistenter Prozess sichergestellt und alle Marktteilnehmer haben die gleichen Informationen.
Freundliche Grüße
Aleksandar Stefanoski
Kommentar
Zu 1.
Der Fehler bzw. Hinweis zum Prozessdiagramm A2.18 [RTANM] wird seitens Verrechnungsstellen berücksichtigt. Das Prozessdiagramm wird folgendermaßen geändert:
a) Entfernung Prozessschritt „Information des Kunden über Beendigung der Lieferantenzuordnung“ in der Spalte „Netzbetreiber (NB)“
b) Ergänzung neuer Prozessschritt „Information des Kunden über die Konsequenzen eines fehlenden Energieliefervertrages“ in der Spalte „Lieferant Aktuell (LA)“ direkt nach Prozessschritt „FINALE_RTANM empfangen“.
Zu 4.
Der Response Code „7 Rückabwicklungsprozess aufgrund von zwischenzeitlich nachfolgendem Prozess nicht durchführbar“ soll mit September 2021 neu aufgenommen werden. Der Response Code „Kunde Prozessdokument stimmt nicht mit Kunde Anlage überein“ ist jedoch kein „neuer“ Code. Der Code ist in der aktuellen Spezifikation bereits enthalten und ist daher in den Prozessen RAANM und RAABM in Verwendung.
Hinsichtlich der Klarstellungen zu den drei genannten Codes werden die Beschreibungen im Excel „a1.1-datendefinition_responsecodes_05.00_v0.4_Anpassung Sept 2021“ wie folgt überarbeitet:
a) Code 135
Beschreibung: Kunde in der Anfrage stimmt nicht mit Kunde in der Anlage beim Empfänger überein
Allgemeine Beschreibung: Prüfung, ob die Felder ZP und Name1 aus der Nachricht ANFRAGE_RAABM/ANFRAGE_RAANM mit den Feldern ZP und Name1 bei der Anlage im Empfänger-System übereinstimmen.
b) Code 131
Beschreibung: Daten passen nicht zur ConversationID
Allgemeine Beschreibung: Die Daten der ConversationID auf die sich die ANFRAGE_RAABM/ANFRAGE_RAANM bezieht (ReferenceConversationId) passen nicht zu den Stammdaten der Anfrage. Die ReferenceConversationId dient als Referenz auf den ursprünglichen Prozess bei Rückabwicklung (ANM oder ABM). Der Netzbetreiber prüft, ob der ursprüngliche Prozess (ReferenceConversationId) eine ANM bzw. ABM ist. Der Netzbetreiber prüft zudem, ob der ZP im ursprünglichen Prozess (ReferenceConversationId) mit dem ZP im Prozess RAANM/RAABM übereinstimmt.
c) Code 132
Die Rückabwicklungsprozesse wurden mehrfach geändert und aus aktueller Sicht wird der Code „Kunde wurde zum angefragten Datum nicht vom Lieferant versorgt“ nicht (mehr) benötigt, weil in der ANFRAGE_RAABM/ANFRAGE_RAANM kein Datum übermittelt wird. Folglich wird Code 132 entfernt.
Zu 8.
Seitens der Verrechnungsstellen wird bzgl. dem Zeitpunkt der Übermittlung der „ERSTE_VGM_WIES“ auf die Ausführungen in der Nachlese zum ENERGYlink-Workshop, welcher am 27.02.2020 stattgefunden hat, verwiesen (https://www.energylink.at/de/veranstaltungen/ENERGYlink-Workshop-Feb-2020). Im Workshop wurde seitens VGM betont, dass die „Ankündigungsnachricht“ so früh wie möglich vom Netzbetreiber an den VGM übermittelt werden soll. Das Risiko möglicher Einwände bzw. eine Prozess-Stornierung wird seitens VGM in Kauf genommen.
M****r
Kommentar
Zu Prüf-und Suchlogik.
Im ENERGYlink-Workshop am 27.02.2020 wurden verschiedene Punkte aus dem Themenblock „Prüf-und Suchlogik“ behandelt. Bei einigen Punkten wurde vereinbart, dass der entsprechende Spezifikationsentwurf sowie die Diagramme seitens Verrechnungsstellen überarbeitet und dem AK Wechselprozess bei Oesterreichs Energie für die weitere Diskussion zur Verfügung gestellt werden. Im Rahmen der Sitzungen im April/Mai 2020 bei Oesterreichs Energie hat sich dann gezeigt, dass einzelne ausgearbeitete Punkte noch weiterer Klärung bzw. Überarbeitung bedürfen. Der Themenblock „Prüf-und Suchlogik“ befindet sich daher noch in Ausarbeitung und ist abhängig vom Ergebnis der weiteren Diskussionen. Demzufolge ist der Umsetzungstermin aktuell noch offen. Eine Konsultation von diesem Themenblock wird wahrscheinlich im Herbst 2020 erfolgen und ggf. wird der Themenblock auch noch für die Umsetzung per September 2021 aufgenommen.
Zu 1.
Der Fehler Hinweis bzgl. der inhaltlich doppelten Formulierung in der Spezifikation Kapitel 1.15.5.1 wird seitens Verrechnungsstellen berücksichtigt. Die Formulierung wird entsprechend entfernt:
a) Entfernung Textpassage in der Zeile Zweck des Prozesses: „Der Lieferant informiert den Netzbetreiber über einen gültigen Vertragsrücktritt laut FAGG.“ (Spezifikation Kapitel 1.15.5.1)
Zu 2.
Die Verrechnungsstellen sehen diesen Vorschlag als sinnvolle Anpassung. Bei der Frist zur automatisierten Identifikation handelt es sich um eine Höchstfrist von 24h. Demzufolge kann es vorkommen, dass der Netzbetreiber nach der automatisierten Identifikation auch eine manuelle Identifikation innerhalb der 24h Frist vornimmt. Der 12. Absatz im Kapitel 1.15.2.4 Prozessdetails wird daher folgendermaßen geändert:
a) Anpassung der Formulierung: „Sofern der Lieferant in der ANFRAGE_ANM das Feld Kennzeichen über „Versorgung letzter Instanz“ = True übermittelt, muss der Netzbetreiber keine manuelle Suche/Identifikation vornehmen, eine diesbezügliche Kennzeichnung kann ignoriert werden.“
Zu 4.
Der Response Code „Kunde Prozessdokument stimmt nicht mit Kunde Anlage überein“ beschreibt die Prüfung auf Übereinstimmung der Daten in der Anfrage-Nachricht mit den Daten im Empfänger-System. Der Response Code 135 sowie die zugehörige Allgemeine Beschreibung im Excel „a1.1-datendefinition_responsecodes_05.00_v0.4_Anpassung Sept 2021“ werden daher präzisiert/überarbeitet (siehe auch Stellungnahme AT004000 A****i):
a) Code 135
Beschreibung: Kunde in der Anfrage stimmt nicht mit Kunde in der Anlage beim Empfänger überein:
Allgemeine Beschreibung: Prüfung, ob die Felder ZP und Name1 aus der Nachricht ANFRAGE_RAABM/ANFRAGE_RAANM mit den Feldern ZP und Name1 bei der Anlage im Empfänger-System übereinstimmen.
Zu 5.
Zu 5.1: In der textuellen Spezifikation werden zum besseren Verständnis die Begriffe „gewünschter Abrechnungszyklus“ (bei ANFRAGE_WIES und ANFRAGE_ANM) und „tatsächlicher Abrechnungszyklus“ (bei VERBRAUCH_WIES, ERSTE_WIES, FINALE_WIES und FINALE_ANM) eingearbeitet. Im Datendefinition-Excel bzw. im XSD-Format wird nur ein Feld Abrechnungszyklus (ConsumptionBillingCycle) verwendet, um eine irrtümliche Befüllung des falschen Feldes zu vermeiden.
Zu 5.2: Nach Rücksprache mit unserem IT-Dienstleister erachten wir das Feld Abrechnungszyklus als eine Information des Vertrages gleichwertig mit dem Feld Netzrechnungsempfänger. Da es sich beim Feld Abrechnungszyklus um ein neues Feld handelt und daher noch keine Erfahrungswerte mit dem Umgang innerhalb der Prozesse bestehen, ist es aus unserer Sicht nicht sichergestellt, dass alle Marktteilnehmer mit dieser vorgeschlagenen Kombination umgehen können. Es wird daher keine Änderung am Konsultationsentwurf vorgenommen (Feld Abrechnungszyklus wird nicht als optionales Attribut im Feld „GridInvoiceRecipient“ im xsd-Format angelegt). Die fachliche Prüfung der Felder erfolgt wie bisher im Empfänger-System.
Zu 5.3: Der Vorschlag bzgl. dem Inhalt im neuen Feld Abrechnungszyklus wird seitens Verrechnungsstellen berücksichtigt. Der Wertebereich wird entsprechend geändert:
a) Anpassung Wertebereich:01, 12 -> MONTHLY, YEARLY
Zu 5.4: Der Hinweis bzgl. der Formulierung wird seitens Verrechnungsstellen berücksichtigt. Das Feld Abrechnungszyklus sollte sich zwischen VERBRAUCH_WIES und FINALE_WIES nicht ändern. Allerdings wird das neue Feld in der ERSTE_ANM nicht übermittelt, weil es mit dem bestehenden Feld Netzrechnungsempfänger gleichgezogen wurde und daher in den exakt gleichen Nachrichten übermittelt wird (ANFRAGE_WIES, VERBRAUCH_WIES, ERSTE_WIES, FINALE_WIES sowie ANFRAGE_ANM, FINALE_ANM). Sofern ein unterschiedlich erfasster Abrechnungszyklus bei LF/NB vorliegt, müsste nach Abschluss WIES/ANM das Feld mittels „Customer Process CP_REQ_GIR“ bearbeitet werden.
Der 12. Absatz im Kapitel 1.14.4.4 Weitere Prozessdetails wird folgendermaßen geändert:
a) Anpassung der Formulierung: Es ist möglich, dass der Netzbetreiber dem Abrechnungszyklus-Anforderungswunsch in der Nachricht ANFRAGE_WIES nicht entsprechen kann (z.B. bei nicht geeignetem Zählertyp), deshalb hat der Lieferant die Inhalte der Bestätigung durch den Netzbetreiber im VERBRACH_WIES, ERSTE_LN_WIES, FINALE_LN_WIES jedenfalls noch einmal zu prüfen.
Der 15. Absatz im Kapitel 1.15.2.4 Prozessdetails wird folgendermaßen geändert:
b) Anpassung der Formulierung: Es ist möglich, dass der Netzbetreiber dem Abrechnungszyklus-Anforderungswunsch in der Nachricht ANFRAGE_ANM nicht entsprechen kann (z.B. bei nichtgeeignetem Zählertyp), deshalb hat der Lieferant die Inhalte der Bestätigung durch den Netzbetreiber im FINALE_ANM jedenfalls noch einmal zu prüfen.
Zu 9.
Die Verrechnungsstellen erachten diesen Vorschlag als sinnvolle Anpassung, da auch bei anderen Nachrichten so verwendet (z.B. FINALE_LN_WIES). Der MessageCode wird daher folgendermaßen geändert:
a) FINALE_DREI_STO -> FINALE_VGM_STO
Allgemeine Anmerkungen zu der Konsultation