Dieser Prozess dient der Übermittlung von Änderungen, der in den XML Komposits MasterData - MeteringPointData, MasterData - ElectricitySpecificData und MasterData - GasSpecificData definierten Daten eines Zählpunktes.

Zweck dieses Prozess ist, dass alle betroffenen Marktpartner genau einmal über die Änderungen informiert werden.

Auslöser dieses Prozesses sind Änderungen in den unter Punkt Prozessauslösende Ereignisse angeführten Elementen. Diese Daten müssen an den Versorger versendet werden, dessen Zählpunkt von der Änderung betroffen ist. Es wird empfohlen, die Änderungen mindestens einmal täglich zu übermitteln.

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.

Das Feld MeterCode ist mit den abrechnungsrelevanten OBIS-Kennziffern zu befüllen. Bei Verwendung von Verbrauchsprofilen/Lastgängen für die Abrechnung ist unabhängig von der Granularität das Feld MeterCode für Strom mit 1-1:1.9.0 P.01 (Lieferung an Endkunden), 1-1:2.9.0 P.01 (Bezug vom Endkunden)  bzw. für Gas mit 7-1:1.9.0 P.01 (Lieferung an Endkunden) , 7-1:1.9.0 P.01 (Bezug vom Endkunden)zu befüllen.

Das Feld DSOTariffClass ist mit dem verrechnungsrelevanten Tarif lt. SNE-VO bzw. GSNE-VO zu befüllen. Folgende Werte sind möglich:

Strom:
G … Leistungsgemessen
GD … Leistungsgemessen Doppeltarif
N … Nicht gemessene Leistung
ND … Nicht gemessene Leistung Doppeltarif
U … Unterbrechbar
UD … Unterbrechbar Doppeltarif
E … Einspeisung

Gas:
G … Leistungsgemessen (keine Unterscheidung bei Verrechnung gem. §10 GSNE-VO Abs. 6a)
N … Nicht gemessene Leistung
E ... Einspeisung

Klarstellung hinsichtlich synthetischer Lastprofile im Zusammenhang mit intelligenten Messgeräten: Die zugeordneten synthetischen Lastprofile sind unabhängig vom DeviceType zu sehen, d.h. sie ändern sich mit dem Einbau eines intelligenten Messgerätes nicht (egal ob  IMS, IME oder DSZ). In der Marktkommunikation ist nur bei einem Lastprofilzähler (DeviceType LPZ) der LoadProfileType LPZ zulässig. Allen anderen DeviceTypes muss ein synthetisches Lastprofil zugeordnet sein.

Gemäß §16e ElWOG 2010 Abs. 1 sind die gemessenen Viertelstundenwerte der Erzeugungs- und Verbrauchsanlagen der teilnehmenden Netzbenutzer nach Maßgabe der Marktregeln ehestmöglich, spätestens am Folgetag, den Lieferanten sowie der Energiegemeinschaft zur Verfügung zu stellen. Dies führt dazu, dass der Lieferant zusätzlich zum Restnetzbezug bzw. Überschuss, auch die gemessenen Werte täglich in der Granularität Viertelstunde erhält. Bisher wurde ausschließlich der Restnetzbezug bzw. Überschuss in der vom Lieferanten angeforderten Granularität übermittelt wurde. Die Teilnahme bzw. das Ende der Teilnahme an einer Energiegemeinschaft hat daher die Änderung des Mess- und Übertragungsintervalls auszulösen.

Zusätzlich erhält der Lieferant die Information darüber, dass der betroffene Zählpunkt an einer Energiegemeinschaft teilnimmt bzw. nicht mehr teilnimmt. Zu diesem Zweck wurde das Schema MasterData um das Pflichtfeld EnergyCommunity erweitert:

MasterData – EnergyCommunity:

• GC --> Gemeinschaftliche Erzeugungsanlage §16a
• RC_R --> regionale Erneuerbare-Energie-Gemeinschaft §16c
• RC_L --> lokale Erneuerbare-Energie-Gemeinschaft §16c
• CC --> Bürgerenergiegemeinschaft §16b
• NONE --> keine Teilnahme an einer Energiegemeinschaft

Unabhängig davon, ob es sich um eine Erzeugungsanlage handelt, die an einer Energiegemeinschaft teilnimmt, ist der Lieferant ebenfalls darüber in Kenntnis zu setzen, wenn diese in Betrieb genommen wird und sich dadurch die Energiemenge der dazugehörigen Verbrauchsanlage verringert. Dies bedeutet, dass für jede dazugehörige Verbrauchsanlage eine MD_CHG_PD mit dem Inhalt SURPLUS oder FULL erzeugt werden muss. Zu diesem Zweck wurde das Feld TypeOfGeneration als Pflichtfeld definiert und mit dem Feldinhalt NONE ergänzt.

Anwendungsfälle zur Klarstellung:

Beispiel 1:
1 Verbrauchszählpunkt / 1 Erzeugungszählpunkt
•Gleicher Anschluss und gleicher Zähler
•Überschusseinspeisung
•TypeOfGeneration = SURPLUS der Verbrauchs- UND Erzeugungsanlage

