Auf dieser Seite 10 Abschnitte
Kurzantwort
CONTRL und APERAK sind Rückmeldungen im EDIFACT-Umfeld, arbeiten aber auf verschiedenen Ebenen. CONTRL quittiert die Syntax und Übertragung einer Datei. APERAK meldet, ob eine Nachricht auf Anwendungsebene verarbeitet werden kann. Beide sind keine Geschäftsnachrichten im engeren Sinn, sondern begleiten den Austausch.
Eine positive CONTRL bedeutet: Die Datei ist syntaktisch angenommen. Eine positive APERAK bedeutet: Die Nachricht kann fachlich verarbeitet werden. Ob der Geschäftsprozess erfolgreich abgeschlossen ist, beantwortet erst die Geschäftsantwort im jeweiligen Prozess.
Diese Abstufung prägt auch die Fehlerbehandlung in den Systemen. Wer die Ebenen kennt, ordnet jede Störung der richtigen Stelle zu und vermeidet unnötige Klärfälle. Der Artikel führt die Ebenen aus und zeigt, worauf SAP-IS-U-Projekte bei der Verarbeitung achten sollten.
Der Transport über AS4 bestätigt die Zustellung auf der Übertragungsebene. Damit ist noch nichts über den Inhalt gesagt.
CONTRL meldet, ob die Datei syntaktisch angenommen wurde. Eine positive CONTRL quittiert den Austausch; eine negative verweist auf die fehlerhaften Segmente.
APERAK meldet, ob die Nachricht auf Anwendungsebene verarbeitet werden kann. Die Anerkennungsmeldung als positive APERAK bestätigt die fachliche Annahme.
Erst die Geschäftsantwort im jeweiligen Prozess, etwa die Bestätigung oder Ablehnung eines Lieferbeginns, beendet den fachlichen Vorgang.
Warum es mehrere Rückmeldungsebenen gibt
Eine Nachricht durchläuft auf ihrem Weg mehrere Prüfungen. Zuerst muss die Übertragung gelingen, dann die Syntax stimmen, dann die fachliche Verarbeitung möglich sein, und zuletzt muss der Geschäftsprozess ein Ergebnis liefern. Jede dieser Stufen kann scheitern, und jede braucht eine eigene Rückmeldung.
Würde eine einzige Rückmeldung alle Stufen abdecken, bliebe unklar, wo ein Fehler liegt. Eine Nachricht, die syntaktisch fehlerhaft ist, kann nicht fachlich geprüft werden. Eine Nachricht, die fachlich nicht verarbeitbar ist, kann trotzdem syntaktisch korrekt sein. Die Trennung der Ebenen macht Fehler lokalisierbar und beschleunigt die Klärung.
Für die Systeme bedeutet das: Jede Ebene braucht eigene Prüfungen und eigene Status. Wer Syntaxfehler und fachliche Fehler in einen Topf wirft, kann nicht steuern, welche Rückmeldung an den Sender geht. Die Marktkommunikation löst das über die getrennten Rückmeldungstypen CONTRL und APERAK.
Die Trennung erleichtert auch die Kommunikation zwischen den Marktpartnern. Ein Sender, der eine negative APERAK erhält, weiß, dass seine Nachricht angekommen und syntaktisch in Ordnung war. Das Problem liegt in der fachlichen Verarbeitung. Diese klare Zuordnung spart Zeit, weil sie die Fehlersuche auf die richtige Ebene lenkt.
CONTRL: die technische Rückmeldung
CONTRL arbeitet auf der Ebene der Syntax und Übertragung. Der Empfänger sendet CONTRL, um zu quittieren, dass er eine Übertragungsdatei erhalten und syntaktisch geprüft hat. Eine positive CONTRL bestätigt die Annahme der Datei. Eine negative CONTRL verweist auf die fehlerhaften Segmente.
Die Besonderheit von CONTRL liegt in ihrem Bezug. Sie bezieht sich auf die Übertragungsdatei, nicht auf einzelne Geschäftsvorfälle. CONTRL ist damit keine Geschäftsnachricht und enthält keine Geschäftsvorfälle. In den allgemeinen Festlegungen der Marktkommunikation wird CONTRL ausdrücklich als Rückmeldung zur Syntax beziehungsweise zum Austausch eingeordnet. Allgemeine Festlegungen
Für den Betrieb heißt das: Eine fehlende oder negative CONTRL zeigt ein Übertragungs- oder Syntaxproblem. Die Ursache liegt in der Datei, nicht im Geschäftsvorfall. Wer bei einer negativen CONTRL den Prozess prüft, sucht am falschen Ort.
In der deutschen Marktkommunikation ist der Versand von CONTRL fest eingeplant. Die Bundesnetzagentur hat festgelegt, dass der Empfänger eine CONTRL sendet, und das Bestätigungsfeld im UNB-Segment wird entsprechend nicht genutzt. Allgemeine Festlegungen Diese Festlegung macht die Rückmeldung planbar: Jeder Sender darf eine CONTRL erwarten und muss ihre Verarbeitung vorsehen.
APERAK: die Anwendungsrückmeldung
APERAK arbeitet auf der Ebene der Anwendung. Der Empfänger sendet APERAK, um zu melden, ob er eine Nachricht verarbeiten kann. Eine positive APERAK bestätigt die Annahme zur Verarbeitung, eine negative APERAK meldet, dass die Nachricht auf Anwendungsebene nicht verarbeitbar ist.
APERAK kann sich auf mehrere fehlerhafte Geschäftsvorfälle einer Übertragungsdatei beziehen. Auch APERAK ist keine Geschäftsnachricht im engeren Sinn, sondern eine Rückmeldung zur Verarbeitbarkeit. Die fachlichen Gründe für eine Ablehnung, etwa eine unbekannte Marktlokation oder ein unzulässiger Zeitpunkt, werden in der APERAK referenziert.
Mit dem Lieferantenwechsel in 24 Stunden hat die positive APERAK an Bedeutung gewonnen. Die Branche führt die Anerkennungsmeldung ein, mit der der Empfänger die fachliche Annahme einer Nachricht bestätigt. Diese Anerkennung ist ein wichtiges Signal im engen Zeitraster des 24-Stunden-Prozesses, weil sie dem Sender früh zeigt, dass seine Nachricht zur Bearbeitung angenommen wurde. adesso business consulting
Die Unterscheidung zwischen Anerkennung und Ergebnis bleibt dabei bestehen. Die Anerkennungsmeldung sagt: Wir haben die Nachricht angenommen und verarbeiten sie. Das Ergebnis des Prozesses, etwa die bestätigte Zuordnung, folgt in der Geschäftsantwort. Wer die Anerkennung als Abschluss behandelt, startet seine Folgeprozesse zu früh.
Die Geschäftsantwort als letzte Stufe
Die eigentliche Entscheidung über einen Geschäftsvorfall fällt in der Geschäftsantwort. CONTRL und APERAK bereiten sie nur vor. Sie ist Teil des jeweiligen Prozesses und wird in der dafür vorgesehenen Nachricht transportiert. Ein Netzbetreiber bestätigt oder lehnt einen Lieferbeginn über die prozessspezifische Antwort ab.
Die Geschäftsantwort trägt das fachliche Ergebnis: die Zuordnung wurde bestätigt, die Stammdatenänderung wurde abgelehnt, der Messstellenbetrieb wurde beendet. Dieses Ergebnis löst die Folgeprozesse aus. CONTRL und APERAK sagen dagegen nur, dass die Kommunikation funktioniert und die Nachricht angenommen wurde.
Für Projekte ist diese Kette entscheidend. Ein Vorgang ist erst abgeschlossen, wenn die Geschäftsantwort vorliegt und die Folgeprozesse ausgelöst sind. Wer den Status eines Vorgangs an CONTRL oder APERAK festmacht, beendet Prozesse zu früh und erzeugt Folgefehler.
Die Geschäftsantwort kann ihrerseits mehrere Ausprägungen haben. Sie kann einen Vorgang bestätigen, ablehnen oder eine Zwischeninformation liefern. Auch hier gilt: Die Form der Antwort hängt vom Prozess ab, nicht vom Nachrichtentyp. Ein und dieselbe Antwortnachricht kann je nach Prüfidentifikator unterschiedliche Ergebnisse transportieren. Die Prozessbeschreibung bleibt damit die maßgebliche Referenz.
Fristen und Überwachung
Die Rückmeldungen unterliegen Fristen. Der Empfänger muss CONTRL und APERAK innerhalb der vorgesehenen Zeit senden, damit der Sender seinen Prozess fortsetzen kann. Im 24-Stunden-Lieferantenwechsel sind diese Fristen besonders eng, weil der gesamte Vorgang innerhalb eines Werktags abgeschlossen sein muss. Die konkreten Fristen und die Fehlercodes, mit denen eine Rückmeldung ablehnt, stehen in Fehlercodes in der Marktkommunikation auswerten.
Die Überwachung der Rückmeldungen ist eine Aufgabe des Betriebs. Ein Sender, der keine CONTRL erhält, weiß nicht, ob seine Datei angekommen ist. Ein Sender, der keine APERAK erhält, weiß nicht, ob seine Nachricht verarbeitet werden kann. Monitoring-Systeme müssen diese Lücken sichtbar machen und offene Rückmeldungen nachführen.
Praktisch heißt das: Jede ausgehende Nachricht braucht einen erwarteten Rückmeldungspfad. Wer eine UTILMD sendet, erwartet CONTRL, anschließend APERAK und schließlich die Geschäftsantwort. Bleibt eine dieser Stufen aus, entsteht ein Überwachungsfall. Das System sollte die Fristen je Stufe kennen und Verspätungen melden, statt still darauf zu warten.
Für SAP-IS-U-Systeme heißt das: Der Status einer ausgehenden Nachricht durchläuft mehrere Zustände. Versendet, technisch quittiert, fachlich angenommen, Geschäftsantwort erhalten. Jeder Zustand ist dokumentationspflichtig und steuerbar. Wer diese Zustände nicht führt, kann weder Fristen noch Klärfälle beherrschen.
Bedeutung für SAP IS-U
In SAP-IS-U-Landschaften werden eingehende und ausgehende Nachrichten überwacht. Die Rückmeldungen CONTRL und APERAK müssen den zugehörigen Nachrichten zugeordnet und ausgewertet werden. Eine positive CONTRL setzt den Status der Übertragung auf quittiert, eine positive APERAK den Status der Verarbeitung auf angenommen.
Die Herausforderung liegt in der automatisierten Reaktion. Nicht jede Rückmeldung erfordert eine Aktion. Eine positive APERAK bestätigt die Verarbeitung, eine negative APERAK erfordert eine Klärung. Das System muss unterscheiden, welche Rückmeldung nur dokumentiert und welche eine Bearbeitung auslöst.
Dazu kommt die Testpraxis. Wer die Rückmeldungslogik testen will, muss sowohl positive als auch negative Fälle abdecken. Ein Test, der nur den Erfolgsweg prüft, übersieht, wie das System mit Ablehnungen umgeht. Die Fehlerbehandlung gehört in die Tests, nicht in den Betrieb.
Ein belastbarer Test deckt außerdem die Zuordnung der Rückmeldungen ab. Eine CONTRL bezieht sich auf eine Übertragungsdatei, eine APERAK auf Nachrichten innerhalb der Datei, eine Geschäftsantwort auf einen einzelnen Vorgang. Das System muss diese Bezüge auflösen und die richtige Ebene fortschreiben. Wer die Bezüge nicht testet, verliert bei vielen parallelen Vorgängen den Überblick.
Praxisbeispiel: Eine abgelehnte Anmeldung nachvollziehen
Ein Lieferant sendet eine Anmeldung zum Lieferbeginn. Der Netzbetreiber empfängt die Datei und sendet eine positive CONTRL. Bei der fachlichen Prüfung stellt er fest, dass die Marktlokation nicht in seinem Netz liegt. Er sendet eine negative APERAK, die den Grund referenziert.
Der Lieferant erhält die Rückmeldung und ordnet sie der Anmeldung zu. Die negative APERAK zeigt ihm, dass die Nachricht nicht verarbeitet werden konnte. Die eigentliche Ablehnung des Lieferbeginns folgt in der Geschäftsantwort, die den Sachverhalt im Detail erläutert. Erst jetzt beginnt die Klärung zwischen den Partnern.
Im Beispiel zeigt sich die Arbeitsteilung: CONTRL bestätigt den Empfang, APERAK die Verarbeitbarkeit, die Geschäftsantwort das Ergebnis. Wer die Ebenen verwechselt, interpretiert eine technische Quittung als fachliche Bestätigung.
Diese Arbeitsteilung prägt auch die Dokumentation in den Systemen. Zu jedem Vorgang gehört die Kette seiner Rückmeldungen: wann die Datei ankam, wann die Syntax bestätigt wurde, wann die Anwendung die Nachricht annahm und wann das Geschäftsergebnis eintraf. Diese Kette macht später nachvollziehbar, warum ein Vorgang zu einem bestimmten Zeitpunkt in einem bestimmten Zustand war.
Typische Missverständnisse
„CONTRL positiv heißt: fachlich verarbeitet.“
Nein. CONTRL quittiert nur Syntax und Übertragung. Die fachliche Verarbeitung bestätigt APERAK oder die Geschäftsantwort.
„APERAK ist die Geschäftsantwort.“
Nein. APERAK meldet die Verarbeitbarkeit auf Anwendungsebene. Das fachliche Ergebnis liefert die Geschäftsantwort im Prozess.
„Eine negative APERAK ist ein technischer Fehler.“
Nein. Eine negative APERAK zeigt ein fachliches Verarbeitungsproblem, etwa eine unbekannte Marktlokation.
„Ohne Rückmeldung ist die Nachricht verloren.“
Nicht zwingend. Fehlende Rückmeldungen sind ein Überwachungsfall: Der Empfänger kann die Nachricht empfangen haben, ohne die Antwort zu senden.
„CONTRL und APERAK sind Geschäftsnachrichten.“
Nein. Beide sind Rückmeldungen und enthalten keine eigenen Geschäftsvorfälle.
Quellen und Pflegehinweis
Die Regeln zu CONTRL und APERAK stehen in den allgemeinen Festlegungen und den Anwendungshandbüchern von EDI@Energy. Die Einführung der Anerkennungsmeldung hängt mit dem Lieferantenwechsel in 24 Stunden zusammen. Wegen laufender Formatänderungen die gültigen Versionen und AHB-Stände prüfen.
- Bundesnetzagentur: Allgemeine Festlegungen zu den EDIFACT- und XML-Nachrichten
- EDI@Energy: Anwendungshandbücher zu CONTRL und APERAK
- Bundesnetzagentur: Lieferantenwechsel 24h (BK6-22-024)
- adesso: Der 24-Stunden-Lieferantenwechsel
- Bundesnetzagentur: Gemeinsame Mitteilungen zu Datenformaten
Abrufdatum aller Quellen: 7. September 2026.
Primärquellen zum Nachlesen
- Bundesnetzagentur – Allgemeine Festlegungen zu den EDIFACT- und XML-Nachrichtenbundesnetzagentur.de
- EDI@Energy – Anwendungshandbücher zu CONTRL und APERAKedi-energy.de
- Bundesnetzagentur – Lieferantenwechsel 24h (BK6-22-024)bundesnetzagentur.de
- adesso business consulting – Der 24-Stunden-Lieferantenwechselblog.adesso-bc.com
- Bundesnetzagentur – Gemeinsame Mitteilungen zu Datenformatenbundesnetzagentur.de
