Prozessdokumente im System

Kurzantwort

Ein Prozessdokument ist der Behälter für einen Marktvorgang. Es hält fest, welcher Marktprozess läuft, welche Marktpartner und Objekte beteiligt sind und welche Nachrichten ausgetauscht wurden. SAP beschreibt es als zentrales Überwachungsobjekt, das alle Schritte eines Prozesses steuert und dokumentiert. Jeder Prozessschritt eines Vorgangs hinterlässt darin einen nachprüfbaren Zustand mit Nachricht und Zeitbezug. Der Bearbeitungsstand ist damit aus dem System heraus belegbar und nicht nur aus dem Gedächtnis der Sachbearbeitung.

Warum drei Ebenen getrennt bleiben

In der Praxis werden drei Dinge ständig vermischt. Trenne sie bewusst:

1. Transport: Wie die Datei das Haus verlässt oder erreicht. Hier zählen Übertragungsweg, Dateiname, IDoc oder Nachrichtenordner.
2. Fachliche Nachricht: Was in der EDIFACT-Datei steht. Hier zählen Prüfidentifikator und Anwendungshandbuch.
3. Prozess: Welcher Vorgang mit welchem Status und welcher Frist daraus wird.

Ein grüner Transportstatus beweist keinen fachlichen Erfolg. Die SAP-Dokumentation führt für Marktnachrichten eine eigene Geschäftssicht. Sie kennt Zustände wie „Positive CONTRL Sent” oder „APERAK Missing”. Der Zustand zeigt also nur den Nachrichtenweg. Market Communication for Utilities, Business Status of Market Messages

Deshalb braucht die Betriebsprüfung Status, Inhalt und Geschäftsobjekt zusammen.

Wie ein Vorgang entsteht

Das folgende Modell gilt für eingehende und ausgehende Marktnachrichten. Es stützt sich auf die Ablaufbeschreibungen der SAP-Anwendungshilfe und lässt sich auf jedes Format übertragen.

Ein neu eintreffender Vorgang beginnt mit der Anlage eines Prozessdokuments. Die SAP-Anwendungshilfe beschreibt diesen Schritt für den Lieferbeginn: Der Verteilnetzbetreiber empfängt eine Anmeldeanfrage, das System legt ein neues Prozessdokument an und prüft Stammdaten und Geschäftsdaten über das Prüf-Framework. Schlägt die Eingangsvalidierung fehl, geht eine Ablehnungsnachricht an den neuen Lieferanten zurück. Intercompany Data Exchange, Prozess Lieferbeginnprozess

Ordne jeder Station eine prüfbare Information zu:

Der Unterschied zwischen „initial” und „Folgeprozess” hängt am Objekt. Für Geschäftsdatenanfragen unterscheidet die Anwendungshilfe einen initialen Prozess, bei dem der Zählpunkt bekannt, im System aber noch nicht vorhanden ist, von einem Folgeprozess, bei dem für den Zählpunkt bereits ein Service existiert. Intercompany Data Exchange, Prozess

Das Bindeglied im Diagramm

Vereinfachtes Beispiel: Lieferbeginn für eine Einspeisung

Das Beispiel folgt dem Lieferbeginn (Einspeisung) aus der SAP-Anwendungshilfe. Alle Kennungen sind erfunden.

1. Eine Anmeldeanfrage erreicht den Verteilnetzbetreiber. Der Transport meldet Erfolg. Das System legt ein neues Prozessdokument an.
2. Das Prü-Framework prüft Stammdaten und Geschäftsdaten. Schlägt die Eingangsvalidierung fehl, geht eine Anmeldeablehnung an den neuen Lieferanten.
3. Der Vorgang hängt am Objekt: Marktlokation DE0001234567890000000000000012345, Lieferrichtung Einspeisung, gewünschtes Lieferbeginndatum 1. Oktober.
4. Das System prüft die Verfügbarkeit des Zählpunkts. Dazu kommen die Belieferungssituation am Lieferbeginndatum und die Tranchenverfügbarkeit.
5. Der Vorgang trägt eine Frist. In der Fachwelt heißt sie Vorlauffrist. Ein Terminschritt im Prozessdokument hält fest, bis wann der Eingang verarbeitet sein muss.
6. Die Bestätigung geht hinaus. Der Status wechselt, die Antwortnachricht wird am Vorgang dokumentiert. Der Vorgang schließt, oder er landet als Klärfall bei einem Verantwortlichen.

Der GPKE-Use-Case Lieferbeginn beschreibt dasselbe Ziel fachlich: Der Lieferant ist der Marktlokation oder Tranche zugeordnet, und der Netzbetreiber beendet gegebenenfalls die Zuordnung des Altlieferanten. Als spätesten Übertragungstag für die Anmeldung bestimmt die Festlegung den Tag vor dem letzten Werktag vor dem Zuordnungsbeginn. GPKE Teil 2, Use-Case Lieferbeginn

