Im Rahmen meiner SAP Schulungen und auch Online-Trainings bei Espresso Tutorials sind die Live-Sessions eine gute Gelegenheit, die eigenen Schulungsunterlagen anzupassen und die Inhalte auf aktuellen Stand zu bringen. Durch den Austausch mit unterschiedlichen Branchen, Modulverantwortlichen und Anwendende kommen manchmal komplexe Fragen und hin und wieder bemerke ich auch, dass ich eine eigentlich sehr einfache Sache in meiner Schulung versäumt habe zu erwähnen.

In einer dieser Live-Sessions der Veranstaltung "Rechercheberichte mit SAP Report Painter" gehe ich auch immer auf praktische Übungsbeispiele ein, die die Grundlagen für Report Painter / Report Writer erläutern, aber vielleicht nicht unbedingt später im SAP System beibehalten werden sollen. Ziel der Veranstaltung ist es nicht ein kundeneigenes Berichtswesen im Rahmen eines Beratungsauftrages aufzubauen sondern Hilfsmittel und Werkzeuge, wie eben Report Painter und Report Writer anzubieten durch die später vielleicht an der ein oder anderen Stelle das eigene Berichtswesen ausgebaut werden können.

Einen Überblick über die Inhalte der Live-Sessions sowie der Lerninhalte ist auf https://www.unkelbach.expert/lernpfad.php zu finden :-).

In einer meiner letzten Schulungen habe ich folgende Frage erhalten: "Wie können die Testreports endgültig gelöscht werden?" Dies ist besonders dann interessant, wenn diese auch keine echte Funktion mehr haben oder unsinnige Ergebnisse liefern.

In der ersten Entwurfsphase habe ich oft Berichte mit Papier und Stift entworfen, sodass hier die Idee meines gehäkelten Gargoyle Gideon gar nicht so fern liegen mag, eine Korrektur wie im folgenden Bild durchzuführen.



Während Gideon hier im Foto mit Radiergummi das Berichtswesen anzupassen versucht, gibt es im SAP System innerhalb Report Painter und Report Writer andere Möglichkeiten einen Bericht zu entfernen.

Report Painter und Report Writer Berichte mit Transaktion GR34 löschen

Im SAP Menü können eigene Transaktionen aufgerufen werden, um Report Painter oder Report Writer Berichte direkt zu löschen.

• Infosysteme
• Ad-Hoc-Berichte
• Report Painter
  • Bericht
    • Löschen (Transaktion GR34)
  • Report Writer
    • Bericht
      • Löschen (Transaktion GR34)

Bei der Transaktion GR34 sind sowohl Bibliothek als auch Bericht auszuwählen und über die Schaltfläche "Löschen" kann dieser Bericht gelöscht werden.

In der Wertauswahlhilfe (F4) Taste kann nach der Wahl der passenden Bibliothek eine Liste aller in der Bibliothek vorhandenen Berichte angezeigt werden und durch das Dreieck auch nach den einzelnen Spalten dieser Liste gefiltert werden.

Als Liste zur Einschränkung stehen folgende Spalten zur Verfügung:

• Bibliothek
• Bericht (8 Zeichen)
• Berichtsname (35 Zeichen)
• Autor (Angelegt von)
• Datum (Datum der Neuanlage)
• Berichtsursprung

Der Berichtsursprung zeigt auch direkt an, mit welcher Transaktion ein Bericht angelegt worden ist. Handelt es sich um einen Report Writer Bericht (erstellt mit der Transaktion GR31 oder später bearbeitet mit der Transaktion GR32)  ist dieser Eintrag nicht gefüllt (leer). Berichte die mit Report Painter (Transaktionen GRR1, GRR2) erstellt / bearbeitet worden sind, ist hier "P" als Wert gefüllt.

Beim Ausführen eines Berichtes, über die Berichtsgruppe, werden Report-Painter-Berichte automatisch in das Report-Writer-Format übersetzt, auch wenn eine spätere Bearbeitung der Berichte weiterhin in der ursprünglichen Umgebung erfolgt.

Report Painter Berichte in Transaktion GRR2 löschen

Sind die zu löschenden Berichte mit Report Painter erstellt worden, können diese auch in der Transaktion GRR2 gelöscht werden. Nach Aufruf der Transaktion GRR2 können alle in den jeweiligen Berichtsbibliotheken vorhandenen Berichten angeklickt werden. 

Hierbei ist zu beachten, dass nur solche Berichte hier aufgeführt sind, die auch mit der Transaktion GRR1 angelegt worden sind. Die Oberfläche der Report Painter Berichte ist eine "modernere" WYSIWYG Oberfläche, die das Bearbeiten der Berichte erleichtert.

Mit der rechten Maustaste (Kontextmenü auf Löschen) oder unter (MEHR) > BERICHT> LÖSCHEN ist es möglich den entsprechenden Bericht zu löschen. 

Dies funktioniert jedoch nur, sofern der Bericht noch keiner Berichtsgruppe zugeordnet worden ist. 

Andernfalls erfolgt hier aber auch in der Transaktion GR34 die Meldung "Bericht ... wird noch in einer Berichtsgruppe verwendet.".

Zugeordnete Berichtsgruppe identifizieren

In der Report Painter Oberfläche (GRR2 Ändern, GRR3 Anzeigen) kann die Zuordnung einer Berichtsgruppe über das Menü (MEHR) > UMFELD > BERICHTSGRUPPE ZUORDNEN... aufgerufen werden.

Sofern eine Berichtsgruppe zugeordnet worden ist, erscheint die Meldung "Der Bericht wird bereits in Berichtsgruppen verwendet".

Hier kann nun über die Schaltfläche "B.gruppen auflisten" die jeweilige Berichtsgruppe angezeigt werden.  Über die Schaltfläche "Weitere B.Gruppe" kann der Bericht in eine weitere Berichtsgruppe aufgenommen werden, die dann auch von dort angelegt werden kann.

Auch bei Report Writer Berichten kann die Berichtsgruppe angezeigt werden. Hier kann über die Transaktion GR32 (Ändern), GR33 (Anzeigen) über MEHR > ZUSÄTZE > VERWENDUNG für den zu pflegenden Bericht die Verwendung des Berichts in Berichtsgruppen aufgerufen werden.

Als Ausgabe erfolgt Verwendung in Berichtsgruppen und direkt die Berichtsgruppe (4 Zeichen) sowie die Beschreibung der Berichtsgruppe, sofern vorhanden.

Bericht aus Berichtsgruppe entfernen

Ist die Berichtsgruppe gefunden, kann jetzt hier auch der jeweilige Bericht entfernt werden.

Die Bearbeitung / Pflege der Berichtsgruppe erfolgt im SAP Menü unter

• Infosysteme
• Ad-hoc-Berichte
• Report Painter
• Report Writer
• Berichtsgruppe
  • Ändern (Transaktion GR52)

Im Einstiegsbild der Transaktion GR52 ist es jetzt möglich die Berichtsgruppe anzugeben und über die Schaltfläche "Berichte" können die zugeordneten Berichte aufgerufen werden.

Alternativ kann diese Schaltfläche auch nach Bestätigung der Berichtsgruppe mit der Eingabetaste (Enter) aufgerufen werden. Sofern die Berichtsgruppe aus der Transaktion GRR2 angelegt worden, ist es erforderlich eine Beschreibung der Berichtsgruppe einzutragen. Diese wird später auch als Titelzeile beim Aufruf des Berichtes verwendet.

Exkurs Status Berichtsgruppe:

Unter Status der Berichtsgruppe kann entweder "Berichtsgruppe ist aktuell generiert" oder "Das Set ... wurde geändert" oder eine vergleichbare Meldung stehen. Hintergrund hierzu ist, dass der Statuseiner Berichtsgruppe angibt, ob die Berichtsgruppe beim Aufrufen bereits generiert wurde oder ob zwischenzeitlich ein Objekt der Berichtsgruppe (zum Beispiel eine Änderung eines zugeordneten Berichtes) erfolgt worden ist, so dass eine Neugenerierung der Berichtsgruppe erforderlich ist.

Durch die Generierung wird im Hintergrund ein ABAP-Programm aus Report Painter oder Report Writer Definitionen geschrieben. Dies erfolgt auch beim Starten des Berichtes über die Pflege (Ausführen) oder eben durch direkten Start der Berichtsgruppe über die Transaktion GR55. Alternativ kann im Einstiegsbild der Transaktion GR52 die Berichtsgruppe generiert werden.

Durch Wechsel über die Schaltfläche "Berichte" ist eine Tabelle mit allen Berichten innerhalb der Berichtsgruppe zu sehen. Hier kann ein Bericht angeklickt werden (auf die Zeile mit dem Berichtsnamen geklickt werden) und über die Schaltfläche (-) Zeile Löschen (UMSCH + F2) der Bericht aus der Berichtsgruppe entfernt werden.

