Andreas Unkelbach
Logo Andreas-Unkelbach.de

Artikel zum Stichwort Query

Alle folgende Artikel sind unter den angegeben Stichwort (TAG) einsortiert. Sollte der gesuchte Artikel nicht dabei sein kann hier auch die Artikelsuche weiter helfen.

Oft sind aber auch die aktuellen Artikel in der jeweiligen Kategorie im Menü interessant.
Espresso Tutorial - die digitale SAP Bibliothek

SAP Fachliteratur ist unter Buchempfehlungen inklusive ausführlicher Rezenssionen und Bestellmöglichkeit zu finden.



Montag, 24. Juli 2017
21:28 Uhr

Grundlagen SAP Query Variablen über Selektionsfelder mit Werten füllen Eingabe auf Selektionsbild oder Abgrenzungsparameter

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.




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


Montag, 26. Juni 2017
14:25 Uhr

Buchveröffentlichung »Berichtswesen im SAP®-Controlling«

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.
 
Berichtswesen im SAP®-Controlling
Cover Berichtswesen im SAP Controlling
Verlag: Espresso Tutorials GmbH
1. Auflage (01. Juni 2017)

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.
Mein erster Blick ins Buch

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.

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


Samstag, 27. Mai 2017
17:44 Uhr

Query zur Auswertung von Klassifizierungsmerkmale PSM Fonds zu CO Innenauftrag und Datumsfelder mit Konvertierung von FLOAT zu DATUM

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 Wert als Float AUSP-ATFLV
Datum als Float
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.
 
Feld Format Berechnungsvorschrift Bedingung
Felder zum Auswertung AUSP-ATFLV
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:
 
ATFLV1 DATUM DATUMTXT JAHR MONAT TAG DATUMZAHL DATUMATFLV1
Query zur Auswertung ATFLV1 aus FLOW wird DATE
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.




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


Samstag, 13. Mai 2017
21:38 Uhr

Neue Wertgrenze für Investitionen bei Finanzstatistik oder Abfrageparameter in SAP Query zur Übernahme von Werten aus Selektionsbild

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.




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


Montag, 24. April 2017
18:48 Uhr

Grundlagen: Selektionstext für Selektionsfelder bei SAP Query ändern

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.




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


Samstag, 8. April 2017
14:32 Uhr

Anzahl Belege Kreditor je Fachbereich oder Abteilung anhand Kostenstelle oder verantwortliche Kostenstelle CO Innenauftrag

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:

Infoset Tabellen GLPCA, BSAS, LFA1, BSAK und SKAT

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.




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


Sonntag, 2. April 2017
18:41 Uhr

Auswertung per CMOD eingeführter kundeneigener Felder Kostenart, Kostenstelle und Innenauftrag per Stammdatenverzeichnis und SAP Query

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.
Beschreibung Technischer Name L S
Auswertung Auftragsart und Auftragslayout
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.
CO Objekt Tabelle Include Bezeichnung
CI Zusatzfelder
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.




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


Samstag, 10. Dezember 2016
09:17 Uhr

Vortrag Controlling Tipps aus der Praxis für die Praxis und die Espresso digitale SAP Bibliothek Flatrate

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.

SAP ERP Controlling Tipps »Aus der Praxis für die Praxis« von www.Andreas-Unkelbach.de



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.

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.

Die digitale SAP-Bibliothek LOGON

Danach ist eine Übersicht aller verfügbaren Bücher und Videos zu sehen.

Startseite digitale Bibliothek

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.

Auszug Themengebiete Espresso Tutorials

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.

Einzelbuchansicht mit Buchbeschreibung

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.

Buch auf virtuellen Schreibtisch mit ausgeklappten Inhaltsverzeichnis

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.

Ein aufgeschlagenes Buch

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.


 
Schnelleinstieg ins SAP-Controlling (CO)
Verlag: Espresso Tutorials GmbH
1. Auflage (01. November 2014)
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. 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.

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


Mittwoch, 2. November 2016
05:48 Uhr

Salden je Finanzposition mit Unterscheidung Personal oder Sachaufwand aus PSM-FM durch Query über logische Datenbank FMF

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.
Aufbau Industriekontenrahmen (IKR) - Kontenklassen  Auszug aus Schnelleinstieg ins SAP Controlling (CO)  ISBN 9783960126874
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.




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


Samstag, 22. Oktober 2016
15:09 Uhr

Drittmittelstatistik nach LOMZ über Recherchebericht und SAP Query

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)
Verlag: Espresso Tutorials GmbH

1. Auflage (01. November 2014)

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.
 

Hinweis:

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




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


Dienstag, 23. August 2016
17:55 Uhr

Auswertung sprechender Nummernkreisintervalle von CO Innenaufträgen mit Query Zusatzfeldcoding und Unterscheidung numerischer oder alphanumerischer Schlüssel

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.
 
Schnelleinstieg ins SAP-Controlling (CO)
Verlag: Espresso Tutorials GmbH
1. Auflage (01. November 2014)
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.




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


Sonntag, 3. Juli 2016
14:56 Uhr

Gruppierung von Finanzierungszwecken bei Drittmittelprojekten per Zusatzfeldcoding mit IF oder CASE

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

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

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

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

Finanzierungszweck in einer Query einbinden (Zusatzfeld oder Zusatztabelle)

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

Unterschied CASE WHEN zu  IF, ELSEIF Statement

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

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

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

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

Der Syntax dazu lautet:

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

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

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

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

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

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

Exkurs Finanzierungszweck über Zusatzfeld finuse

Zusatzfeld PSM-FM Finanzierungszweck aus Fond

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

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

ACHTUNG: Länge der Auftragsnummer / Fondsnummer beachten!

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

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

Zusatzfeld FINANZIERUNGSGRUPPE mit CASE Anweisung

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

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

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

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

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

1. Variante Orientierung am Zusatzfeld FINUSE.


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

finuse = L_FINZWECK.

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

CASE finuse.

2. Variante Einbindung als Zusatztabelle

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

CASE FMFINCODE-FINUSE.

3. Coding mit Bedingungen

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

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

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

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

 WHEN OTHERS.
    FINGRUPPE = FMFINCODE-FINUSE.
ENDCASE.

und für das Zusatzfeld:
 

 WHEN OTHERS.
    FINGRUPPE = finuse.
ENDCASE.

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

Anwendungsgebiet Finanzierungsgruppe

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

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

Hinweis:

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




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


Samstag, 11. Juni 2016
10:49 Uhr

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

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

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

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

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

Vorschlag: Berechtigungsrolle zum Ausführen von SAP Query

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

Daneben bedarf es folgender Berechtigungen:

S_TABU_DIS
ACTVT Aktivität 03
DICIBERCLS Tabellenberechtigung *

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

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

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

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

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

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

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

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

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

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

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


 

Hinweis:

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




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


Montag, 16. Mai 2016
15:50 Uhr

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

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

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

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

Phasen eines Auftrag bzw. Status

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

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

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

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

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

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

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

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

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

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

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

Auswertung Query über einzelne Phasen eines Projektes

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

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

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

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

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

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

 

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

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

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

Die drei Zusatzfelder sind in den folgenden Abschnitten

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

Reihenfolge Selektionsfelder festlegen

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

Konzeption Prozesse und notwendige Stammdatenfelder

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

 

Hinweis:

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




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


Sonntag, 1. Mai 2016
11:22 Uhr

Abrechnungsvorschriften von Innenaufträgen auf identische verantwortliche Kostenstelle und empfangende Kostenstelle per Query mit Ampelfunktion prüfen

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.




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


Samstag, 23. April 2016
22:04 Uhr

Teilen in SAP Query mit den Funktionen MOD und DIV zur Darstellung von Absolutwerten oder auch Restwert bei Divisionen

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"

Mein Tweet zum Wochenende passend zum Weltbuchtag
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:
 
KAP VE FELD1
Formel DIV
 
FELD2
Formel MOD
 
FELD3
Bedingung
 
Excel/Mathe
Beispiel zur Verwendung von MOD und DIV in Query
 
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.




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


Donnerstag, 3. März 2016
17:50 Uhr

Query Einzelpostenliste Innenauftrag mit Ausweis Ertrag und Aufwand Zweiter Teil Query zur Datenaufbereitung

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:

Infoset AUFK-COEP und Zusatzfelder sowie Zusatztabelle FMFINCODE

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.
Aufbau Industriekontenrahmen (IKR) - Kontenklassen  Auszug aus Schnelleinstieg ins SAP Controlling (CO)  ISBN 9783960126874
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.




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


Donnerstag, 18. Februar 2016
20:51 Uhr

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

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.

Stammdaten CO Innenauftrag AUFK verkn�pft mit CO Ist-Einzelposten (COEP und COBK)

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:

Darstellung Infoset aus AUFK, JEST (mit TJ02) und JCDS
Wobei das Thema Systemstatus auch sehr umfassend in den beiden Artikeln:
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:
Infoset inklusive Zusatztabellen und Zusatzfelder f�r AUFK, FMFINCODE und COEP

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.




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


Donnerstag, 28. Januar 2016
22:32 Uhr

Einzelposten Klassische Budgetierung Hierarchiebelge

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.




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


Mittwoch, 27. Januar 2016
18:51 Uhr

Auswertung Kreditoren Einzelposten inklusive CO Objekte wie Kostenstelle oder Innenauftrag

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. Hierzu ist ein etwas komplexeres Infoset anzulegen.
Infoset Tabellen GLPCA, BSAS, LFA1, BSAK und SKAT
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.

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.




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


Montag, 7. Dezember 2015
17:37 Uhr

Zusammenfassung Query über Anlagenzugang - Auswertung Investitionen aus Profit-Center-Rechnung

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
Infoset über GLPCA-TABWT-ANLZ-ANLA

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.




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


Donnerstag, 12. November 2015
18:26 Uhr

SAP Query innerhalb des SAP Moduls PSM FM beziehungsweise Haushaltsmanagement

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 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.



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.

Reporting im SAP - Finanzwesen
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.

Praxishandbuch SAP Query-Reporting
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.




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


Mittwoch, 14. Oktober 2015
21:30 Uhr

Obligo Verwaltung im SAP Modul CO - Customizing, Standardberichtswesen, Report Writer/Painter und SAP Query

Obligos entstehen entweder durch Bestellung oder durch Mittelbindung im CO. Allerdings muss hierfür die Obligoverwaltung in SAP aktiviert werden. Diese ermöglicht neben einer Darstellung der Kosten (unabhängig ob durch von FI fortgeschriebenen Kosten auf primäre Kostenarten) oder innerhalb CO getätigte interne Buchungen (so auch auf sekundäre Kostenarten).
 

Customizing Obligoverwaltung im Modul CO aktivieren

Die Obligoverwaltung ist je nach Kostenrechnung zu aktivieren  (Customizing Transaktion SPRO) und entsprechende Belegarten sowie Nummerkreise zu definieren.

Für die Kostenstellenrechnung ist eine Aktivierung in der Transaktion SPRO über den Customizing-Pfad unter folgende Knoten möglich:

CONTROLLING -> KOSTENSTELLENRECHNUNG -> OBLIGO UND MITTELBINDUNG

Daneben gibt es die Möglichkeit auch für Innenaufträge unter

CONTROLLING -> INNENAUFTRÄGE -> OBLIGO UND MITTELBINDUNG

über den Punkt "OBLIGOVERWALTUNG AKTIVIEREN".

Ferner müssen Belegarten und Nummernkreise für die in CO vverwendeten MITTELBINDUNG eingestellt werden.

Innerhalb der Kostenstellenrechnung ist dieses im gleichen Pfad durch die beiden Punkte "BELEGARTEN ZUR MITTELBINDUNG PFLEGEN" und "NUMMERNKREIS für MITTELBINDUNG DEFINIEREN" möglich, während bei den Innenaufträgen ein Unterordner MITTELBINDUNG die beiden Punkte "BELEGARTEN PFLEGEN" und "NUMMERNKREIS DEFINIEREN" aktiviert werden.

Feldsteuerung Mittelbindung

Ein weiterer Punkt im Customizing ist die Pflege der Feldauswahl. Diese ist im Customizing unterhalb der Einstellungen zur Mittelbindung über die Feldsteuerung Mittelbindung zu finden.Über die Feldauswahlliste legen Sie fest, welche Felder zur Erfassung einer Mittelbindung als Kanneingabe, Musseingabe nur angezeigt oder gar ausgeblendet wird.
Die Zuordnung von Feldstatusvarianten (die einen Buchungskreis zugeordnet ist), Feldstatusgruppe wird eine Feldauswahlliste zugeordnet. Die Feldauswahhliste steuert dann wie gesagt die dargestellten Felder.Über den oben erwähnten Punkt Belegart pflegen wird die Feldstatusgruppe der entsprechenden Belegart zum Beispiel Mittelbindung CO mit Nummernkreis und Feldstatusgruppe zugeordnet.
 

Mittelbindung für Obligo anlegen


Nun ist es auch innerhalb des Controlling möglich ein Obligo durch Mittelbindungen aufzubauen.

Sowohl in der KOSTENSTELLENRECHNUNG als auch bei den INNENAUFTRÄGEN kann hierzu der Unterordner ISTBUCHUNGEN->MITTELBINDUNG verwendet werden.

Als Funktionen stehen hier:
  • Mittelbindung anlegen (Transaktion FMZ1)
  • Mittelbindung ändern (Transaktion FMZ2) und
  • Mittelbindung anzeigen (Transaktion FMZ3)
zur Verfügung. Ferner besteht hier die Möglichkeit die "Mittelbindung abzubauen (Transaktion FMZ6). Damit ist die Mittelbindung als erledigt gesetzt. Auf diese Weise kann die Mittelbindung auf erledigt gesetzt werden und das entsprechende Obligo wird wieder abgebaut.

Einzelpostenlisten und Berichtswesen über Obligo-Buchungen

Ein Ausweis der Obligo Buchungen ist im Standardberichtswesen ist sowohl in der Kostenstellenrechnung als auch der Innenauftragsrechnung möglich. Auch im SAP Modul PSM-FM werden diese Mittelbindungen ebenfalls fortgeschrieben. Dieses dürfte ebenfalls durch Fortschreibung und Integration von CO und FM möglich sein.

Als Beispielberichte seien hier folgende genannt:

Kostenstellen: Ist/Plan/Obligo (Transaktion S_ALR_87013620
Dieser Bericht ist im SAP Menü unter;

CONTROLLING ->
INFOSYSTEM ->
BERICHTE ZUR KOSTENSTELLENRECHNUNG ->
PLAN/IST VERGLEICHE ->
ZUSÄTZLICHE KENNZAHLEN

zu finden.
 
Eine komplette Übersicht alle Obligo sind als "Kostenstellen Einzelposten Obligo" (Transaktion KSB2) im Gegensatz zu "Kostenstellen Einzelposten Ist" (Transaktion KSB1) zu finden.

Diese Berichte sind unter

CONTROLLING ->
INFOSYSTEM ->
BERICHTE ZUR KOSTENSTELLENRECHNUNG ->
EINZELPOSTEN

zu finden.

 Neben den Berichten in der Kostenstellenrechnung sind vergleichbare Berichte auch bei den Innenaufträgen zu finden.

Als Beispiele sind hier
Auftrag: Ist/Plan/Obligo (Transaktion S_ALR_87012999) zu nennen.
Dieser Bericht ist im SAP Menü unter;

CONTROLLING ->
INFOSYSTEM ->
BERICHTE ZUR KOSTENSTELLENRECHNUNG ->
PLAN/IST VERGLEICHE ->
ZUSÄTZLICHE KENNZAHLEN

Vergleichbare Einzelposten sind unter 

CONTROLLING -> INFOSYSTEM -> BERICHTE ZU INNENAUFTRÄGE -> EINZELPOSTEN

zu finden.

Sowohl die Einzelposten Obligo (Transaktion KOB2) als auch die Einzelposten Ist (Transaktion KOB1) zu finden.

Auswertung von Obligo im Report Writer / Painter

 
Auch beim Erstellen von eigenen Berichten kann das Obligo ebenfalls berücksichtigt werden. Dieses ist im Artikel "Erweiterung Report Writer Berichtsbibliothek 1CT zur Darstellung rollierendes Geschäftsjahr für Kostenstelle und Innenauftrag" beispielhaft beschrieben. Anhand des Werttyps sind hier entsprechende Spalten möglich zu definieren, so dass in einen Bericht neben Planwerten auch IST und OBLIGO mit auswertbar.

Auswertung von Obligo in SAP Query

Der erste Gedanke wäre, dass die Obligo-Belege ebenfalls in der Einzelpostenliste CO bzw. in der Tabelle COEP abgespeichert werden und hier mit Wertyp >20 selektiert werden können.

Allerdings werden Obligo-Belege in einer gesonderten Tabelle gespeichert.

Hier sind die Obligo-Einzelposten jedoch in der Tabelle COOI "Obligoverwaltung: Einzelposten" gespeichert. und müssen daher ergänzend zur COEP "CO-Objekt: Einzelposten periodenbezogen" ausgewertet werden. Diese Selektion der passenden Einzelposten und Summensätzetabellen nimmt einem das Berichtstool Report Writer / Report Painter natürlich ab :-).
 

Hinweis:

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




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


Freitag, 4. September 2015
15:13 Uhr

Grundlagen - Berichte von SAP nach Excel exportieren

Gerade die Weiterverarbeitung von Berichten in einer Tabellenkalkulation (in der Regel tatsächlich Excel) dürfte für jeden immer mal wieder ein Thema sein.

So ist es auch nicht weiter verwunderlich, dass dieses Thema sowohl im Artikel "Office Integration - Excelansicht in SAP und Daten kopieren nach Excel" (dieser Artikel ist besonders dann lesenswert, wenn die exportierten Daten in anderen Excelmappen weiterverarbeitet werden sollen - Stichwort: fehlerhafte Farben, Darstellung negatives Vorzeichen, Zahlen als Text,...) als auch unter "Darstellung negatives Vorzeichen in SAP - Standardlayout anpassen für vorangestelltes Vorzeichen" behandelt wurde. Trotzdem möchte ich ergänzend auf das Thema Exportieren nach Excel für verschiedene Berichtstools eingehen.

Bericht Exportieren im Report Writer (Expertenmodus erforderlich)

Innerhalb mit Report Painter / Report Writer erstellten Berichten, wie auch Standardberichten wie Kostenstellen Ist/Plan/Abweichung (Transaktion S_ALR_87012993), besteht die Möglichkeit innerhalb des Menüs BERICHT-EXPORTIEREN (Tastenkombination UMSCH + F2) entsprechende Berichte nach Excel zu exportieren.

Sollte diese Option bei Ihnen im Menü nicht aufgezeigt werden, sondern nur die Möglichkeiten Drucken.., Senden... und Beenden, liegt dieses daran, dass Sie noch nicht den Expertenmodus aktiviert haben.

Über die Schaltfläche Optionen/Office Integration (Tastenkombination STRG+UMSCHALT+F12) kann nicht nur die Office Integration (eine Darstellung des Berichtes in MS Excel) sondern auch die Aktivierung des Expertenmodus vorgenommen werden.

Durch die Aktivierung des Expertenmodus stehen Ihnen nicht nur die wesentlichen Funktionen im Bericht zur Verfügung sondern auch spezielle Funktionen wie Bericht exportieren.. , Layouteinstellungen oder das sichern von Extrakten.

Exkurs Extrakte

Durch Extrakte haben Sie die Möglichkeit umfangreiche Berichte zu speichern und diese direkt aufzurufen ohne dass dieser Bericht erneut erstellt werden muss. Hier dürfte der Artikel "ReportWriter Grundlagen - Extrakte sichern und verwalten" einen guten Überblick bieten.

Sofern der Expertenmodus aktiviert ist steht die Exportfunktion zur Verfügung und Sie können den Bericht als Exceltabelle weiterbearbeiten oder auch versenden.
 

Bericht exportieren nach Excel aus Recherchebericht

Zum Export von Rechercheberichten (sei es nun im Modul PSM-FM oder Bilanzberichte) gibt es ebenfalls die Möglichkeit über die "Berichtsausgabe an XXL" Hierzu kann die Schaltfläche Exportieren  oder BERICHT->EXPORTIEREN (STRG + UMSCH + F12) verwendet werden. Diese startet die Funktion Seite an XXL übergeben, wonach automatisch Excel gestartet wird und hier die Daten entweder als Tabelle oder Pivottabelle übergeben werden.

Je nach dargestellten Merkmal kann jedoch statt "Berichtsausgabe an XXL" auch das Fenster "Exportieren auf dem Präsentationsserver" dargestellt werden. Dieses ist zum Beispiel der Fall wenn statt Fonds die Darstellung auf Finanzstellen oder Finanzpositionen innerhalb einer Hierarchie  gewählt wurde. Ferner dürfte dieses auch der Fall sein, wenn eine GuV Struktur entsprechend dargestellt wird. Dieses Thema wurde unter anderen im Artikel "
Rechercheberichte im Modul FI (Bilanzanalyse)" (diese Rechercheberichte bieten sich auch als Quartalsberichte an).

Hier bietet es sich dann an im Abschnitt Ausgabedatei unter Datei eine temporäre Datei. Es bietet sich hier als Dateiname muster.dat in einem einfach zu erreichenden Pfad an. gewählt werden und im Abschnitt PC-Applikation starten unter Programm C:/EXCEL/EXCEL so dass hier direkt Excel gestartet wird mit eben dieser Datei. Es bietet sich dann natürlich an, diese direkt unter einen anderen Dateinamen zu speichern.


 

ALV Listen nach Tabellenkalkulation exportieren

Sofern Sie eine ALV Liste vorliegen haben, zum Beispiel eine SAP Query Auswertung (im Ausgabeformat SAP List Viewer) haben Sie ebenfalls die Möglichkeit über die Schaltfläche EXPORTIEREN die Option TABELLENKALKULATION als Auswahlmöglichkeit.
Teilweise kann diese Funktion auch im Menü unter BERICHT->EXPORTIEREN oder LISTE->EXPORTIEREN    TABELLENKALKULATION hinterlegt sein. So können Berichte, die nicht als "als interaktive Struktur" dargestellt werden, diese ALV Liste ebenfalls mitsamt der Formatierung nach Excel übertragen werden.

Nachdem Sie diese gewählt haben erscheint ein Auswahlmenü in welchen Format die Tabellenkalkulation übergeben werden soll.

Hierzu stehen Ihnen drei Formate zur Auswahl ("Excel (im MHTML Format)", "OpenOffice (im OpenDocument Format 2.0" sowie "Aus allen verfügbaren Formaten wählen"). Hierbei handelt es sich bei der letzten Option um eine Auswahlliste aller verfügbaren Formate.

Hier habe ich (vor Nutzung von Office 2007, 2010, 2013 oder neuere Versionen) immer das Format "Excel (im bisherigen XXL-Format)" empfohlen. Dieses hat jedoch den Nachteil, dass keine Filter, Sortierung oder Zwischensummen übernommen werden und auch das Layout der Tabelle eher gewöhnungsbedürftig ist (gelber Hintergrund und nicht unbedingt die Spaltenreihenfolge wie in der Query Ansicht).

Seit der Einführung von Office 2007 erscheint mir hier die Option "Excel (im Office 2007 XLSX Format)" wesentlich geeigneter, da hierdurch auch Sortierungen, Zwischensummen sowie der Tabellenaufbau inklusive Filterungen übernommen werden. Von daher ist es empfehlenswert die Excelversion zu wählen die entweder etwas kleiner oder identisch zur lokal eingestzten Excel Version ist. Auf diese Weise bleibt der "Kontoauszug" auch von der Darstellung in Excel identisch zur Darstellug in SAP.

Formatvorauswahl treffen und wieder aufheben

Neben der Auswahl des Formates bietet diese Exportfunktion auch die Aktivierung der Schaltfläche "Immer das gewählte Format anwenden". Hierdurch erscheint beim Export nicht mehr die Nachfrage nach den gewünschten Format. Dieses hat jedoch den Nachteil, dass Sie zum Beispiel nach Einführung einer neuen Excel-Version nicht mehr in das Auswahlmenü für das neue Format gelangen sondern der Export direkt ins ausgewählte Format erfolgt.

Zum Glück ist innerhalb der Liste dieses Auswahlmenü über die rechte Maustaste und hier der Punkt "Tabellenkalkulation ..." wieder aufrufbar, so dass hier erneut ein Format gewählt werden kann und ggf. die Option "immer das gewählte Format anwenden" deaktiviert werden kann.

Technischer Hintergrund SALV_BS_ADMIN

Die Standardeinstellungen werden in der Tabelle SALV_BS_ADMIN ("Tabelle zur Anlage von Steuerwerten zum ALV") je Nutzer gespeichert. Diese kann über den ABAP Report SALV_BS_ADMIN_MAINTAIN durch die SAP Basis gepflegt werden, sofern die User nicht selbst die Option Tabellenkalkulation auswählen.

Durch diesen Report (Transaktion SE80 oder SA38) können die Einstellungen je User eingesehen aber auch gelöscht, geändert oder auch angelegt werden.

Weiterführender Hinweis Downloadverzeichnis

Im Artikel "Downloadverzeichnis für SAP Berichte festlegen" ist auch beschrieben, wie das Zielverzeichnis für einen Export festgelegt werden kann.

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


Freitag, 28. August 2015
17:07 Uhr

Syntaxhevorhebung im ABAP Editor durch neuen Frontend Editor (Quelltext-Modus)

Während einer von mir angebotenen internen Schulung zu SAP Query (Basis der Schulung war auch die am Ende dieses Artikel verlinkte Einführung ins Thema)  war ich erstaunt über die unterschiedliche Darstellung der Oberfläche zur Erfassung von ABAP Coding bei den Zusatzfeldern, so wie diese zum Beispiel im Artikel "SAP Query ABAP Coding im Zusatzfeld für Verknüpfung Innenauftrag und Fond bzw. Finanzierungszweck oder auch Status GESPERRT bei Innenaufträgen" beschrieben wurden.

Neugierig geworden hatte ich nun ein wenig nach der Ursache dieses Unterschieds gesucht und bin recht angetan von der "neuen" Darstellungsweise.

 

Vorteil kollegialer Austausch oder Know How Transfer

So ergeben sich eben doch auch überraschende Kenntnisse, wenn Kolleginnen und Kollegen um einen kurzen Überblick zum Thema anfragen. Auch dieses ist ein Grund, warum ich sehr froh bin, dass hin und wieder ein technischer Austausch zwischen den einzelnen Einrichtungen möglich ist. Ein wenig bin ich auf das Thema "kollaboratives Wissensmanagement" ja auch im Artikel "Praktische Nutzung von social media Diensten für meinen Arbeitsalltag" eingegangen. Nun aber zum eigentlichen Thema.

Unterschied Frontend-Editor alt/neu bzw. Quellcode-basiert/Text-basierter ABAP Editor

Die klassische Darstellung entsprach dabei einen Textfeld in dem direkt das Coding eingefügt werden konnte, wie hier am Beispiel der Ausgabe des Zusatzfeld GESPERRT zu sehen ist:
Front-End Editor Alt
Screenshot © Copyright 2015. SAP SE. Alle Rechte vorbehalten *

Eine wesentlich moderne Form der Darstellung war dann wie folgt zu sehen.

Frontend Editor neu
Screenshot © Copyright 2015. SAP SE. Alle Rechte vorbehalten *

Hierbei wird der Frontend Editor (Quelltext-Modus) eingebunden der jedoch vorher aktiviert werden muss. Zumindest war dieses bei mir erforderlich, während neu angelegte User scheinbar direkt den "neuen" Quelltext-Editor gesehen haben.

Die Vorteile sind hier offensichtlich Syntaxthervorhebung, Autovervollständigung, Zeilennummerierung sowie die Möglichkeit des Zusammenklappens von zusammengehörenden Codeblöcken wie im Beispiel die IF-Bedingung.Gerade die Möglichkeit bestehende Codeblöcke zu expandieren oder zu kompromieren (im Beispiel die IF Bedingung verschafft hier einen guten Überblick über das Coding. Durch die Syntaxhervorhebung werden ABAP Schlüsselworte in blau, Bezeichner in schwarz und Zeichenliterale (alphanumerischen Zeichen bzw. Wertzuweisungen) in grün. Sofern ordentlich gecodet wird (und tatsächlich Kommentare mit eingefügt sind) werden Kommentare in Grau dargestellt. Syntaxfehler werden direkt in rot hervorgehoben.

Einstellungen ABAP Editor

Dieser neue Editor kann in einer beliebigen ABAP Workbench-Werkzeug Transaktion, SE38 – ABAP Editor, SE37 – Function Builder, SE24 – Class Builder oder SE80 Object Navigator über das Menü HILFSMITTEL->EINSTELLUNGEN aktiviert werden. Hierzu ist in der Registerkarte "ABAP Editor" im Reiter "Editor" der Punkt "Front-End Editor (neu)"  zu aktivieren.

Je nach SAP Version kann dieser Punkt auch "Quellcode basierter Editor" und die Alternative als "Text-basierter Editor" bezeichnet sein.

In meinen Fall ist hier der Punkt "Front-End Editor (neu)" wie in der unteren Abbildung abgebildet ausgewählt.

ABAP Editor - Editor - Frontend Editor (neu)
Screenshot © Copyright 2015. SAP SE. Alle Rechte vorbehalten *

Alternativ besteht, wie erwähnt die Auswahl zwischen Quellcode und Text basierter Editor (siehe Abbildung).

ABAP Editor - Editor - Quellcode-basierter Editor
Screenshot © Copyright 2015. SAP SE. Alle Rechte vorbehalten *

Hierdurch wird in allen Coding-Feldern dann auch tatsächlich die moderne Form des Quelltext-Editor im Quelltext-Modus mit allen Vorzügen betrieben. Allerdings ist diese Einstellung benutzerspezifisch, so dass diese für jeden Benutzer selbst vorgenommen werden muss. An der gleichen Stelle können auch die Einstellungen für den Pretty Printer vorgenommen werden, durch den vorhandener ABAP Code nach einer entsprechenden Vorlage formatiert wird. So kann in bestehenden ABAP Code jedes Schlüsselwort/jeder ABAP Befehl in Großbuchstaben geschrieben werden. ABAP selbst unterscheidet nicht zwischen Groß- und Kleinschreibung.

Hinweis EU_INIT, EU_REORG und EU_PUT bei SE80


Sofern Sie die Einstellungen im Object Navigator (Transaktion SE80) vorgenommen haben ist noch auf folgendes zu achten.

Beim erstmaligen Start der Transaktion SE80 (Repository Browser) werden automatisch die drei EU-Jobs erzeugt und, falls der Benutzer über ausreichende Berechtigungen verfügt, freigegeben: EU_INIT (einmaliger Start), EU_REORG (periodisch jede Nacht) und EU_PUT (periodisch jede Nacht).

Diese  EU-Jobs dienen dazu, für die ABAP Workbench wichtige Indizes (Verwendungsnachweise, Navigationsindizes, Objektlisten) neu aufzubauen oder zu aktualisieren. Gerade der Job EU_INIT ist dabei entsprechend intensiv auf der Datenbank aktiv, da hier alle Indizes komplett aufgebaut werden. Die beiden anderen Jobs sind dabei weniger "systemauslastend". Nähere Informationen hierzu sind im OSS Hinweis 18023 zu erfahren.

Änderungen "neuer" Frontend Editor

Eine Übersicht über die Änderungen des "neuen" Frontend Editor sind unter anderen im Berater-Wiki Eintrag zum Thema "Neuer Frontend Editor" von  René Eberstein (Freiberuflicher SAP-Entwickler) zu finden.

Sauberes ABAP Coding dank Namenskonventionen

Anhand oberes Coding ist zwar durch L_ erkenbar, dass es sich um ein lokales Objekt handelt (bzw. um eine lokale Variable) dennoch kann es sehr hilfreich sein sich in einer Programmiersprache an bestimmte Vorgaben zur Namensgebung bei Variablen zu halten.
im Developer Blog der exxens GmbH ist dieses Thema im Artikel "Prommmierrichtlinien / Namenskonventionen" recht ausführlich behandelt und kann als Vorlage dienen.

 

Hinweis:

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




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


Freitag, 8. Mai 2015
19:49 Uhr

Änderungsbelege für Stammdatengruppen im Customizing oder letzte Änderung über Query bspw. für Innenauftragsgruppen

Hin und wieder kann es erforderlich sein Änderungen in Stammdatengruppen anzeigen zu lassen. Diese Änderungsbelege sind beim Anlegen, Ändern oder auch Ansehen einer Gruppe über SPRINGEN -> Änderungsbelege anzuzeigen. Im SAP Standard werden hier Änderungsbelege für alle Stammdatengruppen mit Ausnahme von Auftragsgruppen geschrieben, da diese häufig geändert und oft sehr umfangreich sein können.

Änderungsbelege für Gruppen im Customizing aktivieren

Dennoch können im Customizing (über die Transaktion SPRO) Änderungsbelege für Gruppen aktiviert werden.

Diese Customizingeinstellung finden Sie in der Transaktion SPRO unter:
  • Controlling->
  • Controlling Allgemein->
  • Produktivstart vorbereiten->
  • Änderungsbelege für Gruppen aktivieren
Hier können Sie für unterschiedliche Setklassen ein Kennzeichen zum Schreiben von Änderungsbelegen setzen.

Für die einzelnen Anwendungen gibt es entsprechend unterschiedlcihe Gruppen, die gepflegt werden können und für die passende Änderungsbelege geschrieben werden. Den einzelnen Anwendungen sind entsprechende Setklassen zugeordnet, die dann jeweils ein Kennzeichen erhalten, dass hier künftig Änderungsbelege erfasst werden sollen.

Im Controlling sind dieses unter anderen folgende Anwendungen und entsprechende Setklassen:
CO-OM:   Kostenstellengruppen (Setklasse 0101)
CO-CEL:  Kostenartengruppen (Setklasse 0102)
CO-OPA: Auftragsgruppen (Setklasse 0103)
EC-PCA: Profit-Center-Gruppen (Setklasse 0106)
EC-PCA: Kontengruppen (Setklasse 0109)

Im Modul PSM-FM können diese unter anderen für folgende Anwendungen aktiviert werden:
IS-PS: Fondsgruppe (Setklasse 0111)
IS-PS: Finanzpositionengruppe (Setklasse 0311)
IS-PS: Finanzstellengruppe (Setklasse 0312)-

Aus den eingangs genannten Gründen (häufige Änderung und umfangreiche Inhalte) ist es nicht sehr sinnvoll Änderungsbelege für Innenauftragsgruppen zu aktivieren, da dieses sowohl die Performance der Gruppenpflege als auch das Datenvolumen innerhalb der Datenbank entsprechend beeinflusst.

Dennoch kann es manchmal sinnvoll sein zumindest festzustellen, wann das letzte Mal eine Stammdatengruppe geändert wurde und durch wen.

Hierzu bietet sich eine Query an, die auch schon im Artikel "Auflösen von Stammdatengruppen nach Einzelwerten - Einzelwerte zu Sets" beschrieben wurde.
 

Tabellen für Stammdatengruppen (Sets)

Für eine Auswertung der letzten Änderung einer Stammdatengruppe (SET) sollen die Tabellen SETHEADER, SETHEADERT und SETLEAF verknüpft werden. Die Beziehung zwischen den einzelnen Gruppen (Untergruppe, Obergruppe) der Tabelle SETNODE wird für eine Auswertung der letzten Änderungen einer Gruppe nicht benötigt.

In der Tabelle SETHEADER werden die einzelnen Knoten innerhalb einer Hierarchie beschrieben. In dieser Tabelle sind auch die Informationen über die anlegende Personen und letzten Änderer zu finden. Die Tabelle SETHEADERT gibt wiederum die Kurzbeschreibung der Sets aus. Damit eignet sich diese Tabelle direkt um eine entsprechende Auswertung auszuführen.

Der Übersicht halber sollte aber auch die Tabelle SETLEAF mit aufgenommen werden.

In der Tabelle SETLEAF befinden sich die einzelnen Werte eines Sets, so dass hier auch inhaltlich geschaut werden kann, was in der Gruppe gepflegt ist.

Je nach auszuwertenden Objekt ist in allen drei Tabellen die Klasse eines Sets mit angegeben. Dieses können unter anderen folgende Klassen sein:
  • 0101 Kostenstellengruppe
  • 0102 Kostenartengruppe
  • 0103 Auftragsgruppe
  • 0106 Profit-Center-Gruppe
  • 0109 Kontengruppe
  • 0111 Fondsgruppe
  • 0311 Finanzpositionengruppe
  • 0312 Finanzstellengruppe
Diese Setklassen sind auch im oben angesprochenen Customizing relevant.

Query für letztmalige Änderung eines Sets anlegen

1.) Infoset definieren
Bei der Anlage eines Infosets über die Transaktion SQ02 wird als Datenquelle unter Tabellen-Join  über Tabelle die Tabelle SETHEADER angegeben. In den weiteren Schritten können die anderen Tabellen über  BEARBEITEN->Tabelle einfügen  ergänzt werden.


Die angesprochenen Tabellen werden dabei wie folgt verknüpft.

Die Angabe der Tabellen erfolgt in der Reihenfolge, wie diese auch bei der Infoset Anlage ergänzt werden. Bei den Verknüpfungen handelt es sich um eine "normale" Verknüpfung. Dieser ist mit <--> angegeben.


Die Bezeichnung der einzelnen Sets werden aus den Tabellen SETHEADER "Setkopf und Setverzeichnis" und SETHEADERT "Kurzbeschreibung zu Sets" entnommen.

SETHEADER-SETCLASS <--> SETHEADERT-SETCLASS
SETHEADER-SETNAME <--> SETHEADERT-SETNAME


Die einzelnen Werte innerhalb eines Sets werden aus der Verknüpfung der Tabelle SETHEADER und SETLEAF "Werte in Sets" entnommen.

SETHEADER-SETCLASS <--> SETLEAF-SETCLASS
SETHEADER-SETNAME <--> SETLEAF-SETNAME

Damit sind die drei Tabellen übereinnander verbunden.

Da im Feld SETCLASS die Klassen eines Sets hinterlegt sind, ist dieses Feld für alle Tabellen relevant. Hintergrund ist, dass ein Gruppenname sowohl als Profit-Center-Gruppe als auch als Kontengruppe vorhanden sein könnte.

2.) Query definieren
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:


Zusatzfelder:
Text: Klasse eines Sets (L) TEXT_SETHEADER_SETCLASS

Tabelle SETHEADER "Setkopf und Setverzeichnis"
Setname (L, S) SETHEADER-SETNAME
Klasse eines Sets (S) SETHEADER-SETCLASS

Tabelle SETHEADERT "Kurzbeschreibung zu Sets
Beschreibung (L) SETHEADERT-DESCRIPT


Zusatzfelder:
Text:Feld OPTION im Aufbau der SELECT-OPTIONS-Tabellen (L)
TEXT_SETLEAF_VALOPTION
Hier sollte entweder "Between: Intervall" oder "Equal: Einzelwert" ausgegeben werden.

Tabelle SETLEAF "Werte in Sets"
Option (L) SETLEAF-VALOPTION
Alternativ bietet sich hier das Tabellenfeld SETLEAF-VALOPTION an wo anhand der Werte BT oder EQ Intervalle und Einzelwerte unterschieden werden.

Tabelle SETLEAF "Werte in Sets"
Von Wert (L) SETLEAF-VALFROM
Bis Wert (L) SETLEAF-VALTO


Tabelle SETHEADER "Setkopf und Setverzeichnis"
Änderer (L)
SETHEADER-UPDUSER
Änderungsdatum (L) SETHEADER-UPDDATE

Damit ist die Query vollständig definiert.

