2. Oktober 2024

Common Layer: Prozesse im IS-U konfigurieren

In der dynamischen Welt der Energieversorgung spielt die Prozessautomatisierung eine entscheidende Rolle, um Effizienz und Genauigkeit in der Marktkommunikation zu gewährleisten. Ein zentraler Bestandteil dieses Systems ist der Common Layer im IS-U, der nicht nur automatische Prozessabläufe sicherstellt, sondern auch einen reibungslosen Datenaustausch und eine nahtlose Datenverarbeitung zwischen den Marktpartnern ermöglicht.  

In diesem Artikel werfen wir einen Blick darauf, kundeneigene Prozesse zu konfigurieren und wie man gezielt in Prozessabläufe eingreifen kann. 

Prozessdokumente oder wie wir sie nennen: PDocs 

Prozesse werden über die Prozessdokumente verfolgt. Ein Prozessdokument beschreibt und dokumentiert den Ablauf der Geschäftsprozesse in Versorgungsunternehmen. Es dient als Leitfaden oder Vorlage, um den genauen Ablauf eines Prozesses, einschließlich der beteiligten Schritte, Verantwortlichkeiten und Systemeinstellungen festzuhalten. 

Alle Informationen des PDocs werden in diversen Tabellen gespeichert, die als Reiter auftauchen. Die Prozessreferenz ist hierfür der Primary Key. Es gibt schrittabhängige und schrittunabhängige Daten, die je nach Stand des Prozessfortschritts gefüllt und ermittelt werden. 

Zur Überwachung der PDocs wird die Transaktion /IDXGC/PDOCMON01 verwendet. 

Abb. 1: Prozessdokument Kopfdaten

Unterhalb der Kopfdaten lassen sich über diverse Reiter weitere Prozessinformationen anzeigen:

Abb. 2: Reiter Prozessdokumente (Tabelle)
Abb. 3: PDoc Schrittdaten 

Prozess Customizing 

Prozesse werden über das Customizing mandantenabhängig im System angelegt. Dies kann über die Transaktion SPRO ( Unternehmensübergreifender Datenaustausch -> Marktprozessmanagement für Versorgungsunternehmen -> Prozesskonfiguration -> Prozesskonfiguration definieren ) durchgeführt werden oder über die Viewclusterpflege SM34 ( /IDXGC/VC_PROC ).  

1. Prozesskonfiguration

Tabelle: /IDXGC/PROC

Abb. 4: Prozesskonfiguration Tabelle: /IDXGC/PROC

 Die oberste Ebene ist die Prozesskonfiguration mit grundlegenden Informationen, die den gesamten Prozess definieren.

  • Für eine eindeutige Identifikation des Prozesses ist es notwendig, eine Prozess-ID zu vergeben. Die Prozess-ID dient als Schlüssel zur Zuordnung aller relevanten Informationen und Schritte innerhalb des Prozesses. 
  • Obligatorische Parameter sind die Prozessklasse, die vom Framework zur Verfügung gestellt wird und die Prüfanwendung. Diese geben dem Prozess einen Rahmen und sorgen für die Prozessierung durch das entsprechende Prüfframework sowie die Erstellung des PDocs.
  • Die Quelle wird bei manueller Anlage immer auf C Kunde gesetzt. Dies führt dazu, dass bei SAP-Auslieferungen keine Eigenimplementierung überschrieben wird. Dies gilt für alle Ebenen der Prozesskonfiguration.

2. Prozessversion

Tabelle: /IDXGC/PROCVERS

Abb. 5: Prozessversion Tabelle: /IDXGC/PROCVERS

Die Prozessversion dient in erster Linie dazu, neue Versionen eines Prozesses anzulegen, ohne alte Konfigurationen zu überschreiben. Dies ist besonders hilfreich bei gesetzlich bedingten Änderungen im Prozessablauf, wie etwa Formatwechsel.   

  • In der Prozessversion wird festgelegt, welcher „Engine-Typ“ verwendet wird. Im Common Layer kommt die Process Engine zum Einsatz, der die alten Workflows mit Wechselbelegen ersetzt.  
  • Beim Ausführungsmodus kann zwischen Tiefen- und Breiten-Traversierung unterschieden werden. Traversierungen bestimmen den Algorithmus der Knotensuche und beeinflussen dadurch maßgeblich den Prozessablauf.  
  • Durch das Feld „Gültig ab“ wird die Gültigkeit der Version beschränkt. Es kann nur eine Version zu jedem Zeitpunkt gültig sein. 

