Prozess XX_IN_NB_LF - Elektronischer Rechnungsdatenaustausch Netzbetreiber-Lieferant

5 Versionen Ansichtszeitpunkt (TT.MM.JJJJ)  

Prozess XX_IN_NB_LF (01.10) am 25.03.2023

  
Stammdaten
ProzessXX_IN_NB_LF 
Version01.10 
MutterprozessXX_IN_NB_LF (01.09) 
Aus KonsultationJa 
BezeichnungElektronischer Rechnungsdatenaustausch Netzbetreiber-Lieferant 
BearbeitungsstatusFinal 
Gültig von02.10.2023 
Gültig bis31.12.2099 
StatusAktiv, zukünftig 
GranularitätZählpunkt 
StornierbarJa 
KategorieElektronische Rechnung 
ResponsekategorieKeine 
SpartenStrom
Erdgas
 
BeteiligteVerteilernetzbetreiber
Lieferant
 
  
  

Prozess Grundlagen

  
GrundlagenSonstige Marktregeln Kap. 5 
  
  

Prozessdiagramm

  
ProzessdiagrammKeine Diagramm zugewiesen 
  
  

Beschreibung der Prozessschritte

  
Reihenfolge ProzessschrittNameBedingung/BeschreibungMessageCodeDeadline
Keine Einträge vorhanden.
  
  

Verwendete Marktnachrichten

  
ReihenfolgeKürzelProzessschrittMessageCodeBezeichnung
1-VERSENDEN_REVersenden der Rechnung
  
  

Responsecodes der Marktnachrichten

  
VERSENDEN_RE - Versenden der Rechnung
CodeBezeichnungResponse Kategorie
Keine Einträge vorhanden.

  
  

Dokumente und Links – Teil der Konsultation

  
  
  

Ergänzende Dokumente und Links - nicht Teil der Konsultation

  
  
  
  

Ergänzende Informationen

  

Beschreibung

  

Dieser Prozess dient dem elektronischen Rechnungsdatenaustausch zwischen Netzbetreiber und Lieferanten in der Versorgungsindustrie für die Sparten Strom und Gas im Falle der Rechnungslegung an den Lieferanten. Die Übertragung der Rechnungsdaten hat für beide Energierichtungen zu erfolgen, also sowohl Verbrauchs- als auch Erzeugungsrechnungen mit Rechnung an Lieferanten müssen in dieser Form übermittelt werden. Das Schema ebutilities-Invoice 03.10 muss verwendet werden. Ergänzend zu den gesetzlichen Regelungen sowie den Schema-Vorgaben gelten folgende Regelungen:


Encoding
Bei der Erstellung der XML Daten ist das UTF-8 Encoding zu verwenden.


Rechnungslegung
Alle Rechnungen zur Netznutzung müssen in elektronischer Form übermittelt werden. D.h., neben der Verbrauchsabrechnung müssen auch Teilbetrags- und Stornorechnungen elektronisch gesendet werden.

Bei Teilbetragsrechnungen darf beim Element „PaymentPosition“ nur der Qualifier „TZBA“ übermittelt werden. Die Elemente „ConsumptionItem“ und „IndividualItem“ sowie andere „PaymentPosition“ dürfen nicht befüllt sein.


Die „MeteringPointInfo“ muss generell befüllt sein.


In der Beziehung Netzbetreiber-Lieferant ist der „LegalInvoiceType“ NSIG (ohne Signatur der E-Rechnung) bzw. DSIG (mit Signatur der E-Rechnung) anzuwenden. Es darf zusätzlich keine Papierrechnung versendet werden. 

Das Element "IndividualItem" ist in der Beziehung Netzbetreiber - Lieferant generell nicht mehr zulässig. Rechnungen, die in dieser Form gelegt werden, können mit dem ResponseCode 812 (unzulässige Zusatzpositionen) des Prozesses BI_REJ abgelehnt werden.

Das Feld "DocumentCreationDateTime" darf nicht kleiner als das InvoiceDate sein.


