Nachdem ich im Rahmen einer Arbeitsgruppe des Competence Center für Hessische Hochschulen schon einen "Auffrischungsworkshops SAP Query im Hochschulcontrolling und Hochschulberichtswesen" gehalten habe hat sich dann noch ein Tagesseminar zum Thema »SAP Query in SAP ERP« mit Auswertung von Stamm und Bewegungsdaten aus den Modulen des Rechnungswesens (CO, FI, PSM-FM) ergeben.

Dieses war auch relativ schnell ausgebucht und ich hoffe, dass die angebotenen Übungen tatsächlich weiter geholfen haben um die Möglichkeiten mit SAP Query im Hochschulberichtswesen darzustellen.



Eine wichtige Frage, die auch in der Schulung behandelt worden ist, war wie Endanwende später die erstellte Query aufrufen und nutzen können. Selbstverständlich besteht die Möglichkeit über Benutzergruppen und die Transaktion SQ00 eine Query direkt zu starken und berechtigungsseitig hier die Pflege der Query einzuschränken, aber eleganter und praktischer ist es in meinen Augen der erstellten Query eine eigene Transaktion zuzuweisen.

Report-Transaktion für SAP Query

Hierzu kann über die Transaktion SE93 eine sogenannte Reporttransaktion angelegt werden.

Diese Reporttransaktion ruft direkt einen ABAP Report auf und über das Selektionsbild 1000 gelangt man auch direkt in das Auswahlfenster der Transaktion und kann in der Reporttransaktion auch im Punkt Start mit Variante eine passende Variante für die Query anlegen und diese direkt starten um eine bestimmte Vorauswahl in der Selektion zu speichern und hier auch eine Layoutvariante zu hinterlegen.

Reportname zu SAP Query

Die Frage ist nun nur, wie kann der Reportname herausgefunden werden. Im Artikel "Transaktion anlegen (Report, Parameter) bspw. für SAP Query / Unterschied Parameter- oder Reporttransaktion" bin ich schon einmal darauf eingegangen, dass in der Transaktion SQ01 im Menü über QUERY->WEITERE FUNKTIONEN->REPORTNAME ANZEIGEN der zugeordnete Reportname angezeigt werden kann.

Dabei ist die Namenslogik des Reportnamen wie folgt aufgebaut:

• Mandantenabhängige (Standardbereich) Query beginnen mit AQCS
• Globale (Globaler Beeich) Query beginnen mit AQZZ

danach folgt die Benutzergruppe in der die Query zugeordnet ist und der Name der Query. Dieser wird mit == aufgefüllt, so dass eine Gesamtlänge des Reportnamens von 30 Zeichen sich ergibt.

So wird die Query AQ mit der Bezeichnung  ZCOFM_PROJEKTE der Benutzergruppe ZBUCH im Standardbereich CS(mandantenabhängig) als Report mit folgender Bezeichnung zugeordnet:

• AQCSZBUCH=======ZCOFM_PROJEKTE

Nachdem der Reportname zur Query in der Reporttransaktion hinterlegt wird ist nun noch eine Frage, wie die Berechtigungen für die SAP Query-Transaktion vergeben werden können. Hierzu müssen entsprechende Berechtigungsobjekte mit Berechtigungsfeldwerten versehen werden.

Parametertransaktion zu SAP Query

Eine bessere Alternative ist jedoch die Anlage einer Parametertransaktion zu SAP Query. Diese ist im Artikel "Umstellung Reporttranskationen auf Parametertransaktionen zum Aufruf SAP Query" näher beschrieben inklusive einen Hinweis, warum eine Reporttransaktion Probleme bereiten kann.
 

Berechtigungsobjekte und Berechtigungsfeldwerte auf Tabellen und Tabellenberechtigungsgruppe

Dabei ist natürlich nahe liegend das Berechtigungsobjekt S_TCODE "Transaktionscodeprüfung bei Transaktionsstart" mit im Berechtigungsfeld Transaktionscode mit der neu angelegten Transaktion bspw. ZUNKELBACH zu füllen.

Neben der reinen Berechtigung für den Start der Transaktion sind aber auch noch die Berechtigungen für das Lesen der Daten mit der Query erforderlich.

Hier sind zwei Berechtigungsobjekte noch zu füllen.

