Versionswechsel in der Marktkommunikation absichern

Kurzantwort

Ein Versionswechsel in der Marktkommunikation ist ein fachlicher und technischer Stichtag. Prozessregel, Anwendungshandbuch (AHB), Message Implementation Guide (MIG), Codelisten, Schnittstellen und betriebliche Abläufe müssen auf denselben Gültigkeitsstand gebracht werden. Ein Team sichert den Wechsel deshalb mit einer Quellenliste, einer Betroffenheitsanalyse, fachlichen und technischen Tests sowie einem kontrollierten Umschaltplan ab.

Der BDEW beschreibt die Marktkommunikation als standardisierte Sprache für Prozesse, Datenformate und Identifikatoren. Die Bundesnetzagentur veröffentlicht verbindliche Mitteilungen zu Datenformaten und deren Gültigkeit. Mitteilung Nr. 56 nennt für den dort beschriebenen Stand eine Gültigkeit ab 1. Oktober 2026. Welche Nachrichtentypen und Versionen im eigenen Prozess betroffen sind, muss das Projekt direkt aus der vollständigen Mitteilung und den zugehörigen Dokumenten ermitteln.

Warum ein Release mehrere Artefakte braucht

Ein Marktprozess besteht aus mehreren miteinander verbundenen Ebenen. Eine Festlegung oder Prozessbeschreibung erklärt den fachlichen Ablauf. Das AHB beschreibt, welche Felder in einer konkreten Nachricht unter welchen Bedingungen erforderlich, optional oder unzulässig sind. Der MIG erklärt die technische Struktur, etwa Segmente, Datenelemente und Wiederholungen. Codelisten liefern die zulässigen Werte. Transport und Empfang sorgen dafür, dass die Nachricht beim richtigen Marktpartner ankommt.

Diese Dokumente haben verschiedene Aufgaben. Eine neue Codeliste kann einen bisher fehlenden Wert ermöglichen. Eine AHB-Änderung kann diesen Wert nur in einem bestimmten Geschäftsvorfall zulassen. Eine MIG-Änderung kann die technische Position oder Struktur eines Feldes verändern. Das fachliche Ziel bleibt dabei der Maßstab: Das System muss den Geschäftsvorfall zum gültigen Zeitpunkt richtig verarbeiten.

Der Wechsel scheitert oft an einer Lücke zwischen diesen Ebenen. Ein Mapping kann syntaktisch gültige Nachrichten erzeugen, obwohl der Code im aktuellen Prozesskontext unzulässig ist. Ein AHB kann korrekt umgesetzt sein, während ein Empfänger noch die alte Version erwartet. Ein Prozess kann fachlich richtig modelliert sein, während die Übertragung die neue Nachrichtenversion nicht kennzeichnet.

Schritt 1: Gültigkeitsstand und Umfang feststellen

Das Team legt zuerst fest, welcher Stichtag geplant wird und welche Quelle ihn verbindlich beschreibt. Die Mitteilung der Bundesnetzagentur ist dabei der Ausgangspunkt für den dort veröffentlichten Datenformatstand. Das Projekt liest den vollständigen Geltungsbereich und dokumentiert, ob Prozessbeschreibungen, Nachrichtentypen, AHB, MIG, Codelisten oder ergänzende Hinweise betroffen sind.

Eine Releaseakte sollte mindestens enthalten:

Das Projekt sollte die Originaldokumente versioniert ablegen und den Abruf oder die Freigabe nachvollziehbar markieren. Ein Link auf eine Startseite allein beweist später nicht, welche Fassung umgesetzt wurde. Für jede verwendete Quelle gehört daher eine eindeutige Dokumentbezeichnung, ein Stand und ein Gültigkeitsdatum in die Releaseakte.

Der in Mitteilung Nr. 56 genannte Stichtag 1. Oktober 2026 ist ein zeitabhängiger Sachstand. Vor einer produktiven Umsetzung muss geprüft werden, ob die Mitteilung weiterhin den geplanten Umfang und Termin beschreibt. Die Versionsnummer eines Dokuments und der Zeitpunkt, ab dem es verwendet werden darf, sind getrennte Informationen.

Schritt 2: Fachliche Betroffenheit analysieren

Nach der Quellenprüfung beschreibt das Team die Änderungen in fachlichen Fällen. Es fragt für jede betroffene Rolle: Welcher Anlass löst den Vorgang aus, welches Objekt ist betroffen, welche Nachricht geht in welche Richtung und welches Ergebnis wird erwartet? Erst danach werden einzelne Felder und Codes den Systemobjekten zugeordnet.

Die Betroffenheitsanalyse deckt mindestens folgende Bereiche ab:

• ausgehende Nachrichten und ihre Erzeugungslogik,
• eingehende Nachrichten und ihre Validierung,
• Prüfidentifikatoren, Antwortcodes und Statuswerte,
• zeitliche Gültigkeit von Daten und Prozessschritten,
• Fehlerbehandlung, Klärfälle und Wiederholungen,
• Archivierung und Nachweis der angewendeten Version,
• Schulung und Arbeitsanweisungen für den Betrieb.

