Skip to main content

Veröffentlichte Fragen


Thema Status Kurzfrage Kurzantwort Anlagedatum Ticketnummer Frage Anlagedatum Hauptantwort Veröffentlicht Bearbeiter Vertreter Aktueller Bearbeiter Fragender Textbezug Archiviert Kommentar Änderungsantrag zu erstellen Änderungsantrag erstellt
Regelungen zum Übertragungsweg für AS4 2.1 Eingegangen Wechsel des Übertragungsweg nach dem 01.04.2024 (Sparte Strom) Nach dem 01.04.2024 gibt es keinen Wechsel des Übertragungsweg mehr. 12.02.2024 2024-02098 Muss mit komplett neuen (also bislang kein MAKO/FPM) Marktteilnehmern ab 1.4.2024 ein Path Switch durchgeführt werden, die bislang auch keine E-Mail-Kommunikation gemacht haben? Neue Marktteilnehmer könnten z.B. Unternehmen sein, die erst nach dem 1.4.2024 gegründet wurden und/oder erst ab 1.4.2024 am Strommarkt teilnehmen. 2024-02-12 13:10:03 Sehr geehrter Fragesteller, vielen Dank für Ihre Anfrage. Der Service Änderung des Übertragungswegs "https://www.bdew.de/as4/communication/services/pathSwitch" wird ausschließlich zum Wechseln des Übertragungsweg Email auf den Übertragungsweg AS4 genutzt. Nach dem festgelegten Ende zur Nutzung des Übertragungsweg Email müssen alle Marktpartner den Übertragungsweg AS4 nutzen. Einen Wechsel sollte es dann nicht mehr geben.  Freundliche Grüße Ihr Forum Datenformate Ja Rene Hoffmann Rene Hoffmann Rene Hoffmann Thomas Beckers Kapitel 7.2 Kapitel 2.3.7(AS4-Profil) Nein -------------Dirk Katzenbach-------------14.02.2024 13:35 Nein Nein
Regelungen zum Übertragungsweg 1.6 Eingegangen Leitet sich der Signatur-Hashalgorithmus aus dem verwendeten Zertifikat ab? Die Umsetzung der Signatur muss gemäß RFC 4056 erfolgen. 08.02.2024 2024-02091 Wir haben von einem Marktpartner ein neues Zertifikat erhalten, welches mit dem Algorithmus SHA512 verschlüsselt. Auf die Mail selbst wurde jedoch eine Signatur mit einem SHA256 Schlüssel aufgebracht. Unsere Entschlüsselungssoftware hat diese Kombination als nonkonform mit RFC4056 abgelehnt. Dort ist unter 3. geregelt: 1. The hashAlgorithm field in the certificate subjectPublicKey.algorithm parameters and the signatureAlgorithm parameters MUST be the same. (https://www.rfc-editor.org/rfc/rfc4056) Der Marktpartner beruft sich auf den Abschnitt 5.3 in den Regelungen zum Übertragungsweg: Signatur: Hashfunktion (Hash algorithm): SHA-256 oder SHA-512 Was gilt für den Hash-Algorithmus der Nachricht? 2024-02-08 14:28:57 Sehr geehrter Fragesteller, vielen Dank für Ihre Anfrage. Die Regelungen zum Übertragungsweg geben den Rahmen der Anforderungen für die Absicherung der Kommunikation vor. Die konkreten Anforderungen zur Umsetzung sind den dort angesprochen Regelwerken zu entnehmen. Dies ist insbesondere die TR-03116-4, welche eine Umsetzung der Signatur gemäß RFC 4056 fordert. Freundliche Grüße Ihr Forum Datenformate Ja Rene Hoffmann Sven Schillack Rene Hoffmann Georg Helzle 5.3 Algorithmen und Schlüssellängen für S/MIME Es sind folgende Algorithmen und Schlüssel mit den genannten Schlüssellängen zu verwenden17: Einstellungen in der Software: › Signatur: Hashfunktion (Hash algorithm): SHA-256 oder SHA-512 (gemäß IETF RFC 5754). Signaturverfahren (Signature algorithm): RSASSA-PSS (gemäß IETF RFC 4056). Nein Nein Nein
COMDIS AHB 1.0e Abgeschlossen Gibt es eine direkte Auflistung von REMADV- zu COMDIS-Codes ? Nein, seit der Umstellung auf Entscheidungsbaumdiagramme nicht mehr. 31.01.2024 2024-02075 Gibt es irgendwo eine Auflistung, für welche Statusgründe neg. REMADV eine COMDIS gesendet werden muss? Vormals waren es die Differenzierungsgründe: 14 Z01 Z02 Z07 Z10 Vielen lieben Dank vorab! 2024-01-31 18:16:10 Sehr geehrte Fragestellerin, die von Ihnen zitierte Gegenüberstellung der REMADV- und COMDIS-Codes musste im Rahmen der Umstellung auf einheitliche Prüfung mittels Entscheidungsbaumdiagrammen (EBD) in der bisherigen Form gestrichen werden. Mit der Einführung der EBD wurden die Codes für die COMDIS (PID 29001 Ablehnung REMADV) in die Codeliste S_0109 "Nichtzahlungsavis prüfen" überführt. In der Codeliste sind die Bedingungen vorgegeben, wann die möglichen Codes der Codeliste S_0109 zu verwenden sind. Freundliche Grüße, Ihr BDEW-Forum Datenformate   Ja Thomas Seipt Klaus Keller Thomas Seipt Gabriele Maiburg Nein -------------Klaus Keller-------------09.02.2024 15:57 Vorschlag erstellt und an Thomas Seipt gesendet ------------Thomas Seipt-------------09.02.2024 16:47 Vorschlag für Alternative: Mit der Einführung der EBD wurden die Codes für die COMDIS (PID 29001 Ablehnung REMADV) in die Codeliste S_0109 überführt. In der Codeliste sind die Bedingungen vorgegeben, wann die möglichen Codes der Codeliste S_0109 zu verwenden sind. --------------Klaus Keller-------------12.02.2024 09:17 Antwortvorschlag von Thomas eingebaut und veröffentlicht Nein Nein
REMADV MIG 2.9c Abgeschlossen Gehört der Ablehncode "E_0567" in die REMADV ? Nein, dieser Code ist in der COMDIS enthalten und nur in dieser zu verwenden. 29.01.2024 2024-02069 Die Änderung 24096 in der Änderungshistorie fügt die Codes "E_0566", "E_0567" und "E_0568" dem Feld SG7 AJT Abweichungsgrund DE1082 hinzu, während Änderung 24107 nur -0566 und -0568 dem Feld hinzufügt. Betrachtet man das Dokument fehlt der Code "E_0567" in der Beschreibung des Datenelements. Ist Code "E_0567" nun eine valider Inhalt für das Feld oder nicht? 2024-01-29 14:11:53 Sehr geehrter Fragesteller, der Änderungshistorieneintrag 24096 ist falsch, da der Code "E_0567" im Rahmen der Ablehnung eines Nichtzahlungsavis per COMDIS zu verwenden ist. Es gilt also die Beschreibung der Anpassung des AJT-Segmentes gemäß Änderungseintrag 24107. Der Code E_0567 ist richtigerweise ausschließlich in der COMDIS vorhanden (vgl. hierzu auch die Änderungshistorieneinträge 24125 und 24093).  Freundliche Grüße, Ihr BDEW-Forum Datenformate Ja Klaus Keller Stefan Seidel Stefan Seidel Tobias Schemmelmann Nein -------------Klaus Keller-------------29.01.2024 14:29 Änderungsantrag erstellt und an Herrn Seidel zur QS gesendet -------------Stefan Seidel-------------29.01.2024 22:14 ein wenig umformuliert um es etwas härter auszudrücken. -------------Klaus Keller-------------30.01.2024 12:57 geprüft und veröffentlicht Nein Nein
INVOIC / REMADV AHB 2.5c Abgeschlossen Ist die Sonderrechnung (SOR) verpflichtend? Nein, die Sonderrechnung (SOR) stellt eine Option dar 23.01.2024 2024-02060 Ist die Sonderrechnung (SOR) verpflichtend zu nutzen, um eine Netznutzungsabrechnung zu korrigieren oder kann ebenfalls die Originalrechnung storniert und eine neue NNR verschickt werden? 2024-01-23 09:30:08 Sehr geehrter Marktteilnehmer, die Sonderrechnung (SOR) stellt eine zusätzliche Option für den Rechnungsteller dar, um die Rechnung nicht stornieren und anschließend eine neue Rechnung stellen zu müssen. Sie müssen diese nicht verwenden. Wenn Sie lieber die Ursprungsrechnung stornieren und eine neue Netznutzungsrechnung stellen wollen, ist das möglich. Mit freundlichem Gruß Ihr BDEW-Forum Datenformate Ja Klaus Keller Stefan Seidel Klaus Keller Deborah Svette Im AHB INVOIC/REMADV ist nicht klar ersichtlich, dass zur Korrektur einer NNR eine Sonderrechnung verwendet werden muss. Es lässt den Raum offen, dass zur Korrektur die Original-NNR diese storniert und eine neue NNR versendet werden kann. Mit Aufnahme des neuen Codes Z09 Privilegierung nach EnFG (im GEI 7365) liegt die Annahme vor, dass die NNR nur noch mit einer Sonderrechnung korrigiert werden kann. Ist das korrekt? Nein -------------Stefan Seidel-------------23.01.2024 09:42 Antwortvorschlag erstellt -------------Klaus Keller-------------30.01.2024 12:59 Veröffentlichung Nein Nein
Codeliste der Artikelnummern und Artikel-ID 5.4 - Außerordentliche Veröffentlichung Abgeschlossen Darf die Artikel-ID 4-02-0-023 (Vorzeitige Ausstattung mit IMS) in einer PRICAT enthalten sein? Die Artikel-ID 4-02-0-023 (Vorzeitige Ausstattung mit IMS) wird mit der nächsten Fehlerkorrektur entfernt. 22.01.2024 2024-02057 Hallo zusammen, kann bitte mal jemand Licht ins Dunkel bringen zu dem Artikel 4-02-0-023 (Vorzeitige Ausstattung mit IMS) lt. der Artikelnummernliste ist dieser extra wieder am 23.10.23 mit aufgenommen worden und somit auch zum 01.01.2024 "IN DER PRICAT" gültig. Die Berechnung darf jedoch erst zum 01.01.2025 stattfinden?! Ist das so richtig interpretiert? Ganz viele Lieferanten lehnen die PRICAT komplett ab, weil der Artikel enthalten zum 01.01.2024 enthalten ist. Können Sie da zeitnah reagieren bitte? Danke und Gruß Ulrich Lohmann 2024-01-22 10:07:02 Sehr geehrter Marktteilnehmer, alle PRICAT, die vorm 1.1.2025 gültig sind, dürfen diese Artikel-ID nicht enthalten. Die Artikel-ID 4-02-0-023 (Vorzeitige Ausstattung mit IMS) wird mit der nächsten Fehlerkorrektur entfernt, da über diese nicht die Erbringung des Messstellenbetriebs abgerechnet wird.  Viele Grüße, Ihr BDEW-Forum Datenformate Ja Beate Becker Klaus Keller Beate Becker Ulrich Lohmann Der 01.01.2025 bezieht sich auf die Leistungsbeschreibung des MsbG §34 Abs. 2 Nr. 1: ab 2025 die vorzeitige Ausstattung von Messstellen mit einem intelligenten Messsystem innerhalb von vier Monaten ab Beauftragung, auch an nicht von § 29 Absatz 1 oder Absatz 2 erfassten Messstellen, insbesondere an nicht bilanzierungsrelevanten Unterzählpunkten innerhalb von Kundenanlagen im Sinne von § 3 Nummer 24a und 24b des Energiewirtschaftsgesetzes, Nein in AG R/Z besprochen. -------------Beate Becker-------------16.02.2024 11:31 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
COMDIS AHB 1.0d Abgeschlossen Muss eine COMDIS zur Ablehnung eines Nichtzahlungsavis verwendet werden ? Ja 15.01.2024 2024-02050 Sehr geehrte Damen und Herren, wir benötigen eine Konkretisierung in Bezug auf die Verwendung der COMDIS bei Ablehnung einer NN-INVOIC. Aus unserer Sicht ist eine COMDIS nicht verpflichtend. So haben wir auf eine negative REMADV die bilaterale Klärung mit dem MP angestoßen, ohne vorab eine COMDIS zu versenden. Der Lieferant lehnt nun die Klärung mit Hinweis auf die fehlende COMDIS ab, da laut ihm eine COMDIS laut Prozessvorschrift zwingend notwendig ist. Diese Ansicht teilen wir nicht, aus den Vorgaben des BDEW lesen wir, dass es sich um eine Kann-Regelung handelt. Um nun mit dem Lieferanten für zukünftige Fälle eine Basis zu erhalten, würde ich mich freuen, wenn Sie die Ansicht des BDEW darlegen könnten. Vielen Dank im Voraus für Ihre Rückmeldung. 2024-01-15 10:34:16 Sehr geehrter Fragesteller, die "Option" im SD:Netznutzungabrechnung bezieht sich darauf, dass das "Nicht-Zahlungsavis aus Sicht des NB unberechtigt" war. Eine bilaterale Meldung dieser Informationen spricht gegen einheitliche Prozesse im Sinne aller Marktpartner. Freundliche Grüße, Ihr BDEW-Forum Datenformate Ja Thomas Seipt Klaus Keller Thomas Seipt Florian Behrens Nein -------------Klaus Keller-------------16.01.2024 07:49 Vorschlag erstellt (inkl. Kurzfrage und -antwort) -------------Thomas Seipt-------------17.01.2024 09:30 Zustimmung -------------Vanessa Stemplowsky-------------17.01.2024 14:49 In PG besprochen, kann beantwortet werden Nein Nein
PRICAT AHB 2.0c Abgeschlossen Wie ist der Gültigkeitsbeginn von Preisblättern geregelt? Eine Anpassung der Preisblätter erfolgt in der Regel zum 1. eines Jahres. Ausnahmen sind möglich. 14.12.2023 2023-02035 Als Lieferant erhalten wir von den Marktpartnern unterschiedliche PRICAT und bräuchten etwas Klärung. 1. Welche Preisblätter müssen mit Gültigkeit zum Jahresbeginn gesendet werden und welche dürfen einen unterjährigen (täglichen) Gültigkeitsbeginn aufweisen? Ist der Textbezug so zu verstehen, dass Preisblatt NN ohne Konzessionsabgaben und Preisblatt MSB zum 1. Januar beginnen müssen? 2. Dürfen Preisblätter unterjährig gesendet werden, wenn der Vertragsbeginn unterjährig ist? 3. Sind Preisblätter für Gas mit Gültigkeitsbeginn 00:00 Uhr zu senden oder 06:00 Uhr? 2023-12-14 15:39:07 Sehr geehrter Fragesteller, anbei die Antworten zu Ihren Fragen: 1.) Das Format folgt bezgl. des Gültgkeitsbeginns immer der durch die BNetzA genehmigten Veröffentlichung. Dies muss nicht zwingend immer der 1. Januar eines Jahres sein 2.) Die Gültigkeit eines Preisblattes ist unabhängig vom Vertragsbeginn sondern ändert sich nur bei Preisblattänderungen. Sofern ein Lieferant noch kein Preisblatt erhalten hat, bekommt er dieses im Rahmen der Aufnahme der MaKo bzw. des zugehörgen Kommunikationsprozesses zugesendet 3.) Uns ist keine Vorgabe bekannt, die eine Uhrzeit 0 der 6 Uhr verbindlich vorgibt. Freundliche Grüße, Ihr BDEW-Forum Datenformate Ja Thomas Seipt Klaus Keller Thomas Seipt Alexander Koslowski Netznutzungsvertrag §6 "Eine Anpassung der Netzentgelte sowie der Entgelte für den Messstellenbetrieb auf Grundlage dieses Vertrages erfolgt immer zum 1. Januar eines Kalenderjahres..." Nein -------------Klaus Keller-------------15.12.2023 06:54 Vorschläge an Thomas zur Prüfung gesendet -------------Thomas Seipt-------------15.12.2023 12:44 Kurzfrage und Kurzantwort ergänzt. -------------Klaus Keller-------------18.12.2023 07:17 Veröffentlichung 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
INVOIC / REMADV AHB - informatorische Lesefassung 2.5c Abgeschlossen Gibt es eine Vorgabe, Rechnungspositionen bei gleitender Nachberechnung zur Vermeidung von Rundungsdifferenzen zusammenzufassen? Nein, ob eine zusammenfassende Position oder mehrere einzelne Positionen übertragen werden, obliegt dem Rechnungsersteller. 29.11.2023 2023-02015 Wir nehmen hier Bezug auf die Frage Ticket 2023-01802 Hier wird folgende Information gegeben: Die Rücknahmeposition muss exakt das zurücknehmen, was bisher abgerechnet wurde. Abweichungen zwischen Rücknahmeposition und den bisher in Rechnung gestellten Rechnungspositionen sind abzulehnen. Die BDEW geht lediglich auf die Rücknahme ein, d.h. auf die Auflistung der bisher gezahlten Beträge. Diese nehmen wir laut ihnen auch korrekt zurück, da wir genau das zurücknehmen, was abgerechnet und vom Lieferanten bezahlt wurde. Bei der Neuberechnung der einzelnen Monate (Januar 2023 – Juni 2023) ziehen wir den gleichen Rechenweg heran, d.h. wir berechnen jeden Monat einzeln, der Betrag wird systemisch auf 2 Nachkommastellen gerundet und anschließend wird eine Summe aus allen vorhergehenden Zeiträumen gebildet. Somit gehen wir hier einen einheitlichen Weg bei Rücknahme und Neuberechnung, laut unserem Hersteller SAP ist die Zusammenfassung korrekt und in der Invoic können nicht mehrere Segmente der einzelnen Zeiträume aufgebaut werden. Der Marktpartner benennt hier den Ablehnungsgrund nach Entscheidungsbaumdiagramm 125 Laut unserem Systemhersteller müssen in solchen Fällen die jeweiligen Monate einzeln ausgegeben werden. Andernfalls ist die INVOIC rechnerisch nicht korrekt und ist mit A23 abzulehnen. Frage: Ist die Neuberechnung der einzelnen Zeiträume innerhalb der gleitenden Nachberechnung (innerhalb einer Monatsrechnung) aufgerundet hier falsch dargestellt in der Invoic wenn bei der Rücknahme identische Positionen auch zurückgenommen werden? Das Thema wurde bereits mehrfach mit dem Marktpartner diskutiert, wir erhalten aber hier immer wieder die gleichen Hinweis/Reklamation von einzelnen Marktpartner, die Masse kann die Invoic so verarbeiten, daher benötigen wir bitte eine Bezugnahme auch auf die einzelnen Zeiträume innerhalb der gleitenden Nachberechnung. Danke schön 2023-11-29 08:00:45 Sehr geehrte Fragestellerin, nach unserem Verständnis zielt Ihre Fragen auf die möglichen Rundungsdifferenzen bei folgenden, möglichen Vorgehsweisen bei der gleitenden Nachberechnung: Variante 1 Januar: 1.1.2023 bis 1.2.2023: x kWh * y €/kWh = z €   Februar: 1.1.2023 bis 1.2.2023: - x kWh * y €/kWh = - z € 1.1.2023 bis 1.2.2023: x kWh * y €/kWh = z € 1.2.2023 bis 1.3.2023: x1 kWh * y €/kWh = z1 €   März: 1.1.2023 bis 1.2.2023: - x kWh * y €/kWh = - z € 1.2.2023 bis 1.3.2023: - x1 kWh * y €/kWh = - z1 € 1.1.2023 bis 1.2.2023: x kWh * y €/kWh = z € 1.2.2023 bis 1.3.2023: x1 kWh * y €/kWh = z1 € 1.3.2023 bis 1.4.2023: x2 kWh * y €/kWh = z2 €   Variante 2   Januar: 1.1.2023 bis 1.2.2023: x kWh * y €/kWh = z €   Februar: 1.1.2023 bis 1.2.2023: - x kWh * y €/kWh = - y € 1.1.2023 bis 1.3.2023: x + x1 kWh * y €/kWh = y1 €   März: 1.1.2023 bis 1.3.2023: - (x + x1) kWh * y €/kWh = - y1 € 1.1.2023 bis 1.4.2023: x + x1 + x2 kWh * y €/kWh = y2 €   Aus unserer Sicht kann die Prüfung bei Variante 1 nicht genauso erfolgen wie bei Variante 2. D. h. eine Prüfung ob:  Menge * Preis = Betrag  muss je nach gewählter Variante auf Summen- oder Einzelpositionsebene je gewähltem Rechnungszeitraum erfolgen. Freundliche Grüße, Ihr BDEW-Forum Datenformate Ja Klaus Keller Stefan Seidel Stefan Seidel Tatjana Jusupoglu-Ellmer Nein -------------Klaus Keller-------------05.12.2023 12:34 verstehe die Frage nicht, Rückfrage an Herrn Seidel ob er damt zurecht kommt !? -------------Klaus Keller-------------08.12.2023 08:20 nach Infos von Thomas Seipt und Stefan Seidel einen Antwortvorschlag entworfen -------------Klaus Keller-------------12.12.2023 10:48 Veröffentlichung nach Freigabe von Seidel/Seipt Nein Nein
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
AS4-Profil 1.0 Eingegangen Ist es explizit ausgeschlossen, dass bei einem Path Change PayLoads in der Nachricht enthalten sind? Der Aufruf des Service Wechsel des Übertragungsweg darf eine Übertragungsdatei enthalten. 03.11.2023 2023-01981 Ist es explizit ausgeschlossen, dass bei einem Path Change PayLoads in der Nachricht enthalten sind? 2023-11-03 10:29:00 Sehr geehrter Fragesteller, vielen Dank für Ihre Anfrage. Die Antwort findet sich in der BDEW FAQ zu AS4: Der Aufruf des Service darf, muss aber keine Übertragungsdatei beinhalten. Wenn eineÜbertragungsdatei übermittelt wird, muss diese signiert und verschlüsselt sein. Eine gegebenfallsvorhandene Übertragungsdatei muss ignoriert werden. Freundliche Grüße Ihr Forum Datenformate Ja Rene Hoffmann Rene Hoffmann Dirk Katzenbach Gerrit Müller 2.3.7 AS4 Transmission Path Change ... Die zwischen Partei A und Partei B ausgetauschten Nachrichten MÜSSEN keine Nutzdaten enthalten. .... Nein -------------Dirk Katzenbach-------------14.02.2024 11:26 Nein Nein
AS4-Profil 1.0 Eingegangen Welche Art von SOAP-Message ist bei Patch Switches zu unterstützen? Es sind beide Ausprägungen der SOAP-Message zulässig. 02.11.2023 2023-01979 Welche Art von SOAP-Message ist bei Patch Switches zu unterstützen? "SOAP with Attachments/Multipart" und/oder "Simple-SOAP/kein Multipart"? Gemäß "2.2.3 Nachrichtenverpackung" ist wie bei allen anderen Nachrichten auch "SOAP with Attachments/Multipart" zu verwenden (gemäß Grafik). "2.2.3.2 Payload" liest sich aber so, dass bei Patch Switches auch Simple-SOAP/kein Multipart unterstützt werden muss, da Patch Switches keinen Payload haben. 2023-11-02 09:17:01 Sehr geehrter Fragesteller, vielen Dank für Ihre Anfrage. Es sind beide Ausprägungen der SOAP-Message zulässig und müssen unterstützt werden. Freundliche Grüße Ihr Forum Datenformate Ja Rene Hoffmann Rene Hoffmann Dirk Katzenbach Thomas Beckers BDEW AS4-Profil 1.0: -> 2.2.3 Nachrichtenverpackung -> 2.2.3.2 Payload Nein -------------Dirk Katzenbach-------------14.02.2024 11:22 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
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
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
NetworkConstraintDocument FB 1.1 Abgeschlossen In welcher Kombination werden die Zeitreihen im NetworkConstraintDocument angegeben? Es sind die Zeitreihen für genau eine Flexibilitätsbeschränkung anzugeben; eine oder maximal zwei A77-Zeitreihen (für beide directions) und mindestens eine dazugehörige B59-Zeitreihe. 12.06.2023 2023-01791 In der Formatbeschreibung bzw. der Anwendungstabelle gibt es textliche Unstimmigkeiten bei der Referenzierung des Businesstypes von dem RessourceObject aus. Was ist der korrekte Aufbaue des Dokuments? Eine Zeitreihe mit Businesstype B59, wo die Ressourceobjects die zeitaufgelösten, engpassbestimmenden Netzelemente angegeben sowie beliebig viele Zeitreihen mit Businesstype A77, wo die Ressource Objects die vom Engpass betroffenen SRs und die entsprechende Einschränkung angeben? 2023-06-12 13:55:12 Sehr geehrter Fragesteller, es sind die Zeitreihen für genau eine Flexibilitätsbeschränkung anzugeben. Bei der Meldung einer Flexibilitätsbeschränkung ist für die mögliche Leistungsänderung am Netzbetriebsmittel eine oder ggf. maximal zwei A77-Zeitreihen (für beide directions) anzugeben. Dazu müssen die entsprechenden, dazugehörige B59-Zeitreihen angegeben werden. Hiervon müssen soviel Sensitivitätszeitreihen angegeben werden, wie Ressourcen eine Sensitivität auf das Netzbetriebsmittel haben, aber mindestens eine Zeitreihe.  Freundliche Grüße, Ihr BDEW-Forum Datenformate   Ja Thomas Fellhauer Johannes Umbach Thomas Fellhauer Chris Kittl Element RessourceObject: "Es ist der Identifikator des Netzbetriebsmittel (bei BusinessType A77) bzw. der Steuerbaren Ressource|Cluster Ressource|Steuergruppe (bei BusinessType B59) anzugeben, für welche die Zeitreihen gemeldet werden." Businesstype: "A77 Production, dispatchable B59 Network Element" Nein Vorbereitet für Abstimmung in PG -------------Johannes Umbach-------------06.02.2024 21:54 Besprochen, kann veröffentlicht werden -------------Vanessa Stemplowsky-------------07.02.2024 09:27 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
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
Stammdaten AWT 1.2 Abgeschlossen Muss Bilanzkreis_anfNB angegeben werden? In 2 Use-Cases muss Bilanzkreis_anfNB angegeben werden. 03.02.2023 2023-01648 Hallo, im Stammdaten FB 1.2 (S. 29) wird das Element Bilanzkreis_anfNB mit Typ Bilanzkreis angegeben (laut Stammdaten xsd 1.2 string length 16). In der Stammdaten AWT 1.2 (S. 41) ist Bilanzkreis_anfNB weder erforderlich noch optional. Ist Bilanzkreis_anfNB anzugeben? mfG 2023-02-03 15:52:43 Sehr geehrte/r Fragesteller/in   in der Stammdaten AWT 1.2 bei Bilanzkreis_anfNB in dem Use-Case "Übermittlung Stammdatenänderung zu Bilanzkreisen für die Ausgleichsfahrpläne vom (Anschluss-)NB (verantwortlich) ausgehend" (S.41) sowie "Übermittlung von Stammdaten zu Bilanzkreisen für die Ausgleichsfahrpläne" steht in allen Use-Case Schritten ein "x". Das bedeutet, dass dieses Element dort angegeben werden muss.   Mit freundlichen Grüßen Ihr BDEW-Forum Datenformate Ja Sara Olszewski Alexander Kramer Sara Olszewski Frank Salm Nein Antwortvorschlag zur Besprechung in PG -------------Sara Olszewski-------------14.02.2023 13:52 Passt in PG -------------Vanessa Stemplowsky-------------07.02.2024 10:45 Nein Nein
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
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 &gt; 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änderungsgeschwindig­keit innerhalb des Leistungsbereiches zwischen Mindesterzeugungs­leistung und Nennleistung bei Leistungserhöhung, abgeleitet aus der Zeitdauer der Leistungsänderung zwischen Mindesterzeugungsleis­tung und Nennleistung, zu verstehen. Die Mitteilung ist nur bei Last­gradienten 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?