Das Berechtigungsobjekt S_TABU_DIS "Tabellenpflege (über Standardtools wie zB SM30) ist mit der Aktivität 03 Lesen zu versehen und im Berechtigungsfeld Tabellenberechtigungsgruppe zu hinterlegen. Die Zuordnung von Tabellen zu Berechtigungsgruppen erfolgt mandantenunabhängig über die Transaktion SE54 (Speicherort der Einstellungen ist dann die Tabelle TDDAT Pflegebereiche für Tabellen) einzusehen.

Ferner ist auch das Berechtigungsobjekt S_TABU_NAM "Tabellenzugriff über generische Standardtools" ebenfalls mit der Aktivität 03 und den relevanten Tabellennamen zu pflegen.

Es bietet sich tatsächlich an hier über einen Testuser und der Transaktion SU53 die entsprechenden Berechtigungsfeldwerte zu ermitteln. Im Artikel "SAP Basis Basic oder dank SU53 oder ST01 Trace fehlende Berechtigungen finden" bin ich auch auf die Frage der Berechtigungsprüfung nebst einer Anzeige der fehlgeschlagenen Berechtigungsprüfungen für eine andere Benutzerkennung eingegangen.

Eine Auswertung für Stammdaten im Bereich CO-OM (zum Beispiel "Auswertung sprechender Nummernkreisintervalle von CO Innenaufträgen mit Query Zusatzfeldcoding und Unterscheidung numerischer oder alphanumerischer Schlüssel") verlangte als Berechtigungsausprägung folgende Angaben in den Berechtigungen:

• S_TABU_DIS
  Anzeigeberechtigung auf Tabellenberechtigungsgruppe:
  KA          CO:Anwendungstabelle
  KEC        CO-PA:Customizing

und zum direkten Lesen der Tabellen für die Stammdaten der Innenaufträge sowie  der Stammdaten der Profit-Center (EC-PCA) zu lesen.

• S_TABU_NAM
  Anzeigeberechtigung für Tabellen
  AUFK    Auftragsstammdaten
  CEPCT   Profit-Center-Stammdaten Texte

Während eine Auswertung der Stammdaten im Bereich FI für Kreditoren wie im Artikel "Query über IBAN und Stammdaten Kreditor oder Debitor (Zusatztabellen in SAP Query)" beschrieben folgende Berechtigungen benötigte:

• S_TABU_DIS
  Anzeigeberechtigung auf Tabellenberechtigungsgruppe
  FA   RF:Anwendungstabelle
  &NC&   ohne Berecht.gruppe

und der Stammdaten der Kreditoren (Lieferanten) sowie der IBAN Verbinudng (TIBAN).

• S_TABU_NAM
  Anzeigeberechtigung für Tabellen
  LFBK Lieferantenstamm (Bankverbindungen)
  TIBAN  IBAN

Sollen statt der Kreditoren (Lieferanten) die Debitoren (Kunden) ausgewertet werden ist hier natürlich KNBK Kundenstamm (Bankverbindungen) zu hintelegen.

Gerade die Aussteuerung von Berechtigungen sowie die Umsetzung eines Berechtigungskonzeptes ist ein Grund warum die anwendungsbetreuende Keyuser der jeweiligen Fachabteilungen ebenfalls eng mit der SAP Basis und der Berechtigungsvergabe zusammen arbeiten sollten. Ein weiteres Thema ist hier, insbesondere bei mehreren Mandanten innerhalb des SAP System, auch eine Frage der Namenskonvention. Eine Reporttransaktion wird über einen Workbenchauftrag transportiert und steht damit mandantenübergreifend im System zur Verfügung. Die Query liegt dafür ggf. jedoch im mandatenabhängigen Bereich (es sei denn es ist eine globale Query). Die unterschiedlichen Möglichkeiten zum "Transport von InfoSet mit ABAP-Coding und Query per Transportauftrag" wurden ja schon beschrieben. Sinnvoll kann es hier sein bei kundeneigene Transaktionen als Namensraum Z gefolgt von der Mandatennummer zu verwenden, so dass hier keine Verwechslung entsteht.Sinnvolle Namenskonventionen für kundeneigene Entwicklungen sollten ebenfalls in einen Fachkonzept, wenn nicht sogar im Berechtigungskonzept, hinterlegt werden.

Schulung zu SAP Query

