Im Rahmen der Segmentberichterstattung erfolgt eine Zuordnung zu Segmenten über die Ableitung aus dem Profitcenter. Hier ist das Segment unter Grunddaten als Stammdatum im Profitcenter gepflegt.

Ableitung Segment aus Profitcenter

Die Ableitung Segment über die Profitcenterrechung ist in der neuen Profitcenterrechnung FIN_PCA erfolgt und eine Neuerung gegenüber der klassischen Profitcenterrechnung EC-PCA. 

Aus folgender Abbildung ist diese Zuordnung ersichtlich.



Im Artikel "Segmente in der neuen Profitcenter-Rechnung als Belegaufteilungsmerkmal" bin ich ausführlicher darauf eingegangen.

Kundenerweiterung zur Ableitung eines Segments

Sofern jedoch eine Kundenerweiterung wie im Abschnitt Ableitung Segment durch Kundenerweiterung / Business-Add-In (BAdIs) FAGL_DERIVE_SEGMENT für das Segment und FAGl_DERIVE_PSEGMENT für das Partnersegment genutzt werden sieht dieses etwas anderes aus.



Durch diese BAdI werden abweichend zum Segment im zugeordneten Profitcenter entsprechende Segmente zum Beispiel aus einem Zusatzfeld des Innenauftrages ausgewiesen.

Durch die kundenspezifische Ableitung des Segments per BAdI FAGL_DERIVE_SEGMENT und FAGL_DERIVE_PSGEMENT) ist bei FI-Buchungen (wie zum Beispiel Kreditorenrechnung) oder auch interne Verrechnungen im Controlling das Segment entsprechend der Logik des BAPI abgeleitet.

Dabei erfolgt die Ableitung nach folgender absteigender Hierarchie:

Nach folgender (absteigender) Hierarchie erfolgt die Fortschreibung des Segments auf den entsprechenden Beleg.

1. Manuell gesetztes Segment
   Hier ist es empfehlenswert das Feld Segment in der Feldauswahlliste / Feldstatuspflege der Belegerfassung möglichst an hinterer Position zu setzen, sodass nicht aus Versehen das Segment abweichend zu den anderen Objekten überschrieben wird.
2. BAdI
   FAG_DERIVE_SEGMENT /
   FAGL_DERIVE_PSEGMENT
3. Stammsatz des Profitcenters

Der Aufruf des BAdi erfolgt innerhalb des Funktionsbausteins FAGL_SEGMENT_BELEGPOS_CHECK, sodass hier beim Belegaufbau im Rechnungswesen  FI/CO die Ableitung erfolgt und anschließend die Beleginformation in allen relevanten Berichten im FI für die Hauptbuchsicht zur Verfügung steht.

 

Besonderheit Segmentableitung in der Anlagenbuchhaltung FI-AA

Problematisch ist jedoch, dass der BAdI nicht bei der Aktivierung von Anlagen in der Anlagenbuchhaltung FI-AA erfolgt. 

Im Stammsatz der Anlage wird das Segment nicht durch diesen Badi abgeleitet, sondern zwingend über das hinterlegte Profitcenter. Entsprechend muss hier über einen anderen BAdI hilfsweise ein Profitcenter mit entsprechendem zugeordneten Segment zugeordnet werden (BADI_FIAA_MASTERDATA mit der Methode DERIVE_PRCTR) gesetzt werden. Mehr Informationen dazu liefert der SAP Hinweis 1796962 - "Ableitung Profitcenter: BADI zur Steuerung". Hierdurch kann die Ableitung des Profitcenters und die Fehlerbehandlung beeinflusst werden.

Das über diesen BAdI zugeordnete Profitcenter dient dabei "nur" der Ableitung des Segments und wird nicht direkt mitgebucht, sondern aus der Logik des Zusatzfeldes zum Innenauftrag abgeleitet. 