3.) Query ausführen
Beim Start der Query werden nach SETNAME und die Klasse eines Sets gefragt. Hierbei kann über die F4 Auswahlhilfe ein entsprechendes Set ausgewählt werden.

Hierbei werden immer entsprechende Einzelgruppen ausgewertet.
Soll nun zum Beispiel die Innenauftragsgruppe KLR mit ihren Untergruppen KLR-DM, KLR-GEB, KLR-VERWALTUNG etc. ausgewertet werden kann als Setname die Gruppen über die Mehrfachauswahl und als Klasse eines Sets die 0103 (für Auftragsgruppen) angegeben werden.


Neben der Benennung einer bestimmten Gruppe können auch Platzhalter wie * verwendet werden. Erfolgt die Angabe von * im Setnamen werden sämtliche angelegte Gruppen mit gepflegten Einzelwerten angegeben (für das Beispiel der Gruppen KLR würde sich ein Auswertungsmuster in der Form KLR* anbieten). Ein Anwendungsfall hierfür ist zum Beispiel die Auswertung aller Kontengruppen beginnend mit IKR-5* oder IKR-6* zur Auswertung der Aufwands und Ertragskonten.

Für jede Gruppe wird dann das letzte Änderungsdatum sowie Benutzername der ändernden Person ausgegeben.
Daneben ist auch ersichtlich welche Werte in dieser Gruppe eingetragen sind. Hierbei sollte jedoch beachtet werden, dass nur solche Gruppen aufgeführt werden in denen auch tatsächlich Werte (sei es Intervalle oder Einzelwerte) gepflegt sind. In der späteren Liste es dann sicherlich sinnvoll die Daten entweder nach Änderungsdatum oder nach Änderer zu sortieren.


 

Hinweis:

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




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


Samstag, 14. Februar 2015
11:02 Uhr

Query Einzelpostenliste IST über CO Objekte (Auflösen von Innenauftrag, Kostenstelle) sowie Benutzerstammdaten und Erfassungsdatum

Im Rahmen des Artikels "SAP Query: Einzelpostenliste KAMV für Umbuchung in Planversion"  wurde schon einmal eine Auswertung über den CO Vorgang KAMV und Darstellung der Ist-Buchungen ausführlicher beschrieben. Im Rahmend er Jahresabschlussarbeiten kam es dann jedoch zu einer Rückfrage, welche Belege in das alte Jahr noch im Februar in CO gebucht beziehungsweise über die primären Kostenarten auf CO Objekte (Kostenstelle, Innenauftrag) fortgeschrieben worden sind.

Hierzu wäre eine Auswertung anhand des Erfassungsdatum wünschenswert. Grundsätzlich könnten nun Einzelpostenliste in der Komponente Kostenstellenrechnung (zum Beispiel über die Transaktion KSB1 Kostenstellen Einzelposten IST) oder der Innenaufträge (zum Beispiel über die Transaktion KOB1 Aufträge Einzelposten IST) ausgewertet werden. Dieses hat jedoch den Nachteil, dass eine solche Auswertung nur die jeweiligen CO Objekte der entsprechenden Komponente auswertet. Eine Vergleichbare Ausgangslage ist bei den Einzelposten im Plan im Artikel "CO Planeinzelposten Objekt und Partnerobjekt auswerten / Mehrere Felder summieren" beschrieben.

Während für die Plankosten die beiden Tabellen COBK und COEJ ausgwertet werden, kann bei den Istkosten die beiden Tabellen COEP und COBK miteinander verknüpft werden.

Als kleine Ergänzung kann noch die Kostenartbezeichnung aus den Tabellen CSKB und CSKU übernommen werden.

Infoset aufbauen / Tabellen COBK und COEP verknüpfen

Innerhalb eines Infosets werden folgende Tabellen miteinander verknüpft:

COEP - CO-OBjekt: Einzelposten periodenbezogen
CSKB - Kostenarten (Kostenrechnungskreisabhängige Daten)
CSKU - Kostenartentexte
COBK - CO-Objekt: Belegkopf

Optional könnte noch die Tabelle
USR21 - Zuordnung Benutzername Adressschlussel
ADR6 - E-Mail-Adressen (Business Address Services)
verwendet werden um ergänzend zur Benutzerkennung auch Namen und e-Mailanschrift hinzufügen zu können.
Ergänzend könnte man hier auch die
ADR2 - Telefonnummern (Business Address Services)
mit einbinden.

Verknüpfungen:
Folgende Felder werden hierbei miteinander verknüpft.
Hierbei steht <--> für einen normalen Join und >LO< für einen left outer join. Die left outer joins sind erforderlich um auch Datensätze auszugeben, die nicht in allen Tabellen vorhanden sind.

COEP-KOKRS <-> COBK-KOKRS
COEP-BELNR <-> COBK-BELNR

COEP-KSTAR >LO< CSKB-KSTAR

COEP-KSTAR <-> CSKU-KSTAR

Bei der Verknüpfung der Tabelle COEP und CSKB handelt es sich um einen "left outer join". Diese Verknüpfungsart kann durch die rechte Maustaste auf "left outer join" genutzt werden.Hintergrund ist, dass sich die Bezeichnung der Kostenart ändern kann im Laufe ihres Leben. Alternativ kann natürlich auch das Gültig Bis Datum in der Selektion mit den aktuellen Systemdatum oder Enddatum der Auswertungsperiode als Selektionskriterium gesetzt werden.

In der Feldgruppe können die Werte aus den einzelnen Tabellen übernommen werden. Für dieses Beispiel werden in der Feldgruppe 01 alle Felder der Tabelle COEP übernommen. Ergänzend dazu werden als Feldgruppe 2 die Bezeichnung aus der Tabelle CSKU (CSKU-KTEXT) und in der Feldgruppe 3 der Kostenartentyp (CSKB-KATYP) und Datum gültig bis (CSKB-DATBI) übernommen.

Da wir aber auch die Belegkopfdaten haben möchten werden in der Feldgruppe 4 aus der Tabelle COBK folgende Felder übernommen: Belegnummer (COBK-BELNR), Erfassungsdatum des Beleges (COBK-CPUDT), Buchungsdatum (COBK-BUDAT), Benutzername (COBK-USNAM) und Belegkopf-Text (COBK-BLTXT).
 

Benutzername aus Belegkopf mit Benutzerstammdaten verknüpfen

Sollen auch die Benutzerstammdaten wie Mailanschrift und ausführlicher Benutzername ergänzt werden sind folgende Verknüpfungen im Infoset erforderlich. Hier sollte sich aber vorher dahingehend abgestimmt werden, ob diese Daten notwendig sind.

COBK-USNAM <->  USR21-BNAME

USR21-PERSNUMBER <->ADR6-PERSNUMBER
USR21-ADDRNUMER <->ADR6-ADDRNUMBER

erforderlich. Hierdurch müssen die Daten nicht mehr in der SU01D nachgesehen werden.

Die Tabelle USR03 - Adressdaten Benutzer wurde mit Release 4.0a auf die zentrale Adreßverwaltung umgestellt. Die eigentlich obsolete Tabelle ist immer noch im SAP System vorhanden und könnte daher dazu verführen, diese ebenfalls für eine Auswertung bzw. Zuordnung zu den Benutzerdaten zu nutzen.

Schematische Darstellung Tabellenbeziehung COEP, COBK und Benutzerstammdaten

Schematisch dargestellt sind die Tabellen wie folgt miteinander verbunden:
Tabellen Join �ber COEP, COBK sowie Benutzerstammdaten aus der SU01D




ACHTUNG:
In der Schemazeichnung ist noch der LO leider bei CSKU und nicht CSKB eingezeichnet.



Hierdurch können in der Query dann auch die Benutzerdaten (Anschrift) übernommen werden.

Hierzu kann eine 5. Feldgruppe "Benutzerdaten" hinzugefügt werden.
In dieser würden dann folgende Tabellenfelder eingefügt:
Benutzername im Benutzerstamm (USR21-BNAME) und E-Mail-Adresse (ADR6-SMTP_ADDR) genauso wie die Telefnnummer (ADR2-TELNR_CALL).


 

Query definieren, lokale Felder anlegen um aus Objektnummer Kostenstelle und Innenauftrag auszulesen

Bevor wir die Grundliste für die Query aufbauen sollen zur leichteren Darstellung der Belege aus der Objektnummer der Tabelle COEP Kostenstelle und Innenauftrag getrennt ausgewertet werden.

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 CO-Objekt: Einzelposten periodenbezogen (Tabelle COEP)
Objektnummer -> OBJNR    (entspricht den Tabellenfeld (COEP-OBJNR).

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

Die folgenden Felder legen wir ebenfalls innerhalb der Sachgruppe "
CO-Objekt: Einzelposten periodenbezogen" an.

Das Feld OBJNR hat insgesamt 22 Zeichen. Dabei werden Innenaufträge mittels OR*und die Innenauftragsnummer mit führenden 0  und Kostenstellen als KS gefolgt vom Kostenrechnungskreis und ebenfalsl der Kostenstenstellennumemr mit führenden 0 ausgegeben.

In unseren Fall können Kostenstellen und Innenaufträge bis zu 8 Zeichen lang sein.

Entsprechend werten wir einen Teilstring des Feldes OBJNR aus. Diese Methode ist auch im Artikel "Query Stammdatenvergleich Profit-Center und Auslesen von Textbestandteilen (Teilstring aus Variable)" ausführlicher beschrieben.

Zur Unterscheidung von Kostenstellen und Innenaufträgen legen wir zwei Hilfsfelder an.

1. Feld KTR zur Identifikation der CO Objektnummer (Kostenstelle/Innenauftrag Schlüssel)


Kurzbezeichnung: KTR
Feldbezeichnung: KTR
Überschrift: KTR
Eigenschaften wie: gleiche Eigenschaften wie Feld  OBJNR
Berechnungsvorschrift: OBJNR[7:16]

Hierbei werden aus den Feld OBJNR die Zeichen mit der Position 7 bis Position 16 (entspricht der maximalen Zeichenlänge des Feldes) ausgegeben.

Damit sind die Kostenstelle bzw. der Innnenauftrag mit führender 0 aus der Tabelle ausgelesen ohne die Objektbezeichnung KS oder OR mit aufzuführen.

2. Feld Um welches CO Objekt handelt es sich?

Kurzbezeichnung: KTRA
Feldbezeichnung: KTRA
Überschrift: KTRA
Eigenschaften wie: Textfeld Anzahl Zeichen 1
Berechnungsvorschrift: OBJNR[1:1]

Handelt es sich beim Objekt nun um eine Kostenstelle dann würde hier K und bei Innnaufträgen O (abgeschnitten aus aus OR) ausgegeben.


Diese beiden Felder werden genutzt um Innenaufträge und Kostenstellen auszugeben.

3. Feld Innenauftrag

Kurzbezeichnung: KTR_IA
Feldbezeichnung: KTR_IA
Überschrift: Innenauftrag
Eigenschaften wie: Textfeld Anzahl Zeichen 10
Berechnungsvorschrift:

Statt einer einfachen Berechnungsvorschrift wechseln wir nun über die Schaltfläche "komplexe Berechnung" um verschiedene Bedingungen für die Berechnung dieses Feldes anzugeben.

Bedingung: 
KTRA = 'O'
Es handelt sich also um einen Innenauftrag
Formel: KTR * 1
Durch die Multiplikation mit 1 werden (auch bei Textfeldern) die führenden Nullen entfernt.
Sonst ''
Sofern es sich nicht um einen Innenauftrag handelt bleibt das Feld leer.

3. Feld Kostenstelle

Kurzbezeichnung: KTR_KS
Feldbezeichnung: KTR_KS
Überschrift: Kostenstelle
Eigenschaften wie: Textfeld Anzahl Zeichen 10
Berechnungsvorschrift:

Statt einer einfachen Berechnungsvorschrift wechseln wir nun über die Schaltfläche "komplexe Berechnung" um verschiedene Bedingungen für die Berechnung dieses Feldes anzugeben.

Bedingung: 
KTRA = 'K'
Es handelt sich also um eine Kostenstelle
Formel: KTR * 1
Durch die Multiplikation mit 1 werden (auch bei Textfeldern) die führenden Nullen entfernt.
Sonst ''
Sofern es sich nicht um einen Innenauftrag handelt bleibt das Feld leer.


 Damit ist die Datengrundlage fertig und wir können die Grundliste der Query anlegen.

Grundliste Query über CO Einzelposten IST anlegen

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:


CO-OBjekt: Einzelposten periodenbezogen (COEP)
Kostenrechnungskreis COEP-KOKRS (S)
Geschäftjahr  COEP-GJAHR  (S, L)
Vorgang CO  COEP-VRGNG (S, L)
Belegnummer COEP-BELNR (L)
Kostenart COEP-KSTAR (S, L)

Kostenartentexte (CSKU)
Allgemeine Bezeichnung CSKU-KTEXT (L)

CO-OBjekt: Einzelposten periodenbezogen (COEP)
Wert gesamt in Kostenrechnungskreiswährung COEP-WKGBTR (L)
Als Währungsfeldppsition wird hier kein Währungsfeld aktiviert

Lokale Zusatzfelder
Bei den folgenden beiden Zusatzfeldern wird die Option Feld nur ausgeben wenn <> 0 aktiviert.
Innenauftrag KTR-IA  (L)
Kostenstelle KTR-KS (L)

CO-Objekt: Einzelposten periodenbezogen (COEP)
Objektnummer COEP-OBJNR (S, L)
Partnerobjekt COEP-PAROB (S, L)

Beide Felder sind als Selektionskriterium definiert. Beim Start der Query ist daher darauf zu achten, dass wenn man nur Kostenstelle oder nur Innenaufträge auswerten möchte diese mit OR* bzw. OR*Nummer oder KS* bzw. KS*Nummer ausgwertet werden. Andernfalls werden in der Query alle CO Objekte ausgegeben.

Be-/Entlastungskennzeichen  COEP-BEKNZ (S, L)
Dieses entspricht dem S / H Kennzeichen.

CO-Objekt: Belegkopf (COBK)
Erfassungsdatum COBK-CPUDT  (S, L)
Buchungsdatum COBK-BUDAT (S,L)

CO-OBjekt: Einzelposten periodenbezogen (COEP)
Bezeichnung Belegposition /Segmenttext COEP-SGTXT (L)

CO-Objekt: Belegkopf (COBK)
Belegkopftext COBK-BLTXT (L)

Damit können die Istbuchungen innerhalb CO über diese Query problemlos ausgewertet werden. Lediglich die Selektion einzelner CO-Objekte ist durch die Objektnummer etwas problematisch, auch wenn die Darstellung der Liste diese dann wieder aufschlüsselt. Dafür kann hierdurch aber problemlos erhoben werden, welche Daten noch ins alte Jahr gebucht worden sind.

Sollen auch die Daten der Erfasser (Buchhalter) mit ausgegeben werden, bspw. um schnell eine Rückfrage stellen zu können, können noch folgende Daten mit ausgegeben werden.

CO-Objekt: Belegkopf (COBK)
Benutzername COBK-USNAM (L)

Sofern die Feldgruppe 5 Benutzerdaten im Infoset definiert worden ist können nun noch folgende Felder mit ausgegeben werden:

Zusatzfeld:
Text:Benutzername im Benutzerstamm  TEXT_USR21_BNAME  (L)

E-Mail-Adressen (Business Address Services) (ADR6)
E-Mail-Adresse ADR6-SMTP_ADDR  (L)
Telefonnummern (Business Address Services) (ADR2)
Vollständige Nummer: Vorwahl+Anschluß+Durchwahl ADR2-TELNR_CALL (L)

Durch die Ausgabe der Benutzerstammdaten Name und Mail kann auch direkt Kontakt mit dieser Person aufgenommen werden. Für eine Einzelpostenliste reicht aber vielleicht auch einfach nur der ausführliche Name aus der USR21, so dass statt Benutzername  USER593 dann tatsächlich Andreas Unkelbach in der Liste erscheint. Dieses ist besonders dann sinnvoll, wenn die Benutzernamen durchnummeriert sind und anhand der Benutzerkennung nicht direkt die eigentliche Person identifiziert werden kann. Der Benutzername selbst ist ohnehin im Beleg enthalten.

Kostenrechnungsbelegansicht (Transaktion KSB5) zuordnen

Über die Berichtsschnittstelle kann dann bspw. die Transaktion KSB5 für "Belege Istkosten anzeigen" genutzt werden, so dass hier direkt der Kostenrechnungsbeleg aufgerufen werden kann.


Hierzu rufen wir wiederum über die SQ01 die Query für eine Änderung auf.
Über SPRINGEN->BERICHTSZUORDNUNG können Empfängerberichte definiert werden.

Über das „+“ (Zeile einfügen) können weitere Query eingefügt werden. Alternativ kann hier auch ein anderer Berichtstyp ausgewählt werden. Über "TR Transaktion" sollte hier die Anzeige des  Kostenrechnungsbelegs (KSB5) hinterlegt werden.

Und was ist mit Tee pardon FI?

Neben den CO Belegen besteht dank Query auch die Möglichkeit innerhalb FI eine entsprechende Einzelpostenliste zu erstellen. Diese ist im Artikel "Query FI Einzelposten als Belegjournal - Belegsegment (BSEG) und Belegkopf (BKPF) verknüpfen" beschrieben und dürfte die Kollegen aus der Finanzbuchhaltung noch mehr ansprechen ;-). Dieses Auswertung macht dann zum Beispiel Sinn, wenn bestimmte Sachverhalte nicht direkt in die Kostenstenleistungsrechnung (KLR) fortgeschrieben werden. Problematisch kann hier zum Beispiel die fehlende Fortschreibung von FI nach CO Kostenstelle oder Innenaufträge für bestimmte Sachkonten (Beispiel Reisekostenvorschuss) sein. Dieses Problem ist auch schon im Artikel "Einzelposten FI Hauptbuch (Auswertung Buchungen Partnergesellschaft)" beschrieben. So können werden manche Erfolgskonten aus FI nur nach PSM aber nicht nach CO fortgeschrieben. Als Kontierungsobjekte werden hierbei jedoch ebenfalls Innenaufträge mitgegeben denen teilweise als Fond im PSM-FM nicht ein vergleichbares Objekt zugeordnet ist (identischer Fond wie Innenauftrag) sondern ein Sammler (im Beispiel ein Fond mit der Bezeichnung LANDESMITTEL). Ein Beispiel können hier zum Beispiel "Vorschüsse Reisekosten" sein, die zwar als Aufwand gebucht sind, aber nicht als Kosten in der KLR betrachtet werden. Entsprechend passender ist hier die Auswertung über die oben beschriebene Einzelpostenliste in FI.


 

Hinweis:

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




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


Freitag, 6. Februar 2015
17:43 Uhr

Änderungsbelege zu Systemstatus (JEST) bei Innenaufträgen per Query auswerten

Schon im Artikel "SAP Query: Systemstatus CO Innenauftrag" wurde eine Auswertung zu den verschiedenen Systemstatuszuständen eines Innenauftrag beschrieben. Hierzu wurde die Tabelle JEST über die Objektnummer mit den Auftragsstammdaten aus der Tabelle AUFK verknüpft.  Die Verknüpfung über die Objektnummer ist erforderlich, da in der Tabelle JEST jeder Status eines SAP Objektes festgehalten wird und die einzelne Objekte (so auch das CO Kontierungsobjekt Innenauftrag mit OR*Innenauftragsnummer) in dieser Tabelle hinterlegt sind.

Grundsätzlich beschreibt der Systemstatus den Lebenslauf eines Innenauftrags. Sobald hier der Status ABGS Abgeschlossen gesetzt wurde, könnenweder Buchungen noch sonstige Änderungen vorgenommen werden. Teilweise kann aber auch unabhängig vom Lebenszyklusstatus auch eine Sperre im Auftragsstamm durch BEARBEITEN->SPERRE->SETZEN innerhalb der Stammdatenpflege (KO02) gesetzt werden. Dieses hat gegenüber den Status ABGS den Vorteil, dass Projekte durch entsperren wieder bebucht werden können. Ein Beispiel wäre ein Projekt, dass zwar über einen längeren Zeitraum läuft, dessen Fortführung aber durch eine Verlängerung des Projektgebers abhängig ist.

Exkurs Maschinelle Sammelbearbeitung Innenaufträge

Sollen mehrere Innenaufräge gesperrt werden (bzw. der Status geändert werden) bietet sich die Transaktion KOK4 an. Hier kann anhand einer Selektionsvariante für eine Vielzahl von Innenaufträgen über die Funktionsauswahl Aufträge gesperrt, entsperrt oder auch ein anderer Status gesetzt werden.


Problematisch ist diese Vorgehensweise jedoch, wenn die Sperre genutzt wird um keine weitere Buchungen mehr bei abgelaufenen Projekten zu ermöglichen. Teilweise kann es hier erforderlich sein, dass die Sperre (bspw. bei einen AfA-Lauf) in der KO02 zurück genommen wird oder für eine Plankopie über die Massenpflege KOK4 entfernt wird (siehe hierzu auch der Artikel "Plankopie Innenaufträge").

Innerhalb der Stammdatenansicht (KO03 oder KO02) kann über UMFELD->ÄNDERUNGSBELEGE->ZUM STATUS eine Änderungsbeleliste zum jeweiligen Status für den angezeigten Innenauftrag angezeigt werden. Hier wäre daher eine Liste mit Änderungen zu jeweiligen Status für eine Vielfalt von Innenaufträgen hilfreich.

Ausgangslage: Tabelle mit Änderungsbelegen zum Systemstatus

Diese Änderungsbelege sind in der Tabelle JCDS "Änderungsbelege für System-/Anwenderstatus (Tabelle JEST)" zu finden. Nun soll eine Query erstellt werden aus der eine Liste aller Sperren mit Änderungszeitpunkt und  Änderungstransaktion erstellt werden.

1. Infoset anlegen (SQ02)

Für die SAP Query müssen, wie auch im Artikel "SAP Query: Systemstatus CO Innenauftrag" beschrieben mehrere Tabellen miteinander verknüpft werden.

AUFK - Auftragsstammdaten
JEST - Einzelstatus pro Objekt
TJ02 - Systemstatus

Ergänzend dazu wird noch folgende Tabelle für die Änderungsbelege benötigt.

JCDS -
Änderungsbelege für System-/Anwenderstatus (Tabelle JEST)

Folgende Felder werden hierbei miteinander verknüpft.

Verknüpfungen
Hierbei steht <--> für einen normalen Join und >LO< für einen left outer join.

AUFK-OBJNR <-> JEST-OBJNR
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.

In der Tabelle JEST ist nun der vorhandene Status als Nummernfeld für jedes Objekt hinterlegt. In der Tabelle TJ02 erhalten wir allerdings auch die Bezeichnung dieses Status, so dass dieses Feld gerade bei der späteren Selektion sehr hilfreich ist.

Entsprechend legen wir als weitere Verknüpfung folgende an:
JEST-STAT <-> TJ02-ISTAT

Somit kann nachher in der Query auch über den Text bzw. die Beschreibung des Status verwendet werden.


Um nun eine Verknüpfung zu den Änderungsbelegen herzustellen wird noch die Tabelle JEST mit der Tabelle JCDS über folgende Felder miteinander verknüpft.

JEST-OBJNR <-> JCDS-OBJNR
JEST-STAT <-> JCDS-STAT


Schematisch sollte das Infoset nun wie folgt aussehen:
Darstellung Infoset aus AUFK, JEST (mit TJ02) und JCDS
 

2. Query anlegen (SQ01)

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:


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

Einzelstatus pro Objekt JEST
Einzelstatus eines Objekts JEST-STAT (L)

Systemstatus TJ02
Systemstatus TJ02-ISTAT (S)
Durch Verwendung des Systemstatus aus der Tabelle TJ02 wird in der F4 Auswahlhilfe der Query dann auch die Beschreibung ausgegeben.

Zusatzfeld bzw. Textfeld
Zusatzfeld:
"Text:Systemstatus" TEXT_TJ02_ISTAT (L)


Änderungsbelege für System-/Anwenderstatus (Tabelle JEST) JCDS
Datum (der Änderung) JCDS-UDATE (S, L)
Uhrzeit (der Änderung) JCDS-UTIME (L)
Änderungsnummer JCDS-CHGNR (L)
Benutzer JCDS-USNAM  (L)
Transaktion die zur Änderung führte (Tcode) JCDS-CDTCODE (L)

Zusatzfeld bzw. Textfeld
Textfelder:
"
Text:Transaktion, in der eine Änderung durchgeführt wurde" TEXT_JCDS_CDTCODE  (L)
"Text:Kennzeichen: Status inaktiv"  TEXT_JCDS_INACT  (L)
 

Sortieren und Zwischensummen bilden

Da hier möglicherweise viele Änderungen am Status eines Objekes (im beschriebenen Fallbeispiel am Innenauftrag) auftreten werden ist es sinnvoll hier eine Sortierung über das Feld Innenauftrag/Auftrag vorzunehmen. Hierzu sollte das Feld Auftrags in die Sortierfelder gezogen werden. Hierzu kann in der Grundliste (Layoutdesign) der Beispieldatensatz (weißer Hintergrund)in die Sortierfleder gerzogen werden. Die Sortierfelder können über WERKZEUGE->SORTIERF. EIN/AUS ein bzw. ausgeblendet werden.

Durch die Sortierung nach Zwischensummen bietet es sich, bei der Selektion nach SPERR Status an, über ein kundeneigenes Zusatzfeld angelegt werden.


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.

Ü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 bekommt  nun folgendes Feld  eine Kurzbezeichnung (in der Beschreibung ist die Bezeichnung, gefolgt von der angelegten Kurzbezeichnung und des dahinter technisch liegenden Tabellenfeldes angegeben):


Kennzeichen: Status inaktiv - INAKT (JCDS-INACT)

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. In unseren Fall also ebenfalls in der Feldgruppe der Tabelle JCDS bzw. der Bezeichnung der Feldgruppe "
Änderungsbelege".

Hierbei wird das Feld CHANGE mit folgenden Eigenschaften angelegt:

Kurzbezeichnung:
CHANGE
Feldbezeichnung: CHANGE
Überschrift: CHANGE
Eigenschaften wie: Rechenfeld   Anzahl der Ziffern 31 (um einen Feldüberlauf Meldungsnummer. 0K051  zu vermeiden)
Berechnungsvorschrift:
Hier wird eine komplexe Berechnung mit folgenden Bedingungen hinterlegt:
  • Bedingung: INAKT = ''
    Formel: 1
  • Sonst
    -1
Nun wird das Feld CHANGE als Summationsfeld in der Grundliste mit ausgegeben.

Berichtszuordnung


Sinnvollerweise sollte in der Query auch eine Absprungfunktion in die Funktion Innenauftrag anzeigen (KO03) bzw. Innenauftrag ändern (KO02) hinzugefügt werden.

Hierzu rufen wir wiederum über die SQ01 die Query für eine Änderung auf.
Über SPRINGEN->BERICHTSZUORDNUNG können Empfängerberichte definiert werden.

Über das „+“ (Zeile einfügen) können weitere Query eingefügt werden. Alternativ kann hier auch ein anderer Berichtstyp ausgewählt werden. Über "TR Transaktion" können hier auch die die Transaktionen KO03 und KO02  hinterlegt werden.


 

Handhabung der Query Änderungsbelege zum Auftragsstatus anzeigen

Nun werden die Daten entsprechend sortiert, so dass hier eine Sortierung erfolgt und direkt ersichtlich ist, welche Änderungen jeweils aktuell vorgenommen wurde. Sofern keine Selektion vorgenommen wurde werden alle Änderungen in ihrer zeitlichen Reihenfolge (über die Änderungsnummer bzw. auch Datum und Uhrzeit) unteirnander aufgeführt. Der aktuelle Status ist dann am Ende der Liste ersichtlich. Dabei ist darauf zu achten, dass wenn ein Status in der letzten Spalte (Kennzeichen Status: inaktiv) auf aktiv gesetzt ist, hier (im Beispiel für den Status I0043 Gesperrt) dieser Innenauftrag gesperrt ist. Eine Entsperrung ist als Gegenstück durch den Status inaktiv ersichtlich.

Daneben kann über diese Query aber auch eine Auswertung über den Lebenszyklus (inklusive Zeitpunkten) des Innenauftrages (von EROF (eröffnet), FREI (freigegeben), TABG (technisch abgeschlossen) bis ABGS (abgeschlossen)) dargestellt werden.

Beim Aufruf der Query kann nun über ein Nummernintervall die Änderungen an den einzelnen Aufträgen ausgewertet werden oder alternativ nur Änderungen am Sperrkenzeichen (Systemstatus I0043 ) ausgewertet werden. Ferner ist es sinnvoll über das "Erstellungsdatum des Änderun" (JCDS-UPDATE) eine Einschränkung der Änderungsbelege auf das Vorjahr bis zum 31.12.9999 (bzw. laufendes Jahres) als Variante zur Query zu hinterlegen. Diese kann auch als Standardvariante zur Query im Feld Standard-Variante im Einstiegsbild der Querypflege in der SQ01 hinterlegt werden. Sehr beliebt ist bei mir in diesen Fall ja die Variante ALLGEMEIN.

Sofern das Feld CHANGE genutzt wird, ist bei der Auswertung eines Status bspw. I043 ein Handlungsbedarf gegeben wenn die Summe je Innenauftrag 0 ist, da hier eine Sperre gesetzt und wieder aufgehoben aber nicht erneut gesperrt wurde. Sollte jedoch über das Änerungsdatum eine Abfrage erfolgen kann ein Handlungsbedarf bei 1 gegeben sein :-) .
 

Hinweis:

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




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


Freitag, 19. Dezember 2014
15:00 Uhr

Weitere Zusatzfelder im Infoset mit ABAP Coding zur Verwendung in SAP Query über die Tabellen AUFK und FMFINCODE

Bisher wurden schon einige Stammdaten der CO Innenaufträge und der PSM-FM Fonds miteinander in Verbindung gesetzt. Bei der Definition der Variablen innerhalb des ABAP Coding ist dabei darauf zu achten, dass diese innerhalb der Zusatzfelder auch entsprechend bei den einzelnen Variablen nicht mehrfach ausgewertet werden. Daher habe ich im Folgenden noch einmal die einzelnen schon im Artikel "SAP Query ABAP Coding im Zusatzfeld für Verknüpfung Innenauftrag und Fond bzw. Finanzierungszweck" erwähnten Zusatzfelder an dieser Stelle noch einmal aufgeführt und im Coding ein wenig angepasst.

Das grundsätzliche Infoset zur Auswertung von Innenaufträgen ist in folgender Darstellung bereits im entsprechenden Artikel erläutert.

Infoset Verknüpfung AUFK und CSKS bzw. CEPC zur Darstellung Innenauftrag, verantwortliche Kostenstelle und Profit-Center
Neben den schon erwähnten Feld Finanzierungszweck aus den Stammdaten des Fonds sind auch weitere Felder noch über ein Zusatzfeld und dahinter liegenden Coding zu ermitteln.

Alle hier aufgeführten Coding befinden sich im Codeabschnitt 1. Für die Merkmale der Klassifizierung ist der Codeabschnitt 3 verwendet worden und wird im Artikel "SAP Query - Auswertung Merkmale der Klassifizierung am Beispiel Fonds in PSM-FM".

In den Folgenden Beispielen wird davon ausgegangen dass sich die PSM-FM Stammdaten alle im Finanzkreis FIK befinden.

Die einzelnen Zusatzfelder werden als erstes mit ihren Verweis auf die Eigenschaften des jeweilige Tabellenfeld definiert. Danach folgt eingerückt das zugehörige ABAP-Coding zum Zusatzfeld.

Zusatzfeld: Ist ein Fond zum Innennauftrag vorhanden?

Es wird das Zusatzfeld FONDS angelegt um in der Tabelle FMFINCODE nach einen mit identischer Nummer zum Innenauftrag angelegten Fond im Modul PSM-FM zu suchen.

FONDS like FMFINCODE-FINCODE.
Das entsprechende Coding zum Zusatzfeld sieht wie folgt aus:

DATA: l_fincode TYPE FMFINCODE-FINCODE.
DATA: l_aufnr TYPE aufk-aufnr.
l_aufnr = aufk-aufnr.
SHIFT l_aufnr BY 4 PLACES LEFT.
l_fincode = l_aufnr.
SELECT SINGLE FINCODE FROM FMFINCODE INTO l_fincode
       WHERE fikrs = 'FIK'
         AND FINCODE = l_fincode.
IF sy-subrc <> 0.
  CLEAR fonds.
ELSE.
  fonds = l_fincode.
ENDIF.

Zusatzfeld: Bezeichnung des Fond

Sofern ein passender Fond gefunden wurde soll auch die Bezeichnung des Fond mit ausgewertet werden. Hierzu soll das Feld BEZEICH aus der Tabelle FMFINT ausgewertet werden.

BEZEICHNUNG  Like FMFINT-BEZEICH
Das entsprechende Coding sieht dabei wie folgt aus:

DATA: l_bezeich TYPE fmfint-bezeich.
DATA: l_fincodebezeichnung Type FMFINCODE-FINCODE.
DATA: l_aufnrbezeichnung TYPE aufk-aufnr.
l_aufnrbezeichnung = aufk-aufnr.
SHIFT l_aufnrbezeichnung BY 4 PLACES LEFT.
l_fincodebezeichnung = l_aufnrbezeichnung.
SELECT SINGLE bezeich FROM fmfint INTO l_bezeich
       WHERE fikrs = 'FIK'
         AND fincode = l_fincodebezeichnung.
IF sy-subrc <> 0.
  CLEAR bezeichnung.
ELSE.
  bezeichnung = l_bezeich.
ENDIF.

Zusatzfeld: Gültigkeit des Fond

Neben Arbeitsbeginn und Arbeitsende soll auch die Gültigkeit des Fonds ausgewertet werden.
Hierzu sollen die beiden Felder DATAB und DATBIS der Tabelle FMFINCODE ausgewertet werden. Entsprechend sind hier zwei Zusatzfelder angelegt worden.

DATUM_AB  Like FMFINCODE-datab
Das entsprechende Coding lautet:

DATA: l_datab TYPE FMFINCODE-datab.

DATA: l_fincodedatab Type FMFINCODE-FINCODE.
DATA: l_aufnrdatab TYPE aufk-aufnr.
l_aufnrdatab = aufk-aufnr.
SHIFT l_aufnrdatab BY 4 PLACES LEFT.
l_fincodedatab = l_aufnrdatab.
SELECT SINGLE datab FROM FMFINCODE INTO l_datab
       WHERE fikrs = 'FIK'
         AND FINCODE = l_fincodedatab.
IF sy-subrc <> 0.
  CLEAR datum_ab.
ELSE.
  datum_ab = l_datab.
ENDIF.

DATUM_BIS Like FMFINCODE-datbis
Das entsprechende Coding lautet:

DATA: l_datbis TYPE FMFINCODE-datbis.
DATA: l_fincodedatbis Type FMFINCODE-FINCODE.
DATA: l_aufnrdatbis TYPE aufk-aufnr.
l_aufnrdatbis = aufk-aufnr.
SHIFT l_aufnrdatbis BY 4 PLACES LEFT.
l_fincodedatbis = l_aufnrdatbis.
SELECT SINGLE datbis FROM FMFINCODE INTO l_datbis
       WHERE fikrs = 'FIK'
         AND FINCODE = l_fincodedatbis.
IF sy-subrc <> 0.
  CLEAR datum_bis.
ELSE.
  datum_bis = l_datbis.
ENDIF.

Zusatzfeld: Fondsart

Innerhalb des Haushaltsmanagement können einzelne Fonds einer Fondart zugewiesen werden, die dann für Reportingzwecke verwendet werden können.
Hierzu soll das Tabellenfeld TYPE in der Tabelle FMFINCODE ausgewertet werden.

FONDSART   Like FMFINCODE-TYPE
Das Coding lautet dabei wie folgt:

DATA: l_type TYPE FMFINCODE-TYPE.
DATA: l_fincodefondsart Type FMFINCODE-FINCODE.
DATA: l_aufnrfondsart TYPE aufk-aufnr.
l_aufnrfondsart = aufk-aufnr.
SHIFT l_aufnrfondsart BY 4 PLACES LEFT.
l_fincodefondsart = l_aufnrfondsart.
SELECT SINGLE type FROM FMFINCODE INTO l_type
       WHERE fikrs = 'FIK'
         AND FINCODE = l_fincodefondsart.
IF sy-subrc <> 0.
  CLEAR fondsart.
ELSE.
  fondsart = l_type.
ENDIF.

Zusatzfeld: Budgetprofil

Über das Budegtprofil lassen sich verschiedene Budgetsteuerungen (bspw. Unterscheidung Jahresbudget, Gesamtbudget oder auch Zeithorizonte) festlegen. Die Customizing-Einstellungen sind im Artikel "Budgetprofil klassische Budgetierung" und die Budgetierung an sich im Artikel "SAP PSM-FM klassische Budgetierung mit unterschiedlichen Budgetversionen" näher vorgestellt. Innerhalb des Infosets soll jedoch nur das zugeordnete Budgetprofil zum jeweiligen Fond mit ausgegeben werden. Dieses ist im Tabellenfeld PROFIL der Tabelle FMFINCODE gespeichert.
Entsprechend wurde folgendes Zusatzfeld angelegt:

BUDGETPROFIL   Like FMFINCODE-PROFIL
Das dahinter liegende Coding hat dabei folgenden Aufbau:

DATA: l_profil TYPE FMFINCODE-PROFIL.
DATA: l_fincodebudgetprofil TYPE FMFINCODE-FINCODE.
DATA: l_aufnrbudgetprofil TYPE aufk-aufnr.
l_aufnrbudgetprofil = aufk-aufnr.
SHIFT l_aufnrbudgetprofil BY 4 PLACES LEFT.
l_fincodebudgetprofil = l_aufnrbudgetprofil.
SELECT SINGLE profil FROM FMFINCODE INTO l_profil
       WHERE fikrs = 'FIK'
         AND FINCODE = l_fincodebudgetprofil.
IF sy-subrc <> 0.
  CLEAR budgetprofil.
ELSE.
  budgetprofil = l_profil.
ENDIF.

