Sonntag, 4. November 2018
11:53 Uhr
11:53 Uhr
SAP Query als kundeneigene Transaktion mit Berechtigungen für Tabellenberechtigungsgruppe, Tabellen und Reporttransaktion vergeben
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.
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.
Dabei ist die Namenslogik des Reportnamen wie folgt aufgebaut:
So wird die Query AQ mit der Bezeichnung ZCOFM_PROJEKTE der Benutzergruppe ZBUCH im Standardbereich CS(mandantenabhängig) als Report mit folgender Bezeichnung zugeordnet:
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.
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:
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.
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: Aktuelle Buchempfehlungen besonders SAP Fachbücher sind unter Buchempfehlungen inklusive ausführlicher Rezenssionenzu finden. Mein Weiterbildungsangebot zu SAP Themen finden Sie auf unkelbach.expert.
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
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
- S_TABU_NAM
Anzeigeberechtigung für Tabellen
AUFK Auftragsstammdaten
CEPCT Profit-Center-Stammdaten Texte
- S_TABU_DIS
Anzeigeberechtigung auf Tabellenberechtigungsgruppe
FA RF:Anwendungstabelle
&NC& ohne Berecht.gruppe
- S_TABU_NAM
Anzeigeberechtigung für Tabellen
LFBK Lieferantenstamm (Bankverbindungen)
TIBAN IBAN
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.
Aktuelles von Andreas Unkelbach
unkelbach.link/et.reportpainter/
unkelbach.link/et.migrationscockpit/
Freitag, 14. Juni 2013
15:59 Uhr
15:59 Uhr
Transaktionsart in SE93 ändern
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
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.
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.
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
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.
Weiterbildung Hochschulberichtswesen und Hochschulcontrolling mit SAP
Mittwoch, 31. März 2010
08:33 Uhr
08:33 Uhr
Transaktion anlegen (Report, Parameter) bspw. für SAP Query / Unterschied Parameter- oder Reporttransaktion
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:
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.
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: Hier bietet sich oftmals auch eine geschützte Selektionsvariante ALLGEMEIN an um Standardeinstellungen direkt festzulegen und bestimmte Felder (bspw. Kontengruppen etc.) zu schützen.
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).
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.
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.
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.
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: 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.
Schnelleinstieg ins SAP®-Controlling (CO) – 2., erweiterte Auflage (📖)
Für 29,95 € direkt bestellen
Oder bei Amazon ** Oder bei Autorenwelt
Permalink - SAP