MaStR

MaStR-Datenabgleich: So bereinigen Sie Stammdaten für Redispatch 2.0

Die IT-Strategie für saubere Anlagenstammdaten: Warum der Abgleich mit dem Marktstammdatenregister sofort Wirkung zeigt.

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:

  1. Fehlplanungen bei der Netzengpassanalyse (Research [3], [7]).
  2. Falsche Berechnungen der installierten Kapazitäten.
  3. 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. EANL fü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 LSMW oder 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.

Praxis-Fragen für Ihr Stadtwerk

Experten-Antworten von Regina Recht

Die Rückspielung über dedizierte APIs oder Massenänderungs-Schnittstellen ist LSMW vorzuziehen, da sie eine kontinuierliche (idealerweise tägliche) Synchronisation ermöglicht und die manuelle Fehlerquote reduziert – ein Muss für die Echtzeit-Anforderungen von Redispatch 2.0. Der ROI ergibt sich primär aus der Vermeidung von regulatorischen Strafen und der Reduktion manueller Nacharbeit bei Fehlmeldungen (z.B. durch Adress-Mismatch oder falsche Stilllegungsinformationen), die andernfalls erhebliche Personalkosten binden würden. Die Erweiterung des Datenmodells (ES32/EANL) ist eine einmalige CAPEX-Investition, die die Prozesse für Jahre stabilisiert.

Das Nichterkennen von Stilllegungen führt zur fehlerhaften Berechnung der installierten Kapazitäten und potenziell zur Inklusion von inaktiven Anlagen in die Netzengpassanalyse. Dies erhöht das regulatorische Risiko und kann zu unnötigen Redispatch-Maßnahmen führen, deren Kosten das Stadtwerk im Rahmen der Anreizregulierung möglicherweise nicht geltend machen kann. Ein MaStR-Status 'Stillgelegt' muss im Reconciliation-Tool eine höchste Priorität erhalten und einen automatisierten Workflow zur sofortigen internen Deaktivierung (im Schleupen CS) auslösen, um die Basis für die Netzführung und Abrechnung umgehend zu korrigieren und so die wirtschaftlichen und regulatorischen Risiken zu minimieren.

Das Geocoding (Abgleich über geografische Koordinate) ist in der Regel zuverlässiger als reines Fuzzy Matching (Stringvergleich), um Adress-Mismatches zwischen GIS/IS-U und MaStR zu überbrücken, insbesondere bei kleinen Abweichungen ('Str.' vs. 'Straße'). Wenn die MaLo-Zuordnung nur über Sekundärschlüssel (Betreiber-ID + Leistung) möglich ist, muss der manuelle Nachbearbeitungsprozess (Machers Workaround) hoch priorisiert werden. Die OPEX für manuelle Korrekturen sind hoch und können je nach Komplexität des Falls und Personalstunde zwischen 30 Minuten und mehreren Stunden pro Fall betragen. Eine automatisierte Lösung zur Adressnormalisierung ist daher langfristig deutlich kosteneffizienter.