Das Thema Zusatzfeld und passendes Coding hatte ich schon im Artikel "Auswertung sprechender Nummernkreisintervalle von CO Innenaufträgen mit Query Zusatzfeldcoding und Unterscheidung numerischer oder alphanumerischer Schlüssel" besprochen.

Das Beispiel von damals sollte verwnedet werden, damit eine IF Schleife nur bei Zahlenwerten (ohne Buchstaben) erfolgt.

ABAP: Enthält Variable nur Zahlenwerte

Vorab sollte man sich jedoch bewust sein, dass ein Innenauftrag als Schlüsselfeld durchaus alphanumerische Werte enthalten kann. Hier stellt sich also die Frage, wie es möglich ist die Auftragsnummer zu überprüfen, ob tatsächlich nur Zahlenwerte enthalten sind.

Hier kann eine Wenn Funktion (IF) mit der vergleichendenen Anweisung CO (contains only) weiter helfen. ABAP hat einige Vergleichsoperatoren, so dass hier Variablen mit Variablen oder aber auch mit bestimmten Werten verglichen werden können. Zu diesen logischen Ausdrücken gehört unter anderen CO (contians only), CN (contains not only) und weitere. Diese liefern ein Wahr wenn der Vergleich erfolgreich war und nur die Zeichen des Vergleichsparameter vorhanden war (CO) oder aber wenn noch weitere Zeichen dabei sind (CN). Interessant ist auch noch die Möglichkeit CS (contains string) womit vergleicht werden kann, ob eine bestimmte Zeichenfolge in einen Wert vorhanden ist.

Ein ausführliches Beispiel wäre

DATA: L_ZAHLEN(10) TYPE c VALUE = '0123456789'.
* L_zahlen enthaelt Zahlenwerte Leerzeichen
DATA: L_innenauftrag type AUFK-AUFNR.

IF L_innenauftrag CO L_ZAHLEN.
* Reine Auftragsnummer

ELSEIF.
* Alphanumerischer Innenauftrag

ENDIF.

Selbstverständlich lässt sich dieses auch ohne Definition einer Konstanten regeln. Hierzu kann folgende Anweisung erstellt werden:

IF AUFK-AUFNR CO  '1234567890'.
* Innenauftrag hat nur Nummern
ELSEIF.
*Innenauftrag ist alphanumerisch
ENDIF.

Damit kann nun mit den vorhandenen Zahlenwerten weitergearbeitet werden.

Auch sonst wurden hier noch weitere Übersetzungen der Aufrtragsnummer in einen sprechenderen Schlüssel / Text vorgestellt.

ABAP Vergleichsoperatoren

Isa Bodur hat im Artikel "Auswertung sprechender Nummernkreisintervalle von CO Innenaufträgen mit Query Zusatzfeldcoding und Unterscheidung numerischer oder alphanumerischer Schlüssel" einige Vergleichsmöglichkeiten mit Erläuterungen vorgestellt.

Diese mag ich hier kurz als Tabelle aufführen.
 

ABAP Vergleichsoperatoren

Operator	Bedeutung
CO	Contains Only / Enthält nur …
CN	Contains Not only / Enthält nicht nur …
CA	Contains Any / Enthält mindestens eines der folgenden Zeichen
NA	Contains Not Any / enthält keines der Zeichen
CS	Contains String / enthält Zeichenkette
NS	contains No String / enthält Zeichenkette nicht
CP	Covers Pattern: passend zum Muster
NP	No Pattern: keine Übereinstimmung zum Muster

Beim Pattern / Muster ist zu beachten, dass * eine Zeichenkette und + für ein beliebiges Zeichen steht.
Zum besseren Verständnis nehmen wir eine Variable html als Zeichenkette und geben hier HTML Code als Inhalt.

DATA html TYPE string.
html ='Dieser Text ist <i>kursiv</i>.'

Hier ist das HTML Tag <i> und </i> für kursive Schrift verantwortlich.

In der Prüfung kann nun per

IF html CP '*<*>*'.

darauf reagiert werden, dass die Variable html HTML Code enthält.

Praxisbeispiel CS enthält Zeichenkette

Die CO Innenaufträge sind sowohl über das zugeordnete Profitcenter als auch über die verantwortliche Kostenstelle weiteren Bereichen zugeordnet.

Abhängig vom zugeordneten Profitcenter soll nun eine weitere Information (zum Beispiel der im Kostenstellenschlüssel hinterlegte Abteilung) mit in einer Stammdatenliste ausgegeben werden. Dies soll aber nur bei solchen Innenaufträgen erfolgen die zu bestimmten Buch-Profitcentern gehören ausgegeben werden.

Hier sind die Profitcenter B-SAP, B-OFFICE, B-BWL jeweils für eine bestimmte Sparte von Büchern unseres Verlages hinterlegt.

Nun haben wir ein Zusatzfeld ZABTEILUNG (Type C, Länge 030, Ausgabelänge 030) angelegt und werden hier durch folgendes Coding eine Prüfung durchführen.

Schritt 1:
Leeren der Variable ZABTEILUNG:

CLEAR ZABTEILUNG.

Schritt 2:
Ist das zugeordnete Profitcenter keines mit der Zeichenkette 'B-' soll als Wert NR ausgegeben werden:

IF AUFK-PRCTR NS 'B-'.
  ZABTEILUNG = 'NR'.
ENDIF.

Schritt 3:
Enthält das Profitcenter doch B- soll anhand der verantwortlichen Kostenstelle der sprechende Schlüssel übersetzt werden:

IF AUFK-PRCTR CS 'BS-'.

Schritt 4:
Die Übersetzung des Kostenstellenschlüssels soll jedoch nur bei numerischen Kostenstellen erfolgen:

 IF AUFK-KOSTV CO  '1234567890'.

Schritt 5:
Diverse Bedingungen (IF Schleife) zur Übersetzung des Kostenstellenschlüssels, wobei die Kostenstelle hier mit führenden 0 auf zehn Zeichen geprüft wird.Die Unterscheidung der Abteilungen ist anhand der ersten Ziffer der Kostenstellenummer zu sehen:

• 1 = Verwaltung
• 2 = Einkauf
• 3 = Gebäude
• 4 = Redaktion
• 5 = Produktion

Dabei werden siebenstellige Kostenstellenschlüssel verwendet.

 IF
    AUFK-KOSTV BETWEEN '0001000000' AND  '0001999999'.
    ZABTEILUNG = 'Verwaltung'.
  ELSEIF
    AUFK-KOSTV BETWEEN '0002000000' AND  '0002999999'.
    ZABTEILUNG = 'Einkauf'.
  ELSEIF
    AUFK-KOSTV BETWEEN '0003000000' AND  '0003999999'.
    ZABTEILUNG = 'Gebäude'.
  ELSEIF
    AUFK-KOSTV BETWEEN '0004000000' AND  '0004999999'.
    ZABTEILUNG = 'Redaktion'.
  ELSEIF
    AUFK-KOSTV BETWEEN '0005000000' AND  '0005999999'.
    ZABTEILUNG = 'Produktion'.
 ENDIF.

Schritt 6:
Die Prüfung des Intervalles der Kostenstelle ist damit abgeschlossen und wir schließen beide IF Schleifen (Nummernschlüssel Kostenstelle und Profitcenterprüfung)

 ENDIF.
ENDIF.

Dieses Zusatzfeld kann nun in der Grundliste der Query mit aufgenommen werden.

Das vollständige Coding zum Zusatzfeld lautet also:

CLEAR ZABTEILUNG.
IF AUFK-PRCTR NS 'B-'.
  ZABTEILUNG = 'NR'.
ENDIF.

IF AUFK-PRCTR CS 'BS-'.
 IF AUFK-KOSTV CO  '1234567890'.
 IF
    AUFK-KOSTV BETWEEN '0001000000' AND  '0001999999'.
    ZABTEILUNG = 'Verwaltung'.
  ELSEIF
    AUFK-KOSTV BETWEEN '0002000000' AND  '0002999999'.
    ZABTEILUNG = 'Einkauf'.
  ELSEIF
    AUFK-KOSTV BETWEEN '0003000000' AND  '0003999999'.
    ZABTEILUNG = 'Gebäude'.
  ELSEIF
    AUFK-KOSTV BETWEEN '0004000000' AND  '0004999999'.
    ZABTEILUNG = 'Redaktion'.
  ELSEIF
    AUFK-KOSTV BETWEEN '0005000000' AND  '0005999999'.
    ZABTEILUNG = 'Produktion'.
  ENDIF.
 ENDIF.
ENDIF.

 

Weitere Beispiele ABAP Code im Zusatzfeldcoding

Ein umfangreicheres Beispiel inklusiver einer SELECT Abfrage über alle passenden Ergebnisse zur Abfrage über die verantwortliche Kostenstelle des CO Innenauftrags und eines Feld innerhalb der Kostenstellenstammdaten ist im folgenden Coding zu sehen. Dabei sind im folgenden Code die Regeln als Kommentar mit vorangestellten * im Coding hinterlegt.

Zusatzfeld VLE (Typ C und Länge 030).

DATA: L_CSKSTELTX type CSKS-TELTX.

* Regel 1 Für das Intervall der Kostenstellen 10000000 bis 12345678

IF AUFK-KOSTV => '0010000000' AND AUFK-KOSTV =< '0012345678'.

* Regel 1.1 Die ersten Ziffern der Kostenstelle ohne führende 00

WRITE AUFK-KOSTV(6) TO VLE NO-ZERO .

* Regel 1.2 Sonderfälle einzelner Kostenstelle

ELSEIF AUFK-KOSTV => '0011110000' AND AUFK-KOSTV =< '0011119999'.
  VLE = '1111BE'.
ELSEIF AUFK-KOSTV = '0012340000'.
  VLE = '1234BE'.


* Regel 2 Verantwortliche Kostenstelle ohne führende 00

ELSE.
  WRITE AUFK-KOSTV TO VLE NO-ZERO .
ENDIF.

* Regel 3 Feld Teletexnummer (Stammdaten Kostenstelle - Tabelle CSKS) ist gefüllt


SELECT teltx FROM csks INTO L_CSKSTELTX up to 1 rows
  WHERE kokrs = AUFK-KOKRS
  AND kostl = AUFK-KOSTV
  and datbi >= SY-DATUM
  and teltx ne space.
ENDSELECT.
IF sy-subrc = 0.
    VLE = L_CSKSTELTX.
ENDIF.

Eine inhaltliche Erläuterung ist im Artikel "Query über COEP, AUFK und FMFINCODE für Einzelposten Istkosten Innnenauftrag mit Stammdaten aus CO und PSM-FM sowie Spalten für Ertrag und Aufwand - Erster Teil Infoset als Datengrundlage" im Abschnitt "Zusatzfeld VLE zur Darstellung virtueller Lehreinheit aus Teilstring der verantwortlichen Kostenstelle, sofern nicht in einem anderen Feld ein Wert steht" erläutert.

Gerade im Berichtswesen ist es hilfreich, sich einige Werkzeuge zum Reporting und ihre Möglichkeiten näher anzusehen.



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.

Dabei sind SAP Query und Report Painter für mich noch immer praktische Tools um Berichte zu erstellen.
 

---

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.

---

Im Artikel "LOAD_PROGRAMM_NOT_FOUND Programm AQCS oder AQZZ bei Aufruf Query per Reporttransaktion - SAP Query nachgenerieren lassen" hatte ich beschrieben, wie bei einer Reporttransaktion zu einer SAP Query das entsprechend aus der SAP Query generierte ABAP Programm erneut generiert werden kann.

Zur Erinnerung, der Programmname zu einer SAP Query ist abhängig davon, ob es sich um eine globale oder eine Query im Standardbereich handelt, folgt aufgebaut:
 

Aufbau Programm für Query

1	2	3	4	5	6
Globaler Bereich	AQ	ZZ	RM_CO	====	Z_QUERY01=====
Standardbereich	AQ	CS	AG_CO	====	Z_QUERY02=====

Aus der Tabelle sind der Aufbau des Programmnamen zu erkennen (insgesamt sind dieses 29 Zeichen bestehend aus den Spalten 2 bis 6. Wobei hier === als Füllzeichen zu sehen sind.

Ausgangslage: Rückfrage zur Massenpflege erneute Generierung der Query für Reporttransaktion

Der Artikel ist schon etwas älter und letztens erreichte mich dazu die Frage, ob es hier nicht die Möglichkeit gibt einer "Massenpflege" eben dieser Query, da mit Umstieg auf EHP8 eine Menge an solcher Transaktionen zu SAP Query nicht mehr funktionieren.

Im Artikel "Änderungen und Nacharbeiten nach Einspielung SAP ERP 6.0 Enhancement Package 8 (EHP 8) insbesondere im CO" bin ich ebenfalls auf dieses Problem eingegangen.

Die Lösung dazu war, dass die Query durch die Transaktion REISSQMAIN bzw. über den Report SAP_QUERY_CALL erneut mit Angabe der Benutzergruppe und Query aufgerufen worden ist.

Workaround: zu bestehenden Reporttransaktionen die Query erneut generieren lassen

Dieses ist relativ umständlich und so liegt der Gedanke nahe, dass es doch eine einfachere Variante geben sollte.

Queryverzeichnis und Vormerken der Generierung
Der erste Gedanke wäre hier im Verzeichnis der SAP Query über die Transaktion SQ02 - Infoset pflegen über das Anwendungsmenü

• (Mehr)
• Springen
• Queryverzeichnis

entweder anhand einer selektierten Benutzergruppe oder direkt über Ausführen in der Liste aller Query die Query auswählen und über die Schaltfläche "Mark. Query" (Programmgeneierung UMSCH+F8) die einzelnen Query erneut generieren zu lassen.

Problematisch dabei ist jedoch, dass dadurch die Query nur zur Generierung vorgemerkt werden und das Coding zum ABAP Programm erst beim nächsten Start der Query durchgeführt werden.

Dieser Aufruf müsste also erneut über SQ00 / SQ01 (Query ausführen) oder über REISSQMAIN erfolgen.

Technischer Hintergrund:
SAP Hinweis: 735939 - SAP Query: Query-Reports nicht nachgeneriert

1. Alternative: Transaktionsaufzeichnung von REISSQMAIN

Denkbar wäre auch, ohne es selbst getestet zu haben, eine Transaktionsaufzeichnung der Transaktion REISSQMAIN per LSMW oder eCAT (siehe "Massenstammdatenpflege mit LSMW oder SECATT dank Transaktionsaufzeichnung - Handbuch erweiterte computergestützte Test-Tool (eCATT) und LSMW"). Basis kann hier ebenfalls das Queryverzeichnis als CSV bestehend aus Benutzergruppe und Query sein.  Das entsprechende Verzeichnis kann, wie im Artikel "Reportmatrix über bestehende kundeneigene SAP Berichte (Report Writer, Recherche oder SAP Query)" beschrieben, über die Transaktion SQ02 per Queryverzeichnis erstellt werden.

Achtung: Ich befürchte jedoch, dass die Aufzeichnung problematisch sein kann, da ja kein Ende der Aufzeichnung mit aufgezeichnet wird sondern nur die Query gestartet aber nicht abgebrochen wird. Dennoch ist es natürlich enen Versuch wert.
 

Dauerhafte Lösung: Umstellung Transaktionen von Reporttransaktion auf Parametertransaktion zum Aufruf von SAP Query

Um künftig solche Probleme zu vermeiden ist es eine gute Idee statt einer Reporttransaktion, wie in den beiden Artikeln "SAP Query als kundeneigene Transaktion mit Berechtigungen für Tabellenberechtigungsgruppe, Tabellen und Reporttransaktion vergeben" und "Transaktion anlegen (Report, Parameter) bspw. für SAP Query / Unterschied Parameter- oder Reporttransaktion" eine Parametertransaktion zum Aufruf einer Query anzulegen oder vorhandene Transaktionen umzustellen und künftig hier weniger Probleme zu haben.

Unterschied Reporttransaktion und Parametertransaktion

Als Reporttransaktion wird die Query, der Report direkt gestartet. Hier könnte nun auch ein Berechtigungsobjekt mit Werten hinterlegt werden, auf die die Berechtigungen der Benutzer geprüft werden. Über das Selektionsbild 1000 gelangt man auch direkt in das Auswahlfenster der Transaktion. Über die Option "Einstiegsbild überspringen" kann der Bericht auch ohne weitere Angaben von Selektionswerten direkt übersprungen werden. Dieses kann zum Beispiel sinnvoll sein, wenn im Bericht schon alle Variablen gefüllt sind und der Bericht nur direkt ausgeführt werden soll. Hier hatten wir den generierten Reportnamen zur SAP Query als ABAP Programm genommen und obiges Problem ist entstanden.

Eine Parametertransaktion ermöglicht es Varianten zu einer Transaktion anzulegen. Hier bietet sich bspw. die Transaktion START_REPORT an.  Hier geben wir in der Parametertransaktion bestimmte Vorschlagswerte zur Transaktion START_REPORT vor und überspringen das Einstiegsbild.  Hierbei werden die Dynprofelder der Transaktion festgelegt. So lautet die Bezeichnung des Feldes Report der Transaktion START_REPORT bspw. "D_SREPOVARI-REPORT". So dass hier der Reportname entsprechend eingegeben werden kann. Interessanter ist hier jedoch noch das Feld Variante (Dynprofeld "D_SREPOVARI-VARIANT"), da hier entsprechend gepflegte Selektionsvariante je Report hinterlegt werden können.  Auf diese Weise kann direkt über die kundeneigene Transaktion eine entsprechende Selektionsvariante zu einen Report (inkl. etwaiger gesperrter Felder) gestartet und ausgewertet werden.  Somit eignet sich diese Transaktionsvariante insbesondere dann, wenn man auch gleich eine Selektionsvariante mit übergeben bzw. entsprechend ausgewählt haben mag.

Parametertransaktion für SAP Query

Als Parameter für die Transaktion START_REPORT wären hier folgende Dynprofelder mit entsprechenden Werten zu füllen.

• D_SREPOVARI-REPORTTYPE
  AQ
• D_SREPOVARI-REPORT
  Benutzergruppe (für Querys im globalen Bereich (mandantenunabhängig) muss die 13. Stelle der Benutzergruppe ein ‚G‘ stehen (Leerzeichen!))
• D_SREPOVARI-EXTDREPOR
  Name der Query.

Gerade der Parameter für die Benutzergruppe ist dabei umständlich, daher erscheint folgende Parametertransaktion sinnvoll.

Hier nutzen wir die Möglichkeit einer Parametertransaktion entweder für die Transaktion REISSQMAIN oder wir legen eine Reporttransaktion zum Report SAP_QUERY_CALL mit Selektionsbild 1000 an.

Bei der anzulegenden Parametertransaktion ist es wichtig, die Markierung bei "Einstiegsbild überspringen" zu setzen und im Abschnitt Vorschlagswerte folgende Werte einzutragen:

 

Parameter zu SAP_QUERY_CALL oder REISSQMAIN

Name des Dynprofeldes	Wert
P_WSID	Arbeitsbereich leer lassen oder G für Globaler Bereich
P_UGROUP	Benutzergruppe Die Benutzergruppe in der die Query ist
P_QUERY	Query Name der Query
P_VARI	Selektionsvariante ggf. angelegte Variante zur Query

Nachdem diese Transaktion gesichert ist, kann die Query künfitg auch problemlos über diese Transaktion gestartet werden.

Diese Variante ist auch im SAP Hinweis 2185998 - Anlegen eines Transaktionscodes für eine Query in 2021 beschrieben worden. Bis dahin wurde, bspw. durch die Anlage eines Transaktionscodes über die Rollenpflege (Einfügen einer SAP Query im Rollenmenü) eine Reporttransaktion angelegt.

Ableitung der Parameter aus der Parametertransaktion

Andrea Olivieri hat jedoch in einem Beitrag innerhalb der SAP Community ein ABAP veröffentlicht, durch das die gewünschte Massengenerierung ermöglicht wird. Persönlich habe ich dieses noch nicht ausprobiert, aber ggf. kann damit ihre SAP Basisabteilungen Ihnen eine passende Möglichkeit zur Verfügung stellen.

Der Beitrag "Upgrade – Easy migration of AQ* Report transactions" ist zusammen mit dem Coding auf der Seite https://blogs.sap.com/2015/02/24/upgrade-easy-migration-of-aq-report-transactions/ veröffentlicht worden.

Durch den Funktionsbaustein RSAQ_DECODE_REPORT_NAME werden die notwendigen Parameter aus den Report ermittelt.

• WORKSPACE/ Arbeitsbereich
• USERGROUP / Benutzergruppe
• QUERY / Query
• und CLIENT

Die einzelnen Programme können durch Selektion nach Programm AQ* in der Tabelle TSTC "SAP Transaktions-Codes" ermittelt werden.

Das oben erwähnte Programm liest scheinbar die entsprechenden Transaktionen aus und passt diese dann von einer Reporttransaktion auf eine Parametertransaktion für REISSQMAIN an.

Gerade bei einer Vielzahl von kundeneigener Transaktionen zu SAP Query ist dies sicher eine elegante Methoide.

Anmerkung: Ich habe selbst das Programm nicht getestet würde mich aber über eine positive Rückmeldung ob es weiterhin funktioniert freuen.

Manuelles Umstellen der Reporttransaktion auf Parametertransaktion

Sofern die Umstellung manuell erfolgen soll kann auch die Tabelle TSTC über das Feld Programm nach AQ* durchsucht werden. Damit sind alle kundeneigene Transaktionen die entsprechend der ersten Tabelle im Artikel Query starten identifiziert (AQZZ für globalen Arbeitsbereich und AQCS für Standardbereich).

Danach können die Transaktionen in der SE93 bearbeitet werden.

Im Artikel "Transaktionsart in SE93 ändern" bin ich auch darauf eingegangen, wie die Art der Transaktion geändert werden kann und so nicht erst ein Löschen und danach eine Neuanlage der Transaktion mit entsprechenden Workbenchaufträgen erfolgen müssen.

Keine Anpassung der Berechtigungsrollen erforderlich

Die Berechtigungsprüfungen, siehe Artikel "SAP Query als kundeneigene Transaktion mit Berechtigungen für Tabellenberechtigungsgruppe, Tabellen und Reporttransaktion vergeben"  für die Tabellen sind dabei weiterhin zu beachten. Ebenso ist hier die Berechtigungsprüfung beim Lesen von Tabellen, sofern es sich nicht um logische Datenbanken handelt, zu beachten, dass bspw. Berechtigungen auf CO_Objekte wie Kostenstellen oder Innenaufträge nicht beachtet werden. Dennoch sind Query auch weiterhin eine gute Möglichkeit der Auswertung im Berichtswesen, zumindest, wenn ohnehin zentral Auswertungen erfolgen.

Bei der Anlage eines Transaktionscodes wird ein Workbench-Transportauftrag angelegt, sodass die Einträge der Tablle TSTC entsprechend in die weiteren Systeme transportiert werden. Über die SE10 kann dieser Transportauftrag frei gegeben bzw. transportiert werden. Sofern beim Speichern oder Anlage einer Transaktion keine Abfrage eines Transportauftrages kommt, kann es sein, dass hier noch ein Transportauftrag offen ist.

Ist ein entsprechender Eintrag vorhanden, sollte dieser dann freigegeben und transportiert werden. Andernfalls werden Änderungen oder neue Transaktionen im bestehenden offenen Transportauftrag des Users gespeichert.

Für die Änderung bestehender Transaktionscodes sind diese mit der SE93 zu löschen und danach statt als Reporttransaktion als Parametertransaktion anzulegen. Immerhin bestehende Berechtigungen, insbesondere im Berechtigunsobjekt S_TCODE zum Aufruf der Transaktion bleiben bestehen :-).

Ich freue mich immer über Anfragen über das Blog und auch darüber, dass manche Artikel hier auch anderen weiter helfen können.

---

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.

---

Im Artikel "Berichtsdokumentation in Excel - Hyperlink auf Tabellenblätter indirekt setzen" hatte ich vor einiger Zeit schon einmal erwähnt, dass es sinnvoll sein kann, bestehende Berichte umfassend zu dokumentieren.

Eine besondere Bedeutung kann dies Thema bei der Frage welcher Ansatz bspw. beim Wechsel von ERP nach S/4HANA genutzt werden kann und welche Berichte künftig hier als Thema gesetzt werden.  Dies dürfte auch im Artikel "Bisherige Erkennntnisse rund um SAP S/4HANA und FIORI aus Sicht Rechnungswesen CO und FI" absehbar sein oder auch als Frage beim Online-Training zur Datenmigration nach S/4HANA (siehe Artikel "Mein Online-Training »Einführung SAP S/4HANA Datenmigration mit Migrationscockpit und Migrationsobjektmodellierer« (Andreas Unkelbach)" oder "Live-Session zum Online-Training Datenmigration nach S/4HANA mit Migrationscockpit und Migrationsobjektmodellierer") bedeutend werden.

Der damaligen Anforderung eine Übersicht einiger selbst entwickelter Berichte zu erstellen, bin ich dann aber tatsächlich wesentlich lieber über das Lieblingstool im Controlling nachgegangen und habe eine Arbeitsmappe in Excel für diese Herausforderung angelegt und den Aufbau einer solchen Report-Matrix ausführlicher erläutert.

Sofern bei Ihnen ebenfalls eine solche Report-Matrix ansteht oder ein Überblick über bestehende kundeneigene Berichte im SAP Umfeld erstellt werden sollen, kann hier für das lokale Berichtswesen im SAP eine Übersicht über eigene Berichte erstellt werden.



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.
 
Hier soll nun aber eine Auswertung über vorhandene Berichte im Bereich Report Painter / Report Writer, Rechercheberichte und SAP Query sowie kundeneigene Transaktionen erstellt werden.
 

Übersicht Report Painter / Report Writer Berichte

Innerhalb des SAP Menü gibt es zwei Berichte unter:

• Infosysteme
• Ad-hoc-Berichte
• Report Painter
• Hilfsmittel
• Verzeichnis
  • Berichtsgruppen (Transaktionscode GR5L)
  • Berichte (Transaktionscode GR3L)

Die Berichtsgruppen können über verschiedene Auswahlkriterien ausgewertet werden (Tabelle, Bibliothek,  oder auch Berichtsgruppe Z* sofern diese im Z* Namensraum angelegt worden sind.
Die Berichte können anhand der Berichtsbezeichnung, aber auch der Bibliothek ausgewertet werden sowie weitere Angeben wie Anlagedaten oder Änderungsdaten.

Gerade der Bericht GR3L hat zusätzlich den Vorteil, dass in der Spalte Ursprung eine Unterscheidung zwischen Report Painter Berichte (P) und Report Writer () dargestellt.

Leider sind die Berichte so aufgebaut, dass keine Zuordnung der Berichte und der Berichtsgruppen über diese beiden Berichte möglich ist.

Das Verzeichnis der Berichte (Transaktion GR3L) umfasst:
Bibliothek, Bericht, Beschreibung, Tabelle, Geänder von, Änderungsdatum, Angelegt von, Datum und Ursprung (P Report Painter sonst Report Writer)

Das Verzeichnis der Berichtsgruppen (Transaktion GR5L) umfasst:
Berichtsgruppe, Beschreibung, Tabelle, Bibliothek, Anzahl Selektionen, Geändert von, Änderungsdatum


Für eine Auswertung von Berichtsgruppe und darin enthaltene Berichte habe ich folgende SAP Query erstellt:

Infoset (Transaktion SQ02):

Tabellenjoin über T803J (Report Writer: Berichtsgruppen)  und T803L (Report Writer: Einträge in Berichtsgruppen). Wichtig ist dabei das Feld RGJNR Berichtsgruppe per left outer join zu verknüpfen.

Dieses Infoset ist einer passenden Benutzergruppe zugeordnet worden.

Query (Transaktion SQ01):

Die Query hat dann in der Grundliste folgenden Aufbau (L= Listenfeld, S = Selektionsfeld):

Report Writer: Berichtsgruppe - Tabelle T803J
Bibliothek (T803J-LIB) L
Berichtsgruppe (T803J-RGJNR) L, S

Zusatzfelder:
Text:Berichtsgruppe (TEXT_T803J_RGJNR ) L

Report Writer: Einträge in Berichtsgruppe - Tabelle T803L
Bericht (T803L-RNAME) L

Zusatzfelder:
Text:Bericht (TEXT_T803L_RNAME) L


Report Writer: Berichtsgruppe - Tabelle T803J
Datum der letzten Generierung (T803J-GEN_DATE) L
Autor - anlegender  Benutzer (T803J-CR_USER) L
Datum der Neuanlage (T803J-CR_DATE) L
Letzter Änderer (T803J-UPD_USER) L

Für SAP Query selbst wird im folgenden Abschnitt noch ein Handbuch zu SAP Query zur Einführung von SAP Query verlinkt.

Clusterung der Berichte:
Durch die Auswertung der Berichte unter Report Writer / Report Painter kann mit der Angabe Bibliothek - Berichtsgruppe - Bericht auch gleichzeitig eine Clusterung vorgenommen werden. Als Gruppierungsmerkmal sind die Berichtsgruppen für Report Painter und Report Writer vorgesehen, sodass hier über die Berichtsgruppen innerhalb der Bibliothek mehrere Berichte schon zusammengefasst worden sind.

Auch dieser Gesichtspunkt ist für ein strategisches Berichtswesen im SAP Umfeld durchaus relevant.

 

Weitere Informationen zum Thema Report Painter:
Unkelbach, Andreas: »Grundlagen Kurzeinführung und Handbuch Report Painter Report Writer« in Andreas Unkelbach Blog (ISSN: 2701-6242) vom 10.11.2015, Online-Publikation: https://www.andreas-unkelbach.de/blog/?go=show&id=658

 

Übersicht SAP Query

Für eine Dokumentation der SAP Query ist zwischen Globalen und mandantenabhängigen Bereich zu unterscheiden. Hier ist es sinnvoll in der Pflege der Infoset (Transaktionscode SQ02) über (Mehr) > Umfeld > Arbeitsbereich diesen sowohl Standardbereich (mandantenabhängig) als auch Globaler Bereich (mandantenunabhängig) zu betrachten.

In beiden Bereichen kann dann über das Infoset per Menü (Mehr) > Springen > Queryverzeichns (UMSCH+F8) ein Verzeichnis von Queries über Benutzergruppen oder Infosets aufgerufen werden. Dabei ist die Box Globaler Bereich je nach oben gesetzten Punkt schon markiert oder demarkiert.

Alternativ kann auch das Query-Verzeichnis über den ABAP Report (SA38) RSAQDEL0  aufgerufen werden. Hier ist dann die Option Globaler Bereich als Merkmal markierbar oder nicht.

Die Liste bietet dann folgenden Felder die entsprechend in der Liste ausgeblendet oder eingeblendet werden können:

• Infoset
• Benutzergruppe
• Query
• Query Eigenschaften (Titel)
• Autor
• Anlagedatum
• Änderer
• Änderungsdatum
• ...

Damit sind sowohl im Standardbereich als auch Globalen Bereich alle Query und Infoset aufgelistet.

 

Weitere Informationen zum Thema SAP Query:
Unkelbach, Andreas: »Grundlagen Kurzeinführung und Handbuch SAP Query « in Andreas Unkelbach Blog (ISSN: 2701-6242) vom 28.11.2014, Online-Publikation: https://www.andreas-unkelbach.de/blog/?go=show&id=575

 

Übersicht Rechercheberichte

Ein Verzeichnis der Rechercheberichte (FI, CO, PSM-FM) ist mir leider nicht bekannt, daher führe ich hier den Pfad im jeweiligen Customizing (Transaktion SPRO) auf über den diese Berichte gepflegt und die Formulare und Berichte entsprechend festgehalten werden können.

• Public Sector Management
  • Public-Sector-Management
  • Haushaltsmanagement Öffentliche Verwaltung
  • Informationssystem
  • Recherche-Berichte
  • Formular
    (hier die Funktionen Formular anlegen, ändern, anzeigen)
  • Bericht
    (hier die Funktionen Bericht anlegen, ändern, anzeigen)
• Profitcenterrechnung (EC-PCA)
  • Profit-Center-Rechnung
  • Informationssystem
  • Recherche
    • Formular pflegen
    • Bericht pflegen
• Bilanzreporting (siehe Artikel "Rechercheberichte im Modul FI (Bilanzanalyse)")
  • Finanzwesen
  • Hauptbuchhaltung
  • Informationssysteme
  • Rechercheberichte (Sachkonten)
  • Formular
    • Formular festlegen
  • Bericht
    • Bericht festlegen

Im Artikel "Grundlagen: Was sind die Unterschiede zwischen Report Painter und Rechercheberichte?" bin ich ausführlicher auf die einzelnen Pflegetransaktionen zum Recherchebericht eingegangen und verweise hier insbesondere auch auf die Unterscheide zwischen klassischen Hauptbuch und neuen Hauptbuch (NewGL).

Übersicht kundeneigener Transaktionen

Zu einigen Berichten, sei es Query, Recherche oder Report Painter sind auch entsprechende kundeneigene Transaktionen im Y* oder Z* Namensraum angelegt worden. Diese können entweder per PFCG im Menü angelegt worden sein oder direkt in der Transaktion SE93.

Hier ist die Vorgehensweise im Artikel "Transaktion anlegen (Report, Parameter) bspw. für SAP Query / Unterschied Parameter- oder Reporttransaktion" beschrieben worden.

Neben der Ansicht in der Transaktion SE93 lassen sich diese Transaktionen auch in der Tabelle TSTC auslesen. Im Artikel "Tabellen hinter Transaktionscode oder ABAP Programm über eine SAP Query ermitteln" sind die Tabellen festgehalten worden.

Stammdatengruppen (SETS)

Neben bestehenden Berichten sind auch die Objekte über die berichtet werden relevant. Neben der Standardhierarchie sind hier auch passende SETS und Gruppen zu berücksichtigen. Im Artikel "Auflösen von Stammdatengruppen nach Einzelwerten - Einzelwerte zu Sets" ist eine Auswertung bestehender Gruppen beschrieben, so dass hier schnell eine Dokumentation bestehender Sets oder alternativer Hierarchien für einzelne Business Objekte erfolgen können.
 

ABAP Reports

Persönlich nutze ich obere Berichte im Berichtswesen und Controlling mit SAP nicht nur im Bereich von Hochschulen. Eine größere Flexibilität sind natürlich durch Entwicklungen von ABAP Programmen oder anderen Reports möglich, diese erfordern aber entsprechenden Entwicklerschlüssel und natürlich Kenntnisse in der Programmierung.

Um aber auch auf das Thema Eigenentwicklungen (ABAP Reports etc.) einzugehen verweise ich auf die Tabelle TADIR - Katalog der Repository-Objekte  ausgelesen werden. Hier kann als Objekttyp (Feld OBJECT) PROG für Programm genutzt werden und alle kundeneigene Programme ausgewertet werden.

Dies betrifft dann aber eher Entwicklungen und persönlich würde ich hier eher mit der SE80 innerhalb entsprechender Pakete nach Entwicklungen suchen.

An dieser Stelle auch ein Hinweis auf rz10.de "Identifizieren von Kundenentwicklungen in SAP".

 

Detailinformationen

Sofern Sie nicht neben ihren Ordner zum Berechtigungskonzept auch gleich ein Berichtshandbuch über ihre eigenen Berichte vorliegen haben ist dieses vielleicht auch ein guter Zeitpunkt sich um die Detaildokumentation der vorhandenen Berichte zu kümmern.

Wenn es um eine ausführlichere Dokumentation der Daten angeht finden sich in den Artikeln "Dokumentation von Berichtsgruppe und Berichtsdokumentation bei Report Painter und Writer Berichten", "Fachliche und technische Dokumentation von Selektionsvarianten und individuelle Berichte in SAP identifizieren" noch weitere Informationen wie bspw. die technischen Details unter "Report Painter Übersicht von Elementen und Merkmale zur Darstellung der Struktur und Aufbau eines Berichtes".

Ich hoffe, dass diese Kurzanleitung die Erfassung bestehender Berichte erleichtert hat und Sie sich einen schnellen Überblick der in den einzelnen Modulen genutzten Berichte verschaffen konnten.

Ich benutze ja selbst mein Blog immer einmal wieder als Wissenspool und freue mich auch darüber mich rund um SAP mit anderen Menschen austauschen zu können. Daher sind kurze Mailanfragen auch oft eine gute Grundlage für neue Blogartikel und eine Möglichkeit selbst ein wenig zu lernen.

Manchmal sind aber solche Fragen auch relativ schnell beantwortet, so dass ich hier keinen großen Artikel sondern nur die Antwort hinterlegen mag für den Fall, dass die Frage mal wieder auftaucht.

Währungsumrechnung innerhalb eines Repot Painter Berichtes.
Ist es möglich einzustellen, dass die ausgewiesenen Kosten anstatt EUR in USD ausgewiesen werden?

Für jeden Report Painter Bericht gibt es am Selektionsbild die Schaltfläche "Währungsumrechnung (UMSCH + F9)" über die Zielwährung, Kurdatum und Kurstyp ausgewählt werden können.  Je nach Bericht kann diese Währungsumrechnung auch nur für bestimmte Kennzahlen des Berichtes erfolgen.

Bei der Konzeption von eigenen Berichten sollte die Formatgruppe dahingehend abgeändert werden, dass unter

• (Mehr) Formatierung
• Spalten

in der Formatgruppe beim Abschnitt Zahlenformat die Option "Einhei einblenden" aktiviert werden (siehe auch "Formatierung Report Writer Berichte" oder "Vorzeichenumkehr bei Ertrag und Aufwand im SAP Berichtswesen am Beispiel Recherchebericht und Report Painter").


Für einen Bericht soll ein weiterer Zeilenblock von Kostenarten eingebaut werden, der mit Strichen von den anderen Kostenblöcken getrennt ist.

In der Transaktion GRR2 kann unter

• (Mehr) Formatierung
• Zeile

für die markierte Zeile  nicht nur das Vorzeichen angepasst werden sondern auch.

• Über-/Unterstreichung
  • Überstreichung (Linie oberhalb der Zeile)
  • Unterstreichung (Linie unterhalb der Zeile)

aktiviert werden.  So kann ein Kostenblock tatsächlich als Block formatiert werden.

Ferner kann auch unter Farbeinstellung die Hintergrundfarbe für eine Zeile mit folgenden Optionen angepasst werden:

• Farbe für Hervorhebung
• Farbe für Zwischensummen
• Farbe für eingeschobene Zeilen
• Farbe für Summen
• Keine Farbverwendung

Dabei ist darauf zu achten, dass hier das Template bei der Office Integration diese Farben per VBA festlegt. Dieses bedeutet, dass die Farbtabelle von der normalen Excel Ansicht abweicht. Eine Lösung wie die Farben auch in einer anderen Arbeitsmappe erhalten bleibt ist im Artikel "Office Integration - Excelansicht in SAP und Daten kopieren nach Excel" erläutert.

Ich würde gerne eine Auswertung erstellen, die mir anzeigt, wie viel Geld an einen bestimmten Kreditor geflossen ist.  Mit der Kreditoren-Einzelpostenliste oder einem Versuch in Query mehrere Tabellen zusammen zu legen, bin ich gescheitert.

Bei der Auswertung der Kreditoren-Einzelpostenliste (S_ALR_87012103) ist vermutlich ein Filter auf die Belegart ZP = Zahlposition  zu setzen, da sich sonst die Einzelpositionen gegenseitig saldieren.  Allerdings erhalten Sie damit lediglich alle Buchungen die direkt auf das Kreditorenkonto gebucht worden sind. Sofern es sich um eine Zahlung auf ein  CpD (Conto pro Diverse)  erfolgte kann tatsächlich eine Query hilfreich sien. Im Rahmen der  "Verordnung über die Mitteilung von Zahlungen an die Finanzbehörden" (Mitteilungsverordnung gem § 93a AO) kann hier eine Auswertung über die Profit-Center-Rechnung per Query erfolgen.

Im Artikel "Auswertung Kreditoren Einzelposten inklusive CO Objekte wie Kostenstelle oder Innenauftrag" ist dieses für die klassischen Profitcenterrechnung ohne neues Hauptbuch beschrieben. Für das neue Hauptbuch habe ich diese Auswertung noch nicht getestet. Eine Alternative wäre eine Auswertung über die logische Datenbank BRF.

Dieses ist im Artikel "Query FI Einzelposten als Belegjournal - Belegsegment (BSEG) und Belegkopf (BKPF) verknüpfen" erläutert.

Wie kann ich in einen Report Painter Bericht in einer Formel Bezug auf eine Kombination aus Zeile und Spalte nehmen?

Diese "spezielle Zelldefinition" als Z Feld (X = Spalten, Y = Zeilen)  kann durch einen Doppelklick auf die Zelle erreicht werden. Neben dieser Zelle erscheint dann ein Zeichen "✔". Hierdurch wird eine "spezielle Zelldefinition" vorgenommen. Damit steht die Zelle als Formelbestandteil direkt zur Verfügung.

Im Artikel "Redesign Report Painter Berichte im Rahmen der Hochschulfinanzstatistik hier: Merkmal sowohl in Spalte als auch Zeile ausweisen" ist dieses näher beschrieben.

Wie kann ich meine Spalten und Zeilen in einen neuen Abschnitt kopieren ohne diese erneut anlegen zu müssen?

Da einige Kolleg:innen derzeit mit Report Painter neue Berichte erstellen verweise ich hier gerne auf meinen Artikel "Spalten oder Zeilen in Report Painter Berichten innerhalb Abschnitte kopieren bzw. als Vorlage anlegen Copy & Paste im CO Berichtswesen".

Da in letzter Zeit doch einige Fragen rund um Report Painter, Report Writer gestellt worden sind, verweise ich auch gerne auf unteren Hinweis zu einer Einführung rund um Report Painter.

Wie kann ich Professur, Projektverantwortliche, ... und andere Stammdaten in einen Report Painter Bericht mit ausgeben?

Unter

• (Mehr) Zusätze
• Berichtstexte

in der Transaktion GRR2 können für

1. Titelseite
2. Kopfzeilen
3. Fußzeilen
4. Ende_Seite
5. und Text für Export

weitere Informationen zum Bericht erhoben werden. Letztere Option habe ich im Artikel "Kopfzeilen im Report Painter auch bei Export nach Excel verwenden" näher beschrieben.

Im Artikel "CO Objekte indirekt auswerten Teil 1/2 hier: Anhand Kostenstelle im Report Writer zugeordnete CO Objekte Innenauftrag und Kostenstelle" bin ich darauf eingegangen, dass hier auch mit Variablen zu den Stammdatenobjekten verfahren werden kann.

Nach Aufruf der Textpflege (Kopfzeile oder auch Text für Export) kann über die Schaltfläche Merkmale das Merkmal Kostenstelle gewählt werden und als Textart WERT und als Wertart WERT/GRUPPE verwendet werden. Hierdurch wird entweder der Kostenstellengruppenname oder die selektierte Kostenstelle als Schlüssel (sprich die Kostenstellennummer) ausgegeben. Ergänzend bietet es sich direkt an als weiteres Merkmal ebenfalls die Kostenstelle zu nehmen nun aber als Textart KURZTEXT und Wertart WERT/GRUPPE zu verwenden, so dass auch die Bezeichnung der Kostenstellengruppe beziehungsweise der Kostenstelle mit ausgegeben wird.

Über die Schaltfläche Spez. Var...  können ferner noch Spezielle Textvariablen Stammdatenattribute als Textelement eingefügt werden. Damit ist es möglich zu einer selektierten Kostenstelle über die Stammdatentabelle KOSTENSTELLENSTAMMSATZ das Stammdatenattribut VERANTWORTLICHER als Textart WERT mit einzufügen. Dieses gilt natürlich auch für weitere Stammdatenfelder wie Abteilung oder andere hinterlegte Felder inklusive der per Userexit CMOD (COOMKS01) hinzugekommene kundeneigene Zusatzfelder, die ja auch schon im Artikel "Auswertung per CMOD eingeführter kundeneigener Felder Kostenart, Kostenstelle und Innenauftrag per Stammdatenverzeichnis und SAP Query" ein Thema waren.

Wird statt einer Kostenstelle ein Innenauftrag ausgewertet kann ier aus der Stammdatentabelle Controlling-Auftragsstammdaten auch Felder wie  Arbeitsbeginn, Arbeitsende oder Verantwortlicher und andere Stammdaten hinterlegt werden. Zumindest bei EInzelauswertungen ist dieses eine praktische Anzeige :-).

Sollen jedoch Bewegungsdaten und Stammdaten in einer Liste kombiniert ausgewertet werden kann dieses per Query (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") oder als Ergänzung zum Summenbericht (siehe Verweise unter "Grundlagen Rechercheberichte Ausgabeart grafische Berichtsausgabe oder klassische Recherche" und "Drittmittelstatistik nach LOMZ über Recherchebericht und SAP Query" erfolgen.

Im Rahmen einer SAP S/4HANA Einführung kam die Frage auf, obReport Painter unter S/4HANA noch aktuell ist oder Berichte nur noch als FIORI Anwendungen bzw. Universal Journal aufgebaut werden können.
Sofern noch nicht alle Berichte auf FIORI umgestellt worden sind steltl sich die Frage, ob weiterhin Report Painter Berichte erstellt werden können. Martin Munzel berichtete im FICO-Forum (siehe Beitrag "Berichte mit Report Painter in SAP S/4HANA auf Basis von ACDOCT") über die Aufgabe "einen Bericht für eine GuV in UKV (also mit Profitcentern und Funktionsbereichen) im Universal Journal in Report Painter" zu erstellen. Denkbar wäre hier unter ERP die Verwendung der Berichtsbibliothek 8A2 bzw. der Berichtstabelle GLPCT (siehe Beitrag "Erweiterung Bibliothek 8A2 Ausweis Kostenstelle und Innenauftrag bei Selektion Profit-Center in ReportWriter") jedoch gehört diese Tabelle zu EC-PCA und wird im Universal Journal nicht mehr verwendet.

Allerdings kann eine Berichtsbibliothek auf der Tabelle ACDOCT - die Summentabelle zum Universal Journal aufgebaut werden. Diese liefert alle Daten der ACDOCA (Ist Buchungen). Mit SAP Hinweis "2476144 - ACDOCP in Berichtstabelle ACDOCT verfügbar" st die Tabelle ACDOCP für Reporting-Zwecke in der Berichtstabelle ACDOCT zur Verfügung gestellt worden. Somit können kundeneigene Report-Painter-/Writer-Berichte (Plan/Ist-Vergleiche) zur Berichtstabelle ACDOCT definiert werden.

Stammdaten im Controlling insbesondere der klassischen Profitcenter Rechnung
In welcher Tabelle können inaktive Profitcenter-Stammdaten ausgewertet werden.

Neben einer reinen Stammdatenauswertung, wie im Artikel "Query Stammdatenvergleich Profit-Center und Auslesen von Textbestandteilen (Teilstring aus Variable)" oder der Auswertung von Änderungen in Stammdaten, wie im Artikel "Änderungsbelege zu CDHDR und CDPOST für SAP Objekte wie Stammdaten im Rechnungswesen (Report/Transaktionscode RSSCD100)".

Neben den bekannten Tabelle CEPC "PRofitcenter-Stammdatentabelle" und CEPCT "Profitcenter-Stammdaten Texte" werden inaktive (Profitcenter-) Stammdaten in Tabellen beginnend mit CMDT* gespeichert und können darüber ausgewertet werden.

Wie kann ich mich in Report Painter und Report Writer einarbeiten?

Derzeit arbeite ich ein wenig meine Internetseiten rund um Buchempfehlung und SAP Know How um. Erfreulicherweise kann ich hier auch ein Buch zum Thema Report Painter empfehlen.

  (07. Juni 2019)
Für 29,95 € bestellen


Oder als SAP Bibliothek-Flatrate *




Woher stammen diese Fragen?

Neben direkten Fragen von Kolleg:innen gibt es auch per Mail (oder Kommentar im Blog/Social Media) einen regen Austausch rund um SAP und andere Themen. Heute möchte ich ein paar dieser Fragen aufgreifen und hoffe, dass diese auch anderen helfen werden. Ebenso können oft auch Fragen aus Forenbeiträgen aufgerufen werden.

Je nach Thema wird es aber auch weiterhin noch ausführlichere Artikel hier im Blog geben :-).


 

---

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 Artikel aus 2012 "SAP Query: Einzelpostenliste KAMV für Umbuchung in Planversion"  habe ich eine Query entworfen, die über den betriebswirtschaftlichen Vorgang KAMV "Manuelle Kostenverrechnung" und KZPI "Zuschläge periodisch Ist" für die Gemeinkostenzuschlagsrechnung eine umfangreiche Datenauswertung erstellt, die ich über ein Infoset und Grundliste einer Query erstellt habe.

 

Rückblick

Ausgangslage:

Bei der Kopie der Istdaten in eine Plankopie werden alle CO Belege mit Vorgang KAMV (Manuelle Kostenverrechnung) nicht mit in die Planversion kopiert. Diese manuellen Kostenverrechnungen (Transaktion KB15N zum Erfassen bzw. KB17N zur Stronierung) müssen entsprechend in der Planversion nacherfasst werden. Über die Transaktion KB16N können entsprechende Belege angezeigt werden. Typische Geschäftsvorfälle sind hier bspw. die interne Leistungsverrechnung wie Porto, Kopierkosten oder auch Servicestunden.

Ein vergleichbares Problem tritt bei der Gemeinkostenzuschlagsverrechnung (betriebswirtschaftlicher vorgang KZPI auf wo diese Buchungen ebenfalls nachgebucht werden müssen im Plan.

In der Tabelle COEP sind diese Buchungen über den Vorgang KAMV selektierbar, allerdings ist hierbei darauf zu achten, dass die Buchungen sowohl mit positiven als auch negativen Vorzeichen gespeichert sind. Je nachdem müssen die Sender und Empfänger entsprechend belastet bzw. entlastet werden.

Zielvorgabe:
Abhängig vom Wert soll bei positiven Werten (Aufwandsbuchung) die Objektnummer als Empfänger (NEU) und das Partnerobjekt als Sender (ALT) ausgegeben werden.  Bei negativen Werten sollen Sender / Empfänger entsprechend vertauscht werden. Der Wert soll in jeden Fall mit positiven Kennzeichen ausgegeben werden. Ferner ist darauf zu achten, dass Kostenarten des Typs 42 (Umlage) durch solche des Typs 41 (Gemeinkostenzuschläge) ersetzt werden sollen. Entsprechend sollte auch die Kostenartenbezeichnung und der Kostenartentyp mit ausgegeben werden.
 

Anhand von kundeneigener lokaler Felder innerhalb der SAP Query (Transaktion SQ01) habe ich nun je nach Wert die Objektnummer (OBJEKT) oder das Partnerobjekt (PARTNER) zugewiesen.

Damit habe ich nun also die technischen Bezeichnungen innerhalb der Query umgesetzt.

Der Aufbau des Infoset und der Query ist in obigen Artikel beschrieben.

Nun soll jedoch die Weterverabrietung der Query über KAMV nicht in Access sondern direkt innerhalb der Query erfolgen.

Im Ergebnis soll eine Liste aus folgenden Feldern entstehen (als Sender und Empfängerbeziehungen aus den Objekten aus Z_ALT , Z_NEU und Z_WERT.

Zur Erinnerung Z_WERT, Z_ALT, Z_NEU

Lokales Feld Z_WERT

Der Wert bezieht sich auf das Feld "Wert gesamt in Kostenrechnungskreiswährung"( COEP-WKGBTR ) welches der Kurzbezeichnung WERTK zugeordnet worden ist.

Hintergrund zu den einzelnen Währungsfeldern ist im Artikel "Query Einzelpostenliste Innenauftrag mit Ausweis Ertrag und Aufwand Zweiter Teil Query zur Datenaufbereitung"

festgehalten.

Exkurs: Unterschiedliche Währungen im Controlling

Alternativ hätte die Kurzbezeichnung WERT auch den Feldern "Wert gesamt in Objektwährung" oder "Wert gesamt in Kostenrechnungskreiswährung" zugeordnet werden können. Sofern alle Werte in Euro geführt werden dürfte dieses identisch sein.

Allerdings kann im Controlling, besonders bei internationalen Konzernen unterschiedliche Währungen geführt werden.

Beim Festlegen eines Kostenrechnungskreis wird im Customizing auch gleichzeitig eine Kostenrechnungskreiswährung festgelegt. Dem Kostenrechnungskreis können unterschiedliche Buchungskreise zugeordnet werden, die zwar eine eigene Buchungskreiswährung  (bspw. US Doller USD oder Schweizer Franken SFR) haben aus denen aber die Kostenrechnung die gemeinsame Konzernwährung Euro ableitet, so dass innerhalb des Kostenrechnungskreis eine einheitliche Konzernwährung geführt wird.

Die Transaktionswährung weist dafür die Währung aus, in der die Belege im Controlling tatsächlich gebucht sind.

Daneben können zu einzelnen CO-Objekten, so auch Kostenstelle  oder Innenauftrag ebenfalls eigene Währungen definiert werden (bspw. in der Kostenstelle im Feld Währung in der Registerkarte Grunddaten). In der Regel wird hier aber dem CO-Objekt die Währung als Vorschlagswert beim Anlagen vorgeschlagen und zugewiesen, die auch im Kostensrechnungskreis hinterlegt ist.

Zusammenhang T-Währung (COEP-WTGBTR), O-Währung (COEP-WOGBTR), K-Währung (COEP-WKGBTR)  und Währungsumstellung

Durch den Hinweis eines Kollegen bin ich darauf aufmerksam gemacht worden, dass bei einen Mehrmandantensystemen scheinbar nur das Feld "Wert gesamt in Kostenrechnungskreiswährung"( COEP-WKGBTR ) gefüllt ist und nicht die Felder Transaktionswährung ( COEP-WTGBTR) oder Objektwährung ( COEP-WOGBTR ). Entsprechend sinnvoll ist es daher tatsächlich die Kostenrechnungskreiswährung für diese Query zu verwenden. An welcher Stelle im Customizing dieses Verhalten ausgesteuert ist kann ich leider noch nicht sagen, aber die Artikel, welche die COEP im Rahmen einer Query auswerten, habe ich passend angepasst. Hintergrund ist hier vermutlich, dass einige Mandanten die Währungsumstellung von DM auf EUR mitgemacht haben und andere erst nach der Umstellung auf Euro angelegt worden sind. Dieses spricht dafür, dass die T-Währung und O-Währung nur dann gefüllt wird, wenn auch tatsächlich unterschiedliche Währungen im Systemn vorhanden waren und ansonsten wird nur das Feld  "Wert gesamt in Kostenrechnungskreiswährung" gefüllt, wobei diesse Währung auch identisch zur Buchungskreiswährung ist.

Die Berechnungsvorschrift zum lokalen Feld lautet:

• Bedingung:  WERTK < 0
  Formel:  -1 * WERTK
• Bedingung: WERTK > 0
  Formel: 1 * WERTK
• Sonst
  WERTK

Partner und Objekt als Grundlage Z_ALT und Z_NEU

Die folgenden Felder beziehen sich auf die Felder

Objektnummer  COEP-OBJNR
Kurzbezeichnung: OBJEKT
Partnerobjekt COEP-PAROB
Kurzbezeichnung: PARTNER

Lokales Feld Z_ALT

Hier sind die Eigenschaften identisch zum OBJEKT und folgende komplexe Berechnung hinterlegt:

• Bedingung:  WERTK > 0
  PARTNER
• Bedingung: WERTK < 0
  OBJEKT
• Sonst
  WERTK

Lokales Feld Z_NEU

Auch hier sind die gleichen Eigenschaften wie OBJEKT festgelegt, aber die komplexe Berechnung ist wie folgt definiert:

• Bedingung:  WERTK > 0
  OBJEKT
• Bedingung: WERTK < 0
  PARTNER
• Sonst
  WERTK

Damit habe ich nun im Ergebnis Sender (Z_ALT), Wert (Z_WERT) und Empfänger (Z_NEU)

festgelegt und den Buchwert immer positiv (und je nachdem ob der ursprüngliche Wert positiv oder negativ war WERTK < oder > 0 je Partner oder Objekt als Sender oder Empfänger definiert.
 

Ziel: Umbuchung Kostenstelle alt, Innenauftrag alt, Betrag, Kostenstelle Neu, Innenauftrag Neu

Allerdings mag ich in meiner Umbuchungsmaske nun folgende Felder füllen.

Als Vorlage für eine Umbuchungsliste benötige ich nun aber folgende Angaben:

1. Kostenstelle alt
2. Auftrag alt
3. KOSTENART
4. Kostenstelle neu
5. Auftrag neu

Zumindest die Einordnung ob es sich bei Sender / Empfänger um eine Kostenstelle oder Innenauftrag handelt ist schnell erledigt.

Die Objekte (Partner und Objekt) beginnen entweder mit K für Kostenstelle oder OR für Innenauftrag.

Entsprechend kann ich folgende Hilfsfelder anlegen in der Query:


Lokales Feld ZALT_ART
Textfeld (1 Zeichen)
Formel:
Z_ALT[1:1]
Damit wird das erste Zeichen des Feld  Z_ALT also K oder O gespeichert.


Lokales Feld ZNEU_ART
Textfeld (1 Zeichen)
Formel:
Z_NEU[1:1]
Damit wird das erste Zeichen des Feld  Z_NEU also K oder O gespeichert.


Nun lege ich vier weitere Felder an:

1. Lokales Feld ZKSALT
   Textfeld 10 Zeichen
   Bedingung:
   ZALT_ART = 'K'
   Formel:
   ZALT[7:16] * 1
2. Lokales Feld ZIAALT
   Textfeld 10 Zeichen
   Bedingung:
   ZALT_ART = 'O'
   Formel:
   ZALT[7:16] * 1
3. Lokales Feld ZKSNEU
   Textfeld 10 Zeichen
   Bedingung:
   ZNEU_ART = 'K'
   Formel:
   ZNEU[7:16] * 1
4. Lokales Feld ZIANEU
   Textfeld 10 Zeichen
   Bedingung:
   ZNEU_ART = 'O'
   Formel:
   ZNEU[7:16] * 1

Im Ergebnis habe ich nun also alle Sender und Empfänger Möglichkeiten festgehalten.

Allerdings gibt es nun noch die Notwendigkeit, dass die Kostenart zur Umbuchung geändert werden muss.

Hintergrund ist, dass nicht alle Kostenarten für die kundeneigene Planwertumbcuhung verwendet werden können, daher müssen Kostenarten vom Typ 42 (Umlage) duch entsprechende geeignete Kostenarten bspw. 41 (Gemeinkostenzuschläge)  ersetzt werden.


Dazu habe ich im Infoset ein Zusatzfeld angelegt.

Zusatzfeld ZCOKAMV
LIKE-Referenz   COEP-KSTAR

Zu diesem Feld habe ich nun folgendes Coding für unsere achtstellige Kostenarten ergänzt:

 

Coding zu Zusatzfeld ZCOKAMV

CLEAR ZCOKOMV.

* Damit wird der Wert erst einmal auf leer gesetzt.

ZCOKAMV = COEP-KSTAR.

* Nun wird die ursprüngliche Kostenart zugewiesen.

IF COEP-KSTAR CO '1234567890'.

* Damit nur nummerische Kostenarten geprüft werden.
* Das Feld COEP-KSTAR hat insgesamt 10 Stellen
* allerdings sind unsere Kostenarten achtstellig
* entsprechend sind die 00 vorne weg zu ignorieren.

* Für die Kostenarten beginnend mit 9399 sollen korrespondierende 9398
* Kostenarten ausgewählt werden.
* 9399 (Kostenartentyp 42 Umlage)
* 9398 (Kostenartentyp 41 Gemeinkostenzuschläge)

IF COEP-KSTAR BETWEEN '0093899999' AND '0094000000'.

CONCATENATE '9398' COEP-KSTAR+6(4) INTO ZCOKAMV.

* Hier wird der String 9398 mit den letzten 4 Ziffern der Kostenat verknüpft.

* Dies bedeutet aus Kostenart 93991234 wird 93981234

* Dank der IF Anweisung wird dieses auch nur für das Intervall
* zwischen 0093899999 und 0094000000 ausgeführt

* Daneben können noch weitere Kostenarten ausgestauscht werden.

ELSEIF COEP-KSTAR = '0059999990'. 
  ZCOKAMV =  59999980.

ENDIF.
ENDIF.
 

Dieses Zusatzfeld bekommt in der Query dann die Bezeichnung ZZKAMV.

Ein lokales Zusatzfeld, dass ich vorher für mehrere Berechnungsschritte über lokale Felder nutzte bekommt folgende Eigenschaften:

Z_KSTAR
gleiche Eigenschaften wie Feld KSTAR (entspricht Kostenart COEP-KSTAR)

Formel:
ZZKAMV

Fazit

Die fertige Query umfasst für die Umbuchung dann folgende Felder:

• ZKSALT
• ZIAALT
• Z_KSTAR
• Z_WERT
• ZKSNEU
• ZIANEU

Eben diese Liste kann dann zum Einbuchen per eCATT oder LSMW verwendet werden.

Als Buchungstext für die Umbuchung verwenden wir den Kurztext der ursprünglcihen Kostenart (CSKU-KTEXT).



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.
 
Das Thema SAP Query ist immer wieder als Berichtstool ein klein wenig unterschätzt, daher habe ich auch ein eigenes Kapitel im Buch gewidmet. Daneben gibt es aber auch hier im Blog immer einmal wieder einen aktuellen Artikel. Ebenso versuche ich in meinen Vorträgen Begeisterung für das Berichtstool SAP Query zu wecken.
 

---

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.

---

Im Rahmen eines Userexits (per CMOD) wurde eine Stammdatenerweiterung für Kostenstellen und Innenaufträge umgesetzt. Die Vorgehenswesie für eine solche Modifikation ist grundsätzlich auch im berater-wiki.de unter "Customer-Exits (Transaktionen CMOD und SMOD)" beschrieben.

Kundeneigene Zusatzfelder per Custumer-Exit (CMOD)

Konkret handelt es sich dabei um die Kundenerweiterungen:

• Kostenstellen:
  http://www.consolut.com/s/sap-ides-zugriff/d/e/doc/P-COOMKS01
• oder auch Innenaufträge:
  http://www.consolut.com/s/sap-ides-zugriff/d/e/doc/P-COOPA003

wie auch im Artikel "Stammdatenerweiterung von CO-Objekten am Beispiel ergänzende Kostenstelle beim Innenauftrag" beschrieben.

Zusatzfelder in Stammdatentabellen CI für AUFK und CSKS

Per Customer Include (CI) sind diese Felder dann auch direkt in der Stammdatentabelle CSKS (für Kostenstellen) und AUFK (für Innenaufträge) vorhanden.

Hier zitiere ich gerne die Tabelle aus meinen Artikel "Auswertung per CMOD eingeführter kundeneigener Felder Kostenart, Kostenstelle und Innenauftrag per Stammdatenverzeichnis und SAP Query":
 

Customer Include Stammdaten

CO Objekt	Stammdatentabelle	Struktur (Include)	Kurzbeschreibung
Kostenstelle	CSKS	CI_CSKS	Zusatzfelder Kostenstellen
Innenaufrag	AUFK	CI_AUFK	Zusatzfelder CO-Innenaufträge

Nun stellt sich aber die Frage, wie diese Stammdaten ausgewertet werden können. Natürlich ist dieses mit SE16H und anderen Tabellenanzeigentransaktionen über die Stammdatentabelle möglich, aber auch bei den normalen Stammdatenlisten können diese ausgewertet werden.

Zusatzfelder in Stammdaten Kostenstelle und Innenauftrag

Im Stammsatz der Kostenstelle sind die Zusatzfelder im Register "Zusatzfelder" (Transaktion KS01 bis KS03) einsehbar und pflegbar. Für die Innenauftärge sind diese ebenfalls im Reiter Zusatzfelder vorhanden, müssen jedoch vorher als Gruppenrahmen 09 kundeneigener Felder im Auftragslayout zur Auftragsart hinterlegt werden.

Die Pflege des Auftragslayouts für diesen Fall habe ich im Abschnitt "Zusatzfelder per Gruppenrahmen im Auftragslayout CO Innenauftrag aktivieren" im oberen Artikel beschrieben. Alternativ verweise ich hier auf die zweite Auflage unseres CO Buches :-).


  Paperback ISBN: 9783960120346

Für 29,95 € direkt bestellen

Oder als SAP Bibliothek-Flatrate *

oder bei Amazon (Print, eBook)
 

Stammdatenlisten KS13, KOK3 und KOK5 mit Zusatzfeldern

Praktisch stellt sich eine Auswertung nun in den Stammdatenlisten wie folgt dar.

Im SAP Menü unter

• Rechnungswesen
• Controlling

kann für Kostenstellen

• Kostenstellenrechnung
• Stammdaten
• Kostenstelle
• Sammelbearbeitung
• Anzeigen (Transaktion KS13)

und für Innenaufträge

• Innenaufträge
• Stammdaten
• Sammelbearbeitung
• Sammelanzeige
• Stammdaten (Transaktion KOK3)

eine ALV Liste über die CO Objekte aufgerufen werden.

Alternativ können die Stammdatenberichte auch über

• Rechnungswesen
• Controlling
• für Kostenstelle:
  • Kostenstellenrechnung
  • Inofsystem
  • Berichte zur Kostenstellenrechnung
  • Stammdatenverzeichnis
  • Kostenstelle: Stammdatenbericht (Transaktion KS13)
• für Innenauftrag:
  • Innenaufträge
  • Infosystem
  • Berichte zu Innenaufträgen
  • Stammdatenverzeichnis
  • Innenaufträge (Transaktion KOK5)

aufgerufen werden.


Sowohl bei der KS13 als auch der KOK5 sind entsprechende Selektionsvarianten zur Auswahl der Felder anzulegen.

In der Selektionsvariante KS13 ist hier im Report RKKSTSEL im Abschnitt Zusatzfelder die Schaltfläche Zusatzfelder auszuwählen und hier kann eine Selektion über die vorhandenen Zusatzfelder erfolgen.

In der Selektionsvariante KOK3, KOK5 ist die Auswahl der Zusatzfelder direkt über die Schaltfläche "Kundeneigene Felder" als Selektionskriterein Innenaufträge aufrufbar.

Das diese Transaktionen auch für das Berichtswesen als sich selbst aktualisierende interaktive Stammdatengruppe interessant sind habe ich auch schon im Artikel "Selektionsvariante KOK5 und Statusselektionsschemata zur Auswertung gesperrter Innenaufträge" erwähnt.

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.


 
Nachdem die Auswertung erfolgt ist, muss allerdings gegebenenfalls neben der Selektionsvariante auch die Layoutvariante angepasst werden. Im SAP Signature Design würde ich an deiser Stelle auf den Zauberwürfel verweisen, aber im Belize Theme ist dieses leider nur ein verschachtelte Quadrate die per STRG + F8 (Layout ändern bei KS13 bzw. Aktuelle Anzeigevariante bei KOK3,KOK5) angepasst werden kann.

Hier können dann auch die Zusatzfelder in die Liste aufgenommen werden.

Auswertung der Zusatzfelder per SAP Query (Transaktion ZKOK5)

Im Artikel "Query über COEP, AUFK und FMFINCODE für Einzelposten Istkosten Innnenauftrag mit Stammdaten aus CO und PSM-FM sowie Spalten für Ertrag und Aufwand - Erster Teil Infoset als Datengrundlage" habe ich schon eine Query bzw. die Datengrundlage einer Query beschrieben durch die es möglich ist nicht nur die Stammdaten der CO Innenaufträge sondern auch damit verbundene Objekte wie Profitcenter, Kostenstelle oder auch Fond auszuwerten.

Die Datengrundlage als Infoset entspricht folgender schematischen Darstellung:



Da nun die Query über eine kundeneigene Transaktion (siehe Artikel "Transaktion anlegen (Report, Parameter) bspw. für SAP Query / Unterschied Parameter- oder Reporttransaktion" aufgerufen wird sollen hier auch die Zusatzfelder sowohl als Listenfelder als auch Selektionsfelder berücksichtigt werden.

1. Anpassung Infoset

Innerhalb des Infosets (Transaktion SQ02) habe ich zwei neue Feldgruppen angelegt:

• Zusatzfelder CO Innenauftrag
• Zusatzfelder CO Kostenstelle

in beide können aus der Tabelle AUFK und CSKS die Zusatzfelder beginnend mit Z* in unseren Fall in die Feldgruppe als Datenfeld übernommen werden.

2. Anpassung Query

Innerhalb der Query (Transaktion SQ01) können die Zusatzfelder aus den Tabellen CSKS und AUFK als Listenfelder und Selektionsfelder in die Grundliste aufgenommen werden.

Dabei kann es sinnvoll sein für die einzelnen Felder die Kurzbezeichnung von identischen Feldern noch anzupassen. Sind sowoh für Kostenstelle als auch Innenauftrag ein Zusatzfeld Budgetverantwortliche angelegt kann es hilfreich sein, dieses Feld ebenso wie die Personalnummer um ein KS für Kostenstelle und IA für Innenauftrag zu ergänzen. Ferner ist es nptzlich beim aktiven Feld die Option "Feld nur ausgeben, wenn <>0" am Listenfeld zu aktivieren, da andernfalls der Initialwert (bspw. 00000000)

Sinnvollerweise sollte nachdem die Grundliste entsprechend angepasst worden ist auch das Selektionsbild der Query angepasst werden.

Durch Verlassen der Grundliste (per Zurück) kann über

• (Mehr)
• Springen
• Feldauswahl
• Selektion

Die Selektionsmaske für die einzelnen Felder angepasst werden.

Unter Nr wird die Position des Zusatzfeldes festgelegt und über Selktionstext können auch die Texte die beim Start der Query erscheinen angepasst werden. So habe ich hier hinter Budgetverantwortliche und Personalnummer noch ein CSKS bzw. AUFK ergänzt, so dass ersichtlich ist, dass es sich um die Stammdaten von Kostenstelle und Innenauftrag handelt.

Ferner ist die Nr so gewählt, dass die Felder direkt unter der Kostenstellennummer und Auftragsnummer angesiedelt sind.

An dieser Stelle zeigt sich der Vorteil, dass ich im Vorfeld den Abstand zwischen einzelnen Feldern in 5er Schritten gewählt habe, so dass ich die neuen Felder bspw. auf Position 6 und 7 (nach 5 der Auftragsnummer) und 12 und 13 (nach 11 der verantwortlichen Kostenstelle) wählen konnte.

Fazit

Insbesondere Anpassungen durch neue Zusatzfelder sind ein schönes Beispiel dafür, dass Berichtswesen immer auch ein Thema der Weiterentwicklung ist und daher hier auch Reserven für künftige Anforderungen frei gehalten werden sollte, daher ist gerade in der Software- oder Berichtsentwicklung bei einer durchgehenden Nummerierung es sinnvoll hier in größeren Schritten vorzugehen. In meinen Beispiel haben sich 5er Schritte schon mehrfach bewährt, wie sich an ebenso vorhandenen Nummern wie 7, 16 oder 23 zeigt :-)

Wenn eine Migration zu SAP S/4HANA ansteht sollten diese Felder übrigens ebenfalls bei einer Stammdatenmigration gesondert berücksichtigt werden. Im Template des Migrationsobjekt Kostenstelle sind diese zum Beispiel nicht im Standard vorhanden, so dass eine entsprechende Aufnahme innerhalb eines onPremise S/4HANA Systems durch Anpassung des Migrationsobjektes durch den SAP Migrationsobjektmodellierer erforderlich ist.
 

Exkurs Datenmigration nach SAP S/4HANA

Greenfield, Brownfield oder Bluefield
Bei einer Migration nach S/4HANA stellt sich dieses Thema natürlich nur bei bestimmten Migrationsszenarien

Greenfield:
Dieses ist eine Neueinführung eines SAP S/4HANA Systems und macht es erforderlich die Daten bspw. per LTMC in das neue  System zu migrieren

Brownfield:
Hier wird ein Update auf ein bestehendes SAP ERP System durchgeführt, so dass die Stammdaen ohnehin schon vorhanden sind.

Bluefield / Mixed Field:
Als Alternative kann auch ein gemischter Ansatz gefahren werden. Hier kann ein Rahmensystem quasi als Hülle zur Verfügung gestellt werden in das auf Ebene der Datenbanktabellen revisionssicher die einzelnen Daten übertragen werden können.

Im Beitrag "Literatur Brownfield Ansatz /Migration ERP-S/4" von Jens Plucinski (www.jensplucinski.de) im FICO-Forum.de sind einige zu beachtende Punkte zu einer praktischen Migration von ERP nach S/4HANA zusammengefasst worden, so dass hier eine praktische TODO angelegt werden kann.
 

Welche Möglichkeiten mit der Nachfolge der LSMW (LTMC und LTMOM) möglich sind durfte ich im aktuellen Buch von mir, aber auch im Beitrag "Fragen und Antworten zur Datenmigration nach SAP S/4 HANA mit LTMC und LTMOM - 📚 Buchveröffentlichung zum SAP S/4HANA Migration Cockpit" näher erläutert sein.

Sollten Sie ihre Stammdaten auch schon in SAP ERP ECC System per Massenverabeitung bearbeiten kann es sinnvoll, wenn nicht sogar erforderlich, sein ihre Aufzeichnungen in der LSMW oder eCATT wie im Artikel "Massenstammdatenpflege mit LSMW oder SECATT dank Transaktionsaufzeichnung - Handbuch erweiterte computergestützte Test-Tool (eCATT) und LSMW" beschrieben anzupassen.

Insbesondere wenn diese Felder zeitabhängig gepflegt sind, sollten hier einige Besonderheiten noch beachtet werden. Immerhin kann ich an dieser Stelle ebenfalls auf "Zeitabhängige Felder für Stammdaten insbesondere bei Zusatzfeldern zum Beispiel für Hochschulfinanzstatistik innerhalb des SAP Modul CO-OM" verweisen und empfehlen dieses beim Testen von Zusatzfeldern ebenfalls zu berücksichtigen.
 

---

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.

---

Für eine Einzelpostenliste als ALV soll eine Auswertung über die im SAP System eingebuchten statistische Kennzahlen je CO Objekt im SAP Modul CO-OM (Gemeinkostencontrolling) erfolgen.

Grundsätzlich würde ich hier zwar auch eher einen Report Painter Bericht wie im Artikel "Hochschulcontrolling: Vergleich Lehrimport von Studiengängen und Kostenanteile einzelner Lehreinheiten - Abschnitte mit abgeleiteten Kennzahlen im Report Painter" oder "Auswertung Statistische Kennzahlen auf Innenaufträge für Lehrimport und Lehrexport auf Ebene Studiengänge" für das die Kostenstellenrechnung oder INnenauftragsrechnung anlegen. Da ich aber für die Auswertung der eingebuchten LENA je Cluster die einzelnen Studiengänge, die als Innenauftrag angelegt sind, benötige um hier eine entsprechende Auswertung zu erstellen, erscheint eine Query als eine gute Wahl.

Hier sollen nun aber die abgerechneten Ergebnisse der Studiengänge (über die Kennzahl Lehrnachfrage (LENA)) zurück auf die einzelnen Lehreinheiten gerechnet werden, als Basis zur Verteilung des Grundbudget. Leider scheint es im SAP Standard keinen Bericht über die gebuchten statistischen Kennzahlen je CO Objekt zu geben.

Tabellen Stat. Kennzahlen COSR, COEJ, COEPR

Die statistischen Kennzahlen (bzw. die Mengen) sind in den Tabellen COSR (Summe) und COEPR (Einzelposten "CO-Objekt: Einzelposten Stat. Kennzahlen - periodenbezogen") gespeichert.


Seitens SAP wird der View VIEW COVPR "CO-Objekt: EP Stat. Kennzahlen - periodenbezogen + Bel.kopf" zur Verfügung gestellt über din die beiden Tabellen COBK

Hier sind direkt COBK und COEPR über Mandant, Kostenrechnungskreis und Belegnummer miteinander verknüpft.

Allerdings scheinen in der COEPR keine Werte mehr abgespeichert zu sein, so dass ich hier lieber eine eigene Query über die Tabellen COEJR "CO-Objekt: Einzelposten Stat. Kennzahlen - jahresbezogen"  anlege.


In der erwähnten Tabellen sind für meine Auswertung insbesondere folgende Felder relevant:

• Statische Menge (hier gibt es für jede Periode en Feld SME001 bis SME016)
• Geschäftsjahr (Feld GJAHR)
• Version (Feld VERSN)
• Statistische Kennzahl (Feld STAGR)

Für das Gemeinkostencontrolling ist noch das Feld Objektnummer (OBJNR) wichtig.
 

Exkurs Objektnummer oder Partnerobjektnummer

Die Objektnummer stellt unterschiedeliche Objekte im Controlling einheitlich dar. Hierbei werden Kostenstellen mit führenden KS* und Innenaufträge mit OR* abgebildet.
In vielen Stammdatentabellen ist ebenfalls die Objektnummer vorhanden, so dass diese verknüpft werden kann.


In unseren Fall ist das aber sehr praktisch, da hierdurch zwei Infosets angelegt werden können durch die ich sowohl eine Auswertung der statistischen Kennzahlen je Innenauftrag als auch Kostenstelle auswerten kann.
 

Datenherkunft / Infoset statistische Kennzahlen und CO Objekte

Für die Innenaufträge:

Infoset:
ZCO_COEJR-AUFK  - "ZCO_COEJR-AUFK Stat Kennzahl Innenauftrag"

Join über tabelle COEJR und mit folgenden Tabellen verknüpft:

COEJR-KOKRS <->  AUFK-KOKRS "Kostenrechnungskreis"
COEJR-OBJNR <->  AUFK-OBJNR "Objektnummer"

Das Feld OBJNR hat in Tabellen eine besondere Funktion, da hier unterschiedliche Kontierungsobjekte festgehalten werden können. So werden beispielsweise Innenaufträge als OR* gespeichert, so dass hier eine entsprechende Verknüpfung erfolgen kann.

Um auch Erfasser und Erfassungsdatum zu erhalten kann ich noch

COEJR-KOKRS <-> COBK-KOKRS "Kostenrechnungskreis"
COEJR-BELNR <-> COBK-BELNR "Belegnummer"

miteinander verknüpfe.


Damit ist das Infoset für die Innenaufträge fertig.


Für die Kostenstellen:

Infoset:
ZCO_COEJR-CSKS-CSKT - "ZCO_COEJR-CSKS-CSKT Stat Kennzahl Kostenstelle"
 
Hier werden mehr Tabellen verknüpft, da die Texte zu den Kostnestellen in Tabelle CSKT und die Stammdaten in CSKS gespeichert sind.


Join über tabelle COEJR und mit folgenden Tabellen verknüpft:

COEJR-KOKRS <->  CSKS-KOKRS "Kostenrechnungskreis"
COEJR-OBJNR <->  CSKS-OBJNR "Objektnummer"

Das Feld OBJNR hat in Tabellen eine besondere Funktion, da hier unterschiedliche Kontierungsobjekte festgehalten werden können. So werden beispielsweise Kostenstellen als KS* gespeichert, so dass hier eine entsprechende Verknüpfung erfolgen kann.


Als kleiner Hinweis am Rande, die Profitcenter sind hier leider als CO Objekte nicht erfasst. Sofern eine Buchung in der Profit-Center-Rechnung (EC-PCA) erfolgte wie im Artikel "Statistische Kennzahlen in Profit-Center-Rechnung EC-PCA auf einzelnen Profit-Center auswerten".

Mit den ersten Join sind nun schon einmal die statistische Kennzahl und die Kostenstellenstammdaten verknüpft.

Ferner sollte nun noch die Tabelle CKS "Kostenstellenstammsatz" und CSKT "Kostenstellentexte" wie folgt verknüpft werden:

CSKS-KOKRS <-> CSKT-KOKRS "Kostenrechnungskreis"
CSKS-KOSTL <-> CSKT-KOSTL "Kostenstelle"
CSKS-DATBI <-> CSKT-DATBI "Datum gültig bis"

Besonders letzteres Feld ist erforderlich, wenn unterjährig sich der Name der Kostenstelle ändert.

Auch hier können noch die Daten aus dem Belegkopf ergänzt werden indem ich die Tabellen

COEJR-KOKRS <-> COBK-KOKRS "Kostenrechnungskreis"
COEJR-BELNR <-> COBK-BELNR "Belegnummer"

miteinander verknüpfe.

Auswertung / Query über statistische Kennzahlen nach CO Objekten (hier: Kostenstelle und Innenauftrag)

Nun kommt es zur eigentlichen Auswertung per Query.

In der Grundliste der jeweiligen Query habe ich zu den einzelnen Feldern in Klammern angeegeben, ob dieses ist L = Listenfeld (nur Anzeige) oder auch ein S = Selektionsfeld (Auswahl) handelt.

Dabei habe ich folgende Felder in die Query übernommen:

Query ZCO_STATK-IA "Statistische Kennzahl Innenauftrag"
zum Infoset ZCO_COEJR-AUFK

Version (L,S) COEJR-VERSN
Geschäftsjahr (L,S) COEJR-GJAHR

Auftrag (L,S) AUFK-AUFNR
Kurztext (L)  AUFK-KTEXT

Statistische Kennzahl (L,S) COEJR-STAGR
Statistische Menge (L) COEJR-SME001

Da ich die Kennzahl jede Periode erneut einspiele und es sich bei den Kennzahlen um Festwerte handelt reicht mir hier der Wert für die erste Periode.
Wichitg ist mir noch, dass bei den Eigenschaften dieses Feld keine Einheit mit ausgegeben wird, was sonst ein Extrafeld in der Query wäre.

Optional können aus dem Belegkopf

Erfassungsdatum (L) COBK-CPUDT
Benutzername (L) COBK-USNAME

ergänzt werden.

Query ZCO_STATK-KS "Statistische Kennzahl Kostenstelle"
zum Infoset ZCO_COEJR-CSKS-CSKT

Hier sind folgende Felder aufzunehmen:


Version (L,S) COEJR-VERSN
Geschäftsjahr (L,S) COEJR-GJAHR

Kostenstelle (L,S) CSKS-KOSTL
Bezeichnung (L) CSKT-KTEXT

Statistische Kennzahl (L,S) COEJR-STAGR
Statistische Menge (L) COEJR-SME001

Da ich die Kennzahl jede Periode erneut einspiele und es sich bei den Kennzahlen um Festwerte handelt reicht mir hier der Wert für die erste Periode.
Wichitg ist mir noch, dass bei den Eigenschaften dieses Feld keine Einheit mit ausgegeben wird, was sonst ein Extrafeld in der Query wäre.

Optional können aus dem Belegkopf

Erfassungsdatum (L) COBK-CPUDT
Benutzername (L) COBK-USNAME

ergänzt werden.

Wichtig ist nun allerdings noch das Feld Gültig bis, so dass nur die aktuellste Bezeichnung der Kostenstelle ausgwertet wird.

Datum Gültig bis (S) CSKS-DATBI

Hier bietet es sich an die Query nur mit einer Variante ausführen zu lassen und das Feld als geschützt mit Datumswert 31.12.9999 laufen zu lassen, sofern alle Kostenstellen grds. bis in die Ewigkeit gültig sind. Andernfalls eben bis zum aktuellen Systemdatum.

Fazit

Die entsprechende Auswertung stellt nun eine Query als ALV Liste dar in der sowohl der Wert in der ersten Buchungsperiode als auch die Kostenstelle beziehungsweise der Innenauftrag mit Kurztext sowie Erfassungsdatum und Benutzername dargestellt wird.

Ein Export kann dann wie folgt aussehen.



Natürlich lassen sich diese Daten dann auch noch ergänzen zum Beispiel nach einer virtuellen Lehreinheit als Zusatzdatum zur Kostenstelle oder aber, wie im Artikel "Auswertung sprechender Nummernkreisintervalle von CO Innenaufträgen mit Query Zusatzfeldcoding und Unterscheidung numerischer oder alphanumerischer Schlüssel" beschrieben mit weiteren Stammdaten.

Besonders im Hochschulberichtswesen und Hochschulcontrolling sind solche Auswertung sehr hilfreich. Da diese dann auch als Basis für weitere Berechnungen genutzt werden können.

Neben den eingangs erwähnten Möglichkeiten mit Report Painter / Report Writer kann auch durch Excel hier einiges erreicht werden.

Beispiele sind "Pivottabellen ab Excel 2010 dynamischer filtern mit Datenschnitten am Beispiel Hochschulfinanzstatistik" oder "Datentrends für Drittmittelstatistik mit Sparklines ab Excel 2010 darstellen durch Liniendiagramme in Zellen".

Hier sind dann Auswertungen mit SAP Query als Datengrundlage sehr nützlich und werden von mir gerne genutzt.

 

---

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.

---

Nicht nur die im Artikel "Änderungen und Nacharbeiten nach Einspielung SAP ERP 6.0 Enhancement Package 8 (EHP 8) insbesondere im CO" erwähnten "positive und aufwändige Änderungen im Rahmen der Support Packages bzw. Erweiterungspakete" auch andere kleinere und größere Fehlermeldungen erinnerten dann doch noch einmal an grundsätzlcihe Zusammenhänge auf die man im Rahmen eines Berichtswesen achten sollte.

Neben Report Painter / Report Writer und Rechercheberichten nutze ich auch gerne Query mit kundeneigener Transaktion um hier das interne Berichtswesen zu bereichern.

Im Artikel "SAP Query als kundeneigene Transaktion mit Berechtigungen für Tabellenberechtigungsgruppe, Tabellen und Reporttransaktion vergeben" bin ich schon einmal auf das Anlegen einer Reporttransaktion eingegangen.

Nach Einspielen der EHP gab es dann jedoch zwei Fehlermeldungen.

In beiden Fällen handelte es sich um einen ABAP Laufzeutfehler mit der Meldung;

LOAD_PROGRAM_NOT_FOUND
ABAP PROGRAMM ???????

Hier war aber tatsächlich der Kurztext wesentlich hilfriecher.

• Programm "AQCS...."
• Programm "AQZZ..."

nicht gefunden.

Wie in oberen Artikel beschrieben handelte es sich dabei um zwei Query die über eine Parametertransaktion gestartet werden.

Der Beginn des Programmnamen AQCS weist dabei eine Query im Standardbereich (mandantenabhängig) und AQZZ im globalen Beriech (mandantenunabhängig) aus.

Nach dieser Einordnung des Arbeitsbereiches folgt die Benutzergruppe gefolt vom Querynamen.

Betrachten wir uns hier die Transaktion in der Pflegetransaktion SE93 ist der Programmcode in der Reporttransaktion in der Zeile PROGRAMM zu lesen.

Als Beispiel für eine globale Query die für alle Einrichtungen zur Verfügung gestellt worden ist...
 

Aufbau Programm für Query

1	2	3	4	5	6
Globaler Bereich	AQ	ZZ	RM_CO	====	Z_QUERY01=====
Standardbereich	AQ	CS	AG_CO	====	Z_QUERY02=====

Aus der Tabelle sind der Aufbau des Programmnamen zu erkennen (insgesamt sind dieses 29 Zeichen bestehend aus den Spalten 2 bis 6. Wobei hier === als Füllzeichen zu sehen sind.

Damit die Query wieder funktioniert, muss tatsächlich das Programm zur Query neu generiert werden, so dass hier ein entsprechendes Programm angelegt wird.

Dieses kann entweder über die Transaktion SQ00 oder SQ01 direkt erfolgen indem die Query erneut ausgeführt wird und vorab in den Arbeitsbereich bzw. die passende Benutzergruppe gewechselt wird und hier die Query gestartet wird.

Alternativ besteht die Möglichkeit über die Transaktion REISSQMAIN bzw. das ABAP Programm SAP_QUERY_CALL (zum Starten per SA38) die Query gestaret werden.

Durch Aktivieren von Globaler Bereich kann hier Benutzergruppe, Query und Variante für die mandantenunabhängigen Query eingetragen werden. Ohne Aktivierung wird die Query im mandantenabhängigen Bereich gestartet.

Hierbei ist zu beachten, dass die Benutzergruppe und Query bekannt sein müssen, da hier keine Wertauswahlhilfe (F4) vorhanden ist.

Um künftig solche Probleme zu vermeiden, lohnt sich ein Blick auf den Artikel "Umstellung Reporttranskationen auf Parametertransaktionen zum Aufruf SAP Query".


 

---

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.

---

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.

Gerade in Hinblick auf Drittmittelstatistiken hat das Hochschulberichtswesen dann doch die ein oder andere spezielle Anforderungen, so dass hier oftmals diverse Auswertungen im SAP Modul PSM (Public Sector Management) FM (Funds Management / Haushaltsmanagement) für den öffentlichen Dienst erfolgen.

Berichtswesen im PSM-FM (Rechercheberichte)

Durch Rechercheberichte ist es möglich, wie im Artikel "Saldenliste für Fonds im Haushaltsmanagement Saldo gegen Ertrag und Saldo gegen Budget" beschrieben je Fond (Gegenstück zum CO-Innenauftrag bzw. Drittmittelprojekt nicht nur die Bewilligungen (als Budgetwerte) sondern auch Ertrag und Aufwand sowie einen berechneten Saldo auszuwerten.

Interessant an der Verwendung von Rechercheberichten ist, dass hier auch die dargestellten Merkmale im Rahmen der Navigation ausgetauscht werden können und so interaktiv der Bericht so angepasst werden kann, dass dieser unterschiedliche Informationen darstellen kann. Im Artikel "Grundlagen Rechercheberichte Ausgabeart grafische Berichtsausgabe oder klassische Recherche" habe ich versucht dieses näher zu beschreiben.

Während an manchen Hochschulen eine reine Saldenliste ausreicht kann es an anderen Hochschulen erforderlich sein die Mittelherkunft von Drittmittelprojekten nicht nur über die Projektnummer sondern anhand einzelner Spalten auszuwerten. Hierzu kann im Formular das Merkmal Finanzierungszweck verwendet werden. Der Finanzierungszweck dient dabei als ein Gruppierungsmerkmal und kann sowohl in Spalten im Formular  als auch im Bericht als Merkmal zugewiesen werden. Durch die Verwendung im Bericht kann über die Navigation auch die Sicht auf dieses Merkmal umgestellt werden.

Alternativ kann durch die Festlegung des Finanzierungszweck in einer Spalte hier die Drittmittelstatistik nach Mittelgeber direkt in Tabellenform ausgegeben werden.

Die Grundlagen zur Erstellung eines Rechercheberichtes habe ich in meinen Buch »Berichtswesen im SAP®-Controlling« beschrieben. Hierbei sollte sich nicht durch das Controlling iritiert werden lassen, da Rechercheberichte sowohl in der Finanzbuchhaltung für Bilanzreporting, Controlling in der Profit-Center-Rechnung als auch im Modul für den Öffentlichen Dienst (PSM-FM) genutzt werden können.

Einen Überblick bietet hier der Artikel "Grundlagen: Was sind die Unterschiede zwischen Report Painter und Rechercheberichte?"

Customizing Einstellungen für Finanzierungszweck FINUSE

Damit der Finanzierungszweck zur Verfügung steht muss dieses Feld jedoch zur Pflege verfügbar sein. Hierzu kann im Customizing (Transaktion SPRO) über

• Public Sector Management
• Haushaltsmanagement Öffentliche Verwaltung
• Stammdaten
• Kontierungselemente
• Feldauswahl bearbeiten / Feldauswahlleisten bearbeiten
• Die "Feldauswahlleiste für Fonds bearbeiten"

Die einzelnen Stammdatumfelder der Fond von Ausblenden, Anzeigen, Kanneingabe oder Mußeingabe gepflegt werden.

Dabei kann sowohl das Feld FINUSE Finanzierungszweck als auch SPONSOR (Debitor zum Fond) oder auch TYPE Fondsart als Kanneingabe hinterlegt werden. Interessant ist in unseren Fall der Feldname FINUSE für den Finanzierungszweck, da dieser später auch im Recherchebericht als Merkmal zur Verfügung steht.

Über den Punkt Feldauswahlleisten den Finanzkreis zuordnen kann je Finanzkreis eine Zuordnung der Feldauswahlleiste für Finanzposition, Finanzstelle und Fonds hinterlegt werden.

Nebenbei besteht bei der Pflege der Feldauswahlleiste für Finanzstelle auch die Möglichkeit hier den Feldnamen GSBR für Geschäftsbereich zu hinterlegen. Dieses ist jedoch nur bei der Finanzstelle möglich. Auf das Thema Geschäftsbereiche bin ich im Artikel "Grundlagen Finanzbuchhaltung - Geschäftsbereiche als mögliche Lösung zur Abbildung eines Betrieb gewerblicher Art (BgA)" in einen anderen Zusammenhang eingegangen.

Pflege Finanzierungszwecke im Fond

Nachdem die Feldauswahlleiste entsprechend gepflegt ist kann bei der Anlage oder beim Ändern eines Fond im SAP Menü unter

• Rechnungswesen
• Public Sector Management
• Haushaltsmanagement
• Stammdaten
• Kontierungselemente
• Fonds
• Finanzierungszweck

diese in den Stammdaten per

• Anlegen (Transaktion FM5I) oder
• Ändern (Transaktion FM5U)

in den Zusatzdaten ein Finanzierungszweck hinterlegt werden.

Neue Finanzierungszwecke anlegen

Der Finanzierungszweck selbst dient dabei als Gruppierungskriterium von Fonds bei Auswertungen und kann als eigenes Stammdatum unterhalb des Knoten

• Public Sector Management / Haushaltsmanagement / Stammdaten / Kontierungselemente / Fonds
• unter Finanzierungszweck

per Anlegen (Transaktion FM6I) oder Ändern (Transaktion FM6U) mit einer Bezeichnung und Beschreibung angelegt werden. Hierzu ist kein weiteres Customizing oder ein Transportauftrag erforderlich, da es sich um ein Stammdatum wie Fond oder Finanzstelle handelt.

Eine alphabetische Liste aller bisher angelegten Finanzierungszwecke ist im Infosystem des Haushaltsmanagement im Stammdatenverzeichnis > Fonds als Transaktion S_KI4_38000040 verfügbar.

Die Verwendung vom Finanzierungszweck im Berichtswesen ist auch im Artikel "PSM-FM Grundlagen Finanzierungszweck im Haushaltsmanagement bei Recherchebericht und Selektion" behandelt worden. Allerdings fehlten da ein paar Ausführungen rund um das Customizing.

Alternative Stammdatengruppen

Sollte der Finanzierungszweck schon durch eine andere Berichtsanforderung oder Zuordnung verwendet werden bietet es sich noch an mit Sets bzw. Stammdatengruppen der Fonds zu arbeiten. Auch diese lassen sich als Gruppe im Selektionsbild auswerten oder als Element über die Markierung Gruppe/Set für Fond entweder als feste Bezeichnung des Gruppennamen oder als Variable festlegen.

Abweichend zur Finanzstelle werden Fonds jedoch nicht hierarchisch dargestellt, so dass beim Auswerten einer Gruppe alle zugeordneten Fonds als Liste dargestellt werden. Alternativ können diese natürlich auch als Spalten definiert werden und hier auch per Formel Summen zum Beispiel zwischen den einzelenn Förderlinien der DFG gebildet werden.

Die Pflege von Fondgruppen erfolgt unter:

• Public Sector Management
• Haushaltsmanagement
• Stammdaten
• Kontierungselemente
• Fonds
• Fondsgruppe

Hier können die Sets über Anlegen (Transaktion FM_SETS_FUND1) oder auch Ändern (Transaktion FM_SETS_FUND2) bearbeitet werden.

Eine Liste aller Stammdatengruppen inklusive der Intervalle und zugeordneten Fonds kann zum Beispiel per Query wie im Artikel "Auflösen von Stammdatengruppen nach Einzelwerten - Einzelwerte zu Sets" erläutert ausgewertet werden.
 

Saldenliste aus Recherchebericht um Stammdaten erweitern

Neben der Darstellung von Finanzierungszweck im Rechercheberichten kann es auch sinnvoll sein weitergehende Informationen zum Beispiel als differenziertes Statistikkennzeichen am Fond zu hinterlegen.

Viele Hochschulen nutzen dabei die Merkmale der Klassifizierung die ebenfalls im Fond über die Schaltfläche Klassifizierung gepflegt werden können.

Grundlagen Klassifizierung, Auswertung von gepflegten Merkmalen per Query

Die Grundlagen zum Thema Klassifizierung und die Frage, wie diese Merkmale in Form einer Query ausgewertet werden können habe ich im Artikel "SAP Query - Auswertung Merkmale der Klassifizierung am Beispiel Fonds in PSM-FM" behandelt. Sollten in den Merkmalen auch Datumsfelder erfasst werden und als solche in einen Datumformat definiert sein ist auch der Artikel "Query zur Auswertung von Klassifizierungsmerkmale PSM Fonds zu CO Innenauftrag und Datumsfelder mit Konvertierung von FLOAT zu DATUM" ein guter Hinweis, wie diese ausgewertet werden können.

Weitere Erweiterungen für Stammdatenlisten mit SAP Query

Tatsächlich kann der eingangs beschriebene Recherchebericht genutzt werden um nachdem die Salden gezogen worden sind über eine Query die einzelnen Merkmale und zusätzliche Informationen aus einer Query zu erheben. Neben der reinen Auswertung von Stammdaten können hier auch Bewertungen wie in den Artikeln "Drittmittelstatistik nach LOMZ über Recherchebericht und SAP Query", "Gruppierung von Finanzierungszwecken bei Drittmittelprojekten per Zusatzfeldcoding mit IF oder CASE" oder auch "Auswertung sprechender Nummernkreisintervalle von CO Innenaufträgen mit Query Zusatzfeldcoding und Unterscheidung numerischer oder alphanumerischer Schlüssel" zur Auswertung einer virutellen Lehreinheit um nur ein paar wenige Beispiele zu nennen angewandt werden.

Zweistufige Auswertung für Drittmittelstatistik

Wie schon im Artikel "SAP Query als kundeneigene Transaktion mit Berechtigungen für Tabellenberechtigungsgruppe, Tabellen und Reporttransaktion vergeben" beschrieben besteht die Möglichkeit eine solche Query als kundeneigene Transaktion anzulegen, so dass hier eine hochschuleigener Stammdatenliste erstellt werden kann.

Daneben kann natürlich auch der Budgetbericht bzw. die Saldenliste des Recherchebericht ebenfalls als eigene Transaktion zur Verfügung gestellt werden. Dieses ist im Artikel "Parametertransaktion für Recherchebericht" angesprochen. Wobei der Artikel "»Rechercheberichte de lux« im Modul PSM FM Haushaltsmanagement" auch noch ein wenig weiter geht, was die Umsetzung für ein Berichtswesen anbelangt.

Beide Berichte können dann nach Excel bzw. in eine Tabellenkalkulation exportiert werden und, sofern die Fonds sortiert sind, direkt nebeneinnander gelegt werden. Der Artikel "Grundlagen - Berichte von SAP nach Excel exportieren" stellt hier die Vorgehensweise dar. Eine Besonderheit bei der Excel-Integration bspw. in Report Painter Berichten ist bei Rechercheberichten tatsächlich nicht zu beachten.

Dennoch verweise ich an dieser Stelle gerne auf "Office Integration - Excelansicht in SAP und Daten kopieren nach Excel" um das Thema umfassend zu beschreiben :-)

Hier können dann Fonds selektiert werden und die Nummer der Fonds für den Recherchebericht verwendet werden (Zwischenablage aus der ALV Liste) oder umgekehrt zum Recherchebericht in Excel die beiden Auswertungen miteinander gegenüber gelegt werden.

Auf diese Weise sind dann auch umfassende Analysen wie im Artikel "Datentrends für Drittmittelstatistik mit Sparklines ab Excel 2010 darstellen durch Liniendiagramme in Zellen" beschrieben mit Excel möglich.

Pflege von Stammdaten wie FINANZIERUNGSZWECK

Sollte eine Hochschule ihre Erhebung einer Drittmittelstatistik von den Merkmal der Klassifizierung auf neu eingeführte Finanzierungszwecke abändern oder bisherige Finanzierungszwecke feingliedriger anpassen wollen, kann es sinnvoll sein hier eine Query anzulegen um die gepflegten Statistikkennzeichen aus der Klassifizierung je Fond zu erheben und diese dann als Basis zur Massenstammdatenpflege der Finanzierungszwecke je Fond zu nutzen.

Da dieses ein häufiges Thema ist dürfte auch der Artikel "Massenstammdatenpflege mit LSMW oder SECATT dank Transaktionsaufzeichnung - Handbuch erweiterte computergestützte Test-Tool (eCATT) und LSMW"  im Rahmen einer solchen Umstellung sehr hilfreich sein.
 

Fazit

Gerade im Hochschulberichtswesen (und auch Hochschulcontrolling) können Berichtsanforderungen auf viele Arten erfüllt werden. Nicht ohne Grund ist der Artikel "Unterschiedliche Auswertungsmöglichkeiten im Controlling (Report Writer, Recherchebericht, SAP Query) und natürlich Excel ;-)" mit einen Augenzwinkern in Richtung Excel gehalten. Dennoch sind das Ineinandergreifen unterschiedlicher Berichtstools aber auch Office-Anwendungen wie im Artikel "Serienmails über Serienbrieffunktion in Winword per Outlook, Thunderbird oder anderen Mailprogramm versenden" beschrieben ein wesentlicher Aspekt dessen was mir an der Arbeit besondere Freude macht und sich auch darin äußert, dass ich gerne Workshops oder nun auch ein Tagesseminar zu eben diesen Themen anbiete.

Was die Zukunft in Richtung S/4HANA oder auch die Gestaltung von FIORI Apps anbelangt blicke ich neugierig in eine Zukunft und freue mich schon heute auf die "FICO-FORUM-INFOTAGE 2018" auch da sich hier einige Kolleginnen und Kollegen aus den Bereich Hochschulen ebenfalls angemeldet haben und ich darauf hoffe, dass diese ebenfalls Informationen und Wissen rund um S/4HANA mitnehmen können und von dieser Veranstaltung ebenfalls so begeistert snd, wie ich. Selbst wenn diese Veranstaltung nicht explizit fürs Hochschulcontrolling, Hochschulberichtswesen oder Hochschulfinanzwesen gedacht ist können hier doch Informationen zu verschiedene Themen rund um SAP mitgenommen werden und auch der Austausch vor Ort ist oftmals sehr produktiv auch und gerade dadurch, dass hier unterschiedliche Branchen vor vergleichbaren Problemen stehen.

Sollten Sie ebenfalls an dieser Veranstaltung teilnehmen würde ich mich über einen Austausch eventuell bei einer Tasse Kaffee sehr freuen. So werde ich vom 17. bis 20. November 2018 ebenfalls in Köln sein und am Forum von 19. bis 20. November teilnehmen.

Ich bin mir sicher, dass hier auch wieder viele Neuigkeiten und Informationen ausgetauscht werden können und werde im Anschluss sicherlich auch über das ein oder andere hier im Blog aber vor allen auch an der Arbeit berichten können.

Aber auch unabhängig davon freue ich mich immer wieder über Anfragen hier im Blog oder auf anderen Wegen, da der gelebte Austausch von Wissen hier für jede Seite ein Gewinn zu sein vermag.
 

---

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. Für eine Anleitung für Rechercheberichte kann ich die im Artikel verlinkten Beiträge empfehlen oder tatsächlich auch mein Buch »Berichtswesen im SAP®-Controlling« dass trotz Schwerpunkt auf CO durchaus auch für andere Module wie eben auch das Haushaltsmanagement in der öffentlichen Verwaltung die Grundlagen vermittelt.  Daneben finden sich unter den Buchempfehlungen auch für andere Module gute Bücher und natürlich kann auch sonst ihr SAP Know How erweitert werden.

---

Nachdem ich im Rahmen einer Arbeitsgruppe des Competence Center für Hessische Hochschulen schon einen "Auffrischungsworkshops SAP Query im Hochschulcontrolling und Hochschulberichtswesen" gehalten habe hat sich dann noch ein Tagesseminar zum Thema »SAP Query in SAP ERP« mit Auswertung von Stamm und Bewegungsdaten aus den Modulen des Rechnungswesens (CO, FI, PSM-FM) ergeben.

Dieses war auch relativ schnell ausgebucht und ich hoffe, dass die angebotenen Übungen tatsächlich weiter geholfen haben um die Möglichkeiten mit SAP Query im Hochschulberichtswesen darzustellen.



Eine wichtige Frage, die auch in der Schulung behandelt worden ist, war wie Endanwende später die erstellte Query aufrufen und nutzen können. Selbstverständlich besteht die Möglichkeit über Benutzergruppen und die Transaktion SQ00 eine Query direkt zu starken und berechtigungsseitig hier die Pflege der Query einzuschränken, aber eleganter und praktischer ist es in meinen Augen der erstellten Query eine eigene Transaktion zuzuweisen.

Report-Transaktion für SAP Query

Hierzu kann über die Transaktion SE93 eine sogenannte Reporttransaktion angelegt werden.

Diese Reporttransaktion ruft direkt einen ABAP Report auf und über das Selektionsbild 1000 gelangt man auch direkt in das Auswahlfenster der Transaktion und kann in der Reporttransaktion auch im Punkt Start mit Variante eine passende Variante für die Query anlegen und diese direkt starten um eine bestimmte Vorauswahl in der Selektion zu speichern und hier auch eine Layoutvariante zu hinterlegen.

Reportname zu SAP Query

Die Frage ist nun nur, wie kann der Reportname herausgefunden werden. Im Artikel "Transaktion anlegen (Report, Parameter) bspw. für SAP Query / Unterschied Parameter- oder Reporttransaktion" bin ich schon einmal darauf eingegangen, dass in der Transaktion SQ01 im Menü über QUERY->WEITERE FUNKTIONEN->REPORTNAME ANZEIGEN der zugeordnete Reportname angezeigt werden kann.

Dabei ist die Namenslogik des Reportnamen wie folgt aufgebaut:

• Mandantenabhängige (Standardbereich) Query beginnen mit AQCS
• Globale (Globaler Beeich) Query beginnen mit AQZZ

danach folgt die Benutzergruppe in der die Query zugeordnet ist und der Name der Query. Dieser wird mit == aufgefüllt, so dass eine Gesamtlänge des Reportnamens von 30 Zeichen sich ergibt.

So wird die Query AQ mit der Bezeichnung  ZCOFM_PROJEKTE der Benutzergruppe ZBUCH im Standardbereich CS(mandantenabhängig) als Report mit folgender Bezeichnung zugeordnet:

• AQCSZBUCH=======ZCOFM_PROJEKTE

Nachdem der Reportname zur Query in der Reporttransaktion hinterlegt wird ist nun noch eine Frage, wie die Berechtigungen für die SAP Query-Transaktion vergeben werden können. Hierzu müssen entsprechende Berechtigungsobjekte mit Berechtigungsfeldwerten versehen werden.

Parametertransaktion zu SAP Query

Eine bessere Alternative ist jedoch die Anlage einer Parametertransaktion zu SAP Query. Diese ist im Artikel "Umstellung Reporttranskationen auf Parametertransaktionen zum Aufruf SAP Query" näher beschrieben inklusive einen Hinweis, warum eine Reporttransaktion Probleme bereiten kann.
 

Berechtigungsobjekte und Berechtigungsfeldwerte auf Tabellen und Tabellenberechtigungsgruppe

Dabei ist natürlich nahe liegend das Berechtigungsobjekt S_TCODE "Transaktionscodeprüfung bei Transaktionsstart" mit im Berechtigungsfeld Transaktionscode mit der neu angelegten Transaktion bspw. ZUNKELBACH zu füllen.

Neben der reinen Berechtigung für den Start der Transaktion sind aber auch noch die Berechtigungen für das Lesen der Daten mit der Query erforderlich.

Hier sind zwei Berechtigungsobjekte noch zu füllen.

Das Berechtigungsobjekt S_TABU_DIS "Tabellenpflege (über Standardtools wie zB SM30) ist mit der Aktivität 03 Lesen zu versehen und im Berechtigungsfeld Tabellenberechtigungsgruppe zu hinterlegen. Die Zuordnung von Tabellen zu Berechtigungsgruppen erfolgt mandantenunabhängig über die Transaktion SE54 (Speicherort der Einstellungen ist dann die Tabelle TDDAT Pflegebereiche für Tabellen) einzusehen.

Ferner ist auch das Berechtigungsobjekt S_TABU_NAM "Tabellenzugriff über generische Standardtools" ebenfalls mit der Aktivität 03 und den relevanten Tabellennamen zu pflegen.

Es bietet sich tatsächlich an hier über einen Testuser und der Transaktion SU53 die entsprechenden Berechtigungsfeldwerte zu ermitteln. Im Artikel "SAP Basis Basic oder dank SU53 oder ST01 Trace fehlende Berechtigungen finden" bin ich auch auf die Frage der Berechtigungsprüfung nebst einer Anzeige der fehlgeschlagenen Berechtigungsprüfungen für eine andere Benutzerkennung eingegangen.

Eine Auswertung für Stammdaten im Bereich CO-OM (zum Beispiel "Auswertung sprechender Nummernkreisintervalle von CO Innenaufträgen mit Query Zusatzfeldcoding und Unterscheidung numerischer oder alphanumerischer Schlüssel") verlangte als Berechtigungsausprägung folgende Angaben in den Berechtigungen:

• S_TABU_DIS
  Anzeigeberechtigung auf Tabellenberechtigungsgruppe:
  KA          CO:Anwendungstabelle
  KEC        CO-PA:Customizing

und zum direkten Lesen der Tabellen für die Stammdaten der Innenaufträge sowie  der Stammdaten der Profit-Center (EC-PCA) zu lesen.

• S_TABU_NAM
  Anzeigeberechtigung für Tabellen
  AUFK    Auftragsstammdaten
  CEPCT   Profit-Center-Stammdaten Texte

Während eine Auswertung der Stammdaten im Bereich FI für Kreditoren wie im Artikel "Query über IBAN und Stammdaten Kreditor oder Debitor (Zusatztabellen in SAP Query)" beschrieben folgende Berechtigungen benötigte:

• S_TABU_DIS
  Anzeigeberechtigung auf Tabellenberechtigungsgruppe
  FA   RF:Anwendungstabelle
  &NC&   ohne Berecht.gruppe

und der Stammdaten der Kreditoren (Lieferanten) sowie der IBAN Verbinudng (TIBAN).

• S_TABU_NAM
  Anzeigeberechtigung für Tabellen
  LFBK Lieferantenstamm (Bankverbindungen)
  TIBAN  IBAN

Sollen statt der Kreditoren (Lieferanten) die Debitoren (Kunden) ausgewertet werden ist hier natürlich KNBK Kundenstamm (Bankverbindungen) zu hintelegen.

Gerade die Aussteuerung von Berechtigungen sowie die Umsetzung eines Berechtigungskonzeptes ist ein Grund warum die anwendungsbetreuende Keyuser der jeweiligen Fachabteilungen ebenfalls eng mit der SAP Basis und der Berechtigungsvergabe zusammen arbeiten sollten. Ein weiteres Thema ist hier, insbesondere bei mehreren Mandanten innerhalb des SAP System, auch eine Frage der Namenskonvention. Eine Reporttransaktion wird über einen Workbenchauftrag transportiert und steht damit mandantenübergreifend im System zur Verfügung. Die Query liegt dafür ggf. jedoch im mandatenabhängigen Bereich (es sei denn es ist eine globale Query). Die unterschiedlichen Möglichkeiten zum "Transport von InfoSet mit ABAP-Coding und Query per Transportauftrag" wurden ja schon beschrieben. Sinnvoll kann es hier sein bei kundeneigene Transaktionen als Namensraum Z gefolgt von der Mandatennummer zu verwenden, so dass hier keine Verwechslung entsteht.Sinnvolle Namenskonventionen für kundeneigene Entwicklungen sollten ebenfalls in einen Fachkonzept, wenn nicht sogar im Berechtigungskonzept, hinterlegt werden.

Schulung zu SAP Query

Persönlich hat mir die Ausarbeitung der SAP Schulung zum Thema SAP Query im Berichtswesen viel Freude gemacht und ich hoffe, dass die Begeisterung für die einzelnen Berichtstools und Möglichkeiten gerade im Kontext Hochschulcontrolling und Hochschulberichtswesen hier überzeugend dargestellt worden sind. Eine Darstellung der von mir im Berichtswesen besonders gern genutzten Tools und Möglichkeiten habe ich auch im Buch »Berichtswesen im SAP®-Controlling«  geschildert, dass ebenfalls einen guten Überblick über den Aufbau eines Berichtswesen sowie eine Einführung über "Unterschiedliche Auswertungsmöglichkeiten im Controlling (Report Writer, Recherchebericht, SAP Query) und natürlich Excel ;-)" bietet.

Da das Tagesseminar relativ schnell ausgebucht war bin ich gespannt, ob sich noch einmal eine Nachfrage für ein erneutes Seminar zum Thema finden wird. Ansonsten bleibt es erst einmal bei den Buchempfehlungen die ich auch hier online gerne gebe.

Gerade im Bereich des Berichtswesen auch und besonders für Hochschulen ist auch ausserhalb des Controlling ein sinnvolles Berichtswesen auch daran gekoppelt welche Möglichkeiten zur Auswertung im jeweiligen System zur Verfügung stehen. Daher möchte ich mich auch bei den Teilnehmerinnen und Teilnehmern meiner Schulung bedanken die sowohl eine gute Bewertung als auch durch ihre rege Beteiligung eine Menge an Feedback gegeben haben.

Die Schulung selbst ist relativ umfangreich und anspruchsvoll gewesen, jedoch war die Rückmeldung auch so, dass selbst erfahrende Anwendende noch den ein oder anderen neuen Aspekt dieses Tool kennen gelernt haben. Die Besetzung mit Keyuserinnen und Keyusern aus den Modulen FI, CO, PSM-FM und auch MM sowie geplant HCM hat gezeigt, dass es sinnvoll war hier die Übungen zwar aus den Modulen des Rechnungswesen (CO, FI. PSM-FM) zu nehmen aber so zu wählen, dass diese grundsätzliche Funktionen wie die Nutzung von Join, logische Datenbanken oder auch Zusatztabellen, Zusatzfeldern und Zusatzfeldcoding beschrieben hat.

Teilweise sind die vorgestellten Übungen auch schon in diversen Blogartikeln ausführlich behandelt, allerdings dürfte die Zusammenstellung der Beispiele auch für den ein oder anderen interssant sein. Durch die ausgewählten Beispiele, die sich ursprungsbedingt natürlich in der Hauptsache im CO Umfeld befinden, sollten die verschiedenen Möglichkeiten vorgestellt werden und ich hoffe, dass diese auch für andere Personen übertragbar sind. Sowohl im Finanzwesen als auch im Personalwesen werden tatsächlich auch logische Datenbanken genutzt.

Auf eine Wiederholung der Schulung freue ich mich ebenso wie mir auch das Aktualisieren und Ergänzen der Schulungsunterlagen auf Basis von Rückmeldungen und Fragen Freude gemacht hat. Entsprechend gerne stehe ich mit meinen Angebot für eine künftige Schulung zur Verfügung. Die Schulung slebst ist in vier Abschnitten mit entsprechenden Übungen aufgeteilt und widmete sich nicht nur der Grundlagen von SAP Query mit den einzelnen relevanten Elementen (Arbeitsbereich, Benutzergruppe, Infoset, Query), der Identifizierung von Daten (wo diese gespeichert sind sowie auch die Erweiterung der Query durch lokale Felder, Zusatztabellen und Zusatzfelder inklusive Zusatzfeldcoding das noch weitere Möglichkeiten bietet. Die Übungen zeigten nicht nur die Anwendung dieser Möglichkeiten sondern durch praktische Übungen auch Auswertung von Stamm und Bewegungsdaten aus den Modulen des Rechnungswesens  (CO, FI, PSM-FM).
 

---

Hinweis:

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

---

In letzter Zeit habe ich etwas weniger hier im Blog und dafür mehr auf andere Artikel im "social web" verwiesen (siehe facebook.com/unkelbach/ ) und natürlich werfen auch einige Veranstaltungen im Oktober und November ihren Schatten vorraus (hier verweise ich gerne auf die vorläufige Agenda der FICO Forum Infotage 2018) aber dennoch sind einige Artikel hier in der Entwurfsversion und auch per Mail kam die ein oder andere Frage rund um SAP hier herein über die ich mich sehr gefreut habe und wo der Austausch dann tatsächlich auch für mich lehrreich war.

Ausgangslage: Fehlendes ABAP Coding nach Transport von Infoset und Query

Nachdem ein Infoset mit Coding im Zusatzfeld erzeugt worden ist sollte dieses im Rahmen einer Dreisystemlandschaft (Development/Entwicklung-, Qualitätssicherung/Test- und Produktiv System) transportiert werden.

Der Transport verlief vom D-System ins Q-System problemlos und das Coding im Infoset war ebenfalls vorhanden, lediglich beim Transport ins Produktivsystem fehlte dann das Coding im Infoset und die Query konnte nicht wie erhofft verwendet werden.

Anhand der Beschreibung im Artikel "Transport von SAP Queries (DL/UL)" war der Verdacht naheliegend, dass nicht nur beim Upload über das Dateisystem sondern auch bei der Freigabe des Transport über die SE01 der User die Berechtigung für das Berechtigungsobjekt S_DEVELOP im Produktivsystem benötigt damit der Transport erfolgreich durchgeführt werden könnte.

Damit wäre aber eine Anbindung von Query und Infoset über einen Transportauftrag gar nicht erforderlich, da eine Entwicklung ja ebenfalls direkt im Produktivsystem erfolgen könnte.

Nach einigen Hin und Her hat sich jedoch herausgestellt, dass das Infoset inklusive Coding im Q-System schon vorhanden war und die Ursache für den scheinbaren Fehler an einer anderen Stelle zu finden war.

Für eilige Personen die kurze Zusammenfassung:

"Nachdem per STMS der Transport in das Produktivsystem importiert wurde muss auch ein Import mit der SQ02 erfolgen.  Auf diesem Wege ist es nicht notwendig die Berechtigung S_DEVELOP zu besitzen."

An dieser Stelle vielen Dank auch an die Mail mit den Hinweis auf die gefundene Ursache. Da sicherlich auch andere Personen manchmal auf einen solchen Fehler stossen möchte ich in diesen Artikel diese Lösung gerne etwas ausführlicher erläutern.

Da mir der Transport von Query und Infoset bisher auch mehr über Download und Upload bekannt war mag ich hier aber die notwendigen Schritte für beide "Transportvorgänge" erläutern.

Möglichkeit 1: Download und Upload über Präsentationsserver

Die von mir gerne verwendete Methode ist der Transport von Infoset und Query über das Dateisystem. Dieses hat auch den Vorteil, dass sowohl Query als auch Infoset durch andere Einrichtungen ebenfalls verwendet werden können.

Im Rahmen der Infoset Pflege (Transaktion SQ02) kann über das LKW Symbol (Tastenkombination STRG + F3) das SAP Query Transporttool aufgerufen werden. Alternativ kann auch direkt der Report RSAQR3TR  über die Transaktion SA38 gestartet werden.

Im Abschnitt Transportoption kann Download zum Herunterladen der Objekte (Wahlweise Benutzergruppen, Infoset, Infoset und Query oder nur Query) gewählt werden und später über Upload eben diese auch wieder in einen anderen System hochgeladen werden. Der Austausch erfolgt dann über eine Textdatei in der alle Optionen hinterlegt sind.

Beim Upload / Download ist es jedoch nicht möglich Layout-Varianten von Queries oder Berichts-Bericht-Schnittstellen mit zu übertragen.

Fener ist darauf zu achten, dass sofern Infosets mit ABAP Coding übertragen werden sollen, ist der Objekttyp PROG im Berechtigungsobjekt S_DEVELOP und 'AQ*' für OBJNAME erforderlich. Andernfalls ist ein Coding hier nicht möglich. Dieses gilt dann auch für einen Import von Query per Upload in ein anderes System. Etwas ausführlicher ist das Ganze in unten verlinkter Anleitung im Abschnitt "8. Query und Infoset per Upload/Download transportieren" erläutert.
 

Möglichkeit 2: Export und Import per Transportauftrag

Wesentlich umfangreicher, dafür aber an einer Transportschicht angebunden, ist der Transport von den oben erwähnten Objekten (optional auch mit Layout-Varianten von Queries oder der Bericht-Berichtsschnittstelle) per Transportauftrag.

Hierzu kann ebenfalls das SAP Query: Transporttool aufgerufen werden allerdings muss hier die Option Export ausgewählt werden.

Danach kann ein Transportauftrag angelegt werden und dieser wie üblich über die SE01 oder SE10 freigegeben und per STMS in das Folgesystem transportiert werden.

Nachdem der Transport erfolgreich durchgeführt ist muss jedoch erneut im Zielsystem das SAP Query: Transporttool aufgerufen werden und hier über die Option Importieren im Abschnitt Transportoptionen im Punkt Datenbestand bei Importen der Transportauftrag angegeben werden. Dieses ist per SQ02 über das LKW Symbol (Tastenkombination STRG + F3)  oder aber per ABAP Report RSAQR3TR  (Transaktion SA38). Dazu muss im Abschnitt "Datenbestand bei Importen" der Name des Transportauftrages angegeben werden. Die Transportauftragsbezeichnung ist auch bei erfolgreichen Transport ersichtlich. Erst danach steht auch das Infoset inklusive Coding als Datenbestand zur Verfügung.
 

Nachtrag / Update 2021:

Im Artikel "SAP Query einfach transportieren" hat Andreas Geieger auf ERP-UP.de. die Vorgehensweise über die Transportumgebung  durch Export und Import ausführlicher inklusive Screenshots beschrieben. Sollten Sie sich als dazu entscheiden nicht per Upload / Download sondern per Transportauftrag ihre Query zu transportieren ist dieses ein guter Weg dazu. Nebenbei dürfte ein Grund für den Transportauftrag auch ein entsprechendes Berechtigungskonzept sein, dass auf eine Zuweisung von S_DEVELOP an reine Anwendende (auch eingeschränkt mit OBNAME AQ*) verhindern möchte.
 

Fazit

Der Austausch per Mail hat mir einmal wieder gezeigt, dass die Welt rund um SAP Anwendende doch recht klein ist und der Austausch von Wissen in den seltensten Fällen eine Einbahnstraße ist. Auch wenn ich im ersten Moment nicht weiter helfen konnte hat sich die Lösung dann doch noch gefunden und ich habe mich sehr über die Rückmeldung gefreut und hoffe, dass sollte noch jemand dieses Problem haben künftig hier eventuell dann tatsächlich dieser Artikel etwas weiter helfen kann.

Welche Methode nun besser für den Transport von Query und Infoset geeignet ist muss hier aber tatsächlich mit der SAP Basis, Berechtigungskonzept sowie mit der Frage ob die erstellte Query nur in der eigenen Systemlandschaft oder auch in anderen Systemen genutzt werden sollen abgeklärt werden.

An dieser Stelle verweise ich auch gerne auf notwendige Nacharbeiten nach Support Package oder EHP Einspielung in meinen Artikel "LOAD_PROGRAMM_NOT_FOUND Programm AQCS oder AQZZ bei Aufruf Query per Reporttransaktion - SAP Query nachgenerieren lassen".


Zumindest Anwendungsbetreuende oder Keyuser dürften die Möglichkeit des Tranport per Upload und Download sehr zu schätzen wissen, auch weil hier bestimmte Einstellungen manuell ebenso wie beim Transport von Report Painter und Report Writer Berichten noch angepasst werden können.





Für diese bin ich im Artikel "Report Writer oder Report Painter Berichte über Dateisystem inklusive Bibliothek Variablen und Berichtsgruppe exportieren und importieren" ausführlicher drauf eingegangen.

Daneben ist im Themenfeld Berichtswesen gegebenenfalls auch der Artikel "Transport von Selektionsvarianten"  ebenso lesenswert wie die Erstellung von kundeneigene Transaktionen für Berichte wie im Artikel "Transaktion anlegen (Report, Parameter) bspw. für SAP Query / Unterschied Parameter- oder Reporttransaktion" oder auch "Kundeneigene Transaktionen zu Berichten in PSM FM Haushaltsmanagement zum Beispiel Belegjournal anlegen (Variantentransaktion)" näher beschrieben.

Wie Berichte später den Anwendenden zur Verfügung gestellt werden ist auch ein Thema im Artikel "Benutzereigene SAP Menüs (Favoriten, Benutzermenü, Bereichsmenü)" aber auch meinen Buch zum Thema »Berichtswesen im SAP®-Controlling«

 

---

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.

---

Wie im Artikel "SAP Query: Berechtigung (organisatorisch und technisch)" beschrieben können die Zugriffsberechtigungen auf eine Auswertung per SAP Query unter anderen über die Zuordnung der Benutzerkonten zu Benutzergruppen (zu pflegen in der Transaktion SQ03) gesteuert werden.

Mit Zunahme der Möglichkeiten von SAP Query als Berichtstool kann es aber auch zur Notwendigkeit kommen, dass eine bestehende Query nun von mehr als eine Benutzergruppe genutzt werden soll.

Zum Beispiel könnte eine Query die bisher von der Abteilung Kosten- und Leistungsrechnung in der Benutzergruppe CO genutzt wurde auch den Kolleginnen und Kollegen der Finanzabteilung in der Benutzergruppe FI weiter helfen.

Handelt es sich um eine Quickview kann dieses relativ einfach durch die Funktion "Quickview konvertieren" wie im Artikel "Tabellen doppelt im Infoset nutzen und Quickview in Query umwandeln" beschrieben erfolgen.
 

Exkurs: Konvertieren von QuickView
Hierzu kann in der Transaktion SQ01 in der aktiven Benutzergruppe über das Menü QUERY -> QUICKVIEW KONVERTIEREN eine bestehende Quickview selektiert werden und Infoset und Query dazu angelegt werden.

Nach Aufruf der Funktion "Quickview konvertieren" erscheint ein Auswahlfeld in der die Quickview und der Benutzer anzugeben ist. Nachdem damit die Quickview selektiert wurde kommt zur Konvertierung die Nachfrage nach Query und Infoset Bezeichnug. Beide werden dann in der Benutzergruppe angelegt in der die sich der User gerade in der SQ01 befindet. Wenn ich das richtig sehe besteht hier sogar die Möglichkeit eine Quickview eines anderen User direkt zu kopieren bzw. zu konvertieren.

Dieses dürfte auch beim Wechsel der Zuständigkeiten recht hilfreich sein, wenn benutzerbezogene Quickview künftig von der Nachfolge genutzt werden sollen.
 

Ähnlich komfortabel ist das Kopieren einer Query von einer Benutzergruppe auf die andere Möglich.

Hierzu muss im ersten Schritt das zugeordnete Infoset der Query (als Datengrundlage) in der Transaktion SQ02 über die Schaltfläche "Zuordnung zu Rollen/Benutzergruppen" der Zielbenutzergruppe zugeordnet werden.

Danach kann in der Pflege der Query über die Transaktion SQ01 die Schaltfläche "Kopieren.." oder alternativ die Taste F9 ausgewählt werden. Hierzu sollte aber vorher in die Zielbenutzergruppe, wohin die Query kopiert werden soll, gewechselt werden.

In unseren Fall wäre dieses über die Schaltfläche "BenGruppe wechseln" (alternativ die Tastenkombination UMSCH + F7) die Benutzergruppe FI der Finanzbuchhaltung.

Nach Aufruf der  Schaltfläche "Kopieren einer Query" kann in den Feldern Von die Query nd die Benutzergruppe frei eingegeben werden.

Im Feld Nach kann dann nur der neue Name der Query eingetragen werden, da die Benutzergruppe durch die aktiv gewählte Benutzergruppe vorbelegt ist.

Eine Werthilfe (F4-Auswahl) ist leider nicht vorhanden, so dass vorab der Name der Query und die Benutzergruppe sich gemerkt werden muss.

Zu Beachten ist dabei, dass weder Selektionsvarianten (Varianten zur Query) als auch Layoutvarianten kopiert werden. Dieses kann besonders dann ein Problem sein, wenn in der Query im Eisntiegsbild eine Variante als Standard und Plficht mit angegeben worden ist.

 

---

Hinweis:

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

---

Durch den Beitrag "SAP SQVI – diese Tipps solltest du dir nicht entgehen lassen." auf thinkdoforward.com bin ich auf die Möglichkeit der Funktion von Alias Tabellen aufmerksam geworden.

Das Beispiel im obigen Beitrag bezieht sich auf eine Auswertung im Bereich MM mit der Tabelle MARA, die an zwei Stellen verknüpft worden ist. Das Beispiel hat mich direkt an eine Problemstellung im CO erinnert.

Wenn ich die Tabelle COEP "CO-Objekt: Einzelposten periodenbezogen" verknüpfe ich für die Auswertung von Stammdaten die beiden Tabellen AUFK "Auftragsstammdaten" und CSKS "Kostenstellenstammsatz" als left outer join (1:N Beziehung).

Hier können einzelne Belege entweder die Stammdaten des Innenauftrages oder der Kostenstellen in der Einzelpostenliste in Form einer Query ausgewertet werden.

Im Berichtswesen zu den CO Einzelposten hätte ich gerne ergänzend zum Innenauftrag auch Daten aus den Stammdaten der verantwortlichen Kostenstelle des Innenauftrags mit auswerten (und sei es nur für die Anschrift der Professur).

Allerdings kann im Infoset in der Transaktion SQ02 eine Tabelle nur einmal verknüpft werden.

Alias Tabellen in SAP Query definieren

Wie erwähnt kann man diese Beschränkung in der Definition des Join (Transaktion SQ02 - > Schaltfläche "Join" (Join Definition oder STRG+UMSCH+F6) durch die Schaltfläche "Alias" (Alias-Tabellen definieren) eine Alias-Tabelle einfügen. Dabei wird dort der Tabellenname angegeben auf den Bezug genommen werden soll und ein Alias-Name definiert. So zum Beispiel ZCSKS zur Tabelle CSKS.

Über die Schaltfläche "Tabelle einfügen" kann dann genau diese Alias Tabelle erneut eingefügt werden und wie jede andere Tabelle auch verknüpft werden. Als Beispiel eben auch eine Verknüpfung des Feld AUFK-KOSTV mit ZSKS-KOSTL während die COEP-OBJNR sowohl mit AUFK-OBJNR als auch CSKS-OBJNR verknüpft sind.

Im Ergebnis ist diese Tabelle tatsächlich zweimal im Infoset verwendet worden.

SAP Quick View - Vorteile und Nachteile

Grundsätzlich bin ich tatsächlich ein Fan von SAP Query und nutze ungern den Quickview über die Transaktion SQVI. Teilweise kenne  ich dieses Tool aber aus den Bereich der Ad Hoc Auswertung im Bereich HCM. SAP Quickviewer (Transaktion SQVI) verbindet Benutzergruppe, Infoset und Query zu einer Transaktion, so dass hier kein Infoset angelegt werden muss sondern die Benutzer direkt eine Abfrage erstellen können.

In meinen Augen als Nachteil zu werten ist, dass der Quickview nur für den anlegenden Benutzer nutzbar ist, diese immer mandantenabhängig sind und keine Möglichkeit der Erweiterung durch Zusatzfelder (Berechnungen etc.) vorhanden sind.

Zumindest der erste Nachteil (nur für den anlegenden Benutzer) hat obiger Artikel durch eien Reporttransaktion oder direktes Starten des generierten Report einer Quick View elegant gelöst.

Umwandlung Quickview in SAP Query

Interessanterweise besteht aber tatsächlich auch die Möglichkeit einen Quickview in eine reguläre Query inklusive Infoset zu konvertieren.

Hierzu kann in der Transaktion SQ01 in der aktiven Benutzergruppe über das Menü QUERY -> QUICKVIEW KONVERTIEREN eine bestehende Quickview selektiert werden und Infoset und Query dazu angelegt werden.

Nach Aufruf der Funktion "Quickview konvertieren" erscheint ein Auswahlfeld in der die Quickview und der Benutzer anzugeben ist. Nachdem damit die Quickview selektiert wurde kommt zur Konvertierung die Nachfrage nach Query und Infoset Bezeichnug. Beide werden dann in der Benutzergruppe angelegt in der die sich der User gerade in der SQ01 befindet.
Wenn ich das richtig sehe besteht hier sogar die Möglichkeit eine Quickview eines anderen User direkt zu kopieren bzw. zu konvertieren.

Dieses dürfte auch beim Wechsel der Zuständigkeiten recht hilfreich sein, wenn benutzerbezogene Quickview künftig von der Nachfolge genutzt werden sollen.

Austausch mit SAP Blogs

Solche Artikel, die auch neue Ideen für die eigene Arbeit bringen und auf Funktionen hinweisen die man selbst nicht auf den Schirm hatte sind ein Grund warum ich gerade im Bereich SAP den Austausch mit anderen so wichtig empfinde und gerade Blogs aber auch Onlineforen ein wichtiger Bestandteil sind um hier aktuell sich selbst weiterzubilden aber auch eigene Erfahrungen sammeln zu können. Von daher auch hier einmal wieder vielen Dank an die SAP Menschen da draußen, die immer wieder neue Ideen bringen und auch bereitwillig ihr Wissen teilen oder aus den eigenen Nähkästchen plaudern können.

 

---

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.

---

Im Artikel "Query zur Auswertung von Klassifizierungsmerkmale PSM Fonds zu CO Innenauftrag und Datumsfelder mit Konvertierung von FLOAT zu DATUM" habe ich mich mit der Umwandlung von Gleitpunktzahl des Format FLOAT in Datum (DATE) beschäftigt. Zur Verdeutlichung noch einmal ein Datumswert der im Rahmen der Klassifizierung in der Tabelle  AUSP im Tabellenfeld ATFLV gespeichert ist:

Das Feld ATFLV hat als Eigenschaften Datentyp FLTP (interner Fließkomma-Wert) in der Länge von 16.

Zur Verdeutlichung des Problems rufe ich noch einmal die Ausgangslage des Problems in Erinnerung und habe ein Merkmal als Datum definiert und den gespeicherten Wert in der Tabelle AUSP näher angesehen:
 

Datum als Float

Datum	Wert als Float AUSP-ATFLV
01.01.2018	2,0180101000000000E+07
14.05.2017	2,0170514000000000E+07
13.07.2017	2,0170713000000000E+07

Nun stellt sich für die Query die Frage, wie aus den FLOAT Wert ein Datumswert ermittelt werden kann.

Hierzu hatte, nach der Nutzung von Funktionsbausteinen und verschiedenen anderen Methoden Wolfgang per Kommentar noch eine alternative Lösung gebracht.

Hallo Herr Unkelbach,
zu der Umwandlung von Float in Date gibt es noch eine weitere Alternative:

DATA: zlv_float type f value '2.006123100000000E+07',
text(10) type c.
write zlv_float to text Exponent 0.

Das Ergebnis ist dann ' 20161231'.
Wichtig das Ergebnisfeld muss 10 stellig sein.

Gruß Wolfgang

Vielen Dank an Wolfgang für diesen aber auch schon einige andere Hinweise zu Artikeln hier im Blog. Tatsächlich steckt in der Write Anweisung auch die Möglichkeit Werte umzuwandeln.

Die Anweisung EXPONENT legt den Exponenten bei der Aufbereitung von Gleitpunktzahlen bzw. einer Fließkommazahl fest. Wenn die Anweisung Exponent den Wert 0 enthält, wird kein Exponent erzeugt und somit die originäre Zahl erzeugt.

Matheamtisch enthält die Gleitpunktzahl gleichzeitig eine Information zur Anzahl der Nachkommastellen beziehungsweise der dargestellte wird mit 10^Exponent multipliziert.

In unseren Fall wäre dieses also 2,018010100000000 * 10⁷ was wieder 20180101 ergibt.

Die Verwendung der WRITE Funktion zur Umwandlung von Zahlenwerten in das gewünschte Format hatte ich auch im Abschnitt "Zusatzfeld VLE zur Darstellung virtueller Lehreinheit aus Teilstring der verantwortlichen Kostenstelle sofern nicht in einen anderen Feld ein Wert steht" im Artikel "Query über COEP, AUFK und FMFINCODE für Einzelposten Istkosten Innnenauftrag mit Stammdaten aus CO und PSM-FM sowie Spalten für Ertrag und Aufwand - Erster Teil Infoset als Datengrundlage" behandelt.

Durch den Zusatz NO-ZERO werden die vorrangestellten 000 eines Wertes entsprechend entfernt, so dass später mit der reinen Zahl ohne führender 0 gearbeitet werden kann.

Hierbei ist es jedoch hilfreich vorab zu prüfen, ob der Wert tatsächlich nur aus Zahlen besteht. Dieses ist im Artikel "Drittmittelstatistik nach LOMZ über Recherchebericht und SAP Query" durch die Anweisung

IF AUFK-AUFNR CO  '1234567890'.

im Abschnitt "LOMZ relevante Drittmittel" beschrieben worden.

Gerade beim Umgang mit Programmiersprachen gibt es oft mehrere Wege um ein Ergebnis zu erhalten und gerade die obige WRITE Anweisung eignet sich auch hervorragend dazu als Werte statt Text gespeicherte Klassifizierungsmerkmale wieder aufzulösen und entsprehcend lesbar in der Ausgabe zu machen.

Somit kann auch eine einfache WRITE Anweisung wesentlich mehr als

WRITE 'HELLO WORLD'.

Grundsätzlich ist das Thema ABAP Programmierung aber tatsächlich noch ein Punkt den ich gerne ausbauen würde und wo bei mir noch ein zwei Bücher im RUB stehen.

Für kleinere ABAP Anweisungen zum Beispiel im Rahmen einer SAP Query hilft oft schon der Austausch in Onlineforen, mit Kolleginnen und Kollegen und ein wenig die Webempfehlungen oder andere Blogs.

 

---

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 letztes Jahr (2016) einen externen Vortrag halten durfte (siehe "Vortrag Controlling Tipps aus der Praxis für die Praxis und die Espresso digitale SAP Bibliothek Flatrate") stand dieses Jahr im Rahmen einer Klausurtagung unserer Arbeitsgruppe ein Auffrischungsworkshop zum Thema SAP Query an.

Der Vortrag war auf 60 bis 90 Minuten konzipiert und ich hoffe tatsächlich, dass hier die teilnehmenden Kolleginnen und Kollegen ein wenig Know How mitnehmen konnten. Dankenswerterweise hatten sich auch schon einige Kolleginnen und Kollegen diesen Vortrag vorab angesehen, so dass ich die ein oder andere Anmerkung direkt umsetzen konnte.

Daneben hat sich dieser Vortrag auch angeboten, da durch die  "Buchveröffentlichung »Berichtswesen im SAP®-Controlling«" das Thema ohnehin aktuell war :-). Hier war neben SAP Query, Recherchebericht und Report Painter auch das Berichtswesen im SAP-Controlling selbst ein wichtiges Thema. So gesehen, war hier ein Part der im Artikel "Unterschiedliche Auswertungsmöglichkeiten im Controlling (Report Writer, Recherchebericht, SAP Query) und natürlich Excel ;-)" vorgestellten Möglichkeiten ausführlicher behandelt worden.

Im folgenden Beitrag möchte ich einen Überblick über die Abschnitte geben und gleichzeitig Hinweise auf weiterführende Artikel hier im Blog (insbesondere solche die ich auch als Praxisbeispiel mit angegeben habe) hinweisen.



Der Vortrag selbst ist dabei in folgende Abschnitte aufgeteilt worden:

1. Elemente SAP Query
2. Datenherkunft
3. Query Tabellen zu Transaktion
4. Felder, Formeln und Erweiterungen

Da es sich hier um eine Rückschau handelt gehe ich nur relativ kurz (ohne die Folien ebenfalls anzubieten) auf die Abschnitte ein und hoffe, dass diese Zusammenfassung als Unterlagen oder Ergänzung hilfreich sind, aber vielleicht auch für externe einen guten Überblick zum Thema SAP Query und Berichtswesen bieten können.

Elemente SAP Query

Der erste Abschnitt stellte die einzelnen  Bestandteile / Elemente der SAP Query dar.



Neben der Darstellung von Arbeitsbereich, Benutzergruppe, Infoset und Query wurden dabei auch Namenskonventionen sowie der Unterschied zwishcen Grafischer Join/Query Definition und der "alten" Oberfläche dargestellt.

Gerade bei der SAP Query ist ein wichtiger Punkt auch die unterschiedlichen Ausgabeformate von SAP List Viewer, ABAP Liste oder auch Anzeige als Tabelle.

Am Rande ist hier auch auf das Thema Dokumentation von Infoset und Query eingegangen worden, was gerade beim gemeinsamen Entwickeln ein wesentlicher Faktor ist.

Datenherkunft

Wie schon in im Artikel "Grundlagen Kurzeinführung und Handbuch SAP Query" erwähnt ist eine wichtige Aufgabe beim Erstellen von Auswertungen die Frage, wo einzelne Daten gespeichert sind.

Dabei sind folgende Methoden vorgestellt worden:

1. Technische Informationen zum Feld (F1 Hilfe zum Datenfeld)
2. Transaktion SE12 Tabelle anzeigen
   • Inklusive der Tabellensuche über das Infosystem und des Anwendungsbaum innerhalb der Transaktion (F4-Werthilfe)
   • Graphischer Darstellung der Tabellenverknüpfung
   • Verwendungsnachweis der einzelnen Felder in Tabellen, Join und Programmen
   • Auswertung von Tabellen mit der Transaktion SE16H (und Bezug zu SETS/Gruppen)
3. Logische Datenbanken (Transaktion SE36)
   • Beispiele waren:
     • ADA - Anlagenbuchhaltung
     • BRF - Belegdatenbank
     • PNP - Personalstammdaten
     • PCH - Personalplanung
     • FMF - Haushaltsmanagement - klassische Budgetierung
     • FMB - Haushaltsmanagement auf BCS
4. Websuche
5. Query Tabellen zu Transaktion

Bei der Websuche habe ich einige der mir bekannten und immer noch hilfreichen Internetseiten rund um SAP Query und der Suche von Tabellen zusammengestellt.

Im Einzelnen sind dieses:

• https://www.dv-treff.de/sap-tabellen/uebersicht1
  Verzeichnis SAP Tabellen nach Modulen.
• http://www.rcmoconsulting.de/educsap.php
  Schulungsunterlagen zu Tabellen und Tabellenbeziehungen innerhalb SAP
• http://www.stichpunkt.de/sap/tabellen.html
  Weitere Übersicht über wichtige Tabellen in SAP
• https://www.berater-wiki.de/SAP-Tabellen_und_Strukturen 
  SAP WIKI Abschnitt über Tabellen und Erläuterungen zu SE11
• http://fico-forum.de/Query.php
  Videotutorials zu SAP Query

Was ich im Vortrag nicht erwähnt hatte war noch ein Youtube Channel von ZLEX.DE der webenfalls einige Videos zu SAP Query anbietet.

• https://www.youtube.com/user/ZLexConsult/
  ZLexConsult  Video zu SAP Query

In meiner eigenen Suchmaschine sind ebenfalls einige dieser Quellen eingebunden, so dass durch die Seite

www.andreas-unkelbach.de/websuche.php

ebenfalls eine Menge an Internetquellen durchsucht werden können, so auch mein Blog ;-).

Query Tabellen zu Transaktion

Als "Hausaufgabe" bzw. praktische Übung wurde folgende Auswertung erstellt.




Statt einer umfangreichen Query mit Coding und Speziallösungen sollte das Praxisbeispiel gleichzeitig auch ein Toll sein, dass zur Identifikation von Tabellen zu Programmen und Transaktionen nützlich ist.

Im Artikel "Tabellen hinter Transaktionscode oder ABAP Programm über eine SAP Query ermitteln" ist der Aufbau der Query erläutert und da diese Auswertung sowohl Tabellen, Strukturen und einen Join unterschiedlicher Tabellen beinhaltet bietet sich diese sehr gut an um einen Überblick über den Aufbau eines Infoset, Grundliste einer Query sowie andere Themen zu bieten.

Felder, Formeln und Erweiterungen

Neben einer reinen Betrachtung von Tabelleninhalten besteht in SAP Query aber auch die Möglichkeit mit den Daten zu arbeiten. Hierzu wurden einige Beispiele gezeigt ohne die dahinter liegenden Auswertungen näher zu erläutern. Sofern Interesse an der Auswertung selbst besteht möchte ich zu den einzelnen Punkten die relevanten Artikel ebenfalls verlinken.

Zum Erweitern einer SAP Query nutze ich Beispiele aus folgende Bereiche:

1. Lokales Feld innerhalb SAP Query
2. Zusatztabellen im Infoset
3. Zusatzfelder im Infoset

Lokales Feld in SQ01 SAP Query

Innerhalb der Transaktion SQ01 können einzelne Wertfelder eine Kurzbezeichnung erhalten und diese können dann auch bearbeitet werden.

Als Beispiel wurden hier die einzelnen Periodenwerte aus der Tabelle COEJ genommen und diese addiert.

Hintergrund der Auswertung und Summierung von Feldern ist im Artikel "CO Planeinzelposten Objekt und Partnerobjekt auswerten / Mehrere Felder summieren" beschrieben worden.

Nach der einfachen Addition oder anderer Rechenoperationen wurde auch das Thema ICONE besprochen durch die eine Kontrolle einzelner Werte möglich ist.

Auch dieses beruht auf zwei hier im Blog beschriebene Beispiele:

• Query Stammdaten CO Kontrolle Verantwortliche
• Query Stammdatenvergleich Profit-Center und Auslesen von Textbestandteilen (Teilstring aus Variable)

Auch die Unterscheidung von Werten anhand der Kostenart/Finanzposition ist in folgenden Artikeln behandelt worden:

• Salden je Finanzposition mit Unterscheidung Personal oder Sachaufwand aus PSM-FM durch Query über logische Datenbank FMF
• Query Einzelpostenliste Innenauftrag mit Ausweis Ertrag und Aufwand Zweiter Teil Query zur Datenaufbereitung

Wobei besonders der zweite Artikel schon umfangreicher ist.

Zusatztabelle (SQ02 – Infoset) Erweiterung Infoset um  Zusatztabelle

Hier ist als nachvollziehbares Beispiel die Zustztabelle zum Ausweis der IBAN genutzt worden. Im Artikel "Query über IBAN und Stammdaten Kreditor oder Debitor (Zusatztabellen in SAP Query)" ist nicht nur der Hintergrund erläutert sondern auch auf Änderungen im Rahmen von S/4 HANA hingewiesen worden.

Insgesamt zeigt sich hier aber, dass solche Tools auch die Zusammenarbeit zwishcen FI und CO verbessern.

Zusatzfeld (SQ02 – Infoset) Erweiterung inkl. ABAP Coding vom Infoset um  Zusatzfeld

Das Thema Zusatzfelder ist dann tatsächlich schon etwas komplexer, bietet aber auch mehr Möglichkeiten.

Ein wichtiges Beispiel ist hier die Frage, ob ein CO-Objekt (hier: Innenauftrag) gesperrt ist.

Die Auswertung der Systemstatus ist im Artikel "SAP Query: Systemstatus CO Innenauftrag" erläutert. Da nun aber nur in einen Feld ausgegeben werden soll, ob der Innenauftrag gesperrt ist bedarf es etwas Coding. Darauf ist auch im Artikel "Darstellung einzelner Projektphasen von der Freigabe bis zum Abschluss eines Innenauftrags anhand einer Query mit Ausgabe GESPERRT aber auch Abschlussdatum" Bezug genommen worden.

Das Coding zum Zusatzfeld ist im Artikel "SAP Query ABAP Coding im Zusatzfeld für Verknüpfung Innenauftrag und Fond bzw. Finanzierungszweck oder auch Status GESPERRT bei Innenaufträgen" zu finden.

Die einzelnen Bestandteile des Coding sind in folgender Folie erläutert:



Dabei ist schon ersichtlich, dass Zusatzfelder tatsächlich noch weitere Informationen auslesen können.

Ebenso kann auch ein vorhandener Stammdatenschlüssel (Innenauftragsnummer) übersetzt werden, wenn hier eine sprechende Logik hinterlegt ist. Dieses ist ausführlich im Artikel "Auswertung sprechender Nummernkreisintervalle von CO Innenaufträgen mit Query Zusatzfeldcoding und Unterscheidung numerischer oder alphanumerischer Schlüssel" behandelt worden.

CO und PSM verknüpfen

Ein anderes wichtiges Thema ist noch die Frage, wie Innenauftrag AUFK-AUFNR mit 12 Zeichen und Fond FMFINCODE-FINCODE mit 10 Zeichen miteinander verknüpft werden können.

Im Artikel "Query zur Auswertung von Klassifizierungsmerkmale PSM Fonds zu CO Innenauftrag und Datumsfelder mit Konvertierung von FLOAT zu DATUM" ist nicht nur das Coding für die Auswertung von Klassifizierungsmerkmale sondern auch die Vorgehensweise mit dem Zusatzfeld ZAUFNR zur Verknüpfung der Stammdatentabelle AUFK mit FMFINCODE erläutert.

Die Feldlänge von FMFINCODE-FINCODE (10 Zeichen) und AUFK-AUFNR  (12 Zeichen) lassen sich nicht miteinander verbinden. Dabei sind Innenauftrag und Fond eigentlich identisch (von der Länge aber auch der Nummer her).

Durch folgendes Coding kann ein Feld mit den gleichen Eigenschaften zu FMFINCODE-FINCODE angelegt werden um dieses Feld dann zur Verknüpfung einer Zusatztabelle oder auch zur Auswertung von Klassifizierungsmerkmale genutzt werden:

DATA L_AUFNR  type i.
DATA L_OFFSET type i.

* Tragen Sie hier die Länge ihrer Projektnummer ein
* Standard:  8 stellige Auftragsnummer

L_AUFNR = 8.

* Nun wird die Position im Feld AUFK-AUFNR ermittelt
* ab der die Projektnummer ohne 0 gespeichert ist.

L_OFFSET = 12 - L_AUFNR.

* Maximial 12 Zeichen sind in AUFK-AUFNR vorhanden

ZAUFNR = AUFK-AUFNR+L_OFFSET(L_AUFNR).

Welche Möglichkeiten mit dieser Zusatztabelle bestehen ist zum Beispiel im Artikel "Gruppierung von Finanzierungszwecken bei Drittmittelprojekten per Zusatzfeldcoding mit IF oder CASE" zu sehen.

Ebenso kann die Bewertung, ob ein Fond LOMZ-fähig ist hier hinterlegt werden. Dieses ist im Artikel "Drittmittelstatistik nach LOMZ über Recherchebericht und SAP Query" erläutert.

Eine ausführliche Serie einer PSM/CO Auswertung ist im Artikel "Query über COEP, AUFK und FMFINCODE für Einzelposten Istkosten Innnenauftrag mit Stammdaten aus CO und PSM-FM sowie Spalten für Ertrag und Aufwand - Erster Teil Infoset als Datengrundlage" zu finden. Jedoch dürften hier im Blog immer einmal wieder neue Artikel auftauchen.

Weitere Beispiele: SAP Query im Umfeld SAP Rechnungswesen Finanzwesen und Controlling

Als kleine Zugabe bin ich noch kurz auf einige kleine Beispiele von häufiger genutzten Query eingegangen.

Diese sind in folgenden Artikeln beschrieben:

• Query Kontenplan für Module CO, FI und PSM
• Auflösen von Stammdatengruppen nach Einzelwerten - Einzelwerte zu Sets
  • Hier kann auch "Änderungsbelege für Stammdatengruppen im Customizing oder letzte Änderung über Query bspw. für Innenauftragsgruppen" nützlich sein
• Abrechnungsvorschriften von Innenaufträgen auf identische verantwortliche Kostenstelle und empfangende Kostenstelle per Query mit Ampelfunktion prüfen

Insgesamt hoffe ich mit der Präsentation den Kolleginnen und Kollegen einen guten Überblick über die Verwendung von SAP Query in den Modulen Finanzwesen, Controlling und Haushaltsmanagement gegeben zu haben.



Da wir SAP Query auch als ein zentrales Instrument im Berichtswesen nutzen, möchte ich an dieser Stelle auf mein aktuelles Buch »Berichtswesen im SAP®-Controlling« hinweisen, dass ebenfalls SAP Query neben Report Painter und Rechercheberichte und natürlich allgemein hilfreiche Empfehlungen zum Berichtswesen im SAP Controlling anbietet.

Dieses ist auch bei Amazon * zu finden.



ISBN: 978-3960127406 *
 

Fazit Ziel des Vortrages

Ziel der Veranstaltung war es im Rahmen eines "Auffrischungsworkshops" das Thema SAP Query im Hochschulberichtswesen, Hochschulcontrolling noch einmal ins Bewustsein zu rufen. Auch wenn als Zielpublikum die unterschiedlichen Kolleginnen und Kollegen aus Hochschulcontrolling zugegen waren habe ich mich darum bemüht die Beispiele und Erläuterungen so allgemein zu halten, dass die Schulung eine Hilfe zur Selbsthilfe bieten konnte und die Unterlagen dazu einladen später am eigenen System zumindest die Beispielquery nachzubauen.

Ansonsten stehen noch weitere Optionen zur Verfügung.


Im Artikel "Unterschiedliche Auswertungsmöglichkeiten im Controlling (Report Writer, Recherchebericht, SAP Query) und natürlich Excel ;-)" sind diese beispielhaft dargestellt.


Ergänzend mag ich hier noch auf "SAP Know How" in Form der digitalen SAP Bibliothek mit allen Büchern meines Verlages hinweisen, als auch auf die kommende Veranstaltung der FICO Forum Infotage im November. Diese sind im Artikel "FI CO Forum Infotage 2017 und digitale SAP-Fortbildung für Studenten und Hochschulbeschäftigte" vorgestellt.

Ich hoffe, dass dieser Blogartikel noch als Quellennachweis für einige Folien hilfreich ist und freue mich über etwaiges Feedback oder weiteren spannenden Austausch rund um die Themen SAP im Allgemeinen und Hochschulberichtswesen im Besonderen.
 

---

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.

---

Manchmal kann es hilfreich sein im Selektionsbild einer Query einen Wer zu übergeben um mit diesen dann innerhalb der Query zu arbeiten.

Hierzu möchte ich zwei Möglichkeiten vorstellen ohne tiefer auf die Beispiele einzugehen sondern nur um die Herangehensweise zu schildern.

Im Ergebnis kann beim Ausführen einer Query über ein Selektionsfeld ein Wert mitgegeben werden und dieser weiter verarbeitet werden. Diese Weiterverarbeitung ist noch einmal ein Thema für sich, aber die Arbeit mit Abfrageparametern innerhalb einer SAP Query kann für viele Berichtsanforderungen nützlich sein. Dieses ist der Grund, dass ich die beiden Möglichkeiten hier gerne festhalten möchte.
 

1. Möglichkeit: SAP Query und Lokales Feld Eingabe auf dem Selektionsbild

Handelt es sich um ein Feld in das lediglich eine Eingabe erfolgen soll (Wert eingetragen) oder wenn das Selektionsfeld auch in der Liste der Query selbst genutzt werden soll, bietet sich ein LOKALES FELD an, dass statt einer Berechnungsvorschrift die Option "Eingabe auf dem Selektionsbild" erhält. Dadurch landet das Feld in der Selektionsmaske und es kann ein entsprechender Wert eingetragen werden.

Sofern das Feld eine Referenz über "gleiche Eigenschaften wie Feld" erhält kann hier auch die F4-Werthilfe zum Auswahl eines Feldes genutzt werden.

Denkbar ist hier die im Artikel "Abrechnungsvorschriften von Innenaufträgen auf identische verantwortliche Kostenstelle und empfangende Kostenstelle per Query mit Ampelfunktion prüfen" beschriebene Ursprungszuordnung  zu verwenden und statt ZUK direkt in der Berechnungsvorschrift zu verknüpfen durch das lokale Feld hier Ursprungszuordnung ZUK im Selektionsfeld einzutragen und die Übereinstimmung der verantwortlichen Kostenstelle des Innenauftrag und das Feld empfangende Kostenstelle (COBRB-KOSTL) zu überprüfen.

Wird ZUK nicht eingegeben (das Selektionsfeld bleibt leer) erfolgt dann die Prüfung mit allen Abrechnungsvorschriften. Um dieses zu umgehen kann auch die Option OBLIGATORISCH gesetzt werden, wodurch eine Eingabe auf jeden Fall erfolgen muss.

2. Möglichkeit Infoset Definition von Abgrenzungsparameter und Zusatzfeld

Statt in der Query per lokales Feld besteht auch die Möglichkeit ein Zusatzfeld innerhalb eines Infoset mit einer Selektion zu versehen. Hierzu kann die Möglichkeit der Abgrenzung

Hierzu sind jedoch zwei Schritte erforderlich.

Abgrenzungsparameter anlegen

Im Infoset (Transaktion SQ02) können über die Schaltfläche ZUSÄTZE nicht nur Zusatztabellen und Zusatzfelder  angelegt werden sondern es besteht auch die Möglichkeit über das Register Abgrenzung eine Abgrenzung für das Infoset anzulegen.

Vergleichbar zum Zusatzfeld kann nun ein Name vergeben werden und als Optionen stehen Selektionskriterium und Parameter zur Verfügung. Als Selektionskriterium kann direkt Bezug auf ein Tabellenfeld genommen werden und auch mehrere Werte selektiert werden.

Für dieses Beispiel soll jedoch ein einzelner Wert eingetragen werden (bspw. Kontengruppenname oder ein anderes Stammdatumsmerkmal, dass nicht in der Query selbst, aber innerhalb einer Prüfung einer Berechnungsvorschrift in der späteren Query eingebunden ist).

Daher kann hier die Option PARAMETER gewählt werden. Als Name soll ZP_SYF gewählt werden.

Nachdem NAME und die Option PARAMETER gewählt worden ist, können die Eigenschaften des Parameterfeldes definiert werden.

Natürlich kann hier neben Bedeutung und Selektionstext auch das Format TYP und LÄNGE definiert werden, aber auch per LIKE Bezug auf ein Tabellenfeld genommen werden.

Exkurs Hilfstabellen und Zusatzfelder per Userexit

In diesem Beispiel haben wir eine Hilfstabelle ZHFS_SYF für Systemfinanzierungscodes der Hochschulfinanzstatistik und das Feld  ZSYF in der die einzelnen Systemfinanzierungscodes gepflegt sind.

Diese Hilfstabelle wird als kundeneiegenes  Zusatzfeld ist für die Kostenart über den Userexit COOMKA01 genutzt (siehe Artikel "Stammdatenerweiterung von CO-Objekten am Beispiel ergänzende Kostenstelle beim Innenauftrag").

Im Artikel "Auswertung per CMOD eingeführter kundeneigener Felder Kostenart, Kostenstelle und Innenauftrag per Stammdatenverzeichnis und SAP Query" habe ich auch die Auswertung dieser Felder per Query beschrieben.

Um diese Tabelle später zu pflegen, oder zu erweitern kann diese über die Transaktion SM30 gepflegt werden. Hier hat RZ10.de jedoch eine wesentlich komfortablere Lösung vorgestellt, die im Artikel "Wie Sie eine Parametertransaktion für die SM30 anlegen" beschrieben ist.

ABAP Grundlagen Tabelle anlegen

In seiner Serie zum Thema ABAP Grundlagen erläutert Denis Reis im Artikel "Wie Sie eine SAP Tabelle anlegen" sehr ausführlich, wie kundeneigene Tabellen angelegt werden.

Dieses aber nur am Rande und als kleine Leseempfehlung und Exkurs.

In unseren Fall geben wir also den Parameter per LIKE die gleichen Eigenschaften wie das Tabellenfeld Z_HFS_SYF-ZSYF (Feld ZSYF der Tabelle Z_HFS_SYF).

Damit ist das Feld als Selektionsfeld beim Infoset verfügbar und per F4 können die einzelnen SYF-Codes (Werte aus der Tabelle Z_HFS_SYF für das Feld ZSYF) selektiert werden.

Als Bedeutung und Selektionstext wählen wir die "SyfCode Auswertung (Variante)"

Nun soll aber mit den selektierten Wert in der Query weiter gearbeitet werden.

Zusatzfeld mit Bezug zu Abgrenzungsparameter

Nachdem der Abgrenzungsparameter ZP_SYF angelegt worden ist, kann ein Zusatzfeld angelegt werden, dass den Wert des Paramteres erhalten soll.

In unseren Fall ist dieses ein Zusatzfeld mit den Namen ZSEL_SYF und ebenfalls LIKE Z_HFS_SYF-ZSYF . Wobei hier nur die Feldeigenschaften vererbt werden. Als Langtext und Überschrift soll dieses "Syf Code Auswahl" erhalten.

Über die Schaltfläche CODING wird nun folgendes Coding hinterlegt:
 

CLEAR ZSEL_SYF.
ZSEL_SYF = ZP_SYF.

In der ersten Zeile wird der Inhalt des Zusatzfeldes geleert und danach mit den Inhalt des Abgrenzungsparameter gefüllt. Dieses Zusatzfeld kann in der Query dann als Selektionskriterium wie auch andere Zusatzfelder verwandt werden. Der Vorteil dabei ist, dass hier, obgleich der SYF Code an keiner anderen Stelle eingebunden ist, mit diesen Selektionsfeld gearbeitet werden kann und es auch als Bedingung für lokale Felder in der Query genutzt werden kann.

Natürlich kann dieses Feld auch für andere Zwecke genutzt werden. Denkbar ist es hier im Coding eines Zusatzfeldes per Parameter einen Preis je Stunde zu übergeben und über die Auswertung eines Sachkonto mit Personalkosten zum Beispiel für eine bestimmte Personengruppe hier aus den gebuchten Personalkosten die geleisteten Stunden zu berechnen.
 

Fazit

Beide vorgestellten Methoden haben ihre Vorteile und Nachteile. Während die Eingabe auf Selektionsfeld für lokale Felder schnell umgesetzt ist, ist die Option per Parameter und Zusatzfeld wesentlich flexibler und ermöglicht einige andere Möglichkeiten der Auswertung.

So ist es auch nicht weiter verwunderlich, dass bestehende Query und Infoset durch solche neu entdeckten Möglichkeiten tatsächlich weiterentwickelt werden können.

Gerade im Berichtswesen ist dies einer der Punkte, die eine Weiterentwicklung gleichzeitig auch sehr spannend macht und zeigt, dass auch im Berichtswesen vieles sich weiter zu entwickeln vermag.

Persönlich freue ich mich immer wieder darüber, wenn ein Austausch in diese Richtung möglich ist und sich das gegenseitige Lernen und der Austausch von Wissen und Erkenntnisse so im beruflichen Alltag bewährt.
 

---

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.

---

Ein Thema, dass mir sowohl im Blog als auch im beruflichen Alltag am Herzen liegt, ist das Thema Berichtswesen mit SAP.  So hat sich schon kurze Zeit nach der Buchveröffentlichung »Schnelleinstieg ins SAP® Controlling (CO)« gezeigt, dass neben technischer Möglichkeiten auch immer die Konzeption von Berichten und die Beziehung zwischen Sender und Empfänger eines Berichtes relevant sind.

So ist dann relativ zeitnah die Idee zum neuen Buch entstanden, dass die Möglichkeiten zum Aufbau eines internen Berichtswesen im SAP Modul Controlling beschreibt. Dabei werden sowohl vorhandene Berichte vorgestellt als auch einige praktische Kniffe zum Berichtswesen beschrieben und auch die Entwicklung eigener Berichte sei es mit Report Painter, Rechercheberichte oder auch SAP Query vorgestellt.

In guter Tradition hat mich ein Kollege schon auf das Titelbild angesprochen, dass nun nach Erbsen ein realistisches Tortendiagramm darstellt.
 
Paperback ISBN: 9783960127406

Für 19,95 € direkt bestellen

Oder als SAP Bibliothek-Flatrate *



Dieses Diagramm sieht allerdings nicht nur nett anzusehen aus sondern zeigt auch einen weiteren Punkt der im Buch behandelt wird. Eine wichtige Frage ist auch wie diese Berichte den einzelnen Usern zur Verfügung gestellt werden und wo sowohl ein Informationssystem in Form eines Management-Cockpits für die einzelnen Verantwortungsbereiche zur Verfügung stellen, um an einer zentralen Stelle alle Informationen sammeln und direkt auswerten zu können. Diese Informationen sind nicht nur für die Unternehmensleitung und das Management, sondern auch für andere Verantwortliche im Unternehmen relevant.

Mein erster Blick ins Buch hat mich tatsächlich begeistert, was unschwer am Bild zu sehen ist.


Persönlich bin ich sehr zufrieden das Ergebnis in Händen zu halten und bin tatsächlich außerordentlich begeistert vom Ergebnis. Mein Buch richtet sich an erfahrenere Beschäftigte im Bereich Controlling, die im SAP-Modul CO ein Berichtswesen aufbauen oder erweitern wollen. Daneben können einzelne Beispiele nicht nur für Key-User, sondern auch für fortgeschrittene Sachbearbeiter im Controlling nützlich sein, um für regelmäßig genutzte Berichte kleinere Kniffe zur Arbeitserleichterung zu liefern. Die einzelnen Berichtsanforderungen sind im Buch so allgemein gehalten, dass es damit möglich sein sollte, die vorgestellten Methoden auf eigene Berichtsanforderungen zu übertragen bzw. als Grundlage zur Entwicklung eines eigenen Berichtswesens zu verwenden.

Ich würde mich sehr über ein entsprechendes Feedback freuen sei es hier im Blog, auf Amazon oder auch per Mail.

Sollte ich ein wenig Neugierde auf dieses Buch entfaltet haben, verweise ich gerne auf meine Seite Veröffentlichungen wo meine bisherigen Veröffentlichung aufgelistet sind sowie auf die Seite "Internes Berichtswesen im SAP ERP Modul Controlling (CO)" auf der eine ausführliche Rezension zum Buch »Berichtswesen im SAP®-Controlling« zu finden ist.

Das Thema Klassifizierung scheint etwas zu sein, dass gerade im Modul PSM-FM (Public Sector Management - Funds Management / Haushaltsmanagement) zur Erweiterung von Stammdaten genutzt werden kann und von mir in den Grundlagen im Artikel "SAP Query - Auswertung Merkmale der Klassifizierung am Beispiel Fonds in PSM-FM" inklusive eines kurzen Exkurs zum Anlegen von Klassen und Merkmalen beziehungsweise allgemein zum Thema Klassifizierung beschrieben worden ist.

Hier hatte ich über ein Zusatzfeld OBJNFOND aus Finanzkreis und FOND eine Auswertung der Klassifizierungsmerkmale beschrieben, so dass die einzelnen Felder der Tabelle CABN

In diesen Artikel habe ich über ein Zusatzfeld OBJNFOND aus Finanzkreis und einen Zusatzfeld FONDS, dass aus der CO-Innenauftragsnummer die Nummer des PSM Fond bildet, die PSM Objektnummer erstellt um hier einzelne Merkmale aus den Tabellen CABN "Merkmal" in der die einzelnen Merkmale gespeichert sind und AUSP  "Ausprägungswerte der Sachmerkmale" in der  zum Objekt (Fond) die Werte der einzelnen Merkmale gespeichert sind auswertete.

Im Rahmen des Artikel "Query über COEP, AUFK und FMFINCODE für Einzelposten Istkosten Innnenauftrag mit Stammdaten aus CO und PSM-FM sowie Spalten für Ertrag und Aufwand - Erster Teil Infoset als Datengrundlage" hatte ich das Coding und die Zusatzfelder noch ein wenig optimiert allerdings war hier noch der Nachteil vorhanden, dass die entstandene Query fest den Finanzkreis hinterlegt hatte und so nicht an andere Einrichtungen übertragen werden konnte.

Daher möchte ich in diesen Artikel noch einmal das Thema Verknüpfung von CO Innenauftrag und PSM Fonds sowie die Auswertung der Klassifizierung angehen um danach auf eine Besonderheit einzugehen, sofern es sich beim Merkmal um ein Datumsfeld handelt.

Verknüpfung von CO Innenauftrag und PSM Fond

Statt wie im ersten Artikel beschrieben ein kompliziertes Feld OBJNFOND anzulegen ist es wesentlich leichter mit den Zusatzfeld ZAUFNR zu arbeiten. Dieses hat gleichzeitig den Vorteil, dass die Stammdaten des Fonds problemlos als Zustztabelle eingebunden werden können.

Wie schon in den anderen Artikeln erwähnt sind die beiden Stammdatentabellen von CO Innenaufträgen (AUFK) und PSM Fonds (FMFINCODE) nicht über die Auftragsnummer beziehungsweise Fond verknüpfbar. Hintergrund ist, dass das Feld AUFK-AUFNR  in der Datenbank als Character mit 12 Zeichen und das Feld FMFINCODE-FINCODE als Character mit 10 Zeichen definiert ist.

Im zweiten Artikel wurde hierfür das Zusatzfeld ZAUFNR angelegt um aus der Innenauftragsnummer eine kompatibles Feld zum Fond zu machen.

Hierzu wurde das Zusatzfeld ZAUFNR mit per LIKE-Referenz FMFINCODE-FINCODE erstellt was in den folgenden Abschniten als Hilfsfeld genutzt werden kann. Nun muss "nur" noch die Auftragsnummer in dieses Feld zugewiesen werden.

Da auf Fond und Innenauftrag Drittmittelprojekte abgebildet werden, ist es das Ziel die Projektnummer vom Innenauftrag auch als Fond zu verwenden. Dazu möchte ich zwei Möglichkeiten für das Zusatzfeldcoding darstellen.

ZAUFNR mit fester Länge der Projektnummer des Innenauftrag

Für eine achtstellige Projektnummer (Innenauftrag) lautet das Coding wie folgt:

ZAUFNR = AUFK-AUFNR+4(8).

Hierbei bedient sich das Coding der Technik eines Offsets.

Durch die optionalen Angaben eines Offsets +<o> und eine Länge (<l>) direkt hinter dem Feldnamen <f>, wird der Teil des Felds, der auf Position <o>+1 beginnt und die Länge <l> hat, als eigenes Datenobjekt angesprochen.  In unseren Fall wird also für die Variable ZAUFNR das Feld AUFK-AUFNR (wir erinnern uns die zwölfstellige Auftragsnummer) eingelesen und ab der vierten Stelle insgesamt acht Stellen eingelesen. Da in der Datenbank die Auftragsnummer mit führenden 0000 hinterlegt wird erhalten wir also statt des Datenbankwerte 000012345678 die tatsächliche Auftragsnummer 12345678.

ZAUFNR mit festzulegender Länge der Projektnummer

Sollten Sie eine andere Länge bei den Aufträgen oder Fonds definiert haben ist das Coding natürlich entsprechend anzupassen.

Damit hier nicht selbst die Länge und Position für die Offsetermittlung errechnet werden muss habe ich hier das Coding wie folgt angepasst:

DATA L_AUFNR  type i.
DATA L_OFFSET type i.

* Tragen Sie hier die Länge ihrer Projektnummer ein
* Standard:  8 stellige Auftragsnummer

L_AUFNR = 8.

* Nun wird die Position im Feld AUFK-AUFNR ermittelt
* ab der die Projektnummer ohne 0 gespeichert ist.

L_OFFSET = 12 - L_AUFNR.

* Maximial 12 Zeichen sind in AUFK-AUFNR vorhanden

ZAUFNR = AUFK-AUFNR+L_OFFSET(L_AUFNR).

Damit kann durch Zuweisung eines Zahlenwertes die Position ab der die Projektnummer gespeichert ist direkt ermittelt werden.

Grundsätzlich könnte die Länge der Projektnummer als Variable L_AUFNR natürlich auch als Abfrageparameter, vergleichbar zum Artikel "Neue Wertgrenze für Investitionen bei Finanzstatistik oder Abfrageparameter in SAP Query zur Übernahme von Werten aus Selektionsbild" abgefragt werden, jedoch muss für das spätere Ergänzen der Klassifizierungsmerkmale hier ohnehin das Coding angepasst werden und in der Regel ändert sich die Länge der Projektnummer nicht, so dass diese als Selektionsparameter nur zur Verwirrung und möglichen Fehler führen würde.

Stammdaten Fond ergänzen per Zusatztabelle FMFINCODE

Durch das Zusatzfeld ZAUFNR ist es uns nun wesentlich einfacher möglich die Stammdaten der Fonds aus der Tabelle FMFINCODE ergänzend zur CO Stammdatnetabelle AUFK für die Innenaufträge mit ins Infoset aufzunehmen.

Ein wichtiger Punkt ist dabei die Reihenfolge der Codingabschnitte.

Beim Hinzufügen eines Zusatzfeldes oder einer Zusatztabelle kann am Punkt  Reihenfolge des Codeabschnitts gewählt werden. Auch wenn die Hilfe nicht in diese Richtung zu lesen ist, verstehe ich den Punkt so, dass wenn man Bezug auf vorab definierte Zusatzfelder nehmen möchte die hier nutzenden Felder im nachgeordneten Codeabschnitt liegen sollten.

Da ich in beiden kommenden Fällen mit den neu angelegten Feld ZAUFNR gearbeitet werden soll, werden beide kommenden Fälle im Codabschnitt 2 hinterlegt.

Zusatztabelle FMFINCODE

Anstatt eines Zusatzfeld kann im Register Zusätze über die Schaltfläche ANLEGEN auch eine ganze Tabelle eingefügt werden. Hierzu tragen wir als Name FMFINCODEfür die Stammdatentabelle der Fonds ein und wählen als Art der Zusatzinformation die Option ZUSATZTABELLE..

Im Feld "Reihenfolge des Codeabschnitts" wird nun eine 2 aus den geschilderten Gründen eingetragen.

Hintergrund ist dass erst das Feld ZAUFNR definiert sein soll, bevor Sie mit der Zusatztabelle arbeiten.

Nun erfolgt eine Abfrage über SELECT SINGLE * FROM FMFINCODE WHERE ...
in der folgedene (hervorgehobene) Bedingungen erfüllt sein sollen.

WHERE FIKRS  =  AUFK-BUKRS

da Finanzkreis und Buchungskreis identisch sind, können hier beide Felder sowohl in der Tabelle AUFK als auch FMFINCODE verwendet werden.

AND FINCODE = ZAUFNR

Hierdurch werden dann tatsächlich Fonds und Innenauftrag miteinander verknüpft und es steht die gesamte Tabelle FMFINCODE im Infoset zur Verfügung.

Klassifizierungsmerkmal aus AUSP auswerten

Bisher bin ich bei Klassifizierungsmerkmalen so verfahren, dass ich anhand ATINN den gespeicherten Merkmalswert aus der Tabelle AUSP ausgelesen habe und entsprechend mit ausgegeben habe.

Welche Merkmale sind vorhanden?

Die einzelnen Merkmale sind in der Tabelle CABN hinterlegt und werden über das Feld ATINN mit der Tabelle AUSP mit entsprechenden Inhalten verknüpft.
Entsprechend ist es Möglich für jedes Merkmal ein eigenes Zusatzfeld anhand der Merkmalsnummer (ATINN) zu erstellen.Die entsprechenden Einzelmerkmale können hierbei bspw. mit der Transaktion SE16 und der Auswertung der Tabelle CABN betrachtet werden.

Eines dieser Merkmale ist die Projektbewertung PBW.

Hierzu wird ebenfalls ein Zusatzfeld mit der Bezeichnung PBW für Projektbewertung mit Langtext und Überschrift Projektbewertung erstellt.

Dieses hat als Eigenschaften eine LIKE-Referenz auf AUSP-ATWRT.

Ferner wird im unteren Abschnitt des Fenster bei Reihenfolge des Codeabschnitts ebenfalls eine 2 eingetragen.

Danach wird als Coding zum Zusatzfeld ein passendes Coding zum Zusatzfeld hinterlegt, dass aus der Variable (Zusatzfeld) ZAUFNR und den Buchungskreis bzw. Finanzkreis eine Objektnummer erstellt, die dem Feld AUSP-OBJEK. entspricht.

AUSP-OBJEK Objektnummer mit vorgegebenen Finanzkreis

Unter der Annahme eines dreistelligen Finanzkreis KRK und dass das Merkmal die Interne Merkmalsnummer (Feld ATINN) folgenden Wert hat 0000000022 hat wird folgendes Coding zum Feld hinterlegt:

DATA: L_objfond TYPE AUFK-AUFNR.
DATA: L_MERKMALPBW type AUSP-ATWRT.

CONCATENATE 'KRK ' ZAUFNR INTO L_OBJFOND RESPECTING BLANKS.

SELECT SINGLE ATWRT INTO L_MERKMALPBW FROM AUSP
 WHERE OBJEK = L_OBJFOND AND ATINN ='0000000022' AND KLART = '042'.
IF sy-subrc <> 0.
  CLEAR PBW.
ELSE.
  PBW = L_MERKMALPBW.
ENDIF.

Im Ergebnis enthält nun das Feld PBW die in der Klassifizierung hinterlegte Projektbewertung des Fond.

Objektnummer aus Buchungskreis identisch zum Finanzkreis ermitteln

Wesentlich eleganter ist es jedoch, sofern Finanzkreis und Buchungskreis übereinstimmen, diesen aus der Stammdatentabelle AUFK auszulesen.

Hierzu habe ich das Coding an einer Zeile angepasst.

DATA: L_objfond TYPE AUFK-AUFNR.
DATA: L_MERKMALPBW type AUSP-ATWRT.


CONCATENATE  AUFK-BUKRS ZAUFNR INTO L_OBJFOND RESPECTING BLANKS.


SELECT SINGLE ATWRT INTO L_MERKMALPBW FROM AUSP
 WHERE OBJEK = L_OBJFOND AND ATINN ='0000000022' AND KLART = '042'.
IF sy-subrc <> 0.
  CLEAR PBW.
ELSE.
  PBW = L_MERKMALPBW.
ENDIF.

Durch die Codingzeile:

CONCATENATE  AUFK-BUKRS ZAUFNR INTO L_OBJFOND RESPECTING BLANKS.

wird der Buchungskreis unter Berücksichtigung von Leerzeichen mit den Zusatzfeld ZAUFNR verknüpft, so dass hier von dreistellige ebenso wie vierstellige Finanz- bzw. Buchungskreise berücksichtigt werden.

Datentyp beim Klassifizierungsmerkmal Unterschied AUSP-ATWRT und AUSP-ATFLP

Sofern die einzelnen Klassifizierungsmrerkmale in der Merkmalsverwaltung als Datentyp ZEICHENFORMAT definiert sind, kann hier das Thema schon abgeschlossen werden und die Query kann direkt genutzt werden.

Seitens einer anderen Hochschule bin ich jedoch darauf angesprochen worden, dass das Tabellenfeld AUSP-ATWRT leer ist und bei IHnen das Feld AUSP-ATFLP gefüllt ist. Dieses liegt daran, dass Sie als Klassifizierungsmerkmal den Datentyp DATUM gewählt haben um hier ein Datum zu hinterlegen.

Hierzu muss man wissen, dass die Tabelle AUSP "Ausprägungswerte der Sachmerkmale" die einzelnen Merkmalswerte in zwei Feldern speichert, je nachdem welcher Art die Daten sind.

Die Characterwerte (Zeichenformat) werden wie in oberen Beispiel beschrieben im Tabellenfeld AUSP-ATWRT "Merkmalswert" als Character mit 30 Zeichen gespeichert.

Handelt es sich jedoch um einen nummerischen Wert werden diese als Fließkommazahl (FLOAT) in das Tabellenfeld AUSP-ATFLV als Gleitpunktzahl mit 16 Stellen gespeichert.

Das Problem ist nun aus diesen Wert wieder ein Datumsfeld zu erhalten.

Gleitpunktzahl FLOAT in Datum (DATE) konvertieren

Zur Verdeutlichung des Problems habe ich einmal ein Merkmal als Datum definiert und den gespeicherten Wert in der Tabelle AUSP näher angesehen:
 

Datum als Float

Datum	Wert als Float AUSP-ATFLV
01.01.2018	2,0180101000000000E+07
14.05.2017	2,0170514000000000E+07
13.07.2017	2,0170713000000000E+07

Nun stellt sich für die QUery die Frage, wie aus den FLOAT Wert ein Datumswert ermittelt werden kann.

Im ersten Schritt legen wir ein Zusatzfeld mit ATFLV1 an um den Wert zum Merkmal 0000000043 welches als Datentyp Datum definiert bekommen hat auszulesen. Analog zum ATWRT lautet das Coding im Abschnitt 2 dann wie folgt:

DATA: L_objfond TYPE AUFK-AUFNR.
DATA: L_ATFLVDATUM1 type AUSP-ATFLV.


CONCATENATE  AUFK-BUKRS ZAUFNR INTO L_OBJFOND RESPECTING BLANKS.


SELECT SINGLE ATFLV INTO L_ATFLVDATUM1 FROM AUSP
 WHERE OBJEK = L_OBJFOND AND ATINN ='0000000043' AND KLART = '042'.
IF sy-subrc <> 0.
  CLEAR ATFLV1.
ELSE.
  ATFLV1 = L_ATFLVDATUM1.
ENDIF.

Nun ist also im Feld ATFLV1 das Datum als FLOAT gespeichert. Jetzt gibt es drei Möglichkeiten um daraus ein Datum zu erhalten.
 

Funktionsbaustein CTCV_CONVERT_FLOAT_TO_DATE

Der Funktionsbaustein CTCV_CONVERT_FLOAT_TO_DATE wandelt einen Datumswert im Gleitpunktformat (Typ F) in das Datumsformat (Typ D) um.

Hier kann dann der Aufruf des Funktionsbaustein aus ATFLV1 ein Datum ausgeben.

Hierzu legen wir ein Zusatzfeld DATUM1 vom Typ D an (Länge von 8 wird automatisch vorgegeben) und können über folgendes Coding

DATA : L_datum1 LIKE ausp-atwrt,
       L_datumsformat LIKE sy-datum.
CLEAR T_DATUM.
IF AUSP-ATFLV <> 0.
CALL FUNCTION 'CTCV_CONVERT_FLOAT_TO_DATE'
  EXPORTING
    FLOAT         = ATFLV1
 IMPORTING
   DATE          = L_datum1
          .
WRITE  L_datum1 TO L_datumsformat DD/MM/YYYY.
DATUM1 = L_datumsformat.
ENDIF.

 

Float in Integer und Integer in Datum umwandeln

Hier kann ATFLP über weitere Hilfsvariablen in ein Datumsfeld umgewandelt werden.

Dazu wird ein Zusatzfeld vom Typ D für Datum angelegt und nun mit folgenden Code das ermittelte Feld ATFLV1 umgewandelt. Das Zusatzfeld erhält hier die Bezeichnung DATUM2.

DATA
ZL_integer TYPE I,
ZL_datum TYPE D.

ZL_integer = ATFLV1.

WRITE  ZL_integer TO  ZL_datum.

DATUM2 = ZL_DATUM.

Beide hier kurz vorgestellte Methoden sind im Formumsbeitrag "Convert float to date" unter https://archive.sap.com/discussions/thread/154147 ausführlicher beschrieben.
 

Umwandeln ATFLV in Datum durch lokale Felder in Query

Da wir uns bei der Verwendung obiger ABAP Coding nicht sicher waren, ob diese problemlos funktionieren haben wir eine dritte Variante genutzt in der das Feld ATFLP1 als Zusatzfeld im Infoset zur Verfügung gestellt wird und erst in der Query eine Umwandlung erfahren soll.

Hierzu erhält das Feld Datumsmerkmal auch die Kurzbezeichnung ATFLP1 in der Query. Dieses ist in der SQ01 in der Query zum Infoset über

• SPRINGEN
• FELDAUSWAHL
• FELDAUSWAHL

möglich indem über

• BEARBEITEN
• KURZBEZEICHNUNGEN
• EIN/AUSSCHALTEN

diese eingeschaltet werden und das Feld eine entsprechende Kurzbezeichnung erhält.

Nun ist es erforderlich über

• BEARBEITEN
• LOKALE FELD
• ANLEGEN

mehrere lokale Zusatzfelder mit Formeln und Bedingungen anzulegen.

Als erstes wird ein Feld angelegt, dass die Gleitpunktzahl in eine bearbeitbare Zahl verwandelt.

Dazu legen wir das Feld DATUM als Rechenfeld mit 9 Ziffern und 8 Dezimalstellen an.
Als Berechnungsvorschrift erhält es
ATFLV1/100000000
und als Bedingung
ATFLV1<>0

Damit haben wir nun statt
2,0180101000000000E+07
die Dezimalzahl
0,20180101
erhalten.

Mit dieser arbeiten wir nun weiter und legen für die Datumsbestandteile folgende lokale Felder an.

Das lokale  Feld DATUMTXT erhält die Eigenschaften Textfeld mit 10 Zeichen.

und als Berechnungsvorschrift
DATUM
bei der Bedingung
DATUM<>0

Hierduch ist aus der Zahl ein String entstanden und dieser String kann wie im Artikel "Query Stammdatenvergleich Profit-Center und Auslesen von Textbestandteilen (Teilstring aus Variable)" ausgelesen werden.

Dieses nutzen wir für drei lokale Felder die Teile der Dezimalzahl verwenden um Jahr, Monat und Tag zu erhalten.

Das lokale Feld JAHR hat nun die Eigenschaften Textfeld mit vier Zeichen und folgende Berechnungsvorschrift:
DATUMTXT[3:6]
bei der Bedingung DATUM <>0

Folgerichtig ist das Feld Monat ein Textfeld mit 2 Zeichen und der Formel DATUMTXT[7:8] bei Datum <> 0.

Abschliessend fehlt noch der Tag als Textfeld mit zwei Zeichen und der Formel DATUMTXT[9:10] ebenfalls bei DATUM <>0.

Aus Jahr Monat und Tag lässt sich das Datum zumindest als Zahl ausdrücken.

Hierzu wird das Feld DATUMZAHL als Textfeld mit 8 Zeichen definiert und bekommt folgende Formel JAHR * 10000 +  MONAT * 100 + TAG bei DATUM <> 0

Im Ergebnis ist das Datum hier statt 0,20180101 als 20180101 hinterlegt.

Das spannende ist nun aber das Feld DATUMATFLV1 dieses ist als Datumsfeld definiert und hat folgende Formel DATUMZAHL bei Datum<>0.

Zur besseren Übersicht habe ich die einzelnen Felder noch einmal in folgender Tabelle aufgeführt.
 

Felder zum Auswertung AUSP-ATFLV

Feld	Format	Berechnungsvorschrift	Bedingung
ATFLV1	Zusatzfeld aus Infoset entspricht AUSP-ATFLV
DATUM	Rechenfeld 9 Ziffern 8 Dezimalstellen	ATFLV1/100000000	ATFLV1<>0
DATUMTXT	Textfeld 10 Zeichen	DATUM	DATUM<>0
JAHR	Textfeld 4 Zeichen	DATUMTXT[3:6]	DATUM<>0
MONAT	Textfeld 2 Zeichen	DATUMTXT[7:8]	DATUM<>0
TAG	Textfeld 2 Zeichen	DATUMTXT[9:10]	DATUM<>0
DATUMZAHL	Textfeld 8 Zeichen	JAHR * 10000 +  MONAT * 100 + TAG	DATUM<>0
DATUMATFLV1	Datumsfeld	DATUMZAHL	DATUM<>0

Damit ist das Feld ATFLV1 erfolgreich in ein Datum umgewandelt worden.

Der entsprechende Abschnitt der Query (inklusive der Hilfsfelder, die man sonst natürlich nicht mit in der Grundliste übernehmen würde sieht wie folgt aus:
 

Query zur Auswertung ATFLV1 aus FLOW wird DATE

ATFLV1	DATUM	DATUMTXT	JAHR	MONAT	TAG	DATUMZAHL	DATUMATFLV1
2,0180101000000000E+07	0,20180101	0.20180101	2018	01	01	20180101	01.01.2018
2,0170514000000000E+07	0,20170514	0.20170514	2017	05	14	20170514	14.05.2017

Im Ergebnis ist hier also tatsächlich ein korrekt beziehungsweise lesbares Datum aus den Feld entstanden. Somit können also auch Datumswerte innerhalb der Klassifizierung mit ausgewertet werden. Allerdings sind diese allerdings etwas umständlicher gespeichert. Dafür hat das Erarbeiten einer gemeinsamen Lösung tatsächlich Freude gemacht.

Glücklicherweise haben wir keine als Datum formatierten Merkmale, sonst würde das je Datumsfeld ein etwas umständliches Coding erfordern. Vermutlich würde ich mich dann auch eher mit den oben erwähnten Funktionsbaustein beschäftigen, aber so war dieses für ein einzelnes Datum auch eine praktische Übung beziehungsweise Herausforderung durch die Kollegen an einer anderen Hochschule.

Hinweis:
In der späteren Query bietet es sich dann allerdings tatsächlich an das Feld in der Grundliste mit der Option Feld nur ausgegeben wenn <>0 zu markieren. Andernfalls wird als Dautm 00.00.0000 ausgegeben.

 

---

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.

---

Neben der Verwendung von Zusatzfeldern in SAP Query besteht auch die Möglichkeit über Abgrenzungen einen Parameter anzulegen und hierdurch mit einen übergegeben Wert in einer Query zu arbeiten. Um die Vorzüge dieser Methode zu geben möchte ich vorab die Ausgangslage zu beschreiben die hier eine Notwendigkeit für die Übergabe eines Wertes und Arbeiten mit eben diesen Wert erforderlich gemacht hat. Das einfachste Beispiel wäre nun wohl die Angabe eines Stundenlohnes für eine bestimmte Personengruppe zu übergeben um bei einer Summentabelle über Kostenarten für diese Beschäftigtengruppe die hinter den Personalkosten liegenden Stunden festzulegen. Allerdings möchte ich als Beispiel ein etwas umfangreicheres Thema aus der Auswertung von Investitionen zu verwenden.

Ausgangslage: Änderung Anforderungen Finanzstatistik für Wertgrenze bei Investitionen

Im Rahmen eines Finanzberichtes werden die Investitionsausgaben über Sachkonten in bestimmte Kontengruppe unterteilt. Dabei gibt es für die Investitionsausgaben eine Aufteilung in vier Spalten (oder auch Gruppen). Laut Kontierungsplan sind dabei die zugeordneten Konten so gestaltet, dass diese eine Wertgrenze von bis 5.000 und ab 5.000 seitens der Finanzbuchhaltung zugeordnet bekommen haben.

Nun sollen jedoch die sonstigen Investitionsausgaben unterschieden werden in Investitionsausgaben mit einem Anschaffungswert bis 1.000 Euro und solche mit einem Anschaffungswert über 1.000 Euro. Dieses ist jedoch über die reinen Sachkonten nicht möglich, so dass hier eine entsprechende Korrektur im Finanzberichts auf Basis der Einzelposten erfolgen müssen.

In der Gruppe Investitionen bis 1.000 Euro sind durch die Vorgaben der Finanzbuchhaltung (Stichwort Kontierungsrichtlinie oder Kontierungshandbuch) einzelne Sachkonten bis 5.000 Euro zugeordnet (bspw. Lizensen bis 5.000 Euro) und in der Gruppe "Investitionsausgaben mit einen Anschaffungswert über 1.000 Euro"  sind nur die Konten hinterlegt die ab 5.000 Euro vorgesehen sind (bspw. Lizensen ab 5.000 Euro).

Entsprechend muss hier tatsächlich anhand der Einzelbelege die Werthöhe betrachtet werden.

Die identifizierten Werte müssen also anhand der Werthöhe gegebenenfalls umgebucht werden. Der fachliche Hintergrund dieser Auswertung bzw. die Anforderungen sind auch im Artikel "Pivottabellen ab Excel 2010 dynamischer filtern mit Datenschnitten am Beispiel Hochschulfinanzstatistik" näher erläutert worden.


Nun stellt sich die Frage, wie diese Werte ausgewertet und eine entsprechende Korrekturbuchung ermöglicht werden könnte. Die Auswertung erfolgt für die Jahressicht durch eine Plankopie, so dass hier ein Planwert auf Profit-Center und Kostenart erfolgt.

Das Thema Auswertung von Investitionen habe ich in den Artikeln "Zusammenfassung Query über Anlagenzugang - Auswertung Investitionen aus Profit-Center-Rechnung" sowohl aus der Profit-Center-Rechnung als auch aus der Anlagenbuchhaltung beschrieben. 2008 hatte ich im Artikel "Kurzanleitung Anlage einer SAP Query Auswertung ANBWA in der Profit-Center-Rechnung über ANBW und GLPCA" schon die Möglichkeit über die Tabelle GLPCA beschrieben. Über die Zuordnung von Tabellen und Identiifikation mag ich daher nicht weiter eingehen.

Für einen Quartalsbericht werden die Anlagenzugänge über die gesamte Einrichtung über die Transaktion S_ALR_87012050  (Anlagenzugänge) im SAP Menü unter

• Rechnungswesen
• Finanzwesen
• Anlagen
• Infosystem
• Berichte zur Anlagenbuchhaltung
• Tagesgeschäft
• International
• Anlagenzugänge (S_ALR_87012050)

zu finden. Für einen Jahresbericht ist es allerdings erforderlich passend zu  einzelnen Fächergruppen (um beim Beispiel der Hochschulfinanzstatistik zu bleiben) die einzelnen Kontengruppen (SYF Codes) auszuwerten. Entsprechend ist hier eine Umbuchung zwischen den einzelnen Konten erforderlich.

Nach ein wenig Diskussion mit Kolleginnen und Kollegen haben wir im Ergebnis dann eine Auswertung anhand der Tabelle GLPCA und einer Übergabe eines Abfrageparameters gefunden.

Die gefundene Lösung mag ich nun hier beschreiben, da diese Anforderung ein schönes Beispiel für die Verwendung von Parametern innerhalb SAP Query ist.

Infoset anlegen zur Auswertung der Profit-Center-Einzelposten

Im Artikel "Kurzanleitung Anlage einer SAP Query Auswertung ANBWA in der Profit-Center-Rechnung über ANBW und GLPCA" hatte ich noch einen Join über die Tabellen GLPCA und TABWT erstellt um zur Anlagenbewegungsart  auch direkt den Text dazu zu erhalten. Mittlerweile hat sich aber gezeigt dass in der Grundliste der Query unter Zusatzfelder das Feld "Text:Analagen-Bewgungsart" ( TEXT_GLPCA_ANBWA  ) vorhanden ist und so eine Verknüpfung beider Tabellen nicht erforderlich ist.

Daher wurde als Datenquelle die Option Direktes Lesen der Tabelle GLPCA gewählt und alle Felder ins Infoset übernommen. Nun wollen wir aber beim Auswerten der Einzelposten der Query anhand unserer Selektion überprüfen, ob eine Umbuchung für die Selektierten Konten erforderlich ist. Dazu möchten wir im Selektionsfeld mit übergeben, welche Konten wir auswerten wollen (über einen dreistelligen SYF-Code (Systemfinanzierungscode) und über diesen dann anhand des Buchungswertes überprüfen ob hier eine Korrektur erforderlich ist.

Zusatzfeldern beim Aufruf einer Query mit Wert versehen

Hierzu sind zwei Schritte erforderlich. Zum einen muss der Wert in der Selektionsmaske mit übergeben werden und zum anderen muss dieser Wert später in einem Zusatzfeld dann in der Query auch verarbeitet werden.

Zwar ist bei Zusatzfeldern ohne Probleme möglich weitere Informationen aus Datenbanken anhand der ausgewerteten Daten zu erlangen (siehe zum Beispiel "Query über IBAN und Stammdaten Kreditor oder Debitor (Zusatztabellen in SAP Query)" oder auch "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") aber es ist nicht möglich diese Zusatzfelder als Selektionskriterium für eine Wertübergabe zu verwenden.

Abgrenzungen im Infoset Unterschied Parameter und Selektion

Dieses ist allerdings in der Definition der Query über die Schaltfläche "Zusätze" und hier im Register Abgrenzungen möglich.

Über die Schaltfläche anlegen kann nun eine Abgrenzung als Selektionskriterium oder Parameter angelegt werden.

Der Unterschied ist, dass beim Parameter nur ein einzelner Wert während beim Selektionskriterium auch mehrere Werte oder ganze Intervalle hinterlegt werden können.

Für unseren Fall entscheiden wir uns für einen Parameter ZP_SYF da wir ja nur einen Einzelwert (die auszuwertenden SYF Codes  hinterlegen wollen).

Als Bedeutung und Selektionstext legen wir "SyfCode Auswertung (Variante)" fest und als Format Typ C (Character) mit einer Länge von 3.

Die Option als Default auf Selektionsbild lassen wir deaktiviert, da diese Abgrenzung nur genutzt werden soll, wenn wir auch mit der Query arbeiten wollen. Somit würde sich hier eine Abgrenzung also auch eignen um in einer Selektionsvartiante noch einen bestimmten HInweis zu hinterlegen der gar nicht weiter beachtet werden soll.

Verwendung der Abgrenzung (Parameter) im Zusatzfeld

Nachdem die Abgrenzung angelegt ist stellt sich noch die Frage, wie mit dieser später in der Query gearbeitet werden kann. Hierzu legen wir im Register Zusätze ein Zusatzfeld an.

Dieses Zusatzfeld bekommt die Bezeichnung ZSEL_SYF und als Langtext und Überschrift den Hinweis "Syf Code Auswahl" . Ferner erhält es ebenfalls das Format C und die Länge 3.

Ergänzend erhält es aber über die Taste "Coding zum Feld" noch folgendes Coding

CLEAR ZSEL_SYF.
ZSEL_SYF = ZP_SYF.

Damit wird in der ersten Zeile das Zusatzfeld geleert um es in der zweiten Zeile mit den Wert aus dem Selektionsfeld versehen zu werden.

Dieses Zusatzfeld kann über die Schaltfläche Feldgruppen in eine eigene Feldgruppe übernommen werden.

Zusammenfassung Abgrenzung und Zusatzfelder:

Die Selektionsmaske der späteren Query erhält also den Abgrenzungsparameter und die Query kann später auf das Zusatzfeld zugreifen und damit arbeiten.

Man könnte diese Zusatzfeld-Abgrenzungparameter Kombination mit einen Abfrageparameter in Access für eine Abfrage vergleichen wo dann ebenfalls zur Laufzeit eine Auswertung erfolgen wird.

Nachdem wir nun alle Felder der Tabelle GLPCA sowie das Zusatzfeld in das Infoset übernommen haben kann das Infoset generiert werden.

Das Zusatzfeld haben wir dabei direkt in eine eigene Feldgruppe Zusatzfelder angelegt.

Query anlegen und mit lokalen Zusatzfeldern und Abfrageparametern arbeiten

Bei der Anlage der Query zum eben angelegten Infoset, welche in der gleichen Benutzergruppe zugeordnet sein sollten, springen wir im Menü über

• SPRINGEN
• FELDAUSWAHL
• FELDAUSWAHL

In die Feldliste der Query. Sofern noch nicht geschehen werden wir im Menü unter

• BEARBEITEN
• KURZBEZEICHNUNGEN
• Ein/ausschalten

wählen.

In unserer Feldgruppe EC-PCA: Ist-Einzelposten (die Tabelle GLPCA) geben wir folgenden Werten eine eigene Kurzbezeichnung.

• Kontonummer: = KONTO
• Betrag in Profit-Center-Hauswährung = BETRAG

Und in der Feldgruppe (Sachgruppe) Zusatzfelder geben wir unseren Zusatzfeld ebenfalls eine Kurzbezeichnung zu:

• Syf Code Auswahl = SEL_SYF

Somit können wir nun mit diesen Feldern in der Query direkt arbeiten.

Dazu legen wir zwei lokale Felder an um die Buchung anhand der Werthöhe ggf. anderen SYF Code zuzuweisen.

Dieses ist im Menü über

• BEARBEITEN
• LOKALES FELD
• ANLEGEN

möglich.

1. Lokales Feld SYF (Wertgrenze)

Das erste Feld erhält die Bezeichnung Kurzbezeichnung SYF und folgende Eigenschaften
Feldbezeichnung / Überschrift:
SyF-Code Finanzstatistik

gleiche Eigenschaften wie Feld
SEL_SYF  (also unser Zusatzfeld)

Als Berechnungsvorschrift kann nun eine komplexe Berechnung eingefügt werden.

1. BEDINGUNG
(BETRAG < -1000 OR BETRAG > 1000) AND SEL_SYF <> '561'
Formel
'565'

Hintergrund ist, dass nur die SYF Code 562 und 563 eine Wertgrenzenunterscheidung haben. Wenn der Wert 1.000 Euro übersteigt soll der SYF Code 565 genommen werden.

2. BEDINGUNG
SEL_SYF = 565 AND BETRAG <= 1000 AND BETRAG >= -1000
Formel
'563'

Sollte innerhalb der Auswertung zu 565 ein Betrag unter kleiner als 1000 liegen ist eine Korrektur von 565 nach 563 erforderlich.

SONST
SEL_SYF

Sofern keine der oberen Bedingungen erfüllt ist (also die Wertgrenze nicht greift) kann der übergebene Selektionsparameter als Wert für die Buchung beibehalten werden.

2. lokales Feld CHK_SYF (Ampel)

Als nächstes wird das lokale Feld CHK_SYF mit Feldbezeichnung / Überschrift
CHK SyfCode
angelegt.

Als Eigenschaften soll hier IKONE gewählt werden.

Die komplexe Berechnungsvorschrift lautet einfach:

BEDINGUNG
SEL_SYF = SYF
Formel
ICON_GREEN_LIGHT

SONST
ICON_RED_LIGHT

Nun kann über die Schaltfläche  Grundliste mit den einzelnen Feldern gearbeitet werden.

Innerhalb der Query werden nun auf folgende Felder der einzelnen Tabellen Zugriff genommen. Bzw. in der Grundliste zugewiesen. Hierbei ist L als Listenfeld und S als Selektionsfeld zu verstehen.

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

Tabelle GLPCA "EC-PCA: Ist-Einzelposten"
Geschäftsjahr (L,S) GLPCA-RYEAR
Konto (L,S) GLPCA-RACCT
Belegnummer (L) GLPCA-DOCNR
Soll Haben Kennzeichen (L) GLPCA-DRCRK
Profit-Center (L) GLPCA-RPRCTR
Betrag in Profit-Center-Hauswährung (L) GLPCA-KSL
Wenn nur eine Währung im SAP System verwendet wird kann es hier sinnvoll sein die Option kein Währungsfeld zu aktivieren.

Buchungsdatum (L) GLPCA-BUDAT
Anlage-Hauptnummer (L) GLPCA-ANLN1
Anlagenunernummer (L) GLPCA-ANLN2
Anlagen Bewegungsart (L,S) GLPCA-ANBWA

Zusatzfelder
Text:Anlagen-Bewegungsart (L) TEXT_GLPCA_ANBWA
Syf Code Auswahl (L) ZSEL_SYF

Dieses Feld muss tatsächlich nicht als Selektionsfeld markiert werden, da die Selektion ja über den Abgrenzungsparameter erfolgt und keine Abfrage nach ZSEL_SYF erfolgen soll sondern dieses Feld beim Start der Query mit einen Wert versehen wird.

Lokale Zusatzfelder
Nun werden die einzelnen lokalen Zusatzfelder noch übernommen:
SyF-Code Finanzstatistik (L)
CHK Syfcode (L)

Letzteres Feld ist unsere Ampel.

in der Query kann nun das Feld CHK Syfcode auf die Werkzeugleiste SORTIERFELDER gezogen werden (hierbei nicht über die Spaltenüberschrift sondern durch Ziehen aus den Beispieldatensatz.

Die Sortierung kann dann noch absteigend markiert sein und wir erhalten für jede Auswertung nach den einzelnen SYF Codes auch direkt einen Hinweis darauf welche Belege umgebucht werden müssen.

Fazit Anwendbarkeit von Abgrenzungen als Parameter für SAP Query

Mit der Query ist nun eine Auswertung möglich in der durch eine Ampel direkt erkannt werdne kann, welche Korrekturbuchungen für die Statistik in der CO Planversion notwendig sind.

Daneben können aber Abgrenzungen als Parameter auch für viele weitere dynamische Anwendungen innerhalb einer Query verwandt werden. Ein Beispiel wurde ja schon genannt um hier als Beispiel einen Stundenlohn zu übergeben um eine Anzahl an bestimmter Personen anhand der Personalkosten zu ermitteln. Ein weiteres Beispiel könnten aber auch Zuschlagssätze sein oder Rechenoperatoren die innerhalb der Query dynamisch gesetzt werden können.

Hier empfinde ich die Möglichkeiten als ähnlich weit gehend wie das Coding innerhalb der Zusatzfelder, wobei beides ja eigentlich auch zusammen gehört. Insgesamt hat das gemeinsame Arbeiten an einer Lösung zur Beachtung einer neuen Wertgrenze aus einer Anforderung einer Finanzstatistik sehr viel Freude gemacht und ein weiteres Anwendungsgebiet und Möglichkeit innerhalb der SAP Query erschlossen.
 

---

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.

---

Im Rahmen der in den Artikeln "Query Abrechnungsvorschriften Innenauftrag" und "Abrechnungsvorschriften von Innenaufträgen auf identische verantwortliche Kostenstelle und empfangende Kostenstelle per Query mit Ampelfunktion prüfen" vorgestellten Query zur Auswertung der Abrechnungsvorschriften von CO Innenaufträgen wurde anfangs nur die Auftragsnummer und die Planversion als Selektionsmerkmale definiert.

Zur Erinnerung Query und Infoset zur Abrechnungsvorschrift:

Um die Abrechnungsvorschriften mit einer Query auszuwerten werden die beiden Tabellen AUFK für die Auftragsstammdaten und COBRB - "Aufteilungsregeln Abrechnungsvorschrift Auftragsabrechnung" über das Feld OBJNR Objektnummer miteinander verknüpft.

Exkurs Objektnummer oder Partnerobjektnummer

Die Objektnummer ist auch schon im Artikel "SAP Query: Einzelpostenliste KAMV für Umbuchung in Planversion" näher beschrieben worden. Hierbei werden Kostenstellen mit führenden KS* und Innenaufträge mit OR* abgebildet. Um nun aus den beiden Objekten Kostenstelle oder Innenauftrag als Nummer und die Art des CO Objektes auszuwerten muss dieser String in einzelne Bestandteile aufgeteilt werden.

Hierzu kann im ersten Schritt zum Beispiel über das lokale Feld KTRA in einer Query bestimmt werden ob es sich um eine Kostenstelle oder einen Innenauftrag handelt und in den Feldern KTR_IA beziehungsweise KTR_KS fallweise dann die Nummer der Kostenstelle bzw. der Innenaufträge ausgegeben werden.

Dies Methode ist im Artikel "Query Einzelpostenliste IST über CO Objekte (Auflösen von Innenauftrag, Kostenstelle) sowie Benutzerstammdaten und Erfassungsdatum" ausführlich beschrieben worden und sei hier nur der Vollständigkeit noch einmal erwähnt.

Die Grundliste der Query zur Auswertung der Abrechnungsvorschriften sieht derzeit wie folgt aus:

Auftragsstammdaten AUFK
Auftragsnummer (L,S) AUFK-AUFNR
Kurztext (L) AUFK-KTEXT

Aufteilungsregeln Abrechnungsvorschrift Auftragsabrechnung COBRB
Version (L,S) COBRB-VERSN
Kontierungstyp (L) COBRB-KONTY
Empfangende Kostenstelle (L) COBRB-KOSTL
Auftragsnummer (L) COBRB-AUFNR
Abrechnungsart (L) COBRB-PERBZ
Ursprungszuordnung (L) COBRB-URZUO
Gültig ab Periode (L) COBRB-GABPE
Gültig ab Jahr (L) COBRB-GABJA
Gültig bis Periode (L) COBRB-GBISP
Gültig bis Jahr (L) COBRB-GBISJ

Nun können als Empfänger die beiden Felder

• Empfangende Kostenstelle (L) COBRB-KOSTL
• Auftragsnummer (L) COBRB-AUFNR

in einer Abrechnungsvorschrift gepflegt werden und werden entsprechend mit in der Liste ausgegeben.

Senderauftrag und Empfängerauftrag in der Selektion zur Auswertung eintragen

Für bestimmte Fragestellungen kann es jedoch interessant sein, welche Innenaufträge auf eine bestimmte Kostenstelle oder auf einen bestimmte Innenauftrag abgerechnet worden sind. Ein Beispiel wäre wenn mehrere Innenaufträge auf einen Sammelauftrag Vollkostenprojekte, Weiterbildung, Vermietung und Verpachtung oder auch Erlösaufträge für einzelne Fachbereiche oder andere vergleichbare CO Objekte abgerechnet werden um später dann nur eine Erlösumlage nur über diese Erlösaufträge durchzuführen.

Daher werden beide Felder ebenfalls als Selektionsfelder in der Grundliste aktiviert.

Leider haben sowohl das Tabellenfeld COBRB-AUFNR als auch AUFK-AUFNR die Bezeichnung Auftragsnummer, so dass in der Selektionsmaske der Query an zwei Stellen ein Feld Auftragsnummer einen entsprechenden Wert erwartet.

Dabei ist das Feld COBRB-AUFNR als Empfänger und AUFK-AUFNR als Sender gedacht.

Hier bietet es sich daher an in der Pflege der Query im Bild Selektionen (dieses ist über die Transaktion SQ01 in der Pflege der Transaktion über SPRINGEN > FELDAUSWAHL > SELEKTIONEN zu erreichen. Den Selektionstext des zweiten Feld Auftragsnummer in empfangende Auftragsnummer analog zur empfangenden Kostenstelle umzubenennen.

Auf diese Weise kann sowohl von Seiten der Sender als auch Empfänger eine Stammdatenauswertung erfolgen.
 

---

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.

---

Manchmal erweist sich mein Blog tatsächlich auch für mich selbst als "Wissenspool" auf den ich selbst sehr gerne zurück greife um bestimmte Anforderungen direkt erfüllen zu können.

So kam nun die Frage auf, ob es nicht möglich wäre für alle Kostenstellenbereiche (im Hochschulbereich würden hier bspw. Fachbereiche oder auch Abteilungen in Frage) die Anzahl an Rechnungen (Einzelposten Kreditorenrechnungen) auszuwerten.

Kreditoren Einzelposten Liste im Modul FI

Wie schon im Artikel "Auswertung Kreditoren Einzelposten inklusive CO Objekte wie Kostenstelle oder Innenauftrag" sind bei einer Auswertung der Nebenbuchhaltung im Kreditorenbereich in der Kreditoren-Einzelposten Liste zu finden unter:

• Rechnungswesen
• Finanzwesen
• Kreditoren
• Infosystem
• Kreditoren Posten
• Kreditoren Einzelposten Liste ( Transaktion S_ALR_87012103)

zwar die FI Belegdaten (Kreditorenbeleg und Zahlungsbeleg) und damit die beiden Bücher Kreditorenbuchhaltung und Hauptbuchhaltung angezeigt jedoch sind auf beiden Belegen nicht die CO-Objekte des Kostenrechnungsbeleges zu finden.

Query mit CO-Objekten Kostenstelle und Innenauftrag aus der Profit-Center-Rechnung

Entsprechend haben wir hier eine entsprechende Query angelegt, die im Rahmen der Profit-Center-Rechnung eine passende Auswertung bastelt.

Das entsprechende Infoset ist in folgender Abbildung dargestellt:



Das Infoset verknüpft dabei die Tabellen GLPCA, BSAS, LFA1, BSAK und SKAT und kann sowohl die Felder  CO Innenauftrag und Kostenstelle ausgewiesen.

Anhand der Kostenstelle kann, dank eines sprechenden Kostenstellenschlüssel innerhalb eines bestimmten Intervalls der Bereich (Abteilung oder Fachbereich) anhand der ersten Ziffern der Kostenstellen (bspw. die zweite und dritte Ziffer einer Kostenstelle) identifiziert werden.
 

Aus Kostenstellenschlüssel den Fachbereich oder Abteilung auslesen

Im Rahmen des Artikel "Query Stammdatenvergleich Profit-Center und Auslesen von Textbestandteilen (Teilstring aus Variable)" hatte ich ja schon einmal eine ähnliche Fragestellung anhand der Auslesung der Kostenstelle aus Profit-Centern festgelegt, allerdings möchte ich in der bestehenden Query nicht nur die Ziffern der Kostenstelle sondern auch zu den Innenaufträgen die verantwortliche Kostenstelle und ggf. den Kurztext des Innenauftrag und weitere Stammdaten aus den CO Innenauftrag übernehmen.

Fragestellung: Wie viele Kreditoreneinzelposten sind im Geschäftsjahr je Bereich angefallen

Danach sollen auch noch anhand der Kostenstelle (wenn auf Kostenstelle gebucht) oder anhand der verantwortlichen Kostenstelle (eines Innenauftrages) und sofern die Kostenstellen innerhalb eines Fachbereiches liegen eine Zwischensumme gebildet werden.

Die Aufgabe wäre nun also:

1. Ist die Rechnung auf einen Fachbereich / Abteilung gebucht und um welchen handelt es sich?
2. Welche Kostenstelle (Kostenstelle oder verantwortliche Kostenstelle Innenauftrag) ist betroffen?
3. Wieviele Buchungen sind je Fachbereich (und je Kostenstelle) angefallen?

Für Frage 3 muss in einer solchen Auswertung also auch noch ein Zähler mit aufgeführt werden.

Ausgehend von der vorhandenen Query, die ich ja schon ausführlich im oberen Artikel beschrieben habe, möchte ich den Lösungsweg zu diesen Punkten gerne eingehen.

Der erste Schritt ist die Frage, wie weitere Stammdaten zum Innenauftrag ergänzt werden.

In der Query sind folgende Felder enthalten:

Kostenstelle (L,S) GLPCA-KOSTL
Auftragsnummer  (L,S) GLPCA-AUFNR

Das bedeutet, dass hier tatsächlich zumindest die Kostenstelle unproblematisch ergänzt werden können.

Infoset über Zusatztabellle erweitern

Im ersten Moment hatte ich nun überlegt, dass ich per ABAP Coding und Zusatzfeldern nun aus der Stammdatentabelle AUFK die notwendigen Daten aus den Auftragsstamm auszulesen und zum Feld GLPCA-AUFNR zu ergänzen.

Im schon vorhandenen Infoset soll die Tabelle AUFK als Zusatztabelle ins Infoset übernommen werden.

Über die Schaltfläche Zusätze (F5) bzw.  über  SPRINGEN-> ZUSÄTZE ZUM KNOTEN  innerhalb der Transaktion SQ02 (Pflege des Infosets) kann nun eine Zusatztabelle eingefügt werden. Hierzu kann im Register Zusätze die Schaltfläche Anlegen ausgewählt werden.
Hierzu tragen wir die den Namen AUFK und als Art der Zusatzinformation Zusatztabelle ein. Nun erfolgt eine Abfrage über SELECT SINGLE * FROM AUFK WHERE ...
in der auch gleich die Bedingung AUFNR  = GLPCA-AUFNR vorgeschlagen wird.

Es wird also die führende Tabelle GLPCA mit der Stammdatentabelle AUFK verknüpft wird.

Danach können einzelne Felder der Stammdatentabelle als eigene Feldgruppe ins Infoset übernommen werden.

HINWEIS Vorteil Zusatztabelle versus Join

Sicherlich hätte ich auch per JOIN die Tabelle einfügen und verknüpfen können, was mich aber tatsächlich an der Lösung der Zusatztabelle angenehm überrascht hatte war dass die Tabellenfelder der Tabelle AUFK einfach leer sind, wenn das Feld GLPCA-AUFNR nicht gefüllt ist sondern die Buchung auf Kostenstelle erfolgte und damit GLPCA-KOSTL gefüllt ist.

Die Alternative wäre sicherlich noch ein Outer Join statt Inner Join (statt 1:1 eine 1:N Verknüpfung)  Definition. :-)

Als Beispiel habe ich dabei folgende Felder mit übernommen:

• Auftragsart AUFK-AUART
• Auftragsnummer AUFK-AUFNR
• Kurztext AUFK-KTEXT
• Verantwortliche Kostenstelle AUFK-KOSTV
• Antragssteller AUFK-USER0
• Verantwortlicher AUFK-USER2
• Arbeitsbeginn AUFK-USER7
• Arbeitsende AUFK-USER8

Im Ergebnis können diese Felder dann in einer Query genutzt werden, nachdem natürlich das Infoset gesichert und generiert wurde.

Query mit lokalen Zusatzfeldern für Ermittlung Fachbereich

Da ich im Rahmen einer anderen Query aus einer virtuellen Lehreinhiet auch Text der Lehreinheit und Fachbereich abgeleitet habe war mein erster Gedanke per ABAP Coding und Zusatzfeld wie im Abschnitt "Zusatzfeld VLE zur Darstellung virtueller Lehreinheit aus Teilstring der verantwortlichen Kostenstelle sofern nicht in einen anderen Feld ein Wert steht" im Artikel "Query über COEP, AUFK und FMFINCODE für Einzelposten Istkosten Innnenauftrag mit Stammdaten aus CO und PSM-FM sowie Spalten für Ertrag und Aufwand - Erster Teil Infoset als Datengrundlage" beschrieben näher betrachtet

Glücklicherweise bin ich hier aber nur auf den Fachbereich angewiesen, so dass ich innerhalb der Query per lokalen Zusatzfeld mit den beiden Feldern Kostenstelle und verantwortliche Kostenstelle arbeiten kann.

Bezeichnungen und mit lokalen Feldern arbeiten

Neben der reinen Auswertung von einzelnen Tabellenfeldern kann innerhalb der Query auch die Ergebnisse verarbeitet werden. Um einzelne Felder weiter zu bearbeiten können Sie über SPRINGEN->FELDAUSWAHL->FELDAUSWAHL über die Funktion BEARBEITEN->KURZBEZEICHNUNGEN ->EINSCHALTEN einzelne Felder eine Kurzbezeichnung zuordnen.

Diese Kurzbezeichnungen sind notwendig, da wir auf diese dann Bezug nehmen, wenn wir ein lokaes Feld mit einer Formel anlegen. Dieses geht über
BEARBEITEN->LOKALES FELD->ANLEGEN.
Dieses Lokale Feld wird dann in der Feldgruppe angelegt, in der wir uns gerade befinden. Elegant wäre es natürlich, wenn wir im Infoset eine entsprechende leere Feldgruppe definiert hätten, es geht aber auch ohne.

Für dieses Feld werden dann entsprechende Eigenschaften festgelegt und über eine Berechnungsvorschrift kann auf andere Felder Zugriff genommen werden.

Nachdem ich hier schon die theoretische Vorgehensweise erläutert habe mag ich direkt zur praktischen Umsetzung gehen.

In der Feldgruppe zur Tabelle GLPCA "EC-PCA: Ist-Einzelposten" habe ich den Feld "Kostenstelle" die Kurzbezeichnung KS gegeben. Danach habe ich in der Feldgruppe zur Tabelle AUFK den Feld "Verantwortliche Kostenstelle" die Bezeichnung KS_IA gegeben.

Damit kann ich nun also wahlweise mit der Verantwortlichen Kostenstelle des Innenauftrages oder der bebuchten Kostenstelle im Profit-Center-Beleg arbeiten.

Damit das ganze aber auch Sinn macht habe ich noch zwei weitere Felder über "Bearbeiten->Lokales Feld anlegen" angelegt.

Lokales Feld Fachbereich (2. und 3. Ziffer der Kostenstelle innerhalb eines Nummernintervall)

Das Feld  Fachbereich mit den Eigenschaften Textfeld mit ANzahl der Zeichen 10 hat als komplexe Berechnung folgende Bedingungen angelegt:

Bedingung
KS >= 20000000 AND KS < 22000000
Formel
KS[4:5]

Bedingung
KS_IA >= 20000000 AND KS_IA < 22000000
Formel
KS_IA[4:5]

Sonst
''

Sofern also entweder die Kostenstelle oder die verantwortliche Kostenstelle zwischen 20000000  und  22000000 liegt wird in der Berechnungsvorschrift die 4. und 5. Stelle der Kostenstelle (die mit führenden 0 als zehstelliger Wert abgespeichert ist und bei achtstelligen Kostenstellenschlüsseln damit also die zweite und dritte Ziffer der Kostenstelle darstellt)  ausgewiesen.

Damit kann also im Feld Fachbereich direkt von 00 bis 99 jeder Fachbereich oder Abteilung mit ausgewiesen werden. Sofern die Kostenstelle in einen anderen Bereich liegt bleibt dann das Feld Fachbereich leer.

Lokales Zusatzfeld KSIA zum Ausweis jedglicher Kostenstelle

Da ich später nicht nur eine Auswertung nach Fachbereich sondern auch nach der jeweiligen Kostenstelle machen möchte habe ich noch ein zweites lokales Feld angelegt mit der Bezeichnung KSIA.

Auch dieses Feld ist ein Textfeld (mit 10 Zeichen)  und hat als Berechnungsvorschrift
KS + KS_IA

Da entweder die Kostenstelle oder der Auftrag und damit die verantwortliche Kostenstelle gefüllt ist, wird in diesen Feld dann die Kostenstelle ausgegeben.

Grundliste Query Kreditoren Einzelposten mit Gruppierung Bereich und Kostenstellen

Die Grundliste der Query sieht dann wie folgt aus.
Innerhalb der Query werden nun auf folgende Felder der einzelnen Tabellen Zugriff genommen bzw. in der Grundliste zugewiesen. Hierbei ist L als Listenfeld und S als Selektionsfeld zu verstehen. Die Felder werden hier in der Reihenfolge angeben, wie diese dann auch in der Query ausgegeben werden sollen:

lokale Zusatzfeld
Fachbereich  (L)
Kostenstelle KSIA  (L)

EC-PCA: Ist-Einzelposten (GLPCA)
Geschäftsjahr (S) GLPCA-RYEAR
Kontonummer des Lieferanten bzw. Kreditors (L,S) GLPCA-LIFNR
Belegdatum im Beleg  (L,S) GLPCA-BLDAT
Kontonummer des Lieferanten bzw. Kreditors (L,S) GLPCA-LIFNR
Referenzbelegnummer (L,S) GLPCA-REFDOCNR
Belegart (L,S) GLPCA-BLART

Zusatzfelder
Text: Belegart  (L)  TEXT_GLPCA_BLART

EC-PCA: Ist-Einzelposten (GLPCA)
Kontonummer (L,S) GLPCA-RACCT

SKAT
Sachkontolangtext (L) SKAT-TXT50

EC-PCA: Ist-Einzelposten (GLPCA)
Betrag in Buchungskreiswährung (L) GLPCA-HSL
(sinnvoll kann es sein hier als Währungsfeldposition "kein Währungsfeld" zu markieren, sofern nur mit einer Währung bspw. EUR gearbeitet wird)
Positionstext (L) GLPCA-SGTXT
Kostenstelle (L,S) GLPCA-KOSTL
Innenauftrag (L,S) GLPCA-AUFNR

AUFK
Auftragkurztext (L) AUFK-KTEXT
Verantwortliche Kostenstellle (L) AUFK-KOSTV

Damit habe ich dann tatsächlich alle für unsere Auswertung erforderliche Daten vorhanden.

ALV Liste Gruppieren und Zwischensummen

In der ausgeführten Query kann ich dann über die Schaltfläche Zwischensummen für die Felder Fachbereich und Kostenstelle KSIA sowohl Sortierung als auch Zwischensummen  aktivieren und habe damit eine Liste mit Zwischensummen über die gebuchten Beträge.

Sobald eine solche Zwischensumme gebildet wurde, kann aber über den Zauberwürfel (Layout auswählen und hier die Auswahl im Ausklappmenü auf Layout ändern) aus den Spaltenvorrat die nun vorhandene Spalte Zähler mit in die angezeigten Spalten übernommen werden und man hat sowohl für die Kostenstellen (inklusive der verantwortlichen Kostenstelle der Projekte) als auch auf Ebene der Fachbereiche eine Summe aller Buchungen mit ausgewiesen.

Summenaufrissstufen in ALV Liste wählen

Über die Schatfläche Zwischensumme kann das Menü Aufrisssummenstufe gewählt werden und hier eine Zwischensumme auf Ebene

• 0 Nicht-Summenzeilen
• 1 Kostenstelle KSIA
• 2 Fachbereich

gewählt werden. Hier werden je nach Stufe die tieferliegenden Positionen zugeklappt, so dass zum Beispiel bei der Option 2 nur die Anzahl der Belege auf Ebene der Fachbereiche ausgewiesen werden.

Im Ergebnis sieht man nun Buchungsvolumen sowie in Form der Beträge als auch der Anzahl der Buchungen.

Durch die Selektion der Belegart können nun auch Zahlungen (ZP) unberücksichtigt bleiben (ausgefiltert werden) oder auch einzelne Belegarten direkt in der Selektion der Query gewählt werden.

Fazit

Auf diese Weise kann also relativ einfach das Buchungsvolumen betrachtet werden aber gleichzeitig ist dieses auch ein Beispiel dafür, wie ich selbst das Blog hier nutze um aus bestehenden Lösungen auch neue Probleme direkt zu lösen.

Damit trage ich sozusagen zu meinen eigenen SAP KnowHow bei, da ich die Lösung mit den lokalen Zusatzfeldern im ersten Moment auch nciht mehr in Erinnerung hatte. Aber dafür gibt es ja glücklicherweise die Artikelsuche im Blog ;-).

Belege zählen im FI Belegjournal

Selbstverständlich ist die beschriebene Vorgehensweise nur ein Weg um an ein Ergebnis zu kommen. Für die Fragestellung mit Kreditorenbelege war die Vorgehensweise schon durch die vorhandene Query und den gewohnten Umgang mit ihr recht naheliegend. Sollen jedoch alle Belege eines Bereiches gezählt werden würde ich die lokalen Zusatzfelder eher innerhalb der mehr in der Finanzbuchhaltung angesiedelten "Query FI Einzelposten als Belegjournal - Belegsegment (BSEG) und Belegkopf (BKPF) verknüpfen" einbinden und mich hier nicht der Nebenrechnung bzw. des Ledger der Profit-Center-Rechnung widmen.

Analyse sprechender Nummernschlüssel in SAP Query

Grundsätzlich hat die Übersetzung von sprechenden Nummernkreise tatsächlich das Potential innerhalb einer Query eine ausführlichere Analyse zu machen. Unter "Auswertung sprechender Nummernkreisintervalle von CO Innenaufträgen mit Query Zusatzfeldcoding und Unterscheidung numerischer oder alphanumerischer Schlüssel" habe ich dieses für Innenauftragsnummern beschrieben und hier auch im Artikel "Drittmittelstatistik nach LOMZ über Recherchebericht und SAP Query" dieses auch für weitere Merkmale genutzt.

Feedback auf meiner Facebook Seite

Das Thema Ausweis Fachbereich werde ich in einen der folgenden Artikeln noch einmal aufgreifen (dann allerdings mit Lehreinheitsbezeichnung) und dabei auch auf das Thema ABAP Code in Excel generieren etwas näher beschreiben. Wobei ich hier schon auf Facebook Ende letzten Jahres (siehe Beitrag auf facebook.com/unkelbach) wirklich hilfreiches Feedback erhalten habe.

Wo ich gerade Facebook anspreche. wer mag kann auch gerne, so auf Facebook angemeldet eine Bewertung für meine Seite abgeben.

 

---

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.

---

Im Artikel "Stammdatenerweiterung von CO-Objekten am Beispiel ergänzende Kostenstelle beim Innenauftrag" wurde schon die Stammdatenerweiterung von Kostenarten, Kostenstellen und Innenaufträgen per Userexit (CMOD) beschrieben. Hierdurch sind bei Kostenstellen (bspw. über die Pflegetransaktionen KS01 Kostenstelle anlegen, KS02 Kostenstelle ändern und KS03 Kostenstelle anzeigen) sowie für Kostenarten (ebenfalls hier über die Transaktionen KA01, KA02, KA03)  die Registerkarte Zusatzfelder vorhanden über die die angelegten kundeneingene Felder gepflegt werden können.

Zusatzfelder per Gruppenrahmen im Auftragslayout CO Innenauftrag aktivieren

Lediglich zur Nutzung der Zusatzfelder für den CO Innenauftrag ist noch Customizing erforderlich, so dass die Felder genutzt werden können. Hierzu muss im Auftragslayout der Gruppenrahmen 09 kundeneigener Felder einer Registerkarte zugeordnet werden.

Dieses kann im Customizing über die Transaktion SPRO unter folgenden Pfad erfolgen:

• Controlling
• Innenaufträge
• Aufragsstammdaten
• Bildschirmgestaltung
• Auftragslayout definieren

Hier können entsprechende Registerkarte für die CO Innenauftragspflege definiert werden und innerhalb eines Register der Gruppenrahmen 09 Kundeneigene Felder zugeordnet werden. Dieses Auftragslayout kann dann einzelnen Auftragsarten zugeordnet werden.

Zusammenhang Auftragsart - Auftragslayout

Sofern einer Auftragsart kein Auftragslayout zugeordnet ist, werden ohnehin alle Felder zur Pflege angeboten. Keine Regel ohne Ausnahme, sofern innerhalb des Auftragslayout über die Feldauswahl einzelne Felder ausgeblendet werden ist dieses nicht der Fall.

In diesen Beispiel soll aber tatsächlich das Auftragslayout genutzt werden. Entsprechend ist auch hier im Customizing die Auftragsart mit dem angelegten Auftragslayout verknüpft.

Dieses ist wiederum im Customizing (Transaktion SPRO) unter

• Controlling
• Innenaufträge
• Auftragsstammdaten
• Auftragsarten definieren

beziehungsweise mit der Transaktion KOT2_OPA möglich.

Eine ausführliche Beschreibung zum Thema Auftragslayout und Auftragsart ist auch in Buch "Schnelleinstieg ins SAP Controlling (CO)" geschildert :-)

Nun stellt sich aber die Frage, welche Auftragsarten nun eigentlich welchen Auftragslayout zugeordnet sind. Dieses kann relativ einfach über die Tabelle T003O "Auftragsarten" zum Beispiel über eine SAP Query anhand der Tabellenfelder in folgender Tabelle ausgewertet werden.

Auswertung Auftragsart und Auftragslayout

Beschreibung	Technischer Name	L	S
Auftragsart	T003O-AUART	X	X
Zusatzfeld Text Auftragsart	TEXT_T003O_AUART	X
Auftragslayout	T003O-LAYOUT	X

Dabei sind L als Listenfeld und S für Selektionsfelder vorgesehen.
Anhand dieser Query kann relativ schnell festgestellt werden, welche Auftragsarten und welches Auftragslayout zur Nutzung der Zusatzfelder angepasst werden muss.

Auswertung Zusatzfelder in Stammdatenlisten (KA23, KS13, KOK5)

Im Stammdatenverzeichnis für Kostenarten über die Transaktion KA23 oder für Kostenstellen über die Transaktion KS13 kann durch Nutzung der Option Selektionsvariante im Abschnitt Zusatzfelder anhand der Schaltfläche Zusatzfelder die kundeneigene Felder über eine freie Abgrenzung genutzt werden.

Im Unterschied dazu ist im Stammdatenverzeichnis für Innenaufträge (Transaktion KOK5) direkt eine Schaltfläche "kundeneigene Felder" nach Auswahl der Option Selektionsvariante vorhanden über die ebenfalls diese freie Abgrenzung erfolgen kann.

Auswertung Stammdatentabelle zum Beispiel per SAP Query

Eine weitere Frage ist, wie die neuen Stammdatenfelder in SAP Query oder in den Tabellen ausgewertet werden können.

Hierbei sind in den einzelnen Tabellen die Zusatzfelder als Customer Include der Stammdatentabelle hinzugefügt. Dieses kann auch in der Transaktion SE12 näher betrachtet werden.

In folgender Tabelle habe ich die Stammdatentabellen und das Include mit aufgeführt.

CI Zusatzfelder

CO Objekt	Tabelle	Include	Bezeichnung
Innenauftrag	AUFK	CI_AUFK	Zusatzfelder CO-Innenauftrag
Kostenstelle	CSKS	CI_CSKS	Zusatzfelder Kostenstelle
Kostenart	CSKB	CI_CSKB	Zusatzfelder Kostenart

Für ein Infoset bietet es sich an, diese Felder aus der Stammdatentabelle dann einer eigenen Feldgruppe zuzuordnen, so dass die Felder dann leicht gepflegt werden können und entsprechend in der Query genutzt werden können.

Werden diese Tabellen in einer Query genutzt werden die Zusatzfelder wie normale Tabellenfelder durch den CustomerINclude (CI) zur Verfügung gestellt.  Somit lassen sich auch die entsprechenden Query problemlos anpassen.
 

---

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.

---

Wie schon im Artikel "Rückblick FI CO Forum Infotage 2016 in Köln und Zürich" geschildert nahm ich dieses Jahr an den FI CO Forum Infotagen mit einen eigenen Vortrag teil und zwischenzeitlich sind auch alle Vorträge, wie im Artikel verlinkt, online abrufbar. Die Vorträge der Vorjahre habe ich am Ende dieses Artikel verlinkt.

So kann auch der Vortrag von mir online nachgelesen werden. Der Vortrag ist unter http://fico-forum.de/ET/infotage_2016/Unkelbach/ online abrufbar.





Da hier die gleiche Technik genutzt wird wie in der digitalen SAP Bibliothek (siehe SAP eBook Flatrate) möchte ich auch gleichzeitig nicht nur auf diesen Vortrag verlinken sondern auch meine Erfahrungen mit der Bibliothek von Espresso Tutorials  vorstellen.

Das Thema Berichtswesen im SAP Controlling ist mittlerweile auch im aktuellen Buch von Andreas Unkelbach zum gleichnamigen Thema behandelt worden.



Dieses ist auch bei Amazon * zu finden. Eine ausführliche Beschreibung ist unter »Berichtswesen im SAP®-Controlling«  zu finden.


 

Personalentwicklung, berufliche Weiterbildung, SAP Kenntnisse durch digitale SAP Bibliothek von Espresso Tutorials

Hier kann in Form einer Jahresgebühr ein Vollzugriff auf alle Bücher des Verlags erlangt werden und diese digital geschmöckert werden. Dabei ist die Website responsiv gestaltet, so dass diese auch am Tablet oder Smartphone bedienbar ist. Trotzdem ist wohl für 2017 auch eine App angedacht.

Nachdem man die Zugangsdaten erhalten hat ist ein direktes Anmelden in der Weboberfläche möglich.



Danach ist eine Übersicht aller verfügbaren Bücher und Videos zu sehen.



Positiv aufgefallen ist mir gleich zu Beginn, dass die Suchfunktion alle vorhandenen Bücher umfasst und hier per AJAX sowohl in der Buchbeschreibung als auch im Buchinhalt die Suchergebnisse anzeigt.

Auf der linken Seite sind sowohl die Sprachen (derzeit Englisch, Deutsch und sogar einzelne Werke in portugiesisch oder fanzösisch) und die Themengebiete in der jeweiligen Sprache aufgeführt.



Hier zeigt sich auch der Vorteil eines digitalen Mediums dadurch, dass auch direkt auf Videos verlinkt werden kann und diese dann bestimmte Vorgänge und Sachverhalte noch besser als das geschriebene Wort beschreiben können.

Sofern nicht in allen Büchern recherchiert werden soll, kann natürlich auch ein einzelnes Buch aufgerufen werden.



Hier wird erst einmal eine kurze Buchbeschreibung gegeben und über die Schaltfläche "Inhalte ansehen" kann direkt auf den Inhalt des Buches Zugriff genommen werden.

In Form eines Schreibtisch kann hier erstaunlich gut lesbar ein Buch im wahrsten Sinne des Wortes durchgeblättert werden.



Besonders positiv ist aber auch, dass über die Symbolleiste jederzeit ein Inhaltsverzeichnis (siehe oben der schwarze Kasten) oder auch die Suchfunktion aufgerufen werden kann. Wobei dieses auch ausgeblendet werden kann und so nur das reine Buch gelesen werden kann. Aber auch aufgeschlagen macht das Buch einiges her.



Hierbei können die einzelnen aufgeschlagene Buchseiten anhand der URL auch als Lesezeichen im Browser hinterlegt werden oder auch versandt werden (dann ist auf der Empfängerseite natürlich ebenfalls ein Zugang erforderlich).

Besonders hilfreich empfinde ich, dass einzelne Verweise innerhalb des Buches oder auch auf externe Quellen direkt aufgerufen werden können und so das Buch interaktiv genutzt werden kann. Dieses gilt nicht nur für das Inhaltsverzeichnis im Buch sondern auch für Tabellen oder einzelne Abbildungen.

Das digitale Blättern innerhalb des Buches und die Suchfunktion kann tatsächlich sehr gut anhand der Vorträge nachempfunden werden.

Sofern ich ein Interesse an dieser Form der digitalen Weiterbildung geweckt habe, würde ich mich freuen, wenn der Menüpunkt "Espresso Tutorials " Interesse weckt, da hier auch ein Online-Zugang für 12 Monate für 99,00 Euro in Partnerschaft mit Espresso Tutorials erworben werden kann. Natürlich erhält man hier auch regelmäßig Updates durch Neuerscheinungen. Ausserdem kann so auch unterwegs auf die Bücher Zugriff genommen werden.

Elektronische und gedruckte Bücher vielleicht als Weihnachtsgeschenk ;-)

Gerade für die Weihnachtszeit kann dieses ein ideales Geschenk sein zumal zwischen den Jahren auch immer ein wenig Zeit für gute Literatur sein sollte und ich hier wirklich vom Buch- und Verlagskonzept begeistert bin :-)). Immerhin sind die Bücher nicht nur intensiv und lehrreich wie ein guter Espresso sondern tatsächlich auch Bücher aus der Praxis für die Praxis :-) und bieten einige Anregungen und Zusammenhängen in den unterschiedlichsten SAP Modulen.

Das im Beispiel vorgestellte Buch kann ich natürlich sowohl in der elektronischen als auch in der gedruckten Form empfehlen.


  Paperback ISBN: 9783960126874

Für 19,95 € direkt bestellen

Oder als SAP Bibliothek-Flatrate *

Ebook ISBN: 9783960120414
 


Alternativ stehen natürlich auch diverse andere Bücher in Papierform und eben auch innerhalb der Flatrate zur Verfügung die ich ebenfalls an dieser Stelle sehr empfehlen kann.

Ich bin schon sehr auf die App Lösung gespannt, aber durch das responsive (mobil angepasste Design) ist es sogar gut möglich am Smartphone hier Zugriff zu erhalten.

Wie erwähnt kann als Beispiel mein Vortrag unter http://fico-forum.de/ET/infotage_2016/Unkelbach/ online abgerufen werden.

Wie erwähnt für die persönliche oder auch betriebliche Weiterbildung kann ich das Angebot der digitalen Bibliothek sehr empfehlen. Zur Verdeutlichung kann auch unter "Die digitale SAP Bibliothek" anhand eines Videos ebenfalls ein guter Eindruck vom Angebot und der Oberfläche gewonnen werden. Eine kleine Auswahl habe ich auch im Artikel "Werbung - Fachliteratur rund um SAP Themen" sowie "Schnelleinstieg ins SAP Rechnungswesen mit cat content ;-)" vorgestellt und bin überzeugt, dass diese Bücher auch geeignet sind sich in die SAP Materie gerade bei bisher nicht so oft genutzten Modulen einzuarbeiten. Der größte Vorteil ist hier neben Praxisbezug auch die kompakte und verständliche Darstellung des Buch.

Unterlagen FI CO Forum Infotage

Wie im Artikel schon angekündigt sind mittlerweile auch alle Unterlagen der verschiedenen Infotage online gestellt worden. Zwar sind nicht von allen Jahren die Beiträge online gestellt, aber ab 2014 sind die Unterlagen noch immer aufrufbar. Die Veranstaltung selbst gibt es seit 2012 und ab 2014 sind die Vorträge ebenfalls online gestellt worden.

• 3. FI CO Infotage 2014
• 4. FI CO Infotage 2015 
• 5. FI CO Infotage 2016

So informativ diese Unterlagen jedoch auch sind, so sehr würde ich einen Besuch vor Ort jedoch empfehlen, da oftmals ergänzend zu den Folien weitere Informationen gegeben werden und natürlich auch solch eine Fachtagung vom gegenseitigen Austausch lebt. Meine erste Erfahrungen mit dieser Tagung (in 2016) habe ich im Artikel "Rückblick FI CO Forum Infotage 2016 in Köln und Zürich"  geschildert.

Schon im Artikel "Einzelposten Klassische Budgetierung Hierarchiebelge" wurde die logische Datenbank FMF "Haushaltsmanagement (Klassische Budgetierung)" zur Auswertung von Budgetbelegen und einer entsprechenden Kontrolle verwendet. Allerdings sind hier auch Bewegungsdaten über die beiden Tabellen FMTOX "Summensätze: Obligo und Ist   - Erweitert" und FMOIX "Einzelposten  - Erweitert" vorhanden. Bei beiden handelt es sich jedoch nicht um eine transparente Tabelle sondern um eine Struktur welche erst zur Laufzeit mit entsprechenden Daten versorgt wird.

Der Vorteil bei der Verwendung einer logischen Datenbank, wie im Beispiel FMF, ist dass hierdurch für die Query zur Laufzeit ebenfalls notwendige Daten zur Verfügung gestellt werden.

Infoset über logische Datenbank FMF

Aus der vorherigen Infoset (Budgetauswertung) sind noch folgende Feldgruppen vorhanden:

Feldgruppe 01 "Budgetbelege Gesamtbudget"
Fonds ( BPBTX-FONDS )
Finanzstelle ( BPBTX-FICTR )
Finanzposition ( BPBTX-FONDS )
Belegnummer Budgetvergabe und Strukturplanung ( EPBT-BELNR )
Positionstext ( EPBT-BELNR )
Gesamtbudget in Finanzkreiswährung ( EPBT-WLGES )

Feldgruppe 02 "Budgetbelege Jahresbudget"
Fonds ( BPBYX-FONDS )
Finanzstelle ( BPBYX-FICTR )
Finanzposition ( BPBYX-FIPEX )
Belegnummer Budgetvergabe und Strukturplanung ( EPBY-BELNR )
Positionstext ( EPBY-SGTEXT )
Verteiltes Jahresbudget in Finanzkreiswährung ( EPBY-WLJHV )

Ergänzend zum bestehenden Infoset der Budgetbelege im oben verlinkten Beispiel werden folgende Feldgruppen angelegt um hier sowohl Einzelposten als auch Summen über eine Query auswerten zu können.

Für Saldenliste:
FMTOX - "Summensätze: Obligo und Ist   - Erweitert"

Für Einzelposten:
FMOIX - "Einzelposten  - Erweiter"

Dabei werden folgende Felder werden in die jeweiligen Feldgruppen übernommen:

Feldgruppe 03 "Summensätze Obligo Ist"
Finanzposition ( FMTOX-FIPEX )
Finanzstelle ( FMTOX-FICTR )
Fonds ( FMTOX-FONDS )
Geschäftsjahr ( FMTOX-GJAHR )
Periode ( FMTOX-PERIO )
Werttyp ( FMTOX-WRTTP )
Obligo/Ist (Zahlungsbudget) in Finanzkreiswährung ( FMTOX-FKBTRP )
HHM: Budgetperiode ( FMTOX-BUDGET_PD )
Betragsart ( FMTOX-BTART )

Feldgruppe 04 "Einzelposten"
Finanzstelle ( FMOIX-FICTR )
Fonds ( FMOIX-FONDS )
Finanzposition ( FMOIX-FIPEX )
Geschäftsjahr ( FMOIX-GJAHR )
Periode ( FMOIX-PERIO )
Werttyp ( FMOIX-WRTTP )
Buchungsdatum im Beleg ( FMOIX-BUDAT )
Im Workflow verarbeiteter Betrag in Finanzkreiswährung ( FMOIX-FKBTRW )
Positionstext ( FMOIX-SGTXT )

Danach wir das Infoset generiert und gesichert.

Query Saldenliste PSM-FM

Für unsere Auswertung sind jedoch nur die Salden je Finanzposition erforderlich. Durch die Feldgruppe 03 beziehungsweise der Struktur FMTOX können je Finanzposition alle Buchungen zusammengefasst werden.

Da hier eine logische Datenbank ausgewertet wird, müssen keine Selektionsfelder definiert werden, da die Selektion für die Daten vom Infoset her selbst vorgegeben werden. Entsprechend sind alle Felder als Listenfelder (L) markiert worden. Die Felder werden hier in der Reihenfolge angegeben, wie diese dann auch in der Query ausgegeben werden sollen:

Jahr (L) FMTOX-GJAHR
Periode (L) FMTOX-PERIO
Finanzstelle (L) FMTOX-FICTR
Fonds (L) FMTOX-FONDS
Fondtext (L) Zusatzfeld von FMTOX Text: Fonds  TEXT_FMTOX_FONDS
Finanzposition (L) FMTOX-FIPEX
WT (L) technische Nummer Werttyp FMTOX-WRTTP
Werttyp (L) Zusatzfeld von FMTOX Text: Wertyp  TEXT_FMTOX_WRTTP
Obligo/Ist Zahl.Budget (L) FMTOX-FKBTRP
(Hierbei ist bei der Währungsfeldposition die Option kein Währungsfeld ausgewählt)
Betragsart (L) FMTOX-BTART
Betragsart (L) Zusatzfeld von FMTOX Text: Betragsart  TEXT_FMTOX_BTART

Als Summationsfeld ist das Feld "Obligo/Ist" gewählt worden, so dass hier eine Zwischensumme beim Aufruf der Query gebildet wird. Im Ergebnis werden nun die Summen je Finanzposition unterschieden nach Werttyp ausgegeben. Dabei sind die Einzelposten nicht ersichtlich, so dass nicht mehr Personen etc. erkennbar sind.

Soweit besteht nun eine Liste der Ergbisse je PSM-FM-Objekt und es können hier Summen über diverse Konten (Finanzpositionen), Finanzstellen oder Fonds gebildet werden.

Erweiterung Query zum Ausweis von Ertrag, Aufwand und Personalkosten

Der Vorteil dieser Query gegenüber dem Belegjournal (Transaktion FMRP_RFFMEP1AX ) ist, dass hier direkt eine Summe je Finanzposition ausgewiesen wird und nicht die Einzelposten mit ausgewiesen werden. Sofern mehr Interesse an den Einzelposten besteht dürfte eher der Artikel "Kundeneigene Transaktionen zu Berichten in PSM FM Haushaltsmanagement zum Beispiel Belegjournal anlegen (Variantentransaktion)" hiflreich sein.

Wie auch schon im Artikel "Query Einzelpostenliste Innenauftrag mit Ausweis Ertrag und Aufwand Zweiter Teil Query zur Datenaufbereitung" vorgeschlagen kann anhand der Finanzposition die einzelne Buchung auch einer bestimmten Gruppierung zugeordnet werden.

Neben der reinen Auswertung  der im Infoset zur Verfügung gestellten Feldern kann innerhalb der Query auch die Ergebnisse dieser Datenbankabfrage verarbeitet werden.

Kurzbezeichnung für Finanzposition  und Wert

Dazu müssen einzelnen Feldern eine Kurzbezeichnung zugewiesen werden um auf diese in den lokalen Feldern dann Bezug genommen werden zu können.

Hierzu gehen wir nicht in die Grundliste der Query (wo später  auch das Layoutdesign gepflegt wird) sondern wechseln innerhalb der Querypflege mit nächstes Bild (F6) auf die Feldauswahl der Query. Sofern wir uns noch in der Layoutpflege befinden kann über Zurück dorthin gewechselt werden. Alternativ kann auch im Menü über

SPRINGEN->FELDAUSWAHL->FELDAUSWAHL

in die Feldauswahl der Query gewechselt werden.

Achten Sie bitte darauf, dass über

EINSTELLUNGEN ->EINSTELLUNGEN

der grafischer Query Painter aktiviert ist, wobei dieses auch im Standard der Fall sein sollte. Andernfalls würde sich die Oberfläche zur Querydefinition etwas ändern (was zwar mehr Möglichkeiten bietet, aber leider auch ein wenig am Komfort der Pflege von Query verhindert.

Um den einzelnen Feldern eine Bezeichnung zuzuweisen ist es erforderlich über die Funktion

BEARBEITEN->KURZBEZEICHNUNGEN ->EINSCHALTEN

einzelne Felder eine Kurzbezeichnung zuordnen und mit dieser Bezeichnung dann arbeiten.

Erst nachdem die Kurzbezeichnungen eingeschaltet sind, kann über die Feldauswahl eine Kurzbezeichnung den einzelnen Feldern des Infoset zugewiesen werden.

Hierzu sollen nun das Feld Finanzposition die Kurzbezeichnung FIPO und das Feld Obligo/Ist (Zahlungsbudget) in Finanzkreiswährung die Kurzbezeichnung WERT erhalten.
 

Lokales Feld für Ertrag, Aufwand und Personalkosten anlegen

Die nun zugewiesenenKurzbezeichnungen WERT und FIPO sind notwendig, da wir auf diese dann Bezug nehmen, wenn wir ein lokaes Feld mit einer Formel anlegen.

Dieses geht über

BEARBEITEN->LOKALES FELD->ANLEGEN.

Dieses Lokale Feld wird dann in der Feldgruppe  "Summensätze Obligo Ist" angelegt, in der wir uns gerade befinden und die auch die einzige ist, die wir für die Saldenliste verwenden.

Nun können folgende Felder angelegt werden.

1. Lokales Feld ERTRAG_5
Kurzbezeichnung:  ERTRAG_5
Feldbezeichnung: 5er Ertrag
Überschrift: 5er Ertrag
Eigenschaften:
Gleiche Eigenschaften wie Feld:  WERT
Berechnungsvorschrift:
Hier muss ausnahmsweise keine komplexe Berechnung eingetragen werden, da wir nur eine Bedingung (ein Intervall an Kostenarten) benötigen.

Entsprechen lautet die Berechnung  WERT
und die zugehörige Bedingung
FIPO >= 50000000 AND FIPO <= 59999999

Alternativ kann dieses auch als
Bedingung:  FIPO >= 50000000 AND FIPO <= 59999999
Formel: WERT

angegeben werden und Sonst leer gelassen werden. Somit wird das Feld Wert nur im lokalen Feld ausgegeben, wenn die Kostenart zwischen 50000000  und 59999999 liegt.

Genauso definieren wir folgendes Feld:

2. Lokales Feld AUFWAND_6
Kurzbezeichnung:  AUFWAND_6
Feldbezeichnung: 6er Aufwand
Überschrift: 6er Aufwand
Eigenschaften:
Gleiche Eigenschaften wie Feld:  WERT
Berechnungsvorschrift:
Bedingung: FIPO >= 60000000 AND FIPO <= 69999999
Formel: WERT

Hierdurch haben wir schon einmal eine Unterscheidung nach Ertrag und Aufwand.

Exkurs: Kontenrahmen und Kostenartenintervalle am Beispiel Personalkosten

Nehmen wir als Beispiel den Industriekontenrahmen (IKR). Hier sind die einzelnen Kontenklassen ebenfalls als Intervalle gepflegt.

Innerhalb der Klasse 6 (Betriebliche Aufwendungen) wären die Personalkosten in den Intervallen Löhne (620000 bis 629999), Gehälter (630000 bis 639999) und Personalnebenkosten (640000 bis 649999). Je nach Sichtweise können zu den Personalkosten auch die Sonstigen Personalaufwendungen (660000 bis 669999) betrachtet werden unter die unter anderen die  Aufwendungen für Fort- und Weiterbildung fallen.

Ein weiteres Feld soll nun jedoch auch für den Ausweis von Personalkosten genutzt werden. Hierzu definieren wir diese als Intervall von 62* bis 64*.

3. Lokales Feld AUFWAND_6PERS
Kurzbezeichnung:  AUFWAND_62-64_Peko
Feldbezeichnung: 6er Personalaufwand
Überschrift: 6er Personalaufwand
Eigenschaften:
Gleiche Eigenschaften wie Feld:  WERT
Berechnungsvorschrift:
Bedingung: FIPO >= 62000000 AND FIPO <= 64999999
Formel: WERT

Jedes dieser lokalen Felder kann natürlich ebenfalls in der Query übernommen werden (dafür sind diese ja vorgesehen) und so kann die Query weiterverarbeitet werden.

Eine in meinen Augen sehr praktische Möglichkeit der Weiterverarbeitung in Excel ist hier durch Pivot-Tabelle in Kombination mit Datenschnitten (siehe Artikel "Pivottabellen ab Excel 2010 dynamischer filtern mit Datenschnitten am Beispiel Hochschulfinanzstatistik") möglich. Grundsätzlich liessen sich die Berechnungen für Ertrag, Aufwand etc. auch in Excel über WENN Funktion erheben oder (was ich noch nicht versucht habe) auch wie im Artikel "Excel Berechnete Felder in Pivottabellen" durchführen.

Inwieweit die Daten später dann auch graphisch aufbereitet werden (hier sei der Artikel "Datentrends für Drittmittelstatistik mit Sparklines ab Excel 2010 darstellen durch Liniendiagramme in Zellen" mit Hinweis auf verschiedene Gestaltungsmöglichkeiten erwähnt oder ob die Query selbst nur eine gute Basis für Datenanalysen sein soll steht wieder auf einer anderen Seite. Gerade für das Gestalten von Daten möchte ich gerne auf einen Beitrag von Ing. Katharina Schwarzer hinweisen "Meine Daten – meine Informationsquelle: Wichtige Tipps für das Reporting". Die an dieser Stelle erwähnten Grundsätze zur Gestaltung einer soliden Datengrundlage sollten auch bei der Erstellung einer Query beachtet werden, da auch hier die Form der Datenauswertung entscheidend ist. In diesen Zusammenhang möchte ich auch gerne das Blog von ihr "Soprani Software" empfehlen, dass ebenfalls durch strukturierte und gut verständliche Artikel punktet.

Der Vorteil der oben beschriebenen Auswertung kann mit zwei Punkten beschrieben werden:

• Die Daten werden als Liste sowohl mit Finanzstelle als auch Fond ausgegeben. Hier würde im Recherchebericht nur der Fond BLANK oder WIPLAN für die Finanzstellen ausgegeben werden
• Die Einzelposten würden anonymisiert werden, da die einzelnen Positionen mit Belegtext zusammengefasst sind und diese Info nicht vorhanden ist

Ansonsten ist für eine reine Betrachtung der Fonds der Artikel "Saldenliste für Fonds im Haushaltsmanagement Saldo gegen Ertrag und Saldo gegen Budget" ebenfalls hilfreich.

---

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.

---

Einer der Vorteile bei der Erstellung einer Drittmittelstatistik auf Basis einer leistungsorientierten Mittelzuweisung (LOMZ) Definition von einzelnen Drittmittelgebern über einen Recherchebericht (siehe "Saldenliste für Fonds im Haushaltsmanagement Saldo gegen Ertrag und Saldo gegen Budget") ist dass hier der Finanzierungszweck ergänzend zu den einzelnen Finanzpositionen (zum Beispiel über alle innerhalb der Hierarchie der Finanzpositionen der Finanzposition ERTRAEGE zugeordneten Finanzpositionen) als einzelnen Spalten definiert werden können. Auf diese Weise können alle Erträge vom Bund (einzelnen Finanzierungszwecke) kombiniert mit den Einnahmen ausgewiesen werden.

Damit werden alle Fonds entsprechend ihres Mittelgebers ausgewiesen. Ergänzend dazu könnten noch einzelne Finanzpositionen ohne Zuordnung eines Finanzierungszweckes ausgewiesen werden, so dass auch Einnahmen die auf Kostenstellen bzw. Finanzstellen oder aber Fond WIPLAN (zur Abbildung des Landeshaushalt) so zum Beispiel Geldspenden ausgewiesen werden.*

Im Artikel "Kundeneigene Transaktionen zu Berichten in PSM FM Haushaltsmanagement zum Beispiel Belegjournal anlegen (Variantentransaktion)" hatte ich schon etwas ausführlicher beschrieben, wie ein solcher Bericht (neben Einzelpostenlisten) in einer vorgegebenen Variante als kundeneigene Transaktion ausgerollt werden kann. Besonders bei Rechercheberichten bietet sich hier auch der Artikel "Parametertransaktion für Recherchebericht" zum Nachlesen an.

Nehmen wir nun aber einmal an, dass ein Finanzbericht über alle Projekte (sowohl Drittmittel als auch diverse Sondermittel) berichtet werden sollen, dann kann es sinnvoll sein hier die Definition von LOMZ fähigen Drittmitteln und andere Projekten nicht nur anhand des Finanzierungszwecks sondern auch über andere Merkmale zu definieren.

Im Anwendungsfall sind Mittel Dritter (Drittmittel) über ein Nummernintervall als für die Drittmittelstatistik relevant festgelegt und eine Teilmenge davon ist als Dienstleistungsprojekt (reine Anwendung gesicherter Erkenntnisse) nicht als LOMZ-relevant identifizierbar. Hierzu wurde in der Klassifizierung ein Merkmal PBW für die Projektbewertung definiert und dieses entsprechend mit den Wert DL versehen. Eine Auswertung von Merkmalen der Klassifizierung ist beispielsweise im Artikel "Query über COEP, AUFK und FMFINCODE für Einzelposten Istkosten Innnenauftrag mit Stammdaten aus CO und PSM-FM sowie Spalten für Ertrag und Aufwand - Erster Teil Infoset als Datengrundlage" oder aber mit Grundlagen zur Klassifizierung auch im Artikel "SAP Query - Auswertung Merkmale der Klassifizierung am Beispiel Fonds in PSM-FM" beschrieben.

Sprechende Nummernschlüssel bei Stammdaten

Kleiner Hinweis am Rande, das Thema sprechende Nummernschlüssel wurde sehr ausführlich in unseren Buch
 

Schnelleinstieg ins SAP-Controlling (CO)

Autoren: Andreas Unkelbach, Martin Munzel

Verlag: Espresso Tutorials GmbH

1. Auflage (01. November 2015)

Paperback ISBN: 9783960126874

Für 19,95 € direkt bestellen

Oder als SAP Bibliothek-Flatrate *

Ebook ISBN: 9783960120414
 
diskutiert und zeigt hier tatsächlich unterschiedlichste Ansätze in der Stammdatenkonzeption, aber dieses nur am Rande.

Um nun über Nummernkreis und Merkmale der Klassifizierung die Drittmittel entsprechend einzuordnen bedarf es drei Zusatzfelder im Infoset.

Vorbedingung: Auswertung PSM und CO Stammdaten

Als erstes müssen, erneut, die Stammdaten von CO mit PSM verknüpft werden.

Innerhalb des Abschnitt "Zusatzfeld ZAUFNR (Übernahme AUFK-AUFNR als FMFINCODE-FINCODE" im Artikel "SAP Query innerhalb des SAP Moduls PSM FM beziehungsweise Haushaltsmanagement" wurde nun eine clevere Alternative dargestellt.

Zusatzfeld ZAUFNR zur Verknüpfung von Innnenauftrag und Fond

Hierzu wurde das Zusatzfeld ZAUFNR mit per LIKE-Referenz FMFINCODE-FINCODE erstellt was in den folgenden Abschniten als Hilfsfeld genutzt werden kann.

Als erläuternde Überschrift und Langtext kann "Auftragsnummer 10 stellig" genommen werden.

Das in meinen Augen clevere Coding beschränkt sich auf einen Einzeiler in dem dem Feld per Offset die Auftragsnummer aus der Tabelle AUFK zugewiesen wird.

Für eine achtstellige Projektnummer (Innenauftrag) lautet das Coding wie folgt:

ZAUFNR = AUFK-AUFNR+4(8).

Hierbei bedient sich das Coding der Technik eines Offsets.

Durch die optionalen Angaben eines Offsets +<o> und eine Länge (<l>) direkt hinter dem Feldnamen <f>, wird der Teil des Felds, der auf Position <o>+1 beginnt und die Länge <l> hat, als eigenes Datenobjekt angesprochen.  In unseren Fall wird also für die Variable ZAUFNR das Feld AUFK-AUFNR (wir erinnern uns die zwölfstellige Auftragsnummer) eingelesen und ab der vierten Stelle insgesamt acht Stellen eingelesen. Da in der Datenbank die Auftragsnummer mit führenden 0000 hinterlegt wird erhalten wir also statt des Datenbankwerte 000012345678 die tatsächliche Auftragsnummer 12345678.

Sollten Sie eine andere Länge bei den Aufträgen oder Fonds definiert haben ist das Coding natürlich entsprechend anzupassen.

Im Ergebnis haben wir nun das Feld ZAUFNR, welches die gleichen Eigenschaften wie das Feld FINCODE innerhalb der Tabelle FMFINCODE hat.

Nun kann das Feld für verschiedene Formen der Verknüpfung genutzt werden.
 

Merkmal aus Klassifizierung zur Projektbewertung mit auswerten

Nehmen wir an, dass im Rahmen der Klassifizierung von Fonds im Modul PSM-FM die Projektbewertung in ein Merkmal festgehalten wird. Dann ist auch die im Artikel "SAP Query - Auswertung Merkmale der Klassifizierung am Beispiel Fonds in PSM-FM" erheblich erleichtert.

Hierzu wird ebenfalls ein Zusatzfeld bspw. PBW für Projektbewertung mit Langtext und Überschrift Projektbewertung erstellt.

Dieses hat als Eigenschaften eine LIKE-Referenz auf AUSP-ATWRT.

Ferner wird im unteren Abschnitt des Fenster bei Reihenfolge des Codeabschnitts ebenfalls eine 2 eingetragen.

Danach wird als Coding zum Zusatzfeld ein passendes Coding zum Zusatzfeld hinterlegt, dass aus der Variable (Zusatzfeld) ZAUFNR und den Buchungskreis bzw. Finanzkreis eine Objektnummer erstellt, die dem Feld AUSP-OBJEK. entspricht.


Unter der Annahme eines dreistelligen Finanzkreis KRK und dass das Merkmal die Interne Merkmalsnummer (Feld ATINN) folgenden Wert hat 0000000022 hat wird folgendes Coding zum Feld hinterlegt:

DATA: L_objfond TYPE AUFK-AUFNR.
DATA: L_MERKMALPBW TYPE AUSP-ATWRT.

CONCATENATE  'KRK ' ZAUFNR INTO L_OBJFOND RESPECTING BLANKS.

SELECT SINGLE ATWRT INTO L_MERKMALPBW FROM AUSP
 WHERE OBJEK = L_OBJFOND AND ATINN ='0000000022' AND KLART = '042'.
IF sy-subrc <> 0.
  CLEAR PBW.
ELSE.
  PBW = L_MERKMALPBW.
ENDIF.

Im Ergebnis enthält nun das Feld PBW die in der Klassifizierung hinterlegte Projektbewertung des Fond.

LOMZ relevante Drittmittel

Nun kommt allerdings die Zuordnung über die Projektnummer in Kombination zu der Projektbewertung. Hierzu wird die gleiche Programmlogik verwendet wie im Artikel "Auswertung sprechender Nummernkreisintervalle von CO Innenaufträgen mit Query Zusatzfeldcoding und Unterscheidung numerischer oder alphanumerischer Schlüssel" allerdings beschränkt auf einen Nummernkreis der Drittmittelprojekte sowie einen Bezug auf die Projektbewertung über das Feld PBW.

Hierzu wurde ein Zusatzfeld LOMZ mit den Eigenschaften LIKE AUSP-ATWRT im letzten Codeabschnitt des Infoset (hier Reihenfolge des Codeabschnitts 4) angelegt.

Das zugehörige Coding zum Zusatzfeld sieht dabei wie folgt aus:
 

CLEAR LOMZ.
IF AUFK-AUFNR CO  '1234567890'.
  IF AUFK-AUFNR => '000032000000' AND AUFK-AUFNR <= '000032999999'.
    CASE PBW.
      WHEN 'DL'.
        LOMZ = 'DL'.
      WHEN OTHERS.
        LOMZ = 'LOMZ'.
    ENDCASE.
  ENDIF.
  IF AUFK-AUFNR => '000042000000' AND AUFK-AUFNR <= '000042999999'.
    CASE PBW.
      WHEN 'DL'.
        LOMZ = 'DL'.
      WHEN OTHERS.
        LOMZ = 'LOMZ'.
    ENDCASE.
  ENDIF.
ENDIF.

Dieses Zusatzfeld hat nun für die Beispielnummernkreise 32000000 bis 32999999 und 42000000 bis 42999999 eine Überprüfung, ob es sich dabei um LOMZ Drittmittel oder nur DL für Dienstleistungsprojekte handelt. Die in anderen Nummernkreise abgebildeten Projekte sind keine Drittmittel auf die die LOMZ Definition angewandt wird und erhalten daher auch keinen Wert im Zusatzfeld LOMZ (das Feld bleibt daher leer).
 

Weiterentwicklung Query oder Recherchebericht zur Drittmittelstatistik

Ergänzend zur LOMZ Definition können nun natürlich auch noch die Mittelgeber der jeweiligen Projekte über den Finanzierungszweck identifiziert werden. Gerade für ein zentrales Berichtswesen kann hier eine Gruppierung der einzelnen Finanzierungszwecke, so als Beispiel die einzelnen EU Förderprogramme, zu Gruppen erfolgen, oder eben einfach der Finanzierungszweck ebenfalls mit ausgegeben werden. 

Diese Methodik ist im Artikel "Gruppierung von Finanzierungszwecken bei Drittmittelprojekten per Zusatzfeldcoding mit IF oder CASE" erläutert worden.

In Kombination mit einen Recherchebericht oder auch direkt einer Einzelpostenliste als SAP Query, wie im Artikel "Query Einzelpostenliste Innenauftrag mit Ausweis Ertrag und Aufwand Zweiter Teil Query zur Datenaufbereitung" kann nun relativ ohne Probleme eine entsprechende Auswertung der Drittmittelstatistik erfolgen. Denkbar wäre auch eine Saldenliste basierend auf der logischen Datenbank FMF in der die Summen je Finanzposition auf Kontierungsobjekt FOND und Finanzstelle ausgewertet werden können. Diese logische Datenbank habe ich bisher für die Auswertung von "Einzelposten Klassische Budgetierung Hierarchiebelge" verwendet denkbar ist hier aber auch die Summensätze der Tabelle FMTOX "Summensätze: Obligo und Ist   - Erweitert" in der die Summen je Kontierungsobjekt festgehalten sind. Hier hat ein Kollege einen recht praktischen Extrakt der Summensaldenliste je Finanzposition auf Ebene der Fonds entworfen. Ein Nachteil ist hier nur noch, dass zur Darstellung von Ertrag und Aufwand das Ergebnis erneut summiert werden muss. Jedoch ist dieses über lokale Felder oder Zusatzfelder die die Finanzpositionen gemäß Industriekontenrahmen (Kontenplan) beginnend mit 5*als Ertrag und 6* als Aufwand zuordnen können.

Sind die Berichte fertig erstellt können diese auch per Serienmail versandt werden. Bisher nutzte ich nur die Serienmailfunktion in Winword zum Versand von Serienmails (siehe Artikel "Serienmails über Serienbrieffunktion in Winword per Outlook, Thunderbird oder anderen Mailprogramm versenden") auf Facebook (siehe Beitrag vom 22.10.2016) bin ich jedoch auf zwei Methoden getroffen durch die entweder durch Plugin im Mailer Thunderbrid oder per VBA mit Outlook auch Dateianhänge wie ein Finanzbericht automatisch per Serienmail versandt werden können, so dass diese Berichte nicht zum Beispiel im SAP Business Work Place (siehe Artikel "SBWP: Berechtigungen Allgemeine Ablage") abgelegt werden müssen sondern auch direkt an die Finanzberichtsempfänger versandt werden können.

Innerhalb Excel sind dann natürlich auch graphische Analysen, wie im Artikel "Datentrends für Drittmittelstatistik mit Sparklines ab Excel 2010 darstellen durch Liniendiagramme in Zellen" beschrieben möglich. Wobei dieser Artikel gleichzeitig neben Sparklines auch verschiedene andere Auswertungsmöglichkeiten per Excel darstellt wodurch auch auf einen Blick die Bedeutung der einzelnen Daten hervorgehoben werden können.
 

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

---

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.

---

Neben der Nutzung des Finanzierungszwecks im SAP Modul PSM-FM der entsprechende Fonds zusammenfasst (siehe hierzu Artikel "PSM-FM Grundlagen Finanzierungszweck im Haushaltsmanagement bei Recherchebericht und Selektion") wird im SAP Modul CO ein sprechender Schlüssel für CO Innenaufträge verwendet um hier anhand eines Zahlenintervalls eine Zuordnung zu bestimmten "Projektbereichen" zuzuordnen.

Sprechender Nummernkreis für CO Innenaufträge

Auch wenn die Verwendung von sprechenden Nummern nicht unumstritten ist (eine entsprechende Diskussion zu diesen Thema findet sich auch im Buch "Schnelleinstieg ins SAP Controlling (CO)" wo sowohl Vorteile als auch Nachteile einer Verwendung von sprechenden Nummern dargestellt werden. Wesentlicher Punkt war hier, dass Auftragsnummern im Nachhinein im Gegensatz zu anderen Stammdaten nicht verändert werden können und hier ein anfangs großzügig vorgesehener Nummernkreis nach einigen jahren eventuell aufgebraucht ist.

Auf diese Diskussion gehe ich nun aber nicht weiter ein sondern nehme bestehende Nummernkreisintervalle und Zuordnung zu Bereichen als gegeben hin und möchte nun in einer Query klären in welchen Bereich ein CO Innenauftrag zuzuordnen ist.

Prüfung ob eine Auftragsnummer innerhalb eines Nummernintervall liegt

Innerhalb von Excel kann dieses, wie im Artikel "Prüfung inwieweit ein Wert, bspw. eine Kostenstelle, innerhalb eines Intrevalls (Gruppe) liegt in Excel" beschrieben" durch eine VERWEIS Funktion realisiert werden. Auch Stammdatengruppen, sogenannte Sets können über eine Query (siehe Artikel "Auflösen von Stammdatengruppen nach Einzelwerten - Einzelwerte zu Sets") durch die Verknüpfung zweier Auswertungen zugeordnet werden.

Eine erheblich elegantere Möglichkeit ist es aber in einer Stammdatenauswertung vergleichbar zur Gruppierung von FINANZIERUNGSZWECK auch die Innenauftragsnummernintervalle entsprechend einer Gruppe virtuell zuzuordnen.

Coding von Zusatzfeld für Gruppierungen

Im Artikel "Gruppierung von Finanzierungszwecken bei Drittmittelprojekten per Zusatzfeldcoding mit IF oder CASE" wurde ja schon die Zuweisung von einzelnen Werten je Fall (CASE) mit mehreren Bedingungen (OR) dargestellt, so dass einzelne Finanzierungszwecke zusammengefasst werden konnten. Als Beispiel waren hier die unterschiedlichen EU Rahmenprogramme und die Zuordnung zu EU Mitteln erwähnt.

Einen ähnlichen Fall wurde schon im Abschnitt "Zusatzfeld VLE zur Darstellung virtueller Lehreinheit aus Teilstring der verantwortlichen Kostenstelle sofern nicht in einen anderen Feld ein Wert steht" des Artikel "Query über COEP, AUFK und FMFINCODE für Einzelposten Istkosten Innnenauftrag mit Stammdaten aus CO und PSM-FM sowie Spalten für Ertrag und Aufwand - Erster Teil Infoset als Datengrundlage" beschrieben.

Die Ermittlung der VLE im Infoset anstatt in der Query per lokale Zusatzfelder wie im Artikel "Query über verantwortliche Kostenstelle des Innenauftrag - Bestimmung der Lehreinheit im Fachbereich durch Teil der Kostenstellennummer" hat den enormen Vorteil, dass hier alle Query die auf dieses Infoset aufbauen auch die Angabe des Bereichs oder die VLE auswerten können ohne selbst in der Query mühsam Felder zu basteln.

Analog zur Excellösung werden hier die vorrangestellten Nullstellen durch NO-ZERO entfernt, so dass danach ein Größenvergleich durchgeührt werden kann. Dabei gehe ich davon aus, dass die Innenauftragsnummern tatsächlich numerisch sind. Andernfalls muss man sich mit der Reihenfolge von alphanumerischen Intervallen beschäftigen.

ABAP: Enthält Variable nur Zahlenwerte

Vorab sollte man sich jedoch bewust sein, dass ein Innenauftrag als Schlüsselfeld durchaus alphanumerische Werte enthalten kann. Hier stellt sich also die Frage, wie es möglich ist die Auftragsnummer zu überprüfen, ob tatsächlich nur Zahlenwerte enthalten sind.

Hier kann eine Wenn Funktion (IF) mit der vergleichendenen Anweisung CO (contains only) weiter helfen. ABAP hat einige Vergleichsoperatoren, so dass hier Variablen mit Variablen oder aber auch mit bestimmten Werten verglichen werden können. Zu diesen logischen Ausdrücken gehört unter anderen CO (contians only), CN (contains not only) und weitere. Diese liefern ein Wahr wenn der Vergleich erfolgreich war und nur die Zeichen des Vergleichsparameter vorhanden war (CO) oder aber wenn noch weitere Zeichen dabei sind (CN). Interessant ist auch noch die Möglichkeit CS (contains string) womit vergleicht werden kann, ob eine bestimmte Zeichenfolge in einen Wert vorhanden ist.

Ein ausführliches Beispiel wäre

DATA: L_ZAHLEN(10) TYPE c VALUE = '0123456789'.
* L_zahlen enthaelt Zahlenwerte Leerzeichen
DATA: L_innenauftrag type AUFK-AUFNR.

IF L_innenauftrag CO L_ZAHLEN.
* Reine Auftragsnummer

ELSEIF.
* Alphanumerischer Innenauftrag

ENDIF.

Selbstverständlich lässt sich dieses auch ohne Definition einer Konstanten regeln. Hierzu kann folgende Anweisung erstellt werden:

IF AUFK-AUFNR CO  '1234567890'.
* Innenauftrag hat nur Nummern
ELSEIF.
*Innenauftrag ist alphanumerisch
ENDIF.

Damit kann nun mit den vorhandenen Zahlenwerten weitergearbeitet werden.
Sollten auch Nachkommastellen oder Leerzeichen in Ordnung sein, muss der Vergleichsoperator um . und Leerzeichen erweitert werden. Allerdings sind dann neben Währungen oder Zahlen mit Nachkommastellen auch IP Adressen gültig. Als Beispiel ist hier der allzeits beliebte Public DNS (Domain Name System) von Google wie 8.8.8.8 oder 8.8.4.4 gültig. Sollte damit später gerechnet werden, ist das natürlich wesentlich schwieriger jedoch würde es 100 % in das Vergleichsmuster passen.Zugegeben diese Lösung ist nicht so elegant wie die Funktion ISNUMERIC innerhalb VBA (siehe Abschnitt "Negativzeichen hinter Zahlenwert" im Artikel "Office Integration - Excelansicht in SAP und Daten kopieren nach Excel", aber im Ergebnis liefert es in diesen Fall den gewünschten Effekt.
 

ABAP Prüfung ob Auftragsnummer innerhalb Nummernintervall

Nachdem mit oberen Coding geprüft worden ist, ob es sich bei der Auftragsnummer um eine Zahl handelt kann nun eine Prüfung erfolgen, inwieweit ein Innenauftrag innerhalb eines bestimmten Intervalls liegt und hierzu ein entsprechender Hinweis gegeben werden.

Ausgangspunkt ist das Tabellenfeld AUFK-AUFNR mit insgesamt 12 Zeichen. Hierbei sind die Auftragsnummern, sofern sie nicht 12 Zahlen umfassen mit führenden 0 abgespeichert. Nun besteht entweder die Möglichkeit eine Hilfsvariable zu definieren und über die Anweisung:

DATA: L_Innenauftrag TYPE C LENGTH 8.
WRITE AUFK-AUFNR TO L_INNENAUFTRAG NO-ZERO .

ohne führenden 0 als ein achtstelligen Wert in die lokale Variable L_Innenauftrag zu speichern. Dieses hat dann aber den Nachteil, dass sofern wir einen mehrstelligen Nummernkreis anlegen diese ebenfalls angepasst werden muss.

Daher ist es eleganter die führenden 0000 bei achtstelligen Innenauftragsnummern im Coding ebenfalls zu berücksichtigen.

Hierzu kann in der Definition des Infoset über die Schaltfläche ZUSÄTZE ein Zusatzfeld im Infoset angelegt werden.

In unseren Beispiel hat dieses folgende Eigenschaften:
Name: ZCOKEY
Langtext / Überschrift: ZCOKEY

Dieses hat den Vorteil, dass wir uns beim Coding leichter den Namen merken können (im Zusatzfeldcoding wird anhand des Namen der Wert zugewiesen.

Als Format bekommt das Feld TYP C (für Character) und eine Länge sowie Ausgabenlänge von jeweils 035 Zeichen.

Damit ist das Feld angelegt und es kann über die Schaltfläche CODING ZUM ZUSATZFELD ein entsprechendes Coding angelegt werden. Da wir nur numerische Innenauftragsnummern verwenden ist die im oberen Abschnitt erwähnte Prüfung ob es sich bei der Auftragsnummer um eine numerische Nummer handelt eigentlich obsolet, dennoch habe ich diese als äußere Klammer im Coding eingefügt.
 

WICHTIG / Nachtrag: CLEAR ZCOKEY

Es sollte darauf geachtet werden, dass die Variabele ZCOKEY durch die ABAP Anweisung CLEAR erst einmal geleert wird. Andernfalls merkt sich die Query bei mehreren Innenaufträgen den vorherigen Wert, sofern kein neuer Wert zugewiesen wird. Durch die Anweisung CLEAR wird die Variable bzw. das Zusatzfeld auf Initialwert zurückgesetzt. Sofern dieses nicht der Fall ist wundert man sich über die Ergebnisse.

Als einfaches Beispiel werden Buchprojekte auf Innenaufträgen abgebildet. Dabei sind Publikationen zu Office Produkten im Nummernkreis 4021*, SAP Literatur 4022* und BWL Bücher unter 4023* angelegt worden.

CLEAR ZCOKEY.
IF AUFK-AUFNR CO  '1234567890'.

IF AUFK-AUFNR     => '000040210000' AND AUFK-AUFNR <= '000040219999'.
  ZCOKEY = 'Office Literatur'.
ELSEIF AUFK-AUFNR => '000040220000' AND AUFK-AUFNR <= '000040229999'.
  ZCOKEY = 'SAP Literatur'.
ELSEIF AUFK-AUFNR => '000040230000' AND AUFK-AUFNR <= '000040239999'.
  ZCOKEY = 'BWL Literatur'.
ENDIF.

ENDIF.

Natürlich ist dieses wesentlich einfacher durch Zuordnung von Profit-Centern wie die vorhandenen Profit-Center OFFICE, SAP, BWL möglich. Im Hochschulbereich könnten das Profit-Center für Landesmittel (L), Drittmittel (D) und Sondermittel (S) sein.

Endziffer Innenauftrag zusätzlich zum Nummernkreisintervall prüfen

Soll nun aber zusätzlich noch unterschieden werden, ob es hier ein gedrucktes Buch ist, eine elektronische Publikation oder die Vorbereitung auf ein Buch und dieses durch die letzte Endziffer des Innenauftrages festgelegt werden kann die IF Anweisung noch um eine weitere Bedingung erweitert werden. Die Endziffer 0 ist dabei für normale Buchprojekte, die Endziffer 1 für Print und 2 für Ebook.

CLEAR ZCOKEY.
IF AUFK-AUFNR CO  '1234567890'.

IF AUFK-AUFNR     => '000040210000' AND AUFK-AUFNR <= '000040219999' AND AUFK-AUFNR+11(1) = '0'.
  ZCOKEY = 'Office Literatur'.
ELSEIF AUFK-AUFNR => '000040210000' AND AUFK-AUFNR <= '000040219999' AND AUFK-AUFNR+11(1) = '1'.
  ZCOKEY = 'Office Literatur PRINT'.
ELSEIF AUFK-AUFNR => '000040210000' AND AUFK-AUFNR <= '000040219999' AND AUFK-AUFNR+11(1) = '2'.
  ZCOKEY = 'Office Literatur Ebook'.

...

ENDIF.

ENDIF.

Durch die Offset Anweisung AUFK-AUFNR+11(1) wird das letzte Zeichen der 12 Stelligen Innenauftragsnummer des Tabellenfeld AUFNR der Tabelle AUFK verwendet.Durch die optionalen Angaben eines Offsets +<o> und eine Länge (<l>) direkt hinter dem Feldnamen <f>, wird der Teil des Felds, der auf Position <o>+1 beginnt und die Länge <l> hat, als eigenes Datenobjekt angesprochen. Diese Möglichkeit haben wir auch im Feld ZAUFNR für den Artikel "SAP Query innerhalb des SAP Moduls PSM FM beziehungsweise Haushaltsmanagement" verwendet um PSM Fonds mit CO innenaufträgen zu verknüpfen.

ACHTUNG: Sobald die IF Bedingung erfüllt ist werden keine weiteren Bedingungen geprüft, daher ist hier entsprechende Sorgfalt zu walten.

Weitere Bestandteile der Innenaufragsnummer als Bedingung prüfen

Entsprechend oberen Codingbeispiel ist es natürlich auch möglich weitere Bestandteile der Innenauftragsnummer als Prüfmerkmal zu verwenden. Insgesamt wären hier acht Bedingungen möglich. Ein anderes Beispiel zu Print und Ebook wären bei Gebäudeinnenaufträgen eine Unterscheidung nach Bewirtschaftung und Bauunterhaltung :-) Vielleicht haben Sie dann noch einen dreistelligen Standort oder eine Organisationseinheit (zum Beispiel einen Fachbereich) innerhalb ihrer sprechenden Auftragsnummer verschlüsselt und wollen diese auflösen.

Nummernintervall und Bestandteile der Innenauftragsnummer (hier: Endziffer) per IF und CASE überprüfen

Nehmen wir hierzu wieder das Intervall der SAP Bücher als Beispiel und betrachten folgendes schöne Coding

CLEAR ZCOKEY.
IF AUFK-AUFNR CO  '1234567890'.

IF AUFK-AUFNR     => '000040210000' AND AUFK-AUFNR <= '000040219999'.
  ZCOKEY = 'Office Literatur'.
ELSEIF AUFK-AUFNR => '000040220000' AND AUFK-AUFNR <= '000040229999'.
  ZCOKEY = 'SAP Literatur'.
ENDIF.

IF AUFK-AUFNR => '000040220000' AND AUFK-AUFNR <= '000040229999'.
    CASE AUFK-AUFNR+11(1).
WHEN '1'.
     ZCOKEY = 'SAP Literatur PRINT'.
WHEN '2'.
    ZCOKEY = 'SAP Literatur EBOOK'.
ENDCASE.
ENDIF.

ENDIF.

Im ersten Absatz des Coding werden nur Nummern behandelt und alphanumerische Innenaufträge ignoriert. Danach werden anhand des Nummernintervalls das Genre (hier SAP Literatur) festgelegt. Danach wird für die Bücher (hier nur das Intervall SAP Literatur) die Endziffer als Argument in der CASE Anweisung übergeben und die verschiedenen Zustände per WHEN ausgewertet.

Ein klein wenig eleganter (da für alle Publikationen) ist das natürlich mit CONCATENATE  womit zwei Strings miteinander verbunden werden.

Im Beispiel wären dieses der String 'Ebook' oder 'Print' mit den vorher festgelegten Genre (welches in der Variable COKEY schon über die IF Schleife festgelegt wurde.

Konkret wäre hier also der Abschnitt wie folgt anzupassen.

IF AUFK-AUFNR => '000040210000' AND AUFK-AUFNR <= '000040239999'.
CASE AUFK-AUFNR+11(1).
WHEN '1'.
CONCENTATE ZCOKEY ' Print' INTO COKEY RESPECTING BLANKS.
WHEN '2'.
CONCENTATE ZCOKEY ' Ebook' INTO COKEY RESPECTING BLANKS.
ENDCASE.
ENDIF.

Die Abap Anweisung

    CONCATENATE altenstring neuenstring INTO altenstring REPSECTING BLANKS.

 verkettet getrennte Zeichenfolgen zu einer Zeichenfolge. Durch das Argument RESPECTING BLANKS wird auch das Leerzeichen vor der Art der Publikation ' Print' oder ' Ebook' berücksichtigt.
 

Alternative Profit-Center-Rechnung

Aus verschiedenen auch eingangs erwähnten Gründen haben wir uns gegen diese Vorgehensweise in unserem Buch entschieden und statt dessen Profit-Center genutzt um die einzelnen Publikationsfelder des im Buch erwähnten Verlages abzudecken.
  Paperback ISBN: 9783960126874

Für 19,95 € direkt bestellen

Oder als SAP Bibliothek-Flatrate *

Ebook ISBN: 9783960120414

Sofern Sie aber eine wesentlich feingliedrigere Zuordnung von Innenauftragsnummern zu entsprechenden Nummernbereichen haben, kann hier eine wesentlich feingliedriger Unterscheidung der einzelnen Innenaufträge aus sprechenden Nummern bei extern vergegebenen Auftragsnummern hinterlegt werden. Gerade bei einer Vielzahl von Sondermitteln oder unterschiedlichen Landesmitteln die nur anhand der Nummer unterschieden werden kann es hier für neue Kolleginnen und Kollegen eine Hilfe sein, wenn diese hier eine kurze Erläuterung erhalten um was für eine Art von Projekten es sich dabei handelt.

Verwendung Zustazfeld COKEY für Projektbereich in Query

Sofern nun also das Zusatzfeld in eine Feldgruppe übernommen worden ist besteht auch die Möglichkeit in einer Query auf diese Bezug zu nehmen. Im Ergebnis kann somit die im Artikel "Query Einzelpostenliste Innenauftrag mit Ausweis Ertrag und Aufwand Zweiter Teil Query zur Datenaufbereitung" vorgestellt Query um weitere Informationen wie auch die FINGRUPPE erweitert werden.

Sofern zu einzelnen Innenaufträgen auch die Mittelherkunft anhand eines Ordnungsbegriffes klar definiert ist (siehe "FI-AA Anlagenbuchhaltung: Klassifizierung von Anlagen") kann in einer Quey auch die korrekte Zuordnung von Ordnungsbegriff und Innenauftragsnummernbeeich verglichen werden. Hierzu verweise ich gerne auf den Artikel "Zusammenfassung Query über Anlagenzugang - Auswertung Investitionen aus Profit-Center-Rechnung", aber dieses ist dann auch wieder ein anderes teils auch komplexeres Thema. Grundsätzlich sind aber mit SAP Query nicht nur Stammdatenauswertungen, Analysen und die Darstellung von Bewegungsdaten möglich sondern auch eine Unmenge an Kombination aus vorhandenen Daten und sogar die Neuinterpretation von im System vorhandenen Daten, so dass eine Menge an bisher in Excel erfolgte Schritte nun sozusagen einen Schritt vorverlagert nach SAP gemacht werden können.

---

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.

---

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.

---

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.

---

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

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

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

Phasen eines Auftrag bzw. Status

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

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

• AUFK-PHAS0 -  Phase 'Auftrag eröffnet'
• AUFK-PHAS1 -  Phase 'Auftrag freigegeben'
• AUFK-PHAS2 -  Phase 'Auftrag technisch abgeschlossen'
• AUFK-PHAS3 -  Phase 'Auftrag abgeschlossen'

Entsprechend bauen auch diese Phasen aufeinander auf und lassen entsprechend immer weniger Vorgänge zu.

  Daneben sind die einzelnen Datumsfelder wie folgt in der Tabelle AUFK hinterlegt:

• AUFK-IDAT1 - Freigabedatum
• AUFK-IDAT2 - Technisches Abschlußdatum
• AUFK-IDAT3 - Abschlußdatum

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

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

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

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

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

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

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

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

Auswertung Query über einzelne Phasen eines Projektes

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

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

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

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

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

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

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

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

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

Die drei Zusatzfelder sind in den folgenden Abschnitten

• "Zusatzfeld VLE zur Darstellung virtueller Lehreinheit aus Teilstring der verantwortlichen Kostenstelle sofern nicht in einen anderen Feld ein Wert steht"
• "Zusatzfeld Gesperrt (Sperrkenzeichen auswerten)"
• "Zusatzfeld ZAUFNR um die Stammdatentabelle FMFINCODE als Zusatztabelle im Infoset einzufügen"

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

Reihenfolge Selektionsfelder festlegen

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

Konzeption Prozesse und notwendige Stammdatenfelder

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

 

---

Hinweis:

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

---

Ich hatte vor einiger Zeit schon einmal eine Query beschrieben die relativ komfortabel eine Alternative zur Transaktion KOSRLIST_OR Abrechnungsvorschriften  darstellt, allerdings sind im Laufe der Zeit noch weitere Aspekte beziehungsweise Anforderungen in Richtung einer automatischen Kontrolle dieser Abrechnungsvorschrift hinzugekommen. Auf diese Anforderungen und die Systematik der Auftragsabrechnung möchte ich im folgenden Artikel ausführlicher eingehen.
 

Abrechnungsvorschrift Auswertung über KOSRLIST_OR

Die normale Auswertung der Abrechnungsvorschriften ist im SAP Menü unter

• Rechhnungswesen->
• Controlling->
• Innenaufräge->
• Infosystem->
• Berichte zu Innenaufträgen->
• Stammdatenverzeichnis->
• Abrechnungsvorschriften (Transaktion KOSRLIST_OR )

zu finden.

Allerdings hat diese Auswertung den Nachteil, dass hier keine ALV (sprich Liste) erstellt wird sondern in einer Überschriftzeile der Innenauftrag als Kopfzeile dargestellt wird und unten drunter die Abrechnungsvorschriften als einzelne Positionen dargestellt werden.

Sollte, aus Gründen, nun ein Vergleich oder gar Export der Abrechnungsvorschriften erfolgen ist dieses etwas problematisch.

Von einigen Kolleginnen und Kollegen wurde ich angesprochen, ob nicht eine Kontrolle der Abrechnungsvorschriften nicht auch über eine Query möglich ist. Bisher wurde dieses relativ aufwändig in Excel erledigt.

Besonders bei der Abrechnung von Kosten auf Kostenstellen soll hier überprüft werden, ob die empfangende Kostenstelle identisch zur verantwortlichen Kostenstelle des Innenauftrages ist.

Hintergrund: Abrechnung von Landesmittelprojekten

In der Regel hängen die einzelne Projekte an einer Kostenstelle einer Professur / eines Institut oder einer Einrichtung und sollen im Rahmen der Auftragsabrechnung für eine Plankostenumlage auf die jeweiligen Kostenstellen umgelegt werden. Auf die unterschiedlichen Möglichkeiten der Auftragsabrechnung gehe ich etwas später in diesen Artikel ein.

Nun möchte ich kurz die Möglichkeit einer Query zur Auswertung der Abrechnungsvorschriften vorstellen und diese um eine Prüffunktion erweitern.
 

Infoset zur Auswertung Auftragsabrechnung

Technisch betrachtet beruht das Infoset aus den beiden Tabellen AUFK für die Stammdaten der Innenaufträge und COBRB für die Aufteilungsregeln Abrechnungsvorschrift Auftragsabrechnung.

Die beiden Tabellen sind über das Tabellenfeld OBJEKTNUMMER der beiden Tabellen aufgebaut. Hier werden also die beiden Felder AUFK-OBJNR und COBRB-OBJNR miteinander verknüpft und alle Tabellenfelder in das Infoset übernommen.

Query zur Darstellung Abrechnungsvorschrift

Die Query ist dabei wie im Artikel "Query Abrechnungsvorschriften Innenauftrag" umfassender beschrieben wie folgt aufgebaut:

Auftragsstammdaten AUFK
Auftragsnummer (L,S) AUFK-AUFNR
Kurztext (L) AUFK-KTEXT

Aufteilungsregeln Abrechnungsvorschrift Auftragsabrechnung COBRB
Version (L,S) COBRB-VERSN
Kontierungstyp (L) COBRB-KONTY
Empfangende Kostenstelle (L) COBRB-KOSTL
Auftragsnummer (L) COBRB-AUFNR
Abrechnungsart (L) COBRB-PERBZ
Ursprungszuordnung (L) COBRB-URZUO
Gültig ab Periode (L) COBRB-GABPE
Gültig ab Jahr (L) COBRB-GABJA
Gültig bis Periode (L) COBRB-GBISP
Gültig bis Jahr (L) COBRB-GBISJ

Die im ursprünglichen Artikel beschrieben weiteren Felder zu den Stammdaten Kostenstelle etc. habe ich nun einmal außen vor gelassen.

Soweit ist diese Query auch schon bekannt. Nun gab es allerdings eine Anfrage, dass die Aufteilungsregel der Innenaufträge automatisch überprüft werden sollten.

Ausgangslage unterschiedliche Abrechnungsvorschriften

Hintergrund ist, dass in der Abrechnungsvorschrift drei Einträge vorhanden sind.

• Abrechnung der Kosten auf eine Kostenstelle
  In der Abrechnungsvorschrift wird als Typ KST (Kostenstelle) und als Abrechnungsempfänger  eine Kostenstelle zugeordnet. Die Verteilung der einzelnen Kostenarten erfolgt über die Ursprungszuordnung ZUK werden die einzelnen Kostenarten entsprechenden Abrechnungskostenarten zugeordnet.
• Abrechnung Erlöse auf Erlösauftrag
  Hier ist die Abrechnungsvorschrift so gepflegt, dass als Typ AUF (Auftrag) und ein entsprechender Innenauftrag als Abrechnungsempfänger hinterlegt. Als Ursprungszuordnung wird hier ZUE hinterlegt.
• Abrechnung neutrales Ergebnis
  Neutrale Kosten-/Erlösarten werden ebenfalls per Typ AUF (Auftrag) auf einen Innenauftrag zum neutralen Innenauftrag gelegt werden. Hier wird als Ursprungszuordnung ZUN festgelegt.

Hintergrund: Customizing Abrechnungsvorschrift

Das Customizing der Arbrechnungsvorschriften ist in der Transaktion SPRO unterhalb

• Controlling->
• Innenaufträge->
• Planung->
• Abrechnung pflegen

aufrufbar. Hier können zum einen die einzelnen Abrechnungsschema gepflegt werden aber auch das Ursprungsschema gepflegt werden. Dieses soll aber nicht Thema des Artikels sein.

Sofern Kosten auf eine Kostenstelle abgerechnet werden soll, sollte diese Kostenstelle der verantwortlichen Kostenstelle des Innenauftrages entsprechend. Gerade wenn hier in der Abrechnungsvorschrift eine Abweichung vorhanden ist, kann dieses eine sehr ausführliche Fehlersuche nach sich ziehen.

Lokales Feld mit Ikone LED anlegen

Hierzu arbeiten wir in der Query wieder einmal mit lokalen Feldern.

Um lokale Felder zu definieren wird nicht direkt die Grundliste der Query bearbeitet (wo auch das Layoutdesign gepflegt wird) sondern innerhalb der Querypflege (Transaktion SQ01) mit "nächstes Bild (F6)" auf die Feldauswahl der Query gewechselt. Alternativ ist es auch möglich dies über das Menü SPRINGEN->FELDAUSWAHL->FELDAUSWAHL zu erreichen.

Über
BEARBEITEN->KURZBEZEICHNUNG
kann für die einzelnen Felder eine Kurzbezeichnung eingestellt werden. Nun werden rechts neben den Datenfeldern Eingabefelder für die Kurzbezeichnung angegeben. Hier erhalten nun folgende Felder eine Kurzbezeichnung (in der Beschreibung ist die Bezeichnung, gefolgt von der angelegten Kurzbezeichnung (fett hervorgehoben) und des dahinter technisch liegenden Tabellenfeldes angegeben):

Auftragsstammdaten
Verantwortliche Kostenstelle VKOST  (AUFK-KOSTV)
Aufteilungsregeln Abrechnungsvorschrift Auftragsabrechnung
Ursprungszuordnung URZUO (COBRB-URZUO)
Kontierungstyp KONTY (COBRB-KONTY)
Empfangende Kostenstelle EKOST (COBRB-KOSTL)

Diese Kurzbezeichnung ist notwendig, da wir auf diese dann Bezug nehmen, wenn wir ein eigens Feld mit einer Formel anlegen.

Dieses geht über

BEARBEITEN->LOKALES FELD->ANLEGEN

Dieses Lokale Feld wird dann in der Feldgruppe angelegt, in der wir uns gerade befinden. Von daher ist es ganz praktisch, dass wir uns in den Abrechnungsvorschriften befinden.

Hierzu legen wir ein Feld mit folgenden Eigenschaften an:

lokales Feld (CHKABRV)
Kurzbezeichnung:  CHKABRV
Feldbezeichnung: CHKABRV
Überschrift: CHKABRV
Eigenschaften:
Ikone
Berechnungsvorschrift:
Hier wird eine komplexe Berechnung mit folgenden Bedingungen hinterlegt:

Bedingung: VKOST = EKOST AND URZUO = 'ZUK' AND KONTY = 'KS'
Formel: ICON_LED_GREEN

Bedingung: VKOST <> EKOST AND URZUO ='ZUK' AND KONTY = 'KS'
Formel ICON_LED_RED

Sonst lassen wir leer.

Die Bedingung ist ein klein wenig tricky.

Als erstes wird geprüft ob die Verantwortliche Kostenstelle des Innenauftrags und das Feld empfangende Kostenstelle (COBRB-KOSTL) identisch sind oder ob es hier Abweichung gibt

In der ersten Bedingung sollten die übereinstimmen (dank = ) und in der zweiten gibt es eine Abweichung ( <>  bedeutet ungleich).

Daneben werden aber auch folgende Fragestellungen berücksichtigt

Werden tatsächlich Kosten verteilt und nicht etwa Erlöse?
Wie erwähnt gibt es allerdings neben ZUK für die Verteilung der Kosten noch eine Verteilung von Erlöse auf entsprechende Erlösaufträge über die Ursprungszuordnung ZUE. Hier kann die Kostenstelle nicht übereinstimmen, da die Erlöse der Innnenaufträge auf entsprechende andere Innenaufträge (zum Beispiel Erlösaufträge der einzelnen Lehreinheiten) verteilt werden. Daher soll eine Kontrolle nur erfolgen, wenn es sich bei der Ursprungszuordnung um ZUK für die Kostenabrechnung handelt.

Ist der Abrechnungsempfänger vom Typ her eine Kostenstelle?
Problematisch sind nun Innenaufträge deren Kosten nicht auf Kostenstelle sondern auf einzelne Produkte (Drittmittel, Weiterbildung vergleichbares) abgrechnet werden. Hier ist der Abrechnungsempfänger dann keine Kostenstelle sondern ein Innenauftrag. Deswegen gibt es als dritte Bedingung die Kontrolle handelt es sich beim Typ um eine Kostenstelle "KS". Dieses wirkt nun iritierend, da wir bei der Pflege von Abrechnungsvorschriften im Innenauftrag ja immer eine KST angeben, wie auch in unseren Buch "Schnelleinstieg ins SAP Controlling (CO)" ausführlich erläutert wurde (siehe Buchempfehlung).
Dieses liegt daran, dass in der Abrechnungsvorschrift der Wert zwar als KST zugewiesen wird, in der Datenbank das Feld allerdings unkonventiert als KS gespeichert ist. Besonders ansprechend ist das in der Transaktion SE16H zu betrachten. Ferner umfasst das Feld KONTY der Tabelle COBRB auch nur zwei Zeichen.
Dieses ist auch der Grund, warum ich gerne Tabellendefinitionen (SE12) oder Tabellenanzeige (SE16H) für die Administration von Query nutze ansosnten wundert man sich, warum eine Auswertung nicht funktioniert.


Was für eine Ikone soll als Symbol ausgegeben werden (Formel)?
Als Formel wird nun der Wert der IKONE angegeben.

Hier nutze ich sehr gerne LED Icons die je nach Zustand (Ergebnis) RED = Fehler, YELLOW = Kontrolle erfoderlich oder GREEN = Alles okay ein Ergebnis liefern.

Gemäß SAP Design Guide (siehe https://experience.sap.com/files/guidelines/icons_sap/index.htm ) hätte ich hier wohl ebenfalls besser ICON_CHECKED (grüner Haken) , ICON_INCOMPLETE (rotes Kreuz) oder ICON_FAILURE (Warnhinweis) verwenden können.

Die LED Icons  ICON_LED_GREEN (Green LED; go; correct), ICON_LED_RED (Red LED; stop; incorrect) erscheinen mir hier allerdings tatsächlich als wesentlich sinnvoller.

Wenn ich nun dieses Feld ebenfalls in meine Grundliste übernehme erhalte ich bei gepflegten Abrechnungsvorschriften direkt eine LED wenn es eine entsprechende Abweichung gibt und kann sogar nach Fehlern filtern.

Handhabung der Query

Nachdem die Query angelegt ist lohnt es sich abzurechende Projekte vorab per Query auszuwerten und in der Anzeige beziehungsweise einer Layoutvariante nach roten LEDs zu filtern. Auf diese Weise ist es möglich schon vor der Abrechnung etwaige Abweichungen zu identifizieren und zu verhindern. Ferner kann dieses auch hilfreich sein, entsprechende Abweichungen bei Kostenumlage (zum Beispiel durch die Plankostenumlage) zu korrigieren. Mit ein wenig Glück muss man dann nicht alle Zyklen stornieren (oder eine erneute Plankopie anfertigen) sondern kann dann in Höhe der Abweichung eine Plankorrektur vornehmen. Sofern eine Umlage im Ist erfolgt, kann hier auch das Thema "Segmentkorrektur in SAP" interessant sein.

Nebenbei beim Thema Umlagezyklen oder generell der kennzahlenbasierten Verrechnung sind auch die Artikel "Innenaufträge als Empfänger von Umlagezyklen (KSUB)" oder die Analyse von Kostenumlagen wie im Artikel "ReportWriter: Ergebnisse Planumlage (KSUB) je Partnerobjekt"  oder "Auswertung Statistische Kennzahlen auf Innenaufträge für Lehrimport und Lehrexport auf Ebene Studiengänge". Gerade im Controlling bietet sich hier aber neben der Query auch Report Writer beziehungsweise Report Painter als Analysewerkzeug an. Nach Möglichkeiten sollten aber Auswertungen, wie die hier beschriebene Überprüfung der Abrechnungsvorschrift genutzt werden um die doch sehr umfangreiche Suche nach Abrechnungsfehlern zu vermeiden.

Gerade bei einer Analyse von Einzelbelegen im Plan, wie im Artikel "CO Planeinzelposten Objekt und Partnerobjekt auswerten / Mehrere Felder summieren" beschrieben ist enorm aufwändig.

 

---

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. Wie erwähnt kann im Controlling auch das Thema "Grundlagen Kurzeinführung und Handbuch Report Painter Report Writer" sehr nützlich sein.

---

Nach den letzten Artikeln die mehr im Bereich Office (insbesondere Excel) angesiedelt waren und der für mich besonders erfreulichen Nachricht auf Facebook zum Tag des Buches (siehe folgenden Tweet von mir) mag ich im folgenden Artikel wieder einmal eine Fragestellung aus SAP Query aufgreifen.

Vorab eine kurze Twittermeldung zum Welttag des Buches in eigener Sache
Danach möchte ich auf das Thema "Regalflächen mit Verpackungseinheit bestücken und Dispositionsplanung durch Abrunden von Kapazität / Verpackungseinheit"


Mittlerweile bietet Amazon auch eine Buchvorschau (Blick ins Buch), so dass sich neben der Buchvorstellung auf meiner Seite ein guter Einblick ins Buch möglich ist.

Nun aber zur eigentlichen Frage rund um eine Query aus den Bereich der Materialdisposition.

Ausgangslage

In einer Auswertung mit SAP Query sollen zwei Werte miteinander dividiert werden und das Ergebnis immer abgerundet werden. Da zwar Query erstellt werden dürfen, aber keine Berechtigung für Coding bei Zusatzfeldern gestattet ist, soll dieses in der Erstellung der Query geschehen. Im Ergebnis soll zum Beispiel 24 / 10 nicht 2,4 sondern 2,0 ergeben.

Als zusätzliche Hürde sollen alle Werte größer 1 müssen immer abgerundet werden, Werte die kleiner 0,9 sind müssen allerdings aufgerundet werden.

Betriebswirtschaftlicher Hintergrund Erstdisposition im Markt über Regalmenge und Verpackungseinheiten:

Im konkreten Beispiel geht es um die Simulation einer Erstdispotliste eines Marktes zu bis diese über ein Programm umgesetzt wird. Die Kapazität ( ist die maximale Regalmenge eines Artikels in Stück im Markt und die Verpackungseinheit (VE) entspricht den Standardgebinde der Ware. Das Ergebnis aus Kapazität / VE muss abgerundet werden, da keine halben Kollis geliefert bzw. ins Regal gesetzt werden und aufrunden nicht ginge, da ansonsten die maximale Regalmenge überschritten würde.

Alle Werte größer 1 müssen immer abgerundet werden, Werte die kleiner 0,9 sind müssen aufgerundet werden. Dieses ist inhaltlich auch verständlich, da ja mindestens eine Einheit bestückt beziehungsweise disponiert werden soll.

Technischer Aufbau der Query zur Dispositionsplanung:

Die Information zur maximalen Regalmenge wurde aus der Tabelle "MALG - Zuordnung von Layoutbausteinen zu Materialien" entnommen (Feld MALG-SHQNM "maximale Regalmenge) und die Verpackungseinheit aus der Tabelle "MARM - Mengeneinheiten zum Material" (Feld MARM-UMREZ "Zähler für die Umrechnung in Basismengeneinheiten") gegenübergestellt.

Die Query selbst wurde dabei technisch wie folgt aufgebaut:
Die Tabelle MARM wurde im Infoset mit der Tabelle "MAW1 - Materialstamm: Vorschlagsfelder und spezielle WWS-Felder" und einen Join der Felder MAW1-WAUSM ("Ausgabemengeneinheit") und MARM-MEINH ("Alternativmengeneinheit zur Lagermengeneinheit") miteinander verbunden.

Bedingt durch die Historie haben wird hier die Mengeneinheiten etwas kompliziert dargestellt und muss daher immer über die MARM ausgelesen werden um die tatsächliche Menge hinter der Basis/Kolli etc zu erhalten. Kurzer Hinweis: Die Query stammt nicht von mir aber ich fand diese zum Verständnis des technischen Hintergrund der Anforderung sehr praktisch und freue mich hier erstmals ein Beispiel aus den SAP Modul MM (Materialwirtschaft) beziehungsweise der Logitik schildern zu können. :-) Schon daher mag ich den fachlichen Austausch auch über das eigene Modul hinaus und freue mich, dass es verschiedene Plattformen gibt in der sich SAP Anwendende miteiander austauschen können.
 

Rundunsgfunktionen in Query

Nun stellt sich jedoch die Frage, wie in einer Quer gerundet werden kann. Während Report Writer  / Report Painter wie im Artikel "Reportwriter Funktionsformeln" beschrieben die beiden Formeln ROUND für normales Runden und TRUNC für den Ausweis einer ganzen Zahl anbietet, ist dieses leider bei lokalen Feldern nicht möglich. Allerdings gibt es hier zwei andere Funktionen beziehungsweise Formelbestandteile die zum gewünschten Ergebnis führen.

•  DIV (ganzzahlige Division, d.h. das Ergebnis ist ganzzahlig)
•  MOD (Restwert bei einer Division)

Hier liegt auch schon der Lösungsansatz.

Hierzu gehen wir nicht in die Grundliste der Query (wo auch das Layoutdesign gepflegt wird) sondern wechseln innerhalb der Querypflege mit nächstes Bild (F6) auf die Feldauswahl der Query. Sofern wir uns noch in der Layoutpflege befinden kann über Zurück dorthin gewechselt werden.

Über
BEARBEITEN->KURZBEZEICHNUNG
kann für die einzelnen Felder eine Kurzbezeichnung eingestellt werden.
Nun werden rechts neben den Datenfeldern Eingabefelder für die Kurzbezeichnung angegeben. Hier erhalten nun folgende Felder eine Kurzbezeichnung:

MALG-SHQNM  -> KAP
MARM-UMREZ  -> VE

Diese Kurzbezeichnung sind notwendig, da wir auf diese dann Bezug nehmen, wenn wir ein eiegens Feld mit einer Formel anlegen.
Dieses geht über
BEARBEITEN->LOKALES FELD->ANLEGEN

Dieses Lokale Feld wird dann in der Feldgruppe angelegt, in der wir uns gerade befinden.

Dabei kann dieses Feld die gleichen Eigenschaften wie VE oder KAP erhalten.

Für unser Beispiel legen wir insgesamt drei Felder an.
Der Einfachheit halber habe ich hier nur die Formel zum jeweiligen Feld mit angegeben, denke aber, dass das Prinzip insgesamt klar sein dürfte.

FELD1
Formel
KAP div  VE

FELD2
Formel
KAP mod VE

FELD3
Hier wird nun mit einer Bedingung gearbeitet.

Bedingung: FELD1 < 0.9
Formel: FELD1 +
Alternativ könnte man auch schreiben FELD_1 + 1
Sonst: FELD1

In der Grundliste wird tatsächlich nur das FELD3 ausgewiesen, so dass entweder das abgerundete FELD1 ausgibt, sofern die Division größere Werte als 1 hat oder alternativ die Menge 1 berechnet, wenn die Division kleiner als 1 wäre.

Zur Verdeutlichung bietet folgende Tabelle anhand einiger weniger Beispiele einen Überblick über die Rechenweise:
 

Beispiel zur Verwendung von MOD und DIV in Query
 

KAP	VE	FELD1 Formel DIV	FELD2 Formel MOD	FELD3 Bedingung	Excel/Mathe
15	6	2	3	2	2,5
8	4	2	0	2	2
4	5	0	4 oder 0?	1	0,8

Manchmal bietet auch die Query selbst Möglichkeiten ohne Programmierung etwas umfangreichere Formeln berechnen lassen. Wobei eine Weiterverarbeitung in Excel natürlich auch stets eine Möglichkeit ist ;-).
 

---

Hinweis:

Eine kurze Einführung in das Thema SAP Query habe ich im Artikel
"Grundlagen Kurzeinführung und Handbuch SAP Query" beschrieben und hoffe Ihnen hier eine Einführung ins Thema bieten zu können. Sollten Sie sich für das Thema Report Writer / Report Painter näher interessieren, so ist dieses im Artikel "Grundlagen Kurzeinführung und Handbuch Report Painter Report Writer" ebenfalls beschrieben.

---

Wie schon im ersten Teil dieses Artikel ("Query über COEP, AUFK und FMFINCODE für Einzelposten Istkosten Innnenauftrag mit Stammdaten aus CO und PSM-FM sowie Spalten für Ertrag und Aufwand - Erster Teil Infoset als Datengrundlage") beschrieben wurde aus einer anderen Hochschule ("erweiterten" KollegInnenkreis) basierend auf eine CO Schulung mit SAP Query (aus der auch viele Anregungen im Artikel "SAP Query innerhalb des SAP Moduls PSM FM beziehungsweise Haushaltsmanagement" vorgestellt wurden) die Idee die Stammdaten eines CO Innenauftrages mit einer Einzelpostenliste zu kombinieren und dabei eine Spalte für Ertrag und eine Spalte für Aufwand inklusive Abschreibungen entwickelt und entsprechend umgesetzt. Die hier genutzte Lösung innerhalb der Query möchte ich hier gerne vorstellen.

Im Ergebnis kann hier, vergleichbar zur Saldenliste im PSM-FM (siehe Artikel "Saldenliste für Fonds im Haushaltsmanagement Saldo gegen Ertrag und Saldo gegen Budget") eine Auswertung über bestimmte Innenaufträge aller Erträge und Aufwendungen erfolgen. Ferner können hier sowohl als Selektionsmerkmal als auch für die Liste als Ausgabe entsprechende Stammdaten mit ausgegeben werden.

Basis: Infoset AUFK-COEP und Zustzfelder/Zusatztabellen

Als Grundlage für die Query habe ich ein recht umfangreiches Infoset angelegt, dass sowohl Stammdaten aus CO und PSM-FM als auch die CO Einzelposten aus der Tabelle COEP miteinander in Verbindung setzt.

Als schematische Darstellung sieht das Infoset inklusive Zusatzfelder (mit Coding) und Zusatztabelle, welche beide gelb eingefärbt sind,  wie folgt aus:



Der Aufbau des Infoset und der Zusatzfelder ist im ersten Teil dieses Artikel ausführlich beschrieben. ACHTUNG der Left outer Join gehört zwischen COEP und CSKB und nicht COEP und CSKU (Hintergrund geänderte Kostenartentexte). Hier ist die Zeichnung leider fehlerhaft.

Exkurs: Auswertung Einzelposten COEP statt Summen COSS, COSP

Per Mail wurde ich bezüglich des  Infoset angesprochen, ob es nicht sinnvoller wäre statt der Einzelposten hier die Summentabelle COSP auszuwerten, da dieses einen Performancegewinn für die spätere Query hätte. Der Gedanke der Summentabellen klingt auf den ersten Blick sympathisch hat jedoch einen entscheidenden Nachteil. In der Tabelle COSP werden nur die Primärkosten als Summe gespeichert, die sekundären Kostenarten sind in der Tabelle COSS enthalten. Die COEP hat dafür alle Einzelposten. Ebenso sind die Planbelege ein weiteres Problemfeld, da diese in der Tabelle COEJ hinterlegt sind und ebenfalls eine Herausforderung zur Auswertung bieten. Auf die Auswertung der Plan-Einzelposten bin ich im Artikel "CO Planeinzelposten Objekt und Partnerobjekt auswerten / Mehrere Felder summieren" eingegangen. In diesem Zusammenhang ist auch die Tabelle TJ01 "Betriebswirtschaftliche Vorgänge" interessant, da diese für jeden betriebswirtschaftlichen Vorgang erfasst, wo die erfassten Bewegungsdaten in Tabellenform festgehalten werden.

Zuordnung Infoset zu Query

Das entsprechende Infoset sollte, in der Transaktion SQ02 über die Schaltfläche "Zuordnung zu Rollen/Benutzergruppen" der Benutzergruppe zugeordnet werden in der nun auch die Query erstellt werden soll.

Dieses kann dann in der Transaktion SQ01 erfolgen. In der Query soll nun auf die Gruppierung der Kostenarten nach Ertrag und Aufwand eingegangen werden, sowie die eigentliche Query basierend auf diesem Infoset erstellt werde.

Dazu arbeiten wir auch wieder mit lokalen Feldern in der Query.

Neben der reinen Auswertung von einzelnen Tabellenfeldern beziehungsweise der im Infoset zur Verfügung gestellten Feldern kann innerhalb der Query auch die Ergebnisse dieser Datenbankabfrage verarbeitet werden.

Kurzbezeichnung für Wert und Kostenart

Dazu müssen einzelnen Feldern eine Kurzbezeichnung zugewiesen werden um auf diese in den lokalen Feldern dann Bezug genommen werden zu können.

Hierzu gehen wir nicht in die Grundliste der Query (wo später  auch das Layoutdesign gepflegt wird) sondern wechseln innerhalb der Querypflege mit nächstes Bild (F6) auf die Feldauswahl der Query. Sofern wir uns noch in der Layoutpflege befinden kann über Zurück dorthin gewechselt werden. Alternativ kann auch im Menü über

SPRINGEN->FELDAUSWAHL->FELDAUSWAHL

in die Feldauswahl der Query gewechselt werden. 

Achten Sie bitte darauf, dass über

EINSTELLUNGEN ->EINSTELLUNGEN

der grafischer Query Painter aktiviert ist, wobei dieses auch im Standard der Fall sein sollte. Andernfalls würde sich die Oberfläche zur Querydefinition etwas ändern (was zwar mehr Möglichkeiten bietet, aber leider auch ein wenig am Komfort der Pflege von Query verhindert.

Um den einzelnen Feldern eine Bezeichnung zuzuweisen ist es erforderlich über die Funktion

BEARBEITEN->KURZBEZEICHNUNGEN ->EINSCHALTEN

einzelne Felder eine Kurzbezeichnung zuordnen und mit dieser Bezeichnung dann arbeiten.

Erst nachdem die Kurzbezeichnungen eingeschaltet sind, kann über die Feldauswahl eine Kurzbezeichnung den einzelnen Feldern des Infoset zugewiesen werden.

Hierzu wechseln wir in die Felder der Feldgruppe "CO-Objekt: Einzelposten periodenbezogen" beziehungsweise der Feldgruppe in der Sie die Felder der Tabelle COEP zugewiesen haben.

Hier erhalten nun die Felder "Wert gesamt in Kostenrechnungskreiswährung" und  "Kostenart" eine Kurzbezeichnung. Hier wählen wir die Kurzbezeichnungen WERT und KOA.

Exkurs: Unterschiedliche Währungen im Controlling

Alternativ hätte die Kurzbezeichnung WERT auch den Feldern "Wert gesamt in Objektwährung" oder "Wert gesamt in Kostenrechnungskreiswährung" zugeordnet werden können. Sofern alle Werte in Euro geführt werden dürfte dieses identisch sein.

Allerdings kann im Controlling, besonders bei internationalen Konzernen unterschiedliche Währungen geführt werden.

Beim Festlegen eines Kostenrechnungskreis wird im Customizing auch gleichzeitig eine Kostenrechnungskreiswährung festgelegt. Dem Kostenrechnungskreis können unterschiedliche Buchungskreise zugeordnet werden, die zwar eine eigene Buchungskreiswährung  (bspw. US Doller USD oder Schweizer Franken SFR) haben aus denen aber die Kostenrechnung die gemeinsame Konzernwährung Euro ableitet, so dass innerhalb des Kostenrechnungskreis eine einheitliche Konzernwährung geführt wird.

Die Transaktionswährung weist dafür die Währung aus, in der die Belege im Controlling tatsächlich gebucht sind.

Daneben können zu einzelnen CO-Objekten, so auch Kostenstelle  oder Innenauftrag ebenfalls eigene Währungen definiert werden (bspw. in der Kostenstelle im Feld Währung in der Registerkarte Grunddaten). In der Regel wird hier aber dem CO-Objekt die Währung als Vorschlagswert beim Anlagen vorgeschlagen und zugewiesen, die auch im Kostensrechnungskreis hinterlegt ist.

Zusammenhang T-Währung (COEP-WTGBTR), O-Währung (COEP-WOGBTR), K-Währung (COEP-WKGBTR)  und Währungsumstellung

Durch den Hinweis eines Kollegen bin ich darauf aufmerksam gemacht worden, dass bei einen Mehrmandantensystemen scheinbar nur das Feld "Wert gesamt in Kostenrechnungskreiswährung"( COEP-WKGBTR ) gefüllt ist und nicht die Felder Transaktionswährung ( COEP-WTGBTR) oder Objektwährung ( COEP-WOGBTR ). Entsprechend sinnvoll ist es daher tatsächlich die Kostenrechnungskreiswährung für diese Query zu verwenden. An welcher Stelle im Customizing dieses Verhalten ausgesteuert ist kann ich leider noch nicht sagen, aber die Artikel, welche die COEP im Rahmen einer Query auswerten, habe ich passend angepasst. Hintergrund ist hier vermutlich, dass einige Mandanten die Währungsumstellung von DM auf EUR mitgemacht haben und andere erst nach der Umstellung auf Euro angelegt worden sind. Dieses spricht dafür, dass die T-Währung und O-Währung nur dann gefüllt wird, wenn auch tatsächlich unterschiedliche Währungen im Systemn vorhanden waren und ansonsten wird nur das Feld  "Wert gesamt in Kostenrechnungskreiswährung" gefüllt, wobei diesse Währung auch identisch zur Buchungskreiswährung ist.

Ich habe mich daher für WERT für "Wert gesamt in Kostenrechnungskreiswährung" als Feld entschieden.

Lokales Feld für Ertrag, Aufwand und Verrechnung bzw. Umlage anlegen

Die nun zugewiesenenKurzbezeichnungen WERT und KOA sind notwendig, da wir auf diese dann Bezug nehmen, wenn wir ein lokaes Feld mit einer Formel anlegen.
Dieses geht über

BEARBEITEN->LOKALES FELD->ANLEGEN.

Dieses Lokale Feld wird dann in der Feldgruppe angelegt, in der wir uns gerade befinden. Entsprechend sinnvoll ist es soweit in der Feldliste herunterzunavigieren, bis wir in der Feldgruppe sind in der auch die Zusatzfelder Gesperrt, Projektbewertung und VLE (Virtuelle Lehreinheit) hinterlegt sind.

Nun können folgende Felder angelegt werden.

1. Lokales Feld ERTRAG_5
Kurzbezeichnung:  ERTRAG_5
Feldbezeichnung: 5er Ertrag
Überschrift: 5er Ertrag
Eigenschaften:
Gleiche Eigenschaften wie Feld:  WERT
Berechnungsvorschrift:
Hier muss ausnahmsweise keine komplexe Berechnung eingetragen werden, da wir nur eine Bedingung (ein Intervall an Kostenarten) benötigen.

Entsprechen lautet die Berechnung  WERT
und die zugehörige Bedingung
KOA >= 50000000 AND KOA <= 59999999

Alternativ kann dieses auch als
Bedingung:  KOA >= 50000000 AND KOA <= 59999999
Formel: WERT

angegeben werden und Sonst leer gelassen werden. Somit wird das Feld Wert nur im lokalen Feld ausgegeben, wenn die Kostenart zwischen 50000000  und 59999999 liegt.

Genauso definieren wir die beiden übrigen Felder:

2. Lokales Feld AUFWAND_6
Kurzbezeichnung:  AUFWAND_6
Feldbezeichnung: 6er Aufwand
Überschrift: 6er Aufwand
Eigenschaften:
Gleiche Eigenschaften wie Feld:  WERT
Berechnungsvorschrift:
Bedingung: KOA >= 60000000 AND KOA <= 69999999
Formel: WERT

Wobei dieses nun sowohl den Sachaufwand als auch die AfA umfasst.

Daneben legen wir noch ein weiteres Feld für die sekundären Kostenarten der Kosten-Leistungs-Rechnung an über die Verrechnungen und Umlagen erfolgen.3

3. Lokales Feld AUFWAND_9
Kurzbezeichnung:  AUFWAND_9
Feldbezeichnung: Umlage Verrechnung
Überschrift: Umlage Verrechnung
Eigenschaften:
Gleiche Eigenschaften wie Feld:  WERT
Berechnungsvorschrift:

Hier können dann mehrere Bedingungen hinterlegt werden, als Beispiel sind hier drei Nummernkreise der Kostenarten festgelegt:

Bedingung: KOA >= 91000000 AND KOA <= 91999999
Formel: WERT

Bedingung: KOA >= 93000000 AND KOA <= 93999999
Formel: WERT

Bedingung: KOA >= 95000000 AND KOA <= 95999999
Formel: Wert


Für alle anderen Kostenarten könnte nun ein weiteres Feld mit Prüfung angelegt werden, sofern keines der anderen Felder gefüllt ist.Natürlich können auch andere Intervalle (zum Beispiel für Personalkosten, AfA oder Sachkosten) gewählt werden.

Exkurs: Kontenrahmen und Kostenartenintervalle am Beispiel Personalkosten

Nehmen wir als Beispiel den Industriekontenrahmen (IKR). Hier sind die einzelnen Kontenklassen ebenfalls als Intervalle gepflegt.

Innerhalb der Klasse 6 (Betriebliche Aufwendungen) wären die Personalkosten in den Intervallen Löhne (620000 bis 629999), Gehälter (630000 bis 639999) und Personalnebenkosten (640000 bis 649999). Je nach Sichtweise können zu den Personalkosten auch die Sonstigen Personalaufwendungen (660000 bis 669999) betrachtet werden unter die unter anderen die  Aufwendungen für Fort- und Weiterbildung fallen.

Eine ausführliche Beschreibung der hier zugrundeliegenden Kostenartenrechnung  ist im Buch "Schnelleinstieg ins SAP Controlling (CO)" (ISBN 9783960126874 ^*)  zu finden... .



Hier werden auch weitere Intervalle (im Kapitel Kostenartenrechnung) sowie der Industriekontenrahmen IKR ausführlicher erläutert. Eine gute Einführung in das interne und externe Rechnungswesen anhand der SAP Module FI und CO habe ich ferner im Artikel "Schnelleinstieg ins SAP Rechnungswesen mit cat content ;-)" vorgestellt. Sollten Sie sich für SAP Fachliteratur interessieren dürfte auch die digitale SAP-Bibliothek von Espresso Tutorials interessant sein (siehe SAP ebook Flatrate).

In der in diesem Artikel erstellten Query kann, anhand der lokalen Felder, aber schon anhand der Summe der Spalten und der Summe der Spalte Wert kontrolliert werden, ob tatsächlich alle Kosten ordentlich zugeordnet sind. Sollten Sie auch weitere Aufwendungen über Kostenarten beginnend mit 7* buchen, wäre eine weitere künftige Spalte bzw. lokales Feld anzulegen.
 

Grundliste der Query anlegen

Nach Anlage der lokalen Zusatzfelder kann nun die Grundliste der Query angelegt werden.
Hierzu kann über SPRINGEN->GRUNDLISTE->AUFBAU auf die Pflege der Grundlise gewechselt werden in der sowohl das Layout als auch die einzelnen auszugebenden (oder zu selektierenden Felder) ausgewählt werden.

Innerhalb der Query werden nun auf folgende Felder der einzelnen Tabellen Zugriff genommen. Bzw. in der Grundliste zugewiesen. Hierbei ist L als Listenfeld und S als Selektionsfeld zu verstehen.

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


Tabelle AUFK "Aufragsstammdaten"
Auftragsnummer (L,S) AUFK-AUFNR
Kurztext  (L) AUFK-KTEXT
Arbeitsbeginn (L) AUFK-USER7
Arbeitsende (L) AUFK-USER8

Zusatzfelder (aus Infoset)
G(esperrt) (L) GESPERRT

Tabelle AUFK "Aufragsstammdaten"
Antragsteller (L) AUFK-USER0
Verantwortlicher (L) AUFK-USER2
Abteilung (L) AUFK-USER6

Tabelle FMFINCODE "FIFM: Finanzierungscode"
Finanzierungszweck von Drittmitteln  (L,S) FMFINCODE-FINUSE

Zusatzfelder (aus Infoset)
Projektbewertung (L,S) PBW

Tabelle AUFK "Aufragsstammdaten"
Verantwortliche Kostenstelle (L,S) AUFK-KOSTV


Tabelle COEP "CO-Objekt: Einzelposten periodenbezogen"
Geschäftsjahr (L,S) COEP-GJAHR
Vorgang CO (L) COEP-VRGNG
Belegnummer (L,S) COEP-BELNR
Kostenart (L,S) COEP-KSTAR

Tabelle CSKU "Kostenartentexte"
Bezeichnung Kostenart (L) CSKU-KTEXT

Tabelle COEP "CO-Objekt: Einzelposten periodenbezogen"
Wert gesamt in Kostenrechnungskreiswährung (L) COEP-WKGBTR
Je nach Betrieb kann es hier sinnvoll sein die Währungsfeldposition davor oder dahinter zu setzen. Sofern nur eine Währung genutzt wird kann natürlich auch kein Währungsfeld genutzt werden.

Tabelle COBK "CO-Objekt: Belegkopf"
Erfassungsdatum des Beleges (L,S) COBK-CPUDT
Buchungsdatum  (L) COBK-BUDAT
Benutzername  (L) COBK-USNAM

Tabelle COEP "CO-Objekt: Einzelposten periodenbezogen"
Positionstext (Segmenttext) (L)  COEP-SGTXT

Tabelle COBK "CO-Objekt: Belegkopf"
Belegkopf-Text (L) COBK-BLTXT

Lokale Zusatzfelder (aus der Feldliste der Query)
5er ERTRAG (L)
6er Aufwand (L)
9er UmlageVerrechnung (L)

Zur Zuordnung der Verantwortung kann nun noch die verantwortliche Kostenstelle und natürlich die Lehreinheit mit ausgegeben werden.

Tabelle CSKS "Kostenstellenstammsatz"
Kostenstelle (L) CSKS-KOSTL

CSKT "Kostenstellentexte"
Bezeichnung Kostenstelle (L) CSKT-KTEXT

Tabelle CSKS "Kostenstellenstammsatz"
Verantwortlicher (L) CSKS-VERAK
Abteilung (L) CSKS-ABTEI

Zusatzfelder (aus Infoset)
VLE (virtuelle Lehreinheit) (L) VLE

Damit kann die Query tatsächlich genutzt werden und je Innenauftrag auf Basis der einzelnen Spalten eine Zwischensumme für Ertrag, Aufwand und die interne Verrechnung beziehungsweise der Umlage ausgewiesen werden.

Besonderheiten bei Klassifizierung beziehungsweise Auswerten der Merkmale zur Unterscheidung Drittmittel, Dienstleistung oder Sonstige..

Noch eine kleine Anmerkung zur Klassifizierung. Die Merkmale der Klassifizierung  ermöglichen eine weitergehende Information zum Fond und könnten ebenso auch bei den Innenaufträgen aktiviert werden. Eine gute Übersicht zur Einführung der Klassifizierung habe ich im Artikel "SAP Query - Auswertung Merkmale der Klassifizierung am Beispiel Fonds in PSM-FM" beschrieben. In der erstellten ALV Liste der Query kann dann auch tatsächlich nach einzelnen Merkmalen der Klassifizierung sortiert oder auch gefilert werden. Dieses ist dann wesentlich komfortabler als die Suchfunktion innerhalb der Komponente Klassifizierung von SAP. Auch wenn die Merkmale der Klassifizierung als Selektionsmerkmal in der Query keine Wertauswahlhilfe (F4) anbieten kann es hilfreich sein hier diese ebenfalls als Kriterium zu nehmen.

Somit können alle in der Projektbewertung als DL für Dienstleistung festgelegte beziehungsweise klassifizierten Projekte ausgewertet werden.

Sollten Sie die einzelnen Merkmale einmal von Freitext auf vorgegebene Merkmalswerte umgestellt haben kann die Query Daten in den Merkmalen liefern die im Stammsatz beziehungsweise in der Klassifizierung nicht vorhanden ist beziehungsweise da fehlerhaft nicht ausgewiesen wird.

Als Beispiel konnte das Merkmal PBW früher mit DM2001 gefüllt werden (Drittmittel 2001) und heutzutage werden mit DM, DL, AF bestimmte Merkmale vorgegeben und es kann kein weiteres Merkmal gepflegt werden. Dieses Problem ist im Abschnitt "Sonderfall Inkonsistenz bei Merkmalspflege" im Artikel zur Klassifizierung beschrieben.

Entsprechend spannend kann es daher sein noch weitere Merkmale der Klassifizierung, wie zum Beispiel das Förderkennzeichen des öffentlichen Mittelgeber als weiteres Selektionsmerkmal zu hinterlegen und hier entsprechende Auswertungen zu erstellen. Damit können auch anhand des Förderkennzeichen mit *ESF* alle Projekte des ESF ausgewertet werden.

 

---

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
Aus "erweiterten" KollegInnenkreis (andere Hochschule) wurde mir basierend auf eine CO Schulung mit SAP Query die Idee die Stammdaten eines CO Innenauftrages mit einer Einzelpostenliste zu kombinieren und dabei eine Spalte für die Ertrag und eine Spalte für Aufwand inklusive Abschreibungen auszuweisen vorgestellt, so dass am Ende nach Selektion bestimmter Merkmale aus den CO Stammdaten eine passende Einzelpostenauswertung erstellen zu können, die dann auch noch nach Innenaufträgen summiert werden können.

Diese Idee habe ich im kommenden Artikel aufgegriffen und um den ein oder anderen Punkt erweitert. Insgesamt kommt so eine Liste vergleichbar der Transaktion KOB1 (Aufträge Einzelposten Istkosten anzeigen) heraus. Als Summenbericht ist eine solche Auswertung problemlos im Report Writer / Painter möglich, wie im Artikel "Erweiterung Report Writer Berichtsbibliothek 1CT zur Darstellung rollierendes Geschäftsjahr für Kostenstelle und Innenauftrag" beschrieben. Allerdings können hier nicht alle Stammdaten des auszuwertenden CO-Objekt in unseren Fall also der Innenauftrag als Information oder auch als Selektionsfeld ausgewählt werden.

Entsprechend verfolgen wir mit einer neuen Query einen vergleichbaren Ansatz zu der Query im Artikel "Query Einzelpostenliste IST über CO Objekte (Auflösen von Innenauftrag, Kostenstelle) sowie Benutzerstammdaten und Erfassungsdatum". Jedoch sollen hier nicht einfach die CO-Objekte als Kostenstelle oder Innenauftrag ausgegeben werden sondern gerade die Innenaufträge als Auswertungsmerkmal gesondert betrachtet werden um beispielsweise alle Innenaufträge mit einen bestimmten Merkmal (zum Beispiel über das Feld "Arbeitsgenehmigung liegt vor" oder anhand der verantwortlichen Kostenstelle) auszuwerten. So kann das CHECKIN Feld zum Beispiel zur Kennzeichnung von vollkostenpflichtigen Projekten genutzt werden.

Wie bereits in der Überschrift  erwähnt, wird dieser Artikel in zwei Teilen erscheinen. Im ersten Teil wird die Grundlage für die Auswertung in Form eines Infoset erstellt werden. Hierbei sind auch viele kleine neueren Erkenntnisse rund um die Kombination von Stammdaten aus PSM-FM und CO mit eingebunden. Ferner wird innerhalb des Infoset dank Zusatzfeldcoding auch manches Datum schon vorbereitet wofür es in vorherigen Artikeln relativ umfassende komplexe Berechnungen in der Query gab. Es lohnt sich also tatsächlich diesen recht langen Artikel komplett zu lesen.
 

Infoset Stammdaten Innenauftrag und CO Einzelposten im Ist

Hierzu wurde als erstes ein Join über folgende Tabellen angelegt.



Das Infoset ist dabei vergleichbar des oben beschriebenen Artikel angelegt, so dass sowohl die Einzelpositionen des CO Beleg als auch die Belegkopfdaten ausgewertet werden können. ACHTUNG: Dabei ist jedoch zu beachten, dass der Left Outer Join zwischen CSKB und COEP und nicht CSKU und COEP gesetzt werden sollte. Hier ist die Darstellung leider fehlerhaft.

Nun sollen aber zu den Stammdaten aus CO (beziehungsweise der Tabelle AUFK "Auftragsstammdaten") noch weitere Informationen über Zusatzfelder und Zusatztabellen mit ausgegeben werden.

Bisherige Vorgehensweise (wird im weiteren Verlauf dieses Artikels erheblich verbessert)

Hier bietet sich die Gelegenheit die in der Artikelserie

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"

bereits vorgestellten Methoden sinnvoll zu aktualisieren und die zum Beispiel im Artikel "SAP Query innerhalb des SAP Moduls PSM FM beziehungsweise Haushaltsmanagement" gewonnenen Erkenntnisse ebenfalls einzuarbeiten und hier ein wenig das Infoset anzupassen beziehungsweise für mich neure und in meinen Augen auch intelligentere Methoden zwecks Verknüpfung von Stammdaten aus CO und PSM-FM zu erstellen. Daneben hat sich auch bei der Erstellung eines Feldes zur Darstellung der virtuellen Lehreinheit eine Menge entwickelt, so dass diese nun direkt im Infoset als Zusatzfeld ermittelt werden kann.

Da dieses Vorhaben etwas umfangreicher ist, wurde dieser Artikel in einen Teil zur Datengrundlage (Infoset) und der Auswertung des Infoset in Form einer Query aufgeteilt.
 

Erweiterung des Infoset über Zusatzfelder

Über die Schaltfläche Zusätze (F5) bzw. innerhalb der Transaktion SQ02 (Pflege des Infosets) über  SPRINGEN-> ZUSÄTZE ZUM KNOTEN kann ein zusätzliches Feld in ein Infoset definiert werden, welches nicht direkt in der auszuwertenden Tabelle erscheint. Ich möchte im folgenden Artikel vier Zusatzfelder anlegen um hier wesentlich weitergehende Auswertungsmöglichkeiten als das Lesen einer Tabelle oder eines Infoset zu ermöglichen.

Innerhalb des nun aufgerufenen Register Zusätze kann über die Schaltfläche "Anlegen" ein Zusatzfeld erstellt werden. Es erscheint eine Maske in der der Name des Zusatzfeldes angegeben werden soll und die Art der Zusatzinformation.

Im Einzelnen können dieses Zusatztabelle, Zusatzfeld, Zusatzstruktur und Coding sein. In den folgenden drei Abschnitten soll hier Zusatzfelder erstellt werden. Wobei eines davon später für das Einfügen einer Zusatztabelle genutzt wird. Wichtig ist es nach Eingabe des Zusatzfeldes auch die Eigenschaften wie Langtext, Überschrift sowie Textlänge und Typ definiert werden. Teilweise kann hier auch mit LIKE Referenz gearbeitet werden, so dass die Feldeigenschaften eines referenzierten Tabellenfeldes entsprechen.

Damit ist dann grundsätzlich ein Feld angelegt allerdings enthält es (anders als beim Einfügen einer Zusatztabelle, die direkt mitsamt ihren Daten ins Infoset geladen wird) keine Werte. Um nun eine entsprechende Wertzuweisung im Infoset zu bekommen kann hier mit Coding zum Feld gearbeitet werden.

Nachdem ein Feld jedoch angelegt ist kann über die Schaltfläche "Coding zum Zusatz" ein passendes ABAP Coding für das Feld hinterlegt werden über das wiederum eine Datenbankabfrage erfolgen kann. In den folgenden Abschnitten habe ich das von mir eingefügte Coding angegeben und kurz erläutert.

Berechtigungen für Zusatzfelder mit ABAP Coding

Für die Pflege von Zusatzcoding sind jedoch weiter gehende Basisberechtigungen erforderlich. Hierzu werden die Berechtigungen auf das Berechtigungsobjekt S_DEVELOP und die Berechtigungsfeldwerte Objekttyp PROG, Objektname AQ* sowie die Aktivitäten 01 und 02 geprüft. Da es sich hier um recht weitgehende Berechtigungen handelt, sollten diese auch nur im Entwicklungssystem vergeben werden. Die Berechtigungsprüfung erfolgt ebenfalls, wenn die Query, wie im Artikel "Transport von SAP Queries (DL/UL)" beschrieben, per Dateiupload ins Testsystem oder Produktivsystem transportiert werden soll. Das Infoset selbst lässt sich nach einem erfolgreichen Upload noch bearbeiten, lediglich das Coding ist durch die Berechtigungsprüfung vor weiteren Änderungen geschützt.

In den folgenden Abschnitten wird auf die einzelnen Zusatzfelder mit ihren Eigenschaften und zugehörigen Coding zum Zusatzfeld eingegangen.

Zusatzfeld Gesperrt (Sperrkenzeichen auswerten)

Auch hier wird wieder ausgewertet, ob ein Innenauftrag den Systemstatus Gesperrt (in der Transaktion KO02 "Innenauftrag ändern" per Bearbeiten->Sperre setzen) hat.

Hierzu wird ein Zusatzfeld GESPERRT mit den Eigenschaften Typ C (Charcter) und einer Länge von 001 angelegt. Dahinter wird als Coding folgende Anweisung hinterlegt:

DATA: L_AUFKOBJ type AUFK-OBJNR.
DATA: L_TEMP type AUFK-OBJNR.
L_AUFKOBJ = AUFK-OBJNR.
SELECT  SINGLE objnr FROM JEST into L_TEMP
    WHERE stat = 'I0043'
    AND objnr = L_AUFKOBJ
    AND inact = ''.
IF sy-subrc <> 4.
GESPERRT = 'X'.
ELSE.
CLEAR GESPERRT.
ENDIF.

Damit der Sperrstatus ermittelt werden kann wird anhand der Objektnummer des Innenauftrag (Feld AUFK-OBJNR) in der Tabelle JEST geprüft ob der Status I0043  gesetzt ist.

Zur Verdeutlichung des Zusammenhang sei auf folgende Grafik verwiesen:


Wobei das Thema Systemstatus auch sehr umfassend in den beiden Artikeln:

• "SAP Query: Systemstatus CO Innenauftrag"
• "Änderungsbelege zu Systemstatus (JEST) bei Innenaufträgen per Query auswerten"

erklärt ist und für diese Auskunft lediglich die Information ausreicht, ob der aktuelle Innenuaftrag gesperrt ist oder eben nicht.


 

Zusatzfeld VLE zur Darstellung virtueller Lehreinheit aus Teilstring der verantwortlichen Kostenstelle sofern nicht in einen anderen Feld ein Wert steht

Innerhalb der Kostenstellen einer Hochschule sind auch entsprechend Lehreinheiten mit den ersten vier Ziffern verschlüsselt. Sofern abweichend zu den ersten vier Ziffern innerhalb der Fachbereichskostenstellen eine andere Lehreinheit der Kostenstelle zugeordnet werden soll, ist diese im Feld Teletexnummer (welches nicht mehr für andere Zwecke verwendet wird, ausgewiesen.

Die Ausgabe der verantwortlichen Kostenstelle ist relativ aufwändig innerhalb von lokalen Zusatzfeldern in einer Query gelöst worden. Die hier genutzte Vorgehensweise ist im Artikel "Query über verantwortliche Kostenstelle des Innenauftrag - Bestimmung der Lehreinheit im Fachbereich durch Teil der Kostenstellennummer" beschrieben worden.

Diese Methode hat jedoch den Nachteil, dass jede Query erneut solche Felder und Formeln definiert bekommen muss. Entsprechend positiv wäre es natürlich, wenn eine solche Erhebung direkt im Infoset zum Beispiel über ein Zusatzfeld mit passenden Coding erfolgen kann.

Ein Auslesen der ersten vier Ziffern einer Kostenstelle über eine IF Bedingung ist mir soweit auch gelungen, allerdings hatte ich Probleme eine Abfrage zu erstellen, dass sofern das Feld Teletexnummer gefüllt ist, diese als Lehreinheit genommen wird.

Auf fico-forum.de hatte ich hier eine sehr hilfreiche Unterhaltung mit MrBojangles (Autor des Blog  SAPManDoo) im Beitrag "Query: Auslesen Stammdaten (Zusatzcoding ABAP) Problem SELECT Statement AUFK-KOSTV und CSKS-TELTX".

Das Ergebnis unserer Unterhaltung, inklusiver einer Anpassung für den Fall, dass die Kostenstelle nicht nur numerisch sondern auch Buchstaben enthält habe ich dann wie folgt als Coding zum Zusatzfeld VLE eingebaut.

Hierbei hat das Zusatzfeld VLE durch LIKE-Referenz die Eigenschaften des Tabellenfeldes CSKS-TELTX erhalten (Typ C und Länge 030).

Rahmenbedingungen:
Es werden achtstellige Kostenstellen verwendet, sofern die verantwortliche Kostenstlele des Innenauftrag zwischen 10000000 und 12345678 liegt sollen die ersten vier Ziffern der Kostenstelle als Wert für die Lehreinheit genommen werden.

Ein Sonderfall stellt nun noch die Kostenstelle 47110000 dar. Hier soll als Lehreinheit die 1047BE ausgegegeben werden. Ferner sollen die Kostenstellen der betrieblichen Einrichtung der Kostenstellen 20815000 bis 20815999  der Lehreinheit 208BE und 24300000 bis 24399999 der Einrichtung 243BE zugeordnet werden.

In allen anderen Fällen soll die verantwortliche Kostenstelle des Innenauftrages (aus der Tabelle AUFK-KOSTV) ausgewiesen werden.

Problematisch dabei ist, dass wir zwar achtstellige Kostenstellen nutzen, in SAP jedoch insgesamt zehn Stellen vorgesehen sind, so dass die Kostenstelle aus dem  Tabellenfeld  AUFK-KOSTV mit führenden 00 ausgegeben würden. Mein erster Gedanke wäre daher den erhaltenen Wert mit * 1 zu multiplizieren und so eine Zahl zu erhalten. Hier wurde ich im Forum zu Recht darauf hingewiesen, dass sobald die Kostenstelle auch nur einen Buchstaben enthält ein "ABAP Dump" erzeugt wird. Hier ist eine wesentlich schönere Variante durch die Anweisung NO-ZERO die führenden 00 aus dem Feld zu entfernen und deiesen Wert als VLE zu speichern.

Abschliessend soll nun noch geprüft werden, ob das Feld CSKS-TELTX (Teletexnummer im Kostenstellenstammsatz) mit einen Wert gefüllt ist und dieser Wert in jeden Fall unabhängig der anderen Bedingungen ausgegeben werden.

Hierzu ist eine entsprechende SELECT Abfrage über die Kostenstellen durchgeführt worden. Besonders gelungen empfinde ich hierbei, dass die Gültigkeit des Kostenstellenstammsatzes dahingehend überprüft wird, ob die Information zum Datum der Auswertung (SY-DATUM auch gültig ist, da sich das Feld ja auch auf Basis von zeitabhängigen Daten bei der Kostenstelle ändern kann. Durch ne space wird auch direkt festgehalten, ob die Teletexnummer einen Wert enthält. Sollte dieses der Fall sein, bekommt das Zusatzfeld VLE den Wert der lokalen Variable L_CSKSTELTX zugewiesen, andernfalls den Wert, der anhand der IF Bedingung ermittelt wurde.

Das auf diese Anforderungen erstellte (beziehungsweise angepasste) Coding sieht dann wie folgt aus:

DATA: L_CSKSTELTX type CSKS-TELTX.
IF AUFK-KOSTV => '0010000000' AND AUFK-KOSTV =< '0012345678'.
WRITE AUFK-KOSTV(6) TO VLE NO-ZERO .
ELSEIF AUFK-KOSTV = '0047110000'.
  VLE = '1047BE'.
ELSEIF AUFK-KOSTV => '0020815000' AND AUFK-KOSTV =< '0020815999'.
  VLE = '208BE'.
ElSEIF AUFK-KOSTV => '0024300000' AND AUFK-KOSTV =< '0024399999'.
  VLE = '243BE'.
ELSE.
  WRITE AUFK-KOSTV TO VLE NO-ZERO .
ENDIF.
* bei gefülltem TELTX VLE auf TELTX setzen
SELECT teltx FROM csks INTO L_CSKSTELTX up to 1 rows
  WHERE kokrs = AUFK-KOKRS
  AND kostl = AUFK-KOSTV
  and datbi >= SY-DATUM
  and teltx ne space.
ENDSELECT.
IF sy-subrc = 0.
    VLE = L_CSKSTELTX.
ENDIF.

Nebenbei ist ein solcher fachlicher Austausch mit ein Grund, warum ich immer noch Blogs, Foren und Wikis als ein sehr hilfreiches Arbeitsmittel betrachte und sehr froh darüber bin, dass es immer noch eine Community gibt in der sich gegenseitig geholfen wird. Ein wenig hoffe ich sowohl hier im Blog als auch in einigen Onlineforen meinen Part dazu beitragen zu können. Sehr allgemein habe ich dieses Thema  im Artikel "Praktische Nutzung von social media Diensten für meinen Arbeitsalltag" angesprochen.

Stammdatenfelder aus Fond (PSM-FM) ergänzend zum Innenauftrag ausgegeben

In den beiden Artikeln "SAP Query ABAP Coding im Zusatzfeld für Verknüpfung Innenauftrag und Fond bzw. Finanzierungszweck oder auch Status GESPERRT bei Innenaufträgen" und  "Weitere Zusatzfelder im Infoset mit ABAP Coding zur Verwendung in SAP Query über die Tabellen AUFK und FMFINCODE" wurden einzelne Felder aus der Tabelle FMFINCODE durch eine Select Abfrage und SHIFT Anweisung ausgelesen und einzeln dem Infoset hinzugefügt.

Hintergrund ist, dass das Feld AUFK-AUFNR  in der Datenbank als Character mit 12 Zeichen und das Feld FMFINCODE-FINCODE als Character mit 10 Zeichen definiert ist.

Selbst wenn die Auftragsnummer und die Nummer des Fond übereinstimmen können beide Felder nicht miteinander in Form eines Infoset verknüpft werden, da diese eine "illegale Verknüpfung" wäre, da rein technisch die Felder nicht übereinstimmen.

Innerhalb des Abschnitt "Zusatzfeld ZAUFNR (Übernahme AUFK-AUFNR als FMFINCODE-FINCODE" im Artikel "SAP Query innerhalb des SAP Moduls PSM FM beziehungsweise Haushaltsmanagement" wurde nun eine clevere Alternative dargestellt.

Zusatzfeld ZAUFNR zur Verknüpfung von Innnenauftrag und Fond

Hierzu wurde das Zusatzfeld ZAUFNR mit per LIKE-Referenz FMFINCODE-FINCODE erstellt was in den folgenden Abschniten als Hilfsfeld genutzt werden kann.

Als erläuternde Überschrift und Langtext kann "Auftragsnummer 10 stellig" genommen werden.

Das in meinen Augen clevere Coding beschränkt sich auf einen Einzeiler in dem dem Feld per Offset die Auftragsnummer aus der Tabelle AUFK zugewiesen wird.

Für eine achtstellige Projektnummer (Innenauftrag) lautet das Coding wie folgt:

ZAUFNR = AUFK-AUFNR+4(8).

Hierbei bedient sich das Coding der Technik eines Offsets.

Durch die optionalen Angaben eines Offsets +<o> und eine Länge (<l>) direkt hinter dem Feldnamen <f>, wird der Teil des Felds, der auf Position <o>+1 beginnt und die Länge <l> hat, als eigenes Datenobjekt angesprochen.  In unseren Fall wird also für die Variable ZAUFNR das Feld AUFK-AUFNR (wir erinnern uns die zwölfstellige Auftragsnummer) eingelesen und ab der vierten Stelle insgesamt acht Stellen eingelesen. Da in der Datenbank die Auftragsnummer mit führenden 0000 hinterlegt wird erhalten wir also statt des Datenbankwerte 000012345678 die tatsächliche Auftragsnummer 12345678.

Sollten Sie eine andere Länge bei den Aufträgen oder Fonds definiert haben ist das Coding natürlich entsprechend anzupassen.

Im Ergebnis haben wir nun das Feld ZAUFNR, welches die gleichen Eigenschaften wie das Feld FINCODE innerhalb der Tabelle FMFINCODE hat.

Nun kann das Feld für verschiedene Formen der Verknüpfung genutzt werden.

SAP Query: Reihenfolge des Codeabschnittes

Beim Hinzufügen eines Zusatzfeldes oder einer Zusatztabelle kann am Punkt  Reihenfolge des Codeabschnitts gewählt werden. Auch wenn die Hilfe nicht in diese Richtung zu lesen ist, verstehe ich den Punkt so, dass wenn man Bezug auf vorab definierte Zusatzfelder nehmen möchte die hier nutzenden Felder im nachgeordneten Codeabschnitt liegen sollten.

Da ich in beiden kommenden Fällen mit den neu angelegten Feld ZAUFNR gearbeitet werden soll, werden beide kommenden Fälle im Codabschnitt 2 hinterlegt.

Zusatztabelle FMFINCODE

Anstatt eines Zusatzfeld kann im Register Zusätze über die Schaltfläche ANLEGEN auch eine ganze Tabelle eingefügt werden. Hierzu tragen wir als Name FMFINCODEfür die Stammdatentabelle der Fonds ein und wählen als Art der Zusatzinformation die Option ZUSATZTABELLE..

Im Feld "Reihenfolge des Codeabschnitts" wird nun eine 2 aus den geschilderten Gründen eingetragen.

Hintergrund ist dass erst das Feld ZAUFNR definiert sein soll, bevor Sie mit der Zusatztabelle arbeiten.

Nun erfolgt eine Abfrage über SELECT SINGLE * FROM FMFINCODE WHERE ...
in der folgedene (hervorgehobene) Bedingungen erfüllt sein sollen.

WHERE FIKRS  =  AUFK-BUKRS

da Finanzkreis und Buchungskreis identisch sind, können hier beide Felder sowohl in der Tabelle AUFK als auch FMFINCODE verwendet werden.

AND FINCODE = ZAUFNR

Hierdurch werden dann tatsächlich Fonds und Innenauftrag miteinander verknüpft und es steht die gesamte Tabelle FMFINCODE im Infoset zur Verfügung.
 

Merkmal aus Klassifizierung mit auswerten

Nehmen wir an, dass im Rahmen der Klassifizierung von Fonds im Modul PSM-FM die Projektbewertung in ein Merkmal festgehalten wird. Dann ist auch die im Artikel "SAP Query - Auswertung Merkmale der Klassifizierung am Beispiel Fonds in PSM-FM" erheblich erleichtert.

Hierzu wird ebenfalls ein Zusatzfeld bspw. PBW für Projektbewertung mit Langtext und Überschrift Projektbewertung erstellt.

Dieses hat als Eigenschaften eine LIKE-Referenz auf AUSP-ATWRT.

Ferner wird im unteren Abschnitt des Fenster bei Reihenfolge des Codeabschnitts ebenfalls eine 2 eingetragen.

Danach wird als Coding zum Zusatzfeld ein passendes Coding zum Zusatzfeld hinterlegt, dass aus der Variable (Zusatzfeld) ZAUFNR und den Buchungskreis bzw. Finanzkreis eine Objektnummer erstellt, die dem Feld AUSP-OBJEK. entspricht.


Unter der Annahme eines dreistelligen Finanzkreis KRK und dass das Merkmal die Interne Merkmalsnummer (Feld ATINN) folgenden Wert hat 0000000022 hat wird folgendes Coding zum Feld hinterlegt:

DATA: L_objfond TYPE AUFK-AUFNR.
DATA: L_MERKMALPBW type AUSP-ATWRT.

CONCATENATE  'KRK ' ZAUFNR INTO L_OBJFOND RESPECTING BLANKS.

SELECT SINGLE ATWRT INTO L_MERKMALPBW FROM AUSP
 WHERE OBJEK = L_OBJFOND AND ATINN ='0000000022' AND KLART = '042'.
IF sy-subrc <> 0.
  CLEAR PBW.
ELSE.
  PBW = L_MERKMALPBW.
ENDIF.

Im Ergebnis enthält nun das Feld PBW die in der Klassifizierung hintelregte Projektbewertung des Fond.

Zum Abschluss können alle Zusatzfelder und die Felder der Zusatztabelle als Felder in den Feldgruppen des Infoset übernommen werden.

Persönlich habe ich mir angewöhnt, für die Zusatztabelle eine eigene Feldgruppe anzulegen und auch die Zusatzfelder in einer Extra Feldgruppe mit aufzunehmen.

Schematisch betrachtet sieht der technische Aufbau unseres Infoset nun wie folgt aus:


ACHTUNG: Auch hier hat sich in der Zeichnung ein Fehler reingeschlichen, da der left outer join zwischen CSKB und COEP und nicht CSKU und COEP sein sollte.

Damit können in einer Query nun sowohl Stammdaten aus CO / PSM-FM als auch die Ist-Einzelposten ausgewertet werden. Daher sollten auch alle Tabellenfelder mit in das Infoset in Feldgruppen mit aufgenommen werden. So kann später die Query auch sehr flexibel angepasst werden.

Die Idee der eingangs angesprochenen freundlichen Hochschule aus der Nachbarschaft die einzelnen Felder nach Art der Verwendung zu gruppieren wird im zweiten Teil dieses Artikel dargestellt. Hier soll nur erst einmal die Datengrundlage für die Query geschaffen werden.

Der zweite Teil ist im Artikel "Query Einzelpostenliste Innenauftrag mit Ausweis Ertrag und Aufwand Zweiter Teil Query zur Datenaufbereitung" ebenfalls online zu finden.

 

---

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.

---

Im Artikel "SAP PSM-FM klassische Budgetierung mit unterschiedlichen Budgetversionen" habe ich ja schon die Vorgehensweise zur Budgetbuchung innerhalb der klassischen bdugetierung beschrieben. Sowohl bei der Buchung von Originalbudget als auch bei Budgetumbuchungen sind für Fonds auch immer neben Sender und Empfänger Fonds auch die Finanzstellen als Sender und Empfänger mit angegeben. Innerhalb eines Recherchebericht (wie bspw. im Artikel "Recherchebericht Budget + Ertrag ggü. Aufwand" werden alle Budgetbuchungen mit ausgegeben, unabhängig welche Finanzstelle hier als Sender/Empfänger gesetzt ist. Allerdings gibt es Berichte in der auf Basis der verantwortlichen Kostenstelle des Innenauftrags die Finanzstelle zum Fond ausgewertet wird (sofern Finanzstelle = verantwortliche Kostenstelle des Innenauftrages und der Innenauftrag auch dem Fond entspricht).

Grundsätzlich ist es über das Standardberichtswesen möglich hier die jeweiligen Einzelposten der Belege darstellen zu lassen. Dazu kann als Selektionmerkmal der Fond eingetragen werden und man erhält eine Liste der Hierarchiebelege (dieses bedeutet, dass die Einzelbuchungen auch für jede Hierarchieebene der Finanzpositionenhierarchie eine eigene Belegposition schreibt.

Sowohl für Gesamtbudget als auch Jahresbudget sind die Budgeteinzelposten im SAP Menü unter folgenden Abschnitt zu finden:

• Rechnungswesen
• Public Sector Management
• Haushaltsmanagement
• Infosystem
• Einzelposten
• Budget (klassische Budgetierung)
• Hierarchiebelege
  • Gesamtbudget (Transaktion FMRP_RFFMEP2BX)
  • Jahresbudget (Transaktion FMRP_RFFMEP1BX)

Dieses ist eine schöne Möglichkeit die einzelnen Positionen der Belege dargestellt zu bekommen. Sofern jedoch eine Layoutvariante mit Filtern als Vorgabe genutzt wird kann es passieren, dass man diese vergisst und sich wundert, dass für die Fehlersuche nicht der "falsch kontierte" (z.B. abweichende Finanzstelle) Fond beziehungsweise Buchung auftaucht.

Daher stellt sich die Überlegung, ob eine solche Liste nicht auch als Query möglich zu erstellen wäre.Hier bietet der Artikel "SAP Query innerhalb des SAP Moduls PSM FM beziehungsweise Haushaltsmanagement" einen passenden Lösungsansatz in Form der Nutzung einer logischen Datenbank.

Exkurs: Logische Datenbanken enthalten schon Verknüpfungen und können direkt als Grundlage für ein Infoset verwendet werden. Dieses hat den Vorteil, dass man nicht selbst erst einzelne Tabellenverknüpfungen erstellen muss. Die Struktur einer logischen Datenbank kann in der Transaktion SE36 eingesehen werden. Im Bereich HCM wären dieses bspw. PNP oder PCH während innerhalb des Rechnungswesen ggf. die Datenbanken ADA für die Anlegenbuchhaltung und BRF für FI Belege interessant sind.

Um unsere Berichtsanforderung zu erfüllen gibt es auch für das Modul PSM-FM eine passende logische Datenbank. Innerhalb der logischen Datenbank FMF werden verschiedene Datenstrukturen mit Bewegungsdaten versorgt. Ein Blick auf diese Datenbank mit der Transaktion SE36 kann hier tatsächlich hilfreich sein.
 

Infoset für PSM-FM Budgetbelege

Auf Basis der FMF kann folgendes Infoset über die einzelnen Strukturen erstellt werden. dabei werden zwei Feldgruppen angelegt und diesen folgende Tabellenfelder zugewiesen.

Hierbei werden aus der Datenbank von folgenden Tabellen bzw. Strukturen die Daten übernommen:

Für Gesamtbudget:
BPBTX "Summensätze: Jahresunabhängiges Budget zu Fonds  - Erweitert"
EPBT "Einzelposten: Jahresunabhängiges Budget zu Fonds"

Für Jahresbudget:
BPBYX "Summensätze: Jahresbudget  - Erweitert"
EPBY "Einzelposten: Jahresbudget"

Da es sich bei allen vieren um Strukturen handelt muss hier tatsächlich aus der LDB diese versorgt werden. Eine direkte Auswertung, über View oder Tabellenansicht ist nicht möglich.

Folgende Felder werden in die jeweiligen Feldgruppen übernommen:

Feldgruppe 01 "Budgetbelege Gesamtbudget"
Fonds ( BPBTX-FONDS )
Finanzstelle ( BPBTX-FICTR )
Finanzposition ( BPBTX-FONDS )
Belegnummer Budgetvergabe und Strukturplanung ( EPBT-BELNR )
Positionstext ( EPBT-BELNR )
Gesamtbudget in Finanzkreiswährung ( EPBT-WLGES )

Feldgruppe 02 "Budgetbelege Jahresbudget"
Fonds ( BPBYX-FONDS )
Finanzstelle ( BPBYX-FICTR )
Finanzposition ( BPBYX-FIPEX )
Belegnummer Budgetvergabe und Strukturplanung ( EPBY-BELNR )
Positionstext ( EPBY-SGTEXT )
Verteiltes Jahresbudget in Finanzkreiswährung ( EPBY-WLJHV )

Danach wir das Infoset generiert und gesichert.

Query Hierarchiebelege Gesamtbudget

Die Query zur Darstellung der Einzelbelge zum Gesamtbudget enthält dann die in der entsprechenden Feldgruppe zugeordneten Felder der Strukturen. Für die Darstellung des Gesamtbudget sind entsprechende Felder gewählt worden.

Da hier eine logische Datenbank ausgewertet wird, müssen keine Selektionsfelder definiert werden, da die Selektion für die Daten vom Infoset her selbst vorgegeben werden. Entsprechend sind alle Felder als Listenfelder markiert worden. Die Felder werden hier in der Reihenfolge angegeben, wie diese dann auch in der Query ausgegeben werden sollen:


Summensätze: Jahresunabhängiges Budget zu Fonds  - Erweitert (BPBTX)
Finanzstelle (L) BPBTX-FICTR
Fonds (L) BPBTX-FONDS
Finanzposition (L) BPBTX-FIPEX

Einzelposten: Jahresunabhängiges Budget zu Fonds (EPBT)
Text (L) EPBT-SGTEXT
Belegnr (L) EPBT-BELNR
Gesamtbudget (L) EPBT-WLGES

Grundsätzlich könnte man nun eine zweite Query für die Auswertung der Jahresbudget Einzelposten anlegen (dann allerdings aus der Feldgruppe 02 "Budgetbelege Jahresbudget" die entsprechenden Felder, welche dort definiert sind.

Um eine schnelle Identifikation der "abweichenden" Finanzstelle für einen Fond bei der Budgeterfassung zu identifizieren bietet es sich an im Grundlayout der Query das Feld Finanzstelle in den Werkzeugkasten Sortierfelder zu ziehen. Da meistens die Finanzstellen hierarisch und aufsteigend aufgebaut sind, sollten bei der Einzelpostenliste für den Fond die Finanzstellen entsprechend an oberster Position sortiert sein.

Absprung zur Beleganzeige (Berichtszuordnung FM2F)

Hierzu kann innerhalb der Pflege der Query (Einstiegsbild nach Aufruf der Query in der SQ01) über SPRINGEN->Berichtszuordnung über das +Zeile einfügen weiere Query eingefügt werden. Über anderer Berichtstyp kann hier die Funktion TR Transaktion ausgewählt werden und die Transaktion FM2F "HHM: Budget Beleg anzeigen"

Aus der Transaktion FM2F (Anzeige des Hierarchiebeleges) besteht über die Schaltfläche "Erfassbeleg" auch auf die Transaktion FR60 abzuspringen und die Kontierung am Erfassungsbeleg angezeigt zu bekommen.

Neben der eingangs im Artikel zur klassischen Budgetierung erwähnten Zusammenhang von Erfasungs- und Hierarchiebelegen könnte auch folgender Artikel "Buchungstext ändern bei Budgetbelegen in PSM-FM - Haushaltsmanagement" hilfreich sein, sofern nur der Buchungstext eine Anpassung bedarf.

Nachtrag: Einzelpostenliste (Salden) je Finanzposition nach Finanzstelle und Fond

Im Artikel "Salden je Finanzposition mit Unterscheidung Personal oder Sachaufwand aus PSM-FM durch Query über logische Datenbank FMF" ist ergänzend zu den Budgetbelegen auch eine Darstellung der gebuchten Salden je Finanzposition auf Finanzstelle und Fond dargestellt und dabei als extra Spalte noch Personalaufwand und Sachaufwand unterschieden. Gerade zum Export oder Weiterverarbeitung von Daten bietet sich eine Saldenliste in SAP an. Statt eines Rechercheberichtes kann hier eine Query eine ALV Liste nach Finanzstelle, Fond und Finanzposition liefern ohne dabei wie beim Belegjournal (Transaktion FMRP_RFFMEP1AX ) die Einzelposten mit Belegtexten auszuweisen.

 

---

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.

---

Bei einer Auswertung der Nebenbuchhaltung im Kreditorenbereich wird in der Kreditoren-Einzelposten Liste zu finden unter:

• Rechnungswesen
• Finanzwesen
• Kreditoren
• Infosystem
• Kreditoren Posten
• Kreditoren Einzelposten Liste ( Transaktion S_ALR_87012103)

werden zwar die FI Belegdaten (Kreditorenbeleg und Zahlungsbeleg) und damit die beiden Bücher Kreditorenbuchhaltung und Hauptbuchhaltung angezeigt jedoch sind auf beiden Belegen nicht die CO-Objekte des Kostenrechnungsbeleges zu finden.

Dieses ist nicht weiter verwunderlich, da zwar bei der Erfassung der Kreditorenrechnung (z.B. über die Transaktion FB60 (Kreditoren-Buchung-Rechnung) zwar die CO-Objekte (z.B. Kostenstelle)  mit angegeben diese werden jedoch durch die Mitbuchtechnik auf den Kostenrechnungsbeleg im Controlling fortgeschrieben.

Durch die Mitbuchtechnik werden einzelne FI Belege auch nach CO übergeleitet. Eine ausführliche Beschreibung ist bspw. im Buch "Schnelleinstieg ins SAP Controlling (CO)" (ISBN 9783960126874 ^*)  zu finden... 

Sollen nun über den Kreditor eine Auswertung der CO-Objekte ergänzt werden bietet es sich an hier aus der Profit-Center-Rechnung anhand der Referenzbelegnummer über eine Query eine Auswertung der Profit-Center-Belege ergänzt um die Angabe des Kreditorenbeleges aus FI zu erstellen.

Infoset Einzelposten Kreditoren inkl. CO Objekte

Hierzu ist ein etwas komplexeres Infoset anzulegen.

Dabei ist die Tabelle GLPCA die führende Tabelle und sowohl BSAK als auch BSAS über left outer join verbunden. Der Einfachheit halber wurden alle Tabellenfelder ins Infoset übernommen, selbst wenn für unsere Auswertung nicht alle erforderlich sind. Wobei für unseren Auswertungszweck auf die Tabelle BSAS verzichtet werden könnte.

Sofern Interesse an der Analyse der Zahlungseingänge besteht könnte jedoch die Tabelle BSAD "Buchhaltung: Sekundärindex für Debitoren (ausgebl. Posten)" interessant sein. Diese kann über das Tabellenfeld GLPCA-KUNR ebenfalls analog BSAK verknüpft werden.

Unterschied inner join und left outer join

Daneben gibt es die Möglichkeit die Art der Verknüpfung über die Option left outer join umzustellen. Im Standard werden hier „inner join“ angelegt (1:1 Beziehungen) definiert und als einfache Linie dargestellt. Es ist aber auch möglich „left outer join“ anzulegen (1:n Beziehungen). Hierzu müssen Sie nur mit der rechten Maustaste die Art der Verknüpfung ändern.
Beim Inner Join müssen die Felder beider verknüpften Tabellen exakt übereinstimmen, andernfalls wird kein Ergebnis ausgegeben.

Dahingehend wird beim Left Outer Join immer die "linke" Tabelle ausgegeben und diese mit den übereinstimmenden Feldern der rechten Tabelle kombiniert. Hierbei wird die linke Tabelle immer mit ausgegeben und für jeden Treffer in der rechten Tabelle wird das entsprechende Feld erneut wiederholt, sofern in der rechten Tabelle mehr als eine Übereinstimmung gefunden wurde (daher der Vergleich mit der aus Access bekannten 1:N Beziehung).

Wie bereits erwähnt wird über die Referenzbelegnummer (REFDOCNR) der entsprechenden FI Beleg mit dem CO Profit-Center-Beleg verknüpft. Dieses hat den Vorteil, dass nicht nur Profit-Center sondern die ebenfalls in der Profit-Center-Rechnung bzw. in der Tabelle GLPCA mitgeführten CO-Objekte Innenauftrag und Kostenstelle mit ausgewertet bzw. aufgelistete werden können.

Feldliste Query Einzelposten Kreditoren inkl. CO Objekte

Basierend auf das obige Infoset wird dann die Query wie folgt aufgebaut.

Hierbei ist L als Listenfeld und S als Selektionsfeld zu verstehen. Die Felder werden hier in der Reihenfolge angegeben, wie diese dann auch in der Query ausgegeben werden sollen:

EC-PCA: Ist-Einzelposten (GLPCA)
Geschäftsjahr (S) GLPCA-RYEAR
Kontonummer des Lieferanten bzw. Kreditors (L,S) GLPCA-LIFNR

Zusatzfelder
Name Kreditor (L) Text:Kontonummer des Lieferanten bzw. Kreditors  TEXT_GLPCA_LIFNR

Lieferantenstamm (LFA1)
Straße und Hausnummer (L) LFA1-STRAS
Postleitzahl (L) LFA1-PSTLZ
Ort (L) LFA1-ORT01

EC-PCA: Ist-Einzelposten (GLPCA)
Referenzbelegnummer (L,S) GLPCA-REFDOCNR
Belegart (L) GLPCA-BLART


Zusatzfelder
Belegart (L) Text:Belegart  TEXT_GLPCA_BLART

EC-PCA: Ist-Einzelposten
Kontonummer (L,S) GLPCA-RACCT

Zusatzfelder
Langtext (L) Sachkontenlangtext SKAT-TXT50

EC-PCA: Ist-Einzelposten (GLPCA)
Betrag in Buchungskreiswährung (L) GLPCA-HSL

(sinnvoll kann es sein hier als Währungsfeldposition "kein Währungsfeld" zu markieren, sofern nur mit einer Währung bspw. EUR gearbeitet wird)

Positionstext (L) GLPCA-SGTXT
Kostenstelle (L,S) GLPCA-KOSTL
Auftragsnummer  (L,S) GLPCA-AUFNR
Anlagen-Hauptnummer (L,S) GLPCA-ANLN1

Buchhaltung: Sekundärindex für Kreditoren (ausgegl. Posten (BSAK)
Datum des Ausgleichs (L) BSAK-AUGDT
Belegnummer des Ausgleichsbelegs (L) BSAK-AUGBL

EC-PCA: Ist-Einzelposten (GLPCA)
Belegdatum im Beleg  (L) GLPCA-BLDAT
Buchungsdatum im Beleg (L) GLPCA-BUDAT
Erfasser (L) GLPCA-USNAM

Zusatzfelder
Text:Name des Benutzers (L) TEXT_GLPCA_USNAM

EC-PCA: Ist-Einzelposten (GLPCA)
Referenz (L) BSAK-XBLNR

Eine interessante Option kann es noch sein aus den Beispieldatensatz den "Betrag in Buchungskreiswährung" in den Kasten Summationsfelder und "Kontonummer des Lieferanten" in den Kasten Sortierfelder zu ziehen. damit wird automatisch eine Zwischensumme der Beträge je Kreditor ausgewiesen. Alternativ ist dieses natürlich auch über die Layoutpflege möglich.
 

Sonderfall CpD Kreditoren

Der Referenznummer aus BSAK (BSAK-XBLNR) kommt eine besondere Bedeutung hinzu.
Bei CpD (Conto pro Diverse) Kreditoren werden die Daten für Anschrift und Bank direkt bei der Belegerfassung angegeben und in den Zahllauf übernommen. Entsprechend sind diese Felder bei solchen Kreditoren nicht gefüllt. Allerdings sind hier weitere Informationen oftmals über  das Belegfeld „Referenzbelegnummer zu entnehmen, so dass es sinnvoll sein kann auch dieses Feld mit auszuweisen.

Anwendungsfall pauschalierte Lohnsteuer

Nun kann über diese "Einzelposten Kreditoren" Query die Kostenrechnungsbelege zu einen bebuchten Kreditor (oder nach Anpassung Debitor) aus der Profit-Center-Rechnung heraus ausgewertet werden.Ein weiteres Anwendungsgebiet können Kreditorenbelege auf Ebene einzelner Buchungskonten sein. Hier kann als eines von vielen Anwendungsgebieten das Themenfeld "Pauschalierung der Lohnsteuer" gelten. Ebenso kann diese Query zur Erfüllung der  "Verordnung über die Mitteilung von Zahlungen an die Finanzbehörden" (Mitteilungsverordnung) genutzt werden (Rechtsgrundlage § 93a AO).

---

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.

---

Die Darstellung von Investitionen bzw. den Zugang von Anlagen kann über zwei Wege erfolgen. Zum einen ist da die Möglichkeit in einer Query die logische Datenbank ADA zu verwenden. Diese Variante ist im Artikel "Query Anlagenbuchhaltung (Inventarliste) über logische Datenbank ADA". Eine Alternative ist jedoch die CO Sicht aus der Profit-Center-Rechnung.
Sofern es hier egal ist an welchen Standort die Anlage derzeit steht, kann sich hier auf die beiden Tabellen GLPCA und TABWT. Sofern auch die einzelnen Stammdaten einer Anlage erforderlich sind wäre allerdings der Artikel "Abgleich Belege in CO auf Profit-Center mit zeitabhängigen Stammdaten der Anlagenbuchhaltung bei Investitionen" zu beachten.

Die im folgenden beschriebene Methode hatte ich in Kurzform auch schon im Artikel "Kurzanleitung Anlage einer SAP Query Auswertung ANBWA in der Profit-Center-Rechnung über ANBW und GLPCA" angefangen zu beschreiben.

In diesen Artikel möchte ich hier aber etwas ausführlicher auf beide Möglichkeiten eingehen.
Hierbei sollen zwei Infosets aus der Kombination von GLPCA und den Tabellen der Anlagenbuchhaltung geschildert werden.

Infoset zur Auswertung Investitionen in der Profti-Center-Rechnung

Infoset GLPCA und TABWT

Sofern nur Investitionen auf Kostenstelle, Innenauftrag bzw. Profit-Center interessant sind, reicht es vollkommen aus im Infoset die beiden Tabellen GLPCA und TABWT miteinander über die Felder GLPCA-ANBWA (Anlagen-Bewegungsart) und TABWT-BWASL (Bewegungsart Anlagen) zu verknüpfen.Das so erstellte Infoset kann mit Übernahme aller Tabellenfelder z.B. als ZCO_GLPCA-TABWT benannt werden.

Nachtrag / Hinweis:
Allerdings erfolgt hier keine Kontrolle, ob beim Erfassen des Anlagenbeleges eine Übergabe der CO-Objekte vergessen worden ist. Dieses kann in folgenden Fällen passieren:

1. Vergessen des Innenauftrages in Belegposition Anlagenaktivierung
2. Angabe eines abweichenden Innenauftrages

bei der Erfassung der Anlage berücksichtigt werden.

Daher bietet sich eher das folgende Infoset an, welches auch die Anlagenstammdaten berücksichtigt.

 

Infoset GLPCA. TABWT, ANLA und ANLZ (Stammdaten Anlagenbuchhaltung)

Sofern allerdings auch Stammdaten aus der Anlagenbuchhaltung oder zeitliche Zuordnungen erforderlich sind, sollten auch die Tabellen ANLA und ANLZ in das Infoset übernommen werden.

Hierzu wird das Infoset wie folgt erweitert


Insgesamt werden hier drei Tabellen miteinander verknüpft. Dieses Infoset kann nun ZCO_GLPCA-AA (für die Anlagenbuchhaltung analog FI-AA = Asset Accounting) bezeichnet werden.

Je nach Berichtsziel kann nun entweder das Infoset ZCO_GLPCA-TABWT oder ZCO_GLPCA-AA verwendet werden.


Die einfache Query ist dabei, wie schon im Artikel "Kurzanleitung Anlage einer SAP Query Auswertung ANBWA in der Profit-Center-Rechnung über ANBW und GLPCA" beschrieben wie folgt aufgebaut:
 

Query Ausweis Investitionen auf Profit-Center, Innenauftrag und Kostenstelle inkl. Anlagenbewegungsart

Basierend auf ZCO_GLPCA-TABWT wird die Query ZCO_INVEST-PCTR wie folgt aufgebaut:

Hierbei ist L als Listenfeld und S als Selektionsfeld zu verstehen. Die Felder werden hier in der Reihenfolge angeben, wie diese dann auch in der Query ausgegeben werden sollen:

EC-PCA: Ist-Einzelposten
Geschäftsjahr (L,S) GLPCA-RYEAR
Buchungsperiode (L,S) GLPCA-POPER
Belegnummer (L) GLPCA-DOCNR
Soll-/Haben-Kennzeichen (L) GLPCA-DRCRK
Profitcenter (L,S) GLPCA-RPRCTR
Anlagen-Hauptnummer  (L,S) GLPCA-ANLN1
Anlagenunternummer (L) GLPCA-ANLN2
Anlagenbewegungsart (L,S) GLPCA-ANBWA
Bewegungsartentexte der Anlagenbuchhaltung
Sprachenschlüssel (S)
Bezeichnung Anlagenbewegungsart (L) TABWT-BWATXT
EC-PCA: Ist-Einzelposten
Kontonummer (L,S) GLPCA-RACCT
Betrag in Profit-Center-Hauswährung (L) GLPCA-KSL
Kostenstelle (L,S) GLPCA-KOSTL
Auftragsnummer (L,S) GLPCA-AUFNR

Sofern jedoch auch Daten aus der Anlagenbuchhaltung mit ausgewertet werden sollen, empfiehlt es sich eine Query über das Infoset ZCO_GLPCA-AA anzulegen. Diese Query kann dann bspw. ZCO_INVEST-AA benannt werden.

Query Ausweis Investitionen unter Berücksichtigung von Stammdaten aus FI-AA

Hierzu bedarf es allerdings einer Anpassung über kundeneigener Felder um die Wertausgabe lediglich nur im Jahr des Zugangs auszugeben.

Für die Anlage kundeneigener Felder muss als erstes ein Bezug zu den zu verwendenden Feldern innerhalb der Query gegeben sein.

Hierzu wechseln wir in der Transaktion SQ01 über SPRINGEN->FELDAUSWAHL->FELDAUSWAHL oder solange mittels F6 (nächstes Bild) bis wir zur Feldauswahl gelangen.

Über
BEARBEITEN->KURZBEZEICHNUNG
kann für die einzelnen Felder eine Kurzbezeichnung eingestellt werden.
Nun werden rechts neben den Datenfeldern Eingabefelder für die Kurzbezeichnung angegeben. Hier erhalten nun folgende Felder eine Kurzbezeichnung:

Innerhalb EC-PCA: Ist-Einzelposten werden folgende Felder mit der entsprechenden Kurzbezeichnung zugewiesen:

Betrag in Profit-Center-Hauswährung   KSL
Buchungsdatum im Beleg BUDAT
Kostenstelle KOSTL
Auftragsnummer AUFNR

Aus der Tabelle ANLZ
Datum Gültigkeitsende BDATU
Datum Gültigkeitsbeginn ADATU
Kostenstelle ANLZ_KOSTL
Innenauftrag ANLZ_CAUFN

Diese Kurzbezeichnung sind notwendig, da wir auf diese dann Bezug nehmen, wenn wir ein eiegens Feld mit einer Formel anlegen.
Dieses geht über
BEARBEITEN->LOKALES FELD->ANLEGEN

Da in der Tabelle ANLZ für jeden Zeitraum ein Datensatz zur Anlage vorhanden ist darf der Buchungswert nur ausgegeben werden, wenn das Buchungsdatum auch innerhalb der Gültigkeit der Anlage liegt.

Insgesamt werden hier drei Felder angelegt:

1. Feld Berichtswert
Kurzbezeichnung: Wert
Feldbezeichnung: Berichtswert
Überschrift: Berichtswert
Eigenschaften wie: KSL
Berechnungsvorschrift:
Hier werden entsprechende komplexe Berechnungen angestellt:
Bedingung: BUDAT >= ADATU AND BUDAT <= BDATU
Formel: KSL * 1
sonst: KSL * 0

Somit wird der Wert KSL (GLPCA-KSL) nur ausgegeben, wenn das Buchungsdatum des CO Beleges innerhalb des Zeitraums der zeitabhängigen Kontierung des Anlagenstammes aus der Tabelle ANLZ liegt.


2. Feld Kostenstelle
Kurzbezeichnung: KS
Feldbezeichnung: Kostenstelle
Überschrift: Kostenstelle
Eigenschaften wie: KOSTL
Berechnungsvorschrift:
Hier werden entsprechende komplexe Berechnungen angestellt:
Bedingung: KOSTL + AUFNR > 0
Formel: KOSTL
sonst: ANLZ_KOSTL

Dieses Feld gibt die im CO-Beleg vorhandene Kostenstelle aus, sofern innerhalb der Tabelle GLPCA die Summe der Felder KOSTL und AUFNR größer als Null ist (und damit eine Kostenstelle vorhanden ist). Sofern weder Kostenstelle noch Innenauftrag im CO Beleg vorhanden sind wird aus den Anlagenstammsatz die entsprechende Kostenstelle genommen.

3. Feld Innenauftrag
Kurzbezeichnung: IA
Feldbezeichnung: Innenauftrag
Überschrift: Innenauftrag
Eigenschaften wie: AUFNR
Berechnungsvorschrift:
Hier werden entsprechende komplexe Berechnungen angestellt:
Bedingung: KOSTL + AUFNR > 0
Formel: AUFNR
sonst: ANLZ_CAUFN

Sofern im CO-Beleg kein Innenauftrag übertragen wurde, wird in diesen Feld der im Anlagenstammsatz hinterlegte Innenauftrag ausgegeben.

Danach werden die Felder dann gefüllt wenn in den entsprechenden zeitabhängigen Daten die Felder gefüllt sind. Eine etwas ausführlichere Beschreibung zu diesen Feldern und den entsprechenden Hintergrund ist im Artikel "Abgleich Belege in CO auf Profit-Center mit zeitabhängigen Stammdaten der Anlagenbuchhaltung bei Investitionen"  erläutert.Die hier erläutertere Query wird vergleichbar aufgebaut, allerdings ohne ein Kontrollfeld, ob beim Erfassen des Anlagenbeleges eine Übergabe der CO-Objekte vergessen worden ist.

Die entsprechende Grundliste wird wie folgt aufgebaut:

Auch in dieser Aufstellung ist L als Listenfeld und S als Selektionsfeld zu verstehen. Die Felder werden hier in der Reihenfolge angegeben, wie diese dann auch in der Query ausgegeben werden sollen:

EC-PCA: Ist-Einzelposten (GLPCA)
Geschäftsjahr (L,S) GLPCA-RYEAR
Buchungsperiode (L,S)  GLPCA-POPER
Kontonummer (L,S) GLPCA-RACCT
Soll-/Haben-Kennzeichen (L,S) GLPCA-DRCRK
Profit-Center (L,S) GLPCA-RPRCTR
Anlagen-Hauptnummer (L,S)  GLPCA-ANLN1
Anlagenunternummer (L) GLPCA-ANLN2
Anlagenbewegungsart (L,S) GLPCA-ANBWA

Bewertungsartentexte der Anlagenbuchhaltung (TABWT)
Bezeichnung Bewegungsart (L) TABWT-BWATXT

EC-PCA: Ist-Einzelposten (GLPCA)
Betrag in Proftit-Center-Hauswährung (L) GLPCA-KSL
Buchungsdatum im Beleg (L) GLPCA-BUDAT

Valutierte Anlagenzuordnung (ANLZ)
Datum Gültikatisbeginn (L) ANLZ-ADATU
Datum Gültigkeitsende (L) ANLZ-BDATU

Im Folgenden werden sowohl die CO-Objekte aus der Anlagenbuchhaltung als auch der Profit-Center-Rechnung ausgegeben. Dieses ist erforderlich um etwaige Fehler bei der Erfassung der Anlage zu umgehen. Genaueres zum Hintergrund ist im obene verlinkten Artikel erwähnt.

Valutierte Anlagenzuordnung (ANLZ)
ANLZ_KOST (L) ANLZ-KOSTL
ANLZ_CAUFN (L) ANLZ-CAUFN
ANLZ_VKOST  Verantwortliche Kostenstelle (L) ANLZ-VKOST

EC-PCA: Ist-Einzelposten (GLPCA)
GLPCA_KOSTL (L) GLPCA-KOSTL
GLPCA-AUFNR (L) GLPCA-AUFNR

Nun folgen die angelegten lokalen Zusatzfelder
Kostenstelle (L) KS
Innenauftrag (L) IA
Berichtswert (L) Wert

Sofern nun noch weitere Felder aus der Anlagenbuchhaltung mit ausgegeben werden sollen bietet sich hier die Tabelle ANLA Anlagenstammdaten an.

Für unseren Fall wird die Mittelherkunft über das Feld Ordnungsbegriff 1 abgebildet:

Anlagenstammsatz-Segment (ANLA)
Ordnungsbegriff 1 (L,S) ANLA-ORD41

Sofern die Bezeichnung des Ordnungsbegriff 1 in der Selektionsmaske geändert werden soll bietet es sich an vom Einstiegsbild der Query über SPRINGEN->FELDAUSWAHL->SELEKTIONEN die Bezeichnung Ordnungsbegriff 1 mit Mittelherkunft zu überschreiben. Über die Wertauswahlhilfe (F4) können dann entsprechende Ordnungsnummer selektioert werden, so dass im Selektionsbild entsprechend ausgewählt werden.


 

Hintergrund: Anlagenzugänge über Bewegungsart und Buchungskonto selektieren

Die einfachste Auswertung dürfte nun eine Liste sein die über die Selektion der Anlagenbewegungsart erfolgt.In der Regel ist der Anlagenzugang über die Anlagenzugangsarten 100 bis 190 oder sofern innerhalb eines Konzern auch Anlagenzugänge aktiviert werden oder allerdings zur Aktivierung von Anlagen im Bau bzw. Anlagen selbst erstellt werden dürften auch die Anlagenbewegungsarten:

• 300 Umbuchung Altbestand abgehend von aktiver Anlage
• 310 Umbuchung Altbestand zugehend von aktiver Anlage
• 320 Umbuchung Neuzugang abgehend
• 330 Umbuchung Neuzugang zugehend
• 345 Umbuchung Neuzugang abg.von Anlage im Bau Einzelp.
• 346 Umbuchung Neuzugang zugehend von Anlage im Bau

relevant sein. Als Sachkonto sollten hier dann die Buchungskonten der Anlagenbuchhaltung ausgewertet werden. Basierend auf den Kontenplan IKR kann dieses bspw. über folgendes Intervall dargestellt werden (ohne Werberichtigungskonten)

100000    1000099
1000101    2100099
2100101    5000099
5000101    7000099
7000101    7900099
7900101    8000099
8000101    8900099
8900101    9000099
9000101    19999998
27900000 27999999

Layoutvariante anlegen für Investionsliste

Über eine Layoutvariante können nun folgende Felder ausgegeben werden:

• Geschäftsjahr
• Buchungsdatum
• Kostenstelle
• Innenauftrag
• Berichtswert

Damit werden mit Berichtswert 0 solche Daten ausgegeben sofern sich die CO-Objekte (Zuordnung Kostenstelle, Innenauftrag) wieder geändert haben (zum Beispiel Finanzierung aus Kostenstelle oder Innenauftrag). Vom Selektionsbild ist es nun möglich entweder Profit-Center, Kostenstellen, Innenaufträge oder die Mittelherkunft als Auswahlkriterium zu wählen. Dabei sind auch Platzhalter wie * möglich zu verwenden.

Die Vorraussetzung für das Buchen auf Innenaufträgen in der Anlagenbuchhaltung ist im Artikel "Abgleich Belege in CO auf Profit-Center mit zeitabhängigen Stammdaten der Anlagenbuchhaltung  bei Investitionen" ausführlicher beschrieben.

Grundsätzlich eignet sich diese Query auch als Zugangsliste für Investitionen, wobei dieses nur Sachanlagen (mit Stammsatz in der Anlagenbuchhaltung und nicht Finanzanlagen betrifft. Eine Möglichkeit der Auswertung von Finanzanlagen ist im Artikel "Query FI Einzelposten als Belegjournal - Belegsegment (BSEG) und Belegkopf (BKPF) verknüpfen" beschrieben.


 

---

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.

---

Nachdem im letzten Artikel "Grundlagen Kurzeinführung und Handbuch Report Painter Report Writer" ausführicher behandelt worden ist, soll hier das Thema SAP Query und die Nutzung im Haushaltsmanagement ausführlicher behandelt werden.

Im Rahmen einer SAP Schulung durch Martin Peto (Mitautor des Buch "Reporting im SAP-Finanzwesen: Standardberichte, SAP QuickViewer und SAP Query" welches ich etwas ausführlicher unter SAP Query Buch beschrieben habe) sind einige Eckpunkte zum Berichtswesen mit SAP Query und der Auswertung innerhalb des Moduls PSM-FM angesprochen worden. Die erlangten Kenntnisse habe ich in diesen Artikel festgehalten und betrachte diese als eine Ergänzung zur Einführung, die ich im Artikel "Grundlagen Kurzeinführung und Handbuch SAP Query"  angefangen habe. Neben den empfehlenswerten Buch soll daher auch dieser Artikel einige Denkanstöße zur Nutzung von SAP Query bieten. Da ein besonderes Interesse an der Nutzung von SAP Query mit PSM-FM bestanden hat, sind auch die hier aufgelisteten Erkenntnisse in der Hauptsache mit Bezug zum "public sector management" aufgeführt.

Im Einzelnen konnte ich dabei folgende Punkte aus der Schulung (und der gedanklichen Weiterentwicklung) mitnehmen

• Verwendung der Logischen Datenbank FMF
• Stammdatentabellen innerhalb des SAP Modul PSM-FM
• Zusatzfeld ZAUFNR um die Stammdatentabelle FMFINCODE als Zusatztabelle im Infoset einzufügen
• Gedanklich lässt sich dieses Feld natürlich wunderbar für die Auswertung der Merkmale der Klassifizierung von Haushaltsfond verwenden
• Variablentyp bei Varianten waren für mich ebenfalls neu, was bei Selektionsvarianten gleich eine neue Dynamik reinbringen kann
• Die Möglichkeiten des Verzicht auf den grafischen Painter für Query, waren ebenfalls interessant, auch wenn ich wohl weiterhin mit der grafischen Oberfläche arbeiten werde
• Eine gute Möglichkeit des Coding im Zusatzfeld wurde anhand des Soll/Haben Kennzeichen innerhalb der Tabelle BSEG erläutert. Hier hatte ich damals tatsächlich mit lokalen Feldern und Formeln gearbeitet und bin nicht auf die Idee gekommen, dieses auf Zusatzfelder im Infoset umzustellen
• ... (sicherlich sind mir noch die ein oder andere Sache entfallen, die aber gerne als Kommentar ergänzt werden kann)
• Weitere Quellen und Literaturempfehlung

Ich denke, dass die in der Schulung angesprochenen Punkte tatsächlich hilfreich sind und sich die aufgezählten Punkte als Erweiterung sehr gut eignen. Entsprechend lehrreich könenn auch Schulungen neben Literatur sein und so die eigene Arbeitsweise noch ein Stück verbessern. Gerade der Schwerpunkt auf der Nutzung von SAP Query innerhalb der Rechnungswesenmodule hat hier doch einige gute Erweiterungen gebracht, auch wenn nicht alle Beispiele auf das Hochschulberichtswesen 1:1 übertragbar sind. Ansonsten sind für das Berichtswesen im Bereich PSM-FM weiterhin die im Artikel "PSM Haushaltsmanagement Budgetverwaltungssystem BCS oder klassische Budgetierung" ebenfalls erwähnten Anmerkungen zur Nutzung der Rechercheberichte erläutert.

Logische Datenbank im Bereich PSM-FM

Bisher hatte ich eher mit den logischen Datenbanken BRF für die Finanzbuchhaltung oder ADA für die Anlagenbuchhaltung zu tun.

Logische Datenbanken enthalten schon Verknüpfungen und können direkt als Grundlage für ein Infoset verwendet werden. Dieses hat den Vorteil, dass man nicht selbst erst einzelne Tabellenverknüpfungen erstellen muss. Die Struktur einer logischen Datenbank kann in der Transaktion SE36 eingesehen werden. Im Bereich HCM wären dieses bspw. PNP oder PCH während innerhalb des Rechnungswesen ggf. die Datenbanken ADA für die Anlegenbuchhaltung und BRF für FI Belege interessant sind.

Allerdings gibt es auch für das Modul PSM-FM eine vergleichbare Datenbank.
Innerhalb der logischen Datenbank FMF werden verschiedene Datenstrukturen mit Bewegungsdaten versorgt. Ein Blick auf diese Datenbank mit der Transaktion SE36 kann hier tatsächlich hilfreich sein.

Neben den reinen Stammdaten können hier auch Bewegungsdaten (unter anderen Summensätze und Einzelposten von Jahresbudget oder Gesamtbudget ebenso ausgewertet werden, wie die Summensätze aus Einzelposten und Obligo.

Leider handelt es sich bei den meisten zugeordneten Tabellen nicht um transparente Tabellen die direkt ausgewertet werden können sondern um Strukturen, die zur Laufzeit gefüllt werden. Immerhin kann durch die Verwendung der logischen Datenbank hier auch eine Struktur ausgewertet werden, so dass neben der Auswertung der PSM-FM Daten über Rechercheberichte auch mit SAP Query eine Einzelauswertung erfolgen kann.

Stammdatentabellen im Modul PSM-FM

Neben der Auswertung der logischen Datenbank kann aber auch der Zugriff auf einzelnen Tabellen im Bereich PSM-FM hilfreich sein.
Hierzu sind folgende transparente und damit direkt auswertbare Tabellen hilfreich, insbesondere da diese auch mit anderen Tabellen in Infosets verknüpft werden können.

• FMFINCODE
  "FIFM: Finanzierungscode" - hier sind die Stammdaten der Fonds inklusive Finanzierungszweck als Gegenstück zum CO Innenauftrag zu finden
• FMFCTR
  "Stammsatz der Finanzstelle" - hier sind die Stammdaten der Finanzstelle als Gegenstück zur Kostenstelle zu finden
• FMCI und FMCIT
  "Fiannzpositionen Stammdaten" und "Finanzpositionen Texte" - und damit die Stammdaten der Finanzpositionen als Gegenstück zum Sachkonto oder der Kostenart zu finden
• AUSP
  "Ausprägungswerte der Sachmerkmale" - für die Auswertung der Merkmale der Klassifizeriung (wie im Artikel "SAP Query - Auswertung Merkmale der Klassifizierung am Beispiel Fonds in PSM-FM" beschrieben).
• JEST
  In dieser Tabelle werden die Systemstatus von einzelnen Objekten festgehalten. Hierdurch kann zum Beispiel ausgewertet werden, ob der CO Innenauftrag gesperrt ist. Auf dieses Thema bin ich im Artikel "SAP Query ABAP Coding im Zusatzfeld für Verknüpfung Innenauftrag und Fond bzw. Finanzierungszweck oder auch Status GESPERRT bei Innenaufträgen" näher eingegangen.

Verknüpfung der Tabellen FMFINCODE und AUFK

Während ich in meiner Artikelserie:

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"

teilweise einzelne Felder aus der Tabelle FMFINCODE einzeln übernommen habe (durch individuelles Coding je Feld), hatte Martin Peto die Idee die Tabelle FMFINCODE als Zusatztabelle einzubinden.Hierfür hat er ein Zusatzfeld ZAUFNR für die Übernahme der Auftragsnummer aus der Tabelle AUFK (Feld AUFNR)  welches als Feld mit 12 Stellen definiert ist in das zehnstellige Feld vergleichbar mit der Tabelle FMFINCODE (Feld FINCODE) für den Fond.

Die beiden Tabellen AUFK und FMFINCODE lassen sich nicht verknüpfen, da die Feldlänge mit 10 bzw. 12 Zeichen nicht übereinstimmen. Daher wurde innerhalb des Infoset das Feld ZAUFNR als "Auftragsnummer 10 stellig"  mit LIKE-Referenz (also den gleichen Eigenschaften von FMFINCODE-FINCODE angelegt.

Zusatzfeld ZAUFNR (Übernahme AUFK-AUFNR als FMFINCODE-FINCODE

Über die Schaltfläche Zusätze (F5) bzw. innerhalb der Transaktion SQ02 (Pflege des Infosets) über  SPRINGEN-> ZUSÄTZE ZUM KNOTEN können eigene Felder definiert 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 ZAUFNR)  und die Art der Zusatzinformation. Zur Auswahl stehen: Zusatzfeld, Zusatzstruktur und Coding. In unserem Beispiel soll ein Zusatzfeld mit den Namen ZAUFNR angelegt werden.

Dieses hat folgende Eigenschaften: Langtext und Überschrift haben beide Auftragsnummer 10 stellig oder einfach Auftragsnummer erhalten. Die Formatangabe wurde über LIKE-Referenz idenitsch zum Feld FMFINCODE-FINCODEgehalten. Damit entspricht dieses Feld den Formatangaben in der Tabelle FMFINCODE (Typ C (Character) Länge 010 Ausgabenlänge 010).

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 über das wiederum eine Datenbankabfrage erfolgen kann.

Das in meinen Augen clevere Coding beschränkt sich auf einen Einzeiler in dem dem Feld per Offset die Auftragsnummer aus der Tabelle AUFK zugewiesen wird.

Für eine achtstellige Projektnummer (Innenauftrag) lautet das Coding wie folgt:

ZAUFNR = AUFK-AUFNR+4(8).

Hierbei bedient sich das Coding der Technik eines Offsets.

Durch die optionalen Angaben eines Offsets +<o> und eine Länge (<l>) direkt hinter dem Feldnamen <f>, wird der Teil des Felds, der auf Position <o>+1 beginnt und die Länge <l> hat, als eigenes Datenobjekt angesprochen.  In unseren Fall wird also für die Variable ZAUFNR das Feld AUFK-AUFNR (wir erinnern uns die zwölfstellige Auftragsnummer) eingelesen und ab der vierten Stelle insgesamt acht Stellen eingelesen. Da in der Datenbank die Auftragsnummer mit führenden 0000 hinterlegt wird erhalten wir also statt des Datenbankwerte 000012345678 die tatsächliche Auftragsnummer 12345678.

Sollten Sie eine andere Länge bei den Aufträgen oder Fonds definiert haben ist das Coding natürlich entsprechend anzupassen.

Im Ergebnis haben wir nun das Feld ZAUFNR, welches die gleichen Eigenschaften wie das Feld FINCODE innerhalb der Tabelle FMFINCODE hat.

Zusatztabelle FMFINCODE ins Infoset übernehmen (Stammdaten Fond) aus ZAUFNR

Dieses Feld kann nun zur Einbindung einer Zusatztabelle genutzt werden.

Über die Schaltfläche Zusätze (F5) bzw.  über  SPRINGEN-> ZUSÄTZE ZUM KNOTEN  innerhalb der Transaktion SQ02 (Pflege des Infosets) kann nun eine Zusatztabelle eingefügt werden. Hierzu kann im Register Zusätze die Schaltfläche Anlegen ausgewählt werden.
Hierzu tragen wir die den Namen FMFINCODE  und als Art der Zusatzinformation Zusatztabelle ein.

Hier ist es nun wichtig, dass Sie bei "Reihenfolge de Codeabschnitts" eine 2 eintragen, da natürlich erst das Feld ZAUFNR definiert sein soll, bevor Sie mit der Zusatztabelle arbeiten.

Nun erfolgt eine Abfrage über SELECT SINGLE * FROM FMFINCODE WHERE ...
in der folgedene (hervorgehobene) Bedingungen erfüllt sein sollen.

WHERE FIKRS  =  AUFK-BUKRS

da Finanzkreis und Buchungskreis identisch sind, können hier beide Felder sowohl in der Tabelle AUFK als auch FMFINCODE verwendet werden.

AND FINCODE = ZAUFNR

Hierdurch werden dann tatsächlich Fonds und Innenauftrag miteinander verknüpft und es steht die gesamte Tabelle FMFINCODE im Infoset zur Verfügung.

Merkmale der Klassifizierung durch Definition Feld OBJNFOND

Entsprechend einfacher ist auch die Übernahme dieser Auftragsnummer zur Definition des Feldes OBJNFOND um Merkmale der Klassifizierung zu übernehmen.

Auf die dahinter liegende Methode bin ich schon im Artikel "SAP Query - Auswertung Merkmale der Klassifizierung am Beispiel Fonds in PSM-FM" eingegangen.

Allerdings muss jetzt das Zusatzfeld OBJNFOND nicht mehr per SHIFT aus der Auftragsnummer definiert werden sondern kann im Codeabschnitt 2 wie folgt definiert werden.

Per ABAP zwei Strings mit Leerzeichen verknüpfen

Nun haben wir also die Nummer des Fonds (sofern ein entsprechender Fond passend zum Innenauftrag angelegt worden ist im Feld ZAUFNR angelegt. Dieses muss nun mit "FIK " verknüpft werden.

Die Abap Anweisung

CONCATENATE altenstring neuenstring INTO altenstring.

 verkettet getrennte Zeichenfolgen zu einer Zeichenfolge. Hier wäre nun eine Verkettung des Finanzkreises  'FIK ' mit anschliessenden Leerzeichen und des Fonds denkbar. Allerdings werden Leerzeichen innerhalb der Strings ignoriert. Bei Werten des Typs C (Character) besteht aber die Möglichkeit diese Anweisung um den Parameter RESPECTING BLANKS zu erweitern. Dieses ist nur bei Zeichenketten auch Leerzeichen berücksichtigt werden. Ohne diesen Parameter werden Leerzeichen (Zeichen 32 im ASCII Code) einfach entfernt.

Zusatzfeld OBJNFOND aus ZAUFNR ableiten

(Finanzkreis und Fond verknüpfen entsprechend AUSP-OBJEK)

Entpsprechend wird ein weiteres Zusatzfeld angelegt. Dieses Feld erhält die Bezeichnung OBJNFOND und per LIKE die gleichen Eigenschaften wie das Feld AUSP-OBJEK.

Darüberhinaus wird im Feld "Reihenfolge des Codeabschnittes" statt wie bisher automatisch eine 1 eine 2 eingetragen. Hierdurch wird das Coding zum Feld OBJFOND nach erfolgreicher Wertzuweisung für das Feld ZAUFNR durchgeführt.

Nachdem ein Feld angelegt ist kann über die Schaltfläche "Coding zum Zusatz" ein passendes ABAP Coding für das Feld hinterlegt werden um das Zusatzfeld OBJNFND mit den Finanzkreis zu verknüpfen.

Hierzu ist folgende kurze Codezeile erforderlich:

CONCATENATE  'FIK ' ZAUFNR  INTO OBJNFOND RESPECTING BLANKS.

Nun ist im Zusatzfeld OBJNFOND der entsprechende Fond entsprechend der Objektnummer im Tabellenfeld AUSP-OBJEK gespeichert. Entsprechend hilfreich ist hier die Definition des Feldes ZAUFNR.

Nun können die einzelnen Merkmale der Klassifizierung wie im verlinkten Artikel "SAP Query - Auswertung Merkmale der Klassifizierung am Beispiel Fonds in PSM-FM" zur Klassifizierung eingebunden werden.

Das Ergebnis ist identisch zur bisherigen Methode, allerdings erscheint es mir etwas weniger aufwändig und natürlich durch die Einbindung der Stammdatentabelle FMFINCODE als Zusatztabelle auch eleganter.

Dynamische Datumsberechnung bei Varianten

Weniger im Bereich Query selbst dafür aber in Verbindung mit der Nutzung von Varianten interessant war die Möglichkeit bei Selektionsvarianten bei Varaiblen diese als Dynamisch im Feld Variablentyp zu definieren. Hierdurch besteht bspw. die Möglichkeit über eine Variable das aktuelle Tagesdatum +30 Tage definiert werden.
Auch sonst war der kurze Überblick über verschiedene Standardberichtstool im Bereich FI ein Vorteil der Schulung ebenso wie im Buch

Deaktivierung des grafischen Query Painter

Hier war der Vorteil der Schulung, dass tatsächlich nicht mit den grafischen Query Painter sondern mit der "alten" Ansicht gearbeitet wurde.Hierdurch konnten Sortierreihenfolgen und Formatierungen insbesondere für die ABAP Liste statt ALV  einige Formatierungen und Zwischensummen innerhalb der Grundliste aktiviert werden. Gerade durch mehrere Ebenen ist es hier ein Vorteil, dass noch weitere Informationen ausgegeben werden können. In der Praxis (oder vielmehr in meinen Alltag) verwende ich jedoch tatsächlich eher die Query im Format einer ALV, so dass ich problemlos die Daten exportieren kann und so nur die Spaltenüberschriften als Information verwende.

Trotzdem gibt es hier eine einfache Möglichkeit einzelne Datenfelder in unterschiedliche Zeilen aufzuteilen, oder Sortierkriterien festzulegen. Auch die Summenbildung kann hier sehr feinstufig festgelegt werden. Hier sind die Gruppenstufen der Grundliste einen Blick wert, aber auch die Gruppenstufentexte oder Kopf- und Fußzeilen sind ein Thema, was Berichte für die Ausgabe direkt am Screen hilfreich macht. Ferner können hier auch die Überschriftentexte auf einfache Weise angepasst werden. Nebenbei ist hier auch die Empfehlung die Überschriften schon im Infoset anzupassen. Ein Vorteil bei der Gestaltung dieser einzelnen Elemente und Formatierungen allgemein ist es auch die im System schon vorhandenen Berichte ein wenig besser zu verstehen.

Dieses ist vermutlich vergleichbar mit Kollegen, die immer die Excelintegration aktiviert haben und somit zum Beispiel bei Report Writer / Report Painter Berichten keine Zusatzinformationen sondern das Ergebnis ohne Kopfzeilen und Co dargestellt bekommen.

Coding in Zusatzfeldern

Ein weiterer, eigentlich einfacher Punkt ist in der Schulung die Idee gewesen das Soll / Haben Kennzeichen nicht nur in der Query zur Darstellung des Wertes zu verwenden. So habe ich im Artikel "Query FI Einzelposten als Belegjournal - Belegsegment (BSEG) und Belegkopf (BKPF) verknüpfen" beschrieben, wie anhand eines lokalen Feldes anhand des Soll-/Haben-Kennzeichen - SHKZG (BSEG-SHKZG)  und des  Betrag in Hauswährung - DMBTR (BSEG-DMBTR) nicht erst in der Query über ein lokales Feld und entsprechender Formeln, wie zum Beispiel :


1. Feld (Gebuchter Wert)
Kurzbezeichnung: WERT
Feldbezeichnung: gebuchter Wert
Überschrift: gebuchter Wert
gleiche Eigenschaften wie: DMBTR
Berechnungsvorschrift:
Hier wird eine komplexe Berechnung mit folgenden Bedingungen hinterlegt:

• Bedingung: SHKZG = 'S'
  Formel: 1 * DMBTR
• Bedingung: SHKZG = 'H'
  Formel: -1 * DMBTR

der gebuchte Wert mit passenden Vorzeichen dargestellt wird, sondern auch direkt im Infoset ein Zusatzfeld (als Beispiel BETRAGVZ), dieses schon im Infoset anhand folgendes Coding verwirklicht.

IF BSEG-SHKZG = 'H'.
      BETRAGVZ =  BSEG-DMBTR  * -1.
ELSE
     BETRAGVZ = BSEG-DMBTR.
ENDIF.

Damit steht das Betragsfeld mit "richtigen" Vorzeichen unter Berücksichtigung des Soll/Haben Kennzeichen für alle Query zur Verfügung und muss nicht jedes Mal aufs Neue berechnet werden.

 

Literaturempfehlung und weitere Quellen

Wie bereits erwähnt haben Martin Peto und Katrin Klewinghaus zum Thema SAP Query auch folgendes Buch geschrieben.


Themen sind unter anderen

• SAP-Informationssysteme im Überblick
• Standard-Reporting mit SAP List Viewer (ALV)
• Einsatzmöglichkeiten und Grenzen des SAP QuickViewers
• Aufbau von SAP Queries mit Praxisbeispiel

Sollte sich noch jemand für das angesprochene Buch interessieren, so ist dieses auch auf meiner Unterseite zum Buch  "Reporting im SAP-Finanzwesen: Standardberichte, SAP QuickViewer und SAP Query" beschrieben und kann hier auch bestellt werden.


Daneben kann ich aber auch das Buch von Stephan Kaleske (bzw. in der neuen Auflage auch von Karin Bädekerl, Heinz Forsthuber empfehlen.


ISBN: 978-3836218405

Eine ausführlichere Beschreibung dieses Buch ist auf der Seite "Praxishandbuch SAP Query-Reporting" zu finden. Dieses Buch geht sogar noch ein wenig tiefer in die Materie SAP Query ein und eignet sich damit hervorragend als Nachschlagewerk für fortgeschrittene Anwendende.

 

---

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.

---