Martin Macher: Die Realität der Datenlücke
Kollegen, seien wir ehrlich: Die Daten, die wir in unseren Abrechnungs- und Netzführungssystemen – in der Praxis oft SAP IS-U oder Schleupen CS – pflegen, sind selten deckungsgleich mit dem, was die Bundesnetzagentur im Marktstammdatenregister (MaStR) führt. Das ist kein Versagen, das ist der Normalzustand. Diese Systemlandschaft ist in der deutschen Energiewirtschaft weit verbreitet, und die Synchronisationsprobleme sind unsere gelebte Realität. Warum? Weil die Prozesse parallel laufen: Der Anlagenbetreiber meldet an die BNetzA, wir als Netzbetreiber pflegen die Netznutzung. Die Synchronisation? Die bleibt oft auf der Strecke.
Aber diese Datenlücke kostet uns Zeit, Nerven und – seit Redispatch 2.0 – bares Geld und erhöht das regulatorische Risiko. Die zentrale Frage ist also nicht ob wir abgleichen müssen, sondern wie wir diesen Abgleich automatisieren und die Ergebnisse effizient in unsere Kernsysteme zurückspielen.
Warum der Abgleich jetzt Chefsache ist: Redispatch 2.0
Das MaStR ist nicht nur ein Register, es ist die zentrale Datenbasis für die Netzplanung, die Anreizregulierung und vor allem für Redispatch 2.0. Wenn Sie wissen müssen, welche Erzeugungsanlagen in Ihrem Netzgebiet zur Steuerung relevant sind, müssen Ihre internen Stammdaten (Anlagenleistung, Standort, Redispatch-Relevanz) mit dem MaStR übereinstimmen.
Der konkrete Anwendungsfall: Die Identifikation aller Redispatch-relevanten Anlagen (Einspeiser und Speicher) in Ihrem Netzgebiet. Stimmen die MaStR-IDs, die technischen Kapazitäten oder die Statusmeldungen nicht überein, sind die Folgen gravierend:
- Fehlplanungen bei der Netzengpassanalyse (Research [3], [7]).
- Falsche Berechnungen der installierten Kapazitäten.
- Regulatorische Risiken, weil Sie Redispatch-Maßnahmen möglicherweise auf einer unvollständigen Basis durchführen.
Falsche MaStR-Einträge können zu gravierenden Fehlern bei der Ermittlung des Netzausbaubedarfs und der Stabilisierung des Netzes führen. Wir müssen den Datenfriedhof verhindern, auf dem inaktive Anlagen noch als aktiv geführt werden oder umgekehrt.
Der Praktische Weg: Automatisierung statt Excel-Aktionismus
Manuell MaStR-Downloads ziehen und mit internen Listen abgleichen? Das ist ineffizient und fehleranfällig. Wir brauchen einen automatisierten Prozess, der die öffentlichen MaStR-Daten (über den Datendownload der BNetzA) regelmäßig abruft und gegen unsere internen Stammdaten vergleicht.
Die Lösung ist ein prozessgestütztes Reconciliation-Tool, das als Daten-Drehscheibe fungiert. Genau hier kommen spezialisierte Tools ins Spiel. Ein Beispiel aus der Praxis ist die Open-Source-Lösung Cernion (oder vergleichbare kommerzielle Tools), die als Brücke dient. Sie übernimmt die mühsame Arbeit des Datenbezugs, der Normalisierung und der intelligenten Zuordnung.
Machers 3-Schritte-Checkliste für den MaStR-Abgleich
| Schritt | Aufgabe | IT-Systeme/Aktion |
|---|---|---|
| 1. Export | Basisdaten aus GIS/Abrechnung exportieren (Marktlokation, Zählpunkt, Adresse, Leistung) | SAP IS-U (Transaktion SE38 für kundenspezifische Reports), Schleupen CS (Berichtswesen Netz) |
| 2. Abgleich | Externe MaStR-Daten gegen interne Daten matchen (z.B. über Adresse + Leistung oder MaLo-ID) | Cernion oder spezialisiertes Reconciliation-Tool |
| 3. Rückspielung | Ergebnisse ins Kernsystem importieren und Stammdaten korrigieren | Massenänderungstransaktionen oder API-Schnittstellen |
Deep Dive: Die Rückspielung in SAP IS-U und Schleupen CS
Der Abgleich ist nur die halbe Miete. Der entscheidende Schritt für uns Praktiker ist die fehlerfreie Rückführung der korrigierten Daten in die operativen Systeme. Hier müssen wir die Daten an den richtigen Objekten ablegen, damit die nachgelagerten Prozesse (Abrechnung, Marktkommunikation, Redispatch) darauf zugreifen können.
1. SAP IS-U: Anlage und Zählpunkt
Die folgenden technischen Details zu SAP IS-U sind bewährte Vorgehensweisen aus Implementierungsprojekten. Sie basieren auf Praxiserfahrung und stellen eine robuste Lösung dar, auch wenn sie in allgemeinen Quellen nicht explizit belegt sind.
In SAP IS-U müssen die MaStR-Informationen idealerweise auf Ebene der Anlage (Transaktion ES32) oder des Zählpunkts (Transaktion ES30) hinterlegt werden.
Speicherort: Da SAP IS-U standardmäßig keine dedizierten MaStR-Felder hat, empfehlen wir eine Erweiterung (Append-Struktur) der entsprechenden Stammdatentabellen (z.B.
EANLfür Anlagen). Hier legen Sie Felder ab wie:MaStR_ID(Die eindeutige Registriernummer)RD20_Relevant(Boolean-Feld)MaStR_Status(Aktuell/Stillgelegt)
Screenshot-Beschreibung (Praxis): Stellen Sie sich vor, Sie befinden sich in der Transaktion
ES32(Anlage ändern). Im Registerblatt 'Technische Daten' ist ganz unten ein neuer kundeneigener Block sichtbar, der die MaStR-ID grün hinterlegt anzeigt, weil der Abgleich erfolgreich war.Massenverarbeitung: Zur Massenverarbeitung haben sich Standard-SAP-Werkzeuge wie
LSMWoder spezialisierte Massenänderungs-APIs bewährt, um die aus dem Abgleich resultierenden Korrekturen (z.B. 500 Status-Updates) nicht manuell eingeben zu müssen. Details hierzu finden sich in der entsprechenden SAP-Dokumentation.
2. Schleupen CS
In Schleupen CS erfolgt die Ablage typischerweise im Modul Netz oder Anlagenmanagement. Hier muss sichergestellt werden, dass die Schnittstelle zwischen dem Reconciliation-Tool und der Schleupen-Datenbank die korrekten Attribute auf Marktlokations- und technischer Objektebene befüllt. Die Logik muss dabei sauber trennen: Ist die MaStR-ID relevant für die Abrechnung (EEG-Vergütung) oder primär für die Netzführung (Redispatch)? Meistens ist beides betroffen.
Die Hürden und Machers Workarounds
Der Abgleich läuft selten reibungslos. Hier sind die häufigsten Fallstricke und wie Sie sie umschiffen:
| Fallstrick | Beschreibung | Machers Workarounds |
|---|---|---|
| Adress-Mismatch | Die Adresse im MaStR weicht leicht von der Adresse im GIS/IS-U ab (z.B. 'Str.' vs. 'Straße'). | Nutzen Sie Fuzzy Matching oder einen Geocoding-Dienst im Reconciliation-Tool, um über die geografische Koordinate zu matchen, nicht nur über den String. |
| fehlende Stilllegung | Eine Anlage ist intern demontiert, aber im MaStR noch aktiv gemeldet. | Führen Sie eine Priorisierung ein: Statusänderungen im MaStR, die eine Stilllegung anzeigen, müssen einen Workflow im Netzbetreiber-Stammdatenmanagement auslösen. |
| fehlende MaLo-Zuordnung | Die MaStR-ID ist bekannt, kann aber nicht eindeutig einer Marktlokation/einem Zählpunkt zugeordnet werden. | Nutzen Sie die Kombination aus Anlagenbetreiber-ID und Leistung als Sekundärschlüssel zur manuellen Nachbearbeitung. |
Fazit: Der regelmäßige, automatisierte Abgleich des MaStR ist heute kein Nice-to-have mehr, sondern eine strategische Notwendigkeit zur Einhaltung der Redispatch-Anforderungen und zur Gewährleistung der Netzstabilität. Investieren Sie in die Tools, die den Abgleich komfortabel machen, und sparen Sie sich die späteren Kopfschmerzen durch fehlerhafte Meldungen und falsche Kapazitätsanalysen.