Willi Mako
// PROTOCOL:

APERAK in EDIFACT: Fehler & Bestätigungen nach BDEW/DVGW

ID#DC0-1B
STATUSREAD_ONLY
AUTHORSYS_ADMIN
TAGS [EDIFACT][LIEFERANTENWECHSEL][PROZESS][GPKE][WIM][GELI GAS]

Anwendung der APERAK-Nachricht in EDIFACT nach BDEW/DVGW-Standards

Die APERAK-Nachricht (Application Error and Acknowledgement Message) dient in der elektronischen Datenübertragung (EDI) nach BDEW/DVGW-Standards zur Übermittlung von Fehlermeldungen, Bestätigungen oder Statusinformationen zu zuvor gesendeten EDIFACT-Nachrichten. Sie ist ein zentrales Element im Fehler- und Bestätigungsmanagement und wird insbesondere in Prozessen wie Lieferantenwechsel, Stammdatenänderungen oder Abrechnungsdaten eingesetzt.


1. Anwendungsbereiche der APERAK im BDEW/DVGW-Kontext

Die APERAK wird in folgenden Szenarien verwendet:

  • Fehlerrückmeldung bei syntaktischen oder inhaltlichen Fehlern in empfangenen Nachrichten (z. B. UTILMD, MSCONS, INVOIC).
  • Bestätigung des Empfangs einer Nachricht (z. B. bei ORDERS, ORDCHG).
  • Statusmeldungen zu laufenden Prozessen (z. B. Bearbeitungsstatus einer UTILMD-Änderung).
  • Rückweisung von Nachrichten bei formalen oder fachlichen Mängeln.

Die APERAK ist kein Ersatz für eine korrekte Nachricht, sondern dient der Kommunikation von Fehlern oder Bestätigungen, um eine Nachbesserung oder Klärung zu ermöglichen.


2. Struktur und Aufbau der APERAK nach BDEW/DVGW

Die APERAK folgt dem EDIFACT-Standard (UN/EDIFACT D.21B) und ist in Segmente unterteilt. Die wichtigsten Segmente im BDEW/DVGW-Kontext sind:

Segment Bedeutung Beispiel (BDEW/DVGW-spezifisch)
UNH Nachrichtenkopf (Message Header) UNH+1+APERAK:D:21B:UN'
BGM Beginn der Nachricht (Beginning of Message) BGM+23+REF12345+9' (23 = Fehlerrückmeldung, 9 = Originalnachricht wurde abgelehnt)
DTM Datum/Zeit der APERAK DTM+137:20240515:102' (Erstellungsdatum)
RFF Referenz auf die ursprüngliche Nachricht RFF+ACW:MSG4711' (Referenz auf die ursprüngliche UTILMD-Nachricht)
ERC Fehlercode (Error Code) ERC+1+10' (1 = Syntaxfehler, 10 = Ungültiges Format)
FTX Freitext zur Fehlerbeschreibung FTX+AAI+++Fehlendes Pflichtsegment: NAD+MS'
UNT Nachrichtenende (Message Trailer) UNT+8+1'

Wichtige BDEW/DVGW-spezifische Anpassungen:

  • Fehlercodes (ERC-Segment): Die BDEW/DVGW-Standards definieren eigene Fehlerkategorien, die über die allgemeinen EDIFACT-Codes hinausgehen. Beispiele:

    • ERC+1+20 → "Ungültiger Marktpartner" (z. B. falsche ILN im NAD-Segment)
    • ERC+1+30 → "Fachlicher Fehler in UTILMD" (z. B. falsche Zählpunktbezeichnung)
    • ERC+2+5 → "Nachricht erfolgreich verarbeitet" (Bestätigung)
  • Referenzierung (RFF-Segment): Die APERAK muss eindeutig auf die ursprüngliche Nachricht verweisen, z. B. über:

    • Nachrichtenreferenz (RFF+ACW) → z. B. RFF+ACW:UTILMD12345
    • Transaktionsreferenz (RFF+ON) → bei Bestellungen (ORDERS)
  • Statuscodes (BGM-Segment): Die BGM-Qualifier geben Auskunft über die Art der APERAK:

    • BGM+23 → Fehlerrückmeldung (Ablehnung)
    • BGM+24 → Bestätigung (Erfolgreiche Verarbeitung)
    • BGM+25 → Warnung (Nachricht wurde mit Einschränkungen verarbeitet)

3. Konkrete Anwendung: Schritt-für-Schritt-Anleitung

Schritt 1: Fehleridentifikation in der empfangenen Nachricht

Bevor eine APERAK gesendet wird, muss der Fehler analysiert werden. Typische Fehlerquellen im BDEW/DVGW-Umfeld sind:

  • Syntaktische Fehler:
    • Fehlende Pflichtsegmente (z. B. NAD+MS in UTILMD)
    • Ungültige Codes (z. B. falsche CUX-Währung in INVOIC)
  • Fachliche Fehler:
    • Ungültige Zählpunktbezeichnung in UTILMD
    • Widersprüchliche Daten in MSCONS (z. B. falsche Verbrauchszeiträume)
  • Prozessuale Fehler:
    • Nachricht wurde außerhalb der vereinbarten Fristen gesendet
    • Fehlende Berechtigung des Absenders

Schritt 2: APERAK generieren