3. Prozessschritte  

Tabelle: /IDXGC/PRSTEP 

  • Für jeden Prozessschritt müssen die Attribute Schrittnummer, Prozessschrittklasse, Schritttyp und -kategorie gepflegt werden. 
  • Über die Aktiv-Flag können Schritte aktiviert und deaktiviert werden. 
  • Die Schrittnummer legt die Reihenfolge der Prozessschritte fest. Sofern keine Bedingungen dies verhindern, werden die Schritte in aufsteigender Reihenfolge durchlaufen. 
  • Es gibt vier Prozessschrittkategorien: Start, Standard, Zweigende und Ende. Die Kategorie sowie die Ausführungsart können intuitiv ausgewählt werden. 
Abb. 6: Prozessschrittkategorie
Abb. 7: Prozessausführungsart
  • Die Schritttypen sowie die davon abhängige Prozessschrittklasse beeinflussen die Verarbeitung der Schrittdaten. Es gibt ausgelieferte Klassen, die durch Subklassen und Redefintionen der Methoden angepasst werden können.
Abb. 8: Übersicht Prozessschrittypen

CHECK Bestimmung des nächsten Schrittes

Dieser Prozessschritt wird zur Veränderung von Daten und bei Prüfungen verwendet, wenn der nächste auszuführende Schritt nicht allein durch eine lineare Reihenfolge bestimmt werden kann. Die Entscheidung über den nächsten Schritt erfolgt über den Aufruf des Prüf-Frameworks. Durch den Aufruf von Prüfmethoden können Werte abgefragt, ermittelt und aktualisiert und der Ablauf des Prozesses durch das Prüfungsergebnis beeinflusst werden.

DATA Datenanlage

Wie der Name bereits sagt, wird die Datenanlage für das Anlegen und Aktualisieren von Daten verwendet. Eingesetzt wird dieser Schritttyp im Rahmen des Versorgungsszenarios und zumeist im Initialisierungsschritt.

TRIGG Prozessauslöser

Wenn der Prozess einen weiteren Prozess auslösen soll, kann in einem Trigger Schritt der entsprechende Prozess mit ID, Konfiguration und Schrittnummer angegeben werden. Der Schritt erstellt automatisch eine Prozessverknüpfung der PDocs. 

DLINE Termin anlegen

In manchen Fällen gibt es Prozesschritte, die erst zu einem bestimmten Zeitpunkt starten sollen. Durch die Definition einer Frist kann ein Termin angelegt werden. Der Prozess wartet dann auf den Ablauf der Frist bevor er weiterläuft. Fristen können im Customizing definiert werden. 

INBND OTBND Nachrichten senden und empfangen

Nachrichten verarbeiten Ein- und Ausgangsnachrichten. Das erfolgt über Geschäftsnachrichtenschlüssel, die ein bestimmtes Format aufrufen, das aus den Daten der PDoc-Strukturen befüllt wird. Bei einer eingehenden Nachricht werden die Daten der Eingangsnachricht auf die PDoc-Strukturen übertragen.

4. Prozessschrittbedingungen 

Tabelle: /IDXGC/PRSTPCOND

  • Über Prozessschrittbedingungen kann die Abfolge der Schritte abhängig von dem Ausgang einzelner Schritte festgelegt werden. Dadurch wird der Prozessablauf aufgrund von Prüfergebnissen gesteuert. 
  • Durch die hinterlegten Bedingungen können Verzweigungen dargestellt und Schritte übersprungen werden. Ohne Vorbedingungen werden die Schritte dem Ausführungsmodus entsprechend durchlaufen.
  • Hinterlegt wird dafür die Schrittnummer des entsprechenden Prozesses sowie der Prozesswert oder Status des Schrittes (Prüfergebnis).
  • Die Verknüpfung mehrerer Bedingungen erfolgt über die Verknüpfungsspalte mit logischen Ausdrücken (z.B. OR oder AND).
