Konzept zur Rückmeldung des technischen Prüfergebnisses für XML-Nach-richten - Konsultationsfassung - Bundesnetzagentur
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Konsultationsfassung Konzept zur Rückmeldung des techni- schen Prüfergebnisses für XML-Nach- richten Version: 1.0 Publikationsdatum: 01.08.2022 Autor: BDEW
Konzept zur Rückmeldung des technischen Prüfergebnisses für XML-Nachrichten
Inhaltsverzeichnis
1 Warum veröffentlicht EDI@Energy ein Konzept? ......................................................... 4
2 Einleitung ................................................................................................................... 4
3 Inhalte des Konzepts ................................................................................................... 4
3.1 Abgrenzung .............................................................................................................. 5
3.2 Verantwortlichkeiten und Rahmenbedingungen bei der Kommunikation zwischen
Absender und Empfänger ........................................................................................ 5
3.3 Regelungen bei Fehlern in der Marktkommunikation ............................................. 6
3.4 Auswirkungen einer Syntaxfehlermeldung auf den Geschäftsprozess ................... 7
4 Syntaxprüfung / Empfangsbestätigung ........................................................................ 7
5 Syntaxprüfung ............................................................................................................ 7
5.1 Erläuterungen und Beispiele zur Syntax-Prüfung .................................................... 8
5.1.1 Häufigkeit einer xs:sequence / xsd:sequence (1..1) ................................................ 9
5.1.2 Häufigkeit eines Elements (1..1) .............................................................................. 9
5.1.3 Häufigkeit eines Elements (0..1) .............................................................................. 9
5.1.4 Attribut mit Use „required“ ..................................................................................... 9
5.1.5 Wertevorrat „Anwendbare Codes“ ....................................................................... 10
5.1.6 Wertevorrat „Fixed“............................................................................................... 10
5.1.7 Formatvorgaben „Length“ ..................................................................................... 10
5.1.8 Formatvorgaben „Pattern“ .................................................................................... 11
5.2 Dokumenten-Ebene der einzelnen XML-Nachrichten ........................................... 11
5.2.1 ActivationDocument .............................................................................................. 11
5.2.2 Beschaffungsanforderung energetischer Ausgleich .............................................. 12
5.2.3 Beschaffungsvorbehalt .......................................................................................... 12
5.2.4 Kostenblatt ............................................................................................................. 12
5.2.5 NetworkConstraintDocument ................................................................................ 13
5.2.6 PlannedResourceScheduleDocument .................................................................... 13
5.2.7 Stammdaten ........................................................................................................... 14
Version: 1.0 01.08.2022 Seite 2 von 27Konzept zur Rückmeldung des technischen Prüfergebnisses für XML-Nachrichten
5.2.8 Unavailability_MarketDocument ........................................................................... 14
5.2.9 StatusRequest_MarketDocument ......................................................................... 14
5.3 Übermittlung eines Syntaxfehlers auf Dokumenten-Ebene .................................. 15
5.3.1 Detaillierung des Syntaxfehlers auf Dokumenten-Ebene ...................................... 15
5.3.2 Ortsangabe des Syntaxfehlers auf Dokumenten-Ebene ........................................ 16
5.4 Übermittlung eines Syntaxfehlers auf Dokumenten-Ebene .................................. 16
5.4.1.1 Syntaxfehler im Attribut DtdBDEWNachrichtenVersion ..................................... 17
5.4.1.2 Syntaxfehler im Element SenderIdentification .................................................... 17
5.4.1.3 Syntaxfehler im Attribut v des Element SenderIdentification ............................. 17
5.4.1.4 Syntaxfehler im Attribut codingScheme des Element SenderIdentification ....... 18
5.4.1.5 Syntaxfehler im Attribut codingScheme des Element SenderIdentification (2) .. 18
5.5 Übermittlung eines Syntaxfehlers auf allen weiteren Ebene ................................ 18
5.5.1 Detaillierung des Syntaxfehlers auf allen weiteren Ebenen .................................. 19
5.5.2 Ortsangabe des Syntaxfehlers auf allen weiteren Ebenen .................................... 20
5.6 Übermittlung eines Syntaxfehlers auf allen weiteren Ebenen .............................. 20
5.6.1.1 Syntaxfehler im Attribut v des Element ResourceObject .................................... 23
5.6.1.2 Syntaxfehler im Attribut v des Element Resolution ............................................. 24
5.6.1.3 Syntaxfehler im Attribut v des Element Qty ........................................................ 24
5.6.1.4 Syntaxfehler im Attribut codingScheme des Element SenderIdentification ....... 24
5.6.1.5 Syntaxfehler mit mehreren verschiedenen Fehlern auf unterschiedlichen
Ebenen in einer XML-Nachricht ........................................................................... 25
5.7 Empfangsbestätigung, Syntaxprüfung fehlerfrei ................................................... 26
6 Zeitplan .................................................................................................................... 27
7 Ausblick .................................................................................................................... 27
Version: 1.0 01.08.2022 Seite 3 von 27Konzept zur Rückmeldung des technischen Prüfergebnisses für XML-Nachrichten
1 Warum veröffentlicht EDI@Energy ein Konzept?
Ein Konzept ermöglicht der PG EDI@Energy im Rahmen der Konsultation allen Marktbeteiligten
eine neue Idee zur Weiterentwicklung der EDI@Energy-Dokumente vorzustellen und sich über
diese auszutauschen. In der Konsultationssitzung wird aufgrund der qualifizierten Rückmeldun-
gen aus dem Markt zum Konzept das weitere Vorgehen mit der BNetzA beschlossen.
Hinweis: Es besteht kein Anspruch darauf, zukünftige Änderungen als Konzept dem Markt im
Vorfeld zur Verfügung zu stellen.
2 Einleitung
Dieses Konzept enthält die Übertragung des technischen Prüfergebnisses für XML-Nachrichten
in einer definierten Struktur.
Die definierte Struktur soll den Empfänger des Prüfergebnisses in die Lage versetzen:
technische Fehler in der referenzierten XML-Nachricht zu erkennen,
den Grund des Fehlers nachvollziehen zu können,
die Position des Fehlers in der XML-Nachricht zu identifizieren,
zu erkennen, ob die gesamte XML-Nachricht oder einzelne Vorgänge innerhalb der XML-
Nachricht verarbeitet bzw. nicht verarbeitet werden konnten.
Derzeit besteht bei XML-Nachrichten ausschließlich die Möglichkeit einer Rückmeldung mittels
AcknowledgementDocument, ob eine Nachricht:
vollständig akzeptiert wurde (ReasonCode A01, Message fully accepted), oder
vollständig abgelehnt wurde (ReasonCode A02, Message fully rejected).
Die bisherigen im Markt vorhandenen Lösungen einer individuellen unverbindlichen Rückmel-
dung von technischen Prüfungen sollen durch die Weiterentwicklung standardisiert vorgegeben
werden.
Die Weiterentwicklung der technischen Prüfungen und die strukturierte Rückmeldung schließt
daher diese Lücke in der Marktkommunikation.
3 Inhalte des Konzepts
Das Konzept zur technischen Prüfung und Übertragung des Prüfergebnisses für XML-Nachrich-
ten enthält die verschiedenen Rückmeldungen des Prüfergebnisses auf den verschiedenen Ebe-
nen:
› Dokumenten-Ebene (Dokumentenkopf)
Version: 1.0 01.08.2022 Seite 4 von 27Konzept zur Rückmeldung des technischen Prüfergebnisses für XML-Nachrichten
› darunterliegende Ebenen, wie z.B. TimeSeries, TimeInterval (abhängig vom Nachrichtenfo-
ramt)
Ebenfalls enthalten sind die notwendigen Aktivitäten des Absenders und/oder Empfängers im
Rahmen des Prüfprozesses.
3.1 Abgrenzung
Es wird nicht auf die rechtlichen Konsequenzen eingegangen, die aufgrund von im Rahmen der
Marktkommunikation begangener Fehler von Markteilnehmern zu tragen sind (z. B. ob sich aus
einem nicht fristgerecht erfolgten Datenaustausch Schadensersatzansprüche ableiten lassen).
3.2 Verantwortlichkeiten und Rahmenbedingungen bei der Kommunikation zwischen Absen-
der und Empfänger
Im folgenden Konzept wird von den Parteien immer eine Funktion, entweder als Absender oder
Empfänger wahrgenommen. Dies gilt auch für eine Zwischeninstanz, z.B. die Marktrolle Data-
Provider, auch diese agiert ausnahmslos entweder in der Funktion Absender oder Empfänger,
sodass für diese Marktrolle dieselben Vorgaben gelten. Die Parteien müssen in der Lage sein,
sowohl als Absender als auch als Empfänger die nachfolgend beschriebenen Verantwortungen
zu übernehmen:
› Der Absender ist verantwortlich für eine plausible, inhaltlich und syntaktisch richtige, sowie
vollständig gefüllte XML-Nachricht für den jeweiligen Geschäftsprozess. Tritt ein Fehler auf,
ist er für die Identifizierung der Fehlerursache sowie für deren Beseitigung in seinem Zustän-
digkeitsbereich im Rahmen des Clearings verantwortlich.
› Enthalten vom Absender erstellte XML-Nachrichten dennoch Fehler, die ihm per Syntax-
oder Verarbeitbarkeitsfehlermeldung gemeldet werden, so hat er ohne schuldhaftes Verzö-
gern dafür Sorge zu tragen, die gemeldeten Fehler schnellstmöglich zu bereinigen, sowie die
Ursachen, die zur Fehlermeldung führten, zu erforschen und abzustellen. Des Weiteren hat
der ursprüngliche Absender eine, um den Fehler bereinigte XML-Nachricht, zu übermitteln,
da er weiterhin verpflichtet bleibt die gültigen Prozess- und Rückmeldefristen gegenüber al-
len anderen Beteiligten einzuhalten.
› Enthält die XML-Nachricht fehlerfreie und fehlerhafte Geschäftsvorfälle, so kann der Absen-
der diese für das erneute Versenden auch auf zwei XML-Nachrichten aufteilen, um auf diese
Weise die fehlerfreien Geschäftsvorfälle unverzüglich übermitteln zu können. Hierbei ist zu
beachten, dass bei Syntaxfehlern alle in der XML-Nachricht enthaltenen Geschäftsvorfälle
vom Empfänger nicht verarbeitet wurden, aber durch Verarbeitbarkeitsfehlermeldungen
nur die als fehlerhaft gemeldeten Geschäftsvorfälle einer XML-Nachricht nicht verarbeitet
werden.
› Der Empfänger ist dafür verantwortlich, empfangene XML-Nachrichten rechtzeitig zu prüfen
und den Absender über das Ergebnis der Prüfungen unverzüglich zu informieren.
Version: 1.0 01.08.2022 Seite 5 von 27Konzept zur Rückmeldung des technischen Prüfergebnisses für XML-Nachrichten
› Nach Erhalt einer Syntaxfehlermeldung hat der Absender der XML-Nachricht davon auszu-
gehen, dass die darin enthaltenen Geschäftsvorfälle beim Empfänger der XML-Nachricht
nicht weiterverarbeitet wurden. Der Absender der XML-Nachricht hat ggf. einen Klärungs-
prozess anzustoßen, falls er weitere Informationen vom Empfänger der XML-Nachricht be-
nötigt, um seinen Fehler beheben zu können. Falls er den/die gemeldeten Syntaxfehler nicht
akzeptiert, oder wenn er den/die gemeldeten Fehler nicht akzeptiert, ist der Empfänger der
XML-Nachricht außerhalb der XML-Kommunikation zu kontaktieren.
› Nach Erhalt einer Empfangsbestätigung (erfolgreicher Syntaxprüfung) kann der Empfänger
von der ordnungsgemäßen Weiterverarbeitung seiner XML-Nachricht beim Empfänger aus-
gehen.
› Nach Erhalt einer geschäftsvorfallbezogenen Fehlermeldung hat der Absender der XML-
Nachricht davon auszugehen, dass die beanstandeten Geschäftsvorfälle beim Empfänger
der XML-Nachricht nicht weiterverarbeitet wurden. Der Absender der XML-Nachricht hat
einen Klärungsprozess anzustoßen. Falls er weitere Informationen vom Empfänger der XML-
Nachricht benötigt, um seinen Fehler beheben zu können oder wenn er den/die gemeldeten
Fehler nicht akzeptiert, ist der Empfänger der XML-Nachricht außerhalb der XML-Kommuni-
kation zu kontaktieren.
3.3 Regelungen bei Fehlern in der Marktkommunikation
› Der Absender der XML-Nachricht ist für die fristgerechte Übermittlung verantwortlich.
Bleibt eine Empfangsbestätigung durch den Empfänger aus oder weist eine empfangene
Nachricht auf einen Syntaxfehler hin, ist es die Initiativ-Aufgabe des Absenders der XML-
Nachricht, die Ursache der misslungenen Marktkommunikation zu ermitteln.
› Sofern die Ursache für das Misslingen auf Seiten des Empfängers liegt, hat dieser die ur-
sprüngliche XML-Nachricht in die fristgerechte Verarbeitung aufzunehmen, sofern die jewei-
ligen Prozesse dies noch ermöglichen. Die XML-Nachricht des Absenders wird in diesem Fall
als fristgerecht beim Empfänger eingetroffen behandelt.
› Liegt die Ursache für das Misslingen auf Seiten des Absenders und führt eine erneute Sen-
dung mit einer entsprechend korrigierten, neuen XML-Nachricht zum Erfolg, dann gilt für
die in der XML-Nachricht enthaltenen Geschäftsvorfälle die zum erneuten Sendedatum gül-
tigen Bearbeitungs- bzw. Antwortfristen gemäß den jeweiligen Prozessen.
› Erfolgte der Import der XML-Nachricht fehlerfrei, so ist der Empfänger dann verpflichtet, so-
weit der Prozess eine inhaltliche Antwort erfordert, diese mit dem vorgesehenen Antwort-
nachrichtentypen in der vorgesehenen Frist zu übermitteln. Dies gilt ebenso für die Weiter-
leitung von XML-Nachrichten.
Version: 1.0 01.08.2022 Seite 6 von 27Konzept zur Rückmeldung des technischen Prüfergebnisses für XML-Nachrichten
3.4 Auswirkungen einer Syntaxfehlermeldung auf den Geschäftsprozess
In Bezug auf sämtliche sich ergebende rechtliche Folgewirkungen (etwa Fristeinhaltung, Fällig-
keits- oder Verzugseintritt etc.) gilt eine gerechtfertigt abgelehnte XML-Nachricht und somit alle
darin enthaltenen Geschäftsvorfällen, als dem Empfänger nicht zugegangen, sofern es sich um
eine Syntaxfehlermeldung auf Dokumenten-Ebene handelt. Bei einer Ablehnung auf einzelner
Geschäftsvorfälle gilt ein gerechtfertigt abgelehnter Geschäftsvorfall einer XML-Nachricht als
dem Empfänger nicht zugegangen.
4 Syntaxprüfung / Empfangsbestätigung
Im Rahmen der Syntaxprüfung erfolgt eine Kontrolle, ob die XML-Nachricht der vorgeschriebe-
nen EDI@Energy-Vorgaben entspricht. Ist dies der Fall, so ist eine elementare Voraussetzung
erfüllt, um die in der XML-Nachricht enthaltenen Informationen zu konvertieren und in den IT-
Systemen des Empfängers weiter zu verarbeiten.
Wird kein Syntaxfehler gefunden, so wird der Empfang der XML-Nachricht positiv bestätigt.
Falls die XML-Nachricht Syntaxfehler enthält, gelten die nachfolgenden Regeln:
› Enthält eine XML-Nachricht mindestens einen Syntaxfehler, so wird der gesamte Inhalt der
XML-Nachricht abgelehnt.
› Wird ein Syntaxfehler auf Dokumenten-Ebene gefunden, wird danach die Fehlersuche been-
det und der Syntaxfehler an den Absender der XML-Nachricht übermittelt.
› Enthält die XML-Nachricht keinen Syntaxfehler auf Dokumenten-Ebene, so werden alle wei-
teren Ebenen, die in der XML-Nachricht vorhanden sind, geprüft. Alle hierbei gefundenen
Syntaxfehler werden an den Absender der XML-Nachricht übermittelt.
Die Prüfungen der jeweiligen Ebenen werden in den folgenden Kapiteln weiter beschrieben.
Auf eine XML-Nachricht ist vom Empfänger genau eine Nachricht an den Absender der XML-
Nachricht zu senden. In der Nachricht wird entweder:
› eine XML-Nachricht inkl. aller enthaltenen Geschäftsvorfälle vollständig bestätigt, oder
› die gesamte XML-Nachricht vollständig zurückgewiesen wird.
5 Syntaxprüfung
Die Syntaxprüfung prüft ob:
› die xs:sequence/xsd:sequence vorhanden ist, welche in der Spalte „Häufigkeit“ der jeweili-
gen Formatbeschreibung mit „1..x“ (x = natürliche Zahl bis unbegrenzt) und sich diese in der
XML-Nachricht an den richtigen Stellen befinden,
Version: 1.0 01.08.2022 Seite 7 von 27Konzept zur Rückmeldung des technischen Prüfergebnisses für XML-Nachrichten
› die xs:sequence/xsd:sequence nicht öfter vorhanden ist, als in der Spalte „Häufigkeit“ der
jeweiligen Formatbeschreibung angeben ist,
› innerhalb einer xs:sequence/xsd:sequence sofern diese geöffnet wurde, die Elemente vor-
handen sind, die in der jeweiligen Formatbeschreibung in der Spalte „Häufigkeit“ mit 1..x (x
= natürliche Zahl bis unbegrenzt) und sich diese in der XML-Nachricht an den richtigen Stel-
len und Reihenfolge befinden,
› innerhalb einer xs:sequence/xsd:sequence sofern diese geöffnet wurde, die Elemente nicht
öfter vorhanden sind, als in der Spalte „Häufigkeit“ der jeweiligen Formatbeschreibung an-
geben ist,
› innerhalb der Elemente, sofern diese geöffnet wurden die Attribute vorhanden sind, welche
der jeweiligen Formatbeschreibung unter „Use“ mit „required“ gekennzeichnet sind und
sich diese in der XML-Nachricht an den richtigen Stellen befinden,
› die Elemente/Attribute mit einem Wert aus dem definierten Wertevorrat gemäß der jeweili-
gen Formatbeschreibung gefüllt sind (in der Formatbeschreibung unter „Anwendbare
Codes“ beschrieben),
› die Elemente/Attribute mit einem Wert aus dem fixen Wertevorrat gemäß der jeweiligen
Formatbeschreibung gefüllt sind (in der Formatbeschreibung unter „Fixed“ beschrieben),
› die Formatvorgaben (Länge) der Elemente/Attribute gemäß der jeweiligen Formatbeschrei-
bung eingehalten sind (in der Formatbeschreibung unter „Length“ beschrieben),
› das Pattern der Elemente/Attribute gemäß der jeweiligen Formatbeschreibung eingehalten
ist (in der Formatbeschreibung unter „Pattern“ beschrieben).
Die Syntaxprüfung wird zuerst auf Dokumentenebene durchgeführt. Welche Elemente/Attri-
bute zu der Dokumenten-Ebene der einzelnen XML-Nachrichtenformate gehören ist im Kapitel:
5.2 beschrieben. Wird ein Syntaxfehler auf Dokumenten-Ebene gefunden, wird danach die Feh-
lersuche beendet und der Syntaxfehler an den Absender der XML-Nachricht übermittelt. Enthält
die XML-Nachricht keinen Syntaxfehler auf Dokumenten-Ebene, so werden alle weiteren Ebe-
nen, die in der XML-Nachricht vorhanden sind, geprüft. Alle hierbei gefundenen Syntaxfehler
werden an den Absender der XML-Nachricht übermittelt. Die Differenzierung der Ebenen ist
notwendig, um die genaue Position des erkannten Fehlers an den ursprünglichen Absender der
XML-Nachricht zu übermitteln.
5.1 Erläuterungen und Beispiele zur Syntax-Prüfung
In den folgenden Unterkapiteln werden die verschiedenen Syntax-Prüfungen anhand von Bei-
spielen auf den verschiedenen Ebenen weiter erläutert.
Version: 1.0 01.08.2022 Seite 8 von 27Konzept zur Rückmeldung des technischen Prüfergebnisses für XML-Nachrichten 5.1.1 Häufigkeit einer xs:sequence / xsd:sequence (1..1) In der folgenden Darstellung ist die xs:sequence mit einer Häufigkeit von 1..1 angegeben. Das bedeutet, dass die xs:sequence mindestens einmal angegeben werden muss und auch maximal nur einmal angegeben werden darf. 5.1.2 Häufigkeit eines Elements (1..1) In der folgenden Darstellung ist das Element mit einer Häufigkeit von 1..1 angegeben. Das be- deutet, dass das Element mindestens einmal angegeben werden muss und auch maximal nur einmal angegeben werden darf. 5.1.3 Häufigkeit eines Elements (0..1) In der folgenden Darstellung ist das Element mit einer Häufigkeit von 0..1 angegeben. Das be- deutet, dass das Element nicht angegeben werden muss und wenn, maximal nur einmal ange- geben werden darf. Das Element hat ggf. Abhängigkeiten zu anderen Elementen und ist daher in Abhängigkeit zu anderen Elementen zu befüllen. Diese Details ergeben sich aus den Anwen- dungstabellen und sind daher kein Bestandteil der Syntaxprüfung. 5.1.4 Attribut mit Use „required“ In der folgenden Darstellung aus der ist das Attribut „v“ mit dem Status Use „required“ angege- ben. Das bedeutet, dass das Attribut verpflichtend zu diesem Element anzugeben ist. Version: 1.0 01.08.2022 Seite 9 von 27
Konzept zur Rückmeldung des technischen Prüfergebnisses für XML-Nachrichten 5.1.5 Wertevorrat „Anwendbare Codes“ In der folgenden Darstellung ist der definierte Wertevorrat „Anwendbare Codes“ mit drei Codes vorhanden. Es darf in diesem Element einer der drei Codes aus dem Wertevorrat verwendet werden. Das Element hat ggf. Abhängigkeiten zu anderen Elementen und ist daher in Abhängig- keit zu anderen Elementen zu befüllen. Diese Details ergeben sich aus den Anwendungstabellen und sind daher kein Bestandteil der Syntaxprüfung. 5.1.6 Wertevorrat „Fixed“ In der folgenden Darstellung ist der definierte Wertevorrat „Fixed“ mit einem Wert vorhanden. Es darf hier lediglich der fixe Wert verwendet werden. 5.1.7 Formatvorgaben „Length“ In der folgenden Darstellung ist als Formatvorgabe die mit 1 .. 35 (1 bis zu 35 Zeichen angeben). Es muss also mindestens 1 Zeichen und es dürften maximal 35 Zeichen angegeben werden. Version: 1.0 01.08.2022 Seite 10 von 27
Konzept zur Rückmeldung des technischen Prüfergebnisses für XML-Nachrichten
5.1.8 Formatvorgaben „Pattern“
In der folgenden Darstellung ist als Pattern C[A-Z\d]{9}\d angegeben. Das bedeutet es ist die
Objekt-ID einer Steuerbaren Ressource anzugeben. An der ersten Stelle des Wertes darf dabei
ausschließlich ein „C“ angegeben werden. An den Stellen zwei bis zehn sind ausschließlich Zah-
len „0-9“ und/oder Großbuchstaben „A-Z“ erlaubt. An der Stelle 11 sind ausschließlich Zahlen
„0-9“ erlaubt. Hinweis: Die Identifikationsnummer wird zentral durch die Energie Codes und
Services GmbH ausgegeben.
5.2 Dokumenten-Ebene der einzelnen XML-Nachrichten
Die nachfolgenden Tabellen geben einen Überblick zu den Elementen/Attributen, welche in den
einzelnen XML-Nachrichtenformaten zu der Dokumenten-Ebene gehören.
5.2.1 ActivationDocument
XML-Nachrichten- Element
format
Activation DtdBDEWNachrichtenVersion
Document DocumentIdentification
DocumentVersion
DocumentType
ProcessType
SenderIdentification
SenderRole
ReceiverIdentification
ReceiverRole
CreationDateTime
ActivationTimeInterval
OrderIdentification
OrderIdentificationVersion
Version: 1.0 01.08.2022 Seite 11 von 27Konzept zur Rückmeldung des technischen Prüfergebnisses für XML-Nachrichten
5.2.2 Beschaffungsanforderung energetischer Ausgleich
XML-Nachrichten- Element
format
Beschaffungsan- DtdBDEWNachrichtenVersion
forderung ener- DocumentIdentification
getischer Aus- DocumentVersion
gleich DocumentType
ProcessType
SenderIdentification
SenderRole
ReceiverIdentification
ReceiverRole
DocumentDateTime
TimePeriodCovered
5.2.3 Beschaffungsvorbehalt
XML-Nachrichten- Element
format
Beschaffungsvor- DtdBDEWNachrichtenVersion
behalt DocumentIdentification
DocumentVersion
DocumentType
ProcessType
SenderIdentification
SenderRole
ReceiverIdentification
ReceiverRole
DocumentDateTime
TimePeriodCovered
5.2.4 Kostenblatt
XML-Nachrichten- Element
format
Kostenblatt DtdBDEWNachrichtenVersion
DocumentIdentification
DocumentVersion
DocumentType
ProcessType
SenderIdentification
SenderRole
ReceiverIdentification
ReceiverRole
DocumentDateTime
Version: 1.0 01.08.2022 Seite 12 von 27Konzept zur Rückmeldung des technischen Prüfergebnisses für XML-Nachrichten
XML-Nachrichten- Element
format
TimePeriodCovered
5.2.5 NetworkConstraintDocument
XML-Nachrichten- Element
format
NetworkCons- DtdVersion
traintDocument DtdRelease
DtdBDEWNachrichtenVersion
DocumentIdentification
DocumentVersion
DocumentType
ProcessType
SenderIdentification
SenderRole
ReceiverIdentification
ReceiverRole
DocumentDateTime
TimePeriodCovered
DocStatus
5.2.6 PlannedResourceScheduleDocument
XML-Nachrichtenfor- Element
mat
Plan- DtdVersion
nedResourceSchedule- DtdRelease
document DtdBDEWNachrichtenVersion
DocumentIdentification
DocumentVersion
DocumentType
ProcessType
SenderIdentification
SenderRole
ReceiverIdentification
ReceiverRole
DocumentDateTime
TimePeriodCovered
Version: 1.0 01.08.2022 Seite 13 von 27Konzept zur Rückmeldung des technischen Prüfergebnisses für XML-Nachrichten
5.2.7 Stammdaten
XML-Nachrichtenfor- Element
mat
Stammdaten DtdBDEWNachrichtenVersion
DocumentIdentification
DocumentType
Sender
Senderrolle
Empfaenger
Empfaengerrolle
RefDokumentID
OriginalSender
OriginalDokumentID
OriginalErstellungszeitpunkt
Gueltig_ab
Meldungsstatus
5.2.8 Unavailability_MarketDocument
XML-Nachrichten- Element
format
Unavailabi- DtdBDEWNachrichtenVersion
lity_Market- mRID
Document revisionNumber
type
process.processType
createdDateTime
sender_MarketParticipant.mRID
sender_MarketParticipant.marketRole.type
receiver_MarketParticipant.mRID
receiver_MarketParticipant.marketRole.type
unavailability_Time_Period.timeInterval
docStatus
5.2.9 StatusRequest_MarketDocument
XML-Nachrichten- Element
format
StatusRequ- DtdBDEWNachrichtenVersion
est_Market- mRID
Document type
sender_MarketParticipant.mRID
sender_MarketParticipant.marketRole.type
receiver_MarketParticipant.mRID
Version: 1.0 01.08.2022 Seite 14 von 27Konzept zur Rückmeldung des technischen Prüfergebnisses für XML-Nachrichten
XML-Nachrichten- Element
format
receiver_MarketParticipant.marketRole.type
requested_MarketParticipant.mRID
requested_MarketParticipant.marketRole.type
createdDateTime
original_sender_MarketParticipant.mRID
original_document_mRID
original_createdDateTime
5.3 Übermittlung eines Syntaxfehlers auf Dokumenten-Ebene
Enthält eine XML-Nachricht mindestens einen Syntaxfehler auf Dokumenten-Ebene, so wird der
gesamte Inhalt der XML-Nachricht abgelehnt.
Es wird dem Absender der XML-Nachricht mitgeteilt, dass die XML-Nachricht empfangen wurde
(angekommen ist) und
› diese nicht den Vorgaben der entsprechenden Formatbeschreibung entspricht (Reason,
ReasonCode: A02 „Message fully rejected“), sowie dass
› die XML-Nachricht inkl. aller in dieser Nachricht vorhandenen Geschäftsvorfälle nicht wei-
terverarbeitet werden kann.
5.3.1 Detaillierung des Syntaxfehlers auf Dokumenten-Ebene
Mittels Wiederholung des Elements „Reason“ wird die vollständige Ablehnung der XML-Nach-
richt weiter detailliert und die Ablehnung unter Nutzung eines weiteren „ReasonCode“ begrün-
det. Gründe für die Ablehnung auf Dokumenten-Ebene können sein:
› Pflichtangabe fehlt (xs:sequence/xsd:sequence/Element/Attribut ist nicht angegeben, ge-
mäß Nachrichtenbeschreibung aber als Pflichtangabe definiert)
› Zu viele Wiederholungen (xs:sequence/xsd:sequence/Element/Attribut ist häufiger angege-
ben als dies gemäß Nachrichtenbeschreibung erlaubt ist)
› Reihenfolge der Elemente nicht korrekt (die Reihenfolge der Elemente entspricht nicht der
in der Sequenz vorgegebenen Reihenfolge)
› Code nicht aus erlaubtem Wertebereich (Element/Attribut enthalten einen Wert, der ge-
mäß Nachrichtenbeschreibung nicht unter „Anwendbare Codes“ bzw. oder nicht unter „fi-
xed“ nutzbar ist)
› Angegebener Wert entspricht nicht der definierten Länge (Element/Attribut enthält mehr
oder weniger Zeichen als gemäß Nachrichtenbeschreibung unter „Length“ beschrieben ist)
Version: 1.0 01.08.2022 Seite 15 von 27Konzept zur Rückmeldung des technischen Prüfergebnisses für XML-Nachrichten
› Angegebener Wert entspricht nicht dem definierten Pattern (Element/Attribut enthält ei-
nen Wert, der gemäß Nachrichtenbeschreibung nicht zum definierten „Pattern“ passt)
A01 Message fully accepted
A02 Message fully rejected
ZXA* Pflichtangabe fehlt
ZXB* Zu viele Wiederholungen
ZXC* Code nicht aus erlaubtem Wertebereich
ZXD* Angegebener Wert entspricht nicht der definierten Länge (
ZXE* Angegebener Wert entspricht nicht dem definierten Pattern
* Platzhalter, eigentlicher Code wird erst bei Veröffentlichung der Nachrichtenbeschreibung vergeben.
5.3.2 Ortsangabe des Syntaxfehlers auf Dokumenten-Ebene
Der Fehler ist so genau wie möglich zu beschreiben. Das bedeutet, zu jedem ReasonCode, wel-
cher nicht A01 bzw. A02 lautet, ist auch zwingend ein ReasonText anzugeben. Hierin wird die
Position des Fehlers beschrieben. Es ist die tiefst mögliche Ebene anzugeben, an welcher der
Fehler aufgetreten ist. Zur Angabe der Position des Fehlers ist bei der Anwendung der oben ge-
nannten Gründe für die Ablehnung verpflichtend der „ReasonText“ im Attribut „v“ anzugeben.
Hierzu wird vorgegeben, wie die Befüllung des „ReasonText“ im Attribut „v“ anzugeben ist. Wei-
tergehende Informationen im „ReasonText“ im Attribut „v“ sind nicht erlaubt.
5.4 Übermittlung eines Syntaxfehlers auf Dokumenten-Ebene
Erläuterungen anhand einer Rückmeldung eines Syntaxfehlers auf Dokumenten-Ebene auf das
PlannedResourceScheduleDocument
Version: 1.0 01.08.2022 Seite 16 von 27Konzept zur Rückmeldung des technischen Prüfergebnisses für XML-Nachrichten
5.4.1.1 Syntaxfehler im Attribut DtdBDEWNachrichtenVersion
› Reason,
ReasonCode: A02 (Message fully rejected)
› Reason,
ReasonCode: ZXC (Code nicht aus erlaubtem Wertebereich)
ReasonText: DtdBDEWNachrichtenVersion,
Erläuterung: Der Absender der XML-Nachricht hat eine Nachrichtenversion angegeben, welche
gemäß Nachrichtenbeschreibung nicht zulässig ist.
5.4.1.2 Syntaxfehler im Element SenderIdentification
› Reason,
ReasonCode: A02 (Message fully rejected)
› Reason,
ReasonCode: ZXA (Pflichtangabe fehlt)
ReasonText: SenderIdentification
Erläuterung: Der Absender der XML-Nachricht hat das Element SenderIdentification nicht ange-
geben, obwohl dies gemäß Nachrichtenbeschreibung erforderlich ist.
5.4.1.3 Syntaxfehler im Attribut v des Element SenderIdentification
› Reason,
ReasonCode: A02 (Message fully rejected)
› Reason,
ReasonCode: ZXE (Angegebener Wert entspricht nicht dem definierten Pattern)
ReasonText: SenderIdentification/v
Version: 1.0 01.08.2022 Seite 17 von 27Konzept zur Rückmeldung des technischen Prüfergebnisses für XML-Nachrichten
Erläuterung: Der Absender der XML-Nachricht hat einen Wert im Attribut angegeben, welche
gemäß Nachrichtenbeschreibung nicht dem definierten Pattern entspricht.
5.4.1.4 Syntaxfehler im Attribut codingScheme des Element SenderIdentification
› Reason,
ReasonCode: A02 (Message fully rejected)
› Reason,
ReasonCode: ZXC (Code nicht aus erlaubtem Wertebereich)
ReasonText: SenderIdentification/codingScheme
Erläuterung: Der Absender der XML-Nachricht hat einen Wert im Attribut angegeben, welche
gemäß Nachrichtenbeschreibung nicht den erlaubten Codes entspricht.
5.4.1.5 Syntaxfehler im Attribut codingScheme des Element SenderIdentification (2)
› Reason,
ReasonCode: A02 (Message fully rejected)
› Reason,
ReasonCode: ZXB (Zu viele Wiederholungen)
ReasonText: SenderIdentification/codingScheme
Erläuterung: Der Absender der XML-Nachricht hat das Attribut mehr als gemäß Nachrichtenbe-
schreibung definiert angegeben.
5.5 Übermittlung eines Syntaxfehlers auf allen weiteren Ebene
Enthält eine XML-Nachricht mindestens einen Syntaxfehler auf einer weiteren Ebene unterhalb
der Dokumenten-Ebene, so wird auch hier der gesamte Inhalt der XML-Nachricht abgelehnt.
Es wird dem Absender der XML-Nachricht mitgeteilt, dass die XML-Nachricht empfangen wurde
(angekommen ist) und
› diese nicht den Vorgaben der entsprechenden Formatbeschreibung entspricht (Reason,
ReasonCode: A02 „Message fully rejected“), sowie dass
› die XML-Nachricht inkl. aller in dieser Nachricht vorhandenen Geschäftsvorfälle nicht wei-
terverarbeitet werden kann.
Im Gegensatz zu einem Fehler auf Dokumenten-Ebene wird auf allen weiteren Ebenen nicht bei
dem ersten festgestellten Fehler abgebrochen, sondern es wird weiter geprüft, um möglichst
alle Fehler und die jeweilige Position, an welcher der Fehler aufgetreten ist, an den ursprüngli-
chen Absender der XML-Nachricht zu übermitteln.
Version: 1.0 01.08.2022 Seite 18 von 27Konzept zur Rückmeldung des technischen Prüfergebnisses für XML-Nachrichten
5.5.1 Detaillierung des Syntaxfehlers auf allen weiteren Ebenen
Mittels Wiederholung des Elements „Reason“ wird die vollständige Ablehnung der XML-Nach-
richt weiter detailliert und die Ablehnung unter Nutzung eines weiteren „ReasonCode“ begrün-
det. Gründe für die Ablehnung können sein:
› Pflichtangabe fehlt (xs:sequence/xsd:sequence/Element/Attribut ist nicht angegeben, ge-
mäß Nachrichtenbeschreibung aber als Pflichtangabe definiert)
› Zu viele Wiederholungen (xs:sequence/xsd:sequence/Element/Attribut ist häufiger angege-
ben als dies gemäß Nachrichtenbeschreibung erlaubt ist)
› Reihenfolge der Elemente nicht korrekt (die Reihenfolge der Elemente entspricht nicht der
in der Sequenz vorgegebenen Reihenfolge)
› Code nicht aus erlaubtem Wertebereich (Element/Attribut enthalten einen Wert, der ge-
mäß Nachrichtenbeschreibung nicht unter „Anwendbare Codes“ bzw. oder nicht unter „fi-
xed“ nutzbar ist)
› Angegebener Wert entspricht nicht der definierten Länge (Element/Attribut enthält mehr
oder weniger Zeichen als gemäß Nachrichtenbeschreibung unter „Length“ beschrieben ist)
› Angegebener Wert entspricht nicht dem definierten Pattern (Element/Attribut enthält ei-
nen Wert, der gemäß Nachrichtenbeschreibung nicht zum definierten „Pattern“ passt)
Für jeden festgestellten Fehler ist das Element „Reason“ zu Wiederholen und der Fehler über
einen weiteren „ReasonCode“ zu begründen. Zu jedem der oben genannten „ReasonCode“ ist
zwingend ein „ReasonText“ anzugeben, in welchem die Position des Fehler beschrieben ist
(siehe nachfolgendes Kapitel)
Version: 1.0 01.08.2022 Seite 19 von 27Konzept zur Rückmeldung des technischen Prüfergebnisses für XML-Nachrichten
A01 Message fully accepted
A02 Message fully rejected
ZXA* Pflichtangabe fehlt
ZXB* Zu viele Wiederholungen
ZXC* Code nicht aus erlaubtem Wertebereich
ZXD* Angegebener Wert entspricht nicht der definierten Länge (
ZXE* Angegebener Wert entspricht nicht dem definierten Pattern
* Platzhalter, eigentlicher Code wird erst bei Veröffentlichung der Nachrichtenbeschreibung vergeben.
5.5.2 Ortsangabe des Syntaxfehlers auf allen weiteren Ebenen
Der Fehler ist so genau wie möglich zu beschreiben. Das bedeutet, zu jedem ReasonCode, wel-
cher nicht A01 bzw. A02 lautet ist, auch zwingend ein ReasonText anzugeben. Hierin wird die
Position des Fehlers beschrieben. Es ist die tiefst mögliche Ebene anzugeben, an welcher der
Fehler aufgetreten ist. Zur Angabe der Position des Fehlers ist bei der Anwendung der oben ge-
nannten Gründe für die Ablehnung verpflichtend der „ReasonText“ im Attribut „v“ anzugeben.
Hierzu wird vorgegeben, wie die Befüllung des „ReasonText“ im Attribut „v“ anzugeben ist. Wei-
tergehende Informationen im „ReasonText“ im Attribut „v“ sind nicht erlaubt.
Da sich auf allen weiteren Ebenen zur Dokumenten-Ebene Sequenzen ggf. mehrfach wiederho-
len lassen sind auch die eindeutigen Identifikatoren der einzelnen Sequenzen im „ReasonText“
anzugeben. Dies wird in dem folgenden Kapitel weiter erläutert.
5.6 Übermittlung eines Syntaxfehlers auf allen weiteren Ebenen
Erläuterungen anhand einer Rückmeldung eines Syntaxfehlers auf weiteren Ebenen auf das
PlannedResourceScheduleDocument.
Im PlannedResourceScheduleDocument existieren weitere Ebenen, welche aufeinander auf-
bauen. Um die Position des Fehler so genau wie möglich zu beschreiben, genügt es bei der
Übermittlung nicht einfach auf das Element „Direction“ zu verweisen (wenn hier der Fehler auf-
getreten sein sollte), da das Element „Direction“ innerhalb der XML-Nachricht aufgrund der
Version: 1.0 01.08.2022 Seite 20 von 27Konzept zur Rückmeldung des technischen Prüfergebnisses für XML-Nachrichten
Wiederholbarkeit des komplexen Elements „PlannedResourceTimeSeries“ mehrfach in der XML-
Nachricht vorkommen kann. Daher ist in allen weiteren Ebenen die jeweilige Struktur, in wel-
cher sich der Fehler befindet, eindeutig zu beschreiben.
Exemplarisches Beispiel:
In einer XML-Nachricht PlannedResourceScheduleDocument werden zwei Plan-
nedResourceTimeSeries übermittelt. In der ersten PlannedResourceTimeSeries mit der TimeSe-
riesIdentification XXTS1 wurde eine falsche „ConnectingArea“ angegeben. In der zweiten Plan-
nedResourceTimeSeries mit der TimeSeriesIdentification XXTS2 fehlt das Element „Product“.
Um diese beiden Fehler und deren Position eindeutig zu beschreiben, wird diese wie folgt über-
mittelt:
Syntaxfehler im Attribut v des Element ConnectionArea der ersten PlannedResourceTimeSeries
› Reason,
ReasonCode: A02 (Message fully rejected)
› Reason,
ReasonCode: ZXC (Code nicht aus erlaubtem Wertebereich)
ReasonText: PlannedResourceTimeSeries/TimeSeriesIdentification“XXTS1“/ConnectingA-
rea/v
Syntaxfehler im Element Product der zweiten PlannedResourceTimeSeries
› Reason,
ReasonCode: ZXA (Pflichtangabe fehlt)
ReasonText: PlannedResourceTimeSeries/TimeSeriesIdentification“XXTS2“/Product
Version: 1.0 01.08.2022 Seite 21 von 27Konzept zur Rückmeldung des technischen Prüfergebnisses für XML-Nachrichten
Der ursprüngliche Absender der XML-Nachricht erhält somit strukturiert die exakte Position
übermittelt, an welcher der jeweilige Fehler bzw. die Fehler aufgetreten sind und kann diese
entsprechend analysieren und korrigieren.
Da sich innerhalb von komplexen Elementen auch weitere komplexe Elemente befinden kön-
nen, ist in jedem der komplexen Elemente das erste Element das Element zur Identifikation des
komplexen Elements (siehe auch nachfolgende Tabelle). Auf dieser Basis lässt sich exemplarisch
für das PlannedResourceScheduleDocument die folgende Struktur der einzelnen Ebenen dar-
stellen.
vereinfachte Darstellung:
› PlannedResourceTimeSeries (1..unbounded)
[…] Elemente / Attribute […]
Period (1..1 je PlannedResourceTimeSeries)
o […] Elemente / Attribute […]
o Interval (1..100 je Period)
▪ […] Elemente / Attribute […]
Darstellung der verschiedenen Ebenen mit Identifikatoren
Nr. Ebene Identifikator der Ebene
1 Dokumenten-Ebene --
2 PlannedResourceTimeSeries eindeutiger Identifikator je PlannedResourceTimeSeries =
TimeSeriesIdentification
3 Period eindeutiger Identifikator je Period = TimeInterval
4 Interval Eindeutiger Identifikator je Interval = Pos
Es gelingt daher mit der strukturierten Rückmeldung die Position, an welcher der Fehler auftrat,
auch in einem komplexen Element detailliert anzugeben.
In den folgenden Unterkapiteln werden weitere komplexe Fehlersituationen innerhalb des Plan-
nedResourceScheduleDocument beschrieben, welche sich in verschiedenen komplexen Elemen-
ten befinden. Für das Konzept wurde an dieser Stelle lediglich beispielhaft auf das Plan-
nedResourceScheduleDocument eingegangen. Die eindeutigen Identifikatoren der komplexen
Elemente der verschiedenen XML-Nachrichten werden im Rahmen der Überführung in die For-
matbeschreibung analog dem PlannedResourceScheduleDocument beschrieben.
Version: 1.0 01.08.2022 Seite 22 von 27Konzept zur Rückmeldung des technischen Prüfergebnisses für XML-Nachrichten
Vereinfachte Nachrichtendarstellung für die folgenden Fehlertypen im Plan-
nedResourceScheduleDocument
5.6.1.1 Syntaxfehler im Attribut v des Element ResourceObject
Der Fehler besteht in diesem Beispiel in der dritten PlannedResourceTimeSeries mit dem mit
der TimeSeriesIdentification XXTS3 im Attribut v des ResourceObject
› Reason,
ReasonCode: A02 (Message fully rejected)
› Reason,
ReasonCode: ZXD (Angegebener Wert entspricht nicht der definierten Länge)
ReasonText: PlannedResourceTimeSeries/TimeSeriesIdentification“XXTS3“/ResourceOb-
ject/v
Erläuterung: Der Absender der XML-Nachricht hat in der dritten TimeSeries mit dem Identifika-
tor XXTS3 einen Wert im ResourceObject angegeben, der nicht der definierten Feldlänge gemäß
Nachrichtenbeschreibung.
Version: 1.0 01.08.2022 Seite 23 von 27Konzept zur Rückmeldung des technischen Prüfergebnisses für XML-Nachrichten
5.6.1.2 Syntaxfehler im Attribut v des Element Resolution
Der Fehler besteht in diesem Beispiel in der zweiten PlannedResourceTimeSeries mit der Time-
SeriesIdentification XXTS2 im komplexen Element Period mit dem TimeInterval 2022-08-
01T22:00Z/2022-08-02T22:00Z mit dem Attribut v der Resolution
› Reason,
ReasonCode: A02 (Message fully rejected)
› Reason,
ReasonCode: ZXC (Code nicht aus erlaubtem Wertebereich)
ReasonText: PlannedResourceTimeSeries/TimeSeriesIdentification“XXTS2“/Pe-
riod/TimeInterval“2022-08-01T22:00Z/2022-08-02T22:00Z“/Resolution/v
Erläuterung: Der Absender der XML-Nachricht hat in der zweiten TimeSeries mit dem Identifika-
tor im komplexen Element Period mit dem TimeInterval 2022-08-01T22:00Z/2022-08-02T22:00Z
im dem Attribut v der Resolution einen Code angegeben, der gemäß Nachrichtenbeschreibung
nicht zulässig ist.
5.6.1.3 Syntaxfehler im Attribut v des Element Qty
Der Fehler besteht in diesem Beispiel in der vierten PlannedResourceTimeSeries mit der Time-
SeriesIdentification XXTS4 im komplexen Element Period mit dem TimeInterval 2022-08-
01T22:00Z/2022-08-02T22:00Z im komplexen Element Interval auf der Position 4 im Attribut v
des Element Qty
› Reason,
ReasonCode: A02 (Message fully rejected)
ReasonCode: ZXE (Angegebener Wert entspricht nicht dem definierten Pattern)
ReasonText: PlannedResourceTimeSeries/TimeSeriesIdentification“XXTS4“/Pe-
riod/TimeInterval“2022-08-01T22:00Z/2022-08-02T22:00Z“/Interval/Pos“4“/Qty/v
Erläuterung: Der Absender der XML-Nachricht hat in der vierten TimeSeries mit dem Identifika-
tor im komplexen Element Period mit dem TimeInterval 2022-08-01T22:00Z/2022-08-02T22:00Z
im komplexen Element Intervall mit der Pos 4 im Attribut v des Element v einen Wert angege-
ben, der gemäß Nachrichtenbeschreibung nicht zulässig ist.
5.6.1.4 Syntaxfehler im Attribut codingScheme des Element SenderIdentification
Der Fehler besteht in diesem Beispiel in der ersten PlannedResourceTimeSeries mit der TimeSe-
riesIdentification XXTS1 im komplexen Element Period mit dem TimeInterval 2022-08-
01T22:00Z/2022-08-02T22:00Z im komplexen Element Interval, in dem das komplexe Element
mehr als 100 mal angegeben wurde.
Version: 1.0 01.08.2022 Seite 24 von 27Konzept zur Rückmeldung des technischen Prüfergebnisses für XML-Nachrichten
› Reason,
ReasonCode: A02 (Message fully rejected)
› Reason,
ReasonCode: ZXB (Zu viele Wiederholungen)
ReasonText: PlannedResourceTimeSeries/TimeSeriesIdentification“XXTS1“/Pe-
riod/TimeInterval“2022-08-01T22:00Z/2022-08-02T22:00Z“/Interval
Erläuterung: Der Absender der XML-Nachricht hat in der ersten TimeSeries mit dem Identifika-
tor im komplexen Element Period mit dem TimeInterval 2022-08-01T22:00Z/2022-08-02T22:00Z
im komplexen Element Intervall mehr Wiederholungen durchgeführt, als gemäß Nachrichtenbe-
schreibung zulässig sind.
5.6.1.5 Syntaxfehler mit mehreren verschiedenen Fehlern auf unterschiedlichen Ebenen in
einer XML-Nachricht
Der Fehler besteht in diesem Beispiel wie folgt:
› in der ersten PlannedResourceTimeSeries mit der TimeSeriesIdentification XXTS1 im kom-
plexen Element Period mit dem TimeInterval 2022-08-01T22:00Z/2022-08-02T22:00Z im
komplexen Element Interval in dem das komplexe Element mehr als 100 mal angegeben
wurde sowie
› in der zweiten PlannedResourceTimeSeries mit der TimeSeriesIdentification XXTS2 im kom-
plexen Element Period mit dem TimeInterval 2022-08-01T22:00Z/2022-08-02T22:00Z mit
dem Attribut v der Resolution sowie
› in der vierten PlannedResourceTimeSeries mit dem mit der TimeSeriesIdentification XXTS4
im Attribut v des ResourceObject
› in der vierten PlannedResourceTimeSeries mit der TimeSeriesIdentification XXTS4 im kom-
plexen Element Period mit dem TimeInterval 2022-08-01T22:00Z/2022-08-02T22:00Z im
komplexen Element Interval auf der Position 4 im Attribut v des Element Qty
› Reason,
ReasonCode: A02 (Message fully rejected)
› Reason,
ReasonCode: ZXB (Zu viele Wiederholungen)
ReasonText: PlannedResourceTimeSeries/TimeSeriesIdentification“XXTS1“/Pe-
riod/TimeInterval“2022-08-01T22:00Z/2022-08-02T22:00Z“/Interval
› Reason,
ReasonCode: ZXC (Code nicht aus erlaubtem Wertebereich)
Version: 1.0 01.08.2022 Seite 25 von 27Konzept zur Rückmeldung des technischen Prüfergebnisses für XML-Nachrichten
ReasonText: PlannedResourceTimeSeries/TimeSeriesIdentification“XXTS2“/Pe-
riod/TimeInterval“2022-08-01T22:00Z/2022-08-02T22:00Z“/Resolution/v
› Reason,
ReasonCode: ZXE (Angegebener Wert entspricht nicht dem definierten Pattern)
ReasonText: PlannedResourceTimeSeries/TimeSeriesIdentification“XXTS4“/Pe-
riod/TimeInterval“2022-08-01T22:00Z/2022-08-02T22:00Z“/Interval/Pos“4“/Qty/v
› Reason,
ReasonCode: ZXD (Angegebener Wert entspricht nicht der definierten Länge)
ReasonText: PlannedResourceTimeSeries/TimeSeriesIdentification“XXTS4“/ResourceOb-
ject/v
Erläuterung:
› Der Absender der XML-Nachricht hat in der zweiten TimeSeries mit dem Identifikator im
komplexen Element Period mit dem TimeInterval 2022-08-01T22:00Z/2022-08-02T22:00Z
im dem Attribut v der Resolution einen Code angegeben, der gemäß Nachrichtenbeschrei-
bung nicht zulässig ist.
› Der Absender der XML-Nachricht hat in der ersten TimeSeries mit dem Identifikator im kom-
plexen Element Period mit dem TimeInterval 2022-08-01T22:00Z/2022-08-02T22:00Z im
komplexen Element Intervall mehr Wiederholungen durchgeführt, als gemäß Nachrichten-
beschreibung zulässig sind.
› Der Absender der XML-Nachricht hat in der vierten TimeSeries mit dem Identifikator im
komplexen Element Period mit dem TimeInterval 2022-08-01T22:00Z/2022-08-02T22:00Z
im komplexen Element Intervall mit der Pos 4 im Attribut v des Element v einen Wert ange-
geben, der gemäß Nachrichtenbeschreibung nicht zulässig ist.
› Der Absender der XML-Nachricht hat in der dritten TimeSeries mit dem Identifikator XXTS3
einen Wert im ResourceObject angegeben, der nicht der definierten Feldlänge gemäß Nach-
richtenbeschreibung.
5.7 Empfangsbestätigung, Syntaxprüfung fehlerfrei
Enthält eine XML-Nachricht keinen Syntaxfehler, weder auf Dokumenten-Ebene noch auf allen
weiteren Ebenen, so wird der gesamte Inhalt der XML-Nachricht bestätigt.
Es wird dem Absender der XML-Nachricht mitgeteilt, dass die XML-Nachricht empfangen wurde
(angekommen ist) und
Version: 1.0 01.08.2022 Seite 26 von 27Konzept zur Rückmeldung des technischen Prüfergebnisses für XML-Nachrichten
› diese den Vorgaben der entsprechenden Formatbeschreibung entspricht (Reason, Reason-
Code: A01 „Message fully accepted“), sowie dass
› die XML-Nachricht in die fachliche Verarbeitung des Geschäftsvorfalles/der Geschäftsvor-
fälle gelangt ist.
6 Zeitplan
Es wird beabsichtigt den Markt über das generelle Ergebnis der Umsetzung der in dem Konzept
genannten technischen Prüfung nach Abschluss der Konsultationssitzung im September 2022 zu
informieren. Darauf aufbauend ist geplant die Erweiterungen in den technischen Prüfungen
zum 01.04.2023 in den Nachrichtenformaten zu veröffentlichen. Die Anwendbarkeit ergibt sich
dann ab dem 01.10.2023 00:00 Uhr.
7 Ausblick
Dieses Konzept bildet im ersten Schritt die Basis für die technische Prüfung der XML-Nachricht.
Nach Umsetzung der technischen Prüfung wird sich die Projektgruppe edi@energy mit der Wei-
terentwicklung der Prüfungen auf fachliche Abhängigkeiten (Prüfung auf Anwendungstabellen,
Erlaubte Elemente, Attribute, Codes in den einzelnen Anwendungsfällen, etc.) beschäftigen. Der
weitere Zeitplan der Implementierung der fachlichen Prüfungen ist kein Bestandteil dieses Kon-
zepts. Zum jetzigen Zeitpunkt kann hierzu noch keine Aussage getroffen werden.
Version: 1.0 01.08.2022 Seite 27 von 27Sie können auch lesen
