Skip to main content

Veröffentlichte Fragen


Thema Status Kurzfrage Kurzantwort Anlagedatum Ticketnummer Frage Anlagedatum Hauptantwort Veröffentlicht Bearbeiter Vertreter Aktueller Bearbeiter Fragender Textbezug Archiviert Kommentar Änderungsantrag zu erstellen Änderungsantrag erstellt
REQOTE / QUOTES / ORDERS / ORDRSP AHB WiM 1.3 Abgeschlossen Wie ist das Segment SG32 RFF+AVE in der QUOTES zu nutzen Im RFF+AVE werden die MaLo-IDs angegeben, welche durch die POG unter die Abrechnung fallen 04.12.2018 2018-00162 Hallo, wir haben eine Frage bezüglich der Nutzung des Segmentes SG32 RFF+ AVE (Referenz auf ID weiterer Marktlokationen) im Anwendungsfall 15002 der QUOTES "Angebot zur Abrechnung des Messstellenbetriebs vom MSB an den LF" Wir erhalten als LF die QUOTES mit zwei LIN Segmentgruppen. NAD+DP' LOC+172+IDMaLoLieferung' LIN+1++9990001000798:Z01' PIA+1+01-01-Z25:Z06' QTY+47:1:H87' LIN+2++9990001000798:Z01' PIA+1+01-01-Z25:Z06' QTY+47:1:H87' RFF+AVE:IDWeitereMaLo' Der MSB interpretiert das Segment RFF+AVE (Referenz auf ID weiterer Marktlokationen) als Möglichkeit uns als LF die Abrechnung anderer Marktlokationen de Anschlussnutzuer im identischen Objekt mit anzubieten. Wie zu sehen ist, ist hier auch eine separate Artikelnummer aufgeführt. Aus unserer Sicht ist die Nutzung des SG32 RFF+AVE nur bei einem iMS möglich, wenn die Messung(en) der anderern Marktlokation(en) im POG Bündel enthalten sind. Wir benötigen eine Klarstellung für die Nutzung des SG32 RFF+AVE Vielen Dank vorab 2018-12-04 10:32:24 Sehr geehrter Martteilnehmer, die Formate basieren auf den vorgegebenen Prozessen / Festlegungen. im SG32 RFF+AVE (Referenz auf ID weiterer Marktlokationen) sind die Marktlokationen zu nennen, welche über die POG (Preisobergrenze) eines POG Bündels enthalten sind.  Die Interpretation, Messlokationen anderer Marktlokationen eines Anschlussnutzers gesamthaft einen LF anzubieten, können wir aus dem Prozess nicht entnehmen. Somit kann dieses Segment auch nicht für eine derartige Nutzung verwendet werden. Viele Grüße Ihr Forum Datenformate Ja Holger Kampmann Thomas Fellhauer Holger Kampmann Holger Weickenmeier Nein Antwortvorschlag erstellt. Ich hatte dies mit Holger schon vorab angesprochen. Schaut mal ob Ihr damit leben könnt. Fühlt Euch frei zu ändern. -------------Holger Weickenmeier-------------04.12.2018 10:32 Ich bin mit der Antwort einverstanden und habe nur den ersten Satz redaktionell angepasst. -------------Holger Kampmann-------------04.12.2018 11:06 Nein Nein
REQOTE / QUOTES / ORDERS / ORDRSP AHB WiM 1.3 Abgeschlossen Kann das Abrechnungsbeginndatum für die MSB Abrechnung von dem Ausführungsdatum in der QUOTES abweichen? Das Ausführungsdatum aus der QUOTES entspricht dem Abrechnungsbeginn der MSB Abrechnung 19.04.2018 2018-00010 Sehr geehrte Damen und Herren, Wir hatten eine QUOTES „Angebot zur Abrechnung des Messstellenbetriebs vom MSB an den LF“ (PID 15002) erhalten und dieser zugestimmt. In dieser QUOTES war das DTM+203 (Ausführungsdatum) mit dem Datum 01.10.2017 gefüllt. In der INVOIC erhalten wir nun für den Abrechnungszeitraum ein Abrechnungsbeginn, welcher von dem Ausführungsdatum aus der QUOTES abweicht. Der MSB möchte die Abrechnung schon ab einem früheren Zeitpunkt abrechnen. Gehen wir richtig davon aus, dass mit dem DTM+203 (Ausführungsdatum) aus der QUOTES der Abrechnungsbeginn gemeint ist und somit das Abrechnungsbeginndatum nicht abweichen, bzw. zumindest nicht vor dem Ausführungsdatum liegen kann? Vielen Dank vorab. 2018-04-19 10:04:51 Sehr geehrter Marktpartner,   vielen Dank für Ihren Beitrag im Forum Datenformate.   Das DTM+203 der QUOTES ist in der Nachrichtenbeschreibung wie folgt beschrieben. Bemerkung: Dieses Segment wird benutzt, um das Datum anzugeben, ab dem das Angebot zur Übernahme der Rechnungsabwicklung MSB gilt.   Somit kann in der INVOIC kein Abrechnungsbeginn vorhanden sein, welcher vor dem Datum aus dem Ausführungsdatum der QUOTES liegt. Im Ausführungsdatum der QUOTES ist das Datum zu nennen, ab dem der MSB abrechnen möchte.   Viele Grüße Ihr Forum Datenformate Ja Holger Kampmann Thomas Fellhauer Holger Kampmann Holger Weickenmeier Nein Ich habe da mal einen Antwortvorschlag erstellt. Den stimme ich mit Herrn Kampmann noch ab. Inhalt war so wie in der Sitzung diese Woche besprochen. -------------Holger Weickenmeier-------------19.4.2018 11:8 Nein Nein
INVOIC MIG 2.6e Abgeschlossen Darf der Gemeindesteuerrabatt in SG52-MOA+125 übertragen werden ? In SG52-MOA+125 hat die Übertragung des Gemeindesteuerrabatts nichts verloren 20.11.2018 2018-00157 Sehr geehrte Damen und Herren, einige Marktpartner übermitteln bei Gewährung eines Gemeinderabatts in der SG52 für den Steuersatz 0 den Betrag des Gemeinderabatts im Segment MOA+125. Im Fall einer INVOIC-Rechnung, die sowohl Zeilen mit dem Steuersatz 19% als auch 0% (z.B. Sperrkosten) sowie einen Gemeinderabatt enthält, ergibt sich dabei folgendes Problem: es ist nicht möglich, die Korrektheit der Summe in SG52 gegenüber den einzelnen Rechnungspositionen (SG26 etc.) zu prüfen, weil es je nach Absender variiert, ob der Gemeinderabatt im MOA+125-Segment enthalten ist oder nicht. Ist es daher zulässig, den Gemeinderabatt im MOA+125-Segment der SG52 aufzuführen? Vielen Dank im Voraus. Mit freundlichen Grüßen Sebastian Weiße 2018-11-20 11:02:03 Hallo Herr Weiße, das Vorgehen, den Gemeindesteuerrabatt in SG25-MOA+125 zu übertragen, widerspricht (über die von Ihnen beschriebene Problematik der Nachvollziehbarkeit hinaus) der Erläuterung in SG50-MOA: "Die Summe aller Rechnungspositionen (SG27 MOA+203 zzgl. USt.) ergibt den Rechnungsbetrag („77“). Nun werden der vorausbezahlte Betrag inkl. USt. („113“), sofern vorhanden, und der Gemeinderabatt („Z01“), sofern vorhanden, subtrahiert und das Ergebnis als fälliger Betrag („9“) übertragen. Bei einer Rechnungsstornierung ist das Vorzeichen zu negieren. " Fazit: In SG52-MOA+125 hat die Übertragung des Gemeindesteuerrabatts nichts verloren. Freundliche Grüße, Ihr BDEW Forum Datenformate Ja Klaus Keller Stefan Seidel Klaus Keller Sebastian Weiße Nein -------------Klaus Keller-------------21.11.2018 13:57 Vorschlag für AG R/Z erstellt -------------Klaus Keller-------------27.11.2018 15:37 Vorschlag wurde angenommen und der letzten Sitzung und wird daher genauso veröffentlicht Nein Nein
INVOIC MIG 2.6e Abgeschlossen Abrechnung von Rundsteuerempfängern über MSB- oder Netznutzungsrechnungen ? Abrechnung von Rundsteuerempfängern über MSB-Rechnung 24.10.2018 2018-00145 Sehr geehrte Damen und Herren, wir, als Netzbetreiber / grundzuständiger Messstellenbetreiber, verschicken nur getrennte INVOIC an die Lieferanten. Uns ist unklar, ob Rundsteuerempfänger (die dem Gerät zugeordnet sind) als Steuereinrichtung gesehen werden und über die MSB-Rechnung oder über die Netznutzungsrechnung abgerechnet werden müssen. Gibt es hierzu gesetzliche Grundlagen? Wenn die Rundsteuerempfänger über die Netznutzung abgerechnet werden, welche Artikelnummern müssen dann genutzt werden? Müssen dann auch UTILMD Daten geändert werden? Über eine schnelle Rückmeldung würden wir uns freuen 2018-10-24 12:08:16 Sehr geehrte Fragestellerin, abhängig davon wer Eigentümer des Rundsteuerempfängers ist, muss auch die Abrechnung erfolgen. Da es sich um die Abrechnung des Messstellenbetriebes handelt, muss die Artikelnummer 9990001000798 genutzt werden. Es ist dabei zu beachten, dass wenn neben der Messstellenbetriebsabrechnung des Messstellenbetreibers (POG) auch in der Netznutzungsrechnung ein Messstellenbetriebsentgelt abgerechnet wird, es zu Klärungsaufwand zwischen Lieferant und Netzbetreiber kommen kann. Auswirkungen auf die UTILMD gibt es nicht. Freundliche Grüße, Ihr BDEW-Forum Datenformate Ja Klaus Keller Stefan Seidel Klaus Keller Jessica Eke Nein -------------Klaus Keller-------------31.10.2018 12:44 für die Webko um 13:00 Uhr der AG R/Z vorgemerkt -------------Klaus Keller-------------27.11.2018 15:30 Besprechungsergebnis der AG R/Z veröffentlicht Nein Nein
INVOIC MIG 2.6e Abgeschlossen Müssen die Zeitpunkte der Zählerstände zu den Zeitpunkten des Zeitintervalls der NN-Rechnung passen? Zusammenhang zwischen Zeiträumen der Netznutzungs- und Mehr-/Mindermengenabrechnung 12.10.2018 2018-00135 Sehr geehrte Damen uns Herren, ein Transportkunde von uns akzeptiert unsere INVOIC für die Mehr- und Mindermengenabrechnung nicht, da die Zeiträume der Verbrauchsmeldungen / Zählerstände (MSCONS) nicht zu den Zeiträumen der Abrechnung per INVOIC passen. Beispiel: MSCONS der Zählerstände: Beginn 03.01.2018 Abrechnung per INVOIC: Beginn 01.01.2018 Der Kunde fordert zur Plausibilisierung der MMMA den Zählerstand zum 01. eines Monats, da die Abrechnung (INVOIC-Zeitraum) bei uns immer vom 01., 6 Uhr bis zum folgenden 01. um 6 Uhr geht (Gasmonat). Da wir eine Ablesung der Zähler zum 01. eines jeden Monats um 6 Uhr nicht gewährleisten können, stehen wir nun schon lange Zeit mit dem Kunden in der Diskussion. Bei uns betrifft dieses Problem nur einen einzigen Kunden. Die weiteren akzeptieren unsere Vorgehensweise. Uns stellen sich nun die Fragen: Wie wird das bei anderen Unternehmen gehandhabt, wenn die beiden genannten Zeiträume nicht identisch sind? Was sehen Sie für Lösungsmöglichkeiten bei diesem Problem? Vielen Dank im Voraus. Mit freundlichen Grüßen 2018-10-12 06:48:28 Sehr geehrte Fragestellerin, wenn Ihre Netznutzungsrechnung am Anfang eines Monats beginnen bzw. enden soll, dann müssen für den 1. des Monat Zählerstände vorliegen. Diese können entweder abgelesen oder abgegrenzt (Ersatzwerte) sein. Für die Mehr-/Mindermengenabrechnung muss genau der Netznutzungszeitraum die Grundlage sein. Freundliche Grüße, Ihr BDEW-Forum Datenformate Ja Klaus Keller Stefan Seidel Klaus Keller Nicole Stockkamp Nein -------------Klaus Keller-------------27.11.2018 15:25 Besprechungsergebnis der AG R/Z veröffentlicht -------------Klaus Keller-------------24.10.2018 07:39 zur Klärung an AG R/Z geschickt, hier ein paar Hinweise eines Kollegen aus der MEMI-Abrechnung: " Grundlage der MeMi-Abrechnung ist die „Bilianzierte Menge“ und die NN-Abrechnung. Es kann durchaus sein, dass die „Bilanzierte Menge“ am 01.01. beginnt und die NN-Abrechnung am 03.01. In diesem Fall würde die MeMi-INVOIC völlig korrekt am 01.01. beginnen und die MSCONS zur NN am 03.01. Die MSCONS zur „Bilanzierten Menge“ muss natürlich am 01.01. in diesem Beispiel beginnen. Zu klären wäre demnach: Von welcher MSCONS ist hier die Rede? Die der „Bilanzierten Menge“ oder die der NN-Abrechnung? " Nein Nein
INVOIC MIG 2.6e Abgeschlossen Wie hat die Netznutzung für Straßenbeleuchtungen zu erfolgen? keine Regelung zur Abrechnung der Straßenbeleuchtung 02.10.2018 2018-00125 Ist der Netzbetreiber berechtigt die Leistung (bezogen auf Stromlieferstellen - Straßenbeleuchtung) in Rechnung zu stellen bzw. seine Netzentgelte (Arbeitspreis) entsprechend registrierender Lastgangmessung, obwohl uns in der Anmeldebestätigung das Bilanzierungsverfahren SLP bestätigt wurde? 2018-10-02 08:19:10 Sehr geehrter Fragesteller, für die Abrechnung der Straßenbeleuchtung ist uns derzeit keine Regelung bekannt. Freundliche Grüße, Ihr BDEW-Forum Datenformate Ja Klaus Keller Stefan Seidel Klaus Keller Michael Hein Sehr geehrte Damen und Herren, wir treten in der Rolle als Stromlieferant auf und beliefern seit dem 01.01.2018 Straßenbeleuchtungen im Fremdnetz mit Strom. In der vom Netzbetreiber erhaltenen Anmeldebestätigung (UTILMD) wurde uns mitgeteilt, dass es sich um SLP-Lieferstellen handelt. Als wir vom Netzbetreiber INVOIC (JVR) erhalten haben, mussten wir feststellen, dass dieser einen Leistungswert angesetzt und verrechnet hatte. Ebenso wurde der Arbeitspreis für registrierende Lastgangmessung berücksichtigt anstatt wie erwartet der Arbeitspreis für SLP-Lieferstellen. Da uns gegenüber die Lieferstellen als SLP bestätigt wurden sind wir der Auffassung das der Netzbetreiber seine INVOIC korrigieren muss. Der Netzbetreiber argumentiert, dass bereits in den vergangenen Jahren (mit anderen Lieferanten) so gehandhabt wurde und dies aus seiner Sicht korrekt sei. Bitte teilen Sie uns Ihre Sichtweise mit. Wenn möglich anhand Auszügen aus Verordnungen oder Gesetzestexten. Vielen Dank! Nein -------------Klaus Keller-------------05.10.2018 10:41 keine Ahnung ! -------------Klaus Keller-------------27.11.2018 15:34 Besprechungsergebnis der AG R/Z veröffentlicht Nein Nein
INVOIC MIG 2.6e Abgeschlossen Wie ist mit dem Messstellenbetrieb in der Netznutzungsrechnung umzugehen, wenn im Abrechnungszeitraum ein mME eingebaut wurde? Messstellenbetrieb ist innerhalb des Abrechnungszeitraums abzugrenzen 13.09.2018 2018-00118 Hallo, die Frage zu Positionen mit Null als Betrag kam schon mehrfach auf, aber in Bezug auf die Rechnungsstellung des Messstellenbetriebes für MME noch nicht. Ist es korrekt/gestattet den Messstellenbetrieb für moderne Messeinrichtungen ab dem Umbaudatum in den Netzbetreiberrechnungen als separate Zeitscheibe mit Null zu berechnen? Wir erwarten den Messstellenbetrieb separat vom Messstellenbetreiber und hätten nun die MSB-Position im selben Zeitraum von zwei Marktpartnern gestellt bekommen, wenn auch vom NB als Null. Für die automatisierte Rechnungsprüfung eine schwierige Konstellation. Bitte schaffen Sie Klarheit. Vielen Dank Heiser 2018-09-13 08:40:01 Sehr geehrter Marktteilnehmer, der Messstellenbetrieb wird durch den NB bis zum Ausbau der kME erbracht. Daher ist in der Netznutzungsrechnung die Position mit Hilfe der DTM-Segmente genau auf das Zeitintervall einzugrenzen, in dem der NB diese Leistung erbringt. Mit freundlichem Gruß Ihr BDEW Forum Datenformate Ja Klaus Keller Stefan Seidel Klaus Keller Michael Heiser Antwort auf Frage vom 10.05.2012 "Leistungen .. aufgrund vertraglicher Situation nicht erbracht wurden ... dürfen nicht erscheinen", aber Kurzantwort "rechtfertigen keine APERAK" Antwort auf Frage vom 30.04.2014 "wenn weitere Postionen ungleich Null sind ... ist Ablehnung per REMADV nicht möglich." Nein -------------Klaus Keller-------------20.09.2018 16:32 an Frau Becker zur Abstimmung in AG R/Z gesendet -------------Beate Becker-------------26.09.2018 14:02 AG: beantwortet und veröffentlicht Nein Nein
INVOIC MIG 2.6e Abgeschlossen Für welche Rechnungen ist das "neue Gemeinderabattverfahren" anzuwenden ? Das "neue Gemeinderabattverfahren" gilt für alle neuen Rechnungen unabhängig vom Abrechnungszeitraum. 23.07.2018 2018-00074 Sehr geehrte Damen und Herren, wir bekommen aktuell Netzentgeltrechnungen, die noch das "alte" Gemeinderabattverfahren und in Kombination mit SG42 anwenden. Die Frage lautet: Wie wird der Betrag in SG52 MOA+125 ermittelt? Das Schema der erhaltenen INVOIC sieht dabei in SG50 und SG52 beispielhaft folgendermaßen aus: MOA+77:119.00 MOA+Z01:11.90 MOA+9:107.10 TAX+7+VAT+++:::19+S MOA+125:90.00 MOA+161:17.10 MOA+115:107.10 MOA+77 entspricht dabei der Summe der Einzelpositionen aus SG27 MOA+203 zzgl. USt. mit dem jeweils angegebenen Satz von 19 %. Aus unserer Sicht müsste daher der steuerpflichtige Betrag MOA+125 der Summe der Einzelpositionen aus SG27 MOA+203 ohne USt. entsprechen. Eine Nutzung des SG42 wäre in dieser Form nicht möglich, da darin keine USt. berücksichtigt wird. Teilen Sie diese Ansicht? 2018-07-23 09:51:27 Sehr geehrter Fragesteller, laut Auszug aus Kapitel 2 des Anwendungshandbuchs INVOIC/REMADV 2.3c Das Bundesministerium der Finanzen (BMF) hat am 24. Mai 2017 ein Schreiben zur umsatzsteuerlichen Behandlung des Gemeinderabatts an den BDEW, den deutschen Städtetag und den VKU versendet. Entgegen der ursprünglich vom Ministerium getätigten Aussagen kommt es nun doch zu einer Änderung der Besteuerungspraxis. Der Gemeinderabatt schmälert nicht länger die Bemessungsgrundlage der Leistung, die der Netzbetreiber erbringt, sondern stellt stattdessen ein zusätzliches Entgelt für die Leistung der Gemeinde (d. h. die Gewährung der Wegenutzung für den Netzbetrieb) dar. Eine Übergangsregelung mit Nichtbeanstandung der Vergangenheit gewährt das BMF nicht, so dass die Grundsätze des Schreibens auf alle noch offenen Fälle anwendbar sind. Die Segmentgruppe 42 und die neue Ausprägung der Segmentgruppe 50 werden ausschließlich benötigt, wenn in der Netznutzungsrechnung der Gemeinderabatt abgerechnet wird. Der Gemeinderabatt wird – wie bisher auch – auf Positionsebene ausgewiesen, jedoch aufgrund der Vorgaben expliziter. Die Bemessungsgrundlage des Gemeinderabatts ergibt sich aus der vertraglichen Vereinbarung zwischen Netzbetreiber und Gemeinde unter Berücksichtigung des BMF-Schreibens. gilt die "neue Vorgehensweise" für alle Rechnungen, sodass die von Ihnen beschriebene Anwendung der "alten Vorgehensweise" im aktuellen Format nicht zulässig ist. Freundliche Grüße, Ihr BDEW Forum Datenformate Ja Klaus Keller Stefan Seidel Stefan Seidel Alexander Berwing Nein -------------Klaus Keller-------------25.07.2018 15:48 Kurzfrage, -antwort und Antwort formuliert und an Herrn Seidel zur Prüfung geschickt -------------Stefan Seidel-------------25.07.2018 20:35 Teile diese Ansicht, würde aber über AG R/Z absichern lassen wollen. -------------Beate Becker-------------26.09.2018 13:30 AG: ok Nein Nein
INVOIC MIG 2.6e Abgeschlossen Wie wird SG50 MOA+77 berechnet ? SG50 MOA+77 ist die Summe aller SG27 MOA+203 zzgl. USt. 02.07.2018 2018-00058 Sehr geehrte Damen und Herren, wir haben eine Frage zum folgenden Satz aus der Beschreibung des SG50 MOA+77 (Seite 49 im INVOIC-MIG 2.6e): „Die Summe aller Rechnungspositionen (SG27 MOA+203 zzgl. USt.) ergibt den Rechnungsbetrag („77“).“ Wir gehen davon aus, dass dieser wie folgt zu interpretieren ist: es werden die SG27 MOA+203-Segmente nach dem Steuersatz gruppiert, der im jeweiligen zugehörigen SG34 TAX-Segment der gleichen SG26 angegeben ist. Für jede Gruppe werden die Beträge der MOA+203-Segmente summiert und der jeweilige Umsatzsteuerbetrag (ggf. 0) auf die Summe aufgeschlagen. z.B. (dargestellt sind nur SG27 MOA+203 und SG34 TAX) MOA+203:100' TAX+7+VAT+++:::19+S' MOA+203:50' TAX+7+VAT+++:::19+S' MOA+203:30' TAX+7+VAT+++:::0+S' MOA+203: 20' TAX+7+VAT+++:::0+S' 19% Steuersatz wären also auf die Summe von 150 anzuwenden, 0% auf die Summe von 50. Also ergibt sich (100 +50) *1.19 + (30 +20) * 1.00 = 228.50 und damit MOA+77:228.5' Dies scheint uns zwar selbstverständlich, allerdings gibt es Marktpartner, die im Rahmen einer gleitenden Nachberechnung von Zeilen mit Gemeinderabatt dieser Regel nicht folgen. Bei diesen Fällen berechnet der Marktpartner die Steuer anhand eines Mechanismus, der nicht aus den einzelnen Positionen der INVOIC-Rechnung ableitbar ist. Beispielsweise haben wir eine Rechnung mit 170 Positionen (d.h. 170 Wiederholungen der SG26) erhalten. Die Summe aller 170 Beträge in den SG27 MOA+203-Segmenten ergibt 536.18. In allen 170 SG34 TAX-Segmenten ist ein Steuersatz von 19 angegeben. Daher erwarten wir im SG50 MOA+77 einen Betrag von 536.18 * 1.19 = 638.05. Übermittelt wird aber ein Betrag von 954.78. Ist unsere Interpretation des Satzes auf Seite 49 im MIG korrekt und eine solche Rechnung damit abzulehnen? Vielen Dank im Voraus. Mit freundlichen Grüßen Sebastian Weiße 2018-07-02 09:42:35 Hallo Herr Weiße, Ihre Erläuterungen der entsprechenden Passage mittels Ihres Beispieles sind zutreffend. Ebenso empfehlen wir die Ablehnung einer Nachricht, die wie von Ihnen geschildert, eine entsprechende Differenz bei Bildung der Summe von SG27 MOA+203 Beträgen zzgl. USt. ausweist. Freundliche Grüße, Ihr Forum Datenformate   Hinweis: die folgende Passage wurde aufgrund von anstehenden Diskussionen in den BDEW-Gremien entfernt: Zur Vermeidung weiterer Rundungsdifferenzen empfehlen wir allerdings statt dieser Formel:  (100 +50) *1.19 + (30 +20) * 1.00 = 228.50 passend zum Aufbau der einzelnen Segmente eine Prüfung gemäß dieser Formel: 100*1.19 + 50*1.19 + 30*1.00 +20*1.00 = 228.50 Ja Klaus Keller Stefan Seidel Stefan Seidel Sebastian Weiße Nein -------------Klaus Keller-------------05.07.2018 14:00 Einschätzung des Fragenden trifft nach meiner Prüfung zu -------------Klaus Keller-------------16.07.2018 13:37 Feedback von Herrn Seidel ergänzt -------------Stefan Seidel-------------17.07.2018 13:42 veröffentlicht -------------Beate Becker-------------26.09.2018 10:56 Hinweis eingefügt und neu veröffentlicht Nein Nein
INVOIC MIG 2.6e Abgeschlossen Abrechnung des Messtellenbetiebs, wenn eine moderne Messeinrichtung (mME) sowie ein Wandler in einer Messlokation vorhanden sind Zwei Positionen mit der Artikelnummer 9990001 00079 8 25.05.2018 2018-00039 Wir sind Dienstleister für Netzbetreiber, neu den Messstellenbetreiber sowie Lieferant. Aktuell wird die Messstellenbetriebsabrechnung umgesetzt. Hieraus ergibt sich eine Fragestellung. Hier eine kurze Erläuterung: Für die Erstellung von INVOIC in der modernen Zählerwelt ist laut Artikelnummernliste 4.1f nur die EAN 9990001 00079 8 zulässig. Nun gibt es Anlagen, in denen eine moderne Messeinrichtung (mME) sowie ein Wandler verbaut sind. Das Format PRICAT sieht hierfür verschiedene Parameter vor - in diesem Fall wären das Z25 sowie Z26. Beide Positionen haben unterschiedliche Preise (z.B. 20,00 € - mMe und 25,00 € - Wandler). Bei Erstellung der INVOIC-Nachricht geht der Hersteller unserer Abrechnungssoftware nun her und gibt ein Segment mit der EAN 9990001 00079 8 und einem addierten Preis von 45,00 € aus. Auf unsere Nachfrage kam die Antwort, dass man sich an die Vorgaben der EDIFACT-Nachrichten hält. Nun stellt sich die Frage der Prüfbarkeit beim Rechnungseingang. Der Lieferant bezieht sich hierbei auf die PRICAT. Diese hat zwei Positionen (Z25 und Z26). Die INVOIC hat eine Preiszeile mit der korrekten EAN, jedoch einen Preis, der nicht in der PRICAT steht (er wurde ja addiert). Die Verwendung der EAN für Wandler wäre eine Alternative - ist jedoch gemäß Handbuch für die EAN nicht zulässig. Unter den gegebenen Voraussetzungen erscheint uns nur die mehrmalige Angabe der EAN mit den beiden Preisen als praktikabel. Hierbei wäre jedoch der Abrechnungszeitraum jeweils identisch. Unseres Erachtens ist die Verwendung der selben EAN in einem identischen Abrechnungszeitraum nicht zulässig. Wie ist die Sichtweise des BDEW? Wie soll der Konflikt gelöst werden? Freundliche Grüße Jörg Kattner 2018-05-25 11:35:17 Sehr geehrter Herr Kattner, die INVOIC muss zwei Positionen enthalten, da die PRICAT – so haben wir Sie verstanden – auch zwei Positionen enthält, eine für den Messstellenbetrieb der mME und eine Zweite für den Betrieb des Wandlers. Damit passt die INVOIC zur PRICAT. Dieses Vorgehen hat auch den Vorteil, dass falls sich im Abrechnungszeitraum der Preis einer der beiden Positionen ändern würde, nur für diese der Zeitraum aufgeteilt werden muss und für die Zweite der gesamte Zeitraum in einer Position abgerechnet werden kann. Freundliche Grüße, Ihr Forum Datenformate Ja Klaus Keller Stefan Seidel Klaus Keller Jörg Kattner Artikelnummernliste 4.1f - Seite 6 EDI@Energy PRICAT 1.1 - Seite 21 Nein -------------Stefan Seidel-------------25.05.2018 11:48 Vorschlag erstellt -------------Klaus Keller-------------20.06.2018 14:08 Vorschlag in AG R/Z zur Veröffentlichung freigegeben Nein Nein
INVOIC MIG 2.6e In Bearbeitung SG52 MOA 125 bei Gemeinderabatt ohne USt USt-Betrag bei Gemeinderabatt 22.05.2018 2018-00033 Betreff: INVOIC - SG52 MOA 125 bei Gemeinderabatt ohne USt Sehr geehrte Damen und Herren, wie ist in folgendem Fall zu verfahren? INVOIC mit nicht steuerbarem Umsatz und Gemeinderabatt Rechnungsbetrag Netto = Brutto = 100,00 € Gemeinderabatt = 10,00 € Fälliger Betrag = 90,00 € Wie ist im SG52 MOA, Qualifier 125 die Besteuerungsgrundlage zu füllen: 90,00 € oder 100,00 € ? Besten Dank im Voraus. Mit freundlichen Grüßen Rolf Blättner 2018-05-22 10:10:30 Hallo Herr Blättner, nach unserer Einschätzung müssen die betroffenen Segmente im Fuß wie folgt gefüllt sein bei Ihrem Beispiel: MOA+77:100' (Rechnungsbetrag brutto) MOA+Z01:10' (Gemeinderabatt) TAX+7+VAT+++:::0+S' MOA+125:100' MOA+161:0' Viele Grüße, Ihr Forum Datenformate   Ja Klaus Keller Stefan Seidel Stefan Seidel Rolf Blättner Nein -------------Klaus Keller-------------22.05.2018 13:21 Antwort erstellt und an Herrn Seidel zur Prüfung geschickt -------------Stefan Seidel-------------22.05.2018 15:09 DA auch Herr Metten sein o.k. gegeben hat, veröffentlicht Nein Nein
UTILMD MIG 5.1g Abgeschlossen Dürfen die Codes der Temperaturmessstellen nur numerisch sein? Die Codes der Temperaturmessstellen sind laut Nachrichtenbeschreibung (MIG) alphanumerisch 09.11.2018 2018-00152 Sehr geehrte Damen und Herren, ist es im Prozess vorgesehen, dass uns ein Marktpartner entweder im Zuge des Lieferbeginns oder einer Stammdatenänderung eine alphanummerische Temperaturmessstelle zukommen lässt? Wir bekommen vermehrt anstatt dem Zahlencode Bsp. (10126) für Schwerin die Kombination SCHW126 gemeldet. Dies kann unser System so nicht verarbeiten da das System für die Temperaturmessstelle nur Nummerische Werte akzeptiert. Können Sie uns nun bitte mitteilen, ob wir unser System für die Zuordnung der Messstelle nun auch auf alphanummerische Messstellen ausdehnen müssen. Danke Mit freundlichen Grüßen 2018-11-09 11:19:42 Sehr geehrte Marktteilnehmer, welchen Wertebereich die UTILMD in einem Datenelement übermitteln kann ist grundsätzlich der Nachrichtenbeschreibung zu entnehmen. In den AHBs sind ev. weitere Einschränkungen für den Anwendungsfall beschrieben. Für diese Frage genügt die Nachrichtenbeschreibung, da in den Anwendungsfällen keine weiterführenden Informationen vorhanden sind. Die Temperaturmessstelle wird im LOC+Z02 im Datenelement DE3225 angegeben. Für dieses Datenelement findet sich in der Spalte "Format" die Information "an..17". Der Inhalt kann also alphanumerisch bis zu 17 Stellen lang sein. Somit ist die Übermittlung von alphanumerischen Codes grundsätzlich möglich. Viele Grüße  Ihr Forum Datenformate   Ja Holger Weickenmeier Jessica Riekhoff Jessica Riekhoff Daniel Kaiser Nein Das ist nicht meine Baustelle -------------Beate Becker-------------12.11.2018 16:37 Antwortvorschlag erstellt. An Jessica zum gegenlesen gegeben. -------------Holger Weickenmeier-------------13.11.2018 10:16 Nein Nein
UTILMD MIG 5.1g In Bearbeitung Umgang mit den Codes Z01 für "Struktur Personennamen" und Z02 "Struktur der Firmenbezeichnung" Anhand der Betreffenden Codes kann kein Rückschluss auf ein Kundensegment getroffen werden. 27.08.2018 2018-00097 Codes Z01 Person/Z02 Firma in den NAD Segmenten: Lt. Anwendungshandbuch UTILMD handelt es sich bei den genannten Codes um „Muss“-Felder. Der NB verwendet jedoch immer den Indikatior Z02 Firma ohne eine Differenzierung vorzunehmen. Als Folge kann der Kunde nicht ordnungsgemäß dem jeweiligen Kundensegment (Privat oder Gewerbe) zugeordnet werden. Eine Abweichung der Festlegung zum eingegangenen Prozess würde jedoch ständig zu Datenabweichungen in den Bestandslisten führen. Zudem gibt es Unterschiede zwischen den Indikatioren bei den im Prozess übertragenen Feldern. Muss der NB die Differenzierung zwischen Z01 und Z02 zur Mitteilung an den LF vornehmen, oder muss er die vom LF in der Beantwortung vorgenommene Änderung zwingend übernehmen? 2018-08-27 09:39:05 Sehr geehrter Marktteilnehmer, Ihre Frage ist vielschichtiger. Darum versuchen wir hier eine Klarstellung / Antwort in Gruppierungen zu schaffen. Aussage der Codes Z01 für "Struktur Personennamen" und Z02 "Struktur der Firmenbezeichnung".Anhand der beiden Codes können Sie keine Zuordnung zu einem Kundensegment vornehmen. In den Allgemeinen Festlegungen Kapitel 1.16 Darstellung von Namen ist beschrieben was diese Codes aussagen und wie diese anzuwenden sind.Die Codes tragen aus diesem Grund auch das Wort "Struktur*" in der Bezeichnung.Auszug aus den Allgemeinen Festlegungen. Verwendung des DE3045:Anhand des DE3045 ist lediglich der Strukturaufbau beschrieben. Für eine Identifikation hat dieses keine Auswirkung. Z. B. ein MP führt einen Kunden als „Gewerbekunde“. In der An-meldung wird der Code Z01 (Struktur von Personennamen) verwendet. Dies darf nicht zu einer Nichtidentifikation bzw. einer Ablehnung führen. Der Aufbau ist ebenfalls in Kapitel 1.16 definiert Bei Angabe von Namen von Personen DE3045 = Z01 (Struktur von Personennamen):1. DE3036 = Familienname2. DE3036 = Vorname bzw. Rufname oder Initialen3. DE3036 = Zusätzliche Namensangaben4. DE3036 = Zusätzliche Namensangaben5. DE3036 = akademischer TitelBei Angabe der Firmenbezeichnung DE3045 = Z02 (Struktur der Firmenbezeichnung):1. DE3036 = Offizielle Firmenbezeichnung ggf. inkl. Rechtsform, Teil 12. DE3036 = Offizielle Firmenbezeichnung ggf. inkl. Rechtsform, Teil 23. DE3036 = Zusätzliche Namensangaben4. DE3036 = Zusätzliche Namensangaben5. DE3036 = nicht genutzt Die Unterscheidung durch diese Codes ist notwendig,  da das 5. DE3036 bei einer Struktur eines Firmennamens nicht genutzt wird. Im weiteren wird bei Code Z02 das 1. und 2. DE3036 als zusammenhängende Information gesehen, da Firmennamen auch länger als die max. 70 Zeichen eines DE 3036 sein können. Diese beiden Unterscheidungen sind für den Import notwendig.  Sollte ein Marktpartner die Struktur nicht einhalten, so ist er darauf hinzuweisen. Das DE3045 ist auch kein Datenelement, welches in den Stammdaten abgelegt ist, es spiegelt somit lediglich die Befüllung der Datenelemente wieder. Viele Grüße  Ihr Forum Datenformate   Ja Holger Weickenmeier Jessica Riekhoff Jessica Riekhoff Astrid Kever Nein @Jessica: Bitte gegenlesen. Das war die Originalfrage: Ich habe diese angepasst, da hier falsche Begriffe verwendet wurden. Prüfindikatoren Z01 Person/Z02 Firma Lt. Anwendungshandbuch UTILMD handelt es sich bei den genannten Prüfindikatioren um „Muss“-Felder. Der NB verwendet jedoch immer den Indikatior Z02 Firma ohne eine Differenzierung vorzunehmen. Als Folge kann der Kunde nicht ordnungsgemäß dem jeweiligen Kundensegment (Privat oder Gewerbe) zugeordnet werden. Eine Abweichung der Festlegung zum eingegangenen Prozess würde jedoch ständig zu Datenabweichungen in den Bestandslisten führen. Zudem gibt es Unterschiede zwischen den Indikatioren bei den im Prozess übertragenen Feldern. Muss der NB die Differenzierung zwischen Z01 und Z02 zur Mitteilung an den LF vornehmen, oder muss er die vom LF in der Beantwortung vorgenommene Änderung zwingend übernehmen? -------------Holger Weickenmeier-------------27.08.2018 17:18 -------------Stefan Seidel-------------09.10.2018 20:39 Tippfehler korrigiert Nein Nein
UTILMD MIG 5.1g Abgeschlossen Wie wird dem LFN mitgeteilt, dass der LFA eine Abmeldeanfrage mit APERAK abgelehnt hat Eine APERAK auf eine Abmeldungsanfrage stellt ein Fehler dar. Dieser ist vom Empfänger der APERAK zu klären. 17.05.2018 2018-00031 Im RFF+Z07 wird der "Ablehnungsgrund des dritten Beteiligten" übermittelt. Es gibt keinen definierten Wertevorrat. Es wird auf den Ablehnungsgrund aus der Abmeldungsanfrage verwiesen. Wie ist damit umzugehen wenn der Vorlieferant jedoch eine APERAK auf die Abmeldungsanfrage gesendet hat? Ist dann der APERAK-Grund (bspw. Z10) in diesem Segment anzugeben? 2018-05-17 11:36:41 Sehr geehrter Marktpartner, aus Ihrer Frage entnehmen wir, dass Sie sich in dem Anwendungsfall 11002 (Antwort auf Anmeldung) befinden und Sie eine Abmeldungsanfrage an einen LFA gesendet hatten, welcher Ihnen diese Abmeldungsanfrage mit einer APERAK quittiert hat. Wir haben Ihre Intension so verstanden, dass Sie in der Antwort auf die Anmeldung diese "Ablehnung" mittels APERAK dem LFN kommunizieren möchten. Laut beschriebenem Prozess ist, bei Erhalt einer APERAK, das Problem vom Empfänger der APERAK zu analysieren. Gerade bei dem APERAK Code Z10 (ID Unbekannt) könnte der LFN nicht viel mit dieser Information anfangen, wenn er diese in der Antwort (Ablehnung) auf die Anmeldung, erhält. Er könnte daraus nur ableiten, dass der NB die Abmeldungsanfrage an einen falschen Lieferanten gesendet hatte. Da Sie als NB hier eine APERAK erhalten haben, haben Sie hier Kenntnis darüber dass der LFA diese Nachricht nicht verarbeitet hat. Dies ist gleichzusetzen, als ob Sie als NB nie eine Abmeldeanfrage versendet hätten.  Aus diesen Gründen ist im SG6 RFF+Z07 (Ablehnungsgrund des dritten Marktbeteiligten) und dort im der Bemerkung des DE1154 auch korrekt.  "Ablehnungsqualifier des LF bzw. dritten Marktbeteiligten aus der Abmeldungsanfrage Status der Antwort" Die Probleme, bezüglich der APERAK sind in diesem Fall zwischen dem Sender der Abmeldungsanfrage und dem Sender der APERAK zu klären. Diese Probleme können nicht, durch Angabe der APERAK Codes in besagtem Segment, an den LFN ausgelagert werden. Eine Erweiterung des SG6 RFF+Z07 ist somit nicht notwendig. Viele Grüße Ihr Forum Datenformate   Ja Holger Weickenmeier Beate Becker Jessica Riekhoff Jörg Gruchenberg "Ablehnungsqualifier des LF bzw. dritten Marktbeteiligten aus der Abmeldungsanfrage " S. 79 Nein Diese Frage kam aufgrund einer Interferenz zwischen DREWAG und EnBW/ Yello. Hintergrung: Wir hatten als LF die Antwort auf die Anmeldung, und 4 Sekunden später, die Abmeldeanfrage erhalten. Die Abmeldeanfrage hat die Antwort überholt und somit, aus unserer Sicht, korrekt eine APERAK erzeugt. Herr Gruchenberg hat heute auch eine Frage unter der APERAK eingereicht. Frage an Jessica zum gegenlesen weitergeleitet. Ev. noch an die Kollegen der APERAK zum gegenlesen geben. -------------Holger Weickenmeier-------------17.05.2018 14:16 -------------Stefan Seidel-------------06.06.2018 08:55 habe aufgrund von Hinweisen ein paar Tippfehler korrigiert Nein Nein
Codeliste der OBIS-Kennzahlen 2.2f Abgeschlossen Nur OBIS-Kennzahlen aus dem Dokument Codeliste der OBIS-Kennzahlen sind in der Marktkommunikation zugelassen 08.11.2018 2018-00151 Sehr geehrte Damen und Herren, ein MSB / Netzbetreiber nutzt im Gas die Obiskennzahl 7-20:21.6.1. Diese Obiskennzahl wurde historisch für die Spitzenmenge aus dem Umwerter genutzt (Angabe in nm³ je Stunde). Die Obiskennzahl existiert in der Codeliste nicht (mehr) und wir konnten keinen Hinweis finden, ob die Obiskennzahl einfach entfallen ist oder ob es dafür eine Alternative gibt. Was können wir dem Marktpartner bezüglich der Benutzung dieser Obiskennzahl mitteilen? Vielen Dank für Ihre Mühen. Freundliche Grüße Oliver Kunz 2018-11-08 14:14:48 Sehr geehrter Herr Kunz, nur OBIS-Kennzahlen aus dem Dokument Codeliste der OBIS-Kennzahlen sind in der Marktkommunikation zugelassen. Die von Ihnen angegebene OBIS ist nicht im Dokument enthalten und damit in der Marktkommunikation nicht zu verwenden. Mit freundlichen Grüßen Ihr BDEW Forum Datenformate Ja Reinhard Döring Thomas Seipt Reinhard Döring Oliver Kunz Nein Nein Nein
Codeliste der OBIS-Kennzahlen 2.2f Abgeschlossen Siehe dazu die Dokumente Codeliste der OBIS-Kennzahlen und EDI@Energy Anwendungshilfe zu den Datenformaten des Interimsmodells 02.10.2018 2018-00126 Sehr geehrte Damen und Herren, im Rahmen der Messwerübertmittlung (MÜ-A bis MÜ-F) bei bestehenden iMS und vorhandener Doppeltarif-Marktlokation haben wir folgende Fragen: 1. Handelt es sich bei dem in der Codeliste-OBIS-Kennzahlen genannten "Zählerstand total" um den im GPKE aufgeführten "Gesamtzählerstand"? 2. Wie setzt sich der Zählerstand total zusammen bzw. muss dieser bei einer Doppeltarif-Marktlokation angegeben werden? 3. Ist der Zählerstand total mit der OBIS-Kennzahl 1-b:1.8.0 anzugeben? Vielen Dank vorab. 2018-10-02 09:52:22 Sehr geehrter Herr Böhme, zu Ihren Fragen. 1.) Hierbei handelt es sich einerseits um keine Frage zu dem Thema Datenformate und andererseits haben Sie nicht angegeben, welche Passage in der GPKE referenziert wird. Aus diesen Gründen können wir hier leider keine Antwort geben. 2.) Bei Zählerstand total handelt es sich um nicht tarifunterschiedene Zählerstände. Wann dieser anzugeben ist, ist in den Dokumenten Codeliste der OBIS-Kennzahlen und EDI@Energy Anwendungshilfe zu den Datenformaten des Interimsmodells beschrieben. 3.) Hier ist zu unterscheiden, ob es sich um ein intelligentes Messsystem oder um eine mME oder kME handelt. Details sind in den Dokumenten Codeliste der OBIS-Kennzahlen und EDI@Energy Anwendungshilfe zu den Datenformaten des Interimsmodells beschrieben.   Mit freundlichen Grüßen Ihr BDEW Forum Datenformate Ja Reinhard Döring Thomas Seipt Reinhard Döring Sebastian Böhme Codeliste-OBIS-Kennzahlen 2.2f, Seite 10, 3.3.1.2 Zwischen NB und LF auf Ebene der Messlokation GPKE, Anlage 1 zum Beschluss BK6-16-200, S. 70, 5.2.5.2.1.1 Regelmäßig zu übermittelnde Messwerte bei Bestehen eines iMS Nein Nein Nein
Codeliste der OBIS-Kennzahlen 2.2f Abgeschlossen Siehe Kapitel 3.1 im zugeordneten Dokument (Codeliste-OBIS-Kennzahlen_2_2f_Lesefassung_20170609.pdf) 24.07.2018 2018-00075 Sehr geehrte Damen und Herren, ich habe eine Frage zu den OBIS-Codes. Wenn bei einer Kommunikation zwischen NB und Lieferant die monatlichen Daten übertragen werden, dann ist in unseren Msconsdaten der Prüfidentifikator 13002 enthalten. Dieser ist nach meiner Lesart für Zählerstände zu setzen. Wenn in den Msconsdateien aber nicht Stände, sondern Vorschübe übertragen werden, was ist dann für ein Prüfidentifikator zu setzen? Wir hatten bislang die OBIS-Codes 1-1:1.6.1 für die Monatsleistung, 1-1:1.9.1 und 1-1:1.9.2 für Wirkarbeit, so wie 1-1:3.9.1 und 1-1:3.9.2 für die Blindarbeit. Es handelt sich um Lastgangzähler. Ich kann hier nichts Eindeutiges finden. Können Sie mir hier weiter helfen? M.f.G. Horst Schweinebraden 2018-07-24 12:28:28 Sehr geehrter Herr Schweinebraden, Leistungen (Werteart = Maximum) werden mittels dem OBIS-Code 1-b:1.6.e gekennzeichnet. Prüfidentifikator 13002. Zählerstände  für Wirkarbeit werden mit 1-b:1.8.e (Prüfidentifikator 13002) und die Energiemengen für Wirkarbeit mit 1-b:1.9.e (Prüfidentifikator 13009) übertragen. Lastgänge sind mittels OBIS-Code 1-b:1.29.e und Prüfidentifikator 13008 zu übertragen. Dies und weitere Definitionen sind im Kapitel 3.1 der Codeliste-OBIS-Kennzahlen beschrieben. Bei einem Lastgangzähler ist die Übertragung von Zählerständen nicht notwendig. Mit freundlichen Grüßen Ihr BDEW Forum Datenformate     Ja Reinhard Döring Thomas Seipt Reinhard Döring Horst Schweinebraden Nein Nein Nein
EDIFACT Utilities 14 - 006 Abgeschlossen aktuelle Version 14-007 von EDIFACT Utilities (Stand November 2018) 24.10.2018 2018-00146 Sehr geehrte Damen und Herren, EDIFACT Utilities funktioniert bei uns im Hause nur noch bedingt. Abgesendete Nachrichten werden grundsätzlich abgelehnt. Ist EDIFACT Utilities 14-006 auf dem aktuellsten Stand? Wird das Tool weiterhin supportet? Besten Dank für eine Beantwortung. Freundliche Grüße Gas-Union GmbH 2018-10-24 16:42:48 Sehr geehrter Marktpartner, die aktuell zum Download bereitgestellte Version ist die 14-007. Voraussichtlich bis Ende des Jahres 2018 wird die nächste Version verfügbar sein. Freundliche Grüße, Ihr BDEW-Forum Datenformate Ja Joachim Schlegel Klaus Keller Joachim Schlegel Steven Filbert Nein -------------Klaus Keller-------------05.11.2018 12:25 Antwort erstellt und veröffentlicht Nein Nein
EDIFACT Utilities 14 - 006 Abgeschlossen 17.09.2018 2018-00119 Hallo zusammen, wird es weiterhin Aktualisierungen von EDIFACT Utilities geben? Mit freundlichen Grüßen Sascha Landau 2018-09-17 09:28:02 Hallo Herr Landau, bisher sind uns keine gegenteiligen Planungen zur kostenlosen Bereitstellung der Software für den Markt durch die Westnetz GmbH bekannt. Bitte haben Sie jedoch Verständnis, dass wir hierzu in diesem Forum keine verbindlichen Prognosen für die Zukunft abgeben können. Viele Grüße, Ihr Forum Datenformate Ja Joachim Schlegel Klaus Keller Joachim Schlegel Sascha Landau Nein -------------Klaus Keller-------------20.09.2018 16:34 Antwort erstellt und veröffentlicht Nein Nein
EDIFACT Utilities 14 - 006 Abgeschlossen Gibt es eine Nachrichtenprüfung gegen Vorgaben der Anwendungshandbücher ? keine vollumfängliche AHB-Prüfung implementiert 13.06.2018 2018-00052 Hallo, wir haben mit der Edifact Utilities eine eingehende Zuordnungsliste Strom überprüft. Der Netzbetreiber hat das Feld Bilanzkreis nicht gefüllt. Das Feld ist gem. Handbuch meines Erachtens ein Pflichtfeld. Wir haben in den Utilities die Contrl/APERAK- Prüfung aktiviert. Es wird jedoch kein Fehler bezüglich der fehlenden Angabe des Bilanzkreises ausgegeben. Liegt hier ein Fehler vor oder gibt es Einstellungen, die hier eine Prüfung ausschließen? 2018-06-13 20:02:04 Sehr geehrte Fragestellerin, generell ist keine AHB-Prüfung im Funktionsumfang von EDIFACT Utilities ausgeprägt, Ausnahme sind wenige Prüfidentifikatoren für die Formate UTILMD WiM und GPKE. Bezgl. des von Ihnen geschilderten Falls im Rahmen der Kundenbestandsliste ist derzeit jedoch keine Erweiterung geplant, was somit die fehlende Anzeige eines APERAK-Fehlers erklärt. Freundliche Grüße, Ihr Forum Datenformate Ja Joachim Schlegel Klaus Keller Joachim Schlegel Melanie Täge Nein -------------Klaus Keller-------------20.06.2018 09:37 Rückfrage an Entwickler gestellt -------------Klaus Keller-------------02.07.2018 13:03 Antwort veröffentlicht nach Rückmeldung von Entwickler Nein Nein
EDIFACT Utilities 14 - 006 Abgeschlossen Start der Software durch startEdiUtilities.bat, bzw. edifact-utilities.jar 23.04.2018 2018-00011 Der Edifact Editor lässt sich nicht starten. Gibt es hier irgendwelche Probleme oder Tricks? 2018-04-23 09:24:32 Hallo Frau Reetz, nach dem Entpacken der Dateien im Unterverzeichnis: \EdifactUtilities kann die Software durch manuellen Klick im Explorer der Datei: startEdiUtilities.bat bzw. bei Nicht-Windows-Systemen: edifact-utilities.jar gestartet werden. Damit die Software gestartet werden kann, ist eine Java-Runtime 1.7.0 oder höher vorher zu installieren. Viele Grüße, Ihr Forum Datenformate Ja Joachim Schlegel Klaus Keller Joachim Schlegel Jessica Reetz Nein -------------Klaus Keller-------------24.4.2018 14:7 Frage beantwortet und veröffentlicht Nein Nein
Allgemeine Festlegungen 4.5 Abgeschlossen Fehler in der Änderungshistorie in Änderungs-ID 18063 18.10.2018 2018-00142 Hallo BDEW-Forum Datenformate, lt. Änderungs-ID 18063 für die neue Version, die ab 01.04.19 einzusetzen ist, gilt für das neue Kapitel 1.22.3 "Formatdefinitionen zu Operatoren an Datenelementen" die folgende Einschränkung: "Hinweis: Die Formatdefinitionen sind weder im Rahmen der Syntax- noch der Verarbeitbarkeitsprüfung zu berücksichtigen.". Wie ist dieser Hinweis zum neuen Code in der APERAK Z35 „Format nicht eingehalten“, der sowohl in der MIG als auch dem AHB eingeführt wurde, zu verstehen? Freundliche Grüße, Klaus Keller 2018-10-18 15:04:49 Hallo Herr Keller, danke für Ihren Hinweis. Der irreführende Eintrag in der Änderungshistorie ist dem Umstand geschuldet, dass hier eine Anpassung im Rahmen der Konsultationssitzung mit der BNetzA erfolgt ist, die in dieser Stelle des Dokumentes nicht umgesetzt wurde. Da es keine Fehlerkorrekturen zu fehlerhaften Änderungseinträgen gibt, ist der Hinweis zu ignorieren. Viele Grüße, Ihr Forum Datenformate Ja Holger Weickenmeier Beate Becker Holger Weickenmeier Klaus Keller Nein -------------Klaus Keller-------------18.10.2018 15:10 Antwortvorschlag erstellt Nein Nein
PRICAT MIG 1.1 Eingegangen Darf eine PRICAT abgelehnt werden, wenn das SG36 LIN nicht fortlaufend und damit nicht eindeutig bezeichent wird? Keine Ablehnung per CONTRL/APERAK bei Verstoß gegen forlaufende Nummerierung in LIN-Segment 17.10.2018 2018-00140 Hallo, in einer PRICAT werden mehrere Positionen übermittelt. Laut MIG ist das Datenelement 1082 mit einer fortlaufenden Nummer ( 1-n) zu befüllen. Dürfte eine Nachricht mittels CONTRL/APERAK abgelehnt werden, welche diese Regel nicht einhält? Beispiel: LIN+1++9990001000798:Z01' PIA+1+Z26_Z09_BezeichnungXXX:Z06' IMD+X+Z26+Z09:::Wandler' PRI+CAL:0::::ANN' LIN+1++9990001000798:Z01' PIA+1+Z26_Z10_BezeichnungXXX:Z06' IMD+X+Z26+Z10:::Wandler' PRI+CAL:0::::ANN' LIN+1++9990001000798:Z01' PIA+1+Z26_Z11_BezeichnungXXX:Z06' IMD+X+Z26+Z11:::Wandler' PRI+CAL:0::::ANN' LIN+2++9990001000798:Z01' PIA+1+Z30_BezeichnungXXX:Z06' IMD+C+Z30' PRI+CAL:25.21::::ANN' LIN+2++9990001000798:Z01' PIA+1+Z21_BezeichnungXXX:Z06' IMD+C+Z21' PRI+CAL:84.03::::ANN' LIN+3++9990001000798:Z01' PIA+1+Z29_BezeichnungXXX:Z06' IMD+C+Z29' PRI+CAL:33.61::::ANN' In diesem Beispiel werden mehrere Positionen mit gleicher Positionsnummer übermittelt. Kann eine solche Nachricht abgelehnt werden? Wenn ja mit welchen Gund? (Mir fällt spontan nur eine APERAK mit Z31 ein) Oder darf die Positionsnummer bei der Prüfung zur weiteren Verarbeitung ignoriert werden? Viele Grüße Ronald Damm 2018-10-17 14:59:50 Hallo Herr Damm, eine Ablehnung für den von Ihnen beschriebenen Fall per CONTRL oder APERAK ist nicht möglich. Somit muss die Fehlerklärung bilateral mit dem Marktpartner erfolgen. Freundliche Grüße, Ihr BDEW-Forum Datenformate Ja Thomas Seipt Klaus Keller Thomas Seipt Ronald Damm Dieses Segment zeigt den Beginn des Positionsteils innerhalb der Nachricht an. Der Positionsteil wird durch Wiederholung von Segmentgruppen gebildet, die immer mit einem LIN-Segment beginnen. Vom Programm vergebene Positionsnummer innerhalb der Nachricht (fortlaufende Nummer von 1 bis n) Nein -------------Klaus Keller-------------15.11.2018 08:51 Antwortvorschlag an Thomas geschickt Nein Nein
PRICAT MIG 1.1 Abgeschlossen Ist die Angabe der Vorgängerversion in der PRICAT Pflicht ? Vorgängerversionen sind immer, sofern vorhanden, anzugeben 14.08.2018 2018-00087 Sehr geehrte Damen und Herren, wir erhalten PRICATs von MSB ohne, dass auf eine Vorgängerversion referenziert wird, und wir können diese nicht verarbeiten, da wir sofern schon ein Preisblatt für den Zeitraum vorhanden ist, auf die Vorgängerversion prüfen, um eine zeitliche Abgrenzung vorzunehmen. Beispiel: Der MSB hatte zwei PRICATs mit zwei inhaltlich unterschiedlichen Preisblättern versandt, diese dann in eine PRICAT zusammengeführt und dann erneut versendet. Muss dann referenziert werden bzw. ist die Referenzierung auf eine Vorgängerversion nur erforderlich, wenn eine zeitliche Abgrenzung der PRICAT aufgrund neuer Preise notwendig wird? Welche Vorgehensweise ist korrekterweise anzuwenden, wenn PRICATS aufgrund einer Korrektur (Ersatz) für einen identischen Gültigkeitszeitraum mehrfach vom MSB versandt werden? Laut der Rahmenbedingungen in der WiM muss aus meiner Sicht immer auf die Vorgängerversion referenziert werden, da diese ab dem Initialen Versand immer vorhanden ist. Ohne Referenzierung kann die aktuelle Version nicht bestimmt werden. Vergleiche Punkt 4, Seite 156 WiM: Die Gültigkeit eines Preisblatts endet mit der Übermittlung eines Preisblattes mit identischem Gültigkeitsbeginn und einer höheren Versionskennzeichnung oder mit dem Inkrafttreten eines Preisblatts mit einem späteren Gültigkeitsbeginn. Vielen Dank für Prüfung und Antwort. Mit freundlichen Grüßen Arne Limburg 2018-08-14 10:59:44 Hallo Herr Limburg, zur Angabe der Vorgängerversion in SG1-RFF+ACW ist beim Prüfidentifikator "27002" = "Preisblatt Bedingung Messstellenbetrieb iMS, mME" die Bedingung [1] Wenn Vorgängerversion vorhanden zu erfüllen. Die Einhaltung der Bedingung bei der gesendeten Nachricht ist im von Ihnen skizzieren Beispiel verletzt worden, da ein Vorgängerpreisblatt vorhanden war. Somit muss der Versender der PRICAT den Fehler korrigieren und die Vorgängerversion mit angeben. Viele Grüße, Ihr Forum Datenformate Ja Thomas Seipt Klaus Keller Thomas Seipt Arne Limburg Segment RFF+ACW PRICAT AHB, Seite 4 PRICAT MIG, Seite 9 WiM, Seite 156 Rahmenbedingungen Die Preisblätter sind eindeutig zu versionieren. Auf den Preisblättern sind die aktuelle Versionskennzeichnung, der Gültigkeitsbeginn und die Kennzeichnung der Vorgängerversion des Preisblatts anzugeben. 4. Die Gültigkeit eines Preisblatts endet mit der Übermittlung eines Preisblattes mit identischem Gültigkeitsbeginn und einer höheren Versionskennzeichnung oder mit dem Inkrafttreten eines Preisblatts mit einem späteren Gültigkeitsbeginn. Nein -------------Klaus Keller-------------20.08.2018 13:58 Vorschlag erstellt und an Hr. Seipt geschickt Nein Nein
PRICAT MIG 1.1 Abgeschlossen Muss die PRICAT EDI Nachrichtennummer über alle Empfänger eindeutig sein? Eindeutigkeit ist einzig über die EDI Nachrichtennummer (DocID) im BGM Segment gegeben 12.07.2018 2018-00067 Problem Identische EDI Nachrichtennummer (DocID) in PRICAT Nachrichten von gleicher Sendercodenummer und unterschiedlicher Empfängercodenummer innerhalb eines IS-U Systems (1 Mandant, unterschiedliche Buchungskreise, unterschiedliche Marktpartner) Ausführung/Frage Die Eindeutigkeit eines Preisblatts für den Messstellenbetrieb wird in der PRICAT durch die EDI Nachrichtennummer (DocID) im BGM Segment gegeben. Ist es korrekt, dass ein Messstellenbetreiber (Sendercodenummer) eine identische EDI Nachrichtennummer für unterschiedliche Marktpartner (Empfängercodenummer) verwenden darf? Bsp. MSB1 sendet PRICAT mit DocID=0815 an Lieferant1 MSB1 sendet PRICAT mit DocID=0815 an Lieferant2 MSB1 sendet PRICAT mit DocID=0815 an Lieferant3 2018-07-12 11:03:39 Sehr geehrter Forumteilnehmer, Der MSB muss die Eindeutigkeit lediglich über die EDI Nachrichtennummer (entspricht dem Begriff DocID aus Ihrer Frage) im BGM Segment gegnüber dem einzelnen Empfänger garantieren. Dazu kann er natürlich die EDI Nachrichtennummer für verschiedene Empfänger mehrfach verwenden.   Eine Vorschrift, dass die EDI Nachrichtennummer der PRICAT über alle Empfänger eindeutig sein muss, ist nicht bekannt. Freundliche Grüße, Ihr Forum Datenformate Ja Thomas Seipt Klaus Keller Thomas Seipt Christian Latsch EDI@Energy PRICAT 1.1 PRICAT / UN D.09B S3 Stand: 25.09.2017 Seite: 5 / 26 Nein -------------Klaus Keller-------------16.07.2018 14:37 aus meiner Sicht eher clever ist, für ein Preisblatt für alle MP immer die gleiche Nummer zu verwenden oder was meinst Du, Thomas ? -------------Thomas Seipt-------------29.08.2018 15:32 Sehe ich auch so. Warum muss der Absender sich noch Gedanken zur Eindeutigkeit bei verschiedenen Empfängern machen? -------------Klaus Keller-------------30.08.2018 11:04 Tippfehler beseitigt und redaktionelle Korrekturen Nein Nein
UTILMD AHB GPKE / GeLi Gas 6.0f Abgeschlossen Ist die Angabe des Netzanschlusseigentümers in der Anmeldung E/G verpflichtend? Gemäß des AHBs muss kein Netzanschlusseigentümer angegeben werden 16.10.2018 2018-00138 Hi zusammen, heute ist der Netzbetreiber verpflichtet in einer EoG Z36 den Eigentümer/Anschlussnehmer mitzuteilen? darf der Lieferant explizit hierauf bestehen? insbesondere wenn der Nutzer nicht bekannt ist? oder muss der Lieferant mit einer EoG GP Unbekannt leben und ohne Infos zurechtkommen und von selbst die Leeranlagenrecherche beauftragen? besten Dank im Voraus für eine Antwort 2018-10-16 12:11:49 Sehr geehrter Marktteilnehmer, Sie sprechen mit Ihrem Anliegen den Anwendungsfall mit dem Prüfidentifikator 11013 an. Laut dem AHB ist das SG12 Netzanschlusseigentümer mit "Kann" definiert. Somit ist es dem Versender überlassen, ob dieser das Segment befüllt.  Die Formate bilden die Anforderungen aus den Prozessen ab. Aus diesen lässt sich keine Anforderung, wie von Ihnen angedacht, ableiten. Viele Grüße Ihr Forum Datenformate Ja Holger Weickenmeier Jessica Riekhoff Jessica Riekhoff Dennys Goeres Seite 72 Eigentümer ist als Kann/Muss Feld ausgewiesen - was ist nun richtig? Nein Die Frage finde ich lustig. Die kommt, laut Anfragenden, aus dem Haus welches dieses Kann damals da rein gebracht hat. :-) -------------Holger Weickenmeier-------------17.10.2018 15:04 -------------Jessica Riekhoff-------------17.10.2018 16:00 jaja... kommt immer wieder Nein Nein
UTILMD AHB GPKE / GeLi Gas 6.0f In Bearbeitung Muss die Adresse (NAD) in der Zuordnungsliste identisch gefüllt sein wie in der Antwort auf die Anmeldung? Laut Definition der Zuordnungsliste sind dies die Abgestimmten Stammdaten aus den Wechselprozessen 05.09.2018 2018-00110 Sehr geehrtes Forum-Team, Ein Lieferant bemängelt, dass wir als VNB in der Anmeldebestätigung den Ortsteil der Lieferanschrift versenden, jedoch nicht in der Zuordnungsliste. Die Regelungen zum Ortsteil sind in den allg. Festlegungen hinterlegt. Innerhalb des AHB wird lediglich das Datenelement 3042 (Straße) aufgeführt. Ist der Ortsteil immer mitzugeben wenn eine Adresse mit Straße kommuniziert wird und somit auch zu Füllen bei Zuordnungslisten? Die APERAK-Prüfung (Z29) greift bei derartigen Fällen nicht, da die Bedingungen mit Angaben von Straße, Hausnummer erfüllt werden. 2018-09-05 11:37:14 Sehr geehrter Marktpartner, laut der Definition sind in der Zuordnungsliste die abgestimmten Stammdaten zu füllen. Wenn Sie in der Zuordnungsliste abweichende Stammdaten verwenden, so wird dies beim LF eine Abweichung ergeben.  Das Weglassen des Ortsteils ist eine Änderung der Stammdaten. Wenn es keinen Ortsteil mehr gibt, dann ist dies mittels SDÄ mitzuteilen und die Stammdaten wieder gleich zu ziehen. Ihr Forum Datenformate   Ja Holger Weickenmeier Jessica Riekhoff Jessica Riekhoff Jörg Gruchenberg Nein Bitte vor veröffentlichen noch die Konversation mit dem Fragenden lesen. Der will einfach nicht.... -------------Holger Weickenmeier-------------07.09.2018 11:03 Nein Nein
UTILMD AHB GPKE / GeLi Gas 6.0f Abgeschlossen Welche Nachricht ist bei einer Kündigung eines LRV zu senden? Es gibt für diesen Fall keinen Prozess und somit auch keinen Anwendungsfall 25.05.2018 2018-00038 Welche UTILMD kann seitens des Netzbetreibers versendet werden, wenn dem Lieferanten der Lieferantenrahmenvertrag fristlos gekündigt wurde? Wir haben einem Lieferanten fristlos den Lieferantenrahmenvertrag gekündigt, aufgrund von ausstehender Forderungen. Wir sind Netzbetreiber und haben somit keine Möglichkeit, eine UTILMD für die Beendigung der Zuordnung zu senden. Der Lieferant widerspricht jetzt mit negativer REMADV unseren Endabrechnungen mit der Begründung, er möchte gerne eine Abmeldung vom Netz --> eine ZC8 Beendigung der Zuordnung. Systembedingt ist uns das jedoch nicht möglich, da es sich bei einer ZC8 ja nur um eine Informationsmeldung handelt. Diese Informationsmeldung kann ich nur erzeugen, wenn ich zwar eine neue Anmeldung aber keine Abmeldung vorliegen habe. Jetzt meine Frage: "Was kann ich als Netzbetreiber für eine Meldung/UTILMD an den gekündigten Lieferanten schicken, wenn ihm der Lieferantenrahmenvertrag fristlos gekündigt wurde?" Vielen Dank für Ihre Hilfe. Stefanie Schmied 2018-05-25 09:23:26 Sehr geehrte Frau Schmied, vielen Dank für Ihren Beitrag im Forum Dantenformate. Einen Anwendungsfall für Ihre Konstellation können wir Ihnen nicht nennen. Für den Fall einer Kündigung eines LRV und der damit einhergehenden Beendigung der Belieferung gibt es keinen Prozess. Aus diesem Grund ist von der PG EDI@Energy auch kein Anwendungsfall generiert worden. Weitere Fragen können wir im Forum Datenformate nicht beantworten, da diese prozessual behaftet sind. Hierzu wenden Sie sich bitte an die PG Umsetzungsfragen beim BDEW.  https://www.bdew.de/service/umsetzungsfragen-zu-marktprozessen-und-datenformaten/ Viele Grüße  Ihr Forum Datenformate   Ja Holger Weickenmeier Jessica Riekhoff Jessica Riekhoff Stefanie Schmied Nein Nein Nein
UTILMD AHB GPKE / GeLi Gas 6.0f Abgeschlossen Wie wird mit Großkunden-PLZ Adressen in den NAD Segmenten umgegangen? Jede Adresse mit einer Großkunden-PLZ hat auch eine "normale" Adresse 24.05.2018 2018-00036 Ein Kunde von uns hat seine Adresse für Rechnungen und Ablesekarten geändert. Straße und Postfach gibt es nicht mehr, sonder nur noch eine Großempfänger-PLZ. Sind Straße oder Postfach in diesem Fall dennoch Pflichtangaben in der NN-Anmeldung oder bei Stammdatenänderungen? 2018-05-24 08:23:29 Sehr geehrter Marktteilnehmer, Wie mit Adressen in den NAD Segmenten umzugehen ist, ist unter anderem in den Allgemeinen Festlegungen (Vers. 4.4 im Kapitel 1.17 "Darstellung von Adressen") beschrieben. In der Datenelementgruppe C059 “Straße“ wird die Straße, Hausnummer incl. Zusatzangaben sowie der Ortsteil angegeben. Bei Adressen (gilt nicht für NAD+MR und NAD+MS in der INVOIC), die über eine Großkundenpostadresse verfügen, muss die Anschrift mit Straße oder Postfach verwendet werden. Viele Grüße Ihr Forum Datenformate Ja Holger Weickenmeier Jessica Riekhoff Jessica Riekhoff Stefanie Pasewald Nein An Jessica zum validieren gegeben -------------Holger Weickenmeier-------------24.05.2018 09:40 Nein Nein
UTILMD AHB GPKE / GeLi Gas 6.0f Abgeschlossen Wir erhalten "Dummywerte" in einer Anfrage. Wie ist damit umzugehen? Dummywerte sollten in keinen Nachrichten vorhanden sein 24.04.2018 2018-00013 Sehr geehrte Damen und Herren, wir als Lieferant bekommen in diversen E35 Meldungen von anderen Lieferanten für den Meldepunkt ungültige Werte zugesendet. Laut Aussage der Marktpartner handelt es sich dabei um Dummydaten da ja die wahren Werte nicht bekannt sind. Beispiel mit Zeilenumbruch: ... LOC+172+10000000070' RFF+Z13:11016' CCI+++Z15' SEQ+Z01' CCI+Z01++Z30' SEQ+Z03' RFF+AVE:10000000070' ... Sind solche Dummywerte zulässig und dürfen in Marktnachrichten verwendet werden oder sind diese Segmente nicht zu befüllen wenn die Werte nicht bekannt sind. Aus unserer Sicht sollten solche Werte nicht verwendet werden. Es würde auch Sinn machen einen eigenen APERAK-Code einzuführen mit dem ungültige Marktlokationen abgelehnt werden können, da durch die Prüfziffer eine Validierung gegeben ist. Mit freundlichen Grüßen Jacob Gottwald 2018-04-24 10:39:09 Sehr geehrter Herr Gottwald, vielen Dank für Ihren Beitrag. In der Kündigung ist die ID der Marktlokation bzw. ID der Messlokation mit "Kann" ausgeführt. Da eine Falsche Information nicht zwingend zu einer Ablehnung führt, ist eine Einführung einer APERAK hier nicht sinnvoll. Wie zu identifizieren ist, ist in den Festlegungen definiert. Für GPKE und GeLiGas ist die ID der Marktlokation keine Vorraussetzung. Es muss weiter über andere Angaben identifiziert werden. Hier kann es durchaus zu einer Identifikation kommen. Ein befüllen einzelner Segmente mit "Dummywerten" erachten wir als kritisch. Dies sollte vom Versender bereinigt werden.  Viele GrüßeIhr Forum Datenformate Ja Holger Weickenmeier Jessica Riekhoff Jessica Riekhoff Jacob Gottwald - Nein Antwortvorschlag erstellt und an Jessica zum gegenlesen gegeben. -------------Holger Weickenmeier-------------24.4.2018 17:0 Nein Nein
UTILMD AHB GPKE / GeLi Gas 6.0f Abgeschlossen Wie sollen im Datenaustausch die MaLo/MeLo-Beziehungen (CCI+Z01 und SEQ+Z05/Z06) bei kaskadierten Modems und bei Rundsteuerempfängern übertragen werden? Eine Kommunikationseinrichtung oder eine Steuereinrichtung wird den Geräten zugeordnet, an welche diese angebunden sind 17.04.2018 2018-00005 Guten Tag, wie sollen im Datenaustausch die MaLo/MeLo-Beziehungen (CCI+Z01 und SEQ+Z05/Z06) bei kaskadierten Modems und bei Rundsteuerempfängern übertragen werden? Beispiel: MeLo1 = Zähler 0815 und Modem 0815 --> MaLo 1 MeLo2 = Zähler 0816 --> MaLo2 Das Modem ist auf beiden Zählern geschaltet. 1. Variante: MaLo 2 --> Zuordnung zur MeLo1 (wegen Modem/Rundsteuerempfänger) und MeLo2 2. Variante: MaLo 2 --> MeLo2 3. Variante: separate MeLo (MeLo3) für das Modem/Rundsteuerempfänger aufbauen und der MaLo1 und 2 zusätzlich zuordnen Uns ist unklar, wie hier Verfahren werden soll. Alle Varianten haben Vor- und Nachteile. Aus unserer Sicht kann ein technisches Gerät nur eine MeLo Zuordnung besitzen. Aktuell kann im SEQ+Z05/Z06 nicht auf eine weitere MeLo referenziert werden. Bitte veröffentlichen Sie eine einheitliche Vorgehensweise. Freundliche Grüße André Koepsel enercity netz 2018-04-17 09:10:46 Sehr geehrter Herr Koepsel, vielen Dank für Ihren Beitrag. Die Kommunikationseinrichtung und die Steuereinrichtung werden keinen Messlokationen zugeordnet. Die Zuordnung erfolgt auf das bzw. die Geräte. Diese Zuordnung erfolgt mit dem Segment SG8 RFF+MG in den SEQ+Z05/Z06 (Kommunikationseinrichtungsdaten / Daten der technischen Steuereinrichtung)  Dieses RFF kann bis zu 9 mal angegeben werden, so dass Sie hier bis zu 9 Gerätenummern angeben können.(Anmerkung: Sollte z.B. eine Kommunikationseinrichtung mehr als 9 Geräten (Zählern) zugeordnet sein, so ist das gesammte SEQ zu wiederholen) In keinem Fall ist für eine Kommunikationseinrichtung oder Steuereinrichtung eine einene Messlokation anzulegen. Viele Grüße Ihr Forum Datenformate   Ja Holger Weickenmeier Jessica Riekhoff Jessica Riekhoff Andre Koepsel Siehe angefügte Datei Nein An Jessica zum gegenlesen weitergeleitet -------------Holger Weickenmeier-------------17.4.2018 10:58 Nein Nein
INVOIC / REMADV AHB 2.3c Abgeschlossen Darf der Name des Rechnungsempfängers (SG2\NAD\C080\3036) in einer Storno-INVOIC mit dem Namen des Rechnungsempfängers aus der Ursprungsrechnung verglichen werden? Angabe von Rechnungsempfänger in Stornorechnungen 05.10.2018 2018-00131 Sehr geehrte Damen und Herren, für den folgenden Sachverhalt benötigen wir eine Klärung. Ein Netzbetreiber verschickt eine INVOIC 31001 „Abrechnung Netznutzung“ an den Lieferanten. Inhalte wie Preise, Rechnungsnummer etc. sind OK und werden nicht beanstandet. Diese versendete INVOIC 31001 „Abrechnung Netznutzung“ wird vom Netzbetreiber durch eine INVOIC 31004 „Stornorechnung“ storniert. Die Stornorechnung wird über die Referenz der Ursprungsrechnungsnummer der Rechnung zugeordnet. In der Stornorechnung ist dieselbe Person als Rechnungsempfänger enthalten, diese wird in den Datenelementen des Rechnungsempfängers (SG2\NAD\C080\3036) abweichend zu der Originalrechnung übermittelt. Die INVOIC 31004 „Stornorechnung“ wird durch eine REMADV mit dem Abweichungsgrund „28 - Sonstiges“ und einem Beschreibungstext abgelehnt. Der Lieferant merkt an, dass der Name des Rechnungsempfängers in der Stornonachricht nicht identisch mit dem Namen des Rechnungsempfängers aus der initialen Abrechnung Netznutzung ist. Darf der Name in der Stornonachricht mit dem Namen aus der initial versendeten Abrechnung Netznutzung vom Lieferanten verglichen werden? Falls die übermittelten Namensdaten nicht identisch sind, darf die Stornorechnung per REMADV mit dem Abweichungsgrund 28 „Sonstiges“ abgelehnt werden? Vielen Dank! 2018-10-05 11:44:35 Sehr geehrter Forumsteilnehmer, vielen Dank für Ihre Frage. Unabdingbare Voraussetzung für einen reibungslosen automatisierten Datenaustausch ist eine vorherige Abstimmung von Stammdaten. In der INVOIC ist der Name des zum Erstellungsdatum gültigen Leistungsempfänger zu verwenden. Eine Prüfung des Namens gegen den Namen der Ursprungsrechnung ist nicht erlaubt, da beispielsweise zwischenzeitlich eine Umfirmierung stattgefunden haben könnte. Freundliche Grüße, Ihr BDEW Forum Datenformate Ja Klaus Keller Stefan Seidel Klaus Keller Gregor Scholtyschik Nein -------------Klaus Keller-------------17.10.2018 13:53 Frage gemäß AG R/Z beantwortet und veröffentlicht Nein Nein
INVOIC / REMADV AHB 2.3c Abgeschlossen Prüfung des Namens vom Rechnungsempfänger in einer INVOIC für die Abrechnung der Netznutzung zulässig? Die Angabe des Rechnungsempfängers erfolgt gemäß Lieferantenrahmenvertrag 05.10.2018 2018-00130 Sehr geehrte Damen und Herren, für den folgenden Sachverhalt benötigen wir eine Klärung. Ein Netzbetreiber verschickt eine INVOIC 31001 „Abrechnung Netznutzung“ an den Lieferanten. Inhalte wie Preise, Rechnungsnummer etc. sind Ok und werden nicht beanstandet. Die INVOIC wird durch eine REMADV mit dem Abweichungsgrund „28 - Sonstiges“ und einem Beschreibungstext abgelehnt. Der Lieferant merkt an, dass der Name des Rechnungsempfängers in dem Segment NAD+MR in der Datenelementgruppe C080 nicht korrekt gefüllt wird. Es fehlen aus seiner Sicht die korrekten Angaben in Gruppendatenelementen. Leider werden die benötigten Inhalte der vier Gruppendatenelemente (Namensangabe des Lieferanten) in keiner vorherigen EDIFACT-Nachricht ausgetauscht, so dass der Netzbetreiber die korrekte Befüllung erraten muss. Der Name des Rechnungsempfängers (Namensangabe des Lieferanten) wird ausschließlich im Lieferantenrahmenvertrag und im Kontaktdatenblatt ausgetauscht, wie der Name im IT-System zu hinterlegen ist, ist nirgends beschrieben. Ist das Vorgehen des Lieferanten korrekt? 2018-10-05 11:31:01 Sehr geehrter Forumsteilnehmer, vielen Dank für Ihre Frage. Unabdingbare Voraussetzung für einen reibungslosen automatisierten Datenaustausch ist eine vorherige Abstimmung von Stammdaten. Wenn der Name des Rechnungsempfängers den Angaben des Lieferantenrahmenvertrags entsprechen, ist eine Ablehnung per Nicht-Zahlungsavis im oben genannten Sachverhalts unzulässig. Der Lieferant sollte also sicherstellen, dass in der initialen Stammdatenabstimmung die Dokumente korrekt gefüllt sind, evtl. Änderungen hat er durch direkte Kommunikation mit dem Netzbetreiber sicherzustellen, eine EDIFACT-Nachricht für diesen Fall ist nicht vorgesehen. Freundliche Grüße, Ihr BDEW Forum Datenformate Ja Klaus Keller Stefan Seidel Klaus Keller Gregor Scholtyschik Nein -------------Gregor Scholtyschik-------------05.10.2018 11:34 Frage wurde in der PG bereits besprochen und die Antwort genehmigt. -------------Klaus Keller-------------17.10.2018 13:48 Antwort nach Vorgabe der AG R/Z eingefügt und veröffentlicht Nein Nein
INVOIC / REMADV AHB 2.3c Abgeschlossen Wie ist die u.a. Aussage aus dem AHB zu interpretieren? prozessuale Vorgabe zur INVOIC-Beantwortung sind zehn Werktage 02.10.2018 2018-00127 Auf der Seite 27 im AHB 3. Ausprägungen von REMADV-Nachrichten ist der Umgang mit Guthaben beschrieben. Der erste Satz "Für die Verwendung der REMADV-Nachrichten wird die nachfolgend beschriebene Vorgehensweise empfohlen" stellt für einige Lieferanten lediglich eine Empfehlung im Umgang mit der Beantwortung von Rechnungen zu Gunsten des Lieferanten dar. Punkt 6 "In Fällen, in denen sich im Rahmen der Verrechnung eine Rückerstattung ergibt, ist eine REMADV (mit negativem Zahlbetrag) vom Lieferanten an den Netzbetreiber zu senden. Der Netzbetreiber zahlt genau diesen Betrag an den Lieferanten aus. Der Überweisungsbetrag muss identisch sein mit der Summe aller in einer Zahlungs-REMADV enthaltenen Zahlbeträge" Wir haben daher mit einigen Lieferanten noch immer erhebliche Diskussionen, da diese Guthaben nicht innerhalb von 10 Werktagen anfordern oder erst warten, bis das Guthaben durch nachfolgende Rechnungen "aufgebraucht" ist und erst dann eine REMADV für Guthaben und die Rechnungen übersenden. Dieser Umstand bringt unnötigen Mehraufwand aufgrund von Mahnungen, Telefoninkasso etc. mit sich. Es wäre schön, wenn hier die Vorgehensweise klar und eindeutig beschrieben werden könnte. 2018-10-02 15:48:50 Sehr geehrte Fragestellerin, Entsprechend der prozessualen Vorgaben ist jede INVOIC spätestens nach 10 Werktagen zu beantworten. Die von Ihnen zitierte Empfehlung ist dieser Regelung nachrangig. Viele Grüße, Ihr BDEW-Forum Datenformate Ja Klaus Keller Stefan Seidel Klaus Keller Tanja Heinemann Nein -------------Klaus Keller-------------05.10.2018 10:39 Problem ist nicht neu, aber in den edi@energy-Dokumenten können wir hier nicht weiterhelfen, Rücksprache in AG R/Z zum weiteren Vorgehen -------------Klaus Keller-------------27.11.2018 15:20 Besprechungsergebnis der AG R/Z veröffentlicht Nein Nein
INVOIC / REMADV AHB 2.3c Abgeschlossen Gilt das POG-Bündel auch bei mME? Für jede Marktlokation mit mME-Messung ist ein Angebot zu stellen 27.08.2018 2018-00098 Sehr geehrte Damen und Herren, während der Konfigurierung der Stammdaten für die Messstellenbetriebsabrechnung haben wir es als sinnvoll erachtet mME eines Anschlussnutzers in einem Vertragsverhältnis zu führen. Dies hat den Vorteil, dass bereits ein Bündel gebildet ist, wenn die Umrüstung auf iMS erfolgt. Dementsprechend wird eine QUOTES mit mehreren Positionen von mME versandt. Zu jeder einzelnen Position wird hierbei die MaLo aufgeführt. Damit ist dem Lieferanten die Prüfung anlagenscharf möglich. Beispielsweise enthält die QUOTES Angaben zu drei mME des Anschlussnutzers. Der Lieferant bestätigt die Angebotsannahme. Aktuell würden die Vorgaben die Zusammenfassung der drei mME in ein LIN-Segment fordern. Damit würde das LIN-Segment wie folgt aufgebaut: EAN ...798 // 50,43 €/a / / 3 // 19 % MwSt // 9,58 € // 60,01 €. Damit wäre die zulässige Preisobergrenze für mME (3 x 20 Euro) überschritten. Als Lösung wird von SAP die Berechnungslogik angepasst, damit jede Position einzeln abgerechnet wird. Dies hätte zur Folge, dass in der INVOIC drei separate LIN-Segmente mit identischem Zeitraum aufgeführt werden. Aus unserer Sicht wäre dies zur Rechnungseingangsprüfung auch wesentlich einfacher als die Zusammenfassung zu einem LIN-Segment. Die INVOIC referenziert auf die QUOTES. In dieser ist jede Position separat aufgelistet. Der Gesamtbruttobetrag müsste auch nicht mehr durch die Anzahl der Geräte geteilt werden um die Betragsprüfung gegen die PRICAT vornehmen zu können. Wie steht der BDEW zu diesem Vorschlag? Wäre im Fall einer MSB-Rechnung die mehrfache Aufführung der LIN-Segmente mit der selben EAN und identischem Zeitraum zulässig? Vielen Dank im Voraus für Ihre Antwort. Mit freundlichen Grüßen Jörg Kattner 2018-08-27 09:47:50 Sehr geehrter Marktteilnehmer, dass von Ihnen beschriebene Vorgehen ist derzeit in den Prozessen nicht abgebildet. Daher gibt es in den Formaten nur die Möglichkeit für jede Marktlokation, in deren Messloaktionen mME eingebaut sind, eine separate QUOTES zu senden. Mit freundlichem Gruß Ihr BDEW Forum Datenformate Ja Klaus Keller Stefan Seidel Klaus Keller Jörg Kattner Nein -------------Klaus Keller-------------20.09.2018 16:09 Vorgehen mit drei LIN-Segmenten mit identischer LIN ist derzeit die einzige Möglichkeit - zu diskutieren in AG R/Z -------------Beate Becker-------------26.09.2018 13:48 AG: beantwortet und veröffentlicht Nein Nein
INVOIC / REMADV AHB 2.3c Abgeschlossen Wie sind aufeinanderfolgende Gasmonate darzustellen ? Keine Überschneidung von Zeiträumen 27.07.2018 2018-00077 Sehr geehrte Damen und Herren, ich habe eine Frage zu dem Abrechnungszeitraum in einer INVOIC. Wie rechnen unsere Mehr- und Mindermengen per INVOIC je Gasmonat ab, also immer vom 01. eines Abrechnungsmonats, 6 Uhr bis zum 01. des Folgemonats 6 Uhr. Nun stehen wir in einer Diskussion mit einem TK, welcher behauptet, dass es so zu einer Überschneidung von Zeiträumen kommt und die nächste Rechnung erst am dem 02. des Abrechnungsmonats beginnen müsste. Diese Überschneidung sehen wir nicht. Ich habe dazu noch keine eindeutige Rechtsgrundlage finden können. Können Sie mir bei dem Thema weiterhelfen? Ist der Abrechnungszeitraum gemäß des Gasmonats, so wie auch in den MSCONS, korrekt? Vielen Dank im Voraus. Mit freundlichen Grüßen 2018-07-27 08:01:52 Sehr geehrte Fragestellerin, selbstverständlich sind überschneidende Zeiträume zu vermeiden, da Leistungen nicht doppelt abgrechnet werden dürfen. Bezgl. Ihres Beispieles wären zwei Varianten zur Befüllung der betroffenen DTM-Segmente möglich: 1. Variante: Rechnung 1: DTM+155 = 01.01.2018 DTM+156 = 31.01.2018 Rechnung 2: DTM+155 = 01.02.2018 DTM+156 = 28.02.2018 2. Variante: Rechnung 1: DTM+155 = 01.01.2018 DTM+156 = 01.02.2018 Rechnung 2: DTM+155 = 02.02.2018 DTM+156 = 01.03.2018 Unzulässig wäre die von Ihnen erwähnte Variante: Rechnung 1: DTM+155 = 01.01.2018 DTM+156 = 01.02.2018 Rechnung 2: DTM+155 = 01.02.2018 DTM+156 = 01.03.2018 Freundliche Grüße, Ihr BDEW Forum Datenformate Ja Klaus Keller Stefan Seidel Stefan Seidel Nicole Stockkamp Nein -------------Klaus Keller-------------13.08.2018 08:39 Antwortvorschlag erstellt -------------Beate Becker-------------26.09.2018 13:43 AG: ok Nein Nein
INVOIC / REMADV AHB 2.3c Abgeschlossen Ist die Aufteilung von Arbeit, Leistung und Umlagen auf unterschiedliche Rechnungen möglich? Alle im Abrechnungszeitraum erbrachten Leistungen sind in einer Rechnung abzurechnen. 10.07.2018 2018-00063 Sehr geehrte Damen und Herren, ist es zulässig, die Netznutzungsrechnung für eine Marktlokation und für einen Abrechnungszeitraum auf mehrere Belege aufzuteilen, so dass z.B. je eine INVOIC über die Abrechnung der Wirkarbeit, der Umlagen und der Leistung versendet wird? Oder erfolgt in diesem Fall eine Ablehnung der zweiten bzw. dritten INVOIC mit Code 53 (doppelte Rechnung)? Mit freundlichen Grüßen Stefan Reumann 2018-07-10 17:41:03 Sehr geehrter Herr Reumann, wir halten die von Ihnen beschriebene Verfahrensweise für ungeeignet. Um eine Rechnung prüfen zu können, müssen alle Leistungen (inkl. aller Abgaben und Umlagen etc.), die in dem betroffenen Zeitraum erbracht wurden, auch in einer Rechnung abgerechnet werden. Freundliche Grüße,Ihr BDEW Forum Datenformate Ja Klaus Keller Stefan Seidel Stefan Seidel Stefan Reumann Nein -------------Stefan Seidel-------------10.07.2018 19:28 Vorschlag erstellt -------------Klaus Keller-------------16.07.2018 12:39 Antwort aus meiner Sicht ok, Fragesteller in der Anrede ergänzt, da er auch in der Frage unterschrieben hatte -------------Stefan Seidel-------------17.07.2018 13:47 veröffentlicht Nein Nein
INVOIC / REMADV AHB 2.3c Abgeschlossen Wie erfolgt die Angabe des Gemeinderabatts im Summenteil ? Gemeinderabatt im Summenteil entspricht der Summe der Angaben auf Positionsebene 10.07.2018 2018-00061 Durch die explizite Ausweisung des Gemeinderabatts auf Positionsebene im SG42 MOA+Z01 kann es zu folgender Situation kommen; Aufgrund von Rundungsdifferenzen kann die Addition aller SG42 MOA+Z01 ein anderes Ergebnis auswerfen als die Berechnung des Gemeinderabatt innerhalb des SG50 auf Grundlage des SG50 MOA+77. Die Summe der SG42 MOA+Z01 wären damit ungleich dem SG50 MOA+Z01. Aus unserer Sicht ergibt sich das SG50 MOA+Z01 aus der Addition der SG42 MOA+Z01. Stimmen Sie damit überein? Oder wäre es auch zulässig das SG50 MOA+Z01 Auf Grundlage des SG50 MOA+77 zu berechnen? 2018-07-10 14:45:42 Sehr geehrter Marktpartner, in SG50 MOA+Z01 ist die Summe aller SG42 MOA+Z01 zu übermitteln, um Rundungsdifferenzen bei Berechnung des Gemeinderabatts auf Summenebene zu vermeiden. Freundliche Grüße, Ihr Forum Datenformate Ja Klaus Keller Stefan Seidel Stefan Seidel Steven Seidig Nein -------------Klaus Keller-------------16.07.2018 09:54 Antwortvorschlag an Herrn Seidel geschickt -------------Stefan Seidel-------------17.07.2018 13:33 veröffentlicht Nein Nein
INVOIC / REMADV AHB 2.3c In Bearbeitung Dürfen die MP-ID von Sender und Empfänger im UNB-Segment von den Angaben in den entsprechenden NAD-Segmenten im Nachrichtenkopf abweichen? MP-ID-Verwendung in UNB- und NAD-Segmenten muss zueinander passen 12.06.2018 2018-00050 Sehr geehrte Damen und Herren, ein Netzbetreiber hat uns eine INVOIC mit mehreren Rechnungen gesendet, in welcher der Marktpartnercode des Senders im UNB-Segment, von dem im NAD+MS innerhalb der Rechnung abweicht. (Die NAD+MS-Codes der meisten Rechnungen stimmen mit den im UNB-Segment angegebenen überein.) Bsp.: UNB+UNOC:3+9900000000001:502+MP_CODE_Empfänger:502+180612:0807+MUSTER_UNB_REFERENZ' UNH... NAD+MS+9900000000002::.... UNT+... Aus unserer Sicht ist dies so nicht möglich und die betroffene Rechnung fehlerhaft. Wie ist hier weiter vorzugehen, da auch kein APERAK-Ablehnungsgrund dazu existiert. Mit freundlichen Grüßen Jacob Gottwald 2018-06-12 14:56:58 Hallo Herr Gottwald, die einzuhaltenden Vorgaben hierzu finden sich in Kapitel 1.13 Marktpartneridentifikation in den Allgemeinen Festlegungen: In allen EDIFACT-Übertragungsdateien wird auf Ebene der Übertragungsdatei das UNB-Segment u. a. dazu genutzt, die Absender/Empfänger zu identifizieren. Hierzu stehen die Datenelemente 0004 (Absender) und 0010 (Empfänger) zur Verfügung. Zusätzlich werden auf Nachrichtenebene (UNH-Ebene) die fachlichen Absender/Empfängerim NAD-Segment mit den Qualifier „MS“ (Absender) und „MR“ (Empfänger) im Datenelement 3035 identifiziert (gilt nicht für die DVGW-Nachrichten, da abweichende Qualifier genutzt werden). Die im UNB- und NAD-Segment für den Absender/Empfänger verwendeten MP-ID sind identisch. Sofern eine Marktpartner gegen diese grundlegenden Vorgaben verstößt, müssen sie ihm dies bilateral mitteilen, da es hierfür keinen Ablehngrund in einer Servicenachricht gibt. Freundliche Grüße, Ihr Forum Datenformate Ja Klaus Keller Stefan Seidel Stefan Seidel Jacob Gottwald Nein -------------Klaus Keller-------------20.06.2018 13:57 nach Vorgabe aus AG R/Z Antwort erstellt Nein Nein
INVOIC / REMADV AHB 2.3c Abgeschlossen Gibt es eine Artikelnummer für Sicherheitsleistungen ? Vorauszahlungen im Sinne von Sicherheitsleistungen 11.06.2018 2018-00049 Wir haben von einem Lieferanten eine monatliche Vorauszahlung verlangt. Diese wurde nun auch bezahlt. Wie wird die Vorauszahlung per INVOIC verrechnet? Welche Artikelnummer wird verwendet? 2018-06-11 14:29:00 Sehr geehrte Fragestellerin, wir gehen davon aus, dass es sich bei den vorausbezahlten Beträgen um Sicherheitsleistungen handelt.Es bestehen keine Prozessbeschreibungen, wie die Forderungen aus den Rechnungen im Detail zum Abbau der Sicherheitsleistungen führen. Somit gibt es auch keine verbindlichen Vorgaben wie sich dies in die Nachrichten niederschlägt und somit auch sind dazu auch keine Anwendungsfälle in den Datenformaten beschrieben. Ebenso gibt es hierfür keine eigene Artikelnummer. Für diesen Prozess ist somit die bilaterale Abstimmung mit dem Marktpartner erforderlich.   Freundliche Grüße, Ihr Forum Datenformate Ja Klaus Keller Stefan Seidel Stefan Seidel Nicole Hutschenreuter Nein -------------Klaus Keller-------------20.06.2018 09:15 Antwort erstellt nach Sitzung der AG R/Z -------------Stefan Seidel-------------20.06.2018 20:52 leicht Angepasste Antwort -------------Klaus Keller-------------21.06.2018 10:45 Kurzfrage ergänzt und veröffentlicht Nein Nein
INVOIC / REMADV AHB 2.3c Abgeschlossen Wie wird die Großkundenpostleitzahl in den NAD-Segmenten der INVOIC geprüft? Steuerliche Vorgaben zur Adressangabe bei Rechnungen 11.06.2018 2018-00048 Sehr geehrte Damen und Herren, ein NB sendete uns eine INVOICE mit Prüfidentifikator 31004 (Stornorechnung) zu, welche im NAD+MS nur PLZ und Ort enthielt. Die Straßebezeichnung und Hausnummer fehlten gänzlich. Entsprechend dem INVOIC AHB 2.3c müssen diese beiden Daten erfolgen "sofern keine Großkundenpostleitzahl verwendet wird". Da die Adresse bei Rechnungen ein wichtiger Faktor ist, stellt sich uns die Frage wie die Großkundenpostleitzahl geprüft wird. Müssen wir als Empfänger prinzipiell davon ausgehen, dass es sich um eine Großkundenpostleitzahl handelt, wenn der Versender keine Straßenbezeichnung und Hausnummer angibt? 2018-06-11 14:09:53 Sehr geehrter Fragesteller, die steuerlichen Vorgaben an eine Rechnungen fordern sowohl für den Leistenden als auch den Leistungsempfänger die Angabe von Bezeichnungen, anhand derer sich Name und Anschrift eindeutig feststellen lassen. Insoweit ist es ausreichend, wenn statt der Anschrift ein Postfach oder eine Großkundenadresse angegeben wird. Selbstverständlich empfiehlt sich zur Vermeidung von Zuordnungsproblemen hier eine einheitliche Vorgehensweise für alle Rechnungsdokumente. Freundliche Grüße, Ihr Forum Datenformate Ja Klaus Keller Stefan Seidel Klaus Keller Sebastian Böhme Nein -------------Klaus Keller-------------20.06.2018 09:31 Frage nach Webko der AG R/Z formuliert -------------Klaus Keller-------------16.07.2018 13:48 Frage nach Mail von Herrn Seidel vom 10.07.18 veröffentlicht Nein Nein
INVOIC / REMADV AHB 2.3c In Bearbeitung Wie ist in der Umstellungsphase auf Reverse Charge Verfahren zu verfahren, wenn ein Teil des Abrechnungszeitraums vor dem Umstellungszeitpunkt liegt? Ende des Leistungszeitraums entscheidet über Reverse Charge Verfahren 25.05.2018 2018-00040 Hallo Forum, Thema: Umstellung auf Reverse Charge Verfahren in der Sparte Strom geplant ab 01.01.2018 Wenn ich als Netzbetreiber eine MMMA für den Zeitraum 01.01.2017-31.01.2018 stelle, ist das "von"-Datum oder das "bis"-Datum die führende Größe für die Entscheidung ob Regelsteuersatz oder RCV. (Voraussetzung: gültige Wiederverkäuferbescheinigungen und übereinstimmende Erklärung zur Umstellung ab 01.01.2018 liegen vor.) Frdl. Grüße Claudia März 2018-05-25 15:04:03 Hallo Frau März, für die steuerliche Ausprägung der Rechnung ist das Ende des Leistungszeitraum entscheidend. In dem beschriebenen Fall wird die Rechnung im Reverse Charge Verfahren abgerechnet. Freundliche Grüße, Ihr Forum Datenformate Ja Klaus Keller Stefan Seidel Stefan Seidel Claudia Maerz Nein -------------Klaus Keller-------------25.05.2018 16:22 Rückfrage Hr. Seidel: War es nicht so, dass es ausreicht, wenn eine Position den "Reverse-Charge-Stempel" bekommt. Somit müsste die Antwort lauten "wenn eine Rechnungsposition den ein TAX mit DE 5305 = AE enthält, dann ist das FTX-Segment zur Angabe von Reverse Charge zu verwenden. Richtig ? -------------Klaus Keller-------------20.06.2018 14:05 Antwort nach AG R/Z Vorgabe eingefügt Nein Nein
INVOIC / REMADV AHB 2.3c In Bearbeitung Wie ist das Segment MOA+131 in SG27 im Rahmen von Gemeinderabatten zu befüllen? Verwendung von SG27 beim Gemeinderabatt 18.05.2018 2018-00032 Sehr geehrte Damen und Herren, in der Rolle des Netzbetreibers stellen wir INVOIC mit gewährten Kommunalrabatt an den eigenen Vertrieb mit 0% MwST. Der Vertrieb lehnt uns nun die Rechnungen ab mit der Begründung das Segement SG27+MOA+131 für den Gesamtzu- oder abschlagsbetrag sei nicht korrekt befüllt. Unser Systemdienstleister gibt uns dazu folgende Rückmeldung: "Die übermittelte INVOIC ist soweit korrekt befüllt. Das Segement SG27+MOA+131 für den Gesamtzu- oder abschlagsbetrag hätte auch leer sein können. Da die Summe der Gemeinderabatte nicht in die Summe der Rabatte einfließt. Dieses ist auch an der Bemerkung [26] ersichtlich. Wenn SG39 ALC+A:Z04 vorhanden. In der Rechnung sind keine Rabatte vom Typ Z04 vorhanden (Z04 = Anpassung nach §19, Absatz 2 Stromnetzentgeltver ordnung)" Der Systemdiensleister der Vertriebs entgegnet dem: "Wenn der Gesamtzu- oder abschlagsbetrag nur gefüllt wird, d.h. das Segment in der INVOIC nur enthalten ist, wenn die entsprechende AHB-Bedingung erfüllt ist, wäre das Problem schon vollständig gelöst. Wir erwarten hier (im SG27+MOA+131 ) auch nicht den Betrag des Gemeinderabatts (anstatt der 0,00), was ja nachrichtentechnisch auch falsch wäre. Gerade bei elektronischen Rechnungen sind wir der Meinung, dass diese „sauber“ sein sollten. In diesem Fall war es ja eine neutrale 0,00, aber in diesem Segment hätte ja auch ein Wert 12,34 (bei nicht erfüllten AHB-Bedingungen) stehen können." Könnten Sie uns hierbei weiterhelfen wer hier Recht hat bzw. wie das betroffene Segment schlussendlich zu befüllen ist? Vielen Dank vorab Mit freundlichen Grüßen 2018-05-18 12:59:37 Hallo Herr Oberhofer, die Bedingung "Muss [26] O [27]" = "[26] Wenn SG39 ALC+A+:Z04 vorhanden [27] Wenn SG39 ALC+C vorhanden"betrifft die komplette Segmentgruppe 27 Gesamtzu- oder abschlagsbetrag des Anwendungsfalls 31002 (NN-Rechnung). Die Hinweise Ihres Vertriebs-Systemdienstleisters hinsichtlich "neutraler 0,00" sind für uns nicht nachvollziehbar. Somit teilen wir die Einschätzung Ihres Netz-Systemdienstleisters, die SG27 nur im Bedarfsfalle bei entsprechenden Rabatten zu füllen. Viele Grüße, Ihr Forum Datenformate Ja Klaus Keller Stefan Seidel Stefan Seidel Andreas Oberhofer Nein -------------Klaus Keller-------------22.05.2018 13:45 Antwort zur Prüfung an Herrn Seidel geschickt -------------Stefan Seidel-------------22.05.2018 14:03 Veröffentlicht Nein Nein
INVOIC / REMADV AHB 2.3c Eingegangen Ablehnung unbekannter Markt-, bzw. Messlkationen REMADV Ablehnung unbekannter Markt- und Messlokationen 25.04.2018 2018-00016 Sehr geehrte Damen und Herren, wie soll bei einer eingehenden INVOIC auf einen unbekannten Meldepunkt reagiert werden, da eine APERAK-Ablehnung einer unbekannten Meldepunkt-ID (Fehlercode Z10) für INVOIC explizit ausgeschlossen (S. 31 im CONTRL-APERAK-AHB 2.3d) ist? Vielen Dank für Ihre Mühe. Mit freundlichen Grüßen Sebastian Weiße 2018-04-25 08:01:53 Hallo Herr Weiße, in diesem Fall hat die Ablehnung per REMADV mittels Ablehngrund 14 = Unbekannte Marktlokation, Messlokation im AJT-Segment zu erfolgen. Viele Grüße, Ihr Forum Datenformate Ja Klaus Keller Stefan Seidel Stefan Seidel Sebastian Weiße S. 31 im CONTRL-APERAK-AHB 2.3d Nein -------------Klaus Keller-------------25.4.2018 16:18 Antwort ergänzt und an Herrn Seidel geschickt -------------Klaus Keller-------------22.05.2018 14:00 Aktuellen Bearbeiter auf Herrn Seidel umgestellt -------------Stefan Seidel-------------22.05.2018 15:25 Passt. Somit: Veröffentlicht Nein Nein
MSCONS AHB 2.2i Abgeschlossen Siehe MSCONS AHB 02.10.2018 2018-00128 Im Kapitel 4.5.3 "Übersicht Korrekturvarianten von Werten je ursprünglichem Anwendungsfall" wird das Thema Stornierung angesprochen. Können Sie mir sagen wie eine Stornierung zu den Meldungen Arbeit Leistungsmax. Kalenderjahr vor Lieferbeginn (Prüfidentifikator 13015) Energiemenge u. Leistungsmax. von z. B. Straßenbel. (Prüfidentifikator 13016) aussehen sollen. Mit welcher Kategorie (BGM+1001) soll die Storno erzeugt werden? In der ursprünglichen Meldung werden die Werte: Z27 Bewegungsdaten im Kalenderjahr vor Lieferbeginn bzw. Z28 Energiemenge und Leistungsmaximum verwendet. In einer Storno würde ich erwarten, die gleich Kategorie zu verwenden. Für Storno ist aber nur die Kategorie 7 definiert. Bei anderen Datenformaten, wie zum Beispiel UTILMD wird immer die Kategorie der ursprünglichen Nachricht verwendet. Dieses ist hier nicht möglich. Auch dürfte die Datei nicht die Storno-Nachricht und die neue Nachricht enthalten, da eine Vermischung von Nachrichten mit unterschiedlichen Kategorien für MSCONS laut AHB nicht erlaubt ist. Können Sie beschreiben wie eine Stornonachricht aufgebaut sein soll? 2018-10-02 16:32:15 Sehr geehrter Herr Meyer, ihre Fragen sind im Dokument MSCONS AHB 2.2i Konsolidierte Lesefassung mit Fehlerkorrekturen Stand 16.11.2018 in den Kapiteln 4.5 Stornierung / Korrektur von Werten und 4.6 Anwendungsübersicht Messwert Storno beschrieben. Mit freundlichen Grüßen Ihr BDEW Forum Datenformate   Ja Reinhard Döring Thomas Seipt Reinhard Döring Christian Meyer MSCONS AHB: Kapitel 4.5.3 "Übersicht Korrekturvarianten von Werten je ursprünglichem Anwendungsfall" Tabelle: Arbeit Leistungsmax. Kalenderjahr vor Lieferbeginn (Prüfidentifikator 13015) | NB an LF | Stornierung und Neuversand | Nein | -- ... Energiemenge u. Leistungsmax. von z. B. Straßenbel. (Prüfidentifikator 13016) | NB an LF | Stornierung und Neuversand | Nein | -- allgemeine Festlegung: Mehrere Nachrichten in Übertragungsdatei zulässig? Ja  Nur sortenrein, z. B. keine Lastgänge = TL und Zählerstände = VL in einer Übertragungsdatei bündeln, wegen Anwendungsreferenz im UNB Segment. Darüber hinaus ist eine sortenreine Trennung des Nachrichtentyps lt. BGM DE1001 je Übertragungsdatei zu gewährleisten. Nein Nein Nein
Codeliste der Statuszusatzinformation 1.0b Abgeschlossen Kennzeichnung im Rahmen der Vorgaben 11.09.2018 2018-00116 Bedarf es einer besonderen Kennzeichnung , wenn nachträglich korrigierte Lastgangdaten versendet werden. 2018-09-11 10:49:06 Sehr geehrte Frau Degen, eine Kennzeichnung ist nach den Vorgaben des von Ihnen referenzierten Dokuments möglich und notwendig. Allerdings kann aufgrund der allgemeinen Fragestellung keine detaillierte Antwort gegeben werden. Ihr BDEW Forum Datenformate Ja Reinhard Döring Thomas Seipt Reinhard Döring Nadine Degen Nein Nein Nein
Codeliste der Statuszusatzinformation 1.0b Abgeschlossen Stornierung von Lastgängen 31.08.2018 2018-00105 Sehr geehrte Damen und Herren, wir haben eine Reklamation vorliegen, bei dem es zu Problemen bei der Lastgangaufnahme kommt. Laut IT-Dienstleister gab es zur Malo/Melo-Umstellung zum 01.02.2018 auch eine neue Regelung wie Lastgangdaten gekennzeichnet sein müssen, um vorherige Daten überschreiben zu können.Hierzu gibt es die Überschreibungsregeln (siehe Anlage). Sie beziehen sich hier auf folgende Aussagen des BDEW: https://www.edi-energy.de/index.php?id=38&tx_bdew_bdew%5Buid%5D=68&tx_bdew_bdew%5Baction%5D=download&tx_bdew_bdew%5Bcontroller%5D=Dokument&cHash=3091112ac0486bdc500acd76d264a66b Je nach Fall müssen die Felder Begründung und/oder Bildungsregel korrekt befüllt sein. Nun unsere Frage: Laut der Beschreibung (Codeliste der Statuszusatzinformation), auf die der Link verweist, sind bei MSCONS nur die Energiemengen und Zählerstände betroffen. Ist hiervon auch die MSCONS-TL (Lastgangdaten) betroffen? Leider haben wir hierzu keine Angabe gefunden. Wir würden uns über eine zeitnahe Antwort freuen. 2018-08-31 10:18:01 Sehr geehrter Forumsteilnehmer, wenn wir Sie richtig verstehen, wollen Sie wissen, wie Lastgänge storniert werden können. In der aktuellen Konsultationsfassung des MSCONS AHB 2.2i gibt es hier ein separates Kapitel „4.5 Stornierung / Korrektur von Werten“. Ergänzung vom 09.10.2018: Im Kapitel  4.5.3 Übersicht Korrekturvarianten von Werten je ursprünglichem Anwendungsfall (AHB MSCONS 2.2i) ist in der Spalte "Statuszusatzinformation ist anzugeben" ersichtlich, ob Statuszusatzinformationen anzugeben sind. Im Fall Lastgang (Prüfidentifikatior 13008) sind Statuszusatzinformationen mitzugeben. Ihr BDEW Forum Datenformate Ja Reinhard Döring Thomas Seipt Reinhard Döring Nadine Degen https://www.edi-energy.de/index.php?id=38&tx_bdew_bdew%5Buid%5D=68&tx_bdew_bdew%5Baction%5D=download&tx_bdew_bdew%5Bcontroller%5D=Dokument&cHash=3091112ac0486bdc500acd76d264a66b Nein -------------Thomas Seipt-------------31.08.2018 11:17 Antwortvorschlag an Herrn Döring Nein Nein
PRICAT AHB 1.0 Eingegangen Referenz (RFF+ACW) in der PRICAT bei erhaltener APERAK Referenz erfolgt immer auf die zuletzt gültige PRICAT 11.09.2018 2018-00115 Liebes Forum, im APERAK AHB ist unter Punkt 1.4 folgendes geregelt: "In Bezug auf sämtliche sich ergebende rechtliche Folgewirkungen (etwa Fristeinhaltung, Fälligkeits-oder Verzugseintritt etc.) gilt eine gerechtfertigt abgelehnte Übertragungsdatei, und somit alle darin enthaltenen Geschäftsvorfälle, als dem Empfänger nicht zugegangen." Wenn die Prüfung einer PRICAT eine APERAK zur Folge hat, würden wir rückschließen, dass die Nachricht nicht zugestellt ist und ggf. nicht im Backend System verarbeitet wurde. Die Frage lautet nun: Muss die neue PRICAT auf die vorherige PRICAT (mit APERAK) referenzieren? Freundliche Grüße 2018-09-11 09:19:37 Sehr geehrter Fragesteller, die Frage, ob eine PRICAT auf eine vorherige PRICAT referenziert, die per APERAK abgelehnt wurde, hängt davon ab, ob die APERAK gerechtfertigt war: Fall 1: APERAK war rechtens, dann gilt die PRICAT als nie versendet, somit muss die neue PRICAT auf die PRICAT verweisen, die zuletzt richtig aufgebaut war Fall 2: APERAK war ungerechtfertigt, dann gilt die die PRICAT als zugestellt und muss vom Fehlerverursacher nachverarbeitet werden. In diesem Falle würde die nächste "ordentliche" PRICAT natürlich auf die zuletzt verschickte PRICAT zeigen. Freundliche Grüße, Ihr Forum Datenformate Ja Thomas Seipt Klaus Keller Thomas Seipt Andre Koepsel Liebes Forum, im APERAK AHB ist unter Punkt 1.4 folgendes geregelt: "In Bezug auf sämtliche sich ergebende rechtliche Folgewirkungen (etwa Fristeinhaltung, Fälligkeits-oder Verzugseintritt etc.) gilt eine gerechtfertigt abgelehnte Übertragungsdatei, und somit alle darin enthaltenen Geschäftsvorfälle, als dem Empfänger nicht zugegangen." Wenn die Prüfung einer PRICAT eine APERAK zur Folge hat, würden wir rückschließen, dass die Nachricht nicht zugestellt ist und ggf. nicht im Backend System verarbeitet wurde. Die Frage lautet nun: Muss die neue PRICAT auf die vorherige PRICAT (mit APERAK) referenzieren? Freundliche Grüße Nein -------------Klaus Keller-------------20.09.2018 16:27 Antwortvorschlag erstellt Nein Nein
PRICAT AHB 1.0 Abgeschlossen Wie viele Preispositionen müssen im Preisblatt veröffentlicht werden? Die Anzahl der LIN-Positionen gibt der MSB vor. 27.07.2018 2018-00078 Preisblatt Messstellenbetrieb iMS, mME: Muss der MSB in der PRICAT im Segment SG36 (IMD7081) zwingend alle Preispositionen angeben, auch wenn die Preise für iMS <6000 ( Z28, Z29, Z30, Z31) noch nicht feststehen und nicht veröffentlicht sind? Grund der Anfrage sind Ablehnungen von Lieferanten per APERAK. 2018-07-27 12:56:42 Sehr geehrter Marktteilnehmer, es müssen im Preisblatt nur die Positionen veröffentlicht werden, für die auch ein Preis kalkuliert wurde bzw. welche später auch zur Abrechnung geführt werden. Damit ist eine Ablehnung eines „unvollständigen Preisblatts“ nicht gerechtfertigt. Die Anzahl der LIN-Positionen gibt somit der MSB vor. Ihr BDEW Forum Datenformate Ja Thomas Seipt Klaus Keller Thomas Seipt Mareike Boshüsen PRICAT AHB 1.0 Seite 7 Nein PG: ok und veröffentlicht -------------Beate Becker-------------09.08.2018 15:33 Nein Nein
PRICAT AHB 1.0 Abgeschlossen Gültigkeitszeiträume von Preisblättern 11.06.2018 2018-00047 Sehr geehrte Damen und Herren, bei der automatischen Verarbeitung von PRICATs (Preisblatt, 27002) stehen wir täglich vor der Herausforderung die Gültigkeit der Preisblätter für die Abrechnung ordnungsgemäß zu bewerten. Beispiel (gleicher MSB): PRICAT 1 hat ein Gültigkeitsbeginn (DTM+157) vom 01.07.2018 00:00, dann gilt dieses Preisblatt ab dem 01.07.2018 00:00. PRICAT 2 hat ein Gültigkeitsbeginn (DTM+157) vom 01.07.2018 00:05, dann gilt dieses Preisblatt ab dem 01.07.2018 00:05 und das vorherige Preisblatt gilt am 01.07.2018 von 00:00 bis 00:05. Diese Beispiele kann man bis auf die Sekundenebene herunter brechen und es gibt keine korrekte Möglichkeit die Preisblätter automatisiert für die Abrechnung heranzuziehen. Besteht die Möglichkeit, zukünftig stattdessen an dieser Stelle ein DTM mit dem FORMAT CCYYMMDD einzusetzen oder gibt es einen speziellen Hintergrund, warum an dieser Stelle eine Sekundengenauigkeit benötigt wird? Vielen Dank für Ihre Mühen. Freundliche Grüße Oliver Kunz 2018-06-11 08:04:31 Hallo Herr Kunz, um eine effiziente Abrechnung zu ermöglichen kann die Änderung eines Preisblattes nicht untertägig erfolgen. Das Beginndatum hat immer zu 00:00 Uhr eines Tages zu erfolgen. Hinweis: Die MSB-Abrechnung ist immer tagesscharf, somit macht eine untertägige Preisänderung keinen Sinn. Freundliche Grüße, Ihr Forum Datenformate Ja Thomas Seipt Klaus Keller Thomas Seipt Oliver Kunz PRICAT AHB (Seite 4 von 8) Nein -------------Klaus Keller-------------11.06.2018 17:10 erster Antwortvorschlag zur Diskussion -------------Klaus Keller-------------20.06.2018 14:11 Update der Antwort nach AG R/Z Nein Nein
UTILMD AHB WiM 3.0f Abgeschlossen Welche Kategorie der Nachricht ist im BGM-Segment zu verwenden? Die Code im BGM ergibt sich aus dem Anwendungsfall im AHB 06.09.2018 2018-00113 Sehr geehrte Damen und Herren, zu den nachfolgend aufgeführten Transaktionsgründen aus Prozess E02 Abmeldung Ende MSB ergeben sich zwei Fragestellungen. Kategorie E02 - Abmeldung mit Transaktionsgrund ZG9 Aufhebung einer zukünftigen Zuordnung wegen Auszug des Kunden Kategorie E02 - Abmeldung mit Transaktionsgrund ZH1 Aufhebung einer zukünftigen Zuordnung wegen Stilllegung Kategorie E02 - Abmeldung mit Transaktionsgrund ZH2 Aufhebung einer zukünftigen Zuordnung wegen aufgehobenem Vertragsverhältnis 1. Welche Nachrichtenkategorie wird im Zuge der Bestätigung vom NB aufgehoben ? Zu diesen Transaktionsgründen steht dem NB der Ablehnungsgrund E17 Fristüberschreitung zur Verfügung. 2. Welche Frist gilt es zu beachten bzw. welche Frist kann vom MSBA überschritten werden? Vielen Dank für die damit verbundene Mühe. Mit freundlichen Grüßen 2018-09-06 13:24:33 Sehr geehrter Forumsteilnehmer, Zu 1) Die Kategorie der Nachricht ist im Anwendungsfall im AHB beschrieben. Den Anwendungsfall finden Sie in der Liste der Prüfidentifikatoren mittles des Prozessschrittes aus der Festlegung. Mit diesem Prüfidentifikator finden Sie den Anwendungsfall im AHB. Sollten im Anwendungsfall meherer Kategorien im Segment BGM möglich sein, so sind diese mittels Bedingungen / Hinweisen beschrieben. Zu 2) Die Fristen ergeben sich aus den Prozessen / Festlegungen. Im Forum Datenformate können wir hiezu keine Aussagen treffen. Sollten Sie in den Prozessen keine relevante Frist finden können, so richten Sie diese Frage bitte an die PG Umsetzungsfragen beim BDEW. Freundliche GrüßeIhr Forum Datenformate Ja Thomas Seipt Thomas Fellhauer Thomas Seipt Birgit Dreyer Nein Vorschlag an die Herren Fröse und Weickenmeier -------------Thomas Seipt-------------07.09.2018 14:28 Habe Antwortvorschlag kommentiert: -------------Holger Weickenmeier-------------29.10.2018 14:48 Antwort von Holger übernommen -------------Thomas Seipt-------------01.11.2018 16:26 Nein Nein
Regelungen zum Übertragungsweg 1.1 Abgeschlossen Fehlendes Update Zertifikatssperrliste (CRL) von der CA Es darf keine abgelaufene CRL zur Prüfung verwendet werden 27.08.2018 2018-00099 Eine CRL ist erreichbar und kann heruntergeladen werden, aber diese ist zum Zeitpunkt des Downloads, nach Normalfall, abgelaufen, ist aber neuer als die bisherige CRL (auch abgelaufen, weil der Server nicht erreichbar war noch im Rahmen der Gültigkeit von 3 Tagen). Für diesen Sonderfall ist die Regeleung nicht eindeutig definiert. Welche dieser CRLs ist nun die zu korrekt benutzende? Die CRL welche bereits im Cache liegt, weil eine abgelaufende CRL als 'nicht erreichbar' deklariert wird, oder die neuere CRL, welche das konsistentere Verhalten wäre? 2018-08-27 12:10:12 Bei einem korrekten Betrieb der eigenen Infrastruktur dürfen abgelaufene CRL nicht verwendet werden. Eine Empfehlung für den Fall eines Fehlers in der eigenen Infrastruktur kann nicht gegeben werden. Ja Rene Hoffmann Sven Schillack Rene Hoffmann Peter Kunz Ist eine CRL über die in den Zertifikaten veröffentlichten CRL-DP von einer CA über 3 Tage nicht abrufbar, ist der ausstellenden CA und aller darunter gelisteten Zertifikate bis zur Veröffentlichung einer aktuellen CRL zu misstrauen. Nein Nein Nein
Regelungen zum Übertragungsweg 1.1 Abgeschlossen Wann darf frühestens die alte EDIFACT-Adresse gelöscht werden? Es besteht keine diesbezügliche Fristenregelung. 16.08.2018 2018-00089 Wenn die EDIFACT-Adresse geändert wird und alle Marktpartner über die neue E-Mail-Adresse informiert wurden, wann frühestens darf die alte EDIFACT-Adresse gelöscht werden? 2018-08-16 16:07:28 Es liegen in den Regelungen zum Übertragungsweg diesbezüglich keine Fristen vor. Es gibt eine Frist zur Ankündigung und eine Anforderung für die Terminierung des Umstelltages. Ansonsten wird auf den letzten Abschnitt in Kapitel 2 der Regelungen zum Übertragungsweg verwiesen. Ja Rene Hoffmann Sven Schillack Rene Hoffmann Ingrid Tomasi Punkt 2 Bekanntmachen beim Informationsempfänger …"Der Übertragungsweg zwischen zwei Marktpartnern ist mindestens für drei Jahre ab dem Tage nach dem letzten Datenaustausch (zwischen diesen beiden Marktpartnern) aufrecht zu halten." ..."Eine Aufrechterhaltung des Übertragungswegs bedeutet nicht, dass eine E-Mail-Adresse, die für den Datenaustausch verwendet und durch eine andere E-Mail-Adresse ersetzt wurde, drei Jahre lang nicht gelöscht werden darf. Wurde ein derartiges E-Mail-Postfach zu einer E-Mail-Adresse „stillgelegt", und alle Marktpartner entsprechend der voranstehenden Regel über die neue zu nutzende E-Mail-Adresse informiert, so kann die bisher genutzte E-Mail-Adresse gelöscht werden. " Nein -------------Rene Hoffmann-------------26.09.2018 10:02 Folgender Satz wurde nicht hinzugefügt (nicht besprochen in der PG-Sitzung 03.09.2018). Hinweis: Auch ohne Löschung oder Abschaltung der Mailadresse ist es möglich dem Absender anzuzeigen, dass ab Umstellungszeitpunkt an die veraltete Mailadresse gesendet wurde über eine entsprechende negative CONTRL-Meldung (Empfänger der Übertragungsdatei ist nicht der tatsächliche Empfänger ). Nein Nein
EDI@Energy Anwendungshilfe zu den Datenformaten des Interimsmodells 1.3, Stand: 30.07.2018 Abgeschlossen Kann die Energiemenge der Marktloaktion als Summe angegeben werden? Gesamtenergiemenge kann mit der 1.9.0 angegeben werden. 22.08.2018 2018-00094 Ein Netzbetreiber schickt uns in einer zugestimmten Antwort Anmeldung NN mit PI 11002 folgende Obis-Daten: - 1.1.8.1; Kein Schwachlast - 1.1.8.2; Kein Schwachlast - 1.1.9.0 ; Kein Schwachlast Es handelt sich hierbei um einen Doppeltarifzähler. Beide Zählwerke werden im HT abgerechnet. Als Obis-Code der Marklokation wird nur 1.1.9.0 angegeben. Das wird begründet mit dem folgendem Zitat aus der "Anwendungshilfe", Seite 37 "Nur im Fall, dass keine Unterscheidung der Schwachlastfähigkeit für die beiden Register auf Ebene der Messlokation erfolgt und zusätzlich keine Differenzierung im Netznutzungsentgelt besteht, kann alternativ angegeben werden: Auf Ebene der Marktlokation 1-b:1.9.0" Dürfen 2 HT Obis-Codes für die Messlokation angegeben werden? Ist die obige Angabe der Obis-Daten in einer 11002 zulässig? 2018-08-22 10:08:55 Sehr geehrter Forumsteilnehmer, die Vorgehensweise ist korrekt. Wir verstehen Ihr Beispiel so, dass für beide Register (1-1:1.8.1 und 1-1.1.8.2) auf Ebene der Messlokation keine Unterscheidung in der Schwachlastfähigkeit erfolgt und auch im Netznutzungspreis keine Unterscheidung an den beiden Register besteht. In diesem Fall kann die Gesamtenergiemenge mit einer OBIS-Kennzahl auf Ebene der Marktlokation (z.B. 1-1:1.9.0) angegeben werden.  Sind die oben beschrieben Voraussetzungen nicht mehr gegeben, z.B. bei einer Änderung der Schwachlastfähigkeit einer OBIS-Kennzahl auf Ebene der Messlokation, so muss dies durch eine Stammdatenänderungsmeldung auf Ebene der Marktlokation dem Lieferanten mitgeteilt werden. Ab diesem Moment müssen die Energiemengen auf Ebene der Marktlokation auch getrennt übermittelt werden (z.B. 1-1:1.9.1 & 1-1:1.9.2).   Ihr Forum Datenformate Ja Gregor Scholtyschik Thomas Seipt Gregor Scholtyschik Martina Sauter Nein -------------Thomas Seipt-------------29.08.2018 15:52 Antwort zur Diskussion gestellt (Holger und Gregor) -------------Gregor Scholtyschik-------------29.08.2018 20:52 Habe die Antwort ergänzt. -------------Stefan Seidel-------------25.09.2018 18:48 Tippfehler in Antwort korrigiert Nein Nein
MSCONS AHB 2.2h Abgeschlossen Kann eine MSCONS mit der Energiemenge einer Marktlokation zu mehreren INVOIC führen? nein 09.08.2018 2018-00083 In der Rolle als Netzbetreiber haben wir einem Lieferanten eine MSCONS_EM zugesendet, in der u.a. die Energiemengen von zwei Rechnungen zu einer Abnahmestelle enthalten sind. Der Vertrieb lehnt uns die INVOIC-Rechnungen dazu nun per REMADV ab mit der Begründung die Energiemengen würden nicht der Rechnung entsprechend. (Der Vertrieb vergleicht die kumulierte Energiemenge der MSCONS_EM mit nur einer der beiden Rechnungen). Nach Klärungsversuch besteht der Vertrieb auf die Ablehnung und erwartet für jede Rechnung eine separate MSCONS_EM. Zitat: "Bitte übersenden Sie uns die abrechnungsrelevante Energiemenge mit Angabe der korrekten OBIS je Rechnung zu. " Ist dieser Ablehnungsgrund berechtigt? Vielen Dank vorab für Ihre Bemühung. 2018-08-09 13:53:13 Sehr geehrter Marktteilnehmer, die Energiemenge der Marktlokation, die in einer MSCONS übermittelt wird, kann nur in einer INVOIC abgerechnet werden. Mit freundlichem Gruß, Ihr BDEW Forum Datenformate Ja Reinhard Döring Thomas Seipt Reinhard Döring Andreas Oberhofer Nein AG Rechnungsstellung: beantwortet und veröffentlicht -------------Beate Becker-------------26.09.2018 14:13 Nein Nein
MSCONS AHB 2.2h Abgeschlossen Detaillierung der Regelungen zum Storno sind aktuell in der Konsultation 09.08.2018 2018-00082 Sehr geehrte Damen und Herren, existiert eine einheitliche Regelung zum Versand von Storno-MSCONS-Nachrichten (Sparte Gas) durch den Netzbetreiber an den Lieferanten in folgendem Szenario: Der Lieferant sendet eine MSCONS VL (Prüfi: 13002) an den Netzbetreiber. Der Netzbetreiber reichert diese mit Brennwert und Zustandszahl an und sendet eine MSCONS an den Lieferanten zurück. Der Lieferant sendet nunmehr eine Storno-MSCONS (Prüfi: 13006) mit Bezug im ACW auf seine ursprüngliche MSCONS VL. Ist es vorgesehen, dass der Netzbetreiber seine, mit Gasdaten (Brennwert und Zustandszahl) angereicherte, MSCONS ebenfalls stornieren muss? Hintergrund dieser Frage ist, dass aufgrund des o. s. Szenarios die INVOIC mit negativer REMADV (Z10) beantwortet werden, da der Lieferant auf eine Storno-MSCONS seitens des Netzbetreibers besteht. Freundliche Grüße Jennifer Karaszkiewicz 2018-08-09 08:24:46 Sehr geehrte Frau Karaszkiewicz, die entsprechenden Vorgaben sind im Konsultationsdokument MSCONS_AHB_2.2i.pdf in Kapitel 4.5 gerade in der Konsultationsphase. Ihr BDEW Forum Datenformate Ja Reinhard Döring Thomas Seipt Reinhard Döring Jennifer Karaszkiewicz Nein Nein Nein
MSCONS AHB 2.2h Abgeschlossen Welcher Ablesegrund soll für eine monatliche Zwischenablesung verwendet werden? Verwendung von Ablesegründen 06.08.2018 2018-00081 In den aktuell gültigen Fassungen von WiM und GPKE sind für die Übermittlung von Messwerten bei intelligenten Messsystemen Messwertübertragungsfälle definiert. Für alle Messwertübertragungsfälle ist z.B. ein Versand von Gesamtzählerständen "Monatserster, 0 Uhr" von der Marktrolle NB an die Marktrolle LF vorgesehen. Angenommen, der NB rechnet die Netznutzung weiterhin in jährlichem Turnus ab. Ist es dann (für den Beispielfall MÜ-B) richtig, den Stand im Monat der Abrechnung (und damit auch abzurechnenden Stand) mit dem Ablesegrund PMR zu versehen, die "anderen 11 Stände" mit COT zu übermitteln? 2018-08-06 09:46:08 Sehr geehrter Marktteilnehmer, Ablesungen, die nicht direkt zu einer Abrechnung führen, werden mit dem Ablesegrund "COT" gekennzeichnet. D. h., die elf Zwischenablesungen zum Monatsersten werden in der MSCONS mit CCI+ACH++COT'  übermittelt. Sollte der Turnus auf monatlich geändert werden, müssen die zwölf monatlichen Zählerstände mit PMR „Turnusablesung“ gekennzeichnet werden, da diese dann auch abrechnungsrelevant sind. Ihr BDEW Forum Datenformate Ja Reinhard Döring Thomas Seipt Reinhard Döring Christian Löhr Nein PG: ok und veröffentlicht -------------Beate Becker-------------09.08.2018 14:29 Nein Nein
MSCONS AHB 2.2h Abgeschlossen Sind Stammdatenänderungsmeldung notwendig, wenn sich die Zählernummer geändert hat? Ablehnung mit APERAK - Z19 (Gerätenummer in der Messlokation nicht bekannt) ist durchzuführen. 31.07.2018 2018-00079 Hallo an das Team Datenformate, nach einem Netzbetreiberwechsel erhalten wir (Marktrolle Lieferant) vom NB neu MSCONS–Nachrichten unter Angabe einer veränderten Zählernummer ohne eine Stammdatenänderung erhalten zu haben. Zählernummer MSCONS vom NB alt z.B. 12345 Zählernummer MSCONS vom NB neu z.B. 011–12345 Da wir keine Stammdatenänderung erhalten haben, lehnen wir die MSCONS vom NB neu per APERAK Z19 automatisch ab. Gehen wir Recht in der Annahme, dass unsere APERAK berechtigt ist? Danke vorab und Viele Grüße. 2018-07-31 13:53:42 Sehr geehrter Marktteilnehmer, ändert sich die Zählernummer, ist eine Stammdatenänderung die Voraussetzung für neue Zählerstände. Die Ablehnung des MSCONS-Geschäftsvorfalls erfolgt mittels APERAK „Z19 - Gerätenummer in der Messlokation nicht bekannt“. Ihr BDEW Forum Datenformate Ja Reinhard Döring Thomas Seipt Reinhard Döring Stefan Frings Nein PG: ok und veröffentlicht -------------Beate Becker-------------09.08.2018 15:05 Nein Nein
MSCONS AHB 2.2h Abgeschlossen Muss der Netzbetreiber Zählerstände in der Zukunft verarbeiten? Abgelesene Zählerstände können nicht in der Zukunft liegen. 25.07.2018 2018-00076 Guten Tag, muss der Netzbetreiber Zählerstände in der Zukunft verarbeiten? Wir erhalten von einigen Lieferanten Zählerstände in der Zukunft, die wir logischerweise nicht verarbeiten. Anschließend wird dann von uns geschätzt und der Lieferant sendet uns eine Reklamation via REAMDV. Bsp. Ablesedatum 31.10.2018, MSCONS mit Zählerstand geht bereits am 22.10.2018 ein. Aus unserer Sicht kann der Lieferant diesen Stand am 22.10.2018 noch gar nicht kennen und ist daher irrelevant. Wie soll in diesem Fall Verfahren werden? Wir sind der Meinung, dass der Lieferant die MSCONS frühestens am 31.10.2018 senden kann. Es ist unzumutbar, dass der Netzbetreiber die MSCONS parkt und später verarbeitet! Kann die MSCONS via APERAK abgelehnt werden? MFG 2018-07-25 06:16:44 Sehr geehrter Marktteilnehmer, der Versand von Zählerständen kann vom Lieferanten an den Netzbetreiber nur für abgelesene Zählerstände erfolgen. Der früheste Zeitpunkt kann nur der Tag der Ablesung sein. Eine automatisierte Ablehnung per CONTRL oder APERAK ist nicht möglich. Hier ist eine bilaterale Klärung mit dem Absender notwendig. Ihr BDEW Forum Datenformate   Ja Reinhard Döring Thomas Seipt Reinhard Döring Andre Koepsel Nein PG: ok und veröffentlicht -------------Beate Becker-------------09.08.2018 14:36 Nein Nein
MSCONS AHB 2.2h Abgeschlossen Lastgangmessung nach Stilllegung Empfehlung: Zeit nach Ausbau - auffüllen mit Nullwerten (Status: Ersatzwert) 20.06.2018 2018-00054 Muss bei der Stilllegung eines lastgemessenen Gaszählers die Lastgang-MSCONS trotzdem die Daten für den kompletten Gastag enthalten? Bsp. Ausbau des Gaszähler erfolgt am 05.05.2018 um 12 Uhr. Muss die MSCONS nun mit Ersatzwerten bis 06.05.2018 6 Uhr befüllt werden, oder ist es zulässig dass nur die Daten des Ausbautages versendet werden. Schließlich ist am 06.05.2018 technisch kein Geräte mehr eingebaut. 2018-06-20 11:58:03 Hallo, Zum Zeitpunkt (kurz vor dem Ausbau des Zählers), muss die RLM-Messung "Rest" ausgelesen werden. Damit sind in der Regel wahre Werte bis zum Ausbauzeitpunkt zu versenden. Da die Meldung zum Ausbau (Stilllegung) eines Zählers nur tagesgenau erfolgt, empfiehlt es sich, den Rest des Tages mit Nullwerten mit dem Status "Ersatzwert" aufzufüllen. Auf diese Weise können Fragen bzw. Missverstämdnisse für die Zeit nach dem Ausbau vermieden werden. Ihr Forum Datenformate   Ja Reinhard Döring Thomas Seipt Reinhard Döring Steven Seidig Nein Nein Nein
MSCONS AHB 2.2h Abgeschlossen Ist der Verweis auf eine allte MSCONS (2.2.g) richtig? Es muss auch auf die aktulle Version (2.2.h) verwiesen werden. 01.06.2018 2018-00043 Sehr geehrte Damen und Herren, ist es korrekt, dass beim Prüfidentifikator 13013 und 13014 im UNH auf die Version 2.2g verwiesen wird oder sollte dort korrekterweise 2.2h stehen? Freundliche Grüße Oliver Kunz 2018-06-01 11:00:49 Hallo, vielen Dank für den Hinweis. Dies stellt einen Fehler dar und muss korrigiert werden. Die beiden Anwendungsfälle mit den Prüfidentifikatoren 13013 und 13014 müssen auf die Version 2.2h verweisen. Ihr Forum Datenformate Ja Reinhard Döring Thomas Seipt Thomas Seipt Oliver Kunz Seite 47 -> UNH 0057 Nein Nein Nein
MSCONS AHB 2.2h Eingegangen Kanalnummer "b" ist nicht erlaubt 29.05.2018 2018-00042 Sehr geehrte Damen und Herren, von einem Marktpartner erhielten wir eine marktlokationsscharfe Allokationsliste (Prüfidentifikator 13013), in welcher dieser die OBIS-ähnliche Kennzahl mit 7-b:9.98.0 aufführt. Unserer Ansicht nach sollte die Kanalnummer mit einem Wert von 0 bis 64 angegeben werden. Bei genauerer Prüfung der Codeliste OBIS-Kennzahlen 2.2f Seite 16 viel auf, dass entgegen der anderen Tabellen unter der Tabelle zu 4.2 "Weitere definierte OBIS-Kennzahlen zur Übertragung von Informationen zusätzlich zu Kapitel 4.1" nicht weiter auf die Kanalnummer eingegangen wird. Da der Punkt 4.2 laut Titel "zusätzlich zu Kapitel 4.1" erfolgt, müsste doch für diesen doch auch gelten "Kanal (irrelevant): b = 0 .. 64 ". Kann in diesem Fall die Kanalnummer mit der Variable "b" angegeben werden oder muss ein Zahlenwert erfolgen? Mit freundlichen Grüßen Sebastian Böhme 2018-05-29 11:55:12 Sehr geehrter Herr Böhme, für die marktlokationsscharfe Allokationsliste gilt ebenfalls die Vorgabe bzgl. der Kanalnummer (0 bis 64). Auch hier gilt Kapitel 2.3 Die Angabe eines Kanals ist für die Identifikation über die OBIS-KZ irrelevant (Wertebereich 0 bis 64) und basiert auf gerätetechnischen Vorgaben. Mit freundlichen Grüßen Forum Datenformate   Ja Reinhard Döring Thomas Seipt Reinhard Döring Sebastian Böhme Nein Unter die Tabelle 4.2 ebenfalls "Kanal (irrelevant): b = 0 .. 64" aufnehmen. -------------Reinhard Döring-------------29.05.2018 13:36 Ja Nein
MSCONS AHB 2.2h Eingegangen 25.05.2018 2018-00037 Sehr geehrte Damen und Herren, ist es erlaubt, dass in einer MSCONS in 2 UNHs verschiedene Prüfidentifikatoren verwendet werden? Beispiel: UNH1: RFF 13006 UNH1: RFF 13009 Wir konnten diesbezüglich keine Einschränkung in den Dokumenten finden, allerdings ist es in der täglichen Arbeit nicht schön, dass sowohl eine Stornonachricht wie auch ein neuer Wert in ein und derselben MSCONS sind. Vielen Dank für Ihre Mühen. Freundliche Grüße Oliver Kunz 2018-05-25 08:37:25 Sehr geehrter Herr Kunz, wenn sowohl im UNB DE0026 eine Sortenreinheit gegeben ist und ebenfalls eine Sortenreinheit im BGM DE1001 gegeben ist, können die Nachrichten "gebündelt" werden. Siehe dazu "Allgemeine Festlegungen" Kapitel 1.22. Mit freundlichen Grüßen Forum Datenformate Ja Reinhard Döring Thomas Seipt Reinhard Döring Oliver Kunz Nein Nein Nein
MSCONS AHB 2.2h Eingegangen Kann die Kanalnummer in der OBIS-Kennzahl 7-0:33.86.0, von 0 auf b, d. h. auf irrelevant, angepasst werden? Aktualisierte Antwort: Kanalnummer in der OBIS-Kennzahl der Energiemenge für Gas wird nicht angepasst 09.05.2018 2018-00023 Sehr geehrte Damen und Herren, bei der Übermittlung von Energiemengen in der Sparte Gas ist laut EDI@Energy Codeliste der OBIS-Kennzahlen für den deutschen Energiemarkt (Version: 2.2f) lediglich die Obis 7-0:33.86.0 zu verwenden. In der Sparte Strom kann man die Kanalnummer frei wählen, um so bspw. unter Energiemenge und Korrekturenergiemenge eindeutig unterscheiden zu können. Dies ist in der Sparte Gas nicht möglich, da hier lediglich die Kanalnummer „0“ festgelegt wurde. Können Sie uns bitte mitteilen, wie in der Sparte Gas eine eindeutige Unterscheidung der Energiemengen vorzunehmen ist? Vielen Dank im Voraus! Mit freundlichen Grüßen Björn Bluhm 2018-05-09 09:14:12 Sehr geehrter Herr Bluhm, Sie haben Recht. Hier besteht ein Unterschied im Vergleich zur Regelung für Strom. Diese für Gas abweichende Vorgabe ist schon seit dem 9. Juni 2017 bzw. 1.10.2017 im produktiven Einsatz und die von Ihnen genannte Notwendigkeit zur Unterscheidung zwischen Energiemenge und Korrekturenergiemenge anhand der OBIS-Kennzahl besteht nicht, denn: Eine Korrekturmenge ist ausschließlich auf Ebene der Messlokation anzugeben und somit sind in der MSCONS die ZP-Bezeichnung und die OBIS-Kennzahl anzugeben. Die Gesamtenergiemenge ist ausschließlich auf Ebene der Marktlokation anzugeben und somit sind in der MSCONS die MaLo-ID und die OBIS-Kennzahl anzugeben. Außerdem bedeutet b, dass die dort getroffenen Aussage irrelevant ist. Irrelevant bedeutet, dass die Zahl, die an der Stelle steht keine Information überträgt, d. h. die Zahl, die in der Kanalnummer steht in allen Prozessen zu ignorieren ist. Somit könnte diese Unterscheidung nur beim Absender der MSCONS hausintern, d. h. vor dem Versenden der MSCONS genutzt werden. Vorgaben zu treffen, wie Informationen in den Unternehmen abgelegt werden, ist nicht Aufgabe von EDI@Energy. Somit sind wir nach erneuter, eingehender Diskussion zu dem Ergebnis gekommen, dass die bisherige Vorgabe für die OBIS-Kennzahl der Energiemenge (kWh) "7-0:33.86.0" nicht angepasst wird. Mit freundlichen Grüßen Ihr BDEW Forum Datenformate Ja Reinhard Döring Thomas Seipt Reinhard Döring Björn Bluhm Nein -------------Reinhard Döring-------------09.05.2018 10:32 -------------Stefan Seidel-------------05.06.2018 21:34 Überarbeitung aufgrund der Diskussion in der EDI@Energy-Sitzung 29./30.5.2018 eingefügt und veröffentlicht Nein Ja
MSCONS AHB 2.2h Eingegangen Referenz identifiziert die zu stornierende Originalnachricht eindeutig 04.05.2018 2018-00017 Sehr geehrte Damen und Herren, wir erhalten Storno-MSCONS-Nachrichten für Energiemengen von einem Netzbetreiber. Die ursprüngliche Meldung der Energiemenge enthielt die Marktlokation als Identifier. Die Stornonachricht enthält als Identifier die Messlokation. Nach dem MSCONS-AHB muss die Originalnachricht die Marktlokation enthalten, bei der Stornonachricht nach Kap. 6.2 sind sowohl Markt- als auch Messlokation zulässig. Als 1-Referenztupel zur Zuordnung zur Originalnachricht reicht hier die ID der Nachricht. Hierauf beruft sich der Netzbetreiber. Soweit sind die Nachrichten u.E. korrekt. Unsere Frage geht jetzt in die Richtung, ob diese Regelungen so sinnvoll sind. Die Stornomeldungen sind hier für Zählerstände und Energiemengen ausgeprägt, so dass man beide Lokationen zulassen muss. Besteht die Möglichkeit, dies für Energiemengen zu präzisieren, damit der oben beschriebene Fall nicht auftreten kann? Damit wäre es im Datenaustausch eindeutiger geregelt in der Art, dass Storno- und Originalnachricht einheitliche Identifier führen. Vielen Dank für Ihre Mühe. Mit freundlichen Grüßen Sebastian Weiße 2018-05-04 10:43:09 Sehr geehrter Herr Weiße, die Referenz zur Originalnachricht wird in SG1 RFF+ACW DE1154 (Referenzangaben) angegeben und damit die zu stornierende Nachricht eindeutig definiert. Wir sehen hier keinen Anpassungsbedarf. Mit freundlichen Grüßen Forum Datenformate   Ja Reinhard Döring Thomas Seipt Reinhard Döring Sebastian Weiße Nein Nein Nein
MSCONS AHB 2.2h Eingegangen Siehe MSCONS AHB Kapitel 4.3 10.04.2018 2018-00002 Wir übersenden an den Netzbetreiber Kundenablesungen mit Ablesegrund PMR (asynchrone Turnusabrechnung gegenüber dem Netzbetreiber). Wir sind der Auffassung, dass der Netzbetreiber diese MSCONS Nachricht bei sich im System als Zwischenablesung (COT) ablegen muss. Regelmäßig werden uns diese abgelehnt, mit der Begründung, dass wir als Lieferant nicht mit dem Ablesegrund PMR versenden dürfen. Wie wäre hier die richtige Vorgehensweise? 2018-04-10 13:29:49 Sehr geehrte Frau Sandrock, aus der folgenden Definition PMR wird bei Übermittlung der Turnusablesung zu den Terminen verwendet, die in der Turnus-Beauftragung über die UTILMD als „Geplante Turnusablesung" und „Turnusintervall" vereinbart sind. ist ersichtlich, dass für den von Ihnen beschriebenen Anwendungsfall der Ablesegrund PMR nicht verwendet werden darf. Für diesen Anwendungsfall kann COT verwendet werden. Mit freundlichen Grüßen Forum Datenformate Ja Reinhard Döring Beate Becker Reinhard Döring Jana Sandrock Nein Nein Nein
UTILMD AHB Stammdatenänderung 1.0c Abgeschlossen Wie sind die Datumsfelder in der Stammdatenänderung zu befüllen? Wie die Datumsfelder "Beginn zum" und "Änderung zum" zu verwenden sind, ist im UTILMD AHB Stammdatenänderung beschrieben. 01.08.2018 2018-00080 Guten Tag, ich habe eine Frage zu einer Änderungsmeldung: Wir als Lieferant übermitteln dem Netzbetreiber eine bilanzierungsrelevante Änderungsmeldung mit Änderung des Bilanzkreises. Der Kunde wird seit 01.01.2018 beliefert und die Änderung soll zum 01.05.2019 gültig sein. Welches Datum wird als DTM 2005 / 92 Datum Vertragsbeginn vom Lieferanten angegeben? Aus der konsolidierten Lesefassung Stand 17.07.2018 Seite 28 lesen wir das der 01.01.2018 korrekt ist. Der Netzbetreiber hat uns die Änderungsmeldung mit einer APERAK beantwortet und verlangt das Datum 01.05.2019 als Vertragsbeginn. Was ist korrekt? Vielen Dank im Voraus 2018-08-01 07:47:33 Sehr geehrter Marktpartner, Sie hatten Ihre Frage zur Nachrichtenbeschreibung eingereicht. Diese haben wir dem Stammdatenänderungs AHB zugeordnet, da hier das Vorgehen in Bezug auf die Daten "Beginn zum" und "Änderung zum" eingehend beschrieben sind.  Auszug aus dem AHB Stammdatenänderung: Gültigkeitszeitpunkt (Beginn zum):Der Gültigkeitszeitpunkt für aktuell der Marktlokation bzw. Messlokation zugeordnete Berechtigte ist identisch mit dem Änderungsdatum (Änderung zum). Der Gültigkeitszeitpunkt für zukünftig der Marktlokation bzw. Messlokation zugeordnete Berechtigte ist der Zeitpunkt der Zuordnung des Berechtigten zur Marktlokation bzw. Messlokation und dient in diesem Fall ausschließlich zur Identifizierung der Marktlokation bzw. Messlokation. Änderungszeitpunkt (Änderung zum):Der Änderungszeitpunkt für aktuell und zukünftig der Marktlokation bzw. Messlokation zugeordnete Berechtigte ist der Zeitpunkt ab wann das geänderte Stammdatum in der Marktkommunikation zwischen den beteiligten Marktpartnern zu verwenden ist.Bei Stammdatenänderungen wird unterschieden nach Änderungen, die zu einem in der Meldung (ggf. auch rückwirkend) genannten Zeitpunkt Gültigkeit erlangen und Änderungen, die erst zu einem festen in die Zukunft gerichteten Zeitpunkt wirksam werden (z. B. bilanzierungsrelevante Daten).Der NB informiert immer alle Berechtigten (dazu gehören auch in die Zukunft zugeordnete Berechtigte) über geänderte Stammdaten. An alle Berechtigten wird immer der tatsächliche Änderungszeitpunkt in der Meldung übermittelt. Bei zukünftig der Marktlokation bzw. Messlokation zugeordneten Berechtigten sind der Änderungszeitpunkt und der Gültigkeitszeitpunkt unterschiedlich.Sind unterschiedliche Zeitpunkte der Inkraftsetzung von Daten erforderlich, so müssen entsprechend mehrere Vorgänge gebildet werden. Aus Ihrer Frage entnehmen wir, dass der Lieferbeginn in Bezug auf das Versanddatum des Versands der Stammdatenänderung, in der Vergangenheit lag. Somit sind Sie der Lieferant, der aktuell der Marktlokation zugeordnet ist. In diesem Fall sind beide Datumsfelder "Beginn zum" und "Änderung zum" mit dem identischen, in der Zukunft liegenden Datum, in Ihrem Beispiel 01.05.2019, zu befüllen. Eine Abweichung ist nur dann vorhanden, wenn das Lieferbeginndatum (Beginn zum) in Bezug auf das Versanddatum der Stammdatenänderung noch in der Zukunft liegt.  Viele Grüße Ihr BDEW Forum Datenformate Ja Holger Weickenmeier Jessica Riekhoff Jessica Riekhoff Ina Stoller Nein Hallo Jessica, bitte gegenlesen. -------------Holger Weickenmeier-------------04.08.2018 14:53 PG: ok und veröffentlicht -------------Beate Becker-------------09.08.2018 14:44 folgende Tippfehler in der Antwort korrigiert: Sie hatten Ihre Frage zur Nachrichtenbeschreibung eingereicht. Diese haben wir dem Stammdatenänderungs AHB zugeordenet, da hier das Vorgehen in Bezug auf die Daten "Beginn zum" und "Änderung zum" eingehend beschrieben sind. … Somit sind Sie der Lieferant, der aktuell der Marktlokation zugeordnet ist. In diesm Fall sind beide Datumsfelder d. h. zugeordenet zu zugeordnet und diesm zu diesem gemacht -------------Stefan Seidel -------------15.08.2018 13:12 Nein Nein
UTILMD AHB Stammdatenänderung 1.0c Abgeschlossen Muss bei der "Nicht bilanzierungsrelevante Anfrage der komplexen Marktlokationsstruktur beim NB" eine Messlokation angegeben werden? Es handelt sich bei der "Nicht bilanzierungsrelevante Anfrage der komplexen Marktlokationsstruktur beim NB" um eine Stammdatenänderung und nicht um eine Anfrage in Bezug auf fehlende Stammdaten. 13.07.2018 2018-00069 Hallo Forum, Bei der Anfrage der komplexen Marktlokationsstruktur (LF an NB // Prüfidentifikator 11180) besteht Klärungsbedarf bezüglich der Bedingung [590] im SG5 LOC. Diese besagt, dass die ID der Marktlokation und aller Identifikatoren der Messlokationen anzugeben sind. Da u. U. nur die ID der Marktlokation (für komplexe Konstrukte) bekannt ist, wird die Anfrage verwendet, um die Marktlokationsstruktur zu erfragen. Wenn die Messlokation/en bekannt wären, müsste die Anfrage nicht versendet werden. Dennoch bekamen wir aufgrund der o. g. Bedingung im AHB von einem Marktpartner eine APERAK mit der Begründung „fehlende Messlokation“. Ist die APERAK berechtigt bzw. liegt ein Fehler im AHB vor? 2018-07-13 10:17:54 Sehr geehrter Marktpartner, wenn wir Sie richtig verstanden haben, so möchten Sie mit dieser Anfrage fehlende Stammdaten in Ihrem System ergänzen. Die Stammdatenänderung ist ausschließlich dafür vorgesehen, dass Sie dem anderen Marktpartner "Änderungen" mitteilen, über die Sie neuere / bessere Erkenntnisse haben.  Zur Frage ob eine APERAK berechtigt ist, wenn Sie in diesem Anwendungsfall lediglich den Meldepunkt der MaLo angeben: In diesem Anwendungsfall gibt es am SG5 LOC+172 (Meldepunkt) folgende Konstellation: Muss [527][527] Hinweis: Es ist die ID der Marktlokation und alle Identifikatoren der Messlokationen anzugeben. Sollte für die Markt- und Messlokation die gleiche ID verwendet worden sein, so ist diese nur einmal aufzuführen. Im Weiteren gibt es auf Ebene der SG8 SEQ+Z01 (Marktlokation / Messlokation / Tranche / MaBiS-ZP / Teil des EUZ-Tupels) diese Konstellation: Muss [95][95] Je SG5 LOC+172 ist genau einmal die Segmentgruppe anzugeben Weitere relevante Bedingungen sind in diesem Anwendungsfall nicht enthalten. Zu der Art der APERAK haben Sie keine Angaben gemacht. In Bezug auf die Begründung würden wir davon ausgehen, dass Sie einen AHB Fehler erhalten haben, da dem Empfänger Daten in der Anfrage fehlen.Keine der beiden Bedingungen, wobei es sich bei SG5 LOC+172 nicht um eine Bedingung, sondern lediglich um einen Hinweis handelt, kann zu einer APERAK (AHB Fehler) aufgrund einer fehlenden Angabe einer Messlokation führen.Mit der AHB-Prüfung der APERAK können nur Bedingungen innerhalb eines Anwendungsfalls geprüft werden. Nicht Bestandteil der AHB Prüfung ist eine Prüfung gegen den Datenbestand aus den eigenen Stammdaten. Viele Grüße Ihr BDEW Forum Datenformate   Ja Holger Weickenmeier Jessica Riekhoff Jessica Riekhoff Daniel Härtig Nein Hi Jessica, lies mal gegen. Wenn für Dich OK, dann sollte das ev. noch zu einem APERAK Spezi? -------------Holger Weickenmeier-------------04.08.2018 14:55 PG: ok und veröffentlicht -------------Beate Becker-------------09.08.2018 15:09 Nein Nein
UTILMD AHB Stammdatenänderung 1.0c Abgeschlossen Muss die Änderung der komplexen Marktlokationsstruktur nicht auch an den MSB gesendet werden können? Der MSB benötigt im Interimsmodell die Marktlokationsstruktur nicht. 25.06.2018 2018-00056 Hallo Forum-Team, ich habe eine Frage bezgl. der Anwendung der PI 11175 (Nicht bilanzierungsrelevante Änderung der komplexen Marktlokationsstruktur durch den NB) und PI 11173 (Änderung der Lokationsbündelstruktur durch den NB (Strom)). Ändert sich etwas an der Zuordnung zwischen MaLo und MeLo (z.B.: eine MeLo fällt weg oder kommt zur MaLo hinzu) muss der NB dies per 11175 an den LF mitteilen. Der MSB ist doch über diese Änderung mit PI 11173 zu informieren oder bekommt dieser auch den PI 11175? Laut der Anwendungsübersicht der Prüfidentifikatoren (Stand 26. März 2018) ist der PI 11175 ausschließlich für die Kommunikation zwischen NB und MSB vorgesehen. Dies ist vermutlich ein Fehler oder? 2018-06-25 16:28:01 Sehr geehrter Marktteilnehmer, die Änderung der komplexen Marktlokationsstruktur  (PID 11175) erhält lediglich der LF:Mit der MaLo-Strukutur wird ausgesagt, welche MeLos zu einer MaLo gehören / welche Messwerte geliefert werden um die Energiemenge an der MaLo zu bestimmen. Diese Information benötigt der MSB im Interimsmodell nicht, da dieser lediglich Messwerte an der MeLo erfasst und kommuniziert. Der MSB erhält lediglich die Änderung der Lokationsbündelstruktur (PID 11173)Hiermit wird der MSB in Kenntnis gesetzt, dass zur Ermittlung einer Energiemenge einer MaLo noch weitere MeLos benötigt werden, bzw. dass eine eine MeLo für mehrere MaLos die Grundlage zur Ermittlung der Energiemenge liefert.Dies ist für den MSB von Bedeutung, da er sich für die Zeit nach dem Interimsmodell darauf einrichten muss, dass er ggf. Messwerte mit anderen MSBs austauschen muss, damit er als MSB bzw. ein anderer MSB die Messwerte erhält um die Enegiemenge einer MaLo zu ermitteln. Für den LF ist das Lokationbündel unerheblich. Viele Grüße Ihr BDEW Forum Dateinformate Ja Holger Weickenmeier Jessica Riekhoff Jessica Riekhoff Patrick Pleitgen Nein Jessica bitte gegenlesen -------------Holger Weickenmeier-------------04.08.2018 15:26 PG: Fehlerkorrektur für Anwendungsübersicht der Prüfidentifikatoren erforderlich PID 11175 bzw. 11176 muss vom NB an LF bzw. vom LF an NB gehen und nicht an MSB -------------Beate Becker-------------09.08.2018 15:21 Ja Nein
UTILMD AHB Stammdatenänderung 1.0c Abgeschlossen Werden in der SDÄ Werte in Segmenten nur durch neue Stammdaten ersetzt und leere Datenelemente beibehalten? In einem Segment / Segmentgruppe sind immer alle DE zu füllen, welche Bestand haben sollen 07.06.2018 2018-00046 Sehr geehrtes Forum, folgenden Fall bekommen wir mit einem beteiligten MP in der Funktion VNB nicht geklärt. Wir als Lieferant haben dem VNB eine SDÄ zur Namensänderung - PID 11109 gesendet. In dieser haben wir nur den Namen/Firmenname und die Korrespondezadresse des Kunden, so wie die weiteren Pflichtfelder für diesen PID übermittelt. Der Vorgängerkunde beinhaltete Vor- und Zuname. Musste aber geändert werden. Jetzt teilt uns der Empfänger, nachdem wir die E06-Liste geprüft haben und der Vorname immer noch aufgelistet wird mit, dass dies zu Recht erfolgt, weil wir ja nur den "Nachnamen" geändert hätten. Wir vertreten die Ansicht, wird in einer SDÄ zur Namensänderung der Vorname zum Beispiel weggelassen, ist dies wie eine Löschung zu behandeln. Liegen wir mit dieser Ansicht richtig oder falsch? 2018-06-07 11:19:01 Sehr geehrter Marktteilnehmer, Ihre Interpretation, dass ein Weglassen als "löschen" zu verstehen ist, ist korrekt. Hintergrund:In der Vergangenheit hatte man versucht durch die Angabe von den Zeichen "###" als Löschkennzeichen zuvor ausgetauschte Werte zu löschen. Mit dem Umbau der Stammdatenänderungslogik ist dies entfallen.Es werden immer alle relevanten Informationen in einem Segment / Segmentgruppe angegeben. Dies ist auch im AHB unter Kapitel 5.3 "Hinweis zum Aufbau der Stammdatenänderung" zum Ausdruck gebracht worden. In der Änderungsmeldung sind immer alle Stammdaten innerhalb einer Segmentgruppe bzw.durch Wiederholung der entsprechenden Segmentgruppe anzugeben, die an einem Marklokationbzw. Messlokation ab dem Datum „Änderung zum― Gültigkeit haben. Für Ihr Beispiel würde das bedeuten: Sie hatten in der Anmeldung folgende Information im NAD+UD versendet: NAD+UD+++Mustermann:Jochen::::Z01' Dem NB liegt als Name nun Mustermann Jochen vor. In einer darauf folgenden Stammdatenänderung senden Sie dann NAD+UD+++:Mustermann GbR::::Z02' Nach Ihrer Beschreibung läge dem NB nun die Information "Mustermann GbR Jochen" vor. Nach den Beschreibungen der Stammdatenänderung sollte dem NB nun auch nur noch "Mustermann GbR" vorliegen. Ein "löschen" durch ein Löschkennzeichen gibt es nicht mehr.  Viele Grüße Ihr Forum Datenformate     Ja Holger Weickenmeier Jessica Riekhoff Jessica Riekhoff Matthias Klöckner Nein An Jessica zum prüfen weitergeleitet -------------Holger Weickenmeier-------------08.06.2018 15:01 -------------Jessica Riekhoff-------------18.06.2018 17:26 Nein Nein
ORDERS / ORDRSP AHB Geschäftsdatenanfrage 1.4 Abgeschlossen Geschäftsdatenanfrage vom NB an MSB nur für Bewegungsdaten 20.07.2018 2018-00072 Sehr geehrte Damen und Herren, als Verteilnetzbetreiber haben wir lt. Handbuch die Möglichkeit, per ORDERS und Prüfindikator 17102 eine Geschäftsdatenanfrage an den Messtellenbetreiber zu versenden, um von diesem Stammdaten abzufragen. Von angefragten Messstellenbetreibern erwarten wir hierdurch aktuelle (Geräte-)Daten der Messlokation. Allerdings finden wir in den Beschreibungen nicht, welches Datenformat mit welchem Prüfindikator als Antwort des Angefragten verwendete werden soll/muss. Vielen Dank für Prüfung und Antwort. 2018-07-20 07:32:42 Sehr geehrter Forumsteilnehmer, mit der Lesefassung des AHB Geschäftsdatenanfrage vom 15.11.2017 wurde die Möglichkeit für den Netzbetreiber geschaffen beim Messstellenbetreiber eine Geschäftsdatenanfrage nach Bewegungsdaten zu stellen, die durch die Umsetzungsfrage "UF_Interim_017" erforderlich wurde. Als Grund der Anpassung wird in der Änderungshistorie darauf verwiesen: "Es muss gemäß Umsetzungsfrage UF_Interim_017 „Wie kann der NB beim MSB Bewegungsdaten im Interimsmodell anfordern?“ möglich sein, dass Netzbetreiber bei Messstellenbetreibern Bewegungsdaten per Geschäftsdatenanfrage nachfordern können." Für eine Geschäftsdatenanfrage vom NB an den MSB nach Stammdaten fehlt die prozessuale Grundlage. Dies sollte durch einschränkende Bedingungen in dem Anwendungsfall im AHB bei nächster Gelegenheit präzisiert werden. Vielen Dank für ihren Hinweis! Freundliche Grüße, Ihr Forum Datenformate Ja Holger Kampmann Thomas Fellhauer Holger Kampmann Hubertus Küster BDEW Bundesverband der Energie- und Wasserwirtschaft e. V. Seite 12 3.1.2 Anfrage zur Übermittlung von Messwerten und Stammdaten im Folgeprozess Nein Nein Nein
QUOTES MIG 1.1 Abgeschlossen QUOTES-Datei darf mehrere Nachrichten enthalten 18.06.2018 2018-00053 Segmentwiederholungen UNH doch erlaubt? 2018-06-18 15:14:45 Sehr geehrter Forumsteilnehmer, in einer QUOTES-Datei dürfen mehrere Nachrichten (mehrere UNH) enthalten sein, so wie es in den Allgemeinen Festlegungen festgelegt ist. In den Nachrichtenbeschreibungen (MIG) liegt der Fokus auf der Nachricht, deshalb ist die Wiederholung im MIG beim UNH-Segment mit 1 angegeben. Die Dateiebene wird dort nicht betrachtet. Mit freundlichem Gruß, Ihr Forum Datenformate Ja Holger Kampmann Thomas Fellhauer Holger Kampmann Madeleine Meier Hallo, wir erhalten "aggregierte" QUOTES Z29, heißt es sind mehrere Z29 Vorgänge und damit mehrere UNH Segmente enthalten. Diese können vom System nicht verarbeitet werden. Laut QUOTES Mig v1.1 sind Wiederholungen des UNH Segments unzulässig (MaxWdh = 1). Die Allgemeinen Festlegungen v4.4 scheinen dem auf Seite 17 zu widersprechen: "Mehrere Nachrichten in Übertragungsdatei zulässig?" --> Ja Wie ist es denn richtig? Danke im Voraus Nein Nein Nein
APERAK / CONTRL AHB 2.3d Abgeschlossen Führen zu viele Segmentwiederholungen, welche durch eine Bedingung eingeschränkt sind, zu einer APERAK Z29? Zu viel gesendete Informationen sind zu ignorieren 04.06.2018 2018-00044 Sehr geschätztes Forum-Team. Einer unserer Marktpartner sendet uns Ablehnungen auf EoG-Anmeldungen (Prüfi 11015) mit insgesamt zwei LOC+172-Segmenten im Vorgang. Gemäß UTILMD-AHB GPKE/GeLiGas (konsolidierte Lesefassung vom 26.03.2018) gilt für die durch das Segment LOC+172 zu eröffnende SG5 "Meldepunkt" für diesen Anwendungsfall die Bedingung [61] "Segmentgruppe ist genau einmal je SG4 IDE anzugeben". Unsere AHB-Prüfung setzt auf dieser Bedingung auf und lehnt deshalb beim Prüfi 11015 einen Geschäftsvorfall mit zwei LOC+172-Segmenten innerhalb der SG4 (entspricht mehr als einer SG5 innerhalb der SG4) mit Fehlercode Z29 ab. Der Marktpartner reklamiert unsere AHB-Fehlermeldung unter Verweis auf die Regelung, daß eine zuviel gesendete Information (in diesem Fall die Angabe eines zweiten Meldepunktes) vom Empfänger zu ignorieren ist (EDI@Energy CONTRL (Syntax Version 3) / APERAK Anwendungshandbuch vom 01.04.2017, Kap. 3.1.2, S. 17, Absatz 2, Satz 2). Wir hingegen sind der Auffassung, daß in diesem speziellen Anwendungsfall (Prüfi 11015) unter Berücksichtigung der gegebenen AHB-Bedingung [61] die zuviel gesendete Information die durch den Prüfi vorgegebene AHB-Prüfschablone verletzt und somit zum AHB-Fehler Z29 führt. Eine Klarstellung von Ihrer Seite, welches Vorgehen hier tatsächlich angewendet werden soll (AHB-APERAK oder zweites LOC+172-Segment ignorieren) würde uns entschieden weiterbringen. Vielen Dank im voraus und Beste Grüße Andreas Brardt 2018-06-04 15:34:56 Sehr geehrter Marktpartner, vielen Dank für Ihren Beitrag. Wie eine Verarbeitbarkeitsfehlermedlung durchzuführen ist, ist im CONTRL / APERAK AHB beschrieben. (Hier Version 2.3d) Im Kapitel 3.1.2 "AHB-Prüfung" ist beschrieben wie diese anzuwenden ist. Hier findet sich folgender Abschnitt. (Auszug) Enthält ein Geschäftsvorfall weniger Informationen, als er gemäß der AHB-Vorgabe enthalten muss, soist er abzulehnen. Hier ist zu beachten, dass Informationen, die gemäß des Prüfidentifikators nichtenthalten sein sollten vom Empfänger des Geschäftsvorfalls zu ignorieren sind. Ist aufgrund desPrüfidentifikators die für den Anwendungsfall beschriebene Ausgestaltung der Prüfschablone aufgrundder im Geschäftsvorfall enthaltenen Informationen und der Abhängigkeiten nicht eindeutig, soentscheidet der Empfänger des Geschäftsvorfalls welche Informationen des Geschäftsvorfalls erignoriert und welche er zur Ausgestaltung der Prüfschablone und somit zur AHB-Prüfung verwendet.Sollte sich aus den im Geschäftsvorfall enthaltenen Informationen, die den Umfang für denAnwendungsfall überschreiten und dem Ignorieren der zu viel übertragenen Informationen, eine vomAbsender des Geschäftsvorfalls ungewünschtes Verhalten des Empfängers ergeben, so hat derAbsender des Geschäftsvorfalls die sich daraus ergebenden Konsequenzen zu tragen. In der Beschreibung und der Erläuterung des Code Z29 findet sich auch der Hinweis, dass dieser nicht für Ihren Fall geeignet ist. Z29 "Erforderliche Angabe für diesenAnwendungsfall fehlt" In dem Anwendungsfall, der sich aus dem im Geschäftsvorfall angegebenen Prüfidentifikator ergibt, fehlt an der angegebenen Stelle die Segmentgruppe oder das Segment oder die Datenelementgruppe oder das Datenelement laut zugehöriger Spalte (inklusive MussBedingung) aus dem AHB. Wie der Beschreibung / Erläuterung zu entnehmen ist, ist dieser nur bei fehlen einer Information anzuwenden. Für Ihren Fall gibt es, aufgrund der oben genannter Definition des AHB Fehlers, keinen Code.  Wie in Kapitel 3 "Einsatz der APERAK Nachricht" auch beschrieben ist, werden anderweitige Fehler auf anderem Weg übermittelt. Dies ist durchaus sinnvoll, da auch dem Sender an einer korrekten Nachricht gelegen sein sollte. Im beschriebenen Fall, und den uns zur Verfügung stehenden Informationen, ist der Einsatz einer APERAK nicht gerechtfertigt. Da die AHB Prüfung lediglich den Mindestumfang prüft, sehen wir dies jedoch nicht als Rechtfertigung an, den Umfang nicht auf das erforderliche Maß einzuschränken. Hier sehen wir, für zukünftige Nachrichten auch eine Korrektur beim Sender der Nachrichten. Viele Grüße  Ihr Forum Datenformate Ja Klaus Keller Stefan Seidel Stefan Seidel Andreas Brardt UTILMD-AHB GPKE/GeLiGas, Version 6.0f (konsolidierte Lesefassung vom 26.03.2018), Kap. 4.6, S. 54 Nein Hallo Herr Seidel, ich habe die Frage Ihnen zugeordnet und mal einen Antwortvorschlag erstellt. Da dies doch sehr APERAKlastig ist, ist eine Abstimmung mit Ihnen notwendig. Ich habe mich aber auch gefragt ob diese Frage nicht ev. in die APERAK verschoben werden sollte. Sollten Sie dieser Meinung sein, so schließe ich mich an. Ansonsten kann es auch in der UTILMD verbleiben. Anmerkung!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!: Lesen Sie mal in Kapitel 3 diese Passage!! --------------------- Fehler, die nicht mittels der in der APERAK zur Verfügung gestellten Codes übermittelt werden können, sind über einen anderen Weg als per APERAK zu kommunizieren. Ein Beispiel für derartige Fehler wäre die Wiederholung des Segments SG5 LOC „Bilanzkreis“ in der Anmeldung auf Netznutzung in der Sparte Strom. -------------------- Dies widerspricht eigentlich der Definition aus der AHB Prüfung. Hier müssten wir ev. noch mal ran. -------------Holger Weickenmeier-------------05.06.2018 15:06 Nein Nein
APERAK / CONTRL AHB 2.3d Abgeschlossen Muss der Empfänger einer Nachricht die Zuordnungsprüfung verzögern, um eine Zuordnungsfehlermeldung zu vermeiden? Der Sender ist für einen ausreichenden Abstand, zwischen aufeinander aufbauenden Nachrichten, verantwortlich 17.05.2018 2018-00030 Ein Lieferant sendet eine APERAK auf eine Abmeldungsanfrage. Die Bestätigung der Netzutzung wurde kurze Zeit vor der Abmeldungsanfrage übertragen. Der Lieferant bezieht sich auf das AHB APERAK/CONTRL 3.1.3.3. Dort wird jedoch lediglich empfohlen einen ausreichenden Abstand einzuhalten. Ist diese Empfehlung bindend und was ist aus Ihrer Sicht ausreichend. Da der Lieferant 3 Werktage zur Beantwortung der Abmeldungsanfrage hat, ist ein unverzüglicher Versand der APERAK auch nicht korrekt. 2018-05-17 11:34:12 Sehr geehrter Marktpartner, in Ihrer Frage verweisen Sie auf die hierfür relevante Passage des CONTRL/APERAK AHB: „Damit nur berechtigte Zuordnungsfehler gemeldet werden, sind alle Marktpartner verpflichtet, eine zeitnahe Pflege (Aufbau, Aktualisierung etc.) der Objekte in ihrem IT-System durchzuführen und eingehende Geschäftsvorfälle unmittelbar so abzulegen, dass diesen die neu eintreffenden Geschäftsvorfälle zugeordnet werden können. Zur Vermeidung von unnötigen aber berechtigten Zuordnungsfehlermeldungen wird insbesondere dem Absender von Geschäftsvorfällen, die sich auf einen anderen von ihm versandten Geschäftsvorfall beziehen, empfohlen, einen ausreichenden zeitlichen Abstand zwischen beiden Versendevorgängen einzuhalten.“ Wir wollen hier aber nicht diskutieren, wer was wann hätte tun müssen. Die APERAK dient in ihrer derzeitigen Ausprägung im deutschen Energiemarkt in erster Linie dazu, aufzuzeigen, dass ein Problem aufgetreten ist. Würden immer alle Absender alles richtigmachen, müsste nie eine APERAK versendet werden. Da das nicht der Fall ist, kann im Umkehrschluss auch nicht der Anspruch erhoben werden, dass die APERAK-Versender immer alles richtigmachen. Somit greift auch hier die unverrückbare Regel: Derjenige, der eine APERAK bekommen hat, hat diese ernst zu nehmen. Er muss sich darum kümmern, das mittels APERAK gemeldete Problem zu lösen. Wenn er Glück hat, ist der Geschäftsvorfall, auf die sich die APERAK bezieht richtig gewesen und der APERAK-Sender muss etwas korrigieren, wenn er Pech hat, muss er selbst etwas korrigieren. Auf ihre Frage bezogen: Diese APERAK macht deutlich, dass etwas im Umfeld der Abmeldeanfrage nicht passt. Auch zeigt sie an, dass der Zustand eingetreten ist, als wäre die Abmeldeanfrage nie beim Empfänger angekommen, d. h. als hätten Sie diese Abmeldeanfrage nie versandt. Sie müssen sich deshalb mit den LF in Verbindung setzten, denn wenn sie das nicht tun, würden sie gegen die Vorgaben der GPKE bzw. GeLi Gas verstoßen, denn sie haben eine Abmeldeanfrage an den LF zu senden. Erst wenn geklärt ist, warum die Abmeldeanfrage nicht verarbeitet werden könnte, und zwar deutlich bevor die Frist zur Antwort auf eine Abmeldeanfrage abgelaufen ist, kann die Bearbeitung des Prozesses fortgeführt werden, der dazu führte, dass sie die Abmeldeanfrage an den LF gesendet haben. Mit freundlichen Grüßen Ihr BDEW Forum Datenformate Ja Klaus Keller Stefan Seidel Stefan Seidel Jörg Gruchenberg 3.1.3.3 Zur Vermeidung von unnötigen aber berechtigten Zuordnungsfehlermeldungen wird insbesondere dem Absender von Geschäftsvorfällen, die sich auf einen anderen von ihm versandten Geschäftsvorfall beziehen, empfohlen, einen ausreichenden zeitlichen Abstand zwischen beiden Versendevorgängen einzuhalten. Nein Nach Abstimmung mit Herrn Seidel habe ich die Frage beantwortet. -------------Holger Weickenmeier-------------01.06.2018 11:37 Hallo, diese Frage kommt vom Einreicher aus einem Disput mit uns. 8EnBW / YellO) Antwort auf Anmeldung kam vier Sekunden vor der Abmeldeanfrage. Info: Es ist Umsetzungsfrage auf dem Weg, welche auch aussagt, dass Abstand zu halten ist. Ich habe mal einen Vorschlag erstellt. -------------Holger Weickenmeier-------------17.05.2018 12:32 Nein Nein
APERAK / CONTRL AHB 2.3d Abgeschlossen Ablehnung gebündelter Allokationen per APERAK 24.04.2018 2018-00015 Sehr geehrtes Forum, wir erhalten als NB von einem MGV die folgende APERAK (Ausschnitt) zur Ablehnung einer gesamten, gebündelten Allokationsnachricht aufgrund der Ungültigkeit eines einzelnen Bilanzkreises, bzw. Subbilanzkreises: ERC+Z26' FTX+ABO+++(ABCD123456270000,1234567000000,14G):201801140500201801150500?:719' RFF+ACW:ALOCAT1234514' RFF+AGO:ALOCAT1234514-AL1234904E1' FTX+AAO+++Der Zeitreihentyp ?'RLMMT?'ist im Zeitraum ?'2018-01-14T06?:00?:00?+01?:00 - 2018-01-15T06?:00?:00?+01?:00?'nicht (vollständig) deklariert für das Netz ?'1234567000000?'an dem Bilanzierungsobjekt ?'ABCD123456270000?'. Zeitreihentyp gefunden für?: ?'[]?'' Ist es korrekt, die gesamte Datei abzulehnen oder müsste der MGV in diesem Falle nicht die korrekten BK/SBK in seinem System verarbeiten? Freundliche Grüße, Klaus Keller 2018-04-24 11:43:51 Hallo Herr Keller, der vom APERAK-Versender genutzte Grund Z26 ist laut APERAK-AHB zur Angabe von Zuordnungsfehlern anzuwenden. "Z26" = "Absender ist zum angegebenen Zeitintervall dem Zuordnugstupel nicht zugeordnet" Die weiteren Vorgaben zur Angabe des Zuordnungstupels im FTX+ABO sind ebenfalls erfüllt, vgl. hierzu Kapitel 3.1.3.1 Zuordnung zu einem Objekt und gegebenenfalls zu Unterobjekten aus dem APERAK AHB, in dem steht: <…> in den Folgeprozessen für die Zuordnung von Geschäftsvorfällen zu Objekten relevant, wobei bei gescheiterter     Zuordnung die Fehlercodes Z24, Z25 und Z26 genutzt werden: <…> 3-Tupel der Allokationsmeldung gemäß GABi Gas: (Bilanzkreis, Netzbetreiber, Zeitreihentyp) Somit ist die Nichtverarbeitbarkeit der betroffenen Position der ursprünglichen ALOCAT eindeutig gegeben und es steht einer Verarbeitung der weiteren, fehlerfreien Positionen der ALOCAT nichts im Wege. Freundliche Grüße, Ihr Forum Datenformate Ja Klaus Keller Stefan Seidel Klaus Keller Klaus Keller Nein -------------Klaus Keller-------------24.4.2018 12:48 Antwortvorschlag an Herrn Seidel zur Prüfung geschickt Nein Nein
APERAK / CONTRL AHB 2.3d Abgeschlossen Wie ist bei mehrfach versandten Energiemengen und Zählerständen zu verfahren? Keine Ablehnung doppelter MSCONS per APERAK 18.04.2018 2018-00009 Sehr geehrte Damen und Herren, wir haben Energiemengen MSCONS mehrfach versendet, an dem Inhalt hat sich nichts verändert, also gleichbleibende Menge/Zeitraum. Bei dem Versand von Zählerständen ist es ebenfalls so, dass diese oft mehrfach versendet werden. Dürfen unsere MSCONS Nachrichten per APERAK abgelehnt werden? Bzw. kann der mehrmalige Versand der gleichen Energiemengen als Grund zur Ablehnung von Rechnungen genutzt werden? Freundliche Grüße, Jessica Sennert 2018-04-18 14:29:56 Hallo Frau Sennert, derzeit ist kein Ablehnungsgrund in der APERAK für den Empfang von doppelten MSCONS-Nachrichten verfügbar. Eine Störung beim Rechnungsempfänger bei der Verarbeitung von Netznutzungsrechnungen aufgrund des mehrfachen Versands der MSCONS können wir nicht ausschließen, weshalb wir empfehlen die MSCONS nicht mehrfach zu versenden (da Mehrfachversendungen auch prozessual nicht vorgesehen sind). Ein gültiger Ablehnungsgrund mittels Nichtzahlungsavise per REMADV ist jedoch ebenfalls nicht vorhanden. Falls nötig, empfehlen wir eine bilaterale Klärung der Fehlersituation. Viele Grüße, Ihr Forum Datenformate Ja Klaus Keller Stefan Seidel Klaus Keller Jessica Sennert Nein -------------Klaus Keller-------------19.4.2018 11:25 Antwortvorschlag an Hr. Seidel geschickt zur Prüfung -------------Stefan Seidel-------------10.07.2018 23:29 nachgearbeitet -------------Klaus Keller-------------16.07.2018 13:58 nachgearbeitet & veröffentlicht Nein Nein
APERAK / CONTRL AHB 2.3d Abgeschlossen Darf eine UTILMD-Datei abgelehnt werden, wenn die Vorgaben zur Befüllung der DE3042 für ein Postfach nicht eingehalten wurden? Fehlerhafte Angabe von Postfachadresse 18.04.2018 2018-00006 Sehr geehrte Damen und Herren, darf eine UTILMD Nachricht, bei der eine Postfachadresse nicht korrekt befüllt ist mit einer negativen CONTRL abgelehnt werden? Beispiel: C059 1. DE3042 = „Postfach“ 2. DE3042 = leer 3. DE3042 = Nummer des Postfaches Die Nummer des Postfachs befindet sich abweichend im dritten DE3042. Unserer Meinung nach, ist die Nachricht trotzdem syntaktisch ok und rechtfertigt nicht die Ablehnung der gesamten Nachricht mit negativer CONTRL. 2018-04-18 06:32:22 Sehr geehrter Marktpartner, wenn bspw. NAD+Z04 (Korrespondenzanschrift des Endverbrauchers/Kunden) gefüllt wird, ist laut MIG die Datenelementgruppe C059 mindestens mit dem ersten DE 3042 zu befüllen. Darüber hinaus wird dort der Hinweis auf weiterführende Informationen zur Datenelementgruppe C059 in den Allgemeinen Festlegungen gegeben. Unter Kapitel 1.17 ist dort zu lesen: "Bei Angabe des Postfaches DE3042 = „Postfach“ DE3042 = Nummer des Postfaches " Diese Vorgabe ist offensichtlich im von Ihnen skizzierten Fall nicht erfüllt worden. Daher empfehlen wir eine Korrektur des Fehlers auch wenn die Vorgaben der MIG nicht verletzt wurden und somit eine Syntaxfehlermeldung zur Anzeige des Fehlers nicht zulässig ist. Freundliche Grüße, Ihr Forum Datenformate Ja Klaus Keller Stefan Seidel Klaus Keller Jessica Riekhoff Nein -------------Klaus Keller-------------19.4.2018 11:1 Frage gemäß Sitzungsergebnis aus edi@energy beantwortet -------------Stefan Seidel-------------19.4.2018 21:11 Kurzfrage ergänzt Nein Nein
UTILMD AHB Einspeiser 2.0f Abgeschlossen Müssen Tranchen eine MeLo-ID zugeordent werden? Eine direkte Zuordnung Tranche - Messlokation ist nicht vorgesehen 28.05.2018 2018-00041 Sehr geehrte Damen und Herren, Der Meldpunkttyp Tranche (Z70) ist laut AHB die Tranche einer Marktlokation. In unseren Systemen wird diese Tranche mit einer 11-Stelligen MaLo vergeben und von Marktpartnern akzeptiert. Über einen Softwareanbieter haben wir erfahren, dass eine Tranche (Z70) auch einen "MeteringCode" (also analog einer MeLo) haben kann. Ist dies wirklich der Fall oder sind Tranchen immer mit einer offiziellen MaLo-Nummer zu vergeben? 2018-05-28 17:16:30 Sehr geehrter Marktpartner, Eine Tranche ist ein Teil einer erzeugenden Marktlokation.Wie Sie schon korrekt schreiben, ist der Tanche eine MaLo-ID zuzuordnen, da sich die Tranche ähnlich wie eine Marktlokation verhält. Jede Tranche ist genau mit einer Marktlokation mit eigner MaLo-ID verknüpft.Messlokationen werden nicht direkt einer Tranche zugeordnet. Messlokationen werden immer der Marktlokation zugeordnet. Weitere Informationen zu MaLo und MeLo finden Sie auch im BDEW Rollenmodell. Einen direkten Bezug zur Tranche kann eine Messlokation demzufolge nicht haben. Viele Grüße Ihr Forum Datenformate   Ja Thomas Seipt Jessica Riekhoff Thomas Seipt Jörg Gruchenberg Nein Ich habe mal einen Vorschlag erstellt, der ev. etwas präziser ist. Der Vorschlag von Thomas ist nicht falsch, habe aber bedenken, dass wir nicht richtig verstanden werden. Wenn man auf der Ebene Fragen stellt.... -------------Holger Weickenmeier-------------01.06.2018 12:25 Nein Nein