Danach kann die Berichtsgruppe, selbst ohne einen einzigen zugeordneten Bericht, gespeichert werden.
 

Hintergrund: Berichtsgruppe

Eine Berichtsgruppe fasst alle zugeordneten Berichte zusammen, die in einem Lauf ausgeführt werden sollen. Dabei ist zu beachten, dass innerhalb einer Berichtsgruppe nur Berihcte einer Bibliothek verarbeitet werden kann. Technisch wird aus dem Bericht, ob nun per Report Painter oder Report Writer erstellt, ein ABAP Report / Programm erstellt. Der Name dieses ABAP Programms kann sowohl im Selektionsbild über UMFELD > TECHNISCHE INFO als auch in der ausgegebenen Liste (Bericht) über ZUSÄTZE > TECHNISCHE INFO ausgegeben werden.

Der Name einer Berichtsgruppe ist vierstellig und darf nur aus Zeichen von A bis Z, Zahlen 0 bis 9 sowie den Zeichen - und _ bestehen.

Auf dem Selektionsbild erscheinen alle zu übergebenden Variablen der Berichte.

Technisch werden hier Programme zur Verarbeitung des Einstiegsbildes, Selektion (Lesen) der Daten, Ausgeben der selektierten Daten und ggf. Programme zur Mehrfachselektion erstellt.

In meiner Schulung zeige ich gerne den Unterschied zwischen Abschnitten innerhalb eines Berichtes und separate Berichte in einer Berichtsgruppe, um unterschiedliche Berichtsziele zu erfüllen.
 

Fazit

Im Ergebnis können dann also Berichte, die nicht einer Berichtsgruppe zugeordnet sind, über die Transaktion GR34 gelöscht werden. Sollte der Report Painter / Report Writer Bericht jedoch einer Berichtsgruppe zugeordnet sein, ist dieser erst einmal aus der Berichtsgruppe zu entfernen.

Künftig ist dieses Thema auch fest in der Live-Session innerhalb des Lernpfades zur Schulung vorgesehen :-). Dies ist auch ein Grund, warum sich die Unterlagen zur Live-Session jedes Mal ein wenig ändern.

So sind in letzter Zeit auch Anfragen aus Blog, Linkedin oder im Rahmen von Mailaustausch mit der SAP Community sowohl ins Blog als auch in der Schulung eingeflossen und die Unterlagen der Live-Session bekommen bei jeder Veranstaltung noch einmal ein Update, auch wenn die Begleitvideos weiterhin Bestand haben.

Weitere Beispiele sind zum Beispiel in den Artikeln "Varianten vom Selektionsbild (Selektionsvarianten Reportvarianten) für Report Painter Berichte transportieren" oder auch "Reportmatrix über bestehende kundeneigene SAP Berichte (Report Writer, Recherche oder SAP Query)".

Vielleicht ist der Austausch innerhalb der Lerngruppe auch ein weiterer Vorteil, den solche (Online) Veranstaltungen bieten, besonders wenn hier unterschiedliche Teilnehmende vorhanden sind.
 

---

Hinweis:

Eine kurze Einführung in das Thema Report Painter und Report Writer habe ich im Artikel "Grundlagen Kurzeinführung und Handbuch Report Painter Report Writer" beschrieben und hoffe Ihnen hier eine Einführung ins Thema bieten zu können.

---

Im Blogartikel "Auswertung sprechender Nummernkreisintervalle von CO Innenaufträgen mit Query Zusatzfeldcoding und Unterscheidung numerischer oder alphanumerischer Schlüssel" bin ich schon auf unterschiedliche "IF-Schleifen" eingegangen um anhand der Auftragsnummer einen bestimmten Wert einer Variable als Zusatzfeld innerhalb einer SAP Query zuzuweisen.

Ich schreibe, auch in diesem Artikel, von einer IF-Schleife, da die Prüfungsbedingungen innerhalb eines Konstruktes aus IF, ELSEIF und ENDIF gebunden sind. Technisch ist dies nicht ganz korrekt,  da IF eine Bedingung und keine Schleife ist im eigentlichen Sinne ist. Aber für mein Verständnis liest sich dies etwas einfacher als Bedingungsprüfung. 

Nun mag ich mir Schleifen aber etwas genauer ansehen.



Eine meiner ersten Praxiserfahrungen mit Programmierung habe ich mit PHP gesammelt, wo ebenfalls Schleifen und Bedingungen ein Thema sind. Natürlich sind solche digitale Schleifen ein wenig komplexer als die Schleife als die Schleifen von Schnürrsenkel die mein gehäkelter Gargoyle im oberen Bild betrachtet ;-).

Entsprechend ist mir das Thema schon vertraut aus der Anfangszeit meines "Internetlebens" und ich freue mich noch immer über den Einstieg durch das Tutorial "PHP für dich" meiner Frau welches mir damals den Einstieg in die Webprogrammierung ermöglicht hat.

• If-Anweisung in PHP - Wenn das Wörtchen if nicht wär'...
  https://www.schattenbaum.net/php/if.php
• SWITCH - Hierhin switchen, dahin switchen...
  https://www.schattenbaum.net/php/switch.php

Manche Programmierlogik ist zum Glück auch auf andere Programmiersprachen übertragbar.
Durch eine Weiterbildung sowie komplexere Anforderungen an das Berichtswesen in SAP habe ich mich dann aber auch mit ABAP ein wenig beschäftigt, auch wenn mein beruflicher Hintergrund Controlling und Berichtswesen nur am Rande mit Basistätigkeiten und Entwicklung zu tun hat. Immerhin für das Coding in SAP Query ist kein Entwicklerschlüssel notwendig, so dass hier auch einige Möglichkeiten vorhanden sind, auf die ich im folgenden Praxisbeispiel gerne näher eingehen mag.

Als Beispiel nehme ich hier eine Stammdatenauswertung von CO Innenaufträgen mit SAP Query und gehe auch kurz auf die Funktionsweise des Zusatzfeldcoding ein.

 

Funktionsweise SAP Query

Durch SAP Query ist es möglich auf Datenbankebene Auswertungen für das kundeneigene Berichtswesen zu gestalten. Insbesondere im Bereich HCM aber auch im Rechnungswesen (CO und FI) hat dieses eine Berechtigung. Ich nutze die Möglichkeiten insbesondere gerne im Bereich der Auswertung von Stammdaten.

Die Pflege von SAP Query ist im SAP Menü unter

• Werkzeuge
• ABAP Workbench
• Hilfsmittel
• SAP Query

möglich. hier können Queries (Transaktion SQ01), InfoSets (Transaktion SQ02) und Benutzergruppen (Transaktion SQ03) gepflegt werden.

Neben der Verknüpfung von Tabellen oder der Auswertung von logischen Datenbanken können Infosets auch Zusatzfelder enthalten, die mit einer eigenen Logik genutzt werden können.

Für mein Beispiel, siehe oberen verlinkten Artikel, werte ich CO Innnenaufträge aus und möchte abhängig von der Auftragsnummer AUFK-AUFNR eine entsprechende Zuordnung treffen. Eine Erläuterung wie die einzelnen Tabellen hier als JOIN definiert sind ist in den anderen Artikeln beschrieben, an dieser Stelle soll es um die Behandlung eines Zusatzfeldes gehen.

Anlegen eines Zusatzfeldes als unter Zusätze im Infoset

Über die Schaltfläche ZUSÄTZE (Taste F5) bekomme ich statt der Feldgruppen / Datenfelder die Möglichkeit neben Abgrenzungen, Coding und Erweiterungen auch Zusätze anzulegen.

Durch das Symbol ANLEGEN unterhalb des Register Zusätze habe ich die Optionen einen Namen anzugeben sowie als Art der Zusatzinformation ZUSATZFELD.

Im Beispiel wäre dies

Name:  ZCOKEY
Art der Zusatzinformation: Zusatzfeld


Neben den oberen technischen Namen kann ich dies nun auch ausführlicher beschreiben und die Feldeigenschaften im folgenden Fenster festlegen.

Langtext: ZCOKEY (Zusatzfeld CO AUFNR)
Der Langtext beschreibt das Feld länger und steht in der Query in der Feldauswahl zur Verfügung. Im Beispiel habe ich hier den technsichen Namen übernommen.
Überschrift: ZCOKEY
Die Überrschirft wird, sofern das Feld für Ausgaben herangezogen wird als Überschrift in der Ausgabenliste oder auf der Selektionsmaske zur Verfügung.

Nun kann das Format des Feldes entweder anhand einer LIKE-Referenz die Eigenschaften eines anderen Tabellenfeldes erben oder alternativ die folgenden Eigenschaften zugewiesen bekommen:

Typ: C
Dies ist für Character. Weitere ABAP Typen wären N, D, T, X, I , P oder F.

Exkurs: Datentypen in ABAP

Zu den zeichenartigen Typen zählen