Ein sauberer Scope unterscheidet zwischen „geändert“, „neu“, „entfällt“ und „bleibt unverändert“. Das Team markiert außerdem Abhängigkeiten. Wenn ein Feld im AHB Pflicht wird, muss es eine fachliche Datenquelle geben. Wenn ein Code entfällt, braucht der Prozess einen Umgang mit historischen Nachrichten. Wenn ein Prüfpfad geändert wird, müssen positive und negative Fälle getestet werden.

Die Analyse sollte konkrete Use-Cases verwenden. „UTILMD anpassen“ ist zu ungenau. Besser ist: „Für den Prozessfall Lieferbeginn erzeugt das System ab dem Stichtag die neue zulässige Kombination aus Prüfidentifikator und Gültigkeitsdatum; bei fehlender Voraussetzung entsteht eine fachliche Rückmeldung.“ Der Satz beschreibt Anlass, Bedingung, Ergebnis und Zeitbezug.

Schritt 3: Umsetzung und Versionierung planen

Die technische Umsetzung folgt dem fachlichen Sollprozess. Das Team passt zuerst die relevanten Prüfregeln und Datenzuordnungen an. Danach aktualisiert es Format- und Codelistenreferenzen sowie die Erzeugung und Verarbeitung der Nachrichten. Die konkrete Ausprägung hängt vom eingesetzten System und der Integrationsarchitektur ab.

Für jede Nachricht muss der Versionstand erkennbar sein. Das kann über Konfiguration, Mapping, Prozessdatum oder eine andere systemische Steuerung erfolgen. Entscheidend ist, dass eine Nachricht reproduzierbar bleibt: Ein späterer Prüfer muss feststellen können, welcher Stand für die Erstellung und Verarbeitung galt.

Der Übergang braucht eine Regel für laufende Vorgänge. Nachrichten können vor dem Stichtag erstellt und danach empfangen werden. Andere Vorgänge werden erst nach dem Stichtag erzeugt, obwohl ihre Stammdaten bereits früher angelegt wurden. Das Team definiert deshalb, ob Prozessdatum, Erstellzeitpunkt, Eingang oder ein anderer fachlich vorgegebener Bezug die Version bestimmt. Diese Entscheidung darf nicht stillschweigend aus dem technischen Zeitstempel abgeleitet werden.

Für Altbestände braucht die Releaseakte eine eigene Behandlung. Historische Nachrichten bleiben unverändert archiviert. Korrekturen und Stornos können jedoch neue fachliche Regeln auslösen. Das Projekt legt anhand der gültigen Prozessdokumentation fest, ob ein Vorgang mit dem alten oder neuen Stand weitergeführt wird. Bei Unklarheit muss die Fachverantwortung entscheiden und die Begründung dokumentieren.

Schritt 4: Tests aus Regeln ableiten

Ein Testplan bildet die Änderung entlang der fachlichen Pfade ab. Für jedes geänderte Feld und jeden geänderten Code gibt es mindestens einen gültigen Fall. Dazu kommen ein fehlendes Pflichtfeld, ein unzulässiger Wert, eine falsche Kombination und ein Übergangsfall. Die Tests prüfen sowohl ausgehende als auch eingehende Nachrichten.

Eine kompakte Testmatrix enthält zum Beispiel:

Das Beispiel ist eine Teststruktur und keine Aussage über konkrete Codes oder Nachrichtenversionen. Die erwarteten Werte stammen aus dem zum Stichtag gültigen AHB und den zugehörigen Codelisten.

Fachtests prüfen Bedeutung und Folgeprozess. Technische Tests prüfen Syntax, Encoding, Übertragung und Schnittstellen. Partnertests prüfen das Zusammenspiel mit realen Kommunikationspartnern. Regressionstests sichern bestehende Prozesse ab. Ein Test gilt erst als bestanden, wenn das Ergebnis, die verwendete Dokumentversion und die Abweichungsentscheidung dokumentiert sind.

SAP-IS-U-Perspektive: Release kontrolliert in Betrieb nehmen

In SAP IS-U und angebundenen EDI-Komponenten betrifft ein Versionswechsel häufig mehrere Schichten. Marktpartner und Rollen müssen den richtigen fachlichen Vorgang bestimmen. Stammdaten müssen die erforderlichen Werte liefern. Mapping und Validierung müssen die neue Nachricht erzeugen oder verarbeiten. Monitoring und Klärfallbearbeitung müssen Fehler und Rückmeldungen verständlich anzeigen.

Das Projekt sollte die Umsetzung in Arbeitspakete schneiden:

