Fehlercodes in der Marktkommunikation auswerten

Kurzantwort

Ein formaler Nachrichtenfehler steht in der CONTRL, ein fachlicher Ablehnungsgrund in der APERAK. Die CONTRL meldet Abweichungen gegen die Nachrichtenbeschreibung und weist die gesamte Übertragungsdatei zurück. Die APERAK meldet Verarbeitbarkeitsfehler je Geschäftsvorfall und lehnt nur den beanstandeten Vorgang ab.

Für die Klärung entscheidend ist der Fundort des Codes. UCI, UCM, UCS und UCD zeigen auf Übertragungsdatei, Nachricht, Segment und Datenelement. Das ERC-Segment der APERAK nennt die Fehlerart, das FTX-Segment den Fehlerort. Wer die Codes nach diesem Muster auswertet, verteilt die Bearbeitung auf die richtige Stelle und erkennt Fehlerhäufungen, bevor sie sich in Einzelfällen verlieren.

Warum die Fundstelle mehr sagt als der Code

Ein Fehlercode allein ist eine Nummer. Erst seine Position in der Rückmeldung macht daraus eine Arbeitsanweisung. Die CONTRL kennt vier Meldungsebenen, und zu jeder Ebene existiert genau ein Segment: UCI für die Übertragungsdatei, UCM für die Nachricht, UCS für das Segment, UCD für das Datenelement. Die Prüfung läuft schrittweise von der höchsten zur niedrigsten Ebene. Ein Fehler in UNA, UNB oder UNZ beendet die Prüfung sofort; erst wenn diese Ebene fehlerfrei ist, werden die Nachrichten geprüft. CONTRL/APERAK AHB 2.3m, Kap. 2.2.1 und 2.2.2

Diese Reihenfolge ist keine Formalie. Sie erklärt, warum eine CONTRL oft nur einen Fehler nennt, obwohl mehrere vorhanden sind. Wer auf der obersten Ebene korrigiert und erneut sendet, bekommt unter Umständen die nächste Rückmeldung mit dem nächsten Fehler. Die Ursache liegt dann in der Prüftiefe.

Das Anwendungshandbuch fordert ausdrücklich, den Fehler so genau wie möglich zu beschreiben. Ein genauer Fehlercode hat Vorrang vor einem allgemeinen, und die Position ist über die tiefstmögliche Meldungsebene anzugeben. CONTRL/APERAK AHB 2.3m, Kap. 2.2.2 Für die Auswertung heißt das: ein Code auf UCD-Ebene zeigt auf ein einzelnes Datenelement, ein Code auf UCI-Ebene auf die ganze Datei.

Die drei Fehlerebenen und ihre Folgen

Die Fehlerprüfung kennt zwei Stufen mit unterschiedlicher Reichweite. Die Syntaxprüfung der CONTRL bezieht sich immer auf die gesamte Übertragungsdatei. Enthält sie mindestens einen Syntaxfehler, wird der gesamte Inhalt abgelehnt. Die Verarbeitbarkeitsprüfung der APERAK arbeitet je Geschäftsvorfall. CONTRL/APERAK AHB 2.3m, Kap. 2 und Kap. 3

Innerhalb der Verarbeitbarkeitsfehler unterscheidet das Anwendungshandbuch drei Arten, und die Art steht als Kürzel in der Fehlerliste: AHB-Fehler, Zuordnungsfehler und Übernahmefehler. Die Zuordnungsfehler zerfallen in zwei Unterkategorien, die Zuordnung zu einem Objekt im IT-System des Empfängers und die Zuordnung zu einem vorausgegangenen Geschäftsvorfall. CONTRL/APERAK AHB 2.3m, Kap. 3.1

Diese Kategorisierung ist der Schlüssel zur Zuständigkeit. Ein AHB-Fehler bedeutet, dass der Absender seine Nachricht nicht nach der Prüfschablone des Prüfidentifikators gefüllt hat. Ein Zuordnungsfehler bedeutet, dass der Empfänger das angesprochene Objekt nicht findet. Die Ursache kann beim Absender liegen, etwa bei einer falschen Marktlokations-ID, aber auch beim Empfänger, etwa bei einem ungepflegten Objektbestand.

Wo der Code steht: ERC und FTX