• C (Textfelder / alphanumerische Felder),
• D (Datumsfelder im Format JJJJMMTT),
• N (numerische Zeichen),
• T (Zeitfelder im Format HHMMSS).

Daneben gibt es noch numerische Felder

• I (Ganze Zahlen / Integer),
• F (Gleitpunktzahlen zur Exponentialdarstellung für sehr große Wertebereiche)
• P (gepackte Felder mit bis zu 14 Nachkommastellen die bspw. für Entfernungen, Gewichte oder Geldbeträge verwendet werden).

Als Datentyp X sind Hexadezimalfelder / Byte-Felder zu verstehen. 

Nach der Festlegung des internen ABAP Typs wird noch die Länge des Feldes sowie die Ausgabelänge und gegebenenfalls die Anzahl der Dezimalstellen festgelegt.

Wird keine Länge angegeben erfolgt hier automatisch die Standardlänge die dem Datentyp entspricht. So ist diese 1 bei C und 4 beim Typ I.

Im Beispiel habe ich die Länge und Ausgabenlänge auf 040 gesetzt und das Feld Dezimalen leer gelassen. Die Angabe von Dezimalstellen ist ohnehin nur für ein Zusatzfeld vom Typ P möglich, für andere Zusatzfelder ist eine Dezimalenangabe nicht möglich.

Nun kann ich noch die Reihenfolge des Codeabschnitts festlegen, welcher bei Neuanlage auf 1 gesetzt ist. Dies kann sinnvoll sein, wenn ich die Ergebnisse eines anderen Feldes verarbeiten möchte. 

Anlage eines Zusatzcoding zum Zusatzfeld (Coding zum Zusatz)

Danach ist das Zusatzfeld angelegt und ich kann über die Schaltfläche "Coding zum Zusatz" ein ABAP Coding zum Feld hinterlegen. Hierzu muss auf das Zusatzfeld geklickt werden und es kann nun ein Coding angelegt werden.

Bisher hatte ich hier folgendes, stark vereinfachtes, Coding angelegt.
 

Zeile	Codinganweiseung
1	CLEAR ZCOKEY.
2	IF AUFK-AUFNR CO  '1234567890'.
3	IF AUFK-AUFNR  BETWEEN  '000040210000' AND '000040219999'.
4	ZCOKEY = 'Office Literatur'.
5	ELSEIF AUFK-AUFNR  BETWEEN  '000040220000' AND '000040229999'.
6	ZCOKEY = 'SAP Literatur'.
7	ELSEIF AUFK-AUFNR  BETWEEN  '000040230000' AND '000040239999'.
8	ZCOKEY = 'BWL Literatur'.
9	ENDIF.
10	ENDIF.

In der oberen Tabelle habe ich die Zeilen jedes Coding eingefügt.

In der Zeile 1 wird die Variable ZCOKEY durch die ABAP Anweisung CLEAR erst einmal geleert. Andernfalls merkt sich die Query bei mehreren Innenaufträgen den vorherigen Wert, sofern kein neuer Wert zugewiesen wird. Durch die Anweisung CLEAR wird die Variable bzw. das Zusatzfeld auf Initialwert zurückgesetzt. Sofern dieses nicht der Fall ist wundert man sich über die Ergebnisse.

In der Zeile 2 wird darauf Rücksicht genommen, dass die Auftragsnummer durchaus auch alphanumerisch sein kann, daher wird hier geprüft, dass nur Zahlenwerte einer Prüfung unterlaufen.

Hier kann eine Wenn Funktion (IF) mit der vergleichendenen Anweisung CO (contains only) weiter helfen. ABAP hat einige Vergleichsoperatoren, so dass hier Variablen mit Variablen oder aber auch mit bestimmten Werten verglichen werden können. Zu diesen logischen Ausdrücken gehört unter anderen CO (contains only), CN (contains not only) und weitere.

Diese liefern ein Wahr wenn der Vergleich erfolgreich war und nur die Zeichen des Vergleichsparameter vorhanden war (CO) oder aber wenn noch weitere Zeichen dabei sind (CN). Interessant ist auch noch die Möglichkeit CS (contains string) womit vergleicht werden kann, ob eine bestimmte Zeichenfolge in einen Wert vorhanden ist.

In unserem Fall wird also geprüft, dass das Feld AUFK-AUFNR nur Nummern umfasst.

In den Zeilen 3, 5 und 7 wird nun geprüft ob der Wert innerhalb eines Intervalls liegt und in den Zeilen 4,6 und 8 dem Feld ZCOKEY ein entsprechender Wert zugeordnet. Zu beachten ist hierbei, dass Zeilen 5 und 7 jeweils mit ELSEIF die IF-Bedingung aus Zeile 3 fortsetzen.

Zeile 9 beendet mit ENDIF. die IF-Schleife aus Zeile 3 und Zeile 10 mit ENDIF. die IF-Schleife aus Zeile 2.

Im Ergebnis sind also alle CO Innenaufträge von 40210000 bis 40219999 Office Literatur, 40220000 bis 40229999 SAP Literatur und 40230000 bis 40239999 BWL Literatur.

Oder als direkte Intervalle ausgedrückt:

• 000040210000–000040219999 → Office Literatur
• 000040220000–000040229999 → SAP Literatur
• 000040230000–000040239999 → BWL Literatur

Das Beispiel stammt aus der Publikation zum Schnelleinstieg in das Controlling (CO) mit SAP S/4HANA (siehe Publikationen).

Sonderfall: Einzelwert innerhalb eines Intervalls

Nun gibt es jedoch den Sonderfall, dass ein Buch als Innenauftrag angelegt worden ist und diese Nummer einer besonderen Kategorie zugeordnet werden soll.

Nehmen wir einmal an, dass das Buch "Excel für Erbsenzähler" mit der Auftragsnummer 40210013 nicht als Office Literatur eingeordnet werden soll sondern als EXCEL ohne dass ich das bestehende Intervall erweitere.

Hier kann ich das obere Coding der Zeile 4 wie folgt erweitern:

 

Zeile	Codinganweiseung
1	CLEAR ZCOKEY.
2	IF AUFK-AUFNR CO  '1234567890'.
3	IF AUFK-AUFNR  BETWEEN  '000040210000' AND '000040219999'.
4	IF AUFK-AUFNR = '000040210013'.       ZCOKEY = 'Excel'.      ELSE.       ZCOKEY = 'Office Literatur'.    ENDIF.
5	ELSEIF AUFK-AUFNR  BETWEEN  '000040220000' AND '000040229999'.
6	ZCOKEY = 'SAP Literatur'.
7	ELSEIF AUFK-AUFNR  BETWEEN  '000040230000' AND '000040239999'.
8	ZCOKEY = 'BWL Literatur'.
9	ENDIF.
10	ENDIF.

 
Damit habe ich an diesr Stelle also eine verschachtelte IF-Schleife in der ich innerhalb der Prüfung von Zeile 3 nun in Zeile 4 eine weitere Schleife mit IF einfüge und hier weitere verschachtelte Bedingen einfüge. Natürlich könnte ich hier auch noch weitere Intervalle und Bedingungen mit ELSEIF einfügen.

Damit kann innerhalb eines Bereichs ein bestimmter Einzelwert explizit behandelt werden.

Alternative: CASE-Anweisung im Zusatzfeld

Statt mit verschachtelten IF-Bedingungen kann natürlich auch mit einer CASE Anweisung gearbeitet werden. Hier habe ich das Coding wie folgt angepasst.
 

Zeile	Codinganweisung
1	CLEAR ZCOKEY.
2	* Prüfen, ob AUFNR nur aus Ziffern besteht
3	IF aufk-aufnr CO '0123456789'.
4	CASE aufk-aufnr.
5	WHEN '000040210013' .
6	zcokey = 'Excel'.
7	WHEN '000040210017' OR '000040210021' .
8	zcokey = 'Word'.
9	WHEN '000040210000' TO '000040219999'.
10	zcokey = 'Office Literatur'.
11	WHEN '000040220000' TO '000040229999'.
12	zcokey = 'SAP Literatur'.
13	WHEN '000040230000' TO '000040239999'.
14	zcokey = 'BWL Literatur'.
15	WHEN OTHERS.
16	zcokey = 'Sonstige numerische Aufträge'.
17	ENDCASE.
18	ELSE.
19	* Sonderbehandlung für Aufträge mit Buchstaben
20	zcokey = 'Alphanumerische Auftragsnummer'.
21	ENDIF.

An dieser Stelle habe ich die CASE Anweisung statt einer verschachtelten IF-Schleife genutzt.

Im Artikel "Gruppierung von Finanzierungszwecken bei Drittmittelprojekten per Zusatzfeldcoding mit IF oder CASE" habe ich beide Methoden verglichen.

Das Coding unterscheidet sich gegenüber der vorherigen IF-Schleife durch die Einbindung einer CASE Anweisung.