Für den AfA Lauf wird vergleichbar zur Ableitung FAGL_DERIVE_SEGMENT und FAGL_DERIVE_PSEGMENT ein weiteres BaDI genutzt (BADI_FIAA_DOCLINES unter ERP/ECC siehe SAP Hinweis 698485 - "BADI_FIAA_DOCLINES und Zusatzkontierungen", zur Erweiterung der Funktionalität des BaDI.

Unter S/4 S/4HANA ist das BAdI FAA_DOCLINES_CUSTOMER zu verwenden, wie im SAP Hinweis 2960690 - "Unvollständige What’s-New-Information „BAdI: Kundenspezifische Änderung der Einzelposten im Anlagenbeleg“ (SAP S/4HANA 1909)" erläutert wird, wodurch ab Release 1909 das BaDI FAA_DOCLINES_CUSTOMER sowohl BADI_FIAA_DOCLINES) als auch die Kundenerweiterung Substitution von Gegenkonten bei Abgang, Zugang ... (AINT0002) ersetzt.

Im Gegensatz zur Zugangsbuchung (Bestandskonten) erfolgt die AfA Buchung auf das Profitcenter des zugeordneten CO Innenauftrages sowie Segment im Zusatzfeld, dass dann dem Segment in den Anlagenstammdaten entspricht.

In unseren Fall geht es nun aber um das Berichtswesen bzw. die Darstellung der Segmente in den Stammdaten für Innenauftrag und Kostenstelle und nicht um die Buchung auf den Ergebniskonten.
 

Ableitung der Segmente

Die angesprochenen Zusammenhänge (Segment, Zusatzfeld, Auswertung von CI_Zusatzfeldern) habe ich bereits in folgenden Blogartikel behandelt:

• "Segmente in der neuen Profitcenter-Rechnung als Belegaufteilungsmerkmal"
• "Betriebe gewerblicher Art (BgA) und Belegaufteilungsmerkmale Profitcenter, Segment, Funktionsbereich und Geschäftsbereich"
• "Stammdatenerweiterung von CO-Objekten am Beispiel ergänzende Kostenstelle beim Innenauftrag"
• "Auswertung per CMOD eingeführter kundeneigener Felder Kostenart, Kostenstelle und Innenauftrag per Stammdatenverzeichnis und SAP Query"

Nun ergibt sich aber das Problem, dass in einer Stammdatenliste über die CO Innenaufträge auch das jeweils abgeleitete Profitcenter zum CO Innenauftrag ausgegeben werden soll.

Stammdatenliste Innenauftrag und Berücksichtigung der Ableitung der Segmente aus Zusatzfeld

Im Rahmen einer Stammdatenliste kann dieser BAdI jedoch nicht aufgerufen werden und so kommt es zur Anforderung, dass in einer Stammdatenliste über CO Innenaufträge auch das jeweils zu buchendes Segment mit ausgegeben wird.

Hier verwenden wir eine SAP Query auf deren Aufbau ich heute nicht eingehen mag, sondern nur die Ausgabe des Segments erläutern möchte.

Lokale Zusatzfelder in SAP Query

Neben der reinen Auswertung von einzelnen Tabellenfeldern kann innerhalb der Query auch die Ergebnisse verarbeitet werden. Um einzelne Felder weiter zu bearbeiten, können Sie über SPRINGEN -> FELDAUSWAHL -> FELDAUSWAHL über die Funktion BEARBEITEN-> KURZBEZEICHNUNGEN -> EINSCHALTEN einzelne Felder eine Kurzbezeichnung zuordnen.

Diese Kurzbezeichnungen sind notwendig, da wir auf diese dann Bezug nehmen, wenn wir ein lokales Feld mit einer Formel anlegen. Dieses geht über
BEARBEITEN->LOKALES FELD->ANLEGEN.
Dieses Lokale Feld wird dann in der Feldgruppe angelegt, in der wir uns gerade befinden. Elegant wäre es natürlich, wenn wir im Infoset eine entsprechende leere Feldgruppe definiert hätten, es geht aber auch ohne.

