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)
- Nachrichtenreferenz (RFF+ACW) → z. B.
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+MSin UTILMD) - Ungültige Codes (z. B. falsche
CUX-Währung in INVOIC)
- Fehlende Pflichtsegmente (z. B.
- 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.