Soweit wären hier alle relevanten Stammdaten der Transaktion FM5S (Fond anzeigen) aufgeführt. Eine Erweiterung der Stammdaten um einzelne Merkmale der Klassifizierung ist im Artikel "SAP Query - Auswertung Merkmale der Klassifizierung am Beispiel Fonds in PSM-FM" ausführlich beschrieben. Hier sind die einzelnen Zusatzfelder (für die Merkmale der Klassifizierung innerhalb des Abschnit 3 zu hinterlegen, da diese sich auf das Zusatzfeld OBJNFOND im Abschnitt 2 bezieht.

OBJNFOND   like  AUSP-OBJEK

CONCATENATE  'FIK ' FONDS INTO OBJNFOND RESPECTING BLANKS.

Die einzelnen Merkmale aus der Tabelle AUSP müssen dann jedoch noch über die Tabelle CABN anhand des Felds ATINN ausgewertet werden. Dieses ist aber im entsprechenden Artikel wesentlich ausführlivher erläutert.

Hinweis: Query Stammdaten CO Innenauftrag PSM-FM Fond

Dieser Artikel ist Teil einer Serie um Stammdaten von CO Innenaufträgen und PSM-FM Fonds miteinander zu verknüpfen.
  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"
Insbesondere was die Auswertung von PSM Stammdaten anbelangt (so eben auch Klasifizierung oder Finanzierungszweck) dürfte der Artikel "SAP Query innerhalb des SAP Moduls PSM FM beziehungsweise Haushaltsmanagement" noch eine Menge Potential beschreiben und teilweise auch eine etwas einfachere Variante anbieten. Ein tatsächlich umfangreiches Beispiel ist in der Artikelserie unter "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.


 

Hinweis:

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




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


Freitag, 12. Dezember 2014
14:21 Uhr

SAP Query - Auswertung Merkmale der Klassifizierung am Beispiel Fonds in PSM-FM

Neben den einzelnen Stammdaten besteht auch die Möglichkeit weitere Informationen zu einen Objekt im Wege der Klassifizierung anzulegen um hier über die reinen Stammdaten hinaus noch weitere Informationen zu einzelnen Kontierungsobjekten zu hinterlegen.
Problematisch ist nur, dass die Merkmale der Klassifizierung nicht in einer Stammdatenliste direkt mit aufgeführt werden können. Entsprechend naheliegend ist es diese ebenfalls in einer Query neben verschiedenen anderen Stammdaten auszuwerten.

Exkurs: Klassensystem

Das Klassensystem ermöglicht es innerhalb einer Klasse verschiedene Merkmale zusammenzufassen und diese dann an Stammdaten als weitere Felder zu pflegen.

Innerhalb PSM-FM ist dieses bspw. für die Klassen 042 Fonds, 041 Finanzstelle oder auch 043 Finanzpositionen möglich. Sobald eine Klasse entsprechend angelegt ist, kann die Klassifizierung am jeweiligen Objekt gepflegt werden.

Die Klassifizierung kann auch im Controlling beispielsweise für die Klassenart 013 Controlling: Aufträge gepflegt werden. Hierzu ist es jedoch erforderlich, dass in der Auftragsart (Transaktion KOT2_OPA) bei den Steuerkennzeichen die Klassifizierung aktiviert wurde.

CT04 Merkmalverwaltung

Über die Merkmalverwaltung (Transaktion CT04) können einzelne Merkmale definiert werden. Diese können entweder einwertig oder mehrwertig sein und in den Basisdaten auch als erforderlich markiert werden. Im Reiter Werte können auch schon entsprechende Vorschlagswerte festgelegt werden. Hierbei ist zu beachten, dass die Spalte Merkmalswert dann auch der eigentliche Wert des Merkmals enthält und die Bezeichnung eine passende Beschreibung dazu enthält. Andernfalls handelt es sich beim Merkmal um ein Freitextfeld. Innerhalb der Registerkarte Einschränkungen kann dass Merkmal auf eine bestimmte Klassenart (bspw. 042 Fonds) eingeschränkt werden und nur in dieser Klasse verwendet werden.

CL02 Klassenverwaltung

Über die Klassenverwaltung (Transaktion CL02) können mehrere Merkmale zu einer Klasse zusammengefasst werden und einer bestimmten Klassenart bspw. 042 für Fonds oder 013 für Innnenaufträge zugeordnet werden.

Merkmale pflegen

Über die Schaltfläche Klassifizierung in der Stammdatenpflege (egal ob nun KO02 für Innenaufträge oder FM5U für Fonds) können die einzelnen Merkmale gepflegt werden.

Suche über Klassifizierung

Über eine Stammdatenliste (bspw. Transaktion S_KI4_38000039 für die alphabetische Lsite Fonds) kann über den Knopf Klassifizierung über die entsprechende Klasse und der Klassenart (es besteht somit auch die Möglichkeit für eine Klassenart bspw. Fonds mehrere Klassen anzulegen) entsprechende Objekte in Klassen zu suchen. Im Ergebnis erhält man eine Liste die dann alle entsprechenden übereinstimmende Objekte, die dann als Selektion in die Stammdatenliste übernommen werden können. Alternativ können Sie auch über die Transaktion CL30N eine entsprechende Suche starten.

Alle Funktionen zur Klassifizierung sind innerhalb des SAP Menü unter Anwendungsübergreifende Komponenten > Klassensystem zu finden.

Technisch betrachtet sind die einzelnen Merkmalswerte in der Tabelle AUSP  "Ausprägungswerte der Sachmerkmale" hinterlegt. Sofern Sie die Zuordnung der einzelnen Merkmale zu den einzelnen Klassenarten auswerten wollen, können Sie hier die Tabelle TCLA "Klassenarten" über die Tabelle INOB "Zuordnung einer internen Nummer zu einem bel. Objekt" über das Feld "KLART" miteinander verknüpfen.

Ausgangslage:
In unseren Fall möchten wir jedoch die bestehende Stammdatenliste aus Innenaufträge und entsprechende Fonds (wie im Artikel "SAP Query ABAP Coding im Zusatzfeld für Verknüpfung Innenauftrag und Fond bzw. Finanzierungszweck" um bestimmte Merkmale aus der Klassifzierung erweitern.

Zur Erinnerung nocheinmal das Infoset aus den vorherigen Artikel
Darstellung Infoset über die Tabellen AUFK, FMFINCODE sowie Zusatztabellen



Bisher haben wir in dieser Query den Finanzierungszweck aus PSM, die Laufzeit aus CO sowie das Sperrkenzeichen und die aus den Kostenstellen abgeleitete Lehreinheit gelistet.

Innerhalb der Tabelle AUSP werden die Kontierungsobjekte (zum Beispiel ein Fond) im Feld OBJEK (Schlüssel des zu klassifizierenden Objektes) gespeichert. Daneben kann die Auswahl auch über das Feld KLART (Klassenart) auf Merkmale der Klassenart 042 eingeschränkt werden.

Problematisch am Aufbau des Feldes OBJEK ist jedoch, dass hier für Fonds der Finankreis gefolgt von der Nummer des Fonds als Identifikator gilt. Dieses hat den Nachteil, dass sofern der Finanzkreis weniger als vier Zeichen enthält hier ein entsprechendes Leerzeichen eingefügt wird.

Als Beispiel wäre das Projekt 40210001 im Buchungskreis FIK als "FIK 40210001" in dieser Tabelle gespeichert.

Wo die Objektnummer im Innenauftrag noch in der Tabelle AUFK im Feld OBJNR gespeichert ist (OR000040210001) befindet sich in der Tabelle FMFINCODE kein entsprechendes Feld.

Hierzu müsste als Feld die Nummer des Fonds mit den Finanzkreis und einen Leerzeichen verbunden werden.

Zusatzfeld Fond aus Innenauftrag ableiten

Das bereits angelegte Infoset soll um zwei weitere Zusatzfelder erweitert werden. In der Pflege des Infosets innerhalb der Transaktion SQ02 (Pflege des Infosets)  kann über die Schaltfläche Zusätze (F5) bzw. über  SPRINGEN-> ZUSÄTZE ZUM KNOTEN 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 FONDS)  und die Art der Zusatzinformation.

Um hier die Nummer des Fond zu erhalten, soll ein Zusatzfeld mit den Namen FONDS angelegt werden.

Dieses hat folgende Eigenschaften: Langtext und Überschrift haben beide Fonds erhalten. Die Formatangabe wurde über LIKE-Referenz idenitsch zum Feld
AUFK-AUFNR gehalten. Damit entspricht dieses Feld den Formatangaben in der Tabelle AUFK (Typ C (Character) Länge 012 Ausgabenlänge 012). Damit ist das Feld angelegt, hat jedoch nur eine Datendefinition aber noch keine eigene Daten, da hier ja keine Selektion hinterlegt ist.

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. Dieses Coding entspricht auch den ABAP Code, den ich von einen Kollegen zur Verfügung gestellt bekommen habe. Das Coding für das Feld FONDS  sieht dabei wie folgt aus (wobei statt KRK natürlich Ihr Kostenrechnungskreis im Coding hinterlegt sein sollte):

DATA: l_fincode1 TYPE FMFINCODE-FINCODE.
DATA: l_aufnr TYPE aufk-aufnr.
l_aufnr = 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.
Somit sind die führenden Nullen entfernt

SHIFT l_aufnr BY 4 PLACES LEFT.
l_fincode1 = l_aufnr.

* Durch die Abfrage der Tabelle FINCODE wird die Nummer nur ausgegeben, wenn
* auch tatsächlich ein Fond angelegt ist.
SELECT SINGLE FINCODE FROM FMFINCODE INTO l_fincode1
       WHERE fikrs = 'KRK'
         AND FINCODE = l_fincode1.
IF sy-subrc <> 0.
  CLEAR fonds.
ELSE.
  fonds = l_fincode1.
ENDIF.

Auch diese Query geht davon aus, dass die Nummer des Innenauftrages und des Fonds identisch sind.

ACHTUNG: Länge der Auftragsnummer / Fondcode ist entscheidend!

Sollten die Auftragsnummern bspw. siebenstellig sind, ist hier natürlich mittels

SHIFT l_aufnr BY 5 PLACES LEFT.

das Coding entsprechend anzupassen.

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 FONDS 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 Fond 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 FONDS 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 FONDS mit den Finanzkreis zu verknüpfen.

Hierzu ist folgende kurze Codezeile erforderlich:

CONCATENATE  'FIK ' FONDS INTO OBJNFOND RESPECTING BLANKS.

Nun ist im Zusatzfeld OBJNFOND der entsprechende Fond entsprechend der Objektnummer im Tabellenfeld AUSP-OBJEK gespeichert.

Nun können die einzelnen Merkmale (bzw. deren Werte) als Zusatzfeld im Infoset angelegt werden. Als Selektionskriterium kann nun die Merkmalsnummer und die Klassenart verwandt werden.

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 könnte dann unter anderen das Merkmal FBINSTITUT für die Angabe des dem Fond zugeordneten Kürzel des Fachbereichs beziehungsweise das Kürzel eines zentralen Institutes oder EInrichtung sein. Alternativ könnte auch die betroffene Branche oder eine ausführlichere Zuordnung für die Bilanz sein (bspw. Unterscheidung nach Auftragsforschung, Dienstleistung, ...).

Merkmalswert aus Klassifizierung von Fonds auswerten


Für unser Beispiel nehmen wir an, dass das Merkmal Branche gepflegt ist und die Interne Merkmalsnummer (Feld ATINN) folgenden Wert hat 0000000001. Nun kann ein weiteres Zusatzfeld mit der Bezeichnung Branche angelegt werden.

Dieses erhält über die LIKE-Referenz die gleichen Eigenschaften wie das Tabellenfeld AUSP-ATWRT (hier ist der Merkmalswert gespeichert).
Beachten Sie, dass der Langtext später in der Query als Feldname genutzt wird und die Überschrift dann als Überschrift für die Spalte genutzt wird. Der technische Name steht dahingehend den Query-Erstellenden nicht zur Verfügung. Dennoch kann es sinnvoll sein den Langtext und den technischen Namen identisch zu halten, insbesondere wenn später noch Anpassungen erforderlich sein sollten.

Darüberhinaus wird im Feld Reihenfolge des Codeabschnitts 3 eingetragen, so dass als erstes das Feld FONDS danach OBJNFOND und abschließend die einzelnen Merkmalsfelder definiert werden können.

Das entsprechende Coding zum Feld würde dann wie folgt lauten:

DATA: L_BRANCHE type AUSP-ATWRT.
SELECT SINGLE ATWRT INTO L_BRANCHE FROM AUSP
 WHERE OBJEK = OBJNFOND AND ATINN ='0000000001' AND KLART = '042'.
 IF sy-subrc <> 0.
  CLEAR BRANCHE.
ELSE.
  BRANCHE = L_BRANCHE.
ENDIF.

Entsprechend kann auch für jedes weitere Merkmal verfahren werden.
Hierbei muss jedoch darauf geachtet werden, dass jedes Feld einzeln mit der entsprechenden ATINN gepflegt werden muss.

Wie bereits erwähnt kann in der Tabelle CABN die ATINN für die einzelnen Merkmale entnommen werden. Es bietet sich daher an in einen zweiten Modus über die Transaktion SE16 sich die Merkmale aus der Tabelle CABN ausgeben zu lassen.

Nachdem alle Felder erfasst sind, können diese in einer entsprechenden Feldgruppe (bspw. PSM-FM Stammdaten) eingefügt werden und damit für eine Query verwendet werden.

Dieses kann einen entsprechend hohen Aufwand verursachen insbesondere dann wenn weitere Merkmale hinzukommen.

Zusatzfelder in Query verwenden

Nun stehen die einzelnen Zusatzfelder (oder Merkmale) als eigene Felder im Infoset zur Verfügung und können so in eine Query eingebunden werden. Da das gesamte Infoset jedoch als Basis die Tabelle AUFK hat und anhand der Innenaufträge eine Selektion der einzelnen Datensätze erfolgt ist es leider nicht möglich über die Merkmale der Klassifizierung eine entsprechende Abfrage zu erstellen. Hier müsste der umgekehrte Weg über die Tabelle AUSP und Verknüpfung FMFINCODE mit AUFK gegangen werden, was jedoch den Nachteil hat, dass reine CO-Innnenaufträge in einer Auswertung nicht mehr ausgewiesen wären.

Query Stammdatenliste Innnenaufträge und verknüpfte Fonds sowie Merkmale aus Klassifizierung

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
Kostenstellentexte CSKT
Beschreibung (L) CSKT-KTEXT
Auftragsstammdaten AUFK
Profitcenter (L,S)
AUFK-PRCTR
Profit-Center-Stammdaten Texte (CEPCT)
Allgemeine Bezeichnung (L) CEPCT-KTEXT
Zusatzfelder (die im Infoset angelegt wurden)
Finanzierungszweck (L,S)  FINUSE
Auftragsstammdaten AUFK
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
Zusatzfelder (die im Infoset angelegt wurden)
Gesperrt (L)  GESPERRT
lokale Zusatzfelder

Lehreinheit  (L) 


Das Feld Lehreinheit wurde dabei aus der verantwortlichen Kostenstelle des Innenauftrages abgeleitet (siehe Artikel "Query über verantwortliche Kostenstelle des Innenauftrag - Bestimmung der Lehreinheit im Fachbereich durch Teil der Kostenstellennummer".
Nun können die einzelnen Merkmale der Klassifizierung als Listenfelder übernommen werden. Diese sind als Datenfelder unterhalb der Zusatzfelder zu finden und wurden wie beschrieben im Infoset definiert. Als Beispiel wären hier folgende Merkmale bzw. entsprechende Felder denkbar.

Zusatzfelder
Branche (L)
FB/Institut (L)
Geldgeber (L)
Dienstleistung (L)
Auftragsforschung (L)
UST-Pflicht (L)
VoKoR (L)
...

Das Zusatzfeld OBJNFOND muss nicht extra in der Grundliste der Query eingefügt werden, da darauf aus den einzelnen Merkmalen referenziert wird.

Insgesamt könnten damit wesentlich umfangreiche Stammdatenanforderungen aus SAP erfüllt werden. Im Gesamtergebnis kann hier nun aber eine Stammdatenliste zur Verfügung gestellt werden, die einzelne Daten aus den CO-Innenauftrag, Fond des Haushaltsmanagements (PSM-FM) und zusätzlich noch aus der Klassifizierung und das Sperrkennzeichen beinhaltet. Hierdurch ist eine mühsame Ausgabe über die Stammdatenliste der Innenaufträge (Transaktion KOK5), der Klassensuche (Transaktion CL30N) oder der alphabetischen Liste der Fonds (Transaktion S_KI4_38000039) nicht mehr zwingend erforderlich. Zumal die Klassifizierung in der Hauptsache als weiteres Selektionskriterium für eine Stammdatenliste und einzelnen Aufruf der entsprechende Fonds oder direkt im Stammsatz des jeweiligen Kontierungsobjektes genutzt wurde.

Wie schon beschrieben ist es leider nur möglich die Klassifizierungsmerkmale als Listenfelder und nicht als Selektionsfelder zu verwenden. Dennoch können so auch tiefergehende Informationen zum einzelnen Objekt mit ausgegeben werden.

ACHTUNG: Sonderfall Inkonsistenz bei Merkmalspflege

Die nun erstellte Query verhält sich in Bezug auf einen Sachverhalt abweichend zum SAP System. Sofern in der Merkmalspflege (Transaktion CT04) bestimmte Merkmale fest hinterlegt sind (und nicht die Funktion zusätzliche Werte aktiviert wurde um ein Freitextfeld zu ermöglichen) kann es bei Änderung der Merkmale dazu kommen, dass in der Query ein ehemals gepflegter Merkmalswert ausgewertet wird, wohingehend in der Stammdatenklassifizierung das Merkmal ohne Wert angezeigt wird und statt dessen die Schaltfläche Inkonsistenzen (mit Warnglocke) angezeigt wird.Sofern man auf diese Schaltfläche drückt, wird der nicht mehr gültige Wert als Ladefehler beziehungsweise Wertekonflikt ausgegeben.

Nehmen wir als Beisspiel das Merkmal BRANCHE. Bisher wurden viele Projekte der Branche IKT = Informations und Kommunikationstechnik zugeordnet. Künftig wird dieser Wert jedoch gelöscht und statt dessen die beiden Werte IT = Informationstechnik und KT = Kommunikationstechnik gepflegt.
Bei alten Projekten (Fonds) wird daher in der Transaktion FM5S beziehungsweise in der Klassifizierung ein Wertekonflikt ausgegeben und das Feld wird ohne Wert angezeigt, wohingehend in der Query noch der alte Wert IKT beim Projekt 40210001 ausgegeben wird, da dieser Fond in der Klassifizierung damals das zulässige Merkmal IKT zugewiesen bekam. Daher sollte beim Ändern der Werte eines Merkmals auch immer darauf geachtet werden, ob vorhandene Klassifizierungen ggf. angepasst werden sollten. Dieses sollte aber kein Problem der Query sondern des Stammdatenmanagement sein.

Hinweis: Query Stammdaten CO Innenauftrag PSM-FM Fond

Dieser Artikel ist Teil einer Serie um Stammdaten von CO Innenaufträgen und PSM-FM Fonds miteinander zu verknüpfen.
  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"

Insbesondere was die Auswertung von PSM Stammdaten anbelangt (so eben auch Klasifizierung oder Finanzierungszweck) dürfte der Artikel "SAP Query innerhalb des SAP Moduls PSM FM beziehungsweise Haushaltsmanagement" noch eine Menge Potential beschreiben und teilweise auch eine etwas einfachere Variante anbieten.

NACHTRAG: Merkmale der Klassifizierung durch Zusatztabelle

Seit 2014 ist auch wieder ein wenig Zeit vergangen, so dass ich zwischenzeitlich ebenfalls eine Erleichterung bei der Auswertung der Merkmale der Klassifizierung 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" innerhabl des Abschnitt "Merkmal aus Klassifizierung mit auswerten" durch das Zusatzfeld ZAUFNR kann nciht nur FMFINCOE als Zusatztabelle eingebunden werden sondern auch die Verknüpfung zwischen Fond und Klassifizierungsmerkmale ist dank CONCATENATE   wesentlich einfacher. Daher möchte ich ausdrücklich auch diese Methode empfehlen. ;-)


 

Hinweis:

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




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


Freitag, 28. November 2014
21:18 Uhr

Grundlagen Kurzeinführung und Handbuch SAP Query

SAP Query ist ein Werkzeug in SAP welches das Auslesen und auch Anlysieren von Tabellen im ERP System ermöglicht. Die Query ist dabei vergleichbar mit einer Abfrage innerhalb Access. Da ich unter den Tag Query schon einige Query vorgestellt habe soll dieser Artikel eine kurze eher allgemein gehaltene Einführung ins Thema geben und somit eine Grundlage bzw. ein Kurzhandbuch für die Erstellung von Queries darstellen.

1. Grundeinstellungen / Berechtigungen

Bei der Erstellung von Query und damit eine Auswertung von Datenbanktabellen sollte auch das Thema Berechtigungen nicht aussen vor gelassen werden.

1.1. Allgemeiner Tabellenschutz

Da bei der Erstellung von Query direkt in Datenbanken gelesen wird, sind zur Erstellung entsprechende Berechtigungen erforderlich. Zum Anzeigen einer Tabelle wird die Auswertungstransaktion und die Tabellenansichtberechtigung über das Berechtigungsobjekt S_TABU_DIS geprüft. Hierbei wird im Berechtigungsfeld Aktivität 03 (=Ansicht) und eine der Tabelle zugeordneten Berechtigungsgruppe geprüft. 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).
Hier kann auch über die Berechtigungsgruppe oder die Tabelle nach den entsprechenden Werten gesucht werden. So ist bspw. die Tabelle GLPCA der Berechtigungsgruppe KA (=CO:Anwendungstabelle) zugewiesen.

1.2. Berechtigungsrollen für Query

Sofern auch Anwender Query ausführen sollen, sollte sich hier vorab schon Gedanken um ein passendes Berechtigungskonzept gemacht werden. Hierzu sind im Artikel "SAP Query: Berechtigung (organisatorisch und technisch)" schon einige Anmerkungen gemacht worden.
Da es in diesen Artikel um die Grundlagen zur Erstellung einer Abfrage und das entsprechende Umfeld geht werden hier weiter gehende Berechtigungen vorgestellt.

Berechtigungsobjekt S_TCODE

Hier werden die einzelnen Transaktionscodes zum Arbeiten mit einer Query beschrieben.
Für das Ausführen einer Query ist folgende Transaktion gedacht:

  • SQ00 SAP Query: Queries starten

Für die Pflege und Erstellung sollten noch folgende Transaktionen hinterlegt werden:

  • SE12 ABAP Dictionary Anzeige
  • SE36 Logical Database Builder
  • SQ01 SAP Query: Queries pflegen
  • SQ02 SAP Query: InfoSet pflegen
  • SQ03 SAP Query: Benutzergruppenpflege

Weitere relevante Berechtigungsobjekte sind S_DEVELOP, S_TABU_DIS und S_QUERY. Dieses sollten gemeinsam mit der SAP Basis mit passenden Berechtigungswerten versehen werden.
Sofern auch ABAP Coding im Infoset hinterlegt werden soll, 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.
Für die Ausführung von Query sollte im Berechtigungsobjekt S_DEVELOP die Aktivität 03 und ggf. Objekttyp LDB ausreichend sein. Für die Erstellung von Query sollten ggf. weitere Aktivitäten und Objekttypen hinterlegt werden (weitreichende Berechtigung wären die Aktivitäten 01,02,03,06,07)

Weitere Objekttypen im Berechtigungsobjekt S_DEVELOP sind:

  • DOMA: Domänen
  • DTEL: Datenelemente
  • ENQU: Sperrobjekte
  • INDX: Sekundärindices*
  • MCID: Matchcode-ID*
  • MCOB: Matchcode-Objekte*
  • SHLP: Suchhilfen
  • SQLT: Pool/Clustertabellen*
  • SQTT: Technische Einstellungen Tabellenpool
  • STRU: Strukturen
  • TABL: Transparente Tabellen*
  • TABT: technische Einstellung zu Tabellen
  • TTYP: Tabellentypen
  • TYPE: Typgruppen
  • VIEW: Views*
  • VIET: Viewtypen
  • LDBA: Logische Datenbank

sowie die einzelnen Aktivitäten. Für eine reine Ansicht der Query (bzw. Ausführen) sollte die Aktivität 03 für den Objekttyp LDBA ausreichen, wenn auch logische Datenbanken mitausgewertet werden sollen.

Je nach Aufstellung kann es sinnvoll sein zwei Rollen anzulegen. Eine für die Ausführung von Query bspw. QUERY-EXECUTE und eine für die Pflege bspw. QUERY-CREATE. Bei der Zuordnung des Berechtigungsobjektes S_QUERY ist jedoch zu beachten, dass ein Benutzer, der die Berechtigung für das Berechtigungsobjekt S_QUERY mit den beiden Aktivitäten 02 Ändern und 23 Pflegen besitzt, alle Queries aller Benutzergruppen zugreifen kann.
Daher sollte in der Rolle zum Ausführen einer Query dieses Berechtigungsobjekt ohne Berechtigungsfeldwerte hinterlegt werden, da andernfalls die Steuerung über die Benutzergruppen problematisch ist. Auf diese gehen wir im Folgenden ein.

1.3. Transaktion für Query zuweisen

Im Artikel "Transaktion anlegen (Report, Parameter) bspw. für SAP Query" ist eine Möglichkeit beschrieben, wie die erstellte Query später dann als Transaktion für Infouser zur Verfügung gestellt werden kann.
 

2. Benutzergruppe anlegen (Transaktion SQ03)

Neben der Berechtigungssteuerung über das Berechtigungsobjekt S_QUERY gibt es auch die Möglichkeit Berechtigungen zur Pflege und Zugriff auf Query über Benutzergruppen zuzuordnen. Starten Sie hierzu die Transaktion SQ03.

Sofern Sie zum ersten Mal diese Transaktion aufgerufen haben, sollten Sie über UMFELD->ARBEITSBEREICH auf den Standardbereich (mandantenabhängig) wechseln. Alternativ kann dieses über einen Benutzerparamter im Userstamm festgelegt werden. Dieses geht im SAP Menü unter (System->Benutzervorgaben->Eigene Daten oder direkt über die Transaktion SU3. Hier kann im Reiter Parameter sowohl der Arbeitsbereich als auch ggf. die Benutzergruppe per Benutzerparameter hinterlegt werden. Für den mandantenabhängigen Arbeitsbereich wird hierzu der Parameter AQW ohne Wert angelegt, so dass Sie hier nicht jedes Mal aufs Neue den Arbeitsbereich wechseln müssen.

In das Feld Benutzergruppe können Sie eine entsprechende Benutzergruppe mit der Schaltfläche ANLEGEN erstellen. Hierzu können Sie eine Beschreibung der Gruppe ergänzen. Ein Beispiel wäre die Benutzergruppe AGCO. Über die Schaltfläche "Benutzer und Infosets zuordnen" können Sie dann entsprechende SAP Benutzer (und später auch Infosets) der Gruppe zuordnen. Ergänzend zum Benutzer kann über das Ankreuzfeld neben den Benutzernamen die Änderungsberechtigung über das Berechtigungsobjekt S_QUERY entzogen werden. Benutzer die gar keine Berechtigung zum Ändern haben bekommen auch diese Funktion entsprechend als nicht pflegbar angezeigt.

Dieses bedeutet, dass Benutzer, die generell keine Query ändern, pflegen dürfen über die Benutzergruppe bestimmte Queries zugeordnet bekommen dürfen. Darüber hinaus kann Usern die Berechtigung zur Pflege von Queries trotz vorhandener Berechtigungen im Berechtigungsobjekt S_QUERY entzogen werden kann.

Generell hat ein Benutzer mit Zuordnung des  Berechtigungsobjekt S_QUERY mit den beiden Berechtigungsfeldwerten Ändern und Pflegen die Berechtigung auf jede Query zuzugreifen, ohne dass dieser in einer entsprechenden Benutzergruppe zugeordnet ist. Je nach Berchtigungskonzept kann dieses zum Beispiel für alle Keyuser in diesen Bereich gelten. Um nun nur eine Query auszurollen, kann es daher sinnvoll sein, diese wie im Artikel "Transaktion anlegen (Report, Parameter) bspw. für SAP Query" beschrieben in den Berechtigungsrollen als eigene Transaktion zu hinterlegen.
 

3. Datenherkunft finden

Die Hauptaufgabe zur Erstellung von SAP Query ist die Identifikation der relevanten Datenbanktabellen. Hier können im SAP System die Datenfelder mit der F1 Hilfe angezeigt werden. Hierzu wird im Hilfetext auf die Technischen Informationen geklickt und unter den Feld-Daten sind im Idealfall auch die Tabelle und der Feldname der Tabelle mit aufgeführt.
Alternativ kann auch mit der Transaktion SE12 nach passenden Tabellen für die Auswertung gesucht werden. Eigentlich ist diese Transaktion für die Anzeige der Tabellenstruktur gedacht. Über die Werthilfe (F4) können aber auch vorhandene Tabellen durchsucht werden. Hier kann dann entweder anhand der Schaltfläche Infosystem nach Tabellennamen und Kurzbezeichnung gesucht werden oder über die Schaltfläche SAP Anwendung innerhalb der einzelnen SAP Module und Komponenten gesucht werden. Neben den einfachen Fall einer direkt lesbaren transparenten Tabelle (zum Beispiel für Innenaufträge die Tabelle AUFK) gibt es auch sogenannte Clustertabellen. Innerhalb eines Cluster werden Felder anderer Tabellen komprimiert in einer einzelnen Spalte gespeichert. Hierdurch ist eine Verwendung von Cluster-Tabellen ebenso wie Pool-Tabellen nicht in Joins möglich. Clustertabellen sammeln hierdurch mehrere Einzeltabellen in einer Tabelle und haben den Nachteil, dass diese nicht direkt ausgewertet werden können. Hierzu bietet sich dann die Verwendung einer logischen Datenbank an.

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.


Im Artikel "Tabellen hinter Transaktionscode oder ABAP Programm über eine SAP Query ermitteln" ist eine Möglichkeit beschrieben durch die anhand eines Transaktioncode die hinter diesen Programm genutzten Tabellen ausgegeben werden. Hier sind dann bspw. für die Transaktion KO03 (Innenauftrag anzeigen) auch alle relevanten Tabellen für die Stammdaten des Innenauftrages gelistet.

Daneben gibt es natürlich auch die Möglichkeit der Recherche im Netz nach entsprechenden Tabellen. So bietet die Seite sap-community.de unter "Verzeichnis SAP Tabellen"  eine kleine Zusammenstellung von verschiedenen häufig genutzten Tabellen bspw. aus den Bereichen FI, CO oder anderen Komponenten von SAP an. In Form einer MindMap ist dieses auch auf der Seite eberstein.de zu finden (siehe auch "Mindmapping und Sketchnotes im Beruf nutzen für Brainstorming oder Mind Mapping mit XMIND")

4. Infoset anlegen (Transaktion SQ02)

Durch das Anlegen eines Infosets kann die Bezeichnung und die Art der Datenherkunft (Datenquelle) festgelegt werden. In der Regel können Sie hier drei Varianten häufig nutzen:

Tabellen-Join über Tabelle
Hier kann eine Haupttabelle gepflegt werden und diese mit anderen Tabellen verknüpft werden. Hierzu muss eine entsprechende Verknüpfung zwischen zwei übereinstimmende Felder gestaltet werden (Join).

Direktes Lesen der Tabelle
Hier kann direkt eine Tabelle ausgelesen. Dieses kann sinnvoll sein, wenn nicht die Transaktion SE16 (Tabelle anzeigen) sondern tatsächlich nur eine direkte Tabelle ausgelesen werden soll.

Logische Datenbank
Innerhalb einer logischen Datenbank liefert SAP schon passende Tabellenstrukturen zu wichtigen Datenobjekten. Entsprechende Verknüpfungen sind hier schon hinterlegt. Beispiele für logische Datenbanken sind bspw. ADA (Anlagendatenbank) oder BRF (BELEGDATENBANK).

Wird eine Tabelle direkt gelesen erfolgt im Folgeschirm gleich die Frage, ob alle Tabellenfelder in eine Feldgruppe übernommen werden sollen. Die Datenfelder innerhalb einer Feldgruppe stehen dann später als Auswertungsobjekte zur Verfügung. Daher kann es sinnvoll sein hier direkt alle aufnehmen auszuwählen. Alternativ könnten hier auch einzelne Felder in das Infoset aufgenommen werden.

Sofern ein Tabellen-Join über eine Tabelle gebildet werden soll, erscheint im Folgebild die Tabelle mit ihren einzelnen Feldern und es kann im Menü unter BEARBEITEN->TABELLE EINFÜGEN eine weitere Tabelle eingefügt werden. SAP schlägt automatisch eine Verknüpfung zwischen den beiden Tabellen vor. Hierbei werden als Vorschlag automatisch Verknüpfungslinien zwischen einzelnen Feldern gezogen. Diese können markiert werden und über die rechte Maustaste gelöscht 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).

Sofern Sie weitere Felder miteinander verknüpfen wollen können sie diese Felder zwischen den einzelnen Tabellen hin und her ziehen. Markieren Sie hierzu das Feld der Tabelle und ziehen Sie es auf ein passendes Tabellenfeld. Über die Schaltfläche Verknüpfungsbedingungen prüfen (F9) können Sie sehen, ob diese Verknüpfung auch gültig ist.
Eine Dokumentation von Tabellenbeziehungen (nicht nur für SAP Query) habe ich im Artikel "Graphische Darstellung von Tabellenverknüpfungen bspw. bei Query" beschrieben. Dieses kann bspw. für externe Dokumentationen genutzt werden oder wenn nur die Schlüsselfelder und nicht die gesamten Tabellenbeziehungen als Screenshot aus SAP dokumentiert werden sollen.
 

ACHTUNG:
Eine gültige Verknüpfung ist nur möglich, wenn die beiden Felder in ihren Eigenschaften übereinstimmen. Stimmen die Felder in ihren Eigenschaften nicht überein muss per Coding eine Übereinsteimmung erfolgen. Diese Variante ist im Artikel "SAP Query ABAP Coding im Zusatzfeld für Verknüpfung Innenauftrag und Fond bzw. Finanzierungszweck" ausführlicher beschrieben.

Nachdem Sie die Verknüpfungen definiert haben können Sie über die Schaltfläche Infoset zur Pflege des Infosets zurückkehren. Auch hier bekommen Sie eine Rückfrage, welche Tabellenfelder als Vorbelegung von Feldgruppen verwendet werden sollen. Auch hier empfiehlt sich die Option "alle Tabellenfelder aufnehmen", da dadurch spätere Berichtsanforderungen wesentlich leichter übernommen werden können. Alternativ besteht die Möglichkeit auch selbst Feldgruppen und passende Felder zu erstellen. Nach erfolgreicher Pflege kann das Infoset gespeichert und generiert werden.
Danach sollten Sie das Infoset über die Schaltfläche Zuordnung zu Rollen/Benutzergruppen einer Benutzergruppe bspw. AGCO zuordnen in der Sie später auch die Query erstellen möchten.

Erweiterung des Infosets durch Zusatztabellen oder Zusatzfelder

Neben einer reinen Auswertung von einzelnen Tabellen (oder der Auswertung von Verknüpfungen / Infosets) kann innerhalb einer Query auch mit Zusatzfeldern oder Zusatztabellen gearbeitet werden. Hierdurch können in eine Query auch Tabellen verknüpft werden die nicht direkt innerhalb eines Join verknüpft werden können, da noch ein weiteres Selektionsmerkmal wie bspw. der Buchungskreis erforderlich ist. Ein entsprechendes Beispiel ist im Artikel "Query über IBAN und Stammdaten Kreditor oder Debitor (Zusatztabellen in SAP Query)" beschrieben. Darüberhinaus besteht auch die Möglichkeit Zusatzfelder, wie bereits oben erwähnt per ABAP Coding zu ergänzen. Hier ist im Artikel "SAP Query - Auswertung Merkmale der Klassifizierung am Beispiel Fonds in PSM-FM" ein recht umfangreiches Beispiel gegeben in dem die Merkmale der Klassifizierung aus der Tabelle AUSP ausgewertet werden.

Insbesondere was die Auswertung von PSM Stammdaten anbelangt dürfte der Artikel "SAP Query innerhalb des SAP Moduls PSM FM beziehungsweise Haushaltsmanagement" ein schönes Beispiel für die Verwenudng einer Zusatztabelle mit ABAP Coding sein.

Diese Zusatzfelder können dann ebenfalls entweder in einer eigenen Feldgruppe oder einer bestehenden Feldgruppe übernommen werden (so als wären diese in einer Tabelle vorhanden) und im Query Painter bzw. bei der Erstellung der Query aus den Zusatzfeldern (meistens recht weit unten) ebenfalls übernommen werden.

ABAP Coding

Gerade bei der Anlage von Zusatzfeldern mit Coding ist auch der Umgang mit ABAP hilfreich. Hier zeigt der Artikel "Syntaxhevorhebung im ABAP Editor durch neuen Frontend Editor (Quelltext-Modus)" ein in meinen Augen sehr hilfreiche Ergänzung des Editors. Gerade durch Syntaxhervorhebung dürfte dieses einige Erleichterungen anbieten. Das umfangreichste Beispiel für ABAP Coding bei Zusatzfeldern ist sicherlich die Artikelserie zur CO Einzelpostenliste mit Ergänzung der Stammdaten aus CO-Innenauftrag und PSM-FM Fond  die in folgenden Artikeln  beschrieben ist: "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" (Definition eines Infoset mit entsprechenden Zusatzfeldern und Einbindung der Tabelle FMFINCODE als Zusatztabelle zu AUFK, ferner wird hier durch Coding aus der verantwortlichen Kostenstelle über eine Wenn-Funktion die zugeordnete Lehreinheit ermittelt).

 

5. Query anlegen (SQ01)

Rufen Sie zur Erstellung einer Query die Transaktion SQ01 auf. Ggf. sollten Sie in die passende Benutzergruppe über die Schaltfläche Bengruppe wechseln (Umsch+F7) wechseln und nun eine entsprechende Query anlegen. Beachten Sie hier, dass Sie auch hier im mandantenabhängigen Bereich arbeiten.
Nachdem Sie einen Namen für die Query gewählt haben und auf die Schaltfläche Anlegen gewechselt müssen SIe definieren, welches Infoset als Grundlage für die Query verwendet werden soll. Nun können Sie einen Titel für die Query sowie entsprechende Bemerkungen festlegen. Der einfachste Weg der Gestaltung ist nun der Wechsel über die Schaltfläche "Grundliste". Über die Grundliste können dann die anzuzeigenden Felder des Infosets ausgegeben werden. Sie können im Layoutdesign aus den einzelnen Feldgruppen die einzelnen Felder als Listenfelder (die werden in der Query dann ausgegeben) und Selektionsfelder (diese müssen beim Aufruf der Query gefüllt werden und stellen die Abfragekriterien dar). Über die Schaltfläche Testen kann die entsprechende Query gestestet werden.

Reihenfolge Selektionsfelder bei Query ändern

Nun erscheint auch direkt die Selektionsmaske der Query. Sofern Sie die Reihenfolge der Selektionsfelder später ändern möchten, ist dieses über SPRINGEN->FELDAUSWAHL->SELEKTIONEN durch die Spalte Nr. innerhalb der Transaktion SQ01 (Einstiegsbild) möglich, wodurch die Reihenfolge auf dem Selektionsbild durch Nummern zwischen 1 und 90 festgelegt werden. Hier kann es sinnvoll sein, in fünfer Schritten die Nummern festzulegen, so dass eine Umsortierung problemlos möglich ist.

Andernfalls kann die Grundliste gesichert und beim Verlassen der Query diese auch generiert werden. Sofern Sie als Ausgabeform SAP List Viewer gewählt haben (das ist im Standard der Fall) erhalten Sie beim Start der Query eine ALV Liste und können hier die üblichen Sortierungen, Filterungen oder auch Ausblendungen vornehmen.

6. Berichtszuordnung zu Query (Bericht-Bericht-Schnittstelle)

Je nach Auswertung kann es hilfreich sein auch direkt eine entsprechende Absprungtranssaktion zu definieren. Hierzu kann innerhalb der Pflege der Query über SPRINGEN->Berichtszuordnung über das +Zeile einfügen weiere Query eingefügt werden. Sinnvoller ist es hier oft statt einer Query über anderer Berichtstyp die Funktion TR Transaktion zu wählen. Somit können zu ausgewerteten Stammdaten (zum Beispiel einer Kreditoren-Stammdaten-Liste). entsprechende Bewegungsdaten oder weitere Informationen aufgerufen werden. Ein Beispiel ist hier im Artikel "Query über IBAN und Stammdaten Kreditor oder Debitor" beschrieben in der zu den Kreditoren auch gleichzeitig auf die Transaktion FBL1N für eine Einzelpostenliste gesprungen werden kann. Ein anderes Beispiel wäre der Aufruf einer Anlage mit der Transaktion AS03 oder die Pflegetransaktion von Stammdaten wie KS02 für Kostenstellen ändern.
Wichtig ist dabei, dass in der Grundliste auch alle notwendigen Felder für diesen Bericht mit ausgegeben werden, so dass diese mit übergegeben werden können. So wäre für die Beleganzeige (FB03) auch der Buchungskreis recht hilfreich :-)
 

