Konsultation Ablöse MSCONS

Beschreibung



Das große Ziel dieser Prozessadaptierungen und -einführungen ist die Vereinheitlichung und Optimierung des Energiedatenversandes zwischen Verteilernetzbetreibern und Energielieferanten/Versorgern. Bisher wurden für den Versand von Energiedaten zwischen den berechtigten Marktpartner unterschiedliche Prozesse und Formate verwendet, je nachdem um welchen DeviceType es sich handelt und in weiterer Folge welches Messgerät (Smart Meter, mechanischer/elektronischer Zähler, Lastprofilzähler) sich hinter diesem Zählpunkt befindet. Zukünftig werden dafür einheitliche Prozesse und Formate verwendet, sodass sowohl beim Sender als auch beim Empfänger sich Synergien in der Verarbeitung dieser Prozesse ergeben. Zusätzlich werden auslösende Prozesse bzw. Ereignisse und Fristen demensprechend angepasst, sodass Informationslücken zwischen dem Netzbetreiber und dem Energielieferant/Versorger betreffend der aufgetretenen Energiemengen je Zählpunkt zeitnah geschlossen werden und nahezu zu jedem Zeitpunkt der Informationsstand bezüglich Energiemengen bei Netzbetreiber und Energielieferant/Versorger ident ist. Die Ablöse von MSCONS im Einzelzählpunktbereich schafft so eine Entkopplung von der Übermittlung von Energiedaten und den jeweils vom Netzbetreiber durchgeführten Netzabrechnungen.


ACHTUNG: In weiterer Folge wird in dieser Konsultation und in den davon betroffenen Prozessen der DeviceType "NONSMART" auch "NSM" genannt. Beide Begriffe haben in den Beschreibungen die gleiche Bedeutung.

CR_MSG – Versenden der Energiedaten:
Der Prozess CR_MSG war bisher ausschließlich für den Versand von Energiedaten von Zählpunkten vorgesehen, welche den DeviceTypes IMS, IMN und IME entsprechen. Zukünftig wird der Prozess für alle DeviceTypes der Sparten Strom und Gas verwendet. Prozessauslöser und Fristen werden so angepasst, dass sobald neue Energiemengen an einem Zählpunkt entstehen (z.B. durch Ablesung eines mechanischen Zählers), diese auch unabhängig von den Zeitpunkten der Netzabrechnungen an den jeweiligen berechtigten Marktpartner versendet werden. Das Format Consumption Record wird adaptiert, sodass zukünftig in einer Antwortnachricht auch unterschiedlichen Zeitbereiche eines Zählpunktes übermittelt werden können, auch wenn diese Zeitbereiche sich in den DeviceTypes und den MeterIntervals unterscheiden. Da nun Energiedaten sämtlicher Zählpunkt DeviceTypes der Sparten Strom und Gas übertragen werden können, wurde auch die Liste der zulässigen MeterCodes/OBIS Codes adaptiert bzw. erweitert. Zusätzlich wurde im Namen des Prozesses das Wort „Verbrauchsdaten“ durch „Energiedaten“ ersetzt, da sowohl die Daten von Verbrauchsanlagen als auch von Erzeugungsanlagen übermittelt werden.


CR_REQ_PT – Anforderung von Energiedaten:
Der Prozess CR_REQ_PT stand bisher ausschließlich für Zählpunkte mit den DeviceTypes IMS, IMN und IME zur Verfügung. Zukünftig wird auch dieser Prozess für sämtliche DeviceTypes der Sparten Strom und Gas zur Verfügung stehen. Die Adaptierung dieses Prozesses hat auch zur Folge, dass nun Energiedaten von Zeitbereichen eine Zählpunktes angefordert werden können, auch wenn sich die zugehörigen DeviceTypes der Zeitbereiche des Zählpunktes unterscheiden. Synchron dazu wurde wie schon beschrieben der Prozess CR_MSG adaptiert, um auf solche Anforderungen auch mit einer einzigen Antwortnachricht antworten zu können. Zusätzlich wurde im Namen des Prozesses das Wort „Verbrauchsdaten“ durch „Energiedaten“ ersetzt, da sowohl die Daten von Verbrauchsanlagen als auch von Erzeugungsanlagen übermittelt werden.


MD_IN_NT – Information über Netzabrechnung:
Durch die Ablöse des MSCONS-Versandes geht zwischen Netzbetreiber und Energielieferant/Versorger die Information über eine Netzabrechnung verloren, daher wurde ein neuer Prozess geschaffen welcher dem Energielieferant/Versorger über den Zeitabschnitt und den Grund einer Netzabrechnung informiert. Zusätzlich wird mittels diesem Prozess der Energielieferant/Versorger über den durch die Netzabrechnung neu berechneten Jahresverbrauchswert (Prognosewert) informiert.

Genaue Erläuterungen für das Umstiegsszenario zum Stichtag der Produktivsetzung können folgendem Dokument entnommen werden: https://www.ebutilities.at/documents/20200304140258_Abloese_MSCONS_Umstiegsszenario.pdf

 




 
 