Persönlich hat mir die Ausarbeitung der SAP Schulung zum Thema SAP Query im Berichtswesen viel Freude gemacht und ich hoffe, dass die Begeisterung für die einzelnen Berichtstools und Möglichkeiten gerade im Kontext Hochschulcontrolling und Hochschulberichtswesen hier überzeugend dargestellt worden sind. Eine Darstellung der von mir im Berichtswesen besonders gern genutzten Tools und Möglichkeiten habe ich auch im Buch »Berichtswesen im SAP®-Controlling«  geschildert, dass ebenfalls einen guten Überblick über den Aufbau eines Berichtswesen sowie eine Einführung über "Unterschiedliche Auswertungsmöglichkeiten im Controlling (Report Writer, Recherchebericht, SAP Query) und natürlich Excel ;-)" bietet.

Da das Tagesseminar relativ schnell ausgebucht war bin ich gespannt, ob sich noch einmal eine Nachfrage für ein erneutes Seminar zum Thema finden wird. Ansonsten bleibt es erst einmal bei den Buchempfehlungen die ich auch hier online gerne gebe.

Gerade im Bereich des Berichtswesen auch und besonders für Hochschulen ist auch ausserhalb des Controlling ein sinnvolles Berichtswesen auch daran gekoppelt welche Möglichkeiten zur Auswertung im jeweiligen System zur Verfügung stehen. Daher möchte ich mich auch bei den Teilnehmerinnen und Teilnehmern meiner Schulung bedanken die sowohl eine gute Bewertung als auch durch ihre rege Beteiligung eine Menge an Feedback gegeben haben.

Die Schulung selbst ist relativ umfangreich und anspruchsvoll gewesen, jedoch war die Rückmeldung auch so, dass selbst erfahrende Anwendende noch den ein oder anderen neuen Aspekt dieses Tool kennen gelernt haben. Die Besetzung mit Keyuserinnen und Keyusern aus den Modulen FI, CO, PSM-FM und auch MM sowie geplant HCM hat gezeigt, dass es sinnvoll war hier die Übungen zwar aus den Modulen des Rechnungswesen (CO, FI. PSM-FM) zu nehmen aber so zu wählen, dass diese grundsätzliche Funktionen wie die Nutzung von Join, logische Datenbanken oder auch Zusatztabellen, Zusatzfeldern und Zusatzfeldcoding beschrieben hat.

Teilweise sind die vorgestellten Übungen auch schon in diversen Blogartikeln ausführlich behandelt, allerdings dürfte die Zusammenstellung der Beispiele auch für den ein oder anderen interssant sein. Durch die ausgewählten Beispiele, die sich ursprungsbedingt natürlich in der Hauptsache im CO Umfeld befinden, sollten die verschiedenen Möglichkeiten vorgestellt werden und ich hoffe, dass diese auch für andere Personen übertragbar sind. Sowohl im Finanzwesen als auch im Personalwesen werden tatsächlich auch logische Datenbanken genutzt.

