R::305'LOC YZA-RWUNET---I::305'RFF+MG: 'CCI+++E02'CAV+E02::260'CCI+++E01'CAV+G1::89'CCI+++E03'CAV+E06::260'SEQ++1'PIA+5+1-

Transkript

1 UNA:+.? 'UNB+UNOC: : : : 'UNH+1+UTILMD:D:04B:UN:4.1a'BGM+E 'DTM+137: :203'DTM+735:?+0100:406'RFF+CT:1'DTM+171: :203'NAD+MR ::9'NAD+MS ::293'IDE 'DTM+92: :102'STS+7++E03'AGR+11:E02'AGR +12:E05'AGR+E03:E10'LOC+172+DE ::89'LOC XUELSEN ?:1.8.0:SRW::174'QTY+31:1201:KWH'NAD+IT++++Hardinghauser Str.::31+Uelsen 'NAD+UD+++Am Iland zur EdiEater-Version 7.0 1?:1.8.0:SRW::174'QTY+31:1478:KWH'NAD+IT++++Hundestr.::1+Föhr 'NAD+UD+++Nicola-Tesla-Str:17: :::1+Stromstr.::1+Neuss 'RFF+AVC:1206'IDE 'DTM+92: :102'STS+7++E03'AGR+11:E Oktober 'AGR+12:E05'AGR+E03:E10'LOC+172+DL6BZ ::89'LOC GETELO----- R::305'LOC YZA-RWUNET---I::305'RFF+MG: 'CCI+++E02'CAV+E02::260'CCI+++E01'CAV+G1::89'CCI+++E03'CAV+E06::260'SEQ++1'PIA :KG::::1+Str.::31+Neuss 'RFF+AVC:1205'IDE 'DTM+92: :102'STS+7++E03'AGR+11:E 02'AGR+12:E05'AGR+E03:E10'LOC+172+DE ::89'LOC XSWNEUSS----- Handbuch R::305'LOC YZB-REGION---I::305'RFF+MG: 'CCI+++E02'CAV+E02::260'CCI+++E01'CAV+G1::89'CCI+++E03'CAV+E06::260'SEQ++1'PIA+5+1- R::305'LOC YDE-RWENET---I::305'RFF+MG: 'CCI+++E02'CAV+E02::260'CCI+++E01'CAV+G1::89'CCI+++E03'CAV+E06::260'SEQ++1'PIA+5+1-1?:1.8.0:SRW::174'QTY+31:1733:KWH'NAD+IT++++Hammer Landstr.::13+Itterbeck 'NAD+UD+++Edisonstr:::::1+Zum EdiEater EDIFACT-Nachrichten analysieren und darstellen Steenebarg::3+Uelsen 'RFF+AVC:1207'IDE 'DTM+92: :102'STS+7++E03'AGR+11:E02'A GR+12:E05'AGR+E03:E10'LOC+172+DL6BZ ERSATZ-02::89'LOC+237+DARC----- R::305'LOC YDE-RWENET ::305'RFF+MG:'CCI+++E02'CAV+E02::260'CCI+++E01' CAV+G1::89'CCI+++E03' 1

2 Inhaltsverzeichnis 1 Einleitung Systemanforderungen Installation Manuelle Installation ArcMind Windows-Installer Bedienung Funktionsumfang Übersicht Fehlerarten Syntaxfehler Modellfehler Anwendungsfehler Warnungen Nachrichtenformate Dateigrößen Dateicodierung Grundsätzliches und Einschränkungen EdiEater Status Der Report Aufbau Abschnitt 1 Datei Abschnitt 2 EDIFACT Abschnitt 3 Fehler Abschnitt 4 Segmente Leer übermittelt und nicht übermittelt Große EDIFACT-Dateien Die Präsenzattribute (Status) von Segmenten Textsuche in den Reports Konfiguration Sprache Reportgröße Zeilenumbrüche Dateidecodierung Vollständige Segmente Marktpartnerkennungen Updateverzeichnis EdiEater Fehlermeldungen Nachrichtenmodul nicht vorhanden Syntaxversion nicht unterstützt Kein EDIFACT UNA-Segment defekt

3 7 Undocumented Features GZIP-Komprimierte EDIFACT-Dateien Komprimierte Archive (ZIP) Verzeichnisse EdiEater Startprobleme Exception UnsupportedClassVersionError Eine neue Java-Version ist aber vorhanden! Impressum

4 Handbuch EdiEater Version 7.0 Einleitung Installation 1 Einleitung Sicherlich ist jeder Marktteilnehmer im Zuge der elektronischen Marktkommunikation schon aus eigenem Interesse erpicht, syntaktisch korrekte und modellfehlerfreie EDIFACT-Nachrichten in den Markt zu senden und ebenso korrekte EDIFACT-Nachrichten zu empfangen. Kein Marktteilnehmer wünscht sich den Eingang negativer CONTRLs oder APERAKs, weil sonst die Pflicht zur Fristwahrung an ihn zurückfällt. Fehlerhafte EDIFACT-Nachrichten verursachen zudem mitunter langwierige Klärungsprozesse, entweder im eigenen Hause oder mit anderen Marktpartnern. Schon im Anwendungshandbuch zur CONTRL / APERAK vom hieß es daher mahnend: Der Sender ist verantwortlich für eine plausible, inhaltlich und syntaktisch richtige sowie vollständig gefüllte EDIFACT-Nachrichtendatei 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ändigkeitsbereich verantwortlich [Seite 8 im aktuellen Handbuch zur APERAK 2.0g ].... Je genauer der Fehler beschrieben wird, umso einfacher kann die Fehlerbehandlung seitens des Senders erfolgreich absolviert werden. Dabei kann auch eine Erkundigung beim Empfänger der Nachrichtendatei hilfreich sein [Seite 4 im aktuellen Handbuch]. Sie werden es vermutlich kennen, die Erkundigung eines anderen Marktpartners bei Ihnen ist nicht selten die Aufforderung, genau darzulegen warum die Nachricht X mit einer negativen CONTRL (Syntaxfehlermeldung) oder einer APERAK 313 (Modellfehlermeldung) geahndet wurde. Mit der im Anwendungshandbuch vorsichtig formulierten Mahnung zur Mitwirkung begeben Sie sich also auf die Fehlersuche, die klassischerweise folgenden Ablauf hat. Klassische Fehlersuche Die zu untersuchende EDIFACT-Datei wird in einen Editor geladen und mittels eines zumeist selbst erstellten Makros so modifiziert, dass die Segmente zeilenweise angezeigt werden. Dazu wird jedem Segmentendezeichen durch das Makro ein Zeilenumbruch 4

5 Handbuch EdiEater Version 7.0 Einleitung Installation hinzugefügt. Viele Makros versagen allerdings wenn das Segmentendezeichen auch als Nutzzeichen innerhalb eines Segmentes auftaucht, wie beispielsweise bei der Straßenangabe Metzwies chen. Daher ist nach der Ausführung des Makros oft noch eine Korrektur nötig. Die eigentliche Fehlersuche erfolgt dann unter Heranziehung der entsprechenden Nachrichtenbeschreibung (MIG = Message Implementation Guide) über den visuellen Abgleich zwischen den Sollvorgaben aus dem MIG und dem Ist-Zustand der EDIFACT-Datei im Editor. Bild 1.1 Klassische Fehlersuche mit Editor und Unterlagen 5