Fristen
Konsultation Beginn04.03.2020 
Stellungsnahmen bis17.04.2020 
Vorauss. Veröffentlichung12.05.2020 
Testphase ab01.09.2021 
Produktivsetzung04.10.2021 
Abschluss
Entscheidung
Auf Grund der Konsultation wurden zusätzliche Änderungen durchgeführt:

1. Im Prozess CR_MSG – Versand von Energiedaten:
a. Fehler in den Grafiken und Prozesszeichnungen wurde korrigiert
b. Änderung der Beschreibung, der Prozess CR_MSG wird auch für den Versand von historischen Energiedaten
(12 Monate Sparte Strom, 24 Monate Sparte Gas) aus dem Prozess WIES (Prozessschritt WIES 56) verwendet (gilt nur für DeviceType LPZ)
c. Ergänzung der DeviceType Änderungen, bei denen eine Ablesung notwendig ist
d. Änderung der „Methoden der Messung“, LPZ wurde mit den Smart Meter DeviceTypes harmonisiert (Wegfall von ZZZ und 05)
e. Ergänzung der Fristen für die DeviceTypes NONSMART und DSZ
f. Änderung der Voraussetzungen, die DeviceTypes IME/IMS/IMN sind keine Voraussetzung für den Prozess

2. Im Prozess CR_REQ_PT – Anforderung von Energiedaten:
a. Fehler in den Grafiken und Prozesszeichnungen wurde korrigiert
b. Fristen wurden angepasst, die Umstellung auf die DeviceTypes IMS, IMN oder IME stellen keine Grenze der Datenanforderung in die Vergangenheit mehr der.
Zusätzlich wurde die Fristen bezüglich dem Nachfordern der zyklisch versendeten Daten auf die DeviceTypes IMS, IMN, IME und LPZ beschränkt
c. Änderung der Voraussetzungen, die DeviceTypes IME/IMS/IMN sind keine Voraussetzung für den Prozess
d. Die Anforderung von Daten aus einem Anforderungszeitraum in dem der Anforderer keinen aufrechten Liefervertrag hat, ist nicht möglich
(z.B. Anforderung von historischen Daten aus dem WIES Prozess)
 
  
DokumenteKeine Dokumente zugewiesen 

Allgemeine Anmerkungen zu der Konsultation

  
  

Betroffene Prozesse
  
  
  

CR_MSG (02.90) Versenden der Energiedaten
  
ProzessCR_MSG 
Version02.90 
BezeichnungVersenden der Energiedaten 
Gültig von04.03.2020 

Stellungnahmen

AT000000 H****Ÿ

  • Da bei einigen Netzbetreibern das Wechselmanagement (Stammdaten) von den Zählwertmanagement entkoppelt ist, kommt es immer wieder zu nicht zuordenbaren Datenübermittlungen (ZP bei anderem LF/BG).

    Unserer Meinung nach sollte daher im Prozessen CR_MSG vor dem Sub-Prozess CR_MSG_S_3 „Datensatz erstellen“ ein Prüfprozess „Zählpunkt prüfen“ dazwischengeschaltet sein, damit seitens des Netzbetreibers geprüft wird, ob die Daten tatsächlich an den jeweiligen Lieferanten gesendet bzw. von diesem angefordert werden sollen/dürfen.

    Dies würde dazu führen, dass die Folgeprozesse nur in seltenen Spezialfällen (z.B. Fehler im Wechselmanagement, verzögerte Stammdaten-Informationsflüsse, etc.) anschlagen würden. So könnte vordergründig unnötige Kommunikation, aber auch Verarbeitung und Speicherung von nicht relevanten Daten verringert werden.

 

Kommentar


 
Eine Prüfung der Zugehörigkeit des Zählpunktes zum jeweiligen Energielieferanten oder Anlagenbetreiber muss natürlich zwingend durch den Netzbetreiber durchgeführt werden. Bei derzeitigen Fehlern im Versand von Marktnachrichten ist davon auszugehen, dass etwaige Stammdaten nicht vollständig sind und es daher in Ausnahmefällen zu einem fehlerhaften Versand kommt. Eine automatisierte Prüfung würde bei fehlerhaften Stammdaten nichts nützen, da die Prüfung immer nur auf den Stand der Stammdaten aufbauen kann.

AT008000 D****r


Einführung Gas – CR – variable Brennwerte

Hier ergeben sich aufgrund der in der GMMOVO 2020 festgelegten Verwendung von variablen Monatsbrennwerten (Umrechnung Normvolumen in Energie) Verzögerungen bis der Energiewert aus den Ablesewerten (Volumen) erstellt werden kann (Worst Case über ein Monat).

Dies resultiert daraus, dass erst der Monatsbrennwert bestimmt werden muss und danach erst eine Energiemenge für die entsprechende Zählerstanddifferenz berechnet werden kann.

Schemabeschreibung Version 1.30 – Delivery Point

