Marktkommunikation

Markt

Zunächst aber ein paar Worte zur Ausgangslage der Elektrizitätswirtschaft. Als ich in der Elektrizitätswirtschaft 1977 anfing, bestanden noch Gebietsmonopole, für jeden Anschluss gab es exakt einen Lieferer / Versorger der den Kunden / Abnehmer versorgte. In den 90er Jahren des letzten Jahrhunderts kam es zu einem Paradigmenwechsel, weg vom Gebietsmonopol hin zu einer marktorientierten Stromlieferung. Parallel dazu wurde dieses auch für die Gasversorgung durchgeführt, da vieles ähnlich ist und die Grundlagen sich mittlerweile angepasst haben, ignoriere ich dieses hier einmal. In Zusammenarbeit von Aufsicht, Branchenverbänden und Versorgern ist damals ein Geschäftsmodell entwickelt worden, das eine marktorientierte Lieferung zulässt, aber auf nur einem physischen Netz beruht. Kosten durch Parallelnetze sollten nicht entstehen.

Im Kern besteht dieses Modell zwei Kernelementen:

  • Der Trennung der Netze von der organisatorischen Versorgung und
  • dem Poolmodel für die Abwicklung der Geschäfte

Durch die Trennung der Funktionen und den dazugehörenden Aufgaben in unterschielichen Rollen sind mehrere Marktrollen entstanden:

LiefererLFFühren des Bilanzkreises (Bilanzkreisverantwortlicher)
Erstellen von Fahrplänen für die Beschaffung der Energie und deren Übertagung zum Kunden
MessstellenbetreiberMSBDurchführung von Messungen
VerteilnetzbetreiberVNBBetrieb und Fortentwicklung von Verteilungs- und Ortsnetze zur Versorgung von Kunden
ÜbertragungsnetzbetreiberÜNBBetrieb und Fortentwicklung eines übergeordnetten Höchst- und Hochspannungsnetzes
Beschaffung von Regelenergie (Mehr-/Mindermengen, Netzverluste, Frequenzhaltung …)
BilanzkreisverantwortlicherBKV
Erzeuger

Durch die Trennung der Versorgung auf mehrere Organisationseinheiten ist das Problem entstanden, dass Geschäftsprozesse über merere Organisationen hinweg abgewickelt werden müssen.

Marktkommunikation

Quintessenz ist, dass an der Versorgung einer Anlage immer mehrere, voneinander getrennte Organisationen beteiligt sind. Diese sind dazu verpflichtet, miteinander Kommunizieren. Die gesetzliche Grundlage ergibt sich aus StromNZV §14:

Die Netzbetreiber sind verpflichtet, für die Durchführung des Lieferantenwechsels für Letztverbraucher sowie für die Zuordnung von Einspeiseanlagen zu Händlern und Bilanzkreisen bundesweit einheitliche, massengeschäftstaugliche Verfahren anzuwenden. Für den elektronischen Datenaustausch mit den Netznutzern ist ein einheitliches Datenformat zu verwenden. Die Netzbetreiber sind verpflichtet, die elektronische Übermittlung und Bearbeitung von Kundendaten in massengeschäftstauglicher Weise zu organisieren, sodass die Kundendaten in vollständig automatisierter Weise übermittelt und bearbeitet werden können. Die Verbände der Netznutzer sind an der Entwicklung der Verfahren und Formate für den Datenaustausch angemessen zu beteiligen.

StromNZV $14 (1) Aufruf vom 13.12.2024

Dadurch das die Netzbetreiber zu einer bestimmten Art der Kommunikation verpflichtet sind, müssen auch Lieferanten und Messstellenbetreiber sich an diesen Standard halten.

Anforderungen

  • Massentauglich
  • Einheitlich
  • Automatisiert
  • Kostengünstig

Damit scheidet das allseitz beliebte Faxgerät aus.

