Im Rahmen einer Überarbeitung eines PSM-FM Berichtswesen sollen neben den Rechercheberichten auch Varianten zu Einzelpostenlisten als eigene Transaktion in ein Benutzermenü (siehe Artikel "Benutzereigene SAP Menüs (Favoriten, Benutzermenü, Bereichsmenü)") hinterlegt werden. Auf diese Weise können Infouser direkt bestimmte Informationen, so zum Beispiel Sachmittel, als Liste auswerten ohne, dass sie vorher genau auswählen müssen ob sie nun Personalkosten, Lehrbeauftragte und Hilfskräfte oder Sachmittel angezeigt bekommen wollen.
Ferner können durch die geschickte Wahl einer Variante auch erledigte Positionen, wie abgebaute Mittelbindungen, ausgeblendet werden, so dass nur die relevanten Positionen innerhalb einer Einzelpostenliste dargestellt werden und später auch nach Excel exportiert werden können (siehe auch "Grundlagen - Berichte von SAP nach Excel exportieren" )

Rechercheberichte

Die Grundlagen zur Erstellung eines Recherchebericht in PSM-FM (Public Sector Management-Haushaltsmanagement) habe ich in den Artikeln "Saldenliste für Fonds im Haushaltsmanagement Saldo gegen Ertrag und Saldo gegen Budget" und "Recherchebericht Budget + Ertrag ggü. Aufwand" ausführlich beschrieben. Allerdings sind Rechercheberichte mittlerweile auch im Bilanzreporting oder in der Ergebnisrechnung ein Berichtstool wie im Artikel "Rechercheberichte im Modul FI (Bilanzanalyse)" gezeigt wird.

Solche Rechercheberichte können als Parametertransaktion, wie im Artikel "Parametertransaktion für Recherchebericht" beschrieben als kundeneigene Transaktion angelegt werden. Der Unterschied zwischen den einzelnen Transaktionsarten ist unter anderen auch im Artikel "Transaktion anlegen (Report, Parameter) bspw. für SAP Query / Unterschied Parameter- oder Reporttransaktion" beschrieben.

Bei der Erstellung von Rechercheberichten ist auch der Artikel "»Rechercheberichte de lux« im Modul PSM FM Haushaltsmanagement" lesenswert.


Nun soll aber für eine vorhandene Transaktion eine entsprechende Variante einer Einzelpostenauswertung angelegt werden.

Belegjournal - Obligo/Ist Alle Buchungen

Innerhalb des Belegjournal (Transaktion FMRP_RFFMEP1AX) zu finden unter

• Rechnungswesen
• Public Sector Management
• Haushaltsmanagement
• Infosystem
• Einzelposten
• Obligo und Ist
• Alle Buchungen (Transaktion FMRP_RFFMEP1AX )

sind verschiedene Varianten zur Vorbelegung des Selektionsbildschirm angelegt worden.
 

Varianten zum Belegjournal PSM-FM Einzelposten

Hierbei sind verschiedene Felder schon ausgefüllt (u.a. auch mit Kennzeichen GPA ausschalten siehe Artikel "SAP Berichte alter Name Kostenstelle (falscher Stichtag)" oder auch "PSM: Selektionsvarianten und Wertübernahme aus vorherigen Selektionen") und müssen daher durch die Infouser nur noch um die relevanten Fonds oder Finanzstellen ergänzt werden.. Ein wichtiger Punkt ist auch hinter der Freien Abgrenzung unter den Obligo-Einzelposten der Punkt "Position erledigt" welcher per Optionen als Einzelwert aktiviert mit Leerzeichen gewählt sein sollte um abgebaute Mittelbindungen, die erledigt sind, nicht mehr anzeigen zu lassen.

Für die Anzeigevarianten (benutzerübergreifend oder benutzerspezifisch) ist hier auch das Berechtigungsobjekt S_ALV_LAYO mit der Aktivität 23 für Pflegen. Ist die Berechtigung nicht vorhanden können nur benutzerspezifische Layoutvarianten gespeichert werden.

Neben der Variante ALLGEMEIN sind hier auch SACH für Sachmittel und PERSONAL für Personalmittel angelegt worden, so dass über diese Varianten entsprechende Selektionen vorweggenommen werden können und die Infouser direkt mit dieser Variante arbeiten können.

Nun sollen für diese einzelnen Varianten kundeneigene Transaktion (als Z* oder Y*) angelegt werden.

Der erste Gedanke wäre hier tatsächlich, vergleichbar zu CO Berichten eine sogenannte Variantentransaktion anzulegen.

Variantentransaktion anlegen

Anstatt hier direkt anhand des Belegjournal das Beispiel durchzugehen möchte ich die folgenden Schritte mit einen CO Bericht erläutern.