Aus Sicht EN ist der der Satz „Nur im Versand von (Gas-)Aggregaten relevant“ ersatzlos zu streichen, da diese Feature im MSCONS für mehrere Anwendungen verwendet wird (z.B. Übertragung Einzelwerte an den MVGM, Einzelwerte an HKN – Datenbank usw.)

Schemabeschreibung Version 1.30 – MeteringReason

Hier decken sich die in der Dokumentation V1.30 angeführten Ablesegründe nicht mit der in der Konsultation angeführten.
 

Kommentar


 
In den Prozessen wurde unteranderem festgelegt, dass ein Versand von Energiemengen dann angestoßen werden muss, wenn bei einem Zählpunkt ein neuer Energiewert (kWh) festgestellt/berechnet wurde. Da diese Energiemenge erst berechnet werden kann, wenn die dazugehörigen Brennwerte vorliegen, kommt es hier laut Definition dieses Prozesses zu keiner Verzögerung.
Zu Schemabeschreibung Version 1.30 – Delivery Point: Korrekt, dieser Satz ist zu streichen.
Zu Schemabeschreibung Version 1.30 – MeteringReason: Korrekt, wird korrigiert.

AT002000 A****l

Die Übermittlungen von periodischen Energiedaten eines Zählpunktes an einen Lieferanten während einer Belieferungsdauer immer mit derselben ProzessID (ConversationId) zu versehen, halten wir nicht für sinnvoll. Dies wäre ein zusätzlicher Schlüssel in der Nachrichtenübermittlung, der in den Systemen erhebliche Aufwände nach sich zieht. Wir schlagen daher vor: „Solange ein Zählpunkt durchgehend einem Lieferanten/Versorger zugeordnet ist, KANN und nicht MUSS die gleiche Conversations ID verwendet werden“. Die unter „Methoden der Messung“ angeführten Stati sind für den Gasbereich (SoMa Gas Kap.4) noch unzureichend definiert. Es fehlt z.B: QTY-99 „Ersatzwert. Dies trifft auch auf das Dokument „CustomerProcesses“ zu. Eine Harmonisierung aller MeteringMethods ist sinnvoll. Die Voraussetzung für CR_MSG sollte um die DeviceTyp NSM und LPZ ergänzt werden. Die Prozessauslösung sollte um die DeviceTyp NSM und LPZ ergänzt werden. Der Punkt Netzabrechnung steht im Widerspruch zu erwähnten Trennung von Ablesung und Abrechnung. Entweder es erfolgt hier eine exakte Beschreibung des Ablaufes, oder eine Streichung dieses Punktes.
 

Kommentar


 
Die Einheitliche Conversations ID ist nicht notwendig, somit gilt: Solang ein Zählpunkt durchgehend einem Lieferanten/Versorger zugeordnet ist, KANN die gleiche Conversations ID verwendet werden.

Methoden der Messung: Werden dahingehend angepasst, das L1, L2 und L3 auch sinngemäß für den DeviceType LPZ zu verwenden sind. Daher fallen die Methoden „05“ und “ZZZ“ weg.

Voraussetzung werden natürlich um die DeviceTypes IMN, NSM und LPZ ergänzt.

Bei den Prozessauslösern sind die DeviceTypes NSM und PLZ bereits berücksichtigt. Wird dennoch noch einmal verdeutlicht.

Der Punkt Netzabrechnung steht hier nicht im Widerspruch mit der erwähnten Trennung von Ablesung und Abrechnung. Im zyklischen Versand (z.B. bei IMS) kann es dennoch zu größeren Zeitspannen kommen, in der der Netzbetreiber bereits die Netzabrechnung erstellt hat und der Energielieferant für die Energierechnung noch keine Verbrauchsdaten übermittelt bekommen hat (Beispiel, monatlicher Versand, Abrechnungsstichtag 6. April, am 7 April erstellt Netzbetreiber Netzrechnung, erst am 05.Mai würden bei zyklischem Versand die Daten vom April an den Energielieferanten versendet werden).

AT001002 B****l

Bitte um Definition der Fristen, für Device-Type Änderungen, die nicht in der DAVID-VO geregelt. Der Versand der Verbrauchsdaten sollte unmittelbar nach Erhalt des MD_CHG_PD erfolgen.
 

Kommentar


 
Fristen entsprechend der jeweiligen gesetzlichen Bestimmungen für intelligente Messgeräte (DAVID-VO), welche auch in der Beziehung Netzbetreiber an Anlagenbetreiber anzuwenden sind.

Ergänzung wird vorgenommen:
Zusätzlich muss spätestens 2 Tage nach dem Eintreten eines Prozessauslösers der Versand von neuen Energiemengen erfolgen.

AT900049 Netz Oberösterreich GmbH

In der Sparte Gas wird zur Ermittlung der Energiemenge (kWh) der Brennwert benötigt. Aktuell ist der in der Abrechnung anzuwendende Brennwert bereits bekannt und kann somit bereits zum Ablesezeitpunkt in kWh umgerechnet werden.