Die APERAK trägt den Fehler an zwei Stellen. Das ERC-Segment nennt den Fehlercode im Datenelement DE9321. Das FTX-Segment mit dem Qualifier Z02 trägt die Ortsangabe des AHB-Fehlers in den Datenelementen 4440. Beides gehört zusammen, sonst bleibt der Code eine Nummer ohne Adresse. CONTRL/APERAK AHB 2.3m, Kap. 4.3 und 5.2

Für sieben AHB-Fehlercodes reicht die Angabe des Geschäftsvorfalls nicht aus, und die Ortsangabe wird verpflichtend: Z21, Z29, Z35, Z38, Z39, Z40 und Z41. Die Bezeichnung des fehlerhaften oder fehlenden Segments ist dann obligatorisch. Zusätzlich darf der Absender der APERAK das fehlerhafte Segment aus der Ursprungsdatei optional im Klartext übernehmen. CONTRL/APERAK AHB 2.3m, Kap. 3.1.2.1 und 3.1.2.2

Der Grund für dieses Verfahren ist praktisch. Die Fehlerprüfung kann stattfinden, wenn die Originaldatei beim Empfänger längst nicht mehr vorliegt. Ein Zählen von Segmenten wie in der CONTRL ist dann unmöglich. Deshalb arbeitet die Ortsangabe mit den fachlichen Bezeichnungen aus der Nachrichtenbeschreibung, die in der APERAK-MIG über den Schlüssel FTX+Z02+++ geführt werden. CONTRL/APERAK AHB 2.3m, Kap. 3.1.2.2

Eine Regel musst du beim Auswerten mitlesen. Wird der Fehler auf Nachrichtenkopfebene gefunden, etwa bei UTILMD vor SG4 oder bei INSRPT vor SG3, wird die gesamte Nachricht mit genau einer APERAK abgelehnt, und in der APERAK steht kein SG4 RFF+TN. CONTRL/APERAK AHB 2.3m, Kap. 3.1.2

Ein durchgerechnetes Beispiel

Ein Netzbetreiber sendet eine UTILMD-Anmeldung. Die Rückmeldung kommt als APERAK mit ERC+Z39 und im FTX+Z02 die Segmentbezeichnung der betroffenen Stelle. Der Code Z39 bedeutet laut Fehlerliste „Code nicht aus erlaubtem Wertebereich“, und weil er zu den sieben Codes mit Ortsangabepflicht gehört, ist die Segmentbezeichnung verpflichtend mitgeliefert. CONTRL/APERAK AHB 2.3m, Kap. 5.2 und 3.1.2.1

Die Auswertung ergibt drei Feststellungen. Erstens ist die Art AHB, der Fall gehört also in die Nachrichtenerstellung und nicht in die Stammdatenpflege. Zweitens ist genau ein Geschäftsvorfall betroffen, alle anderen Vorgänge derselben Datei laufen weiter. Drittens liegt die Ursache in einem Codewert, der im Prüfidentifikator dieses Anwendungsfalls nicht vorgesehen ist.

Eine solche Häufung ist typisch für ein Release. Ändert die BNetzA eine Codeliste oder ein AHB, entstehen gleichartige Ablehnungen bei allen Prozessen mit dem betroffenen Code. Wer die Codes über alle Vorgänge zählt, sieht die Ursache.

Fehlerhäufungen auswerten statt Einzelfälle bearbeiten

Für die Auswertung zählst du drei Merkmale getrennt: den Fehlercode, die Fehlerart aus der Spalte „Art“ und die Nachrichtenart, in der der Fehler auftritt. Die Art ist im Anwendungshandbuch je Code ausgewiesen, dazu die Angabe, ob der Code in Initial- oder Folgeprozessen genutzt werden kann. CONTRL/APERAK AHB 2.3m, Kap. 5.2

Die Zählung auf der Art liefert dir den Zuständigkeitshinweis. Steigt der Anteil der AHB-Fehler, hat der Absender ein Erzeugungsproblem, oft nach einer Formatänderung. Steigt der Anteil der Zuordnungsfehler, ist der Objektbestand einer Seite nicht aktuell. Das Anwendungshandbuch verpflichtet alle Marktpartner zu zeitnaher Pflege der Objekte und dazu, eingehende Geschäftsvorfälle sofort so abzulegen, dass neue Vorgänge ihnen zugeordnet werden können. CONTRL/APERAK AHB 2.3m, Kap. 3.1.3.5