Beispiel 2:
1 Verbrauchszählpunkt / 1 Erzeugungszählpunkt
•Gleicher Anschluss und gleicher Zähler
•Volleinspeisung
•TypeOfGeneration = FULL der Verbrauchs- UND Erzeugungsanlage

Beispiel 3:
1 Verbrauchszählpunkt / 0 Erzeugungszählpunkt
•TypeOfGeneration = NONE

Beispiel 4:
0 Verbrauchszählpunkt / 1 Erzeugungszählpunkt
•kein Eigenbedarf
•Volleinspeisung
•TypeOfGeneration = FULL Erzeugungsanlage

Umgang mit bereits bestehenden Anlagen bzw. Konstrukten per 04.04.2022:

TypeOfGeneration:
Es erfolgt kein Austausch der historischen Daten mittels dem Prozess MD_CHG_PD. Dieser ist erst ab dem Stichtag 04.04.2022 bei den oben erwähnten Anwendungsfällen prozessauslösend.

EnergyCommunity:
Für bereits bestehende Gemeinschaftskonstrukte, deren teilnehmende Verbrauchs- und Erzeugungszählpunkte vor dem 04.04.2022 einer Energiegemeinschaft zugeordnet wurden, ist der Prozess MD_CHG_PD mit dem Prozessdatum 04.04.2022 anzustoßen. Den betroffenen Lieferanten und Energieabnehmern sind ab dem Stichtag 04.04.2022 die gemessenen Werte und der Restnetzbezug täglich in der Granularität Viertelstunde zu versenden. Es erfolgt allerdings kein Energiedatenversand von historischen gemessenen Werten an die Lieferanten bzw. Energieabnehmer.

Beispiel:
1 Erzeugungszählpunkt und 5 Verbrauchszählpunkte nehmen seit 01.01.2020 an einer gemeinschaftlichen Erzeugungsanlage gemäß §16a teil.

BIS einschließlich 03.04.2022 haben der Energieabnehmer der Erzeugungsanlage und die Lieferanten der Verbrauchsanlagen keine Information darüber, ob es sich um einen Zählpunkt handelt, der an einer Energiegemeinschaft teilnimmt. Weiters erhalten sie den errechneten Überschuss bzw. Restnetzbezug in der Granularität und Periodizität, die angefordert wurde.

AB 04.04.2022 sind der Energieabnehmer und die Lieferanten darüber zu informieren, dass die betroffenen Zählpunkte an einer Energiegemeinschaft teilnehmen und sich dadurch der Device-Type, die Granularität und Periodizität geändert hat. Dieser Informationsaustausch hat mit dem Prozess MD_CHG_PD zu erfolgen.

Für die Abwicklung des Datenaustausch stehen drei Möglichkeiten zur Verfügung:

1. Prozessumsetzung in der eigenen IT-Landschaft: EDA Messenger oder EDA e-mail. Für weitere Infos kontaktieren Sie bitte eda@ebutilities.at.
   
2. Nutzung eines IT Dienstleister (SaaS): EDA Messenger, welcher durch den IT Dienstleister betrieben wird. Für weitere Infos kontaktieren Sie bitte Ihren IT Dienstleister
   
3. SelfStorage-Dienst der Verrechnungsstellen für Lieferanten: EDA Messenger, welcher durch die Verrechnungsstellen betrieben wird
   

Der energiewirtschaftliche Datenaustausch ist grundsätzlich für alle Marktteilnehmer (ausgenommen Verteilernetzbetreiber) kostenlos.

Keine

Prozessauslösend sind Änderungen von Daten, welche den XML Elementen

• MasterData - DeviceType
• MasterData - DeviceNumber
• MasterData - TypeOfGeneration
• MasterData - LoadProfileType
• MasterData - TransmissionCycle
• MasterData - DSOTariffclass
• MasterData - EnergyCommunity

• MasterData - GridUsageLevel
• MasterData - GridLossLevel
• MasterData - ShortageCapacity

• MasterData - PeakPower
• MasterData - GridUsageLevel

entsprechen. Bei Feldern die sich geändert haben, ist das Attribut Changed zu setzen.

Bei diesem Prozess ist die Übermittlung des XML-Komposit MasterData - MeteringPointData verpflichtend. Abhängig von der Sparte sind auch die XML-Komposits MasterData - ElectricitySpecificData bzw. MasterData - GasSpecificData zu übermitteln.

Voraussetzung ist ein aufrechter Liefervertrag zum Prozessdatum

Neue Schemaversion MasterData 01.31
Ergänzung Prozessauslöser und Prozessbeschreibung
Neue Schemaversion MasterData 01.30
Neue Schemaversionen MasterData 01.20
DSOTariffclass (Tarifklasse Netzbetreiber) als neues prozessauslösendes Feld aufgenommen
SupStatus (Versorgungsstatus) als neues Feld aufgenommen
Detaillierung Prozessdatum
Prozessdiagramm erweitert
Prozessschritte in Diagramm aufgenommen
Prozessschritte in Prozessbeschreibung übernommen