Ab voraussichtlich 2023 wird die Ermittlung von Ist-Brennwerten gemäß GMMO-VO 2020 erfolgen, somit ist monatlich ein Ist-Brennwert zu ermitteln. Diese Ermittlung ist voraussichtlich erst Mitte des Folgemonats möglich. D.h. zum Ablesezeitpunkt kann nur mit einem vorläufigen Brennwert gerechnet werden. In der Spezifikation ist die Kennzeichnung diese "vorläufigen" Brennwertes vorzusehen, bzw. muss der Sendeprozess dieses Gas Spezifikum berücksichtigen.

 

Die Umsetzungsphase bis zur vorgeschlagenen Produktivsetzung am 05.04.2021 ist zu kurz gefasst und benötigt eine Verlängerung von mindestens 6 Monaten.


 

Kommentar


 
In den Prozessen wurde unteranderem festgelegt, dass ein Versand von Energiemengen dann angestoßen werden muss, wenn bei einem Zählpunkt ein neuer Energiewert (kWh) festgestellt/berechnet wurde. Da diese Energiemenge erst berechnet werden kann, wenn die dazugehörigen Brennwerte vorliegen, kommt es hier laut Definition dieser Prozess zu keiner Verzögerung.
Mögliche zukünftige Änderungen bezüglich „dynamischer“ Brennwert wurden jetzt bewusst nicht berücksichtigt, dennoch könnte schon jetzt z.B. L3 dafür verwendet werden. Sollte es zukünftig aus dieser Thematik notwendig sein, einen weiteren Status hinzuzufügen, wird dies über eine Konsultation geregelt.

Der Go Live Termin wird auf Herbst 2021 verschoben (derzeit 06.09.2021).

AT007000 W****z

Start des Prozesses nicht nur mittels Erreichung der Frist (täglich, monatlich) sondern auch durch Prozessauslöser Ablesung, Devicetypeumstellung, ... 

Methode der Messung:

Es soll eine Harmonisierung zwischen LPZ und SmartMeter vorgenommen werden

  • 05 nicht mehr notwendig
  • L3 oder ZZZ beide Möglichkeiten sind nicht notwendig
 

Kommentar


 
Nicht nur das Erreichen von Fristen laut DAVID VO führt zu einem Versand der Energiewerte. Auch sämtliche beschriebene Prozessauslöser führen zu einem Versand von Energiewerten.

Methoden der Messung: Werden dahingehend angepasst, das L1, L2 und L3 auch sinngemäß für den DeviceType LPZ zu verwenden sind. Daher fallen die Methoden „05“ und “ZZZ“ weg.

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 Fragen zum laufenden Konsultationsverfahren „Konsultation Ablöse MSCONS“ übermitteln: Eine genauere Definition der Fristenprüfung bei Prozessschritt CR_MSG_E_3 im Prozess „CR_MSG Versenden der Energiedaten“ ist aus unserer Sicht erforderlich: 1) Welche Fristen müssen hier seitens Marktpartner geprüft werden? 2) Was bedeutet „Prozessdatum korrekt“? Bitte Beispiele anführen. 3) Was passiert, wenn die Fristenprüfung beim Marktpartner negativ ausfällt? Soll dann mit einer ABLEHNUNG_CRMSG geantwortet werden? Welcher RC soll dafür in der ABLEHNUNG_CRMSG verwendet werden?
 

Kommentar


 
Der Prozessschritt CR_MSG_E_3 entfällt bei diesem Prozess, daher ist auch keine Fristenprüfung beim Empfänger durchzuführen.

AT004000 A****i

Sehr geehrte Damen und Herren,


wir erlauben uns folgende Ergänzungen:

  • Die Verbrauchsermittlung erfolgt für Pauschalanlagen (NSM) weiterhin im Zuge der Abrechnung, da hier keine echten Messdaten zur Verfügung stehen.

  • Rechnerisch ermittelte Mengen ohne Netzabrechnung (Abgrenzungen aufgrund Preisänderungen o.ä.) werden nicht zur Verfügung gestellt, da diese erst nach der Netzabrechnung ermittelt werden. Der Abrechnungslauf ist kein Auslöser für CR_MSG und somit erfolgt keine neuerliche Ãœbermittlung. Ansonsten würde ein bereits übermittelter Wert nach der Abrechnung nochmals zweigeteilt bereitgestellt werden und ist nicht empfehlenswert, da hier kein Vorteil gesehen wird und die Abbildung des Prozesses wesentlich verkompliziert wird. Falls diese Mengen notwendig sind, müssten diese in den neuen Prozess MD_INT_NT übernommen werden, da hier der korrekte Auslöser den Prozess steuert.

  • Punkt „Wann werden Energiewerte übermittelt:“ Der Zeitpunkt des Ereignisses neuer Energiemengen nach Ablesungen ist inklusive einer positiven Plausibilisierung zu betrachten.

  • Punkt „Methode der Messung:“ Lastprofilmessungen (vgl. zyklische Ablesungen)

    • Hier sollte auch einheitlich die „MeteringMethod L1, L2, L3“ genutzt werden

    • Der Status „05… Fernauslesung; LPZ“ würde durch „MeteringMethod L1, L2, L3“ ersetzt werden

    •  „MetheringMethod ZZZ“ muss als Ausnahme für LPZ angeführt werden bei Ãœbermittlung von fehlenden Daten, da es ansonsten ein Widerspruch zum Prozess selbst besteht, siehe „Fehlende Daten innerhalb einer Periode:“

    • Ergänzung aus den SoMa 6 (Strom) sollte übernommen werden: Falls ein „ZZZ-Wert“ verwendet wird, muss innerhalb von 10 Arbeitstagen entweder der wahre Wert oder ein Ersatzwert nachgereicht werden.

  • Wünschenswert ist eine einheitliche, zentrale Aufstellung aller gültigen OBIS-Codes am Markt zu erstellen und mit Ergänzung des vorliegenden Vorschlag für den ConsumptionRecord wäre dies möglich. Hier fehlen aktuell die OBIS-Codes für Regelenergie, Netzverlust-Prognosedaten und für ag...

