Donnerstag, 9. Oktober 2025
16:48 Uhr
16:48 Uhr
IF oder CASE im ABAP-Zusatzfeld-Coding einer SAP Query - ein Praxisbeispiel mit Vergleich beider Methoden
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.
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.
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
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.
Ü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.
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.
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.
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:
Das Beispiel stammt aus der Publikation zum Schnelleinstieg in das Controlling (CO) mit SAP S/4HANA (siehe Publikationen).
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:
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.
Statt mit verschachtelten IF-Bedingungen kann natürlich auch mit einer CASE Anweisung gearbeitet werden. Hier habe ich das Coding wie folgt angepasst.
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.
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
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
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.
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.
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
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.
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.
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.
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.
Hinweis: Aktuelle Buchempfehlungen besonders SAP Fachbücher sind unter Buchempfehlungen inklusive ausführlicher Rezenssionenzu finden. Mein Weiterbildungsangebot zu SAP Themen finden Sie auf unkelbach.expert.
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
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
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).
- 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).
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 | |
|
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.
ein Angebot von Espresso Tutorials
unkelbach.link/et.books/
unkelbach.link/et.reportpainter/
unkelbach.link/et.migrationscockpit/
Diesen Artikel zitieren:
Unkelbach, Andreas: »IF oder CASE im ABAP-Zusatzfeld-Coding einer SAP Query - ein Praxisbeispiel mit Vergleich beider Methoden« in Andreas Unkelbach Blog (ISSN: 2701-6242) vom 9.10.2025, Online-Publikation: https://www.andreas-unkelbach.de/blog/?go=show&id=1396 (Abgerufen am 25.11.2025)
Keine Kommentare - Permalink - SAP
Artikel datenschutzfreundlich teilen
🌎 Facebook 🌎 Bluesky 🌎 LinkedIn