Fehlercodes in der Marktkommunikation auswerten

Kurzantwort

Einen Fehlercode wertest du in drei Fragen aus. Erstens: In welcher Nachricht steht er, in einer APERAK oder in der Geschäftsantwort des Prozesses? Zweitens: Welche Fehlerart nennt die Spalte „Art“ des APERAK-Anwendungshandbuchs (AHB-Fehler, Zuordnungsfehler, Objekteigenschaftsfehler, Übernahmefehler)? Drittens: Wo steht die Fundstelle, also welches Segment oder welche ID? Die Fehlerart sagt, wer handelt. Der Code sagt, was zu prüfen ist. Die Fundstelle sagt, wo.

Die Reihenfolge der Prüfstufen, die Fristen und die Frage, wann keine APERAK kommt, stehen in CONTRL und APERAK. Dieser Artikel setzt sie voraus. Die vollständige Codetabelle mit allen Z-Codes steht in APERAK-Fehlercodes: Z-Codes erklärt. Grundlage ist das APERAK AHB 1.1, Kapitel 4.3, gültig seit dem 01.10.2026.

Drei Sorten von Codes, die man nicht mischt

In der Marktkommunikation stehen Codes mit gleichen Buchstaben an verschiedenen Stellen mit verschiedener Bedeutung. Wer die Stelle ignoriert, liest falsch.

• ERC in der APERAK: Fehlercodes aus Kapitel 4.3 des APERAK AHB, im Datenelement 9321 des ERC-Segments. Das sind die Codes dieses Artikels.
• Antwortcodes der Geschäftsantwort: Die Entscheidungsbäume (EBD) und Codelisten legen fest, mit welchem Code ein Empfänger einen Vorgang inhaltlich ablehnt oder bestätigt, etwa bei der Netznutzungsabrechnung E_0406 oder bei der Antwort auf die Nichtzahlungsavise S_0109. Das ist fachliche Antwort, nicht Verarbeitbarkeit. Siehe Codelisten und EBD.
• Statuscodes im Nachrichtentyp: Die INSRPT kennt im STS-Segment eigene Codes. Z29 bedeutet dort „Ablehnung (kein Vertragsverhältnis mehr vorhanden)“ (INSRPT 23003), in der APERAK dagegen „Erforderliche Angabe für diesen Anwendungsfall fehlt“. Gleicher Code, völlig andere Welt.

Ein Fehlercode ohne Nachrichtentyp ist deshalb keine Information.

Die Fehlerart bestimmt die Zuständigkeit

Das APERAK AHB unterscheidet vier Arten (Kap. 2.1). Die Spalte „Prozess“ ergänzt, ob der Code in Initialprozessen (I), Folgeprozessen (F) oder in beiden gebraucht wird.

• AHB-Fehler: Der Geschäftsvorfall verletzt die Prüfschablone seines Prüfidentifikators. Zuständig ist der Absender. Die Ursache liegt in der Erzeugung der Nachricht, oft nach einem Formatwechsel.
• Zuordnungsfehler (ZO Objekt, ZO Geschäftsvorfall): Der Empfänger findet das Objekt oder den Vorgänger-Geschäftsvorfall nicht. Die Ursache kann bei beiden Seiten liegen, meist bei Stammdaten oder Zeitbezug.
• Objekteigenschaftsfehler (OE): Objekt gefunden, aber falsche Eigenschaft für diesen Prüfi.
• Übernahmefehler (ÜN): Daten nicht übernehmbar.

Die Zuordnung ist nur möglich, wenn die Anwendungsübersicht der Prüfidentifikatoren für den Prüfi die Zuordnungsprüfung vorsieht (Spalte „Stelle der Zuordnungsprüfung“ = V). Bei „E“ oder ohne Eintrag darf ein Empfänger keinen Zuordnungsfehler melden (Kap. 2.1.3).

AHB-Fehler: Code, Ursache, nächster Schritt