Fristen, Wiedervorlagen und Klärfälle

Fristenüberwachung funktioniert nur, wenn der Vorgang das Datum kennt. Im IS-U-Umfeld sind Fristen ein eigener Schritttyp. Ein Termin wird definiert, und der Prozess wartet auf den Ablauf der Frist, bevor er weiterläuft. Fristen lassen sich im Customizing pflegen. Common Layer: Prozesse im IS-U konfigurieren

Dasselbe Prozessdokument trägt auch die Fehlerspur. Es zeigt technische und betriebswirtschaftliche Ausnahmen und ein Protokoll, und es erlaubt, Nachrichten zu einem Vorgang abzurufen. Process and Data-Exchange Framework for Utilities, Abschnitt Prozessdokument

Daraus folgt der praktische Nutzen. Prozessmonitoring, Wiedervorlagen und Klärfalllisten lesen denselben Vorgang. Fehlt der Objektbezug, findet keine Wiedervorlage ihr Ziel. Entsteht ein doppelter Vorgang, arbeiten zwei Bearbeiter an einer Marktlokation und überschreiben sich gegenseitig.

Folgen und Fehlerfälle

Nachricht kommt an, kein Objektbezug. Der Transport ist grün, der Vorgang entsteht, aber die Marktlokation lässt sich nicht eindeutig identifizieren. Der Vorgang treibt in der Fristenliste mit, ohne dass jemand ihn bearbeiten kann. Die GPKE verlangt, dass der Netzbetreiber unverzüglich prüft, ob sich die Marktlokation anhand der mitgeteilten Daten eindeutig identifizieren lässt. Genau diese Prüfung fehlt hier.

Antwort verlässt das Haus nicht. Der Vorgang steht auf „Antwort erzeugt”, die Ausgangsnachricht hängt aber im Versand. Für den Partner läuft die Frist weiter. Ohne Verbindung von Vorgangsstatus und Ausgangsmonitor bleibt das unsichtbar.

Doppelter Vorgang beim erneuten Eingang. Sendet der Partner dieselbe Nachricht noch einmal, entsteht ohne Erkennungslogik ein zweiter Vorgang zur selben Marktlokation. Zwei Fristen, zwei Antworten, ein Objekt.

Status von Hand gesetzt. Ein Bearbeiter setzt den Vorgang auf „erledigt”, obwohl keine Antwortnachricht hinausging. Der Status widerspricht der Nachrichtenlage. Solche Einträge zerstören jede Auswertung, weil Monitoring und Wirklichkeit auseinanderlaufen. Die Geschäftssicht der Marktnachrichten führt deshalb eigene Zustände nur für den Nachrichtenweg, etwa für CONTRL- und APERAK-Prüfungen.

Typische Missverständnisse

„IDoc und Prozessdokument sind dasselbe.“ Nein. Das IDoc ist ein Transportbehälter für Daten. Das Prozessdokument beschreibt den Geschäftsvorgang mit Schritten, Verantwortlichkeiten und Ausnahmen. Ein Vorgang kann mehrere IDocs berühren.

„Ein Prozessdokument ist ein Ticket.“ Ein Ticket sammelt eine Anfrage und ihre Bearbeitung. Ein Prozessdokument bildet den Ablauf nach den Regeln des Marktprozesses ab. Der Prozess bestimmt die Schritte, nicht der Bearbeiter.

„Die Nachricht ist der Vorgang.“ Die Nachricht ist ein Beleg innerhalb des Vorgangs. Es können mehrere sein. Anmeldung, Ablehnung und erneute Anmeldung hängen oft am selben Vorgang.

„Ein Statuswechsel ist eine fachliche Entscheidung.“ Der Status dokumentiert einen erreichten Punkt. Die fachliche Entscheidung fällt im Prüf- oder Bearbeitungsschritt davor. Wer beides gleichsetzt, deutet Stillstand als Fortschritt.

Für die Konfiguration gilt eine Einschränkung. Projekt- und Releaseabhängig unterscheiden sich Objektnamen, Prozessschrittklassen und Transaktionen. Prüfe die konkrete Ausprägung immer am System und an der gültigen Prozessdokumentation des Verbunds.

Quellen und Pflegehinweis

Die tragenden Aussagen stammen aus der SAP-Anwendungshilfe und dem Benutzerhandbuch zum Process and Data-Exchange Framework, aus der Geschäftssicht der Marktnachrichten sowie aus der GPKE-Festlegung der Bundesnetzagentur. Ergänzend dient ein Fachbeitrag zur Prozesskonfiguration im IS-U als Einstieg in die Customizing-Sicht.

Prozessdefinitionen und Formate ändern sich unabhängig voneinander. Vor einer Implementierung prüfe die gültige Festlegung, das aktuelle Anwendungshandbuch und die Prozesskonfiguration des eigenen Systems. Der Beitrag beschreibt das Modell, nicht die Ausprägung einer konkreten Installation. Geprüft am 11. September 2026.