Für dieses Feld werden dann entsprechende Eigenschaften festgelegt und über eine Berechnungsvorschrift kann auf andere Felder Zugriff genommen werden.

Lokales Feld für Segmente aus CEPC (Profitcenter) und Zusatzfeld AUFK (Innenauftrag)

Durch Verknüpfung mit der Stammdatentabelle von Profit Center Tabelle CEPC  habe ich folgenden Felder eine Kurzbezeichnung gegeben:

Tabelle CEPC Feld SEGMENT
Segment für Segmentberichterstattung   SEG_PCTR
Zusatzfeld Query TEXT_CEPC_SEGMENT
Text:Segment für Segmentberichterstattung SEGT_PCTR

Für die Innenaufträge gibt es jedoch ebenfalls Zusatzfelder per CI.
Tabelle AUFK Feld Z_SEGMENT
Segment für Segmentberichterstattung SEG_IA
Zusatzfeld Query TEXT_AUFK_Z_SEGMENT
Text:Segment für Segmentberichterstattung SEGT_IA

Sofern nun das Zusatzfeld im Innenauftrag gepflegt ist, würde hier auch bei der Buchung das entsprechende BAdI aktiv werden und entsprechend möchte ich in meiner Stammdatenliste auch nicht das Segment aus dem Profitcenter, sondern aus dem Zusatzfeld angezeigt bekommen.

Lokale Felder in Query mit Berechnungsvorschrift zur Ausgabe Segment

Die Lösung sind hier zwei lokale Zusatzfelder innerhalb der SAP Query.

Lokales Feld Segment:
Kurzbezeichnung / Feldbezeichnung / Überschrift: Segment
gleiche Eigenschaften wie Feld SEG_IA

Berechnungsvorschrift (komplexe Berechnung):

Bedingung: SEG_IA <1
Formel: SEG_PCTR
Sofern das Feld nicht gepflegt ist, gibt die Query hier 0 aus und es wird das Segment aus dem Profitcenter ausgegeben.

Bedingung: SEG_IA >0
Formel: SEG_IA
Ist das Feld jedoch gepflegt, kann direkt das Segment aus dem Innenauftrag ausgegeben werden.

Vergleichbar verfahre ich beim Text für das Segment.

Lokales Feld SEGMENTT

Kurzbezeichnung: SEGMENTT
Feldbezeichnung / Überschrift: Text Segment
Gleiche Eigenschaften wie Feld SEGT_IA

Berechnungsvorschrift (komplexe Berechnung):
Vergleichbar zum Segment wird hier auch mit Segmenttext verfahren

Bedingung: SEG_IA < 1
Formel: SEGT_PCTR
Text zum Segment aus Profitcenter, sofern kein Segment im Zusatzfeld Innenauftrag gepflegt wurde

Bedingung: SEG_IA > 0
Formel: SEGT_IA
Hier wird der Text zum Segment abgeleitet aus dem Zusatzfeld des Innenauftrages ausgegeben.

In der Query selbst wird in der Grundliste nun nur die beiden lokalen Felder ausgegeben.

Denkbar ist darüber hinaus eine Selektion nach Segment sowohl über das Segment im Profitcenter als auch Segment im Zusatzfeld Innenauftrag.

Segmente als Selektionsfelder bei SAP Query

Im Ergebnis habe ich jetzt eine Stammdatenliste mit den entsprechenden Segmenten.

Allerdings sind diese als Selektionsfelder nicht als entweder/oder, sondern als und zu verwenden, sodass ich hier nicht nach beiden Ausprägungen alle Felder erhalte. 