Nehmen wir an, dass für den Bericht S_ALR_87013611 eine entsprechende Variante ALLGEMEIN angelegt ist. Nun kann über die Transaktion SE93 eine neue Transaktion angelegt werden.

Nachdem der neue Transaktionscode angegeben worden ist ist hier zum Einen ein Kurztext für die Transaktion anzugeben und als Startobjekt eine Auswahl getroffen werden.

Die erste Wahl wäre hier

"Transaktion mit Variante (Variantentransaktion)".

Danach kann die ursprüngliche Transaktion ausgewählt werden, in unseren Beispiel also S_ALR_87013611 und über das Feld Transaktionsvariante die entsprechende Variante der Transaktion. Leider stehen hier dann nicht die angelegte Varianten zur Verfügung. Gleiches gilt leider auch für das Belegjournal. Vermutlich würde diese Art der Transaktion mit Varianten der Transaktion KOK5 (CO Innenauftrag Stammdatenliste) funktionieren.

Also der zweite Versuch

"Programm und Selektionsbild (Reporttransaktion)"

Hier kann der Report (Technische Info) zur Transaktion hinterlegt werden z.B. GP4QLQKH46VZJ3P1A40A23S3HJG850 für S_ALR_87013611 .

Hier funktioniert dann auch für das Selektionsbild 1000 der Start mit der Variante die direkt hinterlegt werden kann.

Leider ist dieses nicht möglich für den Report hinter den Belegjournal (Report RFFMEPGAX zur Transaktion FMRP_RFFMEP1AX) Es erfolgt die Fehlermeldung "Es wurden keine geeigneten Varianten für Bild 1000 gefunden".

Somit bleibt auch hier nur die vertraute

"Transaktion mit Parametern (Paramtertransaktion)"

Hier können nun ebenfalls für die Transaktion START_REPORT unter anderen die Felder

• Reporttyp
• Report
• Erweiterter Name
• Variante

mit Werten versorgt werden.

Dazu wird in der Transaktion SE93 eine Parametertransaktion angelegt mit den Vorschlagswerten für die Transaktion START_REPORT. Wichtig ist nun, dass das Feld Einstiegsbild überspringen aktiviert wird. Ferner sollten im Abschnitt Klassifikation die GUI EIgenschaften geerbt werden. Nachdem die Transaktion START_REPORT mit Enter bestätigt worden sind, kann per F4 Auswahlhilfe in der Tabelle mit Vorschlagswerten die einzelnen Dynprofelder ausgewählt werden.

Interessant sind nun folgende Felder

Parametertransaktion für Recherchebericht RFFMEPGAX

Name des Dynprofeldes	Wert
D_SREPOVARI-REPORT	RFFMEPGAX
D_SREPOVARI-VARIANT	Die angelegte Variante bspw. SACH oder PERS

Sofern nun diese neu angelegte Transaktion gestartet wird, wird automatisch das Belegjournal mit den entsprechenden vorbelegten Feldern gestartet. Im Unterschied zu der eigentlichen Transaktion FMRP_RFFMEP1AX sind hier zwar noch weitere Abschnitte im Selektionsbild eingeblendet (Obligo/Ist und FI-Beleg), was am aufgerufenen Report liegt, aber auch diese Felder können per "Feld schützen" vor unbeabsichtigten Änderungen geschützt werden. Somit können also neben Recherchberichten auch Varianten des Belegjournal als eigene Transaktion angelegt werden.

Varianten schützen

Da diese Varianten durch die Parametertransaktion erwartet werden und die Transaktion START_REPORT nicht gegen das Berechtigungsobjekt S_TCODE geprüft wird sondern lediglich der hinter der Transaktion liegende Report (Berechtigungen für Recherchebericht oder auch Belegjournal) ist es notwendig, die Varianten zu speichern und die Option Variante schützen zu wählen.

Sollten einmal geschützte Variante dennoch bearbeitet werden, ist sicherlich der Hinweis auf den Artikel "Frühjahrsputz oder geschützte Varianten und nicht mehr benötigte Rechercheberichte entfernen oder reorganisieren", aber auch die Notwendigkeit angelegte Berichte ordentlich zu dokumentieren ist auch im Artikel "Fachliche und technische Dokumentation von Selektionsvarianten und individuelle Berichte in SAP identifizieren" mit einigen Empfehlungen bedacht worden.

Der Vorteil an solcherart angelegten Transaktionen zum direkten Aufruf von Varianten von Standardberichten ist, dass man hier direkt auf diese Transaktionen im Support verweisen kann und das Berichtswesen nicht mehr innerhalb eines Handbuch auf verschiedene Handhabungen eines bestehenden Berichtes verweisen muss sondern hier die Möglichkeiten vorhanden sind die gewünschte Information in einer gewünschten Art und Weise darzustellen ohne dass dabei ein Missverständnis zustande kommt oder aber SAP wieder einmal ganz und gar andere Daten ausspuckt als der Berichtsempfänger eigentlich erwartet hätte.