Zeile 1 leert ebenfalls den Inhalt des Feldes ZCOKEY. Danach beginnt eine IF Schleife in Zeile 3 die überprüft dass die Werte nur aus Zahlen bestehen.

In Zeile 4 wird mit CASE eine CASE Anweisung eingeleitet in der der Inhalt des Tabellenfeldes aufk-aufnr geprüft wird. Dies ist auch direkt der Unterschied gegenüber IF Anweisung die auch komplexe oder stark verschachtelte Prüfungen vornehmen können. Hier wird nur ein Feld als Datenobjekt auf die Ausprägung (Inhalt) geprüft.

In Zeile 5 wird auf einen Einzelwert '000040210013' geprüft und in Zeile 6 zcokey den Wert 'Excel' zugewiesen.

In Zeile 6 werden zwei Einzelwerte geprüft '000040210017' OR '000040210021' wodurch durch mehrere OR auch mehrere Einzelwerte gegengeprüft werden können und in Zeile 7 wird zcokey den Wert 'Word' zugewiesen.

Die Zeilen 9, 11 und 13 überprüfen nun ein Intervall und weisen in der Folgezeile dann ebenfalls einen entsprechenden Wert zu.

Abschließend sind in Zeile 15 durch WHEN OTHERS. alle sonstigen Ausprägungen zusammengefasst. 
Die CASE Anweisung endet in Zeile 17 mit einen ENDCASE.
Da wir auch  alphanumerische Aufträge haben, also solche die auch Buchstaben enthalten habe ich eine ELSE. Anweisung in Zeile 18 und eine Wertzuweisung in Zeile 20 eingefügt.
Die Schleife aus Zeile 3 endet mit Zeile 21 und der Anweisung ENDIF.

Unterschied IF und CASE Anweisung

Dies ist auch ein Unterschied zur IF-Anweisung. Eine IF-Anweisung kann auch ohne ELSE oder ELSEIF funktionieren, da im Coding einfach fortgefahren wird, sofern keine Übereinstimmung getroffen wurde. Innerhalb einer Case Anweisung ist aber immer ein  WHEN OTHERS. erforderlich, da sonst das Programm an dieser Stelle abbrechen würde, sofern keine Übereinstimmung gefunden wird.

Programmlogik und Reihenfolge

Jede Schleife oder Überprüfung endet damit, dass der zu prüfende Fall eintritt und damit werden keine weitere Prüfungen mehr durchgeführt. Entsprechend wichtig ist, dass hier auch die Programmlogik vom Speziellen aufs Allgemeine aufgebaut ist.

Warum die Reihenfolge der Prüfung der einzelnen Bedingungen wichtig ist

Für das Beispiel der CASE Anweisung wird die Programmlogik in zwei Abschnitten durchgeführt.

Abschnitt 1: Nur wenn die Auftragsnummer rein numerisch ist
(also AUFK-AUFNR CO '0123456789' → keine Buchstaben, keine Sonderzeichen) siehe Coding Zeile 3

Bereich / Einzelwerte	Bedingung  Zeile	Ergebnis ZCOKEY	Bemerkung
000040210013	Zeile 5	Excel	Einzwert
000040210017, 000040210021	Zeile 7	Word	Zwei Einzelwerte
000040210000 - 000040219999	Zeile 9	Office Literatur	Bereich, außer den oben genannten Einzelwerten (da diese vorher geprüft werden)
000040220000 – 000040229999	Zeile 11	SAP Literatur	Bereich
000040230000 – 000040239999	Zeile 13	BWL Literatur	Bereich
alle anderen numerischen Werte	Zeile 15	Sonstige nummerische Aufträge	Zum Beispiel 000040240000– 999999999999

Hier wird auch deutlich, warum die Einzelwerte vor den Intervallen im Coding erfolgen sollen. Würden diese nach dem Intervall geprüft werden, würden diese nicht beachtet werden.

Abschnitt 2: Wenn die Aufragsnummer nicht rein numerisch ist
(also Buchstaben, Sonderzeichen o. ä. enthält) siehe Coding Zeile 18

Bedingung	Codezeile	Ergebnis ZCOKEY	Beispiel
ELSE (nach IF aufk-aufnr CO '0123456789')	18	Alphanumerische  Auftragsnummer	z. B. A00040210000, X400001, 04021A0001

Damit wäre das Coding an sich erläutert. Gerade im ersten Abschnitt sollte klar ersichtlich sein, warum ich erst die Einzelwerte als spezielle Regelung und danach die Bereiche / Intervalle prüfe. Sobald eine Bedingung eingetreten ist (zum Beispiel ein Einzelwert zutrifft) werden nicht die weiteren Bedingungen (im Beispiel die Intervalle / Bereiche) geprüft. daher ist es wichtig bei den Bedingungen vom Speziellen auf das Allgemeine die "Prüfketten" aufzubauen.

Entscheidung zwischen IF-Schleife oder CASE Anweisung

Nun stellt sich natürlich die Frage, welche Coding Anweisung hier eigentlich Vorteile hat.

Relativ pragmatisch würde ich eine CASE Anweisung verwenden, sofern ein einzelnes Feld, wie das Tabellenfeld AUFK-AUFNR, auf einen festen Wert oder ein nummerisches Intervall geprüft werden soll. Eine IF-Anweisung kann dann Sinn machen, wenn komplexe Bedingungen und entsprechende Ausnahmen (zum Beispiel Überprüfung der externen Auftragsnummer im CO Innenauftrag sprich das Tabellenfeld AUFK-AUFEX) ebenfalls geprüft werden sollen. 

Natürlich können auch Mischformen herangezogen werden. Grundsätzlich dürfte die CASE Anweisung auch schneller verarbeitet werden und ist in meinen Augen vom Coding her besser in der Lesbarkeit.

In beiden Fällen ist jedoch darauf zu achten, dass wenn eine Bedingung erfolgt ist die Prüfkette beendet ist, entsprechend sollte bei jeder Schleife genau bedacht werden in welcher Reihenfolge hier geprüft wird.

Empfehlungen aus meiner Praxis zum ABAP Coding allgemein und Bedingungen im Speziellen

Als Anhaltspunkte für die Auswahl einer geeigneten Bedingungs-Prüfung und entsprechender Code-Prüfkette würde ich folgende Gedanken in Betracht ziehen:

Empfehlung 1: Einstellungen zum ABAP Editor

Besonders bei umfangreichen Zusatzfeld-Coding ist es wichtig in der Praxis immer wieder zu prüfen ob auch das gewünschte Ergebnis ausgegeben wird. Innerhalb des Editors für das Coding in SAP Query empfehle ich gerne die Schaltfläche "Coding prüfen" wodurch das Coding auf Syntaxfehler geprüft wird und Fehlermeldungen direkt ausgegeben werden.

Ebenso relevant ist die Schaltfläche "PrettyPrint" wodurch das Coding mit Einrückungen formatiert wird. Sofern die Berechtigungen für die Transaktion SE80 Object Navigator oder SE38 ABAP Editor vorhanden ist empfiehlt es sich hier über die Einstellungen zum Edior (bspw. per SE80 und hier im Menü (Mehr) > Hilfsmittel > Einstellungen) unter der Registerkarte ABAP Editor folgende Einstellungen vorzunehmen:

Reiter Editor
Quellcode-basierter Editor (statt Text-basierter Editor)
Damit wird der Standard-Editor für ABAP Programmierung so gewählt, dass im Quelltext Schlüsselworte (ABAP Befehle) eingefärbt sind, Zeilen eingeblendet werden und eine automatische Syntaxkontrolle erfolgt. Dies erleichtert das Coding durchaus erheblich.

Reiter Pretty Printer
Ferner ist der Abschnitt Pretty Printer für die oben erwähnte Schaltfläche relevant.

Hier können dann Einrückungen aktiviert werden sowie die Groß-/Kleinkonvertierung aktiviert werden mit der bspw. Schlüsselworte groß geschrieben und damit hervorgehoben werden

Empfehlung 2: Wartbarkeit und Fehlersuche in Zusatzfeldern

Betrachten wir uns nun aber nur das Coding haben CASE-Strukturen den Vorteil, dass jeder WHEN-Zweig klar abgegrenzt ist und unerwartete Fälle leichter mit WHEN OTHERS erkannt werden.

Bei verschachtelten IFs kann dagegen ein fehlendes ELSE, ELSEIF  oder eine unvollständige Bedingung leicht übersehen werden, gerade wenn mehrere Personen das Zusatzfeld-Coding innerhalb des Infosets pflegen.

Empfehlung 3: Performance

Im Kontext von Zusatzfeldern bei SAP Query dürfte die Performance bei der Auswertung weniger eine Rolle spielen, da die Auswertung feldweise erfolgen. Dennoch ist bei festen Regeln, wie hier die Prüfung auf Einzelwerten oder Intervallen, CASE oft effizienter, da das System hier intern optimieren kann. Bei umfangreicheren Prüflogiken (z.B. Kombination aus Text- und Zahlenprüfungen) bietet IF jedoch eine flexiblere und vielleicht auch besser lesbare Alternative.