Ziel der Auswertung ist es ja alle dem Segment zugeordneten CO Innenaufträge auszuwerten, so dass sowohl Innenaufträge ohne gepflegtes Segment im Zusatzfeld (hier wäre das BaDI aktiv) als auch solche mit gepflegten Zusatzfeld relevant. Eine Selektion über das Segment macht an dieser Stelle also nur Sinn, wenn nach Innenaufträgen mit gepflegten Segment im Zusatzfeld separat zum Segment im zugeordneten Profitcenter gesucht werden soll. Im Ergebnis wären hier aber zwei Felder Segment (A Segment das Profitcenter, B Segment im Zusatzfeld) in der Selektionsmaske und es sollte klar sein, dass entweder nach A oder nach B gesucht werden kann oder aber beide Felder leer gelassen werden, so dass eine Stammdatenliste über alle CO Innenaufträge mit passenden Segmenten erstellt wird.

Somit kann ich entweder nach der Zuordnung des Segments über das Zusatzfeld (Tabelle AUFK Feld Z_SEGMENT) oder über das Segment aus dem zugeordneten Profitcenter (Tabelle CEPC Feld SEGMENT) selektieren aber nicht über beide Felder gleichzeitig.

Sofern aber keine Selektion über Segment , sondernnur über Auftragsnummer oder verantwortliche Kostenstelle / Profitcenter erfolgen soll bietet sich eine solche SAP Query als Stammdatenliste durchaus an, insbesondere da in dieser Stammdatenliste auch noch weitere Daten mit ausgegeben werden können.


Damit ist die Anforderung einer Stammdatenliste zu Projekten bzw. CO Innenaufträgen erfüllt.
Das Thema SAP Query ist hier im Blog schon häufiger ein Thema, daher verweise ich auch auf folgende Kurzanleitung dazu.

 

---

Hinweis:

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

---

Reddit hatte ich jetzt als Quelle zur Lösung von SAP Problemen auch noch nicht in Betracht gezogen. Entsprechend neugierig bin ich an die Problemanalyse gegangen und habe auf Reddit einen hoffentlich hilfreichen Hinweis gefunden und mag die Lösung hier gerne festhalten. Ich bin gespannt, ob dies tatsächlich der Fehler war, An anderen Rechnern ist das erwähnte Zertifikat nicht installiert und die Office Integration funktioniert dennoch aber zumindest, erscheint es, als spannender Ansatz je nach Systemumgebung. Ich werde noch ein Update nachreichen, sobald der Lösungsansatz geprüft wurde.


Ausgangslage
Im Rahmen der Office-Integration (bspw. in Report Painter Berichten) erscheint bei Anwendende eine leere Excel Arbeitsmappe und nur der Hinweis auf Makros. Allerdings gab es dies Phänomen nur bei einem Arbeitsplatz während bei einem anderen dies kein Problem war. Im ersten Moment dachte ich, dass es am Trust-Center und hier die Makroeinstellungen lag. Diese können unter Excel  DATEI > Optionen > Trust Center > "Einstellungen für das Trust Center"  bearbeitet werden.



Das Thema hatte ich schon damals im Artikel "Office Integration und leere Excelansicht Leere Ansicht statt Excel bei Office-Integration in SAP Berichten wie Kostenstellen Ist/Plan/Abweichung" angesprochen und daher die Einstelungen verglichen die jedoch beim funktionierenden Arbeitsplatz identisch zum Arbeitsplatz an dem die Office Integration nicht funktionierte war.

 Im Trust Center von Excel (Datei->Optionen->Trust Center) ist im Punkt "Einstellungen für das Trust Center ..." im Abschnitt "Vertrauenswürdige Herausgeber" kein  Eintrag für SAP AG vorhanden (ausgestellt für SAP AG). 



Dies ist der wesentliche Unterschied zwischen einen Rechner mit funktionierender Office Integration gegenüber einen mit leerer Arbeitsmappe.

Problem: Es werden keine Daten bei Office-Integration in Report Painter Berichten angezeigt

Nachvollziehbar ist das Problem beim Aufruf eines Kostenstellenberichtes basierend auf Report Painter zum Beispiel unter Rechnungswesen > Controlling > Kostenstellenrechnung > Infosystem > Berichte zur Kostenstellenrechnung > Plan/Ist-Vergleiche > Kostenstellen: Ist/Plan/Abweichung oder per Transaktionscode S_ALR_87013611.

