AnmeldenLernweg starten

AHB, Formate & Datenaustausch

AHB-Testfälle entwickeln

Wie sich aus einer AHB-Zeile und einem Entscheidungsbaum konkrete Positiv- und Negativtestfälle ableiten lassen, am Beispiel der Anmeldung mit Prüfidentifikator 55001, samt Testdaten und erwarteter CONTRL, APERAK und Antwort.

Auf dieser Seite9 Abschnitte

Kurzantwort

Ein AHB-Testfall hat vier Teile: eine Ausgangslage, eine Nachricht mit genau einer bewusst gesetzten Abweichung, die erwarteten Rückmeldungen und das erwartete Ergebnis im Zielsystem. Die Vorlagen liefern zwei Dokumente. Das Anwendungshandbuch (AHB) sagt, welche Segmente und Codes für einen Prüfidentifikator gelten. Der Entscheidungsbaum (EBD) sagt, wie der Empfänger die Nachricht fachlich beantwortet und mit welchem Code.

Der Artikel führt das an der Anmeldung einer verbrauchenden Marktlokation vor: UTILMD mit Prüfidentifikator 55001, Antwort 55002 oder 55003. Grundlage sind die Fassungen UTILMD AHB Strom 2.2 und Entscheidungsbaum-Diagramme 4.3, beide vom 01.04.2026 und verbindlich ab 01.10.2026. Wer ältere Fassungen testet, braucht die Dokumente der jeweiligen Fassung; die AHB-Werkbank zeigt die geltende Fassung FV2610 und die früheren Fassungen ab FV2210.

Ausgangslage: eine AHB-Zeile lesen

Die Tabelle für 55001 steht im AHB in Kapitel 8.2 „Anmeldung einer verbrauchenden Marktlokation“ (S. 70 bis 72). Drei Spalten gehören zusammen: Anmeldung (55001, LF an NB), Bestätigung (55002, NB an LF) und Ablehnung (55003, NB an LF). Aus den ersten Zeilen entstehen schon Testfälle:

  • UNH+...+UTILMD:D:11A:UN:S2.2' ist Muss. Die Versionsnummer S2.2 gehört in jeden Testdatensatz.
  • BGM+E01+<Dokumentennummer>' ist Muss, und E01 (Anmeldungen) ist der einzige zulässige Code. Der Negativfall ist ein falscher Code.
  • DTM+137 (Nachrichtendatum, Format 303) darf nicht nach dem Erstellzeitpunkt liegen. Das ergibt einen Grenzfall mit einem Datum in der Zukunft.
  • NAD+MS (Absender) und NAD+MR (Empfänger) tragen jeweils eine MP-ID mit Codeliste 293 (BDEW).
  • IDE+24 (Vorgang), DTM+92 (Datum Vertragsbeginn) und STS+7 (Transaktionsgrund, etwa „Ein-/Auszug (Umzug)“ mit E01) beschreiben den fachlichen Anlass.
  • In der Gruppe SG6 steht RFF+Z13+55001. Der Prüfidentifikator bestimmt, welche Zeilen der Tabelle für diese Nachricht überhaupt gelten.

Wie man diese Tabelle liest, erklärt AHB lesen und anwenden; wann ein Feld Muss, Soll oder Kann ist und wie die Bedingungen funktionieren, steht in Muss, Kann und Bedingung und Prüfidentifikatoren verstehen.

Testdaten und Fristen festlegen

Vor der Nachricht kommen die Daten. Ein vereinfachtes Beispiel:

Angabe Wert
Marktlokation, verbrauchend 57891234562 (Beispiel-ID aus Die Marktlokation)
Zuordnungsbeginn Montag, 02.11.2026
Letzter zulässiger Übertragungstag der Anmeldung Donnerstag, 29.10.2026
Antwort des Netzbetreibers bis 11:00 Uhr am 1. Werktag nach dem Übertragungstag

Die Frist folgt der GPKE Teil 2 (S. 17): Der späteste Übertragungstag ist der Tag vor dem letzten Werktag vor dem Zuordnungsbeginn. Vor Montag, dem 02.11., ist der letzte Werktag Freitag, der 30.10.; der Tag davor ist Donnerstag, der 29.10. Die Antwort bestätigt oder lehnt bis 11:00 Uhr des ersten Werktags nach dem Übertragungstag (S. 21). Die Fristlogik im Detail zeigt der Ablaufatlas unter Lieferbeginn; der Prozess ist in Lieferantenwechsel in 24 Stunden erklärt.

Der Normalfall sieht in Reihenfolge so aus:

Erwartete Nachrichten im Positivfall, von oben nach unten (APERAK AHB 1.1, Kap. 2.4.1; GPKE Teil 2, Lieferbeginn). Eine CONTRL entfällt, weil die Datei syntaktisch richtig ist.

Aus dem Entscheidungsbaum die Antwortfälle ableiten

Die Bestätigung oder Ablehnung entsteht im Entscheidungsbaum. Für die Anmeldung gelten zwei Bäume, beide mit dem Netzbetreiber als prüfender Rolle (EBD 4.3, Kap. 6.6):

  • E_0622 „Prüfen, ob Anmeldung direkt ablehnbar“. Erste Frage für eine verbrauchende Marktlokation: Wurde die Vorlauffrist eingehalten? Wenn nicht, lautet die Antwort A07 („Vorlauffrist wurde nicht eingehalten“, Cluster Ablehnung).
  • E_0623 „Lieferbeginn prüfen“. Gab es eine Anfrage zur Beendigung der Zuordnung an den bisherigen Lieferanten (LFA)? Hat er fristgerecht geantwortet, und hat er widersprochen? Ohne Anfrage, bei verspäteter Antwort oder bei Zustimmung endet der Pfad bei A51 („Zustimmung“). Bei Widerspruch ohne den Code A30 endet er bei A50 („Der LFA hat der Anfrage zur Beendigung der Zuordnung widersprochen“, Ablehnung). Ein nicht spezifizierter Fehler ergibt A99, dessen Nutzung am 01.04.2027 endet.

Jeder Zweig, der in einem anderen Code endet, ist ein Testfall. Wie man einen Entscheidungsbaum liest, zeigt Codelisten und EBD. Die Antwort-Prüfidentifikatoren stehen in der Anwendungsübersicht: 55002 bestätigt mit E_0623, 55003 lehnt ab mit E_0622 oder E_0623.

Die Testfallmatrix

Aus AHB-Zeilen und Entscheidungsbaum entsteht diese Liste. Jeder Fall ändert genau einen Punkt gegenüber dem Positivfall T1.

T1, Positivfall. Alle Muss-Felder, BGM+E01, Übertragung am 29.10.2026, bisheriger Lieferant stimmt zu oder antwortet nicht. Erwartet: keine CONTRL, APERAK mit Anerkennungsmeldung (BGM+312), UTILMD 55002 mit A51.

T2, Vorlauffrist verletzt. Übertragung am Freitag, 30.10.2026 für denselben Zuordnungsbeginn. Erwartet: APERAK Anerkennung, dann UTILMD 55003 mit E_0622 und A07. Zuordnung unverändert.

T3, Widerspruch des Altlieferanten. Der LFA lehnt die Anfrage zur Beendigung der Zuordnung fristgerecht ab, ohne A30. Erwartet: 55003 mit E_0623 und A50. Dieser Fall braucht in der Testumgebung zwei Teilnehmer.

T4, Altlieferant antwortet nicht. Erwartet: 55002 mit A51, weil die Antwortfrist verstrichen ist.

T5, Syntaxfehler. Der Zähler im UNT stimmt nicht mit der Segmentzahl überein oder ein Segment ist nicht mit ' beendet. Erwartet in der Sparte Strom: eine CONTRL als Syntaxfehlermeldung (UCI DE0083 = 4). Alle Geschäftsvorfälle der Datei gelten als nicht verarbeitet, die Prozessfristen laufen ab dem erneuten Versand. Der Empfänger verarbeitet keinen der Geschäftsvorfälle der Datei. Die Syntax erklärt UNH, UNT und Nachrichtenstruktur.

T6, Verarbeitbarkeitsfehler. Die Datei ist syntaktisch richtig, aber die MaLo-ID existiert beim Netzbetreiber nicht. Erwartet: APERAK als Verarbeitbarkeitsfehlermeldung (BGM+313) mit passendem ERC-Code aus dem APERAK-AHB, etwa Z10 „ID unbekannt“ oder, wenn eine Pflichtangabe fehlt, Z29 „Erforderliche Angabe für diesen Anwendungsfall fehlt“. Es folgt keine 55002 oder 55003, weil der Geschäftsvorfall nicht in den Prozess geht.

T7, Gemischte Datei. Zwei Anmeldungen in einer Datei, eine davon fehlerhaft. Erwartet: für die gültige eine Anerkennung und die Folgeantwort, für die fehlerhafte eine Verarbeitbarkeitsfehlermeldung. Nur der fehlerhafte Geschäftsvorfall wird abgelehnt.