• Z29 Erforderliche Angabe fehlt. Segment, Segmentgruppe oder Datenelement fehlt, das der Prüfi als Muss verlangt. Nächster Schritt: Fundstelle in FTX lesen, im AHB des Prüfis die Zeile suchen (AHB-Werkbank), korrigieren, neu senden.
• Z35 Format nicht eingehalten. Der Wert verletzt die Formatdefinition, zum Beispiel Länge oder Datumsformat. Schritt: Formatvorgabe im AHB, nicht in der MIG nachlesen.
• Z39 Code nicht aus erlaubtem Wertebereich. Ein Code ist für diesen Anwendungsfall nicht zugelassen. Typisch nach einem Versionswechsel, wenn eine Codeliste angepasst wurde (Versionswechsel absichern).
• Z38 Zu viele Codes. Die Paketdefinition erlaubt weniger Codes, als gesendet wurden.
• Z40 Wiederholbarkeit überschritten. Ein Segment oder eine Segmentgruppe kommt zu oft vor. Bei Segmentgruppen wird das eröffnende Segment genannt.
• Z41 Zeitangabe unplausibel und Z34 Zeitintervall negativ oder Null. Beginn liegt nach dem Ende, oder der Zeitpunkt passt nicht zu den Bedingungen des Datenelements.
• Z21 Interne Referenzierung fehlerhaft. Eine Referenz innerhalb des Geschäftsvorfalls zeigt auf Inhalt, den es nicht gibt.
• Z30 Zeitreihe unvollständig. Nur zulässig bei ALOCAT, IMBNOT, TRANOT und bestimmten MSCONS-Prüfis (13003, 13005, 13007 und weitere, Kap. 4.3).
• Z31 und Z37 Prüfi nicht verarbeitet. Z31: Der Empfänger verarbeitet diesen Prüfi in seiner Rolle gar nicht. Z37: Der Prüfi darf zwischen diesen beiden Rollen laut Anwendungsübersicht nicht ausgetauscht werden. Z31 wird vor Z37 geprüft. Schritt: Anwendungsübersicht öffnen, Richtung des Prüfis ansehen, bevor du am Inhalt suchst.

Die sieben Codes Z21, Z29, Z35, Z38, Z39, Z40 und Z41 verlangen eine Ortsangabe. Sie steht im FTX-Segment in zwei Datenelementen 4440: zuerst die fachliche Bezeichnung des fehlerhaften Segments, optional danach das Segment 1:1 aus der Ursprungsdatei. Das AHB-Beispiel für ein fehlerhaftes DTM+137 lautet FTX+Z02+++ Dokumentendatum: DTM?+137?:?:303'. Die fachliche Bezeichnung statt einer Segmentzählung ist Absicht: Die Originaldatei liegt beim Prüfer oft nicht mehr vor (Kap. 2.1.2.1 und 2.1.2.2).

Zuordnungsfehler: Code, Ursache, nächster Schritt

Die ID des Objekts steht bei diesen Codes in SG4 FTX+ABO.

• Z10 ID unbekannt (Folgeprozess). Die ID ist im System des Empfängers nicht vorhanden. Schritt: ID im Ausgangssystem gegen die Marktlokation oder Messlokation prüfen, Tippfehler und Stammdatenstand klären.
• Z14 Objekt nicht gefunden (Initialprozess). Der Empfänger konnte mit den Angaben keine Markt- oder Messlokation oder Tranche ermitteln.
• Z15 Objekt nicht eindeutig. Mehr als ein Objekt passt, nur bei Anfragen. Schritt: genauer anfragen.
• Z16 Objekt nicht mehr im Netzgebiet. Der Netzbetreiber hat das Objekt bereits an einen neuen Netzbetreiber übertragen. In SG5 RFF+Z08 steht dessen MP-ID. Schritt: Nachricht an diesen Netzbetreiber richten und Stammdaten korrigieren.
• Z17 und Z18 Absender beziehungsweise Empfänger zum Zeitpunkt nicht dem Objekt zugeordnet. Die ID ist bekannt, aber im angegebenen Zeitraum ist der Absender (Z17) oder der Empfänger (Z18) nicht am Objekt aktiv. Auch ein Zeitraum, der vor Beginn oder nach Ende der Zuordnung liegt, löst das aus. Schritt: Zeitraum der Zuordnung prüfen, etwa ob die Anmeldung schon bestätigt ist.
• Z19 Gerätenummer an der Messlokation nicht bekannt und Z20 OBIS-Kennzahl am Objekt nicht bekannt. Beide nur bei MSCONS. Die Gerätenummer oder OBIS-Kennzahl wurde nicht vorher per Stammdatenaustausch übermittelt. Schritt: sicherstellen, dass die UTILMD-Vorgänge zur Messlokation beim Empfänger erfolgreich verarbeitet sind.
• Z24, Z25, Z26 Zuordnungs-Tupel. Wie Z10, Z17 und Z18, nur für Objekte, die über mehrere Angaben zugleich identifiziert werden. Das Tupel steht in der Schreibweise (x1, x2, …, xn) in FTX+ABO.
• Z33 Referenzierter Geschäftsvorfall nicht vorhanden. Die Antwort bezieht sich auf einen Vorgang, den der Empfänger nicht hat, zum Beispiel über die Transaktionsreferenz RFF+TN.
• Z42 Konfigurations-ID zum Zeitpunkt nicht bekannt. Wie Z19 und Z20, nur für die Konfiguration, bei MSCONS.