Nachdem eine Kostenstelle ausgewertet wurde kann unter "Optionen / Office Integration" die Art der Ausgabe von "Inaktiv" auf "MS Excel" umgestellt werden. Am Arbeitsplatz wo die Integration nicht funktioniert gab es eine Fehlermeldung bzgl. deaktivierter Makros am funktionierenden Arbeitsplatz war nun die Excel Oberfläche zu sehen inklusive Daten. Am anderen Arbeitsplatz waren keine Daten vorhanden.

Im Beitrag auf Reddit "Adding SAP as a trusted pulisher in Excel" (Original) bzw. "SAP als vertrauenswürdigen Herausgeber in Excel hinzufügen" (Übersetzung) ist eine Lösung veröffentlicht worden. Allerdings gibt es auch Verweise auf passende SAP Hinweise.

SAP Hinweise zu Excel und SAP Office Integration

Das notwendige Zertifikat sowie Lösung ist im SAP Hinweis 1826481 - Microsoft Excel: digitale Signatur für VBA-Makros zu finden. Unter Anlagen ist die Datei "certificate.cer" zu finden. Diese kann wie im SAP Hinweis "3247649 - SAP GUI for Windows/Desktop Office Integration: Die von Microsoft freigegebenen Sicherheitspatches verursachen Makroprobleme" beschrieben am Computer als Vertrauenswürdiger Herausgeber installiert werden.

Für die verwendeten Vorlagen der SAP (dazu später mehr) müssen korrekt signierte Dokumente und gültige Zertifikate  vorhanden sein. 

