|
Frage
|
Hallo,
wir erhalten seit kurzem (14 Tage) Z31-APERAK-Ablehnungen von einem Energiedienstleister (im Namen von 2 Strom- und Gaslieferanten) auf unsere Lieferbeginnbestätigungen (PI 11002) und unsere Stammdatenänderungen (PI 11117). Bis vor dem 16.08.23 wurden diese noch akzeptiert.
Hintergrund der Ablehnung ist lt. der Marktpartner, dass wir Segmente befüllen, welche nicht (mehr) befüllt werden müssen, da die erforderlichen Bedingungen nicht gegeben sind. Aus unserer Sicht ein klarer Fall von "die zu viel gemeldeten Daten sind zu ignorieren".
Bei den zuviel befüllten Segmenten handelt es sich konkret um die "Bezeichnung des Zählwerks auf dem Gerät" und "Singulär genutzte Betriebsmittel in der Netznutzungsabrechnung". Beide Angaben führen zu keinen Konflikten mit anderen Angaben und sind für Folgeprozesse unschädlich. Ein Ignorieren wäre einfach und erfolgt auch durch alle anderen in unserem Netzgebiet tätige Marktpartner.
Meinem Verweis auf die eine bereits in 2018 veröffentlichte Frage des Forum Datenformate (Ticketnummer 2018-00044) wurde mit folgender Begründung widersprochen:
"Den von Ihnen zitierten Text interpretieren wir so, dass ein Segment welches beim Prüfidentifikator im AHB mit aufgeführt ist, auch zum Umfang der Prüfschablone gehört. Dabei sind die Bedingungen des jeweiligen Segmentes einzuhalten.
Wenn die Bedingung sagt, dass ein betroffenes Segment, welches zum Prüfidentifikator und damit zur Schablone gehört, nicht aufzuführen ist, so kann dieses mit APERAK abgelehnt werden. Dies ist die Konsequenz die der Sender zu tragen hat.
Wir mögen aus Ihrer Sicht der einzige Marktpartner sein, der in entsprechenden Fällen mit APERAK reagiert, aber wir haben im Gegenzug auch genügend Marktpartner die nach Empfang der APERAK den entsprechenden gleich gelagerten Fehler korrigiert haben. Eine APERAK ist unserer Meinung nach eine entsprechend zulässige Konsequenz."
Ich bitte um zeitnahe Klarstellung zu dieser Thematik, denn aus unserer Sicht legt der MP die gängigen Regeln falsch aus und wälzt seine seit kurzem bestehenden IT-Probleme auf andere ab.
Vielen Dank.
C. Kunert
|
|
Antwort
|
Seher geehrter Herr Kunert,
nach den Vorliegenden Informationen gehen wir davon aus, dass Sie als Netzbetreiber dem Lieferanten eine Antwort senden (PID 11002). Diese lediglich aus dem Grund da Sie von einem Dienstleister sprechen.
Aus Ihrer Frage geht hervor, dass der Empfänger Ihres Geschäftsvorfalls auf diesen mit einer Verarbeitbarkeitsfehlermeldung (APERAK mit Codes Z31) reagiert.
Ein Geschäftsvorfall mit der von Ihnen beschriebene Problematik kann grundsätzlich nicht mit dem Fehlercode Z31 zurückgewiesen werden.
Zum Z31 ist dem CONTRL/APERAK Anwendungshandbuch, Kapitel 5.2 zu entnehmen:
Code: Z31
Bedeutung: Geschäftsvorfall wird vom Empfänger zurückgewiesen
Erläuterung: Der Geschäftsvorfall mit dem genannten Prüfidentifikator wird vom Empfänger nicht verarbeitet.
Entsprechend seiner Marktrolle verarbeitet der Empfänger Geschäftsvorfälle mit dem angegebenen Prüfidentifikator nicht. In diesem Fall wird keine weitere Prüfung des Geschäftsvorfalls durchgeführt.
Mit dem Code Z31 sagt der Lieferant aus, dass er keine Antworten auf Anmeldungen verarbeit. Dies ist aber offensichtlich falsch, da er ihnen gegenüber ausgesagt hat, dass er derartige Geschäftsvorfälle, die er von anderen NB erhält, verarbeitet. Entsprechend der Nutzungsdefinition des Codes Z31 fällt seine Nutzung zur Rückmeldung von "zu viel gesendeten Informationen" unter Codemissbrauch.
Im Weiteren sind Sie in Ihrer Frage auf die Interpretation des Senders der APERAK in Bezug auf die schon ältere Frage mit der Ticketnummer 2018-00044 eingegangen. In dieser Frage geht es um den von Ihnen beschriebenen Sachverhalt. Dieser ist im Kapitel 3.1.2 "AHB-Prüfung" im CONTRL-APERAK AHB beschrieben.
Auszug aus Kapitel 3.1.2
[..]
Enthält ein Geschäftsvorfall weniger Informationen, als er gemäß der AHB-Vorgabe enthalten
muss, so ist er abzulehnen. Hier ist zu beachten, dass Informationen, die gemäß des Prüfidentifikators
nicht enthalten sein sollten, vom Empfänger des Geschäftsvorfalls zu ignorieren sind. Ist
aufgrund des Prüfidentifikators die für den Anwendungsfall beschriebene Ausgestaltung der
Prüfschablone aufgrund der im Geschäftsvorfall enthaltenen Informationen und der Abhängigkeiten
nicht eindeutig, so entscheidet der Empfänger des Geschäftsvorfalls welche Informationen
des Geschäftsvorfalls er ignoriert und welche er zur Ausgestaltung der Prüfschablone und
somit zur AHB-Prüfung verwendet. Sollte sich aus den im Geschäftsvorfall enthaltenen Informationen,
die den Umfang für den Anwendungsfall überschreiten und dem Ignorieren der zu
viel übertragenen Informationen, eine vom Absender des Geschäftsvorfalls ungewünschtes
Verhalten des Empfängers ergeben, so hat der Absender des Geschäftsvorfalls die sich daraus
ergebenden Konsequenzen zu tragen.
[..]
Die von Ihnen dargelegte Interpretation des APERAK-Senders können wir nicht nachvollziehen.
Aus welcher Beschreibung sich seine Interpretation ergeben sollte, können wir dem CONTRL-APERAK AHB, das abschließend alle Regeln zum Einsatz der APERAK enthält, nicht entnehmen.
Dies spiegelt sich auch in den Fehlercodes der APERAK wider. Es gibt keinen Fehlercode, welcher zu nutzen wäre, wenn ein Geschäftsvorfall "zu viel" gesendete Informationen enthalten würde.
Es gibt lediglich Fehlercodes, welche zu verwenden sind, wenn ein Geschäftsvorfall eine höhere Anzahl an Wiederholungen eines Segments oder einer Segmentgruppe als diese für den Anwendungsfall beschrieben ist, enthält bzw. wenn ein Geschäftsvorfall mehr Codes enthält, als dies die entsprechende Paketdefinition des Anwendungsvorfalls erlaubt.
Diese beiden Fehlercodes haben jedoch nichts mir der von Ihnen beschriebenen Situation zu tun.
Fazit:
Aus den dargelegten Informationen leiten wir einen Missbrauch des Fehlercodes Z31 ab. Es gibt auch keinen anderen Fehlercode, mit welchem einen "Fehler" wie er von Ihnen als Sender verursacht wurde, gemeldet werden könnte. Einen Geschäftsvorfall, der zu viel Informationen enthält, ablehnen zu können ist gemäß Anwendungshandbuch nicht gewünscht.
Mit freundlichem Gruß
Ihr BDEW-Forum Datenformate
|