...Weiterlesen

 

Kommentar


 
Rechnerisch ermittelte Mengen aufgrund von z.B. Abgrenzungen aufgrund von Preisänderungen werden nicht an den Energielieferanten/Versorger übermittelt.

Der Abrechnungslauf bzw. das Vorliegen einer neuen Netzabrechnung ist sehr wohl ein Trigger für den Versand von Energiemengen. Da jedoch auch hier der Grundsatz „sende alles was noch nicht versendet wurde“ gilt, kommt es hier zu keinem Doppelversand.

Sämtliche neu berechnete Energiewerte sind vor Versand einer Plausibilisierung zu unterziehen.

Methoden der Messung: Werden dahingehend angepasst, das L1, L2 und L3 auch sinngemäß für den DeviceType LPZ zu verwenden sind. Daher fallen die Methoden „05“ und “ZZZ“ weg.

Alle OBIS Codes die für den Versand von Energieeinzeldaten zwischen Netzbetreiber und Energielieferant/Versorger/Anlagenbetreiber benötigt werden, sind unter https://www.ebutilities.at/documents/20200304112759_MeterCodes_ConsumptionRecord.pdf aufgelistet.

Fehler in den Prozessdiagrammen werden korrigiert.

AT001000 Wiener Netze G****r

Fristen gehören genauer definiert. Bezug auf DAVID VO gilt nur für Smart Meter.


Thema Brennwert bei Gas muss hier ebenfalls extra betrachtet werden.


Eine einheitliche Conversations ID sollte kein muss sein.  Vorschlag:

Solang ein Zählpunkt durchgehend einem Lieferanten/Versorger zugeordnet ist, KANN die gleiche Conversations ID verwendet werden.

 

Kommentar


 
Fristen entsprechend der jeweiligen gesetzlichen Bestimmungen für intelligente Messgeräte (DAVID-VO), welche auch in der Beziehung Netzbetreiber an Anlagenbetreiber anzuwenden sind.

Ergänzung wird vorgenommen:
Zusätzlich muss spätestens 2 Tage nach dem Eintreten eines Prozessauslösers der Versand von neuen Energiemengen erfolgen.

Da erst beim Vorhandensein des Brennwertes die Energiemenge berechnet werden kann, muss auch erst dann ein Versand nach den definierten Fristen erfolgen. Mögliche zukünftige Änderungen bezüglich „dynamischer“ Brennwert wurden jetzt bewusst nicht berücksichtigt, dennoch könnte schon jetzt z.B. L3 dafür verwendet werden. Sollte es zukünftig aus dieser Thematik notwendig sein, einen weiteren Status hinzuzufügen, wird dies über eine Konsultation geregelt.

Die Einheitliche Conversations ID ist nicht notwendig, somit gilt: Solang ein Zählpunkt durchgehend einem Lieferanten/Versorger zugeordnet ist, KANN die gleiche Conversations ID verwendet werden.

M****r

Für regiocom: Wir brauchen aus Lieferantensicht keine durchgängig über den Versorgungszeitraum beibehaltene ConversationID. Jede Energielieferung könnte also mit einer eigenen ConversationID versehen werden. Wir kommen aber ohne Probleme mit einer beibehaltenen ConversationID zurecht.
 

Kommentar


 
Die Einheitliche Conversations ID ist nicht notwendig, somit gilt: Solang ein Zählpunkt durchgehend einem Lieferanten/Versorger zugeordnet ist, KANN die gleiche Conversations ID verwendet werden.
  
  

CR_REQ_PT (03.90) Anfordern von Energiedaten
  
ProzessCR_REQ_PT 
Version03.90 
BezeichnungAnfordern von Energiedaten 
Gültig von04.03.2020 

Stellungnahmen