In vorherigen Excel Versionen gab es bei der Makrobenachrichtung neben der Schaltfläche "Aktivieren" auch die Option "Gesamten Inhalt des Heruasgebers vertrauen", welche nun nicht mehr vorhanden ist. Weitere Einstellungen wären im Trust Center bei den Makroeinstellungen entweder "Alle VBA-Makros deaktivieren, außer digital signierten Makros" oder "Alle Makros aktivieren (nicht empfohlen, weil potenziell gefährlicher Code ausgeführt werden kann)" sowie die Option "Zugriff auf das VBA-Projektmodell vertrauen". Im Dialog bei Öffnen von Excel können die Makros nicht ausgeführt werden und der Herausgeber (bzw. das Zertifikat kann nicht mehr dynamisch als Vertrauenswürdiger Heruasgeber hinzugefügt werden. 

Interessant ist dabei, dass ich noch ein altes Zertifikat installiert hatte (Vertrauenswürdiger Herausgeber) und die Office-Integration auch mit den oben erwähnten Angaben "Deaktivieren von VBA-Makros mit Benachrichtung" sowie ohne "Zugriff auf das VBA-Projektmodell vertrauen" die Anzeige in Excel funktionierte.


Konkret wird die Ursache des Problems im SAP Hinweis "3507007 - Microsoft-Excel-Integrationsprobleme mit SAP nach Microsoft-Office-Upgrade" mit der Aussage "Da Office 365 freigegeben ist, müssen aufgrund erhöhter Sicherheitsanforderungen signierte Makros aus jeder Anwendung verwendet werden." festgehalten und dabei auf die Hinweise 1826481 (siehe oben) sowie "3261967 - Makroprobleme bei Verwendung von Excel Inplace in Report-Painter-Berichten"  verwiesen.

Sollten bei der Office Integration nur noch der Hinweis Makros deaktivieren und nicht zulassen leigt dies daran, dass VBA-Makros aus dem Internet in Office in aktuellen Sicherheitspatch standardmäßig blockiert werden.

Ablageort der Tabellenvorlage für Reportwriter (Transaktion OAOR)

Die Tabellenvorlagen sind in der Transaktion OAOR (Business Document Service: Dokumente) ersichtlich. Hier ist Klassenname REPORTWRITER und als Klassentyp OT (Andere Objekte) zu wählen. Nach Bestätigung von Ausführen sind hier die Tabellenvorlagen für die einzelnen Versionen zu finden. Beispiele sind Default workbook for MS Excel 97-2003 (SAPrpwoi.xls), Default workbook for MS Excel 2007- (SAPrpwoi.xlsm). Auch andere Vorlagen sind dabei zu sehen.

Die aktuellen Tabellenvorlagen sind zum Download als Anlage im SAP Hinweis "1992004 - Report Writer: Gültigkeit der digitalen Signatur in Office-Integration-Excel-Vorlage" zu finden.

An dieser Stelle auch direkt der Hinweis im kommenden Abschnitt "Zertifikate verlängern".

Für die ALV Listen ist als Klassenname ALVLAYOUTTEMPLATES  verwendbar. Hier im Artikel geht es jedoch um die Excel-Ansicht bzw. Office Integration in Report Painter bzw. Report Writer Berichten.
 

Lösung Option 1: SAP als vertrauenswürdigen Herausgeber in Excel hinzufügen

Diese Vorlage kann geöffnet werden und aus dieser Datei kann aus der Vorlage das Zertifikat exportiert werden. Alternativ kann das Zertifikat aber auch aus der Anlage zum Hinweis 1826481 entnommen werden.

Die Zertifatsdatei kann unter "Computerzertifate verwalten" am einfachsten zu finden durch Windows Taste und Eingabe "Zertif" nun kann in der Zertifikatsverwaltung "unter "Zertifkate - Lokaler Computer" im Ordner "Vertrauenswürdige  Herausgeber" über die rechte Maustaste unter Alle Aufgaben > Importieren die Zertifikatsdatei importiert werden. Als "normale User" gibt es hier jedoch die Meldung "Fehler beim Importvorgang. Der Speicher ist entweder schreibgeschützt, ist voll oder kann nicht korrekt geöffnet werden." Entsprechend sind hier vermutlich Adminstrationsberechtigungen erforderlich.

Zertifikate verlängern

Ein weiterer wichtiger Punkt ist, dass die Gültigkeit der Zertifikate auch beschränkt sind. So ist ein Zertifikat aktualisiert am 15. Januar 2025 bis zum 11. Januar 2027 gültig und muss entsprechend danach aktualisiert werden. Nähere Informationen dazu sind im SAP Hinweis "1992004 - Report Writer: Gültigkeit der digitalen Signatur in Office-Integration-Excel-Vorlagen abgelaufen" zu finden.

Lösung Option 2: Alternative: Makros erlauben

Weniger elegant und möglicherweise ein Sicherheitsproblem ist es im Trust-Center die Option "Aktivieren von VBA-Makros (nicht empfohlen, da potenziell gefährlicher Code ausgeführt werden kann)" zu aktivieren. Hier ist dann bei der Office-Integration Microsoft Excel 2007 zu wählen, da hier die Vorlage XLSM statt XLS genutzt wird. Makros sollen in aktuellen Excel-Versionen als XLSM genutzt werden. Nachteil ist, dass damit auch andere VBA Makros bspw. Makroviren ausgeführt werden können.

Weitere Excel und SAP Artikel

Ein anderes Problem ist noch, wenn Excel nicht inplace (also innerhalb der SAP Oberfläche) sondern im separaten Fenster mit den SAP Berichten geöffnet wird. An dieser Stelle verweise ich aber gerne auf meinen Artikel "SAP und Office Integration Excel im SAP GUI (Excel-Inplace) oder als separates Fenster (Excel-Outplace)".

Die Besonderheit der Vorlagen von SAP Excel Office Integration ist nebenbei, dass hier die Farbtalle von Exce angepasst wird und individuelle Makros hinterlegt sind. MS Excel verweist dabei auf XLS und MS Excel 2007 auf  XLSM als Dateiart. Weiter Besonderheiten hatte ich im Artikel "Office Integration - Excelansicht in SAP und Daten kopieren nach Excel" zusammengestellt insbesonder bzgl. der Farben der Darstellung.
 

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 :-)