1. Fachliches Zielbild: Prozess, Rolle, Objekt, Richtung und Ergebnis beschreiben.
2. Stammdaten: Datenquellen, Gültigkeit und Verantwortlichkeit prüfen.
3. Integration: Nachrichtenversion, Mapping, Validierung und Transport konfigurieren.
4. Prozessverarbeitung: Status, Folgeaktion, Ablehnung und Klärfall testen.
5. Betrieb: Monitoring, Berechtigungen, Archiv und Wiedervorlage anpassen.

Transaktionscodes oder kundenspezifische Erweiterungen lassen sich ohne Systemkontext nicht verlässlich benennen. Fachlich belastbarer ist eine Nachweiskette vom Dokument über den Testfall bis zum produktiven Prozess. Sie zeigt, welche Anforderung umgesetzt wurde und wo ein Fehler zu suchen ist.

Am Umschalttag braucht der Betrieb eine klare Freigabe. Sie bestätigt, dass die Dokumente vorliegen, Tests bestanden sind, Partnerabstimmungen abgeschlossen wurden und ein Rückfall- oder Korrekturplan existiert. Ein Rückfallplan darf die regulatorische Gültigkeit nicht ignorieren. Er beschreibt den Umgang mit bereits erzeugten Nachrichten und Fehlern, falls die neue Verarbeitung gestört ist.

Praxisbeispiel: Formatstand zum 1. Oktober 2026

Ein Versorger prüft die in Mitteilung Nr. 56 beschriebene Änderung mit Gültigkeit ab 1. Oktober 2026. Das Team nimmt den genannten Stichtag in den Releasekalender auf und liest den vollständigen Umfang. Es übernimmt keine Version aus einem Suchtreffer oder aus einem alten Projektordner.

Anschließend ordnet es die betroffenen Nachrichtentypen und AHB zu. Für jeden Prozessfall dokumentiert es, welche Felder, Codes und Antwortpfade tatsächlich geändert wurden. Die Entwickler aktualisieren Mapping und Prüfung. Die Fachseite stellt gültige und ungültige Fälle bereit. Der Betrieb testet Eingang, Ausgang, Rückmeldung, Archivierung und Klärfall.

Vor der Freigabe vergleichen die Verantwortlichen die produktive Konfiguration mit dem getesteten Stand. Zum Stichtag wird die neue Version aktiviert. In den ersten Betriebstagen beobachtet das Team Ablehnungsquoten, technische Fehler und ungeklärte Rückmeldungen. Jede Abweichung verweist auf die Releaseakte und bleibt mit Nachricht, Prozess und Version nachvollziehbar.

Das Beispiel beschreibt einen kontrollierten Lernablauf. Es bestätigt keine konkrete Formatänderung, die nicht in der vollständigen Mitteilung und den zugehörigen AHB nachgelesen wurde.

Typische Missverständnisse

„Ein Versionswechsel ist ein neues Mapping.“
Mapping ist nur ein Teil. Fachregeln, AHB, MIG, Codelisten, Tests und Betrieb müssen gemeinsam betrachtet werden.

„Der Downloadzeitpunkt bestimmt die Gültigkeit.“
Ein Dokument kann früher veröffentlicht werden und erst zu einem späteren Stichtag verbindlich gelten. Veröffentlichung und Gültigkeit müssen getrennt dokumentiert werden.

„Eine syntaktisch gültige Nachricht ist fachlich richtig.“
Syntax prüft die Struktur. Kontext, Codes, Bedingungen, Rolle und Folgeprozess brauchen zusätzliche fachliche Prüfungen.

„Alt und Neu können dauerhaft parallel verwendet werden.“
Parallelbetrieb braucht eine ausdrücklich definierte Übergangsregel. Ohne diese Regel entstehen uneindeutige Versionen und schwer erklärbare Ablehnungen.

„Nach der Umschaltung ist das Release abgeschlossen.“
Die Produktionsbeobachtung gehört zur Umsetzung. Erst wenn Nachrichten, Rückmeldungen und Folgeprozesse stabil verarbeitet werden, ist die Einführung abgeschlossen.

Quellen und Pflegehinweis

Der BDEW beschreibt Zweck und Einordnung der Marktkommunikation. Die Bundesnetzagentur veröffentlicht die verbindlichen Mitteilungen zu Datenformaten. Für einen konkreten Versionswechsel müssen immer die vollständige Mitteilung, die jeweils gültigen AHB, MIG, Codelisten und die Prozessfestlegung gemeinsam geprüft werden.

Mitteilung Nr. 56 nennt eine Gültigkeit ab 1. Oktober 2026. Dieser Stichtag und der konkrete betroffene Formatumfang sind bei der nächsten Umsetzung erneut zu kontrollieren. Der Artikel verwendet bewusst keine einzelnen Format- oder Codelistenversionen, die nicht aus der vorliegenden Primärquelle eindeutig hervorgehen.

• BDEW: Marktkommunikation
• Bundesnetzagentur: Mitteilung Nr. 56 zu Datenformaten

Abrufdatum der Quellen: 9. September 2026.