6 Handbuch EdiEater Version 7.0 Einleitung Installation Die Fehlersuche erfordert Konzentration, Fachwissen und Erfahrung. Bei großen EDIFACT-Dateien ist zudem Ausdauer gefragt. Erfahrene Nachrichtenexperten erkennen sicherlich viele Syntax- und Modellfehler auf Anhieb. Ab einer bestimmten Nachrichtengröße ist die Fehlersuche aber auch für sie praktisch nicht mehr durchführbar. Alternativ besteht natürlich die Möglichkeit, die zu untersuchende EDIFACT-Datei in das vorhandene EDI-System einzuspielen und die Fehlersuche von diesem durchführen zu lassen. Schließlich verfügt das EDI-System über eine Syntax- und Modellfehlerprüfung. Ein Problem besteht zunächst darin, dem EDI-System mitzuteilen, dass diese EDIFACT-Datei lediglich getestet und deren fachlicher Inhalt nicht weiter verarbeitet werden darf. Manche Systeme werten dazu das Testflag im UNB-Segment aus, bei anderen Systemen ist man auf bestimmte Uhrzeiten angewiesen, in denen das System aus dem Produktivbetrieb genommen wird. Ein weiteres Problem sind die mitunter kryptischen Meldungen oder Protokolle des Systems. Viele EDI(FACT)-Systeme sind nicht in der Lage, genaue Auskunft über den Fehlerort und die Fehlerart zu geben. Sie sprechen oft kein EDIFACT. Nicht selten werden lediglich Hinweise auf die Fehlerursache geliefert, denen anschließend von Hand nachgegangen werden muss. Die Verwendung des vorhandenen EDI-Systems ist natürlich dann hinfällig, wenn das System selber Gegenstand des Testes ist, beispielsweise bei der Umstellung auf neue Nachrichtenformate. Eine andere Möglichkeit besteht darin, die Datei über einen im Internet angebotenen Dienst prüfen zu lassen. Dazu muss die Nachricht per Mail meist unverschlüsselt (Datenschutz!) an diesen Dienst gesendet werden. Fehler zu finden, ist das eine. Die Fehler anschaulich darzulegen, das andere Wie auch immer die Fehler letztlich gefunden werden, die Fehlersuche ist nur das eine, das andere ist, die gefundenen Fehler dem Marktpartner gegenüber anschaulich darzustellen und zu begründen. Üblicherweise werden dazu die fehlerbehafteten Segmente aufgeführt, die Fehlerstellen farblich hervorgehoben und unter Verweis auf die entsprechenden Stellen im MIG begründet. Zur 6

7 Handbuch EdiEater Version 7.0 Einleitung Installation Veranschaulichung dienen zusätzliche Screenshots. Das ganze wird dann zu einer mehr oder minder nett formulierten Mail geschnürt und an den Marktpartner geschickt. Alles in allem, Fehlersuche und nachvollziehbare Begründung der Fehler, ist dieses Vorgehen ein zeitaufwändiges Unterfangen. Wer sich nicht täglich mit mehr als zehn Anfragen dieser Art beschäftigen muss, darf sich glücklich schätzen. Für alle anderen wurde aus genau dieser Not heraus der EdiEater entwickelt. Bild 1.2 EDIFACT-Datei EdiEater Report EDIFACT-Datei analysieren und Report erzeugen Der EdiEater Der EdiEater (ausgesprochen edi iter ) analysiert EDIFACT-Dateien auf Syntax- und Modellfehler und stellt die Ergebnisse anschaulich in Form eines HTML-Reports (Miniwebseite) dar. Der Report wird mittels eines üblichen Webbrowsers betrachtet. Die EDIFACT-Datei ist segmentweise aufgeführt, wobei jedes Segment bis herunter auf die einzelnen Datenelemente detailliert dargestellt wird. Datenelemente, Datengruppen und Segmente sind in Anlehnung an die Darstellung in den MIGs einzeln beschrieben. Fehler, wenn vorhanden, sind an ihrem Fehlerort je nach Fehlerart farblich hervorgehoben. Sofern zu den Inhalten bestimmter Datenelemente Informationen bekannt sind, wie z.b. die Bedeutung bestimmter Qualifier, werden diese Informationen ebenfalls angezeigt. Den Report können Sie dann dem Marktpartner per Mail zusenden, was in der Regel dessen Fragen klärt. 7

8 Handbuch EdiEater Version 7.0 Einleitung Installation Bild 1.3: Ein Segment aus einer UTILMD und dessen Darstellung im EdiEater-Report Der EdiEater ist ein Darstellungs- und Analysewerkzeug für EDIFACT-Nachrichten, ausgerichtet auf Syntaxfehler (CONTRL) und Modellfehler (APERAK 313). Er ist ebenfalls ideal für Schulungszwecke, nicht nur, weil der Nachrichtenaufbau anschaulich dargestellt wird, sondern auch weil Änderungen an der EDIFACT-Datei und deren Auswirkungen sofort sichtbar gemacht werden können. Der EdiEater wurde erstmals zum Spätherbst 2007 im BIS-Regelbetrieb der RWE als Prototyp eingesetzt. Im Mai 2008 startete ein einjähriger Praxistest mit drei Marktpartnern. Herzlichen Dank dafür an die ELE in Gelsenkirchen, an die A / V / E in Halle und an die Bocholter Energie- und Wasserversorgung. Seit April 2009 ist der EdiEater bei vielen Marktteilnehmern kommerziell im Einsatz. 8

9 Handbuch EdiEater Version 7.0 Systemanforderungen Installation 2 Systemanforderungen Der EdiEater ist ein Java-Programm und benötigt zur Ausführung lediglich eine Java Laufzeitumgebung (JRE / JVM) ab Java Version 1.5. Sollten Sie bereits die von RWE zur freien Verfügung angebotenen EDIFACT-Utilities (früher UTILMD-Editor) benutzen, dann verfügt Ihr Rechner schon über die passende Java Laufzeitumgebung. Ansonsten muss diese zunächst auf Ihrem Rechner installiert werden. Aus rechtlichen Gründen darf die Java Laufzeitumgebung nicht mit dem EdiEater ausgeliefert werden. Die Java Laufzeitumgebung ist im Internet frei erhältlich. Als Java-Programm ist der EdiEater betriebssystemunabhängig. An die Rechenleistung und den Arbeitspeicher werden keine besonderen Anforderungen gestellt. Sicherlich sind mindestens 500 MHz Prozessortakt und mindestens 256 MB Arbeitsspeicher ratsam je nach verwendetem Betriebssystem und sonstiger Arbeitslast des Rechners. 2.1 Installation Der EdiEater wird üblicherweise mit einem Installationsprogramm für Windows-Plattformen ausgeliefert. Dieses Programm vereinfacht die Installation. Falls Sie den EdiEater mit Installationsprogramm erhalten haben, erübrigt sich der nachfolgende Abschnitt Manuelle Installation Eine Installation im strengen Sinne ist nicht notwendig. Der EdiEater ist ein Javaprogramm und beißt sich daher nicht im Rechner fest. Er erfolgt keine Manipulation der Registrierungsdatei(en) oder anderer Dateien. Der EdiEater kann übrigens auch von einem USB-Stick aus gestartet werden. Um den EdiEater auf Ihrem Rechner heimisch zu machen, braucht der EdiEater lediglich ein Heimatverzeichnis, beispielsweise C:\Programme\edieater. Dieses Verzeichnis ist bitte vom Anwender anzulegen. In diesem Verzeichnis müssen sich mindestens die beiden Dateien 9