Ein zweites Auswertungsmerkmal ist der Zeitpunkt der Rückmeldung. Ein Nachrichtenempfänger muss das Ergebnis der Syntaxprüfung unverzüglich, spätestens sechs Stunden nach Erhalt, per CONTRL mitteilen. Für die APERAK gilt bei Folgeprozessen spätestens der nächste Werktag 12 Uhr, bei Initialprozessen spätestens drei Werktage nach Eingang. CONTRL/APERAK AHB 2.3m, Kap. 2.2.3 und 3.1.5 Eine APERAK, die zwei Wochen nach Eingang eintrifft, ist selbst ein Vorgang, unabhängig davon, ob der Code inhaltlich stimmt.

Folgen und Fehlerfälle

Die Wirkung unterscheidet sich grundlegend. Eine gerechtfertigt abgelehnte Übertragungsdatei gilt samt aller enthaltenen Geschäftsvorfälle als dem Empfänger nicht zugegangen. Ein gerechtfertigt abgelehnter Geschäftsvorfall gilt für sich als nicht zugegangen. CONTRL/APERAK AHB 2.3m, Kap. 1.4 und 1.5 Bei Fristen bedeutet das: Ein Syntaxfehler kann einen ganzen Sendelauf aus der Frist werfen, ein AHB-Fehler nur einen Vorgang.

Daraus folgt die Klärungsrichtung. Liegt die Ursache beim Empfänger, hat dieser die ursprüngliche Datei in die fristgerechte Verarbeitung aufzunehmen, sofern der Prozess das noch zulässt. Die Datei gilt dann als fristgerecht eingetroffen. Liegt die Ursache beim Absender und führt eine korrigierte Neusendung zum Erfolg, gelten die Fristen des neuen Sendedatums. CONTRL/APERAK AHB 2.3m, Kap. 1.3

Zwei Fehlerfälle solltest du kennen, weil sie die Auswertung verzerren. Eine nicht gerechtfertigte Syntaxfehlermeldung löst eine bilaterale Klärung aus; danach hat der Absender der CONTRL eine Empfangsbestätigung nachzuliefern und die Datei zu prozessieren. Und wenn der Empfänger wegen eines selbst verursachten Fehlers eine Datei erneut einspielt, muss er sicherstellen, dass seine Systeme keine Syntaxfehlermeldung mit dem Fehlercode 26 senden. CONTRL/APERAK AHB 2.3m, Kap. 2.3.2 Ein Duplikat-Fehler nach einer gewollten Zweitsendung ist also kein neuer Sachverhalt.

Typische Missverständnisse

Ein häufiges Missverständnis lautet, eine negative CONTRL sei ein fachliches Nein. Die CONTRL bestätigt lediglich die Übertragung oder weist sie zurück, und die Bestätigung bedeutet ausdrücklich nicht, dass der geschäftliche Inhalt angenommen wurde. CONTRL/APERAK AHB 2.3m, Kap. 2.2.2.2

Ein zweites lautet, bei einer APERAK sei eine ganze Übertragungsdatei verloren. Die APERAK lehnt nur den betroffenen Geschäftsvorfall ab; fehlerfreie Vorgänge derselben Datei werden weiterverarbeitet. Eine Ausnahme bilden Fehler auf Nachrichtenkopfebene.

Ein drittes lautet, auf eine APERAK könne man mit einer APERAK antworten. Auf eine APERAK ist immer eine CONTRL zu senden, auf eine CONTRL gar keine CONTRL, und auf eine APERAK wird keine APERAK gesendet. CONTRL/APERAK AHB 2.3m, Kap. 3

Quellen und Pflegehinweis

Tragende Quelle ist das Anwendungshandbuch zu CONTRL und APERAK in der geltenden Fassung 2.3m. Prüfe bei jedem Release, ob die Fehlerliste in Kapitel 5.2 neue Codes erhalten hat, ob sich die Spalte der Fehlerart geändert hat und ob neue Codes ortsangabepflichtig geworden sind. Die Fehlerlisten der Antwortnachrichten mit den zugehörigen Entscheidungsbäumen stehen gesondert in den EBD und Codelisten der BNetzA. Die Vorläuferfassung 2.0b hilft beim Vergleich älterer Nachrichtenbestände.

Für den Betrieb empfehlen sich zwei Zählungen. Die Verteilung über die Fehlerart trennt Erzeugungs- von Stammdatenproblemen. Die Verteilung über den Fundort zeigt, wie oft die Prüfung auf der obersten Ebene abbricht. Wer so auswertet, bearbeitet Muster statt Einzelfälle.