|
PRICAT MIG 2.0c
|
Abgeschlossen
|
Wie kann der Wandlertyp über die Artikel-ID unterscheiden werden?
|
Wandler können nur anhand der Spannungsebene unterschieden werden. |
28.11.2023
|
2023-02010 |
|
|
Kurze Frage eines Laien - Wir wollen in unserer PRICAT gleiche Preise bei identischer Spannungsebene, aber unterschiedlichen Wandlertypen abbilden - hier ein Auszug aus der PRICAT für die Typen Blockstrom- und Messwandler in NS:
LIN+20++4-02-0-018:Z09'PRI+CAL:0.058607'
LIN+21++4-02-0-018:Z09'PRI+CAL:0.058607'
An welcher Stelle müsste der Edi-Code für den Wandlertyp genannt werden, damit die Zeilen für den empfangenden LIF eindeutig werden?
VG aus dem hohen Norden, A. Engel
|
2023-11-28 08:36:47 |
Hallo Herr Engel,
für die Artikelnummern ist es möglich, dass der Ersteller des Preisblatts zu einer Artikelnummer unterschiedliche Preise angibt, in dem sich diese beispielsweise im Preisschlüsselstamm unterscheiden. D. h. die Artikelnummer reicht nicht aus, um die Leistung und damit den Preis exakt identifizieren zu können, dies ist nur durch Hinzunahme mindestens eines weiteren Codes wie dem bereits erwähnten Preisschlüsselstamm möglich.
Im Rahmen des Festlegungsverfahrens BK6-20-160 wurde durch die Beschlusskammer 6 der Bundesnetzagentur die Artikelnummer durch die Artikel-ID ersetzt und gleichzeitig damit auch festgelegt, dass über jede Artikel-ID die damit erbrachte Leistung eindeutig identifiziert wird. Dies sorgt zum einen dafür, dass die Spalte „Bezeichnung“ in der EDI@Energy-Codeliste der Artikelnummern und Artikel-ID recht breit ist und die Inhalte dieser Spalte in den Zeilen regemäßig dafür sorgen, dass diese so hoch sind, weil sie so viel Information beinhalten und zum anderen dafür, dass in den PRICAT-Anwendungsfällen, in denen Artikel-ID verwendet werden, in diesen eine 1:1-Beziehung zwischen Artikel-ID und Preis besteht.
Nun zu Ihrer Frage: Aufgrund dieser Regeln müssten für die (preislich) unterschiedlichen Wandlertypen derselben Spannungsebene unterschiedliche Artikel-ID genutzt werden. Es ist aber nur eine Artikel-ID zur Abrechnung von Wandlern (je Spannungsebene) vorhanden. Bei den Wandlerpreisen kann somit nur zwischen unterschiedlichen Spannungsebenen unterschieden werden.
Freundliche Grüße
Ihr BDEW-Forum Datenformate
|
Ja
|
Thomas Seipt |
Klaus Keller |
Thomas Seipt |
Andreas Engel |
|
Nein
|
Vorschlag für Antwort erstellt
-------------Thomas Seipt-------------28.11.2023 18:16
Korrekturen
-------------Klaus Keller-------------01.12.2023 16:35
Anpassungen von Herrn Seidel in die Antwort übernommen.
-------------Thomas Seipt-------------05.12.2023 18:29
veröffentlicht
-------------Stefan Seidel-------------05.12.2023 21:53
|
Nein
|
Nein
|
|
PRICAT AHB 2.0c
|
Eingegangen
|
Muss das MSB-Preisblatt mit Artikel-IDs auf das vorherige Preisblatt mit Artikelnummern referenzieren?
|
Eine neue Version eines Preisblattes muss immer auf das vorherige Preisblatt referenzieren. |
24.10.2023
|
2023-01975 |
|
|
Muss bei der erstmaligen Übermittlung des Preisblattes für den Messstellenbetrieb mit Artikel-ID (gültig ab 01.01.24) auf die letzte Version des Preisblatts mit Artikelnummern referenziert werden oder erfolgt die erstmalige Übermittlung ohne Referenz?
|
2023-10-24 09:24:34 |
Sehr geehrter Marktteilnehmer,
die Regel, dass ein Preisblatt sich auf ein vorheriges Preisblatt zu beziehen hat, gilt ausnahmslos für alle Preisblätter deren Austausch in der Sparte Strom durch die von der BK6 festgelegten Prozesse vorgeschrieben ist. Dies bedeutet, dass auch die neue Version des Preisblatts des MSB (BGM+Z32 Preisblatt Messstellenbetrieb) mit Artikel-IDs und dem Gültigkeitsbeginn 01.01.2024 00:00 Uhr muss immer auf das vorherige Preisblatt mit Artikelnummern referenzieren (SG1 RFF+ACW-Referenznummer einer vorangegangenen Nachricht). Erst durch die Angabe der Vorgängerversion wird das Preisblatt mit den Artikelnummern zum Zeitpunkt 01.01.2024 00:00 Uhr in seiner Gültigkeit beendet.
Das beschriebene Vorgehen zur Referenzierung ist im Kapitel 4 Erläuterung zur Nutzung des RFF-Segments „Vorgängerversion“ des PRICAT AHB Version 2.0d zu finden.
Mit freundlichem Gruß,
Ihr BDEW-Forum Datenformate |
Ja
|
Thomas Seipt |
Klaus Keller |
Thomas Seipt |
Marko Demuth |
|
Nein
|
Erster Aufschlag.
-------------Gregor Scholtyschik-------------27.10.2023 09:04
Rechtschreibung und Verdeutlichung durch Einfügen von immer und fetter Markierung
-------------Klaus Keller-------------27.10.2023 13:34
Rechtschreibung und etwas umformuliert: "neues Preisblatt" ersetzt "durch neue Version des Preisblatts
-------------Thomas Seipt-------------27.10.2023 14:09
Ergänzung von Herrn Seidel aufgenommen
-------------Thomas Seipt-------------27.10.2023 16:56
|
Nein
|
Nein
|
|
PRICAT AHB 2.0c
|
Eingegangen
|
Ist die max. zulässige POG im Preisblatt vom MSB an den LF zu nennen?
|
Im Preisblatt wird der Preis geschrieben, der in der Rechnung auch verwendet wird. |
23.10.2023
|
2023-01974 |
|
|
Ein Lieferant lehnt unser aktuelles MSB-Preisblatt (Gültigkeit ab 01.01.2024) mit der Begründung ab, dass einige Positionen die maximal zulässige POG überschreiten. Als Beispiel ArtikelID 4-02-0-002, welche für die Kundengruppe für verbrauchende iMS zwischen 50.000 und 100.000 kWh Jahresverbrauch steht.
In Screenshot 1 der Auszug der Textpassage aus dem MsbG. So dürfen insgesamt maximal 200 € von uns als MSB abgerechnet werden (80 € an VNB, 120 € an AN). An diesen 200 € wird auch unser veröffentlichte Tagespreis in Höhe von 0,45918 € bemessen. Bei 366 Tagen in 2024 ergibt dies Netto 168,06 € und Brutto 199,99 €. Somit wäre die Rechnung und unser Preisblatt korrekt.
Der Lieferant argumentiert aber, dass sich der im Preisblatt angegebene Preis lediglich auf die Position 2b (also auf die 120 € / Jahr) bezieht. Somit würden wir die POG überschreiten.
Was ist Ihrer Meinung nach für die zu veröffentlichende PRICAT korrekt?
|
2023-10-23 10:06:54 |
Sehr geehrter Marktteilnehmer,
in dem Preisblatt vom MSB (BGM+Z32 Preisblatt Messstellenbetrieb) werden immer die Preise genannt, welche in der Rechnung verwendet werden.
In ihrem Beispiel darf der MSB im Preisblatt gegenüber dem Lieferanten nur die 120,00 € brutto als Berechnungsgrundlage nutzen. Im Preisblatt gegenüber einem NB werden die 80 € brutto genutzt.
Hinweis: Im Preisblatt werden nur Tagespreise, bezogen auf den Nettopreis, übermittelt.
Mit freundlichen Grüßen,Ihr BDEW Forum Datenformate |
Ja
|
Thomas Seipt |
Klaus Keller |
Thomas Seipt |
Marc Schmidt |
|
Nein
|
Erster Aufschlag
-------------Gregor Scholtyschik-------------27.10.2023 09:15
Rechtschreibfehler korrigiert
-------------Klaus Keller-------------27.10.2023 13:30
|
Nein
|
Nein
|
|
CONTRL MIG 2.0b
|
Abgeschlossen
|
Wie wird ein Segment in einer EDIFACT-Nachricht identifiziert ?
|
Die Identifikation erfolgt durch einfaches Hochzählen aller Segmente innerhalb jeder EDIFACT-Nachricht einer EDIFACT-Datei. |
17.10.2023
|
2023-01967 |
|
|
Im Segment UCS kann mit dem Fehlercode "13" ein fehlendes Segment in einer Nachricht identifiziert werden. Dabei ist auch die Position des Segments in der Nachricht anzugeben.
Das CONTRL MiG sagt dazu "Um ein fehlendes Segment zu melden, wird die Zählerposition
des zuvor verarbeiteten Segments verwendet, auf dem das fehlende Segment hätte folgen müssen"
Allerdings ist die Reihenfolge der Segmente nicht immer eindeutig definiert (https://www.edi-energy.de/index.php?id=40&tx_bdew_bdew%5Buid%5D=598&tx_bdew_bdew%5Baction%5D=show&tx_bdew_bdew%5Bcontroller%5D=Frage&cHash=2160edf5591f5b292f5bda74b9bbdc28).
In nachfolgendem Beispiel (INVOIC 2.8b) ist ein Ausschnitt einer Nachricht gezeigt. Wenn eines der beiden Pflicht MOA Segmente fehlt, welches Segmentposition gebe ich dann an? Die Segmentposition des letzten MOA Segments?
M TAX+7+VAT+++:::16+S'
R MOA+125:1000'
R MOA+161:160'
D MOA+113:116'
D MOA+115:16'
|
2023-10-17 14:07:14 |
Sehr geehrter Fragesteller,
zur Identifikation des betroffenen Segments werden die Segmente in der empfangenen EDIFACT-Nachricht gezählt. Es wird innerhalb jeder Nachricht von vorne mit dem Zählen begonnen.
Die explizite Darstellung der EDI@Energy-Nachrichten legt nicht die Reihenfolge fest, in der die unterschiedlichen expliziten Ausprägungen eines Segments in der Nachricht vorkommen dürfen. Beispielsweise dürfen die von Ihnen genannten MOA-Segmente auch in dieser Reihenfolge vorkommen:
TAX+7+VAT+++:::16+S'
MOA+113:116'
MOA+115:16'
MOA+161:160'
MOA+125:1000'
oder auch das wäre richtig:
TAX+7+VAT+++:::16+S'
MOA+113:116'
MOA+161:160'
MOA+125:1000'
MOA+115:16'
Auf Ihr Beispiel bezogen können Sie also erst wenn Sie alle vorhandenen MOA-Segmente eingelesen haben feststellen, ob das MOA+125 Segment oder das MOA+161 Segmente fehlt. Somit müssen Sie die Zählerposition des letzten MOA-Segments der MOA-Segmentgruppe in der Nachricht angeben, in der das MOA+125 Segment oder das MOA+161 Segmente fehlte. Nur wenn nach dem TAX-Segment kein einziges MOA-Segment in der Nachricht enthalten ist, ist die Zählerposition des TAX-Segments in der Nachricht anzugeben.
Hinweis: Ein Fehlen des MOA+113 Segments bzw. des MOA+115 Segments stellt selbstredend keinen Syntaxfehler dar wegen des Status "D"epending der Segmente.
Freundliche Grüße,
Ihr BDEW-Forum Datenformate
|
Ja
|
Klaus Keller |
Stefan Seidel |
Stefan Seidel |
Tobias Schemmelmann |
|
Nein
|
-------------Klaus Keller-------------26.10.2023 14:25
Änderungsantrag erstellt und an Herrn Seidel zur QS gesendet
-------------Klaus Keller-------------30.10.2023 12:01
Änderungsvorschlag von Herrn Seidel aufgenommen und geringfügig korrigiert
-------------Stefan Seidel-------------30.10.2023 17:50
veröffentlicht! |
Nein
|
Nein
|
|
CONTRL MIG 2.0b
|
Abgeschlossen
|
Dürfen (Gruppen-)Datenelemente, die keinen Inhalt tragen und am Ende eines Segments stehen in einer Nachricht enthalten sein?
|
Deratige (Gruppen-)Datenelemente dürfen, aber sollten nicht enthalten sein, sondern "abgeschnitten" werden. |
14.02.2023
|
2023-01653 |
|
|
Wir hätten eine Frage zum CONTRL-Code 16 - Zu viele Bestandteile
In der Marktkommunikation zwischen einen MP und uns wurde folgende Konstellation in der PARTIN 1.0a Segment BGM (=Beginn der Nachricht) verwendet:
BGM+10+A123456789101112131415++:'
Hier ist unsere Frage:
Hätte man hier nicht die PARTIN mit negativer CONTRL ablehnen müssen, da das BGM zu viele Gruppendatenelemente besitzt.
Im MIG würde man sich nach den zwei „++“ im Datenelement 4343 befinden jetzt kommt in der EDIFACT ja noch ein „:“ , aber es gibt ja jedoch kein Gruppendatenelement an dieser Stelle, somit gibt es zu viele Daten-/Gruppendatenelemente und die Nachricht hätte per negative CONTRL Code 16 – Zu viele Bestandteile abgelehnt werden müssen.
Sehen wir das so richtig?
Mit freundlichen Grüßen
Bastian Hader
|
2023-02-14 13:59:44 |
Hallo Herr Hader,
auch wenn durch den Doppelpunkt formal nur ein weiteres Datenelement angekündigt aber nicht befüllt wird, widerspricht der erwähnte Aufbau des BGM-Segmentes:
BGM+10+A123456789101112131415++:'
doch dem erwarteten Aufbau:
BGM+10+A123456789101112131415'
EDIFACT wurde in Zeiten entwickelt, als jedes Byte geholfen hat, Speicher zu sparen und Übertragungsvolumen von Nachrichten zu reduzieren, daher der Grundsatz mit dem Segmentendekennzeichen abzuschließen, wenn keine Informationen mehr folgen. Deshalb hat man damals nur festgelegt, dass alle (Gruppen-) Datenelemente, die am Ende eines Segments stehen und für die kein Inhalt vorhanden ist, abgeschnitten werden können, weil damals jeder dem es erlaubt war etwas abzuschneiden, also weg lassen zu können, diese Möglichkeit zum Datensparen genutzt hätte.
In der DIN9735:1988 + Amd 1:1992 steht hierzu sinngemäß, dass Datenelemente, die am Ende eines Segmentes stehen und die keinen Inhalt haben, ausgeschlossen werden können und dass dann das Segment-Endezeichen unmittelbar nach dem letzten mit Inhalt belegten Datenelement angegeben wird. Eine identische Aussage ist auch für Gruppendatenelemente enthalten.
Dennoch wurde "nur" die Übertragung eines Datenelementes angekündigt. Da es aber letztendlich nicht passiert ist, kann formal auch nicht mit Code 16 abgelehnt werden. Syntaktisch ist das Segment auch nicht fehlerhaft sondern nur unüblich. Wenn man von Diskussionen mit Marktpartnern und evt. Störungen der Marktkommunikation vermeiden möchte sollte man sich an dem orientieren, was üblich, d. h. weit verbreitet ist. Das ist in diesem Fall die nicht genutzten /(Gruppen-)Datenelemente abzuschneiden. Daher empfehle wir dies umzusetzen, auch wenn es nicht verbindlich vorgeschrieben ist.
Freundliche Grüße,
Ihr BDEW-Forum Datenformate |
Ja
|
Klaus Keller |
Stefan Seidel |
Stefan Seidel |
Bastian Hader |
CONTRL MIG 2.0b - Seite 13
PARTIN MIG 1.0a Konsolidierte Lesefassung mit Fehlerkorrekturen Stand: 15.08.2022 - Seite 8 |
Nein
|
-------------Klaus Keller-------------22.02.2023 08:53
Antwortvorschlag an Herrn Seidel zur Prüfung
-------------Stefan Seidel-------------22.02.2023 10:22
ein wenig nachjustiert und die DIN wegen (C) nur sinngemäß zitiert.
-------------Klaus Keller-------------22.02.2023 10:59
Veröffentlicht
|
Nein
|
Nein
|
|
Codeliste der Artikelnummern und Artikel-ID 5.4 - Außerordentliche Veröffentlichung
|
Abgeschlossen
|
Welches Vorzeichen hat der Preis der Artikel-ID zur Abrechnung von Modul 1 nach § 14a EnWG gem. Festlegungen BK6-22-300 und BK8-22/010-A?
|
Das Vorzeichen ist ein Minus |
13.10.2023
|
2023-01961 |
|
|
Sehr geehrte Damen und Herren,
ist der Preis im DE5118 des PRI-Segments zu den Artikel-ID, mit denen die Pauschale Reduzierung nach Modul 1 der Festlegungen zu Netzentgelten bei Anwendung der netzorientierten Steuerung von steuerbaren Verbrauchseinrichtungen und steuerbaren Netzanschlüssen nach § 14a EnWG gem. Festlegungen BK6-22-300 und BK8-22/010-A, beispielswese der 1-01-9-001 oder der 1-02-0-015 in der INVOIC abgerechnet bzw. in der PRICAT ausgetauscht wird als negative Zahl anzugeben?
Vielen Dank und freundliche Grüße!
|
2023-10-13 13:13:13 |
Sehr geehrter Marktteilnehmer,
ja, bei all diesen Artikel-ID, von denen sie zwei beispielhaft genannt haben, muss der Preis negativ sein, denn nur so ergibt die Multiplikation der Werte aus dem QTY- und PRI-Segment einen negativen Wert im MOA-Segment, da die Anzahl der Stück (in QTY energetische Mengenangaben) und die Anzahl der Tage (in QTY zeitliche Mengenangaben) positive Zahlen in den DE6060 sind. Der Wert im DE5004 des MOA-Segments „Positionsnettobetrag“ muss negativ sein, da nur dadurch eine Reduktion des fälligen Betrags erfolgt, was durch Anwendung dieser Artikel-ID erreicht werden soll.
Mit freundlichem Gruß
Ihr BDEW-Forum Datenformate |
Ja
|
Beate Becker |
Klaus Keller |
Beate Becker |
Stefan Seidel |
|
Nein
|
-------------Stefan Seidel-------------13.10.2023 13:13
Erstentwurf erstellt
-------------Stefan Seidel-------------18.10.2023 16:42
Veröffentlicht |
Nein
|
Nein
|
|
AS4-Profil 1.0
|
Eingegangen
|
[Thema: Doppelt komprimierte Dateien]
|
Keine doppelte Komprimierung |
09.10.2023
|
2023-01950 |
|
|
Bei der Aktivierung der ersten AS4-Verbindungen ist uns aufgefallen, das nach wie vor große Dateien vorkomprimiert versendet werden. Bei der Nutzung von Email als Transportweg hat das sicherlich Sinn gemacht, da aber sowhl AS2 als auch AS4 eine Kompression auf Protokollebene ermöglichen - und sie sogar verpflichtend vorgeschrieben ist, werden hier redundante Prozessschritte durchgeführt, die unserer Auffassung nach Energie durch überflüssigen Prozessaufwand verschwenden. Eine Klärung oder Empfehlung an die Mitglieder wäre hier hilfreich.
|
2023-10-09 11:03:05 |
Sehr geehrte Fragestellerin,
vielen Dank für Ihre Anfrage.
Bei der Nutzung von AS4 als Übertragungsweg wird auschließlich die im Übertragungsprotokoll zu verwendende Komprimierung genutzt. Die Übertragungsdateien dürfen nicht vorab komprimiert werden.
Freundliche Grüße
Ihr Forum Datenformate |
Ja
|
Rene Hoffmann |
Rene Hoffmann |
Rene Hoffmann |
Michael Baden |
2.2.3.3 Nachrichtenkomprimierung
Die AS4-Spezifikation definiert die Komprimierung von Nutzdaten als eine ihrer zusätzlichen
Funktionen. Die Komprimierung von Nutzdaten ist eine nützliche Funktion für viele
Inhaltstypen, einschließlich XML-Inhalten.
Der Parameter PMode[1].PayloadService.CompressionType MUSS auf den Wert
„application/gzip“ gesetzt werden. Beachten Sie, dass GZIP der einzige Kompressionstyp ist, der
derzeit in AS4 unterstützt wird. |
Nein
|
|
Nein
|
Nein
|
|
AS4-Profil 1.0
|
Eingegangen
|
[Thema "#509PKIPathv1"]
|
ASN.1 data type PkiPath ::= SEQUENCE OF Certificate |
26.09.2023
|
2023-01942 |
|
|
Die im AS4-Profil beschriebenen Anforderungen bzgl. Signatur und Verschlüsselung sind textuell beschrieben. Die dazugehörigen Beispiele enthalten aber teilweise widersprüchliche Informationen. Wir gehen davon aus, dass der Text gilt und die Beispiele abweichende/ fehlerhafte Inhalt haben. Ist diese Annahme korrekt?
Eine Anforderung ist jedoch unklar, was die konkrete Implementierung angeht: Abschnitt 2.2.6.2.1 Signatur beschreibt die profilkonforme Verwendung des sogenannten „BinarySecurityToken“ in der Ausprägung „ValueType=http://docs.oasis- open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509PKIPathv1“ als MUSS. Entsprechende Ausprägung ist zwar definiert als Typ, jedoch nicht der exakte Inhalt desselben. Dazu kommt, dass das darunter liegende Beispiel eben jenen Typ nicht verwendet, sondern den Typ „#X509v3“ (ebenfalls WS-Security konform, aber wegen MUSS nicht erlaubt). Das Pendant im Working Draft des EU-AS4-Profils zeigt im Beispiel zwar auch Typ „#509v3“, beschreibt aber die Ausprägung „#X509PKIPathv1“ nur als SOLLTE. Meinen Nachforschungen zufolge wird die Ausprägung „#509PKIPathv1“ zum einen kaum unterstützt, zum anderen konnte ich keine Spezifikation finden, die explizit beschreibt, was der Wert sein soll. Momentan gehe ich von ASN.1 „SEQUENCE OF CERTIFICATE“ als Base64-DER aus, zumal der Typ „#x509v3“, soweit mir bekannt, ein Base64-DER-Zertifikat ist.
Da hier mitunter Interoperabilitätsprobleme lauern, würde ich darum bitten, dass klar gestellt wird, was das deutsche AS4-Profil hier genau erwartet.
|
2023-09-26 11:38:14 |
Sehr geehrte Fragesteller,
vielen Dank für Ihre Anfrage.
Die Anforderungen zur Nutzung dieses Elements kommt aus dem Dokument "OASIS Web Services Security (WSS)". Hier findet sich der Verweis auf "Web Services Security 3 X.509 Certificate Token Profile".
Für die Syntax und Codierung dieses Elements wird verwiesen auf: ITU-T X-SERIES RECOMMENDATIONS: Information Technology – Open Systems Interconnection – The Directory: Public-key and attribute certificate frameworks.Auf den Seiten 20ff findet sich die gesuchte Spezifikation.
Freundliche Grüße
Ihr Forum Datenformate |
Ja
|
Rene Hoffmann |
Rene Hoffmann |
Rene Hoffmann |
Marco Kruse |
2.2.6.2.1 Signatur
Die AS4-Nachrichtensignierung basiert auf der W3C XML Signatur-Empfehlung. Die aktuelle
Version dieses Standards ist die Spezifikation vom April 2013, Version 1.1 [XMLDSIG1], die
relevante neue Algorithmus-Bezeichner definiert. Eine vollständige Liste ist definiert in
[RFC6931].
Dieses BDEW-AS4-Profil verwendet die AS4-Algorithmen für Hashing und Signatur wie in
[TR03116-3] (Abschnitt 9.1) beschrieben. Die zu verwendende Kurve MUSS BrainpoolP256r1
sein.
WS-Security definiert drei Optionen für den Verweis auf ein Sicherheits-Token (Absatz 3.2 in
[WSSX509]). In [ebMS3] oder [AS4] ist kein Parameter für die Auswahl einer bestimmten Option
definiert. In diesem Profil MUSS die Option BinarySecurityToken verwendet werden, um auf das
Sicherheits-Token zu verweisen, und MUSS die in Abschnitt 3.1.2 von [WSSX509] definierte
Option X509PKIPathv1 Token Type verwenden. Die Verwendung dieses Token-Typs MUSS durch
setzen des Attributs ValueType von wsse:BinarySecurityToken auf den Wert
„http://docs.oasis- open.org/wss/2004/01/oasis-200401-wss-x509-token-profile1.0#X509PKIPathv1“ angezeigt werden.
Dieses Profil verwendet die folgende AS4-Konfiguration im P-Mode:
› Der Parameter von PMode[1].Security.X509.Sign MUSS nach Maßgabe der Abschnitte 5.1.4
und 5.1.5 von [AS4] gesetzt werden.
› Der Parameter von PMode[1]. Security.X509.Signature.HashFunction MUSS auf den
Festwert „http://www.w3.org/2001/04/xmlenc#sha256“ gesetzt werden.
› Der Parameter von PMode[1]. Security.X509.Signature.Algorithm MUSS auf den Festwert
„http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha256“ gesetzt werden.
Die in [RFC6090] Abschnitt 7 beschriebenen Interoperabilitätsanforderungen MÜSSEN
implementiert werden. |
Nein
|
|
Nein
|
Nein
|
|
AS4-Profil 1.0
|
Eingegangen
|
AS4-Profil: Es MUSS mindestens TLS Version 1.2 vorliegen (TLS 1.2 UND TLS 1.3)
|
TLS 1.2 muss unterstützt werden, TLS 1.3 sollte unterstützt. |
10.07.2023
|
2023-01825 |
|
|
Im "BDEW AS4-Profil V 1.0" (2.2.6.1) steht folgendes zu den TLS-Versionen:
"Es MUSS mindestens TLS Version 1.2 vorliegen [RFC5246]."
Wie ist das genau zu verstehen? Wir interpretieren das so, dass sowohl Sender und Empfänger TLS 1.2 UND TLS 1.3 unterstützen MÜSSEN.
Wir bitten um klarstellende Formulierung im Dokument.
|
2023-07-10 11:47:48 |
Sehr geehrter Marktteilnehmer,
Das BDEW AS4 Profil fordert die verpflichtende Umsetzung der Vorgaben aus der technischen Richtlinie der BSI TR-03116-3 ein. Die Vorgaben für TLS sind dort dem Kapitel 4 TLS-Kommunikation im WAN und in derMarktkommunikation zu entnehmen.
Mit freundlichem Gruß
Ihr BDEW-Forum Datenformate |
Ja
|
Rene Hoffmann |
Rene Hoffmann |
Rene Hoffmann |
Thomas Beckers |
"BDEW AS4-Profil V 1.0" (2.2.6.1) |
Nein
|
|
Nein
|
Nein
|
|
AS4-Profil 1.0
|
Eingegangen
|
Kryptographiemodul
|
Es müssen Kryptografiemodule gemäß Security Level 1 nach „Key Lifecycle Security Requirements“ verwendet werden. |
14.06.2023
|
2023-01796 |
|
|
Ist bei der Verwendung von AS4 zukünftig der Einsatz eines Hardware-Sicherheitsmoduls (HSM) zur Speicherung/Verwaltung von Zertifikaten bzw. deren Verwendung (zur Ver- und Entschlüsselung von Nachrichten) Pflicht oder können Softwarelösungen verwendet werden, die den Kryptografischen Anforderungen vom BSI genügen?
|
2023-06-14 16:33:20 |
Teilnehmer der Marktkommunikation, die Nachrichten gemäß der Regelungen zum Übertragungsweg mittels des Web-Service AS4 austauschen, sind passive EMT im Sinne der Certificate Policy der Smart Metering PKI.
In der aktuellen Fassung der Policy (Version 1.1.2, 25.01.2023) wurden die Anforderungen für passive EMT geändert. Es heißt nun:
„Passive EMT MÜSSEN Kryptografiemodule einsetzen, die mindestens konform zu [KeyLifeSec] – Security Level 1 sind.“ ([KeyLifeSec] BSI: Key Lifecycle Security Requirements).
Die konkreten Anforderungen an die Kryptografiemodule muss jeder Marktteilnehmer gemäß des von ihm zu erstellendem Sicherheitskonzept für sich ableiten. |
Ja
|
Rene Hoffmann |
Rene Hoffmann |
Rene Hoffmann |
Torsten Küsters |
|
Nein
|
|
Nein
|
Nein
|
|
INVOIC / REMADV AHB - informatorische Lesefassung 2.5b
|
Eingegangen
|
Ist die es richtig, dass auch in den Fällen, in denen als EBD-Code E_0210 in einer REMADV verwendet wird, bei Nutzung von A27, die Rechnungsnummer einer zugehörigen Rechnung in SG12 RFF+AFL angegeben werden muss?
|
Nein, die entsprechenden Bedingungen im INVOIC/REMADV-AHB müssen korrigiert werden |
19.09.2023
|
2023-01927 |
|
|
Sehr geehrte Damen und Herren,
man kann sowohl NN-Rechnungen als auch MSB-Rechnungen auf Positionsebene mit A27 reklamieren.
E_0406/A27: "Ist der Abrechnungszeitraum der Abschlagsrechnung
bereits in einer vorhergehenden, akzeptierten und nicht
stornierten Rechnung (Turnusrechnung, Zwischenrechnung,
Monatsrechnung oder 13I) enthalten?"
E_0210/A27: " Ist der Zeitraum der Rechnungsposition vollständig im
Gültigkeitszeitraum eines oder mehrerer Preisblätter
enthalten?"
Dass man für E_0406/A27 eine Referenz auf eine INVOIC notwendig ist, leuchtet uns ein. Allerdings ist die Bedingung "Referenz auf INVOIC" im AHB für A27 ohne Codeliste festgelegt. Welche INVOIC soll man denn referenzieren, wenn man E_0210/A27 wählt, weil man eine INVOIC wegen des Preises aus der PRICAT ablehnt?
Danke,
mit freundlichen Grüßen
David Schmauser und Ulrike Steiger.
|
2023-09-19 10:54:10 |
Sehr geehrte Frau Steiger, sehr geehrte Herr Schmauser,
vielen Dank für Ihre Frage. Sie haben einen Fehler gefunden. Wir werden diese in der nächsten konsolidierten Lesefassung mit Fehlerkorrekturen des INVOIC / REMADV AHB korrigieren.
Mit freundlichem Gruß
Ihr BDEW-Forum Datenformate |
Ja
|
Klaus Keller |
Stefan Seidel |
Klaus Keller |
Ulrike Steiger |
The condition for SG12_RFF+AFL is [26] ⊻ ([70] ∧ ([65] ⊻ [68] ⊻ [66] ⊻ [69] ⊻ [64] ⊻ [67]))
That means in case the condition 26 or ( condition 70 and ( condition 65 or condition 68 or condition 66 or condition 69 or condition 64 or condition 67 ) is fulfilled, the segment is mandatory.
condition 26 is 'Wenn in dieser SG12 AJT DE4465 = A27/A51/A62/ A82/AA1/AA6/AA7/AB8/AD6'
|
Nein
|
-------------Stefan Seidel-------------22.09.2023 15:06
Erstaufschlag erstellt
-------------Klaus Keller-------------22.09.2023 16:25
angepasst und veröffentlicht
|
Nein
|
Nein
|
|
UTILMD AHB GPKE / GeLi Gas 6.1e
|
Abgeschlossen
|
Müssen zu viel gesendete Informationen, welche im Anwendungsfall mit Bedingung aufgeführt, deren Bedingung aber nicht erfüllt ist, ignoriert werden?
|
Zu viel gesendete Informationen müssen ignoriert werden, sofern es nicht die maximal erlaubte Segment-/Segmentgruppenwiederholbarkeit oder die Überschreitung der Anzahl der Codes aus einer Paketdefinition handelt. |
29.08.2023
|
2023-01899 |
|
|
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
|
2023-08-29 19:51:46 |
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: Z31Bedeutung: 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 enthaltenmuss, so ist er abzulehnen. Hier ist zu beachten, dass Informationen, die gemäß des Prüfidentifikatorsnicht enthalten sein sollten, vom Empfänger des Geschäftsvorfalls zu ignorieren sind. Istaufgrund des Prüfidentifikators die für den Anwendungsfall beschriebene Ausgestaltung derPrüfschablone aufgrund der im Geschäftsvorfall enthaltenen Informationen und der Abhängigkeitennicht eindeutig, so entscheidet der Empfänger des Geschäftsvorfalls welche Informationendes Geschäftsvorfalls er ignoriert und welche er zur Ausgestaltung der Prüfschablone undsomit 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 zuviel übertragenen Informationen, eine vom Absender des Geschäftsvorfalls ungewünschtesVerhalten des Empfängers ergeben, so hat der Absender des Geschäftsvorfalls die sich darausergebenden 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 |
Ja
|
Holger Weickenmeier |
Jessica Rahn |
Holger Weickenmeier |
Christian Kunert |
CONTRL (Syntax Version 3) / APERAK Anwendungshandbuch, S. 23
UTILMD AHB
|
Nein
|
Vorschlag erstellt.
-------------Holger Weickenmeier-------------30.08.2023 13:39
Anpassungen gem. Mailaustausch vorgenommen.
-------------Holger Weickenmeier-------------27.09.2023 15:41
veröffentlicht
-------------Stefan Seidel-------------02.10.2023 10:27
|
Nein
|
Nein
|
|
Entscheidungsbaum-Diagramme und Codelisten 3.4
|
Abgeschlossen
|
Wie wird eine Anmeldung mit TA „Neuanlage“ abgelehnt, wenn schon ein AN zugeordnet ist?
|
Die Unterscheidung zwischen den TA Neuanlage und Einzug ist nur bei der Identifizierung notwendig |
10.08.2023
|
2023-01885 |
|
|
Wie lehnen wir als Netzbetreiber eine Anmeldung, welche der Lieferant mit dem Transaktionsgrund „Einzug in Neuanlage“ gesendet hat, ab, wenn an der Marktlokation schon ein Anschlussnutzer vorhanden ist?
Aktuell können wir solche Anmeldungen nicht ablehnen.
|
2023-08-10 11:40:18 |
Für einen Anschlussnutzer ist es nicht zwingend ersichtlich, ob sich an einer Marktlokation schon ein anderer Anschlussnutzer (z.B. Bauträger) angemeldet hatte. Die Unterscheidung zwischen den Transaktionsgründen „Einzug in Neuanlage“ und „Ein-/Auszug (Umzug)“ liegt in der Identifizierung der Marktlokation. Die Intention des Anschlussnutzers ist die gleiche. „Der Anschlussnutzer ist eingezogen“.
Dies spiegelt sich auch im EBD E_0462. Hier wird bei der Identifizierung zwischen den Transaktionsgründen „Einzug in Neuanlage“ und „Ein-/Auszug (Umzug) unterschieden. Bei der weiteren Verarbeitung ist es irrelevant, ob der Transaktionsgrund „Einzug in Neuanlage“ oder „Ein-/Auszug (Umzug)“ in der Anmeldung angegeben wurde, die weitere Verarbeitung ist identisch und erfolgt über die Prüfung auf den identischen AN. Damit ist hier keine Ablehnung aufgrund des Transaktionsgrundes zulässig.
Viele Grüße Ihre PG Entscheidungsbaumdiagramme |
Ja
|
Matthias Braun |
Vanessa Stemplowsky |
Matthias Braun |
Holger Weickenmeier |
|
Nein
|
Frage wurde in der Sitzung am 10.08.2023 besprochen und das Ergebnis hier veröffentlicht.
-------------Holger Weickenmeier-------------10.08.2023 11:40
|
Nein
|
Nein
|
|
Entscheidungsbaum-Diagramme und Codelisten 3.4
|
Abgeschlossen
|
Ist eine Änderung der Konzessionsabgabe möglich, wenn bereits die Sondervertragskunden-KA zugeordnet ist?
|
Der Wechsel der Konzessionsabgabe von TA zu SA in einer MVR oder 13i ist möglich. |
01.06.2023
|
2023-01772 |
|
|
Im Abschnitt zur Abrechnung der Konzessionsabgabe im EBD E_0406 ist beschrieben, dass der NB für die 13I Rechnung ohne Stammdatenänderung auf die Tarifkunden Konzessionsabgabe wechseln darf, wenn vorher die Sondervertragskunden Konzessionsabgabe kommuniziert wurde. Im EBD E_0477 'Bestellung prüfen' ist festgelegt, dass eine Änderung der Konzessionsabgabe nicht möglich ist, wenn die Sondervertragskunden-KA zugeordnet ist.
Daraus ergeben sich unsere Fragen.
Folgende Situation:
Angenommen einer Marktlokation ist die Sondervertragskunden-KA zugeordnet,
die MaLo erfüllt die Anforderungen dafür nicht (MaLo ist in der NS-Ebene und der Verbrauch weist keine zwei Monate mit Leistungsspitze über 30kW auf).
Die Anforderungen für die Konzessionsabgabe NT werden an der MaLo erfüllt.
Konsequenz:
Der NB kann die MaLo auf Grund der Ausnahmeregelung aus dem EBD E_0406 mit der Tarifkunden Konzessionsabgabe abrechnen.
Die Konzessionsabgabe NT darf nicht verwendet werden, da diese nicht bestellt wurde und der NB somit nicht weiß, dass die Anforderungen für die Konzessionsabgaben NT erfüllt sind.
Der LF hat nicht die Möglichkeit die Konzessionsabgabe NT zu bestellen, da die Bestellung immer abgelehnt wird.
Die Konzessionsabgabenverordnung schreibt vor, dass die Konzessionsabgabe NT abgerechnet werden muss.
Fragen/Hinweise:
• Ist diese Interpretation korrekt und falls ja, ist dies das gewünschte Verhalten?
• Falls der NB die Tarifkunden KA abrechnet auf Grund der Ausnahmeregelung aber nur die Sondervertragskunden-KA kommuniziert wurde, kann die Rechnung dann immer mit A78 abgelehnt werden, da es keine Position mit der erwarteten Artikel-ID für die Sondervertragskunden-KA gibt die vorher mit den Stammdaten ausgetauscht wurde?
• Zudem kennt der Lieferant typischerweise nicht die Einwohneranzahl von sämtlichen Gemeinden, in die er beliefert. Entsprechend weiß der Lieferant nicht mit welcher Tarifkunden-KA-ArtikelID diese MaLo abgerechnet werden wird (1-08-4-001, 1-08-4-002, 1-08-4-003, 1-08-4-004 oder ggf. eine gemeindespezifische ArtikelID). Dies führt dazu, dass das Ziel der Einführung von ArtikelIDs in der NN-Rechnung an dieser MaLo nicht mehr erreicht wird: Der Lieferant weiß nicht, welche ArtikelIDs in der Rechnung zu erwarten sind und somit nicht welcher Rechnungsbetrag zu erwarten ist. Das Problem besteht unabhängig davon, ob die MaLo die Anforderungen für die Konzessionsabgabe NT erfüllt oder nicht.
|
2023-06-01 11:14:13 |
Sehr geehrter Marktteilnehmer,
falls der NB die Tarifkunden-KA abrechnet, aufgrund der Ausnahmeregelung aber nur die Sondervertragskunden-KA kommuniziert wurde, kann die Rechnung nicht mit A78 abgelehnt werden. Die Ausnahmeregelung ist mit den Prüfschritten im EBD E_0406 und E_0407 abgedeckt, so z.B. auch im Hinweis zum Prüfschritt 805. Ihre Annahme ist richtig, dass in dieser Ausnahmeregelung die entsprechende Tarifkunden-KA nicht im Vorfeld vom NB an den LF kommuniziert werden muss. Der LF muss in diesem Fall die Höhe der Konzessionsabgabe eigenständig ermitteln und zur Rechnungsprüfung heranziehen. Zu dem E_0477 soll es zeitnah einen ergänzenden Hinweis im Prüfschritt 10 geben.
Mit freundlichen Grüßen
Ihr BDEW-Forum Datenformate |
Ja
|
Matthias Braun |
Vanessa Stemplowsky |
Vanessa Stemplowsky |
Daniel Beckers |
Auszug aus Abrechnung der Konzessionsabgabe (Seite 66)
Wenn der NB in den Stammdaten die Sondervertragskunden Konzessionsabgabe kommuniziert hat, so kann er ohne Stammdatenänderungen lediglich in der 13I auf die Tarifkunden Konzessionsabgabe wechseln.
Prüfschritt 1 von EBD E_0477
Ist der Marktlokation zum Zeitpunkt der bestellten Änderung die Sondervertragskunden-KA zugeordnet?
Ja => Ablehnung mit A01
Sondervertragskunden-KA gemäß § 2 Abs. 3 der Konzessionsabgabenverordnung, daher keine Änderung möglich
Prüfschritt 805 von EBD E_0406
Fehlen noch Artikel-ID für Rechnungspositionen ≥ 01.01.2023 00:00 Uhr, die vorher mit den Stammdaten ausgetauscht und somit in der Rechnung erwartet wurden?
Ja => Ablehnung mit A78
Cluster: Ablehnung auf Summenebene
Erwartete Artikel-ID in der Rechnung nicht vorhanden.
Hinweis: Die erwarteten Artikel-ID sind zu nennen.
|
Nein
|
Vorschlag der KG Abrechnung.
Zusätzlich: Antwort ist nur in Verbindung mit der Anpassung des EBD E_0477 möglich.
-------------Thomas Seipt-------------23.08.2023 11:58
Veröffentlicht und beantwortet, vorher in PG besprochen
-------------Vanessa Stemplowsky-------------24.08.2023 09:06
|
Nein
|
Nein
|
|
Entscheidungsbaum-Diagramme und Codelisten 3.3
|
Abgeschlossen
|
Passt die Frist zur Fälligkeit im EBD E_0406 zur GPKE?
|
Die Fristenberechnung im EBD entspricht den Vorgaben der GPKE. |
07.08.2023
|
2023-01873 |
|
|
Der Prüfschritt 31 sagt aus , dass die Fälligkeit einer Netznutzungsrechnung größer 10 WT zum Rechnungseingangsdatum sein muss, ansonsten ist die Fälligkeit unterschritten.
In der GPKE hingegen sind als Zahlungsziel einer Netznutzungsrechnung 10 WT definiert (Kapitel 7.2).
So auch im Lieferantenrahmenvertrag Strom. Im §8, Absatz 12 heißt es "Rechnungen und Abschlagsberechnungen werden zu dem vom Netzbetreiber angegebenen Zeitpunkt fällig, frühestens jedoch zehn Werktage nach Zugang der Zahlungsaufforderung.
Daraus folgt, dass die Angaben der Fälligkeiten nicht identisch sind. Welche Aussage soll zur Prüfung herangezogen werden? Mindestens 10 WT oder mind. 11 WT nach Rechnungseingang?
|
2023-08-07 10:58:14 |
Sehr geehrter Marktteilnehmer,
die Fristenberechnung im EBD entspricht den Vorgaben der GPKE. Siehe Kapitel Frsitberechnung. Hiernach beginnt die Frist ab dem Folgetag des Eingangs der Rechnung. Die Frist beinhaltet immer vollständige Werktage.Beispiel zur Werktagsberechnung:
Freundliche GrüßeIhr Forum Datenformate |
Ja
|
Matthias Braun |
Vanessa Stemplowsky |
Matthias Braun |
Lusine Kloos |
Frage zum Prüfschritt 31 (Seite 67) |
Nein
|
Vorschlag der Kleingruppe Abrechnung
-------------Thomas Seipt-------------09.08.2023 16:37
Besprochen in gruppe, veröffentlichung
-------------Vanessa Stemplowsky-------------10.08.2023 09:14
|
Nein
|
Nein
|
|
Entscheidungsbaum-Diagramme und Codelisten 3.3
|
Abgeschlossen
|
Ist der Wechsel der Konzessionsabgabe von TA zu SA in einer MVR möglich?
|
Der Wechsel der Konzessionsabgabe von TA zu SA in einer MVR ist möglich. |
31.07.2023
|
2023-01861 |
|
|
Bei E_0406 und E_0407 schlägt im Prüfschritt 460 die Ermittlung der korrespondierenden Resultierenden fehl, wenn Konzessionsabgabe TA zurückgenommen wird und Konzessionsabgabe SA neu berechnet wird.
Für die abweichende Abrechnung der SA Konzessionsabgabe obwohl die TA per Stammdaten gemeldet worden ist, gibt es ja schon eine Ausnahme. Trotzdem muss validiert werden, ob die Rücknahme und Neuberechnung der Positionen soweit stimmig ist in der MVR.
Nimmt ein Netzbetreiber in der MVR die KOA TA mit Artikel-ID 1-08-4-002 vom 01.01.2023 - 31.05.2023 zurück kann die Neuberechnung der KOA SA mit Artikel-ID 1-08-3-001 vom 01.01.2023 - 30.06.2023 nicht geprüft werden nach Prüfschritt 460:
"Beginnt der Zeitraum der korrespondieren Resultierenden zum selben Zeitpunkt wie der Zeitraum dieser Resultierenden und enthält der Zeitraum der korrespondierenden Resultierenden keinen Zeitraum des Monats, in dem die Resultierende endet?"
Damit die korrespondierende Resultierende gebildet werden kann muss folgendes aus dem EBD beachtet werden:
"Definition: korrespondierende Resultierende
Die korrespondierende Resultierende zu einer Resultierenden ist die Resultierende, die gemäß Bildungsregel einer Resultierenden gebildet wird, wenn man die andere Artikel-ID (entspricht der korrespondierenden Artikel-ID) dieser Gruppenartikel-ID wählt als die Artikel-ID, mit der die Resultierende gebildet wurde, die zur Abrechnung derselben physikalischen Größe verwendet wird."
Es gibt nur 2 festgelegte Gruppen-Artikel ID für die Konzessionsabgaben: 1-08-2-AGS-KG und 1-08-5-AGS-KG
Somit fehlen die Gruppenartikel ID:
1-08-1
1-08-3
1-08-4
1-08-6
Werden hier nun die fehlende Gruppenartikel-ID noch ergänzt oder generell im EBD die Prüfung der Konzessionsabgabe angepasst?
Vielen Dank.
|
2023-07-31 09:42:58 |
Sehr geehrte Marktteilnehmerin,
der Wechsel der Konzessionsabgabe von TA zu SA in einer MVR ist möglich, da die Frage des Prüfschritts 450 „Wird mit der Artikel-ID eine physikalische Arbeit abgerechnet?“ mit "nein" beantwortet werden muss. Es wird nicht eine physikalische Arbeit, sondern die Konzessionsabgabe in der Position abgerechnet. Dadurch wird zum Prüfschritt 470 gesprungen.
Die Validierung der Rücknahmen für den Wechsel der Konzessionsabgabe von TA zu SA in der MVR erfolgt ab Prüfschritt 560.
Freundliche GrüßeIhr Forum Datenformate |
Ja
|
Matthias Braun |
Vanessa Stemplowsky |
Matthias Braun |
Ramona Pantani |
|
Nein
|
Vorschlag der Kleingruppe Abrechnung
-------------Thomas Seipt-------------09.08.2023 16:42
in PG besprochen und veröffentlicht
-------------Vanessa Stemplowsky-------------10.08.2023 09:18
|
Nein
|
Nein
|
|
Entscheidungsbaum-Diagramme und Codelisten 3.3
|
Abgeschlossen
|
Dürfen die Energiemengen auch für Zeiträume vor dem Lieferbeginn bei unterjährigen Lieferbeginn aufgeführt werden?
|
Wenn erforderlich, müssen auch Leistungswerte und Energiemengen für Zeiträume vor dem Lieferbeginn angegeben werden. |
26.07.2023
|
2023-01847 |
|
|
Wir haben einen Fall mit einem unterjährigen Lieferbeginn. Der Netzbetreiber fügt sowohl im Lieferschein, als auch in der INVOIC auch noch die kWh-Werte der Zeiträume vor Lieferbeginn auf.
Uns stellt sich nun die Frage, ob die Beifügung dieser Mengen im Lieferschein bzw. in der INVOIC gestattet ist?
Darüber hinaus bekommen wird die INVOIC reklamiert, da die in den abrechenbaren Stammdaten mitgeteilten Artikel-IDs erst ab unserem Lieferbeginn gültig sind.
Auch hier stellt sich uns die Frage, ob dies korrekt ist?
|
2023-07-26 10:53:51 |
Sehr geehrter Marktteilnehmer,
der Lieferschein muss die Abrechnungsenergiemengen der Netznutzungsrechnung und falls erforderlich, alle notwendigen Leistungswerte enthalten. Dabei ist es unerheblich, ob die Abrechnungsenergiemengen bzw. Leistungswerte vor dem Lieferantenwechsel aufgetreten sind.
D.h., Positionsmengen, die in der Netznutzungsrechnung angegeben werden, müssen auch im Lieferschein aufgeführt werden (Frage 330). Ausgenommen ist die Zonung der Energiemengen bei gesetzlichen Umlagen und Abgaben.
Freundliche Grüße,Ihr BDEW-Forum Datenformate |
Ja
|
Matthias Braun |
Vanessa Stemplowsky |
Matthias Braun |
Michael Fuhrer |
|
Nein
|
Antwort in Kleingruppe erarbeitet
-------------Thomas Seipt-------------18.08.2023 16:36
|
Nein
|
Nein
|
|
Entscheidungsbaum-Diagramme und Codelisten 3.3
|
Abgeschlossen
|
Ist die Reklamation und Ablehnung der Profilscharen mit E_0100:A05 des Lieferanten berechtigt?
|
Die Reklamation ist gerechtfertigt |
20.07.2023
|
2023-01843 |
|
|
Hallo,
im EBD 7.8.1 E_0100 "Profile bzw. Profilscharen prüfen" wird in Schritt 6 geprüft, ob die niedrigste Temperaturmaßzahl der Profilschar der Begrenzungskonstante aus der Liste der Profildefinitionen entspricht.
Als NB haben wir die Bezugstemperatur der Profildefinition auf 18°C mit Begrenzungskonstante 0 definiert. Unsere Profilscharen liefern daher die TMZ für -17°C bis 17°C (35 LIN-Segmente der MSCONS PI 13011), da bei 18°C kein Bezug mehr erwartet wird.
Aus der beschriebenen EBD Prüfung ergibt sich seitens eines Lieferanten die Reklamation, dass unsere niedrigste TMZ nicht der Begrenzungskonstante entspricht, da wir keine TMZ für -18°C liefern.
Unserer Ansicht nach ist die Reklamation unberechtigt, da die Begrenzungskonstante die TMZ abgrenzt und keine Daten für -18°C bzw. +18°C mitgeliefert werden.
Die Begrenzungskonstante 0 mit Bezugstemperatur 18 bedeutet aus unserer Sicht, dass die niedrigste TMZ -17°C ist.
Derivativ bedeutet das für die Profilscharen 35 LIN-Segmente.
Ist die Reklamation und Ablehnung der Profilscharen mit E_0100:A05 des Lieferanten berechtigt?
|
2023-07-20 10:12:42 |
Sehr geehrter Marktteilnehmer,
ja, die Reklamation ist gerechtfertigt. Wenn die niedrigste Temperatur bei Ihnen 18 °C ist, bei der keine Energie zum Heizen mehr benötigt wird (Bezugstemperatur), muss dies auch im Profil mitgegeben werden. Es muss dann eine Profilschar (Spalte) geben mit 18 °C, TMZ = 0 und in den ¼ h allen Werten „0“ angegeben werden. Das bedeutet, dass bei einer T,mä ≥ 18 °C keine Energie bilanziert wird. Freundliche Grüße
Ihr BDEW-Forum Datenformate |
Ja
|
Matthias Braun |
Vanessa Stemplowsky |
Vanessa Stemplowsky |
Arthur Janczak |
7.8.1 E_0100 Profile bzw. Profilscharen prüfen
Nr.6:
Entspricht die niedrigste Temperaturmaßzahl der Profilschar
der Begrenzungskonstante aus der Liste der
Profildefinitionen? |
Nein
|
In PG besprochen und bilateral beantwortet
-------------Vanessa Stemplowsky-------------24.08.2023 09:03
Veröffentlichung aufgrund Marktanfrage - besprochen mit Matthias Braun und Clara Schubert
-------------Vanessa Stemplowsky-------------12.10.2023 11:06
|
Nein
|
Nein
|
|
Entscheidungsbaum-Diagramme und Codelisten 3.3
|
Abgeschlossen
|
Wie genau muss die Rundungen im Rahmen der gleitenden Nachberechnung erfolgen?
|
Es dürfen keine Rundungsdifferenzen auftreten. |
20.06.2023
|
2023-01802 |
|
|
Rundungen im Rahmen der gleitenden Nachberechnung
Hallo,
es gibt Netzbetreiber, die fassen bei der gleitenden Nachberechnung die zu korrigierenden Zeiträume zusammen. Damit einhergehend natürlich auch die Mengen. Die Ermittlung des Nettobetrages für unsere EBD-Prüfung ist dementsprechend Mengensumme * Preis = Nettobetrag. Der Netzbetreiber allerdings berechnet die einzelnen Monate und summiert dann die errechneten Nettobeträge. Dies führt dann bei den EBD-Prüfungen zu Ablehnungen.
Ist die Methodik des Netzbetreibers korrekt?
Vielen Dank.
|
2023-06-20 09:41:24 |
Sehr geehrter Marktteilnehmer,
in dem INVOIC/REMADV AHB befindet sich folgende Aussage:
"Als Grundsatz gilt: Jede Zeitscheibe wird bei der Rücknahme in der ursprünglichen Form zurückgenommen."
Die Rücknahmeposition muss exakt das zurücknehmen, was bisher abgrechnet wurde. Abweichungen zwischen Rücknahmeposition und den bisher in Rechnung gestellten Rechnungspositionen sind abzulehnen.
Freundliche Grüße,Ihr BDEW-Forum Datenformate |
Ja
|
Matthias Braun |
Vanessa Stemplowsky |
Clara Schubert-Gladen |
Michael Fuhrer |
|
Nein
|
Kleingruppe Antwortvorschlag
-------------Thomas Seipt-------------18.08.2023 09:11
In PG besprochen
-------------Clara Schubert-Gladen-------------23.08.2023 13:22
|
Nein
|
Nein
|
|
Entscheidungsbaum-Diagramme und Codelisten 3.3
|
Abgeschlossen
|
Welche Artikel-ID gelten bei einem unterjährigen Lieferantenwechsel?
|
Es gelten die Artikel-ID aus der Anmeldebestätigung bzw. Stammdatenänderung ab dem 01.01. des laufenden Kalenderjahres. |
26.05.2023
|
2023-01768 |
|
|
Sehr geehrte Damen und Herren,
wir haben eine Frage zur Prüfung von Monatsrechnungen im Zusammenhang mit Lieferantenwechseln.
Bei einem unterjährigen Lieferantenwechsel (bspw. zum 01.02.2023) liegen dem neuen LF nur die Artikel-ID's vor, die in der Antwort auf Anm. NN mitgeteilt werden. Diese gelten somit auch erst ab Lieferbeginn (01.02.2023).
Wenn nun die erste Monatsrechnung (MVR) für bspw. 02/2023 kommt und dort auch eine Gegenrechnung der Vormonate erfolgt, so können die Avispositionen für 01/2023 nicht lt. EBD geprüft werden, weil für 01/2023 noch keine Artikel-ID's bekannt sind. Es gibt auch m.W. keine Möglichkeit seitens des NB, die Artikel-ID's rückwirkend für Zeiträume vor Lieferbeginn mitzuteilen.
Gründe für diesen Fall können sein:
- KA-Wechsel von TA auf SA
- Rückrechnung wegen Jahresleistung
- Abrechnung von bereits entfallenen Umlagen seitens des Netzbetreibers
Wie ist hier die Vorgehensweise angedacht oder übersehen wir etwas?
Vielen Dank für Ihre Mühe.
Mit freundlichen Grüßen
Sebastian Weiße
|
2023-05-26 13:40:51 |
Sehr geehrter Marktteilnehmer,
bei einem unterjährigen Lieferantenwechsel gelten die Artikel-ID aus der Anmeldebestätigung bzw. Stammdatenänderung ab dem 01.01. des laufenden Kalenderjahres und sind für die Prüfung der Rechnungspositionen der Netznutzungsabrechnung ebenfalls für Zeiträume vor dem Lieferantenwechsel heranzuziehen.
In dem EBD E_0406 und E_0407 werden die Prüfschritte 400 und 600 mit einem entsprechendem Hinweis in dem Dokument "Entscheidungsbaum-Diagramme und Codelisten für die Antwortnachrichten, Version 3.5" ergänzt.
Mit freundlichen Grüßen
Ihr BDEW-Forum Datenformate |
Ja
|
Matthias Braun |
Vanessa Stemplowsky |
Clara Schubert-Gladen |
Sebastian Weiße |
|
Nein
|
Veröffentlichung
-------------Clara Schubert-Gladen-------------19.09.2023 14:26
|
Nein
|
Nein
|
|
Entscheidungsbaum-Diagramme und Codelisten 3.3
|
Abgeschlossen
|
Anwendungshilfe MaKo2020: Verständnis der Resultierenden in Variante 1 der NN-Rechnung
|
Die EDI@Energy Anwendungshilfe zu den Datenformaten der Marktkommunikation 2020 hat keine Gültigkeit mehr. |
12.05.2023
|
2023-01758 |
|
|
In der Anwendungshilfe zum Lieferschein der MaKo2020
https://www.edi-energy.de/index.php?id=38&tx_bdew_bdew%5Buid%5D=981&tx_bdew_bdew%5Baction%5D=download&tx_bdew_bdew%5Bcontroller%5D=Dokument&cHash=17c4f07399e91e9015417ef3ea0a088a
gibt es folgende Passagen:
- Kapitel 5.4.4
"Somit enthält der Lieferschein, auf den die zu prüfende NN-Rechnung referenziert, nie Energiemengen zu Rücknahmepositionen"
- Kapitel 5.5.2.1 Variante 1
"In der monatlichen vorläufigen NN-Rechnung wird die Arbeit der abgelaufenen Monate in Rechnung gestellt. Die Arbeit wird mit dem aktuellen Arbeitspreis in Abhängigkeit von den Benutzungsstunden (die auf Basis der Arbeit der abgelaufenen Monate und des bisher aufgetretenen Jahresleistungsmaximums) berechnet. Ebenfalls fließt das bisher aufgetretene Jahresleistungsmaximum in die Berechnung für die abgelaufenen Monate mit ein. Dabei werden die bereits berechneten Positionen der direkt vorhergehenden Rechnung verrechnet.
Der Lieferschein beinhaltet die Arbeit der abgelaufenen Monate, welche auf der Rechnung ausgewiesen wird, und das in den abgelaufenen Monaten bisher aufgetretene Jahresleistungsmaximum."
Wir gehen davon aus, dass es weiterhin erlaubt ist die Variante 1 in der NN-Rechnung anzuwenden.
Die Resultierende ist nach unserem Verständnis die Verrechnung der abgelaufenen Monate und der Rücknahmepositionen, sodass in Summe nur der aktuelle Monat übrig bleibt.
Die Prüfschritte 475 (für MVR) und 660 (für 13I) im EBD E_0406 lauten:
"Entsprechen die einzelnen Positionen der Mengen des Lieferscheins dem Absolutbetrag der Menge der Resultierenden der Rechnung?"
Bei nein muss laut EBD mit A45 abgelehnt werden.
Daraus ergeben sich unsere Fragen:
1. Ist unser Verständnis der Resultierenden auch mit Variante 1 korrekt?
2. Wie können dann aber die oben genannten Prüfschritte positiv geprüft werden?
|
2023-05-12 09:44:27 |
Sehr geehrter Marktteilnehmer,
die EDI@Energy Anwendungshilfe zu den Datenformaten der Marktkommunikation 2020 hat keine Gültigkeit mehr. Gemäß GPKE muss der Lieferschein die Abrechnungsenergiemengen des Rechnungszeitraums der Netznutzungsrechnung und, falls erforderlich, alle notwendigen Leistungswerte enthalten. Zudem müssen die angegebenen Abrechnungsenergiemengen der Netznutzungsrechnung in ihrer Höhe und über den Zeitraum mit den vorher auf Ebene der Marktlokation vom NB im Lieferschein übermittelten Abrechnungsenergiemengen übereinstimmen.
Mit freundlichen GrüßenIhr BDEW-Forum Datenformate |
Ja
|
Matthias Braun |
Vanessa Stemplowsky |
Vanessa Stemplowsky |
Daniel Beckers |
|
Nein
|
In PG besprochen, Vorschlag erstellt. Prüfung der PG und anschließende Veröffentlichung
-------------Vanessa Stemplowsky-------------23.05.2023 09:49
Veröffentlicht
-------------Vanessa Stemplowsky-------------23.08.2023 12:12
|
Nein
|
Nein
|
|
UTILMD AHB Strom 1.1
|
Abgeschlossen
|
Umgang mit Segmenten / Segmentgruppen in einer Segmentgruppe
|
Segmente / Segmentgruppen innerhalb einer Segmentgruppe können nur angegeben werden, wenn die darüberliegende Segmentgruppe eröffnet wurde |
27.07.2023
|
2023-01854 |
|
|
Hallo,
wir können eine Kündigung, Identlogik Z12, nicht identifizieren und lehnen mit A12 ab.
Laut AHB ist bei diesem Antwortgrund kein LOC+Malo zu versenden. Das SEQ+Z01 muss aber auch nicht eröffnet werden, wenn LOC+Malo nicht vorhanden ist, Bedingung 2061 und 25.
Allerdings ist die Lieferrichtung ein generelles MUSS ohne Einschränkung. Dazu benötigt man aber das SEQ+Z01.
Können Sie die bitte prüfen und erklären, da der "Fehler" in der aktuellen, aber eben auch in der neuen Version des AHB zu finden ist.
|
2023-07-27 16:10:08 |
Sehr geehrter Marktteilnehmer,
Wir befinden uns in dem Anwendungsfall 55018 Ablehnung Kündigung.
Die Segmentgruppe SG10 CCI+Z30 "Lieferrichtung" ist auf Ebene der Segmentgruppe und des Segemntes mit dem Operator "Muss" definiert. Wenn die darüberliegende Segementgruppe, welches in diesem Fall die SG8 SEQ+Z01 "Daten der Marktlokation" ist, eröffnet wurde, dann müssen alle in der Segmentgruppe angegebenen Segmente / Segmentgruppen gemäß ihres Operators betrachtet werden. Somit ist das Segement SG10 CCI+Z30 "Lieferrichtung" nur anzugeben, wenn auch die darüberliegede Segmentgruppe eröffnet wurde.
Die darüber liegende Segmentgruppe SG8 SEQ+Z01 wurde jedoch nicht eröffnet, da die an diesem Segment beschreibenen Voraussetzungen nicht vorlagen. Diese Segmentgruppe ist mit den Voraussetzung "Muss [2061] ∧ [25]" beschrieben. (∧ steht für "und")Die dort enthaltene Voraussetzung [25] "Wenn SG5 LOC+Z16 (Markltlokation)" vorhanden trifft in diesem Fall nicht zu, da das Segement "SG5 LOC+Z16 (Marktlokation)" bei der Verwendung des Codes A12 im "SG4 STS+E01 (Status der Antwort)" nicht anzugeben ist.
Es handelt sich somit um keinen Fehler. Wir hoffen Ihnen hiermit den Zusammenhang erläutert zu haben.
Ihre PG EDI@Energy
|
Ja
|
Holger Weickenmeier |
Sara Olszewski |
Holger Weickenmeier |
Stefan Losert |
UTILMD Anwendungshandbuch Strom Seite 458, 459 |
Nein
|
-------------Holger Weickenmeier-------------27.07.2023 17:17
|
Nein
|
Nein
|
|
Regelungen zum Übertragungsweg für AS4 2.0
|
Eingegangen
|
Sender VERPFLICHTET im ClientHello des TLS-Handshakes die SNI-Extension mitzuschicken?
|
SNI muss verwendet werden |
10.07.2023
|
2023-01826 |
|
|
In den "Regelungen zum Übertragungsweg für AS4 V2.0" (3.) steht folgendes zur Verwendung von SNI bei TLS:
"Für den Aufbau der TLS-Verbindung ist die Erweiterung Server Name Identification (SNI) gemäß IETF RFC 6060 bzw. IETF RFC 8449 zu unterstützen."
(Hinweis 1: Ist statt RFC 6060 evtl. RFC 6066 gemeint?)
(Hinweis 2: Bei TLS 1.3 ist SNI IMMER Pflicht)
Wir interpretieren das so, dass ein Sender VERPFLICHTET ist im ClientHello des TLS-Handshakes die SNI-Extension mitzuschicken. Ist das der Fall?
Wir empfehlen *dringendst*, dass SNI weiterhin Pflicht ist.
Wir bitten um klarstellende Formulierung im Dokument.
|
2023-07-10 11:49:15 |
Sehr geehrter Marktteilnehmer,
SNI muss auch bei Verwendung von TS 1.2 verwendet werden.
Dieses ist in der Konsolidierten Lesefassung mit Fehlerkorrekturen Stand: 28.07.2023 auch enthalten.
Mit freundlichem Gruß
Ihr BDEW-Forum Datenformate |
Ja
|
Rene Hoffmann |
Sven Schillack |
Dirk Katzenbach |
Thomas Beckers |
"Regelungen zum Übertragungsweg für AS4 V2.0" (Kapitel 3.) |
Nein
|
|
Nein
|
Nein
|
|
Regelungen zum Übertragungsweg für AS4 2.0
|
Eingegangen
|
Feld "BDEWDocumentDate" für Marktprozesse
|
Das Feld BDEWDocumentDate muss in der Kommunikation bei den Marktprozessen befüllt sein. |
09.07.2023
|
2023-01823 |
|
|
Gemäß "Regelungen zum Übertragungsweg für AS4 2.0 Konsolidierte Lesefassung mit Fehlerkorrekturen Stand: 12.05.2023" im Abschnitt "6 Regelungen für den Austausch von Metainformationen" sind für den Austausch von Übertragungsdateien für Marktprozesse innerhalb des Elements „PartProperties“ die Felder "BDEWDocumentType" und "BDEWDocumentNo" zu verwenden, während die Felder "BDEWFulfillmentDate", "BDEWSubjectPartyID" und "BDEWSubjectPartyRole" keine Verwendung finden.
Laut "AS4-Profil 1.0 Konsolidierte Lesefassung mit Fehlerkorrekturen Stand: 12.05.2023" in Abschnitt "2.3.5 Payload Data-Profil" gibt es jedoch ebenfalls das Feld "BDEWDocumentDate", welches in der obigen Auflistung bzw. genanntem Dokument nicht enthalten ist und auch im Dokument "Regelungen zum sicheren Austausch im Fahrplanprozess" Version 2.0 der AG FPM keine Erwähnung findet.
Wie ist mit dem Feld "BDEWDocumentDate" beim Austausch von Übertragungsdateien für Marktprozesse umzugehen?
|
2023-07-09 01:47:40 |
Sehr geehrter Marktteilnehmer,
Das Feld BDEWDocumentDate muss in der Kommunikation bei den Marktprozessen mit dem Datumstempel bei Erzeugung im Format YYYY-MM-DD befüllt sein.
Dieses ist in der Konsolidierten Lesefassung mit Fehlerkorrekturen Stand: 28.07.2023 auch enthalten.
Mit freundlichem Gruß
Ihr BDEW-Forum Datenformate |
Ja
|
Rene Hoffmann |
Rene Hoffmann |
Rene Hoffmann |
Tobias Laube |
|
Nein
|
|
Nein
|
Nein
|
|
Regelungen zum Übertragungsweg für AS4 2.0
|
Eingegangen
|
Eine juristische Person kann mehrere Marktrollen einnehmen...
|
Die interne Kommunikation ist nicht durch die RzÜ geregelt |
08.02.2023
|
2023-01651 |
|
|
Eine juristische Person kann mehrere Marktrollen einnehmen und erhält für jede Rolle eine eigene MP-ID. Zum Beispiel kann ein Unternehmen die Rollen:
- Netzbetreiber
- Messtellenbetreiber
- Lieferant
einnehmen.
a) Strikt genommen müsste dann die interne Kommunikation innerhalb eines Unternehmens dann über die externe AS4 Schnittstelle geroutet werden, oder
b) ist die AS4 Übertragung ausschließlich bei der Kommunikation über öffentliche Netzte anzuwenden, und darf nichtöffentliche Kommunikation auch ohne die Nutzung von AS4 erfolgen (in der Regel innerhalb desselben Unternehmensverbundes).
|
2023-02-08 11:36:21 |
Sehr geehrter Marktteilnehmer,
Die interne Kommunikation ist weder für die aktuelle Kommunikation, noch die zukünftige Kommunikation durch durch die RzÜ 1.x bzw. RzÜ 2.x geregelt.
Mit freundlichem Gruß
Ihr BDEW-Forum Datenformate |
Ja
|
Rene Hoffmann |
Sven Schillack |
Rene Hoffmann |
Tim Koehler |
4 Kommunikationsregeln
Zwischen zwei unterschiedlichen MP-ID ist genau ein Übertragungsweg mit genau einem
Endpunkt zulässig.
Die Grundidee der 1:1-Kommunikation ist, dass ein Marktpartner dafür zu sorgen hat, dass
seine internen Organisationsstrukturen bei den anderen Marktpartnern keinen Zusatzaufwand
im Rahmen der Übermittlung der Übertragungsdateien generieren.
Jeder AS4-Endpunkt muss jederzeit ohne Firewall-Freischaltung erreichbar sein. |
Nein
|
|
Nein
|
Nein
|
|
Regelungen zum Übertragungsweg für AS4 2.0
|
Abgeschlossen
|
Wann aktualisierte CP öffentlich verfügbar.
|
Veröffentlichung ist zwischenzeitlich erfolgt |
06.02.2023
|
2023-01650 |
|
|
Im Dokument wird unter Punkt 5 angegeben das Zertifikate aus der SM-PKI verwendet werden müssen. Bisher (Stand Februar 2023) gibt es keine Möglichkeit solche Zertifikate bei einer SM Sub-CA zu beziehen, da diese Verwendungszweck/Marktrolle "Marktkommunikation" in der entsprechenden Certificate Policy (CP) noch nicht definiert ist. Gibt es einen Zeitplan bis wann das BSI die entsprechende CP anpasst ? Wird die Anpassung rechtzeitig vor dem 01.10.2023 erfolgen? Gibt es ein Ausweichszenario falls diese Änderung nicht rechtzeitig erfolgen kann?
|
2023-02-06 17:51:35 |
Für die Veröffentlichung der neuen Version der CP der SM-PKI steht das BSI in der Verantwortung. Wir können Sie daher nur Bitten sich mit dieser Frage an das BSI oder BNetzA zu wenden. Es gilt nach wie vor der von der BNetzA festgelegter Zeitplan.
Update: Seit dem 03. März 2023 steht die neue Version der CP zum öffentlichen Download bereit. |
Ja
|
Rene Hoffmann |
Sven Schillack |
Rene Hoffmann |
Fabian Lorenz |
5 Zertifikate und PKI
Die Kommunikation wird durch Verwendung der Smart Metering PKI (SM-PKI) des BSI abgesichert. Die Vorgaben der Certificate Policy (CP) der SM-PKI müssen eingehalten werden.
5.1 Vertrauensdiensteanbieter
Die Vertrauensdiensteanbieter müssen eine Sub-CA-Instanz im Sinne der CP der SM-PKI sein. |
Nein
|
|
Nein
|
Nein
|
|
ActivationDocument FB 1.1a
|
Abgeschlossen
|
Ist das Feld "ResourceProvider" korrekt angegeben?
|
Bei der Prüfung sind keine Fehler in der AWT aufgefallen. Die FB wird in der nächsten Version konkretisiert. |
27.06.2023
|
2023-01806 |
|
|
Sehr geehrte Damen und Herren.
ist die beschriebene Abhängigkeit beim Feld "ResourceProvider" korrekt angegeben?
In vielen Prozessschritten wäre die Befüllung entsprechend des AWTs nicht korrekt, bzw. eine Prüfung der FB-Abhängigkeit würde hier fehlschlagen.
Beispielsweise: Abruf im Aufforderungsfall mit Delta-/Sollwertanweisung, Prozessschritt 1. Hier ist die MarktpartnerID vom Einsatzverantwortlichen anzugeben, die Nachricht wird aber vom anweisenden Netzbetreiber gesendet.
|
2023-06-27 11:18:44 |
Sehr geehrter Fragesteller,
wir haben Ihren Hinweis tiefer geprüft. Dabei sind uns keine unkorrekten Angaben in der AWT aufgefallen. Die Abhängigkeiten in der FB werden wir im Laufe der nächsten Konsultation konkretisieren.
Das Feld "ResourceProvider" ist mit der jew. Marktpartner-ID des Marktpartners zu füllen, der für die Ressource zuständig ist. Bei der SR ist es bspw. der Einsatzveranwortliche; bei der CR und SG der Netzbetreiber. Die Informationen über die Sende-/Empfangspartner liegen eine Ebene höher im Dokument und werden über die Felder "SenderIdentification" und "ReceiverIdentification" angegeben. Bei einer Weiterleitung wird der ursprüngliche Sender über das Feld "OriginalSenderIdentification" angegeben. Entsprechend der zitierten Einschränkung aus der Formatbeschreibung zum Feld "ResourceProvider" ist dies in Abhängigkeit des jew. Senders korrekt.
Freundliche Grüße,
Ihr Forum Datenformate |
Ja
|
Johannes Umbach |
Henrike Janissen |
Johannes Umbach |
Jan-André Meyer |
Seite 8:
Abhängigkeit
Die hier angegebene MP-ID muss mit der Angabe im
Element SenderIdentification übereinstimmen, sofern der
Sender nicht der Data Provider ist. Ist der Sender der
Data Provider, so muss die hier angegebene MP-ID mit
der Angabe im Element OriginalSenderIdentification
übereinstimmen.
|
Nein
|
zur Abstimmung in PG
-------------Johannes Umbach-------------21.08.2023 09:20
PG OK, veröffentlicht
-------------Vanessa Stemplowsky-------------28.09.2023 15:29
|
Nein
|
Nein
|
|
INVOIC / REMADV AHB 2.5b
|
Abgeschlossen
|
Wie werden Tagespreise ab dem 1.1.24 für MSB-Rechnungen übertragen?
|
Fehler wird in Lesefassung am 20.7.23 korrigiert |
26.06.2023
|
2023-01805 |
|
|
Hallo,
gemäß den AHB zur MSB-Rechnung 31009 ist im Segment SG29 PRI zum Qualifier CAL im Datenelement 6411 nur die Angabe des Qualifiers ANN erlaubt. Mit Einführung der Artikel-IDs in der MSB-Abrechnung und damit einhergehenden Tagespreisen müsste doch an dieser für Zeiträume ab dem 01.01.2024 die Angabe des Qualifiers "DAY" zulässig sein?
Mit freundlichen Grüßen
|
2023-06-26 13:51:01 |
Sehr geehrter Fragesteller,
der von Ihnen erkannte Fehler ist bereits in Arbeit und wird mit der nächsten Lesefassung am 20.7.23 behoben.
Viele Grüße,
Ihr BDEW-Forum Datenformate |
Ja
|
Klaus Keller |
Stefan Seidel |
Klaus Keller |
Michael Nawrath |
|
Nein
|
Antwortvorschlag erstellt
-------------Klaus Keller-------------29.06.2023 11:01
Veröffentlichung gemäß Abstimmung in PG R/Z und edi@energy vom 4.7.23
-------------Klaus Keller-------------05.07.2023 13:22
|
Nein
|
Nein
|
|
INVOIC MIG 2.8a
|
Abgeschlossen
|
Welche Artikel-ID müssen per UTILMD für die INVOIC ausgetauscht werden?
|
Es dürfen nur die Artikel-ID per UTILMD ausgetauscht werden, wenn diese in der INVOIC folgen. |
19.06.2023
|
2023-01800 |
|
|
In der Stammdatenänderung zum 01.01.2023 haben wir alle Artikelnummern, welche für den Lieferanten abrechnungsrelevant sein könnten, übermittelt. Diese Artikelnummern werden auch im Abrechnungsbeleg mit aufgeführt, sind in der Rechnung und im INVOIC aber nicht enthalten. Im INVOIC sind nur die wirklich abrechnungsrelevanten Artikel-ID enthalten.
Für uns ist es nun wichtig zu klären, ob nur die Artikelnummern in der Stammdatenänderung übermittelt werden dürfen, welche auch abrechnungsrelevant sind, oder ob alle Artikelnummern übermittelt werden müssen, für welche die Abrechnung möglich wäre.
Entega und andere Lieferanten reklamieren wie folgt: Sie dürfen die Artikel-ID nicht per UTILMD austauschen, wenn Sie diese nicht in der INVOIC aufführen.
|
2023-06-19 13:11:50 |
Sehr geehrte Fragestellerin,
in der UTILMD sind nur die Artikel-ID bzw. Gruppenartikel-ID zu nennen, die auch zur Abrechnung kommen. Die dahinter liegende Idee ist, dass der Lieferant durch Nennung dieser Codes weiß, welche Netznutzungskosten an der Marktlokation für ihn zu erwarten sind. Somit ist die Erwartungshaltung Ihrer Marktpartner korrekt.
Freundliche Grüße,
Ihr BDEW-Forum Datenformate |
Ja
|
Klaus Keller |
Stefan Seidel |
Stefan Seidel |
Kerstin Köppe |
|
Nein
|
Antwortvorschlag erstellt und an Herrn Seidel zur Prüfung übergeben
-------------Klaus Keller-------------21.06.2023 16:35
In PG besprochen
-------------Vanessa Stemplowsky-------------04.07.2023 09:11
|
Nein
|
Nein
|
|
INVOIC MIG 2.8a
|
Abgeschlossen
|
Ist eine Fälligkeitsüberschreitung bei Rechnungsbetrag ≥ 0 erlaubt?
|
Fälligkeitsüberschreitung bei Rechnungsbetrag ≥ 0 ist erlaubt. |
09.03.2023
|
2023-01677 |
|
|
Berechnung der Fälligkeitsfrist (Beispiel Überschreitung)
Sehr geehrte Damen und Herren,
wir haben massive Probleme bei der Ablehnung durch Fälligkeitsüberschreitung. Die Netzbetreiber akzeptieren unsere Ablehnungen nicht und unser Softwareanbieter sieht keinerlei Handlungsbedarf, da aus ihrer Sicht die Berechnung korrekt erfolgt.
Beispiel wäre
'DTM+137;202301292300
'DTM+265;202302132300
Behauptung vom Netzbetreiber. Angabe Rechnungsdatum ist UTC und hier müsste aktuell eine 1 h raufgerechnet werden. Dann wären wir beim 30.01.2023 Eingang, Fristberechnung ab 31.0.01.2023 = 10 Werktage, bis Fälligkeit 13.02.2023.
Unser System lehnt wie folgt ab. "Das Zahlungsziel ist überschritten (Fällig 14.02.2023-Eingang 30.01.2023 = 11 volle Werktage)."
Wie ist hier in diesem konkreten Beispiel die richtige Berechnung? Zusatzfrage: müssen Wochenenden und Feiertage auch beim Rechnungseingang berücksichtigt werden? Oder nur bei der Berechnung der Frist?
Vielen Dank
|
2023-03-09 08:39:47 |
Sehr geehrter Fragesteller,
gemäß dem EBD E_0406 und E_0407 darf bei einem fälligen Betrag ≥ 0 die Fälligkeit von 10 WT überschritten werden. Nur bei einem fälligen Betrag < 0 darf die Fälligkeit von 10 WT nicht überschritten werden.
Freundliche Grüße,
Ihr BDEW-Forum Datenformate |
Ja
|
Klaus Keller |
Stefan Seidel |
Klaus Keller |
Ninette Knobbe |
|
Nein
|
-------------Klaus Keller-------------09.03.2023 09:28
Antwortvorschlag zur Diskussion in AG R/Z erstellt
|
Nein
|
Nein
|
|
ActivationDocument AWT 1.1
|
Abgeschlossen
|
Wie ist mit Abrufen zu verfahren, bei denen ein Abrufzeitraum (Pos) in der Vergangenheit liegt oder die laufende Viertelstunde betrifft?
|
Für den Abruf sind die zeitlichen Vorgaben aus den Prozessen zu berücksichtigen. Im Activation Document sind jedoch alle Zeitrschritte eines Tages enthalten. |
15.06.2023
|
2023-01798 |
|
|
Laut dem Dokument "NKK-Detailprozesse_Version_2.2" gibt es bei RD 2.0 Abrufen eine Frist von BIS 15min vor Erfüllungszeitraum. ( Punkt 5.1.2 )
In einem Produktivtest mit unserem vorgelagerten Netzbetreiber, hat dieser uns ein Abrufdokument zugesendet bei dem folgende Unstimmigkeit Aufgetreten ist:
Der CreationTimeStamp lag bei 08:34Z mit dem ersten Abrufzeitfenster 8:30Z.
- Dieses Abrufdokument hätte laut unserer Interpretation von Connect+ abgelehnt werden müssen.
Wie ist mit Abrufen zu verfahren, bei denen ein Abrufzeitraum (Pos) in der Vergangeheit liegt, oder die laufende Viertelstunde betrifft?
|
2023-06-15 13:15:02 |
Sehr geehrter Fragesteller,
Abrufe sind mit dem ActivationDocument mit einem ausreichendem Vorlauf gem. der prozessualen Vorgaben zu senden.
Generell ist jedoch im ActivationDocument zu beachten, dass die Nachricht alle Zeitschritte eines Tages enthält, auch wenn diese bereits in der Vergangenheit liegen.
Freundliche Grüße,
Ihr Forum Datenformate |
Ja
|
Johannes Umbach |
Henrike Janissen |
Johannes Umbach |
Kai Stredder |
Laut dem Dokument "NKK-Detailprozesse_Version_2.2" gibt es bei RD 2.0 Abrufen eine Frist von BIS 15min vor Erfüllungszeitraum. ( Punkt 5.1.2 ) |
Nein
|
Zur Abstimmung in PG vorbereitet
-------------Johannes Umbach-------------16.08.2023 09:11
PG ok, veröffentlicht.
-------------Vanessa Stemplowsky-------------28.09.2023 15:25
|
Nein
|
Nein
|
|
ActivationDocument AWT 1.1
|
Abgeschlossen
|
Besteht ein Widerspruch der Bemerkung in der Fussnote bzgl. der MeasureUnit mit den Prozessvorgaben?
|
Die in der AWT angegebenen MeasureUnit sind korrekt. |
13.03.2023
|
2023-01679 |
|
|
In der Fußnote 2 ist ausgewiesen, dass bei der Deltaanweisung beide MeasureUnits (MAW und P1) möglich sind.
Das steht im Widerspruch mit dem Kapitel "GESAMTÜBERSICHT BENÖTIGTE DATENPUNKTE NACH USE-CASES" Use-Case 5.1 bis Use-Case 5.3 im "Detailprozesse für die Netzbetreiberkoordination im Redispatch 2.0"
(z.B.: https://www.bdew.de/media/documents/RD_2.0_NKK-Detailprozesse_Version_2.1_Implementierung_zum_01.04.2023.pdf)
Im ActivationDocument mit DocumentType A96 Redispatch activation document (ACO) für den UseCase 5.1 ist für Sollwertanweisung nur die MeasureUnit P1 und für Deltaanweisung nur die MeasureUnits MAW zu verwenden.
Für ActivationDocument mit DocumentType A41 Activation response (ACR) gilt folgende Aussage aus "Detailprozesse für die Netzbetreiberkoordination im Redispatch 2.0":
"Der umsetzbare Anteil der Anforderung (IPU) ist in der ACR stets in der Einheit der ACO anzugeben. Dabei sind die Konventionen von Sollwert- und Deltaanforderung zu berücksichtigen. "
In den Use-Case 5.2 (A96 für CR) und Use-Case 5.3. (DocumentType A42 Tender reduction (AAR)) wird ausschließlich die Deltaanweisung mit MeasureUnits MAW verwenden.
|
2023-03-13 10:23:25 |
Sehr geehrter Fragesteller,
die von Ihnen angemerkte Fußnote [2] bezieht sich allein auf den Use-Case "Abruf im Aufforderungsfall mit Delta-/Sollwertanweisung", der aus der Festlegung BK6-20-059 der Bundesnetzagentur. Die von Ihnen weiter aufgezählten Prozesse entstammen der NKK-Detailprozesse. Die Vorgaben in der AWT zu den NKK-Prozessspalten hinsichtlich der Abrufe enthalten keinen Verweis auf Fußnote [2] in dem Element MeasureUnit.
Freundliche Grüße,
Ihr BDEW-Forum Datenformate
|
Ja
|
Johannes Umbach |
Henrike Janissen |
Johannes Umbach |
Frank Salm |
[2]
Bei der Sollwertanweisung ist nur die MeasureUnit P1 zu
verwenden; bei der Deltaanweisung sind beide MeasureUnits
MAW und P1 möglich. |
Nein
|
Frage beanwortet, zur Abstimmung in PG
-------------Johannes Umbach-------------17.04.2023 13:34
in PG besprochen
-------------Katia Schubert-------------12.05.2023 13:53
|
Nein
|
Nein
|
|
ActivationDocument AWT 1.1
|
Zur Abstimmung in PG
|
Wie kann der Widerspruch hinsichtlich der Benutzung "SendersDocumentIdentification" und "SendersDocumentVersion" in Abhänigkeit des Status umgegangen werden?
|
Die Elemente sind gemäß AWT zu verwenden. |
15.11.2022
|
2022-01565 |
|
|
Auf Seite 7 des Dokuments "ActivationDocument AWT 1.1" steht bei "SendersDocumentIdentification" und "SendersDocumentVersion" jeweils ein x [4] trotz Status = A07. Dies widerspricht den Aussagen in "ActivationDocument FB 1.1" auf Seite 10, dass "SendersDocumentIdentification" und "SendersDocumentVersion" nur mit Status A10 zu benutzen sind.
Wie ist dieser Widerspruch aufzulösen?
|
2022-11-15 18:11:01 |
Sehr geehrter Fragesteller,die in der Anwendungstabelle notierte Verwendung ist korrekt. Den Widerspruch zur Formatbeschreibung werden wir in der nächsten zu konsultierenden Version auflösen.Freundliche GrüßeIhr Forum Datenformate |
Ja
|
Johannes Umbach |
Henrike Janissen |
Johannes Umbach |
Raphael Kaiser |
ActivationDocument AWT 1.1, Seite 7
ActivationDocument FB 1.1, Seite 10
|
Nein
|
-------------Johannes Umbach-------------13.12.2022 16:03
Antwort erstellt
in PG besprochen und für Konsultation 02.2023 berücksichtigt.
-------------Katia Schubert-------------25.01.2023 15:41
|
Ja
|
Nein
|
|
INVOIC / REMADV AHB 2.5a
|
Abgeschlossen
|
Kann Änderungs-ID 23687 aus AHB 2.5b auch bereits für 2.5a angewendet werden ?
|
Nein, es gelten immer nur die Bedingungen des aktuellen AHB für den aktuell gültigen Zeitraum. |
23.05.2023
|
2023-01766 |
|
|
Sehr geehrte Damen und Herren,
wir haben von einem Marktpartner eine SOR INVOICE für einen Leistungszeitraum in 2022 mit Artikelnummern bekommen.
Im Dokument: "INVOIC / REMADV AHB 2.5b" wird mit der Änderungs-ID: 23687 die Verwendung der Positionsdaten dahingehend präzessiert, dass "Wenn IMD++SOR vorhanden" nur Artikel-IDs verwendet werden dürfen und somit eine SOR erst ab Leistungszeiträumen ab 01.01.2023 verwendet werden darf.
Im Dokument: "INVOIC / REMADV AHB 2.5a" ist das leider nicht zu finden und bietet aus meiner Sicht Raum für die Interpretation, dass auch "IMD++SOR" für Leistungszeiträume <01.01.2023 unter Verwendung der Artikelnummer benutzt werden darf.
Kann ich davon ausgehen, dass die Änderungs-ID: 23687 auch schon auf das Dokument: "INVOIC / REMADV AHB 2.5a" anzuwenden ist?
Vielen Dank!
|
2023-05-23 10:35:43 |
Sehr geehrter Fragesteller,
im AHB 2.5b wurden im PID 31002 (NN-Rechnung) Änderungen präzisiert, die vorraussichtlich in der Lesefassung am 20.07.2023 korrigiert werden.
Prinzipiell gelten immer nur die Bedingungen des aktuellen AHB für den aktuell gültigen Zeitraum.
Freundliche Grüße,
Ihr BDEW-Forum Datenformate |
Ja
|
Klaus Keller |
Stefan Seidel |
Stefan Seidel |
Frank Elz |
|
Nein
|
-------------Klaus Keller-------------25.05.2023 08:40
Vorschlag an Herrn Seidel gesendet zur QS
Besprochen in PG
-------------Vanessa Stemplowsky-------------04.07.2023 09:22
|
Nein
|
Nein
|
|
INVOIC / REMADV AHB 2.5a
|
Abgeschlossen
|
Sollten Rechnungspositionen mit Menge=0 und Betrag=0 übertragen werden im Sinne einer besseren Nachvollziehbarkeit ?
|
Es müssen alle in den Stammdaten ausgetauschten Artikel-ID angegeben werden, auch wenn diesen ein Nullverbrauch im Abrechnungszeitraum zugewiesen wird. |
22.05.2023
|
2023-01765 |
|
|
Sehr geehrtes Forum,
ist im Abrechnungszeitraum > 31.12.2022 eine Mengenabhängige Artikel-ID (z.B. 1-02-0-002) in der INVOIC anzugeben wenn auf Grund eines Nullverbrauchs die Ergebniszeile 0,00 EUR erhält? Oder ist der Netzbetreiber berechtigt die Artikel-ID auf Grund des Nullpreises in der INVOIC zu unterdrücken?
|
2023-05-22 16:10:03 |
Sehr geehrter Fragesteller,
in der INVOIC sind alle Artikel-ID aufzuführen, die im Vorfeld für diese Marktlokation im Rahmen des Stammdatenaustausches ausgetauscht wurden. Das bedeutet, dass auch Artikel-ID, die in einem Abrechnungzeitraum mit einer Menge "0" bewertet werden, in einer Rechnung aufzuführen sind.
Würde eine derartike Artikel-ID nicht in der INVOIC aufgeführt werden, würde die Rechnung über das entsprechende EBD E_0406, Prüfschritt 805 abgelehnt werden.
Viele Grüße,
Ihr BDEW-Forum Datenformate |
Ja
|
Klaus Keller |
Stefan Seidel |
Stefan Seidel |
Michael Günzel |
|
Nein
|
-------------Klaus Keller-------------23.05.2023 09:21
Antwortvorschlag an Herrn Seidel gesendet
-------------Klaus Keller-------------25.05.2023 10:43
Nach Rückmeldung von Herrn Seidel auf Rücksprache in der AG RZ/ umgestellt
In PG besprochen
-------------Vanessa Stemplowsky-------------04.07.2023 09:34
|
Nein
|
Nein
|
|
INVOIC / REMADV AHB 2.5a
|
Abgeschlossen
|
Ist es bei einer Zonung erlaubt, in der INVOIC die Energiemengen aufzuteilen und im Lieferschein die Summe auszuweisen?
|
Ja, es ist nach aktuellen Formaten korrekt. |
22.05.2023
|
2023-01763 |
|
|
Gruppenartikel-ID 1-10-4 bei Aufteilung §19 StromNEV Gruppe A/B
Hallo,
ein Netzbetreiber führt bereits seit der Januar 2023-INVOIC die Aufteilung zwischen Gruppe A und B und den entsprechenden Artikel-IDs 1-10-4-001 und 1-10-4-002 auf. Im Lieferschein ist aber nur die Summe vorhanden.
INVOIC:
1-10-4-001: 84.932 kWh
1-10-4-002: 8.698 kWh
Lieferschein: 93.630 kWh
|
2023-05-22 06:58:35 |
Sehr geehrter Fragesteller,
es kann genauso übermittelt werden wie von Ihnen beschrieben wurde.
Die EBD-Prüfung wurde mit der Fehlerkorrektur vom 29.06.2023 angepasst (Änd-ID: 60400).
Freundliche Grüße,
Ihr BDEW-Forum Datenformate |
Ja
|
Klaus Keller |
Stefan Seidel |
Stefan Seidel |
Michael Fuhrer |
|
Nein
|
Antwortvorschlag mit Thomas erstellt
-------------Klaus Keller-------------26.05.2023 16:21
Tippfehler beseitigt
-------------Stefan Seidel-------------26.05.2023 17:02
Von PG besprochen
-------------Vanessa Stemplowsky-------------04.07.2023 09:49
|
Ja
|
Nein
|
|
INVOIC / REMADV AHB 2.5a
|
Abgeschlossen
|
Dürfen die Energiemengen der Rück- und Vorwärtsposition zusammengefasst werden?
|
Nein, die einzelnen Energiemengen der NN-Rechnung müssen in Höhe und Zeitraum mit den Energiemengen aus dem Lieferschein übereinstimmen. |
20.04.2023
|
2023-01739 |
|
|
Ist es im Falle einer gleitenden Nachberechnung erlaubt die Werte vergangener Monate kollektiv zurückzunehmen und die neuen Werte kollektiv zu berechnen?
In folgender Form
DTM+155:202212312300?+00:303'
DTM+156:202302282300?+00:303'
MOA+203:-100.00'
DTM+155:202212312300?+00:303'
DTM+156:202303312200?+00:303'
MOA+203:150.00'
|
2023-04-20 16:56:19 |
Sehr geehrter Marktteilnehmer,
die von Ihnen angefragte Konstellation in der INVOIC ist nicht zulässig. Im EBD E_0406 steht dazu:
„Energiemengen im Lieferschein
Hinweis gemäß GPKE: Der Lieferschein muss die Abrechnungsenergiemengen des Rechnungszeitraums der Netznutzungsrechnung und falls erforderlich, alle notwendigen Leistungswerte enthalten. Zudem müssen die angegebenen Abrechnungsenergiemengen der Netznutzungsrechnung in ihrer Höhe und über den Zeitraum mit den vorher auf Ebene der Marktlokation vom NB im Lieferschein übermittelten Abrechnungsenergiemengen übereinstimmen.“
Dies bedeutet, dass die Energiemengen aus dem Lieferschein zu den angegeben Energiemengen aus der Netznutzungsrechnung übereinstimmen müssen.
In Ihrem Beispiel wäre das nicht möglich, da sich die Zeiträume in der INVOIC überschneiden:
Rücknahmeposition: 01.01.2023 00:00 Uhr bis 01.03.2023 00:00 Uhr *
Vorwärtsberechnung: 01.01.2023 00:00 Uhr bis 01.04.2023 00:00 Uhr *
Damit müssten sich auch die Zeiträume im Lieferschein überschneiden und das ist bei selber OBIS-Kennzahl nicht zulässig.
Erlaubt wären z.B. folgende Varianten:
von *
bis *
MSCONS: Lieferschein-Position
INVOIC: Rücknahmeposition
INVOIC: Vorwärtsposition
01.01.2023 00:00
01.03.2023 00:00
100.000 kWh
- 100.000 kWh
100.000 kWh
01.03.2023 00:00
01.04.2023 00:00
50.000 kWh
--
50.000 kWh
oder
von *
bis *
MSCONS: Lieferschein-Position
INVOIC: Rücknahmeposition
INVOIC: Vorwärtsposition
01.01.2023 00:00
01.02.2023 00:00
40.000 kWh
- 40.000 kWh
40.000 kWh
01.02.2023 00:00
01.03.2023 00:00
60.000 kWh
- 60.000 kWh
60.000 kWh
01.03.2023 00:00
01.04.2023 00:00
50.000 kWh
--
50.000 kWh
* In den Beispielen sind alle Zeitangaben in gesetzlich deutscher Zeit angegeben.
Freundliche GrüßeIhr Forum Datenformate |
Ja
|
Klaus Keller |
Stefan Seidel |
Vanessa Stemplowsky |
Daniel Beckers |
|
Nein
|
-------------Stefan Seidel-------------25.04.2023 13:15
Am 25.4.2023 an PG EBD gemeldet und dort aufgenommen
-------------Thomas Seipt-------------16.05.2023 17:57
Vorschlag für die EBD-Gruppe erstellt und an Kaja und Matthias gemeldet
PG EBD abgestimmt zur Veröffentlichung und veröffentlicht.
-------------Vanessa Stemplowsky-------------17.05.2023 14:42
|
Nein
|
Nein
|
|
INVOIC / REMADV AHB 2.5a
|
Abgeschlossen
|
Ist die Bedingung [36] im Anwendungsfall 33003 richtig?
|
Die Bedingung war fehlerhaft. |
09.11.2022
|
2022-01549 |
|
|
Sehr geehrtes Forum,
in der REMADV Abweisung Kopf und Summe (PI 33003) steht im Segment SG7 Abweichungsgrund RFF Zugehörige Rechnung als Bedingung „Muss [36] Wenn in dieser SG7 AJT DE4465 = A12/A75/A80“ ohne Einschränkung auf ein EBD.
Diese Nachricht muss nun auch für die Abweisung einer MSB-Rechnung genutzt werden. Hier im EBD E_0210 ist ebenfalls ein Antwortcode A12 (Die Referenz erfolgt nicht auf das jüngste Angebot zu diesem Zeitpunkt.) vorhanden, für den aber keine Rechnungsnummer angegeben werden kann.
In der Bedingung fehlt eine Einschränkung auf das entsprechende EBD analog der Bedingung im Segment SG7 FTX Nähere Erläuterung des Abweichungsgrundes.
Viele Grüße
|
2022-11-09 10:02:30 |
Sehr geehrter Forumsteilnehmer,
Sie haben Recht. Vielen Dank für den Hinweis. Wir haben eine Fehlerkorrektur veröffentlicht.
Mit freundlichen GrüßenIhr Forum Datenformate |
Ja
|
Klaus Keller |
Stefan Seidel |
Klaus Keller |
Anja Meier |
|
Nein
|
Ich denke der Fragende hat Recht. Das würde dann eine Fehlerkorrektur bedeuten. Ich schreibe einen Änderungsantrag.
-------------Thomas Seipt-------------10.11.2022 18:38
|
Nein
|
Nein
|
|
Codeliste der Artikelnummern und Artikel-ID - informatorische Lesefassung 5.3
|
Abgeschlossen
|
Wann ist die Artikel-ID 1-06-0-037 zu nutzen?
|
Die Artikel-ID 1-06-0-037 ist zu nutzen, wenn der Kunde die Kosten für den Telekommunikationsanschluss trägt. |
20.04.2023
|
2023-01737 |
|
|
Guten Tag,
kann die Artikel-ID 1-06-0-037 bei einem Preisabschlag für einen, vom Kunden gestellten Telekommunikationsanschluss verwendet werden?
Vielen Dank im voraus für die Antwort.
|
2023-04-20 10:30:15 |
Sehr geehrter Marktteilnehmer,
bei der Artikel-ID 1-06-0-037 "Messstellenbetrieb bei kME, alle Spannungsebenen. Telekommunikationsanschluss durch AN (Fernauslesung)" wird die Fernauslesung vom AN getragen. Wenn der NB diese Kosten trägt, ist die Artikel-ID 1-06-0-036 "Messstellenbetrieb bei kME, alle Spannungsebenen, Telekommunikationsanschluss durch NB (Fernauslesung)" zu nutzen. Der Preisabschlag bildet die Differenz zwischen den Preisen der Artikel-ID 1-06-0-036 und der Artikel-ID 1-06-0-037.
Mit freundlichem Gruß
Ihr BDEW-Forum Datenformate |
Ja
|
Beate Becker |
Klaus Keller |
Beate Becker |
Andreas Oblasser |
|
Nein
|
|
Nein
|
Nein
|
|
PRICAT AHB 2.0b
|
Abgeschlossen
|
Dürfen Grundpreise unter einer Artikel-ID "zusammengefasst" werden?
|
Im Prinzip ja, wenn nur ein Grundpreis Anwendung findet. |
31.03.2023
|
2023-01715 |
|
|
Hallo Forum-Team,
kann auf die Verwendung und Kommunikation einzelner Artikel-IDs und somit auf die eindeutige Kennzeichnung einer Leistung verzichtet werden, wenn bestimmte Leistungen auch unter einer Artikel-ID "zusammengefasst" werden können, da die Leistungen gleichartig sind und mit demselben Preis berechnet werden?
Kann z.B. auf die Artikel-ID für einen Grundpreis für Speicherheizung (1-02-0-008) verzichtet werden, wenn alle Grundpreis-Leistungen (ohne diese weiter zu detaillieren) über Artikel-ID 1-02-0-001 verwaltet und abgerechnet werden?
Vielen Dank im Voraus!
|
2023-03-31 16:55:36 |
Sehr geehrter Markteilnehmer,
im Prinzip ja, wenn nur ein Grundpreis Anwendung findet. Nähere Erläuterungen finden Sie in der Frage und Antwort mit der Ticketnummer 2023-01692.
Freundliche GrüßeIhr Forum Datenformate |
Ja
|
Thomas Seipt |
Klaus Keller |
Thomas Seipt |
Stefan Reumann |
|
Nein
|
Vorschlag
-------------Thomas Seipt-------------04.04.2023 11:11
Redaktionelle Anpassungen & Status zur Freigabe in PG umgestellt
-------------Klaus Keller-------------13.04.2023 07:46
|
Nein
|
Nein
|
|
PRICAT AHB 2.0b
|
Zur Abstimmung in PG
|
Wie muss auf die Vorgängerversion referenziert werden?
|
Es erfolgt immer eine Referenz auf die Vorgängerversion |
31.03.2023
|
2023-01714 |
|
|
Frage zur Vorgängerversion mit gleichem Gültigkeitszeitraum
Wenn innerhalb eines Gültigkeitszeitraums eine PRICAT korrigiert und erneut versandt wird, muss dann auf die vorangegangene PRICAT referenziert werden, auch wenn der gleiche Zeitraum angesprochen wird?
Oder ersetzt die korrigierte PRICAT innerhalb des selben Gültigkeitszeitraums die vorangegangene PRICAT, sodass nicht auf eine Vorgängerversion referenziert wird?
Für 2023 würde das bedeuten, dass es keine Vorgängerversionen gibt, da für den Gültigkeitszeitraum 2023 der Initialversand der PRICAT für Netznutzung erfolgt ist.
Folgendes Beispiel soll verdeutlichen, wovon ausgegangen wird. Bitte bestätigen oder korrigieren Sie die Annahme:
Beispiel:
- Preisblatt Netznutzung wird am 01.10.2022 für Gültigkeit 01.01.2023 – 31.12.2023 verschickt (ist Version 1)
- Preisblatt Netznutzung wird am 01.03.2023 für Gültigkeit 01.01.2023 – 31.12.2023 korrigiert und verschickt (ersetzt die „Vorgängerversion“ und wird somit wieder Version 1)
- Preisblatt Netznutzung wird am 01.10.2023 für Gültigkeit 01.01.2024 – 31.12.2024 verschickt (erhält Version 2, weil es eine Version 1 gab und sich der Gültigkeitszeitraum ändert; referenziert somit auf Version 1)
|
2023-03-31 16:11:36 |
Sehr geehrter Markteilnehmer,
ja, wenn eine bereits versendete PRICAT korrigiert werden soll, muss sich die neue PRICAT auf eine Vorgängerversion beziehen. Die Referenz erfolgt auch dann, wenn die ursprüngliche Version dasselbe Beginndatum (DTM+157) hat wie die neue Version. Dabei ist zu beachten, dass eine PRICAT nur ein Beginndatum (DTM+157) hat, aber kein Enddatum. Die Vorgängerversion endet immer zum Beginndatums der neuen Version der PRICAT.
Dies würde sich für Ihr Beispiel folgendermaßen darstellen:
Preisblatt (Version 1) wird am 01.10.2022 für Gültigkeit ab 01.01.2023 00:00 Uhr verschicktPreisblatt (Version 2) wird am 01.03.2023 für Gültigkeit ab 01.01.2023 00:00 Uhr als Korrektur verschickt und ersetzt die Vorgängerversion (Version 1). Referenz auf die Vorgängerversion „Version 1“Preisblatt (Version 3) wird am 01.10.2023 für Gültigkeit ab 01.01.2024 00:00 Uhr verschickt. Damit endet Preisblatt Version 2 automatisch zum 01.01.2024 00:00 Uhr. Referenz auf die Vorgängerversion „Version 2“.
Im PRICAT AHB Version 2.0c ist dies im Kapitel 4 „Erläuterung zur Nutzung des RFF-Segments „Vorgängerversion““ schematisch dargestellt.
Freundliche GrüßeIhr Forum Datenformate |
Ja
|
Thomas Seipt |
Klaus Keller |
Thomas Seipt |
Lusine Kloos |
|
Nein
|
-------------Klaus Keller-------------03.04.2023 17:27
an AG R/Z gemeldet, insbesondere unter Berücksichtigung des neuen AHB-Bildes zum 1.10.23
-------------Thomas Seipt-------------04.04.2023 17:51
Antwortvorschlag nach Besprechung in EDI@Energy
-------------Thomas Seipt-------------17.04.2023 16:25
Änderungsvorschläge von Carsten Fröse eingearbeitet und veröffentlicht. |
Nein
|
Nein
|
|
Codeliste der Artikelnummern und Artikel-ID 5.2
|
Eingegangen
|
Darf die Artikel-ID 1-10-3-001 im Jahr 2023 genutzt werden?
|
Wenn die Artikel-ID über Stammdaten ausgetauscht wurde, muss sie auch mit einem Preis von 0 € in der Netznutzungsrechnung als Position aufgeführt werden. |
29.03.2023
|
2023-01710 |
|
|
Sehr geehrtes Forum,
wie ist im Kalenderjahr 2023 mit der Artikel-ID 1-10-3-001 (Aufschläge aufgrund der Umlage für abschaltbare Lasten Letztverbrauch je Marktlokation (Einheit: €/kWh)) umzugehen, da diese seit dem 01.01.2023 nicht mehr abzurechnen ist?
Vielen Dank im Voraus!
|
2023-03-29 14:51:59 |
Sehr geehrter Marktteilnehmer,
gemäß Bundesnetzagentur wird ab dem Jahr 2023 keine Umlage für „Abschaltbare Lasten“ mehr erhoben. Für den Leistungszeitraum des Jahres 2023 sind zwei Szenarien in der Netznutzungsabrechnung möglich:
Szenario 1: keine Umlage für Abschaltbare Lasten:Der NB hat in der initialen Übermittlung der Abrechnungsdaten für die Netznutzungsabrechnung die Artikel-ID 1-10-3-001 (Aufschläge aufgrund der Umlage für abschaltbare Lasten Letztverbrauch je Marktlokation (Einheit: €/kWh)) für die betroffenen Marktlokationen und dem Leistungszeitraum ab dem 01.01.2023 00:00 Uhr an den LF nicht angegeben. In der Netznutzungsrechnung wird für Leistungszeiträume ab 01.01.2023 00:00 Uhr keine Position mit der Artikel-ID 1-10-3-001 aufgeführt.
Szenario 2: Umlage für Abschaltbare Lasten mit einem Preis von 0,00 €/kWh
Der NB hat in der initialen Übermittlung der Abrechnungsdaten für die Netznutzungsabrechnung die Artikel-ID 1-10-3-001 (Aufschläge aufgrund der Umlage für abschaltbare Lasten Letztverbrauch je Marktlokation (Einheit: €/kWh)) für die betroffenen Marktlokation und dem Leistungszeitraum ab dem 01.01.2023 00:00 Uhr an den LF übermittelt und damit für die Netznutzungsabrechnung vereinbart. In der Netznutzungsrechnung muss die Artikel-ID 1-10-3-001 als eigene Position aufgeführt werden. Der Preis muss mit 0,00 €/kWh aufgeführt werden. Damit entstehen für den LF keine unberechtigten Kosten.
Für Leistungszeiträume ab 01.01.2024 00:00 Uhr ist das Szenario 2 nicht mehr zulässig. Der NB muss für alle betroffenen Marktlokationen eine Stammdatenänderung an den LF senden, da die Artikel-ID 1-10-3-001 für Leistungszeiträume ab 01.01.2024 00:00 Uhr nicht mehr zulässig ist.
In beiden Szenarien wird sichergestellt, dass den LF keine unberechtigten Kosten in Rechnung gestellt werden und für die Rechnungsprüfung die Standardrechnungsprüfung (EBD E_0406) genutzt werden kann.
Andere Szenarien, wie z. B.:
Vereinbarung der Artikel-ID 1-10-3-001 für eine Marktlokation, ohne Aufführung dieser Position in der Netznutzungsrechnung oder
keine Vereinbarung der Artikel-ID 1-10-3-001 für eine Marktlokation, und Aufführung dieser Position in der Netznutzungsrechnung mit einem Preis von 0,00 €/kWh
sind nicht zulässig, da in diesen Fällen die Prüfung der Netznutzungsrechnung (EBD E_0406) zur Ablehnung führen würde.
Ihr Forum Datenformate |
Ja
|
Beate Becker |
Klaus Keller |
Beate Becker |
Thomas Seipt |
|
Nein
|
vereinbarte Antwort eingestellt
-------------Thomas Seipt-------------29.03.2023 14:53
|
Nein
|
Nein
|
|
Codeliste der Artikelnummern und Artikel-ID 5.2
|
Eingegangen
|
Darf die Artikel-ID 1-10-3-001 im Jahr 2023 genutzt werden?
|
Wenn die Artikel-ID über Stammdaten ausgetauscht wurde muss sie auch mit einem Preis von 0 € in der Netznutzungsrechnung als Position aufgeführt werden. |
22.03.2023
|
2023-01698 |
|
|
Sehr geehrtes Forum,
wie ist im Kalenderjahr 2023 mit der Artikel-ID 1-10-3-001 (Aufschläge aufgrund der Umlage für abschaltbare Lasten Letztverbrauch je Marktlokation (Einheit: €/kWh)) umzugehen, da diese seit dem 01.01.2023 nicht mehr abzurechnen ist?
Vielen Dank im Voraus!
|
2023-03-22 10:05:36 |
Sehr geehrter Marktteilnehmer,,
entsprechend § 20 Abs. 2 AbLaV wird im Jahr 2023 keine Umlage für „Abschaltbare Lasten“ mehr erhoben. Für den Leistungszeitraum des Jahres 2023 sind zwei Szenarien in der Netznutzungsabrechnung möglich:
Szenario 1: keine Umlage für Abschaltbare Lasten:Der NB hat in der initialen Übermittlung der Abrechnungsdaten für die Netznutzungsabrechnung die Artikel-ID 1-10-3-001 (Aufschläge aufgrund der Umlage für abschaltbare Lasten Letztverbrauch je Marktlokation (Einheit: €/kWh)) für die betroffenen Marktlokationen und dem Leistungszeitraum ab dem 01.01.2023 00:00 Uhr an den LF nicht angegeben. In der Netznutzungsabrechnung wird für Leistungszeiträume ab 01.01.2023 00:00 Uhr keine Position mit der Artikel-ID 1-10-3-001 aufgeführt.
Szenario 2: Umlage für Abschaltbare Lasten mit einem Preis von 0,00 €/kWhDer NB hat in der initialen Übermittlung der Abrechnungsdaten für die Netznutzungsabrechnung die Artikel-ID 1-10-3-001 (Aufschläge aufgrund der Umlage für abschaltbare Lasten Letztverbrauch je Marktlokation (Einheit: €/kWh)) für die betroffenen Marktlokation und dem Leistungszeitraum ab dem 01.01.2023 00:00 Uhr an den LF übermittelt und damit für die Netznutzungsabrechnung vereinbart. In der Netznutzungsrechnung muss die Artikel-ID 1-10-3-001 als eigene Position aufgeführt werden. Der Preis muss mit 0,00 €/kWh aufgeführt werden. Damit entstehen für den LF keine unberechtigten Kosten.Für Leistungszeiträume ab 01.10.2024 00:00 Uhr ist das Szenario 2 nicht mehr zulässig. Der NB muss für alle betroffenen Marktlokationen eine Stammdatenänderung an den LF senden, da die Artikel-ID 1-10-3-001 für Leistungszeiträume ab 01.01.2024 00:00 Uhr nicht mehr zulässig ist.
In beiden Szenarien wird sichergestellt, dass den LF keine unberechtigten Kosten in Rechnung gestellt werden und für die Rechnungsprüfung die Standardrechnungsprüfung (EBD E_0406) genutzt werden kann.
Andere Szenarien, wie z. B.:- Vereinbarung der Artikel-ID 1-10-3-001 für eine Marktlokation, ohne Aufführung dieser Position in der Netznutzungsabrechnung oder- keine Vereinbarung der Artikel-ID 1-10-3-001 für eine Marktlokation, und Aufführung dieser Position in der Netznutzungsabrechnung mit einem Preis von 0,00 €/kWh
sind nicht zulässig, da in diesen Fällen die Prüfung der Netznutzungsabrechnung (EBD E_0406) zur Ablehnung führen würde.
Ihr Forum Datenformate |
Ja
|
Beate Becker |
Klaus Keller |
Beate Becker |
Thomas Seipt |
|
Nein
|
Antwortvorschlag
-------------Thomas Seipt-------------22.03.2023 10:06
Anpassungen von Gregor übernommen
-------------Thomas Seipt-------------22.03.2023 13:34
|
Nein
|
Nein
|
|
Codeliste der Artikelnummern und Artikel-ID 5.2
|
Abgeschlossen
|
Wie ist die Ergänzung „, für die es keine genauer spezifizierte Artikel-ID gibt“ der Beschreibung der Artikel-ID 1-02-0-007 zu verstehen?
|
Differenziert ein NB bei steuerbaren Marktlokationen preislich nicht, kann die Artikel-ID 1-02-0-007 genutzt werden. |
19.03.2023
|
2023-01692 |
|
|
Sehr geehrte Damen und Herren,
über die Fehlerkorrektur vom 27.01.2023 wird die Beschreibung der von uns verwendeten Artikel-ID zur Abrechnung des Arbeitspreises von nach § 14a EnWG steuerbaren Marktlokationen 1-02-0-007 durch Ergänzung des Textes „für die es keine genauer spezifizierte Artikel-ID gibt“ auf „Grundpreis-/ Arbeitspreissystem Marktlokationen der Kategorie steuerbare Verbrauchseinrichtungen nach § 14a EnWG, für die es keine genauer spezifizierte Artikel-ID gibt Arbeitspreis (Einheit: €/kWh)“ geändert. Wir haben auf unserem Preisblatt lediglich eine Artikel-ID zur Abrechnung des Arbeitspreises von Marktlokationen der Kategorie steuerbare Verbrauchseinrichtungen nach § 14a EnWG, da dieser unabhängig von der Art, d. h. ob es sich dabei beispielsweise um eine Wärmepumpe, oder Elektromobilität handelt. Deshalb verwenden wir in der PRICAT dafür auch nur eine Artikel-ID, nämlich die 1-02-0-007.
Wie ist vor diesem Hintergrund die Textanpassung der Artikel-ID zu verstehen?
Vielen Dank!
|
2023-03-19 18:14:35 |
Sehr geehrter Marktteilnehmer,
diese Ergänzung erfolgte gleichzeitig mit der Anpassung, d. h. Erweiterung der Bezeichnungen der Artikel-ID
1-02-0-003 Grundpreis-/ Arbeitspreissystem Marktlokation der Kategorie steuerbare Speicherheizung, insbesondere nach § 14a EnWG Arbeitspreis (Einheit: €/kWh)
1-02-0-004 Grundpreis-/ Arbeitspreissystem Marktlokation der Kategorie steuerbare Wärmepumpe, insbesondere nach § 14a EnWG Arbeitspreis (Einheit: €/kWh)
1-02-0-006 Grundpreis-/ Arbeitspreissystem Marktlokationen der Kategorie steuerbare Elektromobilität, insbesondere nach § 14a EnWG Arbeitspreis (Einheit: €/kWh)
1-02-0-008 Grundpreis-/ Arbeitspreissystem Marktlokation der Kategorie steuerbare Speicherheizung, insbesondere nach § 14a EnWG Grundpreis (Einheit: €/Tag)
1-02-0-009 Grundpreis-/ Arbeitspreissystem Marktlokation der Kategorie steuerbare Wärmepumpe, insbesondere nach § 14a EnWG Grundpreis (Einheit: €/Tag)
1-02-0-010 Grundpreis-/ Arbeitspreissystem Marktlokationen der Kategorie steuerbare Elektromobilität, insbesondere nach § 14a EnWG Grundpreis (Einheit: €/Tag)
1-02-0-011 Grundpreis-/ Arbeitspreissystem Marktlokation der Kategorie steuerbare Speicherheizung mit erweiterter Steuerbarkeit, insbesondere nach § 14a EnWG Arbeitspreis (Einheit: €/kWh)
1-02-0-012 Grundpreis-/ Arbeitspreissystem Marktlokation der Kategorie steuerbare Wärmepumpe mit erweiterter Steuerbarkeit, insbesondere nach § 14a EnWG Arbeitspreis (Einheit: €/kWh)
1-02-0-013 Grundpreis-/ Arbeitspreissystem Marktlokationen der Kategorie steuerbare Elektromobilität mit erweiterter Steuerbarkeit, insbesondere nach § 14a EnWG Arbeitspreis (Einheit: €/kWh)
um den Text „insbesondere nach § 14a EnWG“.
Um bei NB, die beispielsweise die Artikel-ID 1-02-0-003 verwenden, deutlich zu machen, dass wenn diese beispielsweise zusätzlich auch die Artikel-ID 1-02-0-007 im Preisblatt nutzen, die Artikel-ID 1-02-0-007 nur dann zu nutzen ist, wenn sich auf deren elektronischem Preisblatt „Netznutzung ohne gemeindespezifische Konzessionsabgaben“ keine besser passende Artikel-ID befindet. D. h., wenn der NB für alle Marktlokationen der Kategorie „steuerbare Verbrauchseinrichtungen nach § 14a EnWG“ nur einen Preis nutzt, unabhängig von der Art des Verbrauchs, reicht es aus, wenn nur die Artikel-ID 1-02-0-007 in der PRICAT angegeben, diese jeder entsprechenden Marktlokation zugewiesen und diese anschließend in der Netznutzungsrechnung verwendet wird.
Freundliche Grüße,Ihr BDEW Forum Datenformate |
Ja
|
Beate Becker |
Klaus Keller |
Beate Becker |
Stefan Seidel |
Kapitel 3.1.2 Entgelte des Grundpreis-/Arbeitspreissystems bzw. Änd-ID 23927 |
Nein
|
-------------Stefan Seidel-------------19.03.2023 18:49
Erster Antwortvorschlag entsprechend dem Ergebnis der AG R/Z vom 167.3.2023 erstellt
-------------Stefan Seidel-------------28.03.2023 12:19
Ergebnis der Besprechung vom 27.3.2023 reinkopiert
-------------Klaus Keller-------------28.03.2023 16:21
Kurzfrage und -antwort gemäß Vorgabe aktualisiert und überflüssiges Komma in Antwort entfernt
|
Nein
|
Nein
|
|
Codeliste der Artikelnummern und Artikel-ID 5.2
|
Abgeschlossen
|
Ist eine Artikel-ID anzugeben, wenn keine KA anfällt?
|
Nein, es ist nur eine Artikel-ID anzugeben, wenn eine KA anfällt. |
19.01.2023
|
2023-01626 |
|
|
Sehr geehrtes Datenforum,
wir haben zwei Arten von Anlagen die gänzlich von der KA befreit sind.
Aktuell ist für uns nicht eindeutig klar, wie diese im UTILMD und INVOIC Versand korrekt dazustellen und auszutauschen sind.
Folgende zwei Konstellationen liegen vor:
1. Einen Gemeindeteil (nicht die gesamte Gemeinde) für den es KEINEN KA Vertrag mit der Gemeinde gibt und somit keine KA erhoben wird.
2. Eigenanlagen des Netzbetreibers die per gesetzlicher Regelung, von der KA befreit sind und sich in unterschiedlichsten Gemeinden befinden.
Welche Artikel IDs sind hier für die Darstellung der KA zu verwenden?
a. die Artikel ID ist garnicht anzugeben, weder in der UTILMD noch in der INVOIC
b. eine gemeindespezifische KA ID mit Preis 0 € für alle Nutzergruppen (1-08-4-AGS-KG)
c. die Artikel ID 1-08-6-001
Aus unserer Sicht, wäre die Verwendung der Artikel ID 1-08-6-001 die geeignetste Variante, da hier direkt von Beginn an ersichtlich ist, dass die Mengen der Malo von der KA befreit sind. Diese Artikel ID könnte dann auch in der INVOIC zur 0 € Position angegeben werden. Es würde bei Vollständigkeitsprüfungen durch den Lieferanten, keine zu erwartenden aber fehlenden Artikel moniert werden, weder in UTILMD noch in INVOIC.
Leider darf jedoch diese Artikel ID, laut AHB, nicht in der UTILMD und auch nur im Rahmen der SOR in der INVOIC verwendet werden. Obwohl es sich hier um Fälle handelt, bei denen bereits im Vorfeld die KA Befreiung fest steht und nicht erst im Nachhinein durch ein Testat oder ähnliches nachgewiesen werden muss.
Wie wären diese Fälle korrekt zu versenden und zu verarbeiten?
Vielen Dank und Grüße
|
2023-01-19 08:05:34 |
Sehr geehrter Marktteilnehmer,
nein, es ist nur eine Artikel-ID anzugeben, wenn eine KA anfällt.
Mit freundlichem Gruß,
Ihr BDEW-Forum Datenformate |
Ja
|
Beate Becker |
Klaus Keller |
Beate Becker |
Julia Satzer |
|
Nein
|
|
Nein
|
Nein
|
|
Codeliste der Artikelnummern und Artikel-ID 5.2
|
Abgeschlossen
|
Welche Artikelnummern gelten für die Mehr-/Mindermengenabrechnung?
|
Für die Mehr-/Mindermengenabrechnung gelten die bisherigen Artikelnummern. |
10.09.2022
|
2022-01478 |
|
|
In der ersten Version der BNA Anlage 1b.xlsx waren Artikel-IDs veröffentlicht für Mehr- und Mindermengen.
In der aktuellen Version der Codelisten findet man diese Artikel-IDs jetzt für
Artikel-ID [1-02-0-008] Grundpreis-/ Arbeitspreissystem Marktlokation der Kategorie steuerbare Speicherheizung
Grundpreis (Einheit: €/Tag)
und
Artikel-ID [1-02-0-009] Grundpreis-/ Arbeitspreissystem Marktlokation der Kategorie steuerbare Wärmepumpe
Grundpreis (Einheit: €/Tag)
Wie lauten nun die Artikel-IDs für Mehr- und Mindermengen?
Sind für die Mehr-Mindermengenabrechnung nun wieder die alten BDEW-Codenummern zu verwenden? (Dies widerspräche aber dem Textauszug unten.)
|
2022-09-10 17:31:11 |
Sehr geehrter Marktteilnehmer,
die neuen Artikel-ID für die Mehr-/Mindermengen aus der Anlage 1B der BNetzA sind nicht in die Codeliste der Artikelnummern und Artikel-ID überführt worden, da die Mehr-/Mindermengenabrechnung eine eigene Abrechnung darstellt, die nicht Bestandteil der GPKE oder WiM Strom ist. Daher sind die bisherigen Artikelnummern für die Mehr- und Mindermenge weiterhin gültig.
Mit freundlichem Gruß
Ihr BDEW-Forum Datenformate |
Ja
|
Beate Becker |
Klaus Keller |
Beate Becker |
Claudia Kring |
1 Einleitung
Die Codeliste der Artikelnummern, Gruppenartikel-ID und Artikel-ID findet Anwendung in den
Nachrichtenbeschreibungen INVOIC, ORDERS, ORDRSP, PRICAT, QUOTES und UTILMD. Mit der
neuen BNetzA-Festlegung BK6-20-160 zur Weiterentwicklung der Netzzugangsbedingungen
Strom werden die Artikelnummern in der Sparte Strom für die GPKE von den Artikel-ID aus dem
Preisblatt der Anlage 1b „Netznutzungspreisblatt“ der BNetzA abgelöst. Somit findet
ausschließlich die Codeliste der Artikelnummern und Artikel-ID in der Marktkommunikation
Anwendung. |
Nein
|
Antwortvorschlag formuliert
-------------Beate Becker-------------13.09.2022 13:55
|
Nein
|
Nein
|
|
UTILTS AHB Zählzeitdefinitionen 1.0a
|
Abgeschlossen
|
Darf innerhalb einer "Übermittlung Übersicht Zählzeitdefinition" die gleiche Kombination aus MP-ID des Absenders (NAD+MS)/Versionsangabe (DTM+293)/Gültig Ab (DTM+157) mit neueren DTM+137 gegenüber dem gleichen Empfänger versendet werden?
|
Die von Ihnen obige Kombination darf vom Versender nur einmal gegenüber dem Empfänger verwendet werden, da der Empfänger die gleiche Kombination nicht noch einmal verarbeiten kann. Eine Klärung der Sachverhaltes kann mit dem MP nur bilateral erfolgen. |
27.03.2023
|
2023-01704 |
|
|
Guten Tag,
gemäß AHB ergibt sich die Version der Übersicht aus folgenden Tupeln:
MP-ID des Absenders (NAD+MS)
Versionsangabe (DTM+293)
Gültig Ab (DTM+157)
Nun erhalten wir neue UTILTS mit einem aktuellen DTM+137 (Datum Nachrichtenerzeugung) wo aber die 3 oben genannten Angaben exakt identisch sind. Da weder im MIG noch im AHB Bedingungen gesetzt sind, können wir die Nachrichten nicht ablehnen. Verarbeiten können wir die Nachrichten aber auch nicht, weil diese für unser System "doppelt" sind. Müsste es hier nicht mindestens für das DTM+293 eine Bedingung geben, dass eine Versionsnummer nur "einmalig" zu vergeben ist?
|
2023-03-27 09:45:38 |
Sehr geehrter Fragesteller,
aus Ihren Angaben schließen wir, dass Sie Ihre Anfrage auf die "Übermittlung Übersicht Zählzeitdefinition" bezieht.
Wie Sie zu Recht aufzeigen, wird die Eindeutigkeit über die nachfolgende Kombination gebildet:
MP-ID des Absenders (NAD+MS)Versionsangabe (DTM+293)Gültig Ab (DTM+157)
Da die MP-ID des Absenders sich nicht ändert gehen wir auf dies hier nicht weiter ein.
Somit bleiben noch die beiden Angaben Versionsangabe (DTM+293) und die zeitliche Zuordnung über Gültig Ab (DTM+157).Hier möchten wir die entsprechenden Angaben aus dem UTILTS MIG (Version 1.1a) aufzeigen
SG5 Vorgang
DTM+293 Versionsangabe
Bemerkung:Dieses Segment wird zur Angabe der Version einer Übersicht der Zählzeitdefinition oder einer ausgerollten Zählzeitdefinition verwendet
SG5 Vorgang
DTM+157 Gültig ab
Dieses Segment wird zur Angabe verwendet, zu welchem Zeitpunkt die Berechnungsformel oder die Übersicht der Zählzeitdefinitionen ihre Gültigkeit erlangt.
Aus diesem beiden Angaben wird klar, dass Sie im Grunde - wenn Sie die entsprechende Kombination bereits in Ihren System hinterlegt haben- keine erneute Verarbeitung mehr anstossen müssen. Sie sollten jedoch Ihren MP darauf hinweisen, dass sollte er eine Veränderung vorgenommen haben, so ist entsprechend der obigen Vorgaben eine neue Versionsangabe zwingend notwendig.
Mit freundlichen Grüßen
Ihr Forum Datenformate |
Ja
|
Martin Neubauer |
Holger Weickenmeier |
Martin Neubauer |
Ramona Pantani |
|
Nein
|
-------------Martin Neubauer-------------26.04.2023 09:11
Initialbetrachtung mit Holger
Änderungsantrag ist zu erstellen
Veröffentlichung: ja
Lösung derzeit-> bilaterale Abstimmung
Weiteres Vorgehen: Bedingung im AHB
Bedingung XYZ: ala Version darf vom Versender nicht schon einmal verwendet worden sein, da der Empfänger die gleiche Version nicht noch einmal verarbeiten kann.
-------------Martin Neubauer-------------02.05.2023 09:17
Erstaufschlag zur Abstimmung an Holger übergeben
-------------Holger Weickenmeier-------------30.05.2023 09:32
Mit Martin noch mal durchgesprochen und veröffentlicht.
Wir hatten über eine zusätzliche Bedingung nachgedacht. Diese sehen wir als nicht umsetzbar, da wir je keine Antwort haben und die APERAK ja nur in dem Geschäftsvorfall prüft. |
Nein
|
Nein
|
|
UTILTS AHB Zählzeitdefinitionen 1.0a
|
Abgeschlossen
|
Muss mit jeder Angabe eines Zählzeitänderungszeitpunktes innerhalb der "Übermittlung einer ausgerollten -jährlich zu übermittelnden- Zählzeit" auch das Zählregister wechseln?
|
Eine Angabe eines Zeitpunktes hat grundsätzlich nur beim Wechsel auf ein neues aktives Zählzeitregister zu erfolgen, bei einer "jährlich zu übermittelnde ausgerollte Zählzeit" ist die Angabe zum Start des Gültigkeitsbeginns (01.01.xxxx) davon abweichend |
08.03.2023
|
2023-01675 |
|
|
Laut der im AHB beschriebenen Befüllungslogik zur Übermittlung von ausgerollten Zählzeiten welche jährlich zu übermitteln (Z34) sind, ergibt sich für uns folgender logischer Aufbau für Hochlastzeitfenster:
Vergebener Zählzeitcode ZZD = HLZ (Z34 jährlich zu übermittelnde ausgerollte
Zählzeit) mit:
Register1 ALZ = außerhalb Hochlastzeit
Register2 HLZ = innerhalb Hochlastzeit
Ausgerollte Zählzeiten (tagesscharf betrachtet):
01.01.2023 00:00 = Register1 ALZ (außerhalb Hochlastzeitfenster)
SEQ+Z43'DTM+Z33:202212312300?+00:303'RFF+Z28:ALZ'
02.01.2023 00:00 = Register1 ALZ (außerhalb Hochlastzeitfenster) → neuer Tag
SEQ+Z43'DTM+Z33:202301012300?+00:303'RFF+Z28:ALZ'
02.01.2023 16:30 = Register2 HLZ (innerhalb Hochlastzeitfenster)
SEQ+Z43'DTM+Z33:202301021530?+00:303'RFF+Z28:HLZ'
02.01.2023 19:00 = Register1 ALZ (außerhalb Hochlastzeitfenster)
SEQ+Z43'DTM+Z33:202301021800?+00:303'RFF+Z28:ALZ'
03.01.2023 00:00 = Register1 ALZ (außerhalb Hochlastzeitfenster) → neuer Tag
SEQ+Z43'DTM+Z33:202301022300?+00:303'RFF+Z28:ALZ'
usw…
Im Zeitraum 01.03.2023 bis 30.11.2023 erfolgt die tägliche Zuordnung im Register ALZ (außerhalb Hochlastzeitfenster) da in diesem Zeitraum kein Hochlastzeitfenster vorliegt, hier betrachten wir dennoch tagesscharf.
01.03.2023 00:00 = Register1 ALZ (außerhalb Hochlastzeitfenster)
SEQ+Z43'DTM+Z33:202302282300?+00:303'RFF+Z28:ALZ'
02.03.2023 00:00 = Register1 ALZ (außerhalb Hochlastzeitfenster) → neuer Tag
SEQ+Z43'DTM+Z33:202303012300?+00:303'RFF+Z28:ALZ'
03.03.2023 00:00 = Register1 ALZ (außerhalb Hochlastzeitfenster) → neuer Tag
SEQ+Z43'DTM+Z33:202303022300?+00:303'RFF+Z28:ALZ'
usw…
Diese Übersicht der ausgerollten Zählzeit wird von einigen wenigen Marktpartnern
reklamiert da diese der Ansicht sind, dass mit jedem Änderungszeitpunkt auch
das Zählregister wechseln muss.
Ist die Reklamation berechtigt?
|
2023-03-08 12:49:18 |
Sehr geehrter Fragesteller,
folgende Grundlagen sind in Bezug auf Ihre Fragestellung auf eine "jährlich zu übermittelnde ausgerollte Zählzeit" (Z34) zu beachten:
UTILTS MIG (Version 1.1a)
SG8 Ausgerollte Zählzeit
DTM +Z33 Zählzeitänderunszeitpunkt
Bemerkung:Angabe eines Zeitpunktes, zu dem der Wechsel auf ein neues aktives Zählzeitregister erfolgt.
Ausnahme:
UTILTS AHB Zählzeitdefinitionen (Version 1.0a)
Kapitel 6
Ein Zählzeitänderungszeitpunkt einer ausgerollten Zählzeit muss mit dem identischen Zeitpunkt aus dem Gültigkeitsbeginn angegeben werden. Somit wird dem Empfänger das zum Start der ausgerollten Zählzeit zählende Register mitgeteilt.
Es ist ersichtlich, dass eine Angabe grundsätzlich nur beim Wechsel auf ein neues Zählzeitregister zu erfolgen hat (siehe Hinweis MIG) bzw. zum Start der ausgerollten Zählzeit. Bei Ihrer Abbildung ist dies nicht der Fall, da sie an allen Tagen zu 00:00 Uhr die Zählzeit nennen, was aber nur am 01.01. eines Jahres nötigt (und damit erlaubt) ist.Aus diesem Grund ergibt sich, dass die Reklamation berechtigt ist.
Mit freundlichen Grüßen
Ihr Forum Datenformate |
Ja
|
Martin Neubauer |
Holger Weickenmeier |
Martin Neubauer |
Michael Günzel |
|
Nein
|
-------------Martin Neubauer-------------26.04.2023 09:52
Initialbetrachtung mit Holger
Veröffentlichung: Ja
Umschaltzeitpunkte sind zu benennen und nicht "täglich" den Status zu setzen
Die Aussage in Bezug auf die Reklamation ist korrekt.
Erstaufschlag durch Martin
-------------Martin Neubauer-------------02.05.2023 07:57
Erstaufschlag erstellt und zur Betrachtung an Holger übergeben
-------------Martin Neubauer-------------02.05.2023 12:34
Hinweise von Herrn Seidel aufgenommen
-------------Holger Weickenmeier-------------30.05.2023 09:34
Mit Martin Frage zusammen besprochen und veröffentlicht. |
Nein
|
Nein
|
|
UTILTS AHB Zählzeitdefinitionen 1.0a
|
Abgeschlossen
|
Müssen immer alle Zählzeiten in der Übersicht der Zählzeitendefinitionen enthalten sein?
|
In der "Übermittlung Übersicht Zählzeitdefinition" sind immer alle Codes der vom Versender verwendeten Zählzeiten enthalten. Eine neue Version ist hierzu erforderlich. |
24.10.2022
|
2022-01530 |
|
|
1. Ist es richtig, dass die Nachricht Utilts 25004 immer alle Zählzeitdefinitionen eines NB enthalten muss, auch bei einer Korrektur? Wir als MSB haben von einigen NBs pro Zählzeitdefinition je eine Utilts 25004 Nachricht erhalten. Das wäre dann ja nicht korrekt.
2. Müssen die Versionsnummern bei jeder neuen Version hochgezählt werden oder gibt es Fälle, in denen die Versionsnummer nicht verändert werden muss?
3. Wie ist die Zuordnung einer ausgerollten Zählzeit zu einer Zählzeitdefinition gedacht? Soll das über die Versionsnummer geschehen oder muss man als MSB sich die neueste Definition in dem passenden Gültigkeitsbereich suchen und diesem zuordnen?
4. Was passiert, wenn ich als MSB eine Zählzeitdefinition mit ausgerollten Zählzeiten habe und dann ein Update/Korrektur für die Zählzeitdefinition erhalten, gelten die ausgerollten Zählzeiten dann automatisch auch für das Update oder muss der NB zwingend für das Update neue ausgerollte Zählzeiten schicken bevor diese Definition wirksam wird?
|
2022-10-24 14:47:07 |
Sehr geehrter Fragesteller,
zu 1:
Ja in der Übermittlung Übersicht Zählzeitdefinition (UTILTS 25004) sind immer alle Zählzeitdefinitionen der Vergabestelle abzubilden, dies ist auch im Falle einer Korrektur so.
zu 2:
Wie im UTILTS Anwendungshandbuch Zählzeitdefinition 1.0a auf der Seite 3 ersichtlich, erfolgt die Versionierung der Übermittlung Zählzeitdefinitionen über das Tupel:
MP-ID des Absenders (SG2 NAD+MS)
Versionsangabe (SG5 DTM+293)
Gültig Ab (SG5 DTM+157)
Präzisierung am 29.03.2023:
Da Punkt 2 (Versionsangabe / 293 Fertigstellungsdatum/-zeit) in jeden Fall von der Version davor abweichen muss, erfolgt automatisch das Vergeben einer neuen Version und damit mit Ihren Worten eine „Hochzählung“. Das Fertigstellungsdatum war so angedacht, dass man dies mit dem Versendezeitpunkt der Nachricht befüllt. Somit erhält eine neuere Liste immer eine höhere Version.
Die Versionsangabe (DTM+293 Fertigstellungsdatum/-zeit) vergibt der Absender in seinem IT-System. Ein neue Versionsangabe wird genau dann vergeben, wenn inhaltliche Änderungen in der Übersicht der Zählzeitdefinitionen oder in der ausgerollten Zählzeit durchgeführt wurden, diese wird gegenüber allen Empfängern verwendet. Somit erhält eine neuere Liste mit inhaltlichen Änderungen immer eine höhere Version. Ein mehrmaliger Versand der gleichen Version der Übersicht der Zählzeit oder den ausgerollten Zählzeitdefinitionen ist laut Prozess nicht vorgesehen.
zu 3:
Die Zuordnung einer ausgerollten Zählzeit zu der Übersicht Zählzeitdefinition erfolgt über den zuvor eindeutig vergebenen Code der Zählzeit (25004/ SG9 Code der Zählzeit Z39/ Beispiel: CCI+Z39++ZZ1' zu 25005 / SG5 Code der Zählzeit Z09 / LOC+Z09+ZZ1') Es ist immer die aktuellste vorliegende Version (für das betroffene Kalenderjahr) zu verwenden.
Zu 4:
Alle bereits im Vorfeld bestandenen Codes, die in der Übersicht er Zählzeitdefinitionen weiterhin aufgeführt sind, verlieren nicht ihre Verknüpfung zu den ebenfalls bereits im Vorfeld ausgerollten Zählzeiten, da die Findung weiterhin nach der Regel wie oben bei „3“ ersichtlich ist besteht.
Bei einer Erweiterung der Übersicht der Zählzeitdefinition um einen weiteren Code, ist für diesem natürlich die Übermittlung einer rausgerollten Zählzeit notwendig.
Beim enfallen einer Zählzeit in der Übersicht der Zählzeitdefinitionen sind die ausgerollten Zählzeitden dann obsolet.
Mit freundlichen Grüßen
Ihr Forum Datenformate |
Ja
|
Martin Neubauer |
Holger Weickenmeier |
Martin Neubauer |
Thorsten Bruns |
|
Nein
|
-------------Martin Neubauer-------------02.11.2022 14:19
Erstaufschlag
-------------Holger Weickenmeier-------------27.01.2023 10:46
Veröffentlicht
-------------Gregor Scholtyschik-------------29.03.2023 15:35
Präzisierung mit Holger W. bzgl. genehmigten Konsultationsbeitrag zur UTILTS MIG |
Nein
|
Nein
|
|
UTILTS AHB Zählzeitdefinitionen 1.0a
|
Abgeschlossen
|
Wie ist das Merkmal "Häufigkeit der Übermittlung" zu verstehen, wenn das Merkmal "elektronisch nicht übermittelbar" verwendet wird?
|
Auch bei dem Merkmal "elektronisch nicht übermittelbar" ist die Häufigkeit auf Grund der zugrundeliegenden Abbildung anzugeben. |
05.10.2022
|
2022-01505 |
|
|
Wie ist das Merkmal "Häufigkeit der Übermittlung" zu verstehen, wenn das Merkmal "elektronisch nicht übermittelbar" verwendet wird?
In einer Übersicht ZZD sind Zählzeiten enthalten, die als "nicht elektronisch übermittelbar" (CAV+ZD5:::Z24') gekennzeichnet sind. In diesem Fall stellt sich inhaltlich die Frage, ob die Angabe des Merkmals "Häufigkeit der Übermittlung" (CAV+ZE0) Sinn ergibt. Im MIG steht zum Merkmal "Übermittelbarkeit": "Der NB übermittelt die ausgerollte Zählzeit auf einem bilateral vereinbarten Weg. Dieser Weg wird hier nicht weiter beschrieben. " Wenn der Weg "bilateral vereinbart" ist, sollte das Merkmal "Häufigkeit der Übermittlung" für diesen Fall nicht entfallen oder "bilateral vereinbart" sein?
|
2022-10-05 11:18:21 |
Sehr geehrter Fragesteller,
es hängt davon ab, ob die bilateralen Absprachen einmalig, oder diese für jedes neue Jahr erneut (auf Grund der Abbildung) durchzuführen sind.Eine Zählzeit, welche nicht elektronisch übermittelt werden kann, muss ja sehr komplex sein. Wenn dieser bilaterale Übermittlung dann einmalig ausreichen würde, stellt sich die Frage ob diese nicht doch elektronisch übermittelbar ist. Ansonsten würden wir die Vorgaben aus der Festlegung auch für diesen Fall bindend ansehen.
Grundsätzlich sollte aber bei der Anwendung von ZD5 „Übermittelbarkeit der ausgerollten Zählzeit“ / Z24 „elektronisch nicht übermittelbar“ der Grund dafür hinterfragt werden.
Sollten weitere notwendige Abbildungsmöglichkeiten innerhalb der UTILTS für umfangreiche Anwendungsfälle benötigt werden, so empfehlen wir diese innerhalb der nächsten Konsultation aufzuzeigen und einzufordern.
Gibt es jedoch seltene und komplexe Altlasten bei Marktpartnern, so empfehlen wir diese zu hinterfragen.
Mit freundlichen Grüßen
Ihr Forum Datenformate |
Ja
|
Martin Neubauer |
Holger Weickenmeier |
Martin Neubauer |
Christian Olbrich |
"Der NB übermittelt die ausgerollte Zählzeit auf einem bilateral vereinbarten Weg. Dieser Weg wird hier nicht weiter beschrieben. " |
Nein
|
-------------Martin Neubauer-------------02.11.2022 16:09
Erstaufschlag
-------------Holger Weickenmeier-------------27.01.2023 11:04
Veröffentlicht |
Nein
|
Nein
|
|
Stammdaten AWT 1.2
|
Abgeschlossen
|
Wird Fußnote 22 genutzt?
|
Die Fußnote 22 wurde in der Veröffentlichung am 31.03.2023 gelöscht. |
23.02.2023
|
2023-01668 |
|
|
Die Fußnote 22 "Wenn Status_individuelle_Quote mit Z01 vorhanden" wird im Dokument Stammdaten AWT 1.2 nicht aufgegriffen. Es kann nicht nachvollzogen werden, wann die Fußnote zum Einsatz kommen würde. Bitte um zeitnahe Klarstellung
|
2023-02-23 16:45:41 |
Sehr geehrte/r Fragesteller/in,
die Fußnote 22 "Wenn Status_individuelle_Quote mit Z01 vorhanden" wird in den veröffentlichten Dokumenten zum 31.03.2023 gelöscht und ist infolgedessen nicht zu berücksichtigen.
Mit freundlichen Grüßen
Ihr Forum Datenformate |
Ja
|
Sara Olszewski |
Alexander Kramer |
Sara Olszewski |
Lusine Kloos |
|
Nein
|
bearbeitet
-------------Sara Olszewski-------------31.03.2023 11:13
bearbeitet und besprochen
-------------Katia Schubert-------------12.05.2023 13:48
|
Nein
|
Ja
|
|
Codeliste der OBIS-Kennzahlen und Medien - informatorische Lesefassung 2.4a
|
Eingegangen
|
Warum ist eine Tarifierung von Leistungswerten nicht mehr möglich?
|
Tarifierung von Leistungswerten wurde in der Konsultation bereinigt |
26.01.2023
|
2023-01636 |
|
|
Liebes edi@energy-Team,
wir haben leider das Problem, dass wir Geräte von Elster (A1500-D161-521-OS8-4) mit Leistungszählwerken (1-b:1.6.1) haben, die nicht auf dem Summenzählwerk (1-b:1.6.0) des Leistungsmaximums tarifiert sind. Das Gerät besitzt kein Summenzählwerk bei der Leistungsmaximum. Aufgrund der Anpassung zum 01.10.2022 erhalten wir leider APERAKs, da unsere MSCONS-Nachrichten mit z.B. 1-1:1.6.1 nicht mehr zulässig sind.
Können Sie bitte prüfen, was die Ursache der Änderung zum 01.10.2022 war? Ist eine Anpassung auf 1-b:1.6.e möglich, wie vor 01.10.2022?
Viele Grüße
Rainer Guttroff
|
2023-01-26 14:40:21 |
Sehr geehrter Fragesteller,
die von Ihnen beschriebene Änderung wurde dem Markt im Rahmen der Konsultation im August 2021 zur Verfügung gestellt als Basis für die Umsetzung der MaKo 2022. Aufgrund der Einführung der Zählzeitdefinitionen, z.B. für die Zählzeitenanwendungszwecke Netznutzung (Verwendungszwecke: Netznutzungsabrechnung, Bilanzkreisabrechnung, MMMA, Übermittlung an HKNR, Ermittlung der Ausgeglichenheit von Bilanzkreisen) ist zu jedem Wert welcher keine Tarifstufe "0" hat eine Zählzeit sowie ein Zählzeitregister zuzuordnen. Dieses Vorgehen ist in der BDEW Anwendungshilfe "Einführungsszenario zur Weiterentwicklung der Netzzugangsbedingungen Strom BK6-20-160", welche auf www.edi-energy.de veröffentlicht ist beschrieben. Für den Austausch von Leistungswerten ist hier kein Anwendungsfall bekannt, für den eine Tarifunterscheidung der Leistungswerte aufgrund der genannten Verwendungszwecke notwendig ist. Daher sind ab diesem Zeitpunkt Leistungswerte gemäß Codeliste der OBIS-Kennzahlen und Medien lediglich mit der Tarifstufe "0" im Markt zulässig. Hat der MSB eine Messtechnik verbaut, welche mehr Zählwerke hat, als gemäß Anforderungen notwendig sind (in Ihrem Falle das Leistungsmaximum), so hat er diese Werte, sofern ein Verwendungszweck für diese Werte vorliegt, mit der Tarifstufe "0" zu übermitteln. Die am Messgerät vorhandenen Bezeichnungen des Zählwerkes können dabei als "Bezeichnung des Zählwerks auf dem Gerät" übermittelt werden.
Diese Annahme wurde auch im Rahmen der Konsultationssitzung bestätigt, da hierzu keine weiteren Konsultationsbeiträge von Marktteilnehmern zu diesen Änderungen eingegangen sind.
Viele Grüße,Ihr BDEW-Forum Datenformate
|
Ja
|
Reinhard Döring |
Thomas Seipt |
Tim Geisendörfer |
Rainer Guttroff |
Codeliste der OBIS-Kennzahlen und Medien
Seite 9, 10, 11 und 15 |
Nein
|
Antwortvorschlag an Thomas Fellhauer gesendet
Sehr geehrter Fragesteller,
die von Ihnen beschriebene Änderung kam mit der Konsultation. In dieser hat jeder die Möglichkeit sich einzubringen und Änderungen kritisch zu hinterfragen. Leider kam zu dieser Änderung kein Konsultationsbeitrag, so dass die Annahme bestätigt wurde, dass eine Tarifierung von Leistungswerten in der Marktkommunikation nicht benötigt wird.
Viele Grüße,
Ihr BDEW-Forum Datenformate
-------------Thomas Seipt-------------01.02.2023 12:08
Antwortvorschlag überarbeitet, fe
-------------Thomas Fellhauer-------------07.02.2023 18:11
|
Nein
|
Nein
|
|
REQOTE / QUOTES / ORDERS / ORDRSP / ORDCHG AHB 2.0a
|
Zur Abstimmung in PG
|
Wie ist die Anfrage von Zustandszahl und Brennwert für einen Zeitraum in der Zukunft abzulehnen?
|
Die Anfrage wird per ORDRSP mit dem Code Z15 abgelehnt |
24.01.2023
|
2023-01630 |
|
|
Hallo,
es werden MSCONS per APERAK mit dem Fehler "Zeitangabe unplausibel in Anwendungsfall 13009 (DTM+164)
abgelehnt, da es eine fehlende Prüfung bei eingehender ORDERS 17103 (Z10) gibt. In der ORDERS sollte das angefragte Enddatum nicht in der Zukunft liegen. Hier sollte bereits die ORDERS abgelehnt werden.
Können Sie hier kurzfristig Abhilfe schaffen. (01.04.2023 – Formatwechsel)
Dies würde allen die Arbeit erleichtern, wenn eine direkte Vorgabe besteht.
Danke
Mit freundlichen Grüßen
Tatjana Dirksen und Silke Kleinhans
|
2023-01-24 15:43:39 |
Siehe Entscheidungsbaumdiagramm und Codelisten Kapitel 13.9.1
G_0015_ORDRSP Abl. der Anforderung
Code
Nutzung
Bedingung
Name
Z15
X
Bei Anfragen für Zeitspannen, die nicht in die Vergangenheit gerichtet sind
Ablehnung keine Berechtigung
|
Ja
|
|
Thomas Fellhauer |
|
Tatjana Dirksen |
|
Nein
|
|
Nein
|
Nein
|
|
INVOIC MIG - informatorische Lesefassung 2.8
|
Abgeschlossen
|
Ist die maximale Anzahl Wiederholungen bei Segmentgruppe MOA50+131 zu niedrig gewählt ?
|
Nein, die maximale Anzahl von 20 Wiederholungen reicht für eine Abrechnungszeitraum von einem Jahr aus. |
09.12.2022
|
2022-01593 |
|
|
Sehr geehrte Damen und Herren,
die maximale Anzahl von Wiederholungen der Segmentgruppe SG50 Segment MOA mit Qualifier 131 – Vorausbezahlter Betrag ist als BDEW-Standard in der INVOIC Nachrichtenbeschreibung – Fehlerkorrektur mit Stand 06.07.2022 mit 20 angegeben, diese Vorgabe gilt auch für die ab 01.04.2023 gültige Version.
Diese Einschränkung stellt uns bei der Bearbeitung von weit in die Vergangenheit zurückgehende Zählerverwechslungen oder rückwirkenden Einzugsstornierungen in einzelnen Fällen vor Probleme, da in solchen Fällen in die zu erstellende Abschlussrechnung dann mehr als 20 Abschlagsrechnungen aufgeführt werden müssen. Auf entsprechende Nachrichten erhalten wir von unseren Marktpartnern negative Control-Nachrichten, gleichzeitig werden alle zu berücksichtigende Abschlagsrechnungen für die Rechnungseingangsverarbeitung zwingend benötigt.
Daher bitten wir Sie zu prüfen, ob hier eine Erhöhung der maximalen Wiederholungen möglich ist.
|
2022-12-09 08:34:09 |
Sehr geehrter Fragesteller,
auf Basis von:
EnWG § 40b Rechnungs- und Informationszeiträume:
(1) Energielieferanten sind verpflichtet, den Energieverbrauch nach ihrer Wahl in Zeitabschnitten abzurechnen, die ein Jahr nicht überschreiten dürfen, ohne hierfür ein Entgelt in Rechnung zu stellen. Sie sind verpflichtet, [...]
und
NN-RV der BK6 § 8 Abrechnung, Zahlung und Verzug
Grundsätzlich rechnet der Netzbetreiber die Entgelte nach § 7 bei Marktlokationen im Niederspannungsnetz mit einer jährlichen Entnahme von bis zu 100.000 kWh, die mit Zählerstandsgangmessung oder einer anderen Form der Arbeitsmessung ausgestattet sind, jährlich und im Übrigen (insbesondere im Fall einer viertelstündigen registrierenden Leistungsmessung – RLM) vorläufig monatlich mit dem Netznutzer ab.
wurde bei Erstellung der Formatangaben ein maximaler Abrechnungszeitraum von einem Jahr zugrunde gelegt. In dem von Ihnen geschilderten Fall werden vermutlich mehrere Jahresrechnungen storniert und es soll nur eine neue Rechnung übertragen werden. Damit würde jedoch ein Zeitraum > 1 Jahr abgerechnet was den o.a. Vorgaben widerspräche. Die Lösung ist aus unserer Sicht also die Übertragung mehrerer Rechnungen, die die identischen Abrechungszeiträume umfassen, wie die stornierten Rechnungen.
Freundiche Grüße,
Ihr BDEW-Forum Datenformate |
Ja
|
Klaus Keller |
Stefan Seidel |
Stefan Seidel |
Bastian Schulz |
|
Nein
|
-------------Klaus Keller-------------12.12.2022 16:14
muss in der AG R/Z besprochen werden
-------------Klaus Keller-------------21.12.2022 17:03
Anpassung nach Protokoll der AG R/Z vm 19.12.22 und Übergabe zur Prüfung an Herrn Seidel
-------------Stefan Seidel-------------21.12.2022 21:22
veröffentlicht
-------------Klaus Keller-------------29.12.2022 16:24
ein paar Rechtschreibfehler korrigiert
|
Nein
|
Nein
|
|
APERAK / CONTRL AHB 2.3k
|
Abgeschlossen
|
Wie können Verstöße gegen Mussfeldbedingungen für Mehrfachwiederholungen abgelehnt werden?
|
Genauso wie Verstöße gegen "einfache" Mussfeldbedingungen, d.h. mit Z29. |
05.12.2022
|
2022-01585 |
|
|
Liebes Formate Team,
im UTILTS AHB Zählzeitdefinitionen 1.0a gibt es die Wiederholungsbedingung
[2002] Segmentgruppe ist mindestens je SG8 SEQ+Z42 (Zählzeitdefinition) zweimal anzugeben.
Das APERAK / CONTRL AHB 2.3k sieht den APERAK Ablehnungsgrund Z40 jedoch laut Seite 56 nur für zu viele Angaben vor.
Dies ist aus meiner Sicht nicht ausreichend.
Freundliche Grüße
Antje Völp
|
2022-12-05 14:01:03 |
Sehr geehrte Fragestellerin,
in diesem Falle wurde die Mussfeldbedingung nicht erfüllt und es kann per:
Z29 = Erforderliche Angabe für diesen Anwendungsfall fehlt
abgelehnt werden.
Freundliche Grüße,
Ihr BDEW-Forum Datenformate |
Ja
|
Klaus Keller |
Stefan Seidel |
Stefan Seidel |
Antje Völp |
|
Nein
|
-------------Klaus Keller-------------12.12.2022 15:58
Antwortvorschlag erstellt
-------------Stefan Seidel-------------12.12.2022 16:40
minimal red. angepasst und veröffentlicht |
Nein
|
Nein
|
|
APERAK / CONTRL AHB 2.3k
|
Abgeschlossen
|
Ist die Reihenfolge von Segmentgruppen auf derselben Hierarchieebene beliebig ?
|
Ja, es muss nicht die Reihenfolge aus der MIG eingehalten werden, sofern es sich um SG auf gleicher Ebene handelt |
05.12.2022
|
2022-01583 |
|
|
Müssen Gruppen- oder Segmentwiederholungen in einer Nachricht direkt aufeinanderfolgen?
Beispiel: In der UTILTS ist die SG8 in verschiedenen Ausprägungen spezifiziert, wobei jede dieser Ausprägungen wiederholt werden kann(BDEW MaxWdh > 1). Konkret empfangen wir eine UTILTS mit mehreren SG8-SEQ+Z42-Gruppen und mehreren SG8-SEQ+Z41-Gruppen. Dürfen diese Gruppen gemischt auftreten, also z.B.
SEQ+Z42'
> [Inhalt der Gruppe]
SEQ+Z41'
> [Inhalt der Gruppe]
SEQ+Z42'
> [Inhalt der Gruppe]
SEQ+Z42'
> [Inhalt der Gruppe]
SEQ+Z41'
> [Inhalt der Gruppe]
usw.
Oder müssen die in der MIG spezifizierten Wiederholungen direkt aufeinanderfolgen, also zuerst alle SG8-SEQ+Z41 und dann alle SG8-SEQ+Z42 (oder umgekehrt)?
Aus der Antwort zum Ticket 2019-00598 geht hervor, dass Reihenfolge der BDEW-Ausprägungen von generischen EDIFACT-Segmenten und Segmentgruppen beliebig ist, so lange die Hierarchie der Nachrichtenstruktur eingehalten wird. Aus der Antwort und den Allgemeinen Festlegungen ist mir jedoch nicht ersichtlich, ob Segment- oder Gruppenwiederholungen auf Ebene der BDEW-Spezifikation gemischt werden dürfen, oder ob diese linear in der jeweiligen Nachricht abgebildet werden muss. Wenn letzteres der Fall ist, wie muss ein Verstoß gegen dieses Ordnungsprinzip per CONTRL gemeldet werden?
|
2022-12-05 10:08:33 |
Sehr geehrter Fragesteller,
die Antwort aus der Frage:
2019-00598
gilt unverändert für Segmentgruppen, da ebendiese ja ebenfalls aus Segmenten bestehen.
Hinweis: Weil EDIFACT genau so funktioniert, wie es funktioniert, muss im konkret angefragten Fall im RFF-Segment der SG8 SEQ+Z41 der Code der Zählzeit genannt sein, um dadurch die Codes der Zählzeitregister (und weiterer Informationen) der Zählzeit zuordnen zu können.
Freundliche Grüße,
Ihr BDEW-Forum Datenformate |
Ja
|
Klaus Keller |
Stefan Seidel |
Stefan Seidel |
Ulrich Schuster |
|
Nein
|
-------------Klaus Keller-------------12.12.2022 15:51
Antwortvorschlag erstellt
-------------Stefan Seidel-------------12.12.2022 16:04
Text: "Hinweis: Weil EDIFACT genau so funktioniert, wie es funktioniert, muss im konkret angefragten Fall im RFF-Segment der SG8 SEQ+Z41 der Code der Zählzeit genannt sein, um dadurch die Codes der Zählzeitregister (und weiterer Informationen) der Zählzeit zuordnen zu können. " ergänzt"
-------------Klaus Keller-------------21.12.2022 10:53
veröffenlicht
|
Nein
|
Nein
|
|
Stammdaten FB 1.1a
|
Eingegangen
|
Wie sind fehlende bzw. leere Elemente in einer XML-Stammdatennachricht zu interpretieren?
|
Diese Elemente werden gelöscht, bzw. mit "leer" überschrieben. |
01.12.2022
|
2022-01580 |
|
|
Guten Morgen,
wie sind fehlende bzw. leere Elemente in einer XML-Nachricht, insbesondere in einer Stammdatennachricht, zu interpretieren?
Hintergrund: Einige Datenelemente sind in der Stammdatennachricht optional, zum Beispiel <MaStR-Nr> oder <Klarname>. Weitere Datenelemente sind aktuell für die Übergangsphase für den EIV noch nicht zwingend erforderlich. Daher kann die Situation entstehen, dass in einer initialen Meldung ein solches Datum angegeben ist, in einer folgenden Änderungsmeldung aber nicht.
Wird in einem solchen Fall das vorher gemeldete Datum unverändert beibehalten, oder wird das entsprechende Feld gelöscht?
Ist es zulässig, leere XML-Elemente anzugeben, also etwa <MaStR-Nr/> bzw. <MaStR-Nr></MaStR-Nr>? Sind diese genauso zu interpretieren wie fehlende Elemente, oder verlangen sie eine Löschung des jeweiligen Datums?
Ist das Löschen einmal übermittelter optionaler Daten überhaupt vorgesehen, und falls ja, wie wird dies kommuniziert?
Danke schon mal & viele Grüße!
|
2022-12-01 10:23:35 |
Sehr geehrte/r Fragesteller/in,
eine Stammdatennachricht beinhaltet immer den vollständigen Datensatz, somit wird der ganze Datensatz mit dem Inhalt der Nachricht überschrieben. Das bedeutet, wenn in einer initialen Stammdatenmeldung ein Datum gemeldet wurde, was in einer folgenden Änderungsmeldung nicht mehr beinhaltet ist, wird dieses Datenfeld mit "leer" überschrieben, bzw. gelöscht.
Leere sowie auch fehlende XML-Elemente einer Stammdatennachricht führen auch zu einem leeren Datenfeld in der Datenbank. War vorher das Datenfeld gefüllt, wird es gelöscht, bzw. mit "leer" überschrieben.
Mit freundlichen Grüßen
Ihr Forum Datenformate |
Ja
|
Sara Olszewski |
Alexander Kramer |
Sara Olszewski |
Oliver Chadenas |
|
Nein
|
in PG besprochen
-------------Katia Schubert-------------25.01.2023 15:04
beantwortet
-------------Sara Olszewski-------------14.02.2023 10:55
|
Nein
|
Nein
|
|
Stammdaten FB 1.1a
|
Abgeschlossen
|
Gibt es Einschränkungen für die Schrittweite der Steuerbarkeit?
|
Fachliche Prüfvorschriften zu inkonsistenten Wertekombinationen gibt es aktuell nicht. |
24.05.2022
|
2022-01387 |
|
|
Mit dieser Version ist ja der Wert 0 für die Schrittweite der Steuerbarkeit im Fall "Schritte" ausgeschlossen worden.
Wie sind aber (auch in Version 1.1) andere unsinnige Wertkombinationen zu interpretieren, z.B. Min= 100, Max=100, Schrittweite=100? Oder Min>Max? Oder Min+Schrittweite > Max?
Ist geplant, weitere Einschränkungen oder Präzisierungen vorzunehmen?
Wo findet sich eine Beschreibung, wie inkonsistene Wertkombinationen zu interpretieren sind oder nach welchen Regeln Werte bei Eingabe zu validieren sind, um solche Kombinationen zu verhindern?
|
2022-05-24 07:14:11 |
Sehr geehrter Fragesteller,
Fachliche Prüfvorschriften zu inkonsistenten Wertekombinationen gibt es aktuell noch nicht und können sich daher in den Formatvorgaben noch nicht wiederzufinden.
Wenn inkonsistente Wertekombinationen auffallen, sind sie im Clearing aufzuklären.
Mit freundlichem Gruß
Ihr BDEW-Forum Datenformate |
Ja
|
Johannes Umbach |
Alexander Kramer |
Johannes Umbach |
Felix Deutsch |
|
Nein
|
Antwortentwurf durch Hr. Kramer vorbereitet
-------------Katia Schubert-------------17.06.2022 15:49
in PG besprochen
-------------Katia Schubert-------------15.09.2022 16:20
|
Nein
|
Nein
|
|
INVOIC / REMADV AHB 2.5
|
Abgeschlossen
|
Wie wird bei einer Forderung das Fälligkeitsdatum betrachtet ?
|
Das Fälligkeitsdatum (hier der Zeitpunkt) gibt den Zeitpunkt an, an dem die Frist endet |
23.11.2022
|
2022-01572 |
|
|
Hallo,
trotz mehrmaligem Lesen eines Beitrages zum Thema Fälligkeit, ist für mich immer noch unklar, wie denn das Feld in der EDIFACT gefüllt sein muss. Daher wäre für mich und möglicherweise auch für andere ein eindeutiges Beispiel sehr hilfreich.
Rechnungsdatum (Gutschrift/Forderung): 23.11.2022
Fälligkeit gemäß 10 WT: 07.12.2022
Wie muss das Feld DTM+265 in diesem Fall (Winterzeit) gefüllt sein?
Variante 1: 202212072300+00
Variante 2: 202212062300+00
|
2022-11-23 13:24:10 |
Sehr geehrter Marktteilnehmer,
in Ihrem Beispiel wird für die Forderung eine Frist von 10 WT verwendet. Wir unterstellen, dass die Rechnung noch am 23.11.2022 beim Empfänger eintrifft und er somit die 10 WT Zeit hat, die ihm gemäß Netznutzungsvertrag mindestens einzuräumen sind um die Rechnung zu bezahlen. Der Zeitraum von 10 WT endet mit Ablauf des 07.12.2022. Das ist der 08.12.2022 00:00 Uhr. Somit ist Variante 1 richtig.
In der EDIFACT-Nachricht ist in UTC somit DTM+265 202212072300+00anzugeben.
Freundliche Grüße
Ihr BDEW-Forum Datenformate |
Ja
|
Klaus Keller |
Stefan Seidel |
Stefan Seidel |
Michael Fuhrer |
|
Nein
|
-------------Klaus Keller-------------21.12.2022 17:25
Anpassung nach Protokoll der AG R/Z vm 19.12.22 und Übergabe zur Prüfung an Herrn Seidel
-------------Stefan Seidel-------------21.12.2022 21:39
ein wenig umgearbeitet. Daher nochmals Herrn Keller zur Draufsicht gegeben
-------------Klaus Keller-------------29.12.2022 16:31
kleine Korrekturen & Veröffentlichung
-------------Stefan Seidel-------------30.12.2022 10:46
minimale red. Korrektur durchgeführt |
Nein
|
Nein
|
|
INVOIC / REMADV AHB 2.5
|
Abgeschlossen
|
In welchem Feld sollen Abschlagsrechnungen für den Ablehnungsgrund AC5 kommuniziert werden?
|
Im gleichen Feld, wie für die Ablehnunggründe "A12/A75/A80" - Fehlerkorrektur ist für den 25.10.22 geplant |
11.10.2022
|
2022-01515 |
|
|
In welchem Feld sollen Abschlagsrechnungen für den Ablehngrund AC5 kommuniziert werden?
Im AHB der REMADV soll bei PI 33003 laut Hinweis 537 die SG7 so oft wiederholt werden bist im RFF alle Rechnungsnummern der Abschlagsrechnungen genannt sind die erwartet wurden.
Das RFF ist aber nur ein Pflichtelement bei den Ablehngründen A12/A75/A80 und laut Hinweis 536 dürfen explizit keine Abschlagsrechnungen angegeben werden.
Das FTX+Z14 ist nur für die Gründe A74/A75/A76 verpflichtend. Im zukünftigen Dokument ist es auch für AC5 verpflichtend also glauben wir das die Information in dieses Feld geschrieben werden soll mit analoger Logik zu den anderen drei Gründen allerdings ist auch im zukünftigen Dokument der Hinweis 537 immer noch falsch.
|
2022-10-11 10:48:20 |
Sehr geehrter Fragesteller,
der von Ihnen erkannte Fehler wurde mit Änderungs-ID 23556 im Rahmen der Lesefassung am 25.10.22 behoben.
Freundliche Grüße,
Ihr BDEW-Forum Datenformate |
Ja
|
Klaus Keller |
Stefan Seidel |
Stefan Seidel |
Daniel Beckers |
|
Nein
|
-------------Klaus Keller-------------18.10.2022 12:20
Vorschlag an Herrn Seidel zur Prüfung übergeben
|
Nein
|
Nein
|
|
INVOIC / REMADV AHB 2.5
|
Abgeschlossen
|
Verwendung Antwortcode AC5 – Ablehnung auf Summenebene 3.2 (kons. Lesefassung vom 19.07.22) für EBD E_0406_Netznutzungsrechnung prüfen und E_0407_erneut_Netzungsabrchnung_prüfen in Schritt 922
|
wurde ergänzt in Fehlerkorrektur vom 25.10.22 |
25.08.2022
|
2022-01465 |
|
|
In den Vorgaben EBD_und_Codelisten Version 3.2 zu E_0406/E_0407 ist in Schritt 922 der Antwortcode AC5 mit zusätzlicher Angabe der Rechnungsnummer aller Abschlagrechnungen, die in der Rechnung erwartet werden.
Dieser Antwortcode AC5 findet sich im INVOIC_REMADV AHB 2.5 (kons.Lesefassung vom 19.07.2022) nur bei Hinweis 537 zu SG7 – Abweichungsgrund (und in der Änderungshistorie unter Punkt 23488). Hier wird darauf verwiesen, das zusätzlich RFF-Segmente mitzugeben sind.
Allerdings findet sich dieser Grund nicht in der Bedingung 36 von SG7-RFF, hier steht allerdings der Hinweis 536, dass in RFF KEINE Abschlagsrechnungsnummer enthalten sein dürfen.
Fehlen hier noch die notwendigen Anpassungen zu dem genannten Antwortcode?
|
2022-08-25 14:17:17 |
Sehr geehrter Marktteilnehmer,
vielen Dank für Ihren Hinweis. Das von Ihnen gemeldete Problem wurde in der Fehlerkorrektur vom 25.10.2022 behoben (Änd-ID: 23556). Freundliche GrüßeIhr Forum Datenformate |
Ja
|
Klaus Keller |
Stefan Seidel |
Klaus Keller |
Bastian Schulz |
|
Nein
|
-------------Klaus Keller-------------21.12.2022 17:33
Veröffentlichung nach Vorgabe AG R/Z
|
Nein
|
Nein
|
|
Unavailability_MarketDocument FB 1.0b
|
Abgeschlossen
|
Was sind die Bezugsgrößen von Nichtbeanspruchbarkeit und marktbedingte Anpassung
|
Im Fall der Übermittlung von Nichtbeanspruchbarkeiten wird die nichtbeanspruchbare Leistung angegeben. Als Bezugsgröße wird die Nettonennleistung genutzt. Im Fall einer marktbedingten Anpassung ist der Wert der Einspeisung anzugeben, auf den die Leistung |
21.11.2022
|
2022-01569 |
|
|
Guten Tag zusammen,
verstehen wir die Beschreibung zum Tag <quantity> innerhalb von <Point> so richtig?
Wenn als <type> A80 (Nichtbeanspruchbarkeit) angegeben ist, so ist der angegebene Leistungswert relativ (als Delta) zu interpretieren; wenn als <type> A67 (marktbedingte Anpassung) angegeben ist, so ist der Leistungswert absolut (als Fahrweise in MW) zu interpretieren.
Was bedeutet in diesem Zusammenhang der Satz "Als Bezugsgröße wird die Nettonennleistung genutzt", bzw. worauf bezieht er sich? Im Fall einer absoluten Angabe in MW spielt die Nennleistung keine Rolle; im Fall einer relativen Absenkung wird laut Text von der zuvor beanspruchbaren Leistung ausgegangen.
Danke im Voraus und viele Grüße!
|
2022-11-21 17:40:55 |
Sehr geehrter Marktteilnehmer,
sinngemäß ist es folgendermaßen zu verstehen.
Die Nichtbeanspruchbarkeiten und marktbedingten Anpassungen werden in Megawatt angegeben.
Im Fall der Übermittlung von Nichtbeanspruchbarkeiten wird die nichtbeanspruchbare Leistung angegeben. Als Bezugsgröße wird die Nettonennleistung genutzt.Im Fall einer marktbedingten Anpassung ist der Wert der Einspeisung anzugeben, auf den die Leistung angepasst werden soll.
Dies soll im Rahmen der nächsten Datenformat-Konsultation präzisiert werden.
Mit freundlichem Gruß
Ihr BDEW Forum Datenformate |
Ja
|
Jennifer Collin |
Stefan Seidel |
Jennifer Collin |
Oliver Chadenas |
Unavailability_MarketDocument FB 1.0
<quantity>
"Hier wird die Leistung in Megawatt angegeben. Es wird
die nichtbeanspruchbare Leistung angegeben, d. h., im
Falle eines „Shutdown“ einer technischen Ressource mit
einer zuvor beanspruchbaren Leistung von 1.000 MW ist
eine Leistung von 1.000 MW anzugeben. Im Fall einer
marktbedingten Anpassung ist der Wert der Einspeisung
anzugeben, auf den die Leistung angepasst werden soll.
Als Bezugsgröße wird die Nettonennleistung genutzt." |
Nein
|
-------------Stefan Seidel-------------21.11.2022 18:49
Antwortvorschlag erstellt.
Die aktuelle Formulierung in der FB ist in der Tat schlecht. Ich brauchte die Änderungshistorie um diese Antwort geben zu können und das ist kein gutes Indiz für die Qualität der FB
-------------Jennifer Collin-------------08.12.2022 10:48
Nur den Text redigiert
in PG besprochen
-------------Katia Schubert-------------13.12.2022 16:16
|
Nein
|
Ja
|
|
ActivationDocument FB 1.0a
|
Eingegangen
|
Welche Bedeutung hat Z06 (Sonderedispatch) im ActivationDocument?
|
Sonder-Redispatch-Maßnahmen sind Redispatch-Maßnahmen, welche außerhalb der gemeldeten freien Redispatch-Vermögen (+RDV und -RDV) abgewickelt werden. |
15.11.2022
|
2022-01564 |
|
|
Ist der Code Z06 im Abrufdokument für den Bilanziellen Ausgleich gedacht und ermöglicht dadurch weitere Abrufe für den selben Zeitschritt durch andere AnfNetzbetreiber?
Sollte ein Abruf mit dem Code Z06 in Verbindung mit einem anderen Reason Code (Bsp. Z05) einen Abruf ermöglichen, welcher über das ausgewiesene Redispatchvermögen hinaus geht, anhand welcher Kriterien kann bestimmt werden, welcher Redispatchabruf mit Z06 für eine Anlage physikalisch möglich ist?
|
2022-11-15 14:54:19 |
Sehr geehrter Fragesteller,die Verwendung von Z06 ist für Maßnahmen wie weitere Abrufe durch anfordernde Netzbetreiber vorgesehen. Da aktuell keine prozessuale Grundlage hierfür vorliegt, wird der Code in der nächsten zu konsultierenden Version entfernt.Freundliche GrüßeIhr Forum Datenformate |
Ja
|
Johannes Umbach |
Henrike Janissen |
Johannes Umbach |
Kai Stredder |
|
Nein
|
-------------Johannes Umbach-------------13.12.2022 13:20
Antwort erstellt
In der AWT muss Z06 zu RD 2.0 raus. Keine Grundlage, siehe Beschluss der 61er FL.
Ggfs. für HAP auch noch raus (Klärung Jenni).
-------------Katia Schubert-------------13.12.2022 16:41
|
Ja
|
Nein
|
|
ActivationDocument FB 1.0a
|
Abgeschlossen
|
Wie ist bei einem Abruf mit der einseitigen Fixierung umzugehen?
|
Die einseitige Fixierung ist als Schranke zu betrachten, die abhängig von der Richtung der Fixierung nicht unter- bzw. überschritten werden darf. |
15.11.2022
|
2022-01562 |
|
|
Wird bei einem Abruf mit dem Code einseitige Fixierung erwartet, das die Anlage den Wert anfährt?
· Bsp.:
Anlage: KWK Anlage meldet über die Planungsdaten ein Prod von 70 kW bei einer max Leistung von 150 kW.
Abruf: Für den beschriebenen Zustand der Anlage kommt ein Abruf ReasonCode = Z 09, Qty = 100 kW
Frage: Soll die Anlage nun die 100 kW anfahren, oder ist dieser Wert nur als neue max Leistung für den geforderten Zeitraum zu blockieren? ( Gleiches Bsp geht auch in die andere Richtung mit Z 10)
|
2022-11-15 14:50:14 |
Sehr geehrter Fragesteller,
die einseitige Fixierung ist als Schranke zu betrachten, die abhängig von der Richtung der Fixierung nicht unter- bzw. überschritten werden darf. In Ihrem Beispiel entsprechen 100 kW der maximal erlaubten Leistung der Anlage. Diese darf aber unterschritten werden und die 100 kW müssen somit nicht angefahren werden.
Freundliche Grüße
Ihr Forum Datenformate |
Ja
|
Johannes Umbach |
Henrike Janissen |
Johannes Umbach |
Kai Stredder |
|
Nein
|
-------------Johannes Umbach-------------13.12.2022 09:47
Antwort erstellt
in PG besprochen
-------------Katia Schubert-------------13.12.2022 16:44
|
Nein
|
Nein
|
|
ActivationDocument FB 1.0a
|
Zur Abstimmung in PG
|
Auf welchen Wert bezieht sich der Abrufwert einer Deltaanweisung?
|
Der Deltaabruf bezieht sich auf die „gemeldete Fahrweise“. |
15.11.2022
|
2022-01561 |
|
|
Bezieht sich ein Abrufwert einer Deltaanweisung auf einen neuen Wert, der durch den vorherigen Abrufwert erzeugt wird (Fahrweise 2), oder beziehen sich Deltaanweisungen immer auf den ausgewiesenen Einspeisewert (Fahrweise 1)?
Bsp.:
Pos. Gemeldete Fahrweise Gemeldetes RDV- Deltaabruf Neue Fahrweise 1 Neue Fahrweise 2
10 300 kW 300 kW 50 kW- 250 kW 250 kW
11 300 kW 300 kW 50 kW- 250 kW 200 kW
12 300 kW 300 kW 50 kW- 250 kW 150 kW
|
2022-11-15 14:43:02 |
Sehr geehrter Fragesteller,der Deltaabruf bezieht sich immer auf die "gemeldete Fahrweise". Die erwartete Fahrweise entspricht der "neuen Fahrweise 1".Freundliche GrüßeIhr Forum Datenformate |
Ja
|
Johannes Umbach |
Henrike Janissen |
Johannes Umbach |
Kai Stredder |
|
Nein
|
Antwort erstellt
-------------Johannes Umbach-------------13.12.2022 21:34
in PG besprochen
-------------Katia Schubert-------------25.01.2023 15:33
|
Nein
|
Nein
|
|
ActivationDocument FB 1.0a
|
Abgeschlossen
|
Wie verhält sich eine Anlage nach einem Abruf?
|
Die Anlage kehrt in ihren vorgesehenen Betriebszustand zurück. |
15.11.2022
|
2022-01560 |
|
|
Wird im allgemeinen davon ausgegangen, dass eine Anlage welche abgerufen wurde, nach Beendigung des Abrufes wieder auf Ihren vorherigen Betriebszustand zurückkehrt?
|
2022-11-15 14:40:37 |
Sehr geehrter Fragesteller,nach einem Abruf wird ein zurückkehren der Anlage in den vorgesehenen Betriebszustand erwartet. Das bedeutet, dass sie bspw. auf den in den Planungsdaten gelieferten Wert oder im Falle einer Anlage im Prognosemodell auf ihre dargebotsabhängige Leistung zurückkehrt. Dabei sind aber auch entsprechende Meldungen von Nichtbeanspruchbarkeiten zu berücksichtigen.Freundliche GrüßeIhr Forum Datenformate |
Ja
|
Johannes Umbach |
Henrike Janissen |
Johannes Umbach |
Kai Stredder |
|
Nein
|
-------------Johannes Umbach-------------13.12.2022 09:41
Antwort erstellt
in PG besprochen
-------------Katia Schubert-------------13.12.2022 16:48
|
Nein
|
Nein
|
|
ActivationDocument FB 1.0a
|
Abgeschlossen
|
Verändert ein Abruf mit "kompletter Fixierung" das zu meldende RDV?
|
Nein, ein Abruf mit "kompletter Fixierung" zieht keine Änderung des RDV nach sich. |
15.11.2022
|
2022-01559 |
|
|
Der Code "Z05" verbietet einen weiteren Abruf, durch einen anderen anfordernden Netzbetreiber, da die "Komplette Fixierung" eine andere Fahrweise verbietet.
Muss in den aktualisierten Planungsdaten das RDV mit 0 ausgewiesen werden wenn nicht das ganze RDV herangezogen wurde, oder wird davon ausgegangen, dass ein anfordernder Netzbetreiber durch den Erhalt des Abrufs keinen zweiten Abruf für den selben Zeitraum einstellt?
|
2022-11-15 14:39:19 |
Sehr geehrter Fragesteller,generell zieht ein Abruf mit "kompletter Fixierung" keine Änderung des RDV nach sich. In Ihrem konkreten Beispiel kann ein zusätzlicher Abruf eines weiteren anfordernden Netzbetreibers dazu führen, dass der erfolgte Abruf mit einer neuen Version durch den anweisenden Netzbetreiber aktualisiert wird.Freundliche GrüßeIhr Forum Datenformate |
Ja
|
Johannes Umbach |
Henrike Janissen |
Johannes Umbach |
Kai Stredder |
Datenpunkt: Position/Reason/ReasonCode; Anwendbarer Code = Z05 |
Nein
|
-------------Johannes Umbach-------------13.12.2022 14:00
Antwort erstellt
in PG besprochen
-------------Katia Schubert-------------13.12.2022 16:26
|
Nein
|
Nein
|
|
ActivationDocument FB 1.0a
|
Abgeschlossen
|
Welche Beudeutung haben die ReasonCodes im ActivationDocument hinsichtlich der erwarteten Aktionen?
|
Die Kombinationen und erwarteten Reaktionen auf die verschiedenen ReasonCodes einer Aktivierung sind in der Hauptantwort genauer beschrieben. |
15.06.2022
|
2022-01395 |
|
|
Frage zur Anwendung der Reason Codes Z05, Z06, Z09, Z10 im ActivationDocument für die ProzessLeitSysteme (PLS) welche die Vorgaben aus dem ActivationDocument ausführen sollen:
Unsere bisherige Auffassung:
Z05 (komplette Fixierung):
a.) ohne RC (keine RDMaßnahme, nur mit Qty=0 plausibel): kein Handlungsbedarf durch das PLS
b.) mit RC und Qty: Qty ist durch das PLS auszuführen
Wie ist aber nun der genaue Ablauf/Kombinationsmöglichkeiten bei Z06, Z09, Z10 und was wird vom PLS erwartet?
Wir bitten um Beschreibung der Anwendungsfälle und Ablaufszenarien für die ReasonCodes Z06 (Mehrfachnennungen möglich) , Z09 und Z10 inklusive der möglichen Kombinationen im ActivationDocument (ACO) und der vom PLS zu erwarteten Aktionen.
|
2022-06-15 11:59:42 |
Sehr geehrter Fragesteller,
folgende von Ihnen erwähnte ReasonCodes sind für den DocumentType A96 (ACO) vorgesehen
Z05 komplette Fixierung
Z06 Sonderredispatch
Z09 einseitige Fixierung nach oben
Z10 einseitige Fixierung nach unten
Generell ist bei einem Abruf in jeder von einem Abruf betroffenen Viertelstunde zwingend die Angabe der entsprechenden Art der Fixierung vorgesehen. Deshalb ist die bei Angabe eines Deltaabrufs der Qty von 0 nur ohne die Angabe eines ReasonCodes plausibel und kennzeichnet somit Zeiträume ohne Aktivierung und somit ist keine Reaktion erforderlich.
Bei einer Aktivierung wird zwischen den folgenden Arten der Fixierung unterschieden, wodurch die Fahrweise der Steuerbaren Ressource währen der Aktivierung eingeschränkt wird:
komplette Fixierung
Die angewiesene Leistung der Steuerbaren Ressource darf während einer Aktivierung weder erhöht noch abgesenkt werden.
einseitige Fixierung nach oben
Die Steuerbare Ressource darf den angeforderten Leistungswert nicht überschreiten. Eine Unterschreitung ist hingegen möglich.
einseitige Fixierung nach unten
Die Steuerbare Ressource darf den angeforderten Leistungswert nicht unterschreiten. Eine Überschreitung ist hingegen möglich.
In Verbindung mit den genannten Codes zur Fixierung kann der Code Z06 im Falle eines Sonderredispatches hinzukommen. Zum Sonder-Redispatch kommt es, wenn die gemeldeten Redispatchvermögen (+RDV und -RDV) nicht ausreichen und zusätzliche Redispatch-Leistung mobilisiert werden muss, welche außerhalb der gemeldeten freien Redispatch-Vermögen liegt.
Freundliche Grüße
Ihr Forum Datenformate |
Ja
|
Johannes Umbach |
Henrike Janissen |
Johannes Umbach |
Markus Birngruber |
<ActivationTimeSeries>
<Period>
<Interval>
<Pos v="1" />
<Qty v="30" />
<Reason>
<ReasonCode v="Z05" />
Z06 (Sonderredispatch), Mehrfachnennungen in Verbindung mit Z06 möglich |
Nein
|
-------------Johannes Umbach-------------22.06.2022 19:25
vorbereitet für PG
in kleiner PG-Besetzung angeschaut.
-------------Katia Schubert-------------15.09.2022 16:28
|
Nein
|
Nein
|
|
ActivationDocument FB 1.0a
|
Abgeschlossen
|
Wie ist das TimeInterval korrekt anzugeben?
|
Es ist yyyy-mm-ddThh:mmZ/yyyy-mm-ddThh:mmZ für TimeInterval zu verwenden. |
23.05.2022
|
2022-01382 |
|
|
Sehr geehrtes Forum Datenformate,
in den Abrufformaten (und anderen Formaten) ist bei TimeInterval ein Pattern und ein Beispiel angegeben. Leider scheint das Beispiel nicht mit dem Pattern übereinzustimmen.
Als Beispiel wird hier:
yyyy-mm-ddThh:mmZ/yyyymm-ddThh:mmZ
angegeben. Das Pattern dazu lautet:
20(\d{2}(\-(0[13578]|1[02])\-(0[1-9]|[12]\d|3[01])|\-02\- (0[1-9]|1\d|2[0-8])|\-(0[469]|11)\-(0[1-9]|[12]\d|30)) |([02468][048]|[13579][26])\-02\-(29))T([01]\d|2[0-3]):[0-5] \dZ/20(\d{2}(\-(0[13578]|1[02])\-(0[1-9]|[12]\d|3[01])|\-02\- (0[1-9]|1\d|2[0-8])|\-(0[469]|11)\-(0[1-9]|[12]\d|30)) |([02468][048]|[13579][26])\-02\-(29))T([01]\d|2[0-3]):[0-5] \dZ
Können Sie bitte klarstellen, wie das TimeInterval korrekt anzugeben ist?
Grüße
Martin Schaumann
|
2022-05-23 17:40:20 |
Sehr geehrter Fragesteller,
für die Angabe des TimeInterval ist die Variante
yyyy-mm-ddThh:mmZ/yyyy-mm-ddThh:mmZ
zu verwenden. Es handelt sich dabei um einen Fehler im Beispiel.
Viele Grüße,
Ihr Forum Datenformate |
Ja
|
Johannes Umbach |
Henrike Janissen |
Johannes Umbach |
Martin Schaumann |
|
Nein
|
In PG besprochen
-------------Katia Schubert-------------30.05.2022 16:34 |
Nein
|
Nein
|
|
PlannedResourceScheduleDocument FB 1.0a
|
Abgeschlossen
|
Hat eine Nichtbeanspruchbarkeit eine Auswirkung auf das Pmin oder das Pmax?
|
Die Nichtbeanspruchbarkeit hat eine Auswirkung auf Pmax, jedoch nicht auf Pmin. |
15.11.2022
|
2022-01563 |
|
|
Hat eine Nichtbeanspruchbarkeit mit dem Code Z11 eine Auswirkung auf das Pmin oder das Pmax?
|
2022-11-15 14:51:08 |
Sehr geehrter Fragesteller,
ja, die Nichtbeanspruchbarkeit hat eine Auswirkung auf Pmax, jedoch nicht auf Pmin.
Freundliche Grüße
Ihr Forum Datenformate |
Ja
|
Martin Schaumann |
Lambert Ashu |
Martin Schaumann |
Kai Stredder |
|
Nein
|
in PG besprochen
-------------Katia Schubert-------------13.12.2022 16:59
|
Nein
|
Nein
|
|
PlannedResourceScheduleDocument FB 1.0a
|
Abgeschlossen
|
Wie ist die Direction bei Sollwertvorgabe zu interpretieren?
|
Die Direction gibt bei Sollwertvorgabe an, ob es sich um einen Einspeise- (A01) oder Entnahmesollwert (A02) handelt. |
11.07.2022
|
2022-01426 |
|
|
Mit der Korrektur vom 23.5. wurde die ARM / GRM-Sollwert-Übermittlung auf Prozent umgestellt:
Bleibt es nach wie vor bei der auf Seite 15 beschriebenen Verwendung des Attributs Direction:
Beispiel: Eine -ARM zu einer SR, die auf 30% abgeregelt werden soll, wird mit den Business Type=A85 und Direction=A02 übermittelt, obwohl das ein positiver Sollwert ist und in der Beschreibung zu Direction steht "Die Direction beschreibt die Richtung des Energieflusses". Im ActivationDocument steht dann Business Type=A85 und Direction=A01 für dieselbe Abregelung, richtig?
Wir würde die -ARM für einen Speicher aussehen? Wie kann man dort zwischen negativen und positiven Sollwerten unterscheiden?
|
2022-07-11 09:02:19 |
Sehr geehrte:r Fragesteller:in,
bei der Sollwertvorgabe gibt die Direction nicht an, ob es sich um eine Erhöhung oder Absenkung handelt, sondern ob es sich um einen Einspeise- (A01) oder Entnahmesollwert (A02) handelt. Die Direction gibt somit nicht die Änderung sondern die Richtung des tatsächlich Energieflusses an.
Die notwendige Erhöhung bzw. Absenkung muss aus dem aktuellen Betriebszustand ermittelt werden.
Anmerkung: Die Beschreibung in der Tabelle auf Seite 15-16 der Formatbeschreibung wird für die Sollwertvorgabe korrigiert. Dies wird vorraussichtlich mit einer Weiterentwicklung erfolgen.
Mit freundlichem Gruß
Ihr Forum Datenformate |
Ja
|
Martin Schaumann |
Gina Völsgen |
Martin Schaumann |
Arnd Krönig |
|
Nein
|
in sehr kleiner PG-Besetzung besprochen :(
-------------Katia Schubert-------------15.09.2022 16:50
|
Nein
|
Nein
|
|
PlannedResourceScheduleDocument FB 1.0a
|
Abgeschlossen
|
Wie ist die TimePeriodCovered bzw. das TimeInterval korrekt anzugeben?
|
Pattern ist korrekt, Beispiel müsste lauten: yyyy-mm-ddThh:mmZ/yyyy-mm-ddThh:mmZ |
23.05.2022
|
2022-01381 |
|
|
Sehr geehrtes Forum Datenformate,
in den Planungsdaten (und anderen Formaten) ist bei TimePeriodCovered sowie auch bei TimeInterval ein Pattern und ein Beispiel angegeben. Leider scheint das Beispiel nicht mit dem Pattern übereinzustimmen.
Als Beispiel wird hier:
yyyy-mm- ddThh:mmZ/yyyy-mmddThh:mmZ
angegeben. Das Pattern dazu lautet:
20(\d{2}(\-(0[13578]|1[02])\-(0[1-9]|[12]\d|3[01])|\-02\- (0[1-9]|1\d|2[0-8])|\-(0[469]|11)\-(0[1-9]|[12]\d|30)) |([02468][048]|[13579][26])\-02\-(29))T([01]\d|2[0-3]):[0-5] \dZ/20(\d{2}(\-(0[13578]|1[02])\-(0[1-9]|[12]\d|3[01])|\-02\- (0[1-9]|1\d|2[0-8])|\-(0[469]|11)\-(0[1-9]|[12]\d|30)) |([02468][048]|[13579][26])\-02\-(29))T([01]\d|2[0-3]):[0-5] \dZ
Können Sie bitte klarstellen, wie die TimePeriodCovered bzw. das TimeInterval korrekt anzugeben ist?
Grüße
Martin Schaumann
|
2022-05-23 17:37:17 |
Sehr geehrter Fragensteller,
vielen Dank für Ihre Frage. DDas in der Formatbeschreibung angegebene Pattern des Elements TimePeriodCovered bzw. TimeInterval ist korrekt. Das dort beschriebene Beispiel ist jedoch fehlerhaft. Korrekterweise müsste es wie folgt lauten:yyyy-mm-ddThh:mmZ/yyyy-mm-ddThh:mmZ
Mit freundlichem Gruß
Ihr BDEW-Forum Datenformate |
Ja
|
Martin Schaumann |
Gina Völsgen |
Martin Schaumann |
Martin Schaumann |
|
Nein
|
In PG besprochen
-------------Katia Schubert-------------30.05.2022 16:34 |
Nein
|
Nein
|
|
Entscheidungsbaum-Diagramme und Codelisten 3.2
|
Abgeschlossen
|
Für die Antwort auf die Gerätewechselabsicht fehlt uns die Möglichkeit, die Nachricht abzulehnen, falls uns keine Kündigung vorliegt
|
Aktuell bleibt Ihnen lediglich die Ablehnung: Z07 |
14.11.2022
|
2022-01556 |
|
|
Liebes Forum,
als wMSB erhalten wir ab und an die Meldungen "Anzeige Gerätewechselabsicht" mit PID 17009 ohne einen Start des Prozesses "Ende MSB". Wir erwarten in diesem Fall eine Nachricht "Kündigung MSB" mit PID 11039. Eine Kündigung seitens Anschlussnutzer liegt in solchen Fällen auch nicht vor.
Für die Antwort auf die GWA fehlt uns aber die Möglichkeit, die Nachricht abzulehnen, falls uns keine Kündigung vorliegt. Wie sollen wir in so einem Fall antworten? Ist die Ausarbeitung der Codelisten G_0059, G_0060, S_0065, S_0066 zu einem Entscheidungsbaum geplant?
Vielen Dank
|
2022-11-14 10:35:14 |
Sehr geehrter Marktteilnehmer,vielen Dank für Ihre Frage. Die Verwendung des Use-Case „Gerätewechsel“ bedingt einen vorangegangenen MSB-Wechsel (Use-Case „Beginn Messstellenbetrieb“ oder Use-Case „Verpflichtung gMSB“). Aktuell bleibt Ihnen lediglich die Ablehnung: Z07 Ablehnung (Keine Berechtigung) Der Absender lehnt die Transaktion ab. Der Absender des Vorganges ist nicht berechtigt, eine solche Willenserklärung abzugeben.
Codelisten werden sukzessive durch EBD ersetzt. Neue Prozesse statten wir gleich mit einem EBD aus.
Freundliche GrüßeIhr Forum Datenformate |
Ja
|
Matthias Braun |
Vanessa Stemplowsky |
Vanessa Stemplowsky |
Oleg Pavlov |
|
Nein
|
In PG erstellt und besprochen
-------------Vanessa Stemplowsky-------------20.12.2022 13:34
|
Nein
|
Nein
|
|
Entscheidungsbaum-Diagramme und Codelisten 3.2
|
Abgeschlossen
|
Ein Rechnungsersteller sendet eine Rechnung kurz vor dem 01.10.2022 an den Rechnungsempfänger und ist der Auffassung, dass der Rechnungsempfänger die Rechnung nach dem alten Schema hätte prüfen müssen.
|
Zur Prüfung aller Netznutzungsrechnungen, die ab dem 1. Oktober 2022, 00:00 Uhr beantwortet werden, ist das EBD „E_0406_Netznutzungsrechnung prüfen“ zu nutze |
25.10.2022
|
2022-01533 |
|
|
Guten Tag,
folgendes Szenario:
Ein Rechnungsersteller sendet eine Rechnung kurz vor dem 01.10.2022 an den Rechnungsempfänger. Der Rechnungsempfänger nimmt diese Rechnung entgegen und quittiert den Empfang mit einer positiven CONTRL.
Die eigentliche Verarbeitung erfolgte jedoch erst nach dem 01.10.2022. Entsprechend des Einführungsszenarios wurde das ab 01.10.2022 gültige EBD zur Prüfung der Rechnung verwendet, da dieses EBD zur Beantwortung aller Rechnungen verwendet werden muss, welche ab dem 01.10.2022 beantwortet werden.
Genau diesen Umstand moniert der Rechnungsersteller nun, da die Prüflogik des ab dem 01.10.2022 gültigen EBD zu einem Nichtzahlungsavis geführt hat. Der Rechnungsersteller ist der Auffassung, dass der Rechnungsempfänger die Rechnung nach dem alten Schema hätte prüfen müssen.
Gibt es eine Festlegung welche die eine oder andere Vorgehensweise rechtfertig oder liegt es im Ermessen des Empfängers wann er eine Rechnung (natürlich innerhalb der Fristen) bearbeitet?
Für die Beantwortung der Fragen besten Dank.
|
2022-10-25 14:06:34 |
Sehr geehrter Marktteilnehmer,
vielen Dank für Ihre Frage. Zur Prüfung aller Netznutzungsrechnungen, die ab dem 1. Oktober 2022, 00:00 Uhr beantwortet werden, ist das EBD „E_0406_Netznutzungsrechnung prüfen“ zu nutzen (siehe Änd-ID 50501 vom 19. Juli 2022).
Dies ist ein Beispiel, das auf folgender Grundregel basiert: Es gelten immer die zum Versandzeitpunkt gültigen Dokumente. Dabei ist es unerheblich zu welchem Zeitpunkt die Ursprungsnachricht eingegangen ist.
Freundliche GrüßeIhr Forum Datenformate |
Ja
|
Matthias Braun |
Vanessa Stemplowsky |
Vanessa Stemplowsky |
Ronald Damm |
6.7.1. Zur Prüfung aller Netznutzungsrechnungen, die ab dem 1. Oktober 2022, 00:00 Uhr beantwortet werden, ist das EBD „E_0406_Netznutzungsrechnung prüfen“ zu nutzen. |
Nein
|
In PG Besprochen
-------------Vanessa Stemplowsky-------------20.12.2022 13:23
|
Nein
|
Nein
|
|
Entscheidungsbaum-Diagramme und Codelisten 3.2
|
Abgeschlossen
|
Wie können wir nach Wegfall des A99 im E_0462 eine Anmeldung E01 E02 (Neuanlage) für Marktlokationen der Sparte Strom die zu dem gemeldeten Anmeldedatum keine Neuanlagen sind ablehnen?
|
Aufgrund des gemeldeten Umstands ist die Anmeldung nicht direkt ablehnbar. |
18.10.2022
|
2022-01522 |
|
|
Wir erhalten von Marktpartnern in regelmäßigen Abständen Anmeldungen E01 E02 (Neuanlage) für Marktlokationen der Sparte Strom die zu dem gemeldeten Anmeldedatum keine Neuanlagen sind.
Beim Durchlaufen der Prüfschritte des Kapitel 6.4.1 müssen wir feststellen, dass wir mit der korrekten Beantwortung der Fragestellungen in einer Sackgasse landen, da das Ergebnis der Prüfungen der Prüfschritt 23 ist.
Da es nunmehr mit EBD E_0402_Prüfen weitergeht und wir als NB das Erfordernis einer Abmeldeanfrage nicht prüfen können, da der Prüfidentifikator 11010 bei E01 E02 nicht für Abmeldeanfragen verwendet werden darf, Fragen wir uns wie wir eine solche Anmeldung beantworten sollen?
Bis 30.09.2022 gab es für etwaige Ungereimtheiten A99 (Sonstiges) inklusive Bemerkung als Antwortgrund. Dieser Antwortgrund ist seit 01.10.2022 ersatzlos entfallen.
Der in der GPKE genannte Hinweis für die Bearbeitung des Falls "Neuanlage", dass bei gelungener Zuordnung zu einer Marktlokation der NB das vom LF genannte voraussichtliche Anmeldedatum durch das Inbetriebnahmedatum der Marktlokation ersetzt, ist nicht anwendbar.
Lieferant meldet E02 für den 15.10.2022 mit Kunde B.
Marktlokation war Neuanlage am 23.05.2022 mit Kunde A.
|
2022-10-18 13:37:03 |
Sehr geehrter Marktteilnehmer,
aufgrund des gemeldeten Umstands ist die Anmeldung E01 E02 (Neuanlage) für Marktlokationen der Sparte Strom, die zu dem gemeldeten Anmeldedatum keine Neuanlagen sind, nicht direkt ablehnbar. In der notwendigen Abmeldeanfrage ist der Transaktionscode E01 gemäß UTILMD Anwendungshanddbuch zur GPKE und GELi Gas zu verwenden - siehe Hinweis [644].
Mit freundlichen Grüßen
Ihr BDEW-Forum Datenformate |
Ja
|
Matthias Braun |
Vanessa Stemplowsky |
Vanessa Stemplowsky |
Steve Hille |
EBD Kapitel 6.4.1 (Seite 38 - 42)
UTILMD AHB GPKE/GeLi Gas Prüfidentifkator 11010 (Seite 95 - 96)
GPKE Kapitel 4 (Seite 32 - 33) |
Nein
|
Frage bearbeitet
-------------Vanessa Stemplowsky-------------26.10.2022 10:30
Frage veröffentlicht
-------------Vanessa Stemplowsky-------------26.10.2022 13:36
|
Nein
|
Nein
|
|
Entscheidungsbaum-Diagramme und Codelisten 3.2
|
Abgeschlossen
|
Warum ist im EBD E_0503 vorgesehen, dem Marktpartner immer beide Leistungen (Unterbrechung und Wiederherstellung der Anschlussnutzung) gleichzeitig in Rechnung zu stellen?
|
Der beauftragende Lieferant trägt die Kosten der Sperrung und Entsperrung einer Marktlokation im Rahmen der Sperrung. |
06.09.2022
|
2022-01473 |
|
|
Bei uns ist eine Rückfrage zum EBD „E_0503_Rechnung einer sonstigen Leistung prüfen“ aufgekommen: Warum ist in dem Prozess vorgesehen dem Marktpartner immer beide Leistungen (Unterbrechung und Wiederherstellung) gleichzeitig in Rechnung zu stellen? (siehe Schritt 22, Seite 174)
Zwischen Sperrung und Wiederinbetriebnahme kann in manchen Fällen auch etwas mehr Zeit vergehen, sodass hier eine unbekannte Zahlungsfrist für die Bezahlung des Sperrauftrags entsteht. Besonders ungünstig wäre es, wenn der Kunde gesperrt wird und vor Ausführung der Wiederinbetriebnahme ein Lieferantenwechsel stattfindet. In diesem Szenario müsste die Sperrung dem ehemaligen Lieferanten und die Wiederinbetriebnahme dem neuen Lieferanten in Rechnung gestellt werden. Dies ist nicht möglich, wenn in der INVOIC zwangsläufig die Artikel-IDs für Sperrung und Wiederherstellung enthalten sein müssen.
Wir bitten um Stellungnahme. Vielen Dank.
|
2022-09-06 10:50:56 |
Sehr geehrter Marktteilnehmer,
gemäß neuem Lieferantenrahmenvertrag Strom (siehe § 10 Abs. 6) trägt der jeweils beauftragende Lieferant die Kosten der Sperrung und Entsperrung einer Marktlokation und zwar unabhängig davon, ob der beauftragende Lieferant auch zu einem späteren Zeitpunkt die betroffene Marktlokation beliefert.
Gemäß Vorbedingung des "UC: Wiederherstellung der Anschlussnutzung (Entsperren) auf Anweisung des LF" der GPKE werden die Kosten der Entsperrung dem LF im Rahmen der Sperrung berechnet.
Dieses Vorgehen ist in Marktprozessen zur Marktkommunikation 2022 bzw. deren technischen Umsetzung in den Entscheidungsbaum-Diagrammen bzw. Datenformaten abgebildet.
Mit freundlichen Grüßen
Ihr BDEW-Forum Datenformate |
Ja
|
Matthias Braun |
Nicolas Gassen |
Matthias Braun |
Michalina Rathert |
EBD „E_0503_Rechnung einer sonstigen Leistung prüfen“
Seite 174, Schritt 22
Werden in der Rechnung die beiden Artikel-IDs
[2-01-7-001] (Unterbrechung der Anschlussnutzung in der
regulären Arbeitszeit) und
[2-01-7-002] (Wiederherstellung der Anschlussnutzung in
der regulären Arbeitszeit) abgerechnet? |
Nein
|
Weiterleitung an Fr. Frein
-------------Matthias Braun-------------08.09.2022 13:06
Antwortvorschlag von Christina Frein eingearbeitet
-------------Matthias Braun-------------14.09.2022 11:40
Vorbedingung der GPKE eingearbeitet
-------------Matthias Braun-------------20.09.2022 10:18
|
Nein
|
Nein
|
|
MSCONS AHB 3.1a
|
In Bearbeitung
|
Ist die Anpassung/Änderung des Brennwertbezirks einer Malo eine Parameteränderung, die mittels MSCONS inkl. Referenz auf eine SDÄ erfolgen muss?
|
Es erfolgt keine Änderung der Messtechnik. Es ist ein Zwischenstand mit DTM+7 und DTM+9 im LIN zu übermitteln. |
07.11.2022
|
2022-01544 |
|
|
Im Rahmen einer eichrechtlichen Anordnung wird eine Malo zum 1.10.2022 aus dem Brennwertbezirk 1 in den Brennwertbezirk 2 verschoben. Zur abrechnungstechnischen Abgrenzung muss ein Zählerstand ermittelt werden und dem Lieferanten mitgeteilt werden. Es erfolgt keine techn. Änderung am Gerät der Messlokation.
Ist der ermittelte Zählerstand (in aller Regel rechn. Abgrenzung mit zwei MSCONS und SDÄ
• DTM+7 Gültigkeitsdatum
• DTM+60 Konstrutionsänderungsdatum
• RFF+Z30 Referenz auf vorherige Stammdatenmeldung des MSB
und SDÄ ohne Änderung
oder mit einer MSCONS als Zwischenablesung mit
• DTM+7 Gültigkeitsdatum
• DTM+9 Verarbeitungsdatum
zu übertragen?
|
2022-11-07 13:29:16 |
Da bei der neuen Zuordnung eines Brennwertbezirkes keine direkte Änderung an der Messtechnik erfolgt, ist die Übermittlung eines Zählerstandes in Form einer Zwischenablesung an den Lieferanten zu übertragen. Hierzu werden im LIN die Segmente DTM+7 und DTM+9 genutzt. Brennwert und Zustandszahl sind in weiteren LIN-Segmenten zu übertragen. Da der Brennwertbezirk kein Stammdatum ist, ist eine Stammdatenänderung nicht möglich.
Bei tatsächlicher Änderung an der Messtechnik (z.B. Zählerwechsel) ist die Übermittlung einer Stammdatenänderung erforderlich. Hier wird bis zur Änderung mit Referenz auf die Stammdatenänderung der Zählerstand mit den Segmenten DTM+7 und DTM+60, Brennwert und Zustandszahl mit einzelnen LIN-Segmenten übermittelt. Danach erfolgt die Übermittlung des Zählerstands nach Änderung mit den Segmenten DTM+7 und DTM+60 ohne Brennwert und Zustandszahl. |
Ja
|
Reinhard Döring |
Thomas Seipt |
Reinhard Döring |
Carsten Fröse |
|
Nein
|
|
Nein
|
Nein
|
|
MSCONS AHB 3.1a
|
Abgeschlossen
|
Welches Datumsformat ist für das Ablesedatum eines Zählerstands zu nutzen?
|
Das verwendete Datumsformat hängt von der Erfassung des Zählerstandes ab |
04.11.2022
|
2022-01541 |
|
|
Wir sind in der Marktrolle Lieferant tätig und erkennen zurzeit den unterschiedlichen Umgang mit Zählerständen in den Sparten Strom und Gas.
Ab dem 01.10.2022 00:00 Uhr kann das Ablesedatum für Zählerstände in den Sparten Strom und Gas tagesgenau (Code 102) oder minutengenau (Code 303) übermittelt werden. Es ist aus keinem EDI@Energy Dokument für uns klar ersichtlich, in welchen Fällen das Ablesedatum nur mit einem Datum (Code 102) und in welchen Fällen zusätzlich zum Datum eine Uhrzeit (Code 303) zu nutzen ist.
In einigen Geschäftsvorfällen der MSCONS zur Übermittlung eines Zählerstandes ist das Ablesedatum immer identisch mit dem Nutzungszeitpunkt, nämlich in der Sparte Strom 00:00 Uhr eines Tages und in der Sparte Gas 06:00 Uhr eines Tages.
Könnten Sie bitte präziseren, welche Information im Segment Ablesedatum (DTM+9) und in welcher Granularität (Code 102 oder 303) diese zu übermitteln ist? Oder kann standardmäßig immer der Code 303 genutzt werden? Darf die für Messwerte verantwortliche Marktrolle, der MSB in der Sparte Strom oder der NB in der Sparte Gas, zu einem erhaltenden Zählerstand mit einem Ablesedatum ohne Uhrzeit, irgendeine Uhrzeit auswählen und zum Ablesedatum hinzufügen?
Vielen Dank
|
2022-11-04 08:30:31 |
Sehr geehrter Marktteilnehmer,
in der Nachrichtenbeschreibung der MSCONS 2.4a ist der folgende Hinweis unter dem Segment Ablesedatum vorhanden:
[...]Hiermit wird angegeben, wann der Messwert tatsächlich abgelesen wurde. Liegt lediglich ein Datum ohne Uhrzeit vor, so ist in DE2379 der Code 102 zu verwenden. Liegt ein genauer Ablesezeitpunkt vor, so ist in DE2379 der Code 303 zu verwenden. [...]
Liegt die Information nicht vor, zu welcher Uhrzeit (Zeitpunkt an einem Tag) der Zählerstand tatsächlich erfasst wurde, ist im Geschäftsvorfall der Code 102 zu nutzen. Eine Anreicherung einer Uhrzeit (z. B. die pauschale Nutzung von 00:00 Uhr) darf nicht erfolgen, da die Information „verfälscht“ werden würde.
Liegt die Information, zu welchem Zeitpunkt der Zählerstand z. B. von Endkunden oder einem Ableser erfasst wurde vor (z. B. durch die Uhrzeitangabe auf einer Ablesekarte), muss der Code 303 genutzt und der korrekte Zeitpunkt den Empfängern mitgeteilt werden.
Eine standardmäßige Nutzung des Codes 303 für alle Ablesedaten ist aus fachlicher Sicht nicht sinnvoll. Zudem darf das Ablesedatum nicht standardmäßig auf den Nutzungszeitpunkt verlegt werden, außer die Ablesung wurde tatsächlich um 00:00 Uhr in der Sparte Strom und 06:00 Uhr in der Sparte Gas eines Tages durchgeführt.
Übermittelt der LF einen Zählerstand mit einem Ablesedatum ohne Uhrzeit (Code 102), darf das Ablesedatum vom Messwertverantwortlichen nicht verfälscht werden, indem irgendeine Uhrzeit zum Ablesedatum hinzugefügt wird. In diesem Fall hat der MSB in der Weiterleitung an die berechtigten den Zählerstand ebenfalls ohne eine Zeitangabe (Code 102) zu übermitteln. Das identische Vorgehen betrifft auch den NB in der Sparte Gas.
Mit freundlichen Gruß
Ihr BDEW-Forum Datenformate |
Ja
|
Reinhard Döring |
Thomas Seipt |
Gregor Scholtyschik |
Gregor Scholtyschik |
|
Nein
|
Frage wurde in der Sitzung 03.11.2022 besprochen und freigegeben.
-------------Gregor Scholtyschik-------------04.11.2022 08:31
|
Nein
|
Nein
|
|
Codeliste der Messprodukte 1.0
|
Eingegangen
|
Was ist der Unterschied zwischen den Messprodukten im Kapitel 2.1.1?
|
Die Unterscheidung liegt in der Wertegranularität |
03.11.2022
|
2022-01540 |
|
|
Warum gibt es in der Rubrik 3.3 Erforderliche Werte und zulässige OBIS-Kennzahlen
3.3.1 auf Ebene der Marktlokation Lieferrichtung Verbrauch - zugeordnete Zählzeit nicht vorhanden
die vier Messprodukt Codes 9991000000044, 9991000000490, 9991000000052 und 9991000000060 mit dem identischen Hinweis Wirkarbeit Bezug (+) Vorschub total, tariflos mit OBIS-Kennzahl 1-b:1.9.0.
Wie unterscheiden sich diese Messprodukte?
|
2022-11-03 17:25:41 |
Hallo,
die Unterscheidung der vier Messprodukte liegt in der Angabe der Wertegranularität: jährlich, halbjährlich, quartalsweise und monatlich. Die Wertegranularität gibt hier an, in welchem Abstand das Messprodukt versendet werden soll.
Mit freundlichen GrüßenIhr Forum Datenformate |
Ja
|
Thomas Fellhauer |
Thomas Seipt |
Thomas Fellhauer |
Melanie Täge |
|
Nein
|
beantwortet und veröffentlicht
-------------Thomas Seipt-------------03.11.2022 17:28
|
Nein
|
Nein
|
|
PRICAT AHB 2.0a
|
Eingegangen
|
Ist in PRICAT ist die Bedingung [942] Format: n1-n2-n1-n3 fehlerhaft?
|
Fehlerkorrektur vom 25.10.2022 des Dokuments "Codeliste der Artikelnummern und Artikel-ID" |
25.10.2022
|
2022-01532 |
|
|
Guten Tag,
zum 13.09.2022 wurde die Codeliste der Artikel-ID geändert und neue Artikelnummern aufgenommen:
Änderungs-ID: 23526
[...]
1-10-10
1-10-10-001
1-10-10-002
Leider wurde in dem Zuge das PRICAT AHB für Prüfi 27003 nicht angepasst für LIN Produktnummer 7140, die Bedingung im AHB [942) lautet: Format: n1-n2-n1-n3
Korrekt müsste die Bedinung nun aber lauten: Format: n1-n2-n1-n3 und n1-n2-n2-n3
So laufen nun leider die PRICAT mit den neuen Artikelnummern automatisch auf Formatfehler und werden per APERAK von unserem System abgewiesen.
Kann das bitte kurzfristig korrigiert werden? Es beschweren sich reichlich Netzbetreiber, dass sie trotz korrekter Artikel-ID die APERAK erhalten. Da die Formatprüfung nach AHB hinterlegt ist, können wir das aber nicht einfach so rausnehmen.
Vielen Dank.
|
2022-10-25 11:01:13 |
Hallo,
vielen Dank für den Hinweis. Dieser Widerspruch zwischen PRICAT und Artikel-ID wurde mit der Fehlerkorrektur vom 25.10.2022 des Dokuments "Codeliste der Artikelnummern und Artikel-ID" behoben (Änderungs-ID: 23602).
Mit freundlichen GrüßenIhr Forum Datenformate |
Ja
|
Thomas Seipt |
Klaus Keller |
Thomas Seipt |
Ramona Pantani |
Codeliste der Artikelnummern und Artikel-ID Fassung vom 13.09.2022, Änderungs-ID: 23526
PRICAT AHB Fassung vom 03.06.2022, Seite 14, SG36 LIN 7140 |
Nein
|
|
Nein
|
Nein
|
|
IFTSTA AHB 2.0d
|
Abgeschlossen
|
Prüfung der Bedingung [495] „Der Zeitpunkt muss ≤ dem Wert im DE2380 des DTM+137 sein“ in der IFTSTA.
|
Die realen Zeiträume sind beim Vergleich der Zeitpunkte unterschiedlicher Granularität zu berücksichtigen. |
25.10.2022
|
2022-01531 |
|
|
Sehr geehrtes Forum,
die Bedingung am Datenelement 2380 von SG 6 (Zeitpunkt der Statusvergabe) DTM+334 sagt, dass der hier angegebene Zeitpunkt ≤ dem Erstellungsdatum sein muss, welches im Segment DTM+137 (Dokumentendatum) angegeben ist.
Da die Statusvergabe und der Versand oft sehr nahe bei einander liegen, sind dies dem entsprechend auch die Zeitangaben. Uns werden Statusmeldungen aufgrund dieser Bedingung abgelehnt, wenn der Zeitpunkt der Statusvergabe und der Zeitpunkt der Erstellung der EDIFACT Nachricht innerhalb der gleichen Minute liegt. Ursache ist wohl, dass der Zeitpunkt der Statusvergabe sekundengenau erfolgt, der Zeitpunkt des Dokumentendatums aber nur minutengenau.
Frage: Ist die Ablehnung berechtigt, oder hätte hier nicht der Zeitbereich der unterschiedlichen Genauigkeiten beachtet werden müssen.
|
2022-10-25 08:50:53 |
Sehr geehrter Marktteilnehmer,
vielen Dank für ihre Frage, die Ablehnung ist nicht berechtigt. Die unterschiedlichen Genauigkeiten der beiden Zeitpunktangaben sind im Rahmen des Vergleichs der beiden Zeitpunkte zu berücksichtigen.
Alle Computersysteme stellen Zeitangaben in einer Genauigkeit von Sekunden oder höherer Genauigkeit zur Verfügung. Um ein Datenelement mit einer Zeitangabe zu befüllen, muss der entsprechende Zeitpunkt auf die geforderte Genauigkeit angepasst werden. Durch die Angabe einer Uhrzeit wird daher kein Zeitpunkt im mathematischen Sinne angegeben, sondern ein Zeitbereich, dessen Ausdehnung durch die Genauigkeit der Zeitangabe bestimmt wird. Die EDI@Energy-Dokumente beinhalten keine Vorgaben wie diese Anpassung erfolgen muss, da dies die interne Arbeitsweise des jeweiligen Marktteilenehmers betrifft. Zu klären ist somit lediglich wie zu verfahren ist, wenn ein Zeitpunkt höherer Genauigkeit (und damit geringerer zeitlichen Ausdehnung, also kleinem Zeitbereich) innerhalb des Zeitpunkts geringerer Genauigkeit (und damit größerer zeitlichen Ausdehnung, also größerem Zeitbereich) liegt.
In der Bedingung [495] wird das Vergleichszeichen ≤ verwendet. Die Bedingung ist somit nicht erfüllt, wenn der Zeitpunkt höherer Genauigkeit größer als der Zeitpunkt geringerer Genauigkeit ist. Das ist nur dann der Fall, wenn der Zeitpunkt höherer Genauigkeit nicht im Zeitbereich des Zeitpunkts geringerer Genauigkeit liegt. Wie dieser Vergleich in den IT-Systemen der Markteilnehmer umgesetzt wird, ist nicht durch EDI@Energy vorzugeben, da auch dies wiederum die interne Arbeitsweise des jeweiligen Marktteilnehmers betrifft. Jeder Marktteilnehmer hat nur sicherzustellen, dass bei seiner Umsetzung des Vergleichs zweier Zeitpunkte unterschiedlicher Genauigkeit die unterschiedlichen Ausdehnungen (= unterschiedlich großen Zeitbereiche) der Zeitpunkte richtig berücksichtigt werden.
Bild zur Illustration:
Beispiele:
DTM+334
DTM+137
DTM+334 ≤ DTM+137
01.01.2022 12:00:30
01.01.2022 12:01
WAHR
01.01.2022 12:00:59
01.01.2022 12:01
WAHR
01.01.2022 12:01:00
01.01.2022 12:01
WAHR
01.01.2022 12:01:01
01.01.2022 12:01
WAHR
01.01.2022 12:01:33
01.01.2022 12:01
WAHR
01.01.2022 12:01:59
01.01.2022 12:01
WAHR
01.01.2022 12:02:00
01.01.2022 12:01
FALSCH
01.01.2022 12:02:01
01.01.2022 12:01
FALSCH
DTM+334
DTM+137
DTM+334 ≤ DTM+137
01.01.2022 12:00:30
01.02.2022 12:01
WAHR
01.01.2022 12:00:59
01.02.2022 12:01
WAHR
01.01.2022 12:01:00
01.02.2022 12:01
WAHR
01.01.2022 12:01:01
01.02.2022 12:01
WAHR
01.01.2022 12:01:33
01.02.2022 12:01
WAHR
01.01.2022 12:01:59
01.02.2022 12:01
WAHR
01.01.2022 12:02:00
01.02.2022 12:01
WAHR
01.01.2022 12:02:01
01.02.2022 12:01
WAHR
DTM+334
DTM+137
DTM+334 ≤ DTM+137
01.02.2022 12:00:30
01.01.2022 12:01
FALSCH
01.02.2022 12:00:59
01.01.2022 12:01
FALSCH
01.02.2022 12:01:00
01.01.2022 12:01
FALSCH
01.02.2022 12:01:01
01.01.2022 12:01
FALSCH
01.02.2022 12:01:33
01.01.2022 12:01
FALSCH
01.02.2022 12:01:59
01.01.2022 12:01
FALSCH
01.02.2022 12:02:00
01.01.2022 12:01
FALSCH
01.02.2022 12:02:01
01.01.2022 12:01
FALSCH
DTM+334
DTM+137
DTM+334 ≤ DTM+137
01.01.2022 23:59:30
01.02.2022 00:00
WAHR
01.01.2022 23:59:59
01.02.2022 00:00
WAHR
01.02.2022 00:00:00
01.02.2022 00:00
WAHR
01.02.2022 00:00:01
01.02.2022 00:00
WAHR
01.02.2022 00:00:33
01.02.2022 00:00
WAHR
01.02.2022 00:00:59
01.02.2022 00:00
WAHR
01.02.2022 00:01:00
01.02.2022 00:00
FALSCH
01.02.2022 00:01:01
01.02.2022 00:00
FALSCH
Freundliche Grüße
Ihr BDEW-Forum Datenformate |
Ja
|
Carsten Fröse |
Sven Schillack |
Jessica Rahn |
Jessica Rahn |
|
Nein
|
-------------Jessica Rahn-------------25.10.2022 08:56
Frage aus EDI, Abstimmung Hr. Seidel, Hr. Katzenbach, Hr. Stegmüller, Frau Becker.
Letzten beiden Datumsfelder lt. Hr. Fröhse nicht ok.
|
Nein
|
Nein
|
|
PRICAT MIG 2.0a
|
Abgeschlossen
|
Wie ist die Eindeutigkeit des Preisblatts gewährleistet?
|
Die Eindeutigkeit der Preisblätter eines Marktpartners wird über das BGM 1004 sichergestellt. |
21.10.2022
|
2022-01525 |
|
|
Sehr geehrte Damen und Herren,
auf Seite 6 heißt es zum BGM 1004 (EDI-Nachrichtennummer):
Die Eindeutigkeit eines Preisblatts für das Sperren / Entsperren, die Verzugskosten, die Netznutzung ohne gemeindespezifische
Konzessionsabgaben, Netznutzung: Gemeindespezifische Konzessionsabgaben und die Blindarbeit ist durch die EDINachrichtennummer gegeben, d. h. den Inhalt von DE1004 des BGM-Segments.
Heißt dass, dass das Segment über alle GPKE-PRICAT-Nachrichten eindeutig sein muss oder muss die Eindeutigkeit jeweils für eine Preisblatt-Kategorie eindeutig sein?
Vielen Dank und viele Grüße
Stefan Riemer
|
2022-10-21 10:26:31 |
Hallo,
ja der Sender eines Preisblatts hat sicherzustellen, dass alle von ihm erzeugten Preisblätter über die Dokumentennummer (BGM 1004) zu unterscheiden sind und damit eindeutig sind.
Mit freundlichen GrüßenIhr Forum Datenformate |
Ja
|
Thomas Seipt |
Klaus Keller |
Thomas Seipt |
Stefan Riemer |
Seite 6:
Die Eindeutigkeit eines Preisblatts für das Sperren / Entsperren, die Verzugskosten, die Netznutzung ohne gemeindespezifische
Konzessionsabgaben, Netznutzung: Gemeindespezifische Konzessionsabgaben und die Blindarbeit ist durch die EDINachrichtennummer gegeben, d. h. den Inhalt von DE1004 des BGM-Segments. |
Nein
|
Vorschlag formuliert
-------------Thomas Seipt-------------03.11.2022 17:39
Geprüft und veröffentlicht
-------------Klaus Keller-------------07.11.2022 16:35
|
Nein
|
Nein
|
|
Allgemeine Festlegungen 6.0a
|
Abgeschlossen
|
Wie ist mit den Angaben in den DTM Segmenten umzugehen, welche den Formatcode 303 nutzen?
|
Umgang mit den Angaben in den DTM Segmenten welche den Formatcode 303 nutzen |
20.10.2022
|
2022-01524 |
|
|
Im Stammdatenaustausch kommt es seit dem 01.10.2022 zu unterschiedlichen Anwendungen / Interpretationen des Datumsformates 303 in den DTM-Segmenten.
Es erweckt den Anschein, dass einige Marktteilnehmer die im DTM-Segment angegebenen Uhrzeiten ignorieren und lediglich das Datum (also Tag Monat Jahr) verwenden.
Beispiel:
In dem Geschäftsvorfall wird das folgende im DTM angeben
DTM+93:202212312300?+00:303'
Unsere Interpretation ist die folgende:
Es handelt sich um den Zeitpunkt 31.12.2022 23:00 Uhr UTC
In gesetzlich deutscher Zeit ist dies der Zeitpunkt 01.01.2023 00:00 Uhr
Das Ignorieren der Uhrzeit wird von einigen vor der „Umrechnung“ in die Lokale Zeitzone (gesetzliche deutsche Zeit), von wiederum anderen nach der „Umrechnung“ durchgeführt.
Je nach Umsetzung in den IT-Systemen, wird entweder das Datum 31.12.2022 oder das Datum 01.01.2023 errechnet.
Im Weiteren wird dann über die Information aus der DTM Beschreibung ein Tagesanfang bzw. ein Tagesende abgeleitet. So wie dies vor der Angabe eines Zeitpunkts nötig war.
Daraus können sich dann die verschiedensten Situationen ergeben.
Beispiel an einer Kündigung:
Es wurde DTM+93:202212312300?+00:303' kommuniziert. Daraus ergibt dich der 01.01.2023 00:00 Uhr gesetzlicher deutscher Zeit. Da es sich um ein Endedatum handelt interpretieren dies einige mit dem Ablauf des 01.01.2023.
Bei einem Lieferbeginn (Anmeldung NN) wird DTM+92:202212312300?+00:303' kommuniziert.
Daraus ergibt sich für einige der 31.12.2022 da die Uhrzeit ignoriert wird. Und da es sich um ein Beginndatum handelt, wird das Datum als Tagesbeginn interpretiert.
Datumssegmente mit besonders vielen Problemen:
1. Fälligkeitsdatum in der INVOIC. Es gab in der Vergangenheit anscheinend keine durchgängige Interpretation, ob das Fälligkeitsdatum zu einem Tagesbeginn oder Tagesende gegolten hat. Auch hier wird die Zeitangabe gerne ignoriert und das verbleibende Datum dann auf ein Tagesanfang oder Tagesende „definiert“.
2. Versionsangaben von Zeitreihen
Bei Zeitreihen wird das DTM+293 (Versionsangabe) verwendet. Dieses DTM findet sich dann in der IFTSTA als Referenz in dem RFF+AUU. Wie ist dieses DTM im RFF+AUU zu übertragen?
|
2022-10-20 16:14:39 |
Vielen Dank für den Beitrag. Auch bei uns sind diverse Anfragen zu diesem Thema eingegangen.
Dadurch, dass Zeitpunkte nun in der Genauigkeit Minuten in UTC angegeben werden (DTM mit 303 in DE 2379), muss und darf der Empfänger keinerlei Interpretation mehr durchführen. Er hat nur diesen UTC-Zeitpunkt unverändert, d. h. das angegebene Jahr, den angegebenen Monat, den angegebenen Tag, die angegebene Stunde und die angegebene Minute zu übernehmen und diese Informationen, d. h den genannten Zeitpunkt von UTC in die gesetzliche deutsche Zeit umzurechnen. Das geschieht, in dem während der Sommerzeit zwei Stunden addiert und in der Winterzeit eine Stunde addiert wird. In dem Geschäftsvorfall wird der Zeitpunkt übermittelt, welcher gemeint ist. Anhand Ihres Beispiels mit dem DTM+93:202212312300?+00:303' wird der Zeitpunkt (gesetzlich deutsche Zeit) 01.01.2023 00:00 Uhr übertragen. 00:00 Uhr ist der Zeitpunkt an dem der 01.01.2023 beginnt, gelichzeitig ist dieser Zeitpunkt auch der Zeitpunkt an dem der 31.12.2022 geendet hat.Gleichfalls drückt dieser Zeitpunkt aber auch das Tagesende des 31.12.2022 aus. Merksatz: „Der heutige Tag endet genau zu dem Zeitpunkt, zu dem der morgige Tag beginnt!“Der Zeitstrahl verdeutlicht diese Aussage graphisch:
Gegenüberstellung, des bisherigen Umgangs mit in den Geschäftsvorfällen angegebenen Zeitpunkten geringerer Genauigkeit zu dem jetzigen Umgang mit in den Geschäftsvorfällen angegebenen Zeitpunkten höherer Genauigkeit.
Beispielsweise:
DTM+93:20223112:102' Damit wurde das Datum 31.12.2022 übermittelt. Anhand der fachlichen Information der DTM-Beschreibung „Ende zum“ (Code 93 in DE2005) muss das Ende des 24 Stunden umfassenden Zeitraums des Tages 31.12.2022 interpretiert werden. Es war somit „Ende zum“ die verkürzte Aussage „Ende zum Ablauf des in diesem DTM-Segments angegebenen Tages“.
Seit dem 01.10.2022 wrid nun folgend übertragen.Dies wird nun folgend übertragen:DTM+93:202212312300?+00:303'Es wird nun der genaue Zeitpunkt eines Vertragsendes (Kündigung) bzw. Lieferendes (Abmeldung) angegeben. Dies ist hier der 01.01.2023 00:00 Uhr zu welchem die Kündigung wirksam bzw. die Belieferung beendet werden soll.Wenn man so will, ist „Ende zum“ nun die verkürzte Aussage „Ende zum in diesem DTM-Segment angegebenen Zeitpunkt“.
Anmerkungen zum Fälligkeitsdatum: Auch wenn es in der Vergangenheit verschiedene Auffassungen über den Zeitpunkt einer Fälligkeit gegeben hat, so sind diese unterschiedlichen Auffassungen nun beseitigt. Es wird nun der Zeitpunkt einer Fälligkeit kommuniziert. Bei einem DTM+265:202210152200?+00:303' (Fälligkeitsdatum), welches dem 16.10.2022 00:00 Uhr gesetzlicher deutscher Zeit entspricht, ist nun der 16.10.2022 00:00 Uhr der Zeitpunkt zu dem die Zahlung überfällig ist, eindeutig beschrieben.
Anmerkung zu Versionsangaben:Hier wollen wir zunächst auf die Versionsangaben eingehen, welche vor dem 01.10.2022 vergeben und per MSCONS ausgetauscht wurden. Für diese gilt die Beschreibung aus dem EDI@Energy Einführungsszenario BK6-20-160 1.8, welches zum Zeitpunkt der Veröffentlichung dieser Antwort in der Version 1.8 vorlag.Für alle Versionsangaben, welche nach dem 01.10.2022 vergeben und per MSCONS übertragen wurden, und welche in einer IFTSTA als Referenz in dem RFF+AUU anzugeben sind, gilt, als dass dies exakt so in DE1154 des RFF-Segments der IFTSTA anzugeben sind, wie sie in DE2380 der entsprechenden MSCONS erhalten waren.Beispiel: DTM+293:20221015153452?+00:304'In der IFTSTA findest sich dieser dann wie folgt wiederRFF+AUU:20221015153452?+00‘
Grüße Ihre EDI@Energy |
Ja
|
Holger Weickenmeier |
Sven Schillack |
Holger Weickenmeier |
Holger Weickenmeier |
|
Nein
|
-------------Holger Weickenmeier-------------20.10.2022 16:16
|
Nein
|
Nein
|
|
PRICAT AHB - informatorische Lesefassung 2.0a
|
Eingegangen
|
PRICAT ist die Bedingung [942] Format: n1-n2-n1-n3 leider fehlerhaft
|
Fehlerkorrektur der Artikel-ID |
13.10.2022
|
2022-01519 |
|
|
Sehr geehrte Damen und Herren,
in der aktuell gültigen PRICAT ist die Bedingung [942] Format: n1-n2-n1-n3 leider fehlerhaft.
Die Bedingung sagt aus, dass die dritte Zahl in der Art.-ID nur einstellig sein darf.
In der aktuell gültigen Codeliste gibt es aber inzwischen Artikel-IDs , die an der dritten Stelle zweistellig sind.
1-10-10-001 Aufschläge aufgrund der Offshore-Netzumlage nach § 17f EnWG, die auch für Stromspeicher gelten (Einheit: €/kWh)
1-10-10-002 Aufschläge aufgrund der Offshore-Netzumlage nach § 17f EnWG für Stromspeicher nach § 27b KWKG, deren Strom, der zum Zweck der Zwischenspeicherung in einem elektrischen, chemischen, mechanischen oder physikalischen Speicher verbraucht wird, keine Umlage zahlen (Einheit: €/kWh)
|
2022-10-13 10:35:25 |
Hallo,
vielen Dank für den Hinweis. Dieser Widerspruch zwischen PRICAT und Artikel-ID wurde mit der Fehlerkorrektur vom 25.10.2022 des Dokuments "Codeliste der Artikelnummern und Artikel-ID" behoben (Änderungs-ID: 23602).
Mit freundlichen GrüßenIhr Forum Datenformate |
Ja
|
Thomas Seipt |
Klaus Keller |
Thomas Seipt |
Christian Hildebrandt |
Anbei die Daten:
Es betrifft folgende PRCIAT: PRICAT_AHB_2_0a_info_Fehlerkorrektur_20220603
Bedingung Seite 14 PRICAT zur NN: [942] Format: n1-n2-n1-n3
Widerspruch zur Codeliste: Codeliste_Artikelnummern und Artikel-ID_5_2_info_Fehlerkorrektur_20220913
Seite 38: Betroffene Gruppenartikel-ID: 1-10-10 |
Nein
|
|
Nein
|
Nein
|
|
Codeliste der Standardlastprofile nach TU München-Verfahren 1.1
|
Abgeschlossen
|
|
Weiterführende Informationen zu den Standardlastprofilen gibt es unter https://www.bdew.de/service/standardvertraege/kooperationsvereinbarung-gas/ |
28.09.2022
|
2022-01496 |
|
|
Sehr geehrte Damen und Herren,
wir sind als ESA (Code 9983708000004) für unsere Kunden tätig und haben immer mehr im Zuge der steigenden Relevanz des Energieeinkaufs mit Lastprognosen und Lastprofile zu tun. Gibt es eine Möglichkeit auf die Standardlastprofile nach TUM-Verfahren zuzugreifen?
Mit freundlichen Grüßen
Thomas Eberle
M.Sc. (FH) | Energieberater
Telefon: +49 241 51579 23
E-Mail: thomas.eberle@adapton.de
|
2022-09-28 11:14:42 |
Sehr geehrter Herr Eberle,
vielen Dank für Ihre Frage. Unter der Adresse "https://www.bdew.de/service/standardvertraege/kooperationsvereinbarung-gas/" stellt der BDEW weiterführende Informationen zur Verfügung. Im Falle der Standardlastprofile sollte Ihnen das Dokument "Abwicklung von Standardlastprofilen Gas" bzw. die daran enthaltenen Anlagen helfen.
Mit freundlichen Grüßen
Forum Datenformate |
Ja
|
Oliver Kunz |
Thomas Fellhauer |
Oliver Kunz |
Thomas Eberle |
|
Nein
|
|
Nein
|
Nein
|
|
INVOIC / REMADV AHB 2.4a
|
Abgeschlossen
|
Interpretation DTM+265 "Fälligkeitsdatum"bei INVOIC
|
Das Fälligkeitsdatum wird ab dem 01.10.2022 als "Zeitpunkt" übermittelt und ist somit eindeutig und interpretationsfrei. |
16.09.2022
|
2022-01485 |
|
|
Sehr geehrtes Forum,
wir bitten um eine Definition, wie das DTM+265 (Fälligkeitsdatum) zu interpretieren ist.
Bei Fälligkeit = 29.09.2022 versenden wir in der INVOIC DTM+265 202209292200+00
Da wir bei der Fälligkeit die Uhrzeit „Tagesende“ also 29.09.2022 23:59:59 Uhr verstehen. Der Empfänger hat also Zeit bis zum Ende des 29.09.2022 um die Rechnung fristgerecht zu zahlen.
Beispiel:
Rechnungsguthaben haben die Bedingung DTM+256 (Fälligkeit) vs. DTM+137 (Rechnungsdatum) darf maximal 10 Werktage sein.
Das Rechnungsdatum wird als „Tagesbeginn“ betrachtet und bspw. durch UTC Sommerzeit wie folgt dargestellt:
Rechnungslegung: 14.09.2022
Ausgabe im EDIFACT: DTM+137 202209132200+00
Das Fälligkeitsdatum wird als „Tagesende“ betrachtet und bspw. durch UTC Sommerzeit wie folgt dargestellt:
Fälligkeit Guthaben: 29.09.2022 entspricht genau 10 Werktagen
Ausgabe im EDIFACT: DTM+265 202209292200+00
Das Problem was nun besteht und jetzt in den Tests zu APERAKs führt, ist die “Rückrechnung”.
Weil damit rein rechnerisch 14.09. 00:00 Uhr vs. 29.09. 00:00 Uhr eben > 10 Werktage ergibt.
|
2022-09-16 16:44:57 |
Sehr geehrter Marktteilnehmer,
vielen Dank für den Beitrag. Uns hat diese Fragestellung auch aus verschiedenen Kanälen erreicht. Wir versuchen hiermit dies zu unterstützen.
Zu der Frage wie das DTM+265 zu interpretieren ist:
Das DTM+265 ist im Format CCYYMMDDHHMMZZZ angegeben. Dies stellt einen Zeitpunkt dar. Durch die Bedingung [UB1] ist lediglich ein Zeitpunkt 00:00 Uhr (deutsche Zeit) möglich. (Die UTC Umrechnung außer Acht gelassen, da diese nichts an der Situation verändert.)
In Ihrem Beispiel haben Sie folgenden Wert angegeben:DTM+265 202209292200+00Dies entspricht dem Zeitpunkt 30.09.2022 00:00 Uhr.Zu Ihrer Anmerkung: Da wir bei der Fälligkeit die Uhrzeit „Tagesende“ also 29.09.2022 23:59:59 Uhr verstehen. Der Empfänger hat also Zeit bis zu zum Ende des 29.09.2022 um die Rechnung fristgerecht zu zahlen.Hierzu folgende Anmerkungen:Die Uhrzeit 23:59:59 ist nicht das Tagesende. Der Zeitpunkt des Tagesendes ist der gleiche Zeitpunkt des Tagesbeginns des Folgetages.Das Tagesende des 29.09.2022 entspricht somit der Uhrzeit 30.09.2022 00:00:00. Fazit: Somit ist die "Interpretation" korrekt, dass bei einem DTM+265 202209292200?+00 welches der deutschen Uhrzeit 30.09.2022 00:00:00 entspricht die Rechnung am 29.09.2022 bis zum "Tagesende" bezahlt sein muss. Ab dem Zeitpunkt 30.09.2022 00:00:00 ist die Frist überschritten.
Erlauben Sie uns noch ein paar allgemeine Hinweis zu den Fristen:
In der Festlegung zu Beschluss BK6-20-160 (GPKE MaKo 2022) finden sie unter Kapitel I.7 Fristenberechnung Informationen zu diesem Thema.Zitat: Kap. I.7 Fristenberechnung
Die Fristenvorgaben bezeichnen einen Zeitraum, der zwischen dem Eingang der Nachricht und dem gemeldeten Ereignis liegen muss.
Wird die Frist in WT angegeben, so bestimmt sich dieser Zeitraum nach der Anzahl von WT, d.h. relevant sind jeweils volle Tage, die zwischen Meldungseingang und dem gemeldeten Ereignis liegen und nicht auf ein Wochenende oder einen Feiertag fallen.
Da der Tag des Nachrichteneingangs bei Zugang der Nachricht bereits angebrochen ist, stellt er keinen diesem Mindestzeitraum zuzurechnenden, vollen Tag dar. Die Frist beginnt folglich gemäß § 187 Abs. 1 BGB mit Beginn des auf den Meldungseingang folgenden WT.
Bezieht sich das gemeldete Ereignis auf ein Tagesende2 (z.B. Kündigung, Lieferende), so ist dieser Tag in der Mindestfrist enthalten, die der Nachrichtenversender berücksichtigen muss.
Bezieht sich das gemeldete Ereignis auf einen Tagesbeginn (z.B. Lieferbeginn), so ist dieser Tag nicht in der Mindestfrist enthalten, die der Nachrichtenversender berücksichtigen muss.
Laut Ihrem Beispiel erstellen Sie die Rechnung am 14.09.2022 im Laufe des Tages. Nach Ihren Angaben befüllen Sie das DTM+137 (Nachrichtendatum) mit dem Tagesbeginn 14.09.2022 00:00 deutsche Zeit. Ob hier wirklich immer der Tagesanfang genannt sein muss, oder auch eine genaue Uhrzeit vorhanden sein darf, darauf wollen wir hier nun nicht eingehen, da dies an der Fristenberechnung nichts ändern würde. Die Fälligkeit geben sie mit dem Zeiptunkt 30.10.2022 00:00 Uhr deutsche Zeit an. Problem: Sie berechnen die Frist ab dem 14.09.2022 00:00 Uhr. Die Frist beginnt nicht mit dem Rechnungserstellungsdatum. Die Frist beginnt mit dem Eingangsdatum beim Rechnungsempfänger. Gemäß der oben zitierten Regeln zur Fristberechnung wird die Frist ab dem 15.09.2022 gerechnet. Dies setzt voraus, dass die Rechnung im Laufe des 14.09.2022 beim Empänger eintrifft.
Mi 14.09.2022 ist das Rechnungseingangsdatum beim EmpfängerDo 15.09.2022 1. WTFr 16.09.2022 2. WTMo 19.09.2022 3. WTDi 20.09.2022 FeiertagMi 21.09.2022 4. WTDo 22.09.2022 5. WTFr 23.09.2022 6. WTMo 26.09.2022 7.WTDi 27.09.2022 8. WTMi 28.09.2022 9. WTDo. 29.09.2022 10. WTSomit sind am Do 29.09.2022 volle 10 WT seit dem Eingang der Rechnung beim Empfänger vergangen. Daraus würde sich für eine Gutschrift ein Fälligkeitszeitpunkt ergeben, welcher nicht nach dem 30.09.2022 00:00 Uhr liegen darf. In der EDIFACT würde das Segement in UTC so angegeben werden: DTM+265:202209292200?+00:303'
In Ihrem Beispiel (Zitat)
Das Fälligkeitsdatum wird als „Tagesende“ betrachtet und bspw. durch UTC Sommerzeit wie folgt dargestellt:Fälligkeit Guthaben: 29.09.2022 entspricht genau 10 WerktagenAusgabe im EDIFACT: DTM+265 202209292200+00
geben Sie als Fälligkeit den 29.09.2022 "Tagesende" an. Das Tagesende des 29.09.2022 entspricht als Uhrzeitangabe dem 30.09.2022 00:00 Uhr. In UTC wäre dies DTM+265:202209292200+00
Freundliche Grüße,Ihr BDEW-Forum Datenformate |
Ja
|
Klaus Keller |
Stefan Seidel |
Klaus Keller |
Thomas Seipt |
Fälligkeitsdatum SG8 DTM+265 |
Nein
|
-------------Holger Weickenmeier-------------19.09.2022 17:31
Entwurf
-------------Stefan Seidel-------------30.09.2022 09:31
eben die Veröffentlichung zurückgenommen, da die Aussage
"Geben Sie als Fälligkeit den 29.09.2022 "Tagesende" an. Das Tagesende des 29.09.2022 entspricht als Uhrzeitangabe dem 29.09.2022 00:00 Uhr. In UTC wäre dies DTM+265:202209282200"
falsch ist. Folgende Aussage ist richtig:
"Geben Sie als Fälligkeit den 29.09.2022 "Tagesende" an. Das Tagesende des 29.09.2022 entspricht als Uhrzeitangabe dem 30.09.2022 00:00 Uhr. In UTC wäre dies DTM+265:202209292200"
-------------Holger Weickenmeier-------------30.09.2022 11:12
Danke für den Hinweis. Ich habe dies korrigiert. Dies nur aus dem Grund, damit mein Erstaufschlag zumindest fachlich korrekt ist.
-------------Christina Frein-------------05.10.2022 08:11
Beschluss PG
-------------Klaus Keller-------------05.10.2022 11:08
redaktionelle Korrektur von Rechntschreibfehlern und Grammatikfehlern -> Veröffentlichung |
Nein
|
Nein
|
|
INVOIC / REMADV AHB 2.4a
|
Abgeschlossen
|
Wie kann eine Netznutzungsrechnung für Netzkoppelungspunkte erfolgen ?
|
Aufgrund fehlender prozessualer Vorgaben zur Abrechnung von Netznutzungsrechnungen für Netzkoppelpunkte sind derzeit keine Datenformate ausgeprägt. |
26.08.2022
|
2022-01467 |
|
|
Sehr geehrte Damen und Herren,
im Auftrag unserer Kolleg*innen der Netzabrechnung stelle ich folgende Frage:
Es gibt keine eindeutige Stellungnahme zu dem Punkt Netzkopplungspunkt. Der Netzkopplungspunkt ist immer eine MeLo. Beim Konstrukt ist keine verknüpfte MaLo vorgesehen.
Gemäß AHB INVOIC ist nur die MaLo in der EDIFACT-Nachricht zulässig. Beim Netzkopplingspunkt haben wir jedoch nur die MeLo. Somit kann die INVOIC nicht versandt werden, da sie nicht durch die APERAK-Prüfung kommt. Im AHB bei der NN-Abrechnung müsste somit eigentlich sowohl MaLo als auch MeLo zulässig sein. Dies ist allerdings wohl übersehen worden und müsste in der Anpassung zum 01.10.2022 gültigen Version INVOIC 2.8 noch berücksichtigt werden. Gibt es die Möglichkeit dies in einer Lesefassung bis 01.10. noch aufzunehmen.
Vielen Dank und freundliche Grüße
Jörg Kattner
|
2022-08-26 10:02:43 |
Hallo Herr Kattner,
die prozessualen Vorgaben in der GPKE und GeLi Gas treffen keine Festlegung zur Abrechnung von an Netzkopplungspunkten erfassten Energiemengen.
In der GPKE (Anlage 1a zum Beschluss BK6-20-160) steht im Use-Case: Netznutzungsabrechnung im Feld Vorbedingung: "Die Zuordnung der vom LF angemeldeten Marktlokationen wurde vom NB bestätigt." Somit ist dieser UseCase nicht an Netzkopplungspunkten anzuwenden.
In der GeLi Gas (Konsolidierte Lesefassung (Stand: 20.12.2016)) steht im Kapitel 1. Gegenstand der Anlage:
* Annexprozesse beim Wechsel des Lieferanten:
− Aufbereitung und Weiterleitung von Messwerten,
− [...]
− Netznutzungsabrechnung,[...]
Somit ist der in der GeLi Gas enthaltene UseCase Netznutzungsabrechnung nur für Marklokationen festgelegt, da der durch die GeLi Gas festgelegte Lieferantenwechsel ausschließlich am Marktlokation stattfindet. Somit ist auch der UseCase Netznutzungsabrechnung nicht an Netzkopplungspunkten anzuwenden.
Nur für die Prozessschritte für die gültige, bzw. gültig werdende Prozessbeschreibungen vorliegen werden die Datenformate ausgeprägt und beschrieben. Uns ist keine Prozessbeschreibung bekannt, aus der sich die von Ihnen geschilderte Anforderung an die INVOIC ableiten lassen würde.
Freundliche Grüße,
Ihr Forum Datenformate |
Ja
|
Klaus Keller |
Stefan Seidel |
Klaus Keller |
Jörg Kattner |
|
Nein
|
-------------Klaus Keller-------------26.08.2022 11:39
an Fr. Becker zur Diskussion in der AG R/Z gesendet
-------------Stefan Seidel-------------26.08.2022 13:43
Antwortskizze eingefügt.
-------------Klaus Keller-------------13.09.2022 16:01
Antwort nach Vorgabe der AG R/Z veröffentlicht, nachdem vorher noch Kurzfrage und -antwort ergänzt wurden. |
Nein
|
Nein
|
|
INVOIC / REMADV AHB 2.4a
|
Abgeschlossen
|
Abrechnung der Leistung bei RLM-Kunden, Rundung der Leistungswerte im Rahmen der Abrechnung?
|
Bei Nutzung der im Format angegebenen Nachkommastellen ist eine Rundung auf weniger als 3 Nachkommastellen nicht erforderlich. |
01.06.2022
|
2022-01390 |
|
|
Sehr geehrte Damen und Herren,
welche Vorgaben gibt es denn hinsichtlich der Rundung bei Nachkommastellen bei der gemessenen Leistung im
Rahmen der Abrechnung der Netznutzungsentgelte?
Wir handhaben es so, dass wir den in der Rechnung anzusetzenden Leistungswert auf eine Nachkommastelle runden.
Allerdings nicht kaufmännisch, sondern wir setzen die erste Nachkommastelle ohne auf- oder abrundung an.
Z.B. gemessene Leistung 15,482 KW, wir verwenden im Rahmen der Abrechnung dann 15,4 KW
Bisher gab es diesbezüglich Seitens der Lieferanten auch keine Beschwerden. Ein Lieferant bemängelt nun jedoch
unserer Vorgehensweise.
Im Voraus vielen Dank für Ihre Rückmeldung.
|
2022-06-01 13:12:56 |
Sehr geehrter Fragesteller,
das Format lässt die Genauigkeit von 3 Nachkommastellen zu und damit kann das beschriebene Problem gelöst werden. Wir empfehlen die Nutzung der 3 Nachkommastellen.
Freundliche Grüße,Ihr Forum Datenformate |
Ja
|
Klaus Keller |
Stefan Seidel |
Stefan Seidel |
Michael Hoffmann |
|
Nein
|
-------------Klaus Keller-------------04.07.2022 09:27
Antwort/Kurzfrage/-antwort aus Protokoll der AG R/Z vom 30.6. eingefügt - könnte also ohne weitere QS veröffentlicht werden oder ? |
Nein
|
Nein
|
|
INVOIC / REMADV AHB 2.4a
|
Abgeschlossen
|
Wie wird eine Mehrmenge abgerechnet ?
|
Mehrmenge wird immer mit Anwendungsfall "MMM selbst ausgstelle Rechnung" (PID 31006) abgerechnet |
30.03.2022
|
2022-01326 |
|
|
Erneut die Frage:
Mehrmengenabrechnung BGM+389: Aktuell gibt es auseinandergehende Positionen wie Energiemengen und die Bepreisung in der selbst ausgestellten Rechnung auszusehen haben. Wir sind der Auffassung, dass bei Mehr-/Mindermengenabrechnung, die als Lieferung abgerechnet werden, in der EDIFACT-Datei (INVOIC) der Rechnungsbetrag bei Mehrmenge (im Original) ein negatives Vorzeichen haben muss und der Storno dazu kein Vorzeichen haben darf. Demgegenüber sind wir der Auffassung, dass bei Handelsrechnungen BGM+380 das Gegenteil vorliegt [also der Rechnungsbetrag bei Mindermenge (im Original) kein Vorzeichen haben darf und in dem dazugehörigen Storno ein negatives Vorzeichen haben muss]. Einige Marktpartner haben eine andere Auffassung und sind der Meinung, dass sowohl Mehrmenge als auch Mindermenge kein Vorzeichen in der EDIFACT-Datei haben dürfen, da diese durch die Prüfidentifikatoren 31005 und 31006 gesteuert werden. In unserer Darstellung (angehängte Datei) sind die Prüfidentifikatoren bereits vorhanden. Daraus ergibt sich die Frage, ob in der EDIFACT-Datei INVOIC nur die Prüfidentifikatoren vorhanden sein müssen ohne die Vorzeichen vor den Rechnungsbeträgen (sowohl Mehrmenge als auch Mindermenge) oder ob es wie oben beschrieben auszusehen hat (sowohl Prüfidentifikatoren als auch Vorzeichen vor den Rechnungsbeträgen)?
Gibt es eine Anleitung oder ein konkretes Beispiel?
|
2022-03-30 16:13:46 |
Sehr geehrter Fragesteller,
die Abrechnung einer Mehrmenge wird heute ausschließlich als selbst ausgestellte Rechnung deklariert und dafür ist ausschließlich der Anwendungsfall mit dem Prüfidentifikator 31006 zu verwenden. In dem Anwendungsfall kann kein Korrekturfaktor angegeben werden.
Freundliche Grüße,Ihr Forum Datenformate
|
Ja
|
Klaus Keller |
Stefan Seidel |
Stefan Seidel |
Erich Urosevic |
AHB INVOIC v. 1.4.2021 - BGM+389 / Prüfidentifikator 31006
2.1.3 MMM-rechnung ab Seite 22 |
Nein
|
-------------Klaus Keller-------------04.07.2022 09:25
Antwort aus Protokoll der AG R/Z vom 30.6. eingefügt und Kurzfrage/-antwort ergänzt |
Nein
|
Nein
|
|
INVOIC / REMADV AHB 2.4a
|
Abgeschlossen
|
Wie wird eine Mehrmenge abgerechnet ?
|
Mehrmenge wird immer mit Anwendungsfall "MMM selbst ausgstelle Rechnung" (PID 31006) abgerechnet |
14.03.2022
|
2022-01311 |
|
|
Mehrmengenabrechnung BGM+389: Aktuell gibt es auseinandergehende Positionen wie Energiemengen und die Bepreisung in der selbst ausgestellten Rechnung auszusehen haben. Wir sind der Auffassung, dass bei Mehr-/Mindermengenabrechnung, die als Lieferung abgerechnet werden, in der EDIFACT-Datei (INVOIC) der Rechnungsbetrag bei Mehrmenge (im Original) ein negatives Vorzeichen (-) haben muss und der Storno dazu kein Vorzeichen haben darf. Demgegenüber sind wir der Auffassung, dass bei Handelsrechnungen BGM+380 das Gegenteil vorliegt [also der Rechnungsbetrag bei Mindermenge (im Original) kein Vorzeichen haben darf und in dem dazugehörigen Storno ein negatives Vorzeichen haben muss]. Einige Marktpartner haben eine andere Auffassung und sind der Meinung, dass sowohl Mehrmenge als auch Mindermenge kein Vorzeichen in der EDIFACT-Datei haben dürfen, da diese durch die Prüfidentifikatoren 31005 und 31006 gesteuert werden. In unserer Darstellung (angehängte Datei) sind die Prüfidentifikatoren bereits vorhanden. Daraus ergibt sich die Frage, ob in der EDIFACT-Datei INVOIC nur die Prüfidentifikatoren vorhanden sein müssen ohne die Vorzeichen vor den Rechnungsbeträgen (sowohl Mehrmenge als auch Mindermenge) oder ob es wie oben beschrieben auszusehen hat (sowohl Prüfidentifikatoren als auch Vorzeichen vor den Rechnungsbeträgen)?
Gibt es eine Anleitung oder ein konkretes Beispiel?
|
2022-03-14 15:37:56 |
Sehr geehrter Fragesteller,
die Abrechnung einer Mehrmenge wird heute ausschließlich als selbst ausgestellte Rechnung deklariert und dafür ist ausschließlich der Anwendungsfall mit dem Prüfidentifikator 31006 zu verwenden.
Freundliche Grüße,Ihr Forum Datenformate |
Ja
|
Klaus Keller |
Stefan Seidel |
Stefan Seidel |
Erich Urosevic |
AHB INVOIC v. 1.4.2021 - BGM+389 / Prüfidentifikator 31006
2.1.3 MMM-Rechnungen ab Seite 22 |
Nein
|
-------------Klaus Keller-------------04.07.2022 09:06
Antwort aus Protokoll der AG R/Z vom 30.6. eingefügt und Kurzfrage/-antwort ergänzt
|
Nein
|
Nein
|
|
Stammdaten AWT 1.1a
|
In Bearbeitung
|
Ist die Einschränkung in Fußnote 8 als "und"-Verknüpfung zu lesen?
|
Die Einschränkung in Fußnote 8 ist als "und"-Verknüpfung zu verstehen. |
12.09.2022
|
2022-01479 |
|
|
Hallo zusammen,
die Angaben zu Mindestbetriebszeit, Mindeststillstandszeit, Anfahrzeit kalt, Anfahrzeit warm, Hochfahrzeit kalt, Hochfahrzeit warm und Abfahrzeit sind unter den Bedingungen der Fußnote [8] im AWT-Dokument erforderlich: "Nur bei SEE, die mit thermischen Prozessen betrieben werden [...] und bei Steuerbaren Ressourcen mit einer installierten Bruttonennleistung von > 1 MW".
Ich verstehe den Text so, dass damit sowohl thermische Anlagen als auch solche mit mehr als 1 MW gemeint sind.
Installierte Leistungen von mehr als 1 MW sind bei Windanlagen nicht außergewöhnlich. Werden damit die genannten Felder für diese Windräder zu Pflichtangaben? Oder ist die Einschränkung als „und“-Verknüpfung zu lesen (als „thermische Anlagen, die mehr als 1 MW Nennleistung haben“)?
Eine ähnliche Frage ist am 8.3.2022 schon einmal gestellt worden, allerdings bezog sich die Antwort damals noch auf die alte Formulierung der AWT. Der zweite Halbsatz ist erst danach, bei der letzten Überarbeitung am 23.05., aufgenommen worden.
Danke schon mal und viele Grüße!
|
2022-09-12 12:23:19 |
Sehr geehrte/r Fragesteller/in,
die Fußnote 8 in der Stammdaten AWT ist so zulesen, dass beide Einschränkungen wirken, d.h. die Einschränkung ist als "und"-Verknüpfung zu verstehen:
Nur bei SEE mit einer installierten Bruttonennleistung von > 1 MW, die mit thermischen Prozessen betrieben werden (d.h. wenn Energietraeger mit B01|B02|B03|B04|B05|B06|B09|B14|B15|B17|B20 vorhanden).
Bspw. für Windanlagen (Energieträger B18 oder B19) sind die Angaben mit Fußnote [8] nicht zu liefern.
Mit freundlichem Gruß
Ihr BDEW-Forum Datenformate |
Ja
|
Sara Olszewski |
Alexander Kramer |
Sara Olszewski |
Oliver Chadenas |
AWT Stammdaten RD2 (Stammdaten AWT 1.1_Lesefassung 20220523.pdf) Fußnote 8:
Nur bei SEE, die mit thermischen Prozessen betrieben werden (d.h. wenn Energietraeger mit B01|B02|B03|B04|B05|B06|B09|B14|B15|B17|B20 vorhanden) und bei Steuerbaren Ressourcen mit einer installierten Bruttonennleistung von > 1 MW
|
Nein
|
Antwortvorschlag
-------------Sara Olszewski-------------02.11.2022 14:37
in PG besprochen
-------------Katia Schubert-------------07.11.2022 10:42
|
Nein
|
Nein
|
|
UTILMD AHB Einspeiser 2.1e
|
Eingegangen
|
Ist die Bedingung [21] im PID 11078 am SG6 "Referenz auf die ID der Marktlokation für Termine der Marktlokation" erfoderlich?
|
Darstellung im UTILMD Einspeiser AHB ist richtig |
12.08.2022
|
2022-01460 |
|
|
Bei den PID 11078 und 11079 werden unterhalb des RFF6+Z18 Daten zur "Geplanten Turnusablesung des MSB (Strom)" angegeben, mit den Einschränkungen [21] und [234]. Im PID 11078 hängen diese beiden Bedingungen aber erst am darunterliegenden DTM6+752, während im PID die Einschränkung bereits am RFF6 hängen. Nach unserem Verständnis ist die Variante des PID 11078 nicht korrekt, da die dort vorhandene Ausprägung bedeuten würde, dass das RFF6 in jedem Fall anzugeben ist, auch wenn später das DTM aufgrund der Bedingungen nicht zu befüllen ist. Damit würde in einer Meldung zu einer MaLo mit einer Prognosegrundlage auf Basis von Werten das RFF6 Segment angegeben werden müssen, die eigentliche Information in dem DTM-Segment dann aber nicht mehr. Richtigerweise sollte, wie im PID 11079, unter den genannten Bedingungen auch im PID 11078 das RFF6 gar nicht erst mitgeteilt werden müssen.
Wir bitten dies bei der nächsten Fehlerkorrektur zu berücksichtigen. Vielen Dank
|
2022-08-12 13:19:36 |
Sehr geehrter Marktpartner,,
die Darstellung im UTILMD Einspeiser AHB ist richtig. Im Anwendungsfall 11078 wird gegenüber dem 11079 noch das "Abrechnungsintervall des LF" mitgeben, dass in jedem Fall vom NB anzugeben ist. Wenn eine Einschränkung bereits auf dem SG6 "Referenz auf die ID der Marktlokation für Termine der Marktlokation" erfolgen würde, wie im Anwendungsfall 11079, wäre das "Abrechnungsintervall des LF" nicht in jedem Fall mitzugeben.
Mit freundlichen GrüßenIhr Forum Datenformate |
Ja
|
Thomas Seipt |
Jessica Rahn |
Thomas Seipt |
Bastian Schulz |
|
Nein
|
Vorschlag erarbeitet
-------------Thomas Seipt-------------18.08.2022 14:28
|
Nein
|
Nein
|
|
Stammdaten FB 1.1
|
Abgeschlossen
|
Kann ein Absender mehrere Stammdatennachrichten eines Dokumentypes mit der gleichen DocumentIdentification verschicken?
|
Nein, eine DocumentIdentification darf je Absender und je DocumentTyp genau nur einmal vergeben werden. |
11.08.2022
|
2022-01459 |
|
|
Sehr geehrtes Forum,
kann ein Absender mehrere Nachrichten eines Dokumentypes mit der gleichen DocumentIdentification verschicken? Dies würde bedeuten, dass das Element DocumentIdentification nicht eindeutig ist und nicht zur Identifizierung einer Nachricht herangezogen werden könnte.
Hintergrund der Frage ist, dass in der Beschreibung zur DocumentIdentification Folgendes steht: „Die Identifikation des Dokuments (DocumentIdentification) hat je Absender und je Dokumententyp eindeutig zu sein“.
Im konkreten Fall der Prozesse
„Übermittlung Stammdatenänderung vom EIV (verantwortlich) ausgehend mit DP“,
"Übermittlung Stammdatenänderung vom (Anschluss-)NB (verantwortlich) ausgehend mit DP"
und „Übermittlung von angereicherten Stammdaten mit DP“, bei denen der Dataprovider Z02 bzw. Z03 Meldungen an die betroffenen Netzbetreiber sendet, kann das meiner Meinung nach bedeuten, dass die Meldungen die identische Dokumenten-ID haben können.
Denn in diesem Fall sind Absender (der Dataprovider) und Dokumententyp (Z02 bzw. Z03) eindeutig und die Anforderungen aus der Formatbeschreibung sind damit erfüllt.
Falls dies nicht so sein sollte, könnte dies in der Formatbeschreibung bitte konkretisiert werden.
Vielen Dank im Voraus!
|
2022-08-11 13:46:12 |
Sehr geehrte/r Fragesteller/in,
gemäß Formatbeschreibung und EDI@Energy-Allgemeinen Festlegungen (Kapitel 8.12 Dokumentenidentifikation und Versionierung) darf eine DocumentIdentification je Absender und je DocumentTyp im Zeitraum von 10 Jahren genau nur einmal vergeben werden.
In dem von Ihnen geschilderten Fall ist der DP der neue Absender der Nachrichten (Z02 und Z03) und ist somit verantwortlich für die Vergabe einer neuen DocumentIdentification, sodass obenstehende Anforderung erfüllt ist.
Mit freundlichen Grüßen
Ihr Forum Datenformate |
Ja
|
Sara Olszewski |
Alexander Kramer |
Sara Olszewski |
Julian Sprey |
|
Nein
|
vorbereitet, zur Besprechung in der PG
-------------Sara Olszewski-------------04.11.2022 13:15
in PG besprochen
-------------Katia Schubert-------------07.11.2022 10:31
|
Nein
|
Nein
|
|
PlannedResourceScheduleDocument AWT 1.0a
|
Abgeschlossen
|
Gibt es eine Vorgabe, bei welcher Art der Ressource für den prognostizierten Abruf die Einheit MW oder % zur verwenden ist?
|
Das ergibt sich über die Steuerbarkeit der Ressource. |
01.08.2022
|
2022-01444 |
|
|
Mit der Änderung vom 23.05.2022 ist jetzt im Use Case "Z09" (Prognostizierte Abrufe) eine Angabe relativ zur Nennleistung (C62) möglich. Hierzu die folgenden Frage:
- Im AWT Dokument gibt es mit Fußnote [6] nur eine Vorgabe für Cluster und Steuergruppen. Bei Steuerbaren Ressourcen kann damit die Übermittlung von Sollwerten sowohl relativ zur Nennleistung als auch absolut erfolgen, richtig? Gibt es hierzu eine Vorgabe, wann welche Einheit zur verwenden ist oder liegt das im Ermessen des Senders.
|
2022-08-01 06:01:08 |
Sehr geehrter Fragesteller,
im Fall der Übermittlung eines prognostizierten Abrufs ist die anlagenspezifische Steuerbarkeit zu berücksichtigen. Diese ergibt sich aus den Stammdaten.
Je nach Art der Steuerbarkeit ist der prognostizierte Abruf und der Abruf demnach in MW oder in % zu melden.
Mit freundlichem Gruß
Ihr Forum Datenformate |
Ja
|
Martin Schaumann |
Gina Völsgen |
Martin Schaumann |
Arnd Krönig |
|
Nein
|
in PG besprochen
-------------Katia Schubert-------------07.11.2022 12:07
|
Nein
|
Nein
|
|
Codeliste der OBIS-Kennzahlen und Medien 2.4a
|
In Bearbeitung
|
Wie können mehrere tarifunterschiedene Leistungswerte übermittelt werden?
|
Die Übermittlung von tarifunterschiedenen Leistungswerten ist nicht notwendig/möglich. |
28.07.2022
|
2022-01442 |
|
|
Guten Tag,
wie ist ab dem 01.10.2022 in der Marktkommunikation mit Geräten umzugehen, bei denen aktuell die ab diesem Zeitpunkt nicht mehr erlaubten OBIS 1-b:1.6.1/1-b:1.6.2 bzw. 1-b:2.6.1 und 1-b:2.6.2 Verwendung finden?
Viele Grüße
Boris Meyer
|
2022-07-28 12:20:11 |
Sehr geehrter Fragesteller,
die von Ihnen beschriebene Änderung wurde dem Markt im Rahmen der Konsultation im August 2021 zur Verfügung gestellt als Basis für die Umsetzung der MaKo 2022. Aufgrund der Einführung der Zählzeitdefinitionen, z.B. für die Zählzeitenanwendungszwecke Netznutzung (Verwendungszwecke: Netznutzungsabrechnung, Bilanzkreisabrechnung, MMMA, Übermittlung an HKNR, Ermittlung der Ausgeglichenheit von Bilanzkreisen) ist zu jedem Wert welcher keine Tarifstufe "0" hat eine Zählzeit sowie ein Zählzeitregister zuzuordnen. Dieses Vorgehen ist in der BDEW Anwendungshilfe "Einführungsszenario zur Weiterentwicklung der Netzzugangsbedingungen Strom BK6-20-160", welche auf www.edi-energy.de veröffentlicht ist, beschrieben. Für den Austausch von Leistungswerten ist hier kein Anwendungsfall bekannt, für den eine Tarifunterscheidung der Leistungswerte aufgrund der genannten Verwendungszwecke notwendig ist. Daher sind ab diesem Zeitpunkt Leistungswerte gemäß Codeliste der OBIS-Kennzahlen und Medien lediglich mit der Tarifstufe "0" im Markt zulässig.
Hat der MSB eine Messtechnik verbaut, welche mehr Zählwerke hat, als gemäß Anforderungen notwendig sind (in Ihrem Fall, dass mehrere Leistungszählwerke die das Leistungsmaximum zu unterschiedlichen Zeitpunkten erfassen), so hat er den höchsten der beiden Werte für das jeweilige Intervall, sofern ein Verwendungszweck für diese Werte vorliegt, mit der Tarifstufe "0" zu übermitteln. Die am Messgerät vorhandenen Bezeichnungen der Zählwerke können dabei als "Bezeichnung des Zählwerks auf dem Gerät (also z.B. 1 -1:1.6.1/1-1:1.6.2 oder 1-1:2.6.1 und 1-1:2.6.2)" übermittelt werden. In jedem Falle ist nur der höchste der beiden Werte in diesem Falle mit der Tarifstufe "0" zu übermitteln.
Viele Grüße,Ihr BDEW-Forum Datenformate
|
Ja
|
Reinhard Döring |
Thomas Seipt |
Tim Geisendörfer |
Boris Meyer |
|
Nein
|
Antwortvorschlag zur Prüfung erstellt
2023-01636
-------------Thomas Fellhauer-------------09.02.2023 15:19
-------------Thomas Seipt-------------09.02.2023 16:35
passt aus meiner Sicht |
Nein
|
Nein
|
|
INVOIC / REMADV AHB - informatorische Lesefassung 2.5
|
Abgeschlossen
|
Wurden Abrechnungszeiträume bei den Kapazitätsrechnungen auf Positonsebene vergessen?
|
Fehler wird in der nächsten Lesefassung korrigiert. |
22.07.2022
|
2022-01437 |
|
|
Guten Tag,
für PID 31010 (Kapazitätsrechnungen) sind in dem AHB die Segmente aus SG26 Positionsbezogener Abrechnungszeitraum Beginn und Positionsbezogener Abrechnungszeitraum Ende (DTM+155 und DTM+156) nicht mehr enthalten.
In den ganzen Änderungshistorien ist aber kein Hinweis vorhanden, dass diese Segmente wieder weg fallen sollen. Handelt es sich hier um ein Versehen? Die Segemente sind extra mit Uhrzeit noch per Änderungs-ID 20712 auf 303 angepasst worden für 10/2021.
Vielen Dank.
|
2022-07-22 09:42:19 |
Sehr geehrte Fragestellerin,
dank Ihres Hinweises haben wir zusätzlich den fehlenden Muss-Status im Abrechnungszeitraum auf Kopfebene entdeckt. Beide Fehler werden in der nächsten Lesefassung korrigiert.
Freundliche Grüße,Ihr BDEW-Forum Datenformate |
Ja
|
Klaus Keller |
Stefan Seidel |
Stefan Seidel |
Ramona Pantani |
AHB INVOIC/REMADV Fassung vom 19.07.2022, Seite 43 |
Nein
|
-------------Klaus Keller-------------28.07.2022 11:25
Änderungs-IDs 23513 und 23514 erstellt und Lesefassung zur Veröffentlichung bereitgestellt
-------------Stefan Seidel-------------28.07.2022 14:03
ich würde aus "Beide Fehler werden in der nächsten Lesefassung am 15.8.22 korrigert." "Beide Fehler werden in der nächsten Lesefassung korrigiert werden" machen.
-------------Klaus Keller-------------29.07.2022 09:00
letzte Anpassung nach Feedback von Frau Becker
|
Ja
|
Ja
|
|
PlannedResourceScheduleDocument XSD - informatorische Lesefassung 1.0a
|
Abgeschlossen
|
Reicht eine Sensitivitätszeitreihe aus?
|
Nein |
06.07.2022
|
2022-01420 |
|
|
Operative Umsetzung der Versendung von Sensitivitätszeitreihen (Z08) über das PlannedResourceScheduleDocument:
Beim Versenden einer Sensitivitätszeitreihe (Z08) sind auch ein BuisnessType und davon abhängig eine Direction (A01, Up / A02, Down) anzugeben. Im operativen Austausch hat sich nun die Frage gestellt welcher Umfang die Zeitreihe haben muss. Im speziellen Fall der Z08 verlangt der vorgelagerte Netzbetreiber für einen Netzverknüpfungspunkt und eine Steuerbare Ressource eine Zeitreihe sowohl für die Up-Richtung (A01), als auch für die Down-Richtung (A02). Die Steuerbare Ressource würde demnach zwei mal für beide Richtungen geplant (zwei mal Pos u. Qty)
Ist dieses Vorgehen den angedachten Formaten entsprechend oder reicht eine Sensitivitätszeitreihe aus, weil sich die Directions zwingend gegenseitig ausschließen?
Vielen Dank und viele Grüße
|
2022-07-06 13:21:27 |
Sehr geehrter Fragesteller,
laut der aktuellen Vorgaben in der FB sind die positive und die negative Wirkrichtung von Sensitivitäten für jede Viertelstunde in Form von zwei Zeitreihen zu melden.
Mit freundlichem Gruß
Ihr Forum Datenformate |
Ja
|
Martin Schaumann |
Gina Völsgen |
Martin Schaumann |
Lukas Hormann |
PlannedResourceScheduleDocument 1.0a
PlannedResourceTimeSeries > BusinessType > Direction
PlannedResourceTimeSeries > Period > Pos > Qty |
Nein
|
In PG besprochen
-------------Katia Schubert-------------07.11.2022 11:53
|
Nein
|
Nein
|
|
Kostenblatt AWT 1.0a
|
Eingegangen
|
Welche Angaben zum BusinessType gelten im Kostenblatt?
|
Es gelten die fallspezifischen Codes. |
29.06.2022
|
2022-01417 |
|
|
Zu verpflichtenden / optionalen Angaben im Kostenblatt:
- Ist es korrekt, dass ein valides Kostenblatt gemäß BK6-20-061 für Anlagen im Planwertmodell mindestens Zeitreihen mit den Businesstypen A01, A04 enthalten muss und Z06 nur, insofern kein einheitlicher kalkulatorischer Preis für negativen Redispatch von KWK-Anlagen angesetzt wird?
- Ist eine Zeitreihe mit Businesstyp Z03 ebenfalls verpflichtend oder könnten diese Kosten analog zu anderen vermiedenen Aufwendungen auch in A01 und A04 berücksichtigt werden?
- Sind dieselben Businesstypen für Anlagen im Prognosemodell verpflichtend / optional sind?
- Für Zeitreihen mit dem Businesstyp A01 und Z01: Müssen Zeitreihen für alle Status (Z01-Z05) angegeben werden oder sind einzelne Status optional?
|
2022-06-29 14:43:22 |
Sehr geehrte/r Fragesteller/in,
Frage 1: Der BusinessType A01 ist bei Ressourcen verpflichtend, die Technische Ressourcen mit dem Typ Stromerzeugungseinheit enthalten, ebenso die Z06. Der BusinessType A04 ist bei Ressourcen verpflichtend, die Technische Ressourcen mit dem Typ Stromspeichereinheit enthalten.
Frage 2: Wenn es vermiedene Netzentgelte gibt, dann müssen diese in der Z03 aufgeführt werden. Die A01-Zeitreihen für variable Kosten beinhalten diese Kosten nicht.
Frage 3: Dieser Punkt ist aktuell in Klärung.
Frage 4: Wenn in der Zeitreihenkombination ein Status anzugeben ist, dann muss dieser auch bei der Übermittlung der Zeitreihen mitgeführt werden. Eine genaue Aufschlüsselung finden Sie auch am Ende der FB zum Kostenblatt.
Viele Grüße,
Ihr Forum Datenformate |
Ja
|
Jennifer Collin |
Thomas Fellhauer |
Jennifer Collin |
Chris Kittl |
|
Nein
|
-------------Jennifer Collin-------------24.10.2022 14:52
in PG besprochen
-------------Katia Schubert-------------26.10.2022 16:01
|
Nein
|
Nein
|
|
Kostenblatt AWT 1.0a
|
Abgeschlossen
|
Ist das Kostenblatt nur für das Planwertmodell von Bedeutung?
|
Die Lieferung des Kostenblatts wird über die Planungsdatenprozesse abgewickelt und auch für Anlagen im Prognosemodell ermöglicht. |
12.04.2022
|
2022-01336 |
|
|
Gibt es eine Übersicht, für welche Energieträger die einzelnen Elemente bzw. Attribute von Bedeutung sind?
Gibt es hierzu eine Veröffentlichung der Bundesnetzagentur, z.B. in einem Dokument der BK6-20-Dokumente?
Laut dem Kostenblatt ist dieses Kostenblatt für einen EIV nur von Bedeutung, wenn er Anlagen im Planwertmodell betreut. Stimmt dies soweit oder ist das Kostenblatt auch für einen EIV, welcher Anlagen im Prognosemodell betreut, von Bedeutung? Welche Datenanforderungen sind dann für den EIV relevant?
|
2022-04-12 16:02:17 |
Sehr geehrte/r Fragesteller/in,
sofern nicht die kalkulatorischen Kosten genutzt werden, steht Ihnen das Kostenblattformat zur Verfügung. Dieses wird über die Planungsdatenprozesse abgewickelt und berücksichtigt auch Kosteninformationen bzgl. wärmegebundener Anlagen. In der BNetzA-Festlegung BK6-20-061, Anlage 1, Informationspunkt 2.21. finden Sie weitere Informationen dazu.
Zu Ihrer zweiten Frage: Ja, es wird aktuell für das Planwertmodell vorgesehen. In diesem Zusammenhang ist jedoch auch die Umsetzungsfrage Redispatch_011 zu berücksichtigen, die die Übermittlung auch im Prognosemodell ermöglicht.
Mit freundlichem Gruß
Ihr Forum Datenformate |
Ja
|
Jennifer Collin |
Thomas Fellhauer |
Jennifer Collin |
Eric Wirth |
|
Nein
|
Frage grob in der PG XML besprochen. Die Paten nehmen die Notizen für die Ausformulierung der Antwort mit.
-------------Katia Schubert-------------19.05.2022 16:10
Antwort in PG besprochen
-------------Katia Schubert-------------23.05.2022 15:26
|
Nein
|
Nein
|
|
Kostenblatt FB 1.0a
|
Eingegangen
|
|
Da dies keine formatspezifischen Fragen sind, bitten wir Sie um Verständnis, dass wir die Fragen hier nicht beantworten. |
27.06.2022
|
2022-01413 |
|
|
Fragen:
- Welche Kostenarten gibt es für eine EEG-Anlage (Vergütungsart = EEG) :
* Variable Kosten für Leistungsreduzierung (BT A01 / DIR A02): Ist dort immer der kalkulatorische Preis (momentan 590,60 € / MWh) anzusetzen, oder sind auch spezifische Kosten der Anlage zu berücksichtigen
* Variable Kosten für Leistungserhöhung (BT A01 / DIR A01): Gibt es das für EEG-Anlagen, wenn ja, welcher Kostensatz ist hier zu hinterlegen, spielt hier die spezifische Vergütung der Anlage eine Rolle
* Gibt es für eine EEG-Anlage weitere Kostenarten?
- Wie sind bei KWK-Anlagen (Vergütungsart = KWK) die variablen Kosten für Leistungsreduzierung zu ermitteln: Setzt sich dies immer aus den kalkualorischen Preisen für die Leistungsreduktion (momentan 251,25 €/MWH) und ggf. den Kosten für den wärmegebundenen Redispatch zusammen? Oder sind hier zusätzliche Kosten zu berücksichtigen
- Wie sieht es bei KWK-Anlagen mit den variablen Kosten für Leistungserhöhung aus: Sind hier die jeweils tatsächlichen Kosten zu veranschlagen oder gibt es dort auch kalkulatorische Kosten.
- Wie und für welche Anlagen sind die Kosten für vermiedene Netzentgelte zu berücksichtigen. Diese Kosten werden ja immer nur nachträglich für die abgelaufene Periode ermittelt, aber nicht im voraus.
|
2022-06-27 12:57:46 |
Sehr geehrter Fragesteller,
da dies keine formatspezifischen Fragen sind, bitten wir Sie um Verständnis, dass wir die Fragen hier nicht beantworten.
Freundliche GrüßeIhr Forum Datenformate |
Ja
|
Jennifer Collin |
Thomas Fellhauer |
Jennifer Collin |
Arnd Krönig |
Seite 12: Abhängigkeitsmatrix |
Nein
|
in PG besprochen
-------------Katia Schubert-------------25.01.2023 16:06
|
Nein
|
Nein
|
|
Kostenblatt FB 1.0a
|
Abgeschlossen
|
Wie ist die TimePeriodCovered bzw. das TimeInterval korrekt anzugeben?
|
Es ist yyyy-mm-ddThh:mmZ/yyyy-mm-ddThh:mmZ für TimePeriodCovered und TimeInterval zu verwenden. |
23.05.2022
|
2022-01385 |
|
|
Sehr geehrtes Forum Datenformate,
in dem Format Kostenblatt (und anderen Formaten) ist bei TimePeriodCovered sowie auch bei TimeInterval ein Pattern und ein Beispiel angegeben. Leider scheint das Beispiel nicht mit dem Pattern übereinzustimmen.
Als Beispiel wird bei TimePeriodCovered :
yyyy-mm- ddThh:mmZ/yyyy-mmddThh:mmZ
und bei TimeInterval:
yyyy-mmddThh: mmZ/yyyy-mm-ddThh:mmZ:
angegeben. Das Pattern dazu lautet:
20(\d{2}(\-(0[13578]|1[02])\-(0[1-9]|[12]\d|3[01])|\-02\- (0[1-9]|1\d|2[0-8])|\-(0[469]|11)\-(0[1-9]|[12]\d|30)) |([02468][048]|[13579][26])\-02\-(29))T([01]\d|2[0-3]):[0-5] \dZ/20(\d{2}(\-(0[13578]|1[02])\-(0[1-9]|[12]\d|3[01])|\-02\- (0[1-9]|1\d|2[0-8])|\-(0[469]|11)\-(0[1-9]|[12]\d|30)) |([02468][048]|[13579][26])\-02\-(29))T([01]\d|2[0-3]):[0-5] \dZ
Können Sie bitte klarstellen, wie die TimePeriodCovered bzw. das TimeInterval korrekt anzugeben ist?
Grüße
Martin Schaumann
|
2022-05-23 17:51:18 |
Sehr geehrter Fragesteller,
für die Angabe der TimePeriodCovered und des TimeInterval ist die Variante
yyyy-mm-ddThh:mmZ/yyyy-mm-ddThh:mmZ
zu verwenden. Es handelt sich dabei um einen Fehler im Beispiel.
Viele Grüße,
Ihr Forum Datenformate |
Ja
|
Jennifer Collin |
Thomas Fellhauer |
Jennifer Collin |
Martin Schaumann |
|
Nein
|
-------------Jennifer Collin-------------30.05.2022 09:25
In PG besprochen
-------------Katia Schubert-------------30.05.2022 16:34 |
Nein
|
Nein
|
|
NetworkConstraintDocument FB 1.1
|
Abgeschlossen
|
Wie ist die TimePeriodCovered bzw. das TimeInterval korrekt anzugeben?
|
Es ist yyyy-mm-ddThh:mmZ/yyyy-mm-ddThh:mmZ für TimePeriodCovered und TimeInterval zu verwenden. |
23.05.2022
|
2022-01386 |
|
|
Sehr geehrtes Forum Datenformate,
in dem Format Network Constrains(und anderen Formaten) ist bei TimePeriodCovered sowie auch bei TimeInterval ein Pattern und ein Beispiel angegeben. Leider scheint das Beispiel nicht mit dem Pattern übereinzustimmen.
Als Beispiel wird bei TimePeriodCovered :
yyyy-mm- ddThh:mmZ/yyyy-mmddThh:mmZ
und bei TimeInterval:
yyyy-mmddThh: mmZ/yyyy-mm-ddThh:mmZ:
angegeben. Das Pattern dazu lautet:
20(\d{2}(\-(0[13578]|1[02])\-(0[1-9]|[12]\d|3[01])|\-02\- (0[1-9]|1\d|2[0-8])|\-(0[469]|11)\-(0[1-9]|[12]\d|30)) |([02468][048]|[13579][26])\-02\-(29))T([01]\d|2[0-3]):[0-5] \dZ/20(\d{2}(\-(0[13578]|1[02])\-(0[1-9]|[12]\d|3[01])|\-02\- (0[1-9]|1\d|2[0-8])|\-(0[469]|11)\-(0[1-9]|[12]\d|30)) |([02468][048]|[13579][26])\-02\-(29))T([01]\d|2[0-3]):[0-5] \dZ
Können Sie bitte klarstellen, wie die TimePeriodCovered bzw. das TimeInterval korrekt anzugeben ist?
Grüße
Martin Schaumann
|
2022-05-23 17:53:24 |
Sehr geehrter Fragesteller,
für die Angabe der TimePeriodCovered und des TimeInterval ist die Variante
yyyy-mm-ddThh:mmZ/yyyy-mm-ddThh:mmZ
zu verwenden. Es handelt sich dabei um einen Fehler im Beispiel.
Viele Grüße,
Ihr Forum Datenformate |
Ja
|
Thomas Fellhauer |
Johannes Umbach |
Thomas Fellhauer |
Martin Schaumann |
|
Nein
|
In PG besprochen
-------------Katia Schubert-------------30.05.2022 16:34 |
Nein
|
Nein
|
|
Beschaffungsvorbehalt FB 1.0a
|
Abgeschlossen
|
Wie ist die TimePeriodCovered bzw. das TimeInterval korrekt anzugeben?
|
Es ist yyyy-mm-ddThh:mmZ/yyyy-mm-ddThh:mmZ für TimePeriodCovered und TimeInterval zu verwenden. |
23.05.2022
|
2022-01384 |
|
|
Sehr geehrtes Forum Datenformate,
in dem Format Beschaffungsvorbehalt (und anderen Formaten) ist bei TimePeriodCovered sowie auch bei TimeInterval ein Pattern und ein Beispiel angegeben. Leider scheint das Beispiel nicht mit dem Pattern übereinzustimmen.
Als Beispiel wird bei TimePeriodCovered :
yyyy-mm- ddThh:mmZ/yyyy-mmddThh:mmZ
und bei TimeInterval:
mmddThh: mmZ/yyyy-mm-ddThh:mmZ:
angegeben. Das Pattern dazu lautet:
20(\d{2}(\-(0[13578]|1[02])\-(0[1-9]|[12]\d|3[01])|\-02\- (0[1-9]|1\d|2[0-8])|\-(0[469]|11)\-(0[1-9]|[12]\d|30)) |([02468][048]|[13579][26])\-02\-(29))T([01]\d|2[0-3]):[0-5] \dZ/20(\d{2}(\-(0[13578]|1[02])\-(0[1-9]|[12]\d|3[01])|\-02\- (0[1-9]|1\d|2[0-8])|\-(0[469]|11)\-(0[1-9]|[12]\d|30)) |([02468][048]|[13579][26])\-02\-(29))T([01]\d|2[0-3]):[0-5] \dZ
Können Sie bitte klarstellen, wie die TimePeriodCovered bzw. das TimeInterval korrekt anzugeben ist?
Grüße
Martin Schaumann
|
2022-05-23 17:49:05 |
Sehr geehrter Fragesteller,
für die Angabe der TimePeriodCovered und des TimeInterval ist die Variante
yyyy-mm-ddThh:mmZ/yyyy-mm-ddThh:mmZ
zu verwenden. Es handelt sich dabei um einen Fehler im Beispiel.
Viele Grüße,
Ihr Forum Datenformate |
Ja
|
Jennifer Collin |
Erik Haus |
Jennifer Collin |
Martin Schaumann |
|
Nein
|
-------------Jennifer Collin-------------30.05.2022 09:26
In PG besprochen
-------------Katia Schubert-------------30.05.2022 16:34 |
Nein
|
Nein
|
|
AcknowledgementDocument FB 1.0a
|
Abgeschlossen
|
Ist im QuantityTimeInterval das Pattern oder das Beispiel korrekt?
|
Das Pattern des Elements QuantityTimeInterval ist korrekt, Beispiel müsste lauten: yyyy-mm-ddThh:mmZ/yyyy-mm-ddThh:mmZ |
23.05.2022
|
2022-01383 |
|
|
Sehr geehrtes Forum Datenformate,
im ACK Format (und anderen Formaten) ist bei QuantityTimeInterval (das Feld und damit den Fehler gibt es im ACK mehrmals) ein Pattern und ein Beispiel angegeben. Leider scheint das Beispiel nicht mit dem Pattern übereinzustimmen.
Als Beispiel wird hier:
yyyy-mmddThh:mmZ/yyyy-mm-ddThh:mmZ:
angegeben. Das Pattern dazu lautet:
20(\d{2}(\-(0[13578]|1[02])\-(0[1-9]|[12]\d|3[01])|\-02\- (0[1-9]|1\d|2[0-8])|\-(0[469]|11)\-(0[1-9]|[12]\d|30)) |([02468][048]|[13579][26])\-02\-(29))T([01]\d|2[0-3]):[0-5] \dZ/20(\d{2}(\-(0[13578]|1[02])\-(0[1-9]|[12]\d|3[01])|\-02\- (0[1-9]|1\d|2[0-8])|\-(0[469]|11)\-(0[1-9]|[12]\d|30)) |([02468][048]|[13579][26])\-02\-(29))T([01]\d|2[0-3]):[0-5] \dZ
Können Sie bitte klarstellen, wie das Feld QuantityTimeInterval korrekt anzugeben ist?
Gruß
Martin Schaumann
|
2022-05-23 17:46:06 |
Sehr geehrter Fragensteller,
vielen Dank für Ihre Frage. Das in der Formatbeschreibung angegebene Pattern des Elements QuantityTimeInterval ist korrekt. Das dort beschriebene Beispiel ist jedoch fehlerhaft. Korrekterweise müsste es wie folgt lauten:yyyy-mm-ddThh:mmZ/yyyy-mm-ddThh:mmZ
Mit freundlichem Gruß
Ihr BDEW-Forum Datenformate |
Ja
|
Martin Schaumann |
Torsten Henning |
Martin Schaumann |
Martin Schaumann |
|
Nein
|
In PG besprochen
-------------Katia Schubert-------------30.05.2022 16:34
|
Nein
|
Nein
|
|
PARTIN AHB 1.0a
|
Abgeschlossen
|
Muss ein Zahlungsavis auf Basis des Rechnungstyps sortenrein sein und welche Bankverbindung aus der PARTIN wird verwendet?
|
Ein Zahlungsavis muss nicht sortenrein sein und es wird empfohlen in der PARTIN überall dieselbe Bankverbindung einzutragen. |
12.04.2022
|
2022-01337 |
|
|
Sehr geehrtes Forum Datenformate,
wir haben eine Frage zum Zusammenspiel der REMADV (Zahlungsavis) und der in der PARTIN angegebenen unterschiedlichen Bankverbindungen.
Ausgangssituation 1:
Der Rechnungsersteller (z. B. NB) erhält vom Rechnungsempfänger (z. B. LF) ein Zahlungsavis (Anwendungsfall dem der Prüfidentifikator 33001 zugeordnet ist).
In diesem Zahlungsavis sind die Zahlungsinformationen zu mehreren Rechnungen unterschiedlicher Rechnungstypen enthalten (z. B. NN-Rechnung (Prüfidentifikator 31002) und MMM-Rechnung (Prüfidentifikator 31005)).
Die Summe des Zahlungsavises weist einen positiven Überweisungsbetrag aus (Forderung des Rechnungsstellers ggü. dem Rechnungsempfänger, (im Beispiel also NB ggü. LF)).
Welche Bankverbindung des Rechnungsstellers verwendet der Rechnungsempfänger aus der PARTIN, um den Betrag gemäß Zahlungsavis zu überweisen, wenn der Rechnungssteller unterschiedliche Bankverbindungen für Zahlungen aus der Netznutzungsabrechnung und Zahlungen aus der MMM-Abrechnung in der PARTIN genannt hat?
Ausgangssituation 2:
Der Rechnungsersteller (z. B. NB) erhält vom Rechnungsempfänger (z. B. LF) ein Zahlungsavis (Anwendungsfall dem der Prüfidentifikator 33001 zugeordnet ist).
In diesem Zahlungsavis sind die Zahlungsinformationen zu mehreren Rechnungen unterschiedlicher Rechnungstypen enthalten (z. B. NN-Rechnung (Prüfidentifikator 31002) und MMM-Rechnung (Prüfidentifikator 31005)).
Die Summe des Zahlungsavises weist einen negativen Überweisungsbetrag aus (Forderung des Rechnungsempfängers ggü. dem Rechnungssteller, (im Beispiel also LF ggü. NB)).
Welche Bankverbindung des Rechnungsempfängers verwendet der Rechnungssteller aus der PARTIN, um den Betrag gemäß Zahlungsavis zu überweisen, wenn der Rechnungsempfänger unterschiedliche Bankverbindungen für Zahlungen aus der Netznutzungsabrechnung und Zahlungen aus der MMM-Abrechnung in der PARTIN genannt hat?
|
2022-04-12 17:12:04 |
Sehr geehrter Marktpartner,
vielen Dank für Ihre Frage.
Es ist korrekt, dass in der PARTIN unterschiedliche Bankverbindungen für die unterschiedlichen Verwendungszwecke genannt sein können.
Wie Sie richtig schreiben, dürfen in Zahlungsavisen die Rechnungsbeträge unterschiedlicher Rechnungstypen zusammengefasst werden, und es muss keine Aufteilung des Überweisungsbetrags stattfinden. Zudem kann der Rechnungssteller nicht auf ein sortenreines Zahlungsavis (getrennt nach ursprünglichen Rechnungstypen) bestehen.
Somit muss sich derjenige, der den Betrag des Zahlungsavises zu überweisen hat für eines der Bankkonten des Zahlungsempfängers entscheiden, wenn der Zahlungsempfänger für unterschiedliche Rechnungstypen unterschiedliche Konten angegeben hat und das Zahlungsavis die Rechnungsbeträge unterschiedlicher Rechnungstypen enthält.
Wir empfehlen allen Marktpartnern in der PARTIN dieselbe Bankverbindung für alle Verwendungszwecke einzutragen.
Sind im Kontaktdatenblatt des Zahlungsempfängers unterschiedliche Bankverbindungen zu den unterschiedlichen Zwecken genannt, so kann der Anweisende der Zahlung eine im Kontaktdatenblatt genannte Bankverbindung auswählen. Die Korrekte Zuordnung liegt in diesem Falle beim Zahlungsempfänger, dieser hat die korrekte Verarbeitung sicherzustellen.
Freundliche Grüße
Ihre BDEW-Forum Datenformate |
Ja
|
Gregor Scholtyschik |
Beate Becker |
Thomas Fellhauer |
Thomas Fellhauer |
Bankverbindung |
Nein
|
-wie in EDI@Energy Besprochen am 12.04.2022
------------Thomas Fellhauer-------------12.04.2022 17:13
|
Nein
|
Nein
|
|
Stammdaten AWT 1.0
|
Abgeschlossen
|
Ist die Angabe von thermischen Zeiten für den Energieträger B16 (Solare Strahlungsenergie) verpflichtend?
|
Nein, für B16 (Solare Strahlungsenergie) sind die thermischen Zeiten nicht anzugeben. |
08.03.2022
|
2022-01310 |
|
|
Sehr geehrtes Team der edi@energy,
uns wurden Anlagenmeldungen mit dem Energieträger B16 mit der folgenden Begründung abgelehnt: "Die thermischen Zeiten müssen für SEE, die mit thermischen Prozessen betrieben werden (d.h. wenn Energieträger B01, B02, B03, B04, B05, B06, B09, B14, B15, B17, oder B20 vorhanden) und für steuerbare Ressourcen mit einer installierten Bruttonennleistung von > 1 MW angegeben werden". Nun steht im der AWT in der Fußnote [8]: "Nur bei SEE, die mit thermischen Prozessen betrieben werden (d.h. wenn Energietraeger mit B01|B02|B03|B04|B05|B06|B09|B14|B15|B17|B20 vorhanden)". Für uns stellt sich die Frage, welches der beiden Kriterien ausschlaggebened ist. Wir vermuten dass die Fußnote [8] der AWT das sinnvollste Kriterium ist, da diese Daten für beispielsweise Solaranlagen obsolet wären.
Können wir in diesem Fall davon ausgehen, dass hier ein Fehler seitens Raida/Connect+ vorliegt oder entspricht die Fehlerbeschreibung dem tatsächlichen Kriterium?
|
2022-03-08 16:08:32 |
Sehr geehrter Fragesteller,
wie Sie bereits korrekt aus der Fußnote [8] der Anwendungstabelle zitiert haben, ist bei der Angabe des Energieträgers B16 (Solare Strahlungsenergie) die Angabe der „thermischen Zeiten“ nicht notwendig, da diese im Fall einer PV-Anlage gar nicht vorhanden sind.
Freundliche Grüße
Ihr Forum Datenformate |
Ja
|
Johannes Umbach |
Alexander Kramer |
Johannes Umbach |
Daniel Wagner |
Stammdaten AWT Seite 30: [8] Nur bei SEE, die mit thermischen Prozessen betrieben werden (d.h. wenn Energietraeger mit B01|B02|B03|B04|B05|B06|B09|B14|B15|B17|B20 vorhanden) |
Nein
|
-------------Johannes Umbach-------------15.03.2022 23:46
Vorbereitet für PG
in PG besprochen.
-------------Katia Schubert-------------24.03.2022 16:58
|
Nein
|
Nein
|
|
Stammdaten AWT 1.0
|
Abgeschlossen
|
Ist beim Element "Zuordnung_Speicher" das Feld bei der Meldung angereicherter Stammdaten eine verpflichtende Meldung für SEE vorzusehen?
|
Ja, für SEE mit zugeordneten Speichern ist dies an dieser Stelle verpflichtend anzugeben. |
28.01.2022
|
2022-01264 |
|
|
Hallo Forum Datenformate,
ich habe eine Frage zu den Bedingungen des Stammdaten-Formats des Redispatch 2.0.
Bei angereicherten Meldungen steht im AWT bei dem Feld "Zuordnung_Speicher" die Bedingung [9] (Wenn Typ mit SEE angegeben), im Gegensatz zu allen anderen Bedingungen fehlt hier allerdings ein "x" für Pflicht oder "o" für optional.
Daher ist nicht ersichtlich, ob bei Erfüllung der Bedingung die Zuordnung des Speichers Pflicht oder Wahl ist.
Aktuell gehen wir davon aus, dass es sich in diesem Fall um ein Wahlfeld handelt, wie sehen sie das?
Beste Grüße aus Aachen,
Jonas Diefenthal
|
2022-01-28 09:05:32 |
Sehr geehrter Herr Diefenthal,
wenn die TR vom Typ SEE ist und einen Speicher zugeordnet hat, ist die Angabe verpflichtend. Da es auch SEE ohne zugeordneten Speicher gibt, ist dies kein Pflichtfeld für alle SEE.
Mit freundlichem Gruß
Ihr BDEW-Forum Datenformate |
Ja
|
Johannes Umbach |
Henning Hots |
Johannes Umbach |
Jonas Diefenthal |
|
Nein
|
-------------Johannes Umbach-------------01.02.2022 21:41
Antworten für Abstimmung in PG vorbereitet
-------------Katia Schubert-------------02.02.2022 10:29
in PG besprochen |
Nein
|
Nein
|
|
Stammdaten AWT 1.0
|
Abgeschlossen
|
Umgang mit Angabe energieträgerspezifischer Daten und Nicht-Angabe des Energieträgers bei der initialen Stammdatenmeldung.
|
Die Angaben vorhandenen Angaben in der AWT sind konform mit der Festlegung BK6-20-061. |
20.01.2022
|
2022-01251 |
|
|
Hallo Forum Datenformate,
ich habe eine Frage zu den Bedingungen des Stammdaten-Formats des Redispatch 2.0.
Laut AWT Bedingung [8] dürfen Mindestbetriebszeit, Mindeststillstandzeit, Anfahrtzeit kalt/warm, Hochfahrzeitkalt/warm und Abfahrzeit nur bei bestimmten Energieträgern und auch nur bei SEEs versendet werden.
In initialen Meldungen ist allerdings kein Energieträger enthalten und eine Steuerbare Ressource, die diese Felder enthält, kann sowohl SEEs als auch SSEs gleichzeitig enthalten.
Daher ist nicht klar zu erkennen, wann die besagten Informationen gesendet werden müssen.
Dies betrifft sowohl das aktuelle als auch das zukünftige AWT der Stammdaten.
Wir gehen davon aus, dass entweder die Bedingung falsch ist oder das Feld Energieträger übermittelt werden müsste.
Sehen sie das genauso?
Beste Grüße aus Aachen,
Jonas Diefenthal
|
2022-01-20 14:41:41 |
Sehr geehrter Herr Diefenthal,
der Umfang der Stammdatenmeldung im Use-Case "Übermittlung von initialen Stammdaten" ergibt sich aus dem Festlegungsverfahren zur Informationsbereitstellung für Redispatch-Maßnahmen der Bundesnetzagentur (BK6-20-061). Hierin sind die von Ihnen angesprochenen Elemente enthalten, das ebenfalls von Ihnen angesprochene Element "Energieträger" hingegen nicht. Daher ist die aktuelle Ausprägung korrekt.
Die Angabe des "Energieträgers" ist erst in der Stammdatenanreicherung für den ANB ein Pflichfeld.
Mit freundlichem Gruß
Ihr BDEW-Forum Datenformate |
Ja
|
Johannes Umbach |
Henning Hots |
Johannes Umbach |
Jonas Diefenthal |
|
Nein
|
-------------Johannes Umbach-------------22.01.2022 05:50
zur Freigabe in PG
-------------Katia Schubert-------------25.01.2022 08:34
in PG besprochen |
Nein
|
Nein
|
|
Stammdaten AWT 1.0
|
Abgeschlossen
|
Gibt es eine Legende zu den verwendeten Symbolen/Werten in den Anwendungstabellen?
|
Eine Erläuterung steht in den Allgemeinen Festlegungen in Kapitel 6.18 Hinweise zum Lesen der Anwendungstabellen. |
24.06.2021
|
2021-01039 |
|
|
Gibt es eine Legende zu den verwendeten Symbolen/Werten in der Tabelle "Stammdaten AWT 1.0"?
|
2021-06-24 12:29:38 |
Sehr geehrter Fragesteller,
eine Erläuterung der verwendeten Symbole in den Anwendungstabellen für die Redispatch XML-Datenformate finden Sie in den Allgemeinen Festlegungen (ALF) in der Version 5.0 in Kapitel 6.18 Hinweise zum Lesen der Anwendungstabellen (AWT). Die Allgemeinen Festlegungen sind auf der EDI@Energy Plattform unter der Gruppierung "Formatübergreifende Dokumente" zu finden.
Eine Häufigkeit "0..1" bedeutet, dass dieses Element/Attribut technisch optional ist, da die Angabe nicht für jeden Prozess erforderlich ist. In den Use Case-Spalten und Zellen der AWT ist angegeben, für welche Prozesse und Prozessschritte diese Elemente/Attribute zu befüllen sind.
Mit freundlichem Gruß
Ihr BDEW-Forum Datenformate |
Ja
|
Sara Olszewski |
Henning Hots |
Sara Olszewski |
Julian Schweins |
Konkret geht es darum,
1) welche Bedeutung die "x" und leeres "Kreis-Symbol" in der AWT haben und
2) ob eine Häufigkeit "0..1" bedeutet, dass dieses Element/Attribut optional und nicht "required" ist? Sind nur Elemente/Attribute mit Häufigkeit "1..." und "required" verpflichtende Stammdaten?
Die verdwendeten Codes (z.B. Z01 etc.) sind soweit gut in der Formatbeschreibung erläutert. |
Nein
|
Wie in PG besprochen.
-------------Katia Schubert-------------27.07.2021 11:21
|
Nein
|
Nein
|
|
Stammdaten AWT 1.0
|
Abgeschlossen
|
Ist die Angabe des Lastgradienten immer erforderlich?
|
Nein, die Angabe des Lastgradienten ist nicht immer erforderlich. |
08.06.2021
|
2021-01028 |
|
|
Die Bundesnetzagentur schreibt in "Festlegungsverfahren zur Informationsbereitstellung für Redispatch-Maßnahmen (BK6-20-061), Anlage Informationsbereitstellung für Redispatch-Maßnahmen" folgendes zu den Lastgradienten in den Stammdaten (S. 9):
"Darunter ist die durchschnittliche Leistungsänderungsgeschwindigkeit
innerhalb des Leistungsbereiches zwischen Mindesterzeugungsleistung
und Nennleistung bei Leistungserhöhung, abgeleitet aus der
Zeitdauer der Leistungsänderung zwischen Mindesterzeugungsleistung
und Nennleistung, zu verstehen. Die Mitteilung ist nur bei Lastgradienten
kleiner 20 % PROD_nenn pro Minute erforderlich."
Die Angabe der Lastgradienten ist also nicht für jede SR erforderlich. Im XML-Schema sind die Lastgradienten jedoch (auch nach den Anpassungen vom 03.06.) Pflichtfelder. Wie passt das zusammen? Handelt es sich hier um einen Fehler im XML-Schema? Oder gibt es hier einen Default-Wert, den man setzen kann, wenn eine Angabe nicht erforderlich ist?
|
2021-06-08 16:50:45 |
Sehr geehrter Marktteilnehmer,
vielen Dank für den Hinweis. Wir stimmen Ihnen zu und werden dies über eine konsolidierte Lesefassung mit Fehlerkorrekturen korrigieren.
Freundliche Grüße,
Ihr BDEW-Forum Datenformate |
Ja
|
Sara Olszewski |
Henning Hots |
Sara Olszewski |
Malte Otten |
|
Nein
|
|
Nein
|
Nein
|
|
ActivationDocument FB 1.0
|
Abgeschlossen
|
Was bedeutet: "Die DocumentIdentification hat je Absender und je Dokumententyp eindeutig zu sein."?
|
Die DocumentIdentification muss je Absender und Dokumententyp eindeutig sein. Bei Aktualisierungen dieses Dokuments wird es bei gleicher DocumentIdentification mit einer höheren Version gesendet. |
03.03.2022
|
2022-01308 |
|
|
Sehr geehrte Damen und Herren,
in der Beschreibung zur Documentenidentification heißt es: "Die DocumentIdentification hat je Absender und je
Dokumententyp eindeutig zu sein. Bei der Bildung der Identifikation ist auf Groß- und Kleinschreibung zu achten
(case-sensitive)."
Wir haben bis zu 73 Versionen für Aktivierungen je Anlage als Lieferant erhalten. Die in den Nachrichten verwendete DocumentIdentification war in jeder Version dieselbe. Nun fragen wir uns ob dies so korrekt sein kann und wir evtl. etwas nicht korrekt interpretiert haben.
Vielen Dank im Voraus für Ihre Antwort.
|
2022-03-03 16:05:23 |
Sehr geehrte Fragestellerin,
der von Ihnen geschilderte Sachverhalt klingt plausibel. Im konkreten Fall des ActivationDocument bezieht sich eine Nachricht auf einen konkreten Tag. Das bedeutet, dass es sich für einen Tag hinsichtlich der DocumentIdentification um ein Dokument und somit eine DocumentIdentification handelt. Auftretende Aktualisierungen dieses Dokuments, wie bspw. neue Abrufe, werden somit mit der DocumentIdentification der erstmalig für den Tag, sowie der Kombination aus Absender und Dokumententyp, versandten Nachricht mit einer entsprechend höheren Version versendet.
Freundliche Grüße,Ihr Forum Datenformate |
Ja
|
Johannes Umbach |
Henrike Janissen |
Johannes Umbach |
Grit Neumann |
|
Nein
|
-------------Johannes Umbach-------------15.03.2022 23:19
Vorbereitet für PG
in PG besprochen.
-------------Katia Schubert-------------24.03.2022 16:55
|
Nein
|
Nein
|
|
ActivationDocument FB 1.0
|
Abgeschlossen
|
Woher weiß der EIV, wie eine Anlage im Prognosemodell bei Abruf im Aufforderungsfall fahren muss?
|
Bei Anlagen im Prognosemodell und Aufforderungsfall muss der Abruf als Sollwertabruf durchgeführt werden. |
10.01.2022
|
2022-01234 |
|
|
Als Vorgabe des Netzbetreibers per Abruf (ActivationDocument) sind Delta-Anweisungen (in MW) oder Sollwertanweisungen (in %) möglich. Es ist aber nicht vorgesehen, die vorgegebene Fahrweise in MW angeben zu können.
Die Fragen dazu:
1. Ist es richtig, dass sich der tatsächlich vorgeschriebene Abruf als Differenz zu den ursprünglich abgegebenen Planungsdaten (im Planwertmodell) bzw. zur Prognose des Netzbetreibers (im Prognosemodell) ergibt?
2. Wie kann der EIV im Prognosemodell/Aufforderungsfall wissen, wie die Anlage gefahren werden muss? Ihm ist nur die Delta-Anweisung bekannt, nicht aber die Bezugsgröße, also die ursprünglich vorgesehene Fahrweise.
|
2022-01-10 15:13:29 |
Sehr geehrte Fragestellerin,
bei Anlagen im Prognosemodell und Aufforderungsfall muss der Abruf als Sollwertabruf durchgeführt werden, damit der EIV die Anlage entsprechend richtig steuern kann. Ein Deltaabruf kann nur mit Anlagen im Planwertmodell durchgeführt werden, da sich die Fahrweise nach Abruf aus der geplanten Leistung abzüglich der abgerufenen Deltamenge ergibt.
Viele Grüße,
Ihr BDEW-Forum Datenformate |
Ja
|
Johannes Umbach |
Henrike Janissen |
Johannes Umbach |
Johannes Umbach |
|
Nein
|
-------------Johannes Umbach-------------10.01.2022 15:14
Fragen erstellt
-------------Johannes Umbach-------------11.01.2022 21:21
Anworten hinzugefügt, fertig für Besprechung
-------------Katia Schubert-------------12.01.2022 16:13
in PG besprochen |
Nein
|
Nein
|
|
PlannedResourceScheduleDocument FB 1.0
|
Eingegangen
|
Wie ist der Zusammenhang der Leistungswerte Pmin und wRDV- bei Meldung der Planungsdaten?
|
Für wRDV- ist maximal die Differenz aus PROD und Pmin zulässig. |
01.03.2022
|
2022-01304 |
|
|
Ich habe eine Frage zum Zusammenhang der Werte Pmin und RDV- bei den Planungsdaten.
Eine KWK Anlage mit den Stammdaten:
Bruttonennleistung: 2MW
Fahrbare_Mindesterzeugungsleistung: 1MW
soll für den Zeitraum X in Vollast laufen.
Die Anlage nimmt nicht am Regelleistungsmarkt teil und es gibt keine technischen Einschränkungen.
Bei den Planungsdaten werden folgende Werte übermittelt:
PROD = 2MW
PMAX = 2MW
RDA+- = RDA-- = 0
PRL+- = SRL+- = 0
MRL+ = MRL- = 0
BES+ = BES- = 0
RDA+- = 0
wRDV- = 1MW? oder 2MW?
PMIN = 1MW?
Ist das korrekt so?
Die Anlage kann ja theoretisch auch komplett abgeschaltet werden. Ist also für das negative Redispatchvermögen die Differenz aus PROD und Pmin oder der gleicher Wert wie in PROD anzugeben?
Gibt es ein Dokumente wo die Werte genauer beschrieben sind als im Dokument "BDEW-Branchenlösung Redispatch 2.0 - Datenaustausch-, Bilanzierungs- und Abrechnungsprozesse - Mai 2020"?
|
2022-03-01 10:08:14 |
Sehr geehrter Fragesteller,
das negative wärmegebundene Redispatchvermögen (wRDV-) entspricht der aktivierbaren Wirkleistungsreduzierung einer hocheffizienten KWK-Anlage. Das negative Redispatchvermögen (RDV-) entspricht der aktivierbaren freien elektrischen Leistung einer Anlage in negativer Richtung ohne einen Eingriff in die Kraft-Wärme-Kopplung.
In diesem Fall entspricht der Wert für wRDV- maximal der Differenz aus PROD und Pmin. Folglich ist wRDV- = 1 MW zu melden.
Auch wenn kein RDV vorhanden ist, müssen die Zeitreihen für RDV mitgemeldet werden.
Der Zusammenhang der Leistungswerte wird im Dokument "BDEW-Branchenlösung Redispatch 2.0 - Datenaustausch-, Bilanzierungs- und Abrechnungsprozesse - Mai 2020" in Kapitel 1.3 in der Abbildung auf Seite 171 veranschaulicht.
Mit freundlichem Gruß
Ihr BDEW-Forum Datenformate |
Ja
|
Martin Schaumann |
Gina Völsgen |
Martin Schaumann |
Dennis Atabay |
|
Nein
|
in PG besprochen
-------------Katia Schubert-------------24.03.2022 16:41
|
Nein
|
Nein
|
|
PlannedResourceScheduleDocument FB 1.0
|
Eingegangen
|
Welche Meldung muss durch den EIV erfolgen, wenn der Abruf des ANB durch den EIV nicht erfüllt werden kann?
|
Der EIV übermittelt eine Aktualisierung der Planungsdaten an den ANB |
28.02.2022
|
2022-01301 |
|
|
Ich habe eine Frage zur Übermittlung von Planungsdaten für folgenden Anwendungsfall:
D-2:
Für Zeitraum X wurden bereits Planungsdaten vom EIV an den ANB mit den Werten PROD=10, RDV+=0, RDV-=5, RDA-=0, RDA+=0 übermittelt.
H-4 (4h vor Zeitraum X):
De EIV sendet auf Grund technischer Einschränkungen angepasste Planungsdaten mit dem Werten PROD=5, RDV+=0, RDV-=0, RDA-=0, RDA+=0
Der ANB sendet nahezu zeitgleich einen Abruf für Zeitraum X (Sollwertvorgabe) mit dem Wert 7 (bzw. 70%), bei dem die aktualisierten Planungsdaten noch nicht berücksichtigt sind.
Wie ist das weitere vorgehen seitens des EIVs bzw. ANBs?
Welche Daten müssen nun vom wem gesendet werden und wie sähen die entsprechenden Werte aus?
|
2022-02-28 19:20:17 |
Sehr geehrter Fragesteller,
der EIV schickt gemäß Use Case 3.1 (Anlage 2, FL BK6-20-059) als Antwort auf einen RD-Abruf des ANB eine Aktualisierung der Planungsdaten. Aus den gesendeten Planungsdaten des EIV ist ersichtlich, ob der Abruf durchgeführt werden kann.
Im oben beschriebenen Anwendungsfall hat der anfNB anhand der aktualisierten Planungsdaten seinen Abruf erneut zu dimensionieren.
Mit freundlichem Gruß
Ihr BDEW-Forum Datenformate |
Ja
|
Martin Schaumann |
Gina Völsgen |
Martin Schaumann |
Dennis Atabay |
|
Nein
|
in PG besprochen
-------------Katia Schubert-------------17.03.2022 11:37
|
Nein
|
Nein
|
|
PlannedResourceScheduleDocument FB 1.0
|
Eingegangen
|
Wie ist RDA+/RDA- im Störungsfall zu melden?
|
Im Störungsfall ist RDA+/RDA- = 0 zu melden |
28.02.2022
|
2022-01300 |
|
|
Ich habe eine Frage zu den in den Planungsdaten zu übermittelnden Werten RDA+ und RDA- in folgendem Anwendungsbeispiel:
D-2:
Für Zeitraum X wurden bereits Planungsdaten vom EIV an den ANB mit den Werten PROD=10, RDV+=0, RDV-=5, RDA-=0, RDA+=0 übermittelt.
H-4 (4h vor Zeitraum X):
Der ANB sendet einen Abruf für Zeitraum X (Sollwertvorgabe) mit dem Wert 7 (bzw. 70%)
De EIV sendet daraufhin angepasste Planungsdaten mit dem Werten PROD=7, RDV+=3, RDV-=2, RDA-=3, RDA+=0
H-2 (2h vor Zeitraum X):
Die Anlage hat einen ungeplanten Störungsfall der über den Zeitraum X hinaus bestehen wird.
Der EIV sendet aktualisierte Planungsdaten mit den Werten PROD=0, RDV+=0, RDV-=0
Wie sind hierbei die Werte "RDA+" bzw. "RDA-" zu wählen?
|
2022-02-28 19:16:45 |
Sehr geehrter Fragesteller,
im Störungsfall, der eine vollständige Nichtverfügbarkeit zur Folge hat, ist RDA+/RDA- = 0 zu melden. Dies gilt sowohl für eine geplante als auch ungeplante Nichtverfügbarkeit.
Mit freundlichem Gruß
Ihr BDEW-Forum Datenformate |
Ja
|
Martin Schaumann |
Gina Völsgen |
Martin Schaumann |
Dennis Atabay |
|
Nein
|
in PG besprochen
-------------Katia Schubert-------------17.03.2022 11:23
|
Nein
|
Nein
|
|
PlannedResourceScheduleDocument FB 1.0
|
Abgeschlossen
|
Ist das Pattern zu den Zeitintervallangaben in den Planungsdaten richtig?
|
Pattern mit dem Flavor PCRE2 (PHP>=7.3) wird bei Zeitintervallangaben nicht akzeptiert. |
27.07.2021
|
2021-01066 |
|
|
Wird das Pattern der Elemente TimePeriodCovered/v und Period/TimeInterval/v (d.h. den Zeitintervallangaben) in den Planungsdaten immer als Regulärer Ausdruck akzeptiert?
|
2021-07-27 11:13:40 |
Sehr geehrte Fragestellerin,
bei der Überprüfung von Pattern einer XML-Schema-Datei können unterschiedliche Flavor verwendet werden. Bei dem Pattern der Elemente TimePeriodCovered/v und Period/TimeInterval/v (d.h. den Zeitintervallangaben) wird das Trennzeichen / zwischen beiden Zeitangaben von dem Flavor PCRE2 (PHP>=7.3) nicht akzeptiert. Bei den anderen gängigen Flavor, wie z.B. Java 8, Python oder auch PCRE (PHP<7.3) wird das Pattern immer akzeptiert.
Hinweis: Dies betrifft auch andere XML-Datenformate mit Zeitintervallangaben.
Mit freundlichem Gruß
Ihr BDEW-Forum Datenformate |
Ja
|
Martin Schaumann |
Gina Völsgen |
Martin Schaumann |
|
|
Nein
|
Frage und Antwort wie in der PG besprochen
-------------Katia Schubert-------------27.07.2021 11:14
|
Nein
|
Nein
|
|
PlannedResourceScheduleDocument FB 1.0
|
Abgeschlossen
|
Welcher Wert wird zu den Zeitintervallen übermittelt, in denen keine Abruf-Information vorliegt?
|
Wenn keine Abruf-Information vorliegt, wäre in dem Fall, dass ein Sollwert übermittelt werden muss, der Wert 100% (Pmax) einzutragen. Bei einem Deltaabruf wäre der Wert in diesem Fall 0. |
09.07.2021
|
2021-01051 |
|
|
Sehr geehrte Damen und Herren,
ich habe eine Frage zum Use Case "Übermittlung prognostizierter Abrufe":
Situation:
- Übermittlung eines prognostizierten Abrufs für den Folgetag als Sollwert: Konkret soll eine SR mit einer Nennleistung von 1 MW am Folgetag zwischen 9 und 15 Uhr auf 0.6 MW beschränkt werden.
Information aus den Dokumenten
- Der Abruf bezieht sich immer auf einen vollständigen Kalendertag, also den kompletten Folgetag
- Laut FB Seite 11 "TimeInterval" muss das Zeitintervall bei Übermittlung von Abrufen für den Folgetag immer den vollständigen Tag enthalten
- Laut FB Seite 12 "Interval" müssen alle 92-100 Zeitintervalle innerhalb von "TimeInterval" übermittelt werden
Die Frage ist nun:
Welcher Wert wird zu den Zeitintervallen übermittelt, an denen keine Abruf-Information vorliegt, im Beispiel zwischen 0:00 - 8:45 und 15:15 - 23:45?
Ist das die Nennleistung der Anlage?
Fall ja, wie geht man dann mit Abrufen um, die die Einspeisung nach unten statt nach oben begrenzen?
Vielen Dank und viele Grüße
Arnd Krönig.
|
2021-07-09 21:57:35 |
Sehr geehrter Herr Krönig,
die Nennleistung einer Anlage ist nicht zu nennen. Es kann entweder ein Sollwert oder Deltawert übermittelt werden.
Wenn keine Abruf-Information vorliegt, wäre in dem Fall, dass ein Sollwert übermittelt werden muss, der Wert 100% (Pmax) einzutragen. Bei einem Deltaabruf wäre der Wert in diesem Fall 0.
Siehe dafür auch Detailprozesse für die Netzbetreiberkoordination im Redispatch 2.0, Kapitel Datenpunkte zu Use-Case 2.3.: Übermittlung prognostizierter Abruf und Info über Abruf über Planungsdaten auf Seite 54.
Mit freundlichem Gruß
Ihr BDEW-Forum Datenformate |
Ja
|
Stephan Schlunke |
Gina Völsgen |
|
Arnd Krönig |
|
Nein
|
in PG beantwortet
-------------Katia Schubert-------------14.07.2021 09:10
|
Nein
|
Nein
|
|
PlannedResourceScheduleDocument XSD - informatorische Lesefassung 1.0
|
Abgeschlossen
|
Wie ist der Zusammenhang der Leistungswerte Pmin, PROD und MRL- bei Meldung der Planungsdaten?
|
Pmin entspricht der Mindestleistung einer SEE. MRL- kann über Pmin hinaus gehen. |
01.03.2022
|
2022-01303 |
|
|
Ich habe eine Frage zum Zusammenhang der Werte Pmin und den RL Werten bei den Planungsdaten.
Eine KWK Anlage mit den Stammdaten:
Bruttonennleistung: 2MW
Fahrbare_Mindesterzeugungsleistung: 1MW
soll für den Zeitraum X in Vollast laufen.
Die Anlage nimmt am Regelleistungsmarkt teil und hat für den Zeitraum negative Minutenreserveleistung von 2 MW gemeldet.
Bei den Planungsdaten werden folgende Werte übermittelt:
PROD = 2MW
PMAX = 2MW
RDA+- = RDV+- = 0
PRL+- = SRL+- = 0
MRL+ = 0
MRL- = 2MW
PMIN = 1MW
Ist das korrekt so?
Oder muss PMIN auf 0 gesetzt werden? Oder ist für MRL- maximal die Differenz aus PROD und PMIN zulässig?
Gibt es ein Dokumente wo die Werte genauer beschrieben sind als im Dokument "BDEW-Branchenlösung Redispatch 2.0 - Datenaustausch-, Bilanzierungs- und Abrechnungsprozesse - Mai 2020"?
|
2022-03-01 09:58:51 |
Sehr geehrter Fragesteller,
die Mindestleistung Pmin (Produktion) einer SEE oder SSE ist die minimal elektrisch stabil erzeugbare Leistung (untere Leistungsgrenze), siehe Datenpunkt 2.2 der BNetzA-Festlegung BK6-20-061, Anlage 1. Somit muss in diesem Beispiel Pmin = 1 MW gemeldet werden.
Weil in diesem Fall MRL- = 2 MW ist, schließt die Regelleistungsscheibe Pmin ein.
Mit freundlichem Gruß
Ihr BDEW-Forum Datenformate |
Ja
|
Martin Schaumann |
Gina Völsgen |
|
Dennis Atabay |
|
Nein
|
in PG besprochen
-------------Katia Schubert-------------07.11.2022 11:10
|
Nein
|
Nein
|
|
UTILMD AHB GPKE / GeLi Gas 6.1c
|
Eingegangen
|
Welche OBIS-Kennzahlen werden an der Messlokation ausgetauscht?
|
Es werden nur benötigte OBIS-Codes zur Bildung der Energiemenge der Marktlokation übermittelt |
17.02.2022
|
2022-01278 |
|
|
Sehr geehrte Damen und Herren,
wir sind seit einiger Zeit in einem Konzessionsgebiet Grundversorger in der Sparte Strom. In den Anmeldungen zur EoG erhalten wie neben den benötigten OBIS-Codes an der Messlokation, welche zur Bildung der Energiemenge an der Marktlokation nötig sind, auch weitere OBIS-Codes.
Wir sind der Meinung, dass wird lediglich die Werte erhalten dürfen, die für die Bildung der Energiemenge der Marktlokation benötigt werden und aus diesem Grund vom MSB an uns übermittelt werden müssen. Der NB sendet in den Stammdaten jedoch sämtliche OBIS-Codes, welche an der Messlokation vorhanden sind.
Ist unsere Interpretation korrekt, dass nur die benötigten OBIS-Codes zur Bildung der Energiemenge der Marktlokation in Stammdaten vom NB enthalten sein dürfen?
Viele Dank.
|
2022-02-17 08:00:28 |
Sehr geehrter Marktteilnehmer,
der NB übermittelt in den Stammdaten (in diesem Fall in der Anmeldung EoG) die OBIS-Kennzahlen an der Marktlokation mit den dazugehörigen Verwendungszwecken. In der vom NB an den LF zu übermittelnden Berechnungsformel ist die Bildung der Energiemenge an der Marktlokation beschrieben.
OBIS-Codes der Messlokation für Werte, welche gemäß der Berechnungsformel für die relevante und in der EoG genannte Marktlokation nicht benötigt bzw. genutzt werden, dürfen in den Stammdaten vom NB nicht an den LF kommuniziert werden.
Die Grundlage für die Aussage ist in der Bedingung [323] in Anwendungsfall 11013 "Anmeldung EOG" am Segment "OBIS-Kennzahl der Zähleinrichtung / Mengenumwerter" hinterlegt:
"[323] Es sind alle OBIS- Kennzahlen gem. EDI@Energy Codeliste der OBIS-Kennzahlen und Medien für den deutschen Energiemarkt Kap. 3. anzugeben welche an der Zähleinrichtung genutzt werden, dabei muss der Mindestumfang aus Kap. 3.4 eingehalten werden"
Vielen Dank.
Ihr BDEW Forum Datenformate |
Ja
|
Holger Weickenmeier |
Thomas Seipt |
Holger Weickenmeier |
Sebastian Rieck |
|
Nein
|
Erster Entwurf der Antwort
-------------Gregor Scholtyschik-------------27.04.2022 08:40
Absprache mit Holger W. und Gregor S. zur Veröffentlichung.
-------------Gregor Scholtyschik-------------03.05.2022 16:03
|
Nein
|
Nein
|
|
Unavailability_MarketDocument FB 1.0a
|
Eingegangen
|
Wie sind Meldungen zu (dauerhaften) Nichtverfügbarkeiten durchzuführen?
|
Die Kraftwerksnichtverfügbarkeit ist regulär über das Unavailability_MarketDocument zu melden. |
27.01.2022
|
2022-01261 |
|
|
Bitte um Klärung wie Meldungen zu (dauerhaften) Nichtverfügbarkeiten durchzuführen sind, da die Spezifikation zwar das Datenformat definiert, aber leider inhaltlich unterschiedlich angewendet werden kann.
Frage/Fall 1: Dauerhafte Nichtverfügbarkeit: Eine Anlage/TR mit z.B. 320 kW installierter Leistung ist dauerhaft (z.B. wg. Eigenverbrauch) mit 30 kW als nichtverfügbar zu melden;
*) Wie soll diese Meldung erfolgen? Z.B. als Unavailability mit Versionierung der xml-Datei?
D.h. Bei Veränderung der dauerhaften NV wird der gleiche XML-Datensatz mit höhere Versionsnummer versendet? Dies würde aber bedeuten, dass die Netzbetreiber dies auch so umsetzen müssten.
Frage/Fall 2: Vorübergehende Nichtverfügbarkeit: z.B. aufgrund Wartung ist die TR auf eine Leistung von insgesamt 200 kW begrenzt:
a) Soll dies als Einzelmeldung ohne Versionierung der xml-Datei erfolgen?
b) Ist die Meldung dann mit170 kW (200-30[dauerhafte NV] kW) anzugeben? Bzw. berechnet der Netzbetreiber in verbindung mit einem Dokument zu Frage 1 eine "Netto-Nichtvefügbarkeit"?
Frage 3: Welchen maximalen Zeitraum darf ein Dokument für Nichtverfügbarkeiten abdecken? 1 Tag, 1 Woche, 1 Jahr, beliebig?
|
2022-01-27 09:54:10 |
Sehr geehrter Fragesteller,
zu Ihrer Frage 1: Die Kraftwerksnichtverfügbarkeit ist regulär über das Unavailability_MarketDocument zu melden. Der Grund Eigenverbrauch kann im Element Reason - Code mittels der Z11 angegeben werden. Bei Änderungen wird eine neue Datei versandt und die Aktualisierung durch eine höhere Dateiversion kenntlich gemacht.
Zu Frage 2: Dieser Punkt befindet sich in Klärung.
Zu Frage 3: In Prozessen ist kein maximaler Zeitraum festgeschrieben und im Datenformat gibt es daher keine Einschränkung des Zeitraums.
Freundliche Grüße,
Ihr Forum Datenformate |
Ja
|
Erik Wassermann |
Stefan Seidel |
Jennifer Collin |
Markus Breitschaft |
|
Nein
|
in PG besprochen .
Frage 2 wird weiter geklärt.
-------------Katia Schubert-------------24.03.2022 16:36
|
Nein
|
Nein
|
|
Stammdaten FB 1.0
|
Abgeschlossen
|
Wieso sind keine Patternregeln für das Element "EEG_Anlagenschluessel" enthalten?
|
Diese Konkretisierung kommt mit Version 1.1 der Formatbeschreibung (gültig ab 01.04.2022). |
21.01.2022
|
2022-01255 |
|
|
Das Feld "EEG_Anlagenschluessel" unterliegt im XML keiner weiteren Validierung. Nach https://www.bdew.de/media/documents/2020-09-24_Erg%C3%A4nzung-zu-Umsetzungshilfe-EEG-2017_Generierung-EEG-Anlagenschl%C3%BCssel.pdf ist die Bildung eines EEG-Anlagenschlüssels allerdings streng vorgegeben. Warum spiegelt sich dies nicht als Validierungsregel wieder?
|
2022-01-21 15:54:17 |
Sehr geehrter Fragesteller,
in der ersten Version ist, wie Sie richtig angemerkt haben, die Bildungsvorschrift für das Element "EEG_Anlagenschluessel" nicht enthalten. Wir haben dies mit der Weiterentwicklung des Formats für die Version 1.1 der Formatbeschreibung, die ab dem 01.04.2022 gültig wird, jedoch bereits vorgesehen. Hierin sind auch die Bildungsvorschrift für andere Elemente (bspw. Messlokation) ebenfalls als vorgegebene Pattern hinterlegt.
Mit freundlichem Gruß
Ihr BDEW-Forum Datenformate |
Ja
|
Johannes Umbach |
Henning Hots |
Johannes Umbach |
Malte Otten |
|
Nein
|
-------------Johannes Umbach-------------22.01.2022 05:41
Zur Freigabe in PG
-------------Katia Schubert-------------25.01.2022 08:28
in PG besprochen |
Nein
|
Nein
|
|
Allgemeine Festlegungen 6.0
|
In Bearbeitung
|
Ist ein Lieferende "Datum" 30.11.2021 00:00Uhr als Tagesende zu interpretieren?
|
Mit dem Qualifier 303 wird ein Zeitpunkt beschrieben - eine Interpretation auf Tagesanfang / - ende ist nicht möglich |
16.12.2021
|
2021-01220 |
|
|
Hallo Forum-Team,
ich habe eine Frage zum Kapitel "3.1 Angabe von Zeiten in der EDIFACT Nachricht" und den dort genannten Beispielen zur Erstellung und Versand einer befristeten Anmeldung Netznutzung für Strom.
Bisher war es doch so, dass das in der befristeten Anmeldung übertragene Ende-Datum (30.11.2021) Tagesende bedeutet hat. d.h. die Belieferung geht bis 30.11.2021 "24:00Uhr". Eine neue Belieferung kann dann ab 01.12.2021 00:00Uhr starten.
In den Beispiel wird das Ende-Datum 30.11.2021 00:00Uhr (MESZ) übertragen. Wie muss dieses Datum als Empfänger interpretiert werden? Ist das auch noch als Tagesende zu interpretieren oder geht die Belieferung in diesem Fall nur bis 29.11.2021 24:00Uhr?
In der GPKE steht unter Kapitel 7 Fristenberechnung, dass das Ende des Energieliefervertrags nur dann als Tagesende zu deuten ist, wenn das Abmeldedatum nur ein Tagesdatum (also ohne Uhrzeit so würde ich das interpretieren) ist.
Da ja ab 01.04.2022 mit Uhrzeit das Ende-Datum übertragen wird würde doch bedeuten dass 30.11.2021 00:00Uhr dann als Tagesanfang zu interpretieren ist (also Endet dann zum 29.11.2021 24:00Uhr).
Der Auszug aus der GPKE:
"Ein Energieliefervertrag endet mit Ablauf des letzten Tages des Vertragszeitraums,
folglich mit dem Ablauf des Tages, der durch das Abmeldedatum bezeichnet wird, falls das Vertragsende
nur als Tagesdatum genannt ist. Da am Tag des Abmeldedatums noch eine vollumfängliche Belieferung
durch den LFA erfolgt, ist dieser Tag für die Einhaltung des Mindestzeitraums mit einzubeziehen."
|
2021-12-16 15:27:07 |
Sehr geehrter Makrtteilnehmer,
mit dem Code 303 im DTM Segement wird ein exakter Zeitpunkt angegeben.
Eine Zeitpunktangabe, wie von Ihnen in Ihrer Frage beschreiben <30.11.2021 "24:00Uhr"> gibt es so nicht. Wir haben verstanden, dass Sie damit lediglich den Ablauf des 30.11. darstellen wollten.
Der Zeitpunkt des Ende eines Tages ist identisch mit dem Beginnzeitpunkt des Folgetages.Bedeutet für das Beispiel der Zeitpunktangabe 30.11.2021 00:00 Uhr:- dies ist das Tagesende des 29.11.2021 - dies ist auch der Tagesbeginn des 30.11.2021da dies beides die gleichen Zeitpunkte sind.
Ihre Anmerkung zum Kapitel 7 Fristenberechnung[..]Dies bedeutet beispielsweise für den Use-Case „Lieferende von LF an NB“ im Fall eines Lieferantenwechsels, dass die Meldung beim NB sechs volle WT vor der Beendigung des Energieliefervertrages eingegangen sein muss. Ein Energieliefervertrag endet mit Ablauf des letzten Tages des Vertragszeitraums, folglich mit dem Ablauf des Tages, der durch das Abmeldedatum bezeichnet wird, falls das Vertragsende nur als Tagesdatum genannt ist. Da am Tag des Abmeldedatums noch eine vollumfängliche Belieferung durch den LFA erfolgt, ist dieser Tag für die Einhaltung des Mindestzeitraums mit einzubeziehen.[..]Ein Vertragsende kann man auch mit Ablauf eines Monats oder Jahres angeben. Eine Ableitung daraus, dass bei der technischen Übermittlung der Daten dann ein Format mit Uhrzeit verwendet wird, und dies aus dem Grund vom tatsächlich kommunizierten Zeitpunkt abweichend interpetiert werden muss, können wir nicht nachvollziehen.
Hier soll lediglich ausgesagt werden, dass der letzte Tag der Belieferung noch in die Frist einberechnet werden muss, da die Belieferung an diesem Tag noch komplett erfolgt. Wenn man diese Angaben als Zeitpunkt beschrieben hätte, würde man dies nicht separat erläutern müssen wir ein Datum zu interpretieren ist.
Wir hoffen Ihnen hiermit etwas weitergeholfen zu haben.
Ihre PG EDI@Energy
|
Ja
|
Holger Weickenmeier |
Thomas Fellhauer |
Thomas Fellhauer |
Patrick Pleitgen |
Kapitel 3.1 Angabe von Zeiten in der EDIFACT Nachricht |
Nein
|
-------------Holger Weickenmeier-------------22.12.2021 15:48
|
Nein
|
Nein
|
|
Allgemeine Festlegungen 5.0
|
In Bearbeitung
|
Zeitpunktangaben bei Endzeitpunkten - sind meine Interpretationen korrekt?
|
Korrekte Interpretation der Endezeiptpunktangaben |
02.12.2021
|
2021-01198 |
|
|
Hallo liebes Forum-Team,
ich habe eine Frage bezgl. der Anwendung der Spartenspezifischen, prozessuale Zeitangaben ab 01.04.2022 -genauer gesagt die Frage, ob ich das richtig verstanden habe vor allem bei "Zeitraum-Ende"-DTMs.
Beispiel: ein lückenloser Lieferantenwechsel STROM zum 01.06.2022 -> LFN ab 01.06.2022 (zum Tagesbeginn 00:00Uhr) und LFA bis zum 31.05.2022 (Tagesende 24:00 -> technisch 01.06.2022 00:00) zugeordnet.
Bisher (also bis einschließlich 31.03.2022) war es doch so, dass
- der LFN den Lieferbeginn an den NB 11001 mit DTM+92 (Beginn zum) DTM+92:20220601:102' (01.06.2022)
- der LFN die Kündigung an den LFA 11016 mit DTM+93 (Ende zum, bei fixen Termin) DTM+93:20220531:102' (31.05.2022)
- bei Abmeldeanfrage der NB an den LFA 11010 mit DTM+93 (Ende zum) DTM+93:20220531:102' (31.05.2022)
- der LFA das Lieferende an den NB 11004 mit DTM+93 (Ende zum) DTM+93:20220531:102' (31.05.2022)
gesendet hat. Ist doch korrekt oder?
ab 01.04.2022 und der Änderung der DTMs auf 303 (also mit Uhrzeit) muss das Beispiel nun wie folgt übertragen werden
(Auflistung erstmal in deutscher Zeit - also noch nicht in UTC umgerechnet):
- der LFN den Lieferbeginn an den NB 11001 mit DTM+92 (Beginn zum) DTM+92:202206010000?+02:303' (01.06.2022 00:00 MESZ)
- der LFN die Kündigung an den LFA 11016 mit DTM+93 (Ende zum, bei fixen Termin) DTM+93:202206010000?+02:303' (01.06.2022 00:00 MESZ)
- bei Abmeldeanfrage der NB an den LFA 11010 mit DTM+93 (Ende zum) DTM+93:202206010000?+02:303' (01.06.2022 00:00 MESZ)
- der LFA das Lieferende an den NB 11004 mit DTM+93 (Ende zum) DTM+93:202206010000?+02:303' (01.06.2022 00:00 MESZ)
Umgerechnet in UTC:
- der LFN den Lieferbeginn an den NB 11001 mit DTM+92 (Beginn zum) DTM+92:202205312200?+00:303' (31.05.2022 22:00 UTC)
- der LFN die Kündigung an den LFA 11016 mit DTM+93 (Ende zum, bei fixen Termin) DTM+93:202205312200?+00:303' (31.05.2022 22:00 UTC)
- bei Abmeldeanfrage der NB an den LFA 11010 mit DTM+93 (Ende zum) DTM+93:202205312200?+00:303' (31.05.2022 22:00 UTC)
- der LFA das Lieferende an den NB 11004 mit DTM+93 (Ende zum) DTM+93:202205312200?+00:303' (31.05.2022 22:00 UTC)
Habe ich das richtig verstanden?
Über eine Antwort würde ich mich sehr freuen - Vielen Dank schon mal
Patrick Pleitgen
|
2021-12-02 18:39:33 |
Sehr geehrter Herr Pleitgen,
vielen Dank für Ihren Beitrag.
Sie haben alles korrekt verstanden. :-)
Wir möchten lediglich noch anmerken, dass die Zeitpunkte immer in UTC in den Nachrichten anzugeben sind. Ihren Abschnitt "(Auflistung erstmal in deutscher Zeit - also noch nicht in UTC umgerechnet):" haben wie so interpretiert, dass dies nur für die Herleitung und das Verständnis so beschieben wurde.Schlussendlich wurde dies von Ihnen ja im letzten Abschnitt Ihrer Frage "Umgerechnet in UTC:" final korrekt dargestellt.
Viele Grüße
Ihre PG EDI@Energy |
Ja
|
Holger Weickenmeier |
Thomas Fellhauer |
Holger Weickenmeier |
Patrick Pleitgen |
Kapitel 3 Zeitangaben und Zeitzonen |
Nein
|
Antwortvorschlag erstellt
-------------Holger Weickenmeier-------------23.12.2021 10:51
|
Nein
|
Nein
|
|
Allgemeine Festlegungen 5.0
|
Abgeschlossen
|
Namenskonvention für XML-Nachrichten und Prüfung auf Dateinamen
|
Durch den Empfänger ist auf den Dateinamen nicht zu prüfen |
21.10.2021
|
2021-01132 |
|
|
In Abschnitt 6.12 Namenskonvention für XML-Nachrichten steht:
"Die konkrete Zuordnung von Elementen der XML-Nachrichten zu den einzelnen Namenskomponenten
ist der jeweiligen Formatbeschreibung zu entnehmen."
Unklar ist mir, woher die Information für das Datum (yyyyMMdd) als Namenskomponente kommen soll. Das Erstellungsdatum ist damit offenbar nicht gemeint, da entsprechende Dokumente zurückgewiesen werden.
In den Formatbeschreibungen (z.b. PlannedResourceScheduleDocument FB / AWT) habe ich dazu aber auch nichts gefunden.
Können Sie mir bitte sagen, wo in den Formatbeschreibungen (oder an anderer Stelle) festgelegt ist, welches Datum als Namenskomponente für das jeweilige Dokument verwendet werden soll?
Vielen Dank
|
2021-10-21 13:43:35 |
Sehr geehrter Marktteilnehmer,
vielen Dank für den Hinweis.
Wir werden hier eine Präzisierung im Rahmen der nächsten Veröffentlichung prüfen.
Grundsätzlich gilt jedoch, dass durch den Empfänger auf den Dateinamen nicht zu prüfen ist.
Freundliche Grüße
Ihr BDEW-Forum Datenformate |
Ja
|
Holger Weickenmeier |
Sven Schillack |
Thomas Fellhauer |
Arnd Krönig |
Abschnitt 6.12 Namenskonvention für XML-Nachrichten steht
Die konkrete Zuordnung von Elementen der XML-Nachrichten zu den einzelnen Namenskomponenten
ist der jeweiligen Formatbeschreibung zu entnehmen. |
Nein
|
beantwortet Analog 2021-01097
-------------Thomas Fellhauer-------------29.10.2021 08:05
|
Nein
|
Nein
|
|
Allgemeine Festlegungen 5.0
|
Abgeschlossen
|
Namenskonvention für XML-Nachrichten und Prüfung auf Dateinamen
|
Durch den Empfänger ist auf den Dateinamen nicht zu prüfen |
16.09.2021
|
2021-01097 |
|
|
Ist der Zeistempel in der Namenskonvention für XML-Nachrichten (Kapitel 6.12) identisch zu interpretieren, wie bei den EDIFACT-Dateinamen?
EDIFACT:
yyyy: Jahr | Datumsstempel
mm: Monat | bei Erzeugung
dd: Tag | der Datei
Für XML wurde nicht konkret spezifiziert, ob es sich ebenfalls um den Erzeugungszeitstempel handelt oder um das fachliche "Gültig_ab"-Datum der Stammdaten-Gültigkeit.
Angesichts der wünschenswerten Einheitlichkeit gehen wir vom Erzeugungszeitstempel aus. Das RAIDA-System akzeptiert aber anscheinend derzeit nur Dateien, die im yyyyMMdd das Gültig_ab-Datum enthalten. Angesichts des technischen Routings der Dateien empfinden wir den Ansatz mit Gültig_ab als unlogisch. RAIDA muss den Dateiinhalt sowieso parsen, um die ID`s der technischen Ressourcen o. Cluster sowie der Empfänger zu ermitteln, daher kann an dieser Stelle auch das Gültig_ab ausgelesen werden.
Wir bitten um Konkretisierung des zu verwendenden Zeitstempels im XML-Dateinamen.
|
2021-09-16 12:26:56 |
Sehr geehrter Marktteilnehmer,
vielen Dank für den Hinweis.
Wir werden hier eine Präzisierung im Rahmen der nächsten Veröffentlichung prüfen.
Grundsätzlich gilt jedoch, dass durch den Empfänger auf den Dateinamen nicht zu prüfen ist.
Freundliche Grüße
Ihr BDEW-Forum Datenformate |
Ja
|
Holger Weickenmeier |
Sven Schillack |
Thomas Fellhauer |
Tamara Schlömer |
6.12 Namenskonvention für XML-Nachrichten
Der grundsätzliche Aufbau von Dateinamen ist wie folgt:
yyyyMMdd_DocumentType_AbsenderMPID_EmpfängerMPID_ DocumentIdentifica-
tion_DocumentVersion.xml. |
Nein
|
PG XML: Danke für den Hinweis. Wir prüfen es im Laufe einer der nächsten Sitzungen. Grundsätzlich gilt aber: der Dateiname ist nicht zu prüfen.
-------------Katia Schubert-------------22.09.2021 08:44
gemäß PG Rückmeldung beantwortet
-------------Thomas Fellhauer-------------29.10.2021 08:00
|
Nein
|
Nein
|
|
Unavailability_MarketDocument FB 1.0
|
Eingegangen
|
Ist eine zeitliche Überlappung von mehreren Nichtverfügbarkeitmeldungen für eine Ressource zulässig?
|
Für jeden Zeitpunkt darf maximale eine Nichtverfügbarkeitsmeldung vorliegen. |
01.12.2021
|
2021-01194 |
|
|
Ist es zulässig, dass sich bei zwei Dokumenten mit unterschiedlicher Dokumenten ID, aber demselben Dokumenten-Typ und derselben Ressource die Zeitbereiche überlappen und beide Dokumente gleichzeitig gültig sind (also nicht zurückgezogen wurden)
Also z.B.
Nichtbeanspruchbarkeit mit ID 1:
- Ressource A
- Zeitbereich: 2.12.21 10:00 - 3.12.21 10:00
- Wert: 1
Nichtbeanspruchbarkeit mit ID 2:
- Ressource A
- Zeitbereich: 2.12.21 11:00 - 4.12.21 10:00
- Wert: 2
Falls das zulässig ist, wie soll dann der Wert im überlappenden Zeitintervall behandelt werden? Als Summenwert? Wie sieht das dann bei Markbedingten Anpassungen aus?
|
2021-12-01 21:08:14 |
Sehr geehrter Fragesteller,
die zeitliche Überlappung von Nichtverfügbarkeitmeldungen für eine Ressource ist nicht zulässig. Für jeden Zeitpunkt, für den eine Nichtverfügbarkeit gemeldet wird, darf maximal eine Meldung erfolgen.
Freundliche Grüße,
Ihr Forum Datenformate |
Ja
|
Erik Wassermann |
Stefan Seidel |
Johannes Umbach |
Arnd Krönig |
|
Nein
|
-------------Johannes Umbach-------------07.12.2021 20:00
Frage beantwortet und zur Veröffentlichung vorbereitet
-------------Katia Schubert-------------20.12.2021 14:28
In PG XML besprochen und veröffentlicht.
|
Nein
|
Nein
|
|
Unavailability_MarketDocument FB 1.0
|
Eingegangen
|
Wie kann eine Nichtverfügbarkeit angepasst werden?
|
Eine Nichtverfügbarkeit kann über den Versand einer neuen Version bei gegebenen Anpassungsbedarf aktualisiert werden. |
23.11.2021
|
2021-01182 |
|
|
Kann eine Nichtverfügbarkeit, die bereits begonnen hat, aber noch nicht abgeschlossen ist, verändert werden, insbesondere der Zeitraum verkürzt und der Ausfallgrund teilweise abgeändert werden? Funktioniert das über eine neue Version oder Storno und anschließend neue Meldung(en)?
Beispiel: Im Zeitraum 1 bis 10 ist Z11 Selbstversorgung gemeldet. Zum Zeitpunkt 2 ist nun bekannt, dass im Zeitraum 3 bis 4 eine Wartung B19 durchgeführt wird. Welche Meldungen sind zum Zeitpunkt 2 zu erstellen?
|
2021-11-23 10:46:38 |
Sehr geehrter Fragesteller,
in Ihrem konkret aufgezeigten Beispiel kann zum Zeitpunkt 2, wenn die Wartung bekannt ist, der Grund der Nichtverfügbarkeit durch den Versand der Meldung mit einer entsprechend höheren Version aktualisiert werden. Die von Ihnen angesprochene Möglichkeit der Stornierung ist für Fälle vorgesehen, bei denen die gemeldete Nichtverfügbarkeit komplett zurück genommen werden soll.
Freundliche Grüße,
Ihr Forum Datenformate |
Ja
|
Erik Wassermann |
Stefan Seidel |
Johannes Umbach |
Andreas Gmeinwieser |
|
Nein
|
-------------Johannes Umbach-------------07.12.2021 19:49
Antworten eingefügt und vorbereitet für die Veröffentlichung
-------------Katia Schubert-------------20.12.2021 14:31
in PG XML besprochen
|
Nein
|
Nein
|
|
Einführungsszenario BK6-20-160 1.0
|
Abgeschlossen
|
Wird es in einer weiteren Version des Einführungsszenarios Regelungen zur Auflösung von 100%-Tranchen geben?
|
In einer weiteren Version des Einführungsszenarios wird die Thematik "Auflösung von 100%-Tranchen" aufgegriffen. |
03.11.2021
|
2021-01142 |
|
|
Sehr geehrtes Forum,
im Kapitel 5 MPES heißt es, das die 100%-Tranchen von den Verantwortlichen und Berechtigten in deren Systemen aufzulösen sind. Verstehen wir dies richtig, das jeder Markteilnehmer selbständig in seinen Systemen die neue Marktlokations-Struktur hinterlegen muss?
Weiterhin steht dort das die bestehenden Konstrukte zu 100%-Tranchen in Marktlokationen zu überführen sind. Heißt das, die bisherige ID der Tranche bleibt bestehen und wird zur Marktlokation? Oder müssen die Informationen der bisherigen Tranche an die bereits existierende Marktlokation übernommen werden?
Vielen Dank
|
2021-11-03 08:39:47 |
Sehr geehrter Martteilnehmer,
in einer weiteren Version des Einführungsszenarios wird die Thematik "Auflösung von 100%-Tranchen" aufgegriffen.
Mit freundlichem Gruß
Ihr BDEW-Forum Datenformate |
Ja
|
|
Christina Frein |
|
Anja Meier |
Kapitel 5 MPES |
Nein
|
-------------Christina Frein-------------04.11.2021 14:09
|
Nein
|
Nein
|
|
Stammdaten XSD - informatorische Lesefassung 1.0
|
Abgeschlossen
|
Ist die Häufigkeit des Elements EEG_Anlagenschluessel korrekt?
|
Ja, die Häufigkeit liegt bei 0..unbounded. |
21.09.2021
|
2021-01102 |
|
|
Im complexType "ObjektTyp_TR_T" (Technische Resource) findet sich das Element "EEG_Anlagenschluessel", dessen Vorkommen mit maxOccurs="unbounded" angegeben ist.
Laut Kapitel "1.1.2 EEG-Anlage" in
"Anwendungshilfe für Anlagenbetreiber und Direktvermarkter für die Umsetzung der neuen RD2.0-Prozesse, Version 1.1" (https://www.bdew.de/media/documents/2021-07-02_Umsetzungshilfe_AB_final.pdf):
"Die TR aus dem RD-Prozess ist der Definition nach identisch mit der SEE (Stromerzeugungseinheit) des
MaStR. Einer EEG-Anlage können 1-n TR/SEE zugeordnet werden. Einer TR/SEE kann in der Regel nur
genau eine (oder keine) EEG-Anlage zugeordnet sein. Bei Erweiterung einer Anlage erfolgt eine n:1-
Zuordnung zwischen SEE (entspricht der TR) und der EEG-Anlage. Eine Zuordnung von mehreren EEG-Anlagen zu einer TR (SEE) ist nicht möglich2"
.
Sollte hier nicht maxOccurs="1" stehen?
|
2021-09-21 05:56:13 |
Sehr geehrter Marktteilnehmer,
in der Anwendungshilfe für Anlagenbetreiber wird auf die EEG-Anlage und nicht auf den EEG-Anlagenschlüssel abgestellt.
Einer EEG-Anlage können mehrere EEG-Anlagenschlüssel zugewiesen werden, bspw. bei Erweiterungen. Daher ist die Häufigkeit 0..unbounded des Elements EEG_Anlagenschluessel korrekt.
Mit freundlichem Gruß
Ihr BDEW-Forum Datenformate |
Ja
|
Sara Olszewski |
Henning Hots |
Sara Olszewski |
Felix Deutsch |
<xs:element name="EEG_Anlagenschluessel" type="xs:string" minOccurs="0" maxOccurs="unbounded"/> |
Nein
|
PG XML sieht es bei unbounded, weil bspw. bei PV-Dachanlagen eine Erweiterung zu einem weiteren EEG-Anlagenschlüssel einer TR führen kann.
Patrick Fekete bzgl. Awh ansprechen.
-------------Katia Schubert-------------22.09.2021 08:39
In der PG beantwortet. Die Awh spricht von der EEG-Anlage, nicht vom EEG-Anlagenschlüssel. Daher besteht kein Widerspruch und kein Korrekturbedarf.
-------------Katia Schubert-------------27.09.2021 14:47
|
Nein
|
Nein
|
|
Stammdaten XSD - informatorische Lesefassung 1.0
|
Abgeschlossen
|
|
|
19.05.2021
|
2021-01019 |
|
|
Der Datenpunkt "Verguetungsart" ist in der XSD-Datei als Freitext angelegt. Dagegen ist in der Formatbeschreibung eine Begrenzung auf die möglichen Werte "Z01", "Z02" und "Z03" vorgesehen.
Gehe ich richtig in der Annahme, dass die XSD-Datei einen Datentyp "VerguetungsartT" mit den entsprechenden Auswahlmöglichkeiten definieren müsste?
|
2021-05-19 11:28:02 |
Vielen Dank für den Hinweis. Wir müssen Ihnen zustimmen. Hier ist uns leider ein Fehler unterlaufen, den wir über eine konsolidierte Lesefassung mit Fehlerkorrekturen korrigieren werden.
Freundliche Grüße,
Ihr Forum Datenformate |
Ja
|
Sara Olszewski |
Henning Hots |
Sara Olszewski |
Tobias Paret |
Stammdaten XSD:
<xs:element name="Verguetungsart" type="xs:string" minOccurs="0"/>
Stammdaten FB:
Anwendbare Codes
Z01 EEG
Z02 KWKG
Z03 Sonstiges |
Nein
|
Antwort verfasst
-------------Henning Hots-------------26.05.2021 11:08
|
Nein
|
Nein
|
|
Stammdaten XSD - informatorische Lesefassung 1.0
|
In Bearbeitung
|
|
|
11.05.2021
|
2021-01015 |
|
|
Bei der Stammdatenmeldung des EIV "Übermittlung von initialen Stammdaten mit DP" und "Übermittlung Stammdatenänderung vom EIV (verantwortlich) ausgehend mit DP" sollen keine betroffenen NB angegeben werden.
In der xsd, FB und AWT iist definiert, dass dort 1-6 NB angegeben werden müssen.
Müssen dort nocht 0-6 NB als Anzahl angegeben werden?
|
2021-05-11 09:06:20 |
Vielen Dank für den Hinweis. Wir müssen Ihnen zustimmen. Hier ist uns leider ein Fehler unterlaufen, den wir über eine konsolidierte Lesefassung mit Fehlerkorrekturen korrigieren werden.
Freundliche Grüße,
Ihr Forum Datenformate |
Ja
|
Sara Olszewski |
Henning Hots |
Sara Olszewski |
Nina Meyer |
XSD-Zeile bisher:
<xs:element name="Betroffene_Netzbetreiber" type="MarktpartnerT_BetroffeneNB" minOccurs="1" maxOccurs="6">
XSD-Zeile Lösungsvorschlag
<xs:element name="Betroffene_Netzbetreiber" type="MarktpartnerT_BetroffeneNB" minOccurs="0" maxOccurs="6"> |
Nein
|
Antwort verfasst.
-------------Henning Hots-------------17.05.2021 15:52
|
Nein
|
Nein
|
|
Stammdaten XSD - informatorische Lesefassung 1.0
|
Abgeschlossen
|
Ist der Typ GeokoordinatenT falsch beschrieben?
|
Ja, es handelt sich um einen Fehler und wird über eine konsolidierte Lesefassung mit Fehlerkorrekturen korrigiert werden. |
21.04.2021
|
2021-00999 |
|
|
Liebes EDI-Team,
In der XSD scheint der Typ GeokoordinatenT falsch beschrieben.
Anbei die richtige Version und die alte Version im Feld Textbezug.
Damit es eine Frage wird: Folgen Sie meinen Argumenten?
Schöne Grüße aus dem Ruhrgebiet
Nina Meyer
Hinweis der Redaktion: Es wurden Leerzeichen im XML eingefügt, damit der Beispielauszug im Forum lesbar ist.
< !--Nina Meyer: falsche Version>
< xs:complexType name="GeokoordinatenT">
< xs:simpleContent>
< xs:extension base="Geokoordination">
< xs:attribute name="LaengeOst" use="required" form="unqualified">
< xs:annotation>
< xs:documentation source="Example">12.123456< /xs:documentation>
< /xs:annotation>
< xs:simpleType>
< xs:restriction base="xs:NMTOKEN"/>
< /xs:simpleType>
< /xs:attribute>
< xs:attribute name="BreiteNord" use="required" form="unqualified">
< xs:annotation>
< xs:documentation source="Example">52.123456< /xs:documentation>
< /xs:annotation>
< xs:simpleType>
< xs:restriction base="xs:NMTOKEN"/>
< /xs:simpleType>
< /xs:attribute>
< /xs:extension>
< /xs:simpleContent>
< /xs:complexType-->
< !--Nina Meyer: Gute Version-->
< xs:complexType name="GeokoordinatenT">
< xs:attribute name="LaengeOst" use="required">
< xs:annotation>
< xs:documentation source="Example">12.123456< /xs:documentation>
< /xs:annotation>
< xs:simpleType>
< xs:restriction base="Geokoordination"/>
< /xs:simpleType>
< /xs:attribute>
< xs:attribute name="BreiteNord" use="required">
< xs:annotation>
< xs:documentation source="Example">52.123456< /xs:documentation>
< /xs:annotation>
< xs:simpleType>
< xs:restriction base="Geokoordination"/>
< /xs:simpleType>
< /xs:attribute>
< /xs:complexType>
|
2021-04-21 14:57:04 |
Sehr geehrte Frau Meyer,
vielen Dank für den Hinweis. Wir müssen Ihnen zustimmen. Hier ist uns leider ein Fehler unterlaufen, den wir über eine konsolidierte Lesefassung mit Fehlerkorrekturen korrigieren werden.
Freundliche Grüße,
Ihr Forum Datenformate |
Ja
|
Sara Olszewski |
Henning Hots |
Sara Olszewski |
Nina Meyer |
< !--Nina Meyer: falsche Version>
< xs:complexType name="GeokoordinatenT">
< xs:simpleContent>
< xs:extension base="Geokoordination">
< xs:attribute name="LaengeOst" use="required" form="unqualified">
< xs:annotation>
< xs:documentation source="Example">12.123456< /xs:documentation>
< /xs:annotation>
< xs:simpleType>
< xs:restriction base="xs:NMTOKEN"/>
< /xs:simpleType>
< /xs:attribute>
< xs:attribute name="BreiteNord" use="required" form="unqualified">
< xs:annotation>
< xs:documentation source="Example">52.123456</xs:documentation>
< /xs:annotation>
< xs:simpleType>
< xs:restriction base="xs:NMTOKEN"/>
< /xs:simpleType>
< /xs:attribute>
< /xs:extension>
< /xs:simpleContent>
< /xs:complexType-->
< !--Nina Meyer: Gute Version-->
< xs:complexType name="GeokoordinatenT">
< xs:attribute name="LaengeOst" use="required">
< xs:annotation>
< xs:documentation source="Example">12.123456</xs:documentation>
< /xs:annotation>
< xs:simpleType>
< xs:restriction base="Geokoordination"/>
< /xs:simpleType>
< /xs:attribute>
< xs:attribute name="BreiteNord" use="required">
< xs:annotation>
< xs:documentation source="Example">52.123456</xs:documentation>
< /xs:annotation>
< xs:simpleType>
< xs:restriction base="Geokoordination"/>
< /xs:simpleType>
< /xs:attribute>
< /xs:complexType> |
Nein
|
In der PG besprochen
-------------Katia Schubert-------------22.04.2021 09:46
Leerzeichen im XML zur Lesbarkeit eingefügt
-------------Henning Hots-------------03.05.2021 08:42
|
Nein
|
Nein
|
|
Stammdaten XSD - informatorische Lesefassung 1.0
|
Eingegangen
|
Ist die Felddefinition für die Typen "MarktlokationT" und "TrancheT" falsch?
|
Ja, sie wird über eine konsolidierte Lesefassung mit Fehlerkorrekturen korrigiert werden. |
08.04.2021
|
2021-00978 |
|
|
Sehr geehrte Damen und Herren,
uns ist ein möglicher Fehler im Stammdaten-xsd aufgefallen. In unserem Verständnis verstößt die Felddefinition für die Typen "MarktlokationT" und "TrancheT" gegen den W3C-Standard. Konkret meinen wir:
< xs:attribute name="Code" use="required" >
< xs:simpleType >
< xs:restriction base="xs:integer" >
< xs:maxLength value="11"/ >
< /xs:restriction >
< /xs:simpleType >
< /xs:attribute >
Ein maxLength-Facet ist in unseren Augen aber nur für den Typ String zulässig. Eventuell sollte hier mit einem String gearbeitet werden und dann die Einschränkung auf Ziffern über ein pattern-Facet erfolgen.
Teilen Sie unsere Sichtweise oder übersehen wir hier etwas?
Vielen Dank für Ihre Mühe.
Mit freundlichen Grüßen
Sebastian Weiße
|
2021-04-08 15:54:11 |
Sehr geehrter Herr Weiße,
vielen Dank für den Hinweis. Wir müssen Ihnen zustimmen. Hier ist uns leider ein Fehler unterlaufen, den wir über eine konsolidierte Lesefassung mit Fehlerkorrekturen korrigieren werden.
Freundliche Grüße,Ihr Forum Datenformate |
Ja
|
Sara Olszewski |
Henning Hots |
Sara Olszewski |
Sebastian Weiße |
|
Nein
|
-------------Stefan Seidel-------------14.04.2021 09:41
Erster Aufschlag erstellt.
Komisch ist, dass der XML-Ausschnitt nicht angezeigt wird, nachdem man auf "Speichern" drückt.
-------------Thomas Fellhauer-------------22.04.2021 09:31
Veröffentlicht nach Rücksprache mit PG XML |
Nein
|
Nein
|
|
Anwendungsübersicht der Prüfidentifikatoren - informatorische Lesefassung 1.0c
|
Abgeschlossen
|
Mit welchem Anwendungsfall der ORDERS werden fehlende Zählerstände in der Sparte Strom angefragt?
|
In der Sparte Strom sind fehlende Zählerstände über den Anwendungsfall, dem der PID 17113 zugeordnet ist, zu reklamieren |
30.07.2021
|
2021-01074 |
|
|
Hallo,
sind fehlende Zählerstände für Ein- und Auszug (COS/SMV und COS/SMV) seitens Marktpartner "Lieferant" per ORDERS zu
- reklamieren (PI 17113 "Reklamation von Messwerten") oder
- anzufordern (PI 17004 "Anforderung von Messwerten")
Danke.
|
2021-07-30 10:25:07 |
Sehr geehrter Forumsteilnehmer,
in der Sparte Strom sind fehlende Zählerstände zum Ein- und Auszug seitens eines Marktpartners in der Rolle Lieferant per ORDERS, der der Prüfidentifikator 17113 zugeordnet ist, beim Messstellenbetreiber zu reklamieren.
Freundliche Grüße,
Ihr Forum Datenformate |
Ja
|
Holger Kampmann |
Thomas Fellhauer |
Holger Kampmann |
Marcus Ogon |
|
Nein
|
|
Nein
|
Nein
|
|
Anwendungsübersicht der Prüfidentifikatoren - informatorische Lesefassung 1.0c
|
Abgeschlossen
|
Mit welchem Anwendungsfall der ORDERS werden fehlende Messwerte in der Sparte Strom angefragt?
|
In der Sparte Strom sind fehlende Werte über den Anwendungsfall, dem der PID 17113 zugeordnet ist, zu reklamieren |
10.05.2021
|
2021-01013 |
|
|
Hallo,
im REQOTE/QUOTES/ORDERS/ORDRSP AHB ist bei ORDERS PI 17113 "Reklamation von Messwerten" im Segment "Beschreibung der Reklamation von Werten" angegeben, dass auch fehlende Werte reklamiert werden können.
Können mit dieser ORDERS auch fehlende Messwerte COS (Ein- und Auszug) angefragt werden?
Vielen Dank.
|
2021-05-10 13:14:06 |
Sehr geehrter Forumsteilnehmer,
ja, in der GPKE ist festgelegt, dass fehlende Werte über die "Reklamation von Werten" zu reklamieren sind und dafür nicht die Geschäftsdatenanfrage zu nutzen ist: "liegt die Situation beim NB, LF oder ÜNB vor, dass er unplausible oder fehlende Werte hat, sind diese über den Use-Case „Reklamation von Werten“ beim MSB zu reklamieren. Hierzu darf nicht die Geschäftsdatenanfrage verwendet werden, da diese nicht sicherstellt, dass im Markt ein einheitlicher Wertestand vorliegt."
Demzufolge sind in der Sparte Strom fehlende Werte über den Anwendungsfall, dem der PID 17113 zugeordnet ist, zu reklamieren. Für die Sparte Gas wird die Geschäftsdatenanfrage zur Nachforderung fehlender Werte genutzt.
Freundliche Grüße,
Ihr Forum Datenformate |
Ja
|
Holger Kampmann |
Thomas Fellhauer |
Holger Kampmann |
Marcus Ogon |
REQOTE/QUOTES/ORDERS/ORDRSP AHB 1.0c |
Nein
|
|
Nein
|
Nein
|
|
Anwendungsübersicht der Prüfidentifikatoren - informatorische Lesefassung 1.0c
|
Abgeschlossen
|
In welchen Fällen ist eine Bestellung von Werten per ORDERS, der der PID 17004 zugeordnet ist, auszulösen?
|
Die Auslöser einer Bestellung von Werten wurde mit Umsetzungsfrage WiM_027 präzisiert |
21.04.2021
|
2021-00997 |
|
|
Sehr geehrte Damen und Herren,
wir haben eine Frage / Anmerkung / Korrektur zur veröffentlichten Umsetzungsfrage mit der Nummer 2021-00966. Wir sind hier der Auffassung, dass die PID 17004 an dieser Stelle verkehrt ist und stattdessen die PID 17113 hier verwendet werden müsste.
Begründung:
Laut dem aktuellen Dokument zur Übersicht der Prüfidentifikatoren (Stand 9.4.21) ist die einzige Ausprägung der 17004, bei welcher der NB einem MSB diese Nachricht schickt, basierend auf der Umsetzungsfrage „WiM_024“.
Die WiM_024 (UF-Katalog, Version 1.24) wiederum referenziert ausschließlich auf das Sequenzdiagramm zur Anforderung und Übermittlung von Werten.
In der aktuellen WiM (BK6-18-032) wird in den Vorbedingungen zu diesem Sequenzdiagramm folgende Bedingung aufgestellt:
„Auslöser einer Bestellung kann nur eine Zwischenablesung (s. dazu unter Nr. 4 in der Tabelle „Darstellung der zu übermittelten Werte“) sein.“
In dieser Tabelle wiederum sind unter Nummer 4 nur Zwischenablesungen aufgeführt. Lieferendemeldungen, Abmeldeanfragen, Lieferbeginn und Ersatzversorgungsmeldungen sind unter den Nummern 2 und 3 aufgeführt.
Dies bedeutet unserer Auffassung nach, dass die PID 17004 für alle Punkte unter 2 und 3 und damit auch in der benannten Umsetzungsfrage nicht zulässig ist.
Anders verhält es sich mit der PID 17113. In den Vorbedingungen zu dem Prozess laut aktueller WiM als Auslöser heißt es u.a. „… dem LF, NB, ÜNB oder MSB liegen erforderliche Werte in der entsprechenden Qualität nicht vor.“ Damit kann unseres Erachtens mit der PID 17113 die Werte für die Punkte 2 und 3 lt. der Tabelle „Darstellung der zu übermittelten Werte“ angefordert werden.
Konsequenterweise könnte dann – das ist uns bei der Analyse aufgefallen – im AHB zur ORDERS (Stand 31.3.21) im SG30-CCI-7037 der Qualifier „COS“ gestrichen werden zur PID 17004.
Sind wir hier auf dem richtigen Weg oder übersehen wir etwas?
Mit freundlichen Grüßen
Sebastian Weiße
|
2021-04-21 14:20:20 |
Sehr geehrter Herr Weiße,
mit der Umsetzungsfrage WiM_027 wurde der Anwendungsbereich der Bestellung von Werten (über eine ORDERS, der der Prüfidentifikator 17004 zugeordnet ist) präzisiert und erweitert, sodass sich der Anwendungsbereich auch auf die Nummern 2 und 3 aus der Tabelle „Darstellung der zu übermittelten Werte“ in der WiM bezieht.
Freundliche Grüße,
Ihr Forum Datenformate |
Ja
|
Holger Kampmann |
Thomas Fellhauer |
Holger Kampmann |
Sebastian Weiße |
Ticketnummer 2021-00966 |
Nein
|
|
Nein
|
Nein
|
|
Anwendungsübersicht der Prüfidentifikatoren - informatorische Lesefassung 1.0c
|
Abgeschlossen
|
Welche Datumsangabe erfolgt bei der Bestellung einer Abgrenzung der Energiemenge zum Jahreswechsel mit der ORDERS 17004?
|
Bei der Bestellung einer Abgrenzung der Energiemenge zum Jahreswechsel ist in in SG30 DTM+9 das Datum 01.01.XXXX anzugeben. |
01.04.2021
|
2021-00968 |
|
|
Sehr geehrtes Forum,
wie bestelle ich in der Marktrolle NB eine Abgrenzung der Energiemenge, zum Beispiel aufgrund einer Preisanpassung zum Jahreswechsel (z.B. 01.01.2022), mittels ORDERS PID 17004?
Vielen Dank
|
2021-04-01 13:29:10 |
Sehr geehrter Marktteilnehmer,
In der ORDERS PID 17004 ist als Hinweis an der SG30 DTM+9 (Sollablesetermin / Zeitangabe für Messwertanfrage) angegeben: „In der Sparte Strom ist immer der Wert für 00:00 Uhr des angegebenen Tages gemeint, in der Sparte Gas ist immer der zukünftige Zählerstand für 06:00 Uhr des angegebenen Tages gemeint.“ Falls Sie daher eine Abgrenzung der Energiemenge des MSB benötigen, bestellen Sie diese mit der Angabe 01.01.XXXX in SG30 DTM+9. Also in Ihrem Beispiel 01.01.2022
Freundliche Grüße
Ihr BDEW Forum Datenformate |
Ja
|
Holger Kampmann |
Thomas Fellhauer |
Thomas Fellhauer |
Thomas Fellhauer |
REQOTE / QUOTES / ORDERS / ORDRSP AHB 1.0c PID 17004 |
Nein
|
...wie in der Sitzung am 25./26.01.2021 besprochen, werden die vereinbarten Fragen / Antworten mit Veröffentlichung der neuen Dokumente auf Basis der Konsultationsergebnisse veröffentlicht.
-------------Thomas Fellhauer-------------01.04.2021 13:29
|
Nein
|
Nein
|
|
Anwendungsübersicht der Prüfidentifikatoren - informatorische Lesefassung 1.0c
|
Abgeschlossen
|
Geschäftsdatenanfrage nach Stammdaten auch für rückwirkende Zeitpunkte?
|
Geschäftsdatenanfrage nach Stammdaten immer für aktuelle Stammdaten |
23.02.2021
|
2021-00922 |
|
|
Hallo zusammen,
über den Prüfidentifikator 17102 können Stammdaten vom Lieferanten mit dem Grund Z14 - Stammdaten der Marklokation und Messlokation angefragt werden.
Dies geht hier zum Tagesdatum. Gibt es die Möglichkeit diese auch für rückwirkende Zeitpunkte anzufragen?
Vielen Dank und Beste Grüße
|
2021-02-23 16:46:26 |
Sehr geehrter Forumsteilnehmer,
eine Geschäftsdatenanfrage nach Stammdaten bezieht sich immer auf die aktuellen Stammdaten. Eine rückwirkende Anfrage nach Stammdaten ist nicht möglich.
Freundliche Grüße,
Ihr Forum Datenformate |
Ja
|
Holger Kampmann |
Thomas Fellhauer |
Holger Kampmann |
Tobias Schüßler |
siehe Seite 12 ff |
Nein
|
|
Nein
|
Nein
|
|
Anwendungsübersicht der Prüfidentifikatoren - informatorische Lesefassung 1.0c
|
Abgeschlossen
|
Wie ist die Referenz auf ID weiterer Marktlokationen im Angebot zur MSB-Rechnungsabwicklung (QUOTES) anzugeben?
|
Referenz auf ID weiterer Marktlokationen bei der Position des Messstellenbetrieb-Entgelts ausreichend |
18.01.2021
|
2021-00890 |
|
|
Hallo Forum-Team,
wenn ein Angebot zur MSB-Rechnungsabwicklung (PI 15002) mehrere Marktlokationen abdeckt (AN nutzt mehrere Marktlokationen in einem Gebäude), ist dann die "Referenz auf ID weiterer Marktlokationen" (SG32 RFF 1154) bei allen Positionen des Angebots anzugeben, oder ausschließlich bei der Position des Messstellenbetrieb-Entgelts (Artikelnummer 9990001000798)?
Mit freundlichen Grüßen
S. Reumann
|
2021-01-18 17:23:16 |
Sehr geehrter Herr Reumann,
es genügt die "Referenz auf ID weiterer Marktlokationen" bei der Position des Messstellenbetrieb-Entgelts anzugeben.
Freundliche Grüße,
Ihr Forum Datenformate |
Ja
|
Holger Kampmann |
Thomas Fellhauer |
Holger Kampmann |
Stefan Reumann |
|
Nein
|
|
Nein
|
Nein
|
|
MSCONS AHB 3.0
|
Abgeschlossen
|
Welche Datumsangabe erfolgt bei der Messwertübermittlung von Zählerständen aus einer kME / mME oder iMS bei der Übermittlung eines Turnus-Zählerstandes?
|
Die Angabe des Ablesedatums von Zählerständen ist von der verbauten Messtechnik abhängig. |
15.07.2021
|
2021-01057 |
|
|
Sehr geehrtes Forum Datenformate,
es herrscht Uneinigkeit darüber, wie abhängig von der Messtechnik die Zählerstände korrekt an den Marktpartner übermittelt werden.
Hier haben wir als Netzbetreiber drei Szenarien, für die wir eine Antwort benötigen.
Grundlage für die Messdatenbereitstellung durch den MSB ist die Bereitstellung aufgrund eines Turnuszeitpunktes (z.B. 28.02.2021) welchen der MSB uns vorab mitgeteilt hat.
Welche Datumsangaben sind bei der Übermittlung der Zählerstände anzugeben, wenn es sich um:
A: eine mME oder kME ohne Fernauslesung handelt,
B: eine kME mit Fernauslesung handelt,
C: ein iMS handelt?
Vielen Dank
|
2021-07-15 16:24:05 |
Sehr geehrter Marktteilnehmer,
die Angabe des Ablesedatums von Zählerständen ist von der verbauten Messtechnik abhängig.
Hierbei wird lediglich zwischen zwei Arten, nämlich iMS oder kME / mME unterschieden. Ob die kME ein elektronischer Zähler ist der ggf. über eine Fernauslesung verfügt und die Werte auch zu einem Zeitpunkt 00:00 speichert ist dabei nicht weiter relevant.
In Ihrem Beispiel bedeutet dies bzgl. der Datumsangaben für die Turnusablesung:
im Falle eines iMS: wäre der Messwert mit der Datumsangabe in SG10 DTM DE2379 mit dem Code 303 CCYYMMDDHHMMZZZ zu übertragen. Also immer als Beginn des Tages 00:00 Uhr. In Ihrem Beispiel also zum 01.03.2021 00:00 Uhr.
Im Falle einer kME / mME (unabhängig ob Fernauslesung oder manuelle Ablesung) wäre der Messwert mit der Datumsangabe in SG10 DTM DE2379 mit dem Code 102 CCYYMMDD zu übertragen. Da es sich in Ihrem Beispiel um eine Turnusablesung handelt (Ablesegrund: PMR und Erfassungshinweis: MRV) gilt dabei folgendes: MRV bezieht sich immer auf das Tagesende des angegebenen Tages. Bei der Sparte Strom ist das 00:00 Uhr des Folgetages. Das bedeutet, dass bei der Übertragung des Zählerstandes hier der 28.02.2021 angegeben werden muss.
Bitte beachten Sie, dass dies für alle Ablesegründe, die mit dem Erfassungshinweis MRV oder EMV analog gilt.
Ergänzender Hinweis: Bei der darauffolgenden Übermittlung der Energiemengen (MSCONS AHB 3.0 Kapitel 4.2):
Für Energiemengen, die aus der Messtechnik iMS ermittelt werden, gilt: In SG10 DTM+164 (Ende Messperiode) wird das Datum des Vortages des Zeitpunkts als Ende angegeben, zu dem der letzte Messwert mit den oben angegebenen Kriterien übermittelt wurde.
Für Energiemengen, die aus der Messtechnik kME ohne RLM und mME ermittelt werden, gilt: In SG10 DTM+164 (Ende Messperiode) wird das Datum des Zeitpunkts als Ende angegeben, zu dem der letzte Messwert mit den oben angegebenen Kriterien übermittelt wurde.
Das bedeutet ihn Ihrem Beispiel, dass die Energiemenge unabhängig von der verbauten Messtechnik als Ende Messperiode in SG10 DTM+164 den 28.02.2021 hat.
Freundliche Grüße
Ihr Forum Datenformate |
Ja
|
Reinhard Döring |
Thomas Seipt |
Thomas Fellhauer |
Thomas Fellhauer |
Kapitel 4 Zählerstände und Energiemengen |
Nein
|
Frage und Antwort abgestimmt und daher veröffentlicht, da selbsterklärend und mehrfach bei mir (auch persönlich) eingegangen
-------------Thomas Fellhauer-------------15.07.2021 16:25
|
Nein
|
Nein
|
|
ActivationDocument AWT 1.0
|
Abgeschlossen
|
Wir funktioniert die Abstimmung des Ausgleichsfahrplans im Planwertmodell?
|
Diese Thematik wird mit einer Umsetzungsfrage beantwortet. |
13.07.2021
|
2021-01055 |
|
|
Sehr geehrtes Forum,
der Abruf (sowohl im Aufforderungsfall als auch im Duldungsfall) wird laut Prozessdefinition vom anweisenden NB übermittelt. In der Weiterleitung an den LF bzw. BKV ist im Feld OriginalSenderIdentification dann dieser anweisende NB erhalten.
Der BKV muss im Planwertmodell einen Ausgleichsfahrplan mit dem anfordernden NB erstellen. Woher bekommt der BKV die Information wer der anfordende NB ist. Müsste dies nicht auch im ActivationDocument übermittelt werden? Kann hier an dieser Stell dann auch der Redispatch-Bilanzkreis des anfordernden NB übermittelt werden?
Vielen Dank
|
2021-07-13 12:48:50 |
Sehr geehrte Marktteilnehmerin,
für Ihre Frage ist aufgrund der zu dieser Stelle unklaren Prozesslage eine Umsetzungsfrage in Bearbeitung.
Mit freundlichem Gruß
Ihr BDEW-Forum Datenformate |
Ja
|
Johannes Umbach |
|
Johannes Umbach |
Anja Meier |
ActivationDocument
Abruf im Aufforderungsfall mit Delta-/Sollwertanweisung DP an LF bzw. LF an BKV
Abruf im Duldungsfall mit Sollwertanweisung DP an LF bzw. LF an BKV |
Nein
|
-------------Johannes Umbach-------------14.07.2021 08:37
Antwort eingefügt
in PG besprochen
-------------Katia Schubert-------------14.07.2021 09:37
|
Nein
|
Nein
|
|
MSCONS AHB 2.3c
|
Abgeschlossen
|
Wie erfolgt der Versand der Energiemengen PI 13019 BGM 7 bei rechnerischen Abgrenzungen?
|
Abgrenzungen ohne Zählerstände sind in einer Nachricht mittels Wiederholung der SG9 LIN zu übermitteln. |
18.06.2021
|
2021-01036 |
|
|
Sehr geehrtes Forum Datenformate,
es herrscht Uneinigkeit darüber, wie für ein Zeitintervall (Beispiel 01.04.2020 – 31.03.2021) Energiemengen auf Ebene der Marktlokation gebildet werden.
Als NB haben wir beim MSB eine Abgrenzung zum 01.07.2020 und zum 01.01.2021 mittelt ORDERS aufgrund der MwSt. Anpassung bestellt. Für den Zeitpunkt 01.04.2020 und 31.03.2021 liegt ein Zählerstand vor.
Wie sind diese Mengen durch den MSB zu versenden? Über die Wiederholung der LIN Segmente in einer Nachricht, oder können die Abgrenzungen in einzelnen Nachrichten mit den entsprechenden STS Segmenten versendet werden?
|
2021-06-18 13:12:56 |
Sehr geehrter Marktteilnehmer,
die Mengen in Ihrem Beispiel werden über die Wiederholung der LIN Segmente in einer Nachricht übermittelt. Es ist nicht zulässig die abgegrenzten Mengen die keine Zählerstände als Basis haben in einzelnen Nachrichten zu übersenden.
Am Datenelement: DE4405 der SG10 STS Grundlage der Energiemenge ist mit den Bedingungen: [87] und [88] an den Qualifier / Codes:
Z36 Zählerstand zum Beginn der angegebenen Energiemenge vorhanden und kommuniziert
Z37 Zählerstand zum Ende der angegebenen Energiemenge vorhanden und kommuniziert
zusätzlich beschrieben, dass für den frühesten angegeben Zeitpunkt und den spätesten angegeben Zeitpunkt innerhalb einer Nachricht ein Zählerstand vorhanden und kommuniziert sein muss.
In Ihrem Beispiel wäre die MSCONS Nachricht mit dem Prüfidentifikator 13019 daher wie folgt aufzubauen:
lfd. Position: SG9 LIN: Position 1
Mengenangabe im SG9 QTY – Menge im Zeitintervall 1
Beginn Messperiode SG10 DTM+163: 01.04.2020
Ende Messperiode SG10 DTM+164: 30.06.2020
Grundlage der Energiemenge SG10 STS: Z36 Zählerstand zum Beginn der angegebenen Energiemenge vorhanden und kommuniziert
Grundlage der Energiemenge SG10 STS: Z39 Zählerstand zum Ende der angegebenen Energiemenge nicht vorhanden da Mengenabgrenzung
lfd. Position: SG9 LIN: Position 2
Mengenangabe im SG9 QTY Menge im Zeitintervall 2
Beginn Messperiode SG10 DTM+163: 01.07.2020
Ende Messperiode SG10 DTM+164: 31.12.2020
Grundlage der Energiemenge SG10 STS: Z38 Zählerstand zum Beginn der angegebenen Energiemenge nicht vorhanden da Mengenabgrenzung
Grundlage der Energiemenge SG10 STS: Z39 Zählerstand zum Ende der angegebenen Energiemenge nicht vorhanden da Mengenabgrenzung
lfd. Position: SG9 LIN: Position 3
Mengenangabe im SG9 QTY – Menge im Zeitintervall 3
Beginn Messperiode SG10 DTM+163: 01.01.2021
Ende Messperiode SG10 DTM+164: 31.03.2021
Grundlage der Energiemenge SG10 STS: Z38 Zählerstand zum Beginn der angegebenen Energiemenge nicht vorhanden da Mengenabgrenzung
Grundlage der Energiemenge SG10 STS: Z37 Zählerstand zum Ende der angegebenen Energiemenge vorhanden und kommuniziert
Freundliche Grüße
Ihre Forum Datenformate |
Ja
|
Reinhard Döring |
Thomas Seipt |
Thomas Fellhauer |
Thomas Fellhauer |
MSCONS AHB Übermittlung von Energiemengen |
Nein
|
-------------Thomas Fellhauer-------------18.06.2021 13:13
Formatierung etwas angepasst zur besseren Lesbarkeit, keine textliche Änderung-------------Thomas Fellhauer-------------21.06.2021 08:46
|
Nein
|
Nein
|
|
MSCONS AHB 2.3c
|
Abgeschlossen
|
Wie wird eine Energiemenge aus zwei Zählerständen aus einer Turnusablesung gebildet?
|
Das Ablesedatum in SG10 DTM+9 mit Ablesegrund PMR und Ablesehinweis MRV ist als Ende des angegebenen Tages zu interpretieren. |
01.04.2021
|
2021-00969 |
|
|
Sehr geehrtes Forum,
Wie wird eine Energiemenge mit Beginn- und Endedatum gebildet, wenn ein Zählerstand aus einer kME ohne RLM oder einer mME mit dem Ablesegrund PMR und dem Erfassungshinweis „MRV“ vorliegt?
Beispiel:
Turnusablesung Zählerstand am 01.11.2019 und
Turnusablesung Zählerstand am 01.11.2020 liegt vor und wird übermittelt.
Vielen Dank
|
2021-04-01 13:35:53 |
Sehr geehrter Marktteilnehmer,
Da bei dem Ablesegrund PMR und dem Erfassungshinweis „MRV“ bei kME ohne RLM oder einer mME eine Datumsangabe ohne Uhrzeit der tatsächlichen Ablesung vorliegt, wird auf dieser Basis die Energiemenge auf Ebene der Marktlokation wie folgt gebildet (1:1 Beziehung zwischen Markt- und Messlokation, gemessene Energiemenge entspricht dem Verbrauch der Marktlokation, ohne weitere angeforderte Abgrenzungen).
Energiemenge Beginndatum (SG10 DTM+163): 02.11.2019 – Endedatum (SG10 DTM+164) 01.11.2020.
Freundliche Grüße
Ihr BDEW Forum Datenformate |
Ja
|
Reinhard Döring |
Thomas Seipt |
Thomas Fellhauer |
Thomas Fellhauer |
MSCONS AHB 2.3c Messwert Energiemenge 13019 |
Nein
|
...wie in der Sitzung am 25./26.01.2021 besprochen, werden die vereinbarten Fragen / Antworten mit Veröffentlichung der neuen Dokumente auf Basis der Konsultationsergebnisse veröffentlicht.
-------------Thomas Fellhauer-------------01.04.2021 13:36
|
Nein
|
Nein
|
|
MSCONS AHB 2.3c
|
Abgeschlossen
|
Wie werden Energiemengen mit Beginn- und Endedatum gebildet, wenn Zählerstände mit unterschiedlichen Abelsegründen / -hinweisen vorliegen?
|
Regel „Beginn/Ende Messperiode“ für die Energiemenge: Beginn Messperiode bezieht sich immer auf den Tagesbeginn des angegebenen Tages, Ende Messperiode bezieht sich immer auf das Tagesende des angegebenen Tages |
01.04.2021
|
2021-00967 |
|
|
Sehr geehrtes Forum,
wie werden die drei Energiemengen mit Beginn- und Endedatum gebildet, wenn die folgenden vier Zählerstände aus einer kME ohne RLM oder einer mME vorliegen?
1. Zählerstand
Ablesegrund: COS „Vertragswechsel“
Erfassungshinweis: SMV „Anfangszählerstand“
Ablesedatum: 01.03.2020
Zählerstand: 1000 KWh
2. Zählerstand
Ablesegrund: COT „Zwischenablesung“
Erfassungshinweis: MRV: Zählerstand
Ablesedatum: 01.04.2020
Zählerstand: 1300 KWh
3. Zählerstand
Ablesegrund: PMR „Turnusablesung“
Erfassungshinweis: MRV: Zählerstand
Ablesedatum: 01.05.2020
Zählerstand: 1500 KWh
4. Zählerstand
Ablesegrund: COS „Vertragswechsel“
Erfassungshinweis: EMV: Zählerstand
Ablesedatum: 31.05.2020
Zählerstand: 1900 KWh
Vielen Dank
|
2021-04-01 13:19:20 |
Sehr geehrter Marktteilnehmer,
Regel „Beginn/Ende Messperiode“ für die Energiemenge
Beginn Messperiode“ bezieht sich immer auf den Tagesbeginn des im DE2380 angegebenen Tages. Das ist der angegebene Tag 00:00 Uhr.
„Ende Messperiode“ bezieht sich immer auf das Tagesende des im DE2380 angegebenen Tages. Das ist der Folgetag 00:00 Uhr.
Bei Anwendung der Regel auf Ihr Beispiel stellt sich folgende Konstellation dar: Die drei Energiemengen sind vom MSB der Marktlokation auf Basis der von Ihnen genannten Zählerstände wie folgt zu bilden und den berechtigten Marktpartner zu übermitteln:
Energiemenge
Beginndatum: 01.03.2020
Endedatum: 01.04.2020
Menge: 300 KWh
Energiemenge
Beginndatum: 02.04.2020
Endedatum: 01.05.2020
Menge: 200 KWh
Energiemenge
Beginndatum: 02.05.2020
Endedatum: 31.05.2020
Menge: 400 KWh
Freundliche Grüße
Ihr BDEW Forum Datenformate |
Ja
|
Reinhard Döring |
Thomas Seipt |
Thomas Fellhauer |
Thomas Fellhauer |
MSCONS AHB 2.3c PID 13019 Messwert Energiemenge (Strom) |
Nein
|
...wie in der Sitzung am 25./26.01.2021 besprochen, werden die vereinbarten Fragen / Antworten mit Veröffentlichung der neuen Dokumente auf Basis der Konsultationsergebnisse veröffentlicht.
-------------Thomas Fellhauer-------------01.04.2021 13:19
|
Nein
|
Nein
|
|
MSCONS AHB 2.3c
|
Eingegangen
|
Mit welcher Datumsangabe wird einMesswert aufgrund einer Abmeldung NN bestellt und wie wird dieser vom MSB versendet?
|
In der ORDERS PID 17004 wird bei der Datumsangabe immer der Beginn des Tages angegeben, für die Übermittlung der Messwerte in der MSCONS gibt es unterschiedliche Varianten. |
01.04.2021
|
2021-00966 |
|
|
Sehr geehrtes Forum,
in der Rolle als NB haben wir eine Abmeldung eines Lieferanten zum 31.01.2021 an einer Marktlokation bestätigt. An der dazugehörigen Messlokation ist eine kME ohne RLM oder einer mME verbaut. Ein Zählerstand liegt nicht vor, sodass wir diesen beim MSB bestellen.Daraus ergeben sich folgende Fragen:
Frage1:
Welche Datums Angabe erfolgt in der ORDERS mit dem PID 17004?
Frage 2:
Wie teilt der MSB die Informationen in der MSCONS mit?
Vielen Dank
|
2021-04-01 13:06:47 |
Sehr geehrter Marktteilnehmer,
Antwort auf Frage1:
in der ORDERS PID 17004 ist als Hinweis an der SG30 DTM+9 (Sollablesetermin / Zeitangabe für Messwertanfrage) angegeben: „In der Sparte Strom ist immer der Wert für 00:00 Uhr des angegebenen Tages gemeint, in der Sparte Gas ist immer der zukünftige Zählerstand für 06:00 Uhr des angegebenen Tages gemeint.“ Da die Zuordnung des Lieferanten zur Lokation am 31.01.2021 „Ende des Tages“ beendet wird, bestellen Sie den Messwert zum 01.02.2021 mit dem Ablesegrund „COS“.
Antwort auf Frage2: Hier gibt es unterschiedliche Varianten:
Variante 1:
Die Messwerte erhalten die Marktrollen: NB, LF
In der MSCONS mit dem PID 13017 wird zusätzlich der Erfassungshinweis „SMV“ übermittelt, da mit dem Erfassungshinweis „SMV“ das in der MSCONS PID 13017 das in SG10 DTM+9 (01.02.2021) angegebene Ablesedatum den Start des Tages definiert.
Variante 2:
Die Messwerte erhalten die Marktrollen: NB, LF
In der MSCONS mit dem PID 13017 wird zusätzlich der Erfassungshinweis „EMV“ übermittelt, da mit dem Erfassungshinweis „EMV“ das in der MSCONS PID 13017 das in SG10 DTM+9 (31.01.2021) angegebene Ablesedatum das Ende des Tages definiert.
Variante 3:
Die Messwerte erhalten die Marktrollen: NB, LF
In der MSCONS mit dem PID 13017 wird zusätzlich der Erfassungshinweis „SMV“ übermittelt, da mit dem Erfassungshinweis „SMV“ das in der MSCONS PID 13017 das in SG10 DTM+9 (01.02.2021) angegebene Ablesedatum den Start des Tages definiert
und zusätzlich
in der MSCONS mit dem PID 13017 wird zusätzlich der Erfassungshinweis „EMV“ übermittelt, da mit dem Erfassungshinweis „EMV“ das in der MSCONS PID 13017 das in SG10 DTM+9 (31.01.2021) angegebene Ablesedatum das Ende des Tages definiert.
Freundliche Grüße
Ihr BDEW Forum Datenformate
|
Ja
|
Reinhard Döring |
Thomas Seipt |
Thomas Fellhauer |
Thomas Fellhauer |
MSCONS AHB 2.3c PID 13017,
REQOTE / QUOTES / ORDERS / ORDRSP AHB 1.0c, PID 17004 |
Nein
|
...wie in der Sitzung am 25./26.01.2021 besprochen, werden die vereinbarten Fragen / Antworten mit Veröffentlichung der neuen Dokumente auf Basis der Konsultationsergebnisse veröffentlicht.
-------------Thomas Fellhauer-------------01.04.2021 13:07
|
Nein
|
Nein
|
|
MSCONS AHB 2.3c
|
Abgeschlossen
|
Wie wird ein Zählerstand aufgrund der Bestellung mittels ORDERS PID 17004 mit dem Ablesegrund COS an den Besteller übermittelt?
|
Es ist dasselbe Datum aus der ORDERS mit dem Ablesegrund „COS“ sowie dem Erfassungshinweis „SMV“ anzugeben. |
01.04.2021
|
2021-00965 |
|
|
Sehr geehrtes Forum,
wie ist der Zählerstand bei kME ohne RLM oder einer mME aufgrund der Bestellung eines Messwertes mittels ORDERS PID 17004 für Strom mit dem Ablesegrund „COS“ vom MSB an den Besteller zu übermitteln, bei einer Messwertanforderung zum 01.03.2021 aufgrund des Wechsels eines Marktpartners an der Marktlokation?
Vielen Dank
|
2021-04-01 12:48:58 |
Sehr geehrter Marktteilnehmer,
In der ORDERS PID 17004 ist als Hinweis an der SG30 DTM+9 (Sollablesetermin / Zeitangabe für Messwertanfrage) angegeben: „In der Sparte Strom ist immer der Wert für 00:00 Uhr des angegebenen Tages gemeint, in der Sparte Gas ist immer der zukünftige Zählerstand für 06:00 Uhr des angegebenen Tages gemeint.“
Daraus ergibt sich, dass der MSB dem Besteller einen Zählerstand mittels MSCONS PID 13017, zum 01.03.2021 und dem Ablesegrund „COS“ sowie dem Erfassungshinweis „SMV“ übermittelt. Mit dem Erfassungshinweis „SMV“ wird in der MSCONS PID 13017 das in SG10 DTM+9 angegebene Ablesedatum als Start des angegebenen Tages definiert.
Freundliche Grüße
Ihr Forum Datenformate
|
Ja
|
Reinhard Döring |
Thomas Seipt |
Thomas Fellhauer |
Thomas Fellhauer |
MSCONS AHB 2.3c Messwert Zählerstand 13017 |
Nein
|
...wie in der Sitzung am 25./26.01.2021 besprochen, werden die vereinbarten Fragen / Antworten mit Veröffentlichung der neuen Dokumente auf Basis der Konsultationsergebnisse veröffentlicht.
-------------Thomas Fellhauer-------------01.04.2021 12:49
|
Nein
|
Nein
|
|
MSCONS AHB 2.3c
|
Abgeschlossen
|
Wie sind die Ablesehinweise zu den Ablesegründen bei Zählerständen mit Datumsangabe definiert?
|
Wenn das Ablesedatum eine Datumsangabe ohne Uhrzeit ist: Ablesehinweis SMV als Beginn des angegebenen Tages, Ablesehinweise EMV oder MRV als Ende des angegebenen Tages |
01.04.2021
|
2021-00964 |
|
|
Sehr geehrtes Forum,
wie sind die Ablesehinweise zu den einzelnen Ablesegründen in der MSCONS zu Zählerständen PID 13017 / 13002 im Zusammenspiel mit der Datumsangabe in SG10 DTM+9 (Ablesedatum) bei einer kME ohne RLM oder einer mME definiert? Hierzu gibt es im Markt derzeit unterschiedliche Auffassungen.
Vielen Dank
|
2021-04-01 12:38:47 |
Sehr geehrter Marktteilnehmer,
Bei der Übermittlung einer MSCONS PID 13017 oder 13002 sind die Ablesegründe und die dazugehörigen Ablesehinweise für die Datumsangabe wie folgt definiert
Ablesedatum in SG10 DTM+9 mit Ablesegrund COS und Ablesehinweis SMV = Beginn des angegebenen Tages. Bei der Sparte Strom ist das 00:00 Uhr des angegebenen Tages. Bei der Sparte Gas ist das 06:00 Uhr des angegebenen Tages.
Ablesedatum in SG10 DTM+9 mit Ablesegrund COS und Ablesehinweis EMV = Ende des angegebenen Tages. Bei der Sparte Strom ist das 00:00 Uhr des Folgetages. Bei der Sparte Gas ist das 06:00 Uhr des Folgetages.
Ablesedatum in SG10 DTM+9 mit Ablesegrund COT/PMR/ABZ und Ablesehinweis MRV = Ende des angegebenen Tages Bei der Sparte Strom ist das 00:00 Uhr des Folgetages. Bei der Sparte Gas ist das 06:00 Uhr des Folgetages.
Hinweis Die Ablesegründe COM / IOM / ROM / CMP werden hier nicht weiter betrachtet, da hier das Ablesedatum in SG10 DTM+9 minutengenau mit UTC Abweichung angegeben wird.
Freundliche Grüße
Ihr BDEW Forum Datenformate |
Ja
|
Reinhard Döring |
Thomas Seipt |
Thomas Fellhauer |
Thomas Fellhauer |
MSCONS AHB 2.3, Anwendungsübersicht Zählerstände Prüfidentifikator 13017 / 13002, Ablesegründe / Ablesehinweise. |
Nein
|
...wie in der Sitzung am 25./26.01.2021 besprochen, werden die vereinbarten Fragen / Antworten mit Veröffentlichung der neuen Dokumente auf Basis der Konsultationsergebnisse veröffentlicht.
-------------Thomas Fellhauer-------------01.04.2021 12:39
|
Nein
|
Nein
|
|
MSCONS AHB 2.3c
|
Abgeschlossen
|
Ist bei der Übermittlung eines vorläufigen Wertes eine Statuszusatzinformation anzugeben?
|
Vorläufige Werte sind nicht mit Statuszusatzinformationen zu versehen. |
01.04.2021
|
2021-00963 |
|
|
Sehr geehrtes Forum,
Ist bei der Übermittlung eines vorläufigen Wertes (SG10 QTY Mengenangaben DE6063 mit Wert Z18 vorhanden) keine Statuszusatzinformation mehr anzugeben? Dies war bisher als Bedingung vorhanden, dass eine Statuszusatzinformation sowohl für vorläufige Werte als auch für Ersatzwerte angegeben werden muss.
Vielen Dank
|
2021-04-01 12:27:39 |
Sehr geehrter Marktteilnehmer,
vorläufige Werte sind nicht mit Statuszusatzinformationen zu versehen.
Weiterführende Informationen dazu finden Sie im Umsetzungsfragenkatalog zur Marktkommunikation in der Umsetzungsfrage WiM_044.
Freundlichen Grüße
Ihr BDEW Forum Datenformate |
Ja
|
Reinhard Döring |
Thomas Seipt |
Thomas Fellhauer |
Thomas Fellhauer |
MSCONS AHB 2.3c Lastgang (Strom) PID: 13018 Statuszusatzinformation |
Nein
|
...wie in der Sitzung am 25./26.01.2021 besprochen, werden die vereinbarten Fragen / Antworten mit Veröffentlichung der neuen Dokumente auf Basis der Konsultationsergebnisse veröffentlicht.
-------------Thomas Fellhauer-------------01.04.2021 12:28
|
Nein
|
Nein
|
|
AcknowledgementDocument AWT 1.0
|
Eingegangen
|
Welche Prüfungen sind im Rahmen der Erstellung des AcknowledgementDocument durchzuführen?
|
Aktuell ist ausschließlich die Syntaxprüfung vorgesehen. |
19.05.2021
|
2021-01020 |
|
|
Sehr geehrtes Forum,
welche Prüfungen sind im Rahmen der Erstellung des AcknowledgementDocument durchzuführen?
Soll hier eine reine Syntaxprüfung (analog CONTRL) oder auch eine Verarbeitbarkeitsprüfung (analog APERAK) erfolgen?
Wenn auch eine Verarbeitbarkeitsprüfung erfolgen soll, wie erkennt man anhand der Nachricht in welchem Anwendungsfall (in welchem AWT) man sich befindet.
Z.B. im ActivitionDocument dürfen im Aufforderungsfall für das Feld MeasureUnit die Werte MAW und P1 enthalten sein, im Duldungsfall aber nur P1.
Es gibt aber keine Unterscheidung der Nachrichten anhand irgendwelcher Identifikatoren (wie Prüfidentifikatoren bei EDIFACT). Beide können auch, z.B. im Fall der Sollwertanweisung, dieselben Typen-Ausprägungen haben:
Aufforderungsfall:
DocumentType: A96
ProcessType: A41
BusinessType: A46/A85
Duldungsfall:
DocumentType: A96
ProcessType: A41
BusinessType: A85
Vielen Dank
|
2021-05-19 12:53:16 |
Sehr geehrte Fragestellerin,
aktuell sind noch keine fachlichen/inhaltlichen Prüfungen vorgesehen und daher auch keine Prüfkriterien veröffentlicht. Es sind nur Syntaxprüfungen durchzuführen.
Freundliche Grüße,
Ihr Forum Datenformate |
Ja
|
Stephan Schlunke |
Torsten Henning |
Tim Geisendörfer |
Anja Meier |
AcknowledgementDocument AWT 1.0
ActivationDocument AWT 1.0 - Abruf im Aufforderungsfall mit Delta-/Sollwertanweisung bzw. Abruf im Duldungsfall mit Sollwertanweisung |
Nein
|
Nach Antwort-Vorschlag von Torsten Henning in der PG XML besprochen und veröffentlicht.
-------------Katia Schubert-------------01.06.2021 15:07
|
Nein
|
Nein
|
|
AcknowledgementDocument AWT 1.0
|
Eingegangen
|
Übermittlungsfristen ACK
|
ACK muss unverzüglich nach Prüfung der Datei übermittelt werden |
26.04.2021
|
2021-01001 |
|
|
Sehr geehrtes Forum,
wie sind die Fristen für die Übermittlung einer ACK im Redispatch?
Für die Marktkommunikation mit EDIFACT sind die Firsten für die CONTRL und APERAK in dem entsprechendem AHB zu finden. Für die ACK bei Kommunikation mit XML sind keine Informationen zu den Fristen zu finden.
Gelten hier die gleichen Fristen wie im Fahrplanversand (siehe "Fahrplanmeldung in Deutschland"), wo ja bereits per XML kommuniziert wird?
Vielen Dank
|
2021-04-26 12:04:54 |
Sehr geehrte Fragestellerin,
vielen Dank für Ihre Anfrage.
Bei der "Fahrplananmeldung in Deutschland", auf die Sie Bezug nehmen, verpflichten sich die ÜNB, unmittelbar nach Erhalt einer BK-Fahrplananmeldung diese zu prüfen und unverzüglich einen ACK mit dem Prüfergebnis an den BKV zu übermitteln. Beim harmonisierten Abrufprozess gemäß RD 1.0 geht man davon aus, dass nach spätestens 3 Minuten die Rückantwort auf die Aktivierungsorder in Form eines ACK beim Sender (ÜNB) eintreffen muss. Auch diese Angabe entspricht einer unverzüglichen automatisierten Prüfung der empfangenen Datei seitens des Empfängers, in deren Ergebnis sofort ein ACK mit dem Prüfergebnis an den Dateisender übermittelt wird. Diese unverzügliche Reaktion mittels ACK wird auch beim RD 2.0-Prozess erwartet. Eine Angabe in Sekunden ist bei einer erwarteten unverzüglichen Reaktion nicht erforderlich, zumal die Wartezeit aus Sicht des Empfängers des ACK vom Versand seiner Datei bis zum Erhalt des ACK auch von den Laufzeiten der Datenübermittlungen abhängig ist.
Freundliche Grüße
Ihr Forum Datenformate |
Ja
|
Stephan Schlunke |
Torsten Henning |
Stephan Schlunke |
Anja Meier |
|
Nein
|
|
Nein
|
Nein
|
|
Codeliste der Artikelnummern des BDEW 4.1h
|
Abgeschlossen
|
Darf die Artikelnummer uneingeschränkt genutzt werden?
|
Artikelnummer muss uneingeschränkt genutzt werden. |
29.04.2021
|
2021-01004 |
|
|
Sehr geehrte Damen und Herren,
für die Zusatzdienstleistungen nach § 35 Abs. 2 und Abs. 3 MsbG (Art.-Nr. 81 bis 86) wird in der BDEW-Codeliste auf die Hochziffer 6 verwiesen. Dort heißt es "Die Artikelnummer ist in diesem Anwendungsfall erst ab dem 01.04.2021 zu nutzen.".
Als Lieferant stellen uns MSB nun zwei verschiedene Arten von MSB-INVOIC, die die Art.-Nr. 81 bis 86 enthalten:
Fall1 - Zeitpunkt der Rechnungserstellung: Die Art.-Nr. werden für einen Abrechnungszeitraum < 01.04.2021 in Rechnung gestellt. Das Stelldatum der Rechnung ist jedoch > 01.04.2021.
Fall2 - Abrechnungszeitraum: Die Art.-Nr. werden für einen Abrechnungszeitraum > 01.04.2021 in Rechnung gestellt.
Die Verwendung der Art.-Nr. ist aus unserer Sicht an der Stelle leider nicht eindeutig. Bezieht sich die Nutzung der Art.-Nr. auf den Zeitpunkt der Rechnungserstellung (Stelldatum) oder auf den Abrechnungszeitraum der MSB-INVOIC?
Falls der Abrechnungszeitraum entscheidend ist, müsste eine MSB-INVOIC mit Bsp.-Abrechnungszeitraum 01.01.2021 bis 31.12.2021 für den Teilzeitraum 01.01.-31.03.2021 einen Rechnungsteil mit Art.-Nr. 79 und für den Teilzeitraum 01.04.2021-31.12.2021 einen Rechnungsteil mit Bsp.-Art.-Nr. 83 enthalten. Ist unsere Einschätzung korrekt?
Ich bitte Sie um Beantwortung unserer Fragestellungen.
|
2021-04-29 13:55:39 |
Sehr geehrter Marktteilnehmer,
die Artikelnummern mit der Fußnote 6 sind unabhängig vom Abrechnungszeitraum ab dem 1. April 2021 nutzbar.
Mit freundlichem Gruß,
Ihr BDEW-Forum Datennformate |
Ja
|
Beate Becker |
Beate Becker |
Beate Becker |
Daniel Benz |
|
Nein
|
siehe Antwort zur uneingeschränkten Nutzung der Artikelnummer => gleiche Antwort geben
-------------Beate Becker-------------02.06.2021 11:46
|
Nein
|
Nein
|
|
Codeliste der Artikelnummern des BDEW 4.1h
|
Abgeschlossen
|
Darf die Artikelnummer uneingeschränkt genutzt werden?
|
Artikelnummer muss uneingeschränkt genutzt werden. |
13.04.2021
|
2021-00982 |
|
|
Sehr geehrte Damen und Herren,
wie ist die Fußnote 6 "Die Artikelnummer ist in diesem Anwendungsfall erst ab dem 01.04.2021 zu nutzen" für die Zusatzleistung zu verstehen?
- Bezieht sich das Datum auf den Rechnungszeitraum? (ergo Zeitscheibentrennung: bis 31.03. ist 9990001000798 zu verwenden, ab 01.04. die entsprechende Artikelnummer für die Zusatzleistung)
- oder sind die neuen Artikelnummern ab 01.04.2021 auch für davorliegende Rechnungszeiträume gültig ?
Vielen Dank im Voraus!
|
2021-04-13 15:48:25 |
Sehr geehrter Marktteilnehmer,
die Artikelnummern mit der Fußnote 6 sind unabhängig vom Abrechnungszeitraum ab dem 1. April 2021 nutzbar.
Mit freundlichem Gruß,
Ihr BDEW-Forum Datennformate |
Ja
|
Beate Becker |
Beate Becker |
Beate Becker |
Madeleine Meier |
Fußnote 6: "Die Artikelnummer ist in diesem Anwendungsfall erst ab dem 01.04.2021 zu nutzen" |
Nein
|
|
Nein
|
Nein
|
|
Codeliste der Artikelnummern des BDEW 4.1h
|
Abgeschlossen
|
Wie wird der Datenspeicher abgerechnet?
|
Der Datenspeicher wird als eigene Position abgerechnet. |
29.03.2021
|
2021-00959 |
|
|
Ist es zulässig Datenspeicher+Mengenumwerter für die Artikelnummer 9990001 00065 7 auszuweisen oder darf ausschließlich der Preisbestandteil Mengenenumwerter für diese Artikelnummer verwendet werden?
|
2021-03-29 16:11:15 |
Sehr geehrter Marktteilnehmer,
wir gehen davon aus, dass der Preis für den Datenspeicher auf dem veröffentlichten Preisblatt des NB separat ausgewiesen ist. Dementsprechend muss er in einer eigenen Position in der INVOIC abgerechnet werden. Die dafür passende Artikelnummer ist die 9990001 00062 3 "Entgelt für Einbau, Betrieb und Wartung der Messtechnik".
Mit freundlichem Gruß,
Ihr BDEW-Forum Datenformate |
Ja
|
Beate Becker |
Beate Becker |
Beate Becker |
René Lotter |
|
Nein
|
|
Nein
|
Nein
|
|
Codeliste der Artikelnummern des BDEW 4.1h
|
Eingegangen
|
Müssen Artikelnummern und Preisblatt zusammenpassen?
|
Ja, die Artikelnummern müssen mit dem Preisblatt korrespondieren. |
11.02.2021
|
2021-00914 |
|
|
Auf Seite 5 wurde für die Netznutzungsabrechnung Strom (GPKE) und Netznutzungsabrechnung Gas (GeLi Gas) die Artikelnummer 9990001 00065 7 für die Abrechnung von Wandlern und Mengenumwertern aufgenommen. Es stellt sich die Frage, ob die Abrechnungen des Messstellenbetriebs mit dem Messstellenbetriebsentgelt, welches des Wandler/Mengenumwerter bereits beinhaltet weiterhin so abgerechnet werden kann, oder ob es zwingend notwendig ist, das Messstellenbetriebsentgelt für den Zähler getrennt vom Messstellenbetriebsengelt für den Wandler/Mengenumwerter abzurechnen.
Derzeit wird das Messstellenbetriebsentgelt (incl. Wandler) mit der Artikelnummer 9990001000798 (Entgelt für Messstellenbetrieb) abgebildet.
|
2021-02-11 15:00:50 |
Sehr geehrter Marktteilnehmer,
die Rechnung muss anhand des veröffentlichten Preisblattes nachvollziehbar sein. Das bedeutet, dass bei einer separaten Angabe im Preisblatt für den Wandler/Mengenumwerter, ist dieser auch separat in der Rechnung auszuweisen. Aus der Codeliste der Artikelnummern ist immer die passende Artikelnummer zu verwenden.
Mit freundlichem Gruß,
Ihr BDEW-Forum Datenformate |
Ja
|
Beate Becker |
Beate Becker |
Beate Becker |
Christine Jacob |
|
Nein
|
|
Nein
|
Nein
|
|
Codeliste der Artikelnummern des BDEW 4.1h
|
Eingegangen
|
Welche Artikelnummern werden für iMS und mME in der Netznutzungsrechnung verwendet?
|
Diese Art der Abrechnung ist zwischen NB und LF bilateral abzustimmen. |
03.02.2021
|
2021-00907 |
|
|
Hallo BDEW-Forum,
wir haben eine Frage bzgl. der neuen Artikel-Nr. für Zusatzleistungen:
1. Zusatzdienstleistung nach § 35 Abs. 2 Nr. 1 MsbG Artikel 81 mit der Artikel-Nr. 9990001 000813
2. Zusatzdienstleistung nach § 35 Abs. 2 Nr. 3 MsbG Artikel 83 mit der Artikel-Nr. 9990001 00083 9
Die beiden o.g. Artikel-Nr. sind ab dem 01.04.2021 in der MSB-Rechnung (31009) bei mME und iMS zu verwenden. Wird als Zusatzleistung in der MSB-Rechnung ein Wandler abgerechnet, gilt die Artikel-Nr. (9990001 000813) und für ein Steuergerät (TRE) die Artikel-Nr. (9990001 00083 9) .
Da in der Artikel-Nr. Liste nur in der "Spalte H" für MSB-Rechnung ein Flag sitzt, stellt sich uns die Frage, welche Artikel-Nr. bei mME und iMS für Wandler und Steuergerät (TRE) innerhalb einer integrierten NN-Rechnung (31002) zu verwenden sind.
Ebenfalls die beiden o.g. Artikel-Nr. 9990001 000813 und 9990001 00083 9? Oder gilt hier weiterhin der Artikel 9990001 00079 8 auch für Wandler und Steuergerät (TRE)?
Über eine Rückmeldung wären wir dankbar.
|
2021-02-03 16:22:36 |
Sehr geehrter Marktteilnehmern,
da keine Vorgaben der BNetzA vorliegen, ist diese Abrechnungsart trilateral (NB, MSB und LF) abzustimmen. Im Rahmen dieser Abstimmung ist zwischen NB und LF zu vereinbaren, wie die dabei verwendete INVOIC ausgeprägt wird, insbesondere welche Artikelnummern wofür verwendet werden.
Mit freundlichem Gruß,
Ihr BDEW-Forum Datenformate |
Ja
|
Beate Becker |
Beate Becker |
Beate Becker |
Tanja Lohnert |
|
Nein
|
|
Nein
|
Nein
|
|
Codeliste der Artikelnummern des BDEW 4.1h
|
Abgeschlossen
|
Welche Artikelnummer wird ab dem 1. April 2021 in der Netznutzungsabrechnung für den Wandler/Mengenumwerter genutzt?
|
Ab dem 1. April gilt ausschließlich die Artikelnummer 9990001000657 für den Wandler/Mengenumwerter in der NNA. |
19.01.2021
|
2021-00891 |
|
|
Sehr geehrte Damen und Herren,
der "Artikelnummernliste 4.1h" ist zu entnehmen, dass ab dem 01.04.2021 für die Abrechnung von "Wandlern / Mengenumwertern" im Zuge der Netznutzungsabrechnung (Prüfidentifikator "31002") die Artikelnummer 9990001000657 zu verwenden ist (bislang bzw. noch bis zum 31.03.2021 erfolgt die Abrechnung von "Wandlern / Mengenumwertern" in diesem Szenario hingegen mittels der Artikelnummer 9990001000798).
Ist unser Verständnis richtig, dass für die Verwendung der jeweiligen (= korrekten) Artikelnummer ausschließlich der Rechnungserstellungszeitpunkt - und eben NICHT der Leistungszeitraum der Rechnung - maßgeblich ist?
Zur Verdeutlichung ein einfaches Beispiel:
Am 05.04.2021 wird eine Netznutzungsrechnung mit dem Abrechnungszeitraum (= Leistungszeitraum) 20.03.2020 bis 20.03.2021 angefertigt; in dieser Abrechnung wird - aufgrund des Rechnungserstellungszeitpunktes (> 01.04.2021) -ausschließlich die "neue" Artikelnummer 9990001000657 kommuniziert.
Vielen Dank für eine Klarstellung / Ihre Unterstützung !
Freundliche Grüße
G. Deckenbrock
|
2021-01-19 13:51:31 |
Sehr geehrter Marktteilnehmer,
ab dem Erstellungszeitpunkt 1. April 2021 ist in der Rechnung für den Wandler/Mengenumwerter ausschließlich noch die Artikelnummer 9990001000657 zu nutzen.
Mit freundlichem Gruß
Ihr BDEW-Forum Datenformate |
Ja
|
Beate Becker |
Beate Becker |
Beate Becker |
Gero Deckenbrock |
Artikelnummernliste 4.1h |
Nein
|
|
Nein
|
Nein
|
|
INVOIC / REMADV AHB 2.4
|
Abgeschlossen
|
Besteht immer eine 1zu1 Beziehung zwischen REMADV und Überweisung ?
|
Ja, der Überweisungsbetrag muss zur REMADV passen. |
28.04.2021
|
2021-01002 |
|
|
Sehr geehrte Damen und Herren,
ist es zulässig, dass die Zahlungsbeträge mehrerer REMADV-Dateien mit negativen Betrag in einer Gesamtsumme überwiesen werden?
Im EDI@Energy INVOIC / REMADV Anwendungshandbuch (3. Ausprägungen von REMADV-Nachrichten; 5. Punktaufzählung; Seite 36) wird darauf verwiesen, dass der Überweisungsbetrag identisch mit der Summe aller in einer Zahlungs-REMADV enthaltenen Zahlbeträge sein muss.
Vielen Dank
|
2021-04-28 11:33:08 |
Sehr geehrter Fragesteller,
im INVOIC REMADV Anwendungshandbuch findet sich hierzu folgende Passage:
In Fällen, in denen sich im Rahmen der Verrechnung eine Rückerstattung ergibt, ist eine
REMADV (mit negativem Zahlbetrag) vom Lieferanten an den Netzbetreiber zu senden. Der
Netzbetreiber zahlt genau diesen Betrag an den Lieferanten aus. Der Überweisungsbetrag
muss identisch sein mit der Summe aller in einer Zahlungs-REMADV enthaltenen Zahlbeträge.
Auf der Überweisung wird immer eine Referenzierung zur REMADV mitgegeben: Die in der
REMADV angegebene Avisnummer aus dem BGM DE1004 wird im Verwendungszweck
angegeben, um eine eindeutige Zahlungszuordnung zu den in der REMADV genannten
Rechnungen zu gewährleisten. Dies gilt sowohl im Fall, dass der Summenbetrag der REMADV
positiv ist und somit die Überweisung vom LF an den NB erfolgt, als auch im Fall, dass der
Summenbetrag der REMADV negativ ist und somit die Überweisung vom NB an den LF erfolgt.
Um den administrativen Aufwand zur Erfassung und Buchung der Zahlungseingänge gering zu
halten, ist sicherzustellen, dass keine markt- bzw. messlokationsscharfen Überweisungen
erfolgen.
Somit lautet die Antwort auf Ihre Frage: Nein, es ist nicht zulässig, mehrere Zahlungsbeträge aus verschiedenen REMADV zusammenzufassen.
Freundliche Grüße,
Ihr BDEW-Forum Datenformate |
Ja
|
Klaus Keller |
Stefan Seidel |
Stefan Seidel |
Hermann Eisenreich |
EDI@Energy INVOIC / REMADV Anwendungshandbuch
Seite 36
3. Ausprägungen von REMADV-Nachrichten; 5. Punktaufzählung:
"In Fällen, in denen sich im Rahmen der Verrechnung eine Rückerstattung ergibt, ist eine
REMADV (mit negativem Zahlbetrag) vom Lieferanten an den Netzbetreiber zu senden. Der
Netzbetreiber zahlt genau diesen Betrag an den Lieferanten aus. Der Überweisungsbetrag
muss identisch sein mit der Summe aller in einer Zahlungs-REMADV enthaltenen Zahlbeträge." |
Nein
|
-------------Klaus Keller-------------11.05.2021 09:01
Vorschlag erstellt
|
Nein
|
Nein
|
|
INVOIC / REMADV AHB 2.4
|
Abgeschlossen
|
Reaktionsmöglichkeit auf fehlerhafte Umsatzsteuer-ID
|
Nichtzahlungsavis mit dem Abweichungsgrund 28 Sonstiges (erfordert Erläuterung im Segment FTX) |
01.04.2021
|
2021-00962 |
|
|
Sehr geehrte Damen und Herren,
In der Rolle Lieferant erhalten wir eine INVOIC-Nachricht, in welcher eine fehlerhafte Umsatzsteuer-ID hinterlegt wurde (SG3 RFF 1154).
Im Zuge des Jahresabschlusses bemängelt der Wirtschaftsprüfer es, wenn solche Rechnungen trotzdem gezahlt werden.
Allerdings gibt es unserer Ansicht nach keine Möglichkeit, eine solche Rechnung mit einer negativen REMADV abzulehnen.
Frage: Wie kann eine Rechnung mit einer fehlerhaften/abweichenden Umsatzsteuer-ID abgelehnt werden?
Vielen Dank im Voraus für Ihre Mühe und frohe Ostern!
Mit freundlichen Grüßen
Sebastian Weiße
|
2021-04-01 08:51:04 |
Sehr geehrter Herr Weiße,
eine derartige INVOIC-Nachricht können Sie mit einem Nichtzahlungsavis ablehnen, in dem sie darin den Abweichungsgrund 28 Sonstiges (erfordert Erläuterung im Segment FTX) nutzen und im FTX-Segment erläutern, dass die Umsatzsteuer-ID falsch ist. In diesem Segment könnten Sie sogar die richtige Umsatzsteuer-ID angeben, so dass der Rechnungssteller diesen String nur kopieren und in sein IT-System übernehmen muss.Unseres Erachtens handelt es sich in diesem Fall um eine fehlerhafte Eintragung der Umsatzsteuer-ID im Datensatz zu Ihrem Unternehmen im IT-System des Absenders, so dass dieser Fehler bei allen Rechnungen dieses Absenders an sie auftreten müsste. Somit wäre zu überlegen, ob eine direkte Kontaktaufnahme zum unverzüglichen Stopp aller Rechnungen an ihr Unternehmen bis zur Beseitigung des Fehlers in diesem Fall nicht die effizientere Lösung darstellt.
Freundliche Grüße,Ihr Forum Datenformate |
Ja
|
Klaus Keller |
Stefan Seidel |
Klaus Keller |
Sebastian Weiße |
Unser Vorschlag ist die Definition eines neuen Qualifiers in der REMADV. |
Nein
|
-------------Stefan Seidel-------------01.04.2021 09:33
Antwortvorschlag erstellt |
Nein
|
Nein
|
|
INVOIC / REMADV AHB 2.4
|
Abgeschlossen
|
Welche ORDERS ist gültig, wenn nacheinander mehrer QUOTES bestätigt wurden ?
|
Es kann immer nur eine gültige QUOTES/ORDERS-Kombination geben und zwar die Jüngste. |
03.02.2021
|
2021-00906 |
|
|
Hallo Team des Forums Datenformate,
wir als Netz- und Messstellenbetreiber haben zu einem Lieferanten eine unterschiedliche Auffassung bzgl. der zu hinterlegenden QUOTES Referenz in der folgenden INVOIC bei der Rechnungslegung einer modernen Messeinrichtung in einer separaten INVOIC.
Unser System hat zwei gleichlautende QUOTES mit unterschiedlichen Referenzen an den Lieferanten gesendet, welche beide per ORDERS bestätigt wurden.
Nun reklamiert der Lieferant die INVOIC da die zweite inhaltlich gleichlautende QUOTES softwareseitig zeitlich versetzt (ein paar Monate später) nach der initialen (unverzüglich nach QUOTES-Versand und ORDERS-Erhalt) an den Lieferanten gesendet wurde, welche ebenfalls per ORDERS bestätigt wurde.
Laut Auffassung des Lieferanten verlieren somit die initial inhaltlich gleichen QUOTES und ORDERS ihre Gültigkeit und der Lieferant verlang die Hinterlegung der Referenz aus der späteren QUOTES in der INVOIC. Bei uns wurde die Referenz der initialen QUOTES in der INVOIC angegeben.
Wir bitten um Klarstellung welche Referenz(en) sich der Lieferant zur Prüfung der INVOIC vorhalten muss.
Vielen Dank.
|
2021-02-03 12:28:49 |
Sehr geehrte Fragesteller,
wir teilen die Einschätzung des Lieferanten, nur die jüngste QUOTES, die er per ORDERS bestellt hat, in der Rechnungslegung zu akzeptieren. Eine Berücksichtigung des veralteten QUOTES, die ja eben durch den Versand eines neuen Angebotes ersetzt wurde, ist sinnlos.
Freundliche Grüße,
Ihr BDEW-Forum Datenformate |
Ja
|
Klaus Keller |
Stefan Seidel |
Stefan Seidel |
Andreas Bräuer |
|
Nein
|
-------------Klaus Keller-------------23.02.2021 13:06
Antworztvorschlag erstellt
|
Nein
|
Nein
|
|
INVOIC / REMADV AHB 2.4
|
Abgeschlossen
|
Gibt es eine Regel zur Fällgkeit von Stornorechnungen
|
Nein, aus Formatsicht sind keine Regeln zur Fälligkeit bei Stornorechnungen bekannt. |
02.11.2020
|
2020-00848 |
|
|
Sehr geehrte Damen und Herren,
im AHB ist für DTM+265 die Bedingung angegeben, dass die Fälligkeit von Rechnungen mit Betrag >= 0 mindestens 10 Werktage und <0 maximal 10 Werktage nach DTM+137 liegen muss. Wie verhält sich diese Bedingung bei Stornorechnungen? Muss bei einer Stornorechnung resultierend aus Storno einer Forderung (Stornorechnungsbetragsbetrag <0) ebenso die Bedingung aus DTM+265 angewendet werden, oder muss das Fälligkeitsdatum aus der Originalrechnung übernommen werden?
Mit freundlichen Grüßen
Hans-Christoph Schiemanck
|
2020-11-02 14:36:39 |
Hallo Herr Schiemanck,
an dieser Stelle sei auf die Antwort im alten FDF vom 29.09.15 verwiesen:
"...uns sind keine Regelungen für die Fällgikeit von Stornorechnungen bekannt...."
Die komplette Frage und Antwort finden Sie unter dem FDF-Link.
Freundliche Grüße,
Ihr Forum Datenformate |
Ja
|
Klaus Keller |
Stefan Seidel |
Stefan Seidel |
Hans-Christoph Schiemanck |
INVOIC / REMADV AHB 2.4 -> Bedingungen 20, 21, 24, 25 zu DTM+265, Seite 10 |
Nein
|
-------------Klaus Keller-------------11.11.2020 13:55
Antwortvorschlag nach Feedback Deckenbrock/Seidel erstellt
|
Nein
|
Nein
|
|
INVOIC / REMADV AHB 2.4
|
Abgeschlossen
|
Stehen die Datumsangaben "Beginn Bilanzieurung " und "Ende Netznutzung" im Verhältnis zueinander ?
|
Nein, sie können unabhängig voneinander angegeben werden je nach Erfordernis. |
27.10.2020
|
2020-00843 |
|
|
Inkonsistente Bezeichnung unter 2.1.3MMM-Rechnungen
In dem DTM Segment 2005 Abrechnungszeitraum gibt es sowohl die Prüfidentifikatoren 155 (Rechnungsperiode,Beginndatum)und 156(Rechnungsperiode,Endedatum) und das
DTM Segment 2005 Beginn Bilanzierung mit dem Prüfidentifikator Z11(Beginndatum Bilanzierung zugeordnete Periode)
sowie das DTM Segment 2005 Ende Netznutzung
mit dem Prüfidentifikator Z12 (Ende Netznutzung zugeordnete Periode)
Nach unserem Verständnis stehen die Identifikatoren Z11 und Z12 im Verhältnis sowie die Identifikatoren 155 und 156. Dennoch wird das Feld Z12 nicht als Endedatum Bilanzierung bezeichnet. Dies führt zu Inkonsistenzen in den Abgleichen und Ansichten diverser NB wofür dieser Identifikator Z12 steht. Wir bitten um Klarstellung.
Vielen Dank
F. Lambracht
|
2020-10-27 11:16:32 |
Hallo Herr Lambracht,
die beiden DTM-Segmente mit den Codes Z11 und Z12 können unabhängig voneinander angegeben werden, was jeweils durch die SOLL-Bedingungen [15] und [16] im AHB angegeben ist.
Freundliche Grüße,
Ihr BDEW-Forum Datenformate |
Ja
|
Klaus Keller |
Stefan Seidel |
Stefan Seidel |
Frederik Lambracht |
BDEWAnwendungshandbuchINVOIC / REMADV
2.1.3MMM-Rechnungen
Seite 22 / 23 DTM 2005 Segmente Identifikatoren 155 / 156 und Z11 / Z12
|
Nein
|
-------------Klaus Keller-------------30.10.2020 13:52
Antwortvorschlag erstellt
|
Nein
|
Nein
|
|
INVOIC / REMADV AHB 2.4
|
Abgeschlossen
|
Wo findet der PDF-Versand der Kapazitätsrechnung statt ?
|
Der PDF-Versand ist nicht Bestandteil der MaKo. |
21.08.2020
|
2020-00818 |
|
|
Sehr geehrte Damen und Herren,
Mit der Anwendungshilfe für Kapazitätsabrechnung wird darauf verwiesen, dass neben der INVOIC eine PDF mit den Detailinformationen versendet wird. Im AHB oder in den Regelungen zu Übertragungswegen kann ich dazu nichts finden. Daher gehen wir davon aus, dass dies außerhalb der MaKo vorgenommen wird nach bilateraler Absprache der Übertragung. Die Regelungen zu Übertragungswegen lassen nur einen Anhang zu und dieser muss EDIFACT oder Fahrplan sein.
mit der Bitte um Aufklärung
Jörg Gruchenberg
|
2020-08-21 12:05:23 |
Sehr geehrter Fragesteller,
der PDF-Versand erfolgt nicht über die 1zu1 MaKo-Adressen und ist somit ausserhalb der bestehenden MaKo-Vereinbarungen abzustimmen.
Freundliche Grüße,
Ihr BDEW-Forum Datenformate |
Ja
|
Klaus Keller |
Stefan Seidel |
Stefan Seidel |
Jörg Gruchenberg |
|
Nein
|
-------------Klaus Keller-------------07.09.2020 06:48
Antwortvorschlag erstellt
|
Nein
|
Nein
|
|
PlannedResourceScheduleDocument AWT 1.0
|
Eingegangen
|
Müssen RDA-Zeitreihen auch für Anlagen mit Sollwertanweisung übermittelt werden?
|
RDA-Zeitreihen müssen auch für Anlagen mit Sollwertanweisung übermittelt werden. |
15.04.2021
|
2021-00984 |
|
|
In der Anwendungstabelle steht (seit der Version vom 1.4.) die Fußnote [5], die sich auf alle Übermittlungen von Planungsdaten bezieht:
"[5] Für ein ResourceObject (SR, SG oder CR), welches im Fall einer RD-Maßnahme per Sollwert abgerufen wird, werden keine RDA-Zeitreihen (BusinessType = A46) übermittelt."
Das bedeute aber, dass man in diesem Fall (RD-Maßnahme mit Sollwert-Abruf) aus den Planungsdaten die Produktion ohne Redispatch-Abruf nicht mehr ermitteln kann: Bei einem abgestimmten Abruf mit Sollwert wird der Produktionwert auf diesen Sollwert angepasst und damit geht die Information über das"Delta" verloren, wenn sie nicht als Bestandteil der Planungsdaten (RDA) übermittelt wird.
Diese Fußnote [5] des AWT-Dokuments widerspricht auch der Tabelle "Abhängigkeitsmatrix" im FB-Dokument "PlannedResourceScheudleDocument FB 1.0": Dort steht nämlich in den Zeilen +RDA / -RDA als Erläuterung
"Deltawert (auch bei Sollwertvorgabe) einer abgestimmten RD-Maßnahme (Erhöhung um)"
Daher meine Frage: Ist mein Verständnis der Fußnote [5] richtig?
- Falls ja, wie kann man in diesem Fall die Produktion vor Redispatch, die z.B. für die Abrechnung relevant ist, aus den Planungsdaten ermitteln.
- Falls nein: Wie ist die Fußnote zu interpretieren?
|
2021-04-15 08:35:01 |
Sehr geehrter Herr Krönig,
vielen Dank für Ihre Fragen und Ihren damit verbundenen Hinweis.Die Fußnote [5] in der AWT muss gelöscht werden, die Erläuterung in der FB ist korrekt. Auch als Reaktion auf eine Sollwertanweisung muss eine Planungsdatenaktualisierung vom EIV übermittelt werden, in der die Werte der PROD-Zeitreihe für den Redispatch-Zeitraum der Sollwertanweisung entsprechen. Für die entsprechende korrespondierende positive oder negative RDA-Zeitreihe müssen durch den EIV die Deltawerte berechnet und eingetragen werden.
Der Fehler wird in der nächsten konsolidierten Lesefassung mit Fehlerkorrekturen korrigiert sein.
Freundliche Grüße
Ihr Forum Datenformate |
Ja
|
Stephan Schlunke |
Lucas Breuer |
Stephan Schlunke |
Arnd Krönig |
|
Nein
|
In PG XML besprochen. Für Fehlerkorrektur mitgenommen.
-------------Katia Schubert-------------22.04.2021 09:12
|
Nein
|
Nein
|
|
Entscheidungsbaum-Diagramme und Codelisten 1.0
|
Abgeschlossen
|
Wie wird bei einer Kündigung mit der Identifikationslogik MaLo-ID der Vertragspartner geprüft?
|
Der Vertragspartner wird bei einer Kündigung mit der Identifikationslogik MaLo-ID nicht geprüft |
01.04.2021
|
2021-00971 |
|
|
Vertragspartnerprüfung bei identifizierter Marktlokation:
Wie kann ich bei dem Prozess 6.1.1. (Kündigung Stromliefervertrag prüfen) bei einer im IT-System identifizierten Marktlokation die Richtigkeit des Vertragspartners prüfen? Oder anders formuliert; bei einer identifizierten Marktlokation springe ich automatisch zum Prüfungspunkt 9 - an welcher Stelle kann ich hier den Prüfungspunkt 5 vornehmen oder ist die Vertragspartnerprüfung in diesem Fall nicht vorgesehen?
Ohne Vertragspartnerprüfung bestände sonst die Gefahr, dass bei Angabe einer Marktlokation ein Kunde durch einen Dritten ungewollt gekündigt werden kann.
|
2021-04-01 16:50:35 |
Sehr geehrter Marktteilnehmer,
gemäß der Festlegung GPKE (Kapitel I 6. Identifiaktion einer Marktlokation) ist beschrieben, dass bei der Identifizeirung der Marktlokation allein über die Marktloaktions-ID zugeordnet wird. Somit ist die Überprüfung des Kundennamen/Vertragspartner nicht möglich, deshalb wird der Kundenname in diesem Fall auch nicht übermittelt.
Auszug aus der GPKE
...
b) Nutzt der Absender einer Nachricht zur Identifikation die MaLo-ID und gibt hierbei in den Use-Cases Lieferbeginn und Kündigung an, dass die Identifikation allein über die MaLo-ID zu erfolgen hat, so richtet sich die Identifikation allein nach der Frage, ob die betreffende MaLo-ID im System des Empfängers existiert. Weitere ebenfalls in der Nachricht übermittelte Stammdaten sind in diesem Fall nicht identifikationsrelevant.
...
Ihr BDEW Forum Datenformate |
Ja
|
Beate Becker |
Gregor Scholtyschik |
Beate Becker |
Cornelia Kaiser |
|
Nein
|
-------------Gregor Scholtyschik-------------16.04.2021 16:32
|
Nein
|
Nein
|
|
Entscheidungsbaum-Diagramme und Codelisten 1.0
|
In Bearbeitung
|
Wie ist mit Mehrfachkündigungen zu einem Termin umzugehen?
|
Die Kündigungen sind mit dem Antwortcode A06 zu beantworten |
03.03.2021
|
2021-00931 |
|
|
Im EBD GPKE 6.1 AD:Kündigung E_0400_Kündigung Stromliefervertrag prüfen, ist im Schritt 10 eine Zustimmung vorgesehen, wenn bereits zum angefragten Termin eine bestätigte Kündigung vorliegt.
Hier sind keinerlei Informationen, wie mit einer Mehrfachkündigung umgegangen wird. Der Kunde hat bereits gekündigt zum 31.12.2021, jetzt könnten zusätzlich 3 unterschiedliche Lieferanten bei uns zum 31.12.2021 kündigen und wir senden allen 3 Lieferaten eine A06 Zustimmung.
Dafür gab (im Gas gibt es sie noch) es doch die Ablehnung Mehrfachkündigung, wo angegeben wird, dass der Kunde oder ein anderer Lieferant zum angefragten Termin bereits gekündigt hat.
Es sollte doch nur der Lieferant eine Zustimmung zur Kündigung erhalten, der auch den Kunden tatsächlich dann beliefert.
Bis zur Klärung würdne wir hier statt wie im EBD eine Zustimmung A06 mit einer A99 Sonstiges mit dem Hinweis im Freitext auf Mehrfachkündigung ablehnen.
|
2021-03-03 12:23:01 |
Sehr geehrter Marktteilnehmer,
in dem von Ihnen geschilderten Fall erhalten alle drei Lieferanten den Antwortcode A06 "Vertrag wurde bereits zum angefragten Kündigungsdatum gekündigt". Welcher Lieferant oder ob der Endkunde den Vertrag eigenständig gekündigt hat, spielt im Prozess der Kündigung keine Rolle. Der Lieferant-Alt kann nicht entscheiden, welcher der neuen Lieferanten der Marktlokation zugeordnet wird, deshalb erhalten alle den Antwortcode A06. Die Zuordnung des LF an die Marktlokation trifft der Netzbetreiber.
Eine Ablehnung in dem von Ihnen geschilderten Fall mit dem Antwortcode A99 ist nicht korrekt.
Mit freundlichen Grüßen
Ihr BDEW Forum Datenformate |
Ja
|
Beate Becker |
Gregor Scholtyschik |
Gregor Scholtyschik |
Ramona Pantani |
EBD 1.0 Seite 23 (Antworten für Strom) und zum Vergleich EBD 1.0 Seite 240 (Antworten für Gas) |
Nein
|
|
Nein
|
Nein
|
|
Entscheidungsbaum-Diagramme und Codelisten 1.0
|
Eingegangen
|
Wie ist der Zeitraum des Lieferscheins und die Frage mit der lfd. Nr. 9 zu interpretieren?
|
Beschreibung des Zeitraums eines Lieferscheins und der Frage 9 |
02.03.2021
|
2021-00930 |
|
|
Frage 1: Was ist der Zeitraum des Lieferscheins?
Lieferscheine besitzen keinen Zeitraum auf der obersten Ebene der MSCONS-Nachricht, sondern lediglich Zeiträume in den einzelnen Positionen der Energiemengen. Was ist mit dem Zeitraum des Lieferscheins gemeint? Die größtmögliche Zeitspanne, die alle Zeiträume der Energiemengen umfasst? Was ist dann der Zeitraum des Lieferscheins, wenn Lücken zwischen den einzelnen Energiemengenpositionen bestehen?
Oder sind alle Zeiträume im Lieferschein separat zu prüfen? Dann sollte unseres Erachtens im Entscheidungsbaum zum Lieferschein von den Zeiträumen des Lieferscheins und nicht vom Zeitraum des Lieferscheins die Rede sein.
Frage 2: Wie ist Prüfschritt 9 zu verstehen?
Prüfschritt 5 lautet: Liegt in dem Lieferschein genannten Zeitraum mindestens ein Tag eines noch nicht stornierten Lieferscheins?
Prüfschritt 9 lautet: Liegt für den im Lieferschein genannten Zeitraum für eine der genannten OBIS-Kennzahlen eine zusätzliche Energiemenge vor, die noch nicht storniert wurde?
Beide Prüfschritte sind für Lieferscheine mit Grund-/Arbeitspreis relevant. Unter der Annahme, dass mit dem Zeitraum des Lieferschein jeder im Lieferschein unter den Energiemengen enthaltene Zeitraum gemeint ist, bedeutet dies dann, dass beide Prüfschritte dasselbe prüfen?
Oder ist im Prüfschritt 9 die Überschneidungen von Energiemengen zur selben OBIS-Kennzahl innerhalb des aktuell zu prüfenden Lieferscheins gemeint. Dann müsste dies anders formuliert werden.
|
2021-03-02 11:34:14 |
Sehr geehrter Marktteilnehmer,
vielen Dank für Ihre Fragestellungen, diese werden wie folgt beantwortet.
Antwort zur Frage 1:
Der Zeitraum des Lieferscheins vom Typ "Grund-/Arbeitspreis" ist das früheste Beginndatum (SG10 DTM+163 "Beginn Messperiode") bis zum spätesten Endedatum (SG10 DTM+164 "Ende Messperiode") aller Positionen in einer Nachricht.
Der NB hat die Energiemengen lückenlos im Lieferschein zu übermitteln.
Antwort zur Frage 2:
In der Frage 9 wird geprüft, ob zusätzliche Energiemengen für eine der genannten OBIS-Kennzahlen vom MSB der Marktlokation vorliegen. Mit dieser Prüfung soll sichergestellt werden, dass nur eine Energiemenge pro OBIS-Kennzahl für einen Zeitraum vom MSB der Marktlokation beim LF vorliegen.
Die Fragestellung wird in einer der nächsten Konsultationen präzisiert.
Freundliche Grüße
Ihre Forum Datenformate |
Ja
|
Beate Becker |
Gregor Scholtyschik |
Beate Becker |
Frank Buthe |
Entscheidungsbaum-Diagramme und Codelisten 1.0
Punkt 6.6.1
E_0456_Lieferschein prüfen |
Nein
|
Hinweise von der PG für Antwort eingefügt
-------------Beate Becker-------------24.06.2021 13:34
|
Nein
|
Nein
|
|
Entscheidungsbaum-Diagramme und Codelisten 1.0
|
Abgeschlossen
|
Wie ist mit fehlenden Fragen in einem EBD und dem nicht vorhandenen Ablehnungsgrund E14 - Ablehnung sonstiges umzugehen?
|
Der Antwortgrund "Ablehnung" ist für ein EBD befristet für ein Jahr möglich |
23.12.2020
|
2020-00877 |
|
|
Sehr geehrte Damen und Herren,
im Rahmen der Umsetzung zu den Datenaustauschformaten ab dem 01.04.2021 ist uns folgender Sachverhalt aufgefallen, den wir mit der Bitte um Klärung an Sie weiterleiten möchten.
Es handelt sich um die Ausgestaltung der Entscheidungsbaumdiagramme mit den Kürzeln E_0455 und E_0453.
Ab dem 01.04.2021 entfällt für den Versand einer UTILMD 11187 vom ÜNB an NB der Antwortstatus "E14 - Sonstiges". Prinzipiell begrüßen wir ausdrücklich eine Verringerung der Komplexität des Prozesses der Stammdatensynchronisation, dennoch stellt sich uns die Frage, wie es dem ÜNB in Zukunft möglich sein soll, gegenüber dem NB Unstimmigkeiten in den übermittelten Stammdaten mitzuteilen, die durch die o.g. EBD nicht abgedeckt sind?
Die Frage stellt sich insbesondere vor dem Hintergrund der Übermittlung von Stammdaten zu RLM-Marktlokationen mit dem Anwendungsfall der Stammdatensynchronisation.
Die Komplexität der Trennung von bilanzierungsrelevanten und nicht bilanzierungsrelevanten Stammdaten macht es erforderlich, dem Netzbetreiber möglichst detailliert Rückmeldung zur Verarbeitung seiner übermittelten Stammdaten zu geben. Die Möglichkeit dafür den Status der Antwort "Sonstiges" inkl. Freitextfeld zu benutzen, wäre in der Abwicklung der Prozesse eine enorme Hilfe.
Vielen Dank für Ihre Rückmeldung.
|
2020-12-23 14:37:17 |
Sehr geehrter Marktteilnehmer,
wir möchten Sie auf den Inhalt des Kapitels 3.2 des Dokuments "Entscheidungsbaum-Diagramme und Codelisten für die Antwortnachrichten" aufmerksam machen. In diesem ist beschrieben, dass fehlende und benötigte Fragen zu einem EBD per Änderungsantrag an den BDEW zu senden sind. Der Ablehnungsgrund mit dem Antwortgrund "Sonstiges" ist solange nutzbar, wie er in dem entsprechenden EBD genannt wird (bis zum 01.04.2021 00:00 Uhr mit dem Code "E14" angegeben, ab dem 01.04.2021 00:00 Uhr mit dem Antwortgrund A99 angegeben).
Hinweis: Das Formular zur Einreichung eines Änderungsantrages für ein EBD ist im Forum Datenformate unter Dokumente abrufbar.
Mit freundlichem Gruß
Ihr BDEW-Forum Datenformate |
Ja
|
Beate Becker |
Gregor Scholtyschik |
Beate Becker |
Maximilian Schulz |
|
Nein
|
Ich habe diese Aussage in den vorherigen Dokumenten nicht finden können. Hängen wir uns zu weit aus dem Fenster?
-------------Gregor Scholtyschik-------------28.12.2020 16:01
PG EBD: Antwort aktualisiert
-------------Beate Becker-------------16.04.2021 11:56
|
Nein
|
Nein
|
|
Entscheidungsbaum-Diagramme und Codelisten 1.0
|
Abgeschlossen
|
Sind die Fragen mit der laufenden Nummer 14 und 18 im EBD E_0455_Information prüfen identisch?
|
Nein, die Fragen sind nicht identisch. |
14.12.2020
|
2020-00870 |
|
|
Sehr geehrte Damen und Herren,
im EBD "E_0455_Information prüfen" sind u.a. zwei Prüfschritte definiert:
#14: Entspricht das Bilanzierungsverfahren dem gültigen Bilanzierungsverfahren zur Datenaggregation beim ÜNB?
#18: Ist das angegebene normierte Profil zum angegebenen Zeitpunkt ein Profil aus der Gruppe SLP mit synthetischen Verfahren?
Bislang haben wir für den alten Antwortstatus ZQ2 geprüft, ob eine ZP0-Meldung mit Aggregationsverantwortung durch den ÜNB in Kombination mit dem SG10 CCI+Z02++Z10' auftritt. In diesem Falle (also analytisches Verfahren) haben wir eine Ablehnung versendet.
Diese Logik entspricht aus unserer Sicht dem neuen Prüfschritt #18. Welche Konstellation soll in Prüfschritt #14 geprüft werden, die nicht fachlich redundant zu #18 ist?
Mit besten Grüßen
André Strafehl
|
2020-12-14 16:37:31 |
Sehr geehrter Marktteilnehmer,
in der Frage 14 wird die folgende Konstellation in dem Geschäftsvorfall geprüft:
Die Angabe der Prognosegrundlage der Marktlokation mit dem Code ZA6 "Prognose auf Basis von Profilen" darf nicht zusammen mit der Angabe des Codes E14 "TLP/TEP" in dem CAV-Segment "Details der Prognosegrundlage" erfolgen.
In der Frage 18 wird geprüft, ob das in dem Geschäftsvorfall angegebene Profil in der vom Netzbetreiber übermittelten Profildefinition der Gruppe SLP synthetisches Verfahren zugeordnet ist.
Ein analytischer Netzbetreiber muss im Rahmen der Datenaggregation beim ÜNB ebenfalls synthetische Profile bereitstellen.
Mit freundlichem Gruß
Ihr BDEW-Forum Datenformate |
Ja
|
Beate Becker |
Gregor Scholtyschik |
Beate Becker |
André Strafehl |
Dokument Entscheidungsbaumdiagramme und Codelisten S. 96/97 Prüfungen #14 und #18 |
Nein
|
|
Nein
|
Nein
|
|
Anwendungsübersicht der Prüfidentifikatoren - informatorische Lesefassung 1.0a
|
Abgeschlossen
|
Wie erfolgt die außerplanmäßige Anforderung eines Messwertes?
|
Die außerplanmäßige Anforderung eines Messwertes erfolgt per ORDERS, der der PID 17004 zugeordnet ist. |
22.03.2021
|
2021-00949 |
|
|
Hallo zusammen, in Ticket 2020-00644 teilen Sie bereits folgende Situation mit: "liegt die Situation beim NB, LF oder ÜNB vor, dass er unplausible oder fehlende Werte hat, sind diese über den Use-Case „Reklamation von Werten“ beim MSB zu reklamieren.".
Ein wMSB vertritt hier die Meinung, dass wir als VNB für eine außerplanmäßige Anforderung eines Messwertes (z.B. Zwischenablesung 30.06.2020 aufgrund Umsatzsteuerabgrenzung) immer zuerst eine ORDERS 17004 (Messwertanforderung) senden müssen. Erst wenn diese nicht bearbeitet bzw. beantwortet wurde, darf der fehlende fehlende Wert per ORDERS 17113 (Messwertreklamation) reklamiert werden.
Wir bitten um eine zeitnahe klärende Rückmeldung.
Freundliche Grüße
Marc Schmidt
|
2021-03-22 14:12:56 |
Sehr geehrter Forumsteilnehmer,
die außerplanmäßige Anforderung eines Messwertes erfolgt per ORDERS, der der PID 17004 zugeordnet ist.
Freundliche Grüße,
Ihr Forum Datenformate |
Ja
|
Holger Kampmann |
Thomas Fellhauer |
Holger Kampmann |
Marc Schmidt |
|
Nein
|
|
Nein
|
Nein
|
|
Anwendungsübersicht der Prüfidentifikatoren - informatorische Lesefassung 1.0a
|
Abgeschlossen
|
Reklamation oder Geschäftsdatenanfrage?
|
Fehlende Werte sind in der Sparte Strom per Reklamation nachzufordern. |
07.01.2021
|
2021-00882 |
|
|
Ich habe eine Frage zu den unterschiedlichen ORDERS-Nachrichten, mit denen man Messwerte anfragen, anfordern, bzw. reklamieren kann. Im Speziellen die PI's 17102 und 17113 und die Sparte Strom.
Es kommt relativ häufig vor, das Marktpartner (LF oder NB) mit einer Meldung 17102 und z.B. IMD=Z12 Zählerstände anfragen.
Mir ist nicht klar, wie mit solchen Meldungen zu verfahren ist, vor allem im Hinblick auf den Hinweis im Use-Case "Geschäftsdatenanfrage", dass der Prozess "Geschäftsdatenanfrage" nicht für fehlende oder unplausible Werte zu nutzen ist.
Können Sie mir sagen, in welchen Fällen eine ORDERS 17102 mit BGM=7 Prozessdatenbericht (d.h. IMD Z11 Lastgangdaten, Z12 Zählerstände) gerechtfertigt ist, bzw. genutzt werden darf und kann. Vor allem in Abgrenzung zur ORDERS Meldung 17113 (Prozess Reklamation von Werten).
Wie soll ein Empfänger erkennen, das eine ORDERS 17102 gerechtfertigt ist oder eben nicht, sondern die 17113 hätte benutzen werden müssen?
Wenn eine 17102 nicht gerechtfertigt ist, mit welcher Meldung, bzw. mit welchem Grund kann dann abgelehnt werden?
|
2021-01-07 13:24:03 |
Sehr geehrter Forumsteilnehmer,
in der GPKE ist festgelegt, dass fehlende Werte über die "Reklamation von Werten" zu reklamieren sind und dafür nicht die Geschäftsdatenanfrage zu nutzen ist: "liegt die Situation beim NB, LF oder ÜNB vor, dass er unplausible oder fehlende Werte hat, sind diese über den Use-Case „Reklamation von Werten“ beim MSB zu reklamieren. Hierzu darf nicht die Geschäftsdatenanfrage verwendet werden, da diese nicht sicherstellt, dass im Markt ein einheitlicher Wertestand vorliegt."
Demzufolge sind in der Sparte Strom fehlende Werte über den Anwendungsfall, dem der PID 17113 zugeordnet ist, zu reklamieren. Für die Sparte Gas wird die Geschäftsdatenanfrage zur Nachforderung fehlender Werte genutzt.
Freundliche Grüße,
Ihr Forum Datenformate |
Ja
|
Holger Kampmann |
Thomas Fellhauer |
Holger Kampmann |
Lars Vogel |
|
Nein
|
|
Nein
|
Nein
|
|
Anwendungsübersicht der Prüfidentifikatoren - informatorische Lesefassung 1.0a
|
Abgeschlossen
|
Wie erfolgt die Angabe der Zeitspanne zur Anfrage von Lastgangdaten in der ORDERS?
|
Zeitspannen (Beginndatum und Endedatum) in der ORDERS und MSCONS sollen identisch sein |
16.11.2020
|
2020-00855 |
|
|
Kurzfrage:
ORDERS Lastganganforderung an MSB welcher 1/4-Std. Wert wird als erster Wert versendet?
Frage:
Sehr geehrte Damen und Herren,
wir als wMSB erhalten im Zuge der Lastgangnachforderung ORDERS-Nachrichten, die bei der Zeitspanne für die angeforderten Werte oft wie folgt aussehen:
01.11.2020 00:00 Uhr - 02.11.2020 00:00 Uhr
Angefragt wird Lastgang von 01.11.2020 00:00 bis 02.11.2020 00:00
Wir versenden 97 Werte.
Den letzten 1/4-Std. Wert vom 31.10.2020 23:45 bis 01.11.2020 00:00 der als Zeitstempel 01.11.2020 00:00 hat und weitere 96 Werte vom 01.11.2020 00:15 bis 02.11.2020 00:00
Grundlage: MSCONS AHB
4.1.1 Übertragung von Lastgängen Strom
Tabellenspalte = Messwert Lastgang (Strom) 13018
In der Sparte Strom werden zur Energiemengenübermittlung ¼ Std.-Lastgänge (Messperiode 15 min) ausgetauscht. Der erste Wert ist 00:15 Uhr (dem Intervall 00:00 bis 00:15 Uhr) zugeordnet. Außer an Tagen mit Zeitumschaltung liegen grundsätzlich 96 Werte, an Tagen der Zeitumschaltung Sommer-Winter 100 Werte und bei der Umschaltung Winter-Sommer 92 Werte vor.
Die Marktpartner beschweren sich und erwarten 96 Werte vom 01.11.2020 00:15 bis 02.11.2020 00:00
Unsere Argumentation: die Zeitspanne in der ORDERS-Anfrage soll korrekt nach MSCONS AHB definiert werden Also: 01.11.2020 00:15 bis 02.11.2020 00:00
Wir bitten um eine Stellungnahme ob unsere Vorgehensweise korrekt ist.
Desweiteren werden manchmal auch folgende Zeitspannen angefragt: 01.10.2020 00:00 Uhr - 31.10.2020 23:59 Uhr
Wie sollen wir mit so was umgehen?
Im Voraus vielen Dank!
|
2020-11-16 12:38:18 |
Sehr geehrte Damen und Herren,
die Zeitspannen (Beginndatum und Endedatum) in der ORDERS und MSCONS sollen identisch sein. In ihrem Beispiel ist der erste Wert dann vom in der ORDERS angegebenen Beginndatum 01.11.2020, 00:00 Uhr bis 01.11.2020, 00:15 Uhr.
Freundliche Grüße,
Ihr Forum Datenformate |
Ja
|
Holger Kampmann |
Thomas Fellhauer |
Holger Kampmann |
Steffen Schwarz |
|
Nein
|
|
Nein
|
Nein
|
|
Anwendungsübersicht der Prüfidentifikatoren - informatorische Lesefassung 1.0a
|
Abgeschlossen
|
Wie können in der Sparte Gas fehlende Lastgangdaten nachgefordert werden?
|
In der Sparte Gas werden fehlende Lastgangdaten über die Geschäftsdatenanfrage nachgefordert. |
14.05.2020
|
2020-00757 |
|
|
Der ORDERS-Prozess 17113 "Reklamation von Werten" kommt zum Einsatz, wenn Lastgangwerte in der Sparte Strom fehlen. Wir hatten vor, den analogen Prozess auch für Gas zu nutzen. Leider werden die Nachrichten vom Marktpartner abgelehnt, da FTX+Z06 für Gas nicht gültig ist. Der Sachstand ist aber der, dass uns für einzelne Marktlokationen Gas vom NB keine Werte geschickt wurden und wir diese anfragen möchten. Gehen wir recht in der Annahme, dass für Gas und bei fehlenden Werten eine normale GDA PID 17102 zum Einsatz kommt und eben nicht die PID 17113?
|
2020-05-14 13:58:46 |
Sehr geehrter Forumsteilnehmer,
ihre Annahme ist richtig. In der Sparte Gas werden fehlende Lastgangdaten über eine Geschäftsdatenanfrage nachgefordert.
Freundliche Grüße,
Ihr Forum Datenformate |
Ja
|
Holger Kampmann |
Thomas Fellhauer |
Holger Kampmann |
Andreas Poetschk |
Fakt ist, dass der Qualifier FTX+Z06 (für fehlende Werte) nur für Strom gilt (S.47). Wenn man sich die „Allgemeinen Festlegungen“ (Seite 25 Beispiel 4) anschaut, ist es auch nicht als „KANN“-Feld für Gas zu interpretieren. Das wird verstärkt durch die verbandsübergreifende „Anwendungshilfe Wechselprozesse im Messwesen“ für die Sparte Gas“ vom 27.09.2017, mit Gültigkeit zum 01.10.2017. Für den Use-Case „Reklamation von Lastgängen“ gilt folgendes Zitat: „Die Reklamation erfolgt ausschließlich auf wahre Messwerte und Ersatzwerte“. D.h. der Prozess gilt nicht für fehlende Werte.
|
Nein
|
|
Nein
|
Nein
|
|
PRICAT AHB 1.0b
|
Abgeschlossen
|
Unter welcher Artikelnummer wird ein Rundsteuergerät angegeben?
|
Das Rundsteuergerät kann unter der Artikelnummer 9990001000839 angegeben werden |
24.02.2021
|
2021-00924 |
|
|
Hallo Zusammen,
wo kann das Rundsteuergerät (ungleich Steuergerät für IMSYS) das bei MME verwendet wird im PRICAT ausgewiesen werden? Es geht um die Zusatzleistungen gemäß § 35 Abs. 2 MSBG.
Wie im AHB beschrieben, kann es ja nicht sein, da dies wohl das Steuergerät für IMSYS betrifft. Und beide Arten der
Steuergeräte für MME und IMSYS bestimmt unterschiedliche Preise haben werden.
Und wo bzw. wie können weitere Zusatzleistungen die man erbringt mit in der PRICAT berücksichtigen? Es könnten ja mehr als 5 sein.
Gruß und Danke
|
2021-02-24 10:01:59 |
Sehr geehrter Fragesteller,
Das Steuergerät zur Schaltung von Tarifschaltzeiten (Rundsteuergerät) kann mit der Kombination der Artikelnummer 9990001000839 „Zusatzdienstleistung nach § 35 Abs. 2 Nr. 3 MsbG“ und dem Qualifier Z41 „Zusatzleistung“ im SG36 IMD angegeben werden.
Es können auch unterschiedliche Positionen zur selben Artikelnummer in der PRICAT angegeben werden, solange der dazugehörige Preisschlüsselstamm eindeutig ist. D.h., Steuergeräte zur Schaltung von Tarifschaltzeiten und die Steuerbox zur Fernsteuerbarkeit beim Einsatz von intelligenten Messsystemen können die selbe Artikelnummer nutzen, wenn verschiedene Preisschlüsselstämme genutzt werden. Preisschlüsselstamm und Preis haben immer eine 1:1 Beziehung.
Bitte beachten Sie hierzu auch die Anwendungshilfe „Einführungsszenario: Neue Artikelnummern zum 1. April 2021 in der PRICAT"
Mit freundlichen GrüßenIhr Forum Datenformate |
Ja
|
Thomas Seipt |
Klaus Keller |
Thomas Seipt |
Michael Hoffmann |
PRICAT Seite 9:
Der Z27 Steuergerät wird
ersetzt durch die Kombination
der Artikelnummer
9990001000839
Zusatzdienstleistung nach § 35
Abs. 2 Nr. 3 MsbG und dem
Qualifier Z41 Zusatzleistung |
Nein
|
Vorschlag für Klaus
-------------Thomas Seipt-------------12.03.2021 14:34
|
Nein
|
Nein
|
|
PRICAT MIG 1.1a
|
Abgeschlossen
|
Unter welcher Artikelnummer wird ein Rundsteuergerät angegeben?
|
Das Rundsteuergerät kann unter der Artikelnummer 9990001000839 angegeben werden |
24.02.2021
|
2021-00923 |
|
|
Guten Tag,
es geht um die Formatanpassung bei der PRICAT zum 01.04.2021.
Zusatzdienstleistungen nach § 35 Abs. 2 müssen differenziert in der PRICAT angegeben werden.
Es können maximal die Leistungen 1 bis 5 angegeben werden.
Wo kann ein Rundsteuergerät zu einer MME preislich hinterlegt werden?
Wir würden es unter Nr. 4 "und sonstige Auftragsdienstleistungen" zuordnen.
Was ist wenn mehr Zusatzleistungen angeboten werden?
Im Voraus recht vielen Dank.
|
2021-02-24 09:45:51 |
Sehr geehrter Fragesteller,
Das Steuergerät zur Schaltung von Tarifschaltzeiten (Rundsteuergerät) kann mit der Kombination der Artikelnummer 9990001000839 „Zusatzdienstleistung nach § 35 Abs. 2 Nr. 3 MsbG“ und dem Qualifier Z41 „Zusatzleistung“ im SG36 IMD angegeben werden.
Es können auch unterschiedliche Positionen zur selben Artikelnummer in der PRICAT angegeben werden, solange der dazugehörige Preisschlüsselstamm eindeutig ist.
Bitte beachten Sie hierzu auch die Anwendungshilfe „Einführungsszenario: Neue Artikelnummern zum 1. April 2021 in der PRICAT".
Mit freundlichen Grüßen
Ihr Forum Datenformate |
Ja
|
Thomas Seipt |
Klaus Keller |
Thomas Seipt |
Michael Hoffmann |
|
Nein
|
Vorschlag zur Antwort
-------------Thomas Seipt-------------12.03.2021 13:37
|
Nein
|
Nein
|
|
PRICAT MIG 1.1a
|
Abgeschlossen
|
Müssen die Preisschlüsselstämmen eindeutig sein?
|
Preisschlüsselstämme müssen eindeutig sein. |
17.03.2020
|
2020-00707 |
|
|
Sehr geehrte Damen und Herren,
wir haben eine PRICAT erhalten, die mit unterschiedlichen Preisschlüsselstämmen versendet wurde, in beiden jedoch derselbe Produkt/Leistungscode übermittelt wurde (in unserem Fall Z25). Beide enthielten auch exakt denselben Preis.
Dies ist rein vom Format her zugelassen. Wir können hier jedoch keinen Sinn erkennen. Hier setzt unsere Frage an:
Gibt es einen Grund, dass solche Dateien verschickt werden und wenn ja, wie soll man beide Zweige unterscheiden können? Wenn so etwas nicht verschickt werden soll, kann dann im Rahmen der Weiterentwicklung der Formate hier eine Regelung implementiert werden, die dies verhindert?
Vielen Dank für Ihre Mühe.
Mit freundlichen Grüßen
Sebastian Weiße
|
2020-03-17 16:42:25 |
Hallo,
in WiM Kapitel 10.2 steht: "Mit einem Preisschlüsselstamm wird die abzurechnende Leistung sachgerecht und eindeutig dargestellt, dabei referenziert dieser immer auf eine BDEW-Artikelnummer. Die Eindeutigkeit wird durch eine Beschreibung anhand fachlicher und technischer Informationen im Preisblatt erreicht.".
D.h., dass der Absender der PRICAT für eine Eindeutigkeit aller Preise verantwortlich ist. Eine Prüfung der PRICAT auf Eindeutigkeit ist zur Zeit nicht vorgesehen.
Mit freundlichen GrüßenIhr Forum Datenformate
|
Ja
|
Thomas Seipt |
Klaus Keller |
Thomas Seipt |
Sebastian Weiße |
|
Nein
|
Vorschlag
-------------Thomas Seipt-------------18.03.2020 16:42
|
Nein
|
Nein
|
|
APERAK / CONTRL AHB 2.3f
|
Abgeschlossen
|
Darf das Datum der Erstellung einer Übertragungsdatei im Rahmen der Syntaxprüfung geprüft werden?
|
Jedes Datum, dass lt. gültigem Kalender möglich ist bzw. war, ist in der Syntaxprüfung zu akzeptieren. |
06.10.2020
|
2020-00833 |
|
|
Guten Tag,
darf eine Übertragungsdatei mittels negativer CONTRL und dem Fehlerstatus 12 (ungültiger Wert) angelehnt werden, wenn das Datum der Dateierstellung nicht dem Tagesdatum entspricht bzw. mehr als einen Tag in der Vergangenheit liegt aber dennoch ein valides Datum ist.
Wenn ja, wie groß darf die maximale Zeitspanne zwischen Erstellung und Empfang sein?
VG Ronald Damm
|
2020-10-06 20:23:18 |
Sehr geehrter Herr Damm,
selbstverständlich ist eine Übertragungsdatei mit einem Datum, das es auf Basis des für Deutschland gültigen Kalenders geben kann, syntaktisch richtig. In dem von Ihnen beschrieben Fall erfolgt im Rahmen der vorgenommenen Syntaxprüfung allerdings eine fachliche Prüfung, ob eine Übertragungsdatei, am gleichen Tag erzeugt wurde, zu dem diese empfangen wurde. Die Vorgabe „wie alt“ eine Übertragungsdatei maximal sein darf, ergibt sich – wenn überhaupt – aus prozessualen Vorgaben. Die Einhaltung prozessualer Vorgaben erfolgt nicht im Rahmen der Syntaxprüfung.Somit ist in dem von Ihnen geschilderten Fall keine Syntaxfehlermeldung zu senden, sondern der Empfang der Übertragungsdatei ist durch eine Empfangsbestätigung, die in Form eine CONTRL versandt wird, zu bestätigen, so die Übertragungsdatei keine Syntaxfehler enthält, wovon wir an dieser Stelle ausgegangen sind.
Freundliche Grüße,Ihr BDEW Forum Datenformate |
Ja
|
Klaus Keller |
Stefan Seidel |
Stefan Seidel |
Ronald Damm |
|
Nein
|
-------------Stefan Seidel-------------06.10.2020 21:07
Antwortvorschlag erstellt
-------------Klaus Keller-------------08.10.2020 11:09
Antwort ergänzt bzw. teilweise korrigiert
-------------Stefan Seidel-------------09.10.2020 08:06
veröffentlichz |
Nein
|
Nein
|
|
APERAK / CONTRL AHB 2.3f
|
Abgeschlossen
|
Ist die Reihenfolge der Segmente in den Anwendungshandbüchern verbindlich einzuhalten?
|
Nein, sofern die EDIFACT-Struktur der Nachrichtenbeschreibung eingehalten wird, ist die Reihenfolge der Segmente beliebig. |
13.12.2019
|
2019-00598 |
|
|
Sehr geehrtes Forum Datenformate,
ein Marktpartner sendet nach meiner Einschätzung unberechtigte Syntaxfehlermeldungen per CONTRL mit folgender Begründung:
<...>
"es sich hier um einen Strukturfehler handelt. Laut Anwendungshandbuch UTILMD zu den Stammdatenänderungsprozessen auf Seite 130/131 folgt auf die CAV+Z88 die CAV+Z89 die CAV+Z90 und erst dann CAV+Z91. Sie senden dies aber in einer anderen Reihenfolge wie im Anwendungshandbuch angegeben, bei Ihnen kommt nach CAV+Z89 die CAV+Z91 und dann erst die CAV+Z90.
CAV+Z88:9901064000005'
CAV+Z89:9904489000006'
CAV+Z91:9906311000005'
CAV+Z90:4045399000077'
"
Nach meiner Einschätzung ist die Reihenfolge der Segmente in den Anwendungshandbüchern nicht verbindlich, da die Bedeutung eines Segmentes nicht aufgrund der Position in der Nachricht, sondern anhand des verwendeten Qualifiers erkennbar ist.
Selbstverständlich müssen die Vorgaben der Segmentstruktur eingehalten werden, eine Reihenfolge auf gleicher Ebene in der Nachrichtenstruktur ist jedoch nicht festgelegt.
Freundliche Grüße,
Klaus Keller
|
2019-12-13 16:21:24 |
Hallo Herr Keller,
Sie haben Recht, ein grundsätzlicher Vorteil der EDIFACT-Syntax ist die Verwendung von Codes und Qualifiern zur Übertragung strukturierter Daten. Natürlich muss der Aufbau einer Nachricht der Nachrichtenbeschreibung entsprechen, eine Vorgabe aus den Anwendungshandbüchern zur strikten Einhaltung der zufällig gewählten Segmentreihenfolge ergibt sich nicht.
Die Reihenfolge der Segmente in den Anwendungshandbüchern ergibt sich aus der Reihenfolge, wie diese in der zugrundeliegenden Nachrichtenbeschreibung vorkommen. Die Nachrichtenbeschreibungen sind in der sogenannten expliziten Darstellung verfasst. Um die grundlegende EDIFACT-Regel zu verdeutlichen, dass die Reihenfolge von Segmenten und Segmentgruppen keine Information trägt, sondern jede Information ausschließlich mittels Codes zu notieren ist, ist in den Allgemeinen Festlegung u. a. folgende Aussage enthalten:
"Aufgrund der expliziten Notation werden einzelne Segmente mit unterschiedlichen Ausprägungen auf Datenelement- und Datenelementgruppenebene mehrfach aufgeführt. Die hierfür verwendete Reihenfolge ist beliebig und lediglich dem Umstand geschuldet, dass nur seriell dokumentieren werden kann."
Bestes Beispiel hier dürfte die beliebige Reihenfolge von NAD+MS und NAD+MR zur Angabe von Absender und Empfänger sein. Die Bedeutung ist lediglich an dem verwendeten Qualifier erkennbar, NAD+MR darf also auch zuerst in einer Nachricht gefüllt sein. Um dies zu verdeutlichen, ist es beispielsweise in den IFTSTA-Dokumenten immer NAD+MR vor NAD+MS genannt.
Freundliche Grüße,
Ihr BDEW-Forum Datenformate |
Ja
|
Klaus Keller |
Stefan Seidel |
Stefan Seidel |
Klaus Keller |
|
Nein
|
-------------Klaus Keller-------------13.12.2019 16:24
Frage & Antwortvorschlag erstellt nach telefonischer Abstimmung mit Holger Weickenmeier
-------------Stefan Seidel-------------15.12.2019 21:12
noch ergänzt und Fazitsatz mit zu löschenden Aussagen gefüllt :-)
-------------Klaus Keller-------------16.12.2019 08:52
Fazit entfernt und Veröffentlichung durchgeführt
|
Nein
|
Nein
|
|
UTILMD AHB Stammdatenänderung 1.1a
|
In Bearbeitung
|
Wird durch eine Änderung der Korrespondenzanschrift auch der Kundenname geändert?
|
Wenn ein Stammdatum geändert werden soll, so ist dies auch mitzuteilen. Eine Ableitung zu einer Veränderung ist nicht beschrieben |
09.09.2020
|
2020-00823 |
|
|
Wir als Netzbetreiber haben einen Disput mit einigen Lieferanten.
Problembeschreibung:
Der Lieferant möchte den Namen des Kunden, als auch die Korrespondenzanschrift des Kunden, ändern.
Der Name des Kunden ist in dem NAD+Z09 „Kunde des Lieferanten“,
die Korrespondenzanschrift ist in dem NAD+Z04 „Korrespondenzanschrift des Kunden des Lieferanten“,
enthalten.
Im NAD+Z09 ist lediglich der Name Inhalt des Segments. Das NAD+Z04 besteht aus Name und Adresse.
Wir erhalten nun eine Stammdatenänderung mit dem PID 11109 / Transaktionsgrund ZE6. (Nicht bila. Rel. Änderung vom LF „LF an NB [Verteiler])
In diesem Anwendungsfall sendet der LF lediglich das NAD+Z04 (Korrespondenzanschrift). Das NAD+Z09 ist nicht enthalten.
Von Seiten der Lieferanten wird nur reklamiert, dass wir als NB den Kundennamen nicht übernommen hätten. Diese gehen vehement davon aus, dass eine Änderung des Namens in der Korrespondenzanschrift auch eine Änderung des Kundennamens, welcher in NAD+Z04 ausgetauscht wird, auslösen würde.
Wir gehen davon aus, dass eine Änderung des Kundennamens nicht aus einer Änderung der Korrespondenzanschrift hervorgeht.
Ist unsere Ansicht korrekt?
|
2020-09-09 16:43:17 |
Sehr geehrter Marktteilnehmer,
wenn ein Stammdatum verändert werden soll, so muss dies auch mitgeteilt werden.
Eine Änderung des Kundenamens, welcher in SG12 NAD+Z09 „Kunde des Lieferanten“ ausgetauscht wird, kann nicht durch eine Stammdatenänderung der Inhalte des SG12 NAD+Z04 „Korrespondenzanschrift des Kunden des Lieferanten“ abgeleitet werden.
Wäre dies der Fall, so wäre eine Namensangabe in einem NAD redundant.
In dem SG12 NAD+Z04 wurde vor einiger Zeit, neben der Adresse auch der Name mit aufgenommen. Dies wurde von den damaligen Antragsstellern damit begründet, dass die Kommunikation nicht immer an den Kunden selbst gehen muss. Beispiele waren hier Vormundschaft oder Abrechnungsunternehmen, an welche die Korrespondenz zugestellt werden soll.
Eine Ableitung, dass sich mit dem Namen, welcher in der Korrespondenzanschrift übermittelt wird, auch den Kundennamen ändert, ist nicht vorhanden und wäre auch falsch.
Wenn der LF, für die von Ihnen beschriebene Intension, den Kundennamen und die Korrespondenzanschrift ändern möchte, so sind auch die Änderungen in den entsprechenden SG12 NAD zu kommunizieren.
Nähere Erläuterungen, für welche Verwendung die Inhalte in den beiden hier genannten Segmente zu Grunde liegen, ist in der Nachrichtenbeschreibung (MIG) in den entsprechenden Segmenten beschrieben.
Wir hoffen Ihnen hierbei weitergeholfen zu haben.
Ihre PG EDI@Energy |
Ja
|
Holger Weickenmeier |
Joachim Schlegel |
Holger Weickenmeier |
Holger Weickenmeier |
|
Nein
|
Die Frage ist von uns (NB). Darum bitte genau prüfen.
-------------Holger Weickenmeier-------------10.09.2020 09:13
|
Nein
|
Nein
|
|
UTILMD AHB Stammdatenänderung 1.1a
|
Abgeschlossen
|
Wie / Wann ist der Codes ZP0 in der Stammdatensynchronisation zu verwenden?
|
Der Codes ZP0 im PID 11185 "Stammdatensynchronisation" ist ausschließlich bei dem Übergang der Aggregationsverantwortung zum ÜNB zu verwenden. |
27.08.2020
|
2020-00819 |
|
|
Hallo,
wir diskutieren mit mehreren Marktpartnern folgende Problematik:
In der Stammdatensynchronisation erhalten wir als LF von einigen NB mit dem PID 11185 "immer" als erste Stammdatensynchronisation nach einem Lieferbeginn diese mit den Transaktionsgrund Code ZP0 (Stammdatensynchronisation Beginn der Aggregationsverantwortung).
Aufgrund des Hinweises [613] "Der Code wird verwendet um die Aggregationsverantwortung einer Marktlokation auf den ÜNB zu übertragen" am Code ZP0 interpretieren wir diesen Code so, dass dieser ausschließlich nach dem Prozess GPKE (MaKo2020) Kap. III 2. "Information über die Zuordnung einer Marktlokation zur Datenaggregation durch den ÜNB" Anwendung findet. Die Verwendung des Codes ZP0 hat fachlich nichts mit dem Prozess Lieferbeginn zu tun.
Aus unserer Sicht ist dieser ausschließlich bei der ersten Übertragung der Aggregationsverantwortung vom NB auf den ÜNB zu verwenden.
Ist unsere Interpretation korrekt?
|
2020-08-27 15:21:12 |
Sehr geehrter Marktteilnehmer,
wie Sie korrekt erläutert haben und in dem Hinweis [613] entnehmen können, wird der Code ZP0 ausschließlich zur Übertragung der Aggregationsverantwortung vom NB zum ÜNB verwendet. Durch die Verwendung des Codes ZP0 wird der ÜNB informiert, dass die Verantwortung der Aggregation auf den ÜNB übergeht und dieser ggf. die MaLo anlegen, bzw. wenn aus anderen Gründen (Bilanzkreistreue) die MaLo schon bekannt ist, diese ergäzen muss. Die Bedeutung des ZP0 hat richtigerweise nichts mit einem Lieferbeginn zu tun.Eine anderweitige Verwendung des Codes ZP0 ist nicht vorgesehen.
Ihre PG EDI@Energy |
Ja
|
Holger Weickenmeier |
Joachim Schlegel |
Holger Weickenmeier |
Holger Weickenmeier |
|
Nein
|
Die Frage hatte ich eingereicht. Wir haben dieses Problem mit x NBs.
Grüße Holger
-------------Holger Weickenmeier-------------27.08.2020 15:21
|
Nein
|
Nein
|
|
REMADV MIG 2.8
|
Abgeschlossen
|
Sollte BGM DE 1004 eindeutig sein ?
|
Ja, ansonsten ist die Identifikation einer EDIFACT-Nachricht nicht möglich. |
10.08.2020
|
2020-00807 |
|
|
Sehr geehrte Damen und Herren,
aufgrund einer aktuellen Situation möchten wir Sie um Rückmeldung bitten bzgl. Eindeutigkeit Dokumentennummer BGM 1004.
Muss der Inhalt bei REMADV von einem Marktpartner eindeutig sein oder darf der Marktpartner hier immer ein und die gleiche Angabe bei all seinen REMADVs (Bsp. Zahlungs-REMADV) angeben ?
Vielen Dank vorab
|
2020-08-10 19:22:37 |
Sehr geehrte Fragestellerin,
in Kapitel 3 des INVOIC-/REMADV-Anwendungshandbuches wird u.a. empfohlen:
Auf der Überweisung wird eine Referenz zur REMADV, mittels Avisnummer aus dem BGM, DE1004, mitgegeben.
Diese Empfehlung ist nicht umsetzbar, sofern ein MP immer die gleiche Nummer im BGM DE1004 überträgt. Dies widerspricht darüber hinaus der gängigen Praxis bei allen EDIFACT-Nachrichten, die ebendiese Dokumentennummer zur eindeutigen Identifikation einer Nachricht nutzen.
Freundliche Grüße,
Ihr BDEW-Forum Datenformate |
Ja
|
Klaus Keller |
Stefan Seidel |
Stefan Seidel |
Annett Kalz |
|
Nein
|
-------------Klaus Keller-------------18.08.2020 17:01
Antwortvorschlag an Herrn Seidel geschickt
|
Nein
|
Nein
|
|
INVOIC MIG 2.6f
|
Abgeschlossen
|
Ist die Einführung einer Kennzeichnung von Rechnungskorrekturzeilen denkbar ?
|
Aktuell ist keine Anpassung der bestehenden Möglichkeiten (negative Menge bei Rücknahme von Positionen oder Stornierung gesamter Rechnungen) geplant. |
29.07.2020
|
2020-00797 |
|
|
Sehr geehrte Damen und Herren,
wir haben eine Frage oder vielleicht besser formuliert einen Wunsch an das INVOIC-Format:
Gibt es bereits oder besteht die Möglichkeit, dass Korrekturrechnungszeilen als solche gekennzeichnet werden?
Beim Import von Rechnungen muss derzeit immer ein aufwendiger Algorithmus zur Suche ähnlicher/gleichartiger Rechnungszeilen implementiert werden. Mit einem einfachen Qualifier (bspw. J/N - ausgedrückt mit einem Zxx) könnte man dem Empfänger einer Rechnung diese Information mitgeben und die Prüfung stark vereinfachen.
Dies wäre eine Verbesserungsvorschlag unsererseits für eine nächste Formatversion.
Vielen Dank für Ihre Mühe.
Mit freundlichen Grüßen
Sebastian Weiße
|
2020-07-29 09:40:21 |
Sehr geehrter Herr Weiße,
wir können Ihre Anforderung nicht nachvollziehen, da wenn z. B. in einer Monatsrechnung bereits abgerechnete Positionen „korrigiert“ werden sollen, dies durch Rücknahme der entsprechenden Position erfolgt. Dies erfolgt durch Angabe einer negativen Menge, gefolgt von einer neuen Position mit positiver Menge.
Eine andere Art der Korrektur von einzelnen Positionen, wobei aber nicht alles korrigiert werden darf, ist nicht vorgesehen. Wenn eine Rechnung komplett falsch ist, gilt für jede betroffene Rechnung:
1.) Stornierung der betroffenen Rechnung
2.) Neuberechnung der korrigierten Positionen im Rahmen einer neuen Abrechnung
Bei weiteren Abrechnungsvarianten, die nicht durch prozessuale Vorgaben abgedeckt sind, muss eine bilaterale Absprache zur Nutzung der Nachrichten erfolgen.
Freundliche Grüße
Ihr Forum Datenformate |
Ja
|
Klaus Keller |
Stefan Seidel |
Stefan Seidel |
Sebastian Weiße |
|
Nein
|
-------------Klaus Keller-------------11.08.2020 07:46
Antwortvorschlag auf Basis der Mail von Herrn Seidel erstellt
-------------Klaus Keller-------------12.08.2020 16:49
nach Hinweis von Herrn Seidel zur QS für die AG R/Z vorgemerkt
|
Nein
|
Nein
|
|
MSCONS AHB 2.3a
|
Abgeschlossen
|
Mit welchem Nachrichtentyp erhält der LF die Werte vom MSB?
|
Die Übermittlung der Werte erfolgt mit der MSCONS |
08.07.2020
|
2020-00789 |
|
|
In der Rolle Lieferant beliefern wir Kunden mit komplexen Messungen (i.d.R. zwei Zähler aus denen die Differenz ermittelt wird). Die Menge muss der MSB berechnen und an uns übermitteln, so dass wir die Menge direkt für die Abrechnung des Kunden weiterverwenden können.
Mit welcher Nachricht übermittelt der MSB uns, dem Lieferanten, die Menge?
|
2020-07-08 10:39:49 |
Sehr geehrter Marktteilnehmer,
die Aufbereitung von Werten vom MSB an den Lieferanten erfolgt mit der MSCONS. Dabei wird für die Übermittlung der Zählerstände der Anwendungsfall mit dem Prüfidentifikator 13017 und für die Übermittlung von Energiemengen der Anwendungsfall mit dem Prüfidentifikator 13019 genutzt. Die Zuordnung der Prozessschritte zu den Anwendungsfällen finden Sie in dem EDI@Energy-Dokument "Anwendungsübersicht der Prüfidentifikatoren".
Viele GrüßeIhr BDEW-Forum Datenformate |
Ja
|
Reinhard Döring |
Thomas Seipt |
Reinhard Döring |
Uta Gruner |
|
Nein
|
Ich habe aufgrund einer Nachfrage einen Antwortvorschlag erstellt.
-------------Beate Becker-------------25.08.2020 09:56
|
Nein
|
Nein
|
|
MSCONS AHB 2.3a
|
Eingegangen
|
Wie werden Energiemengen auf Ebene der Marktlokation bei Zählerständen aus einem iMS gebildet?
|
Regel zur Bildung von Energiemengen auf Ebene der Marktlokation |
04.05.2020
|
2020-00748 |
|
|
Sehr geehrte Damen und Herren,
am Markt gibt es zurzeit unterschiedliche Auffassungen wie Energiemengen auf Ebene der Marktlokation zu bilden sind, wenn die Zählerstände aus einem intelligenten Messsystem und mit der Zeitangabe 00:00 Uhr im Geschäftsvorfall mit dem Prüfidentifikator 13017 übermittelt werden.
Wie werden die drei Energiemengen mit Beginn- und Endedatum gebildet, wenn die folgenden vier Zählerstände aus einem iMS vorliegen?
1. Zählerstand
Ablesegrund: COS „Vertragswechsel“
Erfassungshinweis: SMV „Anfangszählerstand“
Ablesedatum: 01.03.2020 00:00 Uhr
Zählerstand: 1000 KWh
2. Zählerstand
Ablesegrund: COT „Zwischenablesung“
Erfassungshinweis: MRV: Zählerstand
Ablesedatum: 01.04.2020 00:00 Uhr
Zählerstand: 1300 KWh
3. Zählerstand
Ablesegrund: PMR „Turnusablesung“
Erfassungshinweis: MRV: Zählerstand
Ablesedatum: 01.05.2020 00:00 Uhr
Zählerstand: 1500 KWh
4. Zählerstand
Ablesegrund: COS „Vertragswechsel“
Erfassungshinweis: EMV: Zählerstand
Ablesedatum: 01.06.2020 00:00 Uhr
Zählerstand: 1900 KWh
Viele Grüße
|
2020-05-04 12:21:52 |
Sehr geehrter Marktteilnehmer,
in dem Dokument „EDI@Energy Anwendungshilfe Messwerteaustausch“ ist die dazu folgende Regel veröffentlicht worden:
Regel „Beginn/Ende Messperiode“ für die Energiemenge:
„Beginn Messperiode“ bezieht sich immer auf 00:00 Uhr des im DE2380 angegebenen Tages.
„Ende Messperiode“ bezieht sich immer auf das Tagesende (umgangssprachlich „24:00 Uhr“) des im DE2380 angegebenen Tages, und somit auf den Zeitpunkt 00:00 Uhr des Folgetags.
Bei Anwendung der Regel auf Ihr Beispiel stellt sich folgende Konstellation dar: Die drei Energiemengen sind vom MSB der Marktlokation auf Basis der von Ihnen genannten Zählerstände sind wie folgt zu bilden und den berechtigten Marktpartner zu übermitteln:
1. EnergiemengeBeginndatum: 01.03.2020Endedatum: 31.03.2020Menge: 300 KWh
2. EnergiemengeBeginndatum: 01.04.2020Endedatum: 30.04.2020Menge: 200 KWh
3. EnergiemengeBeginndatum: 01.05.2020Endedatum: 31.05.2020Menge: 400 KWh
Freundliche Grüße,
Ihr BDEW Forum Datenformate |
Ja
|
Reinhard Döring |
Thomas Seipt |
Reinhard Döring |
Joachim Schlegel |
|
Nein
|
Frage wurde in der Sitzung vom 25.06.2020 freigegeben und sollte veröffentlicht werden.
-------------Gregor Scholtyschik-------------29.06.2020 15:23
|
Nein
|
Nein
|
|
Anwendungsübersicht der Prüfidentifikatoren - informatorische Lesefassung 1.0b
|
Abgeschlossen
|
Ab wann gilt die Bestellung der bilanzierten Menge beim ÜNB (ORDERS) und die Ablehnung der Bestellung (ORDRSP)?
|
Bestellung der bilanzierten Menge beim ÜNB und Ablehnung der Bestellung ab 01.04.2021 |
29.06.2020
|
2020-00784 |
|
|
In den Prozessen zur Ermittlung und Abrechnung von Mehr-/Mindermengen Strom und Gas ist die Bestellung der bilanzierten Menge beim ÜNB beschrieben. Der Prozess soll ab 01.10.2020 gelten. Der ÜNB hat darin die Möglichkeit die Bestellung per ORDRSP mit dem Prüfidentifikator 19115 abzulehnen. Dieser Prüfidentifikator ist aber erstmalig in den Vorgaben zum 01.04.2021 beschrieben und zum 01.10.2020 noch gar nicht gültig. Wie ist hier zu verfahren?
|
2020-06-29 15:22:20 |
Lieber Forumsteilnehmer,
sowohl die Bestellung der bilanzierten Menge beim ÜNB (ORDERS mit dem Prüfidentifikator 17114) als auch die Ablehnung der Bestellung (ORDRSP mit dem Prüfidentifikator 19115) sind in dem Anwendungshandbuch erstmalig beschrieben, welches zum 01.04.2021 gültig ist.
Freundliche Grüße,
Ihr Forum Datenformate |
Ja
|
Holger Kampmann |
Thomas Fellhauer |
Holger Kampmann |
Sabine Kornisch |
Aktuelle Anwendungshilfe MMMA vom BDEW:
https://www.bdew.de/media/documents/20200113_Marktprozesse-Mehr-und-Mindermengenabrechnung_S_G_V_1_3.pdf
Neuer Prozess „Bestellung der bilanzierten Menge beim ÜNB“ (Kap. 4.1.2)
|
Nein
|
|
Nein
|
Nein
|
|
Anwendungsübersicht der Prüfidentifikatoren - informatorische Lesefassung 1.0b
|
Eingegangen
|
Wie erhält der NB die bilanzierte Menge für „iMS-Marktlokationen“ bis zum 1.4.2021
|
In der Bilanzierungsgebietsclearingliste steht die bilanzierte Menge je Marktlokation. |
22.04.2020
|
2020-00740 |
|
|
Wie erhält der NB die bilanzierte Menge für SLP-Marktlokationen mit Aggregationsverantwortung beim ÜNB, wenn die Umsetzung der ORDERS (Bestellung der bilanzierten Menge beim ÜNB) erst zum 01.04.2021 möglich ist?
|
2020-04-22 16:15:56 |
Der Monat April 2020 ist der erste mögliche Monat, in dem die Aggregationsverantwortung einer Marktlokation dem ÜNB zufallen kann. Da die Übermittlung der Bilanzierungsgebietsclearinglisten bereits ab dem 1.12.2019 mit den veröffentlichten Formaten möglich ist, ermöglicht diese Variante einen nahtlosen Übergang der Mehr-/Mindermengenabrechnung ab dem ersten möglichen Bilanzierungsmonat April 2020. Eine Umsetzung der Variante „Bestellung“ erfolgte in den Datenformaten mit Veröffentlichungsdatum 01.04.2020. Eine Umsetzung der Formate ist durch die BNetzA zum 01.04.2021 festgelegt worden. Damit ist eine Bestellung der bilanzierten Menge beim ÜNB (auch rückwirkend) ab dem 01.04.2021 möglich.
Hinweis: Eine untermonatige Aufteilung der vom ÜNB erhaltene bilanzierte Menge ist nicht erforderlich, da die Netznutzungsabrechnung auf Basis der monatlich versandten Zählerstände des iMS erfolgt. Im Falle eines untermonatlichen Lieferantenwechsels ist das Asynchronmodell zu beachten. |
Ja
|
Holger Kampmann |
Thomas Fellhauer |
Holger Kampmann |
Thomas Seipt |
|
Nein
|
|
Nein
|
Nein
|
|
UTILTS AHB Berechnungsformel 1.0
|
Abgeschlossen
|
|
UTILTS wird für alle betroffenen Marktlokationen versendet |
10.06.2020
|
2020-00771 |
|
|
Sehr geehrte Damen und Herren,
ist zum 01.10.2020 die UTILTS an alle Lieferanten zu versenden?
Oder wird sie nur in neuen Prozessen, die ab dem 01.10. gestartet wurden zu versenden?
Beste Grüße
Sam Kruppe
Stromnetz Hamburg
|
2020-06-10 08:54:07 |
Hallo Herr Kruppe,
in Kapitel 2.5.1 der WiM Strom ist unter Vorbedingungen zu lesen:
"Voraussetzungen für den Versand der Berechnungsformeln an alleLF:- Die Ermittlung der Werte der Marktlokation ist nur auf Basis von mehr als einer Messlokation möglich.- Neuzuordnung eines LF zu einer Marktlokation oder- bei Änderung des Messkonzepts in der Art, dass nach der Änderung die Werte der Marktlokation nur auf Basis von mehr als einer Messlokation ermittelt werden können."
Somit ist eine Übermittlung der UTILTS für alle betroffenen Marktlokationen vorgesehen.
Wir weisen darauf hin, daß der Start des Versandes der Berechnungsformel vom NB an den LF vom 01.10.2020 auf den 01.04.2021 durch die BNetzA aufgrund der Corona-Situation verschoben wurde.
Freundliche Grüße,
Ihr BDEW-Forum Datenformate |
Ja
|
Ralf Teutsch |
Klaus Keller |
Ralf Teutsch |
Sam Kruppe |
|
Nein
|
-------------Klaus Keller-------------17.06.2020 14:46
Antwortvorschlag erstellt und an Herrn Teutsch zur Prüfung geschickt
-------------Klaus Keller-------------22.06.2020 09:44
Veröffentlichung nach Prüfung von Herrn Teutsch
-------------Klaus Keller-------------22.06.2020 10:26
Ergänzung nach Mails von Gregor und Joachim:
Wir weisen darauf hin, daß der Start des Versandes der Berechnungsformel vom NB an den LF vom 01.10.2020 auf den 01.04.2021 durch die BNetzA aufgrund der Corona-Situation verschoben wurde.
|
Nein
|
Nein
|
|
UTILTS AHB Berechnungsformel 1.0
|
Abgeschlossen
|
Kann ein Verlustfaktor in einem Rechenschritt mit dem Operator "Addition" verwendet werden?
|
Ja. |
19.12.2019
|
2019-00611 |
|
|
Hallo Liebes Forum,
kann ein Verlustfaktor in einem Rechenschritt mit dem Operator "Addition" verwendet werden?
Wir beobachten sehr oft einen Rechenschritt, welcher aus dem Operator "Addition", einer Referenz auf MeLo und einem Verlustfaktor besteht. Soll das automatisch bedeuten, dass die Werte aus der MeLo vor der Addition mit dem Faktor multipliziert werden sollen?
Wir sind der Meinung, dass Faktor nur in Verbindung mit dem Operator "Faktor" angegeben werden kann. Und wenn man die "Addition" verwenden möchte, dann müssen es 2 Rechenschritte sein.
Viele Grüße und Danke für die Aufklärung
|
2019-12-19 15:39:19 |
Sehr geehrter Fragesteller,
auf die Messwerte der Messlokation sind erst der Verlustfaktor des Transformators und der Verlustfaktor der Leitung, jeweils multiplikativ anzuwenden (UTILTS MIG 1.0 S.29). Das Ergebnis wird anschließend in der Operation des Bestandteils des Rechenschritts verwendet.
Verlustfaktoren können unabhängig vom Operator angegeben werden.
Mit freundlichen Grüßen
Ihr Forum Datenformate |
Ja
|
Ralf Teutsch |
Klaus Keller |
Ralf Teutsch |
Oleg Pavlov |
|
Nein
|
Beantwortet am Dez .2019 Ralf Teutsch
Veröffentlicht
-------------Ralf Teutsch-------------23.06.2020 09:46
|
Nein
|
Nein
|
|
UTILTS AHB Berechnungsformel 1.0
|
In Bearbeitung
|
Kann der LF die Berechnungsformel empfangen?
|
Ja, jedoch erst ab dem 01.10.2020. Das UTILTS AHB wird rechtzeitig angepasst. |
22.10.2019
|
2019-00511 |
|
|
Laut "BK6-18-032_anlage_2_wim Seite 99ff 2.5.2. SD: Übermittlung der Berechnung" erhält der LF die Berechnungsformel vom NB. Im AHB zur UTILTS 1.0 erfolgt die Kommunikation allerdings nur zwischen NB und MSB. Durch welchen Prozess bekommt der LF die Berechnungsformel übermittelt?
|
2019-10-22 14:50:50 |
Laut Beschluss der BNetzA BK6-18-032 Punkt 2 tritt die Verpflichtung der NBs, die Berechnungsformel auch den LF zu übermitteln, erst zum 01.10.2020 in Kraft. Infolgedessen enthält die Version 1.0 des UTILTS AHB diese Ausprägung noch nicht.
Es wird rechtzeitig eine neue Version des UTILTS AHB in Kraft treten.
Mit freundlichen Grüßen
Forum Datenformate |
Ja
|
Ralf Teutsch |
Klaus Keller |
Ralf Teutsch |
Ozan Kahraman |
|
Nein
|
|
Nein
|
Nein
|
|
UTILTS AHB Berechnungsformel 1.0
|
Zur Abstimmung in PG
|
Wie kann ein Faktor z.B. 0,33 angegeben werden?
|
Einheitenlose feste Faktoren (z.B. 0,33) können nicht übermittelt werden. |
05.09.2019
|
2019-00431 |
|
|
zum Mathematischen Operator: Wenn im Segment Z86 ein Faktor (Z82) angegeben werden soll; wie soll das Segment dann vollständig aussehen?
Z.B. Faktor = 0,33
|
2019-09-05 16:28:02 |
Sehr geehrter Fragesteller,
in einem Rechenschritt mit dem Operator Faktor (Z82) muss entweder auf eine Messlokation oder auf einen anderen Rechenschritt als Träger der Werte referenziert werden. Diese Werte gehen als Faktor in die Operation ein.
Einheitenlose feste Faktoren können ausschließlich als Verlustfaktor Trafo oder als Verlustfaktor Leitung in eine Berechnungsformel eingehen. Hat der feste Faktor eine andere Bedeutung, muss die Formel als "muss beim Absender angefragt werden" (STS+Z23+Z34) gekennzeichnet werden.
Mit freundlichen Grüßen
Ihr Forum Datenformate |
Ja
|
Ralf Teutsch |
Klaus Keller |
Ralf Teutsch |
Ulrich Kracker |
|
Nein
|
|
Nein
|
Nein
|
|
Codeliste der Messprodukte 2.1
|
Abgeschlossen
|
Sind überlappende Zeiträume mit einer Null-Menge im Lieferschein erlaubt?
|
Überlappende Zeiträume von Energiemengen pro OBIS-Kennzahl sind im Lieferschein nicht erlaubt |
05.06.2020
|
2020-00766 |
|
|
Übermittlung von Null-Mengen im Lieferschein
Im Entscheidungsbaumdiagramm zum Lieferschein zur Netznutzungsabrechnung heißt es:
„Entspricht die zuvor vom MSB übermittelte Summe der Energiemengen je OBIS-Kennzahl der Summe der Energiemengen der aus dem Lieferschein korrespondierenden OBIS-Kennzahl für den vom Lieferschein abgedeckten Zeitraum?“
Wenn der Netzbetreiber für dieselbe OBIS-Kennzahl und denselben Zeitraum eine Menge ungleich null und eine Null-Menge liefert, ist dies unserer Ansicht nach nicht erlaubt, da dies physikalisch nicht sinnvoll ist und es zu einer Zeitraumüberlappung kommt.
Der Netzbetreiber verweist auf das EBD und darauf, dass die Summierung über beide Mengen den korrekten Wert liefern würde. Unserer Interpretation dieses Schrittes im EBD nach ist hier mit der „Summe der Energiemengen je OBIS-Kennzahl“ allerdings die Summierung über aufeinanderfolgende Zeiträume, nicht überlappende Zeiträume, gemeint.
Darf der Lieferant diese Lieferscheine ablehnen mit der Begründung, dass überschneidende Zeiträume nicht erlaubt sind?
Vielen Dank
|
2020-06-05 14:01:47 |
Sehr geehrter Marktteilnehmer,
für einen Zeitraum darf im Lieferschein nur eine Energiemenge pro OBIS-Kennzahl angegeben werden.
Mit freundlichem Gruß
Ihr BDEW-Forum Datenformate
|
Ja
|
Beate Becker |
Beate Becker |
Beate Becker |
Frank Buthe |
EDI@Energy Entscheidungsbaum-Diagramme Für die Prozesse zur Marktkommunikation 2020
Konsolidierte Lesefassung mit Fehlerkorrekturen Stand: 3. April 2020
EBD 2.1 vom 03.04.2020 Seite 10; 4.1. SD: Übermittlung des Lieferscheins zur Netznutzungsrechnung Nr. 5 |
Nein
|
Wird in die kleine Gruppe zur Überarbeitung des Lieferscheins mit genommen
-------------Beate Becker-------------08.06.2020 09:45
|
Nein
|
Nein
|
|
INVOIC / REMADV AHB 2.3d
|
In Bearbeitung
|
Wie wird zwischen PDF und zugehöriger INVOIC bei Kapazitätsrechnungen referenziert ?
|
Lt. zugehöriger Prozessbeschreibung erfolgt die Referenzierung über die Rechnungsnummer |
03.06.2020
|
2020-00762 |
|
|
Zum 01.10.2020 wird die Kapazitätsrechnung mit aufgenommen.
1. Das dazu begleitende PDF wird ja aufgrund der Regelungen zum Übertragungsweg mit einer separaten E-Mail übermittelt. Wie soll die Verknüpfung vom PDF zur dazugehörigen INVOIC-Datei erfolgen? Gibt es hierzu eine Namenskonvention z.B. dass der Name der PDF die Rechnungsnummer enthalten muss? Wie sonst kann die Zuordnung erfolgen?
2. 2. Im AHB findet sich für den Prüfidentifikator 31010 (Kapazitätsrechnung) keinerlei Hinweis, wie der betreffende Ausspeisepunkt identifiziert werden soll. Ist das gewollt? Müsste man den Ausspeisepunkt nicht auch identifizieren können z.B. anhand der ID (PBF-XXXXXXXX)?
|
2020-06-03 10:34:22 |
Sehr geehrte Fragestellerin,
zur Beantwortung Ihrer Frage empfehlen wir das Studium der zugehörigen BDEW-Prozessbeschreibung, die im INVOIC/REMADV-AHB verlinkt ist. Im AHB findet sich zur Verwendung von BGM DE1004 zusätzlich der Hinweis:
"[517] Hinweis:Dokumentennummer der PDF Kapazitätsrechnung"
Über die in der Prozessbeschreibung getroffene Vorgabe zur Referenzierung hinaus wurden keine zusätzlichen Identifikationsmerkmale, wie die von Ihnen genannten Ausspeisepunkte, für die INVOIC aufgenommen.
Viele Grüße,
Ihr BDEW-Forum Datenformate |
Ja
|
Klaus Keller |
Stefan Seidel |
Stefan Seidel |
Silk Söldner |
|
Nein
|
-------------Klaus Keller-------------04.06.2020 11:29
Antwortvorschlag erstellt
|
Nein
|
Nein
|
|
INVOIC / REMADV AHB 2.3d
|
In Bearbeitung
|
Ist eine automatisierte Ablehnung von falschen Empfängerangaben der Rechnung vorgesehen ?
|
Nein, es ist lediglich möglich eine unbekannte Empfänger-MP-ID per Syntaxfehlermeldung abzulehnen. |
06.04.2020
|
2020-00724 |
|
|
Hallo zusammen,
wie ist abzulehnen, wenn der Marktpartner innerhalb der INVOIC im NAD MS+NAD MR einen falschen Namen und/oder falsche Adresse angibt?
Soll dies mit einer APERAK erfolgen? Z.B. Z31?
Oder erfolgt dies mit einer ablehnenden REMADV? Mit welchem Ablehnungsgrund? Sonstiges darf bei MMMA und MSB nicht gezogen werden.
Wir bitten um eine kurze Rückmeldung.
|
2020-04-06 09:54:06 |
Sehr geehrter Marktpartner,
wir gehen davon aus, dass die verwendete MP-ID im NAD+MR-Segment korrekt ist und es lediglich zu Unstimmigkeiten bei Namens- und Adressangaben gibt. Hier sollte generell gemäß vertraglicher Regelungen zwischen den Beteiligten die Befüllung erfolgen. Nach unserer Einschätzung gibt es hier im Markt unterschiedliche Hintergründe, z.B. Datenqualität in den jeweiligen Stammdatensystemen oder Änderungen bei Umfirmierungen. Hierfür ist derzeit keine automatisierte Ablehnung per REMADV oder APERAK vorgesehen und daher eine bilaterale Klärung zwischen den Beteiligten erforderlich.
Freundliche Grüße,
Ihr BDEW-Forum Datenformate |
Ja
|
Klaus Keller |
Stefan Seidel |
Stefan Seidel |
Jasmin Bernhardt |
|
Nein
|
-------------Klaus Keller-------------22.04.2020 14:05
Kurzfrage, - antwort und Antwort erstellt
|
Nein
|
Nein
|
|
INVOIC / REMADV AHB 2.3d
|
In Bearbeitung
|
Was wird bei "nicht steuerbaren" Rechnungspositionen in SG52-MOA+125 übertragen ?
|
Die Summe der nicht steuerbaren Positionen wird in SG52-MOA+125 übertragen. |
01.04.2020
|
2020-00719 |
|
|
Sehr geehrte Damen und Herren,
wir haben eine Frage zur Anwendung des Formats INVOIC bei einer Steuerbefreiung.
Ein Marktpartner hat eine Rechnungsposition als "nicht steuerbar" gekennzeichnet. Wie muss das MOA-Segment der SG52 mit Qualifier 125 befüllt werden?
Variante 1: Es wird mit "0" befüllt, da nicht versteuert wird.
Variante 2: Es wird der entsprechende Nettobetrag iHv X Euro eingetragen, da beim TAX-Segment der SG34 als Kommentar "Zusätzlich werden im SG52 TAX-MOA die Gesamtsummen je Steuersatz übermittelt." aufgeführt wird?
Vielen Dank für Ihre Mühe.
Mit freundlichen Grüßen
Sebastian Weiße
|
2020-04-01 18:35:03 |
Hallo Herr Weiße,
Ihr unter Variante 2 dargestellter Lösungsansatz ist richtig; im SG 52 wird unter dem MOA 125 der „reguläre“ Nettorechnungsbetrag ausgewiesen, also NICHT 0 Euro dargestellt.
(Im MOA+161 [161 Steuer-/Gebühren-/Abgabebetrag] wird dann 0 Euro ausgewiesen).
Beispiel:
SG52:
…
MOA+125:2404.62'
MOA+161:0'
…
Freundliche Grüße,
Ihr BDEW-Forum Datenformate |
Ja
|
Klaus Keller |
Stefan Seidel |
Stefan Seidel |
Sebastian Weiße |
|
Nein
|
-------------Klaus Keller-------------03.04.2020 15:54
Vorschlag von Gero eingetragen und Kurzfrage/-antwort ergänzt
|
Nein
|
Nein
|
|
INVOIC / REMADV AHB 2.3d
|
Abgeschlossen
|
Kann ein Lieferant eine NN-INVOIC im Bereich Strom mit dem Grund Z07 bzw. Z10 reklamieren, wenn der dazugehörige Lieferschein direkt oder indirekt als o. k. gemeldet wurde?
|
Dies kann nicht ausgeschlossen werden. |
02.03.2020
|
2020-00683 |
|
|
Kann ein Lieferant eine NN-INVOIC im Bereich Strom mit dem Grund Z07 bzw. Z10 reklamieren, wenn der dazugehörige Lieferschein vom Netzbetreiber versendet wurde , mit positiver CONTRL vom Lieferanten bestätigt wurde, die Menge der INVOIC mit der Menge des versendeten Lieferscheins übereinstimmt und der Lieferant keine IFTSTA mit Status Z31 innerhalb der 2 Werktage nach Erhalt des Lieferscheins versendet hat?
Vielen Dank! Clara Craffonara
|
2020-03-02 09:09:50 |
Sehr geehrte Fragestellerin,
prinzipiell sollte es in diesem Fall zu keiner Ablehnung der Rechnung aufgrund der genannten Gründe "Netznutzungsmesswerte / -energiemengen fehlen" oder "Netznutzungsmesswerte / -energiemengen falsch" kommen. Jedoch können wir hier nicht beurteilen, ob es im vorliegenden Fall nicht doch zu einer berechtigten Nutzung dieser Ablehnungscodes kam.
Wir erlauben uns an dieser Stelle den Hinweis, dass mittels einer Empfangsbestätigung, die per CONTRL ausgetauscht wird, der Sender einer derartigen CONTRL lediglich die syntaktische Fehlerfreiheit der entsprechenden Übertragungsdatei sowie deren Eingang bestätigt.
Freundliche Grüße,
Ihr Forum Datenformate |
Ja
|
Klaus Keller |
Stefan Seidel |
Klaus Keller |
Clara Craffonara |
|
Nein
|
Lösungsidee eingestellt
-------------Stefan Seidel-------------02.03.2020 11:28
Kurzfrage und - antwort ergänzt
-------------Stefan Seidel-------------04.03.2020 17:52
veröffentlicht
-------------Klaus Keller-------------09.03.2020 09:13
|
Nein
|
Nein
|
|
INVOIC / REMADV AHB 2.3d
|
Abgeschlossen
|
Welcher Lieferschein ist bei Nachberechnungen oder Korrektur von Umlagen in der INVOIC anzugeben?
|
Es kann auf den bisherigen Lieferschein referenziert werden, sofern dieser gültig bleibt und zur Rechnung passend ist |
19.02.2020
|
2020-00672 |
|
|
Guten Tag,
die INVOIC erfordert ja einen Bezug zu einen im Vorfeld versendeten Lieferschein.
Wie verhält es sich aber bei einer Invoic, die lediglich die Nachberechnung/Korrektur von Umlagen oder Konzessionsabgaben beinhaltet.
Die jährlich von manchen Anschlussnutzern zu meldenden Informationen zu selbstverbrauchten Mengen erfordert z.B. eine (manuelle) Rechnungsskorrektur.
Wie kann man in solchen Fällen vermeiden, dass die INVOIC abgelehnt wird, da kein Lieferschein vorliegt.
Im Voraus vielen Dank.
|
2020-02-19 14:09:45 |
Sehr geehrter Fragesteller,
zu dem prozessualen Teil dieser Fragestellung können wir hier keine Antwort geben. Bezüglich der Ausprägung der INVOIC ist im von Ihnen skizzierten Fall analog der Vorgehensweise bei Stornierungen zu verfahren:
- Angabe der bisherigen Referenz, sofern die Mengen im Lieferschein unverändert und für die INVOIC richtig sind
- Angabe einer neuen Referenz, sofern sich die Mengen im Lieferschein geändert haben und ein neuer Lieferschein verschickt wurde
Freundliche Grüße,
Ihr BDEW-Forum Datenformate |
Ja
|
Klaus Keller |
Stefan Seidel |
Klaus Keller |
Michael Hoffmann |
|
Nein
|
-------------Klaus Keller-------------27.02.2020 09:20
Kurzfrage, - antwort und Antwort erstellt und zur Prüfung an Herrn Seidel geschickt
-------------Stefan Seidel-------------04.03.2020 17:59
leichte Überarbeitung durchgeführt und Herrn Keller informiert
-------------Klaus Keller-------------09.03.2020 09:16
veröffentlicht
|
Nein
|
Nein
|
|
INVOIC / REMADV AHB 2.3d
|
Abgeschlossen
|
Gibt es einen INVOIC-Anwendungsfall zur Übermittlung von Kosten für die Sperrung und/oder Entsperrung ?
|
Es gibt keine Prozessbeschreibung zur Abrechnung von Sperrungen und/oder Entsperrungen und somit keinen dafü |