10 Handbuch EdiEater Version 7.0 Systemanforderungen Installation edieater.jar edieater.cmd befinden. Die Datei edieater.jar ist das eigentliche Programm. Die Datei edieater.cmd dient zum Starten des EdiEaters. Für den einfachen Zugriff auf den EdiEater sollte ein Link (eine Verknüpfung) auf den Desktop gelegt werden. Dazu die Datei edieater.cmd bei gedrückter rechter Maustaste auf den Desktop ziehen und dann im Kontextmenü Verknüpfung hier erstellen auswählen. Der Name der Verknüpfung kann natürlich noch geändert werden (z.b. einfach nur EdiEater). Bild 2.1: Erstellen einer Verknüpfung auf dem Desktop Die zu untersuchende EDIFACT-Datei wird einfach mit der Maus (Drag & Drop) auf die Verknüpfung gezogen (siehe Bild 2.6). Ein vollständiges EdiEater Heimatverzeichnis sieht in etwa so aus, wie in Bild 2.2 gezeigt. Die Datei edieater.cfg ist eine Konfigurationsdatei (Textdatei) in welcher ein paar Einstellungen geändert werden können. Mehr dazu in Kapitel 5. Die Datei status.cmd dient dazu, dem EdiEater einen Statusreport zu entlocken, siehe auch Kapitel 3.8. Das Unterverzeichnis messages wird nur dann benötigt, wenn der EdiEater um weitere Nachrichtenformate erweitert werden soll. Das Verzeichnis ist normalerweise leer oder nicht vorhanden. Das Unterverzeichnis mpid wird gebraucht, wenn Sie dem EdiEater neue Marktpartnerkennungen bekannt machen wollen. Siehe dazu auch Kapitel

11 Handbuch EdiEater Version 7.0 Systemanforderungen Installation Bild 2.2: Beispiel eines EdiEater Heimatverzeichnisses Zum Deinstallieren des EdiEaters löschen Sie einfach das Installationsverzeichnis (Heimatverzeichnis) und die Verknüpfung auf dem Desktop ArcMind Windows-Installer Bestimmte Versionen des EdiEaters werden mit dem ArcMind Windows-Installer (Setup) ausgeliefert. Der Installer prüft zunächst, ob Java ab Version 1.5 (Java 5) auf Ihrem Rechner vorhanden ist. Wenn nicht, dann müssen Sie sich zunächst von eine Laufzeitumgebung herunterladen und auf dem Rechner installieren. Starten Sie den Installer danach erneut. Der Installer schlägt als Installationsverzeichnis das Verzeichnis C:\Programme\ArcMind EdiEater vor. Akzeptieren Sie diesen Vorschlag oder geben ein anderes Installationsverzeichnis an. Nach Weiter wird Ihnen angeboten, eine Verknüpfung auf dem Desktop anlegen zu lassen. Nehmen Sie dieses Angebot bitte an, sonst müssen Sie selber mit Bordmitteln diese Verknüpfung schaffen (siehe vorheriges Kapitel). Sie können die Verknüpfung später vom Desktop an einen anderen Ort verschieben. Nach erneutem Weiter kann die Installation beginnen. Mit Installieren wird der EdiEater auf Ihren Rechner kopiert. Der EdiEater benötigt weniger als 2 MB Plattenplatz (ohne Handbuch). 11

12 Handbuch EdiEater Version 7.0 Systemanforderungen Installation Bild 2.3: Vorschlag des Installationsverzeichnisses (links) und Angebot einer Verknüpfung auf dem Desktop (rechts) In dem vom ArcMind-Installer erzeugten Heimatverzeichnis des EdiEaters finden sich die zwei Dateien unsins000.exe und uninst000.dat. Die erste Datei ist das Deinstallationsprogramm. Wenn Sie dieses ausführen, wird der EdiEater wieder von Ihrem Rechner entfernt. Sie können natürlich auch das EdiEater-Verzeichnis und die Verknüpfung auf dem Desktop von Hand löschen, dann sind Sie den EdiEater ebenfalls los. 12

13 Handbuch EdiEater Version 7.0 Systemanforderungen Installation Bild 2.4: Bereit zur Installation (links). Nach der Installation (rechts) Bild 2.5: EdiEater Heimatverzeichnis mit dem Deinstallationsprogramm unins000.exe 13

14 Handbuch EdiEater Version 7.0 Systemanforderungen Bedienung 2.2 Bedienung Der EdiEater verfügt über keine grafische Bedienoberfläche. Die zu untersuchende EDIFACT-Datei wird einfach mit der Maus auf eine Verknüpfung gezogen (die Verknüpfung wird blau wenn sie die Datei gefangen hat) und dort fallengelassen (= Maustaste loslassen). Bild 2.6: Ziehen einer EDIFACT-Datei auf die Verknüpfung (Drag & Drop) Daraufhin beginnt der EdiEater mit der Analyse der EDIFACT-Datei und erzeugt in deren Ursprungsverzeichnis den Report als HTML- Datei. Der Name der Reportdatei besteht aus dem Originaldateinamen plus der Endung.report.html. Mit einem beliebigen Internetbrowser kann der Report anschließend betrachtet werden. Während des Analysevorganges öffnet sich ein Konsolenfenster, das sich nach Erstellung des Reports wieder schließt. Das mutet altbacken an, ist aber schneller als der Aufbau einer grafischen Benutzeroberfläche. 14

15 Handbuch EdiEater Version 7.0 Systemanforderungen Bedienung Bild 2.7: Temporäres Konsolenfenster während der EdiEater arbeitet. Das Fenster schließt automatisch nach Fertigstellung des Reports. Bild 2.8: EDIFACT Datei und erzeugter Report 15

16 Handbuch EdiEater Version 7.0 Funktionsumfang Übersicht 3 Funktionsumfang 3.1 Übersicht Der EdiEater ist ein Analysewerkzeug für Syntax- und Modellfehler in UN/EDIFACT-Nachrichten mit den Syntaxversionen 1, 2 und 3. Die Syntaxversion 4 wird nicht unterstützt. Der EdiEater unterstützt dabei die Syntax-Level (Zeichensätze) UNOA, UNOB und UNOC. Die EDIFACT-Nachrichten müssen in Form von Textdateien vorliegen. EDIFACT-XML wird nicht unterstützt. Der EdiEater wird nach Kundenwunsch bzw. Lizenz für ein oder mehrere bestimmte EDIFACT-Nachrichtenformate ausgeliefert. Der EdiEater verarbeitet EDIFACT-Textdateien bis mindestens 40 MB Dateigrösse und erzeugt einen Report als HTML-Datei (Miniwebseite). Die Analysedauer liegt bei etwa 10 Sekunden für kleine Dateien und mehr als 5 Minuten bei Dateien über 20 MB Grösse. Der vom EdiEater erzeugte Report wird Hilfe eines Webbrowsers betrachtet. Die Größe des Reports ist aus praktischen Gründen auf etwa 3 MB begrenzt. Der EdiEater ersetzt keinen EDIFACT-Fachmann, er ist ein Unterstützungswerkzeug für EDIFACT-Fachleute bei der Fehlersuche/Analyse von EDIFACT-Nachrichten. Der EdiEater ist auch für Schulungszwecke geeignet. Der EdiEater erkennt neben Syntax- und Modellfehlern auch einige Anwendungsfehler, diese sind aber nicht Gegenstand des offiziellen Leistungsumfanges. In den folgenden Abschnitten wird näher auf die Leistungsmerkmale eingegangen. 3.2 Fehlerarten Der EdiEater unterscheidet drei Fehlerarten, je nach Abstraktionsstufe eines Fehlers. Auf der untersten Stufe sind Syntaxfehler angesiedelt. Sie zeigen ein Integritätsproblem an und stellen den schwerwiegendsten Fehler dar. Syntaxfehler verbieten eine Weiterverarbeitung der Daten. Modellfehler sind definierte Fehler inhaltlicher Art, welche mittels einer APERAK gemeldet werden. Dazu ist jedem Modellfehler ein eindeutiger Qualifier zugeordnet. Modellfehler sind weniger schwerwiegend. Als Anwendungsfehler werden 16