Empfehlung 4: Lesbarkeit und Dokumentation im Team

Hier zeigt sich, wie auch in anderen Projekten, dass der Schlüssel zum Erfolg auch die Kommunikation ist. Im Laufe der Zeit wird ein Coding im Zusatzfeld sicherlich wachsen, da es durch verschiedene Personen angepasst, erweitert und am Ende auch gepflegt wird. Eine klare Struktur - sei es durch sauber eingerückte IF-Blöcken oder logisch gruppierten CASE-Zweigen hilft enorm dabei den Aufbau des Zusatzfeld-Coding auch in naher Zukunft noch nachvollziehbar zu machen.

An dieser Stelle vielleicht auch der Hinweis, dass Kommentare im CODE wie zum Beispiel * Profitcenter … oder * Bereich Office-Literatur durchaus hilfreich sind und nur am Anfang nach ein wenig Mehrarbeit aussehen mögen. Im Ergebnis bleibt die Logik auch nach Monaten noch verständlich und ermöglicht es auch weiteren Personen sich in das Coding einzulesen.
 

Grenzen des Zusatzfeld-Codings in SAP Query

Bei der Auswertung von Daten per SAP Query und Bearbeitung im Zusatzfeld-Coding ist immer darauf zu achten, dass die Auswertung immer zeilenbezogen, im Beispiel also für die bei der Selektion angegebene Auftragsnummer, erfolgt. Es reagiert also stets auf die Information die im jeweiligen Datensatz des Infosets liegt. Eine Berechnung über mehrere Datensätze hinweg oder auch über mehrere Tabellen hinaus übersteigt hier die Möglichkeiten des Infosets.

Sicherlich können später in der Query dann Zwischensummen gebildet werden aber komplexere Auswertungen sind dann doch eher über "reine" ABAP Programme möglich. Dennoch hat das Zusatzfeld-Coding durchaus eine Berechtigung und ermöglicht es Ihnen für eine Query die bestehenden Daten aus dem Infoset noch weiter aufzubereiten. Daher denke ich dass auch unter SAP S/4HANA weiterhin auch SAP Query eine Berechtigung hat und hier solche Auswertungen eine flexible Option für das eigene Berichtswesen sein können. Daneben wären aber auch die Möglichkeiten eines eigenen ABAP-Report, Funktionsbaustein oder künftig auch CDS-View die dann auch unter FIORI genutzt werden können eine Option. Queries sind auch weiterhin ein flexibles Auswertungstool für Modulverantwortliche und ebenso wie Report Painter Berichte je nach Anforderung auch weiterhin nützlich.
 

Fazit: Lesbarkeit und Logik sind entscheidend

Die eigentliche Frage hier im Artikel war aber ob eher eine CASE- oder eine IF-Anweisung für Prüfbedingungen geeignet ist. Am Ende ist der Artikel dann aber an der ein oder anderen Stelle etwas ausführlicher geworden. Nun mag ich aber zur Ausgangsfrage zurück kehren.

In vielen Fällen sollte eine CASE-Anweisung im Zusatzfeld-Coding einer SAP Query die übersichtlichere Wahl sein - besonders wenn ein einzelnes Feld auf feste Werte oder Wertebereiche geprüft wird.

Dahingehend spielt eine IF-Anweisung ihre Stärke aus, wenn mehrere Bedingungen, logische Verknüpfungen oder komplexe Prüfungen erforderlich sind.

Beide Varianten haben ihre Berechtigung - entscheidend ist, die Prüfbedingungen klar zu strukturieren und vom Speziellen zum Allgemeinen aufzubauen.

Es kann durchaus möglich sein, dass die Gliederung des Coding auch andere Aspekte berücksichtigt und nicht nur, wie im Beispiel, die reine Analyse der Auftragsnummer in sich hat. Durch Kommentare und spätere Pflege des Coding durch eine andere Person ist es zum Beispiel denkbar die Sortierung der Anweisung in der Schleife nach dem zugeordneten Profitcenter, so dass in den einzelnen Abschnitten zum Profitcenter die entsprechenden Auftragsnummern geprüft werden können. Dies ist aber durch Kommentare sowohl in der CASE-Anweisung als auch IF-Anweisung möglich.

Meiner persönlichen Meinung nach zeichnet sich ein Programmierstil nicht nur durch Lesbarkeit (und damit Wartbarkeit) sondern auch durch eine klare Gedankenstruktur aus, die hinter einem Coding steht aus. Gerade bei Auswertungen in einer SAP Query die auch von anderen Personen erweitert werden soll sind solche Punkte ebenso wie die ordentliche Übergabe und Erläuterung erforderlich um solchen Code am Ende wirklich wartbar und auch nachvollziehbar gestalten zu können.

 

Diese Woche haben Gideon und ich Post erhalten :-). Wie es sich schon am Foto und am Titel dieses Blogartikels erahnen lässt, handelt es sich um eine neue Buchveröffentlichung.

In diesem Fall ist es für mich etwas ganz Besonderes, da es sich um die dritte Auflage meiner ersten Publikation handelt. Nicht ohne Grund daher auch das "Oops, we did it again ...".



Ich habe mich sehr über das Paket gefreut und durfte dann auch selbst die dritte Auflage zum Schnelleinstieg in das Controlling (CO) mit SAP betrachten.



In der dritten Auflage kann nun die Protagonistin der ersten beiden Auflagen auch einen Blick in das Controlling (CO) mit SAP S/4HANA werfen.

Ich freue mich sehr, dass unser fiktiver Verlag »Neue Medien« in der dritten Auflage den Wechsel nach SAP S/4HANA geschafft hat und war schon sehr gespannt, welche Möglichkeiten unsere Controllerin Kirsten Lotse hier nutzen wird. Mein Dank gilt daher meinen beiden Mitautoren Martin Munzel und Christian Sterlepper, die die Vorzüge von S/4HANA herausgearbeitet und zugleich die Welt der Kacheln und Fiori anschaulich dargestellt haben.

Dabei freut es mich auch besonders, dass Christian Sterlepper es gelungen ist, den Charme der ersten Auflage (aus 2015) zu erhalten und gleichzeitig ein fundiertes Update auf S/4HANA durchzuführen. Vielen Dank dafür 💐.Ich glaube noch immer daran, dass dieses Buch einen wunderbaren Einstieg in das Controlling mit SAP bietet und ich bin schon sehr auf das Feedback gespannt.  Eine Migration nach SAP S/4HANA ist sicherlich anstrengend aber das Update von Texten ist noch einmal eine ganz besondere Herausforderung die hier hervorragend gelungen ist.
 

Buchvorstellung Schnelleinstieg in das Controlling (CO) mit SAP S/4HANA

Ich werde sicherlich auch noch eine ausführlichere Beschreibung zum Buch veröffentlichen, aber bis es so weit ist, stelle ich es auch hier im Blog schon einmal vor.

 
Aber vielleicht sind Sie ja auch so schon neugierig geworden, daher gebe ich gerne die Beschreibung weiter.

Dieser kompakte und praxisnahe Leitfaden führt Sie in die Grundlagen des SAP-Controlling (CO) im Kontext von S/4HANA ein. Die von dem Controlling-Experten Christian Sterlepper überarbeitete, dritte Auflage dieses Buches richtet sich gleichermaßen an Einsteiger wie auch erfahrene SAP-Anwender, die sich einen Überblick über die Grundfunktionen, Teilmodule und Anwendungsmöglichkeiten von SAP CO mit S/4HANA verschaffen wollen, um alltägliche berufliche Anforderungen umzusetzen.

Der erste Teil des Buches widmet sich dem Gemeinkostencontrolling und stellt Ihnen mit Kostenstellen und Innenaufträgen die wichtigsten Werkzeuge für das Überwachen der Gemeinkosten vor. Anschließend lernen Sie die Materialkalkulation und ihre Voraussetzungen in den Logistikmodulen kennen. Im Bereich der Ergebnis- und Marktsegmentrechnung erfahren Sie, wie die Deckungsbeitragsrechnung aufgebaut ist. Das letzte Kapitel behandelt die Profitcenter-Rechnung als internes Controllinginstrument.

Anhand eines durchgehenden Beispiels vermitteln Ihnen die erfahrenen Buchautoren die wichtigsten SAP-Controlling-Funktionen für den Lebenslauf eines Produkts: von der Kalkulation bis hin zur Fertigung sowie der anschließenden Umsatz- bzw. Absatzauswertung. Verständnisfragen am Ende jedes Kapitels ermögliche eine persönliche Lernkontrolle.

• Kompakter Überblick über alle CO-Module
• Praxisnaher Einstieg in das SAP-Controlling mit Fiori
• Prozesse anhand eines durchgängigen Beispiels erklärt
• Inklusive Lernkontrollen zu jedem Kapitel