AT000000 H****Ÿ

  • Die beiden Prozesse CR_REQ_PT_E_6 „Meldung erstellen“ und „CR_REQ_PT_E_7 Meldung übermitteln“ sind unter https://ebutilities.at/utilities/prozesse/detail.php?ProcessID=231 „Beschreibung der Prozessschritte“ gegenüber den Prozessdiagrammen vertauscht.

  • Die beiden Prozesse CR_REQ_PT_E_8 „Meldung erstellen“ und „CR_REQ_PT_E_9 Meldung übermitteln“ sind unter https://ebutilities.at/utilities/prozesse/detail.php?ProcessID=231 „Beschreibung der Prozessschritte“ gegenüber den Prozessdiagrammen vertauscht.

  • Die beiden Prozesse CR_REQ_PT_E_10 „Meldung erstellen“ und „CR_REQ_PT_E_11 Meldung übermitteln“ sind unter https://ebutilities.at/utilities/prozesse/detail.php?ProcessID=231 „Beschreibung der Prozessschritte“ gegenüber den Inhalten der Prozessdiagramme um eine Nummer Verschoben und der eigentliche Prozess CR_REQ_PT_E_10 Daten verarbeiten ist nicht beschrieben/enthalten.

  • Da bei einigen Netzbetreibern das Wechselmanagement (Stammdaten) von den Zählwertmanagement entkoppelt ist, kommt es immer wieder zu nicht zuordenbaren Datenübermittlungen (ZP bei anderem LF/BG).

    Unserer Meinung nach sollte daher im Prozessen CR_REQ_PT vor dem Sub-Prozess CR_REQ_PT_S_2 „Datensatz erstellen“ ein Prüfprozess „Zählpunkt prüfen“ dazwischengeschaltet sein, damit seitens des Netzbetreibers geprüft wird, ob die Daten tatsächlich an den jeweiligen Lieferanten gesendet bzw. von diesem angefordert werden sollen/dürfen.

    Dies würde dazu führen, dass die Folgeprozesse nur in seltenen Spezialfällen (z.B. Fehler im Wechselmanagement, verzögerte Stammdaten-Informationsflüsse, etc.) anschlagen würden. So könnte vordergründig unnötige Kommunikation, aber auch Verarbeitung und Speicherung von nicht relevanten Daten verringert werden.
 

Kommentar


 
Die Prozessdiagramme werden korrigiert. Vielen Dank für den Hinweis.

Eine Prüfung der Zugehörigkeit des Zählpunktes zum jeweiligen Energielieferanten oder Anlagenbetreiber muss natürlich zwingend durch den Netzbetreiber durchgeführt werden. Bei derzeitigen Fehlern im Versand von Marktnachrichten ist davon auszugehen, dass etwaige Stammdaten nicht vollständig sind und es daher in Ausnahmefällen zu einem fehlerhaften Versand kommt. Eine automatisierte Prüfung würde bei fehlerhaften Stammdaten nichts nützen, da die Prüfung immer nur auf den Stand der Stammdaten aufbauen kann.

AT002000 A****l

Die Voraussetzung für die Übermittlung von Datenanforderungen sollten erst mit zunehmendem Grad der Einführung von Smart Meter und einhergehender Harmonisierung der Systemlandschaften der Verteilernetzbetreiber um Energiedaten des Devicetyps LPZ erweitert werden. Ebenfalls empfehlen wir eine Daten-Nachforderung für die im Wechselprozess nicht übermittelten LPZ - Energiedaten (12 bzw. 24 Monate) vorerst nicht in die CR_REQ_PT aufzunehmen. Gleiches gilt für tägliche LPZ Datenübermittlungen, da diese laut SoMa nur nach Können und Vermögen zur Verfügung zu stellen sind.
 

Kommentar


 
Eine getrennte Ablöse von MSCONS für die unterschiedlichen DeviceTypes ist nicht das Ziel dieser Änderung der Marktkommunikation. Bei vielen Netzbetreibern wird vor allem der Versand von LPZ und Smart Meter Daten oft schon jetzt aus ein und demselben System durchgeführt. Hingegen werden auch oft die Werte für den DeviceType NSM nicht im selben System verwaltet und versendet. Sollten Antworten aus mehreren Systemen erstellt werden, ist auch ein getrennter Versand über mehrere CR_MSG Prozesse möglich.
Jede Anpassung der Marktprozesse bringt meist eine Adaptierung der Systemlandschaften der Markteilnehmer mit sich.

Der Prozess CR_REQ_PT wird zu Beginn nicht für die Anforderung von historischen Daten aus dem WIES Prozess (12 Monate Sparte Strom, 24 Monate Sparte Gas) für LPZ Zählpunkte verwendet. Ein Erneuter Versand dieser Daten muss weiterhin manuell angefordert werden. Eine Umsetzung dieses Prozesses für diesen Bereich ist jedoch mittelfristig geplant.

Die Anforderung der täglichen Übermittlung durch den CP_REQ_CMI Prozess kann durch den Netzbetreiber abgelehnt werden, wenn diese nicht möglich ist (Rückmeldecode 91 „Angefordertes Ablese-/Übertragungsintervall nicht möglich “).