17 Handbuch EdiEater Version 7.0 Funktionsumfang Fehlerarten ganz allgemein Fehler in der Anwendung einer EDIFACT-Nachricht bezeichnet, also Fehler beim Befüllen einer EDIFACT-Nachricht mit den für eine Transaktion technisch und fachlich notwendigen Informationen. Modellfehler sind eigentlich Anwendungsfehler, allerdings sind für diese speziellen Anwendungsfehler standardisierte Rückmeldungen mittels APERAK definiert. Der Begriff Anwendungsfehler umfasst daher alle Fehler, die nicht schon durch das Sieb der Syntaxprüfung oder der Modellfehlerprüfung aufgefangen werden. Zu den Anwendungsfehlern gehören jedoch keine Fehler oder Unstimmigkeiten in Bezug auf den Datenbestand des Zielsystems, wie z.b. Kunde unbekannt oder Zählpunkt nicht identifizierbar. Anwendungsfehler beziehen sich nur auf die Umsetzung einer Transaktion mittels einer EDIFACT-Nachricht. Fehlerstufe Anwendungsfehler Modellfehler Syntaxfehler Bild 3.1: Fehlerarten bei Nachrichten mit definierter Modellfehlerprüfung Der EdiEater ist ein Analysewerkzeug für Syntax- und Modellfehler. Zwar erkennt der EdiEater auch einige Anwendungsfehler, jedoch ist diese Fähigkeit lediglich eine Zugabe. Solange Anwendungsfehler in den einschlägigen Dokumenten nicht dediziert benannt, beschrieben und computertauglich standardisiert sind, ist eine programmtechnische Umsetzung nicht möglich. Neben den drei genannten Fehlerarten, kennt der EdiEater auch noch die Warnung. Eine Warnung hat die Funktion eines mehr oder weniger ernstzunehmenden Hinweises. Warnungen werden vom EdiEater immer dann ausgesprochen, wenn sich ein Analyseergebnis nicht als Fehler einordnen lässt. Die Fehlerart Modellfehler gibt es allerdings nur dann, wenn für eine Nachricht durch die Anwenderorganisation (z.b. BDEW) eine Modellfehlerprüfung mit entsprechenden Qualifiern sowie deren Rückmeldung mittels APERAK spezifiziert wurde. Eine solche Prüfung 17

18 Handbuch EdiEater Version 7.0 Funktionsumfang Fehlerarten existiert beispielsweise nicht für alle GPKE-Nachrichten vor dem Zwar gibt es schon immer den Nachrichtentyp APERAK, aber es gab kein vorgeschriebenes standardisiertes Verfahren zur elektronischen Rückmeldung von Anwendungsfehlern mittels einheitlich definierter Qualifier ( = Modellfehler). Für die in GaBi verwendeten Edig@s Nachrichtentypen (z.b. ALOCAT) gilt gleiches, erst ab dem wurde dort eine Modellfehlerprüfung wirksam. Für solche Nachrichten, für die seitens der Anwenderorganisationen keine Modellfehler definiert wurden, existiert die Fehlerstufe Modellfehler nicht. Es gibt nur die Fehlerarten Syntaxfehler und Anwendungsfehler. Fehlerstufe Anwendungsfehler Syntaxfehler Bild 3.2: Fehlerarten bei Nachrichten ohne definierte Modellfehlerprüfung Was also beispielsweise in einer UTILMD 4.1a einen Modellfehler darstellt, fällt für die ältere UTILMD 4.0b in die Kategorie Anwendungsfehler. Der EdiEater weiß, für welche Nachrichtentypen Modellfehler definiert wurden und für welche nicht. 18

19 Handbuch EdiEater Version 7.0 Funktionsumfang Fehlerarten Bild 3.3: Das Fehlen des Datenelementes BGM.DE1225 stellt bei einer UTILMD 4.1a den Modellfehler Z03 dar. Bild 3.4: Das Fehlen des gleichen Datenelementes stellt bei einer UTILMD 4.0b einen Anwendungsfehler dar. Damals gab es keine Modellfehler. 19