Auf eine Wiederholung der Schulung freue ich mich ebenso wie mir auch das Aktualisieren und Ergänzen der Schulungsunterlagen auf Basis von Rückmeldungen und Fragen Freude gemacht hat. Entsprechend gerne stehe ich mit meinen Angebot für eine künftige Schulung zur Verfügung. Die Schulung slebst ist in vier Abschnitten mit entsprechenden Übungen aufgeteilt und widmete sich nicht nur der Grundlagen von SAP Query mit den einzelnen relevanten Elementen (Arbeitsbereich, Benutzergruppe, Infoset, Query), der Identifizierung von Daten (wo diese gespeichert sind sowie auch die Erweiterung der Query durch lokale Felder, Zusatztabellen und Zusatzfelder inklusive Zusatzfeldcoding das noch weitere Möglichkeiten bietet. Die Übungen zeigten nicht nur die Anwendung dieser Möglichkeiten sondern durch praktische Übungen auch Auswertung von Stamm und Bewegungsdaten aus den Modulen des Rechnungswesens  (CO, FI, PSM-FM).
 

---

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.

---

Ausgangslage:

Für einen PSM Recherchebericht wurde aus der PFCG eine kundeneigene Transaktion angelegt. Nach Aufruf dieser Transaktion erscheinen im Selektionsbild die zusätzlichen Felder "Aktualität der Daten (Lesemodus) sowie Druckeinstellungen und Vorverdichtung. Dieses ist bei anderen Transaktionen von Rechercheberichten oder beim Start über die Transaktion FMEQ (Recherchebericht ausführen) nicht der Fall. Auch wenn diese Felder dann über eine entsprechende Selektionsvariante ausgeblendet werden kann, ist dieses doch iritierend.

Lösung:
Ursache hierfür ist, dass aus der PFCG eine Reporttransaktion statt Parametertransaktion angelegt worden ist. Hier kann jedoch über die Transaktion SE93 der Transaktionstyp von Reporttransaktion auf Parametertransaktion geändert werden.

Dieses ist über

• Bearbeiten
• Transaktionsart ändern

möglich umzustellen.

Der Vorteil einer Parametertransaktion ist, dass einzelne Dynprofelder des Reports vorab belegt werden können. Hier scheinen dann auch die oben geschilderten und auch in der FMEQ nicht auftauchenden Felder ebenfalls automatisch belegt zu sein, so dass hier diese automatisch beim Transaktionsaufruf gefült und ausgeblendet sind. Ein weiterer Vorteil der Paramatertransaktion ist es auch, dass gegebenfalls auch Selektionsvarianten mit ausgegeben werden können.

Im Artikel Transaktion anlegen (Report, Parameter) bspw. für SAP Query ist die Vorgehensweise anhand einer SAP Query erläutert. Gerade beim Einführen von neuen Berichten (so auch Rechercheberichte aus PSM) sollte auch die Vorgehensweise beim Erstellen von Transaktionen beachtet werden.

Innerhalb einer 3-Systemlandschaft (Entwicklung, Test, Produktiv) kann es daher sinnvoll sein erst in einen Testnamensraum (bspw. Y*) entsprechende Transaktionen zu testen und produktiv in einen anderen Namensraum (bspw. Z*) die tatsächlich zu verwendenden Transaktionen anzulegen.

Im Rahmen des Transportwesen ist dabei zu beachten, dass es sich beim Anlegen von Transaktionscodes um Workbench-Aufträge und nicht Customizing-Aufträge handelt, so dass hier (gerade beim Einsatz in einer Mehrmandantenumgebung) auch aus Seiten der Berechtigungen eine Einschränkung beim Transport geben kann. Diese Unterscheidung ist relevant, da Einstellungen eines Customizing-Auftrages mandantenabhängig und eines Workbench-Auftrages mandantenunabhängig sind. Wobei hierbei die Pflege der Transaktionen zwar als Workbench-Auftrag definiert ist, da hierzu entsprechende Tabellen gepflegt werden. Eine Übersicht über vorhandene Transaktionen kann auch in der Tabelle TSTC bzw. TSCT wie unter Verwendungsnachweis von Tabellen in Transaktionen beschrieben erstellt werden.

Problem:
Aus einer Query soll eine entsprechende Transaktion zum Aufrufen der Query erstellt werden.

Lösung:
Über SQ01 kann bei einer Query durch das Menü

Query->
Weitere Funktionen->
Reportname anzeigen

der hinter der Query liegende Reportname angezeigt werden.

Sofern eine Tranaktion für Rechercheberichte (bspw. für das Modul PSM-FM angelegt werden soll ist auch der Artikel "Parametertransaktion für Recherchebericht" interessant.

Dieser kann als kundeneigene Transaktion über die Transaktion SE93 angelegt werden und ggf. über einen Workbench-Transportauftrag in das entsprechende System transportiert. Dieses funktioniert bei anderen Berichten ebenfalls über System->Status im Feld Report.

Hier bieten sich zwei Variante an:

a) Reporttransaktion

Als Reporttransaktion wird die Query, der Report direkt gestartet. Hier könnte nun auch ein Berechtigungsobjekt mit Werten hinterlegt werden, auf die die Berechtigungen der Benutzer geprüft werden. Über das Selektionsbild 1000 gelangt man auch direkt in das Auswahlfenster der Transaktion. Über die Option "Einstiegsbild überspringen" kann der Bericht auch ohne weitere Angaben von Selektionswerten direkt übersprungen werden. Dieses kann zum Beispiel sinnvoll sein, wenn im Bericht schon alle Variablen gefüllt sind und der Bericht nur direkt ausgeführt werden soll. Das Thema Berechtigungen für das Ausführen einer solchen Query-Transaktion ist im Artikel "SAP Query als kundeneigene Transaktion mit Berechtigungen für Tabellenberechtigungsgruppe, Tabellen und Reporttransaktion vergeben" behandelt worden.
 

b) Parametertransaktion

Eine Parametertransaktion ermöglicht es Varianten zu einer Transaktion anzulegen. Hier bietet sich bspw. die Transaktion START_REPORT an.

Hier geben wir in der Parametertransaktion bestimmte Vorschlagswerte zur Transaktion START_REPORT vor und überspringen das Einstiegsbild.