AT007000 W****z

Fristen:

  • In der Aufzählung ist der Punkt "maximal bis zur Umstellung auf Device Type IMS, IME oder IMN" nicht mehr relevant

Voraussetzungen

  • Der Satz: "Der Zählpunkt muss im Anforderungszeitraum den Device Type IMS, IME oder IMN besitzen." gilt nicht mehr.
 

Kommentar


 
Fristen: Korrekt. Wird in der Beschreibung adaptiert.
Voraussetzungen: Korrekt. Wird in der Beschreibung adaptiert.

AT004000 A****i

Sehr geehrte Damen und Herren,

wir erlauben uns folgende Ergänzungen

  • Prozess sollte um die Anlagenbetreiber erweitert werden, da dieser ansonsten keine Möglichkeit zur Nachforderung hat

  • Punkt Prozessschritte: Prozessschritt im Prozessdiagramm noch vorhanden, in der Prozessbeschreibung nicht mehr, wie nicht mehr notwendig (zw. CR_REQ_PT_E_4 und E_5 im Text)

  • Punkt Voraussetzungen – Sparte Gas bzw. NMS und LPZ fehlen, in Beispielen sind diese bereits angeführt

  • Punkt Fristen:

    • Anfragen bei LPZ für Strom und Gas sollte auf den Stichtag der neuen Version des CR_MSG begrenzen sein, da die historische Verfügbarkeit der 15‘/ 1h Daten für den Prozess CR_MSG in den Systemen nicht sichergestellt werden kann und der Prozesscode 94 oder ein neuer Prozesscode kann als Ablehnung genutzt werden.

    • Abgrenzung obsolet, da auch NSM, DSZ und LPZ erlaubt sind -„maximal bis zur Umstellung auf DeviceType IMS, IME oder IMN“

Freundliche Grüße

Aleksandar Stefanoski


 

Kommentar


 
Derzeit ist der Prozess CR_REQ_PT nur für den Energielieferanten bzw. Versorger bestimmt.

Die Prozessdiagramme werden korrigiert. Vielen Dank für den Hinweis.
Voraussetzungen: Korrekt. Wird in der Beschreibung adaptiert. -> Sparten nicht in der Voraussetzung geregelt

Fristen: Der CR_REQ_PT darf für den DeviceType LPZ maximal bis zum 06.09.2021 in der Vergangenheit angefordert werden. Dies wird in den Prozessbeschreibungen adaptiert.
„maximal bis zu Umstellung auf DeviceType IMS/IME oder IMN“ wird gestrichen.

AT006000 M****e

Die historischen Verbrauchswerte (Strom 12 Monate und Gas 24 Monate) der LPZ-Zählpunkte werden bis dato wenn kein automatischer Versand im Zuge des Lieferantenwechselprozesses erfolgt ist, bilateral angefordert. Die Voraussetzung des Prozess CR_REQ_PT (Voraussetzung ist ein aufrechter Liefervertrag im Anforderungszeitraum des ConsumptionRecord), würden aber zu einer Ablehnung der Anforderung führen. Dies ist dahingehend anzupassen, dass historische Daten ebenfalls angefordert werden dürfen.
 

Kommentar


 
Der Prozess CR_REQ_PT wird zu Beginn nicht für die Anforderung von historischen Daten aus dem WIES Prozess (12 Monate Sparte Strom, 24 Monate Sparte Gas) für LPZ Zählpunkte verwendet. Ein Erneuter Versand dieser Daten muss weiterhin manuell angefordert werden. Eine Umsetzung dieses Prozesses für diesen Bereich ist jedoch mittelfristig geplant.
  
  

MD_IN_NT (00.90) Information über Netzabrechnung
  
ProzessMD_IN_NT 
Version00.90 
BezeichnungInformation über Netzabrechnung 
Gültig von04.03.2020 

Stellungnahmen

AT000000 H****Ÿ

  • Da bei einigen Netzbetreibern das Wechselmanagement (Stammdaten) von den Zählwertmanagement entkoppelt ist, kommt es immer wieder zu nicht zuordenbaren Datenübermittlungen (ZP bei anderem LF/BG).

    Unserer Meinung nach sollte daher im Prozessen MD_IN_N vor dem Sub-Prozess MD_IN_NT_S_2 „Datensatz erstellen“ ein Prüfprozess „Zählpunkt prüfen“ dazwischengeschaltet sein, damit seitens des Netzbetreibers geprüft wird, ob die Daten tatsächlich an den jeweiligen Lieferanten gesendet bzw. von diesem angefordert werden sollen/dürfen.

    Dies würde dazu führen, dass die Folgeprozesse nur in seltenen Spezialfällen (z.B. Fehler im Wechselmanagement, verzögerte Stammdaten-Informationsflüsse, etc.) anschlagen würden. So könnte vordergründig unnötige Kommunikation, aber auch Verarbeitung und Speicherung von nicht relevanten Daten verringert werden.

 

