|
UTILMD AHB Strom 2.0
|
In Bearbeitung
|
Wann wir im "Lieferende von NB an LF" im BGM der Code E02 bzw. Z90 verwendet?
|
Die Verwendung der Codes ergibt sich aus dem UC und dem Hinweis an dem Codes im AHB |
23.08.2024
|
2024-02309 |
|
|
Guten Tag,
im BGM Segment sind zwei Qualifier vorgesehen:
E02 Abmeldung
Z90 Beendigung der Zuordnung zur Lokation.
Mir ist nicht klar wann, bzw. an welcher Stelle im Prozess der Qualifier Z90 zu verwenden ist.
Viele Grüße
|
2024-08-23 11:25:05 |
Sehr geehrter Marktteilnehmer,
Der PID 55007 "Abmeldung / Beedigung der Zuordnung" wird im UC "Lieferende von NB an LF" in zwei Sequenzschritten verwendet. (Siehe hierzu auch in den Anwendungsübersicht der Prüfidentifikatoren)Dies sind Schritt 1 und Schritt 3. Die Verwendung spiegelt sich in den Hinweisen an den Codes.BGM DE1001 = E02 Abmeldungen [712][712] Hinweis: Wenn die Aktion "Ankündigung der Beendigung der Zuordnung des LF zur Marktlokation bzw. Tranche" durchgeführt wird
Dies entspricht dem Schritt 1 in dem UseCase
BGM DE1001 = Z90 Beedigung der Zuordnung zur Lokation [713][713] Hinweis: Wenn die Aktion "Beendigung der Zuordnung des LF zur Marktlokation bzw. Tranche aufgrund fehlender Antwort" durchgeführt wirdDies entspricht dem Schritt 3 in dem UseCase.
Viele Grüße
Ihre BDEW OG EDI@Energy |
Ja
|
Holger Weickenmeier |
Sara Olszewski |
Holger Weickenmeier |
Anke Mandrella |
S. 183
8.10Abmeldung durch den NB an LF
Prüfidentifikator 55007 - Abmeldung / Beendigung der Zuordnung
BGM-Segment
|
Nein
|
-------------Holger Weickenmeier-------------23.08.2024 15:07
ok. Schritt 3 ist durchzuführen, wenn Schritt 1 (die Antwort) fehlt
-------------Jessica Rahn-------------26.08.2024 09:50
|
Nein
|
Nein
|
|
Regelungen zum Übertragungsweg 1.7
|
Eingegangen
|
Muss AES-CBC bei Kommunikationsproblemen mit AES GCM genutzt werden?
|
Innerhalb des Umstellungszeitraumes muss der Bestandsalgorithmus AES-CBC angeboten werden. |
08.08.2024
|
2024-02290 |
|
|
Sehr geehrte Damen und Herren,
wir erhalten von mehreren Marktpartnern Email Nachrichten, die mit dem ab 01.08.2024 zulässigen Verschlüsselungsalgorithmus AES-GCM verschlüsselt sind. Die Nachrichten vieler Marktpartner können korrekt entschlüsselt werden. Die Nachrichten anderer Marktpartner können nicht entschlüsselt werden. Der Marktpartner möchte oder kann aber nicht auf das alte Verschlüsselungsverfahren zurück wechseln.
Wie ist hier zu verfahren?
Viele Grüße
|
2024-08-08 10:35:29 |
Sehr geehrter Fragesteller,
In der Zeit vom 01.08.2024 bis zur verpflichtenden Nutzung von AES-GCM sind beide Verschlüsselungsalgorithmen, AES-CBC und AES-GCM, zu unterstützen. Der Zeitraum dient der Erprobung der Interoperabilität der Lösungen bei den Marktpartnern. Im Falle einer Störung muss daher in dieser Phase auf die funktionierende Bestandslösung, AES-CBC, gewechselt werden.
Freundliche GrüßeIhr Forum Datenformate |
Ja
|
Rene Hoffmann |
Sven Schillack |
Dirk Katzenbach |
Gregor Scholtyschik |
|
Nein
|
-------------Dirk Katzenbach-------------08.08.2024 10:36
|
Nein
|
Nein
|
|
APERAK / CONTRL AHB 2.4
|
Abgeschlossen
|
Wie kann die Sparte einer Nachricht unterschieden werden ?
|
Die Sparte wird anhand der MP-ID unterschieden. |
23.07.2024
|
2024-02270 |
|
|
Guten Tag.
Mit Einführung der APERAK-Anerkennungsmeldung in der Strom-Sparte ab dem 04.04.2025 kann es zwecks korrekter Behandlung einer Übertragungsdatei nötig sein, die Sparten Strom und Gas anhand des Inhalts dieser Übertragungsdatei unterscheiden zu müssen.
Daher möchten wir fragen, ob es eine Festlegung gibt/geben wird, die die heranzuziehenden Kriterien beschreibt, mit denen stets eine solche Unterscheidung möglich ist.
Beispiel: Unterscheidung anhand des Qualifiers im UNB-Datenelement S003:0007, wobei sich da die Frage anschließen würde, wie eine Sparten-Unterscheidung bei Angabe eines GS1-Codes erfolgen würde.
Vielen Dank
|
2024-07-23 14:10:51 |
Sehr geehrter Fragesteller,
diese Unterscheidung kann nur anhand einer MP-ID-Tabelle erfolgen, da wie bereits richtig von Ihnen erkannt, der Code hinter der MP-ID nur bedingt aussagefähig ist.
Es sind bereits vor Einführung der APERAK-Anerkennungsmeldung zahlreiche spartenabhängige Bedingungen in den Nachrichtenformaten enthalten, deren Prüfmechanismus hier identisch zur Anwendung kommen muss.
Freundliche Grüße,
Ihr BDEW-Forum Datenformate |
Ja
|
Klaus Keller |
Stefan Seidel |
Stefan Seidel |
Marcus Völker |
|
Nein
|
-------------Klaus Keller-------------23.07.2024 17:08
Vorschläge formuliert und an Herrn Seidel zur QS gesendet
-------------Stefan Seidel-------------31.07.2024 21:55
veröffentlicht |
Nein
|
Nein
|
|
PRICAT AHB 2.0d
|
Abgeschlossen
|
Was ist die Vorgängerversion einer PRICAT?
|
Die gestrichelte Pfeilspitze zeigt auf die Vorgängerversion. |
18.07.2024
|
2024-02265 |
|
|
Liebe Experten-Gruppe,
trotz der Darstellung in Kapitel 4 des PRICAT-AHB gibt es leider am Markt immer noch Unklarheiten dazu, wie die Vorgänger-Referenz bei den elektronischen Preisblättern anzugeben ist. Da wir als Versender des Preisblatts (Netznutzungsabrechnung Strom) Reklamationen mehrerer Lieferanten vorliegen haben, möchten wir Sie um eine Aufklärung und Ausräumung des Interpretationsspielraums bitten.
Die abweichende Interpretation bezieht sich auf die unterschiedlichen Pfeile (durchgezogene und gestrichelte Linien) und die Beschreibung in der zugehörigen Legende. Insbesondere bei Preisblatt 5., das mit dem Gültigkeitsbeginn vor den zuletzt versendeten Preisblättern liegt (und bei dem als einziges die Pfeile mit gestrichelten und durchgezogenen Linien voneinander abweichen).
Die Legende beschreibt die Pfeile mit durchgezogenen Linien folgendermaßen:
"Zeigt auf, wie sich auf Basis des Gültigkeitsbeginns der zu versendenden aktualisierten PRICAT (Pfeilanfang) die Nachricht bestimmen lässt, die im Segment "Vorgängerversion" anzugeben ist (Pfeilspitze)."
Strittig ist im Grunde, welche Nachricht an der Pfeilspitze abzulesen ist.
Interpretation A:
Die Pfeilspitze zeigt auf die Vorgänger-Nachricht. Als Nachricht wird hier die Zeile / der Balken im Diagramm angesehen. D.h. jede Nachricht gibt die jeweils vorher versendete PRICAT als Vorgänger an. PRICAT 6 verweist auf 5, PRICAT 5 auf 4, usw.
Interpretation B:
Die an der Pfeilspitze abzulesende Nachricht wird nicht durch die Zeile im Diagramm, sondern durch die PRICAT vorgegeben, die für diesen Zeitpunkt gültig ist. Im Diagramm lässt sich das anhand der unterschiedlichen Farben erkennen. PRICAT 5 liegt mit dem Gültigkeitsbeginn im Zeitraum, der dunkelorange dargestellt ist. Die zugehörige Nachricht ist PRICAT 2, die als Vorgängerreferenz anzugeben ist. Also genau das, was mit den Pfeilen mit gestrichelter Linie dargestellt ist.
Die Darstellung des Diagramms finde ich gut und übersichtlich. Eine Anpassung des Texts in der Legende könnte ausreichen, um derartige Fehlinterpretationen zu vermeiden.
Für den Fall der Interpretationsvariante B zeigt die gestrichelte Linie auf die Nachricht, "... die im Segment Vorgängerversion anzugeben ist".
Besten Dank vorab für eine Aufklärung. Bei Rückfragen stehe ich natürlich gerne zur Verfügung.
|
2024-07-18 11:10:59 |
Sehr ggehrte Damen und Herren,
der gestrichelte Pfeil zeigt auf die Vorgängerversion, die in der neuen Pricat anzugeben ist.
In Ihrem Beispiel muss die PRICAT mit der Versionsnummer 5 auf die PRICAT mit der Versionsnummer 2 verweisen.
Freundliche Grüße
Ihr Forum Datenformate |
Ja
|
Thomas Seipt |
Klaus Keller |
Thomas Seipt |
Matthias Räder |
PRICAT AHB 2.0d Kap. 4 Erläuterung zur Nutzung des RFF-Segments „Vorgängerversion“ (Stand 11.03.2024) |
Nein
|
Antwortvorschlag hinterlegt. Da ich bei eienr 50/50 Frage in der Regel falsch liege, bitte die Antwort noch mal kritisch prüfen.
-------------Thomas Seipt-------------24.07.2024 16:58
Veröffentlichung
-------------Klaus Keller-------------26.07.2024 07:31
|
Nein
|
Nein
|
|
INVOIC MIG 2.8c
|
Abgeschlossen
|
Welche Artikel-IDs dürfen im Rechnungstyp SOR verwendet werden ?
|
Es sind nur die Werte aus dem Dokument "Codeliste der Artikelnummern und Artikel-ID" mit Kennzeichnung "SOR" in der Spalte "INVOC/Codeverwendung" in der sog. Vorwärtsposition einsetzbar. |
05.07.2024
|
2024-02251 |
|
|
Im neuen Rechnungstyp SOR besteht mit dem Grund Z02 im GEI-Segment die Möglichkeit seit dem Abrechnungsjahr 2023 die Berücksichtigung der atypischen Netznutzung abzurechnen. Wir erhalten von Marktpartner hierzu nun Rechnungen vom Typ SOR, bei denen nicht die Artikel der Gruppenartikel-ID 1-07-1 enthalten sind. Es sind die "normalen" Artikel der zugehörigen Spannungsebenen, z. B bei Mittelspannung mit Gruppenartikel-ID 1-01-5 enthalten. Ist dies zulässig?
Vielen Dank
|
2024-07-05 11:57:19 |
Sehr geehrter Fragesteller,
der jeweils aktuell gültigen „Codeliste der Artikelnummern und Artikel-ID“ (zur Zeit: Version 5.5) können über die Kennzeichnung mit dem Inhalt „SOR“ in der Spalte „INVOIC / Codeverwendung“ die für die Verwendung in der SOR-Rechnung zulässigen Artikel-IDs entnommen werden, mit denen Leistungen in Rechnung gestellt werden können. Darüber hinaus dürfen die Artikel-ID, nur die fachlich zu einer derartigen in der SOR vorhandenen Artikel-ID fachlich korrespondieren enthalten sein, die die entsprechende Menge aus der referenzierten Rechnung zurücknehmen (sie stellen die sog. Rücknameposition dar).
Für die von Ihnen beispielhaft genannte Gruppenartikel-ID „1-01-5“ (= Mittelspannung) bzw. die entsprechend dazugehörigen Artikel-ID gibt es keine fachlich korrespondierende Artikel-ID mit dieser Kennzeichnung, daher dürfen diese in der Folge in einer „SOR-Rechnung“ nicht verwendet werden.
Wir erlauben uns an dieser Stelle den Hinweis, dass eine Gruppenartikel-ID niemals Bestandteil einer SOR-Rechnung (wie auch keines anderen Rechnungstyps) sein kann. Ein Beispiel für eine in einer SOR-Rechnung zulässige Artikel-ID wäre die Artikel-ID „1-08-6-001“ (= Für Marktlokationen deren (Teil-)Menge von der Konzessionsabgabe befreit ist), die die vorgenannte Kennzeichnung „SOR“ explizit aufweist.
Freundliche Grüße,
Ihr BDEW-Forum Datenformate |
Ja
|
Klaus Keller |
Stefan Seidel |
Stefan Seidel |
Michael Schimmer |
|
Nein
|
-------------Klaus Keller-------------08.07.2024 07:25
Antwortvorschlag von Gero eingefügt und um Kurzfrage/-antwort ergänzt
-------------Stefan Seidel-------------08.07.2024 08:31
kleine Anpassung durchgeführt
-------------Stefan Seidel-------------10.07.2024 07:55
Korrektur durchgeführt |
Nein
|
Nein
|
|
INVOIC MIG 2.8c
|
Abgeschlossen
|
Welche Arten der Sonderrechnungen können gestellt werden?
|
Es können nur für die Fälle Sonderrechnungen gestellt werden, die über Codes im GEI-Segment spezifiziert sind |
26.06.2024
|
2024-02244 |
|
|
Bei "Art der Sonderrechnung" fehlen aus unserer Sicht Fälle für Korrektur von Konzessionsabgabe für weiterverteilte Mengen. Welche Kennzahl (Z01 bis Z09) soll dafür verwendet werden? Durch die Zusätze in Klammern sind die Fälle Z01 und Z08 zu spezifisch definiert. Auf mehrere SOR INVOIC mit Kennzahl Z01 (Konzessionsabgabe (Testat)) erhielten wir neg. REMADV mit Forderung zur Übermittlung eines Testats.
|
2024-06-26 15:21:07 |
Sehr geehrter Marktteilnehmer,
es können ausschließlich für die Fälle, für die Codes im GEI-Segment vorhanden sind, Sonderrechnungen zur Korrektur der entsprechenden Positionen bereits gelegter Rechnungen durchgeführt werden.Wenn Sie den Code Z01 nutzen, ohne dass Ihnen der LF ein Testat vorgelegt hat, dem zu entnehmen ist, dass an der von ihm belieferten Marktlokation keine Konzessionsabgabe im vorherigen Kalenderjahr zu bezahlen war, weil an der Marktlokation die Voraussetzungen nach §2 (4) KAV vorliegen, dann wird Ihnen eine derartige Sonderrechnung berechtigterweise abgelehnt. Entsprechend des durch die BK6 festgelegten Prozess Netznutzungsabrechnung können Sie Korrekturen an der Konzessionsabgabe für weiterverteilte Mengen (weil die bisher angerechneten Mengen andere sind, als die die abzurechnen gewesen wären (so interpretieren wir zumindest Ihre Problembeschreibung)) nur durch Stornieren der Rechnungen, anschießender Anpassungen und Erstellen neuer Netznutzungsrechnungen durchführen.
Mit freundlichem Gruß,
Ihr BDEW-Forum Datenformate |
Ja
|
Klaus Keller |
Stefan Seidel |
Klaus Keller |
Heiko Teichmeier |
S.23, GEI, 9649, C012, 7365 (Verarbeitungsindikator, Code); Z01 bis Z09 |
Nein
|
-------------Stefan Seidel-------------26.06.2024 16:54
Vorschlag ohne Kurz-Frage und -Antwort erstellt
-------------Stefan Seidel-------------27.06.2024 07:46
gemeldete Tippfehler korrigiert Kurz-Frage und -Antwort erstellt
-------------Klaus Keller-------------05.07.2024 09:17
Veröffentlichung
|
Nein
|
Nein
|
|
INVOIC / REMADV AHB 2.5d
|
Abgeschlossen
|
Warum wurde für die REMADV ein vierstelliger Segmentzähler mit Präfix "R" eingeführt ?
|
Zur Gewährleistung der EIndeutigkeit im INVOIC/REMADV-AHB wurde bei der REMADV das "R" vorangestellt. |
27.06.2024
|
2024-02245 |
|
|
Wie verargumentieren sie den Bruch mit dem definierten Layout den Segmentzähler der REMADV Vorgänge nicht als "n5" anzugeben? Stattdessen wird "Rn4" (ein großes R gefolgt von 4 Ziffern) verwendet.
|
2024-06-27 13:42:38 |
Sehr geehrter Marktteilnehmer,
uns ist keine Layoutvorgabe bekannt, gegen die hier verstoßen wurde.
Gerne erläutern wir Ihnen den Grund des Präfixes "R" bei der REMADV. Bei der Aufnahme der Segmentzähler in die AHB ist aufgefallen, dass in AHB mit mehren Nachrichtenarten die Eindeutigkeit nicht gewährleistet werden kann, wenn jede Nachricht den gleichen Nummernkreis verwendet. Daher wurde die INVOIC wie bisher belassen und bei der REMADV zu Gewährleistung der Eindeutigkeit das "R" vorangestellt.
Freundliche Grüße,
Ihr BDEW-Forum Datenformate |
Ja
|
Klaus Keller |
Stefan Seidel |
Stefan Seidel |
Stefan Demary |
https://www.edi-energy.de/index.php?id=38&tx_bdew_bdew%5Buid%5D=2365&tx_bdew_bdew%5Baction%5D=download&tx_bdew_bdew%5Bcontroller%5D=Dokument&cHash=706e90400d7ce298ce921dc496546b55#page=61 |
Nein
|
-------------Stefan Seidel-------------27.06.2024 14:00
Vorschlag erstellt
-------------Klaus Keller-------------05.07.2024 09:27
Kurzfrage und -antwort erstellt, Hauptantwort etwas diplomascher formuliert, um den "frech" Fragenden "freundlich" abzuholen, hier nochmal der alte Stand zum Vergleich:
"zum einen gibt es keine Vorgabe, dass der Segmentzähler irgendeinem Format zu genügen hätte und zum anderen hilft genau dieses Vorgehen, dass man immer das richtige Segment in der REMADV im AHB angezeigt bekommt, wenn man sich dessen Segmentzähler aus der REMADV MIG kopiert hat. Andernfalls bekäme man auch das nicht gesuchte Segment in der INVOIC an vielen Stellen des AHB angezeigt bekäme."
-------------Stefan Seidel-------------05.07.2024 11:23
passte für mich und daher veröffentlicht |
Nein
|
Nein
|
|
MSCONS AHB 3.1d
|
Abgeschlossen
|
Mit welchem PID werden Werte für den ESA übermittelt?
|
Es ist der PID 13027 zu verwenden. |
31.05.2024
|
2024-02223 |
|
|
An diversen Stellen werden im MSCONS AHB die berechtigten Stellen für die Prüfidentifikatoren von Messwerten (z.B. SG10 QTY 6063 S. 74) genannt. Die Rolle ESA ist dort nicht aufgeführt, obwohl prinzipiell diese MSCONS PID auch an ESA gesendet werden. Liegt hier eine Inkonsistenz im AHB vor?
|
2024-05-31 14:15:09 |
Sehr geehrter Marktteilnehmer,
der ESA erhält die vereinbarten Werte mit dem PID 13027 „Werte nach Typ 2“. Da es sich in der Regel um kostenpflichtige Werte handelt, muss z.B. in diesem Anwendungsfall auch die Referenz auf die Bestellung (ORDERS) mitgegeben werden. Nur so ist nachvollziehbar wieso die Werte versendet wurden.
In dem EDI@Energy Dokument Anwendungsübersicht der Prüfidentifikatoren ist die Zuordnung des Anwendungsfalls zum Prozessschritt dokumentiert.
Freundliche GrüßeIhr Forum Datenformate
|
Ja
|
Reinhard Döring |
Thomas Seipt |
Beate Becker |
Philipp Nagel |
S. 74 |
Nein
|
Antwortvorschlag erstellt und zur Diskussion gestellt.
-------------Thomas Seipt-------------31.05.2024 16:12
|
Nein
|
Nein
|
|
UTILMD AHB Strom 1.2a
|
Abgeschlossen
|
Können mehrere TRs angegeben werden, wenn im AHB diese auf eine eingeschränkt ist, das MIG aber eine Wiederholung zulässt?
|
Im MIG ist die max. Wiederholbarkeit definiert, welche im AHB durch Bedingungen präzisiert werden kann |
10.05.2024
|
2024-02203 |
|
|
Guten Tag,
wir bräuchten bitte eine Klarstellung, ob in einer UTILMD mit Prüfi 55112 das LOC+Z20 mit der Angabe der Technischen Ressource mehrfach genannt werden kann.
Im AHB steht an der Stelle die Bedingung [2061] Segment bzw. Segmentgruppe ist genau einmal je SG4 IDE (Vorgang) anzugeben (siehe Seite 63 UTILMD AHB Strom 1.2a Konsolidierte Lesefassung)
In der MIG steht zur Technischen Ressource das "Ein Vorgang mehrere Technische Ressourcen enthalten kann. Dies ist z. B. dann der Fall, wenn eine Marktlokation mehrere Technische Ressourcen enthält." (siehe Seite 84 UTILMD MIG Strom S1.1a Konsolidierte Lesefassung)
Auch die angegebene Wiederholbarkeit spricht dafür. Wir fassen das so auf, dass eine UTILMD theoretisch 999.999 LOC+Z20 enthalten kann solange die jeweils angegebene ID eindeutig und einmalig ist.
Wir haben da gerade eine große Disskussion mit einigen Marktpartnern, die unsere UTILMD mit mehreren Tech. Ressourcen kategorisch mit einer APERAK Z40 Segment- bzw. Segmentgruppenwiederholbarkeit überschritten ablehnen.
Vielen Dank im Voraus.
Beste Grüße
Stefanie Kruse
|
2024-05-10 12:53:36 |
Sehr geehrte Frau Kruse,
in der Nachrichtenbeschreibung (MIG) ist die maximale Wiederholbarkeit eines Segmentes definiert. Dies kann durch das AHB je Anwendungsfall weiter eingeschränkt werden. Siehe hierzu auch im Dokument "Allgemeine Festlegungen" Kapitel 6.2:
Die maximale Wiederholbarkeit der Segmentgruppen und Segmente ist in den Nachrichtenbeschreibungen(MIG) definiert. Für die Nachrichten im deutschen Energiemarkt finden hierzu dieInhalte der Spalten „BDEW“ (MIG-Spalte „MaxWdh / BDEW“ und „BDEW MaxWdh“) und der Status (MIG-Spalte „ST / BDEW“ und „BDEW ST“) Anwendung (MIG-Status). Eine weitere Präzisierungerfolgt im jeweiligen Anwendungsfall durch die Nutzung von Statusangaben (AHB Status)und ggf. Bedingungen in der Spalte „Bedingung“ des jeweiligen Anwendungsfalls.
Wenn eine höhere Wiederholbarkeit eines Segmentes, obwohl dies durch eine Bedingung eingeschränkt ist, aufgrund der Nachrichtenstrukutur im MIG möglich wäre, wären alle Bedingungen im AHB, welche die Wiederholbarkeit im Anwendungsfall präzisieren, unnötig. Die Wiederholbarkeit und damit die zulässige Anzahl von Segmenten ist im AHB je Anwendungsfall mit Bedingungen aus dem Nummernkreis 2000-2499 beschrieben. Diese sind einzuhalten. Überschreitet die zulässige Anzahl der Wiederholungen, erfolgt eine Verarbeitbarkeitsfehlermelung mit dem APERAK Code Z40.In dem Anwendungsfall 55112 kann es durch die Bedingungen in den SG5 LOC nie mehr als ein SG5 LOC (gleich welchem Code) in einem Geschäftsvorfall geben. Somit kann dort nur ein SG5 LOC+Z20 (Technische Ressource) enthalten sein. Wenn ein SG5 LOC+Z20 vorhanden ist, dann kann auch kein anderes SG5 LOC z.B. LOC+Z16 (Marktlokation) enthalten sein. In diesem Anwendungsfall ist das LOC eindeutig. Viele Grüße Ihre BDEW Projektgruppe EDI@Energy |
Ja
|
Holger Weickenmeier |
Sara Olszewski |
Jessica Rahn |
Stefanie Kruse |
UTILMD AHB Strom 1.2a Konsolidierte Lesefassung
UTILMD MIG Strom S1.1a Konsolidierte Lesefassung |
Nein
|
-------------Holger Weickenmeier-------------27.05.2024 10:07
-------------Jessica Rahn-------------29.05.2024 15:40
|
Nein
|
Nein
|
|
APERAK / CONTRL AHB 2.3n
|
Abgeschlossen
|
Wie ist das Segment COM (Kommunikationsverbindung), bei Angabe einer Rufnummer, korrekt aufzubauen?
|
Bei einer Rufnummer im Segment COM beginnt die Rufnummer mit der internationalen Ländervorwahl in der Schreibweise, die das "+" nutz, d. h. für Deutschland mit +49 |
18.04.2024
|
2024-02184 |
|
|
Hallo,
seit der Umstellung der Formate im April dieses Jahres erhalten wir sehr viele Nachrichten, welche wir mit einer APERAK ablehnen. (im mittleren vierstelligen Bereich von mannigfaltigen Marktteilnehmern)
Der Grund der APERAK sind die Änderungen in den CTA / COM (Ansprechpartner/Kommunikationsverbindung) Segmenten.
Hier insbesondere die Formatbedingung [940]
[940] Format: Die Zeichenkette muss mit dem Zeichen + beginnen und danach dürfen nur noch Ziffern folgen
Folgend ein Beispiel, welches bei uns so überwiegend eintrifft. (anonymisiert)
CTA+IC+:NameAnsprechpartner'
COM+netznutzung@marktteilnehmer.de:EM'
COM+078271234567:TE'
Dieses Beispiel anhand TE = Telefon. Gleiches gilt auch für FX=Fax, AJ= weiteres Telefon und AL=Handy
Aus unserer Sicht müsste das COM Segment wie folgt aufgebaut sein, da wir aus der Formatbedingung [940] ableiten, dass eine Rufnummer nun in internationaler Schreibweise anzugeben ist.
COM+?+4978271234567:TE'
Wir haben nun vielfach die Diskussion, dass das erste „+“ welches die Trennung der Datenelementgruppen beschreibt, als „+“ für die Rufnummer gehalten wird. Somit wird unsere APERAK als unberechtigt zurückgewiesen.
Aus diesem Grund die Frage: Ist unsere Interpretation
COM+?+4978271234567:TE'
korrekt?
Weitere, aus unserer Sicht nicht korrekte Beispiele, welche aber über die APERAK überstehen, sind:
COM+?+78271234567:TE' (ohne Länderkennung)
COM+?+49078271234567:TE' (0 nach Länderkennung)
COM+?+078271234567:TE' (ohne Länderkennung mit 0)
|
2024-04-18 14:55:53 |
Sehr geehrter Marktteilnehmer,
es ist sicher unstrittig, dass die in eine EDIFACT-Nachricht genannten Telefon- (inkl. weiteres Telefon), Fax- und Handynummern wie angegeben nutzbar sein müssen und dafür sorgen, dass der in der EDIFACT-Nachricht genannte Ansprechpartner so erreicht wird. Das heißt im Detail, dass wenn man die in einer EDIFACT-Nachricht angebenden Zeichen des DE3148 nach dem die EDIFACT-Nachrichtendatei unter Beachtung der Standard-Trennzeichen-Vorgabe (so diese nicht vom Absender durch Nutzung des UNA-Segments verändert wurde, dann sind die so vom Absender für die EDIFACT-Übertragungsdatei definierten Trennzeichen in der Konvertierung zu nutzen) konvertiert wurde, in die Zwischenablage kopiert und anschließend in eine Telefon-App einfügt und anschließend dafür sorgt, dass diese App genau diese Nummer wählt, man bei den Ansprechpartner anruft.
Dass dies unstrittig ist, setzen wir im Weiteren voraus.
Die Segmentgruppe, in welcher das CTA / COM enthalten ist, ist wie folgt definiert. Hier am Beispiel eines Screenshots aus der UTILMD.
Aus der Definition im DE3148 gilt, dass bei Verwendung der Codes TE / FX / AJ / AL die in diesem Datenelement enthaltene Zeichenkette mit einem "+" beginnen muss und nur Ziffern folgen dürfen. Die Rufnummer ist in internationaler Schreibweise anzugeben. Aus diesem Grund beginnt diese mit einem "+" da auf dieses Zeichen Ländervorwahl nachgestellt wird. D. h. von den zwei Schreibweisen der internationalen Vorwahl für Deutschland, die entweder 0049 oder +49 lautet, lässt die Formatbedingung [940] eindeutig nur die Schreibweise +49 zu.
Dies geht aus der Beschreibung hervorX (([939] [321]) ∨ ([940] [322])) ∧ [514]
Dies führt zu dem Ergebnis, dass das von Ihnen genutzte Beispiel
COM+?+4978271234567:TE'
korrekt ist.
Da das "+" bei Nutzung der Standard-Trennzeichen-Vorgabe das Zeichen für die Segment-Bezeichner und Datenelement-Trennzeichen ist, muss man, um den String (= die Zeichenkette) "+4978271234567" korrekt im DE3148 übertragen zu können, deutlich machen, dass das "+" im String "+4978271234567" nicht, als Segment-Bezeichner und Datenelement-Trennzeichen zu interpretieren, sondern als "+" zu interpretieren ist. Dies erreicht man, in dem man unmittelbar vor diesem "+" das Freigabezeichen (im Standard ist das "?") einfügt.
An der Stelle möchten wir auch noch darauf hinweisen, dass ein Bespiel für den richtigen Aufbau des COM-Segments an der von Ihnen genannten Stelle, dem INVOIC MIG 2.8c vom 11.03.2024 entnommen werden kann, wobei in diesem die Standard-Trennzeichen-Vorgabe genutzt wird (wie bei allen Beispielen in allen EDI@Energy-Nachrichtenbeschreibungen) und das wie folgt lautet: COM+?+4922271020:TE'
Die von Ihnen angegebenen weiteren - nicht korrekten - Beispiele sind anhand der Beschreibung korrekt aufgebaut. Auch wenn diese sicherlich nicht funktionieren werden. Wie eingangs erläutert, sollte jeder seine Rufnummer kennen und unter Beachtung der Regeln für die Nutzung der internationalen Telefonvorwahl richtig angeben können. Diese Regeln sind sehr einfach im Internet zu finden.
Zum weiteren Studium der EDIFACT-Grundlagen, die hier offensichtlich vielfach ignoriert werden, empfehlen wir all ihren Marktpartnern das Studium der ISO 9735:1988 "Elektronischer Datenaustausch für Verwaltung, Wirtschaftund Transport (EDIFACT), Syntax-Regeln auf Anwendungsebene (ISO 9735:1988 + Amd 1:1992)".
Viele GrüßeIhr BDEW Forum Datenformate |
Ja
|
Klaus Keller |
Stefan Seidel |
Klaus Keller |
Holger Weickenmeier |
|
Nein
|
Frage ist aus unserem Haus. Ich habe mal einen Antwortvorschlag erstellt.
-------------Holger Weickenmeier-------------18.04.2024 14:56
Angepasst
-------------Stefan Seidel-------------18.04.2024 17:32
Veröffentlichung ohne Anpassungen
-------------Klaus Keller-------------19.04.2024 08:05
|
Nein
|
Nein
|
|
INVOIC / REMADV AHB 2.5c
|
Zur Abstimmung in PG
|
Beginn der Fälligkeitsberechnung für eine Mehr-Mindermengenrechnung ist nicht einheitlich vorgegeben?
|
Einhaltung der Bedingung 24 ist notwendig, um die fachliche Vorgabe zur Fälligkeit einhalte zu können (= Notwendige Bedingung) |
03.04.2024
|
2024-02167 |
|
|
Beginn der Fälligkeitsberechnung für eine Mehr-Mindermengenrechnung ist nicht einheitlich vorgegeben
|
2024-04-03 11:57:13 |
Sehr geehrter Marktteilnehmer,
Bedingungen, die in der AHB-Prüfung geprüft werden können, müssen so formuliert sein , dass sie sich auf in dem Geschäftsvorfall vorhandene (oder nicht vorhanden sein dürfende) Inhalte beziehen. Genau so ist die von Ihnen zitierte Bedingung 24 (aus dem Textbezug) formuliert. Darüber hinaus ist zu erkennen, dass diese Bedingung eine im Sinn der Logik notwendige Bedingung ist, um die fachliche Vorgabe erfüllen zu können, dass dem Rechnungsempfänger ab dem Zugang einer Forderung mindestens 10 WT zur Begleichung dieser zur Verfügung gestellt werden müssen. Dies illustrieren wir wie folgt: Ist der Rechnungssteller am Tag, an dem er die Rechnung erstellt in der Lage das Datum dieses Tages in DTM+137 DE2380 zu schreiben und für den Wert, den er in SG8 DTM+265 DE2380 schreibt, die Bedingung 24 einzuhalten und schafft er es auch noch diese Rechnung an diesem Tag an den Rechnungsempfänger zu übertragen, so ist automatisch die fachliche Vorgabe eingehalten (daher notwendige Bedingung). Sollte der Rechnungssteller aber beispielsweise nicht in der Lage sein eine Rechnung in der er als Fälligkeitsdatum das Tagesdatum plus 10 WT und als Nachrichtendatum das Tagesdatum eingetragen hat, an diesem Tag an den Rechnungsempfänger zu übertragen, sondern beispielsweise erst zwei Tage später, dann kann der Rechnungsempfänger diese Rechnung ablehnen, da ihm nicht die zustehenden 10 WT zur Begleichung der Forderung zur Verfügung gestellt wurden. Somit erkennt man, dass die Einhaltung der Bedingung 24 nicht immer ausreicht, um die fachliche Anforderung zu erfüllen; sie somit keine hinreichende Bedingung im Sinne der Logik ist.
Mit freundlichen GrußIhr BDEW-Forum Datenformate |
Ja
|
Klaus Keller |
Stefan Seidel |
Klaus Keller |
Barbara Schröder |
Das BDEW-Dokument „Prozesse zur Ermittlung und Abrechnung von Mehr-/Mindermengen Strom und Gas“ sieht im Use-Case 6.6.1 folgendes vor:
….. Die Rechnung wird in elektronischer Form erstellt. Das Zahlungsziel für NB bzw. MGV beträgt 10 Werktage bezogen auf den Rechnungseingang.
Das edi@energy-Dokument „INVOIC / REMADV Anwendungshandbuch“ sieht im Kapitel MMM-Rechnungen im Anwendungsfall mit Prüfidentifikator 31007 (NB an MGV) für das Segment SG8 DTM 2005 265 Fälligkeitsdatum in [24] folgenden Text vor:
…... Wert muss mindestens 10 WT nach Wert aus DTM+137 DE2380 liegen.
Gemeint ist hier das Nachrichtendatum.
Für die Berechnung des Zahlungsziels muss geregelt werden, welches Dokument ausschlaggebend ist.
Oder anders formuliert benötigen wir die Klärung, ob für die Berechnung des Zahlungsziels das Datum der Erstellung der INVOIC oder das Datum des Eingangs der INVOIC beim Marktpartner entsprechend der Prozessbeschreibung maßgeblich ist.
Vielen Dank im Voraus für die Klärung.
|
Nein
|
-------------Stefan Seidel-------------03.04.2024 12:25
Antwortvorschlag erstellt und Herrn Keller informiert.
Hinweis: Wenn man nur den Hauch von mathematischer Logik in seinem Kopf hat, stellt man diese Fragen nicht. Daher musste ich mich extrem über diese Frage ärgern. zumal sie bereits in der PG MMMA auftauchte, der eine Kollegin der Fragestellerin angehört.
-------------Amirhossein Forootanfard-------------23.04.2024 16:40
-------------Klaus Keller-------------13.05.2024 10:45
Ergänzung des Hinweises auf "Textbezug" - Freigabe durch AG RZ empfohlen, daher Status geändert
|
Nein
|
Nein
|
|
INVOIC / REMADV AHB 2.5c
|
Abgeschlossen
|
Was ist der Unterschied der beiden DTM-Segmente mit dem Code 137 in der REMADV ?
|
Das DTM-Segment im Kopf der Nachricht ist das Datum der REMADV, das DTM-Segment auf Positionsebene ist das Rechnungsdatum zum Forderungsbetrag. |
13.02.2024
|
2024-02107 |
|
|
Für das Format REMADV und die PIDs 33001/33002 gibt es 2x das Segment DTM+137, einmal als Dokumentendatum und ein zweites Mal als Rechnungsdatum. Ist das so korrekt?
|
2024-02-13 18:45:44 |
Sehr geehrter Fragesteller,
die Darstellung ist korrekt:
- da im Kopf einer EDIFACT-Nachricht immer per DTM+137 das Dokumentendatum der gesamten Nachricht angegeben wird
- da bei der REMADV auf Positionsebene zu jeder aufgeführten Rechnung neben der Rechnungsnummer und dem Forderungsbetrag auch das zugehörige Rechungsdatum zur Identifikation angegeben wird
Freundliche Grüße,
Ihr BDEW-Forum Datenformate |
Ja
|
Klaus Keller |
Stefan Seidel |
Stefan Seidel |
Thorsten Bruns |
INVOIC / REMADV Anwendungshandbuch, S.63, Rechnungsdatum SG5 DTM 2005 137 |
Nein
|
-------------Klaus Keller-------------14.02.2024 09:10
Antwortvorschlag erstellt
-------------Klaus Keller-------------14.05.2024 10:27
Veröffentlichung
|
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
|
|
INVOIC / REMADV AHB 2.5c
|
Abgeschlossen
|
Fehlerhafte Bedingungen in aktuellen AHB (2.5c) vorhanden ?
|
Ja, werden korrigiert |
15.12.2023
|
2023-02037 |
|
|
Für den Anwendungsfall 33004 (Abweisung Position) erscheinen mir die Bedingungen [42] ⊻ [96] den falschen Bezug zu haben. Ich denke es sollte SG12 anstatt SG7 heißen, da es in dem Anwendungsfall kein SG7 gibt. Für den Anwendungsfall 33003 passt der Bezug.
Außerdem erscheint mir die Änderung der Bedingung [88] Wenn in SG7 AJT DE1082 = E_0568 (anstatt bisher SG7 AJT DE4465= A25) nicht sinnvoll, da dann "([84] ⊻ [85] ⊻ [86]) ∧ [88])" nie zutreffen wird, wenn eine Liste von EBDs und ein bestimmtes anderes erfollt sein soll. Ist diese Änderung versehentlich erfolgt?
|
2023-12-15 12:30:54 |
Sehr geehrte Fragestellerin,
besten Dank für Ihre Hinweise, die in der nächsten Lesefassung korrigiert werden.
Freundliche Grüße,
Ihr BDEW-Forum Datenformate |
Ja
|
Klaus Keller |
Stefan Seidel |
Stefan Seidel |
Ina Czekalla |
AHB
Referenz auf COMDIS
Nähere Erläuterung des Abweichungsgrundes |
Nein
|
-------------Klaus Keller-------------20.12.2023 12:41
Änderungsanträge erstellt und Vorschlag an Herrn Seidel zu Prüfung gesendet
-------------Klaus Keller-------------14.05.2024 09:51
Veröffentlichung
|
Ja
|
Ja
|
|
CONTRL MIG 2.0b
|
Abgeschlossen
|
Dürfen mit CONTRL-Code "12" = "ungütiger Wert" OBIS-Kennzahlen abgelehnt werden, die die Vorgaben aus der EDI@Energy-Codeliste der OBIS-Kennzahlen und Medien einhalten?
|
Nein, per CONTRL ist unabhängig von weiteren Einschränkungen nur dann ein Wert als „ungültiger Wert“ zu reklamieren, wenn er vom gesamten Inhalt einer externen Liste abweicht. |
18.03.2024
|
2024-02150 |
|
|
Sehr geehrte Damen und Herren,
wir haben eine Frage zu Verwendung vom Syntax-Fehler-Code 12 (Ungültiger Werte; Mitteilung, dass der Wert eines einfachen Datenelements, einer Datenelementgruppe oder eines Gruppendatenelements nicht den entsprechenden Spezifikationen entspricht) in Bezug auf die OBIS-Kennzahlen in der MSCONS.
Als Messtellenbetreiber bekommen wir vermehrt CONTRL-Ablehnungen auf versendete MSCONS-Nachrichten mit dem Fehlercode 12 (Ungültiger Wert). Dieser Fehler-Code bezieht sich auf Segmente mit OBIS-Kennzahlen. Der Marktpartner möchten hier auf ihm nicht bekannten OBIS-Kennzahlen hinweisen. Ein Grund für die beim Marktpartner nicht vorliegenden OBIS-Kennzahlen kann z.B. der fehlende Austausch der Kennzahlen per UTILMD sein.
Ist die Verwendung von Fehlercode 12 (Ungültiger Wert) berechtigt, wenn OBIS-Kennzahlen in der Nachricht syntaktisch korrekt aufgebaut sind?
Aus unseren Sicht ist für solche Fälle eine APERAK (vgl. APERAK MIG (edi-energy.de)) mit Anwendungsfehler-Code Z20 (OBIS-Kennzahl zum angegebenen Zeitintervall /Zeitpunkt am Objekt nicht bekannt) zu nutzen.
Wir bitten um eine Stellungnahme ob im beschriebenen Fall eine CONTRL mit dem Fehler-Code 12 genutzt werden darf.
|
2024-03-18 13:55:16 |
Sehr geehrter Fragesteller,
wir interpretieren Ihre Schilderung so, dass in der MSCONS nur OBIS-Kennzahlen verwendet werden, die den Anforderungen der EDI@Energy-Codeliste der OBIS-Kennzahlen und Medien genügen. In diesem Fall darf im von Ihnen skizzierten Szenario nur per APERAK und nicht per CONTRL abgelehnt werden. Zur Meldung eines Verarbeitbarkeitsfehlers kann es nur dann kommen, wenn - so wie Sie es auch schon dargestellt haben - der Empfänger die OBIS-Kennzahl noch nicht über eine Stammdatennachricht mitgeteilt bekommen hat oder der zeitliche Abstand zwischen der Stammdatenmeldung MSCONS so kurz ist, dass der Empfänger die Stammdaten noch nicht verarbeitet hat, als er die MSCONS erhielt und verarbeitete.
Freundliche Grüße,
Ihr BDEW-Forum Datenformate |
Ja
|
Klaus Keller |
Stefan Seidel |
Stefan Seidel |
Frank Buthe |
https://www.edi-energy.de/index.php?id=38&tx_bdew_bdew%5Buid%5D=1309&tx_bdew_bdew%5Baction%5D=download&tx_bdew_bdew%5Bcontroller%5D=Dokument&cHash=b8a6d7388eb138307548aa05e27105d5
|
Nein
|
-------------Klaus Keller-------------21.03.2024 14:39
Antwortvorschlag an Herrn Seidel gesendet
-------------Stefan Seidel-------------22.03.2024 09:02
Antwort ergänzt und zur Kurzfrage und -antwort per E-Mail mit Herrn Keller kontakt aufgenommen.
-------------Klaus Keller-------------22.03.2024 12:58
Finalisierung nach Infos aus Mail von Herrn Seidel und Veröffentlichung
|
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
|
|
Regelungen zum Übertragungsweg für AS4 2.0
|
Eingegangen
|
Mehrere gültige Zertifikate mit unterschiedlichen URL
|
Ein Kommunikatiosnpartner darf jedes dieser Zertifikate nutzen. |
07.03.2024
|
2024-02134 |
|
|
Wie ist damit umzugehen, wenn ein Marktpartner zwei gültige Zertifikate mit unterschiedlichen URL's veröffentlicht hat. An welche dieser beiden URLs soll der Sender seine EDIFACT-Nachrichten per AS4 senden?
|
2024-03-07 12:24:15 |
Sehr geehrter Fragesteller,vielen Dank für Ihre Anfrage.
Diese Frage ist in den Regelungen zum Übertragungsweg 2.1 adressiert:
Verwendet ein Marktpartner für eine MP-ID mehrere Zertifikate zu gleicher Zeit, ist es anderenMarktpartnern gestattet mit jedem der gültigen veröffentlichten Zertifikate mit diesem zukommunizieren.
Freundliche GrüßeIhr Forum Datenformate |
Ja
|
Rene Hoffmann |
Rene Hoffmann |
Rene Hoffmann |
Peter Poellath |
4 Kommunikationsregeln
Zwischen zwei unterschiedlichen MP-ID ist genau ein Übertragungsweg mit jeweils genau einem Endpunkt zu verwenden. 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. Verwendet ein Marktpartner für eine MP-ID mehrere Zertifikate zu gleicher Zeit, ist es anderen Marktpartnern gestattet mit jedem der gültigen veröffentlichten Zertifikate mit diesem zu kommunizieren |
Nein
|
|
Nein
|
Nein
|
|
Regelungen zum Übertragungsweg für AS4 2.0
|
Eingegangen
|
Metainformation MSCONS Anwendungsreferenz (VL, TL)
|
Die Anwednungsreferenz wird nicht übermittelt |
29.01.2024
|
2024-02068 |
|
|
Sehr geehrte Damen und Herren,
bei unseren ersten Tests der Nachrichtenübertragung per AS4 wurde durch das AS4-System die Anwendungsreferenz (VL, TL) aus dem Namen vonMSCONS-Datei entfernt. Der Dienstleister für die AS4-Übertragung beruft sich auf das aktuell Dokument "Regelungen zum Übertragungsweg für AS4 2.0 und ist der Meinung, dass durch die AS4-Übertragung die Anwendungsreferenz nicht mehr mitgeliefert werden darf.
"Für den Austausch von Übertragungsdateien für Marktprozesse werden die Felder innerhalb
des Elements „PartProperties“ wie folgt gefüllt:
› BDEWDocumentType: EDIFACT-Name des Nachrichten-Typs gem. UNH DE0065
› BDEWDocumentNo: Datenaustauschreferenz aus UNB DE0020
› BDEWDocumentDate : Datumstempel bei Erzeugung im Format YYYY-MM-DD
Die UNH DE0065 enthält nicht die Anwendungsreferenz."
Ist die Namenskonvention, bei welcher die Anwendungsreferenz Pflicht ist, bei AS4-Übertragung noch anzuwenden?
|
2024-01-29 08:31:49 |
Sehr geehrter Fragesteller,
vielen Dank für Ihre Anfrage.
Beim Übertragungsweg AS4 werden keine Dateinamen übermittelt, somit gibt es dafür keine Namenskonvention. Die Übermittlung der Anwendungsreferenz in den PartProperties des SoapEnvelops des AS4 – Aufrufs ist derzeit nicht im AS4 Profil vorgesehen.
Freundliche Grüße
Ihr Forum Datenformate |
Ja
|
Rene Hoffmann |
Rene Hoffmann |
Dirk Katzenbach |
Patrick Stieberitz |
|
Nein
|
|
Nein
|
Nein
|
|
Regelungen zum Übertragungsweg für AS4 2.0
|
Eingegangen
|
Key Lifecycle Security Requirements
|
Bei Zertifikatswechsel sind mehrere gültige Zertifikate nötig |
22.01.2024
|
2024-02058 |
|
|
In den "Key Lifecycle Security Requirements" des BSI gibt es folgende Aussage zu privaten Schlüsseln:
"A private key is called activated when it is first used for the intended purpose, e.g. signing or encryption.
Using a key to prove possession of the key to a Certification Authority (e.g. signing a certificate request) does
not count as key activation.
Each entity MUST NOT have more than one activated key per purpose. In the case of duplication of a key,
e.g. for the purpose of load balancing, the original key and its duplicates count as one key"
Es geht um die Aussage "Each entity MUST NOT have more than one activated key per purpose."
Wie passt das zur Tatsache, dass ein Marktteilnehmer mehrere gültige und in Verwendung befindliche Zertifikatstripel haben kann? Dies ist doch dazu ein Widerspruch. Wir bitten um Klarstellung.
|
2024-01-22 14:15:23 |
Sehr geehrter Fragesteller,
vielen Dank für Ihre Anfrage.
Die CP der SM-PKI besagt: „Beim GWA, GWH und EMT kann es nach der Ausstellung des neuen Zertifikats zu einem temporären Betrieb mit zwei gleichzeitig gültigen Zertifikaten kommen. Diese Phase dient dazu, allen relevanten Komponenten rechtzeitig das neue Zertifikat mitzuteilen“ (Kapitel 3.3 Identifizierung und Authentifizierung von Anträgen auf Schlüsselerneuerung (Routinemäßiger Folgeantrag))
Freundliche Grüße
Ihr Forum Datenformate |
Ja
|
Rene Hoffmann |
Rene Hoffmann |
Dirk Katzenbach |
Thomas Beckers |
- Kapitel 2.5 in "Key Lifecycle Security Requirements" des BSI.
- RzÜ allgemein |
Nein
|
|
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
|
|
Regelungen zum Übertragungsweg für AS4 2.1
|
Eingegangen
|
Patch Switch bei der Umstellungauf AS4-Kommunikation im Fahrplanmanagement
|
Keine Nutzung des Service PathSwitch bei der Umstellung der Kommunikation im Fahrplanmanagement |
13.02.2024
|
2024-02104 |
|
|
Gibt es für die AS4-Kommunikation im Fahrplanmanagement auch einen Patch Switch? Da für MAKO und FPM dieselben MP-IDs benutzt werden, sind die fürs FPM relevanten MP-IDs schon zum 1.4.2024 zu AS4 gewechselt.
Im bislang beschriebenen Path Switch gibt es keine Unterschiedung zwichen MAKO und FPM.
Wird der Wechsel zu AS4 ausschließlich bilateral mit den ÜNBs abgestimmt?
|
2024-02-13 07:40:54 |
Sehr geehrter Fragesteller,
vielen Dank für Ihre Anfrage.
Die aktuellen Regelungen zum sicheren Austausch im Fahrplanprozess sehen keine Nutzung des AS4 Service "Wechsel des Überrtagungsweg" (PathSwitch) vor.
Freundliche GrüßeIhr Forum Datenformate |
Ja
|
Rene Hoffmann |
Rene Hoffmann |
Rene Hoffmann |
Thomas Beckers |
Kapitel 7.2
Kapitel 2.3.7 (AS4-Profil)
https://www.amprion.net/Dokumente/Strommarkt/Bilanzkreise/Fahrplanmanagement/2023/AG-FPM_Regelungen-zum-sicheren-Austausch-im-Fahrplanprozess_v2.1_DE_Final_2023-10-01.pdf |
Nein
|
|
Nein
|
Nein
|
|
Regelungen zum Übertragungsweg für AS4 2.1
|
Eingegangen
|
Muss eine "Retry-After"-Angabe in der Antwort auf einen Web-Service Aufruf beachtet werden?
|
"Retry-After"-Angabe muss nicht beachtet werden. |
12.02.2024
|
2024-02100 |
|
|
Muss der Aufrufer eines AS4-Endpunkts die Antworten mit HTTP-Status-Codes 503 und/oder 429 unterstützen (also einen Retry ausführen)?
Muss die "Retry-After"-Angabe (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Retry-After) in einer 503/429-Antwort unterstützt werden?
Wie oft sollte oder muss im Fehlerfall ein Retry ausgeführt werden?
|
2024-02-12 13:24:35 |
Sehr geehrter Fragesteller,
vielen Dank für Ihre Anfrage.
Wie oft und in welchen zeitlichen Abstand ein Versuch unternommen wird, eine Nachricht einem anderen Marktpartner zuzustellen, ist keine Frage des Übertragungsweg, sondern muss jeder Marktpartner für sich entscheiden.
Ein Hinweis mittels Retry-After Kopfzeile in der Antwort sollte beachtet werden.
Freundliche GrüßeIhr Forum Datenformate |
Ja
|
Rene Hoffmann |
Rene Hoffmann |
Rene Hoffmann |
Thomas Beckers |
|
Nein
|
|
Nein
|
Nein
|
|
Regelungen zum Übertragungsweg für AS4 2.1
|
Eingegangen
|
Darf einem per HTTP übermittelten Redirect gefolgt werdenß
|
Einem Redirect sollte nicht gefolgt werden. |
12.02.2024
|
2024-02099 |
|
|
Wie ist zur Verfahren, wenn der AS4-Endpunkt aus den Zertifikaten via HTTP ein Redirect (HTTP-Status-Code: 301, 302, 303, 307 oder 308) macht? Muss diesem Redirect gefolgt werden? Darf diesem Redirect gefolgt werden?
|
2024-02-12 13:18:10 |
Sehr geehrter Fragesteller,
vielen Dank für Ihre Anfrage.
Einem Redirect muss nicht gefolgt werden.
Es können Sicherheitseinstellungen beim Aufrufer einen Redirect verhindern.
Am neuen Endpunkt muss ein neues, zu dieser Adresse passendes, TLS Zertifikat verwendet werden.
Die übermittelte Nachrichtendatei ist mit dem Verschlüsselungsschlüssel aus dem Zertifikatspaket des ursprünglichen TLS-Schlüssel verschlüsselt. Im Ergebnis kann die Nachricht nicht verarbeitet werden.
Freundliche Grüße
Ihr Forum Datenformate |
Ja
|
Rene Hoffmann |
Rene Hoffmann |
Rene Hoffmann |
Thomas Beckers |
Kapitel 5 (Verweis auf CP der SM-PKI)
Kapitel 2.3.4.5 (AS4-Profil)
Die CP der SM-PKI sagt dazu nur "Zugehöriger AS4-WebService" (A7.1) |
Nein
|
|
Nein
|
Nein
|
|
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
|
|
INVOIC / REMADV AHB - informatorische Lesefassung 2.5b
|
Abgeschlossen
|
Dürfen Abschlagsrechnungen nach Ende der Lieferantenzordnung erhoben werden ?
|
Aus Formatsicht gibt es hierzu keine Einschränkung. |
09.02.2024
|
2024-02095 |
|
|
Sehr geehrte Damen und Herren,
wir haben eine Abschlagsrechnung für den Zeitraum 22.11.2023 bis 17.01.2024 erhalten. Etwa zwei Wochen danach haben wir für die selbe MaLo eine Schlussrechnung (ABR) erhalten. Der Abrechnungszeitraum ist hier vom 01.12.2023 bis 28.12.2023. In der Schlussrechnung wird die von uns gezahlte Abschlagsrechnung berücksichtigt.
Bei der Prüfung auf geleistete Abschlagsrechnungen nehmen wir den Zeitraum der Turnus- oder Schlussrechnung um nach zugehörigen Abschlagsrechnungen zu suchen. In dem vorgenannten Fall bekommen wir allerdings ein Problem, da die Abschlagsrechnung bis 17.01.2024 also über das Enddatum der Schlussrechnung hinausgeht.
Müssen wir unsere Prüfungen anpassen und diesen zeitlichen Überhang akzeptieren oder müsste der Netzbetreiber die Abschlagsrechnung erst stornieren und danach die Schlussrechnung erstellen?
Vielen Dank und viele Grüße
J. Kattner
|
2024-02-09 11:41:42 |
Sehr geehrter Fragesteller,
für den Fall, dass:
- eine Abschlagsrechnung gestellt wurde, als noch kein Versorgungsende feststand
- die Kündigung erst danach erfolgte
- der übrig gebliebene Abrechnungszeitraum vor dem Ende des Abschlagszeitraums lag
erscheint es nachvollziehbar, dass hier unterschiedliche Zeiträume in Abschlags- und Schlußrechnung auftauchen. Da die Abschlagsrechnung aufgrund der erfolgten Zahlung bereits positiv geprüft wurde, erscheint uns eine ebenfalls positive Prüfung der Schlußrechnung naheliegend.
Anders formuliert mit näherem Bezug zu den INVOIC-Formatinhalten:
Wir gehen davon aus, dass zum Zeitpunkt der Erstellung der Abschlagsrechnung das Ende der LF-Zuordnung zum 28.12.2023 dem NB noch nicht bekannt war. In der INVOIC von Typ ABR sind alle in dieser berücksichtigten Abschlagsrechnungsnummern anzugeben, um genau die von Ihnen erwähnten Zeitraumangabenprobleme zwischen ABR und ABS zu beseitigen. Wenn somit – so wie wir Sie verstehen, die Rechnungsnummer des Abschlags über den Zeitraum 22.11.203 bis 17.01.2024 mit dem von Ihnen bezahlten Betrag enthalten ist, können wir keinen Grund erkennen, weshalb die INVOIC des Typs ABR nicht bezahlt werden sollte.
Freundliche Grüße,
Ihr BDEW-Forum Datenformate |
Ja
|
Klaus Keller |
Stefan Seidel |
Stefan Seidel |
Jörg Kattner |
|
Nein
|
-------------Klaus Keller-------------09.02.2024 16:25
Antwortvorschlag an Herrn seidel gesendet
-------------Klaus Keller-------------13.02.2024 13:20
Vorschlag von Herrn Seidel ergänzt
-------------Klaus Keller-------------14.05.2024 09:14
Veröffentlichung
|
Nein
|
Nein
|
|
INVOIC / REMADV AHB - informatorische Lesefassung 2.5b
|
Abgeschlossen
|
Dürfen die Energiemengen nach GeLi Gas der Rück- und Vorwärtsposition zusammengefasst werden?
|
Ja |
07.11.2023
|
2023-01988 |
|
|
Dürfen die Energiemengen nach GeLi Gas der Rück- und Vorwärtsposition zusammengefasst werden?
|
2023-11-07 14:00:09 |
Sehr geehrter Marktteilnehmer,
wir gehen davon aus, dass in Ihrem Beispiel unter Textbezug eine Vielzahl an Segmenten, der SG26 nicht genannt sind, jeder der beiden Zeiträume in einer eigenen SG26 steht und jede der beiden SG26 die identische Artikelnummer im LIN-Segment enthält.
Wir unterstellen ferner, dass die INVOIC auch sonst syntaktisch richtig ist und keinen Verarbeitbarkeitsfehler enthält. Die Rückwärtsposition der Rechnung umfasst den selben Zeitraum und die Mengen und Beträge welche identisch mit denen der Vorwärtsposition der Vorgängerrechnung sind, die einen Monat weniger betrachtet, als die Rechnung. Somit ist der Vergleich der von Rückwärtsposition der Rechnung mit der Vorwärtsposition der Vorgängerrechnung leicht möglich. Da im Gas kein Abgleich der Energiemengen der Rechnungspositionen mit denen eines Lieferscheins vorgeschrieben ist (weil es keinen Lieferschein ausgetauscht gibt) und uns keine Regelung bekannt ist, die das von Ihnen beschriebene Vorgehen verbieten würde, kann so verfahren werden.
Mit freundlichem Gruß
Ihr BDEW-Forum Datenformate |
Ja
|
Klaus Keller |
Stefan Seidel |
Stefan Seidel |
Martin Skupin |
Ist es im Falle einer gleitenden Nachberechnung Erdgas, GeLi Gas, erlaubt die Werte vergangener Monate kollektiv zurückzunehmen und die neuen Werte kollektiv zu berechnen, kein Lieferschein?
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'
|
Nein
|
-------------Stefan Seidel-------------08.11.2023 11:15
Nachdem ich feststellte, dass die relevanten Informationen im Feld "Textbezug" stehen, könnte ich antworten.
-------------Klaus Keller-------------09.11.2023 17:59
Review
-------------Klaus Keller-------------14.05.2024 09:27
Veröffentlichung
|
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
|
|
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
|
|
Entscheidungsbaum-Diagramme und Codelisten 3.4 - Außerordentliche Veröffentlichung
|
Eingegangen
|
Wie ist eine INVOIC abzulehnen wenn der Rechnungsempfänger die MaLo-ID nicht kennt?
|
Die Rechnung ist abzulehnen mit dem Code A01. |
07.02.2024
|
2024-02089 |
|
|
Wie ist eine INVOIC zu reklamieren, wenn die vom Netzbetreiber genannte MALO nicht beim Lieferanten vorhanden ist?
|
2024-02-07 14:00:29 |
Sehr geehrter Marktteilnehmer,
Im Prüfschritt 1 wird geprüft, ob der LF der Marktlokation mind. für einen Tag zugeordnet ist. Wenn dies nicht der Fall ist, erfolgt eine Ablehnung mit dem Code A01.
Anmerkung: Ist die MaLo-ID nicht beim LF im IT-System bekannt, bedeutet dies auch, dass dieser LF der Marktlokation nicht zugeordnet ist.
Mit freundlichen GrüßenIhr BDEW-Forum Datenformate |
Ja
|
Matthias Braun |
Clara Schubert-Gladen |
Matthias Braun |
Michael Fuhrer |
|
Nein
|
Nach Absprache mir der KG Abrechnung
-------------Thomas Seipt-------------18.04.2024 17:19
|
Nein
|
Nein
|
|
Entscheidungsbaum-Diagramme und Codelisten 3.4 - Außerordentliche Veröffentlichung
|
Eingegangen
|
Gilt die Definition zur Bildung einer Resultierenden auch für Artikel-ID wie z.B. Messstellenbetrieb?
|
Definition für die Resultierende gilt auch für Artikel-ID mit Stückpreisen. |
29.01.2024
|
2024-02070 |
|
|
Gilt die Vorgabe zur Bildung einer Resultierenden bzw. korrespondierenden Resultierenden auch für Positionszeilen mit der Mengeneinheit "Stück", wie z.B. dem Messstellenbetrieb?
|
2024-01-29 14:59:31 |
Sehr geehrter Marktteilnehmer,
die Definition für die Resultierende gilt auch für Artikel-ID mit Stückpreisen.Die Korrespondierende Resultierende kann nicht für Artikel-ID mit Stückpreisen gelten, da es dazu eine Gruppenartikel-ID geben müsste.
Mit freundlichen GrüßenIhr BDEW-Forum Datenformate |
Ja
|
Matthias Braun |
Clara Schubert-Gladen |
Matthias Braun |
Michael Fuhrer |
|
Nein
|
Antwort in der KG Abrechnung abgestimmt
-------------Thomas Seipt-------------18.04.2024 17:04
|
Nein
|
Nein
|
|
INVOIC / REMADV AHB 2.5b
|
Abgeschlossen
|
Dürfen Abschlagsrechnungen nach Ende der Lieferantenzordnung erhoben werden ?
|
Aus Formatsicht gibt es hierzu keine Einschränkung. |
06.02.2024
|
2024-02084 |
|
|
Ein Netzbetreiber hat uns im Dezember 2023 eine Schlussrechnung mit dem Enddatum 26.03.2023 geschickt. Bis Dezember wurden von uns Abschlagszahlungen für diese MaLo geleistet. Diese wurden in der Schlussrechnung berücksichtigt. Wir sind allerdings der Ansicht, dass die Abschlagszahlungen, die wir nach dem Enddatum (04.2023 bis 12.2023) geleistet haben, storniert hätten werden müssen und erst anschließend die Schlussrechnung erstellt hätte werden dürfen. Wir sind der Ansicht, dass wir als Rechnungsempfänger nur Abschlagsrechnungen prüfen können, die mit dem Zeitraum der Abrechnung übereinstimmen., was hier nicht der Fall ist.
Wie ist Ihre Sichtweise in einem solchen Fall?
|
2024-02-06 09:20:07 |
Sehr geehrter Fragesteller,
wir gehen davon aus, dass zum Zeitpunkt der Erstellung der Abschlagsrechnungen das Ende der LF-Zuordnung zum 26.03.2023 dem NB noch nicht bekannt war. In der INVOIC von Typ ABR sind alle in dieser berücksichtigten Abschlagsrechnungsnummern anzugeben, um genau die von Ihnen erwähnten Zeitraumangabenprobleme zwischen ABR und ABS zu beseitigen. Wenn somit – so wie wir Sie verstehen, Rechnungsnummern der Abschläge über den Zeitraum 04/2023 bis 12/2023 mit dem von Ihnen bezahlten Beträgen enthalten sind, können wir keinen formalen Fehler innerhalb der EDIFACT-Dokumente erkennen.
Selbstverständlich teilen wir die Ansicht, dass es in jedem Falle erklärungsbedürftig erscheint, dass acht Monate nach Ende der LF-Zuordnung vergangen sind bis zur Schlußrechnung - hierbei handelt es sich jedoch nicht um eine Formatfrage.
Freundliche Grüße,
Ihr BDEW-Forum Datenformate |
Ja
|
Klaus Keller |
Stefan Seidel |
Stefan Seidel |
Jörg Kattner |
|
Nein
|
-------------Klaus Keller-------------09.02.2024 16:45
Dublette, vgl. Frage: 2024-02095 die bereits mit einem Antwortvorschlag an Herrn Seidel gesendet wurde zur QS
-------------Klaus Keller-------------13.02.2024 13:20
Antwortvorschlag erstellt, da doch keine Dublette
-------------Klaus Keller-------------14.05.2024
09:48
Veröffentlichung
|
Nein
|
Nein
|
|
INVOIC / REMADV AHB 2.5b
|
Abgeschlossen
|
Müssen Artikel-IDs, die mit "0" in der INVOIC berechnet werden, vorher per PRICAT angekündigt werden ?
|
Ja, alle Artikel-IDs aus der INVOIC müssen vorher per PRICAT übertragen worden sein. |
11.10.2023
|
2023-01956 |
|
|
Hallo,
wir haben eine neg. REMADV mit dem Grund A37 Der Preis wurde nicht angeben (weder im Preisblatt noch über Stammdaten) und ist auch nicht über "gesetzliche Vorgaben" bekannt. Diese Ablehnung gilt für die Artikel ID 1-10-3-001.
Muss auf dem Preisblatt bei Artikel ID`S die nicht berechnet werden der Preis von 0,00 € hinterlegt sein.
Vielen Dank
Mit vielen Grüßen
Dirk Taugerbeck
|
2023-10-11 12:23:35 |
Sehr geehrter FDF-Fragesteller,
es müssen in der vorherigen PRICAT alle Artikel-IDs übermittelt worden sein, unabhängig vom Betrag des Preises bzw. im Falle, dass in der INVOIC ein zugehöriger Positionsbetrag von 0,00 EURO übertragen wird.
Viele Grüße,
Ihr BDEW-Forum Datenformate |
Ja
|
Klaus Keller |
Stefan Seidel |
Stefan Seidel |
Dirk Taugerbeck |
|
Nein
|
-------------Klaus Keller-------------16.10.2023 19:07
Antwort erstelle und an Herrn Seidel zur QS gesendet
-------------Klaus Keller-------------14.05.2024 09:35
Veröffentlichung
|
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
|
|
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
|
|
Entscheidungsbaum-Diagramme und Codelisten 3.4
|
Eingegangen
|
Wie sind Rück- und Vorwärtspositionen aufzuführen?
|
Ob eine zusammenfassende Position oder mehrere einzelne Positionen übertragen werden, obliegt dem Rechnungsersteller. |
25.01.2024
|
2024-02065 |
|
|
Hallo,
ein Netzbetreiber nimmt bei der 13I-INVOIC die Artikel-ID für den Messstellenbetrieb im Zeitraum 01.01.-30.11.2023 für jeden einzelnen Monat zurück und berechnet den Messstellenbetrieb neu, aber diesmal für den kompletten Jahreszeitraum 01.01.-31.12.2023. Aktuell führt dies zur Reklamation AB8 (Ablehnung - Position - Doppelter Service (13I, 13R, SOR)).
Ist diese Rück- und Vorwärtsrechnung des Messstellenbetriebs in der INVOIC korrekt?
|
2024-01-25 07:35:47 |
Sehr geehrter Marktteilnehmer,
In diesem Fall ist aus allen Positionen dieser Artikel-ID eine Resultierende zu bilden. Entsprechend ihrer Angaben ergibt sich, dass die Resultierende nur einen Monat (01.12.2023 bis 31.12.2023) umfasst.
Damit ist die Netznutzungsrechnung für den Messstellenbetrieb korrekt.
Hinweis: Ob eine zusammenfassende Position oder mehrere einzelne Positionen übertragen werden, obliegt dem Rechnungsersteller.
Freundliche GrüßeIhr Forum Datenformate |
Ja
|
Matthias Braun |
Clara Schubert-Gladen |
Matthias Braun |
Michael Fuhrer |
|
Nein
|
Frage aus der KG Abrechnung beantwortet
-------------Thomas Seipt-------------23.04.2024 09:37
|
Nein
|
Nein
|
|
Entscheidungsbaum-Diagramme und Codelisten 3.4
|
Eingegangen
|
Wie müssen Energiemengen im Lieferschein und der Netznutzungsrechnung dargestellt werden?
|
Energiemengen der Netznutzungsrechnung müssen aus den Energiemengen des Lieferschein ableitbar sein. |
23.01.2024
|
2024-02062 |
|
|
Hallo, ein Netzbetreiber nimmt in der INVOIC zu einem SLP- bzw. RLM-Kunden eine Splittung in Tarifkunden-KA und Schwachlast-KA vor. Im dazugehörigen Lieferschein gibt es nur eine Positionszeile. Beispiel: - Tarifkunden-KA: 1.000 kWh (1-08-4-001) - Schwachlast-KA: 500 kWh (1-08-1-001) - Lieferschein: 1.500 kWh In dieser Konstellation ist jetzt nicht prüfbar, ob die berechneten Mengen der verschiedenen KAs korrekt ist. Muss hier der Netzbetreiber nicht eine entsprechende Trennung im Lieferschein vornehmen?
|
2024-01-23 12:10:59 |
Sehr geehrter Fragesteller,
der NB hält sich nicht an die Vorgabe, dass die Energiemengen aus dem Lieferschein mit den angegeben Energiemengen aus der Netznutzungsrechnung übereinstimmen müssen. 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 über-einstimmen.“
Ausnahmen sind Artikel-ID, die einer der folgenden Gruppenartikel-ID zugehörig sind
1-10-4, 1-10-5, 1-10-6, 1-08-2-AGS-KG und 1-08-5-AGS-KG.
Freundliche GrüßeIhr Forum Datenformate |
Ja
|
Matthias Braun |
Clara Schubert-Gladen |
Matthias Braun |
Michael Fuhrer |
|
Nein
|
Antwort aus der KG Abrechnung
-------------Thomas Seipt-------------23.04.2024 09:53
|
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
|
|
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
|
Wie werden neue Artikel-ID genehmigt?
|
neue Artikel-ID sind von der Bundesnetzagentur zu genhemigen. |
17.11.2023
|
2023-02002 |
|
|
Sehr geehrtes Forum,
die für den MSB hinzugekommenen Artikel-ID´s enthalten u.a. Zusatzleistungen wie Wandler, jedoch fehlt mir hier die Möglichkeit weitere Zusatzleistungen, wie die Miete für einen Messschrank oder Messschrank mit Wandler zu berechnen.
Sind hier noch weitere ID´s in Diskussion/Planung bzw. gibt es eine Artikel-ID, unter der die o.g. Zusatzleistungen abgerechnet werden dürfen/können?
Vielen Dank und viele Grüße
|
2023-11-17 09:50:42 |
Sehr geehrter Marktteilnehmer,
neue Artikel-ID sind von der Bundesnetzagentur zu genhemigen. Derzeit sind keine Änderungen der Artikel-ID geplant.
Mit freundlichen GrußIhr BDEW-Forum Datenformate |
Ja
|
Beate Becker |
Klaus Keller |
Beate Becker |
Martin Probst |
|
Nein
|
Antwort veröffentlicht
-------------Amirhossein Forootanfard-------------23.04.2024 16:15
|
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
|
|
PRICAT AHB 2.0c
|
Abgeschlossen
|
Ist [UB1] für das Preisblatt "GPKE AwH Sperrprozesse Gas NB an LF" korrekt?
|
Ja, [UB1] für das Preisblatt "GPKE AwH Sperrprozesse Gas NB an LF" korrekt. |
16.10.2023
|
2023-01965 |
|
|
Sehr geehrte Damen und Herren,
ist die Bedingung UB1 für übergreifende Bedingungen für Zeitpunktangaben in dem DTM+157 Segment bei dem Prüfidentifikator 27003 (Preisblatt GPKE und Awh Bedingung Sperrprozesse Gas) so korrekt? Der Prozess ist seit dem 01.10. sowohl für Strom als auch für Gas anzuwenden.
Die UB1 Bedingung sagt jedoch bei der Zeitangabe aus, dass nur Uhrzeiten 2200 oder 2300, je nach Zeitzone, erlaubt sind.
Gilt das auch für den Bereich Gas oder muss die Bedingung auf UB3 geändert werden?
Mit freundlichen Grüßen
Stefan Lange
|
2023-10-16 13:51:33 |
Sehr geehrte Marktteilnehmerin, sehr geehrter Marktteilnehmer,
In der Anwendungshilfe "Sperrprozesse Gas", Marktprozesse zur Unterbrechung und Wiederherstellung der Anschlussnutzung (Sperren/Entsperren) auf Anweisung des Lieferanten in der Sparte Gas, Version: 1.0 steht in Kapitel 4.1.2 Rahmenbedingungen: "Ein Preisblatt beginnt und endet immer zu 0:00 Uhr eines Kalendertages" und damit ist [UB1] anzuwenden.
Mit freundlichem Gruß
Ihr BDEW-Forum Datenformate |
Ja
|
Thomas Seipt |
Klaus Keller |
Thomas Seipt |
Stefan Lange |
|
Nein
|
AG 12.08.2024
-------------Thomas Seipt-------------15.08.2024 10:20
|
Nein
|
Nein
|
|
PRICAT AHB 2.0c
|
Abgeschlossen
|
Ist [UB1] für das Preisblatt "GPKE AwH Sperrprozesse Gas NB an LF" korrekt?
|
Ja, [UB1] für das Preisblatt "GPKE AwH Sperrprozesse Gas NB an LF" korrekt. |
05.10.2023
|
2023-01948 |
|
|
Wie ist die Bedingung [UB1] am DE2380 eines DTM+157 im PRICAT Vorgang 27003 im Kontext von Gas-Nachrichten zu interpretieren?
Nachrichten im Gas-Kontext verwenden hier (nachvollziehbar) Angaben á la "DTM+157:202310010400?+00:303'". Diese werden jedoch durch die [UB1] abgelehnt.
|
2023-10-05 08:44:07 |
Sehr geehrte Marktteilnehmerin, sehr geehrter Marktteilnehmer,
In der Anwendungshilfe "Sperrprozesse Gas", Marktprozesse zur Unterbrechung und Wiederherstellung der Anschlussnutzung (Sperren/Entsperren) auf Anweisung des Lieferanten in der Sparte Gas, Version: 1.0 steht in Kapitel 4.1.2 Rahmenbedingungen: "Ein Preisblatt beginnt und endet immer zu 0:00 Uhr eines Kalendertages" und damit ist [UB1] anzuwenden.
Mit freundlichem Gruß
Ihr BDEW-Forum Datenformate |
Ja
|
Thomas Seipt |
Klaus Keller |
Thomas Seipt |
Stefan Marx |
Siehe PRICAT AHB 2.0c Seite 14 |
Nein
|
AG 12.08.2024
-------------Thomas Seipt-------------15.08.2024 10:16
|
Nein
|
Nein
|
|
AS4-Profil 1.0
|
Eingegangen
|
Zeit bis zum Abschluss des AS4-Webservice Aufruf
|
Keine Regelung geplant |
06.12.2023
|
2023-02024 |
|
|
Ist eine Regelung zur Höchstdauer der Zustellung einer NRR angedacht, bzw. ab welchem Zeitraum kann man davon ausgehen, das eine AS4-Nachricht nicht zugestellt wurde und die Nachricht erneut gesendet werden kann?
Hintergrund der Frage: Wir beobachten vermehrt, das trotz großzügig eingestellter Response-Timeouts NRRs nicht rechtzeitig im synchronen Prozess zugestellt werden. Ein Minuten langes offenhalten einer synchronen Verbindung stellt für alle Marktteilnehmer ein erhebliches Risiko bezüglich des Ressourcenverbrauchs dar und wir haben Verhalten beobachtet, das nahelegt, dass der Grund für die langen Antwortzeiten ein nachgelagerter Prozess sein könnte, der z.B. schon CONTROLs zurücksendet ohne dass die synchrone Verbindung schon geschlossen wurde. Läuft die Originalverbindung hier in einen Timeout, würde die Nachricht erneut gesendet werden.
|
2023-12-06 14:54:11 |
Sehr geehrter Fragesteller,
vielen Dank für Ihre Anfrage.
Zur Zeit ist keine Regelung geplant, die die Zeiten für den Aufruf des AS4 Web-Service betrifft.Eine konkrete Zeit ist schwierig, da zur Reduktion von Betriebsstörungen eine gewisse Flexibilität im beiderseitigen Interesse hilfreich ist. Sollte allerdings ein Marktpartner systematisch eine NRR nicht unmittelbar zurücksenden, so ist das nicht mehr synchron im Regelbetrieb. Der Zweck der NRR wird damit unterlaufen.
Freundliche Grüße
Ihr Forum Datenformate |
Ja
|
Rene Hoffmann |
Dirk Katzenbach |
Rene Hoffmann |
Michael Baden |
|
Nein
|
-------------Stefan Seidel-------------03.04.2024 13:56
NNR in der Antwort in NRR korrigiert. |
Nein
|
Nein
|
|
AS4-Profil 1.0
|
In Bearbeitung
|
[RzÜ-Frage] Neuer Marktpartner nach 01.04.2024 AS4-Service Wechsel Übertragungsweg
|
Nach dem 01.04.2024 gibt es keinen Wechsel des Übertragungsweg mehr. |
17.11.2023
|
2023-02006 |
|
|
Hallo PG-TiM,
Es gibt Unklarheit darüber, ob nach dem 01.04.2024 beim Aufbau der Marktkommunikation mit neuen Marktpartnern, der AS4-Service zur Änderung des Übertragungswegs "https://www.bdew.de/as4/communication/services/pathSwitch" aufgerufen werden muss oder dieser Schritt entfällt, da nur noch AS4 zulässig ist?
Im Kapitel 2 aus der Festlegung "Regelungen zum Übertragungsweg für AS4 v2.1" könnte entnommen werden, dass der Service pathSwitch nach dem 01.04.2024 entfällt wobei dieser für eine Fristverkürzung der 3 WT helfen würde.
Mit freundlichen Grüßen
Alexander Beck
|
2023-11-17 13:27:29 |
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 01.04.2024 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 |
Dirk Katzenbach |
Dirk Katzenbach |
Alexander Beck |
Regelungen zum Übertragungsweg für AS4 v2.1
Kapitel 2
"Spätestens drei Werktage (gemäß GPKE/GeLi Gas-Kalender7) nach der erstmaligen Kontaktaufnahme
eines Marktpartners müssen die oben genannten Daten zwischen diesen beiden Parteien
ausgetauscht sein. Spätestens drei Werktage nach Austausch der Kommunikationsdaten
müssen beide Parteien die Daten des jeweils anderen Marktpartners in allen ihren an der
Marktkommunikation beteiligten Systemen eingetragen bzw. zur Verfügung gestellt haben, so
dass alle Voraussetzungen für die Durchführung des elektronischen Datenaustauschs erfüllt
sind." |
Nein
|
Nächste Sitzung mit Fehlerkorrektur RzÜ 2.1
-------------Rene Hoffmann-------------20.11.2023 14:29
|
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
|
|
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
|
|
MSCONS AHB 3.1c
|
Eingegangen
|
Wie ist die Berechnungsformel des NB für Marktlokationen zu berücksichtigen?
|
Die zu übermittelnden Energiemengen für die Marklokationen sind, wenn sie aus mehreren Messlokationen ermittelt werden, unter Berücksichtigung der Messwerte und der Berechnungsformel zu übermitteln. |
07.11.2023
|
2023-01989 |
|
|
Sehr geehrte Damen und Herren,
wie ist die Energiemenge für die Marktlokation der Schule bei einem Schule-Hausmeister-Konstrukt zu bilden?
Die Energiemenge der Marktlokation der Schule (ID: MaLo1) resultiert aus den zwei zugeordneten Messlokationen (ID: MeLo1 und MeLo2). Für die Marktlokation des Hausmeisters (ID: MaLo2) ergibt sich die Energiemenge der Marktlokation nur aus den Messwerten einer Messlokation (ID: MeLo2).
Annahmen / Fallbeispiel:
- MSB1 ist MSB an der Marktlokation „Markt-Hausmeister“ & „Markt-Schule“.
- LF1 ist LF an der Marktlokation „Markt-Hausmeister“ & „Markt-Schule“.
- NB1 ist NB an der Marktlokation „Markt-Hausmeister“ & „Markt-Schule“.
- Zählerstände für Hauptzähler Z1 (MeLo1)
o 15.08.2023 => 200 kWh (Zwischenablesung)
o 31.12.2023 => 400 kWh (Turnusablesung)
- Zählerstände für Nebenzähler Z2 (MeLo2)
o 15.08.2023 => 50 kWh (Zwischenablesung)
o 31.12.2023 => 100 kWh (Turnusablesung)
In der "Anwendungshilfe zu den Datenformaten der Marktkommunikation 2020" (S.115) lässt sich ableiten, dass die Energiemenge für die MaLo1 (Marktlokation der Schule) berechnet wird. Laut dem Dokument "Wechselprozesse im Messwesen" (S.107 | 2.4.Use-Case: Aufbereitung und Übermittlung von Werten) ermittelt der MSB der Marktlokation auf Basis der Werte der Messlokation die Werte der Marktlokation.
Daraus lässt sich Folgendes schlussfolgern:
Bezogen auf das obige Beispiel übermittelt der MSB1 zum 31.12.2023 eine Energiemenge für die MaLo1 (Marktlokation der Schule) in Höhe von 150 kWh („Messlokation der Schule“ [200kWh] minus „Messlokation des Hausmeisters" [50kWh]). Für die MaLo2 (Marktlokation des Hausmeisters) kommuniziert der MSB1 eine Energiemenge von 50 kWh.
Ist die Verrechnung der Energiemenge („Messlokation der Schule“ minus „Messlokation des Hausmeisters“) für MaLo1 (Marktlokation der Schule) korrekt bzw. verpflichtend?
Aktuelle Situation:
Einige MSBs senden für die MaLo1 (Marktlokation Schule) eine Energiemenge ohne Berücksichtigung der MeLo2 (Nebenzähler). Basierend auf den Werten des Fallbeispiels übermittelt der MSB lediglich eine Energiemenge in Höhe von 200 kWh. Meiner Ansicht nach ist diese Handhabung falsch, da die Energiemenge nicht der Lieferscheinmenge entspricht.
Andere MSBs wiederum versenden für die MaLo1 (Marktlokation Schule) zwei Energiemengen. Gemäß den Werten des Fallbeispiels kommuniziert der MSB eine Energiemenge in Höhe von 200 kWh (basiert auf den Werten von MeLo1) und eine weitere Energiemenge mit 50 kWh (basiert auf den Werten von MeLo2). Anhand der Berechnungsformel soll der Lieferant die Energiemenge für MaLo1 (Marktlokation Schule) selbstständig errechnen, um die Menge im Lieferschein überprüfen zu können. Aus meiner Sichtweise ist diese Vorgehensweise ebenfalls nicht korrekt.
Mit freundlichen Grüßen
|
2023-11-07 14:03:23 |
Sehr geehrter Herr Wilde,
Die zu übermittelnden Energiemengen für die Marklokationen sind, wenn sie aus mehreren Messlokationen ermittelt werden, unter Berücksichtigung der Messwerte und der Berechnungsformel zu übermitteln. Die Schlussfolgerung in der Anfrage ist richtig.
Der MSB übermittelt die Zählerstände der einzelnen Messlokationen an die Lieferanten und den NB. In dem Beispiel erhält:
- der LF der Schule die originären Zählerstände der Messlokation 1 und der Messlokation 2. - der LF des Hausmeisters die originären Zählerstände der Messlokation 2.
Zusätzlich versendet der MSB der Marktlokation 1 (Schule) die Energiemenge der Marktlokation 1 (Schule) an den LF und NB. Diese berechnet sich mit Hilfe der Berechnungsformel zur Marktlokation 1 und den dazugehörigen Zählerständen.
Malo Schule = Melo Schule [200 kWh] - Melo Hausmeister [50 kWh] = 150kWh
Malo Hausmeister = Melo Hausmeister [50 kWh] = 50kWhH
Die vom MSB der Malo dem Markt (LF und NB) bereitgestellten Energiemengen werden im Rahmen der Abrechnung (Netznutzungs-, Mehr/Mindermengen-, Bilanzkreisabrechnung) ausschließlich genutzt. Zusätzlich übermittelte Messwerte der zugeordneten Messlokationen dienen den Empfängern insbesondere der Plausibilisierung der Energiemengen.
Der NB darf die Energiemengen der Marktlokation für den Lieferschein nicht selbst berechnen. Daher übernimmt er die berechnete Energiemenge der Marktlokation vom MSB und übermittelt diese in seinem Lieferschein:- an den LF für die Marktlokation 1 (Schule) 150 kWh- an den LF für die Marktlokation 2 (Hausmeister) 50 kWh.
Andere Werte dürfen im Lieferschein nicht genannt werden, da der Lieferschein die Energiemengen für die Netznutzungsrechnung vorgibt. In der Rechnungsprüfung werden die Energiemengen des Lieferscheins gegen die INVOIC geprüft. Zusätzlich wird geprüft, ob die Zählerstände unter Nutzung der Berechnungsformel die ausgewiesene Energiemenge wiedergeben.
Ihr Forum Datenformate |
Ja
|
Reinhard Döring |
Thomas Seipt |
Carsten Fröse |
Marcel Wilde |
WiM:
Die Berechnungsformel stellt die Formel zur Berechnung der Werte der Marktlokation mit der Angabe der notwendigen Messlokationen und deren Messgrößen dar. Dabei wird angegeben wie die ermittelten Werte der einzelnen Messlokationen zur Bildung der Werte der Marktlokation zu verrechnen sind.
... In diese Abrechnungen fließen ausschließlich die vom MSB auf Ebene der Marktlokation zur Verfügung gestellten Werte ein, die ggf. zusätzlich auf Ebene der
Messlokation/en von ihm zur Verfügung gestellten Werte dienen lediglich zur Plausibilisierung4 der Werte auf Ebene der Marktlokation.
|
Nein
|
|
Nein
|
Nein
|
|
Codeliste der Artikelnummern und Artikel-ID 5.3
|
Abgeschlossen
|
Müssen Änderungen von vorläufigen und entgültigen Preisen per UTILMD übermittelt werden?
|
ja |
06.09.2023
|
2023-01912 |
|
|
Probleme mit der Aktualisierung der Preise für singulär genutzte Betriebsmittel:
Die Artikelnummer 1-07-3-001 ist die einzige, bei der der Preis schon in der UTILMD mit übertragen werden muss.
Probleme gibt es nun bei den regelmäßigen (vorläufige Preise zum 15.10. und endgültige bis zum 31.12.) Preisanpassungen. Preisanpassungen führen nicht automatisch dazu, dass der aktuelle und evtl. gleiche Lieferant für das nächste Jahr eine aktualisierte UTILMD erhält.
Wir haben nun einen Lieferanten, der bemängelt, dass wir zum Zeitpunkt der Anmeldung einen Preis übermittelt hätten (es war gerade der Zeitraum mit den vorläufigen Preisen), der nicht in der PRICAT bzw. in der INVOIC verwendet wurde.
Da der Lieferant nun aber die PRICAT (nach Übersendung der UTILMD) regelmäßig bekommt, müsste er doch in der Lage sein, den Preis in seinem System zu pflegen. Und zwar ohne, dass eine neue UTILMD übermittelt werden muss.
Wie sehen Sie denn diesen Sachverhalt. Vielen Dank
|
2023-09-06 15:07:49 |
Sehr geehrter Marktteilnehmer,
wie sie richtig feststellen, wird zu der Artikel-ID 1-07-3-001 der Preis ausschließlich in der UTILMD übermittelt und nicht in der PRICAT angegeben. Daher müssen Sie in den Fällen, in denen Sie in der UTILMD den vorläufigen Preis übermittelt haben, der sich im Verauf der Zeit in einen davon abweichenden endgültigen Preis verändert hat, diesen veränderten Preis per UTILMD (Stammdatenänderung) an den entsprechenden LF übermitteln.
Mit freundlichen GrußIhr BDEW-Forum Datenformate |
Ja
|
Beate Becker |
Klaus Keller |
Beate Becker |
Michael Hoffmann |
Seite 29, 1-07-3-001 Singulär genutzte Betriebsmittel nach § 19 Abs. 3 StromNEV
|
Nein
|
Antwort veröffentlicht
-------------Amirhossein Forootanfard-------------23.04.2024 16:10
|
Nein
|
Nein
|
|
Codeliste der Artikelnummern und Artikel-ID 5.3
|
Abgeschlossen
|
Wann ist die Stammdatenänderung bei Änderung von Artikel-ID vorzunehmen?
|
Die Stammdatenänderung ist zum Tag des Umbaus zu versenden. |
26.05.2023
|
2023-01767 |
|
|
Sehr geehrtes Forum,
angenommen es gibt eine unterjährige Änderung bei der Zuordnung einer Artikel-ID an einer Marktlokation z.B. durch einen Gerätewechsel von kME auf mME, dann sind ja ab Einbau der mME die Artikel-IDs für die Entgelte des Messstellenbetriebs bei kME nicht mehr zu verwenden. Muss der Verteilnetzbetreiber bei diesem Sachverhalt zum Zeitpunkt der Änderung eine Stammdatenänderung mit dem Prüfidentifikator 11218 versenden? Oder ist die Stammdatenänderung (Prüfidentifikator 11218) erst mit Beginn der neuen Abrechnungsperiode durchzuführen?
|
2023-05-26 08:18:44 |
Sehr geehrter Marktteilnehmer,
die Stammdatenänderung, die über die Änderung des Netznutzungsentgeltumfangs informiert, ist unverzüglich nach Bekanntwerdung des entsprechenden Umbaus vom NB an den LF mit dem "gültig ab"-Datum des Umbautags zu übermitteln.
Mit freundlichen GrußIhr BDEW-Forum Datenformate |
Ja
|
Beate Becker |
Klaus Keller |
Beate Becker |
Michael Günzel |
|
Nein
|
Antwort veröffentlicht
-------------Amirhossein Forootanfard-------------23.04.2024 16:00
|
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
|
|
PRICAT AHB 2.0b
|
Eingegangen
|
Welche Artikel-ID sind in der PRICAT anzugeben?
|
In der PRICAT sind nur die Artikel-ID anzugeben, die vom NB an LF verwendet werden. |
21.08.2023
|
2023-01895 |
|
|
Dürfen einzelne Artikel IDs weggelassen werden in der PRICAT vom NB an den LF, wenn es für diese keinen Preis gibt oder sind Null-Werte als Preis zu übermitteln?
|
2023-08-21 15:12:28 |
Sehr geehrte Marktteilnehmerin, sehr geehrter Marktteilnehmer,
über eine Artikel-ID wird eine Leistungsbeschreibung eindeutig einem Code zugewiesen. Es ist sinnlos Leistungen, die nicht erbracht werden in einer Übersicht aufzuführen. Somit hat der Ersteller einer PRICAT ausschließlich die Artikel-ID in seiner PRICAT anzugeben, deren Leistung er in der Lage ist zu erbringen.
Mit freundlichem Gruß
Ihr BDEW-Forum Datenformate |
Ja
|
Thomas Seipt |
Klaus Keller |
Thomas Seipt |
André Cahn |
|
Nein
|
-------------Stefan Seidel-------------29.08.2023 23:16
Antwortvorschlag erstellt
Sehr geehrte Marktteilnehmerin, sehr geehrter Marktteilnehmer,
über eine Artikel-ID wird eine Leistungsbeschreibung eindeutig einem Code zugewiesen. Es ist nicht sinnvoll Leistungen, die nicht erbracht werden in einer Übersicht aufzuführen. Somit hat der Ersteller einer PRICAT ausschließlich die Artikel-ID in seiner PRICAT anzugeben, deren Leistung er in der Lage ist zu erbringen. Dies gilt unabhängig davon, ob die PRICAT durch einen NB oder einem MSB erstellt wird.
Mit freundlichem Gruß
Ihr BDEW-Forum Datenformate
-------------Thomas Seipt-------------30.08.2023 08:54
AG: 12.08.2024
Sehr geehrte Marktteilnehmerin, sehr geehrter Marktteilnehmer,
über eine Artikel-ID wird eine Leistungsbeschreibung eindeutig einem Code zugewiesen. Es ist sinnlos Leistungen, die nicht erbracht werden in einer Übersicht aufzuführen. Somit hat der Ersteller einer PRICAT ausschließlich die Artikel-ID in seiner PRICAT anzugeben, deren Leistung er in der Lage ist zu erbringen.
Mit freundlichem Gruß
Ihr BDEW-Forum Datenformate
-------------Thomas Seipt-------------15.08.2024 10:11
AG 12.08.204 |
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
|
|
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
|
|
Codeliste der Artikelnummern und Artikel-ID - informatorische Lesefassung 5.4 Außerordentliche Veröffentlichung
|
Abgeschlossen
|
Was ist bei Jahrespreisen in Schaltjahren zu beachten, da die BK6 vorgibt, dass diese in der Einheit €/d in der Marktkommunikation auszutauschen sind?
|
Der Preis in €/d muss durch Multiplikation mit der Anzahl der Tages eine Jahres den Preis in €/a ergeben |
21.07.2023
|
2023-01844 |
|
|
Hallo,
gemäß Abschnitt 3.5 und der darin enthaltenen Tabelle der Artikel-Id's müssen die im Messstellenbetriebsgesetz als Jahresbruttopreise angegebenen POG in Tagesnettopreise umgerechnet werden, bevor sie per PRICAT an die Lieferanten versendet werden.
Bedeutet dies, dass im Falle von Schaltjahren im Vorjahr vor dem Schaltjahr sowie im Schaltjahr zum 01.10. neue Tagespreise berechnet werden müssen und neue PRICAT für das Folgejahr zu versenden sind? Eigentlich ändert sich ja an den Jahresbruttopreisen nichts.
Vielen Dank im Vorab
Jörg Freiershausen
|
2023-07-21 15:24:08 |
Sehr geehrter Marktteilnehmer,
wie Sie richtig darstellen müssen die Jahrespreise in der PRICAT in der Einheit €/d (also Euro pro Tag) angeben werden. Der so ermittelte Preis muss, wenn man ihm in einem Schaltjahr mit den 366 Tagen multipliziert unterhalb der durch das MsbG vorgegebene Preisobergrenze liegen. Für die von der BK6 der Bundesnetzagentur vorgegebenen Marktkommunikationsprozesse sind die in der PRICAT genannten Preise die relevanten und nicht die ggf. auf anderen Medien veröffentlichten Preise. Wenn Sie die Preise der PRICAT (in €/d) mit denen Preisen auf anderen Medien (in €/a) gleich halten wollen, stehen ihnen somit zwei Wege offen:
Sie halten die Preise in €/a für alle Jahre konstant und passen die Preise in €/d für das Schaltjahr und das auf das Schaltjahr folgende Jahr an, oder
Sie halten die Preise in €/d für alle Jahre konstant und passen die Preise in €/a für das Schaltjahr und das auf das Schaltjahr folgende Jahr an.
Mit freundlichem Gruß
Ihr BDEW-Forum Datenformate |
Ja
|
Beate Becker |
Klaus Keller |
Beate Becker |
Jörg Freiershausen |
|
Nein
|
-------------Stefan Seidel-------------30.08.2023 17:15
Antworvorschlag erstellt
Antwort veröffentlicht
-------------Beate Becker-------------23.04.2024 13:28
|
Nein
|
Nein
|
|
INVOIC MIG 2.8a
|
Abgeschlossen
|
Kann die Netznutzungsrechnung (PID 31002) auch für Durchleitung an Arealnetzbetreiber nutzen.
|
BDEW-Formate sind nur für BNetzA-Prozesse verpflichtend |
06.07.2023
|
2023-01819 |
|
|
Wenn ich als Verteilnetzbetreiber Strom an einen Arealnetzbetreiber durchleite, habe ich an dieser Stelle ja keine Marktlokation sondern nur eine Messlokation. Kann ich diese im LOC Segment der INVOIC für die Netznutzungsabrechnung verwenden oder geht hier nur eine manuelle Papierrechnung?
Hintergrund: aktuell gibt es Anfragen von Dienstleistern die ein Arealnetz zur Belieferung von Endkunden aufbauen wollen.
Im Voraus recht vielen Dank für Ihre Rückmeldung.
|
2023-07-06 15:12:09 |
Sehr geehrter Marktteilnehmer,
sobald in einer Geschäftsprozessbeschreibung (GPKE, Geli Gas, ...) ein Sequenzdiagramm entsprechende Hinwiese zur verpflichtenden Nutzung der edi@energy-Formate gibt, sind diese zu verwenden.
Im von Ihnen skizzierten Fall scheint das (noch) nicht der Fall zu sein, daher gibt es aus unserer Sicht zwei Varianten:
- Papierrechnung
- bilaterale Nutzung eines elektronischen Formats (z.B. PID 31002) mit entsprechenden Abweichungen zur Vorgabe
Mit freundlichen GrußIhr BDEW-Forum Datenformate |
Ja
|
Klaus Keller |
Stefan Seidel |
Stefan Seidel |
Michael Hoffmann |
|
Nein
|
Antwortvorschlag an Herrn Seidel gesendet
-------------Klaus Keller-------------12.07.2023 15:06
-------------Amirhossein Forootanfard-------------23.04.2024 16:52
|
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 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
|
|
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
|
Wie dürfen die Energiemengen der Rück- und Vorwärtsposition zusammengefasst werden?
|
Die einzelnen Energiemengen der NN-Rechnung müssen in Höhe und Zeitraum mit den Energiemengen aus dem Lieferschein übereinstimmen. |
22.05.2023
|
2023-01762 |
|
|
Dürfen die Zeiträume der Leistung der Rück- und Vorwärtsposition zusammengefasst werden?
Ist es möglich im Rahmen einer gleitenden Nachberechnung die Zeiträume der Leistung zusammen zufassen?
Als Beispiel die INVOIC für März:
Vorwärtsberechnung: 01.01.2023 - 31.03.2023: 351 kW
Rücknahmeposition: 01.01.2023-28.02.2023: - 351 kW
|
2023-05-22 06:50:49 |
Sehr geehrter Forumsteilnehmer,
eine Zusammenfassung wie von Ihnen beschrieben, ist nicht erlaubt. Siehe auch folgende Forumsfrage.
Nach GPKE müssen die Energiemengen aus dem Lieferschein zu den angegeben Energiemengen aus der Netznutzungsrechnung im Zeitraum und der Höhe übereinstimmen. In Ihrem Beispiel wäre das nicht möglich, da sich die Zeiträume in der INVOIC überschneiden.
Freundliche GrüßeIhr Forum Datenformate |
Ja
|
Klaus Keller |
Stefan Seidel |
Stefan Seidel |
Michael Fuhrer |
|
Nein
|
Vorschlag an Herrn Seidel
-------------Thomas Seipt-------------22.05.2023 08:46
Der hinterlegte Antwortvorschlag wurde in der PG EBD abgestimmt, sollte nach Rücksprache mit Thomas aber nochmal in der AG R/Z geprüft werden. (inkl. der ausführlichen Antwort, auf die verwiesen wurde)
-------------Klaus Keller-------------14.05.2024 09:30
Veröffentlichung
|
Nein
|
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
|
|
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
|
Wie wird die vorgelagerte Netzebene bei singulär genutzten Betriebsmitteln abgerechnet?
|
Es können die Preise des vorgelagerten Netzbetreibers genutzt werden. |
16.03.2023
|
2023-01686 |
|
|
Sehr geehrte Damen und Herrn,
vielen Dank für die Möglichkeit hier eine Frage anbringen zu können. Diese bezieht sich auf die Abrechnung von Kunden mit Sonderentgelten für singulär genutzte Betriebsmittel (Artikel-ID 1-07-3-001).
Das Entgelt eines solchen Kunden setzt sich in der Regel zusammen aus dem Entgelt für die singulär genutzten Betriebsmittel sowie zuzüglich den Entgelten der vorgelagerten Spannungsebene. Für die Abrechnung bedeutet dies, dass dem Kunden zwei Artikel-ID zugewiesen würden (Artikel-ID für singuläre Netznutzung Artikel-ID 1-07-3-001 sowie die Artikel-ID für das entsprechende Jahresleistungspreissystem zur Abrechnung der Entgelte der vorgealgerten Netzebene). Dies ist möglich sofern die vorgelagerte Netzebene von dem gleichen Netzbetreiber betrieben wird. Es gibt aber auch Fälle in denen die vorgelagerte Netzebene einem anderen Netzbetreiber zuzurdnen ist. Wie wäre hier die Vorgehensweise? Müssten dann im elektronischen Preisblatt für diese Netzebene die Entgelte des vorgelagerten Netzbetreibers hinterlegt werden?
Denkbar wäre auch über die Artikel-ID 1-07-3-001 die gesamten vom Netznutzer zu zahlenden Entgelte abzurechnen inkl. der Entgelte für die vorgelagerte Netzebene, was aber zu Problemen bei unterjährigen Abschlagszahlungen führen würde.
Vielen Dank für Ihre Antwort vorab.
VG
Benjamin Schüssler
Thüga AG
|
2023-03-16 09:56:52 |
Sehr geehrter Marktteilnehmer,
ein pragmatischer Vorschlag wäre, dass sie die Preise des vorgelagerten Netzbetreibers unter den entsprechenden Artikel-ID in Ihr elektronisches Preisblatt an die betroffenen Lieferanten übernehmen.
Mit freundlichen GrußIhr BDEW-Forum Datenformate |
Ja
|
Beate Becker |
Klaus Keller |
Beate Becker |
Benjamin Schüssler |
|
Nein
|
Antwort veröffentlicht
-------------Amirhossein Forootanfard-------------23.04.2024 15:46
|
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 Artikel-ID sind bei Marktloaktionen mit Hochlasteitfenster zu nutzen?
|
Es sind die Artikel-ID zu hinterlegen, die in der Rechnung genutzt werden. |
09.01.2023
|
2023-01617 |
|
|
Bei der Zuordnung der abrechnungsnotwendigen Stammdaten zu einer Marktlokation mit individuellen Netzentgelten wird ein Teil des Jahres noch mit den normalen Netzentgelten abgerechnet,
da die Bedingungen für die individuellen Netzentgelte noch nicht bekannt sind (Hochlastzeitfenster und dessen Maximum).
Sind dann von Beginn des Jahres an sowohl die regulären Artikel (1-01-…), als auch die individuellen (1-07-…) zu hinterlegen und zu übermitteln?
|
2023-01-09 12:35:54 |
Sehr geehrter Marktteilnehmer,
Es sind die Artikel-ID zu hinterlegen, die in der Rechnung genutzt werden.
Mit freundlichen GrußIhr BDEW-Forum Datenformate |
Ja
|
Beate Becker |
Klaus Keller |
Beate Becker |
Claudia Kring |
|
Nein
|
Antwort veröffentlicht
-------------Amirhossein Forootanfard-------------23.04.2024 15:53
|
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
|
|
Codeliste der Artikelnummern und Artikel-ID 5.2
|
Eingegangen
|
Was ist die Unterscheidung zwischen Steuerbarkeit und Erweiterter Steuerbarkeit?
|
Die Unterscheidung zwischen Steuerbarkeit und Erweiterter Steuerbarkeit ist die Zeitspanne. |
30.08.2022
|
2022-01469 |
|
|
Was ist der Unterschied zwischen den neueren Artikel-IDs wie z.B.
1-02-0-012 Grundpreis-/ Arbeitspreissystem Marktlokation der Kategorie steuerbare Wärmepumpe
mit erweiterter Steuerbarkeit Arbeitspreis (Einheit: €/kWh)
und
1-02-0-004 Grundpreis-/ Arbeitspreissystem Marktlokation der Kategorie steuerbare Wärmepumpe
Arbeitspreis (Einheit: €/kWh)
Was ist unter 'erweiterter Steuerbarkeit' zu verstehen?
Muss jeder Netzbetreiber diese Preise anbieten?
|
2022-08-30 09:05:02 |
Sehr geehrter Marktteilnehmer,
die Unterscheidung zwischen Steuerbarkeit und Erweiterter Steuerbarkeit ist die Zeitspanne in der steuernd eingegriffen werden kann. Bei der Erweiterten Steuerbarkeit ist die Zeitspanne größer und somit das Netznutzungsentgelt niedriger.Der Netzbetreiber braucht nicht beide Varianten anbieten bzw. braucht keine preisliche Unterscheidung vornehmen.
Mit freundlichen GrußIhr BDEW-Forum Datenformate |
Ja
|
Beate Becker |
Klaus Keller |
Beate Becker |
Claudia Kring |
|
Nein
|
Antwort veröffentlicht
-------------Amirhossein Forootanfard-------------23.04.2024 15:18
|
Nein
|
Nein
|
|
Codeliste der Artikelnummern und Artikel-ID 5.2
|
Eingegangen
|
Was ist die Unterscheidung zwischen Steuerbarkeit und Erweiterter Steuerbarkeit?
|
Die Unterscheidung zwischen Steuerbarkeit und Erweiterter Steuerbarkeit ist die Zeitspanne. |
08.08.2022
|
2022-01455 |
|
|
Was ist der Unterschied zwischen reiner Steuerbarkeit und Steuerbarkeit mit "erweiterter Steuerbarkeit" ?
(Beispiel Artikel ID 1-02-0-003 und 1-02-0-011)
|
2022-08-08 16:19:42 |
Sehr geehrter Marktteilnehmer,
die Unterscheidung zwischen Steuerbarkeit und Erweiterter Steuerbarkeit ist die Zeitspanne in der steuernd eingegriffen werden kann. Bei der Erweiterten Steuerbarkeit ist die Zeitspanne größer und somit das Netznutzungsentgelt niedriger.
Mit freundlichen GrußIhr BDEW-Forum Datenformate |
Ja
|
Beate Becker |
Klaus Keller |
Beate Becker |
Lusine Kloos |
Kapitel 3.1.2
Unterscheidung folgender Artikel-IDs aufgrund Bezeichnung schwierig:
1-02-0-003 und 1-02-0-011
1-02-0-004 und 1-02-0-012
1-02-0-006 und 1-02-0-013 |
Nein
|
Antwort veröffentlicht
-------------Amirhossein Forootanfard-------------23.04.2024 14:34
|
Nein
|
Nein
|
|
Codeliste der Artikelnummern und Artikel-ID 5.2
|
Eingegangen
|
Wird die Information über eine Prepaymentzähler zusätzlich zur Artikel-ID über einen weiteren Code ausgetauscht?
|
Nein |
03.08.2022
|
2022-01448 |
|
|
Sehr geehrtes Forum,
Wie kann der LF die übermittelten Artikel-IDs für den Messstellenbetrieb bei kME mit Hilfe der Stammdaten entsprechend prüfen?
In der Codeliste sind Artikel-IDs für verschiedene Arten von Zählern hinterlegt. Für die meisten Zählertypen können wir anhand der in der UTILMD übermittelten Stammdaten die entsprechende Artikel-ID identifizieren (siehe Anhang Zuordnung_Messstellenbetrieb_Zaehler_zu_UTILMD.png)
Wie kann man aber anhand der Stammdaten einen Prepaymentzähler erkennen?
Vielen Dank
|
2022-08-03 12:14:39 |
Es ist richtig, dass Sie in diesem Fall nicht überprüfen können, ob Ihnen der Netzbetreiber über ein anderes Stammdatum mitgeteilt hat, dass in dieser Messlokation ein Prepaymentzähler verbaut ist. |
Ja
|
Beate Becker |
Klaus Keller |
Beate Becker |
Anja Meier |
|
Nein
|
Antwort veröffentlicht
-------------Amirhossein Forootanfard-------------23.04.2024 15:28
|
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
|
|
PRICAT AHB - informatorische Lesefassung 2.0a
|
In Bearbeitung
|
Muss bei einer korrigierten Initialmeldung eine Vorgängerversion angegeben werden, wenn die Initialmeldung durch eine CONTRL oder APERAK abgelehnt wurde?
|
Nein, es darf keine Vorgängerversion bei einer korrigierten Initialmeldung angegeben werden. |
01.03.2023
|
2023-01671 |
|
|
Sehr geehrte Damen und Herren,
auf unserer Seite stellt sich die Frage, wie folgendes Konflikszenario aufgelöst werden soll?
Der Lieferant lehnt das initiale Preisblatt (1. Version) mit negativer CONTRL oder APERAK ab und bringt damit zum Ausdruck, dass er das Preisblatt nicht verarbeiten kann. Eine bilaterale Klärung wird i. d. R. vom Lieferanten mit dem Hinweis abgelehnt, dass eine korrigierte Version übermittelt werden soll.
Jede nachfolgende Version, die anschließend versendet wird, soll jedoch auf die Vorgängerversion referenzieren. Das hat zur Folge, dass der Lieferant auch alle folgenden Preisblätter ablehnt, weil ihm die 1. Preisblattversion fehlt.
Oder gibt es unterschiedliche Ausprägungen, je nach dem, ob es sich um den Versand einer korrigierten Preisblattversion oder um den Versand einer neue Preisblattversion (neue Gültigkeit) handelt?
Vielen Dank im voraus.
MIt freundlichen Grüßen
Stadtwerke Kleve GmbH
i. A. Lashof
|
2023-03-01 16:51:37 |
Sehr geehrter Marktteilnehmer,
bei Ablehnung einer PRICAT per CONTRL oder APERAK muss der Versender davon ausgehen, dass diese PRICAT beim Empfänger so behandelt wird, als ob die PRICAT nicht zugestellt wurde. Im Falle eines Fehlers auf Seiten des Senders muss er diesen korrigieren und die PRICAT in der korrigierten Fassung versenden. Bei der initialen Versendung wird auch bei der Korrektur keine Referenz auf die Vorgängerversion angegeben. Sollte der Fehler auf Seiten des Empfängers liegen, müssen Sie die abgelehnte Version erneut einspielen.
Freundliche Grüße, Ihr BDEW-Forum Datenformate
Freundliche Grüße,
Ihr BDEW-Forum Datenformate |
Ja
|
Thomas Seipt |
Klaus Keller |
Thomas Seipt |
Michael Lashof |
|
Nein
|
-------------Klaus Keller-------------02.03.2023 07:38
Antwortvorschlag erstellt und an Herrn Seidel und Seipt zur QS gesendet
-------------Thomas Seipt-------------15.08.2024 10:02
AG: 12.08.2024 |
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
|
|
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
|
|
PRICAT AHB 2.0a
|
Eingegangen
|
Kann das RFF+ACW auf "Muss" gesetzt werden?
|
Nein |
17.01.2023
|
2023-01623 |
|
|
Wir bekommen seit 01.10. vermehrt mehrere Preisblätter von Netzbetreibern zugesendet, die den gleichen Gültigkeitsbeginn haben, aber in denen das Segment RFF+ACW (Referenznummer einer vorangegangenen Nachricht) nicht aufgeführt ist. Das führt natürlich zu Fehlern bei der Gültigkeitszuordnung. Eine Ablehnung per APERAK bei fehlendem RFF+ACW ist aber auch nicht möglich da das Segment mit dem Operand "Soll" bestückt ist.
Eine Prüfung ist daher, auch laut Aussage der Allgemeinen Festlegungen nicht möglich.
Auf welchem anderen Wege (außer dem bilateralen) ist eine Ablehnung hier möglich?
Vielleicht könnte man ja auch den Operanden von Soll in Muss abändern.
Die Antwort des Tickets 2018-00087 des Forum Datenformate hat die Fragestellung schon einmal in ähnlicher Weise aufgegriffen, aber nicht wirklich durchdringend beantwortet.
Viele Grüße
Jacob Gottwald
|
2023-01-17 10:55:00 |
Sehr geehrter Markteilnehmer,eine Änderung auf "Muss" ist nicht möglich, da im Initialprozess keine Referenz auf die Vorgängerversion angegeben werden kann. In dem von Ihnen beschriebenen Fall ist somit nur eine bilaterale Klärung mit dem Sender der PRICAT möglich.Mit freundlichen GrüßenIhr BDEW-Forum Datenformate |
Ja
|
Thomas Seipt |
Klaus Keller |
Thomas Seipt |
Jacob Gottwald |
PRICAT Anwendungshandbuch 2.0a Seite 12
Allgemeine Festlegungen Version 6.0a Seite 63
Frage aus Forum Datenformat: Ticketnummer 2018-00087 |
Nein
|
AG: 12.08.2024
-------------Thomas Seipt-------------15.08.2024 10:08
|
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
|
|
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
|
|
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
|
|
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
|
|
INVOIC MIG 2.8
|
Abgeschlossen
|
Müssen die Preiseinheiten im Preisblatt und Rechnung identisch sein ?
|
Zur einheitlichen Rechnungsprüfung sind die Vorgaben zur Preisblatterstellung einzuhalten. Die Angabe der Einheiten in der Rechnung folgt dem Preisblatt. |
16.09.2022
|
2022-01482 |
|
|
Rückfrage zur Angabe der Maßeinheit bei Preisen:
Guten Tag,
ab dem 01.10.22 sind die elektronischen Preisblätter zu versenden. Die Maßeinheit ist hier in vielen Fällen €/Tag. In unserem veröffentlichten PDF-Preisblatt und in der Abrechnung (in SAP) wird jedoch bisher die Maßeinheit €/Jahr (z.B. Leistungspreis oder Messkosten) verwendet.
Können wir abweichend von den Angaben in der PRICAT weiterhin die Maßeinheit €/Jahr in der INVOIC verwenden?
Im Voraus vielen Dank für Ihre Rückmeldung.
Grüße aus Saarbrücken
|
2022-09-16 12:27:22 |
Sehr geehrter Marktteilnehmer,
die Vorgaben zum Aufbaue des Preisblattes in der PRICAT-Nachrichten sind einzuhalten, natürlich auch bezgl. der verwendeten Bezugsgrößen bei Einheiten. Eine Abweichung zwischen kommuniziertem Preisblatt und den Einstellungen im Abrechnungssystem ist nicht möglich. Evt. vorher kommunizierte Preisblätter müssen erneut mit korrekten Einheiten versendet werden.
Anschlßend sind im Sinner einer einheitlichen Rechnungsprüfung ebendise Einheiten in der Rechnung anzugeben, die vorher im Preisblatt kommuniziert wurden.
Mit freundlichen GrußIhr BDEW-Forum Datenformate |
Ja
|
Klaus Keller |
Stefan Seidel |
Stefan Seidel |
Michael Hoffmann |
|
Nein
|
-------------Klaus Keller-------------20.09.2022 16:32
Antwortvorschlag erstellt und an Herrn Seidel gesendet
|
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 > 1 MW angegeben werden". Nun steht im der AWT in der Fußnote [8]: "Nur bei SEE, die mit thermischen Prozessen betrieben werden (d.h. wenn Energietraeger mit B01|B02|B03|B04|B05|B06|B09|B14|B15|B17|B20 vorhanden)". Für uns stellt sich die Frage, welches der beiden Kriterien ausschlaggebened ist. Wir vermuten dass die Fußnote [8] der AWT das sinnvollste Kriterium ist, da diese Daten für beispielsweise Solaranlagen obsolet wären.
Können wir in diesem Fall davon ausgehen, dass hier ein Fehler seitens Raida/Connect+ vorliegt oder entspricht die Fehlerbeschreibung dem tatsächlichen Kriterium?
|
2022-03-08 16:08:32 |
Sehr geehrter Fragesteller,
wie Sie bereits korrekt aus der Fußnote [8] der Anwendungstabelle zitiert haben, ist bei der Angabe des Energieträgers B16 (Solare Strahlungsenergie) die Angabe der „thermischen Zeiten“ nicht notwendig, da diese im Fall einer PV-Anlage gar nicht vorhanden sind.
Freundliche Grüße
Ihr Forum Datenformate |
Ja
|
Johannes Umbach |
Alexander Kramer |
Johannes Umbach |
Daniel Wagner |
Stammdaten AWT Seite 30: [8] Nur bei SEE, die mit thermischen Prozessen betrieben werden (d.h. wenn Energietraeger mit B01|B02|B03|B04|B05|B06|B09|B14|B15|B17|B20 vorhanden) |
Nein
|
-------------Johannes Umbach-------------15.03.2022 23:46
Vorbereitet für PG
in PG besprochen.
-------------Katia Schubert-------------24.03.2022 16:58
|
Nein
|
Nein
|
|
Stammdaten AWT 1.0
|
Abgeschlossen
|
Ist beim Element "Zuordnung_Speicher" das Feld bei der Meldung angereicherter Stammdaten eine verpflichtende Meldung für SEE vorzusehen?
|
Ja, für SEE mit zugeordneten Speichern ist dies an dieser Stelle verpflichtend anzugeben. |
28.01.2022
|
2022-01264 |
|
|
Hallo Forum Datenformate,
ich habe eine Frage zu den Bedingungen des Stammdaten-Formats des Redispatch 2.0.
Bei angereicherten Meldungen steht im AWT bei dem Feld "Zuordnung_Speicher" die Bedingung [9] (Wenn Typ mit SEE angegeben), im Gegensatz zu allen anderen Bedingungen fehlt hier allerdings ein "x" für Pflicht oder "o" für optional.
Daher ist nicht ersichtlich, ob bei Erfüllung der Bedingung die Zuordnung des Speichers Pflicht oder Wahl ist.
Aktuell gehen wir davon aus, dass es sich in diesem Fall um ein Wahlfeld handelt, wie sehen sie das?
Beste Grüße aus Aachen,
Jonas Diefenthal
|
2022-01-28 09:05:32 |
Sehr geehrter Herr Diefenthal,
wenn die TR vom Typ SEE ist und einen Speicher zugeordnet hat, ist die Angabe verpflichtend. Da es auch SEE ohne zugeordneten Speicher gibt, ist dies kein Pflichtfeld für alle SEE.
Mit freundlichem Gruß
Ihr BDEW-Forum Datenformate |
Ja
|
Johannes Umbach |
Henning Hots |
Johannes Umbach |
Jonas Diefenthal |
|
Nein
|
-------------Johannes Umbach-------------01.02.2022 21:41
Antworten für Abstimmung in PG vorbereitet
-------------Katia Schubert-------------02.02.2022 10:29
in PG besprochen |
Nein
|
Nein
|
|
Stammdaten AWT 1.0
|
Abgeschlossen
|
Umgang mit Angabe energieträgerspezifischer Daten und Nicht-Angabe des Energieträgers bei der initialen Stammdatenmeldung.
|
Die Angaben vorhandenen Angaben in der AWT sind konform mit der Festlegung BK6-20-061. |
20.01.2022
|
2022-01251 |
|
|
Hallo Forum Datenformate,
ich habe eine Frage zu den Bedingungen des Stammdaten-Formats des Redispatch 2.0.
Laut AWT Bedingung [8] dürfen Mindestbetriebszeit, Mindeststillstandzeit, Anfahrtzeit kalt/warm, Hochfahrzeitkalt/warm und Abfahrzeit nur bei bestimmten Energieträgern und auch nur bei SEEs versendet werden.
In initialen Meldungen ist allerdings kein Energieträger enthalten und eine Steuerbare Ressource, die diese Felder enthält, kann sowohl SEEs als auch SSEs gleichzeitig enthalten.
Daher ist nicht klar zu erkennen, wann die besagten Informationen gesendet werden müssen.
Dies betrifft sowohl das aktuelle als auch das zukünftige AWT der Stammdaten.
Wir gehen davon aus, dass entweder die Bedingung falsch ist oder das Feld Energieträger übermittelt werden müsste.
Sehen sie das genauso?
Beste Grüße aus Aachen,
Jonas Diefenthal
|
2022-01-20 14:41:41 |
Sehr geehrter Herr Diefenthal,
der Umfang der Stammdatenmeldung im Use-Case "Übermittlung von initialen Stammdaten" ergibt sich aus dem Festlegungsverfahren zur Informationsbereitstellung für Redispatch-Maßnahmen der Bundesnetzagentur (BK6-20-061). Hierin sind die von Ihnen angesprochenen Elemente enthalten, das ebenfalls von Ihnen angesprochene Element "Energieträger" hingegen nicht. Daher ist die aktuelle Ausprägung korrekt.
Die Angabe des "Energieträgers" ist erst in der Stammdatenanreicherung für den ANB ein Pflichfeld.
Mit freundlichem Gruß
Ihr BDEW-Forum Datenformate |
Ja
|
Johannes Umbach |
Henning Hots |
Johannes Umbach |
Jonas Diefenthal |
|
Nein
|
-------------Johannes Umbach-------------22.01.2022 05:50
zur Freigabe in PG
-------------Katia Schubert-------------25.01.2022 08:34
in PG besprochen |
Nein
|
Nein
|
|
Stammdaten AWT 1.0
|
Abgeschlossen
|
Gibt es eine Legende zu den verwendeten Symbolen/Werten in den Anwendungstabellen?
|
Eine Erläuterung steht in den Allgemeinen Festlegungen in Kapitel 6.18 Hinweise zum Lesen der Anwendungstabellen. |
24.06.2021
|
2021-01039 |
|
|
Gibt es eine Legende zu den verwendeten Symbolen/Werten in der Tabelle "Stammdaten AWT 1.0"?
|
2021-06-24 12:29:38 |
Sehr geehrter Fragesteller,
eine Erläuterung der verwendeten Symbole in den Anwendungstabellen für die Redispatch XML-Datenformate finden Sie in den Allgemeinen Festlegungen (ALF) in der Version 5.0 in Kapitel 6.18 Hinweise zum Lesen der Anwendungstabellen (AWT). Die Allgemeinen Festlegungen sind auf der EDI@Energy Plattform unter der Gruppierung "Formatübergreifende Dokumente" zu finden.
Eine Häufigkeit "0..1" bedeutet, dass dieses Element/Attribut technisch optional ist, da die Angabe nicht für jeden Prozess erforderlich ist. In den Use Case-Spalten und Zellen der AWT ist angegeben, für welche Prozesse und Prozessschritte diese Elemente/Attribute zu befüllen sind.
Mit freundlichem Gruß
Ihr BDEW-Forum Datenformate |
Ja
|
Sara Olszewski |
Henning Hots |
Sara Olszewski |
Julian Schweins |
Konkret geht es darum,
1) welche Bedeutung die "x" und leeres "Kreis-Symbol" in der AWT haben und
2) ob eine Häufigkeit "0..1" bedeutet, dass dieses Element/Attribut optional und nicht "required" ist? Sind nur Elemente/Attribute mit Häufigkeit "1..." und "required" verpflichtende Stammdaten?
Die verdwendeten Codes (z.B. Z01 etc.) sind soweit gut in der Formatbeschreibung erläutert. |
Nein
|
Wie in PG besprochen.
-------------Katia Schubert-------------27.07.2021 11:21
|
Nein
|
Nein
|
|
Stammdaten AWT 1.0
|
Abgeschlossen
|
Ist die Angabe des Lastgradienten immer erforderlich?
|
Nein, die Angabe des Lastgradienten ist nicht immer erforderlich. |
08.06.2021
|
2021-01028 |
|
|
Die Bundesnetzagentur schreibt in "Festlegungsverfahren zur Informationsbereitstellung für Redispatch-Maßnahmen (BK6-20-061), Anlage Informationsbereitstellung für Redispatch-Maßnahmen" folgendes zu den Lastgradienten in den Stammdaten (S. 9):
"Darunter ist die durchschnittliche Leistungsänderungsgeschwindigkeit
innerhalb des Leistungsbereiches zwischen Mindesterzeugungsleistung
und Nennleistung bei Leistungserhöhung, abgeleitet aus der
Zeitdauer der Leistungsänderung zwischen Mindesterzeugungsleistung
und Nennleistung, zu verstehen. Die Mitteilung ist nur bei Lastgradienten
kleiner 20 % PROD_nenn pro Minute erforderlich."
Die Angabe der Lastgradienten ist also nicht für jede SR erforderlich. Im XML-Schema sind die Lastgradienten jedoch (auch nach den Anpassungen vom 03.06.) Pflichtfelder. Wie passt das zusammen? Handelt es sich hier um einen Fehler im XML-Schema? Oder gibt es hier einen Default-Wert, den man setzen kann, wenn eine Angabe nicht erforderlich ist?
|
2021-06-08 16:50:45 |
Sehr geehrter Marktteilnehmer,
vielen Dank für den Hinweis. Wir stimmen Ihnen zu und werden dies über eine konsolidierte Lesefassung mit Fehlerkorrekturen korrigieren.
Freundliche Grüße,
Ihr BDEW-Forum Datenformate |
Ja
|
Sara Olszewski |
Henning Hots |
Sara Olszewski |
Malte Otten |
|
Nein
|
|
Nein
|
Nein
|
|
ActivationDocument FB 1.0
|
Abgeschlossen
|
Was bedeutet: "Die DocumentIdentification hat je Absender und je Dokumententyp eindeutig zu sein."?
|
Die DocumentIdentification muss je Absender und Dokumententyp eindeutig sein. Bei Aktualisierungen dieses Dokuments wird es bei gleicher DocumentIdentification mit einer höheren Version gesendet. |
03.03.2022
|
2022-01308 |
|
|
Sehr geehrte Damen und Herren,
in der Beschreibung zur Documentenidentification heißt es: "Die DocumentIdentification hat je Absender und je
Dokumententyp eindeutig zu sein. Bei der Bildung der Identifikation ist auf Groß- und Kleinschreibung zu achten
(case-sensitive)."
Wir haben bis zu 73 Versionen für Aktivierungen je Anlage als Lieferant erhalten. Die in den Nachrichten verwendete DocumentIdentification war in jeder Version dieselbe. Nun fragen wir uns ob dies so korrekt sein kann und wir evtl. etwas nicht korrekt interpretiert haben.
Vielen Dank im Voraus für Ihre Antwort.
|
2022-03-03 16:05:23 |
Sehr geehrte Fragestellerin,
der von Ihnen geschilderte Sachverhalt klingt plausibel. Im konkreten Fall des ActivationDocument bezieht sich eine Nachricht auf einen konkreten Tag. Das bedeutet, dass es sich für einen Tag hinsichtlich der DocumentIdentification um ein Dokument und somit eine DocumentIdentification handelt. Auftretende Aktualisierungen dieses Dokuments, wie bspw. neue Abrufe, werden somit mit der DocumentIdentification der erstmalig für den Tag, sowie der Kombination aus Absender und Dokumententyp, versandten Nachricht mit einer entsprechend höheren Version versendet.
Freundliche Grüße,Ihr Forum Datenformate |
Ja
|
Johannes Umbach |
Henrike Janissen |
Johannes Umbach |
Grit Neumann |
|
Nein
|
-------------Johannes Umbach-------------15.03.2022 23:19
Vorbereitet für PG
in PG besprochen.
-------------Katia Schubert-------------24.03.2022 16:55
|
Nein
|
Nein
|
|
ActivationDocument FB 1.0
|
Abgeschlossen
|
Woher weiß der EIV, wie eine Anlage im Prognosemodell bei Abruf im Aufforderungsfall fahren muss?
|
Bei Anlagen im Prognosemodell und Aufforderungsfall muss der Abruf als Sollwertabruf durchgeführt werden. |
10.01.2022
|
2022-01234 |
|
|
Als Vorgabe des Netzbetreibers per Abruf (ActivationDocument) sind Delta-Anweisungen (in MW) oder Sollwertanweisungen (in %) möglich. Es ist aber nicht vorgesehen, die vorgegebene Fahrweise in MW angeben zu können.
Die Fragen dazu:
1. Ist es richtig, dass sich der tatsächlich vorgeschriebene Abruf als Differenz zu den ursprünglich abgegebenen Planungsdaten (im Planwertmodell) bzw. zur Prognose des Netzbetreibers (im Prognosemodell) ergibt?
2. Wie kann der EIV im Prognosemodell/Aufforderungsfall wissen, wie die Anlage gefahren werden muss? Ihm ist nur die Delta-Anweisung bekannt, nicht aber die Bezugsgröße, also die ursprünglich vorgesehene Fahrweise.
|
2022-01-10 15:13:29 |
Sehr geehrte Fragestellerin,
bei Anlagen im Prognosemodell und Aufforderungsfall muss der Abruf als Sollwertabruf durchgeführt werden, damit der EIV die Anlage entsprechend richtig steuern kann. Ein Deltaabruf kann nur mit Anlagen im Planwertmodell durchgeführt werden, da sich die Fahrweise nach Abruf aus der geplanten Leistung abzüglich der abgerufenen Deltamenge ergibt.
Viele Grüße,
Ihr BDEW-Forum Datenformate |
Ja
|
Johannes Umbach |
Henrike Janissen |
Johannes Umbach |
Johannes Umbach |
|
Nein
|
-------------Johannes Umbach-------------10.01.2022 15:14
Fragen erstellt
-------------Johannes Umbach-------------11.01.2022 21:21
Anworten hinzugefügt, fertig für Besprechung
-------------Katia Schubert-------------12.01.2022 16:13
in PG besprochen |
Nein
|
Nein
|
|
PlannedResourceScheduleDocument FB 1.0
|
Eingegangen
|
Wie ist der Zusammenhang der Leistungswerte Pmin und wRDV- bei Meldung der Planungsdaten?
|
Für wRDV- ist maximal die Differenz aus PROD und Pmin zulässig. |
01.03.2022
|
2022-01304 |
|
|
Ich habe eine Frage zum Zusammenhang der Werte Pmin und RDV- bei den Planungsdaten.
Eine KWK Anlage mit den Stammdaten:
Bruttonennleistung: 2MW
Fahrbare_Mindesterzeugungsleistung: 1MW
soll für den Zeitraum X in Vollast laufen.
Die Anlage nimmt nicht am Regelleistungsmarkt teil und es gibt keine technischen Einschränkungen.
Bei den Planungsdaten werden folgende Werte übermittelt:
PROD = 2MW
PMAX = 2MW
RDA+- = RDA-- = 0
PRL+- = SRL+- = 0
MRL+ = MRL- = 0
BES+ = BES- = 0
RDA+- = 0
wRDV- = 1MW? oder 2MW?
PMIN = 1MW?
Ist das korrekt so?
Die Anlage kann ja theoretisch auch komplett abgeschaltet werden. Ist also für das negative Redispatchvermögen die Differenz aus PROD und Pmin oder der gleicher Wert wie in PROD anzugeben?
Gibt es ein Dokumente wo die Werte genauer beschrieben sind als im Dokument "BDEW-Branchenlösung Redispatch 2.0 - Datenaustausch-, Bilanzierungs- und Abrechnungsprozesse - Mai 2020"?
|
2022-03-01 10:08:14 |
Sehr geehrter Fragesteller,
das negative wärmegebundene Redispatchvermögen (wRDV-) entspricht der aktivierbaren Wirkleistungsreduzierung einer hocheffizienten KWK-Anlage. Das negative Redispatchvermögen (RDV-) entspricht der aktivierbaren freien elektrischen Leistung einer Anlage in negativer Richtung ohne einen Eingriff in die Kraft-Wärme-Kopplung.
In diesem Fall entspricht der Wert für wRDV- maximal der Differenz aus PROD und Pmin. Folglich ist wRDV- = 1 MW zu melden.
Auch wenn kein RDV vorhanden ist, müssen die Zeitreihen für RDV mitgemeldet werden.
Der Zusammenhang der Leistungswerte wird im Dokument "BDEW-Branchenlösung Redispatch 2.0 - Datenaustausch-, Bilanzierungs- und Abrechnungsprozesse - Mai 2020" in Kapitel 1.3 in der Abbildung auf Seite 171 veranschaulicht.
Mit freundlichem Gruß
Ihr BDEW-Forum Datenformate |
Ja
|
Martin Schaumann |
Gina Völsgen |
Martin Schaumann |
Dennis Atabay |
|
Nein
|
in PG besprochen
-------------Katia Schubert-------------24.03.2022 16:41
|
Nein
|
Nein
|
|
PlannedResourceScheduleDocument FB 1.0
|
Eingegangen
|
Welche Meldung muss durch den EIV erfolgen, wenn der Abruf des ANB durch den EIV nicht erfüllt werden kann?
|
Der EIV übermittelt eine Aktualisierung der Planungsdaten an den ANB |
28.02.2022
|
2022-01301 |
|
|
Ich habe eine Frage zur Übermittlung von Planungsdaten für folgenden Anwendungsfall:
D-2:
Für Zeitraum X wurden bereits Planungsdaten vom EIV an den ANB mit den Werten PROD=10, RDV+=0, RDV-=5, RDA-=0, RDA+=0 übermittelt.
H-4 (4h vor Zeitraum X):
De EIV sendet auf Grund technischer Einschränkungen angepasste Planungsdaten mit dem Werten PROD=5, RDV+=0, RDV-=0, RDA-=0, RDA+=0
Der ANB sendet nahezu zeitgleich einen Abruf für Zeitraum X (Sollwertvorgabe) mit dem Wert 7 (bzw. 70%), bei dem die aktualisierten Planungsdaten noch nicht berücksichtigt sind.
Wie ist das weitere vorgehen seitens des EIVs bzw. ANBs?
Welche Daten müssen nun vom wem gesendet werden und wie sähen die entsprechenden Werte aus?
|
2022-02-28 19:20:17 |
Sehr geehrter Fragesteller,
der EIV schickt gemäß Use Case 3.1 (Anlage 2, FL BK6-20-059) als Antwort auf einen RD-Abruf des ANB eine Aktualisierung der Planungsdaten. Aus den gesendeten Planungsdaten des EIV ist ersichtlich, ob der Abruf durchgeführt werden kann.
Im oben beschriebenen Anwendungsfall hat der anfNB anhand der aktualisierten Planungsdaten seinen Abruf erneut zu dimensionieren.
Mit freundlichem Gruß
Ihr BDEW-Forum Datenformate |
Ja
|
Martin Schaumann |
Gina Völsgen |
Martin Schaumann |
Dennis Atabay |
|
Nein
|
in PG besprochen
-------------Katia Schubert-------------17.03.2022 11:37
|
Nein
|
Nein
|
|
PlannedResourceScheduleDocument FB 1.0
|
Eingegangen
|
Wie ist RDA+/RDA- im Störungsfall zu melden?
|
Im Störungsfall ist RDA+/RDA- = 0 zu melden |
28.02.2022
|
2022-01300 |
|
|
Ich habe eine Frage zu den in den Planungsdaten zu übermittelnden Werten RDA+ und RDA- in folgendem Anwendungsbeispiel:
D-2:
Für Zeitraum X wurden bereits Planungsdaten vom EIV an den ANB mit den Werten PROD=10, RDV+=0, RDV-=5, RDA-=0, RDA+=0 übermittelt.
H-4 (4h vor Zeitraum X):
Der ANB sendet einen Abruf für Zeitraum X (Sollwertvorgabe) mit dem Wert 7 (bzw. 70%)
De EIV sendet daraufhin angepasste Planungsdaten mit dem Werten PROD=7, RDV+=3, RDV-=2, RDA-=3, RDA+=0
H-2 (2h vor Zeitraum X):
Die Anlage hat einen ungeplanten Störungsfall der über den Zeitraum X hinaus bestehen wird.
Der EIV sendet aktualisierte Planungsdaten mit den Werten PROD=0, RDV+=0, RDV-=0
Wie sind hierbei die Werte "RDA+" bzw. "RDA-" zu wählen?
|
2022-02-28 19:16:45 |
Sehr geehrter Fragesteller,
im Störungsfall, der eine vollständige Nichtverfügbarkeit zur Folge hat, ist RDA+/RDA- = 0 zu melden. Dies gilt sowohl für eine geplante als auch ungeplante Nichtverfügbarkeit.
Mit freundlichem Gruß
Ihr BDEW-Forum Datenformate |
Ja
|
Martin Schaumann |
Gina Völsgen |
Martin Schaumann |
Dennis Atabay |
|
Nein
|
in PG besprochen
-------------Katia Schubert-------------17.03.2022 11:23
|
Nein
|
Nein
|
|
PlannedResourceScheduleDocument FB 1.0
|
Abgeschlossen
|
Ist das Pattern zu den Zeitintervallangaben in den Planungsdaten richtig?
|
Pattern mit dem Flavor PCRE2 (PHP>=7.3) wird bei Zeitintervallangaben nicht akzeptiert. |
27.07.2021
|
2021-01066 |
|
|
Wird das Pattern der Elemente TimePeriodCovered/v und Period/TimeInterval/v (d.h. den Zeitintervallangaben) in den Planungsdaten immer als Regulärer Ausdruck akzeptiert?
|
2021-07-27 11:13:40 |
Sehr geehrte Fragestellerin,
bei der Überprüfung von Pattern einer XML-Schema-Datei können unterschiedliche Flavor verwendet werden. Bei dem Pattern der Elemente TimePeriodCovered/v und Period/TimeInterval/v (d.h. den Zeitintervallangaben) wird das Trennzeichen / zwischen beiden Zeitangaben von dem Flavor PCRE2 (PHP>=7.3) nicht akzeptiert. Bei den anderen gängigen Flavor, wie z.B. Java 8, Python oder auch PCRE (PHP<7.3) wird das Pattern immer akzeptiert.
Hinweis: Dies betrifft auch andere XML-Datenformate mit Zeitintervallangaben.
Mit freundlichem Gruß
Ihr BDEW-Forum Datenformate |
Ja
|
Martin Schaumann |
Gina Völsgen |
Martin Schaumann |
Katia Schubert |
|
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 |
Katia Schubert |
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 |
Katia Schubert |
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
|