Hierbei werden die Dynprofelder der Transaktion festgelegt. So lautet die Bezeichnung des Feldes Report der Transaktion START_REPORT bspw. "D_SREPOVARI-REPORT". So dass hier der Reportname entsprechend eingegeben werden kann. Interessanter ist hier jedoch noch das Feld Variante (Dynprofeld "D_SREPOVARI-VARIANT"), da hier entsprechend gepflegte Selektionsvariante je Report hinterlegt werden können.

Auf diese Weise kann direkt über die kundeneigene Transaktion eine entsprechende Selektionsvariante zu einen Report (inkl. etwaiger gesperrter Felder) gestartet und ausgewertet werden.

Somit eignet sich diese Transaktionsvariante insbesondere dann, wenn man auch gleich eine Selektionsvariante mit übergeben bzw. entsprechend ausgewählt haben mag.

Anwendungsbeispiele für Parametertransaktionen sind unter anderen in folgenden Artikeln beschrieben:

• "Parametertransaktion für Recherchebericht"
• "Parametertransaktion für Reporwriter"

Hier bietet sich oftmals auch eine geschützte Selektionsvariante ALLGEMEIN an um Standardeinstellungen direkt festzulegen und bestimmte Felder (bspw. Kontengruppen etc.) zu schützen.
 

c) Transaktion aus Benutzermün im Profilgeneratur erstellen.

Neben den genanten Möglichkeiten exisitert auch die Variante aus der PFCG heraus innerhalb eines Benutzermenüs einen Report bzw. einen Bericht (bspw. eine Query) einzufügen. Hier wird ebenfalls eine passende Transaktion generert. Hier ist insbesondere zu beachten, dass per Default auch der Transaktionscode automatisch generiert wird (dieses kann über weitere Optionen deaktiviert werden).

d) Nachtrag 2016: Variantentransaktion

Das Thema Variantentransaktion beziehungsweise kundeneigene Transaktionen zum direkten Aufruf einer vorhandenen Transaktion mit einer angelegten Variante ist im Artikel "Kundeneigene Transaktionen zu Berichten in PSM FM Haushaltsmanagement zum Beispiel Belegjournal anlegen (Variantentransaktion)" beschrieben.

e) Parametertransaktion für SAP Query

Neben der Reporttransaktion für SAP Query bietet sich aber noch mehr ebenfalls eine Parametertransaktion an. Diese ist im Artikel "Umstellung Reporttranskationen auf Parametertransaktionen zum Aufruf SAP Query" näher beschrieben inklusive einem Hinweis, warum eine Reporttransaktion Probleme bereiten kann.


Zusammenfassung
Die Variante der Parametertransaktion ist sicherlich vorteilhaft, wenn entsprechende Selektionsvariante in Verbindung mit Layoutvarianten zu einer Query genutzt werden. Hierbei sollte jedoch geprüft werden, ob eine Berechtigungsprüfung auf diese Transaktion erfolgt. Die Reporttransaktion kann dagegen direkt gestartet werden.

Unabhängig davon werden aber auch die Berechtigungsobjekte/Berechtigungswerte des eigentlichen Report geprüft. Eine Besonderheit könnte bei der Reporttransaktion noch die Möglichkeit der Verwendung eines kundeneigenen Berechtigungsobjektes sein, welches bei Anlage der Reporttransaktion auf entsprechend hinterlegten werten geprüft wird.... wobei dieses auch die Transaktion selbst (S_TCODE) innerhalb der entsprechenden Rolle sein kann.

Grundsätzlich hat die Parametertransaktion ihren Vorteil bei der Verwendung von Selektionsvarianten bzw. wenn bestimmte Daten vorbelegt werden sollen. Dahingehend hat die Reporttransaktion ihren Vorteil, wenn ein Bericht direkt ausgeführt werden soll.

Nachtrag 2020: Transportauftrag (Workbenchauftrag zu SE93 - SE10 - STMS)

Bei der Anlage eines Transaktionscodes wird ein Workbench-Transportauftrag angelegt, so dass die Einträge der Tablle TSTC entsprechend in die wieteren Systeme transportiert werden. Über die SE10 kann dieser Transportauftrag frei gegegeben bzw. transportiert werden. Sofern beim Speichern oder Anlage einer Transaktion keine Abfrage eines Transportauftrages kommt kann es sein, dass hier noch ein Transportauftrag offen ist in dem entsprechende Einträge vorhanden sind, ggf. sollte dieser dann frei gegeben und transportiert werden. Andernfalls werden Änderungen oder neue Transaktionen im estehendnen offenen Transportauftrag des Users gespeichert.




 

---

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.

---