Kommentar


 
Eine Prüfung der Zugehörigkeit des Zählpunktes zum jeweiligen Energielieferanten oder Anlagenbetreiber muss natürlich zwingend durch den Netzbetreiber durchgeführt werden. Bei derzeitigen Fehlern im Versand von Marktnachrichten ist davon auszugehen, dass etwaige Stammdaten nicht vollständig sind und es daher in Ausnahmefällen zu einem fehlerhaften Versand kommt. Eine automatisierte Prüfung würde bei fehlerhaften Stammdaten nichts nützen, da die Prüfung immer nur auf den Stand der Stammdaten aufbauen kann.

AT004000 A****i

Sehr geehrte Damen und Herren,


wir erlauben uns folgende Ergänzungen


  • Punkt Beschreibung: Ergänzung um Ablauf bei Stornierung von Netzabrechnungen – es ist keine Storno-Nachricht im Prozess vorgesehen. Bei mehrmaliger Abrechnung über den gleichen bzw. überschneidenden Zeitraum gilt die jüngste Nachricht - Ãœbertragungsdatum. Die Vorgehensweise ist zeitlich unbegrenzt für die Netzabrechnungen zu betrachten.

  • Punkt Fristen: Ãœbermittlung spätestens 2 Arbeitstage nach Erstellung der Netzabrechnung inkl. Fakturierung – Netzrechnung können aufgrund Prüfschritte von der Fakturierung blockiert werden und dadurch wird die Netzabrechnung nicht abgeschlossen.

  • Falls die Abrechnungsmenge in diesem Prozess übermittelt wird, kann das Umstiegsszenario ev. vereinfacht werden, da die Zwischenablesungen vor dem Stichtag 01.04.2020 nicht übermittelt werden müssen.


Freundliche Grüße

Aleksandar Stefanoski

 

Kommentar


 
Ergänzungen zum Thema „Storno“ werden sinngemäß übernommen.

Fristen: Ergänzung „Übermittlung spätestens 2 Arbeitstage nach Erstellung und Freigabe der Netzabrechnung“

Ein in der Übergangszeit zusätzlicher Versand der Energiewerte über den Prozess MD_IN_NT wird dennoch nicht in Betracht gezogen, da dieser Zusatzversand die Problematik nicht löst sondern nur hinauszögert. Eine Lösung kann hier nur durch konsistente Daten der Netzbetreiber geschaffen werden.

AT001000 Wiener Netze G****r

Für anfallende Rechnungsberichtigungen, wird die bereits übermittelte Netzrechnung storniert und eine neue Abrechnung erstellt. Da es hier zu Verbrauchsberichtigungen sowie Zeitraumsberichtigungen kommen kann, sollte hier zwingend der Prozess MD_IN_NT vorgeschrieben werden. Bitte dies in die Beschreibung aufnehmen.


Bei Endabrechnung des Kunden wird kein neuer prognostizierter Jahresverbrauch benötigt.

 

Kommentar


 
Die Annahme ist richtig und bereits in den Beschreibungen enthalten.

AT006000 M****e

Die Felder „/AnnualEnergyConsumption - Neuer Jahresverbrauch“ und „/StartDate - Neuer Jahresverbrauch ist gültig ab“ des Schemas sind als optionale Felder zu deklarieren, da diese beim Abrechnungsgrund Schlussabrechnung überflüssig sind.
 

Kommentar


 
Richtig, diese Felder sind bei der Schlussabrechnung überflüssig, da der betroffene Energielieferant diese Information nicht benötigt. Ein Setzen auf Optional erhöht jedoch auch die Fehleranfälligkeit bei allen anderen Abrechnungsgründen.

AT003101 K****r

Aus den bisherigen Erfahrungen bei Übermittlung der Verbrauchsdaten von Smart Meter (IMS und IME) gehen wir jedoch davon aus, dass nicht alle Netzbetreiber die geforderte Qualität erbringen werden. Im Vorleistungsmodell kann durch Abgleich mit der Eingangsrechnung eine Verbrauchsplausibilität durchgeführt werden. Für Zählpunkte die sich nicht im Vorleistungsmodell befinden schlagen wir  vor, den in der Abrechnung verwendeten Verbrauchswert für eine noch zu bestimmende Übergangsphase im Prozess MD_IN_NT zu übermitteln.

 

Kommentar


 
Es ist völlig richtig, dass der Netzbetreiber in Bezug auf die zu versendeten Daten ein Höchstmaß an Qualität legen muss, unabhängig davon ob sich ein Zählpunkt im Vorleistungsmodell befindet oder nicht. Ein zusätzlicher Versand der eines Verbrauchswertes in der Übergangszeit über den Prozess MD_IN_NT wird dennoch nicht in Betracht gezogen, da dieser Zusatzversand die Problematik nicht löst sondern nur hinauszögert. Eine Lösung kann hier nur durch konsistente Daten der Netzbetreiber geschaffen werden.