7. Query um lokale Felder erweitern

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.

7.1. Per Formel Teilstring aus Variablen auslösen in Query

Im Artikel "Query Stammdatenvergleich Profit-Center und Auslesen von Textbestandteilen (Teilstring aus Variable)" wird als Beispiel die Möglichkeit beschrieben bestimmte Textbestandteile aus einen Feld auszuwerten.

7.2. Ikonen / Ampelfunktionen abhängig vom Wert ausgeben in Query

Daneben gibt es die Möglichkeit über IKONE  eine Ampelfunktion für bestimmte Werte zu hinterlegen (Beispiele sind in den Artikeln "Query Stammdaten CO Kontrolle Verantwortliche" oder "Abgleich Belege in CO auf Profit-Center mit zeitabhängigen Stammdaten der Anlagenbuchhaltung bei Investitionen" zu finden).

7.3. Mehrere Datenfelder in Query summieren

Daneben können aber auch eche Berechnungen durchgeführt werden. Diese ist im Artikel "CO Planeinzelposten Objekt und Partnerobjekt auswerten / Mehrere Felder summieren" beschrieben. Alternativ sind natürlich auch andere Berechnungen (Prozent, Summen oder andere Berechnungen möglich.

7.4. Umgang mit Datum in Query

Der Umgang mit Datumsfeldern in SAP Query ist ein wenig komplizierter. Für einfache Berechnungen dürfte aber folgender Artikel eine gute Anlaufstelle bieten "Umgang mit lokalen Datumsfeldern in Queries". Sofern Sie komplexere Berechnungen (bspw. Abstand zwischen zwei Terminen) berechnen wollen werden Sie  jedoch nicht um die Verwendung eines Zusatzfeldes im Infoset und eines entsprechenden ABAP Codes herumkommen.

Hier wurde auf sap-community.de im Beitrag "Anzahl von Tagen zwischen 2 Daten" eine passende Lösung vorgestellt.

Hierzu werden beide zu vergleichenden Datumsfelder (DATUM1 und DATUM2) mit Type DATS als Variablen definiert und aus den jeweiligen Tabellen innerhalb des Infosets mit einer Wertzuweisung gefüllt.

Danach wird das Zielfeld (AbstandTage) als TYPE P definiert und über die Formel "ABSTANDTAGE = DATUM1 - DATUM2." errechnet. Damit wäre im Infoset auch ein entsprechende Berechnung mit Datumswerten möglich. Inwieweit dieses auch über eine Formel innerhalb der Query möglich ist bin ich mir nicht sicher, aber vielleicht hilft dieser Ansatz ja schon weiter. Hierbei könnte die Variable DATUM1 natürlich auch als SYDATUM definiert werden, so dass heir der Abstand zum aktuellen Systemdatum errechnet wird.

7.5. Zeichenkette eines Feldes nach einen Wert durchsuchen

Eine weitere Möglichkeit per Coding besteht auch in der Durchsuchung eines Feldes nach einen bestimmten Zeichen. Dieses ist auf sap-community.de im Beitrag " Query, Zeichenkette durchsuchen und Ausgabe als lokales Feld?" erläutert.

Hierzu wird folgendes Coding  im Zusatzfeld ZFELDSUCHE für das zu analysierenden Feld (im Beispiel PRUEFFELD)  nach Suchstring hinterlegt.

FIND 'SUCHSTRING' IN prueffeld.
IF sy-subrc = 0.
ZFELDSUCHE = 'J'.
ELSE.
ZFELDSUCHE = 'N'.
ENDIF.

Daneben sind natürlich noch viele andere Möglichkeiten dank ABAP Coding möglich, aber auch einfache Abfragen und Formeln dürften viel Auswertungsarbeit abnehmen.
 

8. Query und Infoset per Upload/Download transportieren

Hier gibt es in der Infosetpflege (Transaktion SQ02) die Möglichkeit der Nutzung eines SAP Query Transporttool. Hier können Benutzergruppen, Infoset, Infoset und Query aber auch nur Queries auf unterschiedliche Weise transportiert werden. Besonders interessant ist hierbei die Option des Download bzw. Upload als Transportvariante. In das SAP Query Transporttool gelangt man über die Transaktion SQ02 und hier über das "LKW" Symbol (Transporte STRG F5). Nun wir der Report RSAQR3TR gestartet und von hier kann ein Transport bzw. Download gestartet werden. Alternativ kann der Transport auch direkt über die Transaktion SA38 gestartet werden. Neben der Auswahl der Transportaktion Download für Export und Upload für Import kann im Abschnitt Transport von Infosets und Queries entsprechende Infosets und Query (auch per Mehrfachauswahl) selektiert werden. Hier gibt es keine Wertauswahlhilfe (F4), so dass hier die exakten Namen eingetragen werden müssen. Vorteilhaft ist hier eine sprechende Namenskonvention. Als Importoption lassen wir REPLACE stehen. Beachten Sie, dass auch die Zuordnung zu einer Benutzergruppe entsprechend hinterlegt ist, so dass diese ebenfalls im System in dem die Query importiert wird, festgehalten werden sollte.

Der Nachteil des Transport über Datei (Download/Upload) ist dass hier der Transport von Varianten von Queries ebenso wie Layout-Varianten nur beim Export/Import/Kopieren möglich ist. Durch Export und Import werden (im Gegensatz zum Download/Upload) keine Datei erzeugt sondern ein echter Transportauftrag. Die Funktion Kopieren ermöglicht es die Query vom Standardbereich in den globalen Bereich zu kopieren (und natürlich auch umgekehrt). Je nach Komplexität der einzelnen Varianten kann daher auch ein klassischer Transportauftrag statt Austausch per Datei hilfreich sein.
 

9. Selektionsvariante und Layoutvarianten

Wird eine Query ausgeführt kann bei der Selektion der notwendigen Daten (Selektionsbild) über "Als Variante sichern..." (Disketten/SpeichernSymbol in der zweiten Symbolleiste oder über Strg+S) die getroffene Auswahl (bspw. bestimmte Zeiträume oder Selektionen gespeichert werden. Hier habe ich mir angewohnt für immer wieder notwenige Datenfelder diese durch eine Variante mit der Bezeichnung ALLGEMEIN vorzubelegen. Diese Variante kann in der Pflege der Query (SQ01) beim Ändern im Einstiegsbild über Spezielle Atttribute als Standardvariante hinterlegt werden, so dass diese auch wenn keine Variante gewählt wurde automatisch mit ausgeführt wird. Ferner kann hier die Option "Ausführen nur mit Variante" gewählt werden, so dass auf jeden Fall eine Variante gewählt werden muss).

9.1. Geschützte Varianten (Selektion und Layout)

Ferner können Varianten auch geschützt werden, so dass in der Regel nur der Autor der Variante diese wieder ändern kann. Im Artikel "Geschützte Selektionsvarianten entsperren" ist allerdings eine Möglichkeit beschrieben diesen Schutz zu entfernen.

Daneben kann in der Ausgabeliste (ALV) der Query ebenfalls eine Layoutvariante erstellt werden, so dass bestimmte Zwischensummen gebildet oder einzelne Spalten ausgeblendet werden. Auch diese Layoutvariante könnte in der Variante zur Query fest hinterlegt werden.

9.2. SAP Query nur ausführen (Berechtigung)

Ein weiterer Aspekt wäre noch auf welche Weise die einzelnen Berichte den Infousern zur Verfügung gestellt werden. Unter 1.3. hatte ich schon darauf verwiesen, dass die Möglichkeit besteht für eine Query eine eigene Transaktion zur Verfügung zu stellen. Auf diese Weise muss die Query nicht über die Transaktion SQ00 (oder über die Transaktionen FQUS, FQUD oder FQUK in der Finanzbuchhaltung bzw. PQAH im HCM) ausgeführt werden sondern können auch im Menü zur Verfügung gestellt werden. Eine ausführlichere Beschreibung hierzu ist im Artikel "Benutzereigene SAP Menüs (Favoriten, Benutzermenü, Bereichsmenü)" zu finden. Dieses Thema ist ausführlicher auch im Artikel "Berechtigungen zur Ausführung von SAP Query (Transaktion SQ00 oder eigene Z/Y Transaktion) und Einbindung im Berechtigungskonzept und Berichtswesen" behandelt worden.
 

10. Beispiele für Query

Bisher erstellte Query sind unter den Tag Query hier ebenso wie diese Einführung als Artikel zu finden. Daneben sind sowohl im Amazon Partnershop (siehe Onlineshop) als auch bei den Buchempfehlungen  einige Literaturempfehlungen zum Thema zu finden.

Insbesondere das Buch "Praxishandbuch SAP Query-Reporting (SAP PRESS) Von Stephan Kaleske, Karin Bädekerl, Heinz Forsthuber" ist hier sicherlich empfehlenswert.

Daneben bin ich aber auch von Martin Peto und Katrin Klewinghaus " Reporting im SAP-Finanzwesen: Standardberichte, SAP QuickViewer und SAP Query" begeistert und finde, dass sich beide sehr gut ergänzen. Gerade da Sie unterschiedliche Schwerpunkte setzen.

11. Ausführliche Literaturempfehlungen

Wie bereits erwähnt haben Martin Peto und Katrin Klewinghaus zum Thema SAP Query auch folgendes Buch geschrieben.

Reporting im SAP - Finanzwesen
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.

Praxishandbuch SAP Query-Reporting

ISBN: 978-3836218405

Eine ausführlichere Beschreibung dieses Buch ist auf der Seite "Praxishandbuch SAP Query-Reporting" zu finden.

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


Donnerstag, 6. November 2014
06:25 Uhr

Query über IBAN und Stammdaten Kreditor oder Debitor (Zusatztabellen in SAP Query)

Ausgangslage
Zur Vermeidung von mehrfach angelegten Kreditoren / Debitoren soll ein Abgleich über die IBAN erfolgen, ob ein entsprechender Stammdatensatz hier schon angelegt worden ist. Da zwischenzeitlich IBAN eingeführt ist (siehe Artikel "IBAN in der Stammdatenpflege generieren (SEPA)") sollte in jeden Kreditor / Debitor das Feld IBAN gepflegt sein.

Da im Standard keine Auswertung über die Stammdaten der Debitoren- / Kreditoren-Rechnung möglich ist, bietet sich hier eine entsprechende Query an.

Tabellen identifizieren

Leider ist das Feld IBAN nicht in den Stammdatentabellen der Kreditoren und Debitoren vorhanden. Hierfür wird in SAP die Tabelle TIBAN angelegt, die zu den "vorhandenen" Bankverbindungsdaten auch die entsprechende IBAN hinterlegt hat.

Die Zahlungsverkehrsdaten sind in den Tabellen LFBK "Lieferantenstamm (Bankverbindungen)" für Kreditoren und KNBK "Kundenstamm (Bankverbindungen)" für Debitoren hinterlegt.

Bei der Definition eines Infosets funktioniert jedoch keine direkte Definition eines Tabellenjoins über die Tabellen LFBK und TIBAN. Es werden hier nur drei Verknüpfungen vorgeschlagen, es sind jedoch vier erforderlich um eine eindeutige Auswertung zu treffen.

Eine Verknüpfung der Felder BANKS, BANKL und BKONT funktioniert zwischen LFBK und TIBAN. Jedoch ist das Feld BANKN (Bankkontonummer) in der Tabelle LFBK als Char mit 18 Zeichen und in der Tabelle TIBAN mit Char 35 Zeichen definiert. daher wird eine Verknüpfung mit der Fehlermeldung "Illegale Join-Bedingung" abgelehnt.


Daher ist hier der Umweg über die Zusatztabelle erforderlich.

Infoset anlegen

Innerhalb der Transaktion SQ02 wird folgendes Infoset definiert. Hierfür wird als Datenquelle ein Tabellen-Join über Tabelle LFBK   (bzw. KNBK) angelgt.

1. Stammdaten

Innerhalb des Infosets IBAN-KREDITOR nehmen wir als Datenquelle einen Tabellen-Join über die Tabelle LFBK und ergänzen in der Join Definition über BEARBEITEN->TABELLE EINFÜGEN die Tabelle LFA1  "Lieferantenstamm (allgemeiner Teil)". Die vorgeschlagene Verknüpfung über das Feld LIFNR lassen wir bestehen. Danach wechseln wir über die Schaltfläche Infoset und lassen alle Felder der beiden Tabellen in Feldgruppen anlegen.

Für das Infoset IBAN-DEBITOR verknüpfen wir die beiden Tabellen KNBK und die Tabelle KNA1 wie vorgeschlagen über das Feld
KUNNR. Auch hier werden alle Felder in eine Feldgruppe übernommen.

Danach haben wir zwei Feldgruppen mit der Bankverbindung und den allgemeinen Stammdaten (Anschrift) der Kreditoren bzw. Debitoren.

Erweiterung des Infoset über Zusatztabelle TIBAN

Ü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 TIBAN  und als Art der Zusatzinformation Zusatztabelle ein. Nun erfolgt eine Abfrage über SELECT SINGLE * FROM TIBAN WHERE ...
in der mehrere Bedingungen erfüllt sein sollen.

Diese habe ich für beide Infosets in folgender Tabelle erläutert.

 
Bedingung INFOSET IBAN-KREDITOR INFOSET IBAN-DEBITOR
Verknüpfungsbedingungen Zusatztabelle TIBAN
WHERE BANKS = LFBK-BANKS KNBK-BANKS
AND BANKL= LFBK-BANKL KNBK-BANKL
AND BANKN= LFBK-BANKN KNBK-BANKN
AND BKONT= LFBK-BKONT KNBK-BKONT

Aus Performancegründen kann hier noch das Feld "intern puffern" angekreuzt werden, wodurch diese Tabelle gepuffert wird und somit bei häufiger Abfrage einer IBAN die Daten schneller gefunden werden können.Der Nachteil ist dann jedoch der gesteigerte Speicherbedarf, da für die Zusatztabelle eine neue interne Tabelle angelegt wird.

Wichtig ist, dass das Feld IBAN aus der Tabelle TIBAN ebenfalls ein einer Feldgruppe innerhalb des Infosets mit aufgenommen werden muss. In der Query ist dieses in der entsprechenden Feldgruppe des Infosets vorhanden.

Vergessen Sie nicht das Infoset dann einer entsprechenden Benutzergruppe über die Schaltfläche "Zuordnung zu Rollen/Benutzergruppe" zuzuordnen, da dieses Infoset andernfalls nicht für eine Query verwendet werden kann.

Hintergrund: Aufbau IBAN

Eine Verknüpfung der Felder BANKN  (Bankkontonummer) war in der Definition des Infosets nicht möglich (Fehlermeldung illegale Verknüpfung). Hintergrund ist, dass das Feld LFBK-BANKN mit 18 Zeichen (Typ Char) und in der TIBAN-BANKN mit 35 Zeichen definiert ist. Alledings werden bei einer Verknüpfung über die Zusatztabelle dann einfach die fehlenden Zeichen aufgefüllt, so dass eine Verknüpfung zwischen LFBK, KNBK und TIBAN hergestellt werden kann. Da sich die IBAN aus einer Kombination von Ländercode, Prüfziffer, Bankleitzahl und Kontonummer zusammensetzt, kann auch nur durch die Verknüpfung aller vier Felder eine eindeutige Zuordnung der Bankverbindung zur IBAN gefunden werden. Dies wird an folgenden Beispiel deutlich:
 
Deutsche IBAN (immer 22 Stellen)
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
DE Prüfsumme Bankleitzahl Kontonummer
 Zur weiteren Beschreibung des IBAN AUfbaus siehe Wikipedia: Zusammensetzung IBAN
 

Query Suche IBAN über Kreditor oder Debitor

Innerhalb der Query werden nun auf folgende Felder der einzelnen Tabellen  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:


Auch hier sind wiederum zwei Query anzulegen:
 
Feld Query Kreditor Query Debitor
Query Suche über IBAN nach Kreditor/Debitor
IBAN TIBAN-IBAN (L,S) TIBAN-IBAN (L,S)
Kontonummer des Lieferanten bzw. Kreditors
Debitorennummer
LFBK-LIFNR (L,S)
 
KNBK-KUNNR (L,S)
 
Name 1 LFA1-NAME1 (L) KNA1-NAME1 (L)
Postleitzahl LFA1-PSTLZ (L) KNA1-PSTLZ (L)
Ort LFA1-ORT01 (L) KNA1-ORT01 (L)
Bankschlüssel (BLZ) LFBK-BANKL (L) KNBK-BANKL (L)
Bankkontonummer LFBK-BANKN (L) KNBK-BANKN (L)

Damit ist eine entsprechende Suche möglich.Natürlich können im Bedarfsfall auch noch weitere Datenfelder mit in die Query eingepflegt werden.

Je nach Bedarf können natürlich auch weitere Felder als Listen- oder Selektionsfelder verwendet werden. Hierdurch ist auch ein vollständiges Kreditorenverzeichnis oder Debitorenverzeichnis als ALV Liste (Tabelle) möglich. Gerade beim Export nach Excel ist dieses ein erheblicher Unterschied zu den Standardtransaktionen S_ALR_87012086 (Kreditorenverzeichnis) und S_ALR_87012179 (Debitorenverzeichnis). Insbesondere da in einer Query auch Suchen über Felder möglich sind, die in der freien Abgrenzung nicht aufgeführt sind (als Beispiel ist dieses hier ja anhand der IBAN erläutert).

Ein Vorteil der Suche über die IBAN besteht auch durch die Möglichkeit der Platzhalter. So kann über eine Suche nach AT* (Ländercode Österreich) oder CH* (Ländercode Schweiz) nach allen Kreditoren/Debitoren mit einer österreichischen oder schweizerischen Bankverbindung gesucht werden.

Berichtszuordnung FK03, FBL1N bzw. FD03, FBL5N

Innerhalb der Querypflege (SQ01) kann nun noch über SPRINGEN->BERICHTSZUORDNUNG  über den Punkt Zeile hinzufügen (+) mittels anderer Berichtstyp eine Transaktion als Absprungtransaktion von der Query hinzugefügt werden. Hier bieten sich die Transaktionen FK03 - Kreditor anzeigen bzw. FD03 - Debitor anzeigen an. Eine weitere ebenfalls sinnvolle Zuordnung wären auch die Transaktionen FBL1N - Kreditoren Konto Posten anzeigen und FBL5N - Debitoren Konto Posten anzeigen. Hierdurch können nicht nur weitere Stammdaten angezeigt werden sondern auch die Einzelposten zum Kreditor / Debitor angezeigt werden.

Basis: SE93 kundeneigene Transaktion anlegen und Query transportieren


Wie im Artikel "Transaktion anlegen (Report, Parameter) bspw. für SAP Query" beschrieben kann dann noch eine kundeneigene Transaktion zum Beispiel ZIBANK und ZIBAND für diese Query angelegt werden. Ansonsten kann die Query, wie im Artikel "Transport von SAP Queries (DL/UL)" beschrieben als Datei zwischen SAP Systemen ausgetauscht werden.

Hinweis 2016 Tabellenänderungen im Rahmen S/4 HANA Finance

Mit der Einführung von S/4 HANA haben sich verschiedene Tabellen im Bereich Finance ebenfalls verändert. So befindet sich die Angabe der IBAN nicht mehr in der Tabelle TIBAN, sondern im Feld IBAN der Tabelle FCLM_BAM_AMD.

Weitere Tabellenänderungen sind im OSS Hinweis  1976487  festgehalten und sollten beim Wechsel nach HANA ebenfalls berücksichtigt werden. Vielen Dank für den Hinweis im Beitrag "Re: Stammdaten Kreditor anzeigen inklusive IBAN als Report" auf fico-forum.de an Alferd (advor180).

 

Hinweis

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




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


Montag, 3. November 2014
19:41 Uhr

Query über verantwortliche Kostenstelle des Innenauftrag - Bestimmung der Lehreinheit im Fachbereich durch Teil der Kostenstellennummer

Wie im Artikel "ABAP Coding im Zusatzfeld für SAP Query" beschrieben wird eine Query bestehend aus Stammdaten zu CO (Innenaufträgen) und PSM-FM (Fonds inklusive Finanzierungszweck) erstellt.

Zur Erinnerung die Query besteht aus folgenden Feldern (basierend auf das Infoset im oben verlinkten Artikel).

Query Stammdatenliste Innnenaufträge und verknüpfte Fonds

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
Kostenstellentexte CSKT
Beschreibung (L) CSKT-KTEXT
Auftragsstammdaten AUFK
Profitcenter (L,S)
AUFK-PRCTR
Profit-Center-Stammdaten Texte (CEPCT)
Allgemeine Bezeichnung (L) CEPCT-KTEXT
Zusatzfelder (die im Infoset angelegt wurden)
Finanzierungszweck (L,S)  FINUSE
Auftragsstammdaten AUFK
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
Zusatzfelder (die im Infoset angelegt wurden)
Gesperrt (L)  GESPERRT
lokale Zusatzfelder

Lehreinheit  (L) 

Lokale Zusatzfeld Lehreinheit


Eine weitere Anforderung ist die Angabe der zugeordneten Lehreinheit zum Projekt. Diese soll sich aus der verantwortlichen Kostenstelle ableiten. Für die einzelnen Fachbereiche ist die Lehreinheit aus den ersten vier Ziffern der Kostenstelle ersichtlich. Teilweise gibt es jedoch einzelne Kostenstellen die einer anderen Lehreinheit zuzuordnen sind. Bei diesen soll das Feld Teletexnummer der Kostenstelle gepflegt werden. Neben den Fachbereichen sollen aber auch einzelne Einrichtungen ebenfalls einer Lehreinheit zugeordnet werden. Da es relativ mühsam wäre diese Information bei jeder Kostenstelle (oder im Innenauftrag) festzuhalten werden über die Funktionalität lokale Felder die einzelnen Fälle der Lehreinheit berechnet oder alternativ die verantwortliche Kostenstelle ausgegeben:

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:

Bei den Auftragsstammdaten:

Auftragsnummer -> AUFNR
Verantwortliche Kostenstelle -> KOSTV

Bei dem Kostenstellenstammsatz:
Teletexnummer -> TELETEX

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. Elegant wäre es natürlich, wenn wir im Infoset eine entsprechende leere Feldgruppe definiert hätten, es geht aber auch ohne.

Da sich die Lehreinheit aus der Kostenstelle berechnet sollten die folgenden Felder in der Feldgruppe Kostenstellenstammdaten angelegt werden.

1. Feld Lehreinheit aus Kostenstelle berechnen

Kurzbezeichnung KS_LE
Feldbezeichnung Lehreinheit_Kostenstelle
Überschrift LE Zuordnung Kostenstelle
Als Feldeigenschaften definieren wir die gleichen Eigenschaften wie TELETEX.

Danach legen wir eine Berechnungsvorschrift an. Dazu klicken wir auf "KOMPLEXE BERECHNUNG". Nun können wir drei Bedingungen und eine sonstige Alternative angeben.
Dieses nutzen wir wie folgt:

Bedingung
KOSTV => 10000  AND KOSTV <=19999  AND TELETEX = ''
Wobei 10000 bis 19999 für das Intervall der Kostenstellen der Fachbereiche steht. Ist also das Feld Teletex nicht gefüllt werden die ersten vier Stellen der Kostenstelle genommen.
Formel
KOSTV[3:6]*1

Bedingung
TELETEX <> ''
Formel
TELETEX

Sofern das Feld Teletexnummer gefüllt ist wird dieses in jeden Fall als Lehreinheit ausgewiesen.

Sonst:
KOSTV[3:10]*1

2. Feld Lehreinheit für bestimmte Bereiche berechnen

Das nächste lokale Feld bezieht sich dann auf bestimmte Bereiche, die ebenfalls einer Lehreinheit zugeordnet sind.
Kurzbezeichnung
BE_LE
Feldbezeichnung Lehreinheit_BE
Überschrift LE Zuordnung BE
Als Feldeigenschaften definieren wir die gleichen Eigenschaften wie KS_LE

Als Formeln können hier dann bestimmte Intervalle oder auch Einzelwerte einen Wert zugewiesen werden .

Beispiel:
Bedingung
KOSTV = 30815  AND TELETEX = ''
Formel
'LE 4321'

Sonst
''

3. Feld Lehreinheit


Das letzte lokale Feld bezieht sich dann auf die vorherigen Felder

Kurzbezeichnung
LE
Feldbezeichnung Lehreinheit
Überschrift Lehreinheit (virtuell)
Als Feldeigenschaften definieren wir die gleichen Eigenschaften wie TELETEX

Bedingung
BE_LE <> ''
Formel
BE_LE

Sonst
KS_LE

Alternativ könnten hier natürlich noch weitere Formeln hinterlegt werden.

Das Feld LE für die virtuelle Lehreinheit wird dann in der Query aufgenommen. Zur Kontrolle können natürlich auch das Feld Teletexnummer der verantwortlichen Kostenstelle ebenso wie die beiden Hilfsfelder KS_LE und  BE_LE übernommen werden.

Pflegeaufwand der virtuellen Lehreinheit

Insgesamt reduziert dieses den Pflegeaufwand zur Darstellung der virtuellen Lehreinheiten auf Kostenstellen deren Zuordnung zu einer Lehreinheit abweichend zur in der Kostenstellen verschlüsselten Nummerierung ist. Insbesondere zeigt sich hier auch der Vorteil eines sprechenden Schlüssel bei Stammdaten im Controlling.

Hinweis: Query Stammdaten CO Innenauftrag PSM-FM Fond

Dieser Artikel ist Teil einer Serie um Stammdaten von CO Innenaufträgen und PSM-FM Fonds miteinander zu verknüpfen.
  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"
Grundsätzlich ist die Erweiterung einer Query über die verantwortliche Kostenstelle und die Bestimmung der Lehreinheit im Fachbereich durch Auslesen der Kostenstelle mit lokalen Zusatzfeldern ein Weg, der jedoch den Nachteil hat, dass in jeder Query erneut eine solche Prüfung zu ergänzen wäre. Eine elegantere Lösung ist es daher schon im Infoset die "virtuelle" Lehreinheit zu ermitteln. Die dahinter liegende Methode inclusive Coding 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" ausführlich beschrieben und gleichzeitig ein gutes Beispiel dafür, wie sich Query weiter entwickeln kann.


 

Hinweis:

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




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


Montag, 3. November 2014
19:31 Uhr

SAP Query ABAP Coding im Zusatzfeld für Verknüpfung Innenauftrag und Fond bzw. Finanzierungszweck oder auch Status GESPERRT bei Innenaufträgen

Ausgangslage:
Im Artikel "Query FI Einzelposten als Belegjournal - Belegsegment (BSEG) und Belegkopf (BKPF) verknüpfen" wurde durch Thomas auf eine Möglichkeit hingewiesen eine Query über eine Zusatztabelle zu erweitern:

Kommentar von Thomas
Wirklich eine Super Anleitung!

Mir hat noch die Kontenbezeichnung gefehlt.
Das lässt sich so realisieren:
SQ02
Zusätze (F5)
Knoten: BSEG
Anlegen
Zusatztabelle -> SKAT
SPRAS = SY-LANGU
KTOPL = 'XXXX' (4stelliger Kontoplan in einfachen Hochkomma)!
Wir arbeiten nur mit einem Kontenplan. Deshalb der Festwert.
SAKNR = BSEG-HKONT
(in diesem Fall noch "intern puffern anhaken"
Jetzt ist die Tabelle unter BSEG eingebunden und das Textfeld (SKAT-TXT20 oder TXT50) kann in das Belegsegment hineingezogen werden.
Gruß
Thomas

Zwischenzeitlich habe ich mich auch ein wenig mehr mit Zusatzfeldern beschäftigt und kann nun die Anforderungen aus 2011 (siehe Artikel "SAP Query Stammdaten PSM / CO Innenauftrag") dank des Codingvorschlages eines Kollegen ebenfalls erfüllen.


Es soll eine Stammdatenliste aus den beiden Modulen CO und PSM-FM (Innenauftrag und Fond) erstellt werden. Hierbei sollen in der Liste Laufzeit des Projektes (Arbeitsbeginn und Arbeitsende aus CO) der Finanzierungszweck (ein Stammdatenfeld aus Fond) und die Information ausgegeben werden, ob dieses Projekt gesperrt ist.

Grundsätzlich sind die Tabellen bekannt in denen diese Informationen stehen. Die Stammdaten der Fonds befinden sich in der Tabelle FMFINCODE und der Innenaufträge in AUFK. Allerdings ist das Feld FMFINCODE-FINCODE   (Fond) vom Typ Char mit einer Länge von 10 Zeichen und das Feld AUFK-AUFNR (Auftragsnummer) zwar auch vom Typ Char allerdings mit einer Länge von 12 Zeichen. Somit können beide Felder nicht verknüpft werden, da diese Werte nicht übereinstimmen.

Der Systenstatus ist zwar ebenfalls in einer Tabelle gespeichert (JEST - siehe Artikel "
SAP Query: Systemstatus CO Innenauftrag") allerdings sind hier mehrere Datenzeilen je Status vorhnaden und uns interessiert eigentlich nur der Status I0043 für gesperrt. Anders als 2011 vermutet bedarf es bei der Pflege von SAP Query aber keines Entwicklerschlüssel für die Nutzung von ABAP Code, so dass hier eine Möglichkeit besteht per Coding an die relevanten Informationen zu kommen. Die Umsetzung ist in diesem Artikel unter "Zusatzfeld GESPERRT bei gesperrten Innenaufträgen" erläutert.
 

Verknüpfung von PSM-FM Stammdaten von Fonds und CO Innenaufträgen

Um dieses zu verwirklichen legen wir ein Infoset für die CO Stammdaten an analog der Beschreibung im Artikel "Query Stammdaten CO Kontrolle Verantwortliche". In der späteren Verwendung des Infosets steht jedoch nicht mehr die Kontrolle der Verantwortlichen von Kostenstelle, Profit-Center und Innenauftrag im Vordergrund, sondern die Zusatzinformationen über Systemstatus und Stammdaten aus PSM-FM.

Infoset als View über AUFK, CSKS, CSKT, CEPC und CEPCT definieren

Innerhalb der Transaktion SQ02 wird folgendes Infoset definiert. Hierfür wird als Datenquelle ein Tabellen-Join über Tabelle AUFK angelgt.
Es werden folgende Tabellen miteinander in Beziehung gesetzt:
AUFK: Auftragsstammdaten
CSKS: Kostenstellenstammsatz
CSKT: Kostenstellenelemente (für die Texte)
CEPC: Stammdatentabelle von Profit Centern
CEPCT: Profit-Center-Stammdaten Texte

Verknüpfungsbedingungen:
Die vorgeschlagenen Verknüpfungsbedingungen seitens SAP sollte hier wieder entfernt werden und folgende Verknüpfungsbedingungen definiert werden.

Folgende Tabellenfelder werden hierbei miteinander verknüpft:

AUFK-KOSTV <-> CSKS-KOSTL
Hierdurch wird die Verantwortliche Kostenstelle des Innenauftrages mit den Stammdaten der Kostenstellen verknüpft.

CSKS-KOSTL <-> CSKT-KOSTL
Hierdurch werden die Stammdaten der Kostenstelle mit der Bezeichnung der Kostenstelle verknüpft.

AUFK-PRCTR <-> CEPC-PRCTR
Hierdurch wird das Profitcenter des Innenauftrages mit den Stammdaten der Profit-Center verknüpft.

CEPC-PRCTR <-> CEPCT-PRCTR
Hierdurch werden die Stammdaten der Profit-Center mit der Bezeichnung der Profit-Center verknüpft.

Etwas ausführlicher (inklusive Verknüpfung "Kostenrechnungskreis" KOKRS und "Datum gültig bis" DATBI sind die Verknüpfungen in folgender Zeichnung dargestellt:

Darstellung JOIN über AUFK und CO Stammdaten


Damit sind alle Verknüpfungen der Tabellen erfolgt. Der Einfachheit halber können nun alle Feldgruppen/Datenfelder übernommen werden. Dieses hat den Vorteil, dass dieses Infoset auch für weitere Queries zur Verfügung steht.

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 können nicht nur wie von Thomas erwähnt Zusatztabellen in das Infoset aufgenommen werden sondern auch 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 FINUSE)  und die Art der Zusatzinformation. Neben der schon angesprochenen Zusatztabelle sind dieses: Zusatzfeld, Zusatzstruktur und Coding. In unserem Beispiel soll ein Zusatzfeld mit den Namen FINUSE angelegt werden.

Dieses hat folgende Eigenschaften: Langtext und Überschrift haben beide Finanzierungszweck 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).

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. Hier habe ich dankenswerterweise von einen Kollegen ein passendes Coding erhalten um die Bezeichnung des Fonds (FMFINT-BEZEICH), Gültigkeitsdatum des Fond (FMFINCODE-DATAB und FMFINCODE-DATBIS) sowie Schlüssel/Nummer des Fond (FMFINCODE-FINCODE) zu erhalten, sofern ein Fond angelegt ist. Dieses Coding hatte ich mir als Vorlage genommen um auch den Finanzierungszweck auszulesen.

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.

Zusatzfeld GESPERRT bei gesperrten Innenaufträgen

Als weitere Anforderung sollte in der Liste auch mitgegeben werden, ob ein Innenauftrag gesperrt ist oder nicht. Hierzu wurde ebenfalls ein Zusatzfeld angelegt. Dieses erhält als Langtext und Überschrift "Gesperrt" und die Eigenschaften Typ C (Character) und Länge, Ausgabelänge 001, da im Ergebnis nur ein X ausgegeben werden soll, wenn der Auftrag gesperrt ist. Das zugehörige Coding lautet wie folgt:

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 = 'X'.
IF sy-subrc <> 0.
GESPERRT = 'X'.
ELSE.
CLEAR GESPERRT.
ENDIF.


Die beiden Zusatzfelder können dann in eine eigene Feldgruppe ins Infoset übernommen werden und stehen damit einer Query zur Verfügung.

Bezüglich des Status eines Innenauftrages können über die ABAP Anweisung

CONCATENATE altenstring neuenstring INTO altenstring.

auch weitere Statuszustände in das Feld übernommen werden. Hierzu würde ein Feld STATUS definiert werden und über eine weitere Schleife über die Bedingung Where STAT = 'I0028' zum Beispiel das Merkmal ABRV in die Variable gespeichert werden. Die Anweisung könnte dann CONCATENATE status  ' ABRV ' INTO STATUS. lauten. Dieses war jedoch keine Anforderung für diese Liste. Ferner sind die einzelnen Phasen eines Innenauftrages auch in der Tabelle AUFK hinterlegt und könnten in der Query über ein kundeneigenes Feld verknüpft werden. Lediglich die Sperre des Innenauftrages ist hier nicht mitaufgeführt.

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'
 

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.
 

Query Stammdatenliste Innnenaufträge und verknüpfte Fonds

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
Kostenstellentexte CSKT
Beschreibung (L) CSKT-KTEXT
Auftragsstammdaten AUFK
Profitcenter (L,S)
AUFK-PRCTR
Profit-Center-Stammdaten Texte (CEPCT)
Allgemeine Bezeichnung (L) CEPCT-KTEXT
Zusatzfelder (die im Infoset angelegt wurden)
Finanzierungszweck (L,S)  FINUSE
Auftragsstammdaten AUFK
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
Zusatzfelder (die im Infoset angelegt wurden)
Gesperrt (L)  GESPERRT
lokale Zusatzfelder

Lehreinheit  (L) 

Erweiterung: Lehreinheit aus Kostenstelle ableiten

Das lokale Zusatzfeld Lehreinheit wird im Artikel "Query über verantwortliche Kostenstelle des Innenauftrag - Bestimmung der Lehreinheit im Fachbereich durch Teil der Kostenstellennummer" noch beschrieben.

Der Vorteil dieser Query ist, dass in der Selektion nicht nur anhand der Innenauftragsnummer, Auftragsart
oder der verantwortlichen Kostenstellen selektiert werden kann sondern auch über den Finanzierungszweck inklusive einer Wertauswahlhilfe (F4), so dass hier direkt die gepflegten Finanzierungszwecke ausgelesen werden können.

Bei den Finanzierungszwecken selbst handelt es sich ebenfalls um Stammdaten die unter
Rechnungswesen > Public Sector Managament > Haushaltsmanagement > Stammdaten > Kontierungselemente > Fonds > Finanzierungszweck > gepflegt werden können (Transakton FM6I - Anlegen, FM6U - Ändern und FM6S Anzeigen).

Erweiterung: Merkmale der Klassifizierung

Eine erhebliche Erweiterung dieser Query ist im Artikel "SAP Query - Auswertung Merkmale der Klassifizierung am Beispiel Fonds in PSM-FM" beschrieben. Hier wird neben den Finanzierungszweck und den CO bzw. PSM-FM Stammdaten auch die Merkmale der Klassifizierung von Haushaltsfonds ausgewertet. Damit sollten alle relevanten Stammdaten von Innenaufträgen und damit verbundenen Fonds ausgewertet werden können.
 

Erweiterung: Weitere Zusatzfelder

Wie schon erwähnt besteht auch die Möglichkeit weitere Stammdaten aus den Fonds aus PSM - FM im Infoset per Coding aufzunehmen. Einige häufig angefragten Felder habe ich im Artikel "Weitere Zusatzfelder im Infoset mit ABAP Coding zur Verwendung in SAP Query über die Tabellen AUFK und FMFINCODE" beschrieben. Teilweise wurde hier auch das Coding der in diesen Artikel beschriebenen Felder noch optimiert.
 

Hinweis: Query Stammdaten CO Innenauftrag PSM-FM Fond

Dieser Artikel ist Teil einer Serie um Stammdaten von CO Innenaufträgen und PSM-FM Fonds miteinander zu verknüpfen.
  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"

Eine Erweiterung des hier vorgestellten Coding hin zur Verwendung einer Zusatztabelle für die Einbindung der PSM-FM Stammdaten wie Finanzierungszweck 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" 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.




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


Samstag, 5. April 2014
10:49 Uhr

Abgleich Belege in CO auf Profit-Center mit zeitabhängigen Stammdaten der Anlagenbuchhaltung bei Investitionen

Ausgangslage

Innerhalb der Anlagenbuchhaltung wurde ein Anlagenstammsatz über die Transaktion AS01 mit zeitabhängiger Zuordnung auf einen Innenauftrag angelegt.

Exkurs: Vorraussetzung für das Buchen auf Innenaufträgen in der Anlagenbuchhaltung

Hierzu muss die Integration mit der Hauptbuchhaltung im Customizing der Anlagenbuchhaltung aktiviert sein. Dieses ist innerhalb der Transaktion SPRO  unter folgenden Pfad möglich:

  • Finanzwesen
  • Anlagenbuchhaltung
  • Integration mit dem Hauptbuch
  • Mitzubuchende Kontierungsobjekte aktivieren
  • Kontierungsobjekte aktivieren

Hier kann das Kontierungsobjekt CAUFN Innenauftrag auf aktiv gesetzt werden.Ferner muss unterhalb des Knoten "Integration mit dem Hauptbuch" auch die "Feldstatusvariante der Anlagenbuchhaltung" die Kontierungsobjekte als Feldstatus für die Buchungsschlüssel 70 Anlagen-Soll und 75 Anlagen-Haben eingeblendet werden, da andernfalls für Buchungen diese  nicht angezeigt werden. Die entsprechende Feldstatusgruppe ist in den Sachkonten der Anlagenbuchhaltung innerhalb der Transaktion FS00 - Sachkonto anzeigen in der Registarkarte ERfassung/Bank/Zins in der Gruppe "Steuerung der Belegerfassung im Buchungskreis" ersichtlich. Von hier aus können auch die einzelnen Felder unter den Punkt "Zusatzkontierung" auf Ausblenden, Musseingabe oder Kanneingabe gesetzt werden. Hier sollte das Feld CO/PP Auftrag ebenso wie Profitcenter auf "Kanneingabe" gesetzt werden.

Bei der Erfassung der Rechnung zur Anlage kann es zu zwei Fehlern kommen.

a) Vergessen des Innenauftrages in Belegposition Anlagenaktivierung
Später wurde eine Kreditorenrechnung gegen die Anlage gebucht. Hierbei wurde die Belegposition (Buchungsschlüßel 31 - kreditorische Rechnung) gegen den Kreditor bei der Erfassung der Anlagenaktivierung (Buchungsschlüssel 70 - Anlagen-Haben , Bewegungsart 100, Konto = Anlagennummer) jedoch versäumt das Feld Auftrag zu füllen. Hierdurch erfolgt zwar eine Buchung eines Profit-Center-Beleges angelegt, der Beleg der Finanzbuchhaltung weist jedoch weder Kostenstelle noch Innenauftrag aus.

b) Angabe eines abweichenden Innenauftrages
Eine weitere Fehlerquelle kann die Angabe eines abweichenden Innenauftrages zum Anlagenstamm sein. Sofern dieser Innenauftrag vom Profit-Center der verantwortlichen Kostenstelle abweicht kommt es zu einer Warnmeldung in der Form "Profit-Center wird neu gesetzt ...", Handelt es sich jedoch um einen Auftrag der ebenfalls am gleichen Profit-Center hängt kann dann der Beleg der Finanzbuchhaltung eine abweichende Kontierung in der Belegposition enthalten, da hier ein anderer Innenauftrag als im Anlagenstamm hinterlegt ist.