Ich freue mich schon sehr auf aktuelle Rückmeldungen und wünsche schon viel Vergnügen beim Lesen.

Aktuelle Buchprojekte und Veröffentlichungen

Auch wenn ich aktuell noch ein neues Buchprojekt habe, freue ich mich doch sehr, dies zwischendurch ebenfalls vorstellen zu können und habe zwischenzeitlich auch meine Seite "Publikationen" aktualisiert.

Aktuelle Veröffentlichungen und auch Online-Trainings vorn mir finden Sie aber auch auf der Verlagsseite beziehungsweise über die Kurz-URL  www.unkelbach.link/et.books/  :-).

Ich bin noch immer sehr stolz auf das durchgehende Unternehmensbeispiel und denke, dass dieses Buch für Anwendende und (neue) Modulverantwortliche im Controlling oder Menschen, die den Aufbau des Controllings in SAP verstehen wollen, eine gute Grundlage bietet.

Für Expert*innen in den Modulen haben die Autoren aber auch noch weitere Bücher im Angebot, sodass sich da ebenfalls ein Blick lohnt. :-)

Vorstellung der Autoren

Gerne verweise ich hier auf den Blogartikel "Neue Buchpublikation Controlling mit SAP S/4HANA – Customizing Kostenstellenrechnung"  und werde sicherlich auch noch das Buch  "Innenaufträge in SAP S/4HANA - Customizing" (Amazon Partnerlink) von Christian Sterlepper ausführlicher vorstellen.

An dieser Stelle mag ich auch kurz ein paar Worte zu den Autoren des Buchs erwähnen. Besonders freut mich, dass Christian Sterlepper ebenfalls in Gießen-Friedberg studiert hat und damit wir beide Alumnus der Technischen Hochschule Mittelhessen sind.

Daher ein paar Worte zu uns Autoren:

Andreas Unkelbach ist Autor, Controller, Blogger und Dozent – mit über 20 Jahren Erfahrung im SAP-Controlling und Berichtswesen, insbesondere im Hochschulumfeld. Seine Schwerpunkte liegen aufpraxisnahen SAP-Lösungen, verständlich aufbereitet und mit einem Blick fürs Detail. Regelmäßig veröffentlicht er Fachartikel, Bücher und Online-Trainings – unter anderem auf andreas-unkelbach.de und unkelbach.expert. (Autorenprofil Espresso Tutorials / Linkedin)

Christian Sterlepper erwarb nach seinem Studium in Gießen-Friedberg (DE), Bergamo (IT) und Charlotte (NC, USA) den akademischen Grad eines »Master of Business Administration (MBA)«. Er ist seit 2016 als SAP-Berater im Bereich des Rechnungswesens tätig, zertifizierter SAP Berater und auf das Modul Controlling spezialisiert. Durch die erfolgreiche Realisierung von SAP-Projekten im Greenfield-, Brownfield- und Bluefield-Ansatz in verschiedenen europäischen Regionen erweitert er kontinuierlich seine SAP-Fachkenntnisse. (Autorenprofil Espresso Tutorials / Linkedin) 

Martin Munzel ist seit mehr als 25 Jahren im SAP-Umfeld tätig und hat in verschiedenen Positionen als Berater und Inhouse-Berater einen breiten praktischen Erfahrungsschatz erworben. Er hat erfolgreich SAP-Projekte in Europa, Asien und Nordamerika durchgeführt und hält regelmäßig Vorträge bei internationalen SAP-Konferenzen. Martin Munzel ist Mitgründer und Geschäftsführer von Espresso Tutorials, einer führenden SAP-Lernplattform. Vor seiner beruflichen Laufbahn studierte er Betriebswirtschaftslehre und Wirtschaftsinformatik in Göttingen, Paderborn und Nottingham. (Autorenprofil Espresso Tutorials / Linkedin)
 

Weitere Veröffentlichungen von Andreas Unkelbach in 2025

Desweiteren möchte ich gerne die Gelegenheit nutzen und auf zwei weitere Publikationen dieses Jahr hinweisen.

Es handelt sich dabei um eine nachträgliche Aufnahme meiner Keynote am Virtuellen SAP Infotag "SAP S/4HANA Migration" (infoday.io) im Mai 2025 sowie meinen vor Ort Vortrag auf den "FICO Forum Infotage meets ICon" von Convista Consulting, IBS Schreiber und Espresso Tutorials (11. bis 12. Juni 2025 in Köln).
   

Fazit

Meiner Meinung nach bieten alle drei Veröffentlichungen einen guten Überblick in Richtung der Datenmigration nach SAP S/4AHANA aber auch einen Einstieg in das SAP Controlling unter SAP S/4HANA. Als Autor macht es mir besonders viel Freude tiefer in ein Thema einsteigen zu können und seit 2015 hier mit Espresso Tutorials einen Partner gefunden zu haben um hier auch neue Ideen umsetzen zu können.

Ein neues Buchprojekt steht ebenfalls an und ich freue mich sehr darauf hier die Gedanken geordnet "zu Papier" bringen zu können und gleichzeitig auch mein vorhandenes Wissen gebündelt weiter geben zu können.

Vergleichbares erlebe ich auch bei meinen (Online) -Training / SAP Schulungen wo der Austausch und das Vermitteln von Wissen rund um SAP Themen mich immer wieder erstaunt. 

Ein weiterer Punkt ist jedoch auch dieses Blog dass in letzter Zeit ebenfalls wieder langsam Inhalte bekommt und auch oftmals Impulse aus meinen Interessen erhält so dass in letzter Zeit auch wieder Office oder it-nahe Themen aber sogar juristische Themen wieder geschildert werden.

So ein klein wenig bleibt das Interesse an der Juristerei eben doch noch vorhanden und ist nicht nur im Studium (vor Jahrzehnten ;-)) durch die beiden Schwerpunkte Wirtschaftsrecht und Wirtschaftsinformatik verschwunden.

Nun wünsche ich aber viel Vergnügen beim Lesen und bin gespannt auf eine mögliche Rückmeldung zu den Veröffentlichungen. Besonders freue ich mich natürlich auch über Rezensionen auf den üblichen Plattformen :-).

Zum Abschluss #HappyControlling und viel Vergnügen beim Lesen :-)
 

Durch den, spätestens unter SAP S/4HANA erforderlichen, Wechsel von der klassischen Budgetierung (hier: KB) auf das Budgetverwaltungssystem / Budget Controll System (BCS) gibt es auch Anpassungen im Berichtswesen.

Innerhalb der klassischen Budgetierung hatte ich mehrere Rechercheberichte in der Form wie im Artikel "»Rechercheberichte de lux« im Modul PSM FM Haushaltsmanagement" oder "Saldenliste für Fonds im Haushaltsmanagement Saldo gegen Ertrag und Saldo gegen Budget" beschrieben.

Während bisher innerhalb von Rechercheberichte im Public Sector Management einen Knoten innerhalb der Finanzpositionenhierarchie nutzen konnte um mehrere untergeordnete Finanzpositionen auszuwerten bedarf es im Berichtswesen mit Report Painter / Report Writer entweder die Angabe von Einzelwert, Intervallen oder eines Sets (Gruppe) zur Auswertung.

Die grundsätzlichen Unterschiede zwischen Rechercheberichte und Report Painter habe ich im Artikel "Grundlagen: Was sind die Unterschiede zwischen Report Painter und Rechercheberichte?" beschrieben.

Ende 2015 hatte ich im Artikel "PSM Haushaltsmanagement Budgetverwaltungssystem BCS oder klassische Budgetierung" die Grundlagen von BCS erläutert und aktuell gewinnt das Thema Report Painter im Modul PSM auch durch den Artikel "Berichtswesen und Reporting-Tools nach Umstieg von klassische Budgetierung auf BCS im PSM-FM" an Bedeutung.

Eine Frage ist nun aber, neben des fehlenden Merkmals Finanzierungszweck, in der Berichtsbibliothek 4FM an welcher Stelle ich nun meine bisher genutzte Hierarchie der Finanzpositionen nutzen kann.

Exkurs: Finanzierungszweck

Auch unter SAP S/4HANA steht der Finanzierungszweck weiterhin als Stammdatum im Public Sector Management - Haushaltsmanagement zur Verfügung.

Die Hintergründe zum Finanzierungszweck sind beispielsweise im Artikel "Grundlagen: PSM-FM Finanzierungszweck (FMFINCODE-FINUSE) im Hochschulberichtswesen für Drittmittelstatistik" beschrieben.

Eine entsprechende Stammdatenliste (ob per Query wie im Artikel "SAP Query innerhalb des SAP Moduls PSM FM beziehungsweise Haushaltsmanagement" beschrieben oder in der normalen Stammdatenliste) kann weiterhin erstellt werden und als Ergänzung zu einer Saldenliste genutzt werden.