Submessungen
Die „BillingQuantity“ der Energiemenge für die Gesamtmessungs-„MeteringPosition“ wird positiv dargestellt. Die „BillingQuantity“ für die Submessungs-“MeteringPosition“ ist negativ darzustellen – beide überlagert (summiert) müssen mit der resultierenden „BillingQuantity“ in den „ConsumptionBillingPosition“ übereinstimmen.

Der Zählpunkt der Submessung darf in den „MeteringPointInfo“ nicht angeführt sein.

Empfehlung: Um in den „MeteringPosition“ die Submessung anhand der Gerätenummer erkennen zu können, sollte die „DeviceNumber“ mit „SUB“ beginnen.

Darstellung zeitabhängiger Preise
Das Element "TimeDefinition" ist im Bereich der ConsumptionBillingPosition immer dann zu verwenden, wenn die Maßeinheit des Einheitspreises (PricePerItem) einen expliziten Zeitanteil enthält (z.B. €/Monat, €/Jahr, €/Tag oder eben insbesondere für die Leistung: €/(kW/Jahr), bzw. €/(kWh/h/Jahr),…)

  • Im Falle rein zeitabhängiger Preise ist als Definition „1 PCE“ für BillingQuantity und BillingUOM zu verwenden (PCE wird hier generell als physikalisch neutrale Einheit gewertet)

  • generell muss immer gelten: NetAmount ~= BillingQuantitiy * TimeDefintion-Faktor * PricePerItem Eine allenfalls geringe Differenz zwischen NetAmount und der vollständigen Produktkette der möglichen 2 - 3 Faktoren ist auch hier wiederum ausschließlich über Rundungsabweichungen begründbar.


Produktkatalog
Für die Sparte Strom ist der beiliegende Produktkatalog und der „ProductCodeType“ „VEO“ verpflichtend zu verwenden.

Für die Sparte Gas ist der beiliegende Produktkatalog und der „ProductCodeType“ „FGW“ verpflichtend zu verwenden.


Produktnummern
Die „ProductID“ für die Produktkennzeichnung ist als 4stelliger alphanumerischer Wert (Zeichenkette und keine Zahl!) definiert. „Führende“ Nullen sind daher immer darzustellen. Beispielsweise ist die Produktnummer „1“ nicht definiert und somit ungültig. Die Produktnummer „1“ ist nicht äquivalent zu „0001“ zu sehen.

Produktnummernzuordnung
Alle Produktnummern sind in der Beziehung Netzbetreiber - Lieferant in den  „ConsumptionBillingPosition“  abzubilden.

Doppeltarife (Sparte Strom)
Für Doppeltarife muss die Produktnummer so gesendet werden, dass die Tarife aus der Produktnummer zu erkennen sind. An der 3. Stelle der Produktnummer muss für NT die Ziffer 7 und für HT die Ziffer 8 verwendet werden.

OBIS Kennziffer
Der „MeterCodeType“ OBIS muss für alle „MeteringPosition“ übermittelt werden. Die OBIS Kennziffern werden in Anlehnung an die die aktuell gültigen Grundlagen „Zählwerte und standardisierte Lastprofile“ (Sparte Strom) bzw. "Datenformate für Zählwerte" (Sparte Gas) abgebildet. Im Segment AA (Messart) wird für Zählerstände der Wert „8“ übermittelt.

Zusatzinformationen

Sparte Strom:
Das Element „AddInformationCode“ ist mit folgenden Informationen zu befüllen:

  • SBR für das erworbene Strombezugsrecht
  • SEB für die Einheit dieses Bezugsrechtes
  • SSP für das Synthetische Lastprofil (optional)
Für die Angaben des Strombezugsrechtes sind Dezimalzahlen mit Dezimalstellen (ohne Trennzeichen und Einheit) vorgesehen.

Sparte Gas:
Das Element „AddInformationCode“ ist mit folgenden Informationen zu befüllen:
  • GMIN für die Mindestleistung
  • GMAX für die vertraglich vereinbarte Höchstleistung
  • GHOE für die vom Netzbetreiber der Rechnung zugrunde gelegte Höhe
  • GTMP für die Temperatur
  • GSP für das Synthetische Lastprofil (optional)