Bereits aus diesem Absatz lassen sich mindestens zwei Ebenen der Kommunikation / Datenaustausch ableiten, eine

  • technische Ebene (die Frage danach, wie kommuniziert wird) und eine
  • organisatorische Ebene (die Frage danach, was kommuniziert wird.

Technische Ebene

Vorgaben durch die Bundesnetzagentur.

Während der Gesetzgeber noch von einem bundesweit einheitlichen, massentauglichen Verfahren spricht, werden die Vorgaben vom BDEW präzisiert: EDI@Energy. Das Verfahren basiert auf dem von der UNO herausgegebenen EDIFACT – Datenformat, das den Erfordernissen der Branche angepasst ist. Die technische Ebene erklärt also, wie die Marktteilnehmer untereinander kommunizieren. Ist in erster Linie ein technisches Problem und hat mit meinem Problem des Lieferantenwechsels nur mittelbare Bedeutung. Ich verkürze deshalt an dieser Stelle.


EDIFACT

Vollständig: United Nations / Electronic Data Interchange for Administration, Commerce and Transport (UN/EDIFACT)


EDI@Energy

Technischer Aufbau

Datei

EDIFACT – Nachrichten werden in Form von Dateien versendet.

Dateiname ist strukturiert:

  • Nachrichtentyp
  • Anwendungsrelevanz
  • Absender-Kennung
  • Empfänger-Kennung
  • Datum (jjjjmmtt)
  • Datenaustauschrelevanz
  • Suffix .txt wenn unkomprimiert, .gz bei komprimierten Dateien

Marktpartneridentifikation (Absender- / Empfänger-Kennung)

Kommunikationspartner müssen über einen Code (Marktpartner-ID, MP-ID) eindeutig zu identifizieren sein. Generell gilt bei der Idetifizierung:

  • Eine MP-ID darf ausschließlich nur für eine Sparte genutzt werden
  • Die MP-ID muss hinsichtlich der Marktrolle eindeutig sein. Dieses betrifft unter anderem Netzwerkbetreiber mit angeschlossenen Messstellenbetrieb.
  • In allen EDIFACT-Übertragungsdateien wird auf Ebene der Übertragungsdatei das UNB-Segment u. a. dazu genutzt, die Absender/Empfänger zu identifizieren. Hierzu stehen die Datenelemente 0004 (Absender) und 0010 (Empfänger) zur Verfügung.
  • Zusätzlich werden auf Nachrichtenebene (UNH-Ebene) die fachlichen Absender/Empfänger im NAD-Segment mit den Qualifier „MS“ (Absender) und „MR“ (Empfänger) im Datenelement 3035 identifiziert.
  • Die im UNB- und NAD-Segment für den Absender/Empfänger verwendeten MP-ID sind identisch.
  • Die Marktpartner-ID ist in den Datenelementen, in denen sie einzutragen ist, genauso einzutragen, wie sie in den Codenummerndatenbanken veröffentlicht ist.
  • Eventuell bereits vergebene MP-ID für die Marktrolle Dienstleister finden keine Verwendung.
  • Diese Vorgehensweise ist für alle EDI@Energy EDIFACT-Nachrichten und -dateien einheitlich anzuwenden.

In D zugelasse MP-ID

  • BDEW-Codenummern (Sparte Strom)
  • DLGW-Codenummer (Sparte Gas)
  • GLN (Global Location Number) jeweils getrennt für die Sparten Strom / Gas

Dateien können mehrere Nachrichten einer Sparte / Nachrichtenklasse von einem Anwender an einen Absender enthalten.

Nachrichtenklassen

NachrichtenklasseVerwendungMehrere NachrichtenMehrere Geschäftsvorfälle
APERAKWird verwendet, wenn bei der auf die Syntaxprüfung folgende Modellprüfungen ein Fehler aufgetreten istneinnein
CONTRLErgebnis der Syntaxprüfung einer eintreffenden Nachricht, inkl. Empfangsbestätigungneinnein
IFTSTAMitteilung über erfolgreiche / gescheiterte Prozessführung im Rahmen MSB/MDL-Prozesseneinja
INSPRTPrüfberichtneinja, je Vorgang
INVOICNetznutzungsrechnungjaja, je Nachricht
MSCONSÜbermittlung von Zählerständenja (sortenrein)ja, je Nachricht, es sei denn BMG DE1001 = Z24
ORDCHGja (sortenrein)ja, je Nachricht
ORDERSVerhandlung über Überlassung von Messgeräten zwischen MSBA und MSBNjaja, je Nachricht
ORDERSPAntwort auf ORDERSja (sortenrein)ja, je Nachricht
PARTINneinnein
PRICATPreislisten, Grundlage für die Netznutzungsrechnungjaja, jeNachricht
QUOTESGeräteübernahmeangebotjaja, je Nachricht
REMADVZahlungsavis als Antwort auf INVOIC (Ankündigung / Ablehnng der Zahlung)neinnein
REQDOCAnforderungen von Stammdaten vom Netzbetreiber
REQOTEAnforderung Geräteübernahmeangebotjaja, je Nachricht
UTILMDÜbermittlung von Stamm- und Vertragsangebotenneinja, je Vorgang
UTILTSneinja, je Vorgang

EDIFACT beinhaltet

  • Syntax Regeln um Daten zu strukturieren
  • ein interaktives Datenaustausch Protokoll (I-EDI)
  • Standardbotschaften, die einen Austausch zwischen verschiedensprachigen Ländern und unterschieldichen Branchen ermögliche

Grundstruktur von EDIFACT-Nachrichten besteht aus einer Folge von Segmenten mit den Trennungen

DateiGruppeNachricht
UNATrenn- und Begrenzungszeichen sowie Sonderzeichen werden für die Interpretationssoftware definiertOptimal
UNBDateikopf, zusammen mit dem Dateiende UNZ bildet UNB den Umschlag für die grundlegende InformationPflicht
UNGGruppenstartOptimal
UNHNachrichtenkopfPflicht
UNTEnde der Nachricht
UNEGruppenende
UNTDateiende

Organisatorische Ebene

Geschäftsprozesse zur Kundenbelieferung mit Elektrizität (GPKE)

Wie der Name besagt, handelt es sich bei der GPKE um eine verbindliche, rollenübergreifende Abwicklung von standardisierten Anwendungsfällen (Use-Cases) im Zusammenhang mit der Belieferung eines Kunden mit Elektrizität.

Diese Anwendungsfälle beschreiben

  • Wer mit wem zu kommunizieren hat
  • Welche Fristen einzuhalten sind
  • Wie Widersprüche eingelegt werden können und wie diese zu behandeln sind

Herausgegeben wird die GPKE von der Bundesnetzagentur Beschlusskammer 6

Die GPKE gilt auch für die Abwicklung in der Sparte Gas.

Use-Cases

  • Kündigung
  • Lieferende
  • Lieferbeginn
  • Beginn der Ersatz- / Grundversorgung
  • Übermittlung der bisher gemessenen Arbeits- und Leistungswerte
  • Netznutzungsabrechnung
  • Übermittlung von Preisblättern
  • Unterbrechnung der Anschlusslieferung auf Anweisung des Lieferanten
  • Wiederherstellung der Anschlusslieferung auf Anweisung des Lieferanten
  • Stornieren und Wiederherstellen der Anschusslieferung auf Anweisung des Lieferanten
  • Stammdatensynchronisation
  • Stammdatenänderungen

Wechselprozesse im Messwesen (WiM)

Use-Cases

  • Kündigung Messstellenbetrieb
  • Beginn Messstellenbetrieb
  • Verpflichtung gMSB
  • Gerätewechsel
  • Geräteübernahme
  • Messlokationsänderungen
  • Ersteinbau einer mME in eine bestehende Messlokation
  • Ersteinbau einer iME in eine bestehende Messlokation
  • Abrechnung Messstellenbetrieb
  • Abrechnung von Dienstleistungen

Bilanzkreisabrechnung (MaBiS)

Wechselprozesse für Erzeuger (MPES)


Marktkommunikation SAP

#SAP Market Communikation for Utilities bietet eine Cloud-basierte Lüsung für die ganzheitliche Verwlatun von Kommunikationsprozessen im Deutschen Energimarkt mit enger Bindung in SAP for Utilities. Wird als Software-as-a-Service (SaaS) – Produkt auf SAP Business Technology Platform (SAP BTP) ausgeliefert.

Gesetzliche Vorgaben und standardisierte Marktkommunikationsprozesse sind nicht-differenzierbare Warenprozesse. SAP Market Communikation for Utilities fürt die Konvertierung und die Datentauschprozesse als einen Service aus.

Entwicklung, Anpassung an Gesetzesänderungen liegen bei SAP, weniger Eigenentwicklung, geringere eigene Verantwortung

Prozessdukumente

Übertragungsdokumente

Application Process Engine (APE)

Market Message Transfor (MMT)

Middelware

Abgebildete Prozesse

Die anfallenden Prozesse sind typisch für die Marktrolle des Anwenders.

459 Prozesse (Prozessübersicht Stand 2025-03-26)

Messstellenbetreiber

ProzessGrundlagePartnerKlasseAnmerkung
Beginn MessstellenbetreibWiMLF, VNB
Ende MesstellenbetriebWiMLF, VBN
Kündigung MesstellenbetriebWiMLF, VBN
Verpflichtung
Gerätekonfiguration
Messlokationsänderung
Störungsbehebung
ErsteinbauWiM
MesswerteWiM
BerechnungsformelWiM
ProfilWiM
StammdatenänderungGPKE, WiM
Geschäftsdaten
Unterbrechnung und Wiederherstellung
Angebot
VNB-Wechsel
Preiskatalog
Beendigung der Abrechnung
Allgemeine Prozesse
Abos
Universalprozess

Anmerkung: Klasse = Nachrichtenklasse ohne technische Klassen


Verteilnetzbetreiber

ProzessGrundlagePartnerKlasseAnmerkung
Anmeldung von MSB für StromMSB
Anmeldung von MSB für GasMSB
Beendigung von MSB für StromMSB
Beendigung von MSB für GasMSB
Gerätekonfiguration
Ersteinbau
Messwerte
Berechnungsformel
Stammdatenänderung
HKNR-ProzesseHerkunftsnachweisregister Strom
Geschäftsdaten
Versorgung
Bestandsliste Gas
Kooperationsvereinbarung Gas (KoV)
EnergiemengenbilanzierungBKV
MeMi-PozesseLFMehr-/Mindermengen
MGV-Abrechnung
Netzbetreiberwechsel
Preiskatalog
Universalprozess

Anmerkung: Klasse = Nachrichtenklasse ohne technische Klassen


Lieferanten

ProzessGrundlagePartnerKlasseAnmerkung
Messlokationsänderung
Störungsbehebung
Ersteinbau
Messwerte
Berechnungsformel
Stammdatenänderung
Geschäftsdaten
Bestandsliste Gas
Versorgung
Abrechnung und Fakturierung
Kooperationsvereinbarung Gas (KoV)
Energiemengenbilanzierung
Redispatch
Netznutzungsrechnung
MeMi-Prozesse
VNB-Wechsel
Universalbestellprozess

Anmerkung: Klasse = Nachrichtenklasse ohne technische Klassen


Bilanzkreisverantwortliche

ProzessGrundlagePartnerKlasseAnmerkung
Kooperationsvereinbarung Gas (KoV)
Energiemengenbilanzierung
Redispatch

Anmerkung: Klasse = Nachrichtenklasse ohne technische Klassen


Monitoring


Quellen

Close Menu
error: Content is protected !!