Objekteigenschaft und Übernahme

• Z43 Geschäftsvorfall für Objekt mit der Eigenschaft nicht erlaubt. Objekt gefunden, aber es hat nicht die Eigenschaft, die für diesen Anwendungsfall nötig ist.
• Z44 Eigenschaft des Objekts weicht von der codierten Eigenschaft ab. Die Nachricht nennt eine Eigenschaft, die das Objekt nicht hat. Schritt: Stammdaten beider Seiten vergleichen.
• Z27 Vorkommastellenzahl des Zählwertes zu lang. Der Wert in einer MSCONS hat mehr Ziffern vor dem Komma, als vorab zum Register vereinbart.

Welche der Prüfungen für einen Prüfi überhaupt laufen, regelt die Anwendungsübersicht in der Spalte „Objekteigenschaft“. Ist sie leer, gibt es keinen Z43/Z44-Fall (Kap. 2.1.4).

Fehlerhäufungen statt Einzelfälle

Ein einzelner Code ist ein Klärfall. Eine Häufung ist ein Befund. Zähle drei Merkmale getrennt: Code, Art und Prüfi.

• Viele AHB-Fehler mit demselben Prüfi: Erzeugungsproblem beim Absender, oft kurz nach einem Formatwechsel. Das betrifft auch dich selbst, wenn du Absender bist.
• Viele Z10 oder Z14 bei einem Partner: Stammdatenabgleich mit diesem Partner, nicht Einzelfälle klären.
• Viele Z37 nach einem Rollenwechsel: Das System sendet Prüfis in einer Richtung, die es nicht gibt.
• Viele Z16 nach einem Netzübergang: Der Netzbetreiber wurde gewechselt, die Stammdaten sind noch beim alten.

Die Deutungen der Häufungen sind Erfahrungsregeln dieses Artikels, keine Vorgabe des AHB. Jeder einzelne abgelehnte Geschäftsvorfall gilt als nicht zugegangen (Kap. 1.5) und seine Prozessfrist läuft weiter.

Beispiel: Z17 bei einer Folgenachricht

Ein Messstellenbetreiber sendet eine MSCONS zu einer Marktlokation und erhält eine APERAK mit ERC+Z17 und im FTX die ID samt Zeitraum. Auswertung: Fehlerart ZO Objekt, Prozess F. Die ID ist beim Netzbetreiber bekannt, aber der Absender ist für den angegebenen Zeitraum nicht am Objekt zugeordnet. Der Messstellenbetreiber prüft: Beginnt sein Messstellenbetrieb an dieser Marktlokation später? Stimmen Zuordnung und Zeitraum in den Stammdaten beider Seiten? Erst danach sendet er die korrigierte Nachricht. Das Beispiel ist vereinfacht. Dass die Prüfung für MSCONS mit bestimmten BGM-Codes ausgeschlossen sein kann, regelt die Nutzungseinschränkung des Codes Z17 im AHB.

Typische Missverständnisse

„Alle Z-Codes in der Marktkommunikation sind APERAK-Codes.“ Nein. Z-Codes stehen in vielen Codelisten mit anderer Bedeutung.

„Ein Zuordnungsfehler ist immer ein Stammdatenfehler beim Absender.“ Auch der Empfänger kann ein ungepflegtes Objekt haben. Die Spalte „Art“ nennt nur die Fehlerart, nicht den Schuldigen.

„Ablehnung per APERAK und Ablehnung per Geschäftsantwort sind dasselbe.“ Die APERAK sagt, dass der Vorgang nicht verarbeitbar ist, und stößt keine Prozessantwort an. Die Geschäftsantwort entscheidet inhaltlich. Letzteres siehe auch COMDIS für den Streit um Abrechnungen.

Quellen und Pflegehinweis

Alle Codes und Bedeutungen stammen aus Kapitel 4.3 des APERAK AHB 1.1. Nicht jede Nutzungseinschränkung ist hier wiedergegeben; sie stehen je Code im AHB. Bei neuer Version die Liste in Kapitel 4.3 neu abgleichen, vor allem Codes, die neu hinzukommen.