Eigentlich hoffte ich ja im Artikel "Grundlagen Kurzeinführung und Handbuch Report Painter Report Writer" alle wesentlichen Fragen rund um die Grundlagen zur Erstellung eines Report Painter / Report Writer Bericht erläutert zu haben.

Jedoch hatte ich letztens eine Anfrage erhalten, dass eine definierte Kopfzeile weder beim Export des Berichts als Excel noch bei aktivierter Excelintegration dargestellt wird, obgleich hier einige Grunddaten hinterlegt worden sind. Neben der direkten Antwort ergibt sich aus dieser Fragestellung auch der folgende Artikel.

Export nach Excel oder als Liste

Grundsätzlich ist der Export nach Excel ja schon im Artikel "Grundlagen - Berichte von SAP nach Excel exportieren" beschrieben worden. Hier kann es, wie im Artikel "Fehlende Daten bei OfficeIntegration (ReportWriter)" zwar tatsächlich Probleme geben, aber ein Grund warum die Kopfzeile nicht mit übertragen wird, war mir bisher nicht klar.

Mein erster Gedanke zum Erhalt dieser Information ist gewesen den Bericht direkt als Liste zu sichern. Hierdurch ist zwar die Formatierung nicht mehr verfügbar, aber es werden alle Informationen wie in SAP dargestellt ebenfalls exportiert. Diese Funktion ist unter

• SYSTEM ->
• LISTE ->
• SICHERN ->
• LOKALE DATEI

zu finden. Dieses war bisher auch tatsächlich meine Vorgehensweise beziehungsweise hatte ich Berichte nicht mit aktivierter Office-Integration dargestellt sondern diese deaktiviert, so dass mir immer alle Informationen ersichtlich waren.

Da nun aber ein bestimmter, relativ komplexer und damit erläuterungsbedürftiger Bericht einrichtungsübergreifend verteilt werden soll, ist es sicherlich sinnvoll auch bei aktivierter Office-Integration beziehungsweise Export nach Excel diese Information ebenfalls zur Verfügung zu stellen.

Berichtstext als Kopfzeile im Report Painter festlegen

Innerhalb des Berichtes (zum Beispiel über die Transaktion GRR2) kann im Menü über

• ZUSÄTZE ->
• BERICHTSTEXTE ->
• KOPFZEILEN

eine Kopfzeile für einen Bericht erstellt werden. Hier können dann sowohl die einzelnen Merkmale (von Gruppe bis hin zur Einzelbeschreibung) oder auch Selektionsparameter, spezielle Textvariablen oder auch Allgemeine Variablen wie Datum der Berichtsausgabe eingefügt werden.

Diese Kopfzeile wird automatisch als Zeile im Bericht ausgegeben und kann optisch auch mit einem Rahmen und diversen anderen Layout versehen werden.

Allerdings ist diese Zeile, wie schon erwähnt bei der aktivierten Officeintegration oder beim Export nach Excel nicht vorhanden.

Berichtstext als Text für Export festlegen

Hier gibt es jedoch einen weiteren Punkt, den ich bisher immer übersehen hatte, der eine Kopfzeile auch für exportierte Berichte ermöglicht.

Diese ist unter

• ZUSÄTZE ->
• BERICHTSTEXTE ->
• TEXT FÜR EXPORT

zu finden. Im Grunde stehen hier die gleichen Funktionen wie bei der Kopfzeile zur Verfügung.

Besonders spannend ist dieses bei Verwendung einer Variation innerhalb eines Berichtes in der zum Beispiel innerhalb einer Kostenstellengruppe navigiert wird. Im Beispielbericht "Erweiterung Report Writer Berichtsbibliothek 1CT zur Darstellung rollierendes Geschäftsjahr für Kostenstelle und Innenauftrag" wird zum Beispiel eine Innenauftragsgruppe ausgewertet (innerhalb der Bibliothek 1CT) nun kann als Kopfzeile und auch als Berichtstext nicht nur die selektierten Innenauftragsgruppe sondern auch der Verantwortliche, Antragssteller, Laufzeit etc. mit exportiert werden, so dass vor der eigentlichen Tabelle noch eine Vielzahl an darüber hinaus gehenden Informationen hier hinterlegt werden können.

Text aus Vorlage importieren

Empfehlenswert ist es dabei aber sowohl Kopfzeile als auch die Texte für den Export zu pflegen. Sofern aber schon eine umfangreiche Kopfzeile (als Beispiel) angelegt worden ist, kann diese problemlos über das Menü

• TEXT ->
• VORLAGE

entweder aus dem bestehenden Bericht (durch Übernahme der Bibliothek und Bericht) oder aus einen anderen bericht über den Texttyp Kopfzeile importiert werden. Dieses erspart eine Menge an manueller Eingaben. Ferner ist es hier natürlich möglich auch aus anderen Berichten eine entsprechende Vorlage zu importieren.

Sofern noch nicht bekannt möchte ich, neben der weiter unten verlinkten Grundlagenartikel zu Report Painter und Report Writer auch auf meine Buchempfehlung hinweisen:
 
Für etwa 59,90 € bei Amazon bestellen  

---

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.

---

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.

ACHTUNG: Hinterlegte Variante in Z- oder Y-Transaktion

Sollten Sie eine Parametertransaktion angelegt haben in der eine Variante mit der Bezeichnung ALLGEMEIN mit übergeben wird (Parameter D_SREPOVARI-VARIANT) müssen Sie entweder diesen Wert löschen oder erneut eine Variante mit der Bezeichnung ALLGEMEIN erneut anlegen, sofern Sie diese gelöscht haben. Alternativ kann die Parametertransaktion nicht mehr gestartet werden. Zur Pflege einer Parametertransaktion verweise ich gerne auf "Transaktion anlegen (Report, Parameter) bspw. für SAP Query / Unterschied Parameter- oder Reporttransaktion". Damit ist auch für einen Recherchebericht diese zu beachten und ggf. bei der Berichtskonzeption zu beachten.

 

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.

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.

---

Während ich normalerweise relativ konstant wenige Gigabyte an Webtraffic auf dieser Internetseite habe konnte ich diesen Monat plötzlich hohe zweistellige Zugriffsmengen verzeichnen. Dieses ist schon dadurch erstaunlich, da meine Seite (und besonders Blogartikel) in der Hauptsache aus Text und sehr selten aus Bildern bestehen.

Entsprechend erstaunt war ich, dass dann eine einzelne IP plötzlich fast 1 Gigabyte an Datenmengen durch Zugriff und Senden verursacht hat und es sich dabei nicht um einen Proxy-Server einer Hochschule handelt. Letzteres wäre ja erklärbar, da ich doch die Vermutung habe, dass einige Besuchende dieser Seite aus den Hochschulumfeld kommen.

Ein intensiverer Blick ins Serverlogfile offenbarte dann auch noch, dass diese IP immer wieder ein und dieselbe Seite aufgerufen hatte um hier möglicherweise Kommentare zu einen Blogartikel abzusetzen.

Datenschutz bei IP Adressen in Logfiles

Wie in der Datenschutzerklärung zu dieser Seite festgehalten, werden beim Besuch auf dieser Seite grundsätzlich Daten sehr sparsam und wenn möglich anonymisiert erfasst. Eine Ausnahme stellen hier die Logfiles des Servers da (siehe Abschnitt "V. Allgemeine Daten".

Die tatsächlichen Logfiles werden seitens des Webhoster regelmäßig gelöscht und die zugrundeliegenden Daten aus technischen aber auch abrechnungstechnischen Gründen zur Verfügung gestellt.

Somit werden diese Daten gem. § 37 BDSG nur zu Zwecken Sicherheit (bspw. Vermeidung von DDOS Angriffen oder Spamvermeidung) aber auch zu Abrechnungszwecken gegenüber meinen Webhoster erhoben.

Eine dauerhafte Zuordnung von Person und IP (Profilerstellung) ist daher hier nicht möglich und in der Statistik erhalte ich für Daten außerhalb des Zeitraums der Logfiles (nach wenigen Tagen) nur den vorhandenen Traffic der Seite. Eine Auswertung wer welche Seite besucht hat ist mir hier nicht möglich.

Für eine ausführliche Analyse der Besuchendendaten nutze ich eine anonymisierte Version von Google Analytics (siehe Datenschutzerklärung zum Punkt "VII. Google Analytics")

 

Maßnahmen gegen Kommentarspam im Blog

Da ich hier tatsächlich Schutzmaßnahmen gegen Blogkommentarspam ergriffen habe werden hier allerdings keine Kommentare abgesetzt sondern die IP oder das Skript scheitert immer wieder beim Versuch eben solche abzusetzen. Im Artikel des ctMagazin "Was Ihr so meint - Mit Kommentaren im eigenen Blog umgehen" sind einige Möglichkeiten des Verhinderns von Spam-Kommentaren auf technischer Ebene vorgestellt. Einen Teil dieser Anregung hat mir Claudia (gerne nutze ich hier die Gelegenheit das Buch  "PHP für dich" zu empfehlen) glücklicherweise auch in diesen Blog umgesetzt :-).
 
Taschenbuch 383915409X

Für etwa 17,90 € bei Amazon bestellen

ebook/Kindle B00BYIPZDY

Für etwa 10,99 € bei Amazon bestellen  

Trafficanalyse einzelner IP

Trotzdem bleibt hier der ansteigende Traffic auf der Seite, so dass ich mich entschlossen habe diese IP entsprechend einen Zugriff aufs Blog zu sperren.

Hierzu musste ich jedoch als erstes sehen um welche IP es sich handelt und ob diese tatsächlich mit SPAM in Verbindung steht oder tatsächlich einen berechtigten Grund hat regelmäßig auf der Seite nachzusehen. Ein Blick in die Serverstatistik ist hier sehr hilfreich. Alternativ könnte man per Excel oder anderen Tools das Logfile des Servers auswerten.

Am frühen Nachmittag sah meine Statistik wie folgt aus:

Hier hatten also einzelne IP (oder Server) eine Datenmenge von rund um die 700 MB an einen Tag abgerufen. Das entspricht (wie in der Statistik angegeben) etwa 11.215 Seiten und entsprechend viele Zugriffe.

IP Sperren okay, aber bitte nicht FEEDLY :-)

Nun stellts ich allerdings die Frage, wo eine ebensolche IP zuzuordnen ist und ob es sich dabei um eine gute oder eher weniger gute URL handelt. Als Beispiel möchte ich natürlich nicht Feedly als RSS Reader (siehe meinen Artikel "Infotainment oder Nachrichtenapps für Android" davon abhalten meine Seite zu besuchen.

Hier gibt Feedly selbst zur Auskunft, dass sich die IP Adresse ihres Crawler von Zeit zu Zeit ändert, so dass dieser eher am Useragent "user-agent: Feedly/1.0." zu identifizieren ist.

Glücklicherweise sind obige IP Adressen nicht mit Feedly in Verbindung zu setzen , was der Blick in ein aktuell vorliegendes Logfile offenbart.



Entsprechend stellt sich die Frage, was hinter obiger IP Adresse steckt.

Hier kann ich dann tatsächlich die von Heise Netze betriebene IP Spam Listenabfrage empfehlen. Auf der URL heise.de/netze/tools/spam-listen/ können mehrere Listen abgefragt werden, ob die entsprechend kritische URL schon bekannt ist.

Zugriffsperre für einzelne IP Ranges

Danach können in der .httaccess Datei des Webspace diese IP durch folgende Regeln gesperrt werden.

order allow,deny
Deny from BADIP
allow from all

Dabei können konkrete IP Adressen oder auch Bereiche gesperrt werden. Als Beispiel könnte die Uni Gießen durch 134.176.247.... vom Zugriff auf dieser Seite komplett gesperrt werden...was ich aus hoffentlich nachvollziehbaren Gründen nicht möchte.

Die Pflege einer solchen umfangreichen httaccess Einstellung kann sehr umfangreich sein. Daher empfinde ich es als einen großartigen Service dass die Firma "BeforeSunrise Internetagentur e.K."  auf der Seite ip-bannliste.de einen Service betreibt in der eine umfangreiche Bannlist für sogenannte "bad bots" betrieben wird.

Die Liste beinhaltet IP-Adressen und Adressbereiche (IP Ranges), die über das simple einzubinden einer .htaccess-Datei keinen Zutritt zu Ihren Onlineangeboten mehr erhalten.  Interessant dabei ist, dass die Liste als Service auch eine Autoupdate Funktion beinhaltet, so dass diese regelmäßig aktualisiert werden kann.

Daneben kann im Angebot aber auch die aktuelle Liste direkt eingesehen werden um diese im eigenen Angebot zu nutzen.

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.

Ebenso bin ich im Artikel "SAP Query als kundeneigene Transaktion mit Berechtigungen für Tabellenberechtigungsgruppe, Tabellen und Reporttransaktion vergeben" auf dieses Thema eingegangen.

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.

---