Die APERAK sollte so präzise wie möglich sein, um eine schnelle Korrektur zu ermöglichen. Beispiel für eine Ablehnung einer UTILMD-Nachricht wegen eines fehlenden Segments:

UNH+1+APERAK:D:21B:UN'
BGM+23+UTILMD56789+9'
DTM+137:20240515:102'
RFF+ACW:UTILMD56789'
ERC+1+10'
FTX+AAI+++Fehlendes Pflichtsegment: NAD+MS (Marktlokation)'
UNT+6+1'

Schritt 3: APERAK versenden

  • Die APERAK muss innerhalb der vereinbarten Fristen (i. d. R. 2–5 Werktage) versendet werden.
  • Sie wird an den Absender der ursprünglichen Nachricht gesendet (Adresse aus dem NAD+MS-Segment der Originalnachricht).
  • Bei kritischen Fehlern (z. B. falsche Stammdaten) sollte zusätzlich eine manuelle Klärung per E-Mail oder Telefon erfolgen.

Schritt 4: Reaktion auf die APERAK

  • Der Empfänger der APERAK muss die Fehlerursache beheben und eine korrigierte Nachricht senden.
  • Bei Bestätigungen (BGM+24) kann der Prozess fortgesetzt werden.
  • Bei Warnungen (BGM+25) ist zu prüfen, ob die Nachricht trotz Einschränkungen akzeptiert wird.

4. Besonderheiten und häufige Fehlerquellen

a) BDEW/DVGW-spezifische Anforderungen

  • Verwendung von BDEW/DVGW-Codes: Die Fehlercodes im ERC-Segment müssen den BDEW/DVGW-Vorgaben entsprechen. Allgemeine EDIFACT-Codes reichen nicht aus.
  • Referenzierung auf Marktprozesse: In UTILMD-Prozessen muss die APERAK explizit auf den Zählpunkt (OBIS-Kennzahl) oder die Marktlokation verweisen.
  • Zeitkritische Prozesse: Bei Lieferantenwechseln (GPKE) oder Stammdatenänderungen muss die APERAK innerhalb von 2 Werktagen erfolgen, um Fristen einzuhalten.

b) Typische Fehler in der APERAK-Anwendung

Fehler Auswirkung Lösung
Unklare Fehlerbeschreibung (FTX) Empfänger kann den Fehler nicht nachvollziehen. Präzise Formulierung, z. B. "Fehlendes Segment: NAD+MS (ILN 9900123456789)"
Falsche Referenzierung (RFF) APERAK bezieht sich auf die falsche Nachricht. Doppelte Prüfung der Nachrichten-ID (z. B. RFF+ACW:UTILMD12345).
Fehlende BDEW/DVGW-Codes Empfänger erkennt den Fehler nicht als BDEW/DVGW-spezifisch. Verwendung der offiziellen Fehlercodes (z. B. ERC+1+20 für ungültigen Marktpartner).
Verspätete APERAK Prozessverzögerungen, ggf. Vertragsstrafen. Automatisierte Überwachung der Fristen.

c) Automatisierung und Tools

  • EDI-Konverter (z. B. Seeburger, Lobster, ecosio) können APERAK-Nachrichten automatisch generieren, wenn Fehler erkannt werden.
  • Validierungstools (z. B. BDEW-Validator) prüfen Nachrichten vor dem Versand auf BDEW/DVGW-Konformität.
  • Monitoring-Systeme sollten APERAK-Nachrichten protokollieren, um Nachweise für Audits zu haben.

5. Rechtliche und vertragliche Rahmenbedingungen

  • Die BDEW/DVGW-Standards (z. B. GPKE, GeLi Gas, WiM) definieren verbindliche Regeln für die APERAK-Anwendung.
  • Vertragliche Vereinbarungen (z. B. EDI-Rahmenverträge) können zusätzliche Anforderungen stellen, z. B.:
    • Maximale Bearbeitungszeiten für APERAK
    • Eskalationswege bei wiederholten Fehlern
  • Dokumentationspflicht: APERAK-Nachrichten müssen mindestens 10 Jahre archiviert werden (gemäß GoBD).

6. Fazit und Handlungsempfehlungen

Die APERAK ist ein zentrales Steuerungsinstrument in der EDI-Kommunikation nach BDEW/DVGW-Standards. Um eine reibungslose Anwendung zu gewährleisten, sollten folgende Punkte beachtet werden:

Präzise Fehlerbeschreibung:

  • Klare Benennung des Fehlers (Segment, Feld, Wert).
  • Verwendung der BDEW/DVGW-spezifischen Fehlercodes.

Einhaltung von Fristen:

  • APERAK innerhalb von 2–5 Werktagen versenden.
  • Bei kritischen Prozessen (z. B. Lieferantenwechsel) sofort reagieren.

Automatisierung nutzen:

  • EDI-Tools zur automatischen Fehlererkennung und APERAK-Generierung einsetzen.
  • Monitoring-Systeme für eine lückenlose Dokumentation.

Manuelle Nachkontrolle:

  • Bei komplexen Fehlern zusätzlich per E-Mail oder Telefon kommunizieren.
  • Testphasen vor Produktivsetzung nutzen, um APERAK-Prozesse zu validieren.

Durch die konsequente Anwendung der APERAK können Prozessstörungen minimiert, Datenqualität verbessert und rechtliche Risiken reduziert werden.