20 Handbuch EdiEater Version 7.0 Funktionsumfang Fehlerarten Syntaxfehler Syntaxfehler sind Fehler in der Struktur einer EDIFACT-Nachricht sowie inhaltliche Unstimmigkeiten in bestimmten Servicesegmenten. Diese Fehler sind unabhängig vom Nachrichtentyp und vom Inhalt der Nachricht. Syntaxfehler sind international einheitlich durch die entsprechenden UN/CEFACT Dokumente definiert (ISO 9735). Nationale Organisationen können, solange es sich bei der herausgebenden Organisation der Nachricht um die UN handelt (UNH.S009.DE0051 = UN) keine eigenen Syntaxregeln aufstellen. Dies widerspräche auch dem Gedanken des standardisierten internationalen Nachrichtenaustausches mittels EDIFACT-Nachrichten. In der Syntaxprüfung wird geprüft, ob die Nutzdaten korrekt verpackt sind. Es geht bei dieser Prüfung nicht darum, was übermittelt wird, sondern wie es übermittelt wird. Der EdiEater erkennt folgende Syntaxfehler gemäß der UN/CEFACT Service Code List, Syntax Version 3 ( 12: Invalid value Ungültiger Wert, z.b. alphabetisches Zeichen in einem strikt numerischen Feld oder numerisches Zeichen in einem strikt alphabetischen Feld. 13: Missing Pflichtelement (Segmentgruppe, Segment, Datengruppe oder Datenelement) fehlt. 15: Not supported in this position Ein Segment, eine Datengruppe oder ein Datenelement wurde an einer Position übermittelt, die in der Nachrichtenstruktur nicht existiert. 16: Too many constituents Zu viele Bestandteile, z.b. zu viele Datenelemente in einer Datengruppe. 19: Invalid decimal notation Eine Kommazahl verwendet nicht das im UNA-Segment als Dezimaltrennzeichen definierte Zeichen. 20

21 Handbuch EdiEater Version 7.0 Funktionsumfang Fehlerarten 21: Invalid character (s) Ein Zeichen entspricht nicht dem in UNB.S001.DE0001 angegebenen Syntax-Level (Zeichenvorrat) UNOA, UNOB oder UNOC. 28: References do not match Referenznummer in UNB / UNH stimmt nicht mit dem Pendant in UNZ / UNT überein. 29: Contrl count does not match number of instances received Die Anzahl der vom EdiEater gezählten Segmente pro Nachricht (UNT) bzw. insgesamt (UNZ) stimmt nicht mit der in UNT / UNZ angegebenen Anzahl überein. 35: Too many data element or segment repetitions Zu viele Wiederholungen von Datenelementen oder Segmenten. 36: Too many segment group repetitions Zu viele Wiederholungen einer Segmentgruppe. 39: Data element too long Die Länge eines Datenelementes überschreitet die Maximalgröße des Feldes. 40: Data element too short Die geforderte Mindestanzahl an Zeichen in einem Datenelement ist unterschritten. 45: Trailing separator (existiert nur in Syntaxversion 4) Es wurden unnötige leere Datenelemente oder Datengruppen direkt vor dem Ende eines Segmentes gesendet (Segment unnötig mit Leerinformation aufgebläht). In Syntaxversion 4, die vom EdiEater nicht unterstützt (und auch im Markt nicht verwendet) wird, ist dies ein Syntaxfehler. Der EdiEater gibt hier eine Warnung aus. 21

22 Handbuch EdiEater Version 7.0 Funktionsumfang Fehlerarten Die in der originalen Codeliste aufgeführten Codes bezeichnen sowohl Syntaxfehler als auch Verfahrensfehler. So bezeichnet beispielsweise der Code 7 (Interchange recipient not actual recipient) keinen Fehler in der Nachrichtensyntax, genau so wie 26 (Duplicate detected) keinen Syntaxfehler sondern einen Verfahrensfehler darstellt. Es ist also nicht so, dass alle Codes der UN/CEFACT Service Code List ausschließlich Syntaxfehler repräsentieren. Der EdiEater stellt Syntaxfehler in Rot dar. Syntaxfehler sind schwerwiegend, da die Integrität der EDIFACT-Datei beschädigt ist. Syntaktisch falsche EDIFACT-Dateien sollen nicht weiterverarbeitet werden. Wenn die vom EdiEater analysierte EDIFACT-Datei die gängige Syntaxversion 3 verwendet (UNB.S001.DE002 = 3), zeigt der EdiEater die zuvor aufgeführten Fehlercodes an. Für die Syntaxversionen 1 und 2 existiert keine UN/CEFACT Codeliste, der EdiEater zeigt natürlich den Fehler, aber keinen Fehlercode an. Bild 3.5: Beispiel für den Syntaxfehler 29 (Syntaxversion 3). Die Angabe im UNT-Segment stimmt nicht mit der Anzahl tatsächlich übermittelter Segmente überein Modellfehler Modellfehler sind Anwendungsfehler, für die einheitliche Qualifier (Fehlercodes) und ein Rückmeldeprozess per APERAK definiert wurden. Nicht für alle Nachrichtentypen sind Modellfehler definiert. Beispielsweise gibt es für eine UTILMD 4.0b keine einheitliche Modellfehlerprüfung und damit auch keine Modellfehler. Bei der Modellfehlerprüfung werden die Segmente unabhängig voneinander folgenden Prüfungen unterzogen: 22

23 Handbuch EdiEater Version 7.0 Funktionsumfang Fehlerarten Sind die von der nationalen Anwenderorganisation (z.b. BDEW, DVGW) als Mussfelder gekennzeichneten Elemente gefüllt? Entspricht der Wert eines Datenfeldes dem von der Anwenderorganisation für dieses Feld vorgegebenem Format? Nur für Qualifier (z.b. 293 = BDEW) und Formatvorgaben (z.b. 203 = JJJJMMTTHHmm): Sind die Qualifier, wenn vorhanden, aus dem von der Anwenderorganisation vorgeschriebenem zulässigen Wertevorrat, sofern ein verbindlicher Wertevorrat für ein Datenelement vorgegeben ist? Der EdiEater unterlegt Modellfehler mit der Farbe Orange. Für Nachrichten, die der Modellfehlerprüfung nach APERAK 2.0a, 2.0b und 2.0c, unterliegen, erkennt der EdiEater folgende Modellfehler: Z01 = Qualifier nicht aus erlaubtem Wertebereich z.b. nicht erlaubter Qualifier 500 statt erlaubtem Qualifier 293 Z02 = Format nicht eingehalten z.b. Datumsformat inkorrekt oder Zahlenformat inkorrekt Z03 = Erforderliche Angabe fehlt Ein gemäß Anwenderorganisation erforderliches Element fehlt oder ist leer Für die Modellfehlerprüfung ab APERAK 2.0d (ab Oktober 2010) erkennt der EdiEater zusätzlich diesen Modellfehler: Z08 = Erforderliches Segment fehlt Ein Segment mit dem BDEW-Status R wurde nicht übermittelt. 23

24 Handbuch EdiEater Version 7.0 Funktionsumfang Fehlerarten Den Fehler Z04 (Identifikationscode für Marktpartner unbekannt, APERAK 2.0a) kann der EdiEater nicht erkennen, dazu bräuchte er eine konstante Internetanbindung an die Datenbank des BDEW oder DVGW um eine Kennung hochaktuell auf deren Existenz bzw. Korrektheit zu überprüfen. Der EdiEater führt aber für BDEW und DVGW-Codenummern, sowie für GLNs einen Prüfsummencheck durch und erkennt ungültige Kennungen. Der Modellfehler Z04 fällt eher in die Kategorie Verfahrensfehler bei der Adressierung von Marktpartnern. Gleiches gilt für die Qualifier Z05 (Empfänger-MP-ID und Empfänger stimmen nicht überein) und Z06 (MP-ID beim Empfänger nicht bekannt), die mit der APERAK 2.0b eingeführt wurden. Da der EdiEater für universellen Einsatz konzipiert ist und nicht an eine bestimmte Marktpartnerkennung gebunden wird, spielen diese Modellfehler für den EdiEater keine Rolle. Gleiches gilt für den Modellfehler Z07 (Datenaustauschreferenz des Absenders bei Empfänger bereits bekannt), der mit der APERAK 2.0c eingeführt wurde. Der EdiEater kann und soll die Modellfehler Z04, Z05, Z06 und Z07 nicht beachten. Bild 3.6: Beispiel für einen Modellfehler Z03. Ein von der Anwenderorganisation als erforderlich eingestuftes Feld wurde nicht übermittelt. Mit der APERAK 2.0f (ab Oktober 2011) können erstmalig ganz bestimmte Anwendungsfehler als so genannte Verarbeitbarkeitsfehler per APERAK zurückgemeldet werden. Diese Verarbeitbarkeitsfehler sind fachlich/inhaltliche Fehler, die nur im Bezug auf den Datenbestand des Empfängers deutlich werden. Beispiel ist Z10 (Zählpunktbezeichnung unbekannt). Solche Fehler werden daher auch nicht vom EDIFACT-Marktkommunikationssystem erzeugt, sondern von den nachgelagerten Systemen, die das nötige Wissen dazu besitzen. Der EdiEater kann aus Prinzip solche Verarbeitbarkeitsfehler nicht (er)kennen. 24

25 Handbuch EdiEater Version 7.0 Funktionsumfang Fehlerarten Bild 3.7: Ein anderes Beispiel für einen Modellfehler Z03. Es gibt keine Ablesewoche 5, ein Monat hat nur vier Ablesewochen Anwendungsfehler Unter Anwendungsfehler werden die Fehler verstanden, die nicht schon durch die Fehlerarten Syntaxfehler oder Modellfehler abgedeckt sind. Nicht zu den Anwendungsfehlern gehören jedoch fachliche Unstimmigkeiten in Bezug auf den Datenbestand des Zielsystems, wie z.b. Lieferstelle nicht identifizierbar. Diese Unstimmigkeiten sind oberhalb der Anwendungsfehler angesiedelt und sind außerhalb der Testfähigkeiten des EdiEaters oder jedes anderen vom Zielsystem entkoppelten Analysewerkzeuges. Die vergangenen Modellfehlerprüfungen, sowie auch die zukünftigen Modellfehlerprüfungen, prüfen höhere Zusammenhänge in der Nachricht nicht auf deren Plausibilität. Eine Zuordnungsliste (UTILMD, E06), die fälschlicherweise als Netznutzungsanmeldung (E01) deklariert ist, wird von der derzeit definierten Modellfehlerprüfung nicht abgedeckt. Für solche Anwendungsfehler (Fehler in der 25

26 Handbuch EdiEater Version 7.0 Funktionsumfang Fehlerarten Anwendung einer EDIFACT-Nachricht zur Durchführung einer Transaktion) gibt es noch keine automatisierten Fehlermeldungen und Fehlercodes. Ein anderes Beispiel für einen nicht von der Modellfehlerprüfung abgedeckten Anwendungsfehler ist die Übermittlung nicht ganzzahliger Jahresverbräuche. Jahresverbräuche werden üblicherweise ganzzahlig (also ohne Nachkommastellen) übermittelt. Ein Verstoß (z.b. Übermittlung des Wertes 350,801 kwh) hat weder eine negative CONTRL, noch eine APERAK zur Folge. Solche Fehler müssen nach wie vor von Hand zwischen den Beteiligten geklärt werden ( bilaterale Klärung ). Mit Einführung der APERAK 2.0f zum Oktober 2011 sind bestimmte Anwendungsfehler als Verabeitbarkeitsfehler per APERAK meldbar. Es handelt sich dabei um fünf genau spezifizierte Fehlerfälle (siehe MIG CONTRL/APERAK, Version 2.0f oder 2.0g, Seite 16). Der EdiEater kann diese Fehler nicht erkennen, da sie nur in Bezug auf den Datenbestand des Empfängers überhaupt als Fehler erkennbar werden. Der EdiEater ist grundsätzlich nur für Syntax- und Modellfehler ausgelegt. Zur Abdeckung aller Anwendungsfehler müssten die AHBs der jeweiligen Nachrichtentypen programmtechnisch umgesetzt werden, was schon wegen der vorhandenen Widersprüchlichkeiten nicht einfach ist. Am Ende stünde ein großvolumiges Software-Expertensystem, das vermutlich ebenso teuer ist wie ein echter Experte. Anwendungsfehler, insbesondere die der höheren Art, werden auch in Zukunft nicht vom EdiEater abgedeckt. Der EdiEater erkennt in Altnachrichten aber mindestens diejenigen Anwendungsfehler, die in neueren Nachrichtenversionen als Modellfehler deklariert sind. Die Anwendungsfehler, die vom EdiEater erkannt und angezeigt werden, sind in der Farbe Gelb hinterlegt. 26

27 Handbuch EdiEater Version 7.0 Funktionsumfang Fehlerarten Bild 3.8: Unzulässige Qualifierkombination (segmentübergreifend). Eine Kündigungsfrist (Z01) gehört nicht in eine Kundenbestandsliste (E06). Bild 3.9: Die Monatsangaben müssen identisch sein. Dies ist ein inhaltlicher Fehler (Anwendungsfehler), kein Formatfehler (Modellfehler). 27

28 Handbuch EdiEater Version 7.0 Funktionsumfang Warnungen 3.3 Warnungen Warnungen werden immer dann vom EdiEater ausgesprochen, wenn sich eine Feststellung nicht als Fehler einstufen lässt bzw. kein ernsthaftes Problem darstellt. Ein Beispiel ist die Verwendung von Feldern, die markteinheitlich nicht ausgewertet werden (N). Die Verwendung eines solchen Feldes stellt keinen Fehler dar (auch keinen Modelfehler, da eine Modellfehlerprüfung grundsätzlich nicht bei Feldern greift, die ohnehin nicht ausgewertet werden), es mag aber für die Systementwickler des Quellsystems interessant sein, da mehr Daten als notwendig übertragen werden. Übrigens wurde in der Vergangenheit eine rege Diskussion um die Verwendung von N-Feldern geführt. Der BDEW hat wiederholt bestätigt, dass N-Felder benutzt werden dürfen auch wenn diese Felder keine für den Geschäftsprozess notwendige Information enthalten. Siehe auch Forum Datenformate des BDEW: Bild 3.10: Ein Feld wird verwendet, welches markteinheitlich jedoch nicht ausgewertet wird. 28

29 Handbuch EdiEater Version 7.0 Funktionsumfang Warnungen Im nächsten Beispiel wird die Datengruppe C059 unnötig aufgebläht. Nach dem Datenelement DE3042 mit dem Inhalt 11 hätte die Datengruppe direkt beendet werden sollen. Stattdessen wurde ein weiteres leeres Datenelement übermittelt. In den Syntaxversionen 1, 2 und 3 stellt dies keinen offiziellen Fehler dar. Allerdings heißt es im UN/EDIFACT DRAFT DIRECTORY: There shall be no component data element separator after the last component data element in a composite data element and no data element separator after the last data element in a segment. Mit anderen Worten, die Zeichenfolgen :+ oder +' oder :' sollen in einer EDIFACT-Nachricht möglichst nicht auftauchen. Bild 3.11: Unerwünschte Übermittlung eines leeren Datenelementes als letztes Element einer Datengruppe. 29

30 Handbuch EdiEater Version 7.0 Funktionsumfang Nachrichtenformate Bild 3.12: Weiteres Beispiel für eine Warnung: Kennung und Qualifier passen nicht zueinander (Nachrichtenformate vor Oktober 2010). Nach Oktober 2010 stellt dieser Fehler gemäß dem Forum Datenformate einen Modellfehler dar. 3.4 Nachrichtenformate Grundsätzlich ist der Verarbeitungskern des EdiEaters in der Lage, jede beliebige UNSM (United Nations Standard Message), sowie deren nationale bzw. organisationsspezifischen Derivate zu verarbeiten. Allerdings sind nicht alle diese Konfigurationen unmittelbar auf Lager, sie werden aber auf Anfrage gefertigt und bereitgestellt. Der EdiEater ist nicht auf den Energiemarkt beschränkt, auch EDIFACT-Nachrichten aus anderen Handelssparten kann der EdiEater prinzipiell analysieren (z.b. EANCOM). Mit dem Stand Oktober 2012 (EdiEater in der Version 7.0) sind Konfigurationen für die folgenden Nachrichtentypen- und Versionen aus GPKE, GeLi, MaBis und WiM verfügbar: APERAK 1.0a, 2.0a, 2.0b, 2.0c, 2.0d, 2.0e, 2.0f, 2.0g 30

31 Handbuch EdiEater Version 7.0 Funktionsumfang Nachrichtenformate CONTRL 1.3, 1.3a, 1.3b, 1.3c, 1.3d IFTSTA 1.0, 1.1, 1.1a INSRPT 1.0 INVOIC 2.0, 2.0a, 2.1, 2.2, 2.3, 2.3a, 2.4, 2.5 MSCONS 1.6b, 2.0c, 2.0d, 2.1, 2.1g3, 2.1a, 2.1b, 2.1c, 2.1d ORDERS 1.0, 1.1 ORDRSP 1.0 PRICAT 1.0 QUOTES 1.0 REMADV 2.0, 2.0a, 2.1, 2.2, 2.3, 2.3a, 2.4 REQDOC 2.0, 2.1, 2.1a, 2.1b REQOTE 1.0 UTILMD 4.0, 4.0a, 4.0b, 4.1a, 4.1ag1, 4.2, 4.2a, 4.2b, 4.3, 4.4, 4.4a, 4.5 Für die Gasbilanzierung (GaBi) sind derzeit Konfigurationen für folgende Nachrichten verfügbar: ALOCAT 5.0, 5.1, 5.2, 5.3, 5.4 INTRES 4.1, 4.2 CAPNOT 4.1, 4.2 NOMINT 4.1, 4.2,

32 Handbuch EdiEater Version 7.0 Funktionsumfang Dateigrößen CAPRES 4.0, 4.2 NOMRES 4.1, 4.2, 4.3 CHACAP 4.1, 4.2 SCHEDL 4.1, 4.2 DELORD 4.1, 4.2, 4.3 SSQNOT 5.0, 5.1, 5.2, 5.3 DELRES 4.1, TRANOT 5.0, 5.1, 5.2 IMBNOT 5.0, 5.1, 5.2, 5.3 TSIMSG 5.0, 5.1, 5.1a INTORD 4.1, 4.2 Beachten Sie bitte, dass Ihr EdiEater, abhängig von der erworbenen Lizenz, nicht zwingend alle hier aufgeführten Nachrichten unterstützt. Welche Nachrichtenformate Ihre Version des EdiEaters beinhaltet, können Sie mit Hilfe des Statusreports sehen (siehe Kapitel 3.8). 3.5 Dateigrößen In der Vollversion unterliegt der EdiEater keiner festen Größenbeschränkung der zu analysierenden EDIFACT-Datei. Dateien bis 60 MB unkomprimierter Größe werden ohne besondere Speicheranforderungen problemlos verarbeitet. Mit größeren EDIFACT-Dateien wurde mangels Verfügbarkeit nicht getestet. Solche Größen sind auch eher unüblich. Für eine 60MB Datei benötigt der EdiEater je nach Rechnerleistung etwa 5 bis 10 Minuten Verarbeitungszeit. 32

33 Handbuch EdiEater Version 7.0 Funktionsumfang Dateicodierung 3.6 Dateicodierung Üblicherweise sind EDIFACT-Dateien in ASCII oder ISO (= UNOC) codiert. Die Verwendung von Unicode ist in den Syntaxversion 1 bis 3 nicht vorgesehen. Dennoch kann es in der Praxis passieren, dass eine Unicode-Datei unterwegs ist. Das passiert dann, wenn EDIFACT-Nachrichten Umlaute enthalten und mit bestimmten Texteditoren manuell verändert wurden. Diese Editoren speichern die Datei dann automatisch mit der Codierung UTF-8. Die UTF-8 codierte Datei führt dann zu Problemen, wenn ein Datenelement bis zur maximalen Länge gefüllt ist und Umlaute enthält. Da ein Umlaut in UTF-8 mit zwei Byte codiert ist (statt mit einem Byte in ISO ), wird die Maximallänge des Datenelementes überschritten, was einen Syntaxfehler darstellt. Diese Fehler sind schwer zu finden, da die Datei in einem Texteditor betrachtet augenscheinlich in Ordnung ist. Der EdiEater erkennt folgende Dateicodierungen: ASCII (wird als ISO behandelt und angezeigt), ISO (=UNOC, das ist der Standard), UTF8 mit oder ohne Byte Order Mark, UTF-16LE und UTF-16BE mit oder ohne Byte Order Mark, UTF-32LE und UTF32-BE nur mit Byte Order Mark. EBCDIC international (Codepage 500, verwendet im Bankensektor) Die Dateicodierung der EDIFACT-Datei wird im Report angezeigt. Unabhängig von der tatsächlichen Dateicodierung führt der EdiEater jedoch eine Zwangsinterpretation auf ISO durch, womit die Syntaxlevel UNOA, UNOB und UNOC immer abgedeckt sind. Durch diese Zwangsinterpretation werden Codierungsprobleme leichter entdeckt. Die Zwangsinterpretation kann abgeschaltet werden, 33

34 Handbuch EdiEater Version 7.0 Funktionsumfang Dateicodierung was bei Schulungszecken vorteilhaft ist, wenn man sich nicht mit den Dateicodierungen verschiedener Editoren herumschlagen möchte. Zur Abschaltung der Zwangsinterpretation siehe Kapitel 4.4. Dazu noch ein Beispiel. In einem NAD-Segment wird die Anschriftenzeile Überkämper Ölmagnatenstr. Gebäude 2 übertragen. Das sind genau 35 Zeichen, darunter vier Umlaute. Die EDIFACT-Datei sei UTF-8 codiert. Bei abgeschalteter Zwangsinterpretation passt sich der EdiEater der Codierung der Datei an das NAD-Segment ist fehlerfrei (Bild 3.13). In der Standardeinstellung jedoch decodiert der EdiEater die EDIFACT-Datei strikt nach ISO Jetzt erweist sich das NAD-Segment als fehlerhaft (Bild 3.14). Da Umlaute in Unicode mit zwei Byte statt mit einem Byte codiert werden, aber bei ISO jedes Zeichen genau einem Byte zugeordnet ist, wächst die Feldlänge auf 39 Zeichen an. Die vier Umlaute bringen je ein zweites Byte mit ins Spiel. Damit ist die zulässige Feldlänge von 35 Zeichen überschritten, was den Syntaxfehler 39 (data element too long) darstellt. Außerdem tritt ein weiterer Syntaxfehler auf. Zwei der zusätzlichen Bytes sind nach UNOC nicht zugelassen (und erst recht nicht nach UNOA und UNOB). Nach UNOC sind u.a. alle Zeichen mit Codewerten zwischen 7F (hexadezimal) und 9F (hexadezimal) nicht definiert. Dies stellt den Syntaxfehler 21 (invalid character) dar. 34

35 Handbuch EdiEater Version 7.0 Funktionsumfang Dateicodierung Bild 3.13: Mit abgeschalteter Zwangsinterpretation. Der EdiEater passt sich der Dateicodierung der EDIFACT-Nachricht an. Bild 3.14: Mit Zwangsinterpretation. Die UTF-8-Codierung ruft zwei verschiedene Syntaxfehler hervor. 35

36 Handbuch EdiEater Version 7.0 Funktionsumfang Grundsätzliches und Einschränkungen Unzulässige (Steuer)zeichen werden im Report durch einen kleinen Kreis dargestellt. Das liegt daran, dass nicht alle Steuerzeichen oder Sonderzeichen in HTML angezeigt werden können. Lediglich das Eurozeichen (ebenfalls unzulässig!) wird als dargestellt. 3.7 Grundsätzliches und Einschränkungen In die Entwicklung des EdiEaters ist viel Erfahrung aus der Praxis, sowie das Studium der UN/CEFACT-Dokumente eingeflossen. Dennoch gibt es nicht zu allen Problemen klare Antworten, wie ein Blick in die einschlägigen Foren zeigt. Ein Beispiel ist die Qualifier- Prüfung bei der geprüft wird, ob ein übermittelter Qualifier aus einem für das entsprechende Datenelement festgelegten Wertevorrat stammt. Die Prüfung wird für jeden Qualifier unabhängig von einem fachlichen Zusammenhang mit anderen Qualifiern vorgenommen. Dies führt in der Praxis beispielsweise bei Lastprofilangaben zu Problemen. Verwendet ein Netzbetreiber seine eigenen Lastprofile, droht ihm der Modellfehler Z01. In den Anlagen zum Anwendungshandbuch APERAK, Stand 2.0 ist für das Datenelement CAV.C889.DE7111 explizit eine Qualifier-Prüfung vorgesehen (Seite 6/8). Eine solche Prüfung kann jedoch nur gegenüber einer geschlossenen Menge von Werten erfolgen. Die Menge aller spezifischen Lastprofile aller an GPKE/GeLi beteiligten Netzbetreiber muss also an zentraler Stelle für alle Beteiligten zugänglich sein. Dem ist aber nicht so, weshalb viele Modellfehlerprüfungen in der Praxis das Feld CAV.C889.DE7111 übergehen. Der EdiEater führt für das Datenelement DE7111 dann keine Qualifier-Prüfung durch, wenn der Qualifier durch den Netzbetreiber vergeben wurde (DE3055 = 89). Der EdiEater kann nicht alle Lastprofile aller Netzbetreiber kennen. Ist jedoch als verantwortliche Stelle beispielsweise der BDEW benannt (DE3055 = 293), so prüft der EdiEater den Qualifier in DE7111 gegen die im MIG als zulässig definierten Qualifier. 36

37 Handbuch EdiEater Version 7.0 Funktionsumfang Grundsätzliches und Einschränkungen Bild 3.15: Vom Netzbetreiber vergebener Qualifier L1A für ein Lastprofil. Kein Modellfehler im EdiEater da netzbetreiberspezifisch. Bild 3.16: Das Lastprofil entspricht nicht dem im MIG definierten Wertevorrat, jetzt ist es ein Modellfehler. Die Lastprofile der TU München sind in den EdiEater eingebaut. Der EdiEater ist dennoch keine Enzyklopädie. Hier ist von Anwenderseite Mitdenken und Fachwissen gefragt. 37

38 Handbuch EdiEater Version 7.0 Funktionsumfang Grundsätzliches und Einschränkungen Ein ähnliches Beispiel zeigt der in Bild 3.17 dargestellte Ausschnitt aus einer UTILMD 4.2. Der EdiEater meldet zu Recht, dass der Qualifier 260 nicht in Verbindung mit Profilscharen (Z12) verwendet wird. Dem Fachmann wird aber auffallen, dass der Qualifier E01 ein Zählverfahren und keine Profilschar angibt. Dem EdiEater sind allerdings die Hände gebunden. Laut MIG wird die Bezeichnung einer Profilschar individuell vom Unternehmen vergeben, deswegen prüft der EdiEater in diesem Fall das Feld CAV.C889.DE7111 nicht. Der Qualifier E01 könnte eine eigenwillige unternehmensindividuelle Bezeichnung einer Profilschar sein, deswegen muss sich der EdiEater zurückhalten. 38

39 Handbuch EdiEater Version 7.0 Funktionsumfang Grundsätzliches und Einschränkungen Bild 3.17: Beispiel zur Qualifier-Kombinationsprüfung (segmentübergreifend). Eine solche unzulässige Qualifierkombinationen stellt keinen Modellfehler dar. Ein weiteres Beispiel sei noch aufgeführt. In Bild 3.18 ist ein ungültiger Zahlenwert gezeigt (nachgestelltes Minuszeichen). Für freie Zahlenwerte existiert kein Formatqualifier, nur die allgemein gehaltene Beschreibung in den Allgemeinen Festlegungen, wie Zahlenwerte darzustellen sind. Insofern unterliegt dieser Fehler nicht der Modellfehlerprüfung. Die APERAK-Prüfung der Firma 39

40 Handbuch EdiEater Version 7.0 Funktionsumfang Grundsätzliches und Einschränkungen Seeburger (BIS) beispielsweise wertet den ungültigen Zahlenwert daher nicht als Modellfehler das System ecount von Robotron aber wohl. Der EdiEater schlägt sich hier auf die Seite von Robotron und wertet diesen Fehler ebenfalls als Modellfehler Z02 Format nicht eingehalten, auch wenn es keinen definierten Formatqualifier für Kommazahlen gibt. Diese Beispiele machen deutlich, dass der EdiEater keinen mitdenkenden Fachmann ersetzen kann. Bild 3.18: Modellfehler oder nicht? Im EdiEater als Modellfehler eingestuft. Erforderliches Segment fehlt: Modellfehler oder nicht? Wenn ein auf nationaler Ebene (bzw. Anwenderorganisationsebene) mit dem Status R versehenes Segment nicht vorhanden ist, dann stufte der EdiEater dies bis zur APERAK 2.0d als Anwendungsfehler nicht als Modellfehler ein. Zwar mochte dem Fachmann sofort der Modellfehler Z03 (erforderliche Angabe fehlt) in den Sinn schießen, das wäre aber nicht korrekt. Ein Segment ist keine Angabe, sondern ein Container für Angaben. Mit dem Begriff Angabe sind laut Anwenderhandbuch CONTRL/APERAK Datenelemente oder 40

41 Handbuch EdiEater Version 7.0 Funktionsumfang Grundsätzliches und Einschränkungen Datengruppen gemeint, die dort auch korrekt als Felder bezeichnet sind. Nachfolgend die Textpassage aus dem Anwenderhandbuch CONTRL/APERAK, Version 2.0a oder Version 2.0c, Seite 14/15. In der Modellfehlerprüfung an sich wird auf Einzelsegmentebene gegen die BDEW-Segmentdefinitionen der Nachrichtentypen ohne Heranziehung des Datenbestandes im Zielsystem des Empfängers geprüft. Das bedeutet im Einzelnen: Die Muss -Felder (gekennzeichnet mit M bzw. R in der Spalte BDEW der jeweiligen Nachrichtentyp-Beschreibung) müssen mit einem Wert aus dem definierten Wertevorrat gefüllt sein. Die Kann -Felder ( O, D und A ) müssen leer oder bei Füllung ebenfalls mit einem Wert aus dem Wertevorrat gefüllt sein. Der Modellfehler betrachtet ausschließlich die Verwendung von Qualifiern und Formatvorgaben innerhalb von Segmenten, also keine Kombinationen von Anwendungsfällen wie z. B. Kategorien und Transaktionsgründe sowie Abhängigkeiten der Inhalte von Datenelementen untereinander. [... ] Bei der Modellfehlerprüfung wird also auf Einzelsegmentebene geprüft, nicht segmentübergreifend. Um ein erforderliches Segment als fehlend erkennen zu können, müsste die Modellfehlerprüfung auf Segmentgruppenebene oder höher durchgeführt werden. Der Modellfehler ist jedoch ausdrücklich beschränkt auf Prüfungen innerhalb von Segmenten. Deswegen stellen fehlende Segmente (ebenso wie Segmentgruppen, die oftmals die erforderlichen Segmente umschließen) keine Modellfehler dar und werden vom EdiEater auch korrekt als Anwendungsfehler gemeldet. Das änderte sich erst mit der APERAK 2.0d ab Oktober Mit der Modellprüfung wurde explizit der Modellfehler Z08 (Erforderliches Segment fehlt) eingeführt. Natürlich wird auch dieser Fehler vom EdiEater seitdem als Modellfehler eingestuft. 41

42 Handbuch EdiEater Version 7.0 Funktionsumfang EdiEater Status 3.8 EdiEater Status Wenn Sie wissen möchten für welche Nachrichtenformate Ihr EdiEater eigentlich konfiguriert ist oder generell einen Überblick erhalten möchten, können Sie vom EdiEater einen Statusreport verlangen. Im EdiEater-Verzeichnis befindet sich dazu die Kommandodatei status.cmd. Starten Sie diese Kommandodatei durch Doppelklick. Kurz darauf legt der EdiEater den Statusreport als status.html in diesem Verzeichnis ab. Bild 3.19: Statusreport (Seitenbeginn) für den EdiEater des fiktiven Kunden Küstenstrom 42

43 Handbuch EdiEater Version 7.0 Funktionsumfang EdiEater Status Zunächst wird im Statusreport das aktuelle Datum genannt. Dann folgt die Seriennummer Ihres EdiEaters. Falls Ihr EdiEater rechnergebunden ist, werden unter Rechnerbindung die Rechnernamen aufgeführt, für die der EdiEater lizenziert ist. Anschließend wird das Heimatverzeichnis (Installationsverzeichnis) des EdiEaters aufgeführt. Unter Konfigurationsdatei (siehe Bild 3.20) zeigt der EdiEater an, welche Einstellungen er der Konfigurationsdatei edieater.cfg entnommen hat und ob er die Anweisungen überhaupt verstanden hat. Der Status ok bedeutet, dass der EdiEater die Konfigurationsanweisung aufgenommen und umgesetzt hat. Der Status Fehler zeigt an, dass entweder das Schlüsselwort unbekannt ist oder die Umsetzung nicht erfolgen konnte. Bild 3.20: Statusreport (Fortsetzung), hier Einstellungen aus der Konfigurationsdatei 43

44 Handbuch EdiEater Version 7.0 Funktionsumfang EdiEater Status In obigem Beispiel (Bild 3.20) ist die Spracheinstellung des EdiEaters Deutsch (Standard). Die Reportgröße ist auf 2 MB begrenzt. Zeilenumbrüche werden ignoriert (und nicht als Fehler angezeigt). Die Dateidecodierung erfolgt automatisch. Mit der letzten Anweisung UPDATEDIR = Z:\public\software\edieater wird ein Updateverzeichnis eingestellt. Zu diesen und anderen Optionen für den EdiEater sehen Sie bitte Kapitel 5. Unter Nachrichtenmodule werden nun die im EdiEater verfügbaren Nachrichtenformate aufgeführt. Die erste Spalte gibt die laufende Nummer an. Die zweite Spalte Nachricht gibt die Kurzbezeichnung der Nachricht an. In der dritten Spalte ist die exakte Bezeichnung Bild 3.21: Statusreport (Fortsetzung), hier die verfügbaren Nachrichtenmodule 44