Dennoch oder vielleicht auch gerade deswegen sollte sich hier sehr genau darüber Gedanken gemacht werden welche Berichte zur Verfügung gestellt werden und ferner sollte man sich darüber bewusst sein, dass weiterhin für die Endanwende die Möglichkeit besteht eine eigene Variante des Berichtes auszuwählen oder gar eine individuelle Berichtsvariante abzuspeichern. Gerade an dieser Stelle ist das Berichtswesen gleichzeitig mit Berechtigungswesen zu verknüpfen.

Einige interessante Ansätze liefern hier die Artikel "Belegartberechtigung F_BKPF_BLA" oder auch "SAP BC: Personalkontenberechtigungen". Auch wenn ich meine Diplomarbeit zur Erlangung des Grades eines Diplom-Betriebswirt (FH) über das Thema: "Berechtigungswesen in SAP auf Basis der Überarbeitung des vorhandenen Konzeptes der FH Gießen-Friedberg im Bereich Finanzwesen und Controlling" nicht veröffentlciht habe, mag ich an dieser Stelle doch die verwendete Literatur empfehlen und denke mir, dass Grundlagen wie "Welche User haben die Berechtigung zur Auswertung einer bestimmten Kostenstelle oder Innenauftrag?" auch weiterhin ihre Bedeutung und Berechtigung im Werkzeugkasten eines Keyusers haben sollten.

Nicht ohne Grund ist der Artikel "Unterschiedliche Auswertungsmöglichkeiten im Controlling (Report Writer, Recherchebericht, SAP Query) und natürlich Excel ;-)" stellvertretend für die Ansicht, dass heutzutage ein SAP Modul übergreifendes Denken und Nutzen der Werkzeuge der Module PSM-FM (Public Sector Management - Funds Management (Haushaltsmanagement)), CO (Controlling) aber auch FI (Finanzbuchhaltung) und HCM (Personalwesen) elementar für ein integratives und wirkungsvolles Berichtswesen, dass sicherlich nciht nur im Hochschulberichtswesen relevant ist. 

Wichtig ist dabei, dass man sich aber auch über die Grenzen einer solchen Vorgabe im Klaren sein sollte und darauf achten muss, dass entsprechende Berichte weiterhin gepflegt werden müssen und spätestens zum Jahresabschluss die Varianten gepflegt werden sollten, was ihren Zeitraum oder andere Werte betreffen mag. So flexibel hier Berichte auch sein mögen, so pflegeintensiv kann hier auch das Vorgehen sein und daher ist eine Dokumentation auch ein wesentlicher Teil eines sinnvollen Berichtswesen und sei es auch nur, dass Nochfolgende CO Keyuser später einmal in ein Fachkonzept Controlling schauen können und nicht dazu gezwungen sind die Dokumentation selbst noch einmal umzuschreiben um ein Verständnis für das dahinter liegende Berichtswesen zu erlangen oder gar aus Versehen scheinbar nicht verwendete Varianten löschen, die dann später doch noch in bestimmten Varianten oder Transaktionen dringend benötigt werden.

Integratives ERP System ->modulübergreifendes Berichtswesen

Aber dieses ist vielleicht auch einer der Gründe warum das Thema Berichtswesen nie langweilig wird und sich nicht nur Keyuser gerne mit Themen wie "Grundlagen Kurzeinführung und Handbuch Report Painter Report Writer" oder auch "Grundlagen Kurzeinführung und Handbuch SAP Query" beschäftigen. Oftmals ist die Frage des Berichtswesen keine von IT Skills sondern eine des Mutes neue Möglichkeiten und Wege zu entdecken und diese dann für das eigene Berichtswesen umzusetzen.

Im Buch »Berichtswesen im SAP®-Controlling« bin ich ausführlich auf dies Thema eingegangen.
  Vielleicht finden sich hier ja auch noch weitere Anregungen für den Aufbau eines Berichtswesen mit SAP nicht nur für CO im Buch.
 

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.

Auch für einen Reportwriter Bericht kann eine kundeneigene Transaktion angelegt werden, so dass hier nicht mehr über die Berichtsbibliothek der eigentliche Bericht gestartet werden muss sondern direkt per Transaktion der eigentliche Bericht gestartet werden kann.

Auch hier bietet sich der einfache Weg über die Parametertransaktion an. Diese kann über die Transaktion SE93 angelegt werden.Hierzu sind folgende Einstellungen erforderlich:


Vorschlagswerte für Transaktion START_REPORT

D_SREPOVARI-REPORTTYPE
RW

D_SREPOVARI-REPORT
Berichtsgruppe

Hier kann die entsprechende Berichtsgruppe hinterlegt werden. Entsprechend würden auch alle in dieser Berichtsgruppe vorhandenen Reports ausgeführt werden.

D_SREPOVARI-VARIANT
Hier kann wiederum eine Selektionsvariante hinterlegt werden (bspw. Allgemein).

Ein weiteres Anwendungsbeispiele für Parametertransaktionen ist in folgenden Artikeln beschrieben:

• "Parametertransaktion für Recherchebericht"

Daneben ist im Artikel "Transaktion anlegen (Report, Parameter) bspw. für SAP Query" der Unterschied zwischen Parameter und Reporttransaktion erläutert. Im Artikel "Kundeneigene Transaktionen zu Berichten in PSM FM Haushaltsmanagement zum Beispiel Belegjournal anlegen (Variantentransaktion)" ist darüber hinaus auch noch die Variantentransaktion erläutert. Wobei hierbei auch gleichzeitig anhand des Belegjournals in PSM-FM auch Varianten für Einzelpostenberichte erläutert werden, so dass direkt über eine Transaktion Einzelposten Personal oder Sachmittel ausgewertet werden können.
 

---

Hinweis:

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

---

Wie unter "Transaktion anlegen (Report, Parameter) bspw. für SAP Query ist es in der Transaktion SE93 möglich eine Parametertransaktion zum Aufruf von Reports bspw. SAP Query aufzurufen. Hier kann auch ein Recherchebericht aufgerufen werden. Hierzu sind folgende Einstellungen erforderlich:

Vorschlagswerte für Transaktion START_REPORT

D_SREPOVARI-REPORTTYPE
RE

D_SREPOVARI-REPORT

D_SREPOVARI-EXTDREPORT

FM  01IFMEISA                       ZREPORT

WICHTIG: Ohne die Leerzeichen ist der entsprechende Report nicht zu finden, daher ist es sinnvoll vor der Anlage dieser Parametertransaktion den Aufruf des Berichtes zu testen.

Den eigentlichen Berichtsnamen erhält man in der Transaktion FMEM (Recherchebericht anzeigen) über das Menü

• Transaktion FMEM (Recherchebericht anzeigen)
• Zusätze->
• Berichtszuordnung ... (STRG F3)
• Techn. Namen ein/aus

Hier ist dann in der obersten Zeile die technische Bezeichnung des Berichtes angegeben.
Dieser sollte ab (RE/ durch STRG Y markieren und STRG C kopiert werden und kann dann übernommen werden.In oberen Beispiel steht ZREPORT gleichzeitig für den Namen des Recherchbericht, welchen wiederum ein entsprechendes Formular zugeordnet ist. Der Recherchebericht selbst kann über die Transaktion FMEQ eingesehen werden. Im Zweifel kann ein Formular durchaus mehreren Berichten zugeordnet werden, die dann wiederum eine individuelle Kopfzeile haben und so nicht für Verwirrungen beim Aufruf des Reports verursachen.

Alternativ Verwendung des Generierungsnamen als Reportname
Alternativ könnte hier vermutlich auch der Reportname (analog der Reporttransaktion genommen werden. Dieser ist unter Zusätze->Berichtsparameter zu entnehmen (alternativ beim Start des Berichtes unter System->Status) als Generierungsname ersichtlich und sollte als Wert für das Dynprofeld D_SREPOVARI-REPORT statt D_SREPOVARI-EXTDREPORT genommen werden, dieses dürfte auch leichter bzgl. der Leerzeichen sein.

D_SREPOVARI-VARIANT
Hier kann wiederum eine Selektionsvariante hinterlegt werden (bspw. Allgemein).

D_SREPOVARI-NOSELSCRN


Zum Testen kann dann nach erfolgreichen Transportauftrag über die Transaktion START_REPORT der Aufruf des Berichtes getestet werden, sofern Berechtigungen für diese Tranaktion vorliegt. Beim Aufruf der Parametertransaktion wird die Berechtigung auf START_REPORT nicht gegen das Berechtigungsobjekt S_TCODE geprüft.

Ein weiteres Anwendungsbeispiele für Parametertransaktionen ist in folgenden Artikeln beschrieben:

• "Parametertransaktion für Reporwriter"

Daneben ist im Artikel "Transaktion anlegen (Report, Parameter) bspw. für SAP Query" der Unterschied zwischen Parameter und Reporttransaktion erläutert.

Sofern der Bereich PSM-FM (Haushaltsmanagement) bereut wird sind auch die beiden Artikel "»Rechercheberichte de lux« im Modul PSM FM Haushaltsmanagement"  zum Umgang mit unterschiedlichen Rechercheberichten und Selektionsvarianten aber auch der Artikel "Kundeneigene Transaktionen zu Berichten in PSM FM Haushaltsmanagement zum Beispiel Belegjournal anlegen (Variantentransaktion)"

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.

---