Auswirkung Abweichung CO Belege zu Stammdaten Anlagenbuchhaltung

Bei aktivierter statistischer Fortschreibung von Investitionen ergibt sich bei der Auswertung auf Basis der Profit-Center eine Abweichungen zwischen der Profit-Center-Rechnung und der Innenauftragsrechnung. So weist eine Auswertung von Profit-Center-Belegen andere Salden je Innenauftrag aus  im Vergleich zu einer Auswertung aller Innenaufträge des jeweiligen Profit-Center. Entsprechend könnte es im Fall b) auch zu einer abweichenden Darstellung innerhalb des SAP Moduls PSM-FM geben. Im Fall a) scheint eine Fortschreibung nach PSM-FM tatsächlich am entsprechenden Fond zu erfolgen.

Eine Auswirkung auf die Bilanz / GuV ist nicht gegeben, da hier die Sachkonten direkt und nicht auf Basis von Kostenstellen und Innenaufträge ausgewertet werden.

Eine mögliche Lösung für dieses Problem, wäre eine Übernahme des Feld Innenauftrag als Vorschlagswert aus den Anlagenstamm in das manuell zu pflegende Feld in der Position der Anlagenaktivierung (Buchungsschlüssel 70, Bewegungsart 100, Konto = Anlagennummer). Dieses funktioniert im Standard schon bei der Kostenstelle, wobei diese nicht übertragen wird, wenn im Anlagenstamm ein Innenauftrag hinterlegt ist. Leider scheint es, meines Wissens nach, keine derartige Möglichkeit im Standard vorhanden zu sein.

Lösung:
Daher bleibt nur die Möglichkeit des Abgleich der CO-Belege mit den vorhandenen Daten innerhalb der Anlagenbuchhaltung. Wie im Artikel "Lebensweg einer Anlage oder Query über zeitabhängige Stammdaten einer Anlage" erläutert werden die zeitabhängigen Daten der Anlagenbuchhaltung in der Tabelle ANLZ "Valutierte Anlagen-Zuordnungen" gespeichert. Die Einzelposten der Profit-Center-Rechnung sind in der Tabelle GLPCA "EC-PCA: Ist-Einzelposten" zu finden. Innerhalb des Profit-Center-Beleges sind auch die Informationen zum Innenauftrag beziehungsweise der Kostenstelle der Buchung zu finden. Entsprechend bietet es sich an, diese Tabellen in einer Query miteinander zu verknüpfen und ein Kontrollfeld bei Abweichung zwischen Buchung der Rechnung und der im Anlagenstamm hinterlegten Kontierung zu ermöglichen.

Query Abgleich Investitionen aus Profit-Center-Beleg mit hinterlegter Kontierung aus zeitabhängige Stammdaten der Anlagenbuchhaltung

Hierzu sind folgende Schritte erforderlich:

1. Infoset anlegen

Bei der Anlage eines Infosets über die Transaktion SQ02 wird als Datenquelle unter Tabellen-Join  über Tabelle die Tabelle GLPCA angegeben. In den weiteren Schritten können die anderen Tabellen über  BEARBEITEN->Tabelle einfügen  ergänzt werden.
Die angesprochenen Tabellen werden dabei wie folgt verknüpft. Die Angabe der Tabellen erfolgt in der Reihenfolge, wie diese auch bei der Infoset Anlage ergänzt werden. Bei den Verknüpfungen handelt es sich um eine "normale" Verknüpfung. Dieser ist mit <--> angegeben.

Zur Darstellung der Bewegungsarten werden die beiden Tabellen GLPCA ("EC-PCA: Ist-Einzelposten") und TABWT ("Bewegungsartentexte der Anlagenbuchhaltung") über die Felder Anlagenbewegungsart miteinander verknüpft.

GLPCA-ANBWA<--> TABWT-BWASL

Für die Zuordnung von CO-Beleg und Anlagenstamm werden die beiden Tabellen GLPCA und ANLZ ("Valutierte Anlagen-Zuordnungen") miteinander über die Felder Buchungskreis, Anlagen-Hauptnummer (ANLN1) und Anlagen-Unternummer (ANLN2) verknüpft.

GLPCA-RBUKRS <--> ANLZ-BUKRS
GLPCA-ANLN1<--> ANLZ-ANLN1
GLPCA-ANLN2<--> ANLZ-ANLN2

In den einzelnen Feldgruppen werden dann alle Felder der Tabellen GLPCA und TABWT übernomen. Bei der Feldgruppe über die Tabelle ANLZ kann sich auf folgende Felder beschränkt werden:
ANLZ-BDATU - Datum Gültigkeitsende
ANLZ-ADATU - Datum Gültigkeitsbeginn
ANLZ-ANLN2 - Anlagenunternummer
ANLZ-ANLN1 - Anlagen-Hauptnummer
ANLZ-KOSTL - Kostenstelle
ANLZ-CAUFN - Innenauftrag
ANLZ-KOSTLV - Verantwortliche Kostenstelle der Anlage

Diese Vorgehensweise ist auch schon im Artikel "Lebensweg einer Anlage oder Query über zeitabhängige Stammdaten einer Anlage" beschrieben. Wobei hier keine einzelnen Tabellen sondern eine logische Datenbank der Finanzbuchhaltung (bzw. Anlagenbuchhaltung) genutzt wurde.
 

2. Query definieren


In der Querydefiniton besteht die Möglichkeit über die im Infoset hinterlegten Felder der tabellen weitere Informationen zu hinterlegen und in der Grundliste entsprechend auszuwerten. Hierfür wird innerhalb der Query mit lokalen Feldern gearbeitet.

2.1 Lokale Zusatzfelder anlegen

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):

Feldgruppe EC-PCA: Ist-Einzelposten (GLPCA
  • Betrag in Profit-Center-Hauswährung - KSL (GLPCA-KSL)
  • Buchungsdatum im Beleg - BUDAT (GLPCA-BUDAT)
  • Kostenstelle - KOSTL (GLPCA-KOSTL)
  • Auftragsnummer - AUFNR (GLPCA-AUFNR)
Feldgruppe Valutierte Anlagen-Zuordnungen (ANLZ)
  • Datum Gültigkeitsende - BDATU (ANLZ-BDATU)
  • Datum Gültigkeitsbeginn - ADATU (ANLZ-ADATU)
  • Kostenstelle - ANLZ_KOSTL (ANLZ-KOSTL)
  • Innenauftrag - ANLZ_CAUFN (ANLZ-CAUFN)
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. In unseren Fall also ebenfalls in der Feldgruppe der Tabelle ANLZ bzw. der Bezeichnung der Feldgruppe "Valutierte Anlagen-Zuordnungen".

In dieser Query werden vier lokale Felder mit folgenden Eigenschaften angelegt.

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. Entsprechend ist ein lokales Feld für die Ermittlung des Wertes mit folgenden Eigenschaften angelegt:

1. lokales Feld (WERT)
Kurzbezeichnung:  WERT
Feldbezeichnung: Berichtswert
Überschrift: Berichtswert
Eigenschaften:
Gleiche Eigenschaften wie Feld:  KSL
Berechnungsvorschrift:
Hier wird eine komplexe Berechnung mit folgenden Bedingungen hinterlegt:
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. lokales Feld (KS)
Kurzbezeichnung:  KS
Feldbezeichnung: Kostenstelle
Überschrift: Kostenstelle
Eigenschaften:
Gleiche Eigenschaften wie Feld:  KOSTL
Berechnungsvorschrift:
Hier wird eine komplexe Berechnung mit folgenden Bedingungen hinterlegt:
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. Dieser Fall sollte jedoch nicht auftreten, da die Übertragung der Kostenstelle bei Buchung auf eine Anlage im Standard funktioniert und lediglich beim Weglassen des Innenauftrages das Feld im CO Beleg nicht gefüllt ist.

3. lokales Feld (IA)
Kurzbezeichnung:  IA
Feldbezeichnung: Innenauftrag
Überschrift: Innenauftrag
Eigenschaften:
Gleiche Eigenschaften wie Feld:  AUFNR
Berechnungsvorschrift:
Hier wird eine komplexe Berechnung mit folgenden Bedingungen hinterlegt:
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. Hierdurch würde der eingangs erwähnte Buchungsfehler "a) Vergessen des Innenauftrages in Belegposition Anlagenaktivierung" innerhalb dieser Auswertung behoben, da der Innenauftrag nun aus den Anlagenstamm ausgewertet würde.

4. lokales Feld (CHK)
Kurzbezeichnung:  CHK
Feldbezeichnung: Kontrolle
Überschrift: Kontrolle
Eigenschaften:
Ikone
Durch die Eigenschaft Ikone kann ein entsprechendes Icon ausgegeben werden. Diese sind entweder in der Tabelle ICON ersichtlich oder können als Liste über die Transaktion ICON ausgegeben werden.

Berechnungsvorschrift:
Hier wird eine komplexe Berechnung mit folgenden Bedingungen hinterlegt:
Bedingung: WERT <> 0 AND AUFNR > 0 AND ANLZ_CAUFN <> AUFNR
Formel: ICON_LED_RED

Bedingung: WERT <> 0 AND ANLZ_CAUFN > 0 AND ANLZ_CAUFN <> AUFNR
Formel: ICON_LED_YELLOW

Sofern der Innenanauftrag des CO-Beleges vom Innenauftrag des Anlagenstamms zum Zeitpunkt der Buchung abweicht wird eine rote Ampel ausgegeben (ICON_LED_RED), ist im CO Beleg kein Auftrag angegeben, jedoch im Stammsatz der Anlage ein Innenauftrag zum Zeitpunkt der Buchung hinterlegt (in der Regel ist dieses der Fall, wenn weder Innenauftrag noch Kostenstelle im CO-Beleg vorhanden sind, wird eine gelbe Ampel (ICO_LED_YELLOW) ausgegeben. Die Prüfung erfolgt jedoch nur in den Fällen, da das Feld WERT gefüllt ist (und Buchungsdatum und Anlagenstammsatz miteinander übereinstimmen.

2.2 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 angeben, wie diese dann auch in der Query ausgegeben werden sollen:



Tabelle GLPCA "EC-PCA: Ist-Einzelposten"
Jahr (L,S)  GLPCA-RYEAR
Soll-/Haben-Kennzeichen  (L,S) GLPCA-DRCRK
Profitcenter (L,S) GLPCA-RPRCTR
Anlage (L,S) GLPCA-ANLN1
Unr. (L) GLPCA-ANLN2
Anlagen-Bewegungsart (L,S) GLPCA-ANBWA

Tabelle TABWT  "Bewegungsartentexte der Anlagenbuchhaltung"
Bezeichnung Anlagenbewegungsart  (L) TABWT-BWATXT
Sprachenschlüssel (S) TABWT-SPRAS
Der Sprachenschlüssel sollte selektiert sein, damit nicht für jede gepflegte Sprachversion die Daten erneut ausgegeben werden.

Tabelle GLPCA "EC-PCA: Ist-Einzelposten"
Konto (L,S) GLPCA-RACCT
Betrag in Profit-Center-Hauswährung  (L) GLPCA-KSL   
Hierbei ist in den Währungsfeldoptionen kein Währungsfeld aktiviert
Buchungsperiode (L,S) GLPCA-POPER
Buchungsdatum im Beleg (L) GLPCA-BUDAT


Tabelle ANLZ "Valutierte Anlagen-Zuordnungen"
Gültig ab (L) ANLZ-ADATU
Gültig bis (L) ANLZ-BDATU
Anlage (L) ANLZ-ANLN1
UNr. (L) ANLZ-ANLN2
ANLZ_KOST (L) ANLZ-KOSTL "Kostenstelle nach Anlagenstamm"
ANLZ_CAUFN (L) ANLZ-CAUFN "Innenauftrag nach Anlagenstamm"
ANLZ_VKOST (L) ANLZ-KOSTLV   "Verantwortliche Kostenstelle der Anlage"


Tabelle GLPCA "EC-PCA: Ist-Einzelposten"
GLPCA_KOSTL (L) GLPCA-KOSTL "Kostenstelle CO Beleges"
GLPCA_AUFNR  (L) GLPCA-AUFNR "Innenauftrag CO Beleg"

Lokale Zusatzfelder
Kostenstelle (L) KS
Innenauftrag (L) IA
Berichtswert (L) WERT
Hierbei ist in den Währungsfeldoptionen kein Währungsfeld aktiviert
Kontrolle (L) CHK

3. Query ausführen

Zum Ausführen der Query ist dann darauf zu achten, dass die entsprechenden Sachkonten der Anlagenbuchhaltung im Feld Konto eingetragen werden und bei den Anlagenbewegungsarten mögliche Zugangsarten (bspw. 100 Zugang) hinterlegt sind. 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.

Qualitätssicherung


Sofern die Auswertung tatsächlich der Qualitätssicherung und damit einen direkten Vergleich der CO Belege und der Anlagenstammsätze beinhaltet, ist es empfehlenswert die erhaltene ALV Liste (Einzelpostenliste) nach  der Anlagennummer zu gruppieren (Zwischensumme zu bilden). Dieses hat den Vorteil, dass man anhand der gelben oder roten Ampel (eigentlich LED) direkt sieht, ob eine Abweichung noch vorliegt, oder ob die entsprechenden Belege in der Folgezeile schon korrigiert sind (hier sollten sich die Beträge zu 0 saldieren).

Auswertung Investitionen

Sofern die verwendeten Berichte, zum Beispiel Kontoauszug, auf PSM-FM basieren und daher eine Kontrolle obsolet ist eigent sich auch der Artikel "Zusammenfassung Query über Anlagenzugang - Auswertung Investitionen aus Profit-Center-Rechnung" aus 2015 für eine direkte Auswertung der Sachinvestionen aus der Profit-Center-Rechnung mit Ausgabe der CO-Kontierung (Innenauftrag und Kostenstelle) entweder durch den Profit-Center-Beleg oder aus den Anlagenstammsatz. :-) Hier zeigt sich auch im Blog eine entsprechende Entwicklung zwischen den Artikeln.
 

Hinweis:

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




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


Dienstag, 25. März 2014
21:24 Uhr

Auflösen von Stammdatengruppen nach Einzelwerten - Einzelwerte zu Sets

Ausgangslage:

Es sollen die zugeordneten Werte einer Stammdatengruppe (zum Beispiel einer Innenauftragsgruppe) ausgewertet werden um diese in einer weiteren Auswertung zu verwenden. Sofern nicht nur die bebuchten Kostenträger (wo sich ein entsprechender Report Writer Bericht mit einer Spalte Innenaufträge und einer Spalte Kosten anbieten würde) sondern alle Stammdaten aufgelistet werden sollen gibt es, neben der Möglichkeit von Copy & Paste bzw. den Export von Stammdatengruppen zwei möglicherweise elegantere Methoden.

Ein Bericht in der Form "Zeige alle Innenaufträge der Gruppe KLR und die jeweiligen Untergruppen mit entsprechenden Aufträgen" ist im Standard leider nicht vorgesehen. Daher bieten sich neben den Standardberichten in SAP folgende Möglichkeiten an:

Auswertung über die Transaktion SE16H

Entweder kann die entsprechende Datenbanktabelle (im Fall der Innenaufträge wäre dieses AUFK) mit der neuen Transaktion SE16H ausgewertet werden. Die neue allgemeine Tabellenanzeige bietet eine Selektion über die einzelnen Datenfelder (Feldnamen) einer Tabelle an und kann hierfür nicht nur Intervalle (Von-Wert und Bis-Wert) sondern auch  Gruppen (Sets) als Auswertungsgröße verwenden.

Hintergrund Transaktion SE16H SAP

Mit SAP HANA (neues Datenbankmodell der SAP SE) wurde eine neue Transaktion eingeführt, die zum direkten Auswerten von Tabellen geeignet ist und eine etwas komplexere Möglichkeit als die SE16 bietet. Diese Transaktion ist auch ausgerollt, wenn noch kein HANA eingeführt wurde.
Durch diese Transaktion können Sets (Gruppen) von Tabellenfeldern ausgewertet werden. Noch schöner sind die Zusatzfunktionen wie Gruppieren!
Weitere Informationen dazu bietet der SAP Hinweis 1636416 CO-OM Tools: Funktionsweise der SE16H (20.07.2012)


Dieses ermöglicht zum Beispiel eine Auswertung der Tabelle AUFK über das Feld AUFNR mit der Möglichkeit anstatt eines Intervalls (oder Einzelwerte) in der Spalte Gruppe eine bestimmte Innenauftragsgruppe auszuwerten und alle zugeordneten Innenaufträge zu erhalten. Daneben besteht auch die Möglichkeit einer Auswertung über weitere Felder und die dort vorhandenen Gruppen, so kann die Tabelle AUFK über das Feld KOSTV  ausgewertet werden und damit ist es möglich hier nicht nur einzelne Kostenstellen einzutragen sondern auf die Kostenstellen einer bestimmten Kostenstellengruppe zuzugreifen. Auf diese Weise ist eine Auswertung aller Innenaufträge der Kostenstellengruppe GEB (Gebäude) problemlos möglich.

Allerdings setzt das Auswerten von Datenbanktabellen zumindest Kenntnisse der entsprechenden Tabellen im System voraus.

Auswertung von Stammdatengruppe per Query

Sofern es bei der Auswertung der einzelnen Werte einer Stammdatengruppe nur um den Wert und nicht um nähere Beschreibung geht besteht auch die Möglichkeit über eine Query die Sets (Gruppen) von Stammdaten auszuwerten.

Stammdatengruppen (oder Sets) werden in den Tabellen SETNODE, SETHEADER und SETLEAF gespeichert.

In der Tabelle SETHEADER werden die einzelnen Knoten innerhalb einer Hierarchie beschrieben. In dieser Tabelle sind auch die Informationen über die anlegende Personen und letzten Änderer zu finden.

Die Tabelle SETNODE stellt die Beziehung zwischen den einzelnen Knoten da. Hierbei werden stets die untergeordneten Knoten zu einer Gruppe aufgeführt.

In der Tabelle SETLEAF befinden sich wiederum die einzelnen Werte eines Sets.

Je nach auszuwertenden Objekt ist in allen drei Tabellen die Klasse eines Sets mit angegeben. Dieses können unter anderen folgende Klassen sein:
  • 0101 Kostenstellengruppe
  • 0102 Kostenartengruppe
  • 0103 Auftragsgruppe
  • 0106 Profit-Center-Gruppe
  • 0109 Kontengruppe
  • 0111 Fondsgruppe
  • 0311 Finanzpositionengruppe
  • 0312 Finanzstellengruppe
Um nun eine Auswertung über eine Stammdatengruppe zu ermöglichen würde der oberste Knoten ausgewertet werden und die untergeordneten Knoten mit ihren zugeordneten Werten ausgewertet werden.

Um nicht jede Tabelle einzeln auszuwerten bietet sich hier ebenfalls eine Query mit Verknüpfung dieser Tabellen an.

1.) Infoset definieren
Bei der Anlage eines Infosets über die Transaktion SQ02 wird als Datenquelle unter Tabellen-Join  über Tabelle die Tabelle SETNODE angegeben. In den weiteren Schritten können die anderen Tabellen über  BEARBEITEN->Tabelle einfügen  ergänzt werden.


Die angesprochenen Tabellen werden dabei wie folgt verknüpft.

Die Angabe der Tabellen erfolgt in der Reihenfolge, wie diese auch bei der Infoset Anlage ergänzt werden. Bei den Verknüpfungen handelt es sich um eine "normale" Verknüpfung. Dieser ist mit <--> angegeben.

Zur Darstellung der Hierarchie werden die Oberknoten aus der Tabelle SETNODE "
Untergeordnete Sets in Sets" und SETHEADER "Setkopf und Setverzeichnis" entnommen:

SETNODE-SETCLASS <--> SETHEADER-SETCLASS
SETNODE-SUBSETNAME <--> SETHEADER-SETNAME

Die Bezeichnung der einzelnen Sets werden aus den Tabellen SETHEADER und SETHEADERT "Kurzbeschreibung zu Sets" entnommen.

SETHEADER-SETCLASS <--> SETHEADERT-SETCLASS
SETHEADER-SETNAME <--> SETHEADERT-SETNAME

Die einzelnen Werte innerhalb eines Sets werden aus der Verknüpfung der Tabelle SETHEADER und SETLEAF "Werte in Sets" entnommen.

SETHEADER-SETCLASS <--> SETLEAF-SETCLASS
SETHEADER-SETNAME <--> SETLEAF-SETNAME

Schematisch sieht dabei das Infoset wie folgt aus:

Darstellung der Verknüpfung von SETNODE, SETHEADER und SETLEAF
Da im Feld SETCLASS die Klassen eines Sets hinterlegt sind, ist dieses Feld für alle Tabellen relevant. Hintergrund ist, dass ein Gruppenname sowohl als Profit-Center-Gruppe als auch als Kontengruppe vorhanden sein könnte.

2.) Query definieren
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 SETNODE "Untergeordnete Sets in Sets":
Klasse eines Sets (S) SETNODE-SETCLASS

Zusatzfelder:
Text: Klasse eines Sets (L) TEXT_SETNODE_SETCLASS

Tabelle SETNODE "Untergeordnete Sets in Sets":
Setname (Obergruppe) (L,S) SETNODE-SETNAME

Tabelle SETHEADER "Setkopf und Setverzeichnis"
Setname (L) SETHEADER-SETNAME

Tabelle SETHEADERT "Kurzbeschreibung zu Sets
Beschreibung (L) SETHEADERT-DESCRIPT

Zusatzfelder:
Text:Feld OPTION im Aufbau der SELECT-OPTIONS-Tabellen (L)
TEXT_SETLEAF_VALOPTION
Hier sollte entweder "Between: Intervall" oder "Equal: Einzelwert" ausgegeben werden.

Tabelle SETLEAF "Werte in Sets"
Option (L) SETLEAF-VALOPTION
Alternativ bietet sich hier das Tabellenfeld SETLEAF-VALOPTION an wo anhand der Werte BT oder EQ Intervalle und Einzelwerte unterschieden werden.

Tabelle SETLEAF "Werte in Sets"
Von Wert (L) SETLEAF-VALFROM
Bis Wert (L) SETLEAF-VALTO

Anpassung der Selektionsvariablenbezeichnung
Innerhalb der Transaktion SQ01 können die einzelnen Selektionsvariablen über den Menüpunkt SPRINGEN->FELDAUSWAHL->SELEKTIONEN eine entsprechende Bezeichnung im Selektionsbild der Query erhalten. Hier ist es sinnvoll der Selektionsvariable Setname die Bezeichnung "Setname (Obergruppe)" zu geben, damit beim Start der Query klar ist, dass nur solche Gruppen ausgewertet werden, die auch eine entsprechende Obergruppe haben.

3.) Query ausführen
Beim Start der Query werden nach SETNAME und die Klasse eines Sets gefragt. Hierbei kann über die F4 Auswahlhilfe ein entsprechendes Set ausgewählt werden. Soll nun zum Beispiel die Innenauftragsgruppe KLR mit ihren Untergruppen KLR-DM, KLR-GEB, KLR-VERWALTUNG etc. ausgewertet werden kann als Setname die Gruppe KLR und als Klasse eines Sets die 0103 (für Auftragsgruppen) angegeben werden.

Die Auswertung erfolgt dann über alle Gruppen, die sich unterhalb der angesprochenen Obergruppe befinden. Daher wird diese auch als Obergruppe mit ausgegeben. In der Query erscheinen dann die Art der Stammdatengruppe (Text der Klasse eines Sets zum Beispiel Kontengruppe), die Obergruppe (im Beispiel KLR), die Untergruppe (im Beispiel KLR-GEB), die Bezeichnung der Gruppe (KLR Gebäude) und das Intervall der hinterlegten Innenaufträge (als Von Wert und Bis Wert). Sofern in der Gruppe keine Intervalle sondern Einzelwerte gepflegt sind erscheint der Innenauftrag sowohl in der Spalte "Von Wert" als auch unter "Bis Wert".
Sinnvollerweise wird daher im Feld Option SETLEAF-VALOPTION bzw. TEXT_SETLEAF_VALOPTION  angegeben, ob es sich hierbei um Einzelwerte (EQ - Equal: Einzelwert) oder Intervall (BT - Between: Intervall) handelt.

Hierbei ist jedoch zu beachten, dass nur die direkt der Obergruppe zugeordneten Untergruppen und ihre Werte ausgewertet werden. Um mehrere Gruppen auszuwerten kann, wie in anderen Berichten auch, die Mehrfachselektion verwendet werden.
Neben der Benennung einer bestimmten Gruppe können auch Platzhalter wie * verwendet werden. Erfolgt die Angabe von * im Setnamen werden sämtliche angelegte Gruppen mit gepflegten Einzelwerten angegeben (für das Beispiel der Gruppen KLR würde sich ein Auswertungsmuster in der Form KLR* anbieten). Ein Anwendungsfall hierfür ist zum Beispiel die Auswertung aller Kontengruppen beginnend mit IKR-5* oder IKR-6* zur Auswertung der Aufwands und Ertragskonten.
 

Anpassung der Query / Weitere Anwendungsgebiete

Die vorgestellte Query funktioniert nur bei Gruppen, die in anderen Gruppen (einer HIerarchie) verwendet werden. Um eine Query zu erhalten, die einzelne Gruppen auswertet kann es sinnvoll sein ein zweites Infoset ohne Verwendung der Tabelle SETNODE analog des hier vorgestellten Infoset aufzubauen. Die Query würde dann als Selektionsfelder folgende Felder verwenden:

Tabelle SETHEADER "Setkopf und Setverzeichnis"
Setname (L, S) SETHEADER-SETNAME
Klasse eines Sets (S) SETHEADER-SETCLASS

Zusatzfelder:
Text: Klasse eines Sets (L) TEXT_SETHEADER_SETCLASS

Hierdurch ist neben einer Auswertung von Gruppen mit Obergruppen auch die Auswertung von einzelnen Gruppen ohne entsprechende Unter- oder Obergruppen möglich.

Einschränkung der Nutzung

Beide Queries funktionieren jedoch nur bei relativ flachen Hierarchien bzw.identischen Gruppennamensbezeichnungen. Die vollständige Auswertung ganzer Gruppen (zum Beispiel der Standardhierarchie) scheitert schon daran, wenn in einzelnen Gruppen kein Wertintervall vorhanden ist und diese Gruppe dann nicht eine Bezeihung innerhalb SETNODE vorhanden hat bzw. innerhalb der Tabelle SETLEAF dann auch kein Eintrag vorhanden ist. Sollen jedoch nur Gruppen mit gepflegten Werten ausgewertet werden bietet sich die Auswertung über Query an, andernfalls sollten die Tabellen wie eingangs beschrieben einzeln ausgewertet werden und innerhalb Excel dann über SVERWEIS oder vergleichbare Funktionen eine Verknüpfung hergestellt werden. .

Auch bei der Auswertung von Stammdatengruppen ist oftmals die Frage, welche Stufe der Auswertungsmöglichkeiten erreicht werden soll und wie viel Aufwand in eine solche Auswertung gesteckt werden soll. In beiden Fällen (sowohl per Query als auch per Auslesen von Tabellen) dürfte die Aufbereitung jedoch leichter fallen als per Export nach Excel aus der Gruppenansicht über die entsprechenden Transaktionen wie KOH3, KSH3, KCH3, KAH3, KDH3, FM_SETS_FUND3, FM_SETS_FICTR3 oder FM_SETS_FIPEX1. Wobei innerhalb des Moduls PSM-FM darüberhinaus auch noch das Problem gegeben ist, dass neben der Möglichkeit hier Gruppen zu pflegen auch die übergeordneten Kontierungselemente die entsprechende Stammdatenhierarchie bilden. Hier wäre dann eine Auswertung über die Felder übergeordnete Finanzstelle oder Finanzposition erforderlich. Innerhalb der Fonds ist eine solche Hierarchie jedohc nicht gegeben, so dass hier ebenfalls mit Gruppen gearebtet werden kann.

Weitere Möglichkeiten der Auswertung von Stammdaten sind unter anderen in den Artikeln Query Kontenplan für Module CO, FI und PSM (für einen Kontenplan über Kostenarten, Sachkonten und Finanzpositionen), Query Abrechnungsvorschriften Innenauftrag oder auch SAP Query: Systemstatus CO Innenauftrag 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.




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


Samstag, 8. März 2014
13:03 Uhr

Lebensweg einer Anlage oder Query über zeitabhängige Stammdaten einer Anlage

Ausgangslage
Im Artikel "Query Anlagenbuchhaltung (Inventarliste) über logische Datenbank ADA" wurde schon eine Möglichkeit dargestellt eine Inventurliste aller vorhandenen Anlagen inklusive ihrer Werte und Standortdaten anzugeben.

Allerdings kann sich im Laufe der Zeit der Anlagenstamm auch von der Kontierung her ändern. So kann innerhalb der Transaktion AS03 (Anlagenstamm anzeigen) im Registerblatt "Zeitabhängig" über den Button "Weitere Intervalle" eine Übersicht der Zeitintervalle angezeigt werden in der sich Änderungen des Standorts aber auch Änderung der Innenaufträge nachvollziehen.

Diese Vorgehensweise ist jedoch relativ mühsam, weswegen eine ALV Liste beziehungsweise eine Query hier schneller zum Ziel führen kann.

Lösung
Die zeitabhängigen Daten einer Anlage sind in der Tabelle ANLZ "Valutierte Anlagen-Zuordnungen" zu finden. Über die Felder ADATU (Datum Gültigkeitsbeginn) und BDATU (Datum Gültigkeitsende) sind in dieser Tabelle Standortdaten ebenso wie Finanzierung (Kostenstelle und Innenauftrag) hinterlegt.

Um die Historie einer Anlage darzustellen kann als Infoset einer Query wiederum die logische Datenbank ADA verwendet werden.
  • Exkurs
    Die Struktur einer logischen Datenbank kann in der Transaktion SE36 eingesehen werden. Hier sind auch die einzelnen Komponenten für die logische Datenbank ADA einzusehen.

    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.
Bei einer Query über die Historie einer Anlage sollten nur die Stammdaten ausgelesen werden, da bei einer wertbetrachtung hier Doppelungen auftreten können, wenn an dieser Anlage zeitlich Daten geändert haben (Beispiel Wert der Anlage 100 ist sowohl am Standort A als auch am Standort B vorhanden, obgleich die Anlage zum jeweiligen Zeitpunkt nur einmal vorhanden war und ist).


Daher sollten folgende Werte ins Infoset über die logische Datenbank ADA übernommen werden (beziehungsweise später in der Query verwendet werden).

1.) Infoset anlegen

Basierend auf die logische Datenbank ADA wurden folgende Werte in Feldgruppen entsprechend der vorhandenen Struktur übernommen


Aus der Struktur ANLAV "Anlagenreporting: ANLA-Felder ergänzt um Kst, ..."

ANLAV-BUKRS Buchungskreis
ANLAV-ANLKL Anlagenklasse
ANLAV-ANLN1 Anlagen-Hauptnummer
ANLAV-ANLN2 Anlagenunternummer
ANLAV-KTOGR Kontenfindung
ANLAV-AKTIV Aktivierungsdatum der Anlage
ANLAV-DEAKT Deaktivierungsdatum
ANLAV-ORD41 Ordnungsbegriff 1
ANLAV-LIFNR Kontonummer des Lieferanten bzw. Kreditors
ANLAV-MENGE Menge
ANLAV-INVNR Inventarnummer
ANLAV-TXT50 Bezeichnung der Anlage
ANLAV-KOSTL Kostenstelle
ANLAV-STORT Standort der Anlage
ANLAV-CAUFN Innenauftrag
ANLAV-RAUMN Raum
ANLAV-KOSTLV Verantwortliche Kostenstelle der Anlage


Dieses dient der aktuellen Daten der Anlage.

Aus der Tabelle ANLZ "Valutierte Anlagen-Zuordnungen"

ANLZ-KOSTLV Verantwortliche Kostenstelle der Anlage
ANLZ-RAUMN Raum
ANLZ-CAUFN Innenauftrag
ANLZ-STORT Standort der Anlage
ANLZ-KOSTL Kostenstelle
ANLZ-ADATU Datum Gültigkeitsbeginn
ANLZ-BDATU Datum Gültigkeitsende
ANLZ-ANLN1 Anlagen-Hauptnummer
ANLZ-ANLN2 Anlagenunternummer


Damit sind sowohl die aktuellen Werte (aus der Struktur ANLAV) als auch die historischen Werte (aus der Tabelle ANLZ) auswertbar.

2.) Query anlegen

Innerhalb der Query werden nun auf folgende Felder 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 in der Query ausgegeben werden sollen:



ANLAV - Anlagenreporting: ANLA-Felder ergänzt um Kst, ...
Buchungskreis (S) ANLAV-BUKRS
Anlagenklasse (S) ANLAV-ANLKL
Kostenstelle (S) ANLAV-KOSTL
Verantwortliche Kostenstelle der Anlage (S) ANLAV-KOSTLV
Standort der Anlage (S) ANLAV-STORT
Deaktivierungsdatum (S) ANLAV-DEAKT


Besonders das Feld Deaktivierungsdatum ist hilfreich um nur vorhandene Anlagen zu selektieren. Durch die Optionen (rechte Maustaste) kann dieses mit Blank (ohne Wert) auf = Einzelwert gesetzt werden, so dass in der Programmabgrenzung nur aktive (vorhandene Anlagen) dargestellt werden.

Anlagen-Hauptnummer (L,S) ANLAV-ANLN1
Anlagenunternummer (L,S) ANLAV-ANLN2
Bezeichnung der Anlage (L) ANLAV-TXT50
Aktivierungsdatum der Anlage (L) ANLAV-AKTIV


ANLZ - Valutierte Anlagen-Zuordnungen
Datum Gültigkeitsbeginn (L) ANLZ-ADATU
Datum Gültigkeitsende (L)


Zusatzfelder zu ANLZ
(Hierbei handelt es sich um ein in der logischen Datenbank gepflegtes Zusatzfeld zur Tabelle ANLZ)
Text:Standort der Anlage (L) TEXT_ANLZ_STORT

ANLZ - Valutierte Anlagen-Zuordnungen
Verantwortliche Kostenstelle der Anlage (L) ANLZ-KOSTLV
Kostenstelle (L) ANLZ-KOSTL
Innenauftrag (L) ANLZ-CAUFN

Zusatzfelder zu ANLZ
Text: Innenauftrag (L) TEXT_ANLZ_CAUFN


3.) Erweiterung
Über die Berichtsschnittstelle kann dann bspw. die Transaktion AS03 für Anlage anzeigen genutzt werden, so dass hier direkt der Anlagenstammsatz genutzt werden kann.


Hierzu rufen wir wiederum über die SQ01 die Query für eine Änderung auf.
Über SPRINGEN->BERICHTSZUORDNUNG können Empfängerberichte definiert werden.

Über das „+“ (Zeile einfügen) können weitere Query eingefügt werden. Alternativ kann hier auch ein anderer Berichtstyp ausgewählt werden. Über "TR Transaktion" können hier auch die Anlagenstammsatzanzeigetransaktion (AS03) hinterlegt 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.




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


Mittwoch, 23. Oktober 2013
18:35 Uhr

Query FI Einzelposten als Belegjournal - Belegsegment (BSEG) und Belegkopf (BKPF) verknüpfen

Ausgangslage

Wie im Artikel Einzelposten FI Hauptbuch (Auswertung Buchungen Partnergesellschaft) beschrieben besteht die Möglichkeit der Auswertung von Einzelposten des Moduls FI durch eine Query über die Tabelle BSEG "Belegsegment Buchhaltung". Hier sind alle einzelnen Belepositionen der Buchungsbelege im SAP System hinterlegt.

Wie beschrieben wurden die absoluten Buchungswerte (ohne Vorzeichen) in Kombination mit den "Soll-/Haben-Kennzeichen" ausgewertet, so dass hier das Ergebnis (der gebuchte Wert) bei einer Habenbuchung negativ und bei der Sollbuchung positiv dargestellt wird. Dieses entspricht auch der Darstellung in Einzelpostenlisten.

Der Nachteil an der Verwendung der Tabelle BSEG ist, dass hier als Belegdatum lediglich das Feld Valutadatum vorhanden sind. Die Information über Belegdatum und Buchungsdatum ist im Belegkopf des Buchungsbeleg zu finden und wird in der Tabelle BKPF gespeichert.

Clustertabellen versus transparente Tabellen

Ein Join über die Tabellen BSEG und BKPF ergibt als Fehlermeldung den Hinweis, dass Pool- und Cluster-Tabellen nicht in einem Tabellen-Join verwendet werden können.

Bei der Tabelle BSEG handelt es sich um eine Clustertabelle, die dem Cluster RFBLG zugeordnet ist. Innehrlab eines Cluster werden Felder anderer Tabellen komprimiert in einer einzelnen Spalte gespeichert. Hierdurch ist eine Verwendung von Cluster-Tabellen ebenso wie Pool-Tabellen nicht in Joins möglich.
Clustertabellen sammeln hierdurch mehrere Einzeltabellen in einer Tabelle.

Die Einzelpostenbelege sind je nach Kontenarten in transparenten Sekundärtabellen (als Sekundärindizes) zu finden. Diese sind entsprechend schneller auszuwerten und können auch einzeln in einer Query verwendet werden.
Hierbei werden von der Art her Tabellen für ausgeglichene Posten (BSA*) und für offene Posten (BSI*) unterschieden. Dabei können folgende transparente Tabellen relevant sein:
  • BSIS "Buchhaltung: Sekundärindex für Sachkonten" (Sachkonten offene Einzelposten)
  • BSAS "Buchhaltung: Sekundärindex für Sachkonten (ausgegl. Posten"
    (Sachkonten ausgeglichene Posten)
  • BSID "Buchhaltung: Sekundärindex für Debitoren"
    (Debitoren Offene Einzelposten)
  • BSAD "Buchhaltung: Sekundärindex für Debitoren
    (ausgebl. Posten)" (Debitoren ausgeglichene Posten)
  • BSIK "Buchhaltung: Sekundärindex für Kreditoren"
    (Kreditoren Offene Einzelposten)
  • BSAK "Buchhaltung: Sekundärindex für Kreditoren (ausgegl. Posten"
    (Kreditoren ausgeglichene Posten)