T8, Transportfehler. Der Empfänger liefert keine AS4-Zustellquittung. Erwartet: Die Übertragung gilt als gescheitert und wird wiederholt. CONTRL und APERAK kommen dann nicht in Betracht. Die Transportregeln stehen in AS4 und die Smart-Metering-PKI.

Die Rückmeldungen im Einzelnen, besonders zur Abgrenzung von CONTRL und APERAK, beschreibt CONTRL und APERAK; die Codes der Fehlermeldungen listet Fehlercodes analysieren.

Erwartungen sauber trennen

Jeder Testfall hält vier Ebenen auseinander:

  1. Transport: Zustellquittung ja oder nein.
  2. Syntax: CONTRL nur bei Syntaxfehler (Strom). Gas ist anders; dort sendet der Empfänger auf jede Datei eine CONTRL.
  3. Verarbeitbarkeit: APERAK mit Anerkennung oder Fehler. Frist für UTILMD und ORDERS: 45 Minuten nach Eingang.
  4. Fachliche Antwort und Zielsystem: UTILMD 55002 oder 55003 mit EBD-Code, dazu die Zuordnung zum 02.11.2026 im System des Netzbetreibers oder des Lieferanten.

Ein grünes Ergebnis auf einer Ebene beweist nichts für die nächste. Die positive APERAK heißt nur, dass der Geschäftsvorfall ordnungsgemäß in die Verarbeitung ging; ob der Netzbetreiber zuordnet, zeigt erst 55002. Die APERAK-Regeln stammen aus dem APERAK-AHB 1.1 (Kap. 1 und 2.4).

Wartung bei Versionswechseln

Testfälle gehören an eine Fassung: UTILMD AHB Strom 2.2, MIG S2.2, EBD 4.3. Bei jedem Wechsel prüft man die Änderungshistorien der Dokumente gegen die Matrix. Beispiel aus diesem Artikel: Der Code A99 („Sonstiges“) im E_0623 läuft zum 01.04.2027 aus; ein Test, der ihn erwartet, braucht dann einen konkreten Grund. Wie man das systematisch absichert, steht in Versionswechsel absichern.

Typische Missverständnisse

„Eine positive APERAK ist die Bestätigung der Anmeldung.“ Sie ist die Anerkennung der Verarbeitbarkeit. Die fachliche Antwort ist 55002 oder 55003.

„Jede Ablehnung kommt als APERAK.“ Eine Ablehnung aus dem Prozess, etwa wegen verletzter Vorlauffrist, kommt als UTILMD 55003 mit EBD-Code. APERAK meldet Verarbeitbarkeitsfehler, CONTRL Syntaxfehler.

„Ein Positivbeispiel genügt.“ Der Entscheidungsbaum E_0623 hat allein fünf Pfade, die in A50, A51 oder A99 enden; jeder braucht seinen Fall.

„Mehrere Fehler in einem Test sparen Zeit.“ Der Test sagt dann nicht, welche Regel die Ablehnung auslöste.

Quellen und Pflegehinweis

Die Fundstellen stammen aus UTILMD AHB Strom 2.2 (S. 70 bis 72), APERAK AHB 1.1, Entscheidungsbaum-Diagramme und Codelisten 4.3 sowie GPKE Teil 2 in der Lesefassung zu BK6-24-174. Erwartete SAP-Ergebnisse in einem konkreten System sind hier nicht beschrieben, weil der Atlas dafür keine belegten Angaben führt. Vor jedem Release gegen die dann gültigen Dokumente prüfen.

Abrufdatum aller Quellen: 5. Oktober 2026.

Primärquellen zum Nachlesen

  1. EDI@Energy – UTILMD Anwendungshandbuch Strom 2.2 (01.04.2026, verbindlich ab 01.10.2026)bundesnetzagentur.de
  2. EDI@Energy – APERAK Anwendungshandbuch 1.1 (01.04.2026)bundesnetzagentur.de
  3. Bundesnetzagentur – Mitteilung Nr. 56 zu den Datenformaten (Entscheidungsbaum-Diagramme und Codelisten 4.3, Allgemeine Festlegungen 6.1d)bundesnetzagentur.de
  4. Bundesnetzagentur – GPKE Teil 2, Lesefassung zum Beschluss BK6-24-174bundesnetzagentur.de
Mein Lernen

Quiz zum Artikel

Teste dein Wissen

5 Fragen zu diesem Artikel, mit Erklärung und Link zurück zur Stelle.

Quiz zum Artikel 5 Fragen

War dieser Artikel hilfreich?