Kurzantwort
Ein APERAK-Z-Code ist der Fehlercode, mit dem der Empfänger einer Nachricht einen einzelnen Geschäftsvorfall als nicht verarbeitbar ablehnt. Er steht im Datenelement 9321 des ERC-Segments in der Segmentgruppe SG4 einer APERAK mit BGM+313 (Anwendungssystemfehlermeldung). Das APERAK Anwendungshandbuch 1.1 führt 27 solcher Codes, von Z10 bis Z44. Wer die APERAK erhält, also der Absender der Ursprungsdatei, muss den Fehler ohne schuldhaftes Verzögern beseitigen und eine bereinigte Übertragungsdatei senden, denn die Prozessfristen laufen weiter (Kap. 1.2). Der abgelehnte Geschäftsvorfall gilt als nicht zugegangen (Kap. 1.5).
Jeder der 27 Codes hat unten eine eigene Karte mit Beispiel und Prüfschritten, die fünf häufig gesuchten Codes Z33, Z17, Z29, Z10 und Z14 stehen zuerst. Wie die APERAK in die Prüfstufen der Sparte Strom passt und welche Fristen gelten, steht in CONTRL und APERAK. Wie du eine Häufung von Codes auswertest, zeigt Fehlercodes analysieren. Diese Seite ist das Nachschlagewerk zu den Codes selbst.
Wo der Z-Code in der APERAK steht
Der Fehlerteil einer APERAK liegt in der Segmentgruppe SG4 mit ihren Untergruppen (Kap. 3 des AHB). Das ERC-Segment mit dem Code ist Muss. Dazu kommen je nach Code weitere Angaben:
- SG4 FTX+ABO „Information über Abweichung“: Soll, wenn ein fehlerhafter Inhalt vorhanden ist. Bei den Zuordnungsfehlern steht hier die ID des Objekts und das Zeitintervall oder der Zeitpunkt, bei Z24 bis Z26 und Z33 das vollständige Tupel.
- SG5 FTX+Z02 „Ortsangabe des AHB-Fehlers“: Muss bei Z21, Z29, Z35, Z38, Z39, Z40 und Z41. Es nennt die fachliche Bezeichnung des fehlerhaften Segments, optional zusätzlich das Segment so, wie es in der Datei stand.
- SG5 RFF+Z08 „MP-ID des nachfolgenden Netzbetreibers“: Muss bei Z16.
- SG5 RFF+TN „Transaktions-Referenznummer“: Soll, wenn der Fehler auf Vorgangsebene von IFTSTA, INSRPT, UTILMD oder UTILTS liegt. Er bezeichnet den Vorgang, den der Code betrifft.
Der Code allein reicht also nicht. Erst die Kombination aus Code, Fundstelle und Referenz sagt dir, was zu tun ist. Das folgende Beispiel zeigt eine vollständige Fehlermeldung mit Z17, Segment für Segment erklärt:
+ trennt Datenelemente ·: trennt Komponenten ·' beendet das Segment ·? schützt das nächste Zeichen
UNH+1+APERAK:D:07B:UN:2.2'Nachrichtenkopf
Nachrichtentyp APERAK in der Ausgabe D 07B der UN. Die 2.2 ist die Versionsnummer der BDEW-Nachrichtenbeschreibung.
BGM+313+APK20261012001'Art der RückmeldungFehlermeldung
313 bedeutet Anwendungssystemfehlermeldung: Der Geschäftsvorfall ist nicht verarbeitbar. Eine Anerkennung trüge hier BGM+312. Dahinter steht die Dokumentennummer dieser APERAK.
DTM+137:202610121005?+00:303'Dokumentendatum
Wann die APERAK erstellt wurde, Format 303 mit der Zeitzone +00. Das Pluszeichen im Wert ist mit einem Fragezeichen geschützt.
RFF+ACE:ZUG20261012-77'Referenz, Nummer des zugehörigen Dokuments
Das AHB nennt dieses Segment „Nummer des zugehörigen Dokuments“. Es ist in der Fehlermeldung und in der Anerkennung Pflicht.
DTM+171:202610120955?+00:303'Referenzdatum
Das AHB nennt dieses Segment „Referenzdatum/-zeit“. Es gehört zur Referenz davor und ist ebenfalls Pflicht.
NAD+MS+9900123456780::293'Absender der APERAK
Die MP-ID dessen, der die APERAK schickt. Das ist der Empfänger deiner Ursprungsdatei (Codepflege 293, BDEW).
NAD+MR+9900259000002::293'Empfänger der APERAK
Die MP-ID dessen, der die APERAK erhält. Das bist du als Absender der Ursprungsdatei.
ERC+Z17'Hier steht der Z-CodeZ-Code
Datenelement 9321 des ERC-Segments, Pflicht in SG4. Z17 heißt: Der Absender ist zum angegebenen Zeitintervall oder Zeitpunkt dem Objekt nicht zugeordnet. Z17 im Detail
FTX+ABO+++Objekt 12345678900, Zeitraum 20260901 bis 20260930'Hier steht die FundstelleFundstelle
Information über Abweichung. Bei Z17 nennt dieses Segment die ID des Objekts und das Zeitintervall. Es ist ein Soll-Segment, das bei fehlerhaftem Inhalt vorhanden sein soll. Der Wortlaut ist hier erfunden.
RFF+ACW:ABC0815'Referenznummer einer vorangegangenen NachrichtReferenz
Laut AHB die „Referenznummer einer vorangegangenen Nachricht“, Pflicht in SG5.
RFF+AGO:MKIDI5422'Hier steht die Referenz auf deine NachrichtReferenz
Absenderreferenz für die Original-Nachricht: die Dokumentennummer der referenzierten Nachricht, also der Nachricht, die der Empfänger abgelehnt hat. Pflicht in SG5.
RFF+TN:VorgangsId12345'Vorgang in deiner NachrichtSoll
Transaktions-Referenznummer des referenzierten Vorgangs. Soll, wenn der Fehler auf der Vorgangsebene einer IFTSTA, INSRPT, UTILMD oder UTILTS liegt.
UNT+13+1'Nachrichtenende
13 Segmente von UNH bis UNT, dieselbe Nachrichtenreferenz 1 wie im UNH.
Alle Z-Codes im Überblick
Das AHB teilt die Codes in vier Fehlerarten (Kap. 2.1): AHB-Fehler, Zuordnungsfehler (ZO), Objekteigenschaftsfehler (OE) und Übernahmefehler (ÜN). Die Zuordnungsfehler zerfallen in „Zuordnung zu einem Objekt“ und „Zuordnung zu einem Geschäftsvorfall“. Die Prüfung läuft in dieser Reihenfolge, und beim ersten Fehler endet sie (Kap. 2.1.1).
Vorstufe: Syntax der Datei. Einen Fehler hier meldet eine CONTRL, nicht die APERAK. Die Z-Codes dieser Karte gehören zur APERAK.
- 1AHB-PrüfungArt: AHB
Der Geschäftsvorfall verletzt die Prüfschablone seines Prüfidentifikators. Alle AHB-Fehler werden genannt, danach endet die Prüfung.
- 2Zuordnung zu einem ObjektArt: ZO Objekt
Das Objekt oder ein Unterobjekt (zum Beispiel Marktlokation, Messlokation, Gerät, Register) ist beim Empfänger nicht zuordenbar. Beim ersten Scheitern bricht die Zuordnung ab.
- 3Zuordnung zu einem GeschäftsvorfallArt: ZO Geschäftsvorfall
Der Vorgänger-Geschäftsvorfall, auf den sich die Nachricht bezieht, liegt beim Empfänger nicht vor.
- 4ObjekteigenschaftArt: OE
Das Objekt wurde gefunden, hat aber nicht die Eigenschaft, die der Anwendungsfall verlangt. Nur nach erfolgreicher Zuordnung.
- 5ÜbernahmeArt: ÜN
Die Daten lassen sich nicht übernehmen, weil ein Zählwert mehr Vorkommastellen hat als vereinbart.
Die folgende Tabelle gibt alle Codes aus Kapitel 4.3 des AHB 1.1 wieder. Die Spalte „Prozess“ nennt, ob der Code in einem Initialprozess (I), einem Folgeprozess (F) oder in beiden genutzt wird. Die letzte Spalte bringt nur, was das AHB zum Code sagt; die Nutzungseinschränkungen je Nachrichtentyp stehen dort im vollen Wortlaut. Codes, die in der Tabelle des AHB nicht vorkommen, gibt es in dieser Version nicht, etwa Z11 bis Z13, Z22, Z23, Z28, Z32 und Z36.
| Code | Art | Prozess | Bedeutung | Laut AHB |
|---|---|---|---|---|
| Z10 | ZO Objekt | F | ID unbekannt | Die ID des Objekts ist im IT-System des Empfängers nicht vorhanden. Siehe Z10. |
| Z14 | ZO Objekt | I | Objekt im IT-System nicht gefunden | Mit den gelieferten Informationen ließ sich keine Markt- oder Messlokation oder Tranche ermitteln. Siehe Z14. |
| Z15 | ZO Objekt | I | Objekt im IT-System nicht eindeutig | Mehr als eine Markt- oder Messlokation oder Tranche passt. Die Prüfung gilt ausschließlich bei Anfragen. |
| Z16 | ZO Objekt | I, F | Objekt nicht mehr im Netzgebiet | Der Netzbetreiber lehnt ab, weil das Objekt bereits an einen neuen Netzbetreiber übertragen wurde. Dessen MP-ID steht in SG5 RFF+Z08. |
| Z17 | ZO Objekt | F | Absender ist zum angegebenen Zeitintervall / Zeitpunkt dem Objekt nicht zugeordnet | Das Objekt ist bekannt, der Absender ist aber im genannten Zeitraum nicht am Objekt aktiv. Siehe Z17. |
| Z18 | ZO Objekt | F | Empfänger ist zum angegebenen Zeitintervall / Zeitpunkt dem Objekt nicht zugeordnet | Gegenstück zu Z17 für den Empfänger. Ist der Empfänger ein Netzbetreiber und das Objekt eine Marktlokation oder Tranche, läuft diese Prüfung erst nach der erfolgreichen Z16-Prüfung. |
| Z19 | ZO Objekt | F | Gerätenummer zum angegebenen Zeitintervall / Zeitpunkt an der Messlokation nicht bekannt | Nur bei MSCONS. Die Gerätenummer wurde dem Empfänger nicht in einem vorhergehenden Stammdatenaustausch übermittelt. Der Absender der Fehlermeldung hat sicherzustellen, dass die UTILMD-Geschäftsvorfälle zur Messlokation erfolgreich verarbeitet sind. |
| Z20 | ZO Objekt | F | OBIS-Kennzahl zum angegebenen Zeitintervall / Zeitpunkt am Objekt nicht bekannt | Nur bei MSCONS. Die OBIS-Kennzahl oder das Medium Ausfallarbeit (Code AUA) wurde nicht im Stammdatenaustausch übermittelt. Je fehlender Kennzahl beginnt eine eigene SG4. Auch hier muss die Verarbeitung der UTILMD-Geschäftsvorfälle gesichert sein. |
| Z21 | AHB | F | Geschäftsvorfallinterne Referenzierung fehlerhaft | Nur bei UTILMD, nicht bei Änderungsmeldungen (BGM+E03). Eine Referenz innerhalb des Geschäftsvorfalls zeigt auf Inhalt, der nicht enthalten ist. Ortsangabe ist Pflicht. |
| Z24 | ZO Objekt | F | Zuordnungs-Tupel unbekannt | Das Tupel steht in der Schreibweise (x1, x2, …, xn) in SG4 FTX+ABO. Nicht anzuwenden, wenn das Objekt über ein 1-Tupel wie die Marktlokations-ID oder die Zählpunktbezeichnung identifiziert wird. |
| Z25 | ZO Objekt | F | Absender ist zum angegebenen Zeitintervall / Zeitpunkt dem durch das Zuordnungs-Tupel identifizierten Objekt nicht zugeordnet | Wie Z17, aber für Objekte, die über ein Tupel identifiziert werden. |
| Z26 | ZO Objekt | F | Empfänger ist zum angegebenen Zeitintervall / Zeitpunkt dem durch das Zuordnungs-Tupel identifizierten Objekt nicht zugeordnet | Wie Z18, aber für Objekte, die über ein Tupel identifiziert werden. |
| Z27 | ÜN | F | Vorkomma-Stellenzahl des Zählwertes ist zu lang | Nur bei MSCONS der Ausprägung VL. Der Wert hat mehr Ziffern vor dem Komma, als vorab zum Register im Stammdatenaustausch vereinbart wurden. |
| Z29 | AHB | I, F | Erforderliche Angabe für diesen Anwendungsfall fehlt | An der angegebenen Stelle fehlt eine Segmentgruppe, ein Segment, eine Datenelementgruppe oder ein Datenelement, das der Prüfidentifikator verlangt. Siehe Z29. |
| Z30 | AHB | F | Zeitreihe unvollständig | Die Zeitreihe für ein fest definiertes Zeitintervall ist unvollständig. Zulässig nur bei ALOCAT, IMBNOT, TRANOT und bestimmten MSCONS-Prüfidentifikatoren. |
| Z31 | AHB | I, F | Geschäftsvorfall wird vom Empfänger zurückgewiesen | Der Empfänger verarbeitet Geschäftsvorfälle mit diesem Prüfidentifikator in seiner Marktrolle nicht. Es folgt keine weitere Prüfung. Die Z31-Prüfung läuft immer vor der Z37-Prüfung. |
| Z33 | ZO Geschäftsvorfall | F | Referenziertes Geschäftsvorfall-Tupel nicht vorhanden | Der Geschäftsvorfall bezieht sich auf einen Vorgänger, den der Empfänger nicht hat. Siehe Z33. |
| Z34 | AHB | I, F | Zeitintervall negativ oder Null | Der Beginn liegt nach dem Ende des Intervalls, oder Beginn und Ende fallen zusammen. |
| Z35 | AHB | I, F | Format nicht eingehalten | Der Wert eines Datenelements erfüllt die Formatdefinition nicht. Die Formatdefinitionen liegen im Nummernkreis [901] bis [999]. Ortsangabe ist Pflicht. |
| Z37 | AHB | I, F | Geschäftsvorfall darf vom Sender nicht gesendet werden | Laut Anwendungsübersicht der Prüfidentifikatoren ist der Geschäftsvorfall zwischen sendender und empfangender Marktrolle nicht auszutauschen. Es folgt keine weitere Prüfung. |
| Z38 | AHB | I, F | Anzahl der übermittelten Codes überschreitet Paketdefinition | Das Paket legt eine Höchstzahl an Codes und je Code fest; sie wird überschritten. Ortsangabe ist Pflicht. |
| Z39 | AHB | I, F | Code nicht aus erlaubtem Wertebereich | Im angegebenen Datenelement steht ein Code, den die Spalte des Prüfidentifikators nicht erlaubt. Ortsangabe ist Pflicht. |
| Z40 | AHB | I, F | Segment- bzw. Segmentgruppenwiederholbarkeit überschritten | Das Segment oder die Segmentgruppe kommt öfter vor, als die Wiederholbarkeit oder eine Paketdefinition erlaubt. Bei einer Segmentgruppe wird das eröffnende Segment genannt. |
| Z41 | AHB | I, F | Zeitangabe unplausibel | Zeitpunkt oder Zeitraum ist nicht plausibel. Beispiele des AHB: ein Dokumentendatum in der Zukunft, ein MSCONS-Zeitraum, der nicht älter als das Nachrichtendatum ist. Ortsangabe ist Pflicht. |
| Z42 | ZO Objekt | F | Konfigurations-ID zum angegebenen Zeitintervall / Zeitpunkt nicht bekannt | Nur bei MSCONS der Ausprägung VL mit BGM+7 in der Sparte Strom. Die Konfigurations-ID wurde nicht im Stammdatenaustausch übermittelt. |
| Z43 | OE | F | Geschäftsvorfall für Objekt mit der Eigenschaft nicht erlaubt | Der Geschäftsvorfall wurde dem Objekt zugeordnet, das Objekt hat aber nicht die Eigenschaft, die der Anwendungsfall verlangt. |
| Z44 | OE | F | Eigenschaft des Objekts weicht von der im Geschäftsvorfall codierten Eigenschaft ab | Der Geschäftsvorfall wurde dem Objekt zugeordnet, das Objekt hat aber nicht die im Geschäftsvorfall codierte Eigenschaft. |
Bei vielen Zuordnungscodes (Z10, Z14 bis Z18, Z24 bis Z26) gilt zusätzlich: Es erfolgt keine Anwendung auf die INVOIC. Ob eine Zuordnungsprüfung für einen Geschäftsvorfall überhaupt zulässig ist, entscheidet die Anwendungsübersicht der Prüfidentifikatoren in der Spalte „Stelle der Zuordnungsprüfung“. Nur bei „V“ darf der Empfänger einen Zuordnungsfehler melden (Kap. 2.1.3).
Alle Z-Codes im Einzelnen
Hier hat jeder der 27 Codes seine eigene Karte mit Anker, zum Beispiel #z33 oder #z10. Oben stehen die fünf am häufigsten gesuchten Codes Z33, Z17, Z29, Z10 und Z14, danach folgen die übrigen nach Prüfstufe. Hinweise zur Behebung stehen als „AHB“ nur dort, wo das Handbuch sie trägt. Eigene Prüfschritte sind als „Allgemein“ gekennzeichnet.
Jede Karte gibt die Bedeutung im Wortlaut des AHB wieder und erklärt sie danach in einfachen Worten. Das Beispiel ist erfunden und zeigt, wie der Code entstehen kann. Bei den Prüfschritten steht AHBfür einen Hinweis aus dem Handbuch und Allgemein für einen eigenen Prüfschritt ohne Quelle im AHB.
Am häufigsten gesucht
Diese fünf Codes werden am meisten nachgeschlagen. Sie stehen zuerst, danach folgen alle anderen Codes nach Prüfstufe.
Z33: Referenziertes Geschäftsvorfall-Tupel nicht vorhanden
Referenziertes Geschäftsvorfall-Tupel nicht vorhanden
In einfachen Worten
Deine Nachricht verweist auf einen früheren Geschäftsvorfall, den der Empfänger nicht kennt. Er findet nichts, woran er deine Nachricht anhängen könnte. Z33 ist der einzige Code für diese Fehlerart.
Fiktives Beispiel
Ein Marktpartner beantwortet eine Anfrage und gibt als Transaktions-Referenznummer (RFF+TN) „TN-0099-0001“ an. Beim Empfänger gibt es keinen UTILMD-Vorgang mit dieser Nummer. Er antwortet mit Z33 und schreibt das Tupel in SG4 FTX+ABO. Ob die Nummer falsch ist oder der Vorgang nie ankam, kann der Empfänger so nicht erkennen.
Das prüfst du
- AHBDer Empfänger muss eingehende Geschäftsvorfälle unmittelbar so ablegen, dass neue Geschäftsvorfälle ihnen zugeordnet werden können. Wer sich auf einen eigenen Geschäftsvorfall bezieht, soll einen ausreichenden zeitlichen Abstand zwischen beiden Sendevorgängen einhalten, damit keine unnötigen, aber berechtigten Z33 entstehen (Kap. 2.1.3.5).
- AllgemeinVergleiche die Referenz in deiner Nachricht mit der Referenz der Ursprungsnachricht und kläre, ob diese eine Anerkennungsmeldung bekommen hat. Eine abgelehnte Ursprungsnachricht gilt als nicht zugegangen, eine Folgenachricht kann dann ins Leere zeigen.
Weitere Angaben des AHB
Diese Fälle nennt das AHB
- Der UTILMD-Vorgang, auf den sich die Antwort auf eine Anfrage per Transaktions-Referenznummer (RFF+TN) bezieht, fehlt beim Empfänger.
- Eine IFTSTA bezieht sich auf eine MSCONS, die der Empfänger nicht hat.
- Die in einer ALOCAT angegebene Clearingnummer ist beim Empfänger nicht vorhanden.
- Der Geschäftsvorfall, auf den sich ein Storno bezieht, fehlt beim Empfänger.
- Die ORDERS, auf die sich die ORDRSP (RFF+ON) bezieht, fehlt beim Empfänger.
- Die in einer REMADV (DOC+380, 389, 457 oder Z25) angegebene Rechnungsnummer ist beim Rechnungssteller nicht bekannt.
Welche Angaben das Tupel bilden
Das hängt vom Prozess ab. Das AHB nennt als Beispiele die Vorgangsnummer der Netznutzungsanmeldung nach GPKE und GeLi Gas, das Versionstupel der MaBiS aus Versionsangabe der Summenzeitreihe, Betrachtungszeitintervall und MaBiS-ZPB sowie die Clearingnummer nach GABi Gas (Kap. 2.1.3.2). Geprüft wird immer das gesamte Tupel. Die APERAK nennt dann das vollständige Tupel aus dem Geschäftsvorfall und sagt nicht, welche Elemente der Empfänger kennt.
Nutzungseinschränkung laut AHB
Keine Anwendung auf die INVOIC.
Nicht verwechseln mit
Z17: Absender ist zum angegebenen Zeitintervall nicht zugeordnet
Absender ist zum angegebenen Zeitintervall / Zeitpunkt dem Objekt nicht zugeordnet
In einfachen Worten
Der Empfänger kennt das Objekt, aber du bist ihm im Zeitraum deiner Nachricht nicht oder nicht für den ganzen Zeitraum zugeordnet. Es kommt auf den Zeitbezug im Geschäftsvorfall an.
Fiktives Beispiel
Ein Lieferant sendet zur Marktlokation 12345678901 Daten für den Zeitraum 01.09. bis 30.09. Der Netzbetreiber hat die Marktlokation, ordnet den Lieferanten ihr aber erst ab dem 15.09. zu. Das Intervall beginnt vor dem Beginn der Zuordnung, deshalb antwortet der Netzbetreiber mit Z17. ID und Zeitraum stehen in SG4 FTX+ABO.
Das prüfst du
- AHBBestimme den Zeitbezug des Geschäftsvorfalls: An-, Abmelde- oder Änderungsdatum bei der UTILMD, Beginn und Ende der Messperiode bei der MSCONS, sonst das Dokumentendatum (DTM+137).
- AllgemeinVergleiche den Zeitraum der Nachricht mit dem Zuordnungszeitraum in deinen Stammdaten und bei der Gegenseite.
Weitere Angaben des AHB
Welcher Zeitbezug zählt
Das AHB versteht darunter bei einer UTILMD das An- oder Abmeldedatum oder das Änderungsdatum, bei einer MSCONS die Zeitintervalle wie Beginn und Ende der Messperiode. Fehlt eine solche Angabe, gilt das Dokumentendatum DTM+137 (Fußnote 8 zu Kap. 4.3).
Die Regel dahinter
Der Absender muss dem Objekt im gesamten Intervall des Geschäftsvorfalls zugeordnet sein. Beginnt das Intervall vor dem Beginn der Zuordnung oder endet es nach dem Ende der Zuordnung, ist das mit Z17 zu melden.
Änderung gegenüber Version 1.0
Eine Nutzungseinschränkung zu UTILTS wurde gestrichen, weil ihre Bedingung seit der Umstellung auf Zeitscheiben nie mehr erfüllt wurde (Änderungshistorie, Änd-ID 27308).
Nutzungseinschränkung laut AHB
Keine Prüfung unter anderem bei der INVOIC, bei bestimmten ORDERS, REQOTE und MSCONS, bei UTILTS mit BGM+Z36 und in der Sparte Strom bei UTILMD mit BGM+E01, E03, E35 (mit LF als Empfänger) oder Z88. Die vollständige Liste steht beim Code in Kapitel 4.3.
Nicht verwechseln mit
Z29: Erforderliche Angabe für diesen Anwendungsfall fehlt
Erforderliche Angabe für diesen Anwendungsfall fehlt
In einfachen Worten
In deiner Nachricht fehlt ein Segment, eine Gruppe oder ein Datenelement, das die Prüfschablone deines Prüfidentifikators zwingend verlangt. Die Ortsangabe in der APERAK sagt dir, wo.
Fiktives Beispiel
Ein Netzbetreiber sendet eine UTILMD mit dem (erfundenen) Prüfidentifikator 99999. In der Spalte dieses Prüfidentifikators ist das Dokumentendatum Muss, in der Nachricht fehlt es. Der Empfänger lehnt mit Z29 ab. In SG5 FTX+Z02 steht die fachliche Bezeichnung „Dokumentendatum“.
Das prüfst du
- AHBLies die Ortsangabe aus SG5 FTX+Z02. Sie nennt die fachliche Bezeichnung des fehlenden Segments.
- AllgemeinÖffne die Tabelle deines Prüfidentifikators und suche die Zeile. Die AHB-Werkbank zeigt die Tabellen je Prüfidentifikator der Geschäftsnachrichten. Die APERAK selbst ist dort nicht enthalten, ihr Handbuch führt keine Tabelle je Prüfidentifikator.
- AHBPrüfe, ob die Zeile als Muss oder Muss mit erfüllter Voraussetzung gekennzeichnet ist. Nur solche Angaben können Z29 auslösen.
Weitere Angaben des AHB
Was das AHB zur AHB-Prüfung festlegt (Kap. 2.1.2)
- Mindestumfang: Die Schablone besteht aus den mit „Muss“ und „Muss mit erfüllter Voraussetzung“ gekennzeichneten Segmentgruppen und Segmenten, den Codes gemäß Paketen und Voraussetzungen und den mit „X“ und „M mit erfüllter Voraussetzung“ gekennzeichneten Datenelementen. Ein „Soll mit Bedingung“ kann deshalb nie zu einem AHB-Fehler führen.
- Ortsangabe: Bei Z29 ist sie Pflicht. Sie steht in SG5 FTX+Z02 und nennt die fachliche Bezeichnung des fehlenden Segments, optional mit dem Segment im Originalwortlaut.
- Mehrere Fehler: Alle AHB-Fehler eines Geschäftsvorfalls werden genannt. Zuordnungs-, Objekteigenschafts- und Übernahmeprüfung entfallen dann.
- Kopfebene: Liegt der Fehler auf Nachrichtenkopfebene, etwa bei UTILMD vor SG4, lehnt der Empfänger die ganze Nachricht mit genau einer APERAK ab. Darin steht kein RFF+TN.
- Zu viel Information: Angaben, die der Prüfidentifikator nicht vorsieht, ignoriert der Empfänger. Folgen daraus unerwünschte Wirkungen, trägt sie der Absender.
Wenn der Prüfidentifikator selbst fehlt
Fehlt der Prüfidentifikator ganz oder ist er ungültig, kommt es nicht bis zur AHB-Prüfung. Die Übertragungsdatei wird schon in der Syntaxprüfung abgelehnt (Fußnote 3 zu Kap. 2.1.2).
Nicht verwechseln mit
Z10: ID unbekannt: Objekt im System des Empfängers nicht vorhanden
ID unbekannt
In einfachen Worten
Die ID, mit der du das Objekt benennst, gibt es im System des Empfängers nicht. Er kann deine Nachricht deshalb keinem Objekt zuordnen.
Fiktives Beispiel
Ein Lieferant sendet einen Folgevorgang zur Marktlokation 98765432109. Im IT-System des Netzbetreibers ist diese ID nicht vorhanden, im Beispiel weil der Lieferant zwei Ziffern vertauscht hat. Der Netzbetreiber antwortet mit Z10 und nennt die ID in SG4 FTX+ABO.
Das prüfst du
- AllgemeinPrüfe die gesendete ID gegen die ID im Quellsystem.
- AllgemeinFrage nach, ob das Objekt beim Empfänger schon angelegt ist.
- AHBBeide Seiten müssen ihre Objekte zeitnah im IT-System pflegen, damit nur berechtigte Zuordnungsfehler gemeldet werden (Kap. 2.1.3.5).
Weitere Angaben des AHB
Wie das Objekt in Folgeprozessen gefunden wird
In Folgeprozessen wird das Objekt ausschließlich über die ID der Markt- oder Messlokation identifiziert (Kap. 2.1.3.6). Fehlt genau diese ID im System, ist es Z10. Das AHB nennt als Beispiel die Marktlokations-ID einer Tranche. Für Initialprozesse gilt der Code Z14.
Wenn die ID vorhanden ist
Ist die ID des Objekts vorhanden, aber der Absender oder der Empfänger im angegebenen Zeitraum dem Objekt nicht zugeordnet, ist stattdessen Z17 oder Z18 zu verwenden.
Nutzungseinschränkung laut AHB
Keine Anwendung auf die INVOIC. In der Sparte Gas schließt das AHB die Prüfung für zwei UTILMD-Konstellationen aus (BGM+E35 mit LF als Empfänger, BGM+E01 mit NB als Empfänger und LF als Absender).
Nicht verwechseln mit
- Z14Z14 gilt in Initialprozessen, in denen die Vorgaben der Festlegung das Objekt bestimmen. Z10 gilt in Folgeprozessen, in denen die ID das Objekt bestimmt.
- Z17Bei Z17 kennt der Empfänger die ID, der Absender ist dem Objekt aber im Zeitraum nicht zugeordnet.
- Z24Z24 meldet ein unbekanntes Tupel aus mehreren Angaben statt einer einzelnen ID.
Z14: Objekt im IT-System nicht gefunden
Objekt im IT-System nicht gefunden
In einfachen Worten
Mit den Angaben in deiner ersten Nachricht findet der Empfänger keine Markt- oder Messlokation und keine Tranche. Z14 ist das Gegenstück zu Z10 für Initialprozesse.
Fiktives Beispiel
Ein Marktpartner startet einen Initialprozess und liefert die Angaben, mit denen der Empfänger das Objekt ermitteln soll, hier erfunden: Musterweg 1, 12345 Beispielstadt und Zähler-Nr. 000111. Der Empfänger findet dazu weder eine Markt- noch eine Messlokation und antwortet mit Z14.
Das prüfst du
- AllgemeinVergleiche die identifizierenden Angaben deiner Nachricht mit den Vorgaben der jeweiligen Festlegung. Das AHB beschreibt hier nur, wann der Code zu senden ist, nicht, wie der Absender ihn behebt.
- AHBPrüfe, ob dein Vorgang ein Initialprozess ist. Nur dann gilt Z14, im Folgeprozess meldet der Empfänger Z10.
Weitere Angaben des AHB
Initialprozess und Folgeprozess
Im Folgeprozess identifiziert die ID der Markt- oder Messlokation das Objekt, deshalb gibt es dort Z10. In Initialprozessen der GPKE, GeLi Gas und WiM gelten dagegen die Identifizierungsvorgaben der jeweiligen Festlegungen (Kap. 2.1.3.6).
Nutzungseinschränkung laut AHB
Keine Anwendung auf die INVOIC.
Nicht verwechseln mit
AHB-PrüfungArt: AHB
Der Geschäftsvorfall verletzt die Prüfschablone seines Prüfidentifikators. Alle AHB-Fehler werden genannt, danach endet die Prüfung. Z29 steht oben bei den häufig gesuchten Codes.
Z21: Interne Referenz im Geschäftsvorfall fehlerhaft
Geschäftsvorfallinterne Referenzierung fehlerhaft
In einfachen Worten
Eine Stelle in deiner UTILMD verweist auf eine andere Stelle desselben Geschäftsvorfalls, und dieses Ziel gibt es dort nicht.
Fiktives Beispiel
Eine Anmeldebestätigung für eine verbrauchende Marktlokation verweist in einer Zeile auf die Zählernummer „ZN-000042“. Im Geschäftsvorfall kommt aber keine Zeile mit dieser Zählernummer vor. Der Empfänger lehnt mit Z21 ab und nennt den Ort in SG5 FTX+Z02.
Das prüfst du
- AHBLies die Ortsangabe aus SG5 FTX+Z02. Bei Z21 ist sie Pflicht.
- AllgemeinPrüfe jede Referenz im Geschäftsvorfall: Gibt es das Segment, auf das sie zeigt, im selben Geschäftsvorfall?
- AHBBeachte, dass nur Referenzen zählen, die der Anwendungsfall laut AHB überhaupt vorsieht.
Weitere Angaben des AHB
Was geprüft wird
Es werden nur Referenzen geprüft, die laut AHB im Anwendungsfall auch vorkommen können. Mindestens eine davon muss fehlerhaft sein. Das AHB nennt als Beispiel die Referenz auf die ID der Markt- oder Messlokation, die Zählernummer oder die OBIS-Kennzahl.
Nutzungseinschränkung laut AHB
Nur bei UTILMD-Eingang und nicht bei Änderungsmeldungen (BGM+E03).
Nicht verwechseln mit
Z30: Zeitreihe im Übertragungszeitraum unvollständig
Zeitreihe unvollständig
In einfachen Worten
In der Zeitreihe fehlen Werte für Zeitpunkte, die gefüllt sein müssen. Der Empfänger nimmt die Reihe deshalb nicht an.
Fiktives Beispiel
Ein Netzbetreiber sendet für den Bilanzierungsmonat Mai eine MSCONS mit Viertelstundenwerten. Für den 14.05. fehlen alle Werte. Der Empfänger prüft den Zeitraum aus SG6, findet die Lücke und lehnt mit Z30 ab.
Das prüfst du
- AHBBestimme den Zeitraum, der vollständig gefüllt sein muss: Bilanzierungsmonat in SG6 oder die beiden DTM-Segmente der SG6.
- AllgemeinZähle die Werte der Zeitreihe und vergleiche sie mit der erwarteten Zahl. Bei Viertelstundenwerten sind es 96 je Tag, an den Tagen der Zeitumstellung 92 oder 100.
- AHBPrüfe, ob dein Prüfidentifikator in der Liste der Nutzungseinschränkung steht. Nur dann kann Z30 kommen.
Weitere Angaben des AHB
Welcher Zeitraum gefüllt sein muss
Er ergibt sich aus dem in SG6 angegebenen Bilanzierungsmonat oder aus den DTM-Segmenten „Beginn Messperiode Übertragungszeitraum“ und „Ende Messperiode Übertragungszeitraum“ der SG6.
Worauf der Code sich bezieht
Er gilt ausschließlich für die Segmente, die die Energiemenge samt allen zusätzlichen Statusinformationen übermitteln.
Nutzungseinschränkung laut AHB
Nur bei ALOCAT, IMBNOT, TRANOT und bei MSCONS mit den Prüfidentifikatoren 13003, 13005, 13007, 13008, 13010, 13011, 13012, 13018, 13020, 13021, 13022, 13023, 13025 und 13026.
Nicht verwechseln mit
Z31: Empfänger verarbeitet diesen Geschäftsvorfall grundsätzlich nicht
Geschäftsvorfall wird vom Empfänger zurückgewiesen
In einfachen Worten
Der Empfänger bearbeitet Nachrichten mit diesem Prüfidentifikator in seiner Marktrolle nicht. Weitere Prüfungen finden nicht mehr statt.
Fiktives Beispiel
Ein Lieferant sendet die Abmeldung einer Netznutzung an einen Messstellenbetreiber. Der Messstellenbetreiber verarbeitet diesen Prüfidentifikator in seiner Rolle nicht und antwortet mit Z31. Das ist das Beispiel, das auch das AHB nennt.
Das prüfst du
- AllgemeinPrüfe, ob du die Nachricht an die richtige Marktrolle gesendet hast.
- AHBNimm den Code ernst: Mit Z31 endet die Prüfung des Geschäftsvorfalls, es folgt keine weitere Fehlerliste.
Weitere Angaben des AHB
Reihenfolge zu Z37
Die Prüfungen, die zu Z31 führen, laufen immer vor den Prüfungen, die zu Z37 führen würden.
Was als Missbrauch gilt
Ein Missbrauch liegt zum Beispiel vor, wenn der Empfänger den fehlerfreien Geschäftsvorfall verarbeiten würde, dieser aber einen Fehler enthält, für den es noch keinen Fehlercode gibt.
Nicht verwechseln mit
- Z37Bei Z31 verarbeitet der Empfänger den Prüfidentifikator nie. Bei Z37 darf der Sender ihn an diese Rolle nicht senden. Z31 wird zuerst geprüft.
Z34: Zeitintervall negativ oder Null
Zeitintervall negativ oder Null
In einfachen Worten
Der Beginn deines Zeitraums liegt nach dem Ende, oder Beginn und Ende sind gleich. Dann ist es ein Zeitpunkt und kein Zeitraum.
Fiktives Beispiel
Eine ORDERS fordert Messwerte an. In SG29 steht als Beginn (DTM+163) der 15.03.2026 07:00 und als Ende (DTM+164) der 15.03.2026 06:00. Der Beginn liegt nach dem Ende, der Empfänger meldet Z34.
Das prüfst du
- AllgemeinLies Beginn und Ende des gemeldeten Segments nebeneinander und vergleiche sie.
- AHBPrüfe, ob Beginn und Ende zusammenfallen. Dann gilt das Intervall ebenfalls als Null.
- AHBWurde das Intervall in zwei Segmenten übertragen, achte auf den Qualifier im DE2005, damit Beginn und Ende nicht vertauscht sind.
Weitere Angaben des AHB
Zwei Arten, ein Zeitintervall zu übertragen
- In einem DTM-Segment: Im DE2380 stehen Beginn und Ende, die erste Hälfte der Zeichenkette ist der Beginn, die zweite das Ende.
- In zwei DTM-Segmenten: Der Code im DE2005 sagt, ob der Inhalt von DE2380 der Beginn oder das Ende ist.
Wie der Fehlerort in FTX+ABO steht
Bei einem Segment steht im ersten DE4440 das Segment des negativen Zeitintervalls. Bei zwei Segmenten steht im ersten DE4440 das Segment des Beginns und im zweiten DE4440 das Segment des Endes.
Hinweise des AHB
- Als Beginn- und Endedatum gelten auch DTM-Segmente, deren Bezeichnung „ab“ und „bis“ enthält.
- Ein Geschäftsvorfall kann mehrere Zeitintervalle enthalten. Die Prüfung läuft nacheinander für jedes einzelne.
- Wer die Fehlermeldung erstellt, muss bei zwei DTM-Segmenten sicherstellen, dass er nicht Segmente unterschiedlicher Zeitintervalle vergleicht.
Beispiele, die das AHB nennt
- Ein einzelnes Segment:
DTM+Z01:201609160400201609090400:719' - Eine MSCONS in SG10:
DTM+163:201010310215?+00:303'undDTM+164:201010310200?+00:303' - Eine UTILMD in SG4:
DTM+Z25:201906012200+00:303'undDTM+Z26:201904012200+00:303'
Nicht verwechseln mit
Z35: Format eines Datenelements nicht eingehalten
Format nicht eingehalten
In einfachen Worten
Ein Wert in deiner Nachricht passt nicht zur Formatdefinition seines Datenelements, etwa weil er zu viele Nachkommastellen hat.
Fiktives Beispiel
Für ein Datenelement gilt die (hier erfundene) Formatdefinition „max. 3 Nachkommastellen“. Die Nachricht enthält QTY+220:12.3456 mit vier Nachkommastellen. Der Empfänger meldet Z35 und nennt in SG5 FTX+Z02 den Ort.
Das prüfst du
- AHBLies die Ortsangabe aus SG5 FTX+Z02 (bei Z35 Pflicht) und finde das Datenelement.
- AHBSchlage die Formatdefinition mit der Nummer [901] bis [999] in der Spalte deines Prüfidentifikators nach.
- AllgemeinPrüfe im Quellsystem oder im Mapping, wie Zahlen, Datum und Nachkommastellen für die Nachricht formatiert werden.
Weitere Angaben des AHB
Wo die Formate stehen
Der Nummernkreis der Formatdefinitionen liegt zwischen [901] und [999]. Details stehen im entsprechenden Kapitel der Allgemeinen Festlegungen.
Nicht verwechseln mit
Z37: Geschäftsvorfall darf vom Sender nicht gesendet werden
Geschäftsvorfall darf vom Sender nicht gesendet werden
In einfachen Worten
Die Anwendungsübersicht der Prüfidentifikatoren sieht diesen Austausch zwischen deiner Rolle und der Rolle des Empfängers nicht vor.
Fiktives Beispiel
Ein Netzbetreiber sendet an einen anderen Netzbetreiber eine Nachricht mit einem Prüfidentifikator, den die Anwendungsübersicht nur zwischen Lieferant und Netzbetreiber vorsieht. Der Empfänger meldet Z37 und prüft nichts weiter. Die Konstellation ist erfunden.
Das prüfst du
- AHBSchlage den Prüfidentifikator in der Anwendungsübersicht der Prüfidentifikatoren nach und prüfe, zwischen welchen Marktrollen er ausgetauscht wird.
- AllgemeinVergleiche deine Rolle als Absender (NAD+MS) und die Rolle des Empfängers (NAD+MR) mit dieser Zuordnung.
Weitere Angaben des AHB
Reihenfolge zu Z31
Die Prüfungen, die zu Z37 führen, laufen ausnahmslos erst nach einer erfolglosen Prüfung auf Z31.
Nicht verwechseln mit
- Z31Bei Z31 verarbeitet der Empfänger den Prüfidentifikator in seiner Rolle nie. Bei Z37 darf gerade dieser Sender ihn nicht an diese Rolle schicken. Z31 geht vor.
Z38: Anzahl der übermittelten Codes überschreitet Paketdefinition
Anzahl der übermittelten Codes überschreitet Paketdefinition
In einfachen Worten
Ein Paket im AHB begrenzt, wie viele Codes und wie oft jeder Code vorkommen darf. Deine Nachricht liegt darüber.
Fiktives Beispiel
Ein Paket erlaubt in einem Gruppendatenelement höchstens zwei Codes aus einer Liste. Die Nachricht enthält drei verschiedene Codes daraus. Der Empfänger meldet Z38 und nennt in SG5 FTX+Z02 das Gruppendatenelement. Das Paket ist erfunden.
Das prüfst du
- AHBLies die Ortsangabe aus SG5 FTX+Z02 und finde das Daten- oder Gruppendatenelement.
- AllgemeinSuche im AHB die Paketdefinition zu diesem Element und zähle, wie viele Codes deine Nachricht enthält.
Weitere Angaben des AHB
Was ein Paket festlegt
Das Paket oder die Pakete des Daten- oder Gruppendatenelements legen die maximale Anzahl an Codes und die maximale Anzahl jedes einzelnen Codes fest. Diese Obergrenze wird im Geschäftsvorfall überschritten.
Nicht verwechseln mit
Z39: Code nicht aus erlaubtem Wertebereich
Code nicht aus erlaubtem Wertebereich
In einfachen Worten
In einem Feld steht ein Code, den die Spalte deines Prüfidentifikators dort nicht zulässt.
Fiktives Beispiel
Die Spalte eines Prüfidentifikators erlaubt in einem Datenelement nur die Codes „A1“ und „B2“. Die Nachricht enthält dort „C3“. Der Empfänger meldet Z39 und nennt in SG5 FTX+Z02 das Datenelement. Die Codes sind erfunden.
Das prüfst du
- AHBLies die Ortsangabe aus SG5 FTX+Z02 und finde das Gruppendatenelement oder Datenelement.
- AHBVergleiche den Code mit den Werten, die die Spalte deines Prüfidentifikators dort aufführt, einschließlich der Pakete.
- AllgemeinPrüfe außerdem, ob dein System überhaupt die Codeliste der gültigen Formatversion verwendet.
Weitere Angaben des AHB
Was als erlaubt gilt
Maßgeblich ist die zugehörige Spalte des AHB einschließlich Muss-Voraussetzung und Paketdefinition.
Nicht verwechseln mit
Z40: Segment oder Segmentgruppe kommt zu oft vor
Segment- bzw. Segmentgruppenwiederholbarkeit überschritten
In einfachen Worten
Ein Segment oder eine Segmentgruppe steht öfter in der Nachricht, als der Anwendungsfall es erlaubt.
Fiktives Beispiel
Laut Spalte des Prüfidentifikators darf eine Segmentgruppe höchstens einmal vorkommen. Die Nachricht enthält sie zweimal, zum Beispiel weil ein Export einen Datensatz doppelt geschrieben hat. Der Empfänger meldet Z40 und nennt die Gruppe in SG5 FTX+Z02.
Das prüfst du
- AHBLies die Ortsangabe aus SG5 FTX+Z02 und finde das Segment oder die Gruppe.
- AHBSuche in der Spalte deines Prüfidentifikators die Bedingung im Nummernkreis 2000 bis 2499 oder die Paketdefinition zu dieser Stelle.
- AllgemeinPrüfe im Export, ob Datensätze doppelt in die Nachricht geschrieben wurden.
Weitere Angaben des AHB
Woher die Grenze kommt
Die erlaubte Zahl ergibt sich aus einer Wiederholbarkeit (Bedingung aus dem Nummernkreis 2000 bis 2499) oder aus einer Paketdefinition.
Nicht verwechseln mit
Z41: Zeitangabe unplausibel
Zeitangabe unplausibel
In einfachen Worten
Ein Zeitpunkt oder Zeitraum in deiner Nachricht kann inhaltlich nicht stimmen, zum Beispiel weil er in der Zukunft liegt.
Fiktives Beispiel
Eine MSCONS mit dem Nachrichtendatum 10.03. enthält Messwerte für den 11.03. Gemessene Werte können nicht jünger sein als die Nachricht, der Empfänger meldet Z41 und nennt in SG5 FTX+Z02 das Zeitsegment.
Das prüfst du
- AHBLies die Ortsangabe aus SG5 FTX+Z02 und finde das Zeitsegment.
- AHBVergleiche die Zeitangabe mit den Bedingungen, die das AHB für dieses Datenelement festlegt.
- AllgemeinPrüfe die Systemuhr und die Zeitzone des Absenders, falls das Dokumentendatum ungewöhnlich vorauseilt.
Weitere Angaben des AHB
Beispiele, die das AHB nennt
- Liegt das Nachrichten- oder Dokumentendatum zum Zeitpunkt des Eintreffens beim Empfänger in der Zukunft, muss die Zeitangabe falsch sein.
- Jeder in einer MSCONS genannte Zeitraum oder Zeitpunkt muss älter als das Nachrichtendatum der MSCONS sein, weil die MSCONS nur gemessene oder auf gemessenen Werten beruhende Werte überträgt.
Nicht verwechseln mit
Zuordnung zu einem ObjektArt: ZO Objekt
Das Objekt oder ein Unterobjekt (zum Beispiel Marktlokation, Messlokation, Gerät, Register) ist beim Empfänger nicht zuordenbar. Beim ersten Scheitern bricht die Zuordnung ab. Z10, Z14 und Z17 stehen oben bei den häufig gesuchten Codes.
Z15: Objekt im IT-System nicht eindeutig
Objekt im IT-System nicht eindeutig
In einfachen Worten
Deine Angaben passen auf mehr als ein Objekt. Der Empfänger kann nicht wissen, welches du meinst.
Fiktives Beispiel
Eine Anfrage nennt nur Straße und Hausnummer eines Mehrfamilienhauses (erfunden: Musterweg 1). Der Netzbetreiber findet dort drei Marktlokationen und kann keine davon auswählen. Er antwortet mit Z15.
Das prüfst du
- AHBPrüfe, ob deine Nachricht eine Anfrage ist. Z15 kommt nur dort vor.
- AllgemeinErgänze die Angaben, die das Objekt eindeutig machen, so wie die jeweilige Festlegung es verlangt.
Weitere Angaben des AHB
Nur bei Anfragen
Die Prüfungen, die zu Z15 führen, sind ausschließlich bei Anfragen anzuwenden.
Nutzungseinschränkung laut AHB
Keine Anwendung auf die INVOIC.
Nicht verwechseln mit
Z16: Objekt nicht mehr im Netzgebiet des Empfängers
Objekt nicht mehr im Netzgebiet
In einfachen Worten
Der Netzbetreiber ist für das Objekt nicht mehr zuständig, weil es an einen neuen Netzbetreiber übergegangen ist. Die APERAK nennt den neuen Netzbetreiber.
Fiktives Beispiel
Ein Lieferant sendet eine Meldung zur Marktlokation 11122233344 an die Beispielnetz AG. Die Marktlokation wurde bereits an die Anderswo Netz GmbH übertragen, beide erfunden. Die Beispielnetz AG lehnt mit Z16 ab und trägt in SG5 RFF+Z08 die MP-ID des neuen Netzbetreibers ein.
Das prüfst du
- AHBLies die MP-ID in SG5 RFF+Z08. Sie nennt den Netzbetreiber, an den das Objekt übergeben wurde.
- AllgemeinGleiche deine Stammdaten mit dem Netzbetreiberwechsel ab und sende die Nachricht erneut an den genannten Netzbetreiber.
- AHBLies ID und Zeitintervall aus SG4 FTX+ABO, damit du das betroffene Objekt eindeutig erkennst.
Weitere Angaben des AHB
Was in der APERAK stehen muss
- In SG4 FTX+ABO stehen die ID der Markt- oder Messlokation oder Tranche und das Zeitintervall oder der Zeitpunkt.
- Bei Z16 ist SG5 RFF+Z08 mit der MP-ID des Netzbetreibers zu füllen, an den der angefragte Netzbetreiber das Netzgebiet übergeben hat.
Tranchen
Für Tranchen kann dieser Code nur in Folgeprozessen verwendet werden (Fußnote 7 zu Kap. 4.3).
Nutzungseinschränkung laut AHB
In der Sparte Gas keine Prüfung bei einer UTILMD mit BGM+E01, NB als Empfänger und LF als Absender.
Nicht verwechseln mit
Z18: Empfänger ist dem Objekt im Zeitraum nicht zugeordnet
Empfänger ist zum angegebenen Zeitintervall / Zeitpunkt dem Objekt nicht zugeordnet
In einfachen Worten
Der Empfänger kennt das Objekt, ist ihm im Zeitraum deiner Nachricht aber nicht zugeordnet. Die Nachricht kann beim falschen Empfänger gelandet sein oder der Zeitraum passt nicht zur Zuordnung.
Fiktives Beispiel
Ein Marktpartner sendet Daten zur Messlokation DE0000000000000001 für den Zeitraum 01.03. bis 31.03. an einen Netzbetreiber. Dessen Zuordnung zur Messlokation endet laut seinem System am 20.03. Der Zeitraum reicht über das Ende hinaus, der Netzbetreiber antwortet mit Z18.
Das prüfst du
- AHBLies ID und Zeitintervall aus SG4 FTX+ABO.
- AllgemeinPrüfe, ob die MP-ID des Empfängers in deiner Nachricht stimmt und ob der Empfänger zum genannten Zeitraum der zuständige Marktpartner ist.
- AHBBeachte, dass die Zuordnung des Empfängers im gesamten Zeitintervall bestehen muss.
Weitere Angaben des AHB
Die Regel dahinter
Der Empfänger muss dem Objekt im gesamten Zeitintervall des Geschäftsvorfalls zugeordnet sein. Beginnt das Intervall vor dem Beginn der Zuordnung oder endet es nach dem Ende der Zuordnung, ist das mit Z18 zu melden.
Reihenfolge bei Netzbetreibern
Ist der Empfänger ein Netzbetreiber und das Objekt eine Marktlokation oder Tranche, läuft diese Prüfung erst, wenn die Prüfung auf Z16 erfolgreich durchlaufen wurde.
Nutzungseinschränkung laut AHB
Keine Anwendung auf die INVOIC, auf MSCONS mit BGM+Z27 oder BGM+Z85 in bestimmten Rollen, auf UTILTS mit BGM+Z36 und in der Sparte Strom auf UTILMD mit BGM+E03, E35 oder Z88. In der Sparte Gas gelten zwei UTILMD-Ausnahmen.
Nicht verwechseln mit
Z19: Gerätenummer an der Messlokation nicht bekannt
Gerätenummer zum angegebenen Zeitintervall / Zeitpunkt an der Messlokation nicht bekannt
In einfachen Worten
Eine MSCONS nennt eine Gerätenummer, die der Empfänger für diese Messlokation nicht aus einem früheren Stammdatenaustausch kennt.
Fiktives Beispiel
Ein Messstellenbetreiber sendet eine MSCONS (Ausprägung VL) zur Messlokation DE0000000000000002 mit der Gerätenummer „1ABC0000123“. Beim Empfänger ist für diese Messlokation im Zeitraum nur die Gerätenummer „1ABC0000456“ aus dem Stammdatenaustausch bekannt. Er antwortet mit Z19 und nennt „1ABC0000123“ in SG4 FTX+ABO. Alle Nummern sind erfunden.
Das prüfst du
- AHBWer Z19 sendet, muss sicherstellen, dass die UTILMD-Geschäftsvorfälle zu dieser Messlokation erfolgreich verarbeitet sind.
- AllgemeinPrüfe als Empfänger der APERAK, ob die Gerätenummer im Stammdatenaustausch an den Empfänger übermittelt wurde und für welchen Zeitraum sie gilt.
Weitere Angaben des AHB
Unterobjekt Gerät
Hier greift die mehrstufige Zuordnung (Kap. 2.1.3.1): Die Messlokation wurde gefunden, ein Gerät mit dieser Nummer gibt es an ihr nicht. Das AHB nennt genau diesen Fall als Beispiel für Z19.
Nutzungseinschränkung laut AHB
Nur bei MSCONS-Eingang zulässig.
Nicht verwechseln mit
Z20: OBIS-Kennzahl am Objekt nicht bekannt
OBIS-Kennzahl zum angegebenen Zeitintervall / Zeitpunkt am Objekt nicht bekannt
In einfachen Worten
Die MSCONS enthält Werte zu einer OBIS-Kennzahl oder zum Medium Ausfallarbeit, die der Empfänger für das Objekt nicht aus dem Stammdatenaustausch kennt.
Fiktives Beispiel
Eine MSCONS enthält Werte zu zwei Kennzahlen, 1-1:1.8.0 für den Bezug und 1-1:2.8.0 für die Einspeisung. Beim Empfänger wurde zum Objekt nur 1-1:1.8.0 übermittelt. Er antwortet mit Z20. Für 1-1:2.8.0 beginnt er eine eigene SG4 mit FTX+ABO.
Das prüfst du
- AHBWer Z20 sendet, muss sicherstellen, dass die UTILMD-Geschäftsvorfälle zu diesem Objekt erfolgreich verarbeitet sind.
- AllgemeinGleiche die OBIS-Kennzahlen in der MSCONS mit den Kennzahlen ab, die im Stammdatenaustausch für das Objekt gemeldet wurden. Der OBIS-Katalog hilft beim Lesen der Kennzahlen.
Weitere Angaben des AHB
Eine SG4 je fehlender Kennzahl
Pro nicht vorhandener OBIS-Kennzahl oder je Code des Mediums Ausfallarbeit (Code AUA) wird eine eigene SG4 begonnen und in FTX+ABO übermittelt.
Nutzungseinschränkung laut AHB
Nur bei MSCONS-Eingang zulässig.
Nicht verwechseln mit
Z24: Zuordnungs-Tupel beim Empfänger unbekannt
Zuordnungs-Tupel unbekannt
In einfachen Worten
Manche Objekte benennt man erst mit mehreren Angaben zusammen, dem Tupel. Diese Kombination gibt es beim Empfänger nicht.
Fiktives Beispiel
Ein Marktpartner meldet Daten zu einem normierten Profil, das über das 2-Tupel (Profilbezeichnung, Netzbetreiber) benannt wird, hier („Profil-Muster-A“, Beispielnetz AG). Der Empfänger kennt die Beispielnetz AG und auch ein Profil „Profil-Muster-A“, aber nicht diese Kombination. Er antwortet mit Z24 und nennt das vollständige Tupel in FTX+ABO. Alle Werte sind erfunden.
Das prüfst du
- AHBLies das Tupel aus SG4 FTX+ABO und prüfe jedes Element für sich und die Kombination.
- AllgemeinVergleiche die Schreibweise der Elemente, etwa von Profilbezeichnung oder Bilanzkreis, mit der Schreibweise in den Stammdaten der Gegenseite.
Weitere Angaben des AHB
Tupel, die das AHB als Beispiele nennt
- 4-Tupel der EEG-Überführungszeitreihen der MaBiS: Bilanzierungsgebiet, EEG-Zeitreihentyp, Bilanzkreis-an, Bilanzkreis-von
- 2-Tupel der normierten Profile nach MaBiS: Profilbezeichnung, Netzbetreiber
- 3-Tupel der Allokationsmeldung nach GABi Gas: Bilanzkreis, Netzbetreiber, Zeitreihentyp
- 2-Tupel der Mehrmindermengenmeldung Gas nach GABi Gas: Netzkonto, Netzbetreiber
Immer das ganze Tupel
Es wird nur auf das gesamte Tupel geprüft. Sind einzelne Elemente im System vorhanden, aber nicht alle, gilt das als Zuordnungsfehler. Die APERAK nennt dann das vollständige Tupel in der Schreibweise (x1, x2, …, xn) und sagt nicht, welche Elemente bekannt sind.
Nutzungseinschränkung laut AHB
Keine Prüfung, wenn das Objekt mit einem 1-Tupel identifiziert wird, also über Marktlokations-ID, TR-ID oder Zählpunktbezeichnung. Dann gilt Z10.
Nicht verwechseln mit
Z25: Absender ist dem Tupel-Objekt im Zeitraum nicht zugeordnet
Absender ist zum angegebenen Zeitintervall / Zeitpunkt dem durch das Zuordnungs-Tupel identifizierten Objekt nicht zugeordnet
In einfachen Worten
Das Tupel ist beim Empfänger bekannt. Du als Absender bist dem Objekt dahinter aber im Zeitraum deiner Nachricht nicht zugeordnet.
Fiktives Beispiel
Ein Marktpartner meldet Daten zum 2-Tupel („Profil-Muster-A“, Beispielnetz AG) für den ganzen Januar. Der Empfänger kennt das Tupel, ordnet den Absender dem Objekt aber erst ab dem 01.02. zu. Er antwortet mit Z25 und nennt Tupel und Zeitraum in FTX+ABO. Alle Werte sind erfunden.
Das prüfst du
- AHBLies Tupel und Zeitintervall aus SG4 FTX+ABO.
- AllgemeinPrüfe, ab wann und bis wann du dem Objekt zugeordnet bist, und vergleiche den Zeitraum deiner Nachricht damit.
Weitere Angaben des AHB
Verweis des AHB
Weitere Details zum Zuordnungs-Tupel stehen im AHB bei Z24.
Nicht verwechseln mit
Z26: Empfänger ist dem Tupel-Objekt im Zeitraum nicht zugeordnet
Empfänger ist zum angegebenen Zeitintervall / Zeitpunkt dem durch das Zuordnungs-Tupel identifizierten Objekt nicht zugeordnet
In einfachen Worten
Das Tupel ist bekannt, aber der Empfänger der Ursprungsnachricht ist dem Objekt dahinter im Zeitraum nicht zugeordnet.
Fiktives Beispiel
Ein Absender meldet Daten zur EEG-Überführungszeitreihe mit dem 4-Tupel („Gebiet-Muster“, „Typ-X“, „BK-AN-1“, „BK-VON-1“) für den Februar. Die Nachricht ging an einen Empfänger, der diesem Objekt im Februar nicht zugeordnet ist. Dieser antwortet mit Z26 und nennt das Tupel in FTX+ABO. Alle Werte sind erfunden.
Das prüfst du
- AHBLies Tupel und Zeitintervall aus SG4 FTX+ABO.
- AllgemeinPrüfe, ob die Nachricht an den richtigen Empfänger ging und ob dessen Zuständigkeit für das Objekt im genannten Zeitraum besteht.
Weitere Angaben des AHB
Verweis des AHB
Weitere Details zum Zuordnungs-Tupel stehen im AHB bei Z24.
Nicht verwechseln mit
Z42: Konfigurations-ID zum Zeitraum nicht bekannt
Konfigurations-ID zum angegebenen Zeitintervall / Zeitpunkt nicht bekannt
In einfachen Worten
Eine MSCONS nennt eine Konfigurations-ID, die der Empfänger aus dem Stammdatenaustausch nicht kennt.
Fiktives Beispiel
Ein Messstellenbetreiber sendet eine MSCONS (Ausprägung VL, BGM+7, Sparte Strom) mit der Konfigurations-ID „KONF-000123“. Beim Empfänger wurde zur Messlokation nie eine Konfigurations-ID mit diesem Wert übermittelt. Er antwortet mit Z42 und nennt die ID in SG4 FTX+ABO. Die ID ist erfunden.
Das prüfst du
- AHBWer Z42 sendet, muss sicherstellen, dass die UTILMD-Geschäftsvorfälle zu dieser Messlokation erfolgreich verarbeitet sind.
- AllgemeinPrüfe als Empfänger der APERAK, ob die Konfigurations-ID im Stammdatenaustausch gemeldet wurde und für welchen Zeitraum sie gilt.
Weitere Angaben des AHB
Voraussetzung auf der Absenderseite
Der Absender einer solchen Fehlermeldung hat sicherzustellen, dass die entsprechenden UTILMD-Geschäftsvorfälle zu dieser Messlokation erfolgreich verarbeitet sind.
Nutzungseinschränkung laut AHB
Nur bei MSCONS-Eingang mit Ausprägung VL und BGM+7 in der Sparte Strom.
Nicht verwechseln mit
Zuordnung zu einem GeschäftsvorfallArt: ZO Geschäftsvorfall
Der Vorgänger-Geschäftsvorfall, auf den sich die Nachricht bezieht, liegt beim Empfänger nicht vor.
Der einzige Code dieser Stufe ist Z33. Er steht oben bei den häufig gesuchten Codes.
ObjekteigenschaftArt: OE
Das Objekt wurde gefunden, hat aber nicht die Eigenschaft, die der Anwendungsfall verlangt. Diese Prüfung läuft nur nach erfolgreicher Zuordnung.
Z43: Geschäftsvorfall für Objekt mit dieser Eigenschaft nicht erlaubt
Geschäftsvorfall für Objekt mit der Eigenschaft nicht erlaubt
In einfachen Worten
Der Empfänger hat das Objekt gefunden. Es besitzt aber nicht die Eigenschaft, die dieser Anwendungsfall verlangt.
Fiktives Beispiel
Ein Anwendungsfall ist nur für Objekte mit „Eigenschaft A“ vorgesehen. Der Absender schickt ihn zu einer Marktlokation, die laut Stammdaten des Empfängers „Eigenschaft B“ trägt. Die Zuordnung zur Marktlokation gelingt, die Prüfung der Eigenschaft scheitert, der Empfänger antwortet mit Z43. Die Eigenschaften sind erfunden.
Das prüfst du
- AHBSchlage in der Anwendungsübersicht der Prüfidentifikatoren die Spalte „Objekteigenschaft“ für deinen Prüfidentifikator nach.
- AllgemeinVergleiche diese Eigenschaft mit der Eigenschaft des Objekts in deinen Stammdaten und bei der Gegenseite.
Weitere Angaben des AHB
Wann Z43 und wann Z44
Ist der Anwendungsfall für genau eine Objekteigenschaft spezifiziert und scheitert die Prüfung, gilt Z43. Ist er für mehrere Eigenschaften spezifiziert, gilt bei einem Scheitern Z44 (Kap. 2.1.4).
Voraussetzung
Die Objekteigenschaftsprüfung läuft nur, wenn die Zuordnungsprüfung erfolgreich war und die Anwendungsübersicht der Prüfidentifikatoren in der Spalte „Objekteigenschaft“ ein Kürzel nennt.
Nicht verwechseln mit
Z44: Eigenschaft des Objekts weicht von der codierten Eigenschaft ab
Eigenschaft des Objekts weicht von der im Geschäftsvorfall codierten Eigenschaft ab
In einfachen Worten
Der Anwendungsfall erlaubt mehrere Eigenschaften. Die Eigenschaft, die du in der Nachricht codiert hast, hat das Objekt beim Empfänger nicht.
Fiktives Beispiel
Ein Anwendungsfall lässt die Eigenschaften A, B und C zu. Die Nachricht codiert „Eigenschaft B“, das Objekt trägt beim Empfänger aber „Eigenschaft C“. Die Zuordnung gelingt, die Prüfung scheitert, der Empfänger antwortet mit Z44. Die Eigenschaften sind erfunden.
Das prüfst du
- AHBSchlage in der Anwendungsübersicht der Prüfidentifikatoren nach, welche Eigenschaften für deinen Prüfidentifikator erlaubt sind.
- AllgemeinVergleiche den Code, den du in der Nachricht gesetzt hast, mit der Eigenschaft des Objekts in deinen Stammdaten.
Weitere Angaben des AHB
Woher die erwartete Eigenschaft kommt
Bei mehreren erlaubten Eigenschaften ergibt sie sich aus dem Prüfidentifikator und dem Code im Geschäftsvorfall, der mit einem der erlaubten Codes übereinstimmen muss (Kap. 2.1.4).
Nicht verwechseln mit
ÜbernahmeArt: ÜN
Die Daten lassen sich nicht übernehmen, weil ein Zählwert mehr Vorkommastellen hat als vereinbart.
Z27: Zählwert hat zu viele Vorkommastellen
Vorkomma-Stellenzahl des Zählwertes ist zu lang
In einfachen Worten
Der Zählwert in der MSCONS hat mehr Ziffern vor dem Komma, als die Partner für dieses Register vereinbart haben. Der Empfänger kann ihn nicht übernehmen.
Fiktives Beispiel
Für ein Register wurde im Stammdatenaustausch eine Vorkommastellenzahl von fünf vereinbart. Eine MSCONS meldet 123456,7 kWh, also sechs Vorkommastellen. Der Empfänger antwortet mit Z27. Das Beispiel ist erfunden.
Das prüfst du
- AHBVergleiche die Zahl der Ziffern vor dem Komma mit der Stellenzahl, die per UTILMD in SG10 CCI+11++Z33 CAV für das Register vereinbart wurde.
- AllgemeinPrüfe, ob Wert und Einheit zusammenpassen, etwa kWh statt Wh, bevor du die vereinbarte Stellenzahl anfasst.
Weitere Angaben des AHB
Wo die Vereinbarung steht
Die Stellenzahl wurde über die UTILMD im Vorfeld zwischen den Marktpartnern vereinbart, in SG10 CCI+11++Z33 CAV, und zwar für den im Geschäftsvorfall genannten Zeitpunkt.
Nutzungseinschränkung laut AHB
Nur bei MSCONS-Eingang zulässig (Ausprägung VL).
Nicht verwechseln mit
Kein Code passt zu dieser Suche. Probiere die Nummer, etwa „Z33“, oder ein Stichwort aus der Bedeutung.
CONTRL oder APERAK: Syntaxprüfung gegen Anwendungsprüfung
Die beiden Rückmeldungen prüfen Verschiedenes (Kap. 1.2 und 2.1):
- CONTRL: prüft die Syntax der Übertragungsdatei. Ein Fehler lehnt die ganze Datei ab, alle Geschäftsvorfälle darin gelten als nicht zugegangen (Kap. 1.4). In der Sparte Strom sendet der Empfänger eine CONTRL nur bei einem Syntaxfehler, in der Sparte Gas quittiert er jede Datei mit einer CONTRL.
- APERAK: prüft jeden Geschäftsvorfall einzeln auf Verarbeitbarkeit. Ein Fehler lehnt nur diesen Geschäftsvorfall ab. Die Fehlerart steht im ERC-Segment, und der Fehlerort ist die fachliche Bezeichnung des Segments, nicht eine Segmentzählung wie in der CONTRL (Kap. 2.1.2.1).
Die Z-Codes dieser Seite gehören zur APERAK. Bei einem Syntaxfehler hat der Empfänger alle Geschäftsvorfälle der Datei nicht verarbeitet (Kap. 1.2), eine Prüfung je Geschäftsvorfall findet dann nicht statt. Auf eine APERAK folgt keine weitere APERAK, und auf eine CONTRL ebenfalls nicht (Kap. 2). Einen Fehler, für den die APERAK keinen Code hat, klärt der Absender auf einem anderen Weg als per APERAK.
Ablauf im Marktprozess
Der Empfänger muss zu jedem Geschäftsvorfall innerhalb der Frist entweder eine Anerkennungsmeldung oder eine Verarbeitbarkeitsfehlermeldung senden. Bei UTILMD und ORDERS bleiben 45 Minuten nach Eingang der Datei, bei Samstagsnachrichten dieser Typen bis Sonntag 12 Uhr, bei allen anderen Nachrichten bis zum nächsten Werktag 12 Uhr (Kap. 2.4.1). Nach einer Fehlermeldung gilt für den Absender (Kap. 1.2):
- Er geht davon aus, dass die beanstandeten Geschäftsvorfälle nicht weiterverarbeitet wurden.
- Er stößt einen Klärungsprozess an und bereinigt den Fehler und seine Ursache ohne schuldhaftes Verzögern.
- Er sendet eine bereinigte Datei. Fehlerfreie und fehlerhafte Geschäftsvorfälle darf er dafür auf zwei Dateien aufteilen, damit die fehlerfreien sofort herausgehen.
Hält der Absender den gemeldeten Fehler für unberechtigt oder braucht er mehr Informationen, kontaktiert er den Empfänger außerhalb der EDIFACT-Kommunikation. Die Anerkennungsmeldung selbst sagt noch nichts über die Frist des Prozesses; die wird erst in der weiteren Verarbeitung geprüft (Kap. 2).
Was tun bei einer APERAK?
Der Weg unten führt vom Eingang der Rückmeldung bis zur Maßnahme. Er verweist auf die Abschnitte zu Z10, Z14, Z17, Z29 und Z33 und auf die Tabelle aller Codes.
Kam eine CONTRL oder eine APERAK?
Das entscheidet, ob die ganze Datei oder nur ein Geschäftsvorfall betroffen ist (Kap. 1.4, 1.5 und 2).
CONTRL mit Syntaxfehler
Die ganze Datei ist abgelehnt, alle Geschäftsvorfälle darin gelten als nicht zugegangen. Das ist kein Z-Code-Fall.
Laut AHB Datei korrigieren und neu senden. Es gelten die Fristen ab dem erneuten Sendedatum (Kap. 1.3).
APERAK mit BGM+312
Anerkennung: Der Geschäftsvorfall ist verarbeitbar und geht in die weitere Verarbeitung (Kap. 2.2).
Laut AHB Nichts zu beheben.
APERAK mit BGM+313
Fehlermeldung: Nur dieser Geschäftsvorfall ist abgelehnt und gilt als nicht zugegangen (Kap. 1.5).
Weiter mit Schritt 2.
Z-Code im ERC lesen
Der Code steht im Datenelement 9321 des ERC-Segments in SG4. Der Code allein reicht nicht.
- SG4 FTX+ABO: Fundstelle bei Zuordnungsfehlern, mit ID und Zeitangabe oder dem Tupel.
- SG5 FTX+Z02: Ortsangabe bei AHB-Fehlern, mit der fachlichen Bezeichnung des Segments.
- SG5 RFF+TN: der Vorgang, den der Code betrifft.
Segmente der APERAK im Beispiel: Wo der Z-Code in der APERAK steht. Bedeutung der Codes: Tabelle aller Z-Codes.
Prüfstufe der Art bestimmen
Die Spalte „Art“ in der Tabelle zeigt, in welcher Stufe der Fehler entstand. Geprüft wird in dieser Reihenfolge, beim ersten Fehler endet die Prüfung (Kap. 2.1.1).
AHB-Prüfung
Art: AHB
- Z21
- Z29
- Z30
- Z31
- Z34
- Z35
- Z37
- Z38
- Z39
- Z40
- Z41
Der Geschäftsvorfall verletzt die Prüfschablone seines Prüfidentifikators.
Zuordnung zu einem Objekt
Art: ZO Objekt
Das Objekt ist beim Empfänger nicht auffindbar oder dem Absender zum genannten Zeitraum nicht zugeordnet.
Zuordnung zu einem Geschäftsvorfall
Art: ZO Geschäftsvorfall
Der Vorgänger, auf den sich die Nachricht bezieht, liegt beim Empfänger nicht vor.
Objekteigenschaft
Art: OE
- Z43
- Z44
Das Objekt wurde gefunden, hat aber nicht die Eigenschaft, die der Anwendungsfall verlangt.
Übernahme
Art: ÜN
- Z27
Ein Zählwert hat mehr Vorkommastellen, als zum Register vereinbart wurden (MSCONS der Ausprägung VL).
Maßnahme je Stufe
Jede Maßnahme trägt die Kennzeichnung, woher sie stammt: aus dem AHB oder als allgemeiner Prüfschritt dieser Seite.
Bei AHB-Prüfung
- Laut AHBBei Z21, Z29, Z35, Z38, Z39, Z40 und Z41 nennt SG5 FTX+Z02 das fehlerhafte Segment mit seiner fachlichen Bezeichnung. Alle AHB-Fehler eines Geschäftsvorfalls stehen in der APERAK.
- Laut AHBFehler beseitigen und eine bereinigte Datei senden.
- Allgemeiner PrüfschrittDie Zeile des Prüfidentifikators im AHB nachschlagen. Bei Z31 und Z37 liegt der Fehler beim Anwendungsfall, nicht im Inhalt.
Bei Zuordnung zu einem Objekt
- Laut AHBID und Zeitangabe stehen in SG4 FTX+ABO. Alle Marktpartner müssen ihre Objekte zeitnah pflegen. Bei Z16 steht die MP-ID des neuen Netzbetreibers in SG5 RFF+Z08.
- Allgemeiner PrüfschrittID und Zeitraum mit den eigenen Stammdaten vergleichen und beim Empfänger nachfragen, ob das Objekt dort angelegt ist.
Bei Zuordnung zu einem Geschäftsvorfall
- Laut AHBDas vollständige Tupel steht in SG4 FTX+ABO. Zwischen Vorgänger und Folgenachricht soll ein ausreichender zeitlicher Abstand liegen.
- Allgemeiner PrüfschrittDie Referenz mit der Ursprungsnachricht vergleichen und klären, ob diese anerkannt wurde. Eine abgelehnte Nachricht gilt als nicht zugegangen.
Bei Objekteigenschaft
- Allgemeiner PrüfschrittDas AHB nennt hier keine Maßnahme. Eigenschaft des Objekts in den Stammdaten gegen den Anwendungsfall des Prüfidentifikators prüfen, bei Abweichung den Marktpartner kontaktieren.
Bei Übernahme
- Allgemeiner PrüfschrittDas AHB nennt hier keine Maßnahme. Die im Stammdatenaustausch vereinbarte Stellenzahl des Registers klären.
Für alle Stufen gilt (Kap. 1.2)
- Laut AHBDavon ausgehen, dass der beanstandete Geschäftsvorfall nicht weiterverarbeitet wurde, einen Klärungsprozess anstoßen und den Fehler samt Ursache ohne schuldhaftes Verzögern bereinigen. Dann eine bereinigte Datei senden: korrigieren und neu senden. Die Prozessfristen laufen weiter. Fehlerfreie und fehlerhafte Vorfälle darf der Absender auf zwei Dateien aufteilen.
- Laut AHBHält der Absender den Fehler für unberechtigt oder braucht er mehr Informationen: den Marktpartner kontaktieren, außerhalb der EDIFACT-Kommunikation. Das gilt auch für Fehler, für die die APERAK keinen Code hat.
Typische Fehlerbilder
Jedes Bild ist direkt an eine Aussage des AHB gebunden. Wie oft sie in der Praxis auftreten, sagt das AHB nicht.
- Folgenachricht ohne Vorgänger (Z33): Eine Antwort, Statusmeldung oder ein Storno verweist auf einen Vorgang, den der Empfänger nicht hat. Das AHB empfiehlt Abstand zwischen beiden Sendevorgängen.
- Zeitraum reicht über die Zuordnung hinaus (Z17, Z18, Z25, Z26): Der Zeitraum beginnt vor oder endet nach der Zuordnung des Absenders beziehungsweise des Empfängers zum Objekt.
- ID oder Objekt fehlt im System (Z10, Z14): Das Objekt fehlt beim Empfänger oder wird dort anders identifiziert, und laut AHB sind alle Marktpartner zur zeitnahen Pflege der Objekte verpflichtet.
- Netzgebiet gewechselt (Z16): Das Objekt liegt nicht mehr beim angefragten Netzbetreiber. Die APERAK nennt die MP-ID des Netzbetreibers, der das Netzgebiet übernommen hat.
- Pflichtangabe oder Format (Z29, Z35, Z39, Z40, Z41): Die Nachricht verletzt die Prüfschablone ihres Prüfidentifikators. Die Ortsangabe nennt das Segment.
- Falscher Weg (Z31, Z37): Der Empfänger verarbeitet diesen Prüfidentifikator in seiner Rolle nicht (Z31), oder der Prüfidentifikator darf zwischen den beiden Rollen nicht ausgetauscht werden (Z37). Beides sind Fehler auf der Ebene des Anwendungsfalls, nicht des Inhalts.
- Stammdaten der Messlokation unvollständig (Z19, Z20, Z27, Z42): Eine MSCONS nennt Gerätenummer, OBIS-Kennzahl, Konfigurations-ID oder Stellenzahl, die vorab nicht per Stammdatenaustausch vereinbart wurden.
Typische Missverständnisse
„Z17 und Z10 sind dasselbe: das Objekt ist nicht auffindbar.“ Bei Z10 ist die ID unbekannt. Bei Z17 ist sie bekannt, aber der Absender gehört im genannten Zeitraum nicht dazu.
„Z29 heißt, das Feld fehlt irgendwo in der Nachricht.“ Z29 gilt für den Anwendungsfall des Prüfidentifikators und nennt die Stelle. Fehlt eine Angabe, die nur als „Soll mit Bedingung“ gefordert ist, entsteht kein AHB-Fehler.
„Eine APERAK mit Z-Code lehnt die ganze Datei ab.“ Nur den Geschäftsvorfall, auf den sich der Code bezieht. Die ganze Datei lehnt nur eine CONTRL mit Syntaxfehler ab (oder ein Fehler auf Kopfebene, der die ganze Nachricht trifft).
„Der Absender ist immer schuld.“ Der Absender ist für die Behebung in seinem Bereich verantwortlich. Ob ein Zuordnungsfehler berechtigt ist, hängt aber auch von den Stammdaten des Empfängers ab. Deshalb nennt das AHB die zeitnahe Objektpflege als Pflicht aller Marktpartner.
„Z-Codes gelten in allen Nachrichten gleich.“ Nein. Dieselbe Zeichenfolge kann in einem anderen Nachrichtentyp etwas anderes bedeuten; siehe die Abgrenzung in Fehlercodes analysieren.
Welche Fassung gilt
Die Tabelle stammt aus dem APERAK Anwendungshandbuch, Version 1.1, Stand MIG 2.2, Publikationsdatum 01.04.2026, Autor BDEW. Die Bundesnetzagentur hat es mit Mitteilung Nr. 56 veröffentlicht. Die dort genannten Versionen gelten laut Mitteilung für alle umsetzungspflichtigen Marktteilnehmer verbindlich ab dem 01.10.2026. Die Codetabelle des PDF und die der informatorischen Lesefassung, die für diese Seite ausgewertet wurde, stimmen überein; allein gültig ist das PDF.
Eine neuere Fassung ist angekündigt, aber noch nicht gültig: Mitteilung Nr. 57 vom 31.07.2026 stellt unter anderem APERAK AHB 1.1a und APERAK MIG 2.2a als Entwurf zur Konsultation, verbindlich grundsätzlich ab dem 01.04.2027. Den Inhalt des Entwurfs hat dieser Artikel nicht geprüft. Bis zur endgültigen Veröffentlichung gilt die Version 1.1.
Quellen und Pflegehinweis
Tragende Quelle ist das APERAK Anwendungshandbuch 1.1, besonders Kapitel 1.2 bis 1.5 (Verantwortlichkeiten), 2.1 bis 2.4 (Prüfungen, Fristen), 3 (Tabellarische Darstellung) und 4.3 (Fehlercodes); Die Geltung belegt Mitteilung Nr. 56, den Ausblick Mitteilung Nr. 57. Nicht am Dokument geprüft sind die CONTRL-Dokumente, die APERAK MIG 2.2 und die Anwendungsübersicht der Prüfidentifikatoren. Aussagen darüber stützen sich auf das, was das APERAK AHB über sie sagt. Die Prüfschritte, die als „allgemein“ gekennzeichnet sind, sind Empfehlungen dieses Artikels und keine Vorgabe der Quelle.
Bei jeder neuen Mitteilung der Bundesnetzagentur zu den Datenformaten die Codetabelle in Kapitel 4.3, die Nutzungseinschränkungen und die Fristen in Kapitel 2.4.1 neu abgleichen.