Im Artikel "Betriebswirtschaftliche Vorgänge und Systemstatus CO-OM Innenauftrag - Plankosten auf ABGS oder TABG CO Innenauftrag zulassen"  bin ich darauf eingegangen, dass der Status ABGS (Abgeschlossen) oder TABG (technsich abgeschlossen) so angepasst werden kann, dass Ist-Belege trotz Status ABGS oder auch Planbelege trotz Status TABG gebucht werden können.

Zur Erinnerung: Betriebswirtschaftliche Vorgänge bei CO-Objekt Innenauftrag und Kostenstelle

Je nach Status sind unterschiedliche betriebswirtschaftliche Vorgänge für das CO Objekt möglich. Dabei gibt es vier Status, die im SAP Standard vorhanden sind:

• ERÖFFNET
  Auftrag ist angelegt, keine Istbuchungen
• FREIGEGEBEN
  Fast alle betriebswirschaftlichen Vorgänge möglich
• TECHNISCH ABGSCHLOSSEN
  Keine Planänderungen mehr möglich, aber Istbuchungen sind weiterhin möglich
• ABGESCHLOSSEN
  Keine kostenrelevante betriebswirtschaftliche Vorgänge möglich

Zwischen den einzelnen Status eines Innenauftrages kann in der Transaktion KO02 in der Registerkarte Steuerung im Feld Systemstatus gewechselt werden. Über die Schaltfläche "Erlaubte Vorgänge.." sind auch die betriebswirtschaftlichen Vorgänge aufgeführt die im jeweiligen Status erlaubt sind.

Ebenso kann aber auch die Kostenstelle eingeschränkt werden. In der Stammdatenpflege KS02 für Kostenstellen pflegen ist es in der Registerkarte Steuerung mehrere Sperren zu setzen. Dieses sind im einzelnen:

• Primärkosten Ist
• Sekundärkosten Ist
• Erlöse Ist
• Primärkosten Plan
• Sekundärkosten Plan
• Erlöse Plan
• Obligofortschreibung

Hier kann also sehr differenziert für Ist und Plan eine Sperre gesetzt werden.

Selektionsvariante "gesperrte" Innenaufträge und Kostenstellen

Neben der Nutzung eines Statusselektionsschemata (siehe Artikel "Selektionsvariante KOK5 und Statusselektionsschemata zur Auswertung gesperrter Innenaufträge")  um gesperrte (Systemstatus SPERR) Innenaufträge auszuwerten ist dieses mit interaktiven Stammdatengruppen für die oben erwähnten Systemstatus und Sperrkennzeichen etwas einfacher.

