Andreas Unkelbach
Werbung


Freitag, 22. Juli 2016
17:25 Uhr

Frühjahrsputz oder geschützte Varianten und nicht mehr benötigte Rechercheberichte entfernen oder reorganisieren

Hin und wieder bietet sich auch die Sommerzeit dazu an ein wenig Frühjahrsputz innerhalb der bisher angelegten Berichte oder Varianten zu machen. Gerade bei Varianten sind oftmals welche im SAP System angelegt (und gesperrt) die durch organisatorische oder fachliche Veränderungen mittlerweile nicht mehr benötigen werden. In diesem Zusammenhang verweise ich gerne auf den hilfreichen Artikel "Geschützte Selektionsvarianten entsperren" um hier etwaige geschützte Varianten doch noch entfernen zu können.

Vorhandene Rechercheberichte

Gerade wenn Sie in den letzten Jahren auch viel mit Rechercheberichten (unabhängig ob nun im Haushaltsmanagement (PSM-FM) wie im Artikel "Saldenliste für Fonds im Haushaltsmanagement Saldo gegen Ertrag und Saldo gegen Budget", "Rechercheberichte im Modul FI (Bilanzanalyse)" in der Ergebnisrechnung  oder in der Profit-Center-Rechnung stellt sich die Frage, wie Sie nicht mehr benötigte Berichte entfernen beziehungsweise löschen können.

Dieses soll am Beispiel eines Recherchebericht im Bereich der öffentlichen Verwaltung (public sector management) im Haushaltsmanagement (funds management) sprich im Modul PSM-FM erläutert werden.

Aufbau Rechercheberichte

Während die Berichtsdefinition (Aufbau des Ergebnisblatt) innerhalb eines Formular festgelegt wird, wird die Steuerung des Berichtes in einen Bericht definiert (inkl. aller Merkmale die für den  Würfel (Merkmalaustausch) zur Verfügung stehen. Um entsprechende Berichte zu starten kann entweder eine Transaktion wie Rechercheberichhte ausführen (für PSM-FM ist dieses die Transaktion FMEQ) oder alternativ eine kundeneigene Transaktion zum Aufruf der Berichte, wie im Artikel "Parametertransaktion für Recherchebericht" angelegt werden.

Rechercheberichte reorganisieren beziehungsweise löschen

Laut Dokumentation im Customizing ist das Löschen von Berichten und Formularen über die Reorganisierung vorgesehen. Hier kann über eine Liste von selektierten Berichten und Formularen diese dann inklusive der zugehörige Daten gelöscht werden.

Diese Funktion ist im Customizing (Transaktion SPRO) unter:
  • Public Sector Management
  • Haushaltsmanagement Öffentliche Verwaltung
  • Informationssystem
  • Rechercheberichte
  • Bericht -> Bericht reorganisieren (Transaktion FME6)
  • und danach
  • Formulkar -> Formular reorganisieren (Transaktion FME5)
zu finden.

Sofern jedoch einzelne Berichte beziehungsweise Formulare gelöscht werden sollen, ist es in meinen Augen wesentlich einfacher diese über die Transaktionen Bericht ändern (Transaktion FMEL) und hier über das Menü RECHERCHEBERICHT-> LÖSCHEN (UMSCH + F2) beziehungsweise im Anschluss Formular ändern (Transaktion FMEO) und hier über FORMULAR -> LÖSCHEN (UMSCH + F2) zu löschen.

Berichtsdaten löschen


Wie im Artikel "Formatanzeige im Recherchebericht (Darstellung in 1 EUR)" im Abschnitt Berichtsdaten sichern beschrieben besteht auch bei Rechercheberichten die Möglichkeit Daten zu halten (einzufrieren). Eine vergleichbare Funktion ist auch bei Report Painter / Report Writer Berichten durch Extrakte (siehe "ReportWriter Grundlagen - Extrakte sichern und verwalten") möglich. Um diese gespeicherten Daten zu löschen ist allerdings tatsächlich die Reorganisierung sehr praktisch die in diesen Fall unter:
  • Public Sector Management
  • Haushaltsmanagement Öffentliche Verwaltung
  • Informationssystem
  • Rechercheberichte
  • Bericht
  • Berichtsdaten reorganisieren (Transaktion FME7)
zu finden ist.Hierdurch werden. Anhand Merkmale wie Geschäftsjahr oder auch Erstellungsdatum etc. können hier die zu löschenden Berichtsdaten auch feingliedriger selektiert werden. Alternativ ist dieses natürlich auch nachdem der Bericht aufgerufen wurde (mit den gespeicherten Daten) unter BERICHT -> LÖSCHEN DATEN möglich.

Grundsätzlich ist eine Bereinigung von Berichten und vorhandenen Varianten sicherlich sinnvoll nicht nur aus Speicher- und Performancegründen sondern auch für eine bestehende Berichtsdokumentation und Handhabung von Berichten. Zumindest im Kreise von Kolleginnen und Kollegen ist es oft sinnvoll hier einen gewissen Aufwand in der Bereinigung von bestehenden Berichten und eventuell nicht mehr benötigte Varianten sich Gedanken zu machen.

Auch hier gilt, ebenso wie im Berechtigungswesen, die Umsetzung der Philosophie von "So viele Berichte wie nötig, so wenig Pfelgeaufwand wie irgendwie möglich".... Hier ist es einfach eine Frage von Übersichtlichkeit, Pflegeaufwand oder auch Nutzen von einzelnen Maßnahmen.

Entsprechend spannend ist natürlich die Fragestellung, wie das lokale Berichtswesen organisiert wird und einige spannende Ansätze bietet hier sicherlich der Artikel "Unterschiedliche Auswertungsmöglichkeiten im Controlling (Report Writer, Recherchebericht, SAP Query) und natürlich Excel ;-)". Von daher kann ich hier nur allen Lesenden dieses Artikel viel Vergnügen bei der Bereinigung bestehender und Konzeptierung eigener Berichte wünschen.

Hinweis: Aktuelle Buchempfehlungen besonders SAP Fachbücher sind unter Buchempfehlungen inklusive ausführlicher Rezenssionen und Bestellmöglichkeit zu finden.
Diesen und weitere Texte von Andreas Unkelbach finden Sie auf http://www.andreas-unkelbach.de


Sonntag, 3. Juli 2016
14:56 Uhr

Gruppierung von Finanzierungszwecken bei Drittmittelprojekten per Zusatzfeldcoding mit IF oder CASE

Gerade beim Coding von Zusatzfeldern werden Variablen oftmals auch auf ihren Inhalt hin überprüft. Hier bieten sich, wie auch in anderen Skriptsprachen, Bedingen (oder Verzweigungen) an, wie zum Beispiel IF oder CASE Statements im ABAP Coding. Anhand von Gruppierungen des Finanzierungszweck eines Haushaltsfonde (Drittmittelprojekt) soll dieses hier dargestellt werden.

Hintergrund: Anwendung Finanzierungszweck im SAP Modul Public Sector Management (PSM)

Innerhalb des Modul Haushaltsmanagement (PSM-FM) können zur Unterscheidung von Drittmittelprojekten als Merkmal sogenannte Finanzierungszwecke genutzt werden. Unerhalb der Fonds können hier einzelne Finanzierungszwecke angelegt, geändert oder auch angezeigt werden. Diese können dann innerhalb der Stammdaten von Fonds im Abschnitt Zusatzdaten ebenso wie Budgetprofile (siehe "Budgetprofil klassische Budgetierung") gepflegt werden. Hierbei handelt es sich um einen alphanummerischen Schlüßel der als Gruppierung und Auswertungsmerkmal für Fonds verwendet werden kann.

Die Finanzierungszwecke können unterhalb:
  • Rechnungswesen
  • Public Sector Management
  • Haushaltsmanagement
  • Stammdaten
  • Kontierungselemente
  • Fonds
  • Finanzierungszweck
gepflegt werden über Anlegen (Transaktion FM5I), Ändern (Transaktion FM6U) oder Anzeigen (Transaktion FM6S).

Finanzierungszweck in einer Query einbinden (Zusatzfeld oder Zusatztabelle)

Innerhalb einer Query können Sie diese dann sowohl als Zusatzfelder eingebunden werden (siehe "SAP Query ABAP Coding im Zusatzfeld für Verknüpfung Innenauftrag und Fond bzw. Finanzierungszweck oder auch Status GESPERRT bei Innenaufträgen") oder durch Verknüpfung der Tabelle FMFINCODE mit den Stammdaten der Innenaufträge (Tabelle AUFK) als Zusatztabelle (siehe "Query über COEP, AUFK und FMFINCODE für Einzelposten Istkosten Innnenauftrag mit Stammdaten aus CO und PSM-FM sowie Spalten für Ertrag und Aufwand - Erster Teil Infoset als Datengrundlage") zugeordnet werden.

Unterschied CASE WHEN zu  IF, ELSEIF Statement

So detailiert entsprechende Finanzierungszwecke abgebildet werden kann es doch auch für das interne Berichtswesen interessant sein mehrere Finanzierungszwecke (FINUSE). Für eine entsprechende Auswertung sollten dann mehrere Finanzierungszwecke zusammengefasst werden wodurch dann zum Beispiel die Fiannzierungszwecke EU/ESF, EU/FRP6, EU/FRP7, EU/FRP8 und andere Mittel der Europäischen Union zu einen gemeinsamen Merkmal "EU" zusammengefasst werden, so dass hier verschiedene Drittmittelprojekte die durch die EU finanziert werden insgesamt zusammengefasst werden.

Schon bei der Darstellung im Abschnitt "Zusatzfeld VLE zur Darstellung virtueller Lehreinheit aus Teilstring der verantwortlichen Kostenstelle sofern nicht in einen anderen Feld ein Wert steht" wurden einzelne Daten ausgelesen und über eine IF Schleife das Zusatzfeld per IF und ELSEIF einen Wert zugewiesen.

Die Besonderheit von IF Statements ist, dass hier besondere Prüfungen vorgenommen werden können. Neben IF gibt es aber auch die Möglichkeit per CASE Anweisung durch ABAP Code den Einzelwert eines Feldes direkt zu prüfen.

Insgesamt können in einer CASE Abfrage bis zu acht Zustände (Bedingungen) überprüft werden.

Der Syntax dazu lautet:

CASE variable.
WHEN bedingung1 OR bedingung2 .
..
Ausgelöste Aktion
..
WHEN bedingung9 OR bedingung10.
..
Ausgelöste Aktion
...
WHEN OTHERS.
..
Kein Fall tritt ein
..
ENDCASE.

Hierdurch ist die Case Anweisung wesentlich flexibler da mehrere Bedingungen per ODER verknüpft werden können, allerdings muss eine absolute Übereinstimmung mit den Werten vorhanden sein. Sofern mit Platzhaltern * gearbeitet werden soll, ist dann doch eher die Variante von IF und ELSEIF hilfreich.

IF variable = wert.
..
ausgelöste Aktion
..
ELSIF bedingung.
..
ausgelöste Aktion bei der die Bedingung, die auch komplexer sein darf, zutrifft.
..
ELSE.
..
ausgelöste Aktion, wenn keine Bedingung zutrifft.
..
ENDIF.

Im Grunde ist diese Funktion vergleichbar mit anderen Skriptsprachen. So wäre bei PHP ein vergleichbarer Fall mit IF (siehe "Wenn das Wörtchen if nicht wär...") oder SWITCH (siehe "Hierhin switchen, dahin switchen...") vergleichbar. Dieses ist auch einer der Gründe, warum ich zum Erlernen einer Programmiersprache auch gerne auf PHP und natürlich das Buch "PHP für dich, Version 2014: So einfach war PHP-lernen noch nie!" verweise, da es sehr anschaulich die Grundlagen einer Programmiersprache darstellt und PHP relativ einfach im Bereich Webseiten für eigene Projekte bzw. die private Homepage genutzt werden kann.




Nun aber wieder zurück zur Anwendung der CASE Anweisung bei Fonds und ihren Finanzierungszwecken.

Zur Erinnerung wir haben den Finanzierungszweck entweder über ein Zusatzfeld (und damit in der Variable finuse) oder über eine Zusatztabelle und damit über das Tabellenfeld FMFINCODE-FINUSE vorliegen.
 

Exkurs Finanzierungszweck über Zusatzfeld finuse

Zusatzfeld PSM-FM Finanzierungszweck aus Fond

Das Coding für das Feld FINUSE sieht dabei wie folgt aus (wobei statt BUK natürlich Ihr Buchungskreis im Coding hinterlegt sein sollte):

    * Lokale Variablen definieren
    DATA: L_FINZWECK type FMFINCODE-FINUSE.
    DATA: L_FOND type FMFINCODE-FINCODE.
    DATA: L_AUFTRAG type AUFK-AUFNR.
    * Zuweisung von Variablen aus der Selektion
    L_AUFTRAG = AUFK-AUFNR.
    * Verschieben des gespeicherten Wertes in der Tabelle AUFK um 4 Zeichen
    * HINTERGRUND:
    * Das Fekd AUFK-AUFNR hat insgesamt 12 Zeichen.
    * Die achtstellige Auftragsnummer wird mit 0000 aufgefüllt
    * Durch die Verschiebung ist die Auftragsnummer direkt in der
    * lokalen Variable gepseichert.
    SHIFT L_AUFTRAG BY 4 PLACES LEFT.
    L_FOND = L_AUFTRAG.
    * Über die Selektabfrage hat nun das Feld Fond die richtige Länge
    SELECT SINGLE finuse FROM fmfincode INTO L_FINZWECK
           WHERE fikrs = 'BUK'
             AND fincode = L_FOND.
    * Abfangen eines Fehlers und Wertzuweisung in Zusatzfeld
    IF sy-subrc <> 0.
      CLEAR finuse.
    ELSE.
      finuse = L_FINZWECK.
    ENDIF.

ACHTUNG: Länge der Auftragsnummer / Fondsnummer beachten!

Im oberen Coding gehen wir davon aus, dass Innenauftrag und Fond jeweils acht Stellen haben. Sollte die Auftragsnummer bzw. Fondcode nur siebenstellig sein ist die Zeile auf
SHIFT L_AUFTRAG BY 5 PLACES LEFT
anzupassen.

Um nun auf die Variable oder den Finanzierungszweck zuzugreifen legen wir ein neues Zusatzfeld an.

Zusatzfeld FINANZIERUNGSGRUPPE mit CASE Anweisung

Über die Schaltfläche Zusätze (F5) bzw. innerhalb der Transaktion SQ02 (Pflege des Infosets) über  SPRINGEN-> ZUSÄTZE ZUM KNOTEN kann ein eigenes Zusatzfeld angelegt werden. Hierzu kann im Register Zusätze die Schaltfläche Anlegen ausgewählt werden. Es erscheint eine Maske in der der Name des Zusatzfeldes angegeben werden soll (im folgenden Beispiel FINGRUPPE)  und die Art der Zusatzinformation. Neben des schon angesprochenen Zusatzfeldes  sind dieses: Zusatztabelle, Zusatzstruktur und Coding. In unserem Beispiel soll ein Zusatzfeld mit den Namen FINGRUPPE angelegt werden.

Dieses hat folgende Eigenschaften: Langtext und Überschrift haben beide Finanzierungsgruppe erhalten. Die Formatangabe wurde über LIKE-Referenz idenitsch zum Feld FMFINCODE-FINUSE gehalten. Damit entspricht dieses Feld den Formatangaben in der Tabelle FMFINCODE (Typ C (Character) Länge 016 Ausgabenlänge 016). Dieses sollte, sofern Sie FINUSE per Zusatzfeld definiert haben, in einen tiefergelegten Codingabschnitt hinteregt werden.

Damit ist das Feld angelegt, hat jedoch nur eine Datendefinition aber noch keine eigene Daten (anders bei der Zusatztabelle, die sich direkt aus der Datenbank einen passenden Datensatz liest).

Nachdem ein Feld jedoch angelegt ist kann über die Schaltfläche "Coding zum Zusatz" ein passendes ABAP Coding für das Feld hinterlegt werden

Hier entscheidet dann die erste Zeile des Coding woran die Bedingungen überprüft werden sollen.

1. Variante Orientierung am Zusatzfeld FINUSE.


Wie in oberen Beispielcoding ersichtlich erhält die Variable finuse ihren endgültigen Wert durch die Anweisung

finuse = L_FINZWECK.

Somit ist die erste Zeile des Coding für unsere FINANZIERUNGSGRUPPE also:

CASE finuse.

2. Variante Einbindung als Zusatztabelle

Sollten Sie die Tabelle FMFINCODE als Zusatztabelle über das Zusatzfeld ZAUFNR eingebunden haben (siehe oben verlinkten Artikel) würde die erste Codingzeile wie folgt lauten:

CASE FMFINCODE-FINUSE.

3. Coding mit Bedingungen

In beiden Fällen kann das Coding nun wie folgt weitergehen, so dass eine entsprechende Ausgabe erfolgen wird.

  WHEN 'EU/ESF' OR 'EU/FRP7' OR 'EU/FRP8' OR 'EU/FRP6'.
    FINGRUPPE = '
EU-Projekte'.
  WHEN 'INDUSTRIE'.
    FINGRUPPE = '
Industrie'.
 WHEN OTHERS.
    FINGRUPPE = '
Andere Projekte'.
ENDCASE.

Insgesamt können je WHEN Zeile acht Varianten als Bedingung gesetzt werden.
Sinnvoller ist es natürlich bei WHEN OTHERS. dann den Finanzierungszweck des Fond auszugeben.

Für die Zusatztabelle wäre hier das Coding:

 WHEN OTHERS.
    FINGRUPPE = FMFINCODE-FINUSE.
ENDCASE.

und für das Zusatzfeld:
 

 WHEN OTHERS.
    FINGRUPPE = finuse.
ENDCASE.

Damit kann dann später noch entschieden werden, was mit einen Finanzierungszweck passieren soll und gegebenenfalls künftig eine weitere Bedingung mit eingebaut werden.

Anwendungsgebiet Finanzierungsgruppe

Während in einer Drittmittelstatistik Daten möglichst ausführlich dargestellt werden sollten kann es für Managementberichte sinnvoll sein vorhandene Daten zusammen zu fassen und so diese Projekte gruppiert darzustellen. Hierzu eigent sich dann tatsächlich die Methode der Finanzierungsgruppe, da hiermit die Ergebnisse einer Auswertung (als Beispiel sei hier der Recherchebericht "Saldenliste für Fonds im Haushaltsmanagement Saldo gegen Ertrag und Saldo gegen Budget" um eine Stammdatenliste ergänzt werden die sowohl CO Stammdaten, Klassifizierungsmerkmale als eben auch die Fiannzierungsgruppe mit ausweisen kann. Für weitere Möglichkeiten einer solchen Query verweise ich gerne auf die Artikelserien:

  1. "Query über COEP, AUFK und FMFINCODE für Einzelposten Istkosten Innnenauftrag mit Stammdaten aus CO und PSM-FM sowie Spalten für Ertrag und Aufwand - Erster Teil Infoset als Datengrundlage"
  2. "Query Einzelpostenliste Innenauftrag mit Ausweis Ertrag und Aufwand Zweiter Teil Query zur Datenaufbereitung"
Oder aber auf:
  1. "SAP Query ABAP Coding im Zusatzfeld für Verknüpfung Innenauftrag und Fond bzw. Finanzierungszweck oder auch Status GESPERRT bei Innenaufträgen"
  2. "Query über verantwortliche Kostenstelle des Innenauftrag - Bestimmung der Lehreinheit im Fachbereich durch Teil der Kostenstellennummer"
  3. "SAP Query - Auswertung Merkmale der Klassifizierung am Beispiel Fonds in PSM-FM"
  4. "Weitere Zusatzfelder im Infoset mit ABAP Coding zur Verwendung in SAP Query über die Tabellen AUFK und FMFINCODE"
Je nach beabsichtigten Berichtszweck dürfen hier auch weitere Mögichkeiten vorahnden sein.
 

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.




Hinweis: Aktuelle Buchempfehlungen besonders SAP Fachbücher sind unter Buchempfehlungen inklusive ausführlicher Rezenssionen und Bestellmöglichkeit zu finden.
Diesen und weitere Texte von Andreas Unkelbach finden Sie auf http://www.andreas-unkelbach.de


Samstag, 11. Juni 2016
10:49 Uhr

Berechtigungen zur Ausführung von SAP Query (Transaktion SQ00 oder eigene Z/Y Transaktion) und Einbindung im Berechtigungskonzept und Berichtswesen

Wie schon im Artikel "Welche User haben die Berechtigung zur Auswertung einer bestimmten Kostenstelle oder Innenauftrag?" angesprochen ist das Thema Berechtigung im Alltag immer wieder aktuell. So hatten wir letztens eine Diskussion über das Ausführen von SAP Query als Keyuser und eine Diskussion mit Basis und bestehenden Berechtigungskonzepten.

Als eine schnelle Lösung möchte ich hier zwei Möglichkeiten darstellen.

Hier sollte immer die Frage geklärt werden, welche Berechtigungen zum Ausführen oder Nutzen von SAP Query (siehe "Grundlagen Kurzeinführung und Handbuch SAP Query") genutzt werden soll.

Innerhalb des Abschnitts "1.2. Berechtigungsrollen für Query" bin ich hier auch auf unterschiedliche Rollen zum reinen Ausführen einer Query (zum Beispiel über die Transaktion SQ00) und den Erstellen der Query eingegangen.

Vorschlag: Berechtigungsrolle zum Ausführen von SAP Query

So würde eine Rolle zum Ausführen von SAP Query natürlich die Berechtigung für SQ00 (Berechtigungsobjekt S_TCODE)und folgende Berechtigungsobjekte enthalten.

Daneben bedarf es folgender Berechtigungen:

S_TABU_DIS
ACTVT Aktivität 03
DICIBERCLS Tabellenberechtigung *

S_DEVELOP
ACTVT Aktitivität 03
DEVCLASS Paket $0, T*, Y*, Z*
OBJTYPE Objekttyp DOMA,  DTEL, ENQU, LDBA, INDX, MCID, MCOB, SHLP. SQLT, SQTT, STRU, TABL, TABT, TTYP, TYPE, VIEW, VIET
P_GROUP Berechtigungr.ABAP/4Program *

S_QUERY
ACTVT
Hier reicht das reine Vorhanden des Beechtigungsobjektes aus, ohne dass hier ein Berechtigungsfeldwert einzutragen ist.

Natürlich sollte dieser Vorschlag noch mit vorhandenen Berechtigungskonzepten abgestimmt werden. Inhaltlich ist dieses ohnehin ein Thema, wo verschiedene Abteilungen (und Keyuser) intensiver und harmonisch mit der SAP Basis Abteilung sich abstimmen sollten.

Von daher ist es auch nicht weiter verwunderlich, dass sich auch manche Blogs ausschliesslich mit den Fragen rund um Berechtigungen und entsprechende Konzepte beschäftigen.

Eine entsprechende Schulung im Bereich Berechtigungswesen kann sicherlich auch in das Fortbildungskonzept der einzelnen Fachabteilungen eingebunden werden.

Sicherlich sollte man darauf achten, dass sich sowohl das Berechtigungskonzept als auch die Frage, welche Art von Berechtigungen im Zusammenhang mit gewünschten Berichtswesen um hier auch solche Fragestellungen zu berücksichtigen.

Diese Themen wurden auch im Artikel "Unterschiedliche Auswertungsmöglichkeiten im Controlling (Report Writer, Recherchebericht, SAP Query) und natürlich Excel ;-)" angesprochen.

Hier sind als Thema Report Writer / Report Painter (siehe auch "Grundlagen Kurzeinführung und Handbuch Report Painter Report Writer" ) Recherchebericht, SAP Query und natürlich Query und nicht zu vergessen, das liebste Spielzeug aller Controller Excel (wodurch auch viele Artikel innerhalb der Rubrik "Office" geklärt sind.
 

Alternative: Transaktion für einzelne Query anlegen und diese im Menü hinterlegen

Eine interessantere Alternative ist dabei für einzelne Query eine eigene Transaktion wie im Artikel "Transaktion anlegen (Report, Parameter) bspw. für SAP Query / Unterschied Parameter- oder Reporttransaktion" beschrieben anzulegen.

Eine spannende Option wäre dann tatsächlich auf diese Weise Query, Report Painter/Writer und andere Berichte in ein kundeneigenes Menü wie im Artikel "Benutzereigene SAP Menüs (Favoriten, Benutzermenü, Bereichsmenü)" beschrieben einzubauen. Diese sind dann auch über Berechtigungen beziehungsweise Rollen einzelnen Usern zuweisbar.


 

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.




Hinweis: Aktuelle Buchempfehlungen besonders SAP Fachbücher sind unter Buchempfehlungen inklusive ausführlicher Rezenssionen und Bestellmöglichkeit zu finden.
Diesen und weitere Texte von Andreas Unkelbach finden Sie auf http://www.andreas-unkelbach.de


Freitag, 10. Juni 2016
20:52 Uhr

Welche User haben die Berechtigung zur Auswertung einer bestimmten Kostenstelle oder Innenauftrag?

Manchmal kommen auch im Bereich SAP BC (basis components) im Bereich Berechtigungswesen ebenfalls Fragen auf, die nicht nur über einen sprechenden Namen der Berechtigungsrollen (ehemals Aktivitätsgruppen) sondern auch über eine technische Auswertung zu beantworten sind. Daher möchte ich hier eine typische Fragestellung und ihren Weg zur Beantwortung stellen. Im Alltag stellte sich die Frage, welche User eine bestimmte Kostenstelle oder ein bestimmtes Projekt auswerten dürfen.

Benutzerinformationssystem (SUIM)

Grundsätzlich können, meiner bescheidenen Meinung nach, alle Fragen zur Auswertung rund um das Berechtigungswesen über die Transaktion SUIM (Benutzerinformationssystem) beantwortet werden. Inhaltlich handelt es sich hierbei um einen Teilausschnitt des SAP Menü (wie auch im Artikel "Benutzereigene SAP Menüs (Favoriten, Benutzermenü, Bereichsmenü)" im Abschnitt Bereichsmenü beschrieben), welches statt über die Transaktion SUIM auch im normalen SAP Menü unter
  • Werzeuge
  • Administration
  • Benutzerpflege
  • Infosystem
direkt zu finden ist.

Für eine Fragestellung "Wer hat Berechtigungen eine Kostenstelle (zum Beispiel 1040000 für die Abteilung Controlling) auszuwerten oder aber wer darf ein bestimmtes Projekt auswerten?".

Zur Beantwortung dieser Frage kann eine Auswertung der Benutzer nach Berechtigungswerten verwendet werden. Dieser Bericht mit der Transaktion S_BCE_68001397 ist innerhalb des Benutzerinformationssystem (SUIM beziehungsweise im entsprechenden Bereichsmenü) unter:
  • Benutzer
  • Benutzer nach komplexen Kriterien
  • nach Berechtigungswerten
zu finden.

Berechtigung zur Auswertung einer Kostenstelle

Von der Handhabung her kann nun als Berechtigungsobjekt K_CSKS "CO-CCA: Kostenstellen-Stamm" oder noch besser K_REPO_CCA "CO-CCA: Reporting auf Kostenstellen / Kostenarten" eingetragen werden.

Nach Bestätigung des Berechtigungsobjekt mit ENTER kann im Feld "KOSTL - Kostenstelle" die auszuwertende Kostenstelle eingtragen werden.

Berechtigung zur Auswertung von Innenaufträgen oder Fonds im Haushaltsmanagement

Sollen stattdessen Berechtigungen auf Projekte (im Sinne von Innenauftrag oder Fond) überprüft werden bietet sich im Modul Controlling (CO) das Berechtigungsobjekt K_ORDER "CO-OPA: Allgemeines Berechtigungsobjekt für Innenaufträge" an. Hier kann über den CO-OM Verantwortungsbereich nach Kostenstelle oder Innenauftrag gesucht werden, dabei sind Innenaufträge vorrangestellt mit OR* abzufragen.

Gerade im öffentlichen Dienst dürfte aber auch das Modul PSM-FM (Public Sector Management - Haushaltsmanagement) eingesetzt werden. Hier werden Projekte auf Fonds abgebildet. Diese sind im Grunde analog zu Innenaufträgen zu betrachten (so wie auch Finanzstellen als Gegenstück zu Kostenstellen betrachtet werden können.
Für eine Auswertung bieten sich die  Berechtigungsobjekte F_FICA_FCD "Haushaltsmanagement Fonds" oder  F_FICA_FTR "Haushaltsmanagement Finanzbudgetkonto" an die direkt als Berechtigungfeld FOND anbieten wo dieser direkt eingetragen werden kann.

Ergebnisliste komplexe Benutzer nach komplexen Kriterien (Berechtigungsfeldwerten)

Im Ergebnis wird eine Liste aller User mit der entsprechenden Berechtigung ausgewiesen.

Über die Schaltfläche Rollen erhält man ferner auch noch eine Liste aller diesen Usern zugeordneten Berechtigungsrollen, so dass hier eine einfache Auswertung möglich ist.

Fazit

Auch wenn es (sicherlich) ein umfangreiches Berechtigungskonzept gibt in dem auch die einzelnen Berechtigungen der jeweiligen User oder zumindest der Rollen festgehalten sind, können solche Auswertungen auf eine sehr schnelle Weise technisch direkt Auskunft darüber geben, wer für ein bestimmtes Objekt entsprechende Berechtigungen inne hat. Entsprechend hilfreich ist es, besonders für Keyuser, sich auch mit Fragen aus den Beeich Berechtigungen auszukennen.

Ich werde vermutlich im Laufe der Zeit auch noch weitere Bücher aus den Bereich Berechtigungen vorstellen (siehe Buchempfehlungen), aber bis dahin kann ich schon einmal das Buch "SAP ® Handbuch Sicherheit und Prüfung. Praxisorientierter Revisionsleitfaden für R/3-Systeme" empfehlen. Aber auch in der Flatrate von Espresso Tutorial sind Bücher zum Thema Berechtigungen zu finden :-).

Daneben beschäftigen sich auch einige von mir gerne gelesene und auch an dieser Stelle empfohlene SAP Blogs mit den Themenschwerpunkt Berechtigungen.

Der Vollständigkeit halber möchte ich natürlich auch auf einige eigene Artikel rund um das Thema Berechtigungswesen in SAP hinweisen: Die Vielzahl an unterschiedlichen Artikeln rund um das Thema Berechtigungswesen ist vermutlich oder eigentlich ganz sicher durch meinen ersten intensiveren Einstieg rund um SAP begründet. Meine damalige Diplomarbeit zum Thema "Berechtigungswesen in SAP auf Basis der Überarbeitung des vorhandenen Konzeptes der FH Gießen-Friedberg im Bereich Finanzwesen und Controlling" hilft auch heute noch dabei modulübergreifend bestimmte Konzept und Zusammenhänge rund um das Thema BC zu begreifen und in die tägliche Arbeitsweise mit einzubinden.

Entsprechend würde ich auch anderen Keyusern das Thema Berechtigungen empfehlen, da es doch immer wieder einige Fragestellungen aus diesen Bereich gibt, die so mit wenigen Schritten im System und nicht per Dokumentensuche zu beantworten sind. Die ernsthafte Beschäftigung mit der Frage, welche Berechtigung Keyuser (oder Poweruser) erhalten sollen ist nicht nur für die Revision des Berechtigungswesen, Datenschutz und verschiedene damit verbundene Tätigkeiten relevant beziehungsweise zu klären sondern sollte sich auch Gedanken darum machen, welche Tätigkeiten entsprechende Benutzer im SAP System erhalten sollen.
 

Hinweis: Aktuelle Buchempfehlungen besonders SAP Fachbücher sind unter Buchempfehlungen inklusive ausführlicher Rezenssionen und Bestellmöglichkeit zu finden.
Diesen und weitere Texte von Andreas Unkelbach finden Sie auf http://www.andreas-unkelbach.de


Montag, 16. Mai 2016
15:50 Uhr

Darstellung einzelner Projektphasen von der Freigabe bis zum Abschluss eines Innenauftrags anhand einer Query mit Ausgabe GESPERRT aber auch Abschlussdatum

Grundsätzlich können alle Status eines CO Innenauftrag wie in den Artikeln "SAP Query: Systemstatus CO Innenauftrag","SAP Query ABAP Coding im Zusatzfeld für Verknüpfung Innenauftrag und Fond bzw. Finanzierungszweck oder auch Status GESPERRT bei Innenaufträgen" und "Änderungsbelege zu Systemstatus (JEST) bei Innenaufträgen per Query auswerten" anhand der Tabellen  "JEST - Einzelstatus pro Objekt", "TJ02 - Systemstatus" ausgewertet werden. Wenn es jedoch um die einzelnen Phasen eines Innenauftrages geht (und nicht um den Status GESPERRT ist auch die Stammdatentabelle AUFK hier hilfreich und kann direkt verwendet werden.

Gerade bei Projekten mit fester Laufzeit ist es wichtig, festzulegen, wie am Projektende mit Buchungen verfahren werden soll. Teilweise kann hier einfach ein Auftrag gesperrt werden (wodurch keine Buchung mehr möglich ist) allerdings kann es gerade im Rahmen einer Plankopie erforderlich sein etwaige Innenaufträge auch wieder zu entsperren, so dass eine Planabrechnung noch erfolgen kann. Eine bessere Idee ist es da die von SAP vorgesehenen Phasen eines Innenauftrag (Eröffnung, Freigabe, Technisch abgeschlossen,Abgeschlossen) zu verwenden. Somit ist auf einen Blick klar, dass hier tatsächlich das Projekt beendet (abgeschlossen) ist und nicht nur zeitweise (zum Beispiel da ein Sachverhalt geklärt werden muss bevor Buchungen erfolgen) gesperrt ist.

Hierzu ist es sinnvoll tatsächlich einen Arbeitsworkflow zu definieren (vergleichbar zum "Workflow Kostenstelle und Innenaufträge (Module CO, PSM)") oder auch die einzelne Arbeitsschritte und Vorgehensweise in einer "Ereignisgesteuerte Prozesskette in DIA darstellen (weitere Objekte einfügen)" darzustellen. Wobei hier das Projektende entsprechend zu ergänzen wäre. Hier ist allerdings, wie an vielen anderen Stellen des Berichtswesen, auch die entscheidende Frage, wie weit eine Dokumnentation gehen sollte.Insbesondere  sollte auch der Buchhaltung (sowohl in der Finanzbuchhaltung als auch im Controlling) klar sein, wo der Unterschied zwischen Status und Sperre bei Projekten gesetzt wurde und welche Idee hinter den einzelnen Status zu sehen ist.
 

Phasen eines Auftrag bzw. Status

Diese hat gleichzeitig auch den Vorteil, dass hier nur ein Status für die einzelnen Phasen inklusive Datum hinterlegt sind.

Die für die einzelnen Phasen eines Innenauftrages mittels X = JA markierten Felder sind:

  • AUFK-PHAS0 -  Phase 'Auftrag eröffnet'
  • AUFK-PHAS1 -  Phase 'Auftrag freigegeben'
  • AUFK-PHAS2 -  Phase 'Auftrag technisch abgeschlossen'
  • AUFK-PHAS3 -  Phase 'Auftrag abgeschlossen'
Entsprechend bauen auch diese Phasen aufeinander auf und lassen entsprechend immer weniger Vorgänge zu.

  Daneben sind die einzelnen Datumsfelder wie folgt in der Tabelle AUFK hinterlegt:
  • AUFK-IDAT1 - Freigabedatum
  • AUFK-IDAT2 - Technisches Abschlußdatum
  • AUFK-IDAT3 - Abschlußdatum
Bei den einzelnen Datumsfeldern ist es dann natürlich sinnvoll innerhalb der Grundliste bei den Feldeigenschaften (links Spalte, wenn es selektiert wurde oder in der Grundliste angeklickt) die Option "Feld nur ausgeben, wenn <> 0 " zu aktivieren. Andernfalls werden hier bei noch nicht abgeschlossenen Innenaufträgen (Feld AUFK-PHAS3 ist nicht mit X gefüllt) als datumswert 00.00.0000 ausgegeben. Schöner sieht hier natürlich ein leeres Feld aus, so dass ein Datum nur ausgegeben wird, wenn auch tatsächlich der Auftrag abgeschlossen ist.

Je nach gewählten Status sind einzelne betriebswirtschaftliche Vorgänge erlaubt beziehungsweise unterbunden. Eine ausführliche Beschreibung der einzelnen Status ist auch im Buch "Schnelleinstieg ins SAP Controlling" (ISBN: 9783960126874) erläutert. Innerhalb der Stammdaten eines Innenauftrages (z.B. über die Transaktion KO03 oder KO02) kann über die Registerkarte Steuerung im Standard das Feld Status eingesehen werden. Sofern Sie über SPRINGEN->STATUS gehen bekommen Sie zum aktuellen Status auch die jeweils erlaubten betriebswirtschaftlichen Vorgänge hinterlegt.

Exkurs: Customizing Statusverwaltung / Statusschemata und Anwenderstatus / Betriebswirtschaftliche Vorgänge

Neben den vom SAP System vorhandenen vorgegebenen Status inklusive der entsprechenden Zuordnungen können im Customizing aber auch eigene "Anwenderstatus" festgelegt werden, die über ein Statusschema auch eigene Anwenderstatus festlegen, die hier ebenfalls einzelne betriebswirtschaftlichen Vorgänge festlegen und eine Vorgangssteuern je Statusschema zuordnen.
Hierbei finden Sie die einzelnen Funktionen im Customizing (Transaktion SPRO) unter

  • Controlling
  • Innenaufträge
  • Auftragsstammdaten
  • Statusverwaltung
  • Statusschemata definieren (Transaktion OK02)

Hier sind die einzelnen Status in einer Reihenfolge festgelegt, so dass in der Stammdatenverwaltung hier auch zwischen den einzelnen Status hin und her geschaltet werden kann. Über SPRINGEN->VORGANGSSTEUERUNG können nun einzelne betriebswirtschaftlichen Vorgänge hinterlegt werden.
In der Definition der Auftragsart (Transaktion kot2_opa) kann nun das Statusschema hintelregt werden. Jeder dieser Statusschema ist dann entsprechenden Objekten so zum Beispiel "Innenauftrag" zugeordnet.

Selbst angelegte Anwenderstatus werden jedoch nicht wie im Artikel "" beschrieben in der Tabelle  JEST (siehe Artikel "Änderungsbelege zu Systemstatus (JEST) bei Innenaufträgen per Query auswerten" oder "SAP Query: Systemstatus CO Innenauftrag"sondern in der Tabelle TJ30 "Anwenderstatus" hinterlegt.

Sollten Sie eigene Anwenderstatus definieren wollen, kann es hilfreich sein sich vorab darüber klar zu werden, welche einzelne betriebswirtschaftlichen Vorgänge beim jeweiligen Status erlaubt bzw. unterbunden werden sollen. Ferner ist ein wesentlicher Punkt auch eine entsprechende Prozessdokumentation und vor allem auch Durchführung eines entsprechenden Ablaufsplan für die einzelnen Phasen eines Projektes welches als Innenauftrag abgebildet wird.

Auswertung Query über einzelne Phasen eines Projektes

Neben der bisherigen Auswertung von Auftragsstammdaten (siehe zum Beispiel der Artikel "Query über COEP, AUFK und FMFINCODE für Einzelposten Istkosten Innnenauftrag mit Stammdaten aus CO und PSM-FM sowie Spalten für Ertrag und Aufwand - Erster Teil Infoset als Datengrundlage" im Abschnitt "Zusatzfeld Gesperrt (Sperrkenzeichen auswerten)" ausführlicher geschildert) kann nun aber auch die einzelnen Phasen des Projektes abgebildet werden.

Zur Auswertung kann aus den schon in den bisherigen Stammdatenlisten verwendeten Infoset die eingangs erwähnten Felder AUFK-PHAS3 (Status abgeschlossen) und AUFK-IDAT3 (Abschlussdatum) mit in der Grundliste der Query aufgenommen werden.

Nun kann das Setzen des Sperrkennzeichen eines Innenauftrag für kurzfristige Buchungssperren gesetzt werden und für tatsächlich abgeschlossene Projekte auf den Status ABGS gewechselt werden, wodurch auch tatsächlich keine weiteren Buchungen mehr möglich sind. Das kurzfristieg Sperren ist dadurch weiterhin über BEARBEITEN->SEPRRE->SETZEN möglich, wohingehend der Status Abschluss im Reiter Steuerung bzw. im Abschnitt Status durch Wechsel des jeweiligen Status gewählt werden kann. Daneben kann durch die Felder Antragsdatum, Arbeitsbeginn und Arbeitsende relativ genau die Laufzeit eines Projektes ausgegeben werden.

Eine stark vereinfachte Stammdatenliste für Innenaufträge (lediglich basierend auf der Tabelle AUFK) könnte dabei wie folgt aufgebaut sein:

Innerhalb der Query werden nun auf folgende Felder der einzelnen Tabellen (bzw. Zusatzfelder) des Infosets Zugriff genommen beziehungsweise in der Grundliste zugewiesen. Hierbei ist L als Listenfeld und S als Selektionsfeld zu verstehen.

Die Felder werden hier in der Reihenfolge angegeben, wie diese dann auch in der Query ausgegeben werden sollen:

 

Auftragsstammdaten AUFK
Auftragsart (S) AUFK-AUART
Auftragsnummer (L,S) AUFK-AUFNR
Kurztext (L) AUFK-KTEXT
Verantwortliche Kostenstelle (L,S) AUFK-KOSTV
Profitcenter (L,S)
AUFK-PRCTR
Antragsdatum (L) AUFK-USER5
Arbeitsbeginn (L,S) AUFK-USER7
Arbeitsende (L) AUFK-USER8
Antragssteller (L) AUFK-USER0
Verantwortlicher (L) AUFK-USER2
Abteilung (L) AUFK-USER6
Externe Auftragsnummer (L) AUFK-AUFEX
Auftrag abgeschlossen (L, S)
AUFK-PHAS3
Abschlussdatum (L) AUFK-IDAT3

Wie eingangs erwähnt sollte bei diesen Feld die Option "Feld nur ausgeben, wenn <> 0 " aktiviert sein.

Zusatzfelder (die im Infoset angelegt wurden)
Virtuelle Lehreinheit (L) VLE
Gesperrt (L)  GESPERRT
Finanzierungszweck (L,S) FINUSE

Die drei Zusatzfelder sind in den folgenden Abschnitten

der Artikel "Query über COEP, AUFK und FMFINCODE für Einzelposten Istkosten Innnenauftrag mit Stammdaten aus CO und PSM-FM sowie Spalten für Ertrag und Aufwand - Erster Teil Infoset als Datengrundlage" und  "SAP Query innerhalb des SAP Moduls PSM FM beziehungsweise Haushaltsmanagement" beschrieben.

Reihenfolge Selektionsfelder festlegen

Ebenfalls interessant, gerade bei vielen Selektionsfeldern, kann es sein, dass der Aufbau des Selektionsbild auch durch die Reihenfolge Selektionsfelder bei Query ändern beeinflusst werden kann. Dieses ist über SPRINGEN->FELDAUSWAHL->SELEKTIONEN über die Spalte NR. möglich. Hier kann ich nur die Empfehlung aus meiner Studiumszeit weiter geben bei Sortierfeldern Abstände immer in 5er Schritten anzugeben (Erstes Feld bekommt Nummer 5, Zweites Feld Nummer 10, ...). Dieses hat den enormen Vorteil, dass später auch Felder verschoben werden können (zum Beispiel auf Numemr 7) ohne dass hier auch alle anderen Felder geändert werden müssen.

Konzeption Prozesse und notwendige Stammdatenfelder

In der Praxis kann es tatsächlich immer einmal wieder vorkommen, dass weitere Felder in der Selektionsliste aufgenommen werden sollen, oder alternativ manche wegen der einfacheren Handhabbarkeit an einer anderen Stelle verschoben werden sollten. Sollten Sie sich neben den einzelnen Projektphasen auch noch weitere Gedanken um die Stammdaten oder Informationen zu einen Innenauftrag machen, kann auch der Artikel "Stammdatenerweiterung von CO-Objekten am Beispiel ergänzende Kostenstelle beim Innenauftrag". Sollten Sie sich gemeinsam Überlegungen über aufzunehmende Felder beziehungsweise neben der Prozessdokumentation auch ein Brainstorming über vorhandene Daten durchführen wollen kann ich auch zum Ordnen der eigenen Gedanke eine Mindmap wie im Artikel "Mindmapping und Sketchnotes im Beruf nutzen für Brainstorming oder Mind Mapping mit XMIND" empfehlen, allerdings müssen sich darauf auch alle Beteiligten einlassen, was bei solchen Methoden nicht immer der Fall ist.

 

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.




Hinweis: Aktuelle Buchempfehlungen besonders SAP Fachbücher sind unter Buchempfehlungen inklusive ausführlicher Rezenssionen und Bestellmöglichkeit zu finden.
Diesen und weitere Texte von Andreas Unkelbach finden Sie auf http://www.andreas-unkelbach.de


<< Frühere Einträge
Hinauf




Werbung


© 2004 - 2016 Andreas Unkelbach
Andreas Unkelbach

Stichwortverzeichnis
(Tagcloud)


Aktuelle Infos (Abo)

Facebook Twitter Google+

Schnelleinstieg ins SAP Controlling (CO) von Martin Munzel & Andreas Unkelbach
Privates

Kaffeekasse 📖 Wunschliste