Der Vorteil der Clustertabelle BSEG ist jedoch, dass diese alle Belegpositionen enthält unabhängig davon ob diese offen oder schon ausgeglichen sind (gleiches gilt natürlich auch für den Belegkopf in der Tabelle BKPF).

Tabellen-Joins können dennoch nur über Transparente Tabellen ausgeführt werden, so dass hier eine Möglichkeit wäre sowohl die oben erwähnten Tabellen mit der Tabelle BKPF zu verknüpfen (outer join). Dieses hat jedoch den Nachteil, dass hier nicht über Felder wie Kostenstelle, Innenauftrag oder Profit-Center selektiert werden können, da diese Informationen ja wiederum in den Einzeltabellen gespeichert sind (auf der Belegposition).

Um nun dennoch die Informationen aus den Belegkopf (Tabelle BKPF) wie zum Beispiel das Belegdatum beziehungsweise Buchungsdatum zu erhalten und gleichzeitig auf die Merkmale der Belegposition (Tabelle BSEG) wie Kostenträger oder Sachkonto zuzugreifen bietet es sich an statt einzelne Tabellen zu verknüpfen eine logische Datenbank zu verwenden.

Logische Datenbank (LDBA)

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.

1. Infoset definieren
Bei der Anlage des Infoset über die Transaktion SQ02 wird als Datenquelle die logische Datenbank BRF definiert.

Hier sollen nach Angabe der logischen Datenbank die auszuwertenden Knoten mit ausgewählt werden. Für eine Auswertung von BKPF und BSEG würde es ausreichen nur diese beiden Knoten auszuwerten. Diese werden dann als Feldgruppen ausgewählt. Innerhalb der Struktur sind aber auch alle anderen Bestandteile der logischen Datenbank vorhanden, so dass hier einzelne Werte in Feldgruppen übernommen werden können. Wie bei jeden Infoset kann es sinnvoll sein so viele Datenfelder wie möglich zu übernehmen, da dieses Infoset dann auch für andere Queries verwendet werden kann.

Um eine vergleichbare Datengrundlage wie in der eingangs beschriebenen Query zu erhalten werden folgende Daten aus den jeweiligen Strukturen übernommen:

Aus der Struktur Belegsegment Buchhaltung (BSEG):
BSEG-VBUND Partner Gesellschaftsnummer
BSEG-PRCTR Profitcenter
BSEG-BELNR Belegnummer eines Buchhaltungsbeleges
BSEG-GJAHR Geschäftsjahr
BSEG-SHKZG Soll-/Haben-Kennzeichen
BSEG-SGTXT Positionstext
BSEG-AUFNR Auftragsnummer
BSEG-KOSTL Kostenstelle
BSEG-DMBTR Betrag in Hauswährung
BSEG-HKONT Sachkonto der Hauptbuchhaltung

Aus der Struktur Belegkopf für Buchhaltung (BKPF):
BKPF-BUDAT Buchungsdatum im Beleg
BKPF-BLDAT Belegdatum im Beleg

2. Query anlegen
Mit Bezug auf dieses Infoset kann dann eine entsprechende Query über die Transaktion SQ01 angelegt werden.

Hierbei ist zu beachten, dass in der Grundliste die einzelnen Merkmale in der Reihenfolge BKPF und danch BSEG ausgegeben werden. Es ist bspw. nicht möglich erst Daten aus BSEG und zwischen drin aus BKPF auszugeben. Jedoch kann das Layout der Query später durch eine Anzeigevariante angepasst werden.

In der späteren Query sind Buchungskreis, Belegnummer und Geschäftsjahr automatisch als Selektionskriterium vorhanden. Das Buchungsdatum und die Referenznummer sind dabei ebenfalls aktiv wie die Möglichkeit der freien Abgrenzung über weitere Parameter des Belegkopfes.

Sofern weitere Felder als Selektionsvariablen definiert werden erscheinen diese im Selektionsbild als Programmabgrenzung.

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.

Dabei werden nun auch die oben angelegten lokalen Felder mit übernommen.

Die Felder werden hier in der Reihenfolge angeben, wie diese dann auch in der Query ausgegeben werden sollen:
  • Buchungsdatum im Beleg (L,S) BKPF-BUDAT
  • Belegdatum im Beleg (L,S) BKPF-BLDAT
  • Jahr (L) BSEG-GJAHR
  • Belegnummer (L) BSEG-BELNR
  • Hauptbuch (L,S) BSEG-HKONT
  • Soll-/Haben-Kennzeichen (L) BSEG-SHKZG
  • Betrag (L) BSEG-DMBTR
  • Kostenstelle (L,S) BSEG-KOSTL
  • Auftrag (L,S) BSEG-AUFNR
  • Prctr (L,S) BSEG-PRCTR
  • Text (L) BSEG-SGTXT
  • Partnergesellschaft (L,S) BSEG-VBUND
Der Vorteil der Verwendung der logischen Datenbank ist sicherlich, dass nun auch Daten aus den Belegkopf (neben Datum sind hier auch Transaktion oder Erfasser) verfügbar sind.

Nun kann die Query ebenso, wie in der vorherigen Auswertung der Tabelle BSEG noch um lokale Felder erweitert werden, so dass hier ebenfalls das Soll/Haben Kennzeichen berücksichtigt wird.

Hierfür wird innerhalb der Query mit lokalen Feldern gearbeitet.

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.

Ü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 und des dahinter technisch liegenden Tabellenfeldes angegeben):
  • Soll-/Haben-Kennzeichen - SHKZG (BSEG-SHKZG)
  • Betrag in Hauswährung - DMBTR (BSEG-DMBTR)
  • Kostenstelle - KOSTL (BSEG-KOSTL)
  • Auftragsnummer - AUFNR (BSEG-AUFNR)
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. In unseren Fall also ebenfalls in der Feldgruppe der Tabelle BSEG bzw. der Bezeichnung der Feldgruppe "Belegsegment Buchhaltung".


Hierbei werden drei lokale Felder mit folgenden Eigenschaften angelegt.

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

2. Feld (Identifikation ob Innenauftrag oder Kostenstelle)
Kurzbezeichnung: IAK
Feldbezeichnung: IAK
Überschrift: Innenauftrag oder Kostenstelle
Eigenschaften: Textfeld (Anzahl Zeichen: 2)
Berechnungsvorschrift:
Hier wird eine komplexe Berechnung mit folgenden Bedingungen hinterlegt:
  • Bedingung: KOSTL>0
    Formel: 'K'
  • Bedingung: AUFNR>0
    Formel: 'IA'
  • sonst: ''

Diese Berechnung ist möglich, da auf eine Belegzeile nicht Innenauftrag und Kostenstelle gleichzeitg ausgewiesen werden.

3. Feld (Bebuchter Kostenträger)
Kurzbezeichnung: KTR
Feldbezeichnung: Kostenträger
Überschrift: Kostenträger
gleiche Eigenschaften wie: AUFNR
Berechnungsvorschrift:
Hier wird eine komplexe Berechnung mit folgenden Bedingungen hinterlegt:
  • Bedingung: KOSTL+AUFNR>0
    Formel: KOSTL+AUFNR
  • sonst: ''

Sofern Kostenstellen und Innenaufträge unabhängige Nummernkreise ohne Überschneidung haben. Dieses könnte als Beispiel der Fall sein, wenn Kostenstellen mit 1* oder 2* beginnen und etwaige Innenaufträge mit 3* bis 8*.

Diese lokalen Felder können nun ebenfalls in der Grundliste der Query mit aufgenommen werden.

Ergänzung:
Eine mögliche Erweiterung dieser Query in Richtung eines umfassenden Belegjournals für die Finanzbuchhaltung könnte dabei wie folgt gestaltet sein.

 
Beschreibung Tabellenfeld
Buchungskreis BSEG-BUKRS
Jahr BSEG-GJAHR
Geschäftsmonat BKPF-MONAT
Belegnummer BSEG-BELNR
Belegart BKPF-BLART
Belegdatum BKPF-BLDAT
Buchungsdatum BKPF-BUDAT
Soll/Haben Kennzeichen BSEG-SHKZG
Hauptbuch BSEG-HKONT
Steuerkennzeichen BSEG-MWSKZ
Profit-Center BSEG-PRCTR
Kostenstelle BSEG-KOSTL
Auftrag BSEG-AUFNR
IAK Formel siehe Beschreibung
Kostenträger Formel siehe Beschreibung
Betrag Hauswährung BSEG-DMBTR
gebuchter Wert Formel siehe Beschreibung
Text BSEG-SGTXT
Zuordnungsnummer BSEG-ZUONR
Partnergesellschaft BSEG-VBUND
Bezeichnung Partnergesellschaft Zusatzfeld TEXT_BSEG_VBUND
Debitor BSEG-KUNNR
Text Debitor Zusatzfeld TEXT_BSEG_KUNNR
Kreditor BSEG-LIFNR
Text Kreditor Zusatzfeld TEXT_BSEG_LIFNR
Referenz BKPF-XBLNR
Ausgleichsdatum BSEG-AUGDT


Fazit
Insgesamt ist bei dieser Query jedoch zu beachten, dass hier ausschliesslich FI Buchungen erfasst werden. Sofern CO Buchungen (auf sekundäre Kostenarten) erfolgen werden diese nicht mit ausgegeben.

Und was ist nun mit Tee Buchungen im Modul CO?

Hierfür gibt es jedoch die Möglichkeit, wie im Artikel "Query Einzelpostenliste IST über CO Objekte (Auflösen von Innenauftrag, Kostenstelle) sowie Benutzerstammdaten und Erfassungsdatum" beschrieben, die Istbuchungen im CO und somit sowohl die fortgeschriebenen FI Buchungen auf primäre Kostenarten als auch die CO internen Buchungen auf sekundären Kostenarten mit auszuwerten. Daneben können auch Planbuchungen im CO, wie im Artikel "CO Planeinzelposten Objekt und Partnerobjekt auswerten / Mehrere Felder summieren" beschrieben, ebenfalls über eine Query ausgwertet 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.




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


Sonntag, 23. Juni 2013
12:27 Uhr

Einzelposten FI Hauptbuch (Auswertung Buchungen Partnergesellschaft)

Manchmal bereitet das Zusammenspiel zwischen FI, PSM-FM und CO durchaus Probleme, wenn im FI mit übertragene Innenaufträge auf Sammler (im Beispiel Fond LANDESMITTEL oder WIRTSCHAFTSPLAN) übertragen werden.


Ausgangslage: Keine Fortschreibung von FI nach CO für bestimmte Sachkonten (Reisekostenvorschuss)


Bestimmte Erfolgskonten werden aus FI nur nach PSM aber nicht nach CO fortgeschrieben. Als Kontierungsobjekte werden hierbei jedoch ebenfalls Innenaufträge mitgegeben denen teilweise als Fond im PSM nicht ein vergleichbares Objekt zugeordnet ist (identischer Fond wie Innenauftrag) sondern ein Sammler (im Beispiel ein Fond mit der Bezeichnung LANDESMITTEL). Ein Beispiel können hier zum Beispiel "Vorschüsse Reisekosten" sein, die zwar als Aufwand gebucht sind, aber nicht als Kosten in der KLR betrachtet werden.

Ferner soll im Rahmen der Konsolidierungsabstimmungen innerhalb eines Konzerns auch Einzelposten innerhalb des Konzerns über die Partnergesellschaft zu selektieren.

Eine Auswertung von FI Einzelposten ist zwar über das Belegjournal möglich jedoch erhält man hier keine passende Listenform, gerade dann wenn man auch Felder wie Profit-Center, Innenauftrag oder Kostenstelle mit angegeben möchte.
 

Lösungsansatz: Auswertung über Query Hauptbuch BSEG


Grundsätzlich sind alle FI Einzelpostenbelege in der Tabelle BSEG "Belegsegment Buchhaltung" zu finden. Für eine Auswertung dieser Tabelle ist jedoch zu beachten, dass hier die Werte absolut gelistet sind und nur anhand des "Soll-/Haben-Kennzeichen" erkannt werden kann, ob dieses im Ergebnis positiv oder negativ auf einen Kostenträger ausgewiesen werden soll.

Entsprechend hilfreich kann hier eine Query über das Hauptbuch beziehungsweise über die einzelnen Belege innerhalb der Tabelle BSEG sein.

Lösung

1. Infoset definieren

Grundlage der geplanten Query ist das direkte Lesen der Tabelle BSEG. Entsprechend wird diese mit allen Feldern in das Infoset übernommen. Beim Erstellen des Infosets wird hierfür die Option "Direktes Lesen der Tabelle" mit der Tabelle BSEG gewählt.

Theoretisch wäre es sicherlich auch möglich diese Tabelle direkt zu lesen (dieses könnte durch die Transaktionen SE12 beziehungsweise SE16 erfolgen), jedoch soll das "Soll-/Haben-Kennzeichen" ebenfalls bei der Auswertung berücksichtigt werden so dass die gebuchten Werte auf den entsprechenden Objekten (Kostenträger) angezeigt werden.


2. Query definieren

Hierzu besteht die Möglichkeit innerhalb einer Query zusätzlich zu dem Inhalt der Tabelle auch pber lokale Felder weitere Informationen zu den Inhalt der Tabelle anzuzeigen beziehungsweise auf Grundlage des Tabelleninhaltes mit den Werte zu arbeiten. Hierfür wird innerhalb der Query mit lokalen Feldern gearbeitet.

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.

Ü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 und des dahinter technisch liegenden Tabellenfeldes angegeben):
  • Soll-/Haben-Kennzeichen - SHKZG (BSEG-SHKZG)
  • Betrag in Hauswährung - DMBTR (BSEG-DMBTR)
  • Kostenstelle - KOSTL (BSEG-KOSTL)
  • Auftragsnummer - AUFNR (BSEG-AUFNR)
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. In unseren Fall also ebenfalls in der Feldgruppe der Tabelle BSEG bzw. der Bezeichnung der Feldgruppe "Belegsegment Buchhaltung".


Hierbei werden drei lokale Felder mit folgenden Eigenschaften angelegt.

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

2. Feld (Identifikation ob Innenauftrag oder Kostenstelle)
Kurzbezeichnung: IAK
Feldbezeichnung: IAK
Überschrift: Innenauftrag oder Kostenstelle
Eigenschaften: Textfeld (Anzahl Zeichen: 2)
Berechnungsvorschrift:
Hier wird eine komplexe Berechnung mit folgenden Bedingungen hinterlegt:
  • Bedingung: KOSTL>0
    Formel: 'K'
  • sonst: 'IA'

Diese Berechnung ist möglich, da auf eine Belegzeile nicht Innenauftrag und Kostenstelle gleichzeitg ausgewiesen werden.

3. Feld (Bebuchter Kostenträger)
Kurzbezeichnung: KTR
Feldbezeichnung: Kostenträger
Überschrift: Kostenträger
gleiche Eigenschaften wie: AUFNR
Berechnungsvorschrift: KOSTL + AUFNR

Sofern Kostenstellen und Innenaufträge unabhängige Nummernkreise ohne Überschneidung haben. Dieses könnte als Beispiel der Fall sein, wenn Kostenstellen mit 1* oder 2* beginnen und etwaige Innenaufträge mit 3* bis 8*.

3. Grundliste erstellen
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.

Dabei werden nun auch die oben angelegten lokalen Felder mit übernommen.

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


Belegsegment Buchhaltung
  • Belegnummer eines Buchhaltungsbeleges (L,S) BSEG-BELNR
  • Geschäftsjahr (L,S) BSEG-GJAHR
  • Sachkonto der Hauptbuchhaltung (L,S) BSEG-HKONT
  • Soll-/Haben-Kennzeichen (L) BSEG-SHKZG
  • Betrag in Hauswährung (L) BSEG-DMBTR
    Anmerkung:Grundsätzlich könnten die Felder SHKZG und DMBTR auch nicht mit ausgegeben werden, da diese zwar als Grundlage für die lokalen Zusatzfelder (weiter oben definiert) verwendet werden, aber nicht extra ausgegeben werden müssen. Im Beispiel sind diese nur ausgegeben um den Ursprung der Werte zu verdeutlichen. Sofern der Wert ausgegeben wird, kann es hilfreich sein, diesen dann ohne Währungszeichen (Kein Währungsfeld) auszugeben)
  • Kostenstelle (L) BSEG-KOSTL
  • Auftragsnummer (L) BSEG-AUFNR

Lokale Zusatzfelder
  • Gebuchter Wert (L)
  • IAK (L)
  • Kostenträger (L)
Anmerkung:Je nach Stammdatensystematik könnte auch das Feld IAK ignoriert bzw. gar nicht erst angelegt werden.

Belegsegment Buchhaltung
  • Profitcenter (L) BSEG-PRCTR
  • Partner Gesellschaftsnummer (L,S) BSEG-VBUND
    Anmerkung: Da diese Query auch innerhalb eines Konzerns genutzt werden soll, ist auch die Partnergesellschaft hilfreich um Umsätze innerhalb des Konzerns zu konsolidieren beziehungsweise sowohl Debitoren- als Auch Kreditorenposten auszuwerten.
  • Positionstext (L) BSEG-SGTXT
    Anmerkung: Neben der reinen Wertgröße ist es sicherlich auch sinnvoll den Belegtext auszugeben um hier einen Hintergrund der Buchung zu erhalten.


Der Nachteil dieser Query ist jedoch, je nach Auslastung des Systems eine etwas längere Laufzeit (je nach Selektionsparamtern). Allerdings würde wohl auch ein Standardbericht (oder das Abspringen von der Saldenanzeige der Transaktion FS10N auf die Einzelpostenliste Zeit in Anspruch nehmen.

Ergänzung
Eine Erweiterung dieser Query ist im Artikel Query FI Einzelposten als Belegjournal - Belegsegment (BSEG) und Belegkopf (BKPF) verknüpfen beschrieben, wodurch neben den Belegpositionen auch Daten des Belegkopfes mit ausgegeben 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.




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


Freitag, 14. Juni 2013
17:02 Uhr

Tabellen hinter Transaktionscode oder ABAP Programm über eine SAP Query ermitteln

Ausgangslage

Neben der Möglichkeit innerhalb eines Feldes über F1 und technische Informationen aus den einzelnen Felddaten Tabellennamen und Feldname zu ermitteln (oder alternativ im Coding nachzuschauen) oder über die Transaktion SE12 in den einzelnen Tabellen des SAP Systems zu suchen besteht auch die Möglichkeit über eine SAP Query die Tabellen D010TAB (Tabelle für Report<->Tabellen-Verwendung) und TSTC (SAP-Transaktions-Codes) innerhalb eines Joins zu verknüpfen und über den hinter der Transaktion liegenden ABAP Programm eine Auswertung die genutzten Tabellen zu ermitteln.

Diese Methode ist im Buch Praxishandbuch SAP Query Reporting von Stephan Kaleske beschrieben und ist hier um die Tabellenart (aus der Tabelle DD02L) sowie der Tabellenbezeichnung (aus der Tabelle DD02T) ergänzt worden.

Als Ergänzung oder mit einen anderen Schwerpunkt kann ich ferner noch das Buch von  Martin Peto und Katrin Klewinghaus " Reporting im SAP-Finanzwesen: Standardberichte, SAP QuickViewer und SAP Query" und natürlich meine Einführung in das Thema SAP Query, welche weiter unten im Artikel verlinkt ist.

1. Infoset definieren
Zur Darstellung der gewünschten Daten müssen folgende Tabellen miteinander verknüpft werden:
  • D010TAB - Tabelle für Report<->Tabellen-Verwendung
  • TSTC - SAP-Transaktions-Codes
  • DD02L - SAP-Tabellen
  • DD02T - R/3-DD: Texte zu SAP-Tabellen


Folgende Felder werden hierbei miteinander verknüpft.

Verknüpfungen
Hierbei steht <--> für einen normalen Join und >LO< für einen left outer join.

D010TAB-MASTER <--> TSCT-PGMNA
D010TAB-TABNAME <--> DD02L-TABNAME
DD02L-TABNAME <--> DD02T

Schematisch ist hierbei folgendes Infoset geplant.

Join über T010TAB, TSTC, DD02L und DD02T

Die Felder der Tabellen D010TAB und TSTC werden komplett innerhalb der Feldgruppen übernommen. Aus der Tabelle DD02L wird nur das Feld Tabellenart (DD02L-TABCLASS) und aus der Tabelle DD02T die Felder Sprachenschlüssel (DD02T-DDLANGUAGE) und die Tabellenbezeichnung (DD2T-DDTEXT) übernommen. Hierbei werden die Feldgruppen analog der Tabellenbezeichnung angelegt

Der Sprachenschlüssel ist dabei erforderlich, da die Bezeichnungen von Tabellen mehrfach vorkommen je nachdem inwieweit unterschiedliche Sprachversionen gepflegt sind.

2.) Query definieren
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 für Report<->Tabellen-Verwendung
TCODE (L,S) TSTC-TCODE

Zusatzfelder (werden in der Grundliste zur Verfügung gestellt)
Text:Transaktionscode (L) TEXT_TSTC_TCODE

Tabelle für Report<->Tabellen-Verwendung
ABAP-Hauptprogramm (L,S) D010TAB-MASTER
Tabellenname (L,S) D010TAB-TABNAME


Zusatzfelder (werden in der Grundliste zur Verfügung gestellt)
Text:Tabellenart (L) TEXT_DD02L_TABCLASS

R/3-DD: Texte zu SAP-Tabellen
Kurzbeschreibung von Repository-Objekten (L) DD02T-DDTEXT
Sprachenschlüssel (S) DD02T-DDLANGUAGE

3. Query ausführen
Beim Ausführen der Query kann nun über den Transaktionscode, ein ABAP-Programm oder über den Tabellenname eine Liste mit allen Transaktionen oder Tabellen die mit der jeweiligen Selektion in Verbindung stehen ausgewertet werden.

Sofern eine Auswertung anhand von ABAP-Programmen ohne Transaktionszuordnung erfolgen soll besteht die Möglichkeit die Verknüpfung
D010TAB-MASTER mit TSTC-PGMNA als "left outer join" zu definieren. Entsprechend länger würde hier aber eine Auswertung dauern.

Als beispielhafte Anwendung der Query kann zum Beispiel die Transaktion KS03 (Kostenstelle anzeigen) mit dem Sprachenschlüssel "DE" ausgewertet werden und innerhalb der Query erkannt werden, dass in der "Transparente Tabelle" "CSKS - Kostenstellenstammsatz" die Kostenstellenstammdaten zu finden sind und hinter der Transaktion das ABAP Programm SAPLKMA1 liegt.

Diese Methode kann besonders dann sinnvoll sein, wenn umfangreiche Transaktionen oder ABAP Programme eine Vielzahl von Tabellen verwenden und ein schneller Überblick geschaffen werden soll.
 

Hinweis:

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




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


Samstag, 23. März 2013
18:23 Uhr

CO Planeinzelposten Objekt und Partnerobjekt auswerten / Mehrere Felder summieren

Ausgangslage
In der Darstellung von Planeinzelposten (bspw. Kostenstellen Einzelposten Plankosten (Transaktion KSBP) oder Innenaufträge Einzelposten Plankosten (Transaktion KOBP)) werden nur die Kostenstelle oder Innenauftrag aber nicht das entsprechende Partnerobjekt dargestellt, so dass bei den Planeinzelposten nicht das Partnerobjekt (Gegenbuchung) angezeigt wird.

Zur Darstellung von Planbelegen in CO (bspw. Plankopie KP98 (für Kostenstellen) oder KO15 (für Innenaufträge), Planwerterfassung über KPF6 oder KP06 oder sonstige Planbuchungen) sollen in einer Einzelpostenliste jedoch sowohl Sender als auch Empfänger eines Buchungsbeleges dargestellt werden.

Lösung
Die Planbelege werden in den Tabellen COBK und COEJ gespeichert. Hierbei ist jedoch zu beachten, dass die Werte über die einzelnen Perioden verteilt sind, so dass hier eine Query sinnvoll ist um die entsprechenden Summen über die Periodeneinzelwerte zu erfassen und sowohl Objekt als auch Partnerobjekt anzuzeigen.

1.) Infoset definieren
Zur Darstellung der gewünschten Daten müssen folgende Tabellen miteinander verknüpft werden:

COBK - CO-Objekt: Belegkopf
COEJ - CO-Objekt: Einzelposten jahresbezogen

Folgende Felder werden hierbei miteinander verknüpft.

Verknüpfungen
Hierbei steht <--> für einen normalen Join und >LO< für einen left outer join.

COBK-KOKRS <--> COEJ-KOKRS
COBK-BELNR <--> COBK-BELNR

Am einfachsten ist es nun alle Tabellenfelder des Infosets als Feldgruppe anlegen zu lassen.

2.) Query definieren
Wichtig bei dieser Query ist es, dass Planwerte auf mehrere Perioden verteilt sind, so dass für eine Jahresbetrachtung alle möglichen 16 Perioden (Monate Januar bis Dezember und die Sonderperioden) ausgewertet werden müssen.

Hierfür wird innerhalb der Query ein lokales Feld genutzt.

Hierzu gehen wir nicht in die Grundliste der Query (wo auch das Layoutdesign gepflegt wird) sondern wechseln innerhalb der Querypflege (Transaktion SQ01) mit nächstes Bild (F6) auf die Feldauswahl der Query.

Ü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 der Feldgruppe "CO-Objekt: Einzelposten jahresbezogen" über die Tabelle COEJ werden die Felder
"Wert gesamt in Transaktionswährung" von W1 bis W16 bezeichnet.

Dieses entspricht den Tabellenfeldern
COEJ-WTG001 bis COEJ-WTG016.

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. In unseren Fall also ebenfalls in der Feldgruppe der Tabelle COEJ.
Das lokale Feld hat folgende Eigenschaften:
Kurzbezeichnung: BETRAG
Feldbezeichnung: Betrag (Summe WTG001-WTG016)
Überschrift: Betrag
gleiche Eigenschaften wie: W1
Als Berechnungsvorschrift wird folgende Formel hinterlegt:
W1+W2+W3+W4+W5+W6+W7+W8+W9+W10+W11+W12+W13+W14+W15+W16

Somit sind in diesen lokalen Feld alle Tabellenspalten von COEJ-WTG001 bis COEJ-WTG016 summiert. Die Summe dieser Felder entspricht dem Jahreswert als "Wert gesamt in Transaktionswährung".

Nachdem dieses Feld definiert ist kann in der Grundliste die Query wie folgt definiert werden. 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:

CO-Objekt: Belegkopf
Belegnummer (L,S) COBK-BELNR
Jahr (L,S) COBK-GJAHR
Belegdatum (L) COBK-BLDAT
CO-Objekt: Einzelposten jahresbezogen
Version (L, S) COEJ-VERSN
Hierdurch können sowohl die Istversion 0 als auch mögliche Planversionen ausgewertet werden.
Objektnummer (L,S) COEJ-OBJNR
Kostenart (L,S) COEJ-KSTAR
lokales Zusatzfeld
Betrag (L) wie oben beschrieben
CO-Objekt: Einzelposten jahresbezogen
Partnerobjekt (L,S) COEJ-PAROB
Positionstext (L) COEJ-SGTXT
(das Originalfeld lautet Segmenttext)
Belegkopftext (L) COBK-BLTXT

Anpassung der Query
In der Querypflege kann über das Bild "Selektionen" (über Springen Nächstes Bild oder durch F6 nächstes Bild) die Bezeichnung der Selektionsfelder angepasst werden.

Hier ist es sinnvoll das Feld Objektnummer in "Objektnummer (KS* OR*)" und Partnerobjekt in "Partnerobjekt (KS* OR*)" umzubenennen.

Handhabung der Query
In der Selektionsmaske können nun Jahr, Version sowie Objektnummer oder Partnerobjekt und Kostenart angegeben werden. Sofern Planwerte in der Istversion erfasst werden (bspw. für einen Plan/Ist Vergleich für CO-Budgets) ist hier die Version 0 auszuwählen.

Als Objekt und Partnerobjekt sind Kostenstellen und Innenaufträge wie folgt definiert.

Hierbei ist zu beachten, dass Kostenstellen als „KS*BUK* NNNNNNNNNN“ wobei BUK für den Kostenrechnungskreis steht gefolgt von der Kostenstelle, die als zehnstelliger Wert (ggf. mit führenden 0en) dargestellt werden muss. Bei den Innenaufträgen ist die Darstellung ORNNNNNNNNNNN (n= 12 Stellen).

Eine vereinfachte Eingabe ist mit Platzhaltern möglich:
Bspw. für die Kostenstelle 1234567: „KS*1234567“ oder für den Innenauftrag 7654321 „OR*7654321“. Zur Darstellung aller Buchungen sollte KS* und OR* verwendet werden, da andernfalls auch Objekte der Anlagenbuchhaltung etc. ausgegeben werden.

Dieses ist auch der Grund, warum in der Selektionsmaske die Bezeichnung des Feldes angepasst 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.




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


Sonntag, 3. Februar 2013
16:19 Uhr

SAP Query: Berechtigung (organisatorisch und technisch)

Ausgangslage
Neben der Gestaltung von SAP Query besteht oftmals auch eine Frage in welcher Form diese dann in die Breite gegeben werden soll. Hier sollte neben der Frage der Gestaltung solcher Abfragen auch darauf geachtet werden, in welcher Form diese dann an "berechtigte" Empfänger weiter gegeben werden soll.

Eine Möglichkeit wäre es eine kundeneigene Transaktion für die Query anzulegen. Am elegantesten wäre hier vermutlich die Parametertransaktion, so dass auch entsprechende Felder vorbelegt sind.

Diese Methode ist sicherlich für einzelne Auswertungen sicherlich sehr hilfreich, sofern aber bspw. in Teilbereichen Queries genutzt werden sollen, muss auch eine Frage der Berechtigungen gestellt werden.


Hier gibt es, meines Wissens nach, drei Methoden, die sicherlich sehr hilfreich sind:

a) einfache Methode: Benutzergruppen

Über die Transaktion SQ03 werden Benutzergruppen gepflegt, die sowohl Infosets als auch Queries zuzuordnen sind. Somit können Benutzer entsprechenden Gruppen zugeordnet werden und diese dann auf bestimmte Queries bzw. Infosets zugreifen können.

Eine Pflege dieser Gruppen kann über Benutzerparameter gesteuert werden, so dass auf eine sehr bequeme Weise über die Transaktion SQ01 oder auch FQ01 nur die SAP Query angezeigt werden, für die die Personen auch berechtigt sind.

  • Vorteil:

  • Leichte Pflegbarkeit
  • "Zwang" zur Organisation und Strukturiereung der Benutzergruppen

  • Nachteil:

  • Dokumentationsaufwand
  • Nachvollziehbarkeit / Klärung der Zuständigkeiten zur Pflege von Benutzergruppen


  •  
b) mittlere Methode: Berechtigungsgruppen

Bei der Pflege von Infosets können im Feld Berechtigungsgruppe angegeben werden. Dieses Feld ermöglicht auf acht Stellen einen entsprechenden Wert einzutragen, der im Benutzerstamm über das Berechtigungsobjekt S_PROGRAMM gepflegt werden kann und im lokalen Berechtigungskonzept hinterlegt werden kann.

  • Vorteil

  • Berücksichtigung innerhalb des Berechtigungskonzept
  • Konzeptionierung anhand der Berechtigungsgruppen

  • Nachteil

  • Disziplin bei Berechtigungspflege
  • Genaues Namenskonzept und ggf. Dokumentation


  •  
c) ABAP Berechtigungsprüfung

Sofern innerhalb einer Query logische Datenbanken genutzt werden sind hier schon entsprechende Berechtigungsprüfungen hinterlegt.

Zum Aufruf von Infosets, die bspw. über Joins miteinander verknüpft werden, sind nur Prüfungen vorhanden, ob generell die dahinter liegende Tabellen gelesen werden dürfen aber keine differenziertere Betrachtung auf die einzelnen Datensätze betrachtet werden.

Hier kann innerhalb der Infosetpflege über das Menü
Springen->
Abgrenzungen->
ein Abgrenzungsparameter hinterlegt werden.

Hier kann dann bspw. über das Feld AUFK-AUFNR die Auftragsnummer als Selektionskriterium hinterlegt werden.

Ist eine solche Abgrenzung definiert, so ist auch beim Anlegen einer Query automatisch dieses Feld als Selektionsfeld mit definiert.

Über den Button "Prüfcoding zum Element" kann nun ein entsprechendes Abap-Coding hinterlegt werden. Hier kann eine Berechtigungsprüfung über "Authority-Check" durchgeführt werden.

Hier würde sich dann das Berechtigungsobjekt K_ORDER anbieten, in dem die Berechtigung für Innenaufträge hinterlegt sind.

Nähere Infos liefert hierzu der OSS Hinweis 692502.

Hier sollte jedoch beachtet werden, dass dort dann auch ein entsprechender ABAP-Schlüssel auch erforderlich ist.

  • Vorteil

  • Sehr differenzierte Berechtigungsprüfung
  • Genaue Prüfung der innerhalb der Tabellen vorhandenen Datensätze

  • Nachteil

  • ABAP Coding erforderlich
  • Entwicklerschlüssel
  • Tiefe Kenntnisse im Bereich SAP-BC und den einzelnen Berechtigungsobjekte der Module


  •  

Fazit:
Je nach Einsatzzweck der SAP Query haben alle Methoden ihre Vorteile und entsprechende Nachteile. Hier sollte insbesondere auf die lokalen organisatorischen Gegegbenheiten geachtet werden und das Thema Berechtigung und Datenschutz nicht ausser acht gelassen werden. Ein wichtiges Thema ist hier generell beim Thema SAP Query auch ein Punkt der Dokumentation und Verbindlichkeit.

Hinweis:

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




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


Mittwoch, 16. Januar 2013
16:15 Uhr

Query Kontenplan für Module CO, FI und PSM

Ausgangslage
Für eine Stammdatenauswertung sollen alle Buchungskonten der Module FI, CO und PSM ausgewertet werden. Dieser Kontenplan soll das Sachkonto (Modul FI), die Kostenart (Modul CO) und die mit den Sachkonto verknüpfte Finanzposition (Modul PSM) enthalten.

Voraussetzung
Grundvoraussetzung für eine Auswertung per Query, ist dass die Nummernkreise von Sachkonto und Kostenarten übereinstimmen. Dieses bedeutet, dass das Sachkonto 6543 auch als Kostenart 6543 angelegt ist. Sofern hier die Sachkonten aus FI mit den Kostenarten aus CO übereinstimmen sollte dieses kein Problem sein. Allerdings werden so reine CO Konten (bspw. sekundäre Kostenarten) nicht ausgwertet.

Problem / bzw. mögliche Fehlerquelle
Hierbei ist zu beachten, dass teilweise durch die FMDERIVE mglw. eine andere Aussteuerung der Sachkonten auf entsprechende Finanzpositionen gepflegt sein kann.

Lösung
Sofern die Voraussetzungen (übereinstimmende Nummernlogik von Sachkonto und Kostenart) erfüllt sind besteht die Möglichkeit einen modulübergreifenden Kontenplan durch Auswertung von Datenbanken zu erstellen.

1.) Infoset definieren
Über SAP Query müssen hierbei mehrere Tabellen miteinander verknüpft werden.
Folgende Tabellen enthalten die für uns erforderlichen Stammdaten:

Tabellen
SKA1 - Sachkontenstamm (Kontenplan)
SKAT - Sachkontenstamm (Kontenplan: Bezeichnung)
SKB1 - Sachkontenstamm (Buchungskreis)
CSKA - Kostenarten (Kontenplanabhängige Daten)
FMCI - Finanzpositionen Stammdaten
CSKB - Kostenarten (Kostenrechnungskreisabhängige Daten)
CSKU - Kostenartentexte
FMCIT - Finanzpositionen Texte


Folgende Felder werden hierbei miteinander verknüpft.

Verknüpfungen
Hierbei steht <--> für einen normalen Join und >LO< für einen left outer join. Die left outer joins sind erforderlich um auch Datensätze auszugeben, die nicht in allen Tabellen vorhanden sind.

SKA1-KTOPL <--> SKAT-KTOPL (Kontenplan)
SKA1-SAKNR <--> SKAT-SAKNR (Nummer des Sachkonto)
SKA1-SAKNR >LO< SKB1-SAKNR (Nummer des Sachkonto)

SKAT-KTOPL >LO< CSKA-KTOPL (Kontenplan)
SKAT-SAKNR >LO< CSKA-KSTAR (Nummer Sachkonto und Kostenart)

CSKA-KTOPL <--> CSKU-KTOPL (Kontenplan)
CSKA-KSTAR <--> CSKU-KSTAR (Kostenart)

CSKA-KSTAR <--> CSKB-KSTAR (Kostenart)

SKA1-SAKNR >LO< SKB1-SAKNR (Nummer des Sachkonto)

SKB1-FIPOS <--> FMCI-FIPOS (Finanzposition)

FMCI-FIKRS <--> FMCIT-FIKRS (Finanzkreis)
FNCI-GJAHR <--> FMCIT-GJAHR (Geschäftsjahr)
FMCI-FIPEX <--> FMCIT-FIPEX (Finanzposition)

Feldgruppen

In den einzelnen Feldgruppen der Query können eigentlich alle Felder der Tabellen übernommen werden. Da für die Finanzpositionen nur bestimmte Felder relevant sind (die Finanzpositionen sind relativ stammdatenpflegefreundlich ;-)).

Entsprechend umfassen die Feldgruppen folgende Felder:

FMCI:
FMCI-FIPOS Finanzposition
FNCI-FIVOR Finanzvorgang
FMCI-POTYP Finanzpositionstyp
FMCI-VPTYP Vortragspositionstyp der Finanzposition
FMCI-FIPUP Übergeordnete Finanzpositions

Gerade das Feld FMCI-FIPUP ist hierbei zu beachten, da anhand der übergeordneten Finanzposition die Standardhierarchie der Finanzpositionen innerhalb PSM abgebildet wird.

FMCIT:
FMCIT-BEZEI Bezeichnung
FMCIT-TEXT1 Beschreibung


2.) Query definieren
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:

a) Sachkonto

SKA1 - Sachkontenstamm (Kontenplan)
Sachkonto (L,S) SKA1-SAKNR
KtoG (L) SKA1-KTOKS (Kontengruppe)
SKAT - Sachkontenstamm (Kontenplan: Bezeichnung)
Kurztext (L) SKAT-TEXT20
Langtext (L) SKAT-TEXT50
SKB1 - Sachkontenstamm (Buchungskreis)
St (L) SKB1-MWSKZ (Steuerkategorie)
Sor (L) SKB1-ZUAWA (Sortierschlüssel)
FStG (L) SKB1-FSTAG (Feldstatusgruppe)
A (L) SKB1-XINTB (Kennzeichen: Konto nur automatisch bebuchbar)
Finanzposition (L) SKB1-FIPOS

Die einzelnen Daten werden bewust in der Reihenfolge ausgegeben in der die Stammdaten auch gepflegt werden.

b) Kostenart

CSKA - Kostenarten (Kontenplanabhängige Daten)
Kostenart (L) CSKA-KSTAR
CSKU - Kostenartentexte
Bezeichnung (L) CSKU-KTEXT
Beschreibung (L) CSKU-LTEXT
CSKB - Kostenarten (Kostenrechnungskreisabhängige Daten)
KA (L) CSKB-KATYP (Kostenartentyp)

c) Finanzposition