Abb. 9: Prozessschrittbedingungen

Das Common Layer ist ein essenzieller Bestandteil der modernen Energieversorgung für die Konfiguration und Verwaltung von Prozessen im IS-U. Die strukturierte Nutzung der Prozessdokumente und die präzise Konfiguration der Prozessschritte gewährleisten, dass alle Abläufe reibungslos und gemäß den festgelegten Standards durchgeführt werden.

Ein wesentlicher Vorteil liegt in der Flexibilität bei der Erweiterung ausgelieferter Prozesse und der Möglichkeit eigene Prozesse zu implementieren. Diese Flexibilität ermöglicht es Versorgungsunternehmen, bestehende Prozesse anzupassen und zu erweitern, um spezifischen Anforderungen gerecht zu werden. So können Prozesse maßgeschneidert und an individuelle Unternehmensbedürfnisse angepasst werden, was zu einer höheren Automatisierung und damit zu einer Steigerung der Effizienz führt.

Die Prozessdokumente stellen sicher, dass die Prozesse überwacht und dokumentiert werden und bieten eine präzise Nachverfolgung sowie zielgerichtete Problemlösung im Prozessablauf.

Wenn Sie noch Fragen haben oder an einem Austausch zu diesem Thema interessiert sind, können Sie sich gerne mit mir in Verbindung setzen.

Diesen Beitrag teilen:

Themen und Schlagwörter:

Ein Beitrag von:

Carolina Stegherr

Carolina ist Associate Consultant im Bereich Utilities. Sie hat das Traineeprogramm mit dem Schwerpunkt Entwicklung durchlaufen und bringt in ihre Projekte sowohl technisches Know-how als auch fachliches Wissen ein.
Alle Beiträge von: Carolina Stegherr

Ähnliche Beiträge

Saubere Stammdaten für S/4 – mit dem adesso-Evaluierungstool

Saubere Stammdaten für S/4 – mit dem adesso-Evaluierungstool

Saubere Stammdaten erfolgreich nach SAP S/4HANA zu migrieren, erfordert wichtige Vorbereitungen. Die Kombination aus adesso active transformation-Vorgehensmodell und des CVI Q-Check-Tools liefert alle Inhalte, um mit sauberen Stammdaten und den notwendigen Aktivitäten ein ECC-System für die S/4-Umstellung optimal vorzubereiten.

Die Regulatorik der Marktkommunikation – was finde ich wo?

Die Regulatorik der Marktkommunikation – was finde ich wo?

Sich zum ersten Mal mit den Marktkommunikationsprozessen (Mako) der Energiewirtschaft zu beschäftigen und diese zu verstehen, kann eine Herausforderung sein. Es ist anfangs schwierig, die einzelnen Marktnachrichten und energiewirtschaftlichen Gesetzestexte zu lesen und die Zusammenhänge zu verstehen. 

Dieser Beitrag bietet einen Überblick darüber, welche energiewirtschaftlichen und regulatorischen Grundlagen für die Marktkommunikation zwischen den einzelnen Marktpartnern zu finden sind und wie sie zusammenhängen.

Neuerungen in der SAP S/4HANA Cloud Public Edition – eine Chance für die öffentliche Verwaltung

Neuerungen in der SAP S/4HANA Cloud Public Edition – eine Chance für die öffentliche Verwaltung

Für die SAP-Kunden des öffentlichen Sektors ist das Modul Public Sector Management (PSM) mit seinen Komponenten Haushaltsmanagement (PSM-FM) und Fördermittelmanagement (PSM-GM) die entscheidende Grundlage für eine effiziente Verwaltung und moderne Steuerung ihrer finanziellen Budgets. 
Die für den öffentlichen Sektor relevanten Funktions- und Prozessverbesserungen im Rahmen der Cloud-Konvertierung blieben jedoch bisher nahezu komplett aus. Dies machte einen Umstieg in die Public-Cloud bislang daher undenkbar.