Für die Angaben der Leistung sind Dezimalzahlen mit Dezimalstellen in kWh/h (ohne Trennzeichen und Einheit) vorgesehen.

Für die Temperatur gelten nur 2stellige ganzzahlige Werte (z.B. „06“ für „Messung außen“, „15“ für „Messung innen“ sowie „TK“ für temperaturkompensierte Messgeräte. Für die Angaben der Höhe sind nur ganze Zahlen (ohne Trennzeichen und Einheit) vorgesehen.


Typ der Kundeninformation
Für das Attribut „CustomerInfoTyp“ gelten für die Sparte Strom folgende Werte: 

  • Allgemein
  • ElWOG_Info_Netzbetreiber
  • ElWOG_Ablesung
Für das Attribut „CustomerInfoTyp“ gelten für die Sparte Gas folgende Werte: 
  • Allgemein
  • GWG_Info_Netzbetreiber
  • GWG_Ablesung 

Die Übermittlung von „ElWOG_Info_Netzbetreiber“ für die Sparte Strom bzw. „GWG_Info_Netzbetreiber“ ist verpflichtend. Um eine übersichtliche Rechnungslegung auf Lieferantenseite zu gewährleisten, dürfen 20 Blöcke nicht überschritten werden. Eine Übermittlung der einzelnen Blöcke ist nicht erforderlich. Der Verweis auf die entsprechende ID im Marktpartnerverzeichnis ist ausreichend. Die Netzbetreiber sind verpflichtet diese Information im Marktpartnerverzeichnis zu hinterlegen.

Typ des Kundenkontaktes
Für das Attribut gelten die Werte: 

  • Allgemein
  • Kundenservice
  • Beschwerdemanagement
  • Stoerung 

„Stoerung“ ist jedenfalls zu übermitteln.

Typ der Umwandlung (nur Sparte Gas)
Im Element „ConversionIndication“ muss das Attribut „ConversionType“ sowohl für den Verrechnungsbrennwert (GBW...Gas Brennwert) zur Umrechnung von Normkubikmeter in kWh als auch für die Zustandszahl (GZZ... Gas Zustandszahl) zur Umrechnung von Betriebskubikmeter in Normkubikmeter übermittelt werden. Der Brennwert wird grundsätzlich von einem Zählerstand zum anderen Zählerstand in der Abrechnung dargestellt. Dadurch ist nicht unbedingt der monatliche Brennwert sondern ein gewichteter Durchschnitt des Brennwerts in den Verbrauchspositionen ersichtlich.


Die Übermittlung der Faktoren dient der Information sowie der Darstellung auf der Lieferantenrechnung. Es soll jedoch keine separate Ermittlung der kWh-Menge durch den Versorger durchgeführt werden.


Zugrundeliegende Menge für Teilzahlungsbetrag

Im Falle eines Teilzahlungsbetrags muss das Element "PaymentPlanSource" verpflichtend übermittelt werden, im Falle einer Rechnung ist dieses Element optional:

Variante 1 - TZB Berechnung auf Grund vorherigem Verbrauch:

DateFrom ... Ab-Datum des zugrundeliegenden Verbrauchs

DateTo ... Bis-Datum des zugrundeliegenden Verbrauchs

Quantity ... zugrundeliegender Verbrauch für die Berechnung des TZB

TotalGrossAmount ... Teilzahlungsbetrag brutto

Count ... Anzahl der vorgeschriebenen TZBs bis zur nächsten Turnusabrechnung

Variante 2 - fixe TZB-Höhe (z.B. auf Grund von Vereinbarung mit dem Kunden):

Manually TRUE

TotalGrossAmount ... Teilzahlungsbetrag brutto

Count ... Anzahl der vorgeschriebenen TZBs bis zur nächsten Turnusabrechnung



PaymentPositions
In der elektronsichen Rechnung des Netzbetreibers an den Lieferanten dürfen die PaymentPositions SOFG (z.B. für die Information von weiteren offenen Rechnungen) und AKON nicht übermittelt werden. Rechnungen, die in dieser Form gelegt werden, können mit dem ResponseCode 812 (unzulässige Zusatzpositionen) des Prozesses BI_REJ abgelehnt werden.


Zählpunktscharfe Kommunikation

In der Beziehung Netzbetreiber-Lieferant darf ein Beleg ausschließlich einem Zählpunkt zugeordnet sein. Dem Lieferanten ist es weiterhin vorbehalten gewisse Zählpunkte für den Kunden zu bündeln. In begründeten Ausnahmefällen ist es nach bilateraler Abstimmung zwischen Netzbetreiber und Lieferant möglich mehrere Zählpunkte in einer Rechnung für Sonderkonstellationen zu übermitteln.


Eine Belegart je Rechnung

In der Beziehung Netzbetreiber-Lieferant darf ausschließlich eine Belegart einer elektronischen Rechnung zugeordnet sein. Ein gemeinsamer Versand von Rechnung und Teilzahlungsbetrag ist beispielsweise nicht möglich. Rechnungen, die in dieser Form gelegt werden, können mit dem ResponseCode 812 (unzulässige Zusatzpositionen) des Prozesses BI_REJ abgelehnt werden.


Anpassungsstorno

Die Erstellung eines Anpassungsstornos ist in der Beziehung Netzbetreiber-Lieferant nicht zulässig. Es muss ein Storno inkl. erneuter Ausstellung der korrigierten Rechnung durchgeführt werden. Sollte ein Anpassungsstorno überittelt werden, kann dieser mit dem ResponseCode 809 (Storno fehlt) des Prozesses BI_REJ abgelehnt werden.


Angeforderte Teilzahlungen

Jeder Teilzahlungsbetrag muss als DocumentType 386 vorgeschrieben und damit konkret angefordert werden. Im Gegenzug ist jeder Teilzahlungsbetrag über XML-Belege wieder zu neutralisieren (spätestens erfolgt die komplette Auflösung bei Beendigung des Lebenszyklus der Lieferantenbeziehung für einen Zählpunkt).

Dies erfolgt entweder im Rahmen der regulären Abrechnung (DocumentType 82) in Form von TZBG oder über eine explizite Stornierung (DocumentType 83).

Um die Trennung der Belegsicht von der Zahlungssicht nochmals zu verdeutlichen, steht TZBG zukünftig für "Teilzahlungen gefordert" und nicht "Teilzahlungen geleistet".


Leistungszeitraum

Der Leistungszeitraum des Teilzahlungsbetrag muss dem Verbrauchszeitraum entsprechen, den er auch betraglich abbildet. Das heißt es darf keine zeitliche Überlappung geben bzw. darf pro Leistungszeitraum nur ein TZB übermittelt werden.

Nach einer ABM oder einem Abgang über WIES darf kein Teilzahlungsbetrag für den betroffenen Zählpunkt mehr übermittelt werden. Sollte dies doch der Fall sein, kann eine Ablehnung mit dem ResponseCode 801 (Verbrauchszeitraum fehlerhaft) des Prozesses BI_REJ durchgeführt werden.


Konsistenz der verrechneten Menge

Die verrechneten Mengen müssen sich auch in den über das Format ConsumptionRecord übermittelten Mengen widerspiegeln, kleinere Rundungsdifferenzen sind zulässig.

Vorhandene Verbrauchsdaten (z.B. Smart Meter-Zeitreihen bzw. NonSmart-Zwischenablesungen) müssen für Abgrenzungen (z.B. Netzpreisänderungen) verwendet werden.

Eine Überleitung von den Ablesedaten hin zu den verrechneten Mengen muss auf der XML-Rechnung stimmig dargestellt werden. Gesetzliche Anforderungen hinsichtlich der Darstellung des Zählerstandes können damit - zumindest in Summe - erfüllt werden. Um die Nachvollziehbarkeit zu erreichen sind zwingend Produktcodes für beispielsweise folgende Konstellationen zu verwenden:

- Code für das Delta zwischen physikalischem Netzbezug und verrechnet Restmenge bei gemeinschaftlichen Erzeugungsanlagen

- Codes für redzuzierte Netzpreise bei Energiegemeinschaften

- Code für die Darstellung von Einspeisemengen

Die entsprechenden Produktcodes für diese Konstellationen sind entsprechend des Produktkatalogs anzuwenden.

Eine Rechnung (DocumentType 82) ohne ConsumptionBillingPosition ist nicht zulässig.


Konsistenz der Umwandlungen

Die angeführten Faktoren müssen bei einer vollständigen Kettenmultiplikation von der MeteringQuantity zur BillingQuantity führen. Es dürfen keine redundanten Faktoren angeführt werden.

Eine minimale Abweichung des Ergebnisses ist nur auf Grund der angewendeten Rundungsregeln denkbar und darf keinen substanziellen Widerspruch darstellen.


Darstellung von Prozenten

Für die Darstellung von Prozenten wurde das neue Feld "PriceUOM" in den "ConsumptionBillingPositions" bzw. "IndividualBillingPositions" eingeführt. Damit kann ein Prozentzuschlag oder -rabatt dargestellt werden. Ein entsprechendes Beispiel ist in der Schemadoku ersichtlich.

Übertragung

  

Für die Abwicklung des Datenaustausch stehen drei Möglichkeiten zur Verfügung:

  1. Prozessumsetzung in der eigenen IT-Landschaft: EDA Messenger oder EDA e-mail. Für weitere Infos kontaktieren Sie bitte eda@ebutilities.at.
  2. Nutzung eines IT Dienstleister (SaaS): EDA Messenger, welcher durch den IT Dienstleister betrieben wird. Für weitere Infos kontaktieren Sie bitte Ihren IT Dienstleister
  3. SelfStorage-Dienst der Verrechnungsstellen für Lieferanten: EDA Messenger, welcher durch die Verrechnungsstellen betrieben wird

Der energiewirtschaftliche Datenaustausch ist grundsätzlich für alle Marktteilnehmer (ausgenommen Verteilernetzbetreiber) kostenlos.

Fristen

  

Fristen entsprechend der gesetzlichen Vorgaben zur Rechnungslegung

Prozessauslösend

  

Verpflichtende XML Knoten

  

siehe Schemadokumentation und Beschreibung

Voraussetzungen

  

Aufrechte Rahmenvereinbarung über die umsatzsteuerliche Behandlung von Leistungen aus Netzzugangsverträgen insbesondere über die Anwendung des in Rz 1536 der USt.-Richtlinien 2000 angeführten Vorleistungsmodells

Aufrechter Liefervertrag im Abrechnungszeitraum

Änderungen

  

Änderungen gegenüber der Version 01.00:

- PaymentPositions SOFG und AKON sind nicht mehr zulässig

- die Kommunikation der XML-Rechnung erfolgt ausschließlich zählpunktsscharf

- in einer Rechnung darf nur mehr eine Belegart übermittelt werden

- ein Anpassungsstorno ist nicht mehr zulässig

- TZBG stellen die Belegsicht und nicht die Zahlungssicht dar

- Klarstellung Leistungszeitraum von TZBs

- durchgehende Konsistenz der verrechneten Menge

- durchgehende Konsistenz der Umwandlungen

- Klarstellungen und Ausformulierungen bei zeitabhängigen Preisen

- Schemaänderung: zukünftig sind statt 6 Nachkommastellen 12 Nachkommastellen im Schema beim PricePerItem zulässig. Diese Maximalanzahl wurde gewählt um für allfällige zukünftige Anforderungen gewappnet zu sein - aus jetziger Sicht ist keine Anforderung mit mehr als 7 NK bekannt

- Schemaänderung: neues Feld für Prozentrabatt und Zuschläge

- Ablöse Workaround für TZB-Höhe durch Element

- Ausschließlich ConsumptionBillingPosition sind zulässig

- Wegfall Übermittlung Gas-Umrechnungsfaktor, sondern Zustandszahl und Brennwert


31.1.2023: Klarstellung dass der in der Beschreibung genannte Reklamationsgrund beim Leistungszeitraum mit dem eigenen Prozess BI_REJ rückgemeldet wird und nicht Teil des Rechnungsprozesses sind. 


  
  
  
  

Änderungen verfolgen

  

Änderungen betreffend Prozess 'XX_IN_NB_LF' abonnieren.