FMCI - Finanzpositionen Stammdaten
Finanzposition (L) FMCI-FIPOS
FMCIT - Finanzpositionen Texte
Bezeichnung (L) FMCIT-BEZEI
Beschreibung (L) FMCIT-TEXT1
FMCI - Finanzpositionen Stammdaten
VG (L) FMCI-FIVOR (Finanzvorgang)
P (L) FMCI-POTYP (Finanzpositionstyp)
Vo (L) FMCI-VPTYP (Vortragspositionstyp)
Übergeordnete Finanzpos. (L) FMCI-FIPUP

Hinweis zur Anwendung
Durch diese Query können nun zu den Sachkonten die entsprechende Kostenarten / Finanzpositionen ermittelt werden. Auf diese Weise kann bspw. ein Stammdatenabgleich zwischen unterschiedlichen Systemen erfolgen. Interessant in diesen Zusammenhang ist auch, dass hier die Zuordnung von Sachkonten zu "symbolischen" Finanzpositionen ersichtlich ist. Bspw. eine Zuordnung zu einer Finanzposition AFA etc..

Hinweis:

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




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


Montag, 19. November 2012
17:13 Uhr

Query Stammdatenvergleich Profit-Center und Auslesen von Textbestandteilen (Teilstring aus Variable)

Ausgangslage
Innerhalb der Profit-Center-Rechnung sind drei Arten von Profit-Center hinterlegt. Diese sind angelehnt an Kostenstellen geführt mit einen Buchstaben je Bereich.

Beispiel:
Kostenstelle 12345678
Profitcenter Bereich D: D12345678
Profitcenter Bereich L: L12345678
Profitcenter Bereich S: S12345678

Ziel ist es, dass das Feld Verantwortlicher innerhalb dieser drei Profit-Center identisch gepflegt ist.

Problem:
Angedacht ist eine Liste aller Profitcenter sortiert nach einer Kostenstelle. Problematisch ist dabei, dass den Profit-Center L* zwar eine Kostenstelle zugeordnet ist, den Bereichen D* und S* jedoch jeweils nur Innenaufträge zugewiesen sind. Entsprechend ist eine Auswertung anhand von Kostenstellen nicht möglich.

Lösung:
Da die Namenslogik vorgegeben ist (Bereich+Kostenstelle) kann jedoch mit Hilfe eines kundeneigenen Feldes innerhalb einer Query wie folgt vorgegangen werden.

Innerhalb der kundeneigener Felder in SAP Query ist es aber möglich auch mit Textfeldern Teile auszulesen. Hierbei können bei Textfeldern einzelne Bestandteile (Zeichenketten) ausgelesen werden. Bei bekannter Zeichenlänge kann hier der Textstring entsprechend ausgelesen werden. Im Beispiel könnte also die Kostenstelle ausgelesen werden, indem aus der Profit-Centernummer ab den 2. Zeichen alle Zeichen ausgelesen werden. Somit würde sowohl aus L12345678 als auch aus D12345678 die Kostenstelle 12345678 dargestellt werden.


Grundlage für die Auswertung von Profit-Center-Stammdaten sind die Tabellen CEPC und CEPCT.

Infoset definieren
Innerhalb der Transaktion SQ02 wird folgendes Infoset definiert. Hierfür wird als Datenquelle ein Tabellen-Join über Tabelle CEPC angelgt.

Es werden folgende Tabellen miteinander in Beziehung gesetzt:
Tabellen:
CEPC: Stammdatentabelle von Profit Centern
CEPCT: Profit-Center-Stammdaten Texte

Verknüpfungsbedingungen:
Die vorgeschlagenen Verknüpfungsbedingungen seitens SAP können direkt übernommen werden.

Damit sind alle Verknüpfungen der Tabellen erfolgt. Der Einfachheit halber können nun alle Feldgruppen/Datenfelder übernommen werden. Dieses hat den Vorteil, dass dieses Infoset auch für weitere Queries zur Verfügung steht. Alternativ könnte man auch nur die notwendigen Felder übernehmen. Innerhalb der Query können dann die Felder auch wieder eingeschränkt werden.

2.) Query definieren
Innerhalb der Query über das Infoset wird nun mit lokalen Feldern gearbeitet.

Hierzu gehen wir nicht in die Grundliste der Query (wo auch das Layoutdesign gepflegt wird) sondern innerhalb der Querypflege mit nächstes Bild (F6) auf die Feldauswahl der Query gewechselt.

Ü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:

Stammdatentabelle von Profit Centern
Profitcenter-> PCTR

Diese Kurzbezeichnung ist notwendig, da wir auf diese dann Bezug nehmen, wenn wir ein eigens Feld mit einer Formel anlegen.

Teilstring aus einen Textstring innerhalb einer Query auslesen

Dieses geht über

BEARBEITEN->LOKALES FELD->ANLEGEN

Dieses Lokale Feld wird dann in der Feldgruppe angelegt, in der wir uns gerade befinden.

Das lokale Feld hat folgende Eigenschaften:
Kurzbezeichnung KST
Feldbezeichnung Kostenstelle
Überschrift Kostenstelle


Unter Eigenschaften wird hier die gleiche Eigenschaften wie Feld PCTR
hinterlegt.

Unter Berechnungsvorschrift kommt nun folgende Formel:

PCTR[2:10]

Hierbei werden aus den Textfeld PCTR die Zeichen mit der Position 2 bis Position 10 (entspricht der maximalen Zeichenlänge des Feldes) ausgegeben.
Das erste Zeichen eines Textfeldes hat die Position 1, was in unseren Beispiel dann D,L oder S wäre.

In der Query kann nun dieses Feld verwendet werden um eine Sortierung der Stammdaten über die Kostenstelle zu erreichen.

Aufbau der Query
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 Zusatzfelder
Kostenstelle (L) (kundeneigenes Feld)

Stammdatentabelle von Proftitcenter CEPC
PrCtr (L) CEPC-PRCTR

Profit-Center-Stammdaten Texte (CEPCT)
Kurztext (L) CEPCT-KTEXT
Langtext (L) CEPCT-LTEXT

Stammdatentabelle von Proftitcenter CEPC
Verantwortliche (L) CEPC-VERAK


Da alle Stammdaten kontrolliert werden sollen ist kein Selektionsfeld definiert.

Allerdings bietet sich an, über die Sortierfelder (durch Markieren der Sortierfeldbox und Ziehen des Feldes Kostenstelle (mit den Beispielwert) auf den entsprechenden Kasten) das Feld Kostenstelle direkt als Summierungsfeld zu verwenden. Hierdurch erscheinen die Profitcenter D12345678, L12345678 und S12345678 direkt unterinander.

Hinweis:

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




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


Samstag, 29. September 2012
12:40 Uhr

Query Anlagenbuchhaltung (Inventarliste) - AHK Wert

In einer Query für die ANlagenbestandsliste (siehe Query Anlagenbuchhaltung (Inventarliste) über logische Datenbank ADA ) wurde innerhalb der logischen Datenbank ADA das Feld ANLCV-KANSW kumulierte Anschaffungs- und Herstellungskosten aus der Struktur ANLCV "Anlagenreporting: ANLC-Felder ergänzt um verschied" entnommen.

Im Laufe der ANwendung hat sich herausgestellt, dass die Query bei im aktuellen Geschäftsjahr angeschaffte Anlagen dieses Feld leer bleibt. Sofern nun eine Anlagenbestandsliste über einen bestimmten Anlagenwert gefiltert werden soll, ergibt sich hier ein Problem.

Ursache:

Das Feld ANLCV-KANSW umfasst die kumulierten Anschaffungs- und Herstellungskosten, die bis zum Anfang des aktuellen Geschäftsjahres auf die Anlage zugegangen sind. Somit sind die im Laufe des Jahres angeschafften Anlagen hier noch mit keinen Buchwert versehen, so dass diese erst zum Jahresende ausgewiesen werden.

Lösung:

Innerhalb der Struktur ANLCV "Anlagenreporting: ANLC-Felder ergänzt um verschied" bietet sich das Feld

ANLCV-BEST_GJE "Anschaffungswert Geschäftsjahresende ( ohne Inv. förderung)" an, da hier alle Anschaffungskosten gelistet werden, so dass nun auch eine Filterung der im laufenden Jahr angeschafften ANlagen erfolgen kann.

Hinweis:

Die summierten Felder der Struktur ANLCV wie z.B. die in der Query verwendeten Felder:
ANLCV-BEST_GJE Anschaffungswert Geschäftsjahresende ( ohne Inv. förderung
ANLCV-KANSW kumulierte Anschaffungs- und Herstellungskosten
ANLCV-KNAFA Kumulierte Normalabschreibungen
ANLCV-KSAFA Kumulierte Sonderabschreibungen
ANLCV-KAAFA Kumulierte außerplanmäßige Abschreibung
ANLCV-LFD_BCHWRT Buchwert der Anlage aktuell

sollten nur als Listenfelder und nicht als Selektionsfelder gewählt werden. Eine Filterung über den Anlagenwert kann dann über die ALV Liste oder in Excel erfolgen.

Ergänzung:

Sollen auch zeitabhängige Stammdaten ausgewertet werden, bzw. die Buchungen der Profit-Center-Rechnung und der Anlagenbuchhaltung aufeinander abgestimmt werden ist auch der Artikel "Abgleich Belege in CO auf Profit-Center mit zeitabhängigen Stammdaten der Anlagenbuchhaltung bei Investitionen" relevant. Hier ist auch das Thema "Vorraussetzung für das Buchen auf Innenaufträgen in der Anlagenbuchhaltung" behandelt.

Hinweis:

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




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


Sonntag, 1. Juli 2012
11:56 Uhr

Umgang mit lokalen Datumsfeldern in Queries

Ausgangslage:

In einer Query wurde ein lokales Feld welches die gleichen Eigenschaften hat wie
das Ausgangsfeld angelegt. Bei dem Versuch ein Datum, +25 Jahre, zu erhalten wird jedoch kein brauchbares Ergebnis ausgegeben. Das rechnen mit Tagen funktioniert. Wenn jedoch der Bereich [YEAR] gewählt wird kommt es jedoch zu keiner vernünftigen Ausgabe des Datums.

Die Frage ist nun, wie in Queries mit Jahreswerten bezogen auf ein Datum gerechnet werden kann.

Lösungsansatz:

Eine echte Lösung habe ich leider nicht, aber wenigstens eine
Teillösung:

Das lokale Feld mit dem Zieldatum kann mit den Eigenschaften eines Textfeld definiert werden stat die eines Datumsfeldes.

Nun kann hier das vorhandene Datumsfeld zumindest bezogen auf die Jahre um 25 erhöht werden.

Nehmen wir an, dass das Datumsfeld die Kurzbezeichnung Datumsfeld hat:

DATUMSFELD[year]+25

Durch [YEAR] wird aus der Variable Datumsfeld (hier steckt das Ausgangsdatum drin), das Jahr ausgegeben.

So erhalten Sie dann das Jahr um 25 erhöht.


Weitere Überlegungen:

Definieren Sie drei lokale Textfelder:

TESTJ:
DATUMSFELD[YEAR]
TESTM:
DATUMSFELD[MONTH]
TESTD:
DATUMSFELD[DAY]

Als Formel für den Zukunfstwert bspw. TEST25

geben Sie nun folgende Formel ein:

TESTD*1000000+TESTM*10000+TESTJ+25

Innerhalb der Grundliste wird dann lediglich das Feld TEST25 ausgeben.

Ich gebe zu, dass diese Vorgehensweise zwei Fehler hat:

a) Optisch wird das Datum in der Form 01072037 ausgegeben (Als Datum war hier 01.07.2012 zzgl. 25 Jahre angegeben)
b) Schaltjahre werden nicht berücksichtigt

Wobei hier die Formel mit der Schaltjahresformel ja noch optimieren
werden kann.

Dieses sollte über entsprechende Bedingungen im Feld TEST25
funktionieren. Hier ist die Funktion MOD (Rest zu verwenden und die
Bedingungen für ein Schaltjahr (durch 100 ohne Rest Teilbar jedoch nicht
durch 400).

Ich denke, dass damit zumindest auf die Schnelle eine passende
Lösung gefunden werden kann. In der Not dürfte es ja auch unproblematisch sein einen 29.02. in der Zukunft hoch zu rechnen, die möglicherweise gar kein Schaltjahr ist.


Rückmeldung:
Das definieren als Text hat prima funktioniert.
Eine wesentlich schönere Variante wäre natürlich per Zusatzfeld ABAP-Coding beziehungsweise Funktionsbaustein, Hier hat das exxsens Developer Blog im Blogartikel "Funktionsbaustein zur Datumsberechnung" auf den Funktionsbaustein RHPP_HALFVALUE_WORKFLOW_DATE hingewiesen. Wie erwähnt bedarf dieses natürlich entsprechende Beechtigungen.
 

Hinweis:

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




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


Dienstag, 22. Mai 2012
17:31 Uhr

Query Anlagenbuchhaltung (Inventarliste) über logische Datenbank ADA

Ausgangslage
Es soll ein Verzeichnis über alle Anlagen inklusive Bezeichnung des zugeordenten Innenauftrages, sowie Standort und Wert der Anlage. Dieses soll bspw. als Inventarliste zur Kontrolle an den einzelnen Standorten genutzt werden. Hierzu nutzen wir die Auswertungsmöglichkeiten einer logischen Datenbank.

Die Struktur einer logischen Datenbank kann in der Transaktion SE36 eingesehen werden. Hier sind auch die einzelnen Komponenten für die logische Datenbank ADA einzusehen.

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.

Diese sind in der SE36 betrachtbar. Im Bereich HR wären dieses bspw. PNP oder PCH. Der Nachteil dieser logischen Datenbanken ist, dass hier keine weiteren Tabellen abgefragt werden können sondern diese hierarchisch von SAP festgelegt sind.

Logische Datenbanken sind bspw. BRF (für FI Belege) oder ADA (für die Anlagenbuchhaltungsdaten).


1.) Infoset anlegen

Basierend auf die logische Datenbank ADA wurden folgende Werte in Feldgruppen entsprechend der vorhandenen Struktur übernommen


Aus der Struktur ANLAV "Anlagenreporting: ANLA-Felder ergänzt um Kst, ..."

ANLAV-BUKRS Buchungskreis
ANLAV-ANLKL Anlagenklasse
ANLAV-ANLN1 Anlagen-Hauptnummer
ANLAV-ANLN2 Anlagenunternummer
ANLAV-KTOGR Kontenfindung
ANLAV-AKTIV Aktivierungsdatum der Anlage
ANLAV-DEAKT Deaktivierungsdatum
ANLAV-ORD41 Ordnungsbegriff 1
ANLAV-LIFNR Kontonummer des Lieferanten bzw. Kreditors
ANLAV-MENGE Menge
ANLAV-INVNR Inventarnummer
ANLAV-TXT50 Bezeichnung der Anlage
ANLAV-KOSTL Kostenstelle
ANLAV-STORT Standort der Anlage
ANLAV-CAUFN Innenauftrag
ANLAV-RAUMN Raum
ANLAV-KOSTLV Verantwortliche Kostenstelle der Anlage

Aus der Tabelle ANLB "Abschreibungsparamter":

ANLB-NAPRZ Prozentsatz Normalabschreibung
ANLB-NDJAR Geplante Nutzungsdauer in Jahren
ANLB-AFASL Abschreibungsschlüssel
ANLB-LGJAN Letztes Geschäftsjahr der Jahreswerte in der Anlagenbuchh.

Aus der Struktur ANLCV "Anlagenreporting: ANLC-Felder ergänzt um verschied":

ANLCV-KANSW kumulierte Anschaffungs- und Herstellungskosten
ANLCV-KNAFA Kumulierte Normalabschreibungen
ANLCV-KSAFA Kumulierte Sonderabschreibungen
ANLCV-KAAFA Kumulierte außerplanmäßige Abschreibung
ANLCV-LFD_BCHWRT Buchwert der Anlage aktuell


2.) Query anlegen

Innerhalb der Query werden nun auf folgende Felder 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 danna uch in der Query ausgegeben werden sollen:

ANLAV - Anlagenreporting: ANLA-Felder ergänzt um Kst, ...
Ordnungsbegriff 1 (S) ANLAV-ORD41
(Hier kann bspw. die Mittelherkunft gepflegt sein)
Buchungskreis (L,S) ANLAV-BUKRS
Der Buchungskreis wird mit in der Listenanzeige übernommen, so dass ein Absprung über die Berichtsschnittstelle zur Transaktion AS03 möglich ist
Standort der Anlage (S) ANLAV-STORT
Verantwortliche Kostenstelle der Anlage (L,S) ANLAV-KOSTLV
Anlagenklasse (L,S) ANLAV-ANLKL

Zusatzfelder zu ANLAV
(Hierbei handelt es sich um ein in der logischen Datenbank gepflegtes Zusatzfeld zur Struktur ANLAV)
Text:Kontenfindung (L) TEXT_ANLAV_KTOGR

ANLAV - Anlagenreporting: ANLA-Felder ergänzt um Kst, ...
Menge (L) ANLAV-MENGE
Bei dieser Einheitenfeldposition sollen keine Einheit und das Feld nur ausgegeben werden, wenn es ungleich 0 ist. Hier sind entsprechende Felder in den Fenster Listenfeld markierbar.
Anlagen-Hauptnummer (L,S) ANLAV-ANLN1
Anlagenunternummer (L,S) ANLAV-ANLN2
Inventarnummer (L) ANLAV-INVNR
Aktivierungsdatum der Anlage (L) ANLAV-AKTIV
Deaktivierungsdatum (L,S) ANLAV-DEAKT
Auch hier ist markiert, dass das Feld nur ausgegeben wird, wenn es ungleich 0 ist
Bezeichnung der Anlage (L) ANLAV-TXT50

Zusatzfelder zu ANLAV
Text:Standort der Anlage (L) TEXT_ANLAV_STORT

ANLAV - Anlagenreporting: ANLA-Felder ergänzt um Kst, ...
Raum (L) ANLAV-RAUMN

Zusatzfelder zu ANLAV
Text:Ordnungsbegriff 1 (L) TEXT_ANLAV_ORD41
(Feld nur ausgeben, wenn ungelich 0, hier bspw. Mittelherkunft)

ANLAV - Anlagenreporting: ANLA-Felder ergänzt um Kst, ...
Kontonummer des Lieferanten bzw. Kreditors (L) ANLAV-LIFNR

Zusatzfelder zu ANLAV
Text:Kontonummer des Lieferanten bzw. Kreditors (L) TEXT_ANLAV_LIFNR

ANLAV - Anlagenreporting: ANLA-Felder ergänzt um Kst, ...
Kostenstelle (L,S) ANLAV-KOSTL
Innenauftrag (L,S) ANLAV-CAUFN

Zusatzfelder zu ANLAV
Text:Innenauftrag (L) TEXT_ANLAV_CAUFN

ANLACV - Anlagenreporting: ANLC-Felder ergänzt um verschiedene Summen
Hier sind alle Wertfeldpositionen mit der Option "kein Währungsfeld" versehen, da andernfalls in einer Zusatzspalte die Währungseinheit bspw. EUR mit ausgegeben werden, ferner sollen die Felder nur ausgegeben werden, wenn diese ungleich 0 sind.
kumulierte Anschaffungs- und Herstellungskosten (L) ANLCV-KANSW
Kumulierte Normalabschreibungen (L) ANLCV-KNAFA
Kumulierte Sonderabschreibungen (L) ANLCV-KSAFA
Kumulierte außerplanmäßige Abschreibung (L) ANLCV-KAAFA
Buchwert der Anlage aktuell (L) ANLCV-LFD_BCHWRT

ANLB - Abschreibungsparameter
Geplante Nutzungsdauer in Jahren (L) ANLB-NDJAR
Letztes Geschäftsjahr der Jahreswerte in der Anlagenbuchh. (L) ANLB-LGJAN

3.) Erweiterung
Über die Berichtsschnittstelle kann dann bspw. die Transaktion AS03 für Anlage anzeigen genutzt werden, so dass hier direkt der Anlagenstammsatz genutzt werden kann.


Hierzu rufen wir wiederum über die SQ01 die Query für eine Änderung auf.
Über SPRINGEN->BERICHTSZUORDNUNG können Empfängerberichte definiert werden.

Über das „+“ (Zeile einfügen) können weitere Query eingefügt werden. Alternativ kann hier auch ein anderer Berichtstyp ausgewählt werden. Über "TR Transaktion" können hier auch die Anlagenstammsatzanzeigetransaktion (AS03) hinterlegt werden.


Eine weitere Möglichkeit ist bspw. auch eine Schnittstelle zu einer anderen Query. Bspw. ist hier eine Stammdatenliste für Kostenstellen und Innenaufträge. Aber auch sonstige Auswertungen sind hier denkbar.


Nachtrag
Besser geeignet für den aktuellen AHK Wert ist das Feld:

ANLCV-BEST_GJE "Anschaffungswert Geschäftsjahresende ( ohne Inv. förderung)

Siehe Artikel:
Query Anlagenbuchhaltung (Inventarliste) - AHK Wert

Nachtrag 2 (2016)

Alternative Auswertung über Profit-Center-Rechnung sowie Bewegungsarten:

Da das Thema Auswertung der Anlagenbuchhaltung mit Mittelherkunft und Profit-Center immer wieder aktuell angefragt wird, habe ich im Artikel "Zusammenfassung Query über Anlagenzugang - Auswertung Investitionen aus Profit-Center-Rechnung" eine ausführlichere Darstellung der Möglichkeiten  inklusive eines Abschnitts zum Thema "Hintergrund: Anlagenzugänge über Bewegungsart und Buchungskonto selektieren" ergänzt.



 

Hinweis:

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



 

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


Donnerstag, 5. April 2012
19:53 Uhr

SAP Query: Einzelpostenliste KAMV für Umbuchung in Planversion

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.

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.

Lösungsansatz: Query über Vorgang KAMV

Ein direktes Auswerten der Tabelle COEP ist relativ mühsam, da hier sowohl auf die Vorzeichen als auch die zu exportierenden Beträge geachtet werden müssen. Zumindest die Aufbereitung nach Sender und Empfänger ist hier im Rahmen einer Query etwas einfacher. Genauso wie bei der Auswertung nach COEP werden als Selektionskriterien das Geschäftsjahr, der Vorgang ("KAMV") als auch das B/Entl.Kennzeichen ("S") verwendet. Dieses hat den Hintergrund, dass jeder Beleg in der COEP sowohl mit Soll als auch mit Haben (also zwei Positionen je Beleg) hinterlegt sind, der Betrag aber nur einmal korrigiert werden soll. Die so gewonnenen Einzelposten können dann entsprechend zusammengefasst werden.

Entsprechend kann die Tabelle COEP als Grundlage einer SAP Query verwendet werden. Als optionale Bereicherung um die Bezeichnung und die Kostenartentypen können hier auch die Tabellen CSKU und CSKB mit der Tabelle COEP betrachtet werden.

Infoset definieren
Tabellen:
COEP - CO-Objekt: Einzelposten periodenbezogen
CSKB - Kostenarten (Kostenrechnungskreisabhängige Daten)
CSKU - Kostenartentexte

Verknüpfungen:
Folgende Felder werden hierbei miteinander verknüpft.

COEP-KSTAR <-> CSKB-KSTAR
COEP-KSTAR CSKU-KSTAR
Bei der Verknüpfung der Tabelle COEP und CSKB handelt es sich um einen "left outer join". Diese Verknüpfungsart kann durch die rechte Maustaste auf "left outer join" genutzt werden. Diese kann genutzt werden, um auch Belege anzugeben, wenn die Verknüpfung keine übereinstimmende Werte ergibt, bspw. weil keine Bezeichnung in der Kostenart ausgegeben werden.

In der Feldgruppe können die Werte aus den einzelnen Tabellen übernommen werden. Für dieses Beispiel werden in der Feldgruppe 01 alle Felder der Tabelle COEP übernommen. Ergänzend dazu werden als Feldgruppe 2 die Bezeichnung aus der Tabelle CSKU (CSKU-KTEXT) und in der Feldgruppe 3 der Kostenartentyp (CSKB-KATYP) und Datum gültig bis (CSKB-DATBI) übernommen.

Nun kann im weiteren die Query definiert werden.

 

1.) Query definieren

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:

COEP - CO-OBjekt: Einzelposten periodenbezogen
Kostenrechnungskreis (S) COEP-KOKRS
Be-/Entlastungskennzeichen (L,S) COEP-BEKNZ
Geschäftsjahr (L,S) COEP-GJAHR

CSKB - Kostenarten (Kostenrechnungskreisabhängige Daten)
Kostenartentyp (L) CSKB-KATYP
Datum gültig bis (S) CSKB-DATBI
Gültig bis wird genommen, sofern es Änderungen innerhalb der CSKB gab um zu vermeiden, dass hier zwei Werte ausgegeben werden


COEP - CO-OBjekt: Einzelposten periodenbezogen
Vorgang CO (L,S) COEP-VRGNG
Belegnummer (L) COEP-BELNR
Objektnummer (L,S) COEP-OBJNR
Kostenart (L,S) COEP-KSTAR

CSKU - Kostenartentexte
Allgemeine Bezeichnung (L) CSKU-KTEXT

COEP - CO-OBjekt: Einzelposten periodenbezogen
Wert gesamt in Kostenrechnungskreiswährung (L) COEP-WKGBTR
Partnerobjekt (L,S) COEP-PAROB


Soweit wäre diese Query beinahe identisch zur Auslesung der Tabelle COEP bspw. mit SE16.
Um nun aber abhängig vom Wert die Daten aufzubereiten wird hier mit "lokalen Feldern" vergleichbar zur Erweiterung der Query Stammdaten CO Kontrolle Verantwortliche genommen.
 

2. Kundeneigene Felder in der Query anlegen

Für die Anlage kundeneigener Felder muss als erstes ein Bezug zu den zu verwendenden Feldern innerhalb der Query gegeben sein.

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.

Ü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 CO-Objekt: Einzelposten periodenbezogen (Tabelle COEP)
Wert gesamt in Kostenrechnungskreiswährung -> WERT
Objektnummer -> OBJEKT
Partnerobjekt -> PARTNER



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. Elegant wäre es natürlich, wenn wir im Infoset eine entsprechende leere Feldgruppe definiert hätten, es geht aber auch ohne.

Insgesamt werden hier drei Felder angelegt Z_ALT für dem Semder (Soll) Z_NEU für den Empfänger (Haben) und Z_WERT für den eigentlichen Wert.

Die lokalen Felder haben hierbei dann folgende Eigenschaften:

a) Feld Z_ALT
Das lokale Feld hat folgende Eigenschaften:

Kurzbezeichnung ALT
Feldbezeichnung Z_ALT
Überschrift Z_ALT


Innerhalb der Sachgruppe kann un die Feldgruppe des Infoset gelegt werden. Dieses ist dann der Bereich, wo das lokale Feld angelegt worden ist.

Als Feldeigenschaften könnten wir nun Textfelder, Rechnfelder etc. hinterlegen. Hier geben wir jedoch die gleichen Eigenschaften wie OBJEKT. Da es sich bei Objekt und PARTNER um die Objektnummer (KS* oder OR*) handelt, ist es eigentlich egal auf welches von beiden Bezug genommen wird. Auf diese Weise werden die Eigenschaften des Tabellenfeldes vererbt. Alternativ hätte man auch Textfeld mit 20 Zeichen nehmen können.
Da nun der Sender / Empfänger abhängig vom Wert ermittelt werden soll legen wir eine Berechnungsvorschrift an. Dazu klicken wir auf "KOMPLEXE BERECHNUNG".

Nun können wir drei Bedingungen und eine sonstige Alternative angeben.

Dieses nutzen wir wie folgt:
Bedingung:
WERT > 0
Formel:
PARTNER

Ist der Wert positiv wird das Partnerobjekt als Sender genommen.

Bedingung:
WERT < 0
Formel:
OBJEKT

Ist der Wert negativ wird die Objektnummer als Sender genommen.

Sonst
WERT

Somit wird bei einer 0 der Wert ausgegeben.

b) Feld Z_NEU
Das lokale Feld hat folgende Eigenschaften:

Kurzbezeichnung NEU
Feldbezeichnung Z_NEU
Überschrift Z_NEU

Hier hat das Feld die gleichen Eigenschaften wie das Feld PARTNER.

Als Formeln wird folgende komplexe Berechnung hinterlegt:

Bedingung:
WERT > 0
Formel
OBJEKT

Bedingung
WERT < 0
PARTNER

Sonst
WERT

Im Grunde ist dieses die umgedrehte Bedingung zum Feld Z_NEU.
Damit sind Z_ALT (S) und Z_NEU (H) definiert. Für die Buchungsliste benötigen wir jedoch noch den Wert mit positiven Vorzeichen (in Excel würde hier als Formel ABS(Wert) für den absoluten Wert genommen werden.

c) Feld Z_WERT
Das lokale Feld hat folgende Eigenschaften:

Kurzbezeichnung Z_WERT
Feldbezeichnung Z_WERT
Überschrift Z_WERT

Hier hat das Feld die gleichen Eigenschaften wie das Feld WERT (entspricht CURR / Währung mit 15 Zeichen und 2 Dezimalstellen).

Als Formeln wird folgende komplexe Berechnung hinterlegt:

Bedingung
WERT < 0
Formel
- 1 * WERT

Bedingung
WERT > 0
Formel
1 * WERT

Sonst
WERT

Die so festgelegten lokalen Felder werden nun ebenfalls in der Grundliste mit als Listenfelder übergeben.

Nun kann diese Query als Grundlage für eine Umbuchung verwendet werden. Ähnlich wie bei der Tabellenauswertung wird hier
der Vorgang KAMV das Belastungs/Entlastungskennzeichen S sowie das Kalenderjahr ausgewählt.


Da jedoch eine Vielzahl von Buchungen vorhanden sind sollte diese Query noch bspw. in Access weiterverarbeitet werden.


 

3. Weiterverarbeitung der Query über KAMV in Access

Besonders wichtig ist hierbei, dass Buchungen die identische Sender und Empfänger haben Gruppiert und Summiert werden. Andernfalls haben wir ggf. wesentlich mehr Buchungssätze, als eigentlich erforderlich wäre.

Im Ergebnis haben wir nun folgende Query erhalten.

Be-/Entlastungskennzeichen (COEP-BEKNZ)
Geschäftsjahr (COEP-GJAHR)
Kostenartentyp (CSKB-KATYP)
Vorgang CO (COEP-VRGNG)
Belegnummer (COEP-BELNR)
Objektnummer (COEP-OBJNR)
Kostenart (COEP-KSTAR)
KOstenart Bezeichnung (CSKU-KTEXT)
Wert/KWähr (COEP-WKGBTR)
Partnerobjekt (COEP-PAROB)

Sowie unsere kundeneigene Felder
Z_ALT
Z_NEU
Z_WERT


In einer Datenbankanwendung (im Beispiel ACCESS) sind nun folgende Abfragen erforderlich.

001 Kostenart Neu
Aus der Grundliste der Query werden folgende Felder in die Abfrage übernommen:
Z_ALT
Kostenart
Wert/TWähr
Z_NEU

Hier sollte für Kostenarten des Typs 42 entsprechende Kostenarten des Typs 41 genommen werden.
Sofern es eine entsprechende Logik innerhalb der Kostenarten gibt (bspw. die Kostenarten Typ 42 beginnen mit 0815 und die korrespondierenden Kostenarten des Typs 41 beginnen mit 4711) kann hier eine passende Wenn Funktion genommen werden.

Beispiel:
Unter der Annahme, dass die Kostenarten achtstellig sind kann, sofern erforderlich die Kostenart wie folgt ermittelt werden.
NeuKA-1: Wenn(Links([Kostenart];4)="4711";"0815" & Rechts([Kostenart];4);0)

Gibt es daneben noch eine Kostenart die direkt ersetzt werden soll bspw. 55555590 durch 55555580 lautet die zweite Bedingen:
NeuKA-2: Wenn([Kostenart]="55555590";55555580;0)

Entsprechend können hier auch weitere "Austauschsfunktionen ermittelt werden.

Als letzter Punkt sollte auf dieser Kostenarten Bezug genommen werden, oder die ursprüngliche Kostenart genommen werden:

Z_Kostenart: Wenn([NeuKA-1]+[NeuKA-2]>0;[NeuKA-1]+[NeuKA-2];[Kostenart])


Zur Verdeutlichung noichmals die Hilfsfelder zur Ermittlung der "neuen" Kostenarten.
  • NeuKA-1: Wenn(Links([Kostenart];4)="4711";"0815" & Rechts([Kostenart];4);0)
  • NeuKA-2: Wenn([Kostenart]="55555590";55555580;0)
  • Z_Kostenart: Wenn([NeuKA-1]+[NeuKA-2]>0;[NeuKA-1]+[NeuKA-2];[Kostenart])



002 KoSt oder IA
Sowohl in der Objektnummer als auch Partnerobjekt werden Kostenstellen als KS* und Innenaufträge als OR* ausgewiesen. Entsprechend ist das Feld Z_ALT sowie Z_NEU noch aufzuteilen ob es sich um eine Kostenstelle oder einen Innenauftrag handelt.

Hierbei wird unter Bezugnahme auf die Abfrage "001 Kostenart Neu" dieses wie folgt ermittelt.

Z_ALT aus 001 Kostenart_neu

ALT_Typ: Links([Z_ALT];2)
Sofern es sich um einen Auftrag handelt sind die ersten zwei Zeichen OR bei einer Kostenstelle KS

Unter der Annahme, dass sowohl Kostenstellen als auch Innenaufträge achtstellig sind (oder mit führender Null ausgewiesen werden, kann nun Z_ALT entsprechend auf die Felder Kost Alt (für sendende Kostenstelle) und Auftrag Alt (für sendenden Innenauftrag) ausgewertet werden-

Kost Alt: Wenn([ALT_Typ]="KS";Rechts([Z_ALT];8);"")

Aufrag Alt: Wenn([ALT_Typ]="OR";Rechts([Z_ALT];8);"")

Z_Kostenart aus 001 Kostenart_neu

Betrag: Wert/TWähr aus 001 Kostenart_neu


Genauso wie unter Z_ALT sowohl Kostenstellen als auch Innenaufträge ausgewiesen sein können, wird hier ebenfalls Z_NEU auf die Spalten Kost Neu und Auftrag Neu aufgeteilt.

Z_NEU aus 001 Kostenart_neu

NEU_Typ: Links([Z_NEU];2)

Kost Neu: Wenn([NEU_Typ]="KS";Rechts([Z_NEU];8);"")

Auftrag Neu: Wenn([NEU_Typ]="OR";Rechts([Z_NEU];8);"")

Als weiteres Feld wird noch die Sender-Empfänger-Beziehung ermittelt:
Beziehung: [ALT_Typ] & [NEU_Typ]
Somit wäre Auftrag an Auftrag bspw. OROR oder Kostenstelle an Auftrag KSOR.



003 Betrag in Summe
Für die Umbuchung sind nun alle Werte vorhanden, da aber Buchungen häufiger eine identische Sender-Empfänger Beziehung haben. Im Beispiel wird die Abteilung A wohl nicht nur eine Kopie im Jahr erhalten sondern häufiger Kopien nutzen ist es sinnvoll eine Gruppierung und Summe über die Werte zu erhalten.

Hierzu wird in dieser Abfrage wie folgt die vorherige Abfrage aufbereitet:
Die einzelnen Werte stammen aus der Abfrage "002 Kost oder IA"

Beziehung (Funktion Gruppierung)
Kost Alt (Funktion Gruppierung)
Auftrag Alt (Funktion Gruppierung)
Z_Kostenart (Funktion Gruppierung)
Betrag (Funktion Summe)
Kost Neu (Funktion Gruppierung)
Auftrag Neu (Funktion Gruppierung)

Somit sind dann alle Buchungen zusammengefasst.


Sollen die Buchungen per CATT eingespielt werden, kann es nützlich sein für die jeweilige Beziehung die Abfrrage 003 Betrag in Summe nochmals aufzuteilen.

Hierbei wird ein Suchkriterium über das Feld Beziehung gelegt, so dass hier insgesamt vier Abfragen mit Bezug auf "003 Betrag in Summe" erstellt werden:

010 Auftrag an Auftrag
Beziehung
Kriterien "OROR"
Auftrag Alt
Z_Kostenart
SummevonBetrag
Auftrag Neu

010 Auftrag an Kostenstelle
Beziehung
Kriterien "ORKS"
Auftrag Alt
Z_Kostenart
SummevonBetrag
Kost Neu

010 Kostenstelle an Auftrag
Beziehung
Kriterien "KSOR"
Kost Alt
Z_Kostenart
SummevonBetrag
Auftrag Neu

010 Kostenstelle an Kostenstelle
Beziehung
Kriterien "KSKS"
Kost Alt
Z_Kostenart
SummevonBetrag
Kost Neu

Weiterntwicklung der Grundlage (Query)

Grundsätzlich ist es natürlich überlegenswert die in der Datenbankanwendung erstellte Abfrage "002 KoSt oder IA" auch schon im Infoset durch Zusetzfelder oder aber in der Query zu erledigen. Hierzu müssten die Felder Objektnummer und Partnerobjekt auf Zusatzfelder *_KS und *_IA aufgeteilt werden. Sinnvollerweise würde dieses im Infoset erfolgen. Und ebenfalls, wie in der Datenbanklösung durch die Abfrage der ersten zeichen und Zuordnungen zum jeweiligen Feld. Dieses dürfte durch ein vergleichbares Coding wie 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 möglich sein. Allerdings ist diese Query dann nicht ohne Weiteres innerhalb der Einrichtungen verteilbar, wenn unterschiedliche Längen von Kostenstellen und Innenauftragsnummern genutzt werden. Trotzdem könnte sich hier lokal, an der eigenen Einrichtungen, eine solche Anpassung tatsächlich lohnen da damit ein weiterer Schritt direkt aus SAP und nicht aus Excel oder Access erstellt wird...was ja durchaus auch einen eigenen Charme hat.
 

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. Weitere Artikel zur Verarbeitung von Daten in MS Access sind unter Access zu finden.




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


Sonntag, 4. März 2012
19:47 Uhr

SAP Query: Systemstatus CO Innenauftrag

Ausgangslage:

Über die Transaktion KOK5 (Stammdatenliste Innenaufträge) ist es möglich auch das Feld Status eines Innenauftrages auszuwerten und so eine Liste aller gesperrten Innenaufträge zu erhalten. Leider ist der Auftragsstatus "gesperrt" nicht als Selektionsparameter bei der KOK5 vorhanden, so dass hier alle Aufträge ausgwertet werden müssen und später selektiert werden muss. Dieses erhöht zum Einen die Dauer der Auswertung und zum anderen werden bei der KOK5 nur bis zu 10.000 Innenaufträge angezeigt.

Dennoch möchte ich hier noch, bevor ich auf eine Lösung eingehe, auf die im Artikel "Selektionsvariante KOK5 und Statusselektionsschemata zur Auswertung gesperrter Innenaufträge" vorgestellte Vorgehensweise verweisen.


Ein weiterer Nachteil ist, dass in der Spalte Sytemstatus-Zeile alle bisher den Auftrag erteilten Statusausprägungen ausgewiesen wird.
Diese Daten stammen intern aus der Struktur MKAUF und werden im Feld SYSST ausgewiesen. Der Nachteil ist, dass hier ein Eintrag zum Beispiel "FREI ABRV SPER" genannt werden kann.


Lösungsansatz:

Auch hier hilft die Objektnummer des Innenauftrages weiter, da innerhalb der Tabelle JEST jeder Status eines SAP Objektes festgehalten wird. Somit kann hier eine Verknüpfung zu den Stammdaten der Innenaufträge erstellt werden.

Der Nachteil ist, dass hier in mehreren Zeilen die einzelnen Status eines Auftrages festgehalten werden. Daher ist es sinnvoll, sich hier ebenfalls eine SAP Query zu bedienen.

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.



1. Infoset definieren
Tabellen:
AUFK - Auftragsstammdaten
JEST - Einzelstatus pro Objekt
TJ02 - Systemstatus

Verknüpfungen:
AUFK-OBJNR <-> JEST-OBJNR
Wie unter ABRV beschrieben wird hier wiederum die Objektnummer verwendet um die Tabellen zu verknüpfen.

In der Tabelle JEST ist nun der vorhandene Status als Nummernfeld für jedes Objekt hinterlegt. In der Tabelle TJ02 erhalten wir allerdings auch die Bezeichnung dieses Status, so dass dieses Feld gerade bei der späteren Selektion sehr hilfreich ist.

Entsprechend legen wir als weitere Verknüpfung folgende an:
JEST-STAT <-> TJ02-ISTAT

Somit kann nachher in der Query auch über den Text bzw. die Beschreibung des Status verwendet werden.


2. Query definieren
Auch hier werden die Felder wieder in der Ausgabereihenfolge angegeben mit der Kennzeichnung L als Listenfeld und S als Selektionsfeld.

Auftragsstammdaten AUFK
Innenauftragsnummer AUFK-AUFNR (S,L)
Kurztext AUFK-KTEXT (L)
Name des letzten Änderers AUFK-AENAM (L)
Änderungsdatum des Auftragsstamms AUFK-AEDAT (L)

Einzelstatus pro Objekt JEST
Einzelstatus eines Objekts JEST-STAT (L)
Kennzeichen: Status inaktiv JEST-INACT (S)
Dieses Feld Status inaktiv, ist als Selektion wichtig, da eine einmal zugewiesene Sperre auch wieder deaktiviert werden kann. Daher wird dieses als weiteres Selektionsfeld mit angegeben.

Systemstatus TJ02
Systemstatus TJ02-ISTAT (S)
Durch Verwendung des Systemstatus aus der Tabelle TJ02 wird in der F4 Auswahlhilfe der Query dann auch die Beschreibung ausgegeben.

Zusatzfeld bzw. Textfeld
Zusatzfeld:
"Text:Systemstatus" TEXT_TJ02_ISTAT (L)

Handhabung der Query
Zur Handhabung der Query können nun alle Innenaufräge ausgewertet werden. Das Feld "Kennzeichen Status inaktiv" sollte auf BLANK oder ungleich X gesetzt werden (durch die Selektionsoptionen). Ferner kann hier der Status: I0043 für gesperrt
gewählt werden, so dass alle derzeit aktiv gesperrten Innenaufträge des Systems ausgewertet werden können.

Alternative: Systemstatus in einer Zeile je Auftrag ausgeben

Der Nachteil dieser Query ist, dass wenn kein Systemstatus vorselektiert wurde je Status eine extra Zeile pro Innenauftrag ausgegeben wird.
Im Artikel "SAP Query ABAP Coding im Zusatzfeld für Verknüpfung Innenauftrag und Fond bzw. Finanzierungszweck" wird alternativ eine Methode beschrieben in der in der Stammdatenliste je Innenauftrag ein Zusatzfeld GESPERRT bei gesperrten Innenaufträgen mit ausgegeben wird. Dieses ist natürlich auch für andere Phasen eines Innenauftrages möglich.
 

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


Donnerstag, 12. Januar 2012
23:18 Uhr

Query Abrechnungsvorschriften Innenauftrag

Ausgangslage:
Für die Auftragsabrechnung werden innerhalb der Innenauftragsstammdaten Abrechnungsvorschriften für einzelnen Innenaufträge gepflegt. Diese können über die Transaktion KOSRLIST_OR Abrechnungsvorschriften (Rechhnungswesen->Controlling->Innenaufräge->Infosystem->Berichte zu Innenaufträgen->Stammdatenverzeichnis) ausgwertet werden.

Hier können für jeden Innenauftrag unter Position folgende Daten mit angeben werden:
- Empfänger
- Kurztext Empfänger
- Prozent
- Abrechnungsart
- Abrechnungsvorgang
- Version
- Gültig bis Jahr

Grundsätzlich ist diese Transaktion zur Kontrolle von gepflegten Abrechnungsvorschriften hilfreich. Der Nachteil ist hier in Form der Berichtsdarstellung.

Innerhalb des Berichtes werden als Kopfzeile der Innenauftra und auf einzelnen Positionen die entsprechenden Abrechnungsregeln ausgegeben. Ein Export
oder Vergleich gestaltet sich daher als recht schwierig.

Lösungsansatz:
Auch die Abrechnungsvorschriften sind in einer enstprechenden Tabelle hinterlegt.
Die Aufteilungsregeln der Abrechnungsvorschriften für die Auftragsabrechnung sind hierbei in der Tabelle COBRB gespeichert.

Hier werden in einzelne Tabellenzeilen die entsprechenden Abrechnungsempfänger hinterlegt. DIese werden entweder als Objektnummer in den Felder REC_OBJNR1 bzw. REC_OBJNR2 gespeichert können aber auch in den Feldern KOSTL und AUFNR entnommen werden.

Im vorliegenden Fall erfolgt eine Abrechnung je nach Ursprungszuordnung auf eine Kostenstelle oder Innenauftrag.

Lösung:
Entsprechend bietet sich eine Query über die beiden Tabellen

1.) Infoset definieren