Zu beachten ist jedoch, dass im PSM-FM Rechercheberichten der Finanzierungszweck als Merkmal für Berichte vorhanden war, aber im BCS durch die Berichtsbibliothek 4FM dieser im Report Painter nicht zur Verfügung steht. In der Berichtstabelle FMRBCS "HHM-Reporting für BCS mit Report Writer" ist dieser als Merkmal nicht zur Verfügung, so dass auch keine dynamischen Berichte nach Finanzierungszweck erstellt werden können, sofern ebenfalls Budgetwerte aus BCS und nicht nur aus der klassischen Budgetierung ausgewertet werden sollen.
 

Bisher konnte in den Rechercheberichten ein Knoten der Finanzpositionenhierarchie, was auch eine eigene Finanzposition ist, angegegeben werden und es wurden die untergeordneten Finanzpositionen (sofern beim Merkmal Hierarchie markiert war) mit ausgewertet.

Im Report Painter kann in der Bibliothek 4FM zum Merkmal Finanzposition ebenfalls ein Set jedoch nicht mehr die Hierarchie ausgewertet werden. Tatsächlich ist es nun erforderlich eigene Finanzpositionengruppen anzulegen.

Innerhalb des SAP Anwendungsmenü findet sich die Gruppenpflege unter:

• Rechnungswesen
• Public Sector Management
• Stammdaten
• Kontierungselemente
• Finanzposition
• Finanzpositionengruppe

Hier können Finanzpostionengruppen über die Transaktionen FM_SETS_FIPEX1 (Anlegen), FM_SETS_FIPEX2 (Ändern), FM_SETS_FIPEX1 (Anzeigen) verwaltet werden.

Jedoch ist es recht mühsam nun manuell einzelne Gruppen anzulegen.

Interessant ist daher die ebenfalls im Ordner vorhandene Transaktion FMRP_CI_SET_HIER (Finanzpositionen-Set-Hierarchie aus Stammdatenhierarchie erzeugen).

Bevor dieses näher betrachtet wird sollte noch einmal die Pflege der Standardhierarchie betrachtet werden.

Exkurs: Zuordnung von Finanzpositionen in Standardhierarchie oder Alternative Hierarchie

Für die Standardhierarchie ist in den Stammdaten einer Finanzposition in den Grunddaten im Abschnitt Hierarchiezuordnung eine Übergeordnete Finanzpos. angegeben. Für alternative Hierarchien kann im Register Alternative Hierarchie eine Variante abweichend zur Standardhierarchie 000 mit einer anderen übergeordneten Finanzposition gepflegt werden.
Solche Alnternative Finanzpositionenhierarchienn konnten im Infosystem genutzt werden um alternative Ist-Datenauswertungen zu erstellen.

Die Standardvariante 000 wird automatisch generiert, sobald eine Finanzposition innerhalb eines Finanzkreis/Geschäftsjahr angelegt bzw. importiert wurde.

Im Customizing kann eine davon abweichende Variante gepflegt werden.

Dies ist in der Transaktion SPRO unter

• Public Sector Management
• Haushaltsmanagement Öffentliche Verwaltung
• Stammdaten
• Kontierungselemente
• Finanzposition
• Variante im Finanzkreis/Geschäftsjahr anlegen

möglich.

Dabei muss der entsprechende Finanzkreis angelegt werden und es können hier Variante/Bezeichnung und Geschäftsjahr angelegt werden. Alternativ kann auch auf die Angabe eines Geschäftsjahres für die Variante verzichtet werden.

Betrachten wir uns ein einfaches Beispiel angelehnt am Industriekontenrahmen. Dabei habe ich einfach die ersten vier Ziffern des Sachkontos als Konto behandelt.

Das Sachkonten 6300* Gehälter und Zulagen sind hier der Finanzposition 6300 zugeordnet. Diese wiederum ist der symbolischen Finanzposition PERSONAL (als übergeordnete Finanzposition) und die Finanzposition der obersten Finanzposition AUFWAND zugeordnet.

Im Recherchebericht könnte ich nun den Knoten AUFWAND für alle Konten, PERSONAL für alls Aufwendungen im Bereich Personal oder SACH für Aufwendungen im Bereich Sachmittel bzw. INVEST für alle Investitionen auswerten.

 

Finanzposition	Übergeordnete Finanzposition	Bezeichnung
AUFWAND		AUFWAND
PERSONAL	AUFWAND	Personalaufwand
6300	PERSONAL	Gehälter und Zulagen
SACH	AUFWAND	Sachaufwand
6800	SACH	Büromaterial
INVEST	AUFWAND	Investitionen
0840	INVEST	Fuhrpark

Die Tabelle würde natürlich über den gesamten Kontenplan bzw. der Zuordnung der Finanzpositionen gehen.

In der Sachkontenpflege (Transaktion FS00) wird die Finanzposition im Abschnitt Erfassung/Bank/Zins hinterlegt. Davon abweichend könnte mit der FMDERIVE auch eine gesonderte Zuordnung erfolgen auf die ich in diesem vereinfachten Beispiel nicht eingehen mag.
 

Finanzpositionen-Set-Hierarchie aus Stammdatenhierarchie erzeugen

Beim Start der Transaktion FMRP_CI_SET_HIER kann als Hauptparameter zum aktuell gesetzten Finanzkreis die entsprechende Variante ausgewählt werden. Soll die Standardhierarchie als Vorlage genommen werden ist hier die Variante 000 zu wählen.

Im folgenden Abschnitt kann die Sethierarchieart gewählt werden.

Sethierarchieart "Finanzpositionenset-Hierarchie"

Sofern hier der Punkt "Finanzpositionset-Hierarchie" gewählt wird, werden als Gruppen zu den einzelnen Finanzpositionen identische Gruppen wie die Finanzpositionsbezeichnung gewählt.

Ein ebenfalls relevanter Punkt ist der Punkt "Präfix für Sethierarchieknoten". Dieser wird eigentlich nur beim Punkt "Allgemeine Sethierarchie" benötigt, sofern hier dennoch ein Wert angegeben wird, betrifft dies bei der "Finzpositionenset-Hierarchie" lediglich den obersten Knoten (Oberknoten).

Sowohl mit als auch ohne Präfix wird als Oberknoten die Version 000 und das entsprechende Geschäftsjahr (sofern keines der Standardvariante zugeordnet ist ebenfalls 0000) angelegt.

Wurde ein Präfix zum Beispiel 4BCI_ mit angegeben, ist der oberste Knoten der angelegten Gruppe 4BCI__000_0000 in unserem Beispiel.

Technisch interessant ist, dass in der Tabelle SETHEADER im Feld SETCLASS (Klasse eines Sets) hier das Set 0311 (Finanzpositionengruppe) verwendet wird.

Sethierarchieart "Allgemein-Sethierarchie"

Sofern eine allgemeine Gruppe / Set angelegt werden soll, ist zwingend ein Präfix beginnend mit 4B anzugeben. Auch hier kann unter Präfix setzen zum Beispiel 4BCI_ gewählt werden.

Der Unterschied zur oberen Anlage ist, dass das Set technisch in der Tabelle SETHEADER in der SETCLASS 0000 (Allgemeines Set) gespeichert wird und jedes angelegte Set das verpflichtend mit 4B beginnende Präfix vorangestellt wird. Ergänzt werden könnte dies dann noch mit FI für Finanzposition oder FS für Finanzstelle.

Meine Empfehlung wäre aber hier direkt die passende Setklasse zu verwenden und die Option "Finanzpositionen-Hierarchie" zu verwenden, sofern nichts dagegen spricht. 
 

Auswertung von Sets und Änderungen

Neben der Verwaltung von Sets über die Transaktionen zur Pflege von Stammdatengruppen zum Beispiel für Finanzpositionen über die Transaktionen FM_SETS_FIPEX1 (Anlegen), FM_SETS_FIPEX2 (Ändern), FM_SETS_FIPEX1 (Anzeigen) kann auch auf Tabellenebene eine Änderung oder Auswertung erfolgen.

Am Beispiel von unterschiedlichen SAP Query habe ich dies in folgenden Artikeln ausführlicher erläutert:

• Artikel "Auflösen von Stammdatengruppen nach Einzelwerten - Einzelwerte zu Sets"
• Artikel "Änderungsbelege für Stammdatengruppen im Customizing oder letzte Änderung über Query bspw. für Innenauftragsgruppen"

Neben den CO Innenaufträgen ist dies anhand der Set-Klasse entsprechend auch für die Stammdatengruppen im Modul PSM-FM wie im Beispiel hier die Finanzpositionen möglich.

 

Testlauf

Gerade nach einer Migration nach BCS ist ein wichtiger Punkt in dieser Transaktion der Punkt Testlauf. Hier kann sich das Ergebnis vorab angezeigt werden.

Sofern die Option Testlauf deaktiviert wird, wird auch tatsächlich die Gruppe angelegt. Nun stehen auch zwei weitere Optionen zur Handhabung von widersprüchlichen Sets zur Verfügung.

Im Abschnitt Handh. v. widerspr. Sets kann zwischen folgenden Systemverhalten gewählt werden:

• Hierarchie nicht erstellen
  Wenn entsprechende Sets schon vorhanden sind kann die Generierung abgebrochen werden.
• Gesamte Hierarchie übersteuern
  In diesem Fall werden widersprüchliche Sets, also bereits vorhandene Sets, überschrieben. Die Überschreibung erfolgt jedoch nur, wenn die Oberknoten der widersprechenden Hierarchie (alt und neu) identisch sind.

Wichtig zu beachten, ist dass zu jeder Finanzposition ob nun symbolisch oder tatsächlich eine eigene Finanzpositionengruppe angelegt wird.

Anhand unseres oberen Beispiels würde dies bei der Sethierarchieart "Finanzpositionenset-Hierarchie" wie folgt aussehen.
 

Set	Bezeichnung	Oberknoten	zugeordnete Finanzposition
4BCI__000_0000	4BCI__000_0000
AUFWAND	AUFWAND	4BCI__000_0000	AUFWAND
PERSONAL	Personalaufwand	AUFWAND	PERSONAL
6300	Gehälter und Zulagen	PERSONAL	6300
SACH	Sachaufwand	AUFWAND	SACH
6800	Büromaterial	SACH	6800
INVEST	Investitionen	AUFWAND	INVEST
0840	Fuhrpark	AUFWAND	0840

Ob an dieser Stelle nicht das manuelle Anlegen von Finanzpositionengruppen einfacher ist wäre eine andere Frage insbesondere wenn eine Vielfalt von Finanzpositionen vorhanden sind und die Hierarchie eigentlich relativ flach ist.

Fazit

Nicht nur beim Aufbau sondern auch bei der weiteren Pflege eines übergreifenden Berichtswesen sind auch Überlegungen zu den Stammdaten (neben Berechtigungen) elementar. Im PSM-FM sind hier Finanzstelle, Fond und Finanzposition relevant.

Im Artikel "Grundlagen: Kontierungselemente im Modul Public Sector Management Haushaltsmanagement (PSM-FM) - Finanzposition, Finanzstelle, Fond und FMDERIVE" habe ich diese näher erläutert.

Da sich nun auch das Haushaltsmanagement mit der Erstellung von Report Painter / Report Writer Berichten beschäftigt, mag ich gerne die Gelegenheit nutzen um auf folgendes Angebot hinzuweisen:




Ich biete ein Onlinetraining zum Report Painter mit Bezug auf die Umstellung auf BCS, aber auch allgemein zum Einsatz des Report Painter an.

SAP setzt in SAP S/4HANA auf die Berichterstattung mit Fiori. Doch wie können Sie eigene Berichte im SAP-Finanzwesen erstellen, wenn Ihr Unternehmen weiterhin SAP GUI als Benutzeroberfläche nutzt? Wie können Sie noch Budgetberichte erstellen, wenn Sie in einem öffentlichen Unternehmen arbeiten, welches durch die Migration nach S/4HANA auf das SAP Budget Control System (BCS) wechseln muss bzw. dieses bereits einsetzt? In diesen Fällen bleibt weiterhin der bewährte Report Painter Ihr Berichtswerkzeug der Wahl.

Nähere Informationen finden Sie auf unkelbach.expert wo auch dei aktuellen Termine zum kommendne Online-Training zu finden sind.

Gerade bei umfangreichen Finanzpositionen und einer flachen Finanzpostionenhierarchie gilt es jedoch abzwägen, ob die beschriebene Ableitung oder eine neu konzipierte manuell gepflegte Gruppe interesanter wäre.

Vorteil der Ableitung ist aber in jeden Fall, dass gewohnte Einstiegselemente verwendet werden können und die Vollständigkeit der Finanzpositionen über die Standardhierarchie gewahrt bleibt.

Nach einem Wechsel auf Microsoft 365 und damit auf "Microsoft Excel für Microsoft 365" gibt es ein abweichendes Verhalten bei der Office-Integration von SAP. Dies ist zum Beispiel bei der Excel-Ansicht innerhalb Report Painter / Report Writer Berichten der Fall.

Das Verhalten tritt nur bei Arbeitsplätzen auf, die mehr als einen Monitor nutzen und dies über "Bildschirm erweitern" nutzen.

Die Ansicht in Microsoft Excel oder Microsoft Word wird nicht innerhalb des SAP GUI, sondern außerhalb in einem separaten Fenster geöffnet.

Im aktuellen SAP GUI befindet sich in den Einstellungen unter OPTIONEN > VISUELLES DESIGN > THEME-EINSTELLUNGEN für das Belize oder Quartz Theme die Option "Skalierung für mehrere Bildschirme"  ist diese Option aktiv, wird bei aktivierter Office-Integration die Excel-Ansicht innerhalb des SAP GUI dargestellt.


© SAP SE. Alle Rechte vorbehalten

Bei älteren SAP GUI Versionen, zum Beispiel SAP GUI 7.60, ist diese Option nicht zu finden, so dass an dieser Stelle in Microsoft 365 (bzw. den einzelnen Microsoft Office Apps) folgende Einstellung vorzunehmen.

Hierzu kann unter Microsoft Excel in den einzelnen Anwendungen wie Excel oder Word die unter DATEI > OPTIONEN im Register ALLGEMEIN unter den Benutzerflächeoptionen unter "Bei Verwendung mehrere Anzeigen" von der Option "Für optimales Aussehen optimieren" auf "Für Kompatibilität optimieren (Neustart der Anwendung erforderlich)" gewechselt werden.

In der App Microsoft Excel für Microsoft 365 sieht dieser Dialog wie folgt aus:



Hintergrund dieser Einstellung ist wohl die Anzeige von Office Apps bei hochauflösenden Display und wenn Sie hier mehrere Monitore verwenden (siehe Einleitung). Ab Office 2016 gibt es die Möglichkeit, dass die Apps sich im Anwendungsfenster dynamisch skalieren, um sich anzupassen, wenn zwischen Monitoren mit hoher und niedrigen DPI-Wert gewechselt wird.

Allerdings wirkt sich diese Option wie beschrieben auch auf den SAP GUI aus.

Um diese dynamische Anpassung zu deaktivieren, kann der Kompatibilitätsmodus verwendet werden.

Eine bessere Variante dürfte es jedoch sein, einen aktuellen SAP GUI zu installieren und die Option "Skalierung für mehrere Bildschirme" zu aktivieren.

Diese Option (englisch: "Multi-monitor scaling awareness") bewirkt, dass seitens des SAP GUI auf die Skalierung (Auflösung) des Monitors, auf dem das SAP Fenster aktuell dargestellt wird, reagiert und damit auch die Office-Integration wieder funktioniert.

Themenbereich Office-Integration in SAP

Die Office-Integration ist auch an anderen Stellen schon Thema hier im Blog gewesen. So findet sich das Thema "Office-Integration und Makrosicherheit" im Artikel "Office Integration und leere Excelansicht (Fehlermeldung" wobei hier auch andere Ursachen für die Fehlermeldung "Kein Dokument geöffnet" erläutert wird. Daneben ist mein immer wieder relevantes Highlight noch immer der Artikel "Office Integration - Excelansicht in SAP und Daten kopieren nach Excel" welcher seit 2014 immer wieder einmal aktuell wird ;-).

Warum ist Excel-Inplace (Darstellung von Excel innerhalb des SAP GUI) sinnvoll?

Berechtigerweise kann sich allerdings die Frage gestellt werden, warum ich die Darstellung von Excel-Inplace (also innerhalb des SAP GUI) gegenüber Excel-Outplace (in einem separaten Fenster) bevorziehe.

Gerade in umfangreichen Report Painter / Report Writer Berichten hat die Excel Integration den großen Vorteil, dass einzelne Abschnitte als Tabellenblätter in Excel dargestellt werden. 

Wenn ich nun in einer Berichtsgruppe jedoch mehrere Berichte zusammengefasst habe und über die Navigation im Bericht von einem Bericht auf einen anderen wechsel braucht es eine ganze Weile bis die Datei "Tabelle von ReportWriter" sich aktualisiert. Daneben ist darauf zu achten, dass das SAP GUI stets die übergeordnete Anwendung ist. Entsprechend werden Daten nicht mehr dargestellt, sollte das externe Fenster von Excel separat geschlossen werden. Hier müsste dann umständlich über die Office-Integration die Darstellung von Excel wieder deaktiviert und aktiviert werden.

Daher ist es für mich bequemer, die Integration von Office und die Darstellung von Excel innerhalb des SAP GUI zu nutzen. Nachteil ist vielleicht noch, dass "Speichern unter" nicht aufgerufen werden kann, aber hier hilft die Taste F12 weiter. Alternativ kann die Schnellzugriffsleiste für das Speicherung unter Symbol konfiguriert werden.