Über die Transaktion KOK5 kann eine Selektionsvariante für Innenaufträge angelegt werden.
Hier kann die Auftragsphase im Abschnitt STATUS  die entsprechende Phase (in unseren Fall Technisch abgeschlossen oder Abgeschlossen gewählt werden.
 

Status TABGL und AfA Buchung

Der Status TABGL (Technisch abgeschlossen) bei Innenaufträgen kann unter anderen dann hilfreich sein, wenn auf eigentlich abgeschlossenen Projekten noch Anlagen abgeschrieben werden sollen (AfA Lauf). Dies kann dann sinnvoll sein, wenn nicht die AfA gegen Planwerte oder Budget läuft, sondern die gesamten Anschaffungs- und Herstellkosten (AHK) zum Zeitpunkt der Investitionen (Zahlungssicht) was im Bereich der öffentlichen Verwaltung doch vorkommt.

Plankosten und Istkosten Sperre für Kostenstellen

Sollten für die Kostenstellen die Plankosten bei gesperrten Kostenstellen zugelassen werden (also die Sperre für Primärkosten Plan und Sekundärkosten Plan aufgehoben werden) können diese Objekte über eine Selektionsvariante mit der Transaktion KS13 ausgewertet werden. In Abschnitt Kennzeichen kann für Primärkosten Ist mit X = Ja die Kostenstellen selektiert werden, die eigentlich gesperrt sein sollen und nur kurzfristig für die Planung noch einmal geöffnet werden.

Das Spannende an den Selektionsvarianten ist, dass sie statt einer Kostenstellen- oder Innenauftragsgruppe über F4 (Gruppenauswahl) und die Markierung "Mit Selektionsvarianten" ausgewählt werden können.

Auswertung Kostenstellen und Innenaufträge mit Report Painter

Neben den beiden Berichten "Kostenstellen: Ist/Plan/Abweichung" (Transaktion S_ALR_87013611) oder "Auftrag: Ist/Plan/Abweichung" (Transaktion S_ALR_87012993) ist es auch möglich einen Report Painter Bericht anzulegen und hier für die Monate in denen die Kostenstellen und/oder Innenaufträge kurzfristig Plan oder auch Ist Buchungen zulassen eine Auswertung anzulegen.

Im Artikel "Report Painter Bericht für Obligo auf CO-Objekten mit interaktive Stammdatengruppen" und "Grundlagen: Set-Variablen im Report Painter / Report Writer am Beispiel Kostenstellengruppe und Innenauftragsgruppe" habe ich einige dieser Berichtsansätze beschrieben.

In den Zeilen können die selektierten Einzelwerte der Kostenstellen und Innenaufträge ausgegeben werden und in der Spalte jeweils Ist, Plan und Obligo je nachdem welche Vorgänge hier erlaubt worden sind. Ferner kann auch eine Selektion per Periode sinnvoll sein, um aktuelle Buchungen zu identifizieren.

Kurztext mit # als gesperrt - Maskierungskennzeichen #, + und *

Eine weitere Anpassung kann es auch sein im Kurztext der CO Objekte ein # an erster Stelle zu führen, sodass durch dieses Zeichen gesperrte Objekte gekennzeichnet werden. Hier ist darauf zu achten, dass innerhalb SAP das Zeichen # als Fluchtkennzeichen angesehen wird.

Das Fluchtzeichen oder Escapezeichen # wird bei Selektionen in SAP verwendet, um nach Sonderzeichen zu suchen. Um nun eine Suche über Kurztexte mit beginnenden # zu suchen, muss dafür ##* als Suchkriterium verwendet werden.

Bei der Suche können folgende Maskierungszeichen verwendet werden:

•  *   Asterisk für beliebige Zeichenketten
•  +  einzelnes Zeichen als Platzhalter
•  #  Fluchtzeichen / Escapezeichen

Massenstammdatenpflege von CO Objekten per LSMW, eCATT oder LTMC in SAP

Eine nachträgliche Pflege von gesperrten Objekten ist per LSMW, eCatt oder unter S/4HANA auch per LTMC möglich.



Im Buch »SAP S/4HANA Migration Cockpit - Datenmigration mit LTMC und LTMOM« bin ich ausführlich auf dies Thema eingegangen.
  Vielleicht finden sich hier ja auch noch weitere Anregungen auch in Richtung einer Datenmigration nach SAP S/4 HANA oder zur Massenpflege von Stammdaten unter SAP ERP mit LSMW und eCatt.


Daneben habe ich im Artikel "Massenstammdatenpflege mit LSMW oder SECATT dank Transaktionsaufzeichnung - Handbuch erweiterte computergestützte Test-Tool (eCATT) und LSMW" die Möglichkeiten mit LSMW oder eCATT unter SAP ERP beschrieben.

Im Hochschulumfeld kann ich daher das Buch sowohl für SAP ERP als auch S/4HANA empfehlen und glaube, dass die Massenstammdatenpflege auch unter ERP zur Stammdatenpflege im Controlling oder auch in anderen SAP Modulen hilfreich ist.

Im Hinblick auf das Berichtswesen ist die Betrachtung von Investitionen oder des Anlagevermögen ebenfalls ein wichtiger Bestandteil, so dass hier bei entsprechenden Auswertungen ebenfalls auf Zusammenhänge zwischen der Anlagenbuchhaltung (FI-AA), Finanzbuchhaltung (FI) aber auch Controlling (CO) egal ob nun im Gemeinkostencontrolling (CO-OM) oder der Profit-Center-Rechnung (ECPA) berücksichtigt werden sollte.

Während ich mich im Artikel "Mehrjahresvergleich im Recherchebericht mit Beschränkung von Aufwand und Ertrag für das laufende Geschäftsjahr bis aktuelle/selektiere Periode/Jahr und komplette Perioden der Vorjahre sowie übertragene Jahresendsalden" noch um die Weiterentwicklung bestehender Berichte gekümmert hatte kam es im beruflichen Umfeld bezüglich einer Auswertung von Investitionen zu einer Abweichung zwischen der ausgewerteten Summen und der Einzelposten einer Profit-Center-Standardauswertung.
Eine vergleichbare Problemschilderung ist auch bei einer Auswertung im CO-OM (Gemeinkostencontrolling)  durch Copy&Paste einer Vielzahl von Aufträgen in der Mehrfachselektion aufgetreten, dass hier ebenfalls im Bericht S_ALR_87012995 (Liste: Aufträge) die Gesamtsumme nicht gepasst hat.

Nach einiger Zeit hatten wir dann tatsächlich festgestellt wo hier die Ursache gelegen hat und diese hier im Artikel festgehalten. Kleiner Spoiler vorab, die Ursache lag an mehrfachen Einträgen von Einzelwerten wodurch doppelte (oder mehrfache) Einträge auch mit angezeigt und mit summiert werden.  Da das Thema aber erstmals im Berecih der Sachkonten für Investitionen aufgetreten ist mag ich zusätzlich zur Mehrfachselektion auch noch auf das Thema Anlagenklasse und Sachkonto eingehen.

Im folgenden Artikel möchte ich daher gerne auf einige Aspekte der Mitbuchtechnik von Anlagenbuchhaltung, Finanzbuchhaltung und Controlling eingehen, aber daneben auch ein Problem ansprechen, dass nun schon mehrere Kolleginnen und Kollegen nach der Einspielung der Enhancement Packages 8 aufgefallen ist, aber nach Rückfrage im Kolleginnen und Kollegenkreis auch schon vorher vorhanden war. Es geht um das Verhalten von Berichten wenn bestimmte Objekte (Sachkonto oder auch CO Innenaufträge) mehrfach in der Selektionsmaske eingetragen sind.
 

Auswertung von Investitionen im Controlling per Report Painter oder Query

In entsprechenden Report Painter Berichten (siehe Artikel "Auswertung Anlagenzugänge als Investitionen im Report Painter mit Ausweis CO Objekte Innenauftrag und Kostenstelle" zur Auswertung der Anlagenbewegungsarten innerhalb der Profit-Center-Rechnung über Einzelpostentabellen oder aber als "Investitionen in ReportWriter (statistische Buchungen)") bin ich schon auf der Definition von Auswertungen eingegangen. Daneben kann die Anlagenbuchhaltung ebenfalls über eine Query ausgewertet werden (sei es über EC-PCA oder über die logische Datenbank ADA). Wer sich dafür näher interessiert findet im Artikel "Zusammenfassung Query über Anlagenzugang - Auswertung Investitionen aus Profit-Center-Rechnung" der ein oder andere Hinweis.

Hintergrund Anlagenbuchhaltung - Anlagengitter

Oftmals hilft es übrigens im Reporting über den eigenen Modultellerrand zu schauen, damit auch Zusammenhänge wie die Verwendung von Ordnungsbegriffen in FI-AA im Artikel "FI-AA Anlagenbuchhaltung: Klassifizierung von Anlagen" klarer werden.

Zur Auswertung von Investitionen hatten wir das Anlagengitter (Transaktion S_ALR_87011990 ausgeweret.

Diese Auswertung ist unter:

• Rechnungswesen
• Finanzwesen
• Anlagen
• Infosystem
• Berichte zur Anlagenbuchhaltung
• Erläuterungen zur Bilanz
• International
• Anlagengitter (Transaktion S_ALR_87011990)

zu finden.

Unter anderen sind hier die Spalten Zugang, Abgang und Umbuchungen neben den Bestandskonto AHK und der Anlagenklasse zu finden.

Zuordnung Anlagenklasse und Hauptbuchkonto

Interessant ist nun der Zusammenhang zwischen der Anlagenklasse under der Zuordnung zum Hauptbuchkonto

Die Customizingeinstellungen zur Anlagenklasse findet sich unter:

• Finanzwesen (neu)
• Anlagenbuchhaltung
• Organisationsstrukturen
• Anlagenklassen
• Anlagenklassen definieren  (Alternativ Transaktionscode OAOA)

Hier kann je Klasse Kurztext und bezeichnung der Anlagenklasse festgelegt werden.

Per Doppelklick auf die Anlagenklasse (oder aber durch Neuanlage) kann zur Anlagenklasse über den Abschnitt Anlageart im Feld Kontenfinden ein Abstimmkonto es Hauptbuches (Bestandskonto) definiert werden.

Hierbei ist zu beachten, dass auch mehrere Anlagenklassen ein identisches Hauptbuchkonto zugeordnet werden können.

Durch die Zuordnung mehrerer Anlagenklassen zu einem Hauptbuchkonto in der Transaktion OAOA kann es bei der Auswertung der Hauptbuchkonten in der Profit-Center-Rechnung nun zu einer Abweichung zum Anlagengitter kommen, was hier für eine kurzfristige Verwunderung geführt hatte.

 

Problem: (Mehrfach)Selektion Sachkonto in Profit-Center-Berichten führt zur doppelten Anzeige von selektierten Werten im Anzeigebereich

Um diese Buchungen mit der Profit-Center-Rechnung (EC-PCA) abzugeleichen wurde ein Plan/Ist Vergleich im SAP Menü zum Beispiel folgender Bericht:

• Rechnungswesen
• Controlling
• Profit-Center-Rechnung
• Infosystem
• Berichte zur Profit-Center-Rechnung
• Listorientierte Berichte
• PrCtr-Gruppe: Plan/Ist/Abweichung (Transaktion S_ALR_87013340)

Beim Aufruf dieser Transaktion werden in der Selektionsmaske neben Profit-Center (Gruppe) auch die Ergebniskonten und Bilanzkonten eingegeben. Diese sind aus der Zwischenablage aus oberen Anlagengitter übernommen worden.

Wird nun die Summe betrachtet ist diese wesentlich höher als die Summe der Zugänge und Abgänge im Anlagengitter.

Beim Betrachten der Einzelposten (durch Doppelklick auf der Summe und Absprung auf den Bericht Profit Center: Ist Einzelposten (Transaktion KE5Z) stimmt nun aber wieder die Summe der Einzelposten mit der Summe des Anlagengitter überein.

Ursache dieser Abweichung war, dass einzelne Sachkonten merhfach in der Selektion eingetragen wordne sind und diese in der Summe dann auch mehrfach berückscihtigt werden. Sofern eine Kontengruppe angelegt wird, ist hier eine Prüfung auf die Eindeutigkeit vorhanden, aber bei der Selektion von mehreren Konten in der Selektionsmaske werden diese im Gegensatz zu den Profit-Centern dann im Bericht auch mehrfach ausgegeben. Lediglich in den Einzelpostenberichten erfolgt dann kein Mehrfachausweis.

Darstellung von Mehrfachselektionen im Anzeigebereich von Berichten
Dieses Problem tritt jedoch grundsätzlich bei allen Berichten auf, die ein Merkmal (welches durchaus auch aus der Selektionsmaske übernommen wird) und im Anzeigebereich eines Report Painter / Report Writer Berichtes (oder auch Recherchebericht) dargestellt wird. Entsprechend sind mehrfach selektierte CO Innenaufträge im Bericht Auftrag: Ist/Plan/Abweichung (Transaktion S_ALR_87012993) korrekt als Summe vorhanden, während mehrfach selektierte Innenaufträge im Bericht Liste:Aufträge (Transaktion S_ALR_87012995) auch mehrfach ausgewiesen werden, jedoch im Absprung auf die Einzelpostenliste nur einfach ausgewiesen werden. Ein Kollege brachte diese Abweichung wie folgt auf den Punkt "Wenn du dir abends in der Kneipe zwei Glas Bier bestellst, solltest du dich ja auch nicht wundern, wenn du dann mehr als eines erhälst..." :-)

Die Frage ist nun, wie kam es zur Selektion von mehreren Sachkonten. Dieses liegt an der Zuordnung von Anlagenklassen und Sachkonten, welche dann für mehrere Anlagenklassen identische Sachkonten hinterlegt hat.

Fazit

Immerhin helfen solche Auswertungen manchmal dabei auch die Zusammenhänge von FI-AA und CO beziehungsweise der Profit-Center-Rechnung und allgemein der Selektion von Konten in Berichten nachzuvollziehen.

Gerade bei unerwarteten Berichtsverhalten ist es hier wirklich positiv sich mit Kolleginnen und Kollegen austauschen zu können, die auch vorher schon das geschilderte Problem hatten und bestätigen können, dass dieses keine direkte Auswirkung der neuen EHP darstellt. Für häufig auftretende Auswertungen ist daher tatsächlich die Verwendung von Stammdatengruppen eine gute Maßnahme um die Eindeutigkeit von Gruppen zu gewährleisten und von der doppelten Auswertung eines Kontos verschont zu werden :-)

Das "abweichende" Verhalten von Berichten über Summen und Einzelposten kann da tatsächlich zu der ein oder anderen Rückfrage oder auch Iritation bezüglich der Interpretation der erhaltenen Werte führen.

Einer der Vorteile im Hochschulumfeld dürfte tatsächlich der Austausch mit Kolleginnen und Kollegen über die eigenen Modulgrenzen hinweg sein. So stellte scih die Frage nach Anlagenzugänge der letzten 30 Tage oder einer Materialbelegliste über Buchungsdatum der letzten 10 Tage  vor der Frage, wie dieses ohne Anpassung des Bezugsdatum möglich ist.

Bei der Pflege von Varianten zu Berichten kann eine Variable für die Datumsberechnung genutzt werden. Nehmen wir als Beispiel einmal eine Auswertung der Anlagenzugänge wie zum Beispiel in der "Query Anlagenbuchhaltung (Inventarliste) über logische Datenbank ADA" oder aber auch der Möglichkeiten der Auswertung die im Artikel "Zusammenfassung Query über Anlagenzugang - Auswertung Investitionen aus Profit-Center-Rechnung" beschrieben sind.

Dynamische Datumsberechnung für Selektionsfelder

In beiden Varianten existiert ein Selektionsfeld wie "Buchungsdatum" um nun ein wenig dynamische Berechnung einzufügen kann das Selektionsbild der Auswertung gesichert werden und neben dem Feld Mußeingabe in der Spalte Selektionsvariable ein X für "Dynamische Datumsberechnung (Systemdatum)" gewählt werden (alternativ D für Dynamische Datumsberechnung (Lokales Datum).

Danach kann in der Spalte "Name der Variable (Eingabe nur per F4) über die Werthilfe  entweder tatsächlich F4 oder die Auswahl neben den Feld) eine Selektionsvariante gewählt werden. Zur Auswahl stehen hier verschiedene Möglichkeiten der Datumsberechnung unter anderen:

• aktuelles Tagesdatum
• Aktuelles Tagesdatum +/- ??? Tage
• Aktuelles Tagesdatum +/- ??? Arbeitstage
• Erster des aktuellen Monats
• Erster tag des Vormaonats
• ...

Daneben kann hier in der ersten Spalte gewählt werden, ob die angegebenen Werte selektiert werden sollen (I = include) oder ausgeschlossen werden sollen (E = exclude). Über die Optionen (zweite Spalte) kann gewählt werden,wie die Werte übereinstimmen sollen.

Als Optionen stehen unter anderen:

• EQ Equal: Einzelwert
• NE Not Equal: Alles außer den angegebenen Einzelwert
• LE Less or equal (kleiner oder gleich den selektierten Wert)
• LT less then (kleiner als)
• GE Greater or Equal (größer als oder gleich)
• GT greater then (größer als)

zur Verfügung.

Für eine Auswertung der Bestellungen der letzten 10 Tage wählen wir hier GE für größer als oder gleich als Option und I für die angegebenen Werte sollen selektiert werden für die Variable Aktuelles Tagesdatum +/- ??? Tage aus. Danach kann ein Paramter für die Datumsberechnung eingegeben werden. Diesesr Wert soll dann für ?? genommen werden.

Für die letzten 10 Tage ist dieses dann -10.

Verwendung dynamischer Datumsberechnung in Selektionsfelder einer Variable

Wird nun die angelegte Variante zum Bericht gewählt wird für das Buchungsdatum automatisch die Option Größer als oder gleich sowie als Datumswert das aktuelle Datum abzüglich 10 Tage gewählt. Die Berechnung erfolgt bei jeden Auswählen der Variante und stellt so eine Option dar um vorab schon einmal bestimmte Selektionskriterien automatisch vorzunehmen.

Manchmal bieten auch schon Varianten zu Berichten Lösungen die ich andersweitig über Zusatzfelder oder Coding vermutet hätte.

Gerade im dezentralen Berichtswesen ist die Nutzung von Varianten sehr praktisch. So können diese, wie im Artikel "Transport von Selektionsvarianten" beschrieben. vom Entwicklungssystem transportiert werden. Gerade in der Zusammenarbeit mit anderen kann es sinnvoll sein "Geschützte Selektionsvarianten entsperren" zu können und hin und wieder sollten auch bestehende Berichte, wie unter "Frühjahrsputz oder geschützte Varianten und nicht mehr benötigte Rechercheberichte entfernen oder reorganisieren" beschrieben kritisch hinterfragt werden.

Ein Vorteil ist auch, dass die Varianten vorausgewählt werden können. Dieses ist im Artikel "»Rechercheberichte de lux« im Modul PSM FM Haushaltsmanagement" am Beispiel PSM erläutert. Aber auch für andere Berichte bietet sich eine eigene Transaktion an.

So funktioniert dieses sowohl im Belegjournal "Kundeneigene Transaktionen zu Berichten in PSM FM Haushaltsmanagement zum Beispiel Belegjournal anlegen (Variantentransaktion)" als auch in anderen vorhandenen Berichten sowie in kundeneigene Berichte, wie am Beispiel "Transaktion anlegen (Report, Parameter) bspw. für SAP Query / Unterschied Parameter- oder Reporttransaktion" ersichtlich ist.

Weitere Anwendungsgebiete dieser dynamischen Datumsfelder

Tatsächlich gibt es auch noch weitere Anwendungsfällte in denen zum Beispiel Stammdaten über Datumsfelder ausgwertet werden können. Sowohl in der Transaktion S_KI4_38000039 (Alphabetische Liste von Fonds), KOK5 (Stammdatenliste von Innenaufträgen) sind hier Datumsfelder wie Arbeitsbeginn und Erfassungsdatum als mögliche dynamisch gefüllte Selektionsfelder mit Bezug zum aktuellen Datum zu erfassen.

Ein weiterer Bonus ist, dass dieses auch in kundeneigene Transaktionen oder auch einer Query funktioniert, was ebenfalls für die im Artikel "SAP Query als kundeneigene Transaktion mit Berechtigungen für Tabellenberechtigungsgruppe, Tabellen und Reporttransaktion vergeben" vorgestellte Transaktion ZKOK5 für eine umfangreiche Stammdatenauswertung gilt.

Somit schliesst sich auch der Kreis zum vorherigen Artikel "Massenänderung von Stammdatengruppen am Beispiel SET für Innenaufträge KOH2 oder Massenupload von Einzelwerten zum Set" über den die Stammdaten gepflegt worden sind und hier dann die Änderungen ausgwertet werden können.

Ausgangslage:
Im Rahmen einer Vereinfachung des Berichtswesen unterscheiden wir zwischen CO Objekten die nur budgetrelevante Kosten und solche die alle Kosten auswerten. Hierzu wurden einige Set Variablen für die Auswertung der budgetrelevnaten und nicht alle Objekte über eigene Gruppen zu Profit-Centern angelegt.

Die Vorgehensweise ist dabei im Artikel "Grundlagen: Set-Variablen im Report Painter / Report Writer am Beispiel Kostenstellengruppe und Innenauftragsgruppe" beschrieben. Jedoch wurden hier statt Kostenstellen- oder Innenauftragsgruppen Setvariablen für Profit-Center angelegt. Als Vorlage ist hier die SetVariable 8A-PCGR verwendet worden (Tabelle GLPCOP, Feldname PRCTR)  wobei hier sowohl als Setvariable ZPCB "Budgetr-Konten L-Profit-Center" als auch ZPCA "Allle Konten L-Profit-Center" angelegt worden sind.

Fehlendes Obligo beim Bericht über Profit-Center (Ausgabe nach CO Objekt Kostenstelle / Innenauftrag

Bei beiden wurden als Eingabefelder auf Selektionsbild sowohl Set- und Werteingabe zugelassen. Im Ergebnis können im Reprort Painter Bericht dann aus der Profit-Center-Rechnung zu diesen Profit-Centern die zugeordneten CO-Objekte wie Kostenstelle und Innenauftrag ausgewertet werden. Der entsprechende Bericht ist im Artikel "Erweiterung Bibliothek 8A2 Ausweis Kostenstelle und Innenauftrag bei Selektion Profit-Center in ReportWriter" vorgestellt worden und um die Auswertung von Investitionen sowie Wertpapiere wie im Artikel "Auswertung Anlagenzugänge als Investitionen im Report Painter mit Ausweis CO Objekte Innenauftrag und Kostenstelle" beschrieben umgesetzt.

Problematisch ist nun aber, dass in der Auswertung von Profit-Center-Belegen keine Obligos ausgewiesen sind. Hier muss die Auswertung dann tatsächlich im CO-OM (Gemeinkostencontrolling) auf Ebene der Kostenstellen und Innenaufträge erfolgen.

Der Artikel "Obligo Verwaltung im SAP Modul CO - Customizing, Standardberichtswesen, Report Writer/Painter und SAP Query" stellt dabei die Behandlung von Obligo im Modul CO ausführlich dar.

Für eine Auswertung der Obligos habe ich in der Biblitothek 6o1 "Innenaufträge" folgenden Bericht angelegt.

Report Painter Bericht ZOBLIGO zur Auswertung von Obligo-Belegen auf CO Objekten

Die einzelnen Elemente haben dabei folgende Eigenschaften:

Allgemeine Selektionskriterien:
Merkmal KostRechKreis (Variable) 6-KOKRS
Merkmal Version 0

Schlüsselspalte
Basiskennzahl Kosten
Kostenart (Gruppe, Set) 1KSTAR
(Alternativ kann auch eine Gruppe der relevanten Kostenarten fix vergeben werden)
Periode 1 bis Variable 1PERIB
Geschäftsjahr (Variable) 1GJAHLH (laufendes Geschäftsjahr)
Werttyp
1 bis 24
2A
2B

1. Zeile Kostenstelle
Merkmal Kostenstelle (Gruppe) BUCH
Dieses ist die oberste Hierarchie der Kostenstellenstandardhierarchie damit alle Kostenstellen ausgewertet werden.

2. Zeile Innenauftrag
Merkmal Auftrag (Set, Variable) 6-AUFGR

Beide Zeilen erhalten über die Schaltfläche Expandieren (UMSCH+F9) die Option EINZELWERT, so dass am Ende nur die Nummer des CO Objekt ausgegeben wird.

Dazu wurde im Berichtslayout FORMATIERUNG->BERICHTSLAYOUT in Register Schlüsselspalte als Inhalt SCHLÜSSEL gewählt.

Beim Aufruf des Berichtes können nun Kostenrechnungskreis, Geschäftsjahr und Bis Periode sowie die Auftragsgruppe angegeben werden.

Interaktive Stammdatengruppe durch Selektionsvariante

Für unseren Finanzbericht sollen die Landesmittel ausgewertet werden. Diese werden über alle Kostenstellen, sowie alle Innenaufträge mit L-Profit-Center abgebildet. Hier könnte nun natürlich immer eine Auftragsgruppe gepflegt werden, aber dieses ist recht aufwändig, so dass hier eine schönere Variante in SAP vorhanden ist.

Beim Feld Auftragsgruppe kann über die Wertauswahlhilfe (F4 Taste) durch Markierung von "Mit Selektionsvarianten" auf angelegte Selektionsvarianten zugegriffen werden. Unter anderen haben wir hier eine Selektionsvariante .Z_FINB-LPCTR angelegt in der alle Innenaufträge mit zugeordneten L-Profit-Center zur Laufzeit als Selektion ausgewählt werden.

Diese Vorgehensweise habe ich im Artikel "Selektionsvariante KOK5 und Statusselektionsschemata zur Auswertung gesperrter Innenaufträge" für gesperrte Innenaufträge beschrieben, was eine Anforderung eines Kollegen einmal war. Dieses funktioniert natürlich auch mit einfacheren Abfragen.

Die Selektionsvarianten können über KS13 für Kostenstellen und KOK5 für Innenaufträge angelegt werden. (01. Juni 2017) Paperback ISBN: 9783960127406

Für 19,95 € direkt bestellen

Oder als SAP Bibliothek-Flatrate *

Oder bei Amazon *

Vielleicht finden sich hier ja auch noch weitere Anregungen für den Aufbau eines Berichtswesen mit SAP nicht nur für CO im Buch. Manchmal können solche Anforderungen ja auch außerhalb des Hochschulberichtswesen und Hochschulcontrolling aktuell sein.

Manchmal können solche "kleinen" Kniffe dann tatsächlich das Berichtswesen oder Controlling, nicht nur an Hochschulen, erweitern.



* Amazon Partnerlink
Als Amazon-Partner verdiene ich an qualifizierten Käufen über Amazon.

---

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.

---

Im Buch »Berichtswesen im SAP®-Controlling« bin ich ausführlich auf das Thema Varianten von Berichten zur Vorbelegung von Selektionsfeldern sowie auf die Selektionsvarianten (zum Beispiel über Kostenstellen mit der Transaktion KS13 oder über Innenaufträge in der Transaktion KOK5) eingegangen durch die über vordefinierte Merkmale Stammdaten wie Kostenstellen oder Innenaufträge in Berichte selektiert werden können.

Innerhalb der KOK5 kann tatsächlich zwischen den "Auftragsphasen" ERÖFFNET, FREIGEGEBEN, TECHNISCH ABGESCHLOSSEN und ABGESCHLOSSEN selektiert werden. Sofern nun aber Projekte GESPERRT werden, wenn diese fertig sind und nicht der Status auf ABGS für Abgeschlossen gesetzt wird kann dieser in der KOK5 nicht auf Anhieb selektiert werden.

Im Abschnitt STATUS findet sich jedoch auch ein Feld Statusselektionsschemata. Über dieses ist es tatsächlich auch möglich Innenaufträge mit Status SPERR auszuwerten, ohne dass hierfür eine Query wie im Artikel "SAP Query: Systemstatus CO Innenauftrag" oder "Änderungsbelege zu Systemstatus (JEST) bei Innenaufträgen per Query auswerten" beschrieben gesetzt werden muss.

Hierzu kann im Customizing über die Transaktion SPRO unter folgenden Pfad ein Selektionsschemata eingesetzt werden

• CONTROLLING
• INNENAUFTRÄGE
• AUFTRAGSSTAMMDATEN
• SELEKTION UND SAMMELBEARBEITUNG
• Statusselektionsschemata definieren

Alternativ ist das auch direkt über die Transaktion BS42 möglich. Technisch sind diese in der Tabelle TJ48 "Prüftabelle der Selektionsids" gespeichert.

Nach Aufruf der Transaktion kann über die Schaltfläche NEUE EINTRÄGE ein Selektionsschemata angelegt werden. Der Eintrag muss dann markiert werden und über den Punkt SELEKTIONSBEDINGUNG kann dazu ein oder mehrere STATUS per UND verknüpft werden. Als Beispiel kann hier ABGS und SPER in die Spalte Status eingetragen werden.

Damit umfasst diese Selektionsvariante alle abgeschlossenen / gesperrten Innenaufträge. Über die Spalte NICHT (Checkbox) kann hier auch eine negative Selektion (sprich entspricht nicht diesem STATUS) ergänzt werden.

Nachdem dieses angelegt worden und per Customizing-Transportauftrag transporiert worden ist (Tabellenpflege) besteht nun die Möglichkeit in der KOK5 dies als Selektion im Feld STATUSSELEKTIONSSCHEMATA zu hinterlegen.

Interessant wird das ganze dadurch, dass im Feld Auftragsgruppe auf diese in der KOK5 angelegten Selektionsvariante in der F4 Auswahlhilfe zugegriffen werden kann, wenn die entsprechende Option gesetzt ist.

Interessant kann dieses werden, wenn eine Kostenstelle selektiert wurde und als zugeordnete Innenaufträge alle zugehörigen nicht gesperrten Innenaufträge zum Beispiel beim Report Writer / Report Painter Bericht selektiert werden soll.

Diese Möglichkeit ist durch Kombination des SELEKTIONSSCHEMATA in einer Selektionsvariante und der Vorgehensweise im Artikel "CO Objekte indirekt auswerten Teil 1/2 hier: Anhand Kostenstelle im Report Writer zugeordnete CO Objekte Innenauftrag und Kostenstelle" beschrieben.

Gerade solche Kniffe (oder nennen wir es Tipps und Tricks) sind ein Grund, warum mir das Projekt "Buchveröffentlichung »Berichtswesen im SAP®-Controlling«" oder auch mein Vortrag am FICO Forum 2016 (siehe "Vortrag Controlling Tipps aus der Praxis für die Praxis und die Espresso digitale SAP Bibliothek Flatrate") tatsächlich Freude gemacht hat insbesondere, da das Thema Berichtswesen im Controlling tatsächlich auch ein Herzensthema von mir ist.

Sollte dies ebenfalls Interesse geweckt haben verweise ich gerne auf die Möglichkeit des Onlineshop auf dieser Seite sowie für Hochschulen auf die Neuigkeiten meines Verlages zum Thema "SAP-Flatrate für Hochschulen - Digitale SAP-Fortbildungsplattform für Studenten und Hochschulmitarbeiter".

Über eine Jahrespauschale erhalten alle Studenten und Hochschulangehörige Zugriff auf die digitalen SAP-Bibliothek von Espresso Tutorials und damit einem breiten, praxisnahen Wissenspool rund um SAP.  Die Vorteile der Flatrate habe ich schon unter SAP Know How vorgestellt und bin tatsächlich überzeugt vom Angebot.

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.
 

Im Rahmen der Berichtsdokumentation kann es hilfreich sein vorhandene Selektionsvarianten zu dokumentieren.

In den meisten Berichten ist dieses über

• SPRINGEN ->
• VARIANTEN ->
• ANZEIGEN

oder aber direkt wie bei der KOK5 durch die Schaltfläche ANZEIGEN (die mit der Brille) möglich in Form einer ALV Liste diese anzuzeigen.

Sofern hier aber kein Druckersymbol aktiv ist, fällt es schwer die getofffenen Merkmale zu dokumentieren. Allerdings gibt es dafür hinter der rechten Maustaste die Option TABELLENKALKULATION wodurch die dargestellte Liste mit den Einzelwerten in eine beliebige Tabellenkalkulation exportiert werden kann.

Sollte hier einmal das falsche Format in Kombination mit "Immer das gewählte Format anwenden" gewählt haben dürften die Ausführung zum Abschnitt SALV_BS_ADMIN im Artikel "Grundlagen - Berichte von SAP nach Excel exportieren" nützlich sein.

Vorhandene Varianten transportieren

Gerade bei der Dreiteilung eines SAP System (Develop (Entwicklung), Quality (Qualitätssicherung), Productiv (Produktivsystem)) kann es auch erforderlich sein vorhandene Varianten auf ein jeweils nachgelagertes System zu transportieren.

Die hierzu erforderlichen Schritte sind unter "Transport von Selektionsvarianten" beschrieben.

Grundsätzlich sollte eine umfangreiche Dokumentation zu einmal angelegten Berichten immer vorhanden sein welche nicht nur dann relevant wird, wenn aus Versehen eine Variante gelöscht wurde. Zumindest die übergreifend zur Verfügung gestellten Selektionsvarianten sind sinnvollerweise festzuhalten.

Wie schon im Artikel "Geschützte Selektionsvarianten entsperren" erläutert sind die einzelnen angelegten Varianten in der Tabelle VARID "Variantenkatalog" hinterlegt.

Anhand von Varianten häufig genutzte Berichte identifizieren

Gerade bei einen Jobwechsel wo die vorherige Stelleninhaber kaum Dokumentationen über die individuellen Berichte (FI, CO) hinterlassen haben kann hier abseits von der Suche innerhalb ABAP Workbench, Report Painter und SAP Query eine entsprechende AUswertung weiterhelfen. Über das Feld ENAME der Tabelle VARID kann anhand des Benutzername als Selektionsmerkmal  zu jeden genutzten Programm (Feldname REPORT) entsprechende Reports identifiziert werden. Dabei sind die Einträge AQ*  z.B. SAP Query, GP* dürfen Berichtsgruppen für Report Writer /Painter sein etc..

Anhand der Queryy "Tabellen hinter Transaktionscode oder ABAP Programm über eine SAP Query ermitteln" kann hier auch der umgekehrte Weg beschritten werden um anhand des ABAP Reports die zugehörige Transaktion aus der Tabelle TSTC "SAP-Transaktions-Codes" zu ermitteln. Wobei es hier auch hilfreich ist in dieser Tabelle nach Z oder Y Transaktionen zu schauen, sofern solche angelegt worden sind.

Wobei in diesen Fall auch die Tabelle SMEN_BUFFC ("Tabelle für die Ablage der Favoriten")  hilfreich sein kann, da doch die meistens genutzten Berichte von Usern in den Favoriten abgespeichert werden. Die verschiedenen Individualiserungsmöglichkeiten sind auch im Artikel "Benutzereigene SAP Menüs (Favoriten, Benutzermenü, Bereichsmenü)" erwähnt worden.

Fachliche und technische Dokumentation von Berichten

Ferner kann sowohl auf Sicht der Anwendenden eine "Dokumentation von Berichtsgruppe und Berichtsdokumentation bei Report Painter und Writer Berichten" von Berichten beim Aufruf des Berichtes hilfreich sein als auch aus technischer Sicht wie im Artikel "Report Painter Übersicht von Elementen und Merkmale zur Darstellung der Struktur und Aufbau eines Berichtes" beschrieben .

Wobei gerade die eigenentwickelten Berichten ein Thema für sich selbst. Hier verweise ich sehr gerne auf folgende Grundlagenartikel:

• "Grundlagen Kurzeinführung und Handbuch SAP Query "
• "Grundlagen Kurzeinführung und Handbuch Report Painter Report Writer"

Wobei die verschiedenen von mir gerne genutzte entwickelten Berichtstool im Artikel "Unterschiedliche Auswertungsmöglichkeiten im Controlling (Report Writer, Recherchebericht, SAP Query) und natürlich Excel ;-)" zusammengefasst sind.

Im Zusammenspiel zwischen Entwicklung und Anwendung sollte daher der Punkt Dokumentation sowohl in Richtung Handbuch für Anwendende als auch für die technische Seite betrachtet werden. Hier mag ich auch sehr gerne auf zwei Dokumentationstools beziehungsweise Software in dieser Richtung hinweisen. Besonders die "Software für Prozessbeschreibungen (DIA)" eignet sich für die  "Graphische Darstellung von Tabellenverknüpfungen bspw. bei Query" oder auch  "Ereignisgesteuerte Prozesskette in DIA darstellen (weitere Objekte einfügen)", Daneben merke ich aber auch, dass mir die Software XMIND, wie im Artikel "Mindmapping und Sketchnotes im Beruf nutzen für Brainstorming oder Mind Mapping mit XMIND" beschrieben nutze. Diese eigent sich sogar dafür Aufgaben oder Organisationen darzustellen.

Inhaltlich ist daher das Thema Berichtswesen sicherlich auch auf Dauer noch ein Thema, dass regelmäßig hier im Blog aufschlägt und aufschlagen wird.

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.

Ausgangslage:
Für bestimmte Reports hinterlegte Selektionsvariante ist das Merkmal "Variante schützen" gesetzt, so dass keine Änderung mehr durch andere User, als denjenigen der dieses Merkmal gesetzt hat, durchgeführt werden können. Dieses ist insbesondere problematisch, wenn die entsprechende Person ausgeschieden ist.

Lösung:
Über den ABAP-Report "RSVARENT" kann dieser Schutz entfernt werden.

Der Report kann über die Transaktion SA38  gestartet werden. Nachdem der Report gestartet wurde, werden Rpor


Hierzu müssen als Werte
Reportname  bzw. S_REPORT (Der hinter den Bericht zugrundeliegende Reportname)
und
der Variantenname S_VARI
eingetragen werden und der Report ausgeführt. Hierdurch ist dann das Merkmal gelöscht.


Die Information, welcher Report hinter einen Bericht hängt ist in der Selektionsmaske des Berichtes über

• System
• Status

im Feld Report in den Repository Daten zu entnehmen. Alternativ kann dieser auch, wie im Artikel Tabellen hinter Transaktionscode oder ABAP Programm über eine SAP Query ermitteln beschrieben, aus der Tabelle TSCT über das Feld PGMNA entnommen werden.

Technischer Hintergrund:
Der Schutz von Selektionsvarianten erfolgt in der Tabelle VARID "Variantenkatalog". Hier sind die Felder REPORT "ABAP: Reportname im Variantenschlüssel", VARIANT "ABAP: Name einer Variante (ohne Programmname)" entscheidend um das entsprechende Programm und die angelegte Variante zu identifizieren. Über die Felder ENAME "Benutzername" und das Feld PROTECTED "Flag (Character)." wird festgelegt unter welchen User die Variante gesichert ist. Das Programm entfernt das entsprechende Flag.

Selektionsvarianten für KOK5 entsperren

Eine Besonderheit sind gegebenenfalls noch die Selektionsvarianten für Innenaufträge, die über die Transaktion KOK5 ausgewählt werden können. Während der Transaktion KOK5 das Programm SAPMKAUF zugeordnet ist, sind die einzelnen Selektionsvarianten dem ABAP Programm  / Report RKOSEL00 zugeordnet, so dass diese über diesen Reportnamen (S_REPORT) bearbeitet werden können.

Praktisch bedeutet dieses, dass um Varianten der KOK5 zu löschen beziehungsweise das Sperrkennzeichen zu entfernen hierzu ebenfalls der Report RSVARENT über die Transaktion SA38 aufgerufen werden sollte und als S_REPORT der Reportname RKOSEL00 eingetragen werden soll. Wichtig ist dabei, dass dann auch das Feld S_VARI gefüllt wird, da andernfalls alle Varianten entsperrt werden.
 

Weitere Informationen rund um das Thema Selektionsvarianten

Ebenfalls interessant kann der Beitrag "Transport von Selektionsvarianten" sein, sofern Sie hier entsprechende geschützte Varianten vorfinden.

Ein von mir häufig geschätztes Anwendungsgebiet von Selektionsvarianten ist diese auch in kundeneigene Transaktionen wie "Parametertransaktion für Reporwriter" oder "Transaktion anlegen (Report, Parameter) bspw. für SAP Query / Unterschied Parameter- oder Reporttransaktion" beschrieben.

Wenn es um die einzelnen Funktionen einer Selektionsvariante geht ist auch der Artikel "PSM: Selektionsvarianten und Wertübernahme aus vorherigen Selektionen" lesenswert, da hier die Vorschlagswerte aber auch die Funktion von GPA ausschalten erläutert wird.

Frühjahrsputz bei ausgeschiedenen SAP Usern

Sofern derzeit ohnehin einige Berichte aufgeräumt werden sollen ist auch der Artikel "Frühjahrsputz oder geschützte Varianten und nicht mehr benötigte Rechercheberichte entfernen oder reorganisieren" sehr nützlich.

Wie unter den technischen Informationen angegeben finden sich alle Varianten in der Tabelle VARID die zum Beispiel mit der SE16 oder noch schöner der SE16H oder einer Query ausgelesen werden kann. Hier merkte K.Kohl im unteren Kommentar an "Um den Namen des Report- bzw. der Variante zu ermitteln nimmt man die SE16N mit der Tabelle VARID. Geschützte Varianten haben ein "x" in der Spalte "FLAG" Es kann u.a. auch nach SAP-User selektiert werden. Ist hilfreich, wenn der User das Unternehmen verlassen hat.". Dieses sollte tatsächlich noch einmal extra erwähnt werden, daher übernehme ich den Kommentar noch mit in diesen Abschnitt. Weiterhin ist darauf zu achten, dass auch auf anderen Stellen (bspw. Extrakte im Report Writer) oder weitere Berichtseinstellungen diese zum Teil mit den nun nicht mehr vorhandenen oder gesperten User verknüpft sind. Dieses kann u.a. auch Workflows betreffen... aber das ist wiederum ein anderes Thema.


 

---

Hinweis:

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

---

Ausgangslage:

Bei Umbenennung von Gebäuden oder anderen Kostenträgern kann es der Fall sein, dass eine vorhandene Kostenstelle innerhalb der Stammdaten umbenannt werden.

Die Bezeichnung einer Kostenstelle kann hier bspw. im Zeitraum 1999 bis 2006 ABC und ab 2007 DEF lauten.

Innerhalb eines Berichtes ist eine Selektionsvariante im Jahr 2006 angelegt die im Jahr 2007 ausgeführt die alte Bezeichnung DEF angezeigt.

Lösung:

Um dieses Problem zu beheben kann in der Selektionsvariante das Merkmal Stichtag mit den Feldern "Merkmal ohne Wert abspeichern" und "GPA ausschalten" gespeichert werden.

Bei Recherchenberichte (sei es Belegjournal oder selbst erstellten Rechercheberichten) werden teilweise bei ausgewählten Varianten mit geschützten Feldern die keine Werte enthalten, in diese eigentlich leeren Felder (bspw.
Finanzstelle, Finanzstellengruppe, Fonds, Fondsgruppe) Werte aus vorherigen Auswertungen in ähnlichen Berichten genommen und behindern
damit eine Auswertung.

Um dieses zu umgehen, sollte bei der gewünschten Übernahme von leeren Feldern innerhalb der Variantenspeicherung die Markierung "GPA ausschalten" gesetzt werden.

Technischer Hintergrund:

Ein Vorschlagswert aus einer vorherigen Selektionsvariante hat stets Priorität, wenn der Wert nicht initial ist. Für initiale Werte kann in der Variantenpflege das Ankreuzfeld "GPA ausschalten" gesetzt werden.

In diesem Fall wird der Initialwert aus der Variante gesetzt. Dieser Wert kann auch null bzw. leer sein. Ansonsten haben SET-Parameter Vorrang.

Ist das Ziel leere Felder in der Selektionsvariante zu übernehmen sollte daher das Feld "GPA ausschalten" gesetzt sein.

Wenn mehrere der oben genannten Funktionen kombiniert werden, gelten
folgende Regeln:

Transaktionsvariante - SET/GET-Parameter:

Ein Vorschlagswert aus einer Transaktions-/Screenvariante hat Priorität, wenn mit der Variante ein Feld auf nicht eingabebereit oder unsichtbar gesetzt wird, oder wenn mit SET-Parameter ein initialer Vorschlagswert gesetzt wird (z.B. SPACE). Umgekehrt haben bei eingabebereiten Feldern Vorschlagswerte von SET-Parametern Priorität, da diese z.B. auch durch Benutzereingaben verursacht sein können.

Selektionsvariante - SET/GET-Parameter:

Ein Vorschlagswert aus einer Selektionsvariante hat stets Priorität, wenn der Wert nicht initial ist. Für initiale Werte kann in der Variantenpflege ein Ankreuzfeld SPA/GPA
ausschalten gesetzt werden. In diesem Fall wird der Initialwert aus der Variante gesetzt, sonst haben SET-Parameter-Werte Vorrang.

GuiXT in Kombination mit anderen Funktionen:

Vorschlagswerte werden über GuiXT nur dann gesetzt, wenn das betreffende Feld einen initialen Wert hat. Das gilt sowohl für das Setzen eines Wertes über eine Transaktion, SET/GET oder über eine Variante.

Zur Vereinfachung des Auswertens ist es innerhalb des Berichtswesen (Infosystem) möglich sich Selektionsvarianten anzulegen. Diese werden dann, sofern diese nicht in der Namensform CUS%...Name angelegt sind nicht automatisch in andere Systeme transportiert. Um eigene Selektionsvarianten zu transportieren ist folgender Weg sinnvoll.

Bei den Varianten CUS%.. bzw. SAP%.. . handelt es sich um sogenannte Systemvarianten  die entweder von Ihnen oder durch SAP angelegt worden sind. Diese Varianten haben als Besonderheit, dass diese in allen Mandanten angelegt werden können und durch ihre Anbindung an den Workbench Organizer lediglich im Mandanten " 000 " abgelegt sind, aber von allen anderen Mandanten auf diese zugegriffen werden können,


A) Variante auswählen

1. ABAP Report herausfinden.

Ist der Bericht aufgerufen so kann man im Anwendermenü über SYSTEM->STATUS die Bezeichnung des ABAP Reports hinter der Transaktion erfahren (Feld REPORT).

2. ABAP Report aufrufen

Der Report kann über die Transaktion SE38 aufgerufen werden (ABAP Editor) und die Varianten angezeigt werden. Alternativ geht dieses über SPRINGEN->VARIANTEN im eigentlichen Bericht. Hier erhalten Sie eine Übersicht aller Varianten.


B) Variantentransportauftrag

Innerhalb der Transaktion SE38 kann über Hilfsmittel->Transportauftrag ein Transportauftrag für die Varianten erstellt werden. Hierzu benötigen Sie natürlich entsprechende Berichtigungen für die Transaktion SE38 (SAP Abap Editor)

Alternativ kann auch direkt der ABAP Report RSTRANSP über die Transaktion SA38 gestartet werden. Hier können dann Programmname (der ABAP Report) und Variantenname (die entsprechende Variante) hinterlegt werden.


Das Programm erzeugt Einträge für den Variantentransport. Die Namen der Varianten, die transportiert werden sollen, können generisch eingegeben werden.

Der Variantentransport ist nur für Programme mit Entwicklungsklasse ungleich $TMP möglich.

Es wird ein Workbenchauftrag generiert, der dann transportiert werden kann.
 

Nachtrag 2024:

Im Artikel "Varianten vom Selektionsbild (Selektionsvarianten) für Report Painter Berichte transportieren" die Transaktionen SVAR_UPLOADDOWNLOAD  und SVAR_CHECK zum Transport von Reportvarianten (nicht nur) für Varianten zu Report Painter Berichten vor.

 

Weitere Informationen rund um das Thema Selektionsvarianten

Ebenfalls interessant kann der Beitrag "Geschützte Selektionsvarianten entsperren" sein, sofern Sie hier entsprechende geschützte Varianten vorfinden.

Ein von mir häufig geschätztes Anwendungsgebiet von Selektionsvarianten ist diese auch in kundeneigene Transaktionen wie "Parametertransaktion für Reporwriter" oder "Transaktion anlegen (Report, Parameter) bspw. für SAP Query / Unterschied Parameter- oder Reporttransaktion" beschrieben.

Wenn es um die einzelnen Funktionen einer Selektionsvariante geht ist auch der Artikel "PSM: Selektionsvarianten und Wertübernahme aus vorherigen Selektionen" lesenswert, da hier die Vorschlagswerte aber auch die Funktion von GPA ausschalten erläutert wird.

Ein weiters Anwendungsgebiet ist im Artikel "Kundeneigene Transaktionen zu Berichten in PSM FM Haushaltsmanagement zum Beispiel Belegjournal anlegen (Variantentransaktion)" beschrieben und gerade im Berichtswesen sehr praktisch.


Im Buch »Berichtswesen im SAP®-Controlling« bin ich ausführlich auf das Thema  Berichtswesen 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.