AUFK - Auftragsstammdaten
COBRB - Aufteilungsregeln Abrechnungsvorschrift Auftragsabrechnung an.

Hier sollte folgende Verknüpfung definiert werden.

AUFK-OBJNR <-> COBRB-OBJNR

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.

2. Query definieren
Auch hier weden die Felder wieder in der Ausgabereihenfolge angegeben mit der Kennzeichnung L als Listenfeld und S als Selektionsfeld.

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


3.) Vergleich mit Innenauftragsstammdatenliste

Diese Liste der Abrechnungsvorschriften kann dann entweder mit der Stammdatenverzeichnis Aufträge (Transaktion KOK5) oder der Tabelle COAS oder einer Query (vergleichbar des vorherigen Infosets) verglichen werden, so dass hier durch einen Vergleich der erstellten Query und der vorhandenen Innenaufträge noch zu pflegende Innenaufträge erkannt werden können.

Für die Querylösung der Innenauftragsstammdaten bieten sich folgende Felder aus den Infoset über die Tabellen AUFK, CSKS, CSKT, CEPC und CEPCT an.

Auch hier weden die Felder wieder in der Ausgabereihenfolge angegeben mit der Kennzeichnung L als Listenfeld und S als Selektionsfeld.

Auftragsstammdaten AUFK
Auftragsnummer (L,S) AUFK-AUFNR
Kurztext (L) AUFK-KTEXT
Verantwortliche Kostenstelle (L,S) AUFK-KOSTV
Kostenstellentexte CSKT
Allgemeine Bezeichnung (L) CSKT-KTEXT
Auftragsstammdaten AUFK
Profitcenter (L,S) AUFK-PRCTR
Profit-Cener-Stammdaten Texte
Allgemeine Bezeichnung (L) CEPCT-KTEXT
Auftragsstammdaten AUFK
Kalkulationsschema (L) AUFK-KALSM

ACHTUNG:
Sofern es bei der Beschreibung der Kostenstellen oder Profit-Center Änderungen in der Bezeichnung gab, sind diese in den Tabellen CSKT und CEPCT mehrfach vorhanden. Hier werden dann auch die Auftragsstammdaten mehrfach mit angegeben. Entsprechend sollte ein Gültig Bis Feld als Selektionsfeld für die Bezeichnungen gewählt werden, oder alternativ die Bezeichnungen aus den Tabellen CPCT und CSKT weg gelassen werden.

Erweiterung:
Das Thema Abrechnungsvorschriften ist im Artikel "Abrechnungsvorschriften von Innenaufträgen auf identische verantwortliche Kostenstelle und empfangende Kostenstelle per Query mit Ampelfunktion prüfen" erneut aufgegriffen worden und hier ein wenig ausführlicher behandelt worden.

 

Hinweis:

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




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


Mittwoch, 14. Dezember 2011
08:33 Uhr

Query Stammdaten CO Kontrolle Verantwortliche

Ausgangslage
Im Rahmen der Stammdatenpflege beziehen sich die Innenaufträge über die verantwortliche Kostenstelle und das zugeordnete Profit-Center im Bereich der Verantwortlichen aufeinander, so dass für die Kostenstelle/das Profit-Center die Verantwortung identisch zum Innenauftrag ist.

Lösungsansatz:
Wie unter SAP Query Stammdaten PSM / CO Innenauftrag beschrieben würde sich eine Auswertung innerhalb der CO Tabellen anbieten.

Hierzu werden folgende Schritte erforderlich.

1.) Infoset definieren
Innerhalb der Transaktion SQ02 wird folgendes Infoset definiert. Hierfür wird als Datenquelle ein Tabellen-Join über Tabelle AUFK angelgt.
Es werden folgende Tabellen miteinander in Beziehung gesetzt:
AUFK: Auftragsstammdaten
CSKS: Kostenstellenstammsatz
CSKT: Kostenstellenelemente (für die Texte)
CEPC: Stammdatentabelle von Profit Centern
CEPCT: Profit-Center-Stammdaten Texte

Verknüpfungsbedingungen:
Die vorgeschlagenen Verknüpfungsbedingungen seitens SAP sollte hier wieder entfernt werden und folgende Verknüpfungsbedingungen definiert werden.

Folgende Tabellenfelder werden hierbei miteinander verknüpft:

AUFK-KOSTV <-> CSKS-KOSTL
Hierdurch wird die Verantwortliche Kostenstelle des Innenauftrages mit den Stammdaten der Kostenstellen verknüpft.

CSKS-KOSTL <-> CSKT-KOSTL
Hierdurch werden die Stammdaten der Kostenstelle mit der Bezeichnung der Kostenstelle verknüpft.

AUFK-PRCTR <-> CEPC-PRCTR
Hierdurch wird das Profitcenter des Innenauftrages mit den Stammdaten der Profit-Center verknüpft.

CEPC-PRCTR <-> CEPCT-PRCTR
Hierdurch werden die Stammdaten der Profit-Center mit der Bezeichnung der Profit-Center verknüpft.

Damit sind alle Verknüpfungen der Tabellen erfolgt. Der Einfachheit halber können nun alle Feldgruppen/Datenfelder übernommen werden. Dieses hat den Vorteil, dass dieses Infoset auch für weitere Queries zur Verfügung steht. Alternativ könnte man auch nur die notwendigen Felder übernehmen. Innerhalb der Query können dann die Felder auch wieder eingeschränkt werden.

1.) Query definieren
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 danna uch in der Query ausgegeben werden sollen:


Auftragsstammdaten AUFK
Auftragsnummer (L,S) AUFK-AUFNR
Kurztext (L) AUFK-KTEXT
Verantwortliche Kostenstelle (S) AUFK-KOSTV
Verantwortlicher (L) AUFK-USER2
Profitcenter (S) AUFK-PRCTR)


Kostenstellenstammdaten CSKS
Kostenstelle (L) CSKS-KOSTL

Kostenstellentexte CSKT
Allgemeine Bezeichnung (L) CSKT-KTEXT
Beschreibung (L) CSKT-KTEXT

Kostenstellenstammdaten CSKS
Verantwortlicher (L) CSKS-VERAK

Stammdatentabelle von Proftitcenter CEPC
Profitcenter (L) CEPC-PRCTR

Profit-Center-Stammdaten Texte (CEPCT)
Allgemeine Bezeichnung (L) CEPCT-KTEXT
Langtext (L) CEPCT-LTEXT

Stammdatentabelle von Proftitcenter CEPC
Verantwortlicher des Profitcenter (L) CEPC-VERAK


Damit sind die Grundfelder schon einmal definiert und die Query kann pronzipiel gestartet werden.
 

Erweiterung der Query


a) Lokales Feld anlegen / Formel

Ziel der Auswertung soll jedoch sein, dass hier auch eine Prüffunktion eingefügt wird, ob die Verantwortlichen identisch sind. Somit sollen also die Felder CEPC-VERAK, CSKS-VERAK und AUFK-USER2 miteinander verglichen werden. Ziel ist es hier entsprechende Symbole zu hinterlegen, wenn diese nicht übereinstimmen, über die dann in der Queryliste selektiert werden kann.


Hierzu gehen wir nicht in die Grundliste der Query (wo auch das Layoutdesign gepflegt wird) sondern wechselkn innerhalb der Querypflege mit nächstes Bild (F6) auf die Feldauswahl der Query.

Ü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:

Bei den Auftragsstammdaten:
Verantwortlicher -> V_IA
Beim Kostenstellenstammsatz:
Verantwortlicher -> V_KS
Beim Stammdatentabelle von Profit Centern:
Verantwortlicher des Profit Centers -> V_PC

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. Elegant wäre es natürlich, wenn wir im Infoset eine entsprechende leere Feldgruppe definiert hätten, es geht aber auch ohne

Das lokale Feld hat folgende Eigenschaften:

Kurzbezeichnung CHECKVERANT
Feldbezeichnung CheckVerant
Überschrift Checkverant

Da wir hier die Verantwortlichen kontrollieren wollen.

Innerhalb der Sachgruppe kann un die Feldgruppe des Infoset gelegt werden. Dieses ist dann der Bereich, wo das lokale Feld angelegt worden ist.

Als Feldeigenschaften könnten wir nun Textfelder, Rechnfelder etc. hinterlegen. In unseren Beispiel möchten wir als Eigenschaften allerdings IKONE hinterlegen. Über entsprechende Icons soll hier ein Unterschied ausgegeben werden. Hierzu legen wir eine Berechnungsvorschrift an. Dazu klicken wir auf "KOMPLEXE BERECHNUNG".

Nun können wir drei Bedingungen und eine sonstige Alternative angeben.

Dieses nutzen wir wie folgt:

Bedingung:
V_IA = V_KS AND V_IA = V_PC
Formel:
ICON_LED_GREEN

Wenn Verantwortliche des Innenauftrages mit Verantwortliche der Kostenstelle übereinstimmt UND Verantwortliche des Innenauftrages mit Verantwortliche des Profit-Center übereinstimmt ist alles in Ordnung und es soll eine grüne LED: so in Ordnung ausgegeben werden. Die Verfügbaren Ikons können über die untere Schaltfläche Ikonen ausgewählt werden.

Bedingung:
V_KS <> V_PC
Formel:
ICON_LED_YELLOW

Wenn die Verantwortliche der Kostenstelle mit der Verantwortlichen des ProfitCenter nicht übereinstimmt soll ein gelbes LED ausgegeben werden. Dieses wird als relativ unkritisch betrachtet.

Bedingung:
V_KS <> V_IA
Formel:
ICON_LED_RED

Als besonders kritisch wird betrachtet, wenn Verantwortliche der Kostenstelle nicht mit Verantwortliche des Innenauftrages übereinstimmt

Sonst:
ICON_LED_RED

Tritt irgendein anderer Fall auf, soll ebenfalls eine rote LED ausgegeben werden.

Sofern die Verantwortlichen in jeden Fall übereinstimmen sollen, kann natürlich auch die beiden mittleren Bedingungen weg gelassen werden. Als weitere Operatoren bieten sich neben AND auch OR an, sowie + - * und verschiedene andere Operatoren.


b) Berichtszuordnung

Durch die Auswertung dieser Query erhalten wir nun eine Liste mit den Stammdaten Innenauftrag, Kostenstelle und ProfitCenter. Sollten nun die Verantwortlichen nicht übereinstimmen müssten wir nun einzeln die entsprechende Objekte bearbeiten. Hier ist es aber möglich aus der Query direkt in die Stammdatenpflegetransaktion zu wechseln, wenn wir auf das Feld Auftragsnummer, Kostenstelle oder Profit-Center doppelklicken. Hierzu muss in der Querypflege eine Berichtszuordnung gepflegt werden.

Hierzu rufen wir wiederum über die SQ01 die Query für eine Änderung auf.
Über SPRINGEN->BERICHTSZUORDNUNG können Empfängerberichte definiert werden.

Über das „+“ (Zeile einfügen) können weitere Query eingefügt werden. Alternativ kann hier auch ein anderer Berichtstyp ausgewählt werden. Über "TR Transaktion" können hier auch die Stammdatenpflegetransaktionen hinterlegt werden.

Hier hinterlegen wir folgende Transaktionen:

KE52 Profit Center ändern
KS02 Kostenstelle ändern
KO02 Innenauftrag ändern


Nun wird die Berichtszuordnung gespeichert und auch die Query kann gespeichert und genutzt 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.




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


Dienstag, 6. Dezember 2011
09:44 Uhr

SAP Query Stammdaten PSM / CO Innenauftrag

Leider wird die Tabelle FMZUOB (Zuordnung von CO Objekten zu PSM Objekten) durch die Einführung der FMDERIVE nicht mehr gepflegt, so dass keine Verknüpfung von Fonds innerhalb der Tabellen FMFINT bzw. FMFINCODE (bspw. für den Finanzierungszweck) mit den Stammdaten der Innenaufträge in der Tabelle AUFK möglich ist. Hier war bis zur Einführung der FMDERIVE eine Verknüpfung über die OBJNR möglich.

Eine direkte Verknüpfung der Tabellen FMFINCODE mit AUFK scheitert daran, dass die Auftragsnummer in der Tabelle AUFK mit führenden 0en gespeichert wird und in der Tabelle FMFINT ohne führender 0. Eine entsprechende Auswertung ist daher über die Stammdeten der Fonds aus PSM und der Innenaufträge in CO scheinbar nicht möglich.

Technischer Hintergrund:
Das Feld FMFINCODE-FINCODE   (Fond) ist vom Typ Char mit einer Länge von 10 Zeichen, das Feld AUFK-AUFNR (Auftragsnummer) ist zwar auch vom Typ Char allerdings mit einer Länge von 12 Zeichen. Somit können beide Felder nicht verknüpft werden, da diese Werte nicht übereinstimmen.

Per Codig innerhalb eines Zusatzfeldes ist es jedoch möglich nur den hinteren Teil aus AUFK-AUFNR zu verwenden und damit eine Verknüpfung zu erstellen.

Diese Methode ist im Artikel "SAP Query ABAP Coding im Zusatzfeld für Verknüpfung Innenauftrag und Fond bzw. Finanzierungszweck" beschrieben, inklusive einer Angabe, ob der Innenauftrag gesperrt ist.

Hinweis: Query Stammdaten CO Innenauftrag PSM-FM Fond

Der erwähnte Artikel ist Teil einer Serie um Stammdaten von CO Innenaufträgen und PSM-FM Fonds miteinander zu verknüpfen.
  1. "SAP Query ABAP Coding im Zusatzfeld für Verknüpfung Innenauftrag und Fond bzw. Finanzierungszweck"
  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"

Erweiterung durch Zusatzfeld/Zusatztabelle Coding im Infoset

Eine Erweiterung dieser Vorgehensweise ist auch im Artikel "SAP Query innerhalb des SAP Moduls PSM FM beziehungsweise Haushaltsmanagement" festgehalten.

Am Anwendungsbeispiel einer CO Einzelpostenliste mit Ergänzung der Stammdaten aus CO-Innenauftrag und PSM-FM Fond  ist dann in folgender Artikelserie beschrieben:
  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" (Definition eines Infoset mit entsprechenden Zusatzfeldern und Einbindung der Tabelle FMFINCODE als Zusatztabelle zu AUFK
  2. "Query Einzelpostenliste Innenauftrag mit Ausweis Ertrag und Aufwand Zweiter Teil Query zur Datenaufbereitung" (Auswertung der Tabelle COEP und einige Hintergrundinformationen zu den unterschiedlichen Währungen in CO und den Kostenarten)

Auswertung CO Stammdaten

Ansonsten lassen sich innerhalb des Moduls CO  die Stammdaten gut miteinander verknüpfen.

Hier bieten sich folgende Tabellen an:

Stammdaten der Innenaufträge:
AUFK

Stammdaten der verantwortlichen Kostenstelle:
CSKS (Kostenstellenstamm)
CSKT (Texte der Kostenstellen)

Stammdaten der Profit-Center:
CEPC (Profitcenterstammdaten)
CEPCT (Texte der Profitcenter)
 

Hinweis:

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




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


Freitag, 17. Juni 2011
10:05 Uhr

Transport von SAP Queries (DL/UL)

Ausgangslage:
Eine SAP Query soll inklusive Infosets von einen System auf ein anderes SAP System transport werden.

Lösung:
Hier gibt es in der Infosetpflege (Transaktion SQ02) die Möglichkeit der Nutzung eines SAP Query Transporttool. Hier können Benutzergruppen, Infoset, Infoset und Query aber auch nur Queries auf unterschiedliche Weise transportiert werden.

Besonders interessant ist hierbei die Option des Download bzw. Upload als Transportvariante.

In das SAP Query Transporttool gelangt man entweder über die Transaktion SQ02 und hier über das "LKW" Symbol (Transporte STRG F5). Nun wir der Report RSAQR3TR gestartet und von hier kann ein Transport bzw. Download gestartet werden.

Über die Transportaktion Upload können dann auch entsprechende Queries importiert werden.

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.

 

Hinweis:

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




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


Mittwoch, 31. März 2010
08:33 Uhr

Transaktion anlegen (Report, Parameter) bspw. für SAP Query / Unterschied Parameter- oder Reporttransaktion

Problem:
Aus einer Query soll eine entsprechende Transaktion zum Aufrufen der Query erstellt werden.

Lösung:
Über SQ01 kann bei einer Query durch das Menü

Query->
Weitere Funktionen->
Reportname anzeigen

der hinter der Query liegende Reportname angezeigt werden.

Sofern eine Tranaktion für Rechercheberichte (bspw. für das Modul PSM-FM angelegt werden soll ist auch der Artikel "Parametertransaktion für Recherchebericht" interessant.

Dieser kann als kundeneigene Transaktion über die Transaktion SE93 angelegt werden und ggf. über einen Workbench-Transportauftrag in das entsprechende System transportiert. Dieses funktioniert bei anderen Berichten ebenfalls über System->Status im Feld Report.

Hier bieten sich zwei Variante an:

a) Reporttransaktion


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

b) Parametertransaktion


Eine Parametertransaktion ermöglicht es Varianten zu einer Transaktion anzulegen. Hier bietet sich bspw. die Transaktion START_REPORT an.

Hier geben wir in der Parametertransaktion bestimmte Vorschlagswerte zur Transaktion START_REPORT vor und überspringen das Einstiegsbild.

Hierbei werden die Dynprofelder der Transaktion festgelegt. So lautet die Bezeichnung des Feldes Report der Transaktion START_REPORT bspw. "D_SREPOVARI-REPORT". So dass hier der Reportname entsprechend eingegeben werden kann. Interessanter ist hier jedoch noch das Feld Variante (Dynprofeld "D_SREPOVARI-VARIANT"), da hier entsprechend gepflegte Selektionsvariante je Report hinterlegt werden können.

Auf diese Weise kann direkt über die kundeneigene Transaktion eine entsprechende Selektionsvariante zu einen Report (inkl. etwaiger gesperrter Felder) gestartet und ausgewertet werden.

Somit eignet sich diese Transaktionsvariante insbesondere dann, wenn man auch gleich eine Selektionsvariante mit übergeben bzw. entsprechend ausgewählt haben mag.

Anwendungsbeispiele für Parametertransaktionen sind unter anderen in folgenden Artikeln beschrieben: Hier bietet sich oftmals auch eine geschützte Selektionsvariante ALLGEMEIN an um Standardeinstellungen direkt festzulegen und bestimmte Felder (bspw. Kontengruppen etc.) zu schützen.
 

c) Transaktion aus Benutzermün im Profilgeneratur erstellen.


Neben den genanten Möglichkeiten exisitert auch die Variante aus der PFCG heraus innerhalb eines Benutzermenüs einen Report bzw. einen Bericht (bspw. eine Query) einzufügen. Hier wird ebenfalls eine passende Transaktion generert. Hier ist insbesondere zu beachten, dass per Default auch der Transaktionscode automatisch generiert wird (dieses kann über weitere Optionen deaktiviert werden).

d) Nachtrag 2016: Variantentransaktion


Das Thema Variantentransaktion beziehungsweise kundeneigene Transaktionen zum direkten Aufruf einer vorhandenen Transaktion mit einer angelegten Variante ist im Artikel "Kundeneigene Transaktionen zu Berichten in PSM FM Haushaltsmanagement zum Beispiel Belegjournal anlegen (Variantentransaktion)" beschrieben.



Zusammenfassung
Die Variante der Parametertransaktion ist sicherlich vorteilhaft, wenn entsprechende Selektionsvariante in Verbindung mit Layoutvarianten zu einer Query genutzt werden. Hierbei sollte jedoch geprüft werden, ob eine Berechtigungsprüfung auf diese Transaktion erfolgt. Die Reporttransaktion kann dagegen direkt gestartet werden.

Unabhängig davon werden aber auch die Berechtigungsobjekte/Berechtigungswerte des eigentlichen Report geprüft. Eine Besonderheit könnte bei der Reporttransaktion noch die Möglichkeit der Verwendung eines kundeneigenen Berechtigungsobjektes sein, welches bei Anlage der Reporttransaktion auf entsprechend hinterlegten werten geprüft wird.... wobei dieses auch die Transaktion selbst (S_TCODE) innerhalb der entsprechenden Rolle sein kann.

Grundsätzlich hat die Parametertransaktion ihren Vorteil bei der Verwendung von Selektionsvarianten bzw. wenn bestimmte Daten vorbelegt werden sollen. Dahingehend hat die Reporttransaktion ihren Vorteil, wenn ein Bericht direkt ausgeführt werden soll.


 

Hinweis:

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




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


Dienstag, 16. September 2008
13:14 Uhr

Kurzanleitung Anlage einer SAP Query Auswertung ANBWA in der Profit-Center-Rechnung über ANBW und GLPCA


Bisher war dieser Artikel als eine Kurzanleitung zur Anlage einer SAP Query gedacht. Zwischenzeitlich gibt es eine ausführlichere Anleitung zum Einstieg ins Thema unter folgenden Hinweis. Dennoch soll in diesen Artikel weiterhin die Auswertung der Anlagenbewegungsarten über eine Query beschrieben werden.

 

 

Handbuch SAP Query

Eine ausfürhliche 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.

 

Auswertung Anlagenbewegungsarten in der Profit-Center-Rechnung


Über eine kennzahlenbasierte Kostenumlage (KSUB) sollen u.a. auch Konten im Bereich der Anlagenbuchhaltung umgelegt werden. Da hier die Konten umgelegt werden gehen die Informationen aus der Anlagenbuchhaltung (Anlagenbewegungsarten) verloren.

Gleiches Problem innerhalb der ProfitCenter Rechnung tritt beim Abgang von Anlagen auf, da diese zu vollen AHK auf den Profitcenterbeleg gebucht werden selbst wenn diese dann eigentlich nur noch einen Restbuchwert aufweisen.

Lösungsansatz Tabellenauswertung GLPCA und ANBW


Es sollen alle innerhalb der Anlagenbuchhaltung angefallenen Profitcenterbelege nach der Anlagenbewertungsart ausgewertet werden.

Hierzu könnte entweder die Tabelle GLPCA über die Felder RYEAR, KSL, RPRCTR und ANBW über SE16 ausgewertet werden oder alternativ die Tabelle über eine Query ausgewertet werden.

Überlegung

SE16:
Hier ist das entsprechende Berechtigungsobjekt siehe Artikel mit der Berechtigungsgruppe der Tabelle GLPCA zu pflegen. Durch Freigabe der Transaktion SE16 könnten jedoch auch andere Tabellen innerhalb der Berechtigungsgruppe ausgewertet werden.
Daher ist hier ggf. eine SAP Query eine Möglichkeit.


Vorgehensweise

Sap Query:
Die Anlage einer Query erfolgt in drei Schritten.

a) Anlage eines Infosets (Datengrundlage)

Über die Transaktion SQ02 kann entweder eine Tabelle direkt ausgewertet werden oder eine Verknüpfung (Join) mehrere Tabellen.
Direktes Lesen der Tabelle wäre eine Auswertung der Tabelle GLPCA.
In unseren Beispiel soll die Tabelle jedoch auch mit der Beschreibung der Bewegungsarten verknüpft werden. Somit wäre hier ein Join der Tabellen GLPCA und TABWT als Datengrundlage.

Hier ist GLPCA als Grundtabelle.
Über
BEARBEITEN->Tabelle einfügen
kann nun die Tabelle TABWT mit übernommen werden.

Hier ist auch schon direkt die Verknüpfung der Tabellenfelder GLPCA-ANBWA und TABWT-BWASL vordefiniert.

Somit kann bei der Auswertung auch direkt das Feld BWATXT (Bezeichnung Anlagenbewgungsart) in der Query ausgegeben werden.

Ist der Join definiert können alle Tabellenfelder oder auch nur die Keyfelder übernommen werden.
Werden alle Tabellenfelder übernommen können diese Felder dann innerhalb einer Query auch genutzt werden.

Nach Generierung des Infosets kann dieses dann direkt genutzut werden.

Das entsprechend generierte Infoset sollte dann noch einer passenden Benutzergruppe zugewiesen werden. Andernfalls kann dieses nicht weiter genutzt werden.

b) Anlage der Query

Die Query definiert dann die Feldauswahl zur Selektion und/oder Ansicht via des Infosets.

Hierzu kann über die Transaktion SQ01 ein Query angelegt werden.

Bei der Anlage des Query wird dann direkt auf den Infoset Bezug genommen.
Über die Grundliste können dann die relevanten Felder aus den beiden per Infoset definierten Tabellen übernommen werden.

Hierbei kann bei den Tabellen zwischen Listenfeldern (diese werden ausgegeben) und Selektionsfeldern (über diese wird dann eine Auswahl getroffen) pro Feld gewählt werden.

Als Werte können hier:
Aus Tabelle GLPCA
Selektionsfelder:
RYEAR (Geschäftsjahr)
RACCT (Buchungskonto)
Listenfelder:
RPRCTR (Profitcenter)
KSL (Betrag)
ANBWA (Anlagenbewegungsart)


Aus Tabelle TABWT
Listenfelder:
BWATXT (Bezeichnung Anlagenbewegungsart)
Selektionsfeld:
SPRAS (Sprachenschlüssel)

Der Sprachenschlüssel sollte selektiert sein, damit nicht für jede gepflegte Sprachversion die Daten erneut ausgegeben werden.


c) Pflege der Benutzergruppe

Über die Transaktion SQ03 können dann die entsprechenden Benutzergruppen gepflegt werden und auch die Benutzer mit Query Berechtigung einer entsprechenden Benutzergruppe zugeordnet werden.


Innerhalb der Benutzerparameter kann die Benutzergruppe und der Arbeitsbereich innerhalb der Query zugewiesen werden.




Nachtrag:
Betroffene Berechtigungsobjekte:

S_TCODE
SQ01
S_TABU_DIS
Act. 03
Berechtigungsgruppe
AC, KA, GC

Weitere Beispiele für Query

Bisher erstellte Query sind unter den Tag Query hier ebenso wie diese Einführung als Artikel zu finden. Daneben sind sowohl im Amazon Partnershop (siehe Onlineshop) als auch bei den Buchempfehlungen  einige Literaturempfehlungen zum Thema zu finden.

Insbesondere das Buch "Praxishandbuch SAP Query-Reporting (SAP PRESS) Von Stephan Kaleske, Karin Bädekerl, Heinz Forsthuber" ist hier sicherlich empfehlenswert.

Daneben bin ich aber auch von Martin Peto und Katrin Klewinghaus " Reporting im SAP-Finanzwesen: Standardberichte, SAP QuickViewer und SAP Query" begeistert und finde, dass sich beide sehr gut ergänzen. Gerade da Sie unterschiedliche Schwerpunkte setzen.

Ausführliche Literaturempfehlungen

Wie bereits erwähnt haben Martin Peto und Katrin Klewinghaus zum Thema SAP Query auch folgendes Buch geschrieben.

Reporting im SAP - Finanzwesen
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.

Praxishandbuch SAP Query-Reporting

ISBN: 978-3836218405

Eine ausführlichere Beschreibung dieses Buch ist auf der Seite "Praxishandbuch SAP Query-Reporting" 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.




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


Mittwoch, 2. August 2006
13:54 Uhr

Arbeitsbereich AbapQuery festlegen

Über die Benutzerparameter läßt sich der Arbeitsbereich innerhalb Abap Query vorbelegen.

Parameter AQW

ohne Wert = mandantenabhängig (Standardbereich)
G = mandantenunabhängig (globaler Bereich)


Weitere Parameter wären:

AQQ: Query
AQB: Benutzergruppe
AQS: Sachgebiet

Hinweis:

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




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


Dienstag, 20. Juni 2006
07:38 Uhr

Verwendungsnachweis von Tabellen in Transaktionen

Innerhalb eines Anzeigebildes (DynPro, ...) kann meistens über die Hilfe und dort auf technische Info innerhalb eines Eingabefeldes die hinterlegte Datenbanktabelle (oder der View) nebst des Datenbankfeldes angezeigt werden.

Möchte man nun den umgekehrten Weg (Nachweis der Verwendung einer Tabelle innerhalb von Transaktionen) nehmen, kann folgende Vorgehensweise weiter helfen.

Durch die Transaktionen SE11/SE12 ist die Tabellenstruktur zu sehen. Über Hilfsmittel-Verwendungsnachweis können Programme/Reports angezeigt werden, die sich dieser Tabelle bedienen.

Die Reports sind innerhalb der Tabelle TSTC (SAP-Transaktions-Codes) Transaktions-Codes zugeordnet. Auf diese Weise lassen sich dann, wenn auch umständlich, die diese Tabelle nutzenden Transaktionen herausfinden.

Der umgekehrte Weg, von Programmen hin zu verwendeten Tabellen ist durch die Query Tabellen hinter Transaktionscode oder ABAP Programm über eine SAP Query ermitteln beschrieben. Hier kann sowohl abhängig vom ABAP Programm bzw. der Transaktion die zu Grunde liegenden Tabellen ermittelt werden. Ergänzend kann durch so eine Query natürlich auch die Programme zur Tabelle ausgwertet 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.



 

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


Freitag, 17. März 2006
09:20 Uhr

SapQuery Personalkostenumlage VZÄ

Zur Auswertung von Vollzeitäquivalenten für eine kostenstellenbezogene Personalkostenumlage benötigen wir als Variablen für die Personen die Kostenverteilung und den Anteil der Arbeitszeit im Verhältnis der tariflichen Arbeitszeit.

Hierzu würde ich gerne den IT 1018 aus Organisationsmanagement und IT 0007 aus der Personaladministration miteinander in Verbindung bekommen. Ideal wäre es hier noch die Personalnummer dabei zu haben.

Mittels einer AdHocQuery kann ich zumindest die Informationen wöchentliche Arbeitszeit / tarifliche Wochenarbeitszeit aus der PA herausbekommen.

Mein Problem ist nun eine Auswertung der Kostenverteilung innerhalb des Organisationsmanagements.

Eine Auswertung über S_AHR_61016532 ist zwar eine Möglichkeit würde aber, da viele Mitarbeiter eine Kostenverteilung inne haben, relativ viel Zeit in Anspruch nehmen.

Daher wäre mir eine Query die angenehmere Variante.

Bisher ist mein Kenntnisstand so, dass die Kostenverteilung innerhalb der Tabellen HRP1018 und HRT108 abgebildet werden.

Über das Feld Tabnummer könnte ich vermutlich beide Tabellen miteinander verknüpfen.

Hierdurch erhalte ich aus der Tabelle HRP1018 die Planstelle über das Feld OBJID und über die Verweisnummer auf Tabellenteil "TABNR" ein Schlüsselfeld, dass ich innerhalb der Tabelle HRT1018 verwenden kann.

Dort sind als Werte Kostenstelle, Auftrag und Prozent in den Feldern
KOSTL, AUFNR und PROZT hinterlegt.


Fraglich sind nun folgende Punkte:

Um eine Gegenüberstellung zu den zugewiesenen Planstellen zu Personalnummern zu verwirklichen müßte ich den Infotyp Organisatorische Zuordnung innnerhalb der Personaladministration auswerten, da teilweise unbesetzte Planstellen vorhanden sein können, die bei der Ermittlung von VZÄ nicht mit berücksichtigt werden dürfen.

Hier gibt es nun aber auch Personen, die mehr als einer Planstelle zugewiesen sind. Eine Auswertung per AdHocQuery lieferte mir jedoch nur eine Planstelle.

Ferner sind in der Kostenverteilung nur von der Hauptkostenstelle abweichende Kostenträger angegeben, so dass eine Berechnung der verbleibenden Kostentragung erfolgen muss.


Lösungsansätze

A) Kostenverteilung

1. Schritt:

Innerhalb der Tabelle PA0001 kann ich durch die Felder PERNR und PLANS eine Verknüpfung zwischen Person und Planstelle herleiten.

Ferner kann durch die Tabelle PA0008 eine Verknüpfung zur Vergütung erfolgen.

2. Schritt:

Über die Tabelle HRP1018 kann ich das Feld OBJID als Verknüpfung zur Planstelle aus der Tabelle PA0001 verwenden. Hier verwende ich das Feld TABNR als weiteres Schlüßelfeld.

3. Schritt:

Über TABNR aus HRP1018 kann ich innerhalb der Tabelle HRT1018 mir die Werte KOSTL, AUFTR und PROZT ausgeben lassen.

Zu beachten ist, dass ich sofern die PROZT nicht 100 ergeben aus der Tabelle PA0001 das Feld KOSTL für die verbleibendene Prozent als Kostenträge nehmen muss.

B) Arbeitszeitanteil

1. Schritt

Abgleich IT 0007 Sollarbeitszeit zur Arbeitszeit innerhalb IT0008 Basisbezüge. Hier kann es zu unerwünschten Unterschieden geben.

Danach muß die Tarifliche Wochenarbeitszeit aus IT0008 mit IT007 im Verhältnis gesetzt werden.

2. Schritt

Datenbanktabellen ausfindig machen.


C) Anlegen einer Query

Zum Anlegen einer Query ist ein neues Sachgebiet zu generieren. Hierfür muss ein Join der Tabellen erfolgen.




Sachgebiet/View/ SQ01 SQ02
Ich habe nun folgende Tabellen miteinander verknüpft.

HRP1018-TABNR = HRT1018-TABNR
PA0001-PLANS = HRP1018-OBJID
PA0001-PERNR = PA0000-PERNR
PA0001-PERNR = PA0002-PERNR
PA0001-PERNR = PA0007-PERNR
PA0001-PERNR = PA0008-PERNR
PA0001-PERNR = PA0041-PERNR
PA0002-PERNR = PA0000-PERNR
PA0002-PERNR = PA0008-PERNR
PA0008-PERNR = PA0000-PERNR

Ziel ist folgendes:
PA0001 soll mir die Personalnummer und die Planstelle einer Person liefern, PA0002 den Namen einer Person, PA0008 die Vergütungsgruppe einer Person und Über die OBJID in der Tabelle HRP1018 möchte ich die Kostenverteilung einer Planstelle aus der Tabelle HRT1018 auslesen.

Soweit funktioniert meine Abfrage auch.

Mein Problem ist nun die zeitliche Abgrenzung. Ich müßte diese Query auf das Jahr 2005 beschränken. Hier fehlt mir jedoch eine sinnvolle Lösung.

Hat möglicherweise jemand von euch einen Ansatzpunkt?

SAP: R/3 4.6b

Hinweis:

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




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


Hinauf




Werbung


© 2004 - 2017 Andreas Unkelbach
Andreas Unkelbach

Stichwortverzeichnis
(Tagcloud)


Aktuelle Infos (Abo)

Facebook Twitter Google+

»Schnelleinstieg ins SAP Controlling (CO)« und »Berichtswesen im SAP ® ERP Controlling«
Privates